ReactJS, TypeScript, Micro FrontendsReact fwdays | 27 березня. Долучайся!
×Закрыть

Jakarta EE 9. Дорогою сліз і страждань

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Передмова

Я не планував писати окрему статтю на цю тематику. Але коли почав писати четверту частину своєї книги «Розробка Java додатків» (it-simulator.com/#/article/608 ), то зрозумів, що в світі Enterprise Java зараз відбуваються цікаві, часом революційні зміни, про які і хочеться написати.

Java EE. Боротьба за виживання

Enterprise Java (то що ми зазвичай називаємо Java EE) в останні роки переживає не найкращі часи. Починаючи з середини 2010-х років Oracle (головну скрипку в розробці Java EE) тільки ледачий не дорікав за повільність і консервативність при розробці Java EE спеціфікацій. Судіть самі, Java EE 8, яка вийшла в 2017 році, так і не отримала нічого, що б мало відношення до двох сучасних трендів backend розробки:

• Реактивне програмування
• Мікросервісная архітектура

Все, що вдалося в неї впихнути з новинок — JSON-B (Json Binding) 1.1 і Java EE Security 1.0. Критиці піддавали і тривалий (3-4 роки) процес підготовки нової версії і відсутність інновацій. З’явилося навіть співтовариство Java EE Guardians, які захищали Java EE від закриття, яке тоді здавалося цілком імовірним. Адже головний конкурент — Spring Framework тільки усталював свої позиції, а на ринку мікросервісних платформ з’являлися нові гравці — Micronaut і Quarkus.

Але закривати її не стали. Замість цього в 2017 році Java EE пересіла з ораклових рейок на нові та перейшла під крило Eclipse Foundation, незалежної організації з досить серйозними учасниками. Все це було покликане реанімувати Java EE і збільшити її популярність. Eclipse Foundation навіть погодився з претензіями Oracle на Java як торгову марку і перейменував своє нове дітище спочатку в Eclipse Enterprise for Java, а потім в Jakarta EE. Були перейменовані всі специфікації, наприклад Java Persistence API (JPA) став просто Jakarta Persistence.

Але процес переходу (перенесення коду і специфікацій) виявився не менш бюрократизованим, ніж сама розробка Java EE. Тільки у вересні 2019 року було випущено Jakarta EE 8, яка була точною копією Java EE 8. Але тут її розробники зіткнулися з дійсно великою проблемою. Oracle заборонила додавати нові пакети в кореневому пакеті javax. *, щоправда дозволивши додавати нові типи (класи і інтерфейси).

При такому розкладі розробка ускладнювалася неймовірно, тому було прийнято болісне рішення перейменувати всі javax. * пакети в jakarta. *, порушивши для клієнтських додатків зворотну сумісність. І ось в листопаді 2020 року було випущено Jakarta EE 9 з переімованнимі пакетами, а також дрібними змінами в вигляді видалення застарілих специфікацій (Corba).

Ніяких нових специфікацій в Jakarta EE 9 додано не було (просто версії існуючих збільшилися на 1), що додало деякого скептицизму. Але більшість головних Jakarta EE вендорів випустило оновлення для реалізації її специфікацій, наприклад:

• Tomcat 10, Jetty 11, GlassFish 6, WildFly 21 (Servlet API)
• Jersey 3 (JAX-RS)
• Hibernate Validator 7 (Bean Validation)
• Weld 4 (CDI)
• EclipseLink 3 (JPA)

Але і тут виникли свої фундаментальні складності. Справа в тому, що ще в 2016 році на конференції Java One виникла пропозиція створити розширення (тоді ще для Java EE 7), яке дозволяло б додавати специфікації для найбільш популярних напрямків в сучасній (читайте мікросервісной) архітектурі. Назвали цей проект Eclipse Microprofile. Його перша версія вийшла в 2017 році і містила існуючі специфікації з Java EE 7 — JAX-RS, CDI і JSON-P.
Але вже у вересні 2017 року з’явилася версія 1.2, куди були додані специфікації:

• Config 1.1
• Fault Tolerance 1.0
• Metrics 1.0
• Health 1.0
• JWT Auth 1.0

З тих пір аж до сьогоднішнього дня вийшло вже 12 головних версій Microprofile, і в версії 4.0 можна знайти і Open API, і Open Tracing і навіть Microprofile Config. Ці специфікації реалізують найбільші сервера додатків — Open Liberty, Wildfly, Payara, Thorntail і Kumuluz EE. І новий веб-фреймворк Quarkus до речі теж. Все це виглядає дуже позитивно, якби не одне лихо — Microprofile 4.0 (і все його реалізації) все ще використовує Jakarta EE 8. Це виглядає досить дивно, враховуючи, що версія 4.0 вийшла через місяць після релізу Jakarta EE 9.

Таким чином, якщо ви використовуєте Microprofile в своєму проекті, то використовувати Jakarta EE 9 ви не можете. І не зрозуміло, коли зможете, тому що немає ніяких планів про підтримку нової версії. Ходять навіть чутки, що Microprofile і Jakarta EE можуть об’єднатися в один проект, але це на рівні чуток.

Що з іншими Java фреймворками? Spring планує підтримку 9-й версії в 2021 році, без конкретних термінів:
github.com/...​ng-framework/issues/26224

Hibernate, завжди достатньо інертний в своїх планах, запланував перехід в версії 5.5, яка буде теж невідомо коли:
hibernate.atlassian.net/browse/HHH-13946

Що робити іншим проектам/бібліотекам, які з якихось причин не планують такий перехід? Є проекти, наприклад, PrimeFaces, які будуть підтримувати дві версії свого продукту (для Jakarta EE 8 і Jakarta EE 9). Як наприклад, деякі бібліотеки (Guava) випускають дистрибутиви і для JDK, і для Android. Але це не саме простий вихід, тому виник такий новий проект як Eclipse Transformer:
projects.eclipse.org/...​ts/technology.transformer

Це по своїй суті утиліта, яка вміє при завантаженні програми динамічно замінювати пакети в class-файлах (в JAR або WAR архівах) при старті програми. Її можна налаштувати так, що вона буде здійснювати міграцію javax. * -> jakarta. *. Така утиліта спростить життя розробникам серверiв додатків, які повинні підтримувати якусь одну версію Jakarta EE. І позбавить від необхідності термінової переробки legacy проектів.

Висновки

В цілому у Enterprise Java і її шанувальників були непрості останні 4-5 років, але ребендінг в Jakarta EE, поява Eclipse Microprofile і останні зміни говорять про те, що її ще рано скидати з рахунків. В 2021-му році виходить Jakarta EE 10, де нас будуть чекати нові плюшки. Тому я сподіваюся, що темні часи для шанувальників цієї технології закінчилися, і за періодом стагнації прийде епоха enterprise Ренесансу.

👍НравитсяПонравилось4
В избранноеВ избранном0
Подписаться на тему «Java»
LinkedIn

Похожие статьи

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
• Реактивне програмування

Уже выходит из моды. Хипстеры так и не осилили вместе со скалой итд.

Spring активно це просуває, тому я б не був так упевнений.

Не взлетит.
И выходит из моды вполне справедливо. Это просто еще-одно-сложное-апи-просто-потому-что-хайпово.

Ви експерт по реактивному програмування, що так впевнені?

Ви експерт по реактивному програмування, що так впевнені?

Ссыш да. Ты кто по жизни?!

Какая разница эксперт он или не эксперт?
Правильный вопрос:
Достаточно ли сценариев использования для этого АПИ?
Я могу придумать несколько, но они довольно специфичны. Основная масса — это КРУД, где с одной стороны синхронный по своей сути РЕСТ, с другой синхронная по своей сути СУБД. Асинхронность тут пока что не необходимость, а просто хайп.
Если вы видите сценарии, то озвучьте их.

Ви за 40 років не змогли вивчити мову своєї країни, а ще збираєтеся мене вчити програмуванню?
Це по-перше. А по-друге, з такими «навичками комунікації» вам потрібно в переході сперечатися, а не на ДОУ.

Ви за 40 років не змогли вивчити мову своєї країни, а ще збираєтеся мене вчити програмуванню?

Просто лолище :)
1) Мне еще нет 40 лет.
2) Мое знание украинского языка вы оценить не можете, потому что я с вами не общался на украинском.
3) Я вас ничему не учу. Я попросил вас не переходить на личности и привести примеры ситуаций, когда реактивное АПИ имеет преимущества.
4) Какое отношение язык имеет к теме обсуждения?

А по-друге, з такими «навичками комунікації» вам потрібно в переході сперечатися, а не на ДОУ.

Что именно в данном блоке вас навело на эту мысль:

Какая разница эксперт он или не эксперт?
Правильный вопрос:
Достаточно ли сценариев использования для этого АПИ?
Я могу придумать несколько, но они довольно специфичны. Основная масса — это КРУД, где с одной стороны синхронный по своей сути РЕСТ, с другой синхронная по своей сути СУБД. Асинхронность тут пока что не необходимость, а просто хайп.
Если вы видите сценарии, то озвучьте их.

Или вы просто не способны оценить сарказм в фразе «Ссыш да. Ты кто по жизни?!»,
который долже был бы вас подтолкнуть к мысли о том что переход на личности не уместен в данной ветке?

жду когда за джавой ЕЕ будет закинута и простая джвва. Это ж нада умудриться скопировать древний типизированный С (С наврено скоро 50 лет будет), расширить его ХМЛ, придумать к нему жсп, настроить вокруг этой хрени кучу уровней абстракций и продолжать использовать его для вебсайтов в то время как существуют нетипизированные языки типа питона и пхп. Я понимаю что привыкается писать все время войд, инт и какой то линкед-лист, но это же все уже было 50 лет назад и все делают вид что это и есть высочайшие стандарты для имплементации алгоримов. А время билда 10 минут на машине с 16 процами, что бы добавить еще одну валидацию формы ? Толи дело на питоне писать fib = lambda n: n if n < 2 else fib(n-1) + fib(n-2)

