Codesta Weblog

Responsible Electronics Recycling for the Pressed-for-Time

Working in software development has the inevitable side-effect of producing, from time to time, a few cast-off electronics, whether old, obsolete, or broken. Here in the Codesta office, we’ve been dutifully amassing ours on a table by the lunch room, in preparation for the day one of us might have time to haul our e-junk to the only local place promising safe disposals: a city-run collection depot in the Portlands area, way on the other side of town.

Enter Shift, purveyors of “Convenient, Secure, Electronics Recycling”.  Having grown weary of the sight of our mountain of keyboards and dead UPSs, all it took was a direct-mail postcard, promising speedy and affordable pick-up from our office. By day’s end we’d arranged to safely and ethically divert or recycle much of our cache of unusable gadgets through Shift. They came on the specified date, whisking away the whole heap, for a little over $30 – both in time and money, a significant savings vs. making use of the city-run options. Shift promises 100% of what they collect will be diverted from landfills and recycled responsibly, and we like that.

And as for Toronto’s own municipal plan for ever-increasing e-waste, we look forward to continued improvement: more Community Environment Days for easy disposal, and better e-waste collection options for multi-unit buildings like ours, in the vein of those now offered for street-level residential dwellings.

Basic Smartphone Support for your Ruby on Rails website

Building a maximum-compatability mobile website is a relatively large undertaking, and that's not what I'm talking about here. The latest smartphones have the ability to render HTML quite well, and just require a site design amenable to viewing on a small screen. This post is about one way to provide separate layouts based on the user-agent of the device hitting your website in Ruby on Rails. It is a rather simple approach intended to get you started as opposed to being a production ready example.

How to detect a mobile browser?

So, jumping right in... how do you detect a mobile browser?  I'm sure there a fair number of ways, but I chose to use the WURFL library (which you should download - the download link is the first one in the left column of the home page).  A quick Google search provided me with the WURFL-Lite gem which provides a thin layer on top of the WURFL data making it quick and easy to integrate it into our site. This is a "big-stick" approach as WURFL contains way more information about the device than we need at this point, but it would allow you to customize your site based on the capabilities of the device in the future. To add the gem to your project just add the following line to your Gemfile:

gem 'wurfl-lite'

Then run bundle install to install the gem on your system. Note that this gem does not store the data in a database, it reads it all into memory - depending on your needs this may or may not be the right approach.

Now that the gem is installed, open the application_controller.rb file - this is where we will be adding some helper methods that will be accessible to all of your controllers and views. First off, we need to load the WURFL data, which is going to take a while so we want to do it as few times as necessary. There are lots of different issues with trying to do this cleanly, so I'm going to start off with a simple approach; I'm going to store it as a class variable like so:

class ApplicationController < ActionController::Base
  @@wurfl_db = nil

  private

  def wurfl_db

    #Try getting the data from the cache, this

    #significantly speeds up performance in the

    #development environment.

    @@wurfl_db ||= Rails.cache.read('wurfl_db')

    if !@@wurfl_db
        @@wurfl_db = WURFL.new "#{Rails.root}/wurfl/wurfl.xml.gz"

        Rails.cache.write('wurfl_db', @@wurfl_db)

    end

    return @@wurfl_db
  end
end

To turn on caching add the following line to your environment.rb file:

ActionController::Base.cache_store = :memory_store

NOTE 1: In the development environment class variables are tossed between requests, meaning that we would have to load the WURFL data every time - which is quite slow. Using the rails memory store was a quick and easy solution, although there is still a small but noticeable decrease in responsiveness in the site. If you are trying to run some tests on your dev environment and the extra time taken to load the wurfl data is a problem, then I would suggest temporarily setting the config.cache_classes to true in your development.rb.

NOTE 2: If your web server uses multiple processes you will end up loading the wurfl database once for every process. Depending on how many processes you expect to run, that could be a lot of wasted memory. If that is the case then it might be worth investigating memcached or a similar caching store, or consider moving the data to the database.

Now that we have the WURFL data loaded into memory we can use it to identify the device browsing our site. Create a new helper method:

class ApplicationController < ActionController::Base
  @@wurfl_db = nil
  helper_method :is_mobile_request?

  private

  def wurfl_db

    #Try getting the data from the cache, this

    #significantly speeds up performance in the

    #development environment.

    @@wurfl_db ||= Rails.cache.read('wurfl_db')

    if !@@wurfl_db
        @@wurfl_db = WURFL.new "#{Rails.root}/wurfl/wurfl.xml.gz"

        Rails.cache.write('wurfl_db', @@wurfl_db)

    end

    return @@wurfl_db

  end

  def is_mobile_request?
    return !wurfl_db[request.user_agent].nil?
  end
end

Now you can call is_mobile_request? from any of your controllers or views to perform custom work for either mobile or desktop.  

Choosing your layout

As long as you have built your site using best practices (i.e. putting your styles into your appliction.css file instead of in-lining them in your html.erb files) then you can easily switch between layouts without having to make any changes to your views. You now have a choice, you can modify your existing layout to use the helper we created above or you can create separate layout files. I am going to go with the 2nd approach since I want a clean and obvious separation between my mobile and desktop versions of the site.  We can do this right in the application controller:

class ApplicationController < ActionController::Base
  @@wurfl_db = nil
  layout :determine_layout
  helper_method :is_mobile_request?

  private

  def wurfl_db

    #Try getting the data from the cache, this

    #significantly speeds up performance in the

    #development environment.

    @@wurfl_db ||= Rails.cache.read('wurfl_db')

    if !@@wurfl_db
        @@wurfl_db = WURFL.new "#{Rails.root}/wurfl/wurfl.xml.gz"

        Rails.cache.write('wurfl_db', @@wurfl_db)

    end

    return @@wurfl_db

  end

  def is_mobile_request?
    return !wurfl_db[request.user_agent].nil?
  end

  def determine_layout
    if is_mobile_request?
      return "mobile_application"
    else
      return "application"
    end

  end
end

Next you will need to create a couple of new files.  A public/stylesheets/mobile_application.css stylesheet, and an app/views/layouts/mobile_application.html.erb layout file. You can probably start with a copy of your application.css and application.html.erb.  There are a whole bunch of things that you might want to do in your mobile layout and styles that are beyond the scope of this article, but a couple of key items are:

• Load your new mobile_application.css style sheet instead of the application.css
• Add a <meta name="viewport" content="width=device-width, initial-scale=1.0" /> element to the <head> section.  This will set the width of your website to the width of the display.
• Update your mobile stylesheet so that clickable items have a fair bit of space between them or are otherwise large.  Touchscreen finger presses cover a relatively large area.
• Create icons for your site - this is unfortunately very phone specific, but you can add links to icons that phones will use to identify your site. e.g. <link rel="apple-touch-icon" media="screen and (resolution: 163dpi)" href="icon57x57.png" />
• You may also want to provide the option for overriding the layout choice so that a user can choose to view the mobile or desktop site in case the device detection fails.

Checking that it works

If you have a mobile phone handy then just hitting your website should give you an idea as to whether it is working or not. If you don't have one handy then you can use one of any number of browser add-ons/plug-ins. I use the Modify Headers add-on for Firefox and set a User-Agent header with the user agent string for whichever phone I want to emulate. This is especially useful if you are doing something specific for a particular set if phones but don't have them all on hand to test with. Another option is to set up an Android development environment and created a bunch of virtual devices with different screen sizes and use the emulator to test your site.

The Codesta Hiring Process

Codesta often recruits for new software development talent and I thought it would be a good time to document our hiring process for all of our candidates so you understand our process and why we follow it. Our goals are similar; we want the best employees we can find and you want to work at the best company you can find.

Our process has 5 steps:

1. Resume Screening
2. The Questionnaire
3. Phone Screen
4. Half Day Interview
5. Offer Letter

The process is based upon the idea of a continual escalation in time and effort for both Codesta and you, the Candidate. At any time in the process either of us can call it quits with, hopefully, the minimal wasted time and effort. If at anytime you realize that this is not the position for you please let your interviewer know, we will appreciate your candor and professionalism. We make the same promise to you, we will not waste your time once we realize you would not be a good fit for Codesta.

Resume Screening

We screen resumes heavily. We get a lot of applicants and we reject the majority of them. We look for people who have demonstrated success, have done the types of work we do, have a solid background in Computer Science, and have a wide range of technical interests and abilities.

Questionnaire

This single page of questions allows us to get a lot of the standard questions asked ahead of the interview. There really isn't a right or wrong answer to most of these questions, just do your views match our culture. If you are the right candidate answering these questions should be easy; they are issues and questions you have discussed with co-workers and classmates and you already have opinions.

Phone Screen

A 20 to 30 minute call to verify some details on the resume, perform a quick coding test and answer a few questions about the position.

The purpose of the screening call is to reduce the risk of wasting your time or our time. We want to weed out clearly unqualified candidates and we want to ensure that qualified candidates are actually interested in the job being offered. Once we explain the type of work we do, some candidates are more excited and others are no longer interested.

