RESTful Routes

What are REST, Routes, CRUD?

Representation State Transfer or REST is a pattern/convention for defining our routes. Routes are the code that listens and receives requests then figures out what to send back. CRUD stands for Create, Read, Update, and Delete. These are the 4 basic functions we have when building an API.

So why do we want any of this? Mostly it’s just about keeping things simple and repeatable when building apps. By following a convention we don’t have to reinvent the wheel every time we make an app and other developers will quickly figure out what’s going on.

The Magnificent 7

REST is made up of 7 standard routes:

NameURLHTTP VerbDescription
Index/teamsGETDisplays a list of all teams
New/teams/newGETDisplays a new team form
Create/teamsPOSTAdds new team to the database then redirects
Show/teams/:idGETShows a particular team
Edit/teams/edit/:idGETShows an edit form for a particular team
Update/teams/:idPUTUpdates a particular team in the database then redirects
Destroy/teams/:idDELETERemoves a particular team from the database then redirects

Installing MongoDB on macOS

The course I’m doing uses Cloud 9 (C9) as cloud-based IDE. I’ve basically ignored that side of things and done everything locally on my Mac as that feels more real world to me. Turns out this was a good decision as C9 has recently announced it’s shutting down. Anyway, at times this has made things more difficult though. A good example is when I need to follow instructions to get a particular part of the development environment setup. Because all the instructions are specific to C9 it means I more or less have to figure out how to do it myself on macOS.

This morning I had an example of this exact thing when I needed to install MongoDB. I’m finally at the point that I’m starting to work with a database (hallelujah!) and I needed to get things going on my Mac. Thankfully there’s Google and I quickly found this treehouse article that gave me some clear steps to follow.

Of course it’s never quite that easy. Different machines are set up in different ways, so a guide like this doesn’t always allow for edge cases. So here’s what worked for me:

  • Open terminal and use the command brew update to update Homebrew itself to the latest version
  • Now install MongoDB using brew install mongodb. This will install the latest version
  • Next we need to create a folder to house our MongoDB data files. Use the command sudo mkdir -p /data/db. The instructions I first followed didn’t include sudo and so didn’t work for me. Your milage may vary
  • We should now have a place for our data but we need to set the folder permissions using sudo chown -R `id -un` /data/db

That’s basically it, you should now have a functional install of MongoDB. Open up two terminal windows in the first start the server with the mongod command. In the second terminal run mongo to launch the mongo shell for accessing data.

A battle for the ages

Spaces vs tabs is a hilarious holy war that doesn’t really matter but I do find amusing. Modern text editors normalise differences on a project anyway, but I do love these ideological battles. The video below covers it better than I ever could. Enjoy… btw I’m a spaces man 😉

Express snippets

Since I’m playing with Express at the moment I’ve updated my collection of snippets to include a few things I seem to be doing regularly:

Express setup

I use the shortcut “myExpressSetup” to kick off all my new Express projects. It has basically all the parts I need to get the project underway, and means I dont have to remeber each bit. This is more or less the Express equivalent of the HTML boilerplate I’ve mentioned in the past.

  'Express Setup':
    'prefix': 'myExpressSetup'
    'body': """
    "use strict"

    var express = require( "express" );
    var app = express();
    var bodyParser = require( "body-parser" );

    app.use( bodyParser.urlencoded( {
      extended: true;
    } ) );

    app.set( "view engine", "ejs" );

    app.get( "/", function( request, response ) {
      response.render( "home" );
    } )

    $1

    app.get( "*", function( request, response ) {
      response.send( "404 page not found );
    } )

    // Tells express to listen for requests (Start server)

    app.listen( 3000, function() {
      console.log( "The server started on http://localhost:3000/" );
    } );
    """

Get route

Shocking no one, if there’s one thing I seem to be doing a lot it’s displaying content on an HTML page. Using the shortcut “myGetRoute” this one basically says if the URL fits this pattern take it and display it using the “project” template.

'Express Get':
    'prefix': 'myGetRoute'
    'body': """
    app.get( "/project/:thing", function( request, response ) {
      let thing = request.params.thing
      response.render( "project", {
        thingVar: thing
      } );
    } );
    """

So, for example, I could have a URL like geekpulp.co.nz/project/banana and have it populate the project templates H1 with “banana”. If the URL was then geekpulp.co.nz/project/apple it would populate the project template H1 with Apple. Obviously later in the course, I’ll start populating things from a database and this will all make a lot more sense.

Post route

