Venus Flytraps from Seed

Venus Flytraps are generally considered a challenging plant to keep. My experience is that they are not that difficult as long as someone understands the conditions that they need. Growing flytraps from seed is thought to be considerably more challenging. I suppose that I am going to find out.

This is an experiment in progress, so it might still turn out to be a disaster.

Plan:
85 degrees (F) max until germination changing to 80 degrees afterward. Removal of cover after germination. A photo-period of 16 hours per day. One cell of the tray has been left empty so that the standing water level can be monitored. Water should be standing but not above the soil. After a few weeks I should have tiny little traps. After a couple of years I should have traps big enough to transplant into other containers and start a dormancy cycle.

Materials:

• 1 x Standard 11" x 22" Seedling tray with cover
  
• 3 x T5 (Sun Blaze) Grow Lights (mounted to and hung by two 5" square dowels)
• 1 x Heat mat
• 1 x Thermostat
• 1 x Timer
• Some aluminum foil
• Soil mix of 1 part Sphagnum peat and 1 part sand
• 2 gallons distilled water (to clean sand and start out)
  
• 375 Venus Flytrap Seeds (Dionaea muscipula)

Fluent Problem Solving by Elimination

Many problems lend themselves to a solution through a process of elimination. These include the selection of scientific hypothesis, technical troubleshooting, medical diagnosis, etc. I have written a small framework to help solve this class of problems. Additionally, I made a fluent interface to create constraint rules. You can download it from the code samples section.

I am planning on creating a few examples in the near future to show it off, but for this post I just want to give a sneak peek at a couple of lines of Java code that uses it. This comes from a test that categorizes an animal based on observable qualities. This is the definition of one constraint rule that allows the system to know that no mammals have scales or feathers.

constraint = when(skin).is(scaley).or(skin).is(feathery).then(animalType).isNot(mammal);

Here is another that tells the system that only bats have both fur and wings:

constraint = when(skin).is(furry).and(phalanx).is(wings).then(animal).is(bat);

Language Use Cases

Imagine that you are the customer for a new programming language. What three use cases would be most important to you and why?

Searching for more Fluent API patterns for Java

Previous posts cover three patterns commonly seen in Fluent APIs in Java.

1. Method Chaining
2. Nested Interfaces
3. Fluent Builder

So far these are the only Fluent patterns that I have seen used successfully in Java. Does anyone have any examples of Fluent APIs in Java that don't use one of these techniques?

Fluent API pattern: Method Chaining

Method Chaining is the simplest and most common pattern for creating Fluent APIs. A great example is in the Binder class in Guice. It allows you to chain methods one after another in a way that describes the desired results. Here is an example from the Guice User's Guide:

binder.bind(Service.class).to(ServiceImpl.class).in(Scopes.SINGLETON);

The simplest implementation of method chaining can be seen in the Java StringBuffer where the 'append' method returns a reference to itself. This is not exactly Fluent since it does not resemble a natural language sentence, but it works the same way.

This can also be seen in an example from a previous post that uses the CustomerCreator:

Customer customer = createCustomer.named("Bob").that(bought.item(CompactDisc).on("02/17/2006"));

The method 'named' returns another instance of a CustomerCreator such that you can chain the 'that' method off of it. Per usual, I strongly encourage you to download the full example source and play with it to see how these Fluent API pattern can be used in conjunction.

Fluent Query Language Through Strategy Composition

In the last post we created a Fluent API that builds a domain object hierarchy. In this post we are going to create a Fluent API that acts as a domain specific querying language for this same domain. Let's take a look at a slightly modified example from a previous post:

CustomerQuery query = questionThatAsks.whichCustomers(bought(anything(), between("01/01/2006", "01/01/2007")));
List<Customer> customers = query.ask(listOfAllCustomers);

This example creates a CustomerQuery object that is capable of answering the question that has been asked, 'Which customers bought anything between 01/01/2006 and 01/01/2007?'. We could have picked any date or date range. We could have specified that are looking for Customers that bought compact discs. Pretty cool, huh? Can you imagine how it works?

We are doing a combination of two things to get this affect. First we are gathering information about the desired return type base on which builder method we call (ie. whichCustomers, howManyCustomers, haveAnyCustomers, etc.). When we ask 'whichCustomers' we know that we are going to return a query object of type <List<Customer>>. If we ask 'howManyCustomers' we know we should return an int.

Secondly we are using a composing the behavior of our query using a Strategy Pattern. In this case our strategy takes the form of a Predicate. You could expand on your interface with different types of Strategy objects. For instance, you could add a Strategy to do proper formatting base on which builder method you call. Or a Strategy to add select a particular property off of the Customer objects.

You don't even have to even create the intermediate CustomerQuery object. You would just as easily get your answer directly. Take some time to look over the full example source. Then think about your business domain and how a similar pattern could be used to allow you to code in your business logic in this incredibly expressive way.

Fluent API pattern: Nested Interfaces

Multiple Fluent APIs can be used in a nested fashion in order to separate and organize responsibilities while keeping individual classes simple. Fluent APIs can become complex as more features are added if a designer is not careful. This pattern gives a clear and sustainable path for growth. Let's take a closer look at one of the examples from my last post:

Customer customer = createCustomer.named("Bob").that(bought.item(CompactDisc).on("02/17/2006"));

Reading the words reveals in English exactly what is going on with the code. It creates a customer named Bob that bought a compact disc on 02/17/2006. What is going on behind the scenes? That is not quite as clear, nor is it important to anyone other than the Fluent API designer!

Before diving in, let's talk briefly about the domain. We are creating a Customer. Customer's have Transactions. Transactions have Items and Dates.

The first thing to notice is that almost half of this code is fully enclosed in parenthesis. The result of 'bought.item(CompactDisc).on("02/17/2006")' is being passed to a method named 'that'. It is not obvious here, but the 'that' method is on a CustomerCreator object.

Now notice that 'bought' is an object. However, in this snippet this object is not instantiated. Don't be too bothered by this. The declaration and instantiation of this object is just fluff that distracts from the true intent of the code. With some creative use of static imports you can instantiate this object in just one place in your entire codebase and never have to look at it again. Know, though, that the 'bought' object is a TransactionCreator.

TransactionCreator has methods that set Items and Date. In order to chain methods, all methods on TransactionCreator return a TransactionCreator with all appropriate data set. Warning: Do not just return 'this' from such methods. You will need to do a deep clone or you will likely have very interesting things happen unexpectedly when you change data on one Transaction and it changes on all the others as well.

The object 'createCustomer' is very similar of type CustomerCreator. It creates a Customer instead of a Transaction. However, it follows the exact same pattern as TransactionCreator. Methods 'named' and 'that' are both on the CustomerCreator class and both return cloned CustomerCreators that have had some piece of data added to it.

The final piece of the puzzle is that CustomerCreator and TransactionCreator extend Customer and Transaction respectively. This allows for method chaining that can end at any time and still give you an object of the target class.

I strongly encourage you to download the full example source and look through it. Fluent APIs do not need to be overly complex, but they are a drastic shift from traditional interface design. Don't give up even if it takes a while to really understand. The benefits are worth the learning curve.