Привет!
А вот и Фаулер советует стартовать с монолита
Из статьи достаточно прочитать две фразы:
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
Привет!
Java 19 зарелизали О_О
ещё недавно ток 17ая была
сколько между 7ой и 8ой лет прошло? 4?
Щяс даже Котлин, кажись, раз в год релизается
Туда ещё и структурную канкаренси в инкубаторе впихнули О_О
так глядишь, году к 30, на юбилейной 30ой джаве можно будет жить почти как на Котлине
#tools@ergonomic_code #java@ergonomic_code
Java 19 зарелизали О_О
ещё недавно ток 17ая была
сколько между 7ой и 8ой лет прошло? 4?
Щяс даже Котлин, кажись, раз в год релизается
Туда ещё и структурную канкаренси в инкубаторе впихнули О_О
так глядишь, году к 30, на юбилейной 30ой джаве можно будет жить почти как на Котлине
#tools@ergonomic_code #java@ergonomic_code
image_2022-09-29_09-56-41.png
90.1 KB
Привет!
По ряду причин сейчас нет ресурса на Эргономичный подход, но внезапно PR-повод подъехал с другой стороны:)
Если и вам надо сделать работу быстро и всё равно достаточно хорошо - приходите, свободные специалисты у меня есть
#ergo_approach@ergonomic_code #why_ergo_approach@ergonomic_code
По ряду причин сейчас нет ресурса на Эргономичный подход, но внезапно PR-повод подъехал с другой стороны:)
Если и вам надо сделать работу быстро и всё равно достаточно хорошо - приходите, свободные специалисты у меня есть
#ergo_approach@ergonomic_code #why_ergo_approach@ergonomic_code
❤4
Привет!
Раскрою одну из причин, почему я приостановил проработку Эргономичного подхода.
По сути - у меня появилась возможность на практике проверить тезис, что Эргономичный подход даёт существенный выигрыш в производительности разработчиков.
Я уже несколько раз упоминал в этом канале, что мне достался на саппорт и вывод в прод легась на дотнете. Так вот я умудрился сделать финт ушами и сначала продать РП идею переписывания его по ЭП на Котлине, потом вместе с РП и клиенту. На этом я и буду сфокусирован в ближайшие 4-5 месяцев.
Проект, не вдаваясь в подробности, можно описать как медицинский дневник, который ведут пациенты и могут просматривать врачи.
Объём проекта:
1) примерно человеко-год разработки
2) 42 таблицы
3) 100+ рест эндпоинтов
4) 14 микросервисов
Ключевые проблемы проекта:
1) 0 (ноль) тестов
2) микросервисы. В данном случае они не решают никаких проблем
3) плохая нарезка на микросервисы.
3.1) Больше всего меня поразил метод генерации отчётов, который задействует 5 (пять) микросервисов. А если считать предварительную генерацию токена доступа, то 6
3.2) В целом практически каждый рест эндпоинт в своей работе идёт в 1-2 микросервиса
4) Библиотека shared, задействованная во всех МСах и ещё больше сцепляющая их
5) Взаимодействие между микросервисами на базе RabbitMQ и с протоколом в shared. В результате его сложно дебажить, а изменение нового требует кучу церемоний (поправить shared, собрать-опбликовать, обновить зависимость сервера, обновить сервер, обновить зависимость клиента, обновить клиент, выкатывать их строго вместе)
6) Вертикальная архитектура на базе MediatR. Даже самый простой эндопоинт требует пачку лишних приседаний - класс команды, класс обработчика, класс ответа, класс содержания ответа.
7) По определённым причинам проект заморозили в 19ом году, и он остался на устаревшей и более не поддерживаемой версии дотнета
8) У меня в команде нет экспертизы дотнета
Всё это привело к дико медленной скорости разработки и большому количеству регрессий.
Поэтому продать эту затею было не так уж и сложно, на самом деле.
Как я собираюсь это делать.
В подробностях я пока не спланировал работы, но в общих чертах план примерно следующий:
1) Мы в ближайшее время выводим в прод текущую версию
2) Сейчас у нас основные работы ведутся по созданию админ-панели к системе и часть АПИ мы уже сделали на дотнете, но на прошлой недели я начал заводить бэк на Котлине и в следующем релизе админку мы уже будем делать на Котлине
3) Все новые методы будем делать на Котлине
4) Все большие баги переписывать на Котлин и фиксать там (?)
5) Параллельно в обратном направлении графа зависимостей МСов методично всё переписывать и покрывать тестами. Выкатывать обновлённые методы будем каждый спринт
Сколько это стоит
Точную цифру я не назову, по понятным, причинам, но я планирую осилить эту работу за 3-4 месяца силами себя и двух джунов
Как я буду оценивать результаты
Для меня успех выглядит так: РП и заказчик отвечают утвердительно на вопрос "Видите ли вы на глаз как минимум удвоение скорости разработки?". Понятно, что это субъективно, но это именно то, что я продаю.
Кроме того, я посмотрю кол-во багов и регрессий, а так же среднее время задачи от "In Progress" до "Done" за месяц работы "до" и "после".
Если РП и клиент заметят удвоение на глаз и оно подтвердиться цифра - это будет оглушительный успех
Если РП и клиент не заметят удвоения, а на цифрах оно будет - пойду учиться доносить результаты
Если наоборот - можно так и оставить 😂
Если РП и клиент не заметят удвоения и это не подтвердиться цифрами - ну всё, расходимся
Касательно проработки ЭП - как только я выведу в прод этот проект и у меня устаканится ещё пара моментов, я надеюсь вернуться к практике "30 минут ЭП в день" и потихоньку продолжить двигать и эту тему.
Вот такие дела, пожелайте мне удачи:)
#project_e@ergonomic_code
Раскрою одну из причин, почему я приостановил проработку Эргономичного подхода.
По сути - у меня появилась возможность на практике проверить тезис, что Эргономичный подход даёт существенный выигрыш в производительности разработчиков.
Я уже несколько раз упоминал в этом канале, что мне достался на саппорт и вывод в прод легась на дотнете. Так вот я умудрился сделать финт ушами и сначала продать РП идею переписывания его по ЭП на Котлине, потом вместе с РП и клиенту. На этом я и буду сфокусирован в ближайшие 4-5 месяцев.
Проект, не вдаваясь в подробности, можно описать как медицинский дневник, который ведут пациенты и могут просматривать врачи.
Объём проекта:
1) примерно человеко-год разработки
2) 42 таблицы
3) 100+ рест эндпоинтов
4) 14 микросервисов
Ключевые проблемы проекта:
1) 0 (ноль) тестов
2) микросервисы. В данном случае они не решают никаких проблем
3) плохая нарезка на микросервисы.
3.1) Больше всего меня поразил метод генерации отчётов, который задействует 5 (пять) микросервисов. А если считать предварительную генерацию токена доступа, то 6
3.2) В целом практически каждый рест эндпоинт в своей работе идёт в 1-2 микросервиса
4) Библиотека shared, задействованная во всех МСах и ещё больше сцепляющая их
5) Взаимодействие между микросервисами на базе RabbitMQ и с протоколом в shared. В результате его сложно дебажить, а изменение нового требует кучу церемоний (поправить shared, собрать-опбликовать, обновить зависимость сервера, обновить сервер, обновить зависимость клиента, обновить клиент, выкатывать их строго вместе)
6) Вертикальная архитектура на базе MediatR. Даже самый простой эндопоинт требует пачку лишних приседаний - класс команды, класс обработчика, класс ответа, класс содержания ответа.
7) По определённым причинам проект заморозили в 19ом году, и он остался на устаревшей и более не поддерживаемой версии дотнета
8) У меня в команде нет экспертизы дотнета
Всё это привело к дико медленной скорости разработки и большому количеству регрессий.
Поэтому продать эту затею было не так уж и сложно, на самом деле.
Как я собираюсь это делать.
В подробностях я пока не спланировал работы, но в общих чертах план примерно следующий:
1) Мы в ближайшее время выводим в прод текущую версию
2) Сейчас у нас основные работы ведутся по созданию админ-панели к системе и часть АПИ мы уже сделали на дотнете, но на прошлой недели я начал заводить бэк на Котлине и в следующем релизе админку мы уже будем делать на Котлине
3) Все новые методы будем делать на Котлине
4) Все большие баги переписывать на Котлин и фиксать там (?)
5) Параллельно в обратном направлении графа зависимостей МСов методично всё переписывать и покрывать тестами. Выкатывать обновлённые методы будем каждый спринт
Сколько это стоит
Точную цифру я не назову, по понятным, причинам, но я планирую осилить эту работу за 3-4 месяца силами себя и двух джунов
Как я буду оценивать результаты
Для меня успех выглядит так: РП и заказчик отвечают утвердительно на вопрос "Видите ли вы на глаз как минимум удвоение скорости разработки?". Понятно, что это субъективно, но это именно то, что я продаю.
Кроме того, я посмотрю кол-во багов и регрессий, а так же среднее время задачи от "In Progress" до "Done" за месяц работы "до" и "после".
Если РП и клиент заметят удвоение на глаз и оно подтвердиться цифра - это будет оглушительный успех
Если РП и клиент не заметят удвоения, а на цифрах оно будет - пойду учиться доносить результаты
Если наоборот - можно так и оставить 😂
Если РП и клиент не заметят удвоения и это не подтвердиться цифрами - ну всё, расходимся
Касательно проработки ЭП - как только я выведу в прод этот проект и у меня устаканится ещё пара моментов, я надеюсь вернуться к практике "30 минут ЭП в день" и потихоньку продолжить двигать и эту тему.
Вот такие дела, пожелайте мне удачи:)
#project_e@ergonomic_code
👍13💩1
Привет!
Я тут тихой сапой перечитал рекламирую мной структуру и интерпретацию компьютерных программ.
И я несколько поменял своё мнение о ней. В целом книга действительно крутая и рассматривает все ключевые вопросы программирования.
Однако, на мой взгляд, относительно просто перенести на реальную практику только первые 3 главы, посвящённые общим понятиям программирования.
А вот главы про интерпретацию и компиляцию перенести на реальную практику довольно сложно, если вы ещё не понимаете как это работает.
Наверное поэтому недавно выпустили редакцию с примерами на JavaScript (только на английском). Я её сам не читал, но может быть её будет проще перенести на реальную практику.
Ну и подтверждаю, что русскую версию можно смело читать.
Итого, вердикт:
1) Книга крутая, рекомендую к прочтению как минимум первые 3 главы
2) Главы 4-5 оригинальной версии не факт, что зайдут и будут полезны
3) Можно попробовать прочитать версию на JS-е, скорее всего так будет проще, если вы не умеете в лисп, или не собираетесь глубоко проштудировать эту книгу, с набором всех примеров и выполнением упражнений
#books@ergonomic_code
Я тут тихой сапой перечитал рекламирую мной структуру и интерпретацию компьютерных программ.
И я несколько поменял своё мнение о ней. В целом книга действительно крутая и рассматривает все ключевые вопросы программирования.
Однако, на мой взгляд, относительно просто перенести на реальную практику только первые 3 главы, посвящённые общим понятиям программирования.
А вот главы про интерпретацию и компиляцию перенести на реальную практику довольно сложно, если вы ещё не понимаете как это работает.
Наверное поэтому недавно выпустили редакцию с примерами на JavaScript (только на английском). Я её сам не читал, но может быть её будет проще перенести на реальную практику.
Ну и подтверждаю, что русскую версию можно смело читать.
Итого, вердикт:
1) Книга крутая, рекомендую к прочтению как минимум первые 3 главы
2) Главы 4-5 оригинальной версии не факт, что зайдут и будут полезны
3) Можно попробовать прочитать версию на JS-е, скорее всего так будет проще, если вы не умеете в лисп, или не собираетесь глубоко проштудировать эту книгу, с набором всех примеров и выполнением упражнений
#books@ergonomic_code
Утащил текст про xUnit Patterns в телеграф: https://telegra.ph/Strategiya-testirovaniya-kotoraya-srabotaet-dlya-bolshnistva-proektov-10-13
Telegraph
Стратегия тестирования, которая сработает для большниства проектов
Дочитав SICP, я пошёл делать второй подход к xUnit Test Patterns, т.к. мне надо расписать стратегию тестирования проекта, который я переписываю на Котлин, а она в полной мере ещё не улеглась у меня в голове. Прочитал первый раздел (A Brief Tour) и офигел…
👍3
Привет!
Накатал микропост с описанием плана реинженеринга Проекта Э.
Там в целом никаких великих откровений нет, пожалуй, но надеюсь хоть кто-то хотя бы что-то полезное для себя почерпнёт. Ну и "на безпостье и микропост пост":)
#posts@ergonomic_code #project_e@ergonomic_code
Накатал микропост с описанием плана реинженеринга Проекта Э.
Там в целом никаких великих откровений нет, пожалуй, но надеюсь хоть кто-то хотя бы что-то полезное для себя почерпнёт. Ну и "на безпостье и микропост пост":)
#posts@ergonomic_code #project_e@ergonomic_code
👍3
Привет!
У меня на той недели был полуотпуск, за который я посмотрел кучу видосов и собрал микропост о том, что увидел.
#talks@ergonomic_code
У меня на той недели был полуотпуск, за который я посмотрел кучу видосов и собрал микропост о том, что увидел.
#talks@ergonomic_code
Привет!
Наконец-то деделал лэндинг и спеку для Диаграммы Эффектов.
Плюс на лэндинге выложил ещё один кейс диаграммы реального коммерческого проекта, значительно большего, чем True Story Project
#effects_diagram@ergonomic_code #ergo_approach@ergonomic_code #project_geoservices@ergonomic_code #case@ergonomic_code
Наконец-то деделал лэндинг и спеку для Диаграммы Эффектов.
Плюс на лэндинге выложил ещё один кейс диаграммы реального коммерческого проекта, значительно большего, чем True Story Project
#effects_diagram@ergonomic_code #ergo_approach@ergonomic_code #project_geoservices@ergonomic_code #case@ergonomic_code
Алексей Жидков
Диаграмма эффектов - Алексей Жидков
https://azhidkov.pro/
🔥6