Slashdot Mirror

Curt Hibbs (author of that Rails article) has just released Instant Rails.

Instant Rails is a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all preconfigured and ready to run. No installer, you simply drop it into the directory of your choice and run it. It does not modify your system environment.

http://instantrails.rubyforge.org/

Curt Hibbs (author of that Rails article) has just released Instant Rails.

Instant Rails is a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all preconfigured and ready to run. No installer, you simply drop it into the directory of your choice and run it. It does not modify your system environment.

http://instantrails.rubyforge.org/

ModelSecurity helps Ruby on Rails developers implement a security defense in depth by implementing access control within the data model.

If you are like most developers, you think about security when you program controllers and views. But a bug in your controller or view can compromise the security of your application, unless your data model has also been secured.

The economical, flexible, and extremely readable means of specifying access controls provided by ModelSecurity makes it easier for the developer to think about security, and makes security assumptions that might otherwise live in one developers head concrete and communicable to others.

• Home Page
• Tutorial.
• Reference.
• RubyForge project.

Ruby has a heavy Smalltalk heritage, including the continuations. Just for fun, have a look at Borges , Seaside 2 ported to Ruby!

We have the data available to us.

http://rubyforge.org/docman/view.php/5/11/rubyforg e_site_status.html

The PostgreSQL database contains about 3.2 million records and takes up 600 MB of disk space.

600 MB is obviously not a few TB. It's not even 1 GB!

RubyForge is currently running on a single machine with two 2.8 GHz Xeon CPUs, 2 GB of RAM, and a hardware RAID 5 SCSI array of 210 GB.

They have 2 GB of RAM for a 600 MB database. Even assuming the web server, mail server, Linux, etc., take half of the available real memory (probably unlikely), that still leaves 1 GB or so for the database. More than enough for the database itself to be resident in RAM.

Sorry for the delay in replying, here's a description of the hardware.

I should really do an analysis of how many queries the DB processes per day/hour/whatever; that would be more useful.

Ruby already has Og/Nitro, which drives the SQL from the code. Developers can focus on thinking in terms of their object model and object relationships, and let Og, the ORM part, handle the database work.

Many developers find this way of working far more natural than spreading their object definitions over multiple locations (SQL definitions and Ruby code).

Good to hear, though, that Rails continues to pick up advanced ideas from Og/Nitro.

The solution?

# assuming Ruby is installed..

wget http://rubyforge.org/frs/download.php/5207/rubygem s-0.8.11.tgz
tar zxvf rubygems-0.8.11.tgz
cd rubygems-0.8.11
sudo ruby1.8 setup.rb
sudo gem install rubygems-update
sudo gem install rails

cd ~
rails goodbyephp5
cd goodbyephp5

script/server &

lynx http://localhost:3000/
# woo!

Myself, along with 2 other people, were selected to work in an Extreme Programming group this summer at the NASA Langley Research Center. We enhanced their current code repository to be more functional. This included making an API to allow for interfacing with CVS (their current source control system) and subversion (hopefully they will upgrade to this soon enough). Furthermore, we had built in automated testing which check all tests as soon as commits were made and continous integration, which checkout the entire repository and built it on seperate machines (also each time a commit was recieved). We build a webpage using Ruby on Rails, which displayed all the feedback from the integration and building. Not bad for 3 summer students and 2 months. All our code will be available on http://www.rubyforge.org/ shortly. A VERY noteworthy internship! (Also had 2 of the best mentors EVER!)

...as my email/contact/calendar/task thingy (OK, PIM) on various Fedora Core releases for the past few years; it's steadily improved and now is quite solid.

Of course, I'm probably biased since I'm working on a Ruby wrapper library for it, but, anyhow.

