Install JDK on OSX Yosemite

jdk

For some reason, Oracle blocked the installers to run only on a fixed OSX version range with a nice and explanatory error message. This range doesn't include Yosemite, which makes sense, since nobody running Yosemite will ever want to write some Java. Anyway, here is how to fix it.

First, download and open the JDK .dmg file. Then, unpackage and edit the Distribution file:

$ pkgutil --expand "/Volumes/JDK 7 Update 67/JDK 7 Update 67.pkg" /tmp/jdk7.unpkg
$ cd /tmp/jdk7.unpkg
$ vim Distribution

PS: I'm using vim, but you can use whatever editor you want, since it is vim.

Replace this function:

function pm_install_check() {
  if(!(checkForMacOSX('10.7.3') == true)) {
    my.result.title = 'OS X Lion required';
    my.result.message = 'This Installer is supported only on OS X 10.7.3 or Later.';
    my.result.type = 'Fatal';
    return false;
  }
  return true;
}

with this:

function pm_install_check() {
  return true;
}

just remove that if statement.

Then, just package and run the installer with:

$ pkgutil --flatten /tmp/jdk7.unpkg /tmp/jdk7.pkg
$ open /tmp/jdk7.pkg

The JDKs will be installed in the /Library/Java/JavaVirtualMachines/ folder.

You can also clean up your mess:

$ rm -rf /tmp/jdk7.*pkg

You can use this tip for JDK 8 too.

Comment this post here.

Java 8

Earlier this year, the new version of the Java Programming Language was released. Finally, it enters in the field of the "cool guys" with some features it should have since some years ago, like Lambdas.

"Java developers are now Hipsters again!"

Seen somewhere in the wild internet.

Anyways, I have been reading about and building simple algorithms with it since day one, but, now that I'm using it in a "real world" project, I would like to say some words about how the experience is going.

But firsts things first. The new features!

The new features!

Well, this version surelly have a lot of cool new features, so, I would like to point out my personal favorites!

1. Lambda Expression

This is really awesome. A lot of languages have this feature for years now, and for years I've been talking about how Java should have this. Now, finally, we have:

Runnable runnable = () -> System.out.println("Run forrest, run!");

Even if the implementation "behind the scenes" is not quite the best, in my humble opinion it is better than the interfaces with all that weird inner classes that we were using before:

Runnable runnable = new Runnable() {
  @Override
  public void run() {
    System.out.println("Run forrest, run!");
  }
};

2. The Stream collection types

I have to admit, this is awesome! We can do all sort of things with a DSL that is actually enjoyable to use:

Map<String, String> hash = new HashMap<>();
hash.entrySet().stream()
    .map(entry -> entry.getValue())
    .filter(entry -> entry.startsWith("C"))
    .distinct()
    .count();

There is also methods for parallel sorting and other stuff (parallelStream). Check also the IntStream class.

3. The new Date and Time API

This is another one that was required for years. Basically, they moved the Date/Time API to the java.time package and followed the Joda Time format, with the good thing that most classes are Threadsafe and immutable.

I just can't wait for Java 8 and the Money API! :moneybag:

4. String.join

I still can't believe that it taked so long...

System.out.println(String.join(". ", "FINALLY", "String", "joining"));
// FINALLY. String. joining

5. Optional

I posted about this in my Facebook timeline and it ends up becoming a little noisy. Anyway, I would really preffer a ruby-ish approach to this problem, but, well, this is better than nothing. I have used it in some filter calls like this, for example:

List<String> names = new ArrayList<>();
names.stream()
    .filter(entry -> entry.startsWith("C"))
    .findFirst() // returns an optional
    .get(); // tries to get its value (might throw NoSuchElementException)

Working with it in the wild

Update all the things! That's it.

I have to admit that I was expecting for this. Almost every library I was using before (with Java 6 or 7) had to be updated.

Some of them aren't even working, and needed some special attention, like openning a pull-request with the fixes and the deploy of custom version with the fix in local nexus repository until the new official version is released, but, nothing that can't be fixed.

This isn't really bad, it's just labor intensive... and a little tedious. Looking for the bright side, you always learn a little. :sparkles:

Resources

Well, you have probably read something about Java 8 already, but, if you didn't, or just want to read more, I recommend you to read the Java 8 Friday at the jOOQ's blog. They have plenty of good study material about this manner.

I could also recommend you a book that I have read: Java 8 Lambdas: Pragmatic Functional Programming. ?

If you want to read some Java 8 code, I have solved some katas using it just for fun. They are probably pretty bad, so feel free to suggest improvements. You can take a look at the source code here.

I have also ran a small Ruby Sinatra service with the last version of jRuby under JDK8 and it worked gracefully. You can take a look at it here.

Well, this is all for now. Feel free to ask anything you want in the comments box bellow!

Cheers!

Comment this post here.

Find the slowest tests of a Java project

