Давненько не писал про свои факапы.
Вспомнился один, древний. Когда давным-давно я работал в компании, где разработка была на Delphi. И уже тогда было понятно, что Delphi не жилец, и нужно переходить на другую платформу.
Ремарка - а Delphi то еще жив: https://habr.com/ru/articles/928810/ Может зря с него слезли?))))
Вводные следующие: небольшая компания, переход от коробочных решений к заказной разработке на основе свой платформы, CRM\MIS системы.
Так вот, на тот момент у нас было два пути - .NET и Java.
Из стека Microsoft уже использовался MS SQL Server, для хранения OLTP данных и OLAP кубов. Ну и Windows с Office само собой.
И надо сказать, что Microsoft тогда (и думаю до 2022 года) активно работала с мелким бизнесом. Несколько конференций в год, бесплатные лицензии для разработки. Прямо кейсы с CD дисками по почте присылали с новыми версиями ПО.
Они еще для Linux решение как раз в то время пилили, так что и этот потенциальный вопрос снимался.
И как язык C# был лучше Java, особенно если смотреть ее начальные версии. Он ведь как раз исходя из уроков Delphi и Java был создан бывшим архитектором Delphi. Java более менее его догоняет только сейчас.
И видимо по этой причине - знакомая компания, частично знакомый стек - я как лид разработки сильно топил за .NET.
Причем лично мне Microsoft ничего не предлагал - на всякий случай)
Сила бренда. Ну и возможно конференции)
В итоге после жарких баталий выбрали Java. По прошествии времени могу сказать - и правильно сделали.
И дело даже не в языке. Сравним https://www.tiobe.com/tiobe-index/java/ vs https://www.tiobe.com/tiobe-index/csharp/
Да, позиции Java выше, C# так и не обогнал Java. И уже не обгонит) Но тренды у обоих языков не очень не очень.
Дело в vendor lock. Все-таки большинство компонентов от Microsoft - коммерческие. VS Code из бесплатных приходит на ум. Завязка на экосистему Windows велика, а эта экосистема больше клиентская, чем серверная. Сообщество разработчиков меньше. Не сравнивал количество библиотек, но почему-то уверен, что для Java их сильно больше.
Ну и все мы живем в мире победившего open source. Сервера приложений, ESB, Windows на серверах ушли. В области SQL хранилищ - Oracle и MSSQL пока держаться, но их теснят. В noSQL практически все open source. CI\CD - тоже. Вот разве что IntelliJ IDEA остается вне конкуренции. Eclipse и NetBeans не смогли, а наследники IDEA вряд ли станут open source.
Вывод философский: иногда стоит отказаться от привычных инструментов и шагнуть в неизведанное. Предварительно прикинув все плюсы и минусы, конечно. Оно может стать мейнстримом)
#fuckups #java #dotnet #delphi
Вспомнился один, древний. Когда давным-давно я работал в компании, где разработка была на Delphi. И уже тогда было понятно, что Delphi не жилец, и нужно переходить на другую платформу.
Ремарка - а Delphi то еще жив: https://habr.com/ru/articles/928810/ Может зря с него слезли?))))
Вводные следующие: небольшая компания, переход от коробочных решений к заказной разработке на основе свой платформы, CRM\MIS системы.
Так вот, на тот момент у нас было два пути - .NET и Java.
Из стека Microsoft уже использовался MS SQL Server, для хранения OLTP данных и OLAP кубов. Ну и Windows с Office само собой.
И надо сказать, что Microsoft тогда (и думаю до 2022 года) активно работала с мелким бизнесом. Несколько конференций в год, бесплатные лицензии для разработки. Прямо кейсы с CD дисками по почте присылали с новыми версиями ПО.
Они еще для Linux решение как раз в то время пилили, так что и этот потенциальный вопрос снимался.
И как язык C# был лучше Java, особенно если смотреть ее начальные версии. Он ведь как раз исходя из уроков Delphi и Java был создан бывшим архитектором Delphi. Java более менее его догоняет только сейчас.
И видимо по этой причине - знакомая компания, частично знакомый стек - я как лид разработки сильно топил за .NET.
Причем лично мне Microsoft ничего не предлагал - на всякий случай)
Сила бренда. Ну и возможно конференции)
В итоге после жарких баталий выбрали Java. По прошествии времени могу сказать - и правильно сделали.
И дело даже не в языке. Сравним https://www.tiobe.com/tiobe-index/java/ vs https://www.tiobe.com/tiobe-index/csharp/
Да, позиции Java выше, C# так и не обогнал Java. И уже не обгонит) Но тренды у обоих языков не очень не очень.
Дело в vendor lock. Все-таки большинство компонентов от Microsoft - коммерческие. VS Code из бесплатных приходит на ум. Завязка на экосистему Windows велика, а эта экосистема больше клиентская, чем серверная. Сообщество разработчиков меньше. Не сравнивал количество библиотек, но почему-то уверен, что для Java их сильно больше.
Ну и все мы живем в мире победившего open source. Сервера приложений, ESB, Windows на серверах ушли. В области SQL хранилищ - Oracle и MSSQL пока держаться, но их теснят. В noSQL практически все open source. CI\CD - тоже. Вот разве что IntelliJ IDEA остается вне конкуренции. Eclipse и NetBeans не смогли, а наследники IDEA вряд ли станут open source.
Вывод философский: иногда стоит отказаться от привычных инструментов и шагнуть в неизведанное. Предварительно прикинув все плюсы и минусы, конечно. Оно может стать мейнстримом)
#fuckups #java #dotnet #delphi
Хабр
Жив ли Delphi в 2025 году? Погружение в технологии, релизы и мнение сообщества
Немного истории и контекста Delphi — легендарная RAD-среда, известная с середины 90-х. Её эпоха расцвета пришлась на Delphi 5-7 и Borland'овский бум. Многие разработчики (включая автора этой статьи)...
👍1
image_2025-07-30_16-31-11.png
290.4 KB
Хочу порекомендовать попробовать такую фичу IDEA, как Kotlin Notebook.
Это конечно заимствование из ML и Python. Суть на картинке выше, но я дам краткое описание.
У нас есть один файл, который содержит как куски кода, так и текст с картинками в формате Markdown. Куски кода (snippet) можно исполнять прямо в файле, т.е. output появляется под кодом. Исполнять можно как сразу все - не интересно - так и по очереди. Результат исполнения сохраняется в контексте. Т.е. если в первом snippet-е объявили функцию, вызвали его, то во-втором можно ее использовать. Она даже красным перестает в этот момент светится. Т.к. autocomplete, подсказки IDE, документация - все работает.
Как по мне - удобная штука для разработки и отладки алгоритмов. Да, их в энтрепрайзе мало, но они есть)
Почему удобная - рядом и аналитика, и код.
Создать новый Notebook можно в Kotlin или Java проекте через меню New.
P.S. Для Java такое можно сделать - с помощью того же jshell. Но IDEA пока не умеет.
P.P.S Да, как и всегда (почти) в мире Java - инициализация ноутбука долгая)))
#kotlin #java #idea
Это конечно заимствование из ML и Python. Суть на картинке выше, но я дам краткое описание.
У нас есть один файл, который содержит как куски кода, так и текст с картинками в формате Markdown. Куски кода (snippet) можно исполнять прямо в файле, т.е. output появляется под кодом. Исполнять можно как сразу все - не интересно - так и по очереди. Результат исполнения сохраняется в контексте. Т.е. если в первом snippet-е объявили функцию, вызвали его, то во-втором можно ее использовать. Она даже красным перестает в этот момент светится. Т.к. autocomplete, подсказки IDE, документация - все работает.
Как по мне - удобная штука для разработки и отладки алгоритмов. Да, их в энтрепрайзе мало, но они есть)
Почему удобная - рядом и аналитика, и код.
Создать новый Notebook можно в Kotlin или Java проекте через меню New.
P.S. Для Java такое можно сделать - с помощью того же jshell. Но IDEA пока не умеет.
P.P.S Да, как и всегда (почти) в мире Java - инициализация ноутбука долгая)))
#kotlin #java #idea
Java vs Python, часть не помню какая)
Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.
Вот еще пример.
Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery
А что есть в Java? Есть ли что-то?)
BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.
Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)
#java #python #data_science
Я уже делал несколько постов про то, как инструменты, исходно появившиеся в экосистеме Python, мигрируют в Java.
Причина я думаю понятна - большое число Java программистов, развитая экосистема.
Вот еще пример.
Важной частью Data Science является веб скрапинг (Web Scraping) - обход сайтов в сети интернет и получение из них определенного рода данных. И если вбить эти два слова "веб скрапинг" в поиск - он сразу подставит python)
Вот типичная статья из выдачи Яндекса https://habr.com/ru/companies/ruvds/articles/796885/
Основные python инструменты оттуда - BeautifulSoup, Scrapy, Selenium, lxml, pyquery
А что есть в Java? Есть ли что-то?)
BeautifulSoup - собственно парсинг страниц сайтов. Аналог в Java - jSoup https://www.baeldung.com/java-with-jsoup
Scrapy - тоже парсинг, но с многопоточкой, работой с сессией, куками. Т.е. для массового скрейпинга и работы со сложными сайтами. В Java - Webmagic https://www.baeldung.com/java-webmagic-web-crawler Возможностей поменьше, но инструмент в наличии
Selenium - не зависит от языка, вообще говоря написан на Java. В интеграционных тестах на Java я его еще лет 15 назад использовал.
lxml - быстрый парсер xml\html. Вообще у Java большой выбор парсеров: DOM, SAX, Stax. Но тут речь про работу с HTML, а HTML - это конечно подмножество XML, но, как правило - XML с ошибками. Зато в Java есть библиотечка TagSoup, цитата: "SAX-compliant parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild".
pyquery - работа с HTML в стиле jquery. Вот тут аналога не нашел, но, кажется, не критично.
Итого - экосистемы не изолированы, хорошие идеи перетекают из одной в другую. Java хоронить рано)
#java #python #data_science
Хабр
Руководство по веб-скрейпингу на Python
В этом туториале мы создадим надёжные веб-краулеры с использованием таких библиотек, как BeautifulSoup, изучим техники, позволяющие преодолевать реальные трудности при скрейпинге, а также представим...
👍2❤1🔥1
Астрологи объявили 2025 годом уязвимостей в Tomcat)
По крайней мере у меня складывается такое впечатление.
И похоже не только впечатление.
https://www.cve.org/CVERecord/SearchResults?query=apache+tomcat
24 уязвимости в 2025 году, по сравнению 15 с 2024. И год еще не закончился)
Предположу, что проблема скорее не в том, что Tomcat кривой по архитектуре или дырявый, а это обратная сторона популярности. Все-таки Tomcat - вариант по умолчанию встроенного сервера для Spring Boot приложений. И большинство его не меняют. Больше инсталляций, больше людей, которые их хотят сломать.
Но не Tomcat единым, как говорится.
Есть еще как минимум 4 сервера для JVM приложений:
1) Jetty
2) Undertow
3) Netty
4) Open Liberty
Все они production ready.
Кто может заменить Tomcat для Spring Boot приложений?
И нужно ли менять?
Начнем с того, кто не сможет.
Netty - это не контейнер сервлетов, синхронное взаимодействие Spring Web MVC он просто не поддерживает. Зато это выбор номер один для реактивщины. Как в Spring, так и в конкурирующих фреймворках Quarkus/Micronaut/Vert.x/Helidon.
И очевидно он выдает намного большую производительность и меньшее потребление памяти, по сравнению с Tomcat. Но требует полного переписывания логики на принципах реактивного программирования. А это сложно и требует я бы сказал повышенной квалификации.
Open Liberty - бывший IBM Websphere Liberty Profile, ушедший в open source. Хотя он и совместим со Spring Boot https://openliberty.io/docs/latest/deploy-spring-boot.html, два факта говорят о том, что смысла так делать нет:
1) одна из главных фишек Open Liberty - полная поддержка Java EE/Microprofile. Это точно не про Spring.
2) среди встроенных серверов Spring Boot нет Open Liberty в отличие от остальных четырех кандидатов.
Тоже побыстрее Tomcat, поддерживает модульность (а это необходимое условие при полной поддержке Java EE).
Остаются два кандидата - Jetty и Undertow.
Undertow - полностью JBoss Undertow - тоже бывшая коммерческая разработка, ушедшая в open source. Архитектурно сделана в неблокирующем стиле а-ля Netty, но с поддержкой сервлетов (Spring Web MVC). Что должно положительно сказаться на производительности. Плюс можно плавно мигрировать с кода в классическом стиле к реактивному. Минус по сути один - мало распространена, меньше сообщество. Да, и уязвимостей мало https://www.cve.org/CVERecord/SearchResults?query=undertow
И наконец Jetty. Архитектура классическая, как и у Tomcat. Разработчики делают фокус на модульной структуре: даже поддержка http (обычного, HTTP v1) обеспечивается модулем и может быть отключена. Кому интересно - вот список модулей из стандартной поставки: https://jetty.org/docs/jetty/12.1/operations-guide/modules/standard.html
Сообщество поменьше, чем у Tomcat, но достаточно большое, учитывая 20 лет на рынке. Уязвимостей сильно меньше в этом году https://www.cve.org/CVERecord/SearchResults?query=Jetty, при сравнимом количестве в 2024.
Вывод: а надо ли куда-то переходить? Для Spring Web MVC приложения большой разницы в производительности, потреблении памяти и надежности на ПРОМ я не ожидаю. Как я говорил - все сервера production ready. Но в плане уязвимостей - возможно, с Jetty жизнь станет немного спокойнее. Не ложное ли это успокоение - может "хакеры" еще не добрались до Jetty? Время покажет, но учитывая 20 лет на рынке ... очень может быть, что и нет, не ложное.
P.S. Интересно, что и IBM, и Redhat (JBoss)) пошли одним путем - выделить ядро своего сервера в отдельный lite компонент и сделать его open source.
#java #web #servlet
По крайней мере у меня складывается такое впечатление.
И похоже не только впечатление.
https://www.cve.org/CVERecord/SearchResults?query=apache+tomcat
24 уязвимости в 2025 году, по сравнению 15 с 2024. И год еще не закончился)
Предположу, что проблема скорее не в том, что Tomcat кривой по архитектуре или дырявый, а это обратная сторона популярности. Все-таки Tomcat - вариант по умолчанию встроенного сервера для Spring Boot приложений. И большинство его не меняют. Больше инсталляций, больше людей, которые их хотят сломать.
Но не Tomcat единым, как говорится.
Есть еще как минимум 4 сервера для JVM приложений:
1) Jetty
2) Undertow
3) Netty
4) Open Liberty
Все они production ready.
Кто может заменить Tomcat для Spring Boot приложений?
И нужно ли менять?
Начнем с того, кто не сможет.
Netty - это не контейнер сервлетов, синхронное взаимодействие Spring Web MVC он просто не поддерживает. Зато это выбор номер один для реактивщины. Как в Spring, так и в конкурирующих фреймворках Quarkus/Micronaut/Vert.x/Helidon.
И очевидно он выдает намного большую производительность и меньшее потребление памяти, по сравнению с Tomcat. Но требует полного переписывания логики на принципах реактивного программирования. А это сложно и требует я бы сказал повышенной квалификации.
Open Liberty - бывший IBM Websphere Liberty Profile, ушедший в open source. Хотя он и совместим со Spring Boot https://openliberty.io/docs/latest/deploy-spring-boot.html, два факта говорят о том, что смысла так делать нет:
1) одна из главных фишек Open Liberty - полная поддержка Java EE/Microprofile. Это точно не про Spring.
2) среди встроенных серверов Spring Boot нет Open Liberty в отличие от остальных четырех кандидатов.
Тоже побыстрее Tomcat, поддерживает модульность (а это необходимое условие при полной поддержке Java EE).
Остаются два кандидата - Jetty и Undertow.
Undertow - полностью JBoss Undertow - тоже бывшая коммерческая разработка, ушедшая в open source. Архитектурно сделана в неблокирующем стиле а-ля Netty, но с поддержкой сервлетов (Spring Web MVC). Что должно положительно сказаться на производительности. Плюс можно плавно мигрировать с кода в классическом стиле к реактивному. Минус по сути один - мало распространена, меньше сообщество. Да, и уязвимостей мало https://www.cve.org/CVERecord/SearchResults?query=undertow
И наконец Jetty. Архитектура классическая, как и у Tomcat. Разработчики делают фокус на модульной структуре: даже поддержка http (обычного, HTTP v1) обеспечивается модулем и может быть отключена. Кому интересно - вот список модулей из стандартной поставки: https://jetty.org/docs/jetty/12.1/operations-guide/modules/standard.html
Сообщество поменьше, чем у Tomcat, но достаточно большое, учитывая 20 лет на рынке. Уязвимостей сильно меньше в этом году https://www.cve.org/CVERecord/SearchResults?query=Jetty, при сравнимом количестве в 2024.
Вывод: а надо ли куда-то переходить? Для Spring Web MVC приложения большой разницы в производительности, потреблении памяти и надежности на ПРОМ я не ожидаю. Как я говорил - все сервера production ready. Но в плане уязвимостей - возможно, с Jetty жизнь станет немного спокойнее. Не ложное ли это успокоение - может "хакеры" еще не добрались до Jetty? Время покажет, но учитывая 20 лет на рынке ... очень может быть, что и нет, не ложное.
P.S. Интересно, что и IBM, и Redhat (JBoss)) пошли одним путем - выделить ядро своего сервера в отдельный lite компонент и сделать его open source.
#java #web #servlet
openliberty.io
Open Liberty Docs
You can enable Open Liberty to support a Spring Boot application. Open Liberty can also configure Spring Boot application arguments and properties and can also thin Spring Boot applications to use resources efficiently.