Самый сложный фреймворк
Я не раз говорил, что считаю одним из самых сложных фреймворков в 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 я рассказываю в этом небольшом видео
Я не раз говорил, что считаю одним из самых сложных фреймворков в 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 разработчика.
🎁
👍37🔥20❤5❤🔥2👌1
#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 - по этому хэштегу можно прочитать мой путь с самого начала
Искал я работу просто выложив резюме на сайте 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 - по этому хэштегу можно прочитать мой путь с самого начала
🔥51👍22❤5👏1
Баланс в принятии решений программиста
При реализации задач программист на самом деле принимает невероятное количество решений:
- а стоит ли разбить метод, или, может, его назвать иначе?
- а какие интерфейсы верхнего уровня создать?
- а как осуществить взаимодействие между разными компонентами системы?
- а как лучше передавать информацию между сервисами?
- а как сделать решение более гибким и расширяемым? И нужно ли вообще это делать?
- а как лучше хранить информацию?Больше операций на чтение или на запись будет? Или и то и другое, и тогда разные подходы придется комбинировать?
- и т.д.
На самом деле можно было бы все сделать “идеально” и вылизывать каждый “сантиметр квадратный” кода.
Но на практике всегда есть ограничения как денежные, так и временные.
Да и не только ты пишешь код на проекте, его пишет целая команда, которая тоже может менять твой код в зависимости от того, как ты его написал.
Поэтому приходится балансировать между гибкостью/уровнем реализации задачи и скоростью написания кода. И этот баланс лучше всего соблюдать, используя “вероятность” какого-то события.
Например, если есть высокая вероятность того, что этот функционал будет расширяться в скором времени, или таблица в базе данных будет достигать больших размеров, или эта часть кода может отпочковаться и стать отдельным микросервисом - то лучше сразу писать код соответствующим образом, чтобы легко было привнести такие изменения. Если же наоборот, вероятность какого-то события мала - то не стоит тратить кучу времени. Достаточно реализовать работающее решение на более менее хорошем уровне и двигаться дальше.
На первых порах это может быть сложным, т.к. приходится делать много умозаключений “а как могут разворачиваться события в этом месте в будущем”. Но этот навык и отличает сильного разработчика от менее опытного. А со временем подобные моменты вообще будут происходить автоматически.
При реализации задач программист на самом деле принимает невероятное количество решений:
- а стоит ли разбить метод, или, может, его назвать иначе?
- а какие интерфейсы верхнего уровня создать?
- а как осуществить взаимодействие между разными компонентами системы?
- а как лучше передавать информацию между сервисами?
- а как сделать решение более гибким и расширяемым? И нужно ли вообще это делать?
- а как лучше хранить информацию?Больше операций на чтение или на запись будет? Или и то и другое, и тогда разные подходы придется комбинировать?
- и т.д.
На самом деле можно было бы все сделать “идеально” и вылизывать каждый “сантиметр квадратный” кода.
Но на практике всегда есть ограничения как денежные, так и временные.
Да и не только ты пишешь код на проекте, его пишет целая команда, которая тоже может менять твой код в зависимости от того, как ты его написал.
Поэтому приходится балансировать между гибкостью/уровнем реализации задачи и скоростью написания кода. И этот баланс лучше всего соблюдать, используя “вероятность” какого-то события.
Например, если есть высокая вероятность того, что этот функционал будет расширяться в скором времени, или таблица в базе данных будет достигать больших размеров, или эта часть кода может отпочковаться и стать отдельным микросервисом - то лучше сразу писать код соответствующим образом, чтобы легко было привнести такие изменения. Если же наоборот, вероятность какого-то события мала - то не стоит тратить кучу времени. Достаточно реализовать работающее решение на более менее хорошем уровне и двигаться дальше.
На первых порах это может быть сложным, т.к. приходится делать много умозаключений “а как могут разворачиваться события в этом месте в будущем”. Но этот навык и отличает сильного разработчика от менее опытного. А со временем подобные моменты вообще будут происходить автоматически.
👍45🔥11👏3❤🔥1
Как и какие написать тесты?
Довольно часто, особенно на начальных порах, возникает вопрос - как правильно покрыть тестами только что написанный функционал, даже когда знаешь теорию и какой-нибудь тест фреймворк вроде 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$
Довольно часто, особенно на начальных порах, возникает вопрос - как правильно покрыть тестами только что написанный функционал, даже когда знаешь теорию и какой-нибудь тест фреймворк вроде 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.
👍27🔥6❤🔥1❤1
Self code review
Порой нам нужен взгляд со стороны на то, что мы делаем. Я бы даже сказал, что человеку жизненно необходима обратная связь от других людей. А что, если мы можем использовать самих же себя в некоторых ситуациях? Например, code review своего же кода?
Когда я разрабатываю какой-то функционал, то первым делом разбиваю его на несколько составных частей, тем самым декомпозируя на более мелкие составляющие. После чего, создаю pull request на каждую из этих частей. И перед тем, как добавить ревьюверов к этим pull requests, я обязательно сам начинаю делать code review, как будто это был бы не мой код.
Со временем я понял, что это невероятно полезная практика - как взгляд с высоты птичьего полета. Ибо я даже не припомню своих pull requests, где после такого просмотра я не нашел какую-нибудь неточность, лишний закомиченный файл или даже ошибку.
Другими словами говоря, человек легко может упустить или недосмотреть что-то по невнимательности, и этого никак не избежать - мы так устроены. Особенно если мы говорим о программировании, где упустить что-то действительно проще простого ввиду огромного количества информации и строчек кода.
Поэтому будет большим плюсом выработать в себе отличную привычку - всегда проверять свои pull requests, чтобы убедиться, что все идет хорошо как и планировалось.
❓ А как часто ты делаешь self code review?
Порой нам нужен взгляд со стороны на то, что мы делаем. Я бы даже сказал, что человеку жизненно необходима обратная связь от других людей. А что, если мы можем использовать самих же себя в некоторых ситуациях? Например, code review своего же кода?
Когда я разрабатываю какой-то функционал, то первым делом разбиваю его на несколько составных частей, тем самым декомпозируя на более мелкие составляющие. После чего, создаю pull request на каждую из этих частей. И перед тем, как добавить ревьюверов к этим pull requests, я обязательно сам начинаю делать code review, как будто это был бы не мой код.
Со временем я понял, что это невероятно полезная практика - как взгляд с высоты птичьего полета. Ибо я даже не припомню своих pull requests, где после такого просмотра я не нашел какую-нибудь неточность, лишний закомиченный файл или даже ошибку.
Другими словами говоря, человек легко может упустить или недосмотреть что-то по невнимательности, и этого никак не избежать - мы так устроены. Особенно если мы говорим о программировании, где упустить что-то действительно проще простого ввиду огромного количества информации и строчек кода.
Поэтому будет большим плюсом выработать в себе отличную привычку - всегда проверять свои pull requests, чтобы убедиться, что все идет хорошо как и планировалось.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36🔥7❤2❤🔥1👎1💩1
#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
4 октября 2012 года - мой первый день на новом месте работы в компании IBA, в которой я проработаю следующие 3.5 года.
Здесь уже выдали и комп мощный, на котором действительно все летает, а не как в лаборатории я ждал минутами, пока просто рестартанет приложение. И место в небольшой комнате на 6 человек, а не open space на 50. Но самое главное - я увидел и начал прощупывать своими руками исходный код реального проекта, после которого все мои предыдущие казались просто детскими забавами. Настолько была колоссальная разница между ними. Именно на нем я провел первые 2 недели, обучаясь технологиям и фреймворками, принятым в этой компании и команде, прежде чем меня назначили на совершенно другой и новый проект с кодовым названием ЕГБДП.
С начальством я договорился, что буду работать по 35 часов в неделю, ибо чисто физически не смогу успевать на полный рабочий день из-за учебы. А учился я на 4 курсе тогда в “среднюю” и самую неудобную смену, когда пары начинались в середине дня. Поэтому я вставал рано утром и шел на работу, прихватив с собой йогурт и булочку на завтрак. Потом уходил на пары, естественно пропуская часть лекций, которые по моему мнению были не важны. Тогда-то и начался спад моей успеваемости и первые 4 балла по экзаменам (по 10-балльной системе).
Но это тогда для меня уже не имело значения - я целиком и полностью был в работе. После пар ближе к 6 часам я возвращался в офис и работал до 9-10 вечера. Тут мне опять повезло, потому что офис-общежитие-универ были близко расположены. За 20-30 минут я мог добраться из одной точки в другую, а из второй - в третью.
Интересный факт: ребятам на проекте казалось, что я сутками в офисе, потому что они приходят утром на работу - я на месте. Уходят с работы вечером - я опять в офисе. Ибо то, что меня не было посреди дня - особо не бросалось в глаза.
Совсем скоро я вклинился как следует, более менее устаканился режим, и я решил выйти на полную ставку, начав работать еще и по субботам. Это было уже зимой, когда я сдал экзамены в универе, впервые неумело воспользовавшись шпорами (до этого я всегда учил и готовился к экзаменам).
Тогда же мне сделали первое повышение на 200$, и я был полон энтузиазма еще больше вкладываться в работу. Эх, как мало мне тогда было надо, чтобы поднять мотивацию, и как сложно этого добиться сейчас 🙂
Так пролетел целый год и закончился 4 курс в универе.
#my_little_story
👍69🔥12❤6❤🔥1
С Днем программиста, коллеги!
Всегда вспоминаю про этот день только когда самого уже поздравляют 😅
Попробуй там запомнить и отсчитать 2^8 степени (=256) дней с начала года. Хотя по факту, День программиста всегда выпадает на одни и те же даты: либо на 12 (високосные года), либо на 13 сентября.
Наверное, за все время самые интересные баги у меня были именно на одном из самых первых моих проектов ЕГБДП, где из-за неправильно написанного алгоритма привязывались прованарушения не к тем людям.
Хотя вот у моего друга еще интереснее были, когда неправильно рассчитывалось количество съеденных мозгов у зомби. Думаю, такие баги даже находить и править будет интересно.
А у тебя какие нескучные баги попадались❓
Всегда вспоминаю про этот день только когда самого уже поздравляют 😅
Попробуй там запомнить и отсчитать 2^8 степени (=256) дней с начала года. Хотя по факту, День программиста всегда выпадает на одни и те же даты: либо на 12 (високосные года), либо на 13 сентября.
Наверное, за все время самые интересные баги у меня были именно на одном из самых первых моих проектов ЕГБДП, где из-за неправильно написанного алгоритма привязывались прованарушения не к тем людям.
Хотя вот у моего друга еще интереснее были, когда неправильно рассчитывалось количество съеденных мозгов у зомби. Думаю, такие баги даже находить и править будет интересно.
А у тебя какие нескучные баги попадались
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉58🔥8👍7❤3❤🔥1
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 можно узнать на моем курсе
В 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 можно узнать на моем курсе
👍29🔥6❤5❤🔥1
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. Для интереса, чтобы лучше разобраться в том, как все устроено (своего рода сделать ликбез) - можно несколько дней или даже недель поработать без среды разработки, используя любой текстовый редактор.
Довольно часто в dmdev чатах и на менторстве вижу вопросы подобного рода:
- IDEA не видит application.properties файл в коде. Что я делаю не так? Мне этот файл нужно не в директории resources держать?
- IDEA не подсказывает модель в jsp/html файлах, хотя все работает, когда запускаю приложение. Как так?
- IDEA пишет, что не вызван callSuper в Lombok аннотации @ToString, хотя я указал это. Почему?
- Я создал файл .gitignore, но когда пытаюсь сделать commit - IDEA все равно не игнорирует директорию build. Почему?
Когда я начинал программировать (а это было почти 15 лет назад), таких вопросов в принципе не возникало у программистов, потому что тогда не было настолько мощных сред разработки. А значит и не было такой сильной зависимости от их функционала, их подсказок и т.д. Если что-то не работало - то ты начинал думать логически и шел искать настоящую проблему в коде, а не задавался вопросом “почему IDEA не…”.
Надо понимать, что IntelliJ IDEA и любая другая среда разработки - это всего лишь программа, которая тоже написана другими разработчиками как ты сам. А значит в ней может быть не реализован какой-то функционал в полном объеме, а также есть баги как и в любом другом приложении.
Поэтому не стоит свято верить всему, что подсказывает твоя любимая среда разработки. Нужно обращать внимание на всякие warnings от нее, серые или подчеркнутые строки кода и т.д., ибо это может быть действительно полезно. Но не нужно свято верить и делать все, что тебе говорит IntelliJ IDEA.
PS. Для интереса, чтобы лучше разобраться в том, как все устроено (своего рода сделать ликбез) - можно несколько дней или даже недель поработать без среды разработки, используя любой текстовый редактор.
👍40🔥8❤2😱2🤔1
Вопрос 👆 - Ответ 👇
Когда я прихожу на новый проект, то алгоритм действий всегда один и тот же, или очень похож. Ниже я буду рассказывать про свой онбординг на проект Fitbit, на котором работаю уже более 3-х лет.
1️⃣ Вне зависимости от уровня разработчика, есть всегда человек или даже несколько, кто помогает в твоем онбординге, например, team lead или ключевой специалист на проекте. Они рассказывают про проект в целом, бизнес логику его, краткосрочные/долгосрочные планы проекта, про команду, процессы внутри этой команды и компании. Этот период, а точнее его активная фаза (потому что вопросы с твоей стороны будут и далее), занимает +- 1 месяц.
2️⃣ В отличие от изучения Java или фреймворков как Spring (то, что я описал в своем roadmap), для онбординга я использую обратный подход - от общего к частному. Другими словами говоря, начинаю читать design docs, чтобы представлять себе в голове общую схему и смотрю на все это с высоты птичьего полета. Design docs всегда пишут в хороших компаниях, прежде чем приступить к разработке ПО. Если их нет - то увеличивается первая фаза онбординга, где тебе будет уже кто-то расписывать такие диаграммы и рассказывать про архитектуру приложения.
3️⃣ Приступаю к тому, чтобы установить все необходимое ПО на комп, скачать исходники и собрать проект. После чего можно детальнее разобраться в коде, фреймворках и технологиях в ключевых сервисах и тех, что будут входить в твою зону ответственности. Эта фаза может проходить в параллели с первыми двумя, если позволяет время и уже имеется весь необходимый доступ (обычно его сразу нет и выдается постепенно).
4️⃣ Беру из backlog НЕ приоритетные задачи. Обычно это баги или мелкие улучшения, чтобы не блокировать команду. Ибо процент того, что пойдет что-то не так у новенького на проекте гораздо выше (и времени на их реализацию уходит больше). Эти небольшие задачи уже помогают на практике закрепить все то, что я получил в теории из предыдущих пунктов. Только так можно разобраться в проекте и технологиях, что ты встречаешь впервые.
#dmdev_qa
Когда я прихожу на новый проект, то алгоритм действий всегда один и тот же, или очень похож. Ниже я буду рассказывать про свой онбординг на проект Fitbit, на котором работаю уже более 3-х лет.
1️⃣ Вне зависимости от уровня разработчика, есть всегда человек или даже несколько, кто помогает в твоем онбординге, например, team lead или ключевой специалист на проекте. Они рассказывают про проект в целом, бизнес логику его, краткосрочные/долгосрочные планы проекта, про команду, процессы внутри этой команды и компании. Этот период, а точнее его активная фаза (потому что вопросы с твоей стороны будут и далее), занимает +- 1 месяц.
2️⃣ В отличие от изучения Java или фреймворков как Spring (то, что я описал в своем roadmap), для онбординга я использую обратный подход - от общего к частному. Другими словами говоря, начинаю читать design docs, чтобы представлять себе в голове общую схему и смотрю на все это с высоты птичьего полета. Design docs всегда пишут в хороших компаниях, прежде чем приступить к разработке ПО. Если их нет - то увеличивается первая фаза онбординга, где тебе будет уже кто-то расписывать такие диаграммы и рассказывать про архитектуру приложения.
3️⃣ Приступаю к тому, чтобы установить все необходимое ПО на комп, скачать исходники и собрать проект. После чего можно детальнее разобраться в коде, фреймворках и технологиях в ключевых сервисах и тех, что будут входить в твою зону ответственности. Эта фаза может проходить в параллели с первыми двумя, если позволяет время и уже имеется весь необходимый доступ (обычно его сразу нет и выдается постепенно).
4️⃣ Беру из backlog НЕ приоритетные задачи. Обычно это баги или мелкие улучшения, чтобы не блокировать команду. Ибо процент того, что пойдет что-то не так у новенького на проекте гораздо выше (и времени на их реализацию уходит больше). Эти небольшие задачи уже помогают на практике закрепить все то, что я получил в теории из предыдущих пунктов. Только так можно разобраться в проекте и технологиях, что ты встречаешь впервые.
#dmdev_qa
👍75🔥6❤3
Личная победа #2 🏆
Ровно год прошел, как я пробежал свои первые 10.000 метров. Сегодня я покорил эту дистанцию во второй раз.
Все те же тезисы, что и год назад я написал, до сих пор очень актуальны. Хотел бы только чуть подкорректировать некоторые из них:
1️⃣ Если за 2 месяца постоянного труда можно добиться хороших результатов в чем-либо, то за год эти результаты будут просто колоссальны.
2️⃣ Если в течение небольшого промежутка времени могут случаться форс-мажоры, то если брать более продолжительное время (год-два) - количество таких ситуаций и их вероятность увеличивается многократно. Главное здесь действительно восстанавливаться и продолжать идти к своей цели
3️⃣ Обратная связь - это лучшее, что можно придумать при освоении любого навыка. В который раз убеждаюсь в этом. Поэтому я своим результатом обязан целиком и полностью тренеру.
И немного статистики, чего мне стоило улучшение результата за год с 53:01 до 40:34
👇
2031.2 км (в среднем 39.1 км в неделю) или
197:23:53 времени (в среднем 3:47:46 в неделю)
Ровно год прошел, как я пробежал свои первые 10.000 метров. Сегодня я покорил эту дистанцию во второй раз.
Все те же тезисы, что и год назад я написал, до сих пор очень актуальны. Хотел бы только чуть подкорректировать некоторые из них:
1️⃣ Если за 2 месяца постоянного труда можно добиться хороших результатов в чем-либо, то за год эти результаты будут просто колоссальны.
2️⃣ Если в течение небольшого промежутка времени могут случаться форс-мажоры, то если брать более продолжительное время (год-два) - количество таких ситуаций и их вероятность увеличивается многократно. Главное здесь действительно восстанавливаться и продолжать идти к своей цели
3️⃣ Обратная связь - это лучшее, что можно придумать при освоении любого навыка. В который раз убеждаюсь в этом. Поэтому я своим результатом обязан целиком и полностью тренеру.
И немного статистики, чего мне стоило улучшение результата за год с 53:01 до 40:34
👇
2031.2 км (в среднем 39.1 км в неделю) или
197:23:53 времени (в среднем 3:47:46 в неделю)
🔥80👍15🎉7❤🔥2
#13 Мой путь
Вот и настал заключительный 5-ый курс университета. Я учился на бюджете, поэтому нужно было либо подписывать договор со своей компанией IBA на 2 года распределения после учебы, либо выбирать компании из предложенного факультетом списка, который мягко говоря был не очень. Ограничивать себя и связывать на столько времени с одной компанией конечно не хотелось мне, но другого варианта не было. Более того, текущий проект на работе разрастался, и меня попросили найти трех толковых ребят к себе в помощь. Другими словами говоря, я стану лидом, что меня очень воодушевляло, т.к. позволяло прокачаться в отличном от написания кода направлении.
Так собственно и произошло - я подписал договор на 2 года о распределении с компанией IBA (кстати, мне почему-то как раз в это время опять повысили зарплату… совпадение?), и привел на собеседование троих ребят, двое из которых были на том же потоке моего факультета. Все трое успешно прошли собеседование, после чего мы вместе стали работать над одним проектом.
Еще интересный момент, что на 5-ой курсе я впервые столкнулся с языком программирования Java, который шел по учебной программе. Там было 4 лабораторные работы за весь семестр, которые я сделал буквально за вечер. Вот, что значит практика на работе и учеба в университете - это абсолютно разные и несравнимые вещи. Тогда же я в который раз убедился, что поступил правильно, забив на учебу и сконцентрировавшись полностью на карьере программиста.
Экзаменов было меньше в этом семестре, и сдавали мы их на несколько недель раньше - в декабре 2013 года, чтобы поскорее начать писать дипломный проект. В качестве его темы я решил выбрать “Автоматизированная система управления ресторанами”. Времени было достаточно и для работы, и для написания дипломного проекта, потому что на заключительном семестре как таковых пар и нет. Нужно просто время от времени показывать проделанную работу и посещать преподавателей по охране труда, экономике и т.д., потому что твой дипломный проект должен быть “экономически обоснованным” и соблюдать “охрану труда”. Хотя по факту, я больше времени потратил не на написание кода приложения, а на форматирование уже готового дипломного проекта, ибо невероятно тяжело соблюдать все ГОСТы, на которые больше всего и обращали внимание преподаватели (кто захочет ревьювить код сотен студентов?).
Потом еще выяснилось, что большинство пятикурсников выгоняют из общежитий в связи с проведением чемпионата мира по хоккею в Минске в мае 2014 года. Спрос на квартиры в то время был невероятен. Каждое утро я просыпался и первым делом шел смотреть на сайты арендного жилья, ибо времени оставалось совсем немного, а любые варианты уходили как горячие пирожки. По какой-то случайности я смог найти себе комнату в трехкомнатной убитой квартире недалеко от офиса за 250$, чему еще и был невероятно рад! Как сейчас помню выражение своей мамы, которая как-то раз приехала в гости и увидела то, где я живу. Еще и наглый рыжий кот вместе с его хозяином, которые оба тырили приготовленную мной еду.
Как хорошо, что долго я в этой квартире не задержался, а в общежитиях я больше не жил…
#my_little_story
Вот и настал заключительный 5-ый курс университета. Я учился на бюджете, поэтому нужно было либо подписывать договор со своей компанией IBA на 2 года распределения после учебы, либо выбирать компании из предложенного факультетом списка, который мягко говоря был не очень. Ограничивать себя и связывать на столько времени с одной компанией конечно не хотелось мне, но другого варианта не было. Более того, текущий проект на работе разрастался, и меня попросили найти трех толковых ребят к себе в помощь. Другими словами говоря, я стану лидом, что меня очень воодушевляло, т.к. позволяло прокачаться в отличном от написания кода направлении.
Так собственно и произошло - я подписал договор на 2 года о распределении с компанией IBA (кстати, мне почему-то как раз в это время опять повысили зарплату… совпадение?), и привел на собеседование троих ребят, двое из которых были на том же потоке моего факультета. Все трое успешно прошли собеседование, после чего мы вместе стали работать над одним проектом.
Еще интересный момент, что на 5-ой курсе я впервые столкнулся с языком программирования Java, который шел по учебной программе. Там было 4 лабораторные работы за весь семестр, которые я сделал буквально за вечер. Вот, что значит практика на работе и учеба в университете - это абсолютно разные и несравнимые вещи. Тогда же я в который раз убедился, что поступил правильно, забив на учебу и сконцентрировавшись полностью на карьере программиста.
Экзаменов было меньше в этом семестре, и сдавали мы их на несколько недель раньше - в декабре 2013 года, чтобы поскорее начать писать дипломный проект. В качестве его темы я решил выбрать “Автоматизированная система управления ресторанами”. Времени было достаточно и для работы, и для написания дипломного проекта, потому что на заключительном семестре как таковых пар и нет. Нужно просто время от времени показывать проделанную работу и посещать преподавателей по охране труда, экономике и т.д., потому что твой дипломный проект должен быть “экономически обоснованным” и соблюдать “охрану труда”. Хотя по факту, я больше времени потратил не на написание кода приложения, а на форматирование уже готового дипломного проекта, ибо невероятно тяжело соблюдать все ГОСТы, на которые больше всего и обращали внимание преподаватели (кто захочет ревьювить код сотен студентов?).
Потом еще выяснилось, что большинство пятикурсников выгоняют из общежитий в связи с проведением чемпионата мира по хоккею в Минске в мае 2014 года. Спрос на квартиры в то время был невероятен. Каждое утро я просыпался и первым делом шел смотреть на сайты арендного жилья, ибо времени оставалось совсем немного, а любые варианты уходили как горячие пирожки. По какой-то случайности я смог найти себе комнату в трехкомнатной убитой квартире недалеко от офиса за 250$, чему еще и был невероятно рад! Как сейчас помню выражение своей мамы, которая как-то раз приехала в гости и увидела то, где я живу. Еще и наглый рыжий кот вместе с его хозяином, которые оба тырили приготовленную мной еду.
Как хорошо, что долго я в этой квартире не задержался, а в общежитиях я больше не жил…
#my_little_story
👍31❤17🔥12❤🔥1
Проблемы с перформансом приложения
Когда речь заходит о производительности приложения и поиск проблемных по перформансу мест, то любые приложения можно разбить на два основных аспекта:
- CPU, т.е. алгоритм и логика работы
- IO, т.е. операции ввода-вывода, к которым можно отнести запросы к СУБД, работу с файлами, общение с другими сервисами по различным протоколам (HTTP, gRPC, Thrift, etc)
Производя нагрузочный тест, или (что хуже) на проде, мы обнаруживаем, что у разработанного нами приложения обнаруживаются проблемы с перформансом - мы почему-то зачастую пытаемся найти ошибки в CPU.
Более того, мы пытаемся максимально оптимизировать код и думаем об ошибках перформанса ВО ВРЕМЯ разработки - тоже в CPU. Хотя подавляющее большинство backend приложений на Java не содержат очень сложной логики, а более 90% проблем связаны именно с операциями IO.
Поэтому, как я писал в посте “Баланс в принятии решений программиста” - нужно сконцентрировать свое внимание на оптимизации кода в более вероятностных местах, например, таких как:
1️⃣ Работа с СУБД, а особенно наши sql запросы, где понадобится не только хорошо знать как грамотно их писать, но и как оптимизировать их в случае возникновения проблем, анализируя планы выполнения (ибо не надо стараться оптимизировать каждый запрос и тратить на это кучу времени). Также обращать внимание на более правильную работу с ORM фреймворками, которые непосредственно связаны с СУБД, а значит могут негативно сказаться на перформансе.
2️⃣ Работа с файлами, особенно большими, где особо часто встречается утечка памяти или даже OutOfMemoryError, когда программист пытается всегда полностью считать файл в память.
3️⃣ Общение с другими сервисами ввиду распространенности микросервисной архитектуры в текущий момент, стараясь избегать блокирующих вызовов в сторону использования асинхронных (или фреймворков вроде Spring Reactive).
А с какими ты ошибками перфоманса сталкивался на своих проектах?
Когда речь заходит о производительности приложения и поиск проблемных по перформансу мест, то любые приложения можно разбить на два основных аспекта:
- CPU, т.е. алгоритм и логика работы
- IO, т.е. операции ввода-вывода, к которым можно отнести запросы к СУБД, работу с файлами, общение с другими сервисами по различным протоколам (HTTP, gRPC, Thrift, etc)
Производя нагрузочный тест, или (что хуже) на проде, мы обнаруживаем, что у разработанного нами приложения обнаруживаются проблемы с перформансом - мы почему-то зачастую пытаемся найти ошибки в CPU.
Более того, мы пытаемся максимально оптимизировать код и думаем об ошибках перформанса ВО ВРЕМЯ разработки - тоже в CPU. Хотя подавляющее большинство backend приложений на Java не содержат очень сложной логики, а более 90% проблем связаны именно с операциями IO.
Поэтому, как я писал в посте “Баланс в принятии решений программиста” - нужно сконцентрировать свое внимание на оптимизации кода в более вероятностных местах, например, таких как:
1️⃣ Работа с СУБД, а особенно наши sql запросы, где понадобится не только хорошо знать как грамотно их писать, но и как оптимизировать их в случае возникновения проблем, анализируя планы выполнения (ибо не надо стараться оптимизировать каждый запрос и тратить на это кучу времени). Также обращать внимание на более правильную работу с ORM фреймворками, которые непосредственно связаны с СУБД, а значит могут негативно сказаться на перформансе.
2️⃣ Работа с файлами, особенно большими, где особо часто встречается утечка памяти или даже OutOfMemoryError, когда программист пытается всегда полностью считать файл в память.
3️⃣ Общение с другими сервисами ввиду распространенности микросервисной архитектуры в текущий момент, стараясь избегать блокирующих вызовов в сторону использования асинхронных (или фреймворков вроде Spring Reactive).
А с какими ты ошибками перфоманса сталкивался на своих проектах?
👍23❤8🔥6❤🔥1
Для получения весомого результата нужно время
В беге - невозможно взять и моментально улучшить темп с 4:00 до 3:40 мин/км за пару тренировок. Все потому, что нужны изменения на клеточном уровне в организме человека. Чтобы образовались новые волокна в мышцах, укрепились связки и сухожилия, появились новые митохондрии и прокачалась сердечно-сосудистая система.
Программирование и любая другая интенсивная мозговая активность - не исключение. Думаю, у всех так бывало, что сегодня изучаемый материал кажется сложным или даже невозможным в понимании. А через денек-другой ты смотришь на тот же самый код или лекцию как будто новыми глазами и удивляешься, как мог не понять.
А все почему? Потому что нужно построить нейронную сеть и проложить новые связи между нейронами в мозге. Т.е. это тоже изменения на клеточном уровне, которые не моментальны и требуют времени. Более того, эти связи между нейронами строятся на основании уже имеющихся. Точно также как и все изобретения человечества создаются но основании уже существующих, потому что невозможно придумать что-то абсолютно новое - это накопительный эффект (опыт).
Это одна из основных причин, почему одному человеку дается что-то проще и быстрее, а другому - сложнее и медленнее. Вот почему так важны основы, база. Чем она лучше и прочнее - тем быстрее строятся новые связи между нейронами, быстрее нарастают мышцы и укрепляются связки, т.е. ускоряется прогресс в любом деле, будь то это спорт, изобразительное искусство или изучение Java.
Так что нужно запастись терпением и добавить немного постоянства - тогда результат точно придет!
В беге - невозможно взять и моментально улучшить темп с 4:00 до 3:40 мин/км за пару тренировок. Все потому, что нужны изменения на клеточном уровне в организме человека. Чтобы образовались новые волокна в мышцах, укрепились связки и сухожилия, появились новые митохондрии и прокачалась сердечно-сосудистая система.
Программирование и любая другая интенсивная мозговая активность - не исключение. Думаю, у всех так бывало, что сегодня изучаемый материал кажется сложным или даже невозможным в понимании. А через денек-другой ты смотришь на тот же самый код или лекцию как будто новыми глазами и удивляешься, как мог не понять.
А все почему? Потому что нужно построить нейронную сеть и проложить новые связи между нейронами в мозге. Т.е. это тоже изменения на клеточном уровне, которые не моментальны и требуют времени. Более того, эти связи между нейронами строятся на основании уже имеющихся. Точно также как и все изобретения человечества создаются но основании уже существующих, потому что невозможно придумать что-то абсолютно новое - это накопительный эффект (опыт).
Это одна из основных причин, почему одному человеку дается что-то проще и быстрее, а другому - сложнее и медленнее. Вот почему так важны основы, база. Чем она лучше и прочнее - тем быстрее строятся новые связи между нейронами, быстрее нарастают мышцы и укрепляются связки, т.е. ускоряется прогресс в любом деле, будь то это спорт, изобразительное искусство или изучение Java.
Так что нужно запастись терпением и добавить немного постоянства - тогда результат точно придет!
🔥53👍16❤12
У меня все выветривается из головы
В Java есть большая и очень важная тема - IO (Input and Output streams). Input stream - это считывание, получение данных В приложение. Output stream - наоборот, передача данных ИЗ приложения. После получения данных (Input) - мы обязательно должны обработать их в программе. Например:
- сохранить в базу данных
- передать в другое приложение
- вернуть пользователю ответ на его http запрос
- преобразовать в другой тип данных и записать в файл
А все это уже самый настоящий Output. Т.е. и Input, и Output streams очень взаимосвязаны друг с другом. В противном случае - все данные исчезнут.
Самое интересное - что наш мозг устроен похожим образом. Из-за большого количества информации в настоящее время, она практически вся фильтруется, даже если мы этого не хотим. Например, я много раз за собой замечал, что после прочтения книги мне поначалу казалось, что запомнил ее очень хорошо - но это оказывалось не так, и я забывал прочитанное с невероятной скоростью.
Поэтому если мы все-таки намерены усвоить какой-то материал - нужно ОСТАНАВЛИВАТЬСЯ и ОСМЫСЛИВАТЬ его, как это мы бы делали в приложении. Другими словами говоря, подключать Output stream.
И самый действенный способ для этого - практиковаться. Практика - это и есть извлечение информации из себя, а точнее - ее использование. Хотя даже просто подумать о прочитанном - уже многого стоит!
В Java есть большая и очень важная тема - IO (Input and Output streams). Input stream - это считывание, получение данных В приложение. Output stream - наоборот, передача данных ИЗ приложения. После получения данных (Input) - мы обязательно должны обработать их в программе. Например:
- сохранить в базу данных
- передать в другое приложение
- вернуть пользователю ответ на его http запрос
- преобразовать в другой тип данных и записать в файл
А все это уже самый настоящий Output. Т.е. и Input, и Output streams очень взаимосвязаны друг с другом. В противном случае - все данные исчезнут.
Самое интересное - что наш мозг устроен похожим образом. Из-за большого количества информации в настоящее время, она практически вся фильтруется, даже если мы этого не хотим. Например, я много раз за собой замечал, что после прочтения книги мне поначалу казалось, что запомнил ее очень хорошо - но это оказывалось не так, и я забывал прочитанное с невероятной скоростью.
Поэтому если мы все-таки намерены усвоить какой-то материал - нужно ОСТАНАВЛИВАТЬСЯ и ОСМЫСЛИВАТЬ его, как это мы бы делали в приложении. Другими словами говоря, подключать Output stream.
И самый действенный способ для этого - практиковаться. Практика - это и есть извлечение информации из себя, а точнее - ее использование. Хотя даже просто подумать о прочитанном - уже многого стоит!
👍63🔥13💯4❤🔥1
Мой Output Stream
В продолжении к предыдущему посту...
...оглядываясь назад я могу вспомнить два очень важных момента, которые невероятно сильно повлияли на мои навыки в программировании (и не только в нем конечно же, ибо все взаимосвязано). Это как два огромных “спайка” на графике моего прогресса:
Первое - это когда я начал преподавать в it-academy.
Второе - это когда я начал создавать видео на YouTube.
Оба варианта - это самый настоящий Output stream. Причем крупнокалиберный, действеннее способа которого вряд ли можно придумать.
Уже не такой мощный, но тем не менее выше на голову всех остальных способов, что я также заметил - это писать посты и статьи вроде тех, что я публикую здесь на канале DMdev talks или Instagram.
А вообще, чем больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов уходит на какое-то действие - тем сильнее закрепляется результат. Но это уже отдельная тема для следующего поста)
В продолжении к предыдущему посту...
...оглядываясь назад я могу вспомнить два очень важных момента, которые невероятно сильно повлияли на мои навыки в программировании (и не только в нем конечно же, ибо все взаимосвязано). Это как два огромных “спайка” на графике моего прогресса:
Первое - это когда я начал преподавать в it-academy.
Второе - это когда я начал создавать видео на YouTube.
Оба варианта - это самый настоящий Output stream. Причем крупнокалиберный, действеннее способа которого вряд ли можно придумать.
Уже не такой мощный, но тем не менее выше на голову всех остальных способов, что я также заметил - это писать посты и статьи вроде тех, что я публикую здесь на канале DMdev talks или Instagram.
А вообще, чем больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов уходит на какое-то действие - тем сильнее закрепляется результат. Но это уже отдельная тема для следующего поста)
👍38🔥15❤🔥3❤2
#14 Мой путь
Июнь 2014 - защита дипломного проекта, которая заняла буквально 5 минут. Так обычно и происходит в жизни, когда мы к чему-то очень долго и кропотливо готовимся, волнуемся, а это все оказывается мимолетным и заканчивается невероятно быстро. После чего возникают одни и те же мысли: и стоило ради этого так переживать! 30 июня было назначено вручение дипломов, но к этому времени нужно было успеть пройти обходной лист, без которого собственно диплом ты не получишь.
Обходной лист нужен для того, чтобы ты не остался что-то должен университету после ухода, вроде книжек в библиотеке. Но самое интересное было под последним пунктом - сняться с воинского учета. И все бы хорошо, но этот пункт имел подводный камень - кроме снятие с учета тебе выдавали повестку под роспись, что ты обязуешься явиться во второй половине лета в свой военкомат по месту прописки. И этот план, надо признать, действительно хорош, потому что продолжать учебу в магистратуре, а затем в аспирантуре я не хотел - мне с головой хватило учебы в университете. Других вариантов отсрочки от армии до 27 лет я не видел на тот момент, а именно этот возраст является в Беларуси максимальным для военнобязанных.
К счастью, на тот момент я все еще работал на гос проекте ЕГБДП и рассказал начальству о сложившейся ситуации - существует большая вероятность, что меня заберут в армию. Заказчик конечно же был заинтересован в том, чтобы ключевой человек оставался на проекте до его завершения, поэтому подготовил для меня соответсвующий документ, в котором просилось либо об отсрочке, либо о возможности резервной службы.
Служба в резерве предполагала сборы на 1-2 месяца 3 раза в течение 2-х лет, что в общей сложности получалось 4.5 месяца армии вместо 1 года, который полагался для всех ребят с высшим образованием. Естественно я выбрал резервную службу, потому что такой проект не вечен, где я бы смог получать отсрочки до 27 лет. А отслужить в армии не увольняясь из компании, да и еще во время обязательного двухлетнего распределения - звучало очень здорово. Осталось только ждать осени, ибо пока этот вопрос был решен.
Тем временем уже наступило 30 июня. Декан факультета торжественно вручил всем выпускникам дипломы, после чего мы своей группой оккупировали аудиторию в 4 корпусе БГУИР, чтобы тихонечко отпраздновать и выпить шампанское. Почему-то очень хорошо запомнился этот момент.
Далее последовал выпускной… и все, 5 лет прошло, и теперь спокойно можно выдохнуть. Начинается новый этап в жизни, который я также отметил переездом в новую двухкомнатную съемную квартиру, воспользовавшись моментом небольшого летнего спада спроса на них (чемпионат по хоккею закончился, да и студенты разъехались). Только в этот раз действительно достойную, с хорошим ремонтом, кухней и мебелью за 550$ в месяц, а не подобие сталинской коммуналки из 5 человек и рыжего кота. Правда, оплачивать одному всю стоимость было пока еще довольно накладно по бюджету, поэтому жил я с другом, вдвоем.
#my_little_story
Июнь 2014 - защита дипломного проекта, которая заняла буквально 5 минут. Так обычно и происходит в жизни, когда мы к чему-то очень долго и кропотливо готовимся, волнуемся, а это все оказывается мимолетным и заканчивается невероятно быстро. После чего возникают одни и те же мысли: и стоило ради этого так переживать! 30 июня было назначено вручение дипломов, но к этому времени нужно было успеть пройти обходной лист, без которого собственно диплом ты не получишь.
Обходной лист нужен для того, чтобы ты не остался что-то должен университету после ухода, вроде книжек в библиотеке. Но самое интересное было под последним пунктом - сняться с воинского учета. И все бы хорошо, но этот пункт имел подводный камень - кроме снятие с учета тебе выдавали повестку под роспись, что ты обязуешься явиться во второй половине лета в свой военкомат по месту прописки. И этот план, надо признать, действительно хорош, потому что продолжать учебу в магистратуре, а затем в аспирантуре я не хотел - мне с головой хватило учебы в университете. Других вариантов отсрочки от армии до 27 лет я не видел на тот момент, а именно этот возраст является в Беларуси максимальным для военнобязанных.
К счастью, на тот момент я все еще работал на гос проекте ЕГБДП и рассказал начальству о сложившейся ситуации - существует большая вероятность, что меня заберут в армию. Заказчик конечно же был заинтересован в том, чтобы ключевой человек оставался на проекте до его завершения, поэтому подготовил для меня соответсвующий документ, в котором просилось либо об отсрочке, либо о возможности резервной службы.
Служба в резерве предполагала сборы на 1-2 месяца 3 раза в течение 2-х лет, что в общей сложности получалось 4.5 месяца армии вместо 1 года, который полагался для всех ребят с высшим образованием. Естественно я выбрал резервную службу, потому что такой проект не вечен, где я бы смог получать отсрочки до 27 лет. А отслужить в армии не увольняясь из компании, да и еще во время обязательного двухлетнего распределения - звучало очень здорово. Осталось только ждать осени, ибо пока этот вопрос был решен.
Тем временем уже наступило 30 июня. Декан факультета торжественно вручил всем выпускникам дипломы, после чего мы своей группой оккупировали аудиторию в 4 корпусе БГУИР, чтобы тихонечко отпраздновать и выпить шампанское. Почему-то очень хорошо запомнился этот момент.
Далее последовал выпускной… и все, 5 лет прошло, и теперь спокойно можно выдохнуть. Начинается новый этап в жизни, который я также отметил переездом в новую двухкомнатную съемную квартиру, воспользовавшись моментом небольшого летнего спада спроса на них (чемпионат по хоккею закончился, да и студенты разъехались). Только в этот раз действительно достойную, с хорошим ремонтом, кухней и мебелью за 550$ в месяц, а не подобие сталинской коммуналки из 5 человек и рыжего кота. Правда, оплачивать одному всю стоимость было пока еще довольно накладно по бюджету, поэтому жил я с другом, вдвоем.
#my_little_story
🔥39👍15❤7
Почему конспекты не работают
Я помню, что в студенческие годы нам говорили и даже заставляли вести конспекты, без которого даже некоторые преподаватели не пускали на экзамен. Отчасти, я понимаю, почему… только, к сожалению, написание конспектов на парах не работало, по крайней мере для меня. И сейчас объясню почему.
Как я уже писал в предыдущем посте, для закрепления информации нужно подключать как можно больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов.
Начнем по порядку.
Сенсорная система человека - это то, как наша нервная система с помощью всех пяти органов чувств получает информацию извне. Другими словами говоря - это наш самый, что ни на есть, природный Input Stream. На примере написания конспекта - мы слышим преподавателя, ощущаем ручку и бумагу, видим написанное, и даже чувствуем запах чернил.
Моторика - это произвольные движения нашего тела, для которых необходимо использовать сразу несколько систем: нервную, костную и мышечную. В нашем примере с конспектами - используются ТОЧНЫЕ движения ручкой. Эта уже даже мелкая моторика, которая подключает отделы нашего головного мозга еще эффективнее (потому так полезна для детей).
Это наш природный Output Stream. И как можно догадаться, он разительно менее эффективен, чем InputStream: все-таки получать информацию мы научились в гораздо больших объемах, нежели выводить ее из себя.
К сожалению, у большинства животных моторика и сенсорные системы развиты в разы лучше, чем у человека. Но человек все-таки превосходит животных благодаря третьей составляющей - осмысливанию информации! Благодаря чему прокладываются прочные нейронные сети и выстраиваются ассоциативные связи между различной информацией.
И именно этой третьей части мне всегда не хватало на лекциях, когда я писал конспекты. Потому что времени на осмысливание информации попросту не было. Я пытался законспектировать услышанное и все. Т.е. преобразовывал Input Stream полученный из слуховой системы (СЕНСОРИКА) - напрямую в записи в тетради (МОТОРИКА) с минимально обработкой, чтобы этого было достаточно для конспектирования.
Именно по этой причине мне никогда не нравились занятия в группах и посещения лекций в универе, я всегда любил заниматься самостоятельно. Для этого я могу использовать, например, видео уроки - их всегда можно пересмотреть с нужного тебе момента, если ты не успел ОСМЫСЛИТЬ услышанное.
Поэтому если правильно использоватьэто оружие конспекты - то можно получить неплохую пользу 🙂
Я помню, что в студенческие годы нам говорили и даже заставляли вести конспекты, без которого даже некоторые преподаватели не пускали на экзамен. Отчасти, я понимаю, почему… только, к сожалению, написание конспектов на парах не работало, по крайней мере для меня. И сейчас объясню почему.
Как я уже писал в предыдущем посте, для закрепления информации нужно подключать как можно больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов.
Начнем по порядку.
Сенсорная система человека - это то, как наша нервная система с помощью всех пяти органов чувств получает информацию извне. Другими словами говоря - это наш самый, что ни на есть, природный Input Stream. На примере написания конспекта - мы слышим преподавателя, ощущаем ручку и бумагу, видим написанное, и даже чувствуем запах чернил.
Моторика - это произвольные движения нашего тела, для которых необходимо использовать сразу несколько систем: нервную, костную и мышечную. В нашем примере с конспектами - используются ТОЧНЫЕ движения ручкой. Эта уже даже мелкая моторика, которая подключает отделы нашего головного мозга еще эффективнее (потому так полезна для детей).
Это наш природный Output Stream. И как можно догадаться, он разительно менее эффективен, чем InputStream: все-таки получать информацию мы научились в гораздо больших объемах, нежели выводить ее из себя.
К сожалению, у большинства животных моторика и сенсорные системы развиты в разы лучше, чем у человека. Но человек все-таки превосходит животных благодаря третьей составляющей - осмысливанию информации! Благодаря чему прокладываются прочные нейронные сети и выстраиваются ассоциативные связи между различной информацией.
И именно этой третьей части мне всегда не хватало на лекциях, когда я писал конспекты. Потому что времени на осмысливание информации попросту не было. Я пытался законспектировать услышанное и все. Т.е. преобразовывал Input Stream полученный из слуховой системы (СЕНСОРИКА) - напрямую в записи в тетради (МОТОРИКА) с минимально обработкой, чтобы этого было достаточно для конспектирования.
Именно по этой причине мне никогда не нравились занятия в группах и посещения лекций в универе, я всегда любил заниматься самостоятельно. Для этого я могу использовать, например, видео уроки - их всегда можно пересмотреть с нужного тебе момента, если ты не успел ОСМЫСЛИТЬ услышанное.
Поэтому если правильно использовать
👍33🤔12🔥9❤1
Мое наблюдение о преподавании Java онлайн и оффлайн
В январе 2018 года, когда я только начал преподавать - я очень тщательно готовился перед каждой лекцией, чтобы понятно и доходчиво объяснить тему. А главное - ничего важного не упустить.
Конечно же я использовал для этого конспекты: память человека всегда может подвести, а вот то, что записал на листок (а значит сохранил на внешний носитель) - нет. И мне такой подход действительно очень нравился поначалу.
Как-то раз, уже во второй половине курса, одна беременная ученица не смогла прийти на мои лекции в виду того, что родился малыш. И попросила методистов it-academy записывать видео.
💭 Я еще тогда подумал: “хм, прикольно, можно же записывать лекции, чтобы даже в таких ситуациях можно было ничего не пропустить и пересмотреть”. Но на этом мысль и закончилась и никуда дальше не продвинулась.
Еще через некоторое время я начал замечать, что ребята начали снимать на камеру то, что я говорю. Видать, мысль про постоянную запись лекций пришла не только ко мне, что в принципе и не удивительно. Один парень просто приносил ноут, поворачивали камерой ко мне - и все 4 академических часа шла съемка. Далее выкладывал на YouTube и шарил ссылку в общем чате нашей группы.
Тогда я понял первый недостаток своего подхода - он все еще неудобен тем, кто слушает меня, потому что невозможно запомнить большой объем информации сразу. А мой краткий конспект удобен только мне - потому что он содержит лишь ключевые фразы, которые мне нужны, чтобы извлечь из своей памяти еще больше информации и не забыть ее рассказать.
Следующие группы с первой же лекции начинали снимать меня и выкладывать видео на YouTube. Более того, все записанные видео бывало пересматривал и я, т.к. было познавательно смотреть на себя со стороны и подмечать моменты, которые мог исправить или улучшить в будущем. Это как взгляд со стороны, обратная связь самому себе. Более того, я мог поделиться ссылкой на записанный playlist с теми, кто самостоятельно изучал Java.
Спустя годы я уже подустал повторять одно и то же. Как и любой программист - хотелось автоматизировать этот процесс. Потом еще начался covid и обучение перешло в online, где ведение живых лекций еще более исказилось и польза от online общения казалась еще менее эффективна. В тот момент и вернулась та самая идея записывать видео, тем самым вывести процесс обучения на новый уровень.
🎥 В принципе, тогда, 30 мая 2020 года, и зародился канал dmdev на YouTube и его самое первое видео.
Из очевидных плюсов записанных видео:
- возможность смотреть видео в удобнее тебе время. Не надо ехать куда-то сразу после работы, экономя время на логистику
- возможность останавливать, проматывать, пересматривать видео сколько угодно раз, чтобы ОСМЫСЛИТЬ информацию
- лектор запишет точно все, что хотел сказать, и ничего не забудет
Из минусов:
- нет возможности задать уточняющие вопросы лектору сразу по ходу видео
- нет обратной связи
Но эти минусы практически полностью решаются с помощью дополнительных созвонов с ментором (которые гораздо эффективнее проходят, ибо понятен контекст обоим сторонам) и телеграм чатов.
Присоединиться на менторство DMdev, оставив заявку по ссылке:
👉Первая ступень менторства
👉Вторая ступень менторства
Старт: конец января 2024г.
P.S. Количество мест ограничено, группы по 10-12 человек.
В январе 2018 года, когда я только начал преподавать - я очень тщательно готовился перед каждой лекцией, чтобы понятно и доходчиво объяснить тему. А главное - ничего важного не упустить.
Конечно же я использовал для этого конспекты: память человека всегда может подвести, а вот то, что записал на листок (а значит сохранил на внешний носитель) - нет. И мне такой подход действительно очень нравился поначалу.
Как-то раз, уже во второй половине курса, одна беременная ученица не смогла прийти на мои лекции в виду того, что родился малыш. И попросила методистов it-academy записывать видео.
💭 Я еще тогда подумал: “хм, прикольно, можно же записывать лекции, чтобы даже в таких ситуациях можно было ничего не пропустить и пересмотреть”. Но на этом мысль и закончилась и никуда дальше не продвинулась.
Еще через некоторое время я начал замечать, что ребята начали снимать на камеру то, что я говорю. Видать, мысль про постоянную запись лекций пришла не только ко мне, что в принципе и не удивительно. Один парень просто приносил ноут, поворачивали камерой ко мне - и все 4 академических часа шла съемка. Далее выкладывал на YouTube и шарил ссылку в общем чате нашей группы.
Тогда я понял первый недостаток своего подхода - он все еще неудобен тем, кто слушает меня, потому что невозможно запомнить большой объем информации сразу. А мой краткий конспект удобен только мне - потому что он содержит лишь ключевые фразы, которые мне нужны, чтобы извлечь из своей памяти еще больше информации и не забыть ее рассказать.
Следующие группы с первой же лекции начинали снимать меня и выкладывать видео на YouTube. Более того, все записанные видео бывало пересматривал и я, т.к. было познавательно смотреть на себя со стороны и подмечать моменты, которые мог исправить или улучшить в будущем. Это как взгляд со стороны, обратная связь самому себе. Более того, я мог поделиться ссылкой на записанный playlist с теми, кто самостоятельно изучал Java.
Спустя годы я уже подустал повторять одно и то же. Как и любой программист - хотелось автоматизировать этот процесс. Потом еще начался covid и обучение перешло в online, где ведение живых лекций еще более исказилось и польза от online общения казалась еще менее эффективна. В тот момент и вернулась та самая идея записывать видео, тем самым вывести процесс обучения на новый уровень.
🎥 В принципе, тогда, 30 мая 2020 года, и зародился канал dmdev на YouTube и его самое первое видео.
Из очевидных плюсов записанных видео:
- возможность смотреть видео в удобнее тебе время. Не надо ехать куда-то сразу после работы, экономя время на логистику
- возможность останавливать, проматывать, пересматривать видео сколько угодно раз, чтобы ОСМЫСЛИТЬ информацию
- лектор запишет точно все, что хотел сказать, и ничего не забудет
Из минусов:
- нет возможности задать уточняющие вопросы лектору сразу по ходу видео
- нет обратной связи
Но эти минусы практически полностью решаются с помощью дополнительных созвонов с ментором (которые гораздо эффективнее проходят, ибо понятен контекст обоим сторонам) и телеграм чатов.
Присоединиться на менторство DMdev, оставив заявку по ссылке:
👉Первая ступень менторства
👉Вторая ступень менторства
Старт: конец января 2024г.
👍24🔥9❤🔥5
Вопрос 👆 - Ответ 👇
Довольно часто задают мне этот вопрос. И в основном, как не удивительно, его задают те, кто математику не очень хорошо понимает, но хочет стать программистом.
Давайте разбираться…
По сути задача программиста - преобразовывать логику в машинный код, который автоматизирует ее и сможет выполнять для миллионов пользователей. Поэтому каждая строчка кода приложения - это логика! Каждая инструкция, каждая операция ветвления, каждый цикл, каждый созданный массив, по которому далее ты будешь проходиться циклом и отфильтровать значения по каким-либо условиям - это все логика.
Теперь самое интересное: математика целиком и полностью построена на логике. Это как следующий уровень после логики. Математика развивает мышление, учит анализировать и систематизировать знания, учит мыслить абстрактно и конечно же ЛОГИЧЕСКИ!
По сути я в предыдущем предложении перечислил все то, что использует программист во время написания приложений.
Надо понять одну простую истину:
И в случае программирования - это в первую очередь логика.
❓Поэтому, отвечая на вопрос нужно ли знать программисту математику?
Ответ нет. Программирование не строится на ней.
❓Хорошо бы знать программисту математику?
Ответ да. Ибо транзитивно математика прокачает ключевые навыки для программиста.
#dmdev_qa
Довольно часто задают мне этот вопрос. И в основном, как не удивительно, его задают те, кто математику не очень хорошо понимает, но хочет стать программистом.
Давайте разбираться…
Что самое важное в любом приложении? Конечно же это логика его работы.
По сути задача программиста - преобразовывать логику в машинный код, который автоматизирует ее и сможет выполнять для миллионов пользователей. Поэтому каждая строчка кода приложения - это логика! Каждая инструкция, каждая операция ветвления, каждый цикл, каждый созданный массив, по которому далее ты будешь проходиться циклом и отфильтровать значения по каким-либо условиям - это все логика.
Теперь самое интересное: математика целиком и полностью построена на логике. Это как следующий уровень после логики. Математика развивает мышление, учит анализировать и систематизировать знания, учит мыслить абстрактно и конечно же ЛОГИЧЕСКИ!
По сути я в предыдущем предложении перечислил все то, что использует программист во время написания приложений.
Надо понять одну простую истину:
знание не бывает в вакууме, оно обязательно цепляет другие сферы, которые жизненно необходимы для усвоения этого нового знания
И в случае программирования - это в первую очередь логика.
❓Поэтому, отвечая на вопрос нужно ли знать программисту математику?
Ответ нет. Программирование не строится на ней.
❓Хорошо бы знать программисту математику?
Ответ да. Ибо транзитивно математика прокачает ключевые навыки для программиста.
#dmdev_qa
🔥33👍11❤🔥3❤1