Back in high school, one of the nicest compliments I ever got was from our system administrator. He said I was one of the best hardware guys at the school because I was somewhat cautious with the computers I fixed. At first it sounded like a weird compliment – there were certainly other people who knew their way around the inside of the computer better than I did, and I certainly wasn’t always cautious; I broke a few computers around school during that computer repair class, even if I did fix most of them again in the end. I think he meant that I was relatively cautious – I think I fell at a happy medium between so timid I would be afraid to even open the computer and another point at which opening a computer was so routine that being cautious was an afterthought.
I think I find myself at that medium still today. I still really enjoy building computers, but I don’t want to overclock my system because I’m pretty much required to keep the computer in working order for a long, long time. I’m adventurous enough to run Linux 90% of the time at home, but I’m not going to compile all my own software from source. I guess a better motto would be “don’t be afraid to break it any more than what you can fix”. No, that doesn’t sound quite right either. Here it is: “Don’t be afraid to break it any more than what you’re motivated to fix.”
I’ve been meaning to write this post for a long time, but it has required a lot of thought. After my older computer’s latest death, I needed a new computer for some website work I was doing. For over a year I debated in my head if I wanted to buy a Mac or build my own computer, and I tried to get input from my wife as well. Over and over in my head it was the Mac vs. PC debate, but in my case it was really more about what Linux and Windows together can do versus what a Mac can do. The Mac I was most strongly considering was the iMac, mostly because the mini isn’t quite powerful enough and the Mac Pro is a bit above my price range.
I ended up building a computer myself, and overall I’m quite happy with the decision. I don’t have anything against the Mac, but it just wasn’t for me this time around. Here are a few reasons why not the iMac:
- Cost. For the money of a 24″ iMac (I wanted the larger screen because anything smaller than 22″ felt really tiny after my dual 24″ setup at work) I found that I could get a pretty good system.
- Building a computer is fun! I’ve built four computers myself now (and helped in the building of several others), and it has always been fun. I found myself window shopping quite a bit for computer parts, and building my own computer was a great release for that.
- Customization. I find myself being picky about my computers sometimes. I like to choose a monitor and peripherals that fit me, and I didn’t feel that an iMac met my needs here.
- Future Upgrades. I can open up my new computer and upgrade anything I want. That just doesn’t happen with an iMac.
- Learning. This fits in with several of the above reasons, but I think it’s a reason in itself. By building my own computer, I learned a lot. By using Linux daily, I’m learning a lot, too. I already have a place to learn the Mac better (I have a Mac Pro at work), but most of my studies have involved Linux or other UNIX systems, so it has helped me a lot to play around with a real Linux system. I could have just virtualized Linux like I do at work, but I was ready to take off the training wheels and really use Linux almost full-time at home.
- Free software upgrades. Note that this really only applies to the Linux side of things, not the Windows side (which is OK, since I’m using Linux 95% of the time). I love that I can get the new features of a new release of Ubuntu without any extra dollar cost. I also love many open source programs like the GIMP more than their paid alternatives. (Note: I’m not trying to hate on Photoshop, but the GIMP fits in much better with what I need it to do. Using the Mac version of the GIMP is just not fun.) There are plenty of free Mac programs, but almost everything is free on Linux.
If I had decided (and I was really close) to buy an iMac, I needed to justify it to myself. Here’s why the iMac:
- Mac OS and Apple Software. This is a pretty big plus in my book. I like iPhoto and iMovie a lot compared to their Linux counterparts. I’ve found out that I have to deal with Vista a bit if I want to make a movie on my computer. The one drawback here is Finder. Just let it be known that I really don’t like Finder and all the Save dialogs in Mac OS – there are just too many ways to interface with it, and it’s really tricky to figure them all out. I’ll probably have it all figured out by the time they redo the interface. If iPhoto and iMovie updates were cheaper or free, I might have gone with the iMac.
- Wife Acceptance Factor: I didn’t make this term up, but the iMac’s form factor fit really well into a family setting. The fact that everything is integrated means fewer cords, which is a big plus in this respect. I made my way around this one by getting a monitor with integrated everything and doing a better job of cord management up front.
In the end, I will say that the things I miss out on the most by not having a Mac at home is the software – particularly the iLife suite. iMovie and iPhoto are really easy-to-use applications, and that’s probably what I need. I’ve found myself using F-Spot on Linux, which is just OK, and Windows MovieMaker on Vista, which again, is OK. I like Vista quite a bit as a part-time operating system, but it’s way too annoying to use every day. If you haven’t had the pleasure of meeting Vista’s annoying UAC “are you sure you want to do that” dialogs, trust me, you’ll hate them if you ever meet them.
I just read a great article that seems to begin with the exact words I wish everyone thought: Online Safety Begins with Parents, not Laws and Government. It seems like this should be common knowledge, but that’s decidedly untrue. Although many parents might know deep down that they are the ones responsible for their children, it’s all to common for parents to at least behave as if they thought the schools were in charge of raising their kids.
A couple of years ago, my wife and I worked with elementary-age children who were at an age of exploration. They were often seeking of ways to test their boundaries, and it was obvious which ones had structured limits at home in the things they were allowed to do. This lack of parental responsibility was a frequent topic on our drives home, and we realized that proper boundaries could help children learn much faster than if they were given free reign to explore boundaries for which they weren’t prepared. It’s up to all us – parents, siblings, friends, whatever – to help raise future generations, so let’s never think it’s someone else’s problem.
This past week I’ve spent some time evaluating CakePHP and trying to compare it to the things I’ve learned in Ruby on Rails. I checked out CakePHP over a year ago, and I admit I didn’t get into it as much as I had hoped. Having dealt with Struts while using Java, I felt at home with both in terms of their MVC nature and I have no desire to go back to life without a framework. Because CakePHP started out as a Rails Clone, they share many advantages:
- Convention over Configuration – Each framework tries to follow a set of standards in filenames, controller names, and so on so on. When I work on a site someone else designed using a framework, I know where things go and I can familiarize myself with that application much more quickly.
- Don’t Repeat Yourself – Specifying code in one place means that you only have to change it once should it need updating.
- MVC and a focus on “Fat Models” – Separate models, views, and controllers make life easier down the road when it comes time to switch to a new system that has a new database or when you want to make a fancy interface for an iPhone or the next new thing.
There are many other advantages to each, but let’s move on to the differences and disadvantages of these frameworks (keep in mind that this is from a somewhat unexperienced perspective, please let me know if these don’t convey the whole truth):
- CakePHP isn’t as mature as Ruby on Rails. Migrations aren’t fully integrated and the feature set seems to be a few steps behind Rails.
- CakePHP isn’t as easy to deploy as Ruby on Rails. This might matter more for larger applications, but I haven’t seen anything like Capistrano in Rails.
- Documentation is somewhat lacking in both. I had a hard time getting going using only tutorials that I found online. Rails has some great books, but I haven’t found any for CakePHP (although the tutorials and my familiarity with PHP made things easier).
- Ruby is new to me. In my opinion, it has a higher learning curve than PHP (possibly because I already knew Java before learning PHP).
- There are far fewer hosting solutions that provide good Ruby on Rails support. Although it’s pretty easy to get both up and running (especially for the lucky users of Mac OS 10.5), good hosting is pricier for Rails applications.
With all that said, there’s no way I’d like to go back to plain old PHP for developing a website. Things have come a long way even in just the past year for both of these frameworks, so I hope to keep learning them both. In the meantime, though, I’m devoting more of my time to Ruby on Rails, simply because I’m actually finding it fun to code in Ruby (and the Ruby Quiz is something I wish my programming classes had been) while PHP never had me quite as excited.
I just had a few weeks off from school and work, so I thought I’d take a look at Ruby on Rails, which has been the “next big thing” in web programming for over a year now. Two books and over a month later, I can say that I’ve been impressed with that test drive and I think I’ll devote some more time to learning more about how to use it. As a test project, I’m working on re-writing Quotational using Ruby on Rails to get some experience beyond just typing in some example code from books.
I enjoy the structure that Rails offers, and that way it has of making web programming fun again. I’ve used PHP for several years now, and I find myself rewriting things continuously just to make things better. While this has certainly made me a better programmer, the steeper learning curve of Rails lets me do more in a shorter period of time although the degree of difficulty is higher. Rails brings a common framework with it, and one that seems to be more accepted in my experience than any PHP framework that I’ve worked with.
So far, the major drawback has been the availability of free resources for the Rails newbie, although this is a problem that is increasingly getting smaller. My initial impetus to take that first step toward learning Ruby on Rails was an offer for a free PDF book from Sitepoint, a deal that has since expired but is still definitely worth paying money for. That book was a great resource for me, and I’ve since gone on to buy a similar book, Agile Web Development with Rails. Those two books provide a lot of the same information, but reading through them both helped me pick up on things that I would have missed otherwise. From here I may not have a lot of time to devote to learning Ruby on Rails, but I definitely plan on continuing that effort.