Mutation === đź’©

One of the many things I’ve picked up from the excellent Syntax podcast over the years is mutation should be avoided. Today a came across a great example of this with the reverse array method.

I had some code that looked something like this:

To my surprise the resulting output of the console logging was identical. Both output the array in the same order. So what’s going on here?

As it turns out, the reverse method actually mutates the original array. Obviously if you don’t know this (like I didn’t), this can be problematic. The best way around this shorting coming is to spread the array into a new one, then reverse it like this:

Protecting myself from myself đź”’

Being the lone developer on a personal project makes it really easy to do sloppy things. For example, doing undisciplined things with my git repo, like just working in the master branch (I really need to change that to main) and pushing commits directly to it.

It’s much better practice to create a branch for each “issue” and merge that into the master branch (as per the GitHub flow). When it’s just you it’s easy to forget to actually do that, and even easier to not care when you realise, and just merge your changes to local master directly into master origin.

Whenever that happens it always feels a bit.. yuck… so today I’ve implemented some some discipline in the form of branch protection rules. Nothing too fancy, just preventing me, or anyone else, from pushing directly to master without first having a pull request approved. Yes I will be the one doing the approval, but that still means I have to actually create a branch and make the pull request in the first place.

This should mean I stop making a mess of master and the whole thing becomes much cleaner.

Published
Categorized as Geekpulp

Taking the month off

After I completed the full stake web dev boot camp (see my final project code) I decided to give myself a month off studying software development to explore a few other interests.

I’d always kicked around the idea of doing some electronics, so I had a hunt around for some little starter projects to upskill in the practical basics. Mostly I just wanted to familiarise myself with soldering and various electronic parts.

I came across two jobs which I thought sounded perfect:

  • Hacking a set of AirPods into custom (artisanal) headphones for use with my Oculus Quest.
  • Constructing a multimeter kit (a paint by number style kit)

Both projects ticked all the right boxes for me. They’d let me create something useful, while also learning new skills. All of this I could just chip away at over the month when I had 15 mins free.

My custom-made headphones for the Oculus Quest

Both projects worked a treat. I think the biggest thing I took away from them is that soldering requires practice to get right. Looking at my initial solders vs the last ones I made, it was a clear progression in skill.

One thing that surprised me a bit was how quickly I felt the soldering iron I was using (a cheap $25 iron) was becoming the limiting factor in my progress. Normally when I start a new skill I tend to just work with cheap gear, and it takes some time for my skills to eclipse the constraints of them.

The next project I’m starting on (making my version of this cyberdeck) I’ll be replacing my iron with something with more control. Either this cool little USB powered one or a more full-on soldering station.

Something I’m conscious of with taking on new skills is the perishability of my other skills, particularly software development. As much as these more hands-on projects are super fun, my intention is to keep them as hobbies rather than something that occupies a lot of my attention.

Now that it’s February I’m starting to get going on more development training. I found the web development book camp a therapeutic return to creating things in software, and it’s something I’m wanting to expand on more in 2020.

I haven’t completely settled on exactly what shape that will take this year, but I’m leaning towards learning React on the front end and using WordPress as a backend. I really like the philosophy behind WordPress and the company behind WordPress.com, Automattic. They are really delivering something profoundly important to the web, and that tickles me.

Sponsor me!

Did you know you can sponsor my study and contributions to open source projects? If I had my way that’s how I’d spend all my professionally time, but a dude’s got to eat right?!

Any funds raised will go directly towards covering costs of study and/or contributions to the open web. The best part is GitHub like me so much they will match any contributions you make. Cool eh?!

I’ll also tattoo your name on my forearm… just kidding, but I will give you a shout out on my blog and link to anything you’re wanting to promote (as long as it’s not your spam site of course).

If you want to help me out, I’d very much appreciate it. https://github.com/sponsors/geekpulp

Published
Categorized as Geekpulp

MongoDB and macOS Catalina

Like a good Apple nerd, I updated to the latest version of macOS Catalina. If you’re using older 32bit apps Catalina won’t run them. Thankfully, I wasn’t in that position, so I didn’t anticipate any issues. So young so innocent.

As it turns out another chance in Catalina does affect my normal workflow. The change is related to a security improvement that prevents users from creating new files in root.

Not an issue for most things, but MongoDB by default uses /data/db as the location for storing data. To fix this the best solution I came across was to simply change the location from the default to somewhere in your user folder. This is easy to do using the following command in terminal:

Mongo will now work, and you can get on with life.

What is the state of JavaScript?

This JavaScript thing is really catching on eh? As the name suggests, “the state of JavaScript” survey gives a snapshot view of JavaScript development. What everyone (over 20,000 developers anyway) is using and enjoying or otherwise. It also gives a general sense of the direction things are going in. As with the StackOverflow survey, I found it well worth a read. It’s also beautifully presented.

Some of my main takeaways:

  • React is where it’s at from a front-end framework perspective
  • Express seems to be the stable go to back-end framework for Node.js
  • GraphQL appears to be the rising star of the data layer, but Redux is the player to beat
  • There seems to be a range of good options with testing, but the community seemed to enjoy Jest the most
  • Building desktop and mobile apps using JavaScript seem to be a two player game at present. Electron for desktop and React Native for mobile. This space does have some competition on the rise though. Flutter looks particularly interesting
  • VS Code dominates text editors by such a large margin, I really need to give it a second look. I haven’t seen anything that makes me think I’ll move from Atom but I’m open to the possibility

Have you read the survey? Did I miss anything you found particularly interesting?

jQuery

What is jQuery?

jQuery is a JavaScript library designed to simplify front end web development. It is the most widely deployed JavaScript library by an insanely large margin.

Why use jQuery

There are quite a few reasons you’d want to use jQuery, or a library like it, in your project rather than vanilla JavaScript. Here are a few examples.

Ease of use

JavaScript can be a handful, jQuery can be far cleaner and more concise than the equivalent in vanilla JavaScript. Take a look at these two examples of a fade in effect:

JavaScript Fade In

function fadeIn(element) {
  element.style.opacity = 0;
  var last = +new Date();
  var tick = function() {
    element.style.opacity = +element.style.opacity + (new Date() - last) / 400;     
    last = +new Date();
    if (+element.style.opacity < 1) {
      (window.requestAnimationFrame && 
      requestAnimationFrame(tick)) || setTimeout(tick, 16);
    }   
  };
  tick();
}
fadeIn(element);

jQuery Fade In

$(element).fadeIn();

Cross browser support

Cross-browser support is one of the most difficult things about web development. jQuery normalises this so you don’t have to worry about different browsers as much.

This reason becomes less true with time. However, If you need to support older browsers, particularly anything older than IE8 then you should seriously consider jQuery.

Lots of people use jQuery

It might seem like a silly reason to use something just because loads of others are using it too. Having said that there are some real benefits to that thinking. In particular, there are plenty of resources available to help you learn and use jQuery. So if you need examples of how to do something you should have no problem finding them.

Even if you’re already a skilled developer, the practice of coding is continuous learning. So it’s always good to have a strong community around the area in which you work.

Why not use jQuery?

Based on the above you’d think jQuery would be a no brainer, and in many situations that’s true. However there are plenty of situations where it isn’t the best option, here’s why.

You can do everything without it

There is nothing in jQuery you can’t do in vanilla JavaScript. So depending on your project adding jQuery to the mix may actually be creating an unnecessary dependency. If you’re not using many of jQuery’s capabilities in your app, it pay’s to consider alternatives.

jQuery contains hundreds of methods that on many applications you’ll never use. There’s no sense in bundling all that in if you’re only using a small part of it.

People are moving away from jQuery

This one is a little contentious depending on who you’re talking to. For a few years now there are signs that people may or may not be moving away from jQuery. Regardless, if new jQuery based projects are in decline there is such a huge existing usage of the library it still pays to learn it.

More on issues

The more you understand an issue the better equipped you’ll be to solve it. When I was creating issues in GitHub for Score Keeper, something about the process felt a bit lacking. A developer needs specific details and the system wasn’t working to deliver them.

Even the issues I’d submitted lacked the detail for someone (other than me) to address the problems outlined. I’d previously contributed to Gutenberg, and I noticed the team had templates for recording issues. As it turns out, this is a standard feature in GitHub.

To improve my practice, I’ve enabled the two default templates provided by GitHub. The first is for reporting bugs like “Max score change doesn’t affect victory formatting” and the second for requesting new features like “Interface needs styling”.

Click the “Set up templates” button in your repos settings tab to get started with issues templates

In time I’ll be updating the current issues submitted to conform to the templates. Any new issue will get the right template depending on its nature. A bug will get one template, while a feature request will get another.

Any tool that can improve communication like this is worth its weight in gold.

Listen to your heart

JavaScript is responsible for the behaviour of your website/app. At the heart of affecting the behaviour of the page is listening for user interaction events. These are things like button clicks, key presses and drags and drops.

To do this, first we select an element then we add an event listener. To add an event listener we use the “addEventListener” function like this:

var button = document.querySelector( "button" );

button.addEventListener( "click", function() {
  console.log( "SOMEONE PLAY SOME ROXETTE!" );
} );

A common pattern is to add event listeners to a set of elements, like each item in a list so each item is clickable. The code for this would look like this:

var listItems = document.querySelectorAll( "li" );
for ( var i = 0; i < listItems.length; i++ ) {
    listItems[ i ].addEventListener( "click", function () {
        this.style.color = "pink";
    } );
}

You can also add multiple event listeners to the same element. So, for example, you can listen for a hover and a click on the same button and take separate actions for each. Listen events are very powerful and a great addition to your JavaScript coding toolbelt.

This is our concern, Dude

In web development, there’s a concept called “the separation of concerns” between your HTML, CSS and JavaScript. Each language plays a role in web development and it pays to remind ourselves what these roles are:

  1. HTML = Structure
  2. CSS = Appearane
  3. JavaScript = Behaviour

There are some overlaps between them, but this should be minimised wherever possible.

There is some overlap between HTML, CSS and JavaScript but this should be minimised wherever possible.

For example, while JavaScript can affect individual CSS styles but it’s good practice to define classes in your CSS files instead. Then you can use JavaScript to call those classes like this:

<!DOCTYPE html>
<html>
<head></head>

<body>
<div id="concerns">
  <ul>
    <li>JUST BECAUSE WE'RE BEREAVED DOESN'T MEAN WE'RE SAPS!</li>
    <li>Sir, please lower your voice</li>
    <li>Hey man, don't you have something else you could put it in?</li>
    <li>That is our most modestly priced receptacle.</li>
    <li>GODDAMNIT! IS THERE A RALPH'S AROUND HERE?!</li>
  </ul>
</div>
</body>

</html>
.concerns li {
  font-weight: bold;
  font-size: 100px;
}
var myConcerns = document.querySelector( "#concerns" );
myConcerns.classList.toggle( "concerns" );

This way the CSS is still where the appearance of the page is manipulated and the JavaScript is still handling the behaviour component. Following this sort of structure makes it easier for your fellow developers (and you) to know where to do what in your code.

Published
Categorized as Geekpulp