September 20, 2009

You open, You see :: Curly Braces

Scroll down for the English translation...

מה המצב? איך עובר עליכם החג? בטוב? יופי.
אז ככה, אתם יודעים שמקום העבודה הוא אחת הזירות הטובות ביותר להעלות תהיות ומחלוקות. וכך קורה ששאלות תמימות (או לעיתים לא ממש) הופכות לדיונים סוערים, שאפשר להפיק מהם בעיקר תובנות ותשובות.
הנה משהו שקולגה שלי העלה וחשבתי שיהיה נכון (כמובן, ברשותו האדיבה) לשתף אתכם בו:
בזמנו, כל ביטוי action script בקובץ MXML היה צריך לחיות בתוך סוגריים מסולסלים, אבל מאז עברו מעט מים בנהר והסוגריים המסולסלים הם לא ממש הכרח. מתי לא? מתי שהצפי הוא עבור אובייקט, או מתודה, או אם להיות יותר מדויק כל מה אמור לייצג מחרוזת. סוגריים מסולסלים קיבלו מקום בעיקר עבור Binding, וכולנו יודעים שהן בעצם מורות לקומפיילר לייצר אקסטרה קוד שאמור לנהל את ה- Binding במקןם הנתון.
ובכל זאת, אנחנו עדיין רואים מפתחים משתמשים בסוגריים מסולסלים, כאשר הם למשל מגדירים event handlers, הו-אז נשאלת השאלה הבלתי נמנעת: האם כאשר אנחנו מגדירים event handler בתוך סוגריים מסולסלים אנחנו למעשה כופים על הקומפיילר ליצור אקסטרה קוד עבור Binding לא נחוץ בעליל?
בפשטות? לא.
למטה תוכלו למצא את קטעי הקוד המג'ונרטים (ברוך המוציא generated מן הקומפלייר), פעם אחת עם סוגריים מסולסלים ופעם בלי. כפי שאתם רואים, ההבדל הוא, באופן מפתיע, סוגריים מסולסלים. אז מעתה אתם יכולים להיות רגועים ולהרגיע את הסובבים אתכם – זה בסדר.
שנה טובה.



How’s its going?
So, you know that the working place is one of the best places to raise thoughts, wonderings and debates. And so it happen that innocent questions (or some time not that innocent) become a great argument, which sometimes you can benefit from.
Here is question that my colleague raised and I thought it would be great (with his generous permission) to share with you:
At the time, any ActionSctipt expression on an MXML file would have to be inside curly braces, but since then time has passed and the curly braces are not mandatory. You ask “when?” – Well, whenever the expression is not meant to define a String. Curly braces got the honorable rule of defining Binding (in general), and they instruct the compiler to generate extra code to handle the binding on the spot.
Still, we see developers using the curly braces when they define Event handlers, for instance. Then, one might ask, when you define an event handler inside curly braces, do you still instruct the complier to generate extra code, to no need?
Simply answered? Nop.
If you look, below, you would see the code and the generated code snippets for both using curly braces and not using them. As you can see, the only difference is, well, the curly braces. So from now on you can relax… it’s ok… it’s ok :).

Cheers.


Without curly braces


/**
* @private
**/
public function ___CurlyBraces_Application1_creationComplete(event:mx.events.FlexEvent):void
{
onCreationComplete(event)
}


With curly braces


/**
* @private
**/
public function ___CurlyBraces_Application1_creationComplete(event:mx.events.FlexEvent):void
{
{onCreationComplete(event)}
}

September 16, 2009

Flashmatticomponent direct SWC download

Scroll down for English translation...

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

יאללא ביי.


Hey guys,
If you'll read the comments on the post where I first published the Flashmatticomponents, you'll notice one that complains about not having a direct download option in the project site, for the SWC file, but rather the option to download the code and compile it locally to get the artifact.
True, yeah… The reason I did it so is because it's a lot harder to manage the versions that way, and a situation might rise, where the direct download SWC will not be as updated as the one generated by compiling the code.
In any case, it would be a good Idea to put a direct download link to the SWC, which I did. Feel free to go there and download it.

Cheers!






September 10, 2009

FlexPMD from Flex Builder

Scroll down for English translation...

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

תשמעו, אתם מריצים את זה על הפרוייקט והוא מוצא תחלואות שלא היו מביישות את סומליה. ממש ממש כלי טוב, פשוט ויעיל העוזר לייצר קוד טוב יותר, ברם (ואתם ידעתם שזה יבוא), אליה וקוץ בה.
זה מגניב שאפשר להפעיל את זה אפילו מהמטבח של גיל חובב (mvn, ant, cmd) אבל אני רוצה דרך מהירה ויעילה להפעיל את העניינים. משהו של "קליק אחד ויאללא לרפואה", משהו של "מתוך פלקס בילדר ולעסק", וזה נכון שאדובה אומרים שהם עובדים על פלאג-אין לפלקס בילדר, אבל סאחבק לא נודע בשל חיכיונו למשיחי-תוכנה החל לתור אחר פתרון.
External tools!
מה שעוללתי הוא external tool בתוך Flex Builder, שיקרא Create PMD, והוא ידע לפנות ולבצע את הפעולות, נכון למיקום הבחירה בעץ הפרוייקט. כלומר, אם תבחרו את ה root, קובץ ה- PMD יופיע שם, אם תבחרו package, הקובץ יופיע בה.
תעקבו אחר הצעדים בתחתית הפוסט (הם באנגלית, אני יודע, אבל אתם תתמודדו), ובשלוש דקות יהיה לכם כפתור שמייצר PMD בקליק אחד. בכדי לחזות בתוצאות באופן נהיר, אדובה מציעים לנו את ה viewer שלהם. כל שצריך הוא להעלות את ה- PMD אליו וחזות בזוועות הקוד.
אם יש בעיות עם ה- tool, דברו איתי :).


Hi guys,
Recently Adobe has launched a new open source project called FlexPMD. You can read all about it here, but here are the highlights:

“FlexPMD is a tool that helps to improve code quality by auditing any AS3/Flex source directory and detecting common bad practices, such as:

* Unused code (functions, variables, constants, etc.)
* Inefficient code (misuse of dynamic filters, heavy constructors, etc.)
* Over-complex code (nested loops, too many conditionals, etc.)
* Over-long code (classes, methods, etc.)
* Incorrect use of the Flex component lifecycle (commitProperties, etc.)”

Well this is multi-nice, but it seems that we need a better/quicker way to invoke it on our projects than have it on the Maven site/Ant/CMD. This is something that we need on a day-to-day, hour-to-hour basis.
So until the Flex Builder plug-in will be out (they are working on it), here is my solution, and you are all welcomed to adopt it for better coding:

STPES:

Download the “command-line” version from adobe and extract it onto your local machine.
Open Flex Builder.
On the top menu, go to Run > External Tools > Open External Tools Dialog…
Create a new External tool and call it “Create PMD”.
Fill it according to the following:
  • The Location is where the java.exe can be found
  • The Working Directory is set to a variable which is the selected resource on the project tree (the variable name is “resource_loc” and can be found on the variables list).
  • The Arguments are where the flex-pmd-command-line-1.0.RC3.jar is found, the source (“s”) and output (“o”) folders which are set to be at the same location as the Working Directory.
Ok – all you need to do now, is to select a resource on the project tree and run this tool.
After the tool has completed its work – you will see a pmd.xml file on the same folder you’ve selected on the project tree (if you don’t, refresh the tree, it’s there…).
Launch Adobe PMD viewer URL.
This is the viewer for PMD that Adobe created (If you’re really lazy, you can open the viewer directly from Flex Builder… but that's another story).
Load the file onto it and witness the HORROR :)

If you encounter any trouble with the tool, please let me know.
Cheers.



September 05, 2009

עברית או אנגלית / Hebrew or English

An English translation is available for this post...

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

It’s been a while that I’ve been walking with a small wondering cloud hanging above my head, as to keeping the Hebrew flavor of my blog. I love Hebrew, I love writing it, but there is no way you can avoid the obvious fact that this blog, being a technical blog, kinda misses its full strength when you mix the holy tongue with hi-tech terms. It’s true that I keep translating the technical posts, but still, aside from the fact that it’s a double work for me, it feels a bit overwhelming to the readers and sometimes even intimidating.
And on the other side, I truly love Hebrew.
I want to ask you, those who read the this blog - what do you think is the right direction to go? Hebrew? English? Both? Maybe a different solution?
What say you?