Организованное программирование | Кирилл Мокевнин

В этом выпуске мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg. Затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне процессора.
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.

Альтернативные площадки: ВК Видео | Подкаст

https://youtu.be/BsNgohFW6rM

Ruby, Ruby, Ruby. В этом выпуске мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails.
В подкасте обсудили:
- Современное состояние языка Ruby, его развитие и применение в больших проектах
- Подходы к созданию устойчивой архитектуры приложений на Ruby и опыт использования языка в open-source проектах
- Эволюцию фреймворка Ruby on Rails, включая новые возможности, такие как асинхронная обработка
- Личный опыт Владимира в разработке таких проектов, как AnyCable, и его вклад в создание инструментария для разработчиков

https://www.youtube.com/watch?v=fBJGj6sd9AQ (первый раз запустили видео как премьеру, можно там прямо в процессе обсуждать)

VK: https://vk.com/orgprog Подкасты: https://podcast.ru/1734325321

Makefile: Заменяем документацию командами

Когда-то много лет назад, я задолбался писать длинные и составные команды, которые были нужны в разных проектах. Особенно актуальной эта проблема стала с появлением Docker и Docker Compose. Некоторые связки для запуска, апдейта и изменений, требовали прямо таки серьезных многострочников. Типа такого:


docker run -it --rm \
-v $(CURDIR):/runner/project \
quay.io/ansible/ansible-runner ansible-vault edit


Выходов из этой ситуации было несколько, например, скидывать их куда-то в доку типа README.md и копировать оттуда. Частично мы так и делали, но оно все время устаревает и просто задалбывает.

Часть команд можно запихнуть во встроенный инструментарий языков, к ним относятся rake tasks, npm scripts и так далее. И это даже хорошо работает, но только до тех пор пока команды простые и скорее относятся к инструментам на этом же языке. Если ваша задача запустить подряд пяток команд Docker Compose, то большинство этих инструментов будут неудобными. Да это пытаются решить тем что создают универсальные запускалки, но ни одна из них не стала по настоящему популярной сквозь разные экосистемы. Почти все эти инструменты носят локальный характер для какого-то языка или конкретного стека.

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

Другой подход это алиасы в bash/zsh/fish. Но мне эта идея никогда не нравилась, потому что алиасы глобальны, а большая часть команд локальна для какого-то проекта. Несмотря на это алиасы все же заняли свое место в этой системе, но не рукопашные, а те что идут в коробке из ohmyzsh. Далеко не все знают, но это по сути ключевая фича этого инструмента. Вы только посмотрите, что он позволяет делать с гитом https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git (а там есть комбо для всех популярных консольных утилит).

Ну и наконец, самый, как оказалось удобный подход. У нас есть старый добрый Make, который либо стоит уже сразу, либо крайне просто ставится в систему. У него есть команды, зависимости и возможность писать консольные команды напрямую (для большинства ситуаций). Еще году в 2015 я полностью перевел все свои проекты на Makefile, которые не просто решили проблему написания и запуска команд, но и создали некий универсальный язык, заменяющий доку. В любом моем проекте открыв Makefile можно понять все, что нужно для работы с проектом: make setup, make test, make lint, make run все эти команды универсальны независимо от стека.


include make-app.mk
include make-compose-app.mk
include make-compose.mk
include k8s/Makefile

project-setup: ansible-generate-env compose-setup

ansible-generate-env:
docker run --rm -e RUNNER_PLAYBOOK=ansible/development.yml \
-v $(CURDIR)/ansible/development:/runner/inventory \
-v $(CURDIR):/runner/project \
quay.io/ansible/ansible-runner


Прикольно то, что со временем это стали видеть многие и даже популярные проекты стали внедрять Makefile. Я помню был пост Андрея Ситника, где он рассказывал, как перевел команды для своей либы с npm scripts на Makefile и был удивлен как все упростилось.

В общем рекомендую. Мое видео на тему: https://www.youtube.com/watch?v=pK9mF5aK05Q

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

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

- Простота и лаконичность Go как основы его философии.
- Влияние Google на развитие языка и баланс между минимализмом и новыми возможностями.
- Рынок Go-разработчиков, востребованность специалистов и нишевые преимущества языка.
- Сравнение Go с другими языками, такими как Rust и Python, для разных типов задач.
- Проблемы обратной совместимости и подходы к оптимизации производительности.
https://www.youtube.com/watch?v=M5XJ_Ojjm8M

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

