Installer Python 3 sous Windows

Sur le site officiel de Python ( https://www.python.org/ )
"Downloads" / "Windows" : https://www.python.org/downloads/windows/

Choisir la dernière version : "Latest Python 3 Release - Python 3.x.x"

Pour un Windows 64 bits sélectionner "Windows x86-64 executable installer"
pour lancer le téléchargement

Lancer l'exécutable qui a été téléchargé ( par exemple "python-3.6.2-amd64.exe" )

Sélectionner "Add Python 3.x to PATH"

Conserver toutes les options cochées,
notamment "pip" pour disposer de l'outil standard d'installation des packages Python.

Après l'installation :

Vérifier que les commandes "python" et "pip" sont utilisables à partir de la ligne de commande :

> path 
exemple de résultat :
PATH=C:\Program Files\Python36\Scripts\;C:\Program Files\Python36\;

> where python  
exemple de résultat : "C:\Program Files\Python36\python.exe"

> where pip
exemple de résultat : "C:\Program Files\Python36\Scripts\pip.exe"

Tester le lancement de l'interpréteur Python :
> python

Tester le lancement de 'pip' :
> pip

Tester le bon fonctionnement de 'pip'
Exemples d'installation de packages :
> pip install bottle( installation de "bottle" dans "(PYTHON-DIR)\Lib\site-packages" )

> pip install sqlalchemy
( installation de "sqlalchemy" dans "(PYTHON-DIR)\Lib\site-packages" )

Dans un répertoire quelconque, créer un fichier "hello.py" contenant :
  print("Hello, World!")  
Exécuter avec la commande
> python hello.py 

Modifier le fichier "hello.py" pour tester l'import du package "bottle"

  import bottle   
  print("Hello, World!")  

Exécuter avec la commande
> python hello.py 

S'il n'y a pas d'erreur tout est OK,
les commandes et les packages sont utilisables quel que soit le répertoire.

Utilisation de git-shell

Un utilisateur qui va travailler avec un repository Git via SSH n'est pas censé disposer de toutes les possibilités offertes à utilisateur "normal".

Pour limiter les actions d'un utilisateur Git propose un "shell restreint" appelé "git-shell".
Il permet d'exécuter uniquement des actions Git sur le serveur.

Seules les commandes suivantes peuvent être exécutées via git-shell :
  - git receive-pack <argument>
  - git upload-pack <argument>
  - git upload-archive <argument>
ce qui permet au client Git de réaliser les opérations suivantes :
  - git push
  - git fetch
  - git archive


Vérification de "git-shell"

L'objectif est de remplacer le shell standard de certains utilisateurs ("bash", "sh", etc) par "git-shell".
"git-shell" doit donc être installé sur le serveur (ce qui doit être le cas, il est fourni avec git)
et faire partie de la liste des "shells" utilisables.

Vérifier que git-shell est bien installé sur le serveur :
$ which git-shell
/usr/bin/git-shell
ou
$ command -v git-shell
/usr/bin/git-shell

Lorsqu'on exécute "git-shell" il affiche le message suivant :
  fatal: Interactive git shell is not enabled.
Ce qui est normal puisque "git-shell" n'est pas un "shell interactif"

Vérifier que "git-shell" fait partie de la liste des shells utilisables
$ cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash

Pour l'ajouter :
$ su
$ vi /etc/shells
Ajouter le path complet ( par exemple "/usr/bin/git-shell" )


Mise en place de "git-shell" pour un utilisateur 

Il suffit de changer le shell de l'utilisateur courant :
$ chsh -s /usr/bin/git-shell
Password:

A partir de maintenant l'utilisateur n'a plus de "shell interactif",
toute tentative de "login" sera refusée.
Lorsqu'il tentera de se connecter via SSH le serveur affichera le message suivant :
  fatal: Interactive git shell is not enabled.
  hint: ~/git-shell-commands should exist and have read and execute acc

Un "su user-name" n'est donc plus possible non plus.

Externaliser la configuration d'une webapp

Comment permettre à une application web Java de récupérer un paramètre de configuration sans avoir à repackager le ".war" ?

Si on s'interdit de modifier le fichier ".war" ça veut dire que l'on ne peut plus utiliser les possibilités de configuration à partir des fichiers qu'il contient ( web.xml, fichiers properties, etc ).
Les paramètres de configuration devront donc être portés par les environnements d'exécution de l'application (et non par l'application elle même), c'est à dire le server d'applications ( Tomcat, Jetty, etc ) ou le système d'exploitation.
Les trois possibilités les plus courantes sont décrites ci-après...

1) Utiliser une variable d'environnement

- Définir la variable d'environnement au niveau du système d'exploitation

Exemple sous Linux  :
   export MYFOLDER=/tmp/foo

- Récupérer la valeur de cette variable dans le code Java,
  par exemple dans une classe de type  "ServletContextListener" :
    String value = System.getenv("MYFOLDER"); 

Cette solution est simple et applicable indépendamment type de serveur d'applications.
Mais elle nécessite une intervention au niveau "système d'exploitation" (pas toujours possible) et on ne peut avoir qu'une seule valeur pour toutes les instances de serveurs d'application sur un même OS.

2) Configurer une propriété de type "Java System property"

