I have mostly shifted my main development language to Ruby, as most of the work I do tends to be pretty well covered with
Rails. That's not new, however - What
is new is that I feel I have got to the point where I actually have something to
share. And it feels very good.
So my next couple of posts (three, actually) will be covering some plugins I've written. They are, of course, just sketched - but they work reliably enough to be deemed as useful by their author ;-)
Today I will start by blogging about
RealFK. Of course, I will be copying from its documentation/description - I wrote it as well, so I'm not really plagiarizing my own site. I'm not suing
self. You can of course also
browse the RealFK SVN tree.
References
Rails is built upon a "dumb database" concept. Rails assumes the database will not force restrictions upon the user - i.e. that the model validators are all there is. But I disagree ;-) I was raised with PostgreSQL, not with MySQL, and I do believe the database can and should impose sane values - It should impose trust on the data..
So, if you want to create a relation field, properly acting as a foreign key and refering to another table, instead of doing it via the
ActiveRecord::ConnectionAdapters::TableDefinition#column (or even
ActiveRecord::ConnectionAdapters::TableDefinition#references) methods, declare them with
add_refrence:
def self.up
create_table :proposals do t
(...)
end
create_table :proposal_types do t
(...)
end
create_table :proposal_statuses do t
(...)
end
add_reference :proposals, :proposal_types
add_reference :proposals, :proposal_statuses, :null => false, :default => 1
end
The corresponding fields (
proposal_type_id and
proposal_status_id, respectively) will be created in
proposals, and the RDBMS will impose a Foreign Key constraint. The references can be removed via
remove_reference, i.e., for inclusion in
down migrations:
def self.down
remove_reference :proposals, :proposal_types
remove_reference :proposals, :proposal_statuses
drop_table :proposal_statuses
drop_table :proposal_types
drop_table :proposals
end
Of course, in this case the
remove_reference call is not really needed - But if you are dropping a table that is referred to from a table that will remain existing, you will have to remove the foreign key constraints (that is, the referring columns).
Join (HABTM) tables
When you define a simple
has_and_belongs_to_many (HABTM) relation in your model, you are expected to create an extra table representing this relation. This is a very simple table (i.e. it has only a row for each of the related table‘s IDs), and it carries foreign key constraints.
Please note that join tables
are not supposed to carry any extra columns - If you need to add information to join tables, think twice and better use a
has_many :elements, :through => :othermodel declaration, and create the
othermodel table manually. To create a HABTM table representing that each person can attend many conferences and each conference can be attended by many people:
def self.up
create_table :people do t
(...)
end
create_table :conferences do t
(...)
end
create_habtm :people, :conferences
end
def self.down
drop_habtm :people, :conferences
drop_table :people
drop_table :conferences
end
The last call will create a
conferences_people table (according to Rails' conventions, table names are sorted alphabetically to get the join table‘s name).
Note that in this case, in the
down migration, the
drop_habtm call
must appear before the
drop_table calls, as it carries foreign key constraints.
These graphs can help give some idea of how the shortened DPL voting period
this year changed voting patterns.
Each vote starts on a Sunday (except 2005 which was a day late). Calls for
votes are posted again each weekend during the vote, and a final call two
days before the end of the vote. These are responsible for most of the
spikes on the graph, and the trail off after each CFV is probably due to
some people seeing it the next day.
Shortening the voting period seems to have made more people respond to
the second and third CFV (both in percentage and absolute number of
voters). It's also interesting that a smaller percent than usual of votes
were recieved on the last day this year. There seems to not have been a
rush to vote on the last day despite the shortened period.
I wonder if posting CFVs more frequently would result in more voters, or
if it would just level off the graph?
(Graph produced using this tool
and final vote timing logs provided by Manoj.)
There have been a number of discussions on sane-devel in the past months revolving around the SANE2 standard (still in development) and/or extensions to the current SANE1 standard. SANE2 is an effort that has been “ongoing” (on and off, mostly off, unfortunately) for a number of years already.
This led to a number of questions being raised, most notably this one: do we need SANE2, or can we get away only with extensions to SANE1? Or should we just redesign the whole stack from the ground up?
It's a bit strange. Still. Writing this personal part of my blog, opening some of my most inner thoughts to the wild public. Though, so wild it doesn't seem to be. To be honest I can't remember having received any bad feedback on my personal stuff, only positive, supportive ones. (Or, there was one. Though, it wasn't related to the core of the personal section but someone thinking it would be "cool" to misinterpret some statement therein and try to hurt me with it. It only made me laugh at them, trying to "use" it as an argument.)
I'm pretty impressed with the new 
If you upload a new package to the Debian archive which contains a setuid or setgid binary please please ask for a security audit, or carry out one yourself.
I certainly accept that the 
After starting to write a comment on 
Quite some time back, I
The lenny l10n NMU campaign is now running for about two months now.
The objectives of this campaign are tackling 
Where, oh, where do I start with this one??
One of the loveliest things about Unix is the select() function (or
its replacement, poll()), and the way it lets a single thread handle a
host of concurrent tasks efficiently by just using file descriptors as
work queues.
Unfortunately, it can be a nuisance to use – you end up having to
structure your program as a state machine around the select() invocation,
rather than the actual procedure you want to have happen. You can avoid that
by not using select() and instead just having a separate thread/process for
every task you want to do – but that creates a bunch of tedious overhead
for the OS (and admin) to worry about.
But magically making state machines is what Python’s generators are
all about; so for my little pet project that involves forking a bunch
of subprocesses to do the interesting computational work my python program
wants done, I thought I’d see if I could use that to make my code more
obvious.
What I want to achieve is to have a bunch of subprocesses accepting
some setup data, then a bunch of two byte ids, terminated by two bytes
of 0xFF, and for each of the two byte inputs to output a line of text
giving the calculation result. For the time being at least, I want the
IO to be asynchronous: so I’ll give it as many inputs as I can, rather
than waiting for the result before sending the next input.
So basically, I want to write something like:
2.6.24 kernels targeted for etch are available for testing in
etch-proposed-updates. Some architectures are missing for this first upload,
but fixes are pending for the next upload.