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.

Every team needs a beauty routine

Over the years everyone will develop their own beauty routines when it comes to their individual coding.

While it’s easy to become attached to how you like to format your code, in a team environment it’s really important to share the mirror with teammates.

Having an agreed set of standards on how the code will be formatted goes a long way to improve its legibility. If one person is using tabs, and another spaces, then things can get ugly fairly quickly. Of course, this sort of formatting can be done manually, but we’re not wild animals so we can just get the computer to do most of the work for us.

Most text editors have multiple plugin options to take care of this sort of thing. There’s even a standard called editorconfig that allows different developers to work on different projects, even using different editors. Using the editorconfig standard a developer can automatically conform to whatever the standard is for a particular project without much of a song and dance.

The two most popular beautifying plugins are:

Believe it or not, you can actually use both of these at the same time. There are some good details as to the how’s and why’s of that on CSS-Tricks.com

We’ve all got issues

Since I’ve been learning JavaScript I’ve been making an effort to do things as if I was working with others. The idea being that any project of meaning is very likely a collaborative one.

To my mind understanding how to effectively work with others on a coding project is as important as the coding itself. Also understanding how people work is always good when managing people is part of your professional life.

To that end, since I’ve recently created an “app” and put it on GitHub, the obvious next step was to record any issues with the app. So far there are three, but I suspect there are plenty more.

  1. The interface needs styling
  2. What constitutes victory isn’t clear
  3. Max score change doesn’t affect victory formatting

Over time I aim to chip away at these and any other reported issues. Of course being open-source, it’s entirely possible others may do the same. Which would no doubt teach me something too…

I made a thing – Score keeper

I’ve been doing a web development course for a few months and today I made my first thing that actually does something. Nothing amazing mind you, but it’s a start.

Do you ever have the need to keep score in a best 2 out of 3 kind of way? Me neither, but here’s a web app that does it regardless  🙂

At some stage, I’ll pop it on a web server and make it live for anyone to use. For now, if you’re interested in the code, take a look at the GitHub repo or you can download it directly.

Update: The app’s now live. Give it a try.

Learning from a 579-year-old printing press

Gutenberg is the name of WordPress’ new editor and like its namesake, the Gutenberg printing press, I think it’s going to be a big deal.

Recently I’ve been committing real time to upskill in web development. I wanted to go way outside my comfort zone as an opportunity to grow. So contributing to an open-source project like Gutenberg seemed like a good place to start.

Things I learnt from doing this:

1.  I have no idea what I’m doing, but I can learn anything – Seriously I know nothing! So, when I started looking for something to do to add value I needed something fairly basic. Thankfully Gutenberg is newbie friendly. This presents itself in a number of ways (see point 3) but the first sign of it was the “good first issue” tag on GitHub issues. As the name implies, this shows issue which are good entry points into making a contribution. So after a few days of self-doubt, I picked one and started working on it.

2.  There’s way more to contributing than code – The first thing I needed to do was get my development environment setup. I’d been learning Javascript for a while so I figured I’d be in good shape but in reality, I was miles away. I needed to setup docker, node, NPM and use GitHub with other peoples code. I’d never done any of this before. So before writing a line of code I already had a lot of new learnings. When I did get to coding, I thought I was in for some simple CSS changes. It turns out Gutenburg is using a CSS pre-compiler called Sass. Surprise! I’ve never used that before either, so back to Google University for another lesson.

3.  The community is incredibly supportive – Given the first two points, I needed a lot of advice. When I got stuck or submitted some code there was the community willing to advise and guide on how I could improve. They are also super accessible and transparent, I’d say more so than most work environments I’ve been in. Slack meetings and GitHub issue comments brought genuine insight, and as a result, skill growth. I never would have got any of it without the patience and generosity of the group.

4.  Having your code on millions of websites is a buzz – It’s strange in retrospect, but when I started doing all this it hadn’t occurred to me that if I managed to deliver something it would end up on millions of websites. Now that I have actually done that it does have an addictive feel to it. However minor my contribution is, the scale of the end result is truly massive.

I think at this point it goes without saying I would highly recommend contributing to a project. Regardless of your skill level, there is something to be learned and value to be given and received.

DOM DOM DOM

Playing with the DOM is all about adding interactivity to your page. The DOM (Document Object Model) is the interface between your JavaScript and your HTML+CSS. The browser takes all the elements of your page and turns it into a JavaScript object.

All the elements of the DOM for your page are contained in the object “document”. You can show everything in “document” by using this command in your browser’s console:

console.dir(document);

