Skip to content

Modèles féminins en informatique

Les informaticiens célèbres sont principalement des hommes, qu’ils soient théoriciens, créateurs de langage ou de logiciels. À l’origine de l’informatique, beaucoup de femmes étaient présentes mais en tant que petites mains plutôt que conceptrices. Voici quelques femmes qui pourraient servir de modèles :

Ada Lovelace

Difficile de ne pas citer Ada Lovelace car elle est considérée comme la première personne à avoir écrit un programme, et cela, bien avant qu’un ordinateur existe. Avec l’importance grandissante de l’informatique, son influence a été reconnue et un langage créé dans les années 80 porte son prénom. Un prix décerné par l’AWC, une association de femmes dans l’informatique, porte aussi son nom.

Margaret Hamilton

Peu de personnes ont écrit avec leur équipe un code source qui, une fois, imprimé est aussi haut qu’eux. Margaret Hamilton, elle peut. Surtout que ce code, probablement écrit en assembleur, est parti dans l’espace…

Suite à son expérience des développements logiciels sur le programme Apollo, Margaret Hamilton a aussi publié des articles importants sur l’ingéniérie logicielle et conçu le langage 001AXIS Universal Systems Language.

Lorinda Cherry

Lorinda Cherry a été embauchée par les Bell Labs pour programmer en assembleur (un classique dans les années 70) et a alors participé au développement d’outils sur l’Unix originel. Elle a conçu à cette période un langage pour afficher des équations (eqn) avec Brian Kernighan. Elle a aussi contribué à Plan 9.

Lorinda Cherry fait une rapide intervention sur une vidéo de 1982 qui présente Unix AT&T. Son intervention commence à 15 minutes 39.

Elles ont raté le podium : Grace Hopper, Jean Bartik, Betty Holberton ou Mary Lee Woods.

Publicités

Avec with : plus d’indentations, moins d’instructions

En python, le mot-clef with permet d’ouvrir un bloc dans lequel un contexte spécifique est actif.

L’exemple de « context manager » le plus courant est celui d’une ouverture de fichier qui se ferme automagiquement :

with open('sortie.txt', 'w') as f:
    f.write('Coucou')
f.closed # vaut True

On retrouve cette possibilité dans de nombreux cas comme l’ouverture d’un serveur SMTP :

from smtplib import SMTP
with SMTP("domain.org") as smtp:
    # faire des trucs
#la connection smtp est fermée

L’utilisation d’un « context manager » est adapté à chaque fois qu’il est nécessaire de réaliser des tâches à l’ouverture ou la fermeture (libérer un verrou, fermer une connection, supprimer un fichier, changer une variable globale, etc.). Cela permet de se concentrer ce qu’on veut vraiment faire dans le contexte du with. Les tâches d’ouverture et fermetures sont respectivement déplacées dans les méthodes magiques __enter__() et __exit__(). Si l’on prend en compte l’ensemble du code source, il n’y a donc pas moins d’instructions. Et le titre de l’article peut être considérée comme de la publicité mensongère.

class Pipeau:

    def __enter__(self):
        print("<bonimenteur>")

    def __exit__(self, type, value, traceback):
        print("</bonimenteur>")

with Pipeau():
    print("Prochain article de blog à -50 % !")

# affiche :
# <bonimenteur>
# Prochain article de blog à -50 % !
# </bonimenteur>

Pour plus de détails sur l’utilisation de with, consultez la documentation Python et l’article de sametmax.

Ignorer des fichiers, de ack à ag

Ag (the silver searcher), comme ack permettent de chercher des motifs de texte dans du code source. Une sorte de grep spécialisé pour du code source.

Les deux outils sont très probablement disponibles dans votre distribution préférée.
Sous Debian et dérivées :

apt install ack-grep # pour ack
apt install silversearcher-ag # pour ag

ag est plus rapide qu’ack pour trouver des motifs. Un comparatif de performance écrit par le développeur d’ag, qui est donc juge et partie, le montre. Quelques tests rapides m’ont aussi montré un gain de temps.

ack utilise un fichier .ackrc pour ignorer des chemins ou fichiers. ag aussi, mais le format est un peu différent (équivalent à .hgignore et .gitignore qu’il utilise aussi) car il ne fait que de l’exclusion. La modification est triviale pour un castor junior :

$ cat .ackrc
--ignore-dir=riri
--ignore-dir=fifi/
--ignore-dir=loulou

devient
$ cat .ignore
riri
fifi/
loulou

À partir de la version 0.33.0, ag utilise le fichier .ignore et .agignore devient déprécié. Dans la dernière version testée, le fichier .agignore est toujours lu s’il est la racine de ${HOME}, mais non pris en compte s’il est dans le répertoire dans lequel la recherche est faite.

Testé avec les versions suivantes :

ack version 2.12 et 2.18
ag version 0.19.2 et 2.1.0

Coder une variante de FizzBuzz basée sur le jeu 6 qui prend

FizzBuzz est un jeu où l’on compte : lorsqu’un entier est un multiple de 3, on dit « Fizz », multiple de 5 « Buzz », multiple de 3 et 5 « FizzBuzz », dans les autres cas, on dit simplement l’entier. Il est aussi utilisé comme test pour évaluer si quelqu’un maîtrise les bases de la programmation. Une variante, un peu plus compliquée, mais du même type pourrait être réalisée avec le jeu 6 qui prend.

C’est un jeu de cartes dont le but est d’avoir le moins de têtes de bœufs. Les cartes sont numérotées de 1 à 104 (inclus).

Les règles d’estimation de la valeur (en tête de bœufs) des cartes sont relativement similaires aux règles du FizzBuzz :

  • si le nombre est un multiple de 5, la carte vaut 2 têtes de bœufs
  • si le nombre est un multiple de 10, la carte vaut 3 têtes de bœufs
  • si le chiffre des dizaines et des unités sont identiques, la carte vaut 5 têtes de bœufs
  • la carte 55 vaut 7 têtes de bœufs
  • les autres cartes valent 1 tête de bœufs chacune

TL; DR Si on a vraiment du temps à perdre, on finit avec un code de ce genre :

CARTES = 104

def tetes(numero):
    _score = 1
    for diviseur, points in ((10, 1), (5, 1), (11, 4)):
        if _est_multiple(numero, diviseur):
            _score += points
    if numero == 55:
        _score += 1
    return _score

def _est_multiple(numero, diviseur):
    return not numero % diviseur

if __name__ == "__main__": 
    for numero in range(1, CARTES + 1):
        print(numero, "★" * tetes(numero))

Le début de la sortie du terminal :

1 ★
2 ★
3 ★
4 ★
5 ★★
6 ★
7 ★
8 ★
9 ★
10 ★★★
11 ★★★★★
12 ★

Première version

Le code le plus rapide à écrire pour passer les tests devrait ressembler à :

def tetes(numero):
    if numero == 55:
        return 7
    if not numero % 10:
        return 3
    elif not numero % 5:
        return 2
    elif numero >= 10 and str(numero)[0] == str(numero)[1]:
        return 5
    else:
        return 1

if __name__ == "__main__": 
    for numero in range(1, 12):
        print(numero, "*" * tetes(numero))

Améliorations

La règle « le chiffre des dizaines et des unités sont identiques » est équivalent à être un multiple de 11 :

#if numero >= 10 and str(numero)[0] == str(numero)[1]:
if not numero % 11:

Autant factoriser le test de divisibilité :

def tetes(numero):
    _score = 1
    if _est_multiple(numero, 10):
        _score += 1
    if _est_multiple(numero, 5):
        _score += 1
    if _est_multiple(numero, 11):
        _score += 4
    if numero == 55:
        _score += 1
    return _score

def _est_multiple(numero, diviseur):
    return not numero % diviseur

