Австралийский дизайнер Уилл Дэйбл предлагает интересную метафору, помогающую разрабатывать простые и удобные интерфейсы. Разработчику, который знает свою систему вдоль и поперек, и отдаёт работе над ней значительную часть своей жизни, очень трудно представить, как будет работать с ней обычный пользователь, чья голова забита другими вещами. Особенно, если он пробует его продукт первый раз в жизни и ещё не уверен в его полезности. Чтобы представить, что творится в голове у пользователя, Уилл Дэйбл предлагает вообразить, что пользователь пьян. Его внимание рассеянно, он легко выходит из себя, он не слишком отчётливо видит и не очень уверенно двигается — если постоянно помнить об этом, интерфейс получится чище и проще. Суть метода Дэйбл рассказывает в этом пятиминутном ролике:

Игра Extra-Terrestrial, выпущенная в 1982 году компанией Atari для собственной консоли Atari 2600 признана одной из худших игр в истории. Согласно легендам все невостребованные копии этого продукта решено было закопать. Все данные связанные с этим действием были скрыты.

В ночь с воскресенья на понедельник закончился прием работ на GamesJamGAMM. Это был недельный гейм джем, где нужно было разработать игру на тему “фобии”.

В этой статье мы расскажем о том, как мы делали для него свой проект.



У нас уже есть опыт участия в подобных мероприятиях. Мы участвовали в недельном гейм джеме от NextCastle (о чем уже писали на Хабре), и в месячном фестивале от Канобу (цикл статей на Хабре).

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

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

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

Когда лётчики-испытатели прокачиваются до следующего уровня, получаются космонавты. И они настолько суровы, что могут использовать алмазы вместо жвачки. Мы уже говорили о крутых космонавтах, но вот что, ребята: в космосе всё круто. Поэтому вот вам ещё кое-что.

1903

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

Статья в NewScientist.

Под катом еще несколько старинных «хаков».

My God, it's full of stars!

Arthur C. Clarke

Кто из нас в детстве не мечтал «бороздить просторы вселенной», как капитан Пикард, прогуливаться по неизведанным планетам далёких миров, встречать рассветы двойных или тройных звёзд, погружаться в атмосферы газовых гигантов, ронять корабли в чёрные дыры? И я тоже не исключение. Конечно, частично эту мечту воплощали книги, фильмы и «Элит»-ные игры. Но вся романтика в них разрушалась банальными купи-продай и «пиу-пиу» в «жидком» космосе на скоростях самолётов времён первой мировой войны. Да и тем немногим виртуальным миркам не хватало свободы, детальности и масштабов реальной вселенной.

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

Но вот, чуть больше года назад, я совершенно случайно наткнулся на вселенную Space Engine, и она просто взорвала мне мозг и размазала его по полу своим масштабом и невероятной детализацией.

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

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

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

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


Иллюстрация Стивена Резига

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



Такая организация имеет свои неоспоримые достоинства, например синхронизация игровых состояний клиентов на сервере, простота в реализации и почти фиксированные задержки до пользователя. Там где есть плюсы, обычно обитают и минусы — это ограниченная пропускная способность сервера и довольно большие задержки, если клиент находится далеко от вашего сервера. Как с ними бороться подробно написано в блоге 0fps.net и есть возможность эти проблемы довольно эффективно решать оставаясь в любимой «звездочке» — купить больше серверов, но что делать если вы студент вы ограничены в финансах и горизонтальное/вертикальное масштабирование для вас не вариант?

Всем привет. DisaDisa начал хорошее дело по переводу уроков по Unity 3D от сайта www.unity3dstudent.com. Я решил продолжить начатое, чтобы уж на хабре был законченный курс.

Ссылки на предыдущие уроки:

• Уроки B00-B03
• Уроки B04-B08
• Уроки B09-B12
• Уроки B13-B16

Введение

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

Для обработки изображений возьмем широкораспространенную библиотеку OpenCV. Она неродная (unmanaged) для .net, поэтому подключим ее через wrapper OpenCvSharp.

OpenCV нам нужна для того, чтобы, применяя различные преобразования к изображениями, выбрать такое преобразование, которое отделит фон и тени от объектов, а объекты друг от друга. К этой цели и будем сегодня двигаться.

---

Затрагиваемые темы: выбор библиотеки для обработки изображений, выбор wrapper-а для работы с OpenCV, основные функции OpenCV, выделение движущихся объектов, цветовая модель HSV.

---

Животные и люди умеют обучаться, играя. В самом деле, что может быть лучше — и интересно, и познавательно. Компьютерные игры не являются исключением, с некоторыми из них можно учиться. Я очень удивился, когда, поискав по Хабру, узнал, что космический симулятор Orbiter всего пару раз мельком упоминался здесь. Бесплатный космический симулятор с открытой для аддонов архитектурой и честной ньютоновской физикой оказался незаслуженно обойдённым вниманием. Наверное, из-за своей требовательности к начинающему игроку.

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

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

Я решил сделать дисковый массив на платформе Intel Atom D410PT. Это материнская плата с пассивным охлаждением процессора, два слота памяти (максимум 4Gb), один слот PCI (который я использовал для контроллера SATA SiliconImage 3512 — 2x1.5Gb/s), 2 SATA (3.0Gb/s) разъема, LAN 100mb/s, и многочисленными USB 2.0 портами (в том числе и на самой материнской плате).
Сама плата поместилась легко в корпус NaviPower PIX-1001 230W. Полное описание моих действий с железом я разместил на своем сайте.

Соответственно, т.к. было решено использовать 4 диска для создания RAID5 массива, то логично вырисовалось решение вынести операционную систему на внешний USB носитель (в моем случае USB HDD Seagate Freeagent GoFlex). Так как установка и настройка системы «с нуля» является зачастую долгим и кропотливым занятием, то я решил что система будет лежать на внешнем диске в контейнере VHDX, а так как материнка поддерживает UEFI, то соответственно и загрузка должна идти используя UEFI. Основная проблема была в том, что в интернете нет понятной инструкции, как это сделать. Вся информация очень разрознена, и описываются только части решения этой задачи.

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом:

Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync.

Каждый программист должен написать свою cms, framework, mmorpg. Именно этим мы и займемся.
Демо

Следующий этап большой и, надеюсь, интересной серии обучающих постов о полётах в Orbiter. После того, как в предыдущем посте мы успешно состыковались с МКС, очевидная следующая задача — вернуться назад на Землю, совершив точную посадку с приемлемыми перегрузками.
Этот пост имеет цель:

• Рассказать о корабле ПТК НП.
• Дать представление о физике маневров торможения и посадки.
• Представить простое руководство для точной посадки в Orbiter.

Сегодня я хочу рассказать об одном малоизвестном игровом движке, который мы используем уже год для кроссплатформенной разработки мобильных игр. Для 2д он нас полностью устраивает, а единственным конкурентом может быть только Unity3d из-за своего редактора. Отсутствие должного внимания к MOAI SDK, очевидно, связано с высоким порогом входа — сами разработчики (Zipline Games) позиционируют свой продукт как «The mobile platform for pro game developers», хотя разобравшись с установкой и настройкой окружения можно очень быстро и просто клепать игры на Lua.

Весной 2006 года Кевин Систром стоял за кофемашиной в кафе Caffé del Doge в Пало-Альто, когда к стойке подошел основатель Facebook Марк Цукерберг. Годом ранее Цукерберг уже ужинал с Систромом — он предложил ему уйти с последнего курса Стэнфорда, чтобы разработать фотосервис для Facebook. Кевин тогда отказался. Оставшись в Стэнфорде, Систром разработал приложение Instagram, которое Цукерберг недавно приобрел за $1 млрд. (Сумма поражает, особенно если знать, что у стартапа нет не только выручки, но и модели ее получения. В компании Instagram, возраст которой еще не достиг двух лет, по-прежнему лишь 14 сотрудников.) В итоге Цукерберг все же захватил Кевина в ряды армии Facebook, с чем его и поздравляем.

Если в истории с Систромом Цукерберг сделал ставки и не прогадал, то с сооснователем WhatsApp Брайаном Актоном все сложилось иначе. В 2009 году его не взяли на работу в Facebook, а в 2014 компания покупает WhatsApp за $16 млрд. Как же так получается, что большие и инновационные компании отказываются от перспективных сотрудников (будем называть их гуру или «звездами»), за которых в будущем будут гоняться с утроенной скоростью, предлагая просто сумасшедшие деньги? Ориентация на метрики, а не на результат.