What is Larry Thinking? #20 => Lots of Q&A

March 3, 2009

In this edition…

About this Newsletter

So nothing huge here, just some thoughts I had, answers to a few of your questions, and whatever other random things came up in the past month. As always, thanks for reading and please do let me know what comments and questions you have! (As an adendum, the way things work for me, this got to be way longer than I had intended, but I answered a lot of questions that had been sitting in my inbox for some time.)

On the Blog => An Introduction to jQuery

I’ve been really getting into jQuery lately and have written a couple of articles on my blog. jQuery, in case you’re not familiar with it, is a JavaScript framework for use in Web development (or HTML-based AIR applications). It takes a different approach than other frameworks, making it easy to use and really impressive. The first article can be found at http://blog.dmcinsights.com/2009/02/05/a-quick-intro-to-jquery/. The third was posted today (after much delay) and I’ve got maybe five more planned. And, of course, you can always check out the official jQuery documentation and tutorials for other information and perspectives.

On the Web => Building RIA’s with the Adobe Flash Platform

In January, Sitepoint posted this article on Building Rich Internet Application’s using the Adobe Flash platform. Personally, it wasn’t until relatively recently that I understood how Flash, Flex, AIR, and now Flash Catalyst all worked together, so reading something like this really helped. In simplest terms, you can create a SWF file (Shockwave Format) using Flash, Flex, or Flash Catalyst. Flash is primarily for designers, with a visual approach. Flex is primarily for programmers. Flash Catalyst, which is new (I think it may still be in beta), falls in between. SWF content can be run in Web browsers through the Flash plug-in, which has like 99% adoption, or so Adobe says. You can also take a SWF file and turn it into a desktop application, in which case it’s run through the Adobe AIR runtime (I have no idea how well adopted AIR has been thus far). But you can also create Adobe AIR applications using just HTML/JavaScript. So, that’s shorthand for the platform. It certainly cleared some things up for me (e.g., what I should consider learning) once I understand these basics.

Q&A => How do I make a Web site easily administratable?

Quite some time ago I was asked this question about making the site you provide to a client be as easily administratable as possible. In other words, how can you make a site that non-technical users can update and not break. For me this all comes down to: proper restrictions, validation, and training. The training is simple: get in a room or on the phone and make sure that the people who will use the interface understand how to use it. Well-written instructions in an email and on the admin site are also crucial. Show the user how the admin interface relates to the public content! Validation here is just as important as validation anywhere: if certain elements are required or must be in a proper format, make sure that they are. The restrictions are the important part. Organize your site so that the types of content falls into categories, then provide specific forms for each content type. I feel that by limiting what a user can do, you help guarantee that they do things correctly.

Related to this was a question I received about WYSIWYG editors that work in HTML forms. Often your users should be able to enter editable-HTML for some content. In such cases, you’ll want to use a JavaScript WYIWYG editor, such as FCKEditor or TinyMCE. Those are the primary ones I’ve used. Here, again, restrictions are key. Don’t provide the end user with an unlimited palette. You can customize these interfaces so that the user is presented only with specific styles, colors, and so forth (like those matching your CSS file). You can also use the PHP strip_tags() function to strip out every tag except those allowed. For example, you may not want to allow tables, as a poor table could ruin the layout of a page. By controlling the types of information the user enters and the types of HTML they use, you can successfully insure they don’t break the site you’ve created. Or come close, at least.

Q&A => How can I generate static HTML-pages from database content?

The impetus for this question was concern over the database going down, making a database-driven site unusable. This can happen, particularly on shared hosting accounts with too many sites on the same server. The easy and practical solution is to use caching. There are many caching systems out there but the basic premise is that static HTML pages are automatically created out of database-driven content. When a request is made, the cached version is provided, if at all possible. Not only is caching a safety measure but, more importantly, it’ll dramatically improve your site’s performance as serving static content is much, much faster than dynamic, database-driven content.

Note that when you do an online search for “PHP cache”, you’ll come across links to things like APC (Alternative PHP Cache). These are opcode caching mechanisms, which means they cache the execution of PHP code (I’m putting this in layman’s terms). In other words, an opcode cache means PHP code can be executed more quickly by the server but this isn’t the same as caching the output of a PHP script (i.e., caching the HTML, which is what I suggest here). For an example of HTML caching, look at what software like WordPress or Phorum does, where it automatically generates static versions of files to be served up instead of dynamically-driven ones.

Q&A => How do I handle bogus form submissions?

As anyone that’s put a form online has seen, bots go through the Internet looking for forms, then automatically submit the forms with mostly bad data. This may be a way of trying to hack a server or just post spam to a site (the comment forms in my blog get hit frequently). Preventing this starts by understanding the process. Specifically, the bots are not loading the form page, entering data into it, and submitting the form. Instead, they find what form elements exist and to what page the form data is posted, then fake the submission by making a POST request of they’re own. (You could do the same thing by creating an HTML form with whatever fields on your computer, but using an action that points to a PHP script at some domain.) With that in mind, there are a couple of tricks to prevent these (note that you can’t prevent the spam form submissions, you can just decide how to properly handle—ignore—them):

