Seshbot Programs

Every programmer should know how to give technical interviews. Although you will rarely be judged on your interviewing abilities, it is definitely in your best interest to help ensure your company is hiring effective programmers. If you manage to surround yourself with great programmers you’ll foster a much better environment in which you can become a great programmer yourself. If you find yourself surrounded by programmers you consider sub-par you’ll end up supporting their crappy software.

I have been interviewing programmers for many years and reckon the best way to find great programmers is by giving them some control over the interview topic, and then going deep into a few questions instead of broad across many topics. This takes a lot of guts however – it requires the interviewer to pay attention, and ideally (though not necessarily) to have a fairly broad knowledge base themselves.

I believe this advice applies to all programmers – of course interviewing is rarely in your job description, but it is definitely in your best interest to make sure interviews get done well at your company. Unfortunately most companies will allow anyone to interview and won’t have a good way to tell that they’re not doing it well, ultimately damaging the work environment.

This post follows on from the previous post creating and deploying a rails + ember app from scratch. In that post I created a basic ember application being served from rails. Here I’ll be adding user authentication to the application I created using the ‘edge template’ option I discussed, which uses the ‘ember-rails’ gem to establish the basic connectivity.

I do not want to implement authentication and authorization myself. It is tricky to get right and tends to cause huge damage when it goes wrong in production.

So I have spent at least three full days looking at various solutions I can build into my simple Ember/Rails application and spent a lot of time experimenting.

This post describes my current understanding of authentication for web applications, and the approach I used to implement a basic authentication system I put up on heroku at http://seshbot.herokuapp.com

If you want to see the source code, have a look at https://github.com/seshbot/new-ember-rails-app

NOTE: this is very text-heavy because after three full days I decided not to spend too long on this blog post. Therefore there are no images at this time. I may update it later to have some nice UML or screenshots, but that time is not now.

Today I decided to wield my new Rails and Ember knowledge and… look into yet another new technology. I thought it would be helpful to have an online app to demonstrate the fruits of my labours, so am deploying a new app to Heroku.

Heroku is an ‘application platform’ in the cloud, meaning that you can push certain kinds of apps (written in Ruby, Python, Java and Node.js) and it will ensure all the correct infrastructure is in place. When you sign up you get to host one app for free so it’s easy to try out.

Later I will probably move to Amazon Web Services, which provides a basic virtual machine in the cloud that you can do anything with. This will allow me to host multiple applications without having to worry about paying money. Heroku does offer some pretty nice scaling, monitoring and deployment tools though (the admin panel literally has a slider to allow you to spin up new application instances.)

This post shows how I went through all steps, including setting up the PostgreSQL database on OSX, creating a skeleton Rails app, and deploying to Heroku. It is a culmination of having gone through several sources:

• much was taken from this useful step-by-step ‘Rails + Ember blog post’ and this follow up post that incorporates changes for newer versions of the frameworks.
• when I got to the part involving installing the ‘ember-rails’ gem, I found that the ember-rails documentation was pretty useful.
• some of the Heroku stuff came from the Heroku Code School lesson summary.

Note: The formatting of this article is not great, but I pumped it out quickly after going through the tutorials

I dedicated this morning to learning some Ruby and Ruby on Rails (RoR). For my purposes, RoR provides the server-side API to a web application, like this:

To my delight, I quickly discovered that Ember (which I have been messing around with quite a bit) is modelled directly on Rails – not just in the generic they-are-both-MVC-architectures-way, but down to their usages being identical in many respects. I think many new webby techs follow this same style (Meteor seems to, for example.)

This post outlines the core concepts I have picked up from the various tutorials. I also included a RoR cheat-sheet I created while doing the Rails tutorial.

To get started on Windows/Mac, I’m guessing the easiest way is by downloading the RailsInstaller.

First here’s a quick summary of what I got up to:

1. trying to build a simple ‘gaming table’ application in Ember.js,
2. styling with Twitter bootstrap,
3. messing with plugins in my blog (trying unsuccessfully to fix code highlighting, and adding a UML tool – see below)

I spent most of my time learning about Ember. Ember.js is a very nice looking front-end MVC framework that has a very appealing getting started guide that make it look super simple to create a reactive application. Three things that people will not tell you however:

• demo videos only ever show the main usage scenario of that framework
• most new frameworks change so often that they’re either unstable or very little up-to-date documentation exists, and
• many of the benefits they offer you probably won’t end up using anyway, for various reasons

For now though I’ll go ahead with it because I feel that I’m just about to start doing cool stuff in it (it kinda always feels like this though.)

Next week I’m thinking of switching back to some C++ stuff so I can dabble in a realm I’m more comfortable with for a while… Monday is a public holiday in Japan though so I’ll probably be wandering around and not programming much.

It is a fact that every programmer is the star of their peer group, and would spin out the most awesome cleanly-built apps if only he or she didn’t have to work under these circumstances. It is also a fact that every programmer understands that they were terribly misguided just a few years prior.

Given these two facts, I would have to think a whole lot of myself to give advice on programming to other programmers. I happen to know however that I am in fact a better programmer than most, and am therefore uniquely qualified to offer such advice.

So here’s some of the things I feel I’ve learned the hard way – at least enough that every time I work on a project they jump to mind and guide my actions.

The web development scene has moved dramatically since my own minor experience at an Internet business company 14 years ago. Back then we created web pages in ColdFusion/PHP/ASP marked-up HTML. Our main tools were frames and tables and a lot of homegrown convention to ensure headers/footers looked right. We spent most of our efforts on effectively using CSS to make our lives easier – not separating views from data or dynamically updating HTML elements.

People now create web applications instead of individual pages. Web apps look a lot like native applications, are responsive and dynamic, and have very high-level frameworks that provide application-wide abstractions for business models and the abstraction of the view logic.

This article describes my current understanding of the technologies used in constructing modern web applications, largely based on a few years’ lurking on Hacker News and a couple weeks’ not-so-intense investigations.

A few months ago I decided to hand in my notice and live off my savings for a while. In 13 years of software development this is the first proper hiatus I’ve taken so I have no idea what to expect.

I intend to spend the next six to twelve months attempting to see what happens when I have time to myself.