Java кабала

Ночь бэкендеров в Яндекс Банке Собеседования — это долго, скучно, иногда мучительно и не всегда понятно. Как вообще можно понять за пару часов, хочешь ли ты работать где-то в ближайшие пару лет? Поэтому в Финтехе Яндекса придумали кое-что получше — препати для тех, кто хочет взять компанию на тест-драйв. Можно бесконечно смотреть отзывы на Хабр Карьере, но лучше один раз увидеть всё своими глазами. Ребята организуют подобные встречи уже не в первый раз, и в октябре собирают бэкендеров — чтобы совместить приятное с полезным: лично познакомиться с командой и руководством, услышать о продуктах в разработке от первых лиц, прошвырнуться по офису, подышать яндексовым воздухом и вообще приятно провести пятничный вечер. Кормить будут. Вкусно. Поить тоже — бар прямо в офисе. А в промежутках между разговорами о невыносимой лёгкости бэкенд-бытия можно будет порубиться в PS5 с коллегами по цеху, выведать все инсайды у продакт-оунера и просто почилить. Если ты не в Москве, собирай чемоданы — ребята не будут дразнить кутежом в зуме, а купят билет и организуют трансфер. P.S.: дресс-кода нет, но есть задачка с кодом. Если ты действительно бэкендер, то решишь её без труда и приглос у тебя в кармане! Подробности 👉 тут.

​​Затронув тему библиотек, вкратце расскажу, что такое groupId, artifactId и version, и для чего это нужно. Это конвенции, которые принято соблюдать при публикации java библиотек. Эти три компонента служат для того, чтобы можно было однозначно идентифицировать библиотеку на просторах интернета. Т.е. эти три компонента в совокупности являются уникальным идентификатором библиотеки. groupId - это "идентификатор группы". Но что же на самом деле это такое? По факту это ваш домен. Например, если у вас есть организация mycompany и у вас есть собственный домен, например mycompany.ru, тогда вы можете использовать его в качестве groupId, только в зеркальном виде - ru.mycompany, что, собственно, логично, т.к. это помогает сортировать артифакты по уровню домена. Что если у вас нет собственного домена? Maven central разрешает использовать адреса ваших github аккаунтов. Да, это валидно, если вы его подтвердите. Например, если мой гитхаб github.com/Kabal163, тогда groupId будет выглядить так: com.github.kabal163. Помимо вашего домена, в группу могут входить дополнительные части, которые помогают идентифицировать, например, направление разработки или продукт. Опять таки, пример: у меня есть компания, и в ней несколько направлний разработки. В каждом направлении у меня есть множество библиотек. Чтобы идентифицировать их, я могу сделать так: ru.mycompany.security ru.mycompany.web ru.mycompany.reactive Таким образом, мы уже гарантируем, что никто в мире не сможет загрузить в публичный репозиторий библиотеку с таким же groupId как у вас (если только раньше этот домен не принадлежал кому-то еще). artifactId - это непосредственно название вашей библиотеки, вашего артефакта. Например: commons-lang3 lombok spring-web version - это версия вашей библиоткей. Конвеция по версии выглядит следующим образом: 0.1.12 На самом деле это не обязательно и вы можете писать тут что угодно, но это гуд практиз. Про версию подробнее напишу в следующем посте. Каждый раз, когда вы изменяете вашу библиотеку, вносите исправления или добавляете новые фичи, у вас будет меняться версия. И вы каждый раз будете заново публиковать вашу библиотеку, только с новой версией. Таким образом, мы всегда имеем уникальный идентификатор библиотеки, по которому можем однозначно идентифицировать ее среди миллионов других.

