New Blog
Please see my new blog on medium: medium.com/cloud-solutions.
Neuer Blog
Meinen neuen Blog zum Thema Cloud Solutions finden Sie auf Medium unter medium.com/cloud-solutions.
Add a Database to your own PaaS
This is the second part of our series on how to be your own PaaS provider using Dokku and RunAbove. The first part covered the basic installation and enabled us to deploy simple Play applications. In this part, we’ll deploy a more interesting application that uses a database.
Continue reading…
Run your own PaaS with RunAbove and Dokku
Last time, we looked at how we can run a Play application on Open Shift. Open Shift offers small instances (512MB memory) for free, but if you need more memory, it quickly gets rather expensive. For 1GB, the hour costs you 5 cents (that’s about 36$ per month). That’s too much for my hobby projects, so I started looking for alternatives. My requirements included 1GB of memory, a relational database that can hold more than just a few megabytes of data and ideally a deployment that isn’t any more work than a git push.
Unfortunately, I couldn’t find a PaaS provider that fit my needs, but I remembered reading about Dokku, the „Docker powered mini-Heroku. The smallest PaaS implementation you’ve ever seen“. Last week, I also learned about RunAbove, and that they not only offer really cheap machines, but also have pre-configured Dokku images (which I later realized isn’t such a big deal because it’s really simple to install):
Play 2.3 Applications on OpenShift
This is a quick how-to guide to get your Play 2.3 applications up and running on RedHat’s OpenShift PaaS. OpenShift unfortunately doesn’t support Play out of the box, and there are some pitfalls that can be quite annoying.
Why OpenShift?
As I said, OpenShift – contrary to many other PaaS providers like CloudBees or Heroku – does not support Play directly, but you can use a third-party „cartridge“ (that’s what they call the set of scripts and the initial template) to run Play. So why OpenShift? For a pet project, that I wanted to run as cheaply as possible, I needed a database with more than the usual 5MB / 10k rows you get with most free PaaS offerings. On OpenShift, you simply get 1GB of total storage, including your database.
Continue reading…
Detecting and Naming Boolean Parameters
After a recent discussion on the Scala-Internals mailing list on the pros and cons of methods that take boolean arguments, the consensus was that they should always be passed as named arguments. The compiler doesn’t enforce this, so it’s up to us IDE and tools developers to provide a solution. The code-analysis branch for the Eclipse Scala IDE can now warn you of such boolean arguments that are passed to Scala methods:
The warning comes with a quick-fix that inserts the parameter name:
Of course, the competition isn’t sleeping either, the IntelliJ Scala plug-in just got a bunch of new Intentions.
Quickfix to Expand Case-Class Bindings in Pattern Matching
When writing Scala code that involves pattern matching I often work with (nested) case classes and sequences of case classes. I usually start with a simple binding like this
case class Person(firstName: String, lastName: String)
List(Person("Mirko", "Stocker")) match {
case person :: Nil =>; ...
}
and then when I need to access members of the matched class convert it to use the extractor:
List(Person("Mirko", "Stocker")) match {
case Person(firstName, lastName) :: Nil => ...
}
What’s tedious about that step is that one needs to know how many arguments there are and name all the bindings. But not for much longer! I wrote a quick-fix for the Scala IDE that does this for you:
Ctrl+1 brings up the available quick fixes:
And this is what happens when the binding you’re expanding is used in the pattern’s body:
It also works if you use a typed pattern where the type is a case class:
This feature isn’t in the recently released Milestone 1, but it should be part of the next one (or one of the upcoming nightly builds). Suggestions for a better wording – expand case class binding – are welcome 🙂
Move Class, Object and Trait Refactoring for Scala
After lots of bug fixing and improvements of existing refactorings in the Scala IDE, I took a few days off between Christmas and New Year to finally implement a completely new refactoring: Move Class.
Move Class (see Fowler’s description if you’re unfamiliar with it) moves a top-level Class, Object or Trait definition into a different package. And if there exists more than one declaration in the file, you can choose to split-off one of the declarations or to move them all. The refactoring will move all the necessary imports along, and also update all the references to the moved implementation (other imports, or qualified names) in the project.
The refactoring can either be invoked from the menu, or by drag-and-dropping a file in the Package Explorer. Here are some screenshots of the refactoring in action:
It’s also possible to create a new package during the refactoring:
As usual, the changes can be previewed. In this case, the class is removed from the original source file and an import is added to its new location:
Looking at the created file, we see the changed package declaration (a copyright notice in the original file would also have been copied along to the new file) and some imports to types of the originating package:
There are a few limitations: the refactoring works only on Scala code, and it simply ignores visibility issues, so moving might result in compilation errors (cursory tests showed that this also happens in Eclipse JDT — my gold standard for refactoring implementations).
The Move refactoring will be part of the 2.1 release of the Scala IDE, for which there are nightly builds available.
Tag Cloud Visualization for Source Code
I’ve always been a huge fan of Wordle, so when I saw Fabian Steeg’s announcement of Cloudio – the SWT-based tag cloud visualization for Zest – I knew I wanted to do something with it, so I created Sourcecloud (suggestions for a better name are welcome).
Sourcecloud is an Eclipse plug-in that lets you create tag clouds of your source code. The idea for this project came from Kevlin Henney, who used such tag clouds in a presentation at Jazoon 2010 (if I remember correctly). Luckily for me, Cloudio comes with an example application, from which I was able to reuse most of the parts, so all the credits go to Cloudio’s creator Stephan Schwiebert.
Why would you want to make tag clouds for source code? It can give you a quick first impression of the quality of a code base. Ideally, you should see many names of the project’s domain. On the other hand, if you see lots of nulls, ints and Strings, chances are that the code will be hard to understand because there are not many domain specific types in it.
You can install Sourcecloud from the update site for integration builds into Eclipse Indigo. And here’s how the result looks:
And here’s a screenshot of the Eclipse view:
The source code is on GitHub, so if you want to add or change something, fork it and send me a pull request!
Organizing Imports in Scala
Organize Imports was a very often requested feature for the Scala IDE for Eclipse, so I wrote the first very limited version as part of my thesis. It couldn’t do much more than sorting the imports and collapsing them from multiple import statements to a single one. At the beginning of this year, Daniel Ratiu provided a patch that made Organize Imports recognize some of the unused imports.
One limitation we still had was that we didn’t really know the complete set of required imports, but this is required to, for example, replace all wildcard imports with the actually used ones. Another request was that it should be possible to push import statements down to the scope where they are used. For this, we also need to know which parts of the code require which imports.
Yet another motivation to write some code to analyze dependencies was that I want to provide a move refactoring, and for this too we need to know some of the dependencies in the code. But that’s for a future post, back to what we have now:
As you can see, just like the JDT, we can now configure grouping for imports (groups are separated by a blank line), and it’s possible to expand or collapse imports from the same package. The Scalaz or Lift users will likely want to always use wildcard imports on some packages and types, so this is also possible. The JDT has some additional options, but I think I implemented the important ones.
And there’s more! No, not Reversi, but if there are missing imports in the file, Organize Imports will add them for you:
This all is part of the latest beta release of the Scala IDE, so please give it a try and open a ticket if you find a problem.