Erlang Example: Min and Max Element of a List

Posted on May 28, 2008 by Geoff Lane

This is part of a series on the Erlang Exercises which is a great set of programming problems that challenge you to implement solutions to some common Erlang problems. I’m going to share some of my solutions to these problems.

Simple recursive programs

1. Write a function lists1:min(L) which returns the mini- mum element of the list L.
2. Write a function lists1:max(L) which returns the maximum element of the list L.

(I’m only showing the max version since the min is basically just the change of the guard clause.)

-module(mylists).
-export([max/1]).
max([H|T]) ->
    max(H, T).
max(M, []) ->
    M;
max(M, [H|L]) when M > H ->
    max(M, L);
max(_M, [H|L]) ->
    max(H,L).

Explanation

max([H|T])
This code is composed of a public, exported function and a private function. max([H|T]) defines a function that takes a list. The slightly funny notation [H|T] is an operation that removes the head value (the zeroth element] from a list and assigns the head value to H and the remainder of the list to T. Think of the list as a stack, and you’ve just popped the stack. This method then delegates the remainder of the work to the internal, 2 value max function.

max(M, [H|L]) when M > H ->
This method is the main part of the internal, 2 value max function. The interesting piece here is when M > Hmax(_M, [H|L]) -> which acts as a fall-through because the ones that don’t match the first will call this. You can see those two functions take either M or H and pass that as the current Max value.

max(M, []) ->
The final piece of the internal max function is max(M, []) ->. This is the end state of the function. The [] clause in the function arguments pattern matches an empty list. Based on those previous 2 parts of the function definition this is fulfilling the final case where the current max value has been compared to the last element in the list.

Example

List = [1,2,4,6,5].
mylists:max(List).

So what happens is:

  1. max([1 | [2,4,6,5]])
  2. max(1, [2 | [4,6,5]])
  3. max(2, [4 | [6,5]])
  4. max(4, [6 | [5]])
  5. max(6, [5 | []]) when M > H
  6. max(6, [])
Posted in Erlang | Tagged | 1 Comment

Erlang Exercises: Ring Messages

Posted on May 28, 2008 by Geoff Lane

Erlang Exercises has a great little series of programming problems that challenge you to implement solutions to some common Erlang problems. It’s a great way to learn the language. I’m going to share some of my solutions to these problems. Maybe for some discussion, maybe for some feedback from some people more experienced with Erlang, maybe just to give some new people a flavor of the language.

Interaction between processes, Concurrency

2) Write a function which starts N processes in a ring, and sends a message M times around all the processes in the ring. After the messages have been sent the processes should terminate gracefully.

-module(ring).
-export([start/2, loop/2]).
start(N, M) ->
    Seq = lists:seq(1, N),
    Messages = lists:reverse(lists:seq(0, M-1)),
    LastP = lists:foldl(fun(S, Pid) -> 
                                             spawn(?MODULE, loop, [N-S, Pid]) 
                             end, self(), Seq),
    spawn(fun() -> [ LastP ! R || R <- Messages ] end).
loop(N, NextPid) ->
    receive
        R when R > 0 -> 
            NextPid ! R,
            io:format(": Process: ~8w, Sequence#: ~w, Message#: ~w ..~n", 
                          [self(), N, R]),
            loop(N, NextPid);
        R when R =:= 0 ->
            NextPid ! R,
            io:format("* Process: ~8w, Sequence#: ~w, Message#: terminate!~n", 
                            [self(), N])
    end.

Explanation

Seq = lists:seq(1, N) and Messages = lists:reverse(lists:seq(0, M-1)),
These create lists of integers from 1 – N and then from M-1 – 0 (because of the reverse). These lists are used for creating processes and the messages that will be passed to those processes respectively.

