InfoQ - Tracking change and innovation in the enterprise software development community

Interesting and provocative talk on writing in Java as if you are writing in a dynamic language.

InfoQ - Tracking change and innovation in the enterprise software development community

Notes from "Clean Code": A Handbook of Agile Software Craftsmanship

Clean Code is an excellent book. Here are some notes I took while reading a few of the chapters online. (The rest I ended up reading on paper, so notes are not easy to share). All in all, the book is full of excellent advice.
The chapter on generics bares a special mention. It's clear, insightful and revolting at the same time. The revolting part comes from the clarify with which the whole ugly nature of Java generics implementation is exposed to the reader. So the blame for that lies with the authors of the implementation, not the book's! The book actually manages to make the muddy mess as clear as it can be.

Here are the notes

• ProQuest Information and Learning - 9780136083238 - Clean Code: A Handbook of Agile Software Craftsmanship
  • The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn't be used anyway.
  • "You know you are working on clean code when each routine turns out to be pretty much what you expected." Half the battle to achieving that principle is choosing good names for small functions that do one thing.
  • Don't be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.
  • The LOGO language used the keyword "TO" in the same way that Ruby and Python use "def." So every function began with the word "TO." This had an interesting effect on the way functions were designed.
  • There are two very common reasons to pass a single argument into a function. You may be asking a question about that argument, as in boolean fileExists("MyFile"). Or you may be operating on that argument, transforming it into something else and returning it. For example, InputStream fileOpen("MyFile") transforms a file name String into an InputStream return value.
    • The distinction is not too clear. A question is a special form of transformation? In both cases there is knowledge in the function about how to answer the question or transform the argument. But there are no side effects in either case (presumably).
  • My general rule for switch statements is that they can be tolerated if they appear only once, are used to create polymorphic objects, and are hidden behind an inheritance relationship so that the rest of the system can't see them
  • If a function does only those steps that are one level below the stated name of the function, then the function is doing one thing.
  • A somewhat less common, but still very useful form for a single argument function, is an event. In this form there is an input argument but no output argument. The overall program is meant to interpret the function call as an event and use the argument to alter the state of the system
    • So this modifies the state and that's the key differentiator? In otherwords, this function has side effects.
  • So, another way to know that a function is doing more than "one thing" is if you can extract another function from it with a name that is not merely a restatement of its implementation [G34].
  • Try to avoid any monadic functions that don't follow these forms, for example, void includeSetupPageInto(StringBuffer pageText). Using an output argument instead of a return value for a transformation is confusing.
    • Yes, but it's the key to reducing garbage production...

Posted from Diigo. The rest of my favorite links are here.

QCon San Francisco 2009 - Part 1

I had a chance to attend the QCon conference in SF this week. I'll try to publish my notes from the talks.

Last year I managed to only publish one article! Ouch, not too impressive. This year I'm hoping to do better because my notes are already (mostly) in a digital form, thanks to FreeMind and a Mac.

So, without further ado, here's the first installment.

Intro

• Overall observations
  

  • I have to say that last year seemed a little more interesting. Perhaps it's just because it was my first QCon.
    

    But there was at least the Un-conference, which there isn't this year. Too bad. Last year it had to compete with highly interesting sessions with high-profile speakers, so I only found time to attend one or two sessions.
    

    However, this year, I would have attended at least two just in the first day.
    

    I still think the conference is very interesting and useful, but it's not quite the same.
    
    

  
  


