2 posts tagged “cruisecontrol”

I've been using the iPhone SDK since its original release way back in March. Many frustrating moment in the beginning but the recent beta 7 and beta 8 release proved to be ready for prime time. Apple has added many helper classes or helper methods to classes to make it far easier to work with the UI components, which is by far the most frustrating things I encountered. I am still having problem wrapping my head around the idea of Interface Builder but since the apps that I am building do not involve very complex UI, I just hand coded all the UI instead.

To illustrate, the original iPhone app idea I had that I started developing using the original SDK is a mobile application for Mingle. The application would consist of a series of table views showing projects, cards, and card details, along with some network code to talk to the Mingle server through REST API. At that time, progress was slow because of many factors. First, learning Cocoa/Cocoa Touch API and Xcode at the same time was tough. Second, the Cocoa Touch API was a bit 'primitive' in the beginning. What I mean is that while the API provides all the necessary hooks for developers to create an iPhone app it does not provide many pre-build components, making it difficult and required lots more work from developers to re-create the look and feel of the built-in iPhone apps.

I was so put off by the initial experience that I skipped beta 4-6 and did not open up Xcode until last weekend. And what a refreshing change with beta 7! Now it is straightforward to make an app that looks and feels just like an Apple's one. I was so fired up that last Sunday evening I decided that I would try to create an app for an idea that one of my fellow ThoughtWorker suggested to me. Instead of days of tearing my hair out and got no where, I was able to create a almost features completed app within hours, using beta 8.

So what is this app? It checks the build status on the CruiseControl server. Just like CCTray (Windows) or CCMenu (OS X), it allows users to monitor their software build status. Following the convention, I am calling it CCPhone. The app isn't more complex than the Mingle app but the fact that I was able to almost match the productivity I normally get on my Windows development environment means that I was excited about working on the app rather than dreading it.

Now here are couple of screen shots:

To-do:

• Fix the build time being 1 hours off (probably day time saving bug)
• Better status icons
• Create application icon (currently it uses icon from CCMenu)
• Finish coding the 'Force Build' functionality
• Add startup screen bitmap (so it won't be just a black screen)
• Add auto detect of CruiseControl server (Java, .Net, or Ruby)

I don't often met new people and thus question of what I do does not pop up this frequently. But it has been hard to describe what I do to people who are not in the software development community since the first day I started my first job. Normally I just say I am a software developer and that tends to put most people off since they don't understand software at all. To them software is a black box, it is magic, it is voodoo. But every now and then there will be someone who does a bit of Visual Basic Scripting in the office and thinks s/he knows software development. This person would then try to probe deeper about what I actually do. In that situation, I'd have no mercy and just tell the person exactly what I do. 99.99% of the time, eyes would glazed over within 10 seconds and conversation would die as soon as I finish my sentence.

We are developing the build & deploy system for the whole enterprise. That is, a system that allows in-house developers to build their applications and deploy the applications to the machines. Sounds simple but we are also implementing Continuous Integration concept using build servers, trigger off source control checkins. (The main reason ThoughtWorks was brought in as we are known in the industry as build expert, re: CruiseControl)

We are also solving their source and binary dependency problem so applications would be self-contained when they are built, tested, and packaged by the build server. The deployment/install process would allow environment specific properties to be substitute during deploy time so packages can be deployed to multiple environments without going through the build process again. (Build once, deploy everywhere)

Deployment process also includes workflow steps to manage code review/gatekeeper approvals, security audits, and code signing.

All of these are built with extensibility in mind so future technology, such as Ruby, IronPython, can be introduced into the organization via plugins with minimum alteration to the system.

In addition, we are also advising the client on code branching and merging strategy, best development and unit testing practices, dependency management, database upgrades (model and data) using delta scripts, etc.