One step you should take is to validate all form data, of course. Especially make sure that an email address is of the proper format (if it makes sense for the form to have an email address input). The other steps involve adding elements to the form expressly for the purpose of weeding out bad submissions. One interesting trick is to include an empty hidden input. Bots will often provide some data for every form element, so if you have an element that should have an empty string as a value and it doesn’t upon submission, that’s a totally bad submission. Another trick is to use a type of captcha, like a text prompt (What is 2+2? How many continents are there?). On the other hand, these aren’t foolproof and it’s possible that the user might not know the answer (yikes!). A final option is to use sessions. Store some key in a session and also store it in a hidden form input. When the form is submitted, make sure the submitted data contains that same key with the same value. This is even more fool-proof if you enforce cookie-only sessions (i.e., session IDs are not allowed in the URL).

Q&A => What should I learn next?

This is a question I get a lot and have already answered a couple of times in previous newsletters. But my thinking always changes (not necessarily gets reversed but is amended with new information), so I’ll talk about this briefly again.

Assuming that you’re coming from a background where you’ve now done some HTML, PHP, and MySQL Web development (which is the bulk of my readers, I think), there are two routes you can take: improve your existing skills or add new ones. I would argue that both are equally important. So mastering SQL and more advanced PHP skills are a good idea. You can also update your HTML skills by becoming familiar with CSS. Maybe, just maybe, you’d want to consider learning a PHP framework or object-oriented programming. In terms of new skills, learning JavaScript is a logical next step, as it’s more important these days than ever (thanks to Rich Internet Applications). And a JavaScript framework makes sense, too. Maybe learning an alternative database, like SQLite (I’m a big fan) or a commerical choice. Depending upon what your needs and interests are, you may want to also venture a little bit further out into desktop applications (like using AIR) or Rich Internet Applications using Flex or Flash. That’s kind of where I am today: I like learning and trying new things but in a pinch I probably still turn to PHP for any server-side work.

I would also say that improving your software skills or learning new ones are equally critical as the technologies themselves. Becoming more proficient with your text editor or IDE may not mean anything on a resume, but will greatly increase your productivity. The same goes for learning a bit about Apache or Subversion, both of which won’t get you jobs but will make you money in terms of your productivity.

Q&A => The Ruby vs PHP Debate

I get some regular questions about Ruby/Ruby on Rails, probably because I also talk about it some and it’s been in the press quite a bit lately. I wrote about this some in my blog a while back, but I thought I’d repeat some of those thoughts here, in brief.

The first thing to understand is that Ruby is a programming language that’s primarily used for command-line and system utilities (kind of like how Perl is most often used). Through things like eRuby and the Ruby on Rails framework, you can also use Ruby for dynamic Web pages, just like you can use Java in JSP (Java Server Pages). So, to be clear, Ruby on Rails is a Ruby framework for building Web sites. It’s not comparable to PHP but rather to something like the Zend Framework, a PHP framework.

With that in mind, I would say without question that Ruby is pretty great. It’s just kind of interesting in how different it is. It’s the most pure object oriented language I’ve ever used but it’s probably also the easiest OOP language I’ve used (JavaScript is pretty easy, OOP-wise, too). And the Rails framework, like all frameworks, does make development much, much faster, once you understand their usage. Rails has had a lot of bad press lately, but it does somethings that other frameworks I’ve used don’t do, or don’t do as well. For example, Rails will generate most of your shell code for you. No creating basic files or class definitions, just edit them as needed. Plus the built-in unit testing, database migration, etc., is great. As an example of how it can facilitate Web development, the Rails chapter in my Ruby book develops a fairly complete and useful site for adding, editing, deleting, and showing employees and directories in just 30 pages. That’s nothing! I talk about running a handful of commands. Then I add/edit maybe 20 lines of code. And that’s it! Is Rails better than a PHP framework in my opinion? No, but it merits equal consideration, assuming you’re comfortable with Ruby, that is.

I’m still most comfortable using PHP, as I’ve been programming in it for nearly 10 years now. If I had any simple server-side work to do, I’m choosing straight PHP hands-down. On the other hand, if I’m doing any command-line or system utilities kind of thing, I’m clearly turning to Ruby. I’m not sure if anyone else sees this, but I liken jQuery to Ruby in terms of how easy it is to use, once you understand it’s capabilities, and both technologies can be extremely cryptic (in a good way). Finally, I were to start a major Web project today, I’m not 100% sure what I’d use. In fact, I’m working on two for a client and will be using the Zend Framework for both. But I have a couple of personal projects that I’m doing in Rails. And I’m updating some existing projects using just PHP.

So that may not be a clear-cut “XXX is better” answer, but that’s not really what I do. But what I would like everyone to see is that Rails and PHP aren’t comparable, that Ruby is really pretty great, and so is Rails. The hype should be believed! Rails is not a flash in the pan technology.

Q&A => How can I convince clients to actually follow through with their deliverables commitments in a timely fashion (without nagging them to death)?

This is a tough one because it’s always hard to get anyone to do anything. I’ve certainly had this problem and, frankly, I’m not sure that I have a good answer because you can’t get anyone to do anything ever. So I guess the approach I would take is to have measures in place for how you respond under such circumstances, because what you do is the only thing in your control. For starters, in your contract (and you must be using contracts), make sure you’re getting paid incrementally: some up front, some at X stage, some at Y stage, the rest when the job is done. If you hit those stages, make sure you get paid and don’t get too far along if you’re not getting paid. Also make sure the contract specifies what is required of the client: information, images, resources, server access, timely feedback, etc. This list should be concrete and in detail. So the contract specifies what you’re obligated to do and what they’re obligated to do. The next thing to include is what you will (or just can) do if they don’t fulfill their obligations. If they don’t provide the necessary whatever in a timely fashion, you can add three times the delay to the project’s completion date (so if they’re a month late getting you some text, your deadline is now three months later than it originally was or the current moment). If they don’t pay within X days, the project is considered closed, you can take all your code and walkaway while keeping the money. If they don’t provide the necessary info in time, the project is considered closed, you can take all your code and walkaway while keeping the money. What’s really important here is that you have explicit measures in place, that these are communicated to the client ahead of time, and that they are communicated to the client when it’s time to enact them. Then get on with your life. Move on to other clients and projects; don’t waste any time with this one.

I’ve worked on more than enough good projects over the years that never made it live through no fault of mine. And it’s frustrating. But what’s more frustrating is wasting time on dud projects when I could have been working on something better. So cut your losses and move on. That’s what I do.

What is Larry Thinking? => Getting Things Done

Sometime in 2008 I heard about a program called iGTD, short for I Get Things Done. This is a Mac application that implements the “Getting Things Done” productivity philosophy (it’s a whole big idea). I never took the time to really get into the program but have always had it in the back of my mind. Considering the amount and types of work I do, while being a full-time stay-at-home dad, it’s crucial that I’m as productive as possible. Previously, I kept a list of personal to do things in my note-taking application, plus notes on client projects and books, plus notes on other kinds of tasks. Then my calendar application lists repeating events, such as quarterly taxes or server backups. Then I edited and printed out a weekly schedule that listed day-to-day jobs (answer book forum questions, respond to emails, etc.), plus had a list at top of special personal and work things that should also be done that week, when possible. As you can tell, this clearly wasn’t an efficient managment system.

So I recently returned to iGTD, only to discover it was grossly unstable on Leopard (the latest version of Mac OS X). I love a good free application, but this one wasn’t it. After some research and testing, I settled upon Things. Even though it costs $50 (US) and I hate paying for anything if I don’t have to, I’ve been very, very pleased with the result. So I’ll talk a bit in generic terms as to how a GTD application helps organize one’s life. (Again, Things is a Mac-only application but I’m sure there are GTD apps for Windows and Linux). Different GTD programs have different terminology, but basically there are specific tasks, which should be concrete, do-able steps. Then there are projects, which are concrete, do-able things, comprised of multiple tasks, with a definite completion. There are also what Things calls “areas” which are areas of responsibiliity. These are broad concepts without completion. So I have these areas: House, Kids, DMCI, etc.

Like any good database, once the data is in there, I can look at it in many ways. I can see the tasks that are due today, which I now do as either the first or second thing on my computer. Or I can look at the steps in a project in order. Or check out what things a particular area has in it. And there’s that satisfaction of checking off a task (Things files these away in a log). With Things, and some other programs, you can add tags to any task, so that you can then find any task that pertains to just accounting or a high priority or things to do around the house that are weather-dependent.

I’m not really writing this as an advocate for Things, in particular (although I do like it very much), but rather to promote this Getting Things Done idea. Having a central repository for all the stuff I need to do has made me much more organized and efficient, and I couldn’t be happier about that! If you’re using a GTD application, particularly a good one for Windows or Linux, please let me know so that I can pass the recommendation along in a subsequent newsletter.

Book Giveaway

Thanks to everyone for participating in the last book giveaway. I had lots of responses and many people got free, signed books. Most people in the US should have received theirs by now (they shipped out on Friday, February 20th), and international recipients should get theirs soon! I still have a healthy stack of “Ruby: Visual QuickStart Guide” and “PHP for the Web: Visual QuickStart Guide (3rd Edition)”, so I’m sure I’ll be doing another giveaway in a couple of months. For those interested in the e-commerce book, I won’t be doing a giveaway for it until closer to the book’s release (i.e., after I’ve actually written it).

My Book News

Nothing new to report, although I have a couple of things in the pipeline and will report them when they’re official. My online JavaScript guide is proceeding slowly (and may be affected by other developments). I just wrapped up three articles on Adobe AIR and five blog posts on Ajax/JavaScript, to be published at Peachpit’s Web site at some point in the future. I’ll provide those URLs once they go live.

In Uncategorized
permalink