Install

First, on our Mac, we need to install Capistrano, which will deploy our app for us once we have it set up. It’s a Ruby gem. Do the following to get it:

sudo gem sources -a http://gems.github.com/
sudo gem install capistrano

Capify

Now, let’s run these commands from our home directory:

cd workspace/railstest
capify .

Capistrano will add two files to our app, Capfile and config/deploy.rb. Let’s edit config/deploy.rb:

pico config/deploy.rb

Here is one place we can look for help in figuring out what to put in this file so that Capistrano will know where and how to deploy our app.

Below is what our config/deploy.rb file ends up looking like:

set :application, "railstest"
set :repository,  "git@github.com:your_github_username/railstest.git"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
set :deploy_to, "/var/local/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
set :scm, :git
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none`

set :deploy_via, :remote_cache
set :branch, "master"

set :passenger_conf, true
set :user, "app" # Login as?
set :runner, "app" # Run ./script as?
set :use_sudo, false

set :domain, "rails.example.com"

role :web, domain                          # Your HTTP server, Apache/etc
role :app, domain                          # This may be the same as your `Web` server
role :db,  domain, :primary => true        # This is where Rails migrations will run
#role :db,  "your slave db-server here"

set :rails_env, "production"

# If you are using Passenger mod_rails uncomment this:
# if you're still using the script/reapear helper you will need
# these http://github.com/rails/irs_process_scripts

namespace :deploy do
  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
end

Deploy

Now, we’re ready to run “cap” and actually do some things. Let’s follow some steps in the handy guide referenced above:

cap deploy:setup
cap deploy:check
cap deploy:update

Note: The “update” task failed for me the first time I tried it, and I think the “Known Hosts List” section at the bottom of this page explains why. I solved the problem by SSHing into the server and doing the following:

su app
git ls-remote git@github.com:your_github_username/railstest.git master

You should see something like:

The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)?

Type “yes”, and press Enter, and you should see something like:

Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
502d44c77a98c812eff27e97d542f47ed891fad1        refs/heads/master

I tried “cap deploy:update” again from my Mac and it succeeded.

OK, let’s continue. We’re already on the server, in a shell as the “app” user, so let’s try this:

cd /var/local/railstest/current
rake RAILS_ENV=production db:schema:load

Note: This one didn’t work for me at first either. I found an explanation here, which jibes with what the PostgreSQL manual says. Evidently, the default is for postgresql to only allow UNIX socket connections as a database user with the same name as the operating system user. In our case, we’re running rake as “app”, and rake is trying to connect to postgresql as “railstest”, which isn’t going to work under the default setup. So, let’s change the setup. Type “exit” to get back to your root shell. As root, do this:

pico /etc/postgresql/8.3/main/pg_hba.conf

Comment out the line that says:

local all all ident sameuser

and add a line right below it that says:

local all all trust

Then, run:

sudo su postgres -c "/usr/lib/postgresql/8.3/bin/pg_ctl reload -D /var/lib/postgresql/8.3/main"

to have postgresql reload the config file we just edited. Now, let’s try this step again:

su app
cd /var/local/railstest/current
rake RAILS_ENV=production db:schema:load

It works! Next, do:

./script/console production
app.get("/")

I got a 404 from this, which apparently isn’t a bad thing in our case, because we haven’t configured our app to return anything from that location in production mode.

Next, opening up a web browser on your Mac and browsing to:

http://rails.example.com/javascripts/prototype.js

should return what you would expect.

So, now that we’ve checked every step of the process, let’s run the whole she-bang. In your Mac Terminal, do:

cap deploy

If it works, then we are now at the moment of truth. In our web browser, let’s browse to:

http://rails.example.com/books

Our app should come up! Success! We’re done! WOO-HOO!!!

Conclusion

Thanks for joining me on this journey (if there’s been anyone out there reading this). It’s actually been quite a ride for me, a PHP/MySQL monkey by trade. I hope you’ve had as much fun learning about this stuff as I have. No doubt there’s a better way to do some of the things described in this series. I’ll probably update some of what I’ve written with better methods in future posts. And I’m sure there will be plenty of all-new adventures “On the Rails” in the future. If you have something to share, please feel free to drop me a line. Thanks again, and see you down the road!

Create a Server

Follow these steps to create a Rackspace Cloud Server:

1. Log in to the control panel at manage.rackspacecloud.com.
2. Click on Hosting in the left nav bar, then Cloud Servers.
3. Click Add New Server.
4. Now, it’s time to pick how much RAM and storage space you want (and how much you want to pay per hour). The default, 256 MB RAM and 10 MB storage at $0.015 an hour, is fine for our purposes.
5. Scroll down and give your server a name, like, oh, I don’t know, “Fred” or “Rails-Test” or something.
6. Next, choose your favorite flavor of ice cream operating system. I like Ubuntu 8.04.2 LTS (hardy). Yum. No, wait, I mean apt-get.
7. Finally, click Add Cloud Server.

While it is building your server according to your specifications, the control panel will give you an IP address and a root password. This information will also be emailed to the primary contact email address associated with your account. Be sure to keep it in a safe place.

Once your server is ready, you can SSH into it. In a Terminal, issue the following command:

ssh root@<your_server_IP_address>

Enter your root password when prompted.

Bootstrap That Baby

Marc Chung (formerly of OpenRain, now of redPear) has published, as a GitHub repo, a collection of handy-dandy shell scripts to aid us in bootstrapping a Rails server. I have forked his repo and made a few updates to a few of the scripts. Go here and start to follow the instructions in the README. Update and upgrade Ubuntu, install Git, and clone the Git repo to get the scripts.

Set Up Password-less Authentication

Before we start running scripts, we ought to make it so that we can connect to our remote server from our local Mac without having to type in a password, while at the same time ensuring that no one besides us can connect in this way. (This is necessary for the deployment process to work, as we’ll see in our next episode.) We’ll achieve this by adding the public key we generated earlier on our Mac to an “authorized_keys” file on the remote server. (reference)

1. On the Mac, run “cat ~/.ssh/id_rsa.pub” and copy the result to the clipboard.
2. On the server, run “pico bootstrap/config/root_authorized_keys”. Paste the key into this file and save it (Ctrl-O).
3. On the server, run “pico bootstrap/config/default_authorized_keys”. Paste the key into this file and save it (Ctrl-O).

Edit/Run Scripts

We are going to be running these scripts in order:

00-core.sh
05-ruby.sh
10-misc.sh
15-postgresql.sh
25-apache.sh
36-passenger.sh
40-rails-apps.sh

You can run the core, ruby, and misc scripts out of the box with no command-line arguments.

You should edit the postgresql script before running it, to customize one of the config options. Namely, edit the “add addresses” block in that file. Change the IP addresses to match the machines from which you’ll be remotely connecting to your PostgreSQL database server, if any. If there are none, you can delete this block.

When running the postgresql script, you have to provide four arguments:

1. your admin database user’s password
2. your normal database user’s username (in our case, railstest)
3. your normal database user’s password (we’ll have to add this to our app in railstest/config/database.yml too)
4. the name of the database you want to create for your app (in our case, railstest_production)

Note: This script will install PostgreSQL 8.3 instead of 8.4, as there’s no Ubuntu hardy package for 8.4.

The apache script can be run with no arguments.

The passenger script takes one argument:

1. the public hostname of your server

After running the passenger script, let’s edit one of our Apache config files:

pico /etc/apache2/sites-available/default

Along with the addition and modification of a couple other options, we’re going to change the DocumentRoot to the directory where our app is going to live. Edit the VirtualHost block of the file to look like this:

<VirtualHost *>
    ServerAdmin youremail@yourdomain.com
    ServerName rails.example.com
    DocumentRoot /var/local/railstest/current/public
    RailsBaseURI /
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /var/local/railstest/current/public>
        Options Indexes FollowSymLinks -MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>
...

Save the file with Ctrl-O. Exit with Ctrl-X, and then run:

apache2ctl -k graceful

to restart Apache.

Finally, let’s run the rails-apps script with no arguments.

Post-Scripts

After we’ve finished running the scripts, we want to make it so that the server can connect to GitHub and access our app’s code repo during the deployment process.

Let’s generate an SSH keypair on the remote server, but as the “app” user instead of root, since that’s the one that we’ll be running the deployment process as:

sudo su app -c "ssh-keygen -t rsa"

As we did earlier with the keys generated on our Mac, we’ll paste the public key into our GitHub config:

1. Run “cat /home/app/.ssh/id_rsa.pub” on the server and copy the result to the clipboard.
2. On GitHub, go to your repo’s home page and click the “Admin” button.
3. Under the “Deploy Keys” section, click “Add another deploy key”.
4. Give the deploy key a title, like “Production App Server” or something.
5. Paste the contents of the clipboard into the “Key” textarea.
6. Click “Add Key”.

We’re done bootstrapping! Our Rackspace Cloud Server is now prepped and ready to run our app upon its arrival. Be sure to type “exit” to log out and close your SSH connection.

One More Thing

Before we call it quits for this episode, let’s go back to our Mac for a second and make sure we add the normal database user’s password to our config file. In Terminal, from our home directory, do the following:

cd workspace/railstest
pico config/database.yml

Go down to the empty “password:” line in the “production” section at the end of the file and add the password you specified above as the third argument to the postgresql install script. Type Ctrl-O to save the file.

Next Time

In our next episode, we’ll install Capistrano and deploy our app to this baby! See you then!

Let’s prepare GitHub for our code’s arrival.

1. Go to github.com.
2. If you don’t already have an account, click on “Pricing and Signup” at the top and get a free one.
3. Log in to your account.
4. Click “New Repository” in the upper right of the “Your Repositories” box.
5. Give your repo the name “railstest”, along with an appropriate description and URL if you know where your project will live in production (i.e. its hostname).
6. Click “Create Repository”.

Next, we need to generate an SSH keypair on our local machine, and add the public key to our GitHub account so our local machine can access the GitHub repo we just created. In a Terminal, issue the following command:

ssh-keygen -C "youremail@yourdomain.com" -t rsa

Accept the defaults, and don’t supply a passphrase unless you want to. Now, issue the following command to display the public key:

cat ~/.ssh/id_rsa.pub

Copy the contents of ~/.ssh/id_rsa.pub to the clipboard, and follow these steps:

1. On GitHub, click “Account Settings” in the upper right of the page.
2. Click “SSH Public Keys” in the second row of tabs.
3. Click “Add another public key”.
4. Give the key a title, like “Jeremy’s Key on MacBook”.
5. Paste the contents of ~/.ssh/id_rsa.pub from the clipboard into the “Key” textarea.
6. Click the “Add key” button.

Now, we’re ready to set things up locally.

Locally

With a few additions and modifications, we’ll follow the instructions you saw after creating the repo. In Terminal, from your home directory, issue the following commands in order:

git config --global user.name "Your Name"
git config --global user.email youremail@yourdomain.com
cd workspace/railstest
git init
git add .
git commit -m 'Initial import'
git remote add origin git@github.com:your_github_username/railstest.git
git push origin master

Now, let’s go back to our repo on GitHub and make sure our code made it there OK. That’s it!

Next time: We’ll create a Cloud Server on the Rackspace Cloud, set it up to host our app, and use Capistrano to deploy our code from GitHub to our server. See you then!

sudo port install apache2

Next, Passenger:

sudo gem install passenger

Now, let’s build and install the Passenger extension module for Apache 2. This part was a little tricky for me, due to the fact that we’ve installed another Apache 2 via MacPorts. We want the Passenger module build process to find the MacPorts one, and not the one that came with Snow Leopard. I found and followed a couple other instructional blog posts on this, but I ended up doing something other than what they did to get it to work.

First, let’s add a line to the end of our ~/.profile file. (Type “pico ~/.profile” to edit it.)

export PATH="/opt/local/apache2/bin:$PATH"

Next, run the following command:

source ~/.profile

Now, we can build the module:

sudo passenger-install-apache2-module

After that builds and installs the module, let’s edit our Apache 2 config file. (Type “sudo pico /opt/local/apache2/conf/httpd.conf” to edit it.)

First, let’s type Ctrl-W and enter “80″ to search for the string “80″. 80 is the default port Apache listens on. But that port is already bound to the Snow Leopard Apache. Let’s change the port our MacPorts Apache will listen on to 3000. Comment out this line (add a “#” character in front):

Listen 80

And add the following line right underneath it:

Listen 3000

Next, let’s add the following to the end of the file:

LoadModule passenger_module /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.8/ext/apache2/mod_passenger.so
PassengerRoot /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.8
PassengerRuby /opt/local/bin/ruby
PassengerDefaultUser your_username

<VirtualHost *:3000>
   ServerName localhost
   DocumentRoot /Users/your_username/workspace/railstest/public
   RailsBaseURI /
   RailsEnv development
   <Directory /Users/your_username/workspace/railstest/public>
      AllowOverride all
      Options Indexes FollowSymLinks -MultiViews
      Order allow,deny
      Allow from all
   </Directory>
</VirtualHost>

The Phusion Passenger users guide for Apache was helpful on this step. Be sure to replace “your_username” and “workspace” above with your username and the name of the directory containing your Rails projects.

Now, let’s start Apache:

sudo apachectl start

And, in a separate Terminal, start PostgreSQL if it’s not already running:

sudo su postgres -c '/opt/local/lib/postgresql84/bin/postgres -D /opt/local/var/db/postgresql84/railstest'

Browse to:

http://localhost:3000/books

and voila! Our CRUD app from last time is now running on Apache with Phusion Passenger instead of WEBrick!

Next up: Git and GitHub stuff.

Before we create the app, though, let’s briefly describe what our data is going to look like. Let’s say we want to store some basic information about all of the books we have in our possession. Most books have, among other things, a title, an author, a publishing company, a copyright year, and an ISBN number (a unique identifier). If our database table is going to be composed of books, then each record in that table is going to have each one of the above attributes, stored as strings of text.

Create CRUD App

So, let’s first create our initial, empty skeleton of a Rails app.  From your home directory, or whatever directory you want to store your Rails projects in, issue the following command:

rails railstest -d postgresql

This will create a folder named “railstest” and populate it with all of the wonderful goodies that Rails provides as a foundation for writing a web-based application that follows the Model-View-Controller architectural pattern. The “-d postgresql” part pre-configures the app to use the relational database system we have chosen, PostgreSQL. (If you wanted to use MySQL or something else, you could just as easily specify a command-line argument for whatever you’ve chosen instead. Type “rails –help” to see all the options.)

Now, we’re going to take our foundation and build a CRUD app on top of it. But we’re not going to type a single line of Ruby code. We’re going to make use of scaffolding. (Later, we’ll want to avoid scaffolding like the plague, and build our apps by actually writing our own Ruby code, but we’re trying to get up and running ASAP, so we’ll take the easy way for now.)

Issue the following commands from the directory containing your Rails project(s):

cd railstest
./script/generate scaffold book title:string author:string publisher:string copyright_year:string isbn:string

This will create some code files — models, views, and controllers — and a database migration, which describes how to set up our database schema. We’ll be invoking rake (a build program for Ruby) a little later to do just that.

Set Up Database

Before we do that, though, we should create a database cluster, launch the database server, create a new database user, and finally create the database. (You may have taken note of some instructions that appeared in your Terminal after you installed PostgreSQL. If you did, some of the commands in this step should look familiar.)

First, we need to create and initialize the data directory, or database cluster. Issue the following three commands in order:

sudo mkdir -p /opt/local/var/db/postgresql84/railstest
sudo chown postgres:postgres /opt/local/var/db/postgresql84/railstest
sudo su postgres -c '/opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/db/postgresql84/railstest'

Next, launch the database server. Open a new Terminal tab or window, and then issue the following command:

sudo su postgres -c '/opt/local/lib/postgresql84/bin/postgres -D /opt/local/var/db/postgresql84/railstest'

Next, create a new database user (or role):

sudo su postgres -c '/opt/local/lib/postgresql84/bin/createuser -S -d -R railstest'

Finally, create the development database:

sudo su postgres -c '/opt/local/lib/postgresql84/bin/createdb -O railstest railstest_development'

Now, let’s run rake and create our schema:

rake db:migrate

Just Push Play

We’re almost there! Time to start up our web server and Ruby application layer. At the moment, all we have is WEBrick, which comes with Ruby. (Note: WEBrick is a quick and dirty web server solution that will run our simple app and get us to the end of this part of the tutorial, but it should not be used for anything more complicated, and certainly not in a production environment.) Run the following command in a new Terminal:

./script/server

Now, open your web browser and go to:

http://localhost:3000

You should see a Rails welcome screen. Next, go to:

http://localhost:3000/books

You should see our CRUD app! You should now be able to Create, Read (or Show), Update (or Edit) and Delete (or Destroy) books. The data is stored in our PostgreSQL database instance we created above.

Next Episode

Next time, we’ll put the code under version control locally using git, set up a remote repository on GitHub, and then push our code to that remote location. See you then!

Note: As the Perl folks say, there’s more than one way to do it. This is only one of many possible configurations and ways to set things up. I’m writing this post (and the next two or three) for my future self and anyone else who might want to get up and running with Rails this way.

In the next few posts, we will: create a simple database-driven CRUD web application in Rails; set up a source repository on GitHub and push our code there; create a server on the Rackspace Cloud, set it up for production use, and finally deploy our app from GitHub to that server.

This post is really an adaptation of a nice guide written by Jared McFarland. His setup includes MySQL rather than Postgres, and so my post will only modify and elaborate on his where appropriate.

Let’s begin.

MacPorts

The first thing we want to get is MacPorts, a system by which we can easily get the latest, most widely-used versions of Ruby, RubyGems (a Ruby software packaging system), Ruby on Rails, and PostgreSQL. (Snow Leopard does come with versions of Ruby, Gems and Rails, but things move fast, and they were already outdated when Snow Leopard was released.)

Go here and get the latest DMG disk image for Snow Leopard (1.8.1 at this writing). Install the PKG. (Note: MacPorts will put itself and everything else you install via MacPorts in the /opt folder on your primary hard disk, so you’ll know where everything is in case you want to get rid of it later.)

Ruby

[Update, 12/21/2009, 4:30 p.m. MST: Marc Chung tells me that a better way to install Ruby than that described in this section is via rvm (Ruby Version Manager), which allows you to have multiple Rubies installed and switch between them. More details forthcoming.]

In Terminal, do:

sudo port install ruby

and enter your user account password if/when prompted. This will install the latest Ruby 1.8, which at this writing is 1.8.7, patchlevel 174, dated June 12, 2009.

When it’s done, do:

which ruby

and you should see:

/opt/local/bin/ruby

Now, do:

ruby -v

and you should see:

ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10]

RubyGems

sudo port install rb-rubygems

Latest RubyGems on MacPorts is 1.3.4. (1.3.5 is the actual latest and is coming to MacPorts Real Soon Now).

SVN and Git

sudo port install subversion

sudo port install git-core +svn

If you don’t have any existing Subversion repositories, you can ignore the subversion line and omit “+svn” from the git-core line. If you’re starting from scratch, you only need Git. Latest Git on MacPorts is 1.6.5.3 (actual latest 1.6.5.6).

PostgreSQL

sudo port install postgresql84-server

Latest PostgreSQL is 8.4.2, and it’s on MacPorts.

[Update, 12/24/2009, 12:30 am MST: Add the following line to the end of your ~/.profile file:

export PATH="/opt/local/lib/postgresql84/bin:$PATH"

Then issue the following command from the prompt:

source ~/.profile

The PostgreSQL binaries need to be in your PATH; if they aren't, the next step will fail.]

That’s all for the MacPorts stuff. Now for some Ruby Gems.

PostgreSQL Ruby Adapter

sudo gem install pg

Latest PostgreSQL Ruby Adapter gem (pg, a.k.a. ruby-pg) is 0.8.0.

Rails

sudo gem install rails

Latest Rails is 2.3.5. This includes eight gems — actionmailer, actionpack, activerecord, activeresource, activesupport, and rails (all 2.3.5); rack (1.0.1); and rake (0.8.7).

You now have all the software you need to start developing web applications using Ruby on Rails on your Snow Leopard Mac!

Be sure to tune in next time, for another exciting episode of Jeremy’s Wild and Crazy Adventures on (off?) the Rails, when we’ll discover how to create a basic CRUD app in Rails without writing a single line of Ruby code! (Before long, we’ll want to develop apps by actually writing some Ruby code, but more on that later.) We’ll also set up Git repositories in which to store and track our code revisions, both locally and on GitHub. See you then!

As someone with three Macs at home, I couldn’t help but notice that Apple pushed Safari 4 out as an automatic update to all of its users this week. Yesterday, all three of the Macs in my household received the update, and we don’t even use Safari.

An informal poll of my friends and colleagues reveals a whole lot of the same. Got the update dialog, downloaded and installed it, don’t intend to use it.

What is at issue is the ridiculously thin claim that the latest Safari is a wild success on the basis that Apple basically pushed it out to everyone it possibly could, whether they wanted it or not.

(Emphasis Paul’s.)

What I take issue with is Robert’s equally misleading title (“Safari 4 download stat is pure hype”) and use of the phrase “pushed it out“.  I suppose it depends on how you define “push“, but to me, this reflects a lack of understanding of how Apple Software Update works.

Unlike Microsoft’s Automatic Updates, for which the recommended and default behavior is to automatically check for, download, and install updates at a given time of day (what I consider “push“), Apple Software Update does not have the ability to automatically download or install anything:

Here’s what Apple Software Update looks like when it pops up, first on a Windows XP machine without Safari installed:

With Safari 3.2.3 installed:

Without Safari installed, Safari 4 appears in the lower pane (New Software), not selected.  With Safari 3 (or 4 beta) installed, Safari 4 appears in the upper pane (Updates), already selected, meaning the user must un-check the box if they choose not to install Safari 4.

Is Strohmeyer suggesting that most Mac users (including himself, evidently) are too lazy and/or ignorant to un-check the box for Safari in Apple Software Update, and are therefore (in some cases, unknowingly) downloading and installing Safari 4, without actually wanting it?

Is Thurrott suggesting that most Windows users (including himself, evidently) who had previously made a choice to download and install Safari (which is not bundled with Windows) are similarly too lazy and/or ignorant?

Apple is not “pushing” Safari 4 on anyone.  And I doubt that the laziness or ignorance of users accounts for a significant fraction of the Safari 4 downloads claimed by Apple.

Grid computing has been used in environments where users make few but large allocation requests. … [O]nly a few of these allocations can be serviced at a time and others need to be scheduled for when resources are released. …

Cloud computing really is about lots of small allocation requests. … The allocations are real-time and in fact there is no provision for queueing allocations until someone else releases resources. …

It’s easy to say “ah, we’ll just run some cloud management software on a bunch of machines,” but it’s a completely different matter to uphold the premise of real-time resource availability. If you fail to provide resources when they are needed, the whole paradigm falls apart and users will start hoarding servers, allocating for peak usage instead of current usage…

The comments on that post are worth reading, as well.

An earlier post from Thorsten (republished later on Cloud Computing Journal) clearly and succinctly defines some terminology used to refer to different aspects of cloud computing:

Applications in the cloud: … Some company hosts an application in the internet… The service being sold (or offered in ad-sponsored form) is a complete end-user application. To me all this is SaaS, Software as a Service, looking to join the ‘cloud’ craze.

Platforms in the cloud: … where an application platform is offered to developers in the cloud. … The service being sold is the machinery that funnels requests to an application and makes the application tick.

Infrastructure in the cloud: … the most general offering that Amazon has pioneered and where RightScale offers its management platform. … virtually any application and any configuration that is fit for the internet can be mapped to this type of service.

Again, the comments are worth reading and link to other articles on the subject.

Yesterday morning, a web-based bookmarking service, ma.gnolia, suffered a catastrophic failure. It will be at least a matter of days before the service returns, and users’ bookmarks may be lost, either partially or completely. Michael Calore writes at Wired’s Epicenter blog:

In light of today’s outage, many are questioning the reliability of web apps and web-based storage in general. Twitter in particular is full of users venting their suspicions.

“Cloud computing becomes fog when it goes down,” says Todd Spragins in a Twitter post.

Another common thread: People are talking about bailing on Ma.gnolia in favor of competitor Delicious.

More ammunition for the critics (warning: NSFW) of “the cloud”, or web-based software and data storage.

This morning, the mighty Google screwed up and, well, “broke the Interwebs”.  For a “brief” period (less than an hour), every single result returned from Google’s search was flagged as potentially “harmful”, meaning the linked site was “known” to install malware upon visiting.  Google VP Marissa Mayer writes:

What happened? Very simply, human error. … We maintain a list of such sites through both manual and automated methods … We periodically update that list and released one such update to the site this morning. Unfortunately (and here’s the human error), the URL of ‘/’ was mistakenly checked in as a value to the file[,] and ‘/’ expands to all URLs. Fortunately, our on-call site reliability team found the problem quickly and reverted the file.

If you click on a link that’s been marked by Google in this way, you don’t go directly to the linked page.  You’re taken to a page from Google asking, and I’m paraphrasing here, “Are you sure you want to visit this page? If so, you do so at your own risk.”  You can then click through to the actual page if you wish, against the advice of Google and their partner in this flagging endeavor, StopBadware.org (who Google initially suggested was at fault for this SNAFU — they’re not).

Needless to say, this essentially ground to a halt pretty much all web browsing linked from Google search results.  Of course, as Leo Laporte brought up on his radio show today, whether Google should be flagging sites and setting up roadblocks to visiting them, based on a computer- and human-generated blacklist, without your permission, is another question entirely.  Leo thinks you should be able to turn off this flagging feature in Google’s settings, and that Google shouldn’t be the supreme arbiter of what we get to see on the web.

Ms. Mayer writes that the problem was taken care of “quickly”, and Leo disputes this as well (“An hour?! That’s an eternity on the Internet!” — again, paraphrasing), but this at least illustrates that they have a plan in place for rolling back to earlier revisions of critical components of their system, as quickly as possible, in the event of a breakage.

Do you?

• Linking SaaS Software Pricing to Value
• Userfly: Get Usability Insights with One Line of Code

Related to Google Chrome:

• Google Releases First Pre-Beta of Chrome 2.0
• Firefox to Adopt Chrome’s Tab Ordering Feature (the osmosis has begun…)

Also of interest, from Google’s Chromium Blog:

• Google Chrome Release Channels - details of the three release/update channels one may subscribe to for Chrome (Stable, Beta, Developer Preview)