Несколько недель назад, на Хабре освещалась одна очень хорошая, но незаслуженно забытая игра — Wasted Dreams. Тем, кто не знаком с ней, настойчиво рекомендую прочитать сначала ее обзор и описание начала этих исторических раскопок, а затем попробовать настроить эмулятор и самому в нее поиграть. Если вы неравнодушны к играм начала-середины 1990-х, цените красивую пиксельную графику и стиль таких игр, как Another World и Flashback — то есть вероятность, что и Wasted Dreams вам понравится.

В наших исторических изысканиях мы остановились на том, что выяснили, что WD разрабатывали всего два человека — программист Томас Цвиянович (Thomas Cvijanovic) и художник Реймонд Циндрич (Raymond Cindric). Weilard удалось найти Реймонда и сделать с ним короткое интервью, а я постарался восполнить пробел — найти второго героя этой истории и провести интервью с программистом этой замечательной команды.

Разговор получился несколько больше, чем планировался. Мы поговорили о прошлом, о настоящем и будущем. Выяснили (спойлер!), что отныне Wasted Dreams можно распространять свободно и без ограничений. Восстановили часть кусочков, пропущенных в этой истории. Итак, если есть желание — предлагаю…

Сломанный ноутбук или планшет бывает жалко выкидывать, тем более если у него сгорела материнка/видеокарта/процессор, а дисплей в полном порядке. В этом случае есть выход: можно подключить ЖКИ от мобильного устройства как второй/третий экран к персональному компьютеру. Лучше всего для этого подходит ЖК-дисплей от последних моделей iPad с размером 9,7" и разрешением сторон 2048х1536. Студент Варшавского университета Анджей Суровец (Andrzej Surowiec) сумел подключить retina-дисплей от iPad к ПК через DisplayPort на максимальном разрешении.

Большинство людей, занимающихся или интересующихся разработкой электронных устройств под управлением ARM-процессоров, прекрасно осведомлены о проекте Raspberry Pi. По сути, это первая дешевая development board с открытой архитектурой, хорошей технической поддержкой, а также с большим и дружелюбным сообществом энтузиастов.
Наша небольшая компания (start-up) почти что случайно решила посоревноваться с этой замечательной ягодой. Ну а написать про это я решил после того, как обнаружил интерес к данной теме вот здесь.

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

Продолжение перевода здесь

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

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

В первой части я рассказал о причинах, побудивших меня заняться построением своего “умного дома”, и об используемом “железе”.
Но “железо”, само по себе, умным быть не может, главное это “софт”. Вот об этой стороне своего проекта я и хочу рассказать в этой части. Банальное управление освещением с пульта, конечно, выглядит круто в глазах непосвященной публики, но “ума” тут никакого.
Так что же такого умного можно сделать? И, главное, как?

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Добрый день, уважаемые хабровчане. В прошлой статье мы с вами разработали простую USB-видеокарту на базе STM32F103 и китайского дисплейного модуля на контроллере ILI9325.
Проверяли мы его из юзерспейса, при помощи LibUSB. Ну что ж, пришло время нам написать свой собственный драйвер, который позволит делать все то же самое, но из-под Linux и без дополнительных библиотек. Этот драйвер мы внесем в дерево исходников OpenWRT и он поселится там наравне со всеми остальными.
Начнем.

Приветствую!

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

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

Это статья об изменениях, которые произошли в мире веб-разработки. Я наблюдаю огромное количество веб-разработчиков, которые буквально застряли в устаревших технологиях, особенно в мире .NET. Если вы еще не начали совершенствовать свои навыки, и адаптироваться к изменяющимся трендам, вы должны начинать уже сегодня.

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

Картинки кликабельны.

Form builder

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

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

Недавно я начал нелёгкое дело по вёрстке диссертационной работы в LaTeX-е. Естественным первым желанием было найти какой-нибудь готовый шаблон. Увы, я не нашёл ничего, что подходило бы под мои нужны. Поэтому я решил сделать свой шаблон (с преамбулой и макрокомандами)! Сразу скажу по поводу соответствия шаблона ВАК-овским требованиям: строгих требований нет (можете сами посмотреть список нормативных документов). Однако определённые требования могут быть у конкретного совета (но они, как правило, весьма похожи и соответствуют здравому смыслу). В своём шаблоне я постарался учесть общие тенденции в оформлении такого рода работ. Не буду приводить кучу технических особенностей вёрстки в LaTeX (на эту тему и так хватает статей), а просто поделюсь готовым результатом: GitHub.

— Ты пил пиво, — тихо заговорил Джо. — Плохо работал консервный нож.
Ты сказал, что сам смастеришь консервный нож, побольше и получше. Это я и есть.
Генри Каттнер, «Робот-зазнайка»

UPD> Начат сбор предзаказов habrahabr.ru/post/163865

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

Картинка Для Привлечения Внимания

Пролог

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

Не покидала мысль о том что хорошо бы сделать видео не «вид сбоку или сверху», а вид с борта девайса, от первого лица. То что самолётчики/коптеристы называют FPV. Было это примерно пару лет назад. Пробовали ставить на машинку аналоговую камеру и передатчик, принимали видео на ТВ-тюнер, далее отдавали на видеосервер для раздачи рулящим машинками. Но сразу всплыли нюансы — одновременно можно транслировать только 3-4 видеопотока, иначе появляются наводки с одного канала на другой. Плюс дороговизна такого решения, плюс проблемы с разрешёнными частотами, плюс паршивое качество картинки с постоянно появляющимися помехами… В общем, попробовали и забили на это дело. К тому же, возможностей управляющего контроллера (тогда всё было сделано на базе всем известной Ардуинки) начало нехватать. Стали искать другие варианты, чтоб было недорого, дёшево, удобно и практично. Но имеющиеся в продаже (за границей, само собой и с довольно высокой стомостью) на тот момент железки для нужд не подходили. Одни умели всё кроме видео, другие умели только видео, но не позволяли подключать периферию, и т.д. и т.п.

Возможное, многие из вас думали после ситуации с Фобос-Грунтом — что такого особенного в микросхемах для космоса и почему они столько стоят? Почему нельзя поставить защиту от космического излучения? Что там за история с арестом людей, которые микросхемы экспортировали из США в Россию? Где все полимеры?

На эти вопросы я и попробую ответить в этой статье.

Disclaimer: Сведения получены из открытых источников и могут быть не вполне точными. Я лично с военной электроникой не работаю, а кто работает — те статьи писать не могут. Буду рад дополнить и исправить статью.

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

Если интересны подробности: электрика/Интернет/отопление/водоснабжение с нуля — прошу под кат (сори, много фоток).

Сразу скажу, чего вы в этой статье не найдете:

• Подробного описания протокола Zigbee
• Подробного описания трансиверов XBee
• Теории и практических рекомендаций по построению mesh drop-in сетей
• Инструкций по работе с Linux
• Инструкций по перепрошивке роутеров и по работе с прошивками от Олега и Open-WRT

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

Предполагается, что вы сами-с-усами, способны найти нужную информацию в интернете и обладаете нужными знаниями. Задача статьи – достаточно крупными штрихами описать способ интеграции XBee и Ethernet/Wi-Fi роутера, привести простенький пример работающей системы, указать направления дальнейшего развития.
Поехали.

Меня очень заинтересовала статья Самая короткая запись асинхронных вызовов в tornado или патчим байткод в декораторе, не столько с практической точки зрения, сколько с точки зрения реализации.
Всё-таки модификация байткода в рантайме это слишком опасная и ненадежная операция. И уж наверняка не поддерживаемая альтернативными интерпретаторами Python.

Попробуем исправить этот недостаток способом, который для этого предназначен куда больше и который применяется для схожих целей во многих других языках (я точно встречал в Lisp или Erlang). Этот способ — модификация Абстрактного синтаксического дерева (AST) программы.

Самым нетерпеливым: лагающая демка, написанная под хром. На моей машине загружается секунд 20.

Эта идея пришла ко мне года 2 назад. Я обратил внимание на то, что, в условиях недостаточного освещения, я воспринимаю видимые объекты преимущественно в синеватых тонах и с небольшой потерей резкости. Возможно, это чисто психологическое восприятие, но мы сейчас не об этом. Мне стало любопытно, как выглядела бы 2D игра с такими особенностями освещения. С целью выяснить это, я, так и не разобравшись с шейдерами, набросал демку на самом удобном для меня языке — javascript. Поскольку эффект применяется к слабоосвещенным участкам, он не самый заметный из происходящего на экране, но вполне ощутимый шарм он добавляет.

От переводчика

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

Также прошу прощения за отсутствие перевода словосочетания “computer science”. В русском языке нет адекватного ему словосочетания. Всякие «информатики» и «компьютерные науки» — это либо дискредитировавшие себя понятия, либо бессмысленные переводческие суррогаты. Английское понятие “computer science” содержит историческую игру слов, которая в переводе на русский язык должна выглядеть как-то так: «науки о вычислениях, обработке информации и вычислительных устройствах». Думаю, лучше оставить оригинальное “computer science”. Во всяком случае, в таком виде это словосочетание позволит вам самим подобрать нужный контекст из всего многообразия, представляемого им в оригинале.

Почему я решил перевести этот текст (ведь он короткий и не особо насыщенный откровениями)? Потому, что это выступление Кармака. А он, как-никак, знаковая фигура в отрасли разработки ПО. То, что написано ниже, показывает отрыв теории разработки ПО от практики. Ведь, если эти мысли посещают такого разработчика и выносятся на QuakeCon, — то что тогда творится в головах рядовых прикладных программистов?

Вступление

Люди всегда стремились систематизировать музыку, разбивая её на жанры и поджанры. Основным методом такой систематизации был и остаётся «исторический» метод, который можно описать так:
Есть исполнитель K, который играет музыку похожую на жанр L, но явно в этот жанр не вписывающуюся. Сам исполнитель или муз. критик, лейбл придумывают для такой музыки новый под жанр, жанра L – LL. И через R лет жанр LL становится каноническим. Или не становится, в зависимости от результатов «проверки временем». Таким образом, все музыкальные жанры можно соединить в граф, в котором жанр L ближе к корню, а LL – к листьям.

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