Нє, джава зробила багато користі — із-за неї попер попит на ультравайд монітори. Кожен тру ява програміст ставить собі два ультравайди: один вертикально для стек трейсів, другий горизонтально для імен класів.

Толи дело на питоне писать fib = lambda n: n if n < 2 else fib(n-1) + fib(n-2)

не треба так ніде писати :)

А время билда 10 минут на машине с 16 процами, что бы добавить еще одну валидацию формы

А що у вас за система збирання? Якщо Maven, то зрозуміло, якщо Gradle (з включеним build cache), то збірка буде не більше 10 секунд.

жду когда за джавой ЕЕ будет закинута и простая джвва

Не думаю, що Java кинуть протягом найближчих 10 років. Тільки уявіть, скільки бібліотек і фреймворків, утиліт і серверів на ній написано. Щоб їх переписати на щось інше (до речі що?) І 100 років не вистачить.

согласен, на ближайшие 10 лет альтернатив не видно. Надеюсь лет через 15 девы начнут таки смеятся с кодеров которые пишут SuperLongLinkedList superLongLinkedList = new SuperLongLinkedList(SUPER_LONG_INT);

навпаки, деви радять (і будуть завжди) використовувати German Naming Convertion всюди,
навіть там де типи повністю виводяться, у статті приклади haskell.

Java 10 ввела var
а якщо у когось виходить

var visitorMonitorInterface = new VisitorMonitorInterface(indoorSessionInitialiser);
а не
var peephole = new Peephole(door);
приклад з «Object? You keep using that word» © Kevlin Henney
то це проблеми всій команді.

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

Коан про Безпеку Статичної Типізації

Послідовник іншої секти запросив Марка Мотля на пляж. Доки віз, розказував Марку «Я більш продуктивний із Динамічною Типізацією! Я можу писати швидше як не треба хвилюватись через скарги компілятора про типи». До пляжу було довго, тому послідовник Динамічної Типізації вирішив заїхати на заправку. Він пішов на станцію заплатити за бензин та прикупити щось посёрбати, а Марк залишився заправити авто. Марк помітив, що бензо-шланг зайнятий, тож давай заливати з дизельного. Динаміст закричав «Гей! Що ж ти, паскудо, твориш — Це ж бензиновий двигун!» Марк спокійно відповідає «Ну, я просто хотів пошвидше на пляж».

так я так и сказал — в девы пришло дохрена людей которые после работы будут заливать дизель в бензиновые моторы если им на заправке сделать одинаковой ширины пистолеты.

В питоне не было ни вар ни типов, и жаваскрипте их не было.

Так и софта на питоне/жаваскрипте тоже не было.
А как только фронт-енд выделился в отдельное направление — так сразу отсутствие типов дало о себе знать и появились typescript / flow / reason / purescript / elm / fable / etc.

Совсем не обязательно использовать java (как язык), чтобы пользоваться всем, что написано для jvm.

А є тут розробники, які використовують legacy Java EE (7 або 8). Які у вас плани? Залишитися з тим що є? Перейти на Jakarta EE? Перейти на Microprofile?

перейти на Jakarta EE 9.
на Jakarta EE 8 уже (хоча й досі є частини з Java EE 5),
бо це те ж API що й Java EE 8.
на MicroProfile не переходять, його додають -
ці API пишуть ті ж люди (буквально), що й Jakarta EE.
тож і ми потрошку MicroProfile досипаємо.

щоби не заводити нових ниток, згадаю заодно за Jakarta EE 9 + MicroProfile.

одне лихо — Microprofile 4.0 (і все його реалізації) все ще використовує Jakarta EE 8

MicroProfile навмисне ж робили окремим і він не перетинається по namespace.
CDI це відповідальність контейнера, тож microprofile має бути по цимбалах.
то в чому проблеми лізуть?
з голови, це лише rest-client має використати ті ж анотації що й JAX-RS, а вони переїдуть.
проте їх продублювати замість поімпортити не проблема — так і задумані.

WildFly 22 реалізує вже й Jakarta EE 9 як Preview.
і у них є збочення цікаве технічне рішення:

Any libraries that were using EE 8 APIs were detected and instructions were incorporated in the feature pack telling Galleon to do byte code transformation of that library whenever it provisions a server using the feature pack.
A WildFly Preview server, when it reads in deployment content to store in the content repository, will transform any EE 8 content into EE 9.

звісно, можливо для цієї збірки (вона ж окрема) вирізали microprofile-platform layer,
проте у них і так microprofile спеки випускалися окремими накочуваними galeon-layers,
як останні два — згадиний у статті реактивний, та graphQL.

А, ну в общем Oracle по факту прибил Java EE
Потому, что без обратной совместимости оно никому не нужно

Oracle c 2017 року по суті не займається Java EE, навіть підтримкою. З 2019 року цей проект розвивається силами community як Jakarta EE. Тобто Java EE і не померла, але вона як би переродилася.

