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 concepted by my then boss and later friend and mentor named 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. 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 and 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.

Its exciting to see LogBook, Comcast Interactive Media’s first open source project get some traction. There is talk of LogBook being included in other open source projects as well as people have started submitting patches and suggestions to the project.

One issue that was submitted a few days back was around the Logging implementation dispatching all logging events out of the application across the LocalConnection. Here is a quote from the issue:

Logging could add significant overhead to an application, due to
log message construction, and sending messages to LogBook.

It is good practice to minimize logging overhead, with code like:

if (Log.isInfo()) {
LOG.info(”version: {0}”, version);
}

The current implementation of class LocalConnectionTarget always
sets the log level to ALL and the log filter to “*”. This means
that all logging methods are executed, which is undesirable.

You can see the details of the issue here.

I just wanted to elaborate a little on why the LocalConnectionTarget class does not use any kind of filtering to reduce the number of LogMessages being constructed.

One of the reason we went with LogBook as an AIR application as opposed to a web application was because as far as I know, the Flash Player process on the web is independent from that in AIR. This means that LogBook could become a very elaborate application on its own but it will not impact the performance of the application using LogBook based logging. Also when we pass objects across LocalConnection, these objects do not accumulate in the application’s memory. Here is a screenshot from a quick experiment where I ran an endless loop that created a custom LogDispatcher object, had it send a log message across the LocalConnection and then get garbage collected. The memory profile of the application can be seen below:

Here is also the live objects screen capture:

As you can see, over 600 objects were constructed but all of them could be garbage collected with no overhead in terms of memory used.

So your take away from this discussion is: using LogBook has virtually no memory overhead in your application. The idea of broadcasting all messages to LogBook is to allow you to filter the data on the client at the moment of debugging or after, rather than configuring it at some pre-launch time.

Now LogBook itself is another story. Another bug submitted by the same developer who reported this also talked about LogBook’s performance when over 1000 messages were collected, and yes, I have verified that at that point, the application becomes pretty sluggish. So for the next version of the LogBook, I am considering leveraging the SQLite database that AIR comes packaged with.

More on LogBook 2.0 soon. We are already on it and it will be good . If you would like to participate in defining the functionality in 2.0 or better yet, help us develop it, join the conversation on the LogBook user group here.

Those are the names people: mark em down. Flexamp is on its way out . I kinda want the player name to be independent of the technology behind it (I am following an industry norm here. There arent and C++MediaPlayers or JavaAmp ). While these names may or may not stick, these are the package names of the Flex Project and the J2EE Project on my Eclipse application so they will always be reflected in the source files.
I am fairly far ahead on the clientside implementation of the player but am just about starting the J2EE part. I havent mucked around with J2EE as much although I do come from a Java background as such. Desktop Java has much fewer rules to adehere to. The first step in J2EE is the biggest one and understanding the structure of a J2EE app does take some serious reading.
Of course there is a leap from the book to the server .
So here is the story of day 1 of Sol development.

Step 0 – Choose Eclipse:
I do all my programming on Eclipse and love it. Ever since the ASDT plugin came out, Eclipse has been my standard development environment. Its well integraded with CVS and SVN and allows quick text searches which makes life a lot easier. And developing Flash and Java on the same IDE is veeeery convinient. The web tools project is something I am just getting used to and while I have heard seasoned Java developers complain about certain features, my own experience has been fairly good. So armed with Google, I created the Sol project.

Step 1 – Get your J2EE app container + MySQL database:
My www host runs Tomcat 5.0.27 so thats what I run as well. I also downloaded the appropriate MySQL version

Step-2 – Create the Dynamic Web Application Project:
This is a project template that I think came with the web tools plugin on Eclipse. Once you create a new Dynamic Web Project, Eclipse will create the WEB-INF, META-INF, classes and lib directories as per the J2EE spec(A typical j2ee webapp should look like this) in a folder called WebContent. That folder can go as is as a webapp in a container (although typically you would deploy it as a web archive (war) file).

Step 3 – Include the jstl taglibs in your container:
Since I will be using the Java Standard Taglibs, I downloaded the jars from the Apache site. Include these taglibs in either your application’s lib folder or, preferably, in your container’s common lib directory (TOMCAT_HOME/ROOT/common/lib/) which would make them visible to all the webapps.

Step 4 – Create your basic JSP
Since the goal of this pass is to verify that my installation is correct, I wrote the simplest JSP file. You can download it from here.

Step 5 – Run the JSP from within Eclipse:
Make sure that the Tomcat Engine isnt running and then right click on the project and choose Run As … > Run on the server. Update the files if prompted and point to the installation directory of the Tomcat server when prompted to choose the local server. As the server starts up, the server logs appear in the Console window. Eclipse will then launch the built in browser and point it to the application root. Click on the JSP page and ensure that it works.

Possible issue: I have no idea why this was happening but even though my JAVA_HOME environment variable was pointed correctly to the JDK, Tomcat could still not find the javac tool to compile my JSP. On a thread I found the solution to put the tools.jar into the TOMCAT_HOME/common/lib directory. That worked.

Cheers.

I tried to play around with Flex Data Services today. So I downloaded the package and went through the install. Now since I already have an instance of Apache Tomcat 5.5 running on my laptop I was less than inclined to install JRun. So I installed the non-JRun package and deployed the FDS WARs. I ran the the collaborative dashboard example and things looked good. The other application I had been eyeing for a while was the NoteTag example application written by Adobe. For the uninitiated, NoteTag is a collaborative note taking application. The coolest part of NoteTag is that it doesnt have a backend database but rather uses Blogger, TypePad and Del.icio.us to store the data. However since these services require authentication over SSL, I had to install a security certificate on my Tomcat instance.

So here is how I went about it. First of all, the SSL key generator is part of the core JDK as of Java 1.4. The keytool is available at %JAVA_HOME%\bin\keytool.exe. Run it as specified at the Apache Tomcat tutorial site:

keytool -genkey -alias tomcat -keyalg RSA

The tool asks a series of questions like name, address etc to write the keystore. Once the key is written, move it to where tomcat can access it in the Catalina directory. Lastly uncomment the HTTPS connector and add the following attributes:

keystoreFile=”tomcat.keystore< or whatever you named your keystore file>“
keystorePass=”“

Ta..daaa…https!!

I still havent managed to run NoteTag (I am getting connection errors) but thats a battle for tomorrow. Right now I need to go to sleep.

Debugging isnt fun….
But it does have its moments, when you feel you have learnt something new.Like today….

First let me step back a bit and explain ip-domain mapping using host files on Windows. The Hosts file contains the mappings of IP addresses to host names. This file is loaded into memory (cache) at startup, then Windows checks the Hosts file before it queries any DNS servers, which enables it to override addresses in the DNS.[1] The host file is located at ‘C:\WINDOWS\system32\drivers\etc\hosts’.

Typically, during development, I use host files to map urls for applications under development to the sub-domain of my main site. This allows me to access cookies etc while still running the web-app on my laptop.

While setting up an web-app today I mapped a domain to an ip using my host file, but could not bring the page up no matter how I hard tried. At my wit’s end I called upon our sys-admin and resident Solaris proponent to help me fix this problem. A couple of hours later I was on my way and had a much deeper understanding of server configuration stuff. Before I forget what I learned I figured I may as well save it for posterity by publishing it here.

The problem arose because I was trying to map my domain to an ip of a virtual server. While this is not a big deal (click here to see how Apache does it), there was something weird happening on my machine.
Typically servers, like regular computers, have physical interfaces that connect them to the network. However you can have multiple virtual interfaces each with individually assigned IP addresses on a single physical interface. Within the webserver software, listening sockets were defined and mapped to the IP addresses on our virtual interfaces.
Each of the virtual interfaces are associated with a listening socket and every virtual server instance is bound to that listening socket. Virtual servers themselves can be name based or ip based. IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve whereas name based ones use DNS mappings of IPs to decide which host to serve

The behavior I was seeing turned out to be because while the server’s virtual server instances were bound to individual IP addresses, there were also names that identified what was allowed in the host request field sent by a browser. Since I defined a name in my local hosts file that didn’t match a name defined on the server to be associated with the virtual server instance that I tried to reach, the web server sent my browser’s request to its default, or primary instance.

…I am glad its a Friday !