I’m so angry about this content blog’s theme that inserts a loading screen after the page has loaded, hiding the page until it’s done showing that shitty spinner.
There are some interesting UX stories about having to insert an artificial spinner or loading bar to reinforce the idea that something important was going on behind the scenes. There’s no excuse for doing something like that on a stupid Tumblr theme, though.
I can’t understand why they don’t make pants that have a little fan built into the butthole area so you can use it to get rid of especially terrible farts or cool off and dry up your sweaty meat mouth when you’re on a steamy summer jog.
If you fund my Kickstarter…
Fuck you, Discourse. So now I have no idea how long the conversation actually is. I have no way of directly jumping to an arbitrary point in the conversation. If it’s a 1000 reply thread, I can’t read page 1, page 2— hop to page 50 to get an idea of the conversation flow, then jump straight to page 100 to see the latest posts. If I refresh the browser or navigate away accidentally, I lose my spot and have to start infinite-scrolling again. I can never use the scroll bar as a gague as to how far into a conversation I am. This is assuming you don’t fuck up scrolling like nearly ever infinite-scroll application I’ve ever used.
I also can’t just hit CTRL-END to jump to the end of a page.
You know what else provided “just in time” access to more posts? A FUCKING NEXT BUTTON!
- Lorne Kates of TDWTF on infinite scrolling
People who frequently work with HTML:
What’s your preferred style for multi-line comments?
Both of these look icky to me:
<!-- One one one one one one one one one one one one one one one one one one one one one --> <!-- Two two two two two two two two two two two two two two two two two two two two two two two two -->
I heard a while ago that on modern OS’s, a lot of cleanup is pointless and stupid.
That’s true, but I think the point of the article I found was that things like making sure all of the memory you allocated for an XML parser is free’d will waste a lot of cycles because you have to traverse the entire XML tree in order to ensure a proper clearance, and if the only reason you’re doing it is because your “close program” routine was called, that you’re programming against a case that just never exists in the real world.
In context, I seem to remember the specific complaint was Google Chrome crashing on exit because it was calling a lot of complicated clean-up code all at once, tying up the processor as well as causing some weird race conditions. I seem to remember the root cause of the crash in question was innocuous and irrelevant - some clean up code was being called twice (a fairly common mistake), but the author of the piece was using it to make a point about how much programmer and CPU time can be wasted when all of this complicated clean-up happens, and that some amount of prioritisation should really happen during an exit routine - files should be closed, driver resources should be freed, and notifications sent to any daemons that need to be aware of the shut down, but as in any other area of software development, duplication of efforts is a Bad Thing™, and in this case freeing process-specific (i.e. not shared) memory that doesn’t affect any other processes is a huge duplication of efforts, and the OS is probably a darn sight better than you are at it anyway.
Walter Bright wrote an interesting article on how he optimized the D compiler. He cited taking advantage of not having to “clean up” as one of the biggest boosts to performance.
DMD does memory allocation in a bit of a sneaky way. Since compilers are short-lived programs, and speed is of the essence, DMD just mallocs away, and never frees. This eliminates the scaffolding and complexity of figuring out who owns the memory and when it should be released. (It has the downside of consuming all the resources of your machine if the module being compiled is big enough.)
It’s like I poured nitrous down the compiler’s throat. Along with the other improvements, this achieved a near doubling of the compiler speed. (It even reduced the memory consumption somewhat, apparently because malloc() needed memory for its data structures.)
So, yeah, you’re right. Ironically, the stigma against “leaking” memory does often preclude speed, reliability and productivity.
# Prepends zeroes until input is the correct length fillZeroes = (input, intendedLength = 2) -> return ("0" for a in [1..intendedLength - ("" + input).length]).join("") + input
I love CoffeeScript so much
Why not just use one of these?
# Recursive version. # Slightly longer than the original, but probably more readable. fillZeroes = (input, intendedLength = 2) -> if input.length >= intendedLength then input else fillZeroes "0" + input, intendedLength # Iterative version. # Slightly shorter than the original, and also probably more readable. fillZeroes2 = (input, intendedLength = 2) -> input = "0" + input until input.length >= intendedLength; input