Recently, I undertook a fascinating task for a client. As the “Head of Curriculum” at the School of Applied Technology, my responsibilities include crafting the content for bootcamps. Our inaugural bootcamp, “Fullstack JavaScript Developer with React and Express,” required me to swiftly set up 33 developer computers to ensure students could start coding within hours.

Here’s a rundown of how I accomplished this feat and the insights gleaned along the way.

As an agile coach working in bigger companies you are sound exposed to JIRA. JIRA - a tool that started out as a good idea and then grew into … a not as good idea.

But hey - we got to live with it, I suppose.

</rant>

In this post I wanted to show you how to easily import data from a JIRA query to Google Sheets (or Excel I presume). That is, in all honesty, not that complicated so I will share a few other tips around this whole process.

In short:

Tweaking export of JIRA data for fun and profit

At my current job, we heavily rely on Google Apps (Docs, Slides, Sheets, etc.). I’ve grown quite fond of them, especially the seamless integration between different apps. One of my favorite features is the ability to create a chart in Google Sheets and easily copy it to Google Slides for presentations.

Today, I want to share a small hack I’ve implemented to keep those slides updated automatically. This is particularly useful for dashboards or presentations displayed in a kiosk-like setup.

Copying the Chart

When copying a chart from Google Sheets to Google Slides, there are two options: as a picture or as a link. For our purpose, we want to use the link option:

1. Open the spreadsheet containing the chart you want to copy.
2. Click on the chart and then click the three dots (…) in the top-right corner.
3. Select “Copy chart.”
4. Open the document or presentation where...

I’ve been playing around with refactoring a Koa application to use modern JavaScript constructs like async, await => and do away with generators etc.

In doing so I had an epic battle with mocha, monk and supertest to use async / await etc. I finally found a good structure for this purpose that I wanted to share.

This is the fifth and last post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application - this post

This is the fourth post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application - this post
• Part V - wrapping up by refactoring the root application

This is the third post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing - this post
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application

This is the second post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit - this post
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application

I have learned so much by following the Koa Js community and framework over the years. My first post on the topic was written in March 2014, when Koa was just a little tiny bird trying out its wings (look up that reference…).

From that point I’ve written many posts, done a few screen casts for fun and other for profit.

4 years (MY GOD!) is a long period but in the JavaScript world it’s eons of time. I noticed that the other day when I refactored one of my later Koa applications into something more modern. I learned so much about the topics that I ran into, while upgrading my code and the resulting code was much more elegant, functional and understandable.

So… I thought I’d do it again. This time you can tag along. This post will be long, but hopefully worth it.

I have a very particular set of memories from my childhood, that revolves around me falling, hitting or otherwise hurting myself. If it was just a bruise my father often said to me:

How bad is it? Is it worth crying for, like you do now?

(I was probably exaggerating quite a lot). Of course, it was!

Tell me, what are you going to do if it really hurts, then?

That was maybe not pedagogically correct for a child in pain but it at least got me thinking. Indeed… what comes after screaming and crying? Could I turn this up? Would it make a difference? Would I get … yes, what was it I wanted, really? Maybe just a hug or comfort. Could I get that by other means of communication that the display I was putting on now?

Of course, 7-year old Marcus didn’t reflect...