bundle_view is now "bundle viz"

Last weekend I tweeted:

My weekend #ruby hacking. GraphViz for your #rails Gemfile using @gembundler. http://bit.ly/b1PaXT Suggestions, patches welcome!

What a fun week it's been.

@wycats hunted me down and asked if I'd roll bundle_view into bundler.

Done.

Checkout my bundler fork on github. Stay tuned for updates about getting into main.

CLI on the Web? Sure, but put x86 their first

Miguel blogged a great idea today, expanding on Joe Hewitt’s simple statement on Twitter:

If CLI was the ECMA standard baked into browsers instead of ECMAScript we'd have a much more flexible web.

Agreed. I’d love to be able to run C# instead of Javascript on my web page. I’d also love to be able to run Ruby. Or even Scala. So why not JVM on the Web? What about Go?

Why not indeed. If there is going to be a push to have broader language support on the web, let’s jump over the problem of picking the right VM and Garbage collector. Let’s skip shared agreement on compatibilities between Microsoft’s implementation and Miguel’s.

Let’s go straight to Native Client.

I’ve talked about Native Client before. Here’s the official summary:

Native Client is an open-source technology for running native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We've released this project at an early stage to get feedback from the open-source community. We believe that Native Client technology will help web developers to create richer and more dynamic browser-based applications.

Native Client runs on 32-bit x86 systems that use Windows, Vista, Mac OS X, or Linux. Some ARM and x86-64 support is implemented in the source base, and we hope to make it available for application developers later this year.

Instead of worrying about Mono or Microsoft worrying about getting the sandbox right for the browser, let’s solve it once.

Then I can target the C# with the Mono CLI.

Or IronPython with the Microsoft CLR.

Or Ruby with JRuby. Or just MRI, if I want.

I’m certainly waving my hands over a lot of technical details. I know.

My thought is simply this: CLI as another Javascript is radical idea.

Perhaps just not radical enough.

Bag of Tricks Update (two years in the making)

Has it really been two years since the last official update of the Bag of Tricks?

I guess it has. A lot has changed since then. I started my own consulting company. And then joined up with Robby to launch Pixel Lab.

With previous releases, I was doing a very good job of breaking out almost all of the changes. This time, there are just too many. I’ll try to highlight the big ones.

• Added Org Tree. This is a pretty straight-forward sample of a vertical tree view.
• Added ReorderListBox. This is something Robby’s had for a while. I cleaned it up a bit for reuse.
• Added Show
• Removed the date controls. There are better versions in the official WPF Codeplex site.
• Created AnimatingPanel abstract class. This is now the base class for AnimatingTilePanel and TreeMapPanel. All you have to tweak is call the protected virtual ArrangeChild in ArrangeOverride.
• A bunch of additions to the Common assembly.
• Moved main development over to VS 2010.
• Added support for Silverlight 4. You’ll find projects nested in the same folder. You’ll also notice #define #if #else for SILVERLIGHT which handles some special cases where things don’t work in both places.
• Added Vector for Silverlight. This allows a bunch of my helper methods and animation methods to work without code changes between the two frameworks.
• Added ObservableCollectionPlus<T>. This has a ReadOnly property, along with support for Sort and adds Move to Silverlight OC<T>.
• …and a bunch of other stuff I’m likely forgetting.

You can get the source (via SVN) at Codeplex: http://bot.codeplex.com/

You can download a sample app that runs against WPF 3.5 here.

The BOT has been the basis for Silverlight, WPF, and Windows Phone 7 apps I’ve written this year. Robby and I are going to keep tweaking it and updating it as we need new stuff.

You should do the same.

File bugs. Submit patches.

Let’s make this our Bag of Tricks.

Happy hacking,

>Kevin

PS -> please make comments on the codeplex project discussion page! It's much easier to reply there. :-)

Google's Native Client belongs on the Server, too

What is Native Client?

Have you heard of Native Client (NaCl) from Google? Yet another open-source client software play from our overlords in Mountainview.

The write-up on the project site is pretty good:

Native Client is an open-source technology for running native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We've released this project at an early stage to get feedback from the open-source community. We believe that Native Client technology will help web developers to create richer and more dynamic browser-based applications.

Think of it this way:

Right now, the only way to play with the HTML DOM is with Javascript--Javascript with a surface area explicitly limited to the DOM.

Now imagine you could give any x86 the same explicit sandbox--with some clever run-type verification.

While we should all be worried about claims of safety, the promise of high-performance and language agnosticism is tempting.

Forget the CLR and the JVM.
x86 won a long time ago.

Now App Engine, Please

If Google really buys into the safety of NaCl, they should put their data center where their mouth is.

They've done a lot of work to provide Python and Java support on App Engine. Why not allow any language on App Engine with NaCl?

Instead HTML DOM being the "safe" surface area, make it HTTP request/response. Think CGI or (as a Ruby guy) Rack--expanded, certainly, for background tasks, datastore/memcache access, email, etc.

A revolution in back-end web programming

There's a painful gap between ease and flexibility on the backend.

Sandbox too Small

If you want ease, you're stuck with a limited "approved stack" at a host--Java/Python on App Engine, PHP/Rails at Dreamhost, etc.

