This pre commit hook will check the PEP8 syntax of your Python files and ask you if you want to continue the commit process.

In your project directory create a file: .git/hooks/pre-commit and add the execution permission on it.

#!/bin/bash

echo "Pre-commit started"
echo "PEP 8 check"
git diff  --cached --name-only | grep .py | xargs pep8

if [ $? == 0 ]
then
    exit 0
fi

# Allows us to read user input below, assigns stdin to keyboard
exec < /dev/tty

echo "Do you want to ignore warning?"
select yn in "Yes" "No"; do
    case $yn in
        Yes ) exit 0;;
        No ) exit 1;;
    esac
done

Asyncio is greats piece of software. But all Python code is not compatible. In the following example we will see how to run blocking code from your asyncio code.

We will by a simple asyncio application:

import asyncio
import time

@asyncio.coroutine
def clock():
    while True:
        print("Current time from asynchronous code: {}".format(int(time.time())))
        yield from asyncio.sleep(1)


def main():
    loop = asyncio.get_event_loop()
    asyncio.async(clock())
    loop.run_forever()

if __name__ == '__main__':
    main()

The output is:

Current time from asynchronous code: 1422265105
Current time from asynchronous code: 1422265106

And add blocking code:

import asyncio
import time

@asyncio.coroutine
def clock():
    while True:
        print("Current time from asynchronous code: {}".format(int(time.time())))
        yield from asyncio.sleep(1)

def blocking():
    while True:
        print("Current time from blocking code: {}".format(int(time.time())))
        time.sleep(1)

def main():
    loop = asyncio.get_event_loop()
    blocking()
    asyncio.async(clock())
    loop.run_forever()

if __name__ == '__main__':
    main()

The output is:

Current time from blocking code: 1422265410
Current time from blocking code: 1422265411
Current time from blocking code: 1422265412

If you want to run blocking code in your asynchronous code you need to run it in a different thread. Hopefully asyncio provide BaseEventLoop.run_in_executor where you can execute code in a different executor. You can pass None in order to execute your code in the default executor: ThreadPoolExecutor.

import asyncio
import time

@asyncio.coroutine
def clock():
    while True:
        print("Current time from asynchronous code: {}".format(int(time.time())))
        yield from asyncio.sleep(1)

def blocking():
    while True:
        print("Current time from blocking code: {}".format(int(time.time())))
        time.sleep(1)

def main():
    loop = asyncio.get_event_loop()
    loop.run_in_executor(None, blocking)
    asyncio.async(clock())
    loop.run_forever()

if __name__ == '__main__':
    main()

The output is:

Current time from blocking code: 1422265601
Current time from asynchronous code: 1422265601
Current time from blocking code: 1422265602
Current time from asynchronous code: 1422265602
Current time from blocking code: 1422265603

run_in_executor return a future and if an exception is raise your code is not stopped you need to check the future. A dummy sample code for stopping your code when something arrive:

import asyncio
import time
import concurrent

@asyncio.coroutine
def clock():
    while True:
        print("Current time from asynchronous code: {}".format(int(time.time())))
        yield from asyncio.sleep(1)

def blocking():
    while True:
        print("Current time from blocking code: {}".format(int(time.time())))
        time.sleep(1)
        raise Exception("Test")

def main():
    loop = asyncio.get_event_loop()
    block = loop.run_in_executor(None, blocking)
    async = asyncio.async(clock())
    loop.run_until_complete(asyncio.wait([block, async], return_when=concurrent.futures.FIRST_COMPLETED))
    print(block.exception())

if __name__ == '__main__':
    main()

Afin d’améliorer ma culture de développeur, j’ai décidé d’apprendre le GO, qu’on voit de plus en plus pour des backend demandant de la performance.

Pour comprendre mon avis, il faut savoir que j’ai un profil de développeur backend pour des startups. Je code en Ruby (y compris avec EventMachine) au travail depuis plusieurs années, dans mes loisirs je fais du Python. J’ai pas mal joué avec Node.js y a un an, mais je n’étais totalement satisfait par l’aspect déploiement et la stabilité. J’ai aussi un bon background en C grâce à mes études à EPITECH.

Voilà donc mes premiers retours après une journée de GO. J’ai choisi d’écrire pour faire mes tests une application très simple qui va vérifier le DNS d’un grand nombre de domaines en même temps.

Je retrouve le slogan de Python “fourni avec les piles”. En effet de base les développeurs de GO fournissent pas mal d’outils de base pour la doc, les tests, le formatage du code, gestion des dépendances…

#La syntaxe

La syntaxe contient quelques bizarreries pour nos esprits formatés, mais rien d’insurmontable.

Par exemple la déclaration d’une fonction:

func TestDomain(domain string) bool {
}

Cela nous donne une fonction TestDomain qui prend en argument un domain de type string et on retourne un bool.

Autre point qui parait bizarre au premier abord:

a := 1
a = 2

L’opérateur := est un raccourci pour déclarer et affecter une variable. En effet le compilateur ne vous laisse pas utiliser une variable non déclarée.

