RoR Scales

Some interesting points about RoR and developing in general. And no, I don’t think 1.5 million unique users per month is that much traffic to say anything about scalability of RoR applications. But that’s not too important here. What is? Quoting from here:

I think it’s important for people new to Rails to spend some time learning Ruby first. Most Rails converts are coming from the Java or PHP worlds, and it’s tempting to force a Java or PHP mentality of coding into your first Rails app.

Seen this one far too often already.

Whenever you’re developing a new feature, ask yourself if it can be written as a plugin rather than added directly to your web app.

This I consider important meta advice. All to often we are tempted to add that new feature ‘just right here, yes, this looks ok’. Don’t. Try hard to put it somewhere outside. In the end you’ll be happy about “subsystemizing” and “modularizing” your application. Obvious? Yes. Practiced? Hardly. And yes, I know about the “Myth of Reuse”. But that’s just not a contra-argument. Sorry.

Groovy vs JRuby – 4:4

Alright. Funny enough. After another day with both, Groovy and JRuby, I would say Groovy did catch up. Here’s the whole story:

After accepting the fact that Groovy is very OO, I found a way to add my plugin’s configuration folder to the classpath and load additional stuff from there. This way I was able to write a simple LexerAdapter and LexerBase class in Groovy. The resulting lexer specification looks something like this:

import jfun.parsec.*
import jfun.parsec.tokens.*
import jfun.parsec.pattern.*

class MyRubySyntax extends jparsec.LexerBase
    {
    protected void setup()
        {
        def s_block_open = Scanners.isPattern( Patterns.regex( /(?m:^=begin)/ ), "BLOCK_OPEN" )
        def s_block_close = Scanners.isPattern( Patterns.regex( /(?m:^=end$)/ ), "BLOCK_CLOSE" )
        def s_block_commented = Scanners.anyChar()

        scanner "DOC_COMMENT",	        Scanners.isBlockComment( s_block_open, s_block_close, s_block_commented )

        regex "LINE_COMMENT",           /(?m:#.*$)/
        regex "SPECIAL_QUOTED_STRING",  /%[qQ]\{(?:(?:\\\})|(?:[^\}]))*\}/
        (..snip..)
        regex "IDENTIFIER",             /\b[a-z]\w*\b/
        regex "NUMBER",                 /\b(?:0x[0-9A-Fa-f]+)|(?:[0-9]+(?:\.[0-9]+)?)\b/
        }
    }

return new MyRubySyntax().lexer()

This is still a lot uglier than the (J)Ruby version. But the thing is: This compiles to Java byte code. And with the LexerAdapter implemented in the scripting part of the system this is significant. To remedy the situation for JRuby I still have the pure Java LexerAdapter available on the classpath. (More on this in the example configuration files.)

What I didn’t figure out: There’s a nice use (“with”) codeword in Groovy. But it didn’t really work. It should provide functionality to merge a module’s methods into a closure/block of code. This way I wouldn’t have to create this MyRubySyntax class, etc and could get away with something like this:

use ( jparsec.LexerBase )
{
    (..snip..)
    regex "NUMBER",                 /\b(?:0x[0-9A-Fa-f]+)|(?:[0-9]+(?:\.[0-9]+)?)\b/

    return lexer()
}

But I guess I still don’t understand Groovy good enough. It has quite a few little quirks.

Another of those would be that I cannot use closures in all the places that should allow them. Here’s one:

for ( idx in 0..myCache.size() - 1 )
{
    def token = myCache.get( idx )
    if ( aStartOffset >= token.start && aStartOffset < token.end ) return token
    if ( aStartOffset < token.end ) return token
}

With myCache being an ArrayList I would expect myCache.each { token -> ... } to work. Somehow I get a compiler error mumbling about 1 parameter where 2 are expected or something like that. Weird.

Anyway, with the compiled approach of Groovy it suddenly feels a lot more practicable for the intended purpose of lexer adaptation and specification. Nice.

With the next step planned - extending the plugin to allow simple parser functionality - I assume JRuby will become even less an option. But it should be helpful to get some quick results. Especially for the Ruby configuration of the plugin. I intend to use one of the existing pure Ruby parsers for the Ruby syntax. We'll see how that turns out..

tfdj

Groovy vs JRuby – 1:4

Admittedly, comparing Groovy and JRuby is like comparing apples and oranges. But my point is: It’s both fruits! :)

Groovy with a compiled approach. JRuby with an interpreter. But nowadays, with the scripting API in Java 6, the really important aspect of both languages is: They can both be used for scripting in a Java context.

While updating my SimpleSyntax plugin to a scripted lexer configuration approach, I started with using Groovy for the scripting. Now, the following ‘issues’ are what I got stuck at. There are probably other – read: correct – ways to solving these problems. But the thing is: Groovy and it’s ‘documentation’ made it hard for me to solve my problems properly. Here’s what I encountered:

  • Every Groovy script is treated as an instance of a class. If you define methods, they are assigned to this ‘script class’.
  • Because of the previous issue, it’s a bad idea to have a script named Something.groovy and define a class Something in it. That is, if you evaluate it as a script. Because Groovy implicitly created a class named Something in which the script executes. (Importing Something.groovy with it being in the class path will probably work. But it’s not what I wanted for my plugin. Well, the Groovy documentation mentions that Groovy is object-oriented and therefore everything is treated as such.)
  • There is no shared ‘global’ method space between calls to GroovyShell#evaluate. To be more precise: Because of the previous issues, you can’t define a method in one script, and call it in another script. Because every script runs in the context of a new class. (I wonder if there is some way around this. Some trick. Something.)
  • Implementing something like ‘source( aScriptFileName)’ for reading a script and evaluating it ‘in place’ is possible, but only with certain limits. Besides the obvious reasons resulting from the previously mentioned issues, there’s a fundamental problem with ‘sourcing’ another script: Because of the compiled approach of Groovy, the right way to include another piece of Groovy code is to use import (I guess). Otherwise you ‘source’ a piece of Groovy code but can’t rely on it’s – for example – contained class definitions to be available at compile time of the ‘calling’ script.

After I solved these issues ‘somehow’ (more in the Example.groovy script in the plugin sources) I started adding support for JRuby.

Here’s what I found: No problems. JRuby has Ruby’s top-level context. You can define a method in script 1, then execute script 2 in the same Ruby instance and access the method defined in script 1. You can implement ‘source’ with a simple call to eval on a script.

There’s even a ‘setCurrentDirectory’ call in the JRuby API which makes things really simple for me with my configuration folder somewhere in IntelliJ IDEA’s file structure.

Well, I’m pretty sure that after spending about two or three hours with both systems, I am far from being an expert in either of them :) But for me the important point is: After a few hours with both systems, JRuby delivered what I needed. Groovy didn’t.

However, I’d really love to here from Groovy pros how to solve the issues mentioned above. I’m sure there’s a proper way to do everything. But I guess it will be a different one. Different to the simple way I was able to employ with JRuby. Am I right?

On the other hand: Getting my lexer out of the script into my enclosing Java plugin is a lot easier with Groovy. You simply return the created object. And use it. It’s the object you expect it to be. With JRuby, however, you have to convert it back into the expected target class using a utility method. (Or at least I think this is they way you have to do it.. :)

Overall, I think Groovy shines if you’re still close to the Java way. What makes sense, I guess.. :) You write Groovy classes, put them on the class path. Everything works. I ‘assume’ JRuby will be a lot more problematic when you want to do this. I didn’t see a JRubyClassLoader, for example, that works like Groovy’s. Well, I guess these are obvious observarions..

If you’re interested have a look at these four files. They are central to the scripting support in my plugin:

tfdj

RubyGems: Absolute Paths

I just read Jay Field’s latest blog article on RubyGems and absolute paths.

It’s interesting to see him propose this pseudo-absolute path scheme. When I started coding in Ruby I used this scheme for the very same reason he mentions. But it soon felt to cumbersome to use. Now I wonder what the real problem with Ruby is.. concerning this path-problem.. it’s very much like a Java classpath problem, isn’t it? Well, of course it’s completely different. But still in the same area.. :)

Anyway, what I’m missing the most with Ruby (Gems), is a way to specify which files are public and which not. This way I would only need to take care of path-related issues in the public entry point into my gem. Everything else could use a require_from_gem method. But this is not really reasonable or possible with Ruby, is it? More probably: You don’t really want this for Ruby.

So I wonder if the burden shouldn’t be on the gem’s user’s shoulder. The gem should probably remain clean and tidy with only relative paths. The user would then have to use something like require_gem_add which loads the gem and adds the root path automagically. Or gem_require should take care of this automagically based on the spec and checking the path. Not sure. Anyway, I don’t think that these clumsy require File.dirname(__FILE__) + [relative path] statements are the best solution.

Well, just a thought..

tfdj

The End Of Ruby? Part 2 :)

The Ruby GUI situation

Amen to that!

tfdj

Ruby: Game on?

I’ve spent some time over the weekend working on a game engine in Ruby. Using RUDL and RubyInline I was able to implement the basics of my old game engine approach within a few hours. Compared to the Symbian C++ terror a few years ago this was real fun.. :)

But Ruby, Python, etc are of course limited in their ‘gaming capabilities’. I have to think about where I want to go with this new approach. Basic questions like: Embed Ruby or inline code in Ruby? Ruby at all (Or Python for that matter..) How do I get the benefits of a nice language like Ruby but still keep all options for optimizing critical system areas.

What I’d like to do in the long run is – for example – have a simple executable file as an end result. With Ruby this is a problem. Ruby2EXE and other similiar approaches are BS. Another option I’d like is to have is a Java Applet or Flash file as the end result.

Well.. it’s late.. I probably shouldn’t try writing stuff like that.. :)

tfdj

Ruby Fox?

got the wrong web-site while looking for some more info on the FOX GUI for Ruby. i like it a lot more than the FXRuby page: Ruby Fox

tfdj

Ruby GUI Toolkits

i just looked into the current situation concerning GUI toolkits for Ruby. one word: BS

wxruby, fxruby, ruby/qt, ruby/gtk.. (not to mention the tcl/tk bs..) well.. the list goes on..

you know something about java’s swing? it works pretty nice by now. on my win-box, my linux-server and even on osx. (tested it on my minimac – which i was able to sell for some good money a short time ago. lucky me.. osx free again! not feeling gay anymore these days.. :)

well, of course theres is a huge difference between java’s swing and fxruby (for example, or wxruby, ..). the difference is about 50 mb.. :) but still: all these little problems with Ruby’s GUI toolkits.. really annoying..

and yes, of course it’s cool to use closures in ruby to handle events, etc.. and you have to know a little bit about swing to make the java code look nice.. or.. well.. as nice as it gets.. :)

anyway, i wonder what the best solution would be for a Ruby GUI toolkit.. from my point of view.. something light-weight.. cross-plattform API to native widgets.. small native ruby extension.. as much functionality as possible implemented in ruby, not in the native part.. in fact, i’d also accept non-native widgets.. the most important part would be to not rely on any other native libraries except the ruby extension part.. have to think about this a bit more.. probably a nice new pet project..

tfdj

quick update: here’s an example of what i mean..

icons = Wx::RadioBox.new(panel, ID_ICON, “&Icons”, Wx::Point.new(20,5), Wx::DEFAULT_SIZE, iconNames, 1, Wx::RA_SPECIFY_COLS)
evt_radiobox(ID_ICON) {|event| on_change_icon(event)}

worse than swing, don’t you think?

Believing the Hype

Inside this post are some interesting facts about Ruby. Look here and here (PDF).

Don’t get me wrong! I really like Ruby! It’s just that it has some serious issues.. :)

Here’s a thought: Could the JVM gain JRuby an advantage?

tfdj

Ruby IDEs

I just stumbled upon this: Sapphire In Steel/. A Ruby IDE for Visual Studio 2005. Of course there are other alternatives like for example TextMate, JEdit, SciTe, Arachno, ActiveState, Mondrian, etc.. lots of choices.. different levels of Ruby support/integration.. from editor with highlighting to integrated ruby debugging..

Anyway, Ruby is not Java. Duh. :) What I’m saying is what many before already said: Many of the IDE features that make a Java developer’s live bearable won’t work very well or at all in a Ruby context. However, you also simply don’t need them in Ruby.

What’s nice to have, of course, is syntax highlighting and context-sensitve word-completion. The latter however, may very well be restricted to the context of the opened file. It doesn’t even have to check the ‘require’d files. What use would it be in a language like Ruby? Think BlankSlate for example.. An IDE would have to really execute code to know what’s going on.. Well, nothing new. The old dilemma of highly dynamic languages.

But again: You just don’t need theses features with Ruby.

I would even go as far as saying that you don’t need a debugger. A debugger is an undisciplined developer’s saviour. Nothing more. I developed quite a few systems. The only time I needed the debugger was back in my Amiga days when writing demos. In M68k assembler.. But a Java debugger? Or a Ruby debugger? What does it tell you about your codebase if you need a debugger to figure out what’s going wrong? Even when developing for Symbian applications and games I never really needed a debugger.. And believe me when I tell you that Symbian development is a real bitch..

(Well, of course there are certain situations.. like being dependant on certain assumptions you make about a library for example.. even then a test suite is a viable alternative.. this might change on a more hardware-near level.. but then again you probably need an oscilloscope anyway.. :)

Anyway, even with Ruby highlighting in VS2k5 or IDEA or JEdit, etc.. I still fall back to using a small and fast editor like TextPad. Maybe my next pet project should be a new text editor.. :) With exactly the features I want.. Unfortunatly this would mean going back to C/C++.. I still don’t consider a Java, C# or Ruby/Python/etc editor a really convincing alternative.. Which I should probably explain in another post..

tfdj

Next Page »