пусть будет "ООП это когда инстансы классов" и все будут счастливы

Аминь

все просто, на мне есть большой груз ответственности, я лучше хочу понимать обыденные процессы

процессы?

поясни мысль

и причем тут ООП

процессы?

хочется знать так ли я использую вещи, какой посыл в них вкладывали, разобраться в первоисточниках что бы дать себе ответ на эти штуки

ну то есть как и меня тебя интересует "почему я пишу на том на чем пишу, почему люди решили так делать и почему те кто делают по другому - меньшенство"

ну то есть - история развития языков программирования

именно

ведь если считать это эволюцией, знать есть прогресс

а где он куда смотреть хз

ну так может быть сфокусироваться на сборе информации, без необходимости ее пока интерпритировать

ведь если считать это эволюцией, знать есть прогресс

весь граф идей сделать, кто когда от кого отсоединился, кто от кого идей взял

мб я потому и не сделал каких-то своих выводов, недостаточно данных :)

какие факторы влияли на выбор тех или иных подходов

а цель какую ты ставишь?)

очень правильный вопрос!

очень правильный вопрос!

типичный вопрос типичного консультанта) так же как и ответ it depends

а вот и нет

нет, ответ не так важен, как сам вопрос

ответа то мы не знаем, но вопрос есть

не знаю смогу ли донести мысль на странном примере, но в Южном парке была серия, когда "создатель унитазов" на самом деле подразумевал их использование не в ту сторону, вот не хотелось бы узнать что по итогу венец творения каких-то моих интеллектуальных возможнойтей был не верно интерпретирован :) http://www.sp-fan.ru/episode/1601/

десять лет назад академик Редько, в свое время основавший кафедру теории программирования в институте кибернетики КНУ, рассказывал мне много важных вещей, которые я до сих пор пытаюсь осознать

например о "целесообразности", принципе необходимой достаточности, и самом главном принципе программирования: "принципе сохранения инвестиций"

оно звучит как что-то сильно далёкое от математики, но я все больше понимаю, что это просто мы далёкие от математики)

я на 5-м курсе ходил на его спецкурс для второкурсников, и пытался что-то понять из его слов

я приходил и рассказывал, что ооп - фигня, приводил аргументы, 10 лет назад

а он делал странные выводы

он не говорил, что ооп фигня, а он говорил что-то типа "вот видите - закон сохранения инвестиций в действии"

и я просто списивал это на его преклонный возраст

70 лет, не шутки

и только теперь я понимаю насколько он был прав! ооп не имеет значения, а имеет значение только основной принцип: улучшение - это движение в сторону сохранения инвестиций, т.е. затраченое время и ресурсы мы хотим вернуть как можно эффективнее

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

какие выводы я сделал на данный момент для себя: - любой паттерн или подход должен иметь основание быть использованым, а не просто потому что это все делают. мы должны стараться сохранить наши инвестиции, а не просто зря потратить время и деньги на внедрение чего-то популярного - нужно пытаться найти ту математику, которая позволяет нам двигаться в сторону сохранения инвестиций... ну потому что это математика, она не врет

какие выводы я сделал на данный момент для себя: - любой паттерн или подход должен иметь основание быть использованым, а не просто потому что это все делают. мы должны стараться сохранить наши инвестиции, а не просто зря потратить время и деньги на внедрение чего-то популярного - нужно пытаться найти ту математику, которая позволяет нам двигаться в сторону сохранения инвестиций... ну потому что это математика, она не врет

то есть инвестиция в поиск математики для того что бы формализовать процесс передачи знаний и уменьшить "мутацию идей" по ходу?

угу, врубаешься

да но мне как... недалекому программисту придется инвестировать в математику что бы разобраться в программировании.... хотя думаю это всеравно будет эффективнее

просто с мотивацией будут проблемы

тут надо читать хорошую книжку

"Любовь и математика: сердце скрытой реальности"

для мотивации и для изменения хода мыслей радикально в другую сторону

Спасибо, почитаю

Название книги вызыващее. Почти как, "Гарри Поттер и методы рационального мышления" :D Кстати, тоже хорошая книжка

минутка пятничной фигни https://medium.com/@caspervonb/a-brief-totally-accurate-history-of-programming-languages-cd93ec806124

нравится

минутка пятничной фигни https://medium.com/@caspervonb/a-brief-totally-accurate-history-of-programming-languages-cd93ec806124

да но.... история то не линейная) в этом вся сложность)

да но.... история то не линейная) в этом вся сложность)

ну то так, именно что пятничный пост с шутейкой про электрон и паттерны в джаве

не, пост годный) я на него натыкался как-то

ну то так, именно что пятничный пост с шутейкой про электрон и паттерны в джаве

И про руби ?

я бы дополнил, там еще много весёлого

Здравствуйте уважаемые ООП разработчики. Пишу вам со следующим вопросом - как вы относитесь к тому, чтобы инджектить коннекшн к БД в констурктор сервиса? Я пока вижу проблему двух стульев: Если инджектим - то тереям стэйтлесс и иммутабельность, сервис становится зависим от внешней байды Если неинджектим - то приходится дергать коннекшн перед каждым методом из локатора, или еще откуда то + дубляж кода(котоырй можно убрать вынеся получение коннекта в приватный метод) Имею ввиду сервисы работающие с бд и реализующие интерфейс мапперов или репозиториев например

Здравствуйте уважаемые ООП разработчики. Пишу вам со следующим вопросом - как вы относитесь к тому, чтобы инджектить коннекшн к БД в констурктор сервиса? Я пока вижу проблему двух стульев: Если инджектим - то тереям стэйтлесс и иммутабельность, сервис становится зависим от внешней байды Если неинджектим - то приходится дергать коннекшн перед каждым методом из локатора, или еще откуда то + дубляж кода(котоырй можно убрать вынеся получение коннекта в приватный метод) Имею ввиду сервисы работающие с бд и реализующие интерфейс мапперов или репозиториев например

По мне так лучше заинжектить. Ну типа смысл завязываться на локатор? Это ж тогда тестить геморройнее. А если оно получает конекшон стринг в конструкторе - то всё нормально, так как работа с базкой-ответственность этого сервиса. А если он не знает как в неё сходить.. то нафиг он такой вообще на свет родился (был инстанциирован)?)

Здравствуйте уважаемые ООП разработчики. Пишу вам со следующим вопросом - как вы относитесь к тому, чтобы инджектить коннекшн к БД в констурктор сервиса? Я пока вижу проблему двух стульев: Если инджектим - то тереям стэйтлесс и иммутабельность, сервис становится зависим от внешней байды Если неинджектим - то приходится дергать коннекшн перед каждым методом из локатора, или еще откуда то + дубляж кода(котоырй можно убрать вынеся получение коннекта в приватный метод) Имею ввиду сервисы работающие с бд и реализующие интерфейс мапперов или репозиториев например

каким образом ты теряешь стейтлесс и имутабельность в случае с инжектом и не теряешь в случае с локатором?

каким образом ты теряешь стейтлесс и имутабельность в случае с инжектом и не теряешь в случае с локатором?

+

пусть это будет мутабельным и а имутабельнео все остальное)))

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

а также часть кода можно делать имутабельной

и будет место где дергается мутабельная штука возвращается результат (который имутабельный) и дальше работает в имутабельных штуках

каким образом ты теряешь стейтлесс и имутабельность в случае с инжектом и не теряешь в случае с локатором?

Коннекшн может оборваться из за ряда причин + в каких то окружениях может быть недоступен

Коннекшн может оборваться из за ряда причин + в каких то окружениях может быть недоступен

как локатор решает проблему того, что коннекшн может оборваться

По мне так лучше заинжектить. Ну типа смысл завязываться на локатор? Это ж тогда тестить геморройнее. А если оно получает конекшон стринг в конструкторе - то всё нормально, так как работа с базкой-ответственность этого сервиса. А если он не знает как в неё сходить.. то нафиг он такой вообще на свет родился (был инстанциирован)?)

вот я тож склоняюсь ближе к этому, типо какая иммутабельность у сервиса, который рабоатет с конкретнйо бд и конкретными таблицами в ней...это

как локатор решает проблему того, что коннекшн может оборваться

никак, по сути ток можем забыть дернуть метод получения коннекшна гдето

никак, по сути ток можем забыть дернуть метод получения коннекшна гдето

что значит забыть дернуть метод получения?

что значит забыть дернуть метод получения?

ну если мы не инджектим коннекшн, нам нужно его перед каждым запрсом к базе дергать

так у тебя он один раз создаться

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

не будет пересоздаваться подключение же каждый раз

не будет пересоздаваться подключение же каждый раз

Ну зависит от того что а приложение

У меня вот в C# каждый раз будет.

а смысл создавать кучу разных коннектов?

Только там под капотом есть конекшон пул и по факту соединение рваться не будет

Ну то бишь Managed-обёртка задиспоузится и освобид память, а под капотом соединение всё ещё отркытым будет, если процесс живой. Чтоб накладные расходы уменьшить.

не будет пересоздаваться подключение же каждый раз

оно и сейчас не пересоздается, там не сервис локатор на самом деле, а коннекшн фактори, в которой пул соединений

есть задача, организовать пайплайн fetch>validate>covert>export для данных из нескольких источников. Типы данных разные, соответственно и валидаторы, конвертеры и експортеры зависят от типов. Изначально написал так, сделал обертки для данных по одному интерфейсу. Експортерами по очереди вытягиваю данные, врапаю их обертками и запихиваю в очередь. Потом фабрикой по типу данных тащу правильный валидатор и валидирую, результат валидации будет пара- (данные, месадж)его опять ложу в очередь. Если все ок и в кюшке только валидные данные, то из пар вытягиваю данные и запихиваю в кюшку. Конвертер и експортер работают аналогично, то есть имеют фабрику и по типу реализацию подсовывают. Вопрос, в правильном ли направлении думаю. Код на джава и он мягко говоря неприятный, куча кастов и инстанс оф в фабриках =(

я, например, знаю, что монада - это моноид в категории эндофункторов

я, например, знаю, что монада - это моноид в категории эндофункторов

вы так говорите, как будто функторы высшего порядка ортогональны

вы так говорите, как будто функторы высшего порядка ортогональны

это форвард месседж, это не я говорю

Привет. Подскажите как можно сделать нагрузочное тестирование веб приложения, да так, чтобы сэмулировать некоторый юзкейс пользователя, например: авторизация, создание сущности, получение списка сущностей.

Привет. Подскажите как можно сделать нагрузочное тестирование веб приложения, да так, чтобы сэмулировать некоторый юзкейс пользователя, например: авторизация, создание сущности, получение списка сущностей.

ну берешь и пишешь такие нагрузочные тесты)

wrk вроде для этого используют, не?

это как e2e тесты но только их можно запусктаь много много на одно приложение

wrk вроде для этого используют, не?

ммм... не, ну там можно на lua замутить, но.... проще jmeter какой

а может и не проще... есть куча тулов для этого добра на самом деле. С записью запросов и т.д.

Я о том, что может какие-то есть удобные под это дело инструменты.

Я о том, что может какие-то есть удобные под это дело инструменты.

может и есть, гугли)

https://www.google.com/search?q=load+testing+tools

тысячи их

сложная там часть все же тестовые данные запилить + более-менее реалистичное распределение нагрузки замутить

а написать - это любой QA осилит

Используем jmeter, пока не сталкивались с тем что что-то не смогли с его помощью запилить в плане сценария нагрузки

Я о том, что может какие-то есть удобные под это дело инструменты.

яндекс танк нормуль

он как раз враппер над jmeter