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.

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.

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();
    @DefaultValue("42")
    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:

port=80
hostname=foobar.com
maxThreads=100
logFile=/var/log/myapp.log

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
admin.user=admin 

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();
          user.setUsername(username);
          return user;
      }
  }
  

• You can define and register a PropertyEditor

  public interface MyAppConfig extends Config {
      @DefaultValue("admin")
      User user();
  }
  
  public class UserPropertyEditor extends PropertyEditorSupport {
      @Override
      public void setAsText(String text) throws IllegalArgumentException {
          User user = new User();
          user.setUsername(text);
          setValue(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”).

public interface MyAppConfig extends Config {
    @DefaultValue("admin,root")
    List<User> users(); // collections of user's domain classes
    @DefaultValue("8080,8090")
    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());
}

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:

@LoadPolicy(LoadType.MERGE)
@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 {
    @Key("HOME")
    String home();

    @Key("USER")
    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 {
    @Key("file.separator")
    String fileSeparator();

    @Key("java.home")
    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 {
    @Key("file.separator")
    String fileSeparator();

    @Key("java.home")
    String javaHome();

    @Key("HOME")
    String home();

    @Key("USER")
    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.

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!"
    System.out.println(sample.helloMr("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.

Conclusions

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?”

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:

server.host=myhost.com
service.url=http://${server.host}/some/endpoint
application.path=${HOME}/myapp
application.data=${application.path}/data
application.logs=${application.path}/logs

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 {
    @Key("server.host")
    String host();

    @Key("service.url")
    URL serviceURL();

    @Key("application.data")
    File appData();

    @Key("application.logs")
    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.

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 {

    @DefaultValue("foobar.com")
    @Key("server.name");
    String serverName();

    @DefaultValue("80");
    @Key("server.port");
    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.

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.

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
fi

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:

/opt/local/share/git-core/contrib/completion/git-completion.bash
/opt/local//share/git-core/contrib/completion/git-prompt.sh

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

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]:

Notes:

1. Beer not included.

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.