tetrix in Scala: day 0

Every now and then I get an urge to explore a new platform, new ways of thinking, even a new programming language. The first thing I try to implement is always the same: a clone of the famous falling block game. I've implemented them in I think eight languages, Palm V that I borrowed, and on Android. Probably the first Scala program I wrote was Tetrix too. Some had network capability so two players could play against each other, and C# one had AI that kept playing on its own.

C# LINQ for Scala heads

This is a memo of C# Linq features for Scala programmers. Or vice versa.

Type inference

C# has type inference. I try to use var when I can for local variables.

var x = 1;

Scala also has var, but the preferred way is to use immutable val if possible.

val x = 1

Creating a new List or an Array

C# can create collections in-line.

using System.Collections.Generic;

IKEA DIY standing desk


sbt plugins roundup


Unlike XML-based build tools sbt's build definitions are written in Scala (for both .sbt and .scala). This means that once one gets over the hurdle of learning sbt's concepts and operators, it doesn't take much for build users to start writing sbt plugins.

I've ported a few from sbt 0.7 before, but I've also been writing some original ones recently that I'd like to share.

treehugger.scala pamflet

treehugger.scala is a library to write Scala source code programmatically. It's also an implementation of Scala AST based on Reflection API, now available from github eed3si9n/treehugger.

I've expanded this into a complete guide using awesome n8han/pamflet.

implicit parameter precedence again

Scala the language is one of the most elegant, expressive, consistent, and pragmatic languages. From pattern matching to the uniform access principle, it got so many things right. And Scala the ecosystem and Scala the community only makes it better.

In Scala 2.9.1, locally declared implicits are preferred over imported ones. The problem is that the spec does not cover such behavior. My original hypothesis was that either I did not understand the spec correctly, or the spec was wrong. Based on the assumptions, I set out to explore the implicits resolution precedence last week. Like MythBusters say, the best kind of result is when you get something totally unexpected. It turns out that both of the hypotheses were wrong.

My understanding of the relevant part of the spec was correct, and spec was correct as well. According to SI-5354, what's wrong was the compiler implementation:

revisiting implicits without import tax

Northeast Scala Symposium 2012 is coming up in a few months, but I want to revisit a talk from this year's nescala to wrap up 2011. One after the other, nescala had amazingly high quality of talks. You can check them all out here. With Daniel's Functional Data Structure and Jonas's Akka each having an hour-long key notes, the symposium left an impression on me that actors and FP are two major forces within Scala community. (Paul declaring that sending messages to actors is not referentially transparent was a hint too, I guess) There were also earlier signs of how the year turned out, like Mark's sbt 0.9 presentation and Nermin's Scala performance consideration. One talk that stood out in terms of immediate impact to change my code was Josh's talk: Implicits without the import tax: How to make clean APIs with implicits.

field test: conscript, giter8, and sbt-dirty-money

Just wanted to share a few techniques of everyday coding using some of the Scala tools.
Suppose you're developing a tool or a library, and you get a bug report. My first focus, before I start analyzing the cause, is to reproduce the issue using the same data the user is using. Once the issue is reproduced, then you can move on to simplifying the issue into a failing spec or functional test. Once the bug is fixed, you can then use the same setup to confirm the fix using the real data.

an unofficial guide to sbt 0.10 v2.0


don't panic

If you've just landed from 0.7 world, sbt 0.10 is overwhelming. Take your time to understand the concepts, and I assure you that you'll get it in time, and really love it.

three representations

There are three ways you may interact with sbt 0.10, which could be confusing at first.

  1. shell, which you get when you start sbt 0.10.
  2. Quick Configuration DSL, which goes into build.sbt or in settings sequence.
  3. good old Scala code, aka Full Configuration.

testing sbt plugins


NOTE: Official docs: http://www.scala-sbt.org/1.x/docs/Testing-sbt-plugins.html

Let's talk about testing. Once you write a plugin, it turns into a long-term thing. To keep adding new features (or to keep fixing bugs), writing tests makes sense. But how does one go about testing a plugin to a build tool? We fly, of course.

scripted test framework

Syndicate content