Reprise du message précédent :

 
Pourquoi ? Pratiquement tous les drivers sont embarqué dans l'OS soit directement dans le noyau soit en tant que modules. Avec Windows, c'est sûr que ca va pas marcher pareil... Enfin, ca dépend, ca peut marcher aussi si tout le HW est compatible avec les drivers génériques embarqués.

Bon ben pas de souci sous Windows (juste à installer les drivers Intel)
 
Et si ça m'étonne, c'est parce que ce n'est pas la première fois que je fais ce genre de trucs, et que ça s'est rarement passé correctement

 
Les OS ont évolué aussi et le matos sous une apparence de diversification est en fait bcp plus limité qu'avant. Suffit que tu aies du intel dans ton laptop et tout va marcher OOTB.

Ouaip, ben c'est cool Moi qui pensais que j'allais devoir galérer toute la soirée à faire fonctionner tout ça

 
J'ai eu fait l'inverse : un HDD avec Windows XP, mis dans un PC où j'avais changé CM/RAM/Proc, et ça a démarré. Ca a pris un peu de temps, mais j'ai pas eu à réinstaller.

AMA de Snowden, Greenwald et Poitras ici et maintenant: http://www.reddit.com/r/IAmA/comme [...] and_glenn/
 
Greenwald, ce troll de compète:
 

https://www.youtube.com/watch?v=lp_PIjc2ga4

La CPAM... 10 à 12 semaines pour traiter une demande de changement de RIB.

Ah tiens j'ai fait partir le courrier hier

@shinuza : qu'est ce qu'il y  a sur smashingmagazine ?

De la merde, la plupart de leur article soient disant techniques sont une perte de temps.

/**
     * verrouille en même temps le dossier par AOP
     */
    public T findByIdForUpdate(final Long id) throws BusinessException {
        T persistedClass = findById(id);
 
        // Si le dossier a déjà été supprimé
        if (persistedClass==null) {
            throw new BusinessException("error.deletedObject" );
        }
        // Si le dossier a déjà été modifié
        else if (!isCurrentVersion(persistedClass)) {
            throw new BusinessException("error.oldObject" );
        }
        else{
            // Si le dossier n'est pas vérouillé le vérou est posé avant de le retourner
            if (!isLock(persistedClass)) {
                lockDossier(persistedClass);
                return persistedClass;
            }
            throw new LockReferenceException("error.lockedObject" );
        }
    }
 
    public T findByIdForDelete(final Long id) throws BusinessException {
        T persistedClass = findById(id);
 
        // Si le dossier a déjà été supprimé
        if (persistedClass==null) {
            throw new BusinessException("error.deletedObject" );
        }
        // Si le dossier a déjà été modifié
        else if (!isCurrentVersion(persistedClass)) {
            throw new BusinessException("error.oldObject" );
        }
        else{
            // Si le dossier n'est pas vérouillé le vérou est posé avant de le retourner
            if (!isLock(persistedClass)) {
                lockDossier(persistedClass);
                return persistedClass;
            }
            throw new LockReferenceException("error.lockedObject" );
        }
    }
 
    public T findByIdForMigration(final Long id) throws BusinessException {
        T persistedClass = findById(id);
 
        // Si le dossier a déjà été supprimé
        if (persistedClass==null) {
            throw new BusinessException("error.deletedObject" );
        }
        // Si le dossier a déjà été modifié
        else if (!isCurrentVersion(persistedClass)) {
            throw new BusinessException("error.oldObject" );
        }
        else{
            // Si le dossier n'est pas vérouillé le vérou est posé avant de le retourner
            if (!isLock(persistedClass)) {
                return persistedClass;
            }
            throw new LockReferenceException("error.lockedObject" );
        }
    }
 
 
    public T findByIdForArchive(final Long id) throws BusinessException {
        T persistedClass = findById(id);
 
        // Si le dossier a déjà été supprimé
        if (persistedClass==null) {
            throw new BusinessException("error.deletedObject" );
        }
        // Si le dossier a déjà été modifié
        else if (!isCurrentVersion(persistedClass)) {
            throw new BusinessException("error.oldObject" );
        }
        else{
            // Si le dossier n'est pas vérouillé le vérou est posé avant de le retourner
            if (!isLock(persistedClass)) {
                lockDossier(persistedClass);
                return persistedClass;
            }
            throw new LockReferenceException("error.lockedObject" );
        }
    }
 
    public T findByIdForUnarchive(final Long id) throws BusinessException {
        T persistedClass = findById(id);
 
        // Si le dossier a déjà été supprimé
        if (persistedClass==null) {
            throw new BusinessException("error.deletedObject" );
        }
        // Si le dossier a déjà été modifié
        else if (!isCurrentVersion(persistedClass)) {
            throw new BusinessException("error.oldObject" );
        }
        else{
            // Si le dossier n'est pas vérouillé le vérou est posé avant de le retourner
            if (!isLock(persistedClass)) {
                lockDossier(persistedClass);
                return persistedClass;
            }
            throw new LockReferenceException("error.lockedObject" );
        }
    }

 
