Смогу ли я устроиться на работу?

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

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

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

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

Поэтому что бы я сделал:

1️⃣ Лучше формулировал бы вопрос. Хороший вопрос - это уже половина ответа. Добавил информацию в каком городе буду искать работу, сколько ресурсов денежных и временных у меня есть для обучения. Кто-то может позволить только самообучение, кто-то наставника. От чего зависит и скорость, и качество обучения.

2️⃣ На каком языке программирования я хочу сфокусироваться. За двумя зайцами погонишься - ни одного не поймаешь.

3️⃣ Предварительно пробил информацию о рынке труда. Сейчас в каждой локации/стране есть сайты-агрегаторы об открытых вакансиях. Лишь благодаря такому анализу я могу вообще передумать изучать программирование или увеличить в 4 раза свои шансы на получение работы, выбрав, например, язык Java, а не C#. Потому что в моем регионе вакансий на Java в 4 раза больше. Или даже запланировал смену места жительства, ибо в городе, где я живу - с программированием все обстоит не очень.

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

Напоминаю, что еще осталось 1 место на менторство 1 ступени, которое уже стартует через 2 недели!

Можно писать в личку, в комментариях к посту, или просто оставить заявку на сайте https://dmdev.tilda.ws/first-level (там же вся информация о процессе обучения)

Чем ты готов пожертвовать ради достижения цели?

Эти мысли я решил изложить здесь в тему предыдущего поста…

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

Например, сколько ты готов тратить времени в сутки для того, чтобы:
- сменить профессию и стать, например, программистом?
- получить первый разряд в беге или другом виде спорта?
- выучить иностранный язык?

Чем потребуется пожертвовать в угоду этой цели?
- меньше времени уделять семье
- уволиться с работы
- финансами
- комфортом
- забросить любимое хобби
- вставать на 2 часа раньше или меньше спать

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

PS. Главное помнить, что все жертвы - временны, потому что цели - конечны. Зато чем сложнее цель, тем большую награду можно получить. И эта награда окупит с лихвой все твои усилия.

Делись к комментариях, чем тебе пришлось пожертвовать, чтобы стать программистом или достичь любой другой цели? А я в другом посте поделюсь своими примерами…

Самый сложный фреймворк

Я не раз говорил, что считаю одним из самых сложных фреймворков в Java - это Hibernate. Именно при его использовании допускается большинство ошибок в приложениях. А т.к. это ORM фреймворк, что означает большое количество запросов в СУБД, а значит много IO операций и проблемы с перформансом всего приложения в целом.

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

Как бы то ни было, из огромного пласта информации я хочу выделить всего лишь 4 основных аспекта, понимание которых будет более чем достаточно, чтобы избавиться от страха в использовании Hibernate и понять его раз и навсегда:

1. Кэш первого уровня (First Level Cache).
Невозможно работать с Hibernate не создавая сессию. И ни одна сессия невозможна без кэша первого уровня, ибо это ее неотъемлемая часть. Проще говоря - это обычный ассоциативный массив, где ключом является id сущности, а значением - сама сущность, ассоциированная с сессией. Такая простота почему-то все равно вводит в заблуждение многих программистов.

2. Жизненный цикл сущности (Entity Lifecycle).
Этот пункт основывается на предыдущем, потому что каждое состояние сущности так или иначе означает “находится ли сущность в кэше первого уровня той или иной сессии”. Вообще, я считаю, что жизненный цикл любого фреймворка или инструмента - это must have откуда нужно начать изучать его, буть то это JUnit, Spring, Hibernate, Maven, Gradle, Apache Tomcat, Asynchronous programming, etc. Это как Java Core для понимая более сложных тем.

3. Паттерн прокси (Proxy).
Многогранность этого паттерна воистину достойна того, чтобы его изучить и понять как следует. Он встречается практически в любом фреймворке, только с разными применениями, начиная от mock/spy в JUnit, добавление динамического функционала для Spring beans, и заканчивая ленивой инициализацией сущностей и коллекций в Hibernate. Именно отсюда черпает свою славу знаменитое исключение LazyInitializationException (естественно вместе с предыдущими двумя пунктами).

4. N + 1 проблема (N + 1 selects problem).
Для любого backend языка программирования невозможно обойтись без общения с СУБД, а знание SQL - это навык, который должен занимать первую строчку в рейтинге у таких программистов. Поэтому понимание того, как оптимально использовать ORM фреймворк Hibernate для работы с СУБД, держа в уме предыдущие 3 пункта - и есть показатель отличного качества и хорошей квалификации Java разработчика.

