In a recent newsletter, I answered a question about how I spend my time between projects. For me, the biggest projects I have, in terms of stress and time consumption, are the books I write. The client projects–Web development and such, no matter how big or complicated, never seem to be that much of a burden. Mostly this is because I find programming to be much easier than writing about programming, and because it’s fun to make things happen, to implement new concepts. Over the course of a year, I’ll work on any number of projects, ranging from consulting a couple of hours here or there (i.e., helping to steer the actual developers) to doing all of the development myself. When these bigger projects are done, I’m pleased to have them off of my list, but there’s never the huge sigh of relief that I have when I’ve finished a book. And that sigh says: now I can do these other 20 things that have been waiting for me!

With the completion of the JavaScript book on the horizon, I’ve been making my January to-do list, and salivating over all the things I’ll be getting done. Certainly, what I will actually do won’t be nearly as long as this list, but one can dream, no? My next deadline isn’t until this summer, which is when I have to turn in the third edition of my PHP 5 Advanced: Visual QuickPro Guide book. Although I’d like to, for a change, get that book done well in advance! Still, I have a bit of time to really put a dent in my “someday” to-do list.

First on my list is to exercise more often. I feel like I’ve gained five pounds for every book I’ve written (all that sitting), and while I’ve exercised more than never over the past few months, I’d like to do much, much better. We could all probably use more exercise!

After exercise, which is a daily and on-going goal, I’ve grouped my dream tasks into four categories:

• Things to work on
• Books to read
• Work things I really should get done
• Personal things I really should get done

The last category is of little interest to you, I imagine, or wouldn’t mean much regardless (mostly construction projects around the house). The work things I really should get done are those things that don’t get done during my books and big projects. For January, this primarily means creating an HTML5 version of this site’s design, plus a corresponding version for my forum. Before I redid this site in October of 2010, the site had become woefully outdated and I want to insure that doesn’t happen again. If time allows, I’ll do a mobile version, too, and make sure everything is performing as well as can be.

The books to read are both personal and work related. I want to read one or two parenting books, a novel, and some work-related books. I’m specifically looking to read The Pragmatic Programmer by Hunt and Thomas first. I’ve heard good things about it. Then, coincidentally, I have a couple of ebooks from The Pragmatic Bookshelf on my computer awaiting a few moments of time. As I read these, I’ll no doubt be posting my thoughts about them here.

Finally, there’s my “things to work on” category, which is a broad category of topics without definitive targets or concrete tasks. Normally these items are a matter of improving my skills in specific areas. Right now I’m thinking honing my abilities and knowledge with respect to Launchbar and TextMate, two Mac apps I use all the time. I know for a fact that I’m underutilizing both. The time I spend improving my skills with them now will pay dividends over the rest of the year. As time allows, I also plan on continuing to write my Yii book, although I’ll probably do that as blog posts, too.

So there are my January 2012 non-resolutions. Which will likely also be my February 2012 non-resolutions. Sadly, at least a quarter of them will end up on my September 2012 resolutions, too!

UPDATE: I just literally finished all the work on the Modern JavaScript: Develop and Design book yesterday, so thus far, I’ve done pretty much none of the things on my list, including exercise more. Ugh. But how about that February list…

• About This Newsletter
• What Were You Thinking? => Using JavaScript
• On the Web => Introduction to MongoDB
• On the Web => The Protocol-Relative URL
• On the Web => 10 Steps to Becoming a Great Web Developer
• On the Blog => My Yii Book Update
• On the Blog => Adobe’s Significant Flash and Flex Changes
• Q&A => How Do You Choose Between Competing Technologies?
• Q&A => How Do You Spend Time Between Projects?
• What is Larry Thinking => Starting a New Project
• Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

Hello, hello. Not a very cohesive theme in this newsletter, but in it, I write about: Web development technologies, how to start new projects, and how to spend one’s downtime. Oh, and there’s one of those bookgiveawaythingies that y’all like so much!

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

What Were You Thinking? => Using JavaScript

In my previous newsletter, I asked for input as to how you use JavaScript, what you know you’re confused by, what you’d like to learn more about, and so forth. I received oodles of replies, which were very much appreciated. I haven’t responded to quite everyone yet, but do plan to still. And all respondents are going into a pool of candidates for a free copy of the book when I have my copies to give away (that looks like February now, or thereabouts).

The bulk of the responses emphasized that I just need to do what I do normally, but this time for JavaScript. In other words, there’s a certain way that I go about presenting technical information that seems to work for many people, and I need to be true to those inclinations. That’s quite flattering and reassuring, as I often second-guess myself when writing new books. It’s also a good reminder not to over extend myself or the book, and as I do the rewrites I’ll be certain to adjust accordingly.

I remember that when I first started writing computer books, I looked at the books that were out there, and many writers seem to want to impress the reader with what she or he (i.e., the writer) knows. Maybe wasn’t the intent, and maybe other writers just have a broader sense of what readers need to know than I do. In any case, my belief has always been that a technical book isn’t about what I know but about what you, the reader, needs to know. Further, it’s not my aim to impress you with my knowledge, but for you to be impressed by what you’ve managed to learn and do. So, as I finish the JavaScript book and perform the rewrites, this is a good reminder for me to keep the content simple (-ish), straightforward, and, above all, useful. When I question if some tip or sidebar is too advanced or unnecessary, that’s probably an indicator that it is.

A good idea that came up a couple of times is to demonstrate and discuss key JavaScript libraries. The book will already introduce some frameworks, but I think libraries merit coverage, too. I’m also now debating doing a chapter on mobile JavaScript. I’m leaning towards doing one, but am pressed for time.

Finally, a couple of people have volunteered to act as proofreaders on the book. The offer is much appreciated, and something I would have definitely taken advantage of if I was self-publishing. However, as this book is going through a traditional publisher, there are already several proofreaders involved. Adding more proofreaders might help catch a thing or two, but would further overwhelm me (it takes a lot of work to assign chapters, read feedback, and so forth) and I’m already so very behind. But I thank everyone again for their offers to help.

And my thanks once again to everyone for their thoughts and feedback. If you have any more suggestions, please keep them coming!

On the Web => Introduction to MongoDB

phpmaster recently posted an article titled Introduction to MongoDB. I’m not entirely sold on non-relational databases yet, in that while I can see how wonderfully beneficial they can be in many situations, they’re not as ubiquitously useful as all the hype would seem to suggest. But in any case, a good article like this one is worth the time to read. The article introduces MongoDB, shows how to install support for it in PHP (although the instructions are for Unix-like systems), and provides code for actually interacting with a MongoDB database.

On the Web => The Protocol-Relative URL

Some time back, I came across this excellent nugget of information that Paul Irish has put forth about the protocol-relative URL. I don’t want to reveal the details here (it’s a short article, and you ought to read it), but the gist is that there’s a very simple way to link CSS, images, JavaScript, and whatever other resources so that they’ll be served over HTTP on HTTP pages and provided over HTTPS on HTTPS pages. I wish I had thought to use this when I wrote my e-commerce book (instead of using two different header files)! Sometimes the simple solution is the most brilliant one…

On the Web => 10 Steps to Becoming a Great Web Developer

