Sérieusement, on est en train de révolutionner le monde des intermédiaires sans foi ni loi. En quelques mots :

1. Le site est entièrement gratuit tant qu’on n’a pas un devis accepté.
2. La commission est 3 fois moins importante qu’un intermédiaire classique (moins de 10% pour Hopwork contre 15%-25% actuellement)
3. On peut contractualiser en direct (ou pas, à vous de choisir)
4. Les freelances sont « approuvés » par leurs pairs et par leurs clients

Pas de ticket d’entrée

Non mais allô quoi, payer pour chercher un développeur ou une mission alors qu’on n’est pas sûr de trouver un deal ? Ça gave ! Hopwork prend clairement le modèle d’Airbnb, on cherche autant qu’on veut, on ne paye que si on trouve !

Commission raisonnée

Quand un intermédiaire classique prend facilement 20% si ce n’est plus, Hopwork ne prendra que 9% sur des missions courtes et ce sera bientôt dégressif en fonction du volume. Quoi de plus logique ? On paye la mise en relation, c’est ce qui a le plus de valeur, ensuite on paye le service (facturation, paiement, litige, recommandations clients etc.)

Contractualisation en direct

Là aussi, franchement en tant que freelance, je ne veux pas avoir une 3ème personne dans la relation, qui a des intérêts potentiellement divergents des miens. Et pour le client qui souhaite pouvoir parler à quelqu’un d’autre que le freelance pour des raisons qu’on peut imaginer aisément (notamment en cas de litige), le service client d’Hopwork est là pour ça !

Freelances approuvés

En plus de la localisation, le moteur de recherche met en avant les freelances qui ont le plus de recommandations et le plus de commentaires satisfaisants des clients. Un gage de sécurité pour le client et un bon moyen de se mettre en avant et d’augmenter son business pour les meilleurs d’entre nous !

Garantie de paiement

Pour les missions courtes, le client déposera un acompte sur un compte de séquestre. Pour une mission longue, Hopwork se chargera du recouvrement. Zéro tracas, Zéro blabla pour reprendre une pub bien connue

Nouveaux clients

Les clients sont souvent verrouillés par les SSII et autres intermédiaires (qui en profitent bien en passant pour faire de belles marges mais passons). Hopwork déverrouille ces clients en ce faisant référencer pour vous. Et va même plus loin en entrant chez certains clients réputés pour ne pas prendre de freelances ! Et n’oubliez pas, vous contractualisez avec le client, ouf non ?

Elle est où l’arnaque ?

L’astuce est dans le contrat que vous faites avec Hopwork, en vous inscrivant sur Hopwork, vous vous engagez à payer la mise en relation à Hopwork. Hopwork vous enverra une facture pour chaque mise en relation.

Quoi encore une facture à payer ? relou !!

Non pas relou, le client vous paye en passant par la plateforme de paiement Hopwork. (Virement ou CB) Ensuite Hopwork vous envoie votre part défalqué de la commission. Comptablement vous avez fait 100% du CA et payé une prestation de mise en relation. Toutes les factures sont générées et disponibles à tout moment. Vous n’avez rien de fait de plus que d’habitude. : Zéro tracas, Zéro blabla !

Alors, bonne idée ? Allez-vous nous rejoindre sur Hopwork et participer à l’aventure ?

Arquillian est un outil qui permet de faire des tests d’intégration. Il permet notamment de construire programmatiquement des jar, war et ear très simplement et de déployer ces pseudos-livrables dans un serveur embarqué.

Étant adepte du TDD, quand on me demande de faire un service web, j’aime me mettre à la place du client web et manger du HTTP afin de vérifier le contenu des retours mais aussi les entêtes, les E-Tag, la compression etc… C’est que nous permet de faire Rest-Assured. Nous allons justement voir dans cet article comment tester un service web par la couche HTTP en se servant d’Arquillian pour déployer le service de manière embarqué.

Dans cet exemple, nous utilisons le serveur glassfish embedded. Nous testons un service REST permettant de consulter des logs applicatifs. Ainsi on souhaite vérifier que la requête HTTP : « GET http://localhost:8181/logs?severity=error » retourne bien un code HTTP 200 OK.

Le Test

Voici le code test que nous souhaitons faire :

import org.jboss.arquillian.container.test.api.RunAsClient;
import org.jboss.arquillian.junit.Arquillian;
import com.jayway.restassured.RestAssured;
import com.jayway.restassured.parsing.Parser;
import com.jayway.restassured.specification.ResponseSpecification;
import static com.jayway.restassured.RestAssured.expect;
import static com.jayway.restassured.RestAssured.given;

@RunWith(Arquillian.class)
public class SomeArquillianTest{

  @Test
  @RunAsClient
  public void simpleClientTestExample(@ArquillianResource URL baseURL) throws IOException {
    expect().statusCode(200).when().get(baseURL.toString() + "logs?severity=ERROR");
  }
}

• @RunWith(Arquillian.class) permet d’utiliser le runner JUnit d’Arquillian.
• @RunAsClient permet de marquer le test comme étant un test de type « Client ».
• @ArquillianResource permet d’injecter l’url de base afin de connaitre l’addresse http de l’application.

Créer l’archive à déployer

Afin qu’Arquillian puisse créer une archive de déployement, il suffit de lui spécifier les composants que nous souhaitons tester (classe annotées @Stateless par exemple.) ainsi que le container / Servlet et le fichier web.xml .

import com.sun.jersey.spi.container.servlet.ServletContainer;

import org.jboss.arquillian.container.test.api.Deployment;

import org.jboss.arquillian.test.api.ArquillianResource;
import org.jboss.shrinkwrap.api.Archive;
import org.jboss.shrinkwrap.api.ArchivePaths;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.EmptyAsset;
import org.jboss.shrinkwrap.api.spec.WebArchive;

@RunWith(Arquillian.class)
public class simpleClientTestExample {

