Java

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

Лойс, пи****ка, досвидония (© Doctor DIY)

Как устроено обучение

Вы, возможно, знаете, как проходит обучение в обычных школах программирования: человек оплачивает курсы, начинает заниматься, сдает работы. У нас в Kata не совсем так. Есть две формы обучения: по предоплате и по постоплате. С предоплатой все просто: это и есть та самая привычная форма, при которой студент платит до начала занятий. Но еще есть постоплата. В этом случае студент учится, ничего не заплатив. И только когда он находит работу в IT, начинает перечислять школе процент от своей зарплаты.

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

Кстати, даже тем, кто идет по предоплате, я советую сначала что-то почитать и посмотреть ролики. Так будет проще понимать, о чем пойдет речь во время учебы, и это поможет быстрее влиться в процесс.

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

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

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

Чему учат в Kata Academy

Большинство студентов допускают одну и ту же ошибку. У них в голове заложена такая форма обучения из школы и института: ты приходишь на лекцию, тебе что-то объясняют, ты в меру своих сил запоминаешь информацию, иногда делаешь задания, потом сдаешь экзамены и получаешь диплом. Курс Kata устроен по-другому: здесь мы даем студентам задания, а им нужно самостоятельно искать информацию. Ведь главный навык разработчика — это умение гуглить. В этой профессии нельзя все узнать раз и навсегда.

Да, ученики сами находят информацию, но программированию по-другому не научишься. Можно годами ходить на курсы и пытаться что-то запомнить, но в итоге на работе твои задачи будут постоянно меняться, усложняться, а ты не сможешь находить решения. Там нельзя сказать: «Мы этого не проходили». Такой сотрудник вместо того, чтобы попытаться разобраться самостоятельно, будет донимать вопросами тимлида. В общем, скорее всего, работа у него не будет идти легко. Так что научиться искать информацию может быть даже важнее, чем кодить. Код, наверное, занимает 40% работы, а поиск — 60%.

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

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

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

Как подготовиться к учебе

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

Конечно, надо готовиться к трудностям. Особенно сложно будет первое время, но со временем станет понятней и легче. Мне кажется, обучение программированию похоже на сборку пазла: сначала перед тобой просто куча разрозненных непонятных деталей, но со временем они начинают складываться в цельную картину. Конечно, будут возникать мысли: «Это слишком сложно». Но нужно проявить терпение, игнорировать их и двигаться дальше.

Как найти работу

После обучения со студентами работают уже не менторы, а сотрудники специального отдела Kata Academy. Но если кто-то хочет продолжить общение, я не возражаю. У меня есть два студента, с которыми мы поддерживаем связь. Опять же, есть чаты выпускников, где тоже можно обсуждать все насущные вопросы. Бывшие студенты активно друг другу что-то подсказывают, особенно если совета просит человек, который идет на свою первую работу в IT.

Если возникают сложности, то наши сотрудники стараются помочь — в Kata Academy есть специальный HR-отдел, который готовит выпускников к их первой работе в IT. Например, кто-то прошел множество собеседований, но офер так и не получил. Тогда его просят сделать запись собеседования, смотрят ее и разбирают ошибки. Может быть, есть проблемы с soft skills, и тогда сотрудник подскажет, как формулировать ответы и держаться увереннее.

УЗНАТЬ БОЛЬШЕ О КУРСЕ JAVA

Реактивнища это не изобретение Спринга.

Первое что нужно знать — реактивщина и реактивный подход не являются изобретением Спринга. Наоборот спринг как обычно поглотил очередную технологию, в данном случае Project Reactor

Реактивный дух времени.

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

Синхронный блокирующий подход:

Предположим что на мнужно выполнить 3 задачи. В старом синхронном подходе мы получим код который будет запущенным одним потоком поочередно и блокирующе.

Реактивный подход

Теперь перепишем ту же задачу используя реактивщину, встроенную в JDK еще с Java 9:

Различия. Небольшая большая разница.

