What Is Larry Thinking? #47 => Random Monkey Appearances

In this edition…

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.

Series

Blog post categories

Note