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

Процедурно-генерируемый контент «правильных» игр — Diablo, Rogue, Spelunky, Daggerfall, Elite, Spore и даже аналогов Football Manager — не перестает удивлять. Он позволяет иначе взглянуть на дизайн и подчеркивает элегантность основных показателей системы. С его помощью вы экономите время и можете зарабатывать. Именно благодаря ему Skyrim и Minecraft привлекают огромное количество игроков, которые не изменяют своему выбору даже через несколько лет после выхода этих продуктов. Процедурная генерация – надежное основание, на котором построена концепция столь ожидаемой "No Man’s Sky" от Hello Games.

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

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

1.Crusader Kings II: Сложные родственные связи становятся динамичными благодаря генерируемым персонажам

Предисловие

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

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

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

P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.

Вот теперь всё, вы предупреждены — можно начинать рассказ.

Привет!
У издательств я узнал, что с 1 по 10 января люди читают больше, чем за год. Поэтому небольшой подарок от нас — мы договорились с Даниилом Куком (бывшим геймдизайнером Epic Megagames), взяли и перевели несколько его хардкорных материалов про разработку игр. И засунули их в PDF на сотню страниц.

• Как игры формируются внешней средой: как рынок влияет на сюжет игры (например, из-за уменьшения среднего дохода на игру уменьшается роль открытого мира – слишком долго делать) и так далее. Очень хороший аналитический обзор от гуру с конкретными советами.
• Организация игровых процессов в многопользовательской игре — как собирать игроков вместе, как делать асинхронные взаимодействия и много чего ещё с числами и примерами. Годный хардкор.
• ТОП-5 споров о разработке 2014-го года — прошлогодний материал о том, что за тренды обсуждались. Всё актуально и сейчас.
• Декларация независимости разработчика — американский крик души о том, что «уберите грязные лапы финансового директора от сюжета игры». Ну, примерно.
• Критика критики игр — что делать, если обзоры пишут дилетанты, и как выделиться из балласта.
• Создание эффективных причинно-следственных связей в играх — невероятно полезная вещь для всех тех, кто хочет понять, как работают когнитивные схемы игр. Полезна не только разработчикам, но и для UI/UX-спецов.
• Таблицы трофеев – математика выковыривания лута из трупов врагов. Начинается с ликбеза и стремительно ускоряется до весьма крутых решений.

Вот PDF и полные тексты. Ниже в посте – основные тезисы, если лень читать всё или хочется здесь и сейчас.

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

1. Робоёлка



Если на праздники вам нужно куда-то сходить с детьми, то выбор очевиден — Робоёлка в сокольниках. DIY спектакль в котором актеры и дети делают серее костюмы из картонных коробок и поролона, а затем смотрят спектакль о королевстве роботов где королеву-мать поражает вирус (как я понял) и она строит козни принцессе, в итоге та оказывается выброшенной на свалку где ее находит команда роботов подозрительно напоминающих черепашек ниндзя. Нужно видеть этот момент, когда целый зал детей кричит «Перезагрузи её», «переверни флешку» или «не кликай на этот баннер». Чувствуешь себя очень старым и снова молодым одновременно, странное но приятное чувство. В конце все оказывается хорошо, всех спасает семейный бэкап. Ну и неожиданное появление деда мороза, но я вам этого не говорил.

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

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

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

Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.

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

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

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

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

Я бродил по пустошам в отчаянных поисках водяного чипа, необходимого, чтобы починить машину и спасти своих. Я провёл несчётное количество часов в калифорнийских пустынях, разыскивая «набор для создания Райского сада», чтобы накормить голодающих.

Я искал способ окропить животворящей водой пустыни Округа Колумбия, сражался с супермутантами в тоннелях метро, и потратил будто бы целые годы, играя в казино Нью Вегаса, в то время как Легион Цезаря сражался с Новой Калифорнийской республикой.

Я знаю войну… война никогда не меняется.

Если от этой фразы у вас побежали мурашки – от ностальгии, или от радостного возбуждения, вы понимаете, к чему я клоню. Лучшей историей про ядерную войну стала серия компьютерных игр Fallout.

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

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

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

Одна из таких финансово-расчетных систем получила название «Хавала». Она зародилась в Индостане задолго до появления банковской системы западного образца (по разным оценкам, она работала уже в 8 веке), и до сих пор используется многими гражданами стран Среднего Востока, Африки и Азии в качестве альтернативного инструмента расчетов.

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

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

Для тех, кто хочет погрызть гранит IT-науки, мы продолжаем публиковать список камней повкуснее и пополезнее. Предлагаем вашему вниманию следующую часть списка рекомендуемой литературы, рассчитанной для студентов 3 семестра Технопарка.

Предыдущие части: первая, вторая.

Гуглил информацию по Ansible, наткнулся на статью на Хабре. Прочитал и сильно удивился: ведь можно сделать красивее! Если вы заинтересованы — добро пожаловать под кат!

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

Итак, не так давно у нас появился новый клиент. У него было несколько нетипичных для нас требований: использовать для конфигурирования серверов ansible, контент сайта хранится в git, каждый сайт находится на своей виртуальной машине. Все это не сулило ничего хорошего, так как совсем не укладывалось в стандартную схему «Клиент всегда прав!», и мы начали разрабатывать новую схему. Но обо всем по порядку.

Исходные данные: есть клиент, у которого более 30 сайтов которые надо перенести на нашу площадку. Каждый сайт должен располагаться в отдельном контейнере (мы используем OpenVZ контейнеры). Используется только один внешний IP. Для конфигурирования серверов используется ansible. Для каждого сайта есть архив с конфигурационными файлами. Контент сайта находится в git.

И мы начали творить… Что у нас получилось, можно посмотреть под катом. Забегая вперед, скажу, разворот нового сайта сводится к нескольким командам.