I think that would mean that specifying it to the database would be about the same as programming it. You'll need to do a series of invariant specifications at various levels to search by, and these rapidly becomes almost as precise as a program. The problem is that a lot of the questions we have are somewhat fuzzy. Which is why I think just searching through the database will often be more expensive than implementing something. I'll use some examples here: - I worked on implementing a system for being able to write UML diagrams as readable text so I could version control them and look at diffs. The generated diagram had to be laid out automatically "so it looked pretty". Describing "looked pretty" as invariants is pretty useless. If I knew the invariants, I could as well have coded it. OK, other example: I wanted to separate concerns in an application for easier testing, so I wanted an Inversion of Control container. Jamis Buck had written a large and complex one called Copland. Now, I had some experience with the concept, but I had no experience with what an IoC framework would give me. I could easily write one by just passing anonymous functions (lambda, procs) around. This would definately be different from what Copland does, and it would take me an hour or three to implement. Now, I spent time to try to understand Copland, to see if the extra complexity there was actually worth anything in my kind of contexts. In the end, Jamis ended up implementing a separate, simpler IoC framework - and I think using less time on the first implementation of that than I used to look at his previous framework, *even with complete docs and the author available to help me understand the concepts*. For things that are purely algorithm implementations, searching by specification would probably be useful. Examples of these that I've come across recently: - Code to compute space-filling grid alignments (a la HTML tables) using minimum sizes and infinities. I worked on this yesterday, and it is fairly standard, fairly easy to produce invariants for, and somewhat hairy to program. - The stuff I work on right now, which is placement of said boxes, with some wraparound rules if they don't fit, and some speciality rules for section. This is quite fiddly to program in an imperative fashion, and probably too expensive if I do it functionally in a language that doesn't handle that well. Invariants are easy to spec, the code is fiddly. However, an invariant set for this (a spec) should be "trivially" translatable to code by a compiler, anyway, and I doubt anybody has programmed anything JUST like it. Maybe a library that could be used somehow, but I have no idea of what invariants that would have... - A generic caching system that I wrote for use with objects that were purely specified by their arguments inside my type system for Ruby. Basically, the flyweight pattern. I'm sure somebody else must have implemented that, too, and it is well enough specified that I could use it. However, again this is trivial to code. My attack on the reuse problems are different than these. My experience is that libraries come in fairly large packages (no matter how small they are), and that it takes time to learn how to use them. No matter what they are, different programmers would normally do the API and invariants around them slightly different. Because of the size and "foreignness" of libraries/frameworks, it takes some time to start using a framework, and you do not find out if this framework fit you or not until you've tried it for a while. The first step you need is a birds-eye view of what packages are available to do what tasks, including subjective views from people about what they like and don't like and why. You can find a start for this for RPA at http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packag eAdvisor The second step you need is to learn that package. We're trying to move packages to standard documentation, standard codest

...is M. Tim Jones' AI Application Programming. It's got all sorts of predator/prey and pathfinding stuff in there.

The code examples are in C, although I ported some of them from the 1st edition of the book to Ruby.

There is no downside to using ruby on rails. Closest thing to a silver bullet since the web came out.

There are several significant downsides to using Ruby on Rails.

Firstly, the way that ActiveRecord works by default - generating classes at run-time based on database tables - is considered by many (well, me at least!) to be a very backward step, as it makes code vunerable to changes in those tables, and also makes portability of code between different databases non-trivial. There are far better ways to do this - the Python ORM Dejavu (in in which the data model is expressed as classes) is an example. Almost all modern development languages work this way - with the exception of RoR!

Expressing the data model as classes can be done using Og (or Nitro+Og), and I believe that Og can be used as an alternative interface to Rails with just a bit of work. However, Rails does this (mostly) the right way, since your data is always more valuable than your application. Where this approach falls down is based on a couple of things:

1. Rails uses MySQL as its “correct” database. MySQL is not and never has been good, just ubiquitous. There are some very broken concepts in ActiveRecord because of this assumption.
2. Migration is difficult, as it is done externally to the application.

People who don’t really know anything about data modelling and relational theory tend to prefer class->table interpretation. People who understand data modelling tend to prefer table->class interpretation. There’s room for both, but the preferred method—and the more portable method—is to treat the database as the authoritative model for the application, not the other way around. (Yes, reading the database model is more portable than creating the database from the application. Especially with a dynamic language like Ruby.)

Secondly, Ruby is slow. There may be future JIT systems that help deal with this, but they are not there yet.

This is a straw-man. Ruby most emphatically is not slow. It is also not the fastest performer. But for what RoR does, it is generally fast enough. If you’re using the MySQL adapter, you definitely want to make sure that you’re using the native adapter, not the pure Ruby adapter. I’m developing one of the more complex applications/libraries in Ruby (PDF::Writer) and while I won’t pretend that it’s a speed demon, it’s impressively fast for what it does do, complete with rollback for the layout handling. Ruby’s performance is more than adequate for most applications, especially most database-backed web applications.

Thirdly, Ruby is changing, and it is likely (from what I read) that the next version will not be fully compatible, so any major project developed now in Rails will have upgrading issues.

Probably not. I suspect that there will be 80% or more compatibility, based on the currently submitted RCRs that have positive response. I also expect that the RoR community will make sure that Rails runs well on whatever the current version of Ruby is. I believe that some work has been done to make sure that RoR works well on Ruby 1.9, which is the test bed environment for most of the syntax changes that will be coming with Ruby 2.0.

So Ruby on Rails is very far from a silver bullet. It may a neat way to get small (in terms of code) websites up quickly.

I agree with your first sentence. I disagree with your second, at least partially. RoR—and Ruby in general—makes a lot of code smaller and easier to maintain. Ruby isn’t the

Just to settle the Oracle v. whatever DB issue: I've paid for an Oracle perpetual license, so it's not an option for me to use anything else.

The main thing I noticed about the database API in Rails regards automatically generated IDs as primary keys. It assumes that you have a datatype that generates this for you. Now I suppose that the writer of the particular database adapter--in this case Oracle--would have the option of doing something clever in order to use an Oracle sequence. I poked through the code in the supplied Oracle driver, and it appeared to be a reasonable implementation. But I couldn't help but think that it would be a lot more efficient to provide for that functionality in the API itself somehow. I admit that I don't recall the details of some other complaints that I had about it, but there were a few other things I noticed, related to foreign keys I think, that made me wonder how much development time it would take to get the Oracle driver working the way I wanted.

FYI, I wrote a Ruby Oracle class library (http://ruby9i.rubyforge.org/) a few years ago as an exercise in learning Ruby. I even wrote one in C++ (http://jimcain.us/orapp/) a couple years before that.

Also, I've had several cocktails tonight before writing this followup, so who knows what other details I've forgotten or obscured. :)

http://make.rubyforge.org/

If you're looking for a very easy make/ant alternative, look at rake, it's written in ruby, and it's damn easy to use. No fiddling with trailing whitespace or xml.

http://rake.rubyforge.org/files/README.html .adam

There's a nice Windows installer for Ruby and a nice set of Ruby bindings for ImageMagick.

There's a nice Windows installer for Ruby and a nice set of Ruby bindings for ImageMagick.

Hard to say, as you have mistated my original point. It is not that learning a task-specific API is always a bad idea, but that some of the Rails task-specific API makes things harder than they need be.

So you have to learn things to do new stuff? Thanks for the insight.

No one has clained that the choice is either pure framework API or code from scratch, but some frameworks (and Rails may be headed this way if it is not already there) so pull you into their idiomatic way of thinking that it hampers you in the long run. (I suggest people lurk on the Rails dev mailing list and read the questions that come up. Very often thay are request for some magic Rails command to perform what is in fact a trivial Ruby task, exepct that using straight Ruby would entail actually learning Ruby.)

For many tasks one is better served learning about ActiveRecord (or Og, for that matter), on its own, and using it where needed. Or going a more agile route and using Nitro. Or opting for a different design pattern altogther and chosing Wee. There is far more in the Ruby Web world than Rails, but only one has the hype.

Hard to say, as you have mistated my original point. It is not that learning a task-specific API is always a bad idea, but that some of the Rails task-specific API makes things harder than they need be.

So you have to learn things to do new stuff? Thanks for the insight.

No one has clained that the choice is either pure framework API or code from scratch, but some frameworks (and Rails may be headed this way if it is not already there) so pull you into their idiomatic way of thinking that it hampers you in the long run. (I suggest people lurk on the Rails dev mailing list and read the questions that come up. Very often thay are request for some magic Rails command to perform what is in fact a trivial Ruby task, exepct that using straight Ruby would entail actually learning Ruby.)

For many tasks one is better served learning about ActiveRecord (or Og, for that matter), on its own, and using it where needed. Or going a more agile route and using Nitro. Or opting for a different design pattern altogther and chosing Wee. There is far more in the Ruby Web world than Rails, but only one has the hype.

Well, my grandma could probably handle it, but mine builds her own computers rather than buying pre-built ones.

