In a previous article, I briefly highlighted some of the end-user improvements I made to my music site, and now in this article, I want to get a little deeper into things. If you’re not into reading code, or don’t care for technical explanations, now would be a good time to read something else on my blog instead…
First, a look into some of the technology that I used.
The original site used procedural-style PHP (not object-oriented and no framework) and while it was super efficient, it wasn’t extendable and changing anything required a lot of weeding through poorly commented code… Not fun. After I had finally decided that a complete re-write was in order, I had a lot of lengthy conversations about it with my older brother (who is a real programmer with an unbelievable wealth of knowledge and experience). He pointed me in the right direction on a lot of things and answered a lot of my questions about "the right way" to do things. (Thanks Alex!) I wasn’t interested in just "getting the job done", instead, I really wanted to do it right.
Seeing as how my experience with object-oriented PHP was in its infancy at the time, and seeing as how I had never used a PHP framework before, he pointed me to CodeIgniter, which I started to use for the new site. But it wasn’t long before I started to hate it, and it almost felt like I had to work around it instead of working with it. So after doing a lot of research and bouncing back and forth, I eventually switched to Kohana 3.0 and I’ve loved it from the start. Compared to CodeIgniter, their documentation sucks so getting started with it was not as smooth, but the source code is extremely well documented and that has proved to be the best kind of "documentation" anyone can ask for. Switching to Kohana was the best decision I made, and it actually significantly sped up the development process for me. I highly recommend it!
At the same time, I decided to follow Kohana’s lead, (and learn from my past mistakes), and commit from the very beginning to extensively comment all my code. Seriously, anyone who looks at the code now will now know exactly what’s going on and why; I made sure everything is very well commented.
While I was at it, I decided to look into my choice of databases and even went as far as installing PostgreSQL to test it out and compare it to MySQL. In the end, it was a tough call, but I decided that there just simply wasn’t a compelling-enough reason to switch away from MySQL, so then spending the time to change over to PostgreSQL would be hard to justify. I did, however, realize that MyISAM was not the way to go and InnoDB would prove superior for what I needed.
I spent a huge amount of time planning the structure of the database and making sure that things would be extendable in the future. The database tables are now all normalized and I made extensive use of InnoDB’s foreign keys and created a lot of triggers to make everything work extremely well together. Keep in mind, what the end-user sees on the site is not even 50% of what has gone into this "app". There’s a lot of backend processes and private data that the end-user never sees on the web, but they’re paramount to facilitating and automating my music "life" (like financial information for gigs, or information on clients and chart sales, for example). So there’s definitely a lot more going on with the database than is immediately apparent. The nice thing is, everything all ties in together and works together in harmony – I used to have to keep multiple sets of the same information for different purposes, but now, not only is there only a single copy to maintain, but I can also use it together in much more powerful ways!
The nice thing about the previous version of my site is that it was already logging a lot of data (which I was doing nothing with, but storing for future use) so I went into this knowing a lot about my visitors. Most visitors to my site are musicians. And almost all musicians that are serious about what they do use Macs. So it’s logical then, that most visitors to my site would use Macs. (They do.) Most are using Safari, and FireFox is second. (Most Windows traffic to my site is also using FireFox.) The amount of Internet Explorer traffic I get is negligible – but more importantly, I learned that the majority of IE traffic to my site was from people that just "stumbled" across my site, and didn’t exactly generate any revenue… Interesting! The only notable exception to this, I discovered, was the occasional event planner or "business" visitor who would come to my site potentially looking to hire a band for an event. Something to keep in mind for sure… But at the same time, having a closer look into things and cross referencing this information with my historical financial data and information I’ve kept about who hires me, how they find me, etc., I was able to determine that IE visitors to my site are indeed not the ones who generate significant revenue for me. Great to know! I now knew that HTML5, (although it’s still a work in progress), was very safe for me to use for the site, not to mention a slew of other things all this information implies…
Seeing as how cross-browser compatibility with IE was not a major concern, it allowed me to use a lot of newer CSS3 and/or webkit and mozilla specific CSS… There are only two images loaded on the site – the main signature logo and baby bass are one image, and a sprite containing all the various icons is another. The shadows, rounded borders, gradients, boxes, etc. are all CSS3 – no images. Same thing on the iPhone version – in fact, even the button on the contact page that looks like a native iPhone button is being drawn by CSS – it’s not an image! Cool.
Well, that about sums it up I think – did I forget anything? Thanks for reading – I’ll get much deeper into things (and put up code samples) in future articles, so keep checking back! On that note, is there anything specific you’d like to hear about?