Code Zen

…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).

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.

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

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:

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.