Manuel Paccagnella

Validations with TotallyLazy

2015-07-22T00:00:00+00:00

TotallyLazy is a library that gives you some tools to do functional programming on the JVM and particularly in Java, like: Option/Maybe, Either, persistent data structures, Sequence operations, etc. Unfortunately, even if quite useful and nice to use this library is also practically undocumented (and no, I don't consider raw code as sufficient documentation).

Since I've been using this library for some time now, in my pet projects and also using it in production, I'd like to share a thing or two that I've learned along the way. In particular, I'd like to show you how to do validations using the primitives offered by TotallyLazy.

What does it means to validate?

TotallyLazy model a validation like a function on some data type that can either:

Be successful.
Be a failure with a list of error messages.

More precisely, Validator is a Predicate<T> with an additional method ValidationResult validate(T instance). A ValidationResult is a type which can be successful or failed, and in the latter case can contain a list of error messages (as Strings).

In Haskell we'd have something like this:

data ValidationResult = Successful | Failed [String]
validate :: a -> ValidationResult

Ok, how do I do that?

In this case, an example can be much more informative that a lot of words. Let's take for example the validation of an email.

An Email in this example is a classic POJO, that I express here as an Haskell record because it's much more concise and the point is not the structure of this class. The only peculiarity of this class is that every field is optional.

data Email = Email {fromAddress :: Maybe String,
                    toAddress :: Maybe String,
                    subject :: Maybe String,
                    body :: Maybe String,
                    host :: Maybe String}

First of all, we want to write a Validator for checking to validate that an optional String field must contain a value:

/**
 * Builds a {@link Validator} that checks that a given {@link Option} contains
 * a value.
 *
 * @param name Name of the datum
 * @return {@link Validator}
 */
private Validator<Option<?>> notEmpty(final String name) {
  return new Validator<Option<?>>() {
    @Override
    public ValidationResult validate(Option<?> x) {
      return matches(x)
          ? ValidationResult.constructors.pass()
          : ValidationResult.constructors.failure("Parameter " + name
              + " missing");
    }

    @Override
    public boolean matches(Option<?> x) {
      return x.isDefined();
    }
  };
}

We've defined a creation method that builds and returns a Validator<Option<?>> that validates an optional value by checking if it actually contains a value. Note that since Validator is also a Predicate, we define the corresponding #matches() method and use that in our #validate().

Next, we need to define an ad-hoc validation for the host: it's optional (in fact ignored) if the system is configured to use a mock mailer. Let's assume that we a method that says if it's configured the mock mailer or not, and write this validation:

/**
 * Builds a validator that checks that the host is present (unless the SMTP
 * server is a mock).
 *
 * @return {@link Validator}
 */
private Validator<Option<String>> validHost() {
  return new Validator<Option<String>>() {
    @Override
    public ValidationResult validate(Option<String> host) {
      return matches(host)
          ? ValidationResult.constructors.pass()
          : ValidationResult.constructors.failure("Host is missing");
    }

    @Override
    public boolean matches(Option<String> host) {
      return host.isDefined() || mailServerIsAMock();
    }
  };
}

Finally, we can use this Validators to "declaratively" validate an entire Email value as follows:

public ValidationResult validateEmailParameters(Email email) {
  return sequence(notEmpty("from").validate(email.getFromAddress()),
                  notEmpty("to").validate(email.getToAddress()),
                  notEmpty("subject").validate(email.getSubject()),
                  notEmpty("body").validate(email.getBody()),
                  validHost().validate(email.getHost()))
         .reduce(ValidationResult.functions.merge());
}

Note that #notEmpty() is defined in very general terms and can be reused in many more circumstances.

And now?

This is just a quick overview on the validation primitives offered by TotallyLazy. A good next step would be looking at all the fine combinators for Validators.

Roy Fielding on Versioning, Hypermedia, and REST

2014-12-19T00:00:00+00:00

Some highlights from this interview to Roy Fielding on InfoQ:

"hypermedia as the engine of application state" is a REST constraint. Not an option. Not an ideal. Hypermedia is a constraint. As in, you either do it or you aren’t doing REST. You can’t have evolvability if clients have their controls baked into their design at deployment. Controls have to be learned on the fly. That’s what hypermedia enables.

The techniques that developers learn from managing in-house software, where they might reasonably believe they have control over deployment of both clients and servers, simply don’t apply to network-based software intended to cross organizational boundaries. This is precisely the problem that REST is trying to solve: how to evolve a system gracefully without the need to break or replace already deployed components.

don’t build an API to be RESTful — build it to have the properties you want. REST is useful because it induces certain properties that are known to benefit multi-org systems, like evolvability. Evolvability means that the system doesn’t have to be restarted or redeployed in order to adapt to change.

there is no need to anticipate such world-breaking changes with a version ID. We have the hostname for that. What you are creating is not a new version of the API, but a new system with a new brand.

Websites don’t come with version numbers attached because they never need to. Neither should a RESTful API. A RESTful API (done right) is just a website for clients with a limited vocabulary.

I had to define a system that could withstand decades of change produced by people spread all over the world. How many software systems built in 1994 still work today? I meant it literally: decades of use while the system continued to evolve, in independent and orthogonal directions, without ever needing to be shut down or redeployed. Two decades, so far.

the initial reaction to using REST for machine-to-machine interaction is almost always of the form "we don’t see a reason to bother with hypermedia — it just slows down the interactions, as opposed to the client knowing directly what to send." The rationale behind decoupling for evolvability is simply not apparent to developers who think they are working towards a modest goal, like "works next week" or "we’ll fix it in the next release".

What we learned from HTTP and HTML was the need to define how the protocol/language can be expected to change over time, and what recipients ought to do when they receive a change they do not yet understand. HTTP was able to improve over time because we required new syntax to be ignorable and semantics to be changed only when accompanied by a version that indicates such understanding.

Software developers have always struggled with temporal thinking.

Imparare la programmazione funzionale

2014-11-17T00:00:00+00:00

(Un amico mi ha chiesto un consiglio su dove iniziare per imparare la programmazione funzionale, ri-pubblico qua la mia risposta leggermente adattata.)

FP in breve

Prima di tutto una breve parentesi riguardo la programmazione funzionale (FP) in generale. Non c'è una definizione universalmente accettata di FP, ma i tratti generali sono abbastanza comuni:

Le funzioni sono cittadini di prima classe, manipolabili come valori. E' possibile ovvero passarle come parametri e ritornarle tramite altre funzioni (per esempio, vedi Javascript).
Tipicamente le funzioni sono pure, ovvero non ci sono effetti collaterali. In altre parole, il valore ritornato da una funzione dipende solo ed esclusivamente dal valore dei suoi parametri, in modo tale che per uno stesso insieme di valori in ingresso alla funzione, questa ritornerà sempre lo stesso risultato.
In molti casi, si lavora principalmente con strutture dati immutabili. Questo significa che, per esempio, modificare una lista significa crearne una nuova (in modo effiente in termini di spazio e tempo ovviamente, utilizzando delle persistent data structures).

Queste caratteristiche hanno tutta una serie di grandi vantaggi in termini di (per esempio):

Modularizzazione
Composizione
Riuso
Flessibilità
Potenza espressiva
Capacità di astrazione
Manutenibilità
Possibilità di sfruttare facilmente concorrenza e parallelismo

Il tutto ha una solida base teorica nel lambda calculus, un modello computazionale equivalente in termini di possibilità ma diverso da quello di Von Neumann.

Il modello di Von Neumann prevede una memoria condivisa e delle procedure che la alterano. Questo crea essenzialmente un accoppiamento temporale e spaziale tra diverse unità funzionali che, anche se gestito tramite oggetti, rimane una caratteristica intrinseca di questa architettura. Il che rende praticamente impossibile sfruttare facilmente il parallelismo offerto dalle odierne CPU multi-core.

In contrasto, il modello computazionale basato sul lambda calcolo si basa su trasformazioni di strutture dati immutabili da parte di funzioni pure. Il che come dicevo ha tutta una serie di vantaggi, non ultima la possibilità da parte del compilatore/interprete di sfruttare in molti casi automaticamente ed in modo trasparente il parallelismo.

Approccio didattico

Alcuni sostengono che il FP sia qualcosa di "alieno", "difficile", "impratico", "inutile". Cavolate! In realtà è piuttosto semplice ed estremamente utile e potente.

Il problema, piuttosto, è che semplicemente è qualcosa di un po' diverso da ciò che fin'ora è stato l'approccio mainstream. Ma anche il mainstream si sta rendendo conto che il FP è un requisito essenziale per poter lavorare in modo sano con concorrenza, parallelismo e sistemi distribuiti. Basti vedere la sempre maggiore popolarità di Clojure e Scala per esempio, ma soprattutto che anche Java si sta evolvendo in questa direzione. Già nella versione 8 sono state aggiunte le lambda expressions e gli stream. In ambito .NET poi, F# esiste già da tempo come cittadino di prima classe in Visual Studio. Senza contare Facebook che si sta orientando su soluzioni di stampo FP come Flux, basato su React.js e immutable-js.

L'ostacolo principale che ti troverai davanti all'inizio è che si tratta il tutto con una angolazione un pò diversa da quella a cui normalmente si è abituati proveniendo da un percorso "standard" di formazione. In realtà è semplice: c'è molta carne al fuoco certo, ma si costruisce tutto su solide e semplici basi. Perciò uno dei primi consigli che posso dare al riguardo è: sospendi il giudizio, e affronta l'argomento con mente aperta (con Shoshin, per evitare l'effetto Einstellung). Se ti applichi, ti posso assicurare che avrai una lunga serie di momenti "a-ha!!", che ti arricchiranno e miglioreranno professionalmente per il resto della tua vita (oltre a essere tremendamente eccitanti e soddisfacenti ;)

Ok, ma all'atto pratico da dove cominciare? Qualcuno direbbe: Scala! Ma essendo un misto-mare pieno di casi particolari e che tenta di "fondere" il paradigma OO con quello FP, rischia veramente di confonderti le idee. Oltre a non funzionare. Ha un type system più avanzato di quello di Java, ma la sua type inference è abbastanza limitata rispetto quella di Haskell per esempio. Ergo, secondo me più è diverso da ciò che già conosci, più facile è evitare che gli schemi di pensiero abituali ti rendano più difficili le cose.

Percorso

Haskell for all!

Per queste ragioni, tenderei a consigliarti di iniziare con Haskell. E' un linguaggio funzionale puro e staticamente tipato, che compila in codice nativo (quindi niente JVM nè .NET). Tieni conto che imparare questo stile migliorerà il tuo codice in qualsiasi linguaggio, anche se non utilizzerai Haskell o simili sul lavoro di tutti i giorni.

Il percorso che consiglio è quello delineato da Chris Allen. Per cominciare, ti consiglio caldamente il corso CIS 194 di Brent Yorgey dell'università della Pennsylvania. E' un corso molto completo e ben fatto. Puoi trovare qualche appunto (per ora sulle prime due settimane) sul blog del sottoscritto, ma a cui consiglio di dare uno sguardo solo dopo che hai affrontato il materiale di Brent Yorgey. Non è eccessivamente impegnativo, ma molto utile.

Altro consiglio: fai gli esercizi. Leggere e capire non significa assimilare, per imparare veramente occorre applicare le cose, solo allora ti rendi conto di ciò che sai e cosa no. L'unico apprendimento è quello attivo. Inoltre tieni presente che si parte dalle basi quindi non avere fretta di scrivere web application in quattro e quattr'otto. Tuttavia dalle basi si progredisce abbastanza velocemente, quindi persevera e vedrai ;)

Come ambienti di sviluppo io uso Emacs (vedi istruzioni di Chris Allen anche per questi aspetti), ma potresti anche usare FPComplete: un IDE web-based gratuito (nel cui sito tra l'altro ci sono molte risorse didattiche).

Padroneggiato un pò Haskell, le possibilità sono diverse:

Esiste una versione di Haskell sulla JVM: Frege.
Web frameworks per Haskell (in ordine di "indagine"):
- Scotty
- Snap
- Happstack
- Yesod
Elm, un linguaggio ispirato ad Haskell per realizzare applicazioni web client-side basate sul paradigma FRP. Vedi la learning roadmap per maggiori dettagli.
PureScript è un linguaggio Haskell-like che "transpila" in Javascript. Vedi anche il libro PureScript By Example che mi dicono sia anche una buona introduzione alla FP.

Alternative track: Clojure

Anche Clojure è una buona scelta per imparare l'approccio FP. Ha bene o male tutti gli attributi necessari e fino a poco tempo fa era il mio linguaggio preferito. Di diverso rispetto ad Haskell:

Ha il dynamic typing, ovvero ti aiuta meno nella comprensione/manutenzione di una base di codice ma è più flessibile. Puoi darti la zappa sui piedi con più flessibilità insomma :P
E' omoiconico, ovvero la sintassi con sui si scrive il codice è identica a quella delle strutture dati. Il famoso detto:

Code is data, data is code.

Pur essendo un linguaggio marcatamente funzionale, un po' per scelta un po' per limitazioni della piattaforma sottostante, è da una parte più semplice di Haskell dall'altra ti assiste meno a tempo di compilazione tramite il type system. C'è core.typed certo, ma non è la stessa cosa. Questa differenza si nota molto a livello di impostazione e workflow: si usa molto la REPL e l'enfasi è sul modificare ed evoltere i sistemi manipolandoli direttamente a runtime (cfr. Smalltalk).

Di interesse la sua concezione del tempo, valori e identità (dello stato insomma) che facilita di molto la concorrenza. Da notare che la STM è presente anche in Haskell.

Clojure gira sulla JVM, ma anche su .NET e transpila su JS, interoperando con naturalezza con la piattaforma ospite.

Come risorse, se vuoi approfondirlo, ti consiglio:

(libro) Programming Clojure, seconda edizione. E' un libro introduttivo e conciso che ho trovato molto chiaro e utile. Probabilmente è la risorsa migliore per cominciare con Clojure.
(libro) Clojure Programming (si lo so...) E' considerato più o meno universalmente come il miglior libro per "beginner" (è uscito dopo quello del punto precedente). Copre tutto il liguaggio e molti aspetti pratici come programmazione web, uso di DB di vario tipo, testing, ecc. Ma è un mattone di quasi 600 pagine, quindi l'ho messo per secondo.
(video) Clojure: Inside Out: corso tenuto da giganti, interessante e utile.
(video) LispCast's Introduction To Clojure altra serie di video.
(online) 4clojure: valangate di esercizi (anche con Clojure è importate farli!).

Che ho esaminato meno da vicino, ma che ti segnalo comunque:

(libro/online) Clojure For The Brave And True: una idiosincratica introduzione gratuita :)
(online/libro?) Clojure From The Ground Up. Aphyr in questi mesi si sta dedicando a completare questa introduzione.
(online) Hitchhicker's Guide To Clojure

Dal punto di vista dello sviluppo, io uso Emacs ma ti segnalo anche:

LightTable un avvenieristico IDE (scritto in ClojureScript) facile da usare, che ha spopolato su Kickstarter un paio di anni fa.
Cursive Clojure: IDE basato su IntelliJ IDEA che sta rapidamente guadagnando adepti e che mi pare abbastanza completo (sta evolvendo velocemente).

Ci sarebbe molto altro da dire, ma per il momento basti questo. Ulteriori aree di indagine se sei interessato:

Puoi dare un'occhiata a del mio codice. Probabilmente di relativamente presentabile/semplice ci sono:
- assert-json
- obj-hierarchy (e post di accompagnamento)
- elekti
- actions
- dicepass
- virtual-adventure
- confunion
Programmazione lato frontend con Om o, forse meglio, Reagent (basati su react.js).
Programmazione web con hoplon, Luminus o Pedestal.
Molto interessante, come database, Datomic. Un vero e proprio database funzionale.

Altro?

Personalmente ti posso dire che parecchie delle cose imparate le sto applicando anche sul lavoro. In ambito Java per esempio sto usando molto TotallyLazy: sfortunatamente di documentazione c'è poco, ma ha una tonnellata di roba funzionale molto interessante. Comunque già solo col concetto di Callable e Sequence puoi fare molto e ti abilita un bel po' di idiomi funzionali (anche se non sempre convengono data la verbosità del linguaggio).

Interessante anche da esplorare lazyrecords (degli stessi autori), che fornisce un accesso ai dati funzionale a-la LINQ in ambito .NET.

Lato Javascript ci sono di interessanti da esplorare:

Flux con React e immutable-js (precedentemente linkati)
fn.js
lodash
bilby.js
wu.js

Ci sarebbe tantissimo altro da dire/esplorare/discutere, ma credo di aver già dato abbastanza materiale per ora.

CIS 194, week 2, Algebraic Data Types

2014-08-14T00:00:00+00:00

This is a post about week 2 of the CIS 194: Introduction to Haskell course by Brent Yorgey, from the Penn University of Pennsilvania.

This week is all about Algebraic Data Types (ADT), not to be confused with Abstract Data Types (also ADT) which are another topic.

Haskell has enumeration types (like Java, but still less verbose and more intuitive). An example:

data Food = Pizza
          | Bacon
          | Salad
    deriving Show

We have just declared a new (algebraic data) type called Food, with three data constructors which are the only values of the type Food.

We can now define new functions on the new data type using pattern matching:

isTempting:: Food -> Boolean
isTempting Salad = False
isTempting _ = True

But in Haskell enumeration types are only a special case of Algebraic Data Types. One common class of ADT is called sum type (a.k.a. tagged union). A simple example of ADT which is not an enumeration is this:

data OperationResult = OK
                     | Error Integer
    deriving Show

Here we see that Error is a data constructor that takes an argument of type Integer. We can construct new OperationResult values using the Error data constructor:

success:: OperationResult
success = OK

failure:: OperationResult
failure = Error 404

OK is a value of type OperationResult (since it's a data constructor with zero arguments), but Error by itself it's not. We have to pass an Integer value to it to build an OperationResult with it.

We've just introduced polymorphic data types. Specifically, we can have type signatures with variables just as we can have function implementations with variables. The difference here is that while in actual code variables are symbols bound to values, in type variables are bound to types of values. In other words, types are actually values in type signatures. We're reasoning on a higher and more abstract level. Take a moment to contemplate this fact.

Formally, in Haskell an ADT is a type with one or more data constructors, each one of them can have zero or more arguments.

A general example that shows how to build values is:

isSafeDiv:: Double -> Double -> OperationResult
isSafeDiv _ 0 = Error 1000
isSafeDiv _ _ = OK

We can also use pattern matching to make decisions based on the structure of the OperationResult value and bind variables to the arguments:

isSuccessful:: OperationResult -> Boolean
isSuccessful OK = True
isSuccessful (Error n) = False

It's idiomatic in Haskell when you have an algebraic data type with a single data constructor, to name it like the data type itself. Example:

data Person = Person String String Int
    deriving Show

This can be done since types and data constructors live in separate namespaces.

Pattern Matching

In general, pattern matching is a way to know what data constructor has been used to create a value of a certain ADT, and to take apart its arguments. Effectively, in Haskell this is the only way to make decisions.

pat ::= _
    | var
    | var @ (pat)
    | (Constructor pat1 pat2 ... patn)

In order:

_ is a wildcard.
We can pattern match against literal values (for example: OK).
We can pattern match against a pattern, and still bind the entire value to a variable.
We can pattern match against a data constructor (even recursively).

It's worth noting that types like Int can be viewed like an ADT:

data Int = 0 | 1 | 2 | ...

Indeed, we can pattern match on its values. But, perhaps obviously, they are not implemented like that in the compiler.

Case expressions

A way (the only one actually) to do pattern matching is by using case expressions:

case exp of
    pat1 -> exp1
    pat2 -> exp2
    ...

For example, we could reimplement the isSuccessful function from earlier using a case expression:

isSuccessful:: OperationResult -> Boolean
isSuccessful op = case op of
                    OK -> True
                    (Error n) -> False

However it's more elegant to use the first version. Indeed, the syntax for doing pattern matching in a function definition is just syntactic sugar on case expressions.

Recursive algebraic data types

It's interesting to note that ADTs can be recursive. For example, let's define a list of integers:

data IntList = Empty
             | Cons Int IntList

This definition can be read as: "an IntList is either an Empty one or an Int value followed by an IntList". This kind of definition is quite clear and elegant (see Church encoding). For example:

-- [1,2,3] can be represented as an IntList:
l:: IntList
l = Cons 1 (Cons 2 (Cons 3 Empty))

A recursive data ADT naturally leads to recursive functions. For example, to calculate the sum of all the values in an IntList:

calcSum:: IntList -> Int
calcSum Empty = 0
calcSum (Cons n ns) = n + calcSum ns

So, we've seen so far that type signatures can have variables, and can be recursive. Sounds like we could have a Turing-complete type system... indeed, we have one. Someone even implemented a LISP interpreter that completely runs on the Haskell type system!

That's all for this week. Remember: do the exercises!

Introduction to Haskell, week 1

2014-08-10T00:00:00+00:00

A while ago I've finally started to study Haskell, in particular following the CIS 194: Introduction to Haskell course by Brent Yorgey from the Penn University of Pennsilvania. This is the first resource of the curriculum I plan to follow to learn Haskell (thanks a lot to Chris Allen for laying out a path to FP enlightenment :)

I've worked through the first 4 weeks now, but I decided at this point to switch gears and go back to recap what I've learned so far.

Without further ado, let's recap CIS 192: week 1.

What is Haskell?

Haskell (named after Haskell Curry, for his work on combinatory logic and for the Curry-Howard Correspondence), is a lazy, statically typed, pure functional programming language created in the 1980's by a committee of academics. It's very well alive today, as it's one of the most advanced (statically typed) languages out there.

Haskell is:

Functional

Functions are first-class values. That is, they can be passed to other functions or returned by them like any other values.
The computation model is based around evaluating expressions, not executing instructions. In other words, it's not based on the Von Neumann architecture (instructions that operate on a shared memory), but on the lambda calculus (you can think about it in terms of composing functions to transform streams of immutable data).

Pure

Every expression is referentially transparent. This means that:

Everything is immutable. Every "mutation" is modeled as a transformation, a function that doesn't change the original value but creates a new one.
There are no side effects (well, there are: modeled with monads to retain purity, but you don't need to know what a monad is to use them!).

As a consequence of the previous points, calling the same function with the same arguments results in the same output, always.

This approach has a number of very nice benefits, that once you wrap your head around this paradigm you won't give away too easily:

Equational reasoning: thinking about the code becomes much more easier. Refactoring becomes a breeze.
Parallelism: using multiple cores is much easier when you know that functions are guaranteed not to interfere with each another. There is no shared state!

In general, with static types and pure functions programs become much more easy to maintain, refactor, debug and reasoning about.

Lazy

In Haskell values are computed only when needed (call-by-need evaluation strategy).

Advantages:

It's easy to define new control structures just by defining a new function. Contrast this with languages like Clojure where you need macros to achieve that, or languages like Java where it's basically impossible.
It's easy to work with infinite data structures, since values are only computed when needed. You can achieve the same in idiomatic Clojure by using the seq abstraction and lazy-seq, in Java 8 using Streams, etc.
It enables a compositional style (we will see it down the road with wholemeal programming, currying and point-free style).

Downside: it becomes harder to reason about the time and space characteristics of programs.

Themes

The course revolves around thee key areas:

Types
Abstractions
Wholemeal programing

Types

Static type systems can be annoying, and some of them really are. But this isn't because type systems are inherently annoying, that's because some of them are insufficiently expressive (for example, Java and C++ ones).

A type system (especially the Haskell one):

Gives you clarity of thinking and helps you to design and reason about programs. Types become an organizing principle, a precise and powerful tool to think about and express abstractions. Using them, you are able to reason at a higher level, in a systematic way.
Is a form of documentation, always in sync with the actual code.
Turns a lot of runtime errors to compile time ones. Computers can do complex, repetitive and clearly specified things efficiently: why not delegate to them some of the burden that a human has to carry on while writing software?

Once you start to get the hang of it, a (good) type system becomes an invaluable ally. It feels liberating, since it can help you long before you write the first line of code: it helps you in the design of the system.

Abstraction

In some way, designing and maintaining software is a battle against repetition: you frequently need to take similar things and factor out their commonality (a process known as abstraction).

Haskell gives you a lot of abstraction power: parametric polymorphism, higher-order functions, type classes, etc. Its type systems is also a powerful, methodic and sound tool to think mathematically about them.

Wholemeal programming

Quoting Ralf Hinze:

“Functional languages excel at wholemeal programming, a term coined by Geraint Jones. Wholemeal programming means to think big: work with an entire list, rather than a sequence of elements; develop a solution space, rather than an individual solution; imagine a graph, rather than a single path. The wholemeal approach often offers new insights or provides new perspectives on a given problem. It is nicely complemented by the idea of projective programming: first solve a more general problem, then extract the interesting bits and pieces by transforming the general program into more specialised ones.”

In short, it's about working with abstractions rather than concrete instances of the problem/solution space, with group/types of things instead of with single instances.

Next, Brent Yorgey goes on showing the basic types (scalars and lists), how to define and combine functions, etc. Lots of good stuff.

Data types as graphical shapes

2014-07-04T00:00:00+00:00

A very interesting idea that I've just found in a post by Aaron Spiegel: to explain basic FP constructs like map, filter and fold/reduce graphically (nothing new, I've already done that several times), but with an interesting twist: by representing types as shapes. That's a clever trick to better explain that HOFs (Higher-Order Functions).

However, visual languages rapidly become inadequate to express more high level concepts. For example you can sort-of encode algebraic data types using different colors for example. Then maybe you can express options using full or empty shapes. But, as you probably can see, there are limits in this medium and we can reach them pretty fast.

In some sense it's like understanding certain mathematical concepts using geometry (as a visual learner, that's how I really understood integrals), but one of the reasons mathematicians use textual notation is that it's much more concise and expressive.

Summary: x-Driven x do not change anything

2014-05-03T00:00:00+00:00

This is a short summary of my takeaways of the article -Driven do not change anything by Michał Bartyzel.

Mental frameworks (like *-Driven*) need to be intepreted in the light of the appropriate context, and require experience to be applied to unknown ones.
These frameworks are usually formed over many years of experience by induction, and adapted to other contexts by deduction.
Instead of focusing on context/experience-dependent mental frameworks, invest in developing the foundamentals:
- Responsibility
- Encapsulation
- Composition

Interesting links

2014-03-29T00:00:00+00:00

Deliver Working Software Frequently

Before you can run, you need to learn how to walk. This is a good primer on agility. Focus first on delivery.

Until you can deliver, work on delivery. Work on nothing else until then. The rest will come in due time.

I reckon your message broker might be a bad idea.

Message brokers can be a bad idea if treated like "infallible gods", because they aren't. Think about three good design principles for realiable systems:

Fail fast
Process supervision
End-to-End principle

In the end, it isn’t so much about message brokers, but treating them as infallible gods. By using acknowledgements, back-pressure and other techniques you can move responsibility out of the brokers and into the edges. What was once a central point of failure becomes an effectively stateless server, no-longer hiding failures from your components. Your system works because it knows that it can fail.

PostgreSQL 9.4 - Looking Up (With JSONB and Logical Decoding)

PostgreSQL 9.4 is going to be exciting with JSONB support. As David Lesches says:

JSONB has been committed to Postgres 9.4, making Postgres the first RDBMS with rock-solid support for schemaless data

On "Enlightenment"

2014-03-24T00:00:00+00:00

The more I think about it, the more I see it. They say that you should expose yourself to different kind of programming languages, and more specifically to different kind of paradigms. The key of that advice is to get exposure (and hopefully proficiency) with different ways of thinking. The more high-level thinking tools you have at your disposal, the more effective and efficient you are at identifying and solving problems.

You become able to really see the problem and build a general solution. You start to deconstruct what you know, the constraints and the problem at hand, and you become able to build general solutions by composing simple things. Systematically. When you start to think in terms of data transformations via map, filter, reduce, juxt, etc. you realize that you are operating on a higher level. You start to really see what the single resposibility principle is all about. And then, you start to see all the accidental complexity that used to slow you down and hide the essence of the solution behind reams of low level details (syntactical or otherwise). When your mind is not distracted by accidental complexity, you can step back and think clearly about what you have and what is really needed.

Unfortunately, this kind of "enlightenment" has some downsides:

You become painfully aware that you could do much better and much faster than when you develop with less advanced languages (for example: Java). Here starts the frustration.
Your "yet-to-reach-enlightenment" colleagues don't see the way you do. They don't understand (yet). This is the blub paradox at work.

Combine both factors, and you have a recipe for misery. It's depressing seeing friends (and yourself) wasting time with unnecessary complexity.

However, even if it requires work, practice and dedication to reach a master level, I think that it's worth it. I'm certainly not a master, and yet I'm seeing benefits of this learning journey even when I'm not writing LISP code. Eric Raymond was right:

LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.

So go ahead and learn some Clojure, Haskell and Factor (for example). You don't need to spend a lot of time to get a feel of what's out there. You will be a better programmer anyway, and I think this is a worthwhile goal.

On frameworks

2014-02-18T00:00:00+00:00

Frameworks remove your ability to solve your specific problems from first principles. They opt you out of innovation, simplicity & elegance — Steve Purcell

How to programmatically manage a Light Table-aware nREPL server

2014-01-26T00:00:00+00:00

Starting an nREPL server for a Clojure application is trivial if you use Leiningen:

lein repl

# or:

lein repl :headless

But what if you have an application deployed as a JAR (or WAR in an application server) and you want to have remote access to an nREPL server? Fortunately, it's easy to start one programmatically:

(require '[clojure.tools.nrepl.server :refer (start-server stop-server)])

; Starting an nREPL server is trivial:
(defonce nrepl-server (start-server :port 12345))

; So is stopping it:
(stop-server nrepl-server)

It works out of the box if you use Emacs with Cider to connect to it, but if you use Light Table, you need to add an additional nREPL middleware to support some functionality that LT needs to work properly. Again, this is easy if you use Leiningen: you just need to declare the dependency to the middleware and add some :repl-options:

(defproject some-awesome-thing "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [lein-light-nrepl "0.0.13"]] 
  :repl-options {:nrepl-middleware [lighttable.nrepl.handler/lighttable-ops]})

Using the lighttable-ops nREPL middleware programmatically is also quite easy, but you have to know how to compose nREPL middlewares. First, you need to add the dependency to the LT middleware in your project.clj as before:

(defproject some-awesome-thing "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [lein-light-nrepl "0.0.13"]])

Then you can add it to the middlewares chain in your code:

(require '[clojure.tools.nrepl.server :refer (start-server stop-server)])
(require '[lighttable.nrepl.handler :refer [lighttable-ops]])

; Starting a server with custom middlewares is trivial:
(defonce nrepl-server 
         (start-server :port 12345
                       :handler (default-handler #'lighttable-ops)))

; So is stopping it:
(stop-server nrepl-server)

Notice that we passed lighttable-ops to the default-handler as a var (in fact, #'lighttable-ops is a reader macro that expands to (var lighttable-ops)).

Now you can connect to your project remotely using Light Table and inspect, modify and control it live. Enjoy :)

Terrifying

2013-12-12T00:00:00+00:00

This is one of the most terrifying technical books I've ever read (not an affiliated link):

I haven't finished it yet, and I already think it's a foundamental read for every professional software developer. Along with, for example:

JDBC Lint

2013-12-11T00:00:00+00:00

Recently I'm working quite heavily with straight JDBC and I'm learning some things from best practices and some others the hard way. One tool that I've found useful is JDBC Lint: it's a tool that acts as a dynamic proxy for Connection objects (so that it can be used transparently) and reports errors at runtime on the standard error channel.

For a primer on some JDBC best practices, see this post.

Fainting Goat Systems

2013-12-09T00:00:00+00:00

Paraphrasing Robert Heinlein, reality is a harsh mistress. Have you ever designed or worked on a system which was finally declared "done" (the mythical 1.0 release): it passed all QC tests, all was green, all the checks in place... but that failed miserably when deployed in production? Unfortunately, a real system lives in a harsh reality made of unreliable networks, crashing subsystems, crazy users and Elbonian hackers.

Architecture is extremely important: flexibility, rapid development, modularity. All technically cool and necessary (I'm all for it!), but you need to take into account and design for the real world. You don't want to design a cool system on paper only to be constantly in emergency mode, struggling and working frantically just to keep the system live (still, with 80% availability, or worse). When you are in survival-mode you can't spend time learning, practicing and developing new systems (that generates revenue). I call those "Fainting Goat Systems": they are beautiful, functional, but when they are under stress, they just crash and fall to the ground. Here is an informative slide of a Fainting Goat System just deployed to production for the first time:

The first thing is stability. The system should be stable, built for cheap and easy operations and ready to make contact with the real world and real users. It's important to release early and often, in production, and adapt to reality. Certain lessons can only be learned in production, with real users and real deployments.

A good book on the subject is Release It! by the Cognitect Michael T. Nygard.

(JAR) Hell is here

2013-12-05T00:00:00+00:00

From Gorging on Java frameworks and dependencies:

I can't remember who said it, but I think one of my colleagues at Comoyo said something along the lines of: "we obsess over our own code with code reviews and such, but we happily depend on any piece of shit some crazy monkey on the net has cobbled together in his spare time".

Think about that. Because it is true.

Right now your Java application probably contains a dozen version conflicts that you have not noticed. The more common variety being the same library occurring in your transitive dependency graph more than once and in different versions. It is sheer dumb luck that your application works at all. If you don't know what I am talking about I suggest you have a close look at your transitive dependency graph.

There has to be a better way to manage dependencies. One that is not necessarily a one-level dependency tree (which isn't an unreasonable thing given a suitable language/ecosystem). Well, maybe there is.

Power comes from Emergence

2013-10-24T00:00:00+00:00

I've been thinking a lot about the intersection of OOP and FP, and I've come to realise one thing: there is real power on the *composition** of simple things*.

It's more general than the objects VS functions debacle, and I won't talk about immutability right now. The point I want to make is that when you have a small set of simple concepts/abstractions that you can compose at will, you get a great deal of expressivity and power that you can build on. Just look at LISP or Smalltalk.

git

Maybe you are among the ones that consider git difficult. Well, at its core git is quite simple: it's a set of simple concepts at your disposal that give you a lot of power and flexibility.

Understanding them in isolation is easy, because they are simple. However, there are a lot of ways to compose simple things and it isn't equally easy to grok all the ways you can combine them. The real power and expressiveness emerge from the interactions between the foundational concepts. In other words: it's more than the sum of their parts.

Git it's a perfect example of the concept of emergence at work. Quoting Wikipedia:

In philosophy, systems theory, science, and art, emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions.

Pedestal

Another example is Pedestal. It's difficult to get it: in part because it's different from the "standard" Rails-esque web framework, and in part because it's designed as a set of simple concepts. Taken one by one they are quite simple, but the real power and perceived complexity is on the number of ways you can compose them.

Contrast this with the average framework: usually there is THE way to do things and you only have to plug your code here and there and BAM! It works. A blog engine in 15 minutes, cool uh? It's certainly easy, but not simple and by a large degree not nearly as powerful.

BTW, yes I know that Pedestal has been designed with real-time collaboration in mind :)

A short tutorial on clojure.java.jdbc

2013-07-18T00:00:00+00:00

clojure.java.jdbc is a useful library to have in your toolbelt when you need to work very close to JDBC and for various reasons you can't or don't want to use higher level tools like Korma. In fact it is a thin wrapper over JDBC that makes working with it from Clojure easier and safer.

This library is undergoing a major API overhaul (starting with version 0.3.0-alpha1) to make it more idiomatic. I've used previous versions but the new API is significantly different and after toying around with it and reading bits of informations here and there, I wanted to jot down a short guide on how to use it.

Dependencies

Using Leiningen is easy to import this library and the hsqldb driver to fiddle with it:

  :dependencies [[org.clojure/clojure "1.5.1"]
                 [org.clojure/java.jdbc "0.3.0-alpha4"]
                 [hsqldb/hsqldb "1.8.0.10"]]

Than a lein deps and you are good to go.

Idea

The main idea behind clojure.java.jdbc (as I understand it) is to provide functions to basically:

Query a DB and transform resulting data sets
Mutate a DB

Both managing connections and transactions in a transparent way, using plain old SQL strings.

There is a basic DSL for composing SQL strings in the clojure.java.jdbc.sql namespace, but as the documentation says it is deliberately not very sophisticated. To make this guide short we'll only explore the JDBC managing stuff, using raw SQL strings. If you want you can use it in conjunction with HoneySQL to generate SQL strings from Clojure data structures (a-la Hiccup).

A short example

(require [clojure.java.jdbc :as j])

(def db-spec {:subprotocol "hsqldb"
              :subname "mem:testdb"})

A JDBC connection can be configured using both a map or a string. Here the HSQLDB configuration is very simple since we want a simple in-memory database, but you can specify a full connection to PostgreSQL, MySQL, Oracle, etc:

{:classname "com.mysql.jdbc.Driver"
   :subprotocol "mysql"
   :subname "//127.0.0.1:3306/mydb"
   :user "myaccount"
   :password "secret"}

Now to mutate a database you can use db-do-commands:

(j/db-do-commands db-spec true
                  "CREATE TABLE movies (id INTEGER IDENTITY, name VARCHAR(256), year INTEGER)")

(j/db-do-commands db-spec true
                  "INSERT INTO movies(name,year) VALUES('Iron Man', 2008)"
                  "INSERT INTO movies(name,year) VALUES('Gattaca', 1997)")

The second parameter is for running all the following SQL statements inside that expression in a transaction.

However, I should mention that for inserting new rows there is a more idiomatic way to do it:

(j/insert! db-spec :movies
  {:name "Iron Man" :year 2008}
  {:name "Gattaca" :year 1997})

Querying database is even simpler:

(j/query db-spec
         ["SELECT * FROM movies WHERE year>?" 2000])

The cool thing about query is that you can add keyword parameters to pass transformer functions that can operate both on single rows or the entire result set.

(j/query db-spec ["SELECT * FROM movies"]
         :row-fn #(str (:name %) " was released in " (:year %)))

Conclusion

clojure.java.jdbc is a valuable tool to work with databases via JDBC when other approaches such as Korma are not applicable or desired. It is even more powerful when used in conjuction with a good DSL to compose SQL strings.

For a more in depth look at this library, go to the corresponding section at clojure-doc.org.

Update: 2013-11-04

clojure.java.jdbc 0.3.0 has just reached beta status. Go read the official announcement for all the details. In short, now it has been declared feature-complete.

Update: 2013-11-25 ##

clojure.java.jdbc 0.0.3-beta2 has been relesed with breaking changes. Based on the feedback from the community, now the sql and ddl namespaces have been removed (they have been extracted in a separate lib: java-jdbc/dsl) and the official recomendation is to use more sophisticated DSLs like HoneySQL, SQLingvo, clojure-sql or Korma. The second breaking change is that the deprecated API has been moved in the clojure.java.jdbc.deprecated namespace to eliminated confusion on what the new API is and to highlight this distinction even in the generated API documentation.

Update: 2013-12-18

The stable 0.3.0 version has just been released. You can read the related post by Sean Cornfield on his blog.

Clojure and Java data structures interoperability

2013-04-21T00:00:00+00:00

Clojure is a language designed to be hosted, this means that it utilizes all the power of the hosting platform without trying to hide or abstract it. This design choice has several consequences:

You have full access to the hosting platform.
Usually Clojure code can interoperate nicely with other code that runs in the same platform, even if it's written in another language (for example Clojure on the JVM can easily interoperate with code written in Java, Ruby, Python, Groovy, etc).
It uses the basic types available on the hosting platform and builds on them.

However, Clojure emphasizes functional programming and immutability, and this has to be taken into account when interoperating with code written in another language that works on lossy mutable state.

Using Clojure data from Java

Usually there is no problem in using Clojure data structures in Java code since all data types in Clojure implements the relevant Java interfaces like java.util.List, java.util.Map, etc.

Let's see the classes and interfaces hierarchies for the main data structures of Clojure:

Lists
- Class: clojure.lang.PersistentList, interfaces: clojure.lang.ISeq, clojure.lang.Sequential, java.util.List, java.io.Serializable, clojure.lang.IHashEq
- SuperClass: clojure.lang.ASeq, interfaces: clojure.lang.IObj, java.io.Serializable
- SuperClass: clojure.lang.Obj
- SuperClass: java.lang.Object
Vectors
- Class: clojure.lang.PersistentVector, interfaces: clojure.lang.IPersistentVector, java.lang.Iterable, java.util.List, java.util.RandomAccess, java.lang.Comparable, java.io.Serializable, clojure.lang.IHashEq
- SuperClass: clojure.lang.APersistentVector, interfaces: clojure.lang.IFn
- SuperClass: clojure.lang.AFn
- SuperClass: java.lang.Object
Maps
- Class: clojure.lang.PersistentArrayMap, interfaces: clojure.lang.IPersistentMap, java.util.Map, java.lang.Iterable, java.io.Serializable, clojure.lang.MapEquivalence, clojure.lang.IHashEq
- SuperClass: clojure.lang.APersistentMap, interfaces: clojure.lang.IFn
- SuperClass: clojure.lang.AFn
- SuperClass: java.lang.Object
Sets
- Class: clojure.lang.PersistentHashSet, interfaces: clojure.lang.IPersistentSet, java.util.Collection, java.util.Set, java.io.Serializable, clojure.lang.IHashEq
- SuperClass: clojure.lang.APersistentSet, interfaces: clojure.lang.IFn
- SuperClass: clojure.lang.AFn
- SuperClass: java.lang.Object

So you can easily write libraries in Clojure that can be used from Java without problems. Clojure data structures outside the Clojure contex usually behave like regular Java collections, maps and sets.

Using Java data from Clojure

Usually, the other way around is straightforward too. But there are some corner cases that you have to be aware of when writing libraries that can be used from Java.

Idiomatic Clojure code often works on data structures through the seq(uence) abstraction. In fact a lot of higher-order functions in clojure.core just call seq on their collections arguments. But there are corner cases, and we'll look at one of them that I discovered recently when writing the assert-json library.

A corner case

Let's build a regular map:

(def m {:a 1 :b 2})

(map class m) ;= (clojure.lang.MapEntry clojure.lang.MapEntry)

(first (first m)) ;= :a
(second (first m)) ;= 1

Ok, so map when iterating on a... map, works on a sequence of clojure.lang.MapEntry. And first and second functions can be used on these MapEntry to extract respectively the key and value of the map entry. Easy.

Now let's try it with a java.util.HashMap:

(def hm (doto (java.util.HashMap.)
              (.put "a" 1)
              (.put "b" 2))

(map class hm) ;= (java.util.HashMap$Entry java.util.HashMap$Entry)

(first (first hm)) ; java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.util.HashMap$Entry
                   ;   RT.java:494 clojure.lang.RT.seqFrom
                   ;   RT.java:475 clojure.lang.RT.seq
                   ;   RT.java:567 clojure.lang.RT.first
                   ;   core.clj:55 clojure.core/first

What's the problem here? In the stacktrace we see that first calls seq on its argument, and seq on a java.util.HashMap$Entry fails miserably. Why? Let's read the documentation of this function:

(doc seq) ;-------------------------
          ;clojure.core/seq
          ;([coll])
          ;Returns a seq on the collection. If the collection is
          ;    empty, returns nil.  (seq nil) returns nil. seq also works on
          ;    Strings, native Java arrays (of reference types) and any objects
          ;    that implement Iterable.

Well, since sequence is a sequential list abstraction, every seqable data structure must be Iterable (or either a String or an array of reference types). If you look again in the Using Clojure data from Java section, you'll see that Clojure maps implements the java.lang.Iterable interface that in this case iterates on clojure.lang.MapEntry instances. These MapEntry objects live in this hierarchy:

Class: clojure.lang.MapEntry, interfaces: clojure.lang.IMapEntry
SuperClass: clojure.lang.AMapEntry, interfaces: clojure.lang.IPersistentVector, java.lang.Iterable, java.util.List, java.util.RandomAccess, java.lang.Comparable, java.io.Serializable, clojure.lang.IHashEq
SuperClass: clojure.lang.APersistentVector, interfaces: clojure.lang.IFn
SuperClass: clojure.lang.AFn
SuperClass: java.lang.Object

And so MapEntry objects are Iterable too. That's why first on map entries works.

On the Java side? We already know that HashMaps are Iterable on java.util.HashMap$Entry instances. But these HashMap$Entry are Iterable too? Probably not, let's see the class and interfaces hirarchy:

Class: java.util.HashMap$Entry
SuperClass: java.lang.Object

Uhm, no they are not.

A better solution

The problem here is that to extract key and value from a map entry I used the wrong functions. first and second are more appropriate on generic sequences, instead for this specific task there are more suitable (and interoperable) functions: key and val.

(def m {:a 1 :b 2})

(key (first m)) ;= :a
(val (first m)) ;= 1

(def hm (doto (java.util.HashMap.)
              (.put "a" 1)
              (.put "b" 2))

(key (first hm)) ;= "a"
(val (first hm)) ;= 1

Wrap up

Clojure and Java are usually nicely interoperable, but pay attention to use the appropriate functions in Clojure to manipulate data structures when it's possible that your code will be used from Java.

Abstraction

2013-02-26T00:00:00+00:00

I've noticed that when two or more people discuss about some technical matter, some words are sometimes used inappropriately and mean different things for different people. You can easily imagine that in this context having meaningful and fruitful discussions is almost impossible.

If you try to discuss about object-oriented programming for example, you'll quickly find out that there are a lot of different ideas on what OO is all about, most of them somewhat "fuzzy". Can you pinpoint exactly what OOP is? I mean, what Alan Kay had in mind when he coined that (unfortunate) term? I would have several things to say here but I digress, lets return on topic.

That's why here I'll try to define exactly what the meaning of the word abstraction really is, and what I mean when I use it.

Definition

First, let's see what etymonline has to say about it (emphasis is mine):

*abstract (adj.)*, late 14c., originally in grammar (of nouns), from Latin abstractus "drawn away," pp. of abstrahere "to drag away; detach divert," from ab(s)- "away" (see ab-) + trahere "draw" (see tract (n.1)). Meaning *"withdrawn or separated from material objects or practical matters"* is from mid-15c [...]

So, here we have something important that we can work with. Something is abstract when it's separated from material practical matters. Excellent! Now let's see what the dictionary says. As an adjective:

thought of apart from concrete realities, specific objects, or actual instances: an abstract idea.
expressing a quality or characteristic apart from any specific object or instance, as justice, poverty, and speed.
theoretical; not applied or practical: abstract science.
difficult to understand; abstruse: abstract speculations.

So from these definitions we can say several things. First of all that something can be abstract, in which case that thing is not concerned with practical considerations.

Another interesting consideration is that when something is abstract it can be difficult to understand. It can happen when the abstract thing has no or very little connections with practical matters, or when it's so complex and with so many interconnected parts that mapping all of them to corresponding more concrete things is very difficult.

As a verb:

to draw or take away; remove.
to divert or draw away the attention of.
to steal.
to consider as a general quality or characteristic apart from specific objects or instances: to abstract the notions of time, space, and matter.
to make an abstract of; summarize.

Furthermore, it's also an action. We can abstract away practical details and have a conceptual model to work with more easily.

Abstraction in the software development domain

Now I think we can try to give a sort-of definition of abstraction in the software development context:

abstraction (noun) is a conceptual model of the structure or function of a software construct that is not concerned with mechanics and other practical considerations.

Probably it isn't a good definition, but it's a starting point (I'm open to discuss and refine or rewrite it). From this definition we can make some deductions:

To abstract in the programming domain means separating a concept from it's implementation details. This way, when we have an abstraction we have a concept that:

It's generally easier to understand, reason about, specify and test.
We can implement it in completely different ways without changing its essence.

If components depends on an abstraction, we can change its implementation and refactor how we want without affecting its users. Nice!

Notice that this concept is independent from scale: we can abstract functions, classes, components, systems or even entire networks of services. And this is exactly the premise and original meaning of OO: a way of thinking and designing systems to manage their complexity, by creating loosely coupled abstractions that communicates by messages at all scales. So "real" object-oriented design is a fractal design thinking that produces a network of abstractions (on both state and behavior) that can be easily rearranged and modified (even at runtime, see Smalltalk for example). Actual mechanics (encapsulation, inheritance and polymorphism) are only consequences, not the definition itself.

We can map the same concept in a different way to FP, but this is matter for another post.

Abstraction or indirection?

Sometime I see the word "abstraction" used when the real meaning is "indirection". Abstraction implies removing implementation details, whether indirection only adds another step to reference the same thing with all the specific low level details in place that you have to take into account. They are both useful but different things.

Suppose that you have to cook a pie, and you can ask a friend for help. But he doesn't have the slightest idea on how to do it, so you sit on your couch and describe to your friend with excruciating details how to cook a pie. Congratulation, you just added a level of indirection.

Now suppose that your friend is an excellent chef. In this case you only need to ask him "just cook an apple pie". And this, my friend, is abstraction.

They are quite different, isn't it? Notice how in the first case you didn't touch the pie with a finger, but you still need to know how to mix, how much to cook it, etc. etc. In the second case however, you didn't have to think about all of that low level details. You just wanted an apple pie!

If you want, let's discuss on Reddit, or read Zed Shaw take on this topic.

Learning faster

2012-10-26T00:00:00+00:00

Learning fast, and being able to master concepts and techniques is more important that ever nowadays in the "information age". Learning something deeply and mastering it to the point of having an intuition about it is very important in every field. The point is developing knowledge and skills, not only being able to reharse dry informations.

But what we could do about this? Learning to learn is underrated, but very important. Here I summarize my understanding of a guest post by Scott Young on Study Hacks, a very interesting blog written by Cal Newport. This guy (Scott), completed the 4-year MIT computer science curriculum in just 12 months... So I suppose he has some good tips to share on this.

The Drilldown Method

The so-called "drilldown method" has this basic structure:

1) Coverage

The first step is gaining a general understanding of what you need to learn. This could mean watching videos, presentations, reading books, papers, doing research, etc.

Don't make the mistake to consider this step the most important. Since this a necessary step but generally the ROI is not so high (the real learning is active), in many cases it's better to speed-up this stage so that you can invest more time on the latter ones.

The interesting thing is that if you're reading a book, highlighting is a poor way of processing informations. It's much better to use techniques like:

Note-taking: taking sparse notes while reading.
Summarizing: writing a one paragraph summary of each major section.

Maybe both, but the point here is to be actively engaged with the material and quickly processing it to gain a general understanding. Probably you won't understand or remember everything: this is perfectly normal. If the subject is not trivial there will be more iterations, but for the first one remember that it's better to quickly review the material and gain a "mental framework" of the subject for further learning than grinding on every section only to give up in frustration. Indeed, often you'll gain enough informations in the first iteration so that in the following ones you'll understand a lot more.

2) Practice

Practice serves a dual purpose:

To test what you learned and "persist" its mechanics and connections to other concepts into your brain.
To Discover what you don't understand.

The first point is self-evident, but the second one is equally important: often you'll think that you understand a subject after reading some material about it... until you try to test it. Practice is both a way to achieve mastery and a way to test your understanding against reality.

One very important thing about practice is that feedback should be immediate. The sooner you know whether you have done is right or wrong, the better. The best way to go about it is to do some exercises with the solutions in hand. This way you do the exercises and immediately know if you really understand that particular subject/technique/process/whatever.

3) Insight

With the previous steps you'll gain informations, some skills, but more importantly an understanding of what areas you need to develop a better intuition for.

One great way to dig deeper and create a profound understanding and mastery of concepts is the Feynman Technique:

Get a piece of paper (actual paper, this way you'll be able to easily draw diagrams, doodles, formulas, etc.) and write at the top in a simple and unambiguous way the top idea or process you want to understand.
Explain the idea, as if you were teaching it to someone else.

This technique is fairly easy to describe, but it enables some important advantages:

Sometimes you'll reach a point in which you can't really explain something: that is a gap in your understanding. Now you can reach out to textbooks, mentors or online to fill that gap.
During this process, you'll come up with insights, novel connections with things you already know, metaphors and problems that will benefit from this new understanding.

"You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein

This technique can be applied in several ways:

For ideas you don't get at all: in this case it's often useful to copy the author's explanation, adding your own insights and ideas in the process. Maybe trying to rewrite the concepts in your own words.
To procedures: writing down the process step-by-step in your own words. What they do, how and why.
To formulas: explaining them piece by piece and how they fits together. What they mean, what are their relationships.
To check and exercise your memory: writing down a summary of a particular concept without using any material other than your memory.

Down the rabbit hole

With the Feynman Technique you can go deeper, but you could go further and develop not just an understanding, but even a deep intuition about it. That's the Ri stage in the Shuhari model.

Understanding intuitively and idea is not easy, but that's when you'd have really internalized it. Most intuitions about an idea, according to Scott, can be classified in this "classes":

Analogies: similarities with easier-to-understand ideas.
Visualizations: visual metaphors that captures some essential aspects.
Simplifications: taking out and being able to explain the essence in simple words (to grandmothers).

Gaining deep understanding and mastery

Don't fall trap of the illusion that these steps in reality are strictly executed in sequence. They are more a cycle that you go through several times, section after section, chapter after chapter, book after book.

Sure, it's more work to do compared to one mindless reading. But it's a faster way to develop a real and deep understanding and mastering the concepts. That is, if you aren't serious and motivated about learning something, you'll give up. And this is good! Not every subject is really useful or interesting to you and that's fine. That's the way you discover what you are really interested into.

What does it means for us developers?

We developers tend to go through only the first two steps:

Coverage: reading a book (or pieces of it) that teaches the basics.
Practice: applying that basics to a toy project (or a production system).

However, some developers extend that practice with the third step: summarizing their insights and new understanding in blog posts, guides, tutorials, presentations and even entire books or courses. I think this is a very useful practice.

On a related note, that's why I claim that good programming books should have exercises with solutions for at least every chapter (for a recent example, see Functional Programming for the Object-Oriented Programmer by Brian Marick).

They should also don't stop after teaching syntax and mechanics, but also teach about:

Design patterns
Best practices

And in general not only the how, but also the why and when.

"That is, the best programming language books infuse a strong sense of design into the narrative. The strength of this approach is that not only are you learning a programming language, but you’re also learning how to think in that language, and the very why of the language itself." -- Michael Fogus

It's the same Michael Fogus that with Chris Houser wrote The Joy Of Clojure, a book that won a Jolt Award in 2011 as one of The six best books every developer should read. Another example to look closely to :)

Software Construction

2012-09-05T00:00:00+00:00

I've just read an interesting post from Daniel Sobral: "Bugs, TDD and Functional programming" in which he gives some ideas on how to bridge the gap between software and physical constructs.

The point in that post is that while physical things obey to the "law of proximity of cause and effect" (ie. when something goes wrong you often find the cause where the problem manifested itself) because of the physics constraints and forces, in software you don't naturally have this kind of direct cause-effect relationships.

I'm not convinced that this is the case for physical things, but I think the point is valid: for introducing direct cause-effect relations, you need to introduce constraints in order to manage complexity. And OOP is one response to this need, functional programming is another.

On a related note, TDD is a very useful practice that helps with realizing this proximity (useful both in OOP and FP contexts).

True OOP

2012-08-16T00:00:00+00:00

OO was not translated properly from the original Alan Key propositions of components sending messages between each other. [...] The Actors model of computation is typically an OO pattern that implements message passing. It’s strange nowadays to see actors being used as a strong argument to adopt FP instead :)

From Reborg.

After studying and exploring papers, articles and talks by Alan Kay I couldn't agree more to this. There was clearly a misunderstanding on the original object-orientation's vision.

Since the rationale for OOP was managing complexity and creating massively scalable systems, I think we need to rediscover the original meaning of this design philosophy if we want to be better armed to solve real world modern problems. Maybe it's not the best way to solve some problem, but it's an additional tool at your disposal.

Come prolungare la vita delle batterie dei laptop

2011-03-28T00:00:00+00:00

Ho da poco acquistato un nuovo portatile e voglio trattarlo bene, facendo durare la batteria il più a lungo possibile. Informandomi in giro ho incontrato molti "boh" e diverse risposte poco convincenti, così mi sono deciso a fare qualche ricerca in proposito (vedi Riferimenti).

Innanzitutto, il famoso effetto memoria (secondo il quale ricaricando ripetutamente la batteria senza arrivare alla capacità massima questa "ricorda" questo livello energetico abbassandone a tutti gli effetti la capacità) riguarda le batterie al nickel-metalidrato (NiMH) e nickel-cadmio (NiCd) che non sono più utilizzate nei portatili moderni. Ad oggi, tutti i dispositivi elettronici dotati di batteria come portatili, videocamere, IPod, etc sono alimentati da batterie aglio ioni di litio (Li-ion) che non soffre di questo problema.

Quando si parla di durata della batteria, due sono i fattori chiave che determinano la durata della vita di una batteria: la temperatura e la carica.

Temperatura

Nel caso delle batterie Li-ion una temperatura troppo altra, specialmente se prolungata nel tempo, accorcia la vita delle batterie. Perciò ecco alcuni suggerimenti da tener presenti:

Assicurati che il dispositivo sia ben areato e non ci sia nulla ad ostruire la ventilazione. In particolare evita di appoggiare il portatile su materiali isolanti come coperte, cuscini e simili che ostacolano la circolazione dell'aria e portano quindi al surriscaldamento.
Evita di ricaricare la batteria mentre stai lavorando: la scheda video, il processore e l'hard disk scaldano e la temperatura diminuisce la vita della batteria.

Carica

Una batteria può essere ricaricata solo un numero limitato di volte, in genere tra le 300-1000 (il numero reale dipende da come la batteria è stata tenuta). Perciò è importante trattarla bene e non ricaricarla troppo spesso.

Qualche suggerimento:

Calibra la batteria ogni 30 cariche. Calibrare significa scaricarla completamente e quindi ricaricarla.
Non scaricarla completamente. Come detto poco sopra le batterie agli ioni di litio non hanno effetto memoria, anzi scaricare completamente una batteria ne accorcia la vita quindi è preferibile limitarsi a farlo solo per la calibrazione. E' perfettamente sicuro ricaricare la batteria anche se non è completamente scarica, meglio se intorno al 20% della capacità totale.
Evita di caricarla completamente. Le batterie caricate completamente, specialmente se sottoposte ad alte temperature, si deteriorano più in fretta. Di norma è bene non superare l'80% della capacità totale.
Evita lavori intensivi durante la ricarica. Anche scaricare la batteria troppo velocemente ne accorcia la vita.
Evita di ricaricare. Di norma i laptop cercano di ricaricare le batterie al 100% (il che non è un bene), e continuano a ricaricarle non appena scendono al di sotto di un certo livello per mantenerle completamente cariche. Per di più di solito un portatile connesso alla rete elettrica lavora in modalità performace la quale produce più calore.

Conservare la batteria ##

E' bene rimuovere la batteria se si lavora prevalentemente connessi alla rete elettrica. Bisogna però considerare che una batteria anche se non connessa continua a perdere lentamente la carica, che invece viene persa più velocemente se viene riposta al 100%. Perciò:

Riporre la batteria ad un livello di carica compreso tra il 40-60%.
Riponila in un posto freddo e asciutto, meglio se intorno ai 0°C. Per esempio in un frigorifero, avvolta in della plastica.
Ricalibra la batteria ogni 30 giorni circa. Ma farla tornare a temperatura ambiente prima di montarla.

In breve

In breve, ecco cosa tenere presente per allungare la vita della propria batteria:

Assicurarsi che il laptop sia ben areato.
Mantenere il livello di carica della batteria tra 20-80% della sua capacità massima, assicurandosi di non effettuare lavori intensivi durante la ricarica.
Calibrare la batteria (ciclo completo di scarica-carica) ogni 30 cariche.
Se si utilizza il portatile prevalentemente connessi alla rete elettrica, rimuovere la batteria e riporla in un posto freddo e asciutto ad una temperatura di 0°C ed un livello di carica tra il 40-60%. Calibrare la batteria ogni 30 giorni.

Riferimenti

Discussione - Adozione dell'Agile

2009-11-09T00:00:00+00:00

Di seguito riporto qualche appunto sull'articolo Why Agile Adoption Fails in Some Organizations apparso su InfoQ il 4 Novembre 2009.

L'agile presuppone che l'organizzazione finanzi il team e che lo sviluppo sia un'attività continuativa e considerata come un investimento. In questo contesto si riconosce l'inevitabile inaccuratezza delle stime iniziali e si procede in modo iterativo e incrementale, accumulando esperienza e imparando a prevedere le tempistiche mano a mano che si avanza con lo sviluppo. In un team agile le stime sulle tempistiche hanno scarsa importanza e il team procede a produrre valore in modo continuativo, ma non si sa con precisione a priori quanto tempo ci vorrà per completarlo.

In uno scenario diverso in cui l'organizzazione finanzia separatamente i singoli progetti, che sono visti come un costo, il management richiede delle stime sui tempi e non è disposto a finanziarlo oltre i tempi preventivati. In questo contesto, a differenza del caso precedente, si hanno dei problemi se la stima iniziale non si rivela corretta e il management è costretto a una scelta:

Modificare i piani e riducendo lo scope del progetto.
Oppure ottenere un ROI negativo (il progetto va in perdita).

Le principali cause del fallimento nell'adozione di uno stile agile di sviluppo possono essere riassunte nei seguenti punti:

L'Agile assume che l'organizzazione voglia uno sforzo di sviluppo continuativo, non un progetto a breve termine. L'agile presuppone un finanziamento a team, non a progetto. In altre parole questo approccio presuppone che non ci siano vincoli di budget sul singolo progetto.
L'Agile è una metodologia che influenza sia il management che il processo di sviluppo: ci sono ripercussioni sia nelle pratiche adottate dal team, sia nella gestione (pianificazione e costi) del progetto stesso. Il management e il processo di sviluppo sono interrelati e qualsiasi metodologia influenza entrambi.

Date queste considerazioni, i progetti a costo fisso sono chiaramente un contesto inadatto nel quale collocare l'Agile. Spesso le aziende che ci provano finiscono per sovrapporre un façade agile su un progetto che in realtà è condotto in stile Waterfall.

In ultima analisi, se l'organizzazione è in grado di finanziare un team di sviluppo in modo continuativo, allora l'agile è un approccio vincente. Se invece i fondi sono allocati per progetto, un approccio più tradizionale è la scelta obbligata.

Discussione

Di seguito riassumo i contributi espressi nei commenti all'articolo da alcuni lettori:

Si assume che un approccio waterfall abbia successo quasi automaticamente in un progetto a costo fisso, quando in realtà è vero l'opposto. Con un cliente che sappia prioritizzare i propri requisiti efficacemente l'agile è un approccio utilizzabile anche in quel caso.
Occorre scegliere la metodologia di sviluppo in base ai requisiti e al contesto: se i requisiti non sono chiari fin dall'inizio e c'è rischio importante che cambino, allora un approccio agile è quasi obbligatorio. Una volta scelto l'approccio più adatto si sceglie la forma contrattuale consona. Le decisioni sulla conduzione del progetto vanno prese in modo pragmatico che rifletta le reali esigenze.

Perhaps we need to start asking, "how much can we get for $X" rather than stating, "I want all this for $Y. Make that happen." -- Robert Dempsey

I metodi agili hanno l'obiettivo di massimizzare l'efficienza, la produttività e il business value realizzato indipendentemente dal budget quindi sono ugualmente applicabili in un progetto a costo fisso. Inoltre, con l'avanzare del progetto e specialmente con l'acquisizione di competenze da parte del team diventa possibile stimare con sempre maggior precisione i tempi richiesti. Ovviamente, in un progetto a costo fisso è ancora più importante avere un team con esperienza e un cliente in grado di prioritizzare le features.

Commenti personali

Innanzitutto l'approccio agile (iterativo e incrementale) comporta importanti vantaggi per tutte le parti coinvolte (clienti, management, sviluppatori), ed è utile educarle tutte sui suoi vantaggi.

Inoltre, data la natura dell'agile (focus su efficienza e qualità) è applicabile anche in un contesto a costo fisso secondo me. Però qualsiasi progetto a costo fisso comporta un rischio sostenibile solo in questi casi:

I requisiti sono chiari fin dall'inizio, sono immutabili e il team è composto da esperti che hanno già affrontato progetti nello stesso dominio applicativo. Solo in questo caso è possibile fare una stima ragionevolmente precisa e adottare un ciclo di vita di tipo sequenziale (Waterfall) con un certo successo.
Lo scope è variabile. In questo caso l'approccio agile continua a essere il più conveniente.

Scelta pragmatica

La scelta della metodologia di sviluppo va fatta in modo pragmatico a seconda del contesto (progetto, dominio applicativo, cliente, team, ecc), non c'è un approccio universalmente migliore (Silver Bullet).

La scelta va fatta anche in base ai parametri che si vuole ottimizzare: costi, tempi, scope e qualità. E' evidente che il fissare tutti questi parametri a priori è praticamente impossibile, allora occorre trovare la combinazione più conveniente per le parti in causa. Fissando la qualità come un parametro imprescindibile e considerando che costi e tempi sono strettamente connessi, individuo i seguenti casi interessanti:

Tempo	Costo	Scope	Commento
fisso	fisso	fisso	Praticamente impossibile.
fisso	fisso	variabile	Sicurezza sui costi ma scope variabile.
variabile	fisso	fisso	Alto rischio di ROI negativo.
variabile	variabile	fisso	Scenario ideale per l'applicazione dell'Agile.
variabile	variabile	variabile	Efficiente con l'Agile.

Forse dobbiamo cominciare a domandare "quanto posso avere per X$" invece che affermare "voglio tutto questo per X$. Fatelo." --Robert Dempsey

Alla luce di queste considerazioni, a meno che non si tratti di un progetto a requisiti completamente specificati e immutabili, e condotto da un team esperto nel dominio applicativo, conviene adottare un approccio agile negoziando la forma contrattuale più adatta.

The Agile Coach

2009-11-06T00:00:00+00:00

Attualmente sto lavorando come una sorta di "Agile Coach" all'interno di un'azienda nell'ambito di uno stage, e mi sono ritrovato a studiare molto materiale al riguardo. In questo post ho annotato i punti più importanti dal mio punto di vista leggendo l'articolo The Agile Coach sul numero di Novembre di "PragPub":

Il compito dell' agile coach è quello di aiutare il team a incrementare le proprie performance e ottenere i benefici dei principi dell'agile. Il modo in cui questo viene fatto è guidando il team ad essere più consapevole del proprio workflow e di modi più efficienti di collaborare. Un buon coach deve essere in grado di insegnare come applicare le tecniche agili e di aiutare il team ad acquisirne competenza.
Il coach può essere anche un membro del team, ma le responsabilità nel progetto possono distrarlo dal suo compito (coaching del team). Perciò un coach preferibilmente non ha un ruolo attivo nel progetto a cui lavora il suo team.
Le doti e i requisiti necessari per un agile coach sono: ** Passione per l'Agile. ** Esperienza nell'applicarne le pratiche e i principi. ** Abilità interpersonali: comunicazione, lavoro di squadra, ecc. ** Abilità di problem-solving. ** Pragmaticità. ** Umiltà.
L'approccio di planning conviene rimanga semplice: preferibilmente una lavagna fisica sul posto di lavoro. Per team distribuiti in genere usare fogli di calcolo e wiki è sufficiente, il software di ALM (Agile Lifecycle Management) porta facilmente a piani iper-complicati. Su questo punto non sono molto d'accordo: un buon software è essenzialmente una lavagna virtuale con molte funzionalità aggiuntive che permette di semplificare molto la gestione di un progetto al punto di potersi quasi "dimenticare" del planning. Comunque mi manca esperienza in questo, vedrò.
Avere il cliente spesso a disposizione è di essenziale importanza per il successo del progetto e uno dei compiti del coach è quello di aiutare a costruire una relazione stretta tra il team di sviluppo e il committente creando un senso di impegno condiviso.
Se l'organizzazione non è convinta e non è consapevole di cosa significhi veramente essere agile, conviene cominciare con l'educarla da questo.
E' importante, come coach, supportare la transizione all' agile e incoraggiare un atteggiamento di sperimentazione e apprendimento continuo.

Wiki Creole mode for Emacs

2009-11-03T00:00:00+00:00

I needed a syntax highlighting support for the wiki Creole syntax in Emacs, but I couldn't find it anywhere... until I found the dot.emacs configuration file of Alex Schroeder of emacswiki fame, which contains a little wonderful elisp snippet that I show you (a little bit modified) here:

;; WikiCreole mode (wiki-mode)
;; Thanks to Alex Schroeder of www.emacswiki.org 
;; And Jason Blevins for his inspiring Markdown Mode
;; http://jblevins.org/projects/markdown-mode/
(define-generic-mode 'wiki-mode 
  nil ; comments 
  nil; keywords 
  '(("^\\(= \\)\\(.*?\\)\\($\\| =$\\)" . 'info-title-1)
    ("^\\(== \\)\\(.*?\\)\\($\\| ==$\\)" . 'info-title-2)
    ("^\\(=== \\)\\(.*?\\)\\($\\| ===$\\)" . 'info-title-3)
    ("^\\(====+ \\)\\(.*?\\)\\($\\| ====+$\\)" . 'info-title-4) 
    ("\\[\\[.*?\\]\\]" . 'link)
    ("\\[.*\\]" . 'link)
    ("\\[b\\].*?\\[/b\\]" . 'bold)
    ("\\[i\\].*?\\[/i\\]" . 'italic)
    ("\\*\\*.*?\\*\\*" . 'bold)
    ("\\*.*?\\*" . 'bold)
    ("\\_<//.*?//" . 'italic)
    ("\\_</.*?/" . 'italic)
    ("__.*?__" . 'italic)
    ("_.*?_" . 'underline)
    ("|+=?" . font-lock-string-face)
    ("\\\\\\\\[ \t]+" . font-lock-warning-face)) ; font-lock list
  '(".wiki\\'"); auto-mode-alist
  '((lambda () (require 'info) (require 'goto-addr))); function-list
  "Wiki stuff including Creole Markup and BBCode.")

Just copy this snippet in your .emacs and any file "*.wiki" will be highlighted correctly. You can also enable this mode from within emacs by: M-x wiki-mode.

I've adapted it a little bit and stealed some regexps from Jason's markdown-mode for highligthing titles. But there is still something missing:

Highlighting of lists
Support for images
Better highlithing of external links
Some functions for preview maybe?

Further versions of this mode will be updated here.

Enjoy :)

Come fare una presentazione

2009-11-03T00:00:00+00:00

Con tutta probabilità sei già stato vittima di presentazioni noiose e confusionarie, esposte da esperti in materia che nonostante tutti i tuoi eroici sforzi sono riusciti a farti addormentare.... E questo non è necessariamente dovuto all'oggetto dell'esposizione, infatti persino gli argomenti più noiosi possono essere resi avvincenti e interessanti da un buon speaker.

Fare una presentazione o insegnare in generale è molto di più che essere degli esperti nella materia. Occorrono delle competenze differenti per presentare informazioni in modo corretto: si devono sviluppare le capacità di comunicazione.

"Presentation skills are worthy of extreme obsessive study." --Tom Peters, Management guru

"Presentation is the 'Killer Skill' we take into the real world. It's almost an unfair advantage." --The McKinsey Mind

Ottima presentazione = conoscenze + comunicazione

Sommario

Obiettivo delle presentazioni
Sull'uso delle slide
Preparazione: Audience, Tema, Struttura, Pratica, Slide
Delivery: Apertura, Talk (show), Chiusura
Infrangere le regole
Conclusioni
Fonti

Obiettivo delle presentazioni

Prima di imbarcarsi in qualsiasi impresa, occorre conoscerne la ragione. Lo stesso vale per una presentazione:

Qual'è l'obiettivo del talk?
Che cosa voglio che il pubblico apprenda?

Troppo spesso invece si comincia subito a preparare l'esposizione senza alcuna idea di partenza di dove si andrà a parare. Conoscere l'obiettivo di una presentazione è indispensabile per esprimere con efficacia il messaggio principale e per preparare un discorso con un suo filo logico.

Ci sono ben poche cose più noiose di un elenco disordinato di fatti. Una vera presentazione non è un semplice elenco di dati, altrimenti sarebbe più conveniente scrivere un articolo. La ragion d'essere delle presentazioni è il dialogo e l'interpretazione di tali dati. La gente è in grado di leggere, e il motivo per cui si scomoda ad assistere ad un talk è per conoscere il significato e per vedere come questo possa prendere vita. Se ci sono dei dati importanti (grafici, tabelle, fonti, ecc) può essere più conveniente scriverle in un documento apposito e renderlo disponibile agli interessati.

Ma il primo e più importante valore che uno speaker deve tenere sempre a mente è il rispetto: rispetto per l'audiece e per sè stessi. Troppo spesso invece gli speaker dimostrano un'insensibilità totale verso il pubblico, esponendo gli argomenti in modo confuso, incomprensibile e noioso, e subissando gli ascoltatori con aridi e lunghi elenchi puntati nello sforzo di fare bella figura e dimostrare di "sapere".

The deepest human need is the need to be appreciated. (William James)

E' essenziale riconoscere al pubblico il rispetto che merita il suo tempo e la sua attenzione, veicolando le informazioni in modo conciso, chiaro e interessante. Si deve essere disposti a sacrificare alcuni dettagli per presentare l'argomento in modo corretto all'audience. E' questo l'obiettivo di ogni buona presentazione.

The presentation isn’t about you, it’s about your material.

Per avere un'idea di come sono delle presentazione fatte veramente bene:

Vedere su YouTube le presentazioni di: Seth Godin, Tom Peters, Guy Kawasaki, Steve Jobs e Dick Hardt.
Guardare le presentazioni di alcuni dei "maghi" su TED.com, ad esempio: Rives, Hans Rosling, Barnett Thomas, Lawrence Lessig e Ken Robinson.
Se si ha occasione, assistere a qualche talk di Damian Conway.
Vai su Common Craft a dare un'occhiata ai loro tutorial "plain English" sul Web 2.0

Sull'uso delle slide

L'uso di slide (lucidi) è diventato ormai sinonimo di presentazione in molti campi, tanto che la stragrande maggioranza si cimenta nel realizzare questi ausili senza pensarci un istante. Il problema, soprattutto con slide contenenti molto materiale, è che ad un certo punto o la gente legge le slide e non segue più lo speaker (a quel punto converrebbe scrivere un semplice articolo), oppure ascolta lo speaker e non guarda nemmeno le slide (in questo caso non servono neppure).

"Replace Powerpoint with directness and enthusiasm."

Ripensando all'obiettivo della presentazione e al contesto, occorre invece essere pragmatici e riflettere sull'utilità delle slide: il principale asset e contenuto di un talk è... l'esposizione di un'argomento dal vivo e dalla voce dello speaker. Le slide sono sono un ausilio che può essere utile in alcuni casi. L'esposizione è qualcosa di dinamico, di vivo. Se il pubblico volesse leggere una lista di punti proiettati su uno schermo andrebbe semplicemente a leggersi un libro o un articolo su internet.

PRIMA viene il discorso, DOPO (eventualmente) gli ausili visivi.

Alcuni realizzano delle slide per sentirsi più sicuri durante l'esposizione, ma i lucidi non possono essere un sostituto per la conoscenza dell'argomento che si presenta. O lo si conosce o non lo si conosce. Usare le slide come "stampelle" è la ragione sbagliata per propinarle e una chiara indicazione del bisogno di fare più pratica. Un argomento lo si conosce e lo si comprende veramente solo quando si è in grado di spiegarlo senza alcun ausilio.

Perciò se devi preparare una presentazione, poniti prima questa domanda: posso fare a meno delle slide?

Prima di tutto è necessario avere ben chiaro in mente:

L'obiettivo.
Il messaggio.
L'audience.

L'uso degli strumenti adatti viene di conseguenza.

"Focus on your purpose, your message and your audience and you won’t go far wrong. Once you are clear on those, the details of tools and delivery will become apparent." --Rowan Manahan

Per un esempio di come è possibile fare una presentazione memorabile senza usare nessuna slide, vedere il talk di Sir Ken Robinson. Inoltre, per un uso creativo e molto visuale delle slide per sottolineare l'esposizione vedere lo stile Takahashi orginale e le sue variazioni che usano anche immagini, come ad esempio la presentazione di Kent Beck sul Responsive Design.

Vediamo ora alcuni suggerimenti su come preparare e effettuare una buona presentazione.

Preparazione

Il suggerimento più importante sulla preparazione di una presentazione è quello di preparala lontano dal PC (e da PowerPoint). Una volta chiaro l'obiettivo, esporre a voce alta in modalità "freestyle" provando vari approcci e annotando idee, frasi e pensieri importanti. Dopo aver steso l'ossatura della presentazione, scriverla su carta (come minimo sotto forma di outline o mappa mentale). Solo dopo si può considerare se servono slide o meno.

Presentazione = discorso

Un passo importante che molti non considerano è che un pezzo scritto prima di raggiungere la sua forma definitiva viene modificato molte volte. Lo stesso vale per i discorsi: per renderli concisi ma evocativi e memorabili è necessario scriverli e perfezionarli esercitandosi molto nell'esposizione. E' così che i grandi discorsi sono stati creati e hanno potuto esercitare un impatto enorme sulle generazioni a venire: vedi Martin Luther King, Lincoln, Ghandi...

Uno dei più grandi "presentatori" contemporanei, Damian Conway, raccomanda un minimo di 10 ore di preparazione per ogni ora di presentazione (20 se l'argomento è relativamente ostico). Questo ovviamente se si vuole fare un talk memorabile...

E' anche utile preparare almeno un piano di backup per non essere colti impreparati dalle evenienze.

Inoltre, tenere presente che il modo migliore di illustrare certi concetti è attraverso delle dimostrazioni. Inserirne il più possibile.

Demonstrations beat descriptions.

Audience

Informarsi sull'audience. Quali sono i suoi interessi, lo stato d'animo, i bisogni e le aspettative?
Quanto tempo si ha a disposizione?

E' importante capire con chi si ha a che fare per veicolare il messaggio nel modo più efficace ed efficiente possibile. Vedere anche un mio precendente post.

Tema

Identificare la singola idea chiave che si vuole comunicare con la presentazione e focalizzarsi su quella. E' più facile lasciare il segno quando il punto importante è uno piuttosto che una collezione di fatti blandamente correlati.

L'idea centrale costituisce il tema della presentazione. Una volta identificato, raccogliere citazioni, aneddoti, fatti a supporto e organizzarli per costruire una storia attorno ad esso.

Per talk più articolati, possono esserci più idee chiave che si vuole trasmettere, ma è bene non andare mai oltre le 3-5. Avere più di 5 messaggi principali rende difficile seguire il discorso e conservarne qualche memoria.

Struttura

La presentazione deve avere una struttura lineare, semplice, chiara e facile da seguire. Qualunque sia la tipologia dell'esposizione, la sequenza di elementi deve avere una struttura logica coerente.

"Bad storytelling is beginning, muddle, end." --Philip Larkin

Gli esseri umani amano e trovano più semplice seguire ragionamenti lineari, e tale deve essere la presentazione: una sequenza lineare, logica e concisa di dati, informazioni e aneddoti correlati. Bisogna resistere alla tentazione di farcire il talk di dati per dimostrare la propria conoscenza (ma non il proprio rispetto). Quasi invariabilmente si è spinti a inserire troppo materiale, conviene quindi distillare la presentazione in modo quasi "brutale" eliminando tutto quanto non è essenziale (il tempo è qualcosa di prezioso, non va sprecato).

"La semplicità è la sofisticazione ultima." --Leonardo Da Vinci

Aiuta avere buone doti di storytelling, ma in ogni caso il talk deve avere un inizio, uno svolgimento (possibilmente che porta ad un climax) e una conclusione che lasci il segno.

Il workflow potrebbe essere:

Identificare i punti rilevanti per l'audience.
Metterli nell'ordine più interessante per il pubblico.
Fornire il contesto necessario.
Arricchire con elementi di teatralità.
Distillare ulteriormente.

La perfezione si raggiunge attraverso la quotidiana diminuzione, non aumento.

Per esempio, per una presentazione incentrata su una soluzione ad un problema:

Illustrare le cause del problema che affligge l'audience.
Mostrare perchè è serio.
Proporre una soluzione.
Sommario e "chiamata alle armi", riassumendo chiaramente cosa bisogna fare.

E' molto utile illustrare questa struttura all'inizio della presentazione per dare un'idea di cosa tratterà il talk e come.

Pratica

Una volta costruita la presentazione: fare pratica, pratica e ancora pratica. Preferibilmente ad alta voce. Sperimentare spostando concetti, eliminando quelli superflui e modificando la presentazione in modo che sia ben coesa e comunichi efficacemente l'idea centrale. Possibilmente avendo qualcuno in carne ed ossa che ascolta e fornisce feedback. Inoltre fare attenzione che si rientri nei tempi. E' molto importante praticare la presentazione, per poi poterla esporre con sicurezza e padronanda davanti al pubblico. Non occorre memorizzare tutto il talk, basta ricordarsi i punti fondamentali, gli accessori verranno con naturalezza se si conosce bene la materia e si è fatta abbastanza pratica.

"The only way to speak better is to speak." --Damian Conway

La pratica è essenziale, non basta preparare un discorso sulla carta. Come gli speaker esperti e gli attori ben sanno, lo scritto e il parlato sono due veicoli di espressione abbastanza diversi e ciò che è scritto spesso non ha lo stesso effetto quando viene letto ad alta voce. Lo stesso dicasi per l'inverso. Il lavorare al discorso sia in forma scritta che parlata (e praticandolo) permette di chiarire il messaggio essenziale ed "editarlo" in modo da renderlo ad alto impatto.

Slide

Come descritto le slide non sono indispensabili per una presentazione, ma se dopo ever preparato il materiale si decide di utilizzarle, tanto vale renderle memoriabili.

"Great content is a necessary condition, but not a sufficient one." --Garr Reynolds

Data la facilità disarmante nel realizzarne di irritanti e inutili, il modo migliore per rendere delle slide attraenti è essere consapevole che sono un ausilio, uno strumento il cui compito è quello di sottolineare ed enfatizzare i punti importanti, non di distrarre il pubblico costringendolo a leggere decine e decine di parole. Inquadrare le slide come uno strumento poi, permette di utilizzarle in modo creativo per sorprendere, mantenere l'attenzione e fissare i concetti.

"Nothing in your slide should be superfluous, ever." --Garr Reynolds

Il criterio più importante da tenere a mente nella realizzazione di slide è: semplicità e stile. Vedere come esempio le slide di: Apple, Bang & Olufsen, The Perl Journal, ecc.

"Your slides, if you choose to use them, should not be textual orgies. Use visual shorthand." --Chris Brogan

Un grande errore compiuto da molti è quello di pensare alle slide come ad un documento a sè stante: così facendo però realizzano un documento in un formato adatto ad essere presentato su uno schermo, non dei lucidi. Ma semplicemente questo non è l'uso per cui le slide sono state inventate e di certo non è quello migliore nel contesto di una presentazione. Le slide non sono la presentazione, sono solo le illustrazioni.

Le slide NON SONO la presentazione.

In quest'ottica, impiegare poche parole ed eventualmente delle immagini significative. L'uso delle immagini delle slide ha un grande potere: rende possibile coinvolgere il pubblico anche emotivamente e ne stimola l'immaginazione aiutando a mantenere desta l'attenzione e migliorare la memoria di quello che viene detto.

L'approccio risulta ancora più potente se si scelgono immagini significative che rappresentano una metafora (meglio se divertente) dei concetti presentati.

Un'immagine vale più di mille parole.

Inoltre, sorprendere l'audience. E' un altro modo per creare un'esperienza emozionante che verrà ricordata.

Flusso di informazioni

Se si decide di utilizzare delle slide come ausilio, bisogna controllare il flusso di informazioni in modo che il talk e i lucidi restino in sincrono.

Quando ad esempio si vogliono elencare una serie di punti, il mostrarli tutti contemporaneamente in un'unica slide mentre si parla, significa fare in modo che l'audience li legga tutti e aspetti che vengano trattati cercando di collegare ciò che è scritto a ciò che viene detto. Questo a scapito dell'attenzione. E' più opportuno in questo caso mostrare un punto alla volta.

Allo stesso modo, se si vuole presentare un grafico, per prima cosa occorre spiegare i dati e il significato prima di mostrarlo nella slide successiva, in modo che a quel punto gli ascoltatori siano in grado di interpretarlo subito. Tra l'altro, il mostrare il grafico dopo averlo spiegato può aiutare anche a creare anticipazione e innalzare l'interesse.

Design

E' importante che le slide siano leggibili e rispettino delle buone linee guida tipografiche. Se c'è qualcosa di peggio di slide mal realizzate, sono slide mal realizzate e illeggibili. Ecco le linee guida più importanti:

Semplicità e stile!
Attenzione al contrasto: colori complementari. Sfondo chiaro, testo scuro. Sfondo scuro, testo chiaro. Chiaro?
Allineare il testo a destra o a sinistra: l'allineamento centrale è poco professionale, amatoriale e meno leggibile.
Andare all'essenziale: Un titolo, qualche punto e al massimo un'immagine. Avere troppi elementi rende difficile "decodificare" la pagina ed è stressante. La cosa migliore è inserire poche parole con un font di dimensione molto grande.
Usare font della famiglia Serif per il corpo: sono i font che rendono meglio su schermo.
Limitare l'uso di font decorativi ai titoli e solo se sono leggibili.
Evitare di inserire il logo in ogni slide. Non si vuole dare l'impressione di essere dei venditori.
Limitare l'uso di effetti di transizione, possibilmente non usarne nessuno: distraggono e basta. Non essere esibizionista.

Delivery

Presentare qualcosa è più di una semplice recitazione di fatti. Si tratta di una vera e propria esibizione comprendente elementi teatrali e di drammaticità. Bisogna imparare a comunicare con efficacia usando non solo le parole ma anche il linguaggio del corpo, il giusto ritmo, le emozioni, la consapevolezza dell'audience e di come questi elementi li influenzino. Ogni presentazione è una performace finalizzata all'intrattenere il pubblico in modo che al termine ne esca arricchito (possibilmente di quello che si aspettava, meglio se di più).

Entertaining always trumps informative.

Se possibile, arrivare prima dell'inizio del talk e preparare tutto prima che il pubblico giunga in sala. Non è molto professionale armeggiare con il proiettore e il portatile mentre l'audience aspetta... Prepararsi per tempo in modo da essere pronti, sicuri che tutto funziona e (relativamente) rilassati quando arriva l'ora di iniziare.

Una piccola nota: vestirsi in modo consono all'occasione e all'audience. Ovvio, ma meglio precisarlo...

Apertura

E' normale essere un pò nervosi prima di cominciare un'esposizione. Le cose importanti sono fare molta pratica e iniziare la presentazione con entusiasmo e sicurezza. Ad esempio, per rompere il ghiaccio si può:

Porre una domanda.
Sfidare l'audience.
Citare una persona famosa.
Raccontare una storia divertente.
Raccontare un fatto interessante.
Proporre una visione grandiosa (e poi proporre come farla avverare)
Proporre una visione spaventosa (e poi parlare di come non farla realizzare)

In altre parole basta cominciare il talk con qualcosa di interessante che catturi l'attenzione.

Talk (show)

Di seguito qualche suggerimento su come condurre al meglio la performace:

Muoversi e guardare le persone negli occhi. Usare il linguaggio del corpo per sottolineare certi punti è utile, ma senza esagerare: non è una prestazione sportiva!
Non recitare i punti a memoria o peggio leggere le slide. Bisogna avere rispetto per il tempo degli altri e dato che catturare l'attenzione non è affatto semplice, una volta che la si ha va gestita correttamente. Si deve conoscere bene ciò che si presenta, e questo significa essere in grado di illustrarlo senza che siano necessari ausili esterni.
Usare un tono di voce chiaro, parlare lentamente e variare spesso il ritmo. Bisogna parlare in modo da essere sentiti, chiaramente e ancora una volta portando rispetto verso il pubblico evitando di annoiarlo a morte con un tono di voce costante e noioso (soporiferio). Spesso i novizi durante i talk parlano troppo velocemente: rallentare deliberatamente.
- Evitare i "filler", ovvero cose come: "cioè, uhm, eh" ecc. Denotano insicurezza.
Raccontare una storia. Anche se inventata, è utile per intrattenere e mantenere viva l'attenzione. Ovviamente che sia in qualche modo rilevante all'argomento oggetto della presentazione. Può essere utile anche mischiarla con delle metafore utili ad illustrare certi concetti e relazioni. Inutile dire che l'effetto è migliore se la storia è divertente.
Usare la retorica per essere incisivi e memorabili. Praticare ad esempio con: contrasto, lista dei tre e soprattutto la pausa. Fare una pausa prima di esporre un punto importante crea anticipazione e drammaticità: un momento teatrale che mantiene l'attenzione.
Se ci si dimentica qualcosa, andare avanti con la presentazione senza scusarsi o fermarsi per cercare di ricordare. Se l'esposizione veicola il messaggio principale, allora è ok.
Emozionare. E' uno dei modi principali e più efficaci per mantenere l'attenzione e far arrivare i concetti a destinazione. Con un pò di pratica diventa facile visto che qualsiasi argomento può essere trattato dal punto di vista umano.
E' utile anche raccontare aneddoti (soprattutto se personali), umorismo e storie. Un tocco personale può aiutare molto a rendere una presentazione autentica e interessante.
ENTUSIASMO! L'entusiasmo è contagioso. La presentazione deve essere colma di passione, deve prendere vita e catturare l'attenzione del pubblico facendo perdere al tempo il suo significato.
Creare una sensazione di intimità con il pubblico: dare l'impressione di essere lì per loro e di conoscerli trattandoli come amici. L'atmosfera dovrebbe essere rilassata e amichevole.
Eventualmente coinvolgere il pubblico trasformando la presentazione in una discussione interattiva. Invitare a fare commenti e portare contributi personali. Chiaramente è possibile solo per chi conosce veramente quello di cui sta parlando ed è in grado di gestire una discussione, diversamente avrà paura di essere colto in fallo. Comunque tutto dipende dal pubblico e dalla natura dell'argomento: non sempre l'oggetto del talk si presta ad una discussione interattiva e a volte l'audience preferisce non essere chiamata in causa.

"Humans want to connect. They are built to want to belong. A great presentation is a fire to gather around and share an experience." --Chris Brogan

Per quanto riguarda le domande, è opportuno avere una policy per dove, come e quando accettare domande da condividere con il pubblico. Se non si conosce qualche risposta si può reagire in modo diverso a seconda della situazione:

"Non conosco la risposta mi dispiace."
Redirigere la domanda a chi può avere la risposta.
"Ora non so risponderti, non appena conoscerò la risposta la scriverò sul mio blog."

Presentazione memorabile = informazioni + intrattenimento

Chiusura

E' importante chiudere la presentazione con un sommario che ricapitola i punti principali e un'ultima, chiara ripetizione del messaggio chiave.

"In the beginning, tell the audience what you're going to tell them. Then tell them, and be sure to leave time at the end to tell them what you told them. It sounds simple, but it works and they will appreciate it." --Lehr, J.H

Il pubblico deve avere la sensazione di aver ottenuto qualcosa dalla presentazione e deve avere delle informazioni pronte all'uso.

Infrangere le regole

Tutto quello che ho illustrato sono consigli e linee guida, ma tutte le regole possono essere infrante e a volte devono esserlo: le interazioni umane sono qualcosa di troppo complesso e dinamico da poter essere gestito da un insieme di regole ferree seguite senza usare la testa.

Sia un principiante che un esperto possono non rispettarne qualcuna, la differenza sta nella conoscenza: l'esperto conosce le regole che infrange e sa spiegare il perchè lo fa, un principiante semplicemente no.

Per infrangere efficacemente le regole bisogna prima conoscerle.

Conclusioni

Ricapitoliamo i punti importanti:

Un buon discorso è intrattenimento e informazioni. Bisogna imparare a comunicare.
Per fare una buona presentazione è essenziale una estensiva preparazione che va fatta lontano dal PC.
Ogni presentazione deve presentare 1-5 idee chiave e organizzare un discorso lineare, logico e conciso attorno ad esse.
Una presentazione è essenzialmente un discorso, le slide sono un accessorio non necessario. Se vengono realizzare, che siano fatte con semplicità e stile.
Ogni presentazione deve essere un'esibizione colma di entusiasmo e in grado di appassionare l'audience. Imparare ad esibirsi e a creare un'atmosfera intima sono ingredienti fondamentali delle presentazioni memoriabili.
All'inizio anticipare quello di cui si parlerà e alla fine dell'esposizione ricapitolare i messaggi importanti.
Se possibile, dare precedenza alle dimostrazioni piuttosto che alle descrizioni.

Approfondimenti

User Stories Applied, capitolo 2

2009-10-30T00:00:00+00:00

Continua l'esplorazione della tecnica delle user stories.

Per capire meglio che cosa sono le user stories bisogna capire cosa non sono mettendole in contrasto con le altre tecniche di raccolta dei requisiti (use cases, specifiche dei requisiti software IEEE 830 e interactive design scenarios).

IEEE 830

Lo standard IEEE 830 documenta un modo di esprimere le specifiche di un software, principalmente attraverso una gerarchia di requisiti nella forma "Il sistema dove...". Un esempio:

4-6) The system shall allow a room to be reserved with a credit card. 4-6-1) The system shall accept Visa, MasterCard and American Express cards. 4-6-2) The system shall charge the credit card the indicated rate for all nights of the stay before the reservation is confirmed. 4-6-3) The system shall give the user a unique confirmation number.

Specifiche a questo livello di dettaglio sono tediose, prone a errori e molto costose in termini di tempo. Per sistemi di media grandezza non sono rari documenti di specifica di 300 pagine... estremamente noiose. la conseguenza è che in realtà gli sviluppatori li guardano appena, ma senza leggerli approfonditamente.
Documenti di questo tipo spingono a pensare ai dettagli implementativi ma rendono molto difficile avere una visione d'insieme.
Non importa quanto impegno si mette nel documentare fin nei minimi particolari le caratteristiche del sistema. Non appena l'utente ha di fronte il software, quasi invariabilmente avrà idee diverse (e migliori).
Le specifiche in questa forma si concentrano sugli attributi del sistema invece che sulle esigenze dell'utente. Si viene spinti a considerare il documento di specifica come una "checklist" delle cose da realizzare, e quindi a dichiarare terminato un progetto quando tutti questi requisiti sono soddisfatti. E quando l'utente modifica le sue richieste, la cosa viene classificata come un cambiamento di scope. In realtà un softwarè veramente terminato quando l'utente è pienamente soddisfatto.

Use cases

In generale uno use case è una descrizione generalizzata dell'interazione tra il sistema e degli attori (che possono essere utenti o altri sistemi).

Uno use case in forma estesa contiene dettagli su un'interazione con in più dei "percorsi alternativi" che costituiscono degli scenari alternativi, in genere per gestire errori. In realtà uno use case esteso è praticamente equivalente ad una storia con i relativi test di accettazione (che prevedono anche i casi alternativi). Ma...
Le principali differenze sono la longevità, la completezza e lo scopo: mentre uno use case rappresenta un accordo tra l'utente e il team di sviluppo fatto per essere valido e normativo (a volte gli use case vengono considerati obblighi contrattuali) per tutta la durata del progetto, una storia rappresenta una conversazione da intrattenere con il cliente e usualmente è utilizzato principalmente ai fini di planning (release, iterazioni).
Gli use case, nella loro forma estesa, sono più soggetti ad essere utilizzati per contenere dettagli sull'interfaccia utente. Il che è chiaramente un male vista la volatilità del design di quest'ultima. Questo è un problema per cui Constantine e Lockwood hanno proposto una soluzione: essential use cases, ovvero una forma di use case ridotta contenente solo: intenzioni dell'utente e responsabilità del sistema, avvicinandoli molto alle storie.
Vista la volatilità dei requisiti software, organizzare un contratto attorno a requisiti a questo livello di dettaglio non fa altro che creare difficoltà: spinge a realizzare il software che l'utente ha chiesto, non quello di cui ha bisogno, infatti l'utente raramente ha le idee chiare fin dall'inizio su quello che vuole.

No matter how much thinking, thinking and thinking we do we can never fully specify a non-trivial system upfront.

Scenari di interazione

Uno scenario è in pratica una "storia" (non nel senso di user story) contenente contesto, attori, obiettivi, azioni ed eventi. Si tratta di una descrizione in forma discorsiva di un'interazione di attori umani in un particolare contesto che hanno determinati obiettivi.

Essendo una descrizione discorsiva e in forma di racconto, molti dettagli sono lasciati fuori percui è comunque necessaria una conversazione con il cliente per chiarirli.
Un singolo scenario ha uno scope decisamente maggiore di una storia, infatti da uno scenario tipico si possono ricavare diverse storie di solito.

User Stories Applied, cap. 1

2009-10-30T00:00:00+00:00

Inizio con questo post una tradizione alla Mark Needham nella quale i annoterò i punti salienti di libri, paper e presentazioni che mi ritroverò a visionare. Questo principalmente per il fatto che il modo migliore per imparare qualcosa (e sapere se lo si è capito realmente) è insegnarlo a qualcun altro.

Per esigenze di lavoro ho cominciato a documentarmi sul project management e alla raccolta di requisiti, principalmente in ambito Agile, e mi sono trovato in contatto con l'idea delle user stories. Il libro che mi sono procurato al riguardo e che sto leggendo attualmente è: "User Stories Applied" di Mike Cohn.

Cominciamo con il primo capitolo, intitolato "Groundwork".

Ciò che è espresso a parole può essere ambiguo e impreciso. Qualsiasi espressione scritta di requisiti lascerà qualcosa di ambiguo o imprecisato. Basti pensare a frasi come: "Deve essere possibile inserire password di 127 caratteri." Che cosa vuol dire possono? Significa che in certi casi non è necessario? E devono essere di 127 caratteri? Di più? E di meno? Scendendo sempre più nei particolari non migliora di molto la situazione, ci saranno sempre dei "punti ciechi" e dei particolari mancanti di cui ci si accorge solo durante lo svilupo. L'unica specifica veramente completa in ogni sua parte è il codice sorgente. Ma tutta questa confusione semplicemente scompare se si sposta il focus dallo scrivere i requisiti al parlarne.
Spesso i clienti che richiedono un certo software non hanno le idee chiare e non possono fornire requisiti chiari, stabili e completi fin dall'inizio. Di conseguenza anche se l'analista funzionale è estremamente preciso e diligente nello stilare use case estremamente completi, tutto questo lavoro potrebbe rivelarsi comunque incompleto o semplicemente inesatto rispetto le reali esigenze del committente. Una volta che il cliente ha qualcosa di funzionante sotto gli occhi sarà in posizione migliore di dire ciò di cui ha bisogno. Occorre evitare di fare il classico errore di realizzare ciò che il cliente chiede piuttosto che quello di cui ha bisogno.
Una user story (storia utente) non è altro che una piccola funzionalità che ha valore per l'utente finale. Tradizionalmente scritta su un cartoncino è una semplice frase che indica una funzionalità richiesta dal punto di vista dell'utente (quindi storie come "Deve essere realizzato in Java" non è una storia), dovrebbero essere abbastanza piccole da poter essere implementate nel giro di mezza giornata o pochi giorni da uno o due sviluppatori.
Quando una storia si rivela troppo grande (ad esempio "L'utente deve poter effettuare una prenotazione"), si definisce Epic e viene suddivisa in due o più storie più piccole.
Una storia, più che definire una funzionalità la rappresenta. Il modo corretto di pensare alle user stories: è come dei "promemoria" di una conversazione da fare con l'utente.
E' importante capire le aspettative dell'utente per ogni storia: annotare queste aspettative sotto forma di test di accettazione. L'obiettivo è stabilire dei criteri secondo i quali si potrà dichiarare una storia "completa". Anche qui non si tratta di essere subito precisi e completi, la precisione verrà raggiunta quando sarà il momento.
Secondo la definizione di Ron Jeffries, una storia è costituita da tre aspetti: Card, Conversation e Confirmation. Ovvero, la forma fisica della storia (index card), la conversazione che rappresenta e i test di accettazione per sapere quando è completa.

Behavioural-Driven Development

2009-08-30T00:00:00+00:00

Il Behavioural Driven Development (BDD) è essenzialmente il TDD fatto correttamente. Il problema è che troppo spesso il TDD è portato avanti in maniera scorretta, principalmente a causa dell'eccessivo focus sull'aspetto di testing.

Perchè Behaviour-Driven?

Come illustrato da Dan North, il TDD è un'ottimo stile di sviluppo ma è molto facile fraintenderlo focalizzandosi troppo sui test di unità creando un falso senso di sicurezza:

That’s not to say that testing isn’t intrinsic to TDD – the resulting set of methods is an effective way of ensuring your code works. However, if the methods do not comprehensively describe the behaviour of your system, then they are lulling you into a false sense of security.
--Dan North

Molte delle domande che possono sorgere nella mente di un principiante, ad esempio:

Che cosa devo testare?
Come chiamo questo test?
In che modo posso testare questa caratteristica?

Tutte queste domande, trovano "magicamente" una risposta quando si smette di pensare al testing e ci si focalizza sul comportamento che un sistema deve avere.

Ecco quindi che il BDD si configura prima di tutto come un "re-branding" del TDD (portato avanti tra gli altri da Dave Astels) e un mutamento di prospettiva per far "afferrare" più facilmente il modo corretto di operare con questa metodologia.

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.
--Dan North

Una conseguenza di questo approccio, è che non è più necessario nè raccomandato avere una classe di test per ogni classe di codice di produzione (ad esempio: Queue e QueueTest). Piuttosto di organizzare i "test" per classe interessata, si raggruppano le "specifiche di comportamento" in base alle fixture (o contesti) nei quali si trovano ad operare.

I Vantaggi

Enfatizzare il comportamento sul testing provoca un mutamento nel modo di pensare e produce alcuni vantaggi:

Si parte dai requisiti, dalle features da implementare invece che dalle singole classi. Si adotta quindi un approccio top-down che guida la progettazione in base alle caratteristiche richieste. Come conseguenza si aderisce naturalmente al principio YAGNI.
Si sottolinea l'aspetto di design
Si ottengono delle specifiche che hanno il vantaggio di essere eseguibili, e che quindi possono essere fatte girare contro la base di codice per verificarne l'aderenza ai requisiti fissati (ecco il testing)
Permettono lo sviluppo di un ubiquitous language (ovvero di un linguaggio comune tra gli sviluppatori, la parte business e il cliente), integrandosi con il DDD

Inoltre, seguendo la metodologia BDD si ottengono sia delle specifiche eseguibili (test funzionali e di sistema) sia dei test di unità (applicando la verifica del comportamento alle singole classi).

Strumenti

Trattandosi di TDD "fatto come si deve", è possibile utilizzare qualsiasi libreria che supporti il testing come l'onnipresente xUnit.

Tuttavia, sono stati sviluppati dei framework che incorporano in concetti del BDD sostituendo ad esempio le parole "test" con "behaviour" o "specification" ad esempio, e fornendo molte altre caratteristiche interessanti come DSL appositamente sviluppati (ad esempio usando groovy in easyb) o interfacce fluide (popolarizzate dal pioniere RSpec), e integrazione di librerie per il mocking come JMock.

Per Java, ho trovato questi framework più o meno utilizzabili:

JBehave2: dal "fondatore" stesso del BDD
Instinct
JDave

Sono tutti costruiti al di sopra di JUnit 4, possono quindi di essere fatti girare in un qualunque IDE (oltre che da CLI o Ant ovviamente).

Esperienza personale

Nel progetto di ingegneria del software a cui ho lavorato abbiamo utilizzato estensivamente l'approccio TDD, rispettando molto il rapporto 1-1 tra classi di test e di codice di produzione.

Non c'è stato molto focus sul comportamento del sistema nel suo insieme, e nemmeno nei test di integrazione e di sistema. Fortunatamente abbiamo fatto uno studio approfondito e un'attenta progettazione durante tutto il processo di sviluppo, facendo attenzione a modularizzare il più possibile (il TDD ha aiutato in questo senso) quindi l'integrazione non è stato un problema molto grave.

Probabilmente però, se fossimo partiti dal principio creando delle specifiche, e usandole per guidare lo sviluppo distribuendo la progettazione lungo il processo e realizzando il prodotto feature-per-feature creando una versione/demo rilasciabile dopo ogni iterazione, sarebbe stato molto meglio.

Update (26/10/2009)

Un paio di articolo di Naresh Jain chiariscono molto bene gli effetti e il significato del BDD:

Automazione!

2009-08-06T00:00:00+00:00

Una cosa risaputa è che un buon programmatore deve essere pigro. Ma di una pigrizia particolare: perchè svolgere a mano ogni compito ripetitivo che può essere svolto altrettanto bene e molto più velocemente da una macchina?

Nella mia situazione, complice anche il fatto che sto imparando Ruby, ho automatizzato diverse cose. In particolare, scrivo su un altro blog di sviluppo personale e per un certo periodo ho avuto un dominio apposito con un blog servito dal software Serendipity che dopo un anno di attività ho chiuso per ritornare a wordpress.

Purtroppo (mea culpa) non avevo effettuato il backup del vecchio blog se non tramite uno "snapshot" del sito, quindi mi sono ritrovato con circa un'ottantina di post sotto forma di file html che volevo importare su wordpress. Inutile dire che farlo a mano sarebbe stata un'impresa non da poco...

Così in un paio di giorni (e un paio di tentativi) ho implementato un programmino di tipo scraper che per ogni post salvato sotto forma di file html, ne estrae: post, titolo, data di pubblicazione e commenti con relative date, nomi ed eventuali link. Il tutto ripulendo il risultato da blocchi non necessari.

Con il primo tentativo ho usato estensivamente le espressioni regolari per identificare ed estrarre le aree desiderate, ma si è rivelato un compito abbastanza lungo e anche se alla fine funzionava per alcuni post c'erano dei problemi. Mi serviva una libreria che fosse a conoscenza dell'html e mi consentisse di farne il parsing.

Con il secondo tentativo, ho utilizzato una stupenda libreria che mi ha permesso di selezionare esattamente i contenuti desiderati e anche di effettuare modifiche: hpricot.

Risultato: una quindicina di minuti circa per postare sul blog originale circa 80 post con la data corretta e tutti i commenti!

Overloading in Ruby

2009-08-01T00:00:00+00:00

A differenza di linguaggi come Java e C++, Ruby non supporta direttamente l'overloading di metodi e costruttori. Il che è abbastanza grave quando si dimostra necessario disporre di più costruttori con un numero diverso di argomenti.

Una soluzione in certi casi potrebbe essere quella di usare un design-pattern come il factory method. In tutti gli altri, fortunatamente, è abbastanza semplice emulare l'overloading grazie al supporto di ruby alle liste di argomenti di lunghezza variabile.

Un esempio, tratto da rubylearning per chiarire il concetto:

# The Rectangle constructor accepts arguments in either  
# of the following forms:  
#   Rectangle.new([x_top, y_left], length, width)  
#   Rectangle.new([x_top, y_left], [x_bottom, y_right])  
class Rectangle
  def initialize(*args)
    if args.size < 2  || args.size > 3  
      # modify this to raise exception, later  
      puts 'This method takes either 2 or 3 arguments'  
    else  
      if args.size == 2  
        puts 'Two arguments'  
      else  
        puts 'Three arguments'  
      end  
    end  
  end
end

Rectangle.new([10, 23], 4, 10)
Rectangle.new([10, 23], [14, 13])

Integrazione Continua

2009-07-27T00:00:00+00:00

Terminato oggi un progetto di dimensioni importanti (con ottimi risultati), è tempo di fare una retrospettiva.

Nel nostro team abbiamo implementato uno stile di sviluppo test-driven, ma non abbiamo predisposto alcun server di build automatizzato. In principio, anche se interessante, sembrava ridondante... Abbiamo ugualmente portato a termine il progetto, ma se avessimo utilizzato una soluzione di questo tipo, avremmo avuto una serie di vantaggi:

Enforcing dell'approccio test-driven: nonostante fosse stato stabilito di scrivere i test prima e per ogni funzionalità, in qualche caso non si è rispettata questa decisione. Probabilmente un sistema che compilasse i sorgenti a ogni commit, che facesse girare tutti i test automaticamente e inviasse un'email a tutti in caso di errori sarebbe stato un aiuto in questo senso.
Pacchettizzazione: come ambiente di sviluppo abbiamo utilizzato Eclipse, che assolve egregiamente i suoi compiti compilando automaticamente i sorgenti ad ogni modifica (segnalando eventuali errori di compilazione) e fornendo un'interfaccia a JUnit per i test. Ma non abbiamo tenuto conto della pacchettizzazione del prodotto finito ("lo faremo alla fine quando sarà ora"). Chiaramente alla fine è stato fatto, ma se avessimo avuto un ciclo di vita evolutivo con un buon numero di piccole iterazioni e un server di build che si sarebbe occupato di creare una versione pacchettizzata pronta per essere distribuita ad ogni commit, la vita sarebbe stata molto più semplice. Se il deployment è continuo, è facile attuarlo. Se non lo è, allora probabilmente ci sono brutte sorprese all'orizzonte...

La lezione è stata imparata.

Update: 09/08/2009

Per approfondire il discorso sull'integrazione continua, è illuminante l'articolo di Martin Fowler.

Ruby - code blocks, coroutines e closures

2009-07-11T00:00:00+00:00

Ruby si ispira abbastanza al Perl (purtroppo, l'ho usato un po' ma non mi è mai piaciuto come linguaggio), ma nonostante questo mi sono sforzato di andare avanti a studiarlo. Uno è in grado di giudicare le potenzialità di un linguaggio solo conoscendolo e avendolo utilizzato, questo vale specialmente per quei linguaggi che forniscono features che non si conoscono e che richiedono un modo di pensare diverso.

Bisogna respingere la sensazione di "scomodità" che si prova all'inizio ed entrare nell'ottica giusta prima di poterne apprezzare le potenzialità ed esprimere un giudizio informato e non basato unicamente su simpatie/antipatie.

Un linguaggio molto dolce

Ruby, a differenza di Python e similmente al Perl, fornisce una gran quantità di zucchero sintattico che porta ad avere più modi diversi per fare una stessa cosa. Infatti molti "entusiasti" del linguaggio parlano spesso di come imparino sempre nuovi modi più eleganti, concisi ed espressivi per esprimere certi concetti (e questo, almeno nel caso del Perl, spesso a discapito della leggibilità).

Non so ancora se sia una cosa positiva o meno, su questo sospendo il giudizio in attesa di acquisire una conoscenza più approfondita.

Coroutines e code-blocks

Un paio di features interessanti che fornisce Ruby sono le coroutines e i code-blocks, che permettono (tra le altre cose) di implementare in maniera molto concisa ed espressiva degli iteratori e dei "blocchi di codice" da eseguire sotto un controllo transazionale.

In un linguaggio "tradizionale" come Java, per iterare sugli elementi di una classe collezione si può procede ad esempio così:

ArrayList<int> lista = new ArrayList<int>();
// ...
for (int i = 0; i < lista.size(); i++) {
    System.out.println(lista.get(i) + " ");
}

Questo modo di iterare su una collezione è familiare a chi è abituato ad usare linguaggi come C++, Java o anche Python.

Ruby, attraverso l'uso dei code-blocks, permette di iterare in modo diverso:

@lista = [1, 2, 3, 4]
@lista.each {|elemento| puts elemento}

Il che è anche abbastanza leggibile una volta fatta l'abitudine:

    lista: per ogni elemento, scrivilo sulla console

Cosa sono i code block e le coroutines?

Un code-block non è altro che un blocco di codice (incredibilmente), delimitato da parentesi graffe o da do-end che non viene eseguito immediatamente, ma viene messo da parte per essere eseguito in un secondo momento.

Questo code-block deve essere adiacente ad una chiamata a un metodo, la quale può cedere il controllo al code-block ogni volta che lo desidera tramite il costrutto yield tutte le volte che lo desidera, eventualmente passandogli parametri e ricevendone.

A tutti gli effetti il metodo e il code-block sono coroutines, ovvero funzioni che lavorano "insieme" passandosi la palla l'una con l'altra. La cosa interessante è che a un metodo che utilizza un code-block esterno, può essere passato un blocco qualunque di istruzioni. E' un concetto simile ma più potente e versatile dei puntatori a funzione del C.

Esempio: iteratori

3.times {puts "Hello, world!"}

Questo codice si legge:

    Per 3 volte: stampa la stringa "Hello, world!"

times è la chiamata all'omonimo metodo fornito dal numero 3 (essendo Ruby un linguaggio completamente ad oggetti, è un oggetto di tipo intero) a cui viene associato un code-block che effettua la stampa. Il metodo times non fa altro che richiamare tante volte yield quanto è il valore che rappresenta l'oggetto su cui viene richiamato il metodo.

Si può ottenere lo stesso effetto di prima con una funzione ad-hoc:

def call_block
    for i in 1..3
        yield
    end
end

call_block {puts "Hello, world!"}

Un code-block può ricevere parametri dalla routine da cui viene invocata tramite yield, e similmente riceverne al ritorno, trasformando yield in una vera e propria chiamata al code-block.

Inoltre, passando un parametro al code-block, possiamo implementare un iteratore per una classe collezione (analogo al metodo each del primo esempio) nel modo seguente:

class Collezione
    def initialize(lista)
        @collezione = lista
    end

    def each 
        for i in 0..@collezione.size
            yield(@collezione[i])
        end
    end
end

lista = Collezione.new([1, 2, 3, 4])
lista.each {|elemento| puts elemento}

Questo è più o meno il modo in cui sono implementati gli iteratori nella libreria standard di Ruby.

Diversamente da come illustrato nel design pattern Iterator della GOF, nel quale l'iteratore è una classe esterna all'oggetto su cui itera e di cui mantiene un riferimento, in Ruby un iteratore viene implementato come un semplice metodo all'interno della classe collezione. Questo a quanto pare rende il mantenere questo tipo di codice più semplice.

Esempio: controllo transazionale su file

Quando ci si trova a lavorare con dei file (o comunque con delle risorse esterne), è importante anche rilasciare la risorsa una volta che si è acquisita e si sono effettuate tutte le operazioni necessarie.

Ad esempio, in Ruby è molto facile leggere il contenuto di un file e stamparlo a video:

f = File.open("test_file.txt")
f.each do |line|
    puts line
end
f.close

Anche qui abbiamo usato un code-block (questa volta delimitato da do-end) per iterare sulle linee (delimitate dal carattere newline) contenute nel file.

Il difetto di questo approccio è che se ci si dimendica di invocare il metodo close sul file, questo rimane aperto. Un modo più corretto sarebbe quello di implementare un metodo che apra e chiuda il file, passando il controllo al code-block esterno per processarlo. In questo modo, il metodo che si occupa di aprire il file si occupa anche di chiuderlo:

class File
    def File.open_and_process(*args)
        file = File.open(*args)
        while line = file.gets
            yield line
        end
        file.close
    end
end

File.open_and_process("test_file.txt", "r") {|line| puts line}

Naturalmente non ho considerato le eccezioni in questo esempio.

Il risultato è lo stesso, ma ora abbiamo un controllo sulle transazioni su file. Infatti, questo è il comportamento implementato nel metodo File.open. Se viene fornito un code-block alla chiamata, open restituisce l'handler del file al code-block per farlo processare, e al ritorno chiude il file aperto.

Closures

Un code-block associato ad un metodo può essere memorizzato insieme al contesto dal quale viene passato per essere invocato in un secondo momento. Per fare questo deve essere convertito in un oggetto Proc (abbreviazione di procedure) al cui interno contiene tutte le informazioni sul contesto in cui viene definito (variabili, metodi, costanti, self).

In questo modo, il code-block può essere utilizzato anche quando il contesto in cui è stato definito non è più presente. Un linguaggio che supporta questa funzionalità si dice che fornisce le closures.

Un esempio per illustrare il tutto (tratto dal PickAxe):

def n_times(thing)
  return lambda {|n| thing * n }
end

p1 = n_times(23)
puts p1.call(3)
puts p1.call(4)
p2 = n_times("Hello ")
puts p2.call(3)

La stampa:

    69
    92
    Hello Hello Hello

La funzione lambda converte il code-block in un oggetto di tipo Proc che ritorna al chiamante, con la variabile thing pari al parametro passato alla funzione contenente il code-block stesso. L'oggetto Proc poi, dispone del metodo call per eseguire il code-block memorizzato.

Vediamo qui che, nonostante il parametro thing passato alla lambda sia ormai fuori dallo scope della call, questo è presente perchè memorizzato nell'oggetto Proc.

Ruby - linguaggio interessante

2009-07-10T00:00:00+00:00

Ho una certa conoscenza del linguaggio python, avendolo già utilizzato per dei progetti personali, ma ho deciso di imparare ad utilizzare in modo soddisfacente un buon linguaggio ad alto livello (o di scripting, anche se non mi piace molto il termine).

Data la maggior produttività che linguaggi di questo tipo consentono, possono essere utilizzati per un paio di scopi già da subito: - prototipazione - automazione

Quale linguaggio?

La risposta sembrerebbe triviale: conosco già un pò di Python, quindi sarebbe naturale scegliere di approfondirne la conoscenza, complice anche il rilascio del nuovo Python 3.

Ma sono curioso, e ho sentito molto parlare di questo nuovo linguaggio che arriva dal Sol Levante: Ruby. La killer-application che ne traina la popolarità è senza dubbio Rails e ci sono troppe persone che rispetto e che hanno una grande esperienza che ne parlano molto bene (I Pragmatici, Robert Martin a.k.a "Uncle Bob" e Martin Fowler tra gli altri) per far finta di nulla.

Questo nonostante il parere di Bruce Eckel (di fama "Thinking in [C++|Java]") che invece ha scelto Python come suo nuovo "linguaggio preferito". Al di là di confronti feature-a-feature e opinioni sullo stile di design, sono entrambi linguaggi in evoluzione (come dimostrano Python 3 e Ruby 1.9) e che possono essere appetibili a palati diversi, quindi l'unico modo valido per scegliere il "proprio" è sporcarsi le mani.

Conclusione

Credo che darò un'occhiata a questo linguaggio e che nel frattempo lo userò per implementare un pò di automazione in quello che faccio ogni giorno, in ogni caso avrò imparato qualcosa e fatto esperienza.

Assert first!

2009-06-27T00:00:00+00:00

Attualmente sto terminando la lettura del libro "Test-Driven Development By Example" di Kent Beck, ed è in mia modesta opinione una lettura molto istruttiva e utile per chi cerca di imparare questo stile di sviluppo. E' di grande beneficio vedere la tecnica all'opera e seguirne l'utilizzo passo-passo (forse l'unico modo per sviluppare un feel e assimilarne la mentalità), per poi rifinire la propria comprensione con dei pattern.

Ho già utilizzato questa tecnica per un progetto complesso sviluppato in un team (oltre che altri side-project personali) e quindi ho una seppur minima esperienza in proposito, ma ci sono ancora diverse finezze, tecniche e pattern che posso applicare per migliorare la mia capacità di sviluppare sistemi guidato dai test.

Un'idea nuova che non ho mai utilizzato è quella di scrivere prima gli assert in un test. La motivazione di questo accorgimento deriva dal vedere i test come un modo per guidare lo sviluppo delle funzionalità che un sistema deve avere.

In pratica, un sistema è composto da diverse funzionalità, ognuna delle quali deve essere soggetta a diversi test, ognuno dei quali a sua volta contiene delle asserzioni. La funzione delle asserzioni è molteplice, ma quelle che ci interessano in questa sede sono essenzialmente:

Qual'è la risposta corretta?
Come posso controllarla?

Cominciare a scrivere un test partendo dalle asserzioni (che normalmente in un test completo si collocano alla fine del test-case: test pattern arrange-do-check) fissiamo subito quali sono le funzionalità sotto test, qual'è la loro forma e sintassi e come devono rispondere. A partire da questa conoscenza possiamo costruire il test-case scrivendo tutte le operazioni necessarie per ottenere quel risultato.

Un esempio

(Tratto da: "Test-Driven Development By Example", Kent Beck)

Supponiamo di voler comunicare con un altro sistema attraverso un socket. Quando abbiamo terminato la comunicazione il socket deve essere chiuso e deve essere stata trasmessa e ricevuta con successo la stringa "abc".

Cominciamo con le asserzioni:

public void testCompleteTransaction() {
   // ...
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

Il reply viene da un socket:

public void testCompleteTransaction() {
   // ...
   Buffer reply= reader.contents();
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

Il socket lo creiamo connettendoci al server:

public void testCompleteTransaction() {
   // ...
   Socket reader= Socket("localhost", defaultPort());
   Buffer reply= reader.contents();
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

E infine (o in principio) dobbiamo connetterci al server:

public void testCompleteTransaction() {
   Server writer= Server(defaultPort(), "abc");
   Socket reader= Socket("localhost", defaultPort());
   Buffer reply= reader.contents();
   assertTrue(reader.isClosed());
   assertEquals("abc", reply.contents());
}

Campagna per il pensionamento di IE6

2009-06-11T00:00:00+00:00

In questo periodo sto studianto le tecnologie web per un progetto a cui partecipo, e non c'è libro sul CSS in cui mi imbatta che non contenga quasi ad ogni capitolo un riferimento a come qualche versione di Internet Explorer (almeno la versione 6 e precedenti) interpreti erroneamente, o addirittura manchi totalmente del supporto a, molte delle funzionalità richieste per il moderno web.

Si parla di proprietà CSS e anche di bug veri e propri che costringono gli sviluppatori e i designer di siti web a spendere un'incredibile quantità di tempo a sviluppare hacks per costringere IE a renderizzare la pagina correttamente come tutti gli altri browser (moderni o meno).

IE6 è un browser vecchio di otto anni ormai, ma purtroppo una fetta ancora non trascurabile del mercato (i dati parlano di una percentuale di circa il 20% delle connessioni totali), probabilmente perlopiù costituita da utenti business su macchine (ad esempio equipaggiate con windows 2000) che non possono fare un upgrade. E questo è un vero e proprio ostacolo allo sviluppo del web, essenzialmente per due ragioni:

Gli sviluppatori di siti devono spendere molto tempo (circa un terzo del tempo totale) a cercare di aggirare i bug e le mancanze di IE6 quando il sito viene renderizzato già perfettamente da tutti gli altri browser (perchè più rispettosi degli standard). In altre parole sono un bel pò di soldi spesi ad aggirare le mancanze di un browser obsoleto
Gli utenti non possono godere appieno delle nuove potenzialità del web. Provate ad andare su Facebook, o ad usare GMail o 37Signals con IE6...

Ecco perchè è nata una [campagna][bdie6] per spingere l'upgrade a browser più moderni (anche ad un'altra versione di IE, solo più recente). Dalla dichiarazione d'intenti della campagna (la traduzione è mia, ora sapete chi incolpare per gli errori):

[bdie6]: http://www.bringdownie6.com/ "campagna: Bring Down IE6"

La premessa è semplice: Internet Explorer 6 è antiquato, non supporta standard web chiave, e dovrebbe essere pensionato. Questo non riguarda l'essere anti-Microsoft, piuttosto riguarda la mancanza di sviluppo del mercato dei browser da parte di Microsoft. Con IE7/8 non disponibili per Windows 2000, IE6 conta circa per un 20% dell'uso del web, principalmente da parte di utenti business. I clienti fanno pressioni sui designer per "contringere" i siti a funzionare con IE6, e i designer, non volendo perdere affari, obbediscono, usando trucchetti e aggirando i problemi. Questa è una perdita di tempo e denaro. Microsoft deve sistemare questa situazione, i designer devono unirsi, e noi dobbiamo passare oltre.

Il dover avere a che fare con sistemi legacy non è una cosa nuova, accade continuamente ed è una conseguenza dell'avere un mercato con una grande inerzia ai cambiamenti. Ma quando questo significa solo uno spreco di soldi e di tempo come in questo caso, evitabile in modo piuttosto semplice, allora occorre spingere per andare avanti e disfarsi di una tecnologia obsoleta.

"IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web."
--Jeff Zeldman, standards guru

Web Software Engineering?

2009-06-07T00:00:00+00:00

Ultimamente sto facendo pratica con la programmazione orientata al web (come noterai dall'argomento dei post precedenti).

La mia impressione è che mentre per il software tradizionale abbiamo ormai una certa esperienza e conosciamo molti pattern e best-practices da applicare, nel caso della programmazione web non è proprio così.

Ci sono alcune soluzioni e metodologie di sviluppo mutuate dalla controparte stand-alone che possiamo applicare, alcuni principi che rimangono utili (riuso, interoperabilità, estendibilità, ecc.) ma ci sono anche nuove sfide da affrontare e molte cose da scoprire che sono peculiari di questo "ambiente di sviluppo".

Se l'ingegneria del software è una disciplina giovane, l'applicazione di questa disciplina al web lo è ancora di più. Il web è una piattaforma che consente possibilità non facilmente disponibili per il software desktop: probabilmente siamo solo all'inizio e, secondo la mia attuale ingenua visione, il futuro si rivelerà decisamente interessante :)

Google Wave!

2009-06-07T00:00:00+00:00

C'è molto fermento dietro il fenomeno Google Wave che potrebbe rivoluzionare il modo di comunicare e collaborare online.

Bando alle ciance ed ecco la presentazione ufficiale:

Sarà rilasciato al pubblico nel corso di quest'anno, ma sono già disponibili le API per integrare Wave con le proprie applicazioni e siti web e il sito dedicato al protocollo sottostante.

Si prospettano tempi eccitanti :)

Cos'è AJAX?

2009-06-06T00:00:00+00:00

AJAX è l'acronimo di Asynchronous Javascript And XML e indica una tecnica per permettere di costruire applicazioni web paragonabili a quelle stand-alone che utilizziamo normalmente.

L'utilità di AJAX

Un'applicazione web tradizionale solitamente costruisce una pagina web che invia al client. Questo compie delle azioni (riempie form, clicca dei link, ecc.) che vengono inviate al server come richieste http, il quale le elabora e costruisce una nuova pagina web che ritrasmette al client.

Questo modello funziona, ma ha l'inconveniente di essere sincrono: da quando l'utente invia una richiesta a quando il server risponde con una nuova pagina, l'utente non può far altro che aspettare.

Il meccanismo funziona per un web che è stato pensato per gli ipertesti ma non è più sufficiente per le esigenze moderne di applicativi costruiti sul web stesso. Applicativi che necessitano di essere responsivi.

Alcuni esempi di applicazioni web molto usate costruite con questa tecnica sono: GMail, Google Maps e Google Docs.

Da cosa è costituito

XHTML e CSS: per la presentazione
DOM: per il layout dinamico e l'interazione con la pagina
XML e XSLT: scambio e manipolazione dati
XMLHttpRequest: recupero asincrono dei dati
Javascript: collante per tutte le tecnologie precedenti

Come funziona

AJAX è stato creato per consentire alle applicazioni web un dialogo asincrono tra client e server minimizzando così il tempo di risposta percepito dall'utente.

In pratica si tratta di interporre tra il browser del client e la rete nella quale si trova il server un motore AJAX, che consente all'utente di interagire con l'applicazione web direttamente senza aspettare la risposta del server.

Dialogo client/server asincrono

Per certi compiti come la validazione dell'input e l'elaborazione di alcune informazioni, il motore AJAX può cavarsela da solo. In tutti gli altri casi in cui è richiesta una risposta dal server, è il motore stesso che si occupa del dialogo consentendo all'utente di continuare ad interagire con l'applicazione mentre si è in attesa della risposta.

Il dialogo poi si svolge solitamente attraverso frammenti XML, senza il bisogno di ricaricare (e ritrasmettere attraverso la rete) l'intera pagina.

E' questo in sostanza che consente al sistema di fornire all'utente un tempo di risposta inferiore, simile a quello di un'applicazione desktop. Qui però la velocità di un applicativo non è più determinata principalmente dalla velocità del sistema, ma dalla velocità della rete.

La maggiore sfida che Ajax pone davanti ai nostri occhi non riguarda la risoluzione dei problemi tecnici da esso derivati, ma il dimenticare tutte le limitazioni che riguardavano il Web, per lanciarsi verso la creazione di applicazioni robuste, veloci e sempre più simili alle applicazioni Desktop.
--Jesse James Garrett, Ajax: a new approach to web applications

Credits

Grazie a Daniele Simonin per la sua traduzione dell'articolo di Jesse James Garrett.

Riflessioni sul cloud computing

2009-06-05T00:00:00+00:00

Ultimamente si fa un gran parlare di Cloud Computing, e di come questo "nuovo" modo di intendere il software come un servizio (SaaS) possa essere conveniente o meno.

I pro

I vantaggi di un modello del genere sono presto detti:

non c'è alcun bisogno di predisporre datacenter
non occorre occuparsi del deployment e della messa in sicurezza
non occorre pagare personale interno che li amministri
tutto il software è direttamente accessibile mediante il browser
i dati sono nella cloud e accessibili (previa autenticazione) da qualunque parte del mondo e da qualunque pc
basta un pc depotenziato come un netbook per accedere a questi servizi (anche computazionalmente intensi)

Quindi i software sono forniti come un servizio, unitamente alla loro gestione per cui un utente non occorre che si preoccupi di altre problematiche aldilà del loro utilizzo. Si tratta di un ulteriore passo verso l'outsourcing.

Esempi di questi servizi sono GMail e Facebook, che sono diventati molto popolari e che hanno aumentato di molto l'efficienza e la produttività (almeno per quanto riguarda GMail).

I contro

Ma se da una parte il cloud computing è molto comodo perchè solleva dalla necessità di installazioni e configurazioni varie, dall'altra fa sorgere un problema di fiducia e di sicurezza in generale, come fa notare Bruce Schneier.

Sicurezza

Mentre posso gestire autonomamente il software installato in locale predisponendo misure di sicurezza come firewall e ambienti di esecuzione controllata, nel caso di SaaS sono completamente in balia del provider di quel software.

Senza contare che se uso un software a codice chiuso e che viene eseguito per di più su macchine remote, non posso essere sicuro che il servizio in questione non faccia di più di quello che dichiara. Di conseguenza sarei portato a fidarmi di più di un servizio basato su software open-source e di standard condivisi.

Privacy

Se utilizzo il cloud computing, utilizzo un software in cui immetto i miei dati che vengono memorizzati in maniera distribuita su server del gestore del servizio. In pratica sto a tutti gli effetti fornendo miei dati a una compagnia esterna che può essere o meno affidabile. Non ho nessun controllo sulle misure di sicurezza di quella compagnia che potrebbe anche avere accesso ai miei dati, o che potrebbe essere compromessa con relativo furto di informazioni.

E se quella compagnia ad esempio va in bancarotta o subisce dei guasti, posso perdere completamente i miei dati.

Inoltre, se i servizi sono accentrati in un'unica piattaforma, un'eventuale compromissione e furto d'identità potrebbero causare danni molto ingenti. Prova a immaginare a un ipotetico servizio che fornisse al tempo stesso email, piattaforma per lo sviluppo di documenti, blog, gruppi di discussione e conversazioni in tempo reale (suona familiare?). Immagina che venga compromesso e che qualche persona senza scrupoli si impadronisca del tuo account. A quel punto avrebbe accesso alle tue email, documenti e contatti e le sue azioni avrebbero una portata enorme sia sulla tua vita lavorativa che personale...

Certo, possono essere adottate misure di sicurezza come crittografia (sia a livello di connessione con https che di storage con AES ad esempio), autenticazione e backup. Ma il punto rimane che il controllo ultimo sulla configurazione e controllo del sistema rimane al fornitore. E i tuoi dati sono in quel sistema.

Lock-in

Quando i dati risiedono su server di terze parti, oltre alle problematiche della sicurezza e della privacy occorre preoccuparsi della portabilità.

Non basta che il fornitore abbia una buona infrastruttura di sicurezza, usi la crittografia, e abbia dei sistemi di backup. Occorre che i dati che io immetto nel sistema li possa recuperare in ogni momento e integralmente, e devo essere sicuro che quando li cancello vengano eliminati realmente (non come nel caso di Facebook).

Si tratta in altre parole di avere il controllo completo sui propri dati, in caso contrario subiamo l'odioso vendor lock-in che stiamo solo ora cominciando a superare nel campo delle suite office e delle pubbliche amministrazioni.

Pay-per-use

Non potendolo classificare come pro o contro, c'è comunque da considerare questo aspetto.

Il cloud computing permette nuovi modelli di business, tra i quali c'è il richiedere un corrispettivo per la fornitura di risorse e software in una cloud. Questo può essere un aspetto positivo per il fornitore e per l'utente (migliore servizio), ma può anche non esserlo, dipende dai punti di vista.

Riflessione

Il cloud computing per come è nato ha proprio gli obiettivi di tagliare i costi di gestione, incrementare la facilità di accesso e la produttività. Però ci sono anche delle problematiche di sicurezza e di fiducia che emergono da questa architettura.

E' anche vero che si possono avere i vantaggi del Cloud Computing in una intranet, mantenendo il controllo sui propri dati e conservando la comodità della centralizzazione di accesso e utilizzando storage e risorse di calcolo distribuite. Ma al costo di sacrificare l'accesso globale (a meno di non predisporre VPN) e di re-introdurre i costi di gestione di un datacenter.

Bisogna stare attenti di chi fidarsi e per cosa. I meccanismi del mercato dovrebbero spingere i fornitori a erogare un servizio di qualità, ma quello che si guadagna in comodità e risparmio, lo si può perdere in privacy, sicurezza e flessibilità.

Trust is a concept as old as humanity, and the solutions are the same as they have always been. Be careful who you trust, be careful what you trust them with, and be careful how much you trust them. Outsourcing is the future of computing. Eventually we'll get this right, but you don't want to be a casualty along the way.
--Bruce Schneier

JDK7 - piattaforma modulare multi-linguaggio

2009-06-04T00:00:00+00:00

Secondo un articolo di InfoWorld, la nuova nuova versione del JDK Sun adotterà un design più modulare che supporterà la versione 7 del linguaggio Java. E questo porterà, secondo Mark Reinhold (ingegnere principale dietro Java SE e OpenJDK) a una serie di vantaggi.

Classpath will be dead

La modularità verrà raggiunta attraverso il progetto Jigsaw, che permetterà agli sviluppatori di sviluppare i propri moduli e di eliminare la necessità del classpath.

"Class path is dead," Reinhold said.

Un JDK per domarli tutti

La modularizzazione potrebbe portare anche ad una singola versione di Java, dato la capacità di un sistema del genere di adattarsi all'ambiente in cui si trova ad essere eseguito.

Piattaforma multi-linguaggio

"We're working to define a modular form of the Java platform and its implementation; we're working to evolve the Java Virtual Machine into a true, multilingual universal runtime for high-level languages; and finally, we're doing things to make developers more productive," said Mark Reinhold, principal engineer for Java SE and OpenJDK.

Aspetto per me decisamente più importante. Per come la vedo io, l'uso di un ambiente di esecuzione per codice managed che permetta a programmi scritti in linguaggi diversi di comunicare e cooperare tra loro, in un'ambiente comune e con un set standard di librerie, è una carta vincente.

Già ora esistono soluzioni simili, le più famose delle quali sono il CLR della piattaforma .Net e appunto il JRE che già ora supporta un gran numero di linguaggi anche molto diversi tra loro come Scala, Groovy, Clojure, Jython e JRuby per citarne alcuni.

Crescente uso delle annotazioni

Per facilitare il compito dei checker statici.

Conclusioni

Con queste nuove modifiche la piattaforma Java potrebbe diventare a tutti gli effetti un ambiente di esecuzione in grado di supportare una gran varietà di necessità, linguaggi e stili di sviluppo, il tutto garantendone l'interoperabilità e l'esecuzione controllata.

Tutte caratteristiche che secondo me potrebbero diventare irrinunciabili in molti settori.

L'importanza della pianificazione

2009-06-02T00:00:00+00:00

Proceed from a plan, whether that plan is in your head, on the back of a cocktail napkin, or on a wall-sized printout from a CASE tool.
--"The Pragmatic Programmer", Andrew Hunt, David Thomas

Iniziare un progetto senza uno straccio di piano è una ricetta per il fallimento, o quantomeno per un'efficientissima fonte di mal di testa.

Non si tratta di pianificare ogni minimo dettaglio fin dal principio. Questo è controproducente (al di là di casi particolari come i programmi che equipaggiano lo space shuttle). Ma non si tratta nemmeno dell'estremo opposto: procedere, praticamente, a caso.

Alcuni proponenti dell'approccio agile erroneamente portano all'estremo il concetto di self-organization, sostenendo in maniera più o meno implicita una generale antipatia per la pianificazione.

Tecnologia

Nell'ambito tecnologico possiamo vedere questa "lotta" ad esempio a livello di progettazione.

Da una parte abbiamo i proponenti del BDUF, che sostengono una specifica completa e dettagliata prima di cominciare a codificare. Il che nella stragrande maggioranza dei casi significa perdere tempo in dettagli minuziosi basati su assunzioni non verificate, per poi scoprire che la soluzione non funziona o che ce ne sono di migliori e più eleganti, a cui non si arriva se non avendo sott'occhio il codice.

Life is what happens to you while you are busy making other plans.
--John Lennon

Dall'altra abbiamo certi "agilisti" (partigiani) che aborriscono qualsiasi forma di pianificazione e preferiscono lanciarsi nella codifica "lasciando che il design si riveli ed evolva da sè grazie ai test". Uhm...

Come fa notare Uncle Bob, in questa situazione come in tantissime altre, la verità sta nel mezzo. Un pò di pianificazione all'inizio (senza arrivare agli estremi del BDUF), permette di capire meglio il problema e impostare una soluzione decente, senza rischiare di ficcarsi in un vicolo cieco da cui è molto difficile uscire.

Inoltre ci sono determinate cose che devono essere fissate up-front. Ad esempio, io mi sono ritrovato a lavorare ad un progetto di un sistema distribuito di simulazione, composto da diversi moduli che comunicavano in modo concorrente e tramite rete, ognuno progettato e realizzato da una parte del nostro team. E' stato necessario definire:

architettura generale
interfacce di comunicazione
tipi di dato condivisi

Senza definire queste cose a priori non saremmo riusciti a lavorare in parallelo e ci saremmo pestati i piedi a vicenda rallentando l'intero progetto.

Management

Lo stesso concetto vale a livello di management, come ho verificato sulla mia pelle.

Anche qui si presenta il concetto di self-organizing team, ma è comunque necessario stabilire delle linee guida e delle regole (meglio se condivise e adottate su base consensuale), che andranno sì modificate e integrate "in corsa", ma che sono comunque necessarie per una comunicazione efficace.

Avere un piano a livello di management significa poter identificare le priorità (infrastruttura, interfacce, user stories, ecc.), poter allocare risorse, pianificare costi e tempi di massima (ad esempio: project velocity di XP) e coordinare il team.

C'è un modo per affrontare con successo anche il progetto più gigantesco e complesso: fare un passo alla volta.

A: "voglio un di sistema di elaborazione di dati scientifici che si appoggia su CUDA pronto tra quattro mesi"
B: "comincia a studiare CUDA per una settimana e fai qualche prototipo, poi faremo un meeting per buttare giù qualche bozza di architettura e stimare i costi"

Quale delle due alternative ti motiva di più ed è più utile?

Conclusione

Sia in ambito tecnologico che in ambito gestionale occorre trovare un equilibrio tra pianificazione e auto-organizzazione, perchè ognuno dei due elementi è necessario alla buona riuscita di un progetto e di un team di sviluppo.

L'importanza di comunicare

2009-05-30T00:00:00+00:00

Non basta avere una buona idea, bisogna anche saperla "vendere". C'è una concezione comune secondo cui "una buona idea si vende da sola" ma purtroppo non è sempre vero: basta guardarsi attorno per vedere delle ottime idee che non hanno riscosso un grande successo a causa di una "cattiva campagna di marketing".

Una buona idea è un'orfana senza una comunicazione efficace.
-- "The Pragmatic Programmer", Andrew Hunt, David Thomas

Inoltre spendiamo buona parte delle nostre giornate comunicando (memo, email, discussioni con colleghi e management, interviste col committente, proposte di miglioramento, ecc.) per cui vale la pena farlo bene.

Personalmente mi sono trovato in molte situazioni in cui ho dovuto fare attenzione al modo in cui comunicavo per sostenere la validità del mio punto di vista. Ad esempio quando ho proposto il VCS Mercurial al team con il quale ho sviluppato un progetto all'università per ingegneria del software, o tutte le volte che abbiamo fatto delle presentazioni ai docenti del medesimo corso.

Come comunicare efficacemente

In "The Pragmatic Programmer" gli autori dedicano un capitolo a come comunicare efficacemente, in cui danno alcuni consigli che applicherò ai post di questo stesso blog e che riassumo qui.

Sapere cosa dire

Punto fondamentale e ovvio, ma troppo spesso ci si ritrova a digitare "Introduzione" e a cominciare a scrivere senza avere un'idea precisa di quello che si vuole comunicare.

E' utile quindi pianificare quello che si vuole dire, ad esempio scrivendo un'outline e modificandola finché la risposta alla domanda "questo comunica quello che sto cercando di dire?" è sì.

Adattare il messaggio all'audience

Ogni idea può essere presentata in modi diversi a seconda dell'audience: ve ne sono di diverse con bisogni, interessi e capacità differenti. E' quindi importante personalizzare il messaggio affinché sia recepito correttamente da chi sta ascoltando.

We've all sat in meetings where a development geek glazes over the eyes of the vice president of marketing with a long monologue on the merits of some arcane technology. This isn't communicating: it's just talking, and it's annoying.

Occorre avere una chiara idea di chi ascolterà il nostro messaggio e delle sue caratteristiche. Le seguenti domande possono aiutare:

Che cosa vuoi che imparino?
Qual'è il loro interesse in quello che hai da dire?
Quanto sono sofisticati?
Quanti dettagli vogliono?
Chi vuoi che faccia propria l'informazione?
Come puoi motivarli ad ascoltarti?

Inoltre occorre adottare uno stile di comunicazione adatto. L'interlocutore preferisce andare dritto ai fatti oppure conversare? Preferisce uno stile formale o uno più sciolto?

Capire queste cose è importante per far recepire al meglio il messaggio.

Scegliere il momento giusto

Non ogni momento è il momento giusto. L'interlocutore può avere fretta, altro da fare o semplicemente può non essere dell'umore giusto. Una parte del capire le esigente dell'audience consiste nel capire le loro priorità, nel dubbio è sempre meglio chiedere: "è un buon momento per parlarti di ...?"

Questo, almeno in un blog, non è un problema visto la natura intrinsecamente on-demand del mezzo di comunicazione :)

Cura l'apparenza

E' uno sbaglio fare affidamento solo sul contenuto di un documento senza badare alla presentazione. L'aspetto è una caratteristica importante che concorre a veicolare efficacemente un'idea. Contenuto e aspetto devono essere curati in sinergia.

TIP 10: "It's Both What You Say and the Way You Say It"

Alcuni suggerimenti per documenti:

usa un sistema di impaginazione che produca risultati gradevoli: ad esempio LaTeX, XHTML+CSS con eventualmente qualche exporter in PDF come FOP, DocBook, o anche qualche word-processor che supporti gli stylesheets.
usa lo spell-checking, prima automatico e poi manualmente (verifica walkthrough)

Coinvolgi l'audience

Un altro suggerimento (che non ho mai impiegato, mea culpa) è quello di coinvolgere gli interlocutori nel processo di produzione del documento per raccogliere feedback e instaurare una proficua relazione di lavoro.

Cosa che sembra abbia funzionato tra l'altro per la produzione di libri interi come Real World Haskell e Programming Scala.

Ragione per cui ho adottato questo approccio per il presente blog: nonostante il suo aspetto/layout sia ancora un work-in-progress è online e il repository dei suoi sorgenti è liberamente accessibile (in lettura) e pubblicato con licenza CreativeCommons.

Inoltre, nel caso di comunicazioni verbali è utile trasformare l'esposizione in una sessione interattiva, ad esempio facendo domande e chiedendo di riassumere quello che si è appena detto.

Desktop-search in KDE 4.2

2009-05-27T00:00:00+00:00

Da parte mia, una volta provata la funzionalità di desktop search è diventata irrinunciabile. E' un utilissimo strumento per utilizzare il proprio computer con efficienza e significa avere tutti i propri dati e applicazioni letteralmente a portata di dita.

Niente più gerarchie di cartelle annidate e menu incastrati uno dentro l'altro come una matrioska. I dati memorizzati nel computer vengono indicizzati da un motore di ricerca e ogni file è raggiungibile non solo ricercando il suo nome, ma anche il suo contenuto. Possiamo aprire documenti, filmati, musica, applicazioni e chi più ne ha più ne metta in pochi secondi e dovunque si trovino su disco.

I vantaggi sono innegabili: io per esempio mi sono sempre trovato a dover gestire molti file (la maggior parte dei quali inutili) e a concepire sempre nuovi sistemi di archiviazione. Con il desktop search posso mettere tutto dentro una sola cartella (ad esempio "Archivio") e raggiungere qualsiasi file al suo interno non appena ne ho bisogno, senza dover navigare alcuna gerarchia.

Piattaforme

Per MacOS abbiamo il migliore (mi dicono): Quicksilver.

Per Windows ci sono Google Desktop e Launchy (meno sofisticato di Google Deskop).

Su piattaforma Linux, per Gnome c'è GNOME Do e, per KDE, Nepomuk con il suo Strigi.

Usare Nepomuk con Ubuntu 9.04

Sfortunatamente Nepomuk non è ancora pronto per un'utilizzo di produzione e attualmente è abilitabile con facilità solo il rating e le annotazioni per i file.

Nonostante questo, con qualche passaggio manuale possiamo abilitare anche il motore di indicizzazione (Strigi), che poi potremo utilizzare con Dolphin o krunner.

Ecco i passaggi necessari:

Installare il backend di Strigi sesame:
```
sudo aptitude install soprano-backend-sesame
```
Attenzione: sarà necessario installare anche la la JRE!
Aprire il pannello:
```
System Settings > Advanced > Desktop Search
```
attivare "Enable Nepomuk Semantic Desktop" e disabilitare "Enable Strigi Desktop File Indexer".
Eliminare i dati correnti di Nepomuk:
```
rm -Rf ~/.kde/share/apps/nepomuk
```
Configurare Strigi per usare il backend sesame nel file:
```
~/.kde/share/config/nepomukserverrc
```
e modificando la linea del backend nella sezione [main Settings] come segue:
```
Used Soprano Backend=sesame2
```

Sfortunatamente, in Ubuntu Jaunty Jackalope sesame è linkato al file libjvm.so, che però viene cercato nella posizione standard /usr/lib quando invece in Ubuntu si trova in un'altra posizione:

locate libjvm.so

nel mio caso:

/usr/lib/gcj-4.2-81/libjvm.so
/usr/lib/gcj-4.3-90/libjvm.so
/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/lib/i386/server/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/cacao/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so
/usr/lib/jvm/java-6-sun-1.6.0.13/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-6-sun-1.6.0.13/jre/lib/i386/server/libjvm.so

basta fare un link alla libreria server in /usr/lib, ad esempio:

ln -s  /usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so \
/usr/lib/libjvm.so

Tornare nel pannello "System Settings" nella sezione "Desktop Search" (vedi punto 2), e nella tab "Advanced Settings" selezionare quali directory far indicizzare da Strigi.
Abilitare Nepomuk e Strigi.

A questo punto dovrebbe comparire l'icona di Nepomuk nella task-list: ciò vuol dire che è partita l'indicizzazione.

Uso di Nepomuk

Il modo più semplice e diretto per usare Nepomuk è con krunner: Alt+F2.

Nell'area di inserimento che compare al centro dello schermo si possono:

lanciare applicazioni
cercare in contatti, bookmarks, file, documenti recenti, cronologia di navigazione
eseguire calcoli
esplorare certe cartelle con dolphin

E altro ancora, il tutto scrivendone il nome o anche una parte (krunner effettua il pattern matching).

krunner funziona anche senza Nepomuk e Strigi, ma con questi ultimi possiamo anche cercare all'interno dei propri file, con tutti i vantaggi che questo comporta.

Hello world!

2009-05-19T00:00:00+00:00

Ecco il primo post di questo mio nuovo blog! Finalmente mi sono deciso ad aprirlo, utilizzando il servizio GitHub Pages.

Si parte con un design molto minimale, creato a partire da quello di Tom Preston-Werner, il creatore di Jekyll e co-fondatore di GitHub.

Gli scopi di questo blog sono molteplici:

Per imparare qualcosa non basta leggere: metterlo in pratica e cercare di insegnarlo è uno dei metodi migliori per apprendere. Quindi questo è un posto in cui insegno prima di tutto a me stesso, e poi rendo anche disponibili questi lavori per aiutare che volesse intraprendere la stessa strada
Per condividere esperienze e instaurare dialoghi con persone che lavorano nel mio stesso campo
Last but not least, fare un pò di pratica con il web-design e pubblicare un sito in una maniera molto comoda e interessante :)

Enjoy!