artodeto's blog about coding, politics and the world

We detected a bug that is known since 2003.

The value of an auto increment column is set back to zero when you are having an empty table and restarting the MySQL DBMS. We run into this issue by using the auto increment value as a history id into a second table.

How can you work around this issue?

The easiest way is to order by id descending on the second table or to setup a "start up" shell script that calculates and sets the auto increment value.

The following lines are loud thoughts so far. I will give it a try and implement a fitting module for that. But so far, it is really just an idea.

You started your zend framework 2 translation by using the official translation guide for zend framework 2 and it was running fine with some words.
But then, you started working agile, using git flow and doing this by using multiple branches. It turned out that you will get a lot of merge conflicts (also on git) with your translation files if something had changed on your develop branch and on your feature branch. This results in high maintenance costs.

So what to do?
Here is my basic idea. Decouple the translation file from your code.

• First of all, you want to shift from file based to database based translation.
• After that, you reduce the usage of the database and add caching

Shift from file based to database based translation

• Create a database with the name like "translation"
• Inside this database, create a table called "keys" with the columns "id", "key_name" (or "name") and "created_at"
• Inside this database, create as many "language" tables as you want
• Each "language" table has the following columns "id", "key_id", "key_value" (or "value") and "created_at"
• After that, create a basic import that inserts all names in the table "keys" and all values in the fitting "language" table
• Next, you have to create an "translation adminstration" frontend to maintain the existing "translation keys" with its fitting "translation values" according to the right language.
• Finally, you have to overwrite the existing view helper with your own, database driven, one

Reduce the usage of the database and add caching

• setup redis in zf 2
• Setup the zf 2 redis cache adapter
• Inject the caching adapter in your translation view helper

By Michael Hüttermann.
Thanks for the book again, i will try to write a review about it this year :-).

What Is This Talk About

• what is a DevOp
• the goal
• the problem
• the solution
• recipes and pitfalls
• examples - not in this documentation
• demo (MySQL, Flyway, Jenkins, Git, Maven, Gradle, Sonar, Vagrant) - not in this documentation

How Is Part Of The Team

• everybody how is envolved in the process of creating the software

What Is Not A DevOp

• is already a buzz word
• it is not a new project role
• its also not a new tool-suite
• devOps is not a new department / business unit
*

What Is A DevOp

• development and operations
• better communication
• improved collaboration

The Goal

• shared incentives
• holistic metrics
• common processes (like kanban)
• shared tools (same deployment tools for development and production for example)
• high automation degree
• improve and accelerate delivery - downsize the batch size
  • small releases
  • downsize the changesize to keep up the frequency
  • improve the cycle time (from bug finding/feature request to release the patch/feature)

The Problem

• a lot of completed functions/features facing a slow release cycle
  • release small, release often
• problem between development (want feature online) against operation (want stable and "relaiable" software)

The Solution

• value stream map
• continuous integration
• continuous delivery (each commit moves system into stable and releaseable version)
• continuous deployment
• development and operation is merged together to create a infinie loop of release and feedback (both directions)
• share knowledge and experience

Define clearly what is a release (new feature, bugfix, and so one). Again DevOps is not a new layer between the two areas. Responsibilites is still clear to reproduce scenarios (automate as much). It is about people, not about tools. Implement culture of communication. Try to find conceptual deficits (also software design problems) as early as possible. Add a version number to your database layout (most likly same release number than code) - flyway, liquibase, self-made

The Area Matrix

• area 1 - extend development to operations
  • practice
    • use tools like puppet/chef/cfengine to provision environments from versioned code
  • goal
    • fast feedback through automations
    • reuse of code and tools
    • reliability of delivery process and provisioning
• area 2 - extend operations to development
  • practice
    • provide monitoring and log files to development (or automated database snapshots to reproduce bug on development machine)
  • goal
    • share information about state in production
    • enable development to improve
    • enable development to trace production incidents
• area 3 - embed development into operations (end user experience is goal to reach)
  • practice
    • set stability and capacity as development goals
  • goal
    • align goals, share incentives
• area 4 - embed operations into development
  • practice
    • operations gives feedback about the design of the application that is under development, early and often
  • goal
    • avoid not releaseable design

Recipes And Pitfalls

• automate to ensure repeatability and foster collaboration (build once on a build server and release)
• consider kanban (scrum is more for development but bad for organisation)
• consider thorough change and config management - content management
• track to ensure traceability (which build/release contains which tickets/bugs - artifactory)
• monitor to support accountability (nagios and everything)
• dashboard what you are doing (talk to each other what you are doing or what you have done)
• use version control to ensure reproducibility (no manual tweaking after checkout)
• consider pipelines/process from "put in feature/bugfix to release"
• create (executable) documentation to, well, document (try to define goals and what it needs to reach it)
• align goals and incentives of devs and ops (small cycle time)
• ask and help, open culture of communication
• respect your colleagues (stability against features, both leads to great user experience)