Ranting is not my favorite way to express, I’m more like a constructive guy. But also, the blog is a reflection of what I’m doing right now. And for the title of the post you can guess I’m not doing a lot of GIS.
Lately I’ve been spending my time reading some questionable code, which made me think about the habits of programming. There’s no exact science here, but it is true that bad handled code can explode really fast creating a series of problems.
- Maintenance hells.
- A bug fixed, uncovers another bug.
- Hard to get somebody up to speed.
- Lots of snorting (iup that’s me).
- Clear increase of gray hair (iup, that’s me).
I started drafting a post about this topic. Then, it exploded in size. So I decided to split it in digestible bits of enjoyment.
The original title was: The Code Apocalypse but I settled for something milder because… that’s my style :-D.
Filed under code, tips, TSP
When I think about sprites, my mind goes directly to the NES, and SNES era.
The graphics were meshed together in a way that was easier to handle than multiple images. And well, now they have this nostalgic appeal. I can’t watch this without a smile.
Luigi Sprite from Super Mario Bros.
As old as 10 years ago (already? :-O) A list apart published an amazing article on how to use this same idea to reduce the amount of browser petitions for images. That article is wonderful, but apart (hehe) from that, it urges people to think creatively!
Long story short, this is going to be a post on how to create a CSS sprite image and stylesheet with 100 lines of python.
CSS sprite generator python
A standard way to style any OGC layer is using SLD. Styled Layer Descriptors.
The Styled Layer Descriptors are a simple (and standard) way to style your web maps. But when you style you also want to generate a nice legend for it.
I recently found myself with the situation of reworking a website styling code. Instead of writing it from scratch we used existing pieces to cleanly fill our webapp divs with the correct legend.
Filed under code, gis, Maps
The third (and probably last) post about this lovely Jenkins guy. It seems that people is right, lately I’m Jenkins man.
Most of what I do in Jenkins can be done with the Groovy Scripting language itself, usually via the Scriptler plugin to keep things organized.
I am a command line guy, and sometimes I just want to get a plain text file with the results for something, instead of firing up Jenkins, going to a build, checking the artifact or output.
In this post I’ll present how to combine a basic Groovy script, with a more in-depth analysis with a python script:
Let’s save some time
I recently talked about how to automate Jenkins using job-dsl. We are going a bit further here.
Jenkins is usually the frontend for projects to check their build status, but for some, Jenkins is the product that we develop, or where we drop plugins etc. In that case, we don’t want to do this into production.
In our case we work with Open Nebula as a VM provider, so it is fairly easy to create a quick VM to test something and then just remove it. It is not as common as having your own Jenkins instance, but since I found that I was doing this quite commonly, it was time to automate.
In this post I present an automatic way to set up a quick Jenkins host. So I just have to type a command and come back later.
Jump around, Jump around. No maps this time, but Continuous Integration. My current work involves a lot of a software piece called Jenkins. I’ve been swimming with it the last 2 months and I feel compelled to share how we changed our ways.
This post is an overview guide on how to configure Jenkins to generate the jobs that are defined in a git repo.
let’s integrate continuously