[Via]

• optimizing
• debugging
• testing

Many of you probably think that optimizing JavaScript is mostly about minifying the code thus keeping code size small and load times short. Minifying is a big part of optimizing cross-compiled ActionScript but there is also a little bit more to it.

Picking the right Optimizer

There are many code minifiers out there but I think everybody will agree with me when I say that  Google’s Closure Compiler is the best. The Closure Compiler offers three different optimization modes and it is worth studying what does what:

• WHITESPACE_ONLY
• SIMPLE_OPTIMIZATIONS
• ADVANCED_OPTIMIZATIONS

SIMPLE_OPTIMIZATIONS is the default and it always works. What you want is ADVANCED_OPTIMIZATIONS. But here is the thing: Google does not guarantee you that your optimized code will always run after optimizing with ADVANCED_OPTIMIZATIONS. In order to successfully optimize with ADVANCED_OPTIMIZATIONS you need to follow a list of rules that you should perhaps follow anyways.

Ninja in, Turtle out

For example calling member functions by name is a no-no for ADVANCED_OPTIMIZATIONS:

// ActionScript
var sprite : Sprite = new Sprite();
var width : Number = sprite["width"].apply(sprite,[]);

Who would do that kind of stuff? I guess, you can call them ActionScript Ninjas, but you will also find this kind of style in Adobe’s Flex libraries. I don’t recommend this coding style and it will for sure limit your optimization options to SIMPLE_OPTIMIZATIONS and  WHITESPACE_ONLY. In general trying to write “cute” ActionScript code will almost always backfire. Either your cross-compiler will misinterpret what you want to do, or the Closure compiler will generate optimized code that does not run. Trust me: reality will bend every ActionScript Ninja. You will be faced with the choice of being right (“This is allowed in ActionScript!”) and being fast (“Hmm, I like 60 fps!”). You pick!

Just to give you an idea what ADVANCED_MODE is capable of if you don’t feed it ninja code: A year ago I cross-compiled Mike Chambers’s Pew Pew game to JavaScript and recently beefed it up a little bit (by also removing some ninja parts). The uncompressed, cross-compiled JavaScript ended up being about 1.5 MB. The optimized version using ADVANCED_MODE brought the size eventually down to 116 KB. I would be willing to give up ninja-style programming for those kind of improvements!

Honey, I shrunk the code

But how? And why was Pew Pew so big to begin with (1.5 MB)? I am planning on writing a series of posts about cross-compiling Pew Pew to JavaScript shortly, but this seems the right time to explain what I think you should consider in your design of your cross-compiler. Simply put, your cross-compiler should try to support ADVANCED_MODE as best as it can. One of the  ADVANCED_MODE rules is that you have to annotate your code with type information (technically you don’t have to, but you want to as explained above):

// ActionScript
package goog
{
  class Baz
  {
    public function query(groupNum:Number, term:Object=null):void { ... }
  }
}

// JavaScript
/**
 * Queries a Baz for items.
 * @param {number} groupNum Subgroup id to query.
 * @param {string|number|null} term An itemName,
 *     or itemId, or null to search everything.
 */
goog.Baz.prototype.query = function(groupNum, term) {
  ...
};

(Source: http://code.google.com/closure/compiler/docs/js-for-compiler.html)

I am proposing that an ActionScript to JavaScript compiler should always emit all type annotations to the JavaScript code in order to enable optimizers like Google’s Closure Compiler to using those type annotations for enhanced optimizations.

Boring is beautiful

You might not always succeed with your noble plan, though. For example it is extremely difficult to determine at compile time what the set of types will be for query’s “term” parameter. So I suspect instead of:

* @param {string|number|null} term An itemName,

You will probably only be able to emit:

* @param {object|null} term

But that’s better than nothing! To me this example is just a variation of the “ninja-in, turtle out” problem. May I ask you: Do you really have to use Object as the type for “term”? How about this “less cute” version of query():

// ActionScript
package goog
{
  class Baz
  {
    public function queryByNumber(groupNum:Number, term:Number=NaN):void { ... }

    public function queryByString(groupNum:Number, term:String=null):void { ... }

  }
}

That’s right: disambiguate your API by using separate methods for string terms and number terms. I hear some ninjas protesting loudly and arguing that my chatty coding style will result in larger code. Trust me, it will not. The ADVANCED_MODE will take of it. But if you use Object and Array (instead of Vector) all over the place the Closure compiler might not be able to make any sense of your code and you will end up with large chunks of half-optimized code. Or consider this example: maybe nobody uses queryByString()? In my chatty version the closure compiler would strip out that function, which it couldn’t do so for the do-it-all-in-one query() method. In this case, I am afraid, boring is beautiful.

Connecting the dots

So far I have only been talking about strategies for minifying generated JavaScript. At this point I might have also convinced you to not worry too much about the code size of  your generated, unoptimized JavaScript. We expect it to be large and verbose, because of the extra type annotations and unused methods that the ADVANCED_MODE will hopefully take care of later.

But there is one type of optimization that you have to take care of yourself. Consider this example from a previous post:

// ActionScript:
package flash.display
{
    public class Sprite
    {
    }
}

// JavaScript:
var flash = {};
flash.display = {};
flash.display.Sprite = function() {};

Creating a Sprite should result in this generated JavaScript code:

// ActionScript:
var sprite : Sprite = new Sprite();

// JavaScript:
var sprite : Sprite = new flash.display.Sprite();

What could possibly be wrong with that translation? There is nothing wrong with it, it’s just slow. The Closure compiler will optimize the JavaScript snippet above roughly to this:

var a=new b.c.d();

Do you see the problem? You would like to get this instead, don’t you?

var a=new b();

With our current implementation of the cross-compiler using too many packages and classes results in code that unnecessarily dereferences object parts where the parts will be optimized but not the expression as a whole. Bummer. Here is my proposal to address this problem (which is unfortunately not easy to implement): Introduce a package separator constant that is a string and that defaults to “.” in debug mode. In release mode use something like “$”. What the closure compiler will receive from your cross-compiler will then look like this (without the type annotations):

// JavaScript:
var flash = {};
var flash$display = {};
var flash$display$Sprite = function() {};

var sprite : Sprite = new flash$display$Sprite();

Since “flash$display$Sprite” is one name literal the Closure compiler will now happily optimize your JavaScript to:

var a=new b();

Here are some numbers to finish up this post: cross-compiled Pew Pew with “.” as package separator yielded about 205 KB optimized JavaScript while the “$” version made the app faster (thanks to less dereferencing) and reduced the size further down to 116 KB.

——-
Full article at http://blogs.adobe.com/ADEP/2011/12/com-adobe-idp-scheduler-schedulerexception-failure-occured-during-job-recovery.html.

If you are using LiveCycle Output to generate PDF documents using XDP files as input, you may encounter the following exception and no PDF will be returned:

0000012a XMLFormAgentW E com.adobe.livecycle.formsservice.logging.FormsLogger logMessage
ALC-OUT-002-017: mid,tid: 29435,23593162.1 sev: f text: Failure to automatically determine column '8' width.
0000012a FormServerExc E com.adobe.livecycle.formsservice.logging.FormsLogger logMessage
ALC-OUT-002-013: XMLFormFactory, PAexecute failure: "(com.adobe.document.xmlform.ReturnStatus@39133913)
Failure to automatically determine column '5' width."

If you load the same XDP file in Designer ES2 and goto PDF Preview, you may notice the same message as a warning in the log, but the PDF will be correctly rendered and displayed:

Failure to automatically determine column '5' width

Reason

This exception is occurring because of a problem in the Form design.  If you have a table in your form design with, let’s say 4 columns, you should check this table to ensure you don’t have a row with more than 4 fields defined.  This can occur especially when you have created the field objects first, and then converted a whole collection of objects into a table later on.  The extra (5th) field, can exist in a 4-column table if it has a width of “0″.

Here is an sample form to demonstrate the problem: support_test

Cell5 in Row1 is the extra field causing the problem in this case.

Solution

Simply delete the extra field as it is not visible anyway due to the “0″ width.

In future LiveCycle versions we will make changes in Output to return the PDF, and only show this message as a warning in the server log.  This will match the behaviour in Designer ES2 and Forms.

어도비 오프라인 세미나에 목 마르셨던 분들께 소개해 드리는 반가운 소식!

디자이너, 개발자, 웹 표준에 관심 있는 분이라면
이번 2월 21일 ADOBE REFRESH 2012에 참여해 보시는 건 어떨까요?

이번 세미나에서는 최근 로스앤젤레스에서 열린 The Best of Adobe MAX에서 소개된
어도비 최신 솔루션을 어도비 플랫폼 이밴절리스트 Ryan Stewart,
아태지역 이밴절리스트 Paul Burnett, Michael Stoddart가 여러분들께 직접 소개할 예정입니다.

Why ADOBE REFRESH 2012?

• HTML5, CSS3, jQuery, jQuery Mobile, TypeKit, Edge, PhoneGap 등 다양한 디바이스를 위한
  웹사이트 및 애플리케이션 제작 과정 소개
• 표준 기반의 웹 및 멀티스크린 전문가의 팁과 노하우 경험
• 전세계 최대 규모의 개발자 컨퍼런스 – MAX에서 선보인 Best of Best과 함께 향후 출시될 솔루션 공개

이번 행사는 한정된 좌석으로 진행되는 유료 세미나로
조기 마감이 예상되오니 참가를 희망하시는 분은 서둘러 주세요

ADOBE REFRESH 2012 HOT LINKs

• 사전등록 : http://www.adobeconference.co.kr/refreshmax/register.asp?sdid=JPPFE 
• 세미나 자세히보기 : http://www.adobe.com/kr/special/adoberefresh2012/index.html?promoid=JPPFF
• 발표자 소개 : http://www.adobe.com/kr/special/adoberefresh2012/speaker.html?promoid=JPPFG 

-

With this being said, let’s get started!