​​В продолжение предыдущей темы: как подключать библиотеки. В Java есть отличный механизм для работы с библиотеками - Maven. Эти ребята сделали множество конвенций, благодаря которым у нас все работает из коробки. Вообще, чтобы разобраться с тем, как мы подключаем библиотеки (их еще называют зависимостями), давайте разберемся, а от куда же они берутся. Давайте представим, что мы хотим создать библиотеку, что нам нужно? Ну очевидно, в первую очередь написать исходный код - это непосредственно код нашей библиотеки. Ну окей, написали. Теперь нам нужно покрыть это дело тестами - но вот не задача, чтобы написать тесты, нам нужны зависимости в виде других библиотек, типа junit, spock, mockito и др. Хаха, давайте сачканем, и пока пропустим тесты (но только в этом случае). Что дальше? Нам нужно скомпилировать все наше добро - ну ок, у нас вроде есть javac. Но что толку с кучи скомпилированных классов? Нам нужно их упаковать! Упаковать в JAR (Java Archive). Вы скажете: «Ну окей, руками создам архив и все туда сложу». Как бы да, никто не запрещает этого вам сделать, но дальше начинается самое интересное - нам нужно опубликовать нашу библиотеку. Это разумеется, тоже можно сделать руками, но вы скорее застрелитесь, чем будете после каждого изменения все перчечисленные действия производить руками! На помощь к нам приходят системы по автоматической сборке проектов - Maven или Gradle. Вот о них-то вам и нужно будет почитать и разобраться как они работают. Maven попроще для старта, Gradle попизже. В общем, чем пользоваться - решать вам. В чем суть - эти ребята автоматизируют сборку проекта. Они компилируют проект, запускают тесты, упаковывают все в JAR и публикуют его в репозитории (о репозиториях далее). Замечательно, мы написали библиотеку, в ней использовали Maven либо гредл, которые нам как минимум все скомпилировали и упаковали в JAR. Супер, у нас есть артифакт. Фактически, этот JAR вы уже можете дать своему товарищу, чтобы тот подключил его к проекту, но это полная дичь, и мы так делать не хотим. Мы хотим, чтобы все было автоматически. Для этого нам необходимо разместить нашу библиотеку в репозитории. Что же такое этот репозиторий? Помните, вначале я сказал, что Maven придумали множество различных конвенцией? Так вот, репозитории это их рук дело. Физически репозиторий это директория на файловой системе. Т.е. у вас на компе есть «локальный репозиторий». Он есть у всех и создается автоматически. Находится в хоум директории в папке .m2 Вы всегда можете опубликовать ваш JAR в свой локальный репозиторий. Но в чем прикол спросите вы? Как ваш коллега тогда подключит библиотеку в свой проект, если один фиг она только на вашем компе? Все верно - никак. Локальные репозитории нужны для кеширования внешних скачанных библиотек и для отладки своих библиотек. Оказывается, существуют еще некие «удаленные репозитории» (не от слова delete, а от слова remote). Удаленный репозиторий - это сервер, на котором можно хранить JAR. У него есть определенный API по которому с ним можно взаимодействовать и загружать на него свои библиотеки, и скачивать нужные вам. Я думаю, вы уже начали догадываться, что тот кто пишет проект и хочет подключить вашу библиотеку к себе, тоже должен собирать свой проект при помощи Maven или Gradle. Эти ребята умеют взаимодействовать как с локальными, так и с удаленными репозиториями и умеют там находить зависимости, которые вам нужны. Для того, чтобы объяснить Maven или Gradle о том, что вам нужно подключить библиотеки (зависимости) к проекту - в специальном конфигурационном файле нужно объявить секцию dependencies в которой вы пишете полное название с версией нужно вам бибилиотеки - groupId, artifactId и version. Да, да, это тоже конвенции Maven. Вуаля, система по автоматической сборке проектов найдет в удаленном репозитории нужную вам библиотеку и скачает ее в ваш локальный репозиторий, а умная IDE увидит ее и вы без проблем сможете ей воспользоваться.

​​И так значит... библиотеки... Буквально вчера я написал о том, чтобы вы не делали свои велосипеды и использовали готовые решения - библиотеки. Я ожидали кучу реакций... а вы оказывается, не знаете что это такое. Давайте исправлять. Библиотека - это готовый кусок кода, который за нас с вами кто-то написал, протестировал, скомпилировал, упаковал в jar и опубликовал в публичном репозитории. Теперь, все что нам с вами нужно сделать - это просто взять и подключить эту библиотеку к своему проекту (как это сделать, расскажу в следующей статье). Давайте представим, какую проблему может решить библиотека? Например, у нас есть проект, и в проекте мы хотим проверять строки на пустоту. Например, если нам пришла пустая строка, тогда мы будем кидать исключение IllegalArgumentException. Но что такое пустая строка? null? empty? или пробельная строка? а переносы строк и табуляция? В общем, если вы имеете ввиду все вышеперечисленное, тогда речь идет именно про BLANK строку. Чтобы самому не писать метод, который делать такое большое количество проверок, мы можем найти библиотеку, в которой уже есть такой метод. Мы находим такую библиотеку, подключаем ее к нашему проекту и вуаля. Мы можем использовать этот метод. Пример такой библиотеки - org.apache.commons:commons-lang3. Вся прелесть в том, что это не просто наш с вами велосипедик. Как правило, самые популярные библиотеки разрабатываются большим комьюнити и там мало того, что используются лучшие практики, так еще и учтены все возможные корнер кейсы. Да и протестировано все вдоль и поперек. Поэтому, когда в очередной раз вы подумайте о том, что вам нужно написать какой-нибудь "умный, универсальный" метод, попробуйте погуглить, а нет ли такого уже на просторах интернета.

