Бэкенд

Где бесплатно учиться веб-разработке?

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

Хорошая новость: получить полезные навыки можно без рисков и вложений. На Хабр Карьере есть множество бесплатных и полезных курсов.

Присмотритесь к веб-разработке:

— Frontend-разработка. HTML, CSS, JavaScript.

— Backend-разработка. Python, Node.js, SQL

— Fullstack-разработка. JavaScript, React, Node.js

→ Иногда лучший старт — просто начать из любопытства.

Что нужно знать про Unicode.

Большая часть сложностей с кодировками ушла в прошлое. Сейчас у нас есть Unicode. Он признаётся как универсальный стандарт всеми современными ОС.

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

Проблема только в том, что Unicode имеет несколько актуальных видов, которыми он может быть закодирован. И всё же, жизнь стала значительно проще.

Тематику Unicode затронул Джоэл Спольски ещё в далёком 2003 году, но она актуальна и на сегодняшний день.

Его статью можно часто встретить как стартовую рекомендацию, когда речь заходит о Unicode. И к этой рекомендации я могу только присоединиться.

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

Статья на сайте Джоэла Спольски: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

Райан Даль, создатель Node.js, одной из ключевых технологий современного веба: времена, когда код писали люди, всё.

Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».

Не пользуюсь LLM-агентами, если могу. Давно замечаю: просто избегаю запускать LLM прямо в проекте, потому что боюсь разучиться кодить и думать. Поход в ChatGPT себе разрешаю — это как встать с дивана, чтобы пойти в магазин, а не заказывать доставку на дом. Там нужно правильно сформулировать запрос, потому что он не может добрать контекст проекта сам. Можно перекинуться парой мыслей, как с товарищем на работе. Надо подумать, как применить ответ, что выкинуть. В итоге я всё равно как-то худо-бедно программирую сам.

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

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

В ответ на это индустрия на венчурные деньги придумывает и продвигает свои «велосипеды», чтобы с помощью агентов эффективнее и дешевле решать задачи:

• В Cursor IDE есть Rules, которые накладывают ограничения поверх ваших промптов. Их можно применять вручную или автоматически; говорят, автомат работает хуже.

• Anthropic пиарит Skills (еще пример Playwright Skill). Это интерфейс для решения типовых задач с адаптивными ступенями контекста в зависимости от сложности.

• Есть MCP (Model Context Protocol) — условное API, которое расширяет возможности агентов, чтобы они не писали собственные инструменты и не тратили контекст и токены на типовые задачи: открыть браузер, прочитать Jira, отправить письмо и т. д.

• Также есть субагенты; их оркестрирует агент-оркестратор. У субагентов чистый контекст: они получают задачу, выполняют её и идут на «свалку».

И вот среди этого новояза я – старпер со своим ChatGPT: после 2–3 запросов удаляю чат и начинаю новый. Вот моя экономика токенов и галлюцинаций. Меня и Альтмана маркетингом не проведешь!

Что общего между счетами за коммуналку и облачными сервисами?

Самый большой страх перед облаками — это «открытый кран», который за месяц сольет весь бюджет компании. Но есть и хорошая новость: чтобы не разориться, не нужно творить чудеса. Достаточно навести порядок в своей «цифровой квартире» и приучить команду к осознанному управлению ресурсами. Применяем логику рачительного домовладельца к облачной архитектуре и смотрим, где можно сэкономить без потери в производительности.

1. Вынесите счетчик из подвала

Трудно экономить воду, если счетчик спрятан в темном углу за слоем пыли или вообще, запрятан внутри самого поставщика. В ИТ всё так же: команды не начнут оптимизировать код, пока не увидят, сколько стоит их «пробег». Поэтому начните с активации расширенных панелей мониторинга (Billing Dashboards). Расходы должны быть на виду у тех, кто их генерирует, а не только у бухгалтерии в конце месяца.

2. Распределите ответственность

У каждой «лампочки» должен быть хозяин. Назначьте ответственных за каждый ресурс, сервис, базу данных или инстанс, но не для галочки, а специалиста, который понимает, как работает этот ресурс и сколько он стоит. Да, на старте это потребует времени (и, возможно, обучения сотрудников), но в итоге вы получаете прозрачность. Золотое правило: если ресурс нельзя идентифицировать — он не должен существовать. Только так можно понять, кто «льет воду», а кто экономит.

