paged=2&category_name=blog%2Fsoftware
Setting up Unit Testing in Xcode 3.1
July 28, 2008 | 2 Comments
Xcode includes OCUnit, so you don’t need to get a copy. But, you might want to take a look at their website (http://sente.epfl.ch/software/ocunit/) for information and tutorials on how OCUnit is intended to be used.
If you are planning on doing Test Driven Development (TDD) you may also want to get the following packages:
- OCMock – OCMock is an Objective-C implementation of mock objects. (http://www.mulle-kybernetik.com/software/OCMock/)
- Hamcrest – library of matchers for building test expressions (http://code.google.com/p/hamcrest/)
Other good articles on Xcode Unit Testing that I came across:
- Unit Testing with OCUnit – http://www.macdevcenter.com/pub/a/mac/2004/04/23/ocunit.html?page=1
- Test Driving Your Code with OCUnit – http://developer.apple.com/tools/unittest.html
- Xcode unit testing articles – http://chanson.livejournal.com/tag/unit+testing
- Unit Testing with Xcode – http://www.stiefels.net/2007/05/01/unit-testing-with-xcode/
By reading through the documents references above I was able to get OCUnit up and running for one of my projects. It took a bit of experimentation, but in the end it looks like OCUnit will work just fine for doing TDD in Xcode with Objective-C. Anyone wanting to try out TDD should give it a try. The benefits for your project are significant. Go for it!
Building Team Cohesion Quickly
July 3, 2008 | Comments Off
When forming a new team to build that Killer Web App ™ it is very important that the team work as a cohesive unit. Much has been written about how to build a collective team spirit and I won’t rehash that here. Sufice to say, if you don’t have a cohesive team you probably won’t be able to execute on your grand ideas and the project will eventually fail.
Today on TechCrunch there was a terrific article that details how one group of like-minded individuals came together to build a web application in a few days for a meer $10,000. Check it out.
Microsoft Professional Developers Conference 2008 – See you there?
July 3, 2008 | 1 Comment
The last time I attended the Microsoft Professional Developer Conference was back in 2001, shortly after the attacks of September 11th, 2001. Just over 6000 people made the trip to Los Angeles to learn about the latest technologies from Microsoft, as they were in the midst of rolling out the .NET Framework. They were pushing Hailstorm (I still have the free book they gave everyone with the Hailstorm API in it. I never did get a chance to use it though.). Everyone was excited about building new web services using .NET and C#.
A lot has changed since then. Vista and Windows Server 2008 are here, the .NET Framework has gone through three major revisions, Visual Studio has seen major improvements supporting team development, Intel has delivered multi-core processors and Microsoft still hasn’t delivered on the promise that was Hailstorm.
The preliminary agenda for PDC 2008 has some interesting sessions listed. Topics I am hoping to learn more about this year include:
- Silverlight
- Visual Studio 10
- Windows 7
- Multi-core Programming Techniques
Even though Bill Gates is now officially retired it looks like he is scheduled to speak at the conference as well. For a geeky college dropout with a whiny voice he does a great job delivering keynotes to developers. He doesn’t have the stage presence of a Steve Jobs, but he isn’t running Apple either. I look forward to hearing what his message for Microsoft developers is this year.
The dates for the conference are October 26 – 30, and the event is being held at the Los Angeles Convention Center once again. I hope to see you there.
Simple UI Refinements Increase Developer Productivity
June 27, 2008 | Comments Off
Recently I have been thinking a lot about what it takes to create a good user interface versus one that just gets the job done. Whole books are available about UI design, but I think most developers steer clear of them, adopting a Git-R-Done attitude instead.
Most developers that do UI work know how to use the various widgets, can follow the general patterns that can be observed in other platform applications (i.e. copy the UI “feel”), and have a vague sense of how to lay out the elements of a dialog box. What we all seem to forget is that the field of human interaction is separate from programming, and that there really is something to it.
A very good example of how subtle changes in a UI can make all the difference can be found in Visual Studio and Xcode; the development environments for Windows and Mac OS X. In both tools a dialog is provided for manipulating the compiler and linker settings that control how the project is build.
Visual Studio 2005 – nice set of property pages that can be navigated by a tree on the left. The problem is, you have to already know where all the properties live (under which tab) in order to quickly navigate to the properties you want to change. Take a look at the screenshot to see what I’m talking about.
Apple took a similar but subtly different approach on their project properties dialog box. They list all properties by default, grouping them by category. The developer can scroll up/down through the complete list to browse all of the properties. The search box at the top of the dialog provides a more powerful user interface than the tree control in Visual Studio. This one little addition makes all the difference in the world for a busy developer.
Here we see how this simple addition can increase the productivity of a developer. By simply letting the developer type a free-form string that describes part of the property he/she wishes to change the list of properties is narrowed to display only those that are a match. In the screenshot below you can see how this makes it very easy to get at the preprocessor definitions to make a quick change. In Visual Studio the developer is expected to remember which category the property appears in, remember the name of the category, and then navigate to that tab before he/she can make the change.
This is just one small example of how similar user interfaces can be very different when actually used. Both provide a way to manage the properties of a project, but only Xcode provides solid UI features that support the day-to-day use cases for a busy developer.
So, it should be clear that spending time on UI design can pay off. Your users may not recognize the amount of effort that was put into the UI, but they will appreciate the increased productivity that a well though out UI provides.
How to enable MSI Logging
June 9, 2008 | Comments Off
If you are trying to debug an installer problem it is probably worth having MSI logging turned on. This will produce a file in your %TEMP% directory that contains a detailed trace of the activities that took place in MSIEXEC. This can be very helpful when an install or uninstall fails without any clear indication as to why it failed.
Log files are stored in the directory pointed to by the TEMP environment variable. The filename format is MSIxxxx.LOG, where xxxx is replaced with a random string. A new log file is created for each invocation of MSIEXEC.
To enable logging through group policy, do the following:
- Start / Run… / gpedit.msc
- Drill down into
Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / Windows Installer / Logging - Enable logging with the setting “voicewarmup”. These are the command-line arguments that MSIEXEC will use.
These links contain more information on setting up logging:
GetQueuedCompletionStatus() – Devil in the Details!
May 22, 2008 | Comments Off
One of the projects I work on makes use of the Win32 asynchronous I/O model for managing network traffic between a Windows Service and a custom-built network device.
One of the key Win32 APIs we use is called GetQueuedCompletionStatus. This API provides access to an I/O completion port that is managed by a separate operating system thread.
When dealing with this API and Windows asynchronous I/O in general it helps to think about the model as being supported by a separate workpool thread. This API gives the caller a way to synchronize with the operations of that workpool thread (or threads).
The prototype for this API is as follows:
BOOL GetQueuedCompletionStatus( HANDLE CompletionPort, LPDWORD lpNumberofBytes, PULONG_PTR lpCompletionKey, LPOVERLAPED* lpOverlapped, DWORD dwMilliseconds);
At first glance the API may not seem too complex. There are 5 parameters and a boolean return type. Some of the parameters are easy to figure out just be looking at their names. Others are less clear. You could speculate that the returned boolean is an indicator of whether or not the operation was successful or not. It is easy to be lulled into a false sense of understanding by reading through the first few paragraphs of the MSDN documentation on this API.
It actually turns out that this API is very complex (perhaps too complex?), and careful study of the MSDN documentation is required if you wish to handle all of the possible conditions when this API returns. Pay careful attention to the section in the documentation that discusses Return Values and Remarks.
My favorite gem from the return values section (and the one I recently missed when using this API) is:
If a socket handle associated with a completion port is closed, GetQueuedCompletionStatus returns ERROR_SUCCESS, with *lpOverlaped non-NULL and lpNumberOfBytes equal to zero.
In other words, when the socket is closed (possibly because the peer closed it) you will get what appears to be a successful I/O completion. This does not represent what most would consider a successful return, and if you have not carefully checked the other parameters, your code may mis-interpret this condition.
Another area where you need to be careful when using Windows Asynchronous I/O is application shutdown. There may be a number of pending I/O operations that have been queued to the I/O completion port. It is your responsibility to finish processing all of these I/O operations (possibly by first closing the socket and then handling each failed I/O completion event) and release any resources that were allocated for the I/O operations. Failing to do this will likely result in a memory leak for the application.
The moral of the story is to always read the entire MSDN documentation page and make sure your code handles all of the possible combinations of return values!
Method Swizzling in Safari on Mac OS X
May 9, 2008 | Comments Off
Recently I have been working on an extension for the Safari web browser. The biggest challenge when developing an extension for Safari is determining how to hook your code into Safari.app. Most browsers these days provide hooks to allow development of extensions, but Safari does not.
A technique that many people use to add functionality to Safari (and other Cocoa applications) is called Method Swizzling. If you want to learn more about this technique there is a terrific article explaining all the details on the CocoaDev site.
When applying the method swizzling technique you may find that the linker complains about unresolved classes and won’t link your bundle. This issue usually crops up when you try swizzling a method that is in a class you learned about by running class-dump or by using FScript. If you run into this problem bring up the project properties in Xcode and add -undefined dynamic_lookup to the Other Linker Flags section.
Without this extra flag your plug-in will not link, and you will be stuck in the mud! Thanks to Aaron Harnly, author of Letterbox, for pointing this out to me in an e-mail exchange.
Young Entrepreneurs ship File Manager for Atari 800
May 5, 2008 | Comments Off
The first computer I owned was an Atari 800. While this was not the first machine I worked on (in 7th grade I was using a TRS-80 from Radio Shack to program in Basic and was using an Apple // at a neighbor’s house to play Space Invaders), it was the first machine I had at home every day after school and all summer long!
Here is a photo of what this beast looked like. I had the main unit with keyboard, a couple language cartridges and two of the Atari 810 floppy disk drive units. I didn’t have the printer shown in the picture. 
In order to program this computer I used the BASIC Programming Language. This was loaded into the computer by inserting a ROM cartridge.
The concept of a disk operating system was somewhat limited in those days. If you wanted to move files around on the floppy disks you didn’t have many options. Of course, this meant there was a golden opportunity for someone to create an application to address this shortcoming!
Shareware was all the rage back then so a friend and I set out to build an application that would help with disk management. Of course, back in those days there was no Internet, no concept of registering your domain name, or any notion of taking payments via PayPal. Nope, in those days you had modems and buliten board systems. People ran file BBS nodes using something called FidoNet. Some people had more than one dial-in phone line for their BBS systems. Most only had one phone line, and some had to shut down their BBS systems when they wanted to make phone calls.
Our plan was to build the application and upload it to FidoNet. People would get to use it for free, and if they liked it they would mail us a check for a few dollars. (Yes — using the postal service, a stamp, and a real paper check.) The application was called Disk Master and the company we founded was called Seaview Software.
I don’t have a copy of the software anylonger but did run across a copy of the documentation for our first release.
Cheers!
Software Managers, don’t forget to invest for the future!
April 4, 2008 | Comments Off
The following was seen recently, buried in the responsibilities list of an employment advertisement seeking a skilled Director of Software Engineering to lead a small team developing a new software product.
Make time for continuous re-factoring and improving existing code and unit tests, to keep the codebase clean, maintainable and fun to work on
What makes this so interesting to me is that there aren’t more senior level software engineering positions requiring this sort of investment in the organizations’ future. I really wish more companies would recognize that it is very important to aggressively carve out some fraction of the engineering time in each release and allocate it to re-factoring and improving existing code.
Every place I work it seems like I end up being the sole voice for continuous improvement and refinement within the existing code. It always feels like I’m trying to sell snow removal equipment in the Middle East, or that I’m pushing 10 times my weight up a steep incline.
Anyone who has spent time in Startup Land tm will be familiar with the oft-heard refrain “There isn’t time to do it right, just make it work.” This is destructive on so many levels; to the product, to the team, to the company, to share holder value, etc.
The current mind set is basically to pour as many new features as possible in each subsequent product release and to fix some percentage of the bugs that exist in the system. When architectural deficiencies surface within the code-base management will often choose to defer addressing the issue (i.e., The issue is shelved indefinitely.)
In essence this behavior is a race to the bottom, both for the development team and the product. As more features are added and more work-arounds are implemented to fix bugs the software becomes more and more brittle. This cycle continues until it is impossible to re-factor at all. The inevitable result is a full rewrite of the software or the death of the product as the company can no longer keep pace with newer competitors that are not constrained by this legacy.
I once heard Grady Booch [Blog, Wikipedia], co-inventor of UML, speaking at a conference about the state of our industry. He used the analogy of building dog houses vs. sky scrapers to make a similar point. His position was that without time spent on architecture, object-oriented design and continuous re-factoring it was impossible to build anything as complex as a sky scraper. He recognized that many teams have a grand vision for their software, but unless they embrace software architecture as a discipline they will never be able to stack up multiple dog houses to create a sky scraper. It just isn’t possible. I encourage you to read through his PowerPoint presentation on the topic or view a PDF here.
A significant change in the mindset of software managers is needed in our industry. The lifespan of most successful large-scale software systems is at least 5 years, and many systems are in productive use for decades. To remain agile and responsive as a company the code-base must be re-factored, improved and refined at every step along the way.
Separate Interface and Implementation in C/C++
April 2, 2008 | 2 Comments
I spend most of my time developing software in C/C++, and have done so for many years now. One thing that always catches me by surprise is when I find code written by someone who decides to put implementation details of a function or method in a header file. The only reason I can come up with for why developers would do this is pure laziness.
Let’s face it, C and C++ are such a pain in the but. I mean, each ADT or Class needs two files; a .h and .c/.cpp. It sure would be easier to just lump all the stuff in a single file. Well, since C/C++ can’t generally handle that we might as well sprinkle some of the code into the .h file and some of it into the .cpp file. The compiler really doesn’t care where the code is. And, to top it off, switching between files in most editors takes at least one keystroke. Whoooaaa – what a burden for a busy developer.
Of course, this has been written about by numerous people on the web as well as having been covered by many technical journals and books. The concept is to keep the interface in one file and the implementation in another. I am still amazed to find that people routinely place implemenation details in the header files of C++ classes. All this does is slow down compile times. Some might say “So what, it doesn’t really matter anyhow. The program still compiles.” Well I say life is too short to spend all your time waiting for the compiler to recompile code that it already compiled, and for which there is no actualy reason to recompile at this point.
It all comes down to dependency management. Developers need to understand how the pieces of their programs interact, how that interaction impacts the build speed for the application, and be aware of techniques they can use to minimize the dependencies between components in their applications.
So, why is it such a bad idea to put implementation details into a header file? There are a number of design principles that would suggest separating interface from implementation pays dividens over the lifetime of an application.
When implementation details creep into an interface header everyone suffers. The compiler has to recompile many more modules each time an implementation change is made. Usually these recompiles are completely unnecessary since all the other modules require is the interface definition from the header file. The problem is that the compiler cannot distinguish an interface change from an implementation change when all of the code is packed into a single header file.
By keeping interface and implementation seperate compile speed will improve. On all but the most trivial projects this is an important thing to keep in mind.
