2 reasons to avoid GWT

Hi guys,

Say your role involves dealing with UI technologies and part of it, naturally, is deciding which technology fits your project best so you've probably came across the big debate of Flash/Flex vs. GWT.
Although the two can live happily together without stepping on each other's toes sometimes the project dictates using one exclusively.
Both technologies mentioned above have their pitfalls, but allow me to focus on GWT and hand you 2 good reasons why you should avoid it :)

The first reason is cross-browsers compatibility:
Well - that's a complete bullshit, and if you've been messing with HTML/JS/CSS long enough you know it. GWT only claims to be fully browser compatible but the reality shows different. Gecko, Trident,  Webkit and other browsers engines interpreter JavaScript differently. It is a fact. There is no one standard there. Read it again - it is a fact!
GWT claims it can compile for each browser permutation, but reality shows that it's simply not working on all browsers the same way.  Forget my bad experience with it - let's rely on logic and ask, can the GWT team guarantee that they have covered all aspects of JavaScript for each JS interpreter engine? All of it? Can they? Come on...
Hold on, you know what? let's say that GWT, at it's core, is browser compatible. Does anyone use GWT alone for building RIA's? I mean, the framework don't have half of the controls needed for it yet. So what do you do? You rely on 3rd parties such as Smart Client. Now, did anyone guaranteed that Smart Client is a full browser compatible? Let me help you - it's not. How about blending IE's quirks-mode into the dance? Oh, now you're dancing, mate...
So when people tell you that GWT is browser compatible, you can tell them that you will believe it when you see a full RIA application running on IE, FF, Chrome, Safari, Opera the same way.

The second reason is memory profiling (especially on IE):
While Firefox has it's amazing Firebug (got to admit it, it's pretty amazing) IE is lacking a good developer tools, at least on IE8, which doesn't have memory profiling for it's developer tool, and for a good reason, it seems, since IE is probably the worst option to run JS on, memory-wise. Modules that run smoothly on FF or Chrome, are jammed on IE, generating an embarrassingly high memory foot print. IE simply doesn't know how to decouple JS from the DOM efficiently enough, leaving objects the GC can't touch.
Now, after searching the web for different memory profiling I came up with a few solutions, but when trying them, the information was so abstract, that I couldn't pinpoint the cause for the memory leak I was experiencing.
Having GWT generate JS code under the hood keeps you wondering why the hell objects are not marked for deletion when you have no real ability to track down the reason. I hate code generators. This truly sucks ass.
So you can always remind GWT evangelists that profiling GWT memory consumption is pure hell. At least on IE.

Needless to say, but Flash and Flex do not suffer from the 2 critical problems mentioned above. Flash is truly a cross browser technology, and profiling it's memory is easy.

With that said, you will probably make your own decision, but remember what you've learned here, just in case…

:)

Cheers.

More than 400 downloads for Flashmatticomponents

Hi guys,
I'm excited to announce that Flashmatticomponents, an open source project I've created, have been downloaded more than 400 times so far.

if you don't know what I'm talking about, please visit Flashmatticomponents and check it out. all the people downloading, I hope you found the package helpful.
Cheers.

Flashoo and Wix are Opening the Summer

Hi guys,
Just a short announcement that might help you open the summer a little bit better.
The Flash/Flex forum Flashoo and the web-sites builder platform company Wix are throwing a cool BBQ on the coolest rooftop in Tel-Aviv.
This event will take place at Wednesday, May 25. 6pm. You can find all the details here.

Here is the Agenda:

• 18:00 :: Gathering, Barbecue opens!
• 18:40 :: "Flashoo in Chain" project showcase - Atar Shadmi. 
• 19:00 :: HTML5 for Flash veterans - Omri Nachman.
• 19:25 :: Flash Mobile Development - Mihai Corlan. 
• 20:20 :: Advantages of writing inefficient code - Nir Yaniv. 
• 20:45 :: 3D Flash and Molehill - Michael Ivanov and Ronen Tsamir.

You can sign up here, just hurry up cause there are only 130 open spots...
And here is the post on Flashoo

See ya there (you know - the one with "Flashmattic Flashmattic" on his sticker... heheheh)
:)

OT: Guthrie Govan

מה המצב?

גיטריסטים אצלי באים בתקופות.

אם פעם זה היה קירק האמט כשהייתי צעיר מדי להבין שהוא יודע שני סולמות ואפקט אחד (ווא-ווא למי שתוהה), אם זה מאוחר יותר מרטי פרידמן המלודי, שמאז הפך לקוקסינל יפני או ג'ייסון בקר הפנומן שמאז הפך צמח. אם זה אלן הולדסוורת' שבעצם לא רוצה לנגן על הכלי ואחריה דיויד גילמור שלוקח הכל באיזי. סטיב מורס וג'ף בק... הכל תקופות.

