Всем привет 🤟
Давайте знакомиться - меня зовут Александр Русаков.
Вкратце перечислю, почему в принципе мои мысли относительно IT (и не только) могут быть интересны:
- занимаюсь программированием за деньги с 2010 года
- прошел путь от Junior Developer до CTO
- обучаю разработке, провожу вебинары с 2017 года
- поработал и в стартапах, и корпорациях, и в заказной разработке
- мне все еще интересен широкий перечень направлений (от фронтенда и верстки до devops и unit-экономики)
- и это еще не все 😊
До следующих апдейтов 😁
Давайте знакомиться - меня зовут Александр Русаков.
Вкратце перечислю, почему в принципе мои мысли относительно IT (и не только) могут быть интересны:
- занимаюсь программированием за деньги с 2010 года
- прошел путь от Junior Developer до CTO
- обучаю разработке, провожу вебинары с 2017 года
- поработал и в стартапах, и корпорациях, и в заказной разработке
- мне все еще интересен широкий перечень направлений (от фронтенда и верстки до devops и unit-экономики)
- и это еще не все 😊
До следующих апдейтов 😁
❤7❤🔥1🔥1🎉1
Продукт vs Технологии
Обсуждали с коллегой вопрос, к чему склоняться при выборе проекта. Что лучше - скучный продукт с крутыми технологиями или интересный продукт, но технологии так себе? 🤔
Давайте попробуем провести небольшую декомпозицию технической части. С одной стороны под технологиями можно понимать низкоуровневый набор языков программирования, библиотек, фреймворков, тулзов и сервисов, с помощью которых продукт функционирует в данный момент. С другой стороны можно иметь в виду более глобальные вопросы, которые придется решать: работа под высокими нагрузками, приложения реального времени, какая-то big data в конце концов. При должном упорстве один фреймворк можно поменять на другой (более хайповый), а вот глобальные задачи вряд ли удастся изменить.
Продукт, в свою очередь, может привлекать новой для вас предметной областью, внутри которой, на самом деле, ничего интересного и глубокого найти не получится.
Такие получились размышления относительно противостояния продукта и технологий в вакууме.
До связи 👋
Обсуждали с коллегой вопрос, к чему склоняться при выборе проекта. Что лучше - скучный продукт с крутыми технологиями или интересный продукт, но технологии так себе? 🤔
Давайте попробуем провести небольшую декомпозицию технической части. С одной стороны под технологиями можно понимать низкоуровневый набор языков программирования, библиотек, фреймворков, тулзов и сервисов, с помощью которых продукт функционирует в данный момент. С другой стороны можно иметь в виду более глобальные вопросы, которые придется решать: работа под высокими нагрузками, приложения реального времени, какая-то big data в конце концов. При должном упорстве один фреймворк можно поменять на другой (более хайповый), а вот глобальные задачи вряд ли удастся изменить.
Продукт, в свою очередь, может привлекать новой для вас предметной областью, внутри которой, на самом деле, ничего интересного и глубокого найти не получится.
Такие получились размышления относительно противостояния продукта и технологий в вакууме.
До связи 👋
👍4🥰1
Скорость софта и божественный ускоряющий upgrade
Скорость современного софта - парадоксальный вопрос. С каждым годом вычислительных мощностей все больше, закон Мура если и не продолжает действовать напрямую, то его интерпретации относительного нарастающего параллелизма работает и по сей день. Любой современный телефон мощнее, чем мой домашний комп в школьные годы, на котором тогда отлично запускались совершенно топовые игры. При этом все сайты и мобильные приложения вокруг нельзя сказать, что работают плавно, моментно и так далее. В чем же дело?
Во-первых, инструменты разработки 🛠 становятся более высокоуровневыми, чтобы мы с вами могли написать больше годного софта за мифический человеко-час. За это мы платим скоростью исполнения. Почти каждый более высокоуровневый язык, более удобный фреймворк и другой способ упрощения для разработчика действует на скорость исполнения итоговой программы в обратную сторону - замедляет ее.
Во-вторых, профессия программист изменилась, изменились кадры. Если в 70ые-80ые это были люди с высшим образованием и степенями PhD 👨🦳, то в наше время можно закончить интенсив на пару месяцев и ты уже "пограмист" 👶. Человечеству нужно как можно больше софта, поэтому чем-то приходится жертвовать. Новоиспеченные разработчики больше обеспокоены тем, как бы задачу сдать в срок, а не все эти ваши рюшечки и бантики.
Кроме этих двух очевидных тезисов я в свое время выдвинул еще один. Сам софт и его специфические характеристики перестали иметь ценность как таковую. Ценность целиком и полностью перешла в плоскость продукта и команды. Если продукт годный, то найдутся ресурсы переписать весь код и не один раз. Аналогично с командой. Сильная команда способна и неудачный продукт выкинуть и создать новый... Вот в таком мире мы теперь и живем. Очень сложно нести светлое, доброе, вечно и, конечно, паттерны банды четырех, если через месяц весь код будет выброшен на помойку.
Но о чем это мы? Мы начинали про скорость софта, поэтому давайте на нем и завершим. Что же делать, если от скорости страдаем здесь и сейчас, а чудесное время работы над тех. долгом не настало. Единственная надежда, на которую мы надеемся - это божественный ускоряющий upgrade. Случайно посмотрели на changelog вашего супер-пупер фреймворка, а он в новой версии стал в 2 раза быстрее 🚀 да еще и сохранил обратную совместимость 🫶 Тогда бежим, скорее обновляемся и наша жизнь становится капельку лучше.
P.S. Например, этой весной вышел TypeScript v5, который стал и меньше весить, и реально быстрее работать.
https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/ Сказка.
Скорость современного софта - парадоксальный вопрос. С каждым годом вычислительных мощностей все больше, закон Мура если и не продолжает действовать напрямую, то его интерпретации относительного нарастающего параллелизма работает и по сей день. Любой современный телефон мощнее, чем мой домашний комп в школьные годы, на котором тогда отлично запускались совершенно топовые игры. При этом все сайты и мобильные приложения вокруг нельзя сказать, что работают плавно, моментно и так далее. В чем же дело?
Во-первых, инструменты разработки 🛠 становятся более высокоуровневыми, чтобы мы с вами могли написать больше годного софта за мифический человеко-час. За это мы платим скоростью исполнения. Почти каждый более высокоуровневый язык, более удобный фреймворк и другой способ упрощения для разработчика действует на скорость исполнения итоговой программы в обратную сторону - замедляет ее.
Во-вторых, профессия программист изменилась, изменились кадры. Если в 70ые-80ые это были люди с высшим образованием и степенями PhD 👨🦳, то в наше время можно закончить интенсив на пару месяцев и ты уже "пограмист" 👶. Человечеству нужно как можно больше софта, поэтому чем-то приходится жертвовать. Новоиспеченные разработчики больше обеспокоены тем, как бы задачу сдать в срок, а не все эти ваши рюшечки и бантики.
Кроме этих двух очевидных тезисов я в свое время выдвинул еще один. Сам софт и его специфические характеристики перестали иметь ценность как таковую. Ценность целиком и полностью перешла в плоскость продукта и команды. Если продукт годный, то найдутся ресурсы переписать весь код и не один раз. Аналогично с командой. Сильная команда способна и неудачный продукт выкинуть и создать новый... Вот в таком мире мы теперь и живем. Очень сложно нести светлое, доброе, вечно и, конечно, паттерны банды четырех, если через месяц весь код будет выброшен на помойку.
Но о чем это мы? Мы начинали про скорость софта, поэтому давайте на нем и завершим. Что же делать, если от скорости страдаем здесь и сейчас, а чудесное время работы над тех. долгом не настало. Единственная надежда, на которую мы надеемся - это божественный ускоряющий upgrade. Случайно посмотрели на changelog вашего супер-пупер фреймворка, а он в новой версии стал в 2 раза быстрее 🚀 да еще и сохранил обратную совместимость 🫶 Тогда бежим, скорее обновляемся и наша жизнь становится капельку лучше.
P.S. Например, этой весной вышел TypeScript v5, который стал и меньше весить, и реально быстрее работать.
https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/ Сказка.
Microsoft News
Announcing TypeScript 5.0
Today we’re excited to announce the release of TypeScript 5.0! This release brings many new features, while aiming to make TypeScript smaller, simpler, and faster. We’ve implemented the new decorators standard, added functionality to better support ESM projects…
🔥4👍1
Про Headless CMS в общем и Strapi в частности
Вряд ли кого-то можно удивить аббревиатурой CMS. Они известны с уже далеких 2000ых: всякие Wordpress, Joomla, или не дай бог Bitrix. Но что за зверь Headless CMS? Давайте разберемся.
Где-то к середине 2010ых годов на рынок разработки вышло приличное количество frontend-разработчиков, потому что всем нужны были Web 2.0 сайты, диджитал и вот это все. Это породило большую тройку фронтенд фреймворков (react, angular, vue) и соответственно создавать страницы внутри убогих интерфейсов CMS и потом прикурчивать jQuery к этим страницам уже никто не хотел. Так появились сначала изоморфные приложение, а потом и Server Side Rendering или SSR, под которым сейчас все понимают запуск js-кода на сервере и рендеренг HTML с помощью вашего любимого браузерного фреймворка.
Что же получается? Для таких ребят не нужна CMS в привычном смысле, где в конструкторе или псевдокоде собираются странички из блоков. Конструктор нужен, но уже не страниц, а бекенда целиком и результирующего API, чтобы затем отобразить полученные данные так, как хочется. Ведь типичный бекенд очень часто похож на копи-паст роутеров, валидаторов, запросов в БД и сериализиторов на выходе. Так почему бы не сделать один раз и на все случаи жизни 😅
Итак, на сцену выходит Headless CMS Strapi (https://strapi.io/):
- начиналась как Open Source проект на Javascript + Node.js
- привлекла первый seed раунд инвестиций $4 миллиона в 2019 году
- суммарный объем инвестиций на текущий момент - $45 миллионов
- более 54k звезд на Github ⭐️
- более 70k установок ежемесячно по данным npmjs.com
Опенсорс версия остается бесплатной и по сей день. На чем же заработок? Для тех, кто не хочет заниматься настройкой и деплоем, Strapi предлагают готовую к использованию облачную версию за $99 в месяц на тарифе Pro и за $499 в месяц на тарифе Team. На тарифе Team прям жирненько 🤑
Какое у меня сформировалось ко всей этой истории отношение:
Во-первых, в 2019 году мы пытались внедрить Strapi на одном проекте, но отказались из-за отсутствия встроенного Rich Text Editor и поддержки иерархичности данных. В тот момент Strapi действительно была очень простой CMS.
Во-вторых, мне очень нравится такая модель, когда на базе опенсорса ребята смогли выстроить коммерчески успешную историю. Единственное, чего мне здесь не хватает, так это какой-то действительно прорывной технологии. Ну запрогали красивую админку, ну поля и формочки разные, есть коннекты к популярным бд (MySQL, PostgreSQL, MongoDB), наружу все это отдается через REST API или новомодный GraphQL. Можно ли это легко повторить? Не вижу препятствий 🙂
Я вроде бы и не впечатлен, но удалось ли этим ребятам захватить действительно полезную и востребованную нишу? Безусловно да. Если кто-то говорит Headless CMS, то Strapi всегда на слуху.
В сухом остатке собирать на конструкторе бекенд критической части приложения я бы не стал, но вот заменить все кастомные админки для лендингов, сайтов-визиток и корпоративных блогов - рекомендую. До связи 🤟
Вряд ли кого-то можно удивить аббревиатурой CMS. Они известны с уже далеких 2000ых: всякие Wordpress, Joomla, или не дай бог Bitrix. Но что за зверь Headless CMS? Давайте разберемся.
Где-то к середине 2010ых годов на рынок разработки вышло приличное количество frontend-разработчиков, потому что всем нужны были Web 2.0 сайты, диджитал и вот это все. Это породило большую тройку фронтенд фреймворков (react, angular, vue) и соответственно создавать страницы внутри убогих интерфейсов CMS и потом прикурчивать jQuery к этим страницам уже никто не хотел. Так появились сначала изоморфные приложение, а потом и Server Side Rendering или SSR, под которым сейчас все понимают запуск js-кода на сервере и рендеренг HTML с помощью вашего любимого браузерного фреймворка.
Что же получается? Для таких ребят не нужна CMS в привычном смысле, где в конструкторе или псевдокоде собираются странички из блоков. Конструктор нужен, но уже не страниц, а бекенда целиком и результирующего API, чтобы затем отобразить полученные данные так, как хочется. Ведь типичный бекенд очень часто похож на копи-паст роутеров, валидаторов, запросов в БД и сериализиторов на выходе. Так почему бы не сделать один раз и на все случаи жизни 😅
Итак, на сцену выходит Headless CMS Strapi (https://strapi.io/):
- начиналась как Open Source проект на Javascript + Node.js
- привлекла первый seed раунд инвестиций $4 миллиона в 2019 году
- суммарный объем инвестиций на текущий момент - $45 миллионов
- более 54k звезд на Github ⭐️
- более 70k установок ежемесячно по данным npmjs.com
Опенсорс версия остается бесплатной и по сей день. На чем же заработок? Для тех, кто не хочет заниматься настройкой и деплоем, Strapi предлагают готовую к использованию облачную версию за $99 в месяц на тарифе Pro и за $499 в месяц на тарифе Team. На тарифе Team прям жирненько 🤑
Какое у меня сформировалось ко всей этой истории отношение:
Во-первых, в 2019 году мы пытались внедрить Strapi на одном проекте, но отказались из-за отсутствия встроенного Rich Text Editor и поддержки иерархичности данных. В тот момент Strapi действительно была очень простой CMS.
Во-вторых, мне очень нравится такая модель, когда на базе опенсорса ребята смогли выстроить коммерчески успешную историю. Единственное, чего мне здесь не хватает, так это какой-то действительно прорывной технологии. Ну запрогали красивую админку, ну поля и формочки разные, есть коннекты к популярным бд (MySQL, PostgreSQL, MongoDB), наружу все это отдается через REST API или новомодный GraphQL. Можно ли это легко повторить? Не вижу препятствий 🙂
Я вроде бы и не впечатлен, но удалось ли этим ребятам захватить действительно полезную и востребованную нишу? Безусловно да. Если кто-то говорит Headless CMS, то Strapi всегда на слуху.
В сухом остатке собирать на конструкторе бекенд критической части приложения я бы не стал, но вот заменить все кастомные админки для лендингов, сайтов-визиток и корпоративных блогов - рекомендую. До связи 🤟
strapi.io
Strapi - Open source Node.js Headless CMS 🚀
Strapi is the next-gen headless CMS, open-source, JavaScript/TypeScript, enabling content-rich experiences to be created, managed and exposed to any digital device.
👍4❤🔥3
Про git и Сonventional Commits
Вспомнил забавную цитату про читаемость кода. "Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте!". Аж кровь стынет в жилах 😅 Шутки-шутками, но мысль о том, что профессиональные программисты пишут код, который потом будут читать и пытаться понять другие люди, так или иначе закрепляется в светлых умах. А что же насчет маленьких строчек текста, которые мы оставляем в git commit?
Ситуация с commit-ами немного иная: все понимают, что лучше бы написать туда что-то понятное, но все не так радужно. Сама система контроля версий никаких ограничений не накладывает, и в итоге коммиты пишутся на скорую руку и без какого-то смысла, а главное структуры: "bugfix something", "add new property", "close issue #42" и т.д. Понять характер измнений и наличие обратной совместимости обычно не представляется возможным.
Если вам так же кажется, что все тлен, то предлагаю познакомится с системой Conventional Commits. В общем виде заголовок коммита выглядит так:
Как это читать?
- Тип изменений - слово из фиксированного списка (fix, feat, perf, test, ci, build и тд)
- Опциональный скоуп - изолированная часть кодовой базы, к которой относятся изменения. Вы их выбираете сами под проект и нужды.
- Короткое описание в настоящем времени. Обычно включает глагол add, remove, setup, change и тд
- Если тип заменен на BREAKING CHANGE или после типа добавляется ! - значит изменения нарушают обратную совместимость
Несколько примеров заголовков коммитов из проектов на github, которые уже следуют этой системе:
Чуть больше подробностей читайте в официальной доке https://www.conventionalcommits.org/. А в следующий раз мы поговорим причем здесь версионирование.
До связи 🤟
Вспомнил забавную цитату про читаемость кода. "Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте!". Аж кровь стынет в жилах 😅 Шутки-шутками, но мысль о том, что профессиональные программисты пишут код, который потом будут читать и пытаться понять другие люди, так или иначе закрепляется в светлых умах. А что же насчет маленьких строчек текста, которые мы оставляем в git commit?
Ситуация с commit-ами немного иная: все понимают, что лучше бы написать туда что-то понятное, но все не так радужно. Сама система контроля версий никаких ограничений не накладывает, и в итоге коммиты пишутся на скорую руку и без какого-то смысла, а главное структуры: "bugfix something", "add new property", "close issue #42" и т.д. Понять характер измнений и наличие обратной совместимости обычно не представляется возможным.
Если вам так же кажется, что все тлен, то предлагаю познакомится с системой Conventional Commits. В общем виде заголовок коммита выглядит так:
type(scope): short description
Как это читать?
- Тип изменений - слово из фиксированного списка (fix, feat, perf, test, ci, build и тд)
- Опциональный скоуп - изолированная часть кодовой базы, к которой относятся изменения. Вы их выбираете сами под проект и нужды.
- Короткое описание в настоящем времени. Обычно включает глагол add, remove, setup, change и тд
- Если тип заменен на BREAKING CHANGE или после типа добавляется ! - значит изменения нарушают обратную совместимость
Несколько примеров заголовков коммитов из проектов на github, которые уже следуют этой системе:
test: fix editor SDK test
perf(core): setup workspaces in parallel
feat!: make all settings mergeable
Чуть больше подробностей читайте в официальной доке https://www.conventionalcommits.org/. А в следующий раз мы поговорим причем здесь версионирование.
До связи 🤟
👍4❤1
Программирование и структуры данных
Я думаю многие знают замечательного парня Линуса Торвальдса, который подарил миру Linux, Git, а также массу мемов и цитат типа "Nvidia, fuck you!". Ещё Линус человек прямолинейный, за словом в корман не лезет и не стесняется поучать других в переписке разработчиков Linux. В одной из таких переписок и находится интересная цитата про код и данные (перевод на русский): "Плохие программисты заботятся о коде, хорошие - о структурах данных и их взаимосвязях".
На первый взгляд кажется, что данные и собственно код по их обработки слабо отделимы, должны органично дополнять друг друга и все такое. Но со временем я соглашаюсь с этим тезисом все больше и вот почему:
- Данные первичны. От постановки задачи до конечного результата "заказчика" интересуют данные, а не чудесный способ их получения/хранения/обработки.
- Структуры данных и способ хранения обычно определяют возможный набор алгоритмов обработки и временные характеристики доступа, что бывает критично.
- Если обсудить структуру данных с разработчиком перед задачей, то это уже направляет в нужное русло.
- Если начинать Code Review со способа хранения, то обычно все остальное становится более понятным.
- Время жизнь данных в общем случае дольше, чем время жизни кода. Код же в любой момент может быть исправлен, отрефакторен, оптимизирован или так далее .
Думайте о данных и хорошего коддинга 🤟
Я думаю многие знают замечательного парня Линуса Торвальдса, который подарил миру Linux, Git, а также массу мемов и цитат типа "Nvidia, fuck you!". Ещё Линус человек прямолинейный, за словом в корман не лезет и не стесняется поучать других в переписке разработчиков Linux. В одной из таких переписок и находится интересная цитата про код и данные (перевод на русский): "Плохие программисты заботятся о коде, хорошие - о структурах данных и их взаимосвязях".
На первый взгляд кажется, что данные и собственно код по их обработки слабо отделимы, должны органично дополнять друг друга и все такое. Но со временем я соглашаюсь с этим тезисом все больше и вот почему:
- Данные первичны. От постановки задачи до конечного результата "заказчика" интересуют данные, а не чудесный способ их получения/хранения/обработки.
- Структуры данных и способ хранения обычно определяют возможный набор алгоритмов обработки и временные характеристики доступа, что бывает критично.
- Если обсудить структуру данных с разработчиком перед задачей, то это уже направляет в нужное русло.
- Если начинать Code Review со способа хранения, то обычно все остальное становится более понятным.
- Время жизнь данных в общем случае дольше, чем время жизни кода. Код же в любой момент может быть исправлен, отрефакторен, оптимизирован или так далее .
Думайте о данных и хорошего коддинга 🤟
👍4❤🔥2