IV набор NarisApp
Начинаю набор в IV сезон. Информацию о проекте и порядке участия можно посмотреть здесь - https://s0er.ru/documents/article/6008

Коротко: NarisApp это OpenSource приложение которое мы делаем с командой SOER.PRO, подать заявку на участие может каждый желающий. Каждый раз мы набираем 30 человек, из которых до конца доходит 5-7 человек. Все очень весело и хардкорно.

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

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

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

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

Про то почему программировать сложно

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

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

Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво
- Сплетни нашего ютуба
- Донаты решают

В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.

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

Попался мне блог очередного успешного программиста из серии "один мой друг тоже учёный, 3 класса образования".
Его критерий успешного программиста - если 1000$ можешь потратить на тусу с друзьями, значит успешный, если нет значит неуспешный.
Сказать что я удивлён - это ничего не сказать, ведь все знают, что успешный программист - это тот кто может 11 1111 1111$ на друзей потратить, ведь все программиста делятся ровно на 10 класса - те кто понимают, кто такие программисты и те кто не понимают.

По поводу того как архитектура мешает делать неправильные вещи

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

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

Изоляция, грануляция, проведение границ, разделение ответственности - основные архитектурные инструменты на уровне системы и приложения.

Типы, принципы и паттерны - это инструменты архитектуры на уровне кода.

Вопрос: Можно ли в domain слой добавлять классы со специфичными ORM атрибутами если ORM плохо поддерживает генерацию POCO классов? Надо ли воевать с этим?

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

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

Ну вот, потерял того единственного зрителя ради которого канал заводил. Ради чего теперь стримы снимать?

Хотя погодите, а че это за хер?

Интересно, этот человек когда-нибудь от меня отъебется? Как объяснить, что мне совершенно параллельно, что он думает?

Как типы помогают программировать

Заметил, что после того как программист переходит на TypeScript, после чистого JavaScript, то через некоторое время, он все меньше смотрит в браузер и все больше доверяет парсеру TS. Цикл работы сокращается и разработка идет быстрее.

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

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

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

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

Не зря все больше фронтендеров любят TS, по сути это означает, что они все больше любят "типы".

По поводу набора в NarisApp
Анализ заявок и приглашение к участию будет ближе к концу недели, пока собираю все обращения. Набор будет примерно 20 человек, пока заявок немного, поэтому пока попадают все.

Субботнего стрима не будет

Завтра стрима не будет. Отдыхаем, набираемся сил.

Набор в NarisApp в IV набор завершен

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

Спасибо всем кто откликнулся.

HATEOAS (Hypermedia as the Engine of Application State)

Недавно в чате обсуждалось соответствие современных REST API требованию единообразия интерфейсов в REST, в частности речь шла о HATEOAS.

С учетом того, что REST API почти всегда делают на базе веб-решений, это требования выполняется по дефолту. Тут надо вспомнить, что REST появился как архитектурный стиль в то время, когда про WEB 2.0 еще толком никто не знал.

Со временем веб-архитектура развилась так, что сейчас "все есть веб". Поэтому у многих возникает вопрос, а где там HATEOAS? Появляются разные интерпретации и надуманные требования о содержимом ответов, которые должны давать REST API (например, что они обязательно должны содержать ссылки на другие ресурсы)

На самом деле в мире где еще не было WEB 2.0 HATEOAS означал лишь то, что REST приложение должно работать не с каким-то специфичным клиентом, который реализует свой протокол, а с любым приложением которое умеет работать с гипермедиа, т.е. по сути любые веб-клиенты.

Отсюда, если ваш REST API может быть доступен по HTTP через браузер, консольный клиент или как-угодно клиентом понимающим HTTP, то он дефакто HATEOAS.

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

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

Субботний стрим 28.10 10:00

Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:

- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают

В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.

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

Завтра поднимаю цены на доступ к ресурсам SOER.PRO.
Для всех у кого есть действующая подписка ничего не меняется, подписка будет пролонгироваться на тех условиях, которые были в момент приобретения подписки.

Если давно думали взять подписку в клуб SOER.PRO, то рекомендую сделать это сегодня по старым ценам (STREAM по 350 рублей в месяц), завтра будет дороже.