gomix.com (HyperDev) - новая игрушка для веб разработчиков

Товарищ Joel Spolsky, известный как один из основателей stackoverflow.com и блогер joelonsoftware, рекламирует новую интересную штуку для веб-разработчиков - gomix.com (в девичестве HyperDev) - "a developer playground for building full-stack web-apps fast", онлайн сервис, позволяющий быстро и бесплатно сваять веб приложение, без необходимости платить за его хостинг.

Вкратце, это возможность слепить свою несложную поделку на nodejs без необходимости все это администрировать/настраивать/платить за хостинг, причем и back-end и front-end создается в одном месте - во встроенной онлайн IDE. Сейчас это в находится в состоянии public beta, но они обещают, что и после релиза возможность бесплатного его использования останется - "We expect to always have some sort of free plan, but we may charge for premium services or capabilities down the line".

Проектики при этом будут open-source. Что еще интересно - есть возможность взять чужую поделку и на ее основе делать свою. При этом некоторые папки/файлы не доступны для свободного доступа (ну то есть можно запихать туда какие-нибудь БД/API key и их никто не увидит, кроме авторизованных разработчиков).

НЕ НАДО:

• Создавать аккаунт (можно играться анонимно, но при этом все будет через 5 дней стерто, или использовать github аккаунт).
• Использовать git
• Иметь дело с хостинг провайдерами
• Настраивать сервер
• Устанавливать ОС
• Инсталлировать Node.js или еще что-нибудь.
• Заботиться о том, чтобы задеплоить приложение.

В общем хорошая платформа для хобби-проектов.

Интересный ресурс на github'е - Библиотека программиста

Чтобы не потерялось:

• Лучшие ресурсы для изучения Angular 2 с нуля.
• Успешное прохождение интервью для фронтенд разработчика.
• Бесплатные ресурсы для изучения NodeJS

Там еще ссылки на книжки по программированию есть

Книжка про архитектуру open source приложений

Книжка про архитектуру 25 популярных open source приложений (на английском):
http://www.aosabook.org/en/index.html

Очень полезное чтение для программистов - это серия коротких описаний внутреннего устройства больших опен-сорсных приложений.

Абзац из введения: "архитектура зданий и архитектура ПО имеют много общего, но есть одно важнейшее отличие. Архитекторы во время своей учебы и карьеры изучают тысячи зданий, большинство разработчиков имеют возможность хорошо изучить только несколько больших программ. Чаще всего это те программы, которые пишут они сами. У них нет возможности изучать величайшие программы в истории или читать критику архитектуры этих программ, написанную опытными практиками. Как результат, они повторяют ошибки друг друга, а не строят на основе успешного опыта других".

Книжка пытается помочь решить эту проблему за счет приложений с открытым исходным кодом.

Содержание:
Introduction
1. Asterisk - программа для создания телефонной станции.
2. Audacity - запись/редактирование звука.
3. The Bourne-Again Shell - bash Unix shell
4. Berkeley DB - высокопроизводительная нереляционная БД
5. CMake - кроссплатформенная система автоматизации сборки программного обеспечения из исходного кода.
6. Eclipse - популярный IDE (конкурент MS Visual Studio)
7. Graphite - система для построения графиков
8. The Hadoop Distributed File System - распределенная, масштабируемая и компактная файловая система, написанная на Java
9. Continuous Integration - система для построения и тестирования программ.
10. Jitsi - приложение, позволяющее делать видео/аудио звонки, расшаривать свой десктоп, обмениваться файлами и сообщениями
11. LLVM - цитата с википедии: "универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями. Может использоваться как оптимизирующий компилятор этого байткода в машинный код для различных архитектур либо для его интерпретации и JIT-компиляции (для некоторых платформ). LLVM позволяет компилировать программы написанные на языках Си, C++, ObjC, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end."
12. Mercurial - популярная система контроля версий
13. The NoSQL Ecosystem - ряд подходов к интерфейсам БД без использования SQL.
14. Python Packaging - система питоновских пакетов.
15. Riak and Erlang/OTP - распределенная отказоустойчивая БД для больших масштабируемых систем на Erlang/OTP
16. Selenium WebDriver - фреймворк для тестирования веб приложений
17. Sendmail - первый и все еще существующий Mail Transfer Agent
18. SnowFlock - монитор виртуальных машин для облачных вычислений
19. SocialCalc - электронные таблицы в интернете
20. Telepathy - фреймворк для создания программного обеспечения мгновенного обмена сообщениями, IP-телефонии или видеоконференций.
21. Thousand Parsec - фреймворк для создания космических стратегий.
22. Violet - простой UML редактор
23. VisTrails - система для визуализации научных данных
24. VTK - Visualization Toolkit - система для обработки и визуализации данных
25. Battle For Wesnoth - пошаговая стратегическая игра