You're stuck with Ruby 1.8.6 at Heroku. You're waiting for Google to support Python 3.0 on App Engine.

Sandbox too Big

If you want flexibility, you're stuck managing a Linux image on Amazon EC2 or Slicehost.

You have to worry about which Linux distro to run...if/when you should patch it.

Not to mention giving up all of the smart scaling one gets from App Engine-like solutions.

Sandbox just right

We need an abstraction layer that fills the gap.

NaCl seems like it would fit the bill.

Google could re-write their Python and Java sandboxes for App Engine to run within NaCl. At this point I'd wager, any language/framework--Ruby/Rails, PHP, or even old-school Perl/CGI could be tweaked to run there, too.

Google could open-source this sandbox, no doubt, providing a de facto, language-agnostic web server model.

Which sounds really nice to me.

Shipping Microsoft Singularity

Our friends in Redmond have been playing with the idea of allowing safe execution of 3rd-party code.

A research project called Singularity aims to allow high-performance and safety...but it feels like the all too common "boil the ocean" play from Microsoft. New tools, new languages, and a new operating system.

It's a project that's been public for 5 years, with little more than some channel9 videos to show for it. I fear we'll see a lot more research papers before we see any production-approved code.

Google's model with NaCl--"let's make x86 safe"--is ambitious, but tightly constrained. It also piggy-backs on a huge stack of open-source languages, frameworks and tools.


Native Client could be huge.
Huge in the browser.
Just as huge on the server.

Tweet This!

Thoughts on Google's client software strategy

We’d all like a peek inside the mind of Eric Schmidt—beyond just understanding what he’s wearing in his twitter profile picture. Search and maps and profiles: these all make sense. But there are a set projects that Google has been putting out lately that don't fit. They're open source and focused on the client machine.

• A browser.
• An operating system.
• An extension to HTTP - SPDY.
• An drastic evolution of AJAX - Web Sockets.
• A public DNS service.
• A drastic evolution in web programming - Native Client.

Some of these are put under the banner of "making the web faster".

Let me go a step further.

Google makes lots of money when you're clicking. The faster and more efficiently you consume their experiences, the more you click. The more you click, the more money Google makes.

But there are bumps along the way.

Crappy ISPs

Out-dated operating system.

Outdated and/or bloated browsers, protocols, and programming languages.

Google was silent on these for a long time--pushing existing technologies in novel or extreme ways--AJAX with Google Maps, Java Web Toolkit for Javascript, even shoe-horning Chrome into IE.

In the end, the've decided to cut out the middle man.

Ponder the stack of technology between you and Google's web offerings. When Eric Schmidt thinks about protocols, operating systems, and browsers--he has the same thoughts as Bill Gates did 20 years ago--about disk drives, CPUs and RAM.

Make them solid. Make them better.

But keep them out of the competitive picture.

Commoditize.

MSFT did it riding a wave of cheap PCs.

GOOG is doing it by riding a wave of free software.

Tomorrow. Seattle. Have a Mac? Wanna learn Rails?

I had a friend ask me if I'd be willing to teach him Rails. I said sure. Then I got to thinking: what would it take? Take a code-savvy person and teach them enough Git and Ruby and ActiveRecord to get them moving.

So I'm going to try it on Friday. Maybe just with Donald, but if anyone else wants to join us on Capitol Hill in Seattle, you're welcome.

Requirements:

1. Have done some coding.
2. Have some experience with web sites, HTML, etc.
3. Have a Mac.
4. Free on Friday, Dec 18, in the afternoon.
5. The catch: you must bring proof of at least a $50 donation to the EFF, Creative Commons, or WikiMedia. (If you're in a tight spot, we can talk.)

Drop me an email at ror4aday (at) j832 (dot) com if you're interested. I might do something slightly more formal in January, too.

See you on Friday.

Goole and reCaptcha: expanding Google's Cloud Brain

You've heard of Google Translate, right?

You know how it works? It learns:

Our system takes a different approach: we feed the computer billions of words of text, both monolingual text in the target language, and aligned text consisting of examples of human translations between the languages. We then apply statistical learning techniques to build a translation model. We've achieved very good results in research evaluations.

Heard of Google 411? Why would Google get into the 411 business? So it can learn. Read:

So we need a lot of people talking, saying things so that we can ultimately train off of that. ... So 1-800-GOOG-411 is about that: Getting a bunch of different speech samples so that when you call up or we're trying to get the voice out of video, we can do it with high accuracy.

So Google bought reCaptcha? Why? I'm betting it's the same reason.

It's not about finding one translation problem with one blurry word and fixing it. It's about learning how to read any and all blurry words. So it'll need humans to intervene less and less.

This is pure brilliance on Google's part: humans providing input--doing valuable work--and getting a valuable service.

And Mountain View silently reaps massive amounts of intelligence.

Google is throwing a lot of code over the fence--Java libraries, Chrome, Android--mocking the business model of traditional software companies.

And they don't care. Because in the end, they have a world-class, next-to-impossible-to-replicate cloud brain.

And it's getting smarter with every search, every new web page, every Goo411 call, and now, every new "You're a human, right?" verification.

Cool...and a bit scary.