Собираетесь менять работу? Нет? Ну может будет интересно. А может поделитесь с миром своим опытом...

К сожалению, разработчики должны не просто писать код :), но и зарабатывать. И если вы не фрилансер, то придется проходить техническое интервью. Я случайно нашел GitHub книгу по подготовке к техническому собеседованию. Чем это интересно?

1. Действительно хороший материал, из которого можно много подчерпнуть.

2. Там есть интересные подборки различных вопросов из top-tech компаний https://github.com/yangshun/tech-interview-handbook/blob/7870a58b31069c2f25b95b2529dfe5c082e05785/non-technical/behavioral.md

3. Это Open Source, это коллективное мнение. Туда можно контрибьютить и/или спрашивать вопросы, просить дополнять.

4. Может вы активно собеседуете людей? Это возможность вспомнить как это выглядит с другой стороны. А может даже поделиться своим опытом по этой части https://github.com/yangshun/tech-interview-handbook/issues/55

https://github.com/yangshun/tech-interview-handbook

Интересный анализ топа контрибуторов в опенсорс проекты. С данными можно поиграться в DataStudio самому.

Что забавно, MS среди лидеров. Подумал бы, что статья не объективная, но автор — Developer Advocate @ Google. Одно дело, когда MS говорит что является топ контрибутором, другое дело, когда это признают соперники. В интересные времена живём, товарищи.

Опенсорс позволяет делать потрясающие вещи. И даже такие гиганты как MS признали это и активно используют.

https://medium.freecodecamp.org/the-top-contributors-to-github-2017-be98ab854e87

Ранее я писал о том как полезно знание шаблонов проектирования, и как оно все может поменять.

Один из ключевых шаблонов, которые изменили мое мировоззрение в ООП мире был Dependency Injection. И это поистине великолепное решение.

Если вы не знаете что это за шаблон, то самое время это исправить.

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

Стандартный подход для устранения зависимостей — использование интерфейсов. Интерфейс позволяет отвязаться от конкретной реализации. А это дает свободу дейсвий и гибкость. Но подход должен быть конзистентным на всех слоях архитектуры.

Представьте, что мы заинжектили интерфейс для взаимодействия с базой данных


void PerformSomeQuery(IDb db)
{
db.Exec("INSERT INTO blabla VALUES('bla', 'bla')");
}


Но что если метод Exec этого интерфейса выглядит следующим образом:


interface IDb
{
void Exec(SQLString query);
}


Проблема данного кода в том, что интерфейс вводит новую зависимость: SQLString — некий внутренний тип для IDb. Это большая проблема, так как имплементировать интерфейс IDb, не привязываясь к внутренним типам, не представляется возможным. Что, по сути, делает данный интерфейс практически бесполезным.

В статье DIP in the Wild Мартин говорит о том, что

Высокоуровневый код не должен зависеть от низкоуровневых деталей

Чтобы избавить пользователя от головной боли, автор интерфейса должен так же использовать интерфейс


interface IDb
{
void Exec(ISQLString query);
}


А SQLString, в свою очередь, должен имплементировать ISQLString. Тогда пользователь класса сможет реализовать удобные для него имплементации, и не привносить никаких дополнительных зависимостей.

Если это возможно, то лучше ограничиваться стандартными типами, и, например, заменить ISQLString на стандартный string.

В статье Мартина вы сможете найти много других интересных примеров и решений распространенных проблем.

Если вас интересуют подобные проблемы и тема проектирования архитектуры приложения, то очень советую книгу Clean Architecture

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

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

Все же попадали с ГИТом в разные непредвиденные ситуации. С губ в такие моменты слетает многозначительный "упс", неприятно щекочет под ложечкой и начинают закрадываться мысли что последние 2 дня ты работал напрасно.
Вот тут https://github.com/k88hudson/git-flight-rules собрали планы спасения на такой случай. Да и просто рецепты, которые в повседневной жизни пригодятся.

Что использовать, знаки табуляции или пробелы? Или в этом нет разницы, потому что существует удобный инструмент? Читайте в нашей новой публикации.

Подробнее: https://habrahabr.ru/company/microsoft/blog/341722/

Думал что холивары на эту тему давно закончились, но нет. Автоматизировать процесс — выход. Такие языки как Go и Rust идут со встроенными форматами, поэтому никаких вопросов по этому поводу не возникает. Вот еще рамышления на тему стандартов кодирования: h
anonymous poll

Я за строгое соблюдение стандартов! – 21
👍👍👍👍👍👍👍 54%

Пусть форматтер делает всю работу – 16
👍👍👍👍👍 41%

Как хочу так и пишу, в топку стандарты! – 1
▫️ 3%

Мне все равно, просто пишу код – 1
▫️ 3%

👥 39 people voted so far.

Что-то voter не осилил все сообщение, потерялась ссылка:

Вот еще рамышления на тему стандартов кодирования: http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/

В последнее время часто сталкиваюсь с различными "платформенными" решениями, типа облачный PaaS. Решения клевые, мощные. Но...

Разработал какое-то решение с минимальным рабочим функционалом. Попробовал увеличить на него нагрузку и видишь что оно не справляется должным образом. Что делать?

Конечно же нужно оптимизировать. Первое правило клуба оптимизаторов гласит:

Никогда не оптимизируй вслепую

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

И вот тут и вылезает проблема. Многие PaaS не имеют инструментов профайлинга и оптимизации. Поэтому приходится использовать годами проверенный метод научного тыка 👉☁️...

На самом деле это относится не только к платформам, но и различным библиотекам и фреймворкам

Как вы относитесь как платформенным решениям 📦 (Platform as a Service и другим решениям типа "черный ящик") ?
anonymous poll

Не пользуюсь. Хз что там внутри – 16
👍👍👍👍👍👍👍 43%

Пользуюсь. Нравится – 8
👍👍👍👍 22%

Пользуюсь. Не нравится – 5
👍👍 14%

Не пользуюсь. По другим причинам. – 5
👍👍 14%

Не пользуюсь. Боюсь вендор лока – 3
👍 8%

👥 37 people voted so far.

Софтварная разработка многогранна. Давайте немного отвлечемся от типичного веб-девелопмента и поговорим об испытаниях при разработке игр.

Я люблю Git, и предпочитаю использовать именно его. Но кодобаза игровых проектов очень большая. Не столько из-за кода, сколько из-за различных игровых ассетов (текстуры, аудио и т.д.). Проблема Git в том, что он хранит ВСЁ в локальной копии. А это значит, что он будет хранить и все версии ваших больших бинарных файлов.

Например, на одном из проектов размер всех файлов репозитория игры был 60+ Гб (исключая файлы истории). Теперь представьте размер репозитория, который должен хранить все версии на машине.

Эта проблема останавливала от перехода на Git и приходилось пользовать SVN. Ведь нужно было иметь и полную историю для кода, и все ассеты под рукой. Поэтому --depth флаг был не вариант.

Для новых проектов можно структурировать кодобазу таким образом, чтобы ассеты были в отдельном репозитории (сабмодуль), но вот переезд существующих репозиториев — большая проблема.

И вот теперь, Microsoft (опять удивляет!) объединился с Github чтобы внедрить поддержку GVFS [ http://www.gvfs.io/ ]. GVFS, как раз, решает проблему больших репозиториев. Ведь в Microsoft столкнулись ровно с тем же испытанием, но на кодобазе Windows.

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

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

Однажды я потратил целую неделю на поиск бага, когда мобильное приложение внезапно начинало жутко тупить даже в idle состоянии. Баг оказался в стороннем компоненте, который в случае потери сетевого соединения начинал спавнить кучу потоков!

Но есть случаи и похардкорнее. Забавный случай от инженера из Quora: https://hackernoon.com/solving-the-most-interesting-bug-of-my-career-in-15-steps-1a1ccd337c35

Главное методичность и упорство :)

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

Блоги, в основном, на английском, так как большинство уникальной информации публикуется именно на этом языке.

Поехали:

- https://engineering.riotgames.com/ — блог инженерной команды Riot Games (не знаете кто это? Разработчики League of Legends). Обзоры архитектур, конкретных технических решений и других вкусностей!
- http://highscalability.com/ — ресурс с кучей подборок и статей на тему масштабирования приложений
- http://horicky.blogspot.com — блог дата сайнтиста Ricky Ho с большим количеством тематических статей, написанных понятным языком
- http://tutorials.jenkov.com/software-architecture/index.html — неплохая подборка статей с кратким обзором основных архитектур и подходов в программировании

Вот уже много лет всеми правдами и неправдами программисты борятся с проблемами, связанными с null значениями. Tony Hoare назвал изобретение null reference для языка ALGOL W — "The Billion Dollar Mistake":

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare.

И если в языках со сборщиком мусора это грозит всего лишь эксепшеном, то в с++ проблема может повлечь undefined behaviour (http://en.cppreference.com/w/cpp/language/ub) — штука, сулящая много часов безудержного веселья.

Некоторые изобретают свои костыли:

http://www.bfilipek.com/2017/10/notnull.html

Вопрос, зачем? Ведь в C++ есть reference, который не может быть null. Это и есть средство, позволяющее программисту выразить его нежелание возиться с null. Другой способ — Optional типы (std::optional в с++, Optional в Java).

В любом случае, стандарт языка имеет все необходимое для решения проблемы, причем compile-time. Так зачем же люди изобретают свои велосипеды?

Другое дело, когда в стандарте языка нет таких выразительных средств. Что делать? Приходится рассчитывать на средства статического анализа кода. Ребята из JetBrains любят такие штуки.

https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html
https://www.jetbrains.com/help/resharper/Code_Analysis__Annotations_in_Source_Code.html

Но как по мне — это тоже так себе решение. Решение должно быть поддержано на уровне языка. Я уже говорил о том, что дизайн языка C# ведется в открытом формате, в репозитории github: https://teleg.eu/poisonous_johns_lair/3. И это поистине потрясающее решение. Ребята действительно слушают коммьюнити. Вот, например, предложение по борьбе с Null:

https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md — proposal
https://github.com/dotnet/csharplang/issues/36 — discussion

Программисты — ленивые. Каждый раз проверять на null — большой геморрой. Так пусть это делает компилятор. Пусть он бьет нас по рукам за нашу лень 😃.

А как же быть тем, кто пишет на интерпретируемых языках или языках с динамической типизацией? Я забыл упомянуть о еще одном решении: монада Maybe — https://curiosity-driven.org/monads-in-javascript#maybe . Конечно, имплементации этого подхода не всегда удобны, но все же это может быть неплохим решением.

Привет и спрошедшими праздниками!
Надеюсь всем удалось хорошенько отдохнуть.

Наткнулся на такую забавную статью о буднях разработки Walking Robots, знаете такую игрушку?

https://habrahabr.ru/company/pixonic/blog/346374/

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

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

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

Посему, "лучшее — враг хорошего". Перфекционизм — это болезнь. Хотя она и имеет положительное влияние, нужно уметь вовремя остановиться. И это важный скилл! Этот скилл является великим преимуществом.

Часто я нахожу себя со свербящим чувством внутри, толкающим меня исправить этот ужасный код. Но, черт возьми, стоит ли тратить на это время, если этот кусок кода выполняется очень редко? Что это даст?

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

Люди боятся рефакторить. А без рефакторинга проект обречен. Команде необходимы люди, которые смогут заниматься этим нелегким делом.

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

Важно понимать не только "как" рефакторить, но и зачем, когда и где.

От себя могу порекомендовать прекрасную книгу от моего любимого Мартина Фаулера и других крутых перцев:

https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

Забавная статья о том, как эволюционировал DevOps, на примере собственного опыта автора.

Автор описывает как менялись процессы при разработке веб сайтов:

- Редактирование сорцов в Dreamweaver и заливание их на ко-локейшн сервер по FTP
- Версионирование кода, созданием отдельных папок под каждую версию
- Конфигурация и поддержка серверов собственными силами
- Бесонная ночь из-за сгоревшего на сервере блока питания
- Появление виртуальных машин
- И, наконец, появление облачных PaaS и инструментов автоматизации CI/CD процессов

Автор показывает перспективу того, насколько все стало легче с использованием Azure AppService и Visual Studio Team Services,
когда по коммиту в Git репозиторий происходит автоматическая сборка и деплоймент на тестовую среду, а по одному клику, без
даунтайма это можно шлепнуть в лайв. Как сервис автоматически реагирует на рост и спад нагрузок, скалируя инстансы серверов.

Работать над бэкэндом становится проще в контексте Operational вещей.

С такими сервисами как Azure AppService и Azure Functions даже инди разработчикам под силу за 5 минут развернуть сервер.

https://medium.freecodecamp.org/the-life-changing-wonder-of-continuous-integration-and-deployment-97f833505eea

Статья неоднозначная, но есть о чем задуматься.

Вредоносный код в OSS продукте? Боже упаси!

https://habrahabr.ru/company/ruvds/blog/346442/

Количество параноидальных разработчиков с синдромом "not invented here" может возрасти.

С другой стороны, ну нельзя же все самому писать.

Для контраста другая статья, о когда не стоит писать все самому, и чем это может помочь.

https://medium.freecodecamp.org/when-writing-code-is-a-waste-of-time-6602af8cb759

Войти в индустрию геймдева может быть сложно. А не выпасть из нее — еще сложнее =). После входа легче не становится, и вошедший может испытывать великое давление.

На твиттере есть забавная ветка обсуждения, где известные игровые разработчики, чтобы дать понять, что ВСЕ делают ошибки, рассказывают о своих фейлах при разработке ААА игр:

https://twitter.com/Danim8tion/status/950465438806257664

Несколько хайлайтов от меня:

- First code I ever submitted (a simple if-statement) I somehow broke reloading of all weapons in Battlefield: Bad Company

- I leaked a new character for Evolve in Twitch chat via a copy pasta fail.

