Телеграм канал 'Java кабала'

Java кабала


11'910 подписчиков
5'704 просмотров на пост

Рассказываю про мир Java разработчиков. Делюсь опытом. Выкладываю обучающие материалы

Детальная рекламная статистика будет доступна после прохождения простой процедуры регистрации


Что это дает?
  • Детальная аналитика 263'245 каналов
  • Доступ к 119'495'377 рекламных постов
  • Поиск по 472'672'485 постам
  • Отдача с каждой купленной рекламы
  • Графики динамики изменения показателей канала
  • Где и как размещался канал
  • Детальная статистика по подпискам и отпискам
Telemetr.me

Telemetr.me Подписаться

Аналитика телеграм-каналов - обновления инструмента, новости рынка.

Найдено 26 постов

Хз почему, но native comments нихрена не работают. В общем, комменты по посту пишите сюда
PS пидр тот, кто не пишет javadoc
Java doc - неотъемлемая часть нашего кода. Код всегда пишется исходя из задачи. Но есть такое понятие, как intention (намерение) разработчика, и зачастую не понятно, почему код написан именно так, и никак иначе. Возникает вопрос: "что имел ввиду тот, кто писал этот код"? Может он знал что-то, чего не знаю я? А может наоборот, и это просто ошибка или упущение разработика? Почему он сделал проверку здесь? Почему входной параметр не может быть отрицательным и т.д.?

Intention это часть проблемы. Другая ее часть заключается в понимании того, как работать с кодом, который написан другим разработчиком. Какой пререквизит нужен, чтобы его код работал корректно? Является ли он потокобезопасным? Какие входные параметры являются валидными, а какие нет? Что будет, если отправить в метод невалидный параметр? Может ли метод вернуть null и нужно ли мне делать на это проверку? На все эти вопросы отвечает контракт. Контракт - это описанное вашего функционала - описание пакета, класса, метода. Описание всех граничных случаев (corner cases). Контракт - это документация к вашей "кофемашине". Прежде чем пользоваться чем либо мы читаем документацию, чтобы понять, как это делать правильно, и что требуется для этого. Так же и с кодом - мы не должны вскрывать его и разбираться в тонкостях реализации (вы же не разбираете кофемашину, чтобы понять, как ее чистить от накипи). Качественно написанный код не требует этого. Он должен быть хорошо задокументирован и описывать все возможное случаи использования. Если вы не можете их описать - скорее всего, потому что вы сами толком не знаете, как работает ваш код. Если вы пишете качественный код - вы знаете для чего он написан. В каких случаях он работает, а в каких нет. Вы можете дать гарантию на его работоспособность при различных обстоятельствах.

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

P.S. Не ограничивайте себя только документацией. Используйте всю мощь статического анализатора, а так же общепринятых конвенций. Пользуйтесь наработками JSR-305. Читайте и разбирайтесь в том, как работает код в крупных opensource проектах. Какие решения они используют там.
Видео/гифка, 7 сек, video.mp4
Лайфхак, как найти любую книгу.
1. Заходите в вк
2. Заходите во вкладку "Файлы"
3. В поиске вбивайте интересующую вас книгу
4. Выберете подходящую
Видео/гифка, 23 сек, video.mp4
Книги, которые дадут вам +100 к знанию Java.
Если вы прям нулевой, тогда Head First то, что вам нужно.
Если есть немного технического бэкграунда, тогда Шилдт.
Чистый код Роберта Мартина нужно прочитать всем!
Управление зависимостями.

В прошлом сообщении я рассказывал про Maven. Там говорилось про то, что он помогает нам управлять зависимостями, на что были замечания о том, что не понятно, что это значит.

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

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

Давайте подумаем, как бы мы подключили библиотеку, если бы не было Maven? Ответ очевиден - мы бы нашли нужную нам библиотеку в интернете, скачали бы ее (это просто Java архив - jar) и положили бы этот архив в наш проект. Профит - у нас есть готовый кусок функционала, который протестирован и проверен тысячами других разработчиков.

Но как же Maven делает это за нас?
Существуют так называемые репозитории артефактов. Если публичные, есть приватный. Нас на данном этапе существуют только публичные. Из публичных можно выделить самые крупные: Central, Atlassian, Spring Plugins и др.
Большинство opensource библиотек хранятся именно в этих репозиториях. По умолчанию, Maven будет искать вашу библиотеку именно в Central репозитории. На данный момент там находится порядка 7,5 млн библиотек. Любой уважающий себя разработчик, который создает opensource решение загружает его на Maven Central.

Так как же Maven находит именно то, что вам нужно среди миллионов других?
Все просто - каждая библиотека имеет свой уникальный индекс. Он формируется из трех параметров: groupId, artifactId, version.
Начнем по порядку:
groupId - идентификатор группы. Это нечто, что характеризует вас или вашу компанию. Здесь принято указывать название вашего домена, только наоборот. Например: com.google или org.springframework. Это дает гарантию, что никто не будет загружать артефакты с идентификатором группы, который ему не принадлежит.
Если у вас нет домена, но вы хотите загрузить свою библиотеку Maven Central, то подойдет ваш github. В моем случае это com.github.kabal163

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

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

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

Пример моей библиотеки:

com.github.kabal163
state-machine
0.4.2


Ссылочка на maven репозиторий: https://mvnrepository.com/artifact/com.github.kabal163/state-machine/0.4.2
Ссылочка на github: https://github.com/Kabal163/akuna-state-machine
Web-страница:
GitHub - Kabal163/akuna-state-machine
Contribute to Kabal163/akuna-state-machine development by creating an account on GitHub.
Видео/гифка, 18 сек, video.mp4
Ребят, накидайте плз идей для тикток. А то продолжу хуйню снимать😘
Maven - фреймворк для автоматизации сборки проектов. Является декларативным - мы описываем в виде XML то, что мы хотим от него.
Помимо Maven есть и другие сборщики. Наиболее популярные для Java: Gradle и Ant (но этого мамонта я никогда не встречал).

Основные задачи, которые решают подобные фреймворки:
1. Управление зависимостями
2. Компиляция
3. Сборка
4. Тестирование
5. Деплой артифактов
6. Генерация документации

Это похоже на pipeline ci/cd, только упрощенный (так сказать подпроцесс).
Все это реализовано в виде жизненных циклов и фаз, в рамках каждого жизненного цикла.
Существуют три стандартных жизненных цикла - clean, default, site.
В каждом жизненном цикле есть фазы, которые исполняются при выполнении жизненного цикла в заранее определенном порядке.

Например, в жизненном цикле clean есть три фазы: pre-clean, clean, post-clean. Я всегда пользуюсь только clean. Эта фаза удаляет все артифакты, которые были созданы в процессе предыдущей сборки.

Жизненный цикл default поинтереснее. В нем есть много фаз. Расскажу про те, которыми пользуюсь сам:
- compile
- test
- package
- install
- deploy

compile - компилирует ваш проект.
test - запускает тесты и выдает отчет
package - упаковывает ваш проект в соответствующий артифакт. В моем случае это всегда jar
install - устанавливает артифакт в локальное хранилище (например, если это библиотека, тогда вы сможете ей пользоваться локально в других проектах)
deploy - загружает артифакты в удаленный репозиторий (например nexus или artifactory)

Не забываем о том, что Maven замечательно (почти всегда) управляет нашими зависимостями и их версиями. В общем, это мой любимый фреймворк. На работе мы используем Gradle, но в собственных проектах я всегда использую Maven.
Умных постов вам в ленту! Можете повыебываться перед друзьями.
Сейчас расскажу вам что такое кластер и какими они бывают.

Кластеры бывают двух типов - физические и виртуальные. Это просто объединение нескольких узлов (физических или виртуальных) в один логический.

Что такое узлы, так еще и виртуальные? Все просто - узел это просто какая-то железка (либо виртуалка). В нашем случае, это сервер, компьютер. Сервер может быть физическим (чаще всего гипервизор) либо логическим - VM (virtual machine). Когда нам не интересны детали реализации сервера, мы будем называть их узлами.
Окей, теперь мы знаем, что такое физические и виртуальные узлы. А что на счет одного логического?
Представьте себе, что вы хотите взаимодействовать с этой армией серверов через единый интерфейс, как будто, вы взаимодействуйте с одним очень мощным сервером. Например, вы говорите - разверни мне приложение. И пусть логический узел сам решит, где и как его развернуть.
Это и называется кластером. Объединение нескольких узлов в один логический с единой точкой входа.
Братишки, кто хочет помимо Java освоить фронт энд технологии, посмотрите канал моего хорошего знакомого: https://t.me/evstratov_online
С ним уже некоторые из вас знакомы - это с ним мы замутили интервью на ютубе) скоро сделаем еще что-нибудь интересное.
Web-страница:
Евстратов на связи IT 🛸
Канал про мобильную и веб разработку. Рассказываю про свои приложения, снимаю обучающие видео и интервью.
Если вы все еще думаете, что программирование, это неимоверно сложно, то подумайте о том, что синтаксис Java состоит из 50 слов из которых даже я некоторых не знаю, потому что никогда не использую.
Структура кода состоит всего из трех базовых вещей: класс, переменная, метод.
Все остальное - дело техники и углубления в изучение.
Если бы мы жили в 80х годах, я бы сказал, что программирование пиздец какое сложное. Но мы живем в 2021, и сейчас, чтобы решать рядовые задачи не нужно иметь семь пядей во лбу, или где там... Захотите стать рок звездой программирования - пожалуйста, углубляйте ваши знания, и решайте задачи, которые другие не могут решить. Вы будете топовым разработчиком. Но не всем это нужно. Многим, достаточно просто стать разработчиком и в ус не дуть.
Поэтому запомните, сегодня, стать разработчиком не сложнее, чем стать любым другим специалистом. Вы сможете решать рядовые задачи и приносить бабки бизнесу. Пока мы можем это делать - у нас есть работа. Программирование само по себе не имеет никакого смысла, если оно не решает какую-то проблему.
Поэтому не бздите ничего. Жизнь одна. Если хотите знать - учите. Нравится - делайте.
Давайте ка я немного расскажу вам про то, что такое git.
Сначала немного сухости из википедии: распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.

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

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

2. Я работаю над кусочком программы, а мой коллега работает над другим кусочком этой же программы, но очень часто случается так, что мы должны использовать кусочки кода друг друга. Мне нужны кусочки его кода, а ему кусочки моего. Но как сделать так, чтобы мой код, который находится на моем компьютере появился на его компьютере и наоборот? Очевидно, я должен каждый раз ему его как-то передавать, а он мне. Немного ебала, учитывая то, что мы меняем код по сто раз на день, и то, что я ему дал пару часов назад, может быть уже не актуальным. А теперь еще хуже - у нас целая команда разработчков, или еще хуже - целый трайб разработчиков (много команд). Все одновременно меняют кодовую базу. Это просто нереально что-то кому-то передавать.

3. Если мы работаем над одним участком кода одновременно, то у нас появляются конфликты. Я переделал строчку кода, а коллега ее и вовсе удалил. Что считается актуальным? Как это объединить в единое целое?

Эти проблемы решает "Система Контроля Версий". Git - это один из вариантов такой системы. Есть и другие, но git самый распространенный.

В системе контроля версий есть такое понятие как ветка.
Представьте, что вы разработчик, который начинает с нуля писать код. Вы накидали немного кода, и "сохранили" его в основную ветку (такая ветка называется master). Но эта ветка все равно пока что находится только у вас на компьютере. Тут приходят на помощь хостинги IT-проектов. Примеры таких хостингов: GitHub, GitLab, Bitbucket. Они позволяют загружать ваш код на сервера хостера, откуда ваш код может "скачать" любой ваш коллега. Делается это очень удобно - нажатием пары кнопок.

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

Осталось решить последнюю проблему: проблема конфликтов. Git помогает решать эти благодаря тем самым веткам. Дело в том, что всегда существует главная ветка (master) - в которой находится рабочий код. Если мы хотим сделать какие-то изменения, то мы отводим новую ветку от master. Это будет точная копия главной ветки (короче, все равно что сделать копию проекта, и работать с копией, а не с основным проектом). В своей ветке вы делаете изменения, которые вам нужны и потом "сливаете" их в основную ветку. Этот процесс называется merge (мёрж). Гит за нас автоматически применит изменения из нашей ветки (копии) к основной ветки. И если вдруг случится так, что гит обнаружит, что код в основной ветки уже кем-то другим был изменен, то выдаст нам конфликт, и заставит его решить. И только после этого, мы сможем слить наши изменения в основную ветку.

Подробнее можно посмотреть тут: https://www.youtube.com/watch?v=PEKN8NtBDQ0&list=PLY4rE9dstrJyTdVJpv7FibSaXB4BHPInb
Web-страница:
Git - для новичков - #1 - основы
Освой профессию frontend-разработчика за 6 месяцев и становись востребованным IT-специалистом со знанием топовых технологий и 5 крутыми проектами в портфолио:
https://loftschool.com/professions/frontend-developer?utm_source=youtube&utm_medium=article&utm_campaign=git1

Для чего нужны системы контроля версий и какими они бывают. Почему именно Git.

Личный канал автора: https://www.youtube.com/user/kovaldn/

Больше уроков от lofblog: #loftblog
Все уроки по хештегу: #loftblogGit
Полезные уроки для веб-программиста: #вебпрограммист
#Git
______________________________

Понравилось?

ГДЕ С НАМИ ПООБЩАТЬСЯ
⚡️Школа онлайн-образования: https://loftschool.com/
⚡️Telegram Loftblog: https://t-do.ru/loftblog
⚡️Telegram IT-обучение: https://t-do.ru/it_loft
⚡️Группа вконтакте: http://vk.com/loftblog

Поставь лайк! Больше лайков - лучше выпуски :)
Неплохой ресурс для подготовки к собеседованию: https://javastudy.ru/reference/interview/

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

Например, такие вещи как JSP, JSF и Servlet уже не актуальны
Web-страница:
Всё для собеседования по Java
Коллекция материалов для прохождения собеседования по Java.

Найдено 26 постов