I was experimenting with the Redmine, a popular Ruby on Rails open source project management web application. It’s pretty full featured: you can set up multiple projects, each with its own issue tracking, wikis, document stores, and calendars, all within the same instance of Redmine. But it didn’t have everything I wanted.
One problem that I quickly realized I wouldn’t be able to live with is that emails sent from a Redmine instance all use the same emission address. For me, this was a showstopper, since I had a requirement that each project would be tied to its own email address, which our users email for tech support. So I set out to figure out how to customize Redmine. While it would be trivial to simply modify Redmine’s source code directly, I wanted to be able to upgrade the original system, while preserving my customizations. The ideal way to do that is to create a plugin.
To start a Redmine plugin project is simple - there is a Rails generator for that:
ruby script/generate redmine_plugin <plugin_name>
In my case, I called it “project_email”. This creates your standard folder hierarchy for a Rails app: controllers, helpers, models, views, db, as well as a lib folder. The most important file is init.rb, which is invoked when the plugin is loaded. This contains some information that Redmine needs.
require 'redmine'
require 'mailer_patch'
require 'project_patch'
Redmine::Plugin.register :redmine_redmine_project_email do
name 'Redmine Project Email plugin'
author 'Lawrence McAlpin'
description 'Adds a per-project email emission address'
version '0.0.1'
url 'http://github.com/lmcalpin/redmine_project_email'
author_url 'http://www.lmcalpin.com/'
end
Like any Rails plugin, we can add our own tables and fields. We simply create a new migration that looks like this:
class AddMailFromToProject < ActiveRecord::Migration
def self.up
add_column :projects, :mail_from, :string
end
def self.down
remove_column :projects, :mail_from
end
end
… and run rake db:migrate:plugins to load it up! Now, the “project” model will automagically have a new property called “mail_from.”
At this point, I need to override some of Redmine’s controllers and models. The problem is: anything loaded by the plugin will be overwritten by the base application. That is not quite what we want. Luckily, Ruby makes it incredibly easy to tame those classes: through metaprogramming.
We set up a few modules with our patches and force the class to include it.
require_dependency 'mail_handler'
module MailerPatch
def self.included(base) # :nodoc:
base.send(:include, InstanceMethods)
base.class_eval do
alias_method_chain :issue_add, :project_emission_email
# ... override the rest of the methods as well
end
end
module InstanceMethods
def issue_add_with_project_emission_email(issue)
from_project issue
issue_add_without_project_emission_email issue
end
def from_project(container)
unless container.nil? || container.project.nil? || container.project.mail_from.nil? || container.project.mail_from.empty?
from container.project.mail_from
end
end
end
end
This code is straightforward: we override the issue_add method. alias_method_chain takes in two parameters, the first being a symbol representing the method we are overriding, as well as a suffix. In our case, we use “project_emission_email” as the suffix, so the alias_method_chain call will rename the original issue_add method to “issue_add_without_project_emission_email” and rename the “issue_add_with_project_emission_email” method that we define to “issue_add”. Any existing code that calls issue_add will end up calling our “issue_add_with_project_emission_email” method.
We simply override the original mailer to set the from address to the value set in the new “mail_from” field we added to our project. If no customized “mail_from” is set for a project, the default emission email will be used.
But now we have a problem: Redmine ignores any attributes not specifically marked as “safe.” So we need to modify the project model to add a call to
safe_attributes 'mail_from'
No problem! Monkey patching to the rescue!
module ProjectPatch
def self.included(base) # :nodoc:
base.class_eval do
unloadable
safe_attributes 'mail_from'
end
end
end
Unfortunately, in development mode, our model appears to be reloaded upon every request! And, you know what? The same thing happens to our mailer! Oh nos. But hey, no problem, we’ll just patch the Rails dispatcher to reapply the patch every time:
Dispatcher.to_prepare do
unless Project.included_modules.include?(ProjectPatch)
Project.send(:include, ProjectPatch)
end
unless Mailer.included_modules.include?(MailerPatch)
Mailer.send(:include, MailerPatch)
end
end
Now we’re almost done! We just need to modify the view. The easiest way would be to simply add our own customized _form.rhtml in the app/views/projects folder. Unlike controllers and models, the views in our plugin take precedence, so our _form.rhtml will be loaded instead of the one included in Redmine.
Redmine provides a hook that lets you add new fields, without overriding the entire view file. This would be the better approach (since a future version of Redmine may have other UI changes that we want) but it’s late, and this beer isn’t going to drink itself, so we’ll just stop here. We’ll learn about plugin hooks another time.
something to offer besides waiting to die -
Recently I had a discussion with @SoundSystemSDC about small companies in small towns competing to attract and retain professional tech talent and stem the brain drain. This topic had come up in the recent The Combine conference here in Bloomington, Indiana. A group of Midwestern executives discussed the challenges of tech companies in the Midwest. During the Q&A session, I asked how an Indiana business can compete given the gross disparity in compensation that you have compared to larger cities like New York City and San Francisco. I even pointed out a job description for a Wall Street job that paid in the six digits and pointed out how much more it was than a similar job for something in Indianapolis. The response was simply “well it’s better to raise a family here and you can’t buy a home in San Francisco.” Which no one really cares about when they first go on the job market. And once you’re launched on your career path, moving to the middle of nowhere isn’t generally considered a step up.
Sorry. If you’re in a small town and you want to attract and retain top tech professionals you’re going to have to try harder than that.
What can a small town with small companies do to attract and retain the top tech talent? Well, how about:
Alternate Compensation
Offer equity compensation to make up for the smaller salary compensation. Let them use some company resources for personal projects. Or something else. I don’t know. Be creative. But compensation doesn’t always have to be pecuniary.
Quality of Life
If you can’t pay Wall Street wages, don’t demand Wall Street hours. In New York City, day cares close at 7:30pm. The day care my daughter goes to here in Bloomington closes at 5:30pm. The day cares close at 7:30 in NYC because people are still working then. You want that top talent to move over to you, but you can’t pay the same? Point out that a move from a 60 hour week to a 40 hour week takes into account 33% of that wage difference already.
Embrace Attrition
Developers crave new experiences. Accept it and embrace it. Get smaller companies within the same community to work together to find ways that can allow for employees who want new experiences to move ‘laterally’ to other companies in the area. That is: help your employees get a job with other companies in your area.
If you work for a larger company, chances are they make it easy to apply for dozens of other opportunities as they arise within the same company. Even outside of the larger companies, in NYC, Chicago, or SF, you can find hundreds of job opportunities with the drop of a hat. I got cold calls from recruiters daily. Here in Indiana, not so much. Realize that people want the opportunity to move on to other opportunities and develop new skills or work on something new. Make it easy for them to do so. Brain drain is bad for everyone; but it’s better to lose your best guy to someone up the street than to see them leave the local community (or the state) entirely. And if you help them go on good terms, they’re more likely to come back.
Also, the cross pollination within the community creates additional bonds that help retain that talent.
Promote the Community
Use the power of local government or band together with fellow local businesses to promote each other and local leaders in the tech community. People want to be recognized for their accomplishments. Big companies and big cities tend to anonymize people: even the cream of the crop can easily end up being no more than a small fish in a BIG pond. Maybe they’d rather come here where they can be a big fish in a small pond. But give them the satisfaction of having people around who will notice that. Otherwise, they’re no better off.
Pay Them What They’re Worth, But Be Selective
If you can afford it, suck it up and pay them what they can earn. People like money, and the better cost of living is attractive when your salary is the same. Obviously this is a risky approach. No one wants to get stuck with a total dud who soaks up twice the salary. But if you’re smart and you’re careful, the experiences these developers have honed in the bigger and much more highly competitive markets can be very beneficial to you - and that one developer can very likely be worth a small team.
I noticed a huge increase in the caliber of the developers I worked with when I first moved to Chicago (and, later, New York City) from the smaller Midwestern town I first worked in (even though I worked at a Fortune 50 company that could afford to pay a pretty competitive rate.) Where I worked initially, people usually came in straight out of college and stayed there their entire lives. Developers I worked with in Chicago and New York City, on the other hand, were constantly exposed to new ideas and new concepts and tended to learn a lot more. Sure, the internet helps spread those ideas to even the remote places on Earth, but the fact is the big cities attract the better developers since there are more challenges there and more people to learn from. You can get more developers for the same amount of money here in the Midwest, but you often get what you pay for.
Telework
OK, maybe you can’t match that six digit coastal salary after all. Sadness. But I bet that just as that New York City salary dwarfs our Midwestern Indiana tech salaries, there are places where our measly offering would be pretty attractive. Where people might want to live despite the fact that it’s not here in Bloomington, for whatever inexplicable reason they might have.
Once upon a time, that might have been a deal breaker. Businesses tended to form near related businesses in the past for a reason. Distance made it harder to trade, communicate, and meet one another. Nowadays, a little invention called the Internet makes it easy to do all three of those things in our underwear. With miles and miles between each of us. So why are we still expecting everyone to sit down next to each other? In my experience telecommuting, I can assure you, I am far more productive now that I have fewer officeplace distractions.
So while your Big City competitors are busy paying half of their budget on overpriced real estate and have half of their workforce tied up suiting up and battling a century old subway system, you can focus on more important things like real work with real people wherever they happen to want to live.
Anything Else?
There are probably plenty of ideas out there that a smaller town with small companies can do to make itself more attractive besides compensation. But seriously guys, give up on the cost of living calculator argument. It’s not compelling. If cost of living is your argument, we may as well move to McAllen, Texas. I hear it’s pretty cheap to live there.
You want to stop brain drain? Either match the coastal salaries, drain brains from some other community (via teleworking), and/or find a way to nurture a stronger sense of community that instills a sense of belonging, where ones’ successes are noticed and celebrated, and ones’ skills are actively developed - even if it means working within the local community to make it easier - or encourages - people - and their ideas - to move from company to company.
We’re building out an application to support this high profile effort that involves something like 10 different teams. My team’s application has over a million lines of code, 8000 classes, and Needs To Work(tm). Or heads will roll. And mine doesn’t like to do that, because it might get all scruffed up. So naturally we decided to get down with the BDD and use the Cucumber. But since we’re enterprise Java developers, things get a little more complicated. Because that’s how we roll.
We use JRuby so our Ruby code can talk to our Java code and it’s totally awesome and all that. But when it comes to deploying, right now we have a simple process that involves a script (using a proprietary internal tool that is kind of like SCP except it leaves me wishing it actually was) that bundles up all my deliverables and sticks it on the target server. The application servers and Java platforms and so on are already there, usually maintained by other teams.
I wanted to build the application on a build server where the features will be run whenever code changes (using hudson to trigger the scripts). I know what versions of Java will be available on the target servers, since there are architectural standards within the enterprise that I can count on. And, among those standards, I can count on not having any variety of Ruby anywhere unless I put it there myself. But that complicates our process, because I really shouldn’t be adding things to the server (which my team doesn’t own or control). And even if I did, then the server would have an additional component that existed nowhere else which would need to be maintained and loved and cared for, and I’m not at all into that sort of thing.
So I says to myself: how do I simplify this process? And myself says back: stick your cucumber in it.
So I did. But what does that mean, you say? Well, besides being what the cool Java kids are calling it these days, what I mean is that I stuck Cucumber and its dependent gems inside the JRuby jar which meant that all I needed to do was bundle a single extra jar in with the application that we build. This makes deploying the exact same version of Ruby with the exact same gems to any machine or environment really easy: you just copy one file around the network. Even a caveman could do it. But TCP/Smoke Signal was notoriously slow and error prone so they usually didn’t.
The process is super easy to do. First of all, you need to download the source code. You can get it from github (http://github.com/jruby/jruby) or just download the source jar: http://jruby.org/download
What we want to do is build the jar-complete version of the distributable, which is a completely standalone JRuby environment encapsulated as a single jar. If you inspect the ant build script (which is like a make file in the Java world), you’ll see the target “jar-complete” invokes a command to install additional gems defined in the “complete.jar.gems” property. This will by default be found in the “default.build.properties” file. I just edited it directly, and added a reference to a new property “cucumber.gems” to the end:
complete.jar.gems=${rspec.gem} ${rake.gem} {$ruby.debug.gem} ${ruby.debug.base.gem} ${columnize.gem} ${cucumber.gems}
Then we need to define the cucumber gems we want. To ensure the build is predictable, I specify each gem and dependency along with its version:
cucumber.gems=${build.lib.dir}/cucumber-0.9.2.gem ${build.lib.dir}/builder-2.1.2.gem ${build.lib.dir}/diff-lcs-1.1.2.gem ${build.lib.dir}/gherkin-2.2.9-java.gem ${build.lib.dir}/json-1.4.6-java.gem ${build.lib.dir}/term-ansicolor-1.0.5.gem
Now you need to get the gem files and put them in the jruby_src/build_lib folder. When you run the build, it will download the actual gem sources. I just copied the gem files from an existing JRuby installation’s gem cache (jruby/lib/ruby/gems/1.8/cache), but you can do it any way you want.
Now run “ant dist-jar-complete” and you’ll be presented with a lovely, customized version of jruby-complete-1.x.y.jar in your jruby_src/dist folder ready for the cukes or whatever else you want.
You could then invoke it by calling:
java -jar jruby-complete-1.5.3.jar -S cucumber features
There’s been some buzz lately about Scalatra, which is a Sinatra like framework for Scala. Sinatra is a very scaled down platform for web programming in Ruby. Unlike many web frameworks (such as Lift, JSF, etc.) which tend to be very stateful and try to abstract away from the HTML and web technologies, Sinatra does no such thing. It’s very low level, which can make it very fast to get up and going for smaller, stateless web applications, especially REST based services. Scalatra is an attempt to bring that to the Scala world.
To create our Hello World webapp in Scalatra, we’ll first create a dummy project. Create a new folder to hold our project and use the simple build tool (sbt) to create your project.
md HelloScalatra cd HelloScalatra sbt
You’ll get output like this:
Project does not exist, create new project? (y/N/s) y Name: HelloScalatra Organization: test Version [1.0]: Scala version [2.7.7]: 2.8.0 sbt version [0.7.4]:
Now you need to tell the simple build tool what additional libraries you need for your project. We’ll create a project build file to do that. This works kind of like a Gemfile in the sense that it lets the build tool know what dependencies we have. The build file is written in Scala itself.
Create the file ScalatraBuild.scala in the HelloScalatra/project/build folder.
// save as project/build/HelloScalatraBuild.scala
import sbt._
class ScalatraBuild(info: ProjectInfo) extends DefaultWebProject(info)
{
// scalatra
val sonatypeNexusSnapshots = "Sonatype Nexus Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
val sonatypeNexusReleases = "Sonatype Nexus Releases" at "https://oss.sonatype.org/content/repositories/releases"
val scalatra = "org.scalatra" %% "scalatra" % "2.0.0-SNAPSHOT"
// jetty
val jetty6 = "org.mortbay.jetty" % "jetty" % "6.1.22" % "test"
val servletApi = "org.mortbay.jetty" % "servlet-api" % "2.5-20081211" % "provided"
}
Now download the dependencies. This is similar to running bundle install in a Rails app.
sbt update
One drawback of Scalatra is that it is a Servlet-based framework. That means we aren’t getting away without creating a web.xml file. So let’s set that up. Since simple build tool uses maven conventions, we need to do that in the HelloWorld/src/main/webapp/WEB-INF folder.
HelloWorld/src/main/webapp/WEB-INF/web.xml:
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<servlet>
<servlet-name>HelloWorld
<servlet-class>com.test.HelloWorld
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld
<url-pattern>/*
</servlet-mapping>
</web-app>
This says that we will have a Servlet handled by the com.test.HelloWorld.scala file (which we haven’t written yet) and it will respond on all URL patterns.
Now we can actually write our app. Simply create the HelloWorld/src/main/scala/com/test/HelloWorld.scala file:
HelloWorld/src/main/scala/com/test/HelloWorld.scala:
package com.test
import org.scalatra._
class HelloWorld extends ScalatraServlet {
get("/") {
"Hello World"
}
}
Now we can start the web server:
sbt jetty
And we can browse to http://localhost:8080/ and we’ll see:
Hello World
I was migrating a JSF application to JSF 2 and noticed that none of the JSTL tags worked anymore. And Googling for a reason for that hasn’t been very helpful as 99% of the posts regarding “JSTL and JSF” just say “don’t”.
The prevailing wisdom used to be that you shouldn’t mix JSTL and JSF, and once upon a time that was very true. But JSF and JSTL has worked pretty well together since at least 1.2, and while in general you should avoid JSTL when there’s an equivalent purely JSF-based solution, there are times when it just makes more sense to use JSTL. So I was disappointed at first to see that this didn’t appear to be working anymore.
Well, it turns out, JSF 2’s Facelets specification requires support for JSTL and both major implementations includes the taglib.xml so we’re good. There’s no reason to rewrite all those .xhtml files just yet.
It turns out the problem was simply that the taglib namespace had changed from
xmlns:c=”http://java.sun.com/jstl/core”
to
xmlns:c=”http://java.sun.com/jsp/jstl/core”
I couldn’t find documentation anywhere about that, so here you go, Googlers. Hopefully I saved a few of you a couple of headscratching minutes.
If you consume a JAXB-RS web service using Jersey, you might encounter an issue when attempting to construct a generic List returned by the service. To get a simple object, you would simply call this code:
Client client = Client.create(); Foo foo = client.resource(url).type(mimeType).get(Foo.class);
But because of type erasure, this isn’t as straightforward for returning a generic collection. As with most APIs that require type-information at runtime for generics, you have to pass in a type token. With Jersey, you can do that by passing in a concrete instance of com.sun.jersey.api.client.GenericType.
Client client = Client.create();
List listOfFoos = client.resource(url).type(mimeType).get(new GenericType<List<Foo>>() {});
This works because when you create a construct a subclass for a generic type, the class can, via reflection, obtain its own parameterized type.
Type superclass = getClass().getGenericSuperclass(); Type myTypeArguments = ((ParameterizedType)superclass).getActualTypeArguments()[0];
This is why GenericType is abstract and you are forced to instantiate a subclass with the type information you want Jersey to know about.
Not exactly an ideal solution (reified generics would be better), but it gets the job done.
I decided to mess around with some Ada. This is an old school compiled language, that is popular with the Department of Defense and almost nobody else. Except me. Mainly because I like the name. It’s pretty.
So here’s what you do:
1) Download the GPL version of GNAT from AdaCore. Make sure you grab AWS also.
2) If you are using Windows, you will need to have a Unix shell prompt available to you. You can get this using Cygwin or MINGW.
3) Install GNAT.
4) Unzip the AWS source code. In a moment, we will build this library. For some reason, on my machine, it didn’t auto-detect the install directory of GNAT properly, so first edit makefile.conf and update the prefix line to point to that directory you installed GNAT into.
5) Run “make setup build install” to install AWS libraries so your projects can find them.
6) Go into the templates_parser subdirectory and edit makefile.setup to change your installation directory and run “make install”.
There is no standard way to install libraries so you have to actually read the README and INSTALL files.
7) Use GPS (which comes with GNAT) or install GNATBench (Eclipse plugin) to set up a new Ada project. Declare the main source file to be “Server.adb”.
8) Create “Server.adb”:
Server.adb:
with GNAT.IO; use GNAT.IO;
with AWS.Default;
with AWS.Server;
with ServerCallback;
procedure Server is
WS : AWS.Server.HTTP;
begin
AWS.Server.Start (WS, "Hello World",
Max_Connection => 1,
Callback => ServerCallback.Echo'Access);
AWS.Server.Wait (AWS.Server.Q_Key_Pressed);
AWS.Server.Shutdown (WS);
end Server;
This sets up a new web server and declares that the method Echo in the file ServerCallback.adb will handle our HTTP requests. The .EXE will run until you hit the Q key. It will listen, by default, on port 8080.
9) Define the server callback files “ServerCallback.adb” and “ServerCallback.ads”.
ServerCallback.adb:
with Templates_Parser; use Templates_Parser;
with Templates_Parser.Utils; use Templates_Parser.Utils;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
package body ServerCallback is
function Echo (Request : AWS.Status.Data) return AWS.Response.Data is
pragma Unreferenced (Request);
URI : constant String := AWS.Status.URI (Request);
Params : constant Translate_Table := (1 => Assoc("URI", URI));
Response : Unbounded_String;
begin
Response := Parse (Utils.Get_Program_Directory & ".." & Directory_Separator& "site.thtml", Params);
return AWS.Response.Build ("text/html", Response);
end Echo;
end ServerCallback;
ServerCallback.ads:
with AWS.Response;
with AWS.Status;
package ServerCallback is
function Echo (Request : AWS.Status.Data) return AWS.Response.Data;
end ServerCallback;
This loads a template file called site.thtml and passes in a parameter URI which gets resolves to the request URI. The parameters are passed to the template_parser using TranslateTable or TranslateSet (I used TranslateTable because I knew in advance how many parameters I would have.)
The actual template itself I put in the root folder of the project (“..” from the obj_debug folder that server.exe gets deposited in.) It’s basically html with tag declarations that the template_parser replaces with the parameters you supplied above.
site.thtml:
<html>
<body>
Hello from @_URI_@.
</body>
</html>
Now you can hit http://localhost:8080/whatever and you should see the response echo the URI you provided.
You might be wondering how the same program would look in Ruby. Well, like this (assuming you have Ruby and the Sintra gem installed):
require 'rubygems'
require 'sinatra'
get '*' do
"Hello from #{params[:splat]}"
end
But that’s nowhere near as fun.
(Of course, Ada isn’t really a language intended for web programming. And I don’t think I would feel comfortable in an airplane where the fly-by-wire controls were powered by the Ruby VM and the software cobbled together by splicing together features from a half dozen open source gems.)
I’m starting a small Rails project for a webapp that I hope to have ready by January. While working on building up the application’s foundation, I ran into a small compatibility issue with Devise and Rails 3.
Devise 1.3.3 and Rails 3.0, on my Windows development machine at least, seems to have some kind of issue where the helpers don’t become available. authenticate_user!, user_signed_in?, current_user, and user_session were unavailable to controllers or views. Backing out to Devise 1.3.2 did the trick, everything works fine now.
So I have this Spring app that uses Hibernate and I’ve defined my model. And I want to generate the DDL that I need to run to get the database in sync with my model. I also want to get the DDL for tables needed for use with the Envers auditing framework. Here’s how you get all that:
@Autowired
LocalContainerEntityManagerFactoryBean lcemfb;
public void printUpdateScripts() {
Ejb3Configuration ejb3 = new Ejb3Configuration();
ejb3.configure(lcemfb.getPersistenceUnitInfo(),
lcemfb.getJpaPropertyMap());
Configuration config = ejb3.getHibernateConfiguration();
config.buildMappings();
AuditConfiguration.getFor(config); // include audit tables
Dialect dialect = Dialect.getDialect(config.getProperties());
DatabaseMetadata metadata;
Connection conn = null;
try {
EntityManager em = lcemfb.getObject().createEntityManager();
conn = ((HibernateEntityManager) em).getSession().connection();
metadata = new DatabaseMetadata(conn, dialect);
String[] scripts = config.generateSchemaUpdateScript(dialect,
metadata);
// String[] scripts = config.generateSchemaCreationScript(dialect);
// String[] scripts = config.generateDropSchemaScript(dialect);
for (String script : scripts) {
System.out.println(script);
}
} catch (Throwable t) {
t.printStackTrace();
} finally {
if (conn != null) {
try {
conn.close();
} catch (Throwable t) {
t.printStackTrace();
}
}
}
}
And LocalContainerEntityManagerFactoryBean is just your standard Spring FactoryBean for creating EntityManagerFactory instances.
<bean id="lcemfb" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceUnitName" value="..." />
<property name="dataSource" ref="..." />
<property name="jpaVendorAdapter" ref="..." />
</bean>
In my last post, I mentioned that I created a simple (very simple!) Google App Engine hosted Play! webapp, written using Scala. The webapp simply tracks people who visit my blog. More accurately, it tracks people who view a little PNG that one of the methods renders. If someone GETs the image, I capture the visitor’s IP address and the time. This won’t be replacing anyone’s use of Google Analytics anytime soon, I can assure you.
But for the edification of those who may want to play with Play! and Scala, this is what I did:
controllers.scala:
def index {
val visits = Visit.recent
render(visits)
}
def track {
val trackedIP = new Visit
trackedIP.remoteAddress = request.remoteAddress
trackedIP.referer = request.headers.getOrElse("referer", None)
// store it in The Cloud(tm)
trackedIP.insert()
// this is the image they see
val file = Play.getFile("/public/images/favicon.png")
renderBinary(file)
}
Note the “getOrElse” call above. This is one of the nice features of Scala. This is there because request.headers is a Map and the referer key isn’t guaranteed to be there. In Java, we would do this:
Http.Header refererHeader = request.headers.get("referer");
String referer = "";
if (refererHeader != null) {
referer = refererHeader.toString();
}
trackedIP.referer = referer;
That’s quite a mouthful, and the Scala version is much more readable.
The Visit class extends siena.Model and declares the properties that we will store on the database. The Visit object is a singleton; if we were writing a Java object, the static/class methods we put on the Visit.class are what we are putting in the Visit object here. In our case, we simply create a method “recent” which returns up to 20 of the most recent visitors. The @Index on the date field is necessary so Siena can order by date, which we will do in reverse order (because we want the most RECENT visitors.)
models.scala:
import play._
import play.data.validation._
import siena._
import java.util.Date
class Visit extends Model {
@Id var id:Long = _
var remoteAddress : String = _
var referer: String = _
@Index(Array("date_index")) var date : Date = new Date
}
object Visit {
def recent:java.util.List[Visit] = Model.all(classOf[Visit]).order("-date").fetch(20)
}
Your views are done in the same manner that you would do them in a Java-based Play! application: via Groovy templates. Of course, you can always replace the template engine with Scalate or whatever else you prefer, via Play! plugins.
One handy trick I learned was the use of the JavaConversions helper class, introduced in Scala 2.8, which adds some implicit conversions between Java and Scala collections classes. This way, if you want to process the result of our call to Visit.recent using Scala style closures, you could do this:
import scala.collection.JavaConversions._
Visit.recent.foreach(v => println(v.remoteAddress))
This isn’t the most useful application, but it does provide a nice starting point for toying with the language.