Don't Overestimate the Cloud and Nvidia's Kepler Chips

I saw this article the other day talking about Nvidia's Kepler chips and how they will "serve up a desktop experience from the cloud". This whole idea is crazy to me.

Don't get me wrong, I'm sure the Kepler chip is awesome. Based upon what is said about the chips themselves, they seem to have some massive power behind them, and they will be incredibly helpful in software where you can make use of the GPU. I just don't buy in to the whole stream your desktop from the cloud idea.

The premise is just a bad one. What happens if your network is down? What happens if the cloud goes down? What happens if you have some latency issues? Network is slow? Bandwidth caps? You get the idea.

Then Rob Enderle takes it a step further and asks "what if you could run Windows on a Mac, or an iPad, or anything that would host a tiny client". Another terrible idea! I've used remote desktop software to access a windows desktop from my iPad, and it was not a great experience. Windows is not built for touchscreens. That is the whole purpose behind Metro for Windows 8. Microsoft has already tried that, and it didn't work. Also, if you want to run Windows on your Mac, you can. Use VMWare or Parallels or any other virtualization software. You could even use Bootcamp and have a full install to go to.

The concept of having a central operating system with a thin client on your device is a great one. There are just too many problems with it. I think having a central server with preferences that sync to devices is a better idea. That way you can store the preferences on the device, and they'll update when they can. This is the same concept behind iCloud and Dropbox. Dropbox is specifically for files, of course, but it has been used that way for BBEdit's preferences. Using this sort of setup means your device isn't useless when the internet is down. Not being able to play Angry Birds just because the internet is down would be incredibly frustrating. I was always mad when I couldn't play Half Life because I couldn't get on Steam.

Later in the article Rob Enderle does get in to some use cases that are great. Modeling galaxy class events where you are tracking millions to billions of objects over a billion years. This kind of computation can be of enormous use to scientists. The datasets that are being worked with now are on that kind of scale, so a chip that can process them quickly is great.

Finally, Rob Enderle goes into possible use in robotics. This is another frontier that can use this sort of processing power. I personally believe in order to make AI approaching our intelligence we will need massive parallelism. The human brain is performing hundreds if not thousands of concurrent "threads" to keep us alive. A robot will need the same amount of computation to stand, walk, and talk.

Looking to the future of what we can do with our most advanced technology is great, but you have to stay realistic. Robots and massive dataset modeling are feasible. Streaming operating systems are great, but we just don't have the infrastructure to support it.

The Pitfalls of Object Relational Mappers

I just read Martin Fowler's ORMHate post, and I must agree with him. I was skeptical the first time I used an Object Relational Mapper, but once you get used to them, they are fantastic.

Just a brief review of what an ORM is. The basic function is to convert a relational table database into objects automatically for use in your application. So your user table with it's associations to user posts (for instance), can be turned into a user object with the ability to fetch user post objects. This is great, because it avoids the need to spend large amounts of time creating repetitive code to access your data and turn it into objects. As Martin pointed out though, you do need to put in some time to make it work exactly right with your database. Once you have this interface, you can create an application much faster, because you don't have to spend so much time building the base access layer.

I do think that Martin missed a few points that are important though. There are several pitfalls that I have seen that a developer needs to be aware of.

The first and most important, in my opinion, is being aware of what the provided calls actually do with regards to the database. For instance, how exactly does the count call work? Does it get all of the objects from the database and then count them, or does it use the built in count function in your database? A good ORM would use the latter, but developers should find out for sure. Another example, and unfortunately I can't find the article, comes from an article I read about someone profiling their application. They noticed there were two nearly identical calls to their database. The first was to find out if there were any records meeting a certain criteria. If there were, then the second call would fetch those and return the data. Obviously, you're making two calls for the same data, but they didn't know the check worked that specific way. The solution ended up being a flag to tell their system to return an empty array when no results were found, instead of false or null.

A second pitfall would be forgetting how to write basic SQL or just interact with a database. I think all developers that are writing code interacting with a database should feel confident working in a SQL command-line. Not for bragging rights or anything along those lines, but because it will help you write better queries. Knowing how long your queries take, how your database is actually laid out, and what unnecessary data you may be getting can lead to optimized queries, saving money. If a developer can use the database less or at least more efficiently, the database doesn't have to scale up as much. With one of the clients I worked on, I was able to take another developers query from 5 seconds down to 200 milliseconds by removing a join that was unnecessary in a certain context. That's a huge savings in resource usage. (The 5 seconds mainly comes from an awful database design, but that's a whole other post).

One final pitfall is when your original developer leaves, and the existing/new developers are only left with an ORM. They may have little understanding of why certain database design decisions were made, or be completely unaware of them. Again, I encountered a system that had two ways of determining whether a user was on the email list. One of them was a legacy from before even the previous developer, but I wasn't made aware of it when he left. The obvious opt in flag was inaccurate for those accounts. Confusion ensued, because the ORM did not account for those columns. They were set to not be included in the models. Suffice to say, I thought they were deprecated/legacy and had already been dealt with. Surely they were just there because no one had bothered to drop the column. Not to mention the column name was less than descriptive. This could all be written up as a lack of documentation, which is true, but it is still something that should be taken into account with ORMs.

Definitely don't take these as reasons to not use an ORM. They are well worth it. These are just warning signs on the road to make developers aware of things to think about. "Bridge ices before road" seems obvious, but you would be surprised how many people don't think about it.

My Reading - A Book Apart

As you can see, I have some reading ahead of me. I finally got around to ordering the A Book Apart books that I wanted, now comes the time to read them. I'll be posting reviews of each as I finish them, and I'm hoping to learn a lot.

Start Your Startup in International Waters!

I may be a little late to the show, but I just read about Blueseed the other day, and I had to say something about it. It seems that some startup founders are frustrated that they can't get the best people in the world working for them, because they're having trouble getting Visas for them to work in the United States. In order to solve this, someone had the amazing idea of just doing business in international waters. The plan is to get a cruise ship and load it up with entrepreneurs. Then sail the ship out to sea and start business.

The first thought that came to mind for me was how crazy these people are, but the more you think about this, it starts to make sense. I assume getting a US Visa is difficult. I've read about difficulties, so I assume this to be true. However, if you look beyond that issue, there are other reasons why this is an amazing idea. Imagine you are working on a new company, and you are facing difficult problems. Who do you want to be surrounded by? Possibly other people doing exactly the same thing. Maybe people that have already been through the problems your having. Maybe even someone that is building a company to solve the very problem you're having.

Blueseed seems like it may actually be entrepreneur nirvana. Come out on a cruise and surround yourself with highly-driven people. People that are trying to accomplish great things. People that have high expectations of themselves. People that you can learn from, and people that you can teach. This takes the idea of a startup incubator to a new level.

If I had a company that needed this, and I had the money, I would sign up in a heartbeat.

Node.js - I don't get it

I have read a lot recently about Node.js, and it seems to be the flavor of the week right now. The gist of Node.js is that it is Javascript on the server, and it uses a "event-driven, non-blocking I/O model that makes it lightweight and efficient". That probably doesn't mean a lot to most people, even many programmers. Suffice to say that when you run a command, you don't wait for it to complete, hence "non-blocking".

As an aside, I'm going to completely brush over the fact that Javscript is slow. Let's pretend it's as fast as other web languages (it's not).

At first glance, that seems like a great way to write software. Waiting for a disk is the slowest action on a computer these days. The typical time scale for a call to the harddrive is at least a factor of 10 slower than other commands. That's exactly the kind of thing you would want to avoid. Here comes the pitfall though, didn't you make that call for a reason? Don't you need the result of whatever you just asked for?

After reviewing every web-app I've ever written (or at least the ones I remember), I couldn't think of any instance where an intensive call was made that didn't require the result. If I make a call to a database to get some data, I'm planning on using it and displaying to the user. So that begs the question, when would you not care about the function result? I can only think of a few instances.

The most obvious are calls where you are logging information to non-volatile storage. Let's say I update my account, you may want to log what the previous values were and the new values. This gives you a "paper" trail to follow. While this is a legitimate use, I can shoot holes in it as well. Should I really completely rewrite my program for something so simple? Why not just make sure the logging system is fast? SQL Inserts are fast. Increase the RAM on you database server. Make sure your database is tuned properly. Queue your logging calls so they run after you've finished output and flush the output buffers.

Another would be when using WebSockets. WebSockets are great, because they give you a persistent connection to the server. So requests can flow in real-time, rather than on a polling schedule using AJAX. Running Javascript on the server and client side would also make sense. You can easily pass JSON back and forth as needed. The main problem here is that WebSockets are currently only supported on three browsers. Going beyond that, what data are you actually going to be passing? Primarily data going into a database most likely. Here we are again, stuck waiting on a database, but this time we have to have the result. So I'm not speeding up the request time, I still have to wait for the database to return data. All Javascript gives you is some horrendous code. I've heard it referred to as the "pyramid of death". Basically you get buried in callbacks, giving a pyramid shape like so:

getData(param, function() {
    processData(param, function() {
        sendData(param, function() {
            ...
        }
    }
}

Now just imagine that actually did something useful. You can easily see how bad things can get.

Those are the best examples I can come up with for a time when Node.js might be useful. It was even talked about at the ConvergeSE conference during one of the workshops. I came away feeling as though all of my complaints had been validated. The speaker showed some interesting applications, but none of them needed to be in Node.js. They could have been in Ruby, PHP, Python, C#, etc. I've even spoken to people that have used Node.js in production, and they openly admitted that it was a complete mistake, and they were working on replacing it. Turns out, it was slower than Ruby on Rails.

Either way, if someone can show me a use that makes sense, I'll be glad to look at it. In the meantime, Node.js is just a hip fad being pushed by people that want something new to talk about. People that like buzzwords, in this case "non-blocking", "event-driven", and "real-time".

I'll close with a wonderful video summarizing the problems with Node.js with humor. Also, a little NSFW due to language.