Kerner wants "One Brush to Rule Them All" and you should, too!

Matt Kerner popped up on my IM client with a long, expletive-laden rant (and he's actively religious, so I started paying attention immediately) about brushes in Fireworks CS3. It seems that he has a workflow issue with Fireworks that involves him moving from Photoshop and back to Fireworks all because he needed to use a specific brush that isn't available to him in Fireworks.

Wow. Who knew that is so simple as a *.abr file could effect someone's sanity. So much so, Kerner made a logo. So much so, he made t-shirts available.

If this was Flex or the Flash Player, I'd be suggesting that you go vote on the issue. Since we don't have that available, if you would find it useful for brush files be easily transferred between Photoshop, Illustrator, Fireworks, Flash, In Design, and After Effect, leave a comment here and I will make sure that Adobe hears you.

One Brush to Rule Them All

 

Flex Builder: Vote For Templates! (Retracting My "Snippets" Recommendation)

Earlier this week I wrote a paragraph about the merits of adding the Snippets view into Flex Builder. I would like to retract that statement and apologize to anyone who followed my advice.

You see, my experience with snippet-like features was with the Flash Development Tool (FDT) plug-in for Eclipse. FDT does not function like the Snippets that I was recommended. In fact, the plug-in I recommended is basically unusable and could be considered harmful.

With FDT, as I recall, you would create your templates in a basic text field then name and save them. When you needed that "snippet" of text, you'd type the name and hit a specific key combination and the "snippet" would appear, replacing the name that you typed. If your "snippet" had variables, dynamically places in the "snippet" to type text, your cursor would appear immediately in that space and as you typed, every place that that variable appeared would update. Ultimately, it came down to you taking the time to create the right kinds of templates for you to really reduce your coding time and effort. Pretty nice, huh? Check out the JSEclipse templates. They use this method of creating snippets.

I assumed that Snippets, at least the plug-in that I was re-recommending via another blog's post, operated in the same manner. But no, woefully not. It's a usablility nightmare. DO NOT USE IT. I'd give you more details but it would be a waste of time — it's that bad.

So, here I go again: let's bring true coding templates to Flex Builder! It's issue FB-11842 in the Flex Bug and Issue Management System (log in required, but worth the time). Please vote for this feature. It may actually save you a week-end or two a year. Think about that.

 

Vote for Flex Builder Source Formatting (or Pedro)

I was reading a blog entry on Flex Builder Enhancements at InsideRIA last night and thought that I would bump the entry and my comment up to the surface for more exposure. RJ Owen's article laments features that are available from the Java Developer Kit and not a part of the Eclipse project itself, thus not immediately available for Flex Builder users. He cites useful features like "TODO", Snippets, Mylyn integration, and a fix to the Open Resource menu bug (something I had never run into). The article also links to where you can acquire these enhancements. All of these features are worthy of mentioning to my team here at Roundbox Global.

Snippets was one of t ne features that I was used to using in Flash Development Tool (FDT) back when I was doing Flash development on a regular basis. This feature allows developers to use templates to help speed up common coding tasks. If you want to be able to have code created for you via Snippets, you first create the template, then in your code type the string associated with the template and "bam" the code is there. All you need to do then is tab through the template variables you set up and enter the data you need. OK, so, it isn't that simple, but once you set it up and get it into your workflow it's powerful.

The comments for the article featured a few people fired up about the lack of source formatting. I mention the lack of this feature privately a while back and could never raise anyone's temperature. But someone else had thought enough about the feature to have entered a bug into the Flex Bug and Issue Management System over at Adobe. The issue, FB-8297, deserves the attention of anyone who wants source formatting in Flex Builder. At this time, the issue has 22 votes but I now feel certain that more people are interested than that.

Although FB-8297 is listed as a "Minor Enhancement", I am certain that Adobe's engineers will look at this issue as more than minor because it isn't just formatting ActionScript code similar to how Java code is structured; this task will require ActionScript, MXML and ActionScript+MXML all to be formatted by Flex Builder, something that is more than what the JDK is able to do. In the issue's comments, I've added some further enhancements to the issue — like making sure the "x" comes before "y" in the MXML which is something that drives me nuts during code reviews.

If you want this feature, vote for it.

 

Good News/Bad News: I'm Speaking at 360Flex San Jose

I was notified last night by 360Flex's Tom and John that I will be speaking at their next conference being held in San Jose, California on August 18-20. I submitted several topics to speak on, and they decided that my internationalization (I18N) topic was the one that they wanted me to speak about. I18N actually stands for Internationalization - "where 18 stands for the number of letters between the i and the n in internationalization" - Wikipedia. When I originally suggested the topic to Tom via instant message, he responded "I18N?", so the session is titled "I18N: Tom Ortega Doesn't Know It, But You Should ;-)." See the full schedule here.

Now for the bad news: I am in the last session of the conference. And I am up against Ryan Stewart's "Synchronization with AIR and LiveCycle DS." I mean seriously, Tom and John. Where is the love?

I'll be blogging about the progress I am making with this presentation, although I have already made quite a bit of progress with the presentation because I am currently using it with two projects and was putting together training for Roundbox Global's Interactive Engineering team on the subject.

Again, thanks to the 360Flex team for accepting my submission!

 

CHI Atlanta Tonight: "How to Use Psychology to Influence Online Behavior"

I know it is last minute, but if you'd like to see Dr. Melissa Read speak on "How to Use Psychology to Influence Online Behavior" at tonight's CHI Atlanta event, you should drop by Roundbox Global tonight.

Here are the details, but I have to warn you that CHI Atlanta charges $10 at the door for non-members. And, no, just because it's at Roundbox doesn't mean I can slip you in the back door.

Come by and learn something. There are currently 50 people who have registered, so it won't be a small crowd. And it's a good crowd to know if you are an Internet professional! And you will actually receive a lot more than $10 worth of knowledge!

 

Adobe Tells Me That My Code Sucks!

Adobe Tells Me That My Code Sucks!

Ah, bad habits. We all have them. In our lives and in our code. We let things slide. We don't clean up after ourselves. We assume that things are correct just because they work.

Well, not any more. Thanks to the heads up from Adrian Parr (I hate you for this, Adrian! I could have remained ignorantly blissful), Adobe has put us all on notice; Adobe has finally published Flex SDK coding conventions and best practices as part of their Open Source Flex initiative. I say "finally" because I believe that this is the very first time the mothership has begun setting some standards and coding Flex. Sure, there have been conference sessions and blog posts about this subject, but not this in-depth nor as specific.

Reading through the first few screens of this unfinished document I am already seeing things that I am doing incorrectly, according to this guide. Although I am quite certain that this guide is intended to standardize coding expectations for developers contributing to the Flex SDK, I am planning to begin following Adobe's advice more ridgedly in my own code in the future. In fact, I am recommending that this document be part of a guide for standard practices at my workplace. It makes a lot sense for me to make this recommendation because, ultimately, this guide is geared towards making it possible for large groups to code by one standard.

My worst habit? See the section labeled "Miscellaneous nomenclature." Ugh.

Which bad habits do you hate seeing from your team's code?

 

BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.