Hi! I'm currently reworking my site, so although this content is still online things may change or look odd. Please get in touch to find out how I can help you!
CodeIgniter Conference 2012
I love CodeIgniter. So when I found out there was a two-day conference dedicated to it in my home town, it frankly would have been rude not to have turned up.
Codeigniter Conference 2012 (or CICONF, from now on) featured talks from people like Phil Sturgeon, Jamie Rumbelow and Harro 'WanWizard' Verton, who should be familiar to anyone who's worked with CodeIgniter or visited the forums.
The talks were all CI related of course, but the overriding theme of the day was "how can we do cool stuff with CodeIgniter?" - there were talks about why CI is great for building APIs, how to use MongoDB with CI and how to get PHPUnit and CI running together for proper unit testing, as well as more generalised talks extolling the virtues of CI and sharing some useful hints and tips.
Talk Highlights
The talks were all interesting and useful, but the few I've picked out below were really the stars of the show for me.
Nick Jackson - API-Driven Development
If you haven't heard of API-driven development (aka "eating your own dog food") before, it's quite simple. Instead of building a cool web service and then tagging an API on later in response to user demands, the idea is that you build the API first, then build your application on top of it. That eliminates a lot of the gripes people have with APIs - unreliability, bugs, glacial development for example- because the API is automatically a first-priority concern.
It's not worthwhile for smaller projects obviously, but if you think you might need an API at some stage, it's probably better to bake it in from the start than try to muddle one together as an afterthought.
The reason CodeIgniter works well for API-driven development is that it has lots of useful libraries and helpers that take care of things like authentication, plus the MVC pattern already has you thinking the right way in terms of separating your domain logic, data handling and presentation.
Nick also shared a few useful tips, such as the fact that you can use CI's built-in form validation library to validate incoming API calls which saves a lot of development time over rolling your own validation.
John Crepezzi - Unit Testing with CodeIgniter
Unit testing is like exercising regularly and having a healthy diet - we know we should do it and that the benefits are numerous, but breaking the inertia of inaction can be very difficult.
John's talk was mainly a beginner's guide to unit testing with PHPUnit, peppered with CI-specific tips.
The thing I really liked about John's talk was that it made it feel very easy to get started with unit testing in CI - even if you have no unit tests on a big code base, you could start by just adding a few tests to your models, or you could just write a few very general "smoke tests" - does it work, yes or no?
Adding unit tests to my base (or "skeleton") project has been on my to-do list for a while now but John's talk has inspired me so when I get some time to do it I'll give it a try. It would certainly be a nice feeling to embark on new projects knowing the basics are in place so that I can add unit tests for important stuff without having to do a whole bunch of setup each time.
Alex Bilbie - Introduction to MongoDB
Before CICONF I'd heard of MongoDB but if I'm honest, wasn't quite sure what it was for or how I would use it in a project.
Luckily for me, Alex did a stirling job of explaining the concepts behind Mongo and its pros and cons for different systems.
Essentially Mongo bridges the gap between traditional relation databases and key-value stores. Instead of rows you have documents, and instead of tables you have collections.
One of the coolest things about Mongo (in my opinion anyway!) is that it is schemaless, which means you're not restricted to a certain set of fields. For example, if I run an online store selling books, DVDs and CDs, the data I might want to store that relates to a DVD won't map exactly to the data I want to store about a book or a CD. In MySQL I would either have to have separate tables and join them, or store them in a single table but with loads of fields, most of which would be empty. In Mongo, I store them in a single collection and each document would contain just the fields relevant for the item it represents.
Another nice thing about documents is that you can store arrays inside the JSON-style objects that actually hold the data, so you don't need link tables like you would in a relational system - for example if I wanted to store different tags that applied to the items in my store.
Mongo also makes it easy to replicate your database as a backup, or shard it if you need to load-balance.
It's not all gravy though. Mongo doesn't have transactions or joins so that automatically precludes it from being used for stuff like billing. There are workarounds, and you can even use Mongo and a traditional SQL database alongside each other, but obviously different projects will have different requirements.
Mongo looks like good fun to work with so I'm glad Alex's talk has helped me add it to my list of possible things to use.
Jamie Rumbelow - Who Needs Ruby?
Jamie is someone who's had a big influence on the way I use CodeIgniter so quite a bit of his talk was stuff I already knew or practiced, but it was great to see how passionate he is about what he does and he was probably the best "performer" of the conference.
One thing Jamie talked about that I hadn't thought about previously was the idea of having form validation rules in the model rather than the controller. It makes sense when you think about it, because the rules relate to the data, and putting them in the model keeps the data logic in the model. You have to use a slight hack to do it (manually map your data back to the $_POST
server variable) but it's not a heinous crime.
Another thing Jamie talked about that I've "kinda" been doing for a while without realising was presenters. The idea is that you add an extra layer between the model and the view, so your view gets its data from the presenter rather than the model itself. What this does is cleans a lot of the logic out of your views and makes it easier to maintain down the line. It also means you're sticking to the "tell, don't ask" principle of telling your presenter what you want from it and letting it decide what to return rather than asking a whole bunch of questions about what it can give you.
The Social
As with any conference there was a healthy social scene as well as the "work" part. I missed the organised evening activities sadly but I managed to get a good bit of pub time in and hang out with people like Adam, Jamie, Ian and Andy which was great fun.
One thing that was nice was that we were already in central London so we could see a few sights in between pubs and restaurants - on the Saturday lunchtime I even managed to have a quick wander around an art exhibition!
Next time I'll have to make sure my calendar is clear and go the whole hog with the social, from the stories I heard the people who went out on the town had a whale of a time!
Overall
In my books CICONF 2012 was a very enjoyable experience - I managed to learn a lot and have a good time too. I would have preferred it to be in the week rather than on a weekend as I need to give my brain a bit of downtime but it wasn't as strenuous as a working day so it wasn't really a hardship.
I'm looking forward to seeing what Phil and co. can come up with for CICONF 2013!
Posted on Wednesday, 7th March 2012.
Feedback
Sorry, feedback is now closed on this post, but please feel free to get in touch if you would like to talk about it!