I’ve been working on Fluent JDF, an open source .NET library for authoring, navigating and transmitting JDF, for the last several weeks. I just posted an article on how to get started over at the JDF blog.
My passion is building systems that tie together supply chains. For the last several years, I have focused my efforts on the commercial printing industry and the industry’s integration standard, JDF. As my company gets closer to releasing FluentJDF, an opensource JDF library for .NET, I will be posting on JDF tools and techniques at the JDF Blog. I will continue to post here on general programming and entrepreneurship.
I am only getting started with NServiceBus after having used Rhino ESB for some time. Overall, I’m liking the functionality. However, at least in the 2.5 release, configuration is a little sensitive and often doesn’t provide any useful information when things go wrong. Take, for example, the following configuration for a web application:
NServiceBus.Configure.WithWeb() .XmlSerializer() .Log4Net() .CastleWindsorBuilder() .MsmqTransport() .IsTransactional(false) .PurgeOnStartup(false) .UnicastBus() .ImpersonateSender(false) .CreateBus() .Start();
When you put in this your Application_Start method it throw a null reference exception in the NServiceBus configuration routine. As it turns out, the code was supposed to look like this instead:
NServiceBus.Configure.WithWeb() .Log4Net() .CastleWindsorBuilder() .XmlSerializer() .MsmqTransport() .IsTransactional(false) .PurgeOnStartup(false) .UnicastBus() .ImpersonateSender(false) .CreateBus() .Start();
Did you spot the difference? The issue is you can’t tell it which serializer to use until after you tell it how to configure the container. Seems kind of fragile if you ask me. This certainly doesn’t make NServiceBus a bad library, but it does make it quite a bit harder to get started. Anyway, thanks to this being open source I was able to debug into the offending routine and figure out what was going wrong.
After using FitNesse for the last several months I can say the following:
- The documentation is quite limited especially when it comes to working with .NET. Lots of trial an error involved for any novice.
- How lucky am I to have Mike Stockdale, the principal developer of FitSharp, working on the project to show the team a variety of useful tricks? I don’t think we would have been successful with FitNesse without him.
- Technical product owners are able to write and troubleshoot their own tests using the wiki once the right test fixtures are in place. Very nice.
- Integrating FitNesse with TeamCity is easy as long as you don’t care about integrating the test counts. Wrote a little MSBuild step that takes care of this. Note to self: document and release as open source to help others.
- Integrating FitNesse with TeamCity’s built-in code coverage has proved impossible thanks to the tests running under Java. Oh well.
- Database setup and FitNesse add substantial overhead to the acceptance test suite so it take several minutes to run. Our extensive unit test suite remains fast partially because integration/acceptance tests run under FitNesse so this is not a big deal.
- I have looked at alternatives like SpecFlow but remain convinced that FitNesse is about the only automated acceptance testing tool that is approachable for non-programmers. For example, although most product owners can write Gherkin specs for SpecFlow, I don’t think they could easily run and troubleshoot tests like they can with FitNesse. Therefore, I will continue to use FitNesse for acceptance testing on future projects.
I just built a developer station for the company with specs substantially identical to the one I built for personal use a few months ago with an I7950 processor, 12GB RAM, 240GB SSD main drive, 1TB storage drive, and a Radeon HD5770 graphics card. I economized a bit by going with an 800 watt power supply, RAM not suitable for over-clocking and a cheaper case. The net result is a cost of less than $2,000 including a whole bunch of extras I didn’t have to buy for my personal computer like three brand new 23″ flat screens, DVI cables, UPS, keyboard, mouse, webcam etc. Apples to apples, it was about 33% less expensive than my last build. Amazing how fast computer prices fall.
I took the plunge and bought the new Xoom Android 3.0 tablet four days ago and so far I am generally impressed. That’s not to say there are not substantial flaws like applications that don’t know how to handle the large screen (e.g. Mint), applications that don’t yet match their iPad counterparts (e.g. Skype without video support) and applications promised and not yet released (e.g. logmein Ignition and Flash). However, the good outweighs the bad. The tablet is fast and responsive, the built-in applications for web browsing, email and calendar are excellent and the screen is very good indeed.
I can certainly see myself traveling with the Xoom instead of a laptop as long as I don’t have to do heavy-duty development. For example, I was able to access a development environment hosted at Amazon with EC2 via RDP to do a little test, fix and patch for a C# application over an average broadband connection without the benefit of a Bluetooth keyboard. Although I would not try this with the current 3G wireless, I fully expect Verizon’s 4G (upgrade available soon) to be fully up to the task.
On the negative side, quite a bit of the potential of the Xoom is untapped right now. Besides 4G, early adopters will have to wait for Flash, support for the Micro SD slot and versions of popular applications that take full advantage of things like the front-facing camera and the large screen. Although overall stability is good, I did experience problems with some popular applications such as Skype and Mint.
Developing for the Xoom has been a good experience so far. I use Intellij with the Android SDK and developing against the device has been trouble-free. The emulator, on the other hand, is ridiculously slow even when running on my otherwise fast I7-950 desktop. For example, I experienced waits of up to three minutes when starting a simple hello world application on the emulator. I can’t quite understand why it has to be so much slower than the emulator for the phone form factors.
If you want to develop for Android tablets or hate big-brother Apple, you will be happy with the Xoom tablet as it exists right now. However, average users would probably be happier with an iPad 2. It is lighter and thinner, has more applications available and has a better UI. Although the Xoom has slightly better hardware , right now the software is a bit too rough around the edges to recommend an Android tablet over the iPad 2 for average users. I fully expect open source, hardware competition and Google to eventually trump the iEmpire, but for now Jobs and company still come out on top.
I wrote the original version of this post on the Xoom. Unfortunately, the open source WordPress Android application chopped up several of the paragraphs and inserted block quotes seemingly at random. I guess there is at least one more application in need of an upgrade.
Many of my projects end up using a Windows service or three to host background processes. Over the years, I’ve developed a common-sense strategy of setting up a server class to contain the functionality that implements start and stop methods. I then create minimal command-line and windows service hosts to instantiate the server class and call start and stop when appropriate. This gives me a command-line server that can be conveniently started from the debugger and a windows service application for use in the production environment. Of course, this also means using InstallUtil when it comes time to install the service.
Today I stumbled across a much nicer solution in the open source TopShelf project. It lets me build a console application using about ten lines of code that hosts my server for development and provides a command-line to install as a Windows service so InstallUtil is not required. Highly recommended!