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.

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:

Spock: You can add notes to when and then
when: "Some conditions"
then: "You should see some results"
In console:
make a list of lists, call combinations()
also: Look up "unroll" for Spock - annotation

CastleController, he uses a service, and makes it "def" instead of a type
then in his test he can do Expando to mock instead of dealing with mocking stuff

Plug-in: build-test-data

You’re welcome.

 

Update 2015-06-15

For the past couple of weeks, I have been working on some Groovy.

I have been working with some metaprogramming to make lists more functional in Groovy. I spent some time trying to intercept the constructors and replace the output with a call to List.asImmutable(). I wasn’t able to quite get the default call, but now that I think about it, that might be a good thing. I think it is good to have choices. I had to use a closure to get what I want.

I took a look at Functional Groovy. He does some stuff with lists, but he does not make them immutable. I think that is part of the functional way: immutable data. I have not committed anything yet, but I might soon.

I have also spent more time on my Groovy email server. It took me a while to get the hang of things. I wanted to use some of the Groovy goodness, but bytes and IO streams are pretty low-level, so I think I may have had to make some compromises. I made two versions, one that uses some of the Groovy goodness, and one that reads bytes. At first I was able to test the version that uses bytes, but not the other one. But the version with bytes is not working as well for some reason. I got another VPS host, and I email myself and print out logging statements to the console. After the “DATA” command, my regular server sends a “RSET” command.

But I figured out how to do some testing in the version that uses some of the Groovy goodness for the java.io classes.

I also got logging to work with Slf4J and Logback. I was using an older version of Logback that was causing problems, but upgrading fixed them.

This might be like the Groovy Validators: I might get frustrated and stop, and then after a while come back to it. We shall see.

You’re welcome.

2015-06-08 Tweets