Previously, it would pop-up a box for you to type in some keywords. Then it would search Snipplr and show you a list of matching snippets you could insert into your document. That worked pretty well, but you had to be online for it to communicate with Snipplr. You’d lose access to your snippets if you weren’t connected to the net.

This new version syncs your snippets and favorites directly into TextMate’s bundle menu – giving you offline access to all your code stored in Snipplr. If you don’t mind me saying so, this rocks. Here’s a screen shot:

Keep in mind that this bundle is still in development. Everything is working fine for me, but your mileage may vary. You can download the new bundle here. Note: You must be logged in to Snipplr for the download to work. Also, make sure you uninstall the old bundle from TextMate before installing this one.

For the nerds in the audience…

This bundle was a lot of fun to write because it forced me to dig into TextMate’s bundle format. I’ve written some advanced bundles before (at least I consider them to be . . . at work we use a bundle that lets us stage and deploy our clients’ websites on remote servers via TextMate) but nothing like this.

When you download the bundle from Snipplr, PHP generates a custom bundle on the fly based on the snippets in your account. It creates all the .tmSnippet and .tmCommand files as well as the OS X property listings. It’s by no means brain surgery, but it definitely took some tinkering to make it come out right.

The bundle also includes a command to refresh itself. It does this by downloading a new bundle in the background and rsync’ing it with the pristine copy stored in TextMate. I consider this a cheap hack – I’m hoping TextMate 2.0 provides an official API for bundles to self-update. (Ideally, each bundle .plist would contain a URL and version number that TextMate could use to search for updates and, if available, update the bundle à la Firefox extensions. You there, Allan? ) It tells TextMate to update its bundle listing using a quick AppleScript command (osascript -e 'tell app "TextMate" to reload bundles').

There’s probably a better way to do all this – I need to search the TextMate mailing list.

Next up, I’m going to try and register the update command with launchd so the bundle can stay in sync automatically – preferably when TextMate isn’t active.

I’d appreciate any feedback from the Snipplr community on this bundle. Bugs and feature requests are always welcome.

Also, if anyone is interested in beta testing the new version of Snipplr we’re working on, let me know.

Snipplr is just ripe for spammers. Think about it. We allow anyone to create an account – no email validation required. Then, we let people post snippets which automatically appear on the front page along with any text they enter.

So how do we prevent spam from becoming a problem?

The obvious answer, and one that I don’t want to implement is to force users to register with a valid email address. Email addresses are a dime a dozen now. You can create a fake email address just for Snipplr with any number of online services. In fact, looking through the current list of users, I can see that about 40% are using fake email addresses. Forcing them to use a real one accomplishes nothing other than annoying the users and creating another barrier they have to get past before using this website.

The next option is to use a captcha every time someone posts a new snippet. (You know, one of those boxes with curvy letters that you have to decipher to proove you’re human.) This would help stop spam, but it would become tedious for people who post a lot.

Snipplr is closely modeled after del.icio.us. That said, I’m leaning towards the method they and other social bookmarking sites use: let the users report spammy snippets. A small “report this” link could be added next to each snippet. If a snippet gets enough spam votes, the system can automatically remove it from the site and place it in a holding queue until it can be manually reviewed by a moderator.

Another similar option is to prevent new users’ snippets from appearing on the front page until they’ve been verified. While tedious for the admins, it’s better than forcing the user to jump through email and captcha hoops.

Any Snipplr users have suggestions? Post them in the comments below.

• Reusable code
• Programming brains
• Programmer’s brains
• Give your brain a rest

I’m not very fond of any of them. I asked the guys at the office what I should do. They suggested

• Take a snippet, leave a snippet
• Share and share alike
• Code and code alike
• The website that Jon wanted
• We don’t need no steenkin E’s!
• Your code sucks. Use mine.

Again, none of them are winners. I’m sure something will come to me while I’m taking a shower. That’s where most of my good ideas appear.

Switching gears, you’ve probably also noticed that Snipplr doesn’t have a logo. In fact, other than the title bar, I don’t even mention the name of the website. This lack of branding was somewhat intentional. I originally built Snipplr as a tool for myself, so I didn’t give any thought to allowing for a logo in the layout. I wanted the design to be functional.

The obvious solution is to drop the nav bar down a bit and stick a logo (or at least the site’s name) in the top left corner. A more avant garde route would be to keep things as is – no branding. It’s a bold move, but it might be a clever way to distinguish Snipplr from other websites. It reminds me of how for the longest time 60 Minutes was the only TV show without a theme song. The point? They were so good they didn’t need a damn song. That simple, ticking stop-watch was enough.