programming

by

OAuth – a brief summary

OAuth is a simple standard for allowing an end user to authorize an application to access a third party service on behalf of said user.

Access is authorized on two levels by the third party as the application needs to be identified as does the the user on behalf of which it is acting.

Application authorization

The application obtains through an out-of-band channel, typically a web form at the third party service where the application developer submits an application for access, the following pair of credentials:

  1. Consumer key (a.k.a. API key, public key, application key). Transmitted to third party as oauth_consumer_key.
  2. Consumer secret (a.k.a API secret, private key, consumer secret key, application secret)

The consumer secret is never directly transmitted to the the third party, as it is used to calculate a signature for requests.

User authorization

The user typically authorizes the application to access the service using a 3-Legged OAuth process whereupon its completion the application obtains an access token consisting of:

  1. Token (a.k.a. access token). Transmitted to third party as oauth_token.
  2. Secret (a.k.a. access token secret, oauth token secret).

The secret is never directly transmitted to the the third party, as it is used to calculate a signature for requests.

Access

OAuth authorized http requests to the third party adds several OAuth specific parameters the most important of which are oauth_consumer_key, oauth_token and oauth_signature. The value of  oauth_signature is a SHA1 calculated hash of the consumer secret, access token secret and all the parameters sent in the request. OAuth parameters can be sent as standard URL parameters or as the value of the Authorization http header.

by

Testing logging behaviour sans Mockito

The most popular post in this somewhat dormant blog is Testing logging behaviour in four code lines flat. The approach described there relies on everyones favourite unit testing mocking swiss army knife – Mockito. To achieve the purpose of unit testing logging Mockito is however not a required drink, some simple Log4j coding goes a long way:

import org.apache.log4j.SimpleLayout;
import org.apache.log4j.WriterAppender;
import static org.hamcrest.CoreMatchers.is;
import org.junit.Test;
import static org.junit.Assert.assertThat;

public class FooTest {

  @Test
  public void testMethod() {

    StringWriter stringWriter = new StringWriter();

    Logger.getRootLogger().addAppender(new WriterAppender(new SimpleLayout(), stringWriter));

    doStuffThatCausesLogging();

    assertThat(stringWriter.toString(), is("WARN - doh\n"));
  }
}

The code is still acceptable and quite compact. However the expressive niceties Mockito provides are lost and making assertions about logging levels, timestamps and multiple logging invocations takes a lof of cruft. Hence I really see few reasons for this approach if Mockito is available.

by

Weighing in on programming language investment options for 2010

In the classic text The Pragmatic Programmer: From Journeyman to Master Andrew Hunt and David Thomas make a very convincing case for practicing software developers to pick up a new programming language each year as a part of a deliberate knowledge investment plan. The software industry can be a pretty fast-moving place sometimes, and keeping on top of (or even ahead of) the latest trends can be a pretty smart thing career-wise, particularly so in a recession. Also, new languages broadens ones horizons, and analogous with picking up new natural languages can further proficiency in ones mother tongue (bread-and-butter programming language).

The language of 2009 was Groovy for me. As a (primarily) Java developer you simply gotta love the groovy! I would like to describe the language as a super charged version of Java that shares most of Java syntax, but requires far less boiler plate code, supports dynamic typing and the closures Sun successfully has been able to keep out of the Java programming language up til now¹. Groovy is extremely interoperable with Java: groovy source code compiles to Java bytecode and calling Java code from Groovy or vice verse is trivial. The Groovy take on the famous Ruby-On-Rails web application framework, Grails, is an impressive invention even if it has its problems.

The Programmatic Programmer argues that one should, just in conventional investing, diversify ones portfolio. For 2010 I’m ready to take on a language that shares far fewer traits with my current personal, as well and most of the industry’s, primary bread-and-butter language Java than Groovy does. Maybe even a  functional programming language. I decided on short listing Scala, Erlang and Clojure.

The short list

Scala appears to enjoy tremendous momentum for the moment. If Groovy is Java on steroids, Scala is Java 2.0. Founder of the Groovy programming language James Strachan has openly stated that if Scala had been around in 2003, Groovy would probably never has seen the light of day. Scala supports a mixed imperative/functional programming model and is a statically typed language with an advanced type system. Scala compiles to JVM bytecode and is Java interoperable on the same level as Groovy. Unfortunately Scala appears be be a quite complex language – the “authoritative tutorial” on the language, Programming in Scala by language founder Martin Odersky, contains more than 750 pages.

Erlang is a  functional language with its origin within the telecommunication industry. Erlang has a strong focus on efficient concurrent execution and fault tolerance. Erlang is of Swedish origin, fully functional and has a syntax very different compared to C syntax language. On the down side, Java interoperability is very weak as Erlang compiles to a none-JVM bytecode. Also, Erlang momentum appears to currently be rather diminutive.

Clojure is a LISP and thus both homoiconic and very functional in nature. The syntax is completely dissimilar to C languages, being much smaller and relying on liberal usage of lots and lots of nice parentheses. Clojure is fully JVM-interoperable and appears to have some traction within the developer community, perhaps not on the level of Scala but there’s definitely some momentum out there.

What investment option did you go with for this year?

¹) Late 2009, Sun finally – obviously much overdue – announced that we can expect closures to be included in Java 1.7 after all.