Profit Center Based Work

When it comes to work that will build a great career, Patrick McKenzie has great advice:

Profit Centers are the part of an organization that bring in the bacon: partners at law firms, sales at enterprise software companies, “masters of the universe” on Wall Street, etc etc. Cost Centers are, well, everybody else. You really want to be attached to Profit Centers because it will bring you higher wages, more respect, and greater opportunities for everything of value to you.

The gist is that you want your role at the company to correlate with revenue generation.

If your role leads to more revenue, your role will always be in demand.  Sales functions have so much money allocated into them with the expectation that it is an investment. Back office tasks (HR, accounting, etc.) are essential, but they do not generate gross revenue and are always on the chopping block.

Maintainable Client JavaScript

I’ve been reading Maintainable JavaScript by Nicholas C. Zakas lately. It has been very insightful into best practices across larger teams. When you have a large team and adopt a consistent coding style, it makes working across your codebase easier.

In Chapter 5 of the book, Zakas covers the UI as a mix of HTML, CSS, and Javascript. He mentions that tightly coupling these three layers makes it “impossible to make small changes without changing one or two other layers.

Also, I’ve been working with AngularJS recently. I understand the benefits of a front end framework to keep data in sync throughout your client. Angular fans tout the benefits of a SPA (single page application) framework.

As someone who strives to separate the structure (HTML) from the scripting (JS), Angular feels too tightly coupled to me. Angular works by tagging everything with [cci]ng-[/cci] and letting the magic work behind the scenes. The application dependencies are hardcoded everywhere in your HTML, and there is no way to swap your framework without changing your HTML drastically.

I’ve worked with Backbone in the past, and now I’m trying out Angular. At some point, I’ll probably try out Ember. I’d like a front end framework that plays well with Rails, so perhaps Ember will be fun.

Leaflet JS with Open MapQuest Tiles

With CloudMade changing their API to focus on enterprise customers, I had to find an alternative for hosted map tiles.

There’s a good gist from mourner that shows Leaflet.js TileLayer shortcuts at https://gist.github.com/mourner/1804938

Instead of the old CloudMade tile tutorial used on Leaflet:

[cc]

L.tileLayer(‘http://{s}.tile.cloudmade.com/API-key/997/256/{z}/{x}/{y}.png’, {
attribution: ‘proper attribution goes here’
}).addTo(map);

[/cc]

You can use Open MapQuest:

[cc]

L.tileLayer(‘http://{s}.mqcdn.com/tiles/1.0.0/osm/{z}/{x}/{y}.png’, {
attribution: ‘proper attribution goes here’,
subdomains: [‘otile1’, ‘otile2’, ‘otile3’, ‘otile4’]
}).addTo(map);

[/cc]

Just make sure your attribution properly reflects all your sources.

Developer Education

As an avid tech news reader, I’m able to follow industry discussions about hot new start ups.

For example, startups such as Snapchat, Pinterest, etc. have garnered a lot of hype. As a technology enthusiast, what is my duty to try out new apps / sites?

Is it enough to know about them? Is it enough to have tried them? Is it enough to know how to recreate them?

Misc Rails Integration Test Tips

I attended an Automated Testing meetup yesterday. In my experience, integration tests turn your speedy test suite into a slowpoke. Here are some different tips and gems to consider using in your tests:

  • rack_session_access Gem
    Instead of making a user log in with capybara, why not set the user_id in the session. This gem sounds amazing.
  • fuubar Gem
    Another way to format your test results. Perhaps you’d like to use a progress slider.
  • rspec-retry Gem
    If a test does not pass on the first try, you can run it again until it passes. This feels like a code smell. In the meetup, the speaker mentioned that they were running their tests against live web requests (instead of pre-recorded requests).
  • Page Objects
    Capybara syntax seems procedural since you are telling it to visit a path and click on things. With page objects, you can have DRY code that abstracts away all the step by step page interactions with something like [cci]ProjectPageObject.create[/cci]
  • View Tests
    Instead of doing full blown integration (feature) testing that uses a browser, you can try view tests that assert things are found on your page.

Hopefully you can use some of these tips to improve your test suite.

Ruby Gems Tip: Check Your Version

Quick ruby gems tip:

If you are having issues with a gem (and it seems like the issue has been resolved in the github repo), double check your gem version.

Even though I had the latest version of a gem by having [cci]gem ‘leaflet-rails'[/cci] in my Gemfile, the latest version wasn’t bumped up at http://rubygems.org/ (Note: Nothing against leaflet-rails, which is awesome. They’re simply used as a recent, real-life example. )

You can make sure you’re using the latest version of a gem (as it appears on github) by specifying the repo & commit hash:

[cc]gem ‘leaflet-rails’, git: ‘git@github.com:axyjo/leaflet-rails.git’, ref: ‘0f50faaa35d41e8ba24c73c97d265e061b159d81′[/cc]

This will lock the specific commit in place in your Gemfile.lock

iOS Simulator

When previewing a site on my iPhone (1136 x 640), I wasn’t satisfied with using my iPhone 5 or a Chrome browser Window Resizer app.

Turns out it’s super simple to use the iOS Simulator with Xcode on OS X (version 10.8.5).

Select Xcode > Open Developer Tool > iOS Simulator

xcode

You’ll be presented with an iPhone to navigate within. Select Safari and you can use a site like localhost:3000 for development.

 
ios_sim