Привет, Хабр!

Сегодня поговорим про одну из тех тем, что вроде бы тривиальна, но до последней капли грязи тащит за собой внушительный пласт вопросов. Речь пойдёт про COUNT(*) и COUNT(col) в PostgreSQL.

Четыре сгоревших STM32, три блока питания, 90 ампер, синяя сосиска, 16 бубенчиков и электродиффузия — в этой части кормим подсветку для трёх теликов, пишем с нуля протокол адресных светодиодных лент WS2812b и обматываемся коаксиальными проводами.

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

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

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

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

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

Привет! Меня зовут Артем Валевич, последние три года я тимлид в AGIMA. За это время я составил для себя что-то вроде тимлидского кодекса — список небольших правил и принципов, которые помогают мне в работе. Правила эти я вывел разными способами: что-то установил опытным путем, что-то подсказали старшие коллеги, что-то вычитал в статьях и книгах.

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

В этой статье попробуем разобраться, почему ООП — худшее, что было придумано в программировании, как оно стало таким популярным, почему опытные программисты Java (C#, C++ и т.п.) в принципе не могут считаться крутыми инженерами, а код на Java - хорошим.

Недавно тут была опубликована пятничная статья о математике. Автор правильно сделал, что не поставил у неё тег «математика» потому что она не про математику. Хотелось бы исправить этот недостаток, написав дополняющую статью о программировании без тега «программирование».

Всем привет! Это Миша Степнов, руководитель центра R&D Big Data в МТС Диджитал.

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

Чтобы модели не «предвзято учились» и не «выдавали мусор», нужно обеспечивать непрерывные R&D-процессы по управлению данными: от сбора и очистки до хранения и быстрых итераций над ними. И тут возникает важное понятие AI Ready Data: все, что касается доступности данных, их формата и актуальности, должно быть продумано заранее и поддерживаться на высоком уровне качества.

Умение грамотно управлять данными — это уже не «хороший тон», а конкурентное преимущество.  Но как прокачивать навыки работы с ними? Один из способов — читать правильную литературу. Так что в этом посте поделюсь списком книг о базовых принципах реляционных баз данных и SQL, продвинутых инструментах и языках программирования и многом другом. Забирайте в закладки, а при желании дополняйте подборку в комментариях.

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

Привет всем! Это Саша Пиманов, разработчик из МТС Диджитал. Сегодня хочу напомнить, что разработка — это не только Python, JavaScript, C++ или Java, и поговорить о не самых распространенных языках программирования. Некоторые из них предназначены для специфических задач, другие можно назвать улучшенной версией популярных языков программирования, а третьи созданы just for fun. Так что если вы как раз хотите изучить что-нибудь новое, забирайте пост в закладки. Поехали!

Как же иногда хочется закинуть коммиты «Remove debug log», «fix» или «fix fix fix». Такие коммиты как грязные носки под кроватью: их не видно, пока не придёт ревьюер с пристальным взглядом или, что еще хуже, потенциальный работодатель, решивший посмотреть на ваш профиль github.

К счастью, Git предлагает два супер-инструмента для того, чтобы история коммитов выглядела так, будто ты всегда знаешь, что делаешь: git commit --fixup и git rebase --autosquash. И сегодня мы разберем на практике как это применять.

– На них сейчас попёр спрос: на сайте их нельзя купить, товара нет в наличии. Может, будем им рекламу делать?

А я понимаю, что им нужна не реклама, а товар — спрос вырос раз в сто, сгребали всё.

То, что раньше стоило 4 000 ₽, сейчас стоит 20 000 ₽. При этом у производителей — пусто. Надо было что-то с этим делать.

Давайте будем честными.

Простые промпты наподобие "Напиши статью из 1500 слов под заголовком: Топ-10 продуктов, которые разрушают вашу печень» не дадут вам и 1% тех результатов, которые способен дать Chat GPT.

Последние два года я почти не пишу код. Наверное, только 10% кода в моих личных и коммерческих проектах написано мной, все остальное генерируют нейронки. За это время у меня выработался определенный подход к созданию проектов и появились инструменты, которые я для этого использую. Этим я и хочу поделиться с вами под катом.

Друзья! Многие из вас, возможно, как и я, интересовались изучением и использованием в работе очень эффективного и востребованного языка программирования Rust но, как и я, оставляли свои попытки из-за сложности, запутанности и многослойности доступного материала и книг по этой теме.

Лично я делал не меньше 5 попыток на протяжении последних 10 лет, прорабатывая, большей частью в свободное и личное время, литературу, некоторые книги по несколько раз, в поисках ответов на простые человеческие вопросы - как свободно писать на Rust и решать, как орешки, ежедневные задачи, не страдая от головной боли и хорошо понимая, что происходит и почему простая программа не компилируется.

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