Often when working on a site, particularly a web app, it can be helpful to show your users what version of the site is currently running, this can help with debugging issues. However it can be a pain to remember to always update the version number when you do a new release, wouldn’t it be easier if the semantic version number was auto-updating?
We’ve been using Vagrant for a while here, but it was always a bit of a pain that it took so long to boot up a virtual machine to work on, since we had to install everything on it ourselves via a bootup script. A little while ago now Laravel released a pre-configured box for Vagrant codenamed Homestead, being pre-configured to support a Laravel built site it took mere seconds to spin up a new box. But it was missing a few things.
A new update has just been pushed to our revisionable package for automated revision logging with Laravel, which adds support for overriding the field name when you’re displaying your history.
We were contacted a short while ago by Tas from ShoeString asking a few questions about how Elevio came about, and where it was heading. We happily answered everything they had to ask, with a decent amount of information, but we were pretty stoked with the end result. Thanks Tas & ShoeString!
We’ve used a few todo list tools in the past, some free, some paid, but all with their pros and cons. There’s not one single perfect solution to the age old problem of how to best break out your task into planned lists, but more importantly make sure that you actually complete the tasks when they are due. As they say, you can’t keep everybody happy.
For a recent project, the client insisted that the tooltips being shown on the page were color coded to the element that they related to, needing red, blue and green tooltips.
The best tooltip in my books, is tipsy by jaz303, and thankfully it matched the design perfectly. However it only allows you to pick one color for all your tooltips, that wasn’t going to do, some mods were needed.
I would have to differentiate between Symfony (v1) and Symfony2 (which is fundamentally/completely different and PHP5.3). The reason why I say that is we weren’t interested in Symfony1 (no major motivations when we evaluated) and weren’t entirely happy with what other frameworks existed in PHP, but now that Symfony2 is along, we are big fans.
My last post about deciding between CodeIgniter and CakePHP stirred up quite a bit of discussion on why we only compared the two frameworks, and didn’t include other frameworks that were lighter, faster, utilised PHP 5.3, and other factors.
The main reason was that they were the two frameworks that we were most familiar with, which would help us to launch the project faster. Where I went wrong was mentioning that I had chosen CakePHP as I wanted to learn something new, as the biggest suggestion was that if I wanted to learn something new and grow myself as a developer, then I should learn something more cutting edge and that I hadn’t worked with before.
So, we’re now going to look into other frameworks, and revise our decision on which framework we are going to go with for this project, and probably the next as well.
The decision on which PHP framework to use has been a hotly debated topic in our office for quite some time, with Matt using CakePHP as his framework of choice, and myself using CodeIgniter as mine. We’ve both completed quite a few sites in both frameworks, but at the end of the day, have our favourite that we always go back to without having to think about it. But the time has come that we need to collaborate on a project, and we need to pick just one.