Slashdot Mirror

I like bzr -- I honestly couldn't choose between hg and bzr, so I eventually picked it for non-technical reasons (bzr is used by Canonical).

However, if you do go with a distributed system, you may want to take a look at Ditz -- it's an issue tracker which uses flat textfiles as a datastore, with the intent that you'll just check those into whatever version control you're using. That means the opening or closing of an issue is directly tied to a commit.

Which means it will work well with any SCM, but is especially well-suited for a distributed one -- better, I think, than trying to wedge those things into something like Trac.

It's not impossible to write the Knuth's optimal line break algorithm in such a way that it continuously examines better lines as text comes in. The algorithm is based on backtracking, but it can be made to work also from beginning to end (reverse order).

Btw, I wrote a small Ruby implementation of the justification algorithm (for fixed-width fonts), which might be useful especially for emails. I was at one point thinking of doing a variable-width font version of the program to make it possible to do this on *server side*, but it has obvious problems (the web server must know about fonts). The program is here:

http://rbpar.rubyforge.org/

...is a fine book by M. Tim Jones if you want a nice overview of programming some "AI" techniques. I wrote up a review of it on Freshmeat. There's a second edition out now... and here's a translation of some of the example code from C to Ruby.

Something like *Tidy is all you need if you don't feel like using some fancy text editor or are too lazy to configure your editor.

http://perltidy.sourceforge.net/
http://rubyforge.org/projects/tidy
http://tidy.sourceforge.net/
etc

If you're just looking for animation in javascript, some much more impressive examples are in the CAKE (Canvas Animation Kit Experiment).

What makes Resig's work interesting to me is his port of the Processing lauguage, so the existing Processing examples can be run without Java. I haven't looked at the processing.js source, but I imagine it would run somewhat faster if you used his API directly, instead of parsing Processing code.

If you're interested in NRK's programs, why not download them straight from NRK? NRK are streaming almost everything! I've written a little Ruby script that scrapes NRK's JavaScript-heavy website until it gets to the raw mms:// URL, which you can then stream or dump via mplayer. I've included a few utility scripts in svn that let you do either.

Currently I'm working on features to recursively list all of a series' episodes, for example. Then they could be queued or downloaded. We could even parse the date from the filename or the link so that you can specify a time frame for your episodes. Any help is really appreciated, as it's just a rough hack so far (but it works).

Before you ask: I'm trying to learn Norwegian and NRK is a fantastic source of training material :)

As much as I agree with the parent that learning from DSLs / specific libraries can make it more difficult to learn Ruby, I disagree that Rails isn't a good way to learn Ruby.

Why? Because Rails gives you a *reason* to learn Ruby. How often do people learn a certain programming language "just cause"? While I love to learn new languages, I tend to learn them when I need to or when there's a great reason to ... for instance, to learn Rails!

I actually didn't learn Ruby by learning _all_ of Rails ... I learned Ruby by using Rails' ActiveRecord implementation.

With 1 line of code ( to set the database connection ), I found that I was more productive in an interactive Ruby console than I was using SQL or using many of the libraries that wrapped the databases I was using. That was my *reason* ( or rather, *excuse* ) to learn Ruby.

So ... while I agree that DSLs can lead to one learning a language slower, I think that they're a great *excuse* to learn the language, and the slowdown is worth it ( because you probably wouldn't have learned the language, otherwise! )

P.S. If you're curious about what I'm talking about, using Ruby / Rails' ActiveRecord to work with your database(s)? Let's say I wanna interact with a little sqlite database ... open up $irb and:

require 'activerecord'
ActiveRecord::Base.establish_connection :adapter => 'sqlite3', :database => 'mysites.db'

class User < ActiveRecord::Base; end
class Site < ActiveRecord::Base
    has_many :users
end

puts Site.count
puts Site.find_by_name('Slashdot').users.map &:email


Or, if I have Dr. Nic's Magic Models ...


require 'dr_nic_magic_models'
ActiveRecord::Base.establish_connection :adapter => 'sqlite3', :database => 'mysites.db'

# don't even have to define a classes ... (uses database tables and relations)

puts Site.count
puts Site.find_by_name('Slashdot').users.map &:email