🎁 Best practices при использовании Hibernate я рассказываю в этом небольшом видео

#11 Мой путь

Искал я работу просто выложив резюме на сайте jobs.dev.by, указав все свои навыки, которые я получил за 3 курса университета, самообучения, бесплатных курсов и лаборатории компании EPAM Systems c желаемой зарплатой 650$. Я думал на тот момент, что этого будет более чем достаточно. Ибо если никто не ответит - значит ничего страшного, у меня есть EPAM. А на меньшее и нет смысла менять место работы, проще сидеть ровно. Тем более от учебы вообще никак не отвлекало ничего неделание в лаборатории. А Linkedin на тот момент еще не был на столько раскручен, чтобы я решил использовать его для поиска работы.

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

Само собеседование проходило в небольшом кабинете, где было кроме меня еще трое человек. Потом я узнал, что это были руководитель департамента разработки и 2 ведущих Java разработчика, которые собственно и искали джунов себе на проекты. Спрашивали в основном только Java Core. Когда беседа вдруг заходила о фреймворках по моей инициативе, то меня, наоборот, останавливали и спрашивали о том, смогу ли я вместо Hibernate написать все на JDBC. И, как я понял позднее, это было связано с тем, что у них не было фреймворков как таковых, все на Java Core или что-то свое самописное. Например, вместо Hibernate они использовали Bodhi, который сами же и разработали.

Само собеседование продлилось около часа. Я им определенно понравился, потому что буквально сразу же после окончания мне предложили работать в их компании с зарплатой в 700$. Недолго думая, я конечно же согласился. На одной чаше весов лаборатория EPAM Systems с зарплатой 300$ и ожиданием задач на реальном проекте в будущем, а на другой - новый проект прямо сейчас и 700$.

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

#my_little_story - по этому хэштегу можно прочитать мой путь с самого начала

Баланс в принятии решений программиста

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

На самом деле можно было бы все сделать “идеально” и вылизывать каждый “сантиметр квадратный” кода.
Но на практике всегда есть ограничения как денежные, так и временные.
Да и не только ты пишешь код на проекте, его пишет целая команда, которая тоже может менять твой код в зависимости от того, как ты его написал.

Поэтому приходится балансировать между гибкостью/уровнем реализации задачи и скоростью написания кода. И этот баланс лучше всего соблюдать, используя “вероятность” какого-то события.

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

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

Как и какие написать тесты?

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

Для этого нужно просто ответить на два вопроса:
1. Какие возможные тест кейсы могут произойти с этим кодом (начиная естественно с наиболее вероятностных)
2. Как бы я вручную проверял этот код?

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

Ответ на второй вопрос показывает, как должна выглядеть секция then (given/when/then) - т.е. наши asserts на результат выполнения кода. Здесь не стоит лентяйничать и проверять только часть. Например, если я пишу тест, проверяющий http endpoint, который возвращает картинку - мне недостаточно проверить, что http status равен 200. Это как проверка возвращаемого значения из обычного метода на not null. Нужно проверить и http body, что там действительно нужная картинка, и основные http headers, такие как Content-Type, Content-Lengh и т.д.

Более подробно про написание тестов и best practices я показываю в бесплатном практическом видео по JUnit 5.
Полный курс JUnit 5 можно приобрести на платформе GetCourse за 999 rub или YouTube по Senior подписке за 9.99$

#12 Мой путь

4 октября 2012 года - мой первый день на новом месте работы в компании IBA, в которой я проработаю следующие 3.5 года.

Здесь уже выдали и комп мощный, на котором действительно все летает, а не как в лаборатории я ждал минутами, пока просто рестартанет приложение. И место в небольшой комнате на 6 человек, а не open space на 50. Но самое главное - я увидел и начал прощупывать своими руками исходный код реального проекта, после которого все мои предыдущие казались просто детскими забавами. Настолько была колоссальная разница между ними. Именно на нем я провел первые 2 недели, обучаясь технологиям и фреймворками, принятым в этой компании и команде, прежде чем меня назначили на совершенно другой и новый проект с кодовым названием ЕГБДП.

С начальством я договорился, что буду работать по 35 часов в неделю, ибо чисто физически не смогу успевать на полный рабочий день из-за учебы. А учился я на 4 курсе тогда в “среднюю” и самую неудобную смену, когда пары начинались в середине дня. Поэтому я вставал рано утром и шел на работу, прихватив с собой йогурт и булочку на завтрак. Потом уходил на пары, естественно пропуская часть лекций, которые по моему мнению были не важны. Тогда-то и начался спад моей успеваемости и первые 4 балла по экзаменам (по 10-балльной системе).