Il s'agit de définir une propriété pour la JVM au lancement du serveur d'applications.

- Définir la propriété pour un serveur d'applications particulier :

Soit avec l'option "-D" de la ligne de commande
Soit en utilisant les fichiers de configuration propres à chaque serveur d'application

Exemple pour Tomcat :
        Dans le fichier "catalina.properties" de Tomcat :

    myfolder=/tmp/foo

       
        NB : pour un lancement dans Eclipse utiliser le fichier "catalina.properties"
                 situé dans le workspace (dans  "Servers" )

- Récupérer la valeur de cette propriété dans le code Java :

    String value = System.getProperty("myfolder");

3) Configurer une "valeur nommée" accessible via JNDI

Une "ressource nommée" peut être définie au niveau du serveur d'applications, elle sera ensuite récupérée via JNDI.

- Définir la "ressource nommée" pour le serveur d'applications concerné

Pour Tomcat :
        Dans le fichier "web.xml" de Tomcat (fichier global pour toutes les webapps) :

      <env-entry>

          <env-entry-name>myTextValue</env-entry-name>

          <env-entry-type>java.lang.String</env-entry-type>

          <env-entry-value>foo</env-entry-value>

      </env-entry>

      <env-entry>

          <env-entry-name>myMaxValue</env-entry-name>

          <env-entry-type>java.lang.Integer</env-entry-type>

          <env-entry-value>10</env-entry-value>

      </env-entry>

        NB :
        - respecter l'ordre des tags "name/type/value"
        - pour un lancement dans Eclipse utiliser le fichier "web.xml" situé
          dans le workspace (dans  "Servers" )
       
        cf https://tomcat.apache.org/tomcat-7.0-doc/config/globalresources.html#Environment_Entries 

Pour Jetty :
        Dans le fichier "jetty.xml" ajouter une ressource avec une entrée du type :

     <New class="org.eclipse.jetty.plus.jndi.EnvEntry">
       <Arg></Arg> <!-- scope : empty = JVM scope-->
       <Arg>myTextValue</Arg> <!-- name -->
       <Arg type="java.lang.String">foo</Arg> <!-- value-->
       <Arg type="boolean">true</Arg>  

     </New>

        cf http://www.eclipse.org/jetty/documentation/current/using-jetty-jndi.html

- Récupérer la valeur de cette variable dans le code Java
  Exemple pour une chaine de caractères :

   String name = "myTextValue" ;

   try {

      Object value = InitialContext.doLookup("java:comp/env/"+name);

      System.out.println("JNDI OBJECT '"+ name + "' = '" + value + "'");

   } catch (NamingException e) {

      System.out.println("JNDI OBJECT ERROR : " + e.getMessage());

      e.printStackTrace();

   }

Installation d'un serveur Git sur Ubuntu

1 - Sur le serveur Git

1.1 - Installation de "git"

Ajout du "PPA (Personal Package Archive) officiel" fournit pat Git :
$ sudo add-apt-repository ppa:git-core/ppa

Mise à jour du "repository" utilisé par "apt-get" :
$ sudo apt-get update

Installation de Git
$ sudo apt-get install git

Test d'utilisation de Git
$ git --version
git version 2.11.0


(  Pour désinstaller Git et toutes ses dépendances :
 $ sudo apt-get remove --auto-remove git  )

1.2 - Création du user "git"

$ sudo adduser git
Saisie du password pour le user "git"

$ su git
$ cd
$ pwd
/home/git

1.3 - Création d'un "repository" vide

$ cd /opt/git
$ mkdir project1.git
$ cd project1.git
$ git init --bare
( l'option "--bare" sert à initialiser un dépôt sans répertoire de travail )
$ ls -lisa
Structure classique des fichiers et répertoire git :
   branches
   config
   description
   HEAD
   hooks
   info
   objects
   refs

2 - Sur le "client" Git

Sur le poste qui va se connecter au serveur...

2.1 - Mise en place de la connexion "ssh" avec clé publique

- Test de la connexion ssh avec mot de passe :
( sous Windows utiliser "Git Bash" qui permet de travailler en ligne de commande )
$ ssh git@<hostname> 
En l'absence de clé publique le mot de passe est demandé

- Génération des clés ( clé publique et clé privée ) si elles n'existent pas déjà
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which you want to save the key (xxx/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in xxx/.ssh/id_rsa.
Your public key has been saved in xxx/.ssh/id_rsa.pub.
The key fingerprint is :
... 
The key’s ramdonart image is:
... 
2 fichiers sont générés dans le répertoire $HOME/.ssh de l’utilisateur :
  - id_rsa  ( la clé privée )
  - id_rsa.pub  ( la clé publique )

- Copie de la clé publique sur le serveur git pour le user "git"
$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@<hostname>
git@<hostname>’s password:
Number of key(s) added: 1
Now try to logging into the machine, 
with "ssh 'git@<hostname>‘”

- Test de la connexion ssh sans mot de passe :
$ ssh git@<hostname> 
Le mot de passe n'est plus demandé

L'accès en "ssh" sans mot de passe est maintenant OK.
Git va donc pouvoir utiliser le serveur remote avec le protocole "ssh"

2.2 - Utilisation de Git en SSH à partir du poste client

Initialisation du repository local (sur le poste client)
$ git init

Création d'un fichier (par exemple un simple fichier ".txt" )

Staging et commit du nouveau fichier
$ git add .
$ git commit -m "Initial commit"

Définition du serveur "remote" avec un chemin absolu (SSH est le protocole par défaut)
$ git remote add origin git@<hostname>:/opt/git/project1.git
$ git remote -v

origin  git@<hostname>:/opt/git/project1.git (fetch)

origin  git@<hostname>:/opt/git/project1.git (push)
ou avec le préfixe "ssh://" pour être plus explicite
$ git remote add origin ssh://git@<hostname>:/opt/git/project1.git

Pour utiliser un chemin relatif : "/~" = répertoire "home" de l'utilisateur (ici home de "git")

$ git remote add origin ssh://git@<hostname>:/~/project1.git

Pour faire un "push" sur le serveur "remote"
$ git push origin master

     Vérification du résultat du "push" sur le serveur (remote)  :
     Côté serveur :
  $ git log       
     Le commit fait côté client doit apparaitre dans le résultat de la commande

Pour faire un "fetch" à partir du serveur "remote"
$ git fetch

3 - Au-delà du protocole SSH 

Le serveur Git peut être adressé avec différents protocoles

• file://
• ssh://
• git://
• http://
• https://

Le protocole git:// nécessite de lancer le "git daemon" sur le serveur,
il permet un accès non authentifié mais n'est pas "internet friendly" (il écoute sur un port spécifique, le 9418 par défaut)

Le protocole http:// ou https:// suppose la mise en place d'un serveur http,
généralement "Apache" avec utilisation de WebDAV ou du script CGI "git-http-backend"

Pour plus d'information sur les différents modes d'accès à un serveur Git voir l'article de Patrick Debois http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository/ 

Installation d'Apache 2 sur Ubuntu

Avant toute installation, mettre à jour le "apt-get repository" :

$ sudo apt-get update


Installation du paquet "Apache 2"

$ sudo apt-get install apache2 

Le service apache est démarré immédiatement après l'installation et écoute sur le port 80.

Liste des processus 

$ ps -edf | grep apache

 root      4927     1  0 17:04 ?        00:00:00 /usr/sbin/apache2 -k start

 www-data  4930  4927  0 17:04 ?        00:00:00 /usr/sbin/apache2 -k start

 www-data  4931  4927  0 17:04 ?        00:00:00 /usr/sbin/apache2 -k start

Test avec un navigateur :  

http://adresse-ip-du-host/

Affiche "Apache2 Ubuntu Default Page"

avec les principales informations sur les fichiers de configuration :

The configuration layout for an Apache2 web server installation on Ubuntu systems is as follows:

/etc/apache2/

|-- apache2.conf

|       `--  ports.conf

|-- mods-enabled

|       |-- *.load

|       `-- *.conf

|-- conf-enabled

|       `-- *.conf

|-- sites-enabled

|       `-- *.conf

The default Ubuntu document root is /var/www/html.

Installation du mod "PHP"

$ sudo apt-get install php5 libapache2-mod-php5

Tester avec un primier fichier ".php" dans "/var/www/html" :

$ cd /var/www

$ chmod 777 html

$ cd html

$ vi phpinfo.php

<?php
  phpinfo();
?>

Test avec un navigateur :  




http://adresse-ip-du-host/phpinfo.php

Affiche la page standard d'information sur la version de PHP utilisée

"PHP Version 5.6.4-4ubuntu6.4"

etc...

Pour utiliser MySQL avec PHP  :  

$ sudo apt-get install php5-mysql 

Pour utiliser PostgreSQL avec PHP  :  

$ sudo apt-get install php5-pgsql 

Redémarrer Apache 2 (après installation des paquets complémentaires de PHP5 )  :  

$ sudo service apache2 restart

Nouveau test avec le navigateur :

http://adresse-ip-du-host/phpinfo.php

La page doit contenir les infos relatives aux paquets complémentaires,

par exemple pour "PostgreSQL" :
    "pdo_pgsql"

    "pgsql"

Installation de PostgreSQL 9.4 sur Ubuntu

Avant toute installation, mettre à jour le "apt-get repository" :

$ sudo apt-get update

Installation de PostgreSQL 9.4 sur Ubuntu

$ sudo apt-get install postgresql postgresql-contrib

Voir les processus actifs de PostgreSQL :
$ ps -f -u postgres
6 processus actifs ( "postgres" est le user Linux )

Autoriser les connexions en "remote"

Dans le répertoire "/etc/postgresql/9.4/main" 

1) Modifier le fichier "postgresql.conf"

$ sudo vi postgresql.conf

listen_addresses = '*'

( le port par défaut est 5432 )

2) Modifier le fichier "pg_hba.conf"

$ sudo vi pg_hba.conf

# IPv4 local connections

host  all  all  (remote_ip)/32   md5

(autorise la connexion pour tous les utilisateurs pour toutes les bases à partir
du poste ayant l'adresse ip indiquée )

An IP address range is specified using standard numeric notation for the range's starting address, 

then a slash (/) and a CIDR mask length. The mask length indicates the number of high-order bits of the client IP address that must match. Bits to the right of this should be zero in the given IP address. There must not be any white space between the IP address, the /, and the CIDR mask length.

Typical examples of an IPv4 address range specified this way are :

 172.20.143.89/32   for a single host

 172.20.143.0/24    for a small network

 10.6.0.0/16      for a larger one

Restart Linux.

Création d'un utilisateur

Lancement de l'interpéteur SQL ( "psql" ) :

$ sudo -u postgres psql

Exemple : création d'un utilisateur "foo" avec mot de passe "foo" :

postgres=# create user foo createdb createuser password 'foo' ;

CREATE ROLE 

postgres=# 

Liste des utilisateurs existants :

postgres=# select * from pg_catalog.pg_user ;

postgres=# \q    (quit)

Création d'une base de données pour un utilisateur

$ sudo -u postgres psql

postgres=# create database foodb with encoding='UTF8' owner=foo connection limit=-1;

CREATE DATABASE

postgres=# 

Liste des bases de données existantss :

postgres=# \list

ou 

postgres=# select * from pg_database ;

Connexion JDBC à distance

Driver class : "org.postgresql.Driver"

URL : jdbc:postgresql://host:port/database

Exemple : 

   - URL : "jdbc:postgresql://10.226.159.81:5432/foodb"

   - User : "foo"

   - Password : "foo"

Installation de Telnet server sur Ubuntu

Deux paquets à installer : "telnetd" et "xinetd"

$ sudo apt-get install telnetd

$ sudo apt-get install xinetd 

Restart


Fichiers de configuration :

/etc/xinetd.conf

/etc/services  ( ports )

Exemple :

$ cat /etc/services | grep telnet

telnet          23/tcp

rtelnet         107/tcp                         # Remote Telnet

rtelnet         107/udp

telnets         992/tcp                         # Telnet over SSL

telnets         992/udp

tfido           60177/tcp                       # fidonet EMSI over telnet

Process : "telnetd"

$ ps -edf | grep telnet

telnetd   3494  3061  0 16:42 ?        00:00:00 in.telnetd: xxxxx

Test avec un client "Putty" sous Windows :

Conserver le port telnet par défaut : "23" 

Sélectionner "(o) Telnet "

JUnit Vade-mecum

Un petit mémo JUnit ...

Cycle de vie des instances et ordre d'exécution :

Remarques : l'API JUnit ne définit aucun ordre d'exécution des tests, ils doivent donc être exécutable dans n'importe quel ordre. Chaque test doit être indépendant des autres.
Cependant JUnit ver 4.11 permet de fixer l'ordre d'exécution avec l'annotation "@FixMethodOrder" qui peut être utilisée au niveau de la classe.
Exemple :
   @FixMethodOrder(MethodSorters.NAME_ASCENDING)
   public class MyTestCase {
      ...
   }

Sous Eclipse, pour faciliter l'utilisation des "assert" avec import statique :
Window / Preferences : Java / Editor / Content Assist / Favorites
ajouter org.junit.Assert.*

GIT vade-mecum

Un petit mémo GIT...

H2 : la base de données "de poche" au service des développeurs

H2 est une base de données relationnelle écrite en Java qui s'avère très utile pour les développeurs.

Cette base de données ultra-légère n'est pas conçue pour supporter de gros volumes de données ni un nombre important d'utilisateurs, mais elle est extrêmement pratique pour les développeurs Java qui ont besoin de tester des applications ou des composants nécessitants des requêtes SQL via JDBC.

H2 présente de nombreux avantages :

• légèreté : elle tient dans un fichier "zip" de 7 mo (y compris les sources et la documentation) 
• portabilité : elle est constituée d'un seul fichier "jar" qui peut être exécuté sur tout système d'exploitation disposant de Java
• fonctionnalités :  H2 dispose des mêmes possibilités que les "grandes bases de données" (schémas multiples, contrôle d'intégrité référentielle, triggers, fonctions, procédures stockés, colonnes auto-incrémentées, séquences, etc)
• différents modes de fonctionnement : client/serveur ou embarqué

Pour installer H2 :

1. Télécharger le fichier "Platform-Independent.zip" ( exemple : "h2-2014-08-06.zip" ) à partir du site http://www.h2database.com/ 
2. Décompresser le fichier "zip"
3. Pour démarrer la base : dans "bin" lancer "start.sh" ou "start.bat" selon le système d'exploitation
4. Et voilà, la base est prête à accepter des connexions, une IHM web est même lancée dans le navigateur

Emplacement de stockage des données 

H2 permet de stocker les données d'une base soit en mémoire (très utile pour des données temporaires par exemple pour des tests JUnit), soit sur disque.

L'emplacement est déterminé lors de la connexion par la dernière partie de l'URL JDBC 

Les différents modes de fonctionnement

1) Le mode "embarqué" ( "embedded" in english )

Dans ce mode le moteur H2 fonctionne dans la même JVM que l'application qui l'utilise. La "connexion" est donc réduite à sa plus simple expression puisqu'elle n'utilise pas le réseau. Le principal avantage de ce mode est qu'il n'est pas nécessaire de démarrer la base (en tant qu'application autonome) avant de s'y connecter, ce qui est extrêmement pratique pour des tests JUnit par exemple.

2) Le mode "client/serveur" ou "connexion à distance" (  "remote" ) 

Dans ce mode la base de données est lancée en tant qu'application de type "serveur" et elle va accepter des connexions de "clients" distants (comme une base de données Oracle, PostgreSQL, etc)

3) Le mode "mixte"

