Last week JSONFeed, an RSS/Atom alternative using JSON, was introduced and to me that seemed like a good excuse to play around with Hugo's new Output Formats.
Over the past weeks I've been working on a new tool. Now, Igor has reached a state where I'm happy with showing it off and so it's time to introduce it to the world.
Today someone asked me if it's possible to host a Hugo site on AWS that is only accessible from their company IP. Of course it is, let me explain how.
GitHub Pages works differently based on how you set it up. As several people have asked me for help when they ran into issues with deploying the site they generated using my Hugo Wercker step, this article will serve as a place to point them to.
For the Docker meetup in Melbourne I gave a presentation on how to use Docker with Jenkins to make it more flexible. The presentation is based on an article I've written about the same subject.
For the DevOps meetup in Melbourne I gave a presentation on preparing deployable code using Docker and Jenkins. The presentation is based on articles I've written about the same subject.
I wanted something that could ensure my usage of the Reporter app would be logged in my journaling app of choice, so I built it.
fcd is a zsh plugin I built for easily switching between different projects on the command line.
As I actually started writing again for this site, I found that I just wasn't happy with Wordpress. I originally chose Wordpress because it was the path of least resistance, but it turns out that it doesn't suit my needs.
As professional nerds, we love role-playing games. And we love web development. Naturally, we wondered what a character talent tree for a web developer might look like.
This is just a fun thing, but can still be used to discover areas to improve yourself in. And of course, it’s one of those sites that shows how much fun web development can be.
Via The Loop
On the one hand, technical debt refers to the quick and dirty shortcuts we take and the effect they have on future development. On the other hand, technical debt is also about the things that we don’t do, such as not commenting our code, not developing documentation, not doing proper testing, etc.
Technical debt is an interesting subject, and one that every developer should take into account. In most cases as a developer you will want to have the most elegant solution for your problem, preferably using the latest or coolest technology. Depending on the situation though this might not always be the solution your boss or client wants, usually because that solution is more expensive than the quick hack you were forced to also mention. That’s why before you then end up implementing the quick hack it is imperative to make it clear this will only postpone the “saved” time until a later moment. To be fair, often enough that trade-off might be worth it, even if this would lead to more time in the future.
Another case of technical debt that isn’t really touched on in this article is caused by using old technology. When there is an existing codebase that makes it easy to build something new, but makes use of older or even no longer supported tools it’s important to weigh the downsides of that very carefully. Especially when it comes to a project that will have to be supported for a long time.
In the short term using this might bring about a successful result faster, and using something new will undoubtedly lead to new and unexpected bugs as well. However, looking at the longer term, there are a fair number of problems that might crop up. Ranging from the obvious security problems, upgrade trouble, and performance issues, to even the decreased ability of the future developers to understand the use of the code base.