Я решил объяснить один из алгоритмов генерации карты, используемых в моей игре In the House of Silence. Главное преимущество этого способа заключается в том, что в отличие от других алгоритмов, он никаким образом не может сгенерировать карту с разделёнными частями.

Генерация идеального лабиринта

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

Для понятности я привёл псевдокод, описывающий алгоритм Прима. Будет довольно просто приспособить его под любой язык программирования.

Мы в PushAll обрабатываем несколько тысяч запросов в секунду для получения статистики доставки и открытия уведомлений и для передачи контента оповещений. Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.

Стараясь все больше операций перенести на быстрые NoSQL хранилища вроде Redis, мы хотим знать как эффективнее его использовать и не будет ли у нас проблем с большим количеством соединений.
Также для работы мы используем форки PHP и нам было интересно, а как поведет себя Redis, если мы будем делать несколько тысяч соединений в одновременно в нескольких потоках. Мы решили поделиться с сообществом нашими тестами.

(у учебника по Основам React вышло второе издание, Redux-учебник в процессе обновления)

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

Курс про Redux попал в официальную документацию.

Оба руководства бесплатны и выложены на gitbook (можно скачать PDF, ePub, mobi).

В текстах нарочно участвуют термины переведенные на русский (например, состояние), английские (state), либо английский термин написанный по-русски — стейт. Считаю это допустимым, и даже более того, удобным для читателя.

Решил собрать в одной статье короткий рецепт приготовления страницы, которая круто шарится во все основные соцсети. Тем, кто вообще не в теме, придётся сначала прочитать про Open Graph protocol.

Введение

Прежде всего определимся с терминами. Есть много разных представлений о том, кто же такой full stack разработчик, кто-то даже вполне обоснованно считает, что такие разработчики — это миф, но в этой статье будет иметься в виду разработчик, который обладает знаниями и умениями, позволяющими с нуля написать некий софт и вывести его в продакшн. При этом софт может быть рассчитан на web платформу, мобильные приложения или десктопные. Идеальный full stack разработчик — это тот, кто владеет в какой-то мере всеми платформами и может разработать и установить на них свой софт. Но это действительно скорее миф.

Возможно, по заголовку кому-то покажется, что это жалобный пост, который говорит о том, как плохо живётся неквалифицированному школьнику, который похватал всего из разных статей в интернете. Нет, пост не жалобный, мы говорим про full stack, а не full slack, и в конце будет так же рассмотрен список плюсов. И мы будем рассматривать не школьника, а разработчика с опытом работы в пять и более лет. Просто посмотрим, какие минусы есть в таком развитии.

В данном посте я бы хотел рассказать о том, как нужно правильно выстраивать RESTfull API для AngularJS и других фронтенд фреймворков с бекендом на Symfony.

И, как вы уже наверное догадались, я буду использовать FOSRestBundle — замечательный bundle, который и поможет нам реализовать backend.

Здесь не будет примеров как работать именно с Ангуляром, я буду описывать исключительно только работу с Symfony FosRestBundle.

Для работы нам так же понадобится JMSSerializerBundle для сериализации данных из Entity в JSON или другие форматы, исключения некоторых полей для той или иной сущности (например пароль для API метода получения списка пользователей) и многое другое.

Подробнее можете почитать в документации.

Предлагаю вашему вниманию перевод статьи Go from PHP engineer's perspective с сайта sobit.me.

Будучи PHP программистом, задумывались ли вы об идее изучения других языков программирования?

Уже много лет выбор многих компаний падает на PHP для создания полноценных монолитных приложений. Более того, за последние 5 лет фреймворки (Symfony, Laravel, Zend), инструменты (Composer, Monolog) и стремительно растущее сообщество (PHP-FIG) помогли многим разработчикам в создании программного обеспечения на уровне предприятий. Многие компании, такие как Facebook, Yahoo!, Wikipedia, Wordpress, Tumblr, начинали свою историю с PHP, и это не помешало им стать успешными в последующие годы.

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

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

Написал недавно движок для синхронизации данных, имеющий первоклассную поддержку оффлайна. Например, можно уйти в оффлайн, изменять данные, закрыть браузер, открыть браузер, открыть сайт (выйти в онлайн) и данные смержатся без потерь. Также во время онлайна данные между клиентом и сервером синхронизируются в реальном времени. Хочу рассказать, в чём была идея, какие есть подобные решения/технологии и кому это может пригодиться.

Перевод статьи Vitalij Mik Clean Code Architecture and Test Driven Development in PHP

Понятие «архитектура чистого кода» (Clean Code Architecture) ввел Роберт Мартин в блоге 8light. Смысл понятия в том, чтобы создавать архитектуру, которая не зависела бы от внешнего воздействия. Ваша бизнес-логика не должна быть объединена с фреймворком, базой данных или самим вебом. Подобная независимость даёт ряд преимуществ. К примеру, при разработке вы сможете откладывать какие-то технические решения, например выбор фреймворка, движка/поставщика БД. Также вы сможете легко переключаться между разными реализациями и сравнивать их. Но самое важное преимущество такого подхода — ваши тесты будут выполняться быстрее.

Просто подумайте об этом. Вы действительно хотите пройти роутинг, подгрузить абстрактный уровень базы данных или какое-нибудь ORM-колдовство? Или просто выполнить какой-то код, чтобы проверить (assert) те или иные результаты?

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
Информация — основа любого приложения или сервиса.



Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?

Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.

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





Думаю, идею вы уже уловили. Примеры можно приводить бесконечно (вот ещё один: на википедию не за дизайном ходят. Более того, часть информации с википедии выводится сразу в поисковой выдаче, без открытия даже самого сайта), и если думаете, что в вашем случае это неприменимо — напишите в комментариях (или на почту / в личку), и я объясню, почему всё же применимо.

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

Я расскажу, как организовать работу с информацией так, чтобы это было:
1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
2. Удобно для пользователей — легко документировать, понятно как использовать.
3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.

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

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

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

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

Кроме того я проверяю, что соотношение длины и ширины комнаты не слишком велико. Нам не нужны как идеально квадратные комнаты, так и сильно вытянутые.

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

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

7. Поскольку нам не нужно, чтобы все комнаты были связаны со всеми, мы строим минимальное остовное дерево. В результате получается граф, в котором гарантированно можно достичь любой комнаты.

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

9. Чтобы превратить его в коридоры, для каждого ребра строится серия прямых линий (в форме Г), идущих по рёбрам графа, соединяющим комнаты. Тут нам пригождаются те клетки, которые остались неиспользованными (те, что не превратились в комнаты). Все клетки, накладывающиеся на Г-образные линии, становятся коридорами. А из-за разнообразия размеров клеток стены коридоров будут неровными, что как раз хорошо для подземелья.

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

Для новичка, экосистема вокруг React (как и фронтэнда в целом) может показаться запутанной. Этому есть несколько причин.

• Изначально, React был нацелен на экспертов и ранних последователей
• Facebook открывает исходный код только тех продуктов, которые использует сам, т. е. не нацеленные на проекты-меньше-чем-Facebook
• Огромное количество гайдов по React совершенно разной сложности

Здесь и далее, я предполагаю, что вы уже знакомы с HTML, CSS и JavaScript.

С наступившим новым годом, хабровчане!

2015 год был очень насыщенным для мира PHP: это и долгожданный релиз 7-ой версии, и мажорное обновление многих фреймворков, и множество многообещающих RFC.

Для Php Inspections (EA Extended) прошедший год был тоже очень насыщенным: проект увидел свет, очень быстро повзрослел и смог сделать мир PHP чуточку лучше (symfony2, symfony 1.5, PHP CS Fixer).