Il s'agit d'un mode dans lequel le moteur de la base de données est "embarqué" dans une application spécifique qui peut l'utiliser et le piloter (notamment le démarrer). Une fois lancé le moteur H2 peut être utilisé avec des connexions locales et/ou distantes.

Les différents types d'URL de connexion 

Avec H2 l'URL JDBC est fondamentale puisqu'elle indique dans quel mode on souhaite se connecter à la base ( "remote" ou "embedded") et l'emplacement ou sont stockées les données de la base (en mémoire ou sur disque dans un répertoire du filesystem).

Voici donc un tableau qui représente les différents cas possibles :

Configuration JDBC "out of the box" 
jdbc.driverClassName=org.h2.Driver ( la classe du driver JDBC est dans le jar "h2-version.jar" )
jdbc.url=jdbc:h2:mem:mydb 
jdbc.username=sa
jdbc.password=sa

Le petit plus : initialisation par un script SQL à la connexion 
Pour ça il suffit d'utiliser  INIT=RUNSCRIPT FROM 'file_name'
Exemples d'URL :

• jdbc:h2:mem:mydb;INIT=RUNSCRIPT FROM '~/init_mydb.sql'
  pour un script situé dans le répertoire du "user"
• jdbc:h2:mem:mydb;INIT=RUNSCRIPT FROM 'classpath:sql/init_mydb.sql' 
  pour un script chargé via le "classpath" (par exemple situé dans "/src/main/resources" )

Dans bien des cas ça remplace efficacement DBUnit pour les tests..

Pour plus d'informations, voir le site de référence ; http://www.h2database.com/ 

Autres liens :
https://stackoverflow.com/questions/5763747/h2-in-memory-database-table-not-found

Initialiser un projet dans Eclipse à partir de GitHub

Environnement utilisé : GitHub, Eclipse Kepler (4.3) avec eGit

1) Sur GitHub

Sélectionner le repository à cloner et copier son URL dans le presse papier

2) Dans Eclipse

Dans le workspace : Import  /  Git  /  Projects from Git

Clone URI

L'URI du repository s'affiche (URI copiée dans le presse papier), sinon Ctrl-V

Sélection de la branche à cloner ( en général c'est la branche "master" que l'on souhaite récupérer )

Définition de la destination locale :

Le plugin eGit va créer un repository Git local qui sera le "clone" de celui de GitHub et il va en extraire les sources dans un répertoire situé au même niveau.
Par défaut il propose de tout localiser dans le répertoire Git qui a été défini pour le poste, les fichiers du projet seront donc situés hors du workspace (ce qui ne pose pas de problème mais ça peut vite devenir compliqué à gérer)

Si on souhaite localiser le tout dans le répertoire du workspace courant il est possible de changer la destination en utilisant "Browse".
Exemple après avoir sélectionner l'emplacement du workspace "myworkspace"

Mais c'est là qu'il y a une subtilité :

Dans un premier temps eGit va cloner le projet dans le répertoire de destination.
Ensuite le wizard d'import tente d'importer le projet dans le workspace, mais
si le projet est situé à la racine du workspace on obtient un erreur du type
"D:\myworkspace\myproject overlaps the location of another project: 'myproject'"