Как я надел очки

У меня всегда было хорошее зрение несмотря на то, что где-то лет с 12 я плотно подсел на компы, а потом и на экран телефона. Несколько лет назад, доктор меня предупредил, что где-то ближе к 40, оно начнет портится, это нормальный процесс, через который проходят все. Сейчас мне 39 и ухудшение пока не заметно слава богу, но морально я готов. Несмотря на это, я уже ношу очки, возможно вы замечали в подкастах.

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

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

p.s. кстати кому интересно, я после долгого изучения reddit купил себе warby parker. Была еще попытка взять недорогие с амазона, но они быстро поцарапались.

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

В поисках идеального UI KIT

Решил на выходных провести время с пользой и перевести code-basics на inertiajs + react + ts + новый ui kit. И неожиданно для себя, уткнулся в проблему с последним. После нескольких дней плотного изучения и попыток внедрить какое-то количество решений, я уперся что для моих задач бутстрап по прежнему на коне.

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

Кто, то скажет, Кирилл погоди, но он же не может вот это, там нельзя вот так и вообще. И у меня есть что на это скзазать. Во-первых, многие до сих пор в голове представляют себе bootstrap 3, где кастомизация была слабая. Начиная с 4 версии и особенно в 5, он очень гибкий для готового набора компонентов. Мало кто например догадывается что на хекслете бутстрап, а в стандартных вещах (не лендах) там почти нет кастома (и это за 11 лет жизни проекта). Во-вторых, я на нем делаю свой проект, где нет абстрактного бизнеса, который может что-то захотеть, что бутстрап не может (картинка: я и есть бизнес). С самого начала была выбрана стратегия подстраиваться под него (кроме лендов), чтобы не тратить время и деньги на UI.

И, в общем, я бы и дальше продолжил им пользоваться без тени сомнения, если не вот эти. но:

- Так как проект переводится на inertia + react, то весь фронтенд уезжает в jsx, а там нужны не классы, а нормальные react компоненты с поддержкой ts и местами логикой (какие-нибудь модалки). У бутстрапа нет своей либы для этого. Есть react-bootstrap, но его делают энтузиасты в свободное от работы время. В общем ненадежно и с отставанием
- Все же сейчас в bootstrap компонентов меньше чем хотелось бы и они как-то не горят их добавлять. Всякие хитрые селекты, автокомплиты и более навороченные с точки зрения UI штуки. Не хочется ходить все это ставить со стороны и заниматься интеграциями (до сих пор мучаемся с select2 для автокомплита).
- Этот пункт меня не радует, но против массы не попрешь. Любая технология проходит путь с восходом и затмением, которое часто связано с приходом нового поколения, отрицающего все старое. Бутстрап, чтобы он не делал, уже отслужил свое в головах большинства. И чем дальше, тем меньше шансов найти кого-то кто от него в восторге. Пофиг даже если человек не работал с ним, это легко наверстать, но вот это ощущение, что это что-то старое, с чем не хочется возиться.

Вот с такими мыслями я засел вечером в пятницу за комп. Загуглил все что есть из популярного chakra, material, mantine, tailwind и все что на базе него daisyUI, nextUI, shadcn, ant.design, primereact, fluentui, blueprint, baseweb.design. Кроме этого видел еще десяток, но по коммитам, звездам и форкам они не вызывают доверия. Слишком высок риск что их забросят.

Изучил их доку, половину попробовал поставил и немного поверстал. В конце-концов выработал такой алгоритм поиска:

- Проверяю есть ли компонент navbar. Если его нет, то либа заставит меня делать то, от чего я хочу уйти
- Смотрю на верстку navbar, если это просто набор элементов из которых собирается navbar, то это не bootstrap-style конструктор. Это скорее конструктор компонентов типа tailwind. Navbar, который мне нужен, это прямо компонент в этом UI Kit с поддержкой схлопывания до бургера, дропдаунов и всего такого
- Смотрю наличие готовых блоков/сниппетов/примеров страниц. Я работаю без дизайнера и мне нужно видеть примеры компоновок компонентов и страниц.
- Ну и конечно же дока. Кто видел доку бутстрапа, понимает что такое хорошее описание.

