Øyvind Bakksjø: The inverse of IoC is Control - a well-founded criticism of the (over)use of inversion-of-control containers such as Spring and Guice. Bakksjø isn't against dependency injection in general but he prefers to do it manually, instead of magically, in a main method, using Java instead of an obscure DSL/XML. The dependencies are typically known at compile time so why postpone assembling (and defect discovery) to runtime? Why hide how parts fit together into the non-transparent magic of IoC? He has many good points though I believe there are cases when some automation of the wiring process is valuable (think of scope-dependant beans, diff. deps in diff. environments etc.) Comment by B. Borud: "Explicit wiring you can read from start to finish beats vague declarative shit that you may be able to figure out if you pay close attention." Check out also the comments at HN.
J. B. Rainsberger: Demystifying the Dependency Inversion Principle - a very good explanation of the value of dependency injection in the terms of general good code principles (promoting abstractions and postponing determination of details to the latest moment/client)
CodingHorror: Coding Without Comments (2008) - a very good explanation if how to treat comments (similar what Clean Code says): write code so that it is self-explanatory (using good method and variable names), if necessary, add comments that explain why (while the code shows what/how).
Frustrations and Aspirations of a Software Craftsman - what makes us happy or unhappy on a project? (I could add some too.) Bad: bureaucracy, old/unfit technology, lack of autonomy and credibility, uninteresting domain, demotivated people, blaming and highly competitive environment, arrogant and unskilled people, ... => it is mostly about people. Good: projects where there is passion, craftsmanship, friendship and trust.
Jetty-9 goes fast with Mechanical Sympathy - interesting how the run-time behavior might differ from what we would expect and how knowing the hardware can improve performance. Here: false sharing of a blocking queue's head/tail pointers and locks (close => same CPU cache row => updating one invalidates the other), using trie backed directly by IO buffers for faster String lookups etc. Result (all microbenchmark disclaimers): jetty-9 out performs jetty-8 by 30% faster and 50% less YG garbage.
Czech
Daniel Kolman: Jak správně pojmenovat test - a good description of different approaches to name and organize tests w.r.t. the experience of the developer - starting with "testWorks1" through one method-one test with "testMyMethodName" through a more thoughtful naming scheme such as Roy Osherove's UnitOfWork_StateUnderTest_ExpectedBehavior (e.g. ndexOf_containsSearchedString_returnsCorrectIndex) to tests as a living documentation: tests represent a list of features of the class, each name is a sentence having the class under test as its subject (e.g. [list] holdsItemsInTheOrderTheyWereAdded). Advantages of the latter: readability, documentation, it forces us to think what actually is still the responsability of the class and what isn't. "Stačí názvům testů věnovat dostatečnou pozornost a ony vám samy napoví, kdy už toho třída dělá moc a měli byste se zamyslet, jak kód lépe rozdělit."
Non-IT
Why You Should Work With Someone You Hate - working with people we like and do not have conflicts with is nice but we are likely to have similar views and ideas and miss the broader picture. Working with somebody that drives you crazy while being able to respect each other is very valuable because it opens you to different views and forces you to really defend yours. Recommended!
Kent Beck: Focusing Talks: Three Questions - some good advices for performing technical talks and avoiding putting too much into the talk. Ask 1) Who is the audience? - be as specific and narrow as possible to be able to tune and cut the content; "Better to reach one person than zero." 2) What is my one startling sentence? - one that makes the audience take notice; "Picking one sentence, I encourage focus and empathy in myself. Now I have one person's attention. What do I say?" 3) What would I like the audience to do? "'To what purpose?' helps me discard interesting-but-tangential points, to, as Peter Jackson put it, move the ring." "The more clear and uncompromising I can be with the three questions, though, the easier all the rest of it becomes." "Talk about less. And less. Less than that."
Clojure Corner
Clojure's Reader is Unsafe (for untrusted strings) - don't use read-string to read untrusted strings - even if you set *read-eval* to false, it can still be persuaded to execute arbitrary code (hopefully fixed in Clojure 1.5). The right, save way is to use clojure.tools.reader.edn/read-string.