#java
Встроенные функциональные интерфейсы

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

https://telegra.ph/Vstroennye-funkcionalnye-interfejsy-06-11

#java
Stream API

https://telegra.ph/StreamAPI-06-11

#web
Модель OSI. Кратко.

7. Прикладной уровень - это единственный уровень который работает с пользователем и пользовательскими данными.
6. Уровень представления - данные с 7 уровня преобразуются в массив байт, возможно происходит сжатие и шифрования данных.
5. Сеансовый уровень - открывает соединение, и передает данные транспортному уровню.
4. Транспортный уровень - разбивает огромный массив байт на сегменты и добавляет к каждому сегменту свой заголовок в виде портов приложений откуда передается информация куда.
3. Сетевой уровень - разбивает сегменты на IP-пакеты, также добавляет свой заголовок.
2. Канальный уровень - разбивает эти пакеты на фреймы(кадры), добавляет заголовки.
1. Физический уровень - фреймы переходят на физический уровень, и через кабель или вайфай, мы преобразуем каждый из этих кадров в последовательность нулей и единиц, которые передаются на наш маршрутизатор или свитч.

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

Каждый из протоколов знает как работать с протоколами смежных уровней.

#java #design
Почему композиция лучше наследования?

GoF: «Предпочитайте композицию наследованию класса».

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

Проблема хрупкого базового класса

Одним из основных критериев хорошей архитектуры является слабое зацепление (loose coupling), которое характеризует степень взаимосвязи между программными модулями. Не зря слабое зацепление входит в перечень паттернов GRASP, описывающих базовые принципы для распределения ответственности между классами.

Слабое зацепление имеет массу преимуществ!

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

Появляется возможность параллельной разработки слабозацепленных модулей без риска нарушить их функционирование.

Логика работы класса становится более очевидной, легче становится использовать класс правильно и по назначению, и сложно использовать – неправильно.

​#utils #definition

Grafana — лучший дашборд для метрик

Graphana — первый действительно хороший дашборд для отображения метрик.

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

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

Теперь есть чатик 👽

