I'm taking part in a course of Specification by Example, lead by Gojko Adzic. Here I want to summarize the key things I've learned in the first day of this entertaining and fruitful course thanks to both Gojko and my co-participants.

If you haven't heard about Specification by Example (SbE) before (really?!), then you need know that its main concern is ensuring that you build the right thing (complimentary to building the thing right), which is achieved by specifying functionality collaboratively with business users, testers, and developers, clarifying and nailing them with key examples, and finally, where it is worth the effort, automating checks of those examples to get not only automated acceptance tests but, more importantly, a "living documentation" of what the system does that never gets out of date. Best to read the key ideas described by Gojko himself or the SbE Wikipedia page.
Continue reading →

---

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Continue reading →

---

Recommended Readings

• The Netflix Chaos Monkey - how to test your preparedness for dealing with a system failure so that you won't experience nasty wakeup when something really fails in Sunday 3 am? Release a wild, armed monkey into your datacenter. Watch carefuly what happens as it randoly kills your instances. This is exactly what Netflix does with their with their cloud infrastructure - also a great inspiration for my recent project. Do you need to be always available? Than consider employing the chaos monkey - or a whole army of monkeys! (PS: There is also a post with a picture of the scary monky.)

Continue reading →

---

If your log file has entries like these:

Continue reading →

---

Which of the following names of test methods do you think to be the best?

Continue reading →

---

While waiting for a new project, I wanted to learn something useful. And because on many projects we need to assess and test the performance of the application being developed while only rarely there is enough hardware for generating a realistic load, I decided to learn more about provisioning virtual machines on demand in the Cloud, namely Amazon Web Services (AWS). I've learned a lot about the tools available to work with AWS and the automation of the setup of resources (machine instances, security groups, databases etc.) and automatic customization of virtual machine instances in the AWS cloud. I'd like to present a brief introduction into AWS and a succinct overview of the tools and automation options. If you are familiar with AWS/EC2 then you might want to jump over the introduction directly to the automation section.


Continue reading →

---

Recommended Readings

• Recommended Reading by Poppendiecks - an excellent selection, starting with Lean from Trenches, Management 3.0, Specification by Example, The Lean Startup etc.
• Eric Allman says that Programming Isn’t Fun Any More  because problem solving has been replaced with learning, configuring, and integrating tons of libraries, frameworks, and tools and many people agree with that (as discussion on reddit proves). In other words we tend to go for any benefit we can have without considering the costs and for "easy" solutions without considering the true enemy: complexity. Perhaps we should always listen to the Rich Hickey's Simple Made Easy talk before we add a lib/tool/framework?

Continue reading →

---

This is a technology blog but why do we actually use technology? We use it because we want to help people achieve something - and in the process of doing that we have to cooperate and communicate with many humans. The human factor is far more determining for our success than any kind of technology could ever be. Why do most project fail? Because of a bad technology? No - usually it's a failure of communication, leadership, process change. And this week I've learnt some very important things about this crucial human factor - and thus this post may well be the most valuable piece published here til now - or ever.

First, I've learned how we decide (and a project - IT or other - is nothing but a bunch of hundreds, millions of decisions, both small and big). To deal with the incredibly complex world around us, human brain has many decision strategies ranging from a very rational decision making to "gut feeling" decisions based on our emotions and subconsciousness. Every of these strategies is perfectly suitable for some situations (for example relying on emotions and intuition is often the best thing, conversely to what we've been thought) - and leads to suboptimal results (read: terrible failures) in others. Thus the single most important factor that determines how successful we are is our ability of metacognition, i.e. being aware of how we think, and thus being able to select the most appropriate strategy for the situation at hand. (Which might not be as easy as it sounds and may require that we "trick" our mind somehow, i.e. by distracting it or forcing it into a certain decision mode.) Jonah Lehrer documents that on the "Marshmallow experiment" - the children who knew that they got to distract themselves somehow not to eat the marshmallow, which they've been given, not only managed to wait those 15 minutes for another one but were also much more successful in their later lives - presumably because their ability of metacognition helped them to make better decisions more often.


Continue reading →

---

I was unsuccessfuly looking for some decent, neither too simple nor to complex Java web application for Iterate hackaton "War of Web Frameworks". I want to record the demo apps and options I've found in the case I'll need it ever again. Tips are welcome.


Continue reading →

---

