А если крупному специализированному грузовому автопарку нужно обеспечить безотказный сервис перевозок, то да, могут и небольшой нефтеперегонный комбинат поставить, если другими способами не обеспечить SLA.
Минус ДЦ это в случае облаков нормальная ситуация, только Яндекс на этом не акцентирует внимание, потому что тогда TCO не так "вкусно" выглядет будет - спасение утопающих в руках самих утопающих, безотказность сервиса надо проектировать на стороне приложений, покупая и оплачивая избыточную геораспределенную инфраструктуру.
Тут непонятно, почему Яндекс объясняет не это, а то, что отказы ДЦ случаи редкие, почти что несуществующие. Вернее, понятно, но ничего хорошего
Ваш текст очень напоминает по стилю те отмазки, которые лепит ваша служба поддержки, чтобы сделать вид, что чем-то помогает
Такие подстанции проектируются как сложные распределённые системы, чтобы предоставить потребителям определённые гарантии независимости ячеек.
Какая потребителям разница, как они планируются и проектируются, если инженеры Яндекса, кажется, по-прежнему считают, что электричество в розетках заводится само?
В целом, понятно, что любую облачную нагрузку надо проектировать в предположении, что 1 ДЦ Яндекса может выйти из чата в любой момент. Но это не особо новость, и не относится только к Яндексу
принцип единственной ответственности, который гласит, что единица кода (например, функция или «компонент») должна выполнять только одну задачу
Вы пишете для начинающих разработчиков, и тут же вбрасываете вредную дезинформацию. Этот принцип был сформулирован а) совершенно иначе б) упоминал исключительно класс в ООП, а не "компонент" или функцию.
"Давайте приготовим оливье, только вместо картошки возьмем репу, а заправим кетчупом; чот какой-то плохой этот ваш оливье, не понравился, не пойму, что вы в нем находите"
Владимир, вы серьезно про выход из "операционки" и про то, что бизнес не должен зависеть от сотрудников рассказываете с такими показателями? Как-то не бьется одно с другим, возможно, я что-то не понимаю
Поиски темной материи это очень, очень денежно, каждый следующий эксперимент на порядок дороже предыдущего, и на каждый отрицательный результат есть оправдание "да, но мы зато узнали много нового" - разумеется, они будут продолжаться
В самом начале предположил, что увижу в статье, и не ошибся: почему-то в таких статьях про переработки берут график переработок 40-50-60 часов в неделю СВЕРХ 40 часовой рабочей недели, и экстраполируют это на любые переработки вообще, включая 4-10 часов в неделю.
При том, что переработок следует избегать, эта аргументация не подходит к другим случаям.
При этом 5–10 лет назад даже не нужно было врать — ты мог просто написать условно: «Умею писать код на C#, готов всему обучаться», и вот тебя уже приглашают на работу.
Нет, такого я не припоминаю никогда. Какая-то секта свидетелей небесного СССР, право слово
Парни, рассмотрите, пожалуйста, возможность выпуска платы на чипе с 1. аппаратным нейроускорителем (типа t527 у allwinner) 2. с встроенным remote core для задач реального времени (прерывания и т.п.) - тот же a523, t527. Если вы и документацию для него гармонизируете, это будет пушка-бомба
Если компаниям не нравится результат внедрения аджайл, значит, они неправильно его используют.
Нет, необязательно. Это значит, что то, что получилось, не соответствует их ожиданиям, даже если внедрено правильно. Например, стало сложнее бюджетировать, сложнее вести наём, и это не окупается более быстрым внедрением изменений в продукт
Что значит "тоже"? Я же утверждаю обратное
А если крупному специализированному грузовому автопарку нужно обеспечить безотказный сервис перевозок, то да, могут и небольшой нефтеперегонный комбинат поставить, если другими способами не обеспечить SLA.
Минус ДЦ это в случае облаков нормальная ситуация, только Яндекс на этом не акцентирует внимание, потому что тогда TCO не так "вкусно" выглядет будет - спасение утопающих в руках самих утопающих, безотказность сервиса надо проектировать на стороне приложений, покупая и оплачивая избыточную геораспределенную инфраструктуру.
Тут непонятно, почему Яндекс объясняет не это, а то, что отказы ДЦ случаи редкие, почти что несуществующие. Вернее, понятно, но ничего хорошего
Ваш текст очень напоминает по стилю те отмазки, которые лепит ваша служба поддержки, чтобы сделать вид, что чем-то помогает
Такие подстанции проектируются как сложные распределённые системы, чтобы предоставить потребителям определённые гарантии независимости ячеек.Какая потребителям разница, как они планируются и проектируются, если инженеры Яндекса, кажется, по-прежнему считают, что электричество в розетках заводится само?
В целом, понятно, что любую облачную нагрузку надо проектировать в предположении, что 1 ДЦ Яндекса может выйти из чата в любой момент. Но это не особо новость, и не относится только к Яндексу
Блин, ребят, всё понимаю, эпоха капитализма, но так грести деньги это надо не иметь совести, конечно
Судя по всему, там флеш-рояль иностранных разведок, а не только российской https://teletype.in/@2634929645652/pulpfiction?utm_source=pocket_saves
Попробуйте фоссил https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki
Вы пишете для начинающих разработчиков, и тут же вбрасываете вредную дезинформацию. Этот принцип был сформулирован а) совершенно иначе б) упоминал исключительно класс в ООП, а не "компонент" или функцию.
"Давайте приготовим оливье, только вместо картошки возьмем репу, а заправим кетчупом; чот какой-то плохой этот ваш оливье, не понравился, не пойму, что вы в нем находите"
Зумеры изобрели DLQ? :)
Владимир, вы серьезно про выход из "операционки" и про то, что бизнес не должен зависеть от сотрудников рассказываете с такими показателями? Как-то не бьется одно с другим, возможно, я что-то не понимаю
Поиски темной материи это очень, очень денежно, каждый следующий эксперимент на порядок дороже предыдущего, и на каждый отрицательный результат есть оправдание "да, но мы зато узнали много нового" - разумеется, они будут продолжаться
Есть директива от АНБ, к примеру: https://habr.com/ru/news/699142/ Рекомендация не требование и не принуждение, однако является формой давления
Там ещё указатели между узлами одного уровня есть для навигации; это, конечно, технические детали, но при навигации по индексу они крайне полезны.
Статья хорошая.
Похоже, этот модем это аппаратный задел под будущие проекты со Старлинк
В самом начале предположил, что увижу в статье, и не ошибся: почему-то в таких статьях про переработки берут график переработок 40-50-60 часов в неделю СВЕРХ 40 часовой рабочей недели, и экстраполируют это на любые переработки вообще, включая 4-10 часов в неделю.
При том, что переработок следует избегать, эта аргументация не подходит к другим случаям.
Похоже, проблема в самой методике, а не в пользователях
KPI(ой, простите, мы же не в водопаде из 90х) OKR требует запускать фичи-фичулечки, иначе можно и на аттестации банан получитьПри этом 5–10 лет назад даже не нужно было врать — ты мог просто написать условно: «Умею писать код на C#, готов всему обучаться», и вот тебя уже приглашают на работу.Нет, такого я не припоминаю никогда. Какая-то секта свидетелей небесного СССР, право слово
Есть какая-то внутренняя логика в том, что если человек -- т.н. "криптоэнтузиаст", то он с большой вероятностью неграмотно пишет на русском
В а527 нет нейроускорителя, только в t527. Конечно, можно внешний edge ai поставить, однако это практически вдвое удорожает ядро системы
Парни, рассмотрите, пожалуйста, возможность выпуска платы на чипе с 1. аппаратным нейроускорителем (типа t527 у allwinner) 2. с встроенным remote core для задач реального времени (прерывания и т.п.) - тот же a523, t527. Если вы и документацию для него гармонизируете, это будет пушка-бомба
Нет, необязательно. Это значит, что то, что получилось, не соответствует их ожиданиям, даже если внедрено правильно. Например, стало сложнее бюджетировать, сложнее вести наём, и это не окупается более быстрым внедрением изменений в продукт