Привет, тебе, <%username%>.


В процессе доводки до ума относительно старенького системного блока пришла мне на ум мысль модернизировать систему охлаждения центрального процессора. Причина банальна — шум от вентилятора.
В своё время при покупке был установлен Zalman CNPS9300 AT. Кулер красивый и достаточно холодный для AMD Phenom II X4 BE, но как выяснилось сразу и подтвердилось в дальнейшем множеством отзывов в интернете, — крайне шумный даже на низких оборотах.
Т.к. к радиатору претензий не было, плюс руки чесались что-нибудь покрутить, да и подрастающему поколению захотелось какой-нибудь урок преподать, решил я не менять весь холодильник полностью, а попробовать заменить только вентилятор.
Если сделать очень краткий реферат всей статьи, то он уместится в две фотографии:

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

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

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

Сегодня я расскажу о реализации шейдера, позволяющего сделать fade in/out по палитре, как это делалось в старых NES-играх и т.п.

Суть состоит в том, что при наличии ограниченной палитры цветов нельзя было постепенно затемнить (или наоборот вывести из темноты) картинку, т.к. просто напросто не существовало нужных цветов в палитре. И это решалось путем использования разных цветов, которые воспринимаются как более темные. То есть нужно вам сделать fade in желтого объекта, а в палитре нет темно-желтых оттенков — вот и приходится сначала делать объект синим (выглядит темным), потом — красным и т.п.

Ниже я покажу, как выглядит конечный вариант написанного шейдера:



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

К сожалению довольно сложно найти хорошие материалы по web-components на русском языке, поэтому мы с filipovskii_off решили перевести эту небольшую статью от Rob Dodson.

Эх… Markdown… Отличная штука! Я, честно говоря, не писал бы этот пост, если бы не Markdown. Много раз я пытался начать блог, но каждый раз находил процесс написания слишком ограниченным, как в GUI так и в HTML режиме WordPress. Markdown всё изменил для меня. По-моему, нам давно пора сделать его полноценной частью инструментария разработчика.
Сегодня я покажу вам, как создать тег Markdown с помощью Polymer, Web Components фреймворка от Google.

Github

Если хотите следить за ходом создания тега, хватайте код с Github.

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

В прошлой статье я обещал, что опишу:

• запуск нескольких процессов для обработки соединений
• межпроцессное взаимодействие
• разделение процессов мастер-воркер
• проксирование вебсокетов с помощью nginx
• запуск из консоли
• интеграция с вашим фреймворком на примере yii
• демонстрация

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

Поговорим на этот раз о технологии. В этой статье я расскажу и покажу, как в Unity создать шейдер для стилизации графики под старые ЭЛТ. Такой шейдер подойдет для пиксель-арта и для стилизации картинки под древнюю технику. Злоупотреблять им не стоит, но иногда использовать к месту — можно. (Специально уточню — я не предлагаю использовать такой эффект постоянно. Но, например, в заставках — он может прийтись к месту).



И сразу оговорюсь — я не владею глубинным пониманием шейдеров, а от читателя жду и того меньшего. Так что буду писать из расчета, что вы про шейдеры не знаете ничего, или почти ничего. И да, я попытаюсь вам пояснить самые базы работы шейдеров, так что если вы ничего о них не знаете — welcome!

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

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

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

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

template <class T>
bool someFunc(T t)
{
	if (t.someCheck()) {
		t.someAction(0);
	}
}

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

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

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

Сразу хочу сказать, что все книги на английском. Часть из них можно найти на русском, но без английского на уровне чтения и прослушивания подкастов будет тяжко – на русский клевые вещи об управлении продуктами переводят медленно и нехотя. Второй момент – чтение книг из этого списка не сделает из вас менеджера продукта. Как и книжка С++ за 21 день не сделает из вас С++ разработчика. Просто уровень вхождения в окологуманитарные профессии пониже, и это иногда создает напрасные иллюзии.

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

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

Некоторое время назад я выбирал библиотеку для работы с вебсокетами. На просторах интернета я натыкался на статьи по интеграции node.js с yii, а почти все статьи о вебсокетах на хабре ограничивались инструкциями к тому, как использовать phpdaemon.

Я изучал библиотеки phpdaemon и ratchet, они достаточно монструозны (причём используя ratchet для отправки сообщения конкретному пользователю рекомендовано дополнительно использовать wamp). Мне не совсем было понятно для чего использовать таких монстров, которые требуют установку других монстров. Почитав исходники этих, а также других библиотек, я разобрался как всё устроено и мне захотелось написать простой вебсокет-сервер на php самостоятельно. Это помогло мне закрепить изученный материал и наткнуться на некоторые подводные камни, о которых я не имел представления.

Так я решил написать необходимый для меня функционал с нуля.

Получившийся код и ссылка на демонстрационный чат в конце статьи.

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

Быстрое изменение состояния посреди анимации

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

@keyframes toggleOpacity {
  50% { opacity: 1; } /* Turn off */
  50.001% { opacity: 0.4; }

  /* Keep off state for a short period */

  52.999% { opacity: 0.4; } /* Turn back on */
  53% { opacity: 1; }
}

Вот как я использовал этот приём для имитации мигающей неоновой вывески с помощью прозрачности и свойства text-shadow:

Множество людей интересовалось установкой HHVM на Nginx для использования с Laravel. Давайте приступим.

HHVM (или HipHop Virtual Machine) — это виртуальная машина, предназначенная для выполнения программ, написанных на PHP. Использует технологию JIT компиляции для увеличение скорости выполнения байткода.

Вступление

Как и в большинстве моих статей, я буду использовать Ubuntu 12.04 LTS как сервер для установки нашего добра. Однако, мы вполне можем установить это все на Mac с помощью Brew (nginx и hhvm). Информация об установке HHVM на другие платформы (включая новые версии Ubuntu) может быть найдена здесь.

Ну что же, поехали!

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


Под катом gif-файлов мегабайт на 10.

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

Память и текстуры

Если Вы уже занимались разработкой мобильных игр, то основное зло не в нехватке ресурсов CPU/GPU, а в нехватке памяти. Именно о памяти нужно думать в мобильной разработке в первую очередь. В Windows Phone 7 ограничение было в 100мб, в Window Phone 8 стало получше, но не сильно:

Тип лимита	Тип приложения	Телефоны с маленьким количеством памяти	1- Гб телефоны	2-Гб телефоны
Default	XNA или native	150 MB	150 MB	150 MB
Default	XAML/.NET excluding XNA	150 MB	300 MB	300 MB
Higher	All app types	180 MB	380 MB	570 MB

И если Вы разрабатываете игру, в которой довольно большое количество спрайтов (уложенных, конечно же, в атласы) — то вы рано или поздно задумаетесь о количестве этих самых атласов и сжатии текстур.
Стандартный атлас, с которым работают все более или менее уважающие себя устройства — это 2048х2048 пикселей. Что в несжатом виде (32 bits per pixel) будет занимать аж 2*2*4 = 16 Мб памяти. Тогда на выручку приходят форматы сжатия текстур, в нашем случае это DXT сжатие.
Сжатые текстуры не только требуют значительно меньше памяти видеокарты, но и вообще отображаются быстрее, чем несжатые текстуры, за счет снижения требований к пропускной способности. Но некоторые качества изображения могут быть потеряны из-за сжатия. Тем не менее, снижение объема памяти позволяет увеличить разрешение текстур, которые будут использоваться, что действительно может дать существенный выигрыш в качестве.

Привет Хабр!
Недавно я разработал чат на вебсокетах для своего сервиса http://internetsms.org/chat.
При реализации, я столкнулся с тем, что в интернете большинство чатов сделаны с использованием повторяющихся ajax запросов, которые проверяют новые сообщения по заданному промежутку времени. Такой подход для меня был неприемлем, т.к при наплыве пользователей, нагрузка на сервер вырастет экспоненциально. На самом деле, есть более интересные варианты реализации:
Long polling
Клиент отправляет на сервер «долгий» запрос, и при наличии изменений, сервер отправляет ответ. Таким образом, число запросов снижается. Кстати, эта технология используется в Gmail.
Web sockets
В html5 появилась встроенная возможность использовать WebSocket соединения. Парадигма запрос-ответ здесь вообще не используется. Между клиентом и сервером один раз устанавливается канал связи. На сервере работает один демон, который обрабатывает входящие соединения. Таким образом, нагрузки на сервер практически нет даже при большом количестве пользователей онлайн.

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

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

— В кэмелкейсе пишем?
— Да, как обычно, в кэмелкейсе
… прошло две недели…
— Мы ж в кэмелкейсе договаривались!!!

В нашем случае не было разве, что последней фразы.
Уже давно хотелось как-то это систематизировать, но никак не доходили руки до выбора между стилями от jQuery, Google, ideomatic.js и Crockford.

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

• Оригинал: https://github.com/airbnb/javascript
• Перевод: https://github.com/uprock/javascript

Прочитать крайне советую как минимум всем начинающим js-разработчикам.

Добрый день, Хабравчане!
Хотелось бы рассказать об одном из способов отрисовки освещения и затенения в 2D-пространстве с учетом геометрии сцены. Мне очень нравится реализация освещения в Gish и Super MeatBoy, хотя в митбое его можно разглядеть только на динамичных уровнях с разрушающимися или перемещающимися платформами, а в Гише оно повсеместно. Освещение в таких играх мне кажется таким «тёплым», ламповым, что непременно хотелось нечто подобное реализовать самому. И вот, что из этого вышло.

Вместо предисловия

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

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.