Тому я сподіваюся, що темні часи для шанувальників цієї технології закінчилися, і за періодом стагнації прийде епоха enterprise Ренесансу.

Если че, то джакарта 9 — это уже результат ренесанса.
Проблема в том что в современном мире есть более эффективные способы решать ментейнабилити и модифиабилити, чем формальные индустриальные стандарты, стандартов уровня энтерпрайза вполне достаточно.
А поскольку спринг-стек более развит, то джаваее остается для «фанбоев» (как бы смешно это не звучало)

На жаль, але будувати прогнози в ІТ більше, ніж на рік — заняття невдячне) Є люди, яким не подобається монополія Spring, і якi хочуть розвивати його альтернативи — той же Jakarta EE.

• Реактивне програмування
• Мікросервісная архітектура

А зачем штраждать ?
Радоваться надо, что современный говнокод ещё до вас не добрался.

Да, лет 15 назад софт работал лучше, никаких тебе багов, вылетов и зависаний=)

Да, пацаны на дельфях клипали по 10 формочек к обеду. Комитили без гитов бранчей и пулл реквестов. Деплоили без всяких девопсов за пять минут. А потом ещё денёк баги фиксили. Но не долго, все дебажилось в одном окошке.
А сейчас что. Тима одну форму пилит два спринта, ещё один спринт пулл реквест комитят. Ещё два спринта баги ловят.

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

Логично, когда на предприятии всего один компутер, то можно просто скомпилить в папку на которую ссылается ярлык на рабочем столе.

Комитили без гитов бранчей и пулл реквестов.

Что за «комитили», кому это хипсторство вообще нужно? Пацаны «на дельфях клипали по 10 формочек к обеду» просто шарили сетевую папку куда каждый будет копировал изменённые файлы.

Так тоже бывало, но более грамотные пацаны даже в те времена использовали какой-нибудь StarTeam или, прости Господи, Visual SourceSafe

никаких тебе багов, вылетов и зависаний

красный крест в делфи таки был

До речі да. Мене давно це напрягає, бо я починаю замічати, що мені часто здається, що «раніше було простіше». А вголос сказати трохи сцикотно, бо засміють, що я старий пердун.

1. В Дельфі програми білдились фактично моментально
2. В Дельфі був афігенний вбудовний дебагер. Та що там Дельфі, в Турбо Паскалі 5.5, який 1989 року, був вбудований дебагер і суб-0.5сек білд час
3. В Дельфі збілджені віконні програми займали 350кб, що здавалось дико багато. А тепер консольний hello world на Го займає 2мб
4. Реально можна було за 15хв наклікати готову форму. Зараз щось схоже є? WinForms наче терпимий, але всерівно виглядає як крок назад в порівнянні з Дельфі... В мікрософта був MFC, який просто повним п****цом був. А про java swing/awt краще взагалі не говорити.

Ну *** з ним, а сучасна веб-розробка нікого не смущає? Як раніше деплоїли сайти? Є ftp, на який закачували .php файлик + ресурси і все працювало. Як до бази даних конектились? Тобі хостер давав доступ до БД і все. Фреймворки? Були, але можна було просто самому сторінку виводити. Локально розробляти? Був www.denwer.ru.

А зараз як? Ну вирішив написати сайт на пітоні. Кажуть треба взяти якийсь фреймворк. Що там норм? Джанго. Пішов по туторіалу docs.djangoproject.com/en/3.1/intro/tutorial01 і о***в — там реально сторінок 50. Ну фіг з ним. Хтось каже, що Flask нічо так. Глянув — норм, можна юзати, але знову морока з деплоєм (gunicorn? uwsgi?).

Ну тобто реально деякі речі раніше були краще.

Як раніше деплоїли сайти? Є ftp, на який закачували .php файлик + ресурси і все працювало. Як до бази даних конектились? Тобі хостер давав доступ до БД і все.

Зараз так теж можна робити і, можливо, в деяких українських «IT-притонах» все ще так і роблять.

Ну і якщо заміть Django взяти WordPress то буде не так вже складно.

І це все ще найшвидший спосіб. Звичайно порти на зовні ніхто не виставляє, є тунелі, якщо треба з базою напряму поспілкуватися, а в іншому — все ще працюють над локальними копіями, можливо підключивши систему контролю версій.

Але ж не в ентерпрайзі.

1. В Дельфі програми білдились фактично моментально

То у вас программки были маленькие

2. В Дельфі був афігенний вбудовний дебагер. Та що там Дельфі, в Турбо Паскалі 5.5, який 1989 року, був вбудований дебагер і суб-0.5сек білд час

Ага-ага, что там с дебагом рекурсии? ;)

4. Реально можна було за 15хв наклікати готову форму. Зараз щось схоже є? WinForms наче терпимий, але всерівно виглядає як крок назад в порівнянні з Дельфі... В мікрософта був MFC, який просто повним п****цом був. А про java swing/awt краще взагалі не говорити.

Qt

