Why Linux Sucks

Just to be clear, I have had Linux on my main home computer for several years. In fact, I'm writing this on Linux and I'm not having any problems. I have no intention of giving up Linux. I like how it works and I like tinkering with the different parts of it.

I use Ubuntu. Ubuntu really is Linux for humans - its easy to use and everything just works. Well...almost everything. I installed the 64-bit version and Adobe didn't support 64-bit flash for a long time (and I couldn't install 32-bit Firefox). Seriously, how many web sites use flash? Essentially every site that my wife and I both use. My wife hates Linux.

There's two sides to the Linux community. There are the people who want to see Linux for the masses (Canonical & team) and then there's the hardcore users.

The thing that really gets me about Linux is that the hardcore users have no intention of making Linux easier to use. I usually don't have a problem finding Linux help on the Internet, but the gurus that answer Linux questions aren't particularly easy going. I've spent enough time reading through forums for Linux help that I know that they follow a strict rubric:

1. Always use command line. The biggest thing is installing new programs and packages. They could easily tell someone that they need to install package x, but instead they always use the command line:
   

   sudo apt-get install destroy_linux
   

   Seriously, why can't you just use the pretty UI that Ubuntu  created for installing software? I know they are easy commands, but seriously. Not making things easy for my wife.
2. Always make things more complicated than necessary. Usually this involves using the command line with three times as many commands than you really need. But also chastising for silly questions
3. Keep things magical. Magical lands are fun at Disney land, but I hate punching in inexplicably terse text into a console. The terms and commands become shorter and less descriptive as you get deeper into Linux (there is no end). Don't try to understand.

There has always been this expectation that eventually everyone will cling to Linux and reject Windows. I think that day won't come until most of the Linux kernal development team & posse have died/started using Windows. The problem with Linux is, and will continue to be for the foreseeable future, it's users.

Object-Form mapping

I'm pretty sure most developers (web developers anyway) have heard of ORM (Object Relational Mapping) tools like NHibernate that map your database tables and to objects. These ORM tools reduce interaction with the database to just a few method calls, many times just Save(), GetById(), and a few custom query methods. There's a lot written about ORM, but no one really writes about the mapping between HTML forms and the objects that ORM maps.

ASP.NET has a great solution for OFM (I'm calling it OFM because google won't give me a real name for it). If you use a FormView in combination with an ObjectDataSource you can bind the properties of your object to form elements. This is pretty cool because it reduces your code to writing an ORM mapping, creating factory methods to get and save the object, and some ASP markup that maps the object to HTML elements.

I was playing with Ruby on Rails which has a somewhat different approach to OFM. Basically you write regular HTML and give your form elements names like "account[id]", "account[name]", etc. This seems like a little more work than the ASP.NET way except that on the server side it uses this notation to wrap the query string into an object that can be referenced in object notation from ruby code like "account.id", "account.name", etc. I believe PHP does something similar. I like this method because it's very light on HTTP - there's no obstructively bloated view state being passed around like there is in ASP.NET and you can pass several objects through the query string.

Basically, OFM manages some of the page flow by marshalling form parameters into objects that can easily be passed to a factory method. This is awesome because it means I can focus more effort on writing unit tests for business logic that has no dependencies on the web API. It allows me to to keep page flow simple and sets up business logic for creating restful web services (seriously, you could just slap [WebMethod] attributes on the factory methods and voila you have web services). There seems to be a lot of framework that goes into managing OFM, but oddly I don't think many people have addressed it directly as a problem that needs to be overcome (I assume this is because the MVC architecture is supposed to address this; unfortunately vanilla ASP.NET isn't MVC).

I recently pulled most of my hair out over the ObjectDataSource and interfacing with factory methods. In the future I want to write a post about how I got around it (and another one lambasting Microsoft for even attempting to release an API as thoughtless as the ODS, but seriously, more on that later).

Why we chose Git instead of Subversion

I just got a new job as an ASP.NET developer at a small company that is freshly developing itself into somewhat of a software company. The development team is undergoing a ton of changes over the past 6 months (6 months ago there were two developers, now there is five as well as a new director of technology). As part of our changes we took some time to evaluate the tools we use. We had been using Microsoft's Team Foundation Server for source control and a home-grown system for bug tracking but after our evaluations we settled on Redmine and Git.

The fact that we are using Redmine for ALM and bug tracking isn't particularly surprising to me because it's a feature heavy and mature product that is very natural to use. There are several other feature heavy mature ALM tools that would fit us, but none that are free (I don't consider Trac feature heavy). Git, however, is a bit of a pleasant surprise for me.

For the uninitiated ones, Git is a distributed SCM (source control management) tool. The distributed part  means that it works kind of like Subversion except that everyone has a full clone of the repository. When you want to check your code in you commit first to yourself and then push your changes to the rest of the team. More realistically you would be committing to yourself several times and occasionally pushing your changes to the rest of the team when you verify that your code is stable.

The benefit of this is that you can maintain your own personal branches of the code where you experiment on certain features without having to push them out to everyone else. I see this as psychologically breaking down the barrier to committing code. I often find that I don't commit code for a while because, even though it builds, I'm not sure if some of the pages will run without errors. However, committing to myself means that I can commit whenever I want and not slow any of my teammates down with potential errors.

Git also provides very easy and simple branching. They made it extremely easy to drop everything your doing to fix that top priority bug in production (the "stash" operation lets you save uncommitted changes and move to another part of the code). With this extra change management, Git also forces you to account for all your changes. Before you switch branches you have to either stash, commit or revert your current changes. At first this seems annoying, but on second thought it forces to always have some sort of accounting for why you changed stuff.

We did have some hesitation with changing to Git. Our biggest concern was if one of our partner teams from a different company could keep up with a change in SCM. After some evaluation we realized that Git provided so much flexibility with managing our workflow with this partner that it makes Subversion look like an archaic hack.

Another concern we had was stability. Git itself has been around since 2005 and seems to have pretty strong development community backing it. It has a very strong Linux following and a year ago lacked a good Windows interface. However, TortoiseGit has been developing at a very rapid rate (it's single developer has been releasing more than twice a month and is quickly working toward supporting most of Git's features). Because it is developing so fast we agreed that we could disregard shortcomings in the Windows environment in due to the awesome number and power of the features it brings.

Today I worked on importing our TFS repository into a Git clone. I found a PowerShell script hosted on Github that got me pretty close. The code in the script was a little too brittle so I made the code a little more generic and sent it back to him. It's taking about six hours to migrate the 1200 changesets into Git, so the script probably won't finish running for another couple hours, but I think it's working so far.

I will have to follow up in six months or so with an evaluation of how things have gone.

CouchDB + Ext as a Replacement for Server Code

In a previous post about ExtJS I mentioned the possibility of developing a web application that runs entirely inside the browser and doesn't require any server side code. The idea stems from a) ExtJS is a fully capable widget framework and b) CouchDB is accessible via a web service. At least 80% of web apps are just a HTML interface with a database back-end and a little bit of business logic. So why can't we move all that business logic to the browser, setup calls to a CouchDB web service from the browser and 86 the server-side code? In this post I'm going to analyze this question and see if it's realistic. In a follow up post I'm going to analyze this same question from a business standpoint.

A Database Void of Schema

CouchDB is a document oriented database, meaning that it doesn't have tables and keys like you do in relational databases. It just has one big space full of documents. A document in CouchDB is a JSON object, so its attribute values can be strings, booleans, numbers, lists, or other objects (documents). Having complex "rows" means that many of your relationships that you would normally form by using a second table and a primary-foreign key set is simplified down to embedding a list. Consequently, 1-to-1 and 1-to-many relationships are native to the database and require no extra thought or planning. Many-to-many relationships are more complicated, so this approach might break down if you require too many of these. Some other oddities in relational databases like versioning and pivot tables come native with CouchDB. Since the bulk of our database requirements are made easier with CouchDB, querying is going to be generally simpler.

The other great thing about having a document formatted in JSON is that you can save any JavaScript object directly to the database. You could save the state of an Ext widget or a whole form. It's like simplified object serialization for the browser! This is definitely a killer argument for making fat client apps with Ext.

But What About Performance?

At some point, someone's going to ask it. I say, Twitter uses it, they seem to be doing well, there's one case that its proven itself. The biggest argument for CouchDB being a scalable database is the fact that it is built from the ground up with the intent of being distributed across many nodes in a cloud. So while it is easy to get a database stood up for development, it's just as easy to move that database into a highly distributed cloud with hundreds of nodes. This makes it easy to develop scalable world-class apps like Twitter or Google.

CouchDB uses a type of index that is based on the map-reduce algorithm used in functional programming. You define a function in JavaScript that takes a list of values and chooses which ones to include in a view. When you want to query the database you just ask it for all or part of a view. Because it uses the map-reduce algorithm to index, it's agnostic towards when and how many documents are indexed at a time. So documents can be quickly indexed on insertion/creation, or the whole database can be indexed at one time.

If the client code is developed entirely in Ext and JavaScript, all forms are static HTML pages, so the server can easily respond to 80% of requests with little more than a few HTTP headers (client-side caching).

What About Security?

At this point someone must be ready to blurt out something about this being an incredibly insecure approach to web development. After all, any slick hacker can modify the JavaScript code and execute arbitrary insertions/deletions. Security is definitely going to be a lot bigger of a concern in this case. However, CouchDB does provide fine grained security controls. Here is an informative video about CouchDB security controls.

The big difference with designing security into couch apps is that security is going to be built into the database instead of the application. CouchDB provides constructs for users to be part of roles. If constructed well, the developer can leverage the database to deny or allow certain operations for the current user.

Taking the Ext + CouchDB approach is going to be a fundamental shift in application design. If we learned to write apps like this we might actually learn to rely on the framework to do what it does best, and let our app do only what it needs to do. We might even find ourselves making stable and secure apps in less time.

Conclusion

From a technical perspective, I think this might be a very feasible design paradigm. In a coming post I am going to talk about the business costs involved. However, I think document oriented databases might be something I want to investigate further and design into future applications.

Playing With ExtJS

I've worked with the JavaScript framework jQuery before and I've heard of Ext JS but I wanted to try it for myself. Essentially the main difference between jQuery and Ext is that while jQuery works great tacked on top of other JavaScript frameworks like ASP.NET or JSF, Ext is more of a replacement for those frameworks. Coding in Ext feels like Swing or Windows Forms but for the browser.

Since Ext forms live completely inside the browser's memory space there isn't a postback every time you click a button or expand a tree node like there is in ASP.NET. I think the delay from a postback makes the user experience feel choppy, especially if you don't have a fast internet connection. ASP.NET makes it very easy to hook into any DOM event, but since these event handlers live on the server, hooking into these events causes a postback which in turn causes the whole page to reload. Moving all this event handling logic to the browser makes the application seem a lot faster.

Since it requires so much JavaScript coding (and so little HTML coding), you should invest in a good JavaScript editor. Ext Designer is a WYSISYG drag-n-drop editor for Ext controls. The pricing seems kind of steep to me, $219 for a single developer license, but I suppose that if you're going to use it a lot then it's probably worth the money. Take a look at the screenshot of Ext Desinger below.

There's a list of controls on the left. You drag a control onto the form, re-size it, edit its properties and preview the whole form. It's very easy for laying out the form (especially if you're not familiar with Ext). You can even setup all the data sources (AJAX calls) for controls, like the grid or the tree, and then preview the form with real data. The major shortcoming is that it's only a UI designer - there is no integrated code editor. You have to export the project to add all the program logic and event handlers via another editor like Eclipse. On the other hand, using the designer in conjunction with another editor isn't particularly difficult if you have the designer project saved in the same folder as the rest of your application, its just a little painful to have to switch between applications, I suppose.

This being my first experience with Ext I have to say that I'm relatively impressed. JavaScript has come a long way since the days of dial-up modems and table-layout. With the dawn of efficient browsers and HTML5 I think creating true fat client web applications is a reality. In a follow-up post I am going to talk about CouchDB and how using Ext with CouchDB could possibly replace the need for server-side code altogether.

Why I Decided To Start A Blog

I strongly believe that for every avenue of life that we enter, we should leave it a better place. So for every job that I take, my goal is to leave a more efficient or more powerful work group behind. By blogging I can bring up issues that I come across, and if I also bring up solutions to those problems I can give other people the chance to learn from my experiences.

I also believe strongly in open source software (OSS). I wish there were more companies like Google that invest a lot of capital in developing OSS. From a business standpoint, when considering investment in public resources like OSS, it is hard to see the ROI. I think Google has done an exceptional job of finding revenue from OSS, and I think that is positive for the world.

Blogging is similar to OSS in the way that blogs are a public resource and they're written by regular people in their spare time (I wish I could be paid to develop OSS). I read a lot of blogs from other technical people. Some of them I follow regularly, others I end up inadvertently reading by googling for some technical problem. Blogs are free content that adds value to our lives.

Starting a blog was a result of a lot of thinking. It's been bugging me for a while that I read all these blogs and I don't write one. I think its important to give back at least a portion of what you consume. If you don't like what I have to say here you don't have to read it. What I say here won't waste anyone's time or clog their inbox without their consent. Since this blog can't ever be a burden on society, it can only add value. So in that line of logic, this blog is necessary.

Incidental Inversion of Control

This morning I started reading about the Spring Framework and, as usual, I followed a rabbit hole to learn what the phrase Inversion of Control (IoC) means. IoC is also known as the Hollywood Effect ("don't call us, we'll call you"). A lot of programming frameworks use an inversion of control to take care of the bulk of the work and leave your code to perform its task (and only its task).

Most web frameworks are a good example of IoC. In Java web applications, the framework takes care of all HTTP complexities and turns control over to your servlet or JSP when the time is right. This leaves your JSP to process the request and return a response - easy! The ASP.NET framework has an excellent inversion of control with its postback model. The framework allows for applications to be built very similar to Windows applications - the underlying framework takes care of display issues and calls parts of the applications code when the time is right. A lot of these calls to code are handlers for events like Click, Load, and others.

As I read about this "new" concept I began to realize that it wasn't new at all. ASP.NET and J2EE use it extensively. In fact, I have created such a framework without realizing what I created. In the middle of last year I created a pluggable scheduler interface for our eQube environment that allows the programmer to simply specify report names and filter values via XML, and when it comes time to do something special, the programmer can hook into events and have the framework execute some JavaScript code to do something special.

I stumbled into creating this framework after doing several short projects that required some boilerplate code to interface with the eQube APIs. It all happened quite innocently, but having taken the incidental route to IoC framework I have gotten much more value than I thought I would. For instance, it is suddenly very easy to run a report with 400 different filter configurations. I just put together some XML to spec the report and throw in a block of JavaScript to change the filter values. The inversion of control takes away most of the responsibility and leaves me to do my job, and only my job.

After today's lesson in inversion of control, I'm brainstorming new ways to use it. Perhaps even consolidating my other code into the scheduler framework, or maybe integrating it with the spring framework. As always, there's power in doing less.