Coderspiel

Help us demo Acro beta at #hackdisrupt by playing it now

Sun, 20 May 2012 11:28:32 -0400

Help us demo Acro beta at #hackdisrupt by playing it now

Disrupt 2012 begins

Sat, 19 May 2012 13:21:27 -0400

Disrupt 2012 begins

implicit.ly: herald 0.5.0

Tue, 15 May 2012 22:16:21 -0400

implicit.ly: herald 0.5.0:

implicitly-notes:

Tumblr Integration

This version of Herald is ported to use the Tumblr API for posting and is configured to publish to notes.implicit.ly by default. The “notes” subdomain is the new home of implicit.ly release notes and redirects are in place.

Upgrade and Authorization

You can upgrade Herald…

The old switcheroo.

Light Table - a new IDE (by Chris Granger)

Tue, 15 May 2012 08:41:23 -0400

Light Table - a new IDE (by Chris Granger)

Adam Hinz & George Adams: Dispatch, Unfiltered, Blue Eyes, & Play: A Comparison - PHASE: Philly Area Scala Enthusiasts (Philadelphia, PA) - Meetup

Mon, 07 May 2012 11:18:21 -0400

Adam Hinz & George Adams: Dispatch, Unfiltered, Blue Eyes, & Play: A Comparison - PHASE: Philly Area Scala Enthusiasts (Philadelphia, PA) - Meetup

"A good developer has a natural, almost visceral aversion to complexity."

Mon, 07 May 2012 10:11:16 -0400

“A good developer has a natural, almost visceral aversion to complexity.”

- Complication is What Happens When You Try to Solve a Problem You Don’t Understand (via bdarfler)

flatMap Oslo (May 15, 16) is Norway’s first Scala...

Sun, 06 May 2012 10:39:54 -0400

flatMap Oslo (May 15, 16) is Norway’s first Scala conference, and the first anywhere to have such exciting light fixtures. (Good speaker lineup, too.)

How to get to the Scalathon.

Mon, 30 Apr 2012 12:12:58 -0400

How to get to the Scalathon.

@jorgeO Parachuted into into enemy territory

Thu, 19 Apr 2012 13:36:10 -0400

@jorgeO Parachuted into into enemy territory

We need to teach our kids to code

Tue, 17 Apr 2012 09:06:34 -0400

We need to teach our kids to code

At first I was worried Viktor did not have a funny t-shirt but...

Tue, 17 Apr 2012 06:38:47 -0400

At first I was worried Viktor did not have a funny t-shirt but then he took off his Akka hoodie.

@marius not talking about Futures

Tue, 17 Apr 2012 05:50:39 -0400

@marius not talking about Futures

DataExpress talk

Tue, 17 Apr 2012 05:06:38 -0400

DataExpress talk

robot-vision 0.0.1 - implicit.ly

Sat, 14 Apr 2012 22:18:55 -0400

robot-vision 0.0.1 - implicit.ly:

Robot Vision Control (RVC) is an embedded unfiltered web server allowing remote control over the host machine similar to RDP and VNC, except control is handled at the http transport layer.

The client is a Chrome extension. This is rad.

Making Meetup: Meetup Futurism

Mon, 09 Apr 2012 13:28:48 -0400

Making Meetup: Meetup Futurism:

makingmeetup:

There are some features on Meetup that, while valuable, are enhancements to the core experience. We wouldn’t want these sometimes memory- and processor-intensive features to prevent someone from doing something as important as RSVPing to a Meetup. Because of this, these features have been…

Everybody needs a ListenableFuture interface.

giter8 0.4.2 - implicit.ly

Sun, 08 Apr 2012 23:24:37 -0400

giter8 0.4.2 - implicit.ly:

Because github is terminating its v2 APIs on May 1, 2012 and these are used by all earlier versions of giter8, you must upgrade in order to continue using the software.

Go ahead and upgrade now, before you forget and github terminates the APIs and you open a bug against giter8 and I get even more annoyed about this whole situation.

Testing Scala Libraries

Sun, 01 Apr 2012 19:03:00 -0400

In the course of developing some Scala libraries that have stuck around, I’ve generally found it helpful to users if I release artifacts compatible with the two most recent major versions of Scala. So at the moment I support everything between 2.8.0 and 2.9.1-1.

Binary compatibility across minor Scala versions can lessen the burden, but as long as the language continues to evolve there will be transition periods where libraries must support more than one major version. Instead of scrambling to handle multiple publishing targets every time this happens, it’s safer and easier to handle them always with the automation known as cross-building. This feature of sbt runs a build against a set of Scala versions and publishes distinctive artifacts, so that sbt can also retrieve artifacts that are compatible with a particular version of Scala.

The same is true, it would seem, for test frameworks. You need to run tests against your own library for all the versions of Scala you claim compatibility with. If you can’t use your test framework with a Scala version, you’re out of luck—and so are your users.

