Back after a long break

If you have been following my blog I apologize for not posting for so long. My last post was in Nov 2010. If you were wondering where I disappeared to, rest assured I have a valid reason.

I have never spoken about my day job and I finally am able to. I work for Imagecom Inc. a company in Arlington TX that has spent the last few years developing an absolutely unique, radical CAD solution. While the  product (which I will talk of soon, hold on to your hats), is not a new idea, the solution that we have come up with is one that is not available anywhere else.

The product is called FlexiDesign. It is a semi-automated 2D drawing to 3D model conversion tool that fits in the CAD system of your choice. The resulting 3D model is fully parametric and feature-based.

If you have worked in the CAD domain, either modeling or developing CAD apps or add-ins, you have definitely heard of automated, semi-automated or manual 2D to 3D conversion tools. Some are:

• 2D to 3D Tool for Autodesk Inventor
• SolidWorks 2D to 3D - The 2nd video titled "Leveraging existing 2D Design Data" shows how SolidWork's 2D to 3D works
• PTC Autobuildz - A bit dated, too, but should show how Autobuildz works.

There may be others, but these are the more well known ones and are from the big boys, each part of the oligopoly that is the CAD industry.

In the next few posts I will be talking about some of my experiences developing a CAD Add-in product/solution. While my plans are not finalized, I hope to discuss topics like licensing, CAD API (the good and the bad), development practices, and my favorite topic - testing. A lot of the tools that I have uploaded as part of this blog were instrumental in developing and deploying FlexiDesign.

So keep an eye on this blog and I will keep it updated as often as possible.

New license for my SWXBATCH_CEEFIT project

Have you heard that the CeeFIT website is back up and running? Well it came back up a few months ago. Thank Heavens.

But the author kindly pointed out to me that I was not complying with the original license of the CeeFIT website, i.e. the "GNU GENERAL PUBLIC LICENSE Version 2" as mentioned here. So to comply I had to change the license of one my projects, specifically the SWXBATCH_CEEFIT. Unfortunately Google Code (where I host the source code of my projects) doesn't allow me to specify different licenses for individual projects. So I had to change the license associated with all my projects to the GPL v2, though this only really affects the SWXBATCH_CEEFIT project. I have added a note on the home page to inform of the changes, but am hoping repeating this information on my blog will help clarify the issue.

As for my other projects, you are free to do what you want with it since I have not attached any license to the projects themselves.

SO DOES THIS AFFECT YOU?

The SWXBATCH_CEEFIT is primarily intended as a test framework. If you use it as intended and don't distribute your test framework to your clients (i.e. you only use the test framework in house) then the license change from 'New BSD' to 'GPL' doesn't affect you. If you are unable to comply with this requirement, I am afraid I can't help, since the GPL is viral in that way.

My Continuous Integration Build is too fast

We all know of Continuous Integration and the importance of having really fast builds, especially on a central build server. If not read up on http://martinfowler.com/articles/continuousIntegration.html. You may have also heard that a good build time to shoot for is ~10-15 minutes for each regular build (not accounting for nightly builds)  at least for small-medium sized projects. If you are interested there are numerous discussions and posts on this. So like any good build engineer striving for efficiency and speed I attempted to reduce build times for the project I work on, at least till now.

Some details on the project build:

• Our projects are currently in Visual Studio 2005 (we are in the process of upgrading to 2010 but that is another story).
• Almost all our projects are native C++ (i.e. Unmanaged code) with a sprinkling of C# (i.e. Managed code)
• We use CruiseControl.NET but use the Visual Studio Task (which internally executes devenv.com to rebuild the Visual Studio 2005 projects).
• Monitor every minute for a developer's commit to the repository
• Run Unit tests
• Run Functional tests
• Run Integrated tests (nightly builds only)
• Notify developers of build status
• Licensing and Unlocking
• Package (ZIP, installer)
• Deploy (for download by our modelers/testers)

This entire process takes about 12-15 minutes on our build server which is not the newest piece of hardware (in fact was purchased somewhere around 2001/2002). The nightly builds could take more than an hour since we run Integrated tests too, on the same build server. Not too shabby but we could definitely do better. 

The simplest way to speed up the build would be to purchase a new build server and cannibalize the old one or simply re-purpose it. 

Licensing and what now?

But here's the catch. In case you missed it, I highlighted "Licensing and Unlocking" in the steps above for that reason. What is that step you wonder? Well I work with Pro/Toolkit applications, the API for Pro/Engineer. If you want to deliver programs that use Pro/Tookit to your customers (who most likely will not have a license for Pro/Toolkit) then PTC provides a little executable called protk_unlock.exe that simply "unlocks" your Pro/Toolkit application to enable it to run on PC that don't have the license for Pro/Toolkit. If you were not aware of it, "unlocking" your Pro/Toolkit application will cause the PTC License Server to hold your Pro/Toolkit license for 15 minutes (yes, you read that right - FIFTEEN minutes). Of course all this is common knowledge.

'14' is the wrong answer

So what if my average build completes in less than 14 minutes? Well CruiseControl.NET uses a "update before you build" style to build your projects regularly. Which means that if two developers commit to the repository within a minute then there is a good chance that the two commits would be rolled into a single build (this is different from the process that some Continuous Integration tools use where a commit triggers a build - must be nice to own these nicer tools). But the worst case scenario is that "if for some reason the average build time is less than, say, 14 minutes AND the next build starts within the minute, THEN there is a good chance that the second build will not be able to 'unlock' its Pro/Toolkit application, since protk_unlock holds the license for 15 minutes and our build has finished in less than that time."

Now what?

So what is the solution to this problem? Well, if you have the money, you could always add a 2nd Pro/Toolkit license to that single build server, so that you always have one license available every 15 minutes.

Or you could do what I did - YOUR BUILD IS TOO FAST, SLOW IT DOWN.

Almost makes me want to cry. Oh well. What other idiocracies have you encountered in your build scenarios?

Note: I linked to a cached page from Google's server for the following link http://openmakesoftware.com/mavericks/2009/02/17/check-out-code-post-commit-not-pre-build/ since the original didn't show when I posted this article.