jimmy.thinking

Speaking at WPI on 2008-11-24

noreply@blogger.com (Jimmy Schementi) — Fri, 21 Nov 2008 20:30:00 +0000

Monday, November 24 I'm speaking at Worcester Polytechnic Institute in Worcester, MA about what I've been doing since graduating in May 2007. There will be a trip down memory lane, Ruby, Python, .NET, Macs, Robots, Music, and spontaneity; it will be epic.

Jimmy hacking (at) Microsoft
Monday, November 21, 2008, 6pm
Fuller Auditorium, Fuller Labs
Worcester Polytechnic Institute
100 Institute Road
Worcester, MA 01609

I'm flying to NY tonight (woot for red-eyes) with Felicia, and then driving/busing (depends how much work is left to do ;)) to Worcester Sunday. Should be a fun couple of days.

If you're in the Worcester-area, stop by! Slides/Demos will be posted shortly after the talk, and I'm looking into recording.

Adding scripting to a C# Silverlight app

noreply@blogger.com (Jimmy Schementi) — Tue, 18 Nov 2008 06:30:00 +0000

At Microsoft, the people I work with and I are definitely the minority, preaching about the benefits of dynamic languages and using the right tools for the right jobs, as in don't use static languages where you don't need it -- though there are plenty of times where you need it.

And now you ask, "Jimmy, but why would I, someone who gets paid to write C#, use a dynamic language?"

The majority would only have static languages pulled from their cold, dead fingers, and I totally agree with them. Don't change for the sake of change. Though, for certain scenarios, running scripts in a VB/C# application would be useful. For example, a shopping application that has a bunch of business rules, like "when someone has three items in their cart that all have to do with cooking, give them 10% off." These type of rules can change all the time, and traditionally you'd either store the rules in a database and implement a engine to understand the rules, or hand-code them yourself and have to redeploy the system every time you want to change them.

Or, you could save yourself the hassle and store the rules as Python or Ruby code, and then host the DLR in your application to run the code. Want to update the rules? Just update the code, nothing more. And a dynamic language is probably closer to how the domain-expert would represent them as, so they could even write them. Yes, this is just one scenario, but a powerful one for existing static language developers. This was the last part of my Seattle CodeCamp talk -- how to host the DLR in your C# Silverlight application.

Starting with an existing C# Silverlight application that just takes some input and echos it back, I'll extend it to run the code through IronRuby and print the result. First, open the solution, and hit F5 to see that the app just echos what you type in the grey area. This requires you to have installed the Silverlight Tools.

Now add references to the DLR and IronRuby (in the Dependencies folder):

Let's write a little wrapper class run Ruby code. Open App.xaml.cs and add the following class to the SilverlightDLRDemo namespace:

class RubyEngine {
  private ScriptEngine _engine;

  public RubyEngine() {
    var runtime = new ScriptRuntime(
      DynamicApplication.CreateRuntimeSetup()
    );
    _engine = Ruby.GetEngine(runtime);
  }

  public object Execute(string code) {
    return _engine.Execute(code);
  }
}

Note: this exact code won't work on the Desktop; you'd have to just give the ScriptRuntime constructor no parameters. Here I use the DynamicApplication.CreateRuntimeSetup() to use the same ScriptRuntimeSetup object that Microsoft.Scripting.Silverlight uses, which knows how to map File system access to the XAP file, which is useful for dynamic languages to depend on other files. Of course, it's your decision to allow this or not.

You'll also need to add the following "using" statements:

using Microsoft.Scripting.Hosting;
using IronRuby;
using Microsoft.Scripting.Silverlight;

And that's it! That's all we need to run IronRuby code. Now let's hook it up to the page. Open Page.xaml.cs and add an instance variable to the Page class, and initialize it in the Page constructor:

// add to Page class
private RubyEngine _ruby;

// add to Page constructor
_ruby = new RubyEngine();

Lastly, replace the "Result.Text = ..." line with this, which prints the typed code, and then the result computed by the RubyEngine wrapper we just wrote:

Result.Text = "\n\n" + 
  ">> " + Code.Text + "\n" +
  (_ruby.Execute(Code.Text).ToString()) + 
  Result.Text;

Now hit F5 again, and type some Ruby into the TextBox, hit enter, and boom, you're C# Silverlight application is running IronRuby code.

In fact, this is exactly how AgDLR, aka the dynamic language integration with Silverlight, works -- a C# application (Microsoft.Scripting.Silverlight.dll) which hosts the DLR and runs a script file (app.rb or app.py). Take a look for yourself.

I hope that shows you how easy it is to host the DLR from a C# Silverlight application, and think twice when writing those complex rule engines. =)

"console=true": REPLs in Silverlight

noreply@blogger.com (Jimmy Schementi) — Tue, 18 Nov 2008 01:23:00 +0000

At Seattle CodeCamp v4.0 today, I talked a lot about REPLs, or "Read, Evaluate, Print Loops". They are the true "minimalist" view of programming; type a line, run a line. Most of them are no frills, only a terminal window and a blinking cursor, though they themselves could be really rich development environments. Also, REPLs are a vital tool for runtime-compilation languages, since the methods/variables/classes/etc are only *really* known to exist at runtime.

I started my talk with a Ruby REPL showing off how you can use IronRuby to explore .NET.

Ah, the beauty of two worlds colliding. You can use Ruby-idioms to explore the .NET types, starting with an A, B, or C, in the System namespace, just like they were Ruby classes to begin with. Call .NET methods, even with Ruby method naming conventions; IsInterface as is_interface.

The lurking awesomeness here is this REPL is running inside the browser! This is a HTML-based Silverlight application, which provides an IronRuby REPL. It accomplishes this by using the Dynamic Language Runtime (DLR) hosting APIs, but don't get hung up on the details of how that works, I'll explain later.

