Derpibooru is an image booru (sharing/commenting/voting system) specifically aimed at fans of the show My Little Pony: Friendship is Magic. If you haven't watched it, don't knock it till you've tried it.
We wrote the software for Derpibooru from scratch with a view to making a really good web application for sharing images. We hope you like it, and welcome any feedback you may have.
It's not meant to replace or supplant any other boorus for the MLP:FiM fandom, but merely to provide another - hopefully useful - avenue of sharing for the fandom. Because sharing is magic.
There's loads of great pony sites out there. Here's a few you might like if you're a fan of Derpibooru, in no particular order:
- Equestria Daily - News, fanfiction, fan-art and community
- Derpy Hooves News - News and community coverage
- Ponyleaks - News, new episode coverage
- FIMFiction - MLP fan-fiction archive
- Ponychan - 4chan-style discussion boards, mostly SFW
- FiMchan - 4chan-style discussion boards, mostly NSFW
- Bronibooru - Danbooru-style image board
- Twenty Percent Cooler - Danbooru-style image board
Derpibooru was created mostly as a fun little project - imageboards present some interesting scalability problems and are quite interesting. The software running the site is a custom web application written in Ruby on Rails using MongoDB for persistence and Redis for caching. Nearly all other imagebooru software has scalability issues, which are worked around with excessive caching, offline data and site updates, and throwing hardware at the problem, not to mention massively complex database queries which are hard to maintain or improve. Derpibooru (and the underlying booru-on-rails project) is fast, lean, and designed to scale cleanly using datastore and cache sharding and replication, combined with background processing of intensive operations like image processing (using Resque).
We're not trying to do as many things as some implementations try to do, we're trying to keep our features quite broad and generally applicable - our tag implementation, for instance, powers filtering, as well as watchlists, and is also the backbone of the search implementation. Danbooru has about 35 distinct database models (and some of those models contain a gigantic amount of code); we have 6 very lean models. Few multipurpose features beats many narrowly targeted features hands down, every time. Keep it simple, stupid.
We are currently hosting the site from a dual Xeon E5606 system with 24GB of RAM and 120GB of very snappy solid-state disk space in RAID1. We use nginx as our web server, and the unicorn application server. This stack is proxied behind a varnish server that handles HTTP caching using a memory storage backend for speed. Images are stored on an independent file server in a GlusterFS distributed filesystem store; this file server has 16GB of RAM and 2TB of disks in RAID1.
For developers, we've got fully automated test suites that are constantly being iterated on to cover more and more of the site, with the goal being 100% coverage of functionality for integration tests. We also have automated unit tests for some of the core model behaviour like tag/image interactions. Cucumber and RSpec are the tools we use for this.
We basically worked out what we wanted from our booru software, what we did and didn't like about current implementations, and wrote our perfect imageboard. We're constantly iterating and improving on it, and it's still early days - but we think it's worth sharing. The intention at the end of all this is to have a solid, Ruby on Rails based image board which is lightweight, easily maintained and improved, and open source, with scalability into the hundreds of thousands of images out of the box on commodity hardware.
Scalability and our grand experiment
The issue with most image boards, especially implementations like Shimmie and to an extent Danbooru is that they don't scale well. This is mostly down to the inherent data modelling required by relational database structures to represent the information that these boards provide about images.
Derpibooru and the booru-on-rails project use nonrelational databases, which have advantages like being able to store associated tag IDs of images in a field within the image document, making querying based on IDs a simple WHERE statement instead of some convoluted joins and selects as used in most booru software.
In Shimmie, one of these joins can literally involve as many IDs as there are tagged images for a given tag - so if you've got 100,000 images tagged 'questionable' and want to hide them all you're now dealing with 100,000 rows to solve a simple question like "Should I show or hide this image?". In Derpibooru that question is a trivial $nin operand with MongoDB, querying only two objects with very fast lookups.
In the case of filtering out hidden images we only need to ask for the system-wide hidden images, add those IDs to the IDs we already have (they're embedded in the user object which we already have loaded) for a user's specific hidden images, then we just do a simple query which asks "Find me the most recent N images where the tag_ids field doesn't include any of these tag IDs". This is fast, and remains fast on large datasets.
So, really, what we're doing is trying out a very new way of doing things as an imageboard. This sort of thinking is applied throughout - we have on-the-fly image processing, as well as background processing of optimisation jobs, and tagging and search that aims to avoid many of the problems currently faced by imageboard users to give a much better browsing experience and a much nicer experience for uploaders and metadata maintainers.
Derpibooru uses many open source components and the aim is to have Derpibooru's source code, the booru-on-rails project, publicly available once we've kicked the tyres and run a board with it to iron out the bugs in a controlled environment.
So, the code is not yet available generally, but if you're interested in spending some time working with it, drop into the #derpibooru channel on irc.ponychat.net and we can talk!