3. Проводите регулярную поверку

Этот пункт напрямую вытекает из предыдущего. Поверка — это не просто аудит «для бухгалтерии», а профессиональный осмотр. Маленькая капля за месяц превращается в кубометры, а забытый «тестовый» сервер — в десятки и сотни тысяч рублей. Проводите ежемесячный аудит: удаляйте брошенные инстансы и делайте оптимизацию мощностей (меняйте размер слишком мощных машин на те, что реально нужны). Сохраняйте историю, чтобы видеть динамику ваших «протечек».

4. «Умный дом» для бюджета

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

5. Энергоэффективность на этапе чертежа

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

Переезд в облако не избавляет от ответственности за инфраструктуру, он просто меняет фокус, с обслуживания «железа» на оптимизацию процессов. Ни один облачный провайдер не придет к вам, чтобы выключить за вами свет. Это ваша «цифровая квартира», и уют (как и бюджет) в ней зависит только от вас.

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

Я же опять стал студентом. Спустя 20 лет. На этот раз учусь в ВШЭ. И поймал себя на странном ощущении, что правила игры теперь совсем другие.

Двадцать лет назад учеба в университете была похожа на жонглирование (а еще и покуралесить с однокурсниками надо было успеть). Стандартная лекция: слушаешь лектора, пытаешься понять и одновременно лихорадочно конспектируешь. Мысль теряется, пока записываешь. Запись теряет смысл, пока ловишь мысль. Были, конечно, уникумы, которые умудрялись успевать записывать и делать качественные конспекты. Такие конспекты ходили по рукам, переписывались и были на вес золота. Тогда это была норма, так все учились. 

Вернувшись в аудиторию на Executive Master in Management, я поначалу действовал по старинке. Слушаю, записываю. Перечитываю иногда. Но что-то было не так…
Хорошо, что довольно быстро понял: я застрял в 2005-м, а мир ушел далеко вперед.

Сегодня у меня совершенно другой алгоритм.
На лекции я просто слушаю, задаю вопросы, связываю новое с опытом. На все 100% сфокусирован на понимании и осознании материала.
А все остальное делают технологии:

• Структура и ключевые тезисы от преподавателя,

• Аудиозапись лекции на телефон

• Транскрибация в mymeet 

• Claude, который превращает полтора часа живой речи в аккуратный 20-страничный конспект,

• Алиса Про (бывший Яндекс Нейроэксперт) сшивает все конспекты в единую базу знаний, с которой легко взаимодействовать.

Рутина практически исчезла. Я переоткрыл для себя обучение. Появилась необычайная легкость и еще большее желание учиться.

Я смотрю на сегодняшних студентов и немного завидую. Белой завистью.
Им не нужно тратить внимание на «успеть записать».
Они могут сразу строить ментальные модели, учиться быстрее и глубже. Кто-то может возразить, мол, так и писать можно разучиться. Но это отдельная тема для обсуждения.

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

А вы уже пересобрали свой способ учиться или все еще учитесь так, как будто ИИ не существует?

Тестовый фреймворк для Си.

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

На практике это не всегда так.

Да, мир Си — дикий запад. Но, тем лучше, всегда есть выбор.

Джон Брюер приводит превосходный пример того, каким может быть минималистичный фреймворк для тестирования. Всего пара макро и одна переменная, восхитительно!

Статья на сайте Джона Брюера: https://jera.com/techinfo/jtns/jtn002

AI не заменяет - AI меняет роль

Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?

55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).

Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).

Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.

Что отдал AI

Почти всю черновую аналитику:

• Spec drafts - первые версии спецификаций по сырым требованиям

• C4 диаграммы - контейнеры, компоненты, контекст

• Sequence diagrams - потоки взаимодействия

• Поисковые запросы - сбор контекста из документации и кодовой базы

• Тест-кейсы - acceptance criteria по спецификации

Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.

Звучит как будто всё отдал. Но нет.

Что не отдам

Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.

То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.

В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.

Про "парадокс продуктивности"

Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".

Не согласен с интерпретацией METR.

Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.

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

Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.

Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".

Джуниоры: как меняется обучение

CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"

Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.

Но джуниор теперь не "пишет CRUD". Джуниор учится:

• Формулировать требования так, чтобы агент понял

• Писать тест-контракты до реализации

• Дебажить и верифицировать результат

• Понимать, когда AI галлюцинирует

Сдвиг роли

Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.

Раньше - исполнитель. Теперь - проектировщик и валидатор.

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

Что стало важнее

Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.

И новый навык: строить свою систему работы с AI.

Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.

Про The Clean Architecture.

Конечно, говоря про Clean Architecture, нельзя обойти стороной книгу Роберта Мартина “Чистая Архитектура”.

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

Но не менее полезной можно считать дистиллированную версию в блоге Clean Coder. Автор заметки — тот же Роберт Мартин. Если Вы не знакомы с Clean Architecture, то статья станет хорошей отправной точкой.

Статья в блоге Clean Coder: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Про воркеры простыми словами

На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал.

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

Пример
Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.

Зачем
Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.

Коллбэк
Коллбэком воркера может быть любая нужная функция: отправить имейл, прочитать содержимое, залить файл во временное хранилище и т. д.

Триггеры
Триггерами для воркера могут быть:

• крон

• таймер

• событие

Очереди
Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.

Воркер-пул
Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.

Накладные расходы
Чем сложнее слой с воркером, тем больше необходимость следить за их хелсчеками. В отличие от вашего сервиса, воркер может тихо упасть. Ваш сервис отдаёт 200, а по факту задачи не отрабатывают. Так что воркеры накладывают дополнительные накладные расходы: связанность, обработка ошибок, логирование, алерты, ретраи, рестарты подов и т. д.

Образ
Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:

def main():

    ... # Какая-то логика по инициализации воркера и очереди

if name == '__main__': 

    main() # Если запускают этот модуль напрямую, выполни команду main()

Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.

🎣 14 собесов за неделю благодаря КАРАСЮ — и да, вам не показалось)

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

Сразу скажу, про карася расскажу ниже, сначала немного контекста)
Недавно я писал о том, как мы с командой пытаемся решить инженерную задачу под названием «поиск работы». Проблема знакома многим: квалифицированные специалисты тратят сотни часов на рутину — пролистывание лент, однотипные отклики, формальные сопроводительные. Цикл повторяется с каждым новым поиском.

Тогда мы решили посмотреть на это как на систему: входные данные (резюме), правила сопоставления (вакансии), повторяемые действия (отклики) — и автоматизировать то, что не требует креатива. Так родился OfferMate 1.0.

🚀 Что получилось в первой версии

Мы создали ассистента, который:

• 🔎 Искал вакансии на hh.ru и в Telegram-каналах.

• 🤖 Автоматизировал отклики через официальное API.

• ✍️ Генерировал сопроводительные письма, анализируя резюме и требования вакансии.

• ⚙️ Работал в фоне, экономя пользователям до 10-15 часов в неделю.

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

🎯 Эксперимент «Карась» и неожиданный результат

Чтобы протестировать систему на реальной нагрузке, мы запустили в блоге условный «челлендж»: попросили желающих оставить в комментариях слово «КАРАСЬ». Это был сигнал для подключения к бета-тесту.

Результаты нас ошеломили. Один из «карасей» поделился статистикой: за 5 рабочих дней — 18 откликов от HR, 9 скринингов и 5 технических собеседований. И при этом это был не единичный случай! Мы получили несколько подобных фидбеков и увидели, что система реально работает и приносит результаты. А также получили огромный заряд мотивации. 💥

⚡️ Переворотный момент

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

🏗️ OfferMate 2.0: фундамент на годы вперёд

И пока все наслаждались новогодними праздниками, наша команда копалась в деталях. Мы не стали наращивать «костыли» на старую архитектуру, а начали строить новый фундамент.

🔥 Наше ключевое изменение:
Мы реализовали механизм, который работает напрямую через пользователя, полностью имитируя человеческие действия в браузере. Это безопасно и снимает внешние ограничения, давая беспрецедентную стабильность.

Грубо говоря, мы учим систему «работать руками» пользователя)

✨ Что в итоге мы реализовали в 2.0?

• 🛡️ Абсолютная стабильность. Больше никаких внезапных остановок из-за изменений на стороне площадок.

• ⚙️ Полная автоматизация рутины. Система может автономно управлять всем циклом: поиск → подъём резюме → отклик → отслеживание статусов.

• 🎭 Глубокая оптимизация сопроводительных писем под культуру конкретной компании.

• 🧠 Автоматизация прохождения типовых онлайн-тестов (New)

• 📊 Централизованные уведомления со статистикой (New)

⏱️ Когда запуск и как попасть в 2.0

Сейчас мы на стадии закрытого бета-тестирования и готовимся к релизу нашего продукта.

Самый сложный технологический этап пройден. Сейчас мы интегрируем новую логику в бота и проводим стресс-тесты под нестандартными сценариями.

Хотим всё хорошо оттестировать и ворваться в новый сезон найма, чтобы разрывать его вместе с вами! 💥

Публичный запуск планируем в конце января. 🗓️🎄

❗️Чтобы обеспечить качество, мы откроем только 100 слотов на 3 дня. 

Это осознанное решение для контроля нагрузки и получения концентрированной обратной связи.

Мы хотим, чтобы OfferMate 2.0 вышел не «сырым анонсом», а готовым инструментом, которому можно доверить карьерный маневр.

🤝 Как поучаствовать

Присоединиться к запуску и поучаствовать в тестировании — можно будет в нашем Telegram-канале: https://t.me/offermatecrew
Мы приглашаем сообщество Хабр помочь нам в разработке лучшего ИИ-ассистента для поиска работы!

P.S. В комментариях готов подискутировать на тему пользы автоматизированных откликов и ответить на технические вопросы 👇

Я подумал, что было бы интересно сделать дотошное исследование кода, который обеспечивает функционирование исключений в С++, и написать статью об этом. Разные платформы могут реализовывать исключения по-разному, поэтому показалось логичным сконцентрироваться на мире Linux.

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

Всё рассмотрение строится на конкретном примере. Где возможно, опираюсь на библиотеку libcxx от LLVM, а в остальных случаях — на libstdc++ от GCC.

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

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

С некоторым опозданием предлагаем вам почитать обзор на переведённую нами книгу Диего Пачеко и Сэма Сгро "Принципы модернизации программных архитектур". Обзор сделали в своём корпблоге специалисты дружественной нам компании SSP-Soft. Книга появилась в продаже в начале декабря, пока только бумажная версия.

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

Приятного чтения!

Записи с backend-митапа, который мы вместе с комьюнити «Live PHP» и «Пых» провели в конце прошлого года офисе Garage Eight

> NULL. Выбросить нельзя использовать
Спикер: Владимир Романичев, CEO «Ветменеджер»
Youtube | VK видео

> RabbitMQ: quorum queues и почему mirrored queues не работают
Спикер: Виктор Михайлов, Backend Lead Garage Eight
Youtube | VK видео

> Архитектура ИИ-сервиса для распознавания документов: путь от MVP до продакшена
Спикер: Михаил Мироненко, Senior PHP Developer, 10+ лет в разработке
Youtube | VK видео

Узнавайте о новых митапах из канала нашей команды ;-))

Статьи по DDD.

Уди Дахан — один из первопроходцев DDD в C#.

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

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

Статьи на сайте Дахана:

• How to create fully encapsulated Domain Models

• Domain Events – Take 2

• Domain Events – Salvation

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

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

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

Начнем с избыточности. Одно дело когда у вас команда из 50 человек, где есть и фронты и бекендеры и девопсы и бог знает кто еще. Другое, когда вся команда это три человека с очень разными компетенциями. Если в команде один бекендер, то его никем не заменить. Тоже самое касается и большинства остальных ролей. Всегда нужен человек, который отвечает за свой блок и разбирается в нем лучше всех (или в принципе только он и разбирается). Такому человеку ИИ конечно помогает, но убрать его с помощью ИИ невозможно, как бы красиво это не звучало и не выглядело (посмотрите как я сгенерил лендинг с помощью ии!).

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

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

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

Больше про разработку в моем телеграм-канале Организованное программирование

Про Null References.

Популярные современные ЯП позволяют переменным-ссылкам иметь значение NULL. И это уже привело к огромным проблемам, рассказывает Тони Хоар на выступлении.

Борьба с NULL принимает разные виды.

Дизайн каких-то ЯП оставляет это на откуп линтерам, не обременяя себя вопросами времени компиляции и исполнения.

Другие ЯП разрешают хранить NULL только в переменных, которые имеют знак вопроса после типа. Пример: Object? a = null. Нет знака вопроса — переменная не может быть NULL.

Отдельные ЯП имеют монаду Maybe или Optional в стандартной системе типов. Так они кардинально избавляются от самого концепта NULL.

Так или иначе, определённо ясно, что NULL — исключительно техническая необходимость прошлого. А в моделировании предметной области использовать NULL просто не получится.

Презентация на сайте InfoQ: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

Пока все отдыхали на праздниках и доедали оливье, эксперт-«скалист» из компании «Криптонит» уже вовсю работал над базой знаний по Scala!

5 января Артём Корсаков, руководитель группы Scala-разработчиков в «Криптоните», опубликовал в своём проекте Scalabook обновления, над которыми он работал больше двух месяцев.

Делимся!

• Создание нового проекта на Scala 3

• Основные типы задач

• Статусы и типы задач

• Локализация

• Работа с базой данных (CRUD операции)

• Генерация SQL через макросы

• Реализация CRUD операций

• Интеграционное тестирование с базой данных

Отправляйте этот пост коллегами, которые пишут на Scala!

Scalabook — это уникальная русскоязычная база знаний по Scala. На сайте представлены материалы о функциональном программировании, алгоритмах и структурах данных, классах типов, переводы статей. Также у проекта есть телеграм-канал с новостями — @scalabook. Подписывайтесь!

Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?

Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:

template <typename T>
struct NumericParameter : public Parameter {
  using ValueType = T;
  ....
  std::string name() const override {
    if constexpr (std::is_same_v<ValueType, int16_t>) {
      return "int16";
    } else if constexpr (std::is_same_v<ValueType, uint16_t>) {
      return "uint16";
    } else if constexpr (std::is_same_v<ValueType, int32_t>) {
      return "int32";
    } else if constexpr (std::is_same_v<ValueType, uint32_t>) {
      return "uint32";
    } else if constexpr (std::is_same_v<ValueType, int64_t>) {
      return "int64";
    } else if constexpr (std::is_same_v<ValueType, uint64_t>) {
      return "uint64";
    } else if constexpr (std::is_same_v<ValueType, size_t>) {
      return "size";
    } else if constexpr (std::is_same_v<ValueType, double>) {
      return "double";
    } else {
      static_assert("unsupported ValueType");
    }
  }
  ....
};

Признаюсь честно, я два раза прочитал этот фрагмент, но так и не увидел ошибку. И засчитал себе поражение. Раз так, думаю, это достойно публикации в канал, чтобы и вы могли испытать свою внимательность :)

Ответ:

Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222

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

Но есть нюанс!

Ещё раз посмотрите на эту строчку:

static_assert("unsupported ValueType");

static_assert используется неправильно: пропущен bool-constexpr. Вернее, строковый литерал неявно конвертируется в значение true, и static_assert никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций NumericParameter, кроме указанных ранее в цепочке if constexpr.

Правильный вариант:

static_assert(false, "unsupported ValueType");

A Micro-Manual for LISP.

LISP имеет удивительный по простоте синтаксис. Это делает его одним из самых популярных кандидатов для программирования своего интерпретатора.

Такой интерпретатор — замечательный пример пет-проекта, который расширит кругозор и познакомит с элегантностью LISP. Быть может, разожжёт интерес к Clojure и Scheme.

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

Маккарти формулирует основу LISP всего в десятке правил и пяти основных аббревиатурах, сопровождая этот набор дополнительными примерами.

И это описание занимает всего две страницы! Фантастика!

Статья на сайте ACM: https://dl.acm.org/doi/pdf/10.1145/960118.808386