Category Archives: Groovy

2016-02-22 Update

I bought Living Clojure by Carin Meier, and I am working through the second half. It seems like a nice language and a nice book. I hope to use it professionally in the future.

I also like Groovy. As Dick Wall would say, I am all about the Groovy, man. I also made some progress on the Groovy Mail Server. I made some progress on authentication using SASL. I using SASL classes in the JDK, but I had to implement some Callback handler code myself. I had some help from Stack Overflow. In general I like Java the language, but sometimes I feel like the API designers like to make things more complex than necessary.Interfaces, extensions, listeners, factories, handlers, the knee bone instantiated the thigh bone, etc, etc, etc.

One thing I found out today is that when calling static methods on a class in the Groovy shell, you need to include the full package name for the class. I prefer the shell over the console, but I may have to switch. I wish the shell could run any Groovy code as-is. After finding out about setting interpeterMode to true in the shell, I thought the shell would run everything fine. Oh well.

I also made some small changes. I was not catching a possible exception, and the code was not closing connections. When I logged into the server it had almost maxed out.

You’re welcome.

Testing Groovy Actors

One thing I did not quite get when I was looking at multithreading technologies was how to unit test them.

I have not looked at Akka for a while, but a few years ago it seemed like the consensus was to use a logger like Log4J, and then parse the logging messages. That is kind of unwieldy and feels wrong. (Akka seems to have more ways to test now.)

I emailed the GPars list about putting private fields in an actor, changing them in the onMessage method, and then checking them afterwards; something like this:

You could do that. There is nothing wrong with having private fields in an actor. You might want to keep some data between requests (like an encryption key). But making a field just for testing seems wrong.

Then I had an idea: Have your actor call another class that does the actual work, and unit test the worker class:

I suppose that will not help with functional testing. It might violate some SOLID principle, or DRY, or GRASP or the Law of Demeter or Principle of Least Astonishment or Poe’s Law,
but it seems like a pretty good idea to me.

You’re welcome.

2015-11-08 Update

I have been traveling for work, but now I am back.

I did some work on the Groovy Mail Server. I am ready to start working on sending mail. I will have to look into authentication, which will complicate things a lot.

I am thinking about going forward with a Grails 3 tutorial.

I am thinking about looking more into Common Lisp/Racket/Scheme/Clojure. I know a lot of the pragmatic programming crowd says you should learn a language every year, I am starting to question that. It seems like languages in the C/C++ family are moving more towards Lisp and Smalltalk. Why not just learn those and be done with it?

You’re welcome.

Update On Groovy Email Server 002

Here is another update on the Groovy Email Server.

After I made the last update, it stopped working. For some reason, I could retrieve messages in Alpine, yet not look at the bodies of the messages. I could view the headers. I was able to figure it out, and now I can retrieve the messages in Alpine again.

I send myself a message with a text file as an attachment, and I was able to save it.

I also tagged the git repo. I did not tag it the last time I posted, so I wasted some time downloading old versions from github to see when things were okay.

For some reason, I cannot retrieve the messages with Thunderbird. I will try another client later.

You’re welcome.

Update On Groovy Email Server

I know I said I was going to shelve the Groovy Email Server. Instead, I kept working on it. I will probably keep at it until I get it to a semi-finished state. Right now it is in a semi-semi-finished state.

Right now I have implemented most of RFC 1939 (POP3) and RFC 5231 (SMTP). (I do not plan on implementing RFC 3501 (IMAP).) I can send email from another account to my GES, and I can retrieve them locally using Alpine. So far I would call it pretty successful.

I have not tried to retrieve messages with attachments. I have not looked at RFC 5232 (Internet Message Format), which may cause problems down the line. I have not tried to send messages while logged into Alpine.

I have written this using PostGres. I have the tests actually writing to the database. I know a lot of test purists will object, but I saw an article linked from Hacker News: Don’t test with SQLite when you use Postgres in Production. One of the comments was a quote (supposedly from NASA): Test what you fly, fly what you test. Maybe it’s not the absolutely best way to test and develop, but as Voltaire wrote: Do not let the perfect be the enemy of the good.

I have to update the README on github. I think I will try to get it to a point where I can also send from Alpine. I might go further than that, and try to get it to the point where I can replace my Apache James server. We shall see.

You’re welcome.

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-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.

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:

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:

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.

Notes From Ken Kousen at Austin GGUG

Ken Kousen spoke about Grails 3 testing a few weeks ago at the Austin Groovy and Grails User Group.

Here are some quick notes I took down:

You’re welcome.