Как можно было понять что сам подход к написанию кода от «естественного» процедурного, где каждый этап движется сверху вниз теряется в реактивщине (хотя и в функциональности он тоже теряется). Реактивный код выглядит скорее как декларативный набор реакций на события и поэтому менее прозрачен и читаем. К сожалению, такой стиль написания кода усложняет процессы разработки, тестирования и поддержки кода.

Но почему реактивщина стала с каждым днем становится все более популярней?

Причин довольно много, но я упомяну лишь два наиболее важных (по моему мнению):

1. Эффективное использование ресурсов (это утверждение истинно только если вы используете неблокирующий код).

2. Отзывчивость системы (Responsive)

Реактивный + неблокирующий подходы = нефть, золото, греча и, конечно же, акции эппл.

Если проанализировать среднестатистический цикл жизни потока то можно заметить что большую часть времени (иногда по 99% времени)

находится либо:

1. В состоянии ожидании доступа к локу те в состоянии ожидании монитора BLOCKED или WAITING

2. В "логическом ожидании" какого то ресурса как то ответа базы, сервиса или просто базы.

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

Решением является совместное использования реактивщины и неблокировщины. Первая организует процесс в котором пул потоков ожидает задачи под выполнение а неблокирующий подход не заставляет ждать потока в рамках одной из задач.

Отзывчивость системы. (Responsiveness)

Один из весомых плюсов реактивщины - возможность получения данных по мере их появления. А как следствие любые решения поверх реактивщины отзывчивы для пользователя и не висят тысячами лет пока все данные не подгрузятся.

Давайте уже, что нибудь попишем.

Как я уже упомянул есть несколько реактивных решений, но в рамках статьи мы напишем Спринговые классические решения.

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

Что это значит на практике?

А на практике это значит что старые библиотеки вроде rest template (общение по http), jdbc template (связь с базой) должны быть выпилены и заменены не реактивные и неблокирующие:

1. Rest Template -> WebClient

2. JdbcTemplate -> DatabaseClient (R2DBC)

3. FileSystemResource (чтение файлов) -> ReadableResource

4. И так далее для соответствующий библиотек.

Пишем классический Фронт Бэк База на Спринге.

Пример ниже не является самым сложным, но скорее показательным. Напишем простую локику:

1. К нам приходит http запрос

2. Мы перенаправляем запрос в базу

3. Как база дает первый ответ мы кидаем данные на фронт

4. Данные на фронте парсятся по мере появления (а не лишь когда все будут доступны)

Если говорить упрощенно то весь код по сути будет сводится к тому что мы будем прокладывать трубы в виде Flux или Mono объектов.

Стоит помнить что вся реактивная магия Спринга возможно лишь когда при его старте используется WebFlux'овый фреймворк. Старый вариант запуска Спринга с каким нибудь томкатом под капотом не сработает. Поэтому зависимости ниже обязательны:

Начнем с базы, используем

Пробросим Flux используя DatabaseClient:

Теперь полученный Flux выставим на сторону фронта:

Наверно вы заметили что возвращаемый тип не application/json. Да тип x-ndjson. Если использовать стандартный application/json то данные которые будут улетать на фронт будут неполный и конвертировать их в целые объекты будет головной болью. Это недостаток потокового подхода (хотя по сути это 1 http запрос, просто растянутый). x-ndjson формат позволяет кидать на фронт кидать объекты

Читаем на фронте. Код неидеален, скорее служит в качестве простого примера.

Код выше делает следующее:

1. Делает http запрос

2. Ожидает ответа

3. Как только ответ прилетает начинает читать его по частям и писать в конcоль

Приведенный пример является довольно простым, возможности WebFlux гораздо богаче и позволяют манипулировать данными в асинхронном, реактивном подходе. Но код становится сложнее для написания, чтения и поддержки.

Еще раз про эффективный расход процессорных ресурсов.

