I’m pretty ready to call this blog a failure in terms of keeping me on track of my homespun coding projects. In its defense, the intention was to encourage focus and reflection during the summer months. Now that we’re solidly in the swing of the academic year, my other commitments have tripled, leaving me with little time for personal projects.
However, the thought of this thing languishing here is enough (occasionally) to call my frazzled brain back to action. So it will stay up, and I’ll put what effort I can into it. If nothing else, it gives me reason to explore ideas or technologies that I wouldn’t come across otherwise. In my book, that counts as a good thing.
This time around, I want broach a topic that I have previously failed to describe comprehensibly: algorithms. Most everybody has heard me gripe about the math requirements in my computer science programs, but in all fairness, the Algorithms courses are usually very interesting; the concepts are intriguingly brain-bending (at least until you have to prove them formally). And let’s face it: this is an important subject. If you want to solve a problem correctly and quickly, you need to know how to write a good algorithm. To all of you who have heard me rail against my mathematician torturers, hopefully, this will give you a basic idea of what the course is about.
Let’s start at the beginning: what is an algorithm? Google defines the word as a “process or set of rules to be followed in calculations or other problem-solving operations, esp. by a computer.” But let’s make it even simpler than that. Think of an algorithm as a recipe. You want to make a chocolate cake (yes, of course you do. don’t interrupt.), so you follow a series of steps that tell you what to do when (preheat the oven, mix x quantity of this with y quantity of that, etc), and when those steps are complete, you have a chocolate cake. An algorithm follows the same basic idea: the computer needs to solve a problem (analogous to your lack of cake), so you give it a series of instructions that will tell it how to accomplish that goal. That theoretical (ie. implementation-indepedent) collection of instructions is an algorithm. It’s a recipe, with few extra variables, conditional statements, and loops.
I was going to mention this at the end of the previous post, but that was before it turned into a 2,000 word essay. After all time spent working on the Arts project, I had forgotten what it was like to spend an evening without coding (time off? what’s that?). Around the time we launched Arts and UChicago, I was yearning for another website to hack instead of, say, eating dinner. Or replying to email. Or shopping for groceries.
The site I picked belongs to one of my martial arts clubs — UCTSD: UChicago Tang Soo Do. It was a beast. My fault — we were in such a rush to build it years ago that I hacked it together out of some free online template. Of course, the original template wasn’t intended for our use, so I had to rejigger a lot of it in very messy ways.
Here’s how it looked:
Before anything else, let me give a shout out to my former roommate (yes, the one who cruelly abandoned me to pursue a career in another state — the nerve!) who has set up his own blog: Nerd Out. As is his wont, he promises that he will be “overthinking everything you can be a nerd about.” It currently involves discussion over the finer points of game design and unfortunate PR parodies, and I fully expect it will soon contain his thoughts on artwork in comics, great moments in cinematic history, a symbolic reinterpretation of Schrödinger’s Cat for the internet era, plus whatever he happens to stumble across on Reddit that day. I, personally, find him an excellent and thought-provoking writer, and intend to engage him in witty repartee at every opportunity. Should nerdy things interest you, you should consider doing the same.
And now back to our regularly scheduled program.
First off, let me apologize for the past few weeks of radio silence. I’ve been distracted by the start of the school year, which brings with it new classes, club organization & internal politics, and a number of major website launches. It’s said launches that I’ve been wanting to discuss, but in addition to my generally overbooked schedule, I’ve also had the dickens of a time trying to find the right tone. Though my goal is to point out some design & technical accomplishments (or failures), most of what I say varies between shameless praise and a frustrated griping session. Either approach seems vaguely inappropriate for the very public nature of the sites, so writing about them has become an arduous process.
(Foreword: work is officially killing me. Long hours, and weekends are far from sacred. It’s crunch time (for my SOUL). I won’t go into details, but suffice to say, the time available for my hacking has been grossly reduced. And I am cross. Ok, that’s all. Now on to more technical stuff.)
As I mentioned last week, (M/W/L)AMP is a bundle of software that, collectively, create a entire web development environment on your computer. In so doing, you’re simulating a very limited cross-section of the internet in order to see what your application will look like once it’s actually hosted out in the real world. Here are the different pieces of that bundle, and the part they play in running the web app.
Given the number of projects I’m attempting, not to mention the number of different computers I plan to be using in the process, my first step along this coding odyssey is setting up version control. For you non physical science types, let me explain a thing or two about version control. Imagine that you’re writing a paper. No, better make that seven papers, all at once. Seven interdependent, self-referential papers that constitute a viable argument only when assembled together. Now, imagine rewording a sentence in paragraph 8 of the second paper, only to discover that it voids a reference you make in paper #7, which in turns makes your whole proposition invalid. And you can’t just undo the change, because you don’t remember the original wording. Basically, you’re stuck rewriting that part from scratch until you have something that works.
This is one necessity that mothered the invention of version control software: that there are some mistakes that you simply can’t undo by tapping Ctrl-Z/Cmd-Z ad infinitum (not without destroying anything useful you’ve done in the meantime, in any case). The other problem that it solves is that usually, you would not be working by yourself; you and 3-4 other people would be writing in the same files, at the same time. Take a moment and imagine the muddled nonsense that would come out of that collaboration. Yech. Luckily, we can side-step both issues with some conceptually easy tools.