Today I attended XConf. Here is a quick recap of the talks I visited.
Keynote by @jezhumble
This has been summarized in other posts far better than I can do here, but I will highlight the things that seemed important to me.
Key questions to measuring your continuous delivery maturity involved:
- Deployment frequency
- Lead time for deployments
- Mean time to recover
- Change fail rate
Mentioned Ronny Kohavi:
Evaluating well-designed and executed experiments
that were designed to improve a key metric,
only about one-third were successful at improving the key metric!
So consider cost, opportunity cost and maintenance cost of new features.
Mentioned the term 自働化, which roughly translates to Autonomation
as
coined by Toyota.
Quoted W. Edwards Deming:
Eliminate the dependence on inspection to achieve quality. Eliminate
the need for inspection on a mass basis by building quality into the product in
the first place.
Do not check in broken code.
Go buy a rubber chicken!
Do fire drills for disaster recovery. Does your backup work? Test your process.
How does your organization work? Is novelty crushed
? Messengers being shot
?
Do not bother testing unvalidated assumptions. Creates churn. So do not start implementing acceptance tests before figuring out if it is the right thing to build.
Patterns for offline web applications by @birgitta410 and @robmiles0
Presented two showcases. The first being an stock ordering application for a super market chain. The latter an app for traveling quality/product testers.
Just push commands into a message queue.
For conflict resolution try to be as simple as possible
- Use locks
- Time limit, tell user to please sync with server now
- Server wins
Leverage HTML5 technology:
- local storage
- appcache
- IndexedDB
- File Access API
Challenge requirements. What has to work offline? Implement offline first and early. Explore the possibilities.
Tales from a radically polyglot team by @itchyankles
6wunderkinder use a gazillion of programming languages.
The run a Micro Service architecture. Key guide lines are:
- Trivial, less than 1000LOC
- Your responsibility
The use a English/Deutsch service pattern.
+--------------+
| |
| auth proxy | +---------------------+
| | | |
+------+-------+ | RAbbitMQ |
| | |
+------v-------+ | |
| | +---------------------+
| request router
| |
+-+------------+
+--------------------+--+-------------+--------------------+
| | | |
+---v------+ +-----v-----+ +---v------+ +-----v--------+
| | | | | | | |
| lists | | tasks + | users | | membership |
+-+------+-+ +----------+| +----------+ +--------------+
| +-----+ |+------------------+
+-----v-----+ +---v-----------+ +v------------++-----v-----------+ +----------+
|Listenleser| |Listenschreiber| |Aufgabenleser||Aufgabenschreiber| | |
| | | | | || | | |
+-----------+ +---------------+ +-------------++-----------------+ +----------+
The english services are reimplemented Rails controllers. The german services are what used to be models. Everything interfaces using HTTP and JSON.
Why use different languages?
- We have to.
- We want to develop quickly.
- We want the system to run faster.
- We want to be more expressive.
- We want to learn.
Deployment woes solved by bash scripts.
Context switching is neglectable.
Jack of all trades. Master of one (or more).
Benefits on a industry level:
- Challenge value rigidity.
- Fallacy of general purpose
- Spread of ideas
- Avoid group think
On an organizational level:
- Hire the best people
- Right tool for the job
- Happier employees.
On personal level:
- It is your future
- Enjoy the benefits of polyglotism
- Be happy
Great talk!
This is covered extensively here.
- Buy when non core
- Try to reuse
Data level integration, pull changes. Shared nothing between verticals.