Сколько лет в теме software design, и всё больше убеждаюсь, что когда дизайном и архитектурой занимается в проекте больше одного человека, то второй третий ... N-й умник всегда начинает спорить, чтобы настоять на своём или доказать, что другой неправ. Поэтому качество, ясность и чистота software design, созданного одним человеком, сразу нарушается, едва к работе подключаются другие люди.
Дизайн быстро загрязняется "улучшениями", альтернативами, рекомендациями "о нуждах пользователей", использованием "уже готовых библиотек", непрошенными советами по масштабируемости, производительности, надежности и т. д...
Дизайн быстро загрязняется "улучшениями", альтернативами, рекомендациями "о нуждах пользователей", использованием "уже готовых библиотек", непрошенными советами по масштабируемости, производительности, надежности и т. д...
❤41✍26💯14😁6👍5
🤔53🐳9👍8❤1🤓1
Советы для тех, кто хочет использовать F# на работе, но часто получает отказ:
Добровольно беритесь за проекты, которые находятся в плохом состоянии, потому что запаздывают или нуждаются в спасении, а люди боятся...
...при условии, что вы сами выберете инструменты.
Спасите проект, получите многомерную прибыль.
Добровольно беритесь за проекты, которые находятся в плохом состоянии, потому что запаздывают или нуждаются в спасении, а люди боятся...
...при условии, что вы сами выберете инструменты.
Спасите проект, получите многомерную прибыль.
👍54✍16🔥8❤3💯3
Пришла вот такая реклама.
Действительно, правильно назвать переменную -- это как дать имя своему коту: сделать наспех нельзя, а идеального варианта вообще не существует.
Предлагаю такие названия:
самое_главное_значение
очень_важная_переменная_1
это_та_самая_переменная
оЧеРеДнАяПерЕмеНнАя22
я_не_знаю_как_тебя_назвать
мои_данные
что_то_универсальное
столько_вариантов_и_ни_одного_правильного
финальный босс:
наконец_конечное_значение_42
Действительно, правильно назвать переменную -- это как дать имя своему коту: сделать наспех нельзя, а идеального варианта вообще не существует.
Предлагаю такие названия:
самое_главное_значение
очень_важная_переменная_1
это_та_самая_переменная
оЧеРеДнАяПерЕмеНнАя22
я_не_знаю_как_тебя_назвать
мои_данные
что_то_универсальное
столько_вариантов_и_ни_одного_правильного
финальный босс:
наконец_конечное_значение_42
😁76✍7👍6🤔5❤2
Для некоторых разработчиков срывы сроков, низкое качество кода, постоянные конфликты при слиянии, и множество ошибок -- это хороший компромисс, потому что он избавляет их от необходимости работать в команде и писать тесты.
алгоритм алгоритм наш тимлид лежит убитым
верх закорма на стаканы заливаю в мастер пьяный
алгоритм алгоритм наш тимлид лежит убитым
верх закорма на стаканы заливаю в мастер пьяный
❤41😁15🤯8👍7✍5
Ставь китика, если реально используешь Guava в своих проектах.
Это "a set of core Java libraries from Google that includes new collection types (such as multimap and multiset), immutable collections, a graph library, and utilities for concurrency, I/O, hashing, primitives, strings, and more!"
Я её случайно отрыл, когда разбирал в новом курсе на примерах темку потенциальных багов в concurrency.
Это "a set of core Java libraries from Google that includes new collection types (such as multimap and multiset), immutable collections, a graph library, and utilities for concurrency, I/O, hashing, primitives, strings, and more!"
Я её случайно отрыл, когда разбирал в новом курсе на примерах темку потенциальных багов в concurrency.
✍40🤔22🐳10👍5🤓3
Если ваша система общается сразу с несколькими stateful-системами, то поздравляю, вы программист распределённых систем! :)
Только скорее всего вы не имеете об этом никакого сознательного понимания, или даже представления, а что тут вообще происходит "по научному".
А так-то, конечно, когда у вас нету множества общих внешних состояний, параллельное, асинхронное, распределённое программирование будет лёгким и простым. Можно тут поумничать и про топологию сети например, но эти темки хотя и будут полезны в некоторых контекстах, но они путают "трудные" и "лёгкие" части программирования распределённых систем. Как правильно тут рассуждать,
хотел написать пост в вк для всех добавлю в трек по параллельным вычислительным моделям.
Только скорее всего вы не имеете об этом никакого сознательного понимания, или даже представления, а что тут вообще происходит "по научному".
А так-то, конечно, когда у вас нету множества общих внешних состояний, параллельное, асинхронное, распределённое программирование будет лёгким и простым. Можно тут поумничать и про топологию сети например, но эти темки хотя и будут полезны в некоторых контекстах, но они путают "трудные" и "лёгкие" части программирования распределённых систем. Как правильно тут рассуждать,
✍47👍14🔥6❤1
Я закончил первый курс (База:) нового трека по software design 💥
Назвал его "Незримые механизмы логики" : знакомимся с темой, как правильно думать о программе, сознательно разделяя исполнение, код и спецификацию. Многие программы, которые корректны на уровне кода, ошибочны на уровне (подразумеваемых) спецификаций, так как реализуют/предполагают поведение, корректность которого никак не гарантируется. Это ошибка рассуждения, так как нельзя утверждать, что функция корректна, только изучив её код и внешние зависимости (не зная, что она должна делать в рамках всей системы).
Четыре основных раздела + два дополнения.
1. Почему дизайн концептуально отличается от реализации, и что из этого следует.
Отделение интерфейса от реализации. Концептуальное проектирование интерфейсов -- это процесс определения контрактов (соглашений) между различными частями системы без привязки к специфической реализации.
2. Как так получается, что вроде бы давно работающий код всё ещё содержит баги?
Ложная уверенность в исходах. Неполное покрытие тестами. Пять концептуально различающихся моментов, которые обязательно надо тестировать. Засады асинхронного программирования и многопоточности. 10 механизмов синхронизации.
3. Как код, выглядящий просто, может оказаться реально сложным, и как избегать такого.
Разбор на примерах вроде бы простого, но коварного кода.
7 способов, как не доводить простой код до неочевидных ошибок.
Защищаем код от внезапных изменений в требованиях. Три классических подхода.
4. Триплы Хоара как спецификации: вы будете видеть логику и сложность точно также напрямую, как и сам код.
Инвариант цикла. Примеры и задачки по созданию формальных спецификаций от простых до достаточно сложных (композиция и рекурсия).
5. "Знание" кода.
Вы можете нередко услышать, как опытные программисты в разговоре упоминают, что одна часть их кода "знает" о другой части кода. Что имеется в виду?
6 видов зависимостей, разбираем на примерах.
6. Польза абстракций.
Неявные взаимосвязи между частями кода могут быть полезными, если они реализуют хорошую абстракцию. Это могут быть и стандартные паттерны проектирования, и оригинальные абстракции, придуманные разработчиком для удобства.
=
18 заданий (все с разбором), 30+ примеров, много тематических отсылок к СильнымИдеям.
Курс для Java-истов, но в принципе, и C#-истам зайдёт.
Уровень -- крепкий джуниор, ну может быть миддл-лайт.
=
На следующем, втором курсе трека займёмся демистификацией самого процесса проектирования.
Назвал его "Незримые механизмы логики" : знакомимся с темой, как правильно думать о программе, сознательно разделяя исполнение, код и спецификацию. Многие программы, которые корректны на уровне кода, ошибочны на уровне (подразумеваемых) спецификаций, так как реализуют/предполагают поведение, корректность которого никак не гарантируется. Это ошибка рассуждения, так как нельзя утверждать, что функция корректна, только изучив её код и внешние зависимости (не зная, что она должна делать в рамках всей системы).
Четыре основных раздела + два дополнения.
1. Почему дизайн концептуально отличается от реализации, и что из этого следует.
Отделение интерфейса от реализации. Концептуальное проектирование интерфейсов -- это процесс определения контрактов (соглашений) между различными частями системы без привязки к специфической реализации.
2. Как так получается, что вроде бы давно работающий код всё ещё содержит баги?
Ложная уверенность в исходах. Неполное покрытие тестами. Пять концептуально различающихся моментов, которые обязательно надо тестировать. Засады асинхронного программирования и многопоточности. 10 механизмов синхронизации.
3. Как код, выглядящий просто, может оказаться реально сложным, и как избегать такого.
Разбор на примерах вроде бы простого, но коварного кода.
7 способов, как не доводить простой код до неочевидных ошибок.
Защищаем код от внезапных изменений в требованиях. Три классических подхода.
4. Триплы Хоара как спецификации: вы будете видеть логику и сложность точно также напрямую, как и сам код.
Инвариант цикла. Примеры и задачки по созданию формальных спецификаций от простых до достаточно сложных (композиция и рекурсия).
5. "Знание" кода.
Вы можете нередко услышать, как опытные программисты в разговоре упоминают, что одна часть их кода "знает" о другой части кода. Что имеется в виду?
6 видов зависимостей, разбираем на примерах.
6. Польза абстракций.
Неявные взаимосвязи между частями кода могут быть полезными, если они реализуют хорошую абстракцию. Это могут быть и стандартные паттерны проектирования, и оригинальные абстракции, придуманные разработчиком для удобства.
=
18 заданий (все с разбором), 30+ примеров, много тематических отсылок к СильнымИдеям.
Курс для Java-истов, но в принципе, и C#-истам зайдёт.
Уровень -- крепкий джуниор, ну может быть миддл-лайт.
=
На следующем, втором курсе трека займёмся демистификацией самого процесса проектирования.
👍63❤🔥9⚡6❤3🎉3
This media is not supported in the widget
VIEW IN TELEGRAM
🔥42🤔21😁11👍5🤯2
Продолжаю рассказывать донам про сверхвозможности Postgres, которого одного достаточно, чтобы развернуть на нём большую инфраструктуру.
Сейчас выходит немало статей в духе "SQL - это навсегда", где отмечается, что многие из известных NoSQL-технологий уже активно удаляются из кодовых баз BigTech, потому что они не работают.
Сейчас выходит немало статей в духе "SQL - это навсегда", где отмечается, что многие из известных NoSQL-технологий уже активно удаляются из кодовых баз BigTech, потому что они не работают.
❤48👏12👍4🤔2🤯2
Дед сказал собирать вещи, кажется, началось, срочно бежать изучать функциональное программирование: в Node.js добавили поддержку TypeScript.
node foo.ts
node foo.ts
✍49👍8🔥5😁4⚡2
TypeScript прекрасен как язык программирования: мощная система генериков (почти как в Haskell или Scala), статическая типизация с тайп-чекингом в процессе кодирования, тип union, дискриминантное объединение (создание типов с разными наборами полей по условию), и даже можно объявлять static строки :)
На этом фоне ООП курит далеко в стороне.
Да, но под капотом всё ещё JS, и как только вы выходите за пределы TS, чтобы интегрироваться с остальной частью экосистемы JS, начинается сплошная боль и страдание :)
npm и куча нестабильных полусырых библиотек, которые регулярно теряют стабильность каждые несколько месяцев, поскольку экосистема переключается на новую среду выполнения или новую систему сборки. Вам придётся перепробовать с десяток вариантов, прежде чем найти тот, который будет работать хотя бы несколько месяцев.
Возможно как раз, добавление TS в Node.js как-то это всё немного упорядочит.
И позавчера я говорил, какая есть JS-библиотека/фреймворк, которой можно научиться сейчас, а потом просто сосредоточиться на коде, не беспокоясь о том, что он скоро устареет.
На этом фоне ООП курит далеко в стороне.
Да, но под капотом всё ещё JS, и как только вы выходите за пределы TS, чтобы интегрироваться с остальной частью экосистемы JS, начинается сплошная боль и страдание :)
npm и куча нестабильных полусырых библиотек, которые регулярно теряют стабильность каждые несколько месяцев, поскольку экосистема переключается на новую среду выполнения или новую систему сборки. Вам придётся перепробовать с десяток вариантов, прежде чем найти тот, который будет работать хотя бы несколько месяцев.
Возможно как раз, добавление TS в Node.js как-то это всё немного упорядочит.
И позавчера я говорил, какая есть JS-библиотека/фреймворк, которой можно научиться сейчас, а потом просто сосредоточиться на коде, не беспокоясь о том, что он скоро устареет.
🤔40👍14❤7✍2🤓2
Напоминаю, CI/CD - это когда:
1. Систему можно развёртывать на протяжении всего жизненного цикла.
2. Команды отдают приоритет развёртываемости системы, а не новым функциям.
3. Все разработчики имеют быструю автоматизированную обратную связь о готовности системы к деплою.
4. Развёртывание возможно по требованию в любой момент.
1. Систему можно развёртывать на протяжении всего жизненного цикла.
2. Команды отдают приоритет развёртываемости системы, а не новым функциям.
3. Все разработчики имеют быструю автоматизированную обратную связь о готовности системы к деплою.
4. Развёртывание возможно по требованию в любой момент.
❤44✍20👍9🏆2🤔1
Более того ↑ ↑ ↑ немало k8s-проектов, где микросервисов больше, чем пользователей.
От курсанта:
Узнал, что у нас есть целый микросервис, который высчитывает нужно ли поднимать сотруднику з/п и на сколько.
Также, к сожалению, узнал, что в этом сервисе есть ифчик из разряда if employee.LastRaise < 6 месяцев, тогда пересмотр не положен даже, если з/п уже отстает от рыночной.
От курсанта:
Узнал, что у нас есть целый микросервис, который высчитывает нужно ли поднимать сотруднику з/п и на сколько.
Также, к сожалению, узнал, что в этом сервисе есть ифчик из разряда if employee.LastRaise < 6 месяцев, тогда пересмотр не положен даже, если з/п уже отстает от рыночной.
😁67🤯12🤔7👍2❤1
Сильно сомневаюсь, что ютуб у нас "специально" тормозится: проверить невозможно, а понадувать щёки на этой темке "вот какие мы крутые" самое оно :)
Гугл -- это половина интернета, и постоянно открыто рассказывает, какие у него проблемы с устаревшим оборудованием по всему миру. Думаю, нереально залочить только один его сервис, а тем более как-то "ухудшить". CDN у Google арендует океан компаний (телеграм и порнхаб например), и если пытаться гугла отключить, то в РФ накроется много чего, причём проблем будет гораздо больше нежели с недавнем мировым сбоем Windows (например, упадут все андроид-устройства).
Ростелеком -- владелец MSK-IX (те самые пиринговые стыки), и другие владельцы магистральных сетей связи последние годы активно вкладываются в своё развитие (и офигевают от подобных "инициатив", но помалкивают), питерские напрямую трафик гонят с Франкфуртом и Амстердамом, странно если вдруг их принудительно заставят что-то там у себя ломать.
Впрочем, подозреваю, "официальные" планы имеют под собой внушительных лоббистов (рейдерский отжим трафика:), которые потом будут например предоставлять к ютубу и прочим быстрый доступ в России за денежку (через православный впн).
В Китае кстати ютуб забанен/тормозится, однако там имеется немало успешных ютуберов-миллионников 😎
Гугл -- это половина интернета, и постоянно открыто рассказывает, какие у него проблемы с устаревшим оборудованием по всему миру. Думаю, нереально залочить только один его сервис, а тем более как-то "ухудшить". CDN у Google арендует океан компаний (телеграм и порнхаб например), и если пытаться гугла отключить, то в РФ накроется много чего, причём проблем будет гораздо больше нежели с недавнем мировым сбоем Windows (например, упадут все андроид-устройства).
Ростелеком -- владелец MSK-IX (те самые пиринговые стыки), и другие владельцы магистральных сетей связи последние годы активно вкладываются в своё развитие (и офигевают от подобных "инициатив", но помалкивают), питерские напрямую трафик гонят с Франкфуртом и Амстердамом, странно если вдруг их принудительно заставят что-то там у себя ломать.
Впрочем, подозреваю, "официальные" планы имеют под собой внушительных лоббистов (рейдерский отжим трафика:), которые потом будут например предоставлять к ютубу и прочим быстрый доступ в России за денежку (через православный впн).
В Китае кстати ютуб забанен/тормозится, однако там имеется немало успешных ютуберов-миллионников 😎
✍46😁14🤔10👍5❤2
Смешная история, как микрософты 10 лет пытались пофиксить баг производительности в F# , и в этом году наконец таки закрыли тикет )))
Что ни в коей мере не умаляет крутости F# самого по себе:
- Система типов: мощность Rust + простота TypeScript;
- Выразительность и эргономичность: ощущение будто пишешь стенографию;
- Прагматичность: полный доступ ко всей инфраструктуре .NET.
P.S. В этом ноябре закончится поддержка .NET 6, но зато доступна .NET 9 превью-6.
Что ни в коей мере не умаляет крутости F# самого по себе:
- Система типов: мощность Rust + простота TypeScript;
- Выразительность и эргономичность: ощущение будто пишешь стенографию;
- Прагматичность: полный доступ ко всей инфраструктуре .NET.
P.S. В этом ноябре закончится поддержка .NET 6, но зато доступна .NET 9 превью-6.
❤35🤔17👍11🤓4🫡1
Пишите больше модульных тестов, нежели интеграционных.
Или нет?
Write tests. Not too many. Mostly integration.
Или нет?
Интеграционные тесты -- это скам :)
Или нет?
А Google и Twitter вообще давно заявляли, что "интеграционный тест" — это бесполезный термин.
Скоро в СильныхИдеях расскажу курсантам, как формализовать (несомненно, ценное) понятие "интеграционный тест".
Или нет?
Write tests. Not too many. Mostly integration.
Или нет?
Интеграционные тесты -- это скам :)
Или нет?
А Google и Twitter вообще давно заявляли, что "интеграционный тест" — это бесполезный термин.
Скоро в СильныхИдеях расскажу курсантам, как формализовать (несомненно, ценное) понятие "интеграционный тест".
🤔46✍7👍5❤🔥4❤1
Ну хорошо, getActiveUsers() выполняет запрос к базе данных, тесты его как будем считать?
Anonymous Poll
40%
модульные
60%
интеграционные
🤔42👌5❤1
Власти Швейцарии потребовали, чтобы весь государственный софт был опенсорсным: "public money, public code" (интересно будет на него посмотреть, кстати).
💯 у нас такое в принципе невозможно и никогда не будет, потому что имеется 100500 "объективных" причин ("Батарея не стреляла по 15 причинам. Во-первых, не было снарядов...").
Во-первых, это как мы будем всем показывать такой говнокод?..
💯 у нас такое в принципе невозможно и никогда не будет, потому что имеется 100500 "объективных" причин ("Батарея не стреляла по 15 причинам. Во-первых, не было снарядов...").
Во-первых, это как мы будем всем показывать такой говнокод?..
😁75👍8🤔2❤1❤🔥1