Coders at Work I've been reading "Coders at Work" by Peter Seibel over the holidays and wanted to share my review. The book is basically a series of in-depth interviews with 15 interesting programmers including people like Brendan Eich (inventor of JavaScript), Ken Thompson (inventor of UNIX), Peter Norvig (Director of Research at Google).

Other programmers interviewed are: Frances Allen, Joe Armstrong, Joshua Bloch, Bernie Cosell, Douglas Crockford, L. Peter Deutsch, Brad Fitzpatrick, Dan Ingalls, Simon Peyton Jones, Donald Knuth, Guy Steele and Jamie Zawinski.
 
I first got interested in in this book after reading an interesting tweet from Ralph Hauwert quoting Joe Armstrong in the book:

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” — Joe Armstrong

Its really invaluable to get the perspective of this wide range of experienced developers and get an insight in the way they work, what inspires them to code and how they see the future of programming languages.

Definitely recommended reading and a good source of inspiration to any developer!
 
www.codersatwork.com
 

Posted
AuthorPeter
2 CommentsPost a comment

Scott Barnes, MicrosoftThose of you that follow me on Twitter will no doubt have been witness to some interesting (and sometimes tedious) discussions between myself, other Flash Platform enthusiasts and Scott Barnes of Microsoft. Scott was an ardent supporter of Flex before his move to Microsoft which makes his perspective all the more interesting. Thought it was worth asking him to answer a few questions about the latest Silverlight developments. As you might imagine I don't fully agree and sometimes strongly disagree with some of the points he makes, but its an interesting read nonetheless.

 
Thanks for your time Scott, can you introduce yourself and explain a little about your role at Microsoft? Sure. I’m a Rich Platforms Product Manager, which is a great title to confuse many with. I’m simply part of the WPF & Silverlight team. I used to be the first RIA Evangelist for Microsoft, so it does in part derive from this previous role.

My role varies from month to month as simply due to my background, and I have a wide degree of interaction with not just the WPF & Silverlight teams but other teams within Microsoft. Overall, my main focus is ensuring we’re putting the right features into Silverlight & WPF whilst ensuring we keep a balanced view between designer and developer needs. I’m currently focused on a complete upgrade of our website experiences.

I also spend a great deal of time monitoring and interacting the online/offline developer and designer communities, as I’m constantly searching for evidence on how we can better meet our customers’ needs.

 
We've seen some exciting announcements around Silverlight 3 at MIX09, can you list us some of your favorite new features

Easy. Out of browser, Pixel Shaders & Effects.

Out of browser This for me is one of the more interesting features we announced. It’s essentially a new canvas to paint from, and that startup entrepreneur in me has sparked a new level of interest in how far one can go with this concept.

I’ve listened to a lot of ideas on how this will change customers’ business directions and—more to the point—how it will impact the concept of what we know as RIAs today. Now comes a new wave of interest in Silverlight which in turn will grow our developer/designer audience further; thus new creations will be born. That ultimately is the proving ground for why this feature will be so compelling. Best part is, no additional installs are required.

I like to think that if you take this new feature and combine it with our recent addition to C# called LINQ (Language Integrated Query), you’ve also got what I foresee as starting a great essential offline storage story. LINQ is an addition to C# and enables developers to write SQL-like syntax against any data; whether they be lists, dictionaries or even object properties. The idea behind this came from one of my personal geek heroes, Anders Hejlsberg, Chief Architect of C# and one of the founding architects of Borland Delphi (My first Windows based GUI language/tool of choice) – currently a Technical Fellow at Microsoft.

Pixel Shaders & Effects When I first joined the Silverlight team, the first thing I investigated was why we didn’t have drop shadow and blur baked into the runtime. Turns out this entire concept has been sitting in the to-do pile since 2007, so for me it was great to see this finally come out. I’m excited to see that folks who previously put Silverlight in the “not ready” pile have, in the last week or so, asked me to hook them up with tooling so they can get started. For me, this tells me we’re on the right track.

I think pixel shaders and effects—and other features like 3D and ClearType—will signal to the design audience how serious we are about enabling better design with our platforms, whilst at the same time continuing to help them work more closely with developers.

“With great power, comes great responsibility” however: please Silverlighters, let’s avoid propagating the dreaded water ripple effect from the old Java Applet days…It’s in the anti-design pattern catalogue now. ;)

 
What direction do you see Silverlight going, is further mobile and devices support on the roadmap? With Silverlight announced to be getting ported to S60 devices, can you imagine it ever coming to lets say Apple's iPhone? Absolutely—we’ve shown Silverlight running on mobile devices in the past and we’re excited about this growth area for Silverlight. Even better, I know the development teams in the Silverlight runtime have worked extremely hard to ensure that we don’t differ in development experience from desktop to device, so that for me is signs of a healthy future. That, and I’ve seen Silverlight run on my old Black Jack II using Windows Mobile personally..

But sorry, no inside gossip from me on this one beyond that J

 
How should we see Silverlight Out of Browser? Is this simply a feature to bring Silverlight web applications to the desktop for basic offline use or should we expect it to get a full API stack and become more like what we see with Adobe AIR? I’ll answer that question in two parts, first being the Adobe AIR & Silverlight comparisons.

It’s funny; I’ve read a few posts already debating how Silverlight and Adobe AIR compare. Having been a part of some of the early out of browser discussions here, it’s funny to me because the actual DNA for this feature derived from Smart Client wish lists (2002 – No Touch Deployment).

This is important to remember, as Microsoft had both the Smart Client strategy and also the WPF (XBF) years before Apollo / Adobe AIR came to market (I remember asking Macromedia/Adobe staffers if it was copy back then before I joined Microsoft), so it’s not really a “me too” feature. Instead it’s a lot of the old coming through to the new and sure, we’re not ignorant of Adobe AIR presence, but we simply feel the two are flowing on separate trajectories.

Second answer to your question is more on expectations of Silverlight Out of browser.

Out of browser is really focused on ensuring Silverlight experiences don’t lose momentum the moment the network cable is disconnected and that ultimately is the real secret here. Microsoft has learned a lot of lessons over the years regarding security and we think that you have to be very careful when mixing the metaphors of web and desktop apps. Anything less and you’re asking for trouble. Silverlight applications running out of the browser are still web RIAs and have the same type of safe sandbox. A Silverlight app isn’t going to wipe your desktop clean or allow someone to create an invisible window over your desktop and intercept your passwords. We are extremely cautious with our sandbox and will continue to open up areas of the feature where it suits customer needs the most whilst ensuring we protect the end users.

For a more robust, tightly integrated desktop application, you’re in luck—WPF is a much better fit for your needs. WPF has a much deeper continuum to Silverlight and the best part is you’re able to re-use a lot of your skills and assets inside WPF, something I think no other solution on the market today provides. I mentioned earlier LINQ and how great it is; well one thing I’ve found is that you can use LINQ universally across both platforms whilst at the same time having a natural amount of extra native access within WPF.

 
You yourself have come from a Flash/Flex background yourself, do you see Silverlight as a competing technology across the board or do they each have their own use case? Are there cases where you would recommend Flash Platform solutions over Silverlight? It’s going to sound silly, but I honestly don’t think Flex & Silverlight compete with one another full on. The reason I say this is that folks in the Microsoft customer base didn’t adopt Flex prior to Silverlight and last time we checked, haven’t since. I’m also not seeing a dramatic increase in Flex developers since I left that community, but have seen an explosion of developers (4:1 ratio on Flex) in the Silverlight community – especially since it started from 0 only a couple of years ago.

I mention this as I personally think, having worked in both spaces, that Flex requires more effort to pitch into the enterprise than a native .NET solution; given Microsoft already has healthy growth there – and I’m speaking from experience here, as I’ve sold Flex back when it was 15k per CPU. Instead, it’s really about ready-made solutions vs. starting from scratch, and I’m not convinced the two products will be isolated as being a choice. Companies, given the current economic climate, are more focused on choosing a platform rather than a runtime with a framework. To compare Silverlight with just Flex doesn’t do either products justice, instead it’s really about Microsoft .NET vs Adobe Open Screen Project.

I mostly get comparison questions between Adobe and Microsoft from developers themselves or folks looking to prove some point. I never get these questions when it comes to large accounts or customers in general: To them it’s both runtimes are simply just a bullet point in the overall discussion, as they are more focused on how they can build an entire solution end to end, servers, tools, etc. all play a role. Not majority of the time which runtime has the better feature matrix?

