The Manifesto of Mike Pearce
Polling Station by hugovk
There’s an election around the corner and I thought I would jump on the bandwagon and outline, with little detail, my manifesto so, should you arrive at your polling staton on the 6th May, step into the wooden voting booth with your Crayola number #000 and your little slip of neutrally coloured paper to find my avatar beaming at you from the page, you’ll know who to vote for *wink, wink*.
So, without further ado, the Manifesto of Mike Pearce
- I shall ensure that all developers adhere to a consitent indenting style. This shall shall be decided by the house over some months of debate no doubt.
- The house shall also debate about the location of braces (or curly brackets). New line or not.
- I shall ensure that people who call an ip address someone “Intellectual Property Address” have no place in my cabinet.
- Bigots will be welcomed.
- A law will be passed that states you can use any IDE you want to. Including vi.
- … except Nano. That is for losers.
- Perl will be struck from the list of languages and no one will be required to write, or learn it ever. In the words of @nefarioustim: “@->$_ {} ? FUCK OFF”
- A Quango will be setup to refactor PHP so that all assignments are done with $var = method($x); and not method($x, $var) as that is suck.
- Independant analysis will decide whether Python Eggs are worth the hassle.
- All code written, ever, will be peer reviewed.
- Any engineer or developer writing code that isn’t documented will be thrown into The Grand Hotel, Room infinity+n for ever (this is not as nice as it sounds, seriously).
- Script writers for TV and Film will be required to submit any scenes that involve computers, programming or other technology to a jury of geeks in order that I don’t have to sit through another film while my peers snort at characters programming with a green screen, on an iPad, with a projected keyboard and mouse-glove.
- Ruby shall be renamed to something that doesn’t sound posher than all the other languages, then Ruby developers can take their heads out of their arses and join the rest of us proletariat devs.
Clearly this is all based around software engineering and development. I have neglected to add anything about Real Ale, Curry or Inline skaters.
Scrummaster? We don’t need no steenking Scrummaster!
A Sad Face by Emmaline
I discovered something strange today. I recently left one development team to go work for another (that’s for a seperate blog post all together) and I was chatting to some old team members today who had just had their Scrum Sprint Review/Retrospective and they mentioned one of the things that had come out of the Retrospective was that they aren’t going to have a Scrum Master for this sprint, or, it seems, any sprint.
“Huzzah!” I hear you cheer! “They must be self-managing!”
No, no they are not. It’s far, far worse than that. They’ve decided they don’t need a scrum master as, in their experience, the scrum master is useless. With no power to help the team make decisions and one team member describing the Scrum Master as “a puppet of the business”, then it’s quite clear that scrum, at this company, is broken.
It’s a sad day for me as ever since I heard about scrum about two and a half years ago from a colleague (@garethholt), I realised it’s potential. I’ve tried hard, arguing the point with colleagues, management and everyone who’ll listen. We’ve tried different length sprints, staggered sprints, digital backlogs, analogue backlogs, all sorts. Inspected and adapted and now it’s all for nowt. At every turn, the business said “No, I’m not confident enough to try scrum properly.” or, more accurately, “I don’t want to surface the organisational dysfunction.”. The team realises that the business cannot let go of the reigns.
It’s all about trust.
They all seem like the wind has been taken from their sails and it’s sad and dissapointing. Especially as they have an ‘Agile Manager’ and a ‘Product Owner’ who is also a director. Even the people employed to support scrum don’t seem to have confidence in it. Now THAT is a problem.
I might go home and cry.
Making sure your API doesn’t suck
A Phalanger - a type of possum. Awesome.
I’ve recently had the displeasure of working with an API published by one of our service providers. I won’t name names as it’d be a little embarassing, but we provision a lot of something from then and then those somethings are used and the provider records their use. The API exposes both the ability to manage these somethings and the ability to report on their use.
There’s a great REST book by the lovely people at O’Reilly (it has a Phalanger on the cover) which describe the best practices for building a RESTful API. There’s a lot covered in the book and I won’t go into it all here. However, there are some lessons to be learned from the book and from using APIs in general about writing an API, even if it isn’t restful.
Here is a (non-exhaustive) list of things to do to make sure your API doesn’t suck:
- Don’t return HTTP 200 OK for EVERY response. If the query to the API fails, send an appropriate response code.
- If you are COMPLETELY unable to send different response codes to describe the outcome of the request, make sure you send SOMETHING to the client so they know the status.
- Make sure this SOMETHING is documented.
- Try and return JUST ONE type of response. If XML, then just send XML. (Bonus tip: Don’t send XML with a plain text header, it’ll annoy your clients).
- Don’t send mixed responses. For example; if your documentation states the client can request a CSV, send a CSV, don’t send the error as XML and the CSV as success. If it doesn’t work, send an appropriate HTTP response … oh, right…
- Document stuff.
- Don’t describe methods in the URL: http://apiurl.com/_functionName(param1, param2, paramn) is NOT RESTful (and is stretching the description of API).
- Use POST, GET, UPDATE and DELETE properly and in context.
- Send API auth credentials with HTTP auth, not in the URL. They can be read in the logs.
- Try and make sure that upstream errors are reported faithfully by your API. No point in the API returning OK when the request IT made upstream failed. There’s no confidence in Confidence-Free-Town
There’s probably more, but that’s all I’ve uncovered when working with client APIs. Avoid those 10 items and you’ll be well on your way to writing an API that doesn’t suck!
Kohana: more than just a fork of Codeigniter
For a while now I’ve used EllisLab’s Codeigniter for quite a few projects. More recently, I’ve turned to Concrete5 as it allows both myself and my clients to edit “in-place” resulting in fewer support calls for me. However, I’ve still had a soft spot for Codeigniter as it does, indeed, allow for Rapid Application Development. But I’ve been using is long enough now to understand many of it’s foibles.
I made the mistake of forking my Codeigniter install early on as I wasn’t familiar with the framework and didn’t quite know how to get it to do what I wanted it to. This was a mistake as couldn’t then apply the security patches that EllisLab released, instead, I’d have to make them myself (although, I rarely did).
Recently, a friend of mine put me on to Kohana which is a fork of Codeigniter that is, in my opinion, fricking awesome. Imagine all the things that aren’t quite right in CI and Kohana has fixed them, including being more OO PHP (according to the website, it’s STRICT OO PHP!). It’s secure, lightweight and things you’re used to working with still work. CI removed the $_GET, $_POST and $_COOKIE vars for security, but it was a little irritating, Kohana puts them back. It uses autoloading and appropriately name classes. There are static classes, methods and objects where neccessary and it uses a cascading load heirarchy similar to CI, except this works. It looks for the thing you’re trying to load first in your “application” directory, then your “module” directory and finally, if all else fails in the core “system” directory. Sweet huh? Also, the event handler responds and reacts better as it’s using an observer pattern. More sweetness.
For me, the best part about it is that it just works, out of the box, with a little config, exactly how I want it to. I can access and reference objects, libraries and resources how I would expect without any framework particular nuances ($CI =& get_instance(); anyone)? It makes just dropping into it easy.
I expect that the lessons I’ve learnt while using CI and the fact that it’s fairly similar in structure to CI has helped me get going with Kohana quicker, but it doesn’t feel quite as much like I’m running uphill when developing with the framework.
As an example, I recently wrote an ACL service with a RESTful API for some of our applications at work and I wanted to use Kohana to build a customer portal, I added a new driver for the Auth module and duplicated the ORM auth driver methods with my own ACL methods, using my API instead of ORM (or files, which is the other default option). Everything was written, presented a structured how I would expect a PHP5 application to be and so it took me only about three hours to implment the whole thing. Awesomesauce.
So, in summary, if you’re looking for a new framework, or an alternative to Codeigniter, you’d do much worse than check out Kohana. The Kohana team are busy writing V3 (http://v3.kohanaphp.com/) but it isn’t quite ready yet. This looks to be even more kick-ass. More streamlined and uses the Zend style directory/filenaming structure. I’ll be checking this out when it’s released.
2 comments