Программистские записки Алексея Фомкина

О старых знакомых

2012-01-13T10:15:00.003+04:00

Пару лет назад, у адоби был такой проект, назывался Flex Builder Linux. Основан он был на кодовой базе Flex Builder 2, в нем отсутствовали профайлер и дизайн-вью, он находился в вечной "альфе", за то работал автокомплит и дебагер (с горем пополам). Это было единственное вменяемое средство разработки для флеш, под линуксом, которое я знал, по этому выбирать не приходилось. Естественно приходилось мириться с гюками, которые я списывал на "альфу". Потом JetBrains сделали поддержку AS3/Flex в IDEA, а умные люди посоветовали мне на нее перейти. Что я собственно сделал, и забыл о проблемах. Потом в моей жизни появился мавен, и к середине 2011 года я наслаждался созданием проектов из архетипов и настройкой среды в один клик. Как же это здорово, когда твой проект, состоящий из нескольких flex-модулей, java-модулей, кодогенераторов и прочего дерьма, разворачивается в один клик и работает, да. Так вот, к чему это я: вчера я поработал, в течении вечера, с Flash Builder 4.6, и знаете, что? Я встретил все старые добрые глюки из той самой "альфы" для линукса. После стольких лет разлуки.

Забор вокруг туалета.

2011-09-05T09:47:00.000+04:00

Есть такой проект Facebook ActionScript API (http://code.google.com/p/facebook-actionscript-api). Так как работа под браузер, дестктоп и девайсы несколько различаются, ребята сделали несколько реализаций своего API. Но как они это сделали!

Есть три класса-синглтона: Facebook, FacebookDesktop и FacebookMobile, отнаследованные от некого AbstractFacebook. Пока все хорошо, идем дальше. Каждый из классов имеет набор статических методов, которые в свою очередь вызывают методы приватного инстанса того же класса. То же не плохо, но вот теперь начинается жопа - все методы инстанса и getInstance() объявлены, как protected! То есть использовать их можно только через статику или отнаследовавшись от нужной платформенной реализации (что в свою очередь то же не правильно). Таким образом ребята перекрывают естественный путь для повторного использования кода при создании мультиплатформенного приложения, а именно приложение работает с чистым платформонезависимым интерфейсом, реализации которого подставляются исходя из цели компиляции.

Синглтон в данном случае весьма уместен. Согласитесь, глупо создавать инстанс API-класса, такскать его по всему приложению, учитывая, что в 99% случаев оно будет работать только с одним фейсбук-профилем одновременно. Это не тот случай, когда нам нужны инъекции, синглтон оберегает нас от желания некоторых тащить зависимость через параметры конструкторов. Но получилось так, что отрезая пути быдлокодеров, ребята отрезали и нормальные юзкейсы.

В программировании нужно руководствоваться здравым смыслом. Глупо строить забор с калиткой вокруг общественного туалета.

После отсутствия.

2010-08-11T18:13:00.000+04:00

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

Для работы в своих проектах мы используем разнообразные предметно-ориентированные языки. Один из них служит для описания структур данных (будем называть его SL). Структуры описанные на нем используются для клиент-серверного обмена. Иметь промежуточный язык очень удобно, когда клиентская и серверная части написаны на разных платформах и языках (к примеру Flash и <подставьте сюда то, что вам больше нравится>). Многие в этом случае пишут свой код дважды. В нашем случае транслятор SL подготавливает структуры данных и методы сереализации под все используемые в проекте платформы.

В OCaml есть такая интересная штука, как Variants. В Scala подобную роль выполняют Case Classes. Поддержка такой языковой конструкции есть и в SL. К сожалению почти во всех императивных языках ее поддержки нет, что создает сложности для трансляции кода из SL в эти языки. На пример для AS3 нет способа реализовать подобное типобезопасно. Недавно понадобилось сделать кодогенерцию SL в Java.

// SL
variant game-resource
  float money
  float energy

// Генерированный код.
public class PGameResource {

    public interface Matcher {
        void energy(float value);
        void money(float value);        
    }

    private Object __storage;
    private byte __variance;

    public void match(Matcher matcher) {
        switch (__variance) {
            case 0:
            matcher.energy((Float) __storage);
                break;
            case 1:
            matcher.money((Float) __storage);
                break;            
        }
    }

    public void set_energy(float value) {
        __variance = 0;
        __storage = value;        
    }
    public void set_money(float value) {
        __variance = 1;
        __storage = value;        
    }

        // ...
}


// Разбор
value.match(new PGameResource.Matcher() {
    public void money(float value) {
        quest.reward.add(new AddResourceAction<Quest>(
                FunholeResourceKind.MONEY,
                value));
    }
    public void energy(float value) {
        quest.reward.add(new AddResourceAction<Quest>(
                FunholeResourceKind.ENERGY,
                value));
    }
});

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

Разочарование в NME.

2009-12-14T12:08:00.000+03:00

Для тех, кто не в курсе. NekoNME это набор биндингов SDL для Neko. В сочетании с Neash представляет собой реализацию Flash API для neko/hxcpp. Простыми словами, эти библиотеки позволяют создавать флеш-приложения в машинном коде для разных платформ (включая IPhone). Звучит очень здорово. Я на пример просто слюной истекаю, когда представлю себе скачиваемый клиент для флешовой MMO, который не тормозит (машинный код + видеокарта).

Некоторое время назад мною была написана серия тестов анимации (что-то вроде 1000 Ogres) и я решил попробовать скомпилировать их в neash/nme. Пришлось дописать Loader::loadBytes, переписать BitmapData::copyPixels и исправить одну критическую ошибку в реализации Input для hxcpp. На все про все ушло примерно четыре часа и тест запустился в режиме software-rendering. В режиме OpenGL он пускаться не захотел.

Производительность будем мерить в FPS :) Итак NME-версия отставала от обыкновенного flashplayer на 10 FPS, хотя таймеры работали субъективно быстрее. Я списал тормоза на software-rendering и отправился ковырять, почему не работает OpenGL. Немного погуглив по ошибке

Couldn't set OpenGL mode: Couldn't find matching GLX visual

мне стала понятна проблема, я внес соответствующие изменения и пересобрал NME (про пересборку отдельная история). Увеличение производительности по сравнению с flashplayer всего 10 FPS. Обидно. Я ожидал, что сейчас все полетит на третьей космической скорости, графика ведь не сложная: ~1000 двадцатикадровых анимаций на разрешении 1024x768. Для современной видеокарты это не задача.

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

Первое сообщение и проблемы с Socket в haXe/cpp

2009-11-16T18:20:00.000+03:00

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

Что бы не плодить сообщения, перейду сразу же к делу. Думаю, что читателю известно, что компилятор языка haXe имеет C++ бэкэнд. То есть исходный код haXe транслируется в C++ код, что бы затем быть скомпилированным в машинный. Сейчас я экспериментирую с haXe, как с серверным языком, но изначально пишу все под NekoVM, но как-то на днях решил попробовать скомпилировать свои поделки в машинный код, ведь API стандартной библиотеки haXe/cpp совместимо с API haXe/neko.

Значит есть у меня сервер, клиент (haXe/Flash9), и бот, что бы нагрузочно тестить. Сервер у меня не собрался вообще, но с этим я пока не разбирался, клиент собирать не пробовал (хотя такая возможность есть за счёт библиотеки Neash), а бот нормально собрался, но работать не захотел.

Runtime error:
Terminal error not bytebuffer, File.//libs/std/Socket.cpp, line 186

Начал рыться в исходниках стандартной библиотеки (в этом самом Socket.cpp), но ничего не нашёл. Оказалось, что ошибка находится в SocketOutput.hx. В нативную функцию записи буффера вместо буффера передаётся ссылка на функцию Bytes.getData (). Совершенно глупая опечатка: автор забыл скобки! Между прочим этот случай раскрывает прелесть динамической типизации:) Нативные функции загружаются как динамический объект, по этому мы не имеем проверки типов аргументов во время компиляции.

Создаётся ощущение, что библиотеку не тестировали вообще. В этом есть минус opensource: ребята пишущие cpp бэкэнд просто не сталкивались с записью данных в сокет через Output, а пользовались writeString, по этому целый кусок кода оказался не оттестированным. Самое интересное, что их нельзя за это винить, ведь они пишут библиотеку для себя и делают свой вклад, не обязуясь создать безглючный «продукт». С другой стороны это плюс opensource: каждый может взять исходный код и исправить инструмент под свои нужды. Хорошо, когда открытость сочетается с enterprise-качеством.

Мой патч исправляющий проблему: http://hxcpp.googlecode.com/issues/attachment?aid=-7013333957780095441&name=socketoutput.patch