Там еще на картинке нарисована Akka. Как человек, однажды пробовавший юзать ее джава-апи, рассматриваю это не иначе как пасхалку от скучающего копирайтера, у которого нейросети отняли всю работу.
Интересно, есть ли какая-нибудь статистика по использованию GraalVM и AoT на реальных проектах? Я всегда думал, что это маргинальные технологии, потому что те, кто гонится за быстрым временем старта, просто не будут выбирать джаву изначально.
Еще одна проблема с их подходом к геймификации в том, что вопросы, на которые можно ответить "из головы", уже по большей части исчерпаны, большинство новых неотвеченных вопросов довольно узкоспециальные. Их можно условно разделить на 2 категории: "новичок не туда поставил скобку" и "уровень курсовой работы, а иногда и кандидатской".
Выходит, что тот, кто 15 лет назад красиво ответил на вопрос "как написать цикл в питоне" сейчас сидит с шестизначным рейтингом. А тебе для ответа на вопрос про хитрый корнер кейс в каком-нибудь редком фреймворке надо потратить несколько часов на ресерч (который автор поленился провести), написать красивый и понятный ответ. Причем автор вопроса получит за это зарплату и съэкономленное время. А ты - потраченное время, и может быть немного рейтинга. Почему "может быть"? Потому что авторы вопросов (особенно, если им несколько дней) далеко не всегда берут на себя труд отметить твой ответ как правильный. Вы можете спросить "а как же чувство глубокого удовлетворения, причастности к сообществу и т.п." - здесь я говорю именно про слабые места геймификации и системы рейтинга.
Именно поэтому лично я отвечаю только на те вопросы, которые я сам искал, и в итоге пришел к решению лучше, чем уже есть в ответах.
Вот кстати да. EJB ведь тоже шел путем добавления абстракций и приводил к кратному увеличению сложности системы. Где сейчас EJB?
И да, я не пытался сказать, что сейчас хуже. Я пытался сказать, что в целом позитивный движ как будто свернул немного не туда. Надеюсь, на следующем витке прогресса народ додумается как получить те же преимущества, но без этой сложности.
А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом. Да, это было не круто. Но этому можно было за час на пальцах научить любого джуна, и дальше они вполне справлялись с поддержкой.
Современные подходы к инфраструктуре, типа service mesh, пошли по пути добавления новых и новых слоев абстракции. Теперь у вас три экземпляра приложения, каждое в своем поде, каждое - за своим прокси, гейтвей, лоад балансер, собиралка логов, собиралка метрик, физическая машина, на которой это в конечном счете крутится (часто, все так же одна единственная, ведь "мы же не гугл"). И у каждого компонента естественно есть свои логи, свои метрики, своя конфигурация при деплое. Каждый компонент - потенциальная точка отказа. Теперь, для того, чтобы с этим всем справится, нужен отдельный специалист. Джун-программист не просто не сможет выполнять такую работу, он скорее всего даже не сможет коммуницировать с таким специалистов в рамках своих задач. Стало ли как-то лучше глобально? Для супер большиъ проектов - наверное да. Остальные и 10 лет назад, и 20 лет назад тоже как-то работали, вполне нормально. Что точно изменилось - современные практики DevOps создали огромное количество рабочих мест собственно для девопсов. Не вижу в этом ничего плохого.
Люди используют Windows не потому, что они провели объективное сравнение технологий и сделали рациональный выбор. Они используют Windows, потому что первый компьютер, который они увидели дома/в школе/в университете был на Windows, потому что у всех их знакомых тоже стоит Windows. Большинство в принципе не задается вопросом Windows vs Linux, потому что этот вопрос не имеет для них смысла.
И эта данность обусловлена событиями 40-летней давности, когда MS-DOS подмял под себя рынок 86-процессоров, а потом ранние версии Windows выиграли конкуренцию у Macintosh. Linux в 90-х, особенно UI-часть, был достаточно сырой поделкой энтузиастов. Как он должен был обойти к тому времени уже корпорацию-монополиста на рынке десктопов не очень понятно. А дальше, по-видимому, как я написал выше, популярность Windows сохранялась за счет инерции, "эффекта утенка".
Что интересно, на рынке серверов Linux довольно легко обошел Windows. Видимо, дело в том, что серверы использует бизнес, поэтому там априори больше профессионализма и рационализма при принятии решений по сравнению с рынком ширпотреба.
"Архитектура" в контесте прикладной бекенд-разработки отвечает на вопросы примерно такого рода:
на какие модули/сервисы/микросервисы разбить систему?
по каким протоколам они будут взаимодействовать (синхронные, асинхронные)?
какое хранилище данных выбрать (реляционное, нереляционное, несколько разных)?
что и где надо кешировать?
и т.п.
Архитектура очень важна, она определяет ключевые характеристики системы. Но она имеет мало отношения к ООП. Да, в готовой архитектуре можно найти вещи, напоминающие паттерны GoF, принципы SOLID или GRASP. Но сами по себе они не приведут вас к готовой архитектуре с нуля. Гораздо лучше работает банальный опыт и знание best practices.
Организация конкретных классов и методов обычно называется словом "дизайн". В контесте прикладной бекенд-разработки дизайн как правило диктуется фреймворками, которые вы используете. Причем чем больше ваша свобода ограничена фреймворками и практиками, принятыми на проекте, тем легче вашим коллегам разбираться в вашем коде, а вам - в их коде. На типовом Java-стеке Spring/Hibernate (который вы упомянули) можно успешно написать десятки проектов и ни разу не потренироваться в "ООП-мышлении" - все было продумано до нас.
Казалось бы можно попробовать применить все эти чудесные методологии при проектировании структуры базы. Но нет, там тоже есть довольно строгие подходы: нормальные формы, денормализация. За любые отклонения от верного пути база больно бьет по рукам потерей консистентности или производительности.
Это было про типовую бекенд-разработку. Если вы вдруг пишете свой фреймворк или библиотеку, тут другая история. Если это хоть немного нетривиально, вы не сможете задизайнить его правильно с первого раза, прочитай вы хоть все книги мира. Только многолетняя полировка на всевозможных сценариях использования приведет вас к пониманию, как это надо было делать изначально.
Спасибо за статью! Хотелось бы еще добавить, что с первой характеристикой функционального программирования в вашем списке, а именно с иммутабельностью данных, в джаве все весьма так себе. Особенно в стандартной библиотеке.
Обычно, когда видишь такие статьи, машинально прокручиваешь до комментариев в надежде, что вот там-то умные люди напихают полную панамку автору, который даже в терминологии не разобрался.
И что там? Половина комментаторов вслед за ним называет процедурное программирование функциональным. Вторая - комментирует так, как будто его статья реально про ФП ("математический стиль" в альтернативно-одаренной терминологии автора).
Спасибо вам за этот комментарий! Я до него доскроллил, и моя вера в здешнюю публику не умерла окончательно.
Интересно было бы посмотреть на другие метрики, типа количества уникальных юзеров в месяц, количество оценок вопросов и ответов и т.п. Показывают ли они такой же тренд?
По тем же причинам Java может стать привлекательным выбором и для исследовательского программирования, но инструментарий для этого ещё не совсем готов.
Хорстманну надо бы почитать про scala-cli: вот удивится, наверное.
Это грубейшая ошибка, которая говорит о том, что вы не понимаете, как правильно использовать Java Time API, и даже не читали официальную документацию. А в ней вполне конкретно написано: "LocalDateTime is a description of the date, as used for birthdays, combined with the local time as seen on a wall clock. It cannot represent an instant on the time-line without additional information such as an offset or time-zone."
В вашем случае должно быть:
private ZonedDateTime createdAt;
Но тогда большая часть страданий и "полезных советов" из статьи становится неактуальной.
Боюсь, все далеко не так просто и однозначно, как вы описали.
Во-первых, на момент разработки logback-appender'а нормальных внешних тулов для отправки Java-логов в Loki просто не было. Promtail и fluent-bit максимально криво парсили стандартный текстовый формат, особенно плохо было со стек-трейсами и записями, задержищими перевод строки. Давно не смотрел, что там с promtail, но у fluent-bit проблема сохраняется до сих пор.
Во-вторых, зачем вообще что-то сериализовать в строку, чтобы потом парсить с потерей информации, если можно отправить напрямую точно без потерь? Это более прямолинейное решение с инженерной точки зрения.
В-третьих, STDOUT вы все равно пишите через аппендер. Почему то же самое через такой же аппендер нельзя писать в локи? В плане полноты логов там будет абсолютно то же самое. Но при этом вы будете использовать тот же знакомый всем джавистам инструмент, и бесплатно получите все его богатые возможности в преломлении к специфике Loki. Например, можно делать динамические лейблы, используя MDC.
Не скажу за все возможные аппендеры, но конкретно мой при тормозах или недоступности Loki не упадет и не будет тормозить приложение (или точнее сказать будет тормозить даже меньше, чем сторонняя тула для отправки логов, которая в любом случае ест сколько-то дополнительного CPU и RAM на ненужную сериализацию/десериализацию).
Ваш единственный аргумент сводится к тому, что при недоступности Loki логи могут потеряться. Да, могут. И это одинаково справедливо и для отправки из приложения и через стороннюю тулу. Если не хотите терять логи, просто делайте высокодоступную инфраструктуру, Loki как раз предназначен для этого.
Хочу еще раз пояснить свою позицию. Она совсем не в том, что promtail и иже с ним вообще не нужны, что не нужно слушать STDOUT контейнера и т.п. Она в том, что конкретно для Java-приложения, сложнее чем HelloWorld, есть варианты лучше, чем писать логи в STDOUT, чтобы потом их парсить и отправлять в Loki отдельной тулзой.
Линукс всегда будет зоной дискомфорта для людей, привыкших к винде. Иначе он бы просто превратился во вторую винду, которая никому не нужна, потому что уже есть первая. А линукс в текущем его виде как раз много кому нужен. Пока винда доминирует на не самом перспективном рынке десктопов, линукс доминирует на рынках, переживающих взрывной рост — интернет, смартфоны, облака.
Переводить ли десктоп с винды на линукс в надежде сохранить свой виндовый пользовательский опыт? Лучше не надо, с такими запросами вас там никто не ждет. Но делать из этого вывод, что линукс до чего-то там не дозрел или что он кому-то там не нужен, тоже не стоит.
По моим наблюдениям, все, кто хочет использовать линукс и понимают, зачем им это нужно, — просто ставят и используют. У таких людей обычно не возникает проблемы потратить несколько минут на проверку железа на совместимость до покупки ноута, или потратить те же несколько минут на поиск решения софтверной проблемы в гугле. Этих проблем у каждого конкретного человека случается не так много, и их число со временем сокращается — я на своем опыте наблюдаю этот прогресс последние 12 лет и да, многое изменилось в лучшую сторону.
Есть другой тип людей, которые думают, что сейчас они поставят линукс, и у них будет все так же как в винде, только лучше. Естественно, они не настроены тратить на что-то время и разбираться, ведь "в винде оно само работало". Зачем тогда выходить из зоны комфорта, просто продолжайте сидеть на винде. Это не линукс все еще не дозрел до вас, это вы все еще не дозрели до линукса.
Раз уж у вас тут разговор о моей карме, тоже выскажусь. Отрицательные значения кармы у меня были практически все время, и не очень напрягали. Потом я из спортивного интереса разогнал карму в плюс, но быстро понял, что в этом нет ничего интересного. Когда можешь ставить эти минусы и плюсы, чувствуешь себя каким-то вахтером, как будто на тебе теперь есть какая-то ответственность за контент, надо не просто читать, а еще и правильно расставлять стрелочки. Короче, спортивный интерес к увеличению кармы быстро пропал.
С другой стороны, когда карма меньше -10, становится реально неудобно комментировать. Вот думаю, хочу я с этим что-то делать или нет.
Ну и раз уж мы тут раскрываем карты, то
вот
Вклад в популяризацию ФП однозначно заслуживает плюса, а минусовать кого-то кроме спамеров вообще неправильно. На момент того спора, который мы обсуждаем выше, я, насколько помню, вполне еще мог голосовать.
Там еще на картинке нарисована Akka. Как человек, однажды пробовавший юзать ее джава-апи, рассматриваю это не иначе как пасхалку от скучающего копирайтера, у которого нейросети отняли всю работу.
Интересно, есть ли какая-нибудь статистика по использованию GraalVM и AoT на реальных проектах? Я всегда думал, что это маргинальные технологии, потому что те, кто гонится за быстрым временем старта, просто не будут выбирать джаву изначально.
Еще одна проблема с их подходом к геймификации в том, что вопросы, на которые можно ответить "из головы", уже по большей части исчерпаны, большинство новых неотвеченных вопросов довольно узкоспециальные. Их можно условно разделить на 2 категории: "новичок не туда поставил скобку" и "уровень курсовой работы, а иногда и кандидатской".
Выходит, что тот, кто 15 лет назад красиво ответил на вопрос "как написать цикл в питоне" сейчас сидит с шестизначным рейтингом. А тебе для ответа на вопрос про хитрый корнер кейс в каком-нибудь редком фреймворке надо потратить несколько часов на ресерч (который автор поленился провести), написать красивый и понятный ответ. Причем автор вопроса получит за это зарплату и съэкономленное время. А ты - потраченное время, и может быть немного рейтинга. Почему "может быть"? Потому что авторы вопросов (особенно, если им несколько дней) далеко не всегда берут на себя труд отметить твой ответ как правильный. Вы можете спросить "а как же чувство глубокого удовлетворения, причастности к сообществу и т.п." - здесь я говорю именно про слабые места геймификации и системы рейтинга.
Именно поэтому лично я отвечаю только на те вопросы, которые я сам искал, и в итоге пришел к решению лучше, чем уже есть в ответах.
Вот кстати да. EJB ведь тоже шел путем добавления абстракций и приводил к кратному увеличению сложности системы. Где сейчас EJB?
И да, я не пытался сказать, что сейчас хуже. Я пытался сказать, что в целом позитивный движ как будто свернул немного не туда. Надеюсь, на следующем витке прогресса народ додумается как получить те же преимущества, но без этой сложности.
А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом. Да, это было не круто. Но этому можно было за час на пальцах научить любого джуна, и дальше они вполне справлялись с поддержкой.
Современные подходы к инфраструктуре, типа service mesh, пошли по пути добавления новых и новых слоев абстракции. Теперь у вас три экземпляра приложения, каждое в своем поде, каждое - за своим прокси, гейтвей, лоад балансер, собиралка логов, собиралка метрик, физическая машина, на которой это в конечном счете крутится (часто, все так же одна единственная, ведь "мы же не гугл"). И у каждого компонента естественно есть свои логи, свои метрики, своя конфигурация при деплое. Каждый компонент - потенциальная точка отказа. Теперь, для того, чтобы с этим всем справится, нужен отдельный специалист. Джун-программист не просто не сможет выполнять такую работу, он скорее всего даже не сможет коммуницировать с таким специалистов в рамках своих задач. Стало ли как-то лучше глобально? Для супер большиъ проектов - наверное да. Остальные и 10 лет назад, и 20 лет назад тоже как-то работали, вполне нормально. Что точно изменилось - современные практики DevOps создали огромное количество рабочих мест собственно для девопсов. Не вижу в этом ничего плохого.
Пример со скайпом игнорируете. Там у вас нет даже опции "make it yourself", только "gtfo".
Так возьмите и напишите сами. Не можете? Задонатьте тому, кто может.
Вот типичный пример closed-source разработки из этой же ниши: Microsoft решили закрыть скайп. И вы ничего не можете с этим сделать.
Люди используют Windows не потому, что они провели объективное сравнение технологий и сделали рациональный выбор. Они используют Windows, потому что первый компьютер, который они увидели дома/в школе/в университете был на Windows, потому что у всех их знакомых тоже стоит Windows. Большинство в принципе не задается вопросом Windows vs Linux, потому что этот вопрос не имеет для них смысла.
И эта данность обусловлена событиями 40-летней давности, когда MS-DOS подмял под себя рынок 86-процессоров, а потом ранние версии Windows выиграли конкуренцию у Macintosh. Linux в 90-х, особенно UI-часть, был достаточно сырой поделкой энтузиастов. Как он должен был обойти к тому времени уже корпорацию-монополиста на рынке десктопов не очень понятно. А дальше, по-видимому, как я написал выше, популярность Windows сохранялась за счет инерции, "эффекта утенка".
Что интересно, на рынке серверов Linux довольно легко обошел Windows. Видимо, дело в том, что серверы использует бизнес, поэтому там априори больше профессионализма и рационализма при принятии решений по сравнению с рынком ширпотреба.
"Архитектура" в контесте прикладной бекенд-разработки отвечает на вопросы примерно такого рода:
на какие модули/сервисы/микросервисы разбить систему?
по каким протоколам они будут взаимодействовать (синхронные, асинхронные)?
какое хранилище данных выбрать (реляционное, нереляционное, несколько разных)?
что и где надо кешировать?
и т.п.
Архитектура очень важна, она определяет ключевые характеристики системы. Но она имеет мало отношения к ООП. Да, в готовой архитектуре можно найти вещи, напоминающие паттерны GoF, принципы SOLID или GRASP. Но сами по себе они не приведут вас к готовой архитектуре с нуля. Гораздо лучше работает банальный опыт и знание best practices.
Организация конкретных классов и методов обычно называется словом "дизайн". В контесте прикладной бекенд-разработки дизайн как правило диктуется фреймворками, которые вы используете. Причем чем больше ваша свобода ограничена фреймворками и практиками, принятыми на проекте, тем легче вашим коллегам разбираться в вашем коде, а вам - в их коде. На типовом Java-стеке Spring/Hibernate (который вы упомянули) можно успешно написать десятки проектов и ни разу не потренироваться в "ООП-мышлении" - все было продумано до нас.
Казалось бы можно попробовать применить все эти чудесные методологии при проектировании структуры базы. Но нет, там тоже есть довольно строгие подходы: нормальные формы, денормализация. За любые отклонения от верного пути база больно бьет по рукам потерей консистентности или производительности.
Это было про типовую бекенд-разработку. Если вы вдруг пишете свой фреймворк или библиотеку, тут другая история. Если это хоть немного нетривиально, вы не сможете задизайнить его правильно с первого раза, прочитай вы хоть все книги мира. Только многолетняя полировка на всевозможных сценариях использования приведет вас к пониманию, как это надо было делать изначально.
Спасибо за статью! Хотелось бы еще добавить, что с первой характеристикой функционального программирования в вашем списке, а именно с иммутабельностью данных, в джаве все весьма так себе. Особенно в стандартной библиотеке.
Обычно, когда видишь такие статьи, машинально прокручиваешь до комментариев в надежде, что вот там-то умные люди напихают полную панамку автору, который даже в терминологии не разобрался.
И что там? Половина комментаторов вслед за ним называет процедурное программирование функциональным. Вторая - комментирует так, как будто его статья реально про ФП ("математический стиль" в альтернативно-одаренной терминологии автора).
Спасибо вам за этот комментарий! Я до него доскроллил, и моя вера в здешнюю публику не умерла окончательно.
Интересно было бы посмотреть на другие метрики, типа количества уникальных юзеров в месяц, количество оценок вопросов и ответов и т.п. Показывают ли они такой же тренд?
Хорстманну надо бы почитать про scala-cli: вот удивится, наверное.
Это грубейшая ошибка, которая говорит о том, что вы не понимаете, как правильно использовать Java Time API, и даже не читали официальную документацию. А в ней вполне конкретно написано: "LocalDateTime is a description of the date, as used for birthdays, combined with the local time as seen on a wall clock. It cannot represent an instant on the time-line without additional information such as an offset or time-zone."
В вашем случае должно быть:
Но тогда большая часть страданий и "полезных советов" из статьи становится неактуальной.
Боюсь, все далеко не так просто и однозначно, как вы описали.
Во-первых, на момент разработки logback-appender'а нормальных внешних тулов для отправки Java-логов в Loki просто не было. Promtail и fluent-bit максимально криво парсили стандартный текстовый формат, особенно плохо было со стек-трейсами и записями, задержищими перевод строки. Давно не смотрел, что там с promtail, но у fluent-bit проблема сохраняется до сих пор.
Во-вторых, зачем вообще что-то сериализовать в строку, чтобы потом парсить с потерей информации, если можно отправить напрямую точно без потерь? Это более прямолинейное решение с инженерной точки зрения.
В-третьих, STDOUT вы все равно пишите через аппендер. Почему то же самое через такой же аппендер нельзя писать в локи? В плане полноты логов там будет абсолютно то же самое. Но при этом вы будете использовать тот же знакомый всем джавистам инструмент, и бесплатно получите все его богатые возможности в преломлении к специфике Loki. Например, можно делать динамические лейблы, используя MDC.
Не скажу за все возможные аппендеры, но конкретно мой при тормозах или недоступности Loki не упадет и не будет тормозить приложение (или точнее сказать будет тормозить даже меньше, чем сторонняя тула для отправки логов, которая в любом случае ест сколько-то дополнительного CPU и RAM на ненужную сериализацию/десериализацию).
Ваш единственный аргумент сводится к тому, что при недоступности Loki логи могут потеряться. Да, могут. И это одинаково справедливо и для отправки из приложения и через стороннюю тулу. Если не хотите терять логи, просто делайте высокодоступную инфраструктуру, Loki как раз предназначен для этого.
Хочу еще раз пояснить свою позицию. Она совсем не в том, что promtail и иже с ним вообще не нужны, что не нужно слушать STDOUT контейнера и т.п. Она в том, что конкретно для Java-приложения, сложнее чем HelloWorld, есть варианты лучше, чем писать логи в STDOUT, чтобы потом их парсить и отправлять в Loki отдельной тулзой.
А что такое целый объект в вашем представлении? Можете привести примеры целых объектов?
Линукс всегда будет зоной дискомфорта для людей, привыкших к винде. Иначе он бы просто превратился во вторую винду, которая никому не нужна, потому что уже есть первая. А линукс в текущем его виде как раз много кому нужен. Пока винда доминирует на не самом перспективном рынке десктопов, линукс доминирует на рынках, переживающих взрывной рост — интернет, смартфоны, облака.
Переводить ли десктоп с винды на линукс в надежде сохранить свой виндовый пользовательский опыт? Лучше не надо, с такими запросами вас там никто не ждет. Но делать из этого вывод, что линукс до чего-то там не дозрел или что он кому-то там не нужен, тоже не стоит.
По моим наблюдениям, все, кто хочет использовать линукс и понимают, зачем им это нужно, — просто ставят и используют. У таких людей обычно не возникает проблемы потратить несколько минут на проверку железа на совместимость до покупки ноута, или потратить те же несколько минут на поиск решения софтверной проблемы в гугле. Этих проблем у каждого конкретного человека случается не так много, и их число со временем сокращается — я на своем опыте наблюдаю этот прогресс последние 12 лет и да, многое изменилось в лучшую сторону.
Есть другой тип людей, которые думают, что сейчас они поставят линукс, и у них будет все так же как в винде, только лучше. Естественно, они не настроены тратить на что-то время и разбираться, ведь "в винде оно само работало". Зачем тогда выходить из зоны комфорта, просто продолжайте сидеть на винде. Это не линукс все еще не дозрел до вас, это вы все еще не дозрели до линукса.
Статья хорошая, спасибо! Но, как мне кажется, Шрёдингер в названии вообще не в тему.
Раз уж у вас тут разговор о моей карме, тоже выскажусь. Отрицательные значения кармы у меня были практически все время, и не очень напрягали. Потом я из спортивного интереса разогнал карму в плюс, но быстро понял, что в этом нет ничего интересного. Когда можешь ставить эти минусы и плюсы, чувствуешь себя каким-то вахтером, как будто на тебе теперь есть какая-то ответственность за контент, надо не просто читать, а еще и правильно расставлять стрелочки. Короче, спортивный интерес к увеличению кармы быстро пропал.
С другой стороны, когда карма меньше -10, становится реально неудобно комментировать. Вот думаю, хочу я с этим что-то делать или нет.
Ну и раз уж мы тут раскрываем карты, то
Вклад в популяризацию ФП однозначно заслуживает плюса, а минусовать кого-то кроме спамеров вообще неправильно. На момент того спора, который мы обсуждаем выше, я, насколько помню, вполне еще мог голосовать.