DearBook (http://www.DearBook.com.cn) zh-cn DearBook第二书店 http%3a%2f%2fwww.nikhilk.net%2fEntry.aspx%3fid%3d168 /Author/images/Nikhil_Kothari_s.jpghttp%3a%2f%2fwww.nikhilk.net%2fEntry.aspx%3fid%3d168Sharing a minor update to my Web Development Helper tool that fixes some bugs, and also provides an early version of a new feature: a script class browser, right in your browser! 2007-7-25 4:28:39Nikhil Kothari http%3a%2f%2fmartinfowler.com%2fbliki%2fDslReadings.html /Author/images/Martin_Fowler_s.jpghttp%3a%2f%2fmartinfowler.com%2fbliki%2fDslReadings.html DslReadings dsl 13 July 2007 Reactions (See my note on DomainSpecificLanguage for a quick intro to this topic and my terminology on it.)Update:David Laribee has written a post contrasting what he calls ordered and unordered fluent interfaces. The distinction is that ordered fluent interfaces force a particular flow on how you compose your DSL sentence. He provides an example where he uses multiple interfaces on a single ExpressionBuilder - the same technique that’s used by JMock.Anders Norås has written two interesting articles on writing internal DSLs in C#. The first article gives a sample of the DSL and a discussion against Chromatic’s cynical check-list. The second article goes into details about its implementation.Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain. 2007-7-25 0:00:00Martin Fowler http%3a%2f%2fmartinfowler.com%2fbliki%2fUiPatternsReadings.html /Author/images/Martin_Fowler_s.jpghttp%3a%2f%2fmartinfowler.com%2fbliki%2fUiPatternsReadings.html UiPatternsReadings design 12 July 2007 Reactions In the summer of 2006 I did a major chunk of work on UI patterns. Since then they’ve been very much on ice as my primary writing focus has shifted (although not very visibly) to DomainSpecificLanguages. On this page I’ll keep a note of links to writings I’ve liked that are connected with that work.Over the last few weeks Jeremy Miller has been writing an excellent series of posts on UI design in C#. (Sadly there doesn’t seem to be a good table of contents article, so I’m linking to the latest post before I wrote this.) 2007-7-25 0:00:00Martin Fowler http%3a%2f%2fmartinfowler.com%2fbliki%2fDesignStaminaHypothesis.html /Author/images/Martin_Fowler_s.jpghttp%3a%2f%2fmartinfowler.com%2fbliki%2fDesignStaminaHypothesis.html DesignStaminaHypothesis design 20 June 2007 Reactions Is it worth the effort to design software well? From time to time I have indirect conversations about whether good software design is a worthwhile activity. I say these conversations are indirect because I don’t think I’ve ever come across someone saying that software design is pointless. Usually it’s expressed in a form like 'we really need to move fast to make our target next year so we are reducing '.In there is a notion that design is something you can trade off for greater speed. Indeed I’ve come across the impression a couple of times that design effort is tolerated to keep the programmers happy even though it reduces speed.If it were the case that putting effort into design reduced the effectiveness of programming I would be against it. In fact I think most software developers would be against design if that were the case. Developers may disagree on what exactly is good design, but they are in favor of whatever brand of good design they favor because they believe it improves productivity. (And by 'design' here I mean either up-front design or agile’s approach, ie planned or evolutionary design.)Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.One way of visualizing this is the following pseudo-graph.The pseudo-graph plots delivered functionality (cumulative) versus time for two imaginary stereotypical projects: one with good design and one with no design. The project that does no design expends no effort on design activities, whether they be up front design or agile techniques. Because there’s no effort spent on these activities this project produces function faster initially.The problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better.I call this a hypothesis because it is a conjecture, there is no objective proof that this phenomenon actually occurs. In scientific terms it’s not a very good hypothesis because it’s hard to test. We CannotMeasureProductivity nor can we measure design quality.But despite it being only a hypothesis, it’s also an axiom for many people, including myself. We may not have objective proof that this effect occurs but many of us feel that this explains what we see we see qualitatively in the field. It’s an axiom for me as it’s the assumption that underpins my entire career as a writer about software design. If design doesn’t actually improve productivity in some way, most of my writings are worthless.I’m sure it sounds strange to many people to treat a hypothesis as an axiom, but it’s a common thing to do. I look at it that I use my judgment to assess that the hypothesis is true, but can do so without ignoring the objective weakness of the hypothesis. I’d love to find a way to to prove it and almost as much to refute it.The hypothesis has a corollary, which comes from the the design payoff line. If the functionality for your initial release is below the design payoff line, then it may be worth trading off design quality for speed; but if it’s above the line then the trade-off is illusory. When your delivery is above the design payoff line neglecting design always makes you ship later. In technical debt terms it’s like taking out a loan but not using the principal for so long that by the time you use it you’ve paid out more in interest payments.This raises the question of where that line is. Even with people who accept the design stamina hypothesis there is substantial, and important, differences over where the payoff line sits. I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.This leads to a consequence for Technical Debt. Technical Debt is a fantastic analogy and I use it frequently. But the design payoff line reminds us that taking out a Technical Debt is only worth doing up to a certain point. Not just do we have to consider whether delivered value is greater than the interest payments, we also have to judge whether the delivery is above the payoff line in the first place. 2007-7-25 0:00:00Martin Fowler http%3a%2f%2fmartinfowler.com%2fbliki%2fDuplexBook.html /Author/images/Martin_Fowler_s.jpghttp%3a%2f%2fmartinfowler.com%2fbliki%2fDuplexBook.html DuplexBook writing 13 June 2007 Reactions Last week I got the newest book in my signature series: xUnit Test Patterns by Gerard Meszaros. I’ve been working with Gerard with it on and off for a couple of years, so I’m fairly familiar with its contents, but somehow seeing the physical copy gave me quite a shock. Somehow it hadn’t dawned on me how big the book was - 883 pages, easily the biggest book in my series.On the whole I’m not keen on big books, I was very proud of keeping UML Distilled so small. A book this big scares me, how will I ever get time to read it?But xUnit Test Patters isn’t as scary as it looks, because it’s actually two books in one set of covers. In this it follows a style I also used in P of EAA. The first book is a narrative book, designed to be read 'cover to cover'. The narrative book is something small enough to be digestible, in xUnit Test Patterns it’s 181 pages, 106 in P of EAA. The second book is reference material, which is designed not be be read cover to cover (although some people do) but instead to be dipped into when needed. The idea is that you read the narrative book to get a good understanding of the field, then put it on your shelf so it’s handy to grab when you need to delve into the reference section.I read a lot of history books and I’ve often wished that the author had written a duplex book. History books often need detail to expand upon a particular topic or to describe the evidence for a point of view. The result, however can be a long book. One example is a favorite book of mine: Guns, Germs and Steel. I’m really glad I read it, and I do recommend it. But it did feel long, and I wonder how it would have worked in duplex.How to Read a Book suggests that when you read a book for the first time you should deliberately skip-read it, unhesitatingly skipping over detail sections. I read very fast, which helps me, but although fast or skip reading is a plus, I’d rather the book was designed to help. My personal rule of thumb is that 200 pages is the limit for a narrative cover-to-cover technical book. If it goes over that you need some way to allow people to get the core information with less bulk. A duplex book isn’t the only way to it, such as selected bolded paragraphs in the Timeless Way of Building, which worked pretty well for me. I’m sure there are other techniques that I haven’t run into yet, but the duplex is currently top of my list.A duplex book is really a specific case of a more general principle to organize a book in gradually increasing sections. The Pick Axe is a good example of this. The first two chapters are a quick overview of ruby in 24 pages. Then you have 280 pages of tutorial, followed by 500 odd pages of reference material. The first few chapters of the Enterprise Integration Patterns book is an overview (95 pages) with rest (~550 pages) reference. Books like this often don’t make these successive layers of revelation as clear as they might, however.An interesting question is whether we can do more with the duplex book format. A lot people won’t realize that xUnit Test Patterns is a duplex book because it looks like one thick book (the back cover actually claims it’s three books by considering the reference section as two separate sections). Could we physically split the books, perhaps by packaging them as two volumes in a slip case? I don’t think actually selling the books separately would make sense as they are too closely coupled together.Naturally we think about online access. Reference material often works better on the web, so perhaps we could make the reference book web only (maybe with a CD or something in the physical book) and sell only the narrative book. What would that structure do to sales?There’s interesting questions here, but the final message is that I’d urge authors of big books to think more about how the book is structured in a way that helps someone who wants something within that 200 page limit. 2007-7-25 0:00:00Martin Fowler http%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fjavaone_wrap_up /Author/images/James_Gosling_s.jpghttp%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fjavaone_wrap_upI did the Toy Show on the last day of JavaOne, intending to write a wrap-up article immediatly. But It’s amazing how way leads on to way. I got off the stage at 10:30 and headed home where I had a houseful of relatives visiting for Mother’s Day. When I got home I found that my neice had broken her ankle (by stepping on a tennis ball - whodathunk?) just moments before I arrived, so I ended up heading off to the ER at Stanford where I spent the next 6 hours. Joy. The rest of the weekend was really nice. Back to the Toy Show... If you weren’t there, you should watch the videos. The tail end of the session was devoted to devices that aren’t important to many JavaOne attendees in their normal software development role, but they sure do stretch the mind. For example, the SONIA autonomous underwater vehicle was a great example of a bunch of students having a huge amount of fun doing something quite interesting. I especially liked their timeline that showed the correlation between their contest ranking and their adoption of Java. Overall, there was a huge amount of interesting stuff at JavaOne. OpenJDK, JavaFX scripting, Glassfish V3, NetBeans 6, NASA World Wind, Consumer JRE, BDJ, applet fun everywhere, and some cool realtime robotics demos — and a whole lot more. I don’t think I’ve ever been through such a hectic JavaOne, or ended up with such a long to-do list (Mostly JavaFX stuff...). Much fun to com! 2007-7-25 0:00:00James Gosling http%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fparticipate /Author/images/James_Gosling_s.jpghttp%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fparticipatePaul Buchheit has gotten pretty cranked up about some convenience methods we should have put into the imaging APIs. Yup. Guilty as charged. There are only 24 hours in a day and we can’t get around to everything, and back then we were putting most of our energy into the enterprise APIs. Java is a community, not a product. So, Paul: I encourage you to join in and help make the imaging APIs better (or any other’s that might trigger a rant). Collaboration is a good thing. 2007-7-25 0:00:00James Gosling http%3a%2f%2fblogs.sun.com%2fjag%2fentry%2ftime_for_the_toy_show /Author/images/James_Gosling_s.jpghttp%3a%2f%2fblogs.sun.com%2fjag%2fentry%2ftime_for_the_toy_showSomehow, JavaOne as once again been a complete blur. My promises to myself to blog more often haven’t worked out. With all the talks, press, analysts, customers, friends, server meltdowns and general running around, there just aren’t enough hours in a day. Some folks tried real hard to get me to the AfterDark party last night, but no: I had to rehearse for this morning. This JavaOne has truly been different. My keynote is both easy and hard: it’s all demos. All stuff that I think is inspiring. All stuff that makes me think 'Could I switch jobs with you?'. But it’s long. Two hours, 12 demos. 2007-7-25 0:00:00James Gosling http%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fthe_robosapiens_are_for_sale /Author/images/James_Gosling_s.jpghttp%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fthe_robosapiens_are_for_saleThere’s been some confusion on this point. Folks have asked me about this: yes, they are for sale, there are some left. They’re in the upstairs lobby at the South Hall (although there was some talk of them moving). Their booth is unmarked and has no signage, but they are selling. The gizmos are very entertaining to program. 2007-7-25 0:00:00James Gosling http%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fbuilding_new_worlds /Author/images/James_Gosling_s.jpghttp%3a%2f%2fblogs.sun.com%2fjag%2fentry%2fbuilding_new_worlds This is the image from this year’s t-shirt. Yes, I do them myself. I do it with a tool called Lightwave. I’m not very good at it, but as hobbies go, it’s a lot of fun. 2007-7-25 0:00:00James Gosling