пятница, 8 марта 2019 г.

Установка переменных среды в Windows для PHPUnit

На новом проекте используем mongoDB. Docker у меня установлен под Wndows (Docker Toolbox). Для тестов используется phpUnit.

Когда запускаются тесты в баше workspace'а - все нормально работает. Проблемы появляются при запуске тестов в phpStorm'e.  Он не может найти хост 'mongo', указанный в конфигурации проекта для mongoDB. Оно и понятно - это внутренний IP, выданный докером контейнеру mongoDB, и из-под хоста (Windows) о нем ничего не известно. Сама виртуальная машина получает IP 192.168.99.100. Таким образом, нужно как-то указать phpStorm, что mongo нужно искать по этому IP-шнику. То есть, нужно заменить параметры конфигурации mongoDB, причем только для phpStorm.

Наиболее простой способ - переопределить переменную среды в файле phpUnit.xml, указав явно IP-адрес виутальной машины. Если же, по какой-то причине, редактировать phpUnit.xml нельзя, можно сделать 2 вещи:
1) Добавить переменные среды для phpUnit в настройках phpStorm (Menu->Run->Edit Configurations...->phpUnit.xml->Environment Variables). После этого появится возможность запускать тесты из среды phpStorm по Alt+Shift+F10.
2) Установка нужной переменной среды прямо в консоли phpStorm перед запуском тестов:
> SET DATABASE_HOST=192.168.99.199      (** вместо DATABASE_HOST - имя вашей переменной среды **)
> phpunit
После этого можно будет запускать тесты из консоли phpStorm'а.

Надеюсь, эта заметка будет полезна кому-нибудь.

понедельник, 31 декабря 2018 г.

С наступающим Новым 2019 годом!

Друзья, вот и подходит к концу 2018 год - год Собаки. На смену ему идет 2019 - год Свиньи (маленького доброго Поросенка =)

Хочется пожелать вам всем в новом году здоровья, удачи и положительных перемен в жизни.

Чтобы все ваши благие желания исполнились и от этого жизнь людей вокруг стала чуточку лучше.

С наступающим Новым 2019 годом! Ура! )


суббота, 29 декабря 2018 г.

Apache for Windows и двоеточие: страшная сказка на ночь

Расскажу одну интересную историю, которая приключилась не так давно.

Изучаю написание ботов в Telegram. В Telegram API можно выставить webhook, который будет дергаться при поступлении событий с серверов Telegram. На одной машине стоит Vagrant и под ним все нормально работает. То есть, моя серверная часть успешно получает события от Telegram. На другой - LAMP под Windows. И на ней, соответственно, все то же самое уже не работает. То есть, ровно тот же самый код.

Разбирался пару часов, наверное, пока не нашел, в чем же дело.

Под Vagrant'ом была VirtualBox c Убунтой внутри. На которой веб-сервером был Nginx.
В Windows стоял OpenServer, в котором запускался Apache под то же самое.

Теперь самое интересное. Дока по Telegram API советует скрывать URL веб-хука, используя для этого выданный токен (никому, кроме пользователя API, неизвестный).  То есть, строить URL как-то так:

https://www.example.com/[token]

Сама строка токена где-то в середине содержит символ двоеточия (:).
Так вот. Так как в Windows символ ':' является значимым для файловой системы, любые URLы, его содержащие, в целях безопасности блокируются апачем под Windows. Нашел интересный тред в буржунете, где люди предлагали даже сделать какой-то флаг при запуска апача, чтобы можно было выключить эту функциональность под свою ответственность, но что-то там дело так и не сдвинулось, как я понял. 
Ну а под другие оси Apache таких ограничений не имеет, если я правильно понял.
В общем, весьма интересная ситуация, знание о которой иногда может быть полезным )

понедельник, 5 марта 2018 г.

Пара забавных ситуаций или вести с полей

Вообщем, хочу рассказать о трудовых буднях п(р)ограммиста. Всего 2 случая из моей личной практики, которые имели место быть не так давно. И в обоих случаях пришлось по дурости потупить немного ) Итак.

1. Есть некий сервис A, который принимает HTTP-запрос, обрабатывает его особым образом и выдает некий результат.  В некоторых (достаточно редких) случаях сервис A в процессе обработки обращается к сервису B.  Эти случаи задаются комбинацией полей в БД для заданной учетной записи. Так вот, тестировал работу сервиса А локально. И долго не мог понять, почему данный конкретный запрос отваливается по таймауту. Пока через NN минут не догадался посмотреть, какова комбинация полей для локальной учетки в БД, от которой выполнется запрос. Разумеется, именно для этой записи требовалось обрашение к сервису B. А сервис B у меня на локальной машине не был запущен по определенным причинам. В общем, ситуация простая, но я долго не мог сообразить, что происходит.  В какой-то момент даже была мысль, что что-то случилось с апачом )

2. Нужно сделать запись некоторой информации в БД. Использую PHP-расширение MySQL PDO. Чтобы не изобретать велосипед, просто скопировал код процесса  инициализации/создания экзмпляра класса PDO из другого проекта. Всего несколько строк. Все, вроде бы, идет хорошо. И тут в какой-то момент понимаю, что данные в БД не пишутся. То есть, все действия выполняются правильно, PHP-функции возвращают корректные результаты и правильное количество обработанных строк, но в phpMyAdmin вижу, что совершенно нет никаких изменений в БД ! Попробовал выполнить запрос из консоли phpMyAdmin - все работает. То есть, проблема где-то в коде.. Была мысль, что просто не в ту БД пишу. Проверил конфиг, который использовался для подключения к БД. Все данные правильные, то есть, правильный сервер, БД, правильная таблица. Потихоньку начал сходить с ума ) Теперь развязка: в скопированном мной коде был такой фрагмент среди прочих параметров настройки подключения:

    $opt = array(
       [..]
        \PDO::ATTR_AUTOCOMMIT         => false,
      [...]
    );
Обратите внимание, что выключен автокоммит в БД. Когда я добавил использование транзакций и выполнил коммит для текущей транзакции после всех своих манипуляций с БД, все заработало.  !!! )))

Даже не знаю, какой из всего этого вывод. Наверное, постараться держать голову холодной (если такое вообще возможно в нашей работе =)) и не пороть горячку. В общем, всем спокойных трудовых будней )

понедельник, 8 января 2018 г.

C Новым 2018 годом и Рождеством!

В этом году я немного припозднился с поздравлениями, но лучше позже, чем никогда :)
Поздравляю всех своих читателей с Новым 2018 годом Желтой Собаки. Желаю вам здоровья, удачи и семейного благополучия. Чтобы все у вас было хорошо.  Даю вам установку на добро )
С праздниками, друзья!



вторник, 20 июня 2017 г.

Интересная вероятностная задача

Недавно обнаружил интересную задачу. Итак.
Имеется некоторая функция one_two(), которая возвращает равномерно распределенные значения 1 или 2. То есть, вероятность появления 1 или 2-ки равна 50% (1/2).
Задача. Написать такую функцию one_two_three(), которая бы возвращала равномерно распределенные случайные значения 1, 2 или 3 (то есть, вероятность появления каждого числа - 33%, или 1/3). Важный момент. Использовать при этом можно только функцию one_two().
То есть, никаких вызовов random() и все такое.  Пока не могу сообразить, как решить. Но интересно )

Обновление от 21.06.2017:  Удалось решить (кое-как =)) Два дня думал ))) 

четверг, 11 мая 2017 г.

Git for Windows и старые проблемы

Ранее писал уже о том, что git log с какой-то версии Git выводит в консоли под Windows русские (utf-8) символы в таком виде:

<d0><b9><d0><b8>.....

В версии 2.11.0.3 это было исправлено, то есть, символы русского языка стали отображаться нормально. Но затем (внезапно! =) все снова поломалось. И до сих пор (а уже на дворе версия Git 2.13.0) ничего в плане улучшения этой ситуации не меняется.
Зверски загуглил на тему того, что же делать с этой проблемой. И в одном из тредов на stackoverflow нашел вот такое решение.
Необходимо перед использованием git log явно в консоли прописать команду:
===
SET LC_ALL=C.UTF-8
===
Попробовал это дело под Windows 7 и... помогло! ))
Ну а далее уже просто прописал установку этой переменной среды в Environment Setup настроек ConsoleZ, и вуаля )
В общем, если кто еще столкнется с той же проблемой, то, возможно, мой пост окажется полезным.