Create your project

rootintootin name:journal port:3000 db_user:root db_password:letmein
cd journal
./gen recreate database
./gen create noun singular:note plural:notes
./gen create scaffold note title:unique_string content:text \
validates presence_of:title,content
./gen migrate
./run

Development happens over at launchpad:

• Launchpad Homepage
• Code Repository
• Bug Reports
• Mailing List

If you have any problems, you can contact Matt Jones at: mattjones@rootin.toot.in

Rails is the best web framework, but ...

1. The page caching and action caching in Rails is extremely time consuming. It is essential to getting acceptable performance, even on trivial applications. This is by far the biggest down-side to Rails. Rootin's philosophy is that the View and Controller code should be fast enough, so there is no benefit to caching, until your site is much larger and heavily trafficked.
2. Installing Rails is still frustrating on systems that use package managers. You end up using a mixture of native packages(RPM, Dpkg), gem packages, and gems copied into your Rails project. This makes deployment unreliable, as all 3 systems compete with each other, and have different versions of gems. Rootin's philosophy is to use the primary installation method for each OS. Plus Rootin is statically linked with your application. So It should "just work" on servers, even if they don't have Rootin installed.
3. Configuration for ruby, gems, and sessions is spread throughout code in environment.rb, boot.rb, and production.rb. Rootin stores all that in json config files.
4. There is too much fragmentation in the Rails server space, and no preferred one. This is confusing as many people end up handcuffing themselves to a combination of FastCGI, CGI, Webrick, Mongrel, Mod Rails, Passenger, Apache, Nginx, Lighttpd, and Cherokee. This dramatically hinders or helps their choices for caching, deployment, sessions, and scaling. Rootin comes with one server that is recommended for testing, development, and production.
5. Having all of Rails and your gems copied to your project's vendor dir is silly. Plus there are tons of symlinks inside those vendor dirs. This wreaks havoc on your VCS and compressed copies of your project.
6. Creating and managing your project requires a smorgasbord of scripts, rake commands, gem commands, and editing config files by hand. Rootin does everything by calling scripts.
7. Rails has traditionally stuck to its original way of doing things: Using Prototype for JS instead of moving to JQuery, and using YAML for configurations instead of moving to JSON. Rootin will always try to use new/better technologies.
8. Some methods in the Rails API work with strings or symbols as arguments. Many do not. This is confusing and leads to a lot of unnecessary conversions. The Rails framework is also very huge and uses a ridiculous amount of meta programming, introspection, and unnecessary runtime database and config file lookup. Rootin focuses on being small, fast, simple, and quickly changing based on feedback.
9. Rails is sorely missing first party plugins for essential things like pagination, user accounts, encryption, cookies, et cetera. Rootin will include plugins for essential features.
10. The way Rails tries to guess the singular to plural naming conventions of your models and controllers is confusing. It optionally lets you specify inflections of words. This leads to the developer constantly using the wrong pluralization, or Rails guessing wrong. The Rootin way is to simply require that you map the pluralization of each controller and model.
11. The primary method of learning Rails is the book Agile Web Development With Rails. It is always late to release, and out-of-date a few months later. It took them over-a-year after rails 2.0 came out, to release the version of the book that covered it(version 3). They should have gone the wiki route, like Django did with The Django Book.
12. Rails and Erb still do not escape output in views by default. Having to opt-in to escaping, with the "h" function is backwards, and dangerous. Rootin escapes everything by default ala Asp.net. The <%=unsafe%> syntax will escape, while the <%#safe%> syntax will not. Note that this should be fixed in the Rails 3 release.
13. Templates in Rails are generated in real-time. This is slow and contributes to the "You must cache for decent performance" attitude. Rootin simply pre-generates the templates at compile time, by turning them inside-out.
14. The Rails ORM(Active Record) does not enforce referential integrity. This means that you will inevitably have your site break, because you didn't realize that deleting stuff, left some foreign key dangling somewhere. Rootin simply uses referential integrity. So you can't delete things improperly.

1. Create a new Rootin Tootin project. It will be named "journal", run on port 3000, and use the mysql user "root" with the password "letmein".

   rootintootin name:journal port:3000 db_user:root db_password:letmein

2. The rootintootin command created a directory named "journal" that contains the complete app. Move into this folder.

   cd journal

3. To create the mysql database, we will use the gen script. As with any scripts in Rootin Tootin, we will run them like "./gen". The "./" simply means to run the script in the local directory.

   ./gen recreate database

4. We will want to create a model and controller named "note". In order for the framework to know about the noun "note", we will tell it how to pluralize and singularize this noun. Singularize means one instance and pluralize means many instances.

   ./gen create noun singular:note plural:notes

5. Now we will create a skeleton website or "scaffolding" for our journal. We will need a database model named notes with string fields title and content. This will also create our models, views, controllers, and migrations.

   ./gen create scaffold note title:string content:string

6. Now we will run the migration that will create the tables that the models are mapped to.

   ./gen migrate

7. Now we will run the project. The run command will start the server on port 3000. The server will look at the project files and compile them automatically when they change.

   ./run

8. Now visit the website in a web browser.

   http://localhost:3000/notes

The project status as of August 2010

Rootin Tootin is alpha software, and not ready for production use. It is missing many key features, and has yet to be significantly tested for security, performance, or reliability. The API is extremely unstable. It is highly recommended that Rootin Tootin is not used on anything, until the 1.0 release. No known websites actually use Rootin Tootin.

1. File uploading works, but the server puts the entire file in memory. This is used to parse the http multipart encoding that browsers use when uploading. This should be fixed in a later release.
2. The only database that is supported is Mysql. In later releases, we should support Postgres and others.
3. Deployment is still difficult. This should be resolved in the 0.6 release.
4. The API reference and documentation are non existent. This should be resolved in the 0.7 release.

Rootin Tootin is licensed under the GNU General Public License version 3 (aka GPLV3). Because it is using the LDC compiler, libraries can only be statically linked. This means that software compiled with Rootin Tootin, will be considered a derivative work of Rootin Tootin, the Dornado Server, and the Tango Library. The compiled software will be licensed under the GPLV3 from Rootin Tootin, the Apache License Version 2 from Dornado, and the BSD License from Tango.

This will make your compiled software only distributable under the GPLV3/Apache 2 Licenses. You can avoid this by three means: By distributing your software in a source code form, without being statically linked to Rootin Tootin or Dornado; By only distributing the unlinked object files; Or by not distributing the binary, and having it run as a server.

Obviously the licensing issue is not ideal. Hopefully this situation will be resolved before Rootin Tootin is usable software. Most likely LDC will gain dynamic linking support, or Rootin Tootin will be re-licensed as BSD .

The Rootin Tootin project does not require copyright assignment. This means that you own any contributions you make. All patches are required to be submitted as Bazaar branches. This way, your contributions are documented in the Bazaar repository.

Rootin Tootin uses the LDC compiler (LLVM D Compiler), and Tango library. The only Operating Systems with packages for LDC and Tango are Debian and Ubuntu. Fedora may have packages in the upcoming Fedora 14 release. In the future I hope to see LDC and Tango on major Linux, BSD, and even Windows OSes.