Wookiee Components

As I mentioned in my previous post, an Open Source project that I affectionately called Wookiee. You can check out the open source code at http://github.com/Webtrends/wookie, if the link fails it is most likely because we renamed the repo to wookiee with the extra e, so that it is the correct spelling. This blog post will be all about components and why I think they are awesome. I might create a series of blog posts about this, and after this post create a tutorial on creating a component for your service.

Wookiee without components

So firstly what does Wookiee look like without components. Well if you had to clone the repo, build it and run it, which is a little tricky because we don’t really tell you how to do that, it would start up all nice and say it is ready. However it really would only be able to do a couple of very limited things, one of them is respond to ping but that is as exciting as it gets. Without components this is a very sad existence. Nothing to do and nowhere to go. Now of course you could write a service on top of that, and run the service. And this would work even if you don’t add a single component, but you would have to build a lot of boiler plate code and at the end of it you might question what was the point of starting with Wookiee to begin with. And this is where components fit in, and why I think they are awesome. Wookiee is lightweight and purposefully so, which is why starting it up without any components doesn’t really do anything. The core of Wookiee really only contains the infrastructure code to support primarily three things, Commands, Services and Components. In a blog post I wrote for Webtrends you can see a introduction to these ideas.

Really though what is a component

Components are primarily libraries that plug into the Wookiee’s communication bus for easy access from any Service that sits on top of Wookiee. The key to a component is that it is resusable. So lets say I want to write a component that adds Spray to my Service, which we actually did write one. This way instead of having to write any Spray code over and over again I simple add that dependency into my project. The more components there are too choose from the more options have to use for my particular service. Wookiee has 10 components that were build with the release of the framework:

• wookiee-cache-memcache
• wookiee-cache
• wookiee-cluster
• wookiee-etcd
• wookiee-kafka
• wookiee-metrics
• wookiee-netty
• wookiee-socko
• wookiee-spray
• wookiee-zookeeper

So by default you can pick and choose what you want to start with and go from there. So as an example you can plug in one of three http based technologies (Spray, Socko, Netty) that will immediately give your service http ability. Of course there are many pluggable frameworks that you can choose from. The difference I find is that a lot of those frameworks are firstly primarily web based frameworks and often over time get pretty heavy at it’s base. Wookiee should never get heavy at the base simply because the base is designed to be incredibly lightweight and the added components will only make it as heavy as you want it to be.

I don’t get it

Ok so maybe this isn’t the best explanation. I have tried to describe it to people, and I think the difficulty often is that a lot of these concepts are not new. And so often when I speak about it they shift to the examples they know about. However sometimes showing someone how easy it is to do it is worth much more. So in the next couple of blog posts I will be creating a mini tutorial that will build an mini service that uses the Spotify API. I will use the Spray component and build a new component called the wookiee-spotify. Hopefully it will be helpful to anyone who is interested in building new components for Wookiee.

Webtrends Wookiee 1.0 Released

For the last half of 2014 and  the beginning of 2015 I was working on an open source project called Wookiee.  I am quite proud of the results of this project, and even prouder that we were able to open source it. This being my personal blog, I am not expounding to greatly on it here particularly as I wrote a Webtrends Blog post regarding the release of Wookiee, and so instead will link you directly there.

I will say that I am super happy that we were able to open source this project and hope that there are other people who will get use out of it. I am really proud of the results of this project and really feel that it is a beneficial tool. If anyone is interested in it, let me know and I could possible give a series of blog posts in a tutorial style fashion to explain it more in depth. Although I would encourage you to look at the docs in Github as they are fairly helpful.

Mob Programming

I want to first off state that my experience in Mob programming is extremely limited. I joined a group of guys (4 other guys) who had been doing it for a couple of months, and sat in for a little over an hour trying to be part of their process. So I am basing a lot on a very limited experience, and understand very clearly that I bring my own bias into this post. I had only recently heard of Mob programming which is basically taking pair programming to the extreme. The concept is to take everyone in the team (or at least part of the team) and have them basically code together. There is one guy designated as the driver (the driver can change during the course of the session, but only one at any given time) and the team as a whole discuss what needs to be accomplished while the driver writes the code and anything else required.

What I liked about it.

• Collaboration
  The collaboration amongst the team is incredibly high. Everyone is part of the process, so you don’t generally have a developer that “owns” this part of the code. Part of this may have been due to the level of experience in the room that I was a part of, however I believe that this would carry over to groups of any or varied experience. From this perspective it was an incredibly beneficial exercise.