Even if she couldn't, though, I'd just tell her to install this. It's just as easy as installing any other program, really. You don't see people complaining that Java is unusuable just because it doesn't come installed by default on most computers.

And if your grandma is using Linux, I would imagine that she's computer-savvy enough to handle a package manager anyway.

...especially having dealt with something like this (on a much smaller scale) recently.

We were having bandwidth limitations on RubyForge; it was getting up to 80 GB per month at the end of 2004. Mirroring out releases helped get usage back down to 15 GB per month. Many thanks to our mirror providers!

...especially having dealt with something like this (on a much smaller scale) recently.

We were having bandwidth limitations on RubyForge; it was getting up to 80 GB per month at the end of 2004. Mirroring out releases helped get usage back down to 15 GB per month. Many thanks to our mirror providers!

...especially having dealt with something like this (on a much smaller scale) recently.

We were having bandwidth limitations on RubyForge; it was getting up to 80 GB per month at the end of 2004. Mirroring out releases helped get usage back down to 15 GB per month. Many thanks to our mirror providers!

> we decided to spend our budgeted
> documentation hours on WikiWork

Very, very cool. I'm working on a Ruby extension on work hours too; it's pretty cool to be able to do so.

> Now I feel guilty for reading /.

Bill it as "networking" :-)

gforge=> select browser, count(browser) from activity_log group by browser;
browser | count
---------+--------
OPERA | 240
OTHER | 167539
MOZILLA | 251311
IE | 73724

A really open-source version might be Alexandria.
Written in ruby, runs on Gnome.

try wxruby or wx* that way you can switch or combine languages and still use the same window tool kit.
wxw
wxruby

Ruby does not have a canonical IDE, unlike Java.

However, most developers agree they are more productive in languages like Python, Ruby or OCaml than they are in languages that do have auto-complete environments (e.g., C++, Java, C#, etc...).

This shouldn't be taken as a "We don't need no stinkin' code completion" comment. It's just an observation that code completion would be icing on the cake, but the cake is allready there, tasty and full of chocolate.

If you want to try ruby with code completion, check out FreeRIDE. It is not done yet, but it'll show you the direction things are going.

True enough, but if and when that day comes, duplicating delcio.us will problay take half a day using a decent language and framework.

In the meantime, the real value of del.cio.us are the collaborative data. It's the network effect of many people using a common resource. Split that resource up into disjoint sites, and the value is diminished.

Just make sure you backup your bookmarks, and you should be good if things change.

...on this.

It's already paid off - I've gotten some good input from outside folks, and our company can use it however because it's under a BSD license. Everybody wins!

...the lists are active (and questions actually get answered authoritatively), the IRC channel is lively, and the development is in the open. They've even got the logs of the team meetings on line.

PLUG: I'm working on a Ruby wrapper for Evolution. Good times!

...and better; I've been using it for a few years now and it's a fine piece of work.

I'm working on a Ruby binding for it that will make the data easier to get at, too... good times.

> Empirical evidence has shown, time and time
> again, that low level languages like C and
> Forth produce more efficient, faster, and
> easier to maintain code than today's so
> called high level languages.

How's that? So it's actually better to manually malloc and free memory than to let a GC take care of it? Surely you're just jesting!

As someone who's currently wrapping the Evolution C API in Ruby, I can assure you that writing Ruby code is much easier than writing the corresponding C code.

I'm not sure why this would be considered a "Linux strength",. since all the good high level languages - Ruby, Python, Perl, etc - all run on Linux, also.

Actually, rails/any ruby library/app/whatever is quite easy to install if it is available on ruby gems and you have installed ruby gems. ruby gems is sort of like apt for ruby. Once you install gems, to install rails, all you have to do is, gem install rails and gem uninstall rails to uninstall rails. Although you are unlikely to need it. :-D

> I was hoping it would be a GNOME/GTK Calendar

Evolution has a nice calendar interface, and the API is pretty good, too.

I'm working on a Ruby binding for it and it's straightforward as long as you're familiar with the Gnome coding conventions.

...but they don't have that pause at the beginning while a 20MB+ VM spins up, they don't have Microsoft shipping mutant versions of the standard, and they're a lot more fun to write.

Finally, as a Java afficiondo, you can have the best of both worlds in at least two different ways as well.

...Subversion support is one of the most requested features on RubyForge.

Is there a StatCVS-type reporting tool for Subversion? I suppose StatCVS could be modified to support Subversion... there's been some discussion of it on their mailing list...

1. boost-build v2 is the absolute BEST if you want to build C/C++ projects with multiple compilers & versions & targets--or even on simple projects that require a one-liner to feed into boost-build2 (normally taking 5-20 lines in GNU make).

Upside for boost-build2? Wraps compiler/linker flags in a generic language for many compilers and versions(gcc, msvc, bcc, etc). Also very easy for simple projects but truly shines on huge and complex projects. Jamfiles can inherit properties , requirements, targets, etc. from parent directories. Very very cool.

Downside to boost-build? Documentation truly sucks compared to other tools. Docs getting better but new users should prepare to unexpectedly find features they could've used to avoid hours of effort.

Boost-build v2 uses bjam but there seems to be a plan to add support for Python.

2. Scons is the next best thing to boost-build v2. The underlying language is Python but you don't have to be a Python expert to use it. And the documentation is much better than boost-build v2. However, it takes many more lines to get things done than boost-build v2 (which isn't all that bad considering boost-build v2 can do things in only 5 lines to replace a 40-line gnu makefile).

