The insider's guide to everything sparqcode
Header image

Using Mixins With Ruby

Posted by Mike on April 20, 2011 in Technical Development | Thoughts - (0 Comments)

If you’re used to a language like C++ or Java the common way to share behavior across classes was to use inheritance. This has some problems because you should only really use inheritance in a is-a relationship. A politican class would probably behave like the fool class, but I don’t think it’s appropriate for the politician to be a fool because then any changes to the fool would also the change the politician.

Now to have classes behave like others we use a strategy called encapsulation. Using the previous example, you would do something like this:

class Fool
  def speak
  end
end

class Politician < Fool
  def initialize
    @fool = Fool.new
  end

  def speak
    @fool.speak
  end
end

Now what if the implementation for speak was the same across the fool and politician classes and would always be the same? Well we could use a mixin to define that behavior.

module Speaking
  def speak
  end
end

class Fool
  include Speaking
end

class Politician
  include Speaking
end

Now this has one downside, lets say the Speaking module was written like this:

module Speaking
  def speak
    "I say " + @motto
  end
end

This definition assumes and requires that both the Fool class and the Politician class have a @motto instance variable. This would also apply to any method definitions that are referenced as well.

The mixin is not the golden hammer but it is a very powerful tool to have in your toolbox.

What’s Your Mobile Presence?

Posted by Mike on April 6, 2011 in Thoughts - (0 Comments)

Soon there is going to be more cellular phone subscriptions in the United States than there are people. Does this scare you? Unless you’ve figured out how to present yourself online, it should. What do I mean by mobile presence? Well it’s not hard to imagine a future where all of your customers access your website and information about you/your company entirely through the customer’s mobile phone. I think a lot of people out there still do not have a handle on how to deal with this shift in access patterns. I’ll share my thoughts on different ways you can deal with your mobile presence.

Don’t

A lot of the modern smartphones (iPhone and Android specifically) have very good browsers in them. It’s quite likely that your web page already renders just fine and your customers will be able to access the information they need. There’s a slight problem with this though, smart phones work on a different aspect ratio than your computer does so a lot of pages don’t look right, require a lot of scrolling, and generally make it harder for the user to navigate effectively.

Mobile Friendly Pages/JQuery Mobile

Another option is to make a mobile centric version of the page. Your mobile site is designed with the constraints of the mobile device in mind. The problem with this approach is that not all mobile phone browsers are created equal. As I mentioned both iPhone and Android have very capable browsers, but the experience you get on older blackberries and Windows Mobile can be downright painful.

The fine folks over at JQuery have been working to solve this problem with jquery mobile. Basically it’s a javascript framework that will adjust your UI to match the capabilities of the phone viewing it and do its best to make your page look like a native phone app. Even though jquery mobile is still in the alpha stage, it’s still remarkably mature. It’s really easy to get a really nice looking app up and running quickly, I highly recommend checking it out if you’re building a mobile web site.

Facebook

If you don’t already, you should have a Facebook page. The nice thing about maintaining an up to date facebook page is that Facebook has already done all the hard work of creating a mobile app and optimizing their site for mobile devices. If you direct your users to your facebook page, all you need to worry about is making sure your personal or company page is up to date.

SPARQ.ME

Available to all of our registered users is a feature called SPARQ.ME. It lets you quickly and easily create a mobile friendly site for yourself or for your business. You can check out my SPARQ.ME here. Like Facebook, we do all the work to make sure it looks good on mobile phones, but we let you customize the page with custom widgets so you can tailor the page to who you think will be viewing it.

In Conclusion…

Think about your mobile presence. As mobile phone usage increases in the US, being accessible through a mobile device is going to become more and more important. It’s better to think about this kind thing now rather than being blindsided by it in the future.

Embedding a Url in a QR Code

Posted by Mike on March 9, 2011 in Thoughts - (0 Comments)

This may seem like a silly topic to a lot of people.  Using Google’s charts API is very easy to generate a QR Code that points to your website.  Like so much in life, the devil is in the details.  If you’re CNN and you’re just embedding a URL in your QR code you’re going to end up with something like this:

The biggest problem with this method is that it will be very hard to scan unless the person scanning has a high resolution camera with a macro lens.  The reason this QR code is hard to scan is because it there’s a lot of data.  Simply speaking, the larger the data payload in a QR Code smaller the dots are, and the harder it is for phones to scan.  How do you combat this?  Url shortening.

The gist of URL shortening is to take some url like http://www.google.com and turn it into something smaller like http://ab.cd/1234.  The idea being is that any arbitrarily long url will turn into something very small and QR Code friendly.  Here is that same CNN url shortened:

There are two ways you can shorten a URL: Case sensitive and Case insensitive.  Case sensitive shortening converts your url into a series of characters consisting of a-z, A-Z, and 0-9.  Case insensitive just uses a-z and 0-9.

The benefit of case sensitive is that you get more URLS per character, for example bit.ly will basically be able to store every URL in the universe with six characters.  The downside is that if you ever have to type your url in on a phone manually the user will have trouble.  Case insensitive on the other hand doesn’t practically require any more characters, but it means if the user ever needs to type in the url they will have a much easier time.  I’ll cover the actual algorithms to compress the URL in a future post.

When you encode URLs in a QR code you should definitely shorten it, but the method you use should be determined by how you expect people to use it.