When I first graduated from college, the job market was pretty bad, and most companies were cutting back rather than hiring new employees. A few months before I graduated, I sent out over 100 copies of my resume to various IT and software shops around the area. I got only one call back, and it was from CTI, where I’ve now worked for most of my career. They took a chance on me when I was greener than grass, and challenged me with some very interesting and difficult projects. I’ve learned a tremendous amount about software development and business in my time here, and while there have been ups and downs, the experience I’ve gained has been invaluable. However, a couple of months ago I decided that it was time for the company and I to part ways.

In May of this year, I met Dan Hounshell, Joe Fiorini, and Leon Gersing at the Cleveland Day of .NET, and Dan asked if I would be interested in applying for a position at Telligent. I’ve had a lot of respect for the company and followed the blogs and Twitter streams of several employees, and when he mentioned that they would consider people for telecommuting positions, my curiosity was piqued. At the time I hadn’t made up my mind to leave my current job, but once I did I pinged Dan to see if they might have an opening for a ninja-obsessed codephile such as myself. :)

After going through their interview process (which was very impressive), I’m happy to announce that I’ve accepted a position on Telligent’s Product Development Team as a Senior Software Development Engineer, starting at the beginning of September. The company is based in Dallas, Texas, but I’ll be working remotely from my home in Ohio — which should prove to be an interesting experience in and of itself. (Oddly enough, several of the people in Product Development that work remotely are in Ohio, although as far as I know, only Joe Fiorini is in the greater Cleveland area like myself.)

I’m very excited to be joining the team, and working on some very cool products with some of the industry’s best and brightest minds!

One of my pet peeves are blog posts where the writer says “don’t worry, I’m not dead, I just haven’t posted in awhile.” I promise this won’t be one of those, in spite of the fact that it’s been a few months since last time I’ve written anything.

Work has been particularly taxing for the past couple of months… actually, as I write this, I’m on a flight to Las Vegas for our first field test of the system that my team and I have been writing since the end of summer. It hasn’t been easy, but I think we’ve got a great piece of software. Hopefully, any bugs will present themselves in Vegas, and we can fix them up before we go live in January.

In spite of being difficult, this project has actually been a lot of fun to work on. We’ve been able to use some really interesting technology, and apply it in particularly creative ways. I mentioned the different pieces of software we were using already, but we’ve added some things since then. The product uses handheld computers to capture data, and transmit it back to mobile servers via a wireless LAN. Since the area that the handhelds need to be used in is pretty large, the system is designed to operate “disconnected,” meaning the handhelds can queue messages and transmit them whenever they come back within range. The entire system has to be mobile as well, so the servers are broken down and moved between locations. That means a whole bunch of data migration and synchronization logic, not to mention importing data from existing legacy systems — specifically, manufacturing machinery.

Originally, we had intended on writing two interfaces to the system, one in WinForms, and one in ASP.NET. In the meantime, one of the developers mentioned the absolutely amazing JavaScript library ExtJS. It’s by far the best toolkit I’ve seen for creating rich Internet applications that have the feeling of a thick-client without the bulk. As a result, we ended up wrapping all of the interface into a web site. I admit, working with JavaScript was a bit painful, but I think Ext dramatically improved our efficiency, and made the project work and look great.

The interface was backed by a RESTful architecture written using Castle MonoRail and ActiveRecord. This was the largest project that I’ve applied NHibernate to, and it was amazing how much easier it made the entire development, not having to work directly with the database. We split off some long-running processes into Windows services, which the web site communicates with via remoting. (I would have preferred WCF, but .NET 2.0 was a requirement. For the next project, I hope to dust off my shiny new MSDN copy of Visual Studio 2008 and crank out some C# 3.0… :)

Our final stack ended up being:

• .NET Compact Framework 2.0 SP2 on Windows CE 5.0, with OpenNETCF to fill in the holes here and there
• ExtJS 2.0
• Castle MonoRail, with the Brail view engine, but mostly just for piping JSON back and forth to Ext
• Castle ActiveRecord for pretty much all data access, except for legacy systems (for that, we went straight to ADO.NET)
• Ninject, integrated into MonoRail
• A custom build of Ninject created for the Compact Framework (first time I’ve applied IoC in a compact framework environment… very interesting, and very useful!)

This project has definitely made me re-think the way I develop software. I used to be skeptical of RIAs, but I’m starting to believe that in certain situations they can be a dramatic improvement over thick applications.

Another contributor to my changing mindset is the fact that I’ve been spending my free time (the little of it that I’ve had) learning Ruby and Rails. My wife and I have started to develop a concept, the end result of which is a web site that should launch in the next couple of months. (If only there were 28 hours to a day…)

Ruby is a fantastic language, and working with it has made me become a little frustrated with the verbosity and rigidity of C# from time to time. (In particular, Ruby blocks are friggin’ sweet.) Ruby is the first “dynamic dispatch” language that I can really get behind… I really think it strikes a great balance between flexibility and clarity. I’m no fan boy, though, and I think that the hype does the language a disservice, by distracting from its legitimacy.

I’d love if there was a way to write Ruby for client-side browser code, rather than using JavaScript… :)

Rails is by far the most impressive full-stack framework for web applications that I’ve ever seen. Certainly, it’s not without its problems, but I can definitely see that the buzz has merit. One of the most impressive pieces is the database migration system. Each time we made a change during my “day job” project, I longed for a similar system in .NET. (If someone can tell me how I can bend the space-time continuum to give myself more time to work, I’d be happy to write one. :)

So there it is, my “I’m not dead” post. :) Over the next few weeks, my “day job” workload will be decreasing, so I should be back more often with more inane ramblings!

Whew! The past 3 weeks have been intense. I’ve been in a dead sprint to complete the first release version of a new product at work. I’ve also broken from form and written an application for a web platform. It’s a ground-up customization of Reporting Services using ExtJS 1.1 to drive the interface. Very cool stuff, although I’ve cultivated a very strong love/hate relationship with JavaScript over some intense coding sessions.

Finally, I’ve got a chance to catch my breath a little bit before diving back into the other project that I’m working on. That project is more of a marathon than a sprint, though. It’s turning out to be one of the most interesting projects I’ve worked on to date, and I’ve been able to use a bunch of cool technologies on it. Not only has it made development more interesting (who doesn’t love a new toy to play with?) — it’s also made the team vastly more productive.

The project has a whole bunch of moving pieces. Currently, we’re using, in various sections:

• .NET Compact Framework (handheld computers are fun!)
• RFID
• Data replication
• Web Services
• Windows Services
• Remoting
• ActiveRecord
• MonoRail
• Ninject
• log4net
• iTextSharp
• Quartz.NET

As you can probably tell by the insane amount of libraries, we’ve done a good job resisting the not-invented-here syndrome so far. :) Back to the grind!

I’ve decided to leave my current job at Merge Healthcare and take a position at Commercial Timesharing, where I was previously employed. A lot of things factored into my decision, but I’ve enjoyed my (brief) time here at Merge, and I have a great deal of respect for the developers and managers that I’ve worked with in my six months here. I wish them nothing but the best. I’m excited to return to CTI and work to build their .NET / business intelligence practice.

Wow.

There are moments in life when you think you know everything. These moments are inevitably followed by moments where you realize how little you actually know. Before it became a cheap buzzword, this was called a “paradigm shift”.

I haven’t written a post in over two months. I’ve been more obsessed than usual in the past few weeks with work, both on a professional and a personal level. In my new position, I’ve been tasked with the construction of a framework library using .NET 2.0 that supports the development of new applications, as well as seamlessly integrating them with the existing legacy code. It’s our hope that the framework will be used in all new development efforts throughout the engineering division, so as a result, I’m also doing my best to evangelize the framework and the ideas contained therein.

In order to better understand what’s required, I’ve been “deconstructing” the source from any framework-type project that I can get my hands on, including Spring.NET, CSLA.NET, the Castle Project, the Enterprise Library, and ObjectBuilder. As a result, I’m doing my best to absorb a very large amount of information. I’ve been exposed to a lot of new ideas in terms of software development, and I’ve undergone a major paradigm shift. Inversion of control, dependency injection, aspect-oriented programming, configuration-driven development, test-driven development, domain-driven design, loose coupling via interfaces, the list goes on and on.

I think every developer goes through a series of paradigm shifts as they gain experience. In high school, I was satisfied when I used a pointer in C and my program didn’t crash. (Although, as I recall, I didn’t quite understand the difference between the &, *, and ** operators.) In college, I was satisfied when my program would compile and fulfill the predetermined requirements in the assignment. In my first job, I was satisfied when my program made the client happy and it was deployed and used in the field without too many support calls.

It’s funny, because at each juncture I was certain that I understood how software was written. I’ve always been aware that I was learning new things (and I’ve always been obsessive about finding new things to learn). But it’s only now that I’m coming to understand that it’s not only new technologies that we as developers need to learn. We also have to keep abreast of new ideas and methodologies, and challenge the way that we write software to become better at what we do. We can’t fall into the common trap of saying “it’s always been done this way, so that must be the way it’s done.” To the contrary, we have to constantly ask, “why is it done this way?” and “how could I improve the way we do things?”

I have a great opportunity at my new job to play the role of “architect” and help bring these new ideas to the other developers at the company. I hope to also write about them here, including our successes and failures in using them. (First I need to stop being so obsessed about work!)