1. Элиот Хоровиц - сооснователь и первый CTO MongoDB. В 2007–2009 годах он возглавил разработку ядра базы данных на C++ и спроектировал систему шардинга и репликации, которая позже стала отраслевым стандартом. Над проектом работала целая команда, но именно техническое видение Хоровица определило архитектуру MongoDB. В 2020 году он покинул пост CTO, основал стартап Viam и вернулся к практической разработке. В интервью он не раз подчеркивал: ему ближе писать код и строить системы, чем управлять крупными командами.

2. MongoDB - одна из самых протестированных баз данных с открытым кодом.

В ее репозитории тестового кода больше, чем продакшен-кода ядра. Это не маркетинг: перед каждым релизом внутренняя система Evergreen запускает миллионы автоматических проверок - от юнит-тестов до сценариев имитации падений серверов и сетевых разделений. Именно такая тестовая культура позволяет MongoDB стабильно работать в продакшене у тысяч компаний.

3. В PHP пустой массив

[]

может интерпретироваться и как список, и как объект.

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

очистку всей коллекции

или базы. Это не был баг самого сервера MongoDB, а именно специфика реализации «обертки» для PHP тех лет.

4. Самый большой известный публично кластер MongoDB принадлежит eBay.

В 2019 году они рассказали, что у них работают

более 100 шардов

, хранящих

петабайты данных

, с нагрузкой

миллионы запросов в секунду

.

5. В MongoDB нет JOIN, но есть $lookup,

который делает то же самое, но с другим синтаксисом. Но появился он только в 2015 году в версии 3.2. До этого люди хакерили с помощью $unwind и $group.

До сих пор встречается мнение, что C# и весь Microsoft-стек - только про Windows. Хотя Java, например, тоже долго ассоциировалась с Oracle, а Go - с Google. Сам факт, что язык или платформа связаны с большой компанией, сам по себе мало о чем говорит.

Если 10–15 лет назад C# и правда был сильно завязан на Windows, то сейчас картина давно изменилась.

Раньше все крутилось вокруг .NET Framework, IIS, Windows Server и MSSQL. Почти весь стек жил внутри экосистемы Microsoft, поэтому такая ассоциация была вполне понятной.

Сейчас C#-backend чаще выглядит совсем иначе: ASP.NET Core, Docker, Linux-контейнеры, PostgreSQL, Redis, очереди, CI/CD, облака и прочая привычная инфраструктура, которая есть почти в любой backend-разработке. Поэтому C# уже давно не воспринимается как что-то сугубо виндовое.

Но тут есть нюанс. Если весь опыт связан только с WPF, WinForms, старым .NET Framework, IIS и Windows-легаси, рынок и правда будет уже. Такие вакансии никуда не делись, просто это отдельный сегмент.

Если же человек работает с ASP.NET Core, Web API, EF Core, Docker, тестами, микросервисами, CI/CD, умеет собирать и деплоить сервисы, понимает базы, логи, мониторинг и производительность, то его обычно воспринимают просто как backend-разработчика. Без привязки к ярлыку Microsoft-мира.

Мне вообще не очень близка идея любой ценой убегать от Microsoft. Куда полезнее взять современный .NET и сверху добрать нормальные универсальные навыки, которые нужны почти в любой backend-команде: Docker, базовый Linux, SQL, Redis, очереди, CI/CD, контейнеры, облака, логирование и метрики.

С таким набором C# на рынке чувствуется вполне уверенно.

Я сидел и тупил в монитор. Потом пошел к менеджеру и спросил: "Вы серьезно?!

• Твой личный эксперт, который отвечает на все вопросы, проверяет домашки и не дает закопаться в прокрастинации.

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

🔴 Хранение данных о движении откликов. Сохраняем то, что часто теряется (контакт рекрутера, ссылка на вакансию, что за компания, когда обещали вернуться с фидбеком и прочее).

🔴

Оценка эффективности поиска. Если ты, например, сделал больше 50 откликов, но дальше дело не пошло - от части причина в молчании рынка, но также проблема может быть в твоем резюме. А если тебя активно зовут на HR интервью, но после него отказывают, стоит поработать над самопрезентацией и ответами на софтовые вопросы. И так далее.

1. Обновления резюме и составления стратегии поиска.
2. Общения с уже существующими контактами - спросить о внутренних вакансиях и реферальных программах.
3. Пересмотра старых диалогов с рекрутерами.
4. Поиска прямых контактов HR в Сетке.

int day = Convert.ToInt16(DateTime.Now.ToString("dd"));
switch(day)
{
    case 1:  num = "st"; break;
    case 21: num = "st"; break;
    case 31: num = "st"; break;
    case 2:  num = "nd"; break;
    case 22: num = "nd"; break;
    case 3:  num = "rd"; break;
    case 33: num = "rd"; break;
    default: num = "th"; break;
}

Вот представь, пишешь свитчи на кучу кейсов, через месяц добавляешь новый кейс, а где-то в другом файле про него забываешь. А потом баг ловят пользователи. Или не надо представлять и уже знакомо?

ts-pattern дает записать всю эту логику одним красивым выражением, а TypeScript сам напомнить про твою криворукость, если ты не обработал какой-то вариант. Особенно кайфово с дискриминированными юнионами по типу статусов заказа или типов событий.

Знаешь, как Object.assign и спред работают с вложенными объектами? Никак. Если у тебя есть { ui: { theme: 'dark', size: 14 } }, а кто-то из коллег накосячил и прилетает { ui: { theme: 'light' } }, то после слияния твой size просто испарится, потому что весь ui заменится целиком.

defu сливает рекурсивно по всем уровням, как ты бы и сам хотел. Незаменимая штука, если пишешь библиотеку, SDK или любой инструмент с настройками.

Запускал с помощью ноды git, ffmpeg или любой shell-скрипт? Тогда знаешь, что нативный дочерний процесс – это боль, страдания и колбэки из 2010 года. execa оборачивает все в нормальный async/await, по-человечески ловит ошибки и даёт удобные пайпы между процессами.

Используется внутри кучи популярных CLI-тулзов. Следоватлельно, это говорит о многом.

Готовая коллекция TypeScript-типов на любой случай жизни. Нужен Partial по всем вложенным уровням? Есть. Сделать массив непустым? Есть. Преобразовать snake_case в camelCase прямо на уровне типов? Тоже.

Короче, прежде чем в десятый раз писать свой DeepPartial, загляни сюда. Скорее всего его уже написал автор либы за тебя.

Нужна шина событий внутри приложения, где один модуль кинул, другой подписался? Тащить ради этого Redux или нативный EventEmitter из ноды – это как везти хлеб на дачу грузовиком. emittery решает задачу с минимумом кода и при этом умеет полезные штуки.
Например, типизирует события через TypeScript и нормально работает с async-обработчиками, чего стандартный EventEmitter не умеет в принципе. От того же автора, что и type-fest, кстати.

Его метод изучения:
— учебники + произношение;
— детские книжки → подростковые;
— письма на новом языке;
— и главное: не говорить, пока не освоишь все нужные конструкции. Никакого «моя твоя понимать»!

Любимое приложение - GNU Emacs. Там он читает почту, редактирует сайт и проводит максимум времени. Консоль - в приоритете, но GUI не демонизирует.

А вот Clojure и Python, которые ему называли «похожими на Lisp», не зашли. Фундаментальной схожести нет, считает RMS.

«Уродливый язык» - и тут Столлмана поддерживает сам Линус Торвальдс (редкий момент единства).

Писал на Java, и даже понравилось. C знает отлично. А вот новые языки после нулевых прошли мимо - перестал активно программировать, ушел в общественную миссию.

Технические характеристики - не главное. Главное - чистота лицензий.

Музыка народная, слова свои. О будущем, где свободное ПО победило «грязные» лицензии.

Исполнил песню при тусовке. Кто-то крикнул: «Классно, спой это Ричарду Столлману!»
— Так я и есть Ричард Столлман

😄

Рассказ-антиутопия о мире, где чтение книг - преступление. Написан как учебник истории будущего. Обязательно найдите и прочитайте.

С 2000-х почти не пишет код. Но его идеи, лицензии и принципы работают до сих пор.