Dependency injection is one of my favourite programming patterns for large projects. Among other things, it's great for promoting loosely coupled components which, when projects get large, is a worth it's weight in gold as re-factoring becomes a much easier and testing these independent modules is cake since they typically follow the dependency inversion principle. Regardless, code typically has two fundamental ways of taking a dependency: via the constructor or via a property (or method). Unfortunately, one of these should be avoided at all cost.
Throughout my professional and my personal career I've been participated in, and been on the receiving end, of a lot of code reviews. I've compiled a few tips that have greatly improved my code reviews as well as improved the code reviews I've participated in.
As a developer I live for APIs. The ability to take structured information from one source and transform it into another is very exciting. Unfortunately, not all information sources provide a API. Many times, the information needed is jamed into a HTML source which presents a challenge attempting to extract it. Luckily, there's an incredible NodeJS package called Cheerio which makes this task pretty simple.
On June Second, Apple announced the very sleek and extremely welcome new development language for constructing iOS and OSX applications: Swift. Swift is the successor to Objective-C which has been the primary language for developing on iOS and OSX platforms. Swift is a completely new language that Apple has designed for the sole purpose of making it easier for developers to rapidly construct their applications. On the surface, this is great news.
The concept of versioning a RESTful API is very basic: you start off developing a set of APIs which you'll label version 1.0. A few months later, you choose to make modifications to the existing set of APIs. Instead of modifying the current structure you choose to make a 2.0 verison. The whole purpose of this process is that you prevent disruption for those using your 1.0 API while you work on a new set of features. If you choose to version your API but ignore this fact and butcher your 1.0 anyway, while not providing a suitable replacement in your 2.0, then you might as well tell your third party developers to get lost.