This challenge seems a bit over the top. The task is to write a fully functional service for creating a photo mosaic service that accesses third party apis for sourcing the photos. Constraints are that you are not allowed to use any libs from outside the include standard library (though you are expected to write tests using some tool the challenge author is apparently trying to push)... The whole things has to be deployed and publicly accessible.
Seems like quite a bit of work for the chance of winning a bunch of ebooks.
No, the Go standard library really does have everything you need to do all this. The only thing that makes me go "Really?" is the actual process of generating the photo mosaic, but that's just because despite appearances that's actually a substantial challenge no matter what library support you have (barring one custom designed for this use case). Technically, yes, the Go library has what you need to do that, but you'll be writing an awful lot of image processing code on your own to get even "good" results.
I also find it amusing that you are "banned" from "ghosting" (putting a faint copy of the image below the mosaic), as that would actually require additional code to implement, and, again, even more so to do well...
Everything else is definitely present out-of-the-box. This is a absurdly large task for a "challenge", IMHO, but it's all perfectly doable out-of-the-box.
If you make the pictures really small relative to the mosiac, to the point that pictures are very nearly just pixels, yes, that works.
However, the next time you see a professionally-done photomosaic, take a moment and really look at it. Especially look at the sharp lines of contrast in the original image. If the mosaic draws from a large source of images, you'll find that you can follow the line through the source images themselves, not just between images. For instance, if you've got a sharp horizontal beige/blue line, you will find that the algorithm will pick up an image of a sunny desert day or something where the line for the horizon is approximately correct.
To do a quality job requires at least edge detection and some fuzzy matching of the primary edges of images, which also means you need to break the image down into more than just averages, you need to be counting the colors of segments of the images.
Nothing impossible about this, of course, it's just that it's an awful lot of work for a challenge like this, considering the stakes.
I am probably missing something, but I would think that treating each sub-image as its own grid would be more than enough for a decent mosaic generator. It seems to me you would get your edge detection for free this way. I just don't think it would be hard, but, again, I haven't done it myself so I'm sure there are surprises within.
It's quite easy to write webapps using Go's std lib. The rules allow for 3rd party database drivers. It's also easy to deploy to something like GAE or an amazon micro instance.
> Seems like quite a bit of work
That's why it's called a challenge.
I think the last challenge sounded more difficult because the problem was much more unique.
This challenge is more practical because you will be doing very common things like consuming REST APIs, writing HTTP handlers, routing, templating, optional database, etc. Most of this is doable by importing net/http and html/template and reading some basic tutorials [1].
As a comparison though, the first 2 challenges took about 200~300 lines of code. This challenge looks like more then 2000~3000. It literally is asking for enough that it made me say "Screw that, I'd rather work on my own projects" rather then "Hey, that looks like it'd be interesting". I could see a photo-mosaic challenge by itself, without all the cruft of logins and such, but this seems like massive feature creep compared to previous challenges.
Edit: Oh, and on top of all that, it's supposed to be deployed on a server... Seriously, screw that, I'm not paying hosting costs for a crappy contest like this.
That's a little strong, it says: "You need to write test cases for the main flow. Do submit your test case file. You can use a useful tool goconvey - use its UI without using their DSL. GoConvey supports Go's native testing package." (My emphasis).
It is odd to demand only using the standard lib, and at the same time call out a tool as a replacement(?)/augmentation to "go test" -- but the challenge also mentions other external services and tools.
Note that they specifically say not to use the goconvey DSL, ie. just use *testing.T. goconvey without it's DSL is just an automated FS watcher and test runner with coverage reports.
This seems more like creating an entire service from start-to-finish rather than an exercise on learning a language. I appreciate the authors are likely trying to do this because the exercise touches on so many different areas, but personally I'd be put off by this, when learning it's always more enticing to go for bite-size challenges, so you can see progress easier and create milestones/goals.
Seems like quite a bit of work for the chance of winning a bunch of ebooks.