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



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

КДПВ: текущее распределение проектов в геймдеве, одна Белоснежка и семь гномов.

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

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

Сразу скажу, что опытным программистом откровения не будет, грабли тривиальные.
Все знают, что в моделях недопустимо использовать суперглобальные массивы $_POST, $_SESSION, $_SERVER и т.д., поскольку это делает невозможным усложняет тестирование кода и его повторное использование. Но если суперглобальные массивы, всё-таки, при желании можно «хакнуть» (разумеется это уже за гранью добра и зла), то другую менее очевидную зависимость от глобального окружения — уже никак.
Я говорю о времени — такую зависимость вы добавляете в свой код, когда используете в php-модели time() ( date() без аргумента timestamp) или в MySql-запросе now() (sysdate в Oracle). «Хакнуть» время сервера, чтобы узнать как поведет себя ваш запрос завтра или вчера — задача нетривиальная.
Как это происходит.

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



От редактора: один из наиболее примечательных моментов в катастрофе, произошедшей с Knight Capital Group – трейдинговой компанией, потерявшей на этой неделе $440 миллионов [статья была опубликована на сайте журнала Wired 08.03.12 — прим. переводчика] – скорость этого коллапса. Новостные сводки сообщили, что большая часть совершенных сделок, приведших к падению биржевых цен и колоссальным убыткам, произошла меньше, чем за час. И это падение, спровоцированное действиями ПО, в очередной раз заставило финансовое сообщество задуматься о том, что гонка за прибылью в итоге может обернуться выбором быстрых, но плохо управляемых и недостаточно «интеллектуальных» программных решений. Мы публикуем эту историю до ее официального выхода в печать в сентябрьском журнале Wired, поскольку она демонстрирует, насколько близко Wall Street подошла к точке, когда такие стремительные падения станут совершаться со все возрастающей частотой, и как далеко готовы зайти трейдеры в погоне за скоростью совершения торговых операций.

На хабре уже проскакивала статья про такие замечательные вещи, как Map, WeakMap и Set, но в действительности реальные возможности этих API не были раскрыты (если я все-таки хорошо воспользовался поиском).
Эти API толком не реализованы нигде, кроме firefox (можно включить в chrome canary), но даже там до недавних пор не поддерживалось использование HTMLElement-подобных объектов в качестве ключей. Polymer, например, убрал только три недели назад

	if (navigator.userAgent.indexOf('Firefox/') > -1)

Чем же они так хороши? По сути Map/WeakMap можно воспринимать как обычные хэш-объекты, только в качестве ключей можно использовать только сложные объекты (Object, Function, Array), так как привязка идет не по содержимому, а по адресу в памяти.
Таким образом появляется возможность привязаться на фронтэнде к

• dom-элементу
• XHR-запросу
• File-элементу

Это дает нам возможность работать без id-шников элементов, делать дата-биндинг в разы быстрее, создать безумную альтернативную реализацию promises и так далее.
Мы будем говорить о WeakMap. Даже не так, мы будем говорить о существующих полифиллах для WeakMap.

За последние шесть лет я добился успеха с тремя моими компаниями («Cube6 Media», «Gravatar» и «GitHub»), и потерпел неудачу с парой других проектов. Я много думал над тем, как все получилось, и определил 3 основных роли, которые необходимы для создания успешных веб-приложений: дизайнер, архитектор и разработчик.

В колледже я провел много времени в комнате с тусклым красным светом, погружая фотопленку и листы бумаги в реактивы. Я вставлял негативы в фотоувеличитель, и печатал изображения на бумаге. Это меня впечатляло. каждый раз, когда я включал яркий свет проектора, я вспоминал поговорку: «Фотография — не более чем рисование светом». На секунду задумайтесь об этом. Когда мы смотрим на фотографию — мы видим только свет, который попал в кадр. Никакие вспышки, софт-боксы, отражатели и задники не помогут вам сделать хорошую фотографию, если свет, который они создают или отражают, направлен неверно. Плохой свет — плохая фотография.

Рано или поздно настройкой резервного копирования рабочих файлов озадачивается любой уважающий себя современный IT специалист. После ряда опечаток/ошибок программистов нашлось время для этого и у меня.
Специфика веб-приложения такова, что рабочий каталог занимает более 50ГБ на жестких дисках, включая в себя около 900 тысяч мелких файлов (картинки, превьюшки, ...). Поэтому в лоб решить задачу с помощью tar и аналогов не вышло. Да и хотелось бы иметь некоторую вариативность хранимых данных, а в случае с полным бэкапом реализация требовала больших затрат на хранение по сути одинаковых данных с небольшими изменениями. Плюс неплохо было бы дублировать копии на удаленном сервере бэкапов для снижения риска потери критической информации в результате краха железа. После скрупулезного анализа поисковых выдач и отбрасывания заведомо неподходящих мне методов, остановился на паре вариантов, навязываемых чаще всего в комментариях к самописным shell-велосипедам энтузиастов.

Часть #1

В предыдущей части цикла мы сделали обзор основных возможностей новой RAD Studio XE5. Сегодня же перейдем к практике. Прежде всего, давайте определимся с задачей.

Постановка задачи

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

Пересчет количества требуемых продуктов.

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

Таймер.

Если вы новичок в кулинарии, то, вам следует использовать рецепты, в которых четко указано время той или иной операции. И таймер на планшете, телефоне или нетбуке вполне может стать удобной заменой кухонному таймеру.
Часто бывает, что несколько операций выполняются параллельно. Каждая операция может иметь свой «таймер».
При этом нас интересует, как «настольная», так и мобильная реализация приложения. Мобильное приложение будет использоваться в качестве пособия для визуализации рецепта и сопровождения процесса подготовки. Настольная версия может быть использована в более расширенном функционале для, например, формирования новых рецептов.

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

Данное приложение мы реализуем для Windows и для Android. Затем на основе единой базы исходных кодов мы сможем выполнить портирование приложения на MacOS и iOS.

Современное общество уже не представляет жизни без фейсбука и твиттера. Аудитория социальных сетей в России на данный момент составляет 54,7 млн. пользователей и продолжает неуклонно расти. Но помогают ли социальные факторы в поисковом продвижении сайтов?

Twitter

Поисковые системы охотно индексируют твиты. У Яндекса даже есть отдельный поиск по твитам. Ссылки в твитах также индексируются, в том числе и непрямые (например, через сервисы goo.gl и др.). При этом твиттер индексируют быстророботы, узнать такие ссылки в выдаче можно по указанной рядом дате или времени:

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

Много лет location.hash был способом в AJAX-приложении заставить работать кнопки «Назад» / «Вперёд» и, например, добавить определенное состояние страницы в избранное и вернуться к нему позже.

Сейчас, когда HTML5 считается нормой, пора обратить свое внимание на History API и забыть про location.hash. HTML5 History API проще для понимания и позволяет сделать URL чуточку красивее (без кракозябры # или #! если вы имеете дело с индексированием ajax приложения).

В первой части разобрались с тем, зачем все это нужно и как я до этого докатился, во второй поговорили о софте. Настала пора остановиться на самом любимом хабравчанами разделе DIY — на железе. Итак, берем текстолит, хлорное железо, паяльник… Хотя нет, стоп, открываем редактор плат. Про паяльник, куда его засовывать, а куда лучше не надо другие лучше меня расскажут. А я расскажу какие платы и датчики трудятся на благо моего умного дома.

Уровень статьи: начальный/средний

Массив в PHP — один из самых мощных типов данных. Он может работать как линейный массив (список), как ассоциативный (словарь) и как смешанный. В качестве ключа массива может использоваться либо целое число, либо строка, причем строка, если она представляет собой целое число (например, «5»), будет конвертирована в целое. Остальные типы, за исключением массивов и объектов, так же конвертируются в целое или строку — подробнее можно прочитать в документации.

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

$foo = isset($array['foo']) ? $array['foo'] : null;
$bar = isset($array['bar']) ? $array['bar'] : null;

Один из способов сделать этот код короче и элегантней — использовать короткую запись тернарного оператора:

$foo = $array['foo'] ? : null;
$bar = $array['bar'] ? : null;

Но такой код выкинет PHP Notice в случе, когда ключ не определен, а я стараюсь писать максимально чистый код — на сервере разработки выставлено error_reporting = E_ALL. И именно в подобных случаях на помощь приходит ArrayObject — класс, к объектам которого можно обращаться используя синтаксис массивов и позволяющий изменять поведение используя механизм наследования.

Рассмотрим несколько примеров изменения поведения.

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

Zephir — Ze(nd Engine) Ph(p) I(nt)r(mediate). Зефир — это компилируемый высокоуровневый язык программирования, предназначенный для написания PHP расширений без использования C. Проект от создателей Phalcon (скомпилированный PHP MVC Framework). О Zephir на Sitepoint
   

JSDB.IO — большая и качественная база нужных скриптов/библиотек/фреймворков на JavaScript. Все распределено по категориям: Animation, Application, Audio, Video, Games и др. Дабы собрать все популярные .js воедино добавлю еще три ссылки: Microjs (множество маленьких полезностей до 5кб), а еще jsdelivr и cdnjs, которые позволяют добавлять собственные скрипты.

Snap.svg — продукт от Adobe Webplatform. Недавно я рассказывал про "достойного конкурента Raphaël" и в комментариях оспоривали эту фразу из за отсутствия поддержки такого же множества браузеров. В разработке Snap участвует автор Raphaël — Дмитрий Барановский, а причина создания новой библиотеки для работы с SVG — невозможность поддерживать все возможности SVG в старых браузерах.

At.js — очень юзабельный скрипт для автозаполнения (в демо используется Emojify). А еще есть более функциональная библиотека для автозаполнения — Typehead от Twitter.

$('.atwho-inputor').atwho({
  at: "@", data: ["one", "two", "three"],
});

Введение

Тема аутентификации и авторизации всегда будет актуальна для большинства web-приложений. Многие .NET разработчики уже успели познакомиться с Windows Identity Foundation (WIF), его подходами и возможностями для реализации так называемых «identity-aware» приложений. Для тех, кто не успел поработать с WIF, первое знакомство можно начать с изучения следующего раздела MSDN. В данной же статье я предлагаю более детально взглянуть на так называемый «claims-based» подход к авторизации пользователей путем изучения того, как это может выглядеть на примере.

Страница проекта на Кикстартер — (Kickstarter link)
Страничка проекта на Фейсбуке — (Facebook link)
Официальный сайт разработчика Kilobite
Твиттер Максима Пашанина Twitter-link
Дебютный трейлер KS кампании Trailer Link

Честно, как на духу, не собирался писать что-либо до завершения еще одного туториала, ибо лучше моей болтовни — хорошая, добрая помощь, вы ясно мне дали это понять (смеется). Но сегодня под вечер увидел эту игру на Kickstarter, и как в случае с SpinTires не удержался. И вовсе не потому, что ее также делают наши соотечественники, и даже не потому, что ролик естественен как пение птиц по утру, но потому, что она… сказочная. И одновременно настоящая. Это не закос (да простят мне подобные формулировки) под ретро, это именно следование заветам, уважение традиций, и одновременно оригинальная подача того чтобы мы знали когда-то и того что мы никак не можем забыть. Предположу, что и не хотим забывать.



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

Часто, при создании достаточно сложных приложений на JavaScript наступает тот момент, когда становиться совершенно непонятно почему приложение перестало работать как надо, или наоборот вдруг заработало. Cвязей между элементами приложения становится так много, что уследить за ними даже с хорошими дебаггером очень трудно. И вот диллема: с одной стороны есть хорошо известная методика создания приложений на JS, столь привычная и глубоко описанная, что недостатков мы уже как бы и не замечаем. С другой стороны есть масса библиотек предлагающих нам перейти на другую сторону попробовать что-то новое. К таким библиотекам относиться и Bacon.js, предоставляя реализацию FRP на JavaScript.

Ручное тестирование — это кропотливый и порой рутинный процесс. Одной из проблем является то что при внесении изменений в код сложно предсказать какие тесты следует проделать заново, чтобы убедиться что все работает так как следует. Для этого прибегают к регрессионному тестированию и повторному прогону всех тестов. Такие операции требуют много времени. Но если вы разрабатываете свои решения на платформе .NET то у вас есть шанс значительно снизить трудозатраты тестировщиков, потому что вы будете точно знать, какие тесты следует провести а какие нет, так как изменения в коде не затронули их поведение. Звучит заманчиво?

Все мы ходили/ходим на собеседования. Каждый раз при подготовке к очередному собеседованию просматриваем основные темы, вспоминаем вопросы, которые нам задавали в предыдущие разы, или вопросы, которые сами задавали. Ниже хочу представить основные вопросы, которые часто (основано на личном опыте) можно получить на собеседовании на должность middle/senior iOS Developer. Так сказать, шпаргалка. Заодно можно проверить свой уровень знания платформы.

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

После того как вы расписали все характеристики будущего продукта, необходимо определить приоритеты в разработке. Первое желание – ранжировать по сложности реализации. Логично, тем более если ресурс ограничен – нет смысла строить “Титаник”, когда для первого преодоления Рубикона нужна просто шустрая и устойчивая лодка. Следуя заветам customer development, вы в будущем будете только наращивать функционал: главное – в архитектуре не промахнуться.

Итак, делаем шуструю лодку. Но выбор все еще непрост – даже из относительно простых деталей нужно определить тот набор, который и станет вашим release candidate. И здесь вам на помощь придет модель, которую придумал в 70-е годы прошлого века японский ученый Нориаки Кано. На “Хабре” уже был текст об использовании его модели для решения задач UX. Этот подход вполне применим и к продуктовым функциям – ведь они тоже отвечают за эмоциональные реакции потребителей. Кано предположил, что таких реакций бывает пять типов: от полной неприязни до прямо-таки восхищения. Эти типы японец изложил на одном графике, где по вертикальной оси отобразил эмоциональную реакцию пользователя (неприязнь – восхищение), а по горизонтальной – “количественное” значение характеристики (нет – много).