Functional Programming for the Object Oriented Programmer

Uncle Bob reviews the book Functional Programming for the Object Oriented Programmer:

We need something to bridge the gap between the huge population of OO programmers, and the growing need for functional programmers.

And continues about functional programming in general:

you’ll also learn a lot about OO that you may not have known before.

I could not agree more. When I discovered LISP ten years ago, I realized two things. First, there is much, much more to discover in programming than we Algol 60 programmer would think. Second, this holds especially for object oriented programming. The C++/Java point of view is just one way to apply OO.

Stop hesitating and tip a toe into functional programming.

· Tags: , ·

How Google tests its APIs

In “Testing Google’s New API Infrastructure“ Anthony Vallone describes how Google tests its public APIs which are available for different programming languages and platforms:

As of this writing, we have released 10 language-specific client libraries and 35 public APIs built on this infrastructure. Also, each of the libraries need to work on multiple platforms. Our test space has three dimensions: API (35), language (10), and platform (varies by lib).

Instead of testing all possible combinations, they use a dedicated Test API:

We want to avoid creating library-specific tests, because this would lead to mass duplication of test logic. The obvious solution is to create a test library to be used by all tests as an abstraction layer hiding the various libraries and platforms. This allows us to define tests that don’t care about library or platform.

See the figures for details.

· Tags: , ·

Rootbear: Run Java Code on GPU

From their description on github:

The Rootbeer GPU Compiler makes it easy to use Graphics Processing Units from within Java.

And it has been developed in TDD style:

Rootbeer was created using Test Driven Development and testing is essentially important in Rootbeer. Rootbeer is 20k lines of product for and 7k of test code and all tests pass on both Windows and Linux. The Rootbeer test case suite covers every aspect of the Java Programming language except:
1. native methods
2. reflection
3. dynamic method invocation
4. sleeping while inside a monitor.

(via slashdot)

·

Property based Testing for Domain Models

Debasish Ghosh describes the benefits of property based testing compared to traditional xUnit style testing. He advocates to use libraries like ScalaCheck1 where only the property to satisfy by the production code is described and the library generates the test data to check the property with:

I don’t need to construct concrete data by hand (in fact this is what makes xUnit based frameworks a sophisticated manual testing system – it only automates the execution part of your testing).

Example:

property("Enrichment of a trade should result in netvalue > 0") {
  forAll((a: Trade) =>
    enrichTrade(a).netAmount.get should be > (BigDecimal(0)))
}

This method shifts writing test from how to test to what to test.

· Tags: , , ·
  1. Similar libraries are available for many programming languages; cf. http://en.wikipedia.org/wiki/QuickCheck↩

With Proper TDD, You Get That

Dariusz Pasciak describes how developing software without TDD is like and concludes:

Test Driven Development is an art that every software developer ought to learn and practice to at least some extent. Even if you don’t think it’s useful, even if you think it’ll be a waste of time – if you have never tried it before (for real), then try it. And I’m not talking about one week or two weeks of “ok fine, I’ll give this thing a shot”. I mean really get yourself motivated, believe that there are many benefits to reap from this practice, and invest valuable time and energy to figure this thing out for good. Then, once you get it down, use it on at least a few projects, see the difference it makes. Treat it as a college course, or as preparation for a marathon.

And by all means don’t just do it so that you can say you’ve done; if you approach it with that kind of attitude then you’ll have wasted your time. Don’t cut corners. If something is “too hard to test”, don’t skip it – spend hours if you must, but figure out a good way to test everything. Explore different ways of doing this, get help from others who live and breathe this, and really figure this thing out. It’s worth it.

Please, every doubters and hesitaters, read this article. Seriously, read it!

· Tags: ·

10 Application Performance Tuning Tips

Mirko Novakovic gives “10 Application Performance Tuning Tips“. I like the first two tips the best:

1. Define the requirements
2. Measure don’t guess

I’m regularly shocked how casual many developers are about these two tips. Many developers start to write software without considering what exactly they are trying to achieve. But without requirements you cannot check, if your software is correct; as Mirko points out for performance requirements:

How do you measure “fast”? Is 8 second fast? Or 1 second?

The same holds for premature optimization lacking a sophisticated analysis. In this sense sophisticated does not mean running your software with some sample data and a profiler on your development machine. It means monitoring your software in production use over time. That is where you will find the real bottlenecks.

·

★ Type Systems Save You from Bugs

In Types and Bugs Rafael Ferreira discusses the advantages of type systems that help to discover bugs which unit and integration tests cannot find. He references a very interesting paper in which the author describes how he discovered bugs by porting an algorithm from Python to Haskell. Rafael stats

 Most of the bugs fell into one of two categories:

  • Assuming that a variable always references a valid value when it can contain a null value.
  • Referencing constructs that no longer exist in the source.

NULL is definitely the most annoying concept ever invented in programming. Briefly, it is just a special construct signaling invalid values. NULL is the source of a plethora of bugs, e.g., when “Dereferencing NULL Pointer, without a Seg Fault“. Today, we have programming languages that express invalid values much cleaner and type safe. See for example Scala’s Option type.

Rafael continues

some method or variable was present but changed, perhaps it was renamed or subsumed, and not all references were updated to reflect the change. Even pervasive unit tests can’t hope to catch these kinds of regressions, as the problem is found on the integration between units of code; the units themselves are just fine. A type system helps when the change affects the signature of the referenced construct, which is often but not always.

You cannot always chose the programming language, because of dependencies. But if you can, use languages that have sophisticated type systems. They safe you from a lot of trouble just by running the compiler.

 

· Tags: , , ·

Quality is mixing Development and Testing

In his book “How Google Tests Software” (Amazon affiliate link) James Whittaker writes

Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

This is the essence of the mindset that you need, if you want to successfully apply Test Driven Development.

Actually, that is the mindset you need, if you want to succeed as a developers at all, today.

· Tags: , ·
← Previous Entries Next Entries →