Author Archives: Aurélien Pelletier

Des tweets et des plus n°17 – Dark Ages of Developer

Avez-vous la culture agile ? Agile Timeline: 1976: publication of Software Reliability by Glenford Myers, which states as an “axiom” that “a developer should never test their own code” (Dark Ages of Developer Testing)

CAMARADES AGILISTES, “INDIGNEZ-VOUS !”: Quoi qu’en disent les SSII, l’agilité et le mode forfait sont immiscibles comme l’eau et l’huile !

PHP: a fractal of bad design: programming is a hilariously young discipline, and none of us have the slightest clue what we’re doing.

What Powers Instagram: 

  • Keep it very simple
  • Don’t re-invent the wheel
  • Go with proven and solid technologies when you can

Des tweets et des plus n°16 – Big data

BIG DATA : Hors Hadoop, point de salut: la déferlante Hadoop a étouffé toute velléité de concurrence propriétaire, devenant hégémonique en à peine 4 ans d’existence […] Hadoop a permis de déverrouiller le marché du Big Data dès sa genèse et le rendre accessible à tous, des grands groupes jusqu’aux TPE. Un constat qui aurait été impossible avec des outils purement propriétaires

Big Data & Open Source: une convergence inévitable?: ce marché à la fois stratégique et à très fort potentiel de croissance.

Why “Big Data” needs to be Functional : Dean examines how OOP and Java thinking is impacting the effectiveness of Hadoop […] Hadoop is enterprise java bean of our time (démarre réellement @ 12min)

Why Large Enterprises and EDW Owners Suddenly Care About Big Data:  The Cost of 1 Gigabyte in 1980 was $210,000 – Today it’s 15 cents.


Des tweets et des plus n°15 – We code hard


Four Principles of Low-Risk Software Releases: there are two fundamental approaches to designing a system. You can optimize for mean time between failures (MTBF), or for mean time to restore service (MTRS). For example, a BMW is optimized for MTBF, whereas a Jeep is optimized for MTRS

How Not To Sell Software in 2012: Don’t make it hard for me to try your software. If I can’t play with a trial version or sandbox immediately, I’m moving on.

Le pair programming mort-né ?: Du point de vue du fonctionnel et de l’infrastructure de l’application, la programmation en paire favorise – et impose naturellement même – le partage de la connaissance. L’appropriation collective du code (Code Collective Ownership) est ainsi accrue et la réactivité face aux bugs de production est meilleure.

ROCA: is an attempt to define a set of recommendations – independent of any particular framework, programming language, or tooling – that embodies the principles of what we consider to be good web application architecture

Des tweets et des plus n°14 – Agile subway map

A Web Developers’ View of Play Framework 2.0: With Play, the Back button just works […]  Play doesn’t fight HTTP or the browser […]  As a Java EE developer, PHP and Rails developers have been laughing at us for years

La pratique “Définition de prêt pour une story”: Une story non prête n’est pas acceptée dans un sprint qui commence

On Naming:  The challenge is that the coder is holding two conversations at once, one with the compiler/interpreter and one with the future maintainer

It’s About The Hashbangs: Directly addressable content is what makes web apps better than desktop apps. It’s certainly not the UIs.


Des tweets et des plus n°13 – Polyglot Persistence

Polyglot Persistence: using multiple data storage technologies, chosen based upon the way data is being used by individual applications. Why store binary images in relational database, when there are better  storage systems

Less Process, More Discipline :The key to agile methods is this: You may have less process, but you must have more discipline.

Service Oriented Agony: Unfortunately this is a huge violation of the Single Responsibility Principle — or its big brother the Common Closure Principle. These principles tell us to group together things that change together, and keep apart things that change for different reasons.

How to Create Maintainable Acceptance Tests: Prefer to test your application via the service layer or at worst the servlet layer; only test on the UI level if you really have to and only as little as possible for UI is much more brittle (and also difficult to test)
The more you want to test the more you have to pay for it in the terms of maintenance effort. Usually you decide so that you cover the part(s) of the application where the most risk is – the best thing is to do cost-benefit evaluation.