• Советы по оптимизации кода на Java: как не наступать на грабли
    0

    Все-таки надо различать пользователей, которые пишут библиотеки/фреймворки от тех, кто пишет бизнес логику. Первых очень немного, и они как правило вкурсе всевозможных оптимизаций. Вторых большинство, и они уже используют оптимизированные (или не очень) библиотеки для реализации своих задач.


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


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

  • Советы по оптимизации кода на Java: как не наступать на грабли
    +2

    Неужели у кого-то реально проект из-за того, что он неправильно пользовал StringBuilder или stream вместо for? В 95% случаев всегда тормозит база данных, причем в половине случаев решение не такое тривиальное, как просто переписать запросы: требуются серьезные архитектурные модификации, использование кешей и т.д. Кроме того, на продакшне ситуация может сильно отличаться от тестового бенча, поэтому всякие профайлеры тут не помогут. Поэтому совет один — используйте лайв мониторинг и фреймворки типа Metrics, пишите понятный код и не сильно забивайте голову всей этой фигней по поводу stream/for, StringBuilder, etc...

  • Использование возможностей Groovy DSL для конфигурации Java-приложения
    0

    Дык, захардкодьте весь дефолтный конфиг значениями прямо в бинах, как я показал выше. А в xml нужно будет прописывать только элементы, значения которых отличаются. JAXB будет создавать объект с дефолтными параметрами, и перезаписывать только поля, указанные в xml. В идеале с пустым xml будет создаваться полный дефолтный конфиг.

  • Опыт построения интеграционной платформы на базе ServiceMix (Camel) и RabbitMQ
    0

    Меня всегда интересовал вопрос, как правильно поставить процесс разработки и тестирования в приложении с OSGi-контейнером? Модуль после каждого изменения приходится запаковывать и передеплоивать. Кроме того нет возможности стартануть контейнер из workspace с подцепленным classpath модуля, соответственно невозможно будет дебажить в IDE, или делать hot replace. Даже в JEE есть такие средства как Arquillian, OpenEJB, Microprofile, которые сильно упрощают разработку...

  • Использование возможностей Groovy DSL для конфигурации Java-приложения
    0

    Не совсем понял, что вы имеете ввиду под "наследованием" конфигов. Если это наследование бинов, то у JAXB с этим проблем нет. А если дефолтные значения для полей, то их можно указывать прямо при описании самих полей:


    public class DatabaseConfig {
        public String url = "jdbc:h2:mem:test";
        public String username = "sa";
        public String password = "";
    }
  • Использование возможностей Groovy DSL для конфигурации Java-приложения
    0
    Может, для этого уже есть библиотека?

    Да полно. Вот очень неплохой вариант: http://owner.aeonbits.org/.
    Для себя я уже давно решил проблему конфигов: использую стандартный JAXB. Структура описывается прямо в бинах при помощи парочки аннотаций. Все сериализуется в XML. Maven автоматически генерит XSD, который понимает IDE и позволяет делать autocomplete при редактировании конфига.

  • Переход на отечественное ПО, установки «мегасайенс» и привлечение ведущих зарубежных учёных: план прорывного развития РФ
    0

    «Цифровая экономика Российской Федерации» — это все правильно и хорошо. Однако возникает вопрос об экономической целесообразности данной программы. Выражаясь простым языком, на программу будут потрачены серьезные государственные средства, но нигде даже не оговариваются способы возврата инвестиций. Из программы понятно, что:


    • Основным бенефициаром программы являются государственные органы, однако программа не ставит самой целью какую-либо экономию средств или повышение эффективности работы госаппарата (про это не сказано ни слова).
    • Четко просматривается цель — сбор данных и контроль над деятельностью. Однако мотивация нигде не раскрыта: уменьшение числа преступлений, повышение налоговых сборов и ликвидация черных денег, мониторинг эффективности работы госаппарата, etc...
    • Нигде не упомянуты интересы и нужды частного бизнеса при реализации программы, что странно. Любая государственная программа первой целью должна ставить интересы физических и юридических лиц.
    • В программе нет ничего про создание конкурентноспособных информационных технологий и выхода на международный рынок. Кто еще, кроме самого государства, будет покупать разработки? На чем планируется возврат инвестиций?
  • Не пишите лишнего
    0

    Опять поиски серебряной пули. Не существует универсального метода написания кода и разбивки на части. Всегда любым гайдлайнам можно найти логичное опровержение.


    Проверьте, не решал ли кто-то до вас в этом проекте такую же (или сильно похожую) задачу.

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


    Знайте и любите утилиты и API собственного проекта. Особенно, если ему больше полугода. Там могут найтись жемчужины, которые сэкономят вам десятки строк кода.

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


    Ещё знайте и любите популярные библиотеки для вашего языка или платформы

    Иногда только из-за одной функции подтягивают кучу зависимостей.


    Код заслуживает быть вынесенным в отдельную функцию

    То есть, когда была объемная, но линейная функция, отражающая какой-то процесс или алгоритм, теперь она раздраконена и раскидана по всему файлу. Это улучшит читаемость? А еще входные и выходные параметры нужно везде мепить...

  • Записки о миграции на Java 10
    –4

    Они все испортят ©! Сейчас мы переживаем фактически начало заката Java. Экосистема не будет поспевать за новым релизным циклом, а Java движется в сторону постоянного ломания совместимости. С Java 8 прокатило, поскольку все давно ждали лямбды и стримы. Но в последних версиях количество вещей реально полезных для финального пользователя, остается минимальным. В итоге экосистема форкнется на две: с одной стороны будет небольшая группа early adopters, а с другой — огромный "легаси", который не будет спешить никуда мигрировать. Резко упадет количество решений, совместимых с новыми версиями Java, и общий интерес к Java платформе потихоньку начнет падать в угоду альтернативам. По моим оценкам Java 8 задержится еще минимум лет на 5, а потом внезапно появится что-то еще...

  • Блеск и нищета Java для настольных систем
    0

    Не совсем понятен мотив использования электрона. У вас уже есть одна зависимость в системе — JVM, и наличие зависимости от браузера уже не принципиально. Сделайте Jetty + Vaadin и открывайте при запуске страницу в system default browser. Ваш электрон в минималке займет лишние 100Mb. Если попытаетесь заэмбеддить jre, то это еще плюсом 180мб, а если все скомпилируете AOT, то будет около 250мб. Итого 350мб для простого "хелло ворлд", что может быть и оправдано для девтулзы, но для простого нативного клиента — вряд ли.
    Далее, так ли принципиальна зависимость от джавы? Для клиентских технологий есть куча приблуд для джавы: JSweet, GWT, TeaVM, вплоть до полной JVM на JS: CheerpJ.
    Ну и по способу деплоймента: зачем бандлить электрон и установщик и почему бы не сделать Chrome Application, распространяемую через Chrome Store?

  • Профессиональное выгорание: как распознать и предотвратить
    +1

    Отлично. Во многом увидел себя. С тем лишь отличием, что мне все еще нравится моя работа, несмотря на выгорание. К причинам я могу добавить еще:


    • Частое переключение. Мы все знаем, что переключение контекстов — дорогостоящая операция для процессора, но она на порядки дороже для головного мозга. Когда тебя заставляют часто переключаться между разными проектами, особенно когда в данный момент сконцентрирован на одном, внезапно тебя срочно просят дописать или исправить баг в проекте месячной давности, который уже вытеснен из головного кэша. А потом также трудно вернуться к основному проекту.
    • Отсутствие вИдения результатов своего труда. Когда ты коммитишь, а сборку делает другой, а установку третий, а поддержку четвертый. Фидбек возвращается тебе исключительно ввиде issues, большая часть из которых не связана напрямую с кодом.
    • К предыдущему пункту: отсутствие общения с живым клиентом. Работа всегда идет через челопрокси (как Tom Smykovsky из Office Space), либо людей из саппорта, либо вообще встревают левые люди, которые не имеют прямого отношения к проекту.
    • Распределение поощрений. Когда за твои идеи и твою реализацию клиент благодарит саппорт (деплойнувшего софт) и начальника (отчитавшегося об успехе), а тебе лишь форвардят мейлом поздравление клиента, который вобщем-то особо и не знает о твоем существовании. Демотивирует. Благо в моем случае премию все-таки выписывают.
    • Перфекционизм. Постоянное желание продемонстрировать себя и свои возможности, и сделать все максимально хорошо. Огромное количество сил тратится на это, причем в порыве перфекционизма человек не контролирует их расход. С другой стороны играет фактор времени и дедлайн — приходится осознанно делать хрень, не получая от этого должного удовлетворения.
    • Перегруженность навыками. Технологии постоянно меняются. Хочется всегда быть в тренде, попробовать новый фреймворк, технологию, методику. В результате на изучение и освоение тратится гораздо больше сил, чем на саму задачу. Демотивирует постоянное ощущение того, что ты не догоняешь и не успеваешь за технологиями: только освоил одно — уже другое в моде, и не хватает никаких сил изучить все, что хочется. Признак перегруженности навыками — это когда для простой задачи у тебя в голове возникают сразу десятки методов решения, и ты тупо не можешь выбрать между ними: какой фреймворк, тех. средство или архитектуру использовать, etc...
    • Специфика работы. Девелопмент — это всегда стресс и негатив, привыкните. Здесь жестко бьются о камни ваши мечты об идеальном коде и совершенной системе. Прежде чем что-то заработает, вы столкнетесь с тонной багов разного рода: как ваших, так и не ваших (фичи). Вашу систему будут смаковать совсем другие люди (некие мифические пользователи), а вам будут присылать только багрепорты и жалобы.
  • Адский проект
    0

    Я не знаю ваш юзкейс, поэтому не могу судить о резонности применения ESB. В нашей среде практически все системы общаются через SOAP и Rest в рамках установленных бизнес-процессов. ESB здесь лишняя.


    По поводу выбора инструментов: разобраться с Camel-ом не составит труда любому компетентнорму джависту. А вы попробуйте сделать то же самое на каком-нибудь пропиетарном продукте типа IBM Message Broker или Oracle Service Bus. Сначала встанет проблема найти соответствующих специалистов, затем вы ужаснетесь их ценам, и, наконец, разочаруетесь в их профессиональной компетентности. В итоге любое изменение в ESB выходит гораздо дороже и больнее, чем в системах.

  • Адский проект
    +1

    Ну это какой-то очень специфический пример. В реальных процессах взаимодействие между системами сводится к двум типам операций: когда одна система должна либо вызвать другую и получить от нее какие-то данные (request-reply), либо оповестить ее о событии (one-way). В теории ESB преподносят как решение следующих задач:


    1. Роутинг. Системы ничего не должны знать об инфраструктуре, вместо этого они имеют single connection point с ESB, которая осущесвляет доставку месседжей до получателя.
    2. Assured delivery. Абстрагирование от транспорта, защита от сбоев сети, остановов систем, перегрузки, etc...
    3. Версионирование и адаптация. Позволяет системам иметь разный релизный цикл. Для каждого получателя ESB может адаптировать формат сообщения и обеспечить совместимость.
    4. Мониторинг.

    Однако это в теории. А на практике:


    1. Инфраструктура меняется редко, есть более простые решения service discovery, начиная от DNS и заканчивая Consul-ами. К тому же с современной тенденцией контейнеризации и клаудизации это становится неактуальным. А single connection point усложняет взаимодействие 1-N, когда producer должен отвечать одному из N consumer-ов, который послал запрос. Появляется таблица правил роутинга, и прочая ненужная фигня.
    2. Ребята, которые сидят на ESB, иногда не слыхивали самого термина QoS, и уж тем более какие параметры установлены. Например ситуация, когда клиент уже устал ждать запрос и благополучно отвалился с ошибкой, а ESB все еще пытается задвинуть request в удаленную систему, вызывая тем самым рассинхронизацию общего состояния. О существовании DLQ узнают только, когда она вдруг переполняется.
    3. Иногда необходимо только для интерфейсов 1-N. Но как правило service consumers без посторонней помощи сами адаптируются к изменениям интерфейса producer-ов, а producer-ы зачастую сами версионируют свои интерфейсы, либо поддерживают обратную совместимость. Большинство же корпоративных интерфейсов 1-1, и оба — producer и consumer синхронно эволюционируют в рамках затронувшего изменения. Так что ESB тут пятым колесом.
    4. Серьезно? У вас че-то не работает — ваши проблемы. А эти ребята из ESB всегда с краю. Пока их мордой не ткнешь в косяк. А когда начинают теряться месседжи, так вообще футбол: A: "мы все отправили", B: "мы ничего не получили", ESB: проблемы где-то у вас, мы ничего не знаем.

    А вот реальный пример как работает эта ваша ESB в корпоративном секторе. Система TOA должна списывать расходный материал в инвентаре, хранящемся в SAP. Посредник — Oracle Service Bus, через который посылается месседж о расходе. Временами SAP подглючивает, либо валится, и месседж не проходит (их светлость не соблаговолила разобраться с проблемой). ESB оказались не в состоянии обеспечить deferred re-delivery (или попросили за эту фичу круглую сумму — история умалчивает). В итоге дешевле и проще оказалось написать демона, который в конце рабочего дня лезет в TOA и аптейдит неучтеные расходы в SAP.
    И вот на том и стоит весь корпоративный сектор: мажорные говнопродукты + куча скрепляющего самопального говна.

  • Адский проект
    0

    Архитектор? Не, не слышали. В лучшем случае вся архитектура — это tutorials + best practices от производителя.


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


    И да, продукты дерьмо!

  • Адский проект
    +2

    Блин, как знакомо! Почти то же самое, только в одной крупной испанской транснациональной корпорации. Инструменты разработки — стек пропиетарных говнопродуктов нескольних крупных производителей со всеми вытекающими маразмами: BPM, ESB, MQ, Unix, Spark. Специалистов разработки нет. Организационная структура — перевернутая пирамида (продукт надо задвинуть в несколько стран, соответственно на каждую страну свой менеджер с командой дармоедов и т.д.). Постоянные трения, борьба за влияние и выяснение кто главный. Коммуникаций между командами никаких — каждый ревностно защищает свой огород, чтобы казаться незаменимым. Команда постоянно пухла, но вместо специалистов нанимались новые руководители, которые были даже не в курсе, кто и над чем работал в их команде. Проект переживал постоянные реорганизации, только за мое время сменилось 5 начальников. Специалисты вместо кодинга собирались в комнате и неделями обсуждали концептуальность того или иного решения, рисуя на доске бесконечные ящики и стрелочки.
    В итоге проект зашевелился, когда наступил кризис, закончилось бабло и уволили 90% команды.
    Из плюсов: платили хорошо, бабла было немеряно, кормили на убой, сортиры мыли несколько раз за день, кофе бесплатный, работа начиналась в 10:30.

  • Профиль неидеального клиента. Каким клиентам отказывать и почему это жизненно важно
    0

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


    Согласно моему опыту, толстый клиент требует не столько новых фич, сколько покрытия всяких очень специфических кейсов. И тут возникает дилемма — с одной стороны хочется заимплементить функционал как можно более generic-ом, модульным и гибким, чтобы потом можно было его переиспользовать, а с другой — не хочется сильно заморачиваться для каждого конкретного кейса, и проще вставить костыль прямо в код системы. И в итоге так или иначе ваш продукт превращается в сервис. Соответственно и экономическая модель должна быть как у сервиса, а не как у продукта.

  • Профиль неидеального клиента. Каким клиентам отказывать и почему это жизненно важно
    +7

    Если честно, я нифига не понял. Общее впечатление — крупно продешевили на этапе продаж. Потому что в итоге все упирается в деньги — остальное все так или иначе решается. Не хватает фич — наймите больше девелоперов, сделайте специализированный форк продукта, организуйте техподдержку… По ходу автор застрял еще в девяностых и продает коробочную версию своего продукта, поэтому идеальный клиент для него — тот, который молча пришел в магазин, купил и установил на свой ПК.


    Хреновых клиентов бывает два типа:


    1. Жмот. Это тот, который изначально не расположен платить за продукт или услуги. Купив базовую версию по огромной выклянченой скидке, он потом вынесет всем мозг, и еще потребует за это деньги. Как правило распознать таких клиентов несложно, и их нужно посылать сразу.
    2. Самодур. Сорит деньгами, но при этом требует танцевать на животе со спущенными штанами. Все силы и деньги будут уходить на реализацию нефункциональных требований, свистелок и перделок, тогда как реально необходимые задачи окажутся непокрытыми. Вскоре проект признают нерентабельным и от него откажутся, а крайним окажетесь вы, ибо "несправились с возложенными надеждами".
  • 13 причин перейти на Kanban. И никаких суеверий
    +3
    Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.

    Именно, когда весь функционал — это большое количество небольших независимых напрямую друг от друга задач. А вот например когда вам нужно провести полный редизайн системы для последующего роста, вы задолбаетесь делить задачи и сортировать по их зависимости друг от друга.
    Scrum основан на ряде априорных допущений и упрощений, которые в общем случае не верны, и зачастую создает лишь видимость эффективной работы. К сожалению, нет объективных и достаточно надежных показателей, позволяющих оценить эффективность внедрегия scrum.

  • Swift vs. Kotlin. Отличия важны
    0

    Передача по ссылке или значению — это архаизмы реализаций компиляторов и языков прошлых лет, когда это имело смысл. На сегодняшний день важно лишь, что описываемая сущность является мутабельной или иммутабельной. В случае иммутабельной сущности нам не важно передается ли она по значению или по ссылке и где физически она находится в памяти — это уже внутренние проблемы компилятора и рантайма. При операциях с иммутабельными сущностями каждый раз создается новый экземпляр. Таким образом иммутабельные классы полностью идентичны value type (подразумевается наличие equals()/hashCode()).


    В случае же мутабельной сущности, мы имеем каждый раз дело с экземпляром, занимающим определенное место в памяти, и поэтому осознанно работаем с ним по ссылке (некоему хэндлу, если угодно). Для передачи информации о внутреннем состоянии мутабельного объекта вовне есть два способа: хороший — обернуть его иммутабельным врапером, либо плохой: просто сделать defensive copy и отдать на растерзание. Структуры в Свифте — это просто реализация defencive copying по умолчанию, тогда как в Котлине это нужно делать въявную. Мне кажется не стоило делать отдельный класс объектов языка только лишь для реализации одного паттерна. Тем более, что изначально структуры (записи) в языках программирования означали немножко другое и появились задолго до классов.

  • Почему я не люблю DevOps (и современное ПО)
    0

    Когда ответственность за функционирование и сопровождение системы ложится полностью на девелоперов, отмазаться будет сложно: ваша система периодически падает — чините как хотите, тестируйте, мониторьте — ваши проблемы.
    С другого конца, когда требования устанавливает некий дядя, называющий себя product owner-ом, девелопер никогда не видит реальных результатов своей работы, не получает должного feedback (кроме бесконечных ошибок и изменений), то его не особо беспокоит качество кода, нефункциональные требования и пр. — пусть об этом голова болит у дяди, ему за это платят. Цель девелопера в этом случае становится не сделать продукт, а закрыть issue.
    Так что чем больше посредников в процессе разработки, тем больше разделение ответственности, что всегда негативно сказывается на качестве финального продукта.

  • Почему я не люблю DevOps (и современное ПО)
    0

    Прошла первая очередь, тесты отработали, и все выкатили на продакшн — и все свалилось в первый же день. Причина — какой-нибудь resource или memory leaking в пулах или кешах. Девелоперы винят тестеров, что те не обнаружили. Тестеры отмазываются, что это нефункциональные требования и ничего не хотят об этом знать. Вот если бы девелоперы сами готовили тесты, то метрики пулов скорей всего были бы включены в тесткейс.

  • Изменения в стандартной библиотеке Java 10
    +1

    Все зависит от глубины изменений. Если речь идет только о новом методе или классе, то самый безболезненный способ — это сделать обычный интерфейс-враппер, а имплементацию подключать динамически через factory или singleton. Уверен, что когда количество изменений вырастет, появятся всякие backport-библиотеки вроде retrolambda. Теперь представьте, что поменялась версия байткода. Тогда по-любому придется делать два билда с разными --target и собирать два разных джарника. Либо если произошла радикальная смена API как в случае с Java8, то вообще придется говорить о двух разных версиях библиотеки, собранной из разных исходников. Multirelease jars же все усложняют: лейаут проекта, компиляцию, сборку и тестирование. Вобщем, поживем-увидим. Пока что пипл не слишком с энтузиазмом относится к фиче.

  • Почему я не люблю DevOps (и современное ПО)
    –2
    Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей.

    Нифигасе заявление! Да практически все идеи генерятся девелоперами! Просто в большинстве компаний сложилась такая номенклатурная организация, что между пользователем и девелопером стоят люди, называющие себя аналитиками, которые практически никогда в жизни не писали код. Они слабо представляют сам процесс разработки, архитектуры и огранизации системы, возможности кода и трудозатраты, и тем не менее сидят на своем месте и получают зарплаты. Это такие как Tom Smykovski из легендарного Office Space, который заявлял: "I have people skills":
    image


    Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте)

    Вы упускаете ОЧЕНЬ важный момент: разделение труда работает только в тех системах, где взаимодействие между членами минимально, и упрощено насколько это возможно, а сам труд реально разделяем — тогда это работает. Инженерная же идея, тем более достаточно сложная, очень плохо скалируется по головам. Если команда девелоперов придумала и закодила функционал, нужно будет объяснять все детали реализации команде тестировщиков, чтобы те, из того, что они поняли, смогли написать кое-какие тесты. А кто лучше сможет написать тесты и покрыть больше кейсов, чем сами девелоперы?


    Из негативных эффектов разделения труда — это круговая порука и сбагривание ответственности. В девопсе же девелопер несет ответственность до конца.


    P.S. Говоря о девопсе, вы полностью упустили сам "опс", например команду админов, которая файерволом стоит между девелоперами и продакшном и фактически не дает девелоперам видеть, что происходит с их кодом на сервере.

  • Изменения в стандартной библиотеке Java 10
    0
    Ещё одна доработка большой фичи, появившейся в Java 9: Multi-Release JARs. Напомню, это возможность в одном JAR-файле иметь несколько версий одного и того же класса или ресурса, соответствующих разной версии Java.

    Мне одному кажется, что это заведомо рудиментарная вещь? Она идет вразрез с имеющимися билд тулзами, процессом сборки и выкатывания, и вообще со здравым смыслом. Версионирование должно быть на уровне всей библиотеки, как это делается сейчас, а не отдельных классов. А уже рантайм должен (был) уметь цеплять версию библиотеки, соответствующей релизу, если такая присутствует.


    Общее впечатление: я так понимаю, эволюция Java Api остановилась, и будущие изменения будут затрагивать по большей части JVM?

  • Что это такое – BPM, и как компании его строить
    0

    Согласно моему опыту основной ошибкой клиента всегда было неправильное внедрение BPM. Последнее предполагает не только смену методики работы компании, но и определенную реструктуризацию, на всех уровнях. А к этому бывают далеко не все готовы. Кроме того есть ряд тормозящих политических факторов, например, топ-менеджеры и управляющие кадры, которые не очень счастливы, чтобы с их работы снимали различные метрики эффективности либо как-то реструктурировали. Поэтому на "попробовать" всегда берут какой-нибудь департамент из Operations и насильно втюхивают туда BPMS, где его вообще в гробу видели, и где большинство процессов уже автоматизировано на 100%. В итоге параллельно с уже работающим стеком, вторая бригада пыхтит над тем, чтобы перевести все процессы на BPMS, вызывая лютый баттхерт у первой по причине постоянного ощущения инородного тела в заднице. По прошествии n-дцать месяцев то, что добивается данная бригада, это сделать тупую прокси-надстройку с парой линейных "процессов" над уже работающими сервисами, гордо объявив это все "Orchestration Layer". После этого отчитываются наверх об успешном запуске, получают медаль и на этом все завершается.

  • Что это такое – BPM, и как компании его строить
    +1
    Инструкция, регламентирующая расчет стоимости, включает многостраничный текст, и чтобы ее прочесть и освоить, понадобится как минимум несколько дней. Диаграммы составлены в строгом соответствии с этой инструкцией, но, естественно, они ее не заменяют, а дополняют – благодаря простоте и наглядности экономят время на расчеты

    Изначальную инструкцию хорошо использовать для составления тестов к функционалу, чтобы удостовериться, что код работает именно так, как написано. А уж имплементить ее именно таким образом никто не заставляет. Адекватный программист (не занимающийся BPM) вместо "процесса рассчета стоимости номера в пансионате" заимплементил бы простую и наглядную функцию с тремя условиями на семь строчек кода. А адекватный аналист пришел бы к клиенту и сказал: "а давайте вместо этой фигни попробуем сделаем простую наглядную таблицу коэффициентов для стоимости номера, которую к тому же можно будет менять в любой момент". И только BPM аналист, у которого в голове одни схемы, станет изобретать некий "процесс" для вычисления простой функции, вместо того, чтобы записать простую формулу.


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

    Это понятно, упорядочение, автоматизация и все такое. И BPMS здесь как бы даже сбоку. Скажите лучше о граблях:


    • уменьшение общей гибкости взаимодействия — все жестко поставлено на рельсы, по полю уже не проедешь
    • увеличение рисков нештатных ситуаций (что-то пошло не по процессу) и отсутствие соответствующих инструкций для реагирования
    • формализация управления и разделение труда ведет к тому, что меньше людей имеет общее представление о решаемой задаче, что ведет к общей бюрократизации
    • несмотря на предоставляемый автоматический мониторинг и обилие метрик, выявление неэффективностей в процессах будет затруднено и более того, реально никто этим заниматься не собирается. Метрики используются исключительно для составления бесполезных отчетов, а не для анализа.
      И когда ситуация ухудшается полностью, вызывают бригаду "оптимизаторов бизнес процессов", которые обнаруживают, что несмотря на всю автоматизацию и BPM, треть персонала фактически ничем не занята, а все бизнеспроцессы надо (опять) менять. Иногда это помогает.
  • Самое опасное слово в разработке программного обеспечения
    +8

    Помимо "просто" меня жутко бесит слово "ВСЕ". Употребляется в контексте, когда нужно добавить новый функционал, но заказчик/менеджер не имеет представления о всей конкретике работы системы, либо тупо не хочет заморачиваться.
    — В какую форму добавить коментарий? — Во ВСЕ!
    — В каком сценарии вызывать этот интерфейс? — Во ВСЕХ!
    — Для пользователей каких ролей сделать проверку? — Для ВСЕХ!
    — Какие интерфейсы экспортировать для удаленного использования? — ВСЕ!

  • Объект в футляре или Optional в Java 8 и Java 9. Часть 1: «Как без него прожить?»
    –1

    Идея как раз в том, чтобы исключить искусственные методы типа isActive() и isPresent() и соответствующие проверки (они ни чем не лучше проверки на null). Возвращаемый "пустой" объект имеет полностью осмысленное поведение при вызове своих методов, и не требует специальных кейсов в логике программы. Например с пустой сторокой можно делать все те же операции, или например пустой список можно также итерировать в цикле без специальной проверки.


    я не понял зачем нужен EMPTY если не имплементируется equals()

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


    public class AnotherClass {
        public MyClass myClass = MyClass.EMPTY;
    }

    Это в случае если класс MyClass immutable. Тогда проверку на empty можно делать простым сравнением "==", но при желании можно добавить и equals()/hashCode(). Хотя как я уже сказал выше, поведение кода не должно отличаться в случае пустого или непустого объекта и не должно содержать искусственных проверок.


    Ну а список можно сделать immutable с помощью Collections.unmodifiableList()

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


    userService.getUsers().add(new User());

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

  • Объект в футляре или Optional в Java 8 и Java 9. Часть 1: «Как без него прожить?»
    –1

    Не использовать вообще нулевые значения.
    У большинства стандартных типов существует некое дефолтное значение, которым можно заменить null. Например для числовых типов это ноль, для String это пустая строка "", для списка — пустой список, etc.
    Поля класса сразу инициализируйте дефолтными значениями.


    Для собственных типов можно использовать можно искусственно определить нулевое значение и при необходимости сравнивать с ним.


    public class MyClass {
      public static final MyClass EMPTY = new MyClass();
    
      public final String name;
      // Optional field, "" by default
      public final String address;
    
      protected MyClass() {this("","");}
      public MyClass(@Nonnull String name) {
        this(name,"");
      }
      public MyClass(@Nonnull String name, @Nonnull String address) {
        this.name= name; this.address = address;
      }
    }

    Возвращается лист, возможно пустой
    Проблема в том, что лист mutable. Лучше возвращать Iterator или Stream.
  • Почему мне кажется, что студентов учат ООП неправильно
    0

    Извиняюсь, что поздно ответил.
    Смысл в том, при пожирании одновременно определенным образом изменяются состояния и собаки и сосиски. Однако первый вариант нарушает инкапсуляцию сосиски: собака должна знать как изменить свое собственное состояние (ок), но также и состояние сосиски. Во втором варианте соответственно нарушается инкапсуляция собаки.
    А третий вариант — это тупо процедурное программирование, закамуфлированное под объект, со всеми вытекающими (нарушение инкапсуляции, отсутствие полиморфизма).


    С упомянутым Вами удалением сосиски все еще хуже: после пожирания на сосиску остается указатель, поэтому впринципе одну и ту же сосиску можно скормить разным собакам, если не ввести искусственный контроль :)


    В более сложной модели собака и сосиска должны обменяться сообщениями типа собака-сосиске: "я тебя ем с такими параметрами", сосиска-собаке: "вот мои питательные вещества". Это будет более корректно. Иными словами собака и сосиска реализуют двунаправленный интерфейс "сожрать"-"быть сожранной" с двумя каналами. Но это уже больше похоже на модель акторов, нежели ООП.

  • Почему мне кажется, что студентов учат ООП неправильно
    0

    Не существует никаких классов и сущностей, есть только интерфейсы. Абстрактный водитель может управлять всем чем угодно, что реализует стандартный интерфейс "автомобиль" и имеет руль, педали и прочие приблуды. Более того, для управления нам не нужна никакая сущность типа "абстрактный или конкретный автомобиль": водитель может ездить на тренажере по виртуальной локации еще вместе с десятком таких же водителей. Здесь "сущность", которой управляем, уже выделить сложно. Точно также с другой стороны у нас нет никакой необходимости в сущности "абстрактный водитель" — стандартным такси может управлять механизм, подключенный к единой сети, которая управляет его действиями.


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


    • собака.сожрать(сосиска)
    • сосиска.бытьСожранной(собака)
    • new ПожирательноеДействие(собака, сосиска).сделать()
  • Servlet 4.0: Делаем больше быстрее. Server Push
    0

    Прикрутили сбоку модную фичу для галочки.
    Никого не напрягает, что на coffie-cup.jpg уже ссылаются из .jsp и что чуть более интеллектуально развитый темплейтер мог бы сам запушать автоматически все необходимые ресурсы? Ну или на крайняк придумать специальную директиву для .jsp, чтобы там же рядышком прописывать все, что надо запушить. А модифицированные сервлеты уж никак не есть естественное место для справления своих потребностей в пуше.

  • Почему Agile не работает и что с этим делать
    0
    Во-первых, в разработке ПО есть такое понятие как гибкость.

    Да, в отличии от инженерного дела разработка ПО не ограничена жестко законами физики, поэтому позволяет девелоперам творить любую фигню — машина все проглотит. Тем не менее, базовые принципы построения проекта никто не отменял.


    Он просто позволяет делать качественный продукт в условиях неопределенности.

    А как вы себе представляете неопределенность? Продукт призван решать определенные задачи, для этого создаются определенные решения. Единственная область, где я вижу более-менее оправданное использование agile — это типичный веб-проект: страничка, сервер и база данных. Клиент пока не знает что конкретно ему нужно, но вы пока начните, сделайте форму логина, потом утвердим дизайн, определимся с функционалом, добавим пунктиков в меню, табличек в БД, etc… Архитектуры — ноль, зависимости слабые, объем работы скалируется и хорошо делится. Типичная дача.

  • Почему Agile не работает и что с этим делать
    0

    Видите ли, снести деревянный сортир на дачном участке и поставить новый железный не составит большого труда. А вот снести целый этаж в уже работающем здании, или поднять везде потолки — будет большой проблемой, равно как и надстраивать этажи в середине, особенно когда у вас вместо фундамента — кирпичи, оставшиеся с первой итерации. И как бы в этом случае клиент не очень намерен платить за различного рода переделку, редизайн и все такое — он всегда хочет видеть новый функционал. Так что объем работ изначально должен быть оценен и составлен более-менее подходящий план (а клиенту сообщена цена), и первая итерация — это возведение каркаса всего проекта, которая всегда будет достаточно долгой, и которая всегда необходима прежде, чем проект начнет наполняться реальным функционалом.

  • Почему Agile не работает и что с этим делать
    0

    Совершенно верно. Agile — это когда вы строите для клиента дачу. Можно начать с возведения сортира, затем пилить баню, забор, сарай, потом приступить к дому, затем пристройку, потом домик для гостей — все по необходимости, и главное, чтобы народ был занят. А вот многоэтажку таким методом построить уже проблематично.

  • Блеск и нищета джавовых веб-фреймворков
    +2

    А дело в том, что Java изначально семантически очень плохо приспособлена для декларативных конструкций и DSL-ей. Фреймворки, построенные на аннотациях — это некий компромисс между декларацией и исполнением, причем очень фиговый по сравнению с тем же DSL. В бекенде еще как-то прокатывает, но во фронтенде, где приходится создавать иерархические конструкции (напр. DOM), в императивном стиле на Java это превращает код в линейную кашу. Поэтому на Java никогда не было и не будет нормальных html-темплейтеров, тем более type-safe как на скале или котлине. Хотя попытки есть: https://j2html.com/

  • Блеск и нищета джавовых веб-фреймворков
    +1

    GWT абсолютно ничего не имеет общего с Java-рантаймом. Это распространенное ошибочное мнение. У него есть определенная Runtime Library Emulation, чтобы можно было работать с коллекциями, строками, стримами, лямдами, etc как в Java. Но в рантайме GWT не таскает с собой вообще никакие библиотеки. Вместо этого он анализирует весь код приложения начиная от EntryPoint, включая только те функции из всей кодовой базы, которые используются въявную (а для 100% явности была выпилена reflection). Остальной шлак жестко шринкается. Дополнительными бонусом идет минимизация и обфускация. В итоге для функционального приложения код получается меньше, чем на нативном JS, т.к. последний грузит все используемые JS-библиотеки полностью со всем функционалом. Кстати, GWT поддерживает SourceMaps при запуске в DevMode, поэтому можно дебажить вживую в Chrome или Firefox, а в SourceMaps показывается только Java-код, который GWT оставил после шринкинга, т.е. то, что реально будет в рантайме.


    Насколько GWT-код может быть минимальным полностью зависит от того, что вы будете использовать. Откажитесь от стандартных GWT-виджетов и UiBinding, используйте библиотеку Elemental, и Overlay Types. Для манипуляции с DOM-ом для GWT есть аналог JQuery — GwtQuery.

  • Блеск и нищета джавовых веб-фреймворков
    +2

    Ну, тут целой статьи мало будет, если рассматривать все косяки языка и его интергации с браузером. Для меня основным недостатком является динамическая типизация. При нескольких кодерах и растущем функционале код постепенно превращается в натуральное дерьмо, отрефакторить которое будет очень нетривиальной задачей. Как правило количество тупых тестов в JS-проектах зашкаливает, которые тестируют не функционал, а тупо правописание. Для меня основное преимущество статический типизации не в раннем обнаружении ошибок при компиляции, а в поддержке IDE:


    • индикация описок, и ошибочных идентификаторов
    • подстрочник: подсказки при вызове методов
    • элементарный рефакторинг
    • простая навигация по коду (своему и библиотечному), позволяющая отследить всю цепочку вызовов
    • контрактный стиль программирования
    • различные тулзы для статического анализа кода
    • умные хинты и варнинги от IDE
    • кодогенерация и умные темплейты
  • Блеск и нищета джавовых веб-фреймворков
    0
    Да, многие из нас работают в банках, и там всё на GWT. Но, оглядываясь назад на этот долгий-долгий путь, давайте честно признаем: управлять JavaScript из Java — наиболее дурацкая и деструктивная идея, которая когда-либо приходила в голову.

    В GWT Java не управляет Javascript-ом. Java управляет DOM-ом, точно также как это делает Kotlin.js, Scala.js, TypeScript, Dart и вообще любой кросс-компилятор в JavaScript. Более того, это то, что должно было мейнстримом по причине ущербности JavaScript-а, но внезапно успело подрасти поколение JS-рунов, которым ущербность языка и динамическая типизация стало норм.
    Для сложных клиентских приложений использование GWT очень даже оправдано.
    GWT-проект очень нетривиально подготовить для воркбенча (вкратце пускайте вручную com.google.gwt.dev.DevMode.main(args)), но работает сносно и инкрементально компилится достаточно быстро.

  • Что я узнал после 1000 code review
    +1

    Не совсем понимаю чем вторая запись лучше и понятней первой. Если str объявлен как @Nullable, то при возможном NPE тулинг выдаст варнинг — и этого в большинстве случаев достаточно. Кроме того, тулинг достаточно умный, чтобы выводить @Nullable по коду.


    Кроме того, в данном случае, как я и говорил, имеет смысл вообще использовать @Nonnull String str = "" вместо null или Optional. И никаких проверок делать не надо.


    NPE исключен

    Да ладно?


    Optional<String> calculate() {
        return null;
    }
    Optional<String> str = calculate();
    ...