Нашел ли я что-то идеальное? К сожалению нет. Пытаюсь завести mantine, так как он ближе всех отвечает моим запросам. Но в целом, мир UI хочет чтобы я был фанатом гибкости и кастомизации :)

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

В этом выпуске мы поговорили с Кирой Кузьменко, которая поделилась своим опытом и взглядом на современные реалии IT-рынка. Обсудили, как меняются ожидания работодателей, почему мультифункциональность стала ключевым навыком, и что нужно, чтобы оставаться востребованным специалистом.
https://www.youtube.com/watch?v=36v3KnpmZyM

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

Принятие решение по новым проектам

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

1. Версионирование документов
2. Систему прав
3. Восстановление удаленных вещей из корзины
4. Какую-нибудь аналитическую систему

Особенность всех эти штук, в том, что для них надо продумать ux и какую-то архитектуру, которая позволит потом это поддерживать расширять и вот это все. И каждую из подобных фич можно напилить самостоятельно. Но, по опыту, это часто получается довольно криво, особенно если фичи не продуманы со стороны UX и разработчикам приходится самим принимать решение как это сделать. На выходе мы получим что-то не очень удобное в использовании и потом нас ждет череда переписываний (справедливости ради, это произойдет в любом случае)

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

Что происходит с ютубом?

Ребят, расскажите что там на самом деле. Надо переживать или работает? Где вы щас смотрите видео? Как вы смотрите мои выпуски?

На всякий куда подписаться, чтобы не пропускать выпуски:

https://vk.com/orgprog
https://rutube.ru/channel/35573563/
https://dzen.ru/orgprog
https://podcast.ru/1734325321
https://vk.com/orgprog

В этом выпуске мы поговорили с Андреем Апанасиком о современном геймдеве, его вызовах и трендах. Обсудили, почему разработчики всё чаще выбирают готовые игровые движки вроде Unreal Engine и Unity вместо создания собственных решений. Андрей поделился своим опытом разработки игр, рассказал о том, как меняются подходы к созданию геймплея и почему маркетинг стал ключевым элементом успеха в игровой индустрии.
https://youtu.be/ZBgRe8FOvx0

Профессиональное развитие. Нам это не задавали

Чья ответственность заниматься своим развитием? Компании или человека? Многие ответят “конечно человека” и будут правы. Да компания может этому способствовать, но может и не способствовать, однако это не может и не должно нас останавливать.

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

В теории звучит просто, на практике же получается как-то не так. Собеседуешь человека и он говорит “я этого не знаю потому что в компании у нас этого нет”. Часто такое говорят про умение писать тесты (но это просто пример, не закливаемся на тестах). И речь не идет про человека, который всего полгода в продакшене, у него за спиной только одна компания и он просто еще не успел этого набраться. Я говорю про людей с большим багажом за спиной и многими годами работы в разных проектах.

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

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

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

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

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

Пошли первые ласточки по нашему видео продакшену, зацените: https://www.youtube.com/shorts/sLU4az5m_zg Как вам? Постить я сюда их не буду, потому что по плану мы будем делать 10-20 шорстов в месяц. Кстати, там на видео я как будто смотрю в камеру, на самом деле это обработка.

В этом выпуске мы с Андреем Ситником. обсудили будущее фронтент разработки и большой сдвиг в сторону баз данных на клиенте с автоматической синхронизацией вместо классических апи вызовов. Или короче, поговорили о движках синхронизации. Андрей рассказал про движение Local First, которое предлагает ряд принципов создания веб-приложений, одновременно решающих задачи владения данными и совместной работой. Благодаря движкам синхронизации, Local First приложения получают возможность работать офлайн и хранить свои данные там где нужно, не завязываясь на конкретный, обычно облачный, провайдер. Это позволяет строить более быстрые, безопасные и защищенные в плане владения данными приложения. https://www.youtube.com/watch?v=-57r5AARRgY

Провел сегодня прямой эфир https://www.youtube.com/watch?v=6FXLzctHGRM Оч рекомендую если вы пытаетесь понять логику работадателей при принятии решений о найме новичков и не только