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


В. Что же такое gemei a330?
О. Dingoo A320 — портативное мультимедийное устройство, совмещающее в себе функции аудиоплеера, видеоплеера, FM-радио и эмулятора игровых консолей. Выпускается компанией Shenzhen Dingoo Digital Co., Ltd. с марта 2009 года. Является главным конкурентом продукции компании GamePark Holdings.
То же самое справедливо и для gemei a330 за исключением даты выпуска и производителя.
Девайс производит компания Gemei Digital Technology Co., Ltd. где-то с прошлого года. От своей предшественницы а320 отличается более мощным процессором (CC1800 ARM 11 600 Mhz заниженный до 500 Mhz против Ingenic JZ4732, 336 МГц (понижена с номинальных 360 МГц, разгоняется до 433 МГц)) и количеством ОЗУ, превышающим динговский аж в два раза (64 против 32х). Другой процессор одновременно самая сильная и самая слабая сторона консоли. Он безусловно быстрее, но обилие софта от динги на гемейку не пойдет.
Подробнее про gemei можно почитать здесь . Или посмотреть видеообзор.


Итак, владельцы уже состоявшиеся и потенциальные, прошу под кат.

Внесу-ка я и свой вклад в дело, тем более, что кто-то просил поделиться информацией.

Как?

Уже скоро 4 года как я живу и работаю в Японии. Попасть сюда иностранцу с одной стороны довольно легко, но с другой стороны — нет. Как так? Дело в том, что программ иммиграции в этой стране нет, натурализация возможна (практически) только через брак, но в стране огромный дефицит инженеров. То есть продавцы, юристы, врачи, строители, таксисты есть, а инженеров мало. О причинах я расскажу ниже. Так вот, Япония каждый год импортирует огромное количество индийцев, китайцев, корейцев, филиппинцев, американцев, тайцев и т.д. для работы в технических областях. Однако, русскому инженеру (как всегда) протиснуться сложно. Хотя бы потому, что нужна виза, поручитель, беготня с бумагами (в последние год-два ситуация стала самую капельку лучше). Поэтому, если очень хочется именно в Японию, придется запастись какими-то уникальными (ну, или хотя бы редкими) знаниями — микроконтроллеры, программирование для RTOS, ГИС, хитрые БД, распределенные вычисления и т.п. А веб-мастеров полно и в Китае :)

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



Предназначение данной диаграммы — показать взаимодействие между различными параллельными компонентами системы. В данном примере Fred, Bob, Hank и Renee в ресторане. Каждый может легко нарисовать подобную диаграмму на бумаге. Проблема в том, что наброски на бумаге могут отличаться от того, что происходит во время выполнения вашей программы.

Правда было бы здорово, если бы вы могли строить похожие диаграммы на основе данных трассировки программы автоматически? Что ж, Erlang вам в этом поможет.

В статье расскажу как достаточно быстро перечислить связные объекты на бинарном растре. Этот алгоритм мы использовали для распознавания изображений и текстов; он отличается от подобных высокой скоростью обработки (на картинках до 3200x2400, с некоторыми оговорками, он отрабатывает за миллисекунды) и доступностью в понимании (при наличии некоторых знаний C++). Отмечу, что исходная картинка будет трактоваться алгоритмом как «только для чтения» (зачем портить то, с чем могут работать другие методы), и в связи с этим, алгоритму потребуется небольшое количество дополнительной памяти. Кроме того, внешние контуры являются полезным объектом для анализа и векторизации изображений.

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

Я уже некоторое время ковыряю TDD и задача постоянного контроля качества для меня становится всё актуальней. Особенно при пополнении команды новыми разработчиками.

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

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

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

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

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

А чтобы тебе было проще, я сделал видео урок на тему изготовления печатных плат методом Лазерного Утюга ака ЛУТ.

Полный цикл, от подготовки платы с куска текстолита, до сверления и лужения.