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.

Most Flash/Flex developers are by now pretty familiar with the Adobe Air platform. And maybe its a case of “when you have a hammer, everything looks like a nail” syndrome, but suddenly the browser doesn’t seem to be enough for the kind of apps I would like to build. The realization couldn’t have come at a better time with so many new cool platforms to play with, and if big company adoption is any measure of the merit of an idea, then web apps that live beyond the browser is the way of the future.

Today a couple of interesting news items came to my attention.

1) Myspace integrated Google Gears into their messaging platform.
This makes Myspace the biggest Gears adopter and with the audience the size of Myspace, the platform has suddenly become relevant again.

For the uninitiated, here is the Gears announcement video from a while back

I use Google Gears (or Gears as apparently it has been renamed today at the Google I/O conference) for Google Reader, but it always surprised me that even GMail hadn’t adopted it. Based on what I read on Techcrunch, MySpace’s main justification was to reduce the load on their servers for pagination and sorting. While they haven’t enabled offline functionality a-la Google Reader, I am sure they will at some time.

This move, while obviously great for MySpace, also is a huge boon to people looking to create OpenSocial applications that would live on MySpace. They can, if not completely depend on, at least use it to lighten the load on their own servers. And these applications living on a different OpenSocial containers may prompt more non-MySpace audience to download Gears.

2) Yahoo launches BrowserPlus
BrowserPlus is an application that adds more services to a web browser. The plugin installs Drag-and-drop capabilities, image manipulation libraries, persistent stores, etc. And the idea is that you will be able to write your more and more services once the platform opens. Another great idea here is that, while there may be a million services out there, only the ones that are needed for apps are loaded on demand. Yahoo will adopt a ITunes-for-IPhone-Apps model to make sure services loaded in are not malicious, and given Yahoo’s history, I trust them a lot more that Apple or Google. All the services will be available via Javascript, so web developers can leverage any of the services out there to build their apps, all of which are basically web pages. I am really psyched about this one. To me it almost looks like a Adobe AIR-esque runtime but this time I can extend it if I need it to do something. Plus given that a Ruby interpreter is already included into the runtime, and I am getting to like Ruby quite a bit, you can potentially build some really awesome applications leveraging libraries available there.

Gears and BrowserPlus are awesome, and there are other technologies that look really interesting. One of these is JavaFX, Java’s stab at a client-side runtime very similar to Flash. The Java Virtual Machine (Java’s equivalent to the Flash Player), is a lot more powerful than the Flash Player itself, although I am not sure how much of that functionality will be enabled from JFX, it still could be an interesting technology to watch, especially after you see the kind of interaction they are hoping to enable (even if the demo below crashes repeatedly)

Besides these there are other technologies that Mozilla Prism as well as other widget engines Yahoo Widget engine, Windows Gadgets, Mac Dashboard widgets, Google sidebars etc etc, all of which are worth watching. With all these technologies and runtimes that are based on web technologies, especially client side technologies like HTML, Javascript and even Flash, the web developer is suddenly at a point where he can enable his applications to do a lot more than ever. Of course now we have to choose our runtimes and make sure we do not serve broken experiences when users dont have appropriate plugins, as well as learn some technologies traditionally we weren’t concerned with (like SQLite, almost everything seems to use SQLite). But in any case, its a good time to be a client-side developer .

About 4 months back, the Flash team at Comcast Interactive Media released LogBook, our first official open source project. This blog post is a retrospective on the experience. The main reason I am writing this entry is to show that open source serves more than just the developer ego, and a company that allows open source of non intellectual property (IP) projects actually benefits from such projects. Hopefully someone can use this entry if they ever need to convince someone on open source projects.

Preamble
As I had mentioned in my pre-launch post, LogBook started as an internal tool that we wrote to debug our Flex applications. Pretty soon this had become an essential part of the application development workflow. We realized there was a real need for a tool like this in the development community and so brought up the idea of open sourcing the application with the development managers and the VP of Engineering. The developer group at CIM had already been participating in the open source community, releasing updates to some Java projects that power our sites, however we had no experience with starting a new open source project. But given our history with open source, selling the idea of open sourcing was a lot easier than you would imagine (special thanks to the legal team at Comcast who got all the legal stuff done so fast, unlike a lot of the stories you hear about projects getting bogged down with legalities)

LogBook was an ideal candidate to get our feet wet with the process of open source projects. The project’s codebase was small (about 15 classes when we started it) was almost completely separated from any other project we worked on. We also knew that the project was not something that grow faster than we were ready for: not a lot of developers enable any kind of logging in their applications and even fewer use the Flex logging framework which is what we released the first build for, but the small scope of the project was by design, being our first open source project, there was a learning curve for us too (I have released quite a bit of code on this blog over the last couple of years but managing a project is a lot different).

With all groups signed off, LogBook was released on Feb 12th, 2008 on Google Code. The project was released under the MIT license. We also started a google group to discuss the evolution of the project. We also made an effort to keep project related conversation in the open, so email exchanges on the LogBook project even within the CIM team happened via the group mail address. Google analytics were also enabled.

LogBook Today

Four months since the project’s release, here is the project’s status:

