Java кабала

Кто читает комменты под моими видео ни раз видел фразу типа "рынок айти перенасыщен", "работу сложно найти" и т.д. Я специально сегодня на один день открыл своё резюме, чтобы проверить, сколько компаний со мной свяжутся. Завтра выложу видео об этом. А пока закидон: напишите в комментариях, сколько компаний со мной связалось. 😂

Я удивлен, но оказывается, многие не знаю про наш чат, где мы обсуждаем именно тему Java и ИТ (Discussion) Вот он - https://t.me/joinchat/lwnLCWi9RAo1YzRi Если у кого-то есть вопросы, вы можете задавать их там. Я стараюсь на них отвечать. Также, на них могут отвечать все, у кого есть опыт в решении подобных проблем. Самое главное правило - не бойтесь показаться глупыми! Мы все не шибко умные. Задавать вопросы - это нормально. Ненормально их не задавать.

Я все время говорю, говорю что вам нужно больше практики, но до сих пор ничего не предложил. Предлагаю вам реализовать первый проект! Задание: Реализовать ПО для учета товаров на складе. - Должна быть возможность создавать категории товаров - Должна быть возможность получать список категорий товаров - Должна быть возможность создавать товар и задавать ему категорию - Должна быть возможность получать список созданных товаров - Должна быть возможность удалять товары, т.к. некоторые могут становиться неактуальными - Должна быть возможность добавлять товары, по мере их прибытия на склад - Должна быть возможность получать количество товара на складе - Должна быть возможность убирать товары, по мере их уменьшения на складе Данные можно хранить in-memory (это просто вариант) Данные можно хранить в файле. Формат выбираете сами (вариант по сложнее) Данные можно хранить в БД. Схему придумываете самостоятельно (сложный вариант) Приложение должно принимать команды из консоли. API предлагается придумать и разработать самим. Также, приложение должно выводить ответы на команды в консоль. Предполагается, что вы знакомы с такими вещами, как: - синтаксис - коллекции Остальные знания нужно получить в процессе разработки. Примерное время выполнения 2-3 недели. Если есть опыт, то сделать можно за 2-3 часа Все вопросы и уточнения пишите в комменты, т.к. я сделал этот высер просто из головы. Будем додумывать спорные моменты. Что я хочу дать вам этим заданием: - Работа со структурами данных. Вы должны получить опыт дизайна сущностей и связей между ними. - Лучшее освоение коллекций - Продумывания взаимодействия ваших компонентов. Декомпозиция функционала и определение зон ответственности - Научиться работать с потоками ввода/вывода - Лучшее освоение конструкций - циклы и условные операторы. Кто сделает задание, я предложу вам расширить функционал, и вот там посмотрим, на сколько ваше приложение готово к этому. Вы прочувствуете, что это такое и зададитесь вопросом, как это можно было минимизировать, и познакомитесь с такими штуками, как паттерны.

Ребят, все, кому нравится неформальное общение и обсуждение отдаленных тем, либо просто попиздеть - милости прошу в openspace https://t.me/joinchat/mLds_hiCpPc3NmEy Давайте чатик discussion оставим для обсуждения айтишной тематики и помощи друг другу. Да, если у вас есть вопросы по Java - пишите их в Discussion, я буду по возможности на них отвечать. Так же отвечать может любой, кто сталкивался с проблемой или знает, как ее решить, или, хотя бы куда можно посмотреть.

Задачка на ночь: сколько раз выполнится цикл при условии, что count = 3? Почему?

Хз почему, но native comments нихрена не работают. В общем, комменты по посту пишите сюда PS пидр тот, кто не пишет javadoc

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

​Лайфхак, как найти любую книгу. 1. Заходите в вк 2. Заходите во вкладку "Файлы" 3. В поиске вбивайте интересующую вас книгу 4. Выберете подходящую

Книги, которые дадут вам +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 - это версия вашей библиотеки. Т.к. ваш продукт развивается и вы постоянно вносите туда какие-то изменения, их необходимо отображать в версии вашего продукта. Таким образом, мы всегда может однозначно сказать, какую именно библиотеку мы хотим использовать, вплоть до версии. Пример моей библиотеки: <dependency> <groupId>com.github.kabal163</groupId> <artifactId>state-machine</artifactId> <version>0.4.2</version> </dependency> Ссылочка на maven репозиторий: https://mvnrepository.com/artifact/com.github.kabal163/state-machine/0.4.2 Ссылочка на github: https://github.com/Kabal163/akuna-state-machine

Ребят, накидайте плз идей для тикток. А то продолжу хуйню снимать😘

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). Когда нам не интересны детали реализации сервера, мы будем называть их узлами. Окей, теперь мы знаем, что такое физические и виртуальные узлы. А что на счет одного логического? Представьте себе, что вы хотите взаимодействовать с этой армией серверов через единый интерфейс, как будто, вы взаимодействуйте с одним очень мощным сервером. Например, вы говорите - разверни мне приложение. И пусть логический узел сам решит, где и как его развернуть. Это и называется кластером. Объединение нескольких узлов в один логический с единой точкой входа.