Forem: Brian Greig

Thanks for the Memoize

Brian Greig — Sat, 14 Dec 2024 19:29:16 +0000

Those of you who know me know I have an absolute crap memory. Anything short of Monty Python dialog and track listing from a 90s alt rock band and I am dead to rights. Fortunately for us, however, computers are far more competent when it comes to remember things.

The Concept

The technique we are looking at today is called memoization. Let's start by discussing pure functions. The idea behind a pure function is that, no matter what input you give it, it is always going to give the same output. Now consider if you have a process intensive function or one that requires a lot of overhead. If you already know the result of running the function when provided a certain set of parameters why utilize your resources to run it again. Memoization allows us to store the result of a previous execution of a function using the parameters to that function as the key. The following code snippet demonstrates what a memoized function might look like:

The Execution

const memoize = {};

const getResult = async (n1, n2) => {
  const key = `${n1}_${n2}`;
  if (!memoize[key]) {
    memoize[key] = await resourceIntensiveFunction(n1, n2);
  }
  return memoize[key];
};

Let's take a look at the code. We start with an object called memoize that will store our parameters and the results as a key value set. Next we have our function called getResult that takes two parameters: n1 and n2. For simplicity's sake of this let's assume that the order matters. We are going to create a variable key using the concatenation of the two parameters.

Now we need to check to see if the memoize object contains a value for that key. We check and, if it doesn't, we have no choice but to run the resource intensive function. If we run the function we must also store the results in the memoization object for future execution. This way the next time run this function for these same parameters it'll find the result in the object and skip the resource intensive function.

Memoize when query has been previously run

Memoize when query has not been previously run

The Benefits

This can be useful in a number of scenarios. If, for instance, you have a long series of calculations that take an extensive amount of time and resource this good be a worthwhile optimization. It can also be valuable if you have something that requires high network throughput or a lot of temporary disk space. For any of these scenarios the advantage is two fold: It eliminates the need to run functions that have been previously executed and it frees up resources for those that need to be calculated because they aren't competing for resources with those functions that are already mapped.

The Challenges

There are situations where this might not be the right approach so don't always use this paradigm. If your function is not a pure function and it changes based on external factors then you don't want to use this approach as it'll always give you the values from the first run not taking into consideration those other variables. You also don't want to use this if the application will rarely run the function with the same set of parameters. In that case you'll have an increasingly large data structure that rarely gets used.

That's pretty much it for memoization. It's a pretty simple pattern with a very intimidating sounding name. There are a lot of applications for it and, hopefully, this gives you a better idea of what is happening under the hood. Now, if you'll excuse me, I have to go remember what it was I was going to do this evening.

Source code available on GitHub

The Joy of Singleton

Brian Greig — Tue, 06 Feb 2024 05:22:30 +0000

There are a lot of people who will tell you that a Singleton is an anti-pattern. Be that as it may, they are something you are going to come across at some point in your development travels and it is good to know about them.

A Singleton is pretty much what it sounds like. It is a single function/object that can't be replicated. Any time you instantiate another instance, instead of creating a copy, it returns the single instance of the object. This is somewhat of a controversial design pattern because anything can make changes to the object which results in similar problems to those you encounter with global scope: lack of encapsulation, mutable values, and side effects.

You may find, however, that the pros outweigh the cons. Let's imagine for a moment that we are creating the earth (eep). Our planet is going to have all the necessities of a world: sea, earth, and, of course, critters.

function World() {
    this.earth = []
    this.water = []
    this.creatures =[]
}

Now let's instantiate our world and add a critter:

const myWorld = new World()
myWorld.creatures.push("Kangaroo")

Wonderful. Our world is soon going to be brimming with life. Unfortunately, we run into a problem if elsewhere in our program, you instantiate the world again.

const yourWorld = new World()
console.log(yourWorld)

This is going to return a planet completely barren of critters, including the kangaroo we added earlier. This is not surprising given we instantiated a new world, but this is not what we want for our Singleton. Instantiating a new world should give us a reference to that same function we created earlier. So, let's implement our function as a Singleton.

const World = function () {
  if (World._instance) {
    return World._instance
  }
  World._instance = this
  this.earth = []
  this.water = []
  this.creatures = []
}

Now when we instantiate a World it is going to check if an instance of the world already exists. If it does, it'll return it, otherwise it will create one. Now, if we create myWorld and yourWorld, adding a critter to one will be reflected in the other:

const myWorld = new World()
const yourWorld = new World()

myWorld.creatures.push("Kangaroo")
console.log(myWorld)
// World { earth: [], water: [], creatures: [ 'Kangaroo' ] }
console.log(yourWorld)
// World { earth: [], water: [], creatures: [ 'Kangaroo' ] }

You have yourself a Singleton. You may not realize it but you are probably already using them. If you are using ESM import/export modules those are Singletons. Hopefully, this gives you a better understanding of how they work under the hood, and feel more comfortable using Singletons when the need arises.

When and How to Use the Facade Pattern

Brian Greig — Fri, 02 Feb 2024 04:19:37 +0000

In conversational English, the term facade has a bad rep. We say, that when someone is fake or untrustworthy, they have a facade. I think this has done very little for the humble facade pattern. Without even knowing what it is you are already judging it.

Let's do this pattern justice and look at when we should use it. We have all worked with legacy code. Let's say, for instance, you have this piece of code that tunes a guitar:

function Guitar(highE, B, G, D, A, lowE) {
  return {
    play: function(){
      console.log("🎶")
    }
  }
}

Nifty, right? We new up Guitar, which gives us back a perfectly tuned guitar that we can play(). Notice, though, that we need to pass it six variables, each corresponding with the pitches for each of the strings. No problem, we're rock stars, we know exactly how to tune a guitar.

But now the rest of the band comes along and, guess what, they have their instruments that they need tuned up and ready to go.


function Bass(G, D, A, E) {
  return {
    play: function(){
      console.log("🎶")
    }
  }
}

function Trumpet(tuningSlide) {
  return {
    play: function(){
      console.log("🎶")
    }
  }
}

function Piano(toolboxFullOfStuff) {
  return {
    play: function(){
      console.log("🎶")
    }
  }
}

You can probably handle the bass guitar but what the heck is a tuning slide and what is the pianist handing you an entire toolbox for? So, now you need to do something. You've got to hand this over to your roadies to get you finely tuned instruments and there is no way you can teach them the intricacies of each of these instruments.

In comes the facade pattern. We can create one interface and, through that one interface, we can new up any one of these instruments. Then, within the context of the pattern, we can handle all the nitty-gritty details of each of the instrument tuning requirements:

function Instrument(instrument) {
  const instruments = {
    piano: Piano,
    guitar: Guitar,
    bass: Bass,
    trumpet: Trumpet
  }
  return new instruments[instrument]()
}

Now, if we want to new up a guitar, it's as easy as

const guitar = new Instrument("guitar")
guitar.play()

So, here we had a situation where we had multiple objects that all had different interfaces and all had very specific configurations. We used the facade pattern to create one, uniform implementation that allowed us to create any of the objects with very little knowledge of how each one was implemented. This is where the facade pattern should be a key component of your technical repertoire.

Working with Function Parameters in JavaScript

Brian Greig — Sat, 27 Jan 2024 06:01:51 +0000

A function signature describes what is necessary when you call a function. For instance, if we have a function whose signature is makeDinner(meat, carb, vegetable). This includes all the information you need to execute the function.

Let's say we wanted to create a bird-watching app (growing up my brother, and by extension, I, were avid bird-watchers). We might want to create a bird object in our app which we can initialize a bird with a few pieces of information. Let's start with name, wingspan, and mass:

const Bird = ( name, wingspan, mass ) => {
  return {
    fly: () => wingspan < 8 ? "flap, flap" : "FLAP, FLAP",
    stats: () => `${name}\nwingspan: ${wingspan} ft\nmass: ${mass}`
  }
}

const bird = Bird('California Condor', 9.5, 20)

This is good if we have all the necessary pieces of information at the time of initiation. What if we don't though? How do we make sure we can create an object with just the information we have? If, for instance, we don't have the mass we can simply leave it blank and let JavaScript do with it what it will.

const bird = Bird('California Condor', 9.5)

