So in Revel you can have your template in several different formats: html, json, xml, or txt. This is super awesome. As it allows you to send the same data and display different formats - Obivously. It also determines what template to use based on the http request headers that have been sent. So if your request sends that it accepts application/xml it’ll use xml and if you request says application/json it uses json.
So lately I’ve been working on a project to increase productivity when dealing with Bitbucket and Jenkins. As I am a web developer, it’s a web app. So one of the first questions when building an application these days seems to be what framework? This for me has taken a month to really decide. In the end I choose Revel. At first At first I decided to use Gorilla Web Toolkit.
So a while back I read a blog post by ChunkHost about a “Huge security hole in Sendgrid”. And instantly I thought why isn’t there a protection against something which is so obviously dodgy. After a few seconds I thought of an easy protection against such an attack, I’ve now found time to write about it so here it is. #The attack The attack was simple, someone phoned up Sendgrid’s customer support and talked them into changing the email for the ChunkHost account from support@chunkhost.
I recently came across a rather unsual error with our testing suite while running on Jenkins. The test would pass on our development environment, not exactly odd in itself. Sadly they aren’t exact copies, patch level out and what not. However the test would pass on the Jenkins server if ran via command line. So it wasn’t that a minor release had a bug fix that was causing the issue. Since after all my googling on the subject turned up nothing I thought I would write up how I found out what it was and what the cause and solution was.
For some reason at some point, I thought it would be hard to implement the observer pattern in Go. Then I made an issue for me to blog about it. Well it’s not hard. It’s as easy as it is in every other language. Observers First part of the observer pattern is you need the actual observers. The logic that you want executed whenever something happens. Here I’ve just put a simple log print statement that will print out the name of the hook to the log.
Wrote this ages ago and just found it and figured I should post it. A while back I saw a blog post (link) saying that he would never hack on a production code base during the interview. Since he was not getting paid for it. Well I strongly disagree with that, both from an interviewee and an interviewer point of view. Interviewer While working at my last job I was in charge of the technical test for developers.
For those not in the know, git-flow is technically a tool for git which allows for the easy use of a specific branch model. Which is most commonly referred to as git-flow. This blog post isn’t about that tool which is super useful. But is about the branch model. Which is also super useful in my opinion if you’re implementing the waterfall development process. Disclaimer: This isn’t meant to be a criticism of either the branching model or the waterfall process.
So I’ve decided to I need to get back to programming more things in my spare time. One way to kinda force this on myself is to attempt to do 100 days of github contributions. My first aim is to write an actual project to do something I need. Currently one of the things I need is something to give me better overview of the status of builds on Jenkins. Currently I just know if the builds are passing or failing.