Development methods

Agile development, presentation

It isn’t just about producing code – it’s also about how we produce code.

Main methods for achieving this are:

What is a sprint and why are we sprinting ? Our sprint’s duration is 3 weeks. Coordinating work within a community is a real challenge. Distributed and agile development is a method to achieve this aim. The team is auto-organised, the aim is to have a big picture about what the team is doing. We have to see in real time what scenario is progressing and what scenario is slowing down, and keep in mind what are the real aims in a sprint.

Pair programming

Find yourself a binomial as soon as possible. Pair programming is an important rule:

  • you keep in touch with what is being done by others
  • you learn a lot
  • some practices and point of views that seemed annoying to you become obvious
  • you learn to code with other human beings

There are a few rules to follow with pair programming practices:

  • only one guy holds the keyboard and the mouse
  • the other guy is only watching and speaking. He understands and follows what the other is doing, he can agree or disagree, he can be surprised in front of some unusual practice or coding style, he can also warn his binomial for syntax errors or forgotten semi columns.

Important

The one who doesn’t have the keyboard can’t catch the mouse, it would be a very intrusive attitude.

Extreme programming methodology

Agile language
An agile language shall help us to go quickly instead of forcing us to go slower.

For example, with an agile language you don’t have to declare variable’s type, because while coding your variable can be a string and an hour later it will be a list. And two hours later it will be a string again. And the compiler shall be OK with this. That’s why a dynamic language is better than a static one.

Run pylint often. Because once it’s coded, the code shall be checked with the type inference. A function that waits for a string must receive a string and not a list as a parameter and pylint will warn you if it is not the case.

Important

The language can be secure in some areas and more open in some others. For example, if you define a constant, it shall be a constant. If an object shall not have a dynamically defined attribute, it shall not have another attribute once instantiated. You will object us that there is no way to do so in python. You’re wrong. There a way to force it in python.

Major extreme programming practices

  • the samuraï rule : a function does what is shall do, otherwise it raises an exception
  • write a test if you think that the function shall behave like this contract or that contract
  • YAGNI : “You ain’t gonna need it”. Don’t try to implement a feature that is not needed at this precise moment of the development. Otherwise you will regret it later.

There are a lot of possibilities enhance security in a code. Type inference, programming by contract in python, You can use these kind of tools. pycontracts for example, or program with ABCMeta, but we think that it is against the rules of extreme programming. It is absolutely not necessary if you have a good test codebase and good linting tools.

Remember that when you code in extreme programming, at first your function returns a string, and one hour later it returns a list, then a string again. Is it really necessary then to make a contract ? If the code is in a stable version, why not. Otherwise : no. Coding by contracts for example is a loss of time in these condition. Remember that in extreme programming, if you don’t throw away 80% of the code it means that you are not doing extreme programming.

Agile development, in practice

Main tools for achieving this

Sprint driven usual practices

  • at the end of the day, the team member has to report:
    • the time spent on each task
    • the time left on each task

Important

At the end of the day, the team member shall let the percentage
of each task unmodified, because the percentage will be updated later on during the next stand up.

in the issue tracker, on the different tasks he worked on.

  • the standup occurs in the morning, during the standup
    • the percentage of the tasks are updated
    • the decision is taken to set the task to resolved (the task’s percentage is set to 100%)
    • the tasks’ statuses are updated (new, in progress, resolved, closed...)
  • the code review must occur before closing the task if the code isn’t considered as ok, the corresponding task is reopened then closed again.

Important rules

  1. The code belongs to everybody. It is not the property of the guy who committed it. If the code has to be refactored of debugged, some other people can handle it. Not only the first guy.
  2. Release early. The code is highly operational. It can be put in production early. But it doesn’t mean that the dev team has no right to make mistakes. Furthermore, the code can be thrown away, if about 80% of the codebase may be put in the trash.
  3. Be at ease with all of this stressing recommendations. If you are not at ease, it is not your problem. It’s the team’s problem. If not, how is it possible to be at ease in such a context ? Just follow the extreme programming rules and don’t panic.

Devops architecture

  • open nebula virtual machines
  • docker

Build a eolebase architecture

First, instanciate an eolebase virtual machine, then update it

Maj-Auto -D

Then install the ewt tools:

apt-eole install git vim git-flow \
         nodejs nodejs-legacy npm eole-saltstack make \
         tiramisu-web ewt-portal ewt-actions

Reconfigure your sever:

reconfigure

Update and install the different developer tools (node, bower, polymer):

npm install -g update
npm install -g polymer-cli vulcanize crisper

For convenience, type git config --global core.pager 'less -R'

Retrieve a working copy repository of your remote repository (with ssh or http):

git clone ssh://git@dev-eole.ac-dijon.fr/ewt-portal.git
cd ewt-portal
make install

work like explained in the developer’s working day Work on your task