А зараз як? Ну вирішив написати сайт на пітоні. Кажуть треба взяти якийсь фреймворк. Що там норм? Джанго. Пішов по туторіалу docs.djangoproject.com/en/3.1/intro/tutorial01 і о***в — там реально сторінок 50. Ну фіг з ним. Хтось каже, що Flask нічо так. Глянув — норм, можна юзати, але знову морока з деплоєм (gunicorn? uwsgi?).

Толсто

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

а чем питон выиграл у пхп для написания сайта ?

Тим, що Python це не PHP. Якщо чесно, то я вже краще на C++ писатиму ніж на PHP... Мені от реально було б стидно сказати, що, скажем, в 2021 я для свого стартапу вибрав PHP. Про недоліки PHP як мови програмування дуже гарно і з гумором описано тут: eev.ee/...​-a-fractal-of-bad-design

І тим не менше, PHP, і все навколо нього, афігенно заточено під те, щоб швидко і без гемору зробити сайт. В цьому сенсі PHP реально виграє у Пітона. Тобто якби у мене не було відрази до самої мови (це мої особисті зайоби — не звертай уваги), то я б реально радив народу брати PHP для написання сайтів, а не Python.

старый добрый пхп позволяет писать сайт в перемешку с хтмл и джава скриптами прямо в блокноте и сразу на денвере все смотреть, а потом скопировать файлик на сервер.

І це ахуєнно. Я на повному серйозі. Цього просто п****ц як не вистачає, коли просто хочеш наговнякати прототип. Я не знаю де ще можна так же легко створити і задеплоїти сайт як з PHP. Поріг входу практично нульови. Цього п****ц як не вистачає ... всім іншим мовам/фреймворкам.

Сходу, думаю що тільки фронт-енд розробка і SPA наближаються до інтуітивності. Але навіть там є гемор з вебпаком, мініфікацією, sass/scss і всім цим говном. ЪУЪ СЪУКА.

дуже гарно і з гумором описано тут: eev.ee/...​-a-fractal-of-bad-design

Можна було вже копнути статтю ше на років 5 старіше, і розкопати взагалі про 4тий PHP ;)

Про недоліки PHP як мови програмування дуже гарно і з гумором описано

більша частина цієї відомої статті — вже неактуальна, пофіксали.

вона приблизно як Javу 1.2 критикує.

за останні PHP та його екосистема — дуже змінилися.
причому — з збереженням сумісності, так що як хочется/можеться, або погані звички — то можна і як на PHP 4 писати — пара скриптів де все — і php і html і sql

в 2021 я для свого стартапу вибрав PHP.

обирають, і ще й як. Laravel зазвичай в основі.
для відразу ентерпрайзного — Symfony.

І тим не менше, PHP, і все навколо нього, афігенно заточено під те, щоб швидко і без гемору зробити сайт

і просто бекенд, з API для SPA та мобайл клієнтів.
майже як на Джаві пишеш — писав, можу порівнювати. тільки з купою можливостей, що немає в джаві.
звісно, за це тра платити — швидкодією.

але пітон ще більш тормознутий ніж php. і кого це на старті хвилює?
потім все одно почнеться переписуватится на Go або Node.js, або взагалі на Java/C#
або проект не вистрелить :)

Цього просто п****ц як не вистачає, коли просто хочеш наговнякати прототип

отож!
тільки php не вимагає етапу compile/build та рестарту аплікації на сервері

майже як на Джаві пишеш

еее ... це звучить як анти-комплімент :)

тільки php не вимагає етапу compile/build та рестарту аплікації на сервері

Ну це не сильно унікальна фішка php. Той же Flask з коробки йде з hot reload’інгом: flask.palletsprojects.com/...​.x/quickstart/#debug-mode

В пітоні просто своя гора проблем з веб розробкою — як деплоїти-то? Тупо весь .py код закидувати на сервер? «as-is» дплоїти чи пакувати в wheel? Чи прямо з репозітарію пулити? А як gracefully reload? З php все ясно було — да, деплоїти весь код — саме так і задумано. gracefully reload тривіалний і за тебе його зробить сам апач.

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

А хто в контейнері буде запускати сам пітонівський сервіс? Ну тобто поверх своєї апки ще треба якийсь Gunicorn. І, знову ж таки, як зробити graceful reload? Тобто дати час допрацювати існуючим конекшенам, а нові запити вже відкривати новим сервісом.

Порівняй це з php’шним «закачай по фтп ось сюди файли». І там за замовчуванням все розподілене :). І тривіально масштабується що вверх що вширь.

1. В Дельфі програми білдились фактично моментально

Ерунда. Во первых не моментально. Во вторых «моментально» если три формы со стандартными компонентами, да пяток классов, под одну таргет платформу, без тестов, СИ\СД, итд. Если на джаве хелло ворлд скомпилить (даже с УИ с древним свингом), он тоже быстро сконпилиццо.

2. В Дельфі був афігенний вбудовний дебагер.

В джаве с интелледж — дебагер лучче. Возможностей на порядок боьше.

