Thoughts for Thursday: Why I wouldn’t use Rails for a new company

Jared Friedman recently wrote a really great article on why he wouldn’t use Rails for any new company. There are a couple of factors that he looks at that makes this a really well written article.

First, he uses data to show the rapid decline in Rails usage by looking at Google Trends. Then he looks at Rails biggest performance headache: ruby. He compares benchmarks of Ruby to other languages. He points out that Ruby has no major corporate sponsor. He also points out the newer growing frameworks around and the job trends on Indeed.

This is a really good article, I would encourage you to check it out and read the Hacker News comments too.

Photo by Adam Bourg, screenshot of

Write better specs!

I love RSpec. It’s one of the best tools on the web for opensource developers to write tests. Nothing compares to its power, ability and extensibility. Mocha and Chai for Javascript pale in comparison to its ability to test.

That said there are some really terrible spec files out there. I’m wholly grateful for a resource you all must checkout if you write Ruby or RSpec, its called “BetterSpecs”. Its a online resource containing examples of bad ideas and examples of better ideas and finally examples of best practices to use when writing RSpec tests.

Check it out, it’s totally free: 

Thoughts for Thursday: Lazy rebasing

Rebasing is extremely useful, lets say you branched off of release 1.8.3 and need to fix a defect, but it wasn’t completed until 1.8.3 was already on production and 1.8.4 is the new hotness. git rebase release1.8.4 defectBranchName will take defectBranchName and reapply the commits over release1.8.4’s history instead of what it was originally based off of.

The problem is if there are conflicts and sometimes there can be conflicts at every commit. So if possible, what I do is:

git checkout defectBranchName
git log

At git log, count the number of commits you made on the branch, N = number of commits to go back

git reset HEAD~N –soft
git stash
git rebase release1.8.4
git stash apply

Now you fix the merge conflicts, and commit. The downside is you lose commit history and can create issues if you do this on something like master because you’ll be changing history. It’ll be especially big impact if you work on a team and do this on develop or master, but your little feature branch should be ok if no branched off it.

Now there you go, a handy little trick to quickly get synced up with history!

Photo by heipei

My story

I’ve been developing for the web for over 10 years. I started writing for the web when I was 13. At 17 I got enough freelance work to pay for my first year of college (and buying a nice Macbook). It took me 6 and a half years of going to school while working full time to graduate. In all of that time I have learned a lot about the internet and about working with people. Continue reading My story

Thoughts for Thursday: You will always be more to your loved ones than a Job.

From Linkedin:

Research published in early 2015 found that globally unemployment caused 45,000 suicides per year. I am getting emotional just writing this because it’s just so sad and it’s not right. There is so much written and spoken material in the Western World around what we should strive for and who we should be. Personally I don’t have a PHD, I haven’t undertaken 20 years of research and I’m not a billionaire – so if that’s your criteria for success and or credibility, no need to read this layman’s “Pub Wisdom.”

Automated E2E testing using protractor

At UHG we use Protractor to test our Backbone app for automated E2E dev only regression tests. We do this as apart of an automated CI process to ensure every branch we ingrate doesn’t break existing functionaility. Today, I’m going to walk you through our setup and how you can use Protractor (an Angular tool) to test your non-Angular app.  Continue reading Automated E2E testing using protractor