Peter Wooley’s Blog

What George Orwell may not have realized when creating 1984’s Newspeak was that a language that could shrink rather than grow might actually be a good idea. For the past two years, Gilad Bracha and a few other folks have been working on a new programming language, called Newspeak, that might actually be able to start off with a mind-bendingly huge feature set, but do it all with just a few brilliant concepts and stay remarkably small in the process.

Josh, a co-worker of mine and a Serial Language Enthusiast, let me know about this new development. Part Smalltalk, a splash of Beta, a helping of Self, and a sprinkling of Pixie Dust makes this language one to take a look at. In Episode 140 of Software Engineering Radio, Gilad explained the concepts of the language. Three things jumped out at me:

1. Class hierarchies, as in Classes within classes within classes. Classes, Modules, Namespaces, and Mixins are all handled with the same construct. Top-level classes are Namespaces and you can have multiple instances of these as Modules—giving you side-by-side deployments—and Mixins come by default as all parent classes are dynamically set at runtime.
2. Dynamic Typing is used, which I love, but they’re working on implementing Pluggable Types, an optional typing system that will allow custom type grammars. Though, keeping a dynamic runtime, the types will only be checked at compile time, which is basically the opposite of ActionScript 3 running without strict mode.
3. Network Aware. The language knows the Internet, as indicated on the Newspeak homepage:
   

   …we believe in a notion of service oriented computing that allows for off-line operation and leverages the inherent advantages of client devices, while utilizing the strengths of the network.

For someone working on the web, this is exciting stuff. Going beyond simply being aware of the network, Newspeak will not only sync with data from the cloud, but with the entire application—running application code client-side. It’ll be like updating the latest version of TweetDeck through AIR’s update system, but only the modified application objects and data will be sent over the wire. Now this next part is purely conjecture, but as multicore processing will be a focus of Newspeak, an implementation of Erlang-style actors may not be out of the question, and hot-swappable code could make the entire update process as smooth as butter.

What I have to disagree with

From Episode 140 of Software Engineering Radio (starting at 2:06), Gilad says,

The real goal of Newspeak is to create a really nice environment where you can program for the  web without worrying about the web, without dealing with all the mechanics of different languages: CSS, HTML, DOM, Database back-end, whatever. In general, to create a language—not just to run in a web browser—but a language for a network world.

Hold it right there! Newspeak sounds like a great idea, but I’m not convinced it will allow people to “program for the web without worrying about the web.” If anything, this sounds like ASP.NET and its automagic markup, styles, and scripts that makes kittens cry. While the day may come when HTML will be treated as the Assembly language of the Web, we are far from it. With so many browsers, so many brand new ideas, and so much further to go in nearly every aspect, from content, accessibility, features, and speed, we’ll be lucky if we get there by 2030, when IE finally implements the CSS3 Template Layout Module.

By then, I will most likely be the old, cantankerous coot that still remembers the days when developers knew why you put the <script /> at the bottom and how to style a <ul /> to make drop-down navigation without JavaScript. But, with HTML5 still on its way and CSS3 being slowly implemented module-after-module, I doubt I’ll have to be very cantankerous anytime soon. Until then, I’ll be playing with a new language and seeing what this Internet fad can really do—even if it isn’t reinvented by Newspeak.

As you have no doubt heard, Tyler Sticka has announced that he will be leaving McAfee. Many of you know that Tyler and I attended the Art Institute of Portland together and, since then, we formed the first Interaction Design team at US Digital (along with Erik Jung), taught at the Art Institute of Portland, and were working closely on Enterprise software at McAfee.

Designing and developing with Tyler is an exhilarating experience. He’s quick, thoughtful, and engaging—and I know he’ll continue to go further as he takes his next step.

With our history, I imagine some might think I’ll be leaving to join Tyler in the near future. I want to say that, while working with Tyler is a ton of fun, I have no plans to leave McAfee. My current role has been, and is, an exciting challenge. With just over a month and a half under my belt, I’m enjoying both the people and code I get to develop with. The five day work weeks have been a little tough to get used to, along with the commute, but free soda and fast-paced, testable, continuously-integrated web development is awesome.

While we may not be working under the same roof, do not fret; professionally we are not done.

Recently at the Art Institute of Portland, I gave a presentation to my Advanced Scripting class on lessons web app developers can take from World of Warcraft. While playing one night, I stopped and pondered all of the things that just work. I began to consider why WoW was so wildly successful and thought about what I could take from my experience as a player and apply to web development. The presentation is hosted below, which will be most easily understood if coupled with the notes following.

What’s the big deal?

• World of Warcraft (or WoW) reached 11.5 Million active subscriptions before Christmas of 2008.
• The graphics engine was originally built sometime during or before 2001, making it around 8 years old.
• Nielsen reported that during 2008, WoW players played an average of 671 minutes (or 11 hours) per week.
• In the past week, the quest titled Jack Me Some Lumber was completed over 680,000 times.

World of Warcrafting Web Applications

• The basics of a Web Application and WoW are similar:
  • Each attempts to create an Internet-based experience where users are given functionality they would not have in an offline or computerless world,
  • Each is served from servers that can crash, software that has bugs, and tubes that can get clogged,
  • And each has the imperative of creating an experience worth their users time and, potentially, money.
• As WoW is one of my main non-web hobbies, I want to justify why I spend my time (Over 75 days, logged in) and money ($727.48).
• As I started to pay attention, the plethora of applicable lessons became obvious.

Take the time

• Blizzard first announced development of WoW in 2001, and released in November of 2004. Basically, three years.
• Development was well under way by 2001, so it is not unreasonable to assume at least a year of work had gone into it by then. Essentially, 4 years, if not 5.
• Lesson: Spending the time to do it right, even when others beat you to the punch, works quite well. (Save for Windows Vista.)

Use iterative design

• In the nearly 4½ years since WoW’s release, it has released two expansion packs and 18 substanial content patches.
• Each update has brought with it brand new content: locations, dungeons, enemies, gear, pets, and more.
• In the same way, gameplay has evolved immensely. The Talent system, which “can make your character a specialist in one of their available class roles, change their entire playstyle, and offer countless combinations for you to experiment with”, has been modified several times.
• During the beta, the entire system was ditched until a better one could be created.
• And all of this came with no apology. The developers of WoW changed the game in a way they felt was positive and defended it vehemently.
• Lesson: Change your app to make it better, and defend your decisions.

But!

Listen to your users

• Whether you’re just starting development or making your 7th version: involve your users.
• For every content patch in WoW, Public Test Realms are used to test out new game mechanics and features. And people are excited to help. The testers copy their character or use a pre-made one and play, knowing full well their progress will be wiped out by the time the patch goes live. But, it’s new and cool and fun—and they feel privileged to get involved before other people.
• During the development of Wrath of the Lich King, I got a picked randomly for a spot in the Beta. I loved it, I even bragged to my friends.
• I spent an entire evening running around the new continent, Northrend. Barely anyone else was there; it felt like I was the very first person to see it. It was awesome.
• Once I had run around, I tried playing the first Heroic player class: the Death Knight.
• Lo and behold, they had implemented a feedback system. Everything quest you were given in the game could be rated for ease-of-use, obviousness, and even fun. With that data, they modified quest explanations, changed quest rewards, updated the map, and made their application better.
• Lesson: Change your app, but base your decisions on real feedback.

Offer something addictive

• In my freshman and sophomore year of high school, I played Diablo II 6 – 8 hours per day. I had a good handle on my classes, so no one really noticed. And I was “working on my computer”, so my parents were cool with it. What I was discovering is the power of flow and addiction.
• As Diablo II is a Blizzard title, I couldn’t wait to see what they would come up with in the MMO space.
• Strangely, where Diablo II used the chance of finding better and better items to hook me, World of Warcraft used social networking.
• Don’t get me wrong, I loved leveling, doing quests, and getting better and better gear; but World of Warcraft actually slows you down, in those areas. Leveling takes longer than in Diablo II, there is no true power leveling, quests can be very, very long, and new items are more based on hard work than chance.
• What was encouraged, was connections with other people.
• It starts off slowly. Some hard quests suggest grouping with other people. A chat pane is always available, where people discuss everything going on (for good or ill). People can create guilds where groups of people can wear a tabard and have chat channel just for them. Dungeons (or instances) provide great rewards, if you can get 5, 10, 25, or 40 people to complete it together. And you can always talk directly to someone, no matter where in the World (of Warcraft) they are.
• The best part: WoW makes shy geeks, like me, cooperate with other players in ways they wouldn’t do in the real world.
• Lesson: Create something unexpectedly addictive, and introduce it slowly.

Customize, Embrace & Extend

• Customization of the game experience is essential in WoW.
• On curse.com, there are 3,993 addons to install, ecah modifying the user experience in their own way.
• Personally, I use 25 addons. One of which allows me to easily coordinate specific spells with other Paladins. Another makes the chat interface a little more usable with a timestamp, clickable links and color-coding. And another still throws everything that’s happening to me and everything I’m doing to others all around my character—so I try to comprehend it.
• In a recent patch, Blizzard introduced a new Calendar feature. Unfortunately, there were several addons that already served this function. Being rather bold, the WoW Calendar implemented several features the others couldn’t offer, such as always up-to-date holiday schedules, a tie-in to their external wowarmory.com, and a more unified look and feel.
• They saw a feature the community had made, and improved upon it. This ruffled feathers with the developers of the other Calendar addons, but they can continue to develop their addons and make them better—possibly pushing Blizzard to implement more functionality in their own feature.
• Lesson: Give your community tools to customize their experience, but don’t be afraid to work with them to better the core experience.

Make it less expensive

• World of Warcraft started at $50.00 for the original game. Over time, it dropped to $40, then $30. When The Burning Crusade was released, the original game could be found for $20.
• If you pay month-to-month, WoW costs 14.99 per month. If you pay every three months, it’s $13.99/month, and every six months is $12.99/month.
• If you buy WoW with both expansions today, it would cost roughly $80 ($39.99 + $39.99) for the first free month. If you bought the games when they were new, you may have paid as much as $220 ($79.99 + $69.99 + $69.99). Same games, 64% cheaper.
• Usable business models on the web are few and far between, but maybe consistent price drops on web apps over time could be the next big thing?
• Lesson: If you’re charging for your app, make it cheaper over time.

Make it pretty

• WoW is beautiful.
• It’s cartoony, colorful, and adorable.
• It uses a graphics engine that is pushing a decade old, but still pulls off some amazing scenes.
• Whatever you do, make your app a joy to use.
• Pay attention to how many clicks a user must make.
• Use eye candy.
• We all know that craigslist works well, but looks awful. It can still work well and look good.
• Lesson: Even with web limitations, make your app gorgeous.

I’m always interested to hear feedback. Let me know if you agree or disagree with anything I put forward here, or share lessons you’ve found in WoW.

“I can’t generate 1000 images—it’s not practical, I can’t use a server-side script—there’s the sandbox and it’s lame, but there has to be some way to just use JavaScript to generate pixel data,” I thought.

Since releasing Gmail FavIcon Alerts version 2.5, I’ve spent a ton of time trying to figure out how to make it better. Thankfully, users were more than happy to help. After talking with some friends, I realized that the key feature missing from all of the favicon message count scripts was dynamic unread message count—being able to know exactly how many messages you had by looking at your favicon. But, how could this be done? Embedding the images as base64 is how most of the scripts work, but base64 is lengthy, and storing 1000 iterations to give exact unread message counts up to 999 would be ridiculous in both size and scope.

Thankfully, while teaching the WDIM355 Client-Side Scripting class at the Art Institute of Portland, the students showed quite an interest in the Canvas tag. After playing with it for a bit, they detailed how they were using it. The methods currently available consist of things like fillRect(), strokeRect(), and drawImage(). It felt like Flash, but lower-level, geekier even.

It suddenly made sense: draw the unread count over the icon using the canvas tag! Starting on a Friday evening, I began. First, I drew a red square in the middle of  a 16×16 pixel Canvas, and it worked! I started drawing shapes, patterns and anything I could to test the speed and capabilities. I couldn’t have been happier. Then I hit a snag: images.

Working with images is never the best experience, but drawing them with the Canvas tag, it turns out, is just plain awful. Because speed is important, the script really needed to keep the images embedded. Base64 is great for that, but I discovered a little issue with the drawImage() function of the canvas: you have to supply it with a standard Image object or HTMLImageElement. This didn’t seem like a problem, until I started setting the Image.src to a Data URI. For some reason, I couldn’t get the images to load and I kept getting the NS_ERROR_DOM_SECURITY_ERR error. After quite a bit of searching, I discovered that, for security reasons, Image objects can’t have their src attribute set to a Data URI!

After nearly giving up, I took a break with my wife, and at some point during the break, I came up with a crazy idea: use fillRect() and a 16×16 array to draw the image, pixel-by-pixel. Crazy, you say? Loco, indeed. I spent the next hour writing the loop and adding each individual hex value into an array. I argued that writing a script to do it would have taken longer—I was wrong. After a bit of number confusion on my part, I got it working and it was beautiful. Literally, pixel-for-pixel, it matched. I had to take a minute to enjoy the hack that sat before me.

The last step was to add the numbers, which turned out to be the easiest part. I created a pixel map of Tyler’s pixel numbers, did some math and drew the background. Even though it took a bit more tweaking, I basically came out with the finished product!

It took plenty of hours, involved several people I’m grateful to, and was some of the most fun I’ve had hacking since I first picked up the script! And now, the script has now been featured on Lifehacker twice, for 2.5 and now 3.0! And it just past 8,000 installs!

After watching Tyler give his This is Not a Graphic Design presentation (which I wrote about), I got to thinking about the horror that is presenting. I worry a fair amount. I can totally believe that Laurence Olivier would throw up before each performance. However, I really do love presenting. I suppose I am teaching a class at the Art Institute and I have and do present and show-off my portfolio to clients and on-lookers whenever someone will look. Granted, what excites me enough to share and teach is oft more technical than most, but they’re things I would have enjoyed hearing (then I could have learned them earlier!) and I think others would too.
With that solidly in my mind, I began to think about what gets me up the morning, why I love going into work at US Digital, and how others might benefit from it. Since Wednesday night, I’ve been rolling the idea of talking about the LAMP stack. Granted, at work we’re not using all the correct applications (our M is MSSQL not MySQL), but I’ve worked with true LAMP, WAMP, and several other unmentionable stacks, and there’s a small project that I’ll be dedicating some time to that will be using it to LAMP to its fullest.

Obviously, the LAMP stack is nothing new to many developers, but I do believe people miss the benefits and power of Linux and especially Apache. Along those lines, I’d want to expand the talk to not only LAMP, but building the perfect workflow: from using Subversion (or other SCM software) to VNC to Mantis Bug Tracking to PEAR to PECL and all of the things that I believe make the perfect Web stack.

What do you think? Would you care to listen to how to build the perfect Web stack from the ground up? If so, let me know in the comments!