Я обожаю программирование графики! Мы все совершаем ошибки в процессе проектирования и написания кода. Иногда это ошибки логики (когда алгоритм продуман неточно или не до конца), иногда ошибки, возникающие по невнимательности, и ещё много-много вариантов. И что происходит в обычном рабочем процессе? — В списках нет необходимых записей, какие-то числа считаются неверно, вываливаются сообщения об ошибках и прочее. В программировании графики всё немного веселее, ведь часто мы получаем результат, который просто не соответствует ожидаемому. В своём небольшом проекте я решил сохранять такие “результаты” на протяжении всего процесса разработки и хотел бы поделиться ими с Вами.

Всех, кто не любит Android, Live Wallpaper, Minecraft, велосипеды, поток сознания, который слабо привязан к теме и всё около того, хочу сразу предупредить, что их может огорчить содержание этого поста, поэтому продолжайте чтение на свой страх и риск. Оставлю тут также и предупреждение для пользователей мобильного или просто небезлимитного интернета: дальше последует довольно много картинок.

Добрый день.
У меня выдалось свободное время, и я решил написать статью про несправедливо обойденный вниманием паттерн написания api. Он подходит в случае, если у Вас и клиент и сервер содержат сложное состояние, и есть необходимость его синхронизировать. На мой взгляд, социальные игры идеально подходят под это описание. В силу того, что я ещё не достиг того уровня мастерства, когда могу писать статьи про программирование без кода, спешу предоставить пример, демонстрирующий данный подход. Посмотреть код можно на github: https://github.com/dbalakov/studio_game.

Roses are red
Violets are blue
All of my base
Are belong to you

Локализация игр — крайне благодатная тема для IT-юмора, один из хрестоматийных примеров которого представлен в эпиграфе. Обычно это происходит, когда за дело берутся недобросовестные переводчики, неграмотные любители или пираты. А иногда и сами разработчики в целях экономии берут на себя несвойственные функции, в результате чего появляются мемы вроде вынесенного в заголовок.

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

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

Когда я работал программистом, ко мне нередко подходили с просьбой помочь сделать проект за долю. В некоторых я участвовал. Но очень мало проектов взлетело.
Со временем я стал менеджером проектов, а люди все так же подходят. И сами вокруг делают стартапы. Взлетают единицы.
Почему же?


Быстро разбогатеть и уплыть на собственный остров просто, увы, лишь в мечтах.

Ответ, увы, кроется не в идее, реализации и даже не в рынке. Дело только в голове создателя стартапа. А точнее, в мифах, которыми она полна.

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

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

Китай невероятно похож на Россию — пришли мы к выводу с Алленом Фу, руководителем подразделения Unity Technologies в Китае, после долгой беседы. Оказывается за 18 месяцев работы китайского офиса Юнити, Аллен встретился с теми же самыми культурными, историческими, национальными особенностями ведения бизнеса, с которыми команда Юнити встречается в России.

«Россия в сердце китайцев является частью общей истории. Я думаю наши страны должны намного больше общаться», — размышляет Синь Чжан, отвечающий за техническую поддержку пользователей Юнити в Китае. Он очень удивлен, почему Юнити до сих пор не открыла офис в России и не предоставляет техническую поддержку пользователей на русском языке…

Впрочем, приоритеты в играх у России и Китая отличаются очень сильно.

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

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

Несколько месяцев назад мы с коллегами решили сделать многопользовательскую realtime игру, которая могла бы работать в вебе. Мы решили использовать node.js для нашего сервера. Это решение привело к очень убедительному успеху — наш сервер работал несколько месяцев без единого падения или перезагрузки процесса.

Мы решили написать нашу игру на node.js, потому что мы слышали много хорошего об этой платформе и очень хотели немного с ней поиграть. И это было потрясающе — мы очень быстро вошли в тему. Для node.js существует множество любопытных библиотек, способных решать абсолютно разные задачи. Побочным преимуществом использования node для серверной части является, собственно, javascript — очень простой в обращении язык. Это позволило нам сфокусироваться на проблемах, которые встречаются во всех realtime играх, без лишней суеты, ограничений и необходимости компилировать код, как это случается при использовании менее динамических языков.

Также node.js проявил себя как очень легковесный язык, даже в моменты пиковой нагрузки. Для нашей игры, процесс node.js использовал только один поток и потреблял всего около 3-4% CPU при одновременной работе 8-10 копий игры, каждая со своим собственным движком обнаружения столкновений.

Когда говорят про разработку игр, обычно речь идет о шейдерах, графике, AI и т.д. Крайне редко затрагивается серверная часть игровых проектов, а ещё реже — базы данных. Исправим это досадное недоразумение: сегодня я расскажу о нашем опыте работы с базами данных, который мы приобрели в ходе разработки Аллодов Онлайн и нашего нового проекта Skyforge. Обе эти игры — клиентские MMORPG. В первой зарегистрировано несколько миллионов игроков. Вторая разрабатывается студией в строжайшей секретности в недрах Allods Team.

Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.

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

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

Дзен Angular

• Хорошо отделять манипуляцию DOM-ом от логики работы приложения. Это существенно улучшает тестируемость кода.
• Хорошо считать, что автоматизированное тестирование приложения настолько же важно, насколько и написание самого приложения. Тестируемость очень сильно зависит от того, как структурирован код.
• Хорошо отделять разработку клиентской части от серверной. Это позволяет вести разработку параллельно и улучшает повторное использование на обеих сторонах.
• Хорошо, когда фреймворк ведет разработчика по всему циклу разработки приложения: от проектирования UI через написание бизнес-логики к тестированию.
• Хорошо, когда распространенные задачи становятся тривиальными, а сложные — упрощаются.

AngularJS представляет собой комплексный фреймворк. В стандартной поставке он предоставляет следующие возможности:

• Все, что вам нужно для создания CRUD-приложений: data-binding, базовые директивы для шаблонов, валидация форм, роутинг, deep linking, повторное использование компонентов, dependency injection, инструменты для взаимодействия с серверными (RESTful) источниками данных.
• Все, что вам нужно для тестирования: средства для модульного тестирование, end-to-end тестирования, mock-и.
• Шаблон типового приложения, включающего в себя структуру каталогов и тестовые скрипты.

AngularJS разрабатывается сотрудниками Google и используется, как минимум, в одном сервисе Google — DoubleClick.

Достаточно вольный перевод заметки 7 reasons why angularJS rocks.


Я backend-разработчик и мир Javascript фреймворков для меня достаточно нов, хотя в последние полгода мой интерес к ним сильно растет. Причина проста: я считаю, что стек технологий REST + JSON + Rich JS все больше подходит для широкого круга веб-приложений. Такой подход помогает победить дерьмовую сомнительную концепцию MVC в серверных приложениях. Почему MVC можно считать вредным — это отдельная история, сейчас лучше поговорим об AngularJS.

Что в AngularJS особенного?

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

Под удобством в первую очередь подразумевается возможность сортировки таблицы со списком материалов и работа без перезагрузки страницы. Если материалов в таблице становится много, то возникает задача разбивать её на страницы.

Всем известный jQuery-плагин tablesorter с tablesorterPager-ом и менее известный, но гораздо более функциональный DataTables хороши, но обладают некоторыми недостатками. Главный из них — сложность динамического добавления новых строк в таблицу (после добавления строки в таблицу, новая строка потеряется при следующем вызове сортировки). tablesorter вообще не даёт средств для добавления строки в свой кэш, DataTables предоставляет широкое и функциональное API для управления внутренним представлением таблицы, но это API довольно многословно и не очень гибко.

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

Сразу приведу, что получится в итоге (кликабельно):

Большинство web-приложений и web-фреймворков используют архитектуру, не позволяющую разделить ui и backend разработку. Тем самым нет возможности разделить команду на узкоспециализированных frontend и backend разработчиков. Вне зависимости от предпочтений разработчика ему приходится иметь понимание как о слое представления, так и о слое логики. Если ui-разработчик знает только о том, как запустить сервер, и о модели данных — это огромная удача. В плохих случаях ui-разработчику необходимо провести полную сборку проекта чтобы увидеть изменения строчки в javascript файле, или знать о языке jsp файлов чтобы поменять стиль элемента. Формирование и передача на сервер обработанных html файлов так-же пагубно влияет на производительность сервера и сети.

Всем доброго дня!

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

В Valve мечтают работать многие, и это ни для кого не секрет. Если вам доводилось видеть их руководство для новых сотрудников ("Handbook for New Employees"), то вам определенно знаком уникальный дух работы в этой компании. Но команда, сделавшая такие игры, как Half-Life, Team Fortress 2, Left 4 Dead 2, DOTA 2 и Portal, обычно принимает в свой штат исключительно опытных и талантливых людей — в то время как школьникам и студентам остается только мечтать о работе там.

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

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

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

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

Поехали?

На прошедшем неделю назад чемпионате мира по командному программированию ACM ICPC 2013 было 11 задач, одну из которых за отведённое время не смогла решить правильно ни одна из команд.

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

В этом году на ACM ICPC был 21 аналитик из Швеции, Нидерландов, США, Словакии, Беларуси и России. И 10 из них были из Яндекса. Все они в разные годы были призёрами ICPC. Специально для Хабра они разобрали все задания чемпионата.

Как получить работу инженера?

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

# x = количество компаний, в которых ты проходил собеседования

# y = количество предложений о работе, которые ты получил

рейтинг = 100 * log(x) * y / x


Если твой рейтинг < 90, обязательно прочти это. Если > 120, возможно, тебе это не нужно, но, все равно прочти.

Наверняка вы видели такую картинку.

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