Tuesday, December 9, 2014

Caching & Naming: the Hardest Things About Programming?

I recently heard someone say: "The two hardest things about software engineering are caching & naming."

I've not learned much about caching, but am about to. The app I am working on was at one time running slow, so the agency decided it would be a good thing to implement caching for user images & data. They did a little overkill though, and have implemented several layers of it so it is affecting user experience. Plus, my company is spending too much on these services.

So, in order to help optimize the app and its caching, I'm reading this article and this article to start learning as much as I can about caching. If you can recommend any others, please do!

The naming thing I'm pretty comfortable with. If these two things are the hardest thing about software engineering, I got this.

I like this idea from a commenter on Steve Souder's blog, Cache is King:
"If you are combining all your JS into a single concat file, you are undoubtedly combining some code which is extremely stable (like a jQuery release which will never ever change) and some (maybe a lot) which is quite volatile (like your UX code you tweak frequently). If you only serve one file, you have to pick one caching length for all that code.  
If you split your JS into 2 chunks (the volatile chunk and the stable chunk), you can serve each with different caching length headers. When your UX code updates frequently, over time, repeat users on your site will not have to keep downloading all that stable code over and over again.  
I have done these things in production on large sites and I can attest time and again it helps. It helps big time. And it’s nice to see your real numbers research backing that up."