И корутины и горутины решают одну и ту же задачу - легковесное управление большим числом асинхронных неблокирующих задач. То что там в реализации используется stackful подход вместо stackless не делает из автомобиля смартфон.
Нет никаких там дополнительных потоков, те же таски но на уровне JVM исполняемые платформенными потоками-носителями. Вся киллер фича Java подхода - это отсутствие необходимости явного этим управления. Для этого в коде буквально напиханы If-чики
public static void sleep(long millis) throws InterruptedException {
if (millis < 0) {
throw new IllegalArgumentException("timeout value is negative");
}
long nanos = MILLISECONDS.toNanos(millis);
ThreadSleepEvent event = beforeSleep(nanos);
try {
if (currentThread() instanceof VirtualThread vthread) {
vthread.sleepNanos(nanos);
} else {
sleep0(nanos);
}
} finally {
afterSleep(event);
}
}
Наверное, дело в каких-то оптимизациях хранения объектов в куче.
Нет все проще. Если не ошибаюсь, в Java только к 2017 году проснулись и осознали что оказывается в современном яп нужна нормальная поддержка неблокирующей асинхронности. Можно было скопировать async/await который уже был отработан много лет но в Oracle решили стать нитакусиками и начали пилить свои идеи. Как результат, в Kotlin корутины зарелизили в 2018 году а в Java виртуальные потоки увидели мир только через 6 лет после этого. Итого мы сейчас в Java имеем виртуальные потоки, которые по факту те же корутины без особых преимуществ, только без необходимости писать async/await и пока что непонятно насколько эффективные в будущем. Просто для сравнения: в C# async/await появился в 5.0 версии в 2012 году.
Развивайте как глубину в своей области, так и ширину знаний. Например, Java-разработчику полезно изучить DevOps или основы UI-дизайна.
Технологии развиваются стремительно. Знание популярных инструментов, таких как Docker или Kubernetes, и новых языков программирования вроде Go или Rust, выделит вас среди других специалистов.
Получаем разрабы в стиле - слышал про многое, не знаю из этого толком ничего.
Умение объяснять сложные технические детали, работать в команде и понимать цели бизнеса ценится не меньше, чем знание фреймворков.
Для кого? Для джуна?
"Java Concurrency in Practice" — Брайан Гетц
Вот тут можно дискутировать насчет полезности LeetCode да и в целом способности решать алгоритмические задачки, но мое индивидуальное мнение - алгоритмы полезны, так как, если ты знаешь структуры данных и можешь их использовать в решении задач, то ты можешь чувствовать себя увереннее в разработке.
Отличные советы чтобы навичок все забросил. Вот есть новичок. Ему итак сложно, он итак перегружен даже той базой знаний что требуется от него здесь и сейчас. А сейчас от него требуется изучить нормально язык программирования, текущие фреймворки, подходы, git, жизненный цикл разработки и т.д., чтобы он хотя бы смог самостоятельное работать и закрепиться в профессии, стать полноценным разрабом.
А Вы ему предлагаете дополнительно изучать Go, Rust, Docker, Kubernetes, многопоточку и учиться решать алгоритмы.
Ни в коем случае. Mock-собеседования выкладывают все кому не лень. Шанс нарваться на видео где кандидат несет ахинею а интервьюер его радостно поддерживает очень высокий. Таких видео полно. Для начинающего, распознать где хорошо а где плохо не просто. Тоже самое касается статей. Лучше всего для новичка - сделать упор на книги и официальные мануалы.
Бесшовный пользовательский опыт: Хотя микрофронтенды разрабатываются отдельно, пользователь воспринимает их как одно целое.
Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода. Читать такие переводы уже на физическом уровне больно.
Отличное знание Java Core и Java Concurrency. Понимание объектно-ориентированного программирования, знание особенностей при работе с ним в Java.
Неплохо так. Мне всегда казалось что найти senior который реально понимает Java Concurrency выше базового уровня - не простая задача сейчас. А тут мидлы еще и на отлично должны знать.
Выражу возможно непопулярное мнение но мне кажется что сейчас, для больших компаний и команд, роль тимлида - это уже рудимент. Намного адекватнее мне показался подход когда есть команда адекватного размера и менеджером с одной стороны и техлидом с другой. Каждый занимается своим делом и делает это эффективно. Очень малореально это - сидеть на всех стульях во всем успевать разбираться, со всеми общаться успевать, при этом не овертаймить и не выгорать.
Чтобы описать концепцию использования переменных для какого-нибудь нового языка программирования, сперва нужно разделить все переменные по их времени жизни на статические и локальные (автоматические):
Статические — это глобальные переменные, функции и типы данных к которым можно обратиться из любого другого участка кода или модуля. Статические переменные (объекты) создаются как правило в куче и сохраняют свое значение при выходе из блока кода, где были определены (т.е. после выхода из текущей области видимости).
Автоматические или локальные переменные, это аргументы функций и переменные в выражениях, которые создаются компилятором в автоматическом режиме как правило на стеке. Локальные и автоматические переменные доступные только изнутри того лексического контекста, в котором они были определены, а их значения уничтожаются при выходе из блока кода, где они были созданы.
Вот я выделил переменную в куче, занял память. Вот эта переменная она по вашей логике статическая или локальная? Если мы возьмем семантику C то окажется что она по Вашей классификации статическая а если семантику Rust то получается что локальная? Не самый лучший пример концепции для нового языка.
Есть много критериев подходящего кандидата, но не все они равноценные. Дипломы и сертификаты можно купить, домашние проекты — «позаимствовать» на гитхабе, а вот решение задач (особенно в реальном времени) сразу показывает, как человек мыслит и к каким алгоритмическим конструкциям он привык.
Можно сколько угодно себя убеждать что "волшебные" алгоритмические задачи решать все ваши проблемы с подбором и как будто бы показывают как человек мыслит, но реальность такова что такие задачи показывают только как человек решает... такие задачи, причем именно за ограниченное время.
У меня есть хороший пример на эту тему. Как то работал на двух разных проектах с двумя разрабами. Уровень говнокода написанного первым стал легендой. Человек просто не мог писать нормально, понятно, расширяемо и оптимально. Его код проще было полностью заново переписать чем пытаться модифицировать. Другой разраб, будучи мидлом, как то раз решил простейшую задачу по блокировке доступа к ресурсу, таким образом что про это хоть отдельную статью писать. Вместо добавления обычного флага и поля с датой, история вылилась в многопоточное решение с отдельным экзекутором и хитрыми механизмами разблокировок в стиле "машинного обучения". При этом все это работало плохо и в случае повторного доступа к странице - блокировало пользователя без возможности как то блокировку снять до таймаута. Решение было просто легендарное.
Что же объединяет этих двух разработчиков и зачем я про них написал? Они оба были победителями олимпиад по программированию и отлично решали алгоритмы. И наверняка бы прошли бы любые алгоритмически интервью на 5 с плюсом.
Понять как мыслит человек можно только поработав с этим человеком и посмотрев как он решает разноплановые задачи а все эти попытки через найти "серебряную пулю" через алгоритмические или system design интервью - просто самообман. Не залезете вы в голову человеку даже за 2 часа интервью. Максимум что можно сделать это построить его таким образом чтобы разноплановыми вопросами, размышлениями и небольшими задачами, пошатать собеседуемого и посмотреть что он действительно понимает а что заученно или подсмотрено, построить вопросы так чтобы сложно было дать шаблонный ответ. И прикинуть насколько все это подходит под ваш проект. А дальше только на испытательном смотреть.
Спасибо множеству британских и американских каналов и сайтов с уроками по произношению. Приятно осознавать что они существуют исключительно для России.
Вот честно говоря, прочитал статью и так и не понял о чем идет речь. Сначала:
Я к тому, что каждый понимает под чистым кодом что-то своё: для кого-то достаточно правильного именования и грамотной декомпозиции, а кто-то не видит чистого кода без полиморфизма и высокого уровня абстракции.
И получаеться что у нас нет предмета обсуждения, так как каждый под эти понимает свое. Но далее встречаеться:
Вопрос состоит в том, стоит ли выполнять абсолютно все правила в любом контексте.
Какие правила, если выше описано что каждый понимает свое?
Собственно, вопрос мой в том, насколько уместно соблюдать все сложные архитектурные правила чистого кода в каком-нибудь TODO приложении..
Мысль, которую я хочу донести, состоит в том, что не все задачи требуют соблюдения всех правил чистого кода.
Вроде бы говорили про философию а перешли к каким то уже конкретным правилам.
Всегда ли стоит добиваться максимальной абстракции? Обязательно ли функции должны быть короткими и выполнять одну задачу? Мой ответ: нет, не всегда. Однако замечу, что и выдавливать максимальную производительность из кода необходимо не всегда.
И вот здесь начинаешь подозревать что уже произошла подмена понятий. Вместо абстрактного философского понятия "чистый код", уже имеется в виду конкретно заветы Мартина, SOLID, паттерны и т.д.
Напишу свое мнение со своего опыта. Не стоит делать из паттернов, принципов и книг известных авторов религию. В моем понимании, чистый код - это код который понятен большинству разработчиков, устойчив к изменениям и надежен а не тот который формально что-то соблюдает. Второе, из определенного опыта связанного с геймдевом и огромным требованиям к производительности, могу заявить: можно писать хорошо и понятно, при этом производительно. Просто не нужно формализованные правила возведенные в религию напрямую отождествлять с понятием хорошего кода.
Честно говоря, я уже от восьмерки плакал. Чтобы так откровенно начать убивать язык - это надо постараться. Все молятся на "Чистый код" Мартина, но требования второй главы в 8 нарушены чуть более чем полностью.
Не могли бы уточнить к каким изменениям у Вас такие претензии?
Вы раз за разом рассказываете спецификацию "своими словами" при этом не можете на эту самую спецификацию сослаться. Сейчас пишите про "расплывчатое определение". Ссылаетесь на часть спецификации где просто есть слова "cached" и "registers".
Почему так сложно признать что на деле слабо понимаете как работает volatile?
Формулировка, очевидно, совпадает не стопроцентно. Но если усреднить, то можно читать это как "Изменения видны всем потокам, вместо использования независимых чтений/записей закешированных значений каждым отдельным потоком."
Там английским по белому написано что "изменения volatile переменных видны другими потоками", как у вас получается читать в этой фразе "закешированных значений каждым отдельным потоком "?
Можете расшифровать что значит фраза:"Изменения видны всем потокам, вместо использования независимых чтений/записей закешированных значений каждым отдельным потоком." ?
Из документации мы можем узнать, что ключевое слово volatile:
Предотвращает использование кэша для разных потоков, тем самым гарантируя, что изменения в переменной будут сразу видны всем потокам;
Устанавливает happens-before отношение между переменной и чтениями/записью рядом, тем самым запрещая производить оптимизации, основанные на изменении порядка операций.
Укажите пожалуйста, где в документации на которую Вы сами и сослались и даже ссылку добавили, упоминания о "Предотвращает использование кэша для разных потоков"?
Так запрещает использовать кэш или запрещает оптимизации или запрещает все на свете на всякий случай?
Мы в итоге отказались от mybatis в пользу jooq — он тоже позволяет контролировать sql код, но возможностей у него на порядок больше.
Как решаете проблему со сложным маппингом нескольких сложенных сущностей после череды джоинов ? Я помню когда читал документация JOOQ пару лет назад то они просто забили на эту проблему а все варианты которые я видел были малоприглядными мягко говоря. Подумалось тогда - зачем мне библиотека позволяющая удобно писать запросы но не дающая никаких нормальных инструментов чтобы потом результаты этих запросов человеческим образом преобразовывать в модели. Поправьте если не так. Менее удобный батис как раз эту проблему решал удобным и простым способом.
У Project Valhalla есть один минус. Учитывая сколько его уже делают и сколько раз обещали что-нибудь наконец выкатить а воз и ныне там, есть ощущение что мы сами в Вальгалле окажемся раньше чем проект в релизе.
Структуры используются для инкапсуляции связанных свойств в один унифицированный тип данных.
забавно было читать. Оказывается анонимные функции и замыкания это одно и тоже а неизменяемость данные это невозможность изменить размер массива или кортежа.
Куча ошибок и неточностей.
Тратить время на прочтение не советую. Лучше уж официальную документацию.
И корутины и горутины решают одну и ту же задачу - легковесное управление большим числом асинхронных неблокирующих задач. То что там в реализации используется stackful подход вместо stackless не делает из автомобиля смартфон.
Нет никаких там дополнительных потоков, те же таски но на уровне JVM исполняемые платформенными потоками-носителями. Вся киллер фича Java подхода - это отсутствие необходимости явного этим управления. Для этого в коде буквально напиханы If-чики
Нет все проще. Если не ошибаюсь, в Java только к 2017 году проснулись и осознали что оказывается в современном яп нужна нормальная поддержка неблокирующей асинхронности. Можно было скопировать async/await который уже был отработан много лет но в Oracle решили стать нитакусиками и начали пилить свои идеи.
Как результат, в Kotlin корутины зарелизили в 2018 году а в Java виртуальные потоки увидели мир только через 6 лет после этого.
Итого мы сейчас в Java имеем виртуальные потоки, которые по факту те же корутины без особых преимуществ, только без необходимости писать async/await и пока что непонятно насколько эффективные в будущем.
Просто для сравнения: в C# async/await появился в 5.0 версии в 2012 году.
Получаем разрабы в стиле - слышал про многое, не знаю из этого толком ничего.
Для кого? Для джуна?
Отличные советы чтобы навичок все забросил.
Вот есть новичок. Ему итак сложно, он итак перегружен даже той базой знаний что требуется от него здесь и сейчас. А сейчас от него требуется изучить нормально язык программирования, текущие фреймворки, подходы, git, жизненный цикл разработки и т.д., чтобы он хотя бы смог самостоятельное работать и закрепиться в профессии, стать полноценным разрабом.
А Вы ему предлагаете дополнительно изучать Go, Rust, Docker, Kubernetes, многопоточку и учиться решать алгоритмы.
Ни в коем случае. Mock-собеседования выкладывают все кому не лень. Шанс нарваться на видео где кандидат несет ахинею а интервьюер его радостно поддерживает очень высокий.
Таких видео полно. Для начинающего, распознать где хорошо а где плохо не просто.
Тоже самое касается статей. Лучше всего для новичка - сделать упор на книги и официальные мануалы.
Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода.
Читать такие переводы уже на физическом уровне больно.
Неплохо так. Мне всегда казалось что найти senior который реально понимает Java Concurrency выше базового уровня - не простая задача сейчас. А тут мидлы еще и на отлично должны знать.
Выражу возможно непопулярное мнение но мне кажется что сейчас, для больших компаний и команд, роль тимлида - это уже рудимент. Намного адекватнее мне показался подход когда есть команда адекватного размера и менеджером с одной стороны и техлидом с другой. Каждый занимается своим делом и делает это эффективно. Очень малореально это - сидеть на всех стульях во всем успевать разбираться, со всеми общаться успевать, при этом не овертаймить и не выгорать.
Вот я выделил переменную в куче, занял память. Вот эта переменная она по вашей логике статическая или локальная? Если мы возьмем семантику C то окажется что она по Вашей классификации статическая а если семантику Rust то получается что локальная?
Не самый лучший пример концепции для нового языка.
Можно сколько угодно себя убеждать что "волшебные" алгоритмические задачи решать все ваши проблемы с подбором и как будто бы показывают как человек мыслит, но реальность такова что такие задачи показывают только как человек решает... такие задачи, причем именно за ограниченное время.
У меня есть хороший пример на эту тему. Как то работал на двух разных проектах с двумя разрабами. Уровень говнокода написанного первым стал легендой. Человек просто не мог писать нормально, понятно, расширяемо и оптимально. Его код проще было полностью заново переписать чем пытаться модифицировать. Другой разраб, будучи мидлом, как то раз решил простейшую задачу по блокировке доступа к ресурсу, таким образом что про это хоть отдельную статью писать. Вместо добавления обычного флага и поля с датой, история вылилась в многопоточное решение с отдельным экзекутором и хитрыми механизмами разблокировок в стиле "машинного обучения". При этом все это работало плохо и в случае повторного доступа к странице - блокировало пользователя без возможности как то блокировку снять до таймаута. Решение было просто легендарное.
Что же объединяет этих двух разработчиков и зачем я про них написал?
Они оба были победителями олимпиад по программированию и отлично решали алгоритмы.
И наверняка бы прошли бы любые алгоритмически интервью на 5 с плюсом.
Понять как мыслит человек можно только поработав с этим человеком и посмотрев как он решает разноплановые задачи а все эти попытки через найти "серебряную пулю" через алгоритмические или system design интервью - просто самообман.
Не залезете вы в голову человеку даже за 2 часа интервью. Максимум что можно сделать это построить его таким образом чтобы разноплановыми вопросами, размышлениями и небольшими задачами, пошатать собеседуемого и посмотреть что он действительно понимает а что заученно или подсмотрено, построить вопросы так чтобы сложно было дать шаблонный ответ. И прикинуть насколько все это подходит под ваш проект. А дальше только на испытательном смотреть.
Спасибо множеству британских и американских каналов и сайтов с уроками по произношению. Приятно осознавать что они существуют исключительно для России.
Вот честно говоря, прочитал статью и так и не понял о чем идет речь.
Сначала:
И получаеться что у нас нет предмета обсуждения, так как каждый под эти понимает свое. Но далее встречаеться:
Какие правила, если выше описано что каждый понимает свое?
Вроде бы говорили про философию а перешли к каким то уже конкретным правилам.
И вот здесь начинаешь подозревать что уже произошла подмена понятий. Вместо абстрактного философского понятия "чистый код", уже имеется в виду конкретно заветы Мартина, SOLID, паттерны и т.д.
Напишу свое мнение со своего опыта.
Не стоит делать из паттернов, принципов и книг известных авторов религию. В моем понимании, чистый код - это код который понятен большинству разработчиков, устойчив к изменениям и надежен а не тот который формально что-то соблюдает.
Второе, из определенного опыта связанного с геймдевом и огромным требованиям к производительности, могу заявить: можно писать хорошо и понятно, при этом производительно.
Просто не нужно формализованные правила возведенные в религию напрямую отождествлять с понятием хорошего кода.
Нет. Это решение абсолютно тех же проблем что и корутины, просто несколько другим способом.
Не могли бы уточнить к каким изменениям у Вас такие претензии?
Вы раз за разом рассказываете спецификацию "своими словами" при этом не можете на эту самую спецификацию сослаться. Сейчас пишите про "расплывчатое определение". Ссылаетесь на часть спецификации где просто есть слова "cached" и "registers".
Почему так сложно признать что на деле слабо понимаете как работает volatile?
Там английским по белому написано что "изменения volatile переменных видны другими потоками", как у вас получается читать в этой фразе "закешированных значений каждым отдельным потоком "?
Можете расшифровать что значит фраза:"Изменения видны всем потокам, вместо использования независимых чтений/записей закешированных значений каждым отдельным потоком." ?
Укажите пожалуйста, где в документации на которую Вы сами и сослались и даже ссылку добавили, упоминания о "Предотвращает использование кэша для разных потоков"?
Так запрещает использовать кэш или запрещает оптимизации или запрещает все на свете на всякий случай?
Как решаете проблему со сложным маппингом нескольких сложенных сущностей после череды джоинов ?
Я помню когда читал документация JOOQ пару лет назад то они просто забили на эту проблему а все варианты которые я видел были малоприглядными мягко говоря. Подумалось тогда - зачем мне библиотека позволяющая удобно писать запросы но не дающая никаких нормальных инструментов чтобы потом результаты этих запросов человеческим образом преобразовывать в модели. Поправьте если не так.
Менее удобный батис как раз эту проблему решал удобным и простым способом.
У Project Valhalla есть один минус. Учитывая сколько его уже делают и сколько раз обещали что-нибудь наконец выкатить а воз и ныне там, есть ощущение что мы сами в Вальгалле окажемся раньше чем проект в релизе.
После таких откровений от автора оригинала:
забавно было читать. Оказывается анонимные функции и замыкания это одно и тоже а неизменяемость данные это невозможность изменить размер массива или кортежа.
Куча ошибок и неточностей.
Тратить время на прочтение не советую. Лучше уж официальную документацию.