The only time I would concede Flash over Silverlight is when we simply don’t have an offering that fits. This can vary in discussion, sometimes it’s a case of the person in front of me has already heavily invested in Adobe technology or they’ve asked specifically for a feature that we don’t have, resulting in their product evolution becoming brain-dead without the said feature.

In the early days the feature vs. feature discussions were hard ( I hated every minute of it), I will admit, but today, I’m finding it easy given I think we’ve got not only parity with Flash in terms of core features and a differentiated offering and a great deal to offer our customers.

In closing Pete, I honestly think both Microsoft and Adobe are solving similar problems but with a different set of tools, and so we are both just going to co-exist. I don’t think you have to be one or the other and companies like Cynergy Systems for example get this, where they are being successful on both platforms.
 

Posted
AuthorPeter
38 CommentsPost a comment

Peldi
Giacomo 'Peldi' Guilizzoni - photo © Matt Snow
I recently had the opportunity to talk to Giacomo 'Peldi' Guilizzoni -- ex-Macromedia/Adobe software engineer -- about his new company Balsamiq and the hugely popular Balsamiq Mockups application. I've started using Balsamiq Mockups on a number of projects myself and its proven to be a very useful application, definitely worth checking out!

 
How did you get the idea to create Balsamiq Mockups? Was it the type of application you were looking for yourself or noticed a market for?

First off, let me thank you Peter for the opportunity to answer your questions. I have been following your blog for years! :)

I think the idea for Balsamiq Mockups took shape over the years. As a developer, I had to write many feature specifications, and the more I wrote, the more I noticed that the process we followed had many gaps in it which could be improved. For instance, we would always design a feature on a dry-erase whiteboard first. While this had just the right amount of low-fidelity to encourage discussion and iteration, it was also a bit painful: first you had to go around the office stealing markers that worked, then if you needed to stretch a rectangle you had to erase an edge and redraw it further out, and sometimes the end result was so messy that you'd come back to a whiteboard the next day and were unable understand what the heck that mess of lines and squiggles really meant.

The next step in the process is to transform the whiteboard drawing into a digital form. The product manager on the team, who is ultimately responsible for the feature design, usually doesn't know Photoshop or Fireworks, so the job always ends up in the hands of the designer or the developer. The designer will go straight to Photoshop and spend hours and hours making the mockup pixel-perfect, with nice gradients and transparency everywhere. The developer will often code the feature (again, hours and hours) and take a screenshot when done.

Both approaches are bad news, as the initial whiteboard design is almost never the best one. Then the screenshot has to be embedded in the spec somehow (it used to be a painful ftp process until we started using a wiki as intranet).

So then feature review time comes around, and flaws in the design are uncovered. The designer or the developer (or both), having already spent many hours on the initial design, resist making changes. So you end up with a compromise, which in the end means software that's not as good or usable as it could have been. Everyone loses.

Clearly there was a need for a low-fidelity, fast, collaborative, digital wireframing tool. If it was integrated with the wiki, even better.

I didn't really do much market analysis before jumping in, other than a quick Google search for wireframing tools. The few that I found were either too complex or too crappy, and none integrated with wikis, so I saw a spot. I certainly did not expect Mockups to be such a hit, at all. I got lucky!

 
Was it immediately clear you wanted to use Flex and AIR for the application given your background or did you also look at other technologies?

I didn't even consider other technologies. Flex is what I know, and IMHO there's nothing better for writing applications such as Mockups (lots of graphics, not a lot of text). I had written the whiteboard for Macromedia Breeze years ago, so I knew I could write a simple image editor again. Plus I wanted my app to work in the browser (to integrate with our wiki), and Flash is clearly a no brainer in terms of penetration.

The choice to port Mockups to AIR came a bit later, during my private alpha/beta program. I thought of making a Mockups AIR app as the answer to the "what if I'm offline" problem, not as my main money-making application. But lo and behold, lots and lots of people still like to buy and install applications on their desktops...working in the cloud via the browser is still something only a few people do. Plus over time I am starting to think that hybrid, "fit client" applications might be the future...Microsoft's "software+services" mantra might actually be right in the end...we shall see.

 
Clearly Balsamiq Mockups is a great way to work on mockups, how would you compare it to prototyping with lets say Fireworks?

