Сколько я себя помню, всегда мечтала сделать процессор. Наконец, вчера я его сделала. Не бог весть что: 8 бит, RISC, текущая рабочая частота — 4 кГц, но он работает. Пока что в программе моделирования логических цепей, но все мы знаем: «сегодня — на модели, завтра — на деле!».

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

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


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

После одного игрового проекта со стримом всего процесса разработки мне часто пишут начинающие разработчики, что-то спрашивают, что-то показывают и на что-то жалуются. Недавно мне пришлось влезть в спор двух ребят, где темой спора было: “Что круче знать 3д-моделирование или программирование, если собираешься разрабатывать игры?”. Влез к ним в спор с предложением сделать первый шаг из схемы, что родилась в процессе участия в игровых проектах и создания своих.

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

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

Как всё начиналось

Однажды мне пришлось участвовать в разработке одного небольшого проекта для научных расчётов, который разрабатывался на языке программирования Python. Изначально Python был выбран как удобный и гибкий язык для экспериментов, визуализации, быстрого прототипирования и разработки алгоритмов, но в дальнейшем стал основным языком разработки проекта. Надо заметить, что проект был хоть и не большим, но довольно насыщенным технически. Для обеспечения требуемой функциональности, в проекте широко применялись алгоритмы теории графов, математическая оптимизация, линейная алгебра и статистика. Также использовались декораторы, метаклассы и инструменты интроспекции. В процессе разработки пришлось использовать сторонние математические пакеты и библиотеки, например, такие как numpy и scipy, а также многие другие.

Со временем стало ясно, что переписывать проект на компилируемом языке слишком затратно по времени и ресурсам. Скорость работы и потребление памяти не являлись критичными показателями в данном случае и были вполне приемлемыми и достаточными. Поэтому было принято решение оставить всё как есть, и продолжить разработку и поддержку проекта на языке Python. К тому же, документация по большей части уже была написана с использованием Sphinx.

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

Здесь сразу обозначилась новая проблема: как защитить исходные коды нашей Python-библиотеки? Может быть, в ином случае никто бы не стал этим заниматься, я бы уж точно, но в библиотеке были реализованы некоторые ноу-хау, и руководители проекта не хотели, чтобы данные наработки попали к конкурентам. Так как я был одним из исполнителей, мне пришлось озаботиться данной проблемой. Далее я постараюсь рассказать об основной идее, что из этого вышло, и как нам удалось скрыть Python-исходники от лишних глаз.

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

Сначала главная новость – Coursera скоро будет доступна с субтитрами на русском, и первый курс как раз геймификация Кевина Вербаха.

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

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

• Хабр. Карма, рейтинг плюс наши бейджи и инвайты: они создают дополнительную мотивацию писать посты.
• Террористы. На самой лекции также говорилось, что боевики в Аль-Каиде проходят несколько уровней своего рода игры, каждый из которых разблокирует новые возможности в организации.
• Обучение. Там же приводился пример про школу, в которой все в начальных классах стали играть роли в экипаже космического корабля. Учиться стало интересно уже не потому что так надо, а потому, что это помогало проходить сюжет.

Чуть более двух лет назад я опубликовал статью Другое видение скучных GTD планировщиков через призму RPG игр, в которой описал свою старую идею про совмещение работы над software проектами и элементов RPG игр.

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

Топик тогда собрал 100500 комментов (в основном «супер! хочу!»), а особо заразительные собрались в команды и стали воплощать идею в жизнь. Так что же было сделано за эти два года?

10 слов об идее.

GTD планировщик в виде многопользовательской RPG для команд разработчиков, вот.

Коротко.

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

Lol, это шутка? Да, так и есть, это шутка. Но в каждой шутке, как говорится, есть доля шутки.

…Говоря о лени и ММО, сейчас я задумываюсь, если мне так влом утром вставать на работу, если мне так лень было ходить на пары, если мне нужно огромное количество усилий потратить, чтобы заставить себя наконец открыть Flex Builder и дописать этот глупый проект, почему я 4 месяца не получая за это зарплаты, вставал в 6 часов утра и весь день «работал» в игре? …

Дла заинтересовавшихся или тех, кому просто любопытно — велкам за хабракат. А вот пока картинка на затравку.

Здравствуй, хабр! Во второй части статьи я продолжу рассказ о том, как я писал клон игры Pacman. Первую часть можно почитать здесь.
С момента, когда я последний раз работал над пакманом прошло порядка трех недель. Прошла большая часть сессии, стало немного больше времени и я решил продолжить. В этот момент появилось желание доделать игру до состояния, когда ее можно будет выложить в Google Play Market, хотя в самом начале разработки я об этом даже не помышлял. Кроме того, доделывание до играбельного состояния – неплохая тренировка. Где-то я слышал, что игры (да и вообще приложения) стоит доделывать.
Напомню, что разработка игры велась с использованием Android NDK (С++) и OpenGL ES 2.0.

День добрый, уважаемые хабражители.
Писать игры хотел ещё с того момента, когда только начал программировать. И вот, решил всё-таки попробовать себя в написании игр на Android.
Игру осенью сделал ещё и выложил в маркет. Правда её удалили, так как права на Bomberman'а у Konami. Но статья, естественно, не об этом.

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

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

Мой выбор пал на несколько отечественных вузов с вечерними программами, и я уже было выбрал МГТУ имени Баумана своей второй альма-матер, как я наткнулся на сайт Harvard Extension School .

Здравствуйте, уважаемые хабралюди!
Последние несколько месяцев, в свободное время, я занимался разработкой клона знаменитой игры Pacman для ОС Android. Как это было, и что из этого вышло я хочу рассказать.

О чем эта статья

В двух предыдущих статьях я рассказывал как отлаживать приложения для Android без исходного кода на Java и о некоторых особенностях установки breakpoints. Если уважаемый читатель ещё не ознакомился с этими статьями — я настоятельно рекомендую начать с них, а уже потом читать эту статью.

Так уж вышло что до сих пор я рассказывал исключительно об отладке байткода Dalvik и ни словом не обмолвился об отладке native методов. А ведь именно в native методах часто скрывается самое вкусное — хитрые защиты, интересные malware фичи, уязвимости нулевого дня. Поэтому сегодня я сжато, без «воды», расскажу как отлаживать native методы без исходного кода на C/C++ (ну или на чем, уважаемый читатель, они у вас там написаны).

Привет, Друзья!

Гитхаб — прекрасный сайт. Но представьте, что вы нашли проект А, и хотите узнать какие еще существуют похожие проекты. Как быть?

Именно с таким вдохновением уселся я разбирать API GitHub'a. Спустя пару недель свободного времени вот что получилось:



Для большинства проектов находится пара действительно интересных предложений. Вот несколько примеров: angular.js, front end bookmarks, three.js

Основная идея для построения рекомендаций — «Разработчики которые поставили звездочку этому проекту, также поставили звездочку...». А детали идеи, ее недостатки и ссылка на код — ниже.

Формат архивов 7-Zip довольно гибкий и позволяет, например, включать весь архив как один из файлов внутри самого архива, лишь немного считерив. Разберём формат на примере: создадим почти вручную архив с именем «Рекурсивный.7z», содержащий два файла: «Какой-то файл.txt» с содержимым «Hello, Habrahabr!» и «Рекурсивный.7z», копию самого себя.

Краткая документация по формату входит в LZMA SDK. Архив начинается со следующей структуры размером 32 байта. Все позиции внутри архива кодируются как смещения относительно конца этой структуры.

сигнатура, 6 байт: { '7', 'z', 0xBC, 0xAF, 0x27, 0x1C };
версия формата, два байта { Major, Minor }, 7-Zip 9.20 пишет сюда { 0, 3 };
CRC следующих трёх полей, 4 байта;
смещение основного заголовка относительно конца этой структуры, 8 байт;
размер основного заголовка, 8 байт;
CRC основного заголовка, 4 байта.

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

Основной заголовок может быть сам по себе упакован (а также зашифрован). Поскольку он содержит структурированные данные (типа имён файлов), коэффициент сжатия достаточно неплохой. Именно для возможности подобного сжатия вся информация о файлах в 7z собрана в одном заголовке и полностью отделена от сжатых данных файлов. Признак упакованности — первый байт основного заголовка: он должен быть равен 1 у неупакованного заголовка и 0x17 у упакованного. Для создания архива вручную мы не будем ничего сжимать.

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

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

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

Качества

Вы всегда должны улучшать три своих качества: компетентность, скорость и осведомленность.

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

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

Читатели этой статьи познакомятся с основными методиками и задачами тестирования электронных устройств и получат общее понимание обеспечения качества на производстве. Особое внимание будет уделено достоинствам и недостаткам различных методов тестирования.

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

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

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