3. В Дельфі збілджені віконні програми займали 350кб

Это в 5-й версии, и с дефолтными компонентами. Как конпонентов добавляеш — экзешник дико растет.
Хотя да современная мода тянуть все и везде с мемами про зависимости ноды.жс — печаль.

4. Реально можна було за 15хв наклікати готову форму.

Вот шо да то да. Но щас надобности в оконных програмах под одну платформу кагбы и нет.

А зараз як? Ну вирішив написати сайт на пітоні. Кажуть треба взяти якийсь фреймворк. Що там норм? Джанго. Пішов по туторіалу docs.djangoproject.com/en/3.1/intro/tutorial01 і о***в — там реально сторінок 50. Ну фіг з ним. Хтось каже, що Flask нічо так. Глянув — норм, можна юзати, але знову морока з деплоєм (gunicorn? uwsgi?).
Ну тобто реально деякі речі раніше були краще.

Ну просто если раньше ты накидал формочку для какогонить бух учета — то ты уже неподецки Программист! То щас вдруг выясняеццо что на глобальном рынке это никому не надо. 1С-ники еще живы, но шото не огонь.

Для контексту — я говорю про світ Дельфі десь ~2004-2005 року.

Білдилось таки моментально. Просто в Дельфі/Паскалі з самого початку була концепція модулів, тобто он ті всі interface/implementation, завдяки чому можна було не перекомпілювати все, а тільки потрбіний модуль. Звісно, якщо чіпаєш якусь глибоку залежність, від якої всі інші модулі залежать, то дійсно прийдеться перезбирати все. А от в C/C++ досі немає модулів і, теоретично, любий дурак може зробити #define private public, тому компілятору треба афігеть як ізвращатись, щоб НЕ перекомпільовувати/парсити ВСЕ. Java теж феноменально швидко компілиться, але я саме про javac а не всі надбудови над ним (ant/mvn/gradle).

А от лінкування в Дельфі реально було відносно повільним і було гірше оптимізоване. Власне так буде завжди — навіть якщо ти посунув кнопку вправо на 1 піксель, то лінкеру все так же треба буде видати новий екзешник на N кілобайт, які треба вивести байт за байтом.

Але знову ж таки, на старому залізі (~2005 рік) білд (compile/link) займав треть секунди. Зараз повно гівна, яке на сучасних комп’ютерах білдиться десятки секунд.

под одну таргет платформу

Давай чесно — тоді існувала тільки 1 таргет платформа. Ми, звісно, грались з лінуксом і навіть QNX, але це були виключно ігри. Але навіть тоді був Kylix, який обіцяв можливість компілювати дельфійські проекти під віндовс. Мені там навіть його вдалось запустити пару раз.

без тестов, СИ\СД

Ми про таке навіть не знали тоді :). Але давай серйозно — майже все це можна було додати. А для повсякденної роботи важлива можливість ШВИДКО внести невелику модифікацією і ШВИДКО її ж вручну затестити. Тут дельфі був королем.

Я колись побачив був як Нотч писав гру і на льоту її ж міняв: youtu.be/g42pTHEW-tE?t=100 — не певен що це саме то відео, але там кльово що можна міняти апку прямо на льоту і навіть не треба перезапускати її. Оце реально дуже-дуже круто. Я такого більше ніде не бачив. Теоретично в ємаксі з elisp’ом це щось схоже, багато де є lua скриптинг, в пітоні (можливо) можна було б щось схоже провернути...

В джаве с интелледж — дебагер лучче.

В 2004 дійсно був кращим? Слабо віриться, бо в 2004 IDEA було 3 роки, а в дельфі багато років і за ним стояв крупний (на той час) Борланд.

Возможностей на порядок боьше.

Яких наприклад? Не тролю, якщо що.

3. В Дельфі збілджені віконні програми займали 350кб

Это в 5-й версии, и с дефолтными компонентами. Как конпонентов добавляеш — экзешник дико растет.

Останньою Дельфі, якою я користувався, була Дельфі 7. Це було десь в 2004-2005 і там реально було 350кб. Розмір ріс, але не дуже критично, імхо. Але знову ж таки, це було 15+ років назад — може я щось неправильно пам’ятаю.

Но щас надобности в оконных програмах под одну платформу кагбы и нет.

Та як сказати. Інтернет (bandwidth, latency) став сильно краще, тому всі знову повернулись до ідеї тонких клієнтів (браузер). Але насправді у всіх нас є дофіга постійно відкритих вкладок, які запросто могли б бути окремими native програмками. Власне на телефонах же так і є — там на всіх платформах нативний GMail, Telegram, FB, Slack, ... і нічо :). Релізити не настільки зручно, але, твою мать, заєбало, що web.telegram.org тормознутий — я ж не аеродинаміку якусь обчислюю, а пишу срані короткі повідомлення і деколи (дуже рідко) вставляю dick pic, йопт.

