DEV Community: Toby Osbourn

Removing fields with a Rails migration

Toby Osbourn — Tue, 09 Jun 2020 14:41:53 +0000

Over time your Rails models will contain fields that no longer serve a purpose. To make things easier to maintain, you should remove fields that aren't useful. Rails provides an easy way to do this.

In our imaginary system, we have the model Artist. When we first made the system, we thought that their eye colour would be a thing we needed. As the system matured, we realised that no one was using this attribute. After speaking to the stakeholders, we decide to remove eye_colour from our system.

In our terminal, we can type rails g migration RemoveEyeColourFromArtists eye_colour:string

rails g migration tells Rails to create a new migration for us. g is short for generate. If you prefer, you can write rails generate migration.

We start with the word Remove which tells Rails that this migration is about removing.

EyeColour is the field we will be dropping, this names the migration appropriately.

FromArtists lets Rails know the table we will be performing the migration on. Note the plural Artists, tables are always plural, to indicate they contain many of something.

Finally, we want to describe the field we are removing. It feels weird to define your attribute again, but migrations can have many actions inside them. eye_colour:string lets Rails know that the field we will be deleting is eye_colour and that it was a string.

We don't need to tell Rails it was a string. It will delete any field so long as the name matches. What we gain by giving Rails this extra bit of information is the ability to undo the migration, more on that later.

When we run this command we get this as part of the output;

create    db/migrate/20200323105013_remove_eye_colour_from_artists.rb

All your migrations will live in db/migrate/.

The numbers are the year, month, day, hour, minute, and second we ran the command. This level of specificity helps reduce clashes and helps you to see when you made a migration.

remove_eye_colour_from_artists is what we typed in earlier, made lower case and with _ (snake case is the name for this).

Inside your new migration file, you will see a change method.

  def change
    remove_column :artists, :eye_colour, :string
  end

The method change gets ran when we do a rails db:migrate and also when we do rails db:rollback. When we do a rollback the opposite of what we ask happens. This is why we set string as the data type. When we do rails db:rollback Rails will know to recreate the field with the appropriate type.

The main reasons why we shouldn't use "click here" as link text

Toby Osbourn — Tue, 09 Jun 2020 14:27:44 +0000

A typical pattern on the web is for links to hide behind text that says "click here", "read more", or similar. I'm going to share the reasons why this is bad and suggest some better patterns to use.

If you trust that I know what I'm talking about then the short version of this article is:

Using "click here" is bad for accessibility, it adds cognitive load and will hurt screen reader usage
Your SEO efforts will suffer with "click here" text. Internal links don't have the context search engines need to score your website
Copy punctuated with "read more" is harder to read than when link text is more natural
"Click" is mouse-centric and "read" is screen-centric. People consume content in more ways that by a screen connected to a mouse
If this list has convinced you, follow my "what to do instead" guidance

For more detail, please read on.

Accessibility

When it comes to web pages, most assistive technologies will grab the page and parse it. Instead of rendering the page, it will showcase the content in a way that is useful for that particular assistive technology.

Screen readers, for example, would be a terrible experience if they didn't allow for skimming. One way they allow skimming is to collate a list of all the links on the page and read them out.

Links on a page saying "click here" or "read more" have no context when reading in a list.

You've made it hard for someone who can't see the link in situ, decreasing how accessible your website is.

There are other accessibility reasons why "click here" is a bad idea.

Generally speaking a "click here" link will appear close to some explanatory text. The presumption is that your reader can keep the context in their head as they go through your website.

Assistive technologies are binary, someone is either using one or they aren't.

Cognitive ability is anything but binary and can be entirely situational. When I'm in a noisy room it's hard to think but when it's quiet it's easier.

The chances are when you are writing your copy you're in your office environment. This will not be the same environment someone will read your content in.

In short; "click here", or "read more" style links are bad for accessibility, don't use them.

SEO