Но это тогда для меня уже не имело значения - я целиком и полностью был в работе. После пар ближе к 6 часам я возвращался в офис и работал до 9-10 вечера. Тут мне опять повезло, потому что офис-общежитие-универ были близко расположены. За 20-30 минут я мог добраться из одной точки в другую, а из второй - в третью.

Интересный факт: ребятам на проекте казалось, что я сутками в офисе, потому что они приходят утром на работу - я на месте. Уходят с работы вечером - я опять в офисе. Ибо то, что меня не было посреди дня - особо не бросалось в глаза.

Совсем скоро я вклинился как следует, более менее устаканился режим, и я решил выйти на полную ставку, начав работать еще и по субботам. Это было уже зимой, когда я сдал экзамены в универе, впервые неумело воспользовавшись шпорами (до этого я всегда учил и готовился к экзаменам).

Тогда же мне сделали первое повышение на 200$, и я был полон энтузиазма еще больше вкладываться в работу. Эх, как мало мне тогда было надо, чтобы поднять мотивацию, и как сложно этого добиться сейчас 🙂
Так пролетел целый год и закончился 4 курс в универе.

#my_little_story

Plugin Management in Apache Maven

В Apache Maven в POM файлах реализован механизм наследования по очень похожему принципу, что и наследование классов в Java. Наследуется тоже почти все.
Поэтому очень легко запомнить, проассоциировав это с Java, а класс Object - с Super POM.

Секция pluginManagement не исключение. Более того, она специально создана, чтобы не дублировать версии и настройки плагинов в дереве POM файлов многомодульного проекта, как это мы не хотим делать с зависимостями, используя секцию dependencyManagement.

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

1️⃣ Достаточно сконфигурировать плагин лишь один раз в pluginManagement секции рутовой POM, в остальных модулях - просто переиспользовать, указав плагин в секции plugins

2️⃣ Стандартные плагины, такие как maven-compiler-plugin, maven-deploy-plugin, и другие участвующие в жизненном цикле проекта - и так будут использоваться по умолчанию, ибо они наследуются из SUPER POM. Поэтому не надо их описывать в каждом модуле.

3️⃣ Эти же стандартные плагины могут находиться в pluginManagement секции рутовой POM, чтобы, например, переопределять их версию на более актуальную. Как мы можем переопределять методы при наследовании в Java.

4️⃣ properties тоже наследуются, как и dependencies, plugins, etc (полный список). Поэтому достаточно определить их лишь раз в рутовой POM и далее просто переиспользовать в любых других модулях.

Еще больше про Apache Maven можно узнать на моем курсе

IntelliJ IDEA зависимость

Довольно часто в dmdev чатах и на менторстве вижу вопросы подобного рода:
- IDEA не видит application.properties файл в коде. Что я делаю не так? Мне этот файл нужно не в директории resources держать?
- IDEA не подсказывает модель в jsp/html файлах, хотя все работает, когда запускаю приложение. Как так?
- IDEA пишет, что не вызван callSuper в Lombok аннотации @ToString, хотя я указал это. Почему?
- Я создал файл .gitignore, но когда пытаюсь сделать commit - IDEA все равно не игнорирует директорию build. Почему?

Когда я начинал программировать (а это было почти 15 лет назад), таких вопросов в принципе не возникало у программистов, потому что тогда не было настолько мощных сред разработки. А значит и не было такой сильной зависимости от их функционала, их подсказок и т.д. Если что-то не работало - то ты начинал думать логически и шел искать настоящую проблему в коде, а не задавался вопросом “почему IDEA не…”.

Надо понимать, что IntelliJ IDEA и любая другая среда разработки - это всего лишь программа, которая тоже написана другими разработчиками как ты сам. А значит в ней может быть не реализован какой-то функционал в полном объеме, а также есть баги как и в любом другом приложении.

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

PS. Для интереса, чтобы лучше разобраться в том, как все устроено (своего рода сделать ликбез) - можно несколько дней или даже недель поработать без среды разработки, используя любой текстовый редактор.

Вопрос 👆 - Ответ 👇

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

1️⃣ Вне зависимости от уровня разработчика, есть всегда человек или даже несколько, кто помогает в твоем онбординге, например, team lead или ключевой специалист на проекте. Они рассказывают про проект в целом, бизнес логику его, краткосрочные/долгосрочные планы проекта, про команду, процессы внутри этой команды и компании. Этот период, а точнее его активная фаза (потому что вопросы с твоей стороны будут и далее), занимает +- 1 месяц.

