Jeremy Hutchings

One of my ongoing pet peeves it's the marketing over substance of the usual "agile" and "scrum" proponents. I've found near constantly that the focus of this approach by it's advocates, is not to facilitate a team; but to prove that the process (i.e. scrum based agile) is the best (and typically only) way to run a technical project, and write software. Agile? ......... sounds more ridged to me. I find this ironic as the pushers  (appear, in my experience to) rarely come come from a software architecture, or at least development back ground. It more appears a thinly veiled covering over typical old school management tactics. As in part demonstrated by this post : http://www.infoq.com/news/2010/11/working-with-difficult-people Ignoring the apparent "I'm right your wrong" title (which sums up what I'm talking about) and going straight for some of the contents of the post, that  supports my points. (Points they are ironically

Background  For a current project I am experimenting with XenForo and integrating CI (CodeIgniter) to build some extra functionality. They are other areas of the site (not form specific). I just needed to be sure that the user ( Visitor in XenForo terminology) was logged in, and if they were a super admin; while having access to libraries and the MVC of CI. XenForo The set up for XenForo is fairly minor, there is none. Just install it and you're done, for this example it's installed in : /var/www/xenforo URL being : http://www.example.com/xenforo/ CodeIgniter I've installed (a default 1.7.3) in a separate directory for the moment just for ease of example (structure you site as needed, as always): /var/www/ci Example URL being : http://www.example.com/ci/ Browsing to, gives us the obligatory all OK from the CI welcome controller : xF_auth I've shared the CI libary on gitHub : https://github.com/JeremyHutchings/xF_auth As with any CI

I noticed a post from an past college  Scott MacVicar  about getting involved with and helping out PHP.  Personally I've always thought about it and wanted to, though have always focused on hard core C, thinking : "Helping PHP, means writing hardcore C, and building libraries" The more I thought about that statement, and the way I typically think about software, Open Source and communities, I realized  what nonsense that is . There is so much more going on in a project and community, therefor there are many more ways to help. Developing a technology & community is a holistic activity . Some of us are writers, framework developers, application developers, business decision makers, power users, clients making requirements, community members, and so on. Though a lot of us, are more than one role, it takes us all and there is always room for more. Though you could use these points for any OSS project, I'm just focused on PHP. Here are 10 I've thought o

Recently I've been meeting with a local company to asses what opportunities they have, how they operate and more importantly, how they treat people. I wanted the first hand information opposed to going on their reputation. I met with them 3 times (have to give them a fair run and all that) and each time there was something strange going on. First time around, in a 14x14 room with paper and pen to do a memory syntax test, to asses what I'm like as a "developer" ...... really .... Second time was a whole day with a 15 min break and given the last 30 seconds of each meeting to ask my own questions. Then when I was called in for the 3rd interview, my mind was made up, which is the experience I'll use as an example here. For the cost of a few hours of my life (the 3rd interview) and something to reflect on, it turned into a gold mind of "How not to interview software people". Everyone was late, there was no interview process, I'd been given the wr

1. It will reduce costs, it's cheaper  It's most common excuse I hear, it's also typically the most short sighted, and most that likens software development to manufacturing widgets. Firstly creating software isn't akin to producing widgets , it's a creative process that depends highly on communication, and the quality of that communication. I don't just mean spoken language there, as the issues with that are all but obvious, but cultural as well. The culture and approach of the company, as well as the work ethics of the teams must be the same, or there will be a lot of friction. The speed that decisions can be made and acted on , are dependent one two things. Firstly on how they decisions are actually made  (i.e. process, hence why smaller teams with less management overhead and programmer lead projects will always beat the top down meeting driven interruption culture of bigger organisations ). Though secondly and that which has more importance here i

How do you log a lot of data without killing your limited setup ? But how can you scale the system or change components easily, i.e. have good architecture ? How to not over load production databases, so logging kills the actual system you're running ? Questions I've dealt with a few times, and a pet project for logging on a game I'm building that I thought I'd share. The situation You've been told to report on " everything " though not given the kind of back-end (or cash) that Facebook/Google/Amazon have for systems like MapReduce or Pentaho. You have at least one server (virtual or real) for "reporting", or at least an allowance of processing time and storage some where. Though if the systems gets big you want to be able to swap out the back end or add more capacity without having to do anything in the application. There are likely some front end machine(s) doing some kind of scripted work, for an application or game (LAMP in this