Skip to content

Internet im Jahre Null - Auf Bugaboo funktioniert das Kontaktformular nur zwischen 9:00 Uhr und 17:00 Uhr und nur, wenn man dem Cookie-Tracking zustimmt?

Servicewüste Deutschland, so wird es gerne bezeichnet. Das andere Länder dem in nichts nachstehen zeigte mir heute die Firma "Bugaboo" mit dem Hauptsitz in den Niederlanden.
Deren Kontaktformular ist nur zwischen "9:00 Uhr und 17:00 Uhr" und nur mit aktiviertem Cookie-Tracking nutzbar. Ist eine der beiden Voraussetzungen nicht erfüllt, erhält man eine "Sorry, the system is under maintenance. Please again try later." Fehlermeldung.
Quelle.

Als Kunde und Nutzer ist dieses Vorgehen unverständlich. Am meisten Entäuscht bin ich von der Fehlermeldung: "Sorry, the system is under maintenance. [...]". Sie ist so unpassend, dass es lange gedauert hat, bis man die anderen beiden Voraussetzungen erkannt hat.
Ob man im Internet "Geschäftszeiten" für ein Kontaktformular einführen sollte, ist in meinen Augen ein zweifelhafter Ansatz. Man kann und sollte gern erwähnen, dass die Menschen hinter dem Kontaktformular solche Geschäftszeiten haben. Aber dass ein Ticket nur in diesen Zeiten erstellt werden kann, empfinde ich im Zeitalter der nie schlafenden Maschinen also nicht zeitgemäß.
Zu guter Letzte muss man besser Kommunizieren, dass man dieses Kontaktformular nur nutzen kann, wenn man dem Cookie-Tracking zustimmt. Auch hier hinterfrage ich die Gründe der Geschäftsleitung deutlich. Ein Kontaktformular sollte eine schnelle und unkomplizierte Möglichkeit geben, dass der Kunde mit dem Hersteller in Kontakt treten kann. Ist man von dem Produkt noch so sehr begeistert, hat man dank dieser Praktiken nun ein sehr schlechtes Gefühl gegenüber der Firma und hinterfragt deren Praktiken.

PHP UserGroup Hamburg - 2016-02-09 - Putting down the leadtime

Following some notes about my the last php usergroup meetup.

By Judith Andresen

  • what is the leadtime?
    • time between adding the ticket and releasing it as a feature
  • what is a cycletime?
    • time between someone has an idea and releaseing it as a feature
  • we are currently in a time of digital transformation to the "first mover"
    • first idea try/test is the one who owns the bigges marked share
    • try to not be perfect
    • remove bottlenecks
    • try to scale vertical (microservice, duplicated data)
      • one team and service per business value/topic
        • search (including frontend, backend, customer data etc.)
        • product page
      • "community of practice" is a team (per vertical cut/team) that try
        • to keep the big architecture picture in mind
        • to share knowledge, approach and libraries
    • try to add a decision-maker into the team (extend the team in the value chain)
    • try to bring people together, also on an emotional level (increase the "we" feeling)
    • you can argue always with a decreased leadtime / small time to market
  • typical "facts" against
    • we have never done that this way
    • my discipline is better, information silos, no talk between departments (typically between 20 and 80 peoples)
    • there is no "we"
  • how?
    • talk to each other
    • major goal: deliver fast
    • create room for improvment or options
      • time
      • people
      • space/room

PHP UserGroup Hamburg - 2016-02-09 - Dockerizing PHP Applications

Following some notes about my the last php usergroup meetup.

By Sebastian Heuer

  • docker is not one tool but a whole ecosystem
    • machine (provisioning)
    • swarm (clustering and container scheduling)
    • compose (multi container application)
    • registry (image distribution)
    • engine (the container)
    • ktematic (gui)
  • pretty small compared to virtual box/full virtual machines
  • updating means, building a new container
  • theoretically, you can use all the images from the hub
    • always ask yourself if you want to use them in production
      • are they maintained
      • how secure are they
  • docker compose
    • builds and pulls images
    • runs containers
    • enables networking between containers
    • aggregates STDOUT and STDERR output

example Dockerfile

FROM php:7.0.2-fpm

RUN docker-php-ext-install pdo pdo_mysql

COPY php/php.ini /usr/local/etc/php/
# copy the content of the source code into the image
# you can ship this code version now
COPY . /srv/meetup-service

# the date in the container is not persistent
# if ypu change something in it, it will bill lost afterwards

CMD ["php-fpm"]

example docker-compose.yml

webserver:
  build: ./nginx    #path to the docker file and configuration etc
  links:
    - application
  ports:
    - "80:80"   #from port 80 to port 80
  volumes_from:
    - application
application:
  build: ./meetup-service   #your project
  links:
    - database
  ports:
    - "9000:9000"
  volumes:
    - ./meetup-service:/srv/meetup-service  #mounting local source code into the container
  environment:
    - MYSQL_HOST=database
    - MYSQL_DATABASE=application
    - MYSQL_USER=root
    - MYSQL_PASSWORD=parola
database:
  image: mysql:5.7  #no build path, instead an image is used
  volumes:
    - /var/lib/mysql
  ports:
    - "3306:3306"
  environment:
    - MYSQL_ROOT_PASSWORD=docker
    - MYSQL_DATABASE=app