Apple vs. Google == Consumer Wins

How quickly we forget. Robert X. Cringely states:

Having been shown the way by Apple, I expect Google to shortly do the same thing, adding automated backup, synchronization and migration to Android and Chrome.

Uh, didn't Google show off new hardware support for doing just that like a month ago? Chrome OS is completely networked. There's no local installation of anything. The next logical step for Google is to enable that capability on a phone. You login to the phone's hardware with your Gmail address and boom, the phone has your phone number, your apps, your music, all ready to go. Log out of that phone and into another one and all of the connections, apps, and data are there again. **Note** This capability doesn't exist, but it is what I believe to be the next logical step forward for Google.

Google and Apple are having some fun. Each are taking turns innovating solutions and improving existing interfaces. Apple's new notifications are an improvement on Google's notifications. Eventually, the two will drive each other to implementations that please their users. For example, I would love to see the notifications get screen realestate on the Android lock screen.

Google has the pieces to compete. It is just a matter of putting them all together in a cohesive way that improves the lives of their users. They have to figure out how to make it seemless. Apple has figured that out and shown their path forward. If Google hasn't already defined a path forward, they will be working on that now.

Apple's way forward is the most integrated and simple solution to a problem many people have. Everything they are doing with software and services sells more hardware. Giving the non-techies avenues to keep their data backed up and access it from anywhere will sell more hardware. The cost of the software is embedded in the hardware. Apple took the cellular industry's strategy, tweaked it, twisted it, and now are profitting like no one else.

From the phone

More than likely this will be my last post from my EVO. I am planning to get the Motorola XPRT and I will be able to post more since it actually has a keyboard.

The future looks bright!

Speed up your counts in Rails 3

Just bumped into this and thought I would share. If you are trying to find the number of records that match two columns in your schema you might do this:

find_all_by_some_column_and_some_other_column('val', 'val2').count

What this does is select all of the data that matches and then does a count in Ruby. This is slower because it retrieves all of the data for every matching record. Whereas if you count like this:

where(:some_column => 'val', :some_other_column => 'val2').count

It will do the count in the database (which databases are really good at) and only return the total number of records that match. If you have 12 records it won't matter much which of the above you use. If you have 12,000 records the second will be incredibly faster.

5 Alternate Uses For GMail

GMail is the ultimate email client. Humorously, the capabilities that are so great for email actually enable several other "features".

1) Note taking - Any time I think of something interesting that I may want to remember, I write myself an email with the subject starting with "howto:". A couple that I visit often are "howto: make SEO work", "howto: deal with meetings" and "howto: amuse users while they are waiting"

2) Bookmarks - I never could get into sites like del.icio.us. Something about going to another site to create a bookmark just didn't make sense. I tried to use the bookmarklets and the browser plugins, but nothing made sense. Then one day I searched for a note that I knew had a link in it because I wanted to find the link. That was when I started sending emails to myself with keywords in the email to help find the link.

3) To do's - To do's are just short lived notes. I almost always delete them after they have been completed. For some reason actual to do lists or to do list software (web based or fat client) just doesn't work for me. I have started to believe that I have to-do-list-ophobia. But if I send myself an email then I am impacting my zero inbox beliefs so getting that to-do email out of my inbox is a priority. Also, I am always checking my email so the to-do is always available, whereas if the to-do list is in software, I have to actively go looking for it. To-do's even have their own tag with the most annoying color combination.

4) File transfer - I can't count the number of times I have used GMail to transfer files from one computer to another. I have emailed songs, books and of course word documents. This "feature" may seem weak, but I would argue it is so strong that you don't even know it is is a feature. You just expect email to send files. Heck, when Gmail came out one of the first things people tried to do with it was put a file system on top of it. Of course everyone is using dropbox for this now, but I still use GMail from time to time.

5) Tell me about your alternate uses for GMail!

Why Ruby and Rails?