When we call bird.stats() we'll get:

California Condor
wingspan: 9.5 ft
mass: undefined

Not ideal, but it works. We could add default values to our parameter list to avoid the undefined:

const Bird = ( name, wingspan = 10, mass = 10)

so that if we don't provide a value it selects a reasonable value. OK, maybe not the best as we wouldn't want to end up creating a bluebird that weighs 10 lbs and has a 10 ft wingspan, but let's just roll with it.

The bigger issue comes in if we have to add a new parameter to the function signature. Say, for instance, we now want to track a bird's conservation status. The new signature is:

const Bird = ( 
  name, 
  wingspan = 10, 
  mass = 10, 
  conservationStatus = 'least concern'
)

We added it as the last parameter in our function which is good because it doesn't break any of our existing functions. If we don't update any of our functions they'll just use the default values. But what if we want to update the call that we issued earlier where we used the default value for mass:

const bird = Bird('California Condor', 9.5)

we can't simply tack the new value on the end. We would have to add both the mass and the conservation status:

const bird = Bird(
  'California Condor', 
  9.5, 
  10, 
  'Critically Endangered'
)

This means to start leveraging this new parameter we may affect other, already functioning parts of our application. That is why I prefer passing objects as parameters:

const Bird = ({
  name,
  wingspan = 10,
  mass = 10,
  conservationStatus = 'least concern' }) => {
  return {
    fly: () => wingspan < 8 ? "flap, flap" : "FLAP, FLAP",
    stats: () => `${name}\nwingspan: ${wingspan} ft\nmass: ${mass}`
  }
}
const bird = Bird({
  name: 'California Condor',
  wingspan: 9.5,
  conservationStatus: 'Critically Endangered'
})

Why is this better? Well, now it doesn't matter if you did or did not specify one of the parameters previously. Adding the new value is just adding a new attribute to the object you are passing to the function. It doesn't matter the order they get passed, or what position the missing field is in. It also makes the function call much more explicit. We now know exactly which values correspond with which attributes without having to count parameters and constantly look back at the function definition.

Object parameters are a great way to create functions that are easily extensible and less rigid. Put yourself in the shoes of the person who is going to be maintaining that code six months or a year from now (especially because that may be you) and create something maintainable and intuitive.

Teach Me How To PubSub

Brian Greig — Thu, 25 Jan 2024 06:23:29 +0000

I'm not going to lie before I even knew what a publisher-subscriber pattern was I just liked saying the word: PubSub. Try it, it's fun.

With that out of the way let me talk for a minute about what a PubSub is. Often in software development, we need to allow communication between two systems without those two systems knowing anything about the other. This may be because the two systems are managed by two different teams but still need to be interoperable. It could also be because we may have an arbitrary number of systems that are listening for particular events. This is important for the separation of concerns, scalability, and maintenance.

A Publisher-Subscriber model is going to do exactly what it sounds like. It is going to allow us to publish, or announce, events and then allow other services to subscribe, or listen, for those events. If you have done much work with JavaScript on the front end you have seen this with eventListeners.

Let's say, for our thoroughly contrived example, we want to create a system where users can shout or whisper a message. We then want to allow other services to listen for all messages that were shouted and/or those that were whispered. We'll start by creating a Publisher, a Subscriber, and a Message Broker:

const EventEmitter = require("events");
const MessageBroker = {
  eventEmitter: new EventEmitter(),
  eventQueue: {},
  add: function(e) {
    this.eventQueue[e.event] = this.eventQueue[e.event] || [] 
    this.eventQueue[e.event] = [...this.eventQueue[e.event], e.data]
    this.eventEmitter.emit(e.event, e.data)
  }
};

function Subscriber() {
  return {
    subscribe: (e, cb) => {
      MessageBroker.eventEmitter.on(e, data => cb(data));
      return true;
    }
  }
}

function Publisher() {
  return {
    publish: (e) => {
      MessageBroker.add(e)
    },
  };
}

Here we are using the Node EventEmitter to handle the events. The MessageBroker creates our event emitter so that when the publisher adds an event it'll do two things: 1. it will add that to an event queue (which we'll talk about shortly) and 2. it will trigger the event emitter to "emit", or announce, your message. The subscriber then simply has to provide a subscribe method for us to listen for all events of a particular type. The implementation of this for our whisper/shout example would be:

const pub = Publisher();
const sub = Subscriber();
const fn = d => {
  console.log(d)
}
sub.subscribe('whisper', fn)
sub.subscribe('shout', fn)
pub.publish({
  event: "whisper",
  data: "be very, very quiet",
});

pub.publish({
  event: "shout",
  data: "let it all out",
});

In the above code we create our publisher and subscriber. We don't need to create our message broker because it is a singleton and it is accessible to both our functions. We then create two subscribers: one that subscribes to our whisper messages and one that subscribes to our shouts. The second parameter just takes a callback function to relay the message. Finally, we start publishing messages. Whenever we publish an event of type whisper our whisper subscriber with relay it back and, unsurprisingly, our shout subscriber will do the same.

Now I said I would get back to our message queue. Let's add one more function to our message broker object:

const MessageBroker = {
// --- snippet ---
  playback: function(e) {
    this.eventQueue[e].forEach( event => {
      this.eventEmitter.emit(e, event)
    })
  }
};
// --- snippet ---
MessageBroker.playback("shout")

This is one of the most powerful things about a PubSub. The ability to play back an entire series of events. We create a playback function that takes an event type and then goes through the queue of all our events re-triggering them. Now all of our subscribers who are listening for those events will execute all of those events again. This technique is great for recovering systems, keeping multiple systems in sync, onboarding a new service to include history and a plethora of other advantages.

Play around with the code above. Add more publishers, and more subscribers, and see what kind of results you get. This is a very rudimentary example of what you can do but a more sophisticated implementation will allow you to playback for a timeframe or for multiple event types. There is a ton you can do with this model and, even though there are plenty of rich implementations that you can use in your applications, it's great to have that understanding of how it all works under the hood.

All You Need is ... Higher Order Functions

Brian Greig — Tue, 23 Jan 2024 05:28:00 +0000

I believe John Lennon and Paul McCartney wrote the song "All You Need is Higher Order Functions". Or maybe not, who knows, but as a JavaScript developer, or any developer working in a functional programming language, you will benefit greatly from these two wise men's advice. Higher-order functions are great.

So, why higher-order functions? Well, one of the things that JavaScript thrives on is working with functions. You've probably heard that JavaScript treats functions as first-class citizens. That means JavaScript allows us to treat functions like any other object. You do all kinds of cool stuff like pass functions to other functions and store them in objects and arrays. Why, pray tell, would you want to do these kinds of things? Well lets look at a program that I have written to test is a thing is a thing:

const validateThing = async thing => {
  switch (thing) {

    case "car":
      return {
        valid: true,
        thing: "An expensive thing"
      }
    case "toaster":
      return {
        valid: true,
        thing: "Mysteriously makes bread disappear and toast appear"
      }
    case "soy sauce":
      return {
        valid: true,
        thing: "Delicious on rice, but a bit salty"
      }
  }
  return { valid: false, thing: "not a thing" }
}

By calling validateThing('car') we receive a very helpful little piece of information (a lesson my son is currently learning at this moment) that cars are expensive. We get a similar bit of information if we check toasters or soy sauce. Now, I have been around for a while and I can tell you there are more things on this planet than cars, toasters, and soy sauce. As we add in more things our case statement starts to grow rapidly. Not only that but writing unit tests for this beast would be crazy.

So let's do our first refactor. We are going to take what is, essentially, a procedural program above and make it into a functional program. We'll break the different validations into functions that can be called individually.

const validations = {
  car: async thing => 
  thing == "car" ? { 
    valid: true, 
    thing: "An expensive thing" 
  } : null,
// --- snippet ---
}
const validateThing = async thing => {
  const invalidThing = { valid: false, thing: "not a thing" }
  for (const validation in validations) {
    const res = await validations[validation](thing)
    if (res) return res
  }
  return invalidThing
}

For brevity, I removed some of the other things and just left the cars. So how does this change things? For one, if we want to add validations we just add them to our program and call them in validateThing. Each of these functions can be individually tested using unit tests and there is less chance that functions are going to interfere with other functions. But there are some disadvantages.

