Here I want to publish a simple yet functional setup for a dockerized app with Laravel backend and Vue.JS frontend.

What did I want?

• Simple setup for development with docker-compose
• With Laravel acting as pure backend
• XDebug
• Vue to take over all the frontend needs
• Hot reload for the Vue app
• No SSL in local development environment

What did I come up with?

1. Nginx acting as web trafic router, proxying to frontend or backend, depending on request URI
2. Backend service: Laravel running artisan serve
3. Frontend service: Vue-cli running npm run serve

Directory/repository structure

Legend: d: directory, f: file

d: backend -> git submodule, points to laravel API repo
d: frontend -> git submodule, points to Vue app repo
d: etc
  d: nginx
    d: conf.d
      f: default.conf.nginx
  d: php
    f: .gitignore
d: dockerize
  d: backend
    f: Dockerfile
f: docker-compose.yml
f: Makefile

As you can see, this project itself mainly serves as an infrastructure project which connects our services and glues them all together. Developer may clone a single repo and work in it, if that’s sufficient. Normally, though, everyone would want to clone this infra repo and start docker-compose stack to have all the project services running locally.

Nginx router

docker-compose part:

www:
  image: nginx:alpine
  volumes:
    - ./etc/nginx/conf.d/default.conf.nginx:/etc/nginx/conf.d/default.conf
  ports:
    - 80:80
  depends_on:
    - backend
    - frontend

…and the configuration, of course.

server {
    listen 80;
    server_name frontend;

    error_log  /var/log/nginx/error.log debug;

    location / {
        proxy_pass http://frontend:8080;
    }

    location /sockjs-node {
        proxy_pass http://frontend:8080;
        proxy_set_header Host $host;
        # below lines make ws://localhost/sockjs-node/... URLs work, enabling hot-reload
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }

    location /api/ {
        # on the backend side, the request URI will _NOT_ contain the /api prefix,
        # which is what we want for a pure-api project
        proxy_pass http://backend:8080/;
        proxy_set_header Host localhost;
    }
}

Backend

I added a Dockerfile for the backend, because official PHP images don’t include XDebug. Also, later on, I wanted to add redis extension:

FROM php:fpm-alpine

RUN apk add --no-cache $PHPIZE_DEPS oniguruma-dev libzip-dev curl-dev \
    && docker-php-ext-install pdo_mysql mbstring zip curl \
    && pecl install xdebug redis \
    && docker-php-ext-enable xdebug redis

RUN mkdir /app
VOLUME /app
WORKDIR /app

EXPOSE 8080
CMD php artisan serve --host=0.0.0.0 --port=8080

And of course, we build this image using docker-compose, that is, we automate and simultaneously document this process with a declarative approach:

backend:
  build:
    context: dockerize/backend
  # this way container interacts with host on behalf of current user.
  # !!! NOTE: $UID is a _shell_ variable, not an environment variable!
  # To make it available as a shell var, make sure you have this in your ~/.bashrc (./.zshrc etc):
  # export UID="$UID"
  user: ${UID}:${UID}
  
  volumes:
    - ./backend:/app
    # custom adjustments to php.ini
    # i. e. "xdebug.remote_host" to debug the dockerized app
    - ./etc/php:/usr/local/etc/php/local.conf.d/
  environment:
    # add our custom config files for the php to scan
    PHP_INI_SCAN_DIR: "/usr/local/etc/php/conf.d/:/usr/local/etc/php/local.conf.d/"
  command: "php artisan serve --host=0.0.0.0 --port=8080"

The laravel app itself is beyond the scope of this post, I will simply assume it’s a standard app built with composer create-project laravel/laravel or alike.

Take a note of the comment above the user: ${UID} directive

Frontend

Again, the Vue app itself is out of scope. I created mine with @vue/cli, using the vue-cli-service.

Docker-compose:

frontend:
  image: node:current-alpine
  user: ${UID}:${UID}
  working_dir: /home/node/app
  volumes:
  - ./frontend:/home/node/app
  environment:
    NODE_ENV: development
  command: "npm run serve"

Структура сервисов была такая:

Сайт: nginx (fastcgi_pass fpm:9000); fpm

API: api-nginx (fastcgi_pass api-fpm:9000); api-fpm

А фишка была в том, что я по незнанке сделал обоим сервисам одинаковые labels:

Service fpm, service api-fpm
...

labels:
  app: fpm
  tier: backend

И в спеке деплоймента тоже указал их же:

Deployment fpm, deployment api-fpm
...

selector:
  matchLabels:
    app: fpm
    tier: backend

Я, если честно, не очень понимал, зачем нужны эти лейблы и селекторы и занимался копипастой. В результате в облачной консоли, если зайти на любой их сервисов, там можно было увидеть оба деплоймента для каждого сервиса. Заходишь в fpm — видишь деплойменты fpm, api-fpm. И то же самое, если зайти в сервис api-fpm. Как результат, получалось, что два разных сервиса “обслуживались” двумя разными контейнерами, и выбор производился фактически случайно.

Я изменил лейблы, оставив для простоты один:

Сайт:

labels:
  app: fpm

...(deployment)...
selector:
  matchLabels:
    app: fpm

API:

labels:
  app: api-fpm

...(deployment)...
selector:
  matchLabels:
    app: api-fpm

Теперь все стало ровно, у каждого сервиса осталось по одному деплойменту, запросы к сервису “сайт” стали выдавать HTML, к сервису “API” стали выдавать JSON.

FOR THE IMPATIENT: the manual page gives you a config with which SQLProxy listens only to connections from localhost (127.0.0.1). You have to change TCP config for the proxy to listen to connections from outside:

command: ["/cloud_sql_proxy",
            "-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:3306",
            "-credential_file=/secrets/cloudsql/credentials.json"]

Now, in a lil bit more detail ;-)

Cloud SQL in Google Cloud Platform is a nice utility — a managed database, with good performance, automatic backups, fully production-ready.

On this page of the manual you can find out how to connect to Cloud SQL from Kubernetes engine. Of all options, Cloud SQL Proxy is said to be the most secure & robust. The manual describes the so-called “sidecar” approach, that is, they start a SQLProxy container in the same deployment as the application, then the app can connect as “mysql:host=127.0.0.1;…”

What if you want to connect to the same DB instance from several apps/services? Yes, it doesn’t look right from the first glance. However, CloudSQL is somewhat expensive, and smaller projects would benefit from using one CloudSQL instance (maybe with multiple databases) for all application services. Also, you may want to start Jobs that connect to the same DB. Having a new SQLProxy container next to every app service/job results in both running multiple instances of sql-proxy and duplicating the sql-proxy deployment configuration.

That is, you might want to have SQLProxy started as a standalone service, not as a “sidecar” container. However, if you simply create another service+deployment using the very same config from the manual, you won’t be able to connect to SQLProxy! It happens because of this line in deployment config:

command: ["/cloud_sql_proxy",
            "-instances=<INSTANCE_CONNECTION_NAME>=tcp:3306",
            "-credential_file=/secrets/cloudsql/credentials.json"]

With this, proxy will only listen to connections from 127.0.0.1, and you may check it with kubectl logs <sqlproxy pod name>

Solution is simple:

command: ["/cloud_sql_proxy",
            "-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:3306",
            "-credential_file=/secrets/cloudsql/credentials.json"]

Notice the tcp configuration change to 0.0.0.0:3306. Now proxy listens to connections from everywhere (but don’t worry, unless you specifically want it and take appropriate steps, you won’t be able to connect from outside of the cluster).

Hope that can save a bit of research to fellow readers!

Русский вариант

ДЛЯ НЕТЕРПЕЛИВЫХ: мануал приводит конфиг, с которым SQLProxy слушает только соединения с localhost (127.0.0.1). Надо изменить конфиг TCP, чтобы заставить его слушать соединения извне:

command: ["/cloud_sql_proxy",
            "-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:3306",
            "-credential_file=/secrets/cloudsql/credentials.json"]

Ну и немного деталей ;-)

Cloud SQL отличная штука — управляемая БД, с хорошей производительностью, автоматическими бэкапами, готова для продакшн.

На этой странице мануала вы узнаете, как подключиться к Cloud SQL из Kubernetes engine. Из всех вариантов самый безопасный и вообще лучший — это Cloud SQL Proxy. Там описан так называемый подход коляска мотоцикла”, в котором контейнер с SQLProxy запускается в том же деплойменте, что и приложение, и тогда из приложения можно коннектиться примерно так: “mysql:host=127.0.0.1;…”

Что если нужно подключаться к одному инстансу Cloud SQL из разных сервисов приложения? На первый взгляд кажется, что это как-то неправильно. Однако, CloudSQL довольно дороная штука, и небольшие проекты могут выиграть от того, чтобы использовать один инстанс CloudSQL (возможно, с несколькими БД) для всех сервисов приложения. К тому же, может возникнуть законное желание запускать Задачи (Jobs), которые подключаются к той же БД. Если запускать контейнер с SQLProxy рядом с каждым сервисом/задачейприложения приводит к дублированию как инстансов sql-proxy, так и конфигов, необходимых для его запуска.

В общем, может возникнуть желание запускать SQLProxy как отдельный сервис. Однако, если тупо создать еще один Service+Deployment и использовать тот же конфиг из мануала, подключиться к SQLProxy не выйдет. Вот из-за этой строчки:

command: ["/cloud_sql_proxy",
            "-instances=<INSTANCE_CONNECTION_NAME>=tcp:3306",
            "-credential_file=/secrets/cloudsql/credentials.json"]

Прокси слушает тольео соединения с 127.0.0.1, это видно, если посмотреть логи: kubectl logs <sqlproxy pod name>

Решение:

command: ["/cloud_sql_proxy",
            "-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:3306",
            "-credential_file=/secrets/cloudsql/credentials.json"]

Мы изменили конфиг TCP на 0.0.0.0:3306. Теперь прокси слушает коннекты отовсюду (но не беспокойтесь, законнектиться из-за пределов вашего кластера не получится, если только вы специально не откроете такую возможность).

Надеюсь, кому-то это сэкономит час-другой!

What I did was that in development I created a fastcgi.conf file for the Nginx container, where I simply set remote addr to 192.168.1.67 (my computer’s IP in internal network):

...
fastcgi_param  REMOTE_ADDR        192.168.1.67;
...

This solution only solves the particular problem of XDebug. It is neither super-elegant nor scalable. But it worked for me and made life easier. Hope it will help you as well.

English version: this videos were sent to us yesterday, filmed from a balcony in Moscow. A guy drove away from the road to the houses, because he wanted to pee. He did not close the door and did not use the hand brake. The car started moving backwards and hit an obstacle. As a result, the door was broken and the guy was in a pure panic. And I wrote a small poem based on these event (Russian only, sorry ;-) )

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Гаврила ехал на машине,
Поссать Гаврила захотел.
Свернул во дворик. Уж светила
Луна в межзвездной пустоте.

Гаврила лихо парканулся,
Дверь распахнул, исчез в ночи…
И только тихо улыбнулся,
Почуяв аромат мочи.

Он был предельно безмятежен,
И пиздеца никак не ждал…
Машина тронулась, понеже
Ручник Гаврила не поднял.

Он резво побежал по лужам -
Остановить фатальный рок.
Хозяйство все торчит наружу,
Кусты щекочут между ног.

Гаврилмобиль достиг забора.
А дверь открыта, вот беда…
Такого слабого упора
Хватило ненадолго, да.

Прижалась дверь к передней арке,
Со скрипом лопнула петля,
Повисла дверь. Гаврила жалко
Почти что про себя шепнул: “ну бля…”

Потом Гаврила матерился,
Орал: “За что??!!”, рвал волоса.
Но голос Кармы все ж пробился
Сквозь этот крик: “Зато поссал!”

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Всем хорошего настроения, оставайтесь цивилизованными людьми в любой ситуации!

I. День дурака

В 2001 году я работал в одной компании в родном Обнинске. Меня туда наняли безо всяких знаний о программировании или технологиях, там я делал первые шаги в HTML и PHP. Штат состоял из студентов, уровень идиотии зашкаливал, а стрелка раздолбометра постоянно торчала в красной зоне. И надо же такому случиться — к нам, как и ко всей остальной стране, пришел День Дурака! Как будто мало было обычных дней, но нет! Надо же получить официальный повод устроить беспредел и шабаш… Не буду останавливаться на стандартных шутках вроде перевернутых рабочих столов и скачущих кнопок “Start” в винде. Паре человек заклеили датчик мыши, у одного мышь оказалась с шариком, но это никого не остановило. Наш Биг Босс Костя вышел на несколько минут поговорить по телефону и оставил незалоченным свой комп. Немедленно его файл hosts подвергся обработке, после чего в течение 20 минут была создана страничка с неприличными лошадьми и большой бегущей строкой “YA HAV BEEN HACKD BY COOL HACKERZZZ!!!”, и все домены наших проектов резолвились на Костиной машине на эту милую поделку. То есть, открыв сайт ООО “Рога и копыта”, который мы разрабатывали, Костя увидел бы лошадей и мессадж от злобных хакеров. Через полчаса шило вылезло из мешка, и Костя поднял крик. Разработчики отреагировали незамедлительно:

- Я понимаю, что это важно. Но у меня тут турнир по “Сапёру”, я не могу! Пусть Ян займется!

- Ян тут один за вас трудится, охламоны! И Ян уходит на час пить кофе! (это, конечно же, сказал человек, который собственноручно переписывал hosts)

Костя был в бешенстве примерно с полчаса. Потом шутку открыли, он нервно поржал и успокоился. Он еще не знал, что в его Microsoft Word тоже покопались и поставили невиннейшую автозамену, а именно: каждая запятая превращалась в “, *ля”. Через пару часов, когда он едва не отправил нашему крупнейшему клиенту полный матюков документ, он снова стал как бы немного не в себе и переустановил ворд “потому что он словил какой-то вирус”. У меня есть подозрение, что Костя до сих пор не в курсе про автозамену…

II. Потому что это неудобно!

Перенесемся в 2006г. У меня еще не было аккаунта на Facebook, твиттера вообще еще не было, слова “Web 2.0” произносились с блаженным трепетом. Я читал умные книжки, про всякие там забугорные бороздящие все подряд космические корабли, имел Webmoney-кошелек, банковскую карту и вообще был продвинутым чуваком. И тем не менее, каждый будний день я садился на электричку-экспресс и ехал из Обнинска в Москву на работу, а вечером обратно. А кому щас легко? — думал я вместе с целой шумной компанией друзей, которые точно так же ехали на том же экспрессе. Билеты на экспресс продавались в кассах дальнего следования, туда нужно было стоять очередь, и у нас была своя очередность — каждую неделю кто-то один из 4 человек закупал билеты на всех на всю следующую неделю. РЖД, как истые староверы, принимали только наличность. Странно, что они бумажным-то деньгам доверяли, я бы не удивился, если бы кассирша попросила золотом рассчитываться. Или там, морскими раковинами. Но вот в один прекрасный день свершилось чудо: открыли отдельную (одну) кассу, где принимали Банковские Карты. Карт этих у мирян не было, и касса была совершенно свободна. Настала моя очередь закупать билеты, и я устремился. Кассирша была настоящая, советской закалки, с отбеленными, завитыми в мелкие кудряшки волосами. Ее лицо понравилось бы художникам: его можно было смело использовать как палитру. Просто обмакивать кисти в макияж. Образ дополняла чарующая улыбка мексиканской жабы и тяжёлый взгляд, в котором сквозила затаенная грусть. Это потом я понял, что причиной этой грусти было то, что ее посадили сюда, где вместо привычных бумажек ей нужно было возиться с карточками, нажимать на кнопки, вызывая таким образом таинственного и непостижимого Deus ex machina. Я отдал ей листок с паспортными данными, она начала выстукивать морзянку одним пальцем на клавиатуре. “Давайте вашу карту” — в лоток отправилась карта, карта ушла в считыватель, в лотке появилась мини-клавиатура с цифрами — надо ввести ПИН. Лоток закрывается, печатается чек, отправляется в лоток. Открываю лоток, расписываюсь на чеке, закрываю лоток. Жужжит принтер, из него появляется билет. Ура! Щас все распечатается и дело в шляпе! Мысленно начинаю хвалить РЖД (да-да, вот до чего дошло). Из мечтательного настроения меня выводят слова кассирши: “Ну что вы уснули-то? Давайте вашу карту!” Зачем карту? Почему карту? Я же уже же заплатил же ж! “Вы за один билет заплатили!”

Не сразу я осознал глубину падения. Только что я радовался успехам страны, применяющей передовые технологии для удобства своих граждан… И вдруг — сорок билетов! Сорок раз передавать через лоток карту, терминал, чек, билет… Позвольте… а можно все билеты разом пробить, распечатать, и я их все оплачу? “Нееет. Так нельзя. Может, у вас там денег не хватит на вашей карточке, а с меня потом штраф за 40 билетов возьмут! Не положено!”

40 минут продолжалась экзекуция. Моя рука писать устала, дважды ломался лоток, собралась небольшая очередь карточных горемык, которые бросали на меня выразительные взгляды.

Получив пачку билетов, я пошел к администратору. Администраторша была настоящая, советской закалки, с отбеленными, завитыми в мелкие кудряшки волосами… постойте, это дежавю какое-то. Она меня выслушала и сказала строго, как говорит матерая воспитательница детям из младшей группы: “А что вы думаете? Вы думаете, почему по этим вашим… карточкам так мало берут? А? Да потому, что это неудобно!”

III. Восстание кофе-машин

Вот вы все говорите “интернет вещей”, “умный дом”… А между тем, как вы сейчас узнаете, еще в 2006 году кофеварки обладали интеллектом, достаточным для нападения на человека. Прямо а-ля Стивен Кинг, ни больше ни меньше.

В офисе компании “ХроноПэй” была кухня. Даже две, поскольку было два этажа. В каждой кухне было по кофеварке, однажды одна из них сломалась и по какой-то причине была перенесена на кухню нижнего этажа, куда затем пришел специально обученный человек, чтобы ее отремонтировать. Ремонт, насколько я могу судить, не увенчался успехом, но человек оставил кофеварку включенной в сеть. Мы с Лешей стояли возле холодильника и мирно беседовали о модульных тестах и парном программировании. Мимо прошел Дима и, взяв кружку, направился к столу с кофе-машинами. Был погожий летний день, и, как говорится в таких случаях, ничто не предвещало беды.

В полном соответствии с законами Мерфи, Дима выбрал сломанную кофеварку. Мы с Лехой переглянулись и стали наблюдать. Нажатие кнопки, тарахтение… Кофеварка задрожала, запыхтела, угрожающе заскакала на месте, из всех ее отверстий повалил пар. Дима испуганно отпрянул и с широко раскрытыми глазами смотрел на разбушевавшийся аппарат. Затем он обернулся и глянул на нас, ища поддержки и сочувствия, но увидел лишь неподдельное любопытство и первобытную жажду зрелищ. В этот момент я почувствовал, что ситуация вышла из-под Диминого контроля настолько, что ее можно превратить в полный хаос одним элегантным движением. Я громко крикнул: “Спасайся!!!” - и спрятался за холодильник. Дима изменился в лице, быстро развернулся, схватил стоявший у стола офисный стул и заслонился им от врага. Кофеварка дрыгалась и скакала, кружка с непонятной коричневой жидкостью разбилась на куски от падения на пол, стул оказался сломанным и развалился на части, так что в руках у Димы осталась только спинка, а все остальное рухнуло ему же на ногу. Через минуту опасность была ликвидирована путем выдергивания вилки из розетки. Дима с ненавистью посмотрел на кофеварку, на меня, и ушел. Видимо, стал разрабатывать машину времени, чтобы ликвидировать меня до того, как все вышеописанное произошло.

IV. Здравствуй, Мир!

В бытность мою разработчиком в компании Badoo я услышал несколько историй, участником которых не был, но тем не менее хочу их записать.

Однажды в офисе, под мерный стук клавиш, Серж(TM), который спокойно сидел за своим монитором и никого не трогал, вдруг произнес:

— А что это у нас баду.ком выдает “халоу ворлд”?

Такие вещи, которые настолько на виду, что их никто не замечает, только Серж может углядеть.

— Данунах. Какой “халоу ворлд”?! Первое апреля кончилось, Серега!

— Небось опять Хасан* чего-то выложил…

Тут где-то рядом, отчетливо, хоть и с надрывом, прозвучало Ля. Примерно первой октавы. Затем было Фа, а дальше ранее неизвестные ноты Ма и Ху. Вслед за музыкой сфер, сбивая стулья и роняя чашки с кофе, промчался Фишер. Обладая недюжинным интеллектом, он быстро сопоставил новость с тем фактом, что 10 минут назад он раскладывал скрипт следующего содержания:

echo “Hello world!”; exit;

Скрипт был написан для теста одного из сишных сервисов, и то ли он был разложен не в ту папку, то ли не на ту группу серверов — но уехал он на продакшн и заменил собой индексный файл.

Триста нод**. Триста пытливых CPU, несколько тысяч ядер, в течение 20 минут раздавали людям по всему миру “Hello world!” Такого унижения не испытывал даже робот-меланхолик Марвин из “Автостопом по Галактике”. Возможно, небольшим утешением для них послужит тот факт, что возможно, это был самый высокопроизводительный Helloworld в истории.

V. Во всем виноват Хасан*

Однажды Хасану* поручили интеграцию с Фейсбуком. Лайк, шер, репост — вот это все. Плюс сущие несколько миллионов новых пользователей. Хасан* принялся за работу, тут же нагуглил блог некоего разработчика, в котором объяснялось, что, куда и как подключать, все по правде и даже с картинками. И с примерами кода, что и сгубило блог. В HTML, который автор приводил на своей страничке, была в том числе ссылка на Javascript-файл, который располагался по адресу хттп://блогчувака/фейсбук.жс. В таком виде этот код и выехал на продакшн badoo (с тех пор много воды утекло, и сейчас подобное было бы практически невозможно).

Сначала прилег сам блог. Спустя немного времени больше юзеров узнало про новую фичу, и в результате слег весь хостинг-провайдер. Конечно, 150млн пользователей поперлись на свежачок. А обнаружили, ясное дело, не сразу: у нас-то все работало после релиза, только позже где-то JS-ошибки посыпались…

VI. Unplug-n-pray

В былые времена админы Badoo выезжали лично устанавливать систему на новую партию серверов, когда они прибывали в датацентры в Европе или Америке.

Вот однажды делегация суровых российских админов отправилась покорять Майами. В поте лица они валялись на пляжах, засучив рукава шлепали горячих пуэрториканок и пили пина-коладу. Днём вся команда в серверной, там прохладно и облачно, относительная влажность самое оно. Обжимаются провода, подключаются разъемы, жизнь бьёт SSH-ключом.

А тем временем в Москве, в Центре Управления Полетами админов в Майами, загорелась красная лампочка. Потом другая, потом третья. Графики упали до отметок, близких к нулевым, настал апокалипсис и третья мировая.

— Короче, полная опа, — ёмко подытожил кто-то, даже не подозревая, насколько близко он подобрался к печальной истине. Это действительно была опа. И принадлежала она Жене Петренко***, который одним ловким движением таза, словно танцуя, выдернул питание из сервера, на котором работал авторайзер****.

Сейчас такое было бы уже невозможно. Новые сервера устанавливаются в стойки работниками ДЦ, и сразу после подключения к сети попадают в заботливые руки (именно руки!) сотрудников

VII. Русский взломщик

Это случилось в июле 2015 года. Первые недели жизни в Голландии, новая работа, много удивительных открытий, в основном приятных, хоть и не всегда. Я работал в городе Almere, компания была, скажем так, странноватая. Начать хотя бы с того, что мне — программисту — в течение месяца не давали доступа к исходным кодам. Вместо этого я изучал какой-то монструозный проект на Java, без документации и вразумительных инструкций по установке и использованию — это было задание на ресёрч от CTO. В течение двух недель после моего трудоустройства три программиста, составлявшие отдел разработки, уволились. Впрочем, в офисе они все равно не появлялись. Я понес к CTO результаты двухнедельного исследования, он слушал меня примерно минуту, после чего произнес “OK” и кивнул головой, выразительно посмотрев в сторону двери: аудиенция была окончена. На следующий день он уволился. Из программистов в компании остались четыре фронтендера, и те в Дубае. Я сидел один в айтишной части этажа, где могла бы свободно разместиться дюжина разработчиков, и читал хабрахабр.

Офис был монументальный. Трехэтажный, с высоченными потолками. Наш отдел был отгорожен от остального этажа матовым стеклом. Каждый вечер один из топ-менеджеров, у кого был доступ к сигнализации, обходил здание убеждался, что там никого нет, и закрывал входы и выходы на ночь.

В тот день я зачитался чего-то интересного и уходил чуть позже обычного. Сигнализация сработала, когда я вызвал лифт. Честно говоря, я слегка опешил, если не сказать — офигел. Я был один в огромном офисном здании, куда скоро прибудет наряд полиции, в чужой стране… Ощущения были не самые приятные. Слава богу, у меня был телефон Робина, который закрывал офис, я объяснил ему ситуацию, и он отправился обратно на работу вызволять меня (да, собственно, исправлять свой же косяк , ведь это он проверял, что сотрудников в здании не осталось).

Полиции приехало аж три машины, я даже загордился. Они, хоть и отнеслись к моей истории с пониманием, не спускали с меня глаз до тех пор, пока не появился Робин, и я чувствовал, что где-то подспудно они думают что-то вроде “Чертов русский хакер, что ты задумал?”

Примечания.

* — во избежание репутационных потерь имя Русана изменено на Хасан

** — на самом деле, черт его знает, сколько нод. Много.

*** — страшный демон.

**** —добродушный великан. Однажды развалил стол для 12 персон, просто оперевшись на него.

Краткий словарь Badoo. Оставлю здесь, чтобы было.

“За приезд” — тост. Говорится по любому поводу, обычно Демиургом. Чаще всего других тостов не произносится.

“Как ты испытательный срок прошел?” (вариант: “Так ты испытательный срок не пройдешь…”) — говорится Рушбой со снисходительной интонацией, в те редкие моменты, когда ему лень выдумать что-то более свежее и оригинальное.

“У меня метровый иридиевый” — говорится Антохой в качестве аргумента в споре.

“Во всем виноваты админы и Русан” — святая правда.

Прочитал, как Варламова ошарашили электрички, и вспомнил свои приключения с РЖД. Докладываю.

Было это лет десять назад. Я тогда мотался каждый день из Обнинска в Москву на экспрессе. Билеты можно было купить только за наличку. И вот в один прекрасный день РЖД открывает продажу билетов по карте! Нас ездила из Обнинска целая компания, человек пять, и как раз была моя очередь покупать на всех билеты (делать это нужно заранее, ибо в последнюю минуту ничего не выйдет). Я прихожу на Киевский вокзал, смотрю — лепота! Отдельная касса выделена для желающих, стало быть, вкусить плодов цивилизации и расплатиться заморским чудом — банковской картой. И эта касса, одна во всем зале, совершенно свободна! Потому как граждане, в массе своей люди несознательные, всех этих карточных фокусов до конца не оценили, а которые попроще, так и вовсе эти карточки… в общем, не доверяли карточкам.

И вот я, гордый от собственной причастности к прогрессу и высоким технологиям, подхожу к окошку. Мне, говорю, билеты на экспресс, Обнинск-Москва и обратно, на 4 человека, туда и обратно, на всю следующую неделю. Вот вам паспортные данные всех пассажиров!

За окошком долго печатают номера паспортов, имена и фамилии.

- карту вашу давайте…

Даю карту. В лоток ее засовываю. Карта вставляется в терминал, терминал отправляется в лоток, я открываю лоток, ввожу пин-код, лоток закрывается, я жду в нетерпении.

Карта моя тоже отправляется в лоток, с ней — чек. В чеке надо расписаться. Расписываюсь, забираю карту, отправляю обратно чек.

Жужжит принтер, из него появляется билет, и отправляется а лоток. Ничего не понимаю. Забираю билет. Говорю:

- Э-э-э… мне же много билетов надо…

- Ну много так много.. щас следующий оформим…

- А можно я за все билеты заплачу один раз? И вы из все сразу мне напечатаете и отдадите.

- Один раз? А может, у тебя денег столько нет на карте? А? А с меня за неиспользованный билет штраф возьмут! Не положено!

Сорок билетов надо было мне оформить. Сорок транзакций по карте. Сорок раз лоток мотался туда и сюда. Ёжика из известного анекдота уже бы давно послали куда подальше, а я все расписывался и расписывался на чеках…

После этого, я пошел к администратору. Нашел. Говорю, так мол и так, работа с картами не тово.. плохо все. Сорок раз расписывался, тудыть ее в качель… Администраторша, дородная тетка, улыбнулась и сказала:

- А вы что же вот это тут себе думаете? Вы думаете, почему этими вашими… картами! Почему ими так мало расплачиваются? Да потому, что это неудобно!

One of my recent larger projects at work was to improve our pretty large PHPUnit test suite, which consists of nearly 7000 test cases. While accomplishing this useful but exhausting work, I made my notes of the most common bad coding, architecture and setup patterns, and this compilation I’d like to offer to you. Mostly, the examples refer to test code, although some were a consequence of poor design decisions. The order in which I list the bad practices and errors, is not the order of their importance. Mostly, it is the order of occurences.

