Perhaps I've drunk too much of the Unix and Heroku 12-factor kool-aid, but I'm skeptical of the usefulness of some of TrapperKeeper's features:<p>> a way to cohesively manage the lifecycle of the various components making up an application<p>I'd need a more specific example to understand exactly what this is talking about, but shouldn't each component with an independent life cycle be a Unix process?<p>> a common logging mechanism that wouldn't need to be set up and configured by each component<p>Just log to stderr. Don't even bother including timestamps; an external utility like svlogd can do that (and rotate the logs too).<p>> a web server flexible enough to load multiple web apps<p>This one in particular strikes me as an anti-feature, common in JVM environments. In the Heroku 12-factor approach, each app embeds a web server (like Jetty), rather than the web server containing apps. Then you use a front-end proxy like HAProxy or nginx to route requests to multiple apps.<p>> and to support a rich set of options for configuring SSL<p>That's the job of the front-end proxy, or maybe even a special-purpose SSL termination daemon such as stud.
This is very cool, especially that they took the time to write up a series of tutorials for "TrapperKeeper" which is really what the post is announcing: <a href="https://github.com/puppetlabs/trapperkeeper" rel="nofollow">https://github.com/puppetlabs/trapperkeeper</a><p>It looks very quick and easy to spin up a service which has all benefits and performance of running on clojure / jvm. Combining this with a website front end using Clojurescript looks like it could be a sweet spot.
I've been looking at Clojure a lot lately. It's a really cool looking language that appears pretty powerful. As an outsider I'd really like to see some more "ramping up" kind of posts to get my head around all the basics of the tooling (leiningen) and how to actually structure a program.
I've also released an opensource tool called TrapperKeeper which is for storing and displaying SNMP traps. We use it at Dropbox to turn SNMP traps into stateful alerts so that they can be polled by monitoring services. We haven't really announced it publicly because I want to finish writing up docs but it's been public on Github for about a month.<p><a href="https://github.com/dropbox/trapperkeeper" rel="nofollow">https://github.com/dropbox/trapperkeeper</a>
A talk by Rich Hickey (creator of Clojure) about what sets Clojure apart from the usual object oriented languages, concurrency-wise:
<a href="http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey" rel="nofollow">http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...</a>
I've tried Clojure for a while, but it didn't stick. It's probably the whole Lisp specific approach being the reason why Lisp never really took off as a main stream language. I've tried Scala after that and stayed with it since. Besides all the good points, Scala has Typesafe behind it - a solid stack/platform that (to best of my knowledge) Clojure doesn't have.
Because of all the great benefits of centralized accounting of our infrastructure and exported resources we started using PuppetDB when it was in its relative infancy. We did make the mistake early on of using the built in DB backend instead of the Postgres.<p>When I looked at migration strategies there wasn't a real migration tool available. To interact with PuppetDB I ended up learing a bit of clojure and rollng my own tool, the built in REPL helped wonders with this (granted it was only enough to accomplish this task and haven't had a chance to touch Closure since).<p>Only kept getting irritated by the startup time which I don't know if it can be attributed to the JVM, Closure or PuppetDB itself.
Does anyone else see dedication to a single language as a flaw? When I read "X is a Y language company" all I can think is "that company has a long ways to go." I imagine the people or person there, having found their favorite pet language and some political energy, forcing it upon everyone else and I feel angry. I get recruiter emails "looking for a Java developer" and have to ignore them. The companies just don't get it. Language Y is not going to fit all needs and cases except for very, very small problems. A company dedicated to one language is like a Popsicle with dirt all over it.
As a clojure-n00b and a Puppet expert (ahum), this triggered me to do a bit of research and write down my thoughts: <a href="http://www.olindata.com/blog/2014/04/clojure-outsiders-investigation" rel="nofollow">http://www.olindata.com/blog/2014/04/clojure-outsiders-inves...</a>
I'm still trying to figure out how to allocate my attention between Clojure and Scala, and this just rebalanced the situation (I had been leaning toward the latter).<p>I do question their conclusions about OSGi though - it seems like a good fit for their case despite the complexity. Apache Felix is particularly nice to work with.
This is very disappointing.<p>Given how often 0-day vulnerabilities are discovered in the Java ecosystem I can't see how this is a good choice for a critical piece of infrastructure.<p>We love using puppet, but one big issue we have is it's lack of consistency, a big part of that is the fact that theres Puppet, Ruby, ERB syntax and ideologies and now you also have thrown Java in the mix?!<p>When we saw this news several people in our team have already started looking at alternatives.