Martian eyrie

RubyForge: RubyInline is an analog to Perl’s Inline::C. Out of the box, it allows you to embed C/ external module code in your ruby script directly. By writing simple builder classes, you can teach how to cope with new languages (fortran, perl, whatever).

Build Ajax into your Web apps with Rails

Ruby on Rails provides an excellent platform for building Web applications. Discover how to use the built-in Asynchronous JavaScript™ XML (Ajax) features of the platform to give your application the Web 2.0 rich user interface experience.

If you haven’t heard about Rails, then welcome back from your trip to planet Zorton, which is the only place you could go and not hear about Ruby on Rails over this past year. Rails is at its most appealing when it allows you to get your application and its features up and running quickly. Rails’ built-in integration with the Prototype.js library for Ajax makes it easy to build so-called rich Internet applications quickly.

This article takes you through the steps of building a Rails application. It then dives right into using the Ajax features to build the JavaScript code that reads and writes data from the server.

AJAX:Getting Started - MDC This article guides you through the AJAX basics and gives you two simple hands-on examples to get you started.

WxRubyWiki:  wxRuby is an open source GUI toolkit for the Ruby programming language. It provides a Ruby interface to the cross-platform wxWidgets C GUI framework. wxWidgets is a mature, fully-featured GUI toolkit that uses native GUI widgets to provide a platform-standard UI experience on Linux, Windows and OS X. wxRuby is intended to dramatically extend Ruby’s usefulness in rapid prototyping and general UI software development.

Why should I use wxRuby instead of one of the other fine ruby GUI toolkits, such as FXRuby, ruby/gtk, ruby/fltk, ruby/qt, ruby/tk, etc?

Here are some reasons:

• wxRuby works on MS Windows, Linux, Mac OS X, and BSD
• Uses native widgets and dialogs
  • Exactly the look, feel and behaviour users expect from their platform
  • More likely to be accessible by users who are blind or otherwise disabled
• wxRuby is provided as an easy-to-install package or gem, which does not any external dependencies
• wxRuby offers full unicode (UTF8) support
• wxWidgets is a very mature, fully-featured GUI toolset, widely used and actively developed

Mostly, it comes down to the native widgets. None of the other toolkits provide cross-platform native widget support, except for Tk, which only provides a limited number of widgets.

The main reason NOT to use wxRuby has been the relative immaturity of the bindings. However, wxruby2 now offers nearly complete coverage of the wxWidgets GUI API, and stability is improving all the time.

Edd Dumbill’s Weblog: JavaScript frameworks, new heroes of the web 

Makers of Dojo, Prototype, jQuery and Mochikit, I salute you.

It is immensely gratifying that there are those with the courage and sense to make JavaScript in the browser workable for the rest of us. Like many busy developers, I’ve steered myself away from hacking JavaScript for many years. Cross-browser incompatibilities, the troubles of debugging and the relatively small reward for effort have kept me focusing on the server side (not to mention the temptation JavaScript poses to those prone to stray from the REST religion).

This is now starting to change. The immense efforts of JavaScript developers are providing frameworks that allow developers to work on the client side with something approaching the elegance and concision that we can now wield on the server side.

One of the wonderful things about the web is that it has become the forum for its own improvement. JavaScript has ensured that this is now true of the browser too. New techniques can be proved in script before they ever need baking into a markup language.

Even the most ardent of declarative programming hacks will appreciate the way toolkits such as jQuery allow painting of behaviour onto pages rather than littering semantic markup with snippets of script.

The problem that faces us now is: which JavaScript framework to choose?

As is my habit in programming languages, I’ve found myself move from framework to framework depending on the actual tools available. Starting off in Prototype as it came with Rails, paying a happy visit to jQuery because of Thickbox, considering Dojo because of its rich text editor, and now being wowed by Plotkit and thus checking out Mochikit.

Why Rails?

When I moved this blog from being Zope-backed to using Rails several people got in touch to ask why. This is a brief explanation of why I’ve moved.

chris blogs: How Rails made me a better programmer  (Consider this an entry for the contest.)

The question how Rails made me a better programmer can be answered in a short, but incomplete and actually wrong way: It didn’t.

That is only half the truth. When Rails was released in 2004, I already had almost three years of programming experience in Ruby. Therefore, I don’t think I learned much from Rails in a technical way. I knew MVC, the code didn’t particularly impress me, and, in the end, I didn’t care a lot about web development either. At that time, at least.

The things I’ve learned (or everyone could learn) from Rails are social lessons. Some of them were to be expected, some were very unexpected and a few still make me question the universe everytime I think of them.

So, what did I learn from Rails?