Web developer blog

Nowadays cypress is a quite hype technology (I am saying this in Fall 2020, everyone knows how rapidly js world can change ;))

Cypress is a next generation front end testing tool built for the modern web.

https://docs.cypress.io/guides/overview/why-cypress.html#In-a-nutshel

I had some experience with Behat and other types of tests like unit/integarational, but today I will tell you about e2e.

When I wrote Behat tests I didn't think a lot about how to structure my test cases in a maintainable way. This led me to the antipattern called "Single-Layer Architecture"[1].

Extending such tests quickly becomes a mess and tends to become an ineffective work:

1. You can't focus on business logic, you always need to remember low-level details to introduce a new step definition
2. Your low-level solutions are often duplicated, and you even don't notice that
3. Changing testing framework means rewriting or updating all step definitions!

Fortunately there is an approach which is very easy to follow and which mitigates mentioned issues.

This story is about wasting time and life. It is about Attraction Wars.

Attraction Wars is an online browser game I developed in my free from job time.

I am surrounded with "success stories". But very few new projects (or startups if you want) succeed. According to the different sources, it is less than 10%, I more believe sources which say that it is even less than 1%.

Of course, it dramatically depends on which stage startup was accounted for this statistics... But this story is not about it. I just feel that I should write "story of NOT success", just to dilute all that success stories with other fairy tale.

Honestly I think that history of Attraction Wars development is an example of how games (or any pet projects) should never be developed.

However it teached me a lot, including technologies and outlook, so I hope this experience will be useful for someone. Or only for me as reminder.

But if you are interested of this deep dive to cave, then please go ahead.

Second version of Circle CI configuration changed dramatically.

It introduced workflows, and they are used in pipes meaning.

Every workflow can include multiple steps.

Node.js example:

Эта заметка начинает цикл заметок о процессах разработки и деплоя приложений. Для начала покажу, как с помощью сервиса Travis CI можно относительно легко реализовать процесс проверки качества и работоспособности кода.

Практику постоянной проверки сборки на наличие дефектов называют Непрерывная интеграция (Continuous Integration).

Вопрос написания тестов в этой статье не будет рассмотрен - это тема другой статьи. Сделано предположение, что у вас уже настроен Behat, и тесты уже могут быть локально запущены с использованием Selenium.

Для начала, проверим, нет ли в коде нарушений установленного код стайла. Это позволит ознакомиться и начать использовать Travis CI. Если у вас нету тестов - настоятельно рекомендую использовать как минимум проверку стиля кода.
Обоснование важности консистентности кода и и его стиля можно найти во множестве мест, например, Стив Макконнелл “Совершенный код” часть 7 раздел 31.

Недавно столкнулся с задачей созданием бэкапов данных сервера на моей vps. На ней хостятся разные сайты. Мои личные работают под управлением более-менее вменяемых технологий/движков, так что весь код есть в системе контроля версий. Для таких сайтов нужно только резервное копирование базы данных и загружаемых данных. Некоторые сторонние сайты  работают на wordpress, так что нужно также сохранять исходники. 

Итак, постановка задачи: с некой периодичностью нужно бэкапить базы данных и все содержимое некоторых директорий. Нужно сохранять бэкапы за определенное последнее время для экономии места.

При работе со старым кодом иногда очень сложно найти место, на котором прервалось исполнение. Конструкции типу die, exit и т.д. - очень плохая практика, но много легаси кода (и не только - я ничего плохого не говорю о Wordpress, так что молчу) ими злоупотребляют. Одна из самых больших проблем подобных конструкций - то, что их сложно найти и отладить. (Используйте exception!)

Но когда все же стоит задача найти место, где прерывается исполнение кода, можно воспользоваться следующим сниппетом: