Posts

Showing posts from August, 2013

scala and composition and extension patterns

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

OSGi as a distributed operating system application manager

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 AppDomain

scala, creating software and decoupling software components (and increasing cohesion)

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