This is nothing *new* in my world. DLRConsole has been around for a while now, and lets you write code in the browser to manipulate a Silverlight canvas. Both REPLs are self-contained, as in they only work against code manually loaded into them, like the previous screenshot shows with loading in the clock.rb and drag.rb files. This is fine for trying small things out, but becomes very cumbersome when trying to interact with a live application.

To interact with a live application seamlessly, the bare minimum would be to have a REPL available directly in the application itself. And that's what I've done:

If you build the latest bits, you can add a new initParam option called "console" to enable a REPL in any application:

<object ... >
  ...
  <param name="initParams" value="console=true" />
</object>

This will inject a HTML-based REPL into whatever web page your app is running on. The language of the REPL is set to whatever language your start script is. To make the console pretty, add this stylesheet to your page. Eventually this stylesheet will be included in the templates script/sl produces.

In the screenshot above, I did not type/click anything on the UI; the code I typed into the REPL set the search term and "clicked" the search button. This type of integration with your application could easily produce Waitr-like automation, for testing and whatnot. I'd really like to see Waitr ported to IronRuby. =

But there's plenty more to-do: this console is very simple.

It only supports Ruby currently; though simple Python statements will work (white space is a bitch =P).
It supports single and multi-line statements, but since the text input is implemented on top of a <input> tag, browser history gets in the way =P
History works, but never resets itself.
If you make a typo, and it's not clear that you've intended for the statement to be completed (like typing "class <enter>"), you'll have to force the console to run the command with <ctrl>+<enter>

Please, play around with this new "usefulness" and let me know what you think. I'd prefer you to leave comments on github, so everyone can participate in the discussion. The code for the REPL lives in Console.cs, so if you want to fix something on the list above, or see something else broken, fix it! If you find more bugs, please post them to Codeplex under the 0.x.0 release.

Hope this little feature makes your live a bit easier!

agdlr: Silverlight + DLR + Open Source

noreply@blogger.com (Jimmy Schementi) — Mon, 17 Nov 2008 21:23:00 +0000

The "Silverlight Dynamic Languages SDK" Codeplex project has existed since March 2008, with signed binary releases and source code drops every month or so. Though it's a good ship vehicle for the Silverlight+DLR integration, it's not really an open source project -- mainly as it lacks a public source repository. That changes today.

AgDLR Source Repository

This repository will contain the sources to Microsoft.Scripting.Silverlight.dll and Chiron.exe, as well as Ruby/Python libraries for writing Silverlight applications. Any "feature" work on those pieces of code will be committed to the public repository first, and eventually make its way into MIcrosoft's internal source control so the DLR/Iron* languages don't break it. This repository takes a binary dependency on the Iron* languages as well as the DLR, since this isn't the place to change that code. The source code for IronRuby, IronPython, and the DLR are available elsewhere, but releases on the Codeplex page for this project will still contain source drops of everything.

The repository is hosted on http://github.com, which is a collaborative development site based around git, a "fast, efficient, distributed version control system ideal for the collaborative development of software". You can browse the sources on the website, look at commits, fork your own version of the repository, or just download a snapshot. If you're new to git, just install it (for windows, see here, and here). If you'd like to learn more about Github, or Git, Github guides is a good place to start.

If you'd like to contribute to AgDLR, fork your own version of the repository, commit your changes to your version, and send me a pull request on github. We'll take it from there.

I've already started to work on a new feature which I talked about at Seattle CodeCamp, but that's the next post.

Seattle CodeCamp v4.0

noreply@blogger.com (Jimmy Schementi) — Sun, 16 Nov 2008 19:36:00 +0000

I just finished speaking at Seattle CodeCamp v4.0 about dynamic languages in Silverlight, titled Browser, Meet Ruby and Python. Here's my abstract:

People entrenched in Visual Studio all day [sometimes] forget how powerful a command-line and a text-editor can be. Remember, these are the *tools* that built and continue-to-build the web. With nothing else up my sleeves (I wear short sleeves) I'll build a cool web applications with IronRuby, IronPython, ASP.NET MVC, and Silverlight, and show you why scripting/dynamic languages are powerful and productive tools.

Of course, that didn't end up being my exact talk, but close enough. I talked about REPL's, IronRuby, Silverlight, and Hippies. Here are the slides (rename it to pptx since my web server is reporting it as a zip mime-type), but I'll be making subsequent posts about the specific things I showed. Stay tuned!

Dynamic Languages in Silverlight 2 RTW!

noreply@blogger.com (Jimmy Schementi) — Wed, 15 Oct 2008 23:12:00 +0000

Silverlight 2 shipped yesterday! And, better yet, there's a new release of dynamic languages for Silverlight!

Download the SDK!

Note: it's the same version number as the RC0 release (0.4.0)

Since this post is devoid of content, here's a bunch of other posts I've made that are more interesting. Here are some announcement blog posts:

For more interesting posts/walk-throughs:

Dynamic Languages in Silverlight 2 RC0

noreply@blogger.com (Jimmy Schementi) — Wed, 01 Oct 2008 07:10:00 +0000

I've just released the Silverlight Dynamic Languages SDK with the newest DLR, IronRuby, IronPython, and JScript binaries and sources to work against Silverlight 2 RC0!

Download the SDK!

This release works with Silverlight 2 RC0. Keep in mind this is a developer release, so no "end-user" runtime exists. This is why the "not-installed" experience doesn't take you directly to the download, but to a page where you can install the tools.

As usual, report any issues on the Issue Tracker, and feel free to ask any questions on the Discussions tab.

