Выступление Ивана на РИФ, статьи Жени на Хабре: 1, 2.

Плюс, мы планируем притащить туда свой мультитач-стол. На нем будет что-нибудь интересное.

В файлик bin/jvm.config нужно добавить к параметрам java.args

-Duser.language=en -Duser.region=US

Помогаю донести в массы информацию об отличной конференции.

По сложившейся традиции конференция Flash GAMM Moscow 2011 состоится за день до КРИ, 12 мая. В этом году организаторы выбрали новое место проведения – конгресс-центр “ЦМТ“ (он же WTC) и ожидают приезд представителей отечественных и зарубежных компаний в количестве более 500 человек!

Тематика Flash GAMM посвящена не только flash-играм, но и социальным, а так же мобильным играм для таких популярных платформ как iPhone, IPad и Android. Это связано с тем, что всё больше и больше flash разработчиков пробуют свои силы в мобильной разработке.

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

- разработка игр (flash, social, iPhone/iPad, Android, 3D, HTML5, портирование игр на различные платформы и пр.)
- графика и анимация (стилистика, спецэффекты, персонажная анимация и пр.)
- монетизация (способы монетизации, реклама в играх, платёжные системы и тп.)
- менеджмент (управление командами, проектами и пр.)
- издательство (социальные сети, AppleStore и др.)
- и многое другое…

Цены для участников с прошлого года не поменялись. Стандартная регистрация стоит всего 25$, а премиум 50$ при оплате билетов до 12 апреля.

Не упусти свой шанс узнать о тенденциях в сфере разработки игр и о перспективах рынка из первых рук!

Зарегистрироваться для участия, а также узнать более подробную информацию о Flash GAMM Moscow 2011 можно на официальном сайте конференции – www.flashgamm.com

Во второй раз я буду делать доклад на Flash GAMM в Москве. Поверьте, будет супер!

Кто читал старые книги по программированию помнит термины “программирование сверху вниз”, “программирование снизу вверх”, и, самое невероятное – “от центра к краям”. Удивительная особенность этих терминов в том, что они просты и понятны, но ни один нормальный человек, примеряя объяснения на себя, понимает, что так работать не может. Это модели понятные, но к реальности никак не относящиеся. Так же, как и «легенда агилистов о ватерфоле».

Действительно. Как раз тот случай, когда “в теории между теорией и практикой не должно быть различий, а на практике…”. Далее автор описывает два граничных подхода: push и pull.

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

Это первый экстремальный подход. Разработка фреймворка ради самого фреймворка. Глаз радует структура и красота кода, но часто на практике не все работает так идеально как хотелось бы. И хорошо, если до осознание этого вообще доходят.

Это у нас гордые и способные программисты. Они, бывает, называют программистов, описанных выше “архитектурными астронавтами”. Почему? Да потому, что они ерундой какой-то занимаются, когда надо просто взять и написать код. И они умеют колбасить этот код тоннами, и делать это быстро. И этот код – работает.

И еще, они обычно работают в одиночку. Либо у них весь жизненный опыт такой, либо они просто не любят работать в группах. Либо, когда они пытаются работать в группах, их гонят оттуда коллеги ссаными тряпками то у них не складывается. Ибо, для того, чтобы продуктивно писать код группой, надо хоть как-то договорится о том, каковы общие принципы устройства этого кода, а это – “архитектурная астронавтика”.

А вот такие большинство флэшеров фрилансеров. Что уж тут, сам таким был, ога.

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

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

В общем, читайте дальше.

at wonderfl

Не спрашивайте как я его нашел.