| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| These are ideas I have for little hacks to open-source projects: TWiki - it would be cool to translate to XML instead of HTML and use a style sheet to transform. That would make it easier to write stuff in Twiki and move it to DocBook XML. | ||||||||
| Line: 23 to 23 | ||||||||
Emacs JDE - when you try to build an application it moves point to the line where the first compile error happened, but not the column. Since many of my compile errors have to do with un-imported classes, having the cursor where I could C-c-v-z would be nice.
magit - "folded" log listing i.e. it looks like a one-line listing but when you tab on a commit line it unfolds to show the commit in more detail. | ||||||||
| Added: | ||||||||
| > > | Rails Auditing - all of the plugins I've seen to date (paper_trail, vestal_versions, etc) are "weak" in that they're application-level code so they can be easily subverted by anyone that has access to the database. It might be interesting to have a "strong" auditing package that uses triggers instead of application code to manage the audit data. This would allow for much more rigorous enforcement of the audit rules. You might be able to, for example, make the audit tables writeable only by triggers so external apps couldn't corrupt the data (on purpose or by accident). How would it work? I worked on a previous system where we wrote a tool to inspect the schema and generate a set of audit tables, one for each data table, that tracked the contents of the data tables along with some additional data such as timestamps. We wrote triggers to push data into the audit tables on insert, update and delete. I'm a little fuzzy on whether we wrote the "old" data or the "new" data to the audit tables but either approach should work. There are 3 principal components: schema maintenance, trigger maintenance, and application code. Schema maintenance will probably be patches to Rails' migration code - essentially for each migration action you need to do that action to the audit tables as well as the regular tables. Triggers will be database vendor-specific, but hopefully will be able to be table-independent. It would be a drag to have to change the triggers for adding or removing columns, for example. Ideally we'd be able to create the trigger when the table is created and have the trigger be able to move the data from the regular table into the audit table without a priori knowledge of the table's schema. Might not be possible, in which case schema maintenance like adding or removing columns from tables would require re-doing the trigger. The application code would add on to AR models: it would read old versions and reify them. Paper_trail's API is a good example. Some sort of diff code and some display code would be nice, too. | |||||||