image_2022-07-12_09-30-36.png
3.2 KB
Привет!
Вес взят! Нас теперь 201:) На всякий случай зафиксирую, чтобы не получилось как в прошлый раз:)
Заодно пара ссылок на избитые темы.
Анкл Боб не исопльзует моки
Ещё мужик против IAbstraction
А вот альтернативное мнение на счёт интерфейсов
#posts@ergonomic_code #ergo_approach@ergonomic_code
Вес взят! Нас теперь 201:) На всякий случай зафиксирую, чтобы не получилось как в прошлый раз:)
Заодно пара ссылок на избитые темы.
Анкл Боб не исопльзует моки
Ещё мужик против IAbstraction
А вот альтернативное мнение на счёт интерфейсов
#posts@ergonomic_code #ergo_approach@ergonomic_code
🎉4
И ещё мысль в слух: разделение бизнес-логики и ввода-вывода - это тоже следование SRP, которое повышает потенциал переиспользование и того и другого
Привет!
Моему маленькому, но гордому индивидуальному предприятию сегодня исполняется 5 лет!:)
История, конечно, не терпит сослагательного наклонения, но я думаю, что останься я в найме, вероятность появления Эргономичного подхода была бы сильно ниже.
Моему маленькому, но гордому индивидуальному предприятию сегодня исполняется 5 лет!:)
История, конечно, не терпит сослагательного наклонения, но я думаю, что останься я в найме, вероятность появления Эргономичного подхода была бы сильно ниже.
🎉16
Привет!
Я сейчас ковыряюсь с легаси проектом, и мне второй месяц не даёт покоя то, что оригинальные авторы запилили RPC over RabbitMQ.
Накатал микропост с разбором этого подхода.
За одно апдейт по статусу постов - написал первый черновик поста "Эргономичный подход к ООП и ООД", который станет обоснованием к посту с методикой декомпозиции на базе диаграммы эффектов.
Но теперь его надо будет полировать и думаю месяц на это в лёгкую уйдет. С учётом того, что я не на 100% уверен, что хочу связываться термином ОО, в силу его расплывчатости
#project_e@ergonomic_code #case@ergonomic_code
Я сейчас ковыряюсь с легаси проектом, и мне второй месяц не даёт покоя то, что оригинальные авторы запилили RPC over RabbitMQ.
Накатал микропост с разбором этого подхода.
За одно апдейт по статусу постов - написал первый черновик поста "Эргономичный подход к ООП и ООД", который станет обоснованием к посту с методикой декомпозиции на базе диаграммы эффектов.
Но теперь его надо будет полировать и думаю месяц на это в лёгкую уйдет. С учётом того, что я не на 100% уверен, что хочу связываться термином ОО, в силу его расплывчатости
#project_e@ergonomic_code #case@ergonomic_code
Telegraph
RPC over RabbitMQ
Привет! Я сейчас ковыряюсь с легаси проектом, и мне второй месяц не даёт покоя то, что оригинальные авторы запилили RPC over RabbitMQ: Что здесь происходит: Это всё происходит в контексте обработки HTTP-запроса Клиентский код отправляет запрос в очередь И…
👍1
Привет!
Линко-пост
Прикольный "научпопный" доклад длязадро... нердов с версией о том, почему ООП стало мейнстримом, а ФП - (пока) нет. Спойлер - случайно и не на всегда:)
Только мужик говорит быстро и слушать сложно:(
Поэтому вот ещё ссылка из доклада на тему ОО/П.
Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.1 If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.
Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!
И прям выжимка-перевод - Кей решал задачу с открытым миром, где новые типы объектов появлялись в системе прямо в рантайме. И тут объекты блистали. Авторы Симулы решали задачи симуляции. И тут объекты тоже блистали.
Только среднестатистическая современная информационная система не является ни открытой, ни симуляцией. Возможно именно поэтому, программируются они в процедурном или функциональном стиле, а не объектном
#talks@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
Линко-пост
Прикольный "научпопный" доклад для
Только мужик говорит быстро и слушать сложно:(
Поэтому вот ещё ссылка из доклада на тему ОО/П.
Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.1 If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.
Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!
И прям выжимка-перевод - Кей решал задачу с открытым миром, где новые типы объектов появлялись в системе прямо в рантайме. И тут объекты блистали. Авторы Симулы решали задачи симуляции. И тут объекты тоже блистали.
Только среднестатистическая современная информационная система не является ни открытой, ни симуляцией. Возможно именно поэтому, программируются они в процедурном или функциональном стиле, а не объектном
#talks@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code
YouTube
Why Isn't Functional Programming the Norm? – Richard Feldman
Richard is a member of the Elm core team, the author of Elm in Action from Manning Publications, and the instructor for the Intro to Elm and Advanced Elm courses on Frontend Masters. He's been writing Elm since 2014, and is the maintainer of several open…
👍3💩1
image_2022-07-29_11-01-13.png
208.5 KB
Привет!
Продолжаю в фоне размышлять о том является ли RPC over RabbitMQ антипаттерном, нагенерял ещё пару мыслей, делюсь.
Нетиповое решение
Я сейчас читаю Building Microservices (кстати, очень крутая книга - в первой же главе пишет что МС это боль и надо начинать с монолита) и там типовым решением для синхронного стиля пишут HTTP/RPC (картинка)
Стримминг
В рамках работы над этим чудо проектом в один момент показалось, что мне нужен стриминг большого объёма данных из одного МС в другой. В итоге обошлось но если бы не обошлось, то на HTTP я бы это без вопросов сделал, а с очередью бы ой вышел
Разделение АПИ
Ещё подумал, что плюсом такого решения является явное разделение АПИ на публичное и приватное. Но на HTTP это тоже можно провернуть (сам не пробовал)
В общем я пока придерживаюсь мнения, что это всё-таки ошибка была.
#case@ergonomic_code
Продолжаю в фоне размышлять о том является ли RPC over RabbitMQ антипаттерном, нагенерял ещё пару мыслей, делюсь.
Нетиповое решение
Я сейчас читаю Building Microservices (кстати, очень крутая книга - в первой же главе пишет что МС это боль и надо начинать с монолита) и там типовым решением для синхронного стиля пишут HTTP/RPC (картинка)
Стримминг
В рамках работы над этим чудо проектом в один момент показалось, что мне нужен стриминг большого объёма данных из одного МС в другой. В итоге обошлось но если бы не обошлось, то на HTTP я бы это без вопросов сделал, а с очередью бы ой вышел
Разделение АПИ
Ещё подумал, что плюсом такого решения является явное разделение АПИ на публичное и приватное. Но на HTTP это тоже можно провернуть (сам не пробовал)
В общем я пока придерживаюсь мнения, что это всё-таки ошибка была.
#case@ergonomic_code
image_2022-08-03_08-05-19.png
238.7 KB
Привет!
Выкинул "первый черновик" (который был на самом деле первой доведённой до конца попыткой) поста с обоснованием декомпозиции на базе диаграммы эффектов.
Написал очередную версию и, кажется (хоть бы, хоть бы) в этот раз наконец успех.
Выкинул "первый черновик" (который был на самом деле первой доведённой до конца попыткой) поста с обоснованием декомпозиции на базе диаграммы эффектов.
Написал очередную версию и, кажется (хоть бы, хоть бы) в этот раз наконец успех.
Заодно находка-любопытка. Вы читали Чистый код анкл Боба? В частности раздел "Антисимметрия данных/объектов"?
Там любопытное написано:
> Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных. Объектно-ориентированный код, напротив, упрощает добавление новых классов без изменения существующих функций.
В любой сложной системе возникают ситуации, когда вместо новых функций в систему требуется включить новые типы данных. Для таких ситуаций объекты и объектно-ориентированное программирование особенно уместны. Впрочем, бывает и обратное — вместо новых типов данных требуется добавить новые функции. Тогда лучше подходит процедурный код и структуры данных.
Вам не кажется, что в информационных системах чаще требуется добавлять новые функции, чем (варианты) типов данных?
Но в этом случае, естественно, ещё лучше функциональный код и неизменяемые структуры данных
#oop@ergonomic_code #dop@ergonomic_code
Там любопытное написано:
> Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных. Объектно-ориентированный код, напротив, упрощает добавление новых классов без изменения существующих функций.
В любой сложной системе возникают ситуации, когда вместо новых функций в систему требуется включить новые типы данных. Для таких ситуаций объекты и объектно-ориентированное программирование особенно уместны. Впрочем, бывает и обратное — вместо новых типов данных требуется добавить новые функции. Тогда лучше подходит процедурный код и структуры данных.
Вам не кажется, что в информационных системах чаще требуется добавлять новые функции, чем (варианты) типов данных?
Но в этом случае, естественно, ещё лучше функциональный код и неизменяемые структуры данных
#oop@ergonomic_code #dop@ergonomic_code
Привет!
А вот и Фаулер советует стартовать с монолита
Из статьи достаточно прочитать две фразы:
1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
1) Практически все микросервисные истории начинались с монолита, который вырос слишком большим и был разбит (на микросервисы)
2) Практически все случаи, о которых я слышал, где начинали с микросервисов, закончились серьёзными проблемами
#posts@ergonomic_code #why_no_microservices@ergonomic_code
А вот и Фаулер советует стартовать с монолита
Из статьи достаточно прочитать две фразы:
1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
1) Практически все микросервисные истории начинались с монолита, который вырос слишком большим и был разбит (на микросервисы)
2) Практически все случаи, о которых я слышал, где начинали с микросервисов, закончились серьёзными проблемами
#posts@ergonomic_code #why_no_microservices@ergonomic_code
martinfowler.com
bliki: Monolith First
Going directly to a microservices architecture is risky, so consider building a monolithic system first. Split to microservices when, and if, you need it.
👍3
Привет!
Прочитал Building Microservices: Designing Fine-Grained Systems - редкая книга, с содержанием которой я согласен без всяких но, рекомендую:)
#books@ergonomic_code
Прочитал Building Microservices: Designing Fine-Grained Systems - редкая книга, с содержанием которой я согласен без всяких но, рекомендую:)
#books@ergonomic_code
👍1
Привет!
Пост о подходах к декомпозиции уже на финишной прямой и если не случится форс-мажёров, я его опубликую до конца месяца.
А тем временем я накатал микропост с историей своих метаний о том как выполнять декомпозицию.
#posts@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code
Пост о подходах к декомпозиции уже на финишной прямой и если не случится форс-мажёров, я его опубликую до конца месяца.
А тем временем я накатал микропост с историей своих метаний о том как выполнять декомпозицию.
#posts@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code
👍3
Привет!
Свинья везде найдёт грязь, а я - в любой книжке по ООП агитацию за ФП.
В рамках подготовки поста об ОО декомпозиции полез кое-чего глянуть в Object-Oriented Software Construction. И пока искал, наткнулся на раздел "23.1 SIDE EFFECTS IN FUNCTIONS". Там достаточно хорошо описано что такое побочный эффект, чем он опасен и как отделять чистые функции от функций с эффектом (это тот самый CQS, если вы понимаете о чём я).
И вообще в этой книге много мудрости, например OCP анкл Боб взял оттуда (хотя и подменил суть, по большому счёту).
Единственное что, Мейер там сильно заблуждается на счёт значимости и практики применения механизма наследования, но это всеобщее помутнение сознания тех лет (конца 80-ых) и вполне простительно.
В общем рекомендую почитать на досуге.
#books@ergonomic_code #whyfp@ergonomic_code #oop@ergonomic_code
Свинья везде найдёт грязь, а я - в любой книжке по ООП агитацию за ФП.
В рамках подготовки поста об ОО декомпозиции полез кое-чего глянуть в Object-Oriented Software Construction. И пока искал, наткнулся на раздел "23.1 SIDE EFFECTS IN FUNCTIONS". Там достаточно хорошо описано что такое побочный эффект, чем он опасен и как отделять чистые функции от функций с эффектом (это тот самый CQS, если вы понимаете о чём я).
И вообще в этой книге много мудрости, например OCP анкл Боб взял оттуда (хотя и подменил суть, по большому счёту).
Единственное что, Мейер там сильно заблуждается на счёт значимости и практики применения механизма наследования, но это всеобщее помутнение сознания тех лет (конца 80-ых) и вполне простительно.
В общем рекомендую почитать на досуге.
#books@ergonomic_code #whyfp@ergonomic_code #oop@ergonomic_code
Привет!
Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code
Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code
YouTube
"Simple Made Easy" - Rich Hickey (2011)
Rich Hickey, the author of Clojure and designer of Datomic, is a software developer with over 30 years of experience in various domains. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield…
🔥1
Привет!
Зацените чё накапал я ненавижу и работать с АПИ в виде сваггера (оно почти всегда не работает полностью) и уш тем более писать его - пихать в код гору аннотаций для доков к сваггеру, где соотношение сигнал шут 1 к 2 - то ещё удовольствие.
И сам я предпочитаю писать доки на Spring Rest Docs - и собственно текст доков можно нормально писать, и примеры гарантированно рабочие. Но многие привыкли таки к сваггеру и хотят его. А с этим тулом, кажется, можно разом обоих зайцев убить.
#docs@ergonomic_code #spring@ergonomic_code #http_api@ergonomic_code #rest_api@ergonomic_code
Зацените чё накапал я ненавижу и работать с АПИ в виде сваггера (оно почти всегда не работает полностью) и уш тем более писать его - пихать в код гору аннотаций для доков к сваггеру, где соотношение сигнал шут 1 к 2 - то ещё удовольствие.
И сам я предпочитаю писать доки на Spring Rest Docs - и собственно текст доков можно нормально писать, и примеры гарантированно рабочие. Но многие привыкли таки к сваггеру и хотят его. А с этим тулом, кажется, можно разом обоих зайцев убить.
#docs@ergonomic_code #spring@ergonomic_code #http_api@ergonomic_code #rest_api@ergonomic_code
GitHub
GitHub - ePages-de/restdocs-api-spec: Adds API specification support to Spring REST Docs
Adds API specification support to Spring REST Docs - ePages-de/restdocs-api-spec
👍3
Привет!
Довольно часто встречаю у студентов и молодых разработчиков ошибку добавления ИД в таблицу связку: user_roles(id, user_id, role_id).
Раньше я в таких случаях из чисто на основе интуиции говорил "лучше убрать и заменить на составной ключ, потому что ИД нафик не нужен и чуть лишней памяти жрёт".
Сегодня наткнулся на развёрнутый ответ, почему их надо убирать. И ещё на пост о суррогатных вс натуральных ключах в целом
#posts@ergonomic_code #relational_model@ergonomic_code
Довольно часто встречаю у студентов и молодых разработчиков ошибку добавления ИД в таблицу связку: user_roles(id, user_id, role_id).
Раньше я в таких случаях из чисто на основе интуиции говорил "лучше убрать и заменить на составной ключ, потому что ИД нафик не нужен и чуть лишней памяти жрёт".
Сегодня наткнулся на развёрнутый ответ, почему их надо убирать. И ещё на пост о суррогатных вс натуральных ключах в целом
#posts@ergonomic_code #relational_model@ergonomic_code
Java, SQL and jOOQ.
The Cost of Useless Surrogate Keys in Relationship Tables
What’s a good natural key? This is a very difficult question for most entities when you design your schema. In some rare cases, there seems to be an “obvious” candidate, such as a…
❤1
Привет!
Решил взять небольшую паузу в постах и немного позаниматься технической работой.
Начал с того, чтоб обновил список чтения - разбил на несколько подборок, везде добавил ссылок и немного дополнил.
Потом собираюсь сделать небольшие лэндинги для диаграммы Эффектов и Эргономичного подхода и потом вернусь к серии о диаграмме Эффектов, которая, похоже, плавно перетечёт в кейс работы по ЭП - в следующем посте я дам пошаговую инструкцию по декомпозиции на базе эффектов, выполню по ней декомпозицию по TSP и покажу как это ложиться на структуру кода, а потом напишу посты с пошаговым описанием реализации в эргономичном стиле нескольких фич в TSP.
Решил взять небольшую паузу в постах и немного позаниматься технической работой.
Начал с того, чтоб обновил список чтения - разбил на несколько подборок, везде добавил ссылок и немного дополнил.
Потом собираюсь сделать небольшие лэндинги для диаграммы Эффектов и Эргономичного подхода и потом вернусь к серии о диаграмме Эффектов, которая, похоже, плавно перетечёт в кейс работы по ЭП - в следующем посте я дам пошаговую инструкцию по декомпозиции на базе эффектов, выполню по ней декомпозицию по TSP и покажу как это ложиться на структуру кода, а потом напишу посты с пошаговым описанием реализации в эргономичном стиле нескольких фич в TSP.
Алексей Жидков
Что почитать разработчику? - Алексей Жидков
https://azhidkov.pro/
🔥5👍2
Привет!
Я тут вынашиваю страшный план - отказаться от REST-стиля в "бэке одного фронта".
Как я собираюсь это делать:
1) Ядро продолжать так же делать из подсистем-объектов
2) Вокруг ядра сделать слой app, где по конторллеру на каждую страницу/экран/вью
3) урлы будут вида /api/app/login-page/login, api/app/dashboard-page/get-init-data
В общем в некотором смысле вернуться к структуре из этого поста, но сервисы приложения смёржить с контроллерами. Ну либо к пакетированию по компонентам Брауна
Что надеюсь получить:
1) Упростить процесс проектирования. Я давно этим занимаюсь и прочитал пачку книг по РЕСТу, но всё равно буквально в каждом проекте вылазит какая-нибудь штука, над которой я долго грею голову
2) снизить сцепленность ядра. в моём текущем подходе зачастую в подсистему надо тащить зависимость на другую подсистему, только для того чтобы вытащить вложенную сущность для какой-нить админки
3) Повысить удобство для фронтендеров - у них постоянно возникают вопросы что откуда брать для данной конкретной страницы. Тут, надеюсь, не будет. Плюс в доках появится понятное место куда можно будет сиквенс диаграммы работы страницы воткнуть
4) Повысить производительность. Как засунуть в рест один запрос для формы ввода, который вернёт пачку справочников для выпадающего списка - я не очень понимаю. А в эту схему - очень понимаю
Что потеряю и как планирую нивелировать потери
1) идиоматичность. С РЕСТом в целом народ как-то уже разобрался, а тут опять какая-то непонятная хрень. Это я попробую нивелировать за счёт простоты, возможности перенести общие принципы проектирования и постами с описанием идеи и кейсов
2) универсальность. Новому клиенту может не подойти существующее АПИ. Для второго клиента можно будет завести свой набор методов, а для третьего уже спроектировать и прикрутить сверху REST апи
Пока не очень понимаю что делать с методами, которые нужны на разных страницах. Но есть несколько идей:
1) по факту дублировать эндпоинты для них с минимизацией дублирования кода через делегирование в Котлине (и кстати о Котлине - я последнее время работаю с .net и чёт прям устал от NullPointerException - хочу назад в налло-безопстность 😥)
2) оставить такие методы в ядре
3) завести понятие ui-компонента на бэке - урлы вида /api/app/image-component/load
Я пока ещё думаю на эту тему и не уверен, что пойду туда, но возможно в ближайшем времени опробую её на личном проекте. И если опробую - расскажу как впечатления:)
#http_api@ergonomic_code #rest_api@ergonomic_code #ergo_approach@ergonomic_code
Я тут вынашиваю страшный план - отказаться от REST-стиля в "бэке одного фронта".
Как я собираюсь это делать:
1) Ядро продолжать так же делать из подсистем-объектов
2) Вокруг ядра сделать слой app, где по конторллеру на каждую страницу/экран/вью
3) урлы будут вида /api/app/login-page/login, api/app/dashboard-page/get-init-data
В общем в некотором смысле вернуться к структуре из этого поста, но сервисы приложения смёржить с контроллерами. Ну либо к пакетированию по компонентам Брауна
Что надеюсь получить:
1) Упростить процесс проектирования. Я давно этим занимаюсь и прочитал пачку книг по РЕСТу, но всё равно буквально в каждом проекте вылазит какая-нибудь штука, над которой я долго грею голову
2) снизить сцепленность ядра. в моём текущем подходе зачастую в подсистему надо тащить зависимость на другую подсистему, только для того чтобы вытащить вложенную сущность для какой-нить админки
3) Повысить удобство для фронтендеров - у них постоянно возникают вопросы что откуда брать для данной конкретной страницы. Тут, надеюсь, не будет. Плюс в доках появится понятное место куда можно будет сиквенс диаграммы работы страницы воткнуть
4) Повысить производительность. Как засунуть в рест один запрос для формы ввода, который вернёт пачку справочников для выпадающего списка - я не очень понимаю. А в эту схему - очень понимаю
Что потеряю и как планирую нивелировать потери
1) идиоматичность. С РЕСТом в целом народ как-то уже разобрался, а тут опять какая-то непонятная хрень. Это я попробую нивелировать за счёт простоты, возможности перенести общие принципы проектирования и постами с описанием идеи и кейсов
2) универсальность. Новому клиенту может не подойти существующее АПИ. Для второго клиента можно будет завести свой набор методов, а для третьего уже спроектировать и прикрутить сверху REST апи
Пока не очень понимаю что делать с методами, которые нужны на разных страницах. Но есть несколько идей:
1) по факту дублировать эндпоинты для них с минимизацией дублирования кода через делегирование в Котлине (и кстати о Котлине - я последнее время работаю с .net и чёт прям устал от NullPointerException - хочу назад в налло-безопстность 😥)
2) оставить такие методы в ядре
3) завести понятие ui-компонента на бэке - урлы вида /api/app/image-component/load
Я пока ещё думаю на эту тему и не уверен, что пойду туда, но возможно в ближайшем времени опробую её на личном проекте. И если опробую - расскажу как впечатления:)
#http_api@ergonomic_code #rest_api@ergonomic_code #ergo_approach@ergonomic_code
Алексей Жидков
Структура эргономичных программ - Алексей Жидков
Описание основных структур эргономичной кодовой базы
👍1
Привет!
Соскучились? Я тоже:)
Но сейчас пока не до креатива. Даже почитать толком не получается. Поэтому сегодня непроверенный линко-пост. У меня неделю уже лежит в закладках пост по перформансу, сам только по заголовкам пробежался, но кажется он очень крут.
#posts@ergonomic_code
Соскучились? Я тоже:)
Но сейчас пока не до креатива. Даже почитать толком не получается. Поэтому сегодня непроверенный линко-пост. У меня неделю уже лежит в закладках пост по перформансу, сам только по заголовкам пробежался, но кажется он очень крут.
#posts@ergonomic_code
Medium
Performance 101
We are going to explore a variety of aspects of the performance of software systems. This article is a checklist from which you can mix and…
👍1
Привет!
Я почти доделал лендинг для Диаграммы Эффектов, но его надо ещё пополировать.
Зато под руку подвернулась хорошая линка про то, как писать доки:)
#posts@ergonomic_code
Я почти доделал лендинг для Диаграммы Эффектов, но его надо ещё пополировать.
Зато под руку подвернулась хорошая линка про то, как писать доки:)
#posts@ergonomic_code