• Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +1

    Впервые за несколько лет увидел адекватную оценку этих техник. Сам понимал всегда что в большинстве проектов они не нужны, и вот в этой статье нашёл подтверждение своему мнению, разложенное по полочкам. Искренне сочувствую тем, кто внедрил в своих проектах не решение конкретных проблем, а модную штуку, которая сделала проект хуже, зато добавила крутую строчку в резюме программиста.
    Не хочу сказать, что эти техники плохи, просто не надо возить уголь автобусами — они хоть и вместительные и грузоподъемные, но всё же неудобно как-то…

  • Java 9 — Вы уже перешли? Нет? И не надо ...!?
    +4

    Так же, как и на любой другой версии Java. Встречал проекты на Java > 6, рабочий день на которых — пытка. Встречал проекты, мало изменившиеся с того момента, когда их создали 10+ лет назад на Java 1.4, и рабочий день на них — вполне приятен. Ощущения от работы на проекте зависят не столько от того, НА ЧЁМ он написан, сколько от того, КЕМ он написан.

  • Почему вам должно быть скучно на работе
    0
    Попробуйте использовать инкрементальную компиляцию, поддерживаемую многими современными средствами разработки, и тогда в большинстве случаев время компиляции будет зависеть не от размера проекта, а от количества изменений. Проверено на проектах от нескольких тысяч строк кода до более миллиона — время компиляции одинаковое (в большинстве случаев — менее секунды).
  • Как пенсионный фонд сливает персональные данные
    –2
    В Казахстане такая единая база с 2007-го года работает, практически все гос. органы к ней подключены. Что-то я не припомню чтобы за 10 лет промышленной эксплуатации где-то появлялась информация об утечках…
    уровень профессионализма чинуш
    никакого влияния на подобные базы не имеет, администрированием и вопросами безопасности технические специалисты занимаются…
  • Свайная суперсила
    +1
    Тьфу в лицо вашим Заказчикам (с вас что взять — просто деньги отработали). Вы же знаете хотя бы нормы расстояния между зданиями, в зависимости от их высоты, нормы площади дворовых территорий? Заказчик учёл правила распределения жилых зон, пром. зон, спальных районов, и расчёта коммуникаций (особенно транспортных)?

    Технически, статья конечно замечательная, спасибо — действительно интересно… Но мое средне-техническое строительное образование не приемлет! А уж ваше — даже не знаю…
  • Закат Stack Overflow
    +4
    «77% пользователей задали только один вопрос, 65% ответили только на один вопрос»

    Эти цифры ничего не говорят об удовлетворённости пользователей. Это не развлекательный или новостной сайт, тем более не социалка, для которой главное чтобы все что-то писали, поэтому эта статистика не говорит ничего об удовлетворённости. Я — программист, и я знаю зачем я хожу на SO, и как это происходит. Я сижу и делаю работу, я «в потоке», и тут — проблема, которая хочет выбить меня из потока. Захожу в Гугл (не в SO, ни разу не использовал внутренний поиск), Гугл предлагает мне SO, открываю страницу, в большинстве случаев практически не читая вопроса/ответа проглядываю код в ответе, и использую его. Причём использую как можно скорее, пока совсем не выпал из потока. Всё! Я удовлетворён на 100% тем что просто дальше делаю свою работу, через 30 секунд забыв что вообще был на SO. Как эту удовлетворённость можно извлечь из статистики задающих вопросы и отвечающих на них?

    Вообще, 4 млн. зарегистрированных пользователей, скорее всего, лишь малая часть из тех, кто получает огромную пользу от сайта вообще не регистрируясь на нём. Как посчитать их удовлетворённость? Лично я за годы использования SO один или два вопроса задал, но при этом ответов я за то же время получил тысячи, просто найдя уже готовые решения.

    Да, мой предыдущий комментарий, мягко говоря, не имеет солидной исследовательской базы, но и сама статья в общем-то — просто чушь. Любой продукт можно закидать экскрементами, имея на то большое желание, но только вреда особого не будет, если продукт хорош. Пара-тройка авторов статей раз в год собирают экскременты и кидают их в вентилятор, а 31 млн посетителей в месяц просто используют продукт дальше, в большинстве случаев вообще не зная об очередной разоблачающей статье…
  • Закат Stack Overflow
    +3
    В общем-то не обязательно быть знакомым с SO для того, чтобы сделать выводы исходя лишь из текста самой статьи:
    более 4 млн. зарегистрированных пользователей


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

    PS Я сам участник SO, есть вопросы и ответы, пусть и немного. Удивился заголовку статьи, особенно тому, что это перевод. Я это к тому, что русская версия пожиже будет, всякой чуши в вопросах более чем хватает. Заметил тенденцию на ru.SO — учащиеся нередко задают вопросы даже не попытавшись самостоятельно поискать. Плюс спрашивают про технологии, устаревшие 10 лет назад…
  • Что едят солдаты разных стран в бою? История армейских сухпайков
    +2
    США

    Ценность первого тестового комплекта составляла 3200 калорий

    Врёшь НАТОвская морда, не может солдат съесть в день два мешка брюквы!
  • Как ускорить сборку с Maven
    +1
    За других говорить не буду, но моё личное решение касательно сборки с Maven — не использовать для сборки Maven, по крайней мере в dev-окружении. Вместо этого предпочитаю собирать средой разработки Idea. Причина, если кратко — у среды разработки есть контроль версий файлов, который она и использует для инкрементальной сборки. Результат — сборка длится считанные секунды независимо от размера проекта, длительность зависит только от количества изменений, внесённых после предыдущей сборки. Да, Maven отлично справляется с конфигурацией проекта, и именно его файлы конфигурации я использую для генерации артефактов в среде разработки. Но как только все нужные зависимости подключены, я про Maven забываю…
  • Как стать профессиональным веб-разработчиком: практическое руководство
    0
    Если Вы считаете, что будете жить вечно, то да — изучайте N технологий/техник/наук/спецификаций/прочее, которые кажутся важными человеку, написавшему именно эту статью. Плюс тысячи статей с технологиями/… от тысяч уважаемых профессионалов про не менее важные вещи. И только потом начинайте писать реальный код, выходящий за рамки Hello World-ов. Это примерно то же самое, что и закончить ВУЗ по специальности: с одной стороны, нельзя сказать что Вы не специалист, с другой — совсем не факт, что Вы можете здесь и сейчас реально помочь реальному проекту. Разница с ВУЗ-ом лишь в том, что он даёт «корочку», которая имеет хоть какой-то вес. А какие рекомендации даст «Bill Sourour» вашему потенциальному работодателю при попытке устройства на работу?
  • Google-oriented programming
    +1
    Напомнило:
    Идеальный мужчина не пьёт, не курит, не играет на скачках, никогда не спорит и не существует.
  • Исповедь Google-спамера
    +4
    Занимался чем-то похожим в свободное время, за год купил 400 доменов и развернул вручную на них сайты. Целью было сделать т.н. «сетку (говно-)сайтов», которая за счёт ссылок друг на друга (т.н. перекрёстных ссылок) получит авторитет в глазах поисковиков. После этого начать продавать ссылки из этой сетки на сторонние сайты, пытающиеся продвинуться в выдаче поисковиков. Наполнял сайты размноженными статьями — это когда берется некий текст, в нём для слов и фраз подбираются синонимы, и специальная программа путём перебора всех возможных вариантов генерирует сотни текстов. На первом этапе, когда сайтов было 20 всё шло хорошо: страницы заходили в индекс, показатели авторитетности росли. На радостях начал клепать сотни новых сайтов, разбивая на группы. Новые сайты так и не вошли в индекс, а первая двадцатка вскоре вылетела из индекса, а показатели авторитетности обнулились. После года-двух ожидания стало ясно, что изменений к лучшему уже не будет. Снятие перекрестных ссылок не помогло. В конце-концов слил почти все сайты, оставив около 30-ти подающих признаки жизни. До сих пор живут, рука не поднимается их грохнуть…

    А началось всё с нормального (не говно-) сайта, информационного блога, за счёт продажи рекламы с него и оплачивались эксперименты с сетками. Сайт жив до сих пор, полторы сотни посетителей в день, но денег уже не приносит. Запустил свой стартап, онлайн-сервис, потихоньку развиваю его.

    Многие говорят о том, что не надо обманывать поисковики, лучше делайте что-то для людей. Так-то оно так, но огромные деньги, крутящиеся в сфере SEO говорят о другом. Правда, как обычно, где-то посередине…
    Переходи на сторону тьмы
    image
  • Чек-лист из 68 пунктов для продвижения сайта в ТОП10 Яндекса
    0
    Яндекс заинтересован в выдаче показывать лучшие сайты

    Яндекс, как и абсолютное большинство других компаний, в первую очередь заинтересован в том, чтобы зарабатывать деньги. Они бы с радостью плюнули на выдачу и лучшие сайты, но тогда высок шанс потерять пользователей, а пользователи = деньги. Они не зарабатывают на поиске, они зарабатывают на рекламе, которую показывают в поиске. И там алгоритм простой — плати больше, будут показывать чаще. А поиск — лишь площадка для показа рекламы.

    сайт появится в ТОПе, это факт

    Я несколько лет крутился в сфере SEO, и одна из главных вещей, которую усвоил — в поисковой оптимизации нет никаких гарантий ни для кого. Ваше заявление — полнейшая чушь. Да, если ваш сайт незаслуженно забанен Яндексом, то обращения в службу поддержки дадут шанс того, что когда-то его вручную оттуда «вытащат», и он появится в поиске, где-нибудь на 10-й странице. Но попасть в ТОП выдачи попросив об этом службу поддержки?!
  • «Иннополис» съел деньги, выделенные на проект российского спутникового интернета для «народа»
    +2
    Закончил школу и уехал учиться в город

    Деревни по берегам почти все пустые… основной источник денег — пенсии пенсионеров

    Мне кажется, что вы не противоречите друг другу. Пока знакомый сидел в деревне через ADSL, его с берега не видно было. А потом он уехал (и вряд ли вернётся, как и многие другие), то остались одни пенсионеры…
  • Чек-лист из 68 пунктов для продвижения сайта в ТОП10 Яндекса
    0
    Статей с успешными методами продвижения сайтов, по-моему, уже больше, чем самих успешных сайтов. Сама статья, конечно, логичная и во-многом адекватная (но не во всём), но пользы от неё не больше, чем от других таких же. Ладно, статья, но вот это уже слишком:
    алгоритм будет скорректирован в Вашу пользу и сайт появится в ТОПе, это факт

    Нет, ну правда, ВЫ ЭТО СЕРЬЁЗНО?!
  • Рекурсивные запросы в PostgreSQL (WITH RECURSIVE)
    +2
    Добавлю: рекурсивных подзапросов может быть несколько в одном SQL-запросе. В начале объявляется WITH RECURSIVE, далее следуют как рекурсивные, так и обычные подзапросы, каждый со своим алиасом. Необязательно осуществлять выборку непосредственно из рекурсивного запроса, его можно, например, джойнить с обычной выборкой из таблицы. Использовал такой подход при формировании отчётов. Выглядит примерно так:
    WITH RECURSIVE
    tree_query_1 AS (... --рекурсивный запрос
    UNION ALL...
    ),
    tree_query_2 AS (... --рекурсивный запрос
    UNION ALL...
    ),
    simple_query_1 AS (... --нерекурсивный запрос
    --no UNION
    )
    --далее строим отчёт, используя объявленные выше запросы
    SELECT
      t1.field1,
      (SELECT field2 FROM simple_query_1 WHERE id = t1.field2) --используем в блоке SELECT
    FROM table_1 t1
    INNER JOIN tree_query_1 t2 ON t1.field3 = t2.field4 --используем в JOIN
    LEFT JOIN (SELECT * FROM tree_query_2 WHERE...) -- используем в подзапросе в JOIN
    

    Как видно из примера, возможности широкие, и это «рецепты» от не специалиста по СУБД и не знатока PostreSQL…
  • Java 8: Овладейте новым уровнем абстракции
    0
    Это просто замечательно, но возникают 2 вопроса:
    1. Писать на 8-ке понятие растяжимое — то же ФП, например, насколько активно используется?
    2. Как насчет "что сделало бы проект реально более читабельным/поддерживаемым/производительным/т.д" — проекты на 8-ке чем лучше проектов на 7-ке/6-ке/5-ке? Производительность, трудозатраты, ошибки: если на конкретном проекте сменить синтаксис на 5-ку, например, станет ли он от этого набором жуткого говнокода?
  • Java 8: Овладейте новым уровнем абстракции
    0
    Я 13 лет в Java EE (про мужиков, которые пилят сервера) и еще ни разу не встретил ни в одном проекте синтаксиса выше Java 5. Я сам хотя бы Generics активно пользую, а чужие проекты открываю, так там вообще на Java 1.4 остановились (и это не легаси, а свежие проекты, использующие Java 6-7, причем разработанные матерыми профи). Сам тоже смотрю нововведения и не вижу ничего, что сделало бы проект реально более читабельным/поддерживаемым/производительным/т.д… Да, это всё классные штуки, но мне доводилось разбирать код, в котором «классные штуки» применялись как вещь в себе, просто ради попробовать, и это была жуть… Синтаксический сахар — вещь на любителя, а если в проекте работает более одного человека, то тут уже можно начать и о вкусах спорить…
  • Conditional indexing. Оптимизируем процесс полнотекстового поиска
    0
    Lucene 4: 2012-й год
    Hibernate Search 5: 2015-й год
    … без комментариев.

    В любом случае, проект не стал менее специфическим, я не очень представляю себе круг задач, для которых он предназначен. Огромный оверхед над Lucen-ом ради экономии, в лучшем случае, нескольких строчек кода, которая компенсируется дополнительными строчками конфигурации. Если пытаться полноценно использовать полнотекстовый поиск, то Hibernate Search не избавит от надобности изучать Lucene. А если вы разобрались с Lucene, то зачем тратить время на изучение обертки над ним? Это ведь не ассемблер, это полноценная библиотека с полным набором высокоуровневого API, зачем надстраивать над ней ещё что-то? Масло масляное…
  • MyBatis как более быстрая альтернатива Hibernate
    –1
    Все сказанное в статье про Hibernate — чушь, больше всего доставляет заголовок — «MyBatis как более быстрая альтернатива Hibernate». Нет опыта работы с Hibernate — не пишите про него, зачем портить неплохую статью ничем не подтвержденными сравнениями?! Hibernate может и сам генерировать SQL, а может предоставить это разработчику. Если у автора нет достаточного опыта работы с Hibernate, зачем писать о том, что он медленнее?

    «MyBatis мапится не на таблицы, а на SQL запросы»
    Hibernate тоже так умеет, но почему-то в статье эта возможность — прерогатива только MyBatis-а

    MyBatis при разумном использовании может дать ощутимый прирост в скорости работы приложения
    А Hibernate при таком же разумном использовании не может, не?

    MyBatis можно использовать совместно с Hibernate там где это действительно нужно
    Да ладно, серьезно? Будете на одном проекте два ORM-а разворачивать?
  • Conditional indexing. Оптимизируем процесс полнотекстового поиска
    0
    На личном опыте вывел для себя «Первое правило в использовании Hibernate Search»: не использовать Hibernate Search. Никогда. Применял как Hibernate Search, так и «голый» Lucene, и понял что не вижу смысла существования Hibernate Search. Если вам не требуется тотально положить в индексы Lucene всю свою базу, т.е. если у вас только пара-тройка таблиц требующих неточного поиска — используйте чистый Lucene. Последний раз, когда я внедрял неточный поиск, отказ от использования Hibernate Search ускорил индексацию на порядок, и уменьшил размер индекса на 20-30%.

    Да и вообще, Hibernate Search, судя по всему, умирает. Давно уже вышел Lucene 4, но последний Hibernate Search до сих пор работает на 3-ей версии.
  • ASH Viewer
    0
    Вопросы:
    1. Насколько велика дополнительная нагрузка на СУБД?
    2. Периодическое обновление означает что будут сниматься мгновенные данные на момент подключения или Oracle может дать также историю с момента предыдущего снятия данных?
    3. Можно ли подключить вашу библиотеку (без GUI) к серверному Java-приложению, чтобы она сохраняла данные в портабельном виде, а затем периодически переносить сохраненные отчеты и просматривать на своем компьютере?
  • Are you a pirate? Пират ли ты?
    0
    Согласен. А механизм комментирования его информационно дополняет, если голосующему есть что сказать…
  • Are you a pirate? Пират ли ты?
    +8
    Насчет моего «при чем тут Хабр?», Ваше «просто ради хорошего настроения в пятницу» — вполне достойный ответ, хотя привычка превращать Хабр по пятницам в ЖЖ-чку довольно неоднозначна, и для подобных вещей даже сделали отдельный ресурс…

    А по теме статьи — мне кажется, что если стартаперу постоянно нужна внешняя мотивация, в т.ч. и в виде таких не информативных статей, то, может быть, пора бросить это дело и спокойно работать на дядю? Пусть он мотивирует его делать хоть что-то…
  • Are you a pirate? Пират ли ты?
    +31
    Еще одна статья ни о чем… Парень поймал удачу за хвост и вывалил свои эмоции в мир, да только толку? 900 слов — и ни крупицы полезной информации. Да, отличная позитивная статья для уютной ЖЖ-чки: прочитал, воодушевился — и забыл. Но при чем тут Хабр?

    И не надо думать, что я просто пессимист и брюзга, ненавидящий дух стартапов. Я уже третий запустил, и развиваю потихоньку, поэтому и заинтересовался, что за интересная статья. Да только зря время потратил…
  • Как подружился Ebean с Gradle и помирился с IntelliJ Idea
    0
    Ясно, спасибо за разъяснение. А можете пояснить насчет "слишком большой ради пары сущностей"? Из личного опыта: я Hibernate применял (и применяю) не только в классических Enterprise-ах, но и микро-проектах, типа утилит, причем некоторые даже для разовых задач. Вполне себе удобно, в любом случае, лучше, чем вручную из ResultSet-ов JDBC вытаскивать данные в свою логику и обратно. Более того, однажды получил мощную оптимизацию, даже сначала не заметив ее, когда Hibernate без указаний с моей стороны применил пакетные обновления сущностей в СУБД. На Ваш взгляд, что именно в Hibernate большое и тяжелое, и на что негативно влияет эта тяжесть?
  • Как подружился Ebean с Gradle и помирился с IntelliJ Idea
    0
    Краткое содержание статьи:
    Я и еще пара моих знакомых не умеем «готовить» Hibernate и поэтому точно знаем, что Hibernate — гуано. Поэтому мы решили помучаться с Ebean и сделали вот так вот нечто для чего-то. Теперь мы знаем, что Ebean — это круто, потому что хипстер, а Hibernate — все равно гуано, потому что «потому что»


    Хорошая статья для тех, кто хочет познакомиться с Ebean. Но, на мой взгляд, Ваше мнение о Hibernate лучше бы вообще не упоминали…
  • Как нанимать наилучших сотрудников
    0
    Похоже, что вы мыслите понятиями конкретно вашей специфики. Видимо, у вас т.н. high load проект(ы) в котором(ых) приходится работать с большим количеством данных, находящихся в ОЗУ. Да, для этого нужны вышеперечисленные знания, и поэтому ваши архитекторы в них «как рыба в воде». Но, во-первых, даже high load бывает разный, а во-вторых далеко не каждый второй проект в стране — это high load… Вам при собеседовании, видимо, надо спрашивать про алгоритмы, но мы же обсуждаем сферическое собеседование в вакууме, срез «в среднем по больнице», поэтому мне кажется, что ваши требования совсем не средние…
  • Как нанимать наилучших сотрудников
    0
    Брала самостоятельных, напористых, амбициозных

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

    Хорошая команда должна состоять из людей различных психотипов/ролей. Есть исследования по этому поводу и тесты соответствующие. Так что неправы ни вы ни компания, т.к. в команде должны быть и те и другие типы людей, и еще несколько других…
  • Как нанимать наилучших сотрудников
    0
    Выдающийся показатель, это например 10 000 запросов в секунду
    Запрос запросу — рознь, так что не стоит вот так вот огульно под одну гребенку… К тому же это просто пример, в надежде донести мысль о том, что как я считаю, знание алгоритмов мало говорит о том, что представляет из себя разработчик. И даже наоборот, раз он так тщательно готовился к собеседованию и штудировал давно забытую теорию, то может с практикой у него туговато… Большинство студентов знает такие алгоритмы лучше, чем большинство синьоров и архитекторов, но говорит ли это о том, что студент лучше справится с реальным проектом?
  • Как нанимать наилучших сотрудников
    +2
    Так я о том речь и веду — в большинстве случаев и знать этого не надо, т.к. «большинство случаев» — это структура из сотни-другой элементов, обращения к которой выполняются реже раза в секунду, в однопоточной среде. В таких условиях не имеет значение «как устроены стандартные структуры данных»… А если требуется работать с большими долгоживущими массивами, которые читаются/изменяются тысячи раз в секунду да еще и в конкурентной (многопоточной) среде, то тут, конечно, стоит поинтересоваться внутренней реализацией, и, возможно даже, реализовать свою.

    НО! В разрезе темы статьи — лично я бы предпочел узнавать/разрабатывать низкоуровневые алгоритмы только когда текущая решаемая задача этого требует, а не просто теоретически знать (и помнить всю жизнь), чтобы на собеседовании блеснуть знаниями, которые пригодятся с вероятностью менее 1%…
  • Как нанимать наилучших сотрудников
    0
    Очень часто
    Возможно, что конкретно в Вашем проекте, действительно часто. Но, готов побиться об заклад, в абсолютном большинстве среднестатистического ПО такие проблемы возникают чрезвычайно редко…
  • Как нанимать наилучших сотрудников
    +1
    не представляете себе, какие кадры «с опытом от 10 лет» встречаются
    я, например, такой «кадр», и я не смогу написать пузырьковую сортировку даже на псевдокоде, т.к. не знаю принципа ее работы. И это несмотря на то, что лет 15 назад я точно знал как она работает. За «от 10 лет» практики на промышленных проектах (Один, например, из более сотни серверов, раскиданных по стране. Другой — обрабатывает более 1 млн. SOAP-запросов в сутки, имея при этом десятикратный запас производительности) мне ни разу не пригодилось знание низкоуровневой реализации списков и сортировок…

    Возможно, Вы на собеседовании посчитаете мой опыт «неправильным», и ненужным, или подумаете что я про опыт лгу, раз не могу «изобразить» пузырьковую сортировку. Практически все мои коллеги (в т.ч. и бывшие) так не считают. Вопрос — кто прав, Вы с теоретическими вопросами или коллеги, знающие что я могу на практике?
  • Java 8, Spring, Hibernate, SSP — начинаем играться
    0
    Насчет фич 8-ой java и дергания логики из View — на мой взгляд не очень хорошая идея
    Ну, логика — понятие растяжимое, даже в вашем примере person.id вполне мог бы быть default методом какого-нибудь интерфейса Identifier, например, при каждом обращении к getId генерирующим новый сиквенс, чисто теоретически…

    По поводу технологий — вечный холивар, у каждой есть плюсы и минусы, не будем об этом. Но вот по поводу JSP — мне кажется, что довольно тяжело расписывать для каждой странички каждый тег. Либо ваша Admin Panel выглядит очень убого, либо на каждую страничку у вас исходники на много сотен строк, либо у вас не чистый JSP, а подключена какая-то библиотека виджетов. Насколько я помню, на заре JSF нередко View рисовался именно на JSP-странице. В общем, чисто из любопытства, скажите, что представляет из себя ваша Admin Panel: много ли страничек, каков внешний вид, какой объем кода типичной странички?
  • Java 8, Spring, Hibernate, SSP — начинаем играться
    0
    Мне в последние годы казалось, что Server Pages — сильно устаревшая технология, т.к. все тонкие клиенты для JEE, с которыми сталкивался (существующие или которые начинал с нуля сам) делались на JSF либо GWT. Да и вообще, за 10+ лет разработки на Java ни разу не видел JSP в качестве основного инструмента «рисования» View. Мне вот интересно, кроме примера в статье, у Вас реальные JEE проекты крутятся на JSP/SSP?

    По поводу перехода на Java 8. Есть у меня проект на Java 7, Tomcat 7, MySQL, JSF, Hibernate. Попытался переключиться на Java 8, вроде без проблем. Попытался тут же применить что-то новое, нашел подходящую структуру, в которую «просился» default метод интерфейса. Переделал, запустил, но — увы — реализация EL на JSF страничке, которая раньше «понимала» метод в абстрактном классе, не нашла тот же метод в интерфейсе. Ну понятно, думаю, 7-й Tomcat восьмую Java не поддерживает, надо 8-й Tomcat попробовать (библиотека EL идет в комплекте с Tomcat-ом). Ставлю 8-й Tomcat, который как оказалось стартует вдвое дольше 7-го, и вижу, что ничего не изменилось — та же ошибка. Дальше копать не стал, т.к. в моем случае овчинка выделки не стоит… И, кстати, поиграйтесь с фичами Java 8 на JSP страничке, вполне вероятно, что интерпретатор JSP тоже «сломается», как и парсер EL…
  • Строим веб-приложение на Java без JEE и Spring
    +6
    Мне кажется, что автор прав в том, что фреймворки — палка о двух концах, и, прежде чем использовать их, следует 7 раз отмерить, насколько плюшки фреймворка покрывают его тяжесть, ограничения и требования изучения его специфики. У меня, например, сейчас в поддержке проект с Seam, в котором не «5 мегабайт библиотек», а 35, причем реально используется в лучшем случае 3-5% их возможностей. Можно было сделать все то же самое, но без Seam (и того, что тянется с ним в зависимостях) вообще…

    С другой стороны, всем понятно, что с нуля писать всё — разве что в качестве «поиграться» пока не надоест либо в маленьких проектах. Лично мне нравится пользоваться не фреймворками, «окружающими» мое приложение (т.е. моё приложение внутри фреймворка), вместо этого предпочитаю, чтобы фреймворки были внутри приложения. Т.е., использую только утилитарные вещи, которые подключаются и делают какую-либо ограниченную часть функций, по возможности не затрагивая другие слои приложения. Например, классический Hibernate берет на себя всю работу с БД, и заставляет разбираться с его спецификой только для операций с базой. При этом, например, получив при его помощи объект считанный из БД, при дальнейших операциях с этим объектом, про Hibernate можно забыть.

    Несмотря на то, что тема статьи в общем и целом актуальна, конкретные примеры, на мой взгляд «ни о чём» — просто некий код, которого в любом проекте море. Ценность статьи, на мой взгляд — 0, комментарии полезнее и информативнее, чем статья…
  • Самодокументированный JAX-WS с поддержкой XSD Restrictions
    +1
    Ну вот, не прошло и дня, как в очередной раз убедился в том, что путь contract last не так плох, как его малюют. Только что пришли претензии от разработчиков сторонней компании к XSD нашего веб-сервиса, который разрабатывался одним из наших программистов по принципу contract first. Пишут что необязательный по бизнес-логике элемент, в XSD указан как обязательный (minOccurs=«1»). Наш программист уже уволился, поэтому сам посмотрел XSD — ничего подобного, нет такого свойства у элемента, и решил их послать отклонить претензию. Но решил сначала поискать какое значение по-умолчанию по спецификации. Оказалось — точно, если не указан явно, то принимается minOccurs=«1», ошибка наша. Программист, не особо вдаваясь в подробности спецификаций, нарисовал в XSD имена и типы элементов, а обязательность не указывал явно нигде.

    Посмотрел тут же для примера свои XSD-шки, сгенерированные с исходников — всё учитывается, для необязательных полей minOccurs=«0». Правда, если уж быть до конца честным, в исходниках обязательность мной задавалась явно, т.е., если бы тоже не вдавался в подробности, то наступил бы на те же грабли…
  • Самодокументированный JAX-WS с поддержкой XSD Restrictions
    +1
    если есть ТЗ
    У кого как, моя практика показывает, что независимо от наличия/отсутствия ТЗ, веб-сервисы (как и любой другой функционал) имеют свойство со временем развиваться/изменяться. Не все, и не так часто, как внутренняя реализация Системы, но факт имеет место быть, и неоднократно.
    Во всех них нельзя просто так взять и написать wsdl
    Да-да, я уже лет 8 постоянно сталкиваюсь с разработкой/доработкой веб-сервисов, но до сих пор в WSDL/XSD чувствую себя неуверенно. Мне кажется, что даже многие из тех, кто использует contract first, не смогут с нуля нарисовать WSDL-описание, никуда не подглядывая…
  • Самодокументированный JAX-WS с поддержкой XSD Restrictions
    +1
    Поддерживаю. Я не согласен с тем, что contract first — это абсолютное добро, предпочитаю contract last, и не только потому, что разработчику обычно удобнее писать код, а не XML. У меня, например, часто объекты веб-сервиса замаплены еще и на СУБД, за счет чего, сущность считанная Hibernate-ом из БД без каких-либо модификаций и копирования, как есть отдаётся движку веб-сервисов на сериализацию в XML. Генерация же с WSDL обычно на корню убивает принципы ООП. Это, конечно, классы из которых создаются объекты, но такие недообъекты нельзя трогать, т.к. при доработке сервиса они будут сгенерированы заново, и все мои плюшки исчезнут. Простейший пример в продолжение связки Hibernate->XML: обычно Hibernate-сущности в проекте наследуются от какого-нибудь Identitfier, при перегенерации extends «слетит».

    В общем и целом, лично мне намного удобнее и приятнее писать хорошо структурированный Java код, а потом генерировать из него WSDL, а не наоборот — генерировать в отдельный пакет кучу псевдо-объектного мусора из классов, которые потом кувалдой внедряешь в логику Системы. Спасибо за статью, буду пробовать…
  • Введение в Акторы на основе Java/GPars, Часть I
    +3
    акторы хороши для программирования многопоточных примитивов
    В приведенном примере Batcher я не вижу никаких синхронизаций, а BatcherDemo, кроме того, что однопоточный, еще и Thread.sleep постоянно вызывает. Что будет, если передача запросов Batcher-у будет многопоточной и высококонкурентной? Могут ли сразу 10 потоков войти в Batcher.onMessage и одновременно пройти проверку argList.size() == 1, что приведет к тому, что после того, как все 10 запросов будут обработаны, lastTimer.send(«KILL») так и не будет вызван? Если GPars где-то внутри не синхронизирует потоки, то многопточность в приведенном примере, видимо, не работает? Или я неправ?