Отчет о поездке на КРИ 2011

13-14 мая был на КРИ 2011.
Список лекций, на которых я успел сходить:

1. Интерфейсы "Аллодов Онлайн" изнутри.
   Это было в 10 утра, проектор в этом зале еще не работал, так что слайдов не было. Лекция была довольно странная, про языки программирования, взаимодействие клиента и сервера, систему аддонов, виджетов и скриптов, репликацию данных, внутреннее устройство классов - и все за 20 минут. Я кстати, видео на фотоаппарат снимал и выложил то, что вышло на youtube - 1/2, 2/2.
2. Игровая механика, управляемая данными.
   Проектор все еще не работал, лекция без слайдов, так что тоже не слишком понятная вышла. Посвящена была data-driven подходу в грядущей игре Prime World от Nival. Цель - передать как можно больше работы от программистов гейм-дизайнерам. А именно - передать настройку взаимодействия различных игровых объектов, таких как игроки, NPC и прочее, между собой. Грубо говоря, кто кого и с какой силой имеет право бить файрболом по башке. Все это реализовано через систему аппликаторов и функций. Функции кодируются в строки, передаются на клиент в виде закодированных в base64 данных и на клиенте распаковываются и компилируются, если я правильно уловил идею.
3. Мир танков: проблемы роста
   Лекция про проблемы масштабирования, с которыми столкнулись в wargaming.net при увеличении популярности World of Tanks. Как устроена раздача патчей (CDN/torrents), проблемы, связанные с ростом команды на 100% за год, немного про отдел тестирования и про необходимость отдельного отдела для deployment'а.
4. Портируем с iPhone на Windows Phone 7 за 24 часа.
   Лекция была посвящена переносу одной игры с iOS на Win Phone 7, вели ее двое - Михаил Черномордиков из Microsoft и парень из проекта этой игры. Я фотографировал слайды, так что пока не найдется нормальная презентация, можно посмотреть на них. В том числе там был любопытный слайд про доли рынка мобильных ОС. Я вытащил данные с него в google docs:
   
   
   Диаграмма, которая говорит о планируемых продажах мобильников с конкретными ОС с 2010 по 2015. Мораль: в 2015 половина новых смартфонов будет под андроидом. Также актуальными будут iOS и Windows Phone 7.
   
   А на этой диаграмме показаны доли уже существующих на руках у людей смартфонов в 2010 и 2014 году. Хоть Nokia и перестала поддерживать Symbian, но в 2014 эта ОС все еще будет установлена на трети мобильников. Значительно (до четверти рынка) вырастет доля андроидов, прибавит Windows Mobile. BlackBerry с iOS стагнируют.
5. CPU спешит на помощь.
   Лекция Intel'а про обратный перенос вычислений с GPU на CPU с целью оптимизации FPS в графических приложениях.
6. Постмортем King's Bounty: Legions
   Странный пост-мортем про не вышедшую игру от KranX. Игра планируется к выходу в виде беты (альфы?) летом. Первой платформой для выхода назначен facebook, то есть это будет социальная игра. Клиент будет сделан на Unity engine. Поскольку это довольно новая технология, разработчики столкнулись с некоторыми подводными камнями, из которых я запомнил сложности для дизайнеров и то, что владельцы Unity внезапно для KranX'а захотели процент от прибыли за включение кэширования. Язык программирования клиента - C# Mono, сервера тоже на С# с использованием Photon Socket Server.
7. Архитектура и процессы разработки серверной части Prime World.
   Судя по зоопарку языков программирования, упомянутых докладчиком, поддерживать это будет очень сложно. Это сложно сделанная социальная игра, в которой имеются разные части - мирная (для девочек) и dota подобная (для мальчиков и пацанок). Еще есть замок, в котором строятся разные здания. Клиент сделан тоже на Unity, язык программирования C#, сервер замка написан на python, сервер боевой части на C++, в клиенте для этой части используются C++ и Lua. Еще кое-где используется PHP. Для разных целей используются разные базы данных - упоминали MongoDB и связку Python+Jungo SQL DB для обработки отчетов об ошибках.
   Рассказали также про сбор игровых метрик (весьма ценная вещь для поддержки и оптимизации нагрузки на сервера). Для отчетов по метрикам используют Pentaho.
8. Unity pipeline в Nival Network
   Рассказывали про организацию workflow между гейм дизайнерами, разрабатывающими 3D модели в Maya и программистами, использующими их в Unity. Докладчик ужасно торопился рассказать все что можно, так что если кто-то в дальнейшем не выложит видео, разобраться довольно сложно. Я фотографировал слайды, но из них одних понять этот pipeline будет трудно.
9. Prime World
   Высокоуровневая лекция в философском ключе про игру Prime World. Сергей Орловский рассказывал про то, как Nival несет счастье людям :) А также показывал трейлеры игры. Слайды здесь. Самый интересный слайд:
   

   

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

   
   
   
   
10. Игры для массовой аудитории: мультиплатформенная гонка.
    Александр Лысковский из Alawar'а рассказывал об игровом бизнесе. Мораль лекции - платформы меняются, а игровая индустрия будет стоять вечно :) Слайды здесь.

Введение в eclipse

Я ни разу не java разработчик, и основным IDE для разработки для меня всю жизнь является MS Visual Studio, но всегда полезно иметь представление об альтернативах, особенно таких крупных, как Eclipse. Посмотрел сегодня вечером видео-лекцию с введением в Eclipse на сайте intuit'а:

http://www.intuit.ru/department/se/useclipse/1/

Дальше там идут еще несколько лекций с подробностями.

Список open source игр.

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

В принципе, должно быть полезно для того, чтобы учиться писать программы в команде. Всё равно в одиночку сейчас ничего серьёзного не напишешь, а так и fun и польза. Посмотрел тут на днях исходники одной open source игры в процессе разработки (в том списке она ещё отсутсвует) - FreeOrion - по мотивам Master of Orion. Она еще до версии 1.0 не добралась, но написано уже порядочно. Пишут на C++ и Python, используют Boost, OGRE и еще много интересных технологий и библиотек.

Код написан в хорошем объектно-ориентированном стиле, при поверхностном осмотре замечены boost::graph (библиотека для работы с графами - для моделирования вселенной, в которой каждая звездная система - вершина графа), boost::statechart (конечный автомат - для переходов между разными состояниями игры), boost::python, boost::shared_ptr, а также обильное использование STL. Так что можно просто посмотреть, как надо писать.

Я думаю, что и в других достаточно давно существующих проектах, таких как Battle for Wesnoth (пошаговая стратегия в фэнтези мире), FreeCol (клон Colonization написанный на java), OpenTDD (open source клон Transport Tycoon Deluxe), UFO Alien Invasion (клон X-COM) есть чему поучиться в смысле программирования игр. У таких долгоиграющих проектов есть развитое community, wiki сайты, форумы, всегда можно получить помощь, если что-то не понятно.

P.S. Нашёл wiki, посвященную таким играм - Libregamewiki.
А так же блог на английском - freegamer.blogspot.com

Unit test framework для языка Perl

Хотя на работе я пишу в основном на 2-х языках, на C++ и Perl, идея того, что юнит тесты можно писать и для скриптов на Perl’е, а не только для C++ программ, пришла мне в голову относительно недавно. Perl не относится к числу простых в изучении языков, да и синтаксис у него такой, что можно голову сломать порою, так что автоматизированная  проверка скриптов на то, что они делают то, для чего они были написаны, в общем, не плохая идея.

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

s/((?:(?! [-_] )[\w-]+\.)+[A-Za-z][\w-]+)/”$1 “( ($addr = gethostbyname($1))?”[" . inet_ntoa($addr) . "]” : “???”)/gex;


Полез искать юнит тест фреймворк для Perl’а - нашёл несколько, но реально попробовал только один:Test::More.
Чтобы его установить на Windows, нужно проделать несколько шагов:

1. Скачать его со CPAN - Test-Simple-0.86.tar.gz.
2. Разархивировать
3. Выполнить:  perl Makefile.pl
4. Найти утититу nmake.exe (она, к примеру, в Visual Studio есть).
5. Выполнить:
   nmake
   nmake test
   nmake install

Всё, после этого этот модуль установлен, можно пользоваться, вот, скажем, пример из туториала к нему:

#!/usr/bin/perl -w

use Test::Simple tests => 8;

use Date::ICal;

$ical = Date::ICal->new( year => 1964,
month => 10,  day => 16,
hour => 16, min => 12, sec => 47,
tz => '0530' );

ok( defined $ical, 'new() returned something' );
ok( $ical->isa('Date::ICal'), "  it's the right class" );
ok( $ical->sec   == 47,       '  sec()'   );
ok( $ical->min   == 12,       '  min()'   );
ok( $ical->hour  == 16,       '  hour()'  );
ok( $ical->day   == 17,       '  day()'   );
ok( $ical->month == 10,       '  month()' );
ok( $ical->year  == 1964,     '  year()'  );

А вот что это выдаёт в результате:

1..8
ok 1 - new() returned something
ok 2 -   it's the right class
ok 3 -   sec()
ok 4 -   min()
ok 5 -   hour()
not ok 6 -   day()
#     Failed test (- at line 16)
ok 7 -   month()
ok 8 -   year()
# Looks like you failed 1 tests of 8.

Тут тестируется стандартный модуль Date::ICal - проверяется, что этот объект создаётся и правильно инициализируется. Для тестирования тут используется Test::Simple - упрощенная версия Test::More, которая также входит в поставку. Test::More содержит порядка 15 тестовых примитивов, типа is, ok, like и др, при помощи которых можно проверять в основном равенства/неравенства, При помощи like, в частности, можно тестировать регулярные выражения.

Boost на русском

Я уже писал как сложно найти русскую документацию по библиотекам boost для c++. Для удобства я решил собрать всё краткие введения в различные библиотеки этого пакета на русском, найденные в рунете, которые показались мне более-менее полезными, чтобы получить общее представление о конкретной библиотеке. Дальнейшее изучение возможностей этих библиотек всё равно требует чтения документации на английском.
Итак:

• Boost Smart pointers. Умные указатели, Boost::Shared_ptr, Boost::Weak_ptr, Boost::Intrusive_ptr.
• Boost::Multi_index - улучшенный вариант контейнеров STL.
• Boost::Spirit - библиотека для создания парсеров. Пример использования Spirit 2.
• Boost::Regex - использование регулярных выражений в С++. Ещё одно введение в библиотеку - Boost это просто. Часть 1. Boost.Regex на хабре.
  
• Boost::Xpressive - альтернатива Boost::Regex. Также работа с регулярными выражениями. Это описание и 4 предыдущих найдены на блоге Alno’s Blog: C++, Java и Rails
• Boost::any - обобщенный контейнер, позволяющий хранить разнородные данные в одном и том же объекте.
• Boost::Asio - для создания кроссплатформенного кода для работы с сетью. Это из блога Alex Ott’а. Еще нашёл перевод туториала по boost::asio
• Boost::threads - библиотека для работы с потоками. Это перевод статьи первого автора этой библиотеки Уильяма Кемпфа в виде PDF. Статья старая, 2002 г, с тех пор библиотека была почти полностью переписана, хотя внешние интерфейсы изменились не сильно, так что общее представление из статьи получить всё ещё можно. 
• Boost.DateTime - Библиотека по работе со временем.
• На сайте sources.ru выложена кое-какая документация по библиотекам: smart_ptr, bind (работа с функторами и предикатами в алгоритмах), function (работа с указателями на функции), signal (для реализации паттернов «Команда» или «Действие» из книги банды четырёх), lexical_cast(преобразование любых типов в строки и из строк в любой тип).
• Ещё несколько достаточно кривых введений в библиотеки boost есть на сайте solarix.ru. В частности кое-что про lexical_cast, format (форматирование строк, замена printf), regex(регулярные выражения), tokenizer (разбор строк на лексемы), и еще несколько. Но перевод ужасный. Правда есть примеры, из которых кое-что можно понять.
• В википедии есть примеры по библиотекам uBLAS (линейная алгебра для матриц и векоров),random (генерация псевдослучайных чисел), Spirit (про него выше уже есть ссылка, в которой всё расписано более подробно), Regex, Graph (алгоритмы на графах).
• И наконец мой собственный перевод документации Boost::test для юнит тестирования .

Вот пока всё, что я нашёл. Найду ещё что-то, добавлю.

Интересный сервис вопросов и ответов для программистов

Обнаружил недавно новый англоязычный стартап - сервис вопросов и ответов для программистов StackOverflow. Напоминает по структуре какой-нибудь digg или reddit, только создан исключительно для программистов. Сервис продвигают несколько западных top-IT блогов, таких как Joel on Software и Coding Horror, у каждого из которых количество подписчиков в районе десятков тысяч. Так что быстрый старт стартапу я думаю обеспечен.

Идея такая: каждый вопрос на сайте подобен статье в Википедии на какую-то узкую тему. Дубликаты удаляются или перенаправляются на оригинальный вопрос. Люди отвечают на вопрос, этот ответ оценивают читатели, ставят + или -. В итоге лучшие ответы всплывают к началу страницы, худшие тонут. Кроме того, люди, заработавшие на сайте репутацию (аналог кармы на хабрахабре) могут редактировать вопросы и ответы - цель то в конце концов получить хорошую информацию на правильно поставленный вопрос.
Кроме обычного поиска есть система тэгов - тоже полезная вещь, иногда достаточно просто почитать вопросы и ответы по какому-нибудь отдельному тэгу, чтобы найти ответ на свой ещё не заданный вопрос.



Примеры вопросов и ответов:

• What do you use to keep notes as a developer?
• What is the single most effective thing you did to improve your programming skills?
• What are the best programming and development related Blogs?
• How to find header dependencies for large scale projects on linux
• How do you detect/avoid Memory leaks in your (Unmanaged) code?

Unit testing для языка програмирования C++

Новые браузеры и web 2.0 сервисы - это конечно хорошо, но что то давно я не писал чего-нибудь жостко программистского… А между тем зря, поскольку, как известно, учить кого-то чему-то - это лучший способ научиться этому самому.

Решил я немного заняться  самообразованием в области методологии разработки ПО, в частности, разобраться с инструментами для юнит-тестирования программ на С++. Как известно, чтобы получить качественную программу её нужно хорошо протестировать, а для этого нужно разбираться в её структуре. А это сложно сделать постороннему тестеру. Проще и быстрее всего если тесты для разрабатываемой программы будут создавать сами разработчики параллельно (на самом деле лучше даже перед) с написанием кода .

Подход этот получил распространение в рамках методики "экстремального программирования" (одна из основных вещей для этой методики - как раз test driven development, "разработка через тестирование"). Согласно этому подходу разработчики перед тем как написать или изменить какую-либо функцию в программе должны написать новые тесты или исправить существующие для этой функциональности. Весь набор тестов выполняется каждый раз, когда в программе что-то изменилось. В этом случае все будут уверены, что при  внесении изменений ничего не сломают, а если сломают, то сразу же будет видно что и почему. За счёт этого экономится куча времени (отладка занимает гораздо меньше времени и сил).
Можно, разумеется, реализовывать такое тестирование вручную для каждого нового проекта. Но гораздо лучше пользоваться существующими библиотеками. Почти для каждого языка программирования существуют несколько библиотек (фреймворков) для выполнения unit test’ов. В частности, для C++ самыми популярными являются следующие:

• CPPUnit - клон JUnit, фреймворка для юнит тестирования на java. Вкратце ознакомится с этим фреймворком можно например тут (на английском, скриншоты и примеры использования) или тут(русский язык!).
• Boost::test. Boost - это вообще-то коллекция независимых библиотек (их несколько десятков) для самых разных вещей - многопоточности, регулярных выражений, умных указателей, работы с графами и прочее и прочее и прочее. Многое из этой библиотеки должно войти в следующий стандарт C++ (известный как c++0x или с++09). Пишется она разными продвинутыми в c++ чуваками, многие из которых принимали участие в разработке STL (стандартной библиотеки шаблонов). Boost::test соответственно библиотека с фреймворком для unit tests. Примеры использования - например здесь.
• TUT - маленький но ужасно гордый портабельный фреймворк для unit test’ов.  Состоит из одного заголовочного файла.

Существует ещё много подобных библиотек, с более полным списком можно ознакомиться например в википедии.

Процесс разработки программного обеспечения

На моей предыдущей работе был очень детализированный процесс внесения изменений в код, никто не мог просто исправить свой или чужой баг и внести изменения в код. Нужно было следовать определённому процессу, а именно создать в специальной базе данных CR - change request, в котором описать проблему, методы воспроизведения бага, версию ПО, на котором баг воспроизводится и т.п. Затем, после того, как этот CR просмотрит специально обученный человек, который принимает решение, стоит ли овчинка выделки, надо эту ошибку исправлять или нет, а если надо, то с какой срочностью, CR назначался на определённого человека, который уже должен исправить эту ошибку. Этот человек может быть, а может и не быть тот, кто создал описание этого бага.

Далее, если эту CR назначили на тебя, ты исправляешь баг, затем, когда ты уверен, что всё сделал, перед тем как вносить эти изменения в общее хранилище кода (в систему контроля версий ) назначаетсяформальная инспекция, на которую ты обязан позвать нескольких человек, как правило 2-3-х, обычно своих ближайших коллег, чтобы они просмотрели твои изменения с помощью Diff-tool'а (конкретно там использовался Araxis Merge, хотя вообще таких программ много, в том числе неплохой бесплатныйWinMerge, которым я пользуюсь в настоящий момент). Это вообще-то весьма полезная практика, обычно другие люди видят в твоём коде то, на что у тебя уже замылен взгляд. По результатам инспекции в описание CR вносятся все найденные ошибки, недочёты, проблемы и т.д, найденные в её ходе, причём если их 0, то есть ничего не найдено, то считается, что инспекция проведена некачественно, так что для всех лучше, если хоть что-нибудь найдут и опишут. Дальше разработчик проводит работу над ошибками, правит свои изменения, и процесс повторяется, в случае серьёзных изменений назначает новую инспекцию.

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

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