dan-menard.com

Adobe is changing. The once-great giant of web and web tools has fallen, and is poised to rise again — albeit in a much different form. What does this mean for us web developers?

For starters, let’s go over some recent news. Adobe made three major announcements in the past six weeks that will have sweeping implications on their image. See if you can spot a trend in these headlines:

• On October 3rd, Adobe acquired Nitobi, makers of PhoneGap.
• On November 9th, Adobe announced that they will cease development of Flash Player for mobile to focus on HTML5.
• Two days later, Adobe announced that Flex is going open-source.

What do these press releases have in common? If you caught that all three are about open technology, give yourself a pat on the back. Let’s dig into the facts before discussing the ramifications.

Adobe has seen the light, and open source is sparkling.

Closed formats are dying across the web. The days are numbered for plugins like Silverlight and Flash; they’re simply not necessary anymore for the vast majority of sites and applications. HTML5, on the other hand, is thriving. We’re starting to see open fonts pick up, and even longtime-stalwarts MP3 and MPEG-4 are starting to lose their grasp of the online audio/video markets.

Adobe isn’t blind. They know they need to transition away from closed platforms. Picking up PhoneGap shows their commitment to this cause.

Re-aligning their mobile efforts towards HTML5 is another positive step towards open technology. Adobe still makes some of the web’s best tools, and Javascript development could seriously use an outstanding IDE. This seems like a great match-up.

Finally, releasing Flex to the community is a smart move. There is a very vibrant community around Flex, and there are still niches where RIA will matter for a little while longer. If Adobe can’t support Flex on its own, enabling the community to take control of it’s own future simply makes sense.

Adobe’s intentions are clear. Proprietary formats are out, the open web is in.

What does this mean for web developers?

Three things:

First and foremost: Learn your shit. If you’re a web developer, learn everything you can about Javascript, HTML5, CSS3, and the myriad of related frameworks. These will only become more important following the fall of Flash.

Second: If you’re a Flash/Flex dev, start looking at Sencha. At SenchaCon last month, the number-one answer I got back when I asked people what they worked in before switching to Sencha was Adobe Flex. And I believe it. I’m a Flex guy too, but that market’s shrinking quickly. Sencha is going to be a major player on the web for a while to come, and it’s a relatively smooth transition.

Third: Get into mobile. Adobe didn’t pick up PhoneGap just to gain FOSS-cred. Mobile is huge. Huge! This is where you want to be right now, and you can join in using Javascript and Sencha and many other web technologies.

This is an exciting time to be in web development. Let’s keep on top of the constantly-changing platforms and tools. Let’s keep building wonderful things. Let’s make this an age to be proud of when they talk about the day Adobe changed their ways.

Who’s with me?

Well, a little something like this:

Image generated using Wordle. Click to enlarge.

Beautiful, isn’t it?

This is a cloud of the most commonly used words in my timesheet entries for a project I worked on over a six-month period. (When you work at a services company, you have to log all your time using archaic worklog software that only works properly in IE7 and below.) Size represents frequency, so the bigger the word, the more I used it to describe what I do.

It’s quite telling.

I’m happy to point out that patch is my most-commonly used word, followed by reviewed. We’re religious about code review at Macadamian, and it’s awesome to me that this is spelled out so clearly in my notes.

Something I’m not as proud of is that tests is a tiny little speck (above the V in reviewed). It’s beaten out by crutch words like etc and sure. Worst of all, we had unit tests set up on this particular project (front-end and service-level). Why did it have such little impact in my notes? This is something that I think I should be spending more time on.

It’s rare to get such a clear glimpse of what my priorities are. I spent nearly 1000 hours of my life on this project, and in one simple image I can see where all that time went. It’s both humbling and encouraging to get this sort of perspective.

What do you think your cloud would look like?

Software architects are a strange breed.

They obsess over code quality. They can’t explain anything without a whiteboard. They adore design patterns that most of us have never even heard of.

When the project is in trouble, they swoop in and save the day.

And they constantly reject my patches.

But I’m thankful for that — all of it. I’ve been fortunate enough to work with some really, really great architects in my (admittedly short) career, and through it all I’ve managed to distill the one skill possessed by every great architect I’ve ever met:

The ability to identify potential pitfalls.

Expecting something more dramatic? Well, tough luck. I know it’s not sexy, but if you want to be a great software architect someday, you need this skill.

Here’s why:

Pitfalls are easy to spot when building a room.

The wife and I are currently finishing our basement. I’m learning a lot during this process, like how to make sure a wall is straight, and the joys of using a ramset.

And of course while I’m swinging that same old hammer into about the fiftieth 3″ nail, my mind starts to correlate what I’m learning about building a room to what I know about building software.

The biggest realization so far?

In simple construction, spotting potential problems is very easy.

If you line up a 2×4, you’re going to notice if it’s not the right size. Measure again, cut again. Problem solved.

If you have to extend some piping, it’s easy to grok the current pipe system and figure out where to make a cut. Plumbing refactored, job well done.

If you’re about to fire a nail through a plank of wood to affix it to the floor, it’s easy to visualize that you’ll have trouble cutting out a doorway there later. Nobody wants to hack through molten metal, so put those nails around where the door is going to be. Crisis averted.

In fact, it’s so trivial to see problems in advance that we’ve yet to make any major mistakes. This is amazing to me! Can you imagine saying anything like that about a software project? (Even a small one?)

Of course you can’t. And you already know why:

Pitfalls are nearly impossible to spot when building software.

How many times have you had to refactor some code you wrote last month, because it wasn’t up-to-snuff? Or had to completely re-write a feature that you implemented earlier in the project?

Seeing potential pitfalls in software is hard.

You would never build a cutting-edge webapp, then turn around and brag about how you got everything right on the first try. Your fellow developers would think you’re crazy, and your QA wouldn’t be able to stop laughing.

Every software developer makes mistakes all the time. Functions that aren’t quite single-purpose, dependencies that aren’t strictly necessary, routines that are a little too verbose. And we always end up paying for it later. Who will save us from this madness?

Architects, that’s who.

Great software architects mitigate rework and lost time by identifying pitfalls in advance.

They can look at a framework and tell you if it’s too abstract or not abstract enough. They can examine an existing codebase, and have a pretty good idea of where to start refactoring. They can tell when a new patch is going to break a valuable design pattern, or introduce inconsistencies into the codebase, or need to be re-written before the end of the next sprint.

This skill, this ability to look at some seemingly-harmless change and intrinsically know what problems it will cause later — it’s amazing. I don’t understand how they do it, and I don’t know if I’ll ever acquire that talent.

But I know it’s something I admire. And if you ever want to become a great software architect, this is the one thing you need to get right.

Now if you’ll excuse me, I have to go fix up my latest patch…

The last day of SenchaCon was a hackathon, where everyone that stuck around (probably over 100 people) grouped together and hacked away to see who could make the coolest one-day project. There were a LOT of great apps, and several came away with cash and prizes (all of it very well earned!).

Not featured in the winners list is the app I made, because I missed the submission deadline by about twenty minutes. All this because I lost far too much time debugging issues with HTML5′s native drag-and-drop API. (I was planning on writing a rant about it, but Quirksmode beat me to the punch.)

In any event, I’ve uploaded the incredibly raw creation, and you can now play my simple HTML5 Video Puzzle Game. I only tested in Chrome, but it seems to run alright in the latest Aurora build of Firefox. Basically the app loads up an HTML5 video, slices it into 16 canvases, and scrambles the pieces. Your job is to re-arrange them by dragging them back into place (using HTML5′s native drag-and-drop, of course).

It’s really, really unpolished. I spent all of about 8 seconds on the styling, and there are a lot of features that are complete but inaccessible (like slicing the video into more pieces). I might try to fix it up later.

Anyway, the whole day was a lot of fun, just like the rest of the conference. It would be awesome to go again next year. We’ll see!

Until then, happy hacking, all my fellow attendees!

Most Sencha Touch applicaions are small, single-purpose mobile apps. Those aren’t the ones I’m talking about.

Over the past 9 months, I’ve worked on a Sencha Touch app with a team of 15 people. It’s for a major, world-famous client. It contains tens of thousands of lines of code. It could be the biggest Sencha Touch app ever built.

My talk will be about how we built it, and how we made it perform well despite the sheer size of the application.

If you’re at SenchaCon, and this sounds like something you want to know more about, here are the details:

Time:
11:35am — 12:20pm

Session Name:
Community Code: Macadamian

Location:
Grand Ballroom, Section 3, 6th Floor

Hope to see you there. I’ll be the guy glowing with enthusiasm :)

Click for full size.

We had a great time.

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. This week’s post was the first to be published after the switch to regular, weekly updates. Here it is again, better than ever!

2009 was an exciting year for the web browser crowd:

• Google released Chrome.
• Apple ported Safari to Windows.
• Firefox picked up a lot of market share.
• Microsoft actually produced a half-decent version of Internet Explorer.
• The iPhone and Android finally made mobile browsing popular.
• Support for HTML5 and CSS3 was way up across the board.

The term crowd is especially appropriate here because it really is starting to get very crowded. For a long time the browser war has been fought largely between two major players at a time (IE/Netscape, IE/Firefox) and all of a sudden we have four major companies with fantastic browsers available to the vast majority of users.

Oh, and then there’s Opera.

Here’s the thing about Opera…

Opera is in serious trouble because it doesn’t have a “thing”:

Internet Explorer’s thing is its existing market share. It has a lot more users than everyone else, so its going to be relevant for the foreseeable future.

Firefox’s thing is its community. Not just its core developers, but the people who create addons or personas or rally everyone they know to go download the latest version on launch day. It’s easily the most passionate user group of the bunch.

Chrome’s thing is its brand. When people think web, they think Google. Google has the best search, the best email, why not the best browser? Users rely on Google for a great online experience, and Google has a lot of high-traffic areas where it can push Chrome.

Apple’s thing is its loyalty. Apple fanboys are a loyal bunch — most of them will stick with Safari on their Mac and many will consider getting Safari for any Windows computers they’re forced to use. Apple also has the iPhone, which gives it a growing space where it has the only browser (not that any iPhone users mind — loyalty, remember?).

What does Opera have? The Wii? Please.

• It used to be the most advanced browser for HTML5 support, then everyone else caught up.
• It used to be a major player in the mobile space, then Apple and Google obliterated it.
• It used to be a fun browser for geeks to talk about, but now the buzz is all Chrome.

Simply put, it’s not enough to be an alternative to IE anymore; users are demanding more from their browsing experience, and they’re flush with places to find it.

Any Opera fans out there?

What’s even worse is that there isn’t really anything you or I can do to help.

Opera’s engine isn’t open source, like Gecko (Firefox) or Webkit (Chrome/Safari), and it doesn’t benefit from a strong plugin community, like Firefox/Chrome. It isn’t an OS-default browser like IE (Windows), Safari (OSX) or Firefox (linux). Even if I wanted to rally some Opera enthusiasts, where would I start? How many people do you know that have even heard of Opera?

I don’t have anything against Opera (it’s a fine browser), it’s just it has fallen behind the times — there are too many better options around preventing Opera from picking up new users, and I can’t think of a single significant reason for its existing users to stick with it.

Do you use Opera? Care to share any thoughts on Opera’s future?

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. Like last week’s resurrection, this is an old favourite of mine, updated for your reading pleasure.

One of my favourite things about New Year’s Eve is making resolutions. You know, those promises to ourselves that we can never seem to keep.

I like this ritual because I like setting goals for myself. One of my resolutions for 2010 was to have a new post up every Monday (a tradition I’ve kept to this day). I made other resolutions that year as well, and as ridiculous as it sounds, by March I was already planning resolutions for the following year.

That’s when it hit me:

Set goals more than once per year.

Why wait until some arbitrary holiday to set goals for yourself?

You can set realistic, helpful, attainable goals right now. And they don’t have to be scoped to a full year, either.

Mix it up and have some that are month- or week-based. Short-term goals are easier to keep, provide benefits right away, and can help build confidence to hit more lofty goals that take a bit longer to reach.

Here are some goals that I’ve set for myself recently:

• (for 2010) Write a blog post every Monday.
• (for March) Cook breakfast every morning.
• (for this week) Get up every day at 6:30am.

Each of these goals has taught me something interesting.

I’ve learned that writing blog posts gets easier the more you do it. That cooking a full breakfast helps me sort out my day (and is delicious). And that I am absolutely not meant to be up at the crack of dawn.

This brings me to my next point:

It’s ok to fail.

Many of my goals don’t play out exactly as planned, and sometimes they get completely cancelled if they turn out to be terrible ideas (6:30 mornings, I’m looking in your direction).

The point is to experiment and see what works for you.

Instead of becoming discouraged when you’re consistently not hitting a goal, pause and consider if this is really a goal worth pursuing. Did you over-estimate how much you could do? Is there a better way to get the result you were after?

Often it’s the goal that is the problem, not you.

Here’s how I hit my goals:

I use a few simple tricks to keep up with whatever goals my past-self may have signed present-me up for. This is what works best for me:

First and foremost, I try to be realistic. It won’t do me any good to set a goal that I won’t be able to reach, so especially for goals that are more than a week long, I’ll run my idea by someone I can trust to give me honest feedback.

This way if a goal is too ambitious, at least I’ll have a red flag telling me that I may need to adjust my targets. Of course, ultimately I know best; if I really think I can do something, I’ll still try it even if the feedback I’m getting back isn’t all roses.

Second, I find it helps to tell people if it’s an interesting goal (like breakfast). Maybe they’ll want to do it too, which makes motivation easier, or maybe they’ll pressure me into remembering to do it, which is nice when needed.