On pourrait l’écrire ainsi:

var a;
a = 1
a = 2

Point très positif pour moi, une commande gofmt est fournie avec le langage. Cela va reformater votre code selon les normes en vigueur dans le monde du GO. Cela coupe court au débat sur l’indentation, la place des parenthèses… Et on retrouve donc le confort de Python où deux codes sont formatés de la même manière.

VIM

Pas de problème de ce côté là j’ai installé VIM-GO qui fait le job:

• coloration syntaxique
• vérification des erreurs de syntaxe
• reformatage du code lorsqu’on sauvegarde avec gofmt

# Gestion de modules

Fournis de base avec le système vous pouvez téléchargez des modules (souvent hébergé sur Github).

go get github.com/noplay/madep

Dans votre code vous pouvez ensuite référencer le code en utilisant le même nom:

package main

import (
	"github.com/noplay/madep"
	"github.com/miekg/dns"
)

Je trouve cela assez pratique, car on retrouve très facilement le site d’où vient un module.

La documentation

Pour le moment tous les modules que j’ai utilisés étaient bien documentés avec généralement un readme qui explique bien l’utilisation du module.

Une commande godoc vous permet d’afficher la documentation et via:

godoc -http=:6060

Vous avez un serveur de documentation un local.

Les Goroutines

L’un des éléments qui rend le GO pratique pour la programmation concurrente est le concept des Goroutines. En effet pour lancer un traitement de tâches de fond il suffit de rajouté le mot-clef go devant l’appel. La fonction sera lancée en tâche de fond et votre code continuera son exécution.

go long_traitement()

C’est une sorte de thread léger.

Les channels

Pouvoir lancer des tâches de fond c’est bien, mais encore faut il communiquer avec. C’est là qu’entre en oeuvre le concept de channels. Basiquement c’est un tube dans lequel on écrit d’un côté et on a une lecture bloquante de l’autre côté.

messages := make(chan string)

go func() { messages <- "hello" }()

msg := <-messages
fmt.Println(msg)

C’est un système simple et qui s’avère efficace à l’usage.

Ce qu’il me reste à voir

Je n’ai pas encore testé le déploiement et c’est un point qui peut devenir compliqué sous Mac OS vu que cela implique de la cross compilation. Il y a aussi un framework de test fourni que je n’ai pas regardé.

Conclusion

Pour le moment j’ai une très bonne première impression sur GO. Le langage semble robuste et relativement simple de prise en main. Les concepts pour la programmation concurrente sont faciles à mettre en oeuvre. Par contre, cela ne remplacera par Ruby ou Python qui ont du sucre syntaxique qui rend certaines taches plus agréables (l’intégration des regex dans ruby par exemple).

Le fait de déployer juste un binaire en production me semble une bonne idée quand on voit les cauchemars dans lesquels on tombe vite lorsqu’on déploie du Ruby, du Python ou du Node.

La syntaxe me plait beaucoup plus que celle du C++ qui offre trop de possibilités ce qui fait qu’on se retrouve avec autant de C++ que d’endroit où l’on fait du C++.

Voilà j’ai enfin pris le temps de troquer mon vieux blog sous SPIP avec un nouveau sous Jekyll. C’est l’occasion d’un gros redesign.

On oublie donc le vieux squelette:

Pour un thème dérivé du thème HMFAYSAL OMEGA avec un look plus moderne. Et a moi le plaisir de blogguer en statique.

J’ai surement cassé plein de truc au passage lors de la migration et je vais réparer au et à mesure.

I made a Virtual Machine images for testing Cassandra integration in MariaDB. This Virtual machine is based on Ubuntu 12.04 with Datastax Cassandra 1.1 version and prebuilt version of MariaDB 5.5.27 + Cassandra from here.

You can get it by using Vagrant.

After that run this commands:

vagrant init cassandramariadb "http://noplay.net/~noplay/cassandramariadb.box"
vagrant up
vagrant ssh

After that:

For loading the sample data:

vagrant@mariadb-cassandra:~$ cat create_keyspace.cql |cqlsh 
vagrant@mariadb-cassandra:~$ cat create_database.sql |mysql -uroot

Show the data in MySQL:

vagrant@mariadb-cassandra:~$ mysql -u root
use blog;
SELECT posts.message,users.name FROM posts,users WHERE posts.user = users.id;

Show the data in Cassandra:

vagrant@mariadb-cassandra:~$ cqlsh 
cqlsh> use blog;
cqlsh:blog> SELECT * FROM posts;

And voilà :)

Lorsqu’on veut indexer un site il peut être utile de partir de la sitemap du site qui est justement faite pour cela.

Tout d’abord vous pouvez regarder dans le fichier robots.txt si il y a une section sitemap:

Sitemap: http://example.com/sitemap.xml

Si la sitemap n’est pas référencé il vous reste une chance. Il est possible que le webmaster ai soumis la sitemap à google. Vous pouvez le savoir en tapant cette requête:

site:example.com filetype:xml OR filetype:gz