PHP has a ridiculous amount of in-built functions.
Even though I code in it daily, I am still surprised to find a new one.
It was not until recently that I discovered strip_tags, which saved me an ample amount of time that I would have spent writing my own implementation.
My philosophy now is that if there is a function you require, PHP most likely already has it.
Whilst working with PHP, I seem to use var_dump a ridiculous amount.
It’s a debugging must-have.
However, it does fall short in a few ways.
It does not take into consideration that the function is almost always displayed on an HTML page, and switching to the page source can be troublesome.
Due to these pitfalls, a host of projects such as Krumo and Kint have emerged to cater for these needs.
In addition to these projects, if you have XDebug installed, it will replace the default var_dump function with its own implementation that outputs the information with much-needed styling.
I have been a part-time Git user for a little over a year now. Before this, I had dabbled with using Subversion but never for anything too serious. I say ‘part-time’ because, throughout the year, I never fully got to grips with all the ideologies and tools available to support my development lifecycle process. This was particularly evident with regard to branching.
I have been a loyal MAMP Pro user for many years. I fell in love with how easy it was to set up custom hosts, without the need to tweak the hosts file myself. However, ever since I documented my experiences with DNSMasq, I have been interested in how this article documented setting up a web stack with Apache, similar to Ruby’s Pow. The ability to set up a new development site with only the creation of a new folder (i.e. a folder called test could be accessible at test.dev) appealed to me greatly.
It is becoming a scarily common occurrence to read about yet another batch of high-profile websites’ users’ passwords being leaked online - for everyone’s cracking pleasure. What’s even more shocking is how poorly these sites are storing them. In the case of LinkedIn, it turned out that they had stored them as unsalted, plain MD5 hashes, which any Joe Bloggs could easily crack using a rainbow table. The tried and tested means of storing passwords in today’s web applications is to create a hash from the user’s input, and then compare any attempted authentication with this stored value. The trouble and confusion arise, however, in how to actually achieve this, as there are so many incorrect methods available.