Most interesting links of September

Recommended Readings

• J. Yip: It’s Not Just Standing Up: Patterns for Daily Standup Meetings - it isn’t easy to make stand-up meetings short, focused, energizing, and centered around continuous improvements and team spirit. This description of an example good standup, the meeting’s goals, and especially the “patterns” and “bad smells” can be pretty useful to get and keep on the track towards a brighter future. TBD: standup goals: GIFTs, team spirit, appreciation where we go and are.
• M. Poppendieck: Don’t Separate Design from Implementation – according to Mary, (detailed) requirements – being it in the form of (backlog) user stories or any other – represent actually a design of the system, which shouldn’t be done by the amateur product owner/business analyst but by professionals, meaning the developers, based on high-level goals and clear specification of the desired business value. She writes about a project that her factory outsourced and which she could have designed but didn’t – yet it succeeded even though there were no detailed requirements. I’ve also read and unfortunately lost an interesting answer where the author argues that that is only possible if the developers are really experienced in the field. I tend to agree more with Mary though it is of course a question what “high” and “low” level goals/requirements are. But undeniably users/analysts tend to propose solutions disguised as requirements while often missing the technical insight to see possible other and better solutions. We also cannot expect the developers to produce a great SW if the true goals, needs, and business values behind the requested “features” aren’t clearly communicated to them. (The best example – lost source again – is where a developer proposes to the client a simple process change that will solve the problem without writing a single line of code.)
• Mike Cohn: The Forgotten Layer of the Test Automation Pyramid – three levels of testing with increasing number of tests: UI/Service/Unit (or end-to-end instead of UI), each requiring a different approach. Unit tests are best because a failure points directly to its source (with higher level tests you don’t immediately know the cause). The higher in the pyramid, the less tests we should have (e.g. because of their redundancy). It’s important not to forget the middle, service layer – unit tests are too low-level, UI tests too difficult and brittle. Also Gojko in Specification by Examples says that acceptance/BDD tests should run mainly at the service layer because of the UI level issues.
  “Although automated unit testing is wonderful, it can cover only so much of an application’s testing needs. Without service-level testing to fill the gap between unit and user interface testing, all other testing ends up being performed through the user interface, resulting in tests that are expensive to run, expensive to write, and brittle.” [Emphasis JH.]
• Technical Debt and the Lean Startup – Paul Dyson remarks that while quality is an essential concern for projects in established environments, in the case of lean startups the primary goal is to find out whether a product is viable and what it should be like and thus it’s reasonable to accept much higher technical debt by not spending too much time on ensuring scalability, de-duplication etc. – only when the product proves viable should we start to care for its long-evity by emphasizing the quality. But one thing can never miss and that is good test suite because this is the crucial factor that makes letter payment of the technical debt possible without ruining oneself.
• Coding dojo – Real time coding competition with Extreme Startup – an inspiring report about a coding dojo lead by Johannes Brodwall in Bergen’s JUG, the task being the implementation of a server that can respond to questions send over HTTP (that’s all participants know at the beginning – they learn the rest during the iterations)
• Using Code Katas to Improve Programming Skills – why to use code katas + links to different proposed katas
• Kent Beck: Don’t Cross the Beams: Avoiding Interference Between Horizontal and Vertical Refactorings - when to do depth-first (more exploratory) refactoring and when to extend it into breadth (i.e. apply it to several similar objects)

Learning Clojure (maybe not so interesting for those not learning the language)

• Phil Calçado: My Experience With TDD In Clojure (via planetclojure) – nice example of how to decompose a task in functional programming to make it easy to test (via Midje), including useful testing-related links and a discussion of side-effect isolation and the building blocks of functional programs, i.e. function composition using combinators (i.e. functions producing functions)
• How to learn Clojure effectively (via planetclojure) – a very good description of how the task at  4Clojure (though I prefer Clojure koans) should be solved to benefit one’s learning the most plus some general tips on functional thinking
• Clojure open source projects for learning how to code it

Most interesting links of June

Recommanded Readings

• Empirical Studies Show Test Driven Development Improves Quality – brief summary of two researche papers comparing TDD/non-TDD, one paper with 1 case study from IBM and 3 from Microsoft (get PDF; conclusion: The pre-release defect density of the four products, measured as defects per thousand lines of code, decreased between 40% and 90% relative to the projects that did not use TDD. The teams’ management reported subjectively a 15–35% increase in initial development time for the teams using TDD, though the teams agreed that this was offset by reduced maintenance costs.), one older summarizing 13 case studies (conclusion: TDD seems to improve software quality, [...] there were indications that TDD does not necessarily decrease the developer productivity or extend the project leadtimes: In some cases, significant productivity improvements were achieved [...] However, in both of those studies the quality was improved.).
• Quantum computers are reality: World’s first commercial quantum computer sold to Lockheed Martin – this means that hard and NP-hard problems become solvable or at least much easier to solve (this means incredibly lot, just think about optimization problems, scientific computations and simulations, …) and that current security measures are becoming obsolete. It has “only” 128 qubits, which sounds small but is a big thing (competitive regime for quantum comp. is about 100).
• Fit co-author says acceptance testing costs more then it is worth (i.e. there are better alternatives) – it’s always good to learn from failures; the author, James Shore, has several pleas against A.T.: “[..] customers (a) weren’t interested in doing that, and (b) often couldn’t understand and didn’t trust tests that were written by others. [..] Furthermore, acceptance testing tools are almost invariably used to create end-to-end integration tests, which are slow and brittle. Fit works best for targeted tests that describe the domain, but that’s not how it’s used. Also, tools like Fit [JH: which is based on HTML] don’t work with refactoring tools.“, summarized: non-participation of customers and maintenance burden. Gojko Adzic opposes that we can avoid the pitfalls while retaining the benefits – I guess his Specification by Example book is quite lot about this, as well as the last month mentioned post Top 10 reasons why teams fail with AT

Favourite Quotes

Unit tests, [..], are so coupled to the low-level API that it is often hard for the developers to avoid the trap of proving that the solution works in a particular way, rather than asserting that is solves a particular problem.

- from the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, published in an InformIT article

Most interesting links of January

I’m moving to Norway and have thus little time for reading but still I’ve stumbled upon something really interesting.

• Bob C. Martin (the Clean Code guy): The Transformation Priority Premise – with TDD the code goes through a series of transformations (similar to refactorings but they change the behaviour) that “move the code from a specific form to a more generic form” (from “return 0;” to “return myFunc();”). “It also appears that these transformations have a preferred order based on complexity.” (nothing => simple code with null; null => constant; …). “It is the premise of this blog that if tests are chosen and implemented in this preferred order of transformations, then TDD impasses will be reduced or eliminated.“
  Also the article explains nicely why the practice of writting simple, wrong (i.e. too specific) code is good. 
  • Uncle Bob’s TDD excercises (katas): Prime Factors kata (as .ppt), The Bowling Game Kata (as .ppt)
• 10 Tips for Proper Application Logging – should be rather called 10 best practices for (enterprise Java) logging
• Kanban Development Oversimplified – finally an explanation of Kanban for SW development I could understand, also thanks to the comparison with other agile approaches

Most interesting links of November

This month has been quite interesting, among others I ‘ve picked up several blogs by Adam Bien. I really like his brief, practical and insightful posts

Java, Jave EE, architecture etc.

• EJB 3.1 + Hessian = (Almost) Perfect Binary Remoting – “With hessian it is very easy to expose existing Java-interfaces with almost no overhead. Hessian is also extremely (better than IIOP and far better than SOAP) fast and scalable.” See also the discussion regarding a “DynamicHessianServlet” (which would be more comfortable then creating a new servlet for each service).
• Binary XML – Fast Infoset performance results – FI is the name of a standard for binary XML encoding and also of its OSS implementation; according to these measurements (with default settings, compared to Xerces 2.7.1), on average: The FI SAX parser  is about 5 times faster than the Xerces SAX parser, the FI DOM serializer (using default settings) is 25% to 30% faster than the Xerces DOM XMLSerializer, and FI documents are 40% to 60% smaller than XML documents (i.e. it can provide modest to good compression). And: “The use of external vocabularies can be a very effective way to increase the efficiency of parsing, serializing and size at the expense of the fast infoset documents no longer being self-describing … .”
  For the interested ones: FI is built on ASN.1, a standard for describing data structures in a way that is independent of machine architecture and implementation language, it also includes a selection on different binary encoding rules, e.g. DER (triplets tag id – length – value).