This release has slightly refactored Microsoft.Scripting.Silverlight, adding two new types: "Package" and "Configuration". You can use "Package" to access files inside the XAP, and "Configuration" can be used to detect languages available in Silverlight.

Hosting

In past releases, if you wanted to host the DLR you needed to create your own ScriptRuntimeSetup which uses Microsoft.Scripting.Silverlight.BrowserScriptHost to tell your hosted scripts about how Silverlight. Your code would look like this:

using Microsoft.Scripting.Silverlight;
using Microsoft.Scripting.Hosting;

//...

var setup = new ScriptRuntimeSetup();
setup.HostType = typeof(BrowserScriptHost);
var runtime = new ScriptRuntime(setup);

//...

Now, since the ScriptRuntimeSetup we use to run user code is public, you can simply this code to:

using Microsoft.Scripting.Silverlight;
using Microsoft.Scripting.Hosting;

//...

var runtime = DynamicApplication.Current.Runtime;

// or if you wanted to create your own runtime, reuse the setup

var runtime = new ScriptRuntime(DynamicApplication.Current.Runtime.Setup);

//...

Future

Blah, blah, blah, I always talk about the future. Has anything happened? Nope. Well, it will eventually. Just keep pestering. If you have no idea what I'm talking about, take a look at my last post.

Compiling the DLR, IronRuby, and IronPython for ANY version of Silverlight

noreply@blogger.com (Jimmy Schementi) — Wed, 01 Oct 2008 06:25:00 +0000

I know you feel like this sometimes when trying to solve a problem. I do. Almost all the time. Even when I'm not angry ... but I digress.

Silverlight 2 RC0 was released this past Thursday, but anyone wanting to use the DLR in it was surprised ... no new binary release of the DLR bits for Silverlight 2 RC0 yet. As I said on Twitter, it would be delayed until today, but that shouldn't stop anyone from taking the sources and compiling them against the new SIlverlight build, right?

Of course! Everything should just work, since there were no major breaking changes in Silverlight that affect the DLR between Beta2 and RC0. So, you hacked up the csproj files to point at mscorlib.dll, system.dll, etc in the new Silverlight install directory (C:\Program Files\Microsoft Silverlight\2.0.30923.0), compile, and it builds fine. Then you try to run an app ...

"InitializeError- Failed to load the application. It was built with an obsolete version of Silverlight"

Poof! What the hell happened? That's a really bad error message, but what it means to say is:

"The application's AppManifest.xaml has a RuntimeVersion <= 2.0.30523.00, which is Silverlight 2 Beta 2's version number, so Silverlight 2 RC0 won't load this application."

So you see, the XAP file that was produced by Chiron is still for SL2 Beta2. But that's an easy fix;

Make sure Chiron.exe isn't running.
Go to your custom build, and edit Chiron.exe.config
Find the <AppManifest.xaml> section, and where it says "RuntimeVersion" make it's value be "2.0.30923.0" (anything with the first three version numbers being greater than the current will do, but be save and use the actual version.)
Re-run Chiron.exe, navigate to your Silverlight application, and .... it works!

Welcome to the wonderful world of versioning in Silverlight. :)

ASP.NET Dynamic Language Support Refreshed!

noreply@blogger.com (Jimmy Schementi) — Wed, 24 Sep 2008 01:21:00 +0000

Today, the IronPython team and the ASP.NET team released ASP.NET Dynamic Language Support on the ASP.NET Codeplex site!

Download it here!

Package

ironpython-webforms-sample.zip: running IronPython ASP.NET website. Either dump this in IIS or open with Visual Studio as a website project.

ironpython-mvc-sample.zip: and IronPython ASP.NET MVC website, so you can get a feel for how dynamic languages can integrate into MVC. However, this just shows IronPython working in Views, not Controllers or Models yet. This requires MVC to be installed to open the project in Visual Studio. Open it with Visual Studio, build, and run your shiny IronPython ASP.NET MVC app.

aspnet-dlr-docs.zip: Documentation on how to use all this stuff. Open intro.html and have fun. :)

Many Thanks!

This is a project that me, David Ebbo, and Phil Haack have been working on for a bit, and I'm so happy that the ASP.NET team is taking the DLR and committing to making dynamic languages work well on ASP.NET. Phil actually announced this on his blog as well, and I'm sure will be talking about this much more in the future. In short, a big thanks to David and Phil for getting this project kick-started again.

Walk-through: WebForms

Back in June I talked about this day coming, but I didn't even have a piece offering, other than my whit. To make up for that, I'm going to walk you through using IronPython in ASP.NET.

Note: I'm going to walk you through using Visual Studio to open the website and make changes. However, you can simply drop this directory into your IIS wwwroot and simply edit the files with a text-editor of your choice.

1. Extract ironpython-webforms-sample.zip, open Visual Studio, and then open a website project (File > Open > Web Site ...). Navigate to where you extracted the webforms sample, and click open; now you should see the following.

2. Take a look at the code in Default.aspx and Default.aspx.py. The aspx page has a asp:Literal control, with the id "messageLiteral", and the py file sets the text of that asp:Literal control.

<!-- Default.aspx -->
<%@ Page Language="IronPython" CodeFile="Default.aspx.py" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
    <head runat="server">
        <title>Untitled Page</title>
    </head>
    <body>
        <form id="form1" runat="server">
        <div>
            <asp:Literal id="messageLiteral" runat="server" />
        </div>
        </form>
    </body>
</html>

# Default.aspx.py
def Page_Load(sender, e):
    messageLiteral.Text = "Hello Dynamic World!"

3. Hit Ctrl+F5 (Start without debugging), and the app will run. If you are not using Visual Studio, simply navigate to Default.aspx in your web browser.

4. Awesome, our app runs! Now let's make it do something. Replace the inside of the <div /> with a Label, TextBox, and a Button control (Note: you can also open the Toolbox in Visual Studio and drag these in).