Я еще раз хочу упомянуть что реактивные, неблокирующие решение написанные прямыми руками позволяют выжать максимум из предоставленных ресурсов. Особенно это актуально во времена микросервисов. Все чаще на проектах под небольшой микросервис могут выделить не более чем 1/0.5/0.1 CPU и я в общем поддерживаю такой подход.

Виртуальные потоки VS Реактивщина.

Эта тема заслуживает отдельного поста. И он будет следующим если эта статья зайдет. Дайте знать в комментах если интересно.

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

Достоинства Flight Recorder

Если сравнивать Flight Recorder с другими похожими решениями то можно отметить

• Минимальную нагрузку на само приложение (пишут, что она составляет около 1% производительности).

• Наличие большого количества метрик и возможность интегрировать свои кастомные метрики.

• Простоту интеграции и поддержки.

• Отсутствие необходимости перезагрузки приложения. Утилита работает с "горячей виртуальной машиной"

• Возможность запускать аналитику на фиксированное количество секунд/минут.

Запуск Flight Recorder.

Предположим, вы уже создали свое приложение и готовы запустить его с помощью JAR. Если вы хотите при старте приложения запустить процесс записи Flight Recorder, то достаточно выполнить следующую команду

В данном случае, в течение 10 секунд после старта Flight Recorder будет записывать все происходящее в виртуальной машине.

Используем JCMD для динамического подключения записи.

Как альтернативу можно использовать утилиту входящую в jdk - JCMD которая позволит подключиться уже к рабочей JVM.

Чтобы узнать, какие виртуальные машины работают в данный момент, достаточно просто написать JCMD и получить что-то вроде:

Как только мы определили, к какому процессу (42800) нужно подключиться, вводим команду для записи отчета на 30 секунд. Файл с записанной аналитикой будет назван myreport.fjr. Итоговая команда будет следующей:

Анализируем отчет

Самый просто способ прочитать myreport.jfr - установить программу JMC (Java Mission Control). Скачать её можно вот тут.

После запуска программы можно выбрать существущий myreport.jfr либо подключиться к рабочей виртуальной машине и создать его внутри программы.

Анализируем File I/O - работу с файловой системой.

На вкладке "OUTLINE" необходимо выбрать "File I/O", и тогда можно получить аналитику работы программы с файловой системой. Я намеренно написал код, который создавал файлы размером 20 МБ. Вот что получилось в итоге:

Socket IO - работа с сетью.

Чтобы просмотреть работу и трафик, необходимо выбрать "Socket I/O". В моем случае, взаимодействия с сетью было крайне мало. Вот результат:

Картина совпала - по сети передавались лишь байты данных. Это примерно ничего.

Аналитика памяти - Ключевая вещь для анализа работы виртуальной машины.

Чтобы оценить затраты памяти, необходимо выбрать "Memory" внутри вкладки "Outline":

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

Аналитика Сборщикам Мусора.

Тут несколько вариантов. Есть Grabage Collectons, GC Configuration, GC Summary. Давайте рассмотрим первый и последний:

Итак, на вкладке видна детализированная аналитика времени работы сборщика мусора. Также можно просмотреть общую статистику:

Суммарное время сборщика сборщика мусора составило 56 мс, и при этом было сделано 13 остановок.

Аналитика потоков. Thread Dumps

Также важной частью отчета является информация о состоянии потоков. Благодаря этим данным можно выявить взаимные блокировки и подобные проблемы. Вкладка "Thread Dumps":

Анализ событий.

Flight Recorder также позволяет записывать происходящие события внутри JVM (и даже создавать свои!). Затем все эти процессы можно удобно просмотреть в Event Browser:

В качестве заключения.

Flight Recorder очень удобная в использовании утилита для аналитики виртуальной машины, которая делает внутренние процессы даже сложных Java программ значительно более читаемыми. Меня лично радует сам факт разивития подобных утилит. Кому интересна Java а также мир разработки приглашаю в мой телеграм канал.

Спасибо за внимание, надеюсь вы узнали что то новое.