Some Go API style nits:

- it's unusual to pass a map with expected keys like this. Normally you'd pass a struct like: p := New(Options{ BaseColor: "...", Color: "...", Generator: "...", })

- You could define the known patterns as constants so they're documented and so users don't have to worry about typos

- Field names are normally camel-case without underscores, e.g., "Base_color" should be "BaseColor"

- You could use Go's build-in image/color package instead of accepting RGB strings, but that's more of a judgement call.

If you're accepting pull requests I might send you some, but they're breaking API changes so it's up to you.

All-in-all though it's a cool project and I'm glad to see it in Go :)

Hi @ImJasonH, I Developed this, let me answer you points :)

I believe these points are not contributing in breaking API :D so lets talk on them first.

2. You mean instead of an array I'm using here [1], We should add them as constants and write separate documentation for each? This sounds nice as it will help obviously like you said.

3. Ohh, I missed this convention, thanks for pointing this out. :)

4. As you said its more of a judgement call, I believe that RGB strings are fine and easy for users. You find any wrong in RGB strings?

So, I'll be very happy to co-operate if you are doing pull request covering points 2 and 3 :) And I'll try to cover your point 1 on my own :)

Cheers \o/

[1] https://github.com/pravj/geo_pattern/blob/master/pattern/pat...

If you're reworking your API, you may want to consider functional options:

http://dave.cheney.net/2014/10/17/functional-options-for-fri...

I haven't attempted it myself, but it looks very interesting.

Another minor nitpick, here [1] you are using reflection. You can pretty easily convert it to a type switch [2], which is more idiomatic.

[1] https://github.com/pravj/geo_pattern/blob/master/svg/svg.go#...

[2] https://golang.org/doc/effective_go.html#type_switch

Regarding 4, I personally tend to be distrustful of what is often described as Stringly Typed code. To me, statically constraining your API to only accept valid inputs seems like superior design.

This is really cool! I quite like the js port https://github.com/btmills/geopattern which you can drop into a website very easily.

This is awesome, thanks for the link.

Please excuse the somewhat off topic and possibly ignorant comment but is importing classes from a URL a feature unique to the Go language?

   import "github.com/pravj/geo_pattern/pattern"

will import from the file system, at $GOPATH/src/github.com/pravj/geo_pattern/pattern/

however, go get will fetch from the URL and install it in said path (it's a mixed blessing)

The [free] Little Go Book [1] makes a special note of it :)

[1] http://openmymind.net/assets/go/go.pdf

no. see http://docs.oracle.com/javase/6/docs/api/java/net/URLClassLo...

> https://guides.github.com/

At first, I thought "create generative background images from a string" meant that the algorithm could be fed any string and it would use that string as a sort of seed for the creation of fractal/geometric art. So I thought that the text overlaying each of the rectangles on the GitHub Guides page was the seed text for the art underneath it. After reading further, I see that assumption is wrong. But I think it's an interesting idea to couple the text on a page with automatically generated geometrically and chromatically pleasing art. I see this sort of organic and causative dynamic as the future of a large part of software development, especially as we enhance our toolset with the power of evolution (e.g., a website that evolves by itself through A/B tests and little human intervention).

I see they have an MIT license, which is great, but I have a theoretical copyright question. If they didn't license out the code and, instead, made a background-image-generating website, who would own the copyright to the computer generated images? I'm guessing they would but does anyone know for sure?

It would probably depend on the background-image-generating websites TOS.

This is not meant to be snarky, but what's the point of this? What use does the pattern being uniquely generated from a SHA of a distinct string have over a random pattern being generated from a SHA of some random string?

Say I'm using this to generate a background image for each post on HN. Also, I want them to be consistent, so everywhere you see a mVChr post it's got a green ringed background.

I could generate a random string for each user, but then I'd have to store it somewhere. It's better to just use the username as the seed.

It's the same fundamental principle behind identicons.

Got it. I can envision the uses for it now. Thanks for the explanation.

Nice idea and implementation. We developed a related application which creates colors from git commit sha strings. Have a look at http://gitart.me/repos/rails/rails

@zorbash Wow, the concept sounds nice :)

nice project, and pretty cool visualizations!

i did port a lot of the xscreensavers to plan9 and then a few of them to go when go came out. this reminds me a lot of some of them. now if only there was a way to animate them!

https://code.google.com/p/goxscr/

they work using x11, mostly on linux :)

This library and the ruby and JS ones are really cool. Does anyone have ideas of other patterns that could be implemented and added to them?

Making this run as a locally-hosted website with net/http would not be a difficult project at all.

Infinite hotel wallpaper.