I've worked in plenty of teams and companies where accessibility is a nice-to-have. I could rant for hours on the reasons why that makes zero business sense, but it is a common position for a company to hold.

One of the beautiful things about accessible writing is you almost always end up making your content do better in search engines.

There are two simple reasons for this:

If assistive technologies can understand your content, so can search engine bots. If a search engine can understand your content better, it will rank it better
Content that is available to more people will allow more people to complete their task. Search engines want to send people to places where they can achieve their task

I could turn this post into a rationale for using marketing budget to make your website more accessible. I will refrain.

Search engines have many ranking factors. Ranking factors are criteria for what makes one page rank above another page. One of the most significant ranking factors is how many links point to a page.

If we have two pages answering the question "what is a gemfile?", the one with more links will likely rank higher. There is good reason to assume the one with all the links is more authoritative, why else would people link to it?

But links are more than the value of the href attribute, they are also the link text, which is the stuff between the opening <a> and closing </a>.

Search engines use the link text to understand why someone would link to a page. This extra context is essential.

If we have a website that everyone links to with the word "cat", we would not expect it to rank well for the word "dog". Everything the search engine knows about this site is that "when people link to this site, they are talking about cats".

Search engines don't only look at links from other sites to yours. They look at how your pages link together. These internal links send a signal of "this is what this website thinks is the best page about this link text".

To sum up. Using "click here" links won't pass relevant context to search engines, which means they can't score the page you linked to appropriately.

Readability

Accessibility and SEO are two excellent reasons why you would want to avoid "click here" links. I can see a counter-argument if the content you're writing is personal and you don't care if others can read or find it.

I counter this by suggesting that you want your writing to come across as well as it can, even if the only audience is you.

"Click here" or "read more" has become a weird kind of punctuation on the web. Like any punctuation, when overused, it becomes annoying and gets in the way of the content.

You presumably want your ideas to flow well on the page. You can do this by not punctuating your writing with meaningless words.

The Text is Semantically Incorrect

My final point is a semantic one. Clicking is something you do with a mouse or trackpad. The chances are most of your writing isn't read by someone using a mouse. The notion of clicking is the equal of using a picture of a floppy disk to mean save. It is an archaism that rarely makes sense to use in the current context.

Likewise, to suggest someone should "read more" sounds silly if they are listening to your content either via a screenreader, or a speech-only device like Alexa.

There is an argument that web users know that a click means a press or that reading means consuming. In the same way, someone knows the save icon without having had the joy of using floppy disks. Why take the risk that someone doesn't? What happens when someone translates your content and the word "click" gets turned into something far more literal.

You presumably want to present yourself well in your writing, so you should make an effort to use the right words.

"Click here" or "read more" don't make sense now and will make even less sense in the future.

What To Do Instead

By now I bet you're on board with the idea that we should do away with "click here" text. What next?

Each case is different. I have a few general tips for improving your link text.

Replace mechanical words with actions

We've already talked about how "click" is a weird choice of word. As well as not being accurate in all cases, it is focused on how you interact with the link, and not what the link will do.

For example "click to view screencast" is telling you to use a mouse to interact with this link. If we used "view screencast" then this link text is telling us the action.

Assume no extra context

Assume someone has removed all other text from the page and only your link text remained.

You should replace "You can click here to buy a Nintendo Switch" with "you can buy a Nintendo Switch".

In the first example, you would see click here, and you would have to guess at the point of the link. In the second you would have buy a Nintendo Switch which is clear.

Name many links

A common pattern people follow when they want to share many links is to make an in-line list:

"You can read more here, here, and here".

Within the context of the sentence, the reader might know the type of content they should expect. They could not infer what is different between the three links. It makes it impossible for them to know which one they should prioritise.

You can still use in-line lists, but you need to add some context. For example, "You can read The Guardian's writeup, @tosbourn's thoughts, and a twitter thread talking about this.". The same three links now convey more information about what might be different between them.

Move action links to the end of a sentence

If you were citing an article, you might link to it, but you wouldn't expect your reader to follow the link, read everything, and come back.

