Estimations are one of the most important parts of project planning and one of the most common tasks that developers do no matter which language they code in, what team they are on, or which company they work for. Estimating is hard, so hard we pretty much get it wrong a lot of the time. Not enough details - guesstimates Estimating without enough information is in my opinion of the leading causes of estimating poorly and causes project overruns.
Posts with the tag theory:
Code review is the process of having others review code that is written and accepting feedback and adapting the code to the feedback given. These days code review is seemingly at every IT department and widely ruled agreed upon as a best practice. It is often one of the largest sources of conflicts within a development team since giving and receiving criticism about work is often hard to do while remaining detached from the work itself.
If you’re programming in an object orientated language that supports exceptions you should never return null in a method that returns an object. Most object orientated languages support exceptions. Exceptions give us an extremely expressive way to represent error conditions. We throw an exception and the program bails out of where it is and then goes to the error handling section. We can create custom exceptions to express exactly what sort of error occured.
I’ve recently had a discussion about how I would go about testing code that makes calls to a remote third party API. It seems my way of thinking isn’t the same as most others. So I figured I would write out my thoughts and explanation behind why I would go for this route. Others peoples approach So first I want to explain other peoples thought patterns seem to be. It goes like:
I’ve been thinking about dependency injection a lot recently and the best way to do it in a clean manner. I recently changed how I was injecting some dependencies, at code review I was asked why. So I figured I would write a blog post fully stating my current views on how to implement Dependency Injection. There are three main ways of injecting a single dependency, as well as what I would consider two ways of injecting multiple dependencies these are also known as patterns.
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.
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.