
ООП *
Объектно-ориентированное программирование
Перевод: Почему ФП важно даже для ООП программистов?
Однажды меня очень заинтересовало функциональное программирование, я стал изучать его и рассказывать всем своим знакомым о том, какое оно замечательное. Позже я наткнулся на статью о функциональном программирования с точки зрения ООП программиста и решил перевести ее для вас. Не судите строго, это мой первый перевод.
«Истина в последней инстанции» или зачем нужен Database First Design
В этой весьма запоздалой статье я объясню почему, по моему мнению, в большинстве случаев при разработке модели данных приложения необходимо придерживаться подхода "database first". Вместо "Java[любой другой язык] first" подхода, который выведет вас на длинную дорожку, полную боли и страданий, как только проект начнет расти.

"Слишком занят, чтобы стать лучше" Licensed CC by Alan O’Rourke / Audience Stack. Оригинальное изображение
Очень простое объяснение принципов SOLID
SOLID — это набор принципов по организации кода. Фактически они декларируют некие правила, которые помогут вам сохранить свои и чужие нервы и время. А могут и не помочь.
Попробуем разобраться в этих принципах на пальцах, без примеров кода и СМС.
Бьёрн Страуструп: Проблема с программированием

Статья 2006 года.
Бьёрн Страуструп, изобретатель языка программирования C++, защищает свое наследие и рассказывает, что не так с большей частью программного кода.
В 1980-х и 90-х годах Бьёрн Страуструп разработал и внедрил язык программирования C++, который популяризировал объектно-ориентированное программирование и повлиял на многие другие языки программирования, включая Java.
C++ остается архетипическим «высокоуровневым» компьютерным языком (то есть языком, который сохраняет особенности естественного, человеческого языка), и он по-прежнему используется миллионами программистов. Многие из систем и приложений эры ПК и интернета были написаны на C++. Несмотря на это, язык остается спорным, во многом потому что его, как известно, трудно изучать и использовать, а также потому, что дизайн Страуструпа позволяет разработчикам допускать серьезные ошибки программирования в интересах сохранения их свободы.
Страуструп, на протяжении многих лет работающий в AT&T Bell Labs, теперь является профессором компьютерных наук на факультете инженерии в Техасском университете A&M, недалеко от Хьюстона.
Технологический обзор: почему большая часть программного обеспечения настолько плоха?
Бьёрн Страуструп: Некоторые программы на самом деле довольно хороши по любым стандартам. Подумайте о Mars Rovers, Google и проекте “Геном человека”. Это качественное программное обеспечение! Пятнадцать лет назад большинство людей, и в частности большинство экспертов, сказали бы, что каждый из этих примеров невозможен. Наша технологическая цивилизация зависит от программного обеспечения, поэтому, если бы программное обеспечение было бы в действительности таким же плохим, как и его наихудшая репутация, большинство из нас уже были бы мертвы.
Простое объяснение принципов SOLID

Принципы SOLID — это стандарт программирования, который все разработчики должны хорошо понимать, чтобы избегать создания плохой архитектуры. Этот стандарт широко используется в ООП. Если применять его правильно, он делает код более расширяемым, логичным и читабельным. Когда разработчик создаёт приложение, руководствуясь плохой архитектурой, код получается негибким, даже небольшие изменения в нём могут привести к багам. Поэтому нужно следовать принципам SOLID.
На их освоение потребуется какое-то время, но если вы будете писать код в соответствии с этими принципами, то его качество повысится, а вы освоите создание хорошей архитектуры ПО.
Чтобы понять принципы SOLID, нужно чётко понимать, как использовать интерфейсы. Если у вас такого понимания нет, то сначала почитайте документацию.
Я буду объяснять SOLID самым простым способом, так что новичкам легче будет разобраться. Будем рассматривать принципы один за другим.
Можно ли осознанно отказаться от функционального программирования?
getUserName(users, user -> user.getUserName());Функциональное программирование настолько полезно и удобно, что, насколько я вижу, проникло во все современные распространённые языки.
Но не всё так радужно. Многие разработчики сопротивляются этому тектоническому сдвигу в нашем подходе к ПО. Честно говоря, сегодня трудно найти работу, связанную с JavaScript, которая не требует знания концепций ФП.
Не пишите лишнего
Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.
Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.
Модули Java 9 и внедрение зависимостей: используем Guice
Вот и пятница, до выходных еще далеко, поэтому мы надеемся, что сравнительно сложный текст вас не очень смутит.
Складывается впечатление, что модульная организация Java 9 потребует от программиста недюжинной изобретательности, и один из перспективных вариантов адаптации к такому дивному новому миру — это внедрение зависимостей. Именно по этому поводу внятно и интересно высказался в блоге O'Reilly уважаемый Пол Бэккер (Paul Bakker), один из авторов книги "Java 9 Modularity"