Does Python have something equivalent? Sure, I'm sure Python's database ORM's make it just as easy (altho I doubt something as dynamic as Dr. Nic's Magic Models exists ... but maybe it does).

But, we are getting off the topic, here, which is, of course Ruby.

> are there good reasons for sticking with CVS or SVN
> or is GIT now The One True Way?

Seems like the other distributed SCMs have their fans too; I've gotten requests on RubyForge for Mercurial, monotone, darcs, etc. There's a request in for git, too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.

> are there good reasons for sticking with CVS or SVN
> or is GIT now The One True Way?

Seems like the other distributed SCMs have their fans too; I've gotten requests on RubyForge for Mercurial, monotone, darcs, etc. There's a request in for git, too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.

> are there good reasons for sticking with CVS or SVN
> or is GIT now The One True Way?

Seems like the other distributed SCMs have their fans too; I've gotten requests on RubyForge for Mercurial, monotone, darcs, etc. There's a request in for git, too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.

Might not be what you're looking for, but ever since I discovered Python and SQLite I've found this little tool http://sqlitebrowser.sourceforge.net/ to be brilliant.

Granted, I'm not using SQLite to do anything complicated - mostly just as dumb storage for non-huge cross-linked lists but it still seems remarkably capable, very fast and very low on resources, with the GUI providing a nice interface for a quick gander at the data structure.

There's also a Ruby/GTK gizmo here http://rsqlitegui.rubyforge.org/

And ActiveRecord does not mandate your primary key. If you don't like the default, you can easily change it.

By change it, I assume you mean use another field.

Perhaps I should have been clearer about what I meant.

What if I want a compound primary key? Rails doesn't support that out of the box, although there is http://compositekeys.rubyforge.org/, so perhaps Rails is flexible after all.

Similar comments apply to surrogate keys of course.

I think there is a tension between what can be done with the framework, and the way DHH thinks you should use it.

Yes, but as far as I know, RoR is the main package people use for Ruby, versus Python which has 5-6 packages that I know of.

I suggested at least that many alternatives for Ruby, and there are more. You don't base all your decisions on how popular or well marketed something is, do you?

Part of the reason for this is that Ruby's language has some unique features that make it favorable to RoR's style

Perhaps, but it's also perfectly favourable to various other "styles". Metaprogramming is quite a general tool, as you might have guessed ;)

I was assuming that most readers would be smart enough to figure out I meant the standard way you do things in PHP or Python

It's akin to calling PHP development Cake. Names of frameworks are not interchangable with generic terms for web development in a language, and I assumed you'd be smart enough to recognise that. I've used Ruby for 8 years, and I certainly don't equate Rails with the One True Way of doing web development in it. I might end at it for some things, but I certainly don't start there.

There's plenty of sites I'm interested in making that actually have no database whatsoever. Because that's RoR's, I would assume it's not going to help me much.

Like I said; you may not have a database, but you probbaly have data you want to serve dynamically in some way? Much of the advantage Rails provides is a convention for how to interact with that data, with ActiveRecord being the de-facto example, but, for example there's also ActiveResource which talks to web services instead of directly to a database; if you don't want a database, you just fill in the "M" part of MVC with a layer that talks to something else, and try to stick with the conventions to keep the interface Rails-alike. Maybe you'll make find() work off flat files, and put more complex queries through Ferret. Maybe you'll just store it in an object temporarily and use validations to help sanitize your data and drive your forms.

Or, again, if that's all a bit overkill or otherwise a poor fit for your applications, use a different framework, or none at all.

By going back, I didn't mean revision control. I meant changes in the structure of the code (you might have heard of refactoring?) or even the database.

The structure's defined by things like your class definition and routing configuration: generating a controller or model basically makes "class FooController < ApplicationController;end" in the right place, plus helpers for your views and templates for testing. You're generally not generating scary big fragile chunks of code; if you want to rename something, do so, it's not magic. The point of metaprogramming is that you can be agile with these changes without you having to generate and maintain reams of static code.

Database wise, the models are mostly driven by what the database looks like; you add a column to the database (probably using a migration) and your models automagically notice. Renaming a model can be done without renaming the table, and vice versa, and you can make renames less painful by mapping old names to new trivially. Either way, the code generation helps you because it's mostly done dynamically via metaprogramming based on the code you wrote, not statically based on your script/generate commands like, e.g. the C++ GUI generators you might be familiar with.

But again, even that level of code generation might be overkill, and if having lots of files dotted about feels wrong when you really just want one or two modest .rb's for a small application, something like Ramaze, Rack or even Campin

Yes, but as far as I know, RoR is the main package people use for Ruby, versus Python which has 5-6 packages that I know of.

I suggested at least that many alternatives for Ruby, and there are more. You don't base all your decisions on how popular or well marketed something is, do you?

Part of the reason for this is that Ruby's language has some unique features that make it favorable to RoR's style

Perhaps, but it's also perfectly favourable to various other "styles". Metaprogramming is quite a general tool, as you might have guessed ;)

I was assuming that most readers would be smart enough to figure out I meant the standard way you do things in PHP or Python

It's akin to calling PHP development Cake. Names of frameworks are not interchangable with generic terms for web development in a language, and I assumed you'd be smart enough to recognise that. I've used Ruby for 8 years, and I certainly don't equate Rails with the One True Way of doing web development in it. I might end at it for some things, but I certainly don't start there.

There's plenty of sites I'm interested in making that actually have no database whatsoever. Because that's RoR's, I would assume it's not going to help me much.

Like I said; you may not have a database, but you probbaly have data you want to serve dynamically in some way? Much of the advantage Rails provides is a convention for how to interact with that data, with ActiveRecord being the de-facto example, but, for example there's also ActiveResource which talks to web services instead of directly to a database; if you don't want a database, you just fill in the "M" part of MVC with a layer that talks to something else, and try to stick with the conventions to keep the interface Rails-alike. Maybe you'll make find() work off flat files, and put more complex queries through Ferret. Maybe you'll just store it in an object temporarily and use validations to help sanitize your data and drive your forms.

Or, again, if that's all a bit overkill or otherwise a poor fit for your applications, use a different framework, or none at all.

By going back, I didn't mean revision control. I meant changes in the structure of the code (you might have heard of refactoring?) or even the database.

The structure's defined by things like your class definition and routing configuration: generating a controller or model basically makes "class FooController < ApplicationController;end" in the right place, plus helpers for your views and templates for testing. You're generally not generating scary big fragile chunks of code; if you want to rename something, do so, it's not magic. The point of metaprogramming is that you can be agile with these changes without you having to generate and maintain reams of static code.

Database wise, the models are mostly driven by what the database looks like; you add a column to the database (probably using a migration) and your models automagically notice. Renaming a model can be done without renaming the table, and vice versa, and you can make renames less painful by mapping old names to new trivially. Either way, the code generation helps you because it's mostly done dynamically via metaprogramming based on the code you wrote, not statically based on your script/generate commands like, e.g. the C++ GUI generators you might be familiar with.

But again, even that level of code generation might be overkill, and if having lots of files dotted about feels wrong when you really just want one or two modest .rb's for a small application, something like Ramaze, Rack or even Campin

h1. Big Header
 
h2. Smaller Header

Big Header
==========
 
Smaller Header
--------------

I'm not making any argument against Mongrel technically. I was trying to soft play it, but here's the hard version: Do you really want a piece of code in your software stack from a guy that is a loose cannon like that?

it's an open source library tracking system. due to a recent review where someone had a library of 3k+ books and had problems with alexandria, people on the dev list have been actively addressing some of the reviewer's concerns. of course, they are still looking for help (like any open source project), but it's been an ongoing gnome project for a while. details here.

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key....

If you do a search for "composite keys rails", hit #1 is this, a gem written by a fairly prominent ruby programmer that makes it trivially easy to use composite primary keys within ActiveRecord. My guess is if you actually cared about this issue, rather than just raising it as a canard to bash Rails with, you would have found this solution to your problem and wouldn't be posting here

I'm not familiar with SciPy or IPython, but Ruby has Ruby/GSL, a wrapper around the GNU Scientific Library. It defines Vector and Matrix classes and many math and stats functions that work on them. There's also Numerical Ruby NArray that defines structures similar to Vector and Matrix and basic math operators. I've used both of these a little, but not for anything large. For example, I just used Ruby/GSL to calculate a Receiver Operating Characteristic curve for a spamfilter, but GSL has no ROC stats function so I wrote my own in Ruby. The function itself has no advantage over Ruby's built-in Arrays, but I left to door open massage my data using GSL before calculating the ROC curve.

See also the SciRuby wiki.

I'm not familiar with SciPy or IPython, but Ruby has Ruby/GSL, a wrapper around the GNU Scientific Library. It defines Vector and Matrix classes and many math and stats functions that work on them. There's also Numerical Ruby NArray that defines structures similar to Vector and Matrix and basic math operators. I've used both of these a little, but not for anything large. For example, I just used Ruby/GSL to calculate a Receiver Operating Characteristic curve for a spamfilter, but GSL has no ROC stats function so I wrote my own in Ruby. The function itself has no advantage over Ruby's built-in Arrays, but I left to door open massage my data using GSL before calculating the ROC curve.

See also the SciRuby wiki.

Over on Linux, my perception is that FastCGI enjoyed a brief reawakening as it was (for a while) _the_ way to deploy Ruby on Rails apps with Apache. But now that seems to have changed to over to using Apache + mod_proxy_balancer + Mongrel.

One nice thing about mod_proxy_balancer is that it's easy to distribute the Mongrels across a couple of machines... and Apache will take them out of the loop if the machine goes down or they become unresponsive or whatever. Works for us, anyhow....

> To use Ruby productively, you have to learn to
> take advantage of the dynamic typing.

So true. I translated a bunch of little artificial intelligence example programs when I was first learning Ruby and now when I look back at that code there's a lot of stuff I'd do differently. Even little idioms like using x = [] vs x = Array.new... I was a Java/C guy doing Ruby, and it showed.

> Elite had hundreds of systems on something like four galactic
> maps, but it wasn't infinitely generated.

Yup, I think the trick was that it was generated with fractals, which was why they could have so many systems and planets and such in 16K of memory.

There's a little blurb about Elite in the preface of Infinite Game Universe; it's kind of funny when it says something to the effect of "a DOOM WAD file can be as large as 2MB"! Now we can generate those same WAD files with interpreted scripting languages, and a 2 MB download takes a few seconds...

I'm a little biased, but I think the RSpec test description language (built on Ruby) encourages nice, legible test scripts. You get to use natural-looking language like this example:

@stack.peek.should == @last_item_added

...as a pleasant alternative to a bunch of assert macros. The source code to RSpec itself is pretty decent, too.

I'm a little biased, but I think the RSpec test description language (built on Ruby) encourages nice, legible test scripts. You get to use natural-looking language like this example:

@stack.peek.should == @last_item_added

...as a pleasant alternative to a bunch of assert macros. The source code to RSpec itself is pretty decent, too.

Mongrel is a web server, hence this package includes a web server (unless it doesn't actually contain Mongrel, despite what the writeup says). Also, Ruby 1.8.6 comes with WEBrick, which is a the web server Rails uses by default...

Anyway isn't a simplified Rails installer for Linux kind of redundant? Most newer Linux distros I've seen already have a native package that installs Ruby on Rails and all its dependencies. Most people will probably find the Instant Rails package a lot more useful, since it does the same for Windows.

Mongrel people dont recomment Lighttpd here. So here is the debate:

* mongrel with nginx
* lighttpd with fastcgi
* apache

Here are some steps you could take:

1. decide what language(s) you want to use (C++, Ruby, etc.)
2. decide what license you want to support (GPL, BSD, MIT, etc.)
3. decide what platform you want to support (Linux Only, Windows Only, Cross-Platform, etc.)
4. decide if you prefer server-side or client-side programming (web server vs GUI, for example)
5. decide if you prefer working in large teams or small teams
6. use the above criteria to filter out projects in places like sf.net, tigris.org, CPAN.org, etc.
7. check the mailing lists of potential projects to see if the communication style (or maturity) of developers match yours
8. initiate contact by letting them know your interest and how exactly you'd like to contribute

There are numerous projects in need of help. Some of them, like wxRuby, are at the intersection of fast-rising language (Ruby) and fast-rising GUI (wxWidgets) but could use more help.

> 5. Experience using CAD like programs (to make maps of my school of course)

Better yet, learning to program by writing DOOM map generators.

Yes, the standard shells are all command oriented, textual and several lack good networking hooks like perl does, but then we also have ruby...

Oh look, Ruby 1.8.6, and for Windoze too!

http://rubyforge.org/frs/download.php/18566/ruby18 6-25.exe

Joy of joys!

You want to write windows programs? Last I checked you had two compiler options anymore: Microsoft and Microsoft. Even the cost of visual basic is going to be close to $100 US.

Uh, Free Microsoft Visual Express, Free Python on Windows, Free Ruby on Windows, MinGW...

If you run Windows on OLPC, I'd go for Windows XP Embedded.

I spent quite some time looking for a way to run my own web-based file transfer site so accountants could stop e-mailling 10MB data files to each other.

The best I've seen is Boxroom, an OSS Ruby on Rails application for web based file transfer. With the Mongrel web server it does upload progress, recent versions have had in-file search added, and my employer is currently sponsoring the implementation of virtual hosting in it.

I would like more people to know about this program - it's very cool, and more developers on it would be certainly be appreciated by all of us who use it!

> then I'd strongly recommend getting a separate
> reference book just for Ruby by itself.

The Ruby Way is an excellent book for that, plus, the author, Hal Fulton, is a nice guy. And his RubyForge user account name is "hal9000", for which he gets additional points.

That's an interesting aspect of rubinius - not only are they attempting another Ruby implementation (and a rather minimal one at that), but they are soliciting specifications (via RSpec) that describe current Ruby behavior, which they then use to test their implementation.

So why do you post anonymously? :-)

Because I can, I don't need a userid to call your bullshit

Please do. I am sure they are 1. already fixed or 2. not present in the new parser (YARV) which is going to be Ruby 2.0


Sure thing bud:

http://rubyforge.org/tracker/?atid=1698&group_id=4 26&func=browse

Please get your facts right when flaming. Ruby was started in 1993. PHP/FI was started in 1994. At that time PHP was not even a language. PHP3 (on which all the crap of today is built) was released in 1997!

Funny, for someone whos programmed sooooo much, you'd figure they'd know a little history about that language.

From Wikipedia

http://en.wikipedia.org/wiki/Ruby_on_Rails

Ruby on Rails was extracted by David Heinemeier Hansson from his work on Basecamp, a project-management tool by the web-design company 37signals.[1] It was first released to the public in July 2004.

OK July 2004 means Ruby on Rails not even 3 years old. Unproven to say the least. Now stop trying to bullshit everyone by spreading misinformation

It's too bad Rails 1.2 wasn't released with mongrel (a very nice app server designed to run Rails apps, among other things). Currently deploying a production-ready server capable of running Rails is a uncomfortably unrails-like experience. Mongrel makes things a bit nicer, but even with that running under virtual hosts and/or with SSL requires some seriously heavy lifting (think Mongrel running behind Apache acting as a reverse proxy).

Until we get a quick and easy way of deploying Rails apps -- especially at the shared hosting level for ISPs (along the lines of PHP hosting, which is now standard), Rails will continue to have a difficult time finding a niche. The only place where Rails really belongs right now, and the only place where I'm using it (and loving it) is the corporate intranet, where putting up dedicated mongrel servers for internal web-based apps is not an issue.

...now I can get back to work on the Linux port of indi. It's one of the few Flash desktop apps out there, and it's a shame not to have it on Linux.

Besides, it'd be a waste of all that code I wrote for the Evolution extension!

A small fast HTTP server written in (mostly) Ruby that can be used to host web frameworks directly with HTTP rather than FastCGI or SCGI.

> I don't know what to do to solve this, any suggestions?

1) Address the ignorance factor first. Make sure people are aware of the issue of data security and the seriousness of it. Don't assume they automatically know. Explain it to them in a way that is informative and not condescending.

2) Use a platform designed to keep users in userland.

3) Setup laptops with encrypted filesystems [0] and encrypted connections [1]. Do not give users administrative access. Re-image [2] system partitions for extra freshness. Stop using WEP.

[0] http://rubyforge.org/projects/fusefs/
[1] http://www.oreillynet.com/pub/a/wireless/2001/02/2 3/wep.html
[2] http://www.feyrer.de/g4u/
      http://sourceforge.net/projects/g4l

> In fact almost no one uses ruby.

11000 RubyForge users disagree with that...

Step 1: write a systematic test plan. There are all kinds of acronyms and books out there on the subject - I doubt you need it. At the very least you can start with CRUD (Create, Read, Update, Delete) and go from there. Cover the success path, cover the failure paths.

Step 1.5: show the test plan to someone else who's reasonably familiar with the project being tested. Let them ask questions about the test plan. Add any new test cases they think of (or that their questions cause you to think of) that you feel are important to test to the test plan. Repeat if you have time (and if you don't have time, show the test plan to someone else then start on step 2 while they're reviewing it.) The developer must, if possible, be one of the people who reviews the test plan. [Your test cases may trigger the developer to realize they hadn't thought about how to handle a certain case, which may lead to a modification to the feature specification and/or your test plan.]

Step 2: automate. This isn't optional if you're planning to maintain a project beyond the 1.0 release. For specifics, it depends on your project. Is it mostly a Java app (http://www.junit.org/)? Is a lot of the logic in the database (http://www.dbunit.org/)? Is it a web app, regardless of language (http://webtest.canoo.com, http://wtr.rubyforge.org/)?

Step 2.5: have someone else code review your tests, just like you'd have someone code review the project code. When they find bugs in your test, fix them. When they find bugs in the project code ("What, you're testing to make sure 2+2=5? That's what the code returns? That needs to be fixed."), pass them back to the developer. When they offer suggestions for other tests to be added, update your test plan and create those new tests.

Step 3: run your automated tests and laugh at how much easier it makes your life than manual testing.

Step 4: If possible, generate some measurement of code coverage and look for lines of code that are not being tested. Add test cases for those lines to your test plan, and add automated tests to the test bed. If you can't think of a way to exercise that line of code, ask the developer. If neither of you can think of a way to exercise that code, ask if it's dead code and needs to be removed. While code coverage is not the be-all and end-all of measuring how effective testing is, if you're not exercising a line of code you'll never find a bug that may be hiding there.

Depending on what you're actually doing, there may be other steps that you can/should run or other suggestions the Slashdot community can make. For instance, I test numerical software, and one of my steps is to think about how the weird edge cases of IEEE arithmetic (Inf, NaN, denormal numbers, etc.) interact with each other and the code.

Step 1: write a systematic test plan. There are all kinds of acronyms and books out there on the subject - I doubt you need it. At the very least you can start with CRUD (Create, Read, Update, Delete) and go from there. Cover the success path, cover the failure paths.

Step 2: automate. This isn't optional if you're planning to maintain a project beyond the 1.0 release. For specifics, it depends on your project. Is it mostly a Java app (http://www.junit.org/)? Is a lot of the logic in the database (http://www.dbunit.org/)? Is it a web app, regardless of language (http://webtest.canoo.com, http://wtr.rubyforge.org/)?

Step 3: run your automated tests and laugh at how much easier it makes your life than manual testing.

I couldn't resist - in Ruby, using the beautiful (but much understated) hpricot library:

Check it out - I've been using it for a project, and it's really fast and really easy to use (supports both xpath and css for parsing links). For spidering you should check out the ruby mechanize library (which is like perl's www-mechanize, but also uses hpricot, making parsing the returned document much easier).

I believe that, in most cases, the problems lies in the page generation. I guess most webmaster test their "static page" layout against xhtml validator, and then use PHP or ASP to generate their code at production-time, thus mixing server code and presentation code. A nice solution I find for this problems are XML constructors like Ruby's Builder and Rails' Markaby. Both of them save a lot of typing (no clumsy &lt/tags>) and will scream at schema error.

The folks at Koders have been nice enough to give RubyForge a little Javascripty thing that integrates nicely into the regular GForge user interface so that folks can search the RubyForge CVS repositories. I've talked with them a couple of times and they seem like nice folks.