LastP = lists:foldl(…
This is an accumulator function. The self() value passed to the function is passed in as Pid on the first iteration, but subsequent iterations get the value computed in the method with the spawn function. The final spawn Pid is returned from the accumulator and is stored in LastP. The spawn function is setting up new processes which are running the loop function with the given values.

spawn(fun() -> [ LastP ! R || R <- Messages ] end).
This is a list comprehension in Erlang. It basically takes each value from the Messages list and sends that as a message to the LastP pid which is the beginning of the Ring.

loop(N, NextPid) ->
This is the function that is being run as the processes of each of the elements of the ring.

R when R > 0 ->
When this process receives a message where the message is an integer greater than zero then write some info to the console and forward the message to the NextPid and use tail recursion to start waiting for another message.

R when R =:= 0 ->
When this process receives a message where the message is an integer that equals zero then write some info to the console and forward the message to the NextPid, but allow this process to complete naturally.

Posted in Erlang | Tagged | 1 Comment

Erlang First Post

Posted on May 27, 2008 by Geoff Lane

Some linguists and philosophers posit the idea that you can not have a thought for which you do not have language.

“The limits of my language mean the limits of my world.”
– Ludwig Wittgenstein

I've started looking at Erlang a bit. Erlang is a functional programming language that is very unlike the imperative languages which I, and many others, are most familiar. Learning a new programming language and especially a fundamentally new programming paradigm really changes the way you think about solving problems. If the linguists are to be believed, it fundamentally allows you to have no thoughts and ideas. This is what makes it so valuable for software developers to look at new languages. I thought I would share some tidbits.

Erlang Variables Aren’t Variable

Erlang only allows you to set the value of a “variable” once. If you try to set it more than once the language actually throws an error.


Eshell V5.6.2  (abort with ^G)
1> X = "foo".
"foo"
2> X = "bar".
** exception error: no match of right hand side value "bar"

At first this sounds like a huge limitation to my imperative mind. In many imperative it probably would be. In Erlang it ends up not being much of an issue. In many ways it’s one of the things that forces you do more idiomatic, functional Erlang.

Side Effect Free

Not being able to modify variables is one of the things that helps keep Erlang programs side effect free. Side Effects make programs harder to understand and can make them more error prone. A side effect free method is one that is “idempotent”, a fancy term that means every time you call it with a given value, it will return the same result.

Thinking of side effects and how they can be reduced or removed from imperative programs can make those programs easier to understand and test.

Pattern Matching as Polymorphism

To my imperative brain that grew up mostly on Object Oriented programming languages Polymorphism and related abstraction are notions of classes and types. Erlang changes this abstraction into one of Pattern Matching. Erlang’s pattern matching is almost a declarative construct like you would find in XSL. When you find call to a function that matches this pattern, use it, otherwise try the next function until you find one that matches.

To compute a Factorial, you can use 2 function signatures. The first *fac(0)* is called whenever the function is called with the integer value of zero. If the value is not zero, then that pattern is not matched and the next version is tried. In that case *fac(N)* where N is any value other than 0 is evaluated.


fac(0) ->
    1;
fac(N) ->
   N * fac(N-1).

In a slightly more complex example, you can actually pass a keyed Tuple. The key, in Erlang speak, is an atom, very similar to a Ruby symbol. Those atoms are used as part of the pattern matching to determine which function to execute.


area({square, Side}) ->
    Side * Side;
area({circle, Radius}) ->
    3.14 * Radius * Radius.



area({circle, 10}).
area({triangle, 2, 2, 2.82}).   %% error, no match

Thinking about abstractions beyond types or classes in your Object Oriented programs could open you to some interesting new solutions

Distribution Should be Explicit, Not Necessarily Hard

Distributed computing takes more work than assuming all your code will be running on a singe machine, in the same process. The Fallacies of Distributed Computing are all about the assumptions we make when we try and hide the complexity of distribution from the caller. With Java and .NET, for example, remote calls can become so hidden that they look like just another method call within the local VM. While this is convenient, it also can lead to serious problems when users don’t take into account the overhead and the extra things that can go wrong with remote calls.

Erlang makes concurrent programming and spawning lots of processes to do work a very natural part of the language. Part of the language then is how to deal with the problems that arise when you run into issues talking to a remote process. The language has exception handling, it can be set up to receive a response, only wait for a timeout, etc.

The biggest thing that Erlang does is not try to hide the fact that you are communicating to a remote process (whether that process is in the same node, a different node, or a different machine). It gives you the programmer the tools to decide what conditions you need to handle based on how your program is built and deployed. All those scenarios are easy, but it’s still explicit that you are talking to a different process.


ping(N, PongPid) ->
    PongPid ! {ping, self()},
    receive
        pong ->            
            io:format("ping received ~B~n", [N])
    after 1000 ->
            io:format("I don't think we're gonna get a response~n")
    end,
    ping(N - 1, PongPid).
pong() ->
    receive
        finished ->
            io:format("pong finished~n", []);
        {ping, PingPid} ->
            io:format("pong received~n", []),
            PingPid ! pong,
            pong()
    end.

Think about how you can make your distribution explicit and not hidden from callers who could make bad assumptions.

I’m finding Erlang and really trying to think in a functional programming language very interesting right now, so I’ll probably post some more about it. I think it will allow me to talk more intelligently to Grant at least.

Posted in Erlang | Tagged | 2 Comments

The Best Reason for REST

Posted on May 2, 2008 by Geoff Lane

REST is a popular means of implementing Service Oriented Architectures (SOA) as well as merely providing simple remote APIs for interacting with systems. REST is a constraint based architecture built on HTTP, the foundational protocol of the Web. That foundation, its simplicity and the constraints it is built upon are its biggest strengths.

1. Simple Foundation

URLs and HTTP are the basis of building REST services.

1. a. HTTP

HTTP is a fairly simple, well understood protocol. Almost any developer who has built a web based application has come to understand the basics of HTTP. It is a stateless protocol with a limited number of request methods it uses. It is made up of 8 total verbs. From a practical point of view, those verbs are broken into Control Methods and Action Methods. The Control Methods are really only there to inspect the HTTP protocol. The Action Methods are the ones that are really used to perform the real work of interacting with a Web server.

Control Methods:

  1. HEAD
  2. TRACE
  3. OPTIONS
  4. CONNECT

Action Methods:

  1. GET
  2. POST
  3. PUT
  4. DELETE

1. b. URLs

URLs refer to resources. Those resources are manipulated using HTTP to pass data from client to server.

2. Existing Knowledge Base

Beyond your average Web Developer there are a large number of people that know HTTP and its semantics. They know how to build scalable solutions. They have knowledge about implementing caching, load-balancing, proxying, etc. In addition there is built up knowledge around network routing, security, DNS, etc. Leveraging existing knowledge in a solution is often a very good idea.

3. Constraint Based

All resources have to be represented as a URL. Those Action Methods that I referred to above constitute the total number of actions that you can take upon a resource in a RESTful architecture. So you can represent a resource and act upon it with four distinct verbs.

The Best Reason

The best arguments for REST are SOAP, OASIS and WS-*. The more I read those specs, the more I think that REST is a better solution. There seems to be a very strong correlation between people who want to build “Enterprise” solutions and people who want those solutions to be complex. It’s as if complexity is somehow a valuable attribute. It’s as if the only way to solve a complex problem is with a complex solution.

I believe that complex problems do not always require complex solutions. In fact, managing and hiding complexity is one of the best ways to deal with complex problems. Software developers do it all the time when they program. Whether that’s through a shared routine or through Object Oriented techniques like Polymorphism, software developers are constantly striving for simpler solutions to complex problems. In this way we combine small, simple solutions together to solve larger, more complex problems.

REST is that simple solution. It’s based on a simple, well known protocol. There are simple, well known techniques that can be used to solve complex security and scalability issues. The constraints of REST itself largely eliminates the need for complex descriptions of Services like WSDL. XML Schemas of the messages themselves and a list of URLs is generally enough.

Need to authenticate once and then pass a token on subsequent requests? Use a cookie.
Need to route messages based on schema version? Use HTTP redirects.
Need to change the location of an endpoint? Change your DNS entry.
Need to secure messages in transit? Use SSL.
Need to secure your endpoints? Use a firewall and/or use Client SSL Certificates.
Need to audit usage? Use the same tools you do for a web site.
Need to scale? Implement load balancing, or use caching techniques.

Conclusion

Sometimes we need to do remoting. Sometimes we would like to build a loosely coupled, distributed architecture. There are quite a few techniques we can use to do that. Sometimes we need to be technology neutral in those implementations. The field is narrowed a bit. I think when I look at REST sometimes I look at it through the lens of alternatives. One of the most common alternatives is SOAP and the WS-* stack. And when I look at REST through that lens, things look quite rosy on the REST side.

Posted in Code | Tagged , , | Leave a comment

Grails Philosophy

Posted on May 1, 2008 by Geoff Lane

There was a post on the Grails Mailing list today asking about the philosophy of Grails. This is my response:

I think I might have ripped this off from somewhere, but fundamentally there are 4 questions to answer for a basic application like this:

  1. How do you display data to a User?
  2. How do you implement business logic?
  3. How do you encapsulate complex business logic (Domain) interactions?
  4. How do you implement data access?

Most of the time when there is a layered approach one of 2 things happen. You’ve implemented a Transaction Script pattern where your business logic is implemented in the Service layer, or your Services are thin wrappers around a Data Access layer. Transaction Script is fine, but doesn’t handle complexity as well as a more Domain Driven, OO approach. The thin-wrapper thing is mostly just busy work and annoying to me.

In Grails:

  1. Controllers gather Data and hand it to GSPs for rendering
  2. Business Logic goes in Domain Objects
  3. Data Access goes in Domain Objects
  4. Complex Interaction are encapsulated in Services

Thin Controllers

Keep your controllers thin so they just mediate between views and Domains.

Active Record

2&3 happen in the same Domain objects because Grails implements the Active Record pattern. So, implement any extra queries in the Domain objects themselves.

Services for Encapsulation

Only introduce a Service when you have complex interactions (multiple objects being constructed or working together to answer a question) among multiple Domain objects that need to be encapsulated.

This is a Domain Driven framework. The complexity should be encapsulated in your Domain Objects so you can use Polymorphism to manage complexity.

Posted in Code, Groovy | Tagged | 3 Comments

Database Migrations for .NET

Posted on April 20, 2008 by Geoff Lane

One of the more difficult things to manage in software projects is often changing a database schema over time. On the projects that I work on, we don’t usually have DBAs who manage the schema so it is left up to the developers to figure out. The other thing you have to manage is applying changes to the database in such a way that you don’t disrupt the work of other developers on your team. We need the change to go in at the same time as the code so that Continuous Integration can work.

Migrations

While I don’t know if they were invented there, migrations seem to have been popularized by Ruby on Rails. Rails is a database centric framework that implies the properties of your domain from the schema of your database. For that reason it makes sense that they came up with a very good way of These are some example migrations to give you an idea of the basics of creating a schema.

001_AddAddressTable.cs:

using Migrator.Framework;
using System.Data;
[Migration(1)]
public class AddAddressTable : Migration
{
    override public void Up()
    {
         Database.AddTable("Address",
             new Column("id", DbType.Int32, ColumnProperty.PrimaryKey),
             new Column("street", DbType.String, 50),
             new Column("city", DbType.String, 50),
             new Column("state", DbType.StringFixedLength, 2),
             new Column("postal_code", DbType.String, 10)
    }
    override public void Down()
    {
        Database.RemoveTable("Address");
    }
}

02_AddAddressColumns.cs:

using Migrator.Framework;
using System.Data;
[Migration(2)]
public class AddAddressColumns : Migration
{
    public override void Up()
    {
        Database.AddColumn("Address", new Column("street2", DbType.String, 50));
        Database.AddColumn("Address", new Column("street3", DbType.String, 50));
    }
    public override void Down()
    {
        Database.RemoveColumn("Address", "street2");
        Database.RemoveColumn("Address", "street3");
    }
}

003_AddPersonTable.cs:

using Migrator.Framework;
using System.Data;
[Migration(3)]
public class AddPersonTable : Migration
{
    public override void Up()
    {
        Database.AddTable("Person", 
            new Column("id", DbType.Int32, ColumnProperty.PrimaryKey),
            new Column("first_name", DbType.String, 50),
            new Column("last_name", DbType.String, 50),
            new Column("address_id", DbType.Int32, ColumnProperty.Unsigned)
        );
        Database.AddForeignKey("FK_PERSON_ADDRESS", "Person", "address_id", "Address", "id");
    }
    public override void Down()
    {
        Database.RemoveTable("Person");
    }
}

Run Your Migrations

The best way to run your migrations will be to integrate it into your build automation tool of choice. If you are not using one, now is the time.

MigratorDotNet supports MSBuild and NAnt.

MSBuild:

<Target name="Migrate" DependsOnTargets="Build">
    <CreateProperty Value="-1"  Condition="'$(SchemaVersion)'==''">
        <Output TaskParameter="Value" PropertyName="SchemaVersion"/>
    </CreateProperty>
    <Migrate Provider="SqlServer" 
            Connectionstring="Database=MyDB;Data Source=localhost;User Id=;Password=;" 
            Migrations="bin/MyProject.dll" 
            To="$(SchemaVersion)"/>
</Target>

NAnt:

<target name="migrate" description="Migrate the database" depends="build">
  <property name="version" value="-1" overwrite="false" />
  <migrate
    provider="MySql|PostgreSQL|SqlServer"
    connectionstring="Database=MyDB;Data Source=localhost;User Id=;Password=;"
    migrations="bin/MyProject.dll"
    to="${version}" />
</target>

So You Want to Migrate?

Some more documentation and example are available MigratorDotNet. Some of the changes represented are still in an experimental branch that is in the process of being merged.


MigratorDotNet is a continuation of code started by Marc-André Cournoyer and Nick Hemsley.

Posted in .NET, Automation, Code | Tagged , , | 5 Comments

Start a New Branch on your Remote Git Repository

Posted on April 14, 2008 by Geoff Lane

Git is a distributed version control system so it allows you to create branches locally and commit against them. It also supports a more centralized repository model. When using a centralized repository you can push changes to it so that others can pull them more easily. I have a tendency to work on multiple computers. Because of this, I like to use a centralized repository to track the branches as I work on them. That way no matter what machine I’m on, I can still get at my branches.

The Workflow

My workflow is generally something like this:

  1. Create a remote branch
  2. Create a local branch that tracks it
  3. Work, Test, Commit (repeat) – this is all local
  4. Push (pushes commits to the remote repository)

Git commands can be a bit esoteric at times and I can’t always seem to remember how to create a remote git branch and then start working on new code. There also seems to be multiple ways of doing it. I’m documenting the way that seem to work for me so that I can remember it. Maybe it will help someone else too.

Creating a Remote Branch

1. Create the remote branch

git push origin origin:refs/heads/new_feature_name

2. Make sure everything is up-to-date

git fetch origin

3. Then you can see that the branch is created.

git branch -r

This should show ‘origin/new_feature_name’

4. Start tracking the new branch

git checkout --track -b new_feature_name origin/new_feature_name

This means that when you do pulls that it will get the latest from that branch as well.

5. Make sure everything is up-to-date

git pull

Cleaning up Mistakes

If you make a mistake you can always delete the remote branch

git push origin :heads/new_feature_name

(Ok Git’ers – that has to be the least intuitive command ever.)

Use the Branch from Another Location

When you get to another computer or clone the git repository to a new computer, then you just need to start tracking the new branch again.

git branch -r

to show all the remote branches

git checkout --track -b new_branch origin/new_feature_name

to start tracking the new branch

Automate it A Bit

That’s a pretty easy thing to automate with a small shell script luckily

#!/bin/sh
# git-create-branch <branch_name>
 
if [ $# -ne 1 ]; then
         echo 1>&2 Usage: $0 branch_name
         exit 127
fi
 
set branch_name = $1
git push origin origin:refs/heads/${branch_name}
git fetch origin
git checkout --track -b ${branch_name} origin/${branch_name}
git pull

For further help, you might want to check out:

Posted in Automation, Code | Tagged , , | 63 Comments

CruiseControl With a Specific Version of Grails

Posted on March 27, 2008 by Geoff Lane

Continuous Integration is a good practice in software development. It helps catch problems early to prevent them from becoming bigger problems later. It helps to reinforce other practices like frequent checkins and unit testing as well. I’m using CruiseControl (CC) for Continuous Integration at the moment.

One of the things about Grails is that it is really run through a series of scripts and classes that set up the environment. The Ant scripts really just delegate the work to those grails scripts. To run properly, the GRAILS_HOME environment needs to be set so that it can find the proper classes, etc. This is not a problem if you are running a single Grails application in Continuous Integration. The issue arises when you want to run multiple against different version of Grails. A project I’m working on uncovered a bug in the 1.0.2 release of Grails. The code worked fine on 1.0.1 so I wanted to run against that specific version of Grails.

It ends up this is not to hard with a few small changes to your Ant build.xml file.

First you can declares some properties that have the paths to the Grails directory and the grails executable (the .bat version if your CC server is on Windows).

<property name="cc-grails.home" value="C:\grails-1.0.1" />
<property name="cc-grails" value="${cc-grails.home}\bin\grails.bat" />

Next you can declare a custom target to execute on the CC server. You reference the ‘cc-grails’ property declared. The key is that you must override the GRAILS_HOME when you execute the grails script.

<target name="cc-test" description="--> Run a Grails applications unit tests">
    <exec executable="${cc-grails}" failonerror="true">
        <env key="GRAILS_HOME" value="${cc-grails.home}"/>
	<arg value="test-app"/>
    </exec>                               
</target>

Now the Continuous Integration of your Grails app runs against a specific version of Grails.

The Full build.xml

<project name="project" default="test">
 
    <condition property="grails" value="grails.bat">
        <os family="windows"/>
    </condition>
    <property name="grails" value="grails" />
    <property name="cc-grails.home" value="C:\grails-1.0.1" />
    <property name="cc-grails" value="${cc-grails.home}\bin\grails.bat" />
 
	<!-- ================================= 
          target: clean              
         ================================= -->
    <target name="clean" description="--> Cleans a Grails application">
		<exec executable="${grails}" failonerror="true">
			<arg value="clean"/>
		</exec>                               
    </target>
 
	<!-- ================================= 
          target: war              
         ================================= -->
    <target name="war" description="--> Creates a WAR of a Grails application">
		<exec executable="${grails}" failonerror="true">
			<arg value="war"/>
		</exec>                               
    </target>
 
	<!-- ================================= 
          target: test              
         ================================= -->
    <target name="test" description="--> Run a Grails applications unit tests">
		<exec executable="${grails}" failonerror="true">
			<arg value="test-app"/>
		</exec>                               
    </target>
 
    <!-- ================================= 
      target: cc-test              
     ================================= -->
    <target name="cc-test" description="--> Run a Grails applications unit tests in Continuous Integration mode">
		<exec executable="${cc-grails}" failonerror="true">
            <env key="GRAILS_HOME" value="${cc-grails.home}"/>
			<arg value="test-app"/>
		</exec>                               
    </target>
 
	<!-- ================================= 
          target: deploy              
         ================================= -->
    <target name="deploy" depends="war" description="--> The deploy target (initially empty)">
        <!-- TODO -->
    </target>
</project>
Posted in Automation, Code, Groovy, Web | Tagged , , | Leave a comment

Encryption, Codecs and Unit Tests in Grails

Posted on February 3, 2008 by Geoff Lane

Certain data stored as plain text in a database is just asking for trouble these days. We hear too often about misplaced and stolen computers that contain databases full of Social Security numbers and other information that can lead to identity theft. We can help avoid these situations by encrypting those fields in a database so that if someone happens to get the data that they will have a difficult time getting the sensitive data.

Codecs

Grails provides a very good mechanism for this encryption in its Codec support. Codecs allow you to create encoders and decoders that become very easy to use in your application. Grails comes with a few useful ones built in to do things like Base64, URL, HTML, and Javascript Encoding.

Anywhere you have a string you can call the encodeAsCodecName or decodeCodecName to perform the encoding or decoding:

assert "apples &amp; oranges " == "apples & oranges".encodeAsHTML()
assert "apples & oranges " == "apples &amp; oranges".decodeHTML()

This is a nice, generally useful utility that can be used for any kind of string conversion really. There’s nothing from stopping you from creating your encodeAsInteger or decodeShortDate if that’s something you need a lot of in your application.

The basic format of a Codec is simple. You can create your new Codec in the grails-app/utils directory and it will be found automatically by Grails based on the naming convention.

class MyCodec {
    static encode = { str ->
        // Implement encoding here
    }
    static decode = { str ->
        // Implement decoding here
    }
}

Encryption Codec

In my case I wanted to create something to do encryption. Luckily this is not so hard with the javax.crypto classes. The crypto API is not the most straight forward to use in the world, but with a little bit of reading you can figure out how to encrypt and decrypt data without a lot of hassle. Basically what you see is a fairly simple encryption routine wrapped in the Grails Codec standard.

As you saw from previous example, the Codec standard is really simple, so all of the complexity here is really just the encryption code.

import javax.crypto.spec.SecretKeySpec
import javax.crypto.Cipher
import javax.crypto.spec.IvParameterSpec
import sun.misc.BASE64Encoder
import sun.misc.BASE64Decoder
import org.codehaus.groovy.grails.commons.ConfigurationHolder
/**
* Used for encrypting things to store in the database
*/
class SecureCodec {
 
    static BASE64Decoder decoder = new BASE64Decoder()
    static BASE64Encoder encoder = new BASE64Encoder()
 
    static encode = { str ->
        Cipher cipher = setupCipher(Cipher.ENCRYPT_MODE, getPassword())
        return encoder.encode(cipher.doFinal(str.getBytes()));
    }
 
    static decode = { str ->
        Cipher cipher = setupCipher(Cipher.DECRYPT_MODE, getPassword())
        return new String(cipher.doFinal(decoder.decodeBuffer(str)));
    }
 
    static getPassword() {
        return ConfigurationHolder.config.encryption.password
    }
 
    private static setupCipher(mode, password) {
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
 
        // setup key
        byte[] keyBytes = new byte[16];
        byte[] b = password.getBytes("UTF-8");
        int len = b.length;
        if (len > keyBytes.length)
              len = keyBytes.length;
        System.arraycopy(b, 0, keyBytes, 0, len);
        SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");
 
        IvParameterSpec ivSpec = new IvParameterSpec(keyBytes);
        cipher.init(mode, keySpec, ivSpec);
        return cipher
    }
}

Another handy thing to notice is the ConfigurationHolder.config. This is the way to access application properties defined in Config.groovy. In a Domain class or a Controller you can get those values using grailsApplication.config but the grailsApplication variable is not available in Codecs or other classes. I use the Config.groovy to define an application specific secret to use for the encryption.

Testing Your Codec

Now to confirm that the code works we can write a Unit Tests. Encryption and Codecs are the perfect example of checking an Inverse Relationships to confirm the functionality of the Codec. Basically just encode it and decode it and compare the original value to the decoded value. If they match, it worked!

As a Unit Test

Outside the context of your running Grails application your Codec is just another Groovy class. Testing it in a Unit Test is easy though. You can just instantiate an instance of it and call the closures like they are methods.

class SecureCodecTests extends GroovyTestCase {
 
    void test_roundtrip_decodes_to_the_same_thing() {
        SecureCodec codec = new SecureCodec()
        def original = "secret"
        def encoded = codec.encode(original)
        def decoded = codec.decode(encoded)
 
        assert original != encoded
        assert encoded != decoded
        assert original == decoded
    }
}

As an Integration Test

If you want to be able to test it as it will be used in your Grails application though, you will need to run it as an integration test. The integration tests are loaded, instrumented and run just like they would be by the real Grails application. To do that, you just have to create the test under the tests/integration directory of your Grails application.

class SecureCodecTests extends GroovyTestCase {
 
    void test_roundtrip_decodes_to_the_same_thing() {
        def original = "secret"
        def encoded = original.encodeAsSecure()
        def decoded = encoded.decodeSecure()
 
        assert original != encoded
        assert encoded != decoded
        assert original == decoded
    }
}
Posted in Groovy | Tagged , , | 3 Comments

ALT.NET in Milwaukee

Posted on February 1, 2008 by Geoff Lane

I am a generalist. I like Ruby and Groovy, Rails and Grails, Objective C and Python sometimes. I use bash scripts and I use Java and .NET too. I work on a MacBook Pro running OS X and a Thinkpad running Windows XP. I run my server on Ubuntu Linux. I use to run Linux at home a lot more, but have basically just switched to the Mac, the mullet of OSes – business on top and party in the back! (No I don’t have a mullet, yes I love the Mac OS X.)

But this post was about .NET right? Well the whole idea behind ALT.NET is that we have learned from our experiences. Whether I’m doing a web app in Grails, a handheld application in .NET CF or a desktop application using Objective C I want to bring all of the experience that I have in each of them to the game. When I do ASP.NET I want to leverage the things I’ve seen using Hibernate and Spring in Java and MVC in Rails, Grails and Objective C. I like to think that I fit the solution to the problem and not the other way around. Having a broad based experience helps with that.

ALT.NET is about bringing all of those ideas along with the ideas of Agile development, testing, continuous integration, refactoring and generally embracing change to the .NET world. It’s about evaluating tools on their merits regardless of the vendor. Microsoft is just another “3rd Party vendor” and gets no special treatment.

Dan Miser is a former bigwig in the Delphi community who now sits next to me at work. He’s a .NET guy who owns a Mac and got excited about Rails. He’s taken it upon himself to organize an ALT.NET in Milwaukee.

Do you believe that choosing the right tools doesn’t depend on who makes them? Do you believe that Open Source works? Do you know more than one language and more than one platform?
Check out his site for more information.

Posted in .NET | Leave a comment