The Value and Perils of Performance Benchmarks in the Wake of TechEmpower's Web Framework Benchmark
Benchmarks are important for rational technological choices yet it is very hard if not impossible to perform them in a sensible way.
I would like to record here some of the important points, mainly as a future reference for myself for whenever I will be dealing with benchmarking.
Continue reading →
Most interesting links of Mars '13
Recommended Readings
A lot of stuff this month since I have finally got time to review some older articles. Quite a few articles by Fowler. Few really great (yet short) talks on agile & SW development.Continue reading →
Tools for Editor - Browser Integration for Interactive JS/HTML Development
These tools usually use either remoting capabilities of the browser or a long-polling connection to the web site, sending and executing JavaScript.
Continue reading →
Markdown + JavaScript = Great HTML Presentation Decks
Continue reading →
Escaping the Zabbix UI pain: How to create a combined graph for a number of hosts using the Zabbix API
This post will answer two questions:
- How to display the same item, f.ex. Processor load, for a number of hosts on the same graph
- How to avoid getting crazy from all the slow clicking in the Zabbix UI by using its API
The problem we want to solve is to create a graph that plots the same item for a number of hosts that all are from the same Host group but not all hosts in the group should be included.
Continue reading →
You are not lean unless you have a clear objective and measure
Without a clear objective you cannot be lean.
Continue reading →
From Stateful Iteration in Python to Stateless Clojure
Continue reading →
Books Our Developers Should Read
There are a few books that every developer in Iterate should read because they express what we believe in and are extremely valuable in themselves. The books chosen are generally and broadly useful and not tied to some too limited domain (contrary to e.g. Effective Java). The list is kept as short as possible, about 4-5 books, and is revised regularly.
Why particularly these books, why lean and agile? Our people are primarily responsible for crafting solutions for our clients, for making sure that they use the customers' limited resources efficiently to produce the maximal business value possible. However, according to our experience, it is never truly known upfront where that value lies. Software development is therefore inherently a learning and exploration process. A process that needs to be continually adjusted based on empirical feedback from the reality and on shifting conditions. This is what lean is about: eliminating waste, maximizing value by maximizing learning, making sure that the right product is built. We value software craftmanship and building things right - but building the right things is crucial.
Here are the books and why we believe they are so important.
Continue reading →
Most interesting links of February '13
Recommended Readings
- Ø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.
Continue reading →
JDBC: What resources you have to close and when?
In JDBC there are several kinds of resources that ideally should be closed after use. Even though every Statement and PreparedStatement is specified to be implicitly closed when the Connection object is closed, you can't be guaranteed when (or if) this happens, especially if it's used with connection pooling. You should explicitly close your Statement and PreparedStatement objects to be sure. ResultSet objects might also be an issue, but as they are guaranteed to be closed when the corresponding Statement/PreparedStatement object is closed, you can usually disregard it.
Continue reading →
Most interesting links of January '13
Recommended Readings
VariousContinue reading →
The Sprinting Centipede Strategy: How to Improve Software Without Breaking It
Our code has been broken for weeks. Compiler errors, failing tests, incorrect behavior plagued our team. Why? Because we have been struck by a Blind Frog Leap. By doing multiple concurrent changes to a key component in the hope of improving it, we have leaped far away from its ugly but stable and working state into the marshes of brokenness. Our best intentions have brought havoc upon us, something expected to be a few man-days work has paralized us for over a month until the changes were finally reverted (for the time being).
Lessons learned: Avoid Frog Leaps. Follow instead Kent Beck's strategy of Sprinting Centipede - proceed in small, safe steps, that don't break the code. Deploy it to production often, preferably daily, to force yourself to really small and really safe changes. Do not change multiple unrelated things at the same time. Don't assume that you know how the code works. Don't assume that your intended change is a simple one. Test thoroughly (and don't trust your test suite overly). Let the computer give you feedback and hard facts about your changes - by running tests, by executing the code, by running the code in production.
Continue reading →
Bash: Parse Options And Non-Options With Getopts
getopts
Continue reading →
Bash Magic: List Hive Table Sizes in GB
sudo -u hdfs hadoop fs -du /user/hive/warehouse/ | awk '/^[0-9]+/ { print int($1/(1024**3)) " [GB]\t" $2 }'
Continue reading →
Fast Code To Production Cycle Matters: For Pleasure, Productivity, Profit
Continue reading →