I just attended a talk by Seth Ladd from Google at RefreshSD. The first part was a general overview of new technologies associated with HTML5, including the new markup, CSS 3, offline storage, websockets, etc. None of that was news to me, but the second half, about the Chrome Web Store, was new and awesome.

The Chrome Web Store is an app marketplace similar to the familiar App Store from Apple, but it's for web applications. Every app is built entirely with open web technologies: HTML, CSS, and JavaScript. The idea of building desktop-caliber applications on the web is nothing new, but there hasn't been a central place for people to go to find them. The Chrome Web Store, surely the first of what will be many similar stores, changes that.

The store allows developers to add their web applications for other people to install and use easily. It even includes a payment and licensing system that allows developers to charge for their apps. If you use Google Chrome as your browser, the store is easier to use through the tight integrations with the browser. Since all the apps are web-based, it's perfectly possible to browse the store and use the apps in other modern browsers, though the experience is not ideal.

I expect that it won't be long before we see Apple, Microsoft, and possibly other big tech companies creating their own equivalents of the Chrome Web Store. I'm curious to see how interoperability between them will play out. Obviously the web apps themselves will be usable in multiple browsers, but I'm hoping it will be easy to register the same app with multiple stores, giving the user the option which they prefer for installation and payment. Seth imagines that, in the future, web apps will identify themselves with Open Graph style data in meta tags, allowing auto discovery for inclusion in multiple stores.

This is an exciting development in the web for me, since the explosive success of Apple's App Store(s) has largely excluded web apps. Now those of us who are not interested in Objective-C or Java development can really start to get in on the fun.

The keyword self in Ruby gives you access to the current object – the object that is receiving the current message. To explain: a method call in Ruby is actually the sending of a message to a receiver. When you write obj.meth, you're sending the meth message to the object obj. obj will respond to meth if there is a method body defined for it. And inside that method body, self refers to obj. When I started with Ruby, I learned this pretty quickly, but it wasn't totally apparent when you might actually need to use self. I will outline the two most common use cases I've found for it.

Class methods

The first usage I ran into was to define class methods. Inside a class, the def keyword will create a new instance method, when used without an explicit receiver.

class Post
  attr_writer :title

  def print_title
    puts "The title of this post is #{@title}"
  end
end

pst = Post.new
pst.title = "Green Beans"
pst.print_title
# "The title of this post is Green Beans"

In the context of a class, self refers to the current class, which is simply an instance of the class Class. Defining a method on self creates a class method.

class Post
  def self.print_author
    puts "The author of all posts is Jimmy"
  end
end

Post.print_author
# "The author of all posts is Jimmy"

Another more advanced way to do this is to define a method inside the Class instance itself. This is referred to as the eigenclass or the singleton class and it uses the self keyword to open a new context where the Class instance is held in self.

class Post
  class << self
    def print_author
      puts "The author of all posts is Jimmy"
    end
  end
end

Post.print_author
# "The author of all posts is Jimmy"

Disambiguation

When you call a method without an explicit receiving object, the method is implicitly called on self. So if self is assumed for us, why do we ever need to use self.meth outside of a class method definition? As it turns out, it may not always be clear which method you're trying to call. Consider this example:

class Post
  attr_writer :title

  def self.author
    "Jimmy"
  end

  def full_title
    "#{@title} by #{class.author}"
  end
end

pst = Post.new
pst.title = "Delicious Ham"
puts pst.full_title

When we call full_title, we get a syntax error because class.author in the method body attempts to use the class keyword instead of the class method on the pst object, which is what we want – the object's class. If we use self.class.author instead, Ruby knows that we want the class method of pst, and we get the result we expect.

Another time when self is needed for disambiguation is when assigning a value to one of the object's attributes. Here is a contrived example:

class Post
  attr_accessor :title

  def replace_title(new_title)
    title = new_title
  end

  def print_title
    puts title
  end
end

pst = Post.new
pst.title = "Cream of Broccoli"
pst.replace_title("Cream of Spinach")
pst.print_title
# "Cream of Broccoli"

Even though we replaced the title of the post with "Cream of Spinach," it remained set to "Cream of Broccoli" and that's what we see when calling print_title. This is because the assignment inside replace_title is simply assigning to a local variable called title which is not used for anything. If we change that line to self.title = new_title, then the call to print_title at the end will give us "Cream of Spinach" as we were expecting. Note that it is not necessary to use self.title explicitly when using the accessor method inside the definition of print_title, because Ruby will see that there is no local variable with that name and then send self the message title. In the case of assignment, Ruby must assume you want to assign to a local variable, because if it sends the title= message to self, you are left with no way to set a local variable.

If you have more examples of when you might use self, feel free to leave a comment.

Today I've launched a completely rewritten version of jimmycuadra.com. When I originally built the site, my intent was on building a freelance business. After a few years, it's become obvious that my goals have changed. I've been working for a company full time and have decided that I greatly prefer the security of a full time job to all the hassles freelancing would involve. I don't want to deal with clients, I don't want to manage taxes and health insurance, I don't want to worry about tracking hours and billing. I just want to program.

With those new directions in mind, it was time to revamp my site with a simpler, streamlined focus. All I really need is a blog, a list of my major projects, and a brief bio. And that's exactly what the new jimmycuadra.com is.

The site is again built with Ruby on Rails but with another year's worth of experience working with Ruby and Rails. This time around it is being hosted on Heroku, where I am in the process of moving all my sites. The code for the site is now open sourced on GitHub along with my other projects.

I'd been hesitant to add new content to the site, knowing that this new version was imminent. Now that it's finished, I hope do more writing and screencasting.

I've also decided that, contrary to my original goal of ultimate accessibility, I am no longer supporting any version of Internet Explorer on any of my sites. I don't even check them in IE. I'm sure they're completely broken, and I don't care. My focus in web development has narrowed greatly, and anyone using IE is not my audience. I definitely wouldn't have this attitude working on a business project where cross-browser compatibility was important to the stakeholders, but on my own projects, spending any time on IE at all is literally a waste of time.

The new site is all about slimming things down: no unnecessary pages, a small number of content tags, integrated blog posts and screencasts, a simple design, easy deployment, one rendering engine to rule them all (Webkit) and motivation for myself to provider better, more frequent content.

Here's to a new era.