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

Только предварительно абсолютно обязательно прорешать все hard-задачки по SQL с хакерранга или codewars, отлично встраивает в голову понимание, как правильно строятся и работают хорошие реляционные модели.

P.S. Кстати, обещанный сериал на эти темы я выложил одним постом в вк.

Спрашивали по поводу этого поста : почему именно логика предикатов?

Ну, например требуется в программе задать отношение "пользователь принадлежит группе".

Мы можем добавить таблице пользователей поле fk на таблицу групп, или в таблице групп добавить fk на таблицу пользователей, или создать новую таблицу для отношения многие-ко-многим, или организовать join-запрос или материализованное представление... Изменения, которые будут внесены при этом в реализацию системы в разных её слоях, могут быть весьма существенными, и пытаться их формально верифицировать (или как минимум легко понимать) весьма сложно и накладно. Однако в нашей думательной машинке, в модели системы в нашем уме, достаточно зафиксировать лишь одну абстракцию, один простейший предикат "пользователь принадлежит группе", который либо истинен, либо ложен.
Вот и всё.

P.S. И лучше уточнять "каждый пользователь принадлежит хотя бы одной/ровно одной группе" (чтобы исключить эти ваши кривейшие NULL), и требовать чтобы такой инвариант всегда был истинен, и т. п.

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

Интересно, что мало кто знает, что Francesco Cirillo -- автор легендарной техники работы "помидорками", также и ИТ-консультант. Главное, что он организовал в 2007-м кампанию Anti-If, в рамках которой активно выступает против условного оператора, а подключились к этой кампании немало очень авторитетных специалистов по computer science. Их аргументы достаточно просты и вески: if-выражения могут создавать экспоненциальное число вариантов работы программы, и вы должны каким-то образом гарантировать, что ваш код успешно работает в каждом из них. Представляете, насколько усложняется 100% покрытие кода тестами, которое например часто требуется в проектах финтеха и КИИ? Ведь, действительно, существует много альтернативных и куда более выразительных и правильных подходов, от полиморфизма до декларативных описаний.

Я иногда консультирую небольшие ИТ-команды, и часто начинаю code review с поиска операторов if, потому что точно знаю, что в 98% случаев, где бы я ни увидел их "концентрацию", тут же обязательно найдется недостаток (и это ещё в лучшем случае стилистический), который я смогу отметить.

На эту тему написано множество статей и даётся множество рекомендаций, как обходить условный оператор, вот например от одного из участников кампании: anti-if-the-missing-patterns

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

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

P.S. Между прочим, групповые тренинги и видеокурсы Cirillo на тему, как избавляться от if (никаких правил-генериков, а просто инженерный разбор множества паттернов, без разбиения на семантические категории, и поэтому с невысоким кпд результата) стоят около 700 евро, а я спалю моим ребятам в СильныхИдеях глубинное решение этой важной темки бесплатно.

Что только не понапихано в Java: packages (пространства имён, по сути), классы, объекты, object types, records, модули, интерфейсы, абстрактные классы... по-моему, даже sum types можно реализовать с помощью visitor (единственный паттерн, достойный уважения, кстати).
У каждой из этих концепций в теории типов имеется своя теория, и иногда они идеологически полностью противоположны друг другу.
98% разработчиков однако используют их "инженерно" без малейшего понимания семантики, смешивая в своём коде совершенно несовместимые вещи, а потом удивляясь, почему всё так быстро запутывается.

Элизер Юдковский (хорошо пропиарившийся на том самом "Гарри Поттере и методах рационального мышления", рекомендую) недавно заявил, что

"You would not want Russia believing that the Allies would back down from destroying the GPU farm given a credible commitment by Russia to nuke in reply to any conventional attack, and the Allies in fact believing that the danger to humanity meant they had to airstrike the GPU farm anyways"

Но кто он такой? :) Известный тусовщик в этой теме, однако его уровень в понимании математики LLM ещё ниже, чем у меня, любой диванный эксперт с университетским образованием в машин лёнинге даст ему 100500 очков вперёд.

Но в целом, это действительно тренд: множество людей, которые пребывают в (поддельном) ужасе перед AGI, практически не пересекается с множеством людей, кто на самом деле создаёт современные модели AI.

P.S. Безусловно однако, что опасения Юдковского отнюдь не беспочвенны :) Они же там у себя собираются ввести мораторий на исследования в области AI, в который Россия (надеюсь) не впишется, и у нас появится прекрасная возможность, во-первых, сократить в этой области существенное отставание (а то и выйти вперёд), и во-вторых, потроллить недружественные страны совершенно реальной альтернативной AI-угрозой. Я бы даже посоздавал множество фейковых дата-центров, как в "Небесном тихоходе", где якобы работают тучи GPU над русским Скайнетом.

По старой памяти, почитал блог про CAN Injection: keyless car theft (Dr. Ken Tindell, CTO of Canis Automotive Labs)

(я работал лет 10 назад в компании крутых ребят, делали они в частности принималки телеметрии с CAN-шины, взламывали закрытые промышленные протоколы...)

Там очень смешное: с помощью 10-долларовой электроники можно хакнуть большинство современных автомобилей.

Ну, совершенно не удивлён: в некоторых (многих) хорошо известных марках современных автомобилей работает уже более 100 миллионов строк кода бортового софта, и можно себе представить его качество.

Элементарную криптозащиту годами не могут прикрутить, поразительно, это десять строк кода добавить...

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

(реклама в духе Пелевина)
100% натуральное программное обеспечение.
Абсолютно никаких Искусственных Ингредиентов.

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

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

Самое печальное (что, впрочем, неотъемлемое свойство современного мэйнстрима), что энтузиасты кампании Anti-If придумывают подчас такие приёмчики, которые скорее вредят, чем помогают. Например, я большой поклонник декларативной формы записи, однако она иногда доводится до абсурда, когда обычное условие

if x > 0
then print("положительное")
else print("отрицательное или 0")

переписывается например с помощью лямбда-функций и макро-команды/темплейта (реальный пример из жизни)

IfElse(x > 0,
() => print("положительное"),
() => print("отрицательное или 0"));

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

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

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

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

Как понять, что вы сеньор? Это когда в вашем стеке вы можете сделать потенциально любой проект (хорошо понимаете, как) полностью самостоятельно. Неважно, что на него может потребоваться 100 лет, речь именно о понимании.

Если аналогично понимаете, как делаются отдельные подсистемы (не менее 50%), значит вы миддл.

Если понимаете устройство и способны реализовать 20-50% подсистем, значит вы пока джуниор.

Иначе, стажёр :)

VK Tech приглашает будущих программистов на стажировку

Сроки проведения отбора: май-июнь 2023
Сроки проведения стажировки: июль-август 2023

(нереклама, просто рекомендую, потому что ВК очень любит деньги -- в прошлом году они заработали 100 миллиардов рублей, и стажёрам наверняка перепадёт)

P.S. Надо отметить, что стажировка по мэйлрусски -- это не писать немножечко ясного кода, они хочут, чтобы стажёр например был в стеке Java + Python + Go + JS + Vue/React (а кому сейчас легко)

ахаха Demiurges — новое слово в компьютерных играх )))

Клон HoMM (неплохой кстати), но в печальном тренде последних лет нарочитой ретро-графики (мне ужасно не нравится), доведённой до абсурда.

Впрочем, уже совсем скоро таким самоделкам придёт конец, вот полюбуйтесь, сегодня подобное начинает клепать AI: симулятор жизни

Как они это делают:
https://arxiv.org/abs/2304.03442

Почему AI в ИТ вряд ли станет массовым?

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

Буквально, даёшь AI сложные задачи -- решает 20%. Добавляешь к условиям фразу "Lets go step by step" -- решает 80% :)

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

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

Дико уважаю.
В феврале 2018-го у него в последний раз было 2-3 дня пауз в работе.
А чего добился ты?

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

Есть такая канадская Wave Financial, которая стоит 1,7 млрд. долл. -- финтех для малого бизнеса, онлайн-бухгалтерия и пр. Сам сервис, по большому счёту, чистый CRUD, занимающийся сложением чиселок. В Wave работает считанные десятки разработчиков, которые пилят прозаический монолит на Python поверх Postgresql.

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

Почти за такую же цену был куплен в своё время и StackOverflow, который так же успешно масштабировал свой монолит.

...У нас были 4 Microsoft SQL Servers, 11 IIS Web Servers, 2 Redis Servers, 3 Tag Engine servers, 3 Elasticsearch servers, 4 HAProxy Load Balancers и 4 циски.
Ну совсем скромная архитектурка, да ещё и под виндой :)

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

P.S. Поподробнее на эту тему в вк напишу пост.

Воистину.

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

Однако вот отличная статья топовых исследователей ОС:
"A fork() in the road"
— Microsoft Research, Boston University, ETH Zurich.

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

In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives. As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.

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

Из чата с курсантом, по развитию карьеры. 50 вакансий -- это статистически значимая выборка!

Евгений:
...я посмотрел около 50 вакансий дата инженера в основных индустриях, где с данными работают (ИТ, телеком, банки, ритейл).
Везде в принципе одно и тоже просят:
- sql и всё смежное по субд (прям отличный уровень нужен, не просто select) (может стоит все-таки ваш курс по SQL пройти, если там есть какая-нибудь теория по БД);
- python,scala,java (обычно один или два языка просят, скалу часто вижу в требованиях);
- hadoop,apache airflowи тд (программы для работы с big data; их много достаточно);
- все остальное что касается ETL процессов

На сеньорских позициях встречается подобное:
- Опыт разработки высоконагруженных бэкенд сервисов на Java, Scala или Python;

Вообще как мне кажется (дилетанским взглядом конечно) дата инженер похож на backend разработчика, который использует в работе много разных big data штук, типо оркестраторов и так далее. А в остальном как будто требования пересекаются в 70-80% случаев.

Мой ответ:

Да, безусловно, 80% это бэкенд, 20% специфика, акцент на ETL (вся унылая грязная работа по очистке датасетов, которую обычно сваливают на джуниоров :) работа с моделями это элитное сеньорское). Вообще, бэк рулит везде, даже для фронтенда немножко ) Я поэтому на нём и делаю основной акцент.

Отличное знание SQL и БД в датасайнсе абсолютно обязательно, прочитайте от корки до корки учебник Бьюли "Изучаем SQL" но это лишь начало, главное уверенно решать middle-hard задачки на хакерранге и codewars, очень правильный навык дата-моделирования при этом вырабатывается. И конечно поизучать классику
"Системы баз данных. Полный курс" Ульмана.

Я кстати раньше рекомендовал ещё "SQL и реляционная теория. Как грамотно писать код на SQL" Дейта, но это не для слабаков из мэйнстрима, сложная, много теории, очень мощная, реальный хардкор,
90% профи многих этих принципиально важных вещей не знают, рекомендую.

Надо ли доводить код до совершенства?

Если вы всегда стремитесь приводить в порядок всё, что выглядит беспорядочным, то вы будете тратить почти всё своё время на рефакторинг и чистоту кода, и совсем мало времени на внедрение новых фич.

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

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

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

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

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

Многие люди не могут придерживаться чего-то одного, не могут сконцентрироваться на важном и полезном для них, не способны ни один длительный проект довести до конца. И это одна из главных причин, по которой они НИКОГДА не заработают много денег. Вот почему они застревают в своих 9-18, пока в 65 лет не становятся старыми и морщинистыми.

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

Из многих сотен ребят все мои курсы, мою Школу до конца за последние три года прошло всего два человека, и ещё считанные единицы с тренинга по проектированию higher work к этому подбираются. А 99% просто не способны даже такое не очень долгое время учиться нужному и полезному. По сути, они предают сами себя. Ну штош...

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