Введение

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

С удовольствием приму критику и выслушаю мнения «другой стороны».

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



Полный код редактора доступен на гитхабе. Готовый редактор можно установить из магазина приложений Chrome.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Вы когда-нибудь думали, как было бы здорово, если бы слитый в один файл и минифицированный яваскрипт код в production-окружении можно было удобно читать и даже отлаживать без ущерба производительности? Теперь это возможно, если использовать штуку под названием source maps.

Если коротко, то это способ связать минифицированный/объединённый файл с файлами, из которых он получился. Во время сборки для боевого окружения помимо минификации и объединения файлов также генерируется файл-маппер, который содержит информацию об исходных файлах. Когда производится обращение к конкретному месту в минифицированном файле, то производится поиск в маппере, по которому вычисляется строка и символ в исходном файле. Developer Tools (WebKit nightly builds или Google Chrome Canary) умеет парсить этот файл автоматически и прозрачно подменять файлы, как будто ведётся работа с исходными файлами. На момент написания (оригинальной статьи — прим. перев.) Firefox заблокировал развитие поддержки Source Map. Подробнее — на MozillaWiki Source Map.

В быстро меняющемся мире IT, да и не только, выигрывают те, кто постоянно развиваются: остановился — значит проиграл. Это справедливо в частности и для CMS. Стараясь идти в ногу со временем, не за горами выход новой версии CMS Drupal 8.

На данный момент, доступна 3 альфа версия Drupal 8. Было создано несколько инициативных групп, работающих над основными направлениями: Управление конфигурациями, Дизайн, Мобильные устройства, Многоязычность и Вебсервисы. Ядро сейчас имеет 1600+ контрибутеров (это примерно в два раза больше чем было у Drupal 7). В новой версии сделано более 500 нововведений и изменений. Ниже я упомяну, по моему мнению, наиболее значимые из них. Изменения описываются по отношению к Drupal 7, т.е. предполагается что читатель знаком с Drupal 7.

По моему скромному мнению, CMS Drupal наиболее близко подошла к понятию «идеальная CMS». Очень многое в Drupal сделано для облегчения жизни разработчиков. В этой статье мне хочется рассказать об основных моментах, которые мне нравятся в Drupal. Материал рассчитан на пользователей, мало знакомых с Drupal. Иногда мне придется говорить очень простые вещи, но именно из-за этих простых мелочей и складывается очень приятное впечатление от Drupal.

Сразу стоит предупредить, что Drupal это не готовое решение. После установки вы не получите настроенную и работающую социальную сеть, интернет магазин и т.д. В Drupal действует принцип «предоставление возможностей по мере необходимости». Именно поэтому на Drupal не делают сателиты и ГС в промышленном масштабе и, возможно, именно поэтому количество рабочих сайтов на Drupal уступает таким CMS как Joomla и Wordpress, любимым CMS строителей сателитов и ГС.

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

Шла четвёртая неделя тяжёлых боёв с Play! Framework 2.1 + Java. Победа неумолимо приближалась, но до полной капитуляции было далеко.
После обнадёживающих новостей про развитие Play! 2.1, например в LinkedIn, было решено попробовать его в одном новом проекте. Испытать его, так сказать, в деле. Что из этого получилось? Я бы сказал, что это была небольшая война между мной и Play! 2.1. Почему? Подробности под катом, а для нетерпеливых:

Краткий вывод

Для штурма надо было брать секретное оружие под кодовым названием Scala. Если встать лицом к лицу с Play! Framework 2.1 и крикнуть со всей силы: «Ты есть Scala-фреймворк!», то он испугается такой прямоты и скромно откроет свои двери в мир больших возможностей.
«Не знаете Scala?» — «Используйте Play 1.2».
«Хорошо разбираетесь в Scala?» — «Обязательно попробуйте Play 2.1. Но всё равно запаситесь терпением».

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

Game Maker — платформа разработки (в начальной концепции 2D) игр. На данный момент наиболее популярны Game Maker 8.0\8.1 и Game Maker Studio. Последний, к слову, поддерживает кросс-платформенную разработку (что, наверное, и является почти единственным фактором выживания движка в целом).

В последнее время GM теряет свою популярность под тенью таких гигантов, как Unity3D/Cryengine/Unreal. Я считаю потерю спроса на этот движок совершенно необоснованной, ведь для создания многих игр (например, под Android) нет необходимости в последних технологиях разработки 3D и других «ненужных» функциях, очень требовательных к системе пользователя. При использовании Game Maker для разработки таких игр можно достичь достаточно высокой производительности без видимых жертв со стороны графики или функционала.

Итак, ближе к делу. С некоторых пор я занимаюсь разработкой игр в среде GM. И в один прекрасный день передо мной возникла интереснейшая задача — разработать приемлемый AI для игры жанра TDS (Top Down Shooter). Признаться, до того момента я не сталкивался с разработкой искусственного интеллекта, и задача поначалу просто поставила меня в тупик. Три последующих дня я провел в поиске решения (естественно, методом проб и ошибок), и узнал я за эти 3 дня довольно много. На основе своего короткого и болезненного опыта, я постараюсь описать основные методы и сторонние библиотеки по разработке AI в среде Game Maker.

Равновесие между работой и жизнью слишком важно, чтобы доверить заботу о нем вашему работодателю, утверждает Найджел Марш. Выступая на конференции TEDxSydney, Найджел Марш дает своё представление об идеальном дне, в котором гармонично сочетаются время для семьи, личных нужд и работы — и предлагает будоражащую идею о том, как этого можно достичь. Основная идея доклада в том что побеждает не тот, у кого на момент смерти больше денег в кошельке, а тот, кто пришел к осмысленной идее о том, как должна выглядеть хорошо сбалансированная жизнь. Лично я в этом докладе увидел много полезного для себя, рекомендую к просмотру, %username%.



Для тех кто любит читать, а не смотреть под катом сокращенная текстовая версия.

Продолжение истории Скотта Миллера и компании Apogee (3D Realms), начало здесь.

Ключевая идея

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

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

«Как жаль, что у меня не сохранились эти письма… Сейчас они, наверное, стоят целое состояние!» — шутит сегодня Миллер.

На Хабре уже есть очень много интересных статей про создание игры с нуля, но мало статей, описывающих что делать, чтобы своя любимая поделка не превратилась во Франкенштейна и дошла до вменяемого состояния. Автор оригинальной статьи рассказывает, как эволюционировал код игрового движка от кучи хлама в основном цикле к продуманной, расширяемой архитектуре, использующей Entity Component System. В статье много кода, который почти весь часто повторяется — но я не стал его выбрасывать, поскольку с ним будет понятнее, какие изменения вносит автор и как это отражается на всей структуре. Статья рассчитана на новичков, вроде меня, которые уже настрочили несколько «гениальных» прототипов, но теперь не знают, как разобраться в их коде.

Привет Хабра!

Эта статья продолжает цикл статей об игровом движке StalinGrad. В прошлой статье мы насиловали DHTML, а в этой — будем насиловать архитектуру и прототипы.

Кода практически не будет, поэтому, если вы не web разработчик, можете просто почитать про архитектуру и ООП. И таки да — про HTML5 тут снова ничего не будет, только DHTML-хардкор :)



Сразу короткое демо:
Пример 1 — паралельные миры
Пример 2 — один мир с разных камер
Пример 3 — боты
Пример 4 — нянкэт, облака и портальная пушка

От России, Беларуси, Украины сейчас на Кикстартере запущено 6 игр, 1 гаджет и 1 кошелек.

Я хочу немного рассказать о четырех новых проектах на Кикстартере из России, Белоруссии, Украины, еще об одном, к которому определенно русские имеют отношение. А также напомню вам те проекты, о которых я уже писал ранее в этом хабрапосте и которые увеличили свои сборы.

На кикстартере появилась система дополненной реальности, вдохновлённая сценой из четвёртого эпизода Звёздных войн, где Чубакка и R2-D2 играют в местный аналог шахмат. На момент написания статьи Джери Элсворт и Рик Джонсон — так зовут изобретателей — уже успели собрать половину от необходимых 400 000 долларов.

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

Всем привет!

Для тех, кто недавно стал читать этот блог. Я работаю в звуковой студии, которая озвучивает игры.

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

По мотивам За что я люблю Drupal.
Опубликовано по просьбе JiLiZART (перевод, как я понял, тоже его).
Оригинал: erickennedy.org.

Немного лирики

Чем дольше я программирую, тем больше мне нравятся слабосвязанные системы, которые состоят из большого числа разрозненных единиц (модулей), ничего не знающих друг о друге, но предполагающих существование других. Такие системы в идеале должны собираться подобно конструктору, без зависимостей и без адаптирования друг к другу. В идеале, в процессе работы такой системы, все необходимые задачи должны выполняться без остановки системы, простым введением нового модуля в мир (скажем, вбросом jar'ника в classpath), и система немедленно начнет взаимодействовать с новым модулем.
В связи с этим, очень привлекательно выглядит парадигма event-driven (или Событийно-ориентированное) программирование.

После многочисленных статей (на русском и английском) на тему использования стилей для Rollover-эффектов, уменьшения задержки при открытии страницы и нагрузки на сервер, я хочу раскритиковать использование CSS Sprites. В качестве более зрелого и мощного способа можно предложить использование data:URL и ряд дополнительных методик. На мой взгляд, область применения CSS Sprites весьма ограничена, я хочу постараться обозначить ее данной статьей и указать, когда их лучше не использовать.

Проблемы при верстке

С какими проблемами сталкивается верстальщик, когда использует спрайты? Это, в первую очередь, проблемы изменения каждой конкретной картинки в общем массиве. Мало того, что нужно открыть ресурсную картинку, найти в ней область, соответствующую данному небольшому изображению (которое меняется), и заменить ее, не потеряв палитру при всех изменениях. Также при изменении расположения картинок в ресурсном файле (например, перераспределили свободное место в связи с очередными дизайнерскими изменениями) нужно заново пересчитать все координаты и внести соответствия в CSS-файл.

читать дальше на webo.in →

Вы веб-разработчик?

Для вас есть новости.

В чем собственно проблема?

Все веб-фреймворки можно разделить на группы. У каждой из этих групп есть свои достоинства и недостатки.

Сервер-ориентированные

Например: RoR, Django, Asp Net, Express.js
Генерируют html на сервере.
Такой подход хорош для статических страничек.
Но как только вы хотите сделать что-то интерактивное, то начинаете утопать в jQuery-коде.

Клиент-ориентированные

Например: Backbone.js, Knockout.js, Ember.js, Batman.js
Генерируют html прямо на клиенте из темплейтов. Код на клиенте структурирован.
Хорошо для интерактивных сайтов.
Не отменяет необходимость использовать сервер-ориентированный фреймворк, что ведет к дублированию кода (модели, валидация и т.д.)

Кросс-компилируемые

Например: GWT, Cappuccino
Позволяют писать всё на одном языке.
Очень большой уровень абстракции.
Шаг вправо, шаг влево — расстрел.

Так же ни один из фреймворков не имеет механизмов синхронизации данных между клиентом и сервером и оставляет реализацию этого на нашу совесть.