Codebrawl

Content-aware image cropping with ChunkyPNG

2011-11-14T13:32:16+00:00

Are you ready for another ChunkyPNG brawl? This week, the challenge is to build a cropping tool that knows which parts to cut off by looking at the contents of the image and deciding what the point of interest is.

Here are the three images we’ll use. A cat, a dog and some ducks. You’ll have to crop all three of them and the resulting images should be 100 by 100 pixels. Your solution should use ChunkyPNG, but of course you can use additional gems if you think you’ll need them.

How you solve this is entirely up to you, but solutions that need human input or are built only to support these images will get disqualified. Please be creative.

When you’re done, throw your implementation, a README and all three resulting images (please don’t include the input images) in a Gist. You can’t add images in the Gist web interface, so you’ll have to clone your Gist and add your output image using plain git. If you don’t know how, just send me a message and I’ll help you out.

You have one week to get your entry in, but we’ll add more time if necessary. I can’t wait to see how you solve this one. Good luck!

Prize

This week’s winner gets one month of free Github Micro!

RSpec formatters 2

2011-10-24T12:19:39+00:00

Our very first contest challenged the contestants to create new formatters for the RSpec testing library. After it closed, I received a lot of comments from people that missed the contest but would have loved to participate.

We decided to do it again. The rules are the same as last time:

This week, the challenge is to create your own formatter for RSpec 2. Your solution should solve a problem you’re facing with the existing formatters (like, I don’t know how long my specs are going to take or I don’t notice when my suite is done running) or you can do something completely crazy and funny. With rainbows, or something like that. Oh, and remember: You’re not limited to terminal output, do whatever you can think of.

A good starting point would be to check out the existing formatters. Also, don’t forget to take a look at the entries in the previous RSpec formatters contest.

As always, when you’re done, put your solution in a Gist, including a README file to explain what it does, how it works and why it should win. Of course, you’re encouraged to put a link to a demo video of your formatter in action in your Gist too.

Prize

This week’s winner gets to choose between $25 of 6sync hosting credit or one month of free Github Micro!

Methods taking multiple blocks

2011-10-10T09:51:27+00:00

Ruby makes it trivial to pass a block of code into our method calls. But what do we do when a method needs two blocks of code or more? For example, a method might want some code to run if an action succeeds and different code to run if it fails.

What would it look like to pass multiple blocks in? How would the method access the blocks it wants for each task? Do we need to worry about making sure passing too many or unexpected blocks are errors?

Let’s make use of Ruby’s ability to modify itself as needed to address this problem. Code up some system for the above that’s superior to passing a Hash full of Proc objects. Throw that code in a Gist and send it in as a solution.

Prize

This week’s winner will receive a copy of James’ Best of Ruby Quiz, a collection of highlights from the first year of Ruby Quiz challenges, sponsored by the Pragmatic Programmers.

Command line TODO lists

2011-09-26T12:49:52+00:00

How many times did you try to use apps to write down your TODOs just to find that they are either slow or too complex for this simple task ? This week, I challenge you to write a simple but useful command line TODO app, implemented in Ruby and small enough to fit in a Gist.

As minimum requirements it should allow users to create, destroy and list their TODOs. You can add a ton of features to improve the app – seriously, I’d love to see what you can come up with – but remember, usability is the main objective.

Please put your entry in a Gist with a README including a brief description of the features and some examples of how it can be used. Of course, don’t be afraid to explain why your solution should win.

You have a whole week to work on your solution, so what are you waiting for? Have fun!

Prize

This week’s winner gets to choose between $25 of 6sync hosting credit or one month of free Github Micro!

Selective color with ChunkyPNG

2011-09-12T13:57:13+00:00

Remember our last ChunkyPNG contest? We had a lot of entries, a lot of fun and a bunch of emails asking us to do it again, so here’s another one!

You’ve probably seen images with the selective color effect before, where the image is in black and white but there’s some element in there that’s colored. Some camera’s have this built in, but most are post-processed color pictures.

We’re not going to use fancy camera’s or expensive photo editing tools. We’re programmers, so we should be able to build a tool that does this for us.

Here’s the image we’ll be working with. Choose one color – bonus points if you choose the yellow or one of the blue ones – and create a black and white image with only one of the crayons in color using ChunkyPNG.

