Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

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

Надеюсь, этот пост станет моральной поддержкой для страдающих программистов и технологов, стремящихся улучшить ситуацию. Дело не только в вас, и мы не просто страдаем от ностальгии: ПО сегодня действительно очень странное.

Как говорил Юрий Гагарин: "В будущем мы будем летать, много летать". В определённой мере игровой движок Dagor Engine от Gaijin Entertainment позволяет это сделать. Давайте посмотрим, как он сделан, и поговорим с его создателями!

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

Всем салют!

Хочу рассказать вам историю о том, как я начинал с уровня — «не могу решить даже 1 easy задачу из 10» до уровня — «могу решить каждую вторую medium задачу» и прошел несколько coding сессий в таких компаниях как Meta, Booking, Careem, Avito...

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

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

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

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

Сегодня мы поговорим о двух концепциях — Event Sourcing и CQRS, и их реализации на языке Go. Go предоставляет хорошие возможности для реализации этих паттернов благодаря своей производительности, простоте и поддержке конкурентности «из коробки».

Наверное, уже все слышали про процесс собеседования в FAANG (и другой BigTech). Leetcode задачи, системный дизайн, поведенческие вопросы, culture fit, и прочие баззворды регулярно обсуждаются на Хабре. Коллективный разум Хабра более или менее пришел к общему консенсусу: это бессмысленная процедура, которую проектировали некомпетентные люди.

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

Использование спецификации открыло для меня новый мир в создании приложений.

Репозитории предоставляют удобное решение для доступа к данным.

Однако за многолетний опыт разработки, побывав в нескольких компаниях, сменив кучу проектов я НЕ ВСТРЕЧАЛ паттерн "Спецификация" совместно с паттерном "Репозиторий".

Подробный туториал по процессам записи и чтения данных в мапах Go. Объясняем проблемы переполнения, эвакуации элементов; важность передачи количества элементов при создании мапы. Рассказываем, почему в Go нельзя обращаться к ключу или значению по адресу.

Уже 3 года я фрилансер 1С.

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

Я веду свой блог где описываю свою практику работы с 1С. Поэтому недостатка в критиках у меня нет.

Хочу объяснить свою позицию.

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

Статья будет интересна тем, кто анализирует бизнес-процессы и создаёт их с нуля.

В последнее время достаточно много выступлений, посвященных реализации подходов Domain Driven Design(DDD) в golang.

Я не буду останавливаться на value object, они в golang хорошо реализуются с помощью type defintions. А разберу работу с изменением аггрегатов.

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

«И для отрицания такой среды мы имеем авторитет тех древнейших и знаменитейших философов древней Греции и Финикии, которые сделали вакуум, атомы и тяготение атомов первыми принципами своей философии, молчаливо приписывая тяготение какой-то иной причине, чем плотная материя. Позднейшие философы отбрасывают рассмотрение такой причины… придумывая [вместо неё] гипотезы для механического объяснения всего сущего [Но] главное дело натурфилософии — без притворных гипотез доказывать явления, выводить причины из следствий, пока мы не придём к самой первой причине, которая, конечно, не механическая.»

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

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

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

Я далек от того, чтобы делать какие-либо моральные оценки этому явлению (если
прочтете до конца, поймете, почему).  Я – тимлид с 15-летним опытом работы в IT. Я лично нанимал многих людей и со многими прощался. У меня есть своя приличная статистика откровенных мыслей и настроений людей, которые со мной работали, работают, или работают, но не со мной. На основании этого своего опыта (и не только своего) я попытаюсь дать ответ на вопрос, как и почему вырастает фига в кармане программиста. Я потяну за ниточку клубка причин и постепенно попытаюсь его распутать целиком. Результатом будет сводный граф причин феномена саботажа в IT. Поехали!

Как пользователь я хочу изменить ФИО и email в системе.

string ExecuteUseCase() 
{ 
  var request = receiveRequest();
  validateRequest(request);
  canonicalizeEmail(request);
  db.updateDbFromRequest(request);
  smtpServer.sendEmail(request.Email);
  return "Success";
}

let executeUseCase = 
  receiveRequest
  >> validateRequest
  >> canonicalizeEmail
  >> updateDbFromRequest
  >> sendEmail
  >> returnMessage

Что такое чистый код? Это то, что все ищут, но никто не может найти. Люди редко могут сойтись на том, что это такое и как это реализовать на практике. Можно найти бесчисленное число статей на эту тему, и эта станет ещё одной. Я попытаюсь разобраться в том, что такое чистый код сам по себе, в отрыве от языков, парадигм и сфер применения. 

Разделяй и влавствуй, или как провести клининг легаси-кода GoLang.

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

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

Что касается подхода к «чистой» архитектуре, описываемого далее, то это симбиоз двух идей: разделение Ports и Adapters, а также контроль за тем, как пакеты ссылаются друг на друга...