I just recently Stumbled Upon an article titled 10 Steps to Becoming a Great Web Developer. Even though the article is two years old, I think it does a great job of laying out the steps one would take to become a Web developer, starting with the basics of HTML, then moving into a server-side technology, and then getting into SQL, CSS, and JavaScript. On the higher end, there are regular expressions, Unix/Linux commands and administration, Web servers, version control, and frameworks. I would question some of the specific resources mentioned, but overall this is a nicely presented list and I can’t argue with the order. Two years later, perhaps the only thing I would add would be to start learning about mobile Web development, and a commenter on my original blog posting suggested XML and JSON, which would be good additions, too.

On the Blog => My Yii Book Update

In my blog and in these newsletters, I’ve informally mentioned my intent to write a book on the Yii framework. In theory, I would be writing it about now, but I’m very much behind on my JavaScript book so that’s not happening at the moment. I have been receiving more questions about this potential book, so I recently posted a quick update on the reasons for the book, how I plan on doing it, and when that might actually happen.

Thanks to anyone interested in that book!

On the Blog => Adobe’s Significant Flash and Flex Changes

I just posted the following on my blog today, and thought I’d share it here since it’s so topical…

Last week, or thereabouts, Adobe announced that it was discontinuing support for Flash on mobile devices. This is, by all accounts, a wave of the white flag in Adobe’s battle against Apple and its iOS devices (if only Steve Jobs were alive today to celebrate). I didn’t think too much of that decision: it does make sense to use HTML5 or native apps for dynamic content to be run on mobile devices anyway. And Flash would still continue to run on desktops, where something like 99% of browsers have the plug-in and 90-some% of video is run through Flash. Flash is such a large component of Adobe’s various technologies that I can’t imagine Adobe leaving it behind.

And then Adobe announced today that it was offering Flex to the Apache Software Foundation (managers of the ubiquitous Apache Web server, among other projects).  Apache will need to vote on whether to accept Flex or not. This announcement does surprise me, as Flex is used not only for Flash creation, but also desktop and mobile application development via the AIR platform. Adobe says it will continue to support Flash and Flex, but clearly Adobe is moving more towards HTML5.
An interesting, and rather big, development. One does not normally think of a technology with such a large market share being outright dropped. We shall see how this plays out…

Q&A => How Do You Choose Between Competing Technologies?

Richard emailed me recently, asking how I approach the situation where two competing technologies can be used for a given project. With his specific example, Richard was trying to decide between using HTML5 or Flash for an animated game. Assuming that both technologies were equally capable of performing the task, how does one make the choice? In simplest terms, Flash will provide the same experience for all users, so long as their browser supports Flash. This, unfortunately, rules out most (and as recently announce, all) mobile devices. Conversely, HTML5 will work equally well on all modern browsers, but will not work at all on older ones.

In response to Richard, I came up with two criteria for making any decision as to what technology to use for a project. First, one has to determine what technologies can achieve the task. Sometimes that alone makes the decision for you, when there’s only one possible solution. Considering the range of technologies and programming languages out there, this is rarely the case these days. For example, for a while, one could only develop iOS apps using Objective-C. But in most situations, there will be more than one option.

The next question is twofold then: who is the target audience and what needs to be supported? In this particular example, if the target audience is mobile users and outdated browsers don’t need to be supported, then HTML5 makes sense. If the target audience is all desktop users and mobile devices don’t need to be supported, then Flash. If everyone needs to be supported, then both technologies is the best solution.

With my own work, I normally aim for the broadest support over the newest thing, unless the point is the newest thing (e.g., you can’t make a site about HTML5 and have it be backwards compatible). I’m really not on the cutting edge of technologies, as many people are. I may be relatively on the cutting edge of useful technologies, but my goal is always to use the best tool, not the coolest one.

A third criteria that I failed to include in my reply to Richard, but is worth considering, is what technology you, the developer, are strongest with. Now, to be clear, this should not have a significant impact on the decision. I’ve seen people use technologies for the wrong tasks too many times, simply because that was the technology the person knew best (e.g. creating graphical desktop applications with PHP, which is possible, but not wise). My point with this criteria is that if you have two comparable choices and you’re stronger with one, then use that by all means. The project will go faster and the end result will be better.

Q&A => How Do You Spend Time Between Projects?

David posed this question, asking me specifically, I believe (as opposed to asking for general advice towards this end). Being me, I’ll both answer for myself and give some advice.

When you work for yourself, the time between projects is especially important. For starters, this is time you’re not making money, so it needs to be used wisely. But if you treat the time between projects as an investment in yourself, and therefore your business, hopefully the period without money coming in will pay off in time. I don’t actually have much time off between projects, which is both a good thing (i.e., I’m busy making money) and a bad thing (I’m stressed and secondary things aren’t getting done). But when I do have downtime, at that moment, I look to the past and I look to the future.

In terms of the past, downtime between projects is when you should make sure that you’ve done everything that needs to be done but got put on the back burner while you were toiling away. This can be replying to emails, doing a little something for a client that wasn’t a priority, and updating your own Web site, LinkedIn profile, and so forth. When I overhauled my Web site a year ago, I was aghast by how out of date and unhelpful it had become. Having such public, poor representations of yourself out there is bad for business in the long run, even if only a little bit. You should have some sort of task management application, and in it you should keep a running list of “high priority someday” tasks, such as those I’ve just mentioned. Complete as many of these as you can as soon as your downtime begins, because if you don’t do it then, when will you?

In terms of the future, it’s largely a matter of improving one’s skills, whether that means learning something new or solidifying existing knowledge. In my task management application, I have a running list of topics that I’m interested in (these are non-high-priority-but-someday tasks). I take some time to investigate those during these little breaks.

Finally, I think it’s really important to recharge one’s batteries during these downtimes, whatever that may mean for you. To me, that primarily means getting away from my computer and doing something active. Part of the reason that I suspect I’m struggling in completing this JavaScript book is that I didn’t have enough (well, any) downtime between it and the previous book I wrote.

Time spent not working may seem like time spent not getting things done and not making money, but there’s a lot to be said for having some recovery time between projects. And I think, perhaps unmeasurably, such downtimes reap their own benefits in the long run.

What is Larry Thinking? => Starting a New Project

Last week, a friend came over to my house, hoping to learn about Web development. This friend has almost completed her PhD from Cornell in computer science, has taught college-level classes on programming languages, and worked at Google, too, so her technical knowledge is excellent, probably exceeding mine. She’s wanting to learn Web development, and while she has had no problems picking up the syntax and fundamentals of PHP, the big picture of Web development was eluding her. We went over a few things and, at one point, she asked how I had learned this or that. And, to be completely honest, I’ve been doing this long enough now, and my memory regarding my own development is sketchy at best, that I couldn’t answer her. But I can certainly recall that starting a big Web project, especially when you’re just beginning, is a daunting enough task as to be overwhelming, and perhaps you, too, don’t know where to begin.

Simply put, projects are a combination of data, functionality, and presentation. Games have a lot more of the latter two and many Web-based projects focus on the data, but those are the three elements, in varying percentages. When you go to begin a new project, it’s in one of these three areas that you must begin. And you should always start with the functionality, as that dictates everything else.

The functionality is what a Web site or application must be able to do, along with the corollary of what a user must be able to do with the Web site or application. The functionality needs to be defined in advance, and ought to be clearly stipulated in the contract (when there is one). Use a paper and pen (or note-taking application), and write down everything the project requires:

• Presentation of content
• User registration, login, logout
• Search
• Rotating banner ads
• Random monkey appearances
• Et cetera

Try your best to be exhaustive, and to perform this task without thinking of files and folders, let alone specific code. Be as detailed as you can about what the project has to be able to do, down to such things as:

