As another year begins, I found myself struggling to get to sleep before the first day back at work. This wasn't a new experience for me as I seem to recall the same sort of nervousness before the first day back at school as a child.
I consider this time of year to be a bit like travelling between very different timezones - just as I have gotten accustomed to going to bed late and sleeping late the following morning, it's time to adjust back to the work life routine.
One of the many thoughts that occurred to me when I should have been blissfully sleeping was whether my skills are still as relevant to my chosen career in software development.
In the morning I woke up early and decided to have a look at some source code from a system that my current project will be interacting with...
A section of code that particularly stood out to me involved something like 12 branches of if / else checks, where each comparison was against a constant defined earlier in the class, and each outcome also involved another constant. This could easily be condensed down to two or three lines with one conditional expression by replacing all of the constants with a single Map.
I'm sleeping much better.
Sunday, 4 January 2015
Sunday, 28 December 2014
Need to exclude referral spam from Analytics reports
It turns out that some unusual referral URLs in my Blog's Google Analytics reports a few weeks ago were not a one off anomaly by a sneaky spammer. If I followed the referral URL I got forwarded on to Amazon with some affiliate details - so they'd get a kickback for any purchases I made.
Today I see over a hundred visits from the Russian city Samara, along with large numbers of referrals from domains that have nothing in common with the content of my blog.
I'm contemplating moving the blog to another platform so that I can have greater control over the behaviour for blocking dodgy referrers. For the time being I will have to settle for adding some filters to the Google Analytics reports as these dodgy referrers come in - so far just blocking one city is sufficient.
I would have hoped that the spammer would realise that my blog does not publish a list of backlinks to sites that have linked to my posts, so there is no value in "visiting" from his dodgy sites.
Today I see over a hundred visits from the Russian city Samara, along with large numbers of referrals from domains that have nothing in common with the content of my blog.
I'm contemplating moving the blog to another platform so that I can have greater control over the behaviour for blocking dodgy referrers. For the time being I will have to settle for adding some filters to the Google Analytics reports as these dodgy referrers come in - so far just blocking one city is sufficient.
I would have hoped that the spammer would realise that my blog does not publish a list of backlinks to sites that have linked to my posts, so there is no value in "visiting" from his dodgy sites.
Wednesday, 10 December 2014
Microservices vs Mechanical Sympathy
At what point does it make sense to split some functionality out to run in a separate process to be called upon over HTTP?
When the only driver is the single responsibility principle, I'm looking for a term that means the opposite of premature optimisation - premature over complication has a nice ring to it.
Why don't I like this? Let me enumerate the ways:
- Additional network IO
- Additional processes
- requiring memory
- occupying CPU cores
- Placing additional load on networking infrastructure
- A potential point of failure
In addition to those runtime overheads, we have some development and deployment considerations:
- Another artefact to deploy
- Another service to test
- Another stream in the continuous delivery pipeline
Tuesday, 2 December 2014
Mystical Secret to Speeding up Software Development - Stop Faking It
A few months ago we developed some functionality based on an unsupported non-production-ready service.
Unsurprisingly we are now in the process of re-writing the functionality to use a real implementation.
Hot tip for reducing the amount of time to deliver a software project - don't build on something that isn't going to exist when your system will be going live.
Coincidentally we have moved away from inserting fake data into our databases in development, QA and production environments. Fake data doesn't belong in our live systems.
Our application doesn't need to insert data into the system, so we no longer need our data access permissions to have inappropriate permissions.
Unsurprisingly we are now in the process of re-writing the functionality to use a real implementation.
Hot tip for reducing the amount of time to deliver a software project - don't build on something that isn't going to exist when your system will be going live.
Coincidentally we have moved away from inserting fake data into our databases in development, QA and production environments. Fake data doesn't belong in our live systems.
Our application doesn't need to insert data into the system, so we no longer need our data access permissions to have inappropriate permissions.
Wednesday, 12 November 2014
Docker Hub Group permissions
As part of a story in a recent development iteration at work, I found myself guiding two development teams in the use of Docker Hub.
Strangely my current project had already had an indirect dependency on Docker Hub for a few months, but today was the first time that we actually needed to consider the ins and outs of this particular system.
In this case the "in" side involves our continuous deployment system pushing an image, and the "out"side involves a separate system pulling an image from the same repository.
In the interests of ensuring that each project team does not run the risk of accidentally blowing away anything or everything that the other project teams have set up, I took it upon myself to learn the ins and outs of group permissions in Docker Hub.
Now instead of just having one big group of Owner users associated with our organisation we have two additional groups for my current project - one that contains users with the right to push images, and one with the right to read (pull) images.
Strangely my current project had already had an indirect dependency on Docker Hub for a few months, but today was the first time that we actually needed to consider the ins and outs of this particular system.
In this case the "in" side involves our continuous deployment system pushing an image, and the "out"side involves a separate system pulling an image from the same repository.
In the interests of ensuring that each project team does not run the risk of accidentally blowing away anything or everything that the other project teams have set up, I took it upon myself to learn the ins and outs of group permissions in Docker Hub.
Now instead of just having one big group of Owner users associated with our organisation we have two additional groups for my current project - one that contains users with the right to push images, and one with the right to read (pull) images.
Monday, 10 November 2014
Strange day in the office
My plan to wait for other teams to sort out the approach to deploying applications in Docker didn't work out quite the way I had hoped.
This morning I guided some colleagues to get our application set up to run from a Docker image, without worrying about the details of deploying anywhere - expecting that another development team would have that sorted out from their project first.
Sure enough, come mid-afternoon we'd established that the other development team didn't need that functionality yet so we'd have to figure it out for ourselves.
Okay, we have a tools engineering team that have already provided something Dockerised automagically through Dockerhub so they'll be able to show us how to do it in no time.
It turned out that the approach used so far involved Dockerhub pulling the Docker image content directly from a Git repository. This doesn't quite suit our needs, as our application needs to be built from source first.
The ugly option involved setting up a dedicated Git repository for our binary artifact, which Dockerhub could pull across.
Back to the drawing board.
An hour or so later I overheard my colleagues mentioning something about authenticating to Dockerhub from Gradle. It turns out that the plugin they've used for creating a Docker image can also be applied to push to a Docker repository.
Don't worry, there's more fun ahead to get this set up in the continuous deployment pipeline.
This morning I guided some colleagues to get our application set up to run from a Docker image, without worrying about the details of deploying anywhere - expecting that another development team would have that sorted out from their project first.
Sure enough, come mid-afternoon we'd established that the other development team didn't need that functionality yet so we'd have to figure it out for ourselves.
Okay, we have a tools engineering team that have already provided something Dockerised automagically through Dockerhub so they'll be able to show us how to do it in no time.
It turned out that the approach used so far involved Dockerhub pulling the Docker image content directly from a Git repository. This doesn't quite suit our needs, as our application needs to be built from source first.
The ugly option involved setting up a dedicated Git repository for our binary artifact, which Dockerhub could pull across.
Back to the drawing board.
An hour or so later I overheard my colleagues mentioning something about authenticating to Dockerhub from Gradle. It turns out that the plugin they've used for creating a Docker image can also be applied to push to a Docker repository.
Don't worry, there's more fun ahead to get this set up in the continuous deployment pipeline.
Subscribe to:
Posts (Atom)