This may be a game-changer.

This new service allows entrepreneurial developers to wrap their own business models around Amazon S3 and Amazon EC2, taking advantage of Amazon’s existing customer base and billing infrastructure. With DevPay, developers can focus on being creative and innovative while dispatching the less-than-glamorous aspects of dealing with bank accounts, credit cards, and so forth to us.

(Via Amazon Web Services Blog: Make Money Fast - Introducing Amazon DevPay.)

As someone that has built more web applications than I care to remember, I am still amazed at how many elements of the web business are built over and over again.

They now have the complete package for some types of startup projects. Letting developers focus on the user-side of their service, instead of recreating the wheel.

Brilliant next step by Amazon.

Just in case you read about the latest Net Applications browser market share report and the .09% share that the iPhone got, I wanted to jump in with a reality check as the Apple zealots are making my ass itch with their usual idiocy. I mean, it’s great to hear the iPhone is doing well… mobile Safari is the best mobile browser bar none and shows the true power of the mobile internet - if you think otherwise you’re an idiot (or have never used it).

However, that said, if you believe any of those wonky mobile stats, you’re also an idiot.

(Via Lies, damn lies and mobile browser market share reports.)

Russell is correct. These reports are usually exaggerated if not flat out lying.

That said, we “mac zealots” have been saying the same thing about market share reports for years. After all, every “PC” shipping is not destined for someone’s desk.

That said, Russell points out that there are more browsing enabled phones than computers.

However, one trend I am witnessing first hand with the iPhone and will see more when iPhone competitors hit the markets in 2008, is that people want easy to use devices.

Amy inherited by partners iPhone recently, she is what you would describe as a typical mobile phone user.

She always has a phone with her, uses it as her primary communication device, yet despite my efforts to keep her phone up to date with the latest trends and encouraging her to text, browse and use email on her phones - she never did before the iPhone.

I am still figuring out what changed and from my observations, it is all about the ease of use.

She doesn’t have to dig through menus, learn to appreciate the hack that is T9 predictive typing and most of her web sites just work.

Instead of asking me for the information when we are out, I frequently look to see her texting, surfing and generally using more of her phone’s features than ever before.

”Today we are happy to tell you about a new feature we’ve started to roll out which will enable you to sign into your AIM account and chat with your AIM buddies right inside Gmail. When you log in to AIM through Gmail chat, your AOL buddies will appear in your chat list with friends from your Google Talk network, and you will see the yellow “running man” logo to the right of your AIM friends’ screen names. To your AIM friends it will look like you are logged in to AIM as usual.”

(Via Official Gmail Blog.)

Wow! Now if they can add the buddy list to the Google Notifier I would be in heaven.

As mentioned in a previous post about url_for, sometimes Rails magic needs to be de-emphasized or eliminated to attain the performance you need.

Rails provides excellent statistics to help you see how your application is humming along.

While you can go into the depth with various tools, like wrapping Benchmark block around code to see how it performs, the hints about where to look are in the logs.

A sample action will generate the following information in the logs:

Completed in 1.77621 (0 reqs/sec) | Rendering: 0.10928 (6%) | DB: 0.50002 (28%)

The discrepancy between the completed, rendering and db times lets know that you have overhead hidden away in an action.

Unless you are doing serious processing, like generating a PDF or accessing a web service, there is an obvious place to start.

The objects you are retrieving with ActiveRecord.

Having had experience with Apple’s WebObjects, I was familiar with the overhead involved in retrieving and instantiating objects.

Instantiating is the key place to look first.

In my case, the performance issue only revealed itself when a customer using the page ended up with thousands of records, not tens or even hundreds.

This action was using a typical AR finder method, with conditions to affect the results based on user input.

In development mode I was able to view the query and craft a custom finder that relied on find_by_sql.

On top of that, I honed down the columns retrieved to the bare minimum.

By default, ActiveRecord retrieves all columns, which can add significantly to the overhead during instantiation.

You can go lower, by retrieving the values using the bare bones database connection.

In my case, that wasn’t needed - yet.

The last month I spent optimizing and improving performance as one of my projects grew in use.

One of the page had to display hundreds and even thousands of links.

Taking pages from others discoveries, I learned that linkto can be dangerous in large doses. Well the real culprit in my case was urlfor.

Replacing it with a simple string concatenation method boosted performance 3-4 fold.

Its not the fault of Rails, free features and Rails magic always costs something.

In most cases it is an acceptable, reasonable and enjoyable cost.

This is also the pleasure of optimizing late, not early - or only when needed.

I have been relying on MySQL’s Full-Text search index for sometime.

Recently a user ran into a black hole in that feature.

He wanted to find records containing a simple phrase, “thank you”.

But, the search resulted in no records found.

You see, “thank” and “you” are stop words in the default full-text index. Meaning they are discarded or given no relevance in the search results.

After some digging, I discovered that others have run into this same limitation and opted to remove the default stop word list.

Quick fix? Not quite.

Removing the stop word list, forces you to rebuild the index. Which on my modestly sized database meant 30 minutes of downtime on that table.

Fair enough. I performed that over the weekend.

Fast forward a couple days. Guess what happens now?

Other users are getting less than stellar search results - of course. Seemed a fair trade off at the time, between the two extremes.

I could keep tuning the stop words and narrowing the gap between the two extremes, but tuning mysql full-text index takes far too long because of the table locking required to rebuild the index.

So I am moving on to external search indexers, like Sphinx. Which can rebuild the entire index in a few minutes without requiring the downtime for the users.