IronRuby

I'm going to miss my first RubyConf since 2005. The IronRuby project is still going strong, and is in the capable hands of Jimmy Schementi. It's heading towards a 1.0 release (0.9.2 today), and Jimmy is going to lay out what that roadmap ... [More] looks like at RubyConf on Friday. So what have I been up to? I've been a happy IronRuby user since December, and working on a fantastic new project. It really was one of those opportunities where I was in the right place at the right time with the right preparation.These days I'm spending a large chunk of my time building an awesome new team from scratch from folks who are currently at the company. Before this year is out, we'll be announcing (in broad terms) what I've been working on since last December and I'll be expanding hiring to folks who aren't currently at the company. I'll also finally be able to talk about what I've been working on. It wasn't easy leaving the IronRuby team, and I'm hopeful that you'll love what we're building as much as we love building it! Permalink | Leave a comment  » [Less]

Dynamic languages on .NET are picking up momentum at this year's TechEd. Your typical TechEd attendee is a mainstream .NET developer, since this conference focuses on technologies that are shipping today (as opposed to futures conferences like ... [More] the PDC). To speak more to this crowd, I focused on how they can make their existing .NET apps better by mixing in some end-user scripting. My talk was DTL332 if you're a TechEd attendee (not sure when/if the videos will open up to the general public). I showed how you can add Ruby and Python scripting to an existing app, and spent some time building some simple REPLs. Toward the end of the talk, I showed a more realistic scenario where I embed a REPL in an existing Open Source .NET application: Witty. During the demo, I showed off a twist on the traditional REPL - one where the editor and the REPL are one and the same. To run code in this REPL, you select the code that you want to run, and the output appears immediately below the selection. Since the REPL is just an editor, you can just delete any output that you don't want. History behaves just fine as well. Here's a screenshot of the REPL in action: There are a couple of other notable things in this REPL. First, it syntax colors the text that ran correctly. Second, it supports more than one .NET language - you can switch between Python and Ruby using %python and %ruby (although whether that's a good idea is left to the reader). Third, all of its configuration is self-contained inside of a single DLL. This means that all you need to do to add scripting support for your app is add a reference to a single assembly. The assembly will write all user configuration files to well-known locations on disk (within your HOME directory) the first time it is run. This idea of a REPL within an editor buffer isn't new by any means. I've been spending some time hanging out with Mark Hamburg recently, and this is his favorite way of implementing a REPL (he's done quite a few, including the embedded IDE that the Adobe Lightroom folks use to build Lightroom). He won me over on the idea, so I thought that I'd hack up an implementation for folks to experiment with. I pushed the code up to Github as the repl-lib project, so feel free to fork, play with the code, and send me some feedback on the idea. Note that there's a nice long tail of bugs in this REPL, so feel free to fix bugs and submit changes! Here's a screenshot of the Witty main window; notice the console button: Here's a sample console session: The last line of code causes the Witty UI to display: After poking around inside Witty, I think there is some work that needs to be done to make scripting truly a first-class citizen in the project. While some might look at this as bad news or an indictment of Witty, it really isn't. Any project that isn't designed for such an invasive feature will likely make lots of assumptions that make it hard to make that feature successful. But the good news here is that if you use scripting as a end-user feature to drive your refactoring efforts, you will wind up with an app that is easy to script, but more importantly, is better designed. I argue that your design is better because it's forces a clean separation of concerns in your code: especially your models and your views. This separation of concerns will make it easier to test your end-to-end scenarios and script your integration tests. This all adds up to better software for everyone. I've made it pretty easy to add scripting support to your app. Grab the repl-lib project and spend a few minutes (that should be how much time it takes) to integrate scripting into your project. If you're interested in how much work it took to integrate these changes into Witty, check out this diff; most of the stuff is VS-related, and ReplResources.xaml is no longer required in current builds of repl-lib: Permalink | Leave a comment  » [Less]

It’s under the Power Manager settings: Permalink | Leave a comment  »