Tuesday, 26 March 2013

Simple SSH/OpenVPN advice

One cannot do research effectively, if he is not aware of shortcuts in his day-to-day interactions with the university's infrastructure. These little stuff may seem not top-priority at first, but after taking some time to setup your environment, they will prove useful, if you will do work/projects from home, if you try to access the intranet to use your institution's IP for accessing academic material, or if you just want to use your institution's VPN network.

This is a super quick tutorial for Ubuntu. Not a PL memo, but still... :)

1. Every university provides vpn access. Mine provides access via an openvpn server and a default configuration file is provided (alongside with the needed ca cert). Instead of using a manual openvpn command, with screen or else, or pollute .profile etc, you can use the graphical network-manager-openvpn and import the provided ovpn file.

 sudo apt-get -y install network-manager-openvpn 

2. Import all the settings/hosts that you frequently type in an ssh_config file and place it in .ssh/config. In there, you can enter a whole bunch of settings, like more strict checking of known hosts, compression, forwarding, alive interval, or what identity files you will use for each connection (e.g., your git server), etc. Mine is the following:

Host linux*  
      User <yourname>  
Host linux01 linux02 linux03 linux04 linux05 linux06 linux07 linux08 linux09 linux10 linux11 linux12 linux13 linux14 linux15 linux16 linux17 linux18 linux19 linux20 linux21 linux22 linux23 linux24 linux26 linux27 linux28 linux29   
      HostName %h.<university's hostname>  

3. Use private / public key for ssh connections. You will need an ssh-agent installed. ssh-agent is a program that starts alongside with an X-session or a login session and loads your private keys in memory.

 ssh-keygen -t rsa  
 chmod 700 ~/.ssh  

Now check the .ssh directory for two files, one is the private key and the other one is the .pub key. What you want to do now (I assume you know the basics of public key cryptography :-D), is to load the private in memory and save the public key somehow to your remote host in order to be able to connect without password, but with an automatic public/private rsa key pair handshake, instead.

If you haven't saved the file in the default location (check if it is loaded with ssh-add -l) then you should communicate it to the ssh-agent with the command below (maybe also append it to the .profile too for your future reboots).

 ssh-add ~/.ssh/whereyousavedtheprivate &>/dev/null  

 ssh-copy-id -i remote-server 

Your .ssh/authorized_keys at the remote profile, also needs secure permissions.

That's it.

Tuesday, 8 January 2013

The original notion of traits

In [1] Schärli et al. provide a simple and understandable point of view: "It should be possible to view the class either as a flat collection of methods or as a composite entity built from traits. The flattened view promotes understanding; the hierarchic view promotes reuse." The authors establish the (original) definition of traits with the list of points below.

  1. A trait provides a set of methods that implement behavior.
  2. A trait requires a set of methods that parameterize the provided behavior.
  3. Traits do not specify any state variables, and the methods provided by traits never directly access state variables.
  4. Traits can be composed: trait composition is symmetric and conflicting methods are excluded from the composition.
  5. Traits can be nested, but the nesting has no semantics for classes—nested traits are equivalent to flattened traits.

First of all, we can view trait composition as a way to complement single inheritance. Each trait is an independent collection of methods, that implements a certain behavior. These methods can depend on other methods / objects (following the general principle of reusability), thus traits can be parametric, by declaring what they require.  Let's view a class with traits. What is class? Class = State + Traits + Glue as the authors say. This means that a class can declare its state variables, can be extended with traits and these traits on the one hand can operate on class' variables via getters / setters and on the other can also call methods from other traits. Traits' composition is not an (total) ordered relation, thus order is irrelevant. The only thing that matters structurally, is that traits as a set, may or may not have conflicting features (methods). If traits had state then the diamond problem could arise very easily, something that is avoided with traits. Conflicting features can arise when various traits define two or more features with the same signature. Then the resolution must be made explicitly and the authors introduce the notions of aliases and exclusion. If conflicting methods arise between class (this class or a superclass) and some trait,  class methods take precedence over trait methods and trait methods take precedence over superclass methods. What is of great importance is that if you take a method in a trait, and the same method in a class is composed with the same trait, then the method has the same semantics (flattening property).