This one’s all about collecting data from a form and adding it back to the page. Again this sort of thing will make a lot more sense when I’m actually posting the data to a database. At the moment if you refresh the page everything will just return to defaut values because nothing is being saved to the backend.

'Express Push':
    'prefix': 'myPushRoute'
    'body': """
    app.post( "/addteam", function( request, response ) {
      let newTeam = request.body.newTeam;
      teams.push( newTeam );
      response.redirect( "/teams" );
    } );
    """

These new snippets are certain to change in the next week or so as I expand to doing things that are actually useful. At this stage, a lot of this stuff is just code that facilities learning. Having said that, I find making snippets for repetitive tasks a good habit to form. Ultimately the whole point is being as efficient as possible.

The three stages of developer growth

Today I happened across a great Quora post by Andreas Blixt. In the post, Andreas outlines the three stages of developer growth:

The novice hacker
“This code sure is ugly and I don’t quite understand why it works, but here it is!”
A developer in this phase finds creative solutions to problems, they just happen to be copy/pasted from all over the internet.
The problem is that the code breaks whenever it needs to be changed or it encounters a new situation

The philosophizing abstracter
“This code works for now, but if I move this part into a factory, and create an interface for these methods, it’ll also support all these future cases I can think of!”
They’ve read all the articles on how to structure code. There’s a lot of patterns out there for object-oriented (or functional!) code. Their code has all sorts of useful interfaces, abstraction layers, factories, extension methods, data structures.
Things break down when the project needs to move in an unexpected direction and it turns out that implementing the change requires changing a lot of the codebase because there were a bit too many abstractions that ended up creating hidden dependencies across the code.

The wise hacker
“Move fast. Break things. Revise and fix. Get shit done.”
Finally, developers balance the concepts of hacking and abstracting. They write code that simply solves the problem at hand, then they take a step back and look for repetition that can be simplified. They know from experience that things always change unexpectedly and that you can’t always foresee what will or will not be useful in the future.

Blixt, A. (2015, October 22). What are the growth stages of a programmer? Retrieved March 20, 2019, from https://www.quora.com/What-are-the-growth-stages-of-a-programmer/answer/Andreas-Blixt

As someone basically just starting out, I find this perspective from a senior developer very reassuring. I can absolutely see this path before me. Already I find myself writing code to get things working, then revisiting the code to see how I can improve it.

I’m yet to have the knowledge to do a great job on the improvements, but I feel that is my workflow. Having these stages outlined actually impacts my pathway through them. As I develop more skills I’ll be mindful of when and where I should deploy them.

How much time should I spend a day learning to code?

This is the question I asked myself when I first started learning (well relearning really) to code a while back. Obviously I Googled this and found some really interesting answers, but generally speaking, the common wisdom is about 4 hours a day.

I call bullshit on this. In my experience (and your mileage may vary) you should code every day, but it really doesn’t matter how much. Sure, you’ll get to the destination faster if you’re able to put 4 hours a day, but that number is completely unrealistic for a good chunk of the population.

Personally, I have a full-time job, 2 young kids, and a wife. 4 hours a day is an absurd amount of free time for me each day to work on much of anything. So when I study something I work to a very simple philosophy. Do some study every day. That’s it. Change is all about momentum. You don’t have to stop sleeping to make a change, you just have to show up every day and do something.

Routine is key

My personal routine is to get out of bed early, normally around 5-5:30am. Then I do as much of my course work before the kids get up as possible. Normally I’d get around an hour or so done. Some days I might sleep in and only get 30 mins, but I still progress. To solidify my learning, in the evening I go over what I did in the morning and write up notes. Sometimes those notes turn into a blog post. In that way, I’m sort of doing double duty. Sharing what I’ve learnt and documented it for my own retention all in one.

The thing about learning anything over and above your already busy life is that you have to make it accessible or it won’t work. Lowering the barrier to just do something each day means I might only research something I learnt the day before or add some comments to code I wrote a week ago. It really doesn’t matter what it is, as long as I get started each day.

So if you’re wanting to study but don’t think you have the time? Explore study options that let you learn in small chunks and to your own deadlines. I’ve found both Udacity and Udemy great services for this sort of thing. You won’t get a formal qualification from these services, but if you’re just interested in the skills then does that really matter?

Flow

