Posts

Conquest

"Do not be afraid." David jumped around, his body flush with adrenaline. He had been alone in the room, or at least that's what he thought. Fortunately, he had managed to put his pants on. "Who are you?" he managed. Someone was there, in the room, on the other side of the bed from him. He couldn't understand how he got past the agents outside. "My name is Ra'ken," the man said. "We need to talk." "How did you get here?" David asked, trying to decide whether shouting would be a good idea. "I will explain. Please finish dressing and then we can go outside so you can feel safer. I did not mean to scare you." David felt a bit ridiculous but he was old enough to know that just because someone tells you they don't want to harm you it doesn't mean it's true. He finished putting a shirt on. "Shall we?" he asked, turning his head back to the other man. "After you," the man said. David ...

Don't expose class internals

I'm going to disagree a bit with Robert Martin, the author of Clean Code . In his G14 "Feature Envy" smell he uses the example of an method on an HourlyPayCalculator class that takes an HourlyEmployee argument and then uses its properties to do its job. That makes the method "envy" the HourlyEmployee class - the method "wishes it was inside the HourlyEmployee class". So far, so good. Unfortunately, Robert continues with a counter-example to the feature envy smell; he uses the following example (Java code): public class HourlyEmployeeReport { private HourlyEmployee employee; public HourlyEmployeeReport(HourlyEmployee e) { this.employee = e; } String reportHours() { return String.format("Name: %s\tHours: %d.%1d\n", employee.getName(), employee.getTenthsWorked()/10, employee.getTenthsWorked()%10); } } Robert says: "Clearly, the reportHours method envies the HourlyEmployee class. On...

The Awakening

The source of their Powers was never discovered; what nobody had doubted, however, was that there was a will behind it. Both the fact that there were exactly nine of them – one for each billion people – and the fact that each of them gained their powers on January 1st, 2050, at exactly midnight local time, made coincidence a too unlikely explanation. Once it found out about their existence, the world called them superheroes; but amongst themselves they would use the name Champions. The people would not discover the existence of the Champions for more than a year, though, because at the same time they had gained their powers, the Universe had started responding to spells. Some would call them wishes, or prayers; whatever the name, people's intentions were starting to directly affect the real world. Like many religions had insisted, it would only happen if the person making the wish genuinely believed in it; unlike what those religions had taught, the effect of the wish appeared ...

TDD by example - first book

This is an alpha version of a TDD booklet I wrote. As I said earlier , I plan on writing several of these. TDD by example - Evaluating an expression [pdf] It's a hands-on book; if you don't plan to follow it by writing code, it might not be of any help. The intended target are people who have done no TDD at all, or who tried it and couldn't make it work. If you have experience doing TDD, this book will probably look childish. Feedback will be strongly appreciated. Positive if at all possible, but even "it sucks" is better than nothing :) The book is also available from Amazon for $4.99 for Kindle (if you're in the US or Canada; I know Amazon changes the price in other countries) or $14.99 in paperback .

Science vs dogma

Two hypotheticals: 1. You (common, everyday man) observe something occurring in nature. Every time it happens, you figure out that a specific something causes it. You emit the hypothesis that "A causes B" and devise a number of experiments to disprove it. You fail, and as far as you know everyone else also fails to disprove your theory. You tentatively accept the theory. 2. You observe something occurring in nature. It violates accepted dogma. You note that there is no known case where the alleged cause is known to actually produce the observed effect and, in fact, there is no actual proof that the cause even exists. You are told that you lack the inner grace that allows the high priests to verify that the cause does indeed exist; that there are secret rituals you're not privy to that they have used to confirm the truth of the dogma, and you're better off just accepting it as fact. The first paragraph describes, for example, the idea that complex information is overwh...

Thou shalt not steal

Jimmy was quite good at his craft, and that made him proud. His Pa, though – his Pa could never find out; he was a big stickler for that “honest work” bull, his Pa was. Jimmy was big for his fourteen years, so his Pa had started to bug him more often lately – “it’s time to start earning your keep, Jimmy”, “come work with me at the farm, Jimmy, we could use someone like you”. It was very annoying, even more so because Jimmy did want his Pa to be proud of him, but he wanted to get there his own way. No, his choice of craft was not that of a farmer, or a carpenter, or anything like that. Jimmy was a pickpocket – a good one, if he said so himself. Minor stuff for now, but he had never been caught – the very thought of what his Pa would do to him if he found out about it gave him shivers – and he was hoping for a big score. Jimmy was sure that his big score was close – didn’t his Ma tell him that “good things come to those who wait”? So Jimmy waited, and practiced. His Pa was also annoying ...

TDD by example

I intend to start a series of short "booklets", for lack of a better term, on the same idea of Growing Object-Oriented Software, Guided by Tests - show how a test-driven design process works for writing an application, from beginning to end. I realize I have hardly any readers, but is anybody interested in something like that? The articles will be free on my blog, of course, but I intend to also make them available for sale on Amazon. I thought of stuff like writing an expression evaluator - 2 + 3 * 5 / (1 - 7) - and a postfix expression evaluator - 7 2 3 + * - but I tend to jump to math problems. On one hand, I need relatively simple problems, as I want to emphasize the TDD part; on the other hand, I don't want to write the next Stack implementation. Can anybody suggest topics? Edited: follow-up at http://mdpopescu.blogspot.com/2011/10/tdd-by-example-first-book.html .