I recently blogged about Functors and mentioned a mysterious beast called Applicative Functor. Here is a simple, complete example that shows how you can use Applicative Functors with the Scalaz library, with references for further reading.
[...]
In the world of functional programming you will quickly come across the concept of a Functor. What I present below is a simple example that might provide some intuition, with references for further reading.
[...]
Over the last few months, we’ve been working on delivering HSBC’s Clearing Connectivity Layer and OTC Cleared Trade Acceptance System. We went live early December, and in fact, we delivered our first release early.
I wanted a very tiny example of using the IO Monad in the brilliant Scalaz library, and here it is.
One of Casual Miracles’ clients had a long running project with a big specification up front. This is not the mode in which we usually like to work. It is, however, an opportunity for an experiment with burndown charts.
How would this be done in an earlier age?
This is the question I frequently ask myself when searching for the names of domain concepts.
The typical architectures and layering of code in ‘the enterprise’ frequently exhibit poor systems of naming which causes developers to jump through hoops to try to maintain the layers because of lack of abstraction. This in turn results in an unwieldy codebase that is more concerned with accidental implementation complexity than codifying domain knowledge.
One of the characteristics of many teams that Casual Miracles has helped over the past few years is that team members have felt a lack of authority to make changes that are necessary to achieve success. Frequently this occurs despite senior management telling them that they can make the changes they want to.
I attended Scaladays 2010 at EPFL in Lausanne, Switzerland in April. at which Nigel Warren and I presented the work we had done on porting Fly’s Java client library to Scala. You can watch all the Scaladays videos on the Scaladays website and so I will not dwell on the talks, which were excellent. Instead, I want to talk about Scala and its community, led by Martin Ordersky.
Over the past six months or so, there has been a fair amount of negative commentary about automated acceptance / integration / system testing. The thrust of this commentary is that testing at this level tends to be brittle, slow and have a high maintenance overhead. None of this needs to be true, but producing a robust suite of tests requires an uncommon adherence to good practice.