1. Lower error_reporting level for unit tests. The first stage of improvements was a task that sounded fairly simple: turn on E_WARNINGs for unit tests. Yes, we used to have them off, as well as E_NOTICE and E_STRICT. And you know what? Never. Repeat. This. Error. I mean it. We have a tough code review process established, and the engineers are quite experienced. That’s why I did not expect too much trouble with this. I was wrong. In test/bootstrap.php I changed error reporting, ran the test suite, and I was totally frustrated by the number of warnings in the report: seven damn hundred! Fixing those was mostly a long and boring job of filling in the missing arguments for function/method calls. Yet I felt really bad about this: fixing a missing argument could introduce another error, and probably even harder to track. If we had error_reporting of E_ALL from the very beginning everywhere, this situation could never happen. What is worse is that a warning or even a notice is somewhat likely to be just the top of the iceberg, with any sort of weird logical error lying deeper. A particular such case is listed below under number 2. In the end, after long days of work, I managed to eliminate all warnings. However, E_NOTICE and E_STRICT are still hidden, and I can only hope it will not be my job to deal with them…
2. Forgotten dataProvider annotation. In several test methods, the dataProvider annotation was missing. Method has signature like this: function testSomeBehavior($input, $expectation), and there is a method below called testSomeBehaviorProvider, but PHPUnit is not told about data provider. Hence, PHPUnit calls method as usual, without arguments, which in PHP is equivalent to passing NULLs, though an E_WARNING is raised. Also, those test methods were only executed one time, instead of several times with different arguments. Those tests were written in such way that giving all NULLs as input was actually OK and all the assertions passed. When writing, developer probably ran a whole test folder, saw the green line and moved on. It is also easy to not pay attention to such a mistake during code review. However, simply turning E_WARNINGs on would have made this impossible.
3. Static state manipulation. Some people say globals are evil but don’t care about singletons and alike. When using (and especially when modifying) static state, you better ask yourself twice if you really need it. If there is no other way, be extremely careful. You change the contents of a static class member — it’s left there for all the future users of it. You have to make it 100% sure that you restore the member to its initial state after you’re done, no matter how your test method is terminated, be it an exception or a return. Consider this:
   DatabaseConnection::$instance is a DB object.
   In your test, you change it:
   DatabaseConnection::$instance = new DBMock();
   Then, all the other test methods, those that will be called later in the test suite and that expect a DB instance, will meet something unexpected, a mock! Maybe you thought about this, so before return in the test method you restore the value:
   DatabaseConnection::$instance = $originalDB;
   However, it might happen that an Exception is thrown before you restore original value, and those situations must be taken care of, as well. The consequence of this particular error is hard-to-debug weird behavior. What makes it even worse is that the weirdness is observed later in a completely different place. The conclusion: don’t mess with statics. If you have to, be extremely careful!
4. Using implicit fixtures in functional tests. In our terms, functional test is one that talks to real database, not to a mock. It happened (yes, “historical reasons”, ya know) that for unit tests we use the same DB snapshot as for development. That is, it contains a small portion of real data with sensitive information obfuscated. I found a lot of functional tests follow this pattern: 1) get an object by ID; 2) apply certain actions; 3) verify the resulting DB structure. For example:
   $order = find_order(3456789);
   cancel_order($order);
   assert(order_is_cancelled(3456789));
   The motivation behind this would be like “For my test, I need an order of type X with 2+ products in it. Let me find that in our DB snapshot… Ahh, here you are, order ID 3456789”. There are two major problems with this approach. First, those numbers don’t say anything to anyone. Much better would be to create a new order in setUp() or in the test method. Learn DbUnit, it’s a handy way to test against a real database. Second, your DB snapshot is not really stable, and you may find your test failing without any of the relevant code changed. This can be frustrating and take long time to find out what’s happening. Also, if you don’t have BEGIN … ROLLBACK in your setUp() and tearDown(), then it’s even worse. For that, see point 5:
5. Not cleaning up after your dog. Functional tests read and write to the real database. For proper isolation, the DB state after each test should always remain the same. Unchanged. This should be easily achievable by BEGIN … ROLLBACK in your setUp() and tearDown() respectively. In our case, we did have this in place… Occasionally, it used to be broken in certain cases (see point 3: mangling with statics). This stuff caused me a lot of trouble when I was to introduce parallel test execution in order to speedup things. The reason being that if your tests modify the database, it is obvious that they rely on a certain order of test execution. I introduced concurrent test runner and got a lot of failures. Test A that asserted to have X rows in some table started to fail because of test B doing INSERTs to that table. Before concurrency, test A used to always run before B, and it all seemed OK. I ran the test suite with several workers — and it screwed everything up. In the end, the cure for pains 4 & 5 is: make your functional tests isolated by running every test case in a transaction which is then rolled back; create explicit fixtures (hello DBUnit!).