"Причиной сбоя в доменной зоне .RU стала некорректная работа программного обеспечения (ПО), который реализует механизм подписи файла с данными зоны .RU в глобальную систему DNS-серверов. Об этом в интервью ТАСС сообщил директор Координационного центра доменов .RU/.РФ Андрей Воробьев."

Да, но самое главное-то не пояснили: что (или кто:) стало причиной некорректной работы ПО, который реализует механизм подписи файла с данными зоны .RU в глобальную систему DNS-серверов??

(правильно: которое (ПО — оно); я знаю русский язык лучше журналистов ТАСС :) много работал с литературными редакторами советской школы, которые вычитывали материалы перед публикацией, особенно в СМИ уровня ТАСС, но сейчас эта культура полностью утеряна)

Работало-работало это ПО корректно, а потом внезапно стало работать некорректно? Космические лучи битик инвертировали?

Ну, раз "власти скрывают", значит 127% накосячил какой-то свой сотрудник :)

Будем надеяться, что из него не сделают стрелочника, т.к. ответственность всегда на менеджерах, не сумевших правильно организовать рабочие процессы.

"Employees Who Stay In Companies Longer Than Two Years Get Paid 50% Less"

Эта истина 10-летней давности с годами всё истинней, как коньяк :)

Чем дальше, тем недоплата ещё больше получается.

Со временем вы замечаете, что на вашу должность набирают новых разработчиков с зарплатой, существенно превышающей вашу (при том, что им месяцами потребуется въезжать в проект:), и никакие переговоры с начальниками тут не помогут, ну добавят +15% в год. Единственный выход -- смена работы с ростом зп 50%-100%.

P.S. Вроде Forbes солидное издание, но выглядит как студенческий помоечный сайт: вылазит куча рекламных окон, включая и видео, закрывают на паузе почти весь экран, фу.

"Несмотря на то, что функциональные программисты часто говорят об иммутабельности, изменяемое состояние -- это фундаментальная часть программирования, от которой нельзя и не нужно отказываться...
Полная приверженность иммутабельности -- это приверженность тому, чтобы никогда не создавать ничего реального." 😂😂😂
-- Ярон Мински, автор великолепной книги "Функциональное программирование на языке OCaml", возглавляющий крупнейший в мире проект, где функциональный язык OCaml используется в промышленном масштабе (в .NET OCaml -- это неформально F#).

Для курсантов на треке переговоров о зарплате выложил 46-й материал
"Если вам предложили слишком низкую зарплату".

Назовём Олегом курсанта, который претендовал на сеньора в хорошо известной компании -- назовём её МОСЯ. Олег очень хорошо прошёл собеседования по рекомендациям этого трека, и ожидал сильного предложения от МОСЯ.

И вот пришёл оффер: "Мы хотели бы сделать вам предложение о работе..."
Отличная новость!

Но зарплата и бонусы, которые они предложили, вызвали недоумение :)

Как, и это всё? Это и есть предложение о работе? Мы надеялись на гораздо большее.

Предложение было существенно ниже минимально приемлемой зарплаты, которую Олег установил перед тем, как проходить собеседования.

В МОСЯ объяснили, что испытывают финансовые проблемы, но стремятся к быстрому росту, поэтому не могут платить высокую базовую зарплату. Они обещали наверстать упущенное за счет всевозможных бонусов и премий, однако и они оказались не слишком впечатляющими.

Олег оказался обманут. Бывает же такое!

Но мы не паниковали, потому что у нас был план Б :)

...

...Кстати иногда ребята ошибочно делают так, что "я им просто сразу сказал 300 чтобы отфильтровать", но, во-первых, на ваши 300 могут сразу согласиться (что означает, что вам хотели дать больше), и вам придётся соглашаться на 300, т.к. вы это сами озвучили, и во-вторых, вам, возможно, готовы были дать 270, и вполне можно было дожать до 300+, а вы сразу отвергли такую возможность.

