Cosmic Fail

Space Engine позиционируется как симулятор Вселенной максимальной реалистичности. Известные объекты описаны реальными данными, неизвестные смоделированы. Можно «слетать» к Сатурну и посмотреть на влияние кольца на цвет поверхности, вернуться на Землю и увидеть северное сияние, пролететь сквозь туманность и посетить соседние галактики. Все очень красиво и плавно работает на не самых мощных компьютерах. Но успех ли это?

Проект начался в 2005 году. Пятнадцать лет — это долгострой уровня третьего Half-Life и Duke Nukem Forever. Причины — отказ от привлечения инвестиций, закрытые исходные коды и авторитарность единственного разработчика. Автор, студент-астроном, просто «пилит» в свое удовольствие хобби-проект, который со временем стал работой за счет пожертвований игроков, мечтающих о «настоящем космосе».

За это время проект стал позиционироваться как «планетарий». Теперь это не какая-то игрушка, а «серьезный инструмент для изучения астрономии». Но увы — на фоне современных звездных каталогов проекта Gaia данные проекта Hipparcos 30-летней давности малочисленны и недостоверны. Большая часть виртуальной Вселенной синтезирована или воспроизведена по изображениям, тоже не всегда достоверным. Небесная механика для такого амбициозного проекта тоже недостоверна и при воспроизведении известных, наблюдаемых событий небесные тела банально «промахиваются». Для игры это проблемой не является, а вот для планетария явно недопустимо.

Автор предлагает свой «движок» для интеграции в сторонние проекты, но за прошедшие 15 лет проект остается «черным ящиком», позволяющим видеть красивые картинки на тему космоса.

Автор ищет тех, кто присоединится к проекту. Но не найдет — авторитарность и необходимость работать на общественных началах делает этот поиск безнадежным. Используемые технологии (С++ и GLSL) пока еще уместны и применимы, но (что особенно касается видеокарт) не вечны и шансы прийти к планируемому релизу на устаревших технологиях (данные, напомню, уже устарели) растут изо дня в день.

Автор пробирается к светлому будущему в одиночку, решая вопросы физического и графического моделирования по мере их возникновения. Вопросы игровой логики, сюжета и баланса нет даже на горизонте событий. Что в переводе с языка астрофизиков означает «никогда».

Вот что бывает, когда проект «в одно лицо» делается программистом. Типичный пример «внутренней вселенной» аутизма, которому в той или иной степени подвержены все «демиурги от программирования».

Это ли не fail?

Про SQL

В запросах полям можно назначать синонимы. Но по ним нельзя сортировать.
select name as username from users order by username
Стандарт говорит нам «используйте реальные имена полей, потому что на момент сортировки синонимы еще не определены».

Ладно, пример не показателен. Но если одна и та же таблица используется несколько раз, то использование реальных имен вызывает путаницу — из какой именно части запроса это поле?

Выход я, конечно, нашел. Если использовать синонимы для таблиц, то в сочетании с реальными полями неоднозначность исчезает. То есть для таблиц синонимы определяются сразу, а для полей — нет. Где логика? Это какой-то бред.

Lua

«Католицизм — это круто». Кевин Смит, «Догма».

Lua — это язык программирования, написанный подразделением технологий компьютерной графики Папского Католического университета Рио-Де-Жанейро. Все-таки католики знают толк в миссионерстве — о языке Lua нет даже нейтральных отзывов, только восторженные. И восторг этот, как оказалось, вполне оправдан.

Lua («луна» по-португальски) проектировался — и до сих пор является непревзойденным в этом своем качестве — как встраиваемый язык сценариев. Он компактен — всего 300 кило(!)байт; он прост — изучается без преувеличения за час; однако простота не синоним ограниченности, он мощен — поддерживает императивный, функциональный, объектно-ориентированный подходы, в нем даже есть многопоточность.

И он быстр — об этом говорит успешное применение в графике вообще и в видеоиграх в частности. В простеньком Angry Birds и в «навороченном» World of Warcraft, во вполне коммерческом Adobe Lightroom и в полностью свободном GIMP, в системном OpenWRT и прикладном SciTe — то есть везде, где быстрая низкоуровневая платформа нуждается в удобной и гибкой логической надстройке.

Lua работает везде. От мобильных устройств на Android, iOS и Symbian (и даже проще — игрушечных роботов Lego Mindstorm тоже можно программировать на Lua) до мейнфреймов. Впрочем, на мейнфрейме можно запустить все, что угодно, это не особенно интересно. Зато интересна поддержка всех разновидностей Windows, Linux и UNIX. Да, и MacOS с WindowsPhone тоже.

Определенно, Бог создал мир за шесть дней потому, что написал его на Lua.

PHP это джинн…

… а джинн не должен покидать лампы.

Всякое использование PHP вне LAMP — это попытка устроить грузчика на работу в детский сад воспитателем. Или наоборот.

Не phpMyAdmin-ом единым…

Кто не знает phpMyAdmin? Наверное, только тот, кому не приходилось работать с SQL. Многие предпочитают этот веб-интерфейс даже «настольным» приложениям — официальным и не очень, бесплатным или «ломанным». Секрет этого продукта в том, что его достаточно «вылить» в любую директорию сервера и… и все. Вводите логин-пароль — и делаете все, что нужно.

На самом деле, он может гораздо больше и множество дополнительных возможностей требует настройки конфигурационных файлов. Но нам-то — кому требуется по-быстрому создать нужную структуру, выполнить запрос или исправить одну-две строки в таблице — всего это не требуется. Полностью настроенный интерфейс со всеми возможностями может быть востребован — и в большинстве случаев используется! — хостинг-провайдерами, которые предоставляют своим клиентам базы mySQL. Остальным же функционал в 17 мегабайт (в архиве 3,5) сильно избыточен. Что же делать?

Например, использовать Adminer. Один-единственный php-файл размером от 158 (английская версия для mySQL) до 381 (многоязычная версия для mySQL, Postgres, SQLite, MS SQL и Oracle) килобайт. Который может… ну, в общем, мне не потребовались функции, которыми не обладает этот продукт. Есть еще рекордно малый (30 килобайт) PHP Mini Admin for MySQL, но сильно проще — не умеет редактировать записи прямо на странице и работает только с mySQL. Продукт либо не завершен и будет еще активно дорабатываться, либо отражает отношение создателя, для которого возможности выполнять запрос достаточно, а всякие «интерфейсные красивости» избыточны и бесполезны.

В общем, остановился на Adminer. Лаконичный, удобный и достаточный инструмент. «Must have!»

XP

Extreme Programming

Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, — это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях. Команды, использующие ХР, производят качественное программное обеспечение с весьма большой скоростью.

Не в этой ли моде причина всеобщей болезни срывов заявленных сроков — Doom3, Half-Life2, NeedForSpeed Carbon? Не говоря уже об отечественной Lada Racing Club — у этих вообще продукт доводился уже после поступления в продажу.

Не могло это быть простым совпадением, что-то одновременно повлияло на монстров игрового рынка. Теперь понятно — «модная болезнь» XP ударила по связке «цена-время-качество», закона сохранения энергии ведь никто не отменял. Причем на Западе, где дорожат репутацией, пострадал критерий «время», а у нас — «качество». «Дорога в будущее» по Гейтсу — идеалисты верят в «новый подход», а реалисты за красивыми сентенциями прячут банальное «клиент потерпит». Между тем «наше все» — это все-таки Юникс и тот свободный софт, который пишут энтузиасты под лозунгом «Code is poetry». Наверное, во мне говорит дух индивидуализма. А еще — любовь к своему делу. И такой «экстрим» мне не по душе…

phpTAL

PHP Template Attribute Language

Одно из решений извечного вопроса web-разработки — «как разделять функциональный код, дизайн и наполнение?». Что делать это надо, вроде бы уже решили, а вот выбор того как это делать…

Подобно тому, как FastTemplate, написанный изначально на языке PERL, а потом перенесенный на PHP (одна из этих реализаций, кстати сказать, принадлежит мне), phpTAL является частью проекта ZOPE (однако, каково название), изначально написаного на языке Pyton, а потом вошел в состав пакета Smarty. В общем-то это не удивительно — технологии быстро становятся кросс-платформенными, а новые «инструментальные» продукты предпочитают предлагать разработчику уже известные технологии, а не каждый раз предлагать изучить что-то новое.

Преимущество phpTAL над FastTemplate декларируется в расширенных возможностях настройки шаблонов. Эти возможности предлагаются в виде специализированного языка программирования, на котором можно определять условия вывода того или иного блока, значение переменных, даже получение доступа к внешним данным. Да, поведение шаблона теперь можно определять достаточно подробно. И вроде бы все хорошо, но не отпускает смутное ощущение идиотизма ситуации…

Если нашей первоначальной целью было разделение кода от дизайна, чтобы дизайнер и программист независимо друг от друга могли работать над одним проектом «не пересекаясь», зачем снова все смешивать в «коктейль Молотова» и в сверстанном коде шаблона запрятывать дополнительную логику исполнения на дополнительном языке программирования? Зачем на ровном месте создавать еще одну технологию и стандарт, которую надо изучать, еще уровень проектирования, который усложняет разработку, еще один компонент системы, который снижает производительность и уже не может работать без «протезов» вроде кеширующей генерации кода и предопределенной обработки исключений, которая накладывает дополнительные ограничения на свободу действий программиста? Как же в таком случае принцип необходимого и достаточного, который в шутливой форме формулируется как KISS-принцип («Keep It Simple, Stupid» — «Делай проще, дурачок»)?

Когда-то я написал собственную реализацию Fast Template для php, когда используемая внешняя библиотека дала необъяснимый сбой. Функциональность ее была, конечно, весьма аскетичной и развивалась в основном «вглубь»,а не вширь — то есть путем оптимизации кода, а не расширения его функциональности. И было время, когда мне казалось, что внутри шаблона необходимо сделать какой-либо механизм, позволяющий тут же, «не отходя от кассы», определять поведение этого шаблона. И тогда мне это казалось правильным и необходимым. И вот мне предоставился случай увидеть свет в конце пути, крайнюю степень развития этой идеи. Сейчас она уже не кажется мне такой правильной и необходимой. Однажды разделенные, код и дизайн не должны снова смешиваться. Эту стадию «гремучих смесей» мы уже проходили…