As a freelance developer, inheriting and working with code I did not originally write is common place. More often than not, code written using a known framework results in perfectly readable code, easy enough to work with and extend. Granted, every project is not written in Laravel 5, but the code that I inherit is workable.
When I recently inherited a complicated CodeIgniter site I was (initially) confident I’d have a good base to extend and work with. How wrong I was I? I could literally write a book about why the project I inherited was so bad. For the sake of brevity, I’ll stick to the main issues.
This post proves a single statement. Code written using a framework, is not necessarily “good”. It can end up painfully awful. In retrospect, I would have preferred to inherit a WordPress site. At least then my expectations are low to begin with 🙂
This morning, I was part of a fairly normal client meeting discussing potential new work. The client started to discuss about what 
Recently, I’ve been looking for ways to streamline and improve my workflow with frontend assets. This is the first article in a mini series, where I’ll be explaining my updated workflow with Bower and GruntJS. Part one covers 
At a recent business networking event I got talking to another web developer, who has just started using Laravel 4. We got chatting about Laravel in general and how awesome it is.Of course, the subject of IoC cropped up. The other developer commented on IoC, saying, “you need to be really careful with the IoC and passing an instance of the $app into the closure for performance reasons, the $app shouldn’t really be passed through at all ideally”. His argument also focused upon the fact that injecting the “Laravel 4 Facades” (
SSH, or