The authors present a use case of traits by refactoring the Smalltalk-80 collection hierarchy. They argue that collections have various characteristics; namely explicit ordering, implicit ordering, unordered, extensible, immutable, keyed etc. By single inheritance a programmer can provide a solution with code duplication or just by lifting everything up to the hierarchy and then throwing unsupported exceptions (effectively disabling the methods that are not needed). The collection was refactored to use 20 traits each one providing different behaviors and depending on others.
  1. Schärli, Nathanael, et al. "Traits: Composable units of behaviour." ECOOP 2003–Object-Oriented Programming (2003): 327-339.

Sunday, 16 December 2012

Attending SIGPLAN PLMW and POPL 2013!

What a great way of planning to start 2013. Today I received an email informing me of receiving the scholarship award, for attending the 2nd SIGPLAN Programming Languages Mentoring Workshop and the 40th Symposium on Principles of Programming Languages (PLMW+POPL) in Rome, the following January. An interesting activity that is going to take place is the One Minute Madness. Simple as it may seem at first, it is really challenging to describe what you study and where your research is going to, in a 60-second time-frame. I may accept the challenge too. :)

I am looking forward to hearing from successful pl-theorists their advice, meeting other students and attending the most prestigious conference of my field. See you there!


Friday, 27 July 2012

Weaving aspects with AspectJ in Maven

First of all welcome at my PL memos, blog. I haven't been blogging for a while and this blog is a simplistic way, to note down something that matters/mattered to me.

Today I tried to build an open source project (and while not important, the project is an SOS service deployed into tomcat), with the AspectJ maven plugin, in order to weave some aspects. I needed to hook certain functionality into an open source project while avoiding cut-pasting code upon each svn update of any upcoming new revision (not even resolving conflicts via the svn tooling). I wanted a clean solution, developed and maintained independently. However there were some minor difficulties through the process, specially for developers without strong know how with the maven build tool, like me.

The SOS service, came as a single maven aggregation project with various modules. I couldn't declare the aspectj compiler plugin there. If you do that you are going to get a "Not executing aspectJ compiler as the project is not a Java classpath-capable package" warning. My attempts to find adequate information around the web, resulted in solutions referring to the version number of source/target. While looking in mailing lists, every reference of this error (like this so), was paired with a "bad version number found in ..." warning. Unfortunately I was getting only the "Not executing aspectJ compiler.." warning, so I couldn't find what was going on, until I checked the if-expression from within the aspectj plugin. This helped me to understand that this had something to do with an entity called ArtifactHandler. Only then I found out the solution. Define the aspect j plugin only to children poms. The next step, after a lot of experimentation concluded in adding the following section at the pom.xml that interested me:


Now you must only see --- aspectj-maven-plugin:1.4:compile (default) @ <project name> --- followed by no warnings or errors. The next step is to drag and drop already developed aspects and place them at the default directory for the aspectj plugin to look into: src/main/aspect. For my proof of concept I coded a simple join point to intercept a specific call (not important but it is a certain listener).

What you expect to see at this point under the --- ... --- message is an info log entry like that:
[INFO] --- aspectj-maven-plugin:1.4:compile (default) @ 52n-sos-core ---
[INFO] Join point 'method-execution(org.n52.sos.resp.ISosResponse org.n52.sos.InsertObservationListener.receiveRequest(org.n52.sos.request.AbstractSosRequest))' in Type 'org.n52.sos.InsertObservationListener' (InsertObservationListener.java:103) advised by around advice from 'InterceptInsertCalls' (InterceptInsertCalls.aj:8) [with runtime test]
Any error messages, any unmatched advices are going to be reported in the maven build output. Finally, assuming that you target a web-app, a war file is packaged and ready to be deployed. This simple case enabled me to weave sample code that appends an incremented string in the log file tomcat7-stdout.2012-07-26.log, when someone posted observations messages to the service.
What we achieved? We patched an open source project, avoiding to mess with the code and isolated the additional functionality into an independent development life-cycle.