aredridel, posts by tag: ruby - LiveJournal

Now that Liferea supports remote OPML files (this in version 1.4), I've set up my livejournal feeds to automatically come and go based on my friends list. I wrote a little CGI script that transforms the LJ FOAF file into an OPML file (including the authentication that's needed to read protected LJ entries.

The code's at http://dinhe.net/~aredridel/projec… (GIT repository), if anyone wants to adapt it. It's obviously not secure, but it should work in a pinch.

I also discovered that there were about 150 journals that I wasn't reading because my manual process managed not to add them. I'll be keeping up with people better now. Sorry about that, folks.

Use the 'user' table from the default connection or pool

class User < DB('user')
end

Use a specific database connection or pool

Connection = DBConnection.new(...)

class Post < DB(Connection, 'post')
end

That is, identify the database by a (reconnectable) connection to it.

Associations

class Post < DB('posts'); end

class User < DB('users')
	collection :posts, Post, :author # Optionally specifying remote key
end

class Post < DB('posts')
	reference :author, User
end

Collection associations return a collection object, not an array — it's enumerable, but will perform the fetch either lazily or eagerly, and has methods to force those. It could also take advantage of cursors for huge datasets.

All in all, it's like a low-magic, easy-to-debug ActiveRecord that I have in mind. I'd layer it on top of DBI, and go about cleaning that up and speeding it up where possible. I'd also love to see the low-level database APIs speak something that's directly usable as a DBI driver, and do type conversions in the database-specific and fastest way possible, preferably in C.

Queries by single field name and primary key should be easy. Maybe something like User.find(:name, 'John') or User.fetch(1)

Queries by join to an associated table should be possible. I'd love suggestions for an API. Dropping to SQL should only be needed for really complex cases, and be well-defined how the objects are derived from the result set. Replacing what's under the hood with something entirely unlike SQL should be possible and only break apps using SQL queries.

All of this makes me wish Ruby had a way to swap in a custom parser inline and then yield back to normal parsing at some place. Something that would allow User.find(name = 'John' and joindate < Date.today) — mixing in some Ruby syntax into a custom parser. I've some thoughts on how that could be done, but nothing coherent enough to stick in code.

I've been working on getting mailr to work. It's not easy.

There's a host of tiny deployment issues that have to be smoothed out. Shebangs are wrong, developed on a Debian-variant, I can tell — the shebang reads #!/usr/bin/ruby18. There's dependencies on Rails being installed, being the correct version, and being in a similar place as on the developer's machine.

It ships in development mode, so one has to understand rails' three-database development framework before you can install it. The docs assume you know this — I only know it having worked with Rails a little, but your usual sysadmin is gonna have a fit when first they have to install ruby, then install rails, then install a couple other dependencies, then start learning how to develop with rails to get an app off the ground.

There's evidence in the rails environment.rb that the rails files were copied into vendor/ as is typical of rails, but they've been sloppily omitted — I'd prefer that rails worked this way from the start, really, since making local copies is equivalent to static linking. Great if disk space and memory are free, I guess. Makes it a pain to roll out a library update to a bunch of apps, though. Sloppily ripped out is bad, too.

It also requires a DRB backend process to handle persistent connections. That's no problem, though I had to correct some of the code (and it requires it to be run with the current directory being lib/ in the mailr distribution. There's no startup script for it, no SysVinit script, no suggestion of a cronjob to start it, nothing. You're on your own here.

This is something I see a tendency toward in rails. The conventions that are convenient for a developer with a shell always open within the rails app files are a hindrance to actual deployment on a unix system. There's path issues, lack of startup scripts, and you have to understand rails development process to even get an app running. Keep working, guys.

Oh, and it doesn't work with my imapd.