Как я надел очки
У меня всегда было хорошее зрение несмотря на то, что где-то лет с 12 я плотно подсел на компы, а потом и на экран телефона. Несколько лет назад, доктор меня предупредил, что где-то ближе к 40, оно начнет портится, это нормальный процесс, через который проходят все. Сейчас мне 39 и ухудшение пока не заметно слава богу, но морально я готов. Несмотря на это, я уже ношу очки, возможно вы замечали в подкастах.
Где-то, лет 15 назад, я понял что сидение за экраном делает больно моим глазам. Это связано с тем, что глаза начинают редко моргать и увлажняться + постоянная фокусировка на предметы близко к лицу. Поэтому существует множество разных рекомендаций, от регулярного отрыва от экрана и рассматривания предметов в далеке (но ни в коем случае не вращение глаз) до использования капель и спец очков с антибликовым и другими покрытиями.
В общем, ощущение что в глаза насыпали песок было настолько сильным, что я не мог просидеть больше 20 минут. Проблему решили глазные капли, но я быстро устал их использовать, капать каждый день по несколько раз в день годами, это то еще удовольствие. Поэтому я пошел в салон и купил очки. Проблема ушла где-то на 10 лет, пока ребенок мне однажды не сломал их. Глаза вроде не болели, поэтому я ничего не стал делать, а продолжил работать без них. Да и за компом я уже проводил меньше времени, а на созвонах они вроде и не нужны. Но буквально года полтора назад, я снова почувствовал что глазам плохо уже не только за компом, но и просто за просмотром экрана телефона. К боли добавилось то, что экран стал размытым, правда только для одного глаза. Вот тут то и накатила паника, а может это конец? Пришлось с одной стороны уменьшить время за техникой и всегда включать яркий свет когда смотрю в экран. Это помогло только частично, поэтому пришлось идти дальше и покупать капли. В конце концов, я плюнул и снова заказал очки. И только после этого все прошло. Но теперь, в отличие от прошлого опыта, я ношу очки не только когда сижу за компом, но и когда смотрю в телефон. А по итогу я ношу их большую часть времени дня. Работаем дальше.
p.s. кстати кому интересно, я после долгого изучения reddit купил себе warby parker. Была еще попытка взять недорогие с амазона, но они быстро поцарапались.
Ссылки: Телеграм | Youtube | VK
У меня всегда было хорошее зрение несмотря на то, что где-то лет с 12 я плотно подсел на компы, а потом и на экран телефона. Несколько лет назад, доктор меня предупредил, что где-то ближе к 40, оно начнет портится, это нормальный процесс, через который проходят все. Сейчас мне 39 и ухудшение пока не заметно слава богу, но морально я готов. Несмотря на это, я уже ношу очки, возможно вы замечали в подкастах.
Где-то, лет 15 назад, я понял что сидение за экраном делает больно моим глазам. Это связано с тем, что глаза начинают редко моргать и увлажняться + постоянная фокусировка на предметы близко к лицу. Поэтому существует множество разных рекомендаций, от регулярного отрыва от экрана и рассматривания предметов в далеке (но ни в коем случае не вращение глаз) до использования капель и спец очков с антибликовым и другими покрытиями.
В общем, ощущение что в глаза насыпали песок было настолько сильным, что я не мог просидеть больше 20 минут. Проблему решили глазные капли, но я быстро устал их использовать, капать каждый день по несколько раз в день годами, это то еще удовольствие. Поэтому я пошел в салон и купил очки. Проблема ушла где-то на 10 лет, пока ребенок мне однажды не сломал их. Глаза вроде не болели, поэтому я ничего не стал делать, а продолжил работать без них. Да и за компом я уже проводил меньше времени, а на созвонах они вроде и не нужны. Но буквально года полтора назад, я снова почувствовал что глазам плохо уже не только за компом, но и просто за просмотром экрана телефона. К боли добавилось то, что экран стал размытым, правда только для одного глаза. Вот тут то и накатила паника, а может это конец? Пришлось с одной стороны уменьшить время за техникой и всегда включать яркий свет когда смотрю в экран. Это помогло только частично, поэтому пришлось идти дальше и покупать капли. В конце концов, я плюнул и снова заказал очки. И только после этого все прошло. Но теперь, в отличие от прошлого опыта, я ношу очки не только когда сижу за компом, но и когда смотрю в телефон. А по итогу я ношу их большую часть времени дня. Работаем дальше.
p.s. кстати кому интересно, я после долгого изучения reddit купил себе warby parker. Была еще попытка взять недорогие с амазона, но они быстро поцарапались.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
January 2
В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка Go и его роли в современном программировании. Разобрали, как Go стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков. Также обсудили, как новые фичи, такие как дженерики и итераторы, меняют подход к разработке.
- Простота и лаконичность Go как основы его философии.
- Влияние Google на развитие языка и баланс между минимализмом и новыми возможностями.
- Рынок Go-разработчиков, востребованность специалистов и нишевые преимущества языка.
- Сравнение Go с другими языками, такими как Rust и Python, для разных типов задач.
- Проблемы обратной совместимости и подходы к оптимизации производительности.
https://www.youtube.com/watch?v=M5XJ_Ojjm8M
Альтернативные ссылки: VK | Аудио
- Простота и лаконичность Go как основы его философии.
- Влияние Google на развитие языка и баланс между минимализмом и новыми возможностями.
- Рынок Go-разработчиков, востребованность специалистов и нишевые преимущества языка.
- Сравнение Go с другими языками, такими как Rust и Python, для разных типов задач.
- Проблемы обратной совместимости и подходы к оптимизации производительности.
https://www.youtube.com/watch?v=M5XJ_Ojjm8M
Альтернативные ссылки: VK | Аудио
YouTube
Дженерики, горутины и перспективы Go: взгляд изнутри | Алексей Палажченко | #26
В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка Go и его роли в современном программировании. Разобрали, как Go стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков.…
January 5
Организованное программирование | Кирилл Мокевнин pinned «В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка Go и его роли в современном программировании. Разобрали, как Go стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков.…»
January 7
Makefile: Заменяем документацию командами
Когда-то много лет назад, я задолбался писать длинные и составные команды, которые были нужны в разных проектах. Особенно актуальной эта проблема стала с появлением Docker и Docker Compose. Некоторые связки для запуска, апдейта и изменений, требовали прямо таки серьезных многострочников. Типа такого:
Выходов из этой ситуации было несколько, например, скидывать их куда-то в доку типа 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 все эти команды универсальны независимо от стека.
Прикольно то, что со временем это стали видеть многие и даже популярные проекты стали внедрять Makefile. Я помню был пост Андрея Ситника, где он рассказывал, как перевел команды для своей либы с npm scripts на Makefile и был удивлен как все упростилось.
В общем рекомендую. Мое видео на тему: https://www.youtube.com/watch?v=pK9mF5aK05Q
Ссылки: Телеграм | Youtube | VK
Когда-то много лет назад, я задолбался писать длинные и составные команды, которые были нужны в разных проектах. Особенно актуальной эта проблема стала с появлением 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
January 7
January 8
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
В подкасте обсудили:
- Современное состояние языка Ruby, его развитие и применение в больших проектах
- Подходы к созданию устойчивой архитектуры приложений на Ruby и опыт использования языка в open-source проектах
- Эволюцию фреймворка Ruby on Rails, включая новые возможности, такие как асинхронная обработка
- Личный опыт Владимира в разработке таких проектов, как AnyCable, и его вклад в создание инструментария для разработчиков
https://www.youtube.com/watch?v=fBJGj6sd9AQ (первый раз запустили видео как премьеру, можно там прямо в процессе обсуждать)
VK: https://vk.com/orgprog Подкасты: https://podcast.ru/1734325321
YouTube
Руби против всех: язык, который пережил свою эпоху и вернулся сильнее | Владимир Дементьев | #27
В этом выпуске подкаста "Организованное программирование" мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails. Владимир поделился своим опытом работы с языком Ruby, рассказал о своей…
January 12
Организованное программирование | Кирилл Мокевнин pinned «Ruby, Ruby, Ruby. В этом выпуске мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails. В подкасте обсудили: - Современное состояние языка Ruby, его развитие и применение в больших проектах…»
January 13
Что такое CodeBasics
Я планирую серию постов, про архитектуру нашего открытого проекта https://code-basics.com/ru, о котором сейчас немного расскажу. Где-то в 2015 году, задумал я сделать проект в стиле CodeAcademy как дополнение к Хекслету. То есть это простые курсы по основам языков с тренажером в браузере. Ключевые фишки проекта:
- Исходный код проекта открыт и выложен на гитхабе
- Курсы создаются не только нами, но и сообществом там же на Гитхабе
- Все бесплатно без исключений
Целей было несколько. Например на тот момент, рекомендовать кому-то платные курсы было зашкваром (сразу считалось рекламой), поэтому программисты тупо стеснялись говорить про Хекслет даже если хотели. Этот проект открывал такую возможность всем без риска, что тебя заклюют. И еще я оглядывался на не безызвестный сайт learn.javascript.ru, мне хотелось добиться похожей популярности по ряду языков, чтобы например когда речь шла про то где учить php, все не задумываясь отвечали, конечно на кодбейзиксе (я все еще мечтаю об этом!).
Большую часть курсов я написал на бейзиксе сам, но часть была написана ребятами из нашего сообщества. И это очень круто, потому что это позволило появиться на сайте курсам по лиспам и элексиру. Самая интересная история была, когда один парень нам нафигачил курс по python, а потом мы взяли его на работу (привет Леша!). На гитхабе проекта созданы репы под все языки, так что если вам интересно, то велкам, можно просто прийти и начать коммитить.
У проекта есть несколько интересных вещей с архитектурной точки зрения, о которых хочется рассказать. Например то, как мы переложили работу с контентом на гитхаб, решив множество задач без кодинга (права, версионирование итп). Про то как устроена база данных, так чтобы иметь версионирование уроков и не ломать людям все сразу при обновлении курсов. Про то как мы его написали на phoenix/elixir, а потом переписали на rails. В общем там реально много интересных концепций. А прямо сейчас я его еще переписываю на инерацию, так что будет что рассказать про фронтендовые примочки в новой реальности.
Короче не проект, а сказка. А на днях мы вышли с ним https://productradar.ru/ это типа нашего продуктханта. Эту неделю идет голосование за лучший проект и мы там вчера вышли на первое место с 104 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)
Я планирую серию постов, про архитектуру нашего открытого проекта https://code-basics.com/ru, о котором сейчас немного расскажу. Где-то в 2015 году, задумал я сделать проект в стиле CodeAcademy как дополнение к Хекслету. То есть это простые курсы по основам языков с тренажером в браузере. Ключевые фишки проекта:
- Исходный код проекта открыт и выложен на гитхабе
- Курсы создаются не только нами, но и сообществом там же на Гитхабе
- Все бесплатно без исключений
Целей было несколько. Например на тот момент, рекомендовать кому-то платные курсы было зашкваром (сразу считалось рекламой), поэтому программисты тупо стеснялись говорить про Хекслет даже если хотели. Этот проект открывал такую возможность всем без риска, что тебя заклюют. И еще я оглядывался на не безызвестный сайт learn.javascript.ru, мне хотелось добиться похожей популярности по ряду языков, чтобы например когда речь шла про то где учить php, все не задумываясь отвечали, конечно на кодбейзиксе (я все еще мечтаю об этом!).
Большую часть курсов я написал на бейзиксе сам, но часть была написана ребятами из нашего сообщества. И это очень круто, потому что это позволило появиться на сайте курсам по лиспам и элексиру. Самая интересная история была, когда один парень нам нафигачил курс по python, а потом мы взяли его на работу (привет Леша!). На гитхабе проекта созданы репы под все языки, так что если вам интересно, то велкам, можно просто прийти и начать коммитить.
У проекта есть несколько интересных вещей с архитектурной точки зрения, о которых хочется рассказать. Например то, как мы переложили работу с контентом на гитхаб, решив множество задач без кодинга (права, версионирование итп). Про то как устроена база данных, так чтобы иметь версионирование уроков и не ломать людям все сразу при обновлении курсов. Про то как мы его написали на phoenix/elixir, а потом переписали на rails. В общем там реально много интересных концепций. А прямо сейчас я его еще переписываю на инерацию, так что будет что рассказать про фронтендовые примочки в новой реальности.
Короче не проект, а сказка. А на днях мы вышли с ним https://productradar.ru/ это типа нашего продуктханта. Эту неделю идет голосование за лучший проект и мы там вчера вышли на первое место с 104 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)
January 15
В этом выпуске мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg. Затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне процессора.
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.
Альтернативные площадки: ВК Видео | Подкаст
https://youtu.be/BsNgohFW6rM
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.
Альтернативные площадки: ВК Видео | Подкаст
https://youtu.be/BsNgohFW6rM
VK Видео
Почему ассемблер остается актуальным в 2025 году? | Дмитрий Коваленко | #28
В этом выпуске подкаста мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg, затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне…
January 19
Про менеджеры версий
Когда надо сменить версию языка под проект, то для этого обычно используют либо докер, либо менеджеры версий. Под каждый язык есть как минимум один такой, а то и пачка: nvm, gvm, rvm, rbenv и так далее. Десятки их. В общем задолбаешься если постоянно надо между языками переключаться. Поэтому кто-то догадался написать универсальный менеджер.
Сейчас их уже два: asdf и mise. Первый появился раньше и я на него подсел много лет назад, второй более молодой и менее популярный. Пока не вижу причин на него пересаживаться, но посматриваю в его сторону, как минимум там не надо плагины для языков ставить.
Начать можно отсюда: https://asdf-vm.com/guide/getting-started.html
В принципе все. Плюс минус такое же для каждого языка. Под капотом, оно использует существующие менеджеры, а не переизобретает их. Поэтому, можно сказать, что asdf это унифицированный фронтенд ко всем популярным менеджерам версий.
p.s. А какой менеджер версий используете вы?
Ссылки: Телеграм | Youtube | VK
Когда надо сменить версию языка под проект, то для этого обычно используют либо докер, либо менеджеры версий. Под каждый язык есть как минимум один такой, а то и пачка: 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
January 25
В этом выпуске мы снова встретились с Дмитрием Коваленко, чтобы разобраться, почему Rust заслужил столько внимания в сообществе разработчиков. Получился содержательный и насыщенный разговор, полезный и начинающим, и опытным специалистам.
Присоединяйтесь, чтобы узнать, чем Rust может усилить ваш tech stack и как писать надёжный, эффективный код!
https://www.youtube.com/watch?v=bKyxOaP-mDg
Альтернативные площадки ВК Видео | Аудио
Присоединяйтесь, чтобы узнать, чем Rust может усилить ваш tech stack и как писать надёжный, эффективный код!
https://www.youtube.com/watch?v=bKyxOaP-mDg
Альтернативные площадки ВК Видео | Аудио
YouTube
Rust: зачем выбирать этот язык в 2025 году? | Дмитрий Коваленко | #29
В этом выпуске мы снова встретились с Дмитрием Коваленко, чтобы разобраться, почему Rust заслужил столько внимания в сообществе разработчиков.
Дмитрий подробно объяснил, как работает знаменитый borrow-checker, в чём преимущества языка без garbage-коллектора…
Дмитрий подробно объяснил, как работает знаменитый borrow-checker, в чём преимущества языка без garbage-коллектора…
January 26
Идеальное решение
Поделюсь техникой, которой я пользуюсь при решении разных технических и не только задач. Она помогает лучше проектировать и фокусироваться на смыслах, там где легко свернуть не туда из-за существующих ограничений. Что здесь имеется ввиду?
Когда мы что-то хотим сделать, то почти всегда, исходим из того, что у нас есть на текущий момент. Наличие каких-то ресурсов, например людей и времени, состояние кода, платформы и так далее. Причем речь идет даже не о технических деталях, а о постановке задачи, которая во время обсуждения обрастает разными “это невозможно”, “это долго”, “у нас так не сработает”, “тут уже работает не так”, “не заложено в архитектуру”.
Может быть и так, но если исходить сразу из ограничений, то мы никогда не придем туда, куда надо идти, с точки зрения смыслов, что может нас сильно замедлить и ослабить по отношению к конкурентам. Вместо выставления границ, лучше поступить по другому. Сначала мы можем представить, что нет никаких ограничений и мы можем сделать все что хотим моментально. Каким бы тогда выглядело наше решение? Идеальное решение. Что в него входит:
* Система выполняет функцию с минимальным количеством ресурсов
* Противоречия устраняются максимально элегантно
Получив такую картинку, можно начать двигаться в обратную сторону. Окей, а что из этого мы не можем сделать? Что придется сделать по другому? И так шаг за шагом приходим к решению, которое уже возможно реализовать в существующих условиях, но двигаемся к этому решению через призму того решения, к которому мы стремимся.
Как пример, у нас есть задача создать систему управления баннерами на сайте. Формулировка задачи на первом этапе производится на примере лучших известных решений на рынке с учетом наших хотелок. Затем на эту систему начинают накладываться ограничения реальной системы и ресурсов.
Зачем, спрашивается, тогда было нужно идеальное решение? Оно помогает фокусироваться на конечном результате, а не промежуточных или тех, которые могут увести нас в другую сторону. Иметь идеальное решение перед глазами полезно, чтобы не забывать куда мы все таки идем и даже в условиях ограничений, думать о том, как заложить в архитектуру возможность дойти таки до нашего идеального решения в конце концов.
Кто-то скажет, Кирилл погоди, это же из ТРИЗ и будет прав. Там это называется Идеальный Конечный Результат (ИКР).
Ссылки: Телеграм | Youtube | VK
Поделюсь техникой, которой я пользуюсь при решении разных технических и не только задач. Она помогает лучше проектировать и фокусироваться на смыслах, там где легко свернуть не туда из-за существующих ограничений. Что здесь имеется ввиду?
Когда мы что-то хотим сделать, то почти всегда, исходим из того, что у нас есть на текущий момент. Наличие каких-то ресурсов, например людей и времени, состояние кода, платформы и так далее. Причем речь идет даже не о технических деталях, а о постановке задачи, которая во время обсуждения обрастает разными “это невозможно”, “это долго”, “у нас так не сработает”, “тут уже работает не так”, “не заложено в архитектуру”.
Может быть и так, но если исходить сразу из ограничений, то мы никогда не придем туда, куда надо идти, с точки зрения смыслов, что может нас сильно замедлить и ослабить по отношению к конкурентам. Вместо выставления границ, лучше поступить по другому. Сначала мы можем представить, что нет никаких ограничений и мы можем сделать все что хотим моментально. Каким бы тогда выглядело наше решение? Идеальное решение. Что в него входит:
* Система выполняет функцию с минимальным количеством ресурсов
* Противоречия устраняются максимально элегантно
Получив такую картинку, можно начать двигаться в обратную сторону. Окей, а что из этого мы не можем сделать? Что придется сделать по другому? И так шаг за шагом приходим к решению, которое уже возможно реализовать в существующих условиях, но двигаемся к этому решению через призму того решения, к которому мы стремимся.
Как пример, у нас есть задача создать систему управления баннерами на сайте. Формулировка задачи на первом этапе производится на примере лучших известных решений на рынке с учетом наших хотелок. Затем на эту систему начинают накладываться ограничения реальной системы и ресурсов.
Зачем, спрашивается, тогда было нужно идеальное решение? Оно помогает фокусироваться на конечном результате, а не промежуточных или тех, которые могут увести нас в другую сторону. Иметь идеальное решение перед глазами полезно, чтобы не забывать куда мы все таки идем и даже в условиях ограничений, думать о том, как заложить в архитектуру возможность дойти таки до нашего идеального решения в конце концов.
Кто-то скажет, Кирилл погоди, это же из ТРИЗ и будет прав. Там это называется Идеальный Конечный Результат (ИКР).
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
January 28
У меня пропал сон
Где-то лет в 35 со мной что-то случилось. Я стал просыпаться в 6 независимо от того во сколько я уснул. Что самое страшное у меня пропала способность “доспать” если я не выспался. Вообще никаких шансов, проснулся - вставай, потому что иначе будешь тупо лежать, но не уснешь. Всегда раньше удивлялся бабушкам и дедушкам, которые так в 4 вставали. А теперь сам такой стал. У вас есть такой эффект?
Где-то лет в 35 со мной что-то случилось. Я стал просыпаться в 6 независимо от того во сколько я уснул. Что самое страшное у меня пропала способность “доспать” если я не выспался. Вообще никаких шансов, проснулся - вставай, потому что иначе будешь тупо лежать, но не уснешь. Всегда раньше удивлялся бабушкам и дедушкам, которые так в 4 вставали. А теперь сам такой стал. У вас есть такой эффект?
January 30
В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают стабильность и масштабируемость в самых требовательных системах.
Альтернативные ссылки ВК Видео | Аудио
https://www.youtube.com/watch?v=lpmZJ2xnsaE
Альтернативные ссылки ВК Видео | Аудио
https://www.youtube.com/watch?v=lpmZJ2xnsaE
VK Видео
Почему WhatsApp, Discord и другие гиганты выбирают Erlang? | Юрий Жлоба | #30
В этом выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Обсудили, почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса. Разобрали ключевые вопросы: — Как модель акторов…
February 2
Собеседования: Истории и раздражающие практики
Ребят, мне тут для одного материала нужно насобирать реальных кринж-треш-историй и практик используемых на собеседованиях, с которыми вы либо не согласны, либо вас прямо бесят. Например когда просят не пользоваться поиском, спрашивают про порядок аргументов в вызове функций (привет php!), интересуются кем вы видите себя через пять лет или почему выбрали нашу компанию. Короче все, что только можно. На днях, кстати, слышал как одного парня попросили пошарить экран, только для того, чтобы убедиться, что он не использует ИИ.
Ссылки: Телеграм | Youtube | VK
Ребят, мне тут для одного материала нужно насобирать реальных кринж-треш-историй и практик используемых на собеседованиях, с которыми вы либо не согласны, либо вас прямо бесят. Например когда просят не пользоваться поиском, спрашивают про порядок аргументов в вызове функций (привет php!), интересуются кем вы видите себя через пять лет или почему выбрали нашу компанию. Короче все, что только можно. На днях, кстати, слышал как одного парня попросили пошарить экран, только для того, чтобы убедиться, что он не использует ИИ.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
February 5
Организованное программирование | Кирилл Мокевнин pinned «В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают…»
February 5
Написал мощную статью на хабр про то как на самом деле надо собеседовать разработчиков. Вложил туда так сказать весь опыт с 2009 года, когда я начал впервые собеседовать и с тех пор провел более 1000 собесов! https://habr.com/ru/articles/879902/ не забудьте поделиться с друзьями ;)
Хабр
Проводим идеальное собеседование разработчика. Советы от практика с тысячей собеседований за спиной
Собеседование — это ключевой этап, определяющий, насколько кандидат подходит компании. Важно создать процесс, который не только выявит технические знания, но и покажет, насколько человек соответствует...
February 6
В сегодняшнем выпуске мы с Артёмом Арутюняном погрузились в тему стейт-менеджмента во фронтенде и функционального реактивного программирования.
Разберем реальные кейсы и технологические подходы, которые позволяют совершенствовать управление состоянием в современных веб-приложениях.
Альтернативные площадки ВК Видео | Аудио
https://www.youtube.com/watch?v=Lbq_NwIKUrI
Разберем реальные кейсы и технологические подходы, которые позволяют совершенствовать управление состоянием в современных веб-приложениях.
Альтернативные площадки ВК Видео | Аудио
https://www.youtube.com/watch?v=Lbq_NwIKUrI
VK Видео
Ключевые тренды 2025: что ждет стейт-менеджмент в будущем? | Артём Арутюнян | #31
В этом выпуске мы с Артёмом Арутюняном погрузились в тему стейт-менеджмента во фронтенде и функционального реактивного программирования. Разобрали ключевые вопросы: — Как современные подходы (например, концепция Local First) помогают решать проблемы синхронизации…
February 9
Организованное программирование | Кирилл Мокевнин pinned «В сегодняшнем выпуске мы с Артёмом Арутюняном погрузились в тему стейт-менеджмента во фронтенде и функционального реактивного программирования. Разберем реальные кейсы и технологические подходы, которые позволяют совершенствовать управление состоянием в современных…»
February 12
slim => inertiajs + react + vite в code-basics
Саммари по переезду с серверной шаблонизации на slim в code-basics на инерацию с реактом. Если кто пропустил напомню, концепция инерации в том, что она соединяет бек и фронт в классическом стиле для бекенд фреймворков. В экшенах контроллера передаются данные во вьюху, а вместо обычной серверной вьюхи, используется какой-либо фронтенд фреймворк, в моем случае реакт. Инерция концептуально работает как nest.js, но в качестве бека может выступать любой бекенд фреймворк для которого есть адаптер. Ключевые моменты:
* Используется серверный роутинг
* На фронтенде нет стора. Данные идут в пропсы
* По причине описанной выше, нет никакого API
Для меня это уже второе приложение в таком стиле. Сначала была приемка документов для колледжа, в разработке которой я участвовал три месяца. Теперь вот code-basics. В отдаленной перспективе, я планирую переводить на эту схему сам Хекслет.
Что хочу сказать. Изменения, которые надо вносить в бек для работы с инерцией минимальны. Главное отличие от рельсового подхода наверное в том, что если валидация не прошла, то инерции нужен редирект, а не рендеринг шаблона, как это принято в рельсе. Для этого адаптер инерции под рельсу идет с нужными хелперами, так что тут проблем нет.
Чуть усложнился проброс данных на фронтенд. В бекенде в шаблон можно передавать сами модели, так как это все происходит на сервере. На клиент уйдет только то, что мы реально будем использовать. В случае же инерции, данные целиком уходят на фронтенд, поэтому появляется промежуточный слой DTO, что вполне себе классика для большинства экосистем. В любом случае такой слой всегда присутствует при наличии API.
Либа для ресурсов (DTO), как и полагается в современном мире, умеет генерировать типы для TS, что очень помогает не дублировать и не описывать все ручками.
Лейаутинг и паршиалы на сервере, это особый механизм внутри шаблонизатора. С переходом на фронт, все это стало не актуально и самое главное, для этого ничего не нужно специального. Лейаут в реакте это просто компонент в который мы все оборачиваем. Да чуть больше кода в каждом конретном шаблоне, но явность тоже имеет свои плюсы.
Рельса предоставляет много удобных механизмов для серверных шаблонов, например офигенные формы, которые умеют работать с моделями. Это автоматизирует кучу вещей, от правильной обработки ошибок, интеграцию с i18n и многое другое. В новой схеме все это пришлось заводить руками. Инерция поставляется с хуками для обработки форм, но им далеко до рельсовых интеграций, поэтому пришлось напилить файл с формами. Для хранения строк я взял i18next, но сделал хитро. Я не стал дублировать и переносить переводы из бека, а заюзал либу, которая автоматом собирает все в json для фронта. Поэтому сами тексты описываются как обычно, но “магически” оказываются на фронтенде.
Примерно такая же история с роутингом. Чтобы не писать урлы ручками, я подключил либу js-routes, которая переносит описание всех маршрутов на фронтенд. Все это типизировано по самое нехочу
А что по внешнему виду? Тут многие знают что я предпочитаю бутстрап, но честно говоря, у меня была попытка найти что-то такое же высокоуровневое. В итоге из более менее подходящего оказался только https://primereact.org/, который можно подстраивать под свои стили. Сейчас в проекте часть компонентов взята из react-bootstrap, часть из primereact, например автокомплит или грид в админке.
Ну и нельзя не сказать про ssr. Так бы он и нафиг не сдался, но для проекта критично SEO, поэтому пришлось заводить. Плюс один процесс в продакшене + настройка + пришлось разбираться с кучей либ, которые не работают в беке.
Помимо этого было еще много мелкой возни с пейджингом, фильтрацией, флешами, событиями для аналитики и бог знает чем еще. Но, в итоге, после первоначальной настройки, я чувствую, что скорость разработки приблизилась к тому, как это было на rails. Да не так быстро, но зато значительно упростилась возможность добавлять любой фронтендовый интерактив. В классическом беке подключать фронт это та еще история.
Ссылки: Телеграм | Youtube | VK
Саммари по переезду с серверной шаблонизации на slim в code-basics на инерацию с реактом. Если кто пропустил напомню, концепция инерации в том, что она соединяет бек и фронт в классическом стиле для бекенд фреймворков. В экшенах контроллера передаются данные во вьюху, а вместо обычной серверной вьюхи, используется какой-либо фронтенд фреймворк, в моем случае реакт. Инерция концептуально работает как nest.js, но в качестве бека может выступать любой бекенд фреймворк для которого есть адаптер. Ключевые моменты:
* Используется серверный роутинг
* На фронтенде нет стора. Данные идут в пропсы
* По причине описанной выше, нет никакого API
Для меня это уже второе приложение в таком стиле. Сначала была приемка документов для колледжа, в разработке которой я участвовал три месяца. Теперь вот code-basics. В отдаленной перспективе, я планирую переводить на эту схему сам Хекслет.
Что хочу сказать. Изменения, которые надо вносить в бек для работы с инерцией минимальны. Главное отличие от рельсового подхода наверное в том, что если валидация не прошла, то инерции нужен редирект, а не рендеринг шаблона, как это принято в рельсе. Для этого адаптер инерции под рельсу идет с нужными хелперами, так что тут проблем нет.
Чуть усложнился проброс данных на фронтенд. В бекенде в шаблон можно передавать сами модели, так как это все происходит на сервере. На клиент уйдет только то, что мы реально будем использовать. В случае же инерции, данные целиком уходят на фронтенд, поэтому появляется промежуточный слой DTO, что вполне себе классика для большинства экосистем. В любом случае такой слой всегда присутствует при наличии API.
Либа для ресурсов (DTO), как и полагается в современном мире, умеет генерировать типы для TS, что очень помогает не дублировать и не описывать все ручками.
Лейаутинг и паршиалы на сервере, это особый механизм внутри шаблонизатора. С переходом на фронт, все это стало не актуально и самое главное, для этого ничего не нужно специального. Лейаут в реакте это просто компонент в который мы все оборачиваем. Да чуть больше кода в каждом конретном шаблоне, но явность тоже имеет свои плюсы.
Рельса предоставляет много удобных механизмов для серверных шаблонов, например офигенные формы, которые умеют работать с моделями. Это автоматизирует кучу вещей, от правильной обработки ошибок, интеграцию с i18n и многое другое. В новой схеме все это пришлось заводить руками. Инерция поставляется с хуками для обработки форм, но им далеко до рельсовых интеграций, поэтому пришлось напилить файл с формами. Для хранения строк я взял i18next, но сделал хитро. Я не стал дублировать и переносить переводы из бека, а заюзал либу, которая автоматом собирает все в json для фронта. Поэтому сами тексты описываются как обычно, но “магически” оказываются на фронтенде.
Примерно такая же история с роутингом. Чтобы не писать урлы ручками, я подключил либу js-routes, которая переносит описание всех маршрутов на фронтенд. Все это типизировано по самое нехочу
А что по внешнему виду? Тут многие знают что я предпочитаю бутстрап, но честно говоря, у меня была попытка найти что-то такое же высокоуровневое. В итоге из более менее подходящего оказался только https://primereact.org/, который можно подстраивать под свои стили. Сейчас в проекте часть компонентов взята из react-bootstrap, часть из primereact, например автокомплит или грид в админке.
Ну и нельзя не сказать про ssr. Так бы он и нафиг не сдался, но для проекта критично SEO, поэтому пришлось заводить. Плюс один процесс в продакшене + настройка + пришлось разбираться с кучей либ, которые не работают в беке.
Помимо этого было еще много мелкой возни с пейджингом, фильтрацией, флешами, событиями для аналитики и бог знает чем еще. Но, в итоге, после первоначальной настройки, я чувствую, что скорость разработки приблизилась к тому, как это было на rails. Да не так быстро, но зато значительно упростилась возможность добавлять любой фронтендовый интерактив. В классическом беке подключать фронт это та еще история.
Ссылки: Телеграм | Youtube | VK
February 15