​​Прежде, чем писать свои собственные костыли, обязательно проверьте, нет ли уже готовой библиотеки, которая решает ваши проблемы. Пример Apache Commons: огромное количество утилитных библиотек на все случаи жизни https://commons.apache.org/ Часто использую: Lang, Collections, IO

​​Эстафета с исключениями Если вы уже дошли до исключений в Java, тогда предлагаю закрепить эту тему небольшим практическим заданием. Давайте организуем соревнования – передачу эстафетной палочки. Что нам для этого нужно? Наверное, нам понадобится две сущность – эстафетная палочка и спортсмен. Давайте сделаем несколько спортсменов (штук 10), сделаем одну палочку и пусть они передают ее друг другу. У них при этом будет 2 метода: 1. Безопасная передача палочки. Палочка передается, и мы считаем, что ничто не предвещает беды. Однако спортсмен может споткнуться и упасть во время бега, тогда должно быть выкинуто исключение. Подумайте, какого типа тут должно быть исключение (check или unchecked). 2.Рисковая передача палочки – это когда спортсмен еще не добежал до своего товарища и швыряет ему эту палочку. Тогда другой спортсмен может не поймать ее. Подумайте, какого типа тут должно быть исключение. Эти два метода должны выкидывать исключение с вероятностью 20%. Не забудьте в main методе обработать исключения.

GC - Garbage Collection или сборка мусора. В Java, как и во многих других современных языках, существует механизм автоматизированного управления памятью. Это значит, что нам не нужно руками освобождать память, если она нам больше не нужна. За нас это сделает Garbage Collector. Для тех, кто уже начал интересоваться этой темой, рекомендую прочитать: 1. Оракловую документацию - https://docs.oracle.com/javase/9/gctuning/introduction-garbage-collection-tuning.htm 2. Визуализация алгоритмов сборки: https://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/ Для более продвинутых - отличная статья, рассказывающая про важность memory locality и как это влияет на производительность: https://www.cs.cornell.edu/courses/cs3110/2014sp/lectures/26/memory.html

Ищем джависта, бэйби! А что ты сделал на Java в свои годы? Предлагаем заняться кое-чем большим и важным: помочь нам создать современный, технологичный и человечный мобильный банк — Яндекс Банк. Мы запускаемся уже в этом году и продолжаем набирать отряд первых. Что нужно делать? Надеемся, это ты нам расскажешь, для этого мы и ищем толковых ребят. Ну а если конкретно: практически с нуля разрабатывать продуктовый движок, бизнес-логику и инфраструктуру финтех-сервисов. Главное — работать головой, а не по 12 часов. Яндекс Финтех — это маленькая команда внутри большой компании. У нас есть, где развернуться, но нет риска превратиться в тыкву, как это часто бывает со стартапами. С нас — отсутствие стоячего болотца рутинных задач и безумной бюрократии. С тебя — опыт на боевых проектах и одна простая задачка.

​Хочу немного вам рассказать о том, что такое Javadoc и для чего он нужен. Java doc - неотъемлемая часть нашего кода. Код всегда пишется исходя из задачи. Но есть такое понятие, как intention (намерение) разработчика, и зачастую не понятно, почему код написан именно так, и никак иначе. Ведь любую задачу можно решить кучей различных способов, при этом результат будет тем же. Возникает вопрос: "что имел ввиду тот, кто писал этот код"? Почему он сделал именно так? Может он знал что-то, чего не знаю я? А может наоборот, и это просто ошибка или упущение разработчика? Почему он сделал проверку здесь? Почему входной параметр не может быть отрицательным и т.д.? Intention это часть проблемы. Другая ее часть заключается в понимании того, как работать с кодом, который написан другим разработчиком. Какой пререквизит нужен, чтобы его код работал корректно? Является ли он потокобезопасным? Какие входные параметры являются валидными, а какие нет? Что будет, если отправить в метод невалидный параметр? Может ли метод вернуть null и нужно ли мне делать на это проверку? На все эти вопросы отвечает контракт. Контракт - это описание вашего функционала - описание пакета, класса, метода. Описание всех граничных случаев (corner cases). Контракт - это документация к вашей "кофемашине". Прежде чем пользоваться чем либо мы читаем документацию, чтобы понять, как это делать правильно, и что требуется для этого. Например, я всегда обращаюсь к документации, прежде чем запускаю процесс очистки от накипи. Так же и с кодом - мы не должны вскрывать его и разбираться в тонкостях реализации (вы же не разбираете кофемашину, чтобы понять, как ее чистить от накипи). Качественно написанный код не требует этого. Он должен быть хорошо задокументирован и описывать все возможное случаи использования. Если вы не можете их описать - скорее всего, потому что вы сами толком не знаете, как работает ваш код. Если вы пишете качественный код - вы знаете для чего он написан. В каких случаях он работает, а в каких нет. Вы можете дать гарантию на его работоспособность при различных обстоятельствах. Качественной документацией вы экономите тонну времени другим разработчикам, которые в будущем будут работать с вашим кодом. Когда на проде всплывает критичный баг, нет времени на то, чтобы сидеть и разбираться в том, как написан ваш код, делать сотни догадок о ваших намерениях и строить гипотезы на различные корнер кейсы, в которых ваш код будет работать или нет. Проблему нужно решать здесь и сейчас. Чем быстрее мы это сделаем, тем лучше для всех. Копание и корпение над чужим кодом не дает никакого инкремента, никакого value (если только вы не делаете этого в ваше личное время для саморазвития). P.S. Не ограничивайте себя только документацией. Используйте всю мощь статического анализатора, а так же общепринятых конвенций. Пользуйтесь наработками JSR-305. Читайте и разбирайтесь в том, как работает код в крупных open source проектах. Какие решения они используют там.

