ООП *

Функциональное программирование пронизывает большую часть основного мира программирования — экосистема JavaScript, Linq для C#, даже функции высокого порядка в Java. Так выглядит Java в 2018-м:

getUserName(users, user -> user.getUserName());

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

Но не всё так радужно. Многие разработчики сопротивляются этому тектоническому сдвигу в нашем подходе к ПО. Честно говоря, сегодня трудно найти работу, связанную с JavaScript, которая не требует знания концепций ФП.

Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.

Коллеги, привет!

Вот и пятница, до выходных еще далеко, поэтому мы надеемся, что сравнительно сложный текст вас не очень смутит.

Складывается впечатление, что модульная организация Java 9 потребует от программиста недюжинной изобретательности, и один из перспективных вариантов адаптации к такому дивному новому миру — это внедрение зависимостей. Именно по этому поводу внятно и интересно высказался в блоге O'Reilly уважаемый Пол Бэккер (Paul Bakker), один из авторов книги "Java 9 Modularity"


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

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

Чтобы из одного процесса создать задачу для следующей стадии обработки, мы просто вызывали в конце обработки dispatch(), примерно так:

Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются воедино. Трудно определить, что отличает такую статью от других. Правильно подобранные слова, оптимальная логика изложения или же просто более релевантный пример. Я не претендую на то, что моя статься окажется новым словом в C# или же лучшей обучающей статьей. Но, возможно для кого-то она станет именно той, которая позволит разобраться, запомнить и начать правильно применять те понятия, о которых пойдет речь.

Перевод блог-поста Стивена Вольфрама (Stephen Wolfram) "Roaring into 2018 with Another Big Release: Launching Version 11.3 of the Wolfram Language & Mathematica".

---

Содержание

— Поток выпуска версий
— Что нового?
— Блокчейн
— Системное моделирование
— Новое в ноутбуках
— Документация рабочего процесса
— Инструменты для презентаций
— Wolfram Чат
— Удобства языка
— Обновления визуализации
— Чтение текста
— Вычисления по лицам
— Нейронные сети
— Асимптотический анализ
— «Элементарная» алгебра
— Доказательства
— Растущая база знаний
— Сообщения и почта
— Операции на системном уровне
— Что не упоминалось

Часть 14: Консоль

Введение

В этой части мы разберём комнату Console. Консоль реализовать гораздо проще, чем всё остальное, потому что в итоге она сводится к выводу на экран текста. Вот, как это выглядит:


Комната Console будет состоять из трёх разных типов объектов: строк, строк ввода и модулей. Строки — это просто обычные цветные строки текста, отображаемые на экране. Например, в показанном выше примере ":: running BYTEPATH..." будет являться строкой. С точки зрения структуры данных это будет просто таблица, хранящая позицию строки, её текст и цвета.

В этой статье мы поговорим о классическом наследовании в JavaScript, распространённых шаблонах его использования, особенностях и частых ошибках применения. Рассмотрим примеры наследования в Babel, Backbone JS и Ember JS и попытаемся вывести из них ключевые принципы объектно-ориентированного наследования для создания собственной реализации в EcmaScript 5.

Статья для тех, кто знаком с наследованием в других языках и сталкивался с попытками эмулировать подобное поведение в JavaScript, а также для тех, кому интересно заглядывать «под капот» различных библиотек и фреймворков, сравнивая их реализацию. Оказывается, простую функцию extend можно реализовать очень по-разному. Нередко при этом допускаются ошибки (см. пункт «Самая распространённая ошибка» ниже).

Часть 13: Дерево навыков

Введение

В этой части статьи мы сосредоточимся на создании дерева навыков. Вот, как оно выглядит сейчас. Мы не будем располагать каждый узел вручную (это я оставлю в качестве упражнений), а рассмотрим всё необходимое для реализации и правильной работы дерева навыков.

Сначала мы рассмотрим способ задания каждого узла, затем узнаем, как считывать эти определения, создавать необходимые объекты и применять к игроку соответствующие пассивные навыки. Затем мы перейдём к основным объектам (узлам и связям), а потом рассмотрим сохранение и загрузку дерева. А в конце мы реализуем функционал, необходимый для того, чтобы игрок мог тратить очки навыков на узлы дерева.

Наука в программировании — быль или реальность? Сколько её в языках и почему идут холивары о приемуществах одних языков над другими? Если интересно — прошу под кат.

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



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

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

Оглавление

• Статья 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 (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомиться в оригинале). Перевод второй — по ссылке. И так как он вызвал БЕШЕННЫЙ ажиотаж(целых ДВА человека подискутировали со мной в комментах), то не перевести третью было бы преступлением.

В предыдущей статье мы обсудили разумную систему расслоения проекта, состоящую из трех слоёв:

• Домен
• Прикладной слой
• Инфраструктура

Сейчас, подробно рассмотрим инфраструктурный слой.

Оглавление

• Статья 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

В 2017 году Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомитсья в оригинале). Переводом второй является данная статья. Перевод третьей будет доступен в скором времени.

Для меня, одним из обязательных требований, к "чистой" архитектуре, является грамотное разделение кода приложения по слоям. Сам слой не делает ничего, вся соль в том, как он используется и какие ограничения накладываются на компоненты, ему принадлежащие. Давайте немного пофилософствуем, перед тем как рассмотреть конеретные практические приемы.

Перевод ироничного поста из блога Боба Мартина в котором он рассуждает о том, насколько неудачным является использование слова interface в современных языках программирования, и какую путаницу и проблемы оно несёт разработчикам.

— Что ты думаешь об интерфейсах?

— Имеешь в виду интерфейсы в Java или C#?

— Да. Классная фича этих языков?

— Просто великолепная!

— Правда? А что такое интерфейс? Это то же самое что и класс?

— Ну… Не совсем!

Здравствуйте коллеги!

В предыдущей статье речь шла о проблеме ООЯП в общем, в данной статье я бы хотел развить эту тему и показать более конкретно проблемы ООЯП.

Основные идеи: ООЯП имеют две ключевые проблемы: неполноценная объектная парадигма и преждевременная типизация. Неполноценная объектная парадигма не даёт определения понятию нетипизированной объектной композиции (композиция является важнейшим элементом любой парадигмы). Преждевременная типизация ограничивает семантику абстрактных понятий (семантических абстракций).

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

Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.

Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.

Главный Технический Императив Разработки ПО — управление сложностью

— Совершенный код

Redux предлагает управлять сложностью с помощью предсказуемых изменений состояния. Предсказуемость достигается за счет трех фундаментальных принципов:

• состояние всего приложения хранится в одном месте
• единственный способ изменить состояние — отправка Action'ов
• все изменения происходят с помощью чистых функций

Смог ли Redux побороть возросшую сложность и было ли с чем бороться?

От переводчика

Всем привет! Я продолжаю серию переводов, в которой мы по косточкам разбираем, что такое Dependency Injection.

В предыдущих статьях серии речь шла о «внедрении зависимостей» как подходе к проектированию приложений и возможных способах реализации такого подхода. Были разобраны типы зависимостей, варианты их внедрения, давались советы по снижению связанности компонентов кода.

В сегодняшнем переводе речь пойдет о том, что собой представляет DI-контейнер, его функциях, преимуществах использования и отличии от фабрик.