Приятного чтения и не забудьте проголосовать пожалуйста!
Управление очередями в Laravel

В моем текущем проекте много задач, которые выполняются в фоне. Из внешнего сервиса прилетают данные и проходят несколько стадий обработки. Обработка реализована через механизм очередей. Это удобно, можно варьировать количество воркеров на каждый тип процессов. Да и в случае, если что-то упадет, очередь будет копиться, и данные не потеряются — обработаются, как только проблема будет устранена.
Чтобы из одного процесса создать задачу для следующей стадии обработки, мы просто вызывали в конце обработки
dispatch(), примерно так:Наследование, композиция, агрегация
Врываемся в 2018 год с очередным большим релизом: выпуск версии 11.3 языка Wolfram Language и Mathematica

Перевод блог-поста Стивена Вольфрама (Stephen Wolfram) "Roaring into 2018 with Another Big Release: Launching Version 11.3 of the Wolfram Language & Mathematica".
Содержание
— Поток выпуска версий
— Что нового?
— Блокчейн
— Системное моделирование
— Новое в ноутбуках
— Документация рабочего процесса
— Инструменты для презентаций
— Wolfram Чат
— Удобства языка
— Обновления визуализации
— Чтение текста
— Вычисления по лицам
— Нейронные сети
— Асимптотический анализ
— «Элементарная» алгебра
— Доказательства
— Растущая база знаний
— Сообщения и почта
— Операции на системном уровне
— Что не упоминалось
Создание игры на Lua и LÖVE — 7

Оглавление
- Статья 1
- Часть 1. Игровой цикл
- Часть 2. Библиотеки
- Часть 3. Комнаты и области
- Часть 4. Упражнения
- Статья 2
- Часть 5. Основы игры
- Часть 6. Основы класса Player
- Статья 3
- Часть 7. Параметры и атаки игрока
- Часть 8. Враги
- Статья 4
- Часть 9. Режиссёр и игровой цикл
- Часть 10. Практики написания кода
- Часть 11. Пассивные навыки
- Статья 5
- Часть 12. Другие пассивные навыки
- Статья 6
- Часть 13. Дерево навыков
- Статья 7
- Часть 14. Консоль
- Часть 15. Финал
Часть 14: Консоль
Введение
В этой части мы разберём комнату Console. Консоль реализовать гораздо проще, чем всё остальное, потому что в итоге она сводится к выводу на экран текста. Вот, как это выглядит:

Комната Console будет состоять из трёх разных типов объектов: строк, строк ввода и модулей. Строки — это просто обычные цветные строки текста, отображаемые на экране. Например, в показанном выше примере ":: running BYTEPATH..." будет являться строкой. С точки зрения структуры данных это будет просто таблица, хранящая позицию строки, её текст и цвета.
Ближайшие события
Классическое наследование в JavaScript. Разбор реализации в Babel, BackboneJS и Ember
Статья для тех, кто знаком с наследованием в других языках и сталкивался с попытками эмулировать подобное поведение в JavaScript, а также для тех, кому интересно заглядывать «под капот» различных библиотек и фреймворков, сравнивая их реализацию. Оказывается, простую функцию extend можно реализовать очень по-разному. Нередко при этом допускаются ошибки (см. пункт «Самая распространённая ошибка» ниже).
Создание игры на Lua и LÖVE — 6

Оглавление
- Статья 1
- Часть 1. Игровой цикл
- Часть 2. Библиотеки
- Часть 3. Комнаты и области
- Часть 4. Упражнения
- Статья 2
- Часть 5. Основы игры
- Часть 6. Основы класса Player
- Статья 3
- Часть 7. Параметры и атаки игрока
- Часть 8. Враги
- Статья 4
- Часть 9. Режиссёр и игровой цикл
- Часть 10. Практики написания кода
- Часть 11. Пассивные навыки
- Статья 5
- Часть 12. Другие пассивные навыки
- Статья 5
- Часть 13. Дерево навыков
14. Console
15. Final
Часть 13: Дерево навыков
Введение
В этой части статьи мы сосредоточимся на создании дерева навыков. Вот, как оно выглядит сейчас. Мы не будем располагать каждый узел вручную (это я оставлю в качестве упражнений), а рассмотрим всё необходимое для реализации и правильной работы дерева навыков.
Сначала мы рассмотрим способ задания каждого узла, затем узнаем, как считывать эти определения, создавать необходимые объекты и применять к игроку соответствующие пассивные навыки. Затем мы перейдём к основным объектам (узлам и связям), а потом рассмотрим сохранение и загрузку дерева. А в конце мы реализуем функционал, необходимый для того, чтобы игрок мог тратить очки навыков на узлы дерева.
Научное программирование: часть 1
Собственные валидации полей для Rules в одном классе

Я не думаю, что многие разработчики любят проверять входные данные и делают это достаточно тщательно, поэтому в современных фреймворках, таких как Yii 2, предусмотрены функции rules() для моделей и классы-Валидаторы, которые хоть и не избавляют от этой рутины, но, как минимум, делают этот процесс менее нудным.
В современной документации Yii 2 и других источниках я не нашел живой пример, как сделать так, чтобы все собственные правила валидации хранились в одном месте и их было удобно использовать, если Вы заинтересованы в решении этой проблемы, добро пожаловать под кат.
Создание игры на Lua и LÖVE — 5

Оглавление
- Статья 1
- Часть 1. Игровой цикл
- Часть 2. Библиотеки
- Часть 3. Комнаты и области
- Часть 4. Упражнения
- Статья 2
- Часть 5. Основы игры
- Часть 6. Основы класса Player
- Статья 3
- Часть 7. Параметры и атаки игрока
- Часть 8. Враги
- Статья 4
- Часть 9. Режиссёр и игровой цикл
- Часть 10. Практики написания кода
- Часть 11. Пассивные навыки
- Статья 5
- Часть 12. Другие пассивные навыки
13. Skill Tree
14. Console
15. Final
Часть 12: Другие пассивные навыки
Залп
Мы начнём с реализации оставшихся атак. Первой будет атака Blast, которая выглядит так:

Выстреливается несколько снарядов с разной скоростью, как из дробовика, которые потом быстро исчезают. Все цвета берутся из таблицы
negative_colors и каждый снаряд наносит меньше урона, чем обычно.Matthias Noback Об Идеальной Архитектуре — Слои, Порты и Адаптеры (Часть 3 — Порты и Адаптеры)
Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомиться в оригинале). Перевод второй — по ссылке. И так как он вызвал БЕШЕННЫЙ ажиотаж(целых ДВА человека подискутировали со мной в комментах), то не перевести третью было бы преступлением.
В предыдущей статье мы обсудили разумную систему расслоения проекта, состоящую из трех слоёв:
- Домен
- Прикладной слой
- Инфраструктура
Сейчас, подробно рассмотрим инфраструктурный слой.
Создание игры на Lua и LÖVE — 4

Оглавление
- Статья 1
- Часть 1. Игровой цикл
- Часть 2. Библиотеки
- Часть 3. Комнаты и области
- Часть 4. Упражнения
- Статья 2
- Часть 5. Основы игры
- Часть 6. Основы класса Player
- Статья 3
- Часть 7. Параметры и атаки игрока
- Часть 8. Враги
- Статья 4
- Часть 9. Режиссёр и игровой цикл
- Часть 10. Практики написания кода
- Часть 11. Пассивные навыки
- Статья 5
- Часть 12. Другие пассивные навыки
13. Skill Tree
14. Console
15. Final