• Group Knowledge
  This works in two ways. Firstly every developer has their own knowledge set that does exactly overlap with any other developer, and so bringing all those skill set’s together allows solutions to be more robust and almost certainly less prone to bugs and especially large destructive bugs. Secondly it helps developers not only understand all the pieces that are being built, because they are being built together, but it also helps increase the knowledge sets of all of the individual developers knowledge.

What I didn’t like about it.

• Efficiency
  I find this method of development incredibly inefficient. In my short session there was a group of senior developers, all very talented, but it took an hour to do a very very basic thing. Something a single developer could have done in probably 15 minutes. And I even say that conservatively as I was not part of the team, just seeing what it was all about, and I felt I could have done the work without any previous knowledge fairly quickly. However in saying that I gained a lot of knowledge about the system in a very short period of time.
• Design by Commitee and Groupthink
  These two concepts were not especially prevalent in the particular meeting I was a part of, however I saw some trappings of it and I can easily see how this could push itself to the surface without too much trouble. For more information basic on these you can go here and here.

In general I can’t say that I would be a complete advocate for Mob programming. My biggest issue with Mob programming, pair programming or even meetings in general is that all these concepts are basically forced collaboration. If a team is not collaborating well together we try to force it, which I believe can end in disaster. I don’t think it is not possible for a team to use mob programming or pair programming effectively and have it help foster collaboration, but I believe a team that is collaborating well outside of these “forced” interactions is a much more agile and efficient team. Of course the world is not perfect and sometimes these things will help and sometimes they will make things worse. It is up to the team to figure out what is the best way to move forward. If it means that they require mob programming because they are continually producing poor quality code with large bugs then mob programming may be helpful to stabilize the code base and foster great communication within the team. In the end it is something that can be good or bad, depending on the users of it.

Personalities can also have a strong impact on mob programming making it better or worse. If there is one very strong individual, they can dominate the conversation and cause serious groupthink to set in, especially if the other developers are non-confrontational. If you have a bunch of ego’s in the room you risk the design by committee problem and everything built becomes a difficult and fragile compromise.

Anyway I understand that I can come across as negative towards it, however I did have a positive experience with it. I just see pitfalls that may not work in each and every situation, and I struggle to see it working well in more than just few situations. Take my words with a grain of salt however, research it and if interested enough try it out at least and see if it is right for you.

15 Years of Programming

I thought the other day that I have spent a good portion of my life programming, or at times at least trying to program. Professionally I have done it for 15 years, but I still remember the first time I started attempting to code. I was around 6-7 years old and my father had bought a 286 pc. This came preinstalled with the latest MS-DOS, which had two things that really got me, Space Invaders and BASIC. Of course Dijkstra once said,

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

So BASIC was my first entry into programming, fortunately I guess it was short and so hopefully I was not scarred for life from this experience. But I remember building programs that did odd things, like lines being drawn all around the screen and then bouncing here or there, also more straight forward things like simple calculators. My new hobby progressed through Pascal, C, C++, Java and various other random languages along the way. However in my professional career I have spent most of my time coding in Java and more recently Scala. Either way I believe a great programmer is more about how you think rather than any one specific language you may know. But over the years here are a couple things I have learnt. These things are more related to professional development and not as a hobby, however it could applied either way. It also is quite random, these are obviously not all the things I have learnt, just a couple that sprung up in my mind.

• Mistakes are not bad

We live in a society that pushes us to always be right, to always do the right thing and to never make mistakes. Mistakes are considered bad. Mistakes however usually get you to your destination quicker, help you learn invaluable lessons. Best practices are built off years of mistakes that help us understand how something should not be used. I remember early in my career I never wanted to make a mistake, and so I hesitated, I didn’t make changes to code I felt was badly developed, and especially if it was developed by more senior developers. Now as someone more senior than most others in my current role, I understand how much of a poor mindset that was. Firstly senior developers are not gods, although as a junior developer sometimes it does seem like they are able to understand things quicker, figure out issues quicker. The reason for this is simply that we have made more mistakes, and so we see an issues and are able to reference a much large larger set of mistakes to decipher what is going on. Which also brings me to the next point.

• No one is nearly as smart as you think they are

