Take a screenshot in Flex and send it to ASP.NET

In Adobe Flex 3, you can get a bitmap image of any control by using this code (you'll need to import ""):

var snapshot:ImageSnapshot =  ImageSnapshot.captureImage(backgroundCanvas);

By default, it uses PNG encoding.

If you want to then send this image to the server, use this code:

var req:URLRequest = new URLRequest();
req.method = URLRequestMethod.POST; =;
req.url = "snapshotuploadhandler.aspx";
var loader:URLLoader = new URLLoader;

Reading the uploaded file is easy using ASP.NET:

private byte[] readPostedFile()
   if (Request.ContentLength > 0)
       byte[] buffer = new byte[Request.ContentLength];
       using (BinaryReader br = new BinaryReader(Request.InputStream))
           br.Read(buffer, 0, buffer.Length);
       return buffer;
       return null;

Like this post? Please share it!

See a mistake? Edit this post!

Intel Core 2 Quad Price Cuts

Two days ago Intel dropped the price on the Q6700 (2.66Ghz) processor in half. Newegg currently has this processor for $299, and you get Unreal Tournament 3 for free.

Core 2 Quad Processor

Before the price drop, I was recommending the Q6600 (2.4Ghz) because of its low price. Right now, it's going for $229.99.

If you're not going to overclock, and you don't plan to take advantage of all of the cores, then the Q6700 is probably a safe bet because of the slightly higher clock speed (10% higher).

If you're trying to save money at all, or you plan to overclock, the Q6600 is still an amazing processor. It's easy to overclock to 3Ghz, while still running extremely cool.

Both of these processors would be great for a VMware server. Paired with some fast hard drives, and a couple gigs of memory, you could easily run 4-8 virtual machines (depending on what they're doing of course).

It's amazing how cheap it is to build what I would consider a fairly top of the line machine.

Like this post? Please share it!

See a mistake? Edit this post!

LEAN software vs planning everything with a spec

Every since reading Joel's article "Painless functional specifications - Part 1: Why Bother?", I've be a big fan of writing functional specs. I've done it for a few projects, and I've encouraged others to do the same. The biggest reason is to solve problems ahead of time, instead of waiting last minute.

Then, I start reading about the LEAN philosophy, and it's telling me to not plan anything, do what you need to do, and change as the customer makes requests, or as you learn what the project really needs. What??? How the heck is that supposed to work.


I think the answer is a hybrid approach. Write your spec document, but don't try to design your entire program before writing any code. Solve the overall issues that you know need to be solved, and also plan any features that you are absolutely sure you will need. The spec document should be a snapshot of the bare bones version of what the software needs to look like.

The problem with Joel's approach is that it assumes that the customer won't change their mind, and if they do, they'll be able to get all of it out of the way before any code is written.

I'll give you a real life example of a project I'm working on. The project was extremely rushed to get the first version out the door. Because of a lack of planning (I wish we had a spec!), we had to throw a lot of our work away and start over.

The lesson learned was that we needed better planning.

However, once the site was live, we realized that we didn't really understand what the customer wanted. We needed to look through our statistics and get customer feedback before we could attempt to plan future features. The result is that we try to plan our features is detail, but we meet every week to prioritize them.

If we were to formally plan the next version of the site, and then code it for a month, I believe the results would be a disaster. Because we are constantly learning, we need to be able to adapt to changing conditions quickly.

If we were to plan another major release of the site, I would advocate creating a detailed spec, but try to minimize the size of the release as much as possible. Release early, and release often.

I know that Joel is against the "release early, release often" mindset. The truth is, it highly depends on what kind of software you're writing. Joel is writing Fogbugz, which is already very popular, and has a great set of features. They can afford to take their time, and they probably have a good understanding of what the customer wants. If you're not as fortunate, you may just have to put something out there that isn't perfect, learn what users want, and adapt quickly.

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG