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

Итак, как и обещал в первой части, продолжаем упрощать бытовую жизнь хабражителя. Сегодня 8 марта (кстати, девушки, поздравляю!) и части мужчин хочется порадовать своих женщин и освободить их от «рабского труда» на кухне, а другой части – приготовить для себя не традиционные пельмени\вареники\сосиски, а что-то посущественней.
Вот несколько проверенных рецептов, которые пригодятся и первым, и вторым.

Осторожно, много картинок. Голодным не входить!

Летом уже упоминали про ODROID-X, альтернативу Raspberry PI. И вот Hardkernel выпустила 3 новые платы для Android-разработчиков.

Энтузиасты активно обсуждают, как использовать эти решения в качестве дешевых десктопов на Android:

• fully fledged desktop os on odroid-a,
• HardKernel ODroid-X Review with Android 4.0.4,
• Linux Kernel 3.6-rc5 runs Ubuntu ARM 12.10 on ODROID-X,
• Ubuntu for Android: Now multi-core Android phones can be PCs too

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

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

Сегодня появилось официальное письмо директора компании Zfort с описанием происходящей ситуации.

Доброго времени суток, решил рассказать вам о своем опыте получения свидетельства государственной регистрации прав на объект авторского права в Казахстане на программный код. Было это в 2011 году и в свете последних событий вокруг авторских прав и патентов, думаю будет интересно. Правда мой опыт рассказывает о регистрации авторских прав в Казахстане.
Немного предыстории- задумалось начальству на работе зарегистрировать авторское право на наш программный код. К большому сожалению мотив руководства до сих пор мне неизвестен, ответа я не получил. Разрабатывали мы автоматизированную информационную систему (АИС) для компании.
Перейдем к самому процессу регистрации. Заходим на сайт Комитет по правам интеллектуальной собственности министерства юстиции республики Казахстан. Находим там Инструкцию о государственной регистрации прав на произведения, охраняемые авторским правом и смежными правами. Сюда относятся как стихи, музыка, рассказы, карты, планы, эскизы, иллюстрации так и программный код или как написано на сайте программы для ЭВМ.

На КДПВ — MK802 mini PC на базе Android 4.0

Если вам был интересен процесс создания мини-ПК — вам сюда.

Под катом 9-минутное видео, включающее в себя процесс производства девайса и небольшое интервью с создателями.

После первой попытки создать мини-компьютер в лице Riko MK802 и CX-01 китайские производители продолжают экспериментировать. Следующим этапом завоевания рынка стал выпуск мини-компьютера с куда более интересными характеристиками.
Как обычно, первая проблема возникла с названием. На данный момент мини-компьютер называется UG802.
Второй интересный момент — кто же на самом деле производит это изделие. Никакого отношения к Rikomagic (как можно было подумать из названия) данное устройство не имеет. В Сети были анонсы этого устройства под маркой Reno Botes. Но третий, самый вероятный вариант, что UG802 был произведён китайской компанией UGoos.
Давайте посмотрим, какую аппаратную часть нам предлагают в этой новинке.

«Две тропинки идут рядом: путь жизни и путь смерти… Люди не идут никаким путём, ни путём жизни, ни путем смерти. Вихрь носит их, как солому.»
Густав Майринк, «Голем»

В офисе было тихо и темно, лишь стук клавиш и редкие щелчки мыши нарушали едва различимое жужжание кулера, да широкоформатный монитор освещал измождённое лицо regular developer'а Миши. Сторонний наблюдатель мог бы подумать, что идёт обычная рабочая ночь с пятницы на субботу. Так оно и было для тысяч других разработчиков по всему миру, но только не для Миши. Поставив очередную пустую бутылку под стол, он внезапно почувствовал, что граница, отделяющая его от гордого титула «senior developer», не так уж и далека.

«Я встаю не раньше полудня, работаю до двух часов ночи и выпиваю за раз до трёх литров пива. Наверное, я становлюсь профессионалом», — подумал Миша, и в этот самый момент почувствовал на себе чей-то тяжёлый взгляд. То, что он увидел, подняв глаза от монитора, заставило его замереть от ужаса. Две фигуры в серых балахонах стояли по обоим сторонам его стола. Лица, скрытые низко надвинутыми капюшонами, смотрели сурово, и в то же время безразлично. Страшно было пошевелить хотя бы пальцем или вздохнуть, а сознание отчаянно отказывалось верить в реальность происходящего — ведь Миша узнал этих двоих. Старшие коллеги рассказывали ему, что всякий раз, когда кто-нибудь подбирается к мистической грани между простым разработчиком и старшим, к нему приходят эти двое, чтобы посвятить в свои мрачные тайны.

Миша сглотнул и тихо спросил дрожащим голосом:

— Тим-лид Коля? Проджект-менеджер Изя? Рабочий день уже давно закончился, что вы здесь делаете? И к чему весь этот маскарад?

Случилось мне опрокинуть свой макбук с двух метровой высоты прямо ребром об асфальт, причем именно той стороной, с которой расположен жесткий диск — разумеется по непонятным мне причинам ноут стал жутко тормозить. Изначально я не придал этому особого значения, так как это был первый Мак в моей жизни, и я не знал, как они должны работать на самом деле. «Ну притормаживается, и что, тоже мне проблема» думалось мне до тех пор, пока не увидел как работает Макбук у моего друга. Причем у него-то белый пластиковый прошлого поколения, а у меня хваленый i7 с 4 гигами оперативки. Тут-то до жирафа и дошло, то что-то тут не так и надо бы его отвезти питомца в сервис центр.
Обследование показало, что диск убит неплохо (думаю никого не удивлю тем фактом, что от удара головки поцарапали диск) и как он вообще все это время работал сервис-техника немного удивило. Мне поставили новый хард на 750 гигов, а я технику поведал о том, как не замечал тормозов и т.д. Коснувшись темы производительности он спросил меня, а почему мол не выжимаю из системы максимум? "– Проц хороший, ноут не древний, можно было бы в пару раз производительность-то поднять, а?" Я призадумался…

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

Я отметил две проблемы подавляющего числа конфигов nginx'а, попадавших мне на глаза:

• «Всё в одном файле»
• Дублирование настроек

С помощью моего подхода, надеюсь, эти и многие другие проблемы будут устранены.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Магические константы в коде — зло. Строковые константы в коде — еще большее зло.
И вроде бы от них никуда не денешься, они повсюду:

1) При загрузке объектов из xib-ов:

MyView* view = [[[NSBundle mainBundle] loadNibNamed:@"MyView" owner:self options:nil] lastObject];

MyViewController* controller = [MyViewController initWithNibName:@"MyViewController" bundle:nil];

2) При работе с CoreData:

NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:[NSEntityDescription entityForName:@"MyCoreDataClass" inManagedObjectContext:moc]];
[request setSortDescriptors:@[ [[NSSortDescriptor alloc] initWithKey:@"someProperty" ascending:NO] ]];

3) Если вы используете KVO, то строки появляются и тут:

[self addObserver:someObservedObject 
       forKeyPath:@"someProperty"
          options:(NSKeyValueObservingOptionNew |  NSKeyValueObservingOptionOld) 
          context:nil];

4) Ну и KVC:

NSInteger maxValue = [[arrayOfMyClassObjects valueForKeyPath:@"@max.someProperty"] intValue];

5) Но даже если CoreData вы предпочитаете работу с SQLite напраямую, xib-ами вы брезгуете, то вот такой код вам должен быть знаком:

[self.tableView dequeueReusableCellWithIdentifier:@"MyTableViewCell"];

6) Ну и когда Apple представила миру Storyboard — это было замечательно, если-бы не одно но:

[self performSegueWithIdentifier:@"MySegue" sender:nil]

-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:( id )sender {
   if ( [segue.identifier isEqual:@"MySegue"] );
}

Вы видите проблему? Она состоит в том, что компилятор никак не проверяет содержимое строк, поскольку не знает (да и не может в принципе знать), что в них содержится. И если вы опечатаетесь или измените значение соответствующих полей в xcdatamodel / xib / storyboard / переименуете property, то ошибка вылезет не на стадии компиляции, а в рантайме, и отловить и исправить ее будет дольше и дороже.
Так что-же можно сделать?

update: Мы ещё живы и наконец-то открыли продажи!готовим первую партию к продаже конце сентября.
Новая версия стала куда лучше и выглядит теперь вот так:


Подробности в нашем блоге.
/update

TL;DR (Abstract)

Мы сделали маленький «одноплатный» встраиваемый компьютер с хорошим набором периферии, в основном беспроводной (GSM/GPRS, NFC, Wi-Fi, GPS, Ethernet, etc). Рабочее название — Wiren Board (от Wireless Enabled)

Предполагается, что использоваться он будет для всяческой автоматизации — то есть в качестве «мозга» для оборудования. Если вы хотите сделать умное устройство, не разрабатывая целиком собственное сложное железо, то это для вас. Впрочем, для DIY наш компьютер тоже весьма полезен, и об этом направлении мы не забыли при разработке. Если понадобится дополнить чем-то специфическим — функциональность можно расширять готовыми модулями. Что ещё приятно, стоимость компьютера мы планируем сделать всего около $100.

Первая версия уже готова, открыт предзаказ.

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

Фреймворк Ruby on Rails меня просто очаровывает, но до недавнего времени некоторую сложность представляла из себя генерация CRUD контроллеров.

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

• стандартный генератор scaffold_controller — ничего подобного нет, CRUD с простейшим дизайном
• nifty Scaffold — его разработка приостановлена, но все равно фильтрации и сортировки нет
• гем для DataTable — не прижился, он обеспечивает только представление данных, а код для фильтрации и сортировки пришлось бы писать самому

Долгое время не удавалось найти ничего похожего на полюбившийся мне виджет CGridView из Yii framework. Уже почти смирился с необходимостью писать свой велосипед, но наткнулся на DRY CRUD и хочу поделится опытом его использования. Может кому-то он окажется полезным, а может кто-то подскажет еще более подходящий инструмент.

Введение

На хабре уже несколько раз упоминали о проекте Meteor, основанном в 2011 году семерыми энтузиастами web-технологий из Сан-Франциско. По сути Meteor является просто надстройкой над node.js, который сам ещё даже не дошёл до релизной версии. Тем не менее проект собрал более семи тысяч подписчиков на github и получил 11 миллионов долларов инвестиций.
С чего такая популярность? Дело в заявлении авторов о том, что они хотят кардинально переосмыслить способ написания современных web-приложений в сторону его упрощения. Не секрет, что написание кода на чистом node.js довольно сильно выворачивает мозг и вынуждает использовать различные костыли в виде control flow средств. На Meteor, говорят авторы, писать крутые приложения сможет даже гуманитарий.
Ну что же, проверим. Имеется: 1 гуманитарий-социолог, закрывший сессию и желающий после Парсонса и Зиммеля перейти на что-нибудь полегче, компьютер с Ubuntu 12.10 и установленный node.js (не спрашивайте, как он оказался у социолога).

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

Описывая один из компьютеров Power Mac, Айв рассказывал: «Мы хотели избавиться от всего, без чего можно было обойтись. Для этого требовалось абсолютное взаимопонимание между дизайнерами, разработчиками, инженерами и изготовителями. Мы без конца возвращались к исходному пункту. Нужна ли эта часть? Может ли она выполнять функции остальных четырёх?»
Уолтер Айзексон, «Стив Джобс. Биография».

В ТРИЗ (Теория Решения Изобретательских Задач), разработанной советским изобретателем Генрихом Альтшуллером есть одно из базовых понятий — понятие идеального объекта.
Формулируется понятие очень просто — идеальный объект — когда объекта нет, а функция его выполняется.

Сегодня я хочу вам рассказать о создании игры для iOS на основе Cocos2D на примере недавно вышедшей игры «Пчелогонки» (анг. – Bee Race).
Геймплей не содержит в себе ничего сложного – это по сути бесконечный ранер, в котором нужно собирать поинты и уворачиваться от препятствий. Только вместо рыжей девочки или кладоискателя – здесь летает двухмерная пчелка.
Для заинтересовавшихся, прошу под кат (Ахтунг! Минен унд много буквирен).
Основные разделы для рассмотрения:

1. Очень краткое введение в Cocos2D
2. Используем Cocos2D одновременно с StoryBoard
3. Краткое описание геймплея и структуры проекта
4. Покупаем инструменты и что делать, если душит жаба
5. Чем не пахнет приложение или подключаем in-app билинг
6. Социализируем. Подключаем Game Center и создаем мультиплеерную версию на два игрока
7. В чём промахнулся Акела
8. Паблиш

Спойлер:

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

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

Удивительно, что человек проработал 10 лет менеджером в ИТ, а у него нет инструкций и документации, что же должен делать менеджер в течении дня. Так может учебник «Основы менеджмента» хотя бы стоило прочитать. А вообще-то менеджмент — это такая научная специальность отдельная… Тысячи научных специалистов трудятся в ней, какие-то теории управления придумывают, книги издают, исследования проводят, те же agile-методы (scrum и другие) развивают. Может там следует инструкции поискать? Ах да, там же одна «водичка» написана, а у нас тут реальные проекты, да еще и работники какие-то неправильные, ни под одну теорию менеджмента не вписываются.

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

1. Геймплей

Главные сходства игрового процесса таких хитов рынка мобильных игр, как Angry Birds, Ninja Jump, FruitNinja, Rope'n'Fly, Doodle Jump — простота и однообразие. Минимум действий и постоянное их повторение.

а) Лёгкость прохождения

Все самые популярные игры крайне легки в прохождении или собственно в самом процессе игры. Эта одна из главных причин их бешеного успеха. Большинство владельцев телефонов и планшетов — обычные люди, они не считают интересным пяток раз на выходных перепройти Марио или Battletoads. Также помните причины, по которым люди играют в мобильные игры. Причины эти — скука и усталость. Люди сидят на работе, на скучных лекциях, едут в метро, и вполне логично у них возникает желание поиграть. Поэтому ни в коем случае нельзя делать огромные сложности в играх — скучающие не получат веселья (девиз Dwarf Fortress «Проигрывать — это весело» здесь не прокатит), а уставшие от сложностей на работе не станут вкладывать кучу сил ещё и в какую-то игрушку.