2013 in review: putting a framework next to the CMS
This was the year I stopped trying to make a content management system do things that are not content management. In January I started a project on a PHP framework instead, and the split has defined how I quote work ever since.
The rule I ended up with
If the client edits it, it belongs in the CMS. If the client only ever sees the result, it belongs in application code. Sounds obvious written down. It is not obvious at 22:00 when the fastest path is one more custom page type with eight fields nobody will ever fill in correctly.
Two long-running client platforms started this year, and both are the second kind: forms, calculations, imports, exports, PDFs. Building those inside a CMS means fighting the CMS. Building them next to it means writing normal code and letting the CMS keep the pages.
The framework parts that actually changed my day
Migrations. A schema in version control, applied in order, the same on my machine and the server. Before this I kept SQL files in a folder and a note about which ones I had run. I do not miss that.
A console command as a first-class thing. Import, cleanup, nightly job: same structure every time, testable, runnable by cron.
Dependency injection I did not have to build myself. Not because the pattern was new, but because it was suddenly cheaper to do the right thing than the wrong one.
And the CSS side: I tried SCSS
First .scss file in a repository this year. I did not commit to it, and I would spend the next
five years half in a preprocessor and half out of it. But nesting and variables were enough to
stop me writing the same six-line vendor-prefixed block by hand.
A side project, in December
Two days before Christmas I started a small project against a cryptocurrency API. I had been aware of that world for a while. What was new in late 2013 was the thought that I might build a trader: not read the numbers, but act on them automatically.
It never became one. But wanting to trade rather than display changes the engineering completely. A dashboard showing a stale price is mildly annoying. Something that places an order on a stale price is a different category of problem, and a stale value looks exactly like a fresh one unless you make it say otherwise.
So it forced habits I use constantly now on things that matter more: cache with an explicit age, carry the timestamp through to wherever the number is used, and refuse to act on a value you cannot vouch for. Rate limits, an API that is briefly down, a response that is technically valid and hours old. Ordinary integration work, learned on something where being wrong would have cost me my own money.
In short
Drew a line between what belongs in a CMS and what belongs in application code. First SCSS file, and a side project against a crypto API.