Чтож, пришла пора подводить итоги года нашего уютного канала. В целом можно сказать, что год был для него неплох. Органически канал вырос на 5 тыщ подписчиков и дошел до 8500. До 10 тыщ не добрали, но ничо.

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

Самое интересное это миллион просмотров и 7 тыщ комментов на 173 поста!!! Это товарищи дохрена. Почти инфлюенсер :)

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

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

Всем добра и мира, до новых встреч. Ну и поставьте чтоли сердечко, если канал в него попал :)

p.s. Боты, от вас тоже жду теплых слов

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

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

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

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

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

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

А с какого ритуала у вас начинается утро за компьютером? Я обновляю плагины в виме :)

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

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

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

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

А нука ребята, кто сразу наметанным взглядом скажет какую типовую orm проблему мы тут наблюдаем?

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

Что такое CodeBasics

Я планирую серию постов, про архитектуру нашего открытого проекта https://code-basics.com/ru, о котором сейчас немного расскажу. Где-то в 2015 году, задумал я сделать проект в стиле CodeAcademy как дополнение к Хекслету. То есть это простые курсы по основам языков с тренажером в браузере. Ключевые фишки проекта:

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

Целей было несколько. Например на тот момент, рекомендовать кому-то платные курсы было зашкваром (сразу считалось рекламой), поэтому программисты тупо стеснялись говорить про Хекслет даже если хотели. Этот проект открывал такую возможность всем без риска, что тебя заклюют. И еще я оглядывался на не безызвестный сайт learn.javascript.ru, мне хотелось добиться похожей популярности по ряду языков, чтобы например когда речь шла про то где учить php, все не задумываясь отвечали, конечно на кодбейзиксе (я все еще мечтаю об этом!).

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

У проекта есть несколько интересных вещей с архитектурной точки зрения, о которых хочется рассказать. Например то, как мы переложили работу с контентом на гитхаб, решив множество задач без кодинга (права, версионирование итп). Про то как устроена база данных, так чтобы иметь версионирование уроков и не ломать людям все сразу при обновлении курсов. Про то как мы его написали на phoenix/elixir, а потом переписали на rails. В общем там реально много интересных концепций. А прямо сейчас я его еще переписываю на инерацию, так что будет что рассказать про фронтендовые примочки в новой реальности.

Короче не проект, а сказка. А на днях мы вышли с ним https://productradar.ru/ это типа нашего продуктханта. Эту неделю идет голосование за лучший проект и мы там вчера вышли на первое место с 104 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)

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

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

https://youtu.be/BsNgohFW6rM

Про менеджеры версий

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

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

Начать можно отсюда: https://asdf-vm.com/guide/getting-started.html

// Вариант установки для brew

// Ставим asdf и зависимости
brew install asdf

// Ставим плагин для ноды
asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
// И его зависимости
brew install gpg gawk

// Устанавливаем последнюю версию nodejs и делаем ее доступной глобально
asdf global nodejs latest

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

p.s. А какой менеджер версий используете вы?

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

В этом выпуске мы снова встретились с Дмитрием Коваленко, чтобы разобраться, почему Rust заслужил столько внимания в сообществе разработчиков. Получился содержательный и насыщенный разговор, полезный и начинающим, и опытным специалистам.
Присоединяйтесь, чтобы узнать, чем Rust может усилить ваш tech stack и как писать надёжный, эффективный код!

https://www.youtube.com/watch?v=bKyxOaP-mDg

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

Идеальное решение

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

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

Может быть и так, но если исходить сразу из ограничений, то мы никогда не придем туда, куда надо идти, с точки зрения смыслов, что может нас сильно замедлить и ослабить по отношению к конкурентам. Вместо выставления границ, лучше поступить по другому. Сначала мы можем представить, что нет никаких ограничений и мы можем сделать все что хотим моментально. Каким бы тогда выглядело наше решение? Идеальное решение. Что в него входит:

* Система выполняет функцию с минимальным количеством ресурсов
* Противоречия устраняются максимально элегантно

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

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

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

Кто-то скажет, Кирилл погоди, это же из ТРИЗ и будет прав. Там это называется Идеальный Конечный Результат (ИКР).

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

У меня пропал сон

Где-то лет в 35 со мной что-то случилось. Я стал просыпаться в 6 независимо от того во сколько я уснул. Что самое страшное у меня пропала способность “доспать” если я не выспался. Вообще никаких шансов, проснулся - вставай, потому что иначе будешь тупо лежать, но не уснешь. Всегда раньше удивлялся бабушкам и дедушкам, которые так в 4 вставали. А теперь сам такой стал. У вас есть такой эффект?

В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают стабильность и масштабируемость в самых требовательных системах.

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

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

Собеседования: Истории и раздражающие практики

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

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

Написал мощную статью на хабр про то как на самом деле надо собеседовать разработчиков. Вложил туда так сказать весь опыт с 2009 года, когда я начал впервые собеседовать и с тех пор провел более 1000 собесов! https://habr.com/ru/articles/879902/ не забудьте поделиться с друзьями ;)