Настройка DATABASE_URL для локальной разработки

При разработке go-проекта (да и любого другого) вы вправе использовать базу данных. Обычно подключение к базе данных требует dsn-строки определенного формата, например (для Postgres):

dbdsn = "dbname=my_database user=postgres password=my_password sslmode=disable"
db, err := sql.Open("postgres", dbdsn)

При размещении проекта на серверах heroku данная конструкция неактуальна, так как силами инженеров heroku dsn-строка перенесена в переменную окружения DATABASE_URL и код подключения выглядит так:

db, err := sql.Open("postgres", os.Getenv("DATABASE_URL"))

Таким образом вам не требуется знать логины-пароли и прочие детали подключения.

Но возвращаясь к локальной разработке вы снова должны внести в код dsn-строку с настройками вашей локальной БД, а при релизе - эту строку затереть. Таким образом, возникает ненужная суета в коде, которая при наличии гита или другой VCS фиксирует еще и ненужные изменения.
Поэтому синхронизируемся с подходом heroku и пропишем у себя переменную окружения с тем же именем.

Сервис кодогенерации

Всем здрасьте.

Как-то давно я создал небольшой сервис, позволяющий быстренько сгенерировать php-код необходимый для создания пользовательского поля, свойства инфоблока или почтового события (даже вместе с шаблоном). Создать-то создал, но написать про это забыл)

Так вот, сервис находится тут. Интерфейс сервиса на английском, тут уж ничего не попишешь. Слева выбираете тип сущности который хотите создать, в подгружаемых полях указываете некоторые значения и на выходе получаете php-файлик с кодом. Файлик можно либо запустить, либо запустить код из него в командной php-строке Битрикса. Быстро и просто.

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

Вот собственно и все. Ссылка на сайт и на бота еще раз.

git-rebase скрипт

Для того чтобы история веток не переплеталась причудливым образом - умные люди придумали git rebase.

Таким образом, процесс разработки в вашей ветке происходит так:

1. Почкуемся от мастера
2. Разрабатываем, коммитим.
3. Когда все готово и можно мержить в мастер выясняется что в мастере появились новые коммиты.
4. Конечно, можно наплевать на всё и сделать мерж, попутно разобравшись с конфликтами и увидеть в графе невероятные узоры).

Но можно сделать по-другому: оставаясь в ветке разработки, можно поребейзить на нее мастер и получить свои коммиты последними в истории ветки. После этого можно мержить и любоваться менее запутанным графом. Чтобы не мотаться туда-сюда по веткам и не набирать одно и то же миллионы раз - небольшой bash-скрипт:

#!/bin/bash

# Перемещаемся в каталог проекта
cd /path/to/project

# Основная ветка разработки, обычно "master"
baseBranch="base_branch"
# Выцепляем текущую ветку
curBranch=`git status |head -n 1| grep "branch" | cut -d ' ' -f 4`

# Если мы не на основной ветке - делаем ребейз, предварительно обновив основную ветку
if [ "$curBranch" != "$baseBranch"  ];
then
    echo "Updating $baseBranch"

    git co "$baseBranch" && \
    git plo "$baseBranch" &&

    echo "$baseBranch updated"

    echo "Moving to $curBranch and start rebasing"

    git co "$curBranch" && \
    git rebase "$baseBranch"

else
    # иначе просто обновим основную ветку, так как мы уже в ней
    git plo "$baseBranch"
fi

exit 0


Этот же скрипт на гисте.
Применяемые гит-алиасы (plo - pull origin, co - checkout) - в моей репе.

Сброс Symfony Lock

Внезапно на Symfony проекте прекратил работу ежеминутный комманд.
В логе сообщалось, что комманд не работает, так как уже запущен экземпляр данного комманда. Это реализуется с помощью стандартного компонента Symfony.

Расспросы причастных показали, что процесс комманда был убит ручками. В связи с этим, стало ясно, что процесс убит, а какой-то флаг, отвечающий за то, что процесс еще работает - остался в живых. Значит, надо удалить lock флаг.

Поиски были краткими:

1. ищем реализацию хендлера в ядре симфони

2. так как кастомный путь к локам в хендлер не передавался - ищем лок-файл во временной папке (если никто ничего не менял то это /tmp/)

3. Смотрим, какие файлы есть во временной папке и удаляем нужный.
Название файла, как можно судить из кода на гитхабе формируется из префикса sf, названия лока, переданного в комманд и хеша этого названия.
Таким образом, если ваш лок называется, например my.lock, то найти и удалить надо файл, начинающийся с sf.my.lock

Затем удаляем данный файл и проверяем, как работает комманд.

Memcache и expiration time

Сегодня пришлось столкнуться со странной багой, связанной с Мемкешом.
При установке какого-либо короткого периода жизни ключа, ключ почему-то существовал гораздо дольше положенного времени.

После различных поисков и сравнений версий на серверах бага была обнаружена. Время в Мемкеше отличалось от системного, аж на 14 часов. Неясно почему, но отличалось. Бага решается перезапуском Мемкеша:

>  /etc/init.d/memcached restart

Небольшой скриптец как проверить системное время и время Мемкеша:
$memcache = new Memcache;
$memcache->connect('127.0.0.1', 11211);
$stats = $memcache->getStats();
$mct = $stats['time'];
$curt = time();
echo'<pre>DIFF: ',($mct - $curt),'</pre>';

В идеале должно выводить 0 или -1.

Update: причиной отставания времени считаю уход в спящий режим. После восстановления системы из спящего режима системное время и время сервера Мемкеша различаются (Ubuntu 14.04)