As a junior developer, senior developers often seem a lot smarter and just generally very confident of our abilities. This at times can make it seem like we are really smart. The thing is yes most people in our field are pretty smart individuals, but I guarantee you that it is very rare that the person you think is so smart is really even nearly as smart as you think they are. Experience is mostly the key here, now sometimes there are individuals who are really really smart, genius level, however it will be very rare that you ever work with these individuals. Not saying you wont, but just based on numbers it is unlikely. So try not to be intimidated by these individuals, especially the individuals who are overly confident or cocky.

• Few are as smart as they think they are

The other side of the spectrum is people who think they are really really smart. Generally the rule of thumb is if they think they are geniuses, they are not. I have met only a couple certifiable geniuses. The kind that are so smart that their brain has overcompensated in one area and often social skills is the first thing to decrease, which maybe they could explain to me. Anyway most people think they are above average, however again just by numbers most likely that person is simply average. Not that they are not able to be great developers, but they most likely are not that much smarter than you. The difference between a junior and senior level developer has less to do with how smart they are and more simply how much experience they have and how willing they have been to fail, and even more importantly how willing they are to learn.

• Debugging is your greatest learning tool

Debugging is super fun, honestly if you don’t like debugging then most likely you are in the wrong career. Writing code is actually probably what you will do the least. Well I would say hopefully it is the least and hopefully most of your time is not spent in meetings or dealing with bureaucracy. Ideally a developer will spend most of their time either thinking or visualizing the problem set, or debugging to get an understanding of the problem set. Cases where this may not be the case, may be in fields that I have less experience in, however even then I am guessing that the figuring out the solution (not actually writing code) is more complex. Granted figuring out the solution may involve prototyping, but I think you get the point. Anyway, back to debugging, this is where you can get into the nuts and bolts of how the software works. And if you didn’t write it, documentation, API’s and the code can give you a lot of insight. But seeing it work in action and tweaking things as you go to see the effects is honestly fun. The rise of open source has opened this up so much, and I have personally enjoyed debugging open source projects to see how it works.

• Always be Learning

I initially had this heading as “Always be reading”, however felt that this encompassed the idea more. You should be constantly learning in your job. Often times this means that you must be reading a lot. But this career is constantly changing. Also understand that you will never ever be able to understand it all. But even basic understanding of different fields, even fields unrelated to computer science can be helpful. It develops a mind that is always in pursuit of knowledge and always trying to figure out solutions to puzzles. Never stop wanting to learn, when that starts happening maybe it is time to retire this profession. There will always be new things to learn and don’t let your seniority get in the way of your learning. Sometimes people will stick to things they know because that is how it is always done. Listen to people with less experience as often their insight is invaluable as they don’t realize that their suggestion is “not correct”.

These are just my random musings, there have been various other things that I have learnt over the years. I think the last one is my favorite. It is a great career to have because it is constantly changing, there are constantly new challenges, new boundaries to be broken and new ways to develop things. Don’t forget to continue to be having fun, if you aren’t, find a new job, start up your own software company, contribute to an open source project. But don’t let yourself get stuck in something you hate. As Steve Jobs once said:

“You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle…

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

Coding Styles – Commenting

This is an odd topic actually, and I say this because of all the things that can get coders heated you would think that this would not list very high. However every coder has there own style of coding, some are very distinct and sometimes if you know someone well enough you can tell if they wrote some piece of code or not. And there are various different style methodologies out there and each language, or set of languages, also has a particular style associated with it. Java for instance will often look very different from something like Perl, but similar to C#. And there are various types of styles, for instances there is ways you indent, ways you space, ways you define your method and variable names and everything in between. The reason why it is all so heated is because if you are working in a team, reading other people’s code is important, and if you have a standardized style it makes things easier. Maybe in other posts I will talk about each one, but in this post I want to talk specifically about commenting because often times it is the last one thought of, and sometimes sadly forgotten.

Why Comment?

So if that is your first question then I think there are a couple of developers who have worked on your old and crusty code that you did even just a year ago that are not happy with you. Or you are not a developer and I am not sure why you care. Sometimes I will hear this statement “The code is the documentation” which firstly is a stupid comment but also doesn’t mean what that statement actually suggests. Firstly what they are really saying is “My code is clean enough that I don’t need to comment, as the code speaks for itself. And secondly documentation is always needed and something wholly different as there will be enough people who don’t care at all about looking at your code. And yes there is definitely a lot to be said about writing clean code. But let’s be honest, how many times have you gone to look over old code and realized how crappy it looks, or worse you completely forgot what you were doing even though it is really clean.

Clean Code

So as I mentioned above, clean code is important, simple code is important, the simpler and cleaner you write your code the less problems you are going to face, the easier it will be to debug and it will be much easier to maintain. So then if your code is clean then shouldn’t the code speak for itself? Yes it definitely should and will, but there are two problems with thinking like that. Firstly I have never met a developer who has coded cleanly 100% of the time, whether it is due to time constraints or simply trying to fit a square peg into a round hole because some sales guy already sold that feature, whatever the reason we developers cut corners at times, we hate ourselves for it, but most of the time understand the necessity. And how often do prototypes somehow become production code? But secondly, we erroneously believe commenting is this:

//In this for loop we are making sure we go through each character in the string
for (int i = 0; i < str.length(); i++)

And honestly this is quite a silly example, but I have seen variations of this all over code. Basically commenting above a line explaining what a line does. This is educational type of commenting, which is fine in some places where you are trying to teach someone to code. It helps them to understand what is happening in code that they may not understand. However as developers most of the time we should easily be able to read the code and understand immediately technically what it is doing. There are definitely scenarios where explaining what the code is doing is important, a simple example would be this:

// Insertion Sort Method for Descending Order
public static void InsertionSort( int [ ] num) {
  // the number of items sorted so far
  int j;                  
  // the item to be inserted   
  int key;                
  int i;  
  // Start with 1 (not 0)
  for (j = 1; j < num.length; j++) {        key = num[ j ];     // Smaller values are moving up     for(i = j - 1; (i >= 0) && (num[ i ] < key); i--) {
      num[ i+1 ] = num[ i ];
    }
    // Put the key in its proper location
    num[ i+1 ] = key;    
  }
}

I pulled this code from a site that was explaining how insertion sort works, and left all the comments in as I thought it would be a good example. Firstly there really is only one comment that is useful, which is the first comment. Now we know that the method name tells us exactly what it is and method names should be part of commenting, it should always try to be clear in what it is doing in this case insertion sort in descending order. Every other comment in that algorithm is only useful in the educational type of setting. They would not generally tell a developer much more than a cursory glance at the code would, but only based on the first comment and method name. We have a starting point for what we are looking at, so we use our knowledge of the insertion sort algorithm and looking at the code to get all the information we need.

Now the comment “// Start with 1 (not 0)” is a perfect segway into what I believe the majority of true commenting should look like….and it is the complete opposite of that. I have alluded to this problem but here is the most perfect example, a developer would actually take longer to read that comment than it would take them to read the code and get the same result. “for (j = 1….” tells us very precisely what that comment tells us. The thing that it doesn’t tell us is why. Why do we start at 1 instead of 0, and this is what I believe commenting should focus on.

Why?

So why? Why do I need to do this? In the professional field most of the developers are always learning but due to experience we understand higher level concepts and we know how to use Google. We can figure out things, it is what we do. However the why question is something I hear all to often. “Why did they do this here?” We look at code and we understand precisely what it does, but we have no idea why the previous developer did it here or why they did it at all. And that previous developer may be the same developer looking at the code. How many times do you look at code you wrote even just a year a go and go, “Why did I do that?” So back to our comment “// Start with 1 (not 0)”, a better comment would be “// We start with 1 because the insertion sort algorithm will check the 2nd element with the first element during the loop”. Now granted the following is just an example and honestly in this particular case you wouldn’t need the comment at all, but the principle is the same.

But my code is clean

We comment not because we want people to understand the mechanics of what your code is doing, we comment to help people understand why we did it. The cleanest code in the world doesn’t always explain what your rationale for doing it is. You could have a specific reason why you are using a HashMap in a threaded environment and another developer comes along and is like hey we should change that to a Hashtable to deal with possible concurrency issues and then breaks something. And worse if you aren’t with the company anymore you now have a bunch of developers trying to debug your code because of a production bug and might not even think that it is the change from HashMap to Hashtable. Why are you doing what you are doing? And if you do not know how to word it yourself maybe you should rethink what you are doing anyway.

How to build a habit of commenting

The best way to address these commenting concerns is actually fairly simple, however requires discipline. I find there are generally speaking two places that the why questions occur. At the class level and at the method level. If we explain to the reader of the code what the class is used for and why and the same thing for the method, we get a long way to explaining a good portion of our code. There are definitely various other places to explain maybe why a certain data structure or anything like that, but classes and methods are a good place to start and a good habit to get into to explain each and every class and method you build. There are always exceptions to the rule, but it should be an exception and not the rule.