Remember, the crayons have a range of colors, they’re not just yellow, for example. It might be a good idea to check out some other color scheme than plain old RGB to support that.

Please put your entry in a Gist with the resulting image, like this example. Please don’t include the input image and don’t fork the example Gist. You can’t add images in the Gist web interface, so you’ll have to clone your Gist and add yout output image using git. If you don’t know how, just send me a message and I’ll help you out.

You have one week to get your entry in, so I’m sure you can make something awesome! Good luck!

Prize

This week’s winner can choose between $25 of 6sync hosting credit or one month of free Github Micro!

Key/value stores

2011-08-29T13:14:29+00:00

This week, the challenge is to write the best key/value storage backend you can think of. It has to be persistent and the goal is for it to be capable of SET, GET, KEYS and DELETE operations, but it’s okay if you don’t have time to implement all of them. We prefer great code over lots of code.

You may implement it as a web service, CLI, Arduino serial adapter… You choose your environment. In the end, I think it would be funny to see lots of funky solutions.

To submit an entry, just put your work in a Gist and include a README to explain what it does and how it works (with code samples!). You have one week to enter, so good luck and have fun!

Prize

Once again, 6sync is offering $25 worth of credit for their hosting platform to this week’s winner!

Whyday 2011

2011-08-19T18:40:10+00:00

Happy Whyday! We’re doing a last minute contest that will end next Monday. This weekend, put your best practices away and celebrate Why’s contributions to our unique culture. Create something wonderful. If you’re still looking for something to build, check out some of the example ideas on the Whyday website.

Go wild! Put your work in a Gist and include a README explaining what it does and how it works. Again, you only have until Monday, so get started as soon as you can!

Happy hacking!

Prize

This week’s winner will receive a code for $25 worth of credit for the 6sync hosting platform!

Ruby diffs

2011-08-15T11:02:28+00:00

Diffs are a great way to inspect changes to files or send them around, but have you ever wondered how they work?

This week’s challenge is to create a diff tool in Ruby. Your tool has to be able to find the difference in two strings and output a diff string from them. You should be able to apply this diff to another string too. Your diff doesn’t have to be human readable – we prefer it to be tiny –, but it would be awesome if it is. Don’t worry if your diff is a bit bigger than what your system’s diff tool produces, a tool like this can become pretty complicated very fast.

Of course, you can’t use any of the diff tools already on your system and your entry should be small enough to fit in a Gist. Also, don’t forget to include a README, explaining exactly how your tool works (with code examples).

Remember, it’s a change too if you move a line around in a multiline string, for example. Be sure your tool understands things like that and also include examples of those edge cases in your README.

As always, you have one week to get your entry in, so that should be enough to build something amazing. Good luck!

Prize

This week’s winner will receive a code for $25 worth of credit for the 6sync hosting platform!

Tools for Travis

2011-08-01T13:30:16+00:00

Travis is an open source and distributed build system for the community. They’re doing continuous integration a lot of great open source projects, including Ruby on Rails recently. Since there’s a bunch of great data in there, this week’s challenge is to do something great with Travis.

You can build anything you like, from CI monitors to command line interfaces showing you data from your projects. You’re probably going to need to fetch data from Travis, so be sure to check out the API documentation. We’ll keep this one open-ended, since the goal is to help the Travis team out a bit. If you’re building a web interface, be sure to use something small, like Sinatra. Remember, your entry should fit into a gist. If you run into any issues along the way, just hop into #travis on Freenode and the team will be happy to help you out.

Remember to keep your entry small, write nice code and include a README explaining what your project does, which problem it solves and how it works. If you’re building a web interface, be sure to include screenshots in there.

We’re still working on a special prize for this week, so you’ll have to wait for some more to get to know what it is.

As always, you have one week to enter, so go build something awesome. Good luck!

Prize

This week’s winner will receive a code for $25 worth of credit for the 6sync hosting platform!

Oh, and this contest description was written by Jeff Kreeftmeijer, on behalf of Sven.

Terminal admin

