Wednesday, January 23, 2008

I chose CakePHP

I decided that it would be a good idea to use a framework. Why? Because those who use frameworks swear by them. The idea is that using a framework cuts down on repetitive coding tasks, which crop up most frequently with database-backed web applications (read: every site worth visiting). But they are very complicated to a beginner like me.

Why did I choose CakePHP instead of Zend Framework or Symfony? Well, I installed Symfony and CakePHP, both seemed to work well enough. Users of both frameworks seem to agree that the Symfony documentation is more complete, and each eyes the other as a worthy competitor (compare this to the Ruby world, where Ruby on Rails is virtually the only choice of framework). Basically, I completed the CakePHP blog tutorial, it worked, and I was hooked. No other reason than that. So there you have it: This web application will be built using the CakePHP framework.

Once I installed it and got it running properly, I tried to go through the manual, but many problems crept up, and I found myself copying code out of the tutorial without understanding ANY of it. It reads nicely: $this->Song['id']->save();. Save this song ID, right? Well not exactly. Turns out Cake basically obliges its users to code in PHP, and to do so in completely object oriented (OO) manner. Object oriented programming is great (so I've been told), but, just like everything else in PHP, I'd never done it. So I did a few google searches, completed a few tutorials, and got a loose understanding of the syntax and purpose of OOP. That made a huge difference. For example, I learned the difference between "->" (navigating inside an object) and "=>" (navigating inside an array). But I still wasn't really grasping CakePHP and all of the "$this" commands, until I had a major breakthrough: "print_r($this)." This outputs the contents of $this on to a web page so you can see the object, and navigate through it with your eyes. So simple, so important, yet I had never done it. More later.

Thursday, January 3, 2008

Installing Apache and PHP

Before I can do anything with PHP, my computer needs to be able to recognize it, so I have to install it.

Installing PHP

The simplest way for me was downloading a Windows installer of the most recent version (5.2.5 in my case) and running the installer. You don't need to do anything fancy, just locate the installation where you would put all your regular program, such as in c:\Program Files\PHP. No problem, I thought. But if you write some PHP code, call it test.php and open it with a web browser, the browser will just show you the code, exactly as you entered it. That's because PHP is a server-side scripting language, so there must be a server to recognize it and parse it. Enter the "A" part of the LAMP stack: The Apache web server.

Installing Apache

To get Apache, download the windows installer, run the installer, and install it wherever you like. The tough part is configuring it, which is done through the httpd.txt file, which in my installation is located at C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.txt. When you open this file you are confronted with a mess of hash marks (#) and scary-looking commands. The hash marks are actually there to cancel out the commands that they precede, which means that in order to enable a command, just delete its hash mark. Anyway, here's the important stuff:
  • ServerRoot "C:/Program Files/Apache Software Foundation/Apache2.2/" - this has to point to the directory where you installed Apache. If you used the windows installer it should be properly filled out.
  • ServerName localhost:80 - this what you put if you're using your own computer as a server, which you are if you're installing it on your own machine. Open a web browser and type in "localhost," and you're accessing your own Apache server, in essence serving a web page to yourself. "80" refers to the port, which is probably set by default if you used the windows installer.
  • DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs" - this points to the folder that "localhost" becomes. Anything in the folder is being hosted by Apache. So if you put a file called "index.html" in the "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/" folder, then you can open it by pointing a browser to "http://localhost/index.html." Neat.
These settings are probably enabled by default (as well as a slew of others), if you used the windows installer like I did. Test the installation by opening a browser and typing in "localhost." If it says "It Works!" then the server is working. Remember that "localhost" just points to the server, which opens C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\index.html. So you can edit index.html to make it say anything you want it to, or even replace it with another file called index.html. "localhost" will point to it every time.

If add a bit of PHP code to index.html, the server won't recognize it unless you have installed and configured PHP. If you open the file via "localhost" you won't see any difference. The file will look the same as if you had opened it from the httpd file folder, i.e. not running on a server.

Back to PHP

So now the PHP installation comes in. If you run the windows installer and the program executes, it added a bit of code the very bottom of the config.txt file (C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.txt).
PHPIniDir "C:/Program Files/PHP/"
LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll"
These two lines tell Apache where PHP installed its .ini file, and it told Apache to load another module (the php5_module) and where to find that module (in the PHP installation directory). The php.ini file is just like Apache's config.txt file - it's a list of commands, most of which are blocked by comment characters (semi-colons instead of hashes). If you used the windows installer, these commands should be set correctly. Test the installation by adding some php code to the index.html file, as above. If the browser render the php code correctly (i.e. without the php tags) then PHP is installed and working.

Saturday, December 29, 2007

Some major design themes from around the web

I'm new to the field of web development, and I've been learning a lot by reading articles and blogs by those who seem to be leaders in the field. What I've found is that there are correct ways and incorrect ways to apply the technology that's available. Here's what I've learned so far.

It is imperative to separate content and style. This refers to HTML (the content) and CSS (the style). In the early days of the internet, content was simple, consisting entirely of text. When graphics-based browsers came out (Netscape (RIP) with the first major browser in 1993), there had to be a way to tell the browser how to display the text, hence HTML (hypertext markup language) was used to "mark up" the text for the browser, telling it how to display different elements. As things got more advanced, this ran into serious problems, so CSS (cascading style sheets) came along. The idea now is that HTML marks up the content (but doesn't tell the browser how to handle that content), and CSS defines how the marked-up content looks.

Use AJAX to streamline the user experience. AJAX stands for Asynchronous JavaScript And XML. It's a method of allowing a web page to request information from a server and insert that information into the web page without requiring a full refresh. This allows a user to click on objects, open sub-trees, and otherwise call information without reloading a page. This makes a web page more like an installed computer application, and less like a traditional web page.

Use a PHP framework to separate models, views, and controls. This is just like separating content and style, but on a deeper level. The model refers to the structure of the code, the view refers to how the page renders, and the controls refer to the actual commands that are within the code. Separating these three elements into distinct layers (and into their own documents in their own folders) allows an application to grow while maintaining a clean code base. However, it's a complicated process, and is best suited for very large web sites. I guess I need to make a detailed plan of each page of my own site before I can decide whether or not to use this method. If I do use, there are many frameworks to choose from (in addition to coding my own, which is way beyond me right now): Symfony, CakePHP, and Zend. Symfony appears to have the most complete documentation as now (including a published book), CakePHP I successfully installed, and Zend is probably great too. All the message boards I perused seem to agree that no one framework is better than any other. Use to taste.

Speaking of frameworks, what about Ruby on Rails? RoR uses the Ruby programming language, extant since 1993 but only exploding in popularity today. As far as I know, the language is entirely object oriented, which PHP is not. PHP5 supports object oriented programming, but doesn't force it on you. Those who use Ruby (the language) and Ruby on Rails (the framework) tend to proselytize like Mac users. They say it's the greatest programming language in the world, but unfortunately it's untested (at least compared to PHP). RoR espouses the MVC framework, just like CakePHP and other PHP frameworks, so I'll stick with PHP instead of learning another programming language. Ruby and RoR seem to be great, and I look forward to using them someday. Just not for this project.

How many languages must I learn?

When I started this project, it seemed like the LAMP stack of applications was the best solution, but it's not the only one. Since I'm new to programming, I don't have a preference for any language, and I carry no bias for one or another, so it's important to me to spend enough time choosing the right one for the job. Right now it looks like I have to learn

  • SQL (Structured Query Languange) for MySQL, the database application.
  • PHP (Php: Hyertext Pre-processor) to communicate with that database
  • HTML (HyperText Markup Language) to correctly mark up the content of the finished web pages
  • CSS (Cascadding Style Sheets) to control the design of the finished HTML pages
  • JavaScript to provide client-side scripting and to make use of AJAX
  • XML (eXtensible Markup Language) to move data from the database to the web page
What a job. HTML is the easiest (it's not even a language, just markup), but the others will require diligence and study.

What will I use to build this application?

The application will be constructed using what is commonly called the LAMP stack, which refers to Linux, Apache, MySQL, and PHP.

Linux is an operating system that is commonly used by servers. Servers host the web sites (including this blog) that make up the world wide web. When the application is finished and ready to deploy, I will have to choose a commercial company to host it, and their servers may or may not run Linux, but that doesn't affect the design of the application, and I don't ever have to deal with Linux. The LAMP stack could be WAMP (with Windows), but for the sake of simplicity I'm just assuming it will be Linux.

Apache is a web server. It's actually a piece of software that enables a physical computer to "serve" web pages. Apache takes a raw HTML file from the server, reads the code, and outputs a finished web page to the client (the end user - you.) For development purposes, I've installed Apache 2.2.6 on my computer, so that I can view the output of my own code without having to upload it to a commercial server and then access it over the internet. This speeds the development cycle. Once installed (on the commercial server or on my own computer) it requires little or no upkeep, so Apache doesn't constitute a large portion of my application's development.

MySQL is a database engine that will store the discography information itself. MySQL is freely available, but also comes as a commercial application (MySQL Enterprise) supported by MySQL AB, the company that owns the code. I will be using the Community version, which is free to download and use. MySQL won't be visible to the end-user, but will run in the background. MySQL, like other databases, uses Structured Query Language (SQL), and is complicated enough to warrant its own future posts. Stay tuned. I am using MySQL Community Server 5.0.

PHP is another language that is commonly used as a translator between the front-end (the part of the application that the user actually sees) and the MySQL database. It's a completely separate and very complicated (and powerful) programming language. PHP is a server-side language, meaning it gives commands to the server, which executes those commands and then sends them back to the client. This is the opposite of JavaScript, whose commands are executed by a locally installed version of Java, and then sent to the web browser. PHP stands for PHP: Hypertext Pre-processor. I am using PHP 5.0.

Each of these applications is free to download and use, which has made the LAMP stack the one of the most popular ways to build and host web sites.

Wednesday, December 26, 2007

A discogra...what?

I'm going to build a discographical database. Discographical information pertains to the who, what, where, and when of, in this case, jazz albums. For example, take the (arguably) most famous jazz album of all time, Miles Davis's Kind of Blue. The discography entry for this album would be something like the following:
Miles Davis (trumpet) Cannonball Adderley (alto sax) John Coltrane (tenor sax) Wynton Kelly (piano -1,2) Bill Evans (piano -3) Paul Chambers (bass) Jimmy Cobb (drums)

Columbia 30th Street Studios, New York City, NY, March 2, 1959


1. CO62290-3 Freddie Freeloader (false start) Mosaic MQ9-191
2. CO62290-4 Freddie Freeloader Columbia CL 1355
3. CO62291-3 So What -
4. CO62292-5 Blue In Green -

From the discographical entry, you can see who all the players were and what they played, and you can see it was recorded on March 2nd, 1959, in New York City at Columbia's 30th street studios. You can see that on this date at this location two tunes were recorded - "Freddie Freeloader" and "So What" - and that "Freddie Freeloader" was recorded twice. You can also see that the first recording of "Freddie Freeloader" is available on an album put out by the Mosaic record label, and that that album has the identification number MQ9-191. The second recording of "Freddie Freeloader" is available on an album put out by Columbia, which you could find by looking for CL 1355, and so on.

A veteran user of discographies would also be able to tell by looking at the issue numbers (CL 1355, for example) what kind of physical media the number represents, such as a CD or LP, and he would also be interested in the matrix number (CO62291-3 for "So What"). For an extended discussion of matrix numbers and their importance to the field of discography, see Howard S. Friedman's excellent paper on the subject.

You may have noticed that the discography entry for Kind of Blue only includes two tunes, which would make for a rather short album. What about "Flamenco Sketches," "All Blues," rest of the tunes that made this album so famous? Those were recorded on a different date, at another "session," so they require a separate entry in the discography.

Miles Davis (trumpet) Cannonball Adderley (alto sax) John Coltrane (tenor sax) Bill Evans (piano) Paul Chambers (bass) Jimmy Cobb (drums)

Columbia 30th Street Studios, New York City, NY, March 2, 1959


1. CO62293-1 Flamenco Sketches (alternate take) Columbia C5X 45000
2. Miles Davis comments Mosaic MQ9-191
3. CO62293-6 Flamenco Sketches Columbia CL 1355
4. CO62294-1 All Blues -
Now we have another album, Columbia C5X 45000, and another track (the alternate take of Flamenco Sketches) that doesn't appear on the original Kind of Blue. As you can see, none of the albums currently available actually give a complete picture of either of the two sessions that produced Kind of Blue. This is why accurate discographies are so important.

According to the New Grove Music Encyclopedia, discography is

The systematic cataloguing of sound recordings. Data for listings, in which aspects of the physical characteristics, provenance, and contents of sound recordings are described, are acquired from the recordings themselves (with their containers and any accompanying written and iconographic materials), as well as from logbooks, lists, and catalogues compiled by the record producer or manufacturer, journals and other printed materials, and oral sources.


A very basic discography will include:

  • Name of leader or group
  • Date and place of recording
  • Musicians and their instruments
  • The titles of the tunes
  • Album issue number
  • Album recording label

A more complete discography will include, where applicable, matrix numbers, take numbers, and an exhaustive list of albums on which each take appears. Accurate information about recorded performances is essential in jazz, where recordings - rather than scores or sheet music - are the principal sources for study.

Tuesday, December 25, 2007

Ready....go!

I am going to design, build, and make available a database of discographical information intended for jazz researchers. I am a computer "power-user," but I have no programming or coding experience beyond some basic HTML. With this blog I will track my progress in learning the skills I need, implimenting those skills in the design of the site, and overcoming what obstacles are sure to arise. I intend to use the LAMP stack for this database: Linux, Apache, MySQL, and PHP.