Знаю, нужно было раньше. Столько осуждений пропустил, ээээх(

​#java #testing
Для чего вообще нужно тестирование?

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

Написание тестов, это всегда минимум 40% от выполнения каждого моего таска. Юнит-тесты, интеграционные, и тесты на взаимодействие с другими сервисами. Чем больше возможных ситуаций можно предугадать, тем лучше.

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

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

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

Пишите много тестов.

9 важнейших принципов разработки программного обеспечения

1. Будь проще, Саймон (Keep It Simple Simon, KISS):
*Ваши методы должны быть небольшими, не превышающими 40-50 строк.
*Каждый метод должен решать только одну проблему.
*У вас в проекте много условий? Убедитесь, что вы разбили их на более мелкие блоки кода.

2. Вам это не понадобится (You Aren't Gonna Need It, YAGNI):
*Как развивающийся разработчик программного обеспечения, всегда начинайте с добавления всего нескольких методов в класс. Когда ваш проект начнет обретать форму и возникнут новые требования, вы можете добавить больше функций. Таким образом, вы будете придерживаться принципов бережливой разработки программного обеспечения.

3. Дважды отмерь и один раз отрежь (Measure Twice and Cut Once):
*Дважды проверьте все требования проекта, чтобы убедиться, что вы не ничего не упускаете и не добавляете лишнего в свой код. После этого сделайте наброски, которые будут направлять весь процесс для получения высококачественного кода. Всегда тестируйте свой проект с самых основ, чтобы убедиться, что все в порядке.

4. Не повторяйся (Don’t Repeat Yourself, DRY):
*При написании кода не повторяйтесь. То есть избегайте копирования кода в разные места. В противном случае дальнейшее обслуживание будет трудным. Причина в том, что вам придется изменять код в разных местах.

5. Бритва Оккама:
*Создатель этого принципа - Уильям Оккам, философ 14 века. Принцип гласит, что в группе гипотез всегда выбирайте ту, которая имеет наименьшее количество предположений. Следуя принципу бережливой разработки программного обеспечения, всегда начинайте с максимально простого кода. Затем осторожно увеличивайте сложность по мере необходимости.

6. Сначала большое проектирование (Big Design Up Front, BDUF):
*Этот принцип разработки программного обеспечения утверждает, что разработчик должен сначала завершить проектирование. После этого проект можно реализовать. Сторонники утверждают, что такой подход помогает обнаруживать проблемы на стадии требований и быстро их решать.

7. Избегайте преждевременной оптимизации:
*Дональд Кнут утверждал, что корень всего зла в программировании - преждевременная оптимизация. Мы все согласны с тем, что оптимизация ускоряет процесс разработки и снижает потребление ресурсов. Однако она приведёт к неприятным последствиям, если вы займётесь ей слишком рано.

8. Наименьшее удивление:
*Принцип наименьшего удивления гласит, что желательно разработать функцию, которая не имеет высокого коэффициента удивления. Компоненты системы должны вести себя так, как того ожидают конечные пользователи. Поэтому результаты вашего проекта будут прибыльными только в том случае, если они очевидны, предсказуемы и последовательны. В противном случае пользователи будут уклоняться от использования функций или структур, которые удивляют или сбивают их с толку.

9. Закон Деметры:
*Закон Деметры пытается разделить обязанности между классами и уменьшить связанность между ними.

Настоятельно рекомендуется:
*Обеспечить независимость программных объектов друг от друга.
*Уменьшить общение или связь между разными классами.
*Поместить связанные классы в один и тот же пакет, модуль или каталог для достижения согласованности.

P.S: О solid вы и так знаете)

#science #news

Скорость света ближе, чем казалось

Пионер варп-двигателя и бывший специалист НАСА по варп-двигателю доктор Гарольд Дж. «Сонни» Уайт сообщил об открытии настоящего, реального «варп-пузыря». И, по словам Уайта, этот первый в своем роде прорыв его команды, Института безграничного космического пространства (LSI), устанавливает новую отправную точку для тех, кто пытается создать полноразмерный космический корабль, способный к деформации.

https://thedebrief.org/darpa-funded-researchers-accidentally-create-the-worlds-first-warp-bubble/

Мы бы сделали какой-нибудь особый пост под новый год, но я уже достаточно выпил, чтобы лечь спать. Хорошего года, успешных проектов.

#java
Сохранение данных в постоянной памяти, используя Preferences.

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

Если очень просто то это обычное API, позволяющее записывать значения по принципу ключ/значения. И основная особенность того, что на всех платформах оно будет адаптироваться. Фактическое хранение данных зависит от платформы.

Вот пример кода (Читайте комментарии):

import java.util.prefs.Preferences;

class PreferenceTest {
    //Created node for storage
    private final Preferences prefs = Preferences.userRoot().node(this.getClass().getName());

    public void setPreference() {
        //Keys
        final String key1 = "key1";
        final String key2 = "key2";
        final String key3 = "key3";

        //Here we define variables with default values
        System.out.println(prefs.getBoolean(key1, true));
        System.out.println(prefs.get(key2, "Hello World"));
        System.out.println(prefs.getInt(key3, 50));

        prefs.putBoolean(key1, false);
        prefs.put(key2, "Bye bye");
        prefs.putInt(key3, 0);

        //You should write key and default value for getting present value
        System.out.println(prefs.getInt(key3, 50));

        prefs.remove(key1);
    }

    public static void main(String[] args) {
        PreferenceTest test = new PreferenceTest();
        test.setPreference();
    }
}

Запустите программу дважды. Значение «key1» должно быть записано со значением по умолчанию (true) в командную строку, так как значение preference было удалено в конце метода. Значение «key2» и «key3» должно было измениться после первого вызова.

Useful link - https://spec-zone.ru/RU/Java/Docs/7/api/java/util/prefs/Preferences.html

#info
👋🏻 Мы решили делать посты на английском.

На это есть несколько причин:
1) количество охватываемой аудитории
2) хоть какая, но прокачка языка
3) легкость поиска контента

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

Если кому-то было интересно и/или полезно - не зря мы их писали 🐸