Хорошо, давайте пройдемся по конкретике:
«Обработка данных в памяти Java», «Использование JDBC», «Соединение данных в памяти Java» — в общем-то и всё. В других ЯП нет памяти и коннекторов к БД? Вот скажите, какой именно из 10 пунктов неприменим к другим ЯП?
Почему заголовок такой желтый? Если пишете советы по правильному написанию SQL-запросов, то и статью называйте соответственно. При чем тут вообще Java-программисты?
Чтобы написать запрос, который «положит» базу, не обязательно быть программистом вообще, достаточно просто иметь доступ к БД. Конечно, программистов, неоптимально использующих ресурсы СУБД немало, но если Вы пишете конкретно про Java, до хотя бы статистику какую-то дайте, что именно на Java косячат больше всех, а Си, PHP, Delphi и остальные белые и пушистые.
PS Да, я Java-программист, и судя по отсутствию комментариев по поводу заголовка, хаб Java читают в основном не Java-программисты…
Делал как-то подобное, пробовал SPNEGO. Уже точно не помню, почему не стал использовать, видимо из-за того, что сервер приложений не в домене. В конце концов остановился на JCIFS, настраивается проще, правда не сильно навороченная технология. На случай, если будут с ней проблемы, сохранил в закладки также WAFFLE…
Меткая статья, некоторые замечания прямо за живое задели… С другой стороны, когда читаешь, кажется что жесть и как так можно вообще жить. А когда работаешь — то просто делаешь свое дело, по возможности качественно. Тогда и новые технологии внедряются на старых проектах, и с ИБ находится общий язык, и SOAP наконец-то работает с обеих сторон (а потом снова, и снова, с другими)… На «хорошем» месте работы познаешь одно, на «плохом» дополняешь свой опыт чем-то другим, а в результате понимаешь, что и то и другое одинаково важная часть тебя.
В свою очередь, прошу меня извинить, если тон был излишне резок. Я хотел высказаться не столько против Вас, сколько за ORM. При хорошей реализации (такой, например, как Hibernate), вещь это чрезвычайно мощная и полезная, и должна применяться в абсолютном большинстве случаев, начиная от простеньких утилит и заканчивая, естественно, Enterprise-ами. Другое дело, что даже в абсолютном большинстве есть исключения, что, собственно к вам и относится.
Ну проектов было несколько, но все JEE, более того, некоторые работают в масштабах страны (не России, но всё же...).
1) В основном Oracle, лет 10 назад попадался Infomix
2) Тут до вас запредельно далеко, не более 100 в секунду, обычно меньше, но запросы достаточно тяжелые, например SOAP веб-сервисы с выборкой из БД. Парсинг XML, знаете ли, штука ресурсоемкая, но стандартизация обязывает.
3) Из аналитики — отчеты, формируемые выборками из БД. Существенной разницы не замечено между запуском их через приклад и напрямую SQL-ем в БД, конечно при условии передачи Hibernate-у нативного SQL-а
4) От 1-го до 30-ти разработчиков на разных проектах и разных этапах.
5) Первый Enterprise, на котором я был джуниором 10 лет назад еще работает. Распределенная система из полуторасотни серверов приложений+баз данных, разбросанных регионально. Абсолютно все более поздние проекты сейчас так же находятся в промышленной эксплуатации.
6) Глянул в текущем проекте — 316 таблиц, в некоторых из них 200-300 полей
7) Вот это не считал, сейчас нет времени искать утилиту, если что — попозже. НО! Думаю, что кол-во строк кода — одно из главных преимуществ ORM-фреймворков, так что больше кода — не всегда означает более сложный проект.
Еще раз скажу, что ни в коем случае не претендую на опыт работы со схожими с вашими объемами данных, но моё ИМХО повторю: "небольшие проекты" — это вы чересчур загнули.
По поводу ORM — жиденькая позиция. Например, через Hibernate можно запускать нативный SQL, получая на выходе либо уже готовые сущности, либо нетипизированные объекты. Т.е., кроме высокоуровневого языка Hibernate, дающего на выходе высокоуровневые объекты, можно также детализироваться до чистого SQL, и даже получить ужасно удобный микс — отдать SQL, получить обратно типизированный замапленный объект.
Три ваших абзаца про ORM мне почему-то кажутся чистой теорией. Лично я 10 лет в проектах масштаба предприятия работаю исключительно через ORM Hibernate. 90+ процентов кода вообще не требуют оптимизации, просто потому, что это простые вещи. Если же где-то требуется более внимательный подход к ресурсам или сложные выборки — Hibernate может это сделать, при этом в большинстве случаев не загаживая ваши исходники рутинным перекладыванием объектов.
Я понимаю, что у вас своя специфика и средний JEE-проект по нагрузкам не тянет и десятой доли ваших, но тем не менее, ваша фраза "ORM — это небольшие проекты, где очень быстро можно сделать интерфейс, не знаю, редактирования, да каких-то простых сущностей. " не выдерживает никакой критики. А хуже всего, что новички прочитают авторитетное мнение и возьмут на вооружение. Печально…
И ведь именно уничтожить, а не раздать бесплатно, потому что именно то количество, что ты раздал, у тебя завтра в магазине не купят… А потом кричим, что на планете не хватает ресурсов чтобы прокормить всех…
В данной статье я ставил целью показать, что существует такая проблема
У кого как, лично у меня сложилось впечатление, что статью надо было писать лет 10 назад, а то и больше. Тогда у "проблемы" пула соединений с БД была некая актуальность. Сейчас в большинстве движков/фреймворков/серверов приложений такие вещи включены по-умолчанию. Если крутануть лет на 5-7 (а не на 10) назад, то актуальными были уже кэширование запросов и результатов выборки. Опять же, сейчас это есть почти везде и делается просто путем указания в конфигурации флага включить/выключить. В наше время интересными темами являются вопросы распределенных кэшей.
На мой взгляд, это не столько специфика написания писем, сколько специфика работы аналитика с Заказчиком. Лучше самим продумать более удобные в реализации варианты и сразу предложить их, чем заставить Заказчика фонтанировать задумками, и потом объяснять ему почему так делать не стоит.
Спасибо за статью, очень интересно. Мне самому довелось поучаствовать в стартапе в качестве наемного разработчика, вспомнил прочитав вот это:
на все требования о смене продавцов, интенсивных продажах, маркетинговых исследованиях и т.д. он лишь благодушно похлопывал нас по плечу, мол, маленькие еще, не доросли, не понимаете, как устроен серьезный бизнес
Была похожая ситуация. Мы, разработчики, в считанные месяцы запустили онлайн-продукт в бета-версии, еще за пару-тройку месяцев привели его в хорошее промышленное состояние, а выхлопа — ноль. Мы хоть и на зарплате сидели, но за продукт душа болела. Поэтому на каждом собрании поднимали одни и те же вопросы к ответственным за продвижение, пытались их как-то «пнуть», и напрямую, и через руководство. Но толку не было. Последние полгода занимались тем, что натягивали новый никому не нужный дизайн на сайт, плюс я немного увлекся продвижением в поисковиках, в общем занимались всякой чушью. Спустя год, к моменту закрытия проекта в виду прекращения инвестирования, мы имели продукт, имеющий функциональность превышающую большинство конкурентов на пост-советском пространстве, но при этом никем не используемый (в отличие от более слабых технически конкурентов, которые и по сей день здравствуют).
Сервер у нас был виртуальный, с памятью в 512 МБ, в виду чего раз в неделю «падал» от недостатка памяти (для Java Enterprise этого явно маловато), поэтому еще пару лет после роспуска команды я заходил и перезапускал сервер приложений. В очередной раз зайти не удалось — сервер просто отключили. Последний след стартапа исчез…
для корпоративных приложений 20% руками сомнительно
Все таки написание кода, зачастую, отнимает 50% времени и более
Более 10 лет занимаюсь корпоративными приложениями (Java Enterprise), боюсь даже представить себе 4 часа в день чистого кодинга. Первые годы, пожалуй, соотношение работы головой/руками стремилось к такому показателю, но чем ближе оно к нему было, тем больше к такому кодингу просился префикс «г»…
Эх, у вас старый модуль, а у меня целая старая Система. В большинстве случаев, куда ни копни, почти любая доработка тянет за собой рефакторинг, ибо нет сил оставлять это ТАК. Вот с начала этой недели искоренил пару тысяч строк копипаста в рамках очередной доработки. На выходе — в 4-6 раз меньшее количество кода стало выполнять чуть большее количество задач…
Вот тут пишут что с heartbeat могут быть проблемы. Не исключаю того, что это только с Apache (или вообще, конкретно их конфигурация неудачная), и с haproxy проблем нет. У вас есть практический опыт применения haproxy + heartbeat, скажите, как работает — стабильно?
По поводу ssl offloading (насколько я понял, более употребимый термин SSL acceleration) — стыдно признавать, впервые услышал о существовании подобной технологии. Опять же, если есть опыт применения, черканёте пару слов?
Любое стандартное веб-приложение (обычно, с расширением .war), развернутое на JBoss 7, в случае добавления в web.xml тэга <distributable/> получит репликацию сессий.
Сдавал давным-давно Programmer-а под 1.4, еще Sun-овский. Судя по всему, у Sun-а было как-то попроще. У нас в компании человек 10-15 сдавали, насколько я помню, никто не провалил. Радовались не столько тому, что вообще сдали, а скорее баллами мерились. Я и еще один программист, как более опытные набрали больше всех, кажется по 88 из 100. Когда готовился прошелся вскользь по русскоязычному руководству по подготовке и погонял тесты, чересчур никто не перенапрягался. Тогда год-два опыта программирования на Java было достаточно, чтобы вообще без подготовки сдать с вероятностью процентов 70-80. Теперь, видимо, другие времена…
выучите регулярные выражения
Насколько я помню, этого не было раньше, но могу и ошибаться, времени много прошло.
нету теории паттернов (а Oracle эту тему как оказалось очень любит — разбирайтесь досконально)
Вот этого для Programmer-а точно не было, а вот когда на Developer сдавал, там пришлось голову поломать, особенно с учетом моего любительского английского… Да и вообще, при подготовке на Developer-а реально много времени и сил угробил, англоязычное руководство по подготовке от корки до корки прочел. И все равно на экзамене все 2 часа со вздыбленной от ужаса холкой сидел, еле сдал. Когда в конце смотрел разбивку баллов по темам, то некоторые были 100%, а некоторые 0%!
Спасибо за моральную поддержку! Но я при написании статей думаю не только о хабросообществе или своем личном рейтинге (хотя и об этом тоже, конечно), но и о любых IT-специалистах, бродящих по Сети в поисках нужной информации. Я сам по крупинкам собирал рецепты для этой статьи из источников, в которых даже не зарегистрирован. Надеюсь, что немало людей, не зарегистрированных на Хабре прочитают статью и узнают из нее что-то новое. Я это к тому, что рейтинг любых статей на Хабре — это лишь часть их жизни в Сети, и даже будучи глубоко в архивах они могут приносить немало пользы.
Спасибо за подсказку, я незнаком с nginx. Слышал, что nginx более производителен в сравнении с Apache. На личном опыте скажу, что и Apache очень шустр. У нас когда-то при переходе на кластер, Apache поставили на тот же сервер, что и один из узлов. Каких-то проблем с производительностью замечено не было, несмотря на то, что в обычном режиме работы JBoss-а на этом сервере, он забирает 80-95% процессорного времени. Думаю, что до тех пор, пока количество запросов в сутки не перевалило семизначные цифры, можно не беспокоиться о производительности Apache.
Хорошо, давайте пройдемся по конкретике:
«Обработка данных в памяти Java», «Использование JDBC», «Соединение данных в памяти Java» — в общем-то и всё. В других ЯП нет памяти и коннекторов к БД? Вот скажите, какой именно из 10 пунктов неприменим к другим ЯП?
Чтобы написать запрос, который «положит» базу, не обязательно быть программистом вообще, достаточно просто иметь доступ к БД. Конечно, программистов, неоптимально использующих ресурсы СУБД немало, но если Вы пишете конкретно про Java, до хотя бы статистику какую-то дайте, что именно на Java косячат больше всех, а Си, PHP, Delphi и остальные белые и пушистые.
PS Да, я Java-программист, и судя по отсутствию комментариев по поводу заголовка, хаб Java читают в основном не Java-программисты…
1) В основном Oracle, лет 10 назад попадался Infomix
2) Тут до вас запредельно далеко, не более 100 в секунду, обычно меньше, но запросы достаточно тяжелые, например SOAP веб-сервисы с выборкой из БД. Парсинг XML, знаете ли, штука ресурсоемкая, но стандартизация обязывает.
3) Из аналитики — отчеты, формируемые выборками из БД. Существенной разницы не замечено между запуском их через приклад и напрямую SQL-ем в БД, конечно при условии передачи Hibernate-у нативного SQL-а
4) От 1-го до 30-ти разработчиков на разных проектах и разных этапах.
5) Первый Enterprise, на котором я был джуниором 10 лет назад еще работает. Распределенная система из полуторасотни серверов приложений+баз данных, разбросанных регионально. Абсолютно все более поздние проекты сейчас так же находятся в промышленной эксплуатации.
6) Глянул в текущем проекте — 316 таблиц, в некоторых из них 200-300 полей
7) Вот это не считал, сейчас нет времени искать утилиту, если что — попозже. НО! Думаю, что кол-во строк кода — одно из главных преимуществ ORM-фреймворков, так что больше кода — не всегда означает более сложный проект.
Еще раз скажу, что ни в коем случае не претендую на опыт работы со схожими с вашими объемами данных, но моё ИМХО повторю: "небольшие проекты" — это вы чересчур загнули.
Три ваших абзаца про ORM мне почему-то кажутся чистой теорией. Лично я 10 лет в проектах масштаба предприятия работаю исключительно через ORM Hibernate. 90+ процентов кода вообще не требуют оптимизации, просто потому, что это простые вещи. Если же где-то требуется более внимательный подход к ресурсам или сложные выборки — Hibernate может это сделать, при этом в большинстве случаев не загаживая ваши исходники рутинным перекладыванием объектов.
Я понимаю, что у вас своя специфика и средний JEE-проект по нагрузкам не тянет и десятой доли ваших, но тем не менее, ваша фраза "ORM — это небольшие проекты, где очень быстро можно сделать интерфейс, не знаю, редактирования, да каких-то простых сущностей. " не выдерживает никакой критики. А хуже всего, что новички прочитают авторитетное мнение и возьмут на вооружение. Печально…
Была похожая ситуация. Мы, разработчики, в считанные месяцы запустили онлайн-продукт в бета-версии, еще за пару-тройку месяцев привели его в хорошее промышленное состояние, а выхлопа — ноль. Мы хоть и на зарплате сидели, но за продукт душа болела. Поэтому на каждом собрании поднимали одни и те же вопросы к ответственным за продвижение, пытались их как-то «пнуть», и напрямую, и через руководство. Но толку не было. Последние полгода занимались тем, что натягивали новый никому не нужный дизайн на сайт, плюс я немного увлекся продвижением в поисковиках, в общем занимались всякой чушью. Спустя год, к моменту закрытия проекта в виду прекращения инвестирования, мы имели продукт, имеющий функциональность превышающую большинство конкурентов на пост-советском пространстве, но при этом никем не используемый (в отличие от более слабых технически конкурентов, которые и по сей день здравствуют).
Сервер у нас был виртуальный, с памятью в 512 МБ, в виду чего раз в неделю «падал» от недостатка памяти (для Java Enterprise этого явно маловато), поэтому еще пару лет после роспуска команды я заходил и перезапускал сервер приложений. В очередной раз зайти не удалось — сервер просто отключили. Последний след стартапа исчез…
Более 10 лет занимаюсь корпоративными приложениями (Java Enterprise), боюсь даже представить себе 4 часа в день чистого кодинга. Первые годы, пожалуй, соотношение работы головой/руками стремилось к такому показателю, но чем ближе оно к нему было, тем больше к такому кодингу просился префикс «г»…
По поводу ssl offloading (насколько я понял, более употребимый термин SSL acceleration) — стыдно признавать, впервые услышал о существовании подобной технологии. Опять же, если есть опыт применения, черканёте пару слов?
Любое стандартное веб-приложение (обычно, с расширением .war), развернутое на JBoss 7, в случае добавления в web.xml тэга <distributable/> получит репликацию сессий.
Сдавал давным-давно Programmer-а под 1.4, еще Sun-овский. Судя по всему, у Sun-а было как-то попроще. У нас в компании человек 10-15 сдавали, насколько я помню, никто не провалил. Радовались не столько тому, что вообще сдали, а скорее баллами мерились. Я и еще один программист, как более опытные набрали больше всех, кажется по 88 из 100. Когда готовился прошелся вскользь по русскоязычному руководству по подготовке и погонял тесты, чересчур никто не перенапрягался. Тогда год-два опыта программирования на Java было достаточно, чтобы вообще без подготовки сдать с вероятностью процентов 70-80. Теперь, видимо, другие времена…
Насколько я помню, этого не было раньше, но могу и ошибаться, времени много прошло.
Вот этого для Programmer-а точно не было, а вот когда на Developer сдавал, там пришлось голову поломать, особенно с учетом моего любительского английского… Да и вообще, при подготовке на Developer-а реально много времени и сил угробил, англоязычное руководство по подготовке от корки до корки прочел. И все равно на экзамене все 2 часа со вздыбленной от ужаса холкой сидел, еле сдал. Когда в конце смотрел разбивку баллов по темам, то некоторые были 100%, а некоторые 0%!