Articles tagged 'ruby'
Ruby link round-up Feb 24 2008
I’ve seen a number of great Ruby articles, tutorials and discussions recently (and not so recently), as well as some interesting projects, so I thought I’d write a quick round-up of links to some of the most interesting stuff. It’s split by category, with a miscellaneous list for stuff that didn’t seem to fit anywhere else.
- Merb
- Amazon EC2 + S3
- iPhone
- Books
- Another post from Ezra, who happens to be one of the authors of ‘Deploying Rails Applications’. This post says that the book is now at the final beta stage, and includes some more advanced content such as Apache/Nginx scaling, and Xen setups. I’ve just ordered up the beta PDF, and will be receiving the paperback too when it ships in May. Hoping to do an initial review once I give the beta a read, looks very interesting though.
- Tools and projects
- Heroku, online Rails application creation and hosting. Very cool tool for creating or collaborating on a hosted Rails application, all through your browser.
- Rush, a Ruby based shell, from one of the guys behind Heroku. Interesting concept, along the same sort of lines as Windows Powershell - but because it’s Ruby, it has a much better syntax :-)
- An article about the usage of Beanstalk, a messaging queue system, to power the Nuby on Rails blog.
- Hot off the presses, a new Capistrano preview, with some cool features such as better role definitions, and better git integration.
- Miscellaneous
- An article on generating feeds using microformats within html.
- Good post from 37signals about building a web app, and making sure you get it right - even if it means starting over.
- An article on using Ruby for scripting tasks on Mac OS X.
- Interesting article on tackling master/slave database setups with Rails.
- Great screencast on PeepCode about git, a source control tool that is all the rage at the minute. Really good introduction to the tool.
Hot Routes Feb 10 2007
Last day or so I’ve come up against a couple of intriguing Rails problems while trying to knock up some plugins for an app I’m writing. I’ll write up the second of the two problems later, but here goes the first…
Put simply, I wanted to define a route within my plugin. My plugin implemented a controller (and also contained a view for that controller, see one of the latest features to hit edge Rails ahead of Rails 2.0).
I searched to try and see if anyone had come up against a similar task, but didn’t see any concrete answers. My testing led me to realise that every time a call to ActionController::Routing::Routes.draw is made, it completely clears and re-generates routes based on the block passed to that method. So simply calling draw with a new block containing my required route wouldn’t work; it’d overwrite other routes, or end up getting overwritten by other routes later in the chain.
I then figured it was time to get cracking with some meta-programming, and that I was going to have to re-define and extend the draw method in order to be able to map the routes I want, and do it in a way that’d be flexible and fair to the original Rails routes file, and other plugins that wanted to toy around with routing. I came up with the following:
module ActionController
module Routing
class RouteSet
alias draw_old draw
def draw
draw_old do |map|
map.connect "controller/action", :controller => "mycontroller", :action => "myaction"
yield map
end
end
end
end
end
Let’s give this a quick run-through… I’m re-opening the ActionController::Routing module, and specifically the RouteSet class where the draw method exists. I’m using alias to copy the existing draw method to a method name “draw_old”, before re-defining the draw method itself. Within my version of the draw method, I’m calling the old one and passing it a block that firstly defines the routes I wanted to add to the application, and that then yields the appropriate mapper object back to any block passed in to the draw method itself. Dependent on where you want your route to appear in the scheme of things, you could always map your plugins custom routes after you yield the mapper to the calling block, so that they appear after any other routes. Another tweak would be to alias the existing draw method to something like “draw_old_APPNAME”, where APPNAME is the name of your application. This would ensure that if multiple plugins implemented something similar, that they then wouldn’t clash.
There may be a better way to tackle the problem, but after half an hour of working the problem over (mad props to my boy Mike for helping me tweak the solution into something useful and re-usable), I think I came up with a pretty solid answer, and with a bit more time, something that could probably be wrapped up into a module or plugin all of its very own. Bottom line? Ruby as a language rocks, the dynamic nature and meta-programming features opens whole new doors of functional programming to me, and I’m having to really think outside of the box to see some of the amazing things you can do with it.
Debuggering Feb 5 2007
This is a pretty nice idea, and looks like a really useful tool. It’s in a fairly early stage, but it is shaping up to be quite nice. Think I’ll grab it, take a look, and see if I can help out somehow…
CommentsRubySharp Aug 22 2006
Recently I’ve been toying with John Lam’s pet project, RubyCLR. The very notion of Ruby and C# interaction interests me, as there are around a billion different situations in which I’d like to combine the two, to get the best of both worlds.
Now, I notice in a post today, that he has spotted that Tim Ng, a guy who works on the Visual Basic compiler team, has been playing with his creation. Only, the way he went about it seemed a little complex, and wasn’t using RubyCLR’s compatibility with interfaces to the max. So, I thought I’d outline a little test scenario I knocked up when I first started playing with it.
I’ll assume that you’ve followed the instructions, and are setup with the latest version of RubyCLR (I was using the code straight from the source tree).
Firstly, the code for the C# side of things (the “host”). This defines the interface, and provides a class for executing implementations of the interface:
Host.cs:
using System;
public interface IAddIn
{
string Name { get; }
string Author { get; }
void Work();
}
public class Host
{
public static void Execute(IAddIn addin)
{
Console.WriteLine("[{0}] : {1} by {2}",
addin.GetType().FullName,
addin.Name,
addin.Author);
addin.Work();
}
}
We can simply compile this into a standalone assembly:
csc -t:library Host.cs
This will output Host.dll, which we will now consume in our super-duper Ruby script, empowered by the magic RubyCLR. I won’t stick the entire contents of the client Ruby script here, however the full thing is available from here (the full C# source file from above is available here). For now, lets just look at the implementation of our C# written interface within Ruby:
class MyAddIn
implements IAddIn
def get__name
return "My first Ruby/.Net add-in!"
end
def get__author
return "El Draper"
end
def work
puts "This is coming straight from my Ruby written add-in!"
end
end
As you can see, in order to implement the Name and Author properties, we define Ruby methods called get__name and get__author (note the double underscore).
This is all useless unless within my Ruby script I actually call my C# host and pass an instance of my Ruby written add-in. After referencing the Host.dll assembly:
reference_file ‘Host.dll’
I’m able to make the call to the host:
Host.Execute(MyAddIn.new)
Running this is then easy - once you’ve executed the “setenv.cmd” batch file within the root of the RubyCLR project, simply execute:
ruby Client.rb
(ensuring that Client.rb and Host.dll reside in the same directory).
This then outputs:
[T32dda3e3] : My first Ruby/.Net add-in! by El Draper
This is coming straight from my Ruby written add-in!
(N.B. the type name changes each and every time the script is run, as the concrete wrapper type created around the Ruby code and passed through onto the CLR is dynamically generated at run-time using System.Reflection.Emit).
The above shows that we can define an object that implements a .Net interface within Ruby, and then pass an instance of this into a .Net written host class. It then executes methods directly on the object that itself then executes Ruby code. Pretty snazzy eh!
Like Tim, I have a number of things I’d like to be able to extend this with. For one, I’d like to be able to “compile up” the concrete CLR types representing Ruby objects, and then execute this from within a .Net host, namely a C# application. My work on tweaking the RubyCLR code so far has resulted in being able to correctly output the dynamically generated assemblies, however these types when executed within a C# host application result in memory errors, presumably because it is lacking the reference to the Ruby host context and the original Ruby source file. So I need to be able to instantiate a Ruby object from my compiled emitted assembly, and then somehow build a Ruby context back to the original source file so it can correctly execute the code, but all from within a .Net host. This is really a reverse of the main scenario that RubyCLR I think was probably invented for, but none-the-less I think it should be possible. Any ideas, John? ;-)
Technorati Tags: el, eldiablo, ruby, rubyclr, clr, dotnet, c#, vb Comments
RIDE-ME, one time Aug 13 2006
So, RIDE-ME has hit version one, and I’m proud to say I was able to be a part of it. In fact this is the first release that has some of my work in it, namely the add-in architecture, and the console add-in built on top of that. It’s shaping up pretty nicely now, and recently I’ve been working on a Rails project using RM with almost no problems. I know I’m a bit behind the times blogging about the release, but come on people, please digg it - we are getting plenty of downloads but a spot on the digg.com frontpage wouldn’t go a miss ;-)
RIDE-THIS Jul 18 2006
My first real contribution to project RIDE-ME, the add-in architecture, is now in the trunk of the source tree. Check it out, comment, submit patches or let me know feedback. I’m pretty pleased with it, and it should foster some nice add-in development hopefully :-)
For all these times, that we walked away Jul 14 2006
Bit of a catch-up here, as it’s been far too long since I blogged:
- England are out, and the World Cup is over. The first event left me feeling raw anger towards the Portuguese (who over the years have given me plenty to be pissed about). The second was a rather bittersweet event. On the one hand, I’d far rather see neither France nor Italy win it, but out of the two I would have to have reluctantly picked the aging French surrender monkeys, rather than the greasy match-fixing Italians, to have won it. But the Zidane incident made the entire thing worthwhile, it was pure enjoyment seeing him getting his marching orders, with the classic shot of him leaving the field yards away from the World Cup trophy, combined with the fact than an Italian was for once legitimately polaxed.
- I got me SkyHD installed, and it is sw-eeeet. I can now watch HD sporting events, movies, and other assorted goodies (including alsorts of random documentaries, which I’d never usually watch except for the fact that it’s in HD). The box itself is sleek and chic, and bar a couple of random lock-ups last couple of days, has behaved excellently for a first generation piece of equipment. Oh, and the Sky+ PVR system is fantastic, I forgot how much I missed being able to setup entire series to be recorded with a couple of remote clicks.
- I’m wrapping up the add-in architecture for RIDE-ME. I hope to have it in my branch by the end of this weekend, and then merge it over after then to trunk. We can then test the hell out of it, while the other guys start to write whatever add-ins they can dream up. Eventually, in the 1.0 release, it’ll see the light of day, and we hope to build a nice add-in community around it. Oh, and I’m now hosting all of the resources for the RIDE-ME project.
- Did I mention HD? I’m currently watching Die Hard With A Vengeance apparently in HD (didn’t even realise HD cameras were around back in ‘95), and Bruce Willis never looked so good.
- I’ve been having a lot of fun with the object/relation mapping framework I’m working on at the minute, integrating it tightly with the model-view-controller framework I knocked together. It’s starting to come together, and I’ve just implemented associations in queries (read: joins). I’ve got a reason for putting all of this together, and that reason is almost ready for the big-time, so watch this space…
- I’ve ordered a SleepTracker watch, but there’s no stock at the minute so I gotta wait.
- The new Rise Against album is fantastic, along with the latest albums from Billy Talent and Lostprophets, expect reviews soon
- RubyCLR is superb, I think John Lam might be a genius
Comments
Rail Riding Jun 9 2006
So I came across what looks to be a nice little Windows based Ruby on Rails IDE - RIDE-ME. It’s written in .Net which is cool, and while still in its early phases, seems to be looking quite nice. Also, they are looking for C# developers to join the fold and help out, so with my experience in C# programming, and my almost unhealthy interest in Ruby and Rails, I feel compelled to contribute!
Haven’t posted much recently, but there’s a few things I’ve got that I want to post when I got more time, so hopefully over the coming weekend I’ll get it done.
Technorati Tags: el, eldiablo, rails, ruby, ide, ride-me, .net, c#
Muby, or Ronad Apr 6 2006
Two interesting points of view on a debate between two technologies that I didn’t think could be so comparable - Monad (MSH), and Ruby. Ted Neward puts forward his case for using Monad, because of its scripting ability, and provides some interesting usage of the scripting syntax to back his views up. Glenn Vanderburg says he’s sticking with Ruby however, and goes on to explain why, cleverly writing the same script that Ted did using Monad, in Ruby - just 17 lines of code, instead of 37 using MSH. Both posts are worth a read, however my opinion? I think Ruby has my vote all the way - it’s cross-platform nature, and the fact that it is a dedicated scripting language (rather than a shell with a neat syntactical scripting language to back it up) are really winning points for me. After all, I’d be happy combining Ruby with Rails to write a fully-fledged web application - but besides utilities/maintenance scripts, I don’t give Bash a run out very often. In the same way, I think at first people may say “look at how cool Monad is, look at what it can do!” but in the long-run, it’s use will be relegated to command line oriented tasks, and the “real code” will be written with languages like Ruby. My $0.02 on an interesting topic of conversation.
UPDATE: it looks like the original script in Ted’s article actually originated from a post by Lee Holmes - and since the debate, he has re-written the script, matching the Ruby version almost line for line - I guess that blows the whole lines of code argument out of the water then. Really it just comes down to what you are trying to write - in this case there’s not a lot between the two, however in other projects there may be a clear advantage to using one or the other. I’m happy to have both at my disposal :-)
Technorati Tags: el, eldiablo, monad, msh, ruby, rails, scripting
I'm getting real Apr 6 2006
I’ve decided to get real - today I went ahead and purchased a copy of Getting Real from 37 Signals, and I plan to get stuck in over the next few days. Expect a review soon.
Technorati Tags: el, eldiablo, “getting real”, “37 signals”, 37s
Ex-Framework Apr 3 2006
As some people may or may not have noticed, I have given up on the xFramework project. The various related project url’s now point to this very blog, and I guess the reason I gave it up is because I figured it just wasn’t that useful. There were no other contributors, so there are no licensing issues - obviously any one who took a snapshot of the licensed code is free to continue to work with that code based on the terms under which it was licensed, however going forward the repository has been retired, and I will no longer work on or continue to update xFramework. Going forward, for those that are interested, I will take the most useful parts of xFramework (namely the reflection helper code, the unit-testing framework, and the web/Xml stuff) and use it to form my own “internal” framework, upon which I will base a few applications I’ve been dreaming up. I’m hoping this will be a more streamlined approach for me, and might work out with better results than if these applications were based on a separate open-source framework I had to maintain aswell.
More news to follow on the result of this change, and the applications I’m working on, shortly I hope.
And for those wondering what happened to my series of articles on Ruby on Rails, I’m working on a BIG next installment, that’ll be a complete walkthrough of my experiences creating a simple database web application, from start-to-finish. The idea is that all the basics, resulting in a fully functioning app, will be completed by the end of this next part, and the following tutorial will then fill in some fancy details, like some advanced style techniques, AJAX, alsorts of extras.
Technorati Tags: el, eldiablo, xframework, mono, coding, ruby, rails
Page 3 of 3 | Previous page