~~~

Since I’m starting fresh with Dispatch reboot I’m also starting fresh on its tests. There’s a lot of interesting efforts going on in testing Scala and I thought, surely, I could find one that is built for the different versions of Scala I support. But that’s just not the case. I tried the usual suspects, as well as every upstart Scala testing framework I could find, and none of them are being dependably cross-published.

I was almost ready to switch to JUnit, which I have never actually used for anything—but hey, it works for Foursquare. Then I remembered to ask Josh Cough what to do. And he told me (as he told me a few years ago when I wasn’t ready to listen) to just use ScalaCheck.

Obviously, ScalaCheck is not cross-built and published for every version of Scala that I support but it has one big advantage: no dependencies. You can generally build it without a lot of drama. And that made me realize that the answer has been there since sbt 0.10: source dependencies.

In their local form, source dependencies are unarguably practical. I’ve never had a better workflow for developing both a library and client application at the same time: you save one file in the library and all dependent sources in both projects are recompiled.

The remote form of source dependencies is more ambitious, and also trickier. In the most common case you specify a git URL that references a specific commit and sbt will clone that project and build it locally. The tricky part is that although the project is okay to build in sbt, it’s in a strange new world when it comes to distribution.

You can’t publish the project’s binaries to a Maven repository. And if you’re building a WAR or a JAR or something else, it’s unlikely that the source dependency’s classes are going to end up in that archive without some gnashing of teeth your sbt build definition. About the only thing you can do in a straightforward way is have your project be used as a source dependency by something else, which is neat but unpopular.

With test dependencies, we just don’t have the problem. Test artifacts aren’t meant to be distributed, they’re meant to be run locally by the project contributors. After the compiled tests pass, you don’t worry about them or their dependencies. Your work is done.

So using test frameworks with a library is the perfect use case for source dependencies, and ScalaCheck with its uncomplicated build the perfect source dependency. I did have to fork the repo to make some superficial changes. Incompatibilities with Scala 2.8 were introduced at some point, so I rewound to the last version tag before that and back-ported the sbt 0.11 build definition, which took all of five minutes. I pushed my changes to a fork on github and that was it.

But the configuration for this on the client library side is not-obvious, and I went though a few ugly iterations of it before I came up with something fairly short and sweet. Here’s the crux of it:

lazy val ufcheck = Project(
  "ufcheck", file("ufcheck")
).dependsOn(scalacheck % "test->compile")

lazy val scalacheck = RootProject(
  uri("git://github.com/n8han/scalacheck.git#1.8cc")
)

(If it looks weird it’s because it’s doing something amazing that you can’t do any other way.) ufcheck is some test code that I use in other modules, but you can pretend it’s a library module that just needs to use ScalaCheck. Its dependsOn clause sets a test dependency on the compile classpath of ScalaCheck, which is exactly what we need to do.

The scalacheck reference points to my fork and a tag “1.8cc”, which is my way of saying it’s version 1.8 with a build that cross-compiles.

And that’s it. Dispatch reboot is testable for life. No matter what happens in the future, it can be tested against different versions of Scala without asking anybody to publish anything.

Since Scala 2.10 is right around the corner I can start thinking about dropping support for 2.8 and updating this source dependency to a newer tag of ScalaCheck, if I feel like it. Or I can support 2.8 through 2.10—whatever! My build is flexible, that’s the whole point.

If only the same trick worked on everything.

"There’s one obvious way to define a set of named, type-safe fields: write a scala trait. Your config..."

Thu, 29 Mar 2012 09:10:05 -0400

“There’s one obvious way to define a set of named, type-safe fields: write a scala trait. Your config file can then just be a scala file that you compile and evaluate when the server starts.”

- Why Config?

On LINQ, Standards, Databases and Fruit | stmts

Tue, 27 Mar 2012 22:12:43 -0400

On LINQ, Standards, Databases and Fruit | stmts:

What’s left seems like low-hanging fruit. I have heard nearly nothing about it, but I’ll be damned if twenty people aren’t sitting around working on it somewhere right now: There needs to be an object/node/graph database built explicitly on LINQ-like principles and in a way as to optimize for LINQ-based usage patterns. The data conforms to object patterns instead of its own designs. The kind of queries you send it informs a dynamic query analyzer, rebuilding and maintaining indexes for optimal access. You don’t have to worry, really, about primary keys, but more about references to other things.

"The Java Platform group is looking for an experienced, passionate and highly-motivated Software..."

Tue, 27 Mar 2012 16:56:39 -0400

“The Java Platform group is looking for an experienced, passionate and highly-motivated Software Engineer to join our world class development effort. Our team is responsible for delivering the Java Virtual Machine that is used by millions of developers.”

- the OpenJDK group at Oracle is growing (John Rose @ Oracle)