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?
During application development sending test emails can usually be a pain, even when using a modern frmaework like the excellent Laravel 4. During development it is very desirable to debug emails without actually sending them.There are a few options I’ve come across:
- Use Laravel 4′s Mail pretend feature. Simply set the configuration key “pretend” to true in app/config/mail.php. Laravel will now not send emails, instead write the content of each email to the application log
- Manually change the “to” email to your own so emails are delivered to your favourite email client – again, messy if sending lots of emails and if you ever made a mistake
- Print out the email data directly to the screen, but don’t send the actual email – the worst solution in my opinion
Options 2 and 3 are particularly fraught with issues. For instance, assume the application was to send out 1000 member renewal reminders and during development the route that sends out the emails was hit. Very soon, we’d have some very real (and confused, annoyed etc.) customers contacting you – disaster!
The Opencart Multistore feature is a great addition for retailers requiring multiple stores, managed via a single administration area. Setting up multistore in Opencart is quite easy and can be accomplished in a few minutes.
However, after visiting the new store you’ll immediately see that existing products, categories, customers, page layouts etc. have not transferred over. Ouch! The new store is completely empty.
When using the excellent Laravel 4, writing DRY and SOLID code is something you’re well aware of. Unfortunately, it’s common for the routes file to get messy and repetitive as an application grows – enter the route pattern method. Even worse (in my opinion) is performing basic and repetitive validation of parameters in controllers.
Consider a routes file that responds to 4 simple URIs:
SSH, or Secure Shell is something any web developer will have come across. Personally, every single website I deploy involves SSH where I’ll upload and extract a single compressed archive. This is simply good practice and most importantly, much faster than normal FTP. There are a plethora of further benefits in having SSH access – I won’t go into these here though. However, as common a feature as SSH access is, gaining SSH Access on a Heart Internet hosting account surprisingly, turns out to be pretty darn hard to get.
Database seeding can be a pain to perform and end up very clumsy. Seeding is a process required in the majority of web applications – either for stress testing or just to generate a reasonable sample of test data during testing. Laravel 4 already has database seeding and migrations built in, which of course is great. However, the functionality to generate the actual sample data is lacking. Enter Faker – a package, available via composer. The author describes this better than I can:
Faker is a PHP library that generates fake data for you. Whether you need to bootstrap your database, create good-looking XML documents, fill-in your persistence to stress test it, or anonymize data taken from a production service, Faker is for you.