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
Yup, it’s 2014 and there are countless articles written about security your PHP code. Hell, most people use a framework. Today, I took over from another developer on a rather large internal quoting system, from another company. The company, rather ironically, class themselves are “the web experts”. The following gem was written on 23/10/2014. I present the following in all it’s scary, insecure glory:
Whilst I don’t usually come into contact with the Heart Internet people too frequently (I only use them for a couple of domains personally and have experienced past annoyances with SSH/Shell access to a Heart Internet account), I did this morning. I have no issue with their manner, as the person I spoke to was very polite.
Heart Internet Support Ticket Statistics
There are some rather painful statistics that this ticket resulted in:
||17/11/2014 at 11:09
||22/11/2014 at 15:54
||5 days, 1 hour, 43 minutes
|Number of ticket updates:
|Number of support staff involved:
||12 (not a typo, 12 different people)
|Issue ultimately resolved:
|Phone calls made (by myself):
|Times Heart Internet blamed PyroCMS:
|Compensation offered by heart Internet:
||3 months free hosting
|Times Heart Internet apologised:
|Amount of my own time wasted:
In short, I had a run of the mill MySQL connection error. PyroCMS was complaining, saying:
mysqli::real_connect(): (HY000/1045): Access denied for user 'THE USER NAME'@'10.0.44.120' (using password: YES)
Unfortunately, when all the connection details are correct in the script, there is little choice but to raise a support ticket. I raised a detailed ticket, provided locations to where the site was connecting to the database and a location to the error log (which was a nicely formatted, CodeIgniter log file). I explained everything in detail.
Just came across this gem, that I’m sure anyone who works in development can appreciate:
As developers need to look at problems from a different standpoint, software projects
cannot be accelerated by spending more time in the office or adding more people
to a project. Development is not just about timelines and assigned tasks. If you visit
the development centers of world-famous software companies such as Google and
IBM, you’ll see that there are many opportunities for spending time away from the
keyboard for developers. Programming questions have to be thought of in the context
of the real world
This morning, I was part of a fairly normal client meeting discussing potential new work. The client started to discuss about what constitutes a good and bad service in relation to web development. In a similar fashion to lots of customers I encounter, they all have their own horror story of working with another developer or agency. This client was no different in that respect. The client had issues with work not being completed and promised missed deadlines in the past.
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 Bower, a package manager for frontend assets and packages – this article is short Bower tutorial for the uninitiated.
Bower is comparable to Composer (a dependency manager for PHP), except for frontend assets. This is great news for any project as Bower allows for stress free management, tracking, finding and updating of all frontend assets for a project.
Previously, you may have manually copied in an updated version of say Twitter Bootsrap or JQuery into a skeleton project, or even have left and older version that has been blindly copied over. Even in medium sized projects, this process of manually setting up each package quickly becomes tiresome. Checking the version, downloading the package, updating references to any changed files etc. Instead, let Bower take away this work.
Web Developers & Designers alike can rejoice! As of 12th January 2016 Microsoft will no longer provide security patches and updates to dated versions of Internet Explorer. In an official announcement, Microsoft said:
.. only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates.
Recently, the latest website security saga in the news has been Hotelhippo.com. I won’t try and top Scott Helme’s article as he does an excellent job at explaining the saga in exhaustive detail, along with the other glaring issues he discovered. There’s another great article by Neil Stud that is definitely worth a read too. However, I’ll be covering the issue purely from a web development perspective, because as a developer myself, I find the whole situation scary/insane.
The issue I will be covering concerns an error that any web developer, even a junior, cannot excuse – the ability to change query string data and view private information without authentication. A site as big as Hotel Hippo and one that that stores a lot of personal customer information should frankly, be ashamed of themselves for such a basic breach.
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” (
config/app.php line 151) into controllers as it is faster.
Personally, I think he’d missed the point of IoC here. The only point he does have at a push, I assume, is if the object doesn’t need an instance of the $app, then don’t pass it through the closure – but that’s pretty obvious?