I’ve been griping all too much about this Apache-config thing. Yes, it’s been a thorn in my side for some time, but that was all of my own doing. In my search to take the most systematic, educational approach to understanding what the configuration does, I deluded myself into believing I could grok the entire system. That may be feasible for smaller systems or more immediate coding challenges, but when applied to a massive open-source software project like Apache, it’s foolhardy at best.
The good news is that I realized this, which led me to scale back my expectations appropriately. That done, I was able to accomplish what I had originally set out to do without too much trouble. To recap, I needed to configure the server software such that if I opened a browser and navigated to, say, http://mysite.local/, I would see the website I was developing on my machine. Technically, the default setup does something like this, but I wanted my working site to stand apart from other files on my computer — the goal was to make it appear as if it were actually online. The best way to do this is by setting up it up as a virtual host. What’s a virtual host? I’m glad you asked.
With the beginning of the new term — and, consequently, a new course load — I’ve been trying to work out the right balance between class work and hobby projects. And maybe even spending some time away from the computer (imagine that!). For that reason, I put aside Conway in order to focus on a lighter task: futzing about with the web application database. Though I did get a few tasks accomplished, I was doing just that: futzing. So this update won’t be particularly fascinating, by any accounts.
Rewind to a few weeks ago, and you’ll recall I was discussing the basics of designing and building a database. Primary Keys and Foreign Key contraints and all that. Well, with the database schema (the configuration of tables & columns) firmly in place and tested, I was almost ready to build a very basic prototype/proof-of-concept. All I lacked was actual data to manipulate, which meant it was time to generate some. Verisimilitude wasn’t the top priority here, but I figured, the more realistic the data, the better: the prototype will then provide a better subjective “sense” of how the app works.
Last week, I took advantage of a few precious days off to stretch my SQL chops and start designing a usable database. This presented a couple of challenges, the first of which was simply remembering the syntax for creating tables, columns of a specific type, etc. The second challenge was figuring out the multifaceted approach to maintaining data integrity. This latter piece involves judiciously-placed constraints on the data, ensuring that it will always make sense in a real world scenario (even without an application to interpret it). More on this later.
I’ve talked about the tabular format of a database before (like an Excel spreadsheet, remember?). What I avoided discussing earlier are the inherent limitations in modeling an arbitrary system as a series of tables. Individual entities fit in well — for instance, you can easily define a person by their most salient details: username, first name, last name, email address, etc. — but relationships among entities becomes more difficult. How would you denote that two people, as two separate rows in the Person table, are friends? There’s no place for that sort of detail in the Person table. I mean, sure, you could try to add a “friend” column, but that would take either only 1 entry (thus restricting every person to have only 1 friend) or an amalgam of all the friends’ names, which would be an unparsable blob of text.
No; it’s best to keep entities and relationships separate. So to implement the example above, you would create a a second table, Friends, in which each row contains the names of two people who are friends. This way, every person in the system has exactly one entry in the Person table, but a variable number of rows in the Friends table depending on how, uh, socially active they are. A misanthrope will not appear in any rows in the Friend table, whereas a social butterfly will have many, many entries.
So, after the debacle with reseting MySQL’s root account, I was eager to stretch some of SQL query muscles again. I’ve taken database courses in both college and grad school, but since I don’t have the opportunity to practice the syntax regularly, I always come up a little rusty — the right keyword stuck on the tip of my tongue. More than just the syntax though: the mindset required to efficiently query databases is different than for programming. This point was driven home to me last year, when my former roommate — then crunching marketing statistics — would use me as a sounding board for some of the more difficult queries he had to write. At the time, I believe I was coding in Java, and paradigm shift I needed to perform to get into the right brainspace for these conversations was brutal.
Just a quick introduction to querying, first. I mentioned last post that you could think of database storage as, essentially, a series of Excel spreadsheets. That’s close enough to the truth: basic tables (where each column defines a certain kind of datum, and each row represents an atomic record) are the prevalent and (with some very clever mathematics) most efficient storage paradigm: the relational model. But unlike Excel, you can’t just scroll through the table, scanning for the data you want. Though it would provide a nice top-level view, it would be completely impractical for modern systems, which regularly store hundreds upon thousands of records. Instead, to access the data, one writes a query — essentially a command, telling the DB management system (eg. MySQL) which records to fetch, alter, or destroy. Your basic SQL query looks like this:
(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.