"Why should we use Ruby and Rails?" has been popping up at work over the last month. Managers are worried about retraining the Java developers. And the Java developers are worried about wasting their time on some fad. Here are my reasons why you should be using Rails to build a web site.

First, Rails is a web framework, nothing more or less. It claims to do nothing but allow developers to easily create websites. It makes hard problems trivial and impossible problems doable. It claims a 10x improvement in development time. That claim is VERY DIFFICULT to believe, so I will address it later with examples from my current project. Rails should be thought of as a Domain Specific Language (DSL) for web applications. Writing templates or views of web pages is eased with many helpers.

Think of scriptlets in JSPs, but terse code that makes sense. The helpers range from creating links to creating whole forms. All of this goodness is packaged up in an MVC pattern. Unlike Struts, which also claimed to be MVC, there is a single layer for Controllers; each layer is contained in its own directory. Another benefit is the directory layout is standard. If you know the directory layout, every Rails application will be familiar to you. This is a big benefit after you have switched to your upteenth Java project which has it's own directory structure, completely different from all of those that came before it.

Second, you get RESTful web services for free. I can't stress this benefit enough. When you use the generators for Rails you get the server side of a the web service. Building the client is trivial. Remember I said I would prove the 10x improvement in developer time? We are building an application which will have many clients. The clients are mostly Java, so a developer was assigned to write the client for the RESTful Rails application. He decided to write a parser in Java. This took a couple of weeks to write and test. And from time to time we find new bugs in the code.

However, we could have written three lines of Ruby that would have done the same thing. I literally implemented the same thing he had been working on for two weeks in 10 minutes. 8 of those 10 minutes were trying to find the documentation on what needed to be written (sadly when I showed him the Rails way he shrugged and said, I know how to do it this way and I already have this time spent on it. Maybe I should have explained sunk costs). 10 minutes vs 2 weeks, 10x improvement in speed might be an understatement. This isn't the only way Rails improves implementation speed. Writing database queries are a breeze.

Rails comes with its own Object Relational Mapping (ORM) tool called ActiveRecord. Similar to Java's Hibernate in functionality, ActiveRecord improves development by making complex is easy. Rails provides generators to create scripts to create tables in your database of choice (support for many databases is provided including MySQL and Oracle). The generator also creates a Model class for each table you have in the database. The Model class is where you write the code for business logic and any methods needed to access the data. Except, you don't need to write much because Rails provides many access methods without the developer needing to write any code. Rails also helps by providing helper methods to create relationships between objects. ActiveRecord provides support for one to one, one to many and many to many relationships with just a single line of code in each Model class or two lines of code in each Model class for many to many relationships (technically you can do many to many with one line of code in each Model class in the relationship, but that method has been deprecated in favor of the more flexible two method approach).

The last time saving feature of Rails is that you can use Ruby gems in your web applications. Gems are like Java's jar files, they are packages of code that can be thought of as a library. Gems easily support dependencies so having a Gem that requires ActiveRecord is easy to create, which means you can create Gems that natively work in Rails applications. Need a User object in your application? Download one of the many authentication gems available on the web. Find the one that suites your need, install it and you are ready to go. Need to upload files? Install a file upload gem. This capability is available in Java applications too, but for some reason they are more complex.

Finally, Rails is a simple and easy way to get a web application up and running. A developer can finish a week long Rails course with enough fundamentals to be ready to go write a Rails application.

Product Development Lesson: Abigail's Purse

A little over a year ago I sat with my daughter after dinner one night and we chatted about entrepreneurship. She was 13 going on 14 but she understood the concept and started to run with it. We talked about what would be a good product. She was going through a very crafty phase. Not crafty as in mischievous, but crafty as in she was painting, building origami, and making artsy things. She enjoyed it and I suggested we should find one of those craft projects that other people might like and turn it into something people would like to buy. We decided one particular project had promise. The craft project was a handbag woven with plastic strips.

She got to work trying to change a craft project into a product. The first discussion was the materials. I told her we were never going to be able to find plastic strips, but we looked on the internet anyway. Nothing was available. I thought we would have to have the strips made for us specifically. So we started talking about alternatives to plastic strips. She came up with using ribbon instead. I liked it because I thought it would make the purse soft and warm vs the cold hard plastic. So we made a trip to Michael's and purchased a ton of ribbon. Problem number two, we had to find a better supplier of ribbon, Michael's was expensive.

She started making the purse out of ribbon and quickly found the next problem. Ribbon doesn't stand up like plastic does. Being the trooper that she is, she tried to make that work as hard as she could. Finally she mentioned that she was having a problem. She needed some kind of support system to allow her to weave. We spent a week or two thinking about this problem and talking about solutions. We tried a couple and failed and some how ended up ruining the ribbon.

This time we went to Joanne's for the ribbon. Who knew ribbon would be so expensive. We got a couple of blocks of styrofoam from Michael to serve as the support system. We cut the styrofoam to the size of the purse, wrapped it in plastic wrap and off Abigail went to build another purse.

This time it was a success. We talked about the fit and finish, it needed a liner, and some kind of tough base. What we ended up with was the purse you see above. I thought it was pretty awesome. She started using it to carry all of her dance gear. And then we stopped working on the purse.

Yesterday we were walking through Wal-Mart and we saw rows and rows of woven bags. A year has gone by since we started working on the purse. But the first thing Abigail said to me when she saw the purses, "They found the plastic strips." The bags are bigger. They are for going to the beach. They are rugged and cold. And they are $7. Each of Abigail's purses were in the $30 range just in ribbon.

The night before the trip to Wal-Mart Abigail mentioned she was ready to do the purses again. That night I searched for ribbon again and I purchased a ton of ribbon that I had found very cheap, 1/40th the cost of Michael's and Joanne's. The ribbon will show up some time soon, and we will make a couple more purses. Hopefully someone on eBay will find them as wonderful as we do and pay a decent price for them.

Lessons:
* Someone always has the same idea
* Get your product out as quickly as you can
* Keep searching for lower cost materials (without sacrificing quality of course)

Skinny User Stories, Fat Unit Tests

One of my colleagues is continuously trying to improve the processes on his project. It is a large enterprisey project with requirements people, testers and a few developers. My friend places high value on knowing exactly what needs to be done and therefor has strived in the past to have very detailed user stories that includes expected behavior and constraints as well as test criteria. He and I had a conversation that restarted his consideration of the user stories. He likes that they are defining the "truth" in only two places, the user story and the code.

While you are defining the truth in two places, I would say that only one of those places has any long term value. The code. As soon as the sprint is completed, your requirements, especially if they live in a tool like Rally, only exist for the sprint where the code is written. After that sprint, it is doubtful that documentation will ever be read again. This is why specs should be light weight. They are only used for a moment in time. Any time that you begin talking about the specs again, you will have to repeat yourself because invariably one person in the conversation will not have a full understanding of the requirements and you won't have the time to send them the requirements to read. Now is a developer going to go through Rally, or any other tool for that matter, to read the requirements for code? No.

The best place to store requirements is in the Unit Tests. Theoretically, you hope to only have one truth, and that one truth has to be the Unit Tests. Every other type of spec is disposable or maybe a better word is perishable. The specs will go away. The contract will go away. The shall statements will go away. The tasks in Rally or JIRA will go away, but the tests will always remain. "Why does this code do
this?" Should always be answered by "look at the test." This doesn't mean leave comments in the test, it means make the test methods the spec.

I've never really been able to put a finger on why I am so against requirements. It seems irrational and crazy. But I think I understand it better now. I have known subconsciously that the requirements are perishable. That they change. They change as soon as you put it in front of someone and show them how it works. The requirements are never absolutely correct. And if they are right, have you put to much time into managing them?

Lessons Learned:
* Requirements are perishable, their shelf life is the length of a sprint.
* Tests are the ultimate "truth" of the requirements of a system.