Application Development Meanderings

The Problem I have an app that uses neo4j as the underlying database. Similar to all database applications, I also have a data access layer that helps abstract out the use of neo4j. The data access layer takes in string parameters, mostly, finds the neo4j nodes or relationships then manipulates the those objects to create a new object. In this access layer, I must gather several different objects together to process. For example, the start node, the end node, another node that holds my dynamic type system, and various other objects. When assembling these nodes, I typically find the pattern to go something like this: Check the input parameters Find the objects. This step typically takes an input parameter, then finds the object. Then use that object, in sequence, to find another object and so on. With all the objects assembled, create the new object The standard approach that I use for error handling is to throw as few exceptions as possible. Instead, I would rather ga...

I had the chance to read the Manning SPA book. It is a great read and I encourage you to read it. It describes how to use the browser as a deployment platform for your application and to develop your application all in the client (the browser) using javascript. The central idea is that a SPA is a desktop application really in that most of the logic, except data access, occurs on the client. Based on the description, there is a launcher html file that is used. It specifies most of the javascript and CSS resources you need for your application. And there is a specific, or at least recommended, way to manage your javascript code for scalability, etc. It recommends that you manage your "single page application" from the javascript. This is all good stuff because I see most of the execution in a variety of frameworks really moving to the desktop. Some frameworks are still more server centric. Essentially, in a SPA, you do not do the puts/gets etc. back to the server, the javas...

The cake pattern is typically described as a way to use small layers of functionality to create a larger, more complex program. This area of application design is typically designed with application scalability not in the pure performance sense, but in the sense of scaling the application up to more complex functionality and maintainability over time. There have been many papers and blogs on this aspect, but a few especially helpful blogs include: http://debasishg.blogspot.com/2010/02/scala-self-type-annotations-for.html http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di https://www.precog.com/blog-precog-2/entry/existential-types-ftw https://coderwall.com/p/t_rapw All of these describe the cake pattern but they all look alittle different and a reader may be left to wondering why are there so many ways to describe the cake pattern? The confusion is warranted. The Cake Pattern is really more of a design pattern than a specific, set- in-stone programmi...

I have been using neo4j for awhile now and I think I have begun to realize that the Node class is really a data transfer object in disguise. Some applications can use it directly, and that's okay and you should because it is simpler to use than other options. Because I need to have to perform other operations on nodes prior releasing them, I need a first-class DBObject type that allows me to use interceptors and various other processing schemes to meet the requirements of my application. For example: Lucene indexing: I need to create special external lucene full text indexing that uses quite a bit of the lucene engine. I need to manage that index in one place where the updates, adds and deletes occur. Property change event: I need to send events when the properties change so that my UI can be updated appropriately. For some properties on a node, I need typed access. I could use a simple wrapper around a Node and access the Node's properties when I need to obtain a va...

Ok, I admit it, after struggling through monads, I know understand them at a basic level and their value.  There are may blogs out there that are really good but I will call out the haskell blog being especially helpful. There seems to be alot of noise, at least 2-3 years ago, around the IO monad in particular. According to the haskell blog, the IO monad helps mark computations that perform IO. Since haskell is a pure functional language, which means no side effects in functions, the IO monad helps delimit the scope of where impure operations are performed. In this use, it is like a marker. However, in scala, which is an impure functional language, functions can have side effects. So is there value in the IO monad? Maybe, but it may be awhile before I see where that value is. Since I can contain side effects and mark them using types e.g. a DAO object for database access, I'm okay for the moment not using the IO monad but I can see where the general concept may be useful for n...

Based on some recent scala work and coming from imperative programming background, reading functional programming code is hard for me. Why? First, the code is rather terse and dense. The terseness derives from the ability to use operator-like characters as  function names. Java does not allow this so its usually easier to read the methods. Java's method name conventions generally make the code easy to read. This comes at the expense of verbosity. Scala can use normal function names as well and most libraries provide both the function name as well as a terse equivalent. Second, its not always clear what design pattern is being implemented. Java has a few generally accepted approaches to writing code. Iterating over a list can only take a few forms. Creating some IO classes generally takes on only a few forms as well. The singleton pattern is implemented only in a few ways. If you are unfamiliar with functional programming, it takes awhile to recognize these types of patte...

As you may have noticed, I have published a few blogs on using the scalaz library.  As I have worked through some examples, I had a growing feeling that scalaz was hard to use. For someone new to scala, this is true (let's ignore the lack of documentation issue for now). Why is this so? After thinking about, I realized that scalaz is designed to implement solutions to a variety of functional problems. These typically involve monoids and other structures. Monoids operate at a small scale. In other words, they are each designed to do a very small job. Because each part of the library is designed to do a very small job, they are ideal for implementing software using small, concise layers. Since monoids encode the programmer's intent into the type system (e.g. State, Reader, Writer), scalaz has many types of class that all perform small, monoidal jobs. The scalaz library is not designed to be a full dependency injection library, say like spring or guice. spring implements a...

As I was working through some content on the Reader monoid, I realized I wanted to lift a function to use it. If you read the Scala In Depth book, which as a really great book, you know that lifting a function to be monoidal could be useful. The classic example is to lift the function so that the arguments as well as the return value are all Option types. Then, if any of the parameters to the new lifted function are None, the function returns None. Otherwise it would return Some. The key thought is that you do not have to write your own, scalaz already supports lift. It turns out that scalaz has support for lifting functions using your monoid of choice. Below is a transcript using scala REPL  with a -cp set to the scalaz core library: See the entire post on  github .

Someone asked how you run the code examples on my blog. I have started using gisthub to store the entire blog, including code. To run the code, simple go to the gisthub. Cut and paste the code into a file. Then run it through the scala REPL. I do scala -cp ./scalaz-core_2.10-7.1.0-M2.jar  yourFile.scala Where yourFile.scala is the file that you save the cut and paste into.

I just put together a short blog on the Reader monad in scala, its similarities to State and some mentions about comparisons to spring dependency injection. You can find the article on  github.

As a follow up to my last post about no free lunch I wanted to show more state monad usage and recognize that you can change function return types in the middle of a for-comprehension. This allows each function to return different types of values from the computation along the way. In the code below, you compose a function by using the for-comprehension. The yield part of the for-comprehension is a State object. When that state object is called, it returns a tuple of (state, value). You can use ._1 or ._2 to obtain the value of interest. The last composed function shows an example of changing the state type (instead of changing the returned value type mentioned above)  in the middle of the for-comprehension using scalaz IndexedState's iPut and iModify. This allows you to change the type of state as you go to adapt to different function's API needs. The entire article is at  gisthub .

I was working on using the State monad in my cake example, but needed to fiddle with some simple examples first. The code below can run in the scale REPL. The main thought is that if your system is already setup to handle the state type already, say by sharing a cache, then you modify your code to return states and the State monad can help you sequence and ensure that the state information is available for each function call. However, if you are accessing resources that do not return state information structurally aligned with your state value, you still have to use some ugly code to convert a function's return value to the structure needed by your state. When using the state monad, you can pull that code out of the functions you are calling which is good, but you still have that code and its still messy--no surprise here. It's clear though that the components you are using must be designed to use the same state structure. This last point effectively makes this design patte...

It has taken me awhile to understand monoids and their use. Once you get the hang of it, they make a lot of sense as a design pattern for structuring your code. Either, Option, Try are all monoids that can help structure your code and adapt existing code without changing the existing code or they help in structuring new code. It also took a while to understand for-comprehensions as well. It turns out that switching monoids types in the middle of a for-comprehension is not impossible but difficult. Its best if each statement in the for-comprehension has the same monoid return type. On gisthub: https://gist.github.com/aappddeevv/6530787 in case it does not display below correctly. 1: 2: // Define functions that return an Option 3: def f1(x: Int): Option[Int] = Some(x*30) 4: def f2(x: Int): Option[Int] = Some(x+3) 5: def f3(x: Int): Option[Int] = Some(x*2) 6: 7: // Sequence the computation, it will be successful 8: var answer = for { 9: x <- f1(30)...

I realized I need to be able to explain the differences between the cake pattern in scala and spring dependency injection. As in my last post, I wanted to understand how to compose objects to build applications. I've become a scala fan because alot of things make sense, although it takes a long time (at least for me) to learn a more functional style. The reason I want to compare the cake pattern to spring dependency injection is because each approach has trade-offs. I'll try to call those out more carefully than I have seen written elsewhere. There are a number of blogs you can find on the cake pattern and it is a pattern often covered in functional programming books. Here we go... Composing Using Plain Old Java Lets ignore all dependency injection for the moment and just think about plain java. We want to compose objects. For example, we have a software component that is dependent on other components. In java, we have two ways to handle this. Inheritance and Bean Prop...

I thought I would create a list of the compositional and extensionable approaches in scala. Some of these can be done in java and other languages but may require more work or more source complexity which outweighs the benefit. I reviewed a number of books and articles and I have tried to cull out the patterns. Some of these patterns require you to modify existing code which may decrease the value of the pattern because the code is frozen or owned by a third party. Some of these patterns allow composition and extensibility without touching existing code. Some of these approaches are made more difficult in scala, say compared to groovy, because they employ static typing so you need to make sure the benefits of static typing outweigh the cost of complexity. Traditional inheritance composition: This is the standard approach to ensure that a subclass of some sort has the requested behavior and in some cases, properties, that you want to mix. In java, a method specification can really b...

I was looking into a few components that I would need to implement some distributed processing. Akka for scala  has a small microkernel that runs on a node that you want to run a remote akka actor on. Communication with the remote actor is transparent. Similarly, hadoop has its process framework that runs on nodes that helps with job control, resource management, etc. (the naming and data nodes). So essentially, all distributed software has some sort of manager that runs on a node. That process may run constantly, or it may only start up when the job starts that runs distributed. The manager helps with starting and stopping processes, arranging for resources to be available and other such . Some more layers are needed of course to handle distributed processing, such as synchronization and coordination primitives that operate across nodes. If you think about OSGi, it allows programs to dynamically start and stop. It allows programs to share services. Its alot like the .NET AppDo...

As part of the application development process, I regularly look at new languages. Recently, I had reviewed and used, fairly extensively, groovy. Groovy programmers can start with java, then groovify the code incrementally. There is almost no "learning" tax and is fairly simple. I found myself using closures and and extension methods to help adapt some 3rd party libraries and make my code cleaner and more compact. I used many of the more functional list methods as well. Based on some of the comments around groovy, I thought I would also look at scala. I am glad I did. Scala is more focused on static type checking then groovy, which is dynamic in nature. Scala recently also added dynamic methods for those times you need them (groovy added more static type checking to their language). Both have some functional flavors, although I did find scala's functional roots more deep than groovy's. After reading several books and blogs, I worked on some code. I was surprised...

I've been looking to do a real UI in javafx and compared to WPF, I am still finding it to be alot of work. In particular, creating tables and customizing everything for my domain objects. In WPF, I built a reasonably interesting interface in 5 days without knowing WPF and that includes working on the domain object. In JavaFX I am finding it slow going on doing controls that need cell factories and other apparatus that apparently is only available to be created through code, XAML was just easier for me. I wrote almost no UI code in WPF. I did write XAML files directly in XAML because they had a nice editor that showed you the results of your XAML file as you typed it. The JavaFX team really needs to sit down and crunch on making it easier to build UIs and bind to my domain objects to get the content into the controls. I do not think its an issue with the relatively complex Callback interfaces either. I think its because they are not thinking of how to create something easy to ...