What is Larry Thinking? #42 => Doing What I Do, Part 3

In this edition…

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.