- The opening/closing valve animation in first Mirror’s Edge is turning the valve the wrong way. I didn’t know which way you turn to open/close a valve so I think I just guessed.

- In GoW 3 Kratos has a magic that summons Spartan shields and spears. I did not realize I animated all the shields upside down until of after the game shipped! To this day I told everyone I intended it because they where exiled Spartans showing defiance! Don't tell anyone

- As a junior TA, While trying to get everyone’s Perforce workspace root mapped to the same location in everyone’s hard drives I accidentally deleted like... a month or two of animation that hadn’t been checked in.

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

Такие решения предлагают многие платформы: Steam, Microsoft, Sony, Playfab и т.д.

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

О них и рассказывается в этой статье:

http://joostdevblog.blogspot.ru/2017/10/working-with-generic-room-based.html

В геймдеве #OpenSource как-то не очень сильно почитается. Но посмотреть все же есть на что.
Лист #OSS крутотенюшек для Unity и игровой разработки в целом:

- UniRx — мой любимые расширения для реактивного программирования, специально для Unity
- Nakama — впечатляющий фреймворк для разработки игровых серверов. Вполне себе альтернатива фотону: авторизация юзеров, мультиплеер (реалтайм, пошаговый, пассивный), чат, социальные фичи (друзья и т.д.), сохранение состояния, матчмейкинг, дашборды и метрики. Одна странность — использует cockroachdb для хранения данных
- Crystal AI - быстрый и расширяемый фреймворк для utility based AI. Кстати untility based AI далеко не самый популярный подход, но он точно заслуживает внимания:
+ статья
+ видео с GDC
- Prime31 — команда, у которой много OpenSource проектов, среди которых
+ Твинер
+ Обджект пул
+ 2D Character Controller
+ Библиотека для поддержки gestures
+ Система сообщений (замена SendMessage в Unity)
+ Библиотека для поддержки переходов между сценами
+ и многое др.
- Fungus — фреймворк для очень простой (даже визуальной) разработки игр типа графических новел, hidden object и других похожих
- StrangeIoC — Dependency Injection фреймворк, разработанный специально для Unity

Масштабируемый реалтайм сервер на .Net Core Orleans, WebSockets и серверном Redux.

После этой статьи есть о чем задуматься. Например, использование Redux на серверной стороне. Идея великолепна. Больше всего мне нравится "time-travel" по стейту. Это незаменимо при отладке проблем бизнес-логики! Вместо многочасового копания логов, можно посмотреть цепочку событий и историю состояний, которые привели к проблеме.

Многие разработчики не слышали о модели акторов. Но в игровой разработке этой модели можно найти много применений.

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

- простота разработки. Использование асинхронного обмена сообщениями сильно упрощает жизнь когда приходится иметь дело с concurrent computing;
- масштабирование. Модель Акторов позволяет создавать огромное количество акторов, каждый из которых отвечает за свою частную задачу. Принцип shared nothing и асинхронный обмен сообщениями позволяет строить распределенные приложения, горизонтально масштабируясь по мере надобности;
- отказоустойчивость. Сбой одного актора может отлавливаться другими акторами, которые предпринимают соответствующие действия для восстановления ситуации (например, механизм супервизоров из Erlang-а).

Так где оно может пригодится при разработке игр?


- Акторы — это, по сути, конечный автомат (пример Akka.FSM), что является стандартным паттерном для игр
- Большинство действий в игре связано только с одним игроком, так что сервисы типа авторизации, магазина, инвентаря и т.д. могут быть легко представлены в виде акторов. Плюс ко всему вы получаете realtime систему, т.е. можете отгружать все обновления на клиент. Забудьте про REST API и поллинг
- Модель акторов имеет встроенную систему маршрутизации сообщений, с помощью них легко сделать чать для игры, представляя комнаты и пользователей как отдельных акторов. Броадкастинг из коробки :)
- Релтайм ПвП, в очень грубом сравнении, тоже похоже на чат. Юзеры отсылают свой ввод на сервер, сервер его обрабатывает, а потом броадкастит обновления всем в комнате

Хочу хочу хочу! Где взять?

- Для новичков, проще попробовать Project Orleans от Microsoft (использованный в самой первой статье) с системой виртуальных акторов. Система виртуальных акторов на порядок прощей традиционной. Плюс ко всему это позволяет масштабироваться без головной боли
- Традиционным акторным фреймворком считается Akka, оригинально разработанный на Scala. Официально есть реализации Scala и Java. Но людям, работающим с Unity/C# ближе будет порт Akka.Net.
- Для C++ решения рассмотрены в упомянутой статье с хабры:
+ QP/C++
+ Asynchonous Agents Library от Microsoft
+ C++ Actor Framework
+ SObjectizer