לאחרונה החזקתי מפטרוצ'י. באמת גיטריסט ורסאטילי מאד, שיכול לנגן למעשה הכל. הכל בלי רגש, אבל הכל. הטכניקה שלו היא בהחלט מהמוצדקות, אבל כמה אפשר להקשיב לו רץ בסיקוונצות על סולמות? אז זה יותר מהר? יופי, מרגש לי את הפופיק. חלאס...

ופתאום, ככה בשיטוטי ביוטיוב אני מוצא גיטריסט-על. יש לו את הטכניקה, רק שהוא לא עובד עם קונגו על הראש שלך. יש לו את הטאצ', הוא יצירתי ברמות אחרות ובעליו הגאים של חוש מלודי נהדר. אני גם מאוד מתחבר לגישה שלו למוסיקה בכלל ולסולואים בפרט. הפירוש שהוא נותן לתוים שהוא בוחר עושה לי המון הגיון בראש, הוא פשוט מעביר בצורה חלקה את הכוונות שלו לכדי צלילים. כל מי שמנגן יודע שהדבר לא פשוט כמו שהוא נשמע.

השם הוא גאת'רי גובאן (Guthrie Govan)

תכלס? נראה כמו קיבוצניק שסיים את האבוקדו ונשאר עם הסנדלים בחזרה של המקהלה. שיער מתולתל וזקן של נער גבעות... בחור טוב, לכל הדעות. אה, הוא גם אנגלי, אז קבלו את המבטא והגישה נטולת הפוזה האמריקאית חינם.

לא לא, אחים יקרים שלי, אין הרבה דברים שכאלו. אני ממליץ לכם בחום לבדוק מה הוא מעולל ב youTube. אני מאמין שעוד נשמע ממנו המון.

אז לתקופה הנוכחית, זהו גאת'רי שמספק את הפסקול.

שאו ברכה!

No sorting for Spark DataGrid? What the hell?

Simple test:
There are numerous examples of the new Spark DataGrid on the web, Just take one of them and put "sortable" on one of it's columns… nothing.
Looking at the SDK I see this nice comment over the "sortable" getter:

/**
* TBD
*
* @default true
*/

TBD as in To Be Decided?
Are you serious, Adobe?
Did you really take away the most important feature of the data grid?

I might be wrong here, but information on the blogs and documentation clearly suggests that Adobe chose not to implement this feature at the moment.

Disappointing to say the least.

Custom Scroll bars for MX Tree with no "white box"

Hi guys,

We ran, at work, into a styling problem which has a simple solution yet elusive.
When you try to custom an MX tree (since Spark tree is not available at the moment) you create a vertical and horizontal scroll bars, same as you would anywhere else.
Once both are present you'll notice that there is a small "white box" in the gap that both leave at the bottom-right. Now this bug is known and has a workaround when happens on any Container based control. The solution relies on the fact that there is actually a member named "whiteBox" on the Container that represents the rebellious shape. Set it's visibility to false or it's alpha to 0 and there you have it.
The trouble is that the Tree, or for the sake of the matter, the ListBase doesn't have this "whiteBox" member, so where does it come from and how do we make it go away?
Simple (and some might say, stupid) answer - the background. Just set the background color to "null" within the CSS, and no more white box. Here is a code sample:

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

   xmlns:s="library://ns.adobe.com/flex/spark"

   xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600"

   backgroundColor="0x000000">

<fx:Declarations>

<!-- Place non-visual elements (e.g., services, value objects) here -->

</fx:Declarations>

<s:layout>

<s:VerticalLayout verticalAlign="middle" horizontalAlign="center"/>

</s:layout>

<fx:Style>

@namespace s "library://ns.adobe.com/flex/spark";

@namespace mx "library://ns.adobe.com/flex/mx";

mx|List {                        

content-background-color: "null";

}

</fx:Style>

<s:Panel

width="400"

height="300">

<mx:Tree

width="100%"

height="100%"

horizontalScrollPolicy="on"

verticalScrollPolicy="on"/>

</s:Panel>

</s:Application>

Hope this helps you,

Cheers.

HTML5 Canvas Performance - should we be worried?

Here is a Tweet from Grant Skinner that surprised me, since Grant is one of the pioneers in Canvas development, having his team develop EaselJS, a framework that puts sense into the mess we call Canvas.
Grant claims that HTML5 Canvas performance is something to be worried about, as it appears to be sluggish, and I must say that from the experiments I've done with it, I've noticed that too...
Knowing Grant's work, I'm pretty sure that he had tested and benchmarked all there is (and probably still is) to back his assessment.

I, like Grant, would really like to know what Steve Jobs has to say about it.

HTML5 Context Updates :: Are you serious?

Hi guys,

So HTML5 is out there and the Canvas is one of it's big promises (aside from the fact that all that is being done so far as for samples of what can be done with it, was available, like, 10 years ago with Flash 4, but let's not let the facts confuse us).

As a technologist in spirit and a Lego-boy at heart, I jumped at the opportunity to play with the Canvas and get my hands dirty with it's bits and bytes. I guessed it would be a good idea to share my experience with it, especially from a Flasher point of view, since you have a lot of HTML-ists out there that are so excited that things move on their screen just by writing HTML and JS that are ready to claim that Flash is dead.

I'm not going into the tools and libraries that are popping up everywhere, but rather to what the technology offers in the means of rendering and controlling the graphic objects on the stage (can we call it that? Yeah, sure, why the hell not).
So it appears that each Canvas has it's own context. This context is where you draw your stuff on and is the object you render.

Let's say you want a ball to move from the left to the right. Simple enough in Flash, you create a ball, throw some motion Tween on it, and you're good to go. Not so much in HTML5 Canvas.
In HTML5 you draw the ball on the left, and each time you want the ball to move, you update it's coordinates and draw it once more. This goes on until the ball has reached it's goal position.

Now, some may say that this is what happens under the hood in the Flash Player, but the bottom line is that you have to make this "update coordinates-clean context-redraw" every time you wish something to move on your screen.

This means that if you have objects for each player in your new game, you have to implement the "update" and "redraw" methods, and moreover - call them manually (on a timer or what have you).
Does this suck? Hmmm… A bit. It's like you have a heart beat (or EnterFrame) which is not a core part of the technology, but rather a pace maker the developer needs to control.

This makes me realize that although you can draw and move stuff on HTML5, the framework is so immature in compare with Flash/Flex, that it makes the comparison a bit embarrassing.
This certainly does not mean that it's not heading the right way in full speed (given that the path has been laid before, now we only need to convert it to HTML5), but it would take some time.

I will be here, monitoring it and getting my hands dirty…
Until then… Have a good one :)

Spark ItemRenderer States Bug

Hi guys,
Here is something I found myself struggling with for an hour, and I thought I might spare you the time. In spark, when you wish to create a Spark Item Renderer, you typically create a new class that extends, obviously enough, the ItemRenderer class.
This is what I did, but I wanted more functionality to it, and implemented some states to that renderer. Which is trivial enough, some might say...
What happened is, that when hovering over the Item Renderer I've just created, the states started acting weird. Mainly changing to the initial state for no real reason.
This seemed to be a nice voodoo in the making, but after diving in a bit , I found out that what causing the trouble is the Super ItemRenderer Class itself.

Why?
It has many features, some are related to states (normal, hovered - rings a bell?). This states handling goes crashing into the state behavior I wanted so… now I have the cause.

Solution
The way to go in my situation is using the DataRenderer which is a simple Group based Class that only implements the IDataRenderer. That is exactly what I need, and thank you for sparing me all the extra Bytes for functionality I don't need, Adobe. next time, try and direct me into using it in the first place...

That's all, people.
Take care.

Flashmatticomponents has passed the 300 downloads!

Hi guys, back in the time, I published a bundle of components up on Google Code. Since then, over 300 developers have downloaded the package!
oh joy :)
I know that 300 is not that big of a number, but then again, it sure makes me proud.
if you don't know what I'm talking about, please visit Flashmatticomponents and check it out. all the people downloading, I hope you found the package helpful. Cheers.

Setting a static background for a DataGroup

Hi guys, So… this is my first post for 2011, and a technical one. How sad, huh? Giving that we have a little less than 2 years for the great galactic alignment and the end of humanity, I thought it would be a great opportunity to display some code regarding a static background for the Spark DataGroup… yeah… oh well.

This is the thin - you would like to create a single DataGroup with an Item Renderer, but have it's content (the item renderer) spread on a background that will simulate different regions in it. get it? no? ok - what I mean is to have a background with 3 colors in it. this background is static and supplies the background for the item renderer's content.
Now, you can say: "why doing it like this, and not have the item renderer define it's background colors. Having multiple ones will create the illusion of a continuous background", right? Wrong. You will have the background just where you have data.
I want the whole list to have the same background, regardless of data. The idea of having 3 different lists combined was also an option, but I rejected it as being to expensive and, well, HTML-ish :). There must be a better way, right?

