Flex и RIA блоги

Мы рады сообщить, что запустили английскую версию сайта Fuzzle CMS.

Мы потратили много времени, чтобы перевести не только основной сайт, а также документацию. Кроме того, мы стали вести блог на английском языке.

Надеемся, что благодаря этому со временем Fuzzle станет известен не только в России, но и во всем мире. Оставайтесь с нами!

Пишет flazm:

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

читать далее

Пишет flazm:

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

читать далее

Я надеюсь, вы будете приятно удивлены, узнав, что Илья Панин и Александр Гахов долго и тайно делали Flex-продукт для Flexis => Cisco Systems и сделали его. Раскрытие тайны — на Adobe Groups.

Я надеюсь, вы будете приятно удивлены, узнав, что Илья Панин и Александр Гахов долго и тайно делали Flex-продукт для Flexis => Cisco Systems и сделали его. Раскрытие тайны — на Adobe Groups.

Пишет Валерия Маллаева, организатор конференции Flash GAMM:

Спешу сообщить, что третья конференция разработчиков flash-игр Flash GAMM! состоится 5-6 декабря 2009 года в Киеве. Любые ваши предложения, пожелания, заявки на доклады и прочее присылайте на flashgamm {(а)} gmail {.} com

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

Как вы помните, в прошлом году мы привязывали Flash GAMM к датам Casual Connect. В этом году даты не совпадают, но появилась мысль — провести UAFPUG в Киеве в тех же числах, т.к многие едут на СС.

Коннект будет проходить 21-23 октября (среда-пятница). Я прозвонила в GlobalLogic на предмет предоставления G-club, к сожалению в субботу 24-го там будет проходить награждение Программании, но 23 и 25 (пт и вс) помещение свободно.

В связи с чем возникает вопрос, стоит ли проводить UAFPUG и если да, то когда — в пятницу или воскресенье? И если всё таки в субботу, то где?

Пишет Валерия Маллаева, организатор конференции Flash GAMM:

Спешу сообщить, что третья конференция разработчиков flash-игр Flash GAMM! состоится 5-6 декабря 2009 года в Киеве. Любые ваши предложения, пожелания, заявки на доклады и прочее присылайте на flashgamm {(а)} gmail {.} com

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

Как вы помните, в прошлом году мы привязывали Flash GAMM к датам Casual Connect. В этом году даты не совпадают, но появилась мысль — провести UAFPUG в Киеве в тех же числах, т.к многие едут на СС.

Коннект будет проходить 21-23 октября (среда-пятница). Я прозвонила в GlobalLogic на предмет предоставления G-club, к сожалению в субботу 24-го там будет проходить награждение Программании, но 23 и 25 (пт и вс) помещение свободно.

В связи с чем возникает вопрос, стоит ли проводить UAFPUG и если да, то когда — в пятницу или воскресенье? И если всё таки в субботу, то где?

Пишет makc3d:

Всем давно известно, что SoundMixer.computeSpectrum() не рулит, когда одновременно играют несколько файлов, тем более с разных доменов. Всем также давно известно, что в 10й версии флеша появился Sound.extract(). И все давно жаловались, что метод этот сам по себе не так интересен, ибо к нему для полного счастья надо дописывать частотный анализ. Прошёл год, и мы продолжаем слышать те же жалобы от тех же лиц; а между тем всё, что нужно для их удовлетворения - google.com и часик времени, чтобы портировать FFT на AS3 с понятного нам языка. Что, собственно, я и сделал сегодня.

Объектом порта стал класс FastFourierTransform, написанный в далёком 1997ом доктором Iain A. Robin на жаве. Как и исходный класс, AS3 версия работает с абстрактным массивом чисел, и посему может быть использована не только для обработки звука, а для всего, на что способна Ваша фантазия. Демонстрацию класса в работе (совместно с Sound.extract) можно наблюдать здесь, а исходники этого swf с проектом под FD+Flex4 SDK можно взять тут.

При использовании кода в своих экспериментах ссылка на Ваш эксперимент в комментариях к этому посту обязательна

Пишет makc3d:

Всем давно известно, что SoundMixer.computeSpectrum() не рулит, когда одновременно играют несколько файлов, тем более с разных доменов. Всем также давно известно, что в 10й версии флеша появился Sound.extract(). И все давно жаловались, что метод этот сам по себе не так интересен, ибо к нему для полного счастья надо дописывать частотный анализ. Прошёл год, и мы продолжаем слышать те же жалобы от тех же лиц; а между тем всё, что нужно для их удовлетворения - google.com и часик времени, чтобы портировать FFT на AS3 с понятного нам языка. Что, собственно, я и сделал сегодня.

Объектом порта стал класс FastFourierTransform, написанный в далёком 1997ом доктором Iain A. Robin на жаве. Как и исходный класс, AS3 версия работает с абстрактным массивом чисел, и посему может быть использована не только для обработки звука, а для всего, на что способна Ваша фантазия. Демонстрацию класса в работе (совместно с Sound.extract) можно наблюдать здесь, а исходники этого swf с проектом под FD+Flex4 SDK можно взять тут.

При использовании кода в своих экспериментах ссылка на Ваш эксперимент в комментариях к этому посту обязательна

Нам часто присылают коды, чтобы мы смотрели на них и говорили, хороши ли они. Насмотревшись на разные, мы поняли, что хорошего кода очень мало. Чтобы помочь нам решить эту проблему, решено опубликовать доселе секретные Унивесальные Правила Хорошего Кода для всех времен и языков программирования. Если ваш код не соответствует на 100 процентов хотя бы одному из нижеперечисленых пунктов, то он не хорош и не нужен. Пришлите этот код нам и мы вместе его улучшим. Итак, правила хорошего кода:

1. Хороший код доставляет удовольствие.

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

1. Хорошее в работе человека с кодом

До написания кода

• Намеревающему код. Удовольствие от намерения написать хороший код огромно, измеряется годами. Хороший код не появится без намерения, а оно в свою очередь определяется предварительными контактами с другим кодом: хорошим, вдохновляющим как пример или наоборот: плохим, вредным, отталкивающим к хорошему коду, кодом. Нам жаль, если вы сталкивались с дурным кодом, но это было важно для вашего понимания. Постарастесь извлечь из этого практические, конструктивные выводы и хороший код.
• Мечтающему. Столько людей было осчастливлено мечтой о хорошем коде! Обещаниями хорошего кода! Нужно больше хорошего в мечтах и больше сдержанных обещаний.

Во время и после написания

• Пишущему код. Хороший код доставляет удовольствие пишущему его. С другой стороны, без своего пишущего хороший код просто не появится. В этом — самая рискованная часть жизни хорошего кода: чтобы он вышел хорошим, нужно, чтобы он доставил удовольствие своему кодеру еще до своего появления на свет. Для решения этой задачи необходимо, чтобы у кодера имелась в наличии голова. Голова нужна кодеру для совершения в ней предварительного кодирования, после которого должно идти кодирование непосредственное, сопровождаемое мягкими, уверенными нажатиями клавиш.
• Читающему. Крайне важно, чтобы чтение кода приносило быстрое понимание, эстетическое удовольствие и практическое применение. Чтение кода — это самое частое, что с ним происходит, и поэтому это самое главное, что может с ним произойти. Это важнее, чем слушание, созерцание и ощупывание кода, о них ниже. Читайте подробнее о подготовке кода к чтению.
• Смотрящему. Как гласит компилийская поговорка, некрасивый код не заработает, а если заработает, то нехорошо. Без комментариев.
• Слушающему. Если код нельзя положить на красивую мелодию, следует тут же выбросить его на помойку, если улучшение невозможно. Код хотя бы должен читаться на манер популярных японских куплетов, ну там "...лягушка прыгнула в воду".
• Обоняющему. Код должен хорошо пахнуть, но лучше не пахнуть вообще, так надежнее.
• Вкушающему. При чтении во время еды хороший код улучшает пищеварение и настроение. Если хороший код испечь в виде таких, знаете, печенек, то они должны помещаться во рту без откусывания и быстро таять с приятным послевкусием.
• Ощупывающему. После ощупывания кода со всех сторон должно оставаться слабое приятное покалывание в подушечках пальцев.
• Вспоминающему. "В конце девяностых видел один код, который изменил мою жизнь! А состоял он лишь из одной строки..."
• Припоминающему. "А вот в наше время код был! Намного больше, не то что тепер! Хороший код был, выпьем!..."
• Напоминающему: "Помнишь, какой ты код год назад написал, я его долго потом пытался понять да так и не понял, дебажил, да не вышло? Сейчас ты за это ответишь!" [Удар, серия ударов. Глухой стук. Удовольствие от мести (эффективно для порчи собственной кармы)].
• Критикующему: Умелое глумление над определенным кодом может доставить столько удовольствия окружающим, что некоторые коды специально пишутся для доставки удовольствия через их критику. Это т.н. поциент-код. Естественно, исправлять такой код преступно и в Компиляндии исправление поциент-кода карается 40 регулярными выражениями на Материнской Площади.

2. Хороший код по размерам эффективной части кода

• Весь. Хороший код должен доставлять удовольствие и быть приятным в целом. При удержании хорошего кода наперевес не должно ощущаться никакой разбалансировки.
• Файл. При поиске файла с хорошим кодом приятные ощущения играют первоочередную роль, идет подготовка к первому контакту с кодом. Это достигается путем присвоения файлам таких имен, которые как бы заранее объясняют, что за код они содержат, и что этот код хорош, и чем он так хорош. Желательно чтобы файл имел благозвучное имя, которое легко сообщать по телефону даже на шумной дискотеке.
• Экран. Вся видимая в любой момент часть кода должна быть безупречна настолько, чтобы не возникало необходимости ни в скроллинге, ни, конечно, просмотре другого (чужого, плохого, враждебного, нехорошего) кода.
• Строка. Отдельная строка кода должна читаться как гениальное одностишие.
• Слово. Каждое отдельное слово кода должно иметь длину больше нулевой и умещаться по ширине в размер монитора и состоять из идеальных символов.
• Символ. Индивидуальные символы кода должны быть просто безупречны. Ведь весь код состоит из них, без исключений. Важно выбрать правильный шрифт.
• Пробел. Он тоже символ, но роль его уникальна. Пробел является универсальным элементом визуального дизайна кода. Хороший код содержит пробелы разных, но строго детерминированных размеров для управления отступами в коде. Для работы с пробелами существует т.н. функция автоформатирования. Правильное использование пробельных символов упрощает чтение, что, как мы узнали выше, есть важнейшая часть жизни кода.

Данный спсико был бы неполным без своего продолжения, того самого, которое следует.

Нам часто присылают коды, чтобы мы смотрели на них и говорили, хороши ли они. Насмотревшись на разные, мы поняли, что хорошего кода очень мало. Чтобы помочь нам решить эту проблему, решено опубликовать доселе секретные Унивесальные Правила Хорошего Кода для всех времен и языков программирования. Если ваш код не соответствует на 100 процентов хотя бы одному из нижеперечисленых пунктов, то он не хорош и не нужен. Пришлите этот код нам и мы вместе его улучшим. Итак, правила хорошего кода:

1. Хороший код доставляет удовольствие.

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

1. Хорошее в работе человека с кодом

До написания кода

• Намеревающему код. Удовольствие от намерения написать хороший код огромно, измеряется годами. Хороший код не появится без намерения, а оно в свою очередь определяется предварительными контактами с другим кодом: хорошим, вдохновляющим как пример или наоборот: плохим, вредным, отталкивающим к хорошему коду, кодом. Нам жаль, если вы сталкивались с дурным кодом, но это было важно для вашего понимания. Постарастесь извлечь из этого практические, конструктивные выводы и хороший код.
• Мечтающему. Столько людей было осчастливлено мечтой о хорошем коде! Обещаниями хорошего кода! Нужно больше хорошего в мечтах и больше сдержанных обещаний.

Во время и после написания

• Пишущему код. Хороший код доставляет удовольствие пишущему его. С другой стороны, без своего пишущего хороший код просто не появится. В этом — самая рискованная часть жизни хорошего кода: чтобы он вышел хорошим, нужно, чтобы он доставил удовольствие своему кодеру еще до своего появления на свет. Для решения этой задачи необходимо, чтобы у кодера имелась в наличии голова. Голова нужна кодеру для совершения в ней предварительного кодирования, после которого должно идти кодирование непосредственное, сопровождаемое мягкими, уверенными нажатиями клавиш.
• Читающему. Крайне важно, чтобы чтение кода приносило быстрое понимание, эстетическое удовольствие и практическое применение. Чтение кода — это самое частое, что с ним происходит, и поэтому это самое главное, что может с ним произойти. Это важнее, чем слушание, созерцание и ощупывание кода, о них ниже. Читайте подробнее о подготовке кода к чтению.
• Смотрящему. Как гласит компилийская поговорка, некрасивый код не заработает, а если заработает, то нехорошо. Без комментариев.
• Слушающему. Если код нельзя положить на красивую мелодию, следует тут же выбросить его на помойку, если улучшение невозможно. Код хотя бы должен читаться на манер популярных японских куплетов, ну там "...лягушка прыгнула в воду".
• Обоняющему. Код должен хорошо пахнуть, но лучше не пахнуть вообще, так надежнее.
• Вкушающему. При чтении во время еды хороший код улучшает пищеварение и настроение. Если хороший код испечь в виде таких, знаете, печенек, то они должны помещаться во рту без откусывания и быстро таять с приятным послевкусием.
• Ощупывающему. После ощупывания кода со всех сторон должно оставаться слабое приятное покалывание в подушечках пальцев.
• Вспоминающему. "В конце девяностых видел один код, который изменил мою жизнь! А состоял он лишь из одной строки..."
• Припоминающему. "А вот в наше время код был! Намного больше, не то что тепер! Хороший код был, выпьем!..."
• Напоминающему: "Помнишь, какой ты код год назад написал, я его долго потом пытался понять да так и не понял, дебажил, да не вышло? Сейчас ты за это ответишь!" [Удар, серия ударов. Глухой стук. Удовольствие от мести (эффективно для порчи собственной кармы)].
• Критикующему: Умелое глумление над определенным кодом может доставить столько удовольствия окружающим, что некоторые коды специально пишутся для доставки удовольствия через их критику. Это т.н. поциент-код. Естественно, исправлять такой код преступно и в Компиляндии исправление поциент-кода карается 40 регулярными выражениями на Материнской Площади.

2. Хороший код по размерам эффективной части кода

• Весь. Хороший код должен доставлять удовольствие и быть приятным в целом. При удержании хорошего кода наперевес не должно ощущаться никакой разбалансировки.
• Файл. При поиске файла с хорошим кодом приятные ощущения играют первоочередную роль, идет подготовка к первому контакту с кодом. Это достигается путем присвоения файлам таких имен, которые как бы заранее объясняют, что за код они содержат, и что этот код хорош, и чем он так хорош. Желательно чтобы файл имел благозвучное имя, которое легко сообщать по телефону даже на шумной дискотеке.
• Экран. Вся видимая в любой момент часть кода должна быть безупречна настолько, чтобы не возникало необходимости ни в скроллинге, ни, конечно, просмотре другого (чужого, плохого, враждебного, нехорошего) кода.
• Строка. Отдельная строка кода должна читаться как гениальное одностишие.
• Слово. Каждое отдельное слово кода должно иметь длину больше нулевой и умещаться по ширине в размер монитора и состоять из идеальных символов.
• Символ. Индивидуальные символы кода должны быть просто безупречны. Ведь весь код состоит из них, без исключений. Важно выбрать правильный шрифт.
• Пробел. Он тоже символ, но роль его уникальна. Пробел является универсальным элементом визуального дизайна кода. Хороший код содержит пробелы разных, но строго детерминированных размеров для управления отступами в коде. Для работы с пробелами существует т.н. функция автоформатирования. Правильное использование пробельных символов упрощает чтение, что, как мы узнали выше, есть важнейшая часть жизни кода.

Данный спсико был бы неполным без своего продолжения, того самого, которое следует.

Сегодня выпустили новую версию Fuzzle CMS 2.6.1.

В основном изменения касаются исправления ошибок, связанных с введением функции «Редактировать дизайн» в предыдущей версии:

• Кнопка «Отменить» при редактировании дизайна теперь работает корректно;
• Ранее, при некоторых видах анимации блоков дизайна, появлялся скроллбар, который изменял внешний вид дизайна;
• При установлении типа прелоадера для картинок в none, теперь корректно работает функция предпросмотра.

Нововвведение одно, но зато довольно приятное: теперь в оформлении блоков можно использовать скругление углов (опция «Радиус скругления»). Как вы можете заметить, эта функциональность очень часто используется в новом сайте Fuzzle.

Ссылки на новую версию, как всегда, здесь: http://fuzzle-cms.ru/app/#/Demo

Наши резиденты в Черногории Дембицкий и Потапенко сделали подкаст, и вдруг — вы его не видели?

1. Доколе ждать флэшерам выхода первого в мире редактора кода, доказывающего их полное превосходство над мировым окружением? В подкасте за №1 ответ быть найден может.
2. Как освободить память от приложения, а личность — от перенапряжения? Подкаст за номером 2 поможет.
3. Как поставить флекс-разработчиков в более удобное положение? Вот третий подкаст, он второго дороже.
4. Как получить от работы удовлетворение, почему выбрано в Черногории офиса месторасположение? Смотри четвертый, он невозможен.

На самом деле я все перепутал, там надо смотреть каждую часть. Ребята анонсируют скорый выход редактора кода, аналогов которого не видели. В котором отменяется компиляция как ожидание. В котором... смотрите сами. Добавляю к посту новый тэг "montenegro", так как у будет больше новостей из Монтенегрии, то бишь Chernogorii.

Хороших выходных!

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

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

А с 14 по 30 сентября на стартап-портале Vator.tv проходит конкурс молодых компаний со всего мира. Главный приз — 3-х минутная презентация перед крутыми инвесторами. UMapper тоже соревнуется за первое место, и ему помогли бы ваши голоса — проголосовать за UMappwer можно здесь.

Разработчикам сервиса интересно ваше мнение о UMapper.com. Дело в том, что 14 ноября в Челябинске будет проходить встреча RAFPUG (скажу вам пока как бы по секрету). И сейчас создатели UMapper готовят доклад, где рассскажут о своих находках, сделанных при работе над этим сервисом. Пишите!

Наглядные официальные статьи по Code Behind во Flex уже есть, включая статьи о Code Behind на русском и украинском, рекомендующие этот подход новичкам во Flex. Напишем о нем еще раз, так как мы о нем толком еще не писали. Это упущение, ведь Code Behind относится к лучшим практикам!

"Code Behind" означает, что код находится за чем-то. А зачем это нужно?

Code Behind помогает стройно разделить код приложения по задачам. Код, в котором задается дизайн находится в одном классе, а код с собственно логикой работы — в другом, том самом, который "Behind".

Во Flex это выражается в том, что Actionscript находится за кодом MXML. Один из возможных (и хорошо работающих, проверенных подходов) к Code Behind реализуется с помощью т.н. Base-классов. Начнем с главного приложения проекта:

1. Для приложения создается базовый Actionscript-класс, в простейшем случае расширяющий родной флексовый класс Application:

package core
{
    public class ApplicationBase extends Application
    {
        ...
    }
}

2. Этот класс затем и используется как базовый в коде MXML-класса самого приложения:

<?xml version="1.0" encoding="utf-8"?>
<core:ApplicationBase ... >
     ...
</core:ApplicationBase>

Что мы получили: есть Actionscript-класс ApplicationBase, в котором мы контролируем MXML-приложение. То же самое мы делаем и для всех остальных MXML-компонентов нашего проекта: создаются AS-классы с именами, соответствующими шаблону ComponentNameBase, а MXML-компоненты используют эти классы как базовые — точно так же, как было показано выше для кода Application.

В таком подходе использование тэга Script в MXML-коде сводится к нулю и является, говоря упрощенно, уже плохой практикой.

Таким образом достигается четкое разделение вычислительной логики и дизайна приложения. Логика идет в Actionscript, дизайн — остается в MXML-коде.

Что такое Flash Platform Services я не знаю, но то, что Adobe тестирует что-то типа Flash App Store уже известно. Через эту платформу можно будет продавать свои Flash плюшки, ну и.... вообщем жмите на линк и читайте сами

На днях мы добавили в каталог новый виджет: Zoom Easing Button

Сам виджет представляет кнопку-картинку, которая увеличивается при наведении мыши. Однако, даже столь несложный эффект можно сделать забавным, если добавить к нему некую «физику». «Физика» заключается в том, что можно задавать функцию появления и исчезновения, благодаря чему можно сделать ощущение «резинки» (elastic) или «мячика» (bounce). Интересно, что первоначальный вариант этого виджета был без физики и смотрелся просто скучно.

Смотрите и экспериментируйте в нашем каталоге виджетов

Вы редактируете код в Eclipse / Flash / Flex Builder и хотите быстро найти в структуре проекта файл, содержащий данный код. Это легко. Понажимайте кнопки в указанном порядке, и у вас будет для этого шорткат:

• [Ctrl+Shift+L] — заход в список шорткатов.
• [Ctrl+Shift+L] — переход к шорткат-редактору.
• [Tab] 4 раза — фокус на фильтре команд Eclipse.
• "flex n" — ввод текста фильтра, кавычки не нужны.
• [Tab] 7 раз — фокус на поле ввода шортката.
• [Ctrl+Alt+Left] — сам шорткат (можно ввести более подходящий вам).
• [Tab] 1 раз — выход из поля ввода шортката.
• [Enter] — подтверждение и закрытие шорткат-редактора.

Теперь у вас есть новое сочетание клавиш: [Ctrl + Alt + Left]. Используйте его для быстрого перехода из редактора кода прямо на файл, код которого редактируете. Он находится, отображается и фокусируется в дереве каталогов автоматически. Чтобы вернуться в редактор кода, нажмите F12.

Unused shortcut has been found

Smoke test — это, как вы наверняка уже знаете, быстрое и грубое тестирование кода сразу после внесения в него правок. Обычно этот тест производится, чтобы определить, выжил ли продукт после свежей переделки, и стоит ли тестировать его глубже. Оказывается, этот термин пришел в программирование из реальной жизни. По поводу происхождения выражения "smoke test" Википедия говорит следующее:

1. Печники после сборки / починки печи смотрели, не идет ли дым из щелей, т.е. не убъет ли эта печь ее юзера.
2. Радиолюбитель, спаяв / пофиксив схему, включает ее в сеть и смотрит, не дымится ли. Отсюда и название "Smoke test" — т.е. тест на дымность продукта.

Smoke test classics

А я-то всю дорогу думал иначе: что этот термин возник уже в разработке ПО и связан с курением. Мол, делаем фикс в коде, запускаем юнит-тесты и идем курить. Возвращаемся с перекура и смотрим, не красны ли наши тесты от критикал багов, делаем выводы и т.п.

Теперь я думаю, что правда была где-то посередине

Smoke test — это, как вы наверняка уже знаете, быстрое и грубое тестирование кода сразу после внесения в него правок. Обычно этот тест производится, чтобы определить, выжил ли продукт после свежей переделки, и стоит ли тестировать его глубже. Оказывается, этот термин пришел в программирование из реальной жизни. По поводу происхождения выражения "smoke test" Википедия говорит следующее:

1. Печники после сборки / починки печи смотрели, не идет ли дым из щелей, т.е. не убъет ли эта печь ее юзера.
2. Радиолюбитель, спаяв / пофиксив схему, включает ее в сеть и смотрит, не дымится ли. Отсюда и название "Smoke test" — т.е. тест на дымность продукта.

Smoke test classics

А я-то всю дорогу думал иначе: что этот термин возник уже в разработке ПО и связан с курением. Мол, делаем фикс в коде, запускаем юнит-тесты и идем курить. Возвращаемся с перекура и смотрим, не красны ли наши тесты от критикал багов, делаем выводы и т.п.

Теперь я думаю, что правда была где-то посередине

Для тех, кто уже давно присматривается к Fuzzle CMS, как к инструменту разработки сайтов, но все еще не решается попробовать:

В течении ближайшей недели (13−20 сентября) мы предоставляем скидку в 90% на базовую версию Fuzzle CMS — т.е. она обойдется вам всего в 1850 р.!

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

Если вы еще не до конца уверены, подходит ли система для вашего сайта — мы предоставляем: тестовую версию с лицензией неограниченного срока действия, демо-сайт в интернете, 10-дневную лицензию под абсолютно любой домен (все это здесь)

Собственный проект. Вы хотели бы сделать на Fuzzle CMS небольшой проект «для себя», чтобы оценить возможности этой системы? Мы можем пойти вам навстречу, и выдать в рамках партнерской программы бесплатную лицензию. Свяжитесь с нами для обсуждения деталей.

Упоминания об акции:

• На Хабрахабре

В Flash Builder появилась созможность генерации геттера/сеттера для переменной.

Адоб просто бъет все рекорды по “адобству” использования.

чтобы сгенерить геттер/сеттер нужно набрать объявление переменной, ее тип, наводим курсор на набраный текст и тут 2 варианта:

1. Главное меню -> Source -> Generate Getter/Setter…
2. Правой кнопкой мыши-> Source -> Generate Getter/Setter…

И появляется оно — окошко генерации:

Лично я не представляю как можно было извратить простую идею генерации небольшого кусочка кода. Вот скажите, зачем мне нужно каждый раз это окошко? Мало того что там несколько полей и галочек, так Flash Builder 4 еще ничего и не запоминает. И каждый раз мне нужно делать одни и те же действия (я предпочитаю вставлять геттеры/сеттеры прям на месте).
А еще мне нравится кнопка превью, наверное человек делавший этот функционал считает, что перед вставкой геттера/сеттера нужно хорошо настроиться, подготовиться, обдумать свое действие и только после этого его выполнить.
Лучше бы сделали темплит кода для этой процедуры (я не говорю даже о глобальном функционале).

Также после перехода на Flash Builder 4 меня подстерегла глобальная засада — изменили коди иерархию объектов в плагине билдера и мои Eclipse Monkey скрипты перестали работать(. Нужно заново изучать чего они натворили и переписывать.

Я все чаще и чаще задумывають над тем чтобы перехать на IDEA. )

Ну и в качестве бонуса:
Главное меню -> Window -> Preferences -> General -> Keys, в фильтр вбиваем Getter выбираем Generate Getter/Setter, кликаем в поле Binding и жмем свою заветную комбинацию клавиш по которой будет вызыватся окошко генерации геттера/сеттера.

Борис Внуков решил заняться haХе-рством. Убив полдня на настройку окружения haxecpp он предположил, что полезно будет описать найденные им подводные грабли этого процесса. Так появилась его первая, вступительная заметка о haXe. Приведу из нее короткую цитату:

Чтобы не заниматься пустым копипастом, я предлагаю вам прочесть остаток полезной, не лишенной юмора статьи в блоге ее автора — nanoflexer.blogspot.com.

Пожалуй, я приложу картинку

Я нашел ее случайно на ццц.НаучныйЮмор.орг:

А пока я писал этот пост, Борис опубликовал следующую часть своего знакомства с haXe.

Борис Внуков решил заняться haХе-рством. Убив полдня на настройку окружения haxecpp он предположил, что полезно будет описать найденные им подводные грабли этого процесса. Так появилась его первая, вступительная заметка о haXe. Приведу из нее короткую цитату:

Чтобы не заниматься пустым копипастом, я предлагаю вам прочесть остаток полезной, не лишенной юмора статьи в блоге ее автора — nanoflexer.blogspot.com.

Пожалуй, я приложу картинку

Я нашел ее случайно на ццц.НаучныйЮмор.орг:

А пока я писал этот пост, Борис опубликовал следующую часть своего знакомства с haXe.

Все “знают” или покрайней мере слышали, что флексовый байндинг не работает в ActionScript 3 проектах, или слышали что он работает, но при этом занимает много места. Из за этого было написано, некоторое количество велосипедов(не мной — другими людьми, если поискать то решения 3 точно можно найти).

Но стороние решения — это плохо, у нас теряется связь с flex проектами.

Года полтора назад передомной встала задача, использовать одни и теже классы в AS3 проекте и во flex проекте, а т.к. большая часть этих классов была обычными байндабл VO, то приходилось в AS3 проекте просто вырезать метатег [Bindable] или попросту делать клонов нужных VO. Благо проект был совсем небольшим и на эти неудобства можно было закрыть глаза.

На днях я таки решил заного попробовать подключить байндинг в AS3 проект, все получилось и на радость мне все оказалось очень хорошо — flexframework доработали и убрали лишние зависимости, теперь флешка с включенным байндингом занимает около 5 кб (релиз версия)!

вот простой пример кода:

package {
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.MouseEvent;

	import mx.binding.utils.BindingUtils;

	[SWF(backgroundColor="#ffffff")]
	public class DataBindingSample extends Sprite
	{
		[Bindable]
		public var stageY:Number = 0;
		[Bindable]
		public var stageX:Number = 0;

		private var circle:Sprite;

		public function DataBindingSample()
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
            stage.align = StageAlign.TOP_LEFT;

			circle = new Sprite();
			circle.graphics.beginFill(0x55aaFF,1);
			circle.graphics.drawCircle(0,0,10);
			circle.graphics.endFill();
			addChild(circle);							

			BindingUtils.bindProperty(circle,"x", this, "stageX");
			BindingUtils.bindProperty(circle,"y", this, "stageY");

			stage.addEventListener(MouseEvent.MOUSE_MOVE, changePosition);

		}

		protected function changePosition(event: MouseEvent): void
		{
			stageX = event.stageX;
			stageY = event.stageY;
		}

	}
}

Скомпилированый пример:

Всем удачного кодирования!

... а Константинер дал нам остальное. Если вам не хватило, и вы думаете, что Костя Ковалев перестал вести блог, то это ошибка. Индид, Костянтинер ведет новый блог и пишет в него много, много чаще, чем писал до этого! Он с нами, и это так хорошо. Он отвечает на комментарии, радует интересными вещами и неподдельными эмоциями.

Эту прямоту я люблю в Косте Ковалеве

Такой бы прямоты и честности побольше нам в каждом.

Новый блог Кости стал возможен также благодаря платформе под названием Juick. Сегодня Жуйк — одно из удобнейших средств быстрого информационного сообщения в формате блогов. Феномен Жуйка в том, что он использует для блоггинга открытый протокол XMPP, в прошлом Jabber. Это делает возможным чтение, постинг и комментирование прямо из вашего любимого чат-клиента: будь то миранда, пиджин, триллиан, или айЧят (выбор Кости — уважать и задуматься). Попробовав Жуйк, быстро понимаешь всю унылость Твиттера, с его жалкими 140 символами на сообщение. Но не об этом речь.

Я всего лишь хотел сказать Косте, и чтобы вы знали, что я это хотел ему сказать: будь здоров, Костя! Расти коров, пей молоко! Лети высоко! Станет медом подотчетный тебе кластер объективной действительности. Приобретет окончательную стройность архитектура твоих проявлений. Озарится светом твой небликующий монитор и твой облик в целом! И это — неизбежно.

Вот я и сказал

... а Константинер дал нам остальное. Если вам не хватило, и вы думаете, что Костя Ковалев перестал вести блог, то это ошибка. Индид, Костянтинер ведет новый блог и пишет в него много, много чаще, чем писал до этого! Он с нами, и это так хорошо. Он отвечает на комментарии, радует интересными вещами и неподдельными эмоциями.

Эту прямоту я люблю в Косте Ковалеве

Такой бы прямоты и честности побольше нам в каждом.

Новый блог Кости стал возможен также благодаря платформе под названием Juick. Сегодня Жуйк — одно из удобнейших средств быстрого информационного сообщения в формате блогов. Феномен Жуйка в том, что он использует для блоггинга открытый протокол XMPP, в прошлом Jabber. Это делает возможным чтение, постинг и комментирование прямо из вашего любимого чат-клиента: будь то миранда, пиджин, триллиан, или айЧят (выбор Кости — уважать и задуматься). Попробовав Жуйк, быстро понимаешь всю унылость Твиттера, с его жалкими 140 символами на сообщение. Но не об этом речь.

Я всего лишь хотел сказать Косте, и чтобы вы знали, что я это хотел ему сказать: будь здоров, Костя! Расти коров, пей молоко! Лети высоко! Станет медом подотчетный тебе кластер объективной действительности. Приобретет окончательную стройность архитектура твоих проявлений. Озарится светом твой небликующий монитор и твой облик в целом! И это — неизбежно.

Вот я и сказал

Удивительно: для того, чтобы перехватить все события в интерфейсе Flex-приложения, нужно написать всего одну строку кода, и она весьма проста:

UIComponent.mx_internal::dispatchEventHook = myEventsHook;

Здесь myEventsHook — это метод вашего приложения, перехватывающий события. Он принимает два аргумента: само событие и объект, это событие породивший, так что в самом методе вы можете легко фильтровать информацию.

Еще удивительнее то, как мало об этой простой технике написано в сети. Гугл в основном находит применение к Cairngorm (снова это имя!), короткую запись на японском и занятный пост о задании поведения флекс-компонентов по умолчанию.

Обратите внимание, речь идет не обо всех событиях флекса, но именно о событиях визуальных компонентов, а точнее — всех компонентов, унаследованнх от класса UIComponent.

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

Например, посмотрим, что происходит при перемещении компонента Text из одной панели в другую:

# Move text field: 
	TextArea event: remove
Panel 1 event: childRemove
Panel 1 event: childrenChanged
Panel 2 event: childrenChanged
Panel 2 event: childAdd
	TextArea event: add
	TextArea event: htmlTextChanged
	TextArea event: textChanged
	TextArea event: valueCommit
	TextArea event: viewChanged
	TextArea event: viewChanged
Panel 1 event: widthChanged
Panel 1 event: heightChanged
Panel 1 event: resize
Panel 2 event: widthChanged
Panel 2 event: heightChanged
Panel 2 event: resize
Panel 1 event: xChanged
Panel 1 event: move
Panel 2 event: xChanged
Panel 2 event: yChanged
Panel 2 event: move
	TextArea event: updateComplete
Panel 1 event: updateComplete
Panel 2 event: updateComplete

Код, который выдает этот лог после нажатия кнопки "Move text":

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
				preinitialize="preinitializeHandler();"	>
	<mx:Script>
		<![CDATA[
			import mx.core.UIComponent;
			
			private function preinitializeHandler():void
			{
				trace("Hooking UIComponent's event dispatcher"); 
				UIComponent.mx_internal::dispatchEventHook = myEventsHook;
			}
			
			private function myEventsHook(event:Event, uiComponent:Object):void
			{
				if(uiComponent.name == "firstPanel")
				{
					trace("Panel 1 event: " + event.type );
				}
				
				if(uiComponent.name == "secondPanel")
				{
					trace("Panel 2 event: " + event.type );
				}
				
				if(uiComponent.name == "textArea")
				{
					trace("\tTextArea event: " + event.type );
				}
			}
			
			private function moveText():void
			{
				trace('##################\n# Move text field: ');
				secondPanel.addChild(textArea);
			}
		]]>
	</mx:Script>
	<mx:Panel id="firstPanel" >
		<mx:TextArea id="textArea" text="Hello world"/>
	</mx:Panel>
	<mx:Panel id="secondPanel" />
	<mx:Button label="Move text" click="moveText();" />
</mx:Application>

Наглядно и просто! А сколько бы пришлось лазить по исходникам Flex SDK, чтобы получить эту элегантную картину

Данная техника помогает оптимизировать код. Например, если задать панелям и текстовому полю из вышеприведенного кода явные размеры (width, height), то событий будет почти в два раза меньше — отпадают всякие ресайзы, ведь размеры указаны явно, и у вас есть еще один повод сделать выводы.

Удивительно: для того, чтобы перехватить все события в интерфейсе Flex-приложения, нужно написать всего одну строку кода, и она весьма проста:

UIComponent.mx_internal::dispatchEventHook = myEventsHook;

Здесь myEventsHook — это метод вашего приложения, перехватывающий события. Он принимает два аргумента: само событие и объект, это событие породивший, так что в самом методе вы можете легко фильтровать информацию.

Еще удивительнее то, как мало об этой простой технике написано в сети. Гугл в основном находит применение к Cairngorm (снова это имя!), короткую запись на японском и занятный пост о задании поведения флекс-компонентов по умолчанию.

Обратите внимание, речь идет не обо всех событиях флекса, но именно о событиях визуальных компонентов, а точнее — всех компонентов, унаследованнх от класса UIComponent.

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

Например, посмотрим, что происходит при перемещении компонента Text из одной панели в другую:

# Move text field: 
	TextArea event: remove
Panel 1 event: childRemove
Panel 1 event: childrenChanged
Panel 2 event: childrenChanged
Panel 2 event: childAdd
	TextArea event: add
	TextArea event: htmlTextChanged
	TextArea event: textChanged
	TextArea event: valueCommit
	TextArea event: viewChanged
	TextArea event: viewChanged
Panel 1 event: widthChanged
Panel 1 event: heightChanged
Panel 1 event: resize
Panel 2 event: widthChanged
Panel 2 event: heightChanged
Panel 2 event: resize
Panel 1 event: xChanged
Panel 1 event: move
Panel 2 event: xChanged
Panel 2 event: yChanged
Panel 2 event: move
	TextArea event: updateComplete
Panel 1 event: updateComplete
Panel 2 event: updateComplete

Код, который выдает этот лог после нажатия кнопки "Move text":

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
				preinitialize="preinitializeHandler();"	>
	<mx:Script>
		<![CDATA[
			import mx.core.UIComponent;
			
			private function preinitializeHandler():void
			{
				trace("Hooking UIComponent's event dispatcher"); 
				UIComponent.mx_internal::dispatchEventHook = myEventsHook;
			}
			
			private function myEventsHook(event:Event, uiComponent:Object):void
			{
				if(uiComponent.name == "firstPanel")
				{
					trace("Panel 1 event: " + event.type );
				}
				
				if(uiComponent.name == "secondPanel")
				{
					trace("Panel 2 event: " + event.type );
				}
				
				if(uiComponent.name == "textArea")
				{
					trace("\tTextArea event: " + event.type );
				}
			}
			
			private function moveText():void
			{
				trace('##################\n# Move text field: ');
				secondPanel.addChild(textArea);
			}
		]]>
	</mx:Script>
	<mx:Panel id="firstPanel" >
		<mx:TextArea id="textArea" text="Hello world"/>
	</mx:Panel>
	<mx:Panel id="secondPanel" />
	<mx:Button label="Move text" click="moveText();" />
</mx:Application>

Наглядно и просто! А сколько бы пришлось лазить по исходникам Flex SDK, чтобы получить эту элегантную картину

Данная техника помогает оптимизировать код. Например, если задать панелям и текстовому полю из вышеприведенного кода явные размеры (width, height), то событий будет почти в два раза меньше — отпадают всякие ресайзы, ведь размеры указаны явно, и у вас есть еще один повод сделать выводы.