Translating Geek Into English

In this edition…

• About This Newsletter
• On the Web => Introducing LarryUllman.com!
• On the Blog => Extras for “Effortless E-Commerce with PHP and MySQL”
• Q & A => Why use the Yii framework?
• Q & A => When will you be doing an OOP book?
• Q & A => What are some sites that have been created based upon your work?
• What is Larry Thinking? => OOP vs. Procedural, the Battle Continues
• Book Giveaway => “Effortless E-Commerce with PHP and MySQL”
• Larry Ullman’s Book News => “Effortless E-Commerce with PHP and MySQL” and more

About This Newsletter

As a warning, this is the first newsletter being sent out using my new system. I apologize if something totally goes haywire. If so, please let me know and I’ll correct it ASAP.

When I revamped my Web site (changing the domain name from www.DMCInsights.com to www.LarryUllman.com and going from a mostly hand-coded site to one based upon WordPress), I looked into the best ways to integrate a newsletter into a WordPress theme. The highest regarded option seemed to be the Newsletter Pro commercial plug-in. It’s designed for WordPress and has some great features. Unfortunately, the one feature it does not have is support for a plain text version. I mentioned this in my previous newsletter and received no complaints (in fact, I received one response along the lines of “It’s 2010, who cares about plain text newsletters?”). Hopefully everyone’s okay with receiving an HTML version, although I’m going to keep the HTML relatively simple. Of course, I haven’t yet figured out how to customize the newsletter’s template using this new system, so what you’re seeing is neither plain text nor pretty HTML, but rather plain HTML. It’s a start, though.

I actually thought this newsletter would be about this recent change, but that turned out not to be the case. Largely this newsletter ended up being about my most recent book, “Effortless E-Commerce with PHP and MySQL“, and object-oriented programming. I’ve thrown in some answers to questions and other stuff. Let me know what you think—about the new site, the new newsletter format, this particular newsletter, etc.—and, as always, thanks for reading!

On the Web => Introducing LarryUllman.com!

My new Web site and new domain name, www.LarryUllman.com, went online on October 31st. If you haven’t checked it out yet, I encourage you to do so. In another newsletter I’m going to write more about the change (once I’ve received more data), but so far I’m quite pleased with the end result. I like the cleaner look of this site and it adds features the previous version didn’t have. Plus, it puts my name and my books front and center, which is kind of the point, after all.

On the Blog => Extras for “Effortless E-Commerce with PHP and MySQL”

After finishing my “Effortless E-Commerce with PHP and MySQL” book, I was left with five PDFs of extra materials. This was content originally intended for the book, but that had to be cut due to page count limitations. Mostly these PDFs discuss and detail various ways to expand or just alter the book’s examples. Although the content is specific to that text, you might get some benefit from them even if you haven’t seen the book. You can find these PDFs among all the extras for the book at my new site.

Q&A => Why use the Yii framework?

I’ve received a couple of questions lately (from Brett and from Joel) about why I prefer the Yii framework. I’ve discussed this before, but it bears repeating. But first , let’s set aside the discussion surrounding using a framework or not. Maybe you like frameworks, maybe you don’t. Maybe, like me, you’ve found a framework you really like, but that still doesn’t mean you’d use the framework on every project. The question here is: Yii vs. CakePHP or Kohana or CodeIgniter or Zend Framework or whatever and how one makes that decision.

My first criteria when choosing a framework is that it must be written for PHP 5, which is to say it cannot run on PHP 4. The way PHP treats objects changed dramatically in PHP 5 and, in my opinion, any framework that will run on PHP 4 just isn’t optimal. Offhand, I forget which frameworks this criteria rules out.

Normally my second criteria would probably be the amount of documentation available. But “amount” and “quality” are not the same thing. The Zend Framework has a ton of documentation, but I found that documentation to be cumbersome and often leaving me with unanswered questions. Conversely, especially when I started using it, the Yii documentation was sparse, but I found Yii intuitive enough that the lack of documentation wasn’t (generally) a show-stopper. I would caution that the quality of anything’s documentation is hard to gauge up front; it’s when you’re trying to figure out something hard at 3 AM that you really see how good the documentation and support is!

Acknowledging that today’s Web sites commonly use JavaScript for added functionality, JavaScript support is another criteria and one of the main reasons I went with Yii. The Zend Framework, which was the first PHP framework I used, has the Dojo Toolkit as its built-in JavaScript framework. I prefer jQuery, though, which is Yii’s built-in solution. So if you’re already familiar with one JavaScript framework, you probably want to make sure that your PHP framework uses it natively as well.

