Если вы пишете не казуалку под веб и не беспощадный суровый рогалик, без сохранения данных на диск не обойтись.
Как это делается в Unity? Вариантов тут достаточно — есть класс PlayerPrefs в библиотеке, можно сериализовать объекты в XML или бинарники, сохранить в *SQL*, можно, в конце-концов, разработать собственный парсер и формат сохранения.
Рассмотрим поподробнее с первые два варианта, и заодно попробуем сделать меню загрузки-сохранения со скриншотами.

Будем считать, что читающий дальше базовыми навыками обращения с этим движком владеет. Но при этом можно не подозревать о сущестовании в его библиотеке PlayerPrefs, GUI, и ещё в принципе не знать о сериализации. С этим всем и разберёмся.
А чтобы эта заметка не стала слишком уж увлекательной и полезной, ориентирована она самый неактуальный в мобильно/планшетно/онлайновый век вариант — сборку под винду (хотя, конечно, более общих моментов достаточно).

• Кстати, пару недель назад на Хабре была статья, где автор упомянул, что Unity3D проходят в курсе компьютерной графики на кафедре информатики питерского матмеха. Занятный факт, немало говорящий о популярности движка.
  Хотя насколько это в целом хорошая идея — на мой взгляд, тема для дискуссии. Может быть, обсудить это было бы даже интереснее вопросов сериализации =)

Javascript — очень изящный язык с кучей интересных возможностей. Большинство из этих возможностей скрыты одним неприятным фактором — Internet Explorer'ом и другим дерьмом, с которым нам приходится работать. Тем не менее, с приходом мобильных телефонов с актуальными браузерами и серверного JavaScript с нормальными движками эти возможности уже можно и нужно использовать прям сейчас. Но по привычке, даже при программировании для node.js мы стараемся писать так, чтобы оно работало в IE6+.

В этой статье я расскажу про интересный и не секретный способ указывать изящные геттеры и сеттеры и немножко покопаемся в исходниках Mootools. Частично это информация взята из статьи John Resig, частично лично мой опыт и эксперименты.

function Foo(bar){
    this._bar = bar;
}

Foo.prototype = {
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
};

ECMAScript 5 идёт по своему пути. Воскреснув из пепла ECMAScript 4, который был ужат обратно к ECMAScript 3.1, который далее был вновь назван ECMAScript 5 (подробнее) — он приходит с новым слоем функциональности, построенным на базе нашего любимого ECMAScript 3.

Анонсировано несколько новых API, включённых в спецификацию, но самая интересная функциональность заключена в коде обьектов и свойств. Этот новый код дает возможность существенно влиять на то, как пользователи смогут взаимодействовать с объектами, позволяя обеспечить геттеры и сеттеры, предотвратить перечисление, манипуляции, или удаление, и даже предотвратить добавление новых свойств. Короче говоря: Вы будете иметь возможность повторить и расширить существующий набор API для JavaScript (например, DOM), с помощью JavaScript (не используя более ничего).

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

Одна из таких особенностей — это реализация прототипного наследования. Этот простой концепт является гибким и мощным. Он позволяет сделать наследование и поведение сущностями первого класса, также как и функции являются объектами первого класса в функциональных языках (включая JavaScript).

К счастью, в ECMAScript 5 появилось множество вещей, которые позволили поставить язык на правильный путь (некоторые из них раскрыты в этой статье). Также будет рассказано о недостатках дизайна JavaScript и будет произведено небольшое сравнение с классической моделью прототипного ОО (включая его достоинства и недостатки).

Мне очень нравится JavaScript и я считаю его мощным и удобным. Но для большинства начинающих JS-программистов, много проблем создаёт недопонимание аспектов языка. Часто конструкции языка ведут себя «нелогично». В данной статье я хочу привести примеры «граблей», на которые я наступил; объяснить поведение языка и дать пару советов.

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

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

Для тестов воспользуемся:
— Mocha — фреймворк позволяющий писать тесты и запускать легко и просто. Генерирует отчеты в различных вариантах, а так же умеет создавать документацию из тестов.
— Should — библиотека для тестов в стиле «утверждения» _{(Не нашел правильного названия)}
— SuperTest — библиотека для тестирования HTTP серверов на nodejs
— jscoverage — для оценки покрытия кода тестами

В прошлой статье я начал рассказывать о своём опыте разработки экспериментального WEB-проекта «Что делать?» на Node.JS. Первая часть была обзорной, в ней я постарался раскрыть плюсы и минусы технологии, а также предупредить о проблемах, с которыми, возможно, придётся столкнуться в ходе разработки. В этой статье я подробнее остановлюсь на технических деталях.

Несколько слов о «хабраэффекте»

Это продолжение перевода «The Trello Tech Stack».

Часть 1

• CoffeeScript
• Клиент
  * Backbone.js
  * HTML5 History API
  * Mustache
• Pushing and Polling
  * Socket.io and WebSockets
  * AJAX запросы

Часть 2

• Сервер
  * node.js
  * HAProxy
  * Redis
  * MongoDB
• Итак, нравится ли нам это?

«Подобные технологии могут стоить несметного состояния.
Представьте управление любым устройством… лишь посылая команды при помощи радиоволн.
Это будущее, Ватсон.»
Шерлок Холмс (Sherlock Holmes)-2009

Трудно представить сегодняшний мир без компьютеров и различных электронных устройств. А ведь с момента изобретения транзистора прошло всего 56 лет. При том, что электричеством люди владеют примерно с конца 18 века — просто поразительно как быстро в нашу жизнь ворвались компьютеры, телефоны, интернет и прочие блага цивилизации, так привычные нам, но о которых — лет 30 назад человечество могло только мечтать. Миллионы людей получили в свои руки мощнейший инструмент для самореализации и самовыражения — ведь правда — вы когда нибудь задумывались — как здорово, что мы можем вот просто так взять и реализовать свою идею без каких либо особых материальных вложений? Компьютер позволил умным и талантливым людям реализовать себя, интернет дал доступ к петабайтам информации, позволил миллионам людей общаться друг с другом, находить единомышленников, учиться, осваивать профессии, зарабатывать — и всё это не вставая с кресла… В общем — хватит лирики, в статье речь пойдет о Программно определяемом радио — что это и как оно работает — узнаете под катом

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

• Что такое домен коллизий?
• Сколько пар используется для Ethernet и почему?
• По каким парам идет прием, а по каким передача?
• Что ограничивает длину сегмента сети?
• Почему кадр не может быть меньше определенной величины?

Если не знаешь ответов на эти вопросы, а читать стандарты и серьезную литературу по теме лень — прошу под кат.

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

Кто из вас уже строил модель самолёта своими руками? Попробую рассказать об этом увлекательном занятии в нескольких статьях и тем начну цикл о прикладном авиамоделировании.

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

Зачем это нужно?

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

Объявлено новое соревнование 7400, и нужно сделать что-то новое. Нельзя ударить в грязь лицом после победы в прошлом году ;)

У меня было несколько расплывчатых идей, но их было недостаточно, чтобы вызвать реакцию «Ух ты!» или «Ты маньяк!». Нужно серьезно потрудиться, чтобы оставаться на уровне моей предыдущей разработки — емкостного сканера.

Я устроил мозговой штурм с моими товарищами: Педерсеном (Pedersen), Асбьёрном (Asbjørn) и Флеммингом (Flemming), которые тут же придумали множество смешных идей. И вот Флемминг упомянул RFID (он разработчик системы управления доступом, которая основана на RFID). А вот это уже мысль. Конечно, первые мысли были об RFID-считывателе, но мы уже собрали их довольно много, и это было скучно. Однако, появилась идея сделать RFID-метку. Я не знаю, кто упомянул это первым, и, как обычно в мозговом штурме, идеи рождаются коллективным разумом. Итак, решено сделать RFID-метку, собранную исключительно на 7400-ой логике.

Прошла неделя с момента пиара на хабре моего проекта «Что делать?». Я напомню, что этот проект начинался, как эксперимент по разработке среднестатистического WEB-проекта целиком на JavaScript (Node.JS). Сейчас я хочу поделиться с сообществом результатами этого эксперимента, полученным полезным опытом, а также подробной картой с отмеченными на ней граблями.

Эпизод 1: начало пути

Я являюсь ярым фанатом игры «Дальнобойщики-2», но к сожалению, у меня не получалось запустить их под Linux. Я пытался заставить игру работать в течении нескольких лет (это не значит, что я сидел сутки напролет над ней) с переменным успехом. Пробовал разные версии wine, ковырял настройки, но игра не поддавалась. Как-то раз у меня появилось свободное время, и я решил разобраться, почему Дальнобойщики не запускаются под Wine, хотя прекрасно работали под Cedega. Далее я расскажу, как мне это удалось.