Так как у меня была одна неделя до моего следующего контракта, я решил закончить мой цикл статей id. После Doom,Doom Iphone, Quake1, Quake2, Wolfenstein iPhone и Doom3, я решил изучить код, который я еще не рассматривал: idTech3 — 3D движок Quake III и Quake Live.

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

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

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

Я давно регулярно читаю Хабр и заметил, что здесь довольно мало внятных статей о локализации ПО, ориентированных на разработчиков. По своему опыту управления проектами локализации я могу сказать, что локализация — это не только перевод строк и адаптация приложения к контексту той или иной страны, но и постоянное противоборство (в идеальных случаях — равноправное взаимодействие) с разработчиками.
В этой статье я постараюсь на примере показать, как можно создать так называемый localization-friendly code, то есть, организовать ресурсы таким образом, чтобы существенно облегчить локализацию приложения, снизив избыточные временные и финансовые затраты.
Сразу же оговорюсь, что речь пойдёт в первую очередь об интернационализации, то есть, об учёте всех лингвистических особенностей на этапе разработки. Если же ресурсы вашего проекта изначально не подразумевали локализацию, а впоследствии вы решились на неё, то их «затачивание» под локализацию может выйти намного дороже, чем доход от неё.

Полтора месяца назад я рассказывал о том, как Бен Краснов (Ben Krasnow) собрал самодельный рентгеновский сканер. Бен не прекратил свои эксперименты с рентгеном и теперь представляет полноценный компьютерный томограф (авторское описание).

Пример работы томографа показан ниже. Сможете угадать, что (или кто) это?

Всем привет,



Сначала хотел озаглавить топик «Миллион загрузок в месяц или как сделать хороший старт на Google Play на примере одной игры», но потом решил, что это слишком длинно. Тем не менее, сегодня я буду говорить о своей последней игре. Не только потому, что мне хочется немного ее прорекламировать (хотя и это тоже, чего скрывать), но и потому что каждый запуск новой игры индивидуален и без «привязки к местности» рассказывать, наверное, было бы не совсем правильно.

Они все-таки успели!
Буквально менее часа назад, новый владелец Qt Framework — компания Digia, объявила о выходе долгожданного релиза Qt 5.0

My God, it's full of stars!

Arthur C. Clarke

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

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

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

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

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

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

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

Оригинальный текст: semitwist.com/articles/article/view/dispelling-common-d-myths
Reddit: www.reddit.com/r/programming/comments/118y4m/dispelling_common_d_myths

Вступление

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

Все эти заблуждения вполне объяснимы. Многие связаны с проблемами, которые играли важную роль в прошлом, так что не удивительно, что эти устаревшие представления продолжают существовать. Мне кажется, что это как раз те области, которые сообщество D должно как можно лучше объяснить остальным программистам. Вот эти темы:

• Для D есть IDE
• DSource угасает, но проекты на D активны как никогда ранее
• Разделения на D1 и D2 больше нет
• Phobos — стандартная библиотека? А как же Tango?
• D — open source
• D позволяет ручное управление памятью
• Статическая типизация НЕ означает непродуктивность

Данная статья является кратким конспектом по книге "Andre Kukla: Mental Traps"

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

С «граблями» или ментальными ловушками можно легко справиться, если они лежат перед вами во всей красе, безо всякой маскировки. Но так бывает далеко не всегда и зачастую мы не видим и не понимаем в чем заключаются наши ошибки. Целью этой статьи является знакомство с наиболее «популярными» ментальными ловушками, которые Андре Кукла описал в своей книге.

Добрый день, уважаемые хабровчане. Представляю вашему вниманию статью, в которой я описываю процесс проектирования и создания шестиногого робота полностью с нуля. Вы не найдете здесь надоевших всем ардуин и готовых наборов «хексапод за 5 минут». Из-за большого объема информации, статья будет состоять из нескольких частей, описывающих разные этапы проектирования и освещающих грабли, на которые я наступал в процессе оного.
Итак, встречайте – Ectognathus.

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

Будет рассмотрен небольшой, но иногда довольно полезный класс, плюс небольшой трюк с макросами, позволяющие проводить первичный анализ стека вызовов (call stack) прямо в stdout, в процессе работы программы. Разумеется, на stdout свет клином не сошёлся, и можете перенаправить хоть в файл, хоть куда-нибудь ещё — я лишь демонстрирую общий принцип.

Сразу договоримся:

1. злоупотребление макросами — зло
2. ничего нового и сверхъестественного в данной статье нет, она будет понятна даже новичку (на них и рассчитана)
3. данный приём мало применим (или вообще не применим) в многопоточной среде
4. реализация не претендует на идеальность, полноту, и уж тем более уникальность
5. данный приём ни в коем случае не заменяет, а лишь дополняет дебаггер

Но если при написании программы вы не раз писали что-то вроде printf(«Entering Foo()\n»); для мониторинга входа в ту или иную функцию, то вы пришли как раз по адресу.

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

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

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

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

Известно, что в рибосомах прокариот и эукариот присутствуют 3 типа рРНК. Информационная емкость крупных молекул больше, но их труднее анализировать. Поэтому наиболее удобным оказался анализ молекул рРНК средней величины: 16S (~1600 нуклеотидов). Систематика основывается на расчете коэффициентов сходства сравниваемых организмов. Именно на основании анализа рРНК современная систематика выделяет три домена бактерии, археи и эукариоты, а так же на этом основывается систематика, бактерий и архей X издания Берги.

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

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

Смотрим, что из этого получилось.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

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

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

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

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

[Статья Armin Ronacher о принципах вычисления коллизий в сетевых шутерах. Носит скорее обзорный и исследовательский, нежели технический характер. Здесь и далее в квадратных скобках примечание переводчика]

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

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