Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: multithreaded cache? Date: Thu, 24 May 2012 23:05:19 +0200 Lines: 160 Message-ID: References: <4fb69812$0$6849$e4fe514c@news2.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net tt9ahK7fOflZTj+f0Ss0zAw3Sq4uy8+CVK6BU01Rhs3Anh8dsjPuD8Mo1f4qc53J8= Cancel-Lock: sha1:kQg6quFtv8k0GNaVl9qCYEzlWfY= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:14783 On 24.05.2012 08:11, Lew wrote: > Robert Klemme wrote: >> And it is true for a number of other techniques I would consider bread >> and >> butter tools: >> >> - Ensuring requirements are gathered properly and understood before >> starting >> to code (and design of course). > > True, with provisos. > > = Requirements are not fixed. What you should have now is the best > available for now. But there is a minimum standard: there must be enough information to at least get an idea of what is to be done. I have seen three sentence requirements for a feature in a complex system which left engineers wondering what they are supposed to do. > = "Properly"? "Understood"? There are books on this, but it boils down to: > > Your software will be used. By whom? Why? What would annoy them? Don't > do that! What would make them forget the software is there and just get > their job done? Do that! ! > "Proper" is always from the user's standpoint. Not what they say, by the > way, but what they think and feel - really. Behind the bullshit and > self-deception, when they aren't posturing for your benefit and really > are just trying to get their work done. And that's where "understood" > comes in. Give'em what they want, not necessarily what they ask for. Pretty early in my career I had a quite instructive experience: we were building a web catalog for a business customer with user management, a lot of technical data about their products - and of course a link to their ERP system. They wanted to have a price calculation in that system which could take several routes depending on the user. They explained it, I wrote a document which also included an UML activity diagram of the flow with explanations. We sent it in. They rejected: "No, it must be completely different." So we sat together. End of the story: it was exactly what they wanted. So they either did not understood the document and didn't want to ask - or their own requirements. :-) >> - Testing code _before_ shipping. > > Some espouse before even writing it. I say, sure, great idea, when you > make it easy to express my ideas in tests instead of imperative code. > > Hmm. > > BTW, this being Java, have you guys tried EasyMock? (AndroidMock in > Android Java.) That shtuff rocks. It makes your very code better, not > just tested but idiomatically. Tricky stuff. I'll post about that when I > get back into it. I've discovered a Right Way and a Wrong Way to do > mocks, just like I did with JPA. Not yet, thank you for the pointer! >> - When writing unit tests, making sure to also include tests for critical >> values (usually corner cases such as -1, 0, 1, limit, limit - 1, limit >> + 1, >> null, "", etc.). > > Consider this. No matter what input a module receives, it must achieve a > valid program state in response. > > No matter what. Absolutely! > Coding to this formalism means, for example, that a method can handle > all possible argument values. > > public interface Caromer > { > public Fromitz carom(Flamo flame); > } > > As Herr Klemme points out, 'null' is one possible input for 'flame'. > Non-'null' is another. Presumably a 'Flamo' has observable state that > distinguishes input values. If the type were 'Integer' or 'int', > Robert's example int values might pertain. > > But you cannot give infinite test cases to a unit test. So you pick edge > cases, on both the "happy path" (positive) and "unhappy path" (negative) > scenarios. Exactly. >> - Thinking about the person who must use what you produce, regardless >> whether >> it's a document, a configuration file layout, a DSL, a class, a >> library. It >> seems many people in software development are far more concerned with the >> inner workings of what they create instead of considering how it will >> be used. >> Maybe it's easier or it is because making it work takes the largest >> part of >> coding - still the outcome often is dissatisfying and a little more >> thought >> upfront goes a long way at avoiding maintenance headaches and worse >> things. >> >> ... >> >> This can't be so difficult, can it? > > You have a fine sense of humor. Well, the fun disappears when you see the same mistakes made over and over again and attempts to improve it do not have effects... > It's as easy as empathy, and getting inside the mind of a professional > in a field of which you know little to nothing. I agree for library API design: that takes a bit of experience to get right. But when it comes to writing documents I think the rules for readability are quite straight forward (some universities even have them in their curriculum): do not start with the details but give the reader an overview first. Give previews and summaries. Generally watch document structure. Do not put too much in a single diagram. Things like that. > Testing certainly helps. Functional tests (as opposed to unit tests) can > and should be part of and produced from requirements. At the user-facing > level you can send test scenarios back as memos of understanding (MoUs) > - what better way to make clear what you understand and how it will play > out? Good point. > Prototypes count, too. They can meet tests, even. Building a prototype > that meets tests, starting within a day or so of starting, kicks ass for > converging on clarity. Keep it up - every day the prototype runs, works > (up to whatever you've done that day), can be checked out and run in any > directory, by any developer, and run, etc. And prototypes are a great way to test whether ideas work with low effort before basing a whole design on an idea. > Add a CI tool like Jenkins to run your tests every time you "git commit" > to "origin/master" (or whatever); you got yourself a one-entity > professional shop. Jenkins is great. We use it. Broken tests are quickly discovered. :-) Kind regards robert PS: Hey, you managed to sneak in a German word. :-) -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/