Enter your name: <br />
    <asp:TextBox ID="TextBox1" runat="server">
    </asp:TextBox>
    <asp:Button ID="Button1" runat="server" Text="Button" />
    <br /><br />
    <asp:Label ID="Label1" runat="server" Text="Label">
    </asp:Label>

5. Open Default.aspx.py and change the Page_Load method to be the following:

def Page_Load(sender, e):
    if not IsPostBack:
        Label1.Text = "...Your name here..."

6. Now add the following code to Default.aspx.py to handle the button's Click event:

def Button1_Click(sender, e):
    Label1.Text = Textbox1.Text

7. Switch back to Default.aspx.py and make the Button handle the event:

<asp:Button ID="Button1" runat="server" Text="Button"
     OnClick="Button1_Click"/>

8. Now navigate back to your browser, and refresh the page. Enter any text in the textblock, click the button, and it'll appear in the label below.

Yeah, I know, not very useful, but it gives you an idea of how things work. Look through the "ASP.NET Dynamic Language Runtime Support Documentation" on the downloads page for more walk-throughs with IronPython and ASP.NET WebForms.

Go make awesome stuff!

I'm so happy that this finally got out, so hopefully I'll hear about people starting to use IronPython in ASP.NET much more. Consult http://codeplex.com/aspnet for any questions about roadmap or tutorials, and feel free to ask me questions as well.

Silverlight Dynamic Languages SDK 0.3

noreply@blogger.com (Jimmy Schementi) — Sun, 31 Aug 2008 02:04:00 +0000

I've finally updated the Silverlight Dynamic Languages SDK with the newest DLR, IronRuby, IronPython, and JScript binaries and sources!

Download the SDK!
This release works with Silverlight 2 Beta 2.

For more information on what is in the SDK, check out the previous release's post or the initial MIX'08 release's post.

As usual, report any issues on the Issue Tracker, and feel free to ask any questions on the Discussions tab.

Version 0.3.0

One noticeable change is the "0.3.0"; where the hell did that come from!? It's going to be more necessary to have a proper version number after this release, since there will be a couple more releases between now and the next major Silverlight release. So, this release is 0.3, and the previous 2 releases are 0.1 and 0.2.

Packaging

Another noticeable change is the packaging; you've now got a 1-stop-shop for binaries, scripts, samples, and source code in the download labeled "Everything." The individual packages still exist as well.

Future

The releases after this will be as much about the Silverlight-specific experience, along with packaging up the new language bits to work together in Silverlight. Some future features being worked on are:

Better support for download-on-demand dynamic language code and assemblies
Tooling support in Visual Studio
Built in console for every app when debug=true
Better ruby stack traces
Startup improvements (running code in interpreted mode to start).

Name?

"Silverlight Dynamic Languages SDK" is a horrible name, and "sdlsdk" is an even more horrible acronym. We need a good/origional/non-suck name for it. If you have any ideas, hit me up on http://twitter.com/jschementi, or leave me a comment.

About the Silverlight Dynamic Languages SDK:

This project represents the integration between Silverlight and Dynamic Languages running on the Dynamic Language Runtime (DLR). The languages included in this package are IronRuby, IronPython, and Managed JScript. The DLR, Silverlight Integration, IronRuby, and IronPython are released under the Microsoft Public License

Dragging elements in Silverlight with DLRConsole

noreply@blogger.com (Jimmy Schementi) — Wed, 27 Aug 2008 05:34:00 +0000

Dragging elements around in Silverlight is not trivial, so I wrote a Drag class in IronRuby during a demo of DLRConsole to show how cool REPL-programming is. I did a 10-minute screencast of this same demo a while ago, but I've given this demo enough times that it deserves a post on its own.

Meet DLRConsole

Can't show dragging without having stuff to drag, can I? Well, rather than requiring you to download a bunch of stuff, let's just program in the browser. Yes, the browser.

DLRConsole (download)

You'll need Silverlight 2 Beta 2, but DLRConsole will tell you to install Silverlight if you don't have it.

If you haven't been introduced to DLRConsole yet, there she is. Pretty straight-forward; a Ruby and Python REPL prompt on the left for typing code in, and a Silverlight canvas on the right for pretty stuff to come out. Got it? Good.

Makin' some stuff to drag

So what do you want to drag around? I know, a clock? Of course, since we can't get enough of those freakin' things in Silverlight-land. I've done you a favor and build a clock already, so you don't have to. You're welcome. Click on the "Ruby" text on the bottom left to switch the console to Ruby, and then type the following in the prompt:

require 'lib/clock'
$clock = Clock.show

Awesome, a clock, in all it's majesty. You might have the urge to try to click said clock to move it ... go ahead, it won't bite.

Drag that face all over the place

Didn't move, huh? Sucks. Let's fix that. Go back to the console and type this:

require 'lib/drag'
Drag.new($clock.canvas)

And for the curious, here's the code in lib/drag.rb:

class Drag
  def initialize(obj)
    @click = nil
    @obj = obj
  end
  
  def enable
    @obj.mouse_left_button_down do |s,e| 
      @click = e.get_position @obj
    end
    Application.current.root_visual.mouse_left_button_up do |s,e| 
      @click = nil
    end
    canvas.mouse_move do |s,e|
      unless @click.nil?
        mouse_pos = e.get_position canvas
        @obj.left, @obj.top = mouse_pos.x - @click.x, mouse_pos.y - @click.y
      end
    end
    self
  end
end

Now click, hold, and moooooove! Awesome, we can move shit. Go ahead, get carried away. Try to find that "Silverlight Canvas" TextBlock and make that dragg-able too. Enjoy your new found powers.

Walk-through: Silverlight Flickr Client in IronRuby

noreply@blogger.com (Jimmy Schementi) — Wed, 13 Aug 2008 07:29:00 +0000

Yesterday I spoke about IronRuby and Silverlight to the .NET Developers Association, or "NETDA", on (Microsoft's) campus tonight. In this post, I'll show one of the apps I built, a Flickr client.

Here's the live app: http://jimmy.schementi.com/silverlight/photoviewer

Pre-requisites

This walk-through will work for both Mac and Windows, however the app seems to have problems in Safari currently. Firefox or IE will work fine.

For starters, you'll need install Silverlight 2 Beta 2, as well as download the Silverlight Dynamic Languages SDK (Beta 2), or "sdl-sdk" for short. Unzip sdl-sdk.zip to a folder named "sdl-sdk" anywhere on your file system.

You'll also need photoviewer-start.zip, which contains images and libraries that this app depends on. (You can also grab photoviewer-final.zip if you want to cheat)

Creating a new project

To create a Silverlight app, there's a script included in the SDK called "sl", which takes two arguments: the language (ruby, python, or jscript), and the name of your application. A folder will be created with the name of your app in your current directory, and a default app generated inside it. Enough talking, let's get to it ... open cmd.exe/Terminal.app/whatever and type:

$ cd path/to/sdl-sdk
$ script/sl ruby photoviewer

(Note: if you're on Windows, make sure to use backslashes "\" instead of forward slashes "/" in the path names)

This should say something along the lines of "Your ruby Silverlight application was created in photoviewer". It does for you too? Awesome, let's move on. So, what got generated? Inside the new "photoviewer" folder you'll find:

index.html - This hosts the Ruby Silverlight app. If you're curious as to what's going on here, there's documentation inline, so read it!

ruby/app.rb - Entry point to the Silverlight app. This generated file just renders app.xaml and sets some text from Ruby.

ruby/app.xaml - XAML UI for the app. Actually, we're not going to use XAML for this app, so we'll delete this later.

ruby/silverlight.rb - Defined "SilverlightApplication" and makes existing Silverlight API's friendlier to Ruby I gave you a newer version of this file in photoviewer-start.zip, so you'll have to overwrite this file with that.

stylesheets/error.css - In the unfortunate event of you writing bad Ruby code, this stylesheet will format the in-browser error message all pretty-like for you.

javascripts/error.js - In case you turn Ruby error reporting off, this file will still catch any errors and not cause your users to see some ugly alert box.

Running your newly created Ruby app

Enough talk, does this thing work? We'll, let's try ...

$ cd photoviewer
$ script/server /b:index.html

(Note "/b" is the same on Windows/Mac, always a forward slash since its part of the argument and not the path)

This will start a Silverlight development web server called Chiron, and launch your default browser at index.html. Using the "/w" flag just starts the server and doesn't open your browser. Anyway, you should see this (in your default browser, of course):

Adding external libraries

Before we can start coding, this app depends on some external libraries, so let's put them in our project now. Since I'm such a good guy, I put all the external dependencies in that photoviewer-start.zip file I had you download already. Yep, I'm awesome, you're welcome. Anyway, take the contents of that zip and place it in your project. Your OS may complain about overwriting silverlight.rb, but it's ok, overwrite it. Did it? Good. So, what did you just add to your app?

images/loading.gif - loading indicator gif thingy.

ruby/System.Json.dll - JSON parser that ships in the Silverlight SDK.

ruby/json.rb - requires and monkey patches System.Json to be more ruby-esk.

ruby/silverlight.rb - This app will depend on a more up-to-date version of silverlight.rb, so you can replace the generated one with this.

lightbox/ - A javascript library for showing images prettily. Love it.

Writing some freakin' code! UI, that is

As I hinted at before, this application with have a HTML UI with IronRuby driving it. Yes, you can use Silverlight without all the pretty graphics. ;) Anyway, to accomplish this, we need to make the Silverlight canvas virtually invisible. Open index.html and on line 28 change the width and height attributes from "100%" to "1":

<object data="data:application/x-silverlight," type="application/x-silverlight-2-b2" width="1" height="1">

By changing the width/height to "1", we're making the control basically invisible, but still actually visible so it still loads. Clever hack, huh?

Now let's give our app a UI. Type this after the "</object>" tag at the bottom of index.html:

<div class="search"> 
  <form id="search" action="javascript:void(0)"> 
    <input type="text" id="keyword" /> 
    <input type="submit" id="submit_search" value="search" /> 
    <img src="images/loading.gif" id="images_loading" /> 
  </form> 
  <div id="search_results"> 
    <div id="search_images"></div> 
    <div id="search_links"></div> 
  </div> 
</div> 
<div class="clear"></div>

This is basic search box, submit button, and a place to render the images found. Let's style it ... open up stylesheets/screen.css. First comes first; delete the #silverlightControlHost style since we don't want our 1x1 control taking up 100% of the page.

#silverlightControlHost {
  height: 100%;
}

Now let's style our plain UI we just made:

body { 
  font-family: "Trebuchet MS" Verdana sans-serif; 
  border: 0px; padding: 0px; margin: 0px; 
} 

div.clear { 
  clear: both; 
} 

/* main search box */ 
.search { 
  padding: 20px; 
  margin: 20px; 
  border: 10px solid gray; 
  background-color: #ccc; 
} 

form#search #images_loading { 
  width: 18px;  
  height: 15px; 
  display: none; 
} 


/* search results */ 
#search_results { 
  display: none; 
} 

