General advice

Hi

For the book I’m writing on IronRuby I’m deciding which way to go to
demonstrate how IronRuby can leverage the .NET framework.

The beginning of the sample application should implement some database
layer. My first instinct is to go with Linq-to-SQL and consume those
classes
from a ruby application.
I have a problem with ActiveRecord that comes with Rails, because often
it
doesn’t allow me to the things I want to do out of the box. And when I’m
in
App Dev mode I don’t really want to think about customizing the
framework
I’m using so that it fits my needs. I should just have to configure it
and
start developing. For this reason I don’t consider ActiveRecord to be
sufficient for most enterprise database systems and definitely not
legacy
ones. I don’t think it would be a good idea to let .NET devs jump to an
ORM
that won’t handle the more complex enterprise scenario’s out of the box.
I’m thinking of writing a real ORM for Ruby ala NHibernate one that uses
a
DataMapper with an IdentityMap backed by a Unit Of Work, when I’m
finished
with the book. It should also have Sql Generation that is highly
optimized
for each platform it supports (not just say because mssql is from ms we
won’t provide the best support for it we can) and maybe make it support
linq-to-sql syntax. Obviously I can’t build that in 2 days so I’ll have
to
drop that idea for a while :wink:

A second option I have in mind is rolling my own implementation of the
ActiveRecord pattern, using database reflection, an ADO.NET backend and
metaprogramming since it has a very limited scope for the book. I’m
always
much in favor for a unit of work implementation for my dataaccess.

