Socko 2.0.0 has officially landed. After some weeks of development and production testing it is time to give 2.0.0 a go. And with this release, the main Socko-package isn’t alone anymore. It has become a platform and consists of packages like js-hierarchy: The main tree wrangler file-hierarchy: A js-hierarchy implementation for the file system socko-converter-file:
So I recently dived into container schedulers (like Kubernetes, DC/OS (Mesos) or Docker Swarm Mode). You know, all the stuff the cool kids talk about. And truth be told, I really liked the ephemeral nature of it all – and using things like Terraform really makes setup a breeze (once you leaped over the „fundamentals“ learning curve).
If you haven’t noticed: I already published a plugin for the IntelliJ platform of IDEs by Jetbrains. Developing for the IntelliJ platform is sometimes a bit hard, because I’m used to have a API-documentation for reference, but somehow Jetbrains didn’t provide one for the platform. Looking at their sources over at github, I found, that
You probably know these times, where you look at an old project (even if it’s just a year old) and get the urge for refactoring – or even rewriting. Socko is such a project. Socko was crafted together in a short time, refactored to at least make it a bit more manageable and released. Now,
Jetbrains Teamcity is a brilliant continuous integration and deployment platform. Being a modern platform, it also provides a REST api. But sadly, the API documentation is, well… something. But it seems, as if Jetbrains is getting there. There’s an undocumented endpoint in the API, that provides a swagger API description file. So, until Jetbrains hosts
I’m responsible for taking out the trash. Yes, this is a cliché, I admit it. But it is like it is. The problem with that isn’t the trash itself, but rather that I’m really bad with remembering dates. But luckily, my home town’s disposal company offers an iCal download of the pickup dates on their website.
…or: How I made Puppetdev. I don’t like making things twice. You could call that „innovative“ or „efficient“. Basically, it’s just laziness. For Puppetdev, which is built using Packer, I needed base images, so I wouldn’t have to cope with ISO urls, kickstart files and such. Luckily, the wonderful guys at boxcutter provide Packer templates
We’re using Puppet to automate many tasks and – together with other components – allow continuous delivery. However, testing puppet manifests, Hiera settings and installing puppet modules can be tedious – especially when you want to test on a clean system each time. Announcing „puppetdev“, a Vagrant box for easily doing those things: Install puppet modules
I’m currently working on a project for a customer involving several parts for Zimbra (well, whaddya know?) – one is a server extension. And I’d like to have the features, Maven brings in my workflow. The problem is, that Zimbra isn’t really made to be used in Maven. The components you need to create server