On peut alors remplacer la succession de if par une boucle, et hop, on obtient un code final (qui est au début de l’article).

Tests

Pour valider le programme, quelques assertions de bon aloi sont à ajouter. Ces assertions auront été obtenues au fur et à mesure si on fait du TDD.

import sixquiprend

assert 1 == sixquiprend.tetes(1)
assert 1 == sixquiprend.tetes(2)
assert 2 == sixquiprend.tetes(5)
assert 3 == sixquiprend.tetes(10)
assert 5 == sixquiprend.tetes(11)
assert 5 == sixquiprend.tetes(22)
assert 7 == sixquiprend.tetes(55)

Comportement d’éditeurs de texte lors d’une modification concurrente

Comment se comportent les éditeurs de texte lorsqu’un fichier est ouvert dans l’éditeur et qu’il a été modifié en même temps? C’est la question que vous ne vous êtes probablement jamais posée et à laquelle cet article répond.

TL;DR : plus ou moins bien mais l’écrasement sauvage est évité.

Dans un terminal

Le comportement est le même dans les trois éditeurs testés (nano, vim et emacs-nox). L’éditeur signale le problème lors de l’enregistrement du fichier. Il est possible de choisir alors entre l’état du fichier sur le disque ou celui qui vient d’être modifié.
Par contre, on ne s’en rend compte uniquement lorsque l’on désire enregistrer. Il est toujours possible d’annuler, d’enregistrer le fichier modifié sous un autre nom puis faire la comparaison entre les deux.

Nano

C-o

Vim

:w

Emacs-nox

C-x C-s

Emacs propose un choix supplémentaire : r annule les modifications en cours (pour « reverted »). C-h affiche une explication des différents choix et leurs implications.

En mode fenêtré

Le comportement est similaire dans les éditeurs testés (Gvim, Emacs, Gedit et Kate).
Ils détectent la modification automatiquement et propose de charger le fichier mis à jour. En cas de refus, une nouvelle alerte survient lors de l’enregistrement.

Gvim

Détection de la modification :

Alerte à l’enregistrement :

Emacs

Détection de la modification :

Alerte à l’enregistrement :

Gedit

Gedit est l’éditeur de base fourni avec GNOME.

Détection de la modification :

Alerte à l’enregistrement :

Kate

Kate est l’éditeur fourni avec KDE.

Kate propose une fonctionnalité que les autres n’ont pas : lorsque la modification du fichier est détectée, Kate propose de visualiser la différence entre les deux fichiers (bouton « View difference »). L’affichage obtenu est un diff entre la version sur le disque et la version en mémoire. On pourrait imaginer qu’il ouvrirait le résultat dans un nouvel onglet mais il semble qu’il utilise l’éditeur sélectionné par la variable d’environnement $EDITOR.

Détection de la modification :

Alerte à l’enregistrement :

Méthode et versions utilisées pour les tests (et captures d’écran)

Le comportement n’est pas identique entre les éditeurs lorsque la modification du fichier est faite par la commande
echo 'ajout' >> fichier.txt
Par exemple, la modification en parrallèle est bien détectée par Emacs mais pas par Gedit (la détection à l’enregistrement fonctionne correctement).

Pour avoir un comportement homogène, la méthode utilisée à chaque fois a été d’ouvrir le fichier nommé fichier.txt dans deux éditeurs, le modifier et l’enregistrer dans l’un des éditeurs et regarder comment réagit l’autre.

Nano :
2.8.6

Vim :
VIM – Vi IMproved 8.0 (2016 Sep 12, compiled Jul 22 2017 06:10:49)

Gvim :
8.0.707, version de GNOME 3.22.2

Emacs :
25.2.2, avec le thème deeper-blue

Gedit :
3.22.0, version de GNOME 3.22.2

Kate :
16.08.3, avec KDE 5.28.0 et Qt 5.7.1

L’ensemble des captures d’écran ont été faites sous GNOME.