2️⃣ В отличие от изучения Java или фреймворков как Spring (то, что я описал в своем roadmap), для онбординга я использую обратный подход - от общего к частному. Другими словами говоря, начинаю читать design docs, чтобы представлять себе в голове общую схему и смотрю на все это с высоты птичьего полета. Design docs всегда пишут в хороших компаниях, прежде чем приступить к разработке ПО. Если их нет - то увеличивается первая фаза онбординга, где тебе будет уже кто-то расписывать такие диаграммы и рассказывать про архитектуру приложения.

3️⃣ Приступаю к тому, чтобы установить все необходимое ПО на комп, скачать исходники и собрать проект. После чего можно детальнее разобраться в коде, фреймворках и технологиях в ключевых сервисах и тех, что будут входить в твою зону ответственности. Эта фаза может проходить в параллели с первыми двумя, если позволяет время и уже имеется весь необходимый доступ (обычно его сразу нет и выдается постепенно).

4️⃣ Беру из backlog НЕ приоритетные задачи. Обычно это баги или мелкие улучшения, чтобы не блокировать команду. Ибо процент того, что пойдет что-то не так у новенького на проекте гораздо выше (и времени на их реализацию уходит больше). Эти небольшие задачи уже помогают на практике закрепить все то, что я получил в теории из предыдущих пунктов. Только так можно разобраться в проекте и технологиях, что ты встречаешь впервые.

#dmdev_qa

Личная победа #2 🏆

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

Все те же тезисы, что и год назад я написал, до сих пор очень актуальны. Хотел бы только чуть подкорректировать некоторые из них:

1️⃣ Если за 2 месяца постоянного труда можно добиться хороших результатов в чем-либо, то за год эти результаты будут просто колоссальны.

2️⃣ Если в течение небольшого промежутка времени могут случаться форс-мажоры, то если брать более продолжительное время (год-два) - количество таких ситуаций и их вероятность увеличивается многократно. Главное здесь действительно восстанавливаться и продолжать идти к своей цели

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

И немного статистики, чего мне стоило улучшение результата за год с 53:01 до 40:34
👇
2031.2 км (в среднем 39.1 км в неделю) или
197:23:53 времени (в среднем 3:47:46 в неделю)

#13 Мой путь

Вот и настал заключительный 5-ый курс университета. Я учился на бюджете, поэтому нужно было либо подписывать договор со своей компанией IBA на 2 года распределения после учебы, либо выбирать компании из предложенного факультетом списка, который мягко говоря был не очень. Ограничивать себя и связывать на столько времени с одной компанией конечно не хотелось мне, но другого варианта не было. Более того, текущий проект на работе разрастался, и меня попросили найти трех толковых ребят к себе в помощь. Другими словами говоря, я стану лидом, что меня очень воодушевляло, т.к. позволяло прокачаться в отличном от написания кода направлении.

Так собственно и произошло - я подписал договор на 2 года о распределении с компанией IBA (кстати, мне почему-то как раз в это время опять повысили зарплату… совпадение?), и привел на собеседование троих ребят, двое из которых были на том же потоке моего факультета. Все трое успешно прошли собеседование, после чего мы вместе стали работать над одним проектом.

Еще интересный момент, что на 5-ой курсе я впервые столкнулся с языком программирования Java, который шел по учебной программе. Там было 4 лабораторные работы за весь семестр, которые я сделал буквально за вечер. Вот, что значит практика на работе и учеба в университете - это абсолютно разные и несравнимые вещи. Тогда же я в который раз убедился, что поступил правильно, забив на учебу и сконцентрировавшись полностью на карьере программиста.

Экзаменов было меньше в этом семестре, и сдавали мы их на несколько недель раньше - в декабре 2013 года, чтобы поскорее начать писать дипломный проект. В качестве его темы я решил выбрать “Автоматизированная система управления ресторанами”. Времени было достаточно и для работы, и для написания дипломного проекта, потому что на заключительном семестре как таковых пар и нет. Нужно просто время от времени показывать проделанную работу и посещать преподавателей по охране труда, экономике и т.д., потому что твой дипломный проект должен быть “экономически обоснованным” и соблюдать “охрану труда”. Хотя по факту, я больше времени потратил не на написание кода приложения, а на форматирование уже готового дипломного проекта, ибо невероятно тяжело соблюдать все ГОСТы, на которые больше всего и обращали внимание преподаватели (кто захочет ревьювить код сотен студентов?).

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

Как хорошо, что долго я в этой квартире не задержался, а в общежитиях я больше не жил…

#my_little_story

Проблемы с перформансом приложения

Когда речь заходит о производительности приложения и поиск проблемных по перформансу мест, то любые приложения можно разбить на два основных аспекта:
- CPU, т.е. алгоритм и логика работы
- IO, т.е. операции ввода-вывода, к которым можно отнести запросы к СУБД, работу с файлами, общение с другими сервисами по различным протоколам (HTTP, gRPC, Thrift, etc)

Производя нагрузочный тест, или (что хуже) на проде, мы обнаруживаем, что у разработанного нами приложения обнаруживаются проблемы с перформансом - мы почему-то зачастую пытаемся найти ошибки в CPU.

Более того, мы пытаемся максимально оптимизировать код и думаем об ошибках перформанса ВО ВРЕМЯ разработки - тоже в CPU. Хотя подавляющее большинство backend приложений на Java не содержат очень сложной логики, а более 90% проблем связаны именно с операциями IO.

Поэтому, как я писал в посте “Баланс в принятии решений программиста” - нужно сконцентрировать свое внимание на оптимизации кода в более вероятностных местах, например, таких как:

1️⃣ Работа с СУБД, а особенно наши sql запросы, где понадобится не только хорошо знать как грамотно их писать, но и как оптимизировать их в случае возникновения проблем, анализируя планы выполнения (ибо не надо стараться оптимизировать каждый запрос и тратить на это кучу времени). Также обращать внимание на более правильную работу с ORM фреймворками, которые непосредственно связаны с СУБД, а значит могут негативно сказаться на перформансе.

2️⃣ Работа с файлами, особенно большими, где особо часто встречается утечка памяти или даже OutOfMemoryError, когда программист пытается всегда полностью считать файл в память.

3️⃣ Общение с другими сервисами ввиду распространенности микросервисной архитектуры в текущий момент, стараясь избегать блокирующих вызовов в сторону использования асинхронных (или фреймворков вроде Spring Reactive).

А с какими ты ошибками перфоманса сталкивался на своих проектах?

Для получения весомого результата нужно время

В беге - невозможно взять и моментально улучшить темп с 4:00 до 3:40 мин/км за пару тренировок. Все потому, что нужны изменения на клеточном уровне в организме человека. Чтобы образовались новые волокна в мышцах, укрепились связки и сухожилия, появились новые митохондрии и прокачалась сердечно-сосудистая система.

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

А все почему? Потому что нужно построить нейронную сеть и проложить новые связи между нейронами в мозге. Т.е. это тоже изменения на клеточном уровне, которые не моментальны и требуют времени. Более того, эти связи между нейронами строятся на основании уже имеющихся. Точно также как и все изобретения человечества создаются но основании уже существующих, потому что невозможно придумать что-то абсолютно новое - это накопительный эффект (опыт).

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

Так что нужно запастись терпением и добавить немного постоянства - тогда результат точно придет!

У меня все выветривается из головы

В Java есть большая и очень важная тема - IO (Input and Output streams). Input stream - это считывание, получение данных В приложение. Output stream - наоборот, передача данных ИЗ приложения. После получения данных (Input) - мы обязательно должны обработать их в программе. Например:
- сохранить в базу данных
- передать в другое приложение
- вернуть пользователю ответ на его http запрос
- преобразовать в другой тип данных и записать в файл

А все это уже самый настоящий Output. Т.е. и Input, и Output streams очень взаимосвязаны друг с другом. В противном случае - все данные исчезнут.

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

Поэтому если мы все-таки намерены усвоить какой-то материал - нужно ОСТАНАВЛИВАТЬСЯ и ОСМЫСЛИВАТЬ его, как это мы бы делали в приложении. Другими словами говоря, подключать Output stream.

И самый действенный способ для этого - практиковаться. Практика - это и есть извлечение информации из себя, а точнее - ее использование. Хотя даже просто подумать о прочитанном - уже многого стоит!

Мой Output Stream

В продолжении к предыдущему посту...

...оглядываясь назад я могу вспомнить два очень важных момента, которые невероятно сильно повлияли на мои навыки в программировании (и не только в нем конечно же, ибо все взаимосвязано). Это как два огромных “спайка” на графике моего прогресса:

Первое - это когда я начал преподавать в it-academy.
Второе - это когда я начал создавать видео на YouTube.

Оба варианта - это самый настоящий Output stream. Причем крупнокалиберный, действеннее способа которого вряд ли можно придумать.

Уже не такой мощный, но тем не менее выше на голову всех остальных способов, что я также заметил - это писать посты и статьи вроде тех, что я публикую здесь на канале DMdev talks или Instagram.

А вообще, чем больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов уходит на какое-то действие - тем сильнее закрепляется результат. Но это уже отдельная тема для следующего поста)