Alors il va falloir laisser le projet hors du workspace ?  :-( 
Non, il suffit de créer un répertoire intermédiaire, par exemple "gitprojects"
et de demander à eGit de localiser la destination dans ce répertoire.

Et ainsi tout se passe bien, le projet est cloné par eGit et correctement importé dans le workspace d'Eclipse. Le répertoire intermédiaire n'étant pas visible dans l'environnement Eclipse il ne gêne en rien
et tous les projets du workspace sont bien regroupés dans le même répertoire.

Pour l'import, le plus simple est de prendre systématiquement l'option "Import as general project" et de convertir ensuite le projet dans le type approprié (Java, Maven, etc)

NB: si un fichier ".project" est présent parmi les fichiers provenant de GitHub l'import va lever une erreur du type "A .project file already exists in directory D:\myworkspace\git-projects\xxxx"
Dans ce cas supprimer le fichier ".project" du répertoire (hors d'Eclipse avec l'explorateur du système d'exploitation) faire "Back" et relancer l'import (c'est le .project de GitHub qui sera donc importé)

Créer un projet web statique sous Eclipse

Bon, je sais, Eclipse n'est pas l'environnement idéal pour faire un projet web statique d'envergure, mais pour une démo ou des prototypes pourquoi pas...

Le principe est extrêmement simple :

1. Créer un projet dans Eclipse pour gérer les ressources statiques du site
2. Installer et lancer un petit serveur HTTP qui va tourner en permanence et qui fera référence au ressources du projet

1) Créer le projet sous Eclipse

Option 1 : créer un projet "Web Static" 

   New / Project... / Web / Static Web Project

Avec ce type de projet il faut spécifier un "Web content folder name" qui va contenir les ressources gérées par le serveur http ( ici "www" ), ce qui correspond à une bonne pratique, ça évite de mélanger les fichiers du site web et la configuration du projet Eclipse.

Option 2 : créer un projet banalisé 

   New  /  Project... /  General  /  Project

Dans ce cas il n'y a pas de notion de "Web content folder name" (puisque le projet n'est pas de type "web")

Ce qui permet de considérer la racine du projet comme la racine du serveur web (ce qui n'est pas conseillé car tous les fichiers du projet seront exposés par le serveur). On pourra éventuellement définir un répertoire servant de "document root" ultérieurement.

2) Installer le serveur http

La on a le choix... Evidemment on pense immédiatement à ce bon vieux Apache, mais pour un simple environnement de développement c'est un peu lourd. Heureusement il existe plein de petits serveurs http ultra légers. Mon préféré c'est "Mongoose" (à télécharger ici : http://cesanta.com/mongoose.shtml ).

La version Windows fait 136 ko ! C'est un simple fichier ".exe" qu'il suffit de poser dans n'importe quel répertoire, puis de le lancer par un double-click. 

Une fois lancé une icone apparaît dans la barre des tâches et le navigateur démarre sur une URL composée de l'adresse IP du poste et du port "8080". Le répertoire par défaut des ressources du site étant le répertoire dans lequel le ".exe" est situé, le navigateur affiche donc cette page :

Il suffirait de poser des fichiers ".html" dans ce répertoire pour y accéder à partir du navigateur, mais pour ne pas tout mélanger on va évidemment personnaliser la configuration du serveur. C'est très simple il suffit de cliquer sur l'icône de la barre des tâches et de sélectionner "Advanced settings" pour ouvrir la page de configuration dans le navigateur ( ou simplement d'invoquer l'URL "http://localhost:8080/__mc" ).

Dans la configuration deux paramètres nous intéressent plus particulièrement :

document_root =  le répertoire qui contient les documents gérés par le serveur

listening_port   =  le port sur lequel le serveur écoute

Pour le listening_port, on va le valoriser par exemple à 9090 (pour éviter les collisions éventuelles avec Tomcat ou tout autre serveur du même genre)

Pour le document_root il va falloir le faire pointer sur le répertoire adéquat du projet Eclipse.
Il suffit de faire un click-droit sur le répertoire voulu dans le projet Eclipse + "Properties" / "Resources" pour voir l'emplacement dans le filesystem ( cf "Location" ). Un simple copier/coller fera l'affaire.

Ne pas oublier d'enregistrer par un click sur "Save settings to the config file" qui va créer le fichier de configuration "mongoose.conf".

Il suffit maintenant de stopper Mongoose et le redémarrer.

Invoquer l'URL  http://localhost:9090/ 

Et voila! Le serveur http est prêt il sert les fichiers à partir du répertoire projet Eclipse et il écoute sur le port 9090. Toutes les modifications apportées aux fichiers dans le projet sont donc immédiatement visibles dans le navigateur.

Pour réinitialiser le serveur Mongoose : 

• stopper le serveur
• supprimer le fichier "mongoose.conf"
• redémarrer le serveur : il se retrouve dans son état initial (comme à la première installation)

3) Autres serveurs http ultra léger

Deux alternatives à Mongoose :

• Pour ceux qui ont la chance de travailler sous Linux :
  LightHttpd ( http://www.lighttpd.net/ )
  Il existe une version pour Windows ( "LightTPD" du projet WLMP http://en.wlmp-project.net/ ),
  mais qui embarque toutes les dll de Cygwin
  
• Pour Windows :
  TinyWeb ( http://www.ritlabs.com/en/products/tinyweb/ )
  Un simple exécutable de 70 ko à lancer en ligne de commande 

Blog de dev's: Couchbase - Installation & Utilisation en Java

Blog de dev's: Couchbase - Installation & Utilisation en Java: Couchbase est une base de données NoSQL orientée documents. Les documents peuvent être par exemple des données clés/valeurs au format ...

Blog de dev's: Maven - Créer un archetype

Blog de dev's: Maven - Créer un archetype: Un archetype Maven permet la création rapide d'un nouveau projet à partir d'un projet existant qui sert alors de modèle. L'ob...

Cours en ligne

Petite compilation de cours en ligne très didactiques (pour débutants) :

• CodeSchool (Ruby, JavaScript, HTML/CSS, iOS, Git)
   https://www.codeschool.com/
  
• CodeAcademy (jQuery, JavaScript, PHP, Python, Ruby, APIs)
   http://www.codecademy.com/
  
• TreeHouse (PHP, Ruby, Git)
   http://teamtreehouse.com/
  
• CodeAvangers ( Web: HTML, CSS, JavaScript)
   http://www.codeavengers.com/
  
• Udacity ( catégorie "Computer science" : Java, Test, ... )
   https://www.udacity.com/

Eclipse Kepler - Créer un projet web-maven avec WTP et M2E

Après quelques années de galère à essayer de faire cohabiter les plugins WTP, M2E et Maven for WTP, les utilisateurs d'Eclipse commençaient à s'impatienter (surtout en voyant d'autres IDE dans lesquels tout ça était plutôt naturel et simple). Mais cette fois on y est, enfin presque (ouf !)

Il aura fallu attendre Eclipse 4.3 ( "Eclipse Kepler" : http://www.eclipse.org/kepler/ ) pour que la distribution "Eclipse IDE for Java EE Developers" soit livrée avec les plugins Maven pré-installés.

Kepler (qui pèse un peu plus de 250 Mb) arrive avec :
  - Maven Integration for Eclipse ( "m2e" )   ver 1.4.0
  - Maven Integration for Eclipse WTP    ver 1.0.0
Ces même versions sont disponibles pour Eclipse Juno (mais à ajouter manuellement)

Voici donc comment créer un projet web avec Maven et WTP ...

1) Création du projet 

Il s'agit dans un premier temps de créer directement un projet Maven (et non WTP)
en utilisant l' archetype  "maven-archetype-webapp"

File  /  New (ou Alt-Shift-N)  /  Maven project

Sélection de l'archetype pour "web app" :

Après création, le nouveau projet apparait dans le workspace.
Le nom du projet est l' Artefact Id de Maven
Pour changer le nom il suffit de faire  " Refactor / Rename "

2) Structure du projet 

La structure du projet est maintenant presque prête.

Mais parfois il manque des répertoires standards de Maven qui n’ont pas été créés (ça semble se produire à partir du deuxième projet créé dans un même workspace).
Ce qui provoque des erreurs au niveau du build path :

Si c'est le cas, il suffit de les ajouter :
  - Dans « src/main » : new folder « java »
  - Dans « src » : new folder « test/java », et tant qu’on y est « test/resources »

3) Configuration du "pom.xml"

En ouvrant le fichier "pom.xml" on constate qu'il contient assez peu de chose.
Trop peu, puisqu'il n'y a même pas les dépendances aux libraires Servlet/JSP.

Il n'y a donc plus qu'à le compléter en fonction des besoins du projets

Exemples :

* Pour ajouter les JARs nécessaires aux Servlets 3.0 et au JSP 2.2 (Tomcat 7, Jetty 8, Java EE 6)
dans "dependencies" :

<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>javax.servlet-api</artifactId>
   <version>3.0.1</version>
   <scope>provided</scope>
</dependency>
<dependency>
   <groupId>javax.servlet.jsp</groupId>
   <artifactId>javax.servlet.jsp-api</artifactId>
   <version>2.2.1</version>
   <scope>provided</scope>
</dependency>
<dependency>
   <groupId>jstl</groupId>
   <artifactId>jstl</artifactId>
   <version>1.2</version>
</dependency>

Pour forcer la version de Java  (ici Java 7)
dans "build/plugins"  :

<plugin>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>3.0</version>
   <configuration>
      <source>1.7</source>
      <target>1.7</target>
   </configuration>
</plugin>

* Pour configurer la production du « war »
dans  "build/plugins" :

<plugin>
   <artifactId>maven-war-plugin</artifactId>
   <version>2.3</version>
   <configuration>
      <failOnMissingWebXml>false</failOnMissingWebXml>
   </configuration>
</plugin>

Après avoir enregistrer les modifications du « pom.xml » ,
faire " Maven / Update project… "
pour répercuter la configuration du « pom.xml » sur le projet Eclipse

Le projet doit finalement avoir la structure suivante :

Et il ne doit plus y avoir aucune erreur nul part.

4) Tester le fonctionnement 

- Test avec une JSP :

Lancer l’exécution comme s’il s’agissait d’un projet web WTP classique :

Run as / Run on server 

On arrive sur la page « Hello world » produite par la JSP « index.jsp »,

si on modifie cette JSP il suffit de rafraîchir la page pour prendre en compte les modifications (comme dans tout projet WTP).

- Test avec une servlet :

Créer une nouvelle servlet dans  « src/main/java » 

(avec les servlet 3.0 il n’est pas nécessaire de déclarer cette nouvelle servlet dans le web .xml, une annotation suffira)

Conclusion

Avec une installation Eclipse Kepler de base il est maintenant assez simple de gérer des projets web.

Pour ceux qui veulent aller un peu plus loin il ne reste plus qu'à créer ses propres archetypes Maven...

Pour plus d'informations :

- http://www.eclipse.org/m2e/ 

- http://www.eclipse.org/m2e-wtp/

Eclipse - Les principaux raccourcis

Avec la pratique chacun a ses raccourcis préférés, ils deviennent vite des réflexes conditionnés.
Même après des années d'utilisation on peut encore en découvrir de nouveaux. Voici donc mon "Best Of" des raccourcis Eclipse (évidemment incomplet), initialement destiné à mes étudiants mais pouvant intéresser  tous les développeurs Java utilisant Eclipse.
Cette liste ne demande qu'à être complétée, toutes les suggestions sont donc les bienvenues ...

---

Recherches (à partir de n'importe quelle vue) : 

 Ctrl - Shift - T    :  "Open Type"
Rechercher un "Type Java" (classe, interface, annotation, ... ) dans les sources (.java) et dans les .jar (.class)

 Ctrl - Shift - R    :  "Open Resource"
Rechercher un fichier dans le workspace (quel que soit le type du fichier)

Dans les deux cas différents patterns de recherche peuvent être utilisés :
Wilcards :
  *  n'importe quelle suite de caractères
  ?  n'importe quel caractère
  <  ou  "blanc" pour marquer la fin du pattern
Notation "camel case" :
Exemples :
  "TZ" : "TimeZone"
  "NuPoEx": java.lang.NullPointerException

---

Dans l'éditeur de code Java :

 Ctrl + S    :  "Save" 

Enregistre le fichier en cours d'édition

 Ctrl + ESPACE    :  "Content Assist" 

Propose une assistance à la saisie ("code completion")

 Ctrl + O    :  "Quick Outline" 

Affiche une fenêtre avec la liste des méthodes et des champs définis dans la classe en cours

Un deuxième "Ctrl+O" affiche toutes les méthodes et les champs (classe en cours + héritage )

 Ctrl + Shift + O   :  "Organize Imports"

Ajoute les imports nécessaires et réorganise la liste par ordre alphabétique

 Ctrl + Shift + F    :  "Format"

Formate le code (lignes de code sélectionnées ou toutes les lignes si aucune sélection)

 Ctrl + Shift + I    :  "Correct Indentation"

Corrige l'indentation du code pour les lignes sélectionnées.

 Alt + Shift + J    :  "Generate Comment"

Génère un bloc de commentaire de type JavaDoc pour la classe, la méthode ou le champ (en fonction de la position du curseur).

 Ctrl + Shift + /    :  "Add/Remove comment"

Ajoute ou supprime "//" au début de chacune des lignes sélectionnées

 Ctrl + T    :  "Quick Type Hierarchy" 

Affiche une fenêtre avec la hiérarchie de la classe en cours

Un deuxième "Ctrl+T" permet de changer le sens de la hiérarchie ( supertype / subtype )

 Ctrl + Alt + H    :  "Open Call Hierarchy" 

Affiche la vue "Call Hierarchy" pour la méthode sélectionnée

 Alt + Shift + B    :  "Show in Breadcrumb" 

Active le bandeau "breadcrum" dans les éditeurs de code Java
(pour désactiver le bandeau utiliser l'icône)

 Alt + Shift + O    :  "Mark Occurrences" 

Active le surlignage de toutes les occurrences identiques à celle qui est sélectionnée.
(raccourci de type "switch" : activation/désactivation)

 Ctrl + Shift + P    :  "Go to Matching Bracket"

Se place sur le { ou } correspondant à celui sur lequel se trouve le curseur 

 Shift + F2    :  "JavaDoc"

Affiche la JavaDoc pour le type sélectionné (ou la méthode sélectionnée) dans une vue de type navigateur.

---

Dans la vue "Package Explorer" :

 F4   :  Affiche la vue "Type Hierarchy" pour la classe sélectionnée (héritage)

---

Référence et déclaration Java :

Dans le code, sélectionner un type (classe, interface, ...), puis :

 F3   :  "Open Declaration"

Ouvre le fichier ".java" correspondant au type sélectionné

 Ctrl + G   pour rechercher la déclaration de ce type dans le workspace ( fichier ".java" dans les sources ou ".class" dans un .jar)

(ou click-droit + "Declarations") 

 Ctrl + Shift + G  pour rechercher les références à ce type dans le workspace

(ou click-droit + "References") 

---

Divers :

 Ctrl + M    :   pour passer la vue courante en taille maximale/normale (switch)

 Ctrl + F8    :   pour basculer vers une autre perspective

 Alt + Shift    :  bascule clavier français - clavier américain  (switch)

NB : Cette combinaison de touches est souvent utilisée par inadvertance ( notamment pour l'ajout de commentaires avec Alt+Shift+J ) 

---

Tous les raccourcis :

Enfin, pour connaitre tous les raccourcis disponibles, il suffit d'aller voir dans les préférences d'Eclipse :

Menu : "Window" - "Preferences",  Rubrique : "General" - "Keys" 

ou d'utiliser le raccourci   Ctrl + Shift + L 

---