• Corporate Opensource
  
  • This year seems to be a year of corporate opensource. Or maybe it's opensourced corporativeness?
    
    • Not sure how to say it right.
      
      
  • Exhibit 1: SpringSource
    

    • SpringSource, which was actually purchased this summer by VMWare.
      

      • The whole thing about the VMWare acquisition seems odd.
        
      
      
      • + -
        I had a chance to talk with some of the falks from Spring and they spin it like this:
        

        • VMWare needed development community to compete with Microsoft (on the cloud offering presumeably)
          

          • I guess if MS builds Azure support in the Visual Studio / .NET, then it will lead to natural use of MS products instead of VMWare's.
            I guess. So what, does VMWare propose to build VMWare support into Spring? What exactly to Spring applications need to know about VMWare? Isn't the whole point of VMWare to be transparent?
            
            The only angle would be with some kind of cloud management / deployment tools. That must be it.
            
            
            

          Second point they make is that it's actually good that there is no overlap between VMWare's core expertise and the Spring's. Right...
          

          • The argument goes that this way Spring can continue doing what they do without interference form VMWare.
            

            And yet, Rod is no longer a CEO but has some strange title along the lines of "VP of the Middle Tier" or something.
            
            

          Third point they make is that now that they are part of a large company with actual revenue, they can feel free-er to spend their time on the opensource work.
          

          • Ok, so that sounds like they ran out of money.
            

          I don't know. I'm sure I'm missing something, but it looks a lot like eBay and Skype.
          

      Spring is huge. It's the new Java EE. It's the new standard library for Java.
      
      On the bright side, they are building great stuff and it tends to really solve real problems and be really useful.
      

      It is also trully opensourced. So we do get all of the code and we are free to make changes and build it and distributed it, etc. It's Apache licened.
      

      So if SpringSource decided to go crazy and build something silly or try to move the project away from usefulness, there are planty of other projects that will be able to pick apart the codebase and take what's useful (not to say anything about the actual userbase which could also control their own destiny).
      

      However, they are pushing ahead at a break-neck speed. Perhaps it's just me, but I'm still not sure of all the pieces that are in Spring 2.5, which was released last year, let alone having had an opportunity to have used them.
      

      This year - Spring 3.0 comes out. And it has a lot more cool stuff that looks very interesting.
      

      As a user, I'm finding it hard to keep up with them. As an opensource developer, it's not possible to compete with the full-time staff of SpringSource building the Spring platform.
      
      

  • Exhibit 2: Terracotta
    

    • Terracotta, which has just acquired ehcache this summer.
      

      I don't have as much to say about them, except that it's yet another open source project that has a community but not is a community.
      

      They are not as well established as Spring yet. But they have made significant changes since I looked at them last.
      

      • They apparently have a better clustering story. To the point where clients no longer stall and crash when there is a problem on the server.
        

        They also now position themselves as a Hibernate plugin that simply does better caching than ehcache. This makes for a straight (and fully opensourced) upgrade path from Hibernate with nothing, to Hibernate with ehcache, to Hibernate with Terracotta.
        

        • Sounds a lot better than what I remember from before. I believe that before you had to write to their API directly or else it was a different VM that had to be used? Not sure.
          

  • Exhibit N: Google with it's many projects
    
    • Firefox
      
    • Android
      
    • Chrome / Chromium
      
    • etc
      
      
  • Is this bad?
    

    • If there is no free lunch, it follows that somehow we are paying for all of this.
      

      Is that bad? Probably not. But it's good to be aware of the motives of those paying for the pizza.
      

      I'm of two minds about this. One the one hand, I find that it's still open source and it's still good, even if it's not quite the kind of (maybe fictional?) opensource that we are used to.
      

      On the other hand, there seems to be something sinister about the whole thing. I can't quite put my finger on it, but basically these corporations are giving out free stuff (code, products) in order to cause developers to behave in certain ways (i.e. use the products), which somehow leads into the company's business model.
      

      But on the whole, I think this model still leads to better software being built, code being open and available for learning and improvement, engineers having a free hand in what they use, and business success of these companies being more closely tied to the actual value they deliver.
      

      So on the whole - I think we are good.
      
      

Canonical releases source code for Launchpad | Ubuntu

http://www.ubuntu.com/news/canonical-open-sources-launchpad

Very interesting. I think platforms like this should find their way into more of the corporate development landscapes. Especially when distributed teams are becoming the norm.

Automated Acceptance Tests - Myth or Reality? Useful or not so much?

• InfoQ: Automated Acceptance Tests - Theoretical or Practical

  tags: tdd

  • Are automated acceptance tests written at the beginning of each iteration just a theoretical assertion that have been proven ineffective by the lack of adoption?
  • why don’t we just make the tests on a white board, have the programmers implement them one at a time, checking them manually even showing them to the product owner manually and when we are done with it, why not just erase it and forget it?
    • The hope is that they will catch regressions. If not - no need to automate. - post by dserebren
  • Now, consider if the tests written by the QA department are written before the development begins. 
    • How could tests be possibly be written before the software is written? It seems that at best they can be written at the same time as the software (in a TDD way). - post by dserebren
  • One of the things that come out when watching Brian Marick's interview, is that there are many teams doing just fine with unit testing for regressions and manual QA Testing for acceptance tests (ad-hoc).
  • ThoughtWorks is building Twist to give QA and test automators the right kind of tool support to make functional test automation work.

Posted from Diigo. The rest of my favorite links are here.