Getting into a flow state is super helpful when you’re trying to get some coding done. Whenever I’m working on a course exercise or side project I find a few things in my daily routine really help focus my mind:

  1. Keeping my desk tidy – It seems silly but a cluttered desk is a cluttered mind for me. Keeping my workspace simple and functional really makes a difference.
  2. Meditation – I’ve dabbled with this for years, but this year I decided to make it a daily habit. I’m not perfect at it, but I’d say I manage to get 10 mins done in 9 out of 10 days. When I miss a day I notice it. I’m currently using Waking up with Sam Harris, which I’ve found very educational too.
  3. Music – Not all music is good for coding, but the right music makes a world of difference to me. I have a few sources I use to block out the world:
    1. Code Radio – Free Code Camp has a live streaming station via YouTube which is specifically for helping developers concentrate.
    2. White Noise – This isn’t technically music, but it’s just as effective at blocking out distraction.
    3. Spotify or Apple Music focus playlists – If you use a streaming service, there are loads of shared playlists for focus, concentration or study that do the job. I suggest using a paid service if you can afford it. Although I don’t come across a lot of ads in the free version of Spotify, they are frequent enough to interrupt my thinking.
  4. Changing location – Most of my best work happens in my home office, but some of my best work is done in a busy café. Sometimes when you’re having a hard time getting your head around a problem the best thing to do is take a break, change location and give it another go. There’s something about a change of scene that can make all the difference.
  5. Eat – If I’m not paying attention I don’t eat. If I don’t eat, I’m not effective at much of anything. I find removing choice helps me to stick to regular patterns of eating. Like with meditation I don’t always get this right but as a general rule, I eat basically the same thing each day at the same time. This makes sure I’m both fed and also taking regular breaks.

Do you have some flow state secrects I haven’t covered?

Pastebot

The more time I spend coding the more time I find myself researching solutions to workflow problems I’ve never had before. Copy and paste is a good example of this.

Sharpening my coding skills I find myself copying and pasting a lot more than normal. Maybe a better way to say it is coping and pasting in specific ways a lot more. For example, when I’m writing CSS I tend to copy and paste a small set of different colour codes over and over. Another example would be copying lists of items from a document one at a time to populate a list in an HTML document.

I had never considered that there might be a better way of doing these things until I stumbled on Pastebot. Pastebot is like copying and pasting on steroids. At a basic level, it keeps a history of everything you copy and paste. Even this simple function makes it incredibly useful when coding. Need to paste that colour code you copied 30 mins ago? Bam there it is in your clipboard history.

Once you’ve got used to having clipboard history you’ll never go back to your old ways. As a developer though that’s not even the best part. Where Pastebot really shines is its filters. Want to copy of a list of items then paste them as an HTML list? Want to copy some text and pasted it wrapped it in <p> tags? Pastebot can take care of all of that for you.

Do yourself a favour and at the very least investigate a clipboard manager, and if you’re on a Mac make sure you try Pastebot. It really is worth your time.

Maintaining an open-source project

This morning I read a short article on the maintainer of GitHub desktop, William Shepherd. For some reason, I kept seeing the article everywhere so eventually I surrendered to it. The post had a number of good points but the highlight for me was the advice to anyone maintaining an open-source project:

  • Have a clear vision of what you’d like your project to accomplish and be open to refining it when it makes sense
  • Have a detailed README that includes information on how to contribute to the project, submit bug reports, and a code of conduct
  • Work hard to make your project inclusive of all people from the start
  • Make your project easy to implement by eliminating the amount of work potential contributors have to do to build and run your project
  • Don’t put the needs of your project ahead of your own

You can read the full article on GitHub’s blog.


Commitment issues

You’ve been spending plenty of time together. You’ve had your ups and downs. As time’s gone on you’ve realised you like the way things are going and it’s time to commit.

Writing effective, communicative commit messages can make the world of difference to other members of your team. Just as with code comments or clear variable and function naming, good commit messages are worth putting some thought into.

First and foremost focus on communicating why the changes are being made. It’s easy to think commit messages are actually about what has changed, but reviewing the code will show you that. Why the code has change lets people know the intent of the change rather than the details of it. Good examples of commit titles are:

  • Update interface to the new branding
  • Add Dutch translation
  • Remove reference to Batmans true identity
  • Add GDPR compliance message

Once you’ve nailed your title follow up with a good description. For example:

Remove reference to Batmans true identity

The copyright text on Batmans website specifiys the copyright holder as “Wayne Enterprises”. This suggests that Batman has some association with the organisation. This update removes all connection between the two entities, protecting all parties. This fix addresses issue #391.

As you can see this message doesn’t contain any details about the code. It clearly highlights why the commit is being made and also connects the commit to a reported issue if one exists.