Categories
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 really easy to do using the following command in terminal:

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

Categories
Dev Geekpulp JavaScript Tools

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?

Categories
Geekpulp

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 as 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.

Categories
Geekpulp

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.

Categories
Geekpulp

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.

Categories
Geekpulp

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.

Categories
Geekpulp

GitHub flow

I’ve recently been attempting to contribute to some open-source GitHub projects with varying degrees of success. One thing that’s extremely useful to do before you start contributing is to develop a basic understanding of the standard GitHub workflow.

It’s not especially complicated but it can be a real faff if you don’t do it correctly from the start.

Step 1 – Clone the repo

The first thing you’re going to need is your own copy of the project to work on. You do this by cloning the repo to your local machine where you’ll make your changes.

Step 2 – Create a branch

Now you’ve got a local copy you’ll want to create a separate branch for your specific contribution. For example, if you’re working on issue #3271 and issue #3244 you’ll want to create separate branches for each issue. It’s a good idea to name this something like fix/issue#3271 and fix/issue#3244 so you know which branch to submit for what issue once you’re done.

Step 3 – Make commits

Once you’ve made your changes within the appropriate branches make your commits. Commits tell the story of your changes, be sure to write clear concise comments that communicate your intent to other developers reading them.

Step 4 – Submit a pull request

Once you believe you’ve completed your changes create a pull request to submit them. Create one pull request for each issue and corresponding branch you’ve created. Pull request are a way of notifying the projects “owner” of your proposed changes for consideration.

Step 5 – Discuss and refine

It’s likely upon review there will be some conversation around the code and changes. Others may have ideas on different approaches and/or improvements to the update. You can continue to make changes and improvements to refine your solution as a result of these discussions. Just keep making those commits.

Step 6 – Deploy

This part you’re likely to be less involved with. If and when the “owner” decides to use your code they will likely deploy it into the master branch where it will then be tested along with all the other changes made in that round of updates. This is were things get exciting.

Step 7 – Release

Assuming everything is tickety-boo your code is then included in the next production release leaving you with a sense of satisfaction from having helped to make the world a better place one pull request at a time. Don’t forget to be grateful for all the help along the way. Open-source is all about community coming together, so remember to give high fives all around.

Categories
Geekpulp

No Comments

When I was first learning to code, something that came up a lot was to always comment your code. Code comments have value, but despite what my teachers at the time may have thought, you should actually try not to use comments.

This isn’t to say you shouldn’t communicate to the reader what the code is trying to do, you should just do that by writing readable code rather than relying on comments.

You do this through a variety of methods, some of which I’ve already covered in previous posts. Things like writing descriptive functions, not abbreviating your variable names, simplifying the code by keeping variables close to the functions that use them, and limiting arguments passed to functions and methods. Bascially this:

var scandal = {
  title: "Moon landing a hoax",
  peopleInvolved: [ "Niel Armstrong", "Buzz Aldrin" ],
  evidenceAvailable: [ "back-stage.mp4", "set-photo.jpg", "confession.pdf" ],
  mediaCoverage [ "www.crackpots.com", "www.flateathers.org" ],
  securityStatus: "TOP SECRECT"
}

function coverUpScandal( scandal ) {
  promotePerson( scandal.peopleInvolved[0] );
  destroy( scandal.evidenceAvailable );
  discredit( scandal.mediaCoverage );
  scandal.securityStatus = "Super duper ultra secret";
}

Is better than this:

//Create a scandal object
var scan = {
  // scandel title
  t: "Moon landing a hoax",
  // names of the people involed in the scandel
  pplIn: [ "Niel Armstrong", "Buzz Aldrin" ],
  // evidence avalible
  ea: [ "back-stage.mp4", "set-photo.jpg", "confession.pdf" ],
  // media outlets covering the scanal
  mc [ "www.crackpots.com", "www.flateathers.org" ],
  // security status of the scandal
  ss: "TOP SECRECT"
}

function cus( scan ) {
  // promote Niel Armstrong
  prmtPrsn( scan.pplIn[0] );
  // destory the scandel evidence
  des( scan.es ); 
  // discredit the media coverage
  dis( scan.mc );
  //change the security status of the scandal
  scan.ss = "Super duper ultra secret";
}
Categories
Geekpulp

DRY variables

The concept of DRY code is simple, Don’t Repeat Yourself. So if you look at some code you’ve just written and notice it’s looking a bit moist, AKA the same stuff repeating over and over, there’s a good chance it’s an opportunity to refactor.

This is also true with variable declaration. Take the this example:

var umbrella = "open";
var raincoat = "on";
var gumboots = "on";
var music = "Singing in the rain";
var action = "Jumping in puddles like a man";
var danceMoves = "The Swim";

Notice how when declaring loads of variables we tend to repeat var a lot? Not very DRY now is it? Let’s put a towel over it:

var umbrella = "Closed",
raincoat = "off",
gumboots = "off",
music = "Walking on sunshine",
action = "slip, slop, slap",
danceMoves = "The twist";

Small difference’s like this add up over the course of a project so it’s best to make these your default habits when you’re a beginner.

Categories
Geekpulp

Zombie code

Part of developing (and certainly learning to develop) is creating code, commenting it out, and creating a better version. As you get into a flow state with coding it’s really easy to get into he habit of doing this and not going back and clearing out the undead code comments.

Here’s an example of what I’m talking about.

function thriller() {
  return “Something evil\'s lurking from the dark”;
}

//function funkyTown() {
//  chargeKeytar();
//  dressInPastels();
//  return “Gotta make a move to a town that\'s right for me”;
//}
//funkyTown();

thriller();

The trouble with code like this is it’s not clear why the commented out code is there. Is the intention to reworking and use it? Can we remove this because the code was old? Was it commented out accidentally?

Zombie code is ambiguous code, and that’s not helpful for anyone. It’s fine in your own dev environment in the short term, but don’t leave it in too long and never let the zombie out in public. It will only eat everyone’s brains.