It has come to my attention that I have not updated this blog in quite a while. This is an error that I wish to remedy immediately. Since my last post a lot of fun and exciting things have happened and I have learned a ton of new stuff that I will hopefully write about in the near future.

I would like to announce that Wezzle has been completed and is for sale on our website! It only took two years since Couchware’s inception, but it’s finally here and it looks great. I couldn’t be happier with the way Wezzle turned out. I think it looks outstanding and has some enjoyable and addicting game play.

I would like to give a huge thanks to those who assisted in the creation of the Wezzle. This includes Renee and Sam and all of our testers. If you like the art and music in the game be sure to check out Renee’s and Sam’s websites.

Despite having put the game up for sale, Wezzle is not yet 100% complete. We are still hard at work finishing up a Wezzle demo that will be playable within the browser. Once the demo has been completed, we will be marketing/launching the game to a larger audience (hopefully!). There will likely be a launch party at an as of yet undisclosed location in Toronto. For those interested in coming, fire me an email or check back at this blog occasionally. Cam has also been hard at work at a REALLY cool Wezzle port, the nature of which I can’t disclose at the moment. It will be hopefully laying the ground-work for some of our future projects.

In other news, I have been put in charge of a major project using Java EE 6 which I’m pretty excited about. Some of the technologies I have been using lately include: Maven2, Logback, JPA/Hibernate, JSF, EJB 3.1, and more. Hopefully in the coming weeks I will have something interesting to say about some of these.

Finally, I have bought kevingrad.com, org and net (all currently have no content) and I will eventually be moving this blog to one of those (probably .org).

I placed the order on April 1, paying extra for the medium-tier shipping package so that I could get the book within 3-5 days of shipping. Since the book was in stock I was hoping to have the book by the end of the week. The only reason I ordered from the U.S. site (which obviously cost more for conversion, shipping, customs etc.) was so i could get the book without waiting 2-3 weeks. This prior weekend was a long weekend and it would have been nice to have had the book to read while I had some time at home. However, by April 8, the book still had not shipped. This was inconceivable to me as it was STILL listed as In Stock on their website, why would it not have shipped?

I sent a strongly worded letter to Amazon customer service, and to their credit, they upgraded me to premium shipping and sent it out the next day. The said there was a problem with the order that he fixed and sent it out at the next available opportunity. I highly doubt there was actually a problem other than the fact that I complained. Long story short, I finally have the book. Even though Amazon customer service was pretty good about the matter, I should not have had to contact them in the first place and I did not get to read the book over the long weekend as I had hoped.

Anyway, back to Scala. Scala seems to be a pretty cool language. From what I gather so far (and I will update you as I know more about it) it combines Object Oriented Programming (OOP) principles with Functional Programming (FP). It allows for both Imperative (think Java, C++) and Functional (Erlang, Haskell) programming styles. It is not the only language to do this, many languages provide functional programming features within the language, such as closures, functions as first class objects etc. The most notable languages to do this would be Python and Ruby.

However, Scala is not a dynamic language. It is statically typed, with type inference, which looks like it could be very nice. Additionally, Scala’s OO model is not implemented in a half-assed fashion like Java (primitives, statics, …) but rather, everything is an object (in the vein of Smalltalk, Ruby, etc.). Finally, it is lightweight, choosing to bundle most features in external libraries (comes with a standard library) rather than in the language itself, (such as BigIntegers, Actors).

The really interesting thing about Scala, is that it uses a lot of the Java types but extends them using something called Traits. For example, it uses primitive Java ints, but in order to make them objects, it defines a trait that will map Scala commands to a custom implementation (kinda). An example of this is if you want to call a function on an int, Scala will first look to the Java implementation, if the function doesn’t exist (which it wont because an int is a primitive) it will look to see if there are any traits defined, (which there are because its part of the Scala language) and then look for the function there. Scala uses these traits as means of wrapping the Java libraries in a nice way for use with the Scala language. It makes external libraries seem as if they are part of the Scala language, which is pretty nice. The beauty of this is, you can define your own traits and extend classes however you see fit. As well, you can use traits as lightweight interfaces, defining partial methods and enforcing multiple traits in a pseudo multiple inheritance scheme. Pretty powerful (if you understand what I just said anyway). I’m not 100% clear on traits so don’t get mad if some of the info I just mentioned is wrong.

Scala is also a fully functional language, borrowing some great ideas from other functional languages such as Haskell and Erlang. Of note, Scala uses an implementation of Erlang’s Actor’s shared memory model to accomplish parallel programming. Erlang’s model has been hugely successful and I am interested to see exactly how I can utilize this feature.

Scala’s name comes from “Scalable Language.” I’m not sure exactly what makes Scala so scalable, some of the things I’ve seen from my brief introduction is its use of traits, its integration with the Java standard library, its ability to run on the JVM and its Erlang-eque concurrency model.

There was a great question Cam pointed out on Stack Overflow which talks a bit about what makes the Lift web framework (written in Scala) so scalable. It is really interesting, and their take on threading is a good one in my opinion. Something I hope to maybe take advantage of with my own stuff.

I have to say that I am pretty excited to learn Scala. It seems like it could be a great language that is still undergoing heavy development and is very extendable. Ultimately I would like to combine Scala with some of my Java programming, something that I see as Scala’s (and all JVM languages) best feature. I believe this is still something that is not entirely EASY to accomplish. Something that I would like to see, and I am sure is on the list of things to do, is the ability to mix JVM languages transparently, without the need to call the specific compilers for the specific classes. Maybe I will work on that as a side project.

Scala is being touted by many as the next “Big” language. I don’t know if that’s necessarily the case, but it sure does seem like a nice language. Maybe it will quench my thirst for new languages temporarily? Who knows. I also purchased Programming Language Pragmatics with a mild desire to create my own language at some point. Perhaps I will be able to leverage some ideas from Scala when doing so.

This will be my first serious venture into the FP world (I have a little experience with Scheme, however, that was a long time ago, in a galaxy far far away…). I am already familiar with a bunch of functional techniques, such as closures/lambdas, but I have never really programmed in a functional way for something serious. Hopefully Scala turns out to be as nice as it appears to be, as I am excited to try the Lift framework and to start mixing functional programming with my current code.

The job requirements included extendability, maintenance, minimal overhead, and it had to work with the current code, i.e. I couldn’t go and redesign the entire system. There were already hundreds of forms in the system with thousands of fields requiring validation. My first task was to explore the different possibilities. I came up with a few various schemes for both client side and server side validations. I opted to go with a client side solution for various reasons, including the fact that I could update the page with any error messages without ever needing to contact the server.

The major problem that I had to address was how to insert my validation functions within the already created web forms in an easy, extensible way. At the time I had been playing around with a JavaScript library known as jQuery. I had very little experience with it, but it seemed very interesting. Cam had also recently begun using jQuery and was big on the library.

One of jQueries big features is easy manipulation of the DOM tree. jQuery ingeniously makes use of CSS Selectors to wrap a group of elements in a jQuery wrapper. If you have never used CSS selectors, I HIGHLY recommend taking a look at them.

Using jQuery, the following simple code:

$('.foo')

returns an array of all DOM elements with the attribute class=”foo”. You can then iterate over this wrapped set in a number of ways. This is immensely powerful. Additionally, jQuery will recognize custom attributes.

The code:

$('input[required=true]')

will return all input elements with a custom attribute required=”true”. What this means is, if you have in your HTML a text field like this:

<input type=”text” required=”true”>

The jQuery code above will find that element and return it in a wrapped jQuery array. I used this as the basis for my validation system.

What I did, was define a set of custom attributes, and a set of JavaScript functions based on requirements given to me by the hiring company. Then I created a validate() function which sequentially called all of my JavaScript functions. This validate function was meant to be called in an onSubmit() but could be called anytime.

If you ever wanted a field to be validated, you simply added my custom attributes to its HTML markup. So for example, if you wanted a field to be marked required, you simply went to that field and added required=”true”. If you wanted a field to be checked for a valid integer, you went to the field and added type=”integer”.

The beauty of this approach is that it allows a field to be marked with an arbitrary number of validations. And removing validation is as easy as removing the custom attribute. Additionally, if you add a new function to the set of JavaScipt functions, all you need to do to add it to a field is add the new custom attribute.

The way this works is, when the person submits the form, the validate function is called. The validate function uses jQuery to parse the DOM tree and iterate over the results. So within the validate function, the first function looked something like this:

$('input[required=yes]').each(function(n)
{    
 
  // validate the required strings.
  var str = validateRequired(this.value, $(this).attr('field_name'));
 
  // If we had an error, concatenate it into the error string and add the errorCase
  errorStr += errorCheck(str, $(this));
 });

What this did was, it searched the page for any input elements with the custom attribute required=”yes”. It then iterated over that set and passed the value into the JavaScript function validateRequired() which checked whether the field was non-empty. It then returned an error string from a function that properly formatted error messages.

Each method concatenated an error string when there were any errors, and at the end of the validate() function if there were any error messages it printed them to the screen in a custom div. Otherwise, it allowed the submit to go through.

This was done for every type of validation, even if there was no elements with that custom tag within the current page. This makes it easy to simply add new validations on the fly. Also, all the JavaScript functions are in a central place and are easy to modify/update and have it filter through the system automatically.

This solution worked perfectly as it was easy to implement and fit the requirements perfectly. The client was pleased and everything worked out.

This may not be the way I would design the validation system today, but it was an excellent choice at the time.