FeFNet

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

As I move on from the stage of just “getting my feet wet” with the Python-based web framework Django, I’ve found a lot of good resources for learning that weren’t very obvious initially. Although everyone’s case may be different, I’ve found the following strategy to be very helpful for my learning.

Get your hands dirty. After getting a feel for what Django is, start the tutorial. I recommend skipping version 0.96 and going straight to the development version of Django because there have been a lot of exciting new features added since 0.96. As long as I’ve been sure to keep up to date with recent changes, I haven’t had any problems using this development version.

Back up often! Make sure you keep copies of different versions of your files. Doing this will help your programming from the beginning, and it encourages you to improve your code instead of being afraid to touch it for fear of breaking something.

Read the Manual. I admit that I usually don’t understand the things I’ve read in the Django Documentation. However, the more I play around with Django, the more I start to understand in the documentation.

Get to know the community. Subscribe to the Django Community feed and find some authors you like to read. Skim the articles that come across and browse through blog archives for more information on subjects you aren’t familiar with yet. Some of my favorites Django authors are James Bennett and Malcolm Tredinnick, although there are plenty of others worth reading.

Take a look at other’s work. One place to start is the DjangoResources page on the wiki. Find a simple application and open it up - figure out why it works the way it does. There are plenty of places to look for this type, including Django Pluggables and Django Sites.

Don’t be afraid to ask! If you can’t find help on a given topic, try a few web searches. If that doesn’t give you what you’re looking for, ask for help on the django-users mailing list. As you learn more, be sure to give back to the communities that have helped you get to where you are now because there are new users who won’t have your experience, and sometimes freshly-learned information can be easier to share with newbies since you’ve been in their shoes recently.

As Django moves toward a 1.0 release in just a few months, there’s never been a better time to learn Django.

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.

Seth Godin struck a chord with me when he discussed reorganizing for profit. He basically says that retailers should organize their stores according to the tasks that buyers will perform. Home Depot should put screwdrivers next to their saws, because a person working with wood would likely need both. I’ve done this a million times at stores like this, finding myself walking through nearly every aisle before I can find what I want. Apparently, there are many people that don’t like this idea, thinking that I’ll find something I didn’t remember I was looking for. They seem to forget that if I can’t find what I’m looking for in the first place, I’m likely to leave.

We all have customers, whether they go by that name or not. Those we’re trying to sell our services to should be the ones we think about first. I’ve met many brilliant computer programmers who sometimes add feature upon feature to their programs that end up being totally unusable because they don’t think about their customers. Hotmail and Yahoo! Mail did this to me recently when they thought I wanted my web-based email client to be more like my desktop email (like say, Outlook or Eudora). Sure, Yahoo and Hotmail felt more like desktop mail clients, but Gmail is a million times faster and easier to use.

Who are your customers? Try putting yourself in their shoes, or better yet, asking them how they think something should be done. If you get yourself into their mode of thinking, then you can try to sell them on the stuff they didn’t know they always wanted.