3. rake is a make-alternative written in Ruby. For all you recent Ruby converts, be sure to check it out. I love Ruby but I gotta admit, I don't see anything out there being better than boost-build v2 today.

GNU make served us well but it is time to move on to better choices that make us more productive. Just like cvs having served us well but svn and others being a better choice today.

.SWF files are an open format, and a recent issue of Dr. Dobbs' Journal has an article on creating an .swf file from a small C++ program.

whether tools like Flash or Director exist as OSS implementations, i don't know. but i do know that libraries and interfaces exist for creating .swf files. just have to look for them.

ooo = OOo::Doc.new( filename )
new_text = "This is the NEW text added #{Time.new.to_s}"
ooo.insert( new_text );
res_ary = ooo.find( /NEW/ )
ooo.insert_heading( "This is the heading", 1 )
ooo.save

• JSON in Java, an example set of Java classes that parse, generate, and manipulate JSON data strings.
• JSON in C.
• JSON in C#.
• JSON in JavaScript, a note on using JSON notation with JavaScript.
• JSON-RPC.
• JSON-RPC-JAVA ORB.
• JSON in Ruby.
• JSON in ML and Ruby.
• The Fat-free Alternative to XML.
• An example of JSON-encoded messages.

Wheres a good tutorial site? (multipule if possible)

Any books worth reading?

There's more than these, of course, but these will definitely get you started.

General resources sites?

• Borges, has been around for a bit, more or less a direct port of Seaside
• Wee, a newer frame work that uses a more modern approach to linear web programming. It can work without continuations meaning you can avoid some of the issues with those. You'll probably find the author's weblog interesting. Another good point about this is that it seems to take code and ideas from Ruby On Rails as well.

If you like seaside, take a look at Borges. I'm pretty sure it's a reimplementation of seaside in Ruby (and think it might have been done by the same ppl who did seaside).

How do you run that Hello World app in smalltalk? Do you need to have the environment running, and have to type it into an interpreter window, or can you have a script starting with a "shebang" line that looks like the following?

#!/usr/bin/smalltalk
Transcript show: 'Hello World!'.

I've tried Squeak, and that's the part I couldn't figure out. If all I want is a script, a little executable program I can have sitting on its own in a "/home/me/bin" directory on my machine, can I do that?

Rails is an incredibly good framework for Ruby, that really shows off its power and makes it easy to get a web application going, but it's not all that Ruby has to offer.

Ruby is full of incredible libraries and frameworks like this, especially where text processing and web development are concerned. It's because Ruby has such a rich set of features.

Anyone who likes Rails should dig deeper. Heck, Ruby's standard library comes with some amazing things. Ruby also has a framework called RubyGems,
which is very much like Perl's CPAN integration or CommonLisp's ASDF framework.

...on RubyForge, including Magic Maze (which was inspired by Gauntlet) and Tadpoles.

...on RubyForge, including Magic Maze (which was inspired by Gauntlet) and Tadpoles.

...on RubyForge, including Magic Maze (which was inspired by Gauntlet) and Tadpoles.

...for Ruby here.

Still lots to do but it's a start...