/* search images */ 
#search_images { 
  padding-top: 10px; 
} 
#search_images .image, .image a, .image a img { 
  float: left;  
  padding: 0px;  
  margin: 0px;  
  border: 0px; 
} 
#search_images .image a:link,  
#search_images .image a:visited { 
  background-color: white; 
  padding: 5px; 
  margin: 5px; 
  background-color: white; 
  border: 1px solid gray; 
} 
#search_images .image a:hover { 
  background-color: #ff9966; 
} 

/* search links */ 
#search_links { 
  clear: both; 
  padding-top: 10px; 
} 
#search_links a { 
  border: 1px solid #003344; 
  margin: 2px; 
  padding: 0px 5px; 
  color: #003344; 
  background-color: white; 
  text-decoration: none; 
} 
#search_links a:hover, 
#search_links a.active { 
  color: white; 
  background-color: #003344; 
  border: 1px solid white; 
} 
#search_links a.active { 
  cursor: default; 
}

Refresh your browser and you'll see this:

IronRuby loves the DOM

Awesome, now we have a UI, but it does nothing ... Ruby enters stage left. Open up ruby/app.rb and let's start hacking.
The point of this app is to type a keyword, hit search, and see images from Flickr that have something to do with the keyword. So, I propose the first step would be to get Ruby handle that search button press. Agree? Good. Replace the entire body of the App class with the following:

def initialize 
  document.submit_search.onclick do |s, e| 
    puts "Search button pressed!"
  end
end

That will print "Search button pressed!" at the bottom of the page every time you press the search button. Duh, that's what the code says! =P

Ruby loves Flickr

Now that we know how to hook a button click with Ruby, let's make it talk to Flickr and get the data about our search back. First off, we need to know what to say to Flickr. So, let's redefine initialize to do the following:

def initialize 
  @url = "http://api.flickr.com/services/rest" 
  @options = { 
    :method => "flickr.photos.search", 
    :format => "json", 
    :nojsoncallback => "1", 
    :api_key => "6dba7971b2abf352b9dcd48a2e5a5921", 
    :sort => "relevance", 
    :per_page => "30" 
  } 
  document.submit_search.onclick do |s, e| 
    create(document.keyword.value, 1) 
  end 
end

We're going to talk to Flickr using REST, because we're sane. The @options hash simply collects the various parts that the REST call requires; we'll build a function to make this into a URL later. The important part is that we're calling flickr.photos.search and asking for the response to be JSON. The onclick event calls this cryptically-name create method which doesn't exist yet, so let's write it.

def create(keyword, page) 
  @options[:tags] = keyword 
  @options[:page] = page 
  request 
end 

def request 
  make_url 
  request = Net::WebClient.new 
  request.download_string_completed do |sender, args| 
    @response = args.result 
    show 
  end 
  document.images_loading.style[:display] = "inline" 
  request.download_string_async Uri.new(@url) 
end

I had a feeling I'd need to reuse create, so it just adds those arguments to the @options we built in initialize since they're also needed to be part of the URI, and call this request method. This is where the "talking" happens.

First, it makes the URL from the @options (we'll define that method soon enough). Then it news-up an instance of System::Windows::Net::WebClient, part of Silverlight, to actually make the request to Flickr. The images_loading.style[:display] = "inline" causes the loading indicator to start spinning. When the response comes back, I call show, which presumable should show the results in some way. For now, we'll just print the response, and stop our loading indicator.

def show 
  puts @response 
  document.images_loading.style[:display] = "none" 
end

Oh, and now would be a good time to implement make_url ;)

def make_url 
  first, separator = true, '?' 
  @options.each do |key, value| 
    separator = "&" unless first 
    @url += "#{separator}#{key}=#{value}" 
    first = false 
  end 
end

Nothing’s really special here, just puts the "?", "&", and "=" in the right places. Anyway, we're not ready to give her another run. Save app.rb, refresh your browser, type a search-term, click search, and you'll see the magic unfold:

Let's make this gunk pretty

So, what to do with all this Flickr data ... hmmm ... thoughts? Somewhere in that muck are some pretty pictures, so let's squeeze them out ... aka parse the JSON. At the top of app.rb, add the following:

require 'json'

That'll load that json.rb file we copied in the beginning. It simply monkey patches System::Json::JsonValue to give easier access to the data. Here's a loot at json.rb, just for fun.

require 'System.Json.dll' 
include System 

module System::Json 

  class JsonValue 
    def [](index) 
      item = self.get_Item(index.to_clr_string) 
      type = item.get_JsonType 
      return item.to_string.to_s.to_f if type == JsonType.Number 
      return item.to_string.to_s.split("\"").last if type == JsonType.String 
      return System::Boolean.parse(item) if type == JsonType.Boolean 
      item 
    end 
  
    def inspect 
      to_string.to_s 
    end 
  end 

end

This just adds the [] method to JsonValue so you can access JSON values like foo['bar'] where the JSON was foo = {'bar' : 'baz'}. Useful. Anyway, back to writing code ourselves. In app.rb, let's redefine the show method to parse our JSON and do something useful with it.

def show 
  @flickr = System::Json::JsonValue.parse(@response) 
  render 
end 

def render 
  @render = Render.new(@flickr, @options[:tags], @options[:page]) 
  document.search_images[:innerHTML] = @render.generate_photos 
  document.search_links[:innerHTML] = @render.generate_pages 
  @render.hook_page_events('search_links') 
  document.images_loading.style[:display] = "none" 
  document.search_results.style[:display] = "block" 
end

So, now show just calls System::Json::JsonValue.parse on our Flickr response, and then I've written a new method called render which delegates the rendering to a new class called Render (defining that is next), and stops the loading indicator. Let's make a new file called render.rb and require it in app.rb:

require 'render'

Open render.rb and let's first tackle rendering the photos:

class Render 
  def initialize(flickr, tags, current_page) 
    @flickr = flickr 
    @tags = tags 
    @current_page = current_page 
  end 

  def generate_photos 
    if @flickr['stat'] == "ok" && @flickr['photos']['total'].to_i > 0 
      tag(:div, :class => 'images') do 
        @flickr['photos']['photo'].collect do |p|  
          photo(p) 
        end.join 
      end 
    else 
      "No images found!" 
    end 
  end 

  def photo(p) 
    source = "http://farm#{p['farm'].to_i}.static.flickr.com/#{p['server']}/#{p['id']}_#{p['secret']}" 
    thumb = "#{source}_s.jpg" 
    img = "#{source}.jpg" 
    tag(:div, :class => 'image') do 
      tag(:a, :href  => "#{img}") do 
        tag(:img, :src => "#{thumb}") 
      end 
    end 
  end 

  def generate_pages 
    "" 
  end 

  def hook_page_events(div) 
  end 

private 

  def tag(name, options, &block) 
    output = "" 
    output << "<#{name}" 
    keyvalue = options.collect do |key, value|  
      "#{key}=\"#{value}\"" 
    end 
    output << " #{keyvalue.join(" ")}" if keyvalue.size > 0 
    if block  
      output << ">" 
      output << yield  
      output << "</#{name}>" 
    else 
      output << " />" 
    end 
    output 
  end 
end

A bit of code here, but it's all straight-forward, except for all these "tag" calls. The private tag method does most of the work here, but generating HTML based on a name and options; it makes writing HTML more ruby-esk. You'll also notice that generate_pages and hook_page_events aren't implemented yet. You can not implement them now, refresh your browser, do a search, and you'll at least get the images back:

Paginating the Flickrnation

Flickr only sends you one page of your request. When we created the options for the Flickr request, there was a :per_page => "30" entry, saying that I want pages of 30 images ... duh. When we call create(document.keyword.value, 1) on the search button click, that second argument asks Flickr for the 1st page of the request. So, to get any page we want, you just give it to the create function, and it'll give is that page. Told you we'd need to reuse it!
So, to implement generate_pages, we just need to render links for the pages, and to implement hook_page_events, we need to hook each one of those page links with an event that calls create for the given page. Simple enough ...

def generate_pages 
  render = "" 
  if @flickr['photos']['total'].to_i > 0 
    num_pages = @flickr['photos']['pages'].to_i > 10 ? 10 : @flickr['photos']['pages'].to_i 
    num_pages.times { |i| render += page(i + 1) } if num_pages > 1 
  end 
  render 
end 

def page(i) 
  tag(:a, :href => 'javascript:void(0)', :id => "#{i}") { "#{i}" } 
end 

def hook_page_events(div) 
  $app.document.get_element_by_id(div.to_s.to_clr_string).children.each do |child| 
    if child.id.to_s.to_i == @current_page 
      child.css_class = "active"  
    else 
      child.onclick { |s, args| $app.create(@tags, child.id.to_s.to_i) } 
    end 
  end 
end

Do the whole save/refresh/search song-and-dance and you'll have pretty paging action.

Ruby, you play nice with Javascript, ya hear!

This is pretty awesome ... ya know, Ruby in the browser and all. But truth be told, I like Javascript too. Especially since there are a ton of Javascript libraries out there.

That being said, I'd like to spruce up the "clicking on an image". Right now it opens in a completely new page, and breaks the back-button since your search is wiped away. It's be awesome to have some cool visual effect when clicking on the image, and even having it link to the real Flickr image page. Only if there was such a library ...

http://www.huddletogether.com/projects/lightbox2/

Like I said before, Lightbox is awesome. So, to pretty up zooming in on an image, we'll use Lightbox. First, let's go back to index.html and add some references to Lightbox:

<script type="text/javascript" src="lightbox/js/prototype.js"></script> 
<script type="text/javascript" src="lightbox/js/scriptaculous.js?load=effects"></script> 
<script type="text/javascript" src="lightbox/js/lightbox.js"></script> 
<link rel="stylesheet" href="lightbox/css/lightbox.css" type="text/css" media="screen" />

Lightbox uses special properties on the anchor tag to store information about the image you are viewing, like if it's part of a collection, or what the title of the image should be, etc. Let's go back into our Render#photo method and add a :title and :rel values to our :a tag.

So, the entire tag(:a) call turns into this:

tag(:a, {
  :href  => "#{img}",  
  :title => "&lt;a href=&quot;http://www.flickr.com/photos/#{p['owner']}/#{p['id']}&quot; target=&quot;_blank&quot;&gt;#{p['title']}&lt;/a&gt;", 
  :rel   => "lightbox[#{@tags}]" 
}) do 
  tag(:img, :src => "#{thumb}") 
end

Lastly, let's initialize Lightbox when we show the response. Put the following after the render call in the show method in app.rb:

if document.overlay && document.lightbox 
  document.overlay.parent.remove_child document.overlay 
  document.lightbox.parent.remove_child document.lightbox 
end
HtmlPage.window.eval("initLightbox()")

That last line isn't the prettiest, but our images are all pretty.

And we're done!

Congrats for getting this far! Now waste time searching for "boobs" or other dirty things on Flickr.

Run Chiron with a right-click

noreply@blogger.com (Jimmy Schementi) — Wed, 30 Jul 2008 03:21:00 +0000

About a month ago Phil Haack posted a registry hack to run the ASP.NET Web Server from a directory's right-click menu, and I thought it would be pretty awesome to have some right-click options for Chiron. Finally decided today would be the day for that:

↓ Download chiron-here.zip

Note: You will need to have the Silverlight Dynamic Languages SDK for any of this to work; only sdl-sdk.zip is required.

Installation (please read!)

chiron-here.reg assumes that you unzipped sdl-sdk.zip into C:\sdl-sdk. If this is not the case, open chiron-here.reg in your editor of choice (notepad will do) and change the two paths to point to your sdl-sdk location.

To install, simply double-click on chiron-here.reg. Say *Yes* to the prompt if you *really* want to install it. That's it! No reboot required.

Take a look at the README for usage. If you're a Windows person hacking Silverlight with Ruby/Python/JScript, this could definitely be useful. Enjoy!

Browser, meet Ruby on Rails

noreply@blogger.com (Jimmy Schementi) — Thu, 24 Jul 2008 21:55:00 +0000

John Lam is announcing a bunch of good IronRuby stuff at OSCON today, mainly around the project's commitment to open source. Part of this commitment is being able to collaborate with the Ruby community on projects that are related to IronRuby. This is where I fit in. :)

At RailsConf John Lam and I gave a talk about IronRuby, Rails, and Silverlight. We showed IronRuby running Rails, as well as the beginnings of an integration between Silverlight and Rails. I've hinted in the past about this very thing, but RailsConf was the first time I got to show it to working to actual Rails developers. Pretty awesome. Today, I get to share it with the world:

silverline is a Ruby on Rails plug-in which gives the ability to run Ruby in the browser to manipulate HTML, vector graphics, or just do some computation. Bottom line: it let's you write Rails code that can run on the client.

Check out the website: http://schementi.com/silverline.

And, most importantly, you can download the plug-in from github: http://github.com/jschementi/silverline.

Also, you can submit bugs/feature-requests on lighthouse: http://silverline.lighthouseapp.com

This is all possible because of Silverlight, the 4 megabyte download of the .NET Framework, and IronRuby, the implementation of Ruby on .NET and the Dynamic Language Runtime. silverline lets you do anything you can do in Silverlight with IronRuby, but it's a first-class part of your Rails application, and makes things a whole lot easier.

To see silverline in action, take a look at the demo site: http://silverline.schementi.com. The source is located at http://github.com/jschementi/silverline-demos. I will be posting walk-throughs of silverline's features shortly. Enjoy!

Note: "silverline" might not be the name of this thing in a couple days, so if you see something else on my blog that seems the same but has a different name, then it's the same thing.

ASP.NET and Dynamic Languages

noreply@blogger.com (Jimmy Schementi) — Fri, 04 Jul 2008 00:04:00 +0000

In the last year, my team @ Microsoft hasn't really done much with ASP.NET. Unfortunately so, since our focus has been on the languages themselves. Though, we have an integration with Silverlight, so why is ASP.NET left out?

That's definitely changing, 'cause now ASP.NET and Dynamic Languages are like this:

... but, that's not to say that we did nothing in the last year:

ASP.NET Futures

In July 2007 the ASP.NET Futures Release contained Dynamic Language Support in ASP.NET, giving you IronPython and Managed JScript as programming languages in ASP.NET. It also had a ton of other good stuff in there, like AJAX futures, Silverlight controls, and Dynamic Data Controls. If you're interested in learning more about this, take a look at the Dynamic Languages in ASP.NET Quickstarts.

The problem with this release is it's a one-off; as in "who the hell knows when this stuff is going to be updated." Also, IronPython releases every month, so the IronPython bits in this release were old fast. And sitting here a year later, a lot has changed! The release is really intended on being a "look at what we *might* do in the future", and a year without anything substantial is way to long in our world.

More so, there is no support for IronRuby. Even today we're not as far along as people would hope. I have a couple "Hello, World" aspx pages using IronRuby running on my machine, but that's really the extent of it. Sucks.

Shout out: Being able to use DLR languages in ASP.NET and Dynamic Data Controls are both the blood and sweat of David Ebbo, an Architect on the ASP.NET team, and the cool guy I got to give a talk with two years ago as an intern.

ASP.NET MVC

Tangential to the whole "holy crap why can't I use Iron* in ASP.NET" issue is giving the "when is my IronRuby going to be in ASP.NET MVC" drones something to chew on. And at TechEd 2008, John Lam gave them some slivers of meat:

IronRuby and ASP.NET MVC. Also, Phil Haack followed up with a IronRuby and ASP.NET BFFs Forever post. Yes, very cute. =)

Anyway, no real bits are out there yet for this, but we do have proof for ourselves that ASP.NET MVC aren't doing things that alienate DLR languages. Woohoo! Now it's just a matter of doing it right and getting it out the door.

Next stop: the Web Server

Today we run on the client, which can be represented by cmd.exe/WPF/WinForms, as well in Firefox/Internet Explorer/Safari with Silverlight. However, the web server has been fairly uncharted by us. This is what we're changing.

Really, this whole post is about DLR Languages and the web server. The DLR in ASP.NET and ASP.NET MVC (yes, they are different. yes, it's confusing).

But it extends past Microsoft web frameworks. At RailsConf 2008 John Lam showed IronRuby running Rails, and I showed integrating Ruby on Rails with Silverlight to nicely have Ruby on the server and the client (more information on the plugin soon).

It's all about making the Microsoft platform, being Windows or Silverlight, valuable to developers.

Next steps

All this kind of leaves you, the dude/dudette trying to get something done, at a loss, since any bits we have are a year old, and with all these pretty words, I've given you nothing but some continued hope. Wow, I'm cynical.

Not really sure about what's next, other than a ton of coffee with David and other folks on the ASP.NET team, trying to figure out how to get this stuff into your hands. We're pretty addicted to Codeplex, so I'm pretty sure it'll find it's way there. However, we need to finish building it, so that's got to happen first. Again, that will be more coffee. Or expensive juice, I've been hooked on that stuff.

So, with that, all I've got to say is "Stay Tuned" =)