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

Если вы разрабатываете free-to-play игры, то вам наверняка интересны вопросы, связанные со сбором и анализом статистики. Почему? Потому что статистика – это важная составляющая успеха free-to-play игр.
Цель моего цикла статей – структурировать разношерстную информацию по данному вопросу, пропустить ее через призму нашего опыта и выдать рекомендации по тому,

• какие показатели стоит отслеживать в играх;
• какие инструменты анализа могут помочь в работе со статистикой;
• какие сервисы сбора и анализа статистики существуют с их достоинствами и недостатками.

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

Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Периодически ко мне обращаются пользователи Хабра со своими идеями создания сайтов. Естественно, почти все хотят на них так или иначе заработать.

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

Они достаточно знают о том, какие способы рекламы использовать, но главный вопрос, который их мучает – о чем сделать сайт?

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

Все это, несомненно, важно, но только после первого шага – выбора тематики проекта.

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

В рамках рабочих задач недавно мною было проведено небольшое исследование на тему целесообразности использования опции prefetchCount при работе с брокером сообщений RabbitMQ.
Хочу поделиться этим материалом в виде слайдов и комментариев к ним.

Тесты проводились на конкретном проекте, но в целом они справедливы для большинства случаев, где обработка сообщений (выполнение задач) занимает хоть сколько-то существенное время (при обработке менее 1000 сообщений в секунду).

* на слайдах вместо слова «подписчик» используется «консумер», в комментариях для единообразия тоже
* рассматривается отдельно взятая очередь с пятью консумерами (C1..C5)

Идеальные условия

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

О чем это

Я долгое время был адептом идей о равенстве, свободе и братстве том, что существует красная таблетка.

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

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

Я не сделаю, возможно, в этом посте никаких открытий. Но сэкономлю вам пару лет, если вы решитесь поверить моему опыту.

Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.

Выкладываю теперь это Введение в Общественное Достояние.

В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.

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


У нас в программе: вольный пересказ спек OAuth2, слабые стороны и Threat Model, 0day на хабретрюк с аутенфикацией.

Крошечная (2 килобайта в минифицированном виде) JavaScript-библиотека Piecon генерирует круговую диаграмму на месте фавикона. API предельно прост и состоит из трёх методов объекта Piecon.

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

Как вы уже догадались из названия статьи, сегодня речь пойдет о самом популярном, разве что после Singleton, шаблоне проектирования MVC, хотя такое сравнение не совсем уместно. Понимание концепции MVC может помочь вам в рефакторинге и разрешении неприятных ситуаций в которые, возможно попал ваш проект. Дабы восполнить пробел, мы реализуем шаблон MVC на примере простого сайта-визитки.

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

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

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

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

Хочу поделиться в вами несколькими трюками, которые помогут сделать работу с Ruby on Rails лучше, быстрее, а также позволят вам много зарабатывать и более лучше одеваться.

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.

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

От переводчика: предлагаю вам перевод начала презентации Michael Fairley — Extending Ruby with Ruby. Я перевел только первую часть из трех, потому что она имеет максимальные практические ценность и пользу, на мой взгляд. Тем не менее, настоятельно рекомендую ознакомиться с полной презентацией, в которой помимо Python приводятся примеры заимствования фишек из Haskell и Scala.

Декораторы функции

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

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

Возьмем Ruby и притворимся, что нам нужно перевести деньги с одного банковского аккаунта на другой. Вроде все просто, так?

def send_money(from, to, amount)
  from.balance -= amount
  to.balance += amount
  from.save!
  to.save!
end