It’s probably too early to start building full client/server projects
using IronRuby, though I am confident the day will come when WPF
development is primarily accomplished using DLR languages and
frameworks. Our shop is also heavily client/server, still using mostly
Windows Forms, and the major potential for IronRuby to add value to our
existing products falls into five categories:
You say you don’t see much added value in using IronRuby in these
scenarios, but I would challenge you to do some real world proof of
concepts. I think you will eventually find the flexibility and dynamic
nature of Ruby blows the standard .NET tooling out of the water from a
productivity perspective. These kinds of tasks are inherently prone to
constant flux and change and are best built in rapid iterations, and
having a dynamic/interpreted language optimized for simplicity is of
immense value.
the front end OR back end
Eventually, you may want to allow your customers (or even your dev team)
to be able to react in custom ways to domain events occurring in your
applications. A dynamic language is perfect for this.
Chances are your applications react to and generate a number of business
events, or domain events. It is likely that at some point, if not
already, your users will want your applications to integrate with other
systems. Your applications may also be required to communicate with
humans, via automated e-mails, sending SMS messages, etc. Giving your
application servers the ability to prepare some event data related to
each domain event and pass it off to dynamically discoverable Ruby
scripts/handlers when these events occur gives your application
tremendous flexibility to easily integrate with almost any system or
platform at the drop of a hat. If you have a customer that wants to call
a partners web service when something happens in their workflow, you
just write a script for it. If the partners system is archaic and
watches the files system for dropped files, you can generate that file
in a few lines of Ruby too. Maybe your customers have IT departments?
They can write their own scripts. As for integrating incoming data into
your application, Ruby is also very good at transforming incoming data
structures or DTO’s into your domain objects, as you can react to
changes in partner services without having to do a full, versioned
deployment process on your clients and servers.
Finally
Being a dynamic, interpreted environment, you can easily put together a
REPL, or interactive console, that can
be launched within the process of your desktop clients or your servers
(via command line) that can allow your operations people to dynamically
probe the running state if those processes. This can be quite useful in
certain troubleshooting or tech support scenarios. By making this shell
environment available remotely (by integrating with a .NET SSH server,
for instance, there is one on codeplex, will take some work but I’ll
have a library out soon to help) you can make your application
externally scriptable for your operations department from any location,
even an iphone (which has many SSH apps)
The main point is that any place in your project that is likely to be
customized on a per-deployment basis, or is likely to change in business
time, which is a must faster rate of change than any infrastructure code
you have, is a very good candidate for using a dynamic language, DLR and
IronRuby. Given that IronRuby can easily call into any static .NET
DLL’s, you lose nothing and gain the flexibility to allow your
application able to morph to meet new business conditions (particularly
at the interface of your application and the rest of the world) very
rapidly.
From: [email protected]
[mailto:[email protected]] On Behalf Of Patrick Brown
Sent: Wednesday, November 11, 2009 10:17 AM
To: [email protected]
Subject: [Ironruby-core] why use IronRuby
Hello
I have been playing with IronRuby 0.9.2 for a week or so and I have
to say that it is alot of fun to tinker with, I am having alot of
trouble trying to figure out where I would really use this though
besides maybe in writing scripts to do little things or to help out with
builds. My development is all desktop Client/Server code. I see people
mention testing and rapid development, I think I can actually develop a
fair bit quicker given current tools. I really am interested in working
this in if I can see some areas that it would be helpful.
Thanks,
Patrick