OpenShift is a private PaaS solution (Platform-as-a-Service) to build, deploy and run applications into containers. Open source, it is available under Apache 2.0 licence and released into 2 versions: Origin (community) and Enterprise.
In addition to his talk at USI, Jurgen Appelo kindly accepted to answer our questions.
OCTO: What would you highlight as new / disruptive with Management 3.0?
Jurgen Appelo: What is new is to manage the system, not the people. For example for our merit money bonus system, I don’t decide who gets how much money, I don’t see that as my job. I think the crowd knows better who has what kind of performance, so I let them make the decision together. What I do is to make sure that this process works as well as possible. That is my responsibility, introducing such an idea. This is the same for many practices traditionally used by managers with higher positions than their employees.
I don’t see it as my responsibility to use a carrot and a stick in order to get someone to perform better. My job is to set up things in such a way that people love developing their own performance.
Over the last few years, the REST approach has become the new standard to build API on top of HTTP. In the same period, server-side landscape is facing huge changes along with the Node.js breakthrough
If it’s easy to build a small HTTP server with few lines of code of node, why not build a real API?
We are very proud to announce that our best-seller book “Les Géants du Web” is currently being translated into English.
The PDF version should be available for free during July, the print version should be available at the end of August on Amazon platforms.
As for the French version, we’ll publish chapters on this blog every week while you wait for the definitive version.
For years now, any process running in parallel of others has required a dedicated thread. We believe this paradigm to be outdated.
In the previous article, we introduced a general overview of the code review practice as well as two specific formats we use in our projects.
Nevertheless, successfully introducing a new practice is not an easy task. It’s a bit like setting sail for the first time: once in the water, the first meters are always chaotic. There are lots of waves, we wonder whether it was really a great idea. Wouldn’t it be wiser to go back ashore? However, after a bit of dedication, we finally get to the quieter open sea: we just had to hold onto it.
During our code reviews, we came across several pitfalls that were detrimental and that could jeopardize code reviewing in the team.
Let’s explore, through real-life use cases*, why the first code reviews will certainly be difficult and what are the essential fundamentals to carry out successful code reviews.
Having an efficient flow monitoring is critical: integrating all data flows, it offers an overall view of the entire Information System.
This article aims to help you compare your current system with generally observed good practices and provides you with suggestions to improve it.
The first steps towards industrialized developments usually start with continuous integration.
Although it is often seen as an achievement in itself, it’s actually only a piece of an efficient and managed solution.
We mainly use two code review formats in our projects: collective review which is rather formal and peer review, which is lighter. Both have advantages and drawbacks: Let’s look into these formats together and see how to implement them within a team.
But first things first: what is a code review and what benefits can we expect?
In most areas involving writing, we cannot imagine that what is written is issued without proofreading. An article will always be proofread before publication (e.g. the one you are currently reading), either to check the substance – is the subject of the article well treated? – or the form – spelling, grammar, structure and text readability. Similarly, the code review practice consists in having one’s code read again in order to track as many defects as possible, be it on the content – does this code work, and correctly implement the required feature? – or the style – clarity, readability, standards compliance, etc.
What about you: how many lines of code have you ever deployed in production without proofreading?