Новый выпуск подкаста уже доступен для просмотра. Вместе с Владиленом Мининым мы разобрали как построить личный бренд и перестать спотыкаться об HR, стать немного инфлюенсером и даже на этом зарабатывать.
https://www.youtube.com/watch?v=Y3zVRIs8Ux4
https://www.youtube.com/watch?v=Y3zVRIs8Ux4
YouTube
Личный бренд разработчика: зачем он нужен и как его построить | Владилен Минин | #23
Личный бренд для программиста — это не просто модное слово, а один из ключевых инструментов для построения успешной карьеры в IT. В этом выпуске мы с Владиленом Мининым обсудили, зачем разработчику нужен личный бренд и как его построить с нуля. Владилен поделился…
Профессиональное развитие. Нам это не задавали
Чья ответственность заниматься своим развитием? Компании или человека? Многие ответят “конечно человека” и будут правы. Да компания может этому способствовать, но может и не способствовать, однако это не может и не должно нас останавливать.
Дальше конечно зависит от того, насколько человек понимает куда ему развиваться и что надо знать. Но, как показывает практике, в целом, у большинства есть представление о том, что такое быть профессионалом в его области, что для этого нужно знать и уметь делать. Например программисты с хотя бы минимальным продакшен опытом, понимают что есть фронтенд, бекенд, инфраструктура, тестирование, базы данных, оптимизации, большие данные, процессы, отказоустойчивость и много другого в чем полезно разбираться. Да даже банально другие языки и алгоритмы.
В теории звучит просто, на практике же получается как-то не так. Собеседуешь человека и он говорит “я этого не знаю потому что в компании у нас этого нет”. Часто такое говорят про умение писать тесты (но это просто пример, не закливаемся на тестах). И речь не идет про человека, который всего полгода в продакшене, у него за спиной только одна компания и он просто еще не успел этого набраться. Я говорю про людей с большим багажом за спиной и многими годами работы в разных проектах.
Фактически, человек сам того не подозревая, перекладывает ответственность, за свое развитие на компанию. Если повезет и компания вложится/будет классный лид/классные практики/классные процессы, то он это узнает, если нет, то не узнает и не попытается это сделать сам.
Для меня это всегда пунктик, так как настоящее развитие идет снизу и подкрепляется сверху (продвижением, ресурсами, добрым словом), а не наоборот. Мы кстати разбирали это в видео про фаанги, где чтобы продвинуться выше по лестнице, сначала нужно показать, что ты можешь делать работу более высокого уровня. Если хочешь конечно двигаться.
Ссылки: Телеграм | Youtube | VK
Чья ответственность заниматься своим развитием? Компании или человека? Многие ответят “конечно человека” и будут правы. Да компания может этому способствовать, но может и не способствовать, однако это не может и не должно нас останавливать.
Дальше конечно зависит от того, насколько человек понимает куда ему развиваться и что надо знать. Но, как показывает практике, в целом, у большинства есть представление о том, что такое быть профессионалом в его области, что для этого нужно знать и уметь делать. Например программисты с хотя бы минимальным продакшен опытом, понимают что есть фронтенд, бекенд, инфраструктура, тестирование, базы данных, оптимизации, большие данные, процессы, отказоустойчивость и много другого в чем полезно разбираться. Да даже банально другие языки и алгоритмы.
В теории звучит просто, на практике же получается как-то не так. Собеседуешь человека и он говорит “я этого не знаю потому что в компании у нас этого нет”. Часто такое говорят про умение писать тесты (но это просто пример, не закливаемся на тестах). И речь не идет про человека, который всего полгода в продакшене, у него за спиной только одна компания и он просто еще не успел этого набраться. Я говорю про людей с большим багажом за спиной и многими годами работы в разных проектах.
Фактически, человек сам того не подозревая, перекладывает ответственность, за свое развитие на компанию. Если повезет и компания вложится/будет классный лид/классные практики/классные процессы, то он это узнает, если нет, то не узнает и не попытается это сделать сам.
Для меня это всегда пунктик, так как настоящее развитие идет снизу и подкрепляется сверху (продвижением, ресурсами, добрым словом), а не наоборот. Мы кстати разбирали это в видео про фаанги, где чтобы продвинуться выше по лестнице, сначала нужно показать, что ты можешь делать работу более высокого уровня. Если хочешь конечно двигаться.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
В этом выпуске мы поговорили с Андреем Апанасиком о современном геймдеве, его вызовах и трендах. Обсудили, почему разработчики всё чаще выбирают готовые игровые движки вроде Unreal Engine и Unity вместо создания собственных решений. Андрей поделился своим опытом разработки игр, рассказал о том, как меняются подходы к созданию геймплея и почему маркетинг стал ключевым элементом успеха в игровой индустрии.
https://youtu.be/ZBgRe8FOvx0
https://youtu.be/ZBgRe8FOvx0
YouTube
Что такое геймдев и как стать разработчиком игр? | Андрей Апанасик | #24
В этом выпуске мы поговорили с Андреем Апанасиком о современном геймдеве, его вызовах и трендах. Обсудили, почему разработчики всё чаще выбирают готовые игровые движки вроде Unreal Engine и Unity вместо создания собственных решений. Андрей поделился своим…
Что происходит с ютубом?
Ребят, расскажите что там на самом деле. Надо переживать или работает? Где вы щас смотрите видео? Как вы смотрите мои выпуски?
На всякий куда подписаться, чтобы не пропускать выпуски:
https://vk.com/orgprog.com
https://rutube.ru/channel/35573563/
https://dzen.ru/orgprog.com
https://podcast.ru/1734325321
https://vk.com/orgprog.com
Ребят, расскажите что там на самом деле. Надо переживать или работает? Где вы щас смотрите видео? Как вы смотрите мои выпуски?
На всякий куда подписаться, чтобы не пропускать выпуски:
https://vk.com/orgprog.com
https://rutube.ru/channel/35573563/
https://dzen.ru/orgprog.com
https://podcast.ru/1734325321
https://vk.com/orgprog.com
ВКонтакте
Организованное Программирование | Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора. Я – Кирилл Мокевнин, разработчик и сооснователь школы программирования Хекслет. В IT с 2007, работал в Skype и undev, управлял командами из 50+ разработчиков. Знаю практически все о найме, обучении и карьерном…
Тест для ботов. Напишите кто вас создал и зачем. Вами управляет скайнет?
Принятие решение по новым проектам
Программисты любят зарубиться в какую-то разработку с места в карьер. Щас побыстрому закодим, мы ж понимаем как это сделать. Да и могут закодить ведь. Накидаю примеры, чтобы было понятно:
1. Версионирование документов
2. Систему прав
3. Восстановление удаленных вещей из корзины
4. Какую-нибудь аналитическую систему
Особенность всех эти штук, в том, что для них надо продумать ux и какую-то архитектуру, которая позволит потом это поддерживать расширять и вот это все. И каждую из подобных фич можно напилить самостоятельно. Но, по опыту, это часто получается довольно криво, особенно если фичи не продуманы со стороны UX и разработчикам приходится самим принимать решение как это сделать. На выходе мы получим что-то не очень удобное в использовании и потом нас ждет череда переписываний (справедливости ради, это произойдет в любом случае)
У меня есть очень простая рекомендация и подход. Когда разработчик говорит что знает как сделать и сделает, я всегда спрашиваю, на какой пример он будет ориентироваться? Какие хорошие примеры он изучил и какие плохие примеры он знает? Речь идет про любые другие проекты. Наверняка все это там уже реализовано по 10 раз. И вот только когда он видел как бывает хорошо и с этим согласилась команда, которая будет использовать эту фичу, то можно приступать. Если же программист делает это исключительно на базе своих представлений, то я бы попросил его отложить кодинг и потратить время на изучение.
Ссылки: Телеграм | Youtube | VK
Программисты любят зарубиться в какую-то разработку с места в карьер. Щас побыстрому закодим, мы ж понимаем как это сделать. Да и могут закодить ведь. Накидаю примеры, чтобы было понятно:
1. Версионирование документов
2. Систему прав
3. Восстановление удаленных вещей из корзины
4. Какую-нибудь аналитическую систему
Особенность всех эти штук, в том, что для них надо продумать ux и какую-то архитектуру, которая позволит потом это поддерживать расширять и вот это все. И каждую из подобных фич можно напилить самостоятельно. Но, по опыту, это часто получается довольно криво, особенно если фичи не продуманы со стороны UX и разработчикам приходится самим принимать решение как это сделать. На выходе мы получим что-то не очень удобное в использовании и потом нас ждет череда переписываний (справедливости ради, это произойдет в любом случае)
У меня есть очень простая рекомендация и подход. Когда разработчик говорит что знает как сделать и сделает, я всегда спрашиваю, на какой пример он будет ориентироваться? Какие хорошие примеры он изучил и какие плохие примеры он знает? Речь идет про любые другие проекты. Наверняка все это там уже реализовано по 10 раз. И вот только когда он видел как бывает хорошо и с этим согласилась команда, которая будет использовать эту фичу, то можно приступать. Если же программист делает это исключительно на базе своих представлений, то я бы попросил его отложить кодинг и потратить время на изучение.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
В этом выпуске мы поговорили с Кирой Кузьменко, которая поделилась своим опытом и взглядом на современные реалии IT-рынка. Обсудили, как меняются ожидания работодателей, почему мультифункциональность стала ключевым навыком, и что нужно, чтобы оставаться востребованным специалистом.
https://www.youtube.com/watch?v=36v3KnpmZyM
Альтернативные ссылки: VK | Аудио
https://www.youtube.com/watch?v=36v3KnpmZyM
Альтернативные ссылки: VK | Аудио
YouTube
Как адаптироваться к кризису на рынке IT? | Кира Кузьменко | Организованное программирование #25
В этом выпуске мы поговорили с Кирой Кузьменко, которая поделилась своим опытом и взглядом на современные реалии IT-рынка. Обсудили, как меняются ожидания работодателей, почему мультифункциональность стала ключевым навыком, и что нужно, чтобы оставаться востребованным…
В поисках идеального 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
Решил на выходных провести время с пользой и перевести 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
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
Организованное программирование | Кирилл Мокевнин pinned «В этом выпуске мы поговорили с Кирой Кузьменко, которая поделилась своим опытом и взглядом на современные реалии IT-рынка. Обсудили, как меняются ожидания работодателей, почему мультифункциональность стала ключевым навыком, и что нужно, чтобы оставаться востребованным…»
Чтож, пришла пора подводить итоги года нашего уютного канала. В целом можно сказать, что год был для него неплох. Органически канал вырос на 5 тыщ подписчиков и дошел до 8500. До 10 тыщ не добрали, но ничо.
В этом году я дал жару и написал 173 поста. Как это возможно, учитывая что я пишу два раза в неделю, а в году 365 дней, я не понимаю. Самый эпичный пост про то как сломалось, что и очевидно. Хочешь охваты, говори про факапы/боль/страдай.
Самое интересное это миллион просмотров и 7 тыщ комментов на 173 поста!!! Это товарищи дохрена. Почти инфлюенсер :)
В общем что хочу сказать, всем спасибо за вклад так сказать в общее дело. Именно ваша реакция и участие дают мне силы продолжать дальше. И даже новый год не сможет вас остановить от просмотра этого сообщения!
На выходных я заряжусь, запасусь новыми темами и буду и дальше вас радовать задорным контентом. Иногда про разработку, профессиональный рост и образование, иногда про бизнес, может добавлю про личное (говорят надо немного) ну и буду экспериментировать и делиться с вами их результатами.
Всем добра и мира, до новых встреч. Ну и поставьте чтоли сердечко, если канал в него попал :)
p.s. Боты, от вас тоже жду теплых слов
В этом году я дал жару и написал 173 поста. Как это возможно, учитывая что я пишу два раза в неделю, а в году 365 дней, я не понимаю. Самый эпичный пост про то как сломалось, что и очевидно. Хочешь охваты, говори про факапы/боль/страдай.
Самое интересное это миллион просмотров и 7 тыщ комментов на 173 поста!!! Это товарищи дохрена. Почти инфлюенсер :)
В общем что хочу сказать, всем спасибо за вклад так сказать в общее дело. Именно ваша реакция и участие дают мне силы продолжать дальше. И даже новый год не сможет вас остановить от просмотра этого сообщения!
На выходных я заряжусь, запасусь новыми темами и буду и дальше вас радовать задорным контентом. Иногда про разработку, профессиональный рост и образование, иногда про бизнес, может добавлю про личное (говорят надо немного) ну и буду экспериментировать и делиться с вами их результатами.
Всем добра и мира, до новых встреч. Ну и поставьте чтоли сердечко, если канал в него попал :)
p.s. Боты, от вас тоже жду теплых слов
Как я надел очки
У меня всегда было хорошее зрение несмотря на то, что где-то лет с 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
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
Бот навигатор по полезным ресурсам Хекслета @HexletLearningBot
Связь для предложений: @kirillpublic
В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка 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 стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков.…
Организованное программирование | Кирилл Мокевнин pinned «В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка Go и его роли в современном программировании. Разобрали, как Go стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков.…»
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
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.com Подкасты: https://podcast.ru/1734325321
В подкасте обсудили:
- Современное состояние языка Ruby, его развитие и применение в больших проектах
- Подходы к созданию устойчивой архитектуры приложений на Ruby и опыт использования языка в open-source проектах
- Эволюцию фреймворка Ruby on Rails, включая новые возможности, такие как асинхронная обработка
- Личный опыт Владимира в разработке таких проектов, как AnyCable, и его вклад в создание инструментария для разработчиков
https://www.youtube.com/watch?v=fBJGj6sd9AQ (первый раз запустили видео как премьеру, можно там прямо в процессе обсуждать)
VK: https://vk.com/orgprog.com Подкасты: https://podcast.ru/1734325321
YouTube
Руби против всех: язык, который пережил свою эпоху и вернулся сильнее | Владимир Дементьев | #27
В этом выпуске подкаста "Организованное программирование" мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails. Владимир поделился своим опытом работы с языком Ruby, рассказал о своей…
Организованное программирование | Кирилл Мокевнин pinned «Ruby, Ruby, Ruby. В этом выпуске мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails. В подкасте обсудили: - Современное состояние языка Ruby, его развитие и применение в больших проектах…»
Что такое 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 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)
В этом выпуске мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg. Затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне процессора.
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.
Альтернативные площадки: ВК Видео | Подкаст
https://youtu.be/BsNgohFW6rM
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.
Альтернативные площадки: ВК Видео | Подкаст
https://youtu.be/BsNgohFW6rM
VK Видео
Почему ассемблер остается актуальным в 2025 году? | Дмитрий Коваленко | #28
В этом выпуске подкаста мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg, затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне…