Welcome to Deadman.org.
Good news and bad news.
The good news is that I've (finally) discovered and fallen in love with del.icio.us. Which means that all of the code I wrote for the DMR8 bookmark manager is being replaced with a clone (that will support using del.icio.us as a mirror) of that interface with some additional functionality. The bad news is that this will take time to write.
The good news is that I've decided that my database schema was stupid and I'm moving to a better one. The bad news is that this takes time.
The bad news is that I'm 0% further along on the user administration stuff that I complained about previously (and thus no closer to actually releasing any of this code. The further bad news is that I've raised my own bar for what DMR8 is going to do, which means additional development time. The final bad news is that I've still not had any offers to help.
DMR's anniversary is still a couple weeks away. In the past, it's been the time when I update the world on the current state of DMR. For some reason, I feel like doing it this morning.
It's been over two years since the last real release of DMR. There was a maintenance release that came out more recently than that, but it only fixed some code that stopped working. I mention this only because a few of my friends used to tease me about not being able to keep up with what they called "the hourly releases." :)
What the hell is taking so long? Well, the biggest part of the two years was simple procrastination. My personal life changed a lot and I got out of coding and more into music and film. When I was taking the time to code, I was experimenting with external libraries. My lack of programming experience contributed to my using a couple of those libraries longer than I should have, so the extrication process took longer than it should have.
I recently got a couple of beta testers (well, one and a half really.) Having users, for me, always accelerates development. Glenn's even switched to DMR for his "production" bookmarks.
Most recently, I've been working on a feature called "metafeed." DMR, which has a new name, BTW, still has the concept of individual RSS/ATOM feeds, but it can also truly aggregate feeds into a sort of chronological newspaper containing items from several feeds. It has a cool XMLHttpRequest interface that allows one to mark items as "read" as well as queuing them up for easy bookmarklet-assisted browsing. I'd love to work up a demo, but I'm guessing I won't even get around to a marked-up screenshot. Hopefully by the time it's released, I'll have something to entice everyone. While still on the subject of feeds, I should mention that all of the feed fetching is handled by a scheduler (in my case cron) and not by the UI script, so loading should never be slow.
I haven't released it because there's at least one feature that is only about 25% implemented. There is no installer. There is no administration interface of any kind. I haven't written any pagination for long data lists. Some of the features that are implemented, are fairly ugly in both appearance and implementation. :)
I've recently fallen in love with MediaWiki and it's spoiled me to having really nice user interfaces along with unbelievable flexibility. Unfortunately, I still find writing administration interfaces and pagers and all of the other things mentioned above to be incredibly tedious. It's much more sexy to make metafeed do something cool than it is to paginate history or print a list of users, or whatever.
I also keep thinking that I should get someone to teach me object-oriented programming, beyond the basics. It seems like DMR could benefit from a few of the things I've seen other OO PHP apps use. That's probably not going to happen, though. But, hey! I'll take this opportunity to do my periodic scream into the void, asking if anyone out there wants to help. Why help with a slashdot clone or blogware when you can help with something as weird and unique as DMR?! If you wanna help, guess my email address (you'll probably be right) and drop me a line.
I finally got around to getting auto-complete for my bash aliases working. It was much easier than I thought, but mostly because I aped a lot of it. The first thing I stole from /etc/bash_completion (Debian's version, if that matters,) and I stole it quite a while ago, was the "have" function from /etc/bash_completion :
have() { unset -v have type $1 >/dev/null 2>&1 && have="yes" } #EG usage: have vim && alias vi='vim -X'
I use that for all sorts of stuff because I use my bash environment across 3 operating systems and two Linux variants. Using have() makes it easy to alias vi to "vim -X" and not get screwed if there's no vim to be had.
In hunting around /etc/bash_completion, and trying to figure out what was going on via the bash man page, I saw that they were using a function to complete apt-get. I had a few aliases for apt-get that I'm very used to typing that only required (a) package name(s): acs, acS and agi. Alas, the function didn't work for them because they already had the apt "command argument" (for lack of a better term) in them. So I made "ac" and "ag" below.
Once I actually read _apt_cache it was quite simple to ape out the parts that seemed like they were blocking acs and friends.
have apt-get &&. function _agi(){ local cur prev COMPREPLY=() cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]} COMPREPLY=( $( apt-cache pkgnames $cur 2> /dev/null ) ) return 0 } if have apt-get ; then alias ac='apt-cache' complete -F _apt_cache $filenames ac alias ag='apt-get' complete -F _apt_get $filenames ag alias acs='apt-cache search' alias acS='apt-cache show' alias agi='apt-get install' complete -F _agi $filenames agi acs acS alias dist='apt-get -u dist-upgrade' alias ug='apt-get -u upgrade' alias agu='ug' alias ud='apt-get update' fi
Introducing the external interface to DMR8's bookmarks. It's subject to change, of course. As you might expect, it's also completely customizable. The current look was obviously inspired by my APB install. It uses (at the time of this writing) a view (template) like this.
Child groups of the current group are sorted alphabetically. Grandchild groups of the current group are sorted by the number of bookmarks they contain.
This version of the script has been configured to only show my user's bookmarks. An alternate configuration (for multi-user installations of the script) allows the username to be appended to the script so that /bookmarks/ becomes /bookmarks/deadman/ or /bookmarks/sam/ or whatever. I haven't decided what to display when a visitor hits /bookmarks/ when the script is in this multi-user configuration.
No part of DMR8 cares where it is in your web tree. It'll work off of /. It'll work in ~youruser. At no point do you need to tell it its location in the web tree or the filesystem.
XML feeds are provided on a per-group basis. This lends itself quite well to blogmarking as you simply track your own RSS/ATOM feed. I must confess that the XBEL stuff is just a "best guess" at this point. I can find no XBEL validator and since Galeon seemed to import some examples without trouble, I called it good. The XBEL feed creator does not currently support XBEL's one bookmark in multiple groups feature. It's planned, but is a low priority.
The livesearch thing is a bit flakey sometimes, but I still love it. I've modified livesearch.js to allow the location of the search engine to be specified in the javascript call. This was done to help DMR not care where it is. I'm not a javascript person, so I probably did a lousy job. Feel free to submit a patch!
I plan to implement a caching feature that I'm calling MyCopy. When a user creates a new bookmark, they'll have the option of caching a local copy of the data to which the bookmark points. My intention is that the local copy will be complete, including external javascript and css files, sans images. That's my intention, anyway, but as I once heard a girl say, "you never know what can concur[sic]!"
© 2009 Sam Rowe. Some rights reserved.
RSS headlines