The Ruby language, started to grow inside the enterprises and to be “the topic” in many blogs after the Rails framework showed up, but Rails is not the only option for developing web applications with Ruby, there are other frameworks, and one of “the others” is called “Nitro Framework“, thsi one has almost the same age as Rails but it has a lot less documentation and AFAIK a lot less users too.
This post is about my first 30 minutes with Nitro.
One of the better things about rails, and one of the things that you can not do with Nitro is just to change a class while the server is running, and see the change after a refresh in the browser window, but I’ll talk about these problems later …
The Nitro framework, goes through a path different from Rails, while Rails tell you where to put your models, where to put your controllers, where to put your views, …
What I think is a great feature, since when you start working in a new project you already know where every thing is, Nitro let you put your stuff just where you want it to be.
What is a nice feature too, but if I want to put things where I want them to be, I’ll use Java as I’m doing for the last 5 years
Nitro is almost a two framework in one, with Nitro you can develop MVC style applications like Rails, but you can write page oriented applications like in PHP or ASP too, and the best thing is that you can mix the two styles too, of course it will increase the complexity of your application, but it can make it a lot easier to work too, you can write what you need using the easier way to accomplish that task.
To start playing with Nitro just run the following commands:
Every thing ready, you are running your first Nitro application!
Until now, I think that nitro is more complicated than Rails, probably the lack of documentation contributed a lot to this, the terrible examples have their share in this responsibility too, but Nitro has some cool things too.
If you want to create a page based application, you just need to create some “.xhtml” files and place your Ruby code between <?r and ?>, or if you just want to display some string, do it just like in any Ruby String, placing your code between #{ … }.
Since nitro does not have a fixed directory structure, you need to “require” some of your Ruby files from inside the “run.rb” code, I think that this is the cause of the lack of automatic reloading of your code.
Nitro uses Og for persistence, and Og does not need your persistent objects to extend any class, it will persist any object that uses any of it’s “property definition helpers”, itlooks for an automatic created method called “serializable_attributes”, I think it is more the “ruby way”, since it uses “Duck Typing” instead of hierarchy.
Nitro does not have any thing like “migrations”, at least I did not find it yet, and I really like Rails Migrations.
I found the source code for Nitro and Og easier to read and understand than the Rails code, but the code for the Rails applications is a lot cleaner and easier to read.
One thing that I found cool about nitro is that they use the explicit parameters for almost all methods, when rails use hashes for almost every thing, both approaches have advantages …
The example I wanted to write for this post will be published another time, because I need to study a little more about Nitro and Og to develop any thing that I’m not ashamed of publishing.
They do not follow a standard directory structure even in the sample applications, in some of them the code is in the source directory, in others it is in the app directory, the only standard is that the public things (style sheets, images, …) are in a directory called public.
For now, they (Nitro and Og) looks like they need more work, they stopped in time for a while, and the development restarted now with the “Rails Boom“.
Nitro has some cool things, but at least for now, I’ll use Rails for my projects (at least the ones that aren’t in Java)
If you enjoyed this post, make sure you subscribe to my RSS feed!
Thanks for trying out Nitro. I would advise you to grab the (vastly improved) repository version and join the mailing list for extra help. I really think that Nitro is actually simpler to use than Rails.
For example Og does not need migrations because it provides automagic database evolution. If you change your ruby classes and restart your application, Og automatcially detects the changes and alters the database schema accordingly (ie adds columns/ removes columns, alters columns etc).
The ability to put things wherever you like comes in addition, not instead of.
There is a bin/nitro command that lays out a canonical standard directory hierarchy, but it’s also simple enough that after the first week I could create it from memory.
nitro –create myapp
results in
myapp ( locate main application script here )
myapp/app/models
myapp/app/controllers
myapp/app/conf
myapp/app/templates
myapp/app/public
myapp/app/public/css
myapp/app/public/css/js
The freedom to do tiny experiments with a minimal layout of one or two files has been incredibly useful. I still have the canonical structure for more significant projects.
I don’t know where how you got the impression that automatic reloading of code doesn’t work.Over here it works flawless. Only when you change app.rb itself do you need to restart to server.
The directory layout that nitro –create generates is considered canonical. You’re free to deviate, but all current examples will use this layout. To get automatic loading of ruby files without having to explicitly require them just add something like
Dir['app/**/*.rb'].each{|f| require f}
to your app.rb.
Thank you for trying out Nitro!
thanks for the tips, I’ll test it again and will write another post about it
PS.: I do not like very much the auto schema update option (did not know nitro has it, but now that i know, is there a way to disable it?), I have had lots of troubles with this kind of feature in hibernate (Java), a migration enables me to write code that for example, moves the data to a new column, process it some way, and then add it to the new column, instead of simply creating a new column with the default value …
My guess would be Og.evolve_schema = false, or adding :evolve_schema => false to the option hash of Og.start, e.g.
Og.evolve_schema = false
or
Og.start( :name => “booklist”,
:adapter => :sqlite,
:evolve_schema => false )
See the slowly evolving cheatsheets at http://robmela.com/cheatsheets
My guess was wrong — looks like it’s :create_schema that needs to be disabled.
Og.start( :name => ‘mydb’, :create_schema => false …. )
You need to set both to false
:create_schema => false,
:evolve_schema => false,
you enable these options only in development (or whn you want to actually update your schema on the live server (and have previously tested this in your debug/staging server)