So, here how it goes:

<?xml version="1.0" encoding="utf-8"?>
<s:Application
    xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/halo"
    creationComplete="application1_creationCompleteHandler(event)">
  
    <fx:Script>
        <![CDATA[
            import mx.utils.UIDUtil;
            import mx.collections.ArrayCollection;
            import mx.events.FlexEvent;
          
            [Bindable]
            private var collection : ArrayCollection;
          
            protected function application1_creationCompleteHandler(event:FlexEvent):void {
                collection = new ArrayCollection();
                collection.disableAutoUpdate();
                for ( var x:int = 0; x < 3; x++ ) {
                    collection.addItem( UIDUtil.createUID() );
                }
                collection.enableAutoUpdate();
            }
          
        ]]>
    </fx:Script>
  
    <s:layout>
        <s:VerticalLayout
            horizontalAlign="center"
            verticalAlign="middle"/>
    </s:layout>
  
  
    <s:Scroller
        width="50%"
        height="50%">  
  
        <s:Group
            width="100%"
            height="100%" >      
            <s:Group
                width="100%"
                height="100%"
                minWidth="{dataGroup.contentWidth}"
                minHeight="{dataGroup.contentHeight}">
              
          
            <s:Rect width="100%" height="100%" >          
                    <s:fill>
                        <s:SolidColor color="black"/>
                    </s:fill>
                </s:Rect>
                <s:Rect width="100%" height="50" bottom="0" >          
                    <s:fill>
                        <s:SolidColor color="0xFFFF00" />
                    </s:fill>
                </s:Rect>
                <s:Rect width="100%" height="50" top="0" >          
                    <s:fill>
                        <s:SolidColor color="0xFF0000" />
                    </s:fill>
                </s:Rect>
            </s:Group>  
              
            <s:DataGroup
                    dataProvider="{ collection }"
                    id="dataGroup"
                    width="100%"
                    height="100%">
                  
                    <s:itemRenderer>
                        <fx:Component>
                            <s:ItemRenderer width="100" height="100%" minHeight="200">
                                <s:states>
                                    <s:State name="normal" />
                                    <s:State name="hovered" />
                                </s:states>
                              
                                <s:Rect
                                    height="100%"
                                    radiusX="10"
                                    width="100"
                                    radiusY="10">
                                    <s:fill>
                                        <s:SolidColor
                                            color="#7fff7f"
                                            color.hovered="#FF6666"
                                            alpha="0.3"/>
                                    </s:fill>
                                    <s:stroke>
                                        <s:SolidColorStroke
                                            color="0x4769C4"
                                            caps="none"
                                            joints="miter"
                                            miterLimit="4"
                                            weight="1"/>
                                    </s:stroke>
                                </s:Rect>
                            </s:ItemRenderer>
                        </fx:Component>
                    </s:itemRenderer>
                  
                    <s:layout>
                        <s:HorizontalLayout
                            useVirtualLayout="true" />
                    </s:layout>
                  
                </s:DataGroup>
        </s:Group>  
    </s:Scroller>
</s:Application>

It’s based on a sample code I took from one of Adobe's demos , just to get the whole item renderer thingy fast. What you should be interested in is that the Scroller which usually wraps the DataGroup is now wrapping a Group inside of it. this Group holds 2 items: another group for the background and the DataGroup. Inside the inner Group I've created a background with Rects, nothing fancy, just for the sake of it. I wanted to maintain the background ratio even when the scrolling is on. This is pretty much it. hope it saves you some time. Cheers.

OT: YouTube "Easter Egg"

Hi guys,

I know I haven't written in a long time, but if you're familiar with this blog you know that it happens to me from time to time.
This one is about a funny little Easter egg I bumped into on YouTube. You might know it, I didn't and suspects that many don't.
I appears that when you're waiting for a movie to load, you can play Snake with the loading animation.
Simply click on the arrow key when the movie is loading and there you go - Snake.

Sure makes your waiting more pleasant.

Cheers.

Why Android Defeats iOS

Well, it’s a fact now: Android have a bigger market share in mobile OS's than Apples iOS.
Surprising? Really?
This was only a matter of time and a great business strategy by Google, that brought this new OS to the front of our smart phones and defeated Apple in the game they invented.
Why, You might ask.
As I see it, the reason is plain simple. Both OS's offer the same features, give or take. This means that the end users don't really mind what OS they have on their mobile device from the two as far as that is concerned, so now other parameters are coming into view:

First one is the hardware, where Apple offers their iPhone G4 and iPad and  Google offers Nexus one… and HTC's evo... Vodafone 845, Motorola… and SmartQ and more…
As for now, we have much more devices that support the Android OS then iOS. Google could not care less about their own Nexus One, and had no trouble stopping it's manufacture. Their goal was to simply distribute as many Android instances as possible. Mission accomplished, wouldn't you agree? I mean, it’s really nice that Steve Jobs is so excited about the numbers of iPad sales, but Google can calmly reply that each day over 100,000 Androids are being activated, and going…
But that's not the whole deal, cause you know that there are still Apple fanatics who truly love their devices, so you have people from both sides sticking to what they know. What, then, is the differentiator?

The differentiator lies with the developers for the OS's. Simple logic tells that for an OS to be attractive for people it should support rich content. Rich in content means that it should support many running environments as possible, having an open SDK and the most important - creating an easy and cheap way for developing and distributing application for it.
Again, Google comes with an open SDK, supporting the strong Java platform and of course Flash/AIR. Just download the SDK and start developing your application. If I want to develop a Flex application or an AIR application for Android I really don't have to do much.
Apple, on the other hand, seems to have set a goal to make the developing process for iOS as expensive and annoying as possible. If I want to use the Adobe Packager for iOS I firstly need to get an Apple ID by filling a form that truly takes considerable time and doesn't appear to help in any way but having Apple accumulate data on all of their developers. Once you have this ID you have to purchase a developer certificate ($100 yearly). No, guys, it does not matter if you only wish to POC the application on iOS or develop a free non-commercial apps, you gotta pay up.
Well… this was quit enough for me. I think it's a sheer Chutzpah by Apple to take money from people who wish to develop application for their OS and by that make it more atractive to end users. Why would I choose to pay money when other alternatives are available for free?

So what you have now is hundreds of developers who know that Android is widely distributed and gaining more and more users by the day. These developers also know that they can develop applications for Android for free and if the developers know these 2 simple facts, they will start developing for Android.
This is the exact scenario that took place with Apple's Mac's back in 1984 when they restricted some application vendors from coding apps for their Macs. if you restrict developers from developing for your OS, or make it expensive and annoying for them, They will simply choose the easier-faster way, the same way big software companies chose to develop for IBM and MS OS back then. The rest is history as we all know.

As a person that part of his job definition is exploring UI technologies and researching for the best technological solutions, I feel that Apple is holding me down and making it very hard for me to use their technology. If in order to create simple POC I need to register as an Apple User, purchase a developer certificate, upload my apps to iTunes just for the sake of downloading them to my mobile device… come on… I have enough to do with my time, I don't need that too.

If Steve Jobs will not wake up soon, he will be surprised to find out that his market share is slipping between his fingers. Steve didn't allow Flash Packager because he wanted it. He had no choice and the same is here. If Android is open and free, developers will go there. More developers mean more applications. More applications mean more end users. Simple math.

Only time will tell.

OT: מייק פורטנוי עוזב את דרים ת'יאטר

לא, לא, תקראו את זה שוב ותנו לזה איזו דקה לחלחל.
מי שלא מכיר את Dream Theater שלא יטרח לקרא את הפוסט הזה, ויסתפק בגושי הצואה שמגיש לו הרדיו האיזורי. בהחלט אחת הלהקות המדהימות שיש כיום, והאדם העומד בגאון מאחוריה, מניע ומזיז הוא לא אחר מהמתופף עטור הפרסים שלה - מייק פורטנוי.
אתמול הברנש הודיע כי הוא לא ממשיך עם הלהקה יותר, נוכח חילוקי דעות לגבי "הפסקה" הכרחית לטעמו. למען האמת, אני מסכים איתו. אני חושב שהלהקה התחילה לחזור על עצמה וצריכה איזה צינון קל בכדי לחזור עם חומרים מעניינים יותר, אבל שאר הלהקה לא הסכימה והחליטה להמשיך בלעדיו. אתם יכולים להקביל את זה לבחור ובחורה שיוצאים ולפתע המילה "הפסקה" עולה. וכמו שחלקנו יודעים - הפסקות יש רק בבית-ספר.
מה אני אגיד לכם... זה מבאס את התחת. בייחוד בימים כאלה, בהם המוסיקה הפופלארית היא מנגינה שמעליות מתביישות להשמיע לנוסעיהן. שלא נדבר על המטאל המתחדש שנשמע כמו גראנג' מעורבל עם שתן. דרים ת'יאטר היא אחת הלהקות שעדיין נתנו לדיסטורשיין שלהן לצאת עם כל האשכים בחוץ. חתימות הזמן מאתגרות, משקלים מוזרים, מלודיות מעוותות, וכמובן מעל להכל - תיפוף של אחד המתופפים הטובים והמשפיעים בעולם, מר פורטנוי.
אז עכשיו הוא הולך להמשיך עם כל מיני פרוייקטים צדידיים מגוכחים ודרים יעשו עוד תקליט בלעדיו - ושום דבר מהמוזכר לעיל לא יהיה הדבר האמיתי. דרים זה פורטנוי וההפך. אין מה לעשות. מי יודע? יש מצב שהתקליט החדש שלהם יהיה הנפצה חדשה, כי פורטנוי באמת כבר נשחק עד עצם, אבל... ואללא, קשה לי להאמין שמשהו טוב ייצא מזה.
גם אתם מרגישים שהמוסיקה ברחבי העולם מתחרבנת לה?

