Tag: github

Enums for scala

Scala has very limited implementation of Enumeration. Enumerated objects can't extends other classes. Partial replacement for it is to use sealed classes. You can do pattern matching on them. When you ommit some possible value you will get compiler warning for not exhaustive pattern matching. One missing feature is that you can't get sorted values of all objects extending them. You can simple got it using my (40-lines) EnumOf class from scala-enum. Examples below.

Declaration

sealed abstract class Color(red: Double, green: Double, blue: Double)

object Color extends EnumOf[Color] {
  case object Red   extends Color(1, 0, 0)
  case object Green extends Color(0, 1, 0)
  case object Blue  extends Color(0, 0, 1)
  case object White extends Color(0, 0, 0)
  case object Black extends Color(1, 1, 1)
}

Usage

Color.values shouldEqual List(Red, Green, Blue, White, Black)

Color.valueOfOpt("Blue").value shouldEqual Blue
Color.valueOfOpt("NotExisiting").isEmpty shouldBe true
You can also enumerate on objects nested in instances

Declaration

case class DistanceFrom(srcCity: String, srcCoordinates: Coordinate) extends EnumOf[DistanceBetween] {

  case object ToBerlin extends DistanceFromSrcCityTo("Berlin", Coordinate(52.5075419, 13.4251364))
  case object ToNewYork extends DistanceFromSrcCityTo("New York", Coordinate(40.7033127, -73.979681))

  abstract class DistanceFromSrcCityTo(val destCity: String, val destCoordinates: Coordinate) extends DistanceBetween {
    override def srcCoordinates: Coordinate = DistanceFrom.this.srcCoordinates
  } 
}

sealed abstract class DistanceBetween {
  def srcCoordinates: Coordinate
  
  def destCity: String
  def destCoordinates: Coordinate

  def inKm: Int = Coordinate.distanceInKm(srcCoordinates, destCoordinates).toInt
}

Usage

val DistanceFromWarsaw = DistanceFrom("Warsaw", Coordinate(52.232938, 21.0611941))

DistanceFromWarsaw.ToBerlin.inKm shouldEqual 519
DistanceFromWarsaw.ToNewYork.inKm shouldEqual 6856

DistanceFromWarsaw.values.map(_.inKm) shouldEqual List(519, 6856)

Sonar Gerrit Plugin Release

Initial release

I am happy to announce a first release of my Sonar Gerrit plugin. This plugin reports Sonar violations on your patchsets to your Gerrit server. Sonar analyses full project, but only files included in patchset are commented on Gerrit. Please forward to project page for installation instructions.

This plugin is intended to use with Gerrit Trigger plugin for Jenkins CI server. Together they provide a great tool for automatic static code analysis.

How does it work?

At the moment you push a patchset to Gerrit, Jenkins is notified with a ssh event. It fetches a code with a patchset and it builds your changes. It quits when build or tests fail.

But if it succeeds, Sonar analase your project in a post-build action. This is a place where my Sonar Gerrit plugin shines. It asks Gerrit for changed files before analysis and after Sonar analysis is finished, plugin reports comments on these files as a Gerrit reviewer. Currently plugin always reports +1 for Code Review, as it's still in development. However, you should always treat these comments as hints to improve, not as direct errors.

Extras

I've released also a second plugin: Sonar File Alerts plugin. This plugin raises alerts on file level in Sonar. It extends default behaviour, which raises alerts only at root project level. It is useful when you create alert rules in Sonar like "Code Coverage < 60". Each file is checked against this rule!

If you use Sonar File Alerts plugin and an alert will be generated on some file, then a comment will be published on this file on Gerrit.

Feedback

Please provide a feedback on these plugins. Feel free to submit issues on github or comment. It's still an early stage so your input is very welcome!

Sonar Gerrit Plugin Release

Initial release

I am happy to announce a first release of my Sonar Gerrit plugin. This plugin reports Sonar violations on your patchsets to your Gerrit server. Sonar analyses full project, but only files included in patchset are commented on Gerrit. Please forward to project page for installation instructions.

This plugin is intended to use with Gerrit Trigger plugin for Jenkins CI server. Together they provide a great tool for automatic static code analysis.

How does it work?

At the moment you push a patchset to Gerrit, Jenkins is notified with a ssh event. It fetches a code with a patchset and it builds your changes. It quits when build or tests fail.

But if it succeeds, Sonar analase your project in a post-build action. This is a place where my Sonar Gerrit plugin shines. It asks Gerrit for changed files before analysis and after Sonar analysis is finished, plugin reports comments on these files as a Gerrit reviewer. Currently plugin always reports +1 for Code Review, as it's still in development. However, you should always treat these comments as hints to improve, not as direct errors.

Extras

I've released also a second plugin: Sonar File Alerts plugin. This plugin raises alerts on file level in Sonar. It extends default behaviour, which raises alerts only at root project level. It is useful when you create alert rules in Sonar like "Code Coverage < 60". Each file is checked against this rule!

If you use Sonar File Alerts plugin and an alert will be generated on some file, then a comment will be published on this file on Gerrit.

Feedback

Please provide a feedback on these plugins. Feel free to submit issues on github or comment. It's still an early stage so your input is very welcome!

Journal.IO 1.3 released

About


Just a moment ago (in February 17th) Journal.IO 1.3 has been released. Journal.IO (https://github.com/sbtourist/Journal.IO) is a lightweight, zero-dependency journal storage implementation written in Java. We use it in our project for storing application events (Event Sourcing pattern). It is a good, stable solution if you want to have simple in use event storage e.g. if you want to implement lightweight queuing mechanism and JMS is overhead for you.

New version resolves some bugs and improves delete operation performance. Unfortunately new version uses new log format which isn't backward compatible. Therefore we decide to write a simple migrating tool for migrate 1.2 version compatible logs to 1.3 version.

Migrator


Migrator was written in groovy. It is available on github (https://github.com/arkadius/journalioMigration). Also link to the tool is available from official Journal.IO homepage. To use it simply run:



oldLogsRoot is recursively scanned for logs which are migrated parallel in 5 threads (used ASYNC read mode additionally speed up this process). Migrated logs are written in the same hierarchy in newLogsRoot.