Один из плюсов Котлина легко превращается в минус. Я про "почти все операторы возвращают значения". Вот конкретно из-за этого участка кода я минут 30 не мог понять почему всё работает не так как надо.

Всё дело в забытом "return" перед when. Кстати, в PHP тоже добавили match - вполне могут быть такие же коллизии.

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

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

Давно пора обновить документацию, сделать видео-туториал по плагину, но как программист-недобизнесмен, приоритет отдаю фичам, чем “всякой ерунде”. И нехватка этой “ерунды” начинает сказываться. Куча жалоб на то, что люди тупо не знают всех фич. Думаю, в том числе и поэтому рост продаж замедлился. В декабре 2021 продажи выросли в два раза по сравнению с декабрем 2020, но всего на 20% от марта 2021. Рост этот вполне можно назвать органическим, поскольку единственный промоушен - это твиттер, в котором пишу новые фичи, и спонсирование Laracon Online.

Поэтому в 2022 в первую очередь надо будет заняться тем, что программисту делать ну никак не хочется: документацией, видео-туториалами, сайт переделать, чтобы народ перестал думать, что если поставить laravel-ide-helper и старый плагин Laravel к шторму, то это будет почти как Laravel Idea. Еще надо будет и SEO, и может какие рекламы покрутить… такая скукота, но если уж начал строить бизнес, то надо строить.

Есть планы еще один платный плагин выпустить, на этот раз уже для всех языков и IDE от JetBrains, только надо подумать о модели монетизации. Она наверняка будет freemium, но надо придумать при каких условиях надо за него деньги брать и сколько брать. Весьма непростое решение и нет особо данных на что опереться при обдумывании. Опять придется тыкать пальцем в небо. И как-то выкраивать время!

В общем, с наступающим новым годом 🙂

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

В твиттере вон дискуссия на эту тему - https://twitter.com/frankdejonge/status/1482652993753333761 . Для PHP-пакета это довольно просто делается - https://github.com/thephpleague/flysystem/blob/3.x/.gitattributes#L29, но топорно. (“Просто, но топорно” - это вообще девиз многих PHP решений). Назовешь случайно класс StubbornUnicorn и он не попадет в экспорт пакета.

Для Явы/Котлин решение не особо простое, похоже. В лоб не загуглил. Поищу еще.

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

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

Ключевое слово “эффективно”. Лениво улучшать тоже все могут 🙂

Я частенько говорю, что ООП в его очищенном от любой процедурщины виде превращается в аналог функционального программирования. И вот эти куски кода плагина отлично это показывают. Вся логика здесь строится из комбинаций разных обьектов друг с другом, и всё выглядит как комбинация функций в ФП. Эдакое программирование конфигурацией.

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

Завтра утром в 11 по москве будет стрим про итоги 2021 года с результатами большого опроса PHP-программистов. Свыше 3000 ответов. Будет разыграно куча мерча и других подарков. Я лицензию на Laravel Idea добавил в общак(как же легко дарить нефизические, легко воспроизводимые, подарки).

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

Ссылка на страницу - https://phpcommunity.ru/2021-php
Ссылка на будущий стрим - https://www.youtube.com/watch?v=Nx39a7n9KIQ

Друзья, сегодня Юлия Insolita ушла из жизни.

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

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

Друзья, берегите себя и близких, будьте здоровы.

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

С одной стороны все верно. С другой - никогда не надо забывать, что все в нашей отрасли “зависит от проекта”. Для проекта на поддержке на второсортной галере мои действия были бы преступлением. Для простого сайтика - наверно тоже. Для моего продукта(Laravel Idea) - нет.

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

Мораль - всегда все зависит от проекта и каждое решение надо оценивать не только в краткосрочной, но и в долгосрочной перспективе.

Если кого интересуют детали, то у меня было несколько источников информации о том, где и под каким неймспейсом и с какими расширениями файлов лежат view-файлы. Настройки плагина, код в ServiceProvider-классах и еще ide.json файлы. Все это лежало в разных частях кода и как-то умело работать. Небольшая фича - вызов View::addExtension() метода в сервис провайдере, который добавляет расширения файлов, которые Laravel считает вьюшками. Хотелось его подхватывать самому, чтобы юзеру не надо было лазить в настройках. После рефакторинга вся необходимая информация про вью-файлы аккумулируется из разных источников в один обьект, который знает про вьюшки все и умеет делать все необходимое.

Объектное ориентирование в массы! Даешь Объекты-значения вместо примитивов!

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

Рефакторю немного Laravel Idea…

класс, кстати, выглядит весьма чистенько.

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

Это бомба замедленного действия. Когда-нибудь все равно долбанет. Появится новое требование и все это взорвется комбинаторным взрывом 🙂 Так оно произошло сейчас у меня, причем я даже не подозревал проблему пока это не случилось.

Все эти куски логики - отдельные обьекты. If - это либо фабрики, либо декораторы. Как только все это раскидаешь по правильным обьектам - станет сильно легче дышать.

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

Такое чувство, что люди очень странно понимают слова “more expressive”. Первый вариант четко говорит о том, что будет возвращен обьект редиректа на такой-то роут. А Нуно здесь очень понравилось “return to_route”, но это больше прикольно, чем реально полезно.

И, конечно, комменты в стиле “ОГО! Я теперь могу писать на несколько символов меньше!”. 🙊 Сразу видно, кто использует продвинутые средства разработки, а кто нет )

Лара-коммунити частенько так удивляет…

Берем камень и отсекаем все лишнее

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

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

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

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

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

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

Вместо этого можно использовать Ctrl(Cmd)-E и просто выключить вкладки за ненадобностью. В том же окошке очень хорошо работает поиск. Крайне рекомендую.

Убрать вкладки: Preferences(Settings) | Editor | General | Editor Tabs | Tab placement: None.

Всегда старался уделять время таким вот фичам. Не сказать, что сэкономят много времени, но некий вау-эффект(“Ого какой софт умный!”) - он важен.

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

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

Если вдруг кто-то захочет почитать главу - https://github.com/adelf/acwa_book_ru/blob/master/manuscript/1-bad-habits.md

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

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

Мотивация путем уменьшения неопределенности

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

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

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

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

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