From time to time, people will ask me questions about my work in software development. Typically, I find myself unprepared to answer these questions. It's not that my work is particularly challenging; it's simply that I've never dedicated time to carefully think about how I would describe my work. Thus, I typically focus on the output or product of my work, rather than the process of what it is that I do to get to those results.
Fortunately, I worked on a small side project in the last two days, and I think this is a very good example of what it is that I do at work. My intention is to give a clear picture of the process I go through, highlighting the key parts. This may inspire some people. Hopefully, it won't confuse people.
Everything starts with a problem. The goal is to solve the problem. In my case, for at least a few months now, if not years, I've been considering how I would add graphs and charts to my website.
- Getting the data is a challenge. There's a few options, but they are all imperfect.
- In order to not have the blog post depend on the database, the data could be hardcoded into the blog post. However, if the data were ever updated in the database, it would not be updated in the blog post. In addition, this may not work well if the dataset is enormous.
After doing some research, I discovered that some charting libraries, such as Google Charts, supported exporting to PNG format. In addition, Google Charts renders charts in SVG format, which is itself easily embedded. Thus, there were two potential solutions to the roadblocks I identified earlier.
The plan became clear: make a tool to convert a Google Chart into PNG or SVG, and make it easy to copy and paste.
The next step is to make the tool. Because Google Charts supports many various forms of charts and graphs, I initially wanted to just let the user specify a URL. The tool would then navigate to the URL, render the page, take a screenshot, save the image, and send it to the user. Unfortunately, this approach came with several risks:
- The URL would need to be publicly accessible by the tool. Since images were being saved on the server, it could be retaining sensitive or confidential information.
- The webpage generating the chart would need to be structured in a specific format to work with the tool.
Next comes the step of implementing the plan. This is when I just did heads-down coding, referencing the Google Charts API. This part actually only took about a few hours, or half a day.
After writing the code comes the step of testing the code, and fixing bugs and issues, making sure it was usable and even pleasant to use. This step actually consumes more time and effort than just coding, because this is when some edge cases come to the light, and some weird behavior need to be debugged. For me, I had to figure out why Material Design Lite (MDL) was clashing with Nuxt.
Finally, having tested the tool to satisfaction, it comes time to releasing it and telling people about it, which is what this post is all about. And, this is what I do at work.
You can explore the tool here.
This is an example of the output:
July 14, 2018