On a similar note, you’ll eventually need to tie the framework-based site into some third-party code, be it a forum or a search engine or whatever. For any decently-complex site, there will be some legacy, third-party system that you have to integrate. Finding a framework that nicely adapts to such situations will make that process all the easier. And one thing I like about Yii is that it can use third-party extensions easily. The result is that I’ve often used the Zend Framework’s Search, PDF, and Email modules in otherwise Yii-based sites.

Finally, I like that Yii generates a lot of the code and file structure for you, meaning that most of your time is just spent tweaking existing code. The first framework I used was Ruby on Rails and it does the same thing. I found with the Zend Framework that I spent far too much time creating folders, creating new scripts, cutting and pasting, etc. This is a minor concern, of course, but something that mattered personally to me.

In the end, frameworks are like cars (you know I like my metaphors): they’ll all pretty much get you where you want to go, it’s really a question of what “feels right” to you. The Zend Framework never felt right to me and the Yii framework really does. Perhaps I might feel the same way about CakePHP, CodeIgniter, Kohana, etc., but, for now, I’ve got a car that works for me. And on that note: if you’re currently using a framework that feels right for you and gets you where you need to be, you probably shouldn’t switch to Yii or any other framework. When it comes to being productive, I’m not a proponent of “change for change’s sake”. If you like learning new things, or want to look into a framework for the first time, then maybe you should consider Yii, but when shopping for a new framework, I would start by looking at the PHP version, the available documentation and support, the JavaScript framework integrated, and the framework’s support for third-party extensions.

Q&A => When will you be doing an OOP book?

Parker had asked when I might be doing an OOP book (and thanks for the interest!). In case you’re not familiar with it, my “PHP 5 Advanced: Visual QuickPro Guide” book has about 150 pages or so dedicated to OOP in PHP from A to Z. Specifically the book has three long chapters on the subject: Basic OOP, Advanced OOP, and Real-World OOP. As a point of comparison, the Real-World OOP chapter rewrites an earlier example from the book using OOP. Neither my “PHP for the Web: Visual QuickStart Guide” nor my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book discusses OOP in any detail, and for good reason: while you can debate whether or not OOP knowledge is mandatory for today’s PHP programmers (more on that later in the newsletter), a decent discussion of OOP requires at least 100 pages. Putting those 100 pages in one of these other books would mean cutting out 100 pages of content that clearly is more critical, like SQL or MySQL or sessions or… But if you are curious about OOP in PHP, I invite you to check out my “PHP 5 Advanced: Visual QuickPro Guide“.

Q&A => What are some sites that have been created based upon your work?

I’ve received a couple of responses to the previous newsletter’s request for sites you’ve created (using, in part, what you’ve learned from my books). Here’s what two people have done:

Steve, a Web developer in America’s “Music City” of Nashville, Tennessee, shared a couple of sites he has done for musicians: www.janisian.com and www.gretchenpeters.com. Steve uses PHP and MySQL to create administrative areas where the artists themselves, without a lot of technical know-how, can post news items and tour dates on their sites.

Edward really likes applying his math skills to Web sites, creating an online application with dozens upon dozens of conversion calculators (at www.CalculatorSoup.com). He also took what he learned about OOP in the “PHP 5 Advanced: Visual QuickPro Guide” book and has turned a lot of the calculators into reusable classes and methods. Another project of his, www.TeacherWishLists.com, allows educators to create “wish lists” through which generous donors can support what they do. Edward uses PHP and MySQL for logging in and out, session management, authentication and security, administration and more.

Thanks to Steve and Edward for sharing. If you’d like to share what you’ve done, let me know!

What is Larry Thinking? => OOP vs. Procedural, the Battle Continues

I never have a long-term plan for my newsletters. When it’s time to send a new one out, I sit down, look through the odds and ends I’ve collected over the past couple of weeks, and put them together. Sometimes the result is a hodgepodge of things with no cohesive theme. Sometimes a theme develops, as the subject of OOP seems to in this particular newsletter. (Similarly, this is how my brain works: sometimes focused and engaged, sometimes scattered about.) I’ve had a couple of questions recently about OOP and a couple about frameworks, which are almost always OOP-based. There was quite a bit of discussion a few months back about OOP making it into my “Effortless E-Commerce with PHP and MySQL” book (it did not). And I recently had a forum encounter about OOP as well. All in all, a bit of writing about OOP in PHP due, I feel.

First, to be clear, let me state unequivocally that I’m not anti-OOP or pro-OOP. I don’t have formal training in OOP or procedural programming and I don’t have a vested interest in the success of either approach (but I am argumentative). Do I use OOP? Absolutely. Sometimes. Which leads us to the reason this is a discussion at all: PHP is one of the rare languages that supports both OOP and procedural programming (C++ is another). If you’re programming in Java, Ruby, JavaScript, and others, you have no choice but to perform object-oriented programming. If you’re programming in C, you have no choice but to do procedural programming. If you’re using a framework in PHP, you almost always have to use OOP. But for general PHP programming, it’s really up to you.

The arguments for OOP over procedural are that OOP is easier to reuse, extend, and maintain, that it’s better for use in team environments, that it’s more secure and less likely to have bugs, and that it’ll make you three inches taller. Okay, I made one of those up. None of these are true. None.

The arguments for procedural over OOP are that procedural is faster both to program and to execute, among other reasons. None of these are true. None.

Bottom line, I think we do ourselves (as developers) a disservice when we think that X is categorically better than Y. The real question should always be: what is best for this particular situation? For example, OOP has benefits when working on large projects or in teams; conversely, procedural has benefits on smaller projects. So it’d be a mistake to think “Oh, OOP is better, so I should use it to handle this contact form.” And I think that’s the trap people, especially beginners, fall into. I worked with a guy 10 years ago who insisted on using OOP for his projects (and this was back when OOP in PHP was more poorly supported). His version of OOP was to create a class that defined EVERY function the site would need. It was terrible, but he thought himself a superior programmer because he used OOP. On the other hand, two huge projects, in terms of both code and popularity, use procedural PHP. Those projects: phpMyAdmin and WordPress. Procedural.

So here’s the real truth: there are situations where OOP may be better and situations where procedural may be better. And in part it depends upon how you define “better”. Faster? Easier? Extendible? Reusable? What is the project? Who is working on it? How are their OOP skills? It’s safe to say that the OOP created by a beginner programmer will not be better than the procedural code put forth by an experienced one.

To be clear, I’m not arguing against OOP here, just arguing against assumptions people make about OOP (and people don’t really argue for procedural). Every single situation should be decided based upon what’s appropriate for that situation, nothing more (although I acknowledge that’s not the way it always works in the real world). Let’s not lock ourselves into thinking we must do X. PHP allows you to program both procedurally or using OOP, so take advantage of that feature. I’ve worked on several Web sites in 2010, two of them were just procedural and the rest were OOP. In each case I would like to think that I choose not the “better” approach but the better approach for the project, which is to say the right approach. (As a segue, one could make a similar argument for Ajax vs Flash for Rich Internet Applications: each has its strengths and weaknesses and it’s best to pick the right tool for each particular job.)

All of that diatribe is intended to address the question “Should I use OOP or procedural?” to which my answer is an unequivocal “Depends”. But if you change the question to “Should I learn OOP?”, the answer is “Absolutely”. For one, employers seems to prefer it, not that I have much direct experience with employers any more. Second, I’m of the opinion that given a choice between learning more and not learning more, always go for learning more. And third, if you know both OOP and procedural, then you can make the proper, educated decision as to which is the right tool for the job at hand.

Book Giveaway => “Effortless E-Commerce with PHP and MySQL”

I gave away about a dozen copies of my “Effortless E-Commerce with PHP and MySQL” in response to the previous newsletter. If you didn’t win a copy, I may giving more away in the future. Or you can ask for it from your local library. Or you could, you know, buy a copy! As for those that did win copies, if you like the book, I always appreciate positive online reviews!

Larry Ullman’s Book News => “Effortless E-Commerce with PHP and MySQL” and more

I’m very pleased to say that my “Effortless E-Commerce with PHP and MySQL” is now out and available in bookstores near you. Well, that really depends upon where you’re at, but it’s been released in America, and will become available internationally in time, I expect. Unfortunately, I never know the particulars of such things. Right now, Amazon.com has it listed for $23.09. If you’re broke, you can always request that your local library get it for you!

I’ve begun working on the fourth edition of my first book, “PHP for the Web: Visual QuickStart Guide“. This is going to be a rather light update of the book, with maybe only 10-20% of it changing. The main addition are a couple of pages at the end of each chapter with review questions and prompts for experimenting on your own. This addition is largely due to repeated reader requests. I also need to update the regular expressions chapter, as the easier-to-understand ereg_* functions are being deprecated in PHP, meaning Perl Compatible Regular Expressions (PCRE) are to be the default.

I haven’t done much (concretely) on my intended self-published JavaScript book, but I haven’t forgotten about it. Once the PHP book is well underway, I’ll start dedicating more time to the JavaScript book.