Gemify

[OriPekelman]

I added a small ruby class / command line tool to generate the images from a template. It can output a parametrized SVG, or any format (gif/png/jpg) etc..

If you want an "API" it is now trivial todo, but I would image main use cas would be to generate static images from this..

[krainboltgreene]

A more concise version of this would be:

# See http://help.github.com/ignore-files/ for more about ignoring files.
#
# If you find yourself ignoring temporary files generated by your text editor
# or operating system, you probably want to add a global ignore instead:
#   git config --global core.excludesfile ~/.gitignore

# Ignore all of the generated gem stuff
/pkg
/*.gem

# Ignore bundler config
/.bundle
/Gemfile.lock

# Ignore all bundler caching
/vendor/cache
/vendor/ruby

# Ignore all tempfiles
/tmp

# Ignores that should be in the global gitignore
/coverage
/doc

Based off the Rails template gitignore.

[chadwhitacre]

@OriPekelman Thanks for your work on this!

If you want an "API" ...

Actually, we already have an API, at http://shields.io/ (see #15). :-)

The CLI we currently use is:

https://github.com/cainus/shielded

We have a ticket (#47) to move to another one, for performance reasons:

https://github.com/jbowes/buckler

At first glance, the main advantage of your version seems to be that it outputs to GIF and JPG in addition to PNG, yes? Since your version is written in Ruby, it might be useful if we ever decide to rewrite the API server in Ruby (it's currently in Python). Even then, I expect your version isn't faster than the Go version (buckler). Are there other advantages you'd like to draw our attention to?

I propose that what makes sense here is for you to host your version in your own repo. I'd have no problem linking to different language implementations of Shields badges, though of course @olivierlacan has the final say.

[olivierlacan]

Fully agree. I love Ruby but we need the fastest possible implementation so vendors can rely on us instead of taking on that responsibility themselves. 

I still think it's great to have multilingual implementations as Chad said because it can provide great example for people looking to build similar services. And it can also be very useful as inspiration to improve the API overall. :-)

On Tue, Nov 12, 2013 at 10:07 AM, Chad Whitacre notifications@github.com
wrote:

@OriPekelman Thanks for your work on this!

If you want an "API" ...
Actually, we already have an API, at http://shields.io/ (see #15). :-)
The CLI we currently use is:
https://github.com/cainus/shielded
We have a ticket (#47) to move to another one, for performance reasons:
https://github.com/jbowes/buckler
At first glance, the main advantage of your version seems to be that it outputs to GIF and JPG in addition to PNG, yes? Since your version is written in Ruby, it might be useful if we ever decide to rewrite the API server in Ruby (it's currently in Python). Even then, I expect your version isn't faster than the Go version (buckler). Are there other advantages you'd like to draw our attention to?

I propose that what makes sense here is for you to host your version in your own repo. I'd have no problem linking to different language implementations of Shields badges, though of course @olivierlacan has the final say.

Reply to this email directly or view it on GitHub:
#77 (comment)

[OriPekelman]

Yo, I was just so lazy I implemented the thing instead of looking if it was already implemented.

With the Ruby and the ImageMagick and what not, this is not going to be faster then the Go version. Though I have a hard time understadning why this would matter. This seems like a very, very cacheable thing. Will have a look at the other implementations to see if I can do some real contribution.

Anyway I wanted to have this in Ruby anyway for this thing: http://oripekelman.github.io/aaar/ (I will want to have more complex badges with squirrels and kittens at a point, so I want to do the generation on my side).

[OriPekelman]

Opening a separte issue to discuss implementation

[chadwhitacre]

Thanks for being a good sport, @OriPekelman. :-)