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

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

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

Теперь посмотрим на круг. Там написано качественно + дешево = долго. Так вот долго это всегда дорого, потому что вам надо платить людям зарплату, а это далеко не только разработчики. У вас либо быстро и дешево, либо долго и тогда дорого. Либо там на самом деле никто не работает и просто создается видимость долгого процесса.

Если бы схема с качественно + дешево = долго работала, то в мире существовали супер успешные бизнесы построенные на Джунах, но этого не происходит. Любой кто пытался так сделать, в какой-то момент понимал, что это тупиковый путь. Вы видели чтобы заказчики радовались то, что на той стороне Джуны? Они не просто не радуются, но еще и проводят собесы, чтобы убедиться, что на той стороне профессионалы.

Но вообще каждый элемент в той схеме зависит от контекста. Дешево относительно чего? Например наш подрядчик по SEO взял миллион за работу. Это дешево или нет? А если в результате его работы мы смогли заработать 10 миллионов? Тогда это крайне дешево. А если выручка не изменилась? Значит мы заплатили очень дорого, за плохую работу. Правда? То есть получается стоимость определяется не фактической ценой, а относительна результата, который заранее не всегда возможно предсказать точно.

Точно так же тут можно продолжать разносить все остальные связки, но это я оставлю на ваше усмотрение :)

Ссылки: Телеграм | Youtube | VK

В этом выпуске мы поговорили с Егором Бугаенко — автором «Elegant Objects» и сторонником «честного» ООП-мышления. Он раскрыл, почему классическое объектно-ориентированное программирование — это не архитектура, а иллюзия порядка, за которой скрывается хаос.

Разобрали, почему null, static и наследование — главные разрушители систем, как мышление «в классах» ведёт к техдолгу, и почему ORM прячет от нас реальные ошибки в работе с данными. Егор настаивает: код должен быть сконструирован, а не написан, иначе система становится неуправляемой — особенно в эпоху LLM, когда ИИ сыплет автопатчами и код перестаёт быть осмысленным.

Также обсудили:

Почему композиция объектов — основа устойчивой архитектуры
Как мыслить модулями, а не строками кода
Что такое Fail Fast и зачем системе «падать» сразу
Почему архитектурное мышление — навык разработчика будущего
Как LLM усиливают хаос, если нет модели
Роль дизайн-долга и как он убивает бизнес-процессы

https://www.youtube.com/watch?v=X1HSGEADAhE

Альтернативные ссылки: Аудио | vk

Вы уже проходили? https://gosuslugi.ru/itskills Я только что получил сертификат по PHP (начинающий) с вопросами где нужно знать SQL и Веб (html + http). Защита от ИИ в стиле: "не используйте ИИ". Как бы там ни было, будем добавлять подготовку на Хекслет (ибо начнут спрашивать)

Конфигурация: данные vs код

Существует два основных подхода к описанию конфигурации: использовать код на каком-то языке (возможно dsх) или описывать все через универсальные форматы (yaml, json).

Например большинство линтеров и форматеров используют конфигурацию через json файлы. Хотя в JS экосистеме происходит сдвиг в сторону написания конфигурации для таких инструментов в js файлы. Системы сборки чаще делают кодом, например gradle или классический Make, хотя тот же maven использует xml.

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

Конфигурация на данных кажется классной идеей и практически незаменима, когда нам надо шарить ее между разными экосистемами. Классный пример это openapi спека. Она нужна и на беке и во фронте и внешним клиентам, которые пишутся на бог знает чем. При том что писать ручками саму спеку еще тот геморрой, поэтому вокруг созданы целые языки (не тьюринг полные) типа typespec, которые умеют генерить openapi спеку.

@route("/stores")
interface Stores {
  list(@query filter: string): Store[];
  read(@path id: Store): Store;
}

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

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

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

Так и что выбирать и на что ориентироваться? Как будто универсального ответа нет, видно как инструменты постоянно прыгают туда сюда и часто есть альтернатива для тех кто хочет гибкость (язык) или наоборот строгость (данные) со всеми плюсами и минусами описанными выше

p.s. Лиспофилы щас бы сказали что у нас два в одном и конфигурация и код описываются данными. Но это немного лукавство, потому что код как данные в лиспах имеет значение только внутри самих лиспов при написании макросов. Для внешних систем это не данные, которые можно взять и использовать

Ссылки: Телеграм | Youtube | VK

Я сегодня вошел в режим, что пока codex (openai copilot) рефакторит мне одну часть приложения, я в это время с chatgpt работаю над другой. Но это все хорошо работает, только когда у этой фигни есть хороший пример перед глазами, тогда оно рефакторит батчами без допилки

p.s. Простите что последние недели было без особых постов, я опять глубоко ушел в кодинг и хочу закончить перед тем как войду в более спокойный режим. youtube.com/watch?v=8LiyDZ8QLD0 не забудьте глянуть новое видео про ИИ на ютубе и в аудио

Альтернативные ссылки: Аудио | vk

Mantine > Bootstrap. Фух, вот я и закончил двухнедельный марафон, переписав Code Basics с Bootstrap на Mantine. Теперь можно выдохнуть перед следующим рывком и провести ретроспективу.

Кто меня знает давно, знают что я за решения где желательно не надо ничего делать и бутстрап для нас был таким решением на протяжении 12 лет и остается по сей день на Хекслете. Буквально полгода назад я делал попытку куда-то свернуть, но но нашел полностью готовый UI Kit, который бы соответствовал всем моим ожиданиям. Но было несколько интересных, среди них Mantine.

Почему я вообще хочу куда-то уйти, если бутстрап такой распекрасный? В целом переход на inertiajs и уход от северной шаблонизации + четыре основных момента по фронтендовым UI Kit:

- Мир ушел сильно вперед по подходам. Современные системы например полностью типизированы (а не просто херачим классы), очень сильно оптимизированы (вырезают всякое) и скомпонованы так, что дают больше возможностей. Бутстрап туда планирует прийти, но его всегда будет тянуть легаси
- Бутстрап это в первую очередь css фреймворк, а сейчас нужен не css, а React/Vue/Svetle. У бутстрапа есть внешняя поделка, которой занимаются в полсилы чуваки после работы. Кстати, tailwind по этой причине тоже не подходит, он может быть только базой для чего-то
- Сейчас во фронтенде нужны не просто компоненты, а полноценные решения типа DataGrid, которые из коробки дают тебе фильтры, пагинацию, поиск, инлайн редактирование и кучу всего еще. В бутстрапе такого нет и приходится тащить, что-то типа primereact.
- Против толпы не попрешь. Мир уже слишком ушел вперед, поэтому если хочется нанимать кого-то и быть привлекательным, то тоже надо двигаться (насколько это разумно)

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

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

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

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

Ну и еще не менее важно, что сам подход Mantine подразумевает работу через пропсы, а не классы. Да это мешает быстро проверять в devtools, но мы получаем полную типобезопасность и автокомплит. Хотя до этого момента, я думал что как же мне не хватает lsp для bootstrap (для tailwind такой есть). А оказалось что он и не нужен.

При этом все можно достаточно неплохо переопределить. Причем не только внешний контейнер компонентов, но и внутренности, для этого у Mantine довольно удобный механизм внутри, который тоже весь вдоль и поперек типизирован. Правда все равно не обошлось без доп подключения утилит tailwind. Например в mantine нет мелких утилит типа добавить границу сверху. Это сделано бай дизайн, типа пишите стили сами, так как это все таки готовый Kit. Но у меня таких использований классов буквальна парочка. Больше классов в проекте нет.

С учетом популярности Mantine (и она растет), я думаю что нашел надежное решение на много лет вперед. Буквально скоро начну внедрение и на самом Хекслете.
https://code-basics.com/ru

