An interesting report, but I kept wondering about this:
Apple decided to go a step further and just begin hiring these creatives directly into Apple
What do these people actually work on? The story makes it clear it’s not Hollywood stuff (because they’re understandably hesitant to bring that work in to Apple), but then what? Does nothing actually come out of this and are these just the world’s most expensive testers?
A turn-by-turn description of how Julia Evans reverse engineered the proprietary image format used by the iOS Notability app.
As she says:
People don’t usually invent totally custom file formats! Nothing in here was really complicated – it was just some existing standard formats (zip! apple plist! an array of floats!) combined together in a pretty simple way.
Doing the Lord’s work (finding the perfect Unicode arrow to illustrate an external link), I stumbled upon ↯, which I can only assume is a tribute to Harry Potter.
An eBook by Addy Osmani on everything you could want to know, and then some, about the most efficient ways to serve images in browsers.
It serves to Google’s credit that existing goo.gl redirects will remain (for the time being…), but this is just another in a seemingly list of tales that all boil down to: You can’t trust Google with this sort of thing.
Fascinating story in The Blizzard (an excellent quarterly football publication for the uninitiated) about the takeover of Notts County.
The Kasper Schmeichel angle (and the general superstar allure of Eriksson and Campbell) meant it was covered in the Danish media, but I had always just assumed the funding dried up, not realising the extent of the scam.
Ned Batchelder on the grey zone between ‘interpreted’ and ‘compiled’ languages where Python (and most programming languages, really) is.
This is the sort of problem which on the surface seems so simple, but where the immediate solution is so wasteful, and can indeed be hard to pull off; my side project Oversigter has been doing this incorrectly for years.
The solution is elegant, although it can be difficult to pull off in practice if you don’t have a lot of control over your hosting environment, as I don’t where Oversigter is hosted.
Via Simon Willison
Back in the day, Django didn’t have a built-in way to change model schemas. You either had to figure out and apply the changes yourself or use a third party tool like South.
After a successful Kickstarter campaign, Andrew Godwin, Django core member and the author of South, added a native migration tool to Django. It solved problems such as conflicting merge names and the ability to squash migrations once there are too many of them in an app.
One thing it also changed is introduce what I have dubbed ‘cosmetic migrations’: these are migrations that make no changes to the database schema, but only add internal Django changes, such as changing a field’s
choices or the
ordering of a model. I’m sure the change is for good reason, but it annoys me to no end, because the lack of schema impact means I’m unlikely to notice that I haven’t made them until at some point I do make a schema-altering change, and that migration is then flooded with an untold number of cosmetic changes. This is a problem because commits should be atomic.
Django will occasionally notify you that ‘[y]our models have changes that are not yet reflected in a migration’, but I found that I would only see those when it was too late.
Thankfully, it is possible to make these checks yourself, although I have never seen it advertised anywhere. Executing this command will give your what you need:
$ python manage.py makemigrations --check
This command seems wholly counter-intuitive to me, but it does what I want: Exit with a code 1 if there are unreflected changes.
You can plug the above in to your Continuous Integration system or possibly a pre-commit hook. If you do so, I recommend that you also make it
--dry-run, like so:
$ python manage.py makemigrations --check --dry-run
This will ensure that no migrations are actually created, which just seems the saner option if you want to check.