#java
Встроенные функциональные интерфейсы
Решил написать сначала о функциональных интерфейсах, все-таки, это база для StreamAPI. Кстати, следующий пост будет о именно о них.
https://telegra.ph/Vstroennye-funkcionalnye-interfejsy-06-11
Встроенные функциональные интерфейсы
Решил написать сначала о функциональных интерфейсах, все-таки, это база для StreamAPI. Кстати, следующий пост будет о именно о них.
https://telegra.ph/Vstroennye-funkcionalnye-interfejsy-06-11
Telegraph
Встроенные функциональные интерфейсы
Как и упоминалось в предыдущем посте, разработчики Java создали довольно много функциональных интерфейсов. Рассмотрим основные.
#web
Модель OSI. Кратко.
7. Прикладной уровень - это единственный уровень который работает с пользователем и пользовательскими данными.
6. Уровень представления - данные с 7 уровня преобразуются в массив байт, возможно происходит сжатие и шифрования данных.
5. Сеансовый уровень - открывает соединение, и передает данные транспортному уровню.
4. Транспортный уровень - разбивает огромный массив байт на сегменты и добавляет к каждому сегменту свой заголовок в виде портов приложений откуда передается информация куда.
3. Сетевой уровень - разбивает сегменты на IP-пакеты, также добавляет свой заголовок.
2. Канальный уровень - разбивает эти пакеты на фреймы(кадры), добавляет заголовки.
1. Физический уровень - фреймы переходят на физический уровень, и через кабель или вайфай, мы преобразуем каждый из этих кадров в последовательность нулей и единиц, которые передаются на наш маршрутизатор или свитч.
После получения данных вторым устройством, начинается обратное преобразование последовательности нулей и единиц в данные прикладного уровня.
Каждый из протоколов знает как работать с протоколами смежных уровней.
Модель OSI. Кратко.
7. Прикладной уровень - это единственный уровень который работает с пользователем и пользовательскими данными.
6. Уровень представления - данные с 7 уровня преобразуются в массив байт, возможно происходит сжатие и шифрования данных.
5. Сеансовый уровень - открывает соединение, и передает данные транспортному уровню.
4. Транспортный уровень - разбивает огромный массив байт на сегменты и добавляет к каждому сегменту свой заголовок в виде портов приложений откуда передается информация куда.
3. Сетевой уровень - разбивает сегменты на IP-пакеты, также добавляет свой заголовок.
2. Канальный уровень - разбивает эти пакеты на фреймы(кадры), добавляет заголовки.
1. Физический уровень - фреймы переходят на физический уровень, и через кабель или вайфай, мы преобразуем каждый из этих кадров в последовательность нулей и единиц, которые передаются на наш маршрутизатор или свитч.
После получения данных вторым устройством, начинается обратное преобразование последовательности нулей и единиц в данные прикладного уровня.
Каждый из протоколов знает как работать с протоколами смежных уровней.
#java #design
Почему композиция лучше наследования?
GoF: «Предпочитайте композицию наследованию класса».
Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования проблемы.
Проблема хрупкого базового класса
Одним из основных критериев хорошей архитектуры является слабое зацепление (loose coupling), которое характеризует степень взаимосвязи между программными модулями. Не зря слабое зацепление входит в перечень паттернов GRASP, описывающих базовые принципы для распределения ответственности между классами.
Слабое зацепление имеет массу преимуществ!
Ослабив зависимости между программными модулями, вы облегчаете сопровождение и поддержку системы за счет формирования более гибкой архитектуры.
Появляется возможность параллельной разработки слабозацепленных модулей без риска нарушить их функционирование.
Логика работы класса становится более очевидной, легче становится использовать класс правильно и по назначению, и сложно использовать – неправильно.
Почему композиция лучше наследования?
GoF: «Предпочитайте композицию наследованию класса».
Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования проблемы.
Проблема хрупкого базового класса
Одним из основных критериев хорошей архитектуры является слабое зацепление (loose coupling), которое характеризует степень взаимосвязи между программными модулями. Не зря слабое зацепление входит в перечень паттернов GRASP, описывающих базовые принципы для распределения ответственности между классами.
Слабое зацепление имеет массу преимуществ!
Ослабив зависимости между программными модулями, вы облегчаете сопровождение и поддержку системы за счет формирования более гибкой архитектуры.
Появляется возможность параллельной разработки слабозацепленных модулей без риска нарушить их функционирование.
Логика работы класса становится более очевидной, легче становится использовать класс правильно и по назначению, и сложно использовать – неправильно.
#utils #definition
Grafana — лучший дашборд для метрик
Graphana — первый действительно хороший дашборд для отображения метрик.
Метрика - мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
Graphana предназначена для отображения всевозможных циклических метрик. Помимо предопределенных системных метрик (CPU, IO, etc..), можно сконфигурировать любой набор произвольных метрик — онлайн, профит и т.д. Graphana имеет две встроенных темы оформления — обе выглядят очень хорошо. Можно создать любое количество произвольных дашбордов.
Grafana — лучший дашборд для метрик
Graphana — первый действительно хороший дашборд для отображения метрик.
Метрика - мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
Graphana предназначена для отображения всевозможных циклических метрик. Помимо предопределенных системных метрик (CPU, IO, etc..), можно сконфигурировать любой набор произвольных метрик — онлайн, профит и т.д. Graphana имеет две встроенных темы оформления — обе выглядят очень хорошо. Можно создать любое количество произвольных дашбордов.
Все Enums наследуются от класса
Anonymous Quiz
6%
Enums
10%
java.lang.Enums
23%
Это специальный тип, у него нету наследника
35%
Object
25%
java.lang.Enum
#java #testing
Для чего вообще нужно тестирование?
Недавно узнал, что не все начинающие разработчики понимают, почему тестирование необходимо и почему на него так много тратят времени.
Написание тестов, это всегда минимум 40% от выполнения каждого моего таска. Юнит-тесты, интеграционные, и тесты на взаимодействие с другими сервисами. Чем больше возможных ситуаций можно предугадать, тем лучше.
Юнит-тесты конечно простейшие. Вы с ними точно встречались, если делали какие-то задачи на LeetCode, или Codewars. Вы просто выделяете маленький блок кода, класс и его методы, даете определенные данные на вход и проверяете, что получаете на выходе. Это самый быстрый и наименее эффективный способ проверить, все ли работает корректно, ведь, если метод работает корректно сам по себе, это не значит, что он будет работать корректно в самой системе. Вот здесь нам и нужны интеграционные тесты.
При имплементации сложных решений, например создание больших фич, как переписывание утилитарного класса на другую библиотеку, необходимо писать интеграционные тесты. Интеграционные тесты, это по сути много юнит-тестов. Вы берете класс и проверяете, как он будет взаимодействовать с другими классами в вашей системе. Хорошие интеграционные тесты требуют написания тысяч линий кода, поэтому иногда приходится писать собственные фреймворки для тестирования.
Ну вот я проверил, что все правильно работает, для чего мне оставлять тысячи линий кода в проекте, если все и так работает?
Тесты часто вам помогают убедиться, что новая фича ничего старого не поломала. При хорошем деплойе проходят все тесты и, если что-то пойдет не так, то поблагодарите тестам, что это не случилось на проде и к вам домой не едет CEO.
Пишите много тестов.
Для чего вообще нужно тестирование?
Недавно узнал, что не все начинающие разработчики понимают, почему тестирование необходимо и почему на него так много тратят времени.
Написание тестов, это всегда минимум 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 вы и так знаете)
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/
Скорость света ближе, чем казалось
Пионер варп-двигателя и бывший специалист НАСА по варп-двигателю доктор Гарольд Дж. «Сонни» Уайт сообщил об открытии настоящего, реального «варп-пузыря». И, по словам Уайта, этот первый в своем роде прорыв его команды, Института безграничного космического пространства (LSI), устанавливает новую отправную точку для тех, кто пытается создать полноразмерный космический корабль, способный к деформации.
https://thedebrief.org/darpa-funded-researchers-accidentally-create-the-worlds-first-warp-bubble/
The Debrief
DARPA Funded Researchers Accidentally Discover The World’s First Warp Bubble "Engage."
Warp drive pioneer Dr. Harold G “Sonny” White has reported research results that he believes could theoretically manifest a warp bubble under laboratory conditions.
Мы бы сделали какой-нибудь особый пост под новый год, но я уже достаточно выпил, чтобы лечь спать. Хорошего года, успешных проектов.