People always ask me what we do, but after 20 years of taking up
IT challenges, I feel like asking what we DON'T do, as our network
of skills has diversified over time!
Development & web packages
This page is aimed mainly at project leaders who wish to learn more
about Agile development methods and benefit from our cross-disciplinary
skills to build internet applications on an à la carte package basis
rather than on a person-day basis for specific profiles.
The first stage of project management is communicating and identifying
the project requirements. It starts with the documentation of
requirements in Agile format.
Concretely, it is a technical-commercial profile whose responsibility is the
quality of your development and ensuring that it meets your expectations.
The next stage of the process requires the team of engineers to collaborate
openly and estimate each User Story in Story Points, which together compose the
Epics: this can easily take up a whole day because an estimate is registered
only if it has the unanimous agreement of the developers!
This documentation will help you to start an “Agile Development Sprint” with
YourLabs Business Service and to ask for quotes from other developers.
There are two ways to build a software architecture: one is to make it so
simple that there are no obvious flaws,
the other is to make it so complicated that there are no obvious flaws.
“Epics” and “User Stories”
A “User Story” is a statement defining a feature used by a user, e.g.:
“The User can authenticate themselves on the platform”.
An “Epic” is a set of User Stories that go together, for example, the
Epic “Authentication” involves the following User Stories:
the user can create an account
the user can authenticate themselves
the user can reset their password by e-mail if they have forgotten it
the administrator can manage users in the administration interface.
The requirements documentation in Agile format consists of Epics and User
A single “Story Point” is assigned to the simplest task and other
User Stories get a proportional number of Story Points in terms of complexity.
Several User Stories may be cumulated to make a Story Point if they are too
simple. In the “Authentication” Epic example above, the User Stories are each
valued at 1 Story Point because this is a classic approach for the developer
as authentication is a subject that has been seen and reviewed and there is
really nothing new to be invented here, as a general rule.
Would you like more technical details about our method?
Woul you like to learn the jargon of the professionals?
Then let’s go!
A “Deployment” is the act of putting code at the service of users and may
also require the updating of data or database structures, known as “migrations”.
“Continuous Delivery” is a practice that consists of automating deployments.
A developer has delivered code to you? If you’re satisfied with
the changes, all you have to do is click a button to deploy it on your
main “production” site.
“Test-Driven Development” and friends
A program that produces incorrect results twice as fast is infinitely slower.
When a bug that has been fixed reappears, it is called a “regression”. How do
we prevent this? Just fixing the bug now won’t prevent it from coming back in
We start by coding a second mini-program (a “test”) that “reproduces” the bug:
that is to say, it simulates the conditions that cause the bug to appear.
Now we can execute this second program and check that the bug occurs: this
means that it correctly reproduces the bug! At this point, we can start to
develop a “patch” to fix the original program.
Result: we end up with a patch for your program plus a program that allows us
to verify that the bug is still squashed, in the blink of an eye.
When we generalize this practice to all our code, it is called “Test-Driven
Development” and it is a practice popularized by “eXtreme Programming”.
All of our production code comes with its test code equivalent, which allows us
to determine whether or not we have broken anything every time we modify
the project’s code!
“Continuous Integration” is the practice of automating the execution of the test
software every time a developer wants to modify the project code.
If a modification breaks a test then the developer is blocked and cannot send
the modifications to production: it’s a lifeline, a safety net that you hang on
to to avoid capsizing when you want to update your code.
Docker or better, with a new CRUDLFA+ project on Django (which we have been
using since 2008) and a PostgreSQL database behind a Traefik https
Thanks to uWSGI, the project already has a cron, a spooler and a native memory
cache at its disposal to enable it to orchestrate triggered calculations to
satisy the requirements of the most creative project owners.
Debugging is twice as difficult as writing code, so if you write code as
cleverly as you can, you are, by definition, not clever enough to debug it.
A “BarCamp” is a meeting, an open non-conference, that takes the form of
participatory workshop events where the content is provided by the participants.
That is to say, we meet in an informal context and exchange our passions in
computing. We cultivate knowledge that multiplies when we share it in a
friendly and playful atmosphere.
Any programming language accepted
Any framework accepted
Any system & networks accepted
Micro-soldering, dump, exploit, hardware hacking
Authentic "White Hat" hackers with a passion
Open Source, Open Bar
Live music and open stage!
A YourLabs project, an association under the 1901 "Sports Club" law