В 2004-2006 був stand alone native Google Talk, який був ахуітєльним. От реально був бомбезним — важив десь мегабайт, був шустрим, дозволяв підключати собі в чат чуваків не тільки з GMail’у, а ще й з інших jabber серверів. Він був закінченим — його досить було залишити як є і не чіпати. Нафіга його закрили?! Ну фіг з ним, ще був pidgin, який теж працював дуже ок. Для групових чатів був IRC і mIRC був дуже ОК. За 15 років ми перенесли все спілкування на чужі сервери, навчились легше шарити дік піки, створювати опитування і додали можливість ставити :partyparrot:’а під постами. Заєбісь прогрес.

Не пойми неправильно — Дельфі вже морально застаріла: немає дженериків, колекцій, рефлексії, ... і зараз виглядає дуже бідно. Але, блять, там реально багато речей було зроблено правильно.

Ну просто если раньше ты накидал формочку для какогонить бух учета — то ты уже неподецки Программист!

Так а чому сарказм-то? Ти швидко вирішив проблему реальних замовників (бухгалтерів) і реально покращив їм життя. Це ж, бля, квінессенція програмування і стартаперства. Ну да, на той час не існувало такого глобального ринку і тому замовлення були, в основному, з місцевого ринку (з витікающими з цього проблемами — низькі зарплати, мало роботи, ...). Так саме із-за низьких зарплат багато компаній і мали можливість наймати програмістів на допомогу бухгалетрам, а тепер це настільки дорого, що сильно дешевше купити готове рішення ніж тримати в штаті програміста на побігушках у бухгалтерів. Я, звісно, став бенефіціаром цього тренду, але не думаю, що для бухгалтерів стало сильно краще.

Ти смієшся, але десь в 2003 я написав маленьку програмку для того, щоб мій тато міг легше робити платіжки. Один 400кб бінарь, один файл з базою. Так ето ... тато цією програмою користувався роками — взагалі 0 проблем з серверами, 0 девопсів, 0 підтримки. Згоден, що це не повнофункціональна прога для ведення бухгалтерії, але йопт — свою роботу ця прога виконала на відмінно і зекономила моєму батькові сумарно (за 8+ років) сотні годин часу і, наскільки мені відомо, з нею було 0 (нуль) проблем за всі ці роки — it just fucking works.

Зараз же реально одну формочку роблять 1 девопс, 2 інженера (фронт і бек), 3 PM’а впродовж 4х спринтів. А ще у кожного з них по особистому психотерапевту і ще декілька спільних командних психотерапевтів. І ще народ постійно хоче на якусь конференцію змотатись. Єбать прогрес. Зато CI/CD. Тільки бідний бух в ахуї сидить і 2 тижня чекає «суму прописью».

В 2004 дійсно був кращим? Слабо віриться, бо в 2004 IDEA було 3 роки, а в дельфі багато років і за ним стояв крупний (на той час) Борланд.

Речь о текущей версии. В контексте «раньше было легше — проще».

Зараз же реально одну формочку роблять 1 девопс, 2 інженера (фронт і бек), 3 PM’а впродовж 4х спринтів.

Эт потому что условный «папа» сейчас не жалет какуюто стенд-элоун прогу на компе, он желает чтобы все было в клауде и доступно со всех девайсов.

В 2004 дійсно був кращим? Слабо віриться, бо в 2004 IDEA було 3 роки, а в дельфі багато років і за ним стояв крупний (на той час) Борланд.

Речь о текущей версии. В контексте «раньше было легше — проще».

Так про які саме революційні фічі дебагера йдеться-то?

желает чтобы все было в клауде и доступно со всех девайсов.

А точно бажає? Просто виглядає так, наче ми самі себе переконали в тому, що клієнту позаріз потрібно саме XYZ. А потім при спілкуванні з заказчиком переконали його в тому, що зараз інакше не робиться.
— ви хочете, щоб було модно-стильно-молодіжно в клауді, і щоб можна було створювати платіжні доручення сидячи на толчку?
— ... тепер вже хочу. Я тепер взагалі не уявляю як я міг до цього жити без того, щоб з голою жопою редактувати коди ЕДРПОУ сидячи на толчку.

Просто мені здається, що ми (програмісти) самі собі напридумували задач, загнали себе ж в невигідне становище і тепер розводимо руками — ну а що, «клієнт-то хоче клауд, CI/CD, ...». Хоча якби клієнт знав, що без магічного слова «клауд» його задачу зміг би рішити 1 (один) шістнадцятилітній піздюк за вихідні, то може він би і погодився б на «по старинці».

Ну так за делфи формочку заказчик заплатит сто грн. А за клауд модна чарджить много тысяч. Придумали не кодеры, а какраз продажники)

Аргументи якось скотились з «зараз стало краще» в «стало гірше, зате клієнтів чарджим втридорога».

оно во многом так и есть на самом деле...

Все верно. У меня вообще есть подозрения, что любой сложный продукт можно написать только по старинке. Вотерфолл и костяк кей разработчиков которые просто херачат код минуя все новомодные процессы. Я смотрю на туже игру GTA 5 и офигеваю от объема работ и продуманности движка. Настолько сложный продукт просто невозможно написать с спринтами скрамами и вот этим вот всем. В скрамах еле круд с вебом шевелятся.

Без поняття про GTA 5 — ніколи не грав, але тепер цікаво стало. Движок десь можна глянути? Якщо цікаво, то заціни Факторіо — от там взагалі на голову не налазить як все спроектувати. Тільки обережно — Факторіо афігітєльно затягує.

GTA 5 самая дорогая игра в истории.
Отличается огромным детализированным открытым миром воссозданным в деталях — город Лос Анжелес (Лос Сантос). Это огромный симулятор, подводного, надводного, наземного, подземного, воздушного мира. В нем есть все, от стрип клубов до разборок гангстеров. Сама игра является симулятором для ещё кучи игр внутри. В игре используется сотни единиц разного вида транспорта, от велосипедов до пассажирских самолётов. Всем можно управлять, все реалистично бьётся. Там есть свой интернет, свои военные, свои бомжи, свои парки аттракционов, свои затерянные деревни нудистов, аэропорты, заводы, военные базы, метро, виллы, магазины, свой голивуд. Всего не перечислить.
Чего нет, нет Jakarta EE9. Как появится выход следующей версии игры будут ждать ещё 0xEE9 лет.

Это огромный симулятор,

не эт не симулятор в традиционном смиысле того слова. Но контента оч много да. Еще Ред дед редемпшон 2 оч рекомендуют.

Хоча якби клієнт знав, що без магічного слова «клауд» його задачу зміг би рішити 1 (один) шістнадцятилітній піздюк за вихідні, то може він би і погодився б
на «по старинці»

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

Просто мені здається, що ми (програмісти) самі собі напридумували задач, загнали себе ж в невигідне становище і тепер розводимо руками — ну а що, «клієнт-то хоче клауд, CI/CD, ...».

да, клиент — это такая дойная корова, которой нужно постоянно продавать, что ее нужно еще вот так подоить, и нужно бы для дойки купить автоматизированное ведро с позолотой и еще пару реплик для устойчивости.
При этом неважно, это продается айти компанией конечному клиенту, или аутсорсом своему заказчику — айти компании.

Эт потому что условный «папа» сейчас не жалет какуюто стенд-элоун прогу на компе, он желает чтобы все было в клауде и доступно со всех
девайсов.

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

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

Я думаю что для этого задумывалась пропаганда микросервисов лет 5-7 назад от Амазона.
Потому что когда пишешь микросервисы возникает куча проблем, которые без клауда решать очень проблематично — все эти оркестраторы, лоад балансеры и все остальное. То есть если подсел на микросервисы то 99% подсядешь на клауд.

Ну просто если раньше ты накидал формочку для какогонить бух учета — то ты уже неподецки Программист!

Где-то меряли производительность в строчках кода, в Делфи меряли в формах.

Ти так кажеш, наче це щось погане. Це ж реально афігенно усвідомлювати, що програма з 50 вікон може бути написана за X днів.

Та просто из подслушанного

Ну просто если раньше ты накидал формочку для какогонить бух учета — то ты уже неподецки Программист

Я все життя вважав, що еволюція програмування — це скорочення часу і зусиль, які програміст має витрачати на «одну формочку». Ну, від перфокарт, до асемблеру, до мов високого рівня, іде, raid. І Delphi безумовно була вершиною. А потім щось пішло не так. І сон розуму породжує ангуляр, нмп, гульп і програмістів гітхаба і джири.

Ну зато и зарплата у тебя 5к, и работы завал на много лет вперед. А так платилб 5к грн и пойди ту работу еще найди.

Так і є. Та взяти той же CI — в TeamCity наклацав і готово. А зараз бачив сам, як кілька місяців клепали github workflow, actions, а мікросервіси ж, треба з незкінченно копіпастити їх. Взагалі додуматись зберігати скрипти білд машини з кодом, бо більше нема де.

Реально можна було за 15хв наклікати готову форму. Зараз щось схоже є? WinForms наче терпимий, але всерівно виглядає як крок назад в порівнянні з Дельфі... В мікрософта був MFC, який просто повним п****цом був. А про java swing/awt краще взагалі не говорити.

Да, помню был такой опыт где-то на 1 или 2 курсе универа. Сначала с MFC — промучались полдня с товарищем, чтобы разобраться как сделать, чтобы в формочке по нажатию кнопки писался текст в поле. А потом через время была лаба на Делфи — сделать копию блокнота. Я ее наклепал за пару часов, хотя делфи впервые в глаза видел. Помню называл это «программирование мышкой».

а сучасна веб-розробка нікого не смущає? Як раніше деплоїли сайти? Є ftp, на який закачували .php файлик + ресурси і все працювало

потому что раньше разрабатывали html-странички, а теперь дестоп приложения для веба делают. Раньше разработка интернет-магазина это был проект для аутсорса на полгода и 3 программистов, а теперь визард проклацал мышкой и у тебя инет-магазин.

MFC це окремий сорт гімна.

Подписаться на комментарии