About a week before my planned talk, I was shocked to receive an email reminder from the Meetup website advertising the meeting as being about Balsamiq, jQTouch, QUnit, advertising, and the App Store. I immediately contacted Reynold and told him this bore no relationship to what I was planning to talk about. He said it didn’t matter. As an established author and Adobe Community Professional, I felt it did matter. People who had signed up for the meeting would be expecting me to talk about those subjects, something which I was not prepared to do—for the simple reason that most of them are out of my sphere of expertise. So, I decided to cancel. Reynold then bombarded me with a series of direct messages on Twitter. One did include an offer to change the description on the website, but I found his attitude aggressive, so decided to leave a 24-hour cooling off period.

The following day, I sent a lengthy email explaining why I had been offended, but saying I was still willing to give the previously arranged talk as long as a revised title and description were published. I know that Reynold received the email, because his account sent an automatic receipt. However, the only other response was an email from Meetup informing me that I had been removed from the group.

The way things have turned out is a pity. As I told Reynold and his predecessor, Nigel Muris, in November, I don’t have time to organize a Dreamweaver user group myself. But I am willing to share my knowledge either through formal presentations or troubleshooting sessions. I can also make arrangements with my publishers for free or discounted copies of my books.

Reynold has changed the name from The London Dreamweaver Meetup Group to The Adobe & Web Open Source London Meetup Group. However, the website still uses the Dreamweaver URL, and the group’s description refers frequently to Dreamweaver. At one point, it even uses the name, London Dreamweaver (Zero coding) Meetup Group. Anyone hoping to use the most recent version of Dreamweaver without a strong understanding of HTML, CSS, and JavaScript (or at least jQuery) is likely to be seriously disappointed.

In spite of using Adobe in the revised name, it’s not an official Adobe user group. I know that Reynold has applied for official recognition, but Adobe’s position is that the organizer must first show that it’s a viable user group. It hasn’t got off to an auspicious start.

• Using variables
• Working with strings (text), numbers, and arrays
• Making decisions with conditions and comparisons
• Using built-in functions and creating your own custom functions
• Including external files
• Deciphering PHP’s often cryptic error messages

Finally, all that knowledge is put to practical use by building a script to gather user input from an online form and send it by email. The content of the course covers similar ground to the first five chapters of my book PHP Solutions, 2nd Edition, and is aimed at people who prefer learning by watching and doing rather than from the pages of a book.

The course costs $39.99 on its own, but is free to video2brain subscribers. Subscription plans start at $14.99 a month ($149 a year), but until the end of March 2012, you can get a discount by following this link. If you’d like to try before you buy, there are four free videos from the course:

• Setting Up a PHP Site in Dreamweaver
• PHP, the big picture
• Using Loops for Repetitive Actions
• How PHP Sends Email

Although one of the videos shows how to set up a PHP site in Dreamweaver, you do not need Dreamweaver to follow the course. It’s completely software-neutral and contains advice on choosing a suitable script editor, with suggestions for both free and paid-for programs.

If you buy any video training (in English) from video2brain before the end of December, you’ll get an activation code that allows you to share the same course(s) with a friend. What makes the offer so interesting is that it also applies to the new subscription service, which gives you access to more than 130 courses and 500+ hours of videos on web development and digital design.

As a video2brain author, I can offer you a discount on the subscription price. So, if you sign up for an annual standard subscription for $129 before 31 December, you’ll get an activation code (which needs to be used by 15 January 2012) for a friend. In effect, two of you can get access to the whole video library for a year for $64.50 each. With at least four new courses being added every month, it’s an incredible bargain. Splash out a bit more on a gold subscription to get access to the project files, or go the whole hog with a platinum subscription to use the videos offline.

Never heard of video2brain? It’s an Austrian company that has been providing video training in German, French, and Spanish for the past decade. It started creating courses in English in 2009, and now has more than 500 hours of English-language instruction on Photoshop, InDesign, Dreamweaver, and many other aspects of digital media. The videos have been created by some of the top names in their fields, including Rufus Deuchler, Tom Green, Angie Taylor, Todd Kopriva—not to mention me. The company has also created a large number of videos for Peachpit, one of the best known names in computer technology publishing. So, it’s no fly-by-night company.

As a video2brain author, I’m able to offer a substantial discount on the already competitive prices for the new subscription service. There are three levels of subscription:

