Often when using CSS transitions, I need to manipulate the same elements sometimes with transitions and sometimes without.
A simple example is moving an element off the page immediately, then transitioning it back in. Due to browsers compressing property changes behind the scenes, simply adding a “noAnimate” (transition: none) class, setting left, removing the class, then setting left again results in the element being in the right place, but without any transition.
I was previously told that the solution was to put the last two steps in a setTimeout callback – and that works. However the code quickly becomes messy in non-trivial situations. While reading today, I found that all that needs to be done is to force a redraw in between, which can be done by accessing the element’s offsetHeight.
Example here: http://jsfiddle.net/nzW24/
When sizing a cache such as Ehcache, back-of-envelope calculations is what’s often done. While it may well give the right answer, the envelope never seems to be kept so when someone comes along needing to modify/tweak the caching behaviour of the application they are faced with an ehcache.xml config file full of various numbers with no indication of why they were chosen.
This is often the case with many config files, but I’ve seen that ehcache.xmls are particularly prone to this (not anything to do with Ehcache, more the people who maintain them).
So I think it’s good to do what we did in a recent project, and document the choices of various settings with comments, and the calculations in a spreadsheet checked in to source control.
Some resources I found useful while calculating cache sizes:
I’d forgotten about this one until it caught me out again recently. I can see why it can’t be fixed though: putting an element with a null value is what you do to release the lock. Thankfully it’s easy to work around by using a plain object as a “null marker”. That does cause some boilerplate in methods that use the method though, so it might make sense to create a decorator that deals with this if you have a lot of it.
Next time I need some in memory caching though, I’ll be considering the Guava caches as quite often the capabilities of Ehcache aren’t required in applications that use it. I particularly like the fact that a self populating cache can bulk load using the CacheLoader.loadAll method, unlike Ehcache’s SelfPopulatingCache.
Dustin Marx shows how Java 7’s MethodHandles lookup functionality can be used to name loggers. Much less error prone than putting the class name in the code.