Coding on a plane… on an iPad

The project

In my ongoing efforts to up my development game, I’m currently working on learning how to create an app that has user authentication. Adding authentication to the web app is completely new to me and as always I’m time constrained. So when I found myself in a plane on the runway for over an hour thanks to a mechanical issue I thought why not try and get some study done on my iPad.

I had previously downloaded all my courses content on the Udemy iPad app. This was some luck on my part as streaming video content over a 4G data connection would quickly blow through my data cap which wouldn’t be ideal. I also had a bunch of dev apps I’d downloaded ages ago but hardly ever used.

The setup

I wasn’t sure how much I would really be able to do given I had a set of tools that I guess you’d call “non-traditional” from a web development perspective. Here’s what I used:

  • iPad Pro 10.5 – This continues to be a great machine for me. The screen size gives me a lot of flexibility without the bulk of the 12.7. It does have its limitations of course but increasingly iPad is filling more and more of my needs
  • iPhone 6s – My iPad doesn’t have LTE so I used my phone as a hotspot to connect to the internet
  • Textastic – While of course I wish had a text editor with all of the power of a desktop app, Textastic is the best I’ve found so far on iOS. The code highlighting is nice, it comes with a range of themes and custom fonts and works seamlessly with my iOS GitHub client of choice, Working Copy
  • Working Copy – This is one of those apps that constantly amazes me. It feels like this is an application that just shouldn’t be able to work on iOS but somehow it does. I had absolutely no issues connecting to my GitHub repos, downloading the latest build of the project I was working on, making changes in Textastic, then pushing those changes back to GitHub. Perfect!
  • Udemy – The work I was doing was part of the Udemy course I’ve been working through and thankfully the app supports downloading the course content to the device.

What works well

The fact this was possible at all feels sort of amazing. For the most part, the applications I used (listed above) did a great job at the basics and in some cases were far more. I think the thing that really stood out to me most was how the single view full-screen apps made me less likely to switch between apps and, as a result, help me focus on what I was doing more. That focus altered my workflow quite a bit. I’m not sure it was better or worse, but it was certainly different. Thinking about it I think I was far more likely to stay in my text editor and write code from my own mind rather than relying on the content of another window.

I also think the lack of some of the power features of a desktop text editor meant I was paying more attention to everything I typed. Not having the code editor automatically format my text for example really made me pay attention to how I was laying out my code because I knew it wouldn’t be reformatted on save. It will be interesting to see the differences between my handwritten code and what my normal beautified code looks like.

What could be better

Screen real-estate – Whenever you’re doing web development you need a few windows open at a time. You really can’t have too much screen real estate in this sort of work so a 10.5-inch screen is always going to be tight. Having said that it wasn’t horrible either.

Testing – The iPad doesn’t have a terminal nor can it run a node or mongo server so I wasn’t able to test my code. While it’s not a big deal given I was just following a tutorial I wouldn’t want to spend to much time working on something without being able to see the results of my efforts. That would run the risk of building issues on top of issues and it might lead to a lot of wasted effort. I could have used Panics excellent Prompt but the app I’m working on isn’t running on anything other than my local dev environment on my Mac. Sorting that from my iPad was more effort than I was prepared to make, although it probably could be done.

Textastic – I like the look and feel of Textastic but compared to my normal desktop setup it feels a li bit like coding in the dark. These may be features I’m oblivious to but I couldn’t see any form on code completion, code beautifying, or much beyond code highlighting. Not a deal breaker of course but it’s another little thing that makes you less productive.

Udemy app doesn’t support split screen – This really means a lot of switching back and forth between apps. Picture in the picture did work but because of the screen size, it made the screencast unreadable so that was of limited value.

I’m really interested to see how iOS continues to evolve as a part of my development workflow. With Apple splitting iPad off into its own OS (iPadOS) it’s difficult to imagine a future in which the iPad doesn’t become an even more capable development machine. With the increasing levels of support for external displays, full-blown safari support and other extended capabilities it’s not impossible future iPads might become fully capable dev environment. At least in some use cases.

The thing I’d like the most that would make the biggest difference is a terminal app. It’s a bit of a pipe dream as I can’t see Apple going that way, but I can dream, right?

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.