Today I found out that I wasn't receiving email correctly. This was pretty distressing given I was awaiting the result from the first round of SVIP (Silicon Valley Internship Programme) interviews.

Over the weekend I switched my blog over to Ghost running on Red Hat's awesome OpenShift platform. Before this, my domain name, 'prydoni.us', used to point to my VPS' static IP and I had MX records set up for Google Apps Email.

To point my domain to its new home on OpenShift I needed to change it to a CNAME record pointing at my sub-domain, since OpenShift doesn't have static IP addresses. It turns out though, that CNAME records don't play nice with MX records.

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

What seems to happen is the lookup ignores the MX records set up on the root domain, and instead looks for MX records on the host domain (in this case, the OpenShift sub-domain).

A simple enough workaround is to setup the root domain as a 301 redirect to a sub-domain that has the CNAME record. I already had http://blog.prydoni.us with this setup, so redirected http://prydoni.us to that and voila! Emails started coming in again! Looks like I am going wake up to a whole load of missed emails tomorrow though, awesome...

On the bright side, I got through the first round of SVIP interviews! Looking forward to hearing from the awesome startups I've been matched with!

I recently had an interview where I was asked to implement a key-value store with a twist, in a language of my choice. For straight-forward programming tasks like this, I like to use Ruby.

Since I can't mention the actual problem I was given, I will describe a different, simpler problem to illustrate the power of syntactic sugar in Ruby. Let's implement a key-value store that capitalises values (assuming all values are strings). We can make use of the built-in Hash library so that we don't have to fuss around with hash functions and the like.

A simple implementation of the problem would be like so:

class CapitalHash  
    def initialize
        @internal_hash = Hash.new
    end

    def set(key, value)
        @internal_hash[key] = value.capitalize
    end

    def get(key)
        @internal_hash[key]
    end
end  

We simply keep an internal hash table, whilst adding our own accessors to handle the capitalisation of values. Again, we're assuming that all values will be strings, so we can omit a type check.

We can now use the capitalised key-value store like so:

kvstore = CapitalHash.new  
kvstore.set("apple", "orange")  
kvstore.get("apple")    #=> "Orange"  

This is the general solution that one could implement in most languages. However, we can leverage Ruby's syntactic sugar to make this more interesting. I'm just going to throw some code at you:

class FancyCapitalHash  
    def initialize
        @internal_hash = Hash.new
    end

    def []=(key, value)
        @internal_hash[key] = value.capitalize
    end

    def [](key)
        @internal_hash[key]
    end
end  

All we have changed are the method names. Hold on though... can square brackets really be the name of a method? How odd.

Let's take a look at Ruby method naming conventions to understand a little more about what we're doing here.

Method names may contain letters, numbers, an _ (underscore or low line) or a character with the eight bit set.
-- Methods - Ruby Doc

The documentation goes on to say that method names may end in either:

  • An exclamation mark -- to indicate that the method modifies the receiver
  • A question mark -- to indicate that the method returns a 'truthy' or 'falsey' (All objects can evaluate to true or false) value
  • An equals sign -- to indicate an assignment

In addition to this, method names can also be standard operators (+, -, *, / etc.), but these only accept one argument. Unary operators can also be defined and are suffixed with an @ symbol. For added fun, we are also allowed the array lookup non-operator ([]), which is what we've used above.

All of these conventions can be seen in the built-in Ruby libraries.

String#capitalize!

a = "string"
a.capitalize!
a    #=> "String"

The receiver, a, is modified directly. The non-exclamation version of String#capitalize will return a capitalised version of a without modifying it.

String#empty?

"hello".empty?  #=> false

Returns a true or false value we can use in Boolean expressions.

Hash#default=

h = { "a" => 100, "b" => 200 }
h.default = "Go fish"
h["a"]    #=> 100
h["z"]    #=> "Go fish"

Provides a setter for the default value returned when a key doesn't exist in the hash table.

String#+

"Hello from " + self.to_s   #=> "Hello from main"

The binary addition operator with one argument.

Array#[]

a = [ "a", "b", "c", "d", "e" ]
a[2] +  a[0] + a[1]        #=> "cab"

Array lookup.

So where does all the syntactic sugar come in? If we think about the way normal instance methods are called, we can start to see that Ruby is doing something magicky under the hood for us.

Taking the last two examples, we can call these functions like so:

# def default=(value); ...; end
h.default=("Go fish")

# def +(str); ...; end
"Hello from ".+(self.to_s)

# def [](index); ...; end
a = [ "a", "b", "c", "d", "e" ]  
a.[](0)  

Ruby implements an object-message protocol such that method calls are actually messages to another object. These messages consist of a name and an (optional) payload. The payload is the list of Ruby Objects that are the arguments of the method.

Since method calls are actually messages, the methods themselves must then be the message handlers -- the action that is performed when a message is received. Ruby provides the send method to invoke a message handler in an object.

So the above methods, can also be expressed like this:

# def default=(value); ...; end
h.send(:default=, "Go fish")

# def +(str); ...; end
"Hello from ".send(:+, self.to_s)

# def [](index); ...; end
a = [ "a", "b", "c", "d", "e" ]  
a.send(:[], 0)  

However, doing things this way can easily lead to some confusing code, and is not analagous to the way of doing things in other languages. This is where Ruby's syntactic sugar comes in, allowing us to transform the above into something more natural:

# def default=(value); ...; end
h.default = "Go fish"

# def +(str); ...; end
"Hello from " + self.to_s

# def [](index); ...; end
a = [ "a", "b", "c", "d", "e" ]  
a[2] +  a[0] + a[1]        #=> "cab"  

This is more in line with what we see in most other languages, but the important point to take away from this is that Ruby gives us the power to define our own methods that can take advantage of special syntax.

This is an extremely important and useful feature. It allows the programmer to build an API for their objects that conforms to the overall language design. In the FancyCapitalHash example, we can expose the same syntax as the built-in Hash class so as to provide a drop-in replacement.

In more traditional languages, one could implement the assignment syntax using properties (setters), much like attr_accessor does. However, we can apply the assignment syntax to any arbritary method in Ruby -- even ones that don't actually assign anything if we wanted to! This flexibility is one of the reasons why Ruby is home to many DSLs (Domain Specific Languages).

def next_message=(msg)  
    puts msg
end

next_message = "hi"     #=> "hi"  

Ruby is simple in appearance, but is very complex inside, just like our human body.
-- matz

The importance of creativity in web development was emphasised recently in one of my Web Technologies lectures.

You need technical skills for web work, to know how to do things. But you also need creative skills, to know what looks and feels good.

This seems a bit obvious at first; the frontend is what our users see, and so it needs to look appealing and instantly friendly to use. However, frontend technologies are becoming increasingly complex. With the advent of HTML5 and modern JavaScript tools we are able to do more on the client side. To support this, we now have access to powerful debugging capabilities built directly into our browsers. In essence, it seems that the frontend is becoming more of a technical playground than it is a creative one.

As the complexity of JavaScript applications increase, developers need powerful debugging tools to help quickly discover the cause of an issue and fix it efficiently.
-- Debugging JavaScript - Chrome DevTools

Complement this with the multitude of CSS frameworks available to us now, making it easier for developers to design semantic websites by conforming to well thought-out standards. This is more in line with traditional desktop/mobile application development paradigms; standard libraries with standard components. I have already spoken about how useful this can be for developers, standards are a good thing. They allow users to become familiar with the components of a web page through uniformity. However, does this not impact our creativity?

It's not fair to say that every website built using a framework will look like the scaffolding the framework provides. The point is to customise to the look and feel you want, whilst still making use of a set of standard components. Going back to the mobile/desktop application analogy, all apps use the same user interface APIs whilst also being visually different from other apps. However, it makes it very easy to fall into a trap where it's easy to ignore customisation of the look and feel. It already looks great with little to no effort, why spend time on design when we can have more fun with the technical problems in our apps? I have seen countless production web apps that so obviously use Bootstrap -- granted these mostly consist of web apps hacked together in a short amount of time, where the word production can be used lightly ;).

The web is moving super fast (24 years ago it didn't even exist), and there have been interesting trends, such as Web 2.0, asynchronous requests, and responsive design. More recently though, we have seen a shift from skeuomorphism (realism) to flat designs. Flat design is picking up fast, and suggests that developers are more interested in focusing design towards usability rather than trying to wow users with flashy, creative illustrations.

I can't help but feel that this subject is close to home for me. My entry point to the world of technology was the web. I started learning HTML and CSS at the age of 12. I can vividly remember spending hours of the day designing web pages in Photoshop. Nowadays I am more a programmer than a designer. I can't remember the last time I touched a glorified paint application, but I'm on the terminal every day. I ferociously stick to my frontend development tools and frameworks, because functionality matters more than nitty-gritty design details.

What happened to all that creativity? I like to think, for the sake of sanity, it's still there. Only it's transformed to accommodate a newer mindset, one of a programmer. Writing well written and documented code is as interesting as writing a novel. Working in a complex development environment is as productive as working in Photoshop. Overcoming a technical hurdle is as beautiful as amazing scenery.

So no, I am not losing my creativity. I am simply applying it where I need it most.

Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn't really do it, they just saw something. It seemed obvious to them after a while. That's because they were able to connect experiences they've had and synthesize new things.
-- Steve Jobs

I haven't posted here in a while, and that's just as well; I've been caught up with exams, CeeVii, and battling blog post ideas in my head.

I like to try to keep up with the latest in software development, through various social media -- most notably Twitter and Hacker News. Today, a very interesting tweet popped up on my timeline by one Ryan Bates (Railscasts).

Ever the curious and proud (of my opinions), I naturally checked the poll out. It striked me as interesting mainly, because Ryan is well known to use TextMate v1 in his screencasts.

At the time, the poll was actively changing but the results were already clear. However, I passed time -- watching two episodes BBC's True Love, and doing some work -- in order to get a clearer picture once the voting had died down.

The results

vim is a winner, so the majority of this sample of Ruby/Rails programmers say. It's really interesting to see Sublime Text 2 as the runner up here though, given it's pretty much the new kid on the block. However, it's not so much a surprise, since it's an amazing cross-platform editor that acted as a nice upgrade from TextMate before TextMate 2. In third place, the notorious TextMate 1.

From the world map on gopollgo, the majority of users in the UK use vim. There seems to be a good divide between vim and Sublime users in the States, though.

When I first started out programming, I swore by IDEs -- simply because they seemed like the easiest thing to use to program in a language effectively. Back then, I probably hadn't even heard of vim or Emacs. It was when I started using git that I got introduced to vim -- and not in a good way (when I used to forget the -m flag). I didn't know any of the commands, and so I relied heavily on nano when I started working with VPSs. Today, I hate the idea of using IDEs (they're sluggish, and intrusive), and I swear by Sublime Text 2 (in vintage mode i.e. vim's modal and command set) for development, and vim for sysadmin.

What I learned from my experience is that when I started programming, having all the features mattered. As I gained experience, I learned that customisability mattered much more. So it truly surprised me when the subset of results for 12-17 year olds showed vim to be in the lead. As we move up to 18-24, vim and Sublime are an equal match. 25-34, vim. Interestingly, the 34-44 age group puts Sublime in the lead, but the vim users are still a force to be reckoned with. Although the samples are small, there is something thought-provoking about these results.

One thing I gathered about the Ruby/Rails community, is that the majority are visually driven -- myself included -- and I suppose this derives from the beautiful Ruby syntax. There's also a large number of Mac users within the community -- this probably derives from the heavy influence of DHH...

So it was fascinating to see that although Sublime is not so far behind for Mac users, vim is most preferred.

Sublime Text 2 is out of beta!

In news relating to this, Sublime Text 2 launched out of beta today (well yesterday since it's 3am as of writing this). Exciting. A particular comment sticks out from the Hacker News thread on the topic:

You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several.
-- msluyter http://news.ycombinator.com/item?id=4162623

I was going to learn a couple of languages this summer just for fun, but was told something along the lines of the above. I'll instead be focusing on some open source projects I have in mind -- but may still try something -- no harm in learning. I couldn't agree more with the quote though, when it comes to programming tools or programming languages. Cliché time, 'it's more about quality than quantity'.

The live poll

Recently faced with a designing task, I thought it would be a great time to try out Bootstrap, and see what all the fuss is about.

I was a bit weary of picking up Bootstrap initially. When it comes to web design, the uniqueness of a website rates highly -- at least from the designer's point of view. Bootstrap offers a confined set of default styles to work with, which although are easily and highly customisable for those fortunate enough to be gifted in CSS and frontend development in general, can drive inexperienced designers to creating uniform designs.

There is another side to this however, in that the uniformity of designs, to an extent, is not such a bad thing. From a users point of view, they will be more familiar with the sites they visit. I'm personally not so sure about this idea. I've constantly found myself finding sites that barely customise their layouts, and thinking... 'Oh, another bootstrap site...'. Having said that though, if your user base isn't very tech savvy, your users won't know what Bootstrap is. Instead, they will simply think something along the lines of, 'Oh, this site has just copied another site I've seen... that's pretty crappy of them', and you definitely do not want your users thinking that.

I did thoroughly enjoy using Bootstrap, though. It's an awesome, extensive framework for creating beautiful designs without putting in much of the effort. I did, however, only end up using a couple of the Bootstrap components in my prototypes, the grid system, labels, icons and buttons. The way I see it though, these components are exactly what makes Bootstrap shine, most notably the grid system. They don't get in the way with your overall layout, and are generally a core component of most sites. It's rare to see a website without buttons, and so here it makes sense to have a conventional look and feel.

I can't stress how great the grid system is. Gone are the days of worrying how many pixels each column should be, and responsive designs are becoming more and more important as we readily move into the world of mass mobile computing. If you don't want Bootstrap for just this though, Adapt.js is a great lightweight alternative. (although Bootstrap can be custom downloaded to include only their grid system anyway)

I realise I'm probably preaching to the choir here, I jumped onto the Bootstrap bandwagon a little later down the line, but better later than never right? Nevertheless, great work all you lovely guys at Twitter!

That's right, you need to if you don't already. There are a bunch of easy to use, WYSIWYG website makers out there these days. In fact, such tools are what I first used in my early days of learning web design. They're getting more popular now though, and people who only need a simple static website will be cutting out the middleman and going straight for one of those cool web building apps all their friends have been talking about.

This sucks for a web designer, but it's true. I'm always seeing advertisements on TV for full-featured web building sites like Weebly or even sites like Template Monster that sell website templates that any user can edit, in something as primitive as Microsoft Frontpage (or whatever it's called now). You'd think we'd be able to stick 'em after they get lost trying to find hosting, but some of these sites even do that for them -- it's despicable. Who would have thought web designers would sell out their own kind, shame on you Weebly!

It gets worse. Blog writers and the like are easily setting up software like Wordpress or Drupal with a 'one-click install' on their snazzy cPanel boxes. Don't think they'll look for a web designer to skin their blog -- no no, they'll be searching for a free or cheap theme for their CMS/Blog software thing on one of the many sites that provide them. Once again, doing away with the poor old web designer. He's got kids to feed, you know! Why don't you think about that before you click your 'one-click install' next time, hmm?

So you understand the problem now? Maybe you already did, and came to this post to find a revelation that could fix up your incomes. Maybe you already know server-side programming and are just getting all nostalgic.

Or maybe you're one of these vile users that shuns the idea of hiring a web designer, because 'you can do it all yourself'. Well there's still one place we can stick it to you mate, the server-side. You probably don't even have a clue about what I'm talking about, do you? Well who's laughing now, eh? Go back to your fancy cPanel, and enjoy freeloading until you realise you do really need us.

A purely custom built site will always need to be developed and designed by a web designer, and the demand for dynamic custom built sites is probably higher than that of static custom built sites. So learn PHP, Ruby on Rails, node.js. Learn some system management whilst you're at it. That's the transition I've made these past few years and my perspective on web development has geared for the better. Do it, it won't hurt (at first), and you'll be better off in the long run. Web designing can make you money, web development can make you ten fold.