Clever Garden, Clever Age, Clever Presence - 100% digital

eZ Systems délivre une nouvelle version entreprise : eZ Publish 4.7 Etna

Matthieu Severe — 2012-05-16T08:12:26Z

Sous le nom de code Etna eZ Systems délivre une nouvelle version d'eZ Publish, la dernière avant la refonte complète à venir (fin d'année) plus connue sous le nom d'eZ Publish 5. Cette version marque l'arrivée d'un certain nombre de services orientés entreprises disponible dans la marketplace eZ. Nous sommes donc soulagé de voir que les développements sont bien découplés du noyau et que le lien avec la version communautaire est toujours présent.

Côté nouveautés une version dans le cloud d'eZ est maintenant disponible. On trouve également une intégration analytics en temps-réel ainsi que le support natif de l'A/B Testing. Une extension, "App Factory", permet de générer à la volée des applications natives iPhone, iPad et Android branchées sur un eZ Publish, tandis qu'une version "web app" est disponible via du responsive design. Parmi les autres extensions intéressantes il faut noter un connecteur Magento et une nouvelle interface d'édition plus orientée contributeur.

Les développeurs attendent tout de même plus d'informations sur la future nouvelle API qui devait sortir en beta avec cette version afin d'anticiper une compatibilité des développements avec eZ Publish 5.

Microsoft prend la défensive

Aurelien Masfrand — 2012-05-10T12:47:16Z

Il y aura 2 versions de Windows 8 : x86 et RT (ex on ARM) ; mais la version RT sera remplie de ventes liées. Déjà prévue avec la suite OFFICE 15, l'annonce récente de l'intégration d'un seul et unique navigateur provoque la ire des éditeurs de Firefox et Chrome. On ne sait pas encore comment Microsoft compte commercialiser Windows RT en Europe. L'UE avait obligé sur les précédentes versions de mettre en place un choix de navigateur lors de l'installation de l'OS. Est-ce que cette position défensive (...)

- Nos réactions "à chaud" / Clever Age

La sécurité au travers de l'OWASP

Mickael Franc — 2012-05-10T08:57:32Z

La qualité d'une application web est intrinsèquement liée à la sécurité de cette dernière, c'est pourquoi nous avons décidé de vous faire une introduction sur l'OWASP et quelques concepts sur la sécurité applicative.

1. Définition

OWASP (Open Web Application Security Project) est un guide de sécurisation des applications web, c'est un "ouvrage" de référence des bonnes/mauvaises pratiques de développement, d'une base sérieuse en termes de statistiques, et d'un ensemble de ressources amenant à une base de réflexion sur la sécurité. Des outils sont aussi proposés pour effectuer un audit de sécurité.

2. Les projets de l'OWASP

De nombreux projets développés en interne sont proposés et disponibles librement sur le site officiel : https://www.owasp.org

Ces projets permettent aussi bien de faire de la veille, comme le TopTen d'OWASP qui liste annuellement les failles les plus couramment utilisées par des utilisateurs malveillants. Mais aussi des logiciels puissants, permettant de faire des audits de sécurité avancés sur n'importe quelle plateforme.

Sur le site d'OWASP est disponible un grand nombre d'articles détaillés sur des failles/vulnérabilités. Ces articles expliquent : le principe d'une faille, son impact, une ou plusieurs méthodes d'attaques, et un mécanisme de protection.

Le guide OWASP propose aussi des documents plus méthodologiques encadrant l'univers d'un RSSI (Responsable de la Sécurité des Systèmes d'Informations). Ces documents offrent une bonne pratique pour définir et qualifier les risques auxquels pourrait être confrontée une société, une application, etc... Afin de couvrir l'ensemble de l'environnement (humain et applicatif) pour ensuite manager les équipes sur les projets.

Voici une liste (non exhaustive) de projets populaires, ainsi qu'une description succincte :

- Top Ten : Liste des failles les plus couramment utilisées par des utilisateurs malintentionnés sur internet. Ce document est accompagné d'une qualification des menaces listées et d'une explication sur l'exploitation.

Cf : https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=2010_Translation_Efforts

Voici le Top Ten de l'année 2010 (vulnérabilités listées de la plus commune à la moins exploitée) :

Injections
Cross-Site Scripting (XSS) => Script corrompu à travers un site
Broken Authentication and Session Management => Violation de Gestion d'Authentification et de Session
Insecure Direct Object References => Références directes non sécurisées à un Objet
Cross-Site Request Forgery (CSRF) => Falsification de requête intersites
Security Misconfiguration => Mauvaise configuration de sécurité
Insecure Cryptographic Storage => Stockage cryptographique non sécurisé
Failure to Restrict URL Access => Manque de Restriction d'accès au niveau des URLs
Insufficient Transport Layer Protection => Protection insuffisante de la couche Transport
Unvalidated Redirects and Forwards => Redirections et Renvois non validés

Ce top 10 évolue dans le temps, certaines failles (comme les problèmes de sécurité dus à une mauvaise configuration) n'étaient plus dans le classement entre 2004 et 2010. Cet exemple montre qu'il y a de nombreux autres points à vérifier, qui ne sont pas listés dans ce classement. Même si vous pensez avoir sécurisé votre application web, vous pouvez déjà être vulnérable face à quelque chose auquel personne n'a jamais pensé auparavant. Certaines vulnérabilités dans les articles d'OWASP sont non-applicables au web, mais peuvent servir de base à une réflexion sur la sécurité et la création d'un référentiel de sécurité.

Il faut voir cette liste comme un référentiel du minimum à sécuriser.

- Webscarab : Un outil d'audit de sécurité. Il s'agit d'un proxy disposant d'une interface graphique qui, une fois relié à un navigateur, intercepte les requêtes/réponses HTTP entre le client et le serveur, ce qui permet de les analyser, de forger des requêtes soi-même, de tenter différentes injections, etc... Le proxy est intercalé entre le client et le serveur à la façon d'une attaque « Man in the middle ». Webscarab dispose de nombreux plugins permettant d'augmenter le nombre de fonctionnalités offert par l'outil (WebServices, Spider, XSS/CRLF, SessionID Analysis, etc...).

Cf : https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Remarque : Par défaut il est livré avec uniquement l'intercepteur de requête, la version "self-contained" est livrée avec tous les plugins. Le gros défaut de cette solution est qu'elle n'est pas régulièrement mise à jour (dernière en date : 04 Mai 2007) et n'intègre pas les dernières vulnérabilités découvertes.

L'intérêt de cette solution : avoir un outil qui facilite un audit applicatif. Ce logiciel ne permettra pas d'avoir une application ayant une sécurité élevée s'il est utilisé seul. D'autres tests seront à faire pour accroitre la sécurité de votre application.

- Webgoat : Il s'agit cette fois d'une application web volontairement non sécurisée. Elle est livrée avec un tutoriel et des exercices pratiques. Une fois de plus, OWASP met en avant l'aspect pédagogique de ces solutions, ayant pour but d'instruire l'intéressé sur les différentes techniques d'exploitation de vulnérabilités. L'intérêt est de former le développeur à produire un code sûr.

Cf : https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

D'autres projets intéressants et utiles pour le milieu de l'entreprise existent, mais ils feront sûrement l'objet d'un prochain article plus détaillé.

3. Orienter les développements vers une démarche défensive

Chaque projet est différent et comporte un seuil de criticité propre à lui. C'est pourquoi il faut qualifier chaque risque associé à ce dernier.

Une méthode consiste à créer un tableau croisé entre les vecteurs d'attaques (XSS, CSRF, etc…) et les risques résultants de ces attaques (défiguration du site, corruption du contenu de la base de données, perte de données confidentielles, interruption totale/partielle de service, etc..).

Chaque projet devrait avoir son propre référentiel de sécurité (Base OWASP + Spécificités du projet + Risque acceptable ou non en fonction du projet).

Une fois les vecteurs d'attaques définis, on est en mesure de prioriser l'implémentation de correctifs de sécurité.

Conclusion

Le guide OWASP regorge d'informations utiles pour tout niveau de compétence. Le développeur non initié au domaine de la sécurité verra cet univers démystifié, l'expert y verra une base de connaissances sur laquelle il pourra se reposer. Les outils proposés sont efficaces même si certains ne sont pas assez maintenus ou accumulent un retard par rapport à d'autres solutions Open-source. L'OWASP reste toutefois un référentiel soutenu par le milieu professionnel et amène à une réflexion intellectuelle sur le domaine de la sécurité, auquel chaque développeur devrait être sensibilisé.

Clever Age SPONSOR PREMIUM du Drupal Camp Lyon les 26 et 27 mai 2012

Yan Paquis — 2012-05-04T09:09:14Z

Dans sa mission d'expertise technique objective et neutre, Clever Age reconnaît depuis de nombreuses années les atouts aujourd'hui incontestés de Drupal.

Du site web traditionnel aux applications basées sur des architectures complexes, des dizaines de projets ont été implémentés par nos équipes sur ce framework depuis sa version 4, couvrant des périmètres fonctionnels et environnements techniques très divers.

Fort de ses expériences et en tant qu'acteur-expert reconnu, Clever Age est fier de soutenir et sponsoriser le Drupal Camp se déroulant à Lyon les 26 et 27 mai 2012.

Nous serons également présents au travers de conférences animées par nos consultants qui illustreront certains cas pratiques rencontrés.

Optimisez vos imports de données avec Migrate
par Matthieu Guillermin
Mettez du temps réel dans votre Drupal avec Node JS
par Matthieu Guillermin et Nicolas Chambrier
Theming Drupal : tips & tricks par Mehdi Kabab

Nous espérons donc avoir le plaisir de vous croiser lors de cet évènement favorisant le partage, l'échange, et qui devrait être très riche d'enseignement pour tous.

Google Analytics et la performance Web

Boris Schapira — 2012-05-03T13:41:35Z

L'équipe de Google Analytics a publié un article donnant quelques chiffres sur la performance Web à travers le monde, issus de leur collecte de données.

Si l'on peut se féliciter que la problématique de la performance Web soit abordée (tant elle reste encore un sujet méconnu, à tort), il est dommage que la Team GA se permette de livrer de telles informations sans prendre davantage de précaution quant à leur interprétation. Car ce qui est comparé ici n'est pas comparable. Les pays présentés n'ont pas les mêmes qualités de connexions, privilégient parfois le filaire (comme en France) ou le mobile (dont les latences sont incroyablement plus coûteuses et les caches de navigateurs moins importants). Le parc informatique lui-même est différent, et donc les navigateurs utilisés !

Si on ajoute à ça qu'il est très difficile, même avec des solutions de mesures similaires (solutions dites "RUM" pour Real User Monitoring, qui consistent à mesurer la performance chez le client en JavaScript) de recouper les informations de Google Analytics (voir cette discussion sur le forum Performance Web français), on se rend compte que la Web Performance est un sujet complexe qui va bien au-delà de la simple installation de la balise statistique de Google.

Enfin, la mesure du Page Load Time n'est pas suffisante pour juger de la qualité d'un site en termes de Performance Web. Le temps passé côté serveur, le temps nécessaire à la construction de la page par le navigateur, le chargement des ressources statiques... sont autant d'indicateurs indispensables pour élaborer une comparaison entre deux pages. Et ils peuvent encore être complétés ou synthétisés par d'autres, comme en témoigne la création récente du Speed Index par Patrick Meenan de WebPageTest.org.

Ce qui est sûr en revanche, c'est que le Web reste lent et s'alourdit, comme en témoignent les statistiques sur 2 ans du projet HttpArchive. Tendance qui devrait normalement s'inverser avec l'expansion du web mobile et du m-commerce.

Sud Web 2012 dans un mois : et dire qu'il y en a qui n'ont pas encore pris leur place !

Nicolas Hoizey — 2012-04-25T09:48:22Z

Chez Clever Age, nous sommes toujours excités à l'approche de conférences qui défendent la qualité web telle que nous la défendons aussi !

Du coup, à un mois de la deuxième édition de Sud Web, dont la première nous avait laissé des étoiles dans les yeux, l'excitation monte aussi chez nous de retrouver nos confrères, d'échanger et de construire tous ensemble sur les bonnes pratiques de la qualité Web.

D'autant plus que cette année, en plus de la traditionnelle journée de conférences du vendredi (dont le programme est plus qu'alléchant), les participants se retrouveront le samedi pour un "élaboratoire" où tout le monde pourra proposer des sujets sur lesquels élaborer des solutions, construire ensemble les outils qui améliorent le web de demain. Nulle doute que les Clever Agiens présents prendront une part active dans cette initiative originale et diantrement constructive !

Cette année, nous serons présents au coeur des participants, mais aussi dans le staff comme l'année dernière par l'action bénévole d'un Clever Agien motivé. Mais aussi, fait original : notre Jérémie Patonnier (qui y était orateur l'année dernière) y sera présent pour présenter les couleurs du sponsor Mozilla, dans la communauté duquel il est très actif !

Bref, rejoignez-nous y gaiement les 25 et 26 mai à Toulouse, et comprenez et construisez le Web de demain avec nous et les autres participants de Sud Web 2012 !

Et bien sûr, si par le plus pur des hasards vous n'avez pas encore de ticket, c'est par là ; dépêchez-vous, ça ferme le 13 mai ! —> http://sudweb.fr/2012/inscription/

La "Facebook Fatigue", un virus contagieux ?

Frédéric Bon — 2012-04-18T09:05:51Z

Que ce soit par sondage empirique autour de soi ou en parcourant diverses études, le phénomène prend de l'ampleur. On lui a même donné un nom : la "Facebook Fatigue". Il faut avouer que le passage forcé à la page personnelle au format Journal (Timeline), dont l'intérêt n'est pas compris par grand monde (help needed ! pour ma part), n'est pas franchement une réussite. Personnellement, je suis irrité de voir ma vie résumée à mon activité Facebook. J'aime pas !

Côté étude plus factuelle, la dernière Wave de GlobalWebIndex montre une érosion du phénomène :

Le nombre d'inscrits sur Facebook ne progresse plus que dans les pays émergents. Le déclin est entamé aux US ;
La quasi-totalité des interactions par profil (envoyer un message, jouer à un jeu, faire des cadeaux, etc...) diminuent depuis un an.

Enfin, si on ajoute le montant délirant de la transaction du rachat d'Instagram : 1 milliard de dollars (à priori négocié en 3 jours par Mark Zuckerberg, sans aucun conseil externe) pour une boite créée il y a 18 mois et comptant 9 salariés ... On se dit qu'on ne vit tellement pas dans le même monde et que le divorce est peut-être la solution.

Le mouvement DevOps

Gwenael Perier — 2012-04-17T11:11:11Z

De manière générale DevOps est un mouvement ayant pour objectif l'alignement du système d'information sur les besoins de l'entreprise (en se concentrant plus essentiellement sur la partie développement / opérations).

"DevOps" est un terme issu de la contraction des mots anglais "development" (développement) et "operations" (exploitation). " [1].

Dans cet article je vais vous présenter ma vision de DevOps. Elle n'est sûrement pas complète mais elle permettra je l'espère de démystifier le terme et d'en comprendre le sens principal.

Définition du mouvement DevOps

En regroupant les différents termes de plusieurs définitions données sur le web, voici ce que l'on obtient :

DevOps est :

un mouvement.
 une culture.
 un processus agile sur l'ensemble de la chaîne (du développement à la mise en production).
 une nouvelle approche technique.
 une autre approche humaine.
 une réponse à de nouvelles problématiques comme le  déploiement massif, le  déploiement régulier.

Pour résumer on peut dire aussi que le mouvement est également pour 30% une affaire d'outils, de code et de processus métiers et pour le reste (70%) une affaire de culture et de communication.

Bon, ok. DevOps est un mouvement, une culture, un état d'esprit, voire même une religion pour certains, mais en pratique, qu'est ce que c'est ? Nous y reviendrons plus loin dans cet article. Pour comprendre DevOps, et découvrir ses méthodes, processus, et les différents outils utilisés, il faut tout d'abord s'intéresser à son origine. Pourquoi ce mouvement est-il apparu ?

Pourquoi DevOps ?

De nombreuses entreprises (essentiellement les plus grandes) divisent le développement (ceux qui pensent et écrivent le code) et l'administration système (ceux qui déploient et exploitent les applications) entre différents départements / services. Dans ce type d'organisation, les développeurs ne sont pas souvent préoccupés par l'impact de leur code sur la production mais plus par la livraison fréquente de nouvelles fonctionnalités. À l'inverse, le service des opérations de production est plutôt concentré sur la stabilisation des services et de l'architecture ainsi que sur la performance des instances actuelles.

La mise en production est pour beaucoup d'entreprises une étape lourde, compliquée à cause des différentes procédures établies. Les équipes en charge refusent souvent le changement rapide du code (nombreuses livraisons / déploiements). Mais plus il y a de nouvelles fonctionnalités présentes, plus le temps pour la mise en production peut devenir important, plus il y a de chance d'avoir des remontées de bugs bloquants, plus il faudra de tests post-production, etc .... Potentiellement cela implique du temps d'indisponibilité pour l'application, du stress pour les équipes et bien entendu de l'argent perdu.

A l'inverse des équipes de production, les développeurs développent leur code sans la contrainte d'un environnement dit 'de production' (plusieurs serveurs, gestion de flux réseaux complexes, configurations différentes, systèmes d'exploitation différents). La plupart du temps, un développeur installe son propre serveur web avec sa configuration habituelle, sa base de donnée habituelle sur son système d'exploitation préféré, etc... Que celui qui n'a jamais eu le problème du 'ça marche sur ma machine' (mais bien entendu pas sur le serveur de recette ou de production) me jette le premier pingouin :).

Même au sein des équipes de développement le problème peut être rencontré. Installation d'Oracle avec une équipe de développeurs sous Mac OSX, Ubuntu, et Windows. Résultat : même code, mais pas un des développeurs n'a réussi à faire fonctionner l'application complète de la même manière !!!

Le mouvement DevOps tend à essayer de fusionner ces deux mondes que sont l'exploitation et le développement. Chaque monde va apprendre de l'autre et surtout essayer de se comprendre :

En facilitant la communication entre les deux mondes (utilisation de méthodes agiles, intercommunication).
En industrialisant les processus de livraison (intégration continue, déploiement continu, etc ...).
En utilisant des outils (Puppet, Chef, Vagrant , fabric, etc ...) pour l'industrialisation de l'infrastructure.

Comment être DevOps ;)

Communication, processus et méthodes agiles

Les équipes de développement ont besoin de communiquer avec les équipes opérationnelles. Elles doivent pouvoir adapter rapidement leur environnement de développement et les changements d'architecture sur leur code. De la même manière, lorsqu'une nouvelle fonctionnalité demande un changement d'architecture ou l'installation d'un nouvel environnement et/ou serveur, les équipes opérationnelles se doivent d'être de bon conseil sur la configuration et l'installation. Elles auront souvent une vision plus juste que les développeurs.

Les équipes opérationnelles ont besoin de communiquer avec les équipes de développement qui ont des connaissances sur des outils, des processus qui peuvent aider à rendre les environnements plus facile à gérer, plus efficace et plus propre. Elles ont également besoin de comprendre le besoin applicatif et fonctionnel des développeurs pour permettre une meilleure optimisation des ressources, un meilleur monitoring et une meilleure remontée d'erreur.

Les méthodes agiles ne sont pas réservées uniquement aux équipes de développement mais peuvent aussi être appliquées sur toute la chaîne IT. Les méthodologies de développement Agile comme Kanban et Scrum peuvent révolutionner les pratiques opérationnelles de la même manière qu'elles ont changé la façon dont les développements s'opèrent.

Prenons l'exemple de l'analyse des problèmes en production qui nécessite une coopération entre les équipes d'exploitation et celles de développement comme la gestion des logs et des exceptions, des outils de concentration et d'analyse de logs. DevOps permet avec les méthodes agiles de gérer sous forme de points les problèmes rencontrés et le partage des informations, des solutions facilitent la résolution des dits problèmes.

L'organisation, bien qu'étant le point le plus complexe à aborder pour l'adoption d'une culture DevOps, n'est pas impossible à mettre en place, même pour de grandes entreprises : Amazon a adopté ce concept, et une devise en est alors ressortie : « You build it, you run it ». Le point essentiel pour la communication est de s'assurer que les objectifs soient communs aux différentes parties et se dirigent vers une amélioration de la disponibilité, de la performance et de l'évolutivité des applications.

Industrialisation des processus de livraison

Beaucoup trop d'organisations restent encore sur le cycle : Développement long -> Recette longue -> Livraison douloureuse -> Bugs -> Recettes correctives -> Redéploiement de patch (ouf..) soit par méconnaissance , soit par peur du changement ou par le coût de celui-ci. Ce type de projet avec un planning de livraison à plusieurs mois regroupe souvent un lots de fonctionnalités pour éviter une multitude de déploiement (souvent dûe à la frilosité de la mise en production). On se retrouve alors avec des allers retours dans tous les sens et des attentes dans chaque équipe, ce qui peut créer des groupes (eux / nous) et certaines frustrations (exemple : ça fait deux mois qu'on a fini de développer cette fonctionnalité mais elle n'est toujours pas testée ni livrée en production).

Prenons le postulat de base : ''une portion de code qui n'est pas livrée n'apporte aucune valeur ajoutée à l'entreprise ou à l'application''. Plus les déploiements sont fréquents, plus le processus est maitrisé. Il y a moins de code à livrer, donc moins de risque d'erreur, moins d'impact lors d'un rollback / retour-arrière. De plus, une application avec laquelle on peut rapidement livrer des nouvelles fonctionnalités ou des correctifs de bugs aura un meilleur retour des utilisateurs (plus de réactivité) et donc une meilleure image. C'est là qu'intervient la méthodologie du déploiement continu permettant le déploiement du code de façon rapide et efficace. Pour arriver à une automatisation complète ou quasi-complète de la chaîne de production, plusieurs étapes sont nécessaires :

« Continuous Integration » est le processus d'intégration (génération de code, compilation, exécution des tests unitaires, fonctionnels, ..) à chaque changement d'environnement (source code, os...)

C'est une très bonne pratique de développement qui consiste à utiliser le « développement piloté par les tests (Test driven Development, TDD) » ou à aller encore plus loin en utilisant le ''développement piloté par les comportements'' (Behavior Driven Development, BDD) pour permettre une couverture améliorée du code et du fonctionnement de l'application. Ces tests sont ensuite exécutés par le serveur d'intégration à chaque évolution de code ou changement de périmètre fonctionnel. Le contrôle et la gestion des résultats (tests, fiabilité, analyse du code) sont à la charge du serveur d'intégration.

« Continuous Delivery » est l'étape suivante et caractérise la possibilité de déployer ses applications à tout moment.

Cette étape est très importante et est dépendante des résultats de l'intégration, si toutes les contraintes sont au vert, le déploiement peut se faire de manière automatisée sur l'environnement cible (recette, pré-production, production).

« Continuous Deployment » est l'ensemble de ces processus et méthodologies permettant le déploiement en continu en production.

Malheureusement, la démarche de déploiement continu est loin d'être simple à mettre en œuvre, car dépendante de tous les acteurs du système d'information de l'entreprise.

Quelques outils DevOps

Les outils jouent un rôle majeur pour industrialiser les processus et la gestion des architectures dans le mouvement DevOps. Voici donc quelques outils (la liste est loin d'être exhaustive) qui vous permettront de vous familiariser avec tous les concepts abordés et qui à mon sens représentent bien le mouvement DevOps :

Capistrano : outil open source pour exécuter des scripts sur plusieurs serveurs, son utilisation principale est le déploiement d'applications web. Il automatise le processus de déploiement d'une nouvelle version d'une application sur un ou plusieurs serveurs web.
Liquibase est une librairie open source (Apache 2.0 Licensed) pour versionner et gérer les changements de schéma de base de données.
Jenkins est une application d'intégration continue qui monitore l'exécution de jobs répétés, comme les builds d'un logiciel ou des tâches automatiques.
VirtualBox est une solution permettant de monter rapidement des 'Virtuals Machine'.
Vagrant est un outil pour construire des VM opérables en VirtualBox via scripting.
Puppet/ chef permet la gestion de configurations systèmes dynamiques.

Conclusion

Définir le mouvement DevOps n'est pas chose facile. Par contre, définir ce que n'est pas DevOps l'est davantage.

Voici ce qu'il n'est pas :

un produit ;
une personne ou une équipe ;
une recette miracle ;
une méthodologie stricte, au sens ou il n'y pas de règle prédéfinie mais plus une philosophie de développement.

Maintenant, à vous de vous faire votre propre opinion sur ce mouvement et ce qu'il représente pour vous.

Pour de plus amples informations sur le mouvement DevOps :

[1] Citation du site http://devops.fr/

Le status Open Source de Magento remis en cause, le départ de son co-fondateur

Matthieu Severe — 2012-04-16T07:07:27Z

Depuis le rachat de Magento par Ebay l'an dernier la communauté se pose beaucoup de questions sur l'avenir de la plateforme e-commerce. Yoav Kutner, CTO et co-fondateur, crée la surprise en annonçant son départ de Magento. Les raisons de son départ n'ont pas été précisées jusqu'à un message de sa part sur Quora où il dénonce la politique d'Ebay sur l'Open Source : "As for now I can say that (very) short term I would not be worried about the ‘open' part of Magento, but as I have learned eBay and the folks at X.commerce don't really understand the meaning of open and have a hard time explaining and defining it to them selves and to others. As such, long term, it would be very interesting to see if Magento will continue to stay open in the manor the people behind Magento and I meant it to be."

Pour rappel le développement de Magento2 est en cours, et son code est disponible sur Github avec des mises à jour "par lot" de la part de l'équipe de développement.

C'est une nouvelle un peu inquiétante pour Magento, on espère que ça n'aura pas d'impact sur le produit et son ouverture !

Plus d'informations

PostGIS vient de sortir en version 2.0 !

Nicolas Ippolito — 2012-04-13T08:14:26Z

PostGIS vient de sortir en version 2.0 ! PostGIS est une "extension" pour la base de données PostgreSQL qui permet de gérer la dimension spatiale des données. Cette nouvelle version supporte notamment les données RASTER (le stockage des images représentant un territoire par exemple) et un modèle topologique (c'est un moteur qui permet de travailler sur la cohérence des données vectorielles saisies). Même si les solutions "NoSQL" sont sur le devant de la scène, PostgreSQL continue d'évoluer dans le bon sens et se place dans la cours des grands en concurrent de solution telle que Oracle par exemple.

Voir un cas d'utilisation de PostgreSQL dans un environnement haute performance

Voir le détail de l'annonce de la sortie de PostGIS relayée par Oslandia