• Show how many users are online
• Cache dynamic pages for improved performance
• Not use cookies or only use cookies
• Have sortable tables of data

The more complete and precise the list of requirements is, the better the design will be from the get-go, and you’ll need to make fewer big changes as the project progresses.

Once you’ve come up with the functionality (with the client, too, if one exists), it’s time to start coding and creating files and folders. You can start that process from one of two directions: the data or the presentation. I’m a data-first person, but let’s look at the presentation side to start.

If you’re a designer, or are working with clients that think in visual terms primarily, it makes sense to begin any new project in terms of how it will look. You may want to start with a wireframe representation, or actual HTML, but create a series of pages that provides a usable bases for how the site will appear from a user interface perspective. You don’t need to create every page, and in a dynamically-driven site you actually shouldn’t, but address the key and common components. The end goal is the HTML, CSS, and media, in a final or nearly-final state. Once you’ve done that, and the client has accepted it, you can work your way backwards through the functionality and data.

If you’re a developer, like me, incapable of thinking in graphical terms, it makes sense to begin any new project from the perspective of the data: what will be stored and how the stored information will be used. For this task, you’ll want to use a paper and pen, or a modeling tool such as the MySQL Workbench, but the goal is to create a database schema. Always err on the side of storing too much information, and always err on the side of pure normalization (when using a relational database). Once you’ve done that, I normally populate the database with some sample data. This allows me to then create the functionality that ties the data into a sample presentation. By doing so, I, and the client, can confirm that it’s looking and working as it should. From there, you can implement more functionality, and then have the presentation finalized.

So that’s the process in a nutshell.

Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)

You must be subscribed to the newsletter to qualify for the book giveaway.

Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

I just submitted Chapter 8 of “Modern JavaScript: Develop and Design”, which means I’m about 50% done with the first draft (well, first submitted draft: there are multiple internal drafts prior to that). Progress is still going more slowly than I’d like, but… I always hope I’m about to turn a corner and speed up and one of these days, I will. In fact, I’ve got another deadline to shoot for (having blown past the original), so I will be doing everything I can to get this done ASAP. If anyone knows how to put more hours in the day, or days in the week, please let me know!

Since my last newsletter, I’ve written chapters on: arrays and objects (Chapter 6); functions (Chapter 7); and events (Chapter 8). Next is Chapter 9, on the browser (including CSS and DOM manipulation), Chapter 10, on forms, and Chapter 11, on Ajax. With the core concepts of JavaScript behind me (really, Chapters 4-7), these chapters are getting into more interesting and useful stuff. For example, two events have been used ever since Chapter 2, but now the examples can take advantage of other events. And although most of the chapters in the book thus far use an HTML form is some way, the forms chapter can now be more of a “cookbook” type chapter, explaining how to best work with specific form element types.

The third part of the book, beginning with Chapter 13, is still somewhat up in the air. There will be a chapter on frameworks, one on HTML5 and JavaScript, and another on advanced programming. Depending upon time and space, I’ll do a chapter on libraries (individual libraries, as opposed to frameworks), server-side JavaScript, and JavaScript for mobile apps.

I first started using the Yii framework about two and half years ago. I’ve never been much of a framework person, but Yii really felt right to me, quite similar to Ruby on Rails, which I also always liked. Being a writer, after learning to use the framework, I wrote an introductory series on the subject, which has been quite popular. In all modesty, many have suggested it’s the best documentation available. In fact, the creator of Yii liked my series so much that he listed it prominently on the official Yii documentation page (it’s now under tutorials). Some time after writing that series, I started thinking about writing a full book on Yii, because that’s what I do.

When I decided to write a book on Yii, I figured I’d self-publish it, for a couple of reasons. First, even though I have a wonderful relationship with Peachpit Press, I’m not sure they’d want to do a book on Yii, as the market is kind of small. Second, even if Peachpit would publish such a book, I doubt I’d make much money on the project, considering the small market. By comparison, if I self-publish, I can make 4-5 times per book what I’d make if I went through a publisher. The higher per copy amount could be enough to make up for the smaller sales, ending up with a project that’s financially worth my time to do (sorry to be crass about the money, but writing a book is a lot of work and I do have bills to pay!). Fourth, I’ve been intrigued about self-publishing for some time. And, fifth, self-publishing would give me the opportunity to distribute the book in unique formats and channels, such as a chapter at a time.

If I had my act together (which is to say, if my life were other than it is, in about ten ways), I would have been on the ball and published this book a year or more ago. Sadly, that has not been the case. I keep fairly busy work-wise, and I don’t actually have the time (due to personal constraints) to put in 40-hour weeks, so it’s really hard to add new projects, especially on the level of an entire book. Moreover, self-publishing means no guaranteed money, so I’d have to not do paying work while not making money working on the Yii book, which is a tough situation to be in.

All that being said, it is still my intention to write and self-publish a book on Yii. The only question is: when? This is the question I’m getting asked a lot lately. Before I do anything towards a book on Yii, I still have to:

• Finish my Modern JavaScript: Develop and Design book (which I’m weeks late on as is)
• Write one more article in support of my PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (4th Edition) [I've written two out of three articles, but I'm weeks late on that, too.]
• Come up with a list of videos to do in support of my Modern JavaScript: Develop and Design book
• Actually do those videos
• Continue doing the Web development and other work I have for my clients

So…yikes. Don’t get my wrong: I’m quite fortunate to be busy, but yikes! I’ll be crying if I haven’t finished all of the above by the end of this year, which means in theory I can begin the Yii book at the beginning of 2012. However, I have the third edition of my PHP 5 Advanced: Visual QuickPro Guide due at the end of April. That does give me four months, but I’d like actually make that deadline for a change (my publisher is wonderfully understanding, but…).

Also, along with writing the Yii book, I’m going to have to come up with a site and an ecommerce system and so forth (I already have the software that can output PDFs, ePubs, and mobis). If I’m being optimistic, perhaps in 2012 I can do two Yii chapters per month, but the PHP 5 Advanced book will need to be my first priority. I also don’t want to start the Yii book, get some people paying for it (in part or in whole), and then have the project drag out. I don’t know. We shall see.

I very much thank everyone for their interest in my writing a book on Yii and I hope to make that happen. If you follow the blog and/or subscribe to my newsletter, you’ll get updates as to how this is progressing, when and if it does actually progress.

• About This Newsletter
• What Were You Thinking? => The JavaScript Book
• On the Web => Flash Builder 4.5/Flex 4.5 for Mobile Apps
• On the Blog => Cookies and Sessions in Yii
• On the Forum => FALSE Comparisons in PHP
• Q&A => Could You Say More About Stored Procedures?
• What is Larry Thinking => Doing What I Do: Web Development
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript: Develop and Design”

About This Newsletter

Another three weeks(-ish), another newsletter! It may only matter to me, but I’m happy to say that since I started using Scrivener to write this newsletter (in late 2010), I’ve done a much better job in getting these out regularly. Although, since they only go out once a month, or slightly better, it may always seem to you that the newsletters come from out of the blue. Anyway…in this newsletter I present a random collection of stuff, including the conclusion of my on-going series on building a career in IT. In my next newsletter, I plan on speaking, briefly, about quantum computing, having recently read a fascinating article on the subject.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

What Were You Thinking? => The JavaScript Book

In the previous newsletter, I posted a question about whether it matters to you if I self-publish my intended JavaScript book or if I use a traditional publisher. I also asked the general question as to what readers look for in a book, beyond the content and perhaps writer. There was an excellent response and I thank everyone for their thoughts.

The bottom line was that most people don’t care about the publisher. Some people specifically like, say, O’Reilly books or the Visual Quick* Series, but many don’t pay much attention to the publisher (I’ve always suspected that many readers don’t pay much attention to who the writer is either). The strongest feedback was just for it being made available in specific formats—PDF, print, what-have-you, and that it be of good quality.

It was also nice, and quite flattering, to hear many people express their interest in purchasing the book, regardless of whether I self-publish or use a traditional publisher. I am, indeed, fortunate to have the readership that I do.

Thanks again to everyone that responded and to those of you interested in this book. The actual decision regarding this JavaScript book can be found in the “Larry Ullman’s Book News” section at the end of this newsletter (this is called “burying the lead”!).

On the Web => Flash Builder 4.5/Flex 4.5 for Mobile Apps

Version 4.5 of both the Flex framework and the Flash Builder IDE just came out and the outlook is very exciting. As announced some time ago, the focus in Flex 4.5 is on developing for mobile apps. This means a new wave of components optimized for mobile platforms. That alone might sound “kind of cool”, but this release is much, much bigger than that.

Instead of using Flex to write Flash content that runs in a Web browser in a mobile device (but not on Apple devices), thanks to Adobe AIR 2.6, you’ll be able to write true mobile apps in Flex. With the initial release, you’re able to create apps for the Google Android platform (the largest platform, in terms of sales of mobile devices today). Version 4.5.1 was just released, which adds support for iOS (iPod Touch, iPhone, and iPad) devices and the Blackberry Tablet OS. To summarize:

If you know Flex, you can create mobile applications that run on all major mobile platforms in no time at all!

This could not come at a better time for me. I have a couple of mobile app ideas that I want to develop and was planning on learning how to do so later this year (yes, yes, I’m totally on the cutting edge of the mobile app craze, eh?). I was still hemming and hawing over whether to pursue the iOS route, which would be natural for me (I primarily use Macs and am comfortable with the C family of languages), or go the Google Android route, which would be harder (Java is the default language there), but technically has a broader market. And now, thanks to Flex 4.5 and Adobe AIR, I won’t have to choose between them.

To see the development process, and the output, in action, check out this sneak peek video at Adobe. There’s also this pretty good article on mobile development using Flex and Flash Builder. It’s a very impressive concept and, as far as I know, the only “write once, run everywhere” development solution for mobile apps. This, of course, is the promise of Adobe AIR itself, which allows you to write one application that can run on multiple operating systems (I still seem to be a bigger fan of AIR than the world at large).

On the Blog => Cookies and Sessions in Yii

In my ever-ongoing series on the Yii framework, I’ve recently written two postings on managing state using the framework. The first is on sessions; the second on cookies. Neither is particularly difficult to do using Yii, once you know the right code, of course. With cookies, Yii has built-in extra security measures you can take, for example, to help prevent Cross-Site Request Forgery (CSRF) attacks.

On the Forum => FALSE Comparisons in PHP

I’m hoping that you’ll take this as a comfort, but you should be aware that we all, no matter how long we’ve been programming, are capable of creating bugs when programming. Through the keen testing of a reader, a bug was caught in the second example site from my “Effortless E-Commerce with PHP and MySQL” book. It’s a common enough mistake that I should have caught it myself and yet… You can read my formal explanation regarding the specific code in the forum, but the premise is this:

Say you have the conditional if ($var) {. That conditional will be TRUE so long as $var has a TRUE value. But what is a TRUE value? It’s easiest to understand what a TRUE value is by knowing what a FALSE value is. These are all FALSE values:

• FALSE (case-insensitive)
• NULL
• (No actual value)
• “” (An empty string)
• 0
• 0.0
• ‘0′

There are a couple of other higher-end FALSEhoods, such as an empty array. It should be fairly obvious that FALSE, NULL, no actual value, and an empty string are all FALSE values; the bug arises when you forget that zero, in any form, is also FALSE. And here’s how it can manifest itself as a bug (this is a different example than the one in the book and referenced in the forum)…

The stripos() function is used to identify whether or not string Needle is found within another string Haystack. If the Needle is not found, stripos() returns FALSE. If the Needle is found, stripos() does not return TRUE, but rather returns the indexed position where Needle begins in Haystack. This code, therefore, could be a problem:

if (stripos($haystack, $needle)) {…

The intent is to see if $needle exists in $haystack. However, if $needle is the first part of $haystack, stripos() will return 0, which will be interpreted by that conditional as FALSE. The bug-free solution is to change the conditional to test if the value returned by stripos() is not identical to FALSE:

if (stripos($haystack, $needle) !== false) {…

Note that you have to explicitly use the not identical operator (!==), as using the not equal operator (!=) would again be a bug, as the zero returned by the function would, in fact, be equal (but not identical) to FALSE.

Again, I hope you can take some solace in knowing that we all make mistakes, no matter the level of experience (or maybe that’s depressing?). I personally find it frustrating to make mistakes that I’m already aware of as a possibility, but on the bright side, making mistakes you know about makes them easier to fix!

Q&A => Could You Say More About Stored Procedures?

Oguz had prompted me to write a bit about stored procedures in general and in MySQL in particular. Stored procedures are one of those higher-end database concepts which you may have heard about but never really used (other examples include VIEWs and UNIONs). I previously wrote about stored procedures in my “MySQL: Visual QuickStart Guide” and my “PHP 5 Advanced: Visual QuickPro Guide“, and then relied upon them extensively in the second example of my “Effortless E-Commerce with PHP and MySQL“.

Both stored procedures and stored functions fall under the category of stored routines, added to MySQL in version 5.1 (and MySQL is still adding features in this area). A stored routine is simply a memorized set of SQL queries and code. Think of it like taking any block of PHP code that interacts with a database, has conditionals, does something with the query data, etc., but store all of that in the database itself. The primary difference between a stored procedure and a stored function is that a stored function can return only a single value whereas a stored procedure can return an entire result set (i.e., multiple rows of multiple columns of data). For example, in “PHP 5 Advanced”, a stored function is created that returns the distance in miles between two points on the globe, which involves complicated trigonometry using latitude and longitude. A call to that function is then part of a standard SELECT query, as if it were any other predefined MySQL function. Conversely, in “Effortless E-Commerce with PHP and MySQL”, stored procedures are used to update shopping carts, return a list of sale items, and much more. Both types of routines can also take arguments, just like functions in PHP.

Stored routines offer several benefits, the most important of which is improved security. Because all of the database references—table and column names—are in the stored routines, a PHP script using those routines need not have any knowledge of the particulars of the database. Further, a stored routine can use its arguments in queries with the same security as prepared statements, thereby preventing SQL injection attacks. Applications with the highest level of security requirements, such as banking, rely upon stored routines.

You can also get better performance using stored routines, both because the routines can be cached and because less data has to be transferred to the database (just the data itself gets transferred; all the SQL is already in the database). Using stored routines also offers improved application portability, in that many different types of clients—PHP scripts, command line tools, GUI applications, etc.—can make use of the same stored routines.

There are arguments against using stored routines, too. For starters, you’ll need a relatively current version of MySQL, and the ability to create an execute stored routines (these are permissions not necessarily offered by, for example, shared hosting environments). Stored routines also marry your applications to specific database applications (e.g., MySQL or Oracle), although stored routines are part of the SQL standard and may be somewhat translatable from one database application to the next. And, as with most things, there’s a learning curve involved and debugging applications that use stored routines becomes a bit harder.

You can find out more about stored routines in the books I mentioned, in the MySQL manual’s main page for stored routines, and in the stored routines FAQ and restrictions pages of the MySQL manual.

What is Larry Thinking? => Doing What I Do: Web Development

In this newsletter I’m finishing what became a series on IT careers. I first wrote about becoming a better programmer, in two parts(1 and 2). Then I wrote about building a career and how I got here. Next, I wrote about some of the specifics of what I do, focussing on the writing side. In the previous newsletter, I discussed training. This leaves me with the last thing that I do: Web and application development (i.e., programming).

Web and application development jobs have a wide range of possibilities with a wide range of potential income. Small, simple jobs may pay a few hundred dollars; big, complex, and well-funded projects can pay tens of thousands or hundreds of thousands. Getting any job, regardless of size, is a two-step process: 1) finding out about the job; and, 2) convincing the client to hire you.

There are online sites for finding projects, but you’ll be competing with everyone else there. You’ll have better luck by networking: connecting with people, businesses, and organizations that might be able to make use of your abilities. For example, for a couple of years I was the outside programmer that did the dynamic functionality for a graphic designer. She got the projects, managed the clients, the contracts, and the billing, and I just did my share of the work. A perfect arrangement for me! Local user groups, schools, and similar communities can be good ways to hook up with people in a casual way that might pan out down the line.

As for convincing clients to hire you, the most important criteria in my mind are good communication skills. Everyone says that communication skills are important, but not that many people excel in this area, and way too many don’t even try to communicate well. Be clear, responsive, and punctual in your communications! Doing so demonstrates that you have a level of professionalism needed to do the work itself. If you can’t clearly express yourself in an email, if you fail to answer questions asked of you, or if you’re negligent in responding promptly, it suggests that the work you do will be poorly put together, will fail to meet expectations, and not be done on time, either.

Secondarily, you’ll need to have a portfolio showing what you’re capable of. If you don’t have a portfolio, then give them something that they can look at. One of my very first clients, for whom I’m still working, wanted a bit of JavaScript coding for his site. At that time I had no portfolio to show him, so as part of my bid, I did the work itself and presented that. Nothing more clearly indicates your ability to do a project than actually doing the project! Further, the client could also see, before he hired me, that the project would be finished quickly (because it already was). Yes, I ran the risk of making no money for my efforts, but at the time I needed the work and had to go out on a limb. It really panned out, and I would do it again if I felt I had to (arguably, I have had to in the past, as getting published involves some amount of writing on spec).

And this leads me to a point that you’ll (hopefully) learn in time as you grow your skills and your budget: you’ll always adjust your bids not just to the project and the client but to your situation. When I’m especially busy or if a project isn’t that interesting, clients will get the “I don’t really want to do this project but if I am going to do it, I’m going to get paid well” bid. When I’m not that busy or a project is interesting, I’ll provide a cheaper bid. Life is always a matter of time versus money, and the professional is constantly making adjustments along that scale.

As a final cornucopia of thoughts, first, don’t be afraid to overbid. Even if you’re desperate, you may really come to regret getting a project at a low bid. If anything, it tells you a lot about a client that wants the lowest price: you probably don’t want to work with people that want things on the cheap. There is no doubt you will sometimes make less money on a project than you should (and hopefully sometimes make more), but try not to plan on shortchanging yourself. For that matter, have a good contract in place with expectations clearly laid out so that you don’t get steamrolled.

Next, you could consider becoming a specialist in one area: CMS (e.g., Joomla), WordPress, etc. You run the risk of not being able to get work as easily, because you are so specialized, but you may also be able to make more money, and get better at a smaller set of skills faster, by narrowing your focus.

And lastly, if you’re working on a project and you’re having problems and aren’t going to make the deadline, handle the situation professionally. Never hide from clients, be as honest as you can, and always reply to emails promptly. For more strategies along these lines, check out this nice article.

So that’s it on my long series on building a career in IT. As happens with me, all the time, what started off as a simple idea expanded and expanded. I worry that I ran out of steam at the end here, but hopefully you’ve benefitted from this discussion somehow, and I’ve helped you, in whatever small way, in pursuing your dream of an IT career (as for me, my dream involves a hammock overlooking the Caribbean Sea).

Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript: Develop and Design”

I’m very pleased to say that I’ve completed the first draft of the fourth edition of “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (and by “first draft”, I mean the first draft submitted to the publisher; there are multiple writing drafts just to get to that point). As with the fourth edition of “PHP for the Web: Visual QuickStart Guide“, I added a “Review and Pursue” section to the end of each chapter. I also expanded the coverage of SQL and MySQL, including much more on JOINs. One new chapter introduces the jQuery JavaScript framework, with examples of form validation and performing Ajax requests. Another new chapter introduces the fundamentals of Object-Oriented Programming, using the MySQL Improved extension for several examples, and the DateTime class for another. In the appendix, I’ve included a few pages on configuring the Apache Web server, providing the syntax for performing common tasks such as password protecting directories and URL rewriting.

Last, but not least, I am pleased to announce that I have in my hands a contract to write the book “Modern JavaScript: Develop and Design” for Peachpit Press. This is the publisher I’ve worked with the most, and so I’m quite comfortable with them. The book will be in a new series, titled “Develop and Design”, specifically created for code-based books (the first title in the series is on ActionScript). The series does not use the two-column format like the Visual QuickStart/QuickPro series (which some people like, some people don’t), and will be in full color, a first for me. The publisher has allotted me up to 600 pages, which is quite a lot, and by using a publisher, the book will have the widest possible availability (Peachpit Press really worked with me on making this happen). I’ll begin formally writing the book in late July or early August so that it comes out by the end of the year. Once again, my thanks to everyone for their interest in this book, and for all of the feedback.

So, CodeLobster is an IDE for PHP that runs on Windows. It’s available in both a free and “professional” version, the professional version costing $100 (US). The free version comes with an HTML editor and inspector, a CSS editor, a JavaScript editor, a PHP editor, and a PHP debugger. This all includes the standard features such as code completion, code collapsing, browser preview, project management, FTP, and so forth. The professional version includes all of those features, plus plug-ins for specific tools and frameworks: CakePHP, CodeIgniter, Drupal, jQuery, Joomla, Smarty, Symfony, WordPress, and Yii. In other words, the professional version gives you code completion, contextual help, and so forth for these additional tools that you may also be programming in.

As I said, I haven’t personally used it, but if you’re looking for a PHP/Web Development IDE, it may be worth checking out.

What you’ll want to do to create a cookie is create a new object of type CHttpCookie: Yii’s class for cookies. Here, then, is the syntax for setting a cookie in Yii:

Yii::app()->request->cookies['name'] = new CHttpCookie('name', 'value');

You must use the same name value in both places, replacing it with the actual cookie name. Remember that the cookie’s name, and value, are visible to users in their browsers, so one ought to be prudent about what name you use and be extra mindful of what values are being stored.

Tip: Because the cookie’s name must be used twice in the code, you may want to consider assigning the cookie’s name to a variable that is used in both instances instead.

Once you’ve created a cookie, you can access it (on subsequent pages, because cookies are never immediately available to the page that set them), using Yii::app()->request->cookies['name']->value. You have to use the extra ->value part, because the “cookie” being created is actually an object of type CHttpCookie (and Yii, internally, takes care of actually sending the cookie to the browser and reading the received cookie from the browser).

To test if a cookie exists, just use isset() on Yii::app()->request->cookies['name'], as you would any other variable.

To delete an existing cookie, just unset the element as you would any array element:

unset(Yii::app()->request->cookies['name']);

To delete all existing cookies (for that site), use

Yii::app()->request->cookies->clear();

By default, cookies will be set to expire when the browser window is closed. To change that, you need to modify the properties of the cookie. You can’t do so when you create the CHttpCookie object (i.e., the only arguments to the constructor are the cookie’s name and value), so you must separately create a new object of type CHttpCookie, to be assigned to Yii::app()->request->cookies later:

$cookie = new CHttpCookie('name', 'value');

Then adjust the expire attribute:

$cookie->expire = time() + (60*60*24); // 24 hours

Then add the cookie to the application:

Yii::app()->request->cookies['name'] = $cookie;

You can manipulate other cookie properties using the above syntax: domain, httpOnly, path, and secure. Each of these correspond to the arguments to the setcookie() function. (You can also manipulate the value of the cookie through $cookie->value and the cookie’s name through $cookie->name). For example, if you want to limit a cookie to a specific domain, or subdomain, use domain; to limit it to a specific folder, use path; and to only transmit the cookie over SSL, set secure to true.

You can also improve the security of your cookies by setting Yii’s enableCookieValidation to true, in the Yii configuration file:

return array(
    'components'=>array(
        'request'=>array(
            'enableCookieValidation'=>true,
        ),
    ),
);

Cookie validation prevents cookies from being manipulated in the browser. To accomplish that, Yii stores a hashed representation of the cookie’s value when it gets sent, and then compares the received cookie’s value to ensure they are the same. Obviously there’s extra overhead required to do this, but in some instances, the extra effort is justified by the extra security.

Finally, one good reason to use cookies in a Yii-based site, even if the site is otherwise using sessions, is to prevent Cross-site Request Forgery (CSRF) attacks. A CSRF works like this: malicious site A has some code on it, such as an image tag whose src attribute points to a page on site B that does something meaningful: http://www.example.com/page.php?action=this. When any viewer loads the page on site A, the use of that src attribute has the effect of that user performing a request of the page on site B.

As an example, let’s say that an administrator at your site logs in and does whatever but doesn’t log out. The administrator therefore still has a cookie in her or his browser indicating access to the site (i.e., the user could open the browser and perform admin tasks without logging in again). Now let’s say that the src attribute on malicious site A points to a page on your site that deletes a blog posting. If the administrator with the live cookie loads that page on site A, it will have the same effect as if that administrator went to your site and requested that page directly. This is not good.

To prevent a CSRF attack on your site, first make sure that all significant form submissions use POST instead of GET. You should be using POST for any form that changes server content anyway, but a CSRF POST attack is a bit harder to pull off than a GET attack.

Second, set enableCsrfValidation to true in your configuration file:

return array(
    'components'=>array(
        'request'=>array(
            'enableCsrfValidation'=>true,
        ),
    ),
);

By doing this, Yii will send a cookie with a unique identifier to the user. All forms will then store that same identifier in a hidden input. The form submission will only be handled then if the two identifiers match. With the case of a CSRF attack, the two identifiers will not match because the form’s identifier will not be passed as part of the request (I hope this is clear; if not, let me know). Note that this only works if you’re using CHtml to create your forms (if you manually create the form tags, Yii won’t insert the necessary code for preventing CSRF attacks).

The most important thing to remember about cookies, which I’ve already stated, is that cookies are visible to the user in the browser. And unless you’re using SSL for the cookies, they are also visible to anyone else while being transmitted back and forth between the server and the client (which happens on every page request). So be careful of what gets stored in a cookie! If the data is particularly sensitive, use sessions instead of cookies.

The question I can’t really answer is what advantage Yii has over the X framework. The only other PHP framework I’ve used extensively is the Zend framework. The Zend framework has a lot going for it and is worth anyone’s consideration. To me, its biggest asset is that you can use it piecemeal and independently (I’ve often used components of the Zend Framework in Yii-based and non-framework-based sites), but I just don’t like the Zend Framework as the basis of an entire site. It requires a lot of work, the documentation is overwhelming while still not being that great, and it just doesn’t “fell” right to me.

Anyway, the point of this post is that there’s a nice article at SHELDMANDU from back in January in which the author does a great job of comparing the Yii framework with the Zend framework and Code Igniter (I’ve heard many good things about Code Igniter). Moreover, the author lays out some of his criteria for what he wants in a framework, has reasonable and detailed critiques, and also specifically details why he didn’t consider other frameworks in his comparison. If you’re looking into frameworks, spend five minutes reading that article to help educate yourself as to what considerations you should have in mind during your research.

The first thing to know about using sessions in Yii is that you don’t have to do anything to enable them, which is to say you don’t have to invoke session_start(), as you would in a standard PHP script. This is the behavior with Yii’s autoStart session property set to true, which is the default. Even without using session_start(), you could, of course, make use of the $_SESSION superglobal array, as you would in a standard PHP script, but it’s best when using frameworks to make total use of the framework. The Yii equivalent to $_SESSION is Yii::app()->session:

Yii::app()->session['var'] = 'value';
echo Yii::app()->session['var']; // Prints "value"

And that’s all there is to it. To remove a session variable, apply unset(), as you would to any other variable:

unset(Yii::app()->session['var']);

So…nothing really unexpected there, once you know where to find the session data. The more complex consideration is how to configure sessions for your Yii application. You can do so using the primary configuration file (protected/config/main.php). Within that, you would add a “session” element to the “components” array, wherein you customize how the sessions behave. The key attributes are:

• autoStart, which defaults to true (i.e., always start sessions)
• cookieMode, with acceptable values of none, allow, and only, equating to: don’t use cookies, use cookies if possible, and only use cookies; defaults to allow
• cookieParams, for adjusting the session cookie’s arguments, such as its lifetime, path, domain, and HTTPS-only
• gCProbability, for setting the probability of garbage collection being performance, with a default of 1, as in a 1% chance
• savePath, for setting the directory on the server used as the session directory, with a default of /tmp
• sessionName, for setting the session’s, um, name, which defaults to PHPSESSID
• timeout, for setting after how many seconds a session is considered idle, which defaults to 1440

For all of these, the default values are the same as those that PHP sessions commonly run using, except for autoStart.

If your site will not be using sessions at all, you would want to disable them by adding this code to the “components” section of protected/config/main.php:

'session' => array (
    'autoStart' => false,
),

If you are using sessions, for security purposes, you may want to change the session’s name, always require cookies, and change the save path:

'session' => array (
    'sessionName' => 'Site Access',
    'cookieMode' => 'only',
    'savePath' => '/path/to/new/directory',
),

The save path, in case you’re not familiar with it, is where the session data is stored on the server. By default, this is a temporary directory, globally readable and writable. Every site running on the sever, if there are many (and shared hosting plans can have dozens on a single server), share this same directory. This means that any site on the server can read any other site’s stored session data. For this reason, changing the save path to a directory within your own site can be a security improvement. Alternatively, you can store the session data in a database. To do that, add this code to the “components” section of protected/config/main.php:

'session' => array (
    'class' => 'system.web.CDbHttpSession',
    'connectionID' => 'db',
    'sessionTableName' => 'actual_table_name',
),

If you choose this route, Yii will automatically create the table if it does not exist. You can also perform any of the other session configuration changes in that code block, too.

So…what else? Frequently, for debugging purposes, and sometimes to store it in the database, I like to know the user’s current session ID. That value can be found in Yii::app()->session->sessionID.

Finally, when the user logs out, you may want to formally eradicate the session. To do so, call Yii::app()->session->clear() to remove all of the session variables. Then call Yii::app()->session->destroy() to get rid of the actual data stored on the server.

And that’s what there is to know about using sessions with Yii, at least that’s all the key information. I hope this helps you with your Yii-based applications. As always, thanks for reading and let me know if you have any comments or questions.

• About This Newsletter
• What are You Thinking? => “PHP and MySQL for Dynamic Web Sites”
• On the Web => Two E-Commerce Articles Published Online
• On the Web => Several Excerpts from “Effortless Flex 4 Development”
• On the Web => Toad for MySQL
• On the Blog => Rendering View Files in Yii
• On the Blog => Using Amazon’s CloudFront as a CDN
• Q&A => How Can One Become a “Real” Programmer?
• What is Larry Thinking => Becoming a Better Programmer, Part 2
• Larry Ullman’s Book News => “PHP for the Web”, “PHP and MySQL for Dynamic Web Sites”, and More!

About This Newsletter

I managed to come up with a theme for this newsletter: how to become a “real programmer”. I’ve received a couple of questions along these lines, and had begun the conversation in the previous newsletter, so I thought I’d write about the subject even more. In my next newsletter, I think I’m going to write about the other side of the equation: for those of you trying to build up a career, what it may be like when you get there. I don’t know: maybe not. Anyway, I’m likely to include a book giveaway in the next issue, regardless.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

Also, for those of you that would like to create an “official” connection with me, you can do so via LinkedIn (I don’t use Twitter, Facebook, or other social media).

What are You Thinking? => “PHP and MySQL for Dynamic Web Sites”

In this newsletter I’m starting a new subsection, titled “What are You Thinking?”. In such sections, I’ll directly ask you, the beloved reader, for your input on a given subject. As always, you’re not obligated to reply, but if you have any thoughts, brief or long, I would really love to hear them. The purpose of such sections is so that I might better cater what I do to what you really want.

In this newsletter, I’m wondering what, if anything, you’d like to see in the next edition of my “PHP and MySQL for Dynamic Web Sites” book. This will be the fourth edition, which I’m going to start writing soon. The immediate plan is to update all the code for the latest version of PHP, remove references to PHP 6 (PHP 6 died since I started writing the last edition of the book), and add a “Review and Pursue” section to the end of each chapter, as I did with the fourth edition of my “PHP for the Web: Visual QuickStart Guide”. The good news is that I should have room for a new chapter, so I’m wondering what you might like to see. Ideas off the top of my head include (in no particular order):

• Another example chapter
• An introduction to a framework
• A quick (very quick) introduction to object-oriented programming
• A JavaScript primer
• More information about Web servers (such as .htaccess files)
• More about databases

So what would be meaningful to you? What have I missed in other editions of this book or my other work? What haven’t I covered enough?

As an added incentive, I’ll give away 10 copies of the book to those in the pool of respondents.

On the Web => Two E-Commerce Articles Published Online

Peachpit Press has published online two of four articles I’ve recently written for them. Both articles are in support of my “Effortless E-Commerce with PHP and MySQL” book, although the ideas explained are applicable to any e-commerce project.

The first article is “Creating a Customer Review System in PHP and MySQL“. The second article is “Building an E-Commerce Site with PHP: Making Product Recommendations“. Two more articles, and a series of blog postings, are forthcoming, probably over the next two weeks.

On the Web => Several Excerpts from “Effortless Flex 4 Development”

Peachpit Press, the publisher of my book “Effortless Flex 4 Development” (technically, Peachpit’s sister company New Riders is the publisher), has posted excerpts from the book available for reading—for free—online. You can read about the following subjects:

• Datagroup
• Item Renderers
• Four Data Formats
• Flash Security Model
• Using the Network Monitor
• Data Paging
• Adding Authentication

You can see all the articles and blog posts that I’ve written for Peachpit Press by viewing my writer’s page there.

On the Web => Toad for MySQL

The technical editor on my past two books is a big advocate of Toad for MySQL, a free MySQL tool for Windows. I don’t regularly use Windows, so I haven’t tried it myself, but I take Jay (the technical editor) at his word on such things. Plus, it’s free!

On the Blog => Rendering View Files in Yii

On my blog, I recently wrote up a quick guide to rendering view files using the Yii framework. If you’re using Yii, the article should help you understand these fundamentals, but even if you’re not using Yii, I hope the article helps convey how frameworks and the MVC design pattern generate the output seen by the user in the Web browser.

On the Blog => Using Amazon’s CloudFront as a CDN

I just published, on my blog, a post explaining how I choose and setup Amazon’s CloudFront as a Content Delivery Network. I decided to finally utilize a CDN in order to improve my site’s sluggish performance. So far, the experience has been remarkably simple and even more remarkably affordable.

Q&A => How Can One Become a “Real” Programmer?

Celia had sent in this question:

Can a person become a “real” web programmer from studying books and online resources, or is it necessary to take college classes and study programming languages such as C++?

I expect many people have wondered this same thing, as you hear about C++ and Java and formal training and certification and can easily believe those things are required to be “real.” Well, as a counterpoint, there’s an argument to be made that I’m a “real” programmer, and my entire body of formal training consists of…one high school Pascal class (twenty years ago). In fact, I expect that a good percentage of people who read my work have more formal computer training than I have. I’m not saying that to be dismissive of my abilities but rather to say that many paths will get you where you want to go.

There are really two issues to this question: becoming an able programmer and being employed as a programmer. You can most assuredly become a “real” and capable programmer without formal training and without learning a more advanced language like C or C++. First, whatever training you have, formal or not, the fact is that you only master a language by using it. It’s just as possible to take a course on, or become certified in, a language and never truly master it as it is to teach that same language to yourself and become quite skilled.

As for the type of language, PHP, my favorite language and the one I use the most, is quite approachable, but that doesn’t mean it’s inconsequential. I can program in C and C++ (even Java, to a lessor degree), but don’t regularly have the need to. There is clearly more than enough that you’ll be able to do by just picking up PHP, or any other language, through books and online resources.

The second issue that I think is implied by the question involves “marketability.” In this regard, formal training and certification is often necessary (sadly). There are many technical jobs that I wouldn’t qualify for on paper because I don’t have a college degree in computer science (it’s in English). However, there are always ways around such things. Bill Gates doesn’t have a college degree (not a legitimate one, anyway), and he made out okay. This is to say that you can, with enough talent, imagination, and hard work, invent your own success. Or you can get your foot in the door at a company by performing an apprenticeship. Even when it comes to marketability, the fact is that formal training and certification can only, at best, get you over any initial qualification hurdles when you’re looking for a job.

At the end of the day, you can only ever become a “real” programmer by doing: creating functional, practical, Web sites, scripts, and applications.

What is Larry Thinking? => Becoming a Better Programmer, Part 2

In my previous newsletter, I wrote about how one becomes a better programmer. In the article, I came up with a simple mantra: Read. Do. Review. If it’s simple, it’s got to be right, right? A second, related question to how one becomes a better programmer is what actual qualities should a good (or better) programmer have? I haven’t come up with a pithy answer for that one, but here’s what I do know…

First, let’s distinguish between the “competent” programmer and the “incompetent” one. The primary basis for the quality of any programming task is: does it work? In other words, does the script or application do what it needs to do? For a competent programmer, the answer is “yes”. For an incompetent programmer, it’s “no”. For an incompetent programmer to become a competent one, she or he first needs to overcome this hurdle. To be fair, a competent programmer may write code that has bugs (in fact, is likely to) and the program might not be optimal, but basic functionality is always the first criteria. So the rest of this article is intended to differentiate among the strata of competent programmers.

(If “competent” and “incompetent” sound too harsh—because every one of us is incompetent when we begin, you could say “capable” and “incapable” instead.)

I’ve come up with three criteria for identifying the quality of code (and therefore, the quality of the programmer): security, usability/maintainability, and performance. You may think I’m missing something with just three items (and I may be), but sub-factors go into them. Let’s look at the least important of the criteria: performance.

On the bright side, performance is easily quantified: run tests and compare numbers. If you write two versions of a PHP script, run them both on the same server, and if one is consistently faster than the other, then it performs better. Better programmers, in my opinion, know how to write code that will perform better. This means that better programmers know things like:

• How to properly design a database
• How to use database indexes appropriately
• To avoid using include_once() and require_once() (when using PHP)
• How to use caches
• And so forth

The problem with performance is that this knowledge takes effort to learn. You’ll have to read a lot, run benchmarks, pay attention, etc. But over time better programmers learn these more optimal programming habits. Also, performance is less important as a criteria because it’s easily overcome. Not an ideal solution, but if code performs poorly, more hardware can always be thrown at the problem. Conversely, no hardware solution can remedy code that’s difficult to use or maintain.

A more critical skill for the better programmer is the ability to write code that’s easier to use, reuse, and maintain. This skill, while more valuable than being able to write code that performs well, is harder to quantify. But I can say what qualities go into such code.

Most importantly, code that is well documented is easier to use, reuse, and maintain than code that is not. In fact, if you were to ask me what is the most important quality of a better programmer, I would say better programmers write better documentation. I used to teach an online PHP course for the University of California at Berkeley and I expect that “document your code more!” was probably the feedback I gave most often. The last time I did a code review for a client, the code was so poorly documented that there was no way I could have told the client that what their in-house programmer was doing was good or valuable. So if you want to become a better programmer today, start doing a better job of documenting your code! Also, do make sure you update your comments as you change your code. It’d be better to have no comments at all than to have comments that contradict what the code actually does.

Second, code that is easier to use, reuse, and maintain is organized well, in terms of files, folders, and functions (I love alliteration; like simplicity, it just has to imply truth). The better programmer makes proper use of subdirectories, included files, and user-defined functions. As for a couple of concrete examples, the better programmer writes included files so that they don’t make assumptions about what has happened previous to their execution. And the better programmer writes good user-defined functions, with appropriate use of arguments, no reliance upon global variables or other external data, and a “black box” mentality (i.e., you don’t have know how the function does what it does in order to use it correctly).

Third, code that is easier to use, reuse, and maintain handles errors gracefully and reports them only when appropriate. In an ideal world, the best programmer is writing code without errors, but in the real world, applications have external dependencies that can undermine what you’ve done. Watching for, and handling, such exceptions is a hallmark of the experienced programmer.

Finally, and probably most importantly, the better programmer is aware of security: common hacks and how to prevent them, protecting the server, protecting the user, etc. This is a life-long pursuit.

So those are the qualities that I think of when it comes to differentiating between good and better programmers. I’m sure I forgot something (feel free to send in your thoughts). I will add that some people see a benefit to brevity when it comes to code. This is particularly true in object-oriented languages, such as Ruby and JavaScript, where multiple actions can take place in a single line. I don’t personally honor brevity as some great goal, at the very least because brevity often comes at a cost of legibility, which is more important to me. But even if you do value brevity, it’s really just window dressing compared to these other qualities.

Larry Ullman’s Book News => “PHP for the Web”, “PHP and MySQL for Dynamic Web Sites”, and More!

As mentioned already, some of the articles I wrote for Peachpit Press’s Web site, supporting my Effortless E-Commerce with PHP and MySQL book, have been published and more will be soon. I’ll post links to the new ones on my Web site, and in future newsletters, as they go live.

The fourth edition of “PHP for the Web: Visual QuickStart Guide” has gone to press. I’ll post updates when it should be available, and give away some copies in the next newsletter. Along with fixing any minor problems, updating the code for the latest version of PHP, and adding a “Review and Pursue” section to the end of each chapter, the book includes one new chapter, called “Putting It All Together.” The chapter demonstrates how to use everything covered in the book to assemble a mini-Web application, with authentication and full CRUD (Create, Retrieve, Update, and Delete) functionality.

Either this week or next, I begin writing the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide.” Near the beginning of this newsletter I explain my intentions for this edition, and ask for any input you may have. The book should be available come August.

I have finally begun working on my self-published JavaScript book, although not as regularly as I would like. But starting is a key step. Once I get a decent first draft completed, I’ll begin looking for volunteer editors and tech reviewers (I’ll also figure out how to reasonably compensate them!).

public function actionUpdate($id) {
    $data=$this->loadModel($id);

    $this->render('update',array(
        'model'=>$data
    ));
}

Note: That method would also have code in it for handling the submission of the update form, but I’m trying not to complicate the discussion.

As you can see in that code, the render() method, defined in the CController class, is how a View file is chosen for rendering. The first argument to the method is the View file to be rendered, without its .php extension. The render() method will render the View file within the appropriate layout file. In other words, the View file will be rendered with its context. The above code renders update.php, for the associated Controller, wrapped within the views/layouts/main.php layout file (the default).

The second argument to render() is an array of data that can be sent to the View file. In the above code, the Model instance is being passed along. In update.php, references to the $model variable will refer to the loaded data (note that the View gets its variable names from the indexes used in the array).

The render() method takes an optional third argument, which is a Boolean indicating if the rendered result should be returned to the Controller instead of sent to the Web browser. This would be useful if you wanted to render the page and then send the output in an email or write it to a text file on the server (to act as a cached version).

Sometimes you’ll want to render a View file without incorporating the layout. To do that, invoke renderPartial(). For example, both the update.php and create.php View files, auto-generated by Yii, just provide a context, and then include the form file:

<?php echo $this->renderPartial('_form', array('model'=>$model)); ?>

Since the initial View file will have already be rendered within the layout context, the layout shouldn’t be rendered again. The renderPartial() method will render just the named View file. Its second argument, as with render(), can be used to pass data to the View file. In the above, the Model instance is passed along.

Tip: The renderPartial() method is also used for Ajax calls, where the layout isn’t appropriate.

As mentioned already, the file being rendered comes from the directory associated with the current Controller. For example, when updating an Employee record, the URL is something like www.example.com/index.php/employee/update/id/23. This calls the actionUpdate() method of the EmployeeController class (whose code is partially shown above). That method renders the “update” View, which is to say protected/views/employee/update.php. But there are rare cases where you’ll need to render View files from other subdirectories. For example, you may want to include a search form on a page, with that form found within another View directory. To change the reference point, start the View reference with a double slash, which means to start in the views folder. Then indicate the subdirectory and file, still omitting the extension:

<?php echo $this->renderPartial('//search/_form'); ?>

And that’s all there is to it!

View rendering is one of the most important concepts to grasp in an MVC design. Fortunately, it’s not that hard to follow in Yii. Just remember that if you want your layout file, use render(). If not, use renderPartial(). If you need to pass data to the View file, use the second argument to send along an array, whose indexes will become the names of the variables within the View. Finally, if you need to change the include path, begin with a double slash.