Weeding out uninterested but qualified candidates is actually the most important part of the phone screen.  It's pretty easy to eliminate unqualified candidates, they won't get past the coding or problem solving stages anyway. The worst thing that can happen is to get an excellent candidate who really doesn't want the job we are offering. You don't want to spend a half day in interviews just to get a job offer you are going to decline either.

The online coding test is meant to be quick, most candidates finish this in a few minutes and we don't let that part of the interview go for more than 10 minutes.

The Half Day Interview

At this stage we will invite the candidate into our offices for a in-person interview. This part of the process takes between 3 and 5 hours.

Coding Assignment:  We will ask you to implement a fairly complicated software system in a basic text editor.  We will not be compiling the code and a developer from Codesta will be there the entire time to answer questions and provide hints. The intent is to see how you develop code, your style and how you adapt to errors and problems. At the end you'll be able to ask the developer more about Codesta, the working environment and what kinds of projects we do.

Design Exercise: We will ask you to design a system on a whiteboard.  As with the Coding Assignment, a Codesta developer will be there to answer questions, clarify requirements and provide hints. We want to see how you think on your feet and how you solve problems.  At the end you'll be able to ask the developer more about Codesta, the working environment and what kinds of projects we do.

General Interview: We will ask you questions about you resume, how you would handle interpersonal situations and problems, questions to test your soft skills and business acumen. We want to see how you would do in this role. This part of the interview will usually be conducted by the Managing Director. You will have an opportunity to discuss the role in depth, ask questions about how we conduct business, projects and opportunities for advancement.

Once you leave the office the three people who interviewed you will meet to discuss how your interview went.

The Offer

If everything goes well, you'll be presented with an offer of employment. We try to make these as soon as possible after the onsite interview.

That's it! We take the process seriously and work very hard at finding the best candidates for Codesta. We hope you found this article useful and look forward to your application in the future. Good luck!

Thoughts on the failure of Google Wave

When Google Wave was first announced I was among the many people who were very excited about the potential.

I realized at the end of July that my Google Wave account had no activity since March and started thinking about why that was. I started writing this article with the intent of describing why I thought Wave hadn't taken off when the cancellation announcement was made. So, after revamping, this is why I believe Wave failed as a product.

It fixes email: Why we were excited in the first place

The only reason the failure of Google Wave is interesting is because of how much excitement it generated when announced. When I first saw the Wave video it demonstrated what seemed like viable solutions to some of the major problems with email:

1. I can fix typos, mistakes and even factual errors after a message is sent.
2. There is excellent threading and management of replies. 
3. People can join the conversation and stay joined. People can be added that were inadvertently left off the original invite list and immediately join the conversation.
4. Attachments are only sent once and then are always available. No digging through my archive for the original message and attachments.
5. Email can't switch to real-time. Wave is real-time. I often leave email and IM somebody when the emails are flying fast.

The promise of improving email was an elixir and we all waited to drink with bated breath.

It's not email: Why it failed

It solves some of the problems with email by eliminating email, but then introduced a whole new set of problems which broke a whole bunch of things that email fixes!

My Head Hurts

One of the coolest superhero powers is mind reading. It's also one of those superhero powers that would never work in real life. Having this power would make simple things like going to the mall a hell on earth; the thought noise of hundreds of insipid teenage shoppers, bored store clerks, shoplifters, flirting couples, etc. would drive you mad.

This is Wave in a nutshell. If it did replace email and IM, my inbox would be a non-stop cacophony of line noise; PM's composing emails, proposals being written, the first half of a note from my wife about plans for tonight, job applicants responding, friends arranging events, urban legends from my Mom ...

And this noise couldn't be ignored like twitter. Half of those responses would be information I was waiting on.

HR Hates Me Now

Depending upon your communication style Wave could be disastrous. I tend to type messages and then edit them; or think better of some ill advised comment and delete them entirely. In Wave I'd be either inadvertently insulting or look like a moron until I corrected my messages.

Like laws and sausages; nobody should see how my email and IM messages are made.

Why Am I Using this Again?

My entire dev team created accounts and we played with it for a couple of days but then haven't used it in a couple of months. We are heavy users of IM, Yammer and Email but couldn't really see a use for Wave.

Communication tends to take two forms: quick comments/questions with a quick follow-up or deliberately worded communications. We have IM and Yammer for the first and email for the second. Wave is a poor substitute for IM and is, if you don't need real-time email, a closed network email system.

Real-time collaboration is something you do rarely and it's almost always a document, a design or code. Wave doesn't help with design (mostly a white board activity) or code (mostly a pair programming activity). We have Google Docs for real-time document collaboration now.

Wave promised to merge IM and Email but that didn't really pan out. You still need IM after all.

Spam

As somebody who worked in the Anti-Virus/Anti-Spam industry for years my first thought was "Cool, an entirely new vector for spam and viruses." Sure enough, a Spam button appeared soon after. In a closed environment.

All Those Technical Problems

The slow, uneven roll out meant that whenever you finally got access to Wave, your friends were either bored with it already or were stuck waiting on Beta invites. Contrast this with Gmail where I got an early beta and then immediately got five invites that also worked immediately. Also, with Gmail, I was able to test it using other email services. I applied for developer preview access which I didn't get, then had 2 beta invites sent to me that never arrived and finally got access on the 3rd beta invite in February of this year. That's not the way to build ground swell support.

There are a large number of user interface issues that exist in Wave that make it unsuitable for it's primary purpose of real-time communications. The way everything jumps around if more than one person is editing at a time, selecting the section you want to edit is error prone and you will often miss; it's more like a game of TF2 than an editor. The new versions of the UI were better but it's kind of moot now.

The versioning system is terrible; rollback is not a viable versioning mechanism.

It's a closed system. The only use I could see for Wave is taking an email Exchange "real-time". Since it's not email this feature is not even available.

No data import or export. I've just collaborated with a co-worker and come up with a great new idea; now how do I get that stream of data into a Word document to send to a VC to make us all rich? I can't.

Help Us Help You!

We have more details now on our needs in Software Development. We're looking for a great resource to join our team and contribute to projects. The job description is provided below, and we'd like to add a couple of key notes:

1. Robust Development Experience Needed - Codesta is not a place for domain experts, or people wanting to master one area of technology. We're a change driven organization and new is our mantra. You must thrive in this environment to be happy here.
2. Excellent Communication Skills Required - You will be interacting directly with our clients. Conference calls, email and in-person meetings are the norm here. The ability to communicate ideas and their benefits is core to our success.
3. Decision Making Chops - We give our employees significant responsibilities, and our best people know when they need to escalate, delegate or contemplate. Our ideal candidate will understand these needs and demonstrate the ability to get things done.

We hope these comments provide insights into the person we're looking for, and we can't wait for that person to join us here at Codesta.

Position: Software Developer, 4+ Year Experience
Location: Toronto, Ontario

Do you love building new products & services? Do you like learning new technologies and methodologies? Do you take ownership of your projects and productivity? Then Codesta is the place for you…

We have an immediate opening for an experienced Software Developer. Our ideal candidate is a talented technology enthusiast with experience using today’s common platforms and processes, such as Java/JEE, LAMP, C# /.NET, Ruby on Rails and Agile Scrum. You will join our experienced development team where you will interact directly with our customers and contribute to the development of creative products for client projects.

If this sounds like you, please submit your resume with cover letter including information on your potential start date and sample work to careers@codesta.com. No telephone inquiries please.

JOB OVERVIEW
- Develop software applications to meet client requirements
- Generate timings estimates for customer projects
- Actively interface with customers and provide general consulting professional services
- Continuously explore new technologies and professional skills

BREAKDOWN OF RESPONSIBILITIES
- 85% Software Development and Supporting Activities
- 10% Personal Development, Training and Internal Projects
- 5% Sales Support Functions

REQUIREMENTS
- Bachelor’s degree in Computer Science from an outstanding university
- 4+ years work experience in a software development capacity
- Highly skilled with Object Oriented languages including Java and C#
- Experience with one or more of Microsoft C# /.NET, Java/JEE, Ruby on Rails or LAMP stack technologies
- Experience with Web services (REST or SOAP), JSON/XML
- Previously handled projects from inception through deployment
- Strong application development and analytical skills, produces high quality, maintainable code
- Excellent communication skills, written & verbal, works well in a team environment
- Short travel and onsite work may be required from time to time
- Candidates applying for the position must be legally eligible to work in Canada
 
ADDITIONAL ASSETS
- Front-End web development experience a significant asset, including skills in JavaScript frameworks such as JQuery, Prototype, AJAX
- Experience with any of C, C++/ DCOM, XML, XSLT, Web Services, PHP
- Experience leading and managing project teams, including local and remote resources
- Software Design experience and industry best practices/development process knowledge

ABOUT CODESTA
Codesta helps companies design and create software products. We use a balance of people and process to turn ideas into innovative products. Our clients want to produce new products quickly and collaboratively using whatever toolset is needed to get the job done. We take an extreme amount of pride in our ability to contribute to our clients’ success by building robust, well architected applications. With offices in Palo Alto, California and Toronto, Canada, Codesta has built new products for companies across North America in sectors ranging from mobile to pharmaceutical to consumer imaging.