Y'a des métriques qui vont être faciles à améliorer...

/**
     * Paquet de merde
     */

J'aime bien les noms en Franglais aussi.

Le français tout court a son charme aussi ("vérou", etc)
 
edit : tiens la findByIdForMigration a sa petite subtilité bien à elle  

c'est pas du français, ça veut dire verrue en portugais, 'oun grousse vérou'

 
Y'a des projets où t'as pas le choix.
Y'a des projets où c'est con de se forcer à l'anglais.

Bah oui, faut surtout pas que d'éventuels collègues non francophones puissent contribuer

 
Ah ? parce que du franglais c'est une contrainte ?    
Je veux bien qu'on impose le français pour certains clients, mais alors dans ce cas il ne faut pas le faire à moitié.

 
C'est quoi que tu ne comprends pas dans "certains projets" ?
Ici par exemple, la probabilité qu'un non-francophone bosse dessus est proche de 0, les utilisateurs et le domaine métier sont en français.
Il n'y a absolument aucun avantage à traduire le domaine métier en anglais pour ensuite devoir en permanence jongler entre le français des utilisateurs et l'anglais dans le code.
Aucune valeur ajoutée et perte de temps pour des points de style ? On va s'en passer hein.

Clairement, il y a des environnements ou la notion de collègues non francophones n'a aucun sens...

 
Les langages viennent avec un certain nombre de conventions et des classes qui sont en anglais.
A moins de bosser sur un """langage""" écrit en français, t'auras forcément du franglais dans tes noms de méthodes ou d'entités.
 
Les trucs importants selon moi sont :  
1) la cohérence : pas avoir un même terme tantôt en anglais, tantôt en français  
2) la contrainte de contributeurs non francophones
3) la langue dans laquelle est définie le domaine métier
 
Parce que si tu perds de vue ces points là, la critique du "franglais" dans le code est à peu près du niveau d'un "fuck kro$osft" de lycéen.

 
Pour les termes métier, ça a du sens, pour les autres non, clairement.
 

 
chuuuut, c'est un bug qu'ils n'avaient pas vu
 
 
Et globalement +1 avec Alt
 
 

 
Ca me choque aussi le franglais, même si je reconnais la pertinence de ton argument. Il me semble que des termes équivalents existent pour les concepts répandus d'abord en anglais, et donc, par facilité de lecture, qu'il vaut mieux tout mettre dans la même langue (pour pas jongler entre deux langages a la lecture). J'ajouterai aussi le risque des anglicismes qui changent de sens entre le mot anglais original et sa version anglicisée.

