Одна из наиболее приятных для меня концепций Go — это возможность композиции интерфейсов. В этой статье мы разберем небольшой пример использования такой возможности языка. Для этого представим гипотетический сценарий, в котором две структуры обрабатывают пользовательские данные и выполняют http-запросы.
Вам действительно нужен Redux?
9 мин
Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.
Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.
Главный Технический Императив Разработки ПО — управление сложностью
— Совершенный код
Redux предлагает управлять сложностью с помощью предсказуемых изменений состояния. Предсказуемость достигается за счет трех фундаментальных принципов:
- состояние всего приложения хранится в одном месте
- единственный способ изменить состояние — отправка Action'ов
- все изменения происходят с помощью чистых функций
Смог ли Redux побороть возросшую сложность и было ли с чем бороться?
Контейнеры внедрения зависимостей и выгоды от их использования
7 мин
Перевод
От переводчика
Всем привет! Я продолжаю серию переводов, в которой мы по косточкам разбираем, что такое Dependency Injection.
В предыдущих статьях серии речь шла о «внедрении зависимостей» как подходе к проектированию приложений и возможных способах реализации такого подхода. Были разобраны типы зависимостей, варианты их внедрения, давались советы по снижению связанности компонентов кода.
В сегодняшнем переводе речь пойдет о том, что собой представляет DI-контейнер, его функциях, преимуществах использования и отличии от фабрик.
А вы знаете где можно применить expression's в вашем проекте или оптимизация создания тестов
5 мин
0. Лирика
Поговорим про unit тестирование. Для больших и возрастных проектов весьма актуальна проблема «толстых» сервисов. Я сейчас говорю про большое количество зависимостей передаваемых в конструктор. Если к этому добавить несколько десятков методов, которые необходимо тестировать, становится очевидно, что тратится много времени на мокирования ненужных частей. Решить проблему поможет автоматизация,. т.е. создание экземпляра необходимого типа и мокирование неиспользованных зависимостей в процессе выполнения.
Получается нам нужно
var myService = new MyService(A.Fake<ISevice1>(), new Sevice2(),
A.Fake<ISevice3>(), A.Fake<ISevice4>(),
A.Fake<ISevice5>(), A.Fake<ISevice6>())заменить на нечто похожее. Напоминает паттерн builder, не так ли?
var myService = GetInstance<MyService>().With(new Sevice2()).Subject;
Главное не переборщить с автоматизацией. Производительность тоже важна, особенно если в проекте несколько десятков тысяч тестов, которые будут запускаться как локально, так и в настроенном CI.
Разумеется нам не обойтись без рефлексии.
Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
18 мин
Туториал
Привет! Я пишу статьи, посвященные архитектуре в игровой разработке. В этой статье я хочу разобрать паттерн Команда (Command). Он многогранен, и может быть применен по-разному. Но я покажу, как сделать мой любимый трюк — машина времени для отладки изменений гейм стейта.
Эта штука сэкономила мне кучу времени в поиске и воспроизведении сложных багов. Она позволяет делать "снапшоты" игрового состояния, историю его изменения, и пошагово их применять.
Начинающие разработчики познакомятся с паттерном, а продвинутые, возможно, найдут трюк полезным.
Хотите узнать как это сделать? Прошу под кат.
Java 8 и паттерн Стратегия
9 мин
Потенциально возможное продолжение книги Паттерны проектирования (Элизабет Фримен и другие).
На дворе 2017 год. В компанию, где работает старший разработчик Джо, пришел на стажировку молодой студент Мартин. Он целый год скрупулезно изучал Java по современному учебнику с акцентом на функциональные интерфейсы, лямбда-выражения и прочие новшества.
На дворе 2017 год. В компанию, где работает старший разработчик Джо, пришел на стажировку молодой студент Мартин. Он целый год скрупулезно изучал Java по современному учебнику с акцентом на функциональные интерфейсы, лямбда-выражения и прочие новшества.
GObject: наследование и интерфейсы
8 мин
В комментариях к прошлой статье часто высказывалось мнение, что система GObject не нужна ввиду наличия C++ и других высокоуровневых языков. Помимо чисто технических моментов, о которых уже поговорили в комментариях, хотелось бы затронуть другой аспект. Вероятно, большинство комментаторов видит смысл существования объектной системы GLib в упорном нежелании сишников-ретроградов пользоваться благами цивилизации и смиряться с неумолимой поступью прогресса. Вероятно, так оно и было на заре развития Glib/GTK, зародившихся в мире UNIX-систем, GNU, open-source, идей Столлмана, и т. п. Большая часть того поколения хакеров действительно предпочитали Си, в то время как C++ был относительно молод и неразвит и преимущества его использования казались не настолько очевидными.
Сегодня, разумеется, для новых проектов большинство из нас предпочтёт использование более удобных, лаконичных и безопасных языков, даже если будет знаком со всеми нюансами использования GObject. Однако не стоит упускать из виду, что за 20 с лишним лет существования GLib/GTK с их использованием были созданы тысячи приложений и библиотек, многие из которых активно развиваются и поныне тысячами программистов со всего мира. В них добавляется новый функционал, вылавливаются баги, их адаптируют к современным технологиям вроде HiDPI-экранов, Wayland, Vulkan, и т. д. Для того, чтобы читать (дополнять, исправлять) код таких проектов, необходимо иметь базовые знания объектно-ориентированных расширений для Си, о котором мы с вами ведём речь.
Засим милости прошу под кат. Тренируемся, как обычно, на кошках :)
Сегодня, разумеется, для новых проектов большинство из нас предпочтёт использование более удобных, лаконичных и безопасных языков, даже если будет знаком со всеми нюансами использования GObject. Однако не стоит упускать из виду, что за 20 с лишним лет существования GLib/GTK с их использованием были созданы тысячи приложений и библиотек, многие из которых активно развиваются и поныне тысячами программистов со всего мира. В них добавляется новый функционал, вылавливаются баги, их адаптируют к современным технологиям вроде HiDPI-экранов, Wayland, Vulkan, и т. д. Для того, чтобы читать (дополнять, исправлять) код таких проектов, необходимо иметь базовые знания объектно-ориентированных расширений для Си, о котором мы с вами ведём речь.
Засим милости прошу под кат. Тренируемся, как обычно, на кошках :)
Создание игры на Lua и LÖVE — 3
42 мин
Туториал
Перевод
Оглавление
- Статья 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
Часть 7: Параметры и атаки игрока
Введение
В этой части мы больше сосредоточимся на части геймплея, относящейся к игроку. Сначала мы добавим самые фундаментальные параметры: боеприпасы, ускорение, здоровье (HP) и очки навыков. Эти параметры будут использоваться на протяжении всей игры и они являются основными параметрами, которые будет использовать игрок для выполнения всех доступных ему действий. После этого мы перейдём к созданию объектов Resource, то есть объектов, которые может собирать игрок. В них содержатся вышеупомянутые параметры. И наконец после этого мы добавим систему атак, а также несколько разных атак игрока.
Dependency injection
5 мин
Перевод
От переводчика
Представляемый вашему вниманию перевод открывает серию статей от Jakob Jenkov, посвященных внедрению зависимостей, или DI. Примечательна серия тем, что в ней автор, анализируя понятия и практическое применение таких понятий как «зависимость», «внедрение зависимостей», «контейнер для внедрения зависимостей», сравнивая паттерны создания объектов, анализируя недостатки конкретных реализаций DI-контейнеров (например, Spring), рассказывает, как пришел к написанию собственного DI-контейнера. Таким образом, читателю предлагается познакомиться с довольно цельным взглядом на вопрос управления зависимостями в приложениях.
В данной статье сравнивается подход к настройке объектов изнутри и извне (DI). По смыслу настоящая статья продолжает статью Jakob Jenkov Understanding Dependencies, в которой дается определение самому понятию «зависимости» и их типам.
Understanding Dependencies
12 мин
Перевод
От переводчика
Мы — внедрители. Мы должны внедрять, а не фантазировать!
(Рина Зеленая, к/ф «Девушка без адреса»)
К переводу этой статьи меня побудили две причины: 1) желание лучше разобраться с фреймворком Spring, 2) небольшое количество источников по теме на русском языке.
Краеугольный камень ООП — «внедрение зависимостей». Если описание процесса «внедрения» в целом, удовлетворительно, то объяснение понятия «зависимость» обычно оставляют за скобками. На мой взгляд, это существенное упущение.
Чтобы не фантазировать, а внедрять, нужно сначала разобраться с тем, что мы внедряем. И в этом нам может помочь лаконичная статья Jakob Jenkov «Understanding Dependencies». Она будет полезна не только тем, кто пишет на Java, но и тем, кто пишет на других языках и следит за качеством проектирования приложений.
UPD: Я перевел еще одну статью Jakob Jenkov о зависимостях. Читайте на Хабре перевод статьи Dependency Injection, которая открывает одноименную серию статей и по смыслу продолжает данную статью. В статьях серии рассматриваются такие понятия как Dependency, Dependency Injection (DI), DI-контейнеры.
Создание игры на Lua и LÖVE — 2
45 мин
Туториал
Перевод
Оглавление
- Статья 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
Часть 5: Основы игры
Введение
В этой части мы наконец приступим к самой игре. Сначала мы выполним обзор структуры игры с точки зрения геймплея, а затем сосредоточимся на основах, являющихся общими для всех частей игры: её пикселизированном стиле, камере, а также симуляции физики. Потом мы рассмотрим основы перемещения игрока и, наконец, разберёмся со сборкой мусора и возможными утечками объектов.
Структура игрового процесса
Сама игра разделена всего на три отдельных комнаты:
Stage, Console и SkillTree.В комнате Stage происходит весь игровой процесс. В ней находятся такие объекты, как игрок, враги, снаряды, ресурсы, бонусы и так далее. Игровой процесс очень похож на Bit Blaster XL и на самом деле достаточно прост. Я выбрал такой простой геймплей, потому что он позволит мне сосредоточиться на другом аспекте игры (огромном дереве навыков).
Создание игры на Lua и LÖVE — 1
37 мин
Туториал
Перевод
Введение
В этой серии туториалов мы рассмотрим создание завершённой игры с помощью Lua и LÖVE. Туториал предназначен для программистов, имеющих некоторый опыт, но только начинающих осваивать разработку игр, или для разработчиков игр, уже имевших опыт работы с другими языками или фреймворками, но желающими лучше узнать Lua или LÖVE.
Создаваемая нами игра будет сочетанием Bit Blaster XL и дерева пассивных навыков Path of Exile. Она достаточно проста, чтобы можно было рассмотреть её в нескольких статьях, не очень больших по объёму, но содержащих слишком большой объём знаний для новичка.
GIF
Кроме того, туториал имеет уровень сложности, не раскрываемый в большинстве туториалов по созданию игр. Большинство проблем, возникающих у новичков в разработке игр, связано с масштабом проекта. Обычно советуют начинать с малого и постепенно расширять объём. Хотя это и неплохая идея, но если вас интересуют такие проекты, которые никак нельзя сделать меньше, то в Интернете довольно мало ресурсов, способных вам помочь в решении встречаемых задач.
Что касается меня, то я всегда интересовался созданием игр со множеством предметов/пассивных возможностей/навыков, поэтому когда я приступал к работе, мне было сложно найти хороший способ структурирования кода, чтобы не запутаться в нём. Надеюсь, моя серия туториалов поможет кому-нибудь в этом.
Способ управления цветовыми схемами «Swift» «iOS»-приложения
4 мин
Даже для самого что ни на есть начинающего разработчика (скорее, на которого и рассчитан данный очерк), надеюсь, не секрет, что в коде не должно присутствовать никаких т.н. «hardcoded»-значений и прочих всяких там «magic numbers». Почему – тоже, надеюсь, понятно, а если нет, то в Сети имеются десятки, а то и сотни статей на эту тему, а также написан классический труд. «Android Studio» (наверное, не во всех случаях, но все же) даже любит генерировать «warnings» на эту тему и предлагать выносить строки и т.д. в ресурсные файлы. «Xcode» (пока?) такими подсказками нас не балует, и разработчику приходится самостоятельно держать себя в узде или, скажем, получать по рукам от коллег после «code review».
Все это касается и используемых в приложении цветов.
Все это касается и используемых в приложении цветов.
Ближайшие события
Firebird Conf: конференция для разработчиков и администраторов СУБД Firebird
6 июня
09:00 – 20:00
Москва
ООП без «О»
3 мин
Надеюсь материалы опубликованные в данной статье не покажутся слишком очевидными или покушением на оскорбление чувств «верующих», и уж тем более никто не воспримет название статьи слишком буквально как «ориентированное программирование». В любом случае данная статья это попытка поделиться личным опытом, а не пропаганда своей точки зрения.
Открытый урок «Диаграммы UML»
1 мин
Всем бобра!
Наш курс «Разработчик С++» потихоньку растёт и ширится: присоединился новый преподаватель с очень богатым опытом — Юрий Авраменко. И он уже провёл у нас первый открытый урок по диаграммам UML, на котором разбирались: виды диаграмм, инструменты построения схем и диаграмм, варианты представлений и прочее.
Ждём вопросы тут или на Дне открытых дверей.
Наш курс «Разработчик С++» потихоньку растёт и ширится: присоединился новый преподаватель с очень богатым опытом — Юрий Авраменко. И он уже провёл у нас первый открытый урок по диаграммам UML, на котором разбирались: виды диаграмм, инструменты построения схем и диаграмм, варианты представлений и прочее.
Ждём вопросы тут или на Дне открытых дверей.
SOLID
5 мин
SOLID критикует тот, кто думает, что действительно понимает ООП
© Куряшкин Виктор
Я знаком с принципами SOLID уже 6 лет, но только в последний год осознал, что они означают. В этой статье я дам простое объяснение этим принципам. Расскажу о минимальных требованиях к языку программирования для их реализации. Дам ссылки на материалы, которые помогли мне разобраться.
GObject: основы
7 мин
GObject — часть библиотеки GLib, реализующая объекто-ориентированнные расширения для чистого Си. Подобная концепция, помимо самой GLib, используется в таких проектах, как GStreamer, GSettings, ATK, Pango и весь проект GNOME в целом, а также в большом количестве прикладных приложений: GIMP, Inkscape, Geany, Gedit и многих других. Большое количество языков программирования, начиная от таких мейнстримовых, как Python и Java, и заканчивая изысками вроде Haskell или D, имеют привязки к GLib/GTK+, а для значительного количества языков биндинги к GTK+ вообще является единственным способом построения GUI.
В отличие от других схожих проектов, GObject отличают архитектурные особенности, целью которых является лёгкая и прозрачная реализация привязок библиотек, написанных с применением чистого Си и GObject, к другим языкам программирования, в том числе с динамической типизацией и управлением памятью при помощи сборщика мусора. Именно этим объясняется некоторое ощущение переусложнённости, которое может возникнуть у программиста, приступившего к знакомству с GObject API. Тем не менее, эта система очень продуманная и логичная, так что проблем с пониманием всего изложенного ниже у программиста, знакомого с C++ или Java, возникнуть не должно.
Данная статья иллюстрирует самые основы работы с объектной системой типов GLib.
В отличие от других схожих проектов, GObject отличают архитектурные особенности, целью которых является лёгкая и прозрачная реализация привязок библиотек, написанных с применением чистого Си и GObject, к другим языкам программирования, в том числе с динамической типизацией и управлением памятью при помощи сборщика мусора. Именно этим объясняется некоторое ощущение переусложнённости, которое может возникнуть у программиста, приступившего к знакомству с GObject API. Тем не менее, эта система очень продуманная и логичная, так что проблем с пониманием всего изложенного ниже у программиста, знакомого с C++ или Java, возникнуть не должно.
Данная статья иллюстрирует самые основы работы с объектной системой типов GLib.
Хочу как у YouTube
11 мин
Вы когда-нибудь задумывались как устроен ID видео на YouTube?
Возможно, вы уже знаете/нашли ответ, но, как показали обсуждения на Stack Overflow, многие понимают эту технологию неправильно. Если вам интересно изучить что-то новое, добро пожаловать под кат.
Применяем принцип KISS к самим принципам проектирования
3 мин
(Update: заменил картинку на более нейтральную)
Коллега упомянул в беседе принцип "Convention over configuration", и я подумал, блин, наверно это что-то крутое, нужно изучить, почитать статьи, а то отстану от жизни.
Каково было моё удивление, что вcё обьяснение помещается в одной фразе "Используй дефолты, которые можно при желании переопределять".
И тут я подумал, что очень много понаверчено принципов, которые произносятся с умным лицом и наморщенным лбом, хотя по сути там ничего сложного нет. Многие из них можно объяснить буквально одной фразой. Ну, может, абзацем текста или практическим примером. На пальцах, короче. Вообще, очень часто бывает такое, что объясняешь кому-то за минуту то, что сам изучал довольно долго. А какие-то детали прирастают уже потом, главное получить "ключ".
В итоге я попытался сделать такую табличку. Можно сказать, своего рода русско-китайский разговорник:
Достоинства и фатальные недостатки типизации в php
4 мин
Язык php часто ругают, обычно необоснованно. Особенно удивляет, что javascript ругают меньше. Зачастую это делают люди, которые писали на нем 10+ лет назад, когда язык был действительно чертовски плох, да и разработчики в те времена не задумывались над качеством кода. Посмотрите хотя бы на код wordpress, который до сих пор вызывает шок.
Ругают необоснованно, но проблемы у языка, конечно же, есть, и они серьёзные. Разуметеся, если сравнить последние релизы php7 (с нормальным ООП и строгим тайпхинтингом) и php4, то разница будет колоссальная. Однако и в последних версиях языка не всё гладко, и до java/c# пока что очень далеко. Более того, берусь утверждать, что будущее php тоже довольно сомнительно (с точки зрения типов).
Другими словами, давайте рассмотрим предметно, что хорошо и что плохо в php с точки зрения типизации.