One-off Webpages That Make Life Easier

Below is a list of one-off webpages that are extremely useful in my day-to-day life as a developer. I’d love to hear what other pages I am missing out on or if you have better versions of any of these tools.

1. JSON Beautifier: http://jsonviewer.stack.hu

Simple and clean UI. Handles broken/incomplete JSON very well.

2. Convert Java Date to Millis:  http://www.fileformat.info/tip/java/date2millis.htm

Converts both ways. Nothing special. When I don’t want to load Eclipse.

3. Amazon EC2 Instance Comparison: http://www.ec2instances.info

Not sure how Amazon doesn’t have something like this. Chart form. Easy to compare. Keeps up to date as best as I can tell.

4. Ruby Regex Tester: http://www.rubular.com

Clean UI. Legend at bottom. Able to easy test many inputs.

5. Git Cheatsheet: http://cheat.errtheblog.com/s/git

Commonly used commands with descriptions.

6. AWS Service Health Dashboard: http://status.aws.amazon.com

Quickly see if a service you depend on is having trouble.

7. AWS Service Pricing: http://www.cloudomix.com/pricing

Cost of all services and comparison. A lot of information.

8. Apache Hive Functions:  https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF

List of all built-in functions with descriptions.

9. TCP Variables:https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html

Simple list with descriptions all in one place.

10. Find Ruby Gems: https://www.ruby-toolbox.com

Quick way to find and compare gems with same purposes.

11. IP Address Lookup: http://www.maxmind.com/en/geoip_demo

Most reliable and matches most accurately.

12. Colour Palette Search: http://www.colourlovers.com/palettes/search

User generated palettes that you can search by color.

13. Online Diagram Creator: https://www.draw.io

Great for architecture diagrams.

14. Nerd jokes: http://devopsreactions.tumblr.com/archive

When you are having a bad day.

That’s all I have. These help me tremendously through my work day and help make my life more productive. What are yours?

Discuss on Hacker News.

Advertisement

Make your RSpec tests better

Below is a (non-exhaustive) list of good practices that I developed when writing my RSpec tests.

1. Use context blocks a lot.  TIP: Write your context blocks first and then fill in the tests.  It helps re-use and organization.

GOOD:

context "campaign has locations" do
  context "when locations < 10" do
    ...
  end

  context "when locations >= 10" do
    ...
  end
end

BAD: (notice double context block, doesn’t promote code sharing because you need to setup the same scenario multiple times. Also if someone modifies the code, they will have to modify in multiple places)

context "campaign has locations" do
  context "when locations < 10" do
    ...
  end
end

context "campaign has locations" do
  context "when locations =< 10" do
    ...
  end
end

2. If you have too many context blocks, that MIGHT mean you need to refactor your method to smaller methods.

3. Make sure that cases belong to their proper context block:

BAD:

context "campaign has locations" do
  context "when locations < 10" do
    ...
  end
  context "when locations >= 10" do
    ...
  end
  context "when locations = 0" do #<--- BAD (should be outside context)
    ...
  end
end

4. Write unit tests for single methods first.  You can skip for small “trivial” methods and include tests for small methods in the calling methods.  Worry about integration last.

5. I usually write unit tests will full stubs to verify input and output.  I might throw in a few tests to test the interaction and method chain.

6. Make sure you DON’T writes tests that test other components. Assume dependent components are written correctly and stub them out.  Good example of this is for external APIs.

7. Make sure your test breaks if you make it false.  I can’t count how many times it hasn’t for myself.

8.  For loops, I usually write a test case to make sure everything happens correctly for 1 iteration.  Then I have a test case to test for n (usually between 2-5) iterations.  TIP: extract the entire contents of the loop into its own sub method.

9. In your before block, if you are testing a certain condition on an object.  Explicitly set that, and don’t rely on Factory defaults:

BAD:

context "when campaign budget is NULL" do
  before do
    @campaign = Factory :campaign   #factory sets campaign budget = nil
  end
end

GOOD:

context "when campaign budget is NULL" do
  before do
    @campaign = Factory :campaign, :budget => nil
  end
end

The Ruby Way == Idiomatic Ruby

Almost 1 year ago, I joined a great start-up Thinknear (acquired by Telenav).  From a software engineer’s standpoint I did a complete 180 in the direction I was heading (outside of the fact that I was dabbling in Project Management at my old company Vistaprint).  

My previous company, Vistaprint, was a .NET shop for the most part.  I worked with C#, VB.NET, ASP.NET, IIS and MS SQL Server.  When I joined Thinknear, it was completely different.  We used Java, Ruby on Rails, Heroku, Apache Tomcat, Memcached, etc (the list could go on for awhile).

Anyways, I took learning Ruby to heart.  It had be awhile since I learned a new language and it was quite different than anything I had done before.  As I mentioned in earlier posts, I started from the ground up with tryruby.org.  I had about 3 weeks between knowing I got the job and starting the new gig (mainly because I had to transfer my visa).

I remember my boss (if you can call him that on a 3 person dev team), told me you can always spot a new Ruby person who came from an OO language.  It was hard for me to understand at the time, but now I get it.  I feel I am in a position to help the Ruby new comers.  So I want to introduce you to the “The Ruby Way” (a.k.a “Idiomatic Ruby”).

When I first started at Thinknear my code reviews were painstaking.  My teammates didn’t let up in learning Ruby and they made sure I would do everything properly.

The one thing that helped me the most was writing done every non-idiomatic mistake I made on code reviews and made sure I looked over the list before I submitted to GitHub.  I made very few mistakes more than 3 times, which believe me…was a HUGE step up from where I was coming from.

I am only 1 year into Ruby, but I am loving it!  It is a very natural and concise language.  It also helps you focus on the core algorithms and problems instead of a lot of other nuances in other languages.  I will be soon be ready to read my Metaprogramming in Ruby book, which will be fun and probably mind bending.  But here are my list of Ruby/Rails Idioms that I learned early on (low hanging fruit):

1. Ruby Style Guide – essential if you want to contribute to projects
2. Your best friend which you will be using a lot: http://ruby-doc.com/
3. Your best friend which you can try anything: irb
4. Do not use for i = 0; i < array.size, i++ etc…. use iterators!
   • Iterate over each element array.each { |element| puts element }
   • Iterate over each element, but transform each item: array.map { |element| element + 1 }
   • So many cool iterators: select, reject, inject
5. Do not use array.length > 0 or array == nil
   • array.present? is the bomb! It checks for nil AND to see if there are any items in the list (Rails only) – this also works for hashes
   • Checking for nil on any object? Use object.nil?
   • Checking for emptiness? array.empty?
   • Opposite of empty? = array.any?
6. Worried that something might be nil? try is your friend! Especially useful for hashes: Instead of hash.has_key?('missing-key') && hash['missing-key'] == value you can use hash.try[:[], 'missingkey') == value). Try will return “nil” if it can’t return anything.
7. Need the opposite of a condition? Do not write if !condition ... end , but instead use unless! unless condition ... end
   • Bonus points for writing conditionals on single line: do_something if condition

That is all I can think of, but I wanted this to be short and sweet and introduce some glaring Ruby newbie mistakes.  There is so much to offer in the language and I hope you have as much fun as I do!