Apple's Leopard lasts '30 seconds' in hack contest

Apple’s Leopard has been hacked within 30 seconds using a flaw in Safari, with rival operating systems Ubuntu and Windows Vista so far remaining impenetrable in the CanSecWest PWN to Own competition.

Security firm Independent Security Evaluators (ISE) — the same company that discovered the first iPhone bug last year — has successfully compromised a fully patched Apple MacBook Air at the CanSecWest competition, winning $10,000 as a result.

Charlie Miller, a principal analyst with ISE, said that it took just 30 seconds and was achieved using a previously unknown flaw in Apple’s Web browser Safari.

Competitors in the hacking race were allowed to choose either a Sony laptop running Ubuntu 7.10, a Fujitsu laptop running Vista Ultimate SP1 or a MacBook Air running OS X 10.5.2.

“We could have chosen any of those three but had to make a judgement call on which would be the easiest and decided it would be Leopard,” Miller said.

“Every time I look for [a flaw in Leopard] I find one. I can’t say the same for Linux or Windows. I found the iPhone bug a year ago and that was a Safari bug as well. I’ve also found other bugs in QuickTime.”

RIAs and Content Management

Forrester recently published a report on Rich Internet Applications and Content Management. The report covers some of the key topics in this area such as organic Search Engine Optimization, changes in build and release management, and how to change Content Management to better support RIA. The content for the report came from interviews across to folks managing and building sites with these technologies. Mike Scafidi’s architecture around Search Optimized Flash Architecture (SOFA) gets a mention.

Microsoft partners with social networks for contact data portability

Microsoft has partnered with some of the world’s top social networks on contact data portability. Starting today, Microsoft will be working with Facebook, Bebo, Hi5, Tagged and LinkedIn to exchange functionally-similar Contacts APIs, allowing them to create a safe, secure two-way street for users to move their relationships between their respective services. Along with these collaborations, Microsoft is introducing a new website at that people can visit to invite their friends from their partner social networks to join their Windows Live Messenger contact list.

The collaborations with Facebook, Bebo, Hi5, LinkedIn and Tagged will make it easier, safer, and more secure for people to have access to their contacts and relationships from more places on the web. These networks will be adopting the Windows Live Contacts API instead of “screen-scraping.”  Starting today, you can visit and to find your friends using the Windows Live Contacts API.  Hi5, Tagged and LinkedIn will be live in the coming months.

Share Google Spreadsheets via Google Gadgets

This is kind of neat, now you can share parts of your collaborative spreadsheets via a Google Gadgets. So, it can show up on your iGoogle page and other places. Neat way to pull folks into looking at your exciting number crunching;). Google also launched spreadsheet notifications. Tools lik eZoho Docs and Google Docs are very cool, no with the ability to syndicate more easily that should help adoption.

Read more here: There’s also some cool gadgets around visualization.

FCC Closes 700MHz Auction at $19.6B

Bidding in the FCC’s 700MHz auction closed March 18, 2008, after the auction raised a record $19.6 billion over 261 bidding rounds. The winners of the spectrum have not been disclosed as yet by the Federal Communications Commission.The results of this single spectrum auction surpass the $19.1 billion combined total raised by the FCC in 68 other auctions over the last 15 years. The proceeds will be transferred to the U.S. Treasury by June 30, earmarked to support public safety and digital television transition initiatives. The spectrum auction is part of the transition to digital television that will culminate in all television signals switching from analog to digital on Feb. 17, 2009. The FCC also placed conditions on the sale of the C block spectrum, requiring the winning bidder to build an open network to which users can connect any legal device and run the software of their choice.Before the auction began in January, Google committed to meeting the minimum bid in the C block. AT&T and Verizon were also interested in the spectrum. Although the FCC did not say when the winner would be announced, the current speculation is that the FCC will release the information by the end of March or early April.“The open platform will help foster innovation on the edge of the network, while creating more choices and greater freedom for consumers to use the wireless devices and applications of their choice,” FCC Chairman Kevin Martin said in a statement. “A network more open to devices and applications can help ensure that the fruits of innovation on the edges of the network swiftly pass into the hands of consumers.”

“Beautiful Code: Leading Programmers Explain How They Think”

“Beautiful Code: Leading Programmers Explain How They Think” is yet-another-excellent book put out by O’Reilly Books. It contains 33 essays written by respected members of the Software Development community and each essay is a variation on the theme of how we define “Beautiful Code”. The range of topics is vast and includes subjects like “A Regular Expression Matcher”, “Distributed Programming with MapReduce”, “Python’s Dictionary Implementation”, and [one my favorites] “The Most Beautiful Code I Never Wrote”. Each of the authors does a fantastic job of being as concise as possible without sacrificing an accurate presentation and solution of the covered problem. 

Although the authors certainly deserve applause, the editors Andy Oram and Greg Wilson are truly the unsung heroes in this publication. I can imagine it was a difficult task to make these separately written essays feel more like a book and less like a collection of chapters. How they accomplished this, however, may not be immediately apparent.  What I found was that within each of the 33 individual essays, lies a unique engineering principle that will emerge in successful software development endeavors. Moving beyond each of those principles within each of those essays, I realized that it is only the developer who grasps these tenets who is capable of writing Beautiful Code. 

Before moving on, I would like to point out that “Beautiful Code” is a book written for advanced developers. If you do not have some degree of familiarity with topics like: Finite Automata, C Programming, Concurrency Problems, Protocol Stacks, Haskell, Cryptography, Algorithm Proof Techniques, and Kernel Development, this book is probably not for you. Even if you are comfortable with these topics, be prepared to encounter a few chapters that may need to be read twice or require a bit of internet sleuthing before you grok it. 

Below, I’d like to present an example of what I mean by “the essay” versus “the extracted principle”.

Chapter Three is titled “The Most Beautiful Code I Never Wrote”. It is written by Joe Bentley and it takes an unique look at the famed QuickSort algorithm. Without delving into the essay itself, Joe cleverly presents how the beauty of the famed QuickSort algorithm lies within the code that is not written at all. Two quotes I’ve highlighted from the chapter are:

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away” - Antoine de Saint-Exupery

“Simplicity does not precede complexity, but follows it” - Alan Perlis

I once overheard a seasoned developer say to a younger developer, “Develop a little, refactor a little. This is your mantra. Simple code simply works”. Developers who strive for simplicity, who strive to write code that not only “works” but “works well”, are developers who produce code with less bugs and require less maintenance. That is the extracted principle presented in this chapter and, ultimately, that is the difference between brute force workmanship and eloquent craftsmanship. 

Within each essay is a life lesson for anyone who is a practicing technologist and I highly recommend this book to anyone who fancies themselves as such. I suspect that “Beautiful Code” would fit nicely between “The Pragmatic Programmer” and “The Practice of Programming” on any development shop’s bookshelf.

The Back of a Napkin...

Often times we spend significant time caught up with diagrams and illustrations of our enterprise technology architectures, patterns, and concepts. Most recently a couple of us have been spending time on some diagrams to help illustrate the concept of a content management bus to help a large organization better share and tag their content. It’s definitely an critical and fun skill. A former collegue, Dan Roam, has just published a book, The Back of the Napkin: Solving Problems and Selling Ideas with Pictures. Having worked with Dan for years, I can tell you his ability to use visual thinking to help communicate complex business and technology concepts is just incredible. I just ordered a couple of copies and I am eagerly awaiting them from Amazon. Especially since I’d love some ideas on how to better help folks think about this content services bus we are working on:)…

The Tools Google Uses Internally

A web seminar Google held at KMWorld Magazine offered a great deal of insight into how Google manages projects and communication internally. The presentation by Google followed an employee through his first few weeks at the company, explaining the many tools he’s using: from the Google intranet MOMA, the Google Ideas site and Google Caribou Alpha, to Google Experts Search, “Googler Search,” and Google Apps.

Here are a few links to view the content of the presentation: mode=embed&documentId=080312113223-aa1c560259e24ac892c4e1cfa3f0c12d


I just finished a book I found hard to put down, Better, by Atul Gawande. Atul is a surgeon in Boston who writes for the New Yorker and has published a couple of books. I love his essays and thoroughly enjoyed his first book, Complications: A Surgeon’s Notes on an Imperfect Science. In Better, Atul takes an unabashed look at how the medical profession can do things well, better. He uses examples ranging from the US Military Iraqi battlefield techniques to a Minnesota doctor’s relentless focus on helping Cystic Fibrosis patients live longer. One of the most exciting things about his writing is his ‘spock’ like ability to examine the things that go well and the things that go poorly. It isn’t good or bad, it’s something we can learn and improve on.

So, how does this relate to building software? Well, at the end of the book he comes up with five things we can do to be a ‘positive deviant’.

  1. **Ask an unscripted question. **Often times we are caught up with the task at hand and we don’t the time to make more human connections with co-workers. I bet this would go a long way to helping inter-disciplinary understanding (See Troy’s Post).

  2. **Don’t Complain. **Keep the conversation moving in a positive direction. Sure we don’t need to ignore uncomfortable things, but after too many complaint sessions we all walk away feeling angry and sorry for ourselves. This isn’t likely to help us get better at software development.

  3. Count something. This one is always fun. Counting things is great. I love looking at the analytics of our internal wiki/blog tools. It’s a great way to get a sense of how much we are collaborating and finding the peaks and valleys. I once spent a couple of late night hours on a project writing regex statement to determine how many lines of code each developer wrote and how many bugs were assigned to them. As a team we loved looking at the numbers and worked to come up with different ways to look at performance and improve on it. This happens all too rarely.

  4. **Write something. **It’s the process more than the content, Working through an essay, blog post, or white paper helps us clear our thoughts and get a sense of our larger purpose. It’s good stuff, even if it feels like a challenge to find the time.

  5. **Change. **Something we hear with just about every project we start is, how can we get it down faster and once it’s down, how can we change it faster. It feels like the answer is change. This is what excites me about technology like Grails(see Jo’s Post) and Ruby on Rails. It’s what excited me about Java 1.0 over C back in the day. So, what are the changes we need to make to get things done faster? Can we do things before the user experience, creative and business teams finish or even start defining them?

Introducing the new FolderShare!

Yesterday, the Windows Live team released a new version of Foldershare along with their new website.

New features added are: • A new website designed to make managing your FolderShare libraries and computers even easier. • A new FolderShare with a better setup, a better system tray menu, and better performance on Windows Vista. • Improvements on the backend to keep FolderShare running more smoothly and reliably.

And all this is still FREE!

You can check out the new site, install the new FolderShare, and let the team know your feedback!

Introducing Grails

It was Tim Bray, who in his predictions for 2008 mentioned that “_Rails will continue to grow at a dizzying speed, and Ruby will in consequence inevitably become one of the top two or three strategic choices for software developers_”. Indeed, in my eyes the rails paradigm which blends well-known best-practice patterns such as MVC web applications with the notions of Coding by Convention and Don’t Repeat Yourself doesn’t only speed up and simplify development, but also keeps your code base clean. There are no more tedious configurations files which all repeat themselves yet have the touching fingerprint of every developer’s style. Developers can focus on the most important issue at hand: the functionality. That’s why I’ve always been a huge proponent of Ruby and Rails.

But why Ruby?

With a fairly high adoption rate for Ruby on Rails, some problems have been discussed across the internet (follow this discussion, for example):

  • Performance, especially in large installations

  • Interoperability issues with other applications / technologies

  • Deployment onto existing infrastructures and application servers

What other frameworks are out there that provide the same benefits? For today, let’s dive a little deeper into Grails.


The Grails project (formerly known as Groovy on Rails) started in July 2005 and the project just recently announced the long awaited 1.0 release on February 18, 2008. Grails is built on top of the J2EE stack and combines the best-of-breed tools Hibernate, the Spring Framework, Groovy Scripting, as well as support for my favorite IDE, Intellij Idea (no worries, Eclipse works too). All mature tools and languages that have been used in the Java community for a long time now. Consequently Grails provides:

  • Lower learning curve for J2EE developers

  • Easy integration points with existing and new Spring and J2EE applications

  • Enterprise deployment of grails applications as a WAR/EAR file

  • Similar performance to a Java application (see performance tests)


Let’s dive straight into a demo in which we will create a few persistent domain classes and integrate an existing CMS backend.

Grails Demo Architecture (Click to view the demo)


The following features are included in the 1.0 release:

  • Test-driven development via unit tests and mock objects

  • An environment-sensitive configuration mechanism out of the box

  • Ruby-on-rails like build and development command line tools (that can create war files)

  • OR-Mapping via Hibernate (with full support for all Hibernate-supported databases)

  • The ability to weave in advanced Hibernate functionality and provide custom OR-mappings if needed (for that remaining 5% of the functionality that require special tuning)

  • An MVC web-layer based on GSPs (Groovy Server Pages) which includes custom taglib and sitemesh support

  • Ajax support (Grails ships with Prototype but has plug-in support for Dojo, Yahoo UI, and Google Web ToolKit)

  • Internationalization Support (Does Ruby do this nowadays? :))

Caveat Emptor?

Yes, the Grails community just released version 1.0 in January 2008. Yet the framework has been in the works for about 2½ years now and I was quite impressed with the amount of features and finesse already contained. The foundation of the framework is built on top of well-established open source frameworks which should minimize the risk of using such a new library.

Would I recommend Grails for a huge enterprise project? Probably not. But I would wholeheartedly recommend every developer and architect to look at this great alternative to traditional web development.

Fading the Tech/Creative Line

The common mentality with respect to creative and technology process integration involves a relatively solid line that separates the two disciplines and work streams. Creatives do their concepting, draw up wireframes, create visual assets, and then toss them over the line. Technologists pick these up, create the front-end HTML, create the back-end code, and wire them up to create the system. That is an extremely over-simplified description of both sides of the line - but it represents the general perception of many clients and peers in our industry.

The agile movement has made great strides toward integrating project teams. But the focus here has been on bringing business and end-user representatives into the process and advancing the project through small, iterative cycles. (Again, a dramatic over-simplification. I’m a huge Agile proponent.) The iterative cycle keeps all disciplines (plus business stakeholders and users!) engaged throughout the project. Great progress! But, within an iteration, the line often remains. Both the creative and technical teams are tightly engaged with the business and user representatives. But they’re only loosely engaged with each other.

There are many reasons for this. On a given project the creative and technical teams are often from separate internal organizations - at best. At worst, they’re from separate companies altogether. Beyond that, they often think, talk, and act very differently - making it hard to relate. Right brain, left brain stuff. There is hope, however.

One of the most satisfying things about working with Avenue A | Razorfish is experiencing the blurring of the tech/creative line. As a company with strong marketing, creative, and technology capabilities that are integrated on many projects, we’ve learned through experience how to work and communicate with each other. That is one of our strongest value propositions to customers. We’ve proven that the line can be blurred and there is significant value in doing so. However, it is within the last year that I’ve seen the most substantial fading of the line.

This can be attributed to the popularity and demand for rich Internet applications. RIAs require a much greater level of cross-discipline understanding and cooperation. Windows Presentation Foundation and XAML have done the same thing for desktop applications (and the web, with Silverlight). There is a great whitepaper on the WPF designer/developer workflow entitled The New Iteration. Definitely worth a read. It specifically addresses WPF, XAML, and the Expression tools, but many of the points apply more generally to RIAs, as well. The value proposition is well stated:

"Ultimately, the new collaboration means that iteration of a project can now happen in a much more fluid way. There is no longer the “one-way street” where a change to a specification downstream means a radical reworking of the entire application. The result opens up new possibilities for collaboration between the designer and developer, where a kind of dialogue is possible with the potential to foster greater creativity."

It is that last point - the potential to foster greater creativity - that excites me the most. Technologists are often in a restricting role. We have to set boundaries that the creative team must work within so that we’re able to deliver on their promises. Rather than promote cooperation and collaboration, this can create an “us versus them” mentality. However, with RIAs I have noticed a great change. Technology and creative teams are pushing each other to expand the solution horizon, rather than constrain it. Both teams are equally invested and sharing their unique perspectives, which results in far better solutions.

It may be intuitive that a shared sense of ownership, varying perspectives, and close collaboration will have positive results on a project. As a consultant “back in the day”, when the Internet and HTML were new, I saw the same level of enthusiasm and collaboration between technical and creative teams. But as technology and creative techniques matured, the tech/creative line solidified. As a result, the solutions became somewhat cookie-cutter. That’s not to say companies weren’t launching sites with great creative and technical work. But truly remarkable solutions are conceived when both the technical and creative limits are stretched and combined to produce something truly unique. I’m thrilled to be back in this sweet spot. The industry as a whole seems to be following suit. But unless a deliberate effort is made to avoid falling into comfortable patterns, truly remarkable solutions may once again join the endangered species.