If you want to send email from your Lift app using SendGrid you need to do two things: set an authenticator and enable the javax.mail authentication flag. That second part isn't obvious.

Step by step...

Assuming your Lift props file contains the following:

# Sendgrid.com configuration: 
mail.smtp.host=smtp.sendgrid.net 
mail.user=you@example.com 
mail.password=letme1n 
 

In Boot you need to set the authenticator:

import javax.mail._ 
def optionalAuth: Box[Authenticator] = for {
    user <- Props.get("mail.user")
    pass <- Props.get("mail.password")
  } yield new Authenticator {
    override def getPasswordAuthentication = new PasswordAuthentication(user,pass)
}
Mailer.authenticator = optionalAuth

And the part that I forgot:

optionalAuth foreach { a => System.setProperty("mail.smtp.auth", "true") } 

Play is a MVC, convention-based, stateless web framework for Java with growing support for Scala too.

It's not for me as I can't face going back to MVC and the kinds of presentation languages they use. Having said that, if you like MVC, and you're not already using Grails or Rails or a similar framework, I strongly urge you to look at Play as there's some nice technology in there. 

Everything I know about Play comes from Rustem Suniev's talk for the London Scala User Group at Skilsmatter on Wednesday. The slides and video are already on-line and they contain a really nice live-coding demo of Play which gave me a good sense of what the framework is about.  Nice work—and pizza courtesy of autoquake.com (who are hiring).

One comment I will make is that Play pushes it's stateless-ness prominently. For many of us I suspect our default position is that stateful=bad and stateless=good.  That sounds sane, but you probably do need some state in your application, and you have to deal with it somehow, or push the issue somewhere, which leaves me feeling that state v. stateless thing is all a bit more complicated that we often think it is.  It certainly does not automatically mean better scaling or performance, but there are definite positives to it.  I'm glad to see the Play community discussing state and exploring some nice ideas.  Just don't assume a label of "stateless" solves all your scaling problems—if you're lucky enough to have any :-)

One part of Taykt.com which I've not spoken much about is the web hooks facility built in.  It means you can write applications which are prodded when a text message arrives, giving you a chance to decide how you want to reply.  I can't think of an easier way get up and running with a SMS-based application: if you can write a web app, you can handle SMS, and you can do it without having to get out a credit card.

To fix the problem of keeping this so quiet, we've documented what we have at Assembla and started to pull together examples. There's a simple echo example (responding to a text message with what was texted in), but I have in my mind plans for other examples.  My favourite would be to see The Internet Oracle implemented, although I also have a soft spot for Eliza and information services... the Taykt.com blog is collecting together ideas for how Taykt.com can be used.

We've also set up a RESTful API for managing accounts, trying to follow as much of the best practices as possible. But I think the web hooks part of the product is the most useful part to just be able to create something and have it running live.

I do like Databinder Dispatch. It wrappers HttpClient and adds in support for oAuth, Twitter and other web services, letting you write code like this:

import dispatch._
import Http._
val http = new Http
http("http://databinder.net/dispatch/Stdout_Walkthrough" >>> System.out)

I admit it might seem a little odd the first time you dig in to use it.  What I found useful was looking at the source which has been formatted with Scala X-Rays—itself quite a eye opener, giving something as useful as an IDE in a browser without actually having an IDE in a browser.

What's happening with the http(...) call is a HttpClient is being invoked via a Handler.  That is, the parameter to the http() call needs to be a Handler, and a Handler is something that takes a request and... handles it, by making use of what comes back from the request, for example.

How do you get a Handler?  You can write your own, but another way is to take a Request and call a method on the Request to give you a Handler.  In the above example the String "http://databinder..." is converted to a Request via an implicit in scope as a result of the import.  The >>> method on the Request gives you a Handler.  In this case, it's a Handler that writes the response to the given stream.

As you might imagine there are lots of methods to give you all sorts of different Handlers, and these can be chained in various ways to set headers, perform POSTs, set encodings.... there's quite a list in Http.scala.

You need to do asynchronous HTTP? It's there. Dealing in Json?  Yup, that's there too.  An impressive library.

Aside:

If you want to just grab some content, work with the content, and return something you could write:

def withContentFrom[T](url: String)(f: String => T): T = new Http().apply(new Request(url) >- f) 

val result = withContentFrom("http://whatever.example.com") { html =>
  // do you thing with html
}

Handy for scripting.

I know next to nothing about the Wicket web framework, but I was intrigued by the jWeekend London Wicket User's Group meet up last night. The topic was "Scala and Wicket".

As far as Scala and web frameworks go, the main name is Lift. The problem with Lift... No, let me re-phrase that because it's not a problem with Lift. The great thing about Lift is that it's made for Scala, so it's going a great fit to the language. Learning Lift and Scala at the same time should mean you're bouncing the framework learning and the language learning off each other, which is going to teach you a lot.

Then again... if you're learning the language and trying to get your head around a framework, it seems to make the goal of "doing something useful with Scala" just that little bit further away. So how about this: Scala and Java work well together, so why not use a web framework you already know, but just use Scala instead of Java? Start gently, then, when ready, take a look a Lift.

I don't know which approach is best, but it seems there might be something in the gently-gently approach. There is one other compelling reason for looking at a existing (legacy? :-) web framework: you can dig into the publications on the topic, such as Wicket in Action, or Programming Struts, or Stripes etc. (Obviously this situation will change for Lift: I've already expressed my disappointment that none of the big publishers are looking at the practical aspects of Scala, but there is the start of a creative commons text).

Sure, you're not necessarily going to learn Scala idioms from a non-Scala framework, and you're going to run into head-scratching issues, but it seems somehow more manageable to at least try it. More so if you're inserting Scala into an existing project.

Of course, the whole argument falls apart for me in the case of this event, as I don't know Wicket :-) But I've tried Scala in a trivial way with a large existing Struts 1 application, and it was surprisingly painless.

But back to the event and the talks:

• Daan van Etten gave a lovely "Basic Introduction to Scala With Wicket". The slides, handouts and code are available. One download and two commands to get the example app up and running was pleasing.
• Dean Phersson-Chapman spoke about his "Experiences Converting an Existing Wicket Application To Scala". It seems there are some serialization issues between Wicket and Scala 2.7.3 which are being fixed.
• Jan Kriesten showed examples of "Real World Scala and Wicket". If you'd not seen Scala before, this was probably pretty scary stuff in places. Jan clearly knows his Scala and his Wicket very well.
• Finally, Alastair Maw spoke about the evils of abstraction, which had some fine points about when to avoid it (mostly) and when to embrace it (rarely).

It looks like slides appear over at londonwicket.org.

This year the London Future of Web Apps conference was held at the ExCel centre. Ah, the ExCel: a place that feels both sterile and grimy—something I thought only possible at airports and large shopping centres.

The conference? It lacked substance, and was disappointing in that respect. Still, that's not what it's all about: it's good to just take some time away from the keyboard, and talk to people about "stuff".

I did enjoy...

• Matt Biddulph talking about "Dopplr: It's made of messages". A good reminder that scale out is a lot easier if from day one you plan for N > 1. I.e,. more than one web server, more than one database, etc. I was interested to see that Dopplr use ActiveMQ for messaging; and we were pointed at Enterprise Integration Patterns as a book worth reading.
• Blaine Cook & Joe Stump on "Languages don't scale". A nice set up by insulting pretty much all programming languages, and then saying that of course, it's not about the language, it's about I/O and the architecture of scalability.
• Blaine Cook's second presentation was on "Using Jabber to make awesome web sites". In essence: polling sucks, use PubSub instead, and in particular use the Jabber protocols to make things scale. Well, it doesn't solve all the problems, but I think the audience by now had taken the hint that messaging is useful.
• I enjoyed the TechCrunch Pitch! event, in which five start ups pitched their ideas, Dragon's Den style. Except without any money being involved. And related to that (in my mind) on the following day was "Work/life balance or Blood, sweat and tears: Which is the startup way?". This was Tom Nixon arguing for some sense of work/life balance, while '80s throwback Jason Calacanis gave the other side of the argument. He didn't actually use the phrase "greed is good", but it was in the air. I liked that session; it was strangely energizing.