DEV Community: James

Assertions of Truth in Ruby Tests

James — Tue, 12 Jan 2021 00:00:00 +0000

I used to write my assertions like this:

assert user.active?
refute user.inactive?

Then I joined a team where I was encouraged to write this:

assert_equal true, user.active?
assert_equal false, user.inactive?

What? That doesn’t look very nice. That’s doesn’t feel very Ruby. It’s less elegant!

Here’s the thing, though: your unit tests aren’t about being elegant. They’re about guaranteeing correctness. You open the door to some insidious bugs when you test truthiness instead of truth.

You might perform an assignment rather than comparing equality.

def active?
  # Should be status == :active
  status = :active
end

You might check the presence of an array, rather than its length.

def has_users?
  # Should be user_list.any?
  user_list
end

def user_list
  []
end

Over time, I’ve gotten used to it. This style still chafes, but not as badly as bugs caused by returning the wrong value from a predicate method.

The Surprising Case of `gets` in Ruby

James — Thu, 07 Jan 2021 00:00:00 +0000

gets is seen is basically every introductory Ruby tutorial, but they rarely tell the whole story.

You’ll be told to write something like this:

#!/usr/bin/env ruby

puts "What is your name?"
your_name = gets.chomp
puts "Hi, #{your_name}!"

Confusingly, if this is in a script that takes additional command line arguments, you may not see “Hi, Janet!”

If you execute ./gets.rb 123 you will pretty quickly be greeted by the following error:

./gets.rb:4:in `gets': No such file or directory @ rb_sysopen - 123 (Errno::ENOENT)

The tutorial didn’t warn you about this. The tutorial is giving you a reduced view of things that may, if you’re like me, leave you scratching your head several years later.

gets doesn’t just read user input from $stdin. gets refers to Kernel#gets, and it behaves like so:

Returns (and assigns to $_) the next line from the list of files in ARGV (or $*), or from standard input if no files are present on the command line.

If you really, truly want to prompt the user for their input, you can call gets on $stdin directly. And who wouldn’t, with a user like you?

your_name = $stdin.gets.chomp

Warning on long branch names with git hooks

James — Wed, 01 Apr 2020 00:00:00 +0000

My company does some cool stuff with our CI pipeline. When someone submits a merge request, we know that this branch may require some manual testing before it gets merged. We enable this with a button on the merge request that lets people spin up a docker container running the proposed change, whacking it on our kubernetes cluster, and pointing a URL to it.

If your branch is called new-feature, you’ll get a shiny copy of the app running just for you at https://new-feature.review.example.com.

If your branch is called super-amazing-cool-new-feature-that-i-love-and-you-will-too, you would expect to be able to test your feature at https://super-amazing-cool-new-feature-that-i-love-and-you-will-too.review.example.com

So, we hit the button. Things begin to churn. We ping off a request to AWS Certificate Manager and… it tell us off.

Oh.

Apparently, the first domain name on a certificate can’t exceed 64 octets in length (including periods). Ours is… somewhat longer than that.

I wish someone had told me that AWS was going to reject my certificate request before I created the branch and wrote the code and created the merge request and waited for the automated test suite to run and waited for the docker container to be built.

Enter git hooks.

git hooks let us execute a script before or after certain git actions. You can do lots of awesome stuff with them, like blocking commits that don’t match certain criteria, triggering deploys in different environments, and more.

In this case, we want to warn ourselves whenever we create a branch name that is going to result in a domain name that won’t pass AWS Certificate Manager’s checks.

We know that the base of our URL is .review.example.com, which is 19 characters long. This gives us (assuming that all of our branch names are plain ol’ UTF-8) 45 characters to play with.

Let’s drop the following into .git/hooks/post-checkout and make it executable:

#!/bin/sh
RED='\033[0;31m'
NC='\033[0m'
branchname=$(git status | cut -d ' ' -f 3 | head -1)
if [${#branchname} -gt 45]
then
  printf "${RED}💩 This branch name is over 45 characters.\n"
  printf "If you proceed, you will be unable to generate a TLS certificate for your review app.${NC}\n"
fi

Now when we try to create a branch with a luxuriously long name, we get:

➜ hooks git:(master) git checkout -b super-amazing-cool-new-feature-that-i-love-and-you-will-too
Switched to a new branch 'super-amazing-cool-new-feature-that-i-love-and-you-will-too'
💩 This branch name is over 45 characters.
If you proceed, you will be unable to generate a TLS certificate for your review app.
➜ hooks git:(super-amazing-cool-new-feature-that-i-love-and-you-will-too)

Sadly there doesn’t seem to be any pre-checkout hook, so you can’t block a branch from being created (or confirm that it’s really what you want), you can only spit out a warning after the fact. But hey, it’s red!

Finding A Method Declaration With Source Location

James — Sat, 30 Nov 2019 00:00:00 +0000

I recently had one of those moments where some code failed, but not in the way I expected it to. To create a contrived example, the scenario was basically this:

class LocationsController < ApplicationController
  def update
    my_location = Location.find(params[:id])
    do_something_with(location)
  end
end

This code won’t do what I want it to because I have defined the variable my_location but then passed location to another method. What I initially expected upon finding the bug is that I would have seen a NameError complaining that the local variable location didn’t exist. But I didn’t. As far as I could tell, location existed and it was nil.

It wasn’t referenced anywhere else in LocationsController, nor in ApplicationController. So what is it? Fortunately, Ruby provides a great way to find out.

class LocationsController < ApplicationController
  def update
    puts method(:location).source_location
    # "/usr/local/bundle/gems/actionpack-5.0.7.2/lib/action_controller/metal.rb"
    # 149
  end
end

That’s that mystery solved. There is a method called location implemented a layer or two up the inheritance hierarchy. We knew it had to come from somewhere, but source_location lets us determine the exact location.

Modules, Macros, Metaprogramming and Magic

James — Wed, 05 Jun 2019 00:00:00 +0000

If you’ve used the Rails framework, you will probably recognise this:

class Comment < ApplicationRecord
  belongs_to :article
end

This snippet of code implies three things:

1) We have a table of comments.
2) We have a table of articles.
3) Each comment is related to an article by some ID.

Rails users will take for granted that if they have an instance of the Comment class, they will be able to execute some_comment.article to obtain the article that the comment is related to.

This post will give you an extremely simplified look at how something like Rails’ ActiveRecord relations can be achieved. First, some groundwork.

Modules

Modules in Ruby can be used to extend the behaviour of a class, and there are three ways in which they can do this: include, prepend, and extend. The difference between the three? Where they fall in the method lookup chain.

class MyClass
  prepend PrependingModule
  include IncludingModule
  extend ExtendingModule
end

In the above example:

Methods from PrependingModule will be created as instance methods and override instance methods from MyClass.
Methods from IncludingModule will be created as instance methods but not override methods from MyClass.
Methods from ExtendingModule will be added as class methods on MyClass.

We can do fun things with extend.

Executing Code During Interpretation Time

module Ownable
  def belongs_to(owner)
    puts "I belong to #{owner}!"
  end
end

class Item
  extend Ownable
  belongs_to :overlord
end

In the above code, we’re just defining a module and a class. No instance of the class is ever created. However, when we execute just this code in an IRB session, you will see “I belong to overlord!” as the output. Why? Because the code we write while defining a class is executed as that class definition is being interpreted.

What if we re-write our module to define a method using Ruby’s define_method?

module Ownable
  def belongs_to(owner)
    define_method(owner.to_sym) do
      puts self.object_id
    end
  end
end

Whatever we passed as the argument to belongs_to will become a method on instances of our Item class.

our_item = Item.first
our_item.overlord
# => 70368441222580

Excellent. You may have heard this term before, but this is “metaprogramming”. Writing code that writes code. You just metaprogrammed.

Tying It Together

You might also notice that we’re getting closer to the behaviour that we would expect from Rails.

So let’s say we have our Item class, and we’re making a videogame, so we’re going to say that our item belongs to a player.

class Item
  extend Ownable
  belongs_to :player
end

Our Rails-like system could make some assumptions about this.

1) There is a table in the database called players.
2) There is a column in our items table called player_id.
3) The player model is represented by the class Player.

Let’s return to our module and tweak it based on these assumptions.

module Ownable
  def belongs_to(owner)
    define_method(owner.to_sym) do
      # We need to get `Player` out of `:player`
      klass = owner.to_s.capitalize.constantize
      # We need to turn `:player` into `:player_id`
      foreign_key = "#{owner}_id".to_sym
      # We need to execute the actual query
      klass.find_by(id: self.send(foreign_key))
      # SELECT * FROM players WHERE id = :player_id LIMIT 1
    end
  end
end

class Item
  extend Ownable
  belongs_to :player
end

my_item = Item.first
my_item.player
# SELECT * FROM players WHERE id = 1 LIMIT 1
# => #<Player id: 12>

Neat.

Book Review: It Doesn't Have To Be Crazy At Work

James — Sat, 09 Mar 2019 23:58:15 +0000

David Heinemeier Hansson and Jason Fried of Basecamp and Signal v. Noise lay out how they achieve calm at Basecamp and how other companies can make the choice to do the same.

They point to the long hours, stolen weekends and barbed perks that run rampant in tech and say "it doesn't have to be this way!"

Growth at all costs. Companies that demand the world of your time, and then steal it away with meetings and interruptions. Companies that coerce or bribe you to spend most of your waking hours with your nose to the grindstone (because after all, this company is like a family, right?)

It Doesn't Have To Be Crazy At Work discusses these problems and proposes a better way of doing things. DHH and Jason Fried discuss the solutions they've found to work at Basecamp, tackling issues from big picture ambitions to lower level project management, and from hiring to perks and payroll. They discuss the solutions that they have found work for them at Basecamp, but make no decrees as to how your company ought to be run. That's for you to iterate on with your own team.

Most of the stuff I have read about taming work feels very prescriptive. Do this. Do that. Try these processes. Add enough kanban boards and everything will click into place and you will finally be able to breathe. It Doesn't Have To Be Crazy At Work takes the opposite approach and encourages you to look at the things that you don't need to do. Make time for the important things by stripping away the inessential.

It's a pretty short read, and worth a look for anyone who feels like work is a little too hectic.

Lazy Loading Images For Your Digital Library

James — Sat, 09 Mar 2019 13:21:50 +0000

A quick morning (or afternoon, at this point) project to play with the magic of lazy loading. I wrote previously on my personal site about how I spent the beginning of the year getting rid of stuff. Like many people, I rather arrogantly identify as a reader. Books sort of amass as trophies. The books I've read occupy a relatively small space, but the books I plan to read threaten to tear the shelves straight off the wall.

The Japanese word for this is "tsundoku."

So, many books had to go. However, people tend to keep books around for two reasons:

1) I might read it again.
2) I like having it there.

The first point is debatable. The second, harder to argue with. I wanted to reclaim some space while ensuring that I wouldn't forget the books that I've read and enjoyed (or not) over the years.

And, as said, I wanted to play with lazy image loading.

https://jsrn.net/library/

I'm James, and I don't want to talk about myself.

James — Thu, 07 Mar 2019 23:26:23 +0000

I tried writing about myself and the things I want to see, but I couldn't really find anything I was comfortable with. I don't think I'm really the person to teach others how to be a good ally. I don't know what I'm doing.

My only advice is to amplify people different than yourself. If there's something you want to say and someone else has already said it, don't speak over them or repeat it just so it can be a tiny picture of your face next to the words. Use your platform to amplify them.

Jessica Rose [Website ⌨ Twitter]
One of the most inspiring people I follow. Jessica always seems to have time to help people and organise within the community.

Sandi Metz [Website ⌨ Twitter]
Almost everything I managed to absorb about OOP came from Sandi Metz. Her books belong on every shelf.

Caroline Ada Ehmke [Website ⌨ Twitter]
Created the contributor covenant. Fights seemingly fearless and tirelessly for decency in tech.

Ali Spittel [Website ⌨ Twitter]
A prolific writer and helper. Seeing her get a role at DEV.to after being so involved in the community was awesome.

Emma Wedekind [Website ⌨ Twitter]
Another super prolific DEV.to writer. It's difficult to visit this site without benefiting from something she wrote.

Amy (Sailor Mercury) [Website ⌨ Twitter]
A programmer who creates zines explaining tech concepts, clothes, and more.

Liz Fong Jones [Website ⌨ Twitter]
Another tireless campaigner for decency in tech. Has been most recently helping me by live-tweeting conference talks in awesome detail.

Happy International Women's Day.

What’s Tripping Up Uglifier?

James — Wed, 06 Mar 2019 00:00:00 +0000

In production mode, Rails 4 uses the uglifier gem to compress your JavaScript code into something nice and small to send over the wire. However, when you’ve got a syntax error, it can fail rather… ungracefully.

You get a big stack trace that tells you that you’ve got a syntax error. It even helpfully tells you what the error was! Unexpected punctuation. There’s a comma, somewhere. Where? Who knows. It doesn’t tell you.

If you have a large project, or have multiple people making large changes, it can be a little time consuming checking the diffs of recent commits to figure out where the error was introduced. Here is how you can use the rails console to at least find the offending file:

Since the uglifier doesn’t run in development, let’s drop into the rails console in production mode:

RAILS_ENV=production rails c

Now we can use the following snippet of code to find our errors:

# Take each javascript file...
Dir["app/assets/javascripts/**/*.js"].each do |file_name|
  begin
    # ... run it through the uglifier on its own...
    print "."
    Uglifier.compile(File.read(file_name))
  rescue StandardError => e
    # ... and tell us when there's a problem!
    puts "\nError compiling #{file_name}: #{e}\n"
  end
end

This saved me a little time recently, so I hope it will be handy to someone else.

Hand-holding Simulator

James — Mon, 04 Mar 2019 13:50:51 +0000

For anyone who needs it.

https://handholding-simulator.glitch.me/

It’s Time For Link Pages

James — Wed, 27 Feb 2019 00:00:00 +0000

There are a few complaints that are often made about the internet by those of us who spend too much time on it.

1) It Sucks Now

The first is that the internet isn’t fun any more. There’s no exploration. Everything is centralised in a few places. Everybody is trying to build a brand. Nobody does anything just for the fun of it. You go on Twitter, get mad, and log off. There’s nowhere else to go.

2) The Whole Thing Is Owned By Like Three People

The second complaint, and it’s very much related, is that the majority of the content that we produce is aggregated in a few places to the benefit of companies. Twitter. Facebook. Yahoo Answers.

I was reading an AskReddit thread a while ago. “What sites do you use when you aren’t on reddit?” I didn’t know. Everything is on one place, and it’s filtered through algorithms, trends, bots and social manipulation. We generate content, but we don’t give it directly to each other. We give it to a third party who flavours it and squeezes it into our waiting mouths like a sort of digital nutrient paste.

The solution ~~RSS, RSS is the solution~~ has been staring us in the face. ~~It’s RSS.~~

Link pages. Remember link pages?

“A link page is a type of web page found on some websites. The page contains a list of links the web page owner, a person or organization, finds notable to mention. Often this concerns an enumeration of partner organizations, clients, friends or related projects.” - Wikipedia, the only good counter-example to my rant.

People still have personal websites. A lot of us techies still have personal websites. But it’s an exercise in brand building. Look how clever I am. Hire me. Be my friend.

We need to bring link pages back. In a big way.

Advantages:

Make friends. Become popular.
Cool graphics.
Won’t disappear when Jack Dorsey dismantles the Twitter servers to salvage parts for Mark Zuckerberg’s future body.

Disadvantages:

Literally none.

I will put my money (just kidding, I use GitHub pages so I don’t pay squat) where my mouth is here and say that if you run a tech site, don’t represent a company, and send me a small (ideally 88 x 31, as per the web badge guidelines) image, I will include it on a special page on my website that gets no traffic.

My dream is that one day our sites will once again be connected by an intricate network of links. A web. A World Wide Web.

Answers To Anticipated Comments

James, the web badges you mention are generally used for web standards, not linking to other sites!

Yeah, I know. Aren’t they cool though?

Are you trying to be funny?

Depends whether it worked or not.

This is a great idea. Can I link to your site?

Sure. Here:

Book Review: Refactoring UI

James — Mon, 25 Feb 2019 00:00:00 +0000

I recently bought myself a copy of Refactoring UI by Adam Wathan and Steve Schoger.

I opted for the much cheaper ($79 USD for a book and three videos) package, foregoing the large amount of extras I could have gotten for another $70 USD: icons, colour palettes, inspiration gallery and a rather comprehensive sounding font showcase.

While I can’t say for sure, not having bought them, my guess is that they would easily provide more than the extra $70 of value to any designer or aspiring designer.

So, on to the book and videos, from which I learned many things:

The Book

1) Design From Above

How to focus on what the product needs to do before worrying about the layout.
How to prototype in low fidelity.
How to prioritise designing the core features without getting bogged down in hypothetical extensions.
How to figure out who you’re designing for.
How to design systems to constrain your choices.

2) Design With Hierarchy

How to use font sizes and colours to convey hierarchy.
How to separate visual hierarchy from document hierarchy.
How to balance semantic importance with position in the hierarchy.

3) Layout

How to use white space effectively (and how not to).
How to build good space relationships.

4) Text

How to establish good font size relationships.
How to choose and pair good fonts for different parts of the interface.
How to design text for prose.

5) Colour

How to choose a good colour palette.
How to define your colours in code.
How to pair colours and make effective use of contrast.

6) Depth

How to use shadows to convey a sense of “realness” in your interface.
How to position and overlap elements effectively.

7) Images

How to choose good images.
How to pair text and images when contrast becomes a problem.

8) Finishing Touches

How to use a lot of simple tips and tricks to make your product look more polished. These aren’t huge wins for accessibility or performance, but things you can do to elevate your design with minimal investment.

The Videos

Both packages come with three screen-cast style videos in which they improve the design of a realistic interface, explaining their process as they work. Being able to watch the interface transform as they talk you through it, and then be presented with the before and after makes a powerful impression as to the value of the concepts they discuss in the book.

Conclusion

This might seem like I’m simply regurgitating the table of contents and I suppose I am, but my aim is to convey the value I gained from this book in my own words as a developer who wants to be good at design (and who isn’t making any money from singing the book’s praises).

The examples are compellingly presented with before and after states, as well as having the important information such as colour and font choices annotated. Weighing in at a relatively lean 218 pages, Refactoring UI doesn’t delve too deeply into colour theory and the psychology of design, but provides countless rules of thumb and visual examples, showing even someone with the most rudimentary design skills (me) how to elevate their work to the next level.

To get a further sense of the value the book provides, I suggest you check out this series of hot tips from author Steve Schoger.