At this moment I’m favoring the Linq-to-Sql (C#) approach because it has
benefits :

  1. I demonstrate interop with one of my own project assemblies and how
    you
    can extend that using IronRuby.
  2. I don’t have to write my own ORM
  3. I won’t be stopped in my writing by features that haven’t been
    implemented yet.

The downside of that approach is that it will be hard to show an example
that makes real extensive use of metaprogramming.
A second concern I have for the Linq-to-SQL approach is that that will
only
work on a windows box, because I don’t think the mono-project has an
implementation already.

Then a last way of doing it would be to use ActiveRecord from the castle
project or SubSonic where the ActiveRecord implementation of the
CastleProject will be the one that handles most edge cases. The reason I
bring these 2 up is that I already got questions from people asking me
to
put examples up on my blog about using those things from IronRuby. At
this
point I haven’t put too much on my blog yet because I’m pretty busy
writing.
And I think every week I wait I’m more close to being able to use as
much
pure ruby as I can.

Any thoughts ?

Cheers
Ivan

Hi Ivan, I have some thoughts. I know I’ve been away from this list a
while, sorry about that.

On Jan 4, 2008 12:07 PM, Ivan Porto C. [email protected] wrote:

Hi

For the book I’m writing on IronRuby I’m deciding which way to go to
demonstrate how IronRuby can leverage the .NET framework.

The beginning of the sample application should implement some database
layer. My first instinct is to go with Linq-to-SQL and consume those classes
from a ruby application.

Ultimately, we should be able to call any .NET lib from IronRuby. So to
an
extent I don’t think it matters what your pre-existing data access layer
is
written in, as long as it is valid .NET code.

That said, if I were buying a book on IronRuby, I would want to know how
Ruby approaches data access. I already know ADO.NET, and possibly the
various.NET-based ORM frameworks. What I probably don’t know are the
Ruby
libraries like DBI.

I have a problem with ActiveRecord that comes with Rails, because often it
doesn’t allow me to the things I want to do out of the box. And when I’m in
App Dev mode I don’t really want to think about customizing the framework
I’m using so that it fits my needs. I should just have to configure it and
start developing. For this reason I don’t consider ActiveRecord to be
sufficient for most enterprise database systems and definitely not legacy
ones. I don’t think it would be a good idea to let .NET devs jump to an ORM
that won’t handle the more complex enterprise scenario’s out of the box.

Regardless whether you consider ActiveRecord sufficient, alot of
developers
will want to know how to use ActiveRecord from IronRuby. I think you
are
missing an great opportunity if AR isn’t covered, along with what
changes
might be needed to get it to work with IronRuby.

Besides, there are always the other ORM libraries that you can cover
which
may be a closer to what you think a good ORM should be:

DataMapper - http://datamapper.org/
Sequel - http://sequel.rubyforge.org/
rBatis - RDoc Documentation

metaprogramming since it has a very limited scope for the book. I’m always
The downside of that approach is that it will be hard to show an example
point I haven’t put too much on my blog yet because I’m pretty busy writing.
And I think every week I wait I’m more close to being able to use as much
pure ruby as I can.

Any thoughts ?

If it were me, I’d avoid anything that required readers to use any
language
other than IronRuby. Good luck!

Hi,

Few Suggestions here.

(1) Do Not Avoid Active Record at any cost. Active Record and Migrations
should be covered in depth. SubSonic is working very hard to get major
parts implemented in Asp.Net MVC and General Asp.Net soon. Plus…
Subsonic is very famous due to Active Record only. Majority of
Developers will jump into IronRuby to take full advantage of Ruby and
Ruby on rails.

As per “Rob Connery” he is suppose to write a book on " SubSonic and MVC
", you may talk to him about his coverage with MVC and get a rough idea
about Subsonic and Active Record implementation in Asp.Net.

(2) Start building an existing Startkerkit in IronRuby, along the way
you explain IronRuby. A Real life approach will be highly appreciated.
You get 3 advantages with it…

(a) Existing Starterkits are discussed with a working site in VB and C#
currently and hence are easy to discuss further.

(b) Existing developers gets an idea about comparing dynamic language
with C#/Vb. They will know what a clear syntax and ironruby code can do.
How many coding lines are saved by comparing C# with Ironruby.

(c) New R. developers entering IronRuby gets a treat of working
example

(3) Try to make IronRuby + Asp.Net a mission. Do not waste much efforts
teaching Ruby in your book. Plenty of Ruby books are already available.
Developers/Students will prefer to read a Book that implements Ironruby
with Asp.Net and get it started immediately.

(4) Since this is a first ever book on IronRuby… It would be better to
get more and more suggestions that the Ruby community wants for a real
life approach.

There are plenty of hopes build up on IronRuby and your book should not
let them down. Mr. John L., has taken a practical approach by choosing
this RubyForge rather than Codeplex, since he wanted more and more
developers to share. Taking the same approach will justify your efforts
and get the real Ironruby out.

(5) IronPython ( Few Chapters ) and Jruby books are also available as a
reference.

(6) Do not waste pages explaining the advantages of DLR , Asp.Net and
.Net framework. You can always give links for further reference.

(5) I am just pointing a very good blog, that clearly requests MSFT to
stop wasting much time on C# 4.0 and rather send few more hands to
IronRuby team. They all are banking on IronRuby.

http://codebetter.com/blogs/jeremy.miller/archive/2008/01/02/c-vnext-take-2.aspx

I am just suggesting it, since i have read plenty of books and know what
helps in real life. Wrox publisher’s " Beer StarterKit " is very famous
and preserved on shelf. You can also take inspiration building such a
kit with Ironruby or other existing Kits, which can help in Real Life.

Learn… Gain… and Earn… Should be the motto of the book.

After all… you are the author… you are the better judge.

Thanks for listening me.

SoftMind.

Thanks for that.
I can’t believe I didn’t know about DataMapper and rBatis, those seem
like a
better fit to what I want. I can follow your reasoning on ActiveRecord
and
it does have some weight for me, most people will be using active record
because it comes with rails.
I guess I could take some relevant snippets from that source code to
illustrate how it has been done, because i wanted to use a model layer
as an
example of metaprogramming. I’ll have a play with the ones you just
proposed
and maybe cover one in addition to ActiveRecord so that readers know
there
are options. The Sequel one looks like a nice and easy one to use.

At this point I’m only planning to talk about using another .NET
language
for illustrative purposes but I want to create a pure ironruby solution
that’s for sure. However talking about IronRuby wouldn’t be complete
without
talking about the Iron in IronRuby and highlighting some of the interop
possibilities there are too. Because suddenly you’re not limited anymore
to
libraries in your favorite language but you can use libraries from a
collection of languages and a more vast community. That being said
about
99.5% of the code samples will be Ruby.

The book will take the reader through building an application built with
IronRuby that leverages most of the .NET technologies like WPF,
Silverlight,
ASP.NET MVC, Webforms etc.
I don’t really want to spend a lot of time explaining rails, because
there
is also plenty of information available about rails, but i will show
that
you can do with rails and IronRuby. I’ll also demonstrate how gems can
make
your life easier etc.

A downside of showing WPF is that the reader won’t be able to run those
samples on mono, or will he?

Keep the feedback coming, I like it :slight_smile: