Привет!
Прочитал субстак про Radical Object-Orientation (автор его ещё дописывает)
Имхо - Эргономичная архитектура, только в профиль.
- PoMO - очень напоминает то, что у меня ресурс может быть включен только в один другой ресурс
- IOSP - очень напоминает сбалансированную форму системы
- У него тоже дизайн рекурсивен - атомарная операция ио с точки зрения оркестрации сама может оказаться оркестрацией на своём уровне абстракции
- Так же придерживатеся мнения, что абстракция != public interface - "Integrations are abstractions as well."
- Но у автора всё, включая интеграции - есть объект. У меня, по крайней мере синтаксически, объектами (штуками эксклюзивно владеющими собственными состоянием) являются только ресурсы, а операции - это скрипты которые заимствуют состояние ресурсов и тем самым разделяют его между собой. Но. Всё приложение в целом - можно считать объектом.
Из минусов:
- (Относительно) многа букаф и картинок и очень мало кода, а тот что есть - тривиальный и про консольные приложения
- Аналогия с клетками привлекательная, но не очень... Клетки действительно организуют очень крутые, сложные и адаптивные системы. Которые человечество за миллион человеко-часов понять не может - хотим ли мы поддерживать такие системы?
- А ещё я в #project_r@ergonomic_code опять (но теперь под другим углом) начал сталкиваться с тем, что инкапсуляция состояния плохо масштабируется, так как влечёт неограниченный рост поверхности АПИ ключевых/центральных/фундаментальных объектов-ресусров.
Вердикт: по принципу "повторение - мать учения" и "количество переходит в качество" - советую почитать. Но мне кажется у меня сейчас те же по сути идеи поданы лучше - как минимум у меня довольно много примеров реального кода, а не консольных утилиток.
#posts@ergonomic_code #ergo_approach@ergonomic_code #oop@ergonomic_code
Прочитал субстак про Radical Object-Orientation (автор его ещё дописывает)
Имхо - Эргономичная архитектура, только в профиль.
- PoMO - очень напоминает то, что у меня ресурс может быть включен только в один другой ресурс
- IOSP - очень напоминает сбалансированную форму системы
- У него тоже дизайн рекурсивен - атомарная операция ио с точки зрения оркестрации сама может оказаться оркестрацией на своём уровне абстракции
- Так же придерживатеся мнения, что абстракция != public interface - "Integrations are abstractions as well."
- Но у автора всё, включая интеграции - есть объект. У меня, по крайней мере синтаксически, объектами (штуками эксклюзивно владеющими собственными состоянием) являются только ресурсы, а операции - это скрипты которые заимствуют состояние ресурсов и тем самым разделяют его между собой. Но. Всё приложение в целом - можно считать объектом.
Из минусов:
- (Относительно) многа букаф и картинок и очень мало кода, а тот что есть - тривиальный и про консольные приложения
- Аналогия с клетками привлекательная, но не очень... Клетки действительно организуют очень крутые, сложные и адаптивные системы. Которые человечество за миллион человеко-часов понять не может - хотим ли мы поддерживать такие системы?
- А ещё я в #project_r@ergonomic_code опять (но теперь под другим углом) начал сталкиваться с тем, что инкапсуляция состояния плохо масштабируется, так как влечёт неограниченный рост поверхности АПИ ключевых/центральных/фундаментальных объектов-ресусров.
Вердикт: по принципу "повторение - мать учения" и "количество переходит в качество" - советую почитать. Но мне кажется у меня сейчас те же по сути идеи поданы лучше - как минимум у меня довольно много примеров реального кода, а не консольных утилиток.
#posts@ergonomic_code #ergo_approach@ergonomic_code #oop@ergonomic_code
Substack
Radical Object-Orientation | Ralf Westphal | Substack
Object-orientation grown from its roots. Click to read Radical Object-Orientation, by Ralf Westphal, a Substack publication with hundreds of subscribers.
👍8
Привет!
#project_r подходит к концу и я ищу для себя новый проект по разработке веб-приложения, веб-сервиса или бакэнда мобильного приложения на JVM-стеке (Kotlin, Java).
Могу собрать команду и сделать проект "под ключ", могу выстроить эффективный процесс разработки в существующей команде, могу писать код.
Рассматриваю варианты работы по договору с ИП, договору ГПХ и трудовому договору.
Если вам или кому из ваших знакомых нужен хорошо сделанный бакэнд - приходите в личку, пожалуйста:)
Буду благодарен за репост.
#project_r подходит к концу и я ищу для себя новый проект по разработке веб-приложения, веб-сервиса или бакэнда мобильного приложения на JVM-стеке (Kotlin, Java).
Могу собрать команду и сделать проект "под ключ", могу выстроить эффективный процесс разработки в существующей команде, могу писать код.
Рассматриваю варианты работы по договору с ИП, договору ГПХ и трудовому договору.
Если вам или кому из ваших знакомых нужен хорошо сделанный бакэнд - приходите в личку, пожалуйста:)
Буду благодарен за репост.
🔥9👍5
Привет!
Реклама
Как сервисам взаимодействовать между собой надёжно, быстро и понятно?
REST, gRPC, события, контракты, версии — деталей много, а универсальных решений нет.
На онлайн-конференции Podlodka Techlead Crew (7–11 апреля) разберёмся, как выстраивать межсервисное взаимодействие: от проектирования API до публикации событий и сравнения протоколов.
В программе:
🎯 Event Storming + DDD: проектируем EDA правильно — Кирилл Ветчинкин расскажет, как выделять правильные события, избавляться от синхронных вызовов и строить событийно-ориентированные системы без боли
🔄 Обратная совместимость в парадигме specification-first — Сергей Константинов покажет, как поддерживать REST API и работать со спецификациями типа OpenAPI
🎙Интервью: Проектируем API — contract first — Илья Зонов поделится, когда этот подход спасает, а когда мешает. И как версионировать API без боли
⚔️ gRPC vs RESTful: битва протоколов — Алексей Романов сравнит два подхода по 10 критериям
Готовы прокачаться?
Билеты здесь🎟
Реклама
Как сервисам взаимодействовать между собой надёжно, быстро и понятно?
REST, gRPC, события, контракты, версии — деталей много, а универсальных решений нет.
На онлайн-конференции Podlodka Techlead Crew (7–11 апреля) разберёмся, как выстраивать межсервисное взаимодействие: от проектирования API до публикации событий и сравнения протоколов.
В программе:
🎯 Event Storming + DDD: проектируем EDA правильно — Кирилл Ветчинкин расскажет, как выделять правильные события, избавляться от синхронных вызовов и строить событийно-ориентированные системы без боли
🔄 Обратная совместимость в парадигме specification-first — Сергей Константинов покажет, как поддерживать REST API и работать со спецификациями типа OpenAPI
🎙Интервью: Проектируем API — contract first — Илья Зонов поделится, когда этот подход спасает, а когда мешает. И как версионировать API без боли
⚔️ gRPC vs RESTful: битва протоколов — Алексей Романов сравнит два подхода по 10 критериям
Готовы прокачаться?
Билеты здесь🎟
podlodka.io
Онлайн-конференция Podlodka Teсhlead Crew #9
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам techlead-разработки, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Привет!
Heartbeat-пост.
Я жив. И канал жив. И Эргономичный подход жив.
Затишье в последнее время связано в основном с тем, что я в Trainer Adviser пилю интеграцию с ical-календарями.
Там не то чтобы прям рокетсайнс, но уже и не совсем тривиальный круд - будет больше примеров нетривиального кода по ЭП.
Но это я днём руками работают. А ночью думаю. Что взять на замену функциональной архитектуре. И у меня тут появилась идея CQTS Principle - Command-Query-Transformation Principle.
Берём старый добрый CQS скрещиваем его со сбалансированной формой системы и получаем профит. Это пока мысль в слух - не знаю стоит ли дальше этот термин педалировать или ну его.
#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code
Heartbeat-пост.
Я жив. И канал жив. И Эргономичный подход жив.
Затишье в последнее время связано в основном с тем, что я в Trainer Adviser пилю интеграцию с ical-календарями.
Там не то чтобы прям рокетсайнс, но уже и не совсем тривиальный круд - будет больше примеров нетривиального кода по ЭП.
Но это я днём руками работают. А ночью думаю. Что взять на замену функциональной архитектуре. И у меня тут появилась идея CQTS Principle - Command-Query-Transformation Principle.
Берём старый добрый CQS скрещиваем его со сбалансированной формой системы и получаем профит. Это пока мысль в слух - не знаю стоит ли дальше этот термин педалировать или ну его.
#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code
GitHub
Commits · ergonomic-code/Trainer-Advisor
Информационная система йогатерапевта и демонстрационный проект Эргономичного подхода - Commits · ergonomic-code/Trainer-Advisor
❤3👍2
Привет!
Баги, найденные командой QA это:
Баги, найденные командой QA это:
Anonymous Poll
89%
Да норм, не в проде же
11%
Это катастрофа, стыд и позор - девелоперы шипают лажу и куча времени тратится на связанные оверхеды
Эргономичный код
Привет!
Баги, найденные командой QA это:
Баги, найденные командой QA это:
Понимаю, что на самом деле сильно зависит от, но хочу понять общее отношение к багам в сообществе - выберите вариант который вам по духу ближе, пожалуйста.
#ergo_testing@ergonomic_code
#ergo_testing@ergonomic_code
Привет!
Начинаю потихоньку собирать отзывы по #project_r.
Начал с простого - спросил у второго разработчика, которая раньше на Котлин не писала: "Какие у тебя впечатления от Котлина? Не появилось непреодолимого желания переехать на него?:)"
Ответ:
Выделение моё.
В общем если пишите на Java и сомневаетесь нужен ли вам Kotlin - попробуйте:)
#retro@ergonomic_code #project_r@ergonomic_code #kotlin@ergonomic_code
Начинаю потихоньку собирать отзывы по #project_r.
Начал с простого - спросил у второго разработчика, которая раньше на Котлин не писала: "Какие у тебя впечатления от Котлина? Не появилось непреодолимого желания переехать на него?:)"
Ответ:
только положительные 😀
очень много рутиных вещей из джавы уже есть в готовых функциях, читаемость намного лучше, легче конструкции логические всякие городить)
А про переехать 🤔
Если бы меня отправили работать в микросервис на котлине, я бы точно фу не сказала, спокойно бы писала, как и на джаве)
Выделение моё.
В общем если пишите на Java и сомневаетесь нужен ли вам Kotlin - попробуйте:)
#retro@ergonomic_code #project_r@ergonomic_code #kotlin@ergonomic_code
👍7💯6
Привет!
Продолжаю ретроспективить #project_r@ergonomic_code.
Подбил Джиру, собрал немного статистики:
1. всего задач по проекту: 223 - сюда входят и задачи на разработку, и баги, и мусорные задачи и метазадачи
2. задач на разработку по бэку проекта Р: 65
3. багов в бэке проекта Р: 12
4. регрессий в бэке проекта Р: 4
5. всего задач на разработку по бэку основного сервиса: 23
6. всего багов в беке основного сервиса: 28
7. всего регрессий в беке основного сервиса: 3
8. моих задач на разработку по бэку основного проекта: 6
9. моих багов в бэке основного проекта: 5
10. моих регрессий в бэке основного проекта: 2
Это упражнение я проделал для того чтобы проверить тезис "Применение ЭП снижает количество ошибок" и я получил очередное свидетельство этому:
1. отношение задач к ошибкам в сервисе по ЭП: 16/65 = 0.25
2. отношение задач к ошибкам в сервисе не по ЭП: 31/23 = 1.35
3. отношение моих задач к ошибкам в сервисе не по ЭП: 7/6 = 1.17
Тут по цифрам вообще выходит, что багов в 4-5 раз меньше, но, имхо, стоит сделать скидку на мою предвзятость в анализе и не учтённые факторы и сделать более консервативный вывод, что ЭП снижает количество ошибок в 2-3 раза.
Вопрос в том, стоит ли оно того - как показал опрос, большинство разработчиков не видит проблем в ошибках.
По хорошему, чтобы ответить на него, надо как-то привязаться к срокам и деньгам, но в этом проекте сделать этого не получится:
1. наверное, стоит начать с того, что по срокам мы тотально зафейлились🥲 Но по моему мнению, любой другой подход дал бы тот же результат
2. у меня есть данные только по своим трудозатратам, а в проекте участвовали ещё два разработчика
3. нет референса, к которому можно было бы привязаться.
#retro@ergonomic_code #project_r@ergonomic_code #case@ergonomic_code
Продолжаю ретроспективить #project_r@ergonomic_code.
Подбил Джиру, собрал немного статистики:
1. всего задач по проекту: 223 - сюда входят и задачи на разработку, и баги, и мусорные задачи и метазадачи
2. задач на разработку по бэку проекта Р: 65
3. багов в бэке проекта Р: 12
4. регрессий в бэке проекта Р: 4
5. всего задач на разработку по бэку основного сервиса: 23
6. всего багов в беке основного сервиса: 28
7. всего регрессий в беке основного сервиса: 3
8. моих задач на разработку по бэку основного проекта: 6
9. моих багов в бэке основного проекта: 5
10. моих регрессий в бэке основного проекта: 2
Это упражнение я проделал для того чтобы проверить тезис "Применение ЭП снижает количество ошибок" и я получил очередное свидетельство этому:
1. отношение задач к ошибкам в сервисе по ЭП: 16/65 = 0.25
2. отношение задач к ошибкам в сервисе не по ЭП: 31/23 = 1.35
3. отношение моих задач к ошибкам в сервисе не по ЭП: 7/6 = 1.17
Тут по цифрам вообще выходит, что багов в 4-5 раз меньше, но, имхо, стоит сделать скидку на мою предвзятость в анализе и не учтённые факторы и сделать более консервативный вывод, что ЭП снижает количество ошибок в 2-3 раза.
Вопрос в том, стоит ли оно того - как показал опрос, большинство разработчиков не видит проблем в ошибках.
По хорошему, чтобы ответить на него, надо как-то привязаться к срокам и деньгам, но в этом проекте сделать этого не получится:
1. наверное, стоит начать с того, что по срокам мы тотально зафейлились🥲 Но по моему мнению, любой другой подход дал бы тот же результат
2. у меня есть данные только по своим трудозатратам, а в проекте участвовали ещё два разработчика
3. нет референса, к которому можно было бы привязаться.
#retro@ergonomic_code #project_r@ergonomic_code #case@ergonomic_code
🔥5👍4
Привет!
Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.
Я в последнее время много думаю о том, как мне железобетонно обосновать пользу применения ЭП и пока не придумал.
А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).
Я про себя уже начал мондеть, что наткнулся на очередную картинку из головы, но парой абзацев ниже Фаулер сам начал оправдываться, что это гипотеза, и с научной точки зрения паршивая гипотеза. Потому что её невозможно проверить.
А проверить её невозможно, потому что по его (и моему) мнению из 2003 года эффективность разработки надо оценивать как <увеличение выручки бизнеса> - <стоимость разработки>. Но как привязать увеличение выручки к реализованной фичи - хз.
#posts@ergonomic_code
Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.
Я в последнее время много думаю о том, как мне железобетонно обосновать пользу применения ЭП и пока не придумал.
А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).
Я про себя уже начал мондеть, что наткнулся на очередную картинку из головы, но парой абзацев ниже Фаулер сам начал оправдываться, что это гипотеза, и с научной точки зрения паршивая гипотеза. Потому что её невозможно проверить.
А проверить её невозможно, потому что по его (и моему) мнению из 2003 года эффективность разработки надо оценивать как <увеличение выручки бизнеса> - <стоимость разработки>. Но как привязать увеличение выручки к реализованной фичи - хз.
#posts@ergonomic_code
martinfowler.com
bliki: Design Stamina Hypothesis
The value of good software design is economic: you can continue to add new functionality quickly even as the code-base grows in size.
👍4🔥3
Ну и за одно полезняшка - рыба статьи на вики о том как поддержать мультитенантность на базе схем в Spring Data JDBC. Основана на опыте её реализации в #project_r
#spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code #project_r@ergonomic_code
#spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code #project_r@ergonomic_code
Эргономичный подход
Мультитенантность на основе схем (v0.0.0)
Для того чтобы поддержать мультитенантность на основе схем, глобально надо сделать три вещи:
Опционально: завести кастомную аннотацию для бинов обеспечиваюищих мультитенантный режим
Завести ресурс/инфраструктурный компонент, который будет хранить тенанта…
Опционально: завести кастомную аннотацию для бинов обеспечиваюищих мультитенантный режим
Завести ресурс/инфраструктурный компонент, который будет хранить тенанта…
👍3🔥3
Привет!
Полезняшка. А для кого-то может и целых три за раз:)
Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.
Я этим активно пользуюсь - у меня всегда есть ворктри для основной текущей задачи, для быстрых фиксов, и для ревью каждого члена команды. Соответственно между всеми этим активностями можно переключаться по щелку. И не чертыхаться каждый раз, что надо зафетчиться.
А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.
Ноесть была проблема - плагин не умеет в worktrees и по дефолту взрывает всю сборку при запуске из директории со вторичной копией.
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.
И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее
Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка
#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code
Полезняшка. А для кого-то может и целых три за раз:)
Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.
Я этим активно пользуюсь - у меня всегда есть ворктри для основной текущей задачи, для быстрых фиксов, и для ревью каждого члена команды. Соответственно между всеми этим активностями можно переключаться по щелку. И не чертыхаться каждый раз, что надо зафетчиться.
А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.
Но
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.
И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее
// build.gradle.kts
gitProperties {
val dotGit = File(".git")
if (dotGit.isFile) {
val actualGitDir = dotGit.readText().substringAfter("gitdir: ").substringBefore("/worktrees")
this.dotGitDirectory.set(File(actualGitDir))
}
}
Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка
#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code
👍6🔥4
Привет!
Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.
Новость №1
В Trainer Advisor появился второй живой пользователь.
Из хорошего для ЭП это значит, что публичный демо проект стал решать больше реальных проблем реальных людей и, как следствие, стал чуть более приближенным к реальной жизни и чуть более показательным.
А из плохого - фича-реквестов и найденных багов стало в два раза больше, поэтому он стал в два раза активнее требовать моего времени, которое я могу добыть только за счёт сокращения работы над каналом в частности и ЭП в целом.
Тут хочу напомнить, что ко мне можно попасть на менторинг заеду работу над TA (или так: в TA можно устроиться на работу за еду опыт). С вас реализация фич в ТА - с меня аккуратное ревью и обучение разработке в целом. И этим вы можете помочь не только себе и мне, но и всему сообществу, дав мне больше времени для работы над ЭП.
Там по началу надо будет починить пару мелких багов/фич (например этот и эту) чтобы познакомиться с проектом и процессами, а потом в бэклоге у меня пачка на мой взгляд интересных и познавательных задач: интеграция с Goggle Calendar (где надо будет ещё и с OAuth поупражняться), реализация веб-пушей (тут сначала надо будет фронт допилить, но это может я сам успею сделать), реализация отправки сообщений клиентам в телегу (через бизнес-акки или бота).
Но сразу хочу предупредить, что ревью будет дотошное и каждый МР скорее всего будет проходить 2-3+ итерации ревью.
И что делать надо будет не только бэк, но и фронт. Как минимум вёрстку на Twitter Bootstrap (с чем неплохо чат-боты справляются) и, иногда UI-логику на AlpineJS типа такой: 1, 2, 3, 4.
В целом сейчас разбивка строк кода по типам следующая: Kotlin - 81%, html - 14%, css - 3%, js - 2%
Но фронт я ревьювлю уже не так дотошно. Думаю, если вы нагенеряете код гопатычем и он будет работать - я не замечу:)
Новость №2
Я официально стартую второй подход к написанию книги. На этот раз с неофициальной пока что поддержкой проектного менеджера ИД Питер.
Пока что осилил накидать только обновлённый план. Относитесь к нему как к архитектуре проекта на 2-3 человеко-года, сделанной джуном - результат в общих чертах будет напоминать исходную архитектуру, но детали, скорее всего, будут существенно отличаться.
И быстрого прогресса по книге не ожидайте - она будет бороться за мой ограниченный временной бюджет ещё и с ТА, блогом (где у меня план таки дописать пост про SQL в ближайшие пару недель, а потом таки написать ретро #project_r) и двумя детьми.
Кроме того, я под книгу планирую написать отдельную версию ТА, чтобы:
1. коммиты были привязаны к главам
2. API сделать в виде более распространённого JSON over HTTP, а не Тру REST API
3. в целом убрать исторические наслоения и быстрые хаки в коде, чтобы код был образцово-показательным, а не реальным в части компромиссов.
В общем, интуитивно, с учётом всех вводных мне кажется, что писать книгу я буду ещё года 2-3.
Так что стей тюнед, будет интересно:)
А ну и с третьей новостью - там тоже будет интересно (я мастер интриги 😂) - надеюсь в начале июня она таки дозреет:)
#trainer_advisor@ergonomic_code #ergo_book@ergonomic_code
Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.
Новость №1
В Trainer Advisor появился второй живой пользователь.
Из хорошего для ЭП это значит, что публичный демо проект стал решать больше реальных проблем реальных людей и, как следствие, стал чуть более приближенным к реальной жизни и чуть более показательным.
А из плохого - фича-реквестов и найденных багов стало в два раза больше, поэтому он стал в два раза активнее требовать моего времени, которое я могу добыть только за счёт сокращения работы над каналом в частности и ЭП в целом.
Тут хочу напомнить, что ко мне можно попасть на менторинг за
Там по началу надо будет починить пару мелких багов/фич (например этот и эту) чтобы познакомиться с проектом и процессами, а потом в бэклоге у меня пачка на мой взгляд интересных и познавательных задач: интеграция с Goggle Calendar (где надо будет ещё и с OAuth поупражняться), реализация веб-пушей (тут сначала надо будет фронт допилить, но это может я сам успею сделать), реализация отправки сообщений клиентам в телегу (через бизнес-акки или бота).
Но сразу хочу предупредить, что ревью будет дотошное и каждый МР скорее всего будет проходить 2-3+ итерации ревью.
И что делать надо будет не только бэк, но и фронт. Как минимум вёрстку на Twitter Bootstrap (с чем неплохо чат-боты справляются) и, иногда UI-логику на AlpineJS типа такой: 1, 2, 3, 4.
В целом сейчас разбивка строк кода по типам следующая: Kotlin - 81%, html - 14%, css - 3%, js - 2%
Но фронт я ревьювлю уже не так дотошно. Думаю, если вы нагенеряете код гопатычем и он будет работать - я не замечу:)
Новость №2
Я официально стартую второй подход к написанию книги. На этот раз с неофициальной пока что поддержкой проектного менеджера ИД Питер.
Пока что осилил накидать только обновлённый план. Относитесь к нему как к архитектуре проекта на 2-3 человеко-года, сделанной джуном - результат в общих чертах будет напоминать исходную архитектуру, но детали, скорее всего, будут существенно отличаться.
И быстрого прогресса по книге не ожидайте - она будет бороться за мой ограниченный временной бюджет ещё и с ТА, блогом (где у меня план таки дописать пост про SQL в ближайшие пару недель, а потом таки написать ретро #project_r) и двумя детьми.
Кроме того, я под книгу планирую написать отдельную версию ТА, чтобы:
1. коммиты были привязаны к главам
2. API сделать в виде более распространённого JSON over HTTP, а не Тру REST API
3. в целом убрать исторические наслоения и быстрые хаки в коде, чтобы код был образцово-показательным, а не реальным в части компромиссов.
В общем, интуитивно, с учётом всех вводных мне кажется, что писать книгу я буду ещё года 2-3.
Так что стей тюнед, будет интересно:)
А ну и с третьей новостью - там тоже будет интересно (я мастер интриги 😂) - надеюсь в начале июня она таки дозреет:)
#trainer_advisor@ergonomic_code #ergo_book@ergonomic_code
Алексей Жидков
Книга: первая версия плана - Алексей Жидков
https://azhidkov.pro/
👍17🔥3❤2
Привет!
#why_kotlin@ergonomic_code #talks@ergonomic_code
Тогда я решил посмотреть на Котлин. И больше не оглядывался [на Java]
— Род Джонсонс, создатель Spring Framework, Kotlin Conf 2025
#why_kotlin@ergonomic_code #talks@ergonomic_code
😱5👍1
Привет!
Полезняшка.
Вы наверняка слышали, что коммиты в гите должны быть маленькими и сфокусированными.
Я про эту идею узнал лет 10 назад минимум. Но всё равно коммиты получались... сильно разные.
Думаю вы и сами прекрасно знаете как так получается - берёшься делать маленькую задачку в один сфокусированный коммит, но походу дела тут что-то подчистил, там что-то подравил, споткнулся о непредвиденное ограничение базового метода, который пришлось подрихтовать и от которого ещё 5 мест зависят и оп - к вечеру уже гора изменений в 30 файлах.
Я как-то пробовал всё равно такие пачки разбивать на коммиты, но тогда идея не умела сплитить чанки, а проваливаться ради этого в консоль не хотелось и если пытаться из горы изменений коммитать только какие-то части - всё равно в некоторых коммитах что-то забывал или добавлял что-то лишние и они получались нерабочие.
В общем я по этому поводу не парился и коммитался как получится.
А в прошлом году я узнал про The Mikado Method больших рефакторингов.
Суть идеи в том, что вы первым делом делаете целевое изменение, смотрите что ломается, откатываете исходное изменение, делаете следующее изменение, которое чинит поломку, смотрите что опять сломалось, откатываете второе изменение, делаете третье изменение и т.д.
Я попробовал эту штуку, но для меня это вышло как-то гемморойно.
Однако этот метод подтолкнул меня к версии создания сфокусированных коммитов, с приемлимым для меня кол-вом оверхеда и геммороя.
Выглядит он так:
1. пилите фичу до победного ваще не парясь про размер
2. шелвите всё что есть.
3. глазами просматриваете изменения в шелве выглядывая там сфокусированные коммиты и их примерный порядок
4. аншелвите изменения первого вспомогательного коммита, прогоняете тесты, коммитаете
5. повторяете п. 4 пока не закоммитаете все предварительные изменения
6. аншелвите изменения целиком (решая конфликты идеевской волшебной палочкой), ещё раз просматриваете, что там нет ничего лишнего и коммитаете финальный коммит
6.1 если нашли что-то лишнее - повторить с п. 2
Эта процедура в зависимости от тяжести случая занимает от 15 минут до пары часов, но даёт таки сфокусированные коммиты.
Это не то чтобы прям гениальное изобретение, но я 10 лет не мог додуматься - может кому-то сэкономлю пару лет:)
#tips@ergonomic_code #git@ergonomic_code
Полезняшка.
Вы наверняка слышали, что коммиты в гите должны быть маленькими и сфокусированными.
Я про эту идею узнал лет 10 назад минимум. Но всё равно коммиты получались... сильно разные.
Думаю вы и сами прекрасно знаете как так получается - берёшься делать маленькую задачку в один сфокусированный коммит, но походу дела тут что-то подчистил, там что-то подравил, споткнулся о непредвиденное ограничение базового метода, который пришлось подрихтовать и от которого ещё 5 мест зависят и оп - к вечеру уже гора изменений в 30 файлах.
Я как-то пробовал всё равно такие пачки разбивать на коммиты, но тогда идея не умела сплитить чанки, а проваливаться ради этого в консоль не хотелось и если пытаться из горы изменений коммитать только какие-то части - всё равно в некоторых коммитах что-то забывал или добавлял что-то лишние и они получались нерабочие.
В общем я по этому поводу не парился и коммитался как получится.
А в прошлом году я узнал про The Mikado Method больших рефакторингов.
Суть идеи в том, что вы первым делом делаете целевое изменение, смотрите что ломается, откатываете исходное изменение, делаете следующее изменение, которое чинит поломку, смотрите что опять сломалось, откатываете второе изменение, делаете третье изменение и т.д.
Я попробовал эту штуку, но для меня это вышло как-то гемморойно.
Однако этот метод подтолкнул меня к версии создания сфокусированных коммитов, с приемлимым для меня кол-вом оверхеда и геммороя.
Выглядит он так:
1. пилите фичу до победного ваще не парясь про размер
2. шелвите всё что есть.
3. глазами просматриваете изменения в шелве выглядывая там сфокусированные коммиты и их примерный порядок
4. аншелвите изменения первого вспомогательного коммита, прогоняете тесты, коммитаете
5. повторяете п. 4 пока не закоммитаете все предварительные изменения
6. аншелвите изменения целиком (решая конфликты идеевской волшебной палочкой), ещё раз просматриваете, что там нет ничего лишнего и коммитаете финальный коммит
6.1 если нашли что-то лишнее - повторить с п. 2
Эта процедура в зависимости от тяжести случая занимает от 15 минут до пары часов, но даёт таки сфокусированные коммиты.
Это не то чтобы прям гениальное изобретение, но я 10 лет не мог додуматься - может кому-то сэкономлю пару лет:)
#tips@ergonomic_code #git@ergonomic_code
Manning Publications
The Mikado Method
The Mikado Method</i> is a book written by the creators of this process. It describes a pragmatic, straightforward, and empirical method to plan and perform non-trivial technical improvements on an existing software system. The method has simple rules, but…
❤4👍2
Привет!
Вы уже запомнили как расшифровывается IODA-архитектура?:)
Вот вам ещё акроним, чтобы блеснуть на собесе эрудицией - self-contained systems (SCS) architecture.
Судя по слайду из картинки - это просто нормальная (микро) сервисная архитектура, сделанная квалифицированными инженерами для того чтобы самим её саппорить. Но... Больше архитектур богу архитектур:)
#talks@ergonomic_code
Вы уже запомнили как расшифровывается IODA-архитектура?:)
Вот вам ещё акроним, чтобы блеснуть на собесе эрудицией - self-contained systems (SCS) architecture.
Судя по слайду из картинки - это просто нормальная (микро) сервисная архитектура, сделанная квалифицированными инженерами для того чтобы самим её саппорить. Но... Больше архитектур богу архитектур:)
#talks@ergonomic_code
😱1
Привет!
Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!
Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.
#posts@ergonomic_code
Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!
Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.
#posts@ergonomic_code
Алексей Жидков
Учимся читать SQL SELECT - Алексей Жидков
https://azhidkov.pro/
❤7👍3
Привет!
Жутиков вам в утреннюю ленту.
В текущем мастере Хибера 1.3М строк Java-кода:
#whynotjpa@ergonomic_code #tools@ergonomic_code
Жутиков вам в утреннюю ленту.
В текущем мастере Хибера 1.3М строк Java-кода:
atomic-armchair : ~/tmp > git clone https://github.com/hibernate/hibernate-orm.git
Cloning into 'hibernate-orm'...
remote: Enumerating objects: 763047, done.
remote: Counting objects: 100% (333/333), done.
remote: Compressing objects: 100% (162/162), done.
remote: Total 763047 (delta 243), reused 171 (delta 171), pack-reused 762714 (from 2)
Receiving objects: 100% (763047/763047), 281.04 MiB | 2.20 MiB/s, done.
Resolving deltas: 100% (471253/471253), done.
atomic-armchair : ~/tmp > cloc hibernate-orm/
17126 text files.
17002 unique files.
204 files ignored.
github.com/AlDanial/cloc v 2.04 T=25.71 s (661.3 files/s, 77566.1 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Java 15603 266991 243111 1348435
AsciiDoc 128 10432 660 32337
XML 816 4135 4441 25428
XSD 21 3912 1455 22496
SVG 29 11 28 6548
Gradle 41 788 436 3426
CSS 7 176 184 3164
SQL 218 401 346 2981
ANTLR Grammar 8 414 698 1760
Bourne Shell 13 222 427 1599
Text 46 322 0 1354
Properties 34 179 257 952
DTD 2 143 185 805
YAML 6 37 77 588
Groovy 5 75 63 367
Markdown 6 114 6 302
HTML 2 24 4 256
Maven 7 33 24 225
DOS Batch 2 42 4 138
Dockerfile 5 20 145 75
JavaScript 1 6 0 52
Kotlin 2 6 4 25
-------------------------------------------------------------------------------
SUM: 17002 288483 252555 1453313
-------------------------------------------------------------------------------
#whynotjpa@ergonomic_code #tools@ergonomic_code
😱11
Привет!
Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
😁4
Эргономичный код
Привет! Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Кстати, я с предыдущим постом про Чистую архитектуру на 50+ рейтинга попал в программу поддержки авторов и теперь мне при рейтинге поста от 30 накидывают по 3 т.р., а от 50 - по 5 т.р. - так что можете поддержать меня и канал простым кликом:) И вам не сложно, и мне приятно:)
🏆4🔥2