This post is inspired by Kent Beck's excellent talk at JavaZone 2011 titled Software G Forces: The Effects of Acceleration where he describes how the development process, practices and partly the whole organization change and/or have to change as you go from annual to monthly to weekly, daily, hourly deployments. I'd like to summarize some of the points he made and use that as a ground for arguing that more frequent deployments are (in general) better.

I'd highly recommend you to watch his presentation as I will only reproduce parts of it (and as they are out of their original context, they might well not represent exactly what Kent wanted to communicate).

Kent argues that as you deploy more and more frequently, many things have to change including the business side of the software. What is a best practice for one of these speeds becomes an impediment for another one. With more frequent deployments teams have to progress towards the following practices, while leaving some other practices behind:


Continue reading →

---

To learn how complex your code base really is and how much effort a particular refactoring might require compared to the initial expectations, follow these steps:

1. Schedule git reset --hard; git clean -fd to run in 1 hour (e.g. via cron)
2. Do the refactoring
3. "WT*?! All my changes disappeared?!" - this experience indicates the end of the refactoring :-)
4. Go for a walk or something and think about what you have learned about the code, its complexity, the refactoring
5. Repeat regularly, f. ex. once every week or two - thus you'll improve your ability to direct the refactoring so that you learn as much as possible during the short time

Continue reading →

---

Having [automated] unit/integration/functional/... tests is great but it is too easy for them to become a hindrance, making any change to the system painful and slow - up to the point where you throw them away. How to avoid this curse of rigid tests, too brittle, too intertwined, too coupled to the implementation details? Surely following the principles of clean code not only for production code but also for tests will help but is it enough? No, it is not. Based on a discussion on our recent course with Kent Beck, I think that the following three principles below are important to have decoupled, easy to evolve tests:

1. Tests tell a story
2. True unit tests + decoupled higher-level integration tests (-> Mike Cohn's Layers of the Test Automation Pyramid)
3. More functional composition of the processing

Continue reading →

---

What I like most at conferences are reports of someone's failure to do or implement something for they're the best sources of learning. And How to Fail with Drools (in Norwegian) by C. Dannevig of Know IT at JavaZone 2011 is one of them. I'd like to summarize what they learned and extend it for introduction of a tool, framework, or library in general based on my own painful experiences.

They decided to switch to the Drools rule management system (a.k.a. JBoss Rules) v.4 from their homegrown rules implementation to centralize all the rules code at one place, to get something simpler and easier to understand, and to improve the time to market by not requiring a redeploy when a rule is added. However Drools turned out to be more of a burden than help for the following reasons:
Continue reading →

---

Paul King had a very good presentation (last year's slides) at JavaZone about why to use Domain-Specific Languages and how to create internal DSLs in Groovy. I'd like to list here few tips that he has mentioned but before we get to that, why would you want to create a DSL? Martin Fowler answers that in his Domain-Specific Languages book (2010). Some of the reasons are to have a higher-level, more focused and conscise representation that also domain experts can read and perhaps even write. You  have certainly already used a DSL such as regular expressions, CSS, SQL, Spock's BDD tests, build instructions in Gradle - these are rather technical but sometimes DSLs are also created to be used by business users, f.ex. for anti-malaria drug resistance simulation. (Want more DSLs in Groovy?).

Paul mentions one important thing - you can always make your DSL better, i.e. more fail-proof (case insensitive, support plural endings, ...) and secure and more like a natural language but it all comes at a cost and you must evaluate when the cost overweights the benefit (beware the 80:20 rule).

Some of the Groovy DSL implementation tips:
Continue reading →

---

A brief overview of dependency injection in Java EE, the difference between @Resource/@EJB and @Inject, and how does that all relate to Spring - mostly in the form of links.

Context Dependency Injection (CDI, JSR 299) is a part of Java EE 6 Web Profile and itself builds on Dependency Injection for Java (JSR 330), which introduces @Inject, @Named etc. While JSR 330 is for DI only and is implemented e.g. by Guice and Spring, CDI adds various EE stuff such as @RequestScoped, interceptors/decorators, producers, eventing and a base for integration with JSF, EJBs etc. Java EE components such as EJBs have been redefined to build on top of CDI (=> @Stateless is now a CDI managed bean with additional services).

A key part of CDI aside of its DI capabilities is its awarness of bean contexts and the management of bean lifecycle and dependencies within those contexts (such as @RequestScoped or @ConversationScoped).

CDI is extensible - you can define new context scopes, drop-in interceptors and decorators, make other beans (e.g. from Spring) available for CDI,... .

Resources to check:
Continue reading →

---

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