Based on the numbers here, with 486 visits to the downloads page and 804 to the main page (which has the direct download link), I would imagine the project has been downloaded around 500 times, which is really cool. The source code itself has been checked out about 216 times. Not bad for what started as a quick debug app between 6 developers .

So Why Open Source?
There are a lot of books out there that talk about the advantage of open source projects, and there is no dearth of open source success stories (Apache, Eclipse, etc). However while these examples are great, in our case, LogBook would always be a small project with a few commits every now and then. So why should a company take on the headache of opening up the source code ? Below is a list of the not-so-obvious advantages of releasing code under open source licenses.

1) Much better code quality:
It was really surprising how much better the LogBook code is today than it was when we decided to open source it. A lot of us had put a few snippets of code here and there when it was an internal tool. But when we decided to open the code base, members of the team decided the code was not good enough to open source (Go developer pride !). Same goes for the user interface as you can see below:

LogBook pre-release:

LogBook post-release:

Thanks to the open source project, LogBook is a lot more pleasurable to work.

2) Bug fixes = education
Once bug reports started coming in from other developers, we took some time to review those and see if when we could finish them. But the bugs taught us things that we didn’t know. For example, there was a bug that talked about LogBook hanging when a you tried to clear more than 100 logs from the list. The code looked fine, we were using ArrayCollection.removeAll() so we were baffled for a while. When we replaced that with ArrayCollection.source = new Array(), the performance went back to normal. Details of the bug/fix can be found here but this situation was never discovered internally. Had we not open-sourced LogBook we could have used removeAll() in code in one of our production projects, where CIM might actually lose money/audience if the application hung or something. We have fixed quite a few such bugs and a lot of them have taught us new things. Its almost like having a group of technically savvy QA engineers for free .

3) Bigger developer pool
The main reason users give for open sourcing code is to have tap a bigger developer pool than if the project is maintained internally. Our biggest non-Flash-Team contributor was Mat Schaffer, a colleague at CIM . While Mat is not part of the Flash team, he has been interested in Flex and this project let him contribute patches to the LogBook project. The collaboration also taught me more than a couple of things in managing project updates / dependencies, domains that are a lot more mature in the Java world which is Mat’s domain at CIM. For example, I have now started using patches for atomic updates to the LogBook code, which is so much better than running through a number of files trying to update code.

4) Open code + good ideas = easier collaboration
The Flash team gets to work with teams from a lot of other groups / companies and a lot of our projects are around integration. With LogBook, we actually started collaborating better. Once LogBook was out, we actually had a project where we sent the developers from another group the link to LogBook and asked them if they would consider using it for logging events from a black box solution we were getting from them. Since LogBook also scratched their itch as well (they needed to monitor how their code was behaving at runtime too), and since its so easy to integrate LogBook based logging, at the end of the day both teams agreed to logging certain events that either of them could see. Since LogBook was not an internal project, they did not have any problem with integrating code that did not add any dependency on a library owned by us. As we open-source more code, it would be great if other teams we work with use that and contribute to that rather than everyone build their own version of the same functionality.

5) Potential New Hire Litmus Test
Another interesting aspect has been the ability to point potential new hires to code in the LogBook project and see how they understand that. Candidates can also be asked to look at and discuss an open bug on the project, since a lot of our day-to-day work is around bug fixes, its a stronger litmus test than a theoretical algorithm kind of question at an interview. Since LogBook represents the way the team at CIM codes, the candidate’s understanding of the code is a good metric to how well he’ll perform with the rest of the code that is internal to CIM. And if the new hire is not up to snuff, we haven’t shown him any CIM propriety code. We haven’t done this yet but its definitely something we want to try going forward.

The Future of LogBook
LogBook as a project is still going strong. A few months after we released LogBook, we also added the CIM Logging framework to the LogBook project. This allowed pure AS3 projects to use LogBook. We also recently launched a hosted version of LogBook, which is exactly the same as the installed version but doesn’t require the application to be installed.
We are also planning to release more code under the MIT license, and a lot of this will be used in the next version of LogBook. The next feature on the roadmap is User preferences with the ability to save things like recently used log keys so that you dont have to remember them (issue #7 in the issues page). The team tries to implement features and bugfixes as we get time as per our needs, so some features may take longer to implement than others but if you want to join the project and help us steer this along, do join the user group and make some noise .

p.s:
And for all you Java/OSGI developers out there, also check out CIM’s cimspringfield open source project. I won’t attempt explaining it cos, well …I cant

So as most of you guys may know, Aral Balkan, one of the biggest names in Flash development, has been working for a while on a reference Google App Engine application called GAE SWF. In the last build, version 1.53, he has included a component that lets users browse and upload an image to their profile page. The user also gets the opportunity to scale and crop the image before he assigns it to his profile. The exciting part is Aral is using my ScrollImage component that he has extended, to handle the scroll, rotate and crop functionality. Aral has also released the updated source code under the MIT license as well, which is the same license that the original code was released in.

I am really excited the ScrollImage is finally out in the wild. I originally wrote it as part of a UI requirement on a pet project that I dropped later so there was no reason to take the component to completion. However now that its out there, I am thinking spending some time adding some configuration options so that its complete (in my book) may not be a bad idea. I will also put the final source code on google code or something where it actually maintains a version history.

In the meanwhile, check out the GAE SWF project here and Aral’s updated code here.