• /
  • /
  • What is Larry Thinking? #10 => OOP, Frameworks, and the Story of My Dryer

What is Larry Thinking? #10 => OOP, Frameworks, and the Story of My Dryer

February 18, 2008

In this edition…

About this Newsletter

Well, it’s been another month since my last newsletter, so here’s another installment. I didn’t get much feedback on the previous one, so either you’re all as busy as I am or it just wasn’t that interesting. In any case, in this one, I’m going to answer some more questions posed by you all over the past few months. As always, please keep your feedback and questions coming! And, of course, thanks for your interest in what I have to say.

Q & A => What are some of your favorite hobbies, outside of computers?

The original question asked what some of my “cool” hobbies are, but I’m pretty sure I don’t do anything cool (I’m a married, middle-age man with two kids, “cool” left a long time ago). And as I’ve mentioned in an earlier newsletter, raising kids has pretty much swept aside all hobbies. But if I did have time…I really like doing things around the house. Our first house was a real “fixer-upper”, and I’ve reconstructed every room by now. Not just new paint, but I’ve taken many rooms down the studs, removed walls, rebuilt two bathrooms, fixed plumbing, did a slew of electrical work, etc. Unlike computer work, I really like doing this kind of stuff, which is physical and has an obvious result. I also really like woodworking: making furniture and such. Most rooms in the house have something that I’ve built and I’m hoping my next house has room for a bigger workshop. I just have to be really, really careful, because if I lose a finger, that’ll make my day-job that much tougher!

Q & A => When should I use OOP vs procedural programming?

Object oriented programming (OOP) is a great mystery to those that aren’t familiar with it. In procedural programming (which predates OOP), you create variables, functions, and statements. When the code is executed, it goes line by line in order. If a function is called, its code is executed, then the flow is returned to continue after that call. OOP is an entirely different kettle of fish. In simplest terms, variables and functions are wrapped inside of a “class”. In your code, you then create an instance of a class, which is called an object. Then all of the work is done through the object. (This is an oversimplication; classes can be used without objects and there’s much more to it but…) Some programming languages like Java, JavaScript, and Ruby always use objects, whether you know it or not (in JavaScript, when you create a function, it’s secretly defined as part of a hidden global object; in Ruby, everything is an object, even the number 2!). Other programming languages, like PHP and C++, allow you to program using either procedural or OOP style or a combination of the two.

If you’re using a language that supports both procedural or objective programming, which route you go depends upon many things. One consideration is your work environment: If you work on a team, where different people might be playing different roles on the same project, OOP makes a lot of sense. Or if you find yourself frequently doing similar types of projects with repeatable elements, OOP would again be a good candidate. But there’s really no hard and fast rule as to when you’d use OOP or procedural programming. The truth is that anything that can be done procedurally can be done using objects and vice versa. In terms of strengths and weaknesses, you’d have to perform benchmarks to verify this, but I would generally say that procedural code is faster to execute and requires less memory, as there’s less overhead. OOP offers code that’s easier to use and maintain, and can be less prone to bugs (because certain protections are in place). That being said, all of these assessments are up to debate, by the way; you’ll get many different opinions on this topic. I suspect what it really comes down to is that hard-nosed OOPers think that OOP is the only way to go and those that don’t really know OOP think “what’s the big deal?”

I would say that even though OOP is tougher to learn and much harder to master than procedural coding, it’s worth your time to play with some. The nice thing is that a little bit of knowledge is all it takes to use the hard OOP work that other people make available (like PHP’s PEAR and PECL). If you do decide to use OOP, there are two things I’d caution against doing. Frequently I’ll see people try to define their own classes that do something for which there’s already a really good option (or several). Interacting with databases is a common example here. I understand if you’re trying to learn OOP, you practice, but if the goal is to use a really good X widget in a program or script, that goal will often be best accomplished by using other people’s established work rather than trying to create your own from scratch (it’s kind of like deciding you’d like a good car, so you’ll build one from scratch yourself). The second thing that’s common, particularly with beginners, is philosophically-terrible OOP: not understanding or implementing the full purpose and mentality behind OOP. I did some work for a guy (this was a PHP project that he, a PHP developer himself, outsourced to me) and he was really big on OOP. Or so he thought. But he had no sense of what OOP was, really just throwing all his functions, no matter how unrelated, within one class. This may not mean anything to you if you don’t know OOP, but it’s equivalent to painting stripes on a horse and calling it a zebra (I’m a man of a thousand metaphors). Bottom line: If you’re going to use OOP, use it right. If you don’t want to use OOP, or just aren’t doing so right now, don’t sweat it.

Q & A => When should I use a framework?

A framework is an established library of code that you can use to more quickly program something. This of course, is an oversimplification. Perhaps it’s best to describe a framework by comparing it to what it’s not. In pretty much any programming language, you can create all the code you want from scratch. This is a good way to learn but will eventually require too much time as you continue doing big projects starting from scratch time and again. So at some point, most programmers begin using code libraries to handle some of the heavy lifting. The best established of these is Perl’s CPAN. PHP has PEAR and PECL. Ruby has RubyGems (among others). For example, instead of creating a form in HTML, writing the PHP validation, etc., you might just use the HTML_QuickForm class (demonstrated in my “PHP 5 Advanced: Visual QuickPro Guide”).

Frameworks take this concept one big step further, making it faster to create an entire project. Frameworks seem to be gaining more popularity over the past few years, in fact, the rapid growth of the Ruby programming language is partially due to the attention garnered by its Ruby on Rails framework for developing Web applications. I don’t know if this is technically correct, but ASP.NET could be considered a framework, as well (actual programing is done using Visual Basic or C# but ASP.NET provides a lot of useful tools). If you’re using PHP, there are many frameworks available, with Zend recently offering their own version. A search online will turn up many others as well as articles comparing the options.

Using frameworks vs writing your own code has pretty much the same plusses and minuses as in the OOP vs procedural argument. A framework is by definition going to be bloated. It cannot be as efficient as writing something yourself, as a framework is intended to be all things for all people. The Zend framework, as an example, is 10MB in size. That doesn’t mean that all 10MB will be used in every project or hog up the server’s memory, but it’s still 10MB of files just to get started. A framework will also take some time to learn how to use. This is where I point out that you should consider the documentation a framework has when you go to choose one. (As an aside, frameworks use an MVC approach to a task: model, view, and controller. Simply put, this is a way of separating the relationship between the data (aka, the model) and the user interface—the view—by using an intermediary—the controller. MVC is a topic worth looking into, if you’re not already familiar with it.) And, you’ll need to keep an eye on the framework to see when it’s necessary to perform upgrades (another good quality would be a mailing list where you’d be notified of updates). You’ll also need to make sure that the framework supports and keeps up with whatever version of PHP (or MySQL or whatever) that you’re using.

On the other hand, a framework should, first and foremost, make application development much, much faster (after you learn how to use it, that is). And, something created using a framework may be more secure and less prone to bugs (that’s a big “maybe”, really depends upon the quality of your work and the quality of the framework). Just as in OOP, framework-based applications are easier to maintain and update, and easier to use in group situations. If I were in a situation where I had to turn out lots of projects—like a couple of Web sites a month, mastering a framework would make a lot of sense.

Although I don’t want to get in the habit of answering good questions with a shrug of my shoulders, I have to again say that using frameworks isn’t mandatory and it may not be right for you, depending upon your situation. However, taking some time to pick a framework, learn how to use it, and play a little bit is really a good idea. That way, you can make the decision as to whether using a framework is right for you. Still, maybe I’ll try to write up some articles on using frameworks at some point (not sure when but…). To date, I’ve written plenty about OOP—mostly in my “PHP 5 Advanced: Visual QuickPro Guide” and “C++ Programming: Visual QuickStart Guide” books—but I haven’t covered a framework. I’ll add it to my to-do list!

Q & A => What mailing list software do you recommend?

For this newsletter, I went with PHPList, written in PHP with a MySQL backend. So far, I find it to be so-so. It’s satisfactory, but it requires that PHP runs using some less optimal settings. The documentation is pretty good, though, and it’s handling of bounces and the like seems to be solid. I will say that I’m probably not using all of its capabilities. One feature that would be nice would be an automatic archiving/posting of old newsletters. Currently I have to post the newsletters online myself. If someone has a recommendation of mailing list software they like, please send that in!

What is Larry Thinking=> The Story of My Dryer

One of the things I’ve learned since becoming a homeowner (actually, since becoming a dryer owner) is that if the dryer can’t vent properly, it won’t dry the clothes. I know this because when I bought the dryer, I was living in an apartment and it really didn’t work that well, particularly for being brand new. I called the store and they told me to clear out the vent line, so I called the maintenance people, who came over and cleaned out a three-foot ball of lint from the main line! That did the trick. Then I moved into a house and every so often the dryer would stop working well, so I’d go outside, clean the vent, and that’d fix the problem. Except for lately. It wouldn’t be working well and I’d go check the vent and it would be relatively clean. But then the dryer would or maybe wouldn’t work fine again. So I got to a point where the dryer clearly wasn’t working properly and I took the time and effort (big pain, really), to pull out the washer and dryer and clean the vent from both sides as well as I could. But that still didn’t fix the problem. I did some searches online and, categorically, if the dryer isn’t drying properly, it’s likely because the vent’s blocked. That clearly wasn’t the case here as I had just cleaned the vent, so I called in a repairman.

The repairman comes in, runs the dryer, says that it’s putting out heat but the vent’s probably blocked. I explained that I had just cleaned it. He asked if I checked if air was coming out the vent, which I hadn’t (in hindsight, a really good and basic test). He goes outside, doesn’t feel much air coming through, ergo, the vent’s blocked. That’s the problem. They don’t fix blocked vents, so his job is done and I just spent $65 (US). I’m almost positive now that the problem was that the grate that blocks animals from coming in (which I occasionally remove and replace to clean out the vent) was sometimes blocking the flap that opened to let the air out. So the vent was being blocked, just not in the normal way. But why, you’re probably asking, am I discussing this in a newsletter ostensibly about computers?

This situation really hit home for me with something I often run across in helping debug other people’s problems. There are a handful of common problems that have singular causes. The best example is perhaps PHP’s infamous “headers already sent” error message. It’s only caused by something being sent to the Web browser. Once in a while someone will say that they’re getting this but aren’t sending anything to the Web browser. They looked, they checked, and that can’t be the problem. These types of situations are pretty hard to assist with because there’s only one cause and the person is positive that’s not the cause. Universally, in time, they realize that’s actually the cause.

Now I’m not trying to make anyone feel stupid for being in such situations (yes, I felt stupid about the dryer, but I really shouldn’t). I think there’s a natural inclination for people to think problems–computer, personal, whatever–are bigger or more exotic than they actually are. Maybe by making a problem out to be unusual or more challenging, it makes us feel better about our inability to solve it. And sometimes, just sometimes, a problem seems hard because it is hard. But most of the time a problem is actually rather obvious and we’re just out- or over-thinking it. I had a similar experience some years ago when teaching a class and it took minutes to figure out why a student’s PHP code wasn’t working properly (answer: she loaded the page from the file system, not through a URL; now that’s one of the first things I check). My point in mentioning all this is twofold: first, even if you think the simple answer doesn’t actually apply, reconsider it (two or three times), because it’s probably just a case of the simple answer. Always check the fundamentals, especially when you’re positive that’s not the problem. Second, these kinds of things happen to the best of us, and the next time someone says something like they know for a fact that their database is okay, only to later realize it isn’t, I’ll remember my dryer. And the $65 I’m out.

My Book News => “Adobe AIR: Visual QuickPro Guide” Available in Rough Cuts

I’m currently working on “Adobe AIR: Visual QuickPro Guide”. I would say I’m about two-thirds of the way through it, with the intent of finishing the first draft over the next two or three weeks. As a writer, I find the documentation and bugs to be annoying! The software is currently in beta format, so bugs and mediocre documentation is to be expected, but it really makes my job hard. I go to write how to do X and the documentation says that you do this, then this, only to discover that that won’t work. Then I spend an extra hour trying to figure out what does work. But that’s the life I have sometimes. And, if it weren’t for poor documentation, people probably wouldn’t need computer books, right? On the bright side, the software itself is really quite exciting. I speak in some detail about what Adobe AIR is in a previous newsletter, but basically it allows you to make cross-platform desktop applications using HTML, CSS, and JavaScript. The book starts with a lot of the basics, but now I’m writing the chapters where you really start doing things (like using files, directories, and databases). It’s so cool to be able to whip out a graphical application in a couple of hours, the kind of thing that I could have spent a day (or two or three) writing in C or C++ and still not be as nice. And I can definitely see myself creating the kinds of things that I might have implemented as a command line utility. And even though I try not to use Windows if I can help it, knowing that the software I write on my Mac will work just the same on Windows is hard to beat.

The book is available to be read online thanks to the Rough Cuts series. The URL is http://safari.informit.com/9780321524614 With Rough Cuts, you can actually read the book as I write it! Besides being able to look at it months before it’s published, you can also see how the book changes in the process, provide feedback, and more. This isn’t free, of course, as you’re actually getting the entire book in the end (you can’t just read bits of it, as far as I know). According to the information on that site, for $24.49 (US), you can read the book while it’s being written and get a PDF of the final book. This is roughly what the book itself will cost once published (Amazon currently has it listed at $23.09). There’s also an option, for $47.23 (US) to read the book online using Rough Cuts, get a PDF of the book, and get a hard copy when it’s published. I’ve never personally used Rough Cuts before (as a writer or a reader) so I’ll be interested in hearing people’s thoughts on this.

In Uncategorized
permalink