Codebrawl doesn’t have a proper admin panel, so I tend to do content changes in the database directly using script/rails console. This gives me a lot of freedom, since I can do anything without having to build features for it in my admin panel first. Also, if Codebrawl had an admin panel, I’m absolutely sure I would have to dive into the console to do stuff every once in a while.

Of course, there are some problems with the console when trying to quickly edit a record. Finding the right one requires you to type a query:

c = Contest.first(:conditions => {:name => 'Terminal Admin'})

Also, editing a field requires you to fill in the whole value every time:

c.update_attribute(:description => 'Codebrawl doesn't have a proper...')

The challenge for this week is to think of something that makes this easier and faster. Tackle one problem (like finding records, for example) the best you can, but don’t try to build a complete terminal admin. The idea is to combine good ideas into one project we can keep working on.

Create a solution you can require into the console. It needs to hook into your ORM of choice (Codebrawl uses Mongoid, but you can build something for another ORM if you want), like in this example Gist. Also, don’t forget to add a REAME file explaining how it works.

No shirt, no shoes, no weapons. You have one week to get your entry in. Good luck!

Prize

This week’s winner will receive a code for $25 worth of credit for the 6sync hosting platform!

James: your very own voice commanded servant

This week, we’ll have some fun with MacRuby. James is a “Voice commanded servant for OSX” you can write dialogs for. Here’s a lightning talk by Florian Hanke, James’ creator.

For example, you could set up a time dialog to ask James what time it is:

<< James, what time is it?
>> It is currently 10:15.

Of course, that’s a pretty simple example. This week’s challenge is to write the most useful or fun dialog for James. You can do about anything, like asking James to do API requests, reboot your machine, run your tests, or whatever you can think of. A simple dialog is enough, but please remember to keep the code nice and understandable.

Haven’t used MacRuby before? Just really easy to install using the binary installer. Be sure to check out James’ README and have a look through its example directory to get up and running. If you have any questions, Florian is here to help.

As always, put your solution in a Gist and you have one week to get your entry in. Good luck!

Prize

This week’s winner will receive a code for $15 worth of credit for the 6sync hosting platform!

Ruby testing libraries

There are a lot of Ruby testing libraries out there and you probably use one of them every day, so it’s about time we dive in to see how they work. This week, the challenge is to create your very own testing library.

Your library should be as tiny as possible – it should be a single file –, but it should have one unique feature you’ve been missing while working with other testing libraries. Of course, it should have a great name and a README, explaining how it works (with code examples) and why it’s awesome.

As always, put the whole thing in a Gist. You can turn it into a gem in a full repository after the contest’s voting period is over. You have one week to get your entry in, so be sure to make something awesome. Good luck!

Pixelizing images with ChunkyPNG

Ever heard of ChunkyPNG? It’s an amazing PNG manipulation library that is easy and fun to use. This week’s challenge is to pixelize the image below, so your resulting image is built up from blocks of 10 by 10 pixels. Remember: you can’t change the size of the image.

If you’ve never used ChunkyPNG before, check out the wiki, you can find some great examples in there.

Again, put your solution in a Gist, together with your resulting image, like this example (please don’t include the input image and don’t fork the example gist). You can’t add images using Gist’s web interface, so you’ll have to clone your Gist and add it using git.

Like last week, you have a week to get your entry in, so I’m sure you have enough time to write a great implementation. Good luck!

RSpec formatters

RSpec has a bunch of formatters you can use when running your tests. The default is the “progress” formatter, which prints out a green dot for every spec tat passes and a red “F” for every spec that fails. There are more, like the “documentation” and “html” formatters.

This week, the challenge is to create your own formatter for RSpec 2. Your solution should solve a problem you’re facing with the existing formatters (like, I don’t know how long my specs are going to take or I don’t notice when my suite is done running) or you can do something completely crazy and funny. With rainbows, or something like that. Oh, and remember: You’re not limited to terminal output, do whatever you can think of.

Creating an RSpec formatter is quite straightforward. Be sure to check out the existing formatters, since you’re probably going to extend one of those. For more information, you can check out the Fuubar source.

When you’re done, put your solution in a Gist, including a README.(markdown|textile) file to explain what it does, how it works and why it should win. Of course, you’re encouraged to put a link to a demo video of your formatter in action in your Gist too.

You have a week to enter, so that should be enough to think of something great. Good luck!