It's pretty useful to have the ability to eperiment interactively with some API using the (desktop) Groovy Console
Continue reading →

---

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)

Continue reading →

---

Have you ever needed to check the state of your webapp's objects/Session/.. to find out why the hell something doesn't work or have you had to learn a weird 3rd party API that is only available on the server? Then you were doomed ... until the publication of GroovyConsole. JeeUtils GroovyConsole provides a JSP page that let you execute any Groovy/Java code on the server side, with access to server-side objects like request/session etc.

Here is a screenshot of my recent troubleshooting session, where I needed to check the state of a session-scoped JSF Managed Bean:


Continue reading →

---

It is surprising how difficult it is to find documentation for some JUnit features such as Theories. May be they haven't bothered to write it because it is still considered "experimental" (even though included in JUnit since 4.4). As usually we have to rely on Jens Schauder's blog
Continue reading →

---

JUnit has a hidden treasure which makes it easy to do something we have long longed for - namely not only to verify that an exception of a particular type has been thrown but also that its message contains the expected message. The hidden pearl is the @Rule ExpectedException and its JavaDoc documents well how to use it (slightly modified):


Continue reading →

---

The page you want to access is Practical Introduction into Code Injection with AspectJ, Javassist, and Java Proxy
Continue reading →

---

The ability to inject pieces of code into compiled classes and methods, either statically or at runtime, may be of immense help. This applies especially to troubleshooting problems in third-party libraries without source codes or in an environment where it isn't possible to use a debugger or a profiler. Code injection is also useful for dealing with concerns that cut across the whole application, such as performance monitoring. Using code injection in this way became popular under the name Aspect-Oriented Programming (AOP). Code injection isn't something used only rarely as you might think, quite the contrary; every programmer will come into a situation where this ability could prevent a lot of pain and frustration.

This post is aimed at giving you the knowledge that you may (or I should rather say "will") need and at persuading you that learning basics of code injection is really worth the little of your time that it takes. I'll present three different real-world cases where code injection came to my rescue, solving each one with a different tool, fitting best the constraints at hand.


Continue reading →

---

I was for a long time unhappy that DbUnit Express users have to create a @Before method in each test just to get the test database initialized. Fortunately since version 1.3.0 they don't need to do it anymore thanks to JUnit Rules (if you are not familiar with them, they are an alternative to @Before/@After and @BeforeClass/@AfterClass, read this rules introduction).

As true coders you are certainly annoyed by so many words so let get to the source code.

Continue reading →

---

The DbUnit Express
Continue reading →

---

Recommended Readings

• Martin Fowler on the problem of software patents - "... while patents (even software patents) are a good idea in principle, in practice they have turned into an unmitigated disaster and would be better scrapped."
• Discovering Hidden Design, Michael Feathers - When refactoring complex code towards a better design with clearer separation of concerns, it may be sometimes worthwhile to factor out a more-less separated cluster of functionality even if it doesn't do just one thing (and this it is difficult to find a descriptive name for it). Comparing the cost and benefit of this and an "ideal" refactoring (where we get to single-responsibility factors), this one may prove better.
• Martin Fowler: Tradable Quality Hypothesis - Martin argues that we must claim that quality in software development is not tradable (even though we know that certain tradeoffs can be done). The reason is that people are used to quality (in food, clothing, ...) being pretty "tradable" and so it is very hard to persuade them that in the case of software development it is tradable much less (or not at all). And once your manager and customers view quality as tradable, you are doomed. They will force you to trade it for time, features, ... in a proportion that will harm the project (because, as already mentioned, in SW it is much less tradable then in other domains).
• Are estimates worthless?& Magne's response - interesting discussion of the value and cost of estimation and its role in contracting w.r.t. trust - a nice addition to the discussion: Agile not suitable for governmental IT?.
• Generate Test Data with DataFactory - nice java library that generate "random" values of different types and optionally satisfying some constraints - f.ex. first/last name (using built-in or custom list), date (within a range, w.r.t. another date, ...), address (cities, streets etc.), email, random text/word/characters, number. Available at GitHub.

Continue reading →

---

The end of our one-month iteration approached and the levels of fear and agitation started to rise. What will happen when we deploy it? Will everything crash? Will all hell break loose? Will there be a flood of midnight severity-one issues? Will the features developed work together or are there going to be unexpected and fatal interactions?

Continue reading →

---

I've recently introduced here DbUnit Express, a wrapper around DbUnit intended to get you started with testing DB-related code in no time, and now I'd like to share two productivity tips: simplifying db tester setup with a parent test and implementing your own convention for data set files, for example one data set per test class.


Continue reading →

---

Recommanded Readings

• Martin Fowler, M. Mason: Why not to use feature branches and prefer feature toggles instead, when branches can actually be used (video, 12min) - feature branches are pretty common yet they are a hindrance for a good and stable development pace due to "merging hells". With trusted developers, feature toggles are a much better choice.
• M. Fowler: The LMAX Architecture - Martin describes the innovative and paradigm shaking architecture of the high-performance, high-volume financial trading platform LMAX. The platform can handle 6 million orders per second - using only a single java thread and commodity hardware. I highly recommend the article for two reasons: First, it crashes the common view that to handle such volumes you need multithreading. Second, for the rigorous, scientific approach used to arrive to this architecture. The key enablers are: 1) The main processing component does no blocking operations (I/O), those are done outside (in other threads). 2) There is no database - the state of the processor can be recreated by replaying the (persistent) input events. 3) To get further from 10k to 100k TPS they "just" wrote good code - well-factored, small methods (=> Hotspot more efficient, CPU can cache better). 4) To gain another multitude they implemented more efficient, cache-friendlier collections. All that was done based on evidence, enabled by thorough performance testing. 5) The processor and input/output components communicate without locking, using a shared (cyclic) array, where each of them operates on sum range of indexes and no element can ever be written by more than one component. Their internal range indexes do ever only increase so it is safe to read them without synchronization (at worst you will get old, lower value). The developers also tried Agents but found them in conflict with modern CPUs for their require context switch leading to emptying of the fast CPU caches. Updated: Martin has published the post titled Memory Image which discusses the LMAX approach to persistence in a more general way.
• S. Mancuso: Working with legacy code with the goal of continual quality improvement - this was quite interesting for me as our team is in the same situation and arrived to quite similar approach. According to the author, the basic rule is "always first write tests for the piece code to be changed," even though it takes so much time - he justifies it saying "when people think we are spending too much time to write a feature because we were writing tests for the existing code first, they are rarely considering the time spend elsewhere .. more time is created [lost] when bugs are found and the QA phase needs to be extended". But it is also important to remember when to stop with refactoring to get also to creating business value and the rule for that is that quality improvements are done only with focus on a particular task. I like one of the concluding sentences: "Constantly increasing the quality level in a legacy system can make a massive difference in the amount of time and money spend on that project."
• Uncle Bob: The Land that Scrum Forgot - Scrum makes it possible to be very productive at the beginning but to be able to keep the productivity and continue meeting the expectations that are thus created we need to concentrate on some essential technical practices and code quality. Because otherwise we create a mess of growing complexity - the ultimate killer of productivity. Uncle Bob advices us what practices and how to apply to attain both high, sustainable productivity and (as required for it) high code quality. It's essential to realize that people do what they are incented to do and thus we must measure and reward both going fast and staying clean. How do we measure quality? There is no perfect measure but we can build on the available established metrics - coverage, # (new) tests, # defects, size of tests (~ size of production code, 5-20 lines per method), test speed, cyclomatic complexity, function (< 20) and class (< 500) sizes, Brathwaite Correlation (> 2), dependency metrics (no cycles, in the direction abstraction). The practices that enable us to stay clean include among others TDD, using tools like Chceckstyle, FindBugs to find problems and duplication, implementing Continuous Integration.
• Getting Started: Testing Concurrent Java Code - very good and worthy overview of tools for checking and testing of concurrent code with links to valuable resources. The author mentions among others FindBugs, concurrent test coverage (critical sections examined by multiple threads) measurement with IBM's ConTest, multithreaded testing with ConTest (randomly tries to create thread interleaving situations; trial version - contact the authors for the full one) and MultithreadedTC (which divides time into "ticks" and enables you to fine-configure the interactions)
• The top 9+7 things every programmer or architect should know - quite good selection of nine, respectively 7 things from the famous (on-line available) books 97 Things every programmer/architect should know.

Continue reading →

---

I've got an opportunity to experiment with JSF 1.2 while preparing a lecture about DbUnit Express
Continue reading →

---

Sometimes I need to observe HTTP communication between my and another machine. I usually use Eclipse' integrated TCP/IP monitor for it's simple and does its job well but today for a large response it just displayed "The HTTP content is too large to display." so I started searching for alternatives and found the Grinder TCPProxy
Continue reading →

---

Copyright © 2026 Jakub Holý
Powered by Cryogen
Theme by KingMob