More information available at http://fangamer.com/blog/rubychallenge
Along with this README (Spec Sheet), this zip file contains three other important files:
The mockup image is there to give you a very brief overview of what we’re hoping to achieve with this simple sprite database (click on the thumbnail to the right to view it full-sized). As the mockup states, we want it to work like this:
- The user clicks on the ‘Change’ button beneath the sprite (or perhaps an ‘Add’ or ‘Delete’ button to add/delete more sprites to the page, if you’re feeling like an overachiever)
- A window pops up (popup.html) with the contents of the Sprite Database
- The user can modify the sprite database from within this popup window (they can add, edit, delete any sprite)
- The user selects a sprite
- The popup window closes
- The user is returned to index.html, where the new sprite (which they just clicked on) has replaced the old one. Neat! Note that index.html needs to know the URL, Title, and ID of the sprite in order to generate the proper html, not just the URL.
Note that I have sprinkled some comments throughout index.html and popup.html. These may prove helpful (or not, if you’ve done development before, in which case you should just email us the address to one of your old projects).
Sprite DB Fields
Not that you need to be told this stuff, but there are a few things we’d like to note about some of the fields:
- ID (obviously)
- Image URL
- Title (plain text)
- Tags (also plain text—the tags don’t have to have any functionality, but if you want to implement an actual tagging system, it will certainly get our attention)
What We’re Looking For in Your Code
- Efficiency (no pointless or unnecessary code)
- Security (user permissions, scrubbed inputs)
- Ruby+Rails concepts (convention over configuration, DRY, MVC, REST, and any other applicable TLAs)
- Small controllers and big models
- Use/understanding of associations (for example, a robust tagging system would have a many:many association between sprites and tags, though that’s not a requirement for this project)
Use Cases (i.e. wtf are we doing this for)
There IS a reason we’re having you guys work on a sprite database—this is a feature that will definitely get implemented into Fangamer’s codebase, although it will have many more features by the time we’re done developing it. The person who presents us with the cleanest and most nicely-coded sprite db will probably be given first dibs on the REAL Sprite DB project.
Anyway, here are a few examples of how we’re planning to use the Sprite DB:- A forum administrator is creating a custom announcement for the header and needs an attention-grabbing sprite. Instead of downloading a sprite archive and looking through each one, she harnesses the mighty power of computer machines and uses the sprite database we’ll provide to her.
- A registered user is choosing a sprite for his avatar. Instead of letting him upload his 3000px x 800px forum signature banner, we’re going to force him to choose from our sprite collection.
- Let’s say that we’re going to put a button on the forum which allows users to insert an EarthBound sprite into their post (kinda like a smiley). Using the sprite database, we’ll be able to easily restrict which sprites are available and easily add/remove new ones in the future.
As you can see, the sprite database doesn’t have to be JUST for video game sprites—we might use it for things like smileys and badges too.
Submit Your Code When You’re Done!
To submit your project, email reidman@starmen.net with a copy of your code. If you can submit a URL with a working copy of your project, that would earn you some awesome points. If you don’t have access to a Ruby+Rails server, but you did the development on your own computer, we’d give you brownie points if you submitted a quick screencast highlighting anything special/different you did with your project.