I have to admit that even though Fireworks is my favorite image editing tool, until a few months ago I had no idea you could use pre-made UI symbols to wireframe applications with it - which is bad because it would have saved me a lot of time, and good because I might not have built Mockups had I known... ;)

The problem with Visio, Fireworks and other such tools is that they are designed to let you create ANY kind of diagram or graphic, they are very generic. Mockups' strength comes from its incredibly narrow focus. Take adding a scrollbar to a DataGrid for instance. In Mockups it takes ONE click: the scrollbar is added in the right spot at the right size, and the DataGrid columns shrink a little to make room for it. Try doing that in a generic tool! :)

 
What do you have planned for the future with Balsamiq Mockups? Are you considering adding support for exporting the mockup to MXML or XHTML, collaboration features perhaps?

Let me talk about code generation first: in short, I'm staying as far as possible from it. I save mockups in XML, so theoretically someone could write scripts to transform my markup to MXML or XHTML or whatever, but it's not a problem I am interested in solving, for three reasons: first off, there are far too many languages and frameworks I could export to, and each is constantly evolving (maintaining the exporters would be a huge headache). Second, I think the "from image to code with one click" holy grail might not actually be attainable: do you know any developers who would happily start from automatically generated code? It's like admitting that the machine is better than you! What about dealing with the roundtrip from image to code and back while iterating on both? Ouch. It's a very, very hard problem, which I'll leave to people smarter than me to solve. Third, and most important: I don't think there's a big pain there. Recreating a UI from a low-fidelity mockup is not where the time is wasted. Coming up with the right design (structure), coming up with a beautiful visual design, and then coding it properly are the real time sinks...laying out controls based on a wireframe is easy enough (in Flex Builder, Interface Builder etc).

As for Balsamiq, I have enough work to keep me busy through 2009 at least. I have some client/editor features planned like the ability to link mockups together (help me design it!), adding support for 'Projects' (i.e. groups of related Mockups), and a host of little improvements here and there like the ability to double-click groups in order to edit their contents.

The bulk of the work though will be server-side. I am working on a hosted subscription-based version of Mockups with collaboration features built in. Then I am working on letting users load and save data to the cloud (think Google Docs, Basecamp) from the desktop app (the hybrid approach again), not to mention the 4 or 5 server-side ports of Mockups to other wikis / bug tracking and content management systems that I have in the pipeline.

Overall, 2009 is going to be so much fun, I'm so excited! I have recently hired my first employee (@balsamiqMarco on Twitter) and it's an awesome feeling, we are definitely still in the honeymoon phase and ready to take on the world! ;)

 
How did you experience going from Adobe to your own studio developing your own software? Are there things you learned from the old days as a software engineer, do you think you have a different perspective on software development now?

Everything I know about making software I owe to working at Macromedia and Adobe. Ok, maybe not everything everything, there might be a 10% that came from reading lots of business/software books, but you get the idea. I was so lucky to have so many great mentors there, from Jonathan Gay and Robert Tatsumi to Nigel Pegg, Dennis Griffin and many, many others. If you want to be surrounded by nice, well-rounded people who are smarter than you, go work at Adobe.

The transition from Adobe to Balsamiq was not easy. Macromedia was my first real job after school, and 6.5 years is a long time. Leaving was not easy, at all. I loved my job there and loved the people I was working with, we did great work and I was happy to go to work every day. A big part of the decision to leave was personal, wanting to move back to Italy with my family and our toddler. Starting my own company was my dream since college, so I thought it was a good time to give it a shot. So far, I'm having a blast, I'm loving every little aspect of it, from the coding to the customer support.

I recommend it! :)

 

Posted
AuthorPeter
CategoriesAIR, Interview

Most of you will more than likely have heard about Alchemy by now, an Adobe project that allows C/C++ code to be cross-compiled to ActionScript. I was incredibly impressed to see an actual port of Doom running in the browser released into the wild just days after Alchemy hit labs.adobe.com.
 
Doom running in the Flash Player
 

I recently had the opportunity to do a quick interview with to the developer behind the Doom port. Its a fascinating read that I wanted to share with you.
 