Ссылки: Телеграм | Youtube | VK

Давно мы не искали себе разработчика, а тут начали. Вакансия называется: “Ruby On Rails” разработчик, при этом внутри сказано, что если не работали с ruby/rails проблем никаких, главное хоть какой-то похожий бекенд фреймворк на любом языке. Ну и фронтенд желательно, потому что мы тут в целом фулстеки и девопсы в одном лице. Опять же, всему чему надо научим.

Всего откликов около 300 и мы все их рассматривали без каких-либо автофильтров. Как она распределилась:

Часть ушла в отказ, потому что нерелевантная, это когда откликаются вообще не программисты или есть технические ограничения в стиле человек в другой стране, а мы не можем платить. Сколько таких было не знаю, это на уровне рекрутера. Тут важно сказать, что в Хекслете рекрутер не принимает решение по техническим скилам и даже не смотрит их. Задача рекрутера это ведение процесса и отсев абсолютно нерелевантные резюме. У нас разок девопс подал заявку на смм-маркетолога, вот типа такого.

Второй уровень отбора уже на мне. Тут большинство улетело в отказ потому что “я фронтенд разработчик подаюсь на вашу вакансию фронтенд разработчика”. Это почти дословно пишут в сопроводительном, а в резюме ноль бекенда. Чувствую автоматику тут я. Такое только с фронтами, их прямо очень много и они все без бекенд опыта. Уверен среди них много толковых, но только на этой должности нам нужен другой человек.

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

Кто пошел дальше? Фулстеки, питонисты, php-разработчики и рубисты. Не было чуваков с java/kotlin/c#, хотя я бы с удовольствием их рассматривал.

В целом на скрининге около 30 человек ( это 10%, нормальная цифра), где с ними в целом на полчасика поговорят про “почему уволился”, “чо хочешь”, “чем занимался”. Технички тут минимум и проводит скрининг наш синьор.

Дальше уже собес у меня. Пока был только один, но главное что я кардинально поменял подход. Мы просто открываем наш опенсорс, клонируем, разворачиваем и делаем какое-то мелкое добавление/изменение. Человека истессно заранее просят подготовиться, чтобы можно было пошарить экран. В процессе можно пользоваться вообще всем чем хочется. Результат пока единственного собеса, что мы не прошли стадию “развернуть проект”, застряли на работе в терминале. Я, кстати, большую часть просто молча смотрю в поваренный экран. То есть на собесе вообще ничего больше нет.

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

Забавно, что многие стали в “о себе” писать капсом МОГУ ПОДТВЕРДИТЬ ОПЫТ :)

А главное что? Никакого отличия от того, как было пять лет назад. Как были сотни откликов и единицы тех кого хочется взять (тут пока еще не было этого), так и осталось

Ссылки: Телеграм | Youtube | VK

Удивительная история. Артем Малышев в 2010 году попал ко мне на работу, но не прошел испытательный срок. Год назад я делал шортс на ютубе, где об этом упоминалось. Так получилось что Артем увидел это видео узнал там себя и написал мне. За это время, как оказалось, он проделал громадный путь и даже стал кор разработчиком популярных опенсорс решений включая компоненты Django. В общем мы договорились, что обсудим его путь на подкасте:

- что давал ранний фриланс на Upwork и почему там важно сразу считать стоимость не только работы, но и валютного контроля;
- как автоматизация антивирусных отчётов превратилась в первый серьёзный питон-опыт;
- Как один твит, XSLT-плагин и 20 чашек кофе привели к внезапному контракту в Германии;
- коридорный разговор на конференции, который привёл к гранту Mozilla и работе над Django Channels;
- историю о контрибьюторе, продавшем поддержку библиотеки без ведома автора — и чем всё закончилось.
https://youtube.com/watch?v=EL8Nnufo6UQ

Альтернативные ссылки: Аудио | vk

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

* Может в бек в несколько языков
* Может во фронт
* Умеет и настраивает пайпланый от Docker Compose до Github Actions
* Может сетапить и настраивать облака

(дисклеймер: речь не о том, что таким должен быть каждый, а что это не рокет сайнс все это уметь на хорошем уровне, достаточным чтобы классно делать проекты)

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

Знает ли досконально все? Вообще не факт, а скорее всего нет. От того что человек занимается только чем-то одним, не означает что он сидит и как не в себя копает во внутрь по этой теме. Как правило я вижу другую картину, если делать долго и упорно одно и тоже, то в какой-то момент это все делается на автомате, а дальше человек просто останавливается в развитии (соседний фреймворк не считается) ну либо становится тем, о ком я пишу выше.

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

А качественный код? Вот тут вообще никакой корреляции. Да, мы все слышали, что приходят беки и пишут фронт, после которых надо все переписывать, но это не ситуация, которую я рассматриваю. Мы все таки говорим про фулстеков, то есть тех кто целенаправленно учит, а не пишет фронт, потому что попросили, а он не сечет и не планирует учиться писать правильно. Что касается в целом подходов, то люди с более широким кругозором и опытом пишут обычно лучше. Потому что качество кода проявляется не в мелких деталях, что вы например в курсе про более крутой хук. Это все локальные оптимизации. Качество оно про более высокий уровень.

На практике все чуть сложнее. Главный фактор, который вижу я, помимо “я не буду этого делать” - компания и команда в которой работает человек. Где-то это норма, где-то нет и в зависимости от этого и идет рост.

Ссылки: Телеграм | Youtube | VK

Пейджеры. Вы задумывались над тем, что за режим открывается когда мы делаем git log или git log -p? Этот режим используется для удобства чтения больших объёмов текста, позволяя вам листать их постранично, искать по ключевым словам и перемещаться без пролистывания всего содержимого сразу.

Многие не знают, но это не встроенная фича гита, гит, в данном случае, в соответствии с философией Unix, гит открывает другую программу, которая называется пейджер. Этот же пейджер открывается и во многих других ситуациях, например, когда вы просматриваете man-страницы или результаты git diff.

Всего существуют два основных пейджера: more и less. Это реальные программы, которые можно запускать прямо в терминале напрямую или перенаправлять в них вывод: ls | less.

Первый менее функциональный, поэтому в основном используется второй. Проверить то, какой у вас стоит в системе можно посмотрев переменную окружения PAGER. Если там more, то лучше поменять на less. Зачем?

Вчера я записывал подкаст с Алексеем Гладких, где мы проходились с ним по фичам вима и терминала. И мне хотелось показать одну прикольную штуку объединяющую пейджеры и вим. Дело в том, что навигация в пейджерах это, по сути, вимовская навигация. j - вниз, k - наверх, / - поиск (n - искать дальше, N - искать предыдущее), ctrl+d - вперед на полэкрана, ctrl+u - назад на пол экрана. И правильное навигирование в пейджере это большой шаг в сторону освоения вима. Но когда Леша открыл git log и попробовал все это сделать, выяснилось что у него на арче по дефолту стоял more, где навигация другая. Мы все это добро быстро поправили и теперь ему проще поддерживать нужный уровень владения инструментом без постоянной активной практики (а у него был такой запрос).

В общем если еще не, то попробуйте

p.s. тот самый случай когда не могу не порекомендовать мой бесплатный курс по основам командной строки, где это объясняется (а еще там много других полезных штук, для тех кто работает с терминалом в магическом режиме) Пейджеры

https://ru.hexlet.io/programs/cli-basics

По мне получился отличный выпуск где мы с Александром Вершиловым разобрали по косточкам ORM, разные подходы и проблемы вокруг. Оч рекомендую https://youtu.be/O1Qxpvt7WCw?si=e3vzp5mYCvbCpXeG

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

Пока только с одним кандидатом мы дошли до точки "получилось развернуть проект, пилим фичу". Остальные споткнулись на его разворачивании. Здесь мы тратили от получаса до часа (весь собес), после чего заканчивали. Какие проблемы возникали?

Сразу дисклеймер. Все это было всегда так, поэтому для меня без сюрпризов. Что 15 лет назад, что сейчас. Технологии двигаются вперед, но люди остаются людьми. Собственно поэтому я когда-то и присоединился к Хекслету, чтобы исправлять ситуацию.

Знание терминала и основ Linux

По действиям людей и их конфигам, видно, что, в основном, его использование сводилось к копированию команд, которые просят ввести: дока утилит, вывод пакетного менеджера, что-то со стековерфлоу и ИИ. Часто утыкались в то, что неправильно настроена PATH, но человек не знающий как это вообще работает, двигался просто не в ту сторону решая не существующие проблемы. В другом случае в запущенном zsh вводились команды bash. И chatgpt в таких ситуациях не только не помогал, но и путал, потому что его пускали по ложному следу.

Ридми проекта

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

Обучение (документация и ИИ)

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

Использование ИИ

Тут тоже немного удивился, потому что ИИ используют многие, но он никому не помог из тех кого я собесил. А причина такая, его используют неправильно. Например терминал что-то выводит и показывает ошибку. Если сходу непонятно что это, то имеет смысл сразу закинуть в ИИ и команду и вывод. Почему-то никто этого не делал. Вместо этого было много попыток догадаться что не так и они были неуспешные. Было один раз, когда не работал докер, но там прямо было написано, что докер не запущен. А в местах где не очевидно, такое не делали.

Ну и последнее. Никто не использует как менеджеры версий mise или хотя бы asdf. Если вы еще не, то уже пора. Забудьте про rbenv, rvm и упаси господи про прямую установку.

Ссылки: Телеграм | Youtube | VK

Вим-сессия с Алексеем Гладких

Уже среда, а я до сих пор не написал что вышел подкаст с Лешей Гладких на тему использования вима и немного командной строки. С другой стороны, за это время накидали разных комментов, которые я бы хотел выделить и дополнить или просто показать прикольные штуки. https://youtube.com/watch?v=Ip89ylyOSdg

home row mods

Я узнал про https://precondition.github.io/home-row-mods Крайне рекомендую ознакомиться и попробовать применить, если вас подбешивает тянуться за управляющими клавишами (либо поменяйте caps lock как мы там обсуждали)

CapsLock

