Most of the time, we think about cloud computing in terms of IT operations, here is a short demo I did for Skytap that illustrates how the cloud can be used for developers.

Skytap Demos

In my earlier post about the NASCAR joke, I mentioned that a ‘colleague’ passed this joke on to me ...

That colleague was actually Dan Fernandez (http://en.wikipedia.org/wiki/Dan_Fernandez). Those were fun years - Dan sent that story around our group and it totally saved me, thanks again! As negotiated, 20% of all speaking engagement profits and a lifetime supply of pixie stix

Hey guys,

We just started a fun new project that I wanted to tell you about. Windows Presentation Foundation is a framework from Microsoft for building really rich, dynamic applications. It has been out for a few years and it really powerful, but it is kind of intimidating. There are many, many new concepts, so it can be hard for developers who are used to Windows Forms to just pick it up. What we’re doing is an open-source project to create a tool that converts between these technologies.

We've posted the project to CodePlex: http://wf2wpf.codeplex.com, please check it out if you get the chance. We are in the early stages of development, so please be patient, there are many cases we can't translate just yet.

Thanks!

Eric.

Hey guys,

As you may know, I tend to use a lot of Amazon Web Service technology when building demonstrations. It really helps to be able to spawn computers quickly, have a lot of storage and/or send Internet-addressable messages.

So, what I've done is consolidate the knowledge of AWS that we've built up over the last few years and started putting them on a new site: http://www.learnaws.com. If you have a chance, please do check it out.

Thanks!

Eric.

The Wounded Warrior Project is an organization that helps empower and honor wounded soldiers returning home from their duty. At WonderAffect, we are trying to help out by offering free, volunteer-driven computer programming classes.

The folks over at the Wounded Warrior Project just graciously posted a notice on their site about this class.

At this point, it is kind of an experiment. I've always enjoyed training, so I figured this might be an interesting way to help out. What I'm hoping to do is host a class or two a week for a handful of Wounded Warrior students. Hopefully, this training will open up a new career path for these veterans.

Thanks!

Eric.

Over the years, I’ve tried to refine the process by which I work with my clients to build their demonstrations.

I put out a document describing this process at http://wonderaffect.com/wondermethod. If you have a chance, please have a look, I would love to get your feedback.

Kigen Motors” is the name of a fictional company that WonderAffect created as part of a demonstration for Amazon Web Services; the definitive cloud computing solution on the market today.

Amazon Web Services (AWS) seems too good to be true.

With AWS, you get unlimited computing power, unlimited storage, unlimited messaging and an Internet-sized database at your beck and call. And the best part is the price. You only pay for what you use. The cost can be as cheap as a thousandth of a penny for sending a message, or 10 cents for an hour of CPU time.

But, those in the technology industry this can be a very difficult concept to understand and appreciate. What exactly does one do with unlimited computing power? And how does that help my business?

That was the challenge that brought Amazon Web Services and WonderAffect together.

There are numerous abstruse academic problems that lend themselves very well to Amazon Web Services, but WonderAffect wanted to tell a very simple, clear story with AWS that everyone in the technology industry could immediately appreciate.

The story goes like this…

A fictional company called ‘Kigen Motors’ wants to start a grassroots advertising campaign called ‘This is how I drive’. The idea behind this campaign is to have Kigen Motors customers submit videos of themselves driving Kigen Motors cars. These videos would be part of a mosaic on the Kigen Motors site.

This scenario presents a few very interesting problems that are deftly solved by Amazon Web Services.

1. First, the web site itself needs to be hosted somewhere. Amazon’s Elastic Compute Cloud (EC2) is ideal for this purpose. When combined with Amazon’s Elastic IP, you can literally have a scalable web server solution with a permanent IP façade in less than 10 minutes.
2. Any kind of video taken by a digital camera or camcorder has to be first optimized for the web. This process is computationally very expensive and can take upwards of a minute for even a short video. With Amazon EC2, you can scale the amount of computing power with amount of incoming demand. As the demand increases, you simply add more computing power. As it subsides, you dial down the amount of computing power. All the while, you only pay for the computing power that you actually use.
3. Any kind of media requires a lot of storage. With Amazon S3 and SimpleDB, you can have as much storage as you need – S3 provides the unstructured storage while SimpleDB provides structured, easily query-able data storage.

The “Kigen Motors” demonstration is a great example of the type of work we really enjoy and excel at doing – helping companies connect their innovations with customers.

I came across this blog post today, and it made me think of perhaps what might be the most accurate metric of software development:  WYSOT (what your significant other thinks).

The blog article that caught my eye was entitled "The smoothest end game ever… but why?" It is from the Rational Team Concert team blog; the opening paragraph is quoted below:

"About a month ago, my wife, who has lived through 20 years of software deliveries with me at IBM, turned to me and asked “Aren’t you guys shipping Rational Team Concert real soon now? You don’t seem nearly stressed out enough - is it still happening?” I assured her that we were still shipping on time, but that, for some reason, this was the smoothest delivery I had ever experienced."

Their WYSOT measure must be pretty good; if you can keep your significant other happy during a ship cycle and still ship on time, then your software development process must be pretty solid

 

DevPay are two billing/payment services that Amazon has offered for quite some time. However, I recently ran across a great example of how these two services complement each other, so I wanted to share.

First, let's talk about Amazon Web Services in general. Amazon made its name by being the first major online book store. From there, they expanded to sell other items. Nowadays, you can find just about any consumer good imaginable for sale at Amazon. As part of this expansion, they enabled other people to sell their goods too. By opening a web store with Amazon, you can take advantage of Amazon's infrastructure (i.e. billing, delivery, categorization) as well as tap into the tremendous traffic that Amazon.com gets on a daily basis.

What Amazon gets in return for letting people use its infrastructure is a small cut of the sale. This must be generating a nice stream of revenue for Amazon. In 2002, Amazon launched a new initiative that expanded the way a person could leverage Amazon's infrastructure. This was collectively known as the Amazon Web Services. Services were rolled out over a number of years, but today they offer the following:

• Amazon Elastic Compute Cloud (EC2)—unlimited computing power, you pay per CPU hour per month
• Amazon Simple Storage Service (S3)—unlimited storage, you pay per GB per month
• Amazon Simple Queue Service (SQS)—very similar to MSMQ or MQServices, but you pay per message per month
• Amazon Simple DB—Internet-sized database in the cloud, you pay per GB per month

Those are the major infrastructure services, you can see a complete list at http://aws.amazon.com/. Anyways, with 2 of those services, S3 and EC2 there is an opportunity to make some money

EC2 charges about 10 cents per CPU and S3 charges about 15 cents per GB per month. There is some variation on the pricing of EC2 because you can decide what kind of computing resource you want (i.e. dual-CPU, more RAM, etc) and those extra options cost a little bit more. Similarly, the amount of data you transfer in and out of S3 effects the cost a little bit too. But, for the purpose of example, let's say that EC2 costs 10 cents per CPU and S3 costs 15 cents per GB.

For those prices, you get basic functionality. With EC2, you basically get a Linux machine. There are a number of image templates (called Amazon Machine Images or AMI for short) that you can choose from. The most fully-loaded image is one with Apache and MySQL installed already. With S3, you get storage you can use. Amazon does not give you a UI, but there are plenty of free community tools available.

For most people, that is all they need. But, there is an opportunity to add value; this is where the money making happens. First, let's talk about Amazon DevPay. What DevPay allows you to do is add a surcharge on top of what Amazon charges for EC2 and S3. So, if Amazon charges me 10 cents per CPU hour, I can use DevPay to add an additional 40 cents. So, when someone uses an AMI that I have associated with DevPay, they will be charged 50 cents per hour; I get 40 cents and Amazon gets 10 (roughly speaking, there is an overhead charge for DevPay as well). The same is true for S3. I can add an amount on top of the 15 cents that Amazon charges and collect that from people who use my S3 storage (called buckets).

What people are doing with this is adding value and collecting money. For example, companies like Redhat (see their cloud solutions) and Oracle (see their cloud solutions are taking advantage of this. Redhat has configured an Amazon AMI with their JBoss Enterprise Application Server. If a customer wants to use it, they are charged about $1/CPU hour. I haven't used JBoss myself before, but presumably a fully configured, hosted version of it makes the cost worthwhile. Oracle is doing the same with a subset of their database offerings. Some people have called this approach selling software appliances.

I think this software appliance model is very interesting. It's a good middle ground between hosting and on-premise software. Some people are not comfortable with multi-tenant hosting. By "multi-tenant", I mean sharing an instance of software with other users. Of course the advantage to hosting is that you do not have the capital expenditure of buying servers and you don't have to hire administrators to keep them running. With the software appliance approach, whatever software you are running is yours, so you are not sharing it with anyone else. You still get the advantages of hosting because the machine is being monitored by someone else (Amazon in this case).

Where does Amazon FlexPay come into the picture? Amazon FlexPay is more a traditional payment system, similar to PayPal. One unique feature is it can process regular monthly payments. So, imagine if you are Redhat or Oracle and you are offering your software appliances. You can happily collect your $1 per CPU hour. But, that kind of revenue is not very predictable. I might make $1000 one month if everyone is running their appliances, but nothing the next month if everyone shuts them down. So, what these guys are doing is also charging a monthly rate. So, to run a perfectly configured JBoss Enterprise Application Server from Redhat, I need to pay $20/month, as well as $1 per CPU per hour (these are rough figures). Again, I have never use JBoss so I don't know if this is reasonable or not.

There are literally dozens of companies doing this for S3 as well. Most of the backup services like Carbonite and JungleDisk both use Amazon S3 as their backend storage. They are adding value by taking the generic storage that Amazon offers and focusing it on specific scenarios. When you sign up for Carbonite, you get a service that trickles your data to Amazon S3 for backup; with JungleDisk you get a drive that looks like any other drive on your system, but it is persisted to Amazon S3.

I think Amazon's payment systems and infrastructure services are some fascinating ways to make money so I wanted to share.

I’ve been fascinated with Amazon EC2 for a while now. As you probably know, it provides grid computing in a way that is accessible to everyone. There are no complicated agreements to sign, just swipe your credit card and pay per CPU-hour. Use as much as you want, just pay for what you use.

Currently, Amazon EC2 offers Linux and Solaris images, but they just announced that they will be supporting Windows Server in the near future:
(http://aws.amazon.com/about-aws/whats-new/2008/10/01/amazon-ec2-running-windows-server-coming-soon/).

 

Just a quick post to share some information. If you are trying out the new Google Chrome browser, you’ll probably quickly notice that it does not support Java out of the box.

The link below details how to do it:
How To Run Java Applets Including Yahoo Games and Yahoo Chat in Google Chrome?

Thanks!

Eric

 

Blist is a Seattle-based start up that is really trying to shake up our perceptions of databases—particularly consumer-focused databases.

The software has always been easy to use; you just create a Blist and drag and drop columns to represent the data you want to store. Just recently, they previewed an API that enables you to publish your Blist.

I've been dabbling in Linux lately, so I thought this would be a good excuse to use a Blist. Obviously, I'm just starting, but if you have any suggestions, please add them as comments and I'll get them into my Blist.

There is nothing better than giving a demonstration in person, tailored to the audience, but that isn’t always possible. 

This is especially true if you are trying to reach a really wide audience. With the right approach, you can build a really effective video demo. The video above is a great example—simple, clear, and there isn't even a single line of dialog.

Disclosure – WonderAffect was not involved in the production of this video in any way. I simply found this while looking for a case for my new iPhone.

 

A few years ago, I was getting ready to deliver the demo for a keynote presentation at VSLive! in San Francisco.

I was demonstrating a pre-release version of Team Foundation Server (TFS). The particular build of TFS I was using had a very peculiar bug. If it sat running for a while, it would throw an exception and put itself in an inoperable state. After a few times, I got pretty smooth at resetting TFS; I figured I could do it in about a minute.

 

Anyway, on the day of the keynote, I set up my machine, warmed it up, and then sat backstage, waiting. Based on the presentation slide deck, my demo was pretty early on, so I thought I would be able to avoid the bug.

As it turned out, the start of the presentation was delayed a bit, and the introductory speaker ran a little bit long. When I was called up to do the demo, it had been just over 1/2 hour; as I performed the first step of the demo, I could tell that TFS was hosed. That's not a great feeling.

Luckily, a colleague of mine shared a joke the other day, and it came to mind. The joke starts with:

"What do NASCAR and technical demos have in common?"

After some furious fiddling with TFS, I delivered the punchline:

"People never talk about the speed, the power, or even who won. They just talk about the crashes they saw."

The audience that day was particularly charitable, so I got a good chuckle out of the crowd. That bought me enough time to get TFS up and running and continue with my demo.

The two lessons I learned that day were:

1. When you prepare your demo machine, let it sit for a while and see if anything goes wrong. Software, particularly pre-release software, has a funny way of going bad when you let it sit.
2. Keep a joke or two handy; you never know when you'll need one.

 

Sometimes the best way to figure out how we can help is by getting in touch. Please send us a message and let’s see if there is way we can help you accomplish your goals…

Eric Lee has delivered great demos, bad demos, and demos of products that don’t exist.

While on stage, he has experienced applause, heckling, computer crashes, and malfunctioning keyboards, and had the chance to deliver one really good joke about NASCAR.

In 2008, after 8 years at Microsoft—where he built demos for executives like Steve Ballmer, Eric Rudder and S. Somasegar—Eric Lee founded WonderAffect. He likes to think of his fledgling company as the world’s first software special effects company. In the same way that Hollywood movies use visual special effects to tell their story, WonderAffect uses special techniques to help companies tell engaging and convincing stories with their software. We call our approach to build demos the WonderMethod.

Sometimes the most effective demos are the ones your customers never see.

In the early 1990s, Mercedes-Benz was struggling to keep pace with its sportier rival BMW. Management believed the problems they were having were simply marketing and sales related. 

There are few things more pressure-packed than the need to build a product demo for a Steve Ballmer keynote.

That is the situation that a group of product managers from Microsoft found themselves in when they contacted WonderAffect. Within a few weeks, WonderAffect built a polished, fail-proof demo that was delivered on stage with Steve Ballmer at the Microsoft Office Project Conference in October of 2007.

As Skytap emerged from stealth-mode in early 2007, they needed a partner to help introduce their revolutionary hosted, virtual test lab service to the market.

Skytap chose WonderAffect to help them define a scenario, and build compelling product demonstrations and videos.

Building a good demonstration is really about telling a story; in that sense, it is very similar to screenwriting, or any type of writing, for that matter.

"Stasis equals death" is a concept that found in a book about screenwriting (Save the Cat by Blake Snyder) that helps writers ensure they are telling an engaging story. The idea is that the current situation cannot be, something must be done to change it.

The video above is a dramatization of this concept. In this example, an asteroid is hurtling towards a city; obviously something has to be done. This context gives the storyteller an easy opportunity to introduce a hero to save the day.

When we build a demonstration, we are essentially trying to do the same thing. We are trying to set up a situation where it is clear that something has to be done. The more dramatic the situation, the more engaging our demonstration is (within reason of course).

Sometimes, when looking for those dramatic situations, we can use real-life events for inspiration. For example, in 2007, a truck ran off the road and knocked out one of Rackspace's data centers in Dallas, causing a rare disruption of service for Rackspace (thankfully nobody was physically hurt).

If we were building a demonstration for a data recovery or failover technology, a runaway truck is a great stasis situation. We would have to let our audience use their imagination to set the stage of course, but it would be immediately clear how important data recovery/failover is, and it gives us a clear opportunity to demonstrate how heroic our technology is.

Applied to demos, "stasis equals death" really boils down to imagining a scenario where your technology could be applied, and then asking yourself the question: "What happens if my technology is not applied"? When the answer to that question is something terrible—data is lost, a company goes out of business, a vast amount of money is lost—then you'll know you have found the right starting point for your demonstration.

At WonderAffect, we have found that applying this simple principle can really help make a demonstration much more engaging.

I talk about this concept further in Big Monsters and Small Houses.

In my Stasis == Death article, I talked about how I like to use Blake Snyder's principle to help find a compelling problem scenario.

Once we have a problem scenario, it is vital to put that problem in the right context. This is where I like to borrow another one of Blake's screenwriting principles: the Monster in the House. This is a very simple principle; you need one of the following:

• A big monster
• A small house

One of those has to be true for a compelling screenplay, or in our case, a compelling demonstration. In our case, the monster is the problem, and the context is the house.

Big problems/monsters like semi-trucks heading for datacenters are great for demos because they are immediately recognizable as huge problems. The 'house' in this case is pretty big too - if a semi-truck is about take out your datacenter, then your entire business, all of your assets and all of your customers are going to be affected. In this case, we have a big monster and a big house - we're OK because one aspect of our principle is true.

Not all of my clients run datacenters (few do actually), so this type of scenario is not always practical. So we have to find other problems. In most cases, these turn out to be small problems or smaller monsters. If we have a small problem—like a email that is too slow or an analysis report that is not quite right—lwe just have to shrink our context/house. A small monster in a small house is still a big monster.

Instead of using the whole company as the context/house, we might have to use just a division in the company, or just a team, or even an individual. In an extreme case, we can focus on an individual's day, or a period during that day, or even a single task. When we focus at that level, even a small monster/problem can be very big.

When I'm trying to think up how to demonstrate a product, a technology, or a service, I like to first apply Stasis == Death to find a situation that needs to change. Once I have that, I like to identify whether I have a big monster. If I don't, I just need to shrink the house. I've found that this tends to increase the drama of a given demonstration and make it more compelling to the audience.

Video games are a great source for finding techniques that can be applied to really immerse your audience in the demonstration you are building. I learned a really great lesson once about 'perceived reality' and wanted to share...

The space battle scene depicted above illustrates a principle I like to apply to the work I do for my clients. Hopefully, you're watching this video with your computer speakers turned on; if you are, you'll hear explosions and space ships screaming past amongst other sound effects.

A number of years ago, I took a video game programming course and the instructor asked our class an interesting question: "Is there sound in space?"

If you think about it, the answer is obviously no. Sound requires air, and there is no air in space, so obviously there is no sound in space. NASA gives a more complete answer:

"Sound is also a type of wave that we cannot see. Like ocean waves,
sound waves need a medium to travel through. Sound can travel through
air because air is made of molecules. These molecules carry the sound
waves by bumping into each other, like dominoes knocking each other
over. Sound can travel through anything made of molecules - even
water! There is no sound in space because there are no molecules there
to transmit the sound waves. "

Then the follow-up question from our instructor (who happened to specialize in sound) was, "If there is no sound in space, then why do space-based video games like StarCraft invest so much in sound?"

The answer is that we expect it. When we see something explode, we expect to hear something. When we see a space ship fly by, we expect to hear something. If those expectations are not met, then we don't feel the experience was realistic.

Satisfying expected realism is something veteran video game developers know they have to do in order to produce something their customers will enjoy.

The same concept applies to building technical demonstrations; in order to captivate our audience, we have to satisfy their sense of expected realism.

This doesn't mean we fake everything in a demonstration; but it does mean that sometimes things have to be tweaked.

Performance is something I really like to tune for a demonstration.

Dialogs that take a long time to open, web sites that take a long time to appear are all good candidates for optimization. Sometimes this optimization is just a matter of warming the system up. But, at WonderAffect, we have done things as drastic as develop completely artificial facades of real applications to lend a sense of speed to their performance. There is no better way to lose an audience's attention than to make them wait. I've found it is far better to tweak/fake/adjust mundane aspects of your demonstration in order to speed up getting to good part—the part where your product/service really adds value.

Recognizing and satisfying expected realism was a really interesting lesson for me years ago in that video game development course, and now it is something I find really helps me produce great products for my clients.

Thank you for visiting our site. We are a privately held Seattle-based company that is focused on helping our clients show off their technology.

PowerPoint presentations and whiteboard sketches can only go so far - at one point or another, if you really want to close the sale or spark interest, you have to demonstrate your product or service.

 

Our entire site is black and white (with a little gray here and there); that is kind of weird, so please let us explain…

It’s never easy to come up with a color scheme for a new company. There are tons and tons of resources that are available and no shortage of opinions from your colleagues and friends.

But in the end, we felt like black and white was the right choice for this company.

Don’t get me wrong, colors are great, but we chose black and white because we think it helps reinforce the identity we’re trying to build for WonderAffect. That identity is probably best explained by the following quote:

“A customer is the most important visitor on our premises. He is not dependent on us. We are dependent on him. He is not an interruption in our work. He is the purpose of it. He is not an outsider in our business. He is part of it. We are not doing him a favor by serving him. He is doing us a favor by giving us an opportunity to do so.” – Mahatma Gandhi

At WonderAffect, we build demonstrations. A customer will come to us and we will help them find a way to demonstrate their product or service. So in the truest sense, the customer is the purpose of our work and business.

You’ll notice that the work we do for our customers is in color; that is because our job is to make them look great. Our colors are black and white because nothing we do should detract from what our customers are building or offering.

 

I get a lot of questions about the name I chose for this new company, so I thought I would try and explain my thinking behind it.

Most of the questions revolve around why I chose Affect instead of Effect. My rationale has to do with a definition of affect that I found on Wikipedia that caught my attention:

Affect, like the adjective affective, refers to the experience of feeling or emotion

I liked the idea of influencing feeling and emotion through technology. That was really the motivation for starting this company. I wanted to help people building products/services to really connect with their customers; the most effective way I think you can do that is by demonstrating what you are building. And the most effective way I think you can connect with a customer is through emotion—getting them to really feel inspired, surprised, and amazed.

Of course, with that explanation so far, I should have named the company EffectiveAffect

The reason I chose Wonder is that I want to always remember that technology, when seen in its best light, should be wondrous. The often used quote from Arthur C. Clarke states it best as, “Any sufficiently advanced technology is indistinguishable from magic!”

That is something we will strive for here; when we work with a client to show off their technology, we want to impart a sense of wonder—a sense of magic—to the audience.

So there you have it. In a survey of my colleagues, WonderAffect was not the most popular choice, but it is the one that I felt was closest to what I’m trying to achieve with this company. In any case, I’ve already ordered business cards, so I’m stuck with the name for at least a little while