Mike WelshQ. Can you introduce yourself and tell us a little bit about your background and how you got the idea to port Doom using Alchemy? My name is Mike Welsh. I've been working for the past few years as a Flash developer for Newgrounds, where I spend a lot of time staying on top of new technology and developments in the Flash community. I also did some work for Castle Crashers. Doom is one of my favorite games, and id Software is nice enough to release the source. It was a good way for me to get familiar with Alchemy.
Q. When did you hear about Alchemy and how did you get started with it? I first heard about it from watching the sneak peak videos from Adobe MAX right on your site! Scott Petersen showed a very cool demo of Quake running inside the Flash Player. This was very impressive, but I remained skeptical. Was it actually cross-compiling C to ActionScript bytecode? Or was it just a trick to run native binary code? As more information was released, it became clear that it was compiling into AVM bytecode, and I was really intrigued. When Alchemy was initially released a few weeks ago, I downloaded it and plunked through the documentation. I figured that I'd use the Doom source to test it out.
Q. How long did it take you to get the Doom example cross-compiled from C/C++ to the Flash Player? It took about a week of hacking to get it going. It was thrilling to see the game slowly come to life. After I got Alchemy up and running, I spent a few hours ripping out all of Doom's OS-specific window and display code. Then, I could see Doom's debug output. It's pretty funny to see "DOOM is Shareware!!" in your trace window!

Some time later, I finally managed to get Doom's frame buffer to display inside Flash. Doom is 8-bit color, and I wasn't reading the palette data, so the display was in grayscale. At that point, the adrenaline kicked in, and I spent some late nights getting the palette, input, and sound rigged up.

The most frustrating part of the port was the most mundane: getting the preloader to work! It still baffles me that it's so difficult and poorly documented to get embedded assets and classes to work properly with a preloader.
Q. Are there any specific feature requests you have with regards to Alchemy or anything else planned to you would like to cross-compile? The main issues I've had with Alchemy are simply bugs and poor documentation. For example, Alchemy code currently doesn't work on PowerPC. This is all to be expected of a preview release, and Scott Petersen has said that these fixes are coming!

My big request isn't specific to Alchemy, but a general Flash request: more mouse control. Many people complained about the lack of mouse control in the Doom port, but it's still impossible to do correct Quake-style mouse control in Flash. This requires a way to "lock" the cursor to the Flash area in the browser. How many times have you been playing a web game, clicking madly, and accidentally clicked outside the window? I understand that there are usability and security concerns, but a ton of people would benefit from these features, so there has to be a solution!

To test the limits of Flash and Alchemy, I have been toying with the Quake 2 source code--who knows how far I'll get! A friend has also started a project to port the SDL library to Flash -- this is really exciting, because there are tons of apps and games that use SDL. They'd instantly be available to Flash!
Q. How do you see the future of Alchemy, will this become a common tool to use in Flash/Flex/AIR development or do you believe that ActionScript will remain the primary scripting language? Adobe seems to be pushing Alchemy as a means to port legacy libraries to Flash. Truthfully, I'm not sure if it will be widely used. Sure, it's nice to work off of an existing code base, and you might be able to get a library quickly running in Flash. Ideally, you'd make an AS3 wrapper around the Alchemy code so that you never need to know that it was cross-compiled. In the long run, though, it's probably much more clean, maintainable, and extensible to rewrite functionality straight into ActionScript by hand. Having to deal with an amalgam of C++ and AS in your project could get messy.

As far as performance benefits, you do get a bit of a performance boost from Alchemy. Flash 10 introduced some new AVM bytecodes for quickly reading and writing to ByteArrays, and Alchemy uses these extensively. Also, C code is very static and can be optimized well at compile-time. Alchemy is compiling to plain ActionScript bytecode, though, so it doesn't have any "special powers." It's subject to the same restrictions as standard ActionScript, and the Flash compiler should be able to make use of the same optimizations that Alchemy does. Ralph Hauwert and Joa Ebert have made good posts on this subject. Therefore, I don't see many people using Alchemy for performance reasons. Pixel Bender is probably better for number crunching.

Maybe I'm totally off-base, but I see a lot of people using Alchemy to port old games into Flash. Why? Because it's always fun to have classic games in your browser! In any case, it's a cool technology, and it'll be interesting to see how it gets used.
 

Thanks to Mike for taking the time to do this interview and I'm pretty sure we'll see many developers playing around with Alchemy over the holiday season!
 

Posted
AuthorPeter
10 CommentsPost a comment