I love personal annual report season. Nicholas Felton's (feltron.com) and Jehiah's are the two that I've been looking at the longest.
The amount of work that goes into these — being thorough when collecting the data throughout the year and putting it together in a nice package at the end — is too daunting for me to consider, so I like observing and admiring the odd minutiae of the lives of those willing and able to put in the work.
"… as soon as I saw 'the slow web movement,' I assigned my own meaning to it. Because it’s a great name, and great names are like knots—they’re woven from the same stringy material as other words, but in their particular arrangement, they catch, become junctions to which new threads arrive, from which other threads depart."
Nice. It does seem like one of the lighter-weight Python web frameworks might fit in better with the overall theme of this intro, and Flask is a great choice.
I thought about doing the same thing as I read through it.
I'm still confused. I'm neither an iOS nor and Android developer, so maybe this is not a confusing situation to them. But:
> What we mean by single backend is you can have one backend and you don't need to know whether you are on an Android or iOS platform. You get the same analytics.
I can't fathom why a backend service would ever not work this way.
Kind of strange title, to me. I don't know why anyone would ever create separate server-side backends for different mobile platforms. I guess this just means that this company is providing libraries for both Android and iOS? Are the other "easy mobile app backend" services focused strictly on one platform or the other?
> _I think this is the current problem with mobile web apps today; too many are trying to feel native. Instead try to make it feel smooth and responsive, as a web app._
I think this is exactly what OP has done. It doesn't feel "native" to iOS to me, but it does feel like a well-made little web app. I don't have an Android device to test it on, but it does seem like it would fit in just fine on one.
That's a pretty good approach. I guess the main drawback is that the git commit hash will change far more often than the contents of most of the static files, though, right?
Ahhh, thanks for the details. The only solution I could think of involved writing out a dict like you're describing and using a template helper to look up the modified asset filenames. I was wondering if there was a more elegant solution that was escaping me.
And it probably would've taken me a little while to realize that I'd need to rewrite CSS files as well, so thanks for that, too!
I like this approach to static assets, where each file's name is changed to include the hash of the file's contents on deployment. But I've never implemented it myself, because I can't figure out a good way to refer to those static assets in my templates.
simonw, if you're listening, how do you solve this problem?
"That cover is NOT the original photo, downsampled. It’s a hand-crafted, precisely drawn interpretation of the source. Anyone who’s ever seriously put pixels to screen will tell you that this is an actual artistic method, one with its own challenges, tricks, and yes, an aesthetic."
The amount of work that goes into these — being thorough when collecting the data throughout the year and putting it together in a nice package at the end — is too daunting for me to consider, so I like observing and admiring the odd minutiae of the lives of those willing and able to put in the work.