Поэтому, абсолютная аксиома в моей Школе: никогда не говорить зарплату (текущую или ожидаемую) первым.

Да, знаю что многие критикуют этот подход, заявляя, что говорить свою зп это норм главное делать это правильно бла бла бла, но на самом деле это всё проплаченые агенты с другой стороны баррикад :)
морочат вам голову, а сами только и мечтают, как бы в итоге дать вам как можно меньше денежек.

Помните всегда: вы не ребёнок проситель и не родитель податель благ.
И вы, и они -- равноправные взрослые (а если они скатываются в одну из этих ролей по транзакционному анализу Берна, тогда вы всегда будете в хорошем выигрыше, если последуете моим рекомендациям :).

Но как только вы станете думать "мы будем делать вместе с ними хороший проект, который принесёт пользу людям, и главное это, а не моя зарплата" ("эффективный альтруизм" и прочий детский сад), вы уже проиграли, потому что мы живем в гос-капиталистическом обществе, где любые проекты приносят пользу (и доход) прежде всего своим организаторам, которые, эксплуатируя ваш наёмный труд, покупают себе очередной Инфинити и пять новеньких любовниц, вешая вам на уши лапшу про "полезненькое".

Вы свою семью обеспечили на пару поколений вперёд?

Ну и конечно ничто (кроме вашего страха) не мешает и вам стать одним из таких организаторов. Но только стоит ли?

Как стать миллиардером?

Трансформеры -- это просто очередной универсальный аппроксиматор. Они стали так популярны фактически лишь потому, что эффективно обучаемы, в частности, на GPU, и хорошо распараллеливаются (т.к. не требуют обработки последовательностей по порядку); именно этот технический момент делает трансформер на сегодня лучше любого другого универсального аппроксиматора; всё остальное вторично.

И вот если вы придумаете (или откопаете в океане научных статей и реализуете) некий алгоритм, который будет работать более эффективно, чем трансформеры на GPU (например, какой-нибудь обобщённый механизм свёртки с алгеброй Хопфа) , можете смело запускать свой OpenAI.

Вообще, увлекательная темка, сам хочу подумать и поэкспериментировать.

Только я вчера написал про (долларовое) миллиардерство в AI, как Сэм Альтман меня поправила: по её мнению, речь идёт уже о триллионах!
"Кто готов вложиться в будущее ИИ? Минимальный чек: $100 млрд"

Соответственно, тут будет множество ниш, где можно получить свои скромные $миллионы. Ну например, дообучить модельку так, чтобы она стала реальным профи в конкретном фреймворке (джанга, спринг, asp net, 1c :) битрикс :) ...), чтобы в тестах выдавала значимые отличия по уровню понимания.

Не забывая, что в России 98% недружественных сервисов недоступно, что даёт особую свободу и перспективу "национализированным" проектам.

Действительно, зачем вам изучать такие технологии, как например kvstore (a simple Key-Value Store based on B+Tree (disk & memory) for Java, там и все бенчи есть), которое можно обобщить до любых деревьев (radix/adaptive, red-black, hashmap, ...) и офигенной эффективности, когда можно за 9 месяцев с нуля схантиться на 300k/sec.

Почти в каждом инструменте, который вы активно используете, есть какая-то скрытая глубина, будь то язык программирования или git, фреймворк или библиотека. Вам не обязательно становиться экспертом в каждом из них, но попробуйте какое-то время тратить ежедневно 10-15 минут на то, чтобы узнать немного больше о том, что он может делать -- и через короткое время удивитесь росту вашей продуктивности.

sudo for windows )))
я сперва думал, это стёб

тогда уж поизучайте заодно и dev tunnels .net
(a game changer for mobile developers)

hono -- очередной киллер реакта например :)

Хотел начать рассказывать, какая вторая волна новых драконовских дополнений к правилам занятий на моих курсах появится с 18 марта, но в пятницу не буду, начну с понедельника.

Практически на любом собеседовании по system design обычно спрашивают про многослойную архитектуру (clean architecture, DDD, гексагональная, луковая, CQRS, ...), наверняка и учат этой темке в каждом университете.

В теории тут возможны бесконечные обсуждения, но сермяга в том, что все эти слои красиво работают ровно в той степени, в которой они тривиальны (на уровне студенческой курсовой). Но на самом-то деле они нужны нам только тогда, когда они нетривиальны! Но когда начинается производственный хардкор, возникают качественно иные проблемы, и вы с этими теоретическими моделями моментально запутываетесь.

Потому что вам нужно сперва достичь мастерства в этой конкретной методике, в том же DDD, причём вложить годы, чтобы научиться что-то тут делать более-менее правильно, по взрослому, набив попутно кучу шишек.

Я ровно поэтому топлю не за инженерные подходы, пусть и неплохо проверенные практикой, а за те, которые основываются на математике и computer science.

Курсантам напомню материал из СильныхИдей "Формализуем многослойную архитектуру", где я даю простую формальную модель слоистой архитектуры, которая может масштабироваться до огромных размеров.

Внезапно :)
Пацаны как бы давно пилят "российскую ОС" (на базе debian), и вдруг такое.
Взялись теперь за клон windows? или моно "русифицируют"?

В СильныеИдеи добавил 85-й материал "Три типа программных ошибок".

Любая система может сломаться: пользователь введёт неверные сведения, данные в базе окажутся некорректными, откажет сеть или интернет, проявятся обычные баги, в параллельных процессах возникнет клинч или гонка, космические лучи инвертируют бит, и т.д. Как правильно рассуждать в таких случаях?

Вы пишете код, который обращается к базе данных, считывает из неё информацию, и что-то с ней делает. Если ваша система зависит от базы данных, то предсказуемой ошибкой будет недоступность базы данных. Но сможете ли вы справиться с такой ситуацией?

Это классическая зависимость, которые мы разбирали в отдельных материалах.

Возникнет сбой сети, сисадмин неправильно настроит строку подключения, переполнятся журналы, откажет физический сервер, пройдёт DDOS-атака и т.д.

Вы можете повторить операцию несколько раз, зафиксировать проблему в логах или уведомить кого-то ответственного. Но в любом случае система зависит от базы данных. Если база данных недоступна, система не сможет работать. Вы не можете справиться с этой проблемой.

Или можете?

Помните, я говорил 31 декабря:
"Эта девушка занимается на моих курсах, и в Новый Год её волнует только один вопрос: как гарантировать холодный старт системы, в которой кэша нету принципиально, за 100 мс?"

Стартап Superhuman (Сверхчеловеческая электронная почта), привлекший $100 млн., предлагает элементарную (!) услугу обычной электронной почты, которая просто "работает по "правилу 100 миллисекунд". Каждое действие - загрузка письма, отправка или обработка поискового запроса и прочее - должно совершаться максимум за 100 мс. Это порог, при котором человек воспринимает действие мгновенным."

Схема такая: берёте любой популярный (лучше нишевый) сервис, и просто пилите его суперскоростной клон по "правилу 100 миллисекунд".

Профит!

А если 16 лет опыта, уже нельзя? overengineering?

Вот интересно, хочут фуллстек с крепким фронтендом, да ещё и ability to work under pressure, а сколько деняк, принципиально не пишут, и будут у вас выпытывать чтобы вы первым сказали свою/желаемую зп. Как думаете, почему?

Наши враги эйчары/кадровики сегодня хорошо автоматизированы, но в конечном (да и в промежуточном) итоге всё равно их побьём, потому что мы, как социальные хакеры, были, есть и будем на несколько шагов впереди (в частности, на курсе карьеры и переговоров по зарплате под две сотни материалов, и постоянно расширяю).