Напомню, что Php Inspections (EA Extended) — это отдельный плагин, расширяющий возможности штатного анализа в PhpStorm и Idea Ultimate. Ранние анонсы на хабре: раз, два, три.

Далее (под катом): несколько опросов и возможность повлиять на выбор стратегии на 2016 год.

Хочу рассказать о своем эксперименте по проверке «Теории шести рукопожатий». На написание этого материала меня вдохновила статья «Анализ дружеских связей VK с помощью Python» (чтобы избежать повторений, в дальнейшем я буду ссылаться на нее). Так как в целом задача мной была поставлена по-другому, да и использованные методы тоже отличаются, то я решил что это может быть интересно.

Случалось ли c вами, долго работая в одной компании над одним и тем же проектом, начинаешь задумываться о смене обстановки, используемых технологий и самого проекта. Раньше я был уверен, что из этой ситуации один выход — найти новую работу. Эта статья, перевод которой мы публикуем, поменяла мое мнение. В ней описывается подход, благодаря которому можно сделать работу программиста нескучной и помогающей ему расти и развиваться. Мы, сервис для организации приема платежей PayOnline, предлагаем вам ознакомиться с этой методикой и поделиться ею со своим работодателем, в случае, если вы испытываете подобные, описанные автором проблемы. Ниже идет, непосредственно, перевод.

В мою бытность разработчиком я никогда не задерживался на одной и той же работе более двух лет. В моем случае каждая новая работа была для меня хорошим ходом с точки зрения карьерного роста. И даже несмотря на то, что высокая “текучка” — обычное дело в нашей профессиональной сфере, я не могу сказать, что мои предыдущие работодатели спокойно относились к моему уходу. Некоторые из них упорно пытались сделать так чтобы я остался, но работа становилась для меня настолько скучной, что оставаться я уже не мог. Сразу поясню: мне посчастливилось жить в таких местах, где работы для программистов было больше чем самих программистов. Я понимаю, что вариант со сменой работы доступен не всем.

В EDISON часто обращаются инженеры, желающие добавить сотрудников в команду. Хочется «по-быстрому склепать задачку», воспользовавшись десятком дополнительных разработчиков. Работает ли подобный подход? К сожалению, не всегда. В программировании, как в физике, есть законы.


Собрать толковую команду — настоящее искусство

Прошел уже почти год с тех пор, как мы начали вести блог на Хабре. За это время было описано несколько способов интеграции наших AltegroSIM, виртуальных АТС, CRM и всего остального, облачного, что используется в бизнесе для автоматизации и оптимизации. Для нас самих стало открытием, насколько значимое место сотовая связь занимает в коммуникационном поле любой компании и насколько, даже самая небольшая, на первый взгляд, модернизация/оптимизация, способна упростить жизнь менеджеров, курьеров и их начальников. И дело даже не в прямых затратах на звонки, дело больше в бизнес-процессах. Порой, правильно выстроенная схема взаимодействия мобильных и офисных сотрудников и клиентов не только снижает размер ежемесячного счета от оператора связи, но и влияет на эффективность продаж в целом. Сегодня мы опишем любопытный кейс, который облегчает жизнь классического тандема “служба доставки — клиент”.

3 года назад я поверил в будущее nodejs и начал кампанию по имплементации этого языка в самые “проблемные” сервисы нашего проекта. У нас все получалось — нагрузка падала, стабильность повышалась. Но все же были грабли, о которых захотелось рассказать.

Это не исчерпывающее руководство к действию, просто я делюсь своим опытом, если вы профи в nodejs можете дописать в коментах свои рекомендации, на которые я с удовольствием сошлюсь в статье.

У многих компаний заметная часть продаж идёт через телефон: клиенты звонят с сайта, с рекламных объявлений, с оффлайн-каналов. Отследить, откуда пришел посетитель при онлайн-заказе, давно не проблема. Но в случае с продажей по телефону мы не видим, какая реклама привела его. Эту задачу решает коллтрекинг.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);