(Около)Рабочий дыбр
Oct. 7th, 2010 10:09 pmВо первЫх строках сообщаю, что на новой работе хорошо. Минусы - ехать туда минут на 10 дольше, чем на старую. Плюсы - что это все в более жилом районе, и с инфраструктурой там, как в жилом районе, а не в промзоне. То есть и магазины, и рыночек, и аптеки, и, небось, сбербанк где-то есть. И идти вечером до метро приятно. И доставка обедов в офис.
Новые знакомства пока не заводятся. Впрочем, старых для работы хватает,а так как сижу в кабинете, где всего 3 человека, один из которых еще не вышел, то с новыми знакомствами придется, видимо, повременить.
Далее - программистское.
Оказывается, примитивный ORM сотворяется на SQL::Abstract за пару часов. Самое интересное, что потом он еще и работает.
Еще оказывается, что со всякими нестандартными постгресовыми типами работать через plain SQL существенно удобнее. То есть
1. Работу с BITSTRING я так и не осилил.
2. для HSTORE гуглится сериализатор.
3. С массивами SQL::Abstract работает из коробки - но не удалось завернуть соответствующую постгресовую конструкцию: элемент, проверяемый на наличие в массиве, должен быть слева, т.е. условие ? = ANY(array) работает, но сходу не пишется, а наоборот - пишется, но не работает.
4. ENUM работает как родной, но добавить в него значение в PostgreSQL до 9.0.1 - фиг, надо явно создавать новый тип.
Да, я в курсе, что есть DBIx::Class. Но сборщики RPM-ов - скорее не в курсе. И вообще оказывается, что на CentOS перловые модули - древние как не знаю что. Правда, пока это не критично.
Да, если кто-то хочет попрограммировать на Perl - welcome. Платят аккуратно, задачи есть, перспектива есть. Но прямо сейчас - только на подряд.
Новые знакомства пока не заводятся. Впрочем, старых для работы хватает,а так как сижу в кабинете, где всего 3 человека, один из которых еще не вышел, то с новыми знакомствами придется, видимо, повременить.
Далее - программистское.
Оказывается, примитивный ORM сотворяется на SQL::Abstract за пару часов. Самое интересное, что потом он еще и работает.
Еще оказывается, что со всякими нестандартными постгресовыми типами работать через plain SQL существенно удобнее. То есть
1. Работу с BITSTRING я так и не осилил.
2. для HSTORE гуглится сериализатор.
3. С массивами SQL::Abstract работает из коробки - но не удалось завернуть соответствующую постгресовую конструкцию: элемент, проверяемый на наличие в массиве, должен быть слева, т.е. условие ? = ANY(array) работает, но сходу не пишется, а наоборот - пишется, но не работает.
4. ENUM работает как родной, но добавить в него значение в PostgreSQL до 9.0.1 - фиг, надо явно создавать новый тип.
Да, я в курсе, что есть DBIx::Class. Но сборщики RPM-ов - скорее не в курсе. И вообще оказывается, что на CentOS перловые модули - древние как не знаю что. Правда, пока это не критично.
Да, если кто-то хочет попрограммировать на Perl - welcome. Платят аккуратно, задачи есть, перспектива есть. Но прямо сейчас - только на подряд.
no subject
Date: 2010-10-07 06:16 pm (UTC)Они такие же, как в RedHat соответствующей версии.
Хочешь дао - ставь от федоры.
no subject
Date: 2010-10-07 06:20 pm (UTC)no subject
Date: 2010-10-07 06:26 pm (UTC)Очень даже интересно... Особенно работа в офисе в режиме на подряд... Мне это гораздо интереснее чем непрерывные обязательства на неопределенное время. hh'шное резюме кинуть?
no subject
Date: 2010-10-07 06:40 pm (UTC)no subject
Date: 2010-10-08 09:22 am (UTC)no subject
Date: 2010-10-11 11:03 am (UTC)no subject
Date: 2010-10-08 12:26 pm (UTC)