• EJB 3.1 And REST – The Lightweight Hybrid – Why to use @Stateless – there have been recently discussion about Spring vs. EJB and whether @Stateless is of any use. According to this article, the added value of EJB (though some are provided also by Spring) include injection capabilities, transactions, single threading model (for why that is good see #2 on Why I like EJB 3.0/3.1), visibility in JMX, concurrency restriction via thread/bean pools.
• Why Service Isn’t A ServiceFacade, But ServiceFacade Is Sometimes A Service…
• Experiences from migrating Hyperic 4.5 from EJB/JBoss to Spring/Tomcat, what good has it brought – simplified unit and integration tests, simplified code thanks to Jdbc/JmsTemplate, … (My comment: EJB 3.1 would certainly bring at least some of the advantages too.)

Performance – large JVM heaps are very much feasible

• Tuning the IBM JVM for large heaps – tuning 64b IBM JVM 6 with 100GB heap to have acceptable GC times (~ 1/2s as opposed to 25s with the default settings)
• BigMemory: Heap Envy – there have been recently a lot of fuss about Terracotta’s new BigMemory, a  GC-resistent many GB cache space (using NIO byte buffer). This post discusses it’s disadvantages and compares it with a solution based on ConcurrentHashMap, comming to the conclusion that the old good ConcurrentHashMap outperforms BigMemory considerably.

Other

• Mind-breaking TDD exercise – Thought-provoking TDD exercise at the Software Craftsmanship conference – a TDD exercise with strict rules requiring to only write implementation in the test itself and then refactor it out as needed. I’d strongly suggest that you try to do it by yourself. There is a more detailed report from a tic-tac-toe version and a bit about implementing a message interceptor in this way. An interesting observation: “differences from a pre-conceived design and the one that emerges from code are considerable, the latter being a lot more elegant and better suited to describe a problem.“
• To code quickly, you must quit coding (Pomodoro etc.) – why Pomodoro technique (concentrate 25m on work rejecting interruptions, then take a break) and similar ones work
• Colorize Maven output in Linux/bash via filtering of Maven’s mvn command output using sed. (Thanks to Alda for the link.)

Most interesting links of October

Few of my favourite themes this month – TDD, performance, build tools/Maven. Plus a usefel JS library, news from the Java community x Oracle world etc.

• About dying JCP and too silent Oracle (or mostly silent) – a summary of the latest issues and hot topics in the Java community that cause lot of rumor but still no reaction from Oracle including the criticism of JCP and its proclaimed decline. Update 11/1: The article about IBM, Oracle and OpenJDK has links to many related resources and a section on JCP future.
• A fair evaluation of TDD – Test driven development at Transloadit (“honest assessment of the beauty and pain of tdd” – Kent Beck) – according to the author, TDD requires a lot of discipline and is a pain to do but it really pays off if your risks are high, basically it’s something like an insurance – there are people living without it but to some it can save life. I miss there a thing I find essential about good test coverage – namely that it forces you to write a better code (more modular, following the single responsibility principle etc.).
• Dear Javascript Guru: Please Stop Using The Hash Symbol For No-Op HREFs – don’t use href=”#” for it modifies the browsing history and makes the browser scroll to the top. Prefer <a href=”javascript:void(0);” … > or just use the javascript: protocol for a function call that returns false (you can force it like this: <a href=”javascript:doSomething(); void(0);”>).
• Why Hibernate 4 switches to Gradle instead of Maven 3 – “a means to describe the issues and frustrations I have seen in my 2.5+ years of using Maven for Hibernate builds; in many cases the cause is simply an assumption or concept in Maven itself which did not line up cleanly with how I wanted to do build stuff in Hibernate.” The main issues were that Hibernate is a very specific project, which doesn’t line up very well with the Maven philosophy and, at the same time, Maven is very strict at forcing it and not really flexible to accommodate to unusual needs (and if Maven is, its plugin often aren’t). For example Hibernate is composed of modules that depend on each other while Maven really supports only an aggregation of independent projects. Also, “the release plugin is completely worthless”. On the other hand, Gradle is very flexible and – among others – offers powerful scripting, doesn’t enforce its way of doing things at all cost (i.e. directory structure), let you also define dependencies on tasks, modules, directories, etc.
• Flot – JavaScript plotting library for jQuery, which has replaced Flash at WordPress.com (so it must be really good!) for blog statistics visualization. Main points: simple usage (all settings are optional), attractive looks and interactive features like zooming and mouse tracking. Really nice one! Check Flot examples.
• String Concatenation Performance vs. String Builder/Buffer and how Liferay 6 achieved a speedup by not using S.B. [that much] – StringBuilder/Buffer has lot of overhead and thus String.concat or custom code can be faster sometimes. Also see the linked ticket, esp. the comment ‘most javac will try to translate “+” to StringBuilder whenever possible. So if you do need to use String.concate(), you’d better use it explicitly.’
• Paul Graham – Beating the Averages – why it’s good to learn Lisp. (Because it makes you able to see the limitations of you current language as it’s most likely superior to it – among others thanks to Lisp macros.) A really good essay on the power of programming languages, which has persuaded me about some year ago, when I’ve originally read it, to learn Clojure (a modern Lisp dialect running on the JVM).

Most interesting links of September

The most interesting articles and other IT resources I’ve encountered the previous month, delayed a bit due to my holiday in Andalusia. In no particular order. Included some performance stuff, few tools and few general SW engineering things.

• The Open-Closed Principle , i.e. open to extension, closed to modification – one of the basic principles in OOP underlying many best practices such as “make all member variables private” nicely explained, with code samples with and without O/CP applied.  Noteworthy: The principle is implemented with abstractions (abstract classes defining the constant part with subclasses being the extensions). You can’t “close” your design against all changes and must thus choose the ones that are more likely, i.e. create a “strategic closure”.
• Java EE 6 xor Spring by A. Bien – the main difference is in the philosophy behind – Java EE is based on Convention over Configuration. The decision factor is usually the support policy, though. Also the tc Server is certainly better than a “custom” Tomcat with Spring.
• ThoughtWorks Technology Radar – to help decision-makers from CIOs to developers understand emerging technologies and trends that affect the market today; though their assignment of GWT under hold is disputable (http://www.dzone.com/links/r/thoughtworks_radar_demystified_gwt.html); TW answers: “As it turned out the conciseness of the text didn’t allow us to adequately make our points so that they were not misunderstood. We are interested in a discussion but our opinion about the suitability and usability of GWT has still not changed.”
  • JavaScript as a 1st-class language w/ the same best practices (unit t., refact.,…); functional languages (Clojure > Scala)
  • WS-* beyond the basic profile, GWT, RIA on hold
• “Agile Business” for a startup with “Virtual Assistants”: outsource (to an “Virtual Assistant”) what you can, only do what’s necessary at the time even if that means doing manually (outsourced) st. that could be automated; this helped to decrease time from 160 MH to 10 MH.
  “The lesson is that before you launch your product, think about the processes you can avoid automating. How about reminder emails? How about monthly billing? Could a human being run a report once a month and send emails or charge credit cards?” , “Every hour spent writing code is wasted time if that code could be replaced by a human being doing the same task until your product proves itself.”
• InMemProfiler: Identifying Memory Allocators – tool to track memory allocation capable of attributing it to the classes (i.e. packages) of interest without blurring the results with char[] and all the java.lang.* classes
• Easy Performance Analysis with AppDynamics Lite – I’m fond of performance troubleshooting tools and AppDynamics Lite looks really cool. The post includes two very short yet very informative and nice screencast showing its installation and usage. App. D. automatically discovers Struts actions, JDBC calls, webservices etc. and captures slow operations with the necessary details; this is quite similar to what the open-source Glassbox.com does. The monitoring web UI is very nice and user friendly. See the white box on the right side at http://www.appdynamics.com/lite.php to see what JVMs, ASs and frameworks it supports. Check also the comparison of the lite and standard versions (max 30 transactions, max 2 hours if diagnostics data, …).
• Google Relaunches Instantiations Developer Tools – Now Available for Free – incl. the static code analysis tool (Eclipse plugin) CodePro AnalytiX
• A blog about Terracota’s new BigMemory (commercial) claims that 64b JVM with heap over few GB may be a nightmare – “… not all people know about 64-bit JVMs and the nightmare these things can cause. Contrary to what other vendors are claiming, most shops such as Unibet, PartyPoker, Expedia, Sabre Holdings, Intercontinental Hotels Group, JP Morgan, Goldman, and more will tell you a 64-bit JVM pauses unpredictably and for minutes at a time. even when a 64 bit JVM is small (<2GB) it takes 30+% more RAM than a 32-bit equivalent JVM running under the same app.“
• Presentation Real Software Engineering by Glenn Vanderburg  – the talk is pretty interesting and I recommend it. Few, subjectively selected and interpreted points:
  The SW engineering as taught in universities doesn’t work, it’s actually a caricature of “engineering” (that is, established practices that work). The reason is that SwE is unreasonably fascinated by (ideally mathematical) modeling and precise, repeatable processes. This is not how real SW development can or does work. Given the complexity and uncertainty, an empirical process, based on frequent feedback and continual adjustment, is much more suitable. Also we don’t need complex models because prototyping and testing is nearly “free”, compared e.g. to spacecraft engineering. And with BDD and tools like RSpec and FitNesse we may have both readable and executable specifications – the code becomes the model.
• Monte Carlo Analysis of the Zero Defect Mentality of TDD – conclusion: TDD pays off in the long run even though being slower [learning curve; 0-value bringing defect fixing] Fow short life time, TDD may be not worth it. Don’t argue, simulate

Most interesting links of April

The most interesting technical links I’ve encountered in April:

• Getting Started with Tdd in Java using Eclipse [Screencast] – you will see not only TDD in practices but also a number of best practices applied and some inspirational novelty (at least for me) ideas  such as creating one test class per test configuration (and thus multiple test classes for a single “business” class); I really recommend this even if you are not interested in TDD
• NoSQL links (as everybody these days, I’m also at least observing the NoSQL movement):
  • Why Twitter selected Cassandra (brought by the great myNoSql blog) – why they choose Cassandra over other alternatives and instead of the current solution of mysql with memcache
  • Cassandra at Digg: Looking to the future with Cassandra (9/2009) – why Digg considered switching to Cassandra (which they also did)
• Testing
  • Easy data-driven testing with Spock – the Spock framework based on the popular JVM scripting language Groovy (99% Java + 1000% added) introduces a custom domain-specific language (DSL), which makes testing of a method using different data incredily easy and readable, with all the power of Groovy at hand; see the post and you will see immediately what I mean

That’s all for this month, stay tuned.

See how Test Driven Development is done in practice

On the Manning site you can read the 2nd chapter of the book Test Driven – Practical TDD and Acceptance TDD for Java Developers by Lasse Koskela from 2007. The chapter 2: Beginning TDD let’s you follow the mental process of a programmer practicing TDD to implement a set of user stories. You’ve probably heard a lot about TDD on the theoretical level but this sample chapter gives you the unique opportunity to see the basic, practical level of TDD in action. I’m very glad to have read it.

The interesting thing is how he really always does the simplest possible solution (read ‘dummy and 0% generic’) to make the test pass and continuously adds tests and refactors the implementation to get the final code.