Personal landmark moment: My first patent: On the design of Comcast’s Fan Player

I joined Comcast four years ago, fresh out of graduate school with a Masters in Computer Engineering and a passion for the Flash programming language. Back then, Comcast was one of the rare companies that had invested heavily in Flash and getting the opportunity to develop applications in Flash that would be seen by a huge number of users was an exciting opportunity.

One of the first apps I got involved in and was my main project till about a year ago was the Fan. Originally conceived by my then boss and later friend and mentor Jeremy Landis, the Fan was a unique application. Comcast was probably one of the first companies who invested in Flash video back when it had just about come out.

History

  • When I joined, the Fan version 1, was written with all the goodness of Flash 6: code in frames, gotoAndPlays, etc etc. That was not too easy to work with.
  • The app was ported to the goodness of ActionScript2 soon after the release of Flash Player 7.
  • Version 3 of the application added some amazing redesign by our new design lead, Alfredo Silva and some amazing interaction models by Gabo (of Gabocorp fame).
  • The 3.5 version of the player introduced the ability to switch to a more conventional square view. There was a sentiment that adding a more conventional interface would lower the barrier to users actually interacting with the application more.
  • The square view was extended even further in Fan 4 which was also written from ground up in Flex 2. Porting the circular view to Flex 2 was an interesting challenge and I think we did an amazing job with Flex custom components.
  • The circular view was discontinued early this year as was the monolithic Fan application with the Comcast.net portal moving to a more conventional single-video-on-page experience.

Its kind of ironic that today the original team responsible for the Fan was awarded the patent by the United States Patent office on the design of the application. My first patent! How f-ing awesome is that !!!

The Fan was always unique if anything, and there was always the debate whether a circular interface was indeed the best to watch rectangular video. But the people loved it for sure, so much so that it even won the Flash Forward People’s Choice award in Sept 2006, and yes, that was for the circular interface. I remember a lot of stories from friends who had parents/relatives who loved the circular interface, and it was perplexing to the usability folk, after all it was clearly breaking all rules of application design. But that was where the magic was. It was different, iconic and had a long history with the Comcast customers who used it to catch up on daily news, events, gossip, etc. Heck, it was cool! Cool enough for even Philebrity to run a post titled The Only Thing Comcast Ever Contributed To The Internet: “The Fan” (Philebrity posts are not usually the most Comcast friendly).

But anyway, this is a moment to celebrate. I have one more fond memory of the Fan now, and believe me, this one is hard to forget :). Special thanks to all who went towards making the Fan a successful product, the editors, content video team, the design,dev and QA teams, etc. This was a fun ride.

Fan 1, 2

Fan 3

Fan 4

When things go wrong: Communicating error and gathering information for client side code

Having developed client side applications for the last few years in a variety of languages (Java, Flash, AIR, Javascript and recent forays into Objective C for the IPhone), its funny that some discussions appear cyclically and are discussed as though for the first time in every new project. Communicating errors in your application seems to be one of them, and I wanted to pen a few thoughts on that.

Serverside developers have it easy!
Well, no ;). But there are paradigms that have become the norm now. If something bad happens and you get a 404 or a 500 error on a webpage, its pretty likely that its been logged and if its on a major product, alarms have been raised. Client side code, especially in the languages I have worked in the last couple of years, have been less…communicative. I would like to focus on AIR and Flash here since those are the technologies I work with most often. The problem becomes more critical in AIR where you have much more things that can go wrong since you are interacting with items on the user’s machine which is not a controlled environment.

Why communicate the error?
Very few client side web apps I have worked with, including my own, have ever seemed to have handled error correctly. Most of the time, the app has been scoped with time allocated against the features and error states have never been considered. Occasionally, a developer will put in an Alert window or something similar just as a precaution (I know I have). In Flash/AIR there doesnt seem to be a good library that I can integrate into my application that encapsulates best practicess. Heck, I dont even know what the best practices are, which is what prompted me to write this post.

What would you include in the error window?
While you may want to include app specific information in the error window, I think there are a few things that make most sense:

  • An error description: What happened ? Corrupt file? Cannot connect to server? Something readable. For bonus points, can the user do anything about this, like restart the application?
  • An error code: This makes sense and if you include a support system, like a bug tracker or a 1-800 number, it would make the conversation a lot more meaningful
  • The detailed stack trace: A good paradigm I have seen here is a toggleable details state that shows/hides the detailed error stack trace, would go a long way in figuring out the source of the error
  • Extra points: email API integration, or some other way for the user to send the error description with as little pain as possible

The last point is kind of interesting, cause you might want to send more than just the stack trace of the error. You might want to set the whole application state. If you have application logging enabled, say with something like the CIM logging framework, the whole log file might be of interest. Again, the developer must ensure that he is only logging non-personal information there.

Of course there are situations when the error might cause the entire app to blow up, without giving it enough time to react to the error. Would it make sense to log and end of session event and allow users to send the application log to the server if the end of session was not successfully logged for a prior session?

Prior Art:

I started looking at some Google results for Error dialogs and crash reporters. Here are some screenshots:

First is the JXErrorPane, a Java class part of SwingX project. This seems to be the most familiar UI for reporting errors(link to API docs)

jxerrorpane

The usage is pretty simple:

try {
//do stuff.... something throws an exception in here
} catch (Exception e) {
JXErrorPane.showDialog(e);
}

A step up would be the UI from crash reporters which would perhaps be overkill for a web app, but would make a lot of sense for desktop apps, especially in the beta stages. Here is a screenshot from something called Bug Buddy.

Bug Buddy

Whats kind of interesting here is that it adds a field that allows user to add information about the context of the crash, as well as an email address that may be used to contact him or something.

The last screenshot is from an open source library called JRFeedbackProvider someone presented at the Philadelphia Cocoa Users Group.

JRFeedbackProvider. This has the features of the previous crash reporters but also adds a “request a feature” tab which is great if you are running an alpha version of your application and are looking for more than bug reports.

If you have seen any other error UI that seem to do a good job, please add a comment here.

Quick Tip: Correct folder for Unit Tests in Flash Builder 4

I really like the fact that FlexUnit is built right into Flash Builder since one of the main reasons unit testing used to fall off our radars was it was a pain setting up Flex Unit and executing scripts. However one of the things that struck me pretty weird was that Flash Builder was writing tests in the source directory. Best practices in unit testing say that the tests should be in a separate folder called tests/ which should be a sibling of the src/ folder. This lets the tests be written with the same package as the code being tested. This allows, for example, testing functions with a package level visibility.

The correct way to get this working is, when starting the project add another folder called tests for the build path. Now Flash Builder will look at both the source and the tests path when looking for .as files. To write a unit test Test Case, right click on the tests folder and click on the new Test Case option.

New folder for Unit Tests

[Update] I have filed a bug in Adobe’s ticketing system to track this issue. Please vote for it if you agree: http://bugs.adobe.com/jira/browse/FXU-50

Compiled vs interpreted languages and why I sometimes wish Actionscript was interpreted

[UPDATE] My friend, Mat pointed out that this post isnt really about compiled vs interpreted languages but rather static vs dynamically typed languages.

Its always interesting to see the conflict between developers who love and those who hate interpreted languages. It often feels like the developers’ equivalent of a generation gap, with a lot younger developers preferring interpreted languages like Ruby and Python over things like Java and C. An interesting post I read on why Web Applications Should Be Compiled which is an interested read, though a bit strongly worded against Ruby. I quote:

The whole philosophy behind Ruby is that the machine should be the servant, not the coder. This is madness. We’re engineers, and we make machines work. You use the best tool for the job to do that. You don’t choose some pretty language that “brings back the joy of coding” or equivalent hippy shit. This is analogous to hiring someone to build a house and having him tell you he’s not going to use conventional materials like wood and steel because they aren’t as fun to use as Play-doh.

The performance argument is often valid. No ruby developer can claim that it can outperform its compiled brethren, though there are signs that this could be changing, with news like JRuby outperforming Ruby C. The core reason people who love interpreted languages is that it gets the cruft out of the way, allowing developers to think more of the business problem.

So how does this debate affect me, considering most of my work is in client side languages like Javascript or Actionscript?

The last few months I have been working with Javascript and have slowly started appreciating it quite a bit. One of the reasons I wasn’t pulling my hair out with cross-browser javascript is because of the JQuery library. JQuery syntax is really nice and I love the chaining feature. For example the purpose of the following line should be pretty self evident:

$(".mydiv").width(200).height(200).bind(click, function(){ alert("I got clicked") }).css("visible", true);

The actionscript equivalent would be something like:


mySprite.width = 200;
mySprite.height = 200;
mySprite.addEventListener(Event.CLICK, function(event:Event){"I got clicked"});
mySprite.visible = true;

I hate the zig-zag i have to do to read AS3 code, so while extending OpenPyro I figured I could make my methods return the object instance back, that could be used to further set properties on the object.

So say my UIControl had a function like setSize(w:Number, h:Number):UIControl and setVisible(val:Boolean):UIControl, I could use them in chaining like:


myControl.setSize(200,200).setVisible(true);

nicer right?

But now imagine you extend UIControl to make it a button and add functions for setLabel(str:String):Button and setIcon(icon:DisplayObject):Button. Note the return types have to be Button so that I can do something like this:

myButton.setLabel("print").setIcon(printer_png_instance);

Now for the fly in the ointment: Lets try chaining this:

myButton.setLabel("print").setIcon(printer_png_instance).setSize(200,200).setVisible(true);

works fine. but

myButton.setSize(200,200).setVisible(true).setLabel("print").setIcon(printer_png_instance);

fails. Why? Because the compiler sees setVisible returning a UIControl but then trying to set the label property on that control. At runtime, the returned instance is a Button but the compiler cannot check that. The only way to do chaining would be to cast objects appropriately for the compiler but at that point, the elegance and readability of the single line is lost.

And that is the core problem. Compilers are stupid and completely depend on the return type information defined in the method signature. I could return Object datatypes for all methods but the performance hit would be pretty severe.

