Improve readability with 100E2R June 15th, 2008
You know those things you stumble upon online, that inspire you to rethink the way you handle an aspect of your work?
I've struck upon one such inspiration nugget in 100E2R, The 100% Easy-2-Read Standard. It's a set of 5 complaints and 5 rules for web publishers. The page on which it's presented also includes an interesting list of referrers and some thought provoking commentary.
It promotes the design choices that I now realize underpin the web content that jumps out at me and inspires me to produce more beautiful applications.
So if you've also been scratching your head and trying to figure out why you can't get "that web 2.0 look" right, even though you're using the Trebuchet MS font and the grid implementation du jour, be sure to feast your mind on The 100% Easy-2-Read Standard.
I recommend reading the comments as well. Both the criticism and affirmation will get you thinking (for yourself). The list of referrers provides some great terrain for exploration.
Model, view or controller? June 14th, 2008
This came up on the rubyonrails-talk mailing list again, and it took me too long to find my answer from last time in the archives, so here it is.
Sometimes it's hard to decide which layer of an MVC application to put code in.
It took me a long time to settle on a simple decision process that works for me, especially in the J2EE environment where it's not as easy to change your mind.
I default to trying to push code down into the model. However, I ask myself these two questions:
- Does this code describe anything other than behavior of this model?
- Does this code know about CGI or HTML?
If the answer to either of those questions is yes, I look more seriously at putting the code in the controller or an helper. If the answer is "yes and no", I'm probably trying to do too much at once, and need to break it up across the layers.
In summary, favor the model, but not at the cost of layering violations.
The attitude that this comes from is that your domain model (your collection of "models") is the system. The controller is only there to mediate a view into it. This attitude works well for the kinds of applications Rails is suited to.
Here are two more considerations:
- Code that you put in the model is easy to use from the Rails console and runner. Code that's in the controller is more of a pain in the arse to get to.
- Model instances can call each others' methods, but they can't call methods on controllers without jumping through hoops.
Say no to ProFTPD January 15th, 2008
It looks like people are still recommending ProFTPD. I wish they wouldn't. This isn't news. It's an opinion I find myself repeating frequently, and now I'll be able to cut'n'paste or provide a URL as appropriate.
Search the National Vulnerability Database for vulnerabilities disclosed against vsftpd and ProFTPD during 2004, 2005 and 2007. You could search all of time, but that would give you a skewed view, because ProFTPD is older than vsftpd, and because you need to allow for software becoming more secure over time.
You'll find 8 vulnerabilities in ProFTPD. One of them is an authentication bypass vulnerability. The rest are stack and buffer overflows that allow denial of service attacks and remote code execution.
You won't find any vulnerabilities for vsftpd.
I used to buy the argument that ProFTPD is more feature rich. But recently, I set up vsftpd for a customer, providing chrooted sessions for virtual users. It was a lot less hassle than it is with ProFTPD.
Interestingly, vsftpd is (at the time of writing) the FTP server software used by kernel.org, the Linux kernel distribution site. From the perspective of a black hat, there aren't many non-commercial sites that would be more useful to break into, so their threat exposure is probably high.
Say no to FTP. If you can't, say no to ProFTPD.
Pinning down Etch backports September 30th, 2007
For a while, I've wanted kde-3.5.7 on my Debian 4.0 (Etch) laptop. It's available in the etch-backports archive from backports.org. But the etch-backports archive contains a lot of other backported packages, and I want to stick to Etch with the exception of KDE.
You may ask why I don't just accept all packages from the etch-backports archive. There are two reasons: stability and security.
With respect to stability, I reckon that the packages in the etch archive have probably been exposed to the largest number of users. Assuming that a wider user base leads to more bug reports and fixes, these packages would be the most stable. That assumption doesn't always hold, but it's a good generalisation, as generalisation's go.
An enormous amount of effort goes into producing a stable Debian release, and I want to maximise my leverage of that effort. As I become more of a manager, my interest in a bleeding edge laptop wanes.
As for security, the Debian Security Team FAQ suggests that the testing archive can receive security updates less frequently than the etch archive. Since the general backports.org policy is to backport only from the testing archive, I figure I'd wait longer for security updates from the etch-backports archive.
So for the most part, I want packages from the etch archive. For KDE, a suite of hundreds of packages, I want what's in the etch-backports archive.
The solution, as presented by the instructions at backports.org, is to use APT preferences to pin specific packages to the etch-backports archive. Unfortunately, the format of the APT preferences file requires that you pin every single package of the KDE suite. With a full KDE installation comprising over 200 packages.
This seemed like it would be a lot of work, especially since I couldn't find the list of packages for the KDE suite in a single list. Rather, I'd have to navigate an extensive dependency tree, ignoring dependencies that aren't part of the KDE suite.
However, I noticed that all the packages from the KDE suite contain the same text in their long descriptions:
This package is part of KDE
How fortunate. Especially since the dctrl-tools package provides a way to search for packages matching against any header in the package control file.
So after following the instructions at backports.org to add the etch-backports archive to my APT sources and update my package index files from their sources, here's what I did to tell APT to accept KDE packages, but nothing else, from etch-backports:
aptitude install dctrl-tools
grep-aptavail -ns Package -F Description \
"This package is part of KDE" | sort | \
for pkg in `cat`; do
echo
echo Package: $pkg
echo Pin: release a=etch-backports
echo Pin-Priority: 999
done >> /etc/apt/preferences
aptitude dist-upgrade
The grep-aptavail options instruct it to print out the value of the Package header (but not the name of the header) for all packages available to APT with a Description header that contains "This package is part of KDE". In short, it prints a list of all packages in the KDE suite. The output is then sorted, transformed into a set of APT preference records, and appended to the APT preferences.
Now I can rest assured that any packages I install from the KDE suite will be installed from the etch-backports archive, but other packages available in etch-backports will not be installed unless I deliberately pin them too.
The same approach works for OpenOffice.org. In fact, it's likely to work for any suite of software where the package maintainers have done something sensible with the package descriptions. All packages in the OpenOffice.org suite contain this text in their descriptions:
OpenOffice.org is a full-featured office productivity suite
Now you can have the toys that the cool kids have, without being cool.
Aptana takes over RadRails development March 11th, 2007
For those of you who've been alarmed by the apparent stalling of the RadRails project, there is hope. I don't usually post news items, but I haven't seen any English coverage of this at RubyCorner, and I know some of you have been worrying that your favourite Ruby and/or Rails IDE is abandonware.
Fear not! Aptana is taking over development of RadRails, after Kyle Shank recently announced that he and his business partner just don't have time for it right now.
For details, see Kyle Shank's announcement, which includes links to a CRN article on how the deal came together and a discussion forum at Aptana's site.
The fundamental flaw in PC security March 8th, 2007
Heard in the antispam community (and reproduced with permission):
The fundamental flaw in the idea of DRM is that it's not possible to simultaneously show something to someone, and not show it to them.
Is the fundamental flaw in PC security that it's not possible to simultaneously allow users to execute arbitrary code (or make arbitrary network connections, or whatever) and not allow them to?
Huey Callison
Astute, I thought. I've known for ages that the RIAA is ripped off repeatedly by crackpots who claim to have the final ultimate solution to digital rights management, because of this problem. But it had never occurred to me that PC security is the same class of problem.
Until users can't execute arbitrary code on their own personal computers, the security of those computers is a measures / counter-measures game at best.
This is worth bringing up next time someone in the board room laughs at you for suggesting you deliver application functionality via the web.
Surviving the expat upgrade on Gentoo February 28th, 2007
Moving to ~x86 on Gentoo Linux requires an upgrade to dev-libs/expat-2.0.0 from dev-libs/expat-1.95.8.
Unfortunately, the expat maintainers broke its ABI between 1.95.8 and 2.0.0 without bumping the library version number. This means the Gentoo ebuild maintainer can't easily slot the versions for happy coexistence.
Whether you've already upgraded dev-libs/expat and are now stuck, or you're still using a version earlier than 2.0.0 and are about to upgrade, this will get you over the hump:
cd /usr/lib emerge -1 '<expat-2' cp libexpat.so.1.5.0 libexpat-1.95.x.so.1.5.0 emerge -1 '>=expat-2' ln -fs libexpat-1.95.x.so.1.5.0 libexpat.so.0
Then, one day when your initial ~x86 upgrade is complete, you can go back and remove libexpat-1.95.x.so.1.5.0 and libexpat.so.0 from /usr/lib once you've used revdep-rebuild --library=libexpat.so.0 -pv to verify that the pre-release library has no remaining dependencies.
You can't have the spam you don't pay for February 27th, 2007
Love him or hate him, John Levine sure knows how to illustrate a point.
Recently, John was participating in a conversation in which someone asserted that if a recipient wants to receive all the spam sent her way, her email provider should allow for that.
Here's John's response, which beautifully nails down the overwhelming influence of cost on email providers' spam filtering policies:
Hi. I belong to a club of people who are trying to prove the existence of God by finding patterns in random data. To do this we need to mail around 100GB files of white noise. They never show up, and when I call my ISP to complain, all I get is gobbledygook about limits to attached sighs or something like that.
If I'm paying for the account, they should be allowing it thru.
Sure, baby, as long as you don't birth a cow when you receive your next bill.