Networking is not something a lot of developers look into. We assume that the requests come in from the network and the responses go out, without thinking about how the data is actually sent around. This is for the best, normally; network infrastructure is a field unto itself. However, in these days of micro-services, cloud computing and full stack development, you might be asked to make choices about the network, such as what load balancers to use and where. Therefore a basic understanding of the principles underlying these networks is very important.
One of the key concepts to understand is the idea of Network Layers. This breaks the passage of information around the network into several incremental ideas or abstractions, built on e on top each-other. Think of it like a house; you have the land, an architect will have to think of one way, then the foundations that are built into the land, which will have to thought of in a different way with a different set of knowledge, then the load bearing walls which again are different etc. until you have a full house. So it goes for the idea of a network. The actual name of this model is the Open Systems Interconnection Model, but that sounds far more intimidating that it actually is.
It’s really quite simple, when you break it down into questions…..
I remember when I was first drafted into the security council of my then employers. I was just a developer keen to improve my understanding of application security, and there I was with the senior architects and developers, along with the devision’s head of delivery. And yet I did something that inadvertantly propelled me into the role of being one of the leaders of the council, significantly raising my profile within the devision and leading to more opportunities. Read on to find out more….
I’ve been learning a lot about the theory and history of BDD recently, and where the Cucumber framework sits in all this. I’d thought I’d share my notes, as there are many misconceptions about both these things; as always with my ‘notes’ posts, the format is a little sparse and unstructured, and is aimed at people who already have exposure to these technologies, the idea being that you can scan it easily and pick out ideas…..
Following on from my previous post, it’s time to delve deeper into the workings of Ruby!
I’ve recently been learning Ruby, and I thought I’d share some of the notes I wrote. This will be in two parts, first the basics, then more advanced topics such as Blocks (when I get around to typing up those notes!).
One thing that’s very surprising about PKI infrastructure is the fact that a lot of the mechanisms put in place don’t work, or don’t work as they should. Often this is driven by sheer necessity, and the need to keep the internet working no matter what. One example of this is certificate revocation. If you are setting up a domain and requesting a new certificate, you would assume that once issued the certificate can be revoked in the case of a security breach.
But you’d be wrong. Even when you revoke the certificate attackers can still use it to enable MIIM attacks. Read on to see why….
One thing that I’ve had to get my head around when learning about DynamoDB is what exactly partition and sort keys are, and how they tie into the more familiar concept of a primary key. DynamoDB as you may know is a hosted NoSql database that can store heterogeneous items of varying structures; imagine a system that stores miscellaneous JSON documents, each with a unique key, and you’ll get the idea (though it’s not strictly a JSON document store)
The DynamoDB documentation talks of two concepts, a partition key and a sort key, and it’s not immediately obvious how these relate to the more common concept of a primary key that you’d get in a traditional database. Really it’s quite simple, but first let’s clarify what each term means. Continue reading
In my previous post, I detail how REST allows us to utilise the HTTP’s native caching functionality without the need for additional technologies or knowledge. However, this whole ‘using what we know about HTTP already’ philosophy goes much deeper than that.
Consider one of the biggest problems with API design and maintenance: getting your clients to use the API correctly, especially when it’s changing or is constant development. This might be easy if you are integrating with one team that sits next to you (and even then misunderstandings can arise), but what if you have multiple clients across the organisation, or if you API is public? Read on if you want to see how REST can help….
So I already covered some of the misconceptions around REST in my previous post (if you haven’t read it, please do), but I want to delve into some of the advantages of using such a methodology. This pattern assumes a simple point-to-point, client/server, request/response architecture, which is far from the only way to skin a cat out in IT land, but if it fits your app, REST can give you certain benefits. Today I will focus on HTTP Caching.
A few months ago I had the opportunity to go to the Agile Testing & BDD eXchange 2016 conference (https://skillsmatter.com/conferences/7428-agile-testing-and-bdd-exchange-2016). I’ve finally had the chance to write up the notes I took (if any of the speakers are reading this and feel that I’m ‘stealing their lunch’ or infringing on their rights, please let me know and I’ll remove the offending content.)
The notes below reflect my own jottings down and interpretations, and not necessarily the views of the speakers.