Archive for the ‘Development’ Category


Preparing For Spam


Published in: Brainstorming, Design, DevelopmentPosted by Tyler on 06/29/06


It’s no longer a matter of what to do if spammers find your websites, it’s what to do when spammers find your website. It’s going to happen.

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.


Happy Accident


Published in: Development, NewsPosted by Tyler on


Well, like I said in an earlier post, the official Snipplr launch was meant to be in the coming weeks, but it got moved up to today. A couple users stubmled upon Snipplr, wrote about it in their blogs, and bam! I wake up this morning to find the official TextMate blog linking to us.

I’m a little freaked out since I wasn’t expecting the traffic to start quite yet. But who am I to complain? I cleaned up a few things on the site, and wrote a very basic bare bones snippet search – so that works for now.

Again, welcome to the site all you TextMate users.


Better Late Than Never


Published in: DevelopmentPosted by Tyler on 06/25/06


I should probably be upfront and admit that I started this blog way too late. I originally had this grand idea to keep a running journal of the entire Snipplr development process. But, seeing how Snipplr is only a few weeks away from launching and this is the first post, that didn’t work out. Better late than never.

The idea for Snipplr came about organically. I wasn’t trying to come up with a great idea or a way to make money, I just realized that I needed a better way to store all the random bits of code I reuse all the time.

In the past I had just kept those code snippets stored in text files on my machine. Invariably, however, they’d get out of date. Plus, it was never easy to find the code I was looking for quickly. The process just didn’t fit into my workflow.

The very first working version of Snipplr was written in six hours late one night in March. The idea for the site solidified for me earlier that day at work, so I knew exactly what I wanted to build as soon as I got home. The website was to be modeled after del.icio.us. Instead of cataloging websites, Snipplr would catalog bits and pieces of code.

All of the major features of Snipplr were present in that initial version. Some were a little rough around the edges, but they worked. Over the next week I cleaned up the code a little, got the website into a stable, working state, and began using it.

For nearly two months I left the source alone. I was too busy at work to worry about developing the site further, and it had integrated into my workflow well enough that I saw no reason to rush back to it. I think this time off was a good thing. It gave me the distance I needed to realize that while Snipplr’s feature set was well thought out the implementation wasn’t. The design wasn’t great, the code was sloppier than I’d like, and I used a little too much javascript.

Fast forward to today. During the last week I’ve picked up development again. I’ve completely reworked the site from the ground up. The layout, while similar, was rebuilt with much cleaner CSS. Knowing in advance my layout requirements helped keep the stylesheet more managable. All of the PHP has been rewritten. The biggest addition has been the use of my custom database object class. It completely automates all of my CRUD code – easily cutting development time in half. (Yes, yes. All you Rails people can pipe down. I don’t care about Ruby.)

Initial reactions to Snipplr have been overwhelmingly positive. (Especially now that the TextMate plugin is working.) I’m happy with the code base and have plenty of ideas for improving things in the future. But, for now I’m focused on getting everything polished and ready for the initial public launch. I expect that to happen in the next few weeks. I’m aiming for July 15th.