это тонкий тролинг же

а внизу мне показалось или это лямбда нарисована?

Да, лямбда. Это многоходовочка. Сектанты ФП, перед простым народом подставляют ООПравославную конфессию. Как бы показывая её быдлянскую суть приверженцев ООП, как рисовальщиков на заборах.

многоходовчка

жаль ее смогут понять только фп программисты

жаль ее смогут понять только фп программисты

Нисколько не жаль)

http://microservices.io/patterns/apigateway.html

Здрасте

И вам

hi

кто-то читал working with legacy code книженцию?

Не читал, но вот прям очень хочу

я тоже

Так что присоединяюсь к вопросу

у меня она в todo но никак руки не доберустя

она входит в top 5 всех рекомедуемых книжек потому... не вижу смысла ее нечитать0

вот щас читаю, написана вкусно с юмором)

У меня Эванс еще не осилен

Но он сука скучный, я его на ночь вместо снотворного

я на днях concurrency in practice осилил

годная книга, советую почитать

Но он сука скучный, я его на ночь вместо снотворного

Сложный

Ну, просто прочитать его смысла мало было мне, бывает что-то осознаешь, откроешь его главу и такой "даааа, точно"

Ну, просто прочитать его смысла мало было мне, бывает что-то осознаешь, откроешь его главу и такой "даааа, точно"

я этим летом перечитывал - многие вещи совсем по другому воспринимются

читать вообще полезно

не понимаю разрабов которые ни единой книги не прочитали

Сложный

Не, просто занудный. Он и живьем-то занудно рассказывает, посмотри видосы. И язык у него немного сложнее обычного технического английского. Я часто в словаре ищу толкование слов:)

Не, просто занудный. Он и живьем-то занудно рассказывает, посмотри видосы. И язык у него немного сложнее обычного технического английского. Я часто в словаре ищу толкование слов:)

все так

слушать я его вообще не могу

еще скучнее чтения

Есть такое :)

очень забавно смотреть видос где болтают живой и харизматичный Грэг Янг и скучный Эванс

https://www.infoq.com/interviews/Architecture-Eric-Evans-Interviews-Greg-Young

Всем привет, у меня новая статья про ООП, на этот раз с критикой всем известных приципов SOLID. Заранее благодарен за обратную связь :) http://www.yegor256.com/2017/03/28/solid.html

Всем привет, у меня новая статья про ООП, на этот раз с критикой всем известных приципов SOLID. Заранее благодарен за обратную связь :) http://www.yegor256.com/2017/03/28/solid.html

про OCP чето странное, открыт для изменений - это и передача стратегий в том числе

> Why was it necessary to create a new principle 15 years later with an ambiguous name and a very questionable definition? потому что coheasion не только про объекты, но и вообще про модули. SRP же фокусируется именно на одном объекте. То есть SRP входит в coheasion но это далеко не все. Все валидно. А если с SOLID еще и GRASP разбирать где упоминается и coheasion и coulping то как бы и норм.

> But then it says it should be extendable, literally through implementation inheritance в интерпритации Боба - нет) все строго за счет полиморфизма.

> Honestly, I suspect that this principle was added to SOLID mostly in order to somehow fill the gap between "SO" and "ID." это мега важный принцип с точки зрения подбора абстракций. Эдакий способ проверки качества оных. Без грамотного подбора абстракций не выйдет ни I и S ни O.

> how is all this different from the good old "loose coupling" только вот у coupling есть куча разновидностей и DIP борется только с одной из них.

@yegor256 короч наброс так себе, раньше было лучше

@yegor256 короч наброс так себе, раньше было лучше

понял, буду думать еще)

уоу

@fes0r когда статья про SRP???

@fes0r когда статья про SRP???

блин, да чет как-то все времени нет(

@fes0r есть подборка книг ?:)

@fes0r есть подборка книг ?:)

- Working effectively with legacy code (потому что легаси код мы пладим со вчера на завтра) - Refactorin фаулера - Agile Software Development, Principles, Patterns, and Practices дяди боба про SOLID - Applying UML and patterns от Крэйга Лармана (про GRASP) - XP от кента бэка - Эрик Эванс про DDD - The Goal про теорию ограничений

@fes0r спасибо :) А что насчет Стив Макконнелл "совершенный код" ?

@fes0r спасибо :) А что насчет Стив Макконнелл "совершенный код" ?

Не тратить на него время и не читать, очевидно же

@fes0r спасибо :) А что насчет Стив Макконнелл "совершенный код" ?

как по мне бесполезная книга. Чистый код Дяди боба с точки зрения практичности получше

Понял, спасибо )

ну мол ты если того что в книге не понимаешь - шансы что поймешь очень малы. А если ты это знаешь - то как бы ты и так это знаешь. Профит может быть как от настольной книги если тебе надо красиво обосновать почему код твоих джунов говно

ну мол ты если того что в книге не понимаешь - шансы что поймешь очень малы. А если ты это знаешь - то как бы ты и так это знаешь. Профит может быть как от настольной книги если тебе надо красиво обосновать почему код твоих джунов говно

Я думаю даже джуны избитые трюизмы из книги наизусть знают

Я думаю даже джуны избитые трюизмы из книги наизусть знают

Запоминается правда не с первого раза, но после практики оно идет в голову (само понятие)

Лучше им Ремесло Гудлифа давать

Может лучше худ. литературу читать ?)

ERROR: S client not available

Полезнее точно

Ну тут даже без спора )

Лучше им Ремесло Гудлифа давать

я не читал(

... и ничего не потерял

Мне кажется лучше прививать интерес к хорошому коду, чем пичкать глупыми цитатами и очевидными подходами. Лучше давать, например, "Идеальный Код" Орама

Хм. День фантастики в чатике

Мне кажется лучше прививать интерес к хорошому коду, чем пичкать глупыми цитатами и очевидными подходами. Лучше давать, например, "Идеальный Код" Орама

А чтобы родину не позорили, пускай читают Пушкина и Есенина, да?)

А чтобы родину не позорили, пускай читают Пушкина и Есенина, да?)

Лермонтова и Маяковского

А чтобы родину не позорили, пускай читают Пушкина и Есенина, да?)

Ветер веет с юга И луна взошла, Что же ты, б*ядюга, Ночью не пришла?

Ветер веет с юга И луна взошла, Что же ты, б*ядюга, Ночью не пришла?

Красиво

В рекомендациях @yegor256

это успех

Всем привет, есть вопрос по архитетуре

борокко збс

рококко лучше

Сразу вопрос, чтоб избавить от чтения конкретики: Вопрос будет в следующем: для конкретного многопользовательского веб-сервиса, где у каждого клиента должно быть свое ограниченное информационное-пространство, лучше использовать одну единую БД (и разделять права доступа к данным) или делать для каждого клиента свою базу данных? Подробнее: Одно из хобби -– организация массовых спортивных мероприятий. Конкретнее хронометраж лыжных, вело и беговых марафонов. Мы разрабатываем собственную систему отметки на основе RFID и софт для нее (писал статью на гиктаймс). Часть софта - работает в облаке (сейчас она написана на простом PHP + MySQL/SQLite) Сейчас появились клиенты из Европы - я переписываю софт на Laravel, потому что за последние 4 года сильно повысил навык программирования и хочется убрать весь говнокод из проекта. Софт нужен чтобы вести базу участников гонки, хранить время пересечения отсечек на дистанции, генерировать протоколы результатов, дипломы и тд. В общем - довольно обычный проект в формате «записная книжка». Сейчас софт должен стать многопользовательским. Одно мероприятие - одна база данных со следующими таблицами Участники, Сплиты (время пересечения участником контрольной отсечки) (порядка 10000 записей за 1 мероприятие) Группы, дистанции, команды (три незначительные таблицы) Настройки мероприятия Допустим: есть 30 клиентов из разных городов России. У каждого будет свой доступ к системе. Каждый клиента проводит 3-5 мероприятий в год. Как правильнее сделать архитектуру БД? Можно создать единую базу данных например PostgreSQL (Клиенты, к ним привязаны мероприятия, к ним участники, к ним сплиты, ID всех сущностей инкрементируются до максимума) Можно создавать копию базы данных для каждого мероприятия (например общая база мероприятий и клиентов - на MySQL, а база для каждого конкретного мероприятия - отдельная, либо SQLite - потому что удобно сохранять из облака к себе на комп, либо так же MySQL)

> лучше использовать одну единую БД (и разделять права доступа к данным) или делать для каждого клиента свою базу данных? зависит от количества клиентов

в целом всякие там postgres-ы позволяют тебе аж row-based разграничивать права

> лучше использовать одну единую БД (и разделять права доступа к данным) или делать для каждого клиента свою базу данных? зависит от количества клиентов

зачем делать зависимость от количества

зачем делать зависимость от количества

ну если 2-3 и надо быстро то дешево то проще разые бд. Если больше - то уже есть нюансы

?

зачем делать зависимость от количества

а в чем зависимость? если использовать UUID какие-нибудь?

ну если 2-3 и надо быстро то дешево то проще разые бд. Если больше - то уже есть нюансы

30-40 мероприятий в год

смотри с точки зрения мэйтейнс. Шанс что что-то пойдет не так при накатке миграций например есть. И если тебе надо накатить миграцию на 30 БД это один уровень боли тогда как накатаить миграцию на 1 бд это другой уровень боли

особенно если у тебя одно приложение работает с этими 30-ю бд