  @Deployment
  public static Archive<?> createTestArchive() {
    return ShrinkWrap.create(WebArchive.class)
        .addPackages(true, Log.class.getPackage(),
        LogServiceRest.class.getPackage(),
        LogService.class.getPackage())
        .addClass(ServletContainer.class)
        .setWebXML("WEB-INF/web.xml")
  }

Changer le port du serveur embarqué

• Le port par défault pour glassfish-embedded est : 8181 (https://docs.jboss.org/author/display/ARQ/GlassFish+3.1+-+Embedded)
• Il est possible de surcharger cette propriété, comme toutes les autres d’ailleurs, dans le fichier arquillian.xml :

<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
  <engine>
    <property name="deploymentExportPath">target/arquillian</property>
  </engine>
  <container default="true" qualifier="glassfish">
    <configuration><property name="bindHttpPort">8181</property></configuration>
  </container>
</arquillian>

La pomme

Voici un extrait de ma pomme, à adapter selon votre situation…

<dependencies>
  <dependency>
    <groupId>org.glassfish.main.extras</groupId>
    <artifactId>glassfish-embedded-all</artifactId>
    <scope>provided</scope>
  </dependency>
  <dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <scope>provided</scope>
  </dependency>
  <!-- Librairies for test -->
  <dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-library</artifactId>
    <version>1.3</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
  </dependency>
  <dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-container</artifactId>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>com.jayway.restassured</groupId>
    <artifactId>rest-assured</artifactId>
    <scope>test</scope>
  </dependency>
</dependencies>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <version>2.2</version>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-dependency-plugin</artifactId>
      <version>2.1</version>
      <executions>
        <execution>
          <phase>validate</phase>
          <goals>
            <goal>copy</goal>
          </goals>
          <configuration>
            <outputDirectory>${endorsed.dir}</outputDirectory>
            <silent>true</silent>
            <artifactItems>
              <artifactItem>
                <groupId>javax</groupId>
                <artifactId>javaee-endorsed-api</artifactId>
                <version>6.0</version>
                <type>jar</type>
              </artifactItem>
            </artifactItems>
          </configuration>
        </execution>
      </executions>
    </plugin>
 </plugins>
</build>

Et voilà !  Plutôt simple non ?

Je suis associé depuis le début de cette année à 4 compagnons d’aventure :

• Hugo Lassiège ( hakanai.free.fr )
• Olivier Girardot ( http://www.readtfb.net/ )
• Florent Biville ( http://florent.biville.net/ )
• Jonathan Winandy ( http://hbrain.net/)

Liberté ++

Et oui, quand on est freelance, on est un peu plus libre qu’un salarié, mais que faire de cette liberté seul ? C’est incroyable ce qu’on peut faire quand on est plusieurs, ne serait que 5 pauvres petits développeurs. Depuis la création de Lateral-Thoughts, il y a quelques mois seulement :

• Nous sommes devenus organisme de Formation (certains freelances le sont aussi mais beaucoup se contentent de se faire porter pour donner des formations)
• Nous avons noué un partenariat avec un éditeur de base de données NoSQL (quel freelance peut faire ça ?)
• Nous nous sommes passé d’intermédiaires ! Certains freelances y arrivent aussi, mais là, c’est juste plus simple.au

Finalement se regrouper dans une structure de type NoSSII(a) telle que LT c’est donner un sens à sa liberté, ou plus généralement, découvrir ce que devrait être une société composée de professionnels de l’informatique.

Tout n’est pas rose

Et oui, ce serait trop facile sinon. LT est une société qui innove dans son organisation en copiant honteusement le principe agile d’auto-organisation. LT est clairement auto-organisée. Chaque membre est libre de prendre le lead sur un sujet qui l’intéresse. Il est parfois rejoint par d’autres, et à chaque fois soutenu par tout le groupe. Mais que faire lorsque personne ne souhaite prendre le lead sur un sujet pourtant important ? Ou que faire si le sujet est trop vaste pour qu’une seule personne s’en occupe alors qu’il faudrait être plusieurs ? L’exemple le plus flagrant est notre site Internet, quelques peu délaissé, faute de temps et de motivation.

Mais ce n’est pas grave, en agrandissant notre cercle, nous trouverons sans nul doute les bras qui nous manquent pour faire aussi bien que nos SSII favorites et bien aimées (Xebia, So@t, Zenika, Valtech, pour ne citer qu’elles).  Traduction : nous sommes ouverts aux candidatures.

La cerise sur le gâteau

C’est cool, quand j’étais freelance il m’est arrivé de financer un hands-on ou 2 organisés par Mathilde et les Duchess (Location de la salle ou repas). Mais aurai-je pu me permettre de payer une semaine de startup-week-retreat à 7 développeurs passionnés ? Et non, trop cher pour mon petit porte-monnaie. En revanche, à 5 on peut aisément le faire, et c’est ce que nous avons fait !

Dès demain, nous partons à Guérande, pour 8 jours de code intensif avec 4 membres de LT et 3 potes : @nivdul @piwai et @ubourdon . Au programme, du fun : Scala, Android, MongoDB  (rien n’est fixé à l’avance, on décidera sur place ce qu’on fait, à la manière d’un hackergarten). Mais aussi de la souffrance : tennis, piscine, jogging et bodyboard … L’idée c’est vraiment de progresser tous ensemble dans la joie et la bonne humeur ^^

On devrait renouveler l’expérience cet hiver ! Si l’expérience vous intéresse, suivez nos blogs ou nos twitter, ça devrait blogguer pendant la semaine

Premièrement, ajouter un champ input acceptant l’ajout de plusieurs fichiers :

 <input id="files" multiple="multiple" name="file[]" type="file">

Ensuite, uploadons les fichiers en utilisant les « FormData » d’HTML5 :

var upload = function (file) {
      var data = new FormData();

      data.append('name', file.name);
      data.append('file', file);

      $.ajax({
         url:'/photo',
         data:data,
         cache:false,
         contentType:false,
         processData:false,
         type:'POST'
      }).error(function () {
                 alert("unable to upload " + file.name);
              })
              .done(function (data, status) {
                 doSomethingUseful(data);
              });
   };

   function multiUpload(files) {
      for (var i = 0; i < files.length; i++) {
         // Only upload images
         if (/image/.test(files[i].type)) {
            upload(files[i]);
         }
      }
   }

   $(document).ready(function () {
      $("#files").change(function (e) {
         multiUpload(e.target.files);
      })
   });

Coté serveur, avec Jersey, il faut inclure le module « multipart » :

<dependency>
    <groupId>com.sun.jersey.contribs</groupId>
    <artifactId>jersey-multipart</artifactId>
    <version>1.13</version>
</dependency>

Ensuite le code est plutôt simple :

import javax.inject.Inject;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;

import com.sun.jersey.core.header.FormDataContentDisposition;
import com.sun.jersey.multipart.FormDataParam;
import java.io.IOException;
import org.apache.log4j.Logger;
import org.springframework.stereotype.Controller;

@Controller
@Path("/photo")
public class PhotoResource extends AbstractResource {
    private static final Logger LOG = Logger.getLogger(PhotoResource.class);

    @Inject
    private FileRepository fileRepository;

    @GET
    @Produces("image/png")
    @Path("/{photoId}")
    public byte[] photo(@PathParam("photoId") String photoId) {
        try {
            return fileRepository.get(photoId);
        } catch (IOException e) {
            LOG.warn("When get photo id : " + photoId, e);
            throw ResourceException.notFound();
        }
    }

    @POST
    @Consumes(MediaType.MULTIPART_FORM_DATA)
    @Produces(MediaType.TEXT_PLAIN)
    public String addPhoto(@FormDataParam("file") byte[] photo,
                           @FormDataParam("file") FormDataContentDisposition fileDetail) {
        String photoId = null;
        try {
            photoId = fileRepository.save(photo);
        } catch (IOException e) {
            LOG.error("unable to add photo", e);
            throw ResourceException.error(e);
        }
        return photoId;
    }
}

Et pour s’amuser, stockons les fichiers dans Mongodb grace à GridFS :

import javax.annotation.PostConstruct;
import javax.inject.Inject;

import com.mongodb.gridfs.GridFS;
import com.mongodb.gridfs.GridFSInputFile;
import java.io.IOException;
import org.apache.commons.io.IOUtils;
import org.bson.types.ObjectId;
import org.jongo.Jongo;
import org.springframework.stereotype.Repository;

@Repository
public class FileRepository {

    private Jongo jongo;
    private GridFS files;

    @Inject
    public FileRepository(Jongo jongo) {
        this.jongo = jongo;
    }

    @PostConstruct
    public void afterPropertiesSet() throws Exception {
        files = new GridFS(jongo.getDatabase());
    }

    /**
     * Save a file and return the corresponding id
     */
    public String save(byte[] file) {
        GridFSInputFile savedFile = this.files.createFile(file);
        savedFile.save();
        return savedFile.getId().toString();
    }

    /**
     Return the file
    */
    public byte[] get(String fileId) throws IOException {
        return IOUtils.toByteArray(files.findOne(new ObjectId(fileId)).getInputStream());
    }
}
}

Et si vous voulez faire du drag and drop, il suffit d’inclure ce plugin jQuery : drop.js et de faire comme ceci :

 $(document).ready(function () {
         $('body').dropArea();

         $('body').bind('drop', function (e) {
            e.preventDefault();
            e = e.originalEvent;
            multiUpload(e.dataTransfer.files);
         });
      });

Sources :

• http://blog.alexmaccaw.com/svbtle-image-uploading
• http://www.mkyong.com/webservices/jax-rs/file-upload-example-in-jersey/
• http://www.mongodb.org/display/DOCS/gridfs

Enfin presque, l’idée est d’installer un server X virtuel : Xvfb

% sudo apt-get install xvfb

Ensuite lancer le server X virtuel :

% Xvfb :1 &

:1 permet de spécifier le nom du « display »

Et pour finir, le build selenium ( ou n’importe quelle commande ayant besoin d’un « display »)

DISPLAY=:1 mvn clean install

Du coup la documentation de Redis est simple. Un autre truc que j’aime c’est qu’elle spécifie la complexité de chaque opération, ce qui permet au développeur de vérifier à chaque fois que la commande qu’il s’apprête à utiliser n’est pas trop gourmande. De plus, il n’a pas le risque d’oublier de mettre un index sur un champ (combien de fois cela arrive en SQL ou avec MongoDb ! ) car toutes les clés sont par définition « indexées » dans une (Hash) Map.

Simple et (donc ?) performant. Redis est sans doute ce qu’il y a de plus performant en terme de base de données. Nous avons donc intérêt à nous y intéresser avant de chercher des solutions plus complètes et donc plus complexes et moins performantes.

Sauf que, Redis ne stocke que des chaînes de caractères. Comment faire pour stocker nos objets métiers complexes ?

On pourrait simplement utiliser une base de données SQL pour stocker notre modèle et utiliser un ORM pour que ce soit « simple ». Ensuite dans Redis on ne stockerai que la dé-normalisation de certaines requêtes : 3 meilleurs clients => { 1 => id:130 ; 2 => id:345 ; 3 => id:456 } Ainsi la requête pour récupérer les identifiants des trois meilleurs clients se fera en temps constant O(1) puis la requête pour récupérer les données des trois clients dans la base SQL se fera également en temps constant,  car les clés primaires sont indexées dans les bases SQL.

Mais il faut avouer que c’est embêtant de devoir gérer deux bases de données, surtout quand on pourrait simplement sérialiser les objets directement dans Redis.

Stocker les objets Java dans Redis grâce à Jackson

Dans notre exemple, le besoin est de pouvoir insérer des liens dans des listes et de pouvoir récupérer en temps constant tous les liens d’une liste donnée.
Jackson est un sérialiseur Objet -> JSON. Ce qui est parfait pour pouvoir lire facilement les objets sérialisé où pour pouvoir les utiliser directement en JavaScript, sans passer par une dé-sérialisation.

On va utiliser JAX-B pour annoter nos objets Java, par exemple :

@XmlRootElement(name = "links")
@XmlAccessorType(FIELD)
public class BannerLink {
   private String label;
   private String url;

   public BannerLink(String label, String url) {
      this.label = label;
      this.url = url;
   }

   public String getLabel() {
      return label;
   }

   public String getUrl() {
      return url;
   }

   protected BannerLink(){}
}

Notez que Jackson sait aussi sérialiser des POJOs (sans JAX-B mais avec Setter)

Ensuite il suffit de sérialiser l’objet avec Jackson pour l’insérer dans une liste Redis.

      AnnotationIntrospector introspector = new JaxbAnnotationIntrospector();
      mapper.getDeserializationConfig().setAnnotationIntrospector(introspector);
      mapper.getSerializationConfig().setAnnotationIntrospector(introspector);

      jedis.rpush("listKey", mapper.writeValueAsString(link));

Pour la lecture, il suffit de dé-sérialiser les objets de la liste.

   mapStringsToLinks(jedis.lrange(key, 0, jedis.llen(key)));

   private List mapStringsToLinks(List jedisResult) {
      return Lists.transform(jedisResult, toBannerLink());
   }

   private Function<String, BannerLink> toBannerLink() {
      return new Function<String, BannerLink>() {

         @Override
         public BannerLink apply(@Nullable String link) {
            return mapper.readValue(link, BannerLink.class);
         }
      };
   }

Je ne sais pas vous, mais moi je trouve ça vraiment plus simple de persister directement et simplement les instances d’objets, telle quelle, sans se prendre la tête avec du mapping, jointure ou autre joyeuseté.

Performances

Je n’ai pas fait le test avec une base SQL et un ORM de type Hibernate mais n’hésitez pas à forker le code et à le faire, ça m’intéresse.

Aucun tuning n’a été fait sur les bases de données. Mongo est bien meilleur en écriture et peut être encore meilleur, car il ne garantie pas que les données sont effectivement écrites sur le disque, j’avoue ne pas avoir cherché à optimiser Redis pour l’écriture, j’ai gardé la configuration par défaut.

En revanche, Redis est bien meilleur en lecture, malgré le surplus de traitements dû à la désérialisation Jackson. Et c’est ce qu’on cherche dans notre cas d’usage, nos listes de liens vont être lus beaucoup plus souvent que modifiées. Et pour ceux qui se poseraient la question, oui j’ai bien créé les indexes dans Mongo.

Ce qu’il faut retenir, c’est que dans bien des cas, une base de données document ou SQL n’est pas forcément obligatoire et qu’il vaut mieux démarrer simple et (très) efficace, quitte à changer par la suite…

Un peu de lecture si vous souhaitez en savoir plus sur Redis : Redis: the Definitive Guide: Data Modeling, Caching, and Messaging

@Configuration
public class RequestConfiguration {

   @Value(value = "${repository?InMemoryRepository}")
   private String repository;
}

Pour ce faire, il faut configurer le property placeholder de Spring pour :

1. Ignorer les @Value vide
2. remplacer le séparateur par défaut (« : ») par « ? » qui est plus parlant.

<bean id="placeholderConfig">
   <property name="locations">
      <list>
         <value>classpath:conf.properties</value>
      </list>
   </property>
   <property name="ignoreResourceNotFound" value="true"/>
   <property name="ignoreUnresolvablePlaceholders" value="true" />
   <property name="valueSeparator" value="?" />
</bean>

Et voilà !

Maintenant il faut faire attention car Spring va ignorer toutes les properties null ce qui pourra provoquer des NullPointerException à l’exécution plutôt que des erreurs de configuration au démarrage de l’application…

Avec Jersey, l’implémentation de référence de JAX-RS (JSR311) pas de prise de tête, tout est générés automatiquement.

Il suffit de faire deux choses :

1. Créer une classe de type « com.sun.jersey.api.wadl.config.WadlGeneratorConfig »
2. Passer cette classe en paramètre d’initialisation de votre servlet

public class SchemaGenConfig extends WadlGeneratorConfig {

    @Override
   public List configure() {
      return generator( WadlGeneratorJAXBGrammarGenerator.class).descriptions();
   }
}

<servlet>
   <servlet-name>
      banner
   </servlet-name>
   <servlet-class>
      com.lateralthoughts.commons.web.LateralCommonsServlet
   </servlet-class>
   <init-param>
      <param-name>
         com.sun.jersey.config.property.WadlGeneratorConfig
      </param-name>
      <param-value>
         com.lateralthoughts.commons.web.wadl.SchemaGenConfig
      </param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>

Le  WADL est maintenant généré et accessible à cette adresse : http://localhost:port/maservlet/application.wadl

Pour aller plus loin, le wiki d’Oracle : https://wikis.oracle.com/display/Jersey/WADL

Merci à Aurélien Thieriot pour l’astuce

Devoxx France en deux mots : C’est la plus grande et la plus intéressante des conférences pour les développeurs Java en France.

Pour moi, ce fut une expérience formidable. En plus d’avoir appris quelques trucs, ce qui m’a fait le plus plaisir c’est d’avoir été conforté sur pas mal de choix que j’ai pu faire ou que je comptais appliquer  prochainement. Hormis l’absence de desserts sucrés et le nombre limité de boissons, l’organisation fut parfaite. Un grand bravo aux organisateurs !

J’ai choisi d’illustrer ces trois jours de conférences par une série d’articles qui racontent ce que pourrait être une success story pour un développeur Java ayant eu une « idée » :

Pour la petite histoire, je craignais au début que limiter à 25% le nombre de speakers anglophones allait mathématiquement faire baisser le niveau des speakers. Cela c’est avéré faux, le niveau des Français fut excellent, même meilleurs que les anglophones que j’ai pu voir. Bravo à tous et vive la France !

Quant à moi (beaucoup m’ont posé la question),  si je n’ai rien présenté et que je n’ai pas non plus voulu participer à la préparation de cette première de Devoxx France bien que je sois un Geek Passionné avec plein de choses à raconter, c’est que j’ai déjà beaucoup de projets en cours et  je pense qu’il est important de garder un certain équilibre entre vie professionnelle, loisirs, famille et amis afin de ne pas finir en « burnout » (En passant j’ai bien rigolé en lisant http://501manifesto.org/ ).

Je remercie ma société de m’avoir payé la conférence ainsi que l’hôtel au Marriott (4 étoiles c’est la classe !). Et si vous n’êtes pas encore Freelance ou que vous ne faites pas partie d’une société qui vous laisse gérer votre budget tel que Lateral Thoughts, il est peut être temps d’y réfléchir…

A l’année prochaine à Devoxx !

Web Oriented Architecture

Avant d’être Startupeur, Gérard était architecte urbaniste respecté et vénéré. Mais trop souvent, il a essayé de plier le web pour faire des applications dites « Stateful » où l’état du client est conservé côté serveur via les sessions. Ce qui amène pas mal de problèmes, en terme de performance bien sûr, car il est du coup difficile d’avoir un cache efficace, mais aussi des problèmes de développement, qui n’a jamais galéré à gérer le bouton « back » et à devoir mettre un bouton « back » spécifique dans son application alors que le navigateur lui-même en possède déjà un ?

La présentation de Habib, qui s’approche de la keynote a hypnotisé le public (et Gérard) en cassant les architectures dites « stateful » et antiweb, celle de Sadek et Guillaume montre que Play! pousse le développeur à embrasser le Web plutôt qu’à lutter contre lui.

Mais au fait c’est quoi une architecture Web ?

• Ressource based : Utilisation des URI et des mediatypes pour identifier et exprimer les « ressources » fournies par l’application
• Stateless : L’état de la conversation est gérée côté client, dans le browser. Le client change l’état de l’application via des commandes au serveur (verbes http PUT, POST et DELETE)
• HTTP powered : Utilisation du protocole HTTP et de ses verbes à bon escient : PUT, POST, DELETE, GET. Une application qui embrasse le web est une application qui ne fait que du CRUD.

WAT ? Mais comment va faire Gérard pour ne faire que du CRUD ? Son application fait des vrais trucs de barbus.

En fait c’est super simple, lorsque vous avez de faire un truc « compliqué » (qui n’est pas CRUD), comme par exemple, déplacer une somme d’argent d’un compte A (ressource) à un compte B (autre ressource) vous n’allez, côté client ni demander de modifier le compte A, ni demander de modifier le compte B, mais ajouter  une ressource à votre système (via un PUT) et ça, ben c’est du CRUD. Cette commande déclenchera l’exécution de notre traitement métier « complexe » de manière « Atomic » et « Asynchrone » (Toi qui es perspicace tu auras reconnu l’objet bancaire Transaction )

Ceci permet d’avoir entre autre une interface réactive, car l’envoie d’une commande dans une  queue est d’une complexité constante.

Ha oui mais du coup, quand on va requêter pour savoir combien il y a sur le compte B il va falloir parcourir toutes les transactions ! (Gérard est fier de sa perspicacité)

Biensûr que non !! La solution est dans le chapitre en dessous avec CQRS, on va séparer le modèle métier d’écriture et le modèle métier de lecture et pré-calculer, dé-normaliser pour être efficace autant en écriture qu’en lecture.

Pour aller plus loin : Implementing REST

CQRS

Le lien fort entre CQRS  et la WOA, c’est le CRUD, une architecture CQRS est une architecture à base de commande, comme en WOA, l’idée est de créer des commandes plutôt que de modifier plusieurs entités du modèle. Cela revient donc à faire du CRUD, comme en WOA.

Une architecture CQRS  (Command Query Responsabilty Segragation) sépare le modèle d’écriture du modèle de lecture  ce qui va permettre :

• De ne pas fetcher d’informations inutiles (On n’a pas besoin du nom du client B pour calculer le solde du client A …) Qui n’a jamais du fetcher des informations inutiles parce que le modèle est unique pour toute l’application ?
• De pré-calculer de manière asynchrone toutes les opérations fortement demandées pour s’approcher d’une complexité constante ( ou linéaire, mais sur un nombre réduit d’éléments).

Bien, se dit Gérard, mais si je suis asynchrone, je ne vais pas voir tout de suite le résultat de ma transaction sur mon compte ! C’est vrai. Mais ce n’est pas grave il faut être « relax », Habid appelle ça la « relaxation temporelle ».

Pour aller plus loin :

• CQRS by Martin Fowler
• Le slides de Jérémie Chassaing (CQRS)

Le mot de la fin

Maintenant qu’on ne fait que du CRUD, du Stateless et de l’asynchrone, cela permet de découper facilement nos applications en plusieurs petites applications ou API qui ne traitent que d’une seule problématique, réduisant encore la complexité du système d’information. Les applications web « finales » agrègent ensuite ces  API pour présenter quelque chose de « complet » à l’utilisateur final. Évidement ces APIs simples et « unitaires » sont réutilisables par autant d’applicatifs finaux que nécessaires, permettant ainsi une ré-utilisatibilité et une interopérabilité maximale.

Appelez ça comme vous voulez, WOA, REST, CQRS, HTTP, Web. L’avenir est dans la simplicité du CRUD, l’asynchrone et le Stateless.  C’est aussi l’avis de Gérard. Est-ce le vôtre ?

Yeah ! Maintenant que Gérard a son business plan qui roule, qu’il a mis en ligne un premier prototype et que les premiers clients commencent à taper au portillon, il est temps de passer à la vitesse supérieure : Créer sa société.

A Devoxx un quickie à particulièrement attiré mon attention : Celui de Andrew Spencer sur son idée de faire une SSII Coopérative. Ce qui est marrant c’est que c’est ce que nous avons fait depuis quelques mois en créant Lateral-Thoughts.

Pourquoi une SSII coopérative ?

Appliquons le « Lean Canvas » et répondons à quelques questions :

• Problem: En SSII il n’y a pas d’argent, pas de fun et pas de liberté, l’innovation n’est pas encouragée.
• Solution: Faisons une SSII qui donne de l’argent (tous actionnaires) du timeoff pour le fun et l’innovation et de la liberté d’action (management plat).
• Key metrics : Salaires moyen (Argent), Satisfaction des membres (Fun et Liberté)
• Uniq Value Proposition : Une bande de développeurs passionnés et auto-organisés qui s’éclatent à faire en codant et en apprenant ensemble.
• Unfair advantage: On s’en fout, copiez nous, ça nous fera plaisir. D’un point de vue business : Nos réseaux, notre toile « unique »
• Channels: Les réseaux de nos membres, leur rayonnance. Ce blog et d’autres ^^
• Customer segments: Les PME, grands comptes et startups.
• Cost Structure: Quasiment rien, un comptable à 1000€ / an. Pas de locaux. Pas de commerciaux. Pas de managers. Pas de boss.
• Revenue Streams: Prestations, Formations, Editions de solutions logicielles.

Il s’agit du canvas pour Lateral Thoughts mais vous pouvez tout à fait imaginer votre propre SSII coopérative pour répondre à une autre problématique. L’exemple du réseau libre-entreprise en est un autre.

Et pour ma startup ?

Les startupeurs sont des gens innovants. Le problème c’est qu’une fois que le produit est devenu « Legacy » où passe l’innovation ? Généralement on revend la structure et on part créer autre chose. Sauf qu’il n’est pas aisé de réussir à chaque fois, surtout lorsqu’on a qu’un seul cerveau. Pourquoi ne pas mettre en place dès le départ dans sa société une organisation qui permettra à l’innovation d’émerger et ce, de manière durable ? Certains l’ont très bien réussi, je pense à W.L. Gore, Whole Foods ou Google. Il suffit de copier, tous leurs secret sont expliqués dans ce livre : The Future of Management

La clé du management du futur et de passer par des sociétés coopératives, le modèle le plus connu est celui de la sociocratie que je résume en quelques points ici :

• Une personne = une voix
• Transparence totale (même et surtout du compte bancaire)
• Décision prise par consensus (tout le monde, à défaut d’être d’accord doit consentir pour qu’une décision soit prise)

Ce type de société à un coût, car une décision prise par consensus prend du temps alors qu’en société standard, le patron prend les décisions le matin seul dans sa douche. Mais le jeu en vaut la chandelle. Les membre d’une telle société donnent le meilleur d’eux-mêmes, ils se sentent investis, ils se sentent d’une même famille avec un but commun, mais aussi des objectifs individuels (qui ne vont pas contre les objectifs collectifs). La transparence fait que chacun a conscience de l’objectif de l’entreprise, de son business. Et chacun en est responsable.

Alors maintenant, qu’allez-vous faire ? Allez-vous continuez à subir ou allez-vous prendre votre vie en main (en intégrant une société coopérative) ?

En bon petit développeur Java, Gérard garde sa petite idée pour lui, développe la nuit et pendant ses congés pour finalement sortir de l’ombre et mettre en ligne THE application (pour l’instant hébergée directement sur son ordinateur personnel)

Et là, vous connaissez la suite, ça fait psssiiichhhhhttt. L’idée n’est pas trop mal mais :

• Elle n’atteint pas exactement la cible
• Il n’existe aucun vecteur pour que le client soit informé du produit
• Gérard n’a pas prévu de façon de gagner de l’argent
• Finalement, l’heure de gloire arrive enfin, un groupe de chinois tombe sur son site et  le copie en deux jours… (c’était bien la peine de l’avoir gardé secrète ton idée Gérard ! )

Ce que nous apprend Camille Roux lors de son talk à Devoxx (et sur  slideshare) c’est qu’une idée n’a pas de valeur, tout le monde à des idées. Ce qui a de la valeur c’est sa réalisation. Il nous raconte que lors d’un startup week-end, il s’est retrouvé avec six profils « business ». Six business-men qui ne savent pas coder, mais comment allait il pouvoir les occuper ?

Et là surprise, il existe un autre monde, un monde qui n’est pas le monde du développement et qui a aussi des méthodes et des outils qui ont fait leurs preuves.

Lean Canvas

Camille nous présente l’un de ces outils : le « Lean Canvas » et conseil que tous les voyants soient au vert avant de commencer le développement du produit.

• Problem : Quels problèmes résolvez vous ? Moins vous en résolvez, mieux c’est.
• Solution : Quelles solutions apportez vous ? Moins vous en apportez, mieux c’est.
• Key Metrics : Quels seront les indicateurs qui vont vous permettre de valider le succès de votre idée ? (Ex : le nombre de visites, d’utilisateurs ou de produits vendus)
• Unique Value Proposition : Qu’est-ce que vous apportez que les concurrents n’apportent pas ?
• Unfair advantage : Pourquoi on ne pourra pas vous copier facilement (Ex : une image de marque)
• Customer segments : Votre cible (Ex : La gamine de 13 ans avec un forfait bloqué à dépenser)
• Channels : Comment allez-vous atteindre votre cible ? (Ex : j’ai déjà un site qui fait 10 000 visites de ma cible par jour)

Pour remplir le tableau n’hésitez pas à parler de votre idée à vos amis, votre famille, au barman du coin ou évidemment à des représentant de votre cible. Une fois que tous les indicateurs sont au vert, vous vous rendrez compte que votre idée initiale n’est pas tout à fait la même qu’au départ, elle est largement meilleure.

Ce qui est marrant c’est que je me suis exercé à cette technique sur plusieurs types de projets et à chaque fois cela m’a apporté quelque chose. Même sur un projet open-source, même sur un projet d’entreprise de type « service ».

Pour aller plus loin :

• Running Lean: Iterate from Plan A to a Plan That Works
• Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers

Tester son idée

Maintenant que l’idée de Gérard a été retravaillée, il est temps de commencer à coder ! Enfin presque, pour tester une idée, un prototype c’est bien, mais il existe d’autres façons :

• Le questionnaire: Faites en un ! Pour savoir notamment si quelqu’un serait prêt à payer pour telle ou telle fonctionnalité. Ainsi vous pourrez démarrer avec la fonctionnalité qui a le plus de valeur et peut-être même avec déjà des clients !
• Sortez ! C’est en sortant, en allant voir vos futurs utilisateurs que vous aurez de nouvelles idées d’améliorations de votre produit,  en voyant comment ils travaillent et quels sont leurs problèmes.
• Un article de blog: Si je blogue sur mon idée et que ça buzze, c’est que je suis certainement sur la bonne voie. C’est aussi une façon d’obtenir du feedback.
• Le prototype : Enfin ! Nous allons coder. Mais là encore il s’agit de tester une idée, n’allons donc pas perdre de temps à faire une architecture scalable du feu de dieu, le truc c’est de développer vite mais aussi de développer quelque chose d’agréable à voir. N’hésitez pas à recruter votre pote designer à cette étape là, sinon vous pouvez utiliser Twitter bootstap ou acheter un CSS sur themeforest (c’est ce que j’ai fait pour buildwall.com ). Camille est un développeur Ruby, il nous explique que pour développer une page de type CRUD, il ne faut pas y passer plus de 15min… En Java on ira jeter un oeil à Spring Roo ou Play! framework

Et maintenant, qu’allez-vous faire de vos idées (et de votre vie)  ?

Pour me préparer aux sélections de code story et pouvoir coder pendant 2 jours une application devant des centaines de développeurs à Devoxx, je me suis entrainé à refactorer une méthode en m’enregistrant.

Le bénéfice que j’attendais de l’exercice était de :

• M’entendre parler pour détecter mes défauts d’expressions et les corriger, car le jour J il faudra expliquer ce qu’on fait et pourquoi, le tout en codant ! Pas facile…
• Maîtriser au maximum mon IDE pour être rapide à coder, rien de plus ennuyeux que de regarder un développeur coder trop lentement !

Pour la petite histoire, je suis partie d’une classe que je venais de refactorer chez un client, il s’agit donc d’un exemple réel. J’ai fait environ 15 essais avant les sélections pour finalement me faire éliminer ! Je suis bon perdant, et je me suis dit que les quelques techniques simples que j’explique pouvaient être intéressantes et que c’était dommage de  garder le screencast pour moi. Du coup j’ai refait 5 essais et voici le résultat :

Ce n’est pas parfait ! J’ai même fait une grossière erreur en cassant le comportement de la méthode. Le premier qui trouve où gagne une bière (la date du commentaire faisant foi) ! Si vous trouvez d’autres boulettes ça marche aussi, à l’exclusion de l’utilisation de framework ou de l’API java, Boolean.compareTo par exemple, car ce n’est pas le propos de l’exercice. D’ailleurs s’il y a une chose que je retiens c’est qu’on peut toujours faire mieux !

Pour ceux qui voudrait faire pareil :

• Achetez un bon casque / micro ! (le mien clic! de temps en temps, il faut que j’en rachète un !)
• Sous linux j’utilise Kazam pour l’enregistrement et key-mon pour montrer ce que j’écris.
• Limitez vous à un exercice de moins de 10minutes, on décroche si c’est trop long.
• N’ayez pas honte !

Bon code à tous !

Cette année, le Paris Java User Group fête ses 3 ans. Pour l’occasion une soirée exceptionnelle est organisée. D’autant plus exceptionnelle que Mathilde viendra raconter comment le statut d’indépendant permet à ceux qui ont fait ce choix de vivre différemment, de vivre mieux.

Tous les détails (lieu, date, programme et inscription) ici : http://www.parisjug.org

« J’en ai rêvé, je l’ai fait ». Voilà comment je résume mon état d’esprit en ce moment. Je suis Freelance parce que j’ai cette fibre d’indépendance, l’envie de voler par mes propres ailes. Je suis développeur parce que j’aime créer, j’aime réaliser des outils utiles, j’aime réaliser des outils de qualité et j’aime partager mes connaissances (ce blog en est la preuve). En cela je me considère comme un artisan, un « Software Craftsman ».

Après mes études, je voulais déjà fabriquer mon propre produit. A l’époque je souhaitais créer un logiciel pour les campings, ayant baigné dans ce milieu depuis tout petit. Manquant d’expérience et devant l’immensité de la tâche pour un débutant ( 2 débutants en l’occurrence puisque Mathilde était déjà de la partie à cette époque), nous avons mis le projet de coté au bout de 6 mois pour aller apprendre la vie en SSII. Depuis, presque chaque jour j’ai une nouvelle idée, presque chaque jour je suis frustré de ne pas pouvoir la réaliser. J’ai une famille et peu de temps pour réaliser mes idées. Je suis dépendant d’un système, comment développer mes idées sans perdre en revenus, sans faire prendre de risque à mes enfants ?

Rework, tu liras

Au début je me disais qu’il fallait trouver l’idée qui tue, la « killer feature ». Qu’il fallait faire une étude de marché, qu’il fallait des clients, qu’il fallait des investisseurs, qu’il fallait investir aussi et savoir prendre des risques. Qu’il fallait tous développer avant de mettre de publier.

Et un jour j’ai lu :

Avec Rework j’ai compris qu’il fallait démarrer petit. Qu’il fallait résoudre un de ses propres problèmes. Qu’il n’était pas utile de dépenser beaucoup d’argent, ni d’arrêter de travailler, ni de prendre des risques. Qu’il fallait se concentrer sur le cœur du service et rencontrer ses utilisateurs au plus tôt. Mon problème était que toute mes idées, je les chiffrait a plus de 50 jours de travail juste pour le cœur, la résolution basique du problème. Quand je vois que l’idée que j’ai finalement réalisé été chiffré a 4 ou 5 jours et que cela m’a pris plus de 8 jours et qu’il reste encore 2 fois plus de boulot, c’est clairement difficile de tenir la longueur sur un projet de plus de 100 jours.

Des gens, tu rencontreras

Et puis j’ai rencontré des gens, j’ai rencontré Olivier Issaly, un ami de Mathilde, fondateur d’Equideow alors qu’il n’avait pas fini ses études,  qui m’a appris que « c’était possible ».

J’ai rencontré Nicolas Martignole, et son express-board, créé en quelques jours avec l’aide des lecteurs de son blog et du framework play!.

Je suis allé à Devoxx, une conférence à ne pas rater, vrai « catalyseur » d’idées et de motivation. Il faut le vivre pour comprendre, allez y

Je suis aussi allé a plusieurs rencontres geek autour de Java, NoSQL, le web sur Paris. A chaque fois j’ai rencontré des gens intéressant qui donne des idées ou nous conforte dans nos idées.

Le web, tu comprendras

Après une mission de 4 ans  sur un Framework Java qui me cachais la « réalité du web » à coup d’architecture Statefull, de JSP, taglibs et autre générateur de pages web, je suis arrivé chez Vidal et j’ai re découvert le Web. J’avais déjà mis un pied dans le Web avant Groupama avec PHP. Chez Vidal j’ai découvert la puissance et la simplicité du JavaScript et des architectures Stateless.

Regardez donc les vidéos sur http://www.zengularity.com/ et lisez les premières page de:

pour comprendre à quel point le vrai Web, c’est l’avenir.

Petit, tu commenceras

C’est facile de dire : je vais faire une facebook-like et je vais être riche. Moins facile à faire ! Alors j’ai listé toutes mes idées et je les ai triées de la plus difficile à la plus simple à réaliser et j’en ai déduit « l’idée ». La toute petite idée, tellement simple qu’en un long week end de 4 jours, j’avais le temps de la réaliser. Mon « problème à résoudre » était en fait multiple:

• Accéder au buildwall de Vidal de chez moi ou depuis mon téléphone
• Ne plus perdre les informations du mur chaque fois que le serveur plantait ou qu’on le mettait à jour.
• Ajouter facilement un membre de l’équipe au wall.

Faire un buildwall. Rien de plus simple fonctionnellement. Pour résoudre mes problèmes il suffisait que je porte le projet en un site Internet. Un service sur le cloud, « Software as a Service ».

Cela m’a pris 2 jours pour résoudre les principales problématiques :

• Faire du plein écran en web.
• Trouver le bas d’une page web (pas si simple, une page web n’a pas de fond..)
• Mettre à jour le mur dynamiquement (merci Ajax et le long polling)

Pour cela j’ai utilisé l’excellent Framework Play! avec JQuery, HTML5 et CSS3 pour la partie client. Des ressources REST, MySQL en base de donnée avec Memcache pour optimiser le tout.

Et puis le plus long fut finalement tout le reste :

• la gestion utilisateur
• le design du site
• les mentions légales
• trouver des formules d’abonnement adaptées
• fignoler les détails

Franchement, je ne m’y attendais pas. La bonne surprise fut le CSS, je n’y connaissais rien et j’ai appris très vite. Comme quoi même un 0% artiste peut faire une site correct. Alors pourquoi continuer à faire des Intranets moches ? Go apprendre le CSS !

Je me suis amusé aussi :

• Tout le site est Ajaxifié
• Gestion de l’historique grâce au hash dans l’url, normé par Google pour qu’il puisse crawler le site
• Gestion de la langue. Si votre navigateur est configuré pour voir les sites en anglais, vous verrez le site traduit en anglais !

En production, tu iras

J’ai mis en production 2 semaines après le début du développement. Sans faire de pub dans un premier temps, le temps de faire les derniers réglages. J’ai su stopper mes ardeurs et ne pas démarrer les fonctionnalités annexes et peut être pas utiles (le paiement en ligne par exemple). Il faut que le produit se confronte aux utilisateurs pour comprendre leurs besoins et faire évoluer le site dans le bon sens.

Vous trouverez le site à cette adresse : http://www.buildwall.com N’hésitez pas a participer à son amélioration ! Toute critique ou idée est la bienvenue !

Grand, tu finiras ?

Clairement le but de ce site n’est pas de faire fortune. C’est un premier site, un premier service, une première création qui me permettra de me confronter à la réalité de l’édition de logiciel. J’y ai passé peu de temps finalement et j’ai appris énormément. Je suis donc déjà récompensé !

Comme je l’ai dit j’ai une « liste », j’ai donc un prochain projet, plus difficile à mettre en œuvre. C’est marrant car ce projet je l’ai mais je ne le connais pas, ma liste évoluant sans cesse, je ne peux dire quel projet ce sera lorsque je me déciderai à le commencer.

Tout le monde, tu remercieras

Je tiens vraiment à remercier tous mes collègues et amis (oula ça fait cliché mais c’est pas grave), en fait je suis surpris de n’avoir rencontré personne qui m’a dit « c’est nul, ça sert à rien » mais je ne désespère pas ! Alors dans le désordre, merci :

Jean-Laurent bien entendu pour m’avoir fait découvrir l’agilité, l’intégration continue et l’utilité d’un buildwall. Louis, pour ta relecture, Tony pour ton aide précieuse sur JQuery, Aurélien alias « John » pour ton aide précieuse sur le logo. Mathilde pour t’être occupée des monstres. Merci a tous ceux qui m’ont encouragé, les collègues de Vidal et les personnes rencontrés à Devoxx à qui j’ai présenté le « proof of concept » du produit et qui ont été les premiers à me donner de nouvelles idées.

Merci enfin à tous ceux qui s’inscriront sur http://www.buildwall.com et qui m’aideront à améliorer le produit (ou à le vendre à leur employeur )

JRebel est un outil payant permettant d’effectuer des rechargements à chaud d’applicatif Java. C’est clairement l’outil qui fera de vous un développeur plus productif. Voilà une bonne façon de se faire bien voir, de rentrer plus tôt à la maison ou d’augmenter sa facturation

Vous pouvez, en tant que personne, acheter une « Personnal license » et l’utiliser dans le cadre de votre travail. Cette licence ne peut pas être remboursée par votre entreprise. L’achat d’une licence « standard » n’est pas rentable, même payé par votre EURL. Votre client peut également acheter des licences standard mais personnellement, je pense qu’il vaut mieux lui permettre de faire cette économie. Un client n’est pas éternel et un geste commercial est toujours bien vu non ?

Fonctionnement

JRebel est ce que l’on appelle un « java agent » (see : http://blog.xebia.fr/2008/05/02/java-agent-instrumentez-vos-classes/ ). C’est à dire qu’il va instrumenter le bytecode.

Pour que cela fonctionne il faudra donc spécifier à la JVM l’agent JRebel (jrebel.jar).

Cette agent fonctionne de manière très simple, il scrute le classpath à la recherche des fichiers rebel.xml. Ces fichiers permettent de faire un mapping entre l’application (bytecode et ressources) et votre code source. JRebel scan les sources et les mets à jour dans l’application en cours d’exécution. C’est aussi simple que cela.

Vous l’avez compris, pour recharger à chaud votre projet et toutes vos dépendances vous devez avoir un fichier rebel.xml dans chacun des projets (.jar  .war) que vous souhaitez recharger à chaud.

Installation

L’installation de JRebel va simplement copier l’agent jrebel.jar dans le répertoire de votre choix. Il existe également un plugin Eclipse (optionnel).

Comme nous l’avons vu, nous devons fournir un fichier rebel.xml dans chacun de nos projets. Avec Maven, il suffit simplement d’ajouter le plugin maven-rebel, dans le fichier pom.xml :

<plugin>
 <groupId>org.zeroturnaround</groupId>
 <artifactId>javarebel-maven-plugin</artifactId>
 <version>1.0.5</version>
 <executions>
  <execution>
   <id>generate-rebel-xml</id>
   <phase>process-resources</phase>
   <goals>
    <goal>generate</goal>
   </goals>
  </execution>
 </executions>
</plugin>

On pourra lancer la génération manuellement via « mvn javarebel:generate »

Ensuite, il suffit de lancer l’application en spécifiant l’agent à la JVM :

-noverify
-javaagent: »C:Program FilesZeroTurnaroundJRebeljrebel.jar »

Si vous lancer votre application via maven (mvn jetty:run par ex), vous pouvez utiliser la variable système  MAVEN_OPTS, ou utiliser « Run configuration » dans Eclipse. Il doit sans doute exister un moyen de le faire dans le pom (via un profil « rebel » par exemple).

Voilà ça fonctionne !

Have fun !

Au début de ma carrière, je me souviens qu’un de mes collègues m’a dit « Tu sais, au final, on se rend compte qu’il n’y a que très peu de différence de productivité entre un bon développeur et un développeur lambda ». Je l’ai cru,  et il m’a fallu quelques années pour me rendre compte qu’il avait complétement tort. Un développeur productif peu produire jusqu’à 10 fois plus (sans diminuer la qualité du code). Sachant que les tarifs vont du simple au double, engager un bon développeur, 2 fois plus cher, peut s’avérer en fait 5 fois plus rentable pour le client. Pensez y au prochain entretien

A votre avis, un client préférera prendre un développeur productif mais cher ou un développeur lambda pas cher ?

Apprendre en continu

Le seul moyen de s’améliorer c’est d’apprendre, apprendre, apprendre. N’hésitez pas à poser une journée ou deux par mois, et de préférence en semaine pour vous former au calme, chez vous. Les transports sont aussi une bonne occasion, pour ceux qui ont la chance de les utiliser.

Ce n’est que quand j’ai commencé à m’ennuyer en mission que j’ai décidé de lire. Et c’est en lisant que je me suis rendu compte à quel point j’étais mauvais en Java. Le livre qui m’a fait prendre conscience est « Effective Java » :

Bien, une fois que j’ai pris conscience qu’en fait j’avais rien compris à Java, suis je meilleur développeur ? Non, mais c’est un début. Maintenant il faut apprendre se comporter comme un bon développeur. Que ce soit avec votre code : « Don’t repeat yourself », avec les autres :  « Provide Options, Don’t Make Lame Excuses » ou avec vous même : « Invest Regularly in Your Knowledge Portfolio »

« The pragmatic programmer » est LE livre à lire et se présente sous la forme d’une liste d’astuces :

Dans le même style, les astuces sont plutôt orientées Business mais certaines peuvent s’appliquer à nos développements. Et puis, quel freelance ne rêve pas de monter sa petite entreprise ? Rework est le genre de livre qui peut révolutionner une vie :

Et après ?

Voici une liste d’astuces, issue de ma propre expérience.

- Maîtriser vos outils : Apprenez les raccourcis clavier de votre IDE et utilisez les. Regarder comment les autres développeur utilisent vos outils, c’est très instructif !

- Choisissez vos missions : Débrouiller vous pour toujours travailler avec des gens meilleurs que vous. Faites en sortes de toujours apprendre quelque chose de nouveau (technos, architecture, langage, métier, méthodologie).

- Reposez vous : Inutile de se fatiguer au travail, cela ne fera que baisser votre productivité. Fatigue = erreurs. Un besoin incompris, c’est une productivité nulle.

- Changez vous les idées, consacrez du temps à vos loisirs et à votre famille. Cela boostera votre créativité et vous aidera à résoudre les problèmes complexes.

- Limitez les sources de perturbations. Coupez Twitter, votre e-mail (même le pro) ainsi que Facebook. Profitez de votre téléphone 3G dernier cris pour traiter tous ça dans les transports le matin et le soir.

- Travaillez vos forces et laissez tomber vos faiblesses : Est ce bien utile de s’obstiner à maîtriser CSS et photoshop alors que l’on n’est pas artiste pour un sou ? Cela va vous prendre énormément de temps. Temps qui serait mieux utilisé à augmenter votre expertise dans votre domaine de compétence. Ne soyez pas dupes et ne soyez pas jaloux des « rockstar », vous êtes sans doute meilleur qu’eux dans un autre domaine !

Livres Bonus

Pour ceux qui vont vite et aussi parceque cet article est l’occasion de tester les liens sponsorisés Amazon , voici 3 livres qui m’ont également aidé à progresser et que je vous conseil pour compléter votre read list:

YapluKa !

1. 1/3 des missions sont pourvues sans qu’il y ait d’appel d’offre ou pourvues avant même la parution de l’AO (Copinage…). Sans copains, moins d’opportunités.
2. Tous les grands comptes ont un service achat qui référence les fournisseurs. En étant indépendant, impossible d’obtenir de référencement. Nous sommes obligé de passer par un intermédiaire qui se sert largement au passage (20% en règle générale).
3. Aucun pouvoir de négociation face à nos propres fournisseurs. Nous payons nos formations plein pot, nos conférences pleins pot et nos comptables pleins pot
4. Pas de support en cas de difficulté technique, commerciale ou même juridique en mission.
5. Pas d’image. Nous avons même plutôt une image « négative », certains nous voient comme des mercenaires.
6. Si vous êtes formateur, ou désirez donner des formations, difficile de proposer un catalogue de formations et de se faire connaître et en restant isolé.

Ce rassembler autour d’une structure commune devrait permettre de palier à toutes ces difficultés, c’est ce que propose Prosymna.

Prosymna

Le Groupement d’Intérêt Économique (GIE) Prosymna (prononcer ProSSimna et non ProZimna) est l’initiative de deux indépendants, Nicolas Ludmann et Pierre Stevenin. L’idée est simple : créer un « Cabinet de conseil » sous la forme d’un GIE composé exclusivement d’indépendants.

L’objectif du GIE est de favoriser le développement de l’activité de chaque adhérent par 3 leviers :

• L’amélioration de la démarche commerciale
• La réduction des coûts de fonctionnement
• La mise en commun des retours d’expériences et des savoirs-faire

Le tout sans ingérences. Chaque société reste complètement libre. Les contrats se font en direct avec les clients et le GIE n’intervient en tant qu’intermédiaire qu’exceptionnellement lorsque la contractualisation directe est impossible. Dans ce cas 2% de la facturation est prélevée (à comparer avec les 20% habituel).

Amélioration de la démarches commerciale

Il s’agit de permettre :

• L’obtention de référencement et la réponse aux appels d’offres en mettant en avant le Chiffre d’Affaire et la taille global du GIE aux clients finaux.
• D’avoir une image, celle du GIE. On peut imaginer sponsoriser des conférences ou en proposer sur nos domaines d’expertise.
• La mise en commun de support commerciaux : site Internet, e-mail, contrat type, modèle de CV etc.
• La mise en avant de l’ensemble des références clients
• Le plus important à mon avis : La création d’un réseau d’apporteurs d’affaires. Nous avons tous notre « petit » réseau de « clients décideurs » que nous pourrons ainsi utiliser pour faire des affaires au sein du GIE, en plaçant les autres membres du GIE.

Il s’agirait également de faire du GIE un centre de formation, de mettre en commun les accréditations, les locaux et tout simplement l’offre de formations.

Partage du savoir

Il s’agit cette fois de :

• Créer un espace documentaire : Je suis plus que perplexe sur ce point, je trouve ce principe simplement dépassé avec toutes les sources d’informations, les forums spécialisés que l’on trouve sur Internet, une espace documentaire ne pourra pas rivaliser et sera certainement du temps perdus. En revanche, un blog aurait beaucoup d’intérêt.
• Créer un réseau de professionnels à qui l’on pourrait faire appel pour du support lors d’une difficulté ou d’un besoin spécifique en mission mais également pour répondre à des appels d’offres nécessitant plusieurs personnes.
• Mettre en place des journées de partage de connaissances comme le font Zenika, Xebia, ou SFEIR…

Réductions des coût fournisseurs

La phrase choc fut : « Présenter 4 personnes pour une formation permet d’obtenir 40% de réduction sans effort ». Lorsque l’on connaît le prix des formations ce simple avantage justifie à lui seul la création d’un groupement.

Mais le spectre est large, il y a les comptables mais aussi les banques et les affactureurs qui ne traitent pas du tout de la même façon une structure qui fait 100k€ de CA et une structure qui fait 10 millions de CA.

Prosymna fournira également une domiciliation dans Paris avec possibilité de louer des locaux.

Domaine d’activité

Prosymna vise le conseil au sens large : organisation et management, gestion de projets, gestion de processus, maîtrise d’oeuvre, maîtrise d’ouvrage. Au forfait ou en régie. N’y a t’il pas un risque à viser trop large ? Comment se vendre « Cabinet d’expert » si le GIE est multi compétences ?

Une solution serait de créer une seule structure mais plusieurs pôles avec une marque différente pour chaque pôle. Si le GIE atteint les 100 adhérents nous pouvons facilement imaginer 4 pôles de 25 personnes dont un pôle « Java » rien qu’à nous ! Face aux clients nous serions un cabinet d’expert de 25 personnes et face aux fournisseurs nous serions toujours un regroupement de 100 sociétés.

Organisation du GIE

La première chose à savoir sur les GIE c’est qu’il est impossible pour un GIE de faire des bénéfices ou des pertes. Les membres sont tous solidaires des dettes et créances du GIE. Cela à un coté intéressant au niveau des créances, car si le montant des adhésions n’est pas consommé il sera possible de réduire, voir de rembourser une partie des cotisations payées. A contrario, cela présente également un risque si le GIE s’endette. Ce risque est à modérer puisque par définition, nous n’avons pas beaucoup de fournisseurs, aucun salarié et nos marges sont très importantes. De plus le GIE ne contractera qu’exceptionnellement et refusera de le faire pour des missions « à risque ». Par exemple, les missions de type conduite du changement où les décisions du prestataire peuvent coûter très chère et engager sa responsabilité seront étudiées de manière collégiale. Pour en finir avec le risque, il est tout à fait possible de proposer un contrat de prestation avec des clauses limitant la responsabilité du GIE à hauteur des sommes prises en charges par l’assurance.

Adhésion

L’adhésion est limitée aux personnes morales. Pas d’Entreprise individuelles ou d’auto-entrepreneur.

L’adhésion d’un nouveau membre est soumise aux votes des membres en assemblée générale.

Pour éviter les profiteurs, qui ne viendraient que pour trouver une mission et repartiraient immédiatement, la sortie du GIE ne pourra se faire que dans un délai de 6 mois.

Prosymna propose 2 niveaux d’adhésion et 3 niveaux que je qualifierai « d’investissement dans le GIE »

1. Les adhérents en industrie : C’est le statut de base, ils n’apportent que leur savoir-faire.
2. Les adhérents en capital : Ce sont les adhérents qui ont au moins un an d’ancienneté au sein du GIE et qui souhaitent s’investir plus en apportant du capital.
3. Le conseil d’administration : Il est obligatoire en GIE et sera donc tenu par les adhérents en capital qui souhaitent s’investir fortement dans le GIE. C’est l’organe exécutif de la structure.

Afin de garantir une complète transparence, des contre-pouvoirs seront mis en place :

• Un contrôle de la gestion du Conseil d’administration par un membre non administrateur.
• La nomination d’un contrôleur des comptes indépendant du GIE (un 2ème comptable en fait).
• Les comptes seront mis à disposition de tous les membres souhaitant y avoir accès.

Droits de votes

Les décisions importantes (adhésions, exclusions, modifications des statuts) sont prises en assemblées générales.

• Une part = 1 vote.
• 50% des parts sont détenus en capital
• 50% des parts sont détenus en industrie.

Là ça se complique. Je donne un exemple :

• Le capital représente 50 000€
• L’apport en industrie représente 50 personnes.

Comme il doit y avoir autant de part en industrie qu’en capital, le capital aura 50 votes et l’industrie 50 votes.

• Avec Mathilde nous sommes 2 personnes, nous avons donc 2 parts en industrie et 2 votes.
• Un des administrateur à apporté 3000€, il a donc 3 parts en capital plus 1 part en industrie : 4 votes.

Financement

J’aime bien le financement proposé. C’est un système juste, à la française, inspiré de notre système d’impôt sur le revenu. Plus on est « riche » et plus on va participer de manière importante à l’effort de financement.

Pour que cela soit plus parlant, je vais encore une fois donner un exemple. Une société qui fait 100k€ de chiffre d’affaire va cotiser :

• 500€ lors de l’adhésion
• puis 1000€ annuellement en 4 versements trimestriel de 250€

Cela peut paraître élevé mais si cela peux être remboursé 10 fois  si le GIE nous permet de contracter en direct et de faire 110k€ ou 120k€ de CA au lieu de 100k€. Une formation de 3000€ pourra ne coûter que 2000€, un apport d’affaire remboursera également une ou 2 années de cotisations etc. Chacun fera ses petits calculs et verra son intérêt à adhérer ( ou à ne pas adhérer ).

Ce qui risque de bloquer les adhésions, c’est que les adhérents potentiels étant déjà en mission, ayant déjà leurs fournisseurs et leur réseau, ils n’auront pas le besoin immédiat de cette structure et risquent de repousser à plus tard l’adhésion pour ne finalement jamais adhérer (et plouf!). Je me demande si, plutôt que de faire une adhésion à 500€ il ne serait pas mieux de faire l’inverse, avec 6 mois de dispense de cotisations, au moins le temps d’atteindre une taille critique. En contrepartie, je porterai une grande attention à la sélection des premiers adhérents.

Le mot de la fin

La présentation du GIE s’est terminée par un « Plan d’action » sur l’année 2010 et sur les objectifs à 4 ans. Cela m’a fait sourire car je suis entrain de lire l’excellent livre Rework qui explique justement que ce n’est que perte de temps de faire des plans sur la comète. L’idée du GIE est excellente, cela fait plusieurs mois que j’ai également eu cette idée tout en ayant ni le courage ni les capacités d’en être l’initiateur. Cette opportunité doit être soit saisie soit être source d’inspiration mais je pense que pour Prosymna il faut maintenant dépenser l’énergie à bâtir une base solide.

Nous avons également évoqué durant la réunion le positionnement du GIE face à la chasse aux indépendants actuellement ouverte chez certains grands comptes.

Si vous voulez en savoir plus, je vous invite à vous inscrire à la prochaine réunion qui aura lieu Mardi 8 Juin 2010. Les inscriptions se font ici.

PowerMock est une extension de 2 API bien connues des mockeurs (Ha ha), EasyMock et Mockito. Qui n’as jamais été obligé de supprimer un final, rendre une méthode private protected ou galérer sur des appels statiques pour faire ses tests ? PowerMock nous permet de « tester l’intestable » sans toucher au code. Bonne idée ? Oui, mais attention, cette bonne idée a un coût qu’il ne faut pas négliger. L’exécution des tests peut prendre jusqu’à 10 fois plus de temps.

De plus, si on ne fait pas attention, on peut tomber sur des anomalies qui peuvent être difficile à résoudre si on n’a pas saisi le « truc ». L’objet de cet article est de vous présenter ce qui me crash le plus souvent mes tests.

Le problème

Voici la classe à tester :

package fr.java.freelance;

public class UnTrucCool {

public final boolean estQuelqueChose(){
return critereUn() && critereDeux();
}

public boolean critereUn(){
return false;
}

public boolean critereDeux(){
return false;
}

}

En fait, un test existe déjà :

package fr.java.freelance;

import static org.junit.Assert.*;

import org.junit.Test;
import static org.mockito.Mockito.*;

public class UnTrucCoolTest {

@Test
public void testEstQuelqueChose() {
UnTrucCool banane = mock(UnTrucCool.class);
when(banane.critereDeux()).thenReturn(true);
when(banane.critereUn()).thenReturn(true);

assertTrue(banane.estQuelqueChose());
}

}

Pour une bonne raison, nous décidons d’utiliser PowerMock, nous modifions donc le test comme ceci :

package fr.java.freelance;

import static org.junit.Assert.*;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

import static org.powermock.api.mockito.PowerMockito.*;

@RunWith(PowerMockRunner.class)
@PrepareForTest(UnTrucCool.class)
public class UnTrucCoolPMTest {

@Test
public void testEstQuelqueChose() {
UnTrucCool banane = mock(UnTrucCool.class);
when(banane.critereDeux()).thenReturn(true);
when(banane.critereUn()).thenReturn(true);

assertTrue(banane.estQuelqueChose());
}

}

Le test est strictement identique, mais ça ne fonctionne plus! estQuelqueChose() renvoie systématiquement false !

La solution

Dans le premier test nous utilisons simplement Mockito qui ne sait pas mocker les méthodes finales. Comme il ne sait pas le faire, il adopte un comportement par défaut et appel la méthode réelle.  En passant à PowerMock, toutes les méthodes finales peuvent être mockées et doivent donc avoir un comportement défini explicitement. On notera que si estQuelquechose() n’avait pas été finale, le test Mockito aurait également dû définir explicitement le comportement à avoir.

@RunWith(PowerMockRunner.class)
@PrepareForTest(UnTrucCool.class)
public class UnTrucCoolPMTest {

 @Test
 public void testEstQuelqueChose() {
 UnTrucCool banane = mock(UnTrucCool.class);
 when(banane.critereDeux()).thenReturn(true);
 when(banane.critereUn()).thenReturn(true);

 when(banane.estQuelqueChose()).thenCallRealMethod();

 assertTrue(banane.estQuelqueChose());
 }

}

Faites attention lorsque vous passez un existant sur PowerMock.

http://code.google.com/p/powermock/

Le domain driven design « Vite fait » : 80 pages pour changer votre vie. Ou plutôt changer votre façon d’écrire vos modèles métiers.

Cours sur la concurrence : Une piqure de rappel ne fait pas (de) mal.

Développer avec Comet et Java : Vous rêver d’envoyer des informations au navigateur en mode « push » ? Voici la solution.

Algodeal: Pour tous ceux qui aime inventer des algos, voici une occasion de faire fortune en s’amusant (et en java)  !

Les castcodeurs : Episode spécial « Freelance » avec Mathilde ! A écouter absolument si vous souhaitez vous mettre indépendant !

Depuis le début de la crise économique mondiale, certains clients finaux ont diminué le nombre de prestataires et ont imposé des baisses de tarif importantes. Résultat : plus de prestataires et moins de mission, loi de l’offre et la demande oblige, les prix ont chuté d’environ 10%.

Pour ceux qui ont la chance d’être resté en mission ou qui n’ont pas vu leur tarif baisser, ce n’était pas le moment de changer. Et pour ceux qui ont subit, le risque est aujourd’hui de continuer à subir alors que le marché a repris. Alors comment avoir une vue globale sur le marché de la prestation Java en France ?

Personnellement j’utilise le baromètre du site hitechpros.com. Apprendre à décrypter ce baromètre permet de se faire une idée des tendances du marché.

Comment décrypter ces données ?

La courbe bleue correspond aux offres de missions (demandes des clients), ramenée à 100% elle sert de base. La courbe rouge correspond aux prestataires disponibles (offres de SSII). Donc plus la courbe rouge baisse, mieux c’est. Pour le mois de Mars, on y est, le nombre de prestataires disponibles est inférieur au nombre de missions ! Champagne !

Voici mon analyse en Mars 2010 :

- La crise est belle est bien terminée, cela fait plusieurs mois qu’on le pressentait avec le nombre d’offres de missions qui explose sur les différents sites d’emplois.
- Cette crise inversée ne va pas durer, les SSII vont se remettre à recruter en masse et le nombre de prestataire va remonter au dessus des offres de missions.
- Toutefois, le marché devrait rester en notre faveur jusqu’à la prochaine crise et les tarifs devraient augmenter fortement.

Mon conseil si vous n’êtes toujours pas freelance :  foncez ! Le temps de démissionner les tarifs seront sur un nouveau « plus haut ». Si vous l’êtes déjà, c’est le moment de changer de mission si vous attendiez une accalmie. Sinon, attendez un peu que cette pénurie atteigne le client avant de demander une revalorisation importante de votre tarif.

Ce qu’était mon analyse fin 2009 :

- Actuellement le nombre d’intercontrat baisse fortement et les clients commencent à avoir du mal à trouver des ressources. Les indépendants trouvent facilement des missions mais mal payées.

- Si la tendance se confirme, les SSII vont recommencer à recruter afin de répondre aux exigences des clients, les débutants et chômeurs vont réussir à trouver du travail mais moins bien payé qu’avant 2007, car les tarifs n’auront pas encore remontés.

- Lorsque le vivier d’inter-contrats et de jeunes diplômés sera absorbé, les prix commenceront à remonter et les salaires feront de même. Il sera temps pour les indépendants de profiter de cette dynamique avant la prochaine crise.

Pour conclure, n’oubliez pas que le meilleur moyen de rester employable, crise ou pas crise est de se former ! En mission comme à la maison ou en dehors. Ainsi que de bien choisir ses missions ! Pas forcément chercher une « niche rentable » mais faire quelquechose qui nous passionne est le meilleur moyen d’y exceller.

Et vous comment vivez vous ou avez vous vécu cette crise ? Quelle est votre stratégie pour les mois à venir ?

import java.io._

class Reader(dir: String) {

	// Concatène les contenus de n fichiers dans une liste
	def readAll() = {

		// Mets toutes les lignes d'un fichier dans une liste
		def readLines (name : String) = {

			// Mets toutes les lignes d'un bufferedReader dans une liste
			def read(buf : BufferedReader, acc : List[String] ) : List[String] = buf.readLine match {
				case null => acc
				case s => read(buf, s::acc)  // Appel recursif optimisé par Scala
			}

			// Compose le nom complet du fichier et appel read
			read(new BufferedReader(new FileReader(dir + "/" + name)), Nil).reverse
		}

		// Applique readLine sur tous les fichiers et renvoi la concaténation des listes
		// Pas de return : En scala c'est la derniere expression qui fait office de retour
		new File(dir).list.flatMap(readLines)
	}
}

13 lignes de code, pour lire tous les fichiers d’un répertoire puis concaténer l’ensemble des lignes dans une liste chaîné.

Une compatibilité à 100% avec Java

Ce qui n’est pas une surprise, car Scala est compilé en ByteCode.

Cela se traduit par la possibilité d’importer  n’importe quelle classe pourvu qu’elle soit dans le classpath :

import java.io._

Et d’appeler des méthodes Java dans le code Scala :

buf.readLine

new BufferedReader(new FileReader(dir + "/" + name))

Et même d’utiliser très simplement un framework comme JUnit :

import org.junit.Test

class ReaderTest() {
  @Test
  def unTest() : Unit = {
    val read = new Reader("src/test/resources/cotations")
    read.readAll().map((x) =>println(x));
  }
}

Oui je sais, ce test n’est pas un test, c’est juste un exemple

Chaque méthode que j’ai écrite ne fait qu’un seul traitement. Cela les rends faciles à comprendre, à maintenir et à tester. La programmation fonctionnelle n’étant pas « impérative », il est de toute façon très difficile d’écrire une méthode sur 1000 lignes alors qu’il est malheureusement très fréquent d’en trouver dans du code Java…

Pas de boucle

En programmation fonctionnelle il est tout à fait possible, et même conseillé de ne pas utiliser de boucle. La façon de penser et de concevoir son programme n’est plus la même. C’est je  pense, la principale raison qui rend les langages fonctionnel « obscurs » pour un développeur impératif.

En programmation impérative, on pense « enchaînements d’instructions », c’est un peu comme écrire une recette de cuisine : faire ci, puis ça, puis ça.

En programmation fonctionnelle on s’attache au « comment ». Comment transformer tel fichier en liste et tel liste en table de base de données. C’est le principe d’une fonction : transformer une entrée en « autre chose ». Les éléments impératifs, comme les boucles ne sont utiles que dans un langage impératif (encore que..).

On utilisera plutôt la récursion :

			def read(buf : BufferedReader, acc : List[String] ) : List[String] = buf.readLine match {
				case null => acc
				case s => read(buf, s::acc)  // Appel recursif optimisé par Scala
			}

			// Compose le nom complet du fichier et appel read
			read(new BufferedReader(new FileReader(dir + "/" + name)), Nil).reverse

Notez qu’il ne se produira pas de StackOverflowError car ce code récursif est traduit par une boucle. Oui ne riez pas, c’est vrai. Un code récursif identique en java produira un beau StackOverflowError lorsque les fichiers dépasseront un certain nombre de lignes.

Scala a quand même une petite faiblesse, il n’optimisera que si l’appel récursif est direct. Une pile {read, read, read, read, read} sera optimisée alors qu’une pile {read2, read1, read2, read1} ne le sera pas. Ce qui nous empêche d’écrire ce code qui aurait été plus élégant :

def read(buf : BufferedReader) : List[String] = buf.readLine match {
      case null => Nil
       case s => s::read(buf)  // Appel recursif
}

  // Compose le nom complet du fichier et appel read
  read(new BufferedReader(new FileReader(dir + "/" + name)))

La stack ici est {read, ::, read, ::, read, ..} « :: » est la fonction d’ajout d’élément à une liste en Scala !

En fait, Java nous interdit carrément d’utiliser la récursion sur une trop grande profondeur, ce qui est clairement une énorme lacune du compilateur Java, qui pourrait très bien optimiser les fonctions récursives pour éviter les stackOverflow. Scala à une longueur d’avance sur ce point. Ceci dit je pense que cela donnera des idées pour Java7.

Cette traduction en Java ne sera pas optimisée malgré une pile d’appel optimisable :

private List readLines(final BufferedReader buf, final List acc) {
		String line;
		try {
			line = buf.readLine();
			if (line != null) {
				acc.add(line);
				return readLines(buf, acc);
			}
		} catch (IOException e) {
			e.printStackTrace();
		}

		return acc;
	}

Voici une autre façon de ne pas utiliser de boucle :

// flatMap est une méthode native.
new File(dir).list.flatMap(readLines)

Ici on créé un objet java.io.File, on appel la fonction list() puis on appel la fonction readLines sur chacun des fichiers.

La méthode « map » applique la méthode readLines à tous éléments de la liste et retourne cette nouvelle liste. On effectue donc bien un mapping d’une liste de valeurs vers une nouvelle liste de valeurs : List<FileName> => List<ContenuDuFichierFileName>. Le tout, sans boucle !

La méthode flatMap() diffère de la méthode map() car au lieu de renvoyer une List<List<String>> (ReadLines renvoie une List<String>, elle va « aplanir » (ou concaténer) les listes, ce qui donnera une simple List<String> contenant toutes les lignes de tous les fichiers situés dans le répertoire « dir ».

Alors en vérité, et je pense que c’est une lacune du langage Scala, il existe un mot clé « for » qui permet d’écrire certaine ligne de mon code d’une autre manière faisant grandement penser à une boucle « for » Java… mais sans l’être.. bref, je conseil d’éviter cette écriture, Scala étant déjà assez difficile à appréhender pour un programmeur impératif, inutile d’ajouter de la confusion en codant un truc ressemblant à de l’impératif..

Et pas de variable

Scala encourage l’utilisation d’objet immutable. C’est à dire avec un état fixe, sans setters par exemple. Je vous renvoie à la lecture de l’excellent livre « Effective Java » pour en savoir plus sur les avantages de l’immutabilité en Java, et donc a fortiori en Scala. Et bien entendu il beaucoup plus simple de faire de l’immutable en Scala qu’en Java !

Scala permet de différencier très clairement les valeurs des variables via les mots clé « val » et « var ». « val s : MyObject  » est l’équivalent de « final MyObject o; » alors que « var s : MyObject  » sera l’équivalent de « MyObject o; » En Scala les paramètres des fonctions sont des « val ». Un objet immutable sera forcément une valeur.

Il est donc tout à fait possible et même conseillé de ne jamais utiliser de variables. En fait, lorsqu’on aura besoin d’un objet avec état changeant on utilisera le pattern « Actor », dont Scala fourni le support et qui permet d’avoir des objets mutables « sans risques ».

Développer avec le Bloc-notes : Facile !

Le gros défaut de Scala, c’est qu’il n’existe pas d’IDE aussi avancé que pour Java. Ceci dit, je n’ai pas du tout souffert de ce manque. J’utilise le plugin eclipse fourni sur le site officiel, qui permet l’auto complétion et rajoute de la couleur et honnêtement, ça suffit largement. C’est à se demander si une grosse partie de l’outillage nécessaire en Java n’était finalement pas lié aux lacunes de Java !

Pour comparer voici les 2 codes Java et Scala mis côte à côte. J’ai essayé de réduire au maximum le code Java ! On remarquera qu’en Java, j’ai été obligé d’avoir une variable non final.

import java.io.*;
import java.util.*;

public class Reader {

	private final String directory;

	public Reader(final String dir) {
		this.directory = dir;
	}

	public final List<String> readAll() {
		final String[] fileNames = new File(directory).list();
		final List<String> ret = new LinkedList<String>();

		for (String name : fileNames) {
			try {
				BufferedReader buf = new BufferedReader(new FileReader(directory + "/" + name));
				String line = buf.readLine();
				while (line != null) {
					ret.add(line);
				}
			} catch (FileNotFoundException e) {
				e.printStackTrace();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}

		return ret;
	}
}

No comment :

import java.io._

class Reader(dir: String) {
    def readAll() = {

        def readLines (name : String) = {

            def read(buf : BufferedReader, acc : List[String] ) : List[String] = buf.readLine match {
                case null => acc
                case s => read(buf, s::acc)
            }

            read(new BufferedReader(new FileReader(dir + "/" + name)), Nil).reverse
        }

        new File(dir).list.flatMap(readLines)
    }
}

Réactiver votre cerveau

Apprendre un nouveau langage, c’est apprendre à penser autrement, cela bouscule nos neurones et comment dire : Ça fait du bien !

Scala offre beaucoup d’autres choses intéressantes, comme les traits,  les actors, sa gestion native du XML, son framework web « Lift », Comet etc. J’espère avoir le temps d’approfondir tout ça et d’en faire quelques articles.

Plus généralement, la programmation fonctionnelle offre d’énormes avantages, rendant obsolète bon nombre de patterns et de framework qui n’existent finalement que parce que, Java et les langages impératifs en général ont de nombreuses imperfections.

Source : http://www.scala-lang.org/

Voici son calcul de charges obligatoires :

TNS RSI (Commerçant / Artisan) :  45,2 %

TNS Prof. Libérale : 33%

Salarié : 22% de cotisations salariales et 30% de charges patronales donc : charges = 50%.

Vu comme ça, et étant donné la différence de prestation entre un salarié et un TNS (indemnités journalières, retraite, chômage..), il est plus souvent avantageux d’être salarié, voir complétement préférable pour un artisan au RSI.

Où est l’erreur ?

Alors pourquoi tout le monde ne se met pas salarié ? Les solutions pour le faire sont pourtant multiples ! L’erreur est simple, les taux sont corrects mais la base de calcul n’est absolument pas la même.

Pour le régime salarié, on applique les taux sur le brut versé alors qu’en TNS on applique le taux sur le net versé.

Petit rappel mathématique : y * taux = x  n’est pas égal a x * taux = y.

D’un coté on a brut * (1-taux) = net

de l’autre coté on a : net * (1 + taux) = brut (<=> net = brut * (1/(1+taux)) )

Jusqu’à preuve du contraire 1/(1+taux) n’est pas égal a (1-taux). On compare donc des choux et des carottes.

Pour être plus clair, voici un tableau comparatif avec des exemples facile à comprendre :

Attention, les taux ne sont qu’un ordre de grandeur, en réalité cela varie un peu en fonction des situations.

La comparaison entre salarié et TNS pour un indépendant en informatique, donc en profession libérale, se fera  soit en comparant 81% à 33%  de charges sur le net,  soit en comparant 45% à 25% de charges sur le brut.

En passant, attention au simulateur que l’on trouve sur http://www.freelance-info.fr, il est faux pour les mêmes raisons. Utilisez plutôt notre simulateur.

Pour ceux qui ont la chance d’être resté en mission ou qui n’ont pas vu leur tarif baisser, ce n’est pas le moment changer. Et pour ceux qui ont subit, le risque est de continuer à subir quand le marché aura reprit. Alors comment avoir une vue globale sur le marché de la prestation Java en France ?

Personnellement j’utilise le baromètre du site hitechpros.com. Apprendre à décrypter ce baromètre permet de se faire une idée des tendances du marché.

Comment décrypter ces données ?

Premièrement, ignorer les pourcentages, ils correspondent aux ratios entre les différentes technologies. Cela n’a aucun intérêt, si ce n’est de savoir que les nouvelles technologies sont plus demandées que le reste…

La courbe bleue correspond aux offres de missions (demandes des clients), ramenée a 100% elle sert de base. La courbe rouge correspond aux prestataires disponibles (offres de SSII). Donc plus la courbe rouge baisse, mieux c’est. Pour le mois de septembre, on voit clairement que le ratio offres / demandes se rapproche de plus en plus du ratio pré crise. C’est un premier indicateur qui indique simplement que le marché s’équilibre. Cela ne veut pas dire qu’il y a un plus grand choix de mission, ni que la crise est terminée mais simplement que pour le mois en cours, il y a eu 242 missions pour 457 prestataires. On en déduit qu’il faut théorique au maximum 2 mois pour trouver une mission et en moyenne 1 mois.

Ce ratio baisse aussi si les SSII ont moins d’intercontrat. Et vue qu’elles ont stoppées les recrutements, il est mécanique qu’il baisse. Les jeunes diplômés payent aussi pour cette crise.

Pour se faire une idée de l’évolution réelle de la demande il faut donc jeter un oeil aux mois précédents. Il y avait 255 missions en Septembre, 119 en Août et autour de 200 les mois précédents. Août est traditionnellement peu dynamique;nous l’ignorons donc. Les demandes étaient donc d’environ 200 par mois pendant la crise. Si le nombre d’offres continue de progresser on peut s’attendre à un retour à des tarifs décents.

Voici mon analyse :

- Actuellement le nombre d’intercontrat baisse fortement et les clients commencent à avoir du mal à trouver des ressources. Les indépendants trouvent facilement des missions mais mal payées.

- Si la tendance se confirme, les SSII vont recommencer à recruter afin de répondre aux exigences des clients, les débutants et chômeurs vont réussir à trouver du travail mais moins bien payé qu’avant 2007, car les tarifs n’auront pas encore remontés.

- Lorsque le vivier d’inter-contrats et de jeunes diplômés sera absorbé, le prix commenceront à remonter et les salaires feront de même. Il sera temps pour les indépendants de profiter de cette dynamique avant la prochaine crise.

Pour conclure, n’oubliez pas que le meilleur moyen de rester employable, crise ou pas crise est de se former ! En mission comme à la maison ou en dehors. Ainsi que de bien choisir ses missions !

Et vous comment vivez vous ou avez vous vécu cette crise ? Quelle est votre stratégie pour les mois à venir ?

- http://www.waterfallmanifesto.org :  Site parodique sur les anciennes méthodes de développement (mais hélas toujours d’actualités) .

- http://blog.crisp.se : Vue artistique d’une journée de dev avec la méthode Kanban.

- http://www.scala-lang.org/ : Nouveau langage à typage fort, à la fois objet et fonctionnel, qui fonctionne sur la plateforme Java (compilé en bytecode). Formidable language sur le papier, je reste perplexe quant à son adoption par le plus grand nombre.

- http://www.kiad.org/ :  Blog généraliste du PDG d’Owlient. Articles sur le Web de très bonne qualité.

- Bases de données dénormalisées : Article très instructif sur la nouvelle génération de bases de données dites « Dénormalisées », utiles pour les applications effectuant un très grand nombre de lectures et peu de modification.

Faire ce qu’on a envie de faire et que l’on sait bien faire… à condition que ce soit monétisable (…).

Je suis resté pas mal de temps à regarder ce schéma et à réfléchir aux actions à mettre en place pour « monétiser ce que je sais faire et que j’ai envie de faire » et pour « progresser sur ce que je veux faire et qui est monétisable mais que je ne maitrise pas ». Que du bon sens mais je trouve utile d’avoir un schéma simple pour stimuler la réflexion.

source

Dans 4 jours, cela fera 4 mois que je suis « libre », ou plutôt devrait je dire « nous » car nous sommes 2 à avoir changé de statut en même temps. C’est l’heure de faire un premier bilan sur ce qui a changé dans nos vies.

• Malgré la crise, nous avons trouvé une mission avant la fin de nos préavis, avec au final moins d’une semaine d’inter-contrat chacun. Et pourtant, nous n’avons que peu d’expérience : respectivement 3 et 4 années. Nos profils sont « standards » mais avec Internet, les sites de missions pullulent et le temps où il fallait être « connu », voir « reconnu » pour trouver une mission est bel et bien révolu.

• La création ensuite. Le choix, soit disant plus compliqué de l’EURL c’est révélé être d’une extrême simplicité. Tous les documents-types sont disponibles sur Internet et les démarches faisable à distance.

• Au quotidien, rien n’a changé ou presque. Les missions sont du même type qu’en étant en SSII, notre métier n’a pas changé. Il n’y que quelques petites paperasseries en plus : les factures et les notes de frais à la fin du mois. Un petite visite chez le comptable de temps en temps pour éclaircir certains points et transmettre les premières pièces comptables. Il faut compter entre 30 minutes et une heure par mois de travail supplémentaire par rapport à un salarié.

• Coté budget, c’est le bonheur, nous avons fait une augmentation de 50% de nos revenus net. Sans compter les dividendes qui pourront monter à 3 mois de revenus chacun si nous faisons de bonnes années, c’est à dire : si nous n’avons pas d’inter-contrat. Soit un potentiel doublement de salaire. Ça laisse rêveur et j’avoue avoir encore  du mal à y croire.

• Coté épanouissement personnel, outre le fait de changer de mission après 3 ans chez le même client (ouf!), l’importance de rester « à jour » a pris tout son sens. Fini d’attendre le DIF ou que la DRH daigne accepter la formation de nos rêves. Si nous ne le faisons pas nous même, personne ne viendra le faire à notre place, du coup le temps libre que nous passions à se tourner les pouces, nous le passons dorénavant à nous auto-former : que ce soit en anglais, sur les technologies émergentes ou sur des domaines annexes tel que l’organisation, le management ou l’économie. Au programme : prototypes, livres, logiciels d’anglais, blogs, forums, conférences … En 4 mois j’ai plus progressé en anglais qu’en 10 ans de scolarité et plus appris techniquement qu’en 3 ans de salariat et je peux vraiment dire que cela me rend « heureux ».

La suite ? Toutes les portes sont ouvertes.  Les possibilités d’évolution sont nombreuses. Ce qui est sûr c’est que jamais je ne serai de nouveau salarié. Nous n’hésiterons pas à prendre un mois de « vacances » supplémentaire pour passer des certifications ou à l’inverse, prendre 4 mois de vacances pour faire un tour du monde… ou développer un nouveau produit !

Comme nous le rappel dans un style plutôt décalé jeunerebeumillionnaire dans son manifeste de l’équation sécrète, le meilleur investissement qu’une personne – et donc un indépendant – puisse faire, c’est dans sa formation.

Internet est un outil formidable pour se former, on l’a vu avec les castcodeurs et javablackbelt (dans d’autres domaines, il existe également de nombreux sites, je pense notamment à l’apprentissage de l’anglais).

Aujourd’hui, l’ on vient de faire un pas de géant au niveau des ressources francophones avec Octo et son Université du SI. Un grand nombre de conférences de très bonnes qualités, viennent d’être mise en ligne. Bon visionnage !

Alors comment faire ?

1) Prendre les devants : Si vous avez un intermédiaire, demandez à ce qu’il fasse appel à un service d’afacturage et d’être payé a J+10, J+20. Ainsi, en cas de défaut de paiement, vous vous en rendrez compte plus rapidement. Si vous n’avez pas d’intermédiaire, faites le vous même… cela coute généralement 3% à 5% du montant HT de la facture mais permet de mieux dormir la nuit !

2) En cas de problème avéré, il existe un moyen très simple quand les relances amiables et par courriers recommandés ont echouées : envoyer une injonction de paiement via le tribunal de commerce. Simple à effectuer, c’est d’une efficacité redoutable : transmis par huisser avec tampon du tribunal, effet garantie. Plus d’infos ici.

Voici une excellente initiative d’un freelance : http://www.mavieauboulot.fr/blog