Sometimes you add a link because you want someone to do something. When this is the case, you should consider putting the link at the end of the sentence.

Giving it after the context means they can decide at the point of seeing the link. "@tosbourn has a twitter account, you should follow them" means the reader has to scan back to find the link. "You should follow @tosbourn on Twitter" gives the reader less work.

Improve your website by improving your links

When I first started writing this article, I thought there was only enough content for a few paragraphs, so thank you for making it this far!

Putting thought into how you name your links will improve the accessibility of your site, increase your rankings in search engines, and will engage your readers more. This will result in more people reading and getting value from your content.

If you have any other reasons that "click here" is wrong, or if you have any fantastic tips to share on writing great link copy, I'm all ears! Please share in the comments below.

Good things happen to those that blog

Toby Osbourn — Fri, 10 May 2019 09:22:59 +0000

In this post, I want to explain why I think most technical folk would benefit from a blog that they keep fairly up to date. I originally posted this few years ago here and have made some small edits for this version.

For some context for people who don't know me, I am not a professional blogger or anything like that, I kind of enjoy writing but at my core, I am a developer, I like tinkering with stuff and swapping things around to figure out why stuff works. This means that my experience has largely been writing about dev stuff, primarily for other developers and future me when I forget about something.

So, what good things have happened to me that I think can happen to you as a result of blogging?

Job Opportunities

A blog as kind of like a self-updating CV, it talks about projects you have worked on and challenges you have overcome, it even timestamps things for you to give people an idea of how long you have been into a particular field of interest.

At a job interview wouldn't it be excellent if you were asked a question and one of the references you gave in your answer was a blog post you had already written? It shows a potential employer that you are keen enough about the industry and are already knee deep in the challenges they are currently facing.

In terms of getting noticed, I have found a blog to really help, folk looking for folk to work with or hire are generally pretty lazy (like all people!) and they are going to pick the path of least resistance, if someone comes to them and tasks them with finding someone in technology x who lives in location y, you can be damn sure that is going straight into a google search and if they can find a local dev with knowledge of that stack, you know you will be getting contacted.

I'm now contracting, and the majority of potential clients haven't been looking specifically to hire us, but know of us because of the blog.

Writing Opportunities

This is one of my favourite things that has come out of me blogging and that is more writing! I have two quick examples for this;

The first was I was asked to write for the IEEE journal because of an article I put together about StackOverflow had I not of written the article, it would never have been retweeted by the founders and the person who contacted me to write an article would never have known I existed.

The second is that it was a quick post I had written about Bootstrap's Typeahead functionality which made Packt Publishing contact me about writing a book on Twitter's Typeahead functionality. The only factor in them first contacting me was that blog post, there was nothing else on the internet that would suggest I even knew what typeahead functionality even was. (the book is now very out of date!)

Money and Free Stuff

If you blog about problems that you are facing that are non-trivial (there isn't already a standard solution that is easily searchable) then chances are people will find your blog when they come looking for the same problem, that being the case having a couple of non-obtrusive adverts is a nice way to make a modest amount of passive income, it certainly pays for domain name renewal and stuff like that.

Some of the free stuff I have been offered whilst blogging includes;

Free copies of books to review
Free passes to conferences so long as I do a write up
Free and early access to software to give my thoughts on it

I have a very modest amount of traffic and it isn't well known by any stretch of the imagination, but I have to say I turn down more stuff than I ever imagined I would be offered.

Community Karma

Helping people is nice and feels good, if something took you a long time and you write about the steps you took in order to help someone else out you get a nice feeling when people send you comments saying things like "You saved me a days work", or even just a "Thanks!"

If you work on or with Open Source software then you already have so many people to thank that make your life so much easier every day and I think leaving little clues to help people figure out there own issues is one way you can give back to the community.

Solidified Thoughts

I find that blogging really helps solidify my thoughts on something, it is one thing to read something and think you understand it, but when you try and write about it yourself you will find you need to pause and consider what you are trying to say and what is going to be the best way to say it. Also, if you have strayed in your thinking there will surely be someone in the comments that will point you back in the right direction.

Typing and Writing Skills

As I am sure the slew of grammatical errors in this post will likely attest to, I am in no way an expert at writing, but even I have to admit as I look back at earlier posts that this is something I have improved upon as I have written more. Likewise with typing - sure I am a developer by trade so I need to be in front of a keyboard a lot, but typing in programming languages is vastly different from typing in English.

Procrastination

Sometimes you just don't want to do any real work, but you do want to do something productive, I have found that occasionally banging out a quick blog post gives you that quick productivity fix without actually accomplishing anything on your to-do list (do you think this blog post has been on my to-do list? It has not!).

This isn't an ideal way to work 100% of the time, but once in a while I don't think hurts.

Do you like blogging?

Share your blog in the comments below!

I am the head of platform and standards at one of the UK's largest children's charities, Ask Me Anything!

Toby Osbourn — Mon, 06 May 2019 16:51:03 +0000

I lead a dev team there and head up a team seeking to unify our technical assets under a common set of best practice standards.

What I would look for in a junior developer

Toby Osbourn — Mon, 06 May 2019 16:47:18 +0000

In various jobs I have held I have had to sit in and conduct interviews for a junior developer role. Junior developers by their nature have very little industry experience and very few projects which they can discuss at length.

It is about Passion

In those interviews I wasn’t looking for someone that had all the answers, I was looking for someone that I thought the team would enjoy working with and teaching.

What I look for in a junior developer is passion. There has to be a fire in their belly and a genuine desire to learn about things that right now probably seem so unknowable.

It is about Communication

Junior developers generally won’t have had too much interview experience, so I would not be looking for a candidate who maintains eye contact at all times and answers everything without first taking time to think.

What I do look for is someone who can communicate – even with my limited experience as an interviewer I feel it is apparent when someone isn’t communicating well because of nerves, or isn’t communicating well because it isn’t in their nature to communicate.

Communication is a massive part of our job, we are telling stories through code and through commit messages and through support emails. I am not good enough to teach someone how to be a good communicator so I would like to hire people who are by their nature communicators.

It is about honesty

I look for honesty.

I was once in an interview where the interviewee said they had looked at our website’s source code (we asked). Before putting out the position we had introduced a comment at the very top of the site saying something along the lines of;

<!-- Hello there, if you are interviewing with us and mention that you seen this comment, you will score major points! -->

We asked what they noticed and they had no comment (and clearly looked very nervous). There was no way we could hire them.

It doesn’t have to be this extreme of course, what really turns me off about a candidate is when you ask them “Do you know much about technology y” and instead of answering “No, but I have heard it is like technology x which I know about”, or “No, sorry, is there another name I might have heard it being called”, they answer with “Ummm yeah, I think so, it is like this thing that lets you do this thing that…”

It is honestly better to be honest!

It is about the mindset

When asked a hypothetical question like “The client is reporting that the email form we built them isn’t working, how would you handle this” we generally aren’t looking for technical answers.

I want to know about how you think about things – being able to think on your feet is incredibly important and I want to know what type of thought process you use.

I also want to know about how you might communicate the issue with your hypothetical teammates and this hypothetical client.

It is about the questions you ask

In my experience the questions you get asked at the end of an interview are very telling and say a lot about the interviewee.

First up, have questions. There is nothing worse than asking nothing.

Second up, know that there are no dumb questions – you won’t get marked down for asking something you think everyone else knows.

Good questions I have heard before include topics such as;

If there is a training budget
What is a normal day like for a dev in the company
Who would I be reporting to and what is their role
Why has a position opened up
Are there any main projects that I would be spending most of my time on?

It is about… Time I wrapped up

If you're a junior developer who has landed an interview, you may be interested in my post interview tips for junior developers.

This article originally appeared on tosbourn.com