Spray.io Custom Directives

path("hello") {
  get {
    complete("world")
  }
}

Above is a basic example of a http route using spray. So if you had to start up a server with that bit of code you could then use http://127.0.0.1/hello and would get a response “world”. Ultimately spray is fairly easy way to get things working, and if you are building an application it is very useful to create routes quickly and easily for your application. And for more information you can look here.

But Spray is more than just basic routes. The “path” and “get” functions you see are directives that get you the results you want. In this case the “path” directive is going to look for the path “hello” and the get directive is going to check if the request coming in is a get request. Recently I have found a desire to build custom directives. These are directives that I can code that will allow me to add custom functionality into my routes. Or as was my goal to build routes automatically. I will not go into the reasons why I was trying to do this, however it become clear that the best way to approach this would be to use custom directives.

What I needed

For my particular use case I needed to build a path dynamically from a custom string and add all the parameters from the request into a map and have the map be available in the next step of the Spray DSL. So in the end I would want something that would look like this.

customPath("path1/path2/$var1/$var2/index") {
  params =>
}

The params variable would then contain the parameters at the location in the url passed down in the request. Now some might be saying, wait a second you can do that in Spray. And you would be 100% correct, Spray can do exactly that, and you can do it with this little bit of code

path("path1" / "path2" / Segment / Segment / "index") {
  (var1, var2) =>
}

And honestly in most cases this is perfect. You basically get everything you require. I however needed to use a dynamic path, so I did not know ahead of time what that path would look like or what Segments I would require or even how many. And I could not find any way that the standard directives could do what I was looking for. There may be, but I could not find it. So how did I go about it?

The Custom Solution

So custom directives are pretty basic for the most part and the link above can explain things from a more general perspective, but for me this was the solution that I came up with.

  def customPath(path:String) : Directive1[Map[String, Any] = {
    extract(_.request.uri.path.toString()) flatMap {
      pa =>
        val returnMap = new mutable.Map[String, Any]()
        val testPath = path.split("/") filter { x => x.nonEmpty }
        val urlPath = pa.split("/") filter { x => x.nonEmpty }

        val m = urlPath.corresponds(testPath) {
          // case for grabbing variable from the url
          case (x, y) if y.charAt(0) == '$' =>
            returnMap += (y.substring(1) -> y)
            true
          // standard case
          case (x, y) => x == y
        }
        m match {
          case true => provide(returnMap)
          case false => reject
        }
    }
  }

So the code above basically is stripping the request uri from the event and then matching the each element of the uri with the expected path that is passed into the customPath function, taking into account the variables that we need to pull out and place in the map. And if there are any mismatches we simply reject the request which will then bubble up the DSL and Spray will try to go to the next available route.

Bonus

There’s a bonus….heck yeah there is. We can easily add functionality into this directive by simply creating more cases under the corresponds method. So lets say we wanted to add optional path elements we could add this case

// case if you want optional path values
case (x, y) if y.contains("|") =>
  val matches = y.split("\\|") flatMap {
    _ == x match {
      case true => Some(true)
      case false => None
    }
  } groupBy(_ == true)
  // the flatMap and groupBy function will return a map with a single element pointing to all the
  // matched path elements, all false matches will be thrown out. So if there is no matches the
  // size of the map would be 0 otherwise it would be 1
  matches.size == 1

The code is fairly easy to read but it basically checks to see if a path element like “path” is in the optional list “path|path1|path2”. And look at the comments, comments are your friend, I think I should blog about commenting in your code.

Agg Tables a different look

Originally Posted on August 27th 2009

Aggregate tables are a great performance booster for any reporting system. It has the ability to really shave seconds of the length of time it takes to return results. However never rely solely on agg tables as it is not substitute for good database optimization, especially in regards to database indexes and statistics, it also does not replace any reporting caching layer that you may build into your system. It is simply another piece of the puzzle. This post is more of an different kind of look onto agg tables, not how to build them but rather what to build and why. For a detailed more technical explanation of agg tables, the Mondrian website I think has a good article for that here.

So the strong question is firstly why use aggregate tables at all, and to give you a basic answer to that question let us for a second say that you are tracking page views on your website. Each person comes in gets a track call that enters a record into your database. My report simply is a basic line graph that shows the total number of page views per day. So if we have a million page views over 1 month our calculation has to go through 1 million entries in our fact table and add up all the values per day. We would be doing a lot of extra work adding up all these values every time we requested that report. Now let us say instead we decided to aggregate that data per day. So instead of say roughly 30,000 records over a single day we aggregate that data into a single record. So we have another table that tells us that for Day 1 we have 30,000 page views. In doing this we now are doing our calculation for page views per day on a table that will never have more records then the number of days you are requesting. This is always going to be a lot faster than if you did not have any aggregate tables at all. Granted that the original type of query shouldn’t have taken too long anyway but this is to give you an idea of why agg tables are good.

Of course reporting is rarely that straight forward and usually their are multiple variables that you would be reporting on. Each variable possibly increases the size of a aggregate table and also the number of aggregate tables that you could create. For example from our previous example we were just tracking page views per day. So that is basically 2 variables making the maximum records only ever N, where N is the number of days. However what if you wanted to report on page views per url per day. Now all of a sudden your maximum records in the agg table is NxM where N is the number of days and M is the number of urls that were hit. At some point the number of records in your aggregate table could get a little too close to the actual number of records in your fact table, and hence defeating the whole point of actually having aggregate tables to begin with. It is important to remember that aggregate tables should be used more like snapshots of data instead of detailed data, which need to be optimized generally in other ways.

The other problem is the number of possible combinations of agg tables that could be created for your reporting engine. It can understandably become very troublesome and unmanageable. Firstly it is important to understand that aggregate tables are not there to solve every reporting variable (although I guess technically it could). It is best to have a good understanding of how your reports are being used, which reports are used the most, what sets of data are most requested and which are not. Once you have a good basic understanding of how exactly your reports are being used (or going to be used) you can then start deciding what type of aggregate tables you can create to help. I have found that the easiest way to manage this is to have your reporting engine build the aggregate tables for you, however this often requires a little more technical know how and would required dynamic schema’s and managing rollups of data efficiently and effectively in the background while your system is running. Maybe I will write a little bit more about how exactly I have accomplished that task in the past in some other post.

Hopefully you are a believer in aggregate tables, and hopefully you also understand that it is important to understand the requirements of your system before wasting a lot of time and effort on building tons of different types of aggregate tables only to find that it is used maybe 1% of the time. When building reporting systems in general I feel it is vitally important to build a solid framework and understand exactly what the reporting users want to get out of the reports so that you can effectively solve their problems, and when using Mondrian aggregate tables are simply one important part of that puzzle.

Fun with Scala traits

So I think in a previous blog post I mentioned something about how treating Scala traits like Java interfaces is the wrong way to go. If I didn’t it was probably something I just said out loud. Ultimately Scala traits have fundamental differences than interfaces and I think if you treat them similarly you get yourself in trouble. Anyway I am not going to get into the differences between traits and interfaces as this is not what this post is about. So what is this post about, well it is about a very specific thing that happens when you use multiple traits on your classes. Personally I think it is interesting and definitely something to be aware of. So firstly lets just produce some basic code:

trait A { def test = "testA" }
trait B { def test = "testB" }
class C extends A with B { println(test) }


And you can paste that directly into the Scala console, and once executed you will get a nice error message just like this:
| | :9: error: class C inherits conflicting members:
method test in trait A of type => String and
method test in trait B of type => String
(Note: this can be resolved by declaring an override in class C.)
class C extends A with B {
^
Basically what it is saying is that it has no idea which “test” function to use, as both the traits it is using defines the “test” function. But it is very nice and offers a solution, which is to just override the function in the class C. So you then do this:

class C extends A with B {
println(test)
override def test = { "testC" }
}


This will work, however now you don’t get any of the possible functionality from either of your traits. So how to we leverage the functionality of the traits but still mixin both traits into the class….we use SUPER!!! We can just change our code ever so slightly with:

class C extends A with B {
println(test)
override def test = { super[A].test + " - " + super[B].test }
}


And viola, you will get “testA – testB” as your response, which is the results from both the mixins. Anyway like I said this is just a little fun with Scala traits and I found it useful.

Why I dislike Spray.io

You can get detailed information about Spray.io here.

So why do I dislike Spray.io, firstly let me say why I actually like it, as I don’t like to just complain about things and there are definitely things that are genuinely great about Spray.

• The DSL is incredibly clean and easy to use, and fairly intuitive, which is no mean feat.
• Creating a route is dead simple and makes sense when you look at it.
• For most cases it just works.

These things are all no mean feat, they were able to abstract the larger concepts and still give the developer a certain amount of flexibility. For your average application it works great.

Why I dislike Spray

• The DSL abstracts away the underlying code and can seem like it is quite flexible, the problem is when you start to deviate from their patterns. When this starts happening you can quickly find yourself in a place where the code becomes very difficult to bend in the directions you want it to bend.
• It is clear when you look at the source code for Spray that the developers are very smart individuals. However the readability of their code can be difficult at times, and for someone like me who likes to get into the code it can be frustrating.

The magnet pattern that seems to be the core of Spray, is a neutral one for me. From the articles I have read, it seems like a really good idea. But I am not sold, however the fact that I haven’t thought about it too much probably means it is working quite well and in the end was a good decision to use in their development.

But every thing above I could live with, there are various things that I don’t like in various languages. A lot of the time the complaints are fairly superficial, or at the very least I can work around it. I don’t mind getting my hands dirty and figuring out what is going on. Sometimes that means diving through documentation, other times it means diving through the code. But in the end one of my most important tools is debugging. I love debugging code, step line through line through other people’s code in my mind is one of the best ways to understand it, or at least understand it quickly. In this area Spray is confusingly difficult, or at least I haven’t figured out how to truly debug it.

• First problem is that a large portion of the route is precomputed, and so when a request comes in, it doesn’t really go through the code, but rather hits an “entry point” later in the code. I quote entry point, as that is not really what it is doing, but when debugging that is kind of what it looks like. I understand the reasoning behind it, and it truly makes sense, but it can make debugging a nightmare at times.
• Second problem is that when you do step through it, it rarely makes sense. You can decipher certain things, but it is really difficult.

Please note that I am not saying it is impossible to debug the code, I am doing it currently. It is just frustrating to figure out why something is not working quite the way you would expect. I would be very happy to be corrected.

Maven Archetype Plugin

I tend to be all over the place in my blog posts, from Amazon Prime to concurrent futures to random gaming news. If I don’t watch out I will be talking my mind about NFL shortly. Anyway I have recently been dealing with the Maven Archetype Plugin. Not really a very complex kind of thing, and honestly not something that people would use all that often. Unless you are managing a team of people, or working on a larger projects you probably wouldn’t find yourself using this plugin all too often unless for experimentation.

So what is it?

The archetype plugin allows you to use maven to create projects quickly using a template that is laid down when executing. This can add things like Intellij project files, .gitignore files, base class files, resources and anything else that may be necessary to get going without having to either copy and paste files and rename, edit or whatever. I am sure SBT has something similar, I just happen to be using Maven at the moment, which is why I am writing about the Maven plugin.

What can you do?

This is were I think things get kind of cool. You can do a lot of different things. But basically if you know Apache Velocity at all it incorporates that technology into the construction of your base project/module. I am not going to go over everything, as you can just look at the look at the Apache Maven website and get a whole bunch of information about it. However here are the things I think are cool, and took more than just a brief google search to figure it out. This is a very beginner level based post so nothing should be very complicated to do, however I am going to assume you know how the plugin works so that I don’t have to go over the basics.

Using custom filenames

So this one didn’t take me too long to figure out but mainly by finding some random blog post that said how to do it. The docs from the site may have eventually got me to the same thing, but I found it first. Anyway it wasn’t obvious and if you don’t know it then guessing might be tricky, or using some experimental approach. Anyway in the end it is super simple.

1. In the archetype-metadata.xml file add the following:
   • <requiredProperties>
     <requiredProperty key=”custom-filename”><defaultValue>Custom</defaultValue></requiredProperty>
     </requiredProperties>
2. Add a template file with the name __custom-filename__.java

And that is it, note in step two the file name has two underscores and the beginning and the end of the filename. Now when you run the archetype pom when it lays down that file it will replace it with “Custom.java”. This is the default value, and now if you want to change it.

Edit: On a second glance I noticed that this is pretty clear on the website I just missed it

Replacing properties in template files

So this one is also fairly clear from the website, but to have maven use the template files as velocity templates you can simply use the following in the archetype-metadata.xml file.

<fileset filtered="true" encoding="UTF-8">
<directory>mydirectory</directory>
</fileset>

And that is it, by adding the attribute “filtered” the files in mydirectory are now referenced as velocity templates which allows you to do a lot of very powerful things.

Why did I even bother writing about these simple thing.

Because I thought it was interesting…. 😉