Working with the DOM is similar to CSS. This is because you select an element then you manipulate it. Here’s an example of what I mean:

var batmanComments = document.querySelectorAll( ".batmanComments" );

In the above example, we are selecting all elements with the class “batmanComments”. Now to do something with our newly selected elements:

var length = batmanComments.length;
for (var i = 0; i < length; i++) {
    batmanComments[i].textContent = “Ironman sucks”
}

This code replaces the contents of each element in the “batmanComments” array with the string “Ironman sucks”… because maturity isn’t Batman’s strength.

If you want more details on working with the DOM, MDN is a good place to start and an even better reference as you’re learning.

Load scripts last

So you’ve got your HTML and CSS sorted and you’ve started to drop in some customs scripts to make things a bit interactive. To keep things in shape it pays to develop some good habits early on.

One such habit is placing your scripts just before the closing body tag like this:

...

<script type="text/javascript">
  var secretWords = prompt( "What are the secret words?" );
  var welcomeMessage = document.querySelector( "h1" );
  function unlockBatCave( secretWords ) {
    if ( secretWords === “Ironman sucks” ) {
      welcomeMessage.textContent = “He sure does, right this way sir”;
    } else {
      welcomeMessage.textContent = “Nice try Joker”;
    }
  }
</script>

</body>

</html>

We do this because it allows the full HTML page load before the script runs. This means the page contents will appear faster for the user and the HTML will be ready for you to manipulate it with the script.

The second thing you should do is split your scripts out into a separate file rather than writing them directly into your HTML files. Loads of online tutorials use inline scripting because it’s easy for demonstration purposes, but it isn’t good practice in reality.

Once you’ve moved your code into a separate file update your script tag like this:

<script type="text/javascript" src="your-javascript-file.js"></script>

Equals vs equals

In JavaScript not all comparisons are created equal… see what I did there. Let’s say we’re comparing two values like this:

if ( 42 == “42” ) {
 return “The meaning of life is 42”; 
}

The use of “==“ will compare two values regardless of their type, so in this example, it will return “The meaning of life is 42”. Used correctly this can be fine of course, but it can leave you open to issues like this:

var meaingOfLife = “41”;

if (meaningOfLife == 41) {
  meaningOfLife += 1;
}
return meaingOfLife; 

In this example, we’ve done the same comparison but then tried to add to the meaningOfLife variable which we can’t do because it’s a string, not a number. This is why as a general rule it’s best practice to use “===” for comparison as it will compare both value and type. Here’s an updated example:

var meaingOfLife = “41”;

if (meaningOfLife === 41) {
  meaningOfLife += 1;
}
return meaingOfLife; 

This version will correctly return “41” due to the fact the if statement will return false because the items match in value but not type. Do yourself a favour and default to “===“, it’s the comparison you’re likely to want the majority of the time.

Github Learning Lab🔬

I’ve been using GitHub for a while now as part of my spelunking into the world of VR and Mobile development. I think it’s fair to say it’s done a great job of protecting me from the inevitable mistakes of learning something new. Having said that, it does take a while to get your head around anything other than the basics.

Thankfully there are a large number of resources available to help you along the way. Most recently I discovered GitHub Learning Lab, a fantastic resource for learning how to use the platform for your own projects or contributing to others.

I think the thing I enjoy most about this particular option for learning is that it’s actually using the tools themselves. Yes, there is text and video to consume, but you actually use GitHub itself to work with the course material. I’m a real learn by doing sort of person so this sits particularly well with me.

So if you’re new to GitHub, or just want to solidify your knowledge of it, I suggest you take a look.

 

How to: Setup CocoaPods in Xcode

Hey, guess what? I’m learning iOS development and have been for months! Thought I might increase my rate of publishing to my blog if I did what I did for my VR course and posted study related stuff here. So to that end…

Here’s a simple step by step guide for adding CocoaPods to your iOS projects. There are quite a few steps involved and I suspect this is something that is done relatively infrequently in a single project. It’s always nice to have a reference for this sort of thing.

Steps

  1. Inside Terminal, change directory to the folder containing the Xcode project
  2. Initialise a new Podfile. You do this by using the “pod init” command. If you need more details read about it in the CocoaPod’s guide for pod init
  3. Open the Podfile in Xcode. Just drag it to the Xcode icon in the dock
  4. Add the library to the pod file. Here’s an example Podfile with SwiftyJSON and Alamofire libraries added
  5. Install the pods using the “pod install” command in Terminal. Here are more details on pod install should you need them
  6. Now open your Xcode project via the new .xcworkspace file

Easy as pie.