Programming for Pennies

This post is geared toward the readers who are programmers or the readers who wish to become programmers.  I don't think there'll be anything particularly difficult to understand here, but if you're not interested in becoming a programmer then this advice is useless for you (it may be useless anyway).  You can always read on for my exciting prose, though.

Much of my (desired) life revolves around how I can simplify the world around me and spend as little money as possible without sacrificing the quality of life I want to have.  This is predominantly a security blanket for me.  The world is a chaotic place, and I tend to be a pessimist, so I always run through exercises that give me the illusion of control of my environment even if I don't achieve actual control.  One exercise I run consistently, if not to the point of obsession, is creating a Panic Budget.  In that scenario, I run through a (hopefully) hypothetical situation where I lose my current job and wind up taking another job at reduced pay.  I then determine the amount of money needed to live my life at the relative level of comfort I've come to take for granted and then determine if I can sacrifice some of those comforts without making myself miserable.

So, what's this got to do with programming? Well, obtaining resources for programming can run from extremely cheap to massively expensive.  As one example, Google has 74,000 employees and spends billions of dollars on infrastructure per year.  After running through my Panic Budget I've determined that I don't have a spare billion to spend yet, so I'll have to be more creative.

To start with, in order to be a programmer, I'll need a computer.  I don't really have a lot of heavy needs for my computer on a day to day basis.  I generally surf the net, watch some movies, occasionally write a blog post, and...write some code.  I also don't like lugging a bunch of hardware around for no particular reason.  So, this leads me to my first investment as a programmer on the cheap - a Chromebook.  I like Chromebooks - they boot fast, they have a lot of easy to plug in software because they're essentially glorified browsers, they're secure, and they're Linux based (though in almost all cases that's an implementation detail that only developers need to pay attention to).  However, because they are essentially nothing more than glorified browsers, they don't have a lot of the same tooling availability as more traditional systems like a Windows, Mac, or Linux laptop.  However, since we're living in the age of the internet, this isn't as big an obstacle as it first appears.

The rest of this post assumes that you have at least a tenuous grasp of programming tools.  If you're not a programmer but are a serious autodidact, fear not, the internet will come to your rescue here as well.  If you're willing to go all in and spend some serious time on a computer science education (but not some serious cash), this curriculum is free and comprehensive.  Get through it, and you'll be as prepped as any fresh-faced college grad.  Don't have the time to invest in a computer science education, but want to pick up on the tradecraft?  You can take your pick from several coding websites that will provide you with a good practical foundation.

Once you have your computer and your plan for learning programming in place, you'll need an IDE to code.  An IDE offers capabilities that make managing software projects much easier than they would be if simply left to the basic tools offered by an operating system.  However, due to the fact that IDEs require the installation of supporting software and compilers of the programs we're writing, a browser-based system like Chromebook isn't initially set up to handle an IDE.  Luckily, there are several options on the web that provide these capabilities.  They range in cost based on storage, compute capacity, and features available, but almost all of them have a basic tool for hobbyists or lone developers that are either free or extremely cheap.  I've chosen to use Codeanywhere because it's a remote virtual computer that allows me to install any necessary software for my projects, and I like the IDE capabilities they provide on top of that virtual computer.  I've upgraded from their free, basic plan - which is still pretty solid - to one that gives me a few more capabilities at $84/year.  As a side note, Amazon has its own version of an IDE which looks pretty slick named Cloud9.  It may wind up being even cheaper in operation than Codeanywhere (at least Codeanywhere's paid plan), but I've grown comfortable with Codeanywhere, so I won't likely switch unless I'm compelled.

Once we have a computer and an IDE, we now need a place to store our code.  Though GitHub is the defacto leader in this space, they don't allow for free private storage and their HR practices still seem to be a little bit suspect, so I avoid them when possible.  This leaves two alternatives - Bitbucket and Gitlab.  I use both because they both offer free private accounts.  Gitlab offers more features where Bitbucket offers more polish and a wider user base.  Depending on my project, one is likely to serve my needs better.

So, now we can write and store our code.  But, if we ever want to let the outside world view it, we need to deploy it somewhere.  I've narrowed myself down to a few providers here.  In cases where I want to deploy static sites (HTML, CSS, and javascript code only), Gitlab and Bitbucket provide options for easy and free hosting.

If I need to do something that requires a storage backend or something more programmatically complex, Google App Engine offers an amazing set of tools and generous free quotas for users as long they follow the framework's guidelines.

If I need more flexibility or need to experiment with something that the GAE framework restricts me from doing, then I use Digital Ocean.  It offers a lot of capabilities for minimal and straight-forward prices.

That'll get you up and running if you want to develop and don't want to spend a lot of money.  But that's just the start.  There are a lot of tools available to play around with for curious programmers (and their professional alter egos - software engineers).  As mentioned previously, the internet is definitely your friend in this case.  For example, if you want to experiment to continuous deployment, you can try several tools, including the one I use.  For image processing and storage, you can use a free one or one with free quotas and more capability.

If you're experimenting or are on a limited budget, don't be afraid to look around and try different software as a service solutions.  They give you broad exposure to the ecosystem on the internet and introduce to tools that pop up in most software engineering contexts, so they're valuable learning tools.  If you're trying to go-it-alone or almost alone, they also provide a lot of leverage for functionality that you would otherwise have to write yourself.

A Recipe for Writing a Recipe Website

So, about that first recipe website I keep bringing up...

My stint in CS grad school wound up coinciding with my greater exploration of Epicurious.  Since I was working part-time at Starbucks and I didn't have classes every day, I had ample time to cook more and search for new recipes.

As I was new to programming, and it was the early 2000s, I also thought it would be a great idea to put up my own simple web page (...and that code still exists on some random hard drive in my house).

Because I was taking a class on XML transformations at the time, I decided to store all of my recipes in XML and then run them through an XSLT transformer to spit out the HTML everyone sees on a web page.  For the uninitiated, XML was a data format that was expected to encode information in an easily interchangeable format that was also human readable.  Today it's rarely if ever used for newer projects as it turned out to be too verbose and restrictive in its required structure.

So, yeah, XML recipes, but it worked.  Because I got side-tracked by other concerns - namely software engineering in a professional setting - the original website fell by the wayside.  But, it was for all intents and purposes, my first actual completed software project.

And then, much as my cooking career did, my self-directed programming career began wandering in the desert.  I always planned to spend my weekend learning something new.  My typical grand scheme was to use Ruby to write a personal finance site similar to the old installable Quicken application.  Every once in a while, I'd make headway, but would then lose motivation for the next few weeks, at least, in part, because I couldn't convince myself to put in two solid hours on Saturday and Sunday toward my goal, so why even bother putting in any time at all?

This leads me to a brief digression.  Though I'm sure it's prevalent in other professions, the expectation that developers should code in their free time is ingrained in them starting in school.  I'm not sure if it's due to the fact that there are many mythical computer scientists who started programming as hobbyists in middle school or if the industry is seen as so fast-changing that we need to spend more than a typical work cycle keeping up, but it's an expectation.

It's also a dumb expectation.  The word 'passion' is thrown around too much in the software engineering industry.  What's wrong with just being good at your job and furthering your company's business goals as a result?  Why not expand the breadth of your life experiences rather than lock yourself in a room for an additional 4-8 hours per day and slowly slide toward becoming an insufferable bore in order to satisfy some vague definition of 'passion'?  I've heard about companies that turn down potential applicants because they didn't have personal GitHub repositories.  That may lead to a very specific culture, but is that really the type of culture you want to foster?

I have no problems if people want to spend time outside of work on their professional development.  I mean, that's what I'm doing here, but why should that be an expectation?

So, anyway, I didn't get very far on the personal website.  I'd still try some sort of extra-professional learning from time to time, but I was always demotivated by learning a new language or framework simply to solve a set of contrived problems or to write yet another simple blog site.  If I was going to learn a language, I needed to do so in the context of an actual problem rather.

Technically, with the creation of this recipe site, I'm still not really solving a problem that doesn't already have an existing solution, but it scratches a few itches for me -

The problem with most recipe websites is, well, they're blogs.  That's not a problem in itself, but the fact that everyone wants to monetize their blog is.  This means the page load times are incredibly slow as the blogs retrieve external ads for display.  This also means that, in order to actually get to the recipe, I have to go through an entire blogger's backstory before arriving at the recipe, since the more text I have to scan, the more ads I have to see.

While I'm not opposed to this as a business strategy, I don't want to deal with this on every recipe site I cross.  The easiest method for me to get around this is to use existing blog templates built for recipes and write my own ad-free blog for reference.  Blogs, though, aren't designed to index information in the same way, say, a cookbook is expected to do so.  Blogs are generally date oriented.  True, we can actually get around this with some labeling and other simple steps, but this is where the programmer in me begins to bubble up.

Before proceeding, it's probably helpful to review my goals, both for your clarity and my own so I can explain why I'm writing a recipe website.  These are my goals in order:

• Create a website that stores my compilation of recipes for easy reference.
• Use the website as a means to maintain a small software project and keep my skills up to date.
• Use the website as a means to practice some of my other creative endeavors, like drawing.
• Create a section on the website that explains tools and techniques that may be able to assist new cooks to avoid the pain I faced in my culinary travels.
• Possibly find a way to make money off the site, in a non-intrusive fashion.

If I just concentrate on the first goal, and possibly the third, fourth, and fifth, then a blog probably gets me where I want to go.  It's the second goal that throws a wrinkle in the execution.

This, though, leads to conflict with my other goals when I'm not disciplined enough to keep the focus on all of my goals.  Why? Well here's my line of thinking on writing my own recipe website starting around November 2016.  Keep in mind that this wasn't my first iteration either, but the thought process laid out here is indicative of previous iterations of this project as well as iterations of other side projects.

• I'm going to write a simple app and store my recipes on the site in a small database.
• I'm going to use Google AppEngine to do it.
• I'm not going to use Google AppEngine to do it, as the framework model they use is going to be too restrictive, so let me find another way.
• I'm going to research other software as a service sites that will let me write a small app for free or really cheap.
• Everything is either a pain to start up, acquire access to, or too expensive to use.
• DigitalOcean seems to be a good place to run my site on the cheap.
• I still haven't published any recipes.
• OK, I'm starting to write code on a site called Codeanywhere, and it seems to be a great alternative to the need to write all of my code on my own computer.
• However, the virtual machines it uses need to be re-initialized every once in a while and installing all of the necessary software is a pain.
• I'll learn Chef to provision machines automatically.
• I've learned Chef.
• I still haven't published any recipes.
• Why am I spending all of this time writing a program from scratch?  There's probably an open source one I can fork and customize.  Maintaining other software is a valuable skill to have in the industry, so it furthers my goal.
• There is an open source alternative!
• It's a bit outdated.  I should upgrade the components that are there.
• I've learned a lot about code maintenance, upgrades, and Chef.
• I still haven't published any recipes.
• I should just write a static site generator so I can actually publish some recipes.
• Doing so in Javascript will make it much more extensible.
• These Javascript frameworks are more difficult than they need to be for my needs.
• I still haven't published any recipes.
• I'll just write a static site.
• I've published a recipe!
• I've learned about Jekyll.
• I've published several more recipes!

And here we are.

The Heuristics of Computer Science

In my last post, I took a dive into my cooking history from the teen years to present.  In this post, I'll visit my passionate relationship with programming and computer science.  Eventually, I'll get to the motivations for why I'm writing a recipe website, but probably not here.  Again this is a rehash of old content but fleshes out some of the details to make me look more human.

I wasn't always a fan of programming and its academic discipline, computer science.  When I was younger I knew my way around a DOS prompt and played the occasional computer game, but never really got into programming BASIC.  At the time, I don't think I was necessarily intimidated by programming, I just didn't understand what it had to offer.

By the time I got to college, I'd decided on mechanical engineering as a major and, as a result, needed to take a few rudimentary programming courses because even in ME, Software was the Wave of the Future ©.  I was actually pretty excited. I'd come to understand that programming allowed me to build tools from scratch and it could be used to augment analysis I'd do as a future ME.  Having these skills would make me a highly sought after recruit.  While those two previous sentences are true, my introduction to computer science (CS101) didn't help close the gap between my talent and my expectations and make those sentences a reality for me.

Though I knew my way around computers, I certainly didn't know my way around programming languages.  I was also thrown into a weed out class filled with a bunch of kids who'd been programming since they were 12 and a bunch who were ready to drop engineering for a different major in the next week.  I was eager to learn right up until I hit my first compiler error.  Though compiler message syntax is pretty straightforward once you know what you're looking at, it's not a stretch to say it comes close to looking like Greek to someone who's never met a compiler (or, if you're Greek it looks like Aramaic).  I would spend hours in the lab poring over what would later become obvious to me as simple compiler errors with absolutely no context of what I was exploring.  It's as though I was required to learn Chinese simply by staring at the characters.  When I asked a TA for help, the TA would simply circle the compiler output on the screen with his finger and state, "it's somewhere right...there," without explaining the output to me.  This is similar to asking someone what this character means and being told, "the clues are in the context of the characters you're staring at."

Another great point of confusion around CS101 was the fact that we were learning CS basics in a language called Mathematica.  The language itself wasn't the problem.  The problem for me was that we were constantly told, "it's not a programming language."  Since at this stage I understood learning a programming language as something similar to learning a second speaking language rather than a subset of pidgin English, I freaked:  "If I have to relearn everything when I learn a programming language, why am I even learning this stuff!"  Turns out, Mathematica had plenty of the control mechanisms and data structures "real" programming languages have, so I was actually learning to program, I just didn't know it.

Needless to say, the rest of my CS career in undergrad didn't pan out to be as illustrious as I'd hoped.  I slogged through a few more fearful moments before getting my degree and heading out to be a mechanical engineer.  I followed this path for a few years until the company I was at decided it wanted to rebrand itself as an internet company (similar to how everyone now is looking to score off the blockchain fad.  Or was).  As such, they started offering online tutorial classes for programming, and because I was now safely separated from threatening TAs with their Fingers of Doom, I decided to look into the tutorials.

Turns out I liked them.  I even had dreams of teaching myself programming and somehow sneaking into the industry as an autodidact.  Then I worried that no one would hire me if I didn't have proper credentials.  Then I realized I could go back to school for a CS degree.  I started taking a few classes at night, and when my company told me they wouldn't reimburse my tuition because the new degree wasn't relevant to my job, I decided to quit and go back to school full time.  Right at the end of the Dot-com boom.  My first fulltime day at school was September 10th, 2001.  Tim - OH MY GOD, WHAT THE HELL DID I JUST GET MYSELF INTO! - ing.

Well, as we all know, the software engineering market seems to have recovered (just a bit).  It also turns out that my second round with CS was much better than my first.  I wrote a thesis on cellular automata and graduated with honors.  I even got a job before finishing school (turns out it was the worst job of my career and I was fired six months later, but that's probably a different blog post).  And, it was during my computer science renaissance that I wrote my first incarnation of a recipe website.  But that's definitely a different blog post.  Probably even the next one.