Forem: Cadoret Théo

Randomness, what did you expect ?

Cadoret Théo — Mon, 24 Aug 2020 06:46:45 +0000

Randomness is, at first glance, a hard to grasp philosophical concept that we are absolutely not going to tackle in this article. Definitely not.

Rather, we are going to use a pretty common and globally accepted definition, and what could be better for that than a community maintained definition such as Wikipedia's ?

“Randomness is the apparent lack of pattern or predictability in events”

Yes, we are going to talk about patterns and predictability.

But wait I'm getting ahead of myself, first, let's see why I am even writing about it.

Randomness is needed everywhere

Well, actually randomness is everywhere in software.

Video games make an extensive use of randomness to make each game different from the last. Sometimes to make enemies (or allies for what it's worth) unpredictable. Sometimes to generate a whole new world that the the player will explore.

_Randomly generated map in Don't Starve_

But it's not only for "adventure" games, it is also very useful in virtual card games which are often based on the unpredictability of the deck shuffling.

_Online poker game_

One can also think of Spotify who offers to shuffle your playlists (actually their algorithm is based on random but is rigged, because we humans don't like it when it's too random).

_Spotify's shuffling algorithm schema_

Light simulators also make extensive use of randomness to simulate light diffusion on matter in every direction of space. Instead of modelling every light beam we randomly select few of them to save the machine from a certain death.

Optimisation algorithms as well, such as Monte-Carlo, could use some randomly chosen initial values.

Finally security is also a great playground for random based algorithms, especially for generating encryption keys. Indeed they must be absolutely unpredictable to be of any use. If someone could predict which key you're going to use, then it's easy for them to decrypt your message.

There are many more fields of application for this peculiar concept, but I think I made my point.
We need randomness.

Ok that's cool, but what's the big deal? If I just go Math.random() I'm fine right ?

Both "yes" and "no". That's where it gets interesting.

Randomness is far from innate

Let's go back to fundamentals, what is a computer and what is its purpose ?

In essence, a computer has an initial defined state, and a set of predefined instructions which will, by their execution, lead it to another state.

There is no place for actual randomness. Everything is fully deterministic and that's pretty useful actually.

So how do we cope with our needs being completely out of reach of our means ?

Donald Knuth gives us a clue for what could be our first move:

“In a sense, there is no such thing as a random number. For example, is 2 a random number ? Rather, we speak of a sequence of independent random numbers with specified distribution.”

Which matches pretty well with our definition of a computer that executes a set of instructions that lead it to a sequence of consecutive states.

So our first approach will be based on generating a sequence of numbers that seem random.

Pseudo-Random Number Generators (PRNGs)

This is where pseudo-random number generators come into play. They are entirely defined by two parameters :

A seed
A function

The seed is the starting point of the algorithm, the first value of the sequence.
Then to generate the sequence, one just has to apply that function to the seed, recursively. Each obtained value is part of the sequence.
The challenge is to choose a couple (seed, function) that will produce random looking values.

Middle square algorithm

The middle square algorithm is very simple :

// Define an initial value
Seed = 5678

// Square it
5678^2 = 32239684

// Take the 4 middle digits (if it's not 8 digits long, add leading 0s)
32[2396]84 = 2396

// Start over with the new value

Here you can find an online generator if you want to try it yourself.

The middle square algorithm applied to the seed 5678 gives this sequence :

2396 7408 8784 1586 5153 5534 6251 0750 5625 6406 0368 1354 8333 4388 2545 4770 7529 6858 0321 1030 0609 3708 7492 1300 6900 6100 ...

Which indeed seems very random to a human.

But the next iterations of this sequence point out one of the main issues of PRNGs :

... 6100 2100 4100 8100 6100 2100 4100 8100 6100 ...

As soon as the PRNG falls on a value it has already visited, it gets trapped in a loop. The length of this loop is called the period and can be very short as in this example : 4

Any PRNG will eventually cycle as the range (number of possible values) is limited and defined by the function itself. For the middle square algorithm the range is [0-9999]=> 10 000 possible values. And the best possible period is proved to be 4096.

But PRNGs are not dead. Middle square algorithm is just one of their soldiers, and not the mightiest.

Actually their Achilleus, the gold standard when it comes to PRNGs, is the Mersenne Twister algorithm. We are not going to it discuss in details though as it is fairly complex (for the curious and rather mathematical ones).

But it's worth discussing the Linear Congruential generator which can be viewed as a base for the Mersenne Twister.

Linear Congruential generator

The function for this PRNG is based on 3 parameters :

A : the multiplier
C : the increment
M : the modulus

f(x) = ( x * A + C ) mod M

So the range is defined by M so that f(x) ∈ [0, M-1].
Choosing M to be a power of 2 is very efficient as the modulus operation can be simply truncating the binary representation.
By correctly tuning all 3 parameters it is possible to obtain a very large range and period. One of the best sets of parameters involve choosing M a power of 2 so that M-1=2^N-1 is prime.

And a prime that is one less than a power of two is called... a Mersenne Prime !

Okay so let's sum up what we've got.

PRNGs :

do look random : Given a not too absurd set of parameters and a correct algorithm, the output sequence seems random to us humans.
can provide a uniform distribution : Before the first loop, values appear only once in the sequence. From an external point of view, they are equiprobable.
are fast to compute : They are rather basic algorithms and easy to compute
are deterministic : Meaning sequences can be reproduced if you know the seed and parameters. Which is good when used in tests for instance.

And for most use cases it's enough. One can think of video games, light simulator, card games... card games ?
It depends, if it is to draw your Solitaire initial state, PRNGs are widely sufficient, but when it comes to online card games such as Poker, where people bet real money and would have solid reasons to try to take advantage of our Achilleus heel, we need a different approach.
As you can imagine, it is also the case for encryption keys, which job is to protect from bad intentioned intruders.

For these use cases, we will need more than random looking sequences, we will need true unpredictability.

True Random

If you aim for true randomness, you must seek first for true unpredictability, a property that is inherently out of reach of a software.
One must search for it on the other side of the keyboard, in the real world, which is an incredible source of disrupted events. We call it entropy.

Entropy sources are everywhere and can take various forms, from atmospheric noise to radioactive decay.

For instance, Cloudflare (who is responsible for the security of about 10% of the overall internet traffic) uses a video stream from a camera pointed 24/7 at a wall of lavalamps to encrypt data.

This is the wall I'm talking about :

Online card games are not outdone either as PokerStars chose another option. Their card drawer algorithm relies partly on a light beam shot at a semi-opaque mirror.

If the photon passes the mirror that's a 0, if it gets reflected that's a 1.

As a last example I'll mention the Linux kernel which makes use of both hardware metrics and user inputs to fill its entropy pool.
Hardware metrics can take the shape of an SSD access time, which is not deterministic. User inputs can be timestamps of a keyboard pressure, or a mouse movement etc. This website gives an example of what can be done with a cursor movement to generate random strings.

But unpredictability is not sufficient to provide randomness. We also need a uniform distribution of probability among the possible values. Meaning we need the absence of pattern.

In order to provide this, we'll need CSPRNGs.

Cryptographically Secure Pseudo Random Number Generators (CSPRNGs)

CSPRNGs are basically just badass PRNGs often based on hash functions. It's an algorithm that takes a seed as input and outputs a value. They have 2 very important properties that make them way more secure than classic PRNGs :

Withstand the 'Sate compromise extension'

In the event that part or all of its state has been revealed (or guessed correctly), it should be impossible to reconstruct the stream of random numbers prior to the revelation.
Satisfy the next bit test

We say that a sequence of bits passes the next bit test for at any position i in the sequence, if any attacker who knows the i first bits (but not the seed) cannot predict the (i+1)st with reasonable computational power.

(Reasonable computational power means with less than the overall computing power on the planet, pretty safe.)

A good CSPRNG is SHA256 for instance ! (Secure Hash Algorithm)

On linux you can access this truly random source by reading from /dev/urandom...
... or /dev/random?

/dev/random vs /dev/urandom

When Linux OS receives entropy from the outside world, it stores it in an entropy pool. Entropy pool from which both /dev/urandom and /dev/random draw. The only difference is that /dev/random will block when it estimates that the entropy level is too low, whereas /dev/urandom can draw from this pool almost endlessly providing perfect randomness ("u" stands for unblocking).

You are safe using /dev/urandom for cryptographic purposes.

The nitty-gritty details can get a bit too technical for this article, the curious ones though can choose the red pill and dive into the rabbit's hole

Conclusion

Random numbers don't exist, we speak of a random sequence of numbers. This is something that software can easily simulate and fool human brains with a rather basic algorithm. They look unpredictable and uniformly distributed. This is more than sufficient for the vast majority of use cases, but it is inherently flawed. These pseudo random number generators won't fool well designed attacking software. In use cases where attacks are awaited, such as encryption keys, these simple algorithms won't do, we'll need a more robust source of unpredictability which can only be found through interactions with the real world.

À quoi bon écrire des tests ?

Cadoret Théo — Fri, 10 Jul 2020 13:50:05 +0000

On entend souvent que le Test Driven Development est une bonne pratique, qu'elle permet d'avoir une base de code clean, plus maintenable, plus robuste etc.
À tel point que cette implication semble acceptée par ses adeptes comme un lien direct.
Quelqu'un m'a posé la question justement, pourquoi ? En quoi le TDD aide-t-il a obtenir tout ça ?
J'ai bafouillé et n'ai su poser des arguments. J'avais fini par accepter le TDD sans plus pouvoir l'expliquer.

Dans cet article allons considérer l'écriture des tests dans un contexte de TDD.
Le but ici n'est pas de décrire et d'expliquer comment pratiquer le TDD ni comment écrire de bons tests, les méthodes pour y parvenir sont nombreuses et déjà très bien renseignées dans d'autres articles.
Non, ici j'aimerais m'intéresser au pourquoi des tests, est-ce bien utile après tout ?

Je vais donc revenir sur certains points qui me semblent pertinents vis à vis de l'écriture de tests dans un contexte de TDD.
Ça n'est pas un top. Ça n'est pas exhaustif.

Parce que notre code répond à un besoin métier

Le code que nous écrivons, que ce soit dans un contexte personnel ou professionnel, doit répondre à un besoin métier.
Ce besoin peut ainsi se décomposer en une série de spécifications qui ensuite pourront être traduites en tests.
Une fois ceux-ci implémentés, nous savons que nous avons répondu au(x) besoin(s) dans la plupart de ses aspects métiers et de manière durable.
Écrire des tests n'est rien d'autre qu'ancrer les spécifications métier dans le code source du système de manière à en assurer la validité sur le long terme.

Je vais prendre un exemple simple sur le Game of Life de John Conway, l'une des spécifications / règles du jeu qui sera toujours vraie :

Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

public class CellTest{
    @Test
    void dead_cell_with_3_neighbors_should_come_alive() {
        Cell cell = new Cell(CellState.DEAD);

        CellState nextRoundCellState = cell.withLiveNeighbors(3).computeNextState();

        assertThat(nextRoundCellState).isEqualTo(CellState.ALIVE);
    }
}

Ainsi, on s'assure que cette spécification sera toujours vérifiée quelles que soient les modifications qui peuvent survenir par la suite. Une cellule morte possédant 3 voisins vivants va naître.
Il est même envisageable d'annoter ce test avec un tag Jira / Gitlab / Whatever, renvoyant directement vers la story concernée.

Parce que nous ne sommes pas seuls

Le code évolue continuellement, mais il n'est pas le seul. L'équipe de développement aussi !

Il est possible que nous ayons une vue d'ensemble claire du système dont nous avons la garde, mais il arrivera un moment où nous devrons partager le bébé, voire même le transmettre à quelqu'un d'autre.
Cette personne ne sera pas aussi au fait que nous du pourquoi du comment de certaines fonctionnalités, la documentation - même mise à jour régulièrement - n'a pas vocation à couvrir l'intégralité du code.
Peut-être que nous avons introduit de la complexité pour, par exemple, éviter que certains données d'entrée ne causent des problèmes.
Ajouter un test pour ça est comme documenter ce choix :

Je sais que cet évènement peut se produire, nous l'avons vu en prod et ça a causé des problèmes.
Voici les inputs en question, ils ne devraient plus poser de soucis car l'oracle (comportement spécifié par le métier) est celui-ci.

Le nouveau venu sera alors alerté si par mégarde il-elle modifie inconsciemment le comportement par un test rouge pointant directement sur la spécification en question.

De plus, nous sommes parfois amenés à designer des systèmes qui se doivent d'être génériques, ce qui passe très souvent par une large utilisation d'interfaces et autres niveaux d'abstraction.
Plus il y a de niveaux d'abstraction, plus il est difficile et long d'appréhender le code dans son ensemble et de s'approprier son comportement.
Avoir des tests qui implémentent de manière concrète certaines entités abstraites va grandement faciliter la construction d'un modèle mental global du système au nouveau venu.
C'est exactement comme illustrer un cours très théorique à l'aide d'exemples concrets, ça aide à fixer les idées.

Parce qu'on veut refactorer l'esprit tranquille

Plus le système évolue pour intégrer de nouvelles fonctionnalités, corriger des comportement anormaux etc. plus il se complexifie.
Ce phénomène se manifeste par l'apparition d'une complexité essentielle, inhérente aux besoins métiers que l'on essaie de traduire algorithmiquement, et d'une complexité accidentelle souvent due à l'ajout de pièces les unes au dessus des autres.
Dans un certain ordre. En un temps donné.

C'est donc l'empilement de nouvelles fonctionnalités qui transforme du code bien pensé et lisible en legacy lourd difficile à lire et à maintennir.
C'est la règle et il faut faire avec. Mais il est possible d'atténuer cette transformation en réécrivant ce vieux code au fur et à mesure, et pour ça, nos vieux tests de non régression sont nos meilleurs atouts.
Nous, on code, on redesign, on repense l'architecture. Eux ils nous protègent si l'on fait une erreur et nous évitent de tout se prendre dessus si ça tombe. Ils sont les garants du respect des spécifications.
Il arrive souvent qu'un petit refactoring prenne de plus en plus d'ampleur à mesure que l'on tire sur le fil.
Avoir confiance en sa couverture de tests (en terme de spécifications, pas de lignes de code) nous permet de nous arrêter quand on veut, tant qu'ils sont verts.
On peut donc garder les MR de refactoring courtes, faciles à merger, et fréquentes.

Parce qu'on veut une review

Les code reviews peuvent parfois être un exercice prenant, elles demandent une charge mentale très importante à la personne qui s'y colle. Il s'agit de lire, comprendre, et critiquer (constructivement, toujours) du code qui a pu prendre plusieurs jours à son/ses développeur(s).

Bon très bien, il est 9h30, j'ai du café, j'y vais. Mais par quoi je commence ?

La lecture / compréhension

En tant que reviewer on n'a pas nécessairement tout le contexte de la fonctionnalité, quels peuvent être les points sensibles. Les tickets / issues / post-its / whatever de stories sont bien souvent incomplets, et de toute façon ne relatent pas les difficultés techniques rencontrées qui ont pu pousser à certains choix.
Souvent les problèmes se posent à l'implémentation et le programmeur prend des décisions de design en fonction de ceux-ci, ce qui rend la mise en contexte plus difficile.
Sans aucun guide de lecture nous devons donc lire le code et comprendre par rétro-ingénierie ce qui a été implémenté et pourquoi les choix ont-été faits. (Même si certaines formes de documentation peuvent aider, voir cet article sur les ADR 😉 )

Exemple :

La merge request présente les plans d'un attelage avec 3m de rênes, 2 mors, 2 avaloirs etc. Celle-ci fait également état de points de ravitaillement espacés de 50km avec de l'eau et d'autres espacés de 100km possédant eau et nourriture.

Hmm ok, on veut parcourir une raisonablement longue distance en peu de temps avec deux chevaux sans les laisser se déssecher ni mourrir de faim.

La critique / Le biais

Une fois compris, nous devons avoir un regard critique (constructif, toujours) par rapport à ce qui a été développé.
Il faut donc réussir à être critique vis à vis d'une solution à un problème que l'on a compris à la sueur de nos cellules grises en se basant sur cette même solution. Vous voyez le biais ?

Difficile de prendre du recul, notre esprit est déjà polarisé par la solution avant même de pouvoir y réfléchir. C'est l'oeuvre d'un biais cognitif bien connu : le biais d'ancrage.

Pour des chevaux, des ravitaillements espacés de 40km et 80km seraient plus avisés sinon on risque de les épuiser rapidement. J'aurais plutôt pris 4m de rênes, il faut compter l'espacement entre les chevaux et la calèche, et se garder du mou pour être plus confortable (Valeurs prises un peu au hasard, j'avoue 😅)

Les tests comme guide

Pour une code review de qualité, à mon sens, le reviewer doit avoir une vision claire du problème avant d'attaquer la lecture de la solution.
C'est là que les tests entrent en jeu. Ils définissent à plus ou moins haut niveau les spécifications de la fonctionnalité.

Exemple :

On devrait couvrir la distance de 300km en deux jours maximum.

On devrait pouvoir tracter un chargement de X kilos.

Simplement à la lecture des tests le reviewer peut avoir une vision d'ensemble des possibilités et contraintes de la fonctionnalité implémentée.
Ensuite seulement il-elle peut se plonger dans l'étude de notre solution avec un esprit clair et proposer des critiques pertinentes et constructives.

Hmmm si tu remplaces l'attelage par un moteur devant la calèche tu peux te passer des points de ravitaillement

Enfin, il va sans dire qu'un reviewer à qui on évite la charge mentale de devoir faire une rétro-ingénierie sera plus enclin à prendre en charge la merge request et notre fonctionnalité ira en prod plus vite !

Parce que ça marche !

Mesurer l'efficacité d'un développeur ou d'une équipe sur le long terme est une tache fastidieuse car elle dépend de nombreux facteurs.
Il est donc impossible d'être sûr de l'efficacité du TDD dans un environnement donné et je ne peux pas vous assurer que ça rendra votre système parfait, ni même meilleur.
Mais j'aimerais néanmoins mettre en valeur certains chiffres obtenus par des études sur le TDD dans des conditions de test qui méritent qu'on s'y attarde un peu.

Temps de développement / Qualité du code

Cette étude, conduite avec des équipe d'IBM et de Microsoft, montre que le temps de développement d'un produit avec TDD est supérieur à celui sans TDD d'environ 15 à 35%.
Ce qui peut s'expliquer par beaucoup de choses. Évidemment le nombre de tests est supérieur, ce qui risque d'allonger le développement, mais il faut également voir que la méthodologie est loin d'être instinctive et facile à mettre en place !
Écrire les tests d'abord c'est commencer par se poser des questions sur ce que l'on veut obtenir, mettre en place ses interfaces etc. On renverse la logique et au début c'est pas facile.

Cette même étude met ces résultats en balance avec le nombre de défauts trouvés dans les pre-releases des produits issus ou non du TDD : Avec TDD ils sont de l'ordre de 40 à 90% moins fréquents.
On observe donc une réelle différence avec ou sans TDD en terme de qualité et de robustesse du code produit.
Il est alors intéressant de mettre ces résultats en perspective avec le coût d'un défaut à différentes étapes du cycle de développement.

Coût d'un bug

Pour illustrer cette grandeur, et comme on trouve beaucoup d'études et de résultats différents à ce propos, j'ai choisi de prendre la plus prudente des estimations que j'ai trouvée, présentée dans cette étude conduite par IBM Science Institute :

D'après IBM System Sciences Institute, corriger un bug en prod coûte 6x plus cher qu'à l'implémentation.

Cela s'explique notamment par le coût du changement de contexte.
Corriger un défaut en prod c'est changer de contexte de travail, se réapproprier le code en question (parfois vieux si l'agilité n'est pas la qualité première de l'équipe, mais c'est une autre histoire), diagnostiquer la cause, fixer ledit défaut et enfin rechanger de contexte pour poursuivre son travail.
Le défaut en question peut aussi être un mauvais choix d'implémentation qui, au fur et à mesure, a pu se propager : plus tard on s'en rend compte, plus il a pu servir de socle à d'autres développements. Les impacts de la réécriture sont donc décuplés.
Ça va sans dire que trouver l'origine d'un bug dans son environnement de développement est plus rapide qu'en se basant sur des extraits de logs de prod en level 'INFO'.
Enfin on peut noter qu'un défaut trouvé en prod risque fortement d'impacter le service, voire le tomber pour les plus graves, ce qui peut avoir un coût financier monstrueux dans le cas d'un service d'e-commerce, ou pire dans le médical...

La diversité des résultats issus des études sur les coûts des défauts s'explique très bien au vu de la difficulté de les quantifier.
Il reste néanmoins que tous les arguments, bien que qualitatifs plus que quantitatifs, sont tous orientés dans la même direction.

Conclusion

Écrire des tests c'est bien plus que garder sa couverture au dessus des 80% pour rassurer des gens qui n'y toucheront jamais.

Écrire des tests c'est expliciter son code, valider son travail, avoir confiance en son système, s'assurer de sa qualité, communiquer ses intentions etc.
Bref si on écrit des tests c'est avant tout pour nous aujourd'hui, et pour nous demain !

Learning curve : Inject physical properties into digital interfaces

Cadoret Théo — Fri, 10 Jul 2020 13:49:05 +0000

As a UI/UX designer, if your end users need documentation, then you’ve already lost, no matter how usable is your interface. Nowadays, especially on the web, solutions are everywhere and users allow very little time on an interface to understand its behavior and interact with it. If they don’t learn quickly enough how to use a piece of software, they’re likely to switch on another available solution.
That's why learnability is a key factor in human computer interfaces and it's important to take a special care of it.

This article does not aim to lead to perfect learnability, but focuses on a widely used trick to improve it.

But first let's focus on defining what exactly is learnability, so we can make it easier.

Learnability

Learnability is a difficult concept to catch. What does it mean for a software to be easy to learn ?

According to Grossman T. et al. who did a review of how researchers define learnability during the past 25 years, it can firstly be divided in two : Initial Learning and Extended learning.
Here we'll focus more precisely on initial learning as extended learning is more about mastering the use of a software.

Even in initial learning, definitions in scientific documentation vary, but let's take Shneiderman's view :

”The time it takes members of the user community to learn how to use the commands relevant to a set of tasks.”

From this definition we can extract two important things that initial learning relies on :

The user community, its initial knowledge and habits
Learning process itself Learning is about creating mental and conceptual models of a system. Therefore, when facing something new, users will try to find its familiar features in order to conceptualise and categorise it. So the learning process is mainly about building knowledge upon existing experience, especially physics laws, mechanics and so on. This is where the concept of affordance becomes a very powerfull tool to ease learning.

Affordance

Affordance designates the ability of a device to suggest a particular kind of use by virtue of some physical attribute. In Don Norman’s 1988 book, The Design of Everyday Things, affordances became defined as :

Perceivable action possibilities—i.e., only actions users consider possible

The real world offers tons of examples of great interfaces using affordances

How would you open this door ?

If you answered by pushing on the grey plate, congrats your brain is fully functionnal.

You just faced an unknown object (you’ve - probably - never interacted with it before) and two things happened:

By seeing it you inferred it’s behaviour.
You had enough confidence in this inference to try to interact with it without using a manual. This door just afforded its behavior.

Physical objects tend to have great affordances because their behaviour relies upon basic physics laws that everyone is familiar with. (By applying a force on the right side of a door which rotation axis is on the left will cause it to rotate around it.)

Here is an example of how a simple change in design can increase the affordance of the system :

_How would you switch on the top-right one ?_

Unfortunately, 1s and 0s, first components of the digital world, tend to be less explicit about that. That is why UXs tried to represent real world into softwares to use physical affordances so the user could try to infer behaviour based on an existing knowledge.

That is what metaphors are all about.

Metaphors

It all began with Alan Kay's "Desktop Metaphor" :

_The original 1984 Mac OS desktop that popularized the new graphical user interface._

These familiar items (desktop, folders, files etc.) have the same rules as their physical equilvalent:

Everything is represented on the desktop, usual working environment, where you can put files and folders. Files gather data and can go into folders if you drag and drop them in.
Files and folders can be thrown away by putting them into the trash bean that you will empty once in a while.

Thinking about it for a minute is enough to realise it makes no sense at all to put files into a trash bean and then empty it to actually free some disk memory. But it is easy to learn.

Nowadays one does not see these similarities as we're more used to computers than dealing with actual files and folders, but back then it was a key point to acceptation of new born computers.

Implementing these similarities allows us to build on something we know, to reuse a known mental model.

Metaphors are present within the smaller detail of interfaces guiding us on how to interact with it.
Skeumorphic design makes metaphoric use of physical analogies that indicate which parts a user can press, click, or slide, etc. These phenomena have been described as ‘indicating functions’ in product semantics, and as ‘affordances’ in cognitive psychology.

Theses metaphors are everywhere in software interfaces. I'll take an Apple product as example once again (sorry windows lovers, I really tried...).

_iOS 3 unlock slider._

Here it seems pretty obvious what action the UX designer wants us to perform, and its output.
Apple used skeumorphic design to suggest that the white 'slider' could be moved within the boundaries defined by its black environment, from left to right.
Using signs like the arrow and text, they finish to encourage the user to perform the action and make the interface predictable.

But users evolve constantly, and one must nuance this result.

In 2001 Prensky introduced the term Digital Natives to describe a new generation of users who ‘have spent their entire lives surrounded by and using computers, videogames, digital music players, video cams, cell phones, and all the other toys and tools of the digital age’.
The idea that interfaces are being learned by transferring knowledge from the ‘real’ (i.e. analogue) world to the digital world may be loosing its dominance.
Experienced Digital Immigrants rather transfer knowledge they previously acquired using other interfaces,
That is why design is evolving and flat design is a great example of this dynamic. Skeumorphism is becoming less usefull, in favor of clean, neat design that satisfies the eye.

A perfect example of this dynamic is the new Iphone's unlocker :

_iOS 7 unlock slider._

Conclusion

Finally, injecting physical properties into digital interfaces is an efficient way to improve its learnability, especially initial learning.
But one must not forget that the learning process deeply relies on already known mental models as it is all about building over it and finding similarities.
Users have been evolving since the birth of computers and their global knowledge over this technology follows. Where complex interactions will highly benefit in term of learnability from rich skeumorphic design, more usual interactions will satisfy from a more minimalist design.
Wether or not you choose skeumorphism of flat design, consider taking a great care of affordances, they're a - complex - way to make your interface simple to use.

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”