I found that it's pretty hard to have a project with high test coverage and fast build... if the tests are slow, people will feel the need to skip them to speed up the build, and will probably write less tests than they should, afraid that the build will became even slower. You go out for a walk and when you come back no one is running or writing tests anymore...

One way to avoid that is to track down the slowest tests and fix them. The less dependencies your test have, the fast it will run. Just saying.

Paraphrasing Uncle Bob:

"The first rule about tests is that they should be fast. The second rule about tests is that they should be faster than that."

** Actually he said that about method sizing, but, I think this fits just fine.

To help with that, I wrote a small script to generate a list of the slowest JUnit tests. It should give you some direction in where to attack. The script is pretty simple, but it does the job.

git clone https://gist.github.com/9420690.git scripts
scripts/slowest-tests project/folder

You can also generate that list in CSV format by running:

scripts/csv-slowest-tests project/folder

More than that, you can use maven-profiler to find other slow parts of your build and fix them.

One last tip: if are having problems with low test coverage in your project, try coverage-maven-plugin, a maven plugin that will blame pull request with coverage bellow a specified amount.

That's it for today, happy hacking!

Comment this post here.

Spotify for Everyone

I personally love Spotify. I can hear music everywhere and even sync some music to my devices, and it works pretty well even in slow connections.

But in lot of countries, including Brazil (where I currently live), Spotify would not let you create an account, due to some copyright bullshit.

Lucky for us, this is one case where proxies are actually useful. To begin, you will need a proxy server in USA, or, you could just open a SSH connection to some server in US and use it as a SOCKS5 proxy.

I used the later and it is working as expected for a month or two now. So, I will guide you through this process.

1. Get some server

First thing, you need a server in US. I recommend DigitalOceal for that. It is really cheap, easy to signup, easy and fast to create and destroy the server.

Create an account and create a server. You can put anything you want in the hostname and leave the rest as it is.

You will receive an email with the password to access your server, and it will be up and running in about 60 seconds.

2. Create a SOCK5 proxy

You will receive from DigitalOcean an email like this:

You can access it using the following credentials:
IP Address: X.X.X.X
Username: root
Password: pwd

To create the proxy, you will need OpenSSH installed. It is default in Linux and Mac OS X boxes, I don't know about Windows, but, given the history, probably not. In that case, you are by yourself to get this working.

Now, back to what really matters: to create the proxy server, run this:

ssh root@X.X.X.X -NCD 8080

Here, X.X.X.X is the IP from the DigitalOcean email. When asked, enter also the password provided in the very same email.

Now you should have a proxy server running!

3. Setup your machine

You will have to setup SOCKS proxy to address to 127.0.0.1 and the port to 8080.

I recommend you to use Mozilla Firefox for that, so you can change the settings for the browser only.

How to setup the proxy in Firefox

Don't forget to check the SOCKSv5 option if asked and to uncheck the "Use this proxy server for all protocols" if it is checked.

Now, point to google and search for the term "my ip". You should see the IP you received by email.

4. Create the account, finally

Now, just point the browser to the Spotify website and register. You will notice that you will not be able to change your country. This is expected. Just proceed and create your account.

Now:

  • Go to the console where you ran that command I said before, and press CTRL+C. This will stop the proxy server;
  • Go to Firefox settings and check the "No Proxy" option.

Now, access your Spotify Payment Method Setup and configure everything. Yes, you will have to pay or they will block you out after some time.

5. Enjoy!

Download the app for your OS or access the web player and enjoy your music!

6. Clean up

If you will not need the server anymore, you can shut it down. To do that, access your droplet in DigitalOcean, click in the destroy tab and follow the instructions.

Thats all folks

Hope you enjoy this not-very-technical post. Cheers!

Comment this post here.

PullRequest Coverage Blammer Maven Plugin

At the company I work Pull Requests are part of our culture. When someone opens a Pull Request, we do Code Review. If we think it's ok, we comment "+1", or "-1" otherwise. We usually only merge a PR when it has 3 or more "+1" comments.

Part of this review is to check for tests. We used to manually look at our code coverage statuses, and see if our recently added lines are with enough coverage. But this is boring, and we are developers, and developers automate things, and so we did.

@velo came with the idea of doing a maven plugin to automatically report bad code coverage in new lines added in pull requests. In the weekend, I sit next to a pack of beers and a considerable amount of coffee and made it work. Well, not the 100% one perfect solution, but we are improving it. And it is OpenSource! You can see a Pull Request example here. All my comments in this PR are actually the plugin working via the Github API :heart:.

coverage

We already have Sonar and Code Formatter Maven Plugins (both written by @velo) that will fail the build in case of code style changes and report code with bugs and other issues, respectively, so, it makes sense to us to add coverage to the party.

We configured those plugins to run within our CI Server, so, everything is automated: we just open a pull request and the CI do the rest.

Now, with test coverage reports automated for new code, we only need to discuss about what really matters: the business.

Comment this post here.