There is this phenomenon in JS called “function hoisting.” It’s regarded as odd to newcomers but I found it improving code readability and use it every day.

On my front-end side-projects I mostly did test-first development and it worked pretty well. But for my new job that I began recently I found myself struggling really hard to do TDD, and eventually gave up and coded test-after.

One of the first things that I learned about CSS is that it cascades. Cascading is a lot like inheritance in OOP. It’s useful for the same reasons, and, for the same reasons leads to CSS fragility when misused.

6 weeks ago I have switched jobs. It’s a big change and it’s also good time to review other big things.

I use one non-academic guideline that helps me decide what and how to test in my code.

There was a video on TED called “The paradox of choice.” I have never agreed with this idea that more options make the choice harder. I have criticized it a while ago on Facebook, but today I share my understanding of its mechanics.

More than a few years ago I decided I want to work on my own business. I’ve been learning quite a few things from books, blogs, and podcasts, and even tried a few things. But I think today it has become clear to me that business ownership is not my thing.

I remember how amazed I was while reading Kent Beck’s “Test Driven Development: By Example.” Automated regression tests sounded very useful. But it was not obvious how to apply that in the context of web UIs.

In the last post on Travis Neilson’s mailing list, he’s sharing his thoughts about motivation and proposes some solutions.

In the episode 21 of “Giant Robots” podcast Jim Gay is invited to talk about the DCI concept. The original document explains it with an example about saving accounts. Jim tries to explain it with an app user. I find both examples somewhat unhelpful, and thinking about this subject a little more, I think I found a better one.