Sunday, February 16, 2014

Cloud at fixed price

I've recently started looking for a cloud server provider because I wanted to have my own VPS. After digging through many nice options as Amazon EC2, Rackspace and Digital Ocean I stumbled upon this strange website: Cloud At Cost.

They offer "Pay once" plans that were a little too good to be true, but for anyone that's not looking for a commercial production server, the offer is pretty good. After some research through the web I learned that they're a new company from Canada and backed by a large telecommunications provider.

The features they include in the package are a Server Panel, a support service(ticket system) and DDoS protection.

From the server panel the options available are:
  • Start/Stop/Restart server
  • Reverse DNS
  • Upgrade to a higher configuration
  • Web console (alwful)
  • Re-Image the machine with: Ubuntu 12.04.3 LTS, CentOS 6.4 or Debian 7.1
I've got myself a Quad Core Xeon with 2GB memory and 40GB SSD space. It has a limited 3TB network transfer limit(monthly), but for incredibly $140 dollars I think it was a nice deal. No options to backup an image are being offered at the moment, and that was somewhat frustrating to me.

Well, I'm still hoping that was not a scam, but so far everything is working fine and I don't have anything to complain.

For anyone that would also like to experiment on it but don't want to spend much money, they have a monthly $1 plan for a fairly simple machine(1 core, 512MB memory and 10GB SSD), it might be worth a try! Oh, these prices are also supposed to be a limited time offer, just so you know.

Resolving UnknownHostException right after installing Jenkins

I've just installed Jenkins on my CentOS 6.4 using the very instructions provided on Jenkins website:
Installing Jenkins on RedHat distributions

After the installation, even though Jenkins was up, I was getting the following exception on logs:

WARNING: Could not intialize the host network interface on nullbecause of an error: centos64: centos64: Name or service not known
java.net.UnknownHostException: centos64: centos64: Name or service not known
    at java.net.InetAddress.getLocalHost(InetAddress.java:1473)
    at javax.jmdns.impl.HostInfo.newHostInfo(HostInfo.java:75)
    at javax.jmdns.impl.JmDNSImpl.<init>(JmDNSImpl.java:407)
    at javax.jmdns.JmDNS.create(JmDNS.java:60)
    at hudson.DNSMultiCast$1.call(DNSMultiCast.java:32)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.UnknownHostException: centos64: Name or service not known
    at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
    at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
    at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1293)
    at java.net.InetAddress.getLocalHost(InetAddress.java:1469)
    ... 8 more

Now I don't have the slightest clue about why was jenkins trying to resolve to a server called centos64, but adding that entry to my /etc/hosts file resolved the problem:

127.0.0.1   localhost centos64

It guess it must have used some default configuration and got that network hostname that didn't exist.

Saturday, February 15, 2014

Running all jUnit tests in package with IntelliJ

To run all jUnit tests in a package using IntelliJ click on Run > Edit configurations:


On the left bar, click on the + sign and select JUnit (you must have JUnit plugin and JUnit dependencies on your project).


This will open a Dialog Window to edit the run configuration for a new test.

Name the new configuration, I've used the label <Run all tests>
The fork mode for JUnit allows you to run each test method or class in a separate process, if you're not sure what to use just leave it at <None>
On the <Test Kind> field, select the <All in package> option.
On the <Package> field, select the package from where tests should be executed, then click <Ok>.



It is also a good idea to click on the Code Coverage tab and add your test package to run coverage:


Now run your tests by clicking on the shortcut located on the top bar:


Results should be displayed at the bottom of the screen:


In case you want to see coverage, use the shortcut:

 

Results displayed on the dialog:


Steps to use Gradle with IntelliJ 12 to build a Spark web app

First, install Groovy and Gradle. This can be done by downloading and installing the binaries offered in their respective websites or using your favorite package manager. 
I've used brew for Mac: 
brew install groovy 
brew install gradle 
Make sure you add Gradle bin dir to your PATH and test installation using the following commands on your shell: 
gradle -v 
groovy -v 
On IntelliJ, Groovy's plugin is usually installed by default and Gradle's not. On the plugin list screen click on Install JetBrains plugin... and make sure both plugins are installed. 

Both IntelliJ 12 and 13 have the plugin for Gradle, but 12 doesn't have a full support so that it doesn't offer a Gradle project creation wizard for example. That's not a big deal, IntelliJ 12 is perfectly capable of applying the Gradle facet or import existing Gradle projects through build.gradle files. Most important, the JetGradle panel is available on both versions. That is the interface that will abstract Gradle's console commands and behaves very similarly to Maven or ant IDE tools.

Now let's start building our web app: create a build.gradle file on the root of the project, click on the JetGradle tab and then click on the Add link. Search your recently generated build.gradle file and click Ok. This will integrate JetGradle to your project.

If it is your first time using the Gradle IntelliJ plugin, the IDE might ask you to point your Gradle installation. Go to Preferences and on the Project Settings menu select the Gradle tab on the left column. The <Gradle project> field should contain your build.gradle file path. The <Gradle home> field should contain your Gradle installation path (in my case /usr/local/Cellar/gradle/1.8/libexec because I used brew to install it)

You can use the  command below in the shell in case you need help finding your gradle installation path.
which gradle
Gradle is highly configurable, but relies strongly on default tasks. For them to work, your web project should follow this structure: 
├── build.gradle
└── src
    └── main
        ├── java
           └── com
               └── moody
                   └── model
                       ├── JavaClass.java
                       └── GoesHere.java
        └── webapp                                                  
            ├── WEB-INF
               └── web.xml                                         
            └── index.jsp

Tip: If you create these folders mannually, in order to get IntelliJ to recognize these folders as src folders:
Right click on src/main/java and Mark directory as a Source folder (in blue)
Right click on src/test/java and Mark directory as a Test Source folder (in green)

If you have trouble creating the directory structure, try disabling the <Compact empty middle packages> on the Project panel configuration.
Now let's create a very simple web application using Gradle's convention over configuration features to use an embedded Jetty server. Add this to your build.gradle file:

The first block will require jetty plugin, which will require war and java plugins as well. That will provide all default tasks for build a java, web and jetty application(and handle embedding the server in the application.
The second block will add mavenCentral to the list of repositories where Gradle will look for dependencies.
The third block will add Spark web framework as a dependency of the project.

We're going to use Spark, a lightweight web framework for Java that will allow us to use Routes to respond to http requests. As we will be using the embedded Jetty server, a little configuration on the web.xml file will be necessary in order for Spark to use the Jetty server.
WebServer.java

web.xml


Now go to JetGradle view and click on Refresh Gradle Project. It might take a little while because dependencies might be downloaded. This will analyze all changes in the project and in the build file, import dependencies and etc. This will also refresh the list of available tasks in the tab Tasks. Clicking on it, you will see many defaults tasks.  Gradle allows you to create your own tasks and establish dependencies between them. In our case, we'll use Gradle's java and jetty plugins default tasks to build our web server with almost no configuration at all.

To start the application execute the jettyRun task(available on the JetGradle tab) that will compile, package and deploy the application.

Test it by browsing the URL: localhost:8080/testing-gradle3/hello

Now that's a very simple example of the simplicity of Gradle's automation tool. In very few lines of code we managed to handle a web application build and deploy. We also handled the management of other transitive dependencies.

The verbosity is amazingly little and Gradle also offer many other features. What I really like about it is the Task-like approach that reminds me of Ant, and avoids the overly complex configuration that Maven needs. The build.gradle file would be a mix of an ant build file and Maven's pom.xml, leveraging best features of both worlds.
And even though in this walkthrough I emphasized the nice IntelliJ interface for using it, Gradle can be used entirely through the console, just like Maven and ant.

The relationship between java plugin default tasks(from Gradle User Guide):


Awesome documentation can be found at: