Yosemite network problems

I’ve successfully updated two macbooks to Yosemite, and I’m quite happy so far.

The only problem I got, is that one of the two (an old late 2008 macbook) stopped seeing other devices on the network. Even from the Airport utility, it continues to look around without seeing the Time Machine connected to the network.

So I found this article: Fix Wi-Fi Problems in OS X Yosemite

luigi@hal9000:~$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
luigi@hal9000:~$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist

Now everything works fine.

Ignoring versioned files with GIT

Suppose you work in a team. You download the project sources and you need to change some configurations according to your working environment, like the tcp port on which to run the webserver or the path where to store the log files. If you commit those files, after your local set up, this would impact the other members of your team when they update.
You cannot simply add them to .gitignore since those files need to be versioned. But you want just to avoid committing your local configuration to your repository.
So here we have a problem…

As far as I know, GIT is the only scm able to handle the issue. This is done by running the command:

$ git update-index --assume-unchanged path/to/file.txt

Once marking a file as such, git will completely ignore any changes on that file; they will not show up when running git status or git diff, nor will they ever be committed.

To make git track the file again, simply run

$ git update-index --no-assume-unchanged path/to/file.txt

Credits to GitHub Help pages for this awesome trick.

To cancel the effect of the --assume-unchanged run

$ git update-index --really-refresh

which does a real refresh ignoring the --assume-unchanged entries.

For the ones who don’t know what OWNER library is, you can read my previous article here: Introducing OWNER, a tiny framework for Java Properties files.

It has been a long time since I posted the Part 1 of this article, and version 1.0.3 was just released. Now I should probably write about version 1.0.4 which is going to have some neat new features, and it will be released soon; but first I need to complete the overview of 1.0.3, and I will also mention new stuff coming in 1.0.4.

In February I wrote about variable expansion. Here I want to briefly introduce some other things that can be useful:

  • Advanced type conversion
  • LoadPolicies to load your property files using different strategies
  • Wrapping your java.util.Properties instances (and java.util.Maps too…)
  • Passing parameters to properties (and the wonder of @DefaultValue)

Advanced type conversion

In last post I showed that user can specify some basic Java types as return type for your Properties Mapping Interface, so this is what I am talking about:

public interface ServerConfig extends Config {
    Integer port();
    String hostname();
    int maxThreads();
    File logFile();

// then you can do
public static void main(String[] args) {
    ServerConfig cfg = ConfigFactory.create(ServerConfig.class);
    System.out.println("Server " + cfg.hostname() + ":" + cfg.port() + " will run " + cfg.maxThreads());

So if you have a file called ServerConfig.properties in the same package of the above class looking like the following one:


The OWNER library will map the interface methods to the properties associated, making all the work to convert the String value to int, Integer, java.util.String or any other java primitive type, enums, wrapper classes. Plus some additional Java types are supported, like java.io.File, java.net.URL, java.net.URI, java.lang.Class etc. This is fully customizable, and fully documented here. But this is not new.

The new thing in version 1.0.3, is that you can map your property values to your own business objects. So, for instance, if you have class com.acme.wonderfulapp.User, you could define a properties mapping interface like this:

public interface MyAppConfig { 
    //... other properties
    @Key("admin.user") // this associates the key for the property
    User adminUser();

The associated file MyAppConfig.properties should define the above properties like:

# MyAppConfig.properties

To allow the OWNER library to convert the property admin.user=admin to a com.acme.wonderfulapp.User there are many options:

  • You can declare a public Constructor taking java.lang.String or java.lang.Object:
    public class User {
        public User(String username) {
            this.username = username;
        // or 
        public User(Object username) {
            this.username = username;
  • You can declare a public static method valueOf(String):
    public class User {
        public static User valueOf(String username) {
            User user = new User();
            return user;
  • You can define and register a PropertyEditor
    public interface MyAppConfig extends Config {
        User user();
    public class UserPropertyEditor extends PropertyEditorSupport {
        public void setAsText(String text) throws IllegalArgumentException {
            User user = new User();
    public static void main(String[] args) {
        // register the propertyEditor (consult PropertyEditorManager javadocs)
        PropertyEditorManager.registerEditor(User.class, UserPropertyEditor.class);
        MyAppConfig cfg = ConfigFactory.create(MyAppConfig.class);
        System.out.println("admin username is: " + cfg.user().getUsername());

    PropertyEditorManager resolves the editor using some naming convention, so if I rename the class UserPropertyEditor into UserEditor then there is no need to invoke the method PropertyEditorManager.registerEditor(): PropertyEditorManager tries to resolve an editor appending '-Editor' to your class name. The editor resolution is a little bit more complex than that; please consult PropertyEditorManager javadoc.

In the above examples I just showed simple cases, but having the ability specify the logic to convert a java property value into a domain object can be quite handy and powerful I think.
The full list of supported automatic conversion is available on the documentation website (see paragraph “Type Conversion”).


With version 1.0.4 the OWNER library also supports arrays and Collections of all the already supported types. This topic will be covered in the next post, when version 1.0.4 will be officially released. So you could do:

public interface MyAppConfig extends Config {
    List<User> users(); // collections of user's domain classes
    int[] ports(); // also arrays and primitive are supported!

public static void main(String[] args) {
    PropertyEditorManager.registerEditor(User.class, UserPropertyEditor.class);

    MyAppConfig cfg = ConfigFactory.create(MyAppConfig.class);
    List<User> users = cfg.users();
    assertEquals("admin", users.get(0).getUsername());
    assertEquals("root", users.get(1).getUsername());

Thanks goes to Dmytro Chyzhykov for the awesome code he contributed.

But… I’ll tell you more after the 1.0.4 release.

LoadPolicies to load your property files using different strategies

By default you don’t specify any source, OWNER API tries to load the properties from a file called like your class: if my class is called com.acme.MyAppConfig, then by default OWNER will try to load com.acme.MyAppConfig.properties from the classpath.

Of course this is not enough, and since the first release, OWNER is able to load your property files in a flexible way. You can specify the annotation @Source with several locations, in form of URLs, from where the properties must be loaded.

@Sources({ "file:~/.myapp.config", "file:/etc/myapp.config", "classpath:foo/bar/baz.properties" })
public interface ServerConfig extends Config {
    public String myProperty();

This means that OWNER will fist try to load the file “.myapp.config” located in my home directory (the ‘~’ is resolved as the user home), then if that file does not exists the file “/etc/myapp.conf” will be loaded, and as last resort the file “foo/bar/baz.properties” will be loaded from the class path. And, as if this was not enough, you can also specify a default value for every property with the annotation @DefaultValue.
All this is nice, but NOT NEW, since version 1.0.3 adds even more.

In fact, with version 1.0.3 you have two different “load policies”. The default one, is the one exposed above. And we call this behavior LoadType.FIRST, since the first available resource specified by the @Source annotation is loaded and the remaining are ignored.
The new additional load policy is called LoadType.MERGE, and here is an example:

@Sources({ "file:~/.myapp.config", "file:/etc/myapp.config", "classpath:foo/bar/baz.properties" })
public interface ServerConfig extends Config {
    public String myProperty();

This means that, when I call the method ServerConfig.myProperty() ALL the sources will be considered in order. If myProperty is specified in “file:/etc/myapp.config” will be loaded from there, unless it is redefined in “file:~/.myapp.config”. So basically we have a kind of “fallback” mechanism which allows the user to have a main configuration with lower priority (i.e. system level) and overriding configurations with higher priorities (i.e. user level).

Wrapping your java.util.Properties instances (and java.util.Maps too…)

If you have existing instances of Properties (or Maps), for example you have a legacy application that loads the property in some particular way, or just instantiates those properties programmatically, you can “wrap” those instances with OWNER.
I called this mechanism “importing properties” since it is an *addition* to loading the properties from external resources, and you can use this feature in combination of it.
For instance you can wrap System.getProperties() or System.getenv() doing something like this:

// wrapping System.getenv() 

interface EnvProperties extends Config {
    String home();

    String user();

public static void main(String[] args) {
    SystemEnvProperties cfg = ConfigFactory.create(SystemEnvProperties.class, System.getenv());
    assertEquals(System.getenv().get("HOME"), cfg.home());
    assertEquals(System.getenv().get("USER"), cfg.user());

// wrapping System.getProperties()

interface SystemEnvProperties extends Config {
    String fileSeparator();

    String javaHome();

public static void main(String[] args) {
    SystemEnvProperties cfg = ConfigFactory.create(SystemEnvProperties.class, System.getProperties());
    assertEquals(File.separator, cfg.fileSeparator());
    assertEquals(System.getProperty("java.home"), cfg.javaHome());

// you can also wrap them together in a single interface:

interface SystemEnvProperties extends Config {
    String fileSeparator();

    String javaHome();

    String home();

    String user();

public static void main(String[] args) {
    SystemEnvProperties cfg = ConfigFactory.create(SystemEnvProperties.class, System.getProperties(), System.getenv());
    assertEquals(File.separator, cfg.fileSeparator());
    assertEquals(System.getProperty("java.home"), cfg.javaHome());
    assertEquals(System.getenv().get("HOME"), cfg.home());
    assertEquals(System.getenv().get("USER"), cfg.user());

In the same way, you can wrap any instance of Properties – and any subclass of java.util.Map – you already have in your project, in a convenient JavaBean-like interface (if you like JavaBeans), with the advantage of having the type conversion for free.


Notice that the wrapped object becomes unmodifiable (since it is internally copied), so if you modify the original objects, the change will not be reflected. The objects instantiated by OWNER, should be considered immutable (well, I am planning to implement the “hot reloading” soon, maybe already in 1.0.4, and being thread safe is a requirement).

Passing parameters to properties (and the wonder of @DefaultValue)

This feature is not really new and is more related to internationalization than on configuration. In any case, in Java interface method can accept parameters and I thought it may be useful to parametrize a property value. And it was easy and elegant to implement, so I did it.

interface Sample extends Config {
    @DefaultValue("Hello Mr. %s!")
    String helloMr(String name);
public static void main(String[] args) {
    Sample sample = ConfigFactory.create(Sample.class);
    // this will print "Hello Mr. Luigi!"

This is not new in 1.0.3 but I feel like this is an unknown feature, and… in the above example I also show the usage of the @DefaultValue annotation. Sometime you just want to define some default values for your configuration, plus specifying a source from where to load the overriding values defined by the user. This is one of the things I like more about this library: it saves me to write properties file until they are really needed. Or if you want, you can write an example, put it on the classpath and let the user to override it placing the property in a conventional location.
The parameters, are just a plus and an excuse to talk again about @DefaultValue.


Some people don’t need this parameter formatting feature, or the variable expansion that has been introduced in the previous episode. For example, your application may already implement variable expansion in a very similar way, and having an unwanted feature may lead to conflict with legacy features if you are trying to introduce OWNER in your project. For this reason, version 1.0.4 will have an annotation @DisableFeature which will allow the user to disable the variable expansion or the parameter formatting on class level and/or on method level.


This is just a quick tour on the new things regarding the OWNER library. In 1.0.3 there were also some minor bugfixes and some code cleanup.
What we are trying to do with OWNER library, is to add beautiful features while keeping the code compact, elegant, documented and thoroughly tested. So far so good, I suppose. And more things are bubbling in the pan*.

*: “what’s bubbling in the pan?” is the italian literal translation of “Cosa bolle in pentola?”, which corresponds to “What’s cooking?”

In the last blog post I introduced what is the OWNER API and how to use it.
Basically it is tiny library that helps reducing the Java code to read the configuration for your application from Java Properties files. You can find full documentation here. Version 1.0.0 was having the very basic features, and now I’m adding new things that may return useful without compromising its simplicity and compactness.

Yesterday I have released version 1.0.3 which includes some new features that I want to introduce in some short blog posts.
On this weekend I set up the continuous integration on CloudBees and I noticed that compiling with JDK 6 there was a compilation error, since I was using JDK 7, so I decided that the fix was worthing another release, so that if somebody is using JDK 6 won’t have any problem.

So, what’s new then?

First of all, the OWNER library is now available on Maven Central Repository, and this will ease the job of people willing to try it, since now it only requires few lines to configure your project to use it, and I tried to improve the documentation. Unfortunately, publishing the library on Maven Central Repository required me to buy an internet domain name and use it for the groupId of the library. This may have broken the backward compatibility if someone started to use this library. I apologize for that.

The first thing I want to point out, is something I always missed in Java Properties files. A “variable expansion” mechanism.
For example, imagine your application having a configuration file like this:


With plain Java properties file, the job to replace the variables is left to you. With Owner API, you can create a Java interface to map the above configuration and have all the variables resolved:

public interface MyAppConfig extends Config {
    String host();

    URL serviceURL();

    File appData();

    File appLogs();

// then use it with:
MyAppConfig cfg = ConfigFactory.create(MyAppConfig.class, System.getenv());

The System.getenv() is used to resolve the ${HOME} system environment variable. In the same way you can pass other properties files too, like System properties or any other class implementing java.util.Map, see ConfigFactory.create(). I called this technique “importing properties”, since you specify some Properties or Maps during the creation of the Config object.

More details can be found on the README file on github: variables expansion and importing properties.

I’ll write more about what’s new in the next blog post.

I never liked to create “wrapper” classes for properties files. Do you know… those classes like:

public class MyAppConfig {
    private static Properties p = ...;

    public static String serverName() {
        return p.getProperty("server.name");

    public static int serverPort() {
        return Integer.parseInt(p.getProperty("server.port"));


There’s nothing really bad about those classes. Only that they don’t do actually anything useful; plus, you need to keep things in sync with the properties file associated.

So, I always preferred to directly use Properties.getProperty() and pass a config properties to objects:

public class MyBusinessClass {
    private final Properties conf;
    public MyBusinessClass(..., Properties conf) {
        this.conf = conf;

    public void doSomething() {
        String serverName = conf.getProperty("server.name");
        int serverPort = Integer.parseInt(conf.getProperty("server.port"));

99% of the times, you need a configuration setting in a single point. So that’s good enough, and I don’t have to write (and keep in sync) a class that I can spare.

But… what about this?

public interface MyAppConfig extends Config {

    String serverName();

    int serverPort();

Add to this, a smart -annotation based- configuration loading:

@Sources({"file:~/.myapp.config", "file:/etc/myapp.config", "classpath:foo/bar/baz.properties"})
public interface MyAppConfig extends Config {

And a simple instantiation:

    MyAppConfig conf = ConfigFactory.create(MyAppConfig.class);

And you have OWNER. A little configuration framework based on Java properties.

BSD license.
Credits to Google GWT, that does similar things with i18n.

Ssh “Write failed: Broken pipe”

I started to get this error “Write failed: Broken pipe” when I was leaving the terminal alone.
Since plumbers are still expensive, despite the crisis, I decided to fix the pipe by myself.
Very easy, just add the following line to /etc/ssh/sshd_config:

ClientAliveInterval 60

This will send a “keep-alive” packet from the server to the terminal client every 60 seconds so that the connection doesn’t get dropped.

If you can’t fix it on the server, for example if you don’t have administrative rights, you can fix your client to send the “keep-alive” packet to the server every 60 seconds, adding this line to ~/.ssh/config

ServerAliveInterval 60

It’s also possible to specify the ServerAliveInterval at the ssh command line:

$ ssh -o ServerAliveInterval=60 user@sshserver

More info about ClientAliveInterval and ServerAliveInterval can be found typing at the command line:

$ man 5 sshd_config
$ man 5 ssh_config
$ man ssh

Another reference here.

Your pipes should be safe now, and the plumbers out of business.

-bash: __git_ps1: command not found

Today I updated mac ports and a new error started to show up at the command line saying that the __git_ps1 command is not found.
This is because I added the git branch in my bash prompt long time back and in last update of git-core port they moved the __git_ps1 bash functions to a separate script.

To fix it, you just need to include following lines in your .profile (or .bashrc):

if [ -f /opt/local/share/doc/git-core/contrib/completion/git-prompt.sh ]; then
    . /opt/local/share/doc/git-core/contrib/completion/git-prompt.sh

It worked for me.

Depending on your git installation, this file may be located elsewhere; find command should help in this case.

Update 30-03-2013:

They changed the location of those files again. Super!

now they are here:


just include them.
Hope they won’t change the paths again soon :)

It’s a couple of days I’m experiencing my macbook pro being more unstable (than usual). This morning I noticed that the cpu temperature was around 80˚C (using iStat Menus) and I notice that the process coreserviced was taking 80% CPU, and after that there was pentabletdriver with another 20%. I thought that it was a funny coincidence that this started to happen right after the release of Mountain Lion, so I thought that this may be the chance to upgrade, even though I can’t find a single feature in Mountain Lion that I really need.
First, I tried the oldest and most effective strategy to solve computer problems, the reboot, but it didn’t help.
So, I googled around and I found many people complaining the same behavior, but nothing to solve the problem in my case.
At the end I did this: from spotlight I opened the Activity Monitor and I forced-quit the coreserviced and the pentabletdriver, and immediately the cpu returned idle, but after that the menu bar disappeared so I thought it would be a good idea to shutdown the laptop and reboot (CTRL+Eject button). After the reboot, things went fine, but I had already purchased Mountain Lion, so… good for you Apple, you got my 15 euros.

I purchased an awesome 24″ LCD Monitor by Asus, I didn’t spend much (except for the Apple Mini DisplayPort to HDMI cable). The problem with OS X, is that once you have such a wonderful display you want to use it fully, and the Apple operating system works against you. In fact, by default the monitor enters as “secondary monitor” so you need to drag applications into it, and you don’t have the dock and the menubar there. This would be fine, if only the way to switch the primary monitor was easy to find.
I wanted to use the big monitor as primary monitor, and I couldn’t find how. I looked around on internet without any luck. I purchased an application, Multimon, from the App Store, but it wasn’t much of an help; $10 wasted.

At the end I found how to use the external monitor as Primary Display. Here it is how:

  1. Open ‘System Preferences’. I do that from spotlight (cmd+space then type ‘system preferences’)
  2. Choose Displays, and select the Tab ‘Arrangement’, you’ll see something like this:

  3. You see that the menu bar is set on the little display (the one of the MacBook). The menu bar also identifies the ‘Primary Display’, which also gets the Dock. All you need to do, to switch the primary display is to drag the menu bar on the other display. It is also written in the dialog, but who see that? After dragging the menu bar, the representation becomes like this:

    Now the primary monitor is the external one.

When the external monitor gets disconnected, the MacBook display returns to be the primary one. If you have much stuff on the desktop, it gets a little bit messed up, but you can rearrange that automatically, right-clicking on the desktop and doing a Clean-Up By Kind or by Name.

Notice that if you have a MacBook earlier than 2010, like me, the Mini DisplayPort doesn’t transport the audio signal, which has been added only later; so your external display will be mute.

Last advice: once you have a big external monitor, you’ll probably want to buy a Apple Wireless Keyboard and the Magic Trackpad. Both strongly recommended. (For the Apple guys: for this recommendation you owe me some gift!)

This would be the final result [1]:


  1. Beer not included.

I always found Dashboard pretty useless, and I just notice it exists when by mistake I press some key which switches the desktop to it. So, here is how to get rid of it; I write this post mainly for future memory for myself.

From this article:

$ defaults write com.apple.dashboard mcx-disabled -boolean YES
$ killall Dock

to re-enable it:

$ defaults write com.apple.dashboard mcx-disabled -boolean NO

Less is more.


Luigi Viggiano

"Thoughts about technology, code, life and diverse and occasionally related matters"
A blog by Luigi R. Viggiano

Follow me

twitter flickr LinkedIn feed

Subscribe by email

Enter your email address:



Tag Cloud