code

giphy-facebook_s

Développeur : Un métier qui plait de plus en plus !

Posted by | Blog | No Comments

Découvrez les premiers résultats de la plus grande étude jamais menée par Stack Overflow sur les développeurs.

Jeudi 25 février 2016, l’équipe Stack Overflow investissait les locaux de Prestashop pour présenter en exclusivité les derniers résultats de son étude 2016, basée sur les réponses de 56 000 développeurs interrogés à travers 173 pays, dont 1 626 français. C’est la plus importante étude de ce genre jamais réalisée par Stack Overflow.

L’assistance était principalement composée de recruteurs et autres RH, avides d’en savoir plus sur les profils les plus insaisissables du marché. Il manquerait chaque année en France près de 5 000 ingénieurs dans l’industrie du numérique. Au cas où vous en douteriez encore, développeurs, la balle est donc dans votre camp !

Dans le monde, 58 % des développeurs sont autodidactes

Seuls 13 % des développeurs interrogés par Stack Overflow se déclarent à la recherche active d’un emploi. Une recherche dont la durée moyenne est estimée en France à 7 jours, où on compterait 5 à 6 jobs par développeur… 62 % sont en poste mais restent à l’écoute du marché, 24 % ne sont pas intéressés par de nouvelles opportunités.

Fait intéressant : au niveau mondial, 58 % des développeurs sont autodidactes, seuls 56 % détiennent un diplôme de programmation. C’est loin d’être le cas en France, où le diplôme est encore très largement plébiscité. Notons également une hausse de 6 % des développeurs ayant suivi des cours de programmation en ligne cette année.

Le salaire moyen du développeur est estimé à 46 646$ par an. Les deux-tiers des développeurs gagnant moins de 20 000$ par an recherchent activement un autre job, quant aux développeurs les mieux lotis – entre 120 et 170 000$ par an, aucun d’entre eux ne souhaite changer d’emploi.

Le code, plus qu’un métier, une passion

Les développeurs utilisent majoritairement JavaScript, SQL et Java, mais se servent plus rarement de R, Coffee Script et G and Dart.

85,7 % des développeurs interrogés déclarent passer au minimum une heure par semaine à programmer pour des projets perso, 17 % y consacrent plus de vingt heures par semaine. C’est dire l’importance que prend le code, considéré comme une véritable passion, dans la vie de la majorité des développeurs !

L’équilibre entre vie privée et vie professionnelle est plébiscité

À l’heure de choisir un emploi, les développeurs se penchent principalement sur le salaire qu’on leur propose, sur la qualité de l’équipe qu’ils vont rejoindre, mais aussi sur l’équilibre entre vie professionnelle et vie privée de leurs futures conditions de travail. Curieusement, pour une raison que Stack Overflow ne s’explique pour le moment pas, en France, les hommes plébiscitent davantage cet équilibre que les femmes.

Enfin, le tout n’étant pas d’être recrutés, mais de rester en poste, le plus important pour les développeurs interrogés est d’apprendre de nouvelles technologies, de construire régulièrement de nouveaux projets, et d’avoir un minimum de pouvoir de décision sur les produits qu’ils développent.

La messe est dite !

source DevMag.fr

bercy

Les députés imposent la communication du code source des logiciels de l’État

Posted by | Blog | No Comments

La commission des lois a adopté un amendement qui impose à l’État et aux collectivités territoriales de communiquer le code source des logiciels qui sont produits dans le cadre de services publics.
Contre l’avis du gouvernement, la commission des lois de l’Assemblée nationale a adopté mercredi matin l’amendement n°CL534 présenté par le rapporteur Luc Belot, qui impose à l’administration de communiquer sur demande le code source de logiciels qu’elle développe et utilise.
L’amendement ajouté au projet de loi pour une République numérique impose que soient considérés comme des documents administratifs pouvant faire l’objet d’un droit de communication les codes sources des logiciels produits par « l’Etat, les collectivités territoriales ainsi que par les autres personnes de droit public ou les personnes de droit privé chargées d’une mission [de service public] ».
En séance, la secrétaire d’État au numérique Axelle Lemaire a expliqué que le gouvernement était défavorable à la généralisation de la publication du code source des logiciels utilisés par l’administration, par crainte qu’une telle communication puisse favoriser les fraudes. Sans doute l’État craint-il que des personnes mal intentionnées puissent partir à la recherche de bugs dans les logiciels utilisés pour vérifier l’éligibilité à certains droits, ou pour calculer des sommes dues, et parviennent à les exploiter à leur bénéfice.
image: http://www.numerama.com/content/uploads/2015/12/bercy-1900-1024×582.jpg
bercy-1900
Axelle Lemaire a toutefois annoncé que le ministre des finances Michel Sapin avait enfin accepté d’imposer à ses services de communiquer le code source du logiciel utilisé par Bercy pour calculer l’impôt sur le revenu.
Dans un avis du 8 janvier 2015, la Commission d’accès aux documents administratifs (CADA) avait estimé que « les fichiers informatiques constituant le code source sollicité, produits par la direction générale des finances publiques dans le cadre de sa mission de service public, revêtent le caractère de documents administratifs ». L’amendement adopté, qui devra être confirmé en séance plénière, vise donc à généraliser cette décision pour l’ensemble des administrations et des logiciels produits par ou pour le service public.

En savoir plus sur http://www.numerama.com/politique/138542-les-deputes-imposent-la-communication-du-code-source-des-logiciels-de-letat.html#Yj52bpVSbWSFDbzr.99

Article par Guillaume Champeau, source : numerama.com

php 5.6

PHP 7 vs PHP 5.6 : le comparatif de performance du JDN

Posted by | Blog | No Comments

La direction technique de CCM Benchmark, éditeur du JDN et de Comment Ça Marche, a testé la nouvelle version de PHP. Voici les résultats.

L’un des principaux apports annoncés de la version 7 du langage PHP est d’améliorer la performance d’exécution des applications. C’est là la promesse faite par Zend, l’un des principaux acteurs du projet PHP, à travers le chantier phpng (PHP Next Generation). Grâce à une refactorisation du moteur PHP, son objectif était de proposer un noyau entièrement réoptimisé.

Un travail qui est passé notamment par un grand ménage dans le code de base du langage, un nettoyage des API, ainsi qu’une meilleure gestion de l’allocation de la mémoire vive. Et même si phpng pouvait engendrer des problèmes de compatibilité avec certaines extensions, l’intégration de cette branche à PHP 7 a finalement été approuvée par les contributeurs au projet PHP. Toujours en matière de perf, PHP 7 introduit, aussi, le stockage natif des threads en local.

Des gains de performance de 50%

Au final, la mise à jour des applications vers PHP 7 peut engendrer d’après les équipes de Zend un surcroît de performance de 25% à 70%. Pour illustrer ces gains, des benchmarks de performance ont d’ailleurs été publiés par la société de Zeev Suraski et Andi Gutmans (qui, rappelons-le, vient tout juste d’être acquise par Rogue Wave Software).

En vue de se faire une idée plus précise des capacités de PHP 7, les équipes techniques de CCM Benchmark se sont mobilisées. Elles ont effectué des comparatifs de performance entre PHP 5.6 et PHP 7 (en préversion RC4) sur plusieurs sites du groupe développés en PHP, notamment JDN et Comment Ça Marche.

Des gains de performance
historiques

« Nous nous sommes concentrés exclusivement sur la performance du langage et avons exclu tout le reste, notamment le réseau et la couche base de données », précise Xavier Leune, responsable Framework PHP chez CCM Benchmark. C’est l’outil de testopen source ApacheBench qui a été utilisé pour simuler les connexions, et les points de mesure ont été réalisés grâce à des sondes ajoutées en début et fin d’exécution de chaque page. Au total, 1000 requêtes ont été lancées depuis 25 clients en parallèle sur chaque page testée. La configuration de la plateforme sous-jacente ? Elle s’adosse à des serveurs avec des processeurs intel i7-2640M. 4Go de RAM sont dédiés à chaque machine virtuelle. Côté logiciel, Apache 2.4 (sous Debian 8) est utilisé, avec à la clé une configuration PHP 5.6.

Les résultats de notre benchmark ? Des gains jusqu’à 50% sont observés en temps d’exécution CPU entre PHP 5.6 et PHP 7, et de près de 50% également en consommation de mémoire. « C’est au-dessus de ce que nous avions anticipé. Je n’ai jamais vu un tel différentiel de performance lors des précédentes montées de version , note Xavier Leune. « L’impact du refactoring du moteur sur l’empreinte CPU est très significatif, et l’optimisation du stockage en mémoire des variables porte ses fruits. »


Comparatif de performance CPU et mémoire sur la page d’accueil de JDN Développeur. © CCM Benchmark

Comparatif de performance CPU et mémoire sur une page d’article du JDN. © CCM Benchmark

source : journaldunet
google dart

Google Dart finalisé

Posted by | Blog | No Comments

Dart est prêt. Google a publié le SDK de son langage web, développé en interne, en version 1.0. Son but : améliorer le Javascript, pour lequel il se présente en alternative. Plus efficace pour la programmation côté développeurs, plus performant pour les sites et apps web côté utilisateurs.

Cette version 1.0 marquerait la fin d’une période de test, et l’entrée de Dart « dans le monde réel », selon Lars Bak, leader du projet. Lancé il y a deux ans, le projet consiste en un nouveau langage de programmation simple à apprendre pour les développeurs connaissant Javascript.

Deux langages en parallèle ? Ouille…

Une version Dartium du navigateur Chrome a également été mise à jour, qui permet de faire tourner directement les programmes Dart. Pour les navigateurs qui ne le prennent pas en charge – tous les autres donc – Google a prévu un outil dart2js permettant de convertir les programmes Dart en Javascript.

C’est là que pèche le projet : en dehors de Google, aucun autre éditeur de navigateur n’a été convaincu par Dart. Le Javascript est déjà bien implanté, comprend des librairies déjà écrites à la pelle, s’améliore régulièrement au niveau rapidité d’exécution et est à la veille d’une évolution importante avec EcmaScript 6.

Javascript est sans doute imparfait, mais les concurrents de Google ne voient pas l’intérêt qu’ils auraient à soutenir un second langage aussi fondamental pour le web. Plus de complexité en découlerait, d’autant que Javascript est largement utilisé sur des millions de pages web.

D’où des difficultés pour Google à évangéliser : dur de trouver des programmeurs, des évangélistes, de mettre sur pied des librairies aussi nombreuses que pour Javascript ou d’engager des développeurs pour améliorer le produit et boucher ses failles. Reste que Google ne croit pas pour autant à l’abandon de Javascript : il tente même, en parallèle, de le pousser dans ses retranchements pour le faire évoluer plus vite.

Lire sur zdnet.fr

php7

Des news PHP7

Posted by | Blog | No Comments

Zend, la société à la tête du projet PHP, vient de dévoiler une infographie qui fait le point sur la future version du langage. On y apprend que sa sortie est prévue pour cette année.

Zend vient de diffuser une infographie qui donne un bon aperçu de l’état d’avancement de PHP 7, la prochaine version de PHP. Elle se décline en quatre principaux points.

 1. PHP 7 sortira en 2015. La date de lancement de PHP 7 a été arrêtée au 7 octobre 2015. « Même si cette date est décalée, cette version devrait être disponible d’ici la fin de l’année », indique Zend, qui précise que les spécifications de la nouvelle mouture sont presque finalisées.

 2. Les Spaceships PHP 7 introduisent un nouvel opérateur de comparaison <=>. Il pourra être utilisé pour combiner des comparaisons (un décryptage en français ici).

 3. Les Return Type Declarations & Scalar Type Hints permettront de déclarer (de manière optionnelle) un type de retour pour les fonctions et méthodes. Les Type Hints comme cette nouvelle déclaration pourront en outre prendre en charge les types scalaires (pour préciser le retour attendu en matière de nombre ou chaîne de caractères).

 4. PHP 7 sera plus rapide. Cette nouvelle version est basée sur PHPNG (pour PHP Next-Generation). Ce projet a été lancé par Zend en réponse à l’initiative HHVM de Facebook, qui avait pour but de proposer une version de PHP qui se voulait plus performante. Selon Zend, la mise à jour des applications vers PHP 7 pourrait engendrer un surcroît de performance de 25% à 70%.

 

source : journaldunet

HTML5

HTML5 finalisé

Posted by | Blog | No Comments

La spécification de la dernière mouture majeure de HTML a été publiée par le W3C en version finale. Elle est passée hier à l’état de recommandation officielle.

C’est un projet de près de 10 ans de travail qui s’achève au sein du W3C. Le consortium vient de publier la spécification de HTML5 en version finale. Le langage est ainsi érigé à l’état de recommandation. La cinquième itération de HTML est donc désormais considérée comme un standard par le groupement.

HTML5 a pour but de faire entrer Internet dans l’ère du Web enrichi. Il introduit un très grand nombre d’évolutions utiles aux sites mobiles (en facilitant notamment la création de pages enresponsive design), ainsi qu’aux applications cloud. Dans cette optique, il apporte tout un lot d’interfaces de programmation (API) JavaScript. Au programme notamment : l’API History pour gérer la navigation, ContentEditable pour l’édition en front office, Web Storage pour le stockage côté client, ou WebSocket pour gérer une communication bi-directionnelle (et asynchrone) entre navigateur et serveur.

HTML5 : le tueur de Flash

A cela s’ajoute l’introduction de nouvelles balises (<video>, <audio> et surtout <canvas>) permettant de positionner HTML5 en concurrent direct de Flash. Ce qui s’est d’ailleurs d’ores et déjà révélé le cas sur le terrain. Alors que les « préversions » de HTML5 commençaient à être adoptées, la part de marché de Flash n’a cessé de fondre ces dernières années. Adobe a d’ailleurs été obligé de repositionner sa technologie sur le jeu et la vidéo, et de rapidement réécrire ses outils développement Web pour prendre en compte HTML5.

Pourquoi le passage de HTML5 a l’état de recommandation a demandé tout ce temps ? Depuis l’annonce de la finalisation de la spécification début 2012, le W3C a déroulé une batterie de 100 000 tests. Objectif : s’assurer de la prise en charge du langage par le plus grand nombre de configurations clientes. « La finalité était de tenir la promesse de HTML5 qui est de pouvoir écrire une application une fois, et de la déployer partout », conclut le W3C.

 La spécification HTML5 à l’état de recommandation (site du W3C)

 

source JDN

php 5.6

PHP 5.6 : la nouvelle version disponible

Posted by | Blog | No Comments

Le langage introduit notamment le débogueur phpdbg. Le téléchargement des fichiers de plus de 2 Go est aussi désormais possible.

La version 5.6 de PHP est disponible depuis la semaine dernière en téléchargement sur le site du projet open source. Il s’agit de la dernière mise à jour importante du langage de script orienté serveur avant le lancement de sa version 7 (la branche 6 ayant été abandonnée, suite à des problèmes rencontrés dans le cadre de l’intégration de l’Unicode).
Aux côtés de la correction de bugs, PHP 5.6 introduit nombre de nouveautés, dont aucune ne ressort véritablement du lot. On note néanmoins parmi elles la possibilité de télécharger des gros fichiers, de plus de 2 Go. Ou encore l’introduction du débogueur phpdbg – qui vient remplacer X-Debug. Il apporte une meilleure gestion des points d’arrêt, et présente l’avantage d’être agnostique côté SAPI.

Les principales autres évolutions et nouveautés de PHP 5.6 :
La prise en charge des expressions scalaires constantes,
Les fonctions variables, l’exponentiation et les décompressions d’arguments sont désormais possibles via l’opérateur,
php://input est ré-utilisable,
La surcharge d’opérateurs et le transtypage en types scalaires sont supportés par les objets GMP,
La fonction hash_equals() a été ajoutée pour comparer deux chaînes (en vue d’éviter les attaques de type timing),
L’algorithme de hashage gost-crypto est introduit,
La gestion des protocoles SSL/TLS est améliorée (pour une meilleure vérification des protocoles, et un contrôle plus fin des correspondances)

source php.net

mobile-plateform-dev

Les développeurs privilégient les smartphones et tablettes Android/iOS

Posted by | Blog | No Comments

Chiffres : Pour leurs applications mobiles, les développeurs ciblent en priorité les smartphones Android (64%) et iOS (55%), puis les tablettes Android (54%) et les iPad (48%). Mais Windows Phone trouve peu à peu sa place (30%), tout comme Firefox OS (16%).

 

Dans la bataille des plateformes mobiles, Android et iOS continuent de bénéficier d’une longueur d’avance dans les préférences des développeurs d’applications. Les OS de Google et Apple se taillent la part du lion selon une étude de Forrester.

Pas de mystère pour le cabinet, en raison de leur large adoption par les consommateurs et dudéveloppement du BYOD en entreprise, Android et iOS sont privilégiés par les développeurs pour le support de leurs applications.

Windows Phone n’est plus négligé 

Android devance même iOS d’après les données de Forrester. 64% des développeurs ciblent en priorité les smartphones Android, devant l’iPhone (55%). Viennent ensuite les tablettes sous Android (54%) et les iPad (48%).

Pour autant, Forrester assure que les jeux ne sont pas faits et que le marché du mobile ne se partage plus entre seulement deux plateformes. Ainsi environ un tiers des développeurs sur mobile ciblent désormais les smarptphones Windows Phone. Et sur certains marchés, en particulier le Brésil, Microsoft renforce sa présence avec 41% de développeurs supportant Windows Phone.

 

Malgré sa jeunesse, Firefox OS suscite déjà l’intérêt des développeurs (16%). L’OS mobile de Mozilla supplante ainsi les terminaux BlackBerry (13% et 10% pour BB 10), ainsi que Bada (13%) et Tizen (3%) ou encore WinRT (13%), le système Microsoft pour les tablettes ARM.

 

Source : ZDnet

 

ruby

Ruby : Objections sur la vulnérabilité CVE-2014-2734

Posted by | Blog | No Comments

Objections sur la vulnérabilité CVE-2014-2734

Il a récemment été mis en lumière une vulnérabilité qui pourrait affecter Ruby, en l’occurrence CVE-2014-2734. Toutefois, sur la base d’une analyse détaillée retranscrite ci-dessous, nous considérons que Ruby n’est pasconcerné par cette faille de sécurité.

Cette faille donne à un attaquant la possibilité de contrefaire n’importe lequel des certificats racine, en modifiant sa signature (ce qui revient dans les faits à remplacer la clé privée originelle du certificat par une autre clé, choisie par l’attaquant).

Démonstration du problème

Ce qui suit est notre analyse de CVE-2014-2734. Nous avons été en mesure de condenser notre prototype initial en quelques lignes qui démontrent le cœur du problème :

require 'openssl'

forge_key = OpenSSL::PKey::RSA.new(2048)
raw_certificate = File.read("arbitrary.cer")
cert = OpenSSL::X509::Certificate.new(raw_certificate)
resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new)

resigned_cert.verify(key) #=> true

Il peut effectivement sembler étrange que X509Certificate#verify soit évalué à true. Le certificat original peut contenir des métadonnées de typeSubject Public Key Info qui pointent vers la clé publique originelle, différente de la clé publique forge_key. Manifestement, la paire de clés (publique/privée) utilisée pour re-signer le certificat ne correspond plus à la clé publique originelle, référencée dans le hash de métadonnées. Pourquoi, dans ces conditions, #verify retournerait true ?

À propos de la vérification des clés

X509Certificate#verify fait usage de la méthode X509_verify d’OpenSSL, une fonction qui délègue en fait à ASN1_item_verify. Ces fonctions vérifient la validité de la signature, étant donnée une clé publique initiale. Cependant, elles ne vérifieront pas si la clé en question correspond à une éventuelle clé publique référencée dans le certificat. C’est pourquoi la valeur de retourtrue est bien le comportement attendu pour X509Certificate#verify, dans ce cas précis. Il faut bien comprendre que ne pas effectuer cette « double vérification » ne remet en aucun cas en cause la sécurité du modèle de confiance X.509.

La section 4.1.1.3 de la RFC 5280 rend explicite le fait que, en calculant la signature d’un certificat, la CA (Certificate Authority) confirme de facto la validité des informations contenues dans le-dit certificat. Bien que ce principe soit visiblement bafoué dans l’exemple ci-dessus, il n’implique en fait aucune faille de sécurité, du fait de l’implémentation de la procédure. Un certificat modifié de cette façon ne saurait être utilisé par un attaquant, à moins que l’attaque ne soit effectivement en mesure de vous faire explicitement admettre que le certificat est valide.

Les risques potentiels

Deux cas sont à considérer :

Le fait de signer à nouveau un certificat racine

En tant qu’utilisateurs de certificats, nous plaçons une confiance inconditionnelle dans les certificats racines. Quand bien même ils ne contiendraient pas des informations valides, le fait qu’ils aient été approuvés publiquement par une autorité de certification les rend digne de confiance. Ils agissent comment des valeurs pré-configurées dans nos navigateurs ou nos systèmes d’exploitation : le simple fait de les posséder leur donne le statut de référence. À ce titre, même OpenSSL ne prend pas la peine de vérifier la signature de ses propres certificats racines, arguant du fait qu’ils sont auto-signés (cf. X509_V_FLAG_CHECK_SS_SIGNATURE documentation).

À ce titre, un certificat racine re-signé est immédiatement considéré comme digne de confiance, même dans le cas où il contiendrait des informations erronées (Subject Public Key Info). Ce certificat étant racine, il n’y aucune différence avec un certificat racine « valide », donc aucune raison de procéder à une vérification. En principe, n’importe qui peut produire des certificats racines auto-signés qui correspondent point pour point à un certificat racine déjà existant, à l’exception bien sûr de la signature. On comprend alors qu’en jouant sur le fait que nous faisons confiance aux certificats racines que nous possédons, pour la simple raison que nous les possédons, il devient possible à quelqu’un en capacité de produire un vrai-faux certificat racine et de le mettre en place chez quelqu’un, de se créer un vecteur d’attaque important.

Le fait de re-signer un certificat intermédiaire

Si le fait de re-signer un certificat racine ne représente pas une faille de sécurité en tant que telle dans le modèle de confiance X.509, il en va de même pour le fait de re-signer un certificat intermédiaire, mais pour une raison tout à fait différente.

Nous ne possédons en général pas de certificats non-racine en avance. Une contrefaçon sur ce type de certificat sera par conséquent détectée lors de la procédure de validation (path validation procedure). Il s’agit ici de vérifier la signature de tout certificat non racine en utilisant la clé publique du certificat d’autorité correspondant. Si le certificat non racine en cours de vérification a été modifié, sa non conformité sera tout simplement détectée sous la forme d’une signature non valide. Il s’agit du modèle de confiance standard.

Conclusion

En résumé, nous sommes convaincus que X509Certificate#verifyn’introduit pas de faille de sécurité d’un point de vue technique. D’autres analyses indépendantes sont arrivées à la même conclusion, de sorte que nous avons décidé de demander le retrait de CVE-2014-2734. Vous pouvez lire l’analyse complète sur le prototype original.

Source : ruby-lang.org