Когда я говорю про свитч капслока с контролом, мне часто возражают мол ESC нажимается чаще, поэтому его надо туда. На самом деле не надо. В виме вообще не надо нажимать ESC потому что вместо него есть стандартный ctrl + [. И как видите снова контрол. Это единственная из управляющих клавиш, которая должна находится в максимально удобном месте

Смена буферов

Я там говорил про комбо для смены между двумя последними активными буферами и многие начали писать что вот мол есть комбо проще и еще встроенные в сам вим. Это правда, комбо такое есть (ctrl + ^), но тянуться до ^ далеко (при такой частоте использования это далеко) и что еще крайне важно, это комбо работает только для свича двух буферов, а для переключения на другие надо использовать что-то еще. В моем же подходе (стандартный в lazyvim) это единое комбо для переключения по любым буферам (с фази) включая быстрый свитч по последним двум

% при замене в %s/replace/to/

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

Git в редакторе

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

Ссылки: Телеграм | Youtube | VK

p.s. В этот раз в аудио не выгружали, без видео тут бесмысленно

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

TypeScript, Kotlin, Scala, ClojureScript, Elm, CoffeeScript, Elixir — все эти языки работают внутри чужих платформ: JavaScript, JVM или BEAM (виртуальная машина Erlang). Одни из них становятся массовыми и вытесняют оригинальные языки. Другие — остаются нишевыми или вымирают.

🔑 Один из ключевых факторов успеха — прозрачность интеропа. Важно не просто “можно ли вызывать код другой платформы”, а насколько это естественно:

- Совпадают ли типы данных
- Совпадают ли структуры: массивы, строки, объекты
- Совпадает ли модель исполнения: async, исключения, мутабельность

🟢 Когда интероп прозрачный, код из другого мира ощущается как “свой”, без лишнего контекста.
🔴 Когда интероп чужеродный, ты всё время чувствуешь стык: пишешь обёртки, преобразуешь данные, думаешь как бы “переехать” между языками.

Как только интероп становится непрозрачным — возникают обёртки: адаптеры поверх JS-библиотек (в ClojureScript, Elm, Scala.js), shim-функции и преобразователи структур, вспомогательные типы и интерфейсы. Это ведёт к дополнительной сложности, ошибкам и постоянной ментальной перегрузке.

📎 Пример: Elm → JavaScript

Даже чтобы вызвать console.log, нужна отдельная конструкция:

-- Elm
port module Main exposing (..)

port logToConsole : String -> Cmd msg

update msg model =
  case msg of
    TriggerLog ->
      (model, logToConsole "Hello from Elm!")

// JavaScript
const app = Elm.Main.init()

app.ports.logToConsole.subscribe((msg) => {
  console.log(msg)
})

Для любого взаимодействия с внешним миром (HTTP, localStorage, DOM) придётся городить такие конструкции.

📌 Примеры:

TypeScript — бесшовный интероп с JS. Код можно смешивать без усилий. Поэтому стал стандартом.
Kotlin — отлично встраивается в JVM и Java-проекты. Небольшие различия, но высокая совместимость.
Scala — технически совместим, но требует усилий: система типов сложнее, код не всегда читаем из Java. Интероп чувствуется.
ClojureScript — сильно отличается по структурам данных и синтаксису. Использовать JS-библиотеки можно, но неудобно.
Elm — намеренно изолирован от JS. Интероп возможен только через порты. Это безопасно, но очень ограниченно.
CoffeeScript — хорошо совпадал с JS. Был популярен, пока не появился TypeScript с типами и без сюрпризов.
Elixir — работает на BEAM и отлично сочетается с Erlang: одни структуры, общая модель исполнения. Пример максимально прозрачного интеропа.

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

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

Ссылки: Телеграм | Youtube | VK

Почему многие программисты не станут синьорами никогда

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

Запоминайте паттерн решения любого затыка в кодинге:

1. 5-10 минут пробуем применить какие-то быстрые догадки и метод тыка
2. 10-20 минут тратим на поиск готовых решений в ИИ и на reddit (стековерфлоу прости, ты больше не нужен)
3. И примерно спустя 30 минут тыкания останавливаемся. На этом этапе мы должны перейти в режим, а что это вообще за проблема? Начинаем читать по теме пытаясь понять как в целом работает эта штука, которая сломалась, что за ней стоит, какая теория подходы и все в этом духе. Разбираемся за час-два и фиксим
4. Если не помогло, тут уже надо с кем-то поговорить. Нельзя висеть на одной задаче без движения больше 2 часов.

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

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

На практике так происходит очень часто. Человек тыкается не 5 минут, а часами никак не разбираясь в том, что он делает.

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

Видео на эту тему одно из первых у меня на канале: https://www.youtube.com/watch?v=9iwYRcw3A8A

Ссылки: Телеграм | Youtube | VK

Почему надо знать про супервизоры

По мотивам собеса. Значит ситуация, человек запускает постгрю в докере, но контейнер не стартует потому что порт 5432 уже занят. Дальше начинается отладка, которая с большой вероятностью будет не очень успешной, если разработчик не знаком с тем как функционируют операционки. И так, поехали в разбор.

Почему порт занят, что это значит? Значит что на этом порту уже запущена какая-то программа. Почти наверняка это постгрес, который был установлен прямо в систему.

Первым делом стоит проверить, а не запущен ли уже контейнер с базой, возможно для другого проекта: docker ps. Если в выводе есть: 0.0.0.0:5432->5432/tcp, то отладка прошла, можно стопать и запускать нужный конейтенер. А если нет?

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

lsof -i :5432

NAME
localhost:postgresql->localhost:60378 (FIN_WAIT_2)
localhost:60378->localhost:postgresql (CLOSE_WAIT)

Для простоты я оставил здесь только NAME, но сам вывод показывает и команду и пид и пользователя. В общем достаточно информативно.

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

sudo kill -9 <pid>

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

Вот тут остановитесь и подумайте. А что собственно говоря происходит?

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

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

Локально все работает точно так же, даже если вы этого явно не видите. Постгрес стартует в вашей системе не сам по себе, его запускает супервизор и управлять им нужно через супервизор. В Ubuntu это systemd, в MacOS launchd. В каждой из этих систем предоставляется высокоуровневый интерфейс для работы. Вот как это выглядит для тех кто использует brew:

brew install postgresql@14
brew services start postgresql@14

brew services list

Name          Status   User File
postgresql@14 started  kirill ~/Library/LaunchAgents/homebrew.mxcl.postgresql@14.plist
php           none
caddy         none

brew services stop postgresql@14

Плюс минус тоже самое во всех остальных операционках.

Ссылки: Телеграм | Youtube | VK

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

А так же:

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

https://youtube.com/watch?v=_tj5way-6hQ

Инкапсуляция не работает

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

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

class User {
    private final List<Role> roles = new ArrayList<>();

    public List<Role> getRoles() {
        return roles;
    }
}

Но нам никто не машет сделать так:

user.getRoles().clear(); // теперь ролей нет
// Можно добавить дубль
user.getRoles().add(new Role("admin"));
user.getRoles().add(new Role("admin"));

Даже если геттеров нет, рефлексия пробивает любую «защиту»:

var field = User.class.getDeclaredField("roles");
field.setAccessible(true);
@SuppressWarnings("unchecked")
var roles = (List<Role>) field.get(user);
roles.clear();

Мое мнение о механизме private/protected/public со временем сильно поменялось, когда я пописал на языках где этого нет, но есть ООП. По большому счету этот механизм является в первую очередь защитой от дурака и он вообще не влияет на архитектуру. Если взять любой проект и поменять там все на public, то проект продолжит работать как ни в чем не бывало (если конечно код не завязан на рефлексию с этими).

Это не значит что инварианты соблюдать не надо и не нужно иметь публичный интерфейс для работы с нашими объектами (иначе как обновлять код и либы?). Речь скорее про другое, это не панацея и уж точно не механизм, который влияет хоть как-то на архитектуру. Обозначать публичный и внутренний интерфейс можно и другими способами, а данные внутри объектов часто делают закрытыми в принципе без возможности обращаться к ним без методов или рефлексии (например в ruby).

p.s. Какие еще способы вы знаете как обойти private?

Программисты не верят в инструкции

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

Напоминание: мой собес это берем продакшен проект (опенсорсный), в котором классические rails. Человек его разворачивает на свой машине и делает несколько простых фиксов. Только вот до фич доходят единицы, в основном мы зависаем на сетапе. И вот почему. Ниже пара примеров.

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

В другом случае человек увидел Dockerfile и даже не заглянув в README.md проекта начал его собирать. А в этом проекте запуск в деве идет не через него. Кстати, проект так и не запустился.

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

Ну и последний пример. Видят домен .localhost и все равно идут добавлять его в hosts, хотя в инструкции нет такой установки (потому что и так работает)

И знаете что самое интересное? В большинстве случаев, ребята начинают менять что-то в файлах самого проекта, хотя для меня это нонсенс. Проект, сетап которого требует в рукопашную менять внутренние файлы (при этом оно нигде не описано)? Чот я давно с таким не встречался.

Без проблем все проходило только у тех, кто просто выполнял команды по очереди как они даны в README.md.

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

Ссылки: Телеграм | Youtube | VK