Особенности кодирования

Занимаясь разработкой своего пета, наконец-то смог четко выделить две особенности, которые (как мне кажется) отличают мой стиль программирования.

Первое. Частый compile/run. Для компактного приложения (например, для юнит-теста) я стараюсь пользовать функцию компиляции проекта и его запуска максимально часто (примерно раз в минуту). При этом запуску подвергается любой успешно собираемый вариант - пусть даже он имеет одни только заглушки и его исполнение гарантированно обрушит программу - я хочу видеть КАК ИМЕННО оно его обрушит? Получу ли я нужную диагностику в протокол, совпадет ли вывод в лог и поведение программы с тем, что я ожидаю. Например, недавно получил pure function call, который бы 98% не случился, если бы я написал чуть больше кода, а не бросил реализацию функции на полпути.

Второе. Перевод ошибок в компайл-тайм. Отлаживал ошибку с порчей хипа, оказалось, что в нужном месте не нажался амперсанд и класс, который не имеет права пользовать copy ctor, вернулся из функции не по ссылке, а по значению. Наверное, большинство программистов заменят MyClass get() на MyClass& get() и успокоятся (ошибка исправлена). Я вместо этого поступаю иначе. Сначала меняю реализацию MyClass - добавляю приватный copy ctor и на всякий случай в него пихаю hard assert с диагностикой "this call is not allowed" (чтобы потом не облажаться еще и во внутренних методах). Потом компилирую программу и получаю желаемую ошибку в compile time. И только после этого исправляю MyClass& get().

А используются ли такие особенности кодирования у вас?

Апгрейд

На прошлой неделе, занимался плановым "апгрейдом" техники. Все дело в том, что меня перестал устраивать функционал коммуникатора, и я решил поменять его на связку "простенький телефон + ноутбук". Простеньким телефоном стал Samsung Duos GT-B5722 (кстати, продаю годовалый Samsung Witu с 8 Гб на борту - http://market.yandex.ru/model.xml?hid=91491&modelid=2616809&show-uid=947813912699571252 - за весьма умеренные деньги - 7 тысяч неденоминированных рублей), ну а в качестве ноутбука был выбран довольно простенький (даже больше похожий на нетбук) Acer AS3410.

Windows Vista неожиданно шустро пошла на ноуте (разумеется, после определенного твикирования).
Порадовало, что большинство игрушек от Алавара также летают с весьма приемлемой производительностью.
Дальнобойщиков на нем запускать не хочу, чтобы не расстраиваться :)
А вот флеш игры вконтакте удивили. Почему-то "Город" с весьма плотной и детальной графикой летает на порядок лучше, чем абсолютно примитивный по графике, но не вылезающий за 4-5 FPS "Лунапарк". Интересно, почему? :-D.

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

Многопоточность (поток сознания)

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

Модная несколько лет назад тема "а давайте разместим игровой цикл в двух потоках - графика отдельно, физика отдельно" постепенно сходит на нет. И слава богу. По целому ряду причин. Во-первых, двухпроцессорными машинами уже никого не удивить, скоро никто не будет удивляться процессорам, в которых количество ядер будет измеряться двузначными числами. А во-вторых (и это более важно), ручное распределение задач по ядрам имеет определенную степень осмысленности только для простых задач, где такое распределение действительно может принести определенный перформанс. Но чем сложнее становится код, тем сложнее: а) держать в голове все выполняемые приложением задачи, б) иметь действительно эффективную реализацию многопоточности, в которой треды будут выполнять вычисления, а не ожидать друг друга.

Collapse )

Строительство, и ни капли agile'а

Вот оно, чего я так долго планировал сам, продумывал, рисовал в Google SketchUp, и наконец, вопротил в жизнь при помощи профессиональных архитекторов. Трехкилограммовый диздок (спасибо огромное Стратегу, что он приволок его сегодня на работу):


Да, пользуясь случаем, хочу сказать, что пока что тренд обрастает крайне правильными знакомствами, которые могу посоветовать всем друзьям, если таковая потребность возникнет.
  • очень хороший агент по продаже недвижимости. Честно говорю - не из самых дешевых, но я ни разу не пожалел, что обратился к нему;
  • очень хорошее архитектурное бюро, которое и подготовило мне этот диздок строительный план;
Если кому нужны контакты - прошу в личку.

Следующая задача после всего этого - определяться с поставщиками middleware всяких разных материалов и, что более важно, с бригадой, которая согласится все это возвести. На примете уже есть несколько вариантов, но если кто-то сможет что-то посоветовать дельное, буду очень рад. Вариант "таджики с ярославки под моим присмотром" отметаю сразу, ибо даже обладание таким трехкилограммовым талмудом и просмотр всех передач телеканала "Усадьба" не дает мне уверенности в своих силах. Поэтому рассматриваю варианты "вменяемый бригадир / бригада", "строительная фирма" и т.п. Не Москва, возможно мос. область, возможно - что-то более отдаленное.

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

Agile и строительство

В развитие вчерашней дискуссии про предварительное проектирование компонент. И одновременно это будет третья запись про тренд :).

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

Что тут думать, трясти надо!

Уже в который раз вижу, что огромное количество провалов в разработке связано в первую очередь с [полным] игнорированием технического препродакшена компонент приложения перед началом их разработки. Это, кстати, относится не только к коробочным играм (совсем критично), но также и к казуалкам (уже достаточно заметно, чтобы вызывать крупные проблемы), и к играм для соц. сетей (там пока еще это разгильдяйство сходит с рук, но ситуация изменится в ближайший год).

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

Результат, в общем-то, плачевен - подсистема, на разработку которой было потрачено много месяцев (например, препродакшен - 2 минуты "а давайте сделаем красивую ***ню", разработка - 5 неконтролируемых месяцев wild development) к моменту своего релиза оказывается как минимум УГ, а как максимум - физически несовместима ни с чем и требует либо своей полной переделки, либо полной переделки всего софта.

Еще немного про кино

Честно признаюсь - не люблю ходить в кинотеатры, но текущий год с двумя просмотрами уже побил рекорд как минимум всей моей московской жизни. Очевидно, это связано с активным нашествием 3D формата. Очевидно, что двумя фильмами стали Аватар и Алиса.
Про Аватар писал чуть ранее, Алиса с точки зрения 3D воздействия на зрителя выглядит намного интереснее и веселее. К тесным 3D очкам тоже приспособился, так что можно было вполне вникать в происходящее на экране.
Впрочем, трактовка сюжета довольно спорная, от оригинальной отличается заметно. Скорее, это не "Алиса в стране чудес", а "посмотрите, как несколько знакомых (даже, знАковых) сюжетов из Кэрролла можно связать в другую историю".
Вполне вероятно, что с развитием домашних 3Д-технологий я снова заброшу посещение кинотеатров и вернусь к более привычному и приятному режиму просмотра фильмов в домашних условиях, пусть даже и с опозданием на пару месяцев от премъеры. И чтобы снова затащить меня в кинотеатр, надо будет анонсировать фильмы с изменяемой гравитацией на сферическом экране (как это успешно применяется во многих аттракционах) и прочие вибро-запахо-дождево-температурные эффекты.

Топ-10 самых нелепых падений игр (2)

Очень давно ничего не писал в ЖЖ. Банально нет времени, сначала его было мало из-за операции на руке, потом навалились проблемы с оформлением документов на строительство и я вынужден был пропадать в Королеве.

Впрочем, этот пост был заготовлен давно - он писался в течение года, периодически сортировался, и наконец, готов.

Новый Топ-10 самых нелепых падений игр. Частично повторяет старый, ибо, как это ни грустно, проблемы с запуском игр повторяются снова и снова. И снова разработчики наступают на те же самые грабли (при желании можно сравнить список с тем, который был опубликован год назад). Впрочем, старых ошибок не так уж и много. Либо разработчики все же читают мой ЖЖ, либо квалификация программистов за прошедший год существенно повысилась, либо "плохие" разработчики не смогли пережить кризис.

Итак, поехали.

Collapse )