Steve Jobs has surrendered

Apple has just announced that they (actually "he") will relax the restrictions on the development tool for creating content for iOS. Read about it here.
Ok, let me translate what is written above: Steve Jobs has agreed to let Flash CS5 export flash content to an iPhone apps.
No, not good enough. Let me try again: Steve Jobs has surrendered.
Steve Jobs has surrendered not Just to Adobe but to all the vendors that can and should produce content for iPhone.
Yep… it's time to climb down that high tree, Apple, and realize the reality everyone's in. I must take my hat off in respect for Adobe in their fair and positive campaign ("we love Apple") , and hand that same old hat to Mr. Jobs to chew on. Please don't waste our time again, mate.

IntelliJ, Flex SDK 4.5 and FCSH

Hi guys,
Here is something you might find interesting if your working with FCSH, or use it to compile within IntelliJ, but first - a disclaimer: I didn't go to the bottom of this problem and I don't know what exactly causes it. I just know how to work around it in IntelliJ, so… sorry 'bout that.
I recently updated my Flex SDK version to version 4.5. as part of it, I defined the SDK on my copy of IntelliJ IDEA but after doing so it stopped compiling the sources. Actually it jammed IntelliJ completely.
So… what I did is to check if any of the configurations were changed… nop, that's not it. Second thing was to check out the IntelliJ flex compiler settings.
As you might know, IntelliJ uses the FCSH of adobe, which is a shell compiler, for compilation. I simply disabled the usage of FCSH and used the default MXMLC (I mean, why not?) and it all works well now.
Here's how you do it:
Go to IntelliJ preferences, type "flex" on the search box and you will see the Flex Compiler tab. Just change it from FCSH to parallel compilation. That's all.
Hope this help you,
Have a great week.

Cheers.

Providing GWT with the browser's locale at runtime

I think it's my first post on GWT (Google Web Kit) so bear with me, I come in peace :).
I came across a problem where I've created a localization support for a project but wanted my generated code to obtain the browser's locale (note: not the system locale) and act accordingly on runtime.
Now GWT supplies 2 formal way on setting the locale for the web page; one is with a query string on the URL request and the other is adding the metadata on the host page and set the GWT property.
Both option are not satisfying since the a simple HTML cannot access the browser locales (security issues as far as I've looked), so the web pages cannot obtain the locale. You can use GWT to fetch the locale and reload the page with the right locale concatenated to the URL, but that will cause the page to flicker… nhaaaa, not good enough.
The solution is rather simple - having the server analyze the http request and get the browser's locale from it. You don't want you page to flicker, but rather generate the metadata on the host page which holds the locale information for GWT.
Comes JSP.
Since the project runs on J2EE application server, I was able to create a simple JSP page, to be used as the host page for GWT, and have a code inside that will generate the metadata for the locale derived from the request.
Here is the code

<HTML>
<HEAD>
<meta name="gwt:property" content="locale=<%= request.getLocale()%>">
</HEAD>

<BODY>
<%
out.println("Languge:");
out.println(request.getLocale());
%>
</BODY>
</HTML>

Hope this help you guys, I spent some time searching for an elegant solution on the web but couldn't find anything specific, so there you go.
Cheers!

OT: ומחר... עוד הכבדה בחום

מזמן לא השתלחתי, ובטח שלא בשפת אימי, אבל אני חושש שהגיעה העת לתקתק מספר מילים עבור העונה המיותרת הזו, הנקראת קיץ וכמובן לסיפטום המטונף שלה הנקרא חום.
פעם מזמן, שעוד היינו זבי חוטם, מאד אהבנו את העונה המיוזעת הזו. כמובן שאז, ואני מדבר על שנות השמונים, הקיץ לא היה טאבון אנושי אלא יותר עונה חמימה עם ימי שרב בודדים. אהבנו גם את הרעיון של חופש בן-חודשיים בו רובצים כמו רד-נקס מול נילס הולגרסון, עם קרטיב לימון בשבעים אגורות. ומעבר לכך, היותי ירושלמי העניקה לי קיצים הרבה יותר נעימים, ללא לחות. מה יותר טוב?
והנה עברו השנים ואני מוצא עצמי באיזור גוש דן, שלדעת רבים עדיין נחשב כבית השחי של אלוהים, הלא היא המטרופולין המבאישה, בירת הגו'קים הנצחית וטמטמת גיל האחרי צבא - תל-אביב.
הקיץ כאן, רבותי, הוא לא עונה. הוא נמשך 12 חודשים שלפרקים יורד גשם-ערפיח, שזה סוג חדש של גשם שבא ללכלך את הרחובות ולגרום למאותגרי נשימה שכמותי לחרחר את שנתם הטרופה. הקיץ כאן הוא מכה שאלוהים חסך מפרעה פן תאבד תרבות הספינקס. ובמדור גיהנום שבע הזה, ישנם חודשיים שלמים בהם המפזר-חום של כדוה"א נשאר דולק על MAX, כשהכנפיים שלו מכוונות לשפלה שלנו. יולי-אוגוסט הם חודשים שצריך להוציא מחוץ לחוק.
מעבר לכך שבני הנוער החשופים למשעי והטיפשים להפליא פוקקים כל ספסל רחוב, החום והלחות פשוט מעבירים אותך על דעתך. כך אני מוצא עצמי מסתובב בדירתי, שפיתחה סוג חדש יכולת המורכבת מספיחת חום במשך היום ויציקתו אל פנים הבית במהלך הליל, כולי לח כמו חתיכת ג'ילדה של מוסכניק תאב בצע, עצבני כמו שרק דמויות מאנגה יכולות להביע ולא יודע איך לפתור את הכבשן בו אני חי.
אי אפשר להתרווח על כורסה, כי גם היא לחה. ואם אני אקנה ארטיק הוא יהפוך לשלולית כימית אחרי הביס הראשון. נילס מזמן לא מככב, וכל שנותר לי הוא לראות את יונית לוי מביטה בי במבט שאפילו עגל מתקשה להעלות, מדברת על מסמך הרמטכ"ל, שבנינו... מעניין לי את המקש לשמאלו של "ס".
הו אז מגיח לו מהטלוויזיה אדון מר דני דוייטש, חזאי ופיגורת-סלב, ומספר לי במתק שפתיים שמחר תחול עוד הכבדה בחום, מה שמביא אותי לחשוב, בחמסין הנוראי הזה, על מקצוע חזאות האויר, שהוא ללא ספק המקצוע הכי מיותר בעולם. מקריא מה שכל ילד בן שנתיים יכול לגגל. כן? הכבדה בחום? אחרי מחקרים הגיעו למסקנה שהקיץ הזה הוא הנוראי ביותר מאז ומעולם? לא צריך מחקרים חתיכת אמבצילים! תראו את האנשים שמתאדים בחוץ כאילו הופצצו בחמישה טונות של נאפלם. אתם כל כך חכמים שאפילו לגרף הטמפרטורות יש זקפה.
שהחזאים יעשו לי טובה, ויסתמו את הפה שלהם עד שגל החום הזה יפסק! אם כרגע אין ירידה משמעותית בחום, אני לא רוצה לשמוע או לראות, לא את דני דויטש, לא את דני רופ ולא את המתבייצת הסדרתית - שרון וקסלר. מחר הכבדה בחום בחצוצרה הימנית שלך!
אתה מדליק מזגן, והמכונה המסכנה הזו כבר לא יכולה לספק לך אויר הרים צלול כיין, וכל הזמן רצה לך בראש המחשבה שחברת החשמל המסכנה שלנו בוכה על זה שהיא לא מוסגלת לספק את הצרכים של המדינה הזעירה הזו. אולי אם הם היו מפסיקים לשרוף פחם כמו קטר במהפכה התעשייתית, ולא מאירים כל גשר-כביש מצ'וקמק כאילו היה חזיון אור-קולי במצדה, היה לנו פחות אפקט חממה ויותר חשמל, נכון דירקטור וולט?!
ועל כל אלה בא המרענן הרישמי של הקיץ - צביקה הדר ונבחרת "כוכב נולד", שמנסה ללא הצלחה להעביר שיר אחד בלי לזייף, וכל זאת עם מודולציה צפויה כמוות לקראת סופו, בעיבודו הניצחי של האדם הבנאלי ביותר בסצנת המוסיקה הישראלית - עמוס בן-דוד.
ומי מאושרים, מי? הג'וקים. וודאי שהרי בשבילם זו יריית הפתיחה של חגיגות המעוף והנחיתה בדירות. הריצה הבהולה שלהם אל מקומות המסתור מהם יגיחו באישון לילה בכדי לטמא את המטבח שלכם. כל תחלואות הארץ, הרמשים והשקצים פורחים בלהט המחורבן הזה. אתה פותח את דלת הפח השכונתי, ומגלה שהפרעת לרייב פארטי מטורף של חמש-מאות תיקנים, בעוד שגל צחנת פחים מבושלים הודף אותך לרצפה.

די!
כמה אפשר?!
לא נותר אלא לצוטט את הצב החכם מכל אדם, הלא הוא בץ מ"פרפר נחמד", ששר בדכאון:

"קיץ, קיץ תיגמר
חורף חורף בוא מהר
חם מלמטה, חם מלמעלה
חם ביום וחם בלילה"

עד גל החום הבא,
סלאמת.

Why Browsers?

I've read it somewhere that if Karl Benz was asking people at the time what would they want in terms of mobility, they would probably say "a faster horses". Why horses? Because this is what the knew at the time.
Faster horses can be "created" if you somehow breed them and mess with their genes, but what Benz did was to create a different thing altogether - the car.
The reason I'm telling you this geeky story is because I feel we're kinda behaving like those people back in those days. "In what way?" you might ask. Let me elaborate.
Big companies are asking us what do we want in terms of Internet browsing. What would enhance our experience, what will make it richer. They are asking us all they can and we answer according to what we know and understand - we want a better, faster, more interactive… browser.
Lets add to the pot the whole HTML5 saga. You've probably asked yourself why is HTML5 appears to be the future of web technologies, right? No? ok, anyway, the main reason for people to believe that HTML5 will rule the future of the web is that it will make our browsing experience better, faster and more interactive and it will be a standard for all the… browsers.
Again, browsers.
Here is a thought - given that the browsers are the standard for web browsing today, do they all interpret JS the same way? CSS in the same way? HTML? The answer is no. so what kind of a standard is it?
The W3C is setting up the standard for the web but can't really enforce their standard to be fully respected with no differences among the browsers on the market. Cause eventually it all comes to whether your browser supports it or not. That's all.
But if we're putting HTML to the side for a sec, let me ask you this - don't you feel a bit caught in the past when writing an HTML tag? No really… I mean, Body tag again? Header? This must be extra painful for the Flashers/Flexers among you guys, don't you feel like going ten years back in time? Do you feel that writing ASP,JSP is writing in biblical glyphs?  Well, I do.
So we're coming to the question that hangs on the top of this post. Why browsers? Is that the way we should be consuming our web content in 2010? I may be naive but I don't think so.
I think that HTML on all it's variations had it's time and it is high time we moved into something that fits our web needs better.
I don't have the answers to what can be the "car" for us horse riders, but I feel that our horses don't do the job anymore. We need more speed, more interaction, more abilities, more.
HTML5 is a faster horse, but still - a horse. It is not the answer. As long as it relies on that same old engine, our web experiences will never go past and meet our needs, until the web Benz will come and create something that will blow our minds out into thinking - how the hell we didn't think of it until now?! I will even go as far as saying that having us depend on HTML is kind of having humanity depend on Oil. We all know that there are many far better alternatives out there but somehow, we chose (do we?) not to use them. I'm thinking to myself, maybe it's the same as in with the Oil, where global corporation prevent us from using a better solutions for their own reasons and interests. Luckily, the web is not as rigid as the global energy consortium, right?... I sure hope so.
Something to think about...

Cheers.

Is this the time for a security flop, Adobe?

Adobe just recently published that it found a critical (as Adobe claims) security issue regarding Flash Player and Acrobat reader and what can be a better time for this new findings, just after Steve Jobs claimed that Adobe's Flash is not secured enough in that long "mail" he wrote the world.
I mean… come on guys, I can't even find the right metaphor to describe how pathetic this whole matter makes you look like, Adobe. No really, if someone had asked me I would say the Jobs has people inside the Flash Player team, cause it sure feels like there couldn't be a more horrific timing than this.
I think that the people responsible for this security breach should be held responsible for making Adobe appear to the world as an amateur software company. Steve Jobs can now easily say "ha! Told ya!" and the man would be right.
I write these words with pain, guys. I love Adobe but I don't think the love will save the day here.
I know that this breach has workarounds, but let me tell you this Adobe - telling your customers to download a Beta version of the Player is unacceptable. Work day and night, eat, dream, breathe the solution for this matter as fast as humanly can, cause guys… you can't afford to shake the boat, now that the whole RIA world is examining you with a fine lens microscope.

Simply can't.