Shelving Groovy Mail Server

I am shelving the Groovy Mail Server for the time being.

I did not think it would be easy, but it is turning into a lot more work than I thought. I am also having issues with some stuff in Postgres. I want to learn Clojure, and lately I have been getting impatient to do something there. There seems to be more activity in the Clojure community, and I think the Clojure job market will hit a critical mass faster than Groovy will. I think I might start with the tutorial on the Luminus site.Besides, I am more likely to get a job making web apps than writing mail servers.

Granted, I said a few times I was done with Groovy Validators, and then later I came back and improved it.

You’re welcome.

2015-08-10 Tweets

2015-07-27 Tweets

2015-07-27 Update

I took some time off work to see family on the East Coast. Now I am back in front of my computer again.

I am still working on my Groovy email server. Just getting one RFC done is taking a long time.

I have talked about working on a Grails tutorial. It looks like there is some progress on porting the Shiro plugin to Grails 3. I will try it out and see what happens. If I make a tutorial, I think I would need to run it on a static site. I will also look into static site generators, like Grain or JBake.

After I get done (or closer to done) with the mail server (or at least RFC 5321), I will spend some time with Clojure. I found an article on programming on HuffPo (via hacker News) with a link to a page by the author that advocated functional programming (without using the word “functional”). It is looking like that might be the way to go.

You’re welcome.

Running A Groovy Closure In a Groovy Closure

One thing I did not see in the Groovy documentation is how to call a closure on a closure.

While working on my mail server, I wanted to try out some regular expressions on some strings. So I put them in a list, and I ran the list through a closure.

someList.each {
    println "looking at ${it}"
    q = it =~ regex
    print it ==~ regex
    print "; " + ( it?: q[0][2] )
    println "; done with ${it}"
}

Then I wanted to do that with several lists. I did not want to type or copy and paste the closure over and over again.  So I assigned the closure to a name:

regexClosure = {
    println "looking at ${it}"
    q = it =~ regex
    print it ==~ regex
    print "; " + ( it?: q[0][2] )
    println "; done with ${it}"
}

Then I had some problems getting it to work as expected.

Calling someList.each{ regexClosure } did not work.

I tried several guesses and variations until I found a way to call a closure in a closure.

What finally worked was:

someList.each{regexClosure(it)}

You’re welcome.

2015-07-05 Update

Lately I have been working on a mail server in Groovy.

I have thought about making a mail server for years. The evolution of the idea is this: I decided to run my own mail server, so I went with Apache James. The version I am running is a bit old. The newer version that will be coming out soon is a bigger piece of software. It also handles IMAP as well as POP and SMTP. I looked at it a while back. I am running on a small VPS. I don’t know if I could run something too big.

So I decided to try doing it myself. Let’s see how simple SMTP is.

Turns out it is a bit hard in some places. Right now I am getting bogged down in regular expressions to validate email addresses. There is a class in Apache Commons that handles that. But the problem with using any of the sub-projects in Apache Commons is that you wind up having to download a whole bunch. Like commons-logging, commons-beanutil, commons-io, commons-kitchensink and commons-baggage.

I am writing it in Groovy. I was hoping to try using GPars, but I might not need to. Some of the GDK extension classes, like java.net.Socket and java.net.ServerSocket take closures for arguments, and they run each closure in a separate thread.

I am doing a lot of meta-programming. Mostly I am adding methods to the String class. I am making methods like “isGreaterThan255Char” which just checks if a String is more than 255 chars, and methods that check if a string contains or starts with a particular substring. It is more lines of code, but I think it makes things easier to read. After Groovy Validators, I decided to try some easier meta-programming.

I am also going to use Postgres for the database. I might even use it for tests. I know some testing purists say your tests should never touch the database. Good for them. Never argue with a purist. They will always find something to complain about. What’s wrong with touching the database? I am not using some external data source. I figured I can learn more about mocking and stubbing later. Applications change databases, not mocks and stubs, so why if you never test against a database, what are you really testing?

There are a lot of people in the Chicago Ruby community who are big on automated tests, never touching the database, and making sure their tests run fast. Good for them. But now, looking back, they all seem pretty hilarious. There is a lot of code in this world that has no automated tests at all. If telling people it’s okay to touch the database brings more people into the world of automated testing, then that is a good thing.

You’re welcome.