I find this works really well for me, for certain types of goals. However, it seems my opinion on this subject is not very popular. Your mileage may vary!

Third, I find it’s important to give myself visual reminders of my goals.

The tool I use most for this is a web-based task-management application called HiTask. For my month-long breakfast experiment, for example, I added a task to HiTask with a flashy-coloured label and a star, so that it really stuck out and was always at the top of my to-do list.

Low-tech works as well: At the start of the year I printed out a grid of every Monday in 2010, broken down by month, so that I could check them off after publishing each weekly post.

Does any of this sound useful to you?

I’d love to hear about what’s helping you hit your goals right now. What tools do you use? What strategies work for you?

If you haven’t set any goals for yourself lately, why not start now?

(What do you have to lose?)

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. It’s the first of three posts from the early days of the blog, dug up from the archive and polished ’til good as new!

Ladies and gentlemen, allow me to share with you a tale of two photographers.

Back in the summer of 2010, my fiancée and I were featured in a piece for our local newspaper. The columnist wanted an image to accompany her content, and sent a photographer to our apartment to take a photo of me and my soon-to-be bride.

The photography session played out as I’d expected. Some nondescript ‘dude’ with a camera sauntered in, looked around the room for all of about six seconds, arranged a semi-interesting shot involving a mirror, snapped a few pictures and left. Took around ten minutes.

A few days later, the writer called back and asked if she could send over another photographer. Apparently the shot the boring fellow took was too similar to a shot the newspaper was running on another article — on the same day, in the same section — so they needed a different one.

The second photographer was Christopher Pike.

Christopher ran things a bit differently. After introducing himself, he spent a few minutes looking around our humble abode and the surrounding area. He then asked what my fiancée and I thought of a few potential shots, and started taking pictures.

Many pictures.

We posed on our balcony. We posed on a bench. We posed near a wall, and then next to a fence. Every time Christopher noticed something that might make for a cool shot, he asked if we wouldn’t mind another photo.

After about an hour of this, he thanked us and left.

Like the first photographer, Christopher was a freelancer hired by the newspaper. Presumably, the two of them were each paid the same amount for their work. But while the former spent ten minutes taking a picture he had decided upon in advance, Christopher spent seven times that long experimenting and looking for the perfect shot.

What does this have to do with programming?

Just like photography, programming is a craft.

That first photographer, the one whose name I couldn’t be bothered to remember, was just in it for the job. The columnist wanted a cute photo of a young couple, so our unremarkable photographer snapped an equally (un)impressive shot, and left.

This is how unremarkable coders look at programming. You need a function that converts X inputs into Y outputs? Sure. Let me whip up a quick algorithm that does that. Done. What’s next?

Christopher, on the other hand, was there to take great pictures.

He was passionate, and he approached photography as a craft. Yes, the result was still just a photo to sell to a newspaper, but believe me when I tell you that’s not why Christopher is a photographer.

Here’s how I look at coding (and hopefully how you do too):

You need a function that converts X inputs into Y outputs? Ok. Let’s first consider the context, ask a few questions, then create a proper solution. Functionally, it may be the same as Joe-first-photographer’s solution, but a programmer that cares about his craft took the time to:

• Verify that a single function is in fact the best solution.
• Keep future maintenance and extensibility in mind.
• Write clear, reusable code.
• Add useful comments when necessary.
• Refactor the function to be as simple as possible.
• Switch spaces to tabs to match the existing code-base.

Which photographer would you rather hire?

Which programmer would you rather have on your team?

Later today I shall board a plane bound for Europe.

I won’t be back for a full three weeks. But fear not! While I’m out gallivanting about, amidst fine architecture and breathtaking scenery, you will not be left without updates.

Introducing Classics Week(s)

It occurred to me that this blog has been around for a couple of years now, and not all of you were here in the beginning. You’ve probably missed some great posts!

This is unacceptable, and I’ve devised a solution:

Every Monday for the next three weeks, this blog will feature a re-run of a classic post from the early days of its existence.

I’ve selected three of my favourites and given them a quick sprucing-up. I tried to choose a matching set of posts; the goal was to reflect the general content of the blog. In any event, you’ll have something nice to read, and that’s what counts.

The only internet-capable device that will be near my person for the duration of this adventure will be the wife’s iPod Touch, so I’m not expecting to check my mail very often. I’ll also be slow at approving and replying to comments, and you won’t see much of me in my other haunts.

This does not mean you should avoid emailing me and posting interesting tweets. Quite the contrary! I look forward to conquering a content mountain upon my return. Heaping piles of hypertext and prose!

Like a little ASCII version of the alps :)

See you in mid-October!