Corgi Pomodoro — A Lame Excuse to Learn Basic JavaScript

The webpage is live and viewable in Google Chrome

Corgi Pomodoro is a newly-released, state-of-the-art web application that takes advantage of a revolutionary software paradigm known as Dogs as a Service (or DaaS, for short). Though only recently released to the public, Corgi Pomodoro has already received support from numerous Silicon Valley investors. It currently has a valuation of approximately $30 million, and I hope to use it to achieve my lifelong dream of getting a corgi onto the cover of Forbes.

Okay, in all seriousness:

The Actual Introduction

I make my living as a software engineer, but I am very different from a web developer — what I have done in the field for at least the past year is mostly middleware implemented in C++. If software engineers can be compared to contractors who build metaphorical houses, then web developers are the ones who care a lot about how the house looks, how the rooms are laid out, and whether or not everything is aesthetically pleasing (some may consider this a stretch, since web development is fairly broad and involves different parts of the stack, but bear with me). In the world of C++ middleware, all we really care about is that data flows efficiently and with integrity. If we go back to the house metaphor, middleware programmers are like the ones who build the wiring and make sure the water goes where it’s supposed to go.

Pipes are fine. Pipes are necessary. Pipes are surprisingly complex, and even as we speak there are a million frameworks for making pipes, libraries to help people make pipes, and white papers about how a very specific set of pipes will solve all of the world’s problems. You can probably dedicate your entire life to pipes, but I think we all get at least a little bored of it from time to time.

It wouldn’t be completely accurate to say that I’ve never done anything with web development, but it would be fair to say that I’ve barely done anything with JavaScript. I’ve talked about it a lot. I’ve wanted to use it for a project for some time. Corgi Pomodoro is no big project, but I do like that it takes advantage of a humorous but somehow useful API.

That really is the purpose of this project, in a nutshell. That and the blog post I am writing right now

A Pomodoro is a pretty effective time-management technique that’s designed to facilitate flow and prevent procrastination: It involves 25 minutes of undistracted work, followed by a 5-minute rest. CorgiPomodoro is like a regular pomodoro, only it uses something called the Dog API to display a random image of a corgi every time a session ends. Like most pomodoro implementations, it has a pause and reset button (I almost wish my preference was for pomeranians, so that I could have named this PomPomodoro, but oh well).

As a bonus feature, the timer sound has been replaced by a woofing sound!

So really quickly…a few things to note about web development. Some of these are things I knew already, and some are things I learned in this little project:

  • Github now features free web hosting. Any github repository can be hosted for free with GitHub pages. This is how I now host my CSIF writing website, as I am no longer a student at UC Davis and my CSIF access has been revoked
  • If you’re not super interested in web development and just want to throw up a website quickly, GitHub Pages probably isn’t the way to go. But if you actually want to go through the process of creating HTML, CSS, and other web files while quickly seeing the results go live, this is perfect. You can also use web frameworks, but I don’t think you can use all of them
  • CodePen has public pens, which are MIT licensed and considered fair use for other developers. This is a great feature, considering that many Codepens consist of a simple html, css, and js file instead of the complex things you find online that usually leverage a web framework.
  • Still, let me give credit where credit is due: This project was largely the result of combining the Fetch API Example, a codepen that demonstrates basic Dog API usage, and Vanilla Pomodoro, a pomodoro implemented in vanilla JavaScript. There was some integrating, a little new logic, the obvious and important step of separating out the corgis from the non-corgis…but it definitely would not have been finished without these codepen links

A Little Detour: How APIs Work (explained by OTHER people)

This is the best explanation of APIs I ever found online, but I think of an API more as a series of functions that you use to make calls and control something.

The Dog API employs fetch commands, and even though fetch is a common software term I just can’t seem to get over the sheer cuteness of that.

To add even more cuteness, the person who wrote PoC code for the doge api made a function called getRandomDoggo().

What I wrote was getRandomCorgi(), which was like one line apart. See the one difference? I’ll give you a hint: The only difference is corgi.

This is a function in MY JavaScript file, yet it uses the fetch command to get pembroke welsh corgis via the Dog API.
To really drive how APIs work home, this is Jarvis Johnson using the Twitter API to order a pizza via code

A Little Detour: How Websites Work

I’ve only scratched the surface of this, and I have to be a little careful how I word things because Medium is so full of software engineers who really understand how websites work, but there are a few really interesting things going on.

  • Like they point out in Programming Throwdown, web development is nice because of how quickly you can share your work with others. I don’t have to call my mom, tell her to go to the Google App store, then realize she has an iPhone
  • The fact that you can view source is kind of amazing. Sometimes you can bypass certain blocks on websites simply by viewing source and deleting nodes; sometimes you can simply download an html and then view it in your web browser, to avoid other annoying aspects of viewing a website
  • What browser you use matters a lot. This only works in Firefox or FireCorgi for some reason
  • You’re going to hear a lot about things like the DOM, which I still have only a vague concept of…
This JavaScript code takes advantage of the DOM and actually maps to id attributes in the corresponding index.html file
This JavaScript code takes advantage of something called Font Awesome. You can use it to make customized fonts and customized buttons

The HTML, CSS, and .js files are all linked up. There’s no web framework — it’s what I think you would describe as vanilla javascript.

There are some other things I found along the way, some of them frustrating. Normally when I go through the process of writing code, I ty to compile it and then I try to run it — if anything goes wrong during compilation, I’ll have my compiler tell me where the error likely occurred. Here it’s not so simple. You can view the web console, which is extremely helpful, yet things will still be partially functioning in a sort of weird “fail silently” state. You can have a button that’s totally broken because it uses variables that don’t exist, yet the button will display.

I’m sure there’s a good reason this is like it is, I just don’t know why yet.

Other Obstacles

Interesting that it was such a small project, yet I still had problems along the way. I don’t take advantage of all the files present. The buttons don’t look as nice as the ones on codepen; in fact, I had to use different and noticeably lamer ones. I don’t know how to make the image scale — at least not when the image is retrieved from an API like this. The woof sound doesn’t work in Google Chrome. I haven’t bothered to look in mobile, but it probably looks horrendous on a mobile device. All of these areas for improvement, yet now I kind of want to move onto the next thing.

It would be nice to get into a web framework, at some point in the future, and something other than Bootstrap.

On the plus side, the commit messages were surprisingly fun to write

One of my favorite parts of a project is actually writing the markdown. A million years ago I used to want to be a technical writer; I guess I’ll take what I can get.

The github link:

Closing Thoughts

It’s probably neither the time nor the place to write some long-winded, pseudo-intellectual conclusion about the nature of work in this day and age. Long story short, I think that a lot of people are dissatisfied with their current lines of work when they feel a disconnect between what they do and the people it impacts.

Workers used to physically make things. It was very obvious what you were doing and what the impact was. Now, with the exception of doctors and a few obvious sectors like teaching, effects seem less tangible. Sometimes we write software that gets blown away, or hidden away somewhere, or instead of getting to write something new we just sort of put duct tape on existing legacy software. It gets pretty frustrating, not just because it seems to reduce our positive impact as software engineers but because we learn a lot less than we would have otherwise.

But it’s just how a corporation works. Sometimes projects get defunded. Sometimes new technology replaces old technology so rapidly that the things we wrote a year ago are already considered deprecated.

The solution the problem, I think I’ve found, is doing personal projects. I’ve known this and said this for a while, but I didn’t really practice what I preached.

So lately, in what I hope will be a long series of projects, I’m trying to do personal projects.