Начали с голубей, а чем закончат? И понятно, исследования обоснуют исключительно заботой о парализованных и прочими радостями. А потом у любого маньяка во власти будет отличный инструмент для отправки необходимости что-то обосновывать в корзину.
Спринг всегда был где-то на обочине. Крупные конторы использовали и продвигали JEE, а молодые стартаперы да, пробовали всякую всячину. И да, пробовали они её десятилетиями (а в более широком смысле - тысячелетиями). Но сторонние подходы всегда были и будут очень пёстрыми, самыми разными. И на этом дико разнообразном фоне мы видим в том числе и спринг. Он далеко не победитель среди этой мелочи. Хотя если в конторе все вокруг обязаны использовать спринг, то может показаться, что это "промышленный стандарт".
Но у автора скорее всего уже весь проект на спринге
Ну что вы, автор пишет про чтение данных пользователя из какого-то файлика. И пользователь там один. Для такого "гигантского" проекта действительно нужен спринг :)
спринг реально упрощает разработку
Можете привести пример? С моей колокольни спринг лишь вносит ненужное усложнение. Один из примеров скрытого некорректного поведения рассказал нам автор данной статьи. А ещё больше есть примеров неинтуитивной логики за сценой, которая требует либо погружения в исходники, либо писать на авось, с кучей ошибок, разумеется.
альтернатив мало
Спринг - это тонкая обёртка. Сначала вас садят на так называемые бины, которые неявным образом создаются где-то в глубинах спринга, а потом, когда вас отучили писать что-то вроде new MyObject(), спринг предлагает точно так же прятать и всё остальное. Вот в примере в статье спрятал за тончайшей (и ненужной) обёрткой вызов для проверки пароля, в результате возник косяк с производительностью. И альтернатива таким "прям вот все что мне нужно" штуковинам полно. Главная - просто используйте new MyObject() вместо кучи ненужных аннотаций и конфигурационных файлов.
Эффективность - широкое понятие. Вы заявили про эффективность затрат времени разработчика, но никак не продемонстрировали реальное наличие такой эффективности.
Если говорить проще, то ваш пример не даёт возможности увидеть, как "Интерпретатор позволяет решать более-менее общие задачи". Решение каких-то задач он даёт, но где вы увидели более общие? И если более общих нет, то значит и по критерию эффективности затрат времени разработчика ваш подход получается неэффективным.
Уж и не знаю, заявит ли мне автор снова, что "Знаем, что можно изменить подходы, библиотеки и...", но похоже он не в курсе, что есть целый набор механизмов, позволяющий работать с сессией, а не с отдельными соединениями. Да, при этом придётся выбросить прокладку в виде спринга, но ведь именно она приводит к проблемам, не умея использовать сессию (авторы спринга тоже про неё не слышали?).
Вот так выбор модной библиотеки влияет на результат.
Непонятен смысл статьи. Зачем всё это? Вот что я нашёл:
написать интерпретатор Prolog, такой, что его состояние хранится в переменной
Но зачем хранить состояние в переменной? И где пример эффективности такого подхода? Волк, коза и капуста из примера в статье решаются весьма просто без записи фактов базу. Но даже приведённая программа с записью в базу никак не подчёркивает хоть какие-то преимущества "состояния в переменной". Автор считает, что читатели обязаны внимательно изучить весь код и самостоятельно понять, зачем это всё написано? Или он просто забыл добавить пояснения? Ну и испанские слова без перевода тоже несколько напрягают не знающих испанского.
А где место? Мне интересна тема, было бы полезно обсудить. Могу в личку написать, или предложите форум какой-нибудь. Но лучше здесь ответить, а на недоброжелателей болт забить.
Поведение последовательности в среднем и так давно понятно. Но вы не показали гарантии отсутствия отличающихся от средних последовательностей. Пример - в среднем все звёзды излучают свет, но некоторые становятся чёрными дырами. Это про отклонения от среднего.
Вы рассуждаете про идеальную нагрузку. Но в реальности обработка различных запросов требует различного времени. Поэтому при циклическом распределении запросов по обработчикам будем иметь недогруженные и перегруженные единицы. Если перегруженная единица пропускает один-два хода, то недогруженные отлично справятся с этими перенесёнными на них запросами.
Сообщать источнику о необходимости тормознуть нагрузку - вполне разумный подход. Пример - балансировщик раздаёт запросы в цикле на все обработчики последовательно, но запросы обрабатываются за разное время, поэтому какому-то обработчику поплохеет и он либо упадёт, либо скажет балансировщику прекратить нагружать себя. Второй вариант явно лучше.
Другое дело, что вместо примитивнейшего анализа результата вызова функции разного рода реакторы предлагают сложную конструкцию из десятков описанных в статье интерфейсов и к ним какой-то сложной логики. Зачем нам такие предложения - непонятно, ну и статья ничего не проясняет.
Вы строите локальный мир, удобный для вас. Вы это понимаете?.
Вопрос "зачем" важен для акционеров конторы. Вы выступаете в роли доброго малого, помогающего акционерам жить вольготно. Да, вам за это платят, и это в некотором смысле оправдание для вас. Но тем, кто выше вас по должности, платят во много раз больше, и именно они во множестве случаев игнорируют проблемы в ТЗ, про которые вы пишете "зачем ты это сделал". Даже не просто игнорируют, они генерируют входящие требования, которые уже послушно записывает и как-то оформляет очередной аналитик. Вы исправляете их ошибки.
Но бардак вокруг умных людей убивает психологически, поэтому они вынуждены исправлять ошибки, текущие бурным потоком сверху. Рационально? Глобально - нет. Но на локальном уровне "задача получить максимум из имеющейся ситуации" вы как-то справляетесь.
Как аналитик вы должны понимать разницу в эффективности между локальной оптимизацией и глобальной. Как умный человек вы должны понимать глупость ситуации, в которой все вокруг заняты исключительно локальной оптимизацией. Ну а как рационально действующий (в очень узких рамках доступного) субъект, вы обязаны оптимизировать своё окружение под себя, чем помогаете локально оптимизировать выгоды всем выше стоящим, то есть ещё сильнее отдаляете идеал в виде глобальной оптимизации.
Вас радует жизнь такой шестерёнки в чужом механизме?
Хотя да, деньги позволяют забыться. Плюс жена, дети, ипотека. Ну и вечный бардак вокруг. Если не думать, то сразу становится легко. И те кандидаты, которых вы отсеяли, по части "не думать" гораздо лучше вас локально оптимизировали свою жизнь. Они счастливее вас. Задевает ли умного человека такое положение? Или он увлёкся теоремами Вейерштрасса и обо всём остальном забыл?
Ладно, не буду зудеть. Но было бы неплохо глобально оптимизировать этот мир.
А нужны ли такие аналитики, каких ищет автор? Зачем они в современном мире? Неужели есть где-то контора, которой реально полезны глубокий анализ и системный подход?
Мне жаль автора. Он ищет умных людей. А фирме нужны сговорчивые исполнители. Автор об этом подозревает, но либо в конторе бардак и ему позволено вольничать, либо выше кто-то из таких же, но во втором случае работает бардак уже на его уровне. Третьего не дано. К сожалению.
Поэтому в среднем по данной больнице наблюдаем вопль возмущения в комментариях - как, я же умный, я всегда отвечал как автору не нравится и всегда имел хорошую з/п, а он тут меня окунает лицом в нечистоты! Ладно, не так жёстко, но в целом имеем именно возмущение и возражения по той же причине.
Было бы интересно понять, на сколько далёк автор от понимания реальности. Варианты следующие:
Не ведает
Что-то подозревает
Понимает основы, но не видит общей картины
Я вообще за разумных коллег, но реальность такова, что разум конторам обычно не нужен. Даже если они пишут обратное в требованиях к вакансии. Уж не на эти ли требования повёлся автор?
Начали с голубей, а чем закончат? И понятно, исследования обоснуют исключительно заботой о парализованных и прочими радостями. А потом у любого маньяка во власти будет отличный инструмент для отправки необходимости что-то обосновывать в корзину.
Спринг всегда был где-то на обочине. Крупные конторы использовали и продвигали JEE, а молодые стартаперы да, пробовали всякую всячину. И да, пробовали они её десятилетиями (а в более широком смысле - тысячелетиями). Но сторонние подходы всегда были и будут очень пёстрыми, самыми разными. И на этом дико разнообразном фоне мы видим в том числе и спринг. Он далеко не победитель среди этой мелочи. Хотя если в конторе все вокруг обязаны использовать спринг, то может показаться, что это "промышленный стандарт".
Ну что вы, автор пишет про чтение данных пользователя из какого-то файлика. И пользователь там один. Для такого "гигантского" проекта действительно нужен спринг :)
Можете привести пример? С моей колокольни спринг лишь вносит ненужное усложнение. Один из примеров скрытого некорректного поведения рассказал нам автор данной статьи. А ещё больше есть примеров неинтуитивной логики за сценой, которая требует либо погружения в исходники, либо писать на авось, с кучей ошибок, разумеется.
Спринг - это тонкая обёртка. Сначала вас садят на так называемые бины, которые неявным образом создаются где-то в глубинах спринга, а потом, когда вас отучили писать что-то вроде new MyObject(), спринг предлагает точно так же прятать и всё остальное. Вот в примере в статье спрятал за тончайшей (и ненужной) обёрткой вызов для проверки пароля, в результате возник косяк с производительностью. И альтернатива таким "прям вот все что мне нужно" штуковинам полно. Главная - просто используйте new MyObject() вместо кучи ненужных аннотаций и конфигурационных файлов.
Это точно. И ещё масло тоже масленное.
Эффективность - широкое понятие. Вы заявили про эффективность затрат времени разработчика, но никак не продемонстрировали реальное наличие такой эффективности.
Если говорить проще, то ваш пример не даёт возможности увидеть, как "Интерпретатор позволяет решать более-менее общие задачи". Решение каких-то задач он даёт, но где вы увидели более общие? И если более общих нет, то значит и по критерию эффективности затрат времени разработчика ваш подход получается неэффективным.
Я про строчку ничего не говорил. И про можно или нельзя не говорил. Я лишь указал на гибельное влияние моды.
Хотя возможно вы против использования сессии? Или ещё как-то оригинально смотрите на мир?
Уж и не знаю, заявит ли мне автор снова, что "Знаем, что можно изменить подходы, библиотеки и...", но похоже он не в курсе, что есть целый набор механизмов, позволяющий работать с сессией, а не с отдельными соединениями. Да, при этом придётся выбросить прокладку в виде спринга, но ведь именно она приводит к проблемам, не умея использовать сессию (авторы спринга тоже про неё не слышали?).
Вот так выбор модной библиотеки влияет на результат.
Непонятен смысл статьи. Зачем всё это? Вот что я нашёл:
Но зачем хранить состояние в переменной? И где пример эффективности такого подхода? Волк, коза и капуста из примера в статье решаются весьма просто без записи фактов базу. Но даже приведённая программа с записью в базу никак не подчёркивает хоть какие-то преимущества "состояния в переменной". Автор считает, что читатели обязаны внимательно изучить весь код и самостоятельно понять, зачем это всё написано? Или он просто забыл добавить пояснения? Ну и испанские слова без перевода тоже несколько напрягают не знающих испанского.
А что вам интересно?
А где место? Мне интересна тема, было бы полезно обсудить. Могу в личку написать, или предложите форум какой-нибудь. Но лучше здесь ответить, а на недоброжелателей болт забить.
Я не вижу смысла в реакторе, поэтому никогда с ним не работал.
Поведение последовательности в среднем и так давно понятно. Но вы не показали гарантии отсутствия отличающихся от средних последовательностей. Пример - в среднем все звёзды излучают свет, но некоторые становятся чёрными дырами. Это про отклонения от среднего.
Вы рассуждаете про идеальную нагрузку. Но в реальности обработка различных запросов требует различного времени. Поэтому при циклическом распределении запросов по обработчикам будем иметь недогруженные и перегруженные единицы. Если перегруженная единица пропускает один-два хода, то недогруженные отлично справятся с этими перенесёнными на них запросами.
Что неизбежно? Вы затронули сложную тему, но ответ получился крайне поверхностным.
Сообщать источнику о необходимости тормознуть нагрузку - вполне разумный подход. Пример - балансировщик раздаёт запросы в цикле на все обработчики последовательно, но запросы обрабатываются за разное время, поэтому какому-то обработчику поплохеет и он либо упадёт, либо скажет балансировщику прекратить нагружать себя. Второй вариант явно лучше.
Другое дело, что вместо примитивнейшего анализа результата вызова функции разного рода реакторы предлагают сложную конструкцию из десятков описанных в статье интерфейсов и к ним какой-то сложной логики. Зачем нам такие предложения - непонятно, ну и статья ничего не проясняет.
Вы строите локальный мир, удобный для вас. Вы это понимаете?.
Вопрос "зачем" важен для акционеров конторы. Вы выступаете в роли доброго малого, помогающего акционерам жить вольготно. Да, вам за это платят, и это в некотором смысле оправдание для вас. Но тем, кто выше вас по должности, платят во много раз больше, и именно они во множестве случаев игнорируют проблемы в ТЗ, про которые вы пишете "зачем ты это сделал". Даже не просто игнорируют, они генерируют входящие требования, которые уже послушно записывает и как-то оформляет очередной аналитик. Вы исправляете их ошибки.
Но бардак вокруг умных людей убивает психологически, поэтому они вынуждены исправлять ошибки, текущие бурным потоком сверху. Рационально? Глобально - нет. Но на локальном уровне "задача получить максимум из имеющейся ситуации" вы как-то справляетесь.
Как аналитик вы должны понимать разницу в эффективности между локальной оптимизацией и глобальной. Как умный человек вы должны понимать глупость ситуации, в которой все вокруг заняты исключительно локальной оптимизацией. Ну а как рационально действующий (в очень узких рамках доступного) субъект, вы обязаны оптимизировать своё окружение под себя, чем помогаете локально оптимизировать выгоды всем выше стоящим, то есть ещё сильнее отдаляете идеал в виде глобальной оптимизации.
Вас радует жизнь такой шестерёнки в чужом механизме?
Хотя да, деньги позволяют забыться. Плюс жена, дети, ипотека. Ну и вечный бардак вокруг. Если не думать, то сразу становится легко. И те кандидаты, которых вы отсеяли, по части "не думать" гораздо лучше вас локально оптимизировали свою жизнь. Они счастливее вас. Задевает ли умного человека такое положение? Или он увлёкся теоремами Вейерштрасса и обо всём остальном забыл?
Ладно, не буду зудеть. Но было бы неплохо глобально оптимизировать этот мир.
А нужны ли такие аналитики, каких ищет автор? Зачем они в современном мире? Неужели есть где-то контора, которой реально полезны глубокий анализ и системный подход?
Мне жаль автора. Он ищет умных людей. А фирме нужны сговорчивые исполнители. Автор об этом подозревает, но либо в конторе бардак и ему позволено вольничать, либо выше кто-то из таких же, но во втором случае работает бардак уже на его уровне. Третьего не дано. К сожалению.
Поэтому в среднем по данной больнице наблюдаем вопль возмущения в комментариях - как, я же умный, я всегда отвечал как автору не нравится и всегда имел хорошую з/п, а он тут меня окунает лицом в нечистоты! Ладно, не так жёстко, но в целом имеем именно возмущение и возражения по той же причине.
Было бы интересно понять, на сколько далёк автор от понимания реальности. Варианты следующие:
Не ведает
Что-то подозревает
Понимает основы, но не видит общей картины
Я вообще за разумных коллег, но реальность такова, что разум конторам обычно не нужен. Даже если они пишут обратное в требованиях к вакансии. Уж не на эти ли требования повёлся автор?
Из чего вы сделали такой вывод? Вас вогнало во грех впечатление от серенького цвета моего комментария? Это самый сильнодействующий аргумент?
По хорошему, вам бы извиниться. Ну и перечитать мой комментарий.
Энциклопедисты не запоминали ключи от тысячи утилит unix.
Энциклопедист, это человек, умеющий применять широкие знания. А запоминанием орфографического словаря перед энциклопедистом хвастаться не получится.
Вы можете указать физический принцип, который позволяет летать, прилагая меньшие усилия, чем весит аппарат? Для рассматриваемого случая, разумеется.