Тема поднимается полезная, и с исходными посылами сложно спорить. Но к ней прилагается очередная из миллиона статья с изложением одних и тех же выводов и мыслей. И ошибки допускают одни и те же. Вот пример первой же:
если ипотечный платёж сравним с арендной платой, возможно, имеет смысл купить жильё
Ипотечный платеж состоит из уплаты процентов + уплаты основной части долга. В этом платеже вы навсегда прощаетесь только с первой частью денег, вторую часть вы не отдаете, вы обмениваете её на "бетон", то есть деньги остаются у вас, просто меняют свою форму/ликвидность. На примере: допустим, в платеже 50 тыс. рублей по ипотеке 15 тыс. это проценты, а 35 основная сумма долга - получается, что вы как бы арендуете эту квартиру за 15 тыс, что обычно выгоднее, чем могло бы показаться. Так что имеет смысл покупать, если проценты сравнимы, а не когда весь платеж. На практике из-за аннуитентной схемы платежа сумма процентов меняется о каждом взносе и усложняет расчёт, но он остается верным по сути.
Ну и по остальным примерам есть что сказать. Хорошо на эту тему пишет Бодо Шефер, тем более что его опыт складывался в схожей с нашей экономической ситуацией, с высокой инфляцией и штормами в экономике послевоенной Германии
Вот что мы видим из SLA yandex compute. Чуть раньше на сайте пишут, что фактический уровень доступности - Tier 3.
Из снимка я могу сделать вывод, что написана, мягко говоря, неправда -- номинально ДГУ есть, фактически оказывается, что она неспособна питать ДЦ при отказе лучей питания национальных операторов.
А если крупному специализированному грузовому автопарку нужно обеспечить безотказный сервис перевозок, то да, могут и небольшой нефтеперегонный комбинат поставить, если другими способами не обеспечить SLA.
Минус ДЦ это в случае облаков нормальная ситуация, только Яндекс на этом не акцентирует внимание, потому что тогда TCO не так "вкусно" выглядет будет - спасение утопающих в руках самих утопающих, безотказность сервиса надо проектировать на стороне приложений, покупая и оплачивая избыточную геораспределенную инфраструктуру.
Тут непонятно, почему Яндекс объясняет не это, а то, что отказы ДЦ случаи редкие, почти что несуществующие. Вернее, понятно, но ничего хорошего
Ваш текст очень напоминает по стилю те отмазки, которые лепит ваша служба поддержки, чтобы сделать вид, что чем-то помогает
Такие подстанции проектируются как сложные распределённые системы, чтобы предоставить потребителям определённые гарантии независимости ячеек.
Какая потребителям разница, как они планируются и проектируются, если инженеры Яндекса, кажется, по-прежнему считают, что электричество в розетках заводится само?
В целом, понятно, что любую облачную нагрузку надо проектировать в предположении, что 1 ДЦ Яндекса может выйти из чата в любой момент. Но это не особо новость, и не относится только к Яндексу
принцип единственной ответственности, который гласит, что единица кода (например, функция или «компонент») должна выполнять только одну задачу
Вы пишете для начинающих разработчиков, и тут же вбрасываете вредную дезинформацию. Этот принцип был сформулирован а) совершенно иначе б) упоминал исключительно класс в ООП, а не "компонент" или функцию.
"Давайте приготовим оливье, только вместо картошки возьмем репу, а заправим кетчупом; чот какой-то плохой этот ваш оливье, не понравился, не пойму, что вы в нем находите"
Владимир, вы серьезно про выход из "операционки" и про то, что бизнес не должен зависеть от сотрудников рассказываете с такими показателями? Как-то не бьется одно с другим, возможно, я что-то не понимаю
Поиски темной материи это очень, очень денежно, каждый следующий эксперимент на порядок дороже предыдущего, и на каждый отрицательный результат есть оправдание "да, но мы зато узнали много нового" - разумеется, они будут продолжаться
В самом начале предположил, что увижу в статье, и не ошибся: почему-то в таких статьях про переработки берут график переработок 40-50-60 часов в неделю СВЕРХ 40 часовой рабочей недели, и экстраполируют это на любые переработки вообще, включая 4-10 часов в неделю.
При том, что переработок следует избегать, эта аргументация не подходит к другим случаям.
При этом 5–10 лет назад даже не нужно было врать — ты мог просто написать условно: «Умею писать код на C#, готов всему обучаться», и вот тебя уже приглашают на работу.
Нет, такого я не припоминаю никогда. Какая-то секта свидетелей небесного СССР, право слово
Тема поднимается полезная, и с исходными посылами сложно спорить. Но к ней прилагается очередная из миллиона статья с изложением одних и тех же выводов и мыслей. И ошибки допускают одни и те же. Вот пример первой же:
если ипотечный платёж сравним с арендной платой, возможно, имеет смысл купить жильёИпотечный платеж состоит из уплаты процентов + уплаты основной части долга. В этом платеже вы навсегда прощаетесь только с первой частью денег, вторую часть вы не отдаете, вы обмениваете её на "бетон", то есть деньги остаются у вас, просто меняют свою форму/ликвидность. На примере: допустим, в платеже 50 тыс. рублей по ипотеке 15 тыс. это проценты, а 35 основная сумма долга - получается, что вы как бы арендуете эту квартиру за 15 тыс, что обычно выгоднее, чем могло бы показаться. Так что имеет смысл покупать, если проценты сравнимы, а не когда весь платеж. На практике из-за аннуитентной схемы платежа сумма процентов меняется о каждом взносе и усложняет расчёт, но он остается верным по сути.
Ну и по остальным примерам есть что сказать. Хорошо на эту тему пишет Бодо Шефер, тем более что его опыт складывался в схожей с нашей экономической ситуацией, с высокой инфляцией и штормами в экономике послевоенной Германии
Вот что мы видим из SLA yandex compute. Чуть раньше на сайте пишут, что фактический уровень доступности - Tier 3.
Из снимка я могу сделать вывод, что написана, мягко говоря, неправда -- номинально ДГУ есть, фактически оказывается, что она неспособна питать ДЦ при отказе лучей питания национальных операторов.
Что значит "тоже"? Я же утверждаю обратное
А если крупному специализированному грузовому автопарку нужно обеспечить безотказный сервис перевозок, то да, могут и небольшой нефтеперегонный комбинат поставить, если другими способами не обеспечить 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 поставить, однако это практически вдвое удорожает ядро системы