As I write this a new direction comes to mind. Doing $(“#mydiv”) in JQuery doesnt actually return a div but rather a jQuery wrapped set. Maybe a AS3 equivalent could be created using Actionscript 3’s Proxy class

Hmmm…stay tuned for a followup post.

Epilogue:
Returning for a bit to the previous quote chastising developers on choosing Ruby, a counterpoint can be found on why developers at Twitter chose Scala:

The other big reason we looked at Scala was that, although we’ve run into problems with Ruby, we like the flexibility of the language. We like that it’s such a full featured language, that it’s fun to code in. … We know that people write super high performance code in C++, and engineers like Steve and Robey have had experience with that. But we wanted to be using a language that we’re really passionate about, and it seemed worth taking a gamble on Scala.

I think programmer productivity is a factor of more than the programming languages, its also dependent on the developer’s passion for the language.

New Adobe toys this week: Flash Builder 4, Flex 4 SDK, Flash Catalyst, BrowserLab

An exciting week for Flash Platform Developers as Adobe released a number of Beta versions on the Adobe Labs site. I have just started playing with a couple of them but its definitely worth the shout out.

Flash Builder 4:
Flash Builder 4 is the next version of the Eclipse based IDE formerly known as Flex Builder. The renaming is more than just a re-branding exercise, as FB4 seems to have added features that make it a lot easier to work with other frameworks besides Flex. This is really exciting for me personally as this means it will be a lot easier to work with OpenPyro in FB4. In fact Greg even created a simple project with AS3 only classes that could be exposed as MXML tags. The resultant file size is minute.

Besides that, the my favorite extension to the IDE has been the inclusion of FlexUnit, the unit testing framework for Flex. While FlexUnit itself has been available as a library for a while, inclusion into the IDE will make unit testing a lot easier and hopefully a lot more prevalent.

There is also a network monitor built right into the IDE. While I have used Firebug with success for Flash apps on the web, doing the same for AIR apps has been a challenge (though Charles has been really good, though a requires a bit of a context-switch when coding). The network monitor is going to make a lot of lives a lot easier.

Integration of ASDocs is another great feature, as well as code generation for integrating with serverside code.

[Update] There are also a bunch of improvements to the Debugger on FB4 which you can read more about here.

Flash Catalyst:
Flash Catalyst is a new tool that Adobe is releasing with the promise of truthfully translating designer interactions to stub code that a developer can add functionality to. Basically Catalyst can import any Photoshop, Fireworks or Illustration file, and then can allow the design to assign behaviors to the different parts. For example the designer can select four graphics and mark tham as the four parts of a Scrollbar. The interactions are written out as Flex4 tags that can be compiled into a swf with complete interactivity.

The video below shows how Catalyst can be used:

http://tv.adobe.com/Embed.swf

Flex 4:
The two releases of course directly depend on the Flex 4 SDK, Adobe’s Open Source framework for building Rich Internet Applications. The new release of the SDK introduces a new component architecture called Spark. The core difference between the Spark and the earlier Halo architecture is the favor of the composition as a design pattern over inheritance. What this translates into in everyday development is a leap in productivity as complex UI components can be created a lot easier than before and not requiring things to be subclassed as often. This also makes skinning a lot easier, since all the skin parts can be swapped pretty easily. Another new thing in Flex 4 is the introduction of a new graphics interchange format called FXG, an xml format for graphics that can be understood even by the CS4 products like Photoshop and Fireworks. Matt Chotin’s post on changes in Flex is a lot more comprehensive.

BrowserLab
BrowserLab, a project formerly known as Meer Meer, is a new service being released by Adobe that targets HTML developers. BrowserLab allows developers to preview any URL as rendered by different browsers. The service is in limited beta, but I was able to get an account before it was capped, and I can tell you its pretty impressive. It would be interesting to see how Adobe can integrate this with Dreamweaver, although its supposed to remain open to mortals like myself who still prefer TextMate 😉

So a lot of toys on the labs site. Take em out for a spin and let me know what you think 🙂

So I am co-manager of the Philadelphia Flex User Group

…or rather as of a month or so ago. Still it felt worthy of a blogpost if nothing else to mark this date (/month) for posterity. I will be working with Derek Wischusen who has been doing an amazing job so far organizing local meetups. If you are in Philadelphia and interested in Flex, I would love to get to know you better and welcome your suggestions on making the group truly kick@$$.

The timing has been perfect, with Flex 4 on the horizon that seems really cool. In fact on the 24th of June, Adam Lehman from Adobe will be coming down to talk about Flex 4 and Coldfusion NEXT (details for the event can be found at the Philadelphia Flash Platform Group page on Adobe User Groups portal. Going forward we are hoping to coordinate even more events with the Philadelphia Flash Platform Adobe User Group as Flash and Flex come together.

If you have any suggestions on content, agendas and such for group activities, do join the conversation on our Google group. And if you are a local Flash or Flex developer who’s on Twitter, do drop me a comment here with your Twitter id (mine is @arpit).

My experience with Git and why I think Open Source projects should be released on Git

Over the last couple of years I have released a bunch of libraries under Open Source licenses, usually on Google code. However the my last project, OpenPyro was a little different and was released on GitHub with Git as the Version Control System. I write this as a developer with more experience and comfort using Subversion and yet encourage you to release your open source projects on Git.

So what is Git? The one line description (from Wikipedia) is “Git is a distributed version control system, born with the fundamental mechanisms making branching and merging really easy.” A detailed description of Git is beyond this post but the Wikipedia page is a good place to start.

Releasing OpenPyro on Git was not an easy decision to make. The project represents a lot of work on my part and I am nowhere near as comfortable yet with Git as I was with SVN. I definitely did not want an unfamiliar Version Control System deter possible contributors to the project. However the fundamental philosophy of Git was what finally won me over.

The Git workflow is kind of new (at least to me). A developer working on a project begins by forking the core repository. He can commit code to his fork at his whim and needs to keep merging from the original branch to get the latest updates from there. Its up to him to merge changes from the core repository as they happen. People working on different forks merge changes from each other as they see fit (if you are working in a non-distributed environment, you can all merge off of a source of truth repo)

Forking basically allows the project to achieve velocities greater than the initiator of the project. If tomorrow I stop working on OpenPyro, there could be a fork that has developers more committed than I could be. Why should OpenPyro stall just cause the original developer may have.

As of right now OpenPyro has been forked a couple of times. The first fork was for a Haxe port and this was before OpenPyro was on GitHub so it wont show up on the network graph on Github. The second fork was by Kelvin Luck who fixed a few bugs on his branch and is adding new functionality there. However he didnt have to wait for me to commit his changes into OpenPyro head. I merged his changes into the OpenPyro head much later. And now the OpenPyro history shows his additions to the project as official commits.

The diagram below shows the state of the repository as it got branched and merged at different times.

OpenPyro Git Graph

This kind of collaboration wasnt possible with SVN, something I realized while working on LogBook. I would get patches for bugs on the project, sometimes feature updates I didn’t much care about. But it was up to me to add those in, and sometimes time pressures made me miss commiting some features forcing the developer on the other side to wait with probably changes local to his machine.

I have been on the receiving side of that as well and I am sure you have as well. How many times have you looked at an open source project that seems to fit the bill for what you are working for but comes up slightly short. What do you do then ? Do you fork it? Without commit access to the core repository that the original author is maintaining, you cannot branch the project. All you can do is export all the files and recommit them into a new repository that you control. But now you have lost the project history (plus something about this approach just smells wrong, with very little attribution on the “forked” repository to the main project).

There are other features that are great in Git. Offline commits is another great feature that I use quite a bit. A more detailed comparison against SVN can be found here

Whether this paradigm works as well within teams working together, I am not sure. At work we continue to use SVN right now and I am not sure if we plan to move off it anytime soon, But if you are a developer releasing code under open source, I strongly encourage you to try Git. In the meanwhile here are some resources that you could find useful. Linus Torvald’s talk at Google is a good place to start understanding Git philosophically.

Git Manual
GitCasts: Videos on using Git
Getting Started with Git docs on OpenPyro

OpenPyro 0.4 released !

I am excited to announce the first official dot release (0.4) of OpenPyro, the open source UI framework I have been working on (on and off) for the last few months. All the information including source code, samples and documentation can be found at OpenPyro.org. I would love to hear some feedback as well. I am really hoping for this to be community powered and would love to integrate or help integrate more features into the framework, so if you are interested in the project and would like to collaborate, please feel free to contact me via blog comments, Twitter (http://twitter.com/arpit) or via the OpenPyro mailing list. And definitely take a look at the OpenPyro Wiki, which has a bunch of examples, samples and some concepts explained.

The biggest feature in 0.4 is the measurement and layout system that is pretty similar to Flex that I love and a fairly decent component set. Because all OpenPyro components use composition rather than inheritance, I am really hoping to build something very Flex4-esque but keeping filesize . Am also hoping to keep the core library pretty small and create a comprehensive library of functionality using plugins, basically libraries whose functionality depends on OpenPyro but not the other way around. For a full set of development themes check out the section here on the wiki.

I have been writing about OpenPyro on this blog for the last few months as well, all those posts can be found here

Hopefully this can grow into a body of code that the community finds useful.

Flex Builder Tip: Use SWCs for image assets, not Embed metatags for pure Actionscript Projects

I have been using Flex Builder for a while now as my main Actionscript IDE for both Flex and Actionscript projects. Of course in the latter, I have been very sensitive to not using even an iota of the Fx library. However traditionally I had always used the [Embed] metatag to embed graphic symbols into my Swfs. What I did not realize was that the Embed tag brought in Flex code into my project. I only discovered that as I was getting a build of OpenPyro ready for a release (its going to be 0.4, isnt out yet, but probably early next week).

I was trying to build the OpenPyro swc that users could be imported into projects. However running the compc command resulted in the following error screen:

Compc Error

Apparently, using the Embed metatag was causing the graphic to be imported but then converted to an instance of the Flex SpriteAsset class. WTF, this was definitely not what I wanted. Googling (at 2 am, so I may not have used the best queries) did not bring in any meaningful results. However a friend of mine recently switched from Flex Builder to FDT and I remembered him showing me how he did it, so here are the steps:

1) Create MovieClip symbols in the Fla and export them for Runtime Sharing with appropriate class names.
2) Generate the SWC from the Fla
3) Place the SWC in the classpath of the Actionscript project.
4) Use the exported symbol’s class name to reference the graphic symbol

So this worked. I was pretty aware that the Bindable tag was Flex specific but I didnt know that Embed tag did as well. Adobe really needs to differentiate the Flex specific metatags like Bindable and Embed with the pure AS3 ones like Event. My one big complaint with Flex Builder was that it never complained considering I was in a pure Actionscript project.

I hope Gumbo fixes this.