Tu auras forcement de l'anglais
Le français sans accent est une source de contresens.  
 

 
Effectivement le franglais est moins agréable à la lecture que d'utiliser uniquement de l'anglais, mais en contrepartie on n'a pas besoin d'une traduction complète du domaine métier.
Faut voir où le projet met sa priorité, la réponse ne sera pas la même partout (c'est le propos le plus important que je voulais faire passer)
 

Oui, j'ai pas dit qu'on pouvait faire du français pur, à moins de faire du WinDev (ou autre abomination qui traduit les constructions du langage).
Quant aux contresens liés à l'absence d'accents... c'est pas spécialement courant mais ça demande parfois un poil d'attention.

J'peux jouer ?    
 
Chez nous : tout en anglais, à tel point que même dans notre GitLab perso, les issues sont en anglais, alors qu'on est qu'entre nous
 
Et franchement, c'est mieux de tout passer en anglais, parce que ça évite de merder entre les specs et la rédaction. Exemple : faire une issue/spec avec le terme TVA, ya 99% de chance que le dev « réfléchisse pas » et utilise des champs "TVA" au lieu de "VAT".
 
Bonjour la cohérence. Donc à notre échelle : 100% anglais, pas de source d'emmerde. On s'y fait bien et ça roule nickel maintenant
 
Oui, on est pas la world company, mais un dev pas capable de tenir une discu au moins technique sur un bug tracker en anglais: nope. Nope, nope, nope.  

 
Je trouve ça plutôt distrayant et désagréable à lire, y compris quand les termes sont cohérents,
devoir passer de l'anglais pour les mots clefs au français pour les variables m'empêche de
lire le code de manière fluide, j'ai moins de facilité à dérouler l'exécution de tête.
 
En plus des mots clefs, y'a le problème des rôles et des structures qui ne sont pas spécifiques
au domaine métier, (factory, hash table...). Si c'est écrit en français, le mot passe mentalement
par une traduction en anglais, et ensuite le mot anglais allume la représentation dans ma tête.
 
Ceci dit, ne pas avoir un mot unique pour évoquer quelque chose au sein de toute une boîte est
aussi casse pied et participe à la divergence de vision entre les devs et la partie com'/market/public

Ah oui au passage : l'API de Paypal c'est du gros caca.
 
Stripe est environ 50 années lumières au dessus

J'ai pas de soucis avec le Français, même si dans l'absolu ton langage hôte sera probablement en Anglais. Mais pour le coup, pourquoi ne pas faire verouillerDossier plutôt que lockDossier, en dehors de l'économie de caractères.

Ça me perturbe un peu, ce concept.  
Entre l'outsourcing et l'ouverture des frontières intra-européennes, personne n'est vraiment à l'abri de produire du code qui ne sera pas lue par un non-francophone.
 
Mais je dois manquer de billes, je ne vois pas quelles sont ces "environnements ou la notion de collègues non francophones n'a aucun sens".

 
https://www.codeur.com/projects/670 [...] on-du-code
 
Budget: 5k-20k  
 
Il y en a qui rêvent.

SSII française / client français, je ne vois pas pourquoi un contributeur anglais (ou autre) devrait se présenter, j'ai travaillé sur des dizaines de projets petit ou gros où on s'en foutait éperdumment de l'anglais (y compris pour de grosse boites, genre administrations).

A l'inverse depuis quelques mois je bosse avec nos amis Belges et là bas l'anglais est de rigueur, y compris pour les mails, à cause de la forte communauté néerlandaise.

edit : ce message répondait à celui d'erulio

Note qu'ils ont reçu des propositions quand même, mais à coup de TJ plutôt qu'offre complète .
A 5k€ ils peuvent se gratter . A 20k€ c'est à peine réaliste...

Stratégiquement, c'est une bonne idée, si tu vois ce que je veux dire
 
Sinon, dossier, c'est directory en rosbeef.

bordel, mais quelle mentalité à la con... Pour justifier d'avoir pas factorisé le code, le dev me dit que "ouais, non, mais en fait si on fait ça, la CP doit revalider toutes les fonctions qui utilisent ce code, donc on peut pas lui demander ça"
 
Donc je lui réponds que s'il avait des TUs, des TIs, et des TFs, il pourrait lui garantir l'absence d'effet de bord sur le périmètre couvert, tout ça...  
 
Et lui me répond que "non, elle doit pas nous faire confiance, c'est elle qui est garante de la recette, si elle commence à faire confiance à ce genre de test, elle finira par avoir des problèmes, donc tant que ça fait ce qu'elle demande, on touche à rien.
 
bordel...

Houla tu t'avances bcp.
Tu n'as pas idée du nombre de projets franco-français dont la réalisation a été délocalisée en Inde.
 

J'voulais juste acheter des filtres aeropress et là paf, je sais pas ce qui s'est passé

Pas dans tous les domaines, en compta ou en légal tu as souvent différences subtiles entre des termes moins-que-plus équivalents, ou des concepts qui n'existent que dans certains pays/groupes de pays (genre le passif ça existe pas en compta anglo-saxonne, ils n'ont rien qui désigne liabilities + equity).

Site de paiement et gestion des impôts, trucs hyperlocaux.

 
Sans mauvais jeu de mots y'a un paquet de clampins qui en sont revenus, des projets délocalisés

 
Le terme de lock évoque des choses assez précises auxquelles t'as plutôt envie de penser
automatiquement quand tu codes (threads, deadlock, etc...) pour faciliter l'écriture de code correct.
 
Plus précisément, "foo.lock()" va pas provoquer la même réaction que "foo.setLocked()"
et va pas t'inciter à la même prudence.
Si tu traduis en français tu perds un peu de communication implicite entre les devs.
 
Dans le code en exemple c'est assez catastrophique par contre, "!isLock(persistedClass)"
est associé au commentaire "Si le dossier n'est pas verrouillé", j'arrive pas trop à savoir
si c'est une faute sur le terme anglais ou si il teste que la classe est un lock.

Ici, ce qui est d'ordre technique (donc un lock au sens ressource partagée) sera en anglais, ce qui est d'ordre métier sera en français.
Du coup si le fait de verrouiller quelque chose était une notion métier on l'aurait écrit en français.