Ловите новенький видосик 😘

Кабальчики, нашел хороший канал @steponeit. Чувак делится своим опытом и рассказывает очень интересные вещи, включая разработку на c#. Кстати, до этого я натыкался на его статьи на хабре) Подписывайтесь, рекомендую 👍 https://t.me/steponeit

​Недавно в инсте задавал вопрос: "Чем отличается компилятор от интерпретатора"? По большому счету я не получил ни одного правильного ответа, за исключением такого: "компилятор - компилирует, интерпретатор - интерпретирует". Как бы ни казалось это смешным, но ответ вполне приемлемый, т.к. они отвечают за два совершенно разных процесса. Что делает компилятор - компилирует. Его задача преобразовать / конвертировать код из человекочитаемого формата в нечто, что понятно кому-то другому (машине / интерпретатору). Это значит, что компилятор работает до того, как мы с вами запустим нашу программу. Все дело в том, что для компьютера наш код (то, что мы написал) - это филькина грамота. Он не понимает этот код. Компьютер / машина понимает лишь машинный код. Для этого и нужен компилятор - он преобразует понятный человеку код в код, понятный машине (НО НЕ В СЛУЧАЕ С JAVA!). С Java все немного интереснее. Компилятор Java (javac) преобразует человекочиаемый код (исходники) в код, понятный интерпретатору (байт код). А вот интерпретатор уже будет интерпретировать его в машинный код прямо в момент выполнения программы. А кто же в случае с джава этот самый интерпретатор? Это наш JVM! Зная это, мы уже понимаем, как работает интерпретатор - его задача взять код, который непонятен машине, и транстлировать его в понятный для машины. Интерпретаторы работают не только с байт кодом как в Java. Если мы говорим про другие языки программирования, то там интерпретаторы могут интерпретировать сразу исходный код (человекочитаемый) в машинный, пропуская шаг компиляции. Итого: Компилятор преобразует исходный код в машинный код, либо в байт код (в случае с java). Интерпретатор - интерпретирует исходный код, либо байт код в машинный код, прямо в момент выполнения программы (когда программа работает. Собственно она и работает благодаря этому)

У нас много новых подписчиков, и я опять начал получать вопросы "как я стал программистом" 😃 Чтобы не рассказывать все это еще раз - вот видосик, в котором я все рассказываю) https://www.youtube.com/watch?v=S40xF3spUKM

10к подписчиков! ❤️🔥

Вы мне постоянно пишете "где брать задания для практики"? Для тех из вас, кто только постигает или уже постиг тему ООП микро проект: Давайте создадим фибрику супергероев. Что я хочу видеть: 1. Должна быть фабрика (соответственно класс), который умеет создавать супергероев. 2. Фабрика должна уметь создавать разных супергероев – бэтмэн, аквамэн, халк, человек-паук, рассомаха, супермен. 3. У каждого супергероя должно быть имя, уровень силы по 10ти бальной шкале и признак принадлежности к лейблу: DC или Marvel. 4. У каждого героя должна быть какая-то суперспособность. Пусть это будет обычный вывод в консоль. Например, у бэтмэна «Ааа, я бэтмэн!». Сомнительная суперспособность, но нас устроит. Задание со звездочкой: Создать арену гладиаторов. На арену можно отправлять двух супергероев. Победитель должен определяться в зависимости от того, какой супергерой сильнее. Имя победителя нужно выводить в консоль. При этом, когда супергерои дерутся, они должны использовать свои суперспособности. Задание с двумя звездочками: Можете добавить уровень неопределенности в то, какой супергерой победит. Иначе, если всегда будет побеждать супергерой, у которого уровень силы больше, то это не очень интересно. В жизни бывает так, что сильнейший не всегда побеждает.