Posts with the tag development:
Here I try to explain in nontechnical ways things that happen in IT departments which in my opinion are generally harmful to the company. The aim of this series is to help company founders who aren’t experienced in IT be able to judge the health of their IT department.
The Product Team is there to decide which features are to built first and how the features are to work. They are one of the most crucial parts of the development processes since they choose the path for the project and help make sure that the project brings the most business value as possible.
Over the years of leading teams and working in various IT environments I’ve discovered, there are generally three types of tickets within the small to medium size companies.
An Idea An Idea Request is where someone has an idea, and it would be nice to try it out and see if it works or not. An idea is not a request that is based on current business needs but on the possibility to improve something that is already working.
For the most part, sanity checks are put into the code to ensure there are no bugs. For this reason, guaranteeing sanity checks are done correctly becomes necessary. If you do not check to see if the data is valid, and it is invalid, then you’re going to allow invalid data to proceed. Here, I’m going to discuss how I think we should do sanity checking in PHP.
Asserting Valid Data What I’ve seen a lot is people are asserting for invalid data when they’re doing their sanity check.
Single Responsibility Principle (SRP) is probably one of the most well-known principles from SOLID. At its core is a desire to prevent classes from becoming overwhelming and bloated. While enabling the ability to change how a single thing works by only changing a single class. So the benefits of SRP are that you have an easier codebase to maintain since classes are less complex and when you wish to change something you only have to change a single class. In this blog, I will go through some ways to try and help avoid breaching SRP while doing code review.
In development we constantly bemoan bad developers. But what I’ve noticed is everyone generally thinks they’re doing a good job and the other developers are bad. I don’t think you can exactly define what is a good developer down to a tee but I think you can have rough benchmarks for whether or not you’re good. These generally are if you follow well defined practices. There are levels of development practices ranging from the basics (DRY) to advance (CQRS).
So I recently started a new side project that involves data mining. While working on this project I’ve learned a little bit about how to manage a larger than usual database. At the point of writing this the database is approximately 50GB and growing daily. So here are a few things I’ve learned.
Backups This is probably the main area where I learned a bunch of stuff. Usually when you’re dealing with a database of approximately 1GB in size, backups at midnight are rather routine.
A very simple breakdown of how the password encoding works with Symfony 2.
Encoder factory The encoder factory is where you get your password encoders from. You pass in a User entity and it returns an Encoder. Encoders are created from the encoder configs and stored within the factory, there is only a single instance of the encoder unless you clone it outside of the factory. The encoder configs are passed to the factory upon creation.
Facebook’s Hack bring lots of features that a lot of other programming languages get to take advantage of. One of major advantages of Hack over PHP is a typing system. So here’s a quick run over of the typing system as I understand it.
Annotate Annotating is when you define which type is going to be used. You can type the following:
function arguments function return class variable constants For function arguments you just put the type before the variable name for the argument.
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: