Aurélien Pelletier

Des tweets et des plus n°18 – Methods to find out what’s going on

2012-05-01T19:58:01Z

Valve Handbook for new employees : hierarchy or codified divisions of labor [...] We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers

What Amazon’s ebook strategy means: By foolishly insisting on DRM, and then selling to Amazon on a wholesale basis, the publishers handed Amazon a monopoly on their customers—and thereby empowered a predatory monopsony.

Word, le fax du XXIe siècle: Je ne connais qu’une personne qui adore Word: mon fils de 4 ans. Il aime bien mettre le nom des lignes de métro dans la bonne couleur, ou écrire «automne» avec chaque lettre dans une teinte de feuille différente, ou sauter de la police Times New Roman à Comic Sans. Il adore aussi écrire sur ma vieille machine Smith-Corona. Les outils qui ont perdu de leur utilité font de remarquables joujoux.

Vive Soap: We have an employee whose last name is Null. He kills our employee lookup app when his last name is used as the search term.

Why is Estimating so Hard? It turns out that we don’t know the procedure. We haven’t got any clue to just how difficult the procedure is. We aren’t computers. We don’t follow procedures. And so comparing the complexity of the manual task, to the complexity of the procedure is invalid.

Pourquoi je ne veux plus entendre parler de SOAP

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

2012-04-13T12:17:46Z

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

2012-03-25T19:16:38Z

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

2012-03-06T20:52:56Z

Click here to view the embedded video.

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

2012-02-20T22:32:03Z

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°9 – Developeronomics

Des tweets et des plus n°13 – Polyglot Persistence

2012-02-10T12:22:34Z

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.

No related posts.

Des tweets et des plus n°12 – Mega Busted

2012-01-25T20:26:03Z

The GitHub Job Interview: You come up with a cool idea of an open-source project. This becomes your company’s development sandbox. Candidates are asked to then contribute to the project in some way

Languages, Verbosity, and Java: “A little redundancy in a language is a good thing. It’s important for readability.” Joshua Bloch

Amazon DynamoDB: A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries

Average Is Over: the reason we have such stubbornly high unemployment and sagging middle-class incomes today is largely because of the big drop in demand because of the Great Recession, but it is also because of the quantum advances in both globalization and the information technology revolution

Code Search tools

Des tweets et des plus n°11 – Geeks win

2012-01-08T17:34:43Z

Shame driven development: it was throwaway, one-use code so didn’t have any unit tests. I was embarrassed. [...] the only way to go fast, is to go well

Cleaning a kitchen is a good metaphor for Refactoring: Neither would a cook accept that I go into his kitchen and say: I want my steak half the price, can’t you not clean the kitchen today? In the software world we let people tell us, do it quick and dirty, you can clean up after, when we have the time.

How netflix get out of the way: Who has junior engineers, graduate hires and interns writing code? We don’t. We find that engineers who cost twice as much are far more than twice as productive, and need much less management overhead

CQRS: est un modèle d’architecture système qui sépare la partie lecture de données (query) de celle qui les modifie (command) de manière à produire un système extensible, distribuable, et fournir quelques avancées utiles qui rendent la maintenance du système moins pesante.

No related posts.

Another Git branching model

2012-01-02T21:39:32Z

We’ve switched to git at work a few month ago. Not an easy task but the rewards are worth the trouble. Our branching model was based on Git Flow because it’s well documented and gives you a structure to start with DVCS. Well, after a few iterations it wasn’t working as expected in our context. So we had to come up with our own workflow.

I guess Git Flow works well on a clean code base with good test coverage. But on legacy code, where one feature means two regressions, a release branch is like the vietnam war, you never know when you will get out of it. That was one of our main problem on subversion, we were creating release branch to go to production. And it would take forever to actually ship the code. Meanwhile all other development efforts remain stuck.

I though that cheap branching and merging in git would solve our issue. But cheap merging is not enough, you also need to be able to easily pick what to merge. And with Git Flow it’s not easy to remove a feature from a release branch once it’s there. Because a feature branch is started from develop it is bound by its parents commits to other features not yet in production. As a result, if you merge a feature without rebasing you always get more commits than wanted.

So here is the workflow we use to solve those issues:

The main branches

We have three branches with an infinite lifetime based on the classical trio (dev/test/prod):

master
staging
develop

Master is the same as in git flow:

We consider origin/master to be the main branch where the source code of HEAD always reflects aproduction-ready state.

Staging is a bit like develop in Git Flow :

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.

Develop is there for continuous integration, this is where we constanly merge all the changes to detect bugs and conflicts as soon as possible. The source code in the develop branch never reach a stable point where it is ready to be released. Instead only some feature branches reach a stable point. Those stable feature branches are merge into the staging branch. Since feature branches were created from master and not from develop we can pick individualy which one will be merge to staging. In fact this is the main point of this workflow: We can easily choose which features will go into production next.

To release the code to production we just merge staging into master.

Feature Branches

All work is done in feature branches which can be merge into

master for a quick fix in production
staging for bug fixes
develop constanly for continuous integration

Since we use github we usualy do a pull request to merge feature branches. We don’t always follow the rules and commit on master and staging happens, they are merge back to staging and develop. The only place where we don’t commit is develop (only merge commit)

Summary

Git Flow was not working for us, but by creating feature branches from master instead of develop we gained the ability to easily choose which features we release next. This gave us much more flexibility and got us out of “vietnam release branch”.

Now I should tell about all the best practices to make this workflow really work, but I’m lucky, someone already wrote them down.

And you, what is your branching model ?

Des tweets et des plus n°2 – Post It war

Des tweets et des plus n°10 – Tous bureaucrates

2011-12-30T22:15:43Z

Tous bureaucrates: Ainsi – et c’est la caractéristique principale d’une bureaucratie – la défense des territoires y devient un objectif plus important que l’intérêt général de l’entreprise, sa survie. Car ce rapport de force moyenâgeux entre services se superpose à la traditionnelle séparation entre penseurs et faiseurs, autre caractéristique des bureaucraties

Strangest language feature:

JavaScript truth table:
 
''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0             // true

Les métiers de l’informatique: En France, 77% des jeunes diplômés en informatique débuteraient ainsi leur entrée dans la vie professionnelle à partir d’une SSII, alors que seul 1 % de l’effectif des SSII quitterait l’entreprise pour cause de départ à la retraite (contre 10,4 % en moyenne)

LA PÉNURIE DE DÉVELOPPEURS: Altaïde rencontre aussi depuis deux ans les pires difficultés à trouver des développeurs sur les technos du web et mobile. Trouver des développeurs PHP, Java, .Net, IOS, Androïd ou RoR, pour ne citer que ces technos les plus demandées, c’est une débauche de moyens et d’énergies énorme.

No related posts.