I installed MT-Blacklist,
a comment and trackback spam filter a couple weeks ago. Man does
it do it's job well. Took a little training to get it catching
all the usual suspects, but just in the past few days it's caught over
a thousand spam comments. So much nicer than having to delete
them manually.
Last night, I also installed MT-Notifier,
which is a plugin to allow you to subscribe to an entry's
comments. I'd been wanting to do that for a while, but since I'm
still running MT 2.6x (the free version), I had some troubles finding
an older version to install. Much thanks to Chad (the author) for
helping out on that quest. So far it seems to be a very nice
little plugin.
Last night I finally got Fink
installed on my newly Tiger-ed PowerBook. Opted for the binary
install this time, and it worked like a charm. Less than 40
minutes to go from noticing that a 10.4-specific release had been made
to having it all set up with X, Gnucash, the GImP, and the GNU
FileUtils package (for the color-aware ls command) all installed.
I was working on a little app of mine over the weekend that uses a
closed-source (encrypted) CFC for some of it's functionality. The
CFC (which will go unnamed to protect the innocent), does a number of
things, but it's functionality wasn't quite "complete" enough for my
application, so I extended it to add a couple more features. No
problem, until I started having this really weird error about an
invalid method return type for a private method that I didn't even know
existed.
After a quick dump of the 'variables' scope, I
discovered the problem was nothing more than a variable
collision. One of the instance variable from the encrypted CFC
happened to be the same as what I wanted to call one of the methods I
was adding. Needless to say, I was a little bothered by this; now
my method wouldn't be able to conform to same naming conventions as the
rest of the CFC's methods. However, being the [relatively] mature
adult that I am, I quickly got over it, did a quick search and replace, and went on with my business.
The reason I'm writing is that I want to restate the point that you should never put anything
directly into the 'variables' scope in a CFC except public data fields
that are clearly documented with CFPROPERTY. Instance variables
should always go into a substruct (I prefer 'my', but 'instance' seems
to be a more common name), both to keep them nicely packaged, and to
avoid this kind of variable collision. This is particularly
important if you're going to be distributing your CFCs for other
developers to use and possibly extend.
I just wrote a script that would check for orphaned files in an
uploads directory. Orphan meaning the file still exists, but the
database doesn't have record of it. Those files needed to either
be reclaimed or deleted, but finding them is cumbersome (and slow!)
process.
What I discovered is that CFDIRECTORY ACTION="list" is really slow if you just need a list of filenames without any of the extra metadata. Using the list() method of the java.io.File
class turned out to be more than a order of magnitude faster. The
one caveat is that you can't do a filter without writing some Java (an
implementation of java.io.FileFilter or java.io.FilenameFilter). But for the performance gain, it's hard to beat.
Here's the CFML code:
<cfdirectory action="list" directory="#LOCAL_DIRECTORY#" name="files" />
And here's the Java code:
<cfset fileList = createObject("java", "java.util.Arrays").asList(
createObject("java", "java.io.File").init(LOCAL_DIRECTORY).list()
) />
With the Java, you get an instance of java.util.List, which can be treated just like a normal CF array.
Before I start, how many of you loyal readers out there use or have used PasswordSafe? If you would, leave me a comment, because I'm curious.
Anyway,
I just got an email from a PasswordSafe user that said it was
connecting to the internet every time he saved his data file. I'm
not a devious type, and the codebase has been checked over by at least
two or three other people (quite possibly many more), and one even took
the time to rewrite some chunks of it to be more efficient and look
prettier. So I'm quite confident that there isn't any malicious
code lurking around anywhere.
However,
his comments concerned me, because that's some blatantly suspicious
behaviour for security-related software to be exhibiting. One
common use for PasswordSafe (from talking to various users) is to store
the data file at a shared location (and possibly even the actual
binaries), where all parties that need access can get it without having
to keep files synchronized in multiple places. I suspect this is
what's happening, but I wanted to ask if anyone else has seen this sort
of behaviour?
I've also just pushed a new update that has no
functional changes, just a couple little tweaks to the
documentation. It can be downloaded at http://www.barneyb.com/go/ps_download.
Follow Up:
After doing some more testing (both myself and the guy who sent me the
email), it appears to be the XML-based bean serializer that
PasswordSafe uses that is causing the internet lookup. Presumably
this is to find a remote XML Schema or something.
Spike sent me this link to www.yubnub.org,
which endeavors to be a "command line for the web", as they put
it. It's a pretty cool idea, really. You create commands
that are implemented with web services, and then anyone can run your
commands via the shell. Not sure if it has any real application,
but it's definitely an interesting use of web-base technologies.
So I just set up a CF7 server a week or two
ago and started moving one of my apps over to it. We use the
CF6.1 DevNet edition on our dev servers, and it's great. I
figured I'd do the same with CF7. All going along great until I
start testing our admin area, which relies heavily on JS remoting, and
that damned DevNet META tag completely breaks it.
On
CF6.1, you could just use CFCONTENT to set the content type to
something, and the META tag would magically vanish. But on CF7,
it appears to be impossible to make the META tag disappear.
Ordinarily, I wouldn't care too much, except that it completely breaks my application
(not to mention prevents doctype sniffing from working
correctly). So after screwing around for what seemed like
forever, I finally gave
up, archived my settings (my god is that cumbersome), undeployed CF,
generated some developer-edition WARs, deployed those, and restored my
settings. Fortunately, I can get by with the IP restrictions.
Things seem to be all good
now, but man was that not how I wanted to spend my Saturday night. I
know DevNet is going away and all, but you'd think they'd at least make
it usable if they took the effort to release a DevNet edition of CF7.
