100 Days of Code

Using Some ES6 JavaScript

This is something I worked on as part of my 100 days of code challenge during week 3.

I invested a bit of development time into a project I've been thinking of for a long time but left it neglected at the beginning stages.

It's a Javascript split-testing library.

I'm perfectly capable of reading and writing JS code with plenty of real world experience working with it. It's not one of my strongest skills though so I took this as an opportunity to improve and learn some more things. 

Javascript and ES6

When people say modern Javascript what they often mean is ES6 Javascript. The 6th edition was finalized in 2015 and is called ECMAScript 2015.

Sadly even though it's been around for some time browser implementation was slow to start and there is no backporting being done in many cases for older browser versions.

Modern browsers support ES6 code fairly well. Chrome, Opera, Safari, Firefox and even Edge have good levels of support – older browser versions do not and there's essentially no support for it on any version of IE.

Developers want to take advantage of the newer features that ES6 offers. They write ES6 code then compile it to ES5 compatible code – systems like babel make that easy. I wanted to take advantage of the new paradgrims too..

New Methods and Features in ES6 I Was Excited About

Deciding to go full ES6 in this project allowed me to take advantage of some features that I had previously only made minimal or no use of. There are 3 things I discovered in ES6 that made writing JavaScript a vastly more pleasant experience.

  • Native Classes to build with.
  • Variable and Function scoping inside blocks with let.
  • Default value assignments for function declarations.

I'm excited to work with those features all the time. Classes especially.

In ES5 you could use variables with objects, custom prototypes and anonymous functions to get similar Classes-like behaviors. To me that method always seemed to create very convoluted and hard to read code so native Classes are very welcome.

There is a couple of other very nice additions that I'm looking forward to using in future and in code refactors.

  • Rest and Spread Operators – ...variable.
  • Template Literals with raw string access.
  • Constants – Immutable Variables
  • String Searching.

Doing Things the ES6 Way

There are a few things in this project that I done differently to in the past and in ES6 they are much cleaner.

Merging Objects

While working I wanted to merge some objects. Previously I'd done that with a custom function that iterates through all prototypes of an object and merged them into another object. ES6 has a method for doing just that in a single line.

let defaults = {the defaults};
 * Merge 2 (or several) objects together.
 * This merges myObject into the object containing the defaults.
 * and returns the updated destination object only.
this.myObject = Object.assign( defaults, this.myObject );

Better Sub-String Methods

A lot of work takes place with strings and string manipulation. In my latest project I had the pleasure of searching for values inside strings using much cleaner methods.

let myString = 'a string';
// there's a `startsWith` method now and it includes an index spot. This returns true because we start at index 4. There is also an `endsWith` that behaves similarly.
if ( myString.startsWith( 'ring', 4 ) ) {
    console.log( 'found "ring" at end of ' + myString );
// my favorite is `includes`. Previously I would have used indexOf or a regex for complex strings for this.
if ( myString.includes( 'tri' ) {
    console.log( 'Found "tri" inside of . + myString );
100 Days of Code

100 Days of Code Challenge

Week 1 – Day 1-5

For the first week of my 100 Days of Code challenge I didn't go too far out of my way to work with code. It's part of my job, I do it day-to-day.

I spent some time looking for a code bug to discover it was simple typesetting issue. I learned, once again, the value of explicit typesetting and the pitfalls of allowing an operation to do it's own type juggling.

When you're in need of specific operations or types to be the outcome it's best to strictly define those types instead of allowing the system to do it for you.

Another thing that I was amazed by is how much can be done, in a far more efficient manner, when you spend time only in the command line and semi-automate tasks.

There are times when it's far more time effective and less error prone to do that over manually processing data and verifying the results of your work.

Juggling & Defensive Typecasting

Be defensive when it comes to casting variables to the types you expect when data comes from somewhere you're not in control of. Sometimes it's what you expect – sometimes it's not.

William Patton

Wait… What type is this??

Strict typesetting is a good idea when working with variable types in a loosely declared language because sometimes types are juggled in a way that you don't expect and when you've got a type you're not expecting your results may not be what you're expecting as well.

Example of this happening with strings and numbers in JavaScript:

// Data comes from an object.
var data = {
    'id': '1452',
// Try increment the ID number by 5.
let new_id = + 5;
 * Instead of incrementing the starting data was a string 
 * and appended our number to the end like a string concat.
console.log( new_id ); // new_id = 14525
 * What we really wanted to happen was to increment the number
 * by 5.
let new_id = parseInt( ) + 5; // parsed the `id` and made sure it was int.
console.log( new_id ); // new_id = 1457

There is also a different operator specifically made for doing type conversions from string to number in javascript and is written in a more easily flowing manner. Both methods create the same output when successful.

var data = {
    'id': '1452',
let new_id =;
new_id = + 5;
console.log( new_id ); // new_id = 1457

Command Line Automation

Working in command line and creating automation scripts beats manual tagging and sorting for large datasets.

Every. Single. Time.

William Patton

With a directory of .html files to have articles exported and a database of thousands of posts already imported: Find what files were not already converted and imported to the site as articles.

  • The list of content that was intended to include came from thousands of .html files – in various directories arranged mostly by year.
  • Using mysql queries to extract data about articles then filter it so it had only a value easily compared against the files needing import – that value will be a match with the filename that's to be imported.
  • With the data use BASH with some loops and a direct comparison logic to find matches.
  • Use git diff reporting to determine what posts were missing from the list of imported content.

BASH Scripts That Loop and Compare

At the heart of things were bash scripts that mostly looped within a loop.

Iterate through lines of a file while looping through lines of another file then output the results to different file.

It's a blunt object approach. A lot of overheads, not at all efficient in operations.

Regardless of inefficiencies it didn't take long to run through. It was simple and incredibly effective to highlight the differences between items present and items expected.

I called the script it then ran it passing 3 .txt files. One filled with the files that are expected to be in the list, another filled with the list of articles present for this category and the 3rd file to store the results.

./ filename-list.txt metavalue-present.txt matched.txt 

echo "Matching $1 inside of $2 and saving to $3"
echo "Do the above values look correct?"
sleep 5s

# loop through all the lines in the first file passed.
while IFS='' read -r line || [[ -n "$line" ]]; do
	# loop through all the lines in the second file passed.
	while IFS='' read -r linein || [[ -n "$linein" ]]; do
		# if line from f2 matches the line from f1...
		if [[ $linein == *$line* ]]; then
			# echo line 1 (filename) to a file.
			echo "$line" >> ./$3
			# we found a match, break from loop 2.
	# loop 2 is passed contents of file passed as arg2.
	done < "$2"
# loop 1 is passed the contents of file passed as arg1.
done < "$1"

The next step was a repeat of this except to compare the list of expected items against the list of matches and save that to new file too.

./ filename-list.txt matched.txt missing.txt 

The final step was to use git diff to compare the differences between the matched items and the original list of items expected.

One thing that helped here to improve processing speed by several minutes per run was to split the large groups of data into smaller, more manageable, sets or categories and then handle comparing them in them in batches. Since my compare method was so inefficient this helped a lot.

100 Days of Code

A 100 Days of Code Challenge

I've been mulling over this idea for a long time. 100 days of code. The original idea is essentially spend 1 hour a day coding, document the progress and share on code platforms or on social.

On the surface that sounds easy as I spend almost every single day with code in some form or another. Generally it's an hour or more.

The fact is that it's difficult to have 100 consecutive days to work on an idea without interruptions. Even if it's just 1 hour a day – sometimes you might just not have it. There's work and family life to prioritize.

30 days ok, 60 maybe. 100 full days in a row working directly with code and no deviations: That's more of a challenge than I can commit to.

An Outline of a More Forgiving 100 Days of Code Challenge

It's not just about writing code – there is plenty of value to be found in working with code it in other ways.

It is not 100 consecutive days and you never need to commit 7 days a week.

Improving documentation for code or reading and reviewing someone else's code are both high value tasks in some cases.

  • It's 100 working days, no minimum per day.
  • Code review or other improvements are included and highly encouraged.
  • Documentation isn't necessary everyday – once a week is a good target.
  • Daily tracking isn't required – track ideas or projects over the space of a week or more. 

The 100 days could start from any point. I've decided to start January 1st.

  • Between January 1st and June 1st there are a little over 100 working days.
  • That's 5 days in a week – or every day minus weekends and major holidays. Spread over around 5 months of time.

I will be documenting some things I work on each week, write some example code and schedule posts to publish throughout the span of the challenge.

Documentation Format Suggestions

Sharing of knowledge in the programming and development world is done in a few formats. Most obviously the sharing of code. That's a great way let someone see the work that's been done or methods that were used.

Another common way to share is via articles, blog posts and books. This is useful for sharing overall process, detailing setup steps or explaining some thought processes behind what's been done.

  • Anything that can be shared in a blogpost. Text, screenshots or examples could be included here.
  • Links to code sharing platforms like a GitHub repo or a Codepen.
  • Social shares like tweets.

Consider helping someone to solve a coding problem as being a valid exercise as well. Working through an issue tracker like in GitHub repo or similar counts. StackOverflow is a great place to offer assistance and to share what you know with someone in need of help. 

Important Notes

With an emphasis on working with code there's some things I think will be relatively important to keep in mind throughout the 100 days. It's about working with code not necessarily writing code all the time.

  • Looking at and learning from some code is a valid exercise.
  • Adding inline docblocks or improving existing comments is valid. 
  • Participating in an open source project of any kind will be valid.

Remember if it's working with code then it can be considered part of the challenge. Some other things to note throughout the challenge:

  • Sharing of example code is always good, sharing of full source when possible is encouraged too.
  • Creation of actual code documentation – either external documentation or inline code doc block addition or improvements is a very big part of writing code that is for sharing. 
Development Tools

Open Source Projects That I Rely On To Effectively Do My Job – Part 1

There are a number of things that exist in the open source world without which I do no think I could do my Job. I am a Web Developer. I work on a range of projects using different systems, languages and processes. I work a lot with WordPress as well.

Many aspects of my work revolve around scanning logs, writing and reading code in a text editor and browsing the internet. I have my prefered programs for doing each of those tasks.

This is a set of articles that look at a lof of the open source projects that I rely on to do my job and do it effectively.

Open Source Operating Systems and Server Software

A lot of open source code is enabled by other software, tools, specifications and systems that are also open source. The most obvious enabler is the availability of open source Operating Systems. These are used on local machines but even more common in infrastructure powering systems and services.

Operating Systems

Open Source OS are only possible because of the ability to take many other pieces of OSS and link or modify it in such a way that it works well together as a whole.

I mainly use Linux OS. Ubuntu, Cent OS, CoreOS, Arch. At the heart of them all is the Linux Kernel. All open, all developed in public.

Server Software – Specifically HTTP Servers

Another specific type of software that I rely on is HTTP servers. These servers allow requests and responses to be made between clients and servers – in a user friendly way returning the rich content we expect on the web today.

There are 2 specific softwares that dominate the http server domain. Apache and NGINX. 

I'd take a guess at 75% or more of all http requests made over the internet would be responded to by one or the other.

Without both OSs and HTTP servers being available as open source I doubt that the web would be what it is. I expect my job may not exist.

PHP & JavaScript

WordPress is primarily written in PHP with many JavaScript components for use in the browser. PHP is itself an open source language and JavaScript is an open specification.

Coding for WordPress most of the time involves working with pure PHP or JavaScript and then hooking that code into WP with some more code.


The application layer of most applications, including WordPress, connect to a data layer that is often a MySQL database. MySQL is another open source project (although at the time of MariaDB creation that was very up in arms).


Node is another popular system that I work with a lot. Essentially it runs JavaScript without a browser.

Many people are first introduced to Node as part of build tools – especially since the usage of task runnings become more popular. Grunt and Gulp run in Node. If you've ever ran a npm install command you've used Node.

Development Tools

Automate All The things With Grunt

I’ve recently become a fan of Grunt. It’s a JavaScript task runner that get installed within a project to handle jobs for the project. For me it’s extremely useful for a whole range of things – even in just a short 2 weeks I’ve got so much more value from using it than I ever expected.

If you’re a developer of any kind then Grunt is something that you could probably benefit from using. The reason? This is the reason they give on their homepage:

In one word: automation.

On it’s own Grunt doesn’t do a lot – it runs tasks but you need to define those tasks for it to be useful.

Tasks are defined by plugins installed alongside Grunt. There’s already thousands of plugins created that do many of the things that you might need (4,403 of them at time of writing). Many of them are officially maintained by the team at Grunt, so you can guarantee a decent level of support or documentation will be available.

Grunt for WordPress Development

I mostly work on WordPress projects. PHP, JavaScript, HTML and CSS is what I deal with daily. Grunt has MANY tasks available for working with those. There’s 2 specific things that are extremely useful.


Linting is the process of parsing your code and making sure it complies with a set of predefined rules. It can parse for errors as well as coding standards and all of the major code types used in WordPress can be linted with readily available tools.

Being notified of errors in code as they are introduced can save many hours of debugging.

Combine + Minify

Making sure you have comments in your files so you know what’s happening at a given point is good practice. It’s also good practice to serve optimized files to users – in as few requests and bytes as possible.

Combining your styles and scripts reduces the amount of requests needed and eliminates any overheads associated with additional requests. Minfying them as well will make sure you’re sending only the data that you need.

Making sure your images are optimized or compressed as well can save a lot of unnecessary transfer. You can have Grunt handle that for you too.

Watching for Changes

Since automation is the name of the game you can make use of the Watch task. It watches for changes to your files and when it detects them goes ahead and runs certain tasks. As a starting point watching your styles and scripts for changes then recompiling them could save you hours of time to spend on doing more useful things in your project.