• Standard—$129 a year or $12.99 a month (normally $149/$14.99). This gives you unlimited access to all English courses streamed online.
• Gold—$179 a year or $17.99 a month (normally $199/$19.99). In addition to the courses, you also get access to all project files and PDF books.
• Platinum—$279 a year (normally $299). In addition to the the project files and PDF books, you can download the courses to view them offline.

Students and teachers can purchase the academic version of the standard subscription for $99 a year.

If you subscribe during the introductory period, video2brain says it will lock the subscription price for three years. And as the collection of courses grows, you’ll get immediate access to all new titles. It’s planned to add at least four new courses each month. So, if you’re looking to brush up your digital skills and keep abreast of the latest developments, you can do so for as little as 35 cents a day. Many of the courses have sample videos that you can view free of charge, so you can judge the quality for yourself before committing your hard-earned cash.

I have to admit that I’m far from being an expert in JavaScript. I’ve used it for about eight years, but it’s never come as easy to me as PHP. So, earlier this month, I headed down to Brighton for the third Full Frontal JavaScript Conference organized by JavaScript whiz kid, Remy Sharp. I had attended Remy’s Node.js workshop in London in May, and realized he was not only knowledgeable, but also well organized. That gave me high hopes for the conference, although I was a little concerned about immersing myself for a full day in a series of talks about different aspects of JavaScript. Unlike a dedicated workshop, you can’t raise your hand and get the speaker to go over a point you didn’t quite understand. Well, you could, if you wanted to make a fool of yourself in front of 300 people, most of whom were likely to be pretty hot on JavaScript.

I needn’t have worried. Remy had invited an excellent mix of speakers, and each talk was limited to 40 minutes. As a result, even the technical presentations by Jeremy Ashkenas (about CoffeeScript) and Marijn Haverbeke (about code editing in the browser with Code Mirror) served more to inspire than to fill me with dread. In fact, that’s the main thing I took away from the conference—inspiration at the incredible ways you can use JavaScript. Glenn Jones demonstrated some really cool uses of the new drag and drop API in HTML5. Nicholas Zakas’s talk was more theoretical, emphasizing the value of building applications in loose coupled modules—something that applies to most programming languages.

Two of the most inspiring talks came from Brendan Dawes and Marcin Wichary. Brendan presented a witty tour-de-force that somehow got from his obsession with pencils to a fascinating series of demonstrations of visual navigation systems that encourage exploration. With a background in Flash development, Brendan’s showing that—with skill and imagination—you can do visually amazing things with JavaScript. Equally amazing things are done by Marcin Wichary, who unveiled some of the secrets of Google doodles. What really impressed me was the length he goes to in order to ensure that even users of older browsers get a similar, if not equal experience.

JavaScript is becoming easier thanks to libraries such as jQuery and Microsoft’s decision to follow the World Wide Web Consortium’s Document Object Model (W3C DOM) since Internet Explorer 8. The HTML5-related APIs are also adding lots of new functionality to browsers, but there’s a danger of slipping back to the days of animated GIFs if designers/developers add new bells and whistles to their sites “just because they can”. So, Phil Hawksworth’s witty presentation was timely, warning against shizzle for the sake of shizzle.

All in all, a good day out. Any regrets? Yes, Brighton is only an hour’s train ride from London, so I decided to make it a day trip. But I had to get up so early to make it to the venue in time that I was dog tired and began nodding off in the afternoon. I was also too tired to go to the after-conference party—and missed all the free beer! Next time, I’ll book myself into a local hotel.

To get the group going, I have agreed to give a talk on Thursday 26 January demonstrating how to create a simple mobile website using jQuery Mobile, which is integrated in Dreamweaver CS5.5. The time and location have yet to be decided, but we’re trying to fix somewhere in easy reach of central London.

Reynold has put a lot of effort into planning the relaunch of the Dreamweaver group, so I’ll leave it up to him to announce the details of what he’s got in mind. In the meantime, I’d like to share some thoughts of my own about Dreamweaver’s reputation and how it can be improved.

Does Dreamweaver produce bad code?

I’ve been using Dreamweaver on an almost daily basis for about ten years, so I know the program pretty much inside out. Even before I started writing books about Dreamweaver in 2003, I always updated to the latest version as soon as it was released. As a result, I also know how the program has developed over the years. Yet whenever I meet professional web developers in Britain, they’re almost unanimous in their hostility towards Dreamweaver. Time and again I’ve been told that no serious professional would consider using Dreamweaver because it produces such terrible code. However, when I ask how long ago it was since they last used Dreamweaver, the answer is usually “ten years ago”.

How is it possible to judge the quality of any product—let alone a piece of software—based on impressions of it ten years ago? I freely admit that the quality of the code created by Dreamweaver all those years ago was far from perfect. Back in 2001, the Web Standards Project (WaSP) set up the Dreamweaver Task Force (later renamed the Adobe Task Force) under the leadership of Rachel Andrew and Drew McLellan, working together with Jeffrey “Mr Web Standards” Zeldman. The task force had two basic aims:

1. Improve the standards compliance and accessibility of web pages produced with Dreamweaver.
2. Raise awareness of web standards among the Dreamweaver community.

When Dreamweaver MX was released in 2002, the WaSP task force released its findings, which concluded—among other things—that “Dreamweaver produces valid markup ‘out of the box’”, and that “the most important thing about this release is that it recognizes the importance of web standards and tries to promote them within the constraints placed on it.” So, even as far back as 2002, WaSP acknowledged Dreamweaver’s support for web standards and the quality of the code it produces. But what were the constraints the task force referred to? The main problem was that Dreamweaver MX still used <font> tags as the default for styling text—although the user could switch to CSS. That changed with the following release, MX 2004, when CSS became the default. And since Dreamweaver CS4 (released in 2008), the only way to use <font> tags has been to insert them manually.

Even so, some horrors remained inside Dreamweaver, the worst of which was Layout Mode. This was aimed at visual designers with an aversion for code, but it created a tangled mass of nested tables that collapsed like a house of cards if you tried to alter the design. As a result of behind-the-scenes lobbying, Layout Mode was deliberately hidden in Dreamweaver CS3, before being removed completely from Dreamweaver CS4. At the same time, all the sample pages that used nested tables and deprecated markup were replaced by standards-compliant CSS layouts designed by WaSP evangelist, Stephanie Sullivan (now Rewis). Another monstrosity that bit the dust in Dreamweaver CS5 was the Web Photo Album. Many of the outdated JavaScript “behaviors” have also been quietly swept away.

As well as removing the bad aspects of the program, the Dreamweaver engineers have added new features—some of them highly successful, others not quite so good. One that I would put in the latter category is Spry, Adobe’s attempt at creating an Ajax library. The idea behind Spry was good, but lack of investment, combined with the runaway success of jQuery, meant that it never fulfilled its potential. Although Spry widgets still live on in Dreamweaver, Adobe has focused its efforts on jQuery—not only incorporating code hinting for it, but also becoming a major corporate sponsor and donating the full-time efforts of several engineers. Among the really positive improvements in Dreamweaver, I would cite syntax checking and code introspection for both JavaScript and PHP, plus the dynamic incorporation of full documentation for PHP 5.3. Dreamweaver’s handling of CSS3 media queries is also a great timesaver, keeping its features in tune with web standards as they evolve.

At the recent HTML5 Live conference in London, Opera evangelist Bruce Lawson jokingly asked me when Dreamweaver was going to stop writing crap code. I’ve known Bruce for some time, and realize that it was meant as a gentle leg-pull, but such thoughts are a decade out of date. Many web professionals use TextMate or Coda to build their websites, but it isn’t the software they use that makes them professionals. It’s their knowledge of HTML, CSS, and other web technologies. In the hands of an unskilled person, TextMate and Coda will produce rubbish. If you know what you’re doing with Dreamweaver, you can produce just as clean code—and possibly a lot quicker.

Raising awareness of web standards in the Dreamweaver community

I’m not a member of WaSP, but I’m passionate about web standards. Getting a Dreamweaver group off the ground is going to take a lot of effort, but I hope that it attracts a wide range of people who use Dreamweaver or are simply interested in web development. Although it will be important to show people the mechanics of using the program, I would like the topics discussed to cover web development and standards in general. When I teach Dreamweaver, I tell students to forget about the mechanics and to concentrate on understanding the markup that is being generated. Once you know HTML and CSS, using Dreamweaver falls easily into place.

Of course, some people might ask why London needs another group devoted to web development and web standards. After all, London Web and London Web Standards (LWS) are both well established and thriving. My hope is that the Dreamweaver Meetup Group can play a complementary rather than a rival role. Both London Web and LWS tend to gather large crowds, which could be intimidating for someone who is just starting out in web development or who has responsibility for maintaining a website as part of wider duties. I also hope that by showing people how to create standards-compliant sites in Dreamweaver, we can remove some of the unjustified prejudice against the program. Dreamweaver isn’t perfect, but nor is it the horror that some people portray.

The invitation to review the rival book came from the marketing department of Packt, the company that published it. I sent a polite reply saying that I didn’t think it would be appropriate for me to review a book that had an almost identical title to mine. I thought that would be the end of it. However, I received an email from Packt saying they knew I had written a book with an identical title, and that’s why I would be the perfect person to write an honest review.

At first I wasn’t sure whether to be flattered or horrified. It’s nice to think that I have such a great reputation for fairness that I would write a glowing review of a book that’s in direct competition with mine. Of course, there’s always the temptation to savage the book in public, but I would never want to do that to a fellow author. I know how much a bad review hurts. Since my book was published three months earlier (and was available even before that as Rough Cuts in the Safari Online Library), Packt can have no excuse for not knowing the title of its rival book was almost identical. I’ve no idea if the title was chosen as a deliberate spoiler, but asking me to review Packt’s book is rather like asking Coca Cola to endorse Pepsi’s latest offering.

I haven’t read the Packt book, which is written by David Karlins, an established and respected author. What I have read is David’s “Thoughts from the author” on Amazon.com. In it, he says you don’t need to know HTML, CSS, or JavaScript. In fact, you don’t even need to know what they are. That immediately tells me that our books take completely different approaches to the same subject. I think it’s a pity his new publisher has decided to muddy the waters with the confusing titles.

I firmly believe that to build a website, you need to have at least a basic understanding of the underlying technologies. Website development is becoming increasingly complex. Dreamweaver helps speed up development through dialog boxes, prepackaged widgets, and code hints; but if you rely solely on point-and-click or copy-and-paste techniques, you’ll remain severely limited in what you can achieve. My book is aimed at readers who aren’t afraid to dig into a bit of code. In fact, you’ll need to do so if you want to access features such as geolocation and web storage on mobile devices. I guide you through the code, explaining what it does so that you can adapt it to your own needs.

So, if you’re looking for a book on developing for mobile with Dreawmeaver CS5.5 with jQuery, HTML5, and CSS, make sure you choose the one that’s right for you. Don’t be confused by the titles. Oh, and as small bonus, my book is in full colour, even though it’s the same length and the same cover price ($39.99) as the one published by Packt.

$stmt = $db->stmt_init();
$sql = 'SELECT username FROM users WHERE username = ?';
$stmt->prepare($sql);
$stmt->bind_param('s', $_POST['username']);
$stmt->execute();
$numrows = $stmt->num_rows;

The code worked without error, so it wasn’t immediately obvious why $numrows was always 0. So, I checked the PHP documentation for mysqli_stmt::num_rows. The description is rather ambiguous in that it refers only to the need to store the result when using the procedural style, but the object-oriented example makes it clear that you need to call the store_result() method before accessing the num_rows property. When I changed my code like this, I got the expected result:

$stmt = $db->stmt_init();
$sql = 'SELECT username FROM users WHERE username = ?';
$stmt->prepare($sql);
$stmt->bind_param('s', $_POST['username']);
$stmt->execute();
// store result of prepared statement
$stmt->store_result();
$numrows = $stmt->num_rows;

At first, it seemed counterintuitive to store a result that I was going to throw away, but that’s how num_rows works with a MySQLi prepared statement. Thinking about it a bit more, it makes sense because if you use the MySQLi query() method instead of a prepared statement, you store the result in a MySQLi_Result object and get the number of rows from the result like this:

$sql = 'SELECT user_id, name, username FROM users';
$result = $db->query($sql);
$numrows = $result->num_rows;

Chapter 3 of my PHP Solutions, 2nd Edition makes for pretty heavy reading. So much so that I recommend stopping halfway through on the first pass. That’s why I skirted around the difference between parameters and arguments on page 43. But I’ve piqued the interest of Tom Flis, one of the participants in Boston PHP‘s self-study group PHP Percolate. He’s asked what’s the technical difference between the two words, so here goes. It’s actually quite simple.

When you define a function, the variables that represent the values that will be passed to it for processing are called parameters. For example, the following function definition has one parameter called $number:

function doubleIt($number) {
return $number *= 2;
}

However, when you use a function, the value you pass to it is called an argument. So, in the following case, $price is passed as the argument to doubleIt():

$price = 50;
$inflated_price = doubleIt($price);  // 100

It’s a pretty subtle difference. A parameter contains no value; it’s simply a placeholder for the value that will be passed to the function. An argument contains a value (even if it’s null or an empty string) that the function processes to produce a result. Because the meanings are so similar, many developers use the words interchangeably or always refer to arguments.

So, now you know.