For every new function we add we have to update validateThing
What if we have different sets of "things"? Now we need to manage multiple validateThing functions

For our last refactor let's use higher-order functions. We'll add all of our validate functions to an object and pass that to our validate function. We'll call this object tangibleThings. We'll also create another object called intangibleThings which can each be passed individually.

const tangibleValidations = {
  car: async thing =>
    thing == "car" ? {
      valid: true,
      thing: "An expensive thing"
    } : null,
// --- snippet --
}
const intangibleValidations = {
  love: async thing =>
    thing == "love" ?
      {
        valid: true,
        thing: "Something The Beatles sang a lot about."
      } : null,
  }
}

Now we can pass two parameters to validateThing: our thing, and a list of validation functions to check it against. For instance: validateThing('love', intangibleValidations) to find out what gives us butterflies in our stomach. We have now completely decoupled any of the implementations for validations from our validateThing function, made it extensible so that we can pass specific validation functions, and made it easily testable as we can test all of the individual validation functions independently.

Using higher-order functions in your applications is great, but it is not always the answer. There is some overhead and sometimes the juice isn't worth the squeeze. But when you are working with complex systems that have many moving parts it can make your life, and the lives of your teammates, exponentially better.

Taming Data in JavaScript (x-post to ALA)

Brian Greig — Sat, 22 Dec 2018 00:37:16 +0000

A List Apart was gracious enough to publish my article on Taming Data with JavaScript. Anyone interested in working with data in JavaScript might enjoy this piece. http://alistapart.com/article/taming-data-with-javascript

Getting an Open Source Projects Off the Ground

Brian Greig — Fri, 02 Nov 2018 02:40:50 +0000

Some of you may remember when I published an article a month or so back on Binding charts to data in Vue. Since then I have found myself engaged in trying to build out a full featured library of D3 charts for Vue.js. This has been a great learning experience and by embracing Hacktoberfest I was able to get some contributors to pick up a few features here and there. Nearly two months in I feel like it is coming together nicely but I don't feel like it is reaching an audience. Now it could be that this is too niche or because there are other, more mature libraries that provide similar functionality. I like to think, however, that there is a slice of the development community that would be interested in building out a robust, standards-based, customizable charting library for Vue.

What are some of the things that you have done to get your open source project in front of developers? Is it just about getting stars (which I would greatly appreciate wink wink) so that it hits Github's trending page? Or is there something else to it? I would love to hear some of your personal experiences and how to build that audience.

Thanks and keep coding.

Project Management Lifecycles for Personal Projects

Brian Greig — Mon, 08 Oct 2018 14:58:03 +0000

I have started a few OpenSource projects in my web development career. In that time I have had varied level of success with features, maintenance, and defect management. Having always felt that creating a proper project was overkill meant that none of them followed a conformed standard. On my current project v-chart-plugin I experimented with following an Agile management methodology. As I walk through the workflow below I am curious what levels of success others have had. Please share in the comments below.

Overview of the project

Just to give you a sense of the size / scale of the project: This is a customizable Vue component plugin for adding charts and graphs bound to Vue's reactive data. The plan is to have about a dozen or so charts with multivariate support, goal tracking, customizable widgets (labels, titles, etc) and additional customization via CSS and the API.

I began the project about a month ago and I am currently in the 0.1 pre-alpha stage with 0.2 alpha planned for November 2018. Currently I am the sole contributor but I have been actively looking for others. Long term the expectation is a stable plugin would allow for contributors to integrate their own graphs using the API. Those graphs could be included in future releases extending the library of total charts available.

The project

Starting the project I decided to follow some basic Git best practices. This meant no pushing directly to Master, all features would have their own unique branches, and all new code would be merged via PRs in Github. To organize these I created an issue in GitHub for each bug, feature, enhancement, etc and labeled them accordingly. I also created some backlog / tech debt items (such as general optimization, error handling, documentation) for those type of tasks. Those are labeled accordingly as well.

Any time I began work on a new feature I would create a branch in Git with the name issue-{x}-{short-description}. From here I end up with a series for branches that look like this:

I can then work on each of those branches individually occasionally merging the changes back in from Master when other features are completed. They can then be pushed back up to origin when the feature is complete and merged into Master via a PR in Github

To manage the project I have broken it up into Sprint Milestones with larger projects that consist of three two-week sprints each.

Finally I assign issues to each of my sprints.

This allows me to set deadlines for each of the features and keeps me on task to deliver features and close issues. So far it has been working well allowing me to focus on a single feature or bug without being overwhelmed with all of the open items. It has also allowed me to push out changes fairly regularly. My concern is, as the project gets bigger and potentially more people start working on it, is this going to scale. Will it also deter people from contributing because of the added process around changes or is this type of workflow a welcome addition.

Binding Data to Charts using Vue Components and D3

Brian Greig — Thu, 30 Aug 2018 03:40:57 +0000

There is nothing more satisfying than making a change and seeing that change propagated through somewhere immediately. Lately, I have been experimenting a lot with integrating D3 charts into Vue. I tried doing this with helpers, directives and, most recently, with components. Since Vue is declaring components to be their recommended implementation method for reusable components I am going to be focusing here on that version.

If you are unfamiliar with Vue it is a popular JavaScript framework for two-way data binding. D3 is a library for modeling data in the DOM. What we are going to be focusing on is building a reusable component in Vue that leverages the D3 library to create a chart stays in sync with the data in Vue.

We are going to start with the vue-cli which will allow us to create a template for our new app. Once we have our starter app we are going to create a JavaScript file within our src directory called v-chart-plugin.js. This will need to be imported and used in our main.js

import Chart from './v-chart-plugin.js'

Vue.use(Chart);

The idea here is that all of the functionality for rendering the chart and binding the data will be handled within the component completely seperate from the Vue instance. This way when the component is added all the developer needs to do is add in the element with the proper data bindings.

<v-chart v-bind:chartData="chartData"></v-chart>

As long as the object (in this case chartData) being passed follows the appropriate structure with the required values there is nothing further required of the dev. The component itself will be structured as so:

Import dependent libraries (D3)
Define the component
Export the component
Use the component (if vue is defined at the global scope)

The framework would look something like this

// Limited to just those dependencies we are going to need for the example
var d3 = Object.assign({}, 
    require("d3-selection"));

const Chart = {
...
}

export default Chart;

if (typeof window !== 'undefined' && window.Vue) {
    window.Vue.use(MyPlugin)
}

The bulk of the plugin is going to be in the definition of the Chart object itself. If you are familiar with Vue then you should recognize a lot of these methods and properties. If you are familiar with other frameworks like React and Angular some of the terminology should be familiar as well. Let's examine the structure of the component before we get into the details

const Chart = {
    install(Vue, options) {
        Vue.component('v-chart', {
            props: ['chartData'], 
            data: function () {
                ...
            },
            methods: {
                ...
            },
            // lifecycle events
            mounted: function () { 
                ...
            },
            // watch functions
            watch: {
                ...

            },
            template:
                ...
        })
    }
}

You should recognize the value v-chart. This is the value that was used in our Vue template to add the component to the application. Below that we are referencing the props. This correlates to the object that we bound via the v-bind directive. You can pass multiple parameters instead of an object but I'll be using an object as it is easier for configuration. Following the props are the familiar data and methods which are values and functions that are scoped to the component. We won't be using data in this example as all the data is coming from the props but we will be using methods extensively. Note that for components data needs to be a function.

Vue.component('v-chart', {
    props: ['chartData'], 
    data: function () {
        return {
        }
    },
    methods: {
        initalizeChart: function () {
            this.drawChart();
        },
        refreshChart: function () {
            this.clearCanvas();
            this.drawChart();
        },
        drawChart: function () {
            ...
        },
        clearCanvas: function () {
            d3.select(this.chartData.selector).selectAll("*").remove();
        },
        getHeight: function () {
            return this.chartData.height || 200;
        },
        getWidth: function () {
            return this.chartData.width || 200;
        }
    },

Outside of our methods we have a few additional functions that serve some specific purposes. Firstly are the lifecyle hooks. These are functions that get called at specific intervals within the application. This allows us to associate functionality with these events such as when an instance is created, updated, destroyed, etc. We'll be using the mounted hook to ensure the page is loaded when we render our chart.

mounted: function () { // <-- lifecycle events
    this.initalizeChart();
},

The other special methods we will be adding are watch functions. Watch functions serve the unique purpose of executing when the data is updated. This will allow us to re-render the chart when the data changes. Doing so will ensure that the chart is always in sync with the data.

watch: { // <-- watch functions
    'chartData': {
        handler: function (val) {
            this.refreshChart();
        },
        deep: true
    }
},

Lastly, we have the template. This is a standard Vue template for the content we intend on rendering on the page. In this example, it is simply an SVG as that is what we will be using to draw our graph. We use interpolation to get the values of the width and height based on what was configured in the object.

template:
    `<svg class="chart" :height="this.getHeight()" :width="this.getWidth()"> </svg>`

If you have been following along you will notice I purposefully left out the details of the drawChart function. This is the part of the code that uses D3 to draw the chart on the SVG canvas we created in our template. This is going to rely heavily on the data we are passing in from the props: specifically the chartData.selector for identifying the unique id for the chart and chartData.data which is an array of data configured in the Vue instance. The rest is a boilerplate D3 that binds the data and appends rectangles with a length equal to each value in the array. This can be extended to create any data visualization.

drawChart: function () {
    d3.select(this.chartData.selector)
        .append("text")
        .attr("x", 20)
        .attr("y", 20)
        .style("text-anchor", "left")
        .text(this.chartData.title)

    d3.select(this.chartData.selector)
        .selectAll("g")
        .data(this.chartData.data)
        .enter().append("g")
        .append("rect")
        .attr("width", function (d) {
            return d;
        }).attr("height", 20)
        .attr("y", function (d, i) {
            return (i + 1.5) * 20 + i
        }).attr("x", 0);
},

If you want to see the full code go ahead and clone the Github Repo that this tutorial was based on. Hopefully, this gives you a foundation on how to bind your data from Vue with your components and model it in visualizations.

Tips and Tricks to Finding Issues to Contribute to on Github

Brian Greig — Sat, 18 Aug 2018 20:35:27 +0000

Want to start contributing to open source? Here is a quick primer on how to find issues to work on in GitHub.

Head over to Github Issues Page. By default this is going to show you your open issues. Look in the search bar and you'll see all the default qualifiers. Mine looks like this: is:open is:issue author:ignoreintuition archived:false
Create a set of filters to limit the result to projects you might be interested in working on. Search for issues that are unassigned, recently updated, and based on the language of your choice:is:open is:issue is:public no:assignee language:javascript archived:false updated:>=2018-06-01
Next we can limit it to certain tags or keywords. Tags are useful for things like finding issues that are good for beginners or where the author is actively seeking help:is:open is:issue is:public no:assignee language:javascript archived:false label:"help wanted" updated:>=2018-06-01
Lastely we want to sort our results. You can sort by the number of interactions or when it was authored:is:open is:issue is:public no:assignee language:javascript archived:false label:"help wanted" updated:>=2018-06-01 sort:interactions-desc

Documentation for all of the qualifiers can be found here. Hopefully, this will help you track down issues that you can work on and get you started with working on some cool new open source projects.

Games that teach you to program (without you realizing it)

Brian Greig — Tue, 24 Jul 2018 02:21:13 +0000

I've been replaying a game recently on Steam called Spacechem. I had never realized it before but this game does an excellent job of simulating programming. For example:

Creating small, modular components that can be used in conjunction to create more complex systems
Multiple processes run in parallel and need to be managed concurrently
Bugs in your dependent modules that were tested individually can break when incorporated into larger systems if not thoroughly tested

I could go on but you get the idea. The premise of the game has nothing to do with programming but, fundamentally, it is requires the same skills and techniques to be successful. It's amazing because when I started playing this game 6 or 7 years ago I never thought of it as, basically, a training module for building complex applications.

What are some of the games that you found invaluable in learning to program? I am not specifically talking about the obvious ones like CodeCombat, which are great games in their own right, where the primary objective is to teach programming. I am referring to those that are more subtle and teach you the techniques while not ultimately being a coding exercise disguised as a game.