From kapranoff на gmail.com  Fri Jan  2 21:38:44 2015
From: kapranoff на gmail.com (Alex Kapranoff)
Date: Sat, 3 Jan 2015 09:38:44 +0400
Subject: [Moscow.pm] 2015 CPAN Pull Request Challenge
Message-ID: <CAHw_nxjo1Gts1-kNVVigsU712SN5D+nKzRD=cip7vHruxMZ6=g@mail.gmail.com>

Нил Бауэрс устраивает вот такое:
http://blogs.perl.org/users/neilb/2014/12/take-the-2015-cpan-pull-request-challenge.html

Вписываетесь, и он раз в месяц присылает ссылку на цпановский модуль, к
которому нужно отправить пуллреквест. Всем разную, понятно. Мне вот на
январь Redis.pm назначили :)

-- 
Alex Kapranoff.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150103/4cb733e8/attachment.html>

From denis.fedoseev на gmail.com  Sat Jan  3 11:44:35 2015
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Sat, 3 Jan 2015 23:44:35 +0400
Subject: [Moscow.pm] 2015 CPAN Pull Request Challenge
In-Reply-To: <CAHw_nxjo1Gts1-kNVVigsU712SN5D+nKzRD=cip7vHruxMZ6=g@mail.gmail.com>
References: <CAHw_nxjo1Gts1-kNVVigsU712SN5D+nKzRD=cip7vHruxMZ6=g@mail.gmail.com>
Message-ID: <CALE3dTXpPR19=MVA76ZzOvcA1G6VE5+04Q5swHzzb6+8_boG5w@mail.gmail.com>

Написал ему, поглядю как оно будет :)

3 января 2015 г., 8:38 пользователь Alex Kapranoff <kapranoff на gmail.com>
написал:

> Нил Бауэрс устраивает вот такое:
> http://blogs.perl.org/users/neilb/2014/12/take-the-2015-cpan-pull-request-challenge.html
>
> Вписываетесь, и он раз в месяц присылает ссылку на цпановский модуль, к
> которому нужно отправить пуллреквест. Всем разную, понятно. Мне вот на
> январь Redis.pm назначили :)
>
> --
> Alex Kapranoff.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением, Денис Федосеев
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150103/62ed6df0/attachment.html>

From tolid на tolid.eu.org  Sat Jan  3 11:51:36 2015
From: tolid на tolid.eu.org (Anatoliy Dmytriyev)
Date: Sat, 3 Jan 2015 20:51:36 +0100
Subject: [Moscow.pm] 2015 CPAN Pull Request Challenge
In-Reply-To: <CAHw_nxjo1Gts1-kNVVigsU712SN5D+nKzRD=cip7vHruxMZ6=g@mail.gmail.com>
References: <CAHw_nxjo1Gts1-kNVVigsU712SN5D+nKzRD=cip7vHruxMZ6=g@mail.gmail.com>
Message-ID: <A633AE89-8D6B-423B-A5FD-9ADFB03C3E0E@tolid.eu.org>

IRC  канал #pr-challenge на irc.perl.org <http://irc.perl.org/> , если кому-то интересно, конечно :)

Regards,
Anatoliy



> On 03 Jan 2015, at 06:38, Alex Kapranoff <kapranoff на gmail.com> wrote:
> 
> Нил Бауэрс устраивает вот такое: http://blogs.perl.org/users/neilb/2014/12/take-the-2015-cpan-pull-request-challenge.html <http://blogs.perl.org/users/neilb/2014/12/take-the-2015-cpan-pull-request-challenge.html>
> 
> Вписываетесь, и он раз в месяц присылает ссылку на цпановский модуль, к которому нужно отправить пуллреквест. Всем разную, понятно. Мне вот на январь Redis.pm назначили :)
> 
> -- 
> Alex Kapranoff.
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150103/4bcbcdf9/attachment.html>

From i.petro.77.00 на gmail.com  Tue Jan  6 09:42:16 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Tue, 6 Jan 2015 20:42:16 +0300
Subject: [Moscow.pm] =?utf-8?b?TERBUCwg0LAg0YHRgtC+0LjRgiDQu9C4INC+0LI=?=
	=?utf-8?b?0YfQuNC90LrQsCDQstGL0LTQtdC70LrQuD8=?=
Message-ID: <20150106174216.GK31138@vdsl.uvw.ru>

у нас вебпроект который сейчас включает в себя уже около 4
самостоятельных подпроектов, намечается еще несколько подпроектов.

и вот мы между подпроектами испытываем необходимость в синхронизации
таблиц пользователей, групп, итп.

соответственно что сделано сейчас:

1. сейчас все пользователи заводятся на одном проекте
2. при каждом изменении профиля пользователя (или его появлении)
кладется таск в очередь и профиль воркером реплицируется в другие
проекты


далее поскольку у нас намечаются еще подпроекты, то стали задумываться
о какой-то единой централизованной системе-хранилище пользователей и
настроек.

и вроде бы LDAP специально для этого предназначен.

однако смотрю я на этот LDAP уже более внимательно, тесты какие-то
делаю и пока не могу точно определиться, а стоит ли овчинка выделки
или нет?

1. пользователи (objectClass), предопределенные в LDAP нам не подойдут
полностью, все равно придется свои атрибуты им делать. а ближе
посмотришь, так и лучше, вероятно, полностью с нуля objectClass
описывать (иначе там будет куча лишнего мусора)
2. описание своих сущностей в LDAP оч геморное, плюс на OID надо пусть
и бесплатное но разрешение получать
3. асинхронных коннекторов к LDAP я не нашел

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


кто использует LDAP в вебпроектах, расскажите что вы об этом думаете?

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

в общем смотрю на LDAP и думаю.
толи это нужная штука, толи жутко навороченное бесполезное что-то.

кто что думает?


From denis.fedoseev на gmail.com  Thu Jan  8 13:05:03 2015
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Fri, 9 Jan 2015 01:05:03 +0400
Subject: [Moscow.pm] =?utf-8?b?TERBUCwg0LAg0YHRgtC+0LjRgiDQu9C4INC+0LI=?=
	=?utf-8?b?0YfQuNC90LrQsCDQstGL0LTQtdC70LrQuD8=?=
In-Reply-To: <20150106174216.GK31138@vdsl.uvw.ru>
References: <20150106174216.GK31138@vdsl.uvw.ru>
Message-ID: <CALE3dTXfGhj7GR2gQ+otPu2CNBuaUeGCHa9Ur=o4ZQt34ipfBQ@mail.gmail.com>

У нас LDAP используется только для авторизации под доменной учеткой.

Если этого не требуется - то я бы заюзал какой-нибудь CAS и там все держал.

6 января 2015 г., 20:42 пользователь Ivan Petrov <i.petro.77.00 на gmail.com>
написал:

> у нас вебпроект который сейчас включает в себя уже около 4
> самостоятельных подпроектов, намечается еще несколько подпроектов.
>
> и вот мы между подпроектами испытываем необходимость в синхронизации
> таблиц пользователей, групп, итп.
>
> соответственно что сделано сейчас:
>
> 1. сейчас все пользователи заводятся на одном проекте
> 2. при каждом изменении профиля пользователя (или его появлении)
> кладется таск в очередь и профиль воркером реплицируется в другие
> проекты
>
>
> далее поскольку у нас намечаются еще подпроекты, то стали задумываться
> о какой-то единой централизованной системе-хранилище пользователей и
> настроек.
>
> и вроде бы LDAP специально для этого предназначен.
>
> однако смотрю я на этот LDAP уже более внимательно, тесты какие-то
> делаю и пока не могу точно определиться, а стоит ли овчинка выделки
> или нет?
>
> 1. пользователи (objectClass), предопределенные в LDAP нам не подойдут
> полностью, все равно придется свои атрибуты им делать. а ближе
> посмотришь, так и лучше, вероятно, полностью с нуля objectClass
> описывать (иначе там будет куча лишнего мусора)
> 2. описание своих сущностей в LDAP оч геморное, плюс на OID надо пусть
> и бесплатное но разрешение получать
> 3. асинхронных коннекторов к LDAP я не нашел
>
> с другой стороны профитом может быть какая-нибудь скажем авторизация в
> чем-нибудь. итп
>
>
> кто использует LDAP в вебпроектах, расскажите что вы об этом думаете?
>
> я вот думаю, если сложить юзеров в (скажем) новый тарантул, то с его
> бидирект репликацией он пожалуй может быть поудобнее LDAP потому что
> бидирект, а не мастер-слейв.
> плюс изменять (при необходимости) профили можно будет значительно
> чаще, нежели в LDAP'е (вроде пока такой необходимости не
> просматривается, но все же)
>
> в общем смотрю на LDAP и думаю.
> толи это нужная штука, толи жутко навороченное бесполезное что-то.
>
> кто что думает?
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением, Денис Федосеев
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150109/98446e37/attachment.html>

From mi на ya.ru  Tue Jan 13 10:24:24 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Tue, 13 Jan 2015 21:24:24 +0300
Subject: [Moscow.pm] =?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
	=?koi8-r?b?ztTF0s7F1ME=?=
Message-ID: <952071421173464@web29h.yandex.ru>

Добрый день, Moscow-pm!!
С рождеством и наступающим старым новым годом!!

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

https://github.com/mishin/Datastage-DsxParse/blob/master/scripts/install_perl_module.bat

file_src=File-Slurp-Tiny-0.003.tar.gz
REM set file_src=%1
ptar -x -f %file_src%
perl -e "if ($ARGV[0]=~ /(.*)([.]tar[.]gz|[.]tgz)$/){print $1}" %file_src% > tmpFile
set /p dir_name= < tmpFile
del tmpFile
echo %dir_name%
cd %dir_name%
perl Makefile.PL
dmake
dmake test && dmake install

Так вот в батнике это не работает, останавливаясь после команды ptar
Но, если скопировать и вставить в консоль cmd, то все работает,
как бы сделать так
1) Чтобы это работало
2) Чтобы еще автоматически сканило README
и запускало или 
perl Makefile.PL
или
perl Build

в зависимости от типа установщика

3) И, если, после 
perl Makefile.PL
были бы ошибки в виде зависимостей,
то останавливалось.

спасибо
-- 
С уважением
Николай Мишин


From maxim.vuets на gmail.com  Tue Jan 13 10:36:50 2015
From: maxim.vuets на gmail.com (Maxim Vuets)
Date: Tue, 13 Jan 2015 19:36:50 +0100
Subject: [Moscow.pm] =?utf-8?b?0YPRgdGC0LDQvdC+0LLQutCwINC80L7QtNGD0Ls=?=
	=?utf-8?b?0LXQuSDQv9C+IHdpbiDQsdC10Lcg0LjQvdGC0LXRgNC90LXRgtCw?=
In-Reply-To: <952071421173464@web29h.yandex.ru>
References: <952071421173464@web29h.yandex.ru>
Message-ID: <CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>

Николай,

2015-01-13 19:24 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
> На работе перекты консольный доступ к инету, можно только скачивать с сайта.

Не совсем понятно в чём здесь разница между "консольным доступом" и
"скачиванием с сайта"?

Может у вас http прокси на работе? И браузер о нём знает (например,
https://ru.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol), а
консольному приложению нужно явно об этом сказать. Например, через
переменные окружения http_proxy и т.п.

> Написал следующий батник
>
> https://github.com/mishin/Datastage-DsxParse/blob/master/scripts/install_perl_module.bat
>
> file_src=File-Slurp-Tiny-0.003.tar.gz
...

Я не вникал в логику твоего батника, но может стоит использовать
хороший проверенный cpanm? Он умеет устанавливать дистр из локального
тарбола:

  cpanm ~/dists/MyCompany-Enterprise-1.00.tar.gz   # install from a local file

From mi на ya.ru  Tue Jan 13 11:51:40 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Tue, 13 Jan 2015 22:51:40 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
	=?koi8-r?b?ztTF0s7F1ME=?=
In-Reply-To: <CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
Message-ID: <1131081421178700@web21h.yandex.ru>

Спасибо за совет
1) почему-то cpanm не работает, запущу завтра и покажу ошибки, если они вообще будут
2)в pac файле несколько прокси
и неясно, как указать их все,
видимо, придется поднимать reverse proxy-server
например, http://cntlm.sourceforge.net/
говорят, что еще на реверс Nginx настроить, но я не знаю, как это сделать

13.01.2015, 21:37, "Maxim Vuets" <maxim.vuets на gmail.com>:
> Николай,
>
> 2015-01-13 19:24 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
>>  На работе перекты консольный доступ к инету, можно только скачивать с сайта.
>
> Не совсем понятно в чём здесь разница между "консольным доступом" и
> "скачиванием с сайта"?
>
> Может у вас http прокси на работе? И браузер о нём знает (например,
> https://ru.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol), а
> консольному приложению нужно явно об этом сказать. Например, через
> переменные окружения http_proxy и т.п.
>>  Написал следующий батник
>>
>>  https://github.com/mishin/Datastage-DsxParse/blob/master/scripts/install_perl_module.bat
>>
>>  file_src=File-Slurp-Tiny-0.003.tar.gz
>
> ...
>
> Я не вникал в логику твоего батника, но может стоит использовать
> хороший проверенный cpanm? Он умеет устанавливать дистр из локального
> тарбола:
>
>   cpanm ~/dists/MyCompany-Enterprise-1.00.tar.gz   # install from a local file
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением
Николай Мишин


From maxim.vuets на gmail.com  Tue Jan 13 12:00:39 2015
From: maxim.vuets на gmail.com (Maxim Vuets)
Date: Tue, 13 Jan 2015 21:00:39 +0100
Subject: [Moscow.pm] =?utf-8?b?0YPRgdGC0LDQvdC+0LLQutCwINC80L7QtNGD0Ls=?=
	=?utf-8?b?0LXQuSDQv9C+IHdpbiDQsdC10Lcg0LjQvdGC0LXRgNC90LXRgtCw?=
In-Reply-To: <1131081421178700@web21h.yandex.ru>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
	<1131081421178700@web21h.yandex.ru>
Message-ID: <CAG6DbojPyUZj26scznK9ULUK_8fDd2r7GKfPNK=99bvSAy1YfA@mail.gmail.com>

2015-01-13 20:51 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
> Спасибо за совет
> 1) почему-то cpanm не работает, запущу завтра и покажу ошибки, если они вообще будут

Давай.

> 2)в pac файле несколько прокси
> и неясно, как указать их все,

А все указать и не удастся )-: pac файл это джаваскрипт-подобная
программа, которую исполняет браузер для  маршрутизации твоих запросов
на разные прокси сервера в зависимости от разных параметров (типа
имени хоста или IP адреса).

Но поскольку CPAN находится в пределах одного хоста, ты можешь явно и
конкретно для cpanm устанавливать подходящий http_proxy.

Как альтернатива, сделай себе один раз локальное зеркало при помощи
https://metacpan.org/pod/distribution/CPAN-Mini/bin/minicpan (можно
даже дома на нормальном интернете), и потом ставь пакеты оттуда:
  cpanm --mirror /path/to/the/local/mirror --mirror-only Module::Name

From ivan.kharpalev на gmail.com  Wed Jan 14 01:34:50 2015
From: ivan.kharpalev на gmail.com (=?UTF-8?B?0KXQsNGA0L/QsNC70ZHQsiDQmNCy0LDQvQ==?=)
Date: Wed, 14 Jan 2015 12:34:50 +0300
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
Message-ID: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>

Доброго времени, могучий MoscowPM!

Сейчас пишу небольшой язык.
То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
потренироваться, а потом в C, там типизация, там сложнее).

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

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

В общем тория у меня хромает и очень интересна. Но первым делом практика.
Скажите, чем строить дерево синтаксического разбора?
что-то вроде
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/101f2de4/attachment.html>

From ivan.kharpalev на gmail.com  Wed Jan 14 01:40:22 2015
From: ivan.kharpalev на gmail.com (=?UTF-8?B?0KXQsNGA0L/QsNC70ZHQsiDQmNCy0LDQvQ==?=)
Date: Wed, 14 Jan 2015 12:40:22 +0300
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
In-Reply-To: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
Message-ID: <CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>

что-то вроде "f(1,2) + 3"  в {function=>'+', args=>[{function=>'f',
args=>[1, 2]}, 3]}


14 января 2015 г., 12:34 пользователь Харпалёв Иван <
ivan.kharpalev на gmail.com> написал:

> Доброго времени, могучий MoscowPM!
>
> Сейчас пишу небольшой язык.
> То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
> потренироваться, а потом в C, там типизация, там сложнее).
>
> Когда язык был совсем примитивный, я его парсил регэкспами и по
> рабоче-крестьянски собирал код на целевом языке.
> Но язык подростает. И рефакторить оказывается очень печально.
>
> Как я понимаю весь процесс работы транслятора состоит из стандартных
> стадий, например:
> токенизация
> построение дерева разбора
> сбор кода на целевом языке из полученного описания.
>
> В общем тория у меня хромает и очень интересна. Но первым делом практика.
> Скажите, чем строить дерево синтаксического разбора?
> что-то вроде
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/f32f0f19/attachment.html>

From shafiev на gmail.com  Wed Jan 14 01:46:13 2015
From: shafiev на gmail.com (Naim Sh)
Date: Wed, 14 Jan 2015 13:46:13 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?88nO1MHL08nexdPLycogwc7BzMnaIM7BIFBlcmwu?=
 =?koi8-r?b?IPTSwc7TzNHUz9Iu?=
In-Reply-To: <CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
	<CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
Message-ID: <54B63AE5.3050903@gmail.com>

Иван, вам язык этот для каких целей ?. Может что-то по типу DSL 
подойдет, зачем усложнять что-то ?

On 01/14/2015 01:40 PM, Харпалёв Иван wrote:
> что-то вроде "f(1,2) + 3"  в {function=>'+', args=>[{function=>'f', 
> args=>[1, 2]}, 3]}
>
>
> 14 января 2015 г., 12:34 пользователь Харпалёв Иван 
> <ivan.kharpalev на gmail.com <mailto:ivan.kharpalev на gmail.com>> написал:
>
>     Доброго времени, могучий MoscowPM!
>
>     Сейчас пишу небольшой язык.
>     То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
>     потренироваться, а потом в C, там типизация, там сложнее).
>
>     Когда язык был совсем примитивный, я его парсил регэкспами и по
>     рабоче-крестьянски собирал код на целевом языке.
>     Но язык подростает. И рефакторить оказывается очень печально.
>
>     Как я понимаю весь процесс работы транслятора состоит из
>     стандартных стадий, например:
>     токенизация
>     построение дерева разбора
>     сбор кода на целевом языке из полученного описания.
>
>     В общем тория у меня хромает и очень интересна. Но первым делом
>     практика.
>     Скажите, чем строить дерево синтаксического разбора?
>     что-то вроде
>
>
>
>

-- 
  

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/b8dee9e1/attachment-0001.html>

From khrt на ya.ru  Wed Jan 14 01:46:49 2015
From: khrt на ya.ru (Artur Kh)
Date: Wed, 14 Jan 2015 11:46:49 +0200
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
 =?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+0YAu?=
In-Reply-To: <CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
	<CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
	<CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
Message-ID: <etPan.54b63b27.3d1b58ba.89aa@Kenobi>

Если я правильно понимаю, то возможно вам нужно что-то вроде этого: https://metacpan.org/pod/Marpa::R2

-- 
ak

From: Харпалёв Иван <ivan.kharpalev на gmail.com>
Reply: Moscow.pm group <moscow-pm на pm.org>>
Date: 14 January 2015 at 11:40:40
To: Moscow.pm group <moscow-pm на pm.org>>
Subject:  Re: [Moscow.pm] Синтаксический анализ на Perl. Транслятор.  

что-то вроде "f(1,2) + 3"  в {function=>'+', args=>[{function=>'f', args=>[1, 2]}, 3]}


14 января 2015 г., 12:34 пользователь Харпалёв Иван <ivan.kharpalev на gmail.com> написал:
Доброго времени, могучий MoscowPM!

Сейчас пишу небольшой язык.
То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы потренироваться, а потом в C, там типизация, там сложнее). 

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

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

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

--  
Moscow.pm mailing list
moscow-pm на pm.org | http://moscow.pm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/926ff6a4/attachment.html>

From mail на knutov.com  Wed Jan 14 01:42:15 2015
From: mail на knutov.com (Nick Knutov)
Date: Wed, 14 Jan 2015 14:42:15 +0500
Subject: [Moscow.pm]
 =?koi8-r?b?88nO1MHL08nexdPLycogwc7BzMnaIM7BIFBlcmwu?=
 =?koi8-r?b?IPTSwc7TzNHUz9Iu?=
In-Reply-To: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
Message-ID: <54B639F7.2030509@knutov.com>

Хорошо бы сначала сделать рбнф. А потом искать парсер по рбнф, мне
кажется в cpan-е я их видел. Название сходу не вспомнил.


14.01.2015 14:34, Харпалёв Иван пишет:
> Как я понимаю весь процесс работы транслятора состоит из стандартных
> стадий, например:
> токенизация
> построение дерева разбора
> сбор кода на целевом языке из полученного описания.
> 
> В общем тория у меня хромает и очень интересна. Но первым делом практика.
> Скажите, чем строить дерево синтаксического разбора?
> что-то вроде  

-- 
Best Regards,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130

From aml на rulezz.ru  Wed Jan 14 01:51:16 2015
From: aml на rulezz.ru (Alexander Lourier)
Date: Wed, 14 Jan 2015 09:51:16 +0000
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
	<54B639F7.2030509@knutov.com>
Message-ID: <CANLU1qF0dYJuK7J+KnuxzmFA9uiV81xBSC7WdDCrZKCspgS0eQ@mail.gmail.com>

Есть ещё Parse::Yapp. Нагуглилась сходу ещё страничка в википедии -
http://en.wikipedia.org/wiki/Comparison_of_parser_generators

On Wed Jan 14 2015 at 10:49:21 AM Nick Knutov <mail на knutov.com> wrote:

> Хорошо бы сначала сделать рбнф. А потом искать парсер по рбнф, мне
> кажется в cpan-е я их видел. Название сходу не вспомнил.
>
>
> 14.01.2015 14:34, Харпалёв Иван пишет:
> > Как я понимаю весь процесс работы транслятора состоит из стандартных
> > стадий, например:
> > токенизация
> > построение дерева разбора
> > сбор кода на целевом языке из полученного описания.
> >
> > В общем тория у меня хромает и очень интересна. Но первым делом практика.
> > Скажите, чем строить дерево синтаксического разбора?
> > что-то вроде
>
> --
> Best Regards,
> Nick Knutov
> http://knutov.com
> ICQ: 272873706
> Voice: +7-904-84-23-130
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/745518a9/attachment.html>

From bobrovaksenia на gmail.com  Wed Jan 14 02:14:04 2015
From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=)
Date: Wed, 14 Jan 2015 14:14:04 +0400
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
In-Reply-To: <CANLU1qF0dYJuK7J+KnuxzmFA9uiV81xBSC7WdDCrZKCspgS0eQ@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
	<54B639F7.2030509@knutov.com>
	<CANLU1qF0dYJuK7J+KnuxzmFA9uiV81xBSC7WdDCrZKCspgS0eQ@mail.gmail.com>
Message-ID: <CAO_8yzcYyaBF50W90wpNcNh+6a8SSmwjqLt7RCSbcaDbx=bfqQ@mail.gmail.com>

Можно грамматики Perl 6 использовать

14 января 2015 г., 13:51 пользователь Alexander Lourier <aml на rulezz.ru>
написал:

> Есть ещё Parse::Yapp. Нагуглилась сходу ещё страничка в википедии -
> http://en.wikipedia.org/wiki/Comparison_of_parser_generators
>
>
> On Wed Jan 14 2015 at 10:49:21 AM Nick Knutov <mail на knutov.com> wrote:
>
>> Хорошо бы сначала сделать рбнф. А потом искать парсер по рбнф, мне
>> кажется в cpan-е я их видел. Название сходу не вспомнил.
>>
>>
>> 14.01.2015 14:34, Харпалёв Иван пишет:
>> > Как я понимаю весь процесс работы транслятора состоит из стандартных
>> > стадий, например:
>> > токенизация
>> > построение дерева разбора
>> > сбор кода на целевом языке из полученного описания.
>> >
>> > В общем тория у меня хромает и очень интересна. Но первым делом
>> практика.
>> > Скажите, чем строить дерево синтаксического разбора?
>> > что-то вроде
>>
>> --
>> Best Regards,
>> Nick Knutov
>> http://knutov.com
>> ICQ: 272873706
>> Voice: +7-904-84-23-130
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
Ksenia Bobrova
Senior Perl Developer
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/2cc2ca96/attachment-0001.html>

From chesnokov.ilya на gmail.com  Wed Jan 14 06:17:40 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Wed, 14 Jan 2015 18:17:40 +0400
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
In-Reply-To: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
Message-ID: <CANh0x-y1cDnpWdHrENTkXVwokwsDArnyeh5P811pNU36-HnZFg@mail.gmail.com>

14 января 2015 г., 12:34 пользователь Харпалёв Иван
<ivan.kharpalev на gmail.com> написал:
> Доброго времени, могучий MoscowPM!
>
> Сейчас пишу небольшой язык.
> То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
> потренироваться, а потом в C, там типизация, там сложнее).
>
> Когда язык был совсем примитивный, я его парсил регэкспами и по
> рабоче-крестьянски собирал код на целевом языке.
> Но язык подростает. И рефакторить оказывается очень печально.
>
> Как я понимаю весь процесс работы транслятора состоит из стандартных стадий,
> например:
> токенизация
> построение дерева разбора
> сбор кода на целевом языке из полученного описания.
>
> В общем тория у меня хромает и очень интересна.

По теории советую почитать dragon book.

> Но первым делом практика.

:-)))))))

> Скажите, чем строить дерево синтаксического разбора?
> что-то вроде

Вообще для создания компиляторов есть специальные инструменты.
http://dinosaur.compilertools.net

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards,
Ilya Chesnokov

From 0body0 на rambler.ru  Wed Jan 14 09:19:49 2015
From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=)
Date: Wed, 14 Jan 2015 20:19:49 +0300
Subject: [Moscow.pm]
 =?koi8-r?b?88nO1MHL08nexdPLycogwc7BzMnaIM7BIFBlcmwu?=
 =?koi8-r?b?IPTSwc7TzNHUz9Iu?=
In-Reply-To: <CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
	<CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
Message-ID: <54B6A535.9080702@rambler.ru>

Для того, чтобы использовать инструменты нужна грамматика и однозначная 
+ нужно для любого правила указать, как ты из AST частей правила собираешь
AST целого.
Собственно это и есть семантика.
Есть модули которые сразу могут построить AST в своем виде искать нужно 
в  Parse:: на CPAN

Т.е. самое сложное написать грамматику, которую эти инструменты смогут 
переварить.


14.01.2015 12:40, Харпалёв Иван пишет:
> что-то вроде "f(1,2) + 3"  в {function=>'+', args=>[{function=>'f', 
> args=>[1, 2]}, 3]}
>
>
> 14 января 2015 г., 12:34 пользователь Харпалёв Иван 
> <ivan.kharpalev на gmail.com <mailto:ivan.kharpalev на gmail.com>> написал:
>
>     Доброго времени, могучий MoscowPM!
>
>     Сейчас пишу небольшой язык.
>     То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
>     потренироваться, а потом в C, там типизация, там сложнее).
>
>     Когда язык был совсем примитивный, я его парсил регэкспами и по
>     рабоче-крестьянски собирал код на целевом языке.
>     Но язык подростает. И рефакторить оказывается очень печально.
>
>     Как я понимаю весь процесс работы транслятора состоит из
>     стандартных стадий, например:
>     токенизация
>     построение дерева разбора
>     сбор кода на целевом языке из полученного описания.
>
>     В общем тория у меня хромает и очень интересна. Но первым делом
>     практика.
>     Скажите, чем строить дерево синтаксического разбора?
>     что-то вроде
>
>
>
>

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/55582277/attachment.html>

From 0body0 на rambler.ru  Wed Jan 14 09:53:48 2015
From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=)
Date: Wed, 14 Jan 2015 20:53:48 +0300
Subject: [Moscow.pm]
 =?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
 =?koi8-r?b?ztTF0s7F1ME=?=
In-Reply-To: <952071421173464@web29h.yandex.ru>
References: <952071421173464@web29h.yandex.ru>
Message-ID: <54B6AD2C.2040808@rambler.ru>

13.01.2015 21:24, Nikolay Mishin пишет:
> Добрый день, Moscow-pm!!
> С рождеством и наступающим старым новым годом!!
>
> На работе перекты консольный доступ к инету, можно только скачивать с сайта.
> Написал следующий батник
>
> https://github.com/mishin/Datastage-DsxParse/blob/master/scripts/install_perl_module.bat
>
> file_src=File-Slurp-Tiny-0.003.tar.gz
> REM set file_src=%1
> ptar -x -f %file_src%
> perl -e "if ($ARGV[0]=~ /(.*)([.]tar[.]gz|[.]tgz)$/){print $1}" %file_src% > tmpFile
> set /p dir_name= < tmpFile
> del tmpFile
> echo %dir_name%
> cd %dir_name%
> perl Makefile.PL
> dmake
> dmake test && dmake install
>
> Так вот в батнике это не работает, останавливаясь после команды ptar
> Но, если скопировать и вставить в консоль cmd, то все работает,
> как бы сделать так
Попробуй вместо ptar написать
call ptar,
либо perl { путь к ptar с нужными опциями }

И вообще зачем убогий cmd, если есть очень симпатичный perl?
Там же есть perldoc -f system.
+ будет  быстрее по времени и понятнее для всех нас.

> 1) Чтобы это работало
> 2) Чтобы еще автоматически сканило README
> и запускало или
> perl Makefile.PL
> или
> perl Build
>
> в зависимости от типа установщика
>
> 3) И, если, после
> perl Makefile.PL
> были бы ошибки в виде зависимостей,
> то останавливалось.
>
> спасибо


From pef-secure на yandex.ru  Wed Jan 14 10:37:29 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Wed, 14 Jan 2015 19:37:29 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
Message-ID: <1858407.iHouSzOesI@rawen>

Приветствую!

Есть желание опубликовать на CPAN свой модуль, этакий вариант недо-ORM. Моё 
мнение, что все навороты ORM полезны, пока они упрощают код или дают ещё какие 
плюсы, но если пользование ORM превращается в спорт, то это уже как-то не 
здорово. Прочтение статьи http://pragmaticperl.com/issues/22/pragmaticperl-22-dbixclass.-%D1%81%D0%B1%D0%BE%D1%80%D0%BD%D0%B8%D0%BA-%D1%80%D0%B5%D1%86%D0%B5%D0%BF%D1%82%D0%BE%D0%B2.html
убеждает лично меня в том, что чистый SQL часто сильно проще понимать и 
использовать. Тем не менее, чистый SQL часто не настолько уж "чист": код 
приходится собирать по каким-то внешним условиям, иногда условия становятся 
уже сложно подчинённые, тогда на помощь приходит SQL::Abstract. Постепенно с 
использованием этого модуля у меня родился свой: https://github.com/pef-secure/dbix-struct -- ревью его кода, а так же любым комментариям буду 
признателен. 

Существует _демонстрационный_ проект, в котором этот модуль использован в 
основе операций CRUD: 
https://github.com/pef-secure/pef-front-demo/blob/master/app/Demo/Local/Article.pm . В остальных модулях тоже 
встречается использование, этот самый показательный. Структура демо приложения 
тут: https://github.com/pef-secure/pef-front-demo/blob/master/demo.sql

-- 
PEF Developer

From warstone на list.ru  Thu Jan 15 05:39:40 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Thu, 15 Jan 2015 16:39:40 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1858407.iHouSzOesI@rawen>
References: <1858407.iHouSzOesI@rawen>
Message-ID: <1421329180.20345538@f361.i.mail.ru>

 Вообще есть 2 школы решения проблемы "Как работать с базой":
1) Все в СУБД
2) Все в Программе.

Суть проблемы (Зачем вообще появились ORM монстры типа DBIx::Class, я не говорю об основной причине появления ORM, которая в названии кроется):
СУБД существует много. Если вы пишете код, который вы будете выкладывать в паблик, то он должен мочь работать с несколькими СУБД. Сейчас это PostgreSQL, MySQL, для мажоров - Oracle и более нестандартные СУБД типа MSSQL.
Если перекладывать бизнес логику на СУБД, то для многобазия будет много различного кода для каждой СУБД. Решение - перенести логику в ORM.
Отсюда появляется необходимость иметь возможность писать "триггеры" в объектах ORM.
При всем том, что, казалось-бы, эта возможность - не причина появления ORM, она одна из основных.

Фактически, при всех минусах DBiX::Class (один из которых вы неявно упомянули), она позволяет писать 1 код на много СУБД (с ограничениями, конечно) и переносить бизнес-логику в приложение. Ведь далеко не все СУБД могут из коробки горизонтально масштабироваться. Для MySQL - это, платный, насколько я помню, MySQL Cluster. Для PostgreSQL - это PostgreSQL-XC, который появился очень недавно и пока страшновато его использовать. Для платных СУБД - это "много денег за то что вы это будете использовать". Отсюда - перенос бизнес логики в приложение разгружает СУБД и, если мы говорим о ХайЛоаде, то перенос логики в приложение, позволяет решить проблему хайлоада "докидыванием серверов в стойку", до следующего боттлнека, который опять будет в СУБД, скорее всего, но на других нагрузках. А как известно, при увеличении нагрузки можно найти нестандартное решение, которое опять-таки снимет проблемы боттлнека.

Мои разглагольствования сводятся к двум мыслям:
Голый SQL это плохо, если вы не умеете сахар на приложении.
"ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только вы". У вас оно есть?.. А стоит-ли начинать?

Простите, если вбросил.

Wed, 14 Jan 2015 19:37:29 +0100 от PEF Secure <pef-secure на yandex.ru>:
>Приветствую!
>
>Есть желание опубликовать на CPAN свой модуль, этакий вариант недо-ORM. Моё 
>мнение, что все навороты ORM полезны, пока они упрощают код или дают ещё какие 
>плюсы, но если пользование ORM превращается в спорт, то это уже как-то не 
>здорово. Прочтение статьи  http://pragmaticperl.com/issues/22/pragmaticperl-22-dbixclass.-%D1%81%D0%B1%D0%BE%D1%80%D0%BD%D0%B8%D0%BA-%D1%80%D0%B5%D1%86%D0%B5%D0%BF%D1%82%D0%BE%D0%B2.html
>убеждает лично меня в том, что чистый SQL часто сильно проще понимать и 
>использовать. Тем не менее, чистый SQL часто не настолько уж "чист": код 
>приходится собирать по каким-то внешним условиям, иногда условия становятся 
>уже сложно подчинённые, тогда на помощь приходит SQL::Abstract. Постепенно с 
>использованием этого модуля у меня родился свой:  https://github.com/pef-secure/dbix-struct -- ревью его кода, а так же любым комментариям буду 
>признателен. 
>
>Существует _демонстрационный_ проект, в котором этот модуль использован в 
>основе операций CRUD: 
>https://github.com/pef-secure/pef-front-demo/blob/master/app/Demo/Local/Article.pm . В остальных модулях тоже 
>встречается использование, этот самый показательный. Структура демо приложения 
>тут:  https://github.com/pef-secure/pef-front-demo/blob/master/demo.sql
>
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/1d286825/attachment.html>

From pef-secure на yandex.ru  Thu Jan 15 06:37:11 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Thu, 15 Jan 2015 15:37:11 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421329180.20345538@f361.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
Message-ID: <1607253.JGqLNyoG1C@rawen>

On Thursday, January 15, 2015 16:39:40 Warstone на list.ru wrote:
>  Вообще есть 2 школы решения проблемы "Как работать с базой":
> 1) Все в СУБД
> 2) Все в Программе.
> [...]
> Мои разглагольствования сводятся к двум мыслям:
> Голый SQL это плохо, если вы не умеете сахар на приложении.
> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
> вы". У вас оно есть?.. А стоит-ли начинать?
> 
> Простите, если вбросил.

Моя позиция примерно такая: в реальном приложении, обычно, заранее известно 
что за база будет использоваться, поэтому использование голого SQL вполне 
нормальное явление. Если приложение должно абстрагироваться от базы, то это, 
на мой взгляд, очень специальное приложение, которое должно как-то решить 
вопрос этой абстракции. Когда же мне приходится писать приложение, то база 
известна заранее. Мой модуль старается быть простым и понятным, т.е. это 
попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда 
можно понять во что это развернётся в реальном SQL, кроме того, реальный SQL в 
модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые 
процедуры. Т.е. между 1 и 2 я выбираю середину :)
-- 
PEF Developer

From warstone на list.ru  Thu Jan 15 08:19:25 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Thu, 15 Jan 2015 19:19:25 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1607253.JGqLNyoG1C@rawen>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<1607253.JGqLNyoG1C@rawen>
Message-ID: <1421338765.643061553@f363.i.mail.ru>

 То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из жизни...

Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как будет использоваться пользователь и какие у него будут дополнительные поля определяется приложением.  Ядро заботится о "стандартных" полях. У пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро, зная что серверов много и выбирая какие сервера сейчас активны, на каких из них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто аксессор.

То что я описал - это один из примеров. Возможно не самый лучший. Но он дает представление о том, что ждут большие приложения от ORM'а. Если вы сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и оконными процедурами в результате получив пользователя , получу урл на аватар, прогнанный через мой аксессор, не указывая что это пользователь (то есть ORM сам должен понять - откуда это взялось и что надо сделать с полями), то можно начинать разговаривать про ваш ORM. До этих пор большого смысла использовать его в "продакшене" я не вижу. Проблема в том, что я плохо представляю как этого добиться, не указывая очень много дополнительной информации при каждом запросе. Хотя вру... Для PostgreSQL - знаю как. Но только для него.

Теперь более детально:
> в реальном приложении, обычно, заранее известно 
что за база будет использоваться
Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой вариант немного сбивает с толку, правда?

> поэтому использование голого SQL вполне 
нормальное явление
Это не следует из вышенаписанного по причинам, изложенным выше.

> Если приложение должно абстрагироваться от базы, то это, 
на мой взгляд, очень специальное приложение, которое должно как-то решить 
вопрос этой абстракции.
Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта абстракция и именно об абстракции мы и говорим.

> Мой модуль старается быть простым и понятным, т.е. это 
попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда 
можно понять во что это развернётся в реальном SQL
SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не мыслили так узко.

> Тригеры у меня в БД, если нужны, как и хранимые 
процедуры.
Вы на этапе архитектуры подписались на то, что у вас не будет высокой нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам будет потом больнее это переделывать.

Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. И приложение не проектируется под большую нагрузку. Как следствие такой подход не генерирует большого интереса к себе, так как перл - это веб в большинстве случаев, а веб это хайлоад.
Кстати вы это могли увидеть при первом сообщении в рассылку, которое было где-то месяц назад.

Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Thursday, January 15, 2015 16:39:40  Warstone на list.ru wrote:
>>  Вообще есть 2 школы решения проблемы "Как работать с базой":
>> 1) Все в СУБД
>> 2) Все в Программе.
>> [...]
>> Мои разглагольствования сводятся к двум мыслям:
>> Голый SQL это плохо, если вы не умеете сахар на приложении.
>> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
>> вы". У вас оно есть?.. А стоит-ли начинать?
>> 
>> Простите, если вбросил.
>
>Моя позиция примерно такая: в реальном приложении, обычно, заранее известно 
>что за база будет использоваться, поэтому использование голого SQL вполне 
>нормальное явление. Если приложение должно абстрагироваться от базы, то это, 
>на мой взгляд, очень специальное приложение, которое должно как-то решить 
>вопрос этой абстракции. Когда же мне приходится писать приложение, то база 
>известна заранее. Мой модуль старается быть простым и понятным, т.е. это 
>попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда 
>можно понять во что это развернётся в реальном SQL, кроме того, реальный SQL в 
>модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые 
>процедуры. Т.е. между 1 и 2 я выбираю середину :)
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/095d9fed/attachment-0001.html>

From dsimonov на gmail.com  Thu Jan 15 09:01:11 2015
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Thu, 15 Jan 2015 20:01:11 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421338765.643061553@f363.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<1607253.JGqLNyoG1C@rawen> <1421338765.643061553@f363.i.mail.ru>
Message-ID: <CAL9wMxW=W9EmUNkgBHXcp36xfT6dmU5F3V_6xaQnEwJ-Hs+_1Q@mail.gmail.com>

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

---
Dmitriy V. Simonov

15 января 2015 г., 19:19 пользователь Warstone на list.ru <warstone на list.ru>
написал:

> То есть сложных проектов, где есть "Ядро" и "Приложение", или
> гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот
> вам пример из жизни...
>
> Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как
> будет использоваться пользователь и какие у него будут дополнительные поля
> определяется приложением.  Ядро заботится о "стандартных" полях. У
> пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро,
> зная что серверов много и выбирая какие сервера сейчас активны, на каких из
> них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто
> аксессор.
>
> То что я описал - это один из примеров. Возможно не самый лучший. Но он
> дает представление о том, что ждут большие приложения от ORM'а. Если вы
> сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и
> оконными процедурами в результате получив пользователя , получу урл на
> аватар, прогнанный через мой аксессор, не указывая что это пользователь (то
> есть ORM сам должен понять - откуда это взялось и что надо сделать с
> полями), то можно начинать разговаривать про ваш ORM. До этих пор большого
> смысла использовать его в "продакшене" я не вижу. Проблема в том, что я
> плохо представляю как этого добиться, не указывая очень много
> дополнительной информации при каждом запросе. Хотя вру... Для PostgreSQL -
> знаю как. Но только для него.
>
> Теперь более детально:
> > в реальном приложении, обычно, заранее известно
> что за база будет использоваться
> Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой
> вариант немного сбивает с толку, правда?
>
> > поэтому использование голого SQL вполне
> нормальное явление
> Это не следует из вышенаписанного по причинам, изложенным выше.
>
> > Если приложение должно абстрагироваться от базы, то это,
> на мой взгляд, очень специальное приложение, которое должно как-то решить
> вопрос этой абстракции.
> Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта
> абстракция и именно об абстракции мы и говорим.
>
> > Мой модуль старается быть простым и понятным, т.е. это
> попытка свернуть "голый" SQL в перловые структуры данных и по записи
> всегда
> можно понять во что это развернётся в реальном SQL
> SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не
> мыслили так узко.
>
> > Тригеры у меня в БД, если нужны, как и хранимые
> процедуры.
> Вы на этапе архитектуры подписались на то, что у вас не будет высокой
> нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете
> класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам
> будет потом больнее это переделывать.
>
> Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. И приложение
> не проектируется под большую нагрузку. Как следствие такой подход не
> генерирует большого интереса к себе, так как перл - это веб в большинстве
> случаев, а веб это хайлоад.
> Кстати вы это могли увидеть при первом сообщении в рассылку, которое было
> где-то месяц назад.
>
> Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <pef-secure на yandex.ru>:
>
>   On Thursday, January 15, 2015 16:39:40 Warstone на list.ru
> <https://e.mail.ru/compose?To=Warstone на list.ru> wrote:
> > Вообще есть 2 школы решения проблемы "Как работать с базой":
> > 1) Все в СУБД
> > 2) Все в Программе.
> > [...]
> > Мои разглагольствования сводятся к двум мыслям:
> > Голый SQL это плохо, если вы не умеете сахар на приложении.
> > "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не
> только
> > вы". У вас оно есть?.. А стоит-ли начинать?
> >
> > Простите, если вбросил.
>
> Моя позиция примерно такая: в реальном приложении, обычно, заранее
> известно
> что за база будет использоваться, поэтому использование голого SQL вполне
> нормальное явление. Если приложение должно абстрагироваться от базы, то
> это,
> на мой взгляд, очень специальное приложение, которое должно как-то решить
> вопрос этой абстракции. Когда же мне приходится писать приложение, то база
> известна заранее. Мой модуль старается быть простым и понятным, т.е. это
> попытка свернуть "голый" SQL в перловые структуры данных и по записи
> всегда
> можно понять во что это развернётся в реальном SQL, кроме того, реальный
> SQL в
> модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые
> процедуры. Т.е. между 1 и 2 я выбираю середину :)
> --
> PEF Developer
> --
> Moscow.pm mailing list
> moscow-pm на pm.org <https://e.mail.ru/compose?To=moscow%2dpm на pm.org> |
> http://moscow.pm.org
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/a61e8236/attachment.html>

From pef-secure на yandex.ru  Thu Jan 15 09:16:21 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Thu, 15 Jan 2015 18:16:21 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421338765.643061553@f363.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1607253.JGqLNyoG1C@rawen>
	<1421338765.643061553@f363.i.mail.ru>
Message-ID: <5989421.toM4NsiATy@rawen>

On Thursday, January 15, 2015 19:19:25 Warstone на list.ru wrote:
>  То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных,
> сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из
> жизни...

Придумывание чужих профилей самостоятельно -- это такое завуалированное 
оскорбление? 

> Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как
> будет использоваться пользователь и какие у него будут дополнительные поля
> определяется приложением.  Ядро заботится о "стандартных" полях. У
> пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро,
> зная что серверов много и выбирая какие сервера сейчас активны, на каких из
> них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто
> аксессор.

Мне не удаётся увидеть в этом проблему, связанную с обсуждаемым модулем. Речь 
идёт о доступе к базе данных. Какие поля есть у пользователя -- определяется 
динамически в момент коннекта к базе или вызовом метода populate(), который 
заново может перечитать структуру базы.

> То что я описал - это один из примеров. Возможно не самый лучший. Но он дает
> представление о том, что ждут большие приложения от ORM'а. Если вы сможете
> поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и
> оконными процедурами в результате получив пользователя , получу урл на
> аватар, прогнанный через мой аксессор, не указывая что это пользователь (то
> есть ORM сам должен понять - откуда это взялось и что надо сделать с
> полями), то можно начинать разговаривать про ваш ORM.

В моём представлении, тут уже есть некоторая смесь понятий ORM и логики ядра. 
Ядро спросили URL, оно ответило. Откуда оно его взяло, какими модулями 
пользовалось -- совсем не важно. Для ядра у меня есть другой фреймворк, в 
котором _возможно_ использовать DBIx::Struct, он (другой фреймворк) не готов к 
публичному релизу и я его пока не намереваюсь обсуждать. 

В самом первом сообщении я сразу определил, что модуль не пытается строить из 
себя настоящую ORM, но обладает её некоторыми чертами. Все "сложные" случаи 
оставлены "настоящему" SQL, который, на мой взгляд, куда понятнее и проще 
поддаётся отладке.

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

Я не знаю что у Вас там за приложение, но, видимо, что-то мега-крутое. В своих 
проектах последние 5 лет стараюсь использовать только PostgreSQL, чему и рад, 
столкновения с MySQL часто вызывают у меня недоумение. Например, рекурсивный 
запрос для построения дерева комментариев к статье.

> Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой
> вариант немного сбивает с толку, правда?

Правда. Никто не застрахован от "странных" случаев. Мне приходилось работать 
одновременно с PostgreSQL и MySQL, но вторая база только для "специальных" 
случаев, там можно просто DBIx::Connector как есть использовать.

> Это не следует из вышенаписанного по причинам, изложенным выше.

Это моя точка зрения. Если база известна, то "диалект" SQL уже не является 
препятствием. Проблема, когда пишется что-то обобщённое, что должно учитывать 
возможные диалекты.

> Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта
> абстракция и именно об абстракции мы и говорим.

Целей у неё, как я понимаю, две: концептуально не использовать SQL, перейдя на 
"родные" структуры языка; абстрагироваться от БД, что может дать некоторую 
свободу приложению, а может и наоборот, внести ограничения.

> SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не
> мыслили так узко.

Ну ясно дело, узко -- это мой удел, я понял.

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

Чем больше нагрузка на базу, тем сильнее надо думать о кешировании данных. Это 
выходит за рамки модуля. Хранимые процедуры, наоборот, за счёт более близкого 
доступа к данным дают выше пропускную способность базы, с тригерами тоже надо 
быть аккуратными, но в правильных случаях они не мешают и помогают сохранить 
логическую стркутуру базы.

Вобщем, про боттлнек в базе _тут_ не понял.

> Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. 

Так, давайте по порядку, что же мне нужно. Я согласен, что _глобально_, я даже 
слова такого знать не хотел бы. Но постоянное писание одних и тех же 
простейших 

$row = $dbh->selectrow_hashref('select * from user where login = ? and 
password = ?', undef, $login, $password) 

за много лет задолбало. В итоге оно постепенно вылилось в то, что при коннекте 
получается структура таблиц, между ними строятся связи, по этим связям можно 
создавать упрощённые запросы:

$row = one_row([article => -join => 'author'],{id_article => $id_article}) 

в объекте $row будет разбирая на поля выборка 

select * from article join author on (article.id_author = author.id) where 
id_article = ?

Получилось у меня привести это к чисто перловым структурам данных? Мне 
кажется, вполне. 

Абстрагировался ли я от конкретной БД? Ну почти, реальные тесты делал только 
на PostgreSQL, предусмотрел пару моментов по майскл и склайт, но их не 
тестировал за неимением. 

Стало ли это выглядеть лучше, чем было? Ну мне так больше нравится. 

> И приложение не проектируется под большую нагрузку. 

Максимально допустимая нагрузка определяется множеством факторов. Как по мне, 
модуль DBIx::Struct вряд ли будет тормозом. Даже скорее наоборот, расход 
памяти для хранения данных ниже, чем когда строка результата выборки 
представлена хешем. Грубое тестирование не выявило разницы с чистым DBI.

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

Имею иное мнение :)
-- 
PEF Developer

From pef-secure на yandex.ru  Thu Jan 15 09:17:46 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Thu, 15 Jan 2015 18:17:46 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CAL9wMxW=W9EmUNkgBHXcp36xfT6dmU5F3V_6xaQnEwJ-Hs+_1Q@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421338765.643061553@f363.i.mail.ru>
	<CAL9wMxW=W9EmUNkgBHXcp36xfT6dmU5F3V_6xaQnEwJ-Hs+_1Q@mail.gmail.com>
Message-ID: <7195892.Ex3L2tan1d@rawen>

On Thursday, January 15, 2015 20:01:11 Dmitry Simonov wrote:
> Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента,
> когда на сайте есть хоть какой-то биллинг. До этого момента не
> заморачивайтесь и используйте, что хотите.

Биллинг не гарантирует хайлоада :)
-- 
PEF Developer

From warstone на list.ru  Thu Jan 15 10:46:04 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Thu, 15 Jan 2015 21:46:04 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <5989421.toM4NsiATy@rawen>
References: <1858407.iHouSzOesI@rawen> <1421338765.643061553@f363.i.mail.ru>
	<5989421.toM4NsiATy@rawen>
Message-ID: <1421347564.904617394@f397.i.mail.ru>

 Thu, 15 Jan 2015 18:16:21 +0100 от PEF Secure <pef-secure на yandex.ru>:
>Придумывание чужих профилей самостоятельно -- это такое завуалированное 
>оскорбление? 
Нет, конечно, что-вы.
>Мне не удаётся увидеть в этом проблему, связанную с обсуждаемым модулем. Речь 
>идёт о доступе к базе данных. Какие поля есть у пользователя -- определяется 
>динамически в момент коннекта к базе или вызовом метода populate(), который 
>заново может перечитать структуру базы. Ну просто обычно это делается так: UserRS->search({id => $uid})->single->avatar_url
При всем при этом в User.pm (которое схема таблицы User) лежит что-то такое:
sub avatar_url {
    ...
   my $candidates = _get_best_candidates_as_array;
    return  $candidates->[random(scalar @$candidates)]; 
}
То есть вызов отдает разные данные, при том что само поле содержит только ссылку на картинку (которая не всегда должна совпадать с именем пользователя или его id).
>В моём представлении, тут уже есть некоторая смесь понятий ORM и логики ядра. 
>Ядро спросили URL, оно ответило. Откуда оно его взяло, какими модулями 
>пользовалось -- совсем не важно. Для ядра у меня есть другой фреймворк, в 
>котором _возможно_ использовать DBIx::Struct, он (другой фреймворк) не готов к 
>публичному релизу и я его пока не намереваюсь обсуждать.  Только для приложения - пользователь - это данные. И с этими данным оно пойдет в модель, которая ORM (зачем 100500 модулей городить? Больше пакетов богу пакетов?)
>В самом первом сообщении я сразу определил, что модуль не пытается строить из 
>себя настоящую ORM, но обладает её некоторыми чертами. Все "сложные" случаи 
>оставлены "настоящему" SQL, который, на мой взгляд, куда понятнее и проще 
>поддаётся отладке.
Сложные варианты действительно проще делать на чистом SQL'е понимая чем это грозит. Допустим аналитики у нас имеют доступ к базе и сами строят SQL запросы. На мой взгляд - сложный вариант, это когда PostgreSQL включает GEQO.
>Правда. Никто не застрахован от "странных" случаев. Мне приходилось работать 
>одновременно с PostgreSQL и MySQL, но вторая база только для "специальных" 
>случаев, там можно просто DBIx::Connector как есть использовать. Действительно в данном случае так оказалось быстрее. Использовать MySQL как Key-Value (Холивар монгистов, давайте опустим, не об этом)
>Ну ясно дело, узко -- это мой удел, я понял. Да не в этом дело, право слово... В SQL::Abstract думали еще и о том, что это должно выполняться на как можно большем количестве диалектов, допустим., а потому некоторые конструкции получаются странные.
>Чем больше нагрузка на базу, тем сильнее надо думать о кешировании данных. Это 
>выходит за рамки модуля. Хранимые процедуры, наоборот, за счёт более близкого 
>доступа к данным дают выше пропускную способность базы, с тригерами тоже надо 
>быть аккуратными, но в правильных случаях они не мешают и помогают сохранить 
>логическую стркутуру базы. Ну... А за рамки ORM не выходит, ИМХО. И кешировать не все и не всегда получается. Хранимки дают большую скорость очень редко. У Pg в 99,9% узкое место - скорость доступа к диску.
>Вобщем, про боттлнек в базе _тут_ не понял. База одна и она медленная. Беков много и пофиг что они медленные, их много. Так понятнее?
>Так, давайте по порядку, что же мне нужно. Я согласен, что _глобально_, я даже 
>слова такого знать не хотел бы. Но постоянное писание одних и тех же 
>простейших 
>
>$row = $dbh->selectrow_hashref('select * from user where login = ? and 
>password = ?', undef, $login, $password) 
>
>за много лет задолбало. В итоге оно постепенно вылилось в то, что при коннекте 
>получается структура таблиц, между ними строятся связи, по этим связям можно 
>создавать упрощённые запросы:
>
>$row = one_row([article => -join => 'author'],{id_article => $id_article}) 
>
>в объекте $row будет разбирая на поля выборка 
>
>select * from article join author on (article.id_author = author.id) where 
>id_article = ?
>
>Получилось у меня привести это к чисто перловым структурам данных? Мне 
>кажется, вполне. 
>
>Абстрагировался ли я от конкретной БД? Ну почти, реальные тесты делал только 
>на PostgreSQL, предусмотрел пару моментов по майскл и склайт, но их не 
>тестировал за неимением. 
>
>Стало ли это выглядеть лучше, чем было? Ну мне так больше нравится. 
Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это удовлетворит, так как это оно и есть.
>Максимально допустимая нагрузка определяется множеством факторов. Как по мне, 
>модуль DBIx::Struct вряд ли будет тормозом. Даже скорее наоборот, расход 
>памяти для хранения данных ниже, чем когда строка результата выборки 
>представлена хешем. Грубое тестирование не выявило разницы с чистым DBI. Я говорил это в разрезе "Не используйте хранимки, переносите логику на приложение. Беков много, база одна".

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/283dcee3/attachment-0001.html>

From i.petro.77.00 на gmail.com  Thu Jan 15 11:30:28 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Thu, 15 Jan 2015 22:30:28 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <1858407.iHouSzOesI@rawen>
References: <1858407.iHouSzOesI@rawen>
Message-ID: <20150115193028.GL6552@vdsl.uvw.ru>

Мы кстати пришли к тому же: чистый SQL лучше автоматических
генераторов SQL.

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

соответственно первый и самый распространенный пример - генерация
HTML.
далее мы взяли и запилили модуль который делает embedded-perl в SQL
запросе, сделали синтаксис совместимым с Mojo и далее стало очень
удобно (см. DBIx::DR).

SELECT
    *
FROM
    table
JOIN
    table2 ON col1 = col2
...
WHERE
    group_id = 10

    % if ($filter{from_date}) {
        AND date >= <%= $filter{from_date} %>
    % }

    % if ($filter{name}) {
        AND name ilike <%= '%' . $name . '%' %>
    % }

и тому подобное.

у нас проект около 3 млн строк сейчас, очень круто получается по MVC
парадигме:

lib/Controller/* - модули контроллеров
lib/Model/* - модули моделей
templates/* - темплейты
sql/* - sql'и

SQL-и вынесли в отдельные файлы и теперь во первых их редактим
отдельным редактором с подсветкой синтаксиса
во вторых они лежат в таком же дереве как и модели/итп.

PS: я написал XS'ную реализацию embedded-perl парсера, но пока не
опубликовал. все хочу DBIx::DR на него перевести, заодно плагин
сделать для Mojo на нем же. будет быстрый темплейт.
руки пока не доходят допилить

From i.petro.77.00 на gmail.com  Thu Jan 15 11:44:16 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Thu, 15 Jan 2015 22:44:16 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <1421329180.20345538@f361.i.mail.ru>
References: <1858407.iHouSzOesI@rawen>
 <1421329180.20345538@f361.i.mail.ru>
Message-ID: <20150115194416.GM6552@vdsl.uvw.ru>


> Мои разглагольствования сводятся к двум мыслям:
> Голый SQL это плохо, если вы не умеете сахар на приложении.

мне кажется голый SQL это единственный способ строить нормальные
хайлоады.
как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
ОЧЕНЬ интимные.

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

далее, раз уж эту тему обсуждать далее.
я считаю что попытка делать приложение "переносимым между БД" ничего
удобного кроме тестов не дает.
ну только что тесты вы сможете делать на SQLLite, тогда как на боевом
у вас будет скажем Pg/MySQL.
но вопрос поднять тестовую Pg базу для проекта - несложный и я не вижу
в этом преимущества.

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

SELECT
    *
FROM
    table1
JOIN
    table2
JOIN
    table3
WHERE
    table1.col = 10

до сих пор многие базы не научились нормально во всех случаях
оптимизировать.
то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
JOIN на все остальное додумается далеко не каждый планировщик. причем
те планировщики которые умеют до такого додуматься, додумаются не
всегда.
то есть в постгре это все сразу улетает в секцию WITH. запросы
начинают летать, а код становится недоступным для SQLLite/MySQL.

в общем надо делать выбор БД на этапе ДО начала проектирования.
удержать проект переносимым не получится.

потому что даже в ORM используя скажем Pg, вы рано или поздно сядете
за книжечку и построите скажем GIN индекс на нужную вам выборку.
(мы вот пришли даже к тому что собственные варианты GIST пишем).
и как только вы это сделаете проект перестанет быть переносимым.

а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
нагрузкой

> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
> вы". У вас оно есть?.. А стоит-ли начинать?

мы запилили целый проект на DBIx::Class. очень упорно убили год и
где-то 500К строк кода.
чтобы понять что ORM - зло.
чистый SQL конечно не сахар, но лучшего ничего нет.

From pef-secure на yandex.ru  Thu Jan 15 12:22:06 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Thu, 15 Jan 2015 21:22:06 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421347564.904617394@f397.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <5989421.toM4NsiATy@rawen>
	<1421347564.904617394@f397.i.mail.ru>
Message-ID: <2714461.A8G7u388Lt@rawen>

On Thursday, January 15, 2015 21:46:04 Warstone на list.ru wrote:
> Ну просто
> обычно это делается так: UserRS->search({id => $uid})->single->avatar_url
> При всем при этом в User.pm (которое схема таблицы User) лежит что-то такое:
> sub avatar_url {
>     ...
>    my $candidates = _get_best_candidates_as_array;
>     return  $candidates->[random(scalar @$candidates)];
> }
> То есть вызов отдает разные данные, при том что само поле содержит только
> ссылку на картинку (которая не всегда должна совпадать с именем
> пользователя или его id).

В моём варианте можно унаследовать класс DBC::User и сделать то же самое. 
Пользовался подобным несколько раз, но, в основном, "всё иначе" и объекты БД 
не привожу к ООП (смеси данных из БД и произвольных методов), а определяю 
отдельный API работы с ядром, а что вернёт хендлер метода API уже дело 
хендлера.

>  Только для приложения - пользователь - это данные. И с этими
> данным оно пойдет в модель, которая ORM (зачем 100500 модулей городить?
> Больше пакетов богу пакетов?) 

Ни разу не наблюдал особой проблемы с количеством модулей. Ах, да, я ж, 
наверное, "не писал сложных проекто никогда". Возможно.

> Сложные варианты действительно проще делать на чистом SQL'е понимая чем это
> грозит. 

Да ничем, кроме некоторой негибкости кода, по моему мнению.

> Действительно в данном случае так оказалось быстрее.
> Использовать MySQL как Key-Value

Ой. И никакой ORM? 

> В SQL::Abstract думали еще и о том, что это должно
> выполняться на как можно большем количестве диалектов, допустим.

Ну да, поэтому работу с offset/limit решили не делать. SQL::Abstract. как ни 
странно, ничего не хочет знать про БД, он именно абстрактный "вычислитель 
запросов".


> Ну... А за рамки ORM не выходит, ИМХО. И кешировать не все
> и не всегда получается. Хранимки дают большую скорость очень редко. 

Зависит от ситуации. Хранимки выполняют две функции: поддержание некоторого 
API БД и исключение лишнего трафика клиент-сервер. Если сам запрос достаточно 
тяжёлый и лишнего трафика сервер-клиент нет, то хранимка особого выигрыша в 
производительности не даст, но некоторые алгоритмы там всё-таки разумнее 
реализовывать. Но, собственно, кому я рассказываю.

> База одна и она медленная. Беков много и пофиг что они
> медленные, их много. Так понятнее? 

Нет, так как раз запутаннее. Сначала надо всё-таки полную структуру 
подразумеваемого приложения понять. Фронт запрашивает ядро. Ядро обращается к 
бекенду. Бекенд обращается к базе. При этом объекты ORM выступают в роли 
бекенда (или ядра?). Я запутался.

Я признаюсь, ни разу не писал, когда бекендов много. Или когда баз данных 
много. У меня были проекты, когда несколько фронтов<->ядро+база, а проблема 
производительности базы решалась ростом RAM и переходом на SSD. Но, я 
чувствую, что это просто мелочь в сравнении с настоящим хайлоадом.

> Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это
> удовлетворит, так как это оно и есть.

Смотрел когда-то давно. Ну, допустим, я повторил даже чью-то функциональность. 
Но, как мне кажется, я сделал это удобнее. И зачем мне отказываться от того, 
что я написал в пользу других модулей? Например, в моём модуле есть следующий 
сахар (цитата из документации)

Допустим, у нас есть следующие таблицы:

employer:
    id_employer,
    name
  
 employee:
    id_employee,
    id_employer references employer (id_employer),
    id_employee_invited_by
    name

 alter table employee add constraint fk_employee_employee 
     foreign key (id_employee_invited_by) references employee (id_employee);

Тогда можно использовать следующие выражения:

 my $employee = one_row("employee", {name => 'John'});
 my $employer = $employee->Employer;

Последняя строка автоматически по ссылке из объекта $employee выберет объект 
$employer.

my $referenced_by = $employee->refEmployeeInvitedBys;

Эта строка выберет всех "employee", которые были рекомндованы конкретным  
$employee.

my $robert_associates = $employee->Employer->refEmployees(name => 'Robert');

А эта строка выберет коллег этого $employee, у кого имя 'Robert'.

Личто мне этот сахар удобен и экономит код. На счёт эффективности не вижу тут 
проблем так же.

-- 
PEF Developer

From warstone на list.ru  Thu Jan 15 12:35:21 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Thu, 15 Jan 2015 23:35:21 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <20150115194416.GM6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
Message-ID: <1421354121.133391093@f398.i.mail.ru>


>а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
>нагрузкой
Эм... 4 года полета... DAU 700K, правда у нас очень специфичная нагрузка. Чтения и записи в базу очень мало. BTREE есть, GIN/GIST негде применять... Сейчас вот JSONB появился, может начнем.
>мы запилили целый проект на DBIx::Class. очень упорно убили год и
>где-то 500К строк кода.
>чтобы понять что ORM - зло. ORM зло, но оно неизбежно, особенно если вы хотите переносимость кода (1 ядро, несколько проектов).
Вообще нам не хватает от DBIx::Class скорости и асинхронности. С первым боремся. Со вторым - там все печально.
>чистый SQL конечно не сахар, но лучшего ничего нет. Не совсем согласен. Тут просто разные подходы. Вы пилите конкретику, мы разрабатываем... ну можно сказать Фреимворк и на нем пилим проекты. В вашем подходе это разумно. При нашем - не совсем.
С точки зрения разумности подходов - они оба имеют прав на жизнь, конечно.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/c130c336/attachment.html>

From pef-secure на yandex.ru  Thu Jan 15 12:52:21 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Thu, 15 Jan 2015 21:52:21 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421354121.133391093@f398.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
Message-ID: <3943791.F3nr7uCsHe@rawen>

On Thursday, January 15, 2015 23:35:21 Warstone на list.ru wrote:
> >а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
> >нагрузкой
> 
> Эм... 4 года полета... DAU 700K, правда у нас очень специфичная нагрузка.
> Чтения и записи в базу очень мало. BTREE есть, GIN/GIST негде применять...
> Сейчас вот JSONB появился, может начнем.
> >мы запилили целый проект на DBIx::Class. очень упорно убили год и
> >где-то 500К строк кода.
> >чтобы понять что ORM - зло. ORM зло, но оно неизбежно, особенно если вы
> >хотите переносимость кода (1 ядро, несколько проектов).
> Вообще нам не хватает от DBIx::Class скорости и асинхронности. С первым
> боремся. Со вторым - там все печально.
> >чистый SQL конечно не сахар, но лучшего ничего нет. Не совсем согласен. Тут
> >просто разные подходы. Вы пилите конкретику, мы разрабатываем... ну можно
> >сказать Фреимворк и на нем пилим проекты. В вашем подходе это разумно. При
> >нашем - не совсем.
> С точки зрения разумности подходов - они оба имеют прав на жизнь, конечно.

Есть просьба вернуться к изначальной теме -- про DBIx::Struct. 
-- 
PEF Developer

From warstone на list.ru  Thu Jan 15 13:16:40 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 00:16:40 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <2714461.A8G7u388Lt@rawen>
References: <1858407.iHouSzOesI@rawen> <1421347564.904617394@f397.i.mail.ru>
	<2714461.A8G7u388Lt@rawen>
Message-ID: <1421356600.176900395@f374.i.mail.ru>

 В моём варианте можно унаследовать класс DBC::User и сделать то же самое. 
>Пользовался подобным несколько раз, но, в основном, "всё иначе" и объекты БД 
>не привожу к ООП (смеси данных из БД и произвольных методов), а определяю 
>отдельный API работы с ядром, а что вернёт хендлер метода API уже дело 
>хендлера. Согласен, неудачный пример. Ну да, надеюсь простите, если не буду более удачного показывать... Под рукой ничего такого не находится с ходу. Хотя-я-я... Да вот пожалуйста: поле active_status - является-ли пользователь активным или нет. Раньше было поле, которое должно было апдейтиться  по крону и на его основе перебирались таблички на быструю и медленную (для Пг это разумно, чтобы больше вероятность попадания была). Рассчитывали запилить такой подход, потом оказалось что понятие активности для бизнеса и для базы - разные вещи. active_status стал геттером, который проверяет конфиг и last_visit. Приложения (которых много и разрабатываются несколькими командами) не заметили этого и продолжили жить, как есть. Таких примеров... не то, чтобы много, но они есть. Это конечно, не панацея, но в некоторых случаях помогает.
>Ни разу не наблюдал особой проблемы с количеством модулей. Ах, да, я ж, 
>наверное, "не писал сложных проекто никогда". Возможно.
Хватит прибедняться... Я вот тут недавно заметил, что на текущей архитектуре мне надо создать 4 или 5 файлов, чтобы реализовать ту или иную фичу... Сейчас с этим боремся.
>Да ничем, кроме некоторой негибкости кода, по моему мнению. Первое что приходит в голову - вы теряете возможность кастомных типов данных. Допустим у нас есть специальный тип, который сериализуется в JSON. В схеме я ему пишу тип: MyCoolSpecialType, а во время создания объекта прописываю inflate и deflate процедуры. После чего ...->single->cool_column->make_cool_method_on_my_cool_type. Наверняка еще 100500 маленьких приятностей, которые называются сахаром.
>Ой. И никакой ORM? 
Подколка засчитана... Свой ORM из 15-20 строчек не считая сервисной рутины.
>
>> В SQL::Abstract думали еще и о том, что это должно
>> выполняться на как можно большем количестве диалектов, допустим.
>
>Ну да, поэтому работу с offset/limit решили не делать. SQL::Abstract. как ни 
>странно, ничего не хочет знать про БД, он именно абстрактный "вычислитель 
>запросов". SQL::Abstract::More , если вам надо больше. ))
>Зависит от ситуации. Хранимки выполняют две функции: поддержание некоторого 
>API БД и исключение лишнего трафика клиент-сервер. Если сам запрос достаточно 
>тяжёлый и лишнего трафика сервер-клиент нет, то хранимка особого выигрыша в 
>производительности не даст, но некоторые алгоритмы там всё-таки разумнее 
>реализовывать. Но, собственно, кому я рассказываю.
У нас философия такая:
Все что надо сделать с базой, чтобы база работала быстрее - делается внутри базы... То есть теоретически можно и RULE на VIEW навесить и сказать что это таблица и прочее. Но только до тех пор, пока это надо и потому что по другому никак, но надо. Остальное - в приложении.
>Нет, так как раз запутаннее. Сначала надо всё-таки полную структуру 
>подразумеваемого приложения понять. Фронт запрашивает ядро. Ядро обращается к 
>бекенду. Бекенд обращается к базе. При этом объекты ORM выступают в роли 
>бекенда (или ядра?). Я запутался. Front-end(браузер) запрашивает страницу, nginx через proxy-pass отдает запрос на один из back-end'ов, которое есть наше приложение. Ядро - это набор библиотек, подключенных туда-же.
>Я признаюсь, ни разу не писал, когда бекендов много. Или когда баз данных 
>много. У меня были проекты, когда несколько фронтов<->ядро+база, а проблема 
>производительности базы решалась ростом RAM и переходом на SSD. Но, я 
>чувствую, что это просто мелочь в сравнении с настоящим хайлоадом.
Не совсем... Просто настоящий, как вы говорите, хайлоад начинается тогда, когда больше RAM и больше SSD не дают эффекта или не выгодны, так как нагрузка может кратно превысить сервер... Тут есть несколько вариантов, они, в общем-то, описаны в интернете (но по задворками и равномерным слоем) и никакого ноу-хау там нету. Просто подходы меняются и все.
>
>> Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это
>> удовлетворит, так как это оно и есть.
>
>Смотрел когда-то давно. Ну, допустим, я повторил даже чью-то функциональность. 
>Но, как мне кажется, я сделал это удобнее. И зачем мне отказываться от того, 
>что я написал в пользу других модулей? Например, в моём модуле есть следующий 
>сахар (цитата из документации)
>
>Допустим, у нас есть следующие таблицы:
>
>employer:
>    id_employer,
>    name
>
> employee:
>    id_employee,
>    id_employer references employer (id_employer),
>    id_employee_invited_by
>    name
>
> alter table employee add constraint fk_employee_employee 
>     foreign key (id_employee_invited_by) references employee (id_employee);
>
>Тогда можно использовать следующие выражения:
>
> my $employee = one_row("employee", {name => 'John'});
> my $employer = $employee->Employer;
>
>Последняя строка автоматически по ссылке из объекта $employee выберет объект 
>$employer.
>
>my $referenced_by = $employee->refEmployeeInvitedBys;
>
>Эта строка выберет всех "employee", которые были рекомндованы конкретным 
>$employee.
>
>my $robert_associates = $employee->Employer->refEmployees(name => 'Robert');
>
>А эта строка выберет коллег этого $employee, у кого имя 'Robert'.
>
>Личто мне этот сахар удобен и экономит код. На счёт эффективности не вижу тут 
>проблем так же. refEmployeeInvitedBys и refEmployees из коробки в том-же DBIx::Class'е нету, но... Как вы не видите, что пишете свой DBIx::Class, который в последствии разрастется хуже оригинального?.. Если видите, так может сразу взять лучшее оттуда и добавить недостающие фишки... Причем DBIx::Class тот-же прекрасно сабклассится (если понимать идеологию mro::c3)

Ну хорошо... вы хотели некоторых отзывов...
Открываем DBIx::Struct.pm:
%driver_pk_insert - и там код как строка... Зачем?..
Идем дальше...
sub make_object_new - Бешеная кодогенерация . Вы про наследование слышали? Делаете класс-аксессоры, а потом тупо:

sub create_new_package {
  my ($self, $class_name, $config) = @_;
  my $isa = \@{"${class_name}::ISA"};
  push(@$isa, "DBIx::Struct::Base");
  $class_name->_initialize($config); # Или не делаете, если инициализировать нечего или сами забивайте руками эти аксессоры.
}

Нет, все... Я на куче кодогенерации выпал в осадок.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/e366a674/attachment-0001.html>

From i.petro.77.00 на gmail.com  Thu Jan 15 14:37:59 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 01:37:59 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICAgREJJeDo6U3RydWN0?=
In-Reply-To: <1421354121.133391093@f398.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
Message-ID: <20150115223759.GN6552@vdsl.uvw.ru>

> Не совсем согласен. Тут просто разные подходы. Вы пилите конкретику, мы
> разрабатываем... ну можно сказать Фреимворк и на нем пилим проекты. В вашем
> подходе это разумно. При нашем - не совсем.
> С точки зрения разумности подходов - они оба имеют прав на жизнь, конечно.

у Вас видимо все проекты друг на друга похожи, раз можно запилить
фреймворк ажно под тип данных.

From pef-secure на yandex.ru  Thu Jan 15 15:12:41 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 00:12:41 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421356600.176900395@f374.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <2714461.A8G7u388Lt@rawen>
	<1421356600.176900395@f374.i.mail.ru>
Message-ID: <2167719.CUnOryv6hc@rawen>

On Friday, January 16, 2015 00:16:40 Warstone на list.ru wrote:
> Нет, все... Я на куче кодогенерации выпал в осадок.

В ней весь смысл. Данные объекта-строки хранятся массивом, конкретные поля 
знают свои индексы в массиве. Первичные ключи знают свои индексы в этом 
массиве.
-- 
PEF Developer

From pef-secure на yandex.ru  Thu Jan 15 15:19:36 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 00:19:36 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421356600.176900395@f374.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <2714461.A8G7u388Lt@rawen>
	<1421356600.176900395@f374.i.mail.ru>
Message-ID: <2164471.WIYC34W15E@rawen>

On Friday, January 16, 2015 00:16:40 Warstone на list.ru wrote:
> Согласен, неудачный пример. Ну да, надеюсь простите,
> >если не буду более удачного показывать... Под рукой ничего такого не
> >находится с ходу. Хотя-я-я... Да вот пожалуйста: поле active_status -
> >является-ли пользователь активным или нет. Раньше было поле, которое
> >должно было апдейтиться  по крону и на его основе перебирались таблички на
> >быструю и медленную (для Пг это разумно, чтобы больше вероятность
> >попадания была). Рассчитывали запилить такой подход, потом оказалось что
> >понятие активности для бизнеса и для базы - разные вещи. active_status
> >стал геттером, который проверяет конфиг и last_visit. Приложения (которых
> >много и разрабатываются несколькими командами) не заметили этого и
> >продолжили жить, как есть. 

Я не понял как этот пример отменяет возможность сделать подкласс, в котором 
переопределить метод как хочется.

> Front-end(браузер) запрашивает страницу,

Я называл фронтом уже сам нжинкс/приложение фроненда, которое принимает 
запрос. Шаблоны же не бекендом генерятся.

> Как вы не видите, что пишете свой
> >DBIx::Class, который в последствии разрастется хуже оригинального?.. 

Ну, будет альтернатива DBIx::Class, это плохо? Пока что мне кажется хорошо.

-- 
PEF Developer

From alexclear на gmail.com  Thu Jan 15 15:26:04 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 03:26:04 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421329180.20345538@f361.i.mail.ru>
References: <1858407.iHouSzOesI@rawen>
	<1421329180.20345538@f361.i.mail.ru>
Message-ID: <CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>

2015-01-15 16:39 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
> Вообще есть 2 школы решения проблемы "Как работать с базой":
> 1) Все в СУБД
> 2) Все в Программе.
>
> Суть проблемы (Зачем вообще появились ORM монстры типа DBIx::Class, я не
> говорю об основной причине появления ORM, которая в названии кроется):
> СУБД существует много. Если вы пишете код, который вы будете выкладывать в
> паблик, то он должен мочь работать с несколькими СУБД. Сейчас это
> PostgreSQL, MySQL, для мажоров - Oracle и более нестандартные СУБД типа
> MSSQL.
> Если перекладывать бизнес логику на СУБД, то для многобазия будет много
> различного кода для каждой СУБД. Решение - перенести логику в ORM.
> Отсюда появляется необходимость иметь возможность писать "триггеры" в
> объектах ORM.
> При всем том, что, казалось-бы, эта возможность - не причина появления ORM,
> она одна из основных.
>
> Фактически, при всех минусах DBiX::Class (один из которых вы неявно
> упомянули), она позволяет писать 1 код на много СУБД (с ограничениями,
> конечно) и переносить бизнес-логику в приложение. Ведь далеко не все СУБД
> могут из коробки горизонтально масштабироваться.

Огласите весь список тех реляционных СУБД, которые могут.


> Для MySQL - это, платный,
> насколько я помню, MySQL Cluster.

MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.

> Для PostgreSQL - это PostgreSQL-XC,
> который появился очень недавно и пока страшновато его использовать. Для
> платных СУБД - это "много денег за то что вы это будете использовать".
> Отсюда - перенос бизнес логики в приложение разгружает СУБД

То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
не останется?
O_O

> и, если мы
> говорим о ХайЛоаде, то перенос логики в приложение, позволяет решить
> проблему хайлоада "докидыванием серверов в стойку", до следующего боттлнека,
> который опять будет в СУБД, скорее всего, но на других нагрузках.

Очень интересно.
То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы
перенесли ее на приложение, после чего уже на других нагрузках
боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы
просто не взяли, я не знаю, master-slave репликацию? CPU-bound
приложения легко масштабируются на любом конце многозвенной
архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на
других нагрузках, а не на этих же? Нет никаких оснований так полагать.

--
SY,
Alex


> А как
> известно, при увеличении нагрузки можно найти нестандартное решение, которое
> опять-таки снимет проблемы боттлнека.
>
> Мои разглагольствования сводятся к двум мыслям:
> Голый SQL это плохо, если вы не умеете сахар на приложении.
> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
> вы". У вас оно есть?.. А стоит-ли начинать?
>
> Простите, если вбросил.
>
> Wed, 14 Jan 2015 19:37:29 +0100 от PEF Secure <pef-secure на yandex.ru>:
>
> Приветствую!
>
> Есть желание опубликовать на CPAN свой модуль, этакий вариант недо-ORM. Моё
> мнение, что все навороты ORM полезны, пока они упрощают код или дают ещё
> какие
> плюсы, но если пользование ORM превращается в спорт, то это уже как-то не
> здорово. Прочтение статьи
> http://pragmaticperl.com/issues/22/pragmaticperl-22-dbixclass.-%D1%81%D0%B1%D0%BE%D1%80%D0%BD%D0%B8%D0%BA-%D1%80%D0%B5%D1%86%D0%B5%D0%BF%D1%82%D0%BE%D0%B2.html
> убеждает лично меня в том, что чистый SQL часто сильно проще понимать и
> использовать. Тем не менее, чистый SQL часто не настолько уж "чист": код
> приходится собирать по каким-то внешним условиям, иногда условия становятся
> уже сложно подчинённые, тогда на помощь приходит SQL::Abstract. Постепенно с
> использованием этого модуля у меня родился свой:
> https://github.com/pef-secure/dbix-struct -- ревью его кода, а так же любым
> комментариям буду
> признателен.
>
> Существует _демонстрационный_ проект, в котором этот модуль использован в
> основе операций CRUD:
> https://github.com/pef-secure/pef-front-demo/blob/master/app/Demo/Local/Article.pm
> . В остальных модулях тоже
> встречается использование, этот самый показательный. Структура демо
> приложения
> тут: https://github.com/pef-secure/pef-front-demo/blob/master/demo.sql
>
> --
> PEF Developer
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From alexclear на gmail.com  Thu Jan 15 15:28:38 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 03:28:38 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CAL9wMxW=W9EmUNkgBHXcp36xfT6dmU5F3V_6xaQnEwJ-Hs+_1Q@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<1607253.JGqLNyoG1C@rawen> <1421338765.643061553@f363.i.mail.ru>
	<CAL9wMxW=W9EmUNkgBHXcp36xfT6dmU5F3V_6xaQnEwJ-Hs+_1Q@mail.gmail.com>
Message-ID: <CA+kq2xueZy=1Wh4gffQZrm5joqB7vw2CwaZqeBCURRsKKM=JFQ@mail.gmail.com>

2015-01-15 20:01 GMT+03:00 Dmitry Simonov <dsimonov на gmail.com>:
> Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента,
> когда на сайте есть хоть какой-то биллинг. До этого момента не
> заморачивайтесь и используйте, что хотите.

Какой хитрый ответ!
Два раза прочитал, но так и не понял, когда есть биллинг - ORM все еще
нужен, или уже нет? :)

--
SY,
Alex



>
> ---
> Dmitriy V. Simonov
>
> 15 января 2015 г., 19:19 пользователь Warstone на list.ru <warstone на list.ru>
> написал:
>
>> То есть сложных проектов, где есть "Ядро" и "Приложение", или
>> гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот
>> вам пример из жизни...
>>
>> Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как
>> будет использоваться пользователь и какие у него будут дополнительные поля
>> определяется приложением.  Ядро заботится о "стандартных" полях. У
>> пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро,
>> зная что серверов много и выбирая какие сервера сейчас активны, на каких из
>> них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто
>> аксессор.
>>
>> То что я описал - это один из примеров. Возможно не самый лучший. Но он
>> дает представление о том, что ждут большие приложения от ORM'а. Если вы
>> сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и
>> оконными процедурами в результате получив пользователя , получу урл на
>> аватар, прогнанный через мой аксессор, не указывая что это пользователь (то
>> есть ORM сам должен понять - откуда это взялось и что надо сделать с
>> полями), то можно начинать разговаривать про ваш ORM. До этих пор большого
>> смысла использовать его в "продакшене" я не вижу. Проблема в том, что я
>> плохо представляю как этого добиться, не указывая очень много дополнительной
>> информации при каждом запросе. Хотя вру... Для PostgreSQL - знаю как. Но
>> только для него.
>>
>> Теперь более детально:
>> > в реальном приложении, обычно, заранее известно
>> что за база будет использоваться
>> Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой
>> вариант немного сбивает с толку, правда?
>>
>> > поэтому использование голого SQL вполне
>> нормальное явление
>> Это не следует из вышенаписанного по причинам, изложенным выше.
>>
>> > Если приложение должно абстрагироваться от базы, то это,
>> на мой взгляд, очень специальное приложение, которое должно как-то решить
>> вопрос этой абстракции.
>> Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта
>> абстракция и именно об абстракции мы и говорим.
>>
>> > Мой модуль старается быть простым и понятным, т.е. это
>> попытка свернуть "голый" SQL в перловые структуры данных и по записи
>> всегда
>> можно понять во что это развернётся в реальном SQL
>> SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не
>> мыслили так узко.
>>
>> > Тригеры у меня в БД, если нужны, как и хранимые
>> процедуры.
>> Вы на этапе архитектуры подписались на то, что у вас не будет высокой
>> нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете
>> класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам
>> будет потом больнее это переделывать.
>>
>> Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. И приложение
>> не проектируется под большую нагрузку. Как следствие такой подход не
>> генерирует большого интереса к себе, так как перл - это веб в большинстве
>> случаев, а веб это хайлоад.
>> Кстати вы это могли увидеть при первом сообщении в рассылку, которое было
>> где-то месяц назад.
>>
>> Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <pef-secure на yandex.ru>:
>>
>> On Thursday, January 15, 2015 16:39:40 Warstone на list.ru wrote:
>> > Вообще есть 2 школы решения проблемы "Как работать с базой":
>> > 1) Все в СУБД
>> > 2) Все в Программе.
>> > [...]
>> > Мои разглагольствования сводятся к двум мыслям:
>> > Голый SQL это плохо, если вы не умеете сахар на приложении.
>> > "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не
>> > только
>> > вы". У вас оно есть?.. А стоит-ли начинать?
>> >
>> > Простите, если вбросил.
>>
>> Моя позиция примерно такая: в реальном приложении, обычно, заранее
>> известно
>> что за база будет использоваться, поэтому использование голого SQL вполне
>> нормальное явление. Если приложение должно абстрагироваться от базы, то
>> это,
>> на мой взгляд, очень специальное приложение, которое должно как-то решить
>> вопрос этой абстракции. Когда же мне приходится писать приложение, то база
>> известна заранее. Мой модуль старается быть простым и понятным, т.е. это
>> попытка свернуть "голый" SQL в перловые структуры данных и по записи
>> всегда
>> можно понять во что это развернётся в реальном SQL, кроме того, реальный
>> SQL в
>> модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые
>> процедуры. Т.е. между 1 и 2 я выбираю середину :)
>> --
>> PEF Developer
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From alexclear на gmail.com  Thu Jan 15 15:40:11 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 03:40:11 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <20150115194416.GM6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
Message-ID: <CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>

2015-01-15 22:44 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> Мои разглагольствования сводятся к двум мыслям:
>> Голый SQL это плохо, если вы не умеете сахар на приложении.
>
> мне кажется голый SQL это единственный способ строить нормальные
> хайлоады.
> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
> ОЧЕНЬ интимные.
>
> то есть например если у вас пользователи, то вам пойдет практически
> любой вид шардинга, а если у вас таблицы с логами действий тех же
> пользователей и вам надо выводить списки, то уже далеко не любой
> подойдет.

Хранить time-series data в RDBMS, да еще и с шардами - какая свежая
идея, однако!


>
> далее, раз уж эту тему обсуждать далее.
> я считаю что попытка делать приложение "переносимым между БД" ничего
> удобного кроме тестов не дает.
> ну только что тесты вы сможете делать на SQLLite, тогда как на боевом
> у вас будет скажем Pg/MySQL.
> но вопрос поднять тестовую Pg базу для проекта - несложный и я не вижу
> в этом преимущества.
>
> а далее начинается.
> ну MySQL, как БД - полное говно, это понятно.
> если говорить о Pg, то там например полно синтаксиса который можно
> использовать для оптимизации скорости работы.
>
> SELECT
>     *
> FROM
>     table1
> JOIN
>     table2
> JOIN
>     table3
> WHERE
>     table1.col = 10
>
> до сих пор многие базы не научились нормально во всех случаях
> оптимизировать.
> то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
> JOIN на все остальное додумается далеко не каждый планировщик. причем
> те планировщики которые умеют до такого додуматься, додумаются не
> всегда.

Силюсь понять, что имеется в виду.
Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть
какие-то планировщики, которые сначала сделают декартово произведение,
а потом только наложат условие? ДА ЛАДНО? Где это такая радость?
Нет - MySQL может неправильно выбрать driving table в существенно
более сложном, чем показано, запросе - но для таких случаев в нем есть
хинты. Или имеется в виду тот факт, что MySQL не умеет hash join, а
только nested loops? Ну да, не умеет. Но полное говно он не поэтому.


> то есть в постгре это все сразу улетает в секцию WITH. запросы
> начинают летать, а код становится недоступным для SQLLite/MySQL.
>
> в общем надо делать выбор БД на этапе ДО начала проектирования.
> удержать проект переносимым не получится.
>
> потому что даже в ORM используя скажем Pg, вы рано или поздно сядете
> за книжечку и построите скажем GIN индекс на нужную вам выборку.
> (мы вот пришли даже к тому что собственные варианты GIST пишем).
> и как только вы это сделаете проект перестанет быть переносимым.
>
> а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
> нагрузкой
>
>> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
>> вы". У вас оно есть?.. А стоит-ли начинать?
>
> мы запилили целый проект на DBIx::Class. очень упорно убили год и
> где-то 500К строк кода.
> чтобы понять что ORM - зло.
> чистый SQL конечно не сахар, но лучшего ничего нет.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From alexclear на gmail.com  Thu Jan 15 15:43:33 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 03:43:33 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421354121.133391093@f398.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
Message-ID: <CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>

2015-01-15 23:35 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
>
> а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
> нагрузкой
>
> Эм... 4 года полета... DAU 700K, правда у нас очень специфичная нагрузка.
> Чтения и записи в базу очень мало. BTREE есть, GIN/GIST негде применять...
> Сейчас вот JSONB появился, может начнем.
>
> мы запилили целый проект на DBIx::Class. очень упорно убили год и
> где-то 500К строк кода.
> чтобы понять что ORM - зло.
>
> ORM зло

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

--
SY,
Alex



> , но оно неизбежно, особенно если вы хотите переносимость кода (1
> ядро, несколько проектов).
> Вообще нам не хватает от DBIx::Class скорости и асинхронности. С первым
> боремся. Со вторым - там все печально.
>
> чистый SQL конечно не сахар, но лучшего ничего нет.
>
> Не совсем согласен. Тут просто разные подходы. Вы пилите конкретику, мы
> разрабатываем... ну можно сказать Фреимворк и на нем пилим проекты. В вашем
> подходе это разумно. При нашем - не совсем.
> С точки зрения разумности подходов - они оба имеют прав на жизнь, конечно.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From onokonem на gmail.com  Thu Jan 15 16:08:00 2015
From: onokonem на gmail.com (Daniel Podolsky)
Date: Fri, 16 Jan 2015 04:08:00 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
	<CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>
Message-ID: <CAKaHDOF0uQbTBRmk1h-tovLkuJM8+0_iKxOB3ok4UZCSWdqxsA@mail.gmail.com>

> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
Если ты пишешь для конкретной базы - ты пишешь для конкретной базы.

Понимаешь, почему мускул не умеет hash join, а постгрес не умеет
использовать индексы при select distinct и еще миллион всего.

Знаешь, как это обойти, а то и использовать под свои нужды.

Если ты пишешь для  ORM - ты пишешь для ORM. Что именно этот ORM
генерит, как это все будет работать с большими данными - ты не в
курсе.

Ладно бы это. Писуя очередную миграцию для  БД ты не знаешь, как оно
отразится на производительности всего того кода, что у тебя уже есть.

Внятно?

From alexclear на gmail.com  Thu Jan 15 16:14:07 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 04:14:07 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CAKaHDOF0uQbTBRmk1h-tovLkuJM8+0_iKxOB3ok4UZCSWdqxsA@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
	<CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>
	<CAKaHDOF0uQbTBRmk1h-tovLkuJM8+0_iKxOB3ok4UZCSWdqxsA@mail.gmail.com>
Message-ID: <CA+kq2xt8Yt-9459PQSGnqsQXGg5UCAO5ccWpMeiGiwfMRBfSyw@mail.gmail.com>

2015-01-16 3:08 GMT+03:00 Daniel Podolsky <onokonem на gmail.com>:
>> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
> Если ты пишешь для конкретной базы - ты пишешь для конкретной базы.
>
> Понимаешь, почему мускул не умеет hash join, а постгрес не умеет
> использовать индексы при select distinct и еще миллион всего.

Это два разных утверждения, и из первого не следует второе. Бывает,
что человек пишет для Postgres, потому что ему пацаны на раене
сказали, что Postgres чиста круче. А чем круче, и что там за цифирки у
него в конфиге - он не ведает. Бэкграунд райтер? Какой еще бэкграунд
райтер? Буфера сортировки? Какой такой еще сортировки? План запроса?
О, нет!

>
> Знаешь, как это обойти, а то и использовать под свои нужды.
>
> Если ты пишешь для  ORM - ты пишешь для ORM. Что именно этот ORM
> генерит, как это все будет работать с большими данными - ты не в
> курсе.

Ну - почти любой ORM общего применения умеет позволять исполнить raw
SQL (те, которые не умеют, надо отправить обратно авторам с
рекламацией).

>
> Ладно бы это. Писуя очередную миграцию для  БД ты не знаешь, как оно
> отразится на производительности всего того кода, что у тебя уже есть.

Так это вон и с обычным SQL ровно так же.
В базах данных живут гномики и все вот это вот.

--
SY,
Alex


>
> Внятно?
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From warstone на list.ru  Thu Jan 15 16:47:47 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 03:47:47 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>
Message-ID: <1421369267.490056532@f27.i.mail.ru>


>Огласите весь список тех реляционных СУБД, которые могут. Здравствуй добрый тролль
>MySQL Cluster - это средство горизонтального масштабирования? Ооооокей. Могу ошибаться. Для меня MySQL синоним каки. Исторически. Его можно использовать, но ты кровью расписываешься что ты понимаешь что делаешь.
>> Для PostgreSQL - это PostgreSQL-XC,
>> который появился очень недавно и пока страшновато его использовать. Для
>> платных СУБД - это "много денег за то что вы это будете использовать".
>> Отсюда - перенос бизнес логики в приложение разгружает СУБД
>
>То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
>не останется?
>O_O Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы между "разгружает" и "не останется" нету?
>Очень интересно.
>То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы
>перенесли ее на приложение, после чего уже на других нагрузках
>боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы
>просто не взяли, я не знаю, master-slave репликацию? CPU-bound
>приложения легко масштабируются на любом конце многозвенной
>архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на
>других нагрузках, а не на этих же? Нет никаких оснований так полагать. 1) И что вам даст эта репликация?.. Данные в одном месте, а CPU баунд может получиться при записи. Тогда уже PostgreSQL-XC, со всеми его приколами, типа 2х фазного коммита и умножения количества серверов на 2,5 при адекатном развертывании (Мы тут сейчас считаем что кроме PostgreSQL СУБД нету. У него это написано вот тут:  https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207 хотя у MySQL известно). При всем при этом стоимость масштабирования приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера (1 под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало 4 (2 под приложение, 2 под СУБД).
2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно спокойно добавить +1 сервер, а не +2,5 из текста выше. Причем в случае с СУБД масштабированием у вас время нулевой транзакции увеличивается, то есть сервер начинает отвечать чуть медленнее.
> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
>Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют
>совершенно разный смысл, но часто - одинаковые последствия. Есть
>случаи, когда ORM - безусловное зло, но это граничные случаи.
>И, конечно, ORM большое зло, когда разработчики из-за предоставляемых
>абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами профессионалы.
Потому что из 2го часто следует 1е. Однако согласитесь, что 1го это не отменяет в ряде задач.

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/d2358aea/attachment.html>

From alexclear на gmail.com  Thu Jan 15 17:09:45 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 05:09:45 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421369267.490056532@f27.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>
	<1421369267.490056532@f27.i.mail.ru>
Message-ID: <CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>

2015-01-16 3:47 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
>
> Огласите весь список тех реляционных СУБД, которые могут.
>
> Здравствуй добрый тролль

Вечер в хату!

>
> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.
>
> Могу ошибаться. Для меня MySQL синоним каки.

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

> Исторически. Его можно
> использовать, но ты кровью расписываешься что ты понимаешь что делаешь.

А PostgreSQL, стало быть, можно использовать, не понимая? Ну да,
многие так и поступают.

>
>> Для PostgreSQL - это PostgreSQL-XC,
>> который появился очень недавно и пока страшновато его использовать. Для
>> платных СУБД - это "много денег за то что вы это будете использовать".
>> Отсюда - перенос бизнес логики в приложение разгружает СУБД
>
> То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
> не останется?
> O_O
>
> Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы
> между "разгружает" и "не останется" нету?

Мне, собственно, интересно, как можно вынести CPU-bound задачи с СУБД
(которая у всех нормальных людей обычно IO-bound) и что-то на ней
разгрузить. Я, правда, достаточно повидал CPU-bound архитектурных
решений на реляционных СУБД, но там вынос логики в приложение ничего
не изменил бы - там надо линейкой по рукам фигачить.

>
> Очень интересно.
> То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы
> перенесли ее на приложение, после чего уже на других нагрузках
> боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы
> просто не взяли, я не знаю, master-slave репликацию? CPU-bound
> приложения легко масштабируются на любом конце многозвенной
> архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на
> других нагрузках, а не на этих же? Нет никаких оснований так полагать.
>
> 1) И что вам даст эта репликация?.. Данные в одном месте, а CPU баунд может
> получиться при записи.

Хотел бы я это увидеть!
Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в
том числе - потому что у него репликация CPU-bound при определенных
условиях).
Вообще, конечно, не имея синхронной репликации в кластере СУБД
разносить хранимки по разным нодам - это чисто теоретическая идея. Я
бы так делать не стал. С другой стороны - что такое можно делать в
хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.
Конвертировать видео? Биткойны майнить?

> Тогда уже PostgreSQL-XC, со всеми его приколами, типа
> 2х фазного коммита и умножения количества серверов на 2,5 при адекатном
> развертывании (Мы тут сейчас считаем что кроме PostgreSQL СУБД нету.

Приколы PostgreSQL-XC связаны с тем, что там синхронная репликация еще
и с масштабированием записи.
До масштабирования записи мы пока не добрались, у нас CPU-bound
задача, синхронностью репликации предлагаю тоже пренебречь.

> У него
> это написано вот тут:
> https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207
> хотя у MySQL известно). При всем при этом стоимость масштабирования
> приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера (1
> под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало 4
> (2 под приложение, 2 под СУБД).
> 2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно
> спокойно добавить +1 сервер, а не +2,5 из текста выше.

Боюсь, в тексте выше не использовалась строгая типизация - это вы там
яблоки с совами сравнили.

> Причем в случае с
> СУБД масштабированием у вас время нулевой транзакции увеличивается, то есть
> сервер начинает отвечать чуть медленнее.
>
>  Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
> Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют
> совершенно разный смысл, но часто - одинаковые последствия. Есть
> случаи, когда ORM - безусловное зло, но это граничные случаи.
> И, конечно, ORM большое зло, когда разработчики из-за предоставляемых
> абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами
> профессионалы.
>
> Потому что из 2го часто следует 1е.

Если люди не умеют использовать ORM, они себе чем угодно башку отстрелят.
Что и происходит сплошь и рядом.
Утверждение "мы откажемся от ORM прямо на этапе проектирования и
поэтому заживем" - лютая чушь.
Некоторые ORM отлично заменяют горе-рукоделов, для того и придуманы.
Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).

--
SY,
Alex


> Однако согласитесь, что 1го это не
> отменяет в ряде задач.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From warstone на list.ru  Thu Jan 15 17:18:39 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 04:18:39 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <2167719.CUnOryv6hc@rawen>
References: <1858407.iHouSzOesI@rawen> <1421356600.176900395@f374.i.mail.ru>
	<2167719.CUnOryv6hc@rawen>
Message-ID: <1421371119.474965071@f133.i.mail.ru>


То есть вместо того чтобы использовать Class::XSAccessor который оптимизирован по самое не балуйся вы используете eval, тем самым:
1) Раздуваете working-set приложения
2) Теряете возможность рантаймого похачить базовый класс или сделать инъектирование к наследование, если уж вы не хотите mro::c3 с next::method пользовать и таким образом давать возможность пользовать миксины, если ОЧЕНЬ надо.
3) Теряете читабельность кода
4) Выигрываете мизерный процент на обращении к хешу.

И вы считаете это плюсом? Если вы где-то используете кодогеренацию вы что-то делаете не так.

---

Вы деретесь за сабы типа:  ref ${ft} s ? Так генерите их в базе с использованием какого-нибудь initialize метода так-же как и сейчас или заюзайте автолоад. А еще лучше посмотрите как это делает DBIx::Class.

---

Вам надо еще? Хорошо... Почему вы в коде где-то пользуете ссылку на CORE, а где-то нет? Вы в своем модуле, что defined и exists перебили? Или... Зачем это вообще? Причем в части коде есть CORE:: перед ref, в части нету...

---

Вы проверяете во время setup_row есть-ли у вас уже такой класс, только вот вы получаете имя класса и таблицу, а отдаете только имя класса... То есть я никоем образом не узнаю, что я 2й раз пытаюсь вызвать генерацию класса, и фиг с ним, если на одной и той-же таблице, а если на разных? Где там проверка на название таблицы и гроханье с большим ором, если она не такая. Где варн, если таблица та-же? Или это тренд такой "Если программист чего-то ступил, давайте ему максимально осложним поиск баги"?


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

Fri, 16 Jan 2015 00:12:41 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Friday, January 16, 2015 00:16:40  Warstone на list.ru wrote:
>> Нет, все... Я на куче кодогенерации выпал в осадок.
>
>В ней весь смысл. Данные объекта-строки хранятся массивом, конкретные поля 
>знают свои индексы в массиве. Первичные ключи знают свои индексы в этом 
>массиве.
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/40dd90f1/attachment.html>

From warstone на list.ru  Thu Jan 15 17:30:17 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 04:30:17 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421369267.490056532@f27.i.mail.ru>
	<CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
Message-ID: <1421371817.935978423@f133.i.mail.ru>

 Fri, 16 Jan 2015 05:09:45 +0400 от Alex Chistyakov <alexclear на gmail.com>:
>2015-01-16 3:47 GMT+03:00  Warstone на list.ru < warstone на list.ru >:
>>
>> Огласите весь список тех реляционных СУБД, которые могут.
>>
>> Здравствуй добрый тролль
>
>Вечер в хату!
>
>>
>> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.
>>
>> Могу ошибаться. Для меня MySQL синоним каки.
>
>Ну а я больше люблю зеленый чай, чем черный.
>Такая у нас примерно будет техническая беседа. Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут дурак полностью и он гениален.
>> Исторически. Его можно
>> использовать, но ты кровью расписываешься что ты понимаешь что делаешь.
>
>А PostgreSQL, стало быть, можно использовать, не понимая? Ну да,
>многие так и поступают.
>
>>
>>> Для PostgreSQL - это PostgreSQL-XC,
>>> который появился очень недавно и пока страшновато его использовать. Для
>>> платных СУБД - это "много денег за то что вы это будете использовать".
>>> Отсюда - перенос бизнес логики в приложение разгружает СУБД
>>
>> То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
>> не останется?
>> O_O
>>
>> Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы
>> между "разгружает" и "не останется" нету?
>
>Мне, собственно, интересно, как можно вынести CPU-bound задачи с СУБД
>(которая у всех нормальных людей обычно IO-bound) и что-то на ней
>разгрузить. Я, правда, достаточно повидал CPU-bound архитектурных
>решений на реляционных СУБД, но там вынос логики в приложение ничего
>не изменил бы - там надо линейкой по рукам фигачить. Есть еще вариант с wait-bound... Я такое тоже видал. Это когда в PL/Perlu удаленный хост через LWP дергают.
Оно еще бывает Lock-Bound. Когда вы вроде-бы считаете не много, но за счет того, что в это время транзакция открыта - локи на таблицы висят красиво... Похлеще чем IDLE IN TRANSACTION, если вы понимаете...
Причем зачастую, это рождается так: Была хранимка, а вот тут кровь из носу нужны вон те данные. А переделывает не автор. И все... Пипец.
>Хотел бы я это увидеть!
>Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в
>том числе - потому что у него репликация CPU-bound при определенных
>условиях).
>Вообще, конечно, не имея синхронной репликации в кластере СУБД
>разносить хранимки по разным нодам - это чисто теоретическая идея. Я
>бы так делать не стал. С другой стороны - что такое можно делать в
>хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.
>Конвертировать видео? Биткойны майнить? Выше частичный ответ. И да, давайте не о MySQL.
>> У него
>> это написано вот тут:
>>  https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207
>> хотя у MySQL известно). При всем при этом стоимость масштабирования
>> приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера (1
>> под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало 4
>> (2 под приложение, 2 под СУБД).
>> 2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно
>> спокойно добавить +1 сервер, а не +2,5 из текста выше.
>
>Боюсь, в тексте выше не использовалась строгая типизация - это вы там
>яблоки с совами сравнили. Это больше манагерский подход использовался "Сколько мне это будет в баксах / количествах серверов". Естественно дьявол - в деталях.
>> Причем в случае с
>> СУБД масштабированием у вас время нулевой транзакции увеличивается, то есть
>> сервер начинает отвечать чуть медленнее.
>>
>>  Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
>> Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют
>> совершенно разный смысл, но часто - одинаковые последствия. Есть
>> случаи, когда ORM - безусловное зло, но это граничные случаи.
>> И, конечно, ORM большое зло, когда разработчики из-за предоставляемых
>> абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами
>> профессионалы.
>>
>> Потому что из 2го часто следует 1е.
>
>Если люди не умеют использовать ORM, они себе чем угодно башку отстрелят.
>Что и происходит сплошь и рядом.
>Утверждение "мы откажемся от ORM прямо на этапе проектирования и
>поэтому заживем" - лютая чушь.
>Некоторые ORM отлично заменяют горе-рукоделов, для того и придуманы.
>Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).
Вот тут я не могу не согласиться. ORM - зло, отсутствие ORM - тоже. Жизнь - боль. Голактека жестока... Впрочем это уже из другой оперы.

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/fa727720/attachment-0001.html>

From alexclear на gmail.com  Thu Jan 15 23:33:04 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 11:33:04 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421371817.935978423@f133.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421369267.490056532@f27.i.mail.ru>
	<CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
	<1421371817.935978423@f133.i.mail.ru>
Message-ID: <CA+kq2xvwZJGR4Xbdf62V0-Xg-R+K-HeJx7QrZXq+Ee0b9foJ-w@mail.gmail.com>

2015-01-16 4:30 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
> Fri, 16 Jan 2015 05:09:45 +0400 от Alex Chistyakov <alexclear на gmail.com>:
>
> 2015-01-16 3:47 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
>>
>> Огласите весь список тех реляционных СУБД, которые могут.
>>
>> Здравствуй добрый тролль
>
> Вечер в хату!
>
>>
>> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.
>>
>> Могу ошибаться. Для меня MySQL синоним каки.
>
> Ну а я больше люблю зеленый чай, чем черный.
> Такая у нас примерно будет техническая беседа.
>
> Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут
> дурак полностью и он гениален.

Похоже на то, что он и правда гениален. Я почитал синопсис и тест и
остался в тяжком недоумении.
Как мне вытащить структуру объектов (то, что в старом добром SQL
называется JOIN)? Где lazy loading? Где двухуровневый кэш?
Где генерация структуры таблиц по метаописанию на XML?
Нет, это не тот ORM, к которому я привык. Фиг бы с ним, с XML - но
зачем нужен конструктор запросов к единственной таблице?
Идти читать сам код я теперь немного боюсь - при таком радикальном
подходе к постановке задачи, кто его знает, что ждет в реализации...

--
SY,
Alex


>
>> Исторически. Его можно
>> использовать, но ты кровью расписываешься что ты понимаешь что делаешь.
>
> А PostgreSQL, стало быть, можно использовать, не понимая? Ну да,
> многие так и поступают.
>
>>
>>> Для PostgreSQL - это PostgreSQL-XC,
>>> который появился очень недавно и пока страшновато его использовать. Для
>>> платных СУБД - это "много денег за то что вы это будете использовать".
>>> Отсюда - перенос бизнес логики в приложение разгружает СУБД
>>
>> То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
>> не останется?
>> O_O
>>
>> Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы
>> между "разгружает" и "не останется" нету?
>
> Мне, собственно, интересно, как можно вынести CPU-bound задачи с СУБД
> (которая у всех нормальных людей обычно IO-bound) и что-то на ней
> разгрузить. Я, правда, достаточно повидал CPU-bound архитектурных
> решений на реляционных СУБД, но там вынос логики в приложение ничего
> не изменил бы - там надо линейкой по рукам фигачить.
>
> Есть еще вариант с wait-bound... Я такое тоже видал. Это когда в PL/Perlu
> удаленный хост через LWP дергают.
> Оно еще бывает Lock-Bound. Когда вы вроде-бы считаете не много, но за счет
> того, что в это время транзакция открыта - локи на таблицы висят красиво...
> Похлеще чем IDLE IN TRANSACTION, если вы понимаете...
> Причем зачастую, это рождается так: Была хранимка, а вот тут кровь из носу
> нужны вон те данные. А переделывает не автор. И все... Пипец.
>
> Хотел бы я это увидеть!
> Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в
> том числе - потому что у него репликация CPU-bound при определенных
> условиях).
> Вообще, конечно, не имея синхронной репликации в кластере СУБД
> разносить хранимки по разным нодам - это чисто теоретическая идея. Я
> бы так делать не стал. С другой стороны - что такое можно делать в
> хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.
> Конвертировать видео? Биткойны майнить?
>
> Выше частичный ответ. И да, давайте не о MySQL.
>
>> У него
>> это написано вот тут:
>>
>> https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207
>> хотя у MySQL известно). При всем при этом стоимость масштабирования
>> приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера
>> (1
>> под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало
>> 4
>> (2 под приложение, 2 под СУБД).
>> 2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно
>> спокойно добавить +1 сервер, а не +2,5 из текста выше.
>
> Боюсь, в тексте выше не использовалась строгая типизация - это вы там
> яблоки с совами сравнили.
>
> Это больше манагерский подход использовался "Сколько мне это будет в баксах
> / количествах серверов". Естественно дьявол - в деталях.
>
>> Причем в случае с
>> СУБД масштабированием у вас время нулевой транзакции увеличивается, то
>> есть
>> сервер начинает отвечать чуть медленнее.
>>
>> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
>> Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют
>> совершенно разный смысл, но часто - одинаковые последствия. Есть
>> случаи, когда ORM - безусловное зло, но это граничные случаи.
>> И, конечно, ORM большое зло, когда разработчики из-за предоставляемых
>> абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами
>> профессионалы.
>>
>> Потому что из 2го часто следует 1е.
>
> Если люди не умеют использовать ORM, они себе чем угодно башку отстрелят.
> Что и происходит сплошь и рядом.
> Утверждение "мы откажемся от ORM прямо на этапе проектирования и
> поэтому заживем" - лютая чушь.
> Некоторые ORM отлично заменяют горе-рукоделов, для того и придуманы.
> Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).
>
> Вот тут я не могу не согласиться. ORM - зло, отсутствие ORM - тоже. Жизнь -
> боль. Голактека жестока... Впрочем это уже из другой оперы.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From i.petro.77.00 на gmail.com  Fri Jan 16 01:02:28 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 12:02:28 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
Message-ID: <20150116090228.GP6552@vdsl.uvw.ru>

>> мне кажется голый SQL это единственный способ строить нормальные
>> хайлоады.
>> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
>> ОЧЕНЬ интимные.
>> 
>> то есть например если у вас пользователи, то вам пойдет практически
>> любой вид шардинга, а если у вас таблицы с логами действий тех же
>> пользователей и вам надо выводить списки, то уже далеко не любой
>> подойдет.

> Хранить time-series data в RDBMS, да еще и с шардами - какая свежая
> идея, однако!

Вот допустим билинг у вас.
пользователь что-то сделал, а Вы с него денюжку считали.
все транзакции пишем в лог + баланс пользователя расчитываем.

Нужно уметь показывать выборки из этого лога
ибо пользователь захочет видеть отчет вида "списания с времени X до
времени Y"
соответственно такой лог где Вы предлагаете хранить?

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

>> SELECT
>>     *
>> FROM
>>     table1
>> JOIN
>>     table2
>> JOIN
>>     table3
>> WHERE
>>     table1.col = 10
>> 
>> до сих пор многие базы не научились нормально во всех случаях
>> оптимизировать.
>> то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
>> JOIN на все остальное додумается далеко не каждый планировщик. причем
>> те планировщики которые умеют до такого додуматься, додумаются не
>> всегда.

> Силюсь понять, что имеется в виду.
> Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть
> какие-то планировщики, которые сначала сделают декартово произведение,
> а потом только наложат условие? ДА ЛАДНО? Где это такая радость?

в MySQL и Pg. сюрприз?
иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
выборку ДО JOIN.

вторая проблема, толкающая в свой синтаксис - заставить использовать
именно нужный индекс.

это пожалуй единственная хорошая черта MySQL - то что можно сказать в
явной форме какой индекс использовать для запроса.
в Pg если у Вас частичный индекс размером 100Кб построенный специально
для данного запроса, то он все равно может решить использовать
8Гиговый индекс по каким-то своим внутренним соображениям.
и единственный способ убедить его как надо правильно действовать -
WITH.


From i.petro.77.00 на gmail.com  Fri Jan 16 01:08:10 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 12:08:10 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <CA+kq2xt8Yt-9459PQSGnqsQXGg5UCAO5ccWpMeiGiwfMRBfSyw@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
	<CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>
	<CAKaHDOF0uQbTBRmk1h-tovLkuJM8+0_iKxOB3ok4UZCSWdqxsA@mail.gmail.com>
	<CA+kq2xt8Yt-9459PQSGnqsQXGg5UCAO5ccWpMeiGiwfMRBfSyw@mail.gmail.com>
Message-ID: <20150116090810.GQ6552@vdsl.uvw.ru>


> Ну - почти любой ORM общего применения умеет позволять исполнить raw
> SQL (те, которые не умеют, надо отправить обратно авторам с
> рекламацией).

вопрос можно? спасибо
если в ORM исполнять rawSQL, зачем нужен ORM?

если ORM не умеющий исполнять rawSQL по вашему - говно и его "надо
отправить обратно авторам с рекламацией", следовательно фича
"исполнять rawSQL" - очень, критически важная.

следовательно ORM со своей ГЛАВНОЙ задачей не справляется.

в соседнем письме Вы спрашивали обосновать почему ORM - зло.
я сперва думал написать Вам развернутый ответ. но вот по этому письму
я отлично понял, что информацией почему ORM - зло, Вы владеете
отлично, без моих пояснений

From i.petro.77.00 на gmail.com  Fri Jan 16 01:13:48 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 12:13:48 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <1421371817.935978423@f133.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421369267.490056532@f27.i.mail.ru>
	<CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
	<1421371817.935978423@f133.i.mail.ru>
Message-ID: <20150116091348.GR6552@vdsl.uvw.ru>


> Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут
> дурак полностью и он гениален.

я почитал.
новой парадигмы перед прочими билдилками SQL из перл я не увидел.
запроса в красивой форме пользователь тут не видит, соответственно
читабельность кода не возрастает.
далее в тонкости не вникал


From pef-secure на yandex.ru  Fri Jan 16 01:34:02 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 10:34:02 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421371119.474965071@f133.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <2167719.CUnOryv6hc@rawen>
	<1421371119.474965071@f133.i.mail.ru>
Message-ID: <1493409.IR33SjMdWE@rawen>

On Friday, January 16, 2015 04:18:39 Warstone на list.ru wrote:
> То есть вместо того чтобы использовать Class::XSAccessor который
> оптимизирован по самое не балуйся вы используете eval, тем самым: 

Аксессоры -- малая часть того, что требуется. Если б только это, я бы обошёлся 
Class::Struct.

> 1) Раздуваете working-set приложения

Простите, но что именно раздувается? Я не понял, особенно учитывая мой ответ 
на п.4.

> 2) Теряете возможность рантаймого похачить базовый класс или сделать
> инъектирование к наследование, если уж вы не хотите mro::c3 с next::method
> пользовать и таким образом давать возможность пользовать миксины, если
> ОЧЕНЬ надо. 

Use Case какой? Perl -- язык динамический, в рантайме можно что угодно 
сделать.


> 3) Теряете читабельность кода

Кода, который пользуется этим модулем? Я приводил примеры, там было, по моему 
мнению, наоборот. Если речь про код модуля, то, Вы часто лезете под капот 
машины, чтобы проверить красоту устройства двигателя? Кроме того, не такой уж 
он нечитабельный, при достаточной подготовке читателя.


> 4) Выигрываете мизерный процент на обращении к хешу.

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


> И вы считаете это плюсом? Если вы где-то используете кодогеренацию вы что-то
> делаете не так.

Это похоже на постулат некоторой веры. Ну и на что же мне _динамический_ язык 
тогда?

> Вам надо еще? Хорошо... Почему вы в коде где-то пользуете ссылку на CORE, а
> где-то нет? Вы в своем модуле, что defined и exists перебили? Или... Зачем
> это вообще? Причем в части коде есть CORE:: перед ref, в части нету...

Если существует таблица, у которой есть поле "ref". Использование выражения 
ref $a в коде объекта при наличии аксессора ref() у объекта приведёт к 
неоднозначностям. Поэтому, в генерируемом коде постарался везде прописать явно 
CORE::.

> Вы проверяете во время setup_row есть-ли у вас уже такой класс, только вот
> вы получаете имя класса и таблицу, а отдаете только имя класса... То есть я
> никоем образом не узнаю, что я 2й раз пытаюсь вызвать генерацию класса, и
> фиг с ним, если на одной и той-же таблице, а если на разных? Где там
> проверка на название таблицы и гроханье с большим ором, если она не такая.
> Где варн, если таблица та-же? Или это тренд такой "Если программист чего-то
> ступил, давайте ему максимально осложним поиск баги"?

Я немного не понял проблемы. Проверяется существование класса по таблице 
символов, известной интерпретатору. Если класс есть, он используется, если 
нет, то генерируется. Генерация происходит один раз для каждой таблицы при 
коннекте, который происходит при стартапе приложения. Так же генерация 
происходит для динамических запросов, тоже только один раз, второй раз 
используется готовый класс.

> Вы хотели ревью - вот он вам. Модуль выбросить или переписать по
> нормальному, а не через... кодогенерацию. Сейчас модуль безнадежен с точки
> зрения дальнейшего развития и использования. Его просто опасно
> использовать.

Всё опасно использовать. Даже регексп может вызвать rm -rf. За обсуждение и 
мнение -- спасибо.
-- 
PEF Developer

From dmitry на eremeev.ru  Fri Jan 16 01:36:54 2015
From: dmitry на eremeev.ru (Dmitry Eremeev)
Date: Fri, 16 Jan 2015 12:36:54 +0300
Subject: [Moscow.pm]
 =?koi8-r?b?djIg0NLP09jCwSDPINLF19jAIM3PxNXM0SBEQkl4?=
 =?koi8-r?b?OjpTdHJ1Y3Q=?=
In-Reply-To: <1493409.IR33SjMdWE@rawen>
References: <1858407.iHouSzOesI@rawen> <2167719.CUnOryv6hc@rawen>
	<1421371119.474965071@f133.i.mail.ru> <1493409.IR33SjMdWE@rawen>
Message-ID: <9F96DB23-5038-4C49-AFE6-29367BF993A0@eremeev.ru>

"Не ссорьтесь, девочки".



Yours
Dmitry Eremeev
CEO adPremium

Russia / office: +7 499 703 32 07
UK / office: +44 870 295 24 46
Skype: eremeev.ru

https://linkedin.com/in/dimkae
https://facebook.com/dimkae


> 16 янв. 2015 г., в 12:34, PEF Secure <pef-secure на yandex.ru> написал(а):
> 
>> On Friday, January 16, 2015 04:18:39 Warstone на list.ru wrote:
>> То есть вместо того чтобы использовать Class::XSAccessor который
>> оптимизирован по самое не балуйся вы используете eval, тем самым:
> 
> Аксессоры -- малая часть того, что требуется. Если б только это, я бы обошёлся 
> Class::Struct.
> 
>> 1) Раздуваете working-set приложения
> 
> Простите, но что именно раздувается? Я не понял, особенно учитывая мой ответ 
> на п.4.
> 
>> 2) Теряете возможность рантаймого похачить базовый класс или сделать
>> инъектирование к наследование, если уж вы не хотите mro::c3 с next::method
>> пользовать и таким образом давать возможность пользовать миксины, если
>> ОЧЕНЬ надо.
> 
> Use Case какой? Perl -- язык динамический, в рантайме можно что угодно 
> сделать.
> 
> 
>> 3) Теряете читабельность кода
> 
> Кода, который пользуется этим модулем? Я приводил примеры, там было, по моему 
> мнению, наоборот. Если речь про код модуля, то, Вы часто лезете под капот 
> машины, чтобы проверить красоту устройства двигателя? Кроме того, не такой уж 
> он нечитабельный, при достаточной подготовке читателя.
> 
> 
>> 4) Выигрываете мизерный процент на обращении к хешу.
> 
> В плане скорости, да, это микрооптимизация, которая глобально может и не 
> влиять. А в плане расхода памяти это уже заметная разница. Был у меня в 
> далёком прошлом случай, когда пришлось переделать структуру строки с хеша на 
> массив, чтобы анализируемые данные стали влезать в память.
> 
> 
>> И вы считаете это плюсом? Если вы где-то используете кодогеренацию вы что-то
>> делаете не так.
> 
> Это похоже на постулат некоторой веры. Ну и на что же мне _динамический_ язык 
> тогда?
> 
>> Вам надо еще? Хорошо... Почему вы в коде где-то пользуете ссылку на CORE, а
>> где-то нет? Вы в своем модуле, что defined и exists перебили? Или... Зачем
>> это вообще? Причем в части коде есть CORE:: перед ref, в части нету...
> 
> Если существует таблица, у которой есть поле "ref". Использование выражения 
> ref $a в коде объекта при наличии аксессора ref() у объекта приведёт к 
> неоднозначностям. Поэтому, в генерируемом коде постарался везде прописать явно 
> CORE::.
> 
>> Вы проверяете во время setup_row есть-ли у вас уже такой класс, только вот
>> вы получаете имя класса и таблицу, а отдаете только имя класса... То есть я
>> никоем образом не узнаю, что я 2й раз пытаюсь вызвать генерацию класса, и
>> фиг с ним, если на одной и той-же таблице, а если на разных? Где там
>> проверка на название таблицы и гроханье с большим ором, если она не такая.
>> Где варн, если таблица та-же? Или это тренд такой "Если программист чего-то
>> ступил, давайте ему максимально осложним поиск баги"?
> 
> Я немного не понял проблемы. Проверяется существование класса по таблице 
> символов, известной интерпретатору. Если класс есть, он используется, если 
> нет, то генерируется. Генерация происходит один раз для каждой таблицы при 
> коннекте, который происходит при стартапе приложения. Так же генерация 
> происходит для динамических запросов, тоже только один раз, второй раз 
> используется готовый класс.
> 
>> Вы хотели ревью - вот он вам. Модуль выбросить или переписать по
>> нормальному, а не через... кодогенерацию. Сейчас модуль безнадежен с точки
>> зрения дальнейшего развития и использования. Его просто опасно
>> использовать.
> 
> Всё опасно использовать. Даже регексп может вызвать rm -rf. За обсуждение и 
> мнение -- спасибо.
> -- 
> PEF Developer
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From pef-secure на yandex.ru  Fri Jan 16 01:44:02 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 10:44:02 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xvwZJGR4Xbdf62V0-Xg-R+K-HeJx7QrZXq+Ee0b9foJ-w@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421371817.935978423@f133.i.mail.ru>
	<CA+kq2xvwZJGR4Xbdf62V0-Xg-R+K-HeJx7QrZXq+Ee0b9foJ-w@mail.gmail.com>
Message-ID: <7344207.ePzTgM6GQZ@rawen>

On Friday, January 16, 2015 11:33:04 Alex Chistyakov wrote:
> 
> Похоже на то, что он и правда гениален. Я почитал синопсис и тест и
> остался в тяжком недоумении.
> Как мне вытащить структуру объектов (то, что в старом добром SQL
> называется JOIN)? Где lazy loading? Где двухуровневый кэш?
> Где генерация структуры таблиц по метаописанию на XML?
> Нет, это не тот ORM, к которому я привык. Фиг бы с ним, с XML - но
> зачем нужен конструктор запросов к единственной таблице?
> Идти читать сам код я теперь немного боюсь - при таком радикальном
> подходе к постановке задачи, кто его знает, что ждет в реализации...

1. Я не собирался делать ORM. Я собирался упростить частые и очевидные SQL.
2. JOIN есть, но теста на него пока нет, есть описание в документации модуля.
3. Генерации подзапросов нет, сложные запросы предполагается писать руками. 
Для примера использования я привёл ссылку в самом первом сообщении. 
4. Код можно не читать, можно же просто почитать что о нём говорят другие и 
составить своё мнение, на основании которого сказать "фи".

-- 
PEF Developer

From onokonem на gmail.com  Fri Jan 16 01:45:19 2015
From: onokonem на gmail.com (Daniel Podolsky)
Date: Fri, 16 Jan 2015 13:45:19 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xt8Yt-9459PQSGnqsQXGg5UCAO5ccWpMeiGiwfMRBfSyw@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
	<CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>
	<CAKaHDOF0uQbTBRmk1h-tovLkuJM8+0_iKxOB3ok4UZCSWdqxsA@mail.gmail.com>
	<CA+kq2xt8Yt-9459PQSGnqsQXGg5UCAO5ccWpMeiGiwfMRBfSyw@mail.gmail.com>
Message-ID: <CAKaHDOEBVbibV=ni7KCqqW2jG_eSsR8jLya77JHRk57GSr30qQ@mail.gmail.com>

> В базах данных живут гномики и все вот это вот.
в ORM-то _планово_ никто, кроме гномиков не живет...

From warstone на list.ru  Fri Jan 16 03:45:17 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 14:45:17 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1493409.IR33SjMdWE@rawen>
References: <1858407.iHouSzOesI@rawen> <1421371119.474965071@f133.i.mail.ru>
	<1493409.IR33SjMdWE@rawen>
Message-ID: <1421408717.738849153@f91.i.mail.ru>

 Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...


Fri, 16 Jan 2015 10:34:02 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Friday, January 16, 2015 04:18:39  Warstone на list.ru wrote:
>> То есть вместо того чтобы использовать Class::XSAccessor который
>> оптимизирован по самое не балуйся вы используете eval, тем самым: 
>
>Аксессоры -- малая часть того, что требуется. Если б только это, я бы обошёлся 
>Class::Struct. На скорость вы принципиально плюете.
>> 1) Раздуваете working-set приложения
>
>Простите, но что именно раздувается? Я не понял, особенно учитывая мой ответ 
>на п.4. На то, сколько программа будет занимать в памяти после того, как вы все нагенерите. Хотя ладно, это придирка. Могу еще одну рассказать... Вы пользуете DBIx::Connector, который в себе при создании имеет следующее: $self->{pid} = $$; Прощай форк после вашего populate'а. Прощай здравый смысл. Хотя это не ваша вина, но анализировать модули, которые используете - имеет смысл.
>> 2) Теряете возможность рантаймого похачить базовый класс или сделать
>> инъектирование к наследование, если уж вы не хотите mro::c3 с next::method
>> пользовать и таким образом давать возможность пользовать миксины, если
>> ОЧЕНЬ надо. 
>
>Use Case какой? Perl -- язык динамический, в рантайме можно что угодно 
>сделать. Сделать "просто". Если мне не допустим надо сделать аудит в моем варианте я перебиваю базовые методы в Base пакете. В вашем мне надо по всей схеме пройтись. Это для примера.
>> 3) Теряете читабельность кода
>
>Кода, который пользуется этим модулем? Я приводил примеры, там было, по моему 
>мнению, наоборот. Если речь про код модуля, то, Вы часто лезете под капот 
>машины, чтобы проверить красоту устройства двигателя? Кроме того, не такой уж 
>он нечитабельный, при достаточной подготовке читателя.
Я всегда лезу под капот машины, чтобы понять насколько она быстрая и не будет-ли у меня проблем с этой моделью. Я могу не понимать всего алгоритма работы, но примерное поведение я должен знать. Более того, нету лучше метода узнать что делает модуль, чем посмотреть на его код. И у нас такие все. В резульатте рождается что-то типа вот этого:  http://search.cpan.org/~randir/Class-Accessor-Inherited-XS-0.07/lib/Class/Accessor/Inherited/XS.pm (Автор не я, сразу говорю. Он метрах в 10 от меня сидит. Просто у него было время для того, чтобы это сделать).
А если мне еще надо и подготовиться... Я лучше подготовлюсь путем неиспользования модуля, особенно если у него есть альтернативы (DBIx::Simple + SQL::Abstract, у которых так-же есть проблемы с форками, кстати).
>> 4) Выигрываете мизерный процент на обращении к хешу.
>
>В плане скорости, да, это микрооптимизация, которая глобально может и не 
>влиять. А в плане расхода памяти это уже заметная разница. Был у меня в 
>далёком прошлом случай, когда пришлось переделать структуру строки с хеша на 
>массив, чтобы анализируемые данные стали влезать в память.
Ну куда вы полезли?.. Доступ к хешу в классе. Вы экономите чуть-чуть на кждом созданном классе таким образом, а не объекте.
>> И вы считаете это плюсом? Если вы где-то используете кодогеренацию вы что-то
>> делаете не так.
>
>Это похоже на постулат некоторой веры. Ну и на что же мне _динамический_ язык 
>тогда? А для вас динамический - это только eval? Ну тогда да. Если-же нет, то создание пакета в рантайме без евала - это тоже динамика.
>> Вам надо еще? Хорошо... Почему вы в коде где-то пользуете ссылку на CORE, а
>> где-то нет? Вы в своем модуле, что defined и exists перебили? Или... Зачем
>> это вообще? Причем в части коде есть CORE:: перед ref, в части нету...
>
>Если существует таблица, у которой есть поле "ref". Использование выражения 
>ref $a в коде объекта при наличии аксессора ref() у объекта приведёт к 
>неоднозначностям. Поэтому, в генерируемом коде постарался везде прописать явно 
>CORE::. Вопрос не почему вы это сделали, а почему вы это сделали не везде. Но тут возможно просто не нашли все, так как текст, а не код... А теста такого вы не набросали, похоже... B::Deparse попользуйте думаю узнаете немного интересного.
>> Вы проверяете во время setup_row есть-ли у вас уже такой класс, только вот
>> вы получаете имя класса и таблицу, а отдаете только имя класса... То есть я
>> никоем образом не узнаю, что я 2й раз пытаюсь вызвать генерацию класса, и
>> фиг с ним, если на одной и той-же таблице, а если на разных? Где там
>> проверка на название таблицы и гроханье с большим ором, если она не такая.
>> Где варн, если таблица та-же? Или это тренд такой "Если программист чего-то
>> ступил, давайте ему максимально осложним поиск баги"?
>
>Я немного не понял проблемы. Проверяется существование класса по таблице 
>символов, известной интерпретатору. Если класс есть, он используется, если 
>нет, то генерируется. Генерация происходит один раз для каждой таблицы при 
>коннекте, который происходит при стартапе приложения. Так же генерация 
>происходит для динамических запросов, тоже только один раз, второй раз 
>используется готовый класс. Проблема вот в этом: setup_row('table1', 'MySchema::Table'); setup_row('table2', 'MySchema::Table'). На 2-м должен упасть. У вас не падает.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/5821e027/attachment-0001.html>

From pef-secure на yandex.ru  Fri Jan 16 04:40:49 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 13:40:49 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421408717.738849153@f91.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1493409.IR33SjMdWE@rawen>
	<1421408717.738849153@f91.i.mail.ru>
Message-ID: <6567681.z3y6XbftDU@rawen>

On Friday, January 16, 2015 14:45:17 Warstone на list.ru wrote:
>  Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...

Поскольку ж написали, мне придётся ответить :)

> 4. На то, сколько программа будет занимать в памяти после того,
> >как вы все нагенерите.

Ну сгенерируется и скомпилируется код на каждый _класс_. Он и так и этак бы 
компилировался, что при ORM, что с моим модулем. Речь может идти только о 
"производных" классах, которые основаны на генерящихся запросах, тут всё от 
приложения зависит, но мне сомнительно, что это такая уж проблема.

> >Хотя ладно, это придирка. Могу еще одну
> >рассказать... Вы пользуете DBIx::Connector, который в себе при создании
> >имеет следующее: $self->{pid} = $$; Прощай форк после вашего populate'а.

Почему же? Стартап: connect, populate. Дальше форки могут идти сколько угодно, 
их кухню от меня скроет DBIx::Connector. Если речь о prepared, то их 
использования пока нет, и "прозрачный реконнект" как одна из причин. Хотя уже 
давно думаю над их внедрением. 

> >Прощай здравый смысл. Хотя это не ваша вина, но анализировать модули,
> >которые используете - имеет смысл.

Анализировал. Если посмотреть на мой DBIx::Struct::Connector, то можно понять, 
что внутрь коннектора я смотрел. Кстати, туда возможно и встрою кеширование и 
сброс prepared.

> Сделать "просто". Если мне не допустим надо сделать аудит в моем
> >варианте я перебиваю базовые методы в Base пакете. В вашем мне надо по
> >всей схеме пройтись. Это для примера.

Слишком абстрактно. Но идею я понял. Как вариант, могу сделать настройку, 
чтобы все генерируемые классы наследовали какой-то, который будет указан. Если 
я правильно понял вопрос.

> Я всегда лезу под капот машины, чтобы понять насколько она быстрая и не
> будет-ли у меня проблем с этой моделью. 

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

> Я лучше подготовлюсь путем неиспользования
> модуля, особенно если у него есть альтернативы 

Насильно мил не буду.

> (DBIx::Simple + SQL::Abstract, у которых так-же есть проблемы с форками,
> кстати).

Смотря что называть проблемами. Вот я привёл пример демо-приложения. Там PSGI. 
Приложение запускается, в стартапе происходит connect(), populate(), затем уже 
запущенное и проинициализированное приложение передаётся в uwsgi для форков по 
мере надобности. 

> Ну куда вы полезли?.. Доступ к хешу в классе. Вы экономите чуть-чуть на
> кждом созданном классе таким образом, а не объекте.

Зависит от меры "чуть-чуть". В два раза минимум, ведь как минимум массиву не 
нужно хранить названия ключей для каждой строки, их знание обозначено один раз 
в описании класса. Экономлю именно на каждом созданном объекте. Убедиться в 
разнице memory footprint можно используя модуль Devel::Size.

> >А для вас динамический - это только eval? 

Нет, но именно при написании _фреймворка_ мне это видится очень полезным 
свойством. До написания фреймворка пользовался им для перехвата исключений, в 
основном.

> Вопрос не почему вы это сделали, а почему вы это сделали не
> >везде. Но тут возможно просто не нашли все, так как текст, а не код...

Спасибо за багрепорт, поищу где пропустил.

> Проблема вот в этом: setup_row('table1',
> >'MySchema::Table'); setup_row('table2', 'MySchema::Table'). На 2-м должен
> >упасть. У вас не падает.

Там иной сценарий использования. Это внутренний метод, такого варианта, что Вы 
написали, в модуле нет. 
-- 
PEF Developer

From i.petro.77.00 на gmail.com  Fri Jan 16 05:08:02 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 16:08:02 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <1421408717.738849153@f91.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421371119.474965071@f133.i.mail.ru>
	<1493409.IR33SjMdWE@rawen> <1421408717.738849153@f91.i.mail.ru>
Message-ID: <20150116130802.GS6552@vdsl.uvw.ru>

> Аксессоры -- малая часть того, что требуется. Если б только это, я бы
> обошёлся
> Class::Struct.

> На скорость вы принципиально плюете.

скорость акцессоров в вопросе работы с БД - последнее место, которое
надо оптимизировать


From rabbit+moscowpm на rabbit.us  Fri Jan 16 05:37:54 2015
From: rabbit+moscowpm на rabbit.us (=?UTF-8?B?0J/QuNGC0Y3RgCDQoNGN0LHQsdC40YLRgdC+0L0=?=)
Date: Fri, 16 Jan 2015 14:37:54 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen>
	<1421329180.20345538@f361.i.mail.ru>	<CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>	<1421369267.490056532@f27.i.mail.ru>
	<CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
Message-ID: <54B91432.6070301@rabbit.us>

On 01/16/2015 02:09 AM, Alex Chistyakov wrote:
>
> Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).
>

Огласите весь список пожалуйста ;)



From warstone на list.ru  Fri Jan 16 05:44:56 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 16:44:56 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <6567681.z3y6XbftDU@rawen>
References: <1858407.iHouSzOesI@rawen> <1421408717.738849153@f91.i.mail.ru>
	<6567681.z3y6XbftDU@rawen>
Message-ID: <1421415896.429042806@f339.i.mail.ru>


Fri, 16 Jan 2015 13:40:49 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Friday, January 16, 2015 14:45:17  Warstone на list.ru wrote:
>>  Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...
>
>Поскольку ж написали, мне придётся ответить :)
>
>> 4. На то, сколько программа будет занимать в памяти после того,
>> >как вы все нагенерите.
>
>Ну сгенерируется и скомпилируется код на каждый _класс_. Он и так и этак бы 
>компилировался, что при ORM, что с моим модулем. Речь может идти только о 
>"производных" классах, которые основаны на генерящихся запросах, тут всё от 
>приложения зависит, но мне сомнительно, что это такая уж проблема. Вы принципиально издеваетесь?... Ладно, вот вам тест:  http://pastebin.ru/Un6reVrU
Быстрее в 6 раз, памяти занимает более чем в 2 раза меньше. И это при том, что тут один метод с очень маленьким кодом. при увеличении кода разрыв будет увеличиваться, так как в обоих случаях много на себя берет сам стеш и "создание" модуля. Вывод:
_Пуш в ису гораздо быстрее по времени, меньше занимает памяти и вообще лучше чем кодогенерация. Всегда_ Забудьте про кодогенерацию. Если вы ее используете вы что-то делаете не так.
>> >Хотя ладно, это придирка. Могу еще одну
>> >рассказать... Вы пользуете DBIx::Connector, который в себе при создании
>> >имеет следующее: $self->{pid} = $$; Прощай форк после вашего populate'а.
>
>Почему же? Стартап: connect, populate. Дальше форки могут идти сколько угодно, 
>их кухню от меня скроет DBIx::Connector. Если речь о prepared, то их 
>использования пока нет, и "прозрачный реконнект" как одна из причин. Хотя уже 
>давно думаю над их внедрением.  Так вы для себя или выложить на cpan? Если для себя - ок. Если на cpan - это проблема. А еще большая проблема, если у вас перед Pg стоит PgBouncer в режиме TRANSACTION_POOLING.
>> Сделать "просто". Если мне не допустим надо сделать аудит в моем
>> >варианте я перебиваю базовые методы в Base пакете. В вашем мне надо по
>> >всей схеме пройтись. Это для примера.
>
>Слишком абстрактно. Но идею я понял. Как вариант, могу сделать настройку, 
>чтобы все генерируемые классы наследовали какой-то, который будет указан. Если 
>я правильно понял вопрос. На примере выше. Я могу сделать так: Base::cool_long_method = sub { ... } , будет перехвачено все. В вашем случае, даже с наследованием - не будет перехвачено ничего. Чтобы это сработало, надо сделать класс наследник, куда запихать сначала меня, потом то что вы нагенерили (По определению работы наследования). то есть:
package Schema::Table;
our @ISA = qw/Schema::Table::Base/;
тогда можно через сплайс вставить себя перед вами и получить то, что я получаю простым присвоением. и делать это надо каждый раз.
>> Ну куда вы полезли?.. Доступ к хешу в классе. Вы экономите чуть-чуть на
>> кждом созданном классе таким образом, а не объекте.
>
>Зависит от меры "чуть-чуть". В два раза минимум, ведь как минимум массиву не 
>нужно хранить названия ключей для каждой строки, их знание обозначено один раз 
>в описании класса. Экономлю именно на каждом созданном объекте. Убедиться в 
>разнице memory footprint можно используя модуль Devel::Size. Нет, на классе. Название таблицы и прочего засовывается в класс аксессор, а не в объект. И оверхеда копейки. Вы больше своим евалом генерите.
>> >А для вас динамический - это только eval? 
>
>Нет, но именно при написании _фреймворка_ мне это видится очень полезным 
>свойством. До написания фреймворка пользовался им для перехвата исключений, в 
>основном. Это вредное свойство. Наглядный пример - выше.
>> Проблема вот в этом: setup_row('table1',
>> >'MySchema::Table'); setup_row('table2', 'MySchema::Table'). На 2-м должен
>> >упасть. У вас не падает.
>
>Там иной сценарий использования. Это внутренний метод, такого варианта, что Вы 
>написали, в модуле нет.  А вы написали что он внутренний? А то у вас внутренние с _ начинаются, а этот - нет... Значит не внутренний.

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/7c442489/attachment-0001.html>

From dsimonov на gmail.com  Fri Jan 16 05:51:03 2015
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Fri, 16 Jan 2015 16:51:03 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421415896.429042806@f339.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <1421408717.738849153@f91.i.mail.ru>
	<6567681.z3y6XbftDU@rawen> <1421415896.429042806@f339.i.mail.ru>
Message-ID: <CAL9wMxXn4JC_PKP3+aRupmqq+re_CqqaFaXUR7bOpkBngcBRHQ@mail.gmail.com>

Господи. Сколько же в Тебе текста!

---
Dmitriy V. Simonov
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/e907b0fa/attachment.html>

From alexclear на gmail.com  Fri Jan 16 05:58:09 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 17:58:09 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <54B91432.6070301@rabbit.us>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>
	<1421369267.490056532@f27.i.mail.ru>
	<CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>
	<54B91432.6070301@rabbit.us>
Message-ID: <CA+kq2xsLO-MYewOdd4U6m4Zz3qbgKC6EYGzHZxs126W-W2_6dA@mail.gmail.com>

2015-01-16 16:37 GMT+03:00 Питэр Рэббитсон <rabbit+moscowpm на rabbit.us>:
> On 01/16/2015 02:09 AM, Alex Chistyakov wrote:
>>
>>
>> Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное
>> суждение).
>>
>
> Огласите весь список пожалуйста ;)

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


>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From alexclear на gmail.com  Fri Jan 16 06:00:27 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 18:00:27 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <20150116090228.GP6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
Message-ID: <CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>

2015-01-16 12:02 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>>> мне кажется голый SQL это единственный способ строить нормальные
>>> хайлоады.
>>> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
>>> ОЧЕНЬ интимные.
>>>
>>> то есть например если у вас пользователи, то вам пойдет практически
>>> любой вид шардинга, а если у вас таблицы с логами действий тех же
>>> пользователей и вам надо выводить списки, то уже далеко не любой
>>> подойдет.
>
>> Хранить time-series data в RDBMS, да еще и с шардами - какая свежая
>> идея, однако!
>
> Вот допустим билинг у вас.
> пользователь что-то сделал, а Вы с него денюжку считали.
> все транзакции пишем в лог + баланс пользователя расчитываем.
>
> Нужно уметь показывать выборки из этого лога
> ибо пользователь захочет видеть отчет вида "списания с времени X до
> времени Y"
> соответственно такой лог где Вы предлагаете хранить?

Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только
ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг
повалится в один и тот же регион. Как вариант - в OpenTSDB (то есть, в
том же HBase). Предупреждая вопросы - я так делал, брат жив. Только у
меня был не лог операций, а другие первичные пользовательские данные.

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

Он здесь нинужен, я бы с этого начал.

>
>>> SELECT
>>>     *
>>> FROM
>>>     table1
>>> JOIN
>>>     table2
>>> JOIN
>>>     table3
>>> WHERE
>>>     table1.col = 10
>>>
>>> до сих пор многие базы не научились нормально во всех случаях
>>> оптимизировать.
>>> то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
>>> JOIN на все остальное додумается далеко не каждый планировщик. причем
>>> те планировщики которые умеют до такого додуматься, додумаются не
>>> всегда.
>
>> Силюсь понять, что имеется в виду.
>> Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть
>> какие-то планировщики, которые сначала сделают декартово произведение,
>> а потом только наложат условие? ДА ЛАДНО? Где это такая радость?
>
> в MySQL и Pg. сюрприз?

В MySQL - не сюрприз, а клевета.
MySQL так не делает, точка.

> иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
> выборку ДО JOIN.

"Много усилий" - например, отключить hash join в данной сессии?
Или покажите план - возможно, мы просто не вполне понимаем друг друга.
Если не покажите, то хотя бы опишите словами, что за чем будет следовать.

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

Ну - это не офигеть какая хорошая черта (и, да, не единственная, не
нужно этого элитизма).

> в Pg если у Вас частичный индекс размером 100Кб построенный специально
> для данного запроса, то он все равно может решить использовать
> 8Гиговый индекс по каким-то своим внутренним соображениям.

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

> и единственный способ убедить его как надо правильно действовать -
> WITH.

Не самый плохой способ, работает же.

--
SY,
Alex


>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From alexclear на gmail.com  Fri Jan 16 06:05:25 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 18:05:25 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <20150116090810.GQ6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<1421354121.133391093@f398.i.mail.ru>
	<CA+kq2xtU+0Ukg4HUN3ap6WAHqOUVFFqJgfch0KMm1T+J8sSxZg@mail.gmail.com>
	<CAKaHDOF0uQbTBRmk1h-tovLkuJM8+0_iKxOB3ok4UZCSWdqxsA@mail.gmail.com>
	<CA+kq2xt8Yt-9459PQSGnqsQXGg5UCAO5ccWpMeiGiwfMRBfSyw@mail.gmail.com>
	<20150116090810.GQ6552@vdsl.uvw.ru>
Message-ID: <CA+kq2xsiP_BLyz8fC9VD4tuZXCZ-jR=5+Cib+jX1Gour=0Zy-g@mail.gmail.com>

2015-01-16 12:08 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> Ну - почти любой ORM общего применения умеет позволять исполнить raw
>> SQL (те, которые не умеют, надо отправить обратно авторам с
>> рекламацией).
>
> вопрос можно? спасибо
> если в ORM исполнять rawSQL, зачем нужен ORM?

Вы еще спросите, для чего у кошки хвостик.
Я не знаю. Я стараюсь делегировать написание bulk кода, типа basic
CRUD, специально предназначенным для этого лошкам, которые без ORM как
Ватсон без трубки (см. "а Ватсон без трубки уже не мог"). Говорят, так
существенно дешевле в деньгах.

>
> если ORM не умеющий исполнять rawSQL по вашему - говно и его "надо
> отправить обратно авторам с рекламацией", следовательно фича
> "исполнять rawSQL" - очень, критически важная.

Так и есть.

>
> следовательно ORM со своей ГЛАВНОЙ задачей не справляется.

Именно.

>
> в соседнем письме Вы спрашивали обосновать почему ORM - зло.
> я сперва думал написать Вам развернутый ответ. но вот по этому письму
> я отлично понял, что информацией почему ORM - зло, Вы владеете
> отлично, без моих пояснений

Да, похоже, что мы понимаем друг друга.

--
SY,
Alex


> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From rabbit+moscowpm на rabbit.us  Fri Jan 16 06:07:27 2015
From: rabbit+moscowpm на rabbit.us (=?UTF-8?B?0J/QuNGC0Y3RgCDQoNGN0LHQsdC40YLRgdC+0L0=?=)
Date: Fri, 16 Jan 2015 15:07:27 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <CA+kq2xsLO-MYewOdd4U6m4Zz3qbgKC6EYGzHZxs126W-W2_6dA@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen>
	<1421329180.20345538@f361.i.mail.ru>	<CA+kq2xs=nb3Z-BzRsrgkOrXBR2PEGs7Ubfwb0rU=0QZgOWG+ig@mail.gmail.com>	<1421369267.490056532@f27.i.mail.ru>	<CA+kq2xtXogX1BYSFO9aC4usJoZaRBsbA_GKRssGCn3YWJubBTw@mail.gmail.com>	<54B91432.6070301@rabbit.us>
	<CA+kq2xsLO-MYewOdd4U6m4Zz3qbgKC6EYGzHZxs126W-W2_6dA@mail.gmail.com>
Message-ID: <54B91B1F.7090009@rabbit.us>

On 01/16/2015 02:58 PM, Alex Chistyakov wrote:
> 2015-01-16 16:37 GMT+03:00 Питэр Рэббитсон <rabbit+moscowpm на rabbit.us>:
>> On 01/16/2015 02:09 AM, Alex Chistyakov wrote:
>>>
>>>
>>> Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное
>>> суждение).
>>>
>>
>> Огласите весь список пожалуйста ;)
>
> По некоторым эпизодам еще сроки давности не вышли - так что пусть
> живут, один плохой программист способен создать до десяти рабочих
> мест.
>

Печально...


From pef-secure на yandex.ru  Fri Jan 16 06:14:36 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 15:14:36 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421415896.429042806@f339.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <6567681.z3y6XbftDU@rawen>
	<1421415896.429042806@f339.i.mail.ru>
Message-ID: <118468869.HnqIDoSUrq@rawen>

On Friday, January 16, 2015 16:44:56 Warstone на list.ru wrote:
> Ладно, вот вам тест: 
> >http://pastebin.ru/Un6reVrU

for(my $i = 1; $i < $iterations; $i++){
    eval "package Namespace2::${i};\nsub cool_long_method { my \$self = shift; 
print \"This method is loooong\\n\";} 1;";
}

Я чувствую, что либо меня не понять, либо Вы не поняли.

_Зачем_ делать миллион итераций с eval? Это какая то совсем иная проблема. Я 
измерял следующий вариант:

eval {"\$sub_eval = sub {my \$self = shift; print \"This method is 
loooong\\n\";}" }; 

в сравнении с:

$sub_pure = sub {my $self = shift; print "This method is loooong\n" };

и сравнивал соответственно быстродействие $sub_eval->() и $sub_pure->(). 
Разницы почти нет. 

Именно этого случая я пытаюсь добиваться, а не того, что Вы написали.

> Так вы для себя или выложить на
> >cpan? Если для себя - ок. Если на cpan - это проблема. 

Для себя я б тут даже выступать не стал. Сидел бы себе и писал что хотел. 

> >А еще большая
> >проблема, если у вас перед Pg стоит PgBouncer в режиме
> >TRANSACTION_POOLING.>

В чём именно проблема?


>На примере выше. Я могу сделать так: Base::cool_long_method = sub { ... } ,
>будет перехвачено все. В вашем случае, даже с наследованием - не будет
>перехвачено ничего. Чтобы это сработало, надо сделать класс наследник, куда
>запихать сначала меня, потом то что вы нагенерили (По определению работы
>наследования). то есть:

Раз уж нам доступна кодогенерация свыше, всегда можно сделать то, что хочется. 
Например, инъекцию пользовательского кода. Я не говорю, что собираюсь это 
сделать, я говорю, что это _можно_. Я не пытаюсь из данных, выбранных из БД 
сделать полноценный произвольный объект в смысле ООП. Я использую их именно 
как данные, а абстракции у меня в другом слое.

> >Нет, на классе. Название таблицы и прочего засовывается в класс аксессор,
> >а не в объект. И оверхеда копейки. Вы больше своим евалом генерите.>

Название модуля (класса), к которому объект, (в дебрях не копался, но из общих 
соображений) должно быть одним указателем на описание этого модуля, единое для 
всех объектов (экземпляров). 8 байт на 64 бит платформе. Что-то мне кажется, 
Вы уже поплыли...


> Это вредное свойство. Наглядный пример - выше.

Который я не понял как относится к _моему_ коду. 

>  А вы написали что он внутренний? А то у вас
> >внутренние с _ начинаются, а этот - нет... Значит не внутренний.

Да, упустил. Спасибо за багрепорт.
-- 
PEF Developer

From i.petro.77.00 на gmail.com  Fri Jan 16 07:36:05 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 18:36:05 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
	<CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
Message-ID: <20150116153605.GT6552@vdsl.uvw.ru>


> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только
> ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг
> повалится в один и тот же регион.

про ключ - это я думал понятно итак.

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

> Он здесь нинужен, я бы с этого начал.

мы говорили о кластерах.
кластера для чего нужны?

1. распределение нагрузки по кластеру
2. размазывание данных (желательно с избыточностью) по кластеру


и вот задача "показ лога" - она довольно типовая для бизнесов, а вот
на кластера ложится плохо.

> В MySQL - не сюрприз, а клевета.
> MySQL так не делает, точка.

делает делает.

>> иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
>> выборку ДО JOIN.

> "Много усилий" - например, отключить hash join в данной сессии?

расставить веса для seq_scan например итп итд

всегда проще переписать запрос


> Допускаю такую возможность - но на практике удавалось избежать
> подобного дропнув индекс большего размера вообще и лишив планировщик
> выбора.

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

> Либо подобрав условие в WHERE так, чтобы большой индекс
> задействовать было нельзя.

либо переписав запрос

>> и единственный способ убедить его как надо правильно действовать -
>> WITH.

> Не самый плохой способ, работает же.

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

From warstone на list.ru  Fri Jan 16 07:58:51 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 18:58:51 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
 =?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <118468869.HnqIDoSUrq@rawen>
References: <1858407.iHouSzOesI@rawen> <1421415896.429042806@f339.i.mail.ru>
	<118468869.HnqIDoSUrq@rawen>
Message-ID: <1421423931.158280327@f77.i.mail.ru>




Fri, 16 Jan 2015 15:14:36 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Friday, January 16, 2015 16:44:56  Warstone на list.ru wrote:
>> Ладно, вот вам тест: 
>> > http://pastebin.ru/Un6reVrU
>
>for(my $i = 1; $i < $iterations; $i++){
>    eval "package Namespace2::${i};\nsub cool_long_method { my \$self = shift; 
>print \"This method is loooong\\n\";} 1;";
>}
>
>Я чувствую, что либо меня не понять, либо Вы не поняли.
>
>_Зачем_ делать миллион итераций с eval? Это какая то совсем иная проблема. Я 
>измерял следующий вариант:
>
>eval {"\$sub_eval = sub {my \$self = shift; print \"This method is 
>loooong\\n\";}" }; 
>
>в сравнении с:
>
>$sub_pure = sub {my $self = shift; print "This method is loooong\n" };
>
>и сравнивал соответственно быстродействие $sub_eval->() и $sub_pure->(). 
>Разницы почти нет. 
>
>Именно этого случая я пытаюсь добиваться, а не того, что Вы написали. Только у вас, насколько я помню именно генерация модуля идет, так? Если да, то вы не то и не с тем сравниваете... давайте на простом примере, ладно...
http://pastebin.ru/huvowqZG
Специально для вас - комментарии... Мы симулируем что у нас в базе 100.000 таблиц, чтобы было нагляднее.
В случае с ISA - создаем новый пакет, где весь код прописан в базовом и настраиваем свойства конкретно пакета (минимизируем часть, которая свойственна генерирующемуся пакету в пользу статического пакета с базовыми методами).
В случае с eval тупо создаем кучу пакетов с кастомным кодом. Я намеренно не делаю парсинг данных тут, так как у вас в методе data нету ни одного подстановочного места и он будет работать одинаково для обоих случаев.с остальными будет ак, как с методом query тут.

Я намеренно не использую XS аксессоры, которые быстрее, чтобы не код был более читабелен и тут не было никакой XS'ной магии.

Теперь по скорости работы... Вариант с ISA в 2 раза медленней, так как реально тестируется вызов сабы 1 раз или 2 раза. Это самый плохой вариант для меня, так как нету обвязки рядом. Как только вы накручиваете логику цифры будут приблежаться одна к другой. Причем это вызов метода класса, если вызывать на объекте и с XS магией, то eval вариант будет на 20% быстрее, а ISA на 40 (от текущих)

Фактически вы выжимаете где-то 30%-50% скорости, но делаете этот код не расширяемым и не поддерживаемым никем, кроме вас. Такие модули на цпане никому не нужны. При этом вы теряете скорость на старте и память на создании кучи пакетов с одинаковым кодом.
>
>
>> Так вы для себя или выложить на
>> >cpan? Если для себя - ок. Если на cpan - это проблема. 
>
>Для себя я б тут даже выступать не стал. Сидел бы себе и писал что хотел. 
>
>> >А еще большая
>> >проблема, если у вас перед Pg стоит PgBouncer в режиме
>> >TRANSACTION_POOLING.>
>
>В чём именно проблема?
>
>
>>На примере выше. Я могу сделать так: Base::cool_long_method = sub { ... } ,
>>будет перехвачено все. В вашем случае, даже с наследованием - не будет
>>перехвачено ничего. Чтобы это сработало, надо сделать класс наследник, куда
>>запихать сначала меня, потом то что вы нагенерили (По определению работы
>>наследования). то есть:
>
>Раз уж нам доступна кодогенерация свыше, всегда можно сделать то, что хочется. 
>Например, инъекцию пользовательского кода. Я не говорю, что собираюсь это 
>сделать, я говорю, что это _можно_. Я не пытаюсь из данных, выбранных из БД 
>сделать полноценный произвольный объект в смысле ООП. Я использую их именно 
>как данные, а абстракции у меня в другом слое.
>
>> >Нет, на классе. Название таблицы и прочего засовывается в класс аксессор,
>> >а не в объект. И оверхеда копейки. Вы больше своим евалом генерите.>
>
>Название модуля (класса), к которому объект, (в дебрях не копался, но из общих 
>соображений) должно быть одним указателем на описание этого модуля, единое для 
>всех объектов (экземпляров). 8 байт на 64 бит платформе. Что-то мне кажется, 
>Вы уже поплыли...
>
>
>> Это вредное свойство. Наглядный пример - выше.
>
>Который я не понял как относится к _моему_ коду. 
>
>>  А вы написали что он внутренний? А то у вас
>> >внутренние с _ начинаются, а этот - нет... Значит не внутренний.
>
>Да, упустил. Спасибо за багрепорт.
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/598387b6/attachment-0001.html>

From mail на knutov.com  Fri Jan 16 08:09:51 2015
From: mail на knutov.com (Nick Knutov)
Date: Fri, 16 Jan 2015 21:09:51 +0500
Subject: [Moscow.pm]
 =?koi8-r?b?djIg0NLP09jCwSDPINLF19jAIM3PxNXM0SAgREJJ?=
 =?koi8-r?b?eDo6U3RydWN0?=
In-Reply-To: <20150115193028.GL6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <20150115193028.GL6552@vdsl.uvw.ru>
Message-ID: <54B937CF.8030609@knutov.com>

Очень интересная идея, но вы не используете плейсхолдеры в этом случае?
И если нет, то что с экранированием?
А если используете, то как потом собираете массив переменных для
плейсхолдеров? Если так же как WHERE, то это становится огромным и
нечитабельным, на мой вкус.

ps: сколько ни смотрел - не смог пока найти лучше варианта, чем писать
функцию, как мне подсказали тут несколько месяцев назад, которая будет
делать @where, @params, а потом собирает запрос целиком:

do { push @where, 'p.status=?';  push @params, ...    } if ...;
...
$sql .= ' WHERE '. join ' AND ', @where if @where;
$hashref_array = sql_select($sql, @params)


pps: а у вас есть замеры профита от перевода процесса сборки sql запроса
на XS? На сколько это имеет смысл?


16.01.2015 0:30, Ivan Petrov пишет:
> Мы кстати пришли к тому же: чистый SQL лучше автоматических
> генераторов SQL.
> 
> Далее мы стали думать как это улучшить.
> в итоге пришли к тому что идеально видимо просто посмотреть на то что
> происходит в мире других декларативных языков, когда требуется их
> автоматическая генерация.
> 
> соответственно первый и самый распространенный пример - генерация
> HTML.
> далее мы взяли и запилили модуль который делает embedded-perl в SQL
> запросе, сделали синтаксис совместимым с Mojo и далее стало очень
> удобно (см. DBIx::DR).
> 
> SELECT
>     *
> FROM
>     table
> JOIN
>     table2 ON col1 = col2
> ...
> WHERE
>     group_id = 10
> 
>     % if ($filter{from_date}) {
>         AND date >= <%= $filter{from_date} %>
>     % }
> 
>     % if ($filter{name}) {
>         AND name ilike <%= '%' . $name . '%' %>
>     % }
> 
> и тому подобное.
> 
> у нас проект около 3 млн строк сейчас, очень круто получается по MVC
> парадигме:
> 
> lib/Controller/* - модули контроллеров
> lib/Model/* - модули моделей
> templates/* - темплейты
> sql/* - sql'и
> 
> SQL-и вынесли в отдельные файлы и теперь во первых их редактим
> отдельным редактором с подсветкой синтаксиса
> во вторых они лежат в таком же дереве как и модели/итп.
> 
> PS: я написал XS'ную реализацию embedded-perl парсера, но пока не
> опубликовал. все хочу DBIx::DR на него перевести, заодно плагин
> сделать для Mojo на нем же. будет быстрый темплейт.
> руки пока не доходят допилить
> 

-- 
Best Regards,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130

From i.petro.77.00 на gmail.com  Fri Jan 16 08:52:45 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 19:52:45 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICAgREJJeDo6U3RydWN0?=
In-Reply-To: <54B937CF.8030609@knutov.com>
References: <1858407.iHouSzOesI@rawen> <20150115193028.GL6552@vdsl.uvw.ru>
	<54B937CF.8030609@knutov.com>
Message-ID: <20150116165245.GU6552@vdsl.uvw.ru>

> Очень интересная идея, но вы не используете плейсхолдеры в этом случае?
> И если нет, то что с экранированием?

еще как используем.

<%= перл-код %> использует стандартный плейсхолдер DBI (знак
вопросика) и подставляет возвращенное значение в массив переменных в
это же место.

<%== перл-код %> непосредственная подстановка без экранирований.

все так же как в Mojo только с SQL спецификой.


> А если используете, то как потом собираете массив переменных для
> плейсхолдеров? Если так же как WHERE, то это становится огромным и
> нечитабельным, на мой вкус.

как раз получается очень читабельный шаблон.

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

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

> ps: сколько ни смотрел - не смог пока найти лучше варианта, чем писать
> функцию, как мне подсказали тут несколько месяцев назад, которая будет
> делать @where, @params, а потом собирает запрос целиком:

> do { push @where, 'p.status=?';  push @params, ...    } if ...;
> ...
> $sql .= ' WHERE '. join ' AND ', @where if @where;
> $hashref_array = sql_select($sql, @params)

> pps: а у вас есть замеры профита от перевода процесса сборки sql запроса
> на XS? На сколько это имеет смысл?

значит так.
DBIx::DR написан за пол часа на коленке в том смысле - опробовать
парадигму написания SQL-запросов в виде темплейтов.

далее эта парадигма так понравилась что ее стали активно использовать,
а вот сам DBIx::DR не переписывался совсем. так и осталось то что
написано на скорую руку.

там соответственно довольно плохонький парсер темплейтов - раз
там итераторы для совместимости с DBIx::Class - два.

то есть если это развивать то надо приделывать

- кеширование считанных с диска SQL-запросов
- нормальный однопроходный парсер темплейта
- расширить минимальный набор хелперов из коробки (сейчас там толкьо
  include, list, hlist: hlist как выяснилось никому не нужен)
- есть некоторые проблемы с вычислением стектрейса падения (если
  падает в перловом коде в шаблоне). но эти проблемы и Mojo тоже
  решить до конца не смогли, увы. это perl

ну вот однопроходный парсер embedded-perl (сишная часть) написан уже
(и используется в тарантуле в embedded-lua). он очень быстрый,
но оформить XS-модулем руки пока не дошли (с временем плоховато)


From pef-secure на yandex.ru  Fri Jan 16 08:45:57 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 17:45:57 +0100
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <1421423931.158280327@f77.i.mail.ru>
References: <1858407.iHouSzOesI@rawen> <118468869.HnqIDoSUrq@rawen>
	<1421423931.158280327@f77.i.mail.ru>
Message-ID: <11122292.6TsjOYBcgk@rawen>

On Friday, January 16, 2015 18:58:51 Warstone на list.ru wrote:

> http://pastebin.ru/huvowqZG

Ну это уже поразумнее выглядит. 

> Специально для вас - комментарии... Мы симулируем что у нас в базе 100.000
> таблиц, чтобы было нагляднее. 

Как-то многовато, конечно. 

> Теперь по скорости работы... Вариант с ISA в 2 раза медленней, так как
> реально тестируется вызов сабы 1 раз или 2 раза. Это самый плохой вариант
> для меня, так как нету обвязки рядом. Как только вы накручиваете логику
> цифры будут приблежаться одна к другой. Причем это вызов метода класса,
> если вызывать на объекте и с XS магией, то eval вариант будет на 20%
> быстрее, а ISA на 40 (от текущих)

Я писал уже, что проблема даже не в самой скорости доступа к данным, а к 
занимаемой ими памяти. Описание одной таблицы должно быть всё-таки заметно 
меньше занимать, чем выбранные строки разбитые по именам полей в хеш. Что 100 
тыщ (500 забыли?) таблиц одни только описания и сгенерированный код будут 
много места занимать, кто бы спорил? Но в них же соответсвенно данных должно 
быть много, а в сравнении с объёмом данных единственное описание структуры 
должно наоборот место экономить. В случае ORM не придётся делать по классу на 
каждую таблицу?

> Такие модули на цпане никому не нужны. 

Спасибо за Ваше мнение.
-- 
PEF Developer

From alexclear на gmail.com  Fri Jan 16 08:46:35 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 20:46:35 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <20150116153605.GT6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
	<CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
	<20150116153605.GT6552@vdsl.uvw.ru>
Message-ID: <CA+kq2xsFgeoBSeUETUbBRKRDJF_JPfv3qkA=Lppi-7TL=yNRFA@mail.gmail.com>

2015-01-16 18:36 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только
>> ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг
>> повалится в один и тот же регион.
>
> про ключ - это я думал понятно итак.

Ну - я на всякий случай.
А то сейчас скажу, не оговорив граничные условия, а кто-нибудь из
читателей воспользуется, не подумав, и будет потом Предъявлять. От
людей, на прошлой неделе открывших для себя Dragon book, всего можно
ожидать.

>
>>> далее если говорить о кластере то в контексте выборок списков шардинг
>>> сюда ложится только с кучей оговорок
>
>> Он здесь нинужен, я бы с этого начал.
>
> мы говорили о кластерах.
> кластера для чего нужны?

О каких именно? Об HA или о LB кластерах?
Какие в кластере трейдоффы? Это CP или AP система?

>
> 1. распределение нагрузки по кластеру

Я хочу посмотреть на распределение нагрузки по HA кластеру!

> 2. размазывание данных (желательно с избыточностью) по кластеру
>
>
> и вот задача "показ лога" - она довольно типовая для бизнесов, а вот
> на кластера ложится плохо.

Ну и в каком именно месте она плохо ложится на кластера?
То, что в фидоэхе RU.PERL подписчики до сих пор не знают, как
использовать тот же HBase - это проблема кластеров, или, таки,
подписчиков RU.PERL?

>
>> В MySQL - не сюрприз, а клевета.
>> MySQL так не делает, точка.
>
> делает делает.

А я говорю - не делает!
Я же прав, иначе ведь быть не может?
Я к тому, что примеров, конечно, не будет? С планами запросов?

>
>>> иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
>>> выборку ДО JOIN.
>
>> "Много усилий" - например, отключить hash join в данной сессии?
>
> расставить веса для seq_scan например итп итд

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

>
> всегда проще переписать запрос

Особенно, если он генереный тем же ORM.
Нет, не всегда проще переписать запрос, далеко не всегда.

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

Ну так и нет проблем - пользователю нужно выбрать, чего он хочет -
купить еще памяти, поставить две машины с логической репликацией, или
СТРАДАТЬ.

> то есть два индекса они не просто так построены, а для двух возможных
> вариантов.
>
>> Либо подобрав условие в WHERE так, чтобы большой индекс
>> задействовать было нельзя.
>
> либо переписав запрос
>
>>> и единственный способ убедить его как надо правильно действовать -
>>> WITH.
>
>> Не самый плохой способ, работает же.
>
> дык я об этом и говорю.
> только этот способ сразу ставит крест на переносимости кода с базы на
> базу
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From i.petro.77.00 на gmail.com  Fri Jan 16 10:07:42 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 16 Jan 2015 21:07:42 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <CA+kq2xsFgeoBSeUETUbBRKRDJF_JPfv3qkA=Lppi-7TL=yNRFA@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
	<CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
	<20150116153605.GT6552@vdsl.uvw.ru>
	<CA+kq2xsFgeoBSeUETUbBRKRDJF_JPfv3qkA=Lppi-7TL=yNRFA@mail.gmail.com>
Message-ID: <20150116180742.GV6552@vdsl.uvw.ru>

>>> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только
>>> ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг
>>> повалится в один и тот же регион.
>> 
>> про ключ - это я думал понятно итак.

> Ну - я на всякий случай.
> А то сейчас скажу, не оговорив граничные условия, а кто-нибудь из
> читателей воспользуется, не подумав, и будет потом Предъявлять. От
> людей, на прошлой неделе открывших для себя Dragon book, всего можно
> ожидать.

а вы не кичитесь тем что вы Dragon book видели.
а то это как-бы анекдот напоминает про дзюдо, тайквандо и много других
страшных слов

>> 
>>>> далее если говорить о кластере то в контексте выборок списков шардинг
>>>> сюда ложится только с кучей оговорок
>> 
>>> Он здесь нинужен, я бы с этого начал.
>> 
>> мы говорили о кластерах.
>> кластера для чего нужны?

> О каких именно? Об HA или о LB кластерах?

мы говорили о кластерах вообще.
вроде пока никто ничего не конкретизировал



>> 2. размазывание данных (желательно с избыточностью) по кластеру
>> 
>> 
>> и вот задача "показ лога" - она довольно типовая для бизнесов, а вот
>> на кластера ложится плохо.

> Ну и в каком именно месте она плохо ложится на кластера?
> То, что в фидоэхе RU.PERL подписчики до сих пор не знают, как
> использовать тот же HBase - это проблема кластеров, или, таки,
> подписчиков RU.PERL?

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


> А я говорю - не делает!
> Я же прав, иначе ведь быть не может?

нет не правы

> Я к тому, что примеров, конечно, не будет? С планами запросов?

примеров не будет. со времен mysql 5.0.1 я не использую mysql.
это уже три по моему года прошло.
и соответственно именно основываясь на планах запросов мы в свое 
время для него писали аналог внешнего with

>> расставить веса для seq_scan например итп итд

> А еще можно засунуть в рот ствол ружья и нажать спусковой крючок
> большим пальцем ноги.
> Сегодня день отличных рецептов!

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

я как-то не очень понимаю вашего веселья
вы там видели обложку Dragon book. и от этого не можете остановиться
веселиться?
странно, очень страно

>> всегда проще переписать запрос

> Особенно, если он генереный тем же ORM.
> Нет, не всегда проще переписать запрос, далеко не всегда.

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

поэтому о запросах генеренных ORM говорят уже только ламье и школота,
под влиянием наркоты и Java


From alexclear на gmail.com  Fri Jan 16 10:31:58 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Fri, 16 Jan 2015 22:31:58 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <20150116180742.GV6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
	<CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
	<20150116153605.GT6552@vdsl.uvw.ru>
	<CA+kq2xsFgeoBSeUETUbBRKRDJF_JPfv3qkA=Lppi-7TL=yNRFA@mail.gmail.com>
	<20150116180742.GV6552@vdsl.uvw.ru>
Message-ID: <CA+kq2xvfCEAp9aRJsmdD7ssq+UEOjG_5bj_2b2nTXwW0riPGWQ@mail.gmail.com>

2015-01-16 21:07 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>>>> Ну, если мы говорим о так называемом "хайлоаде", то в HBase. Только
>>>> ключ надо начинать не с даты, а с ID пользователя, иначе весь биллинг
>>>> повалится в один и тот же регион.
>>>
>>> про ключ - это я думал понятно итак.
>
>> Ну - я на всякий случай.
>> А то сейчас скажу, не оговорив граничные условия, а кто-нибудь из
>> читателей воспользуется, не подумав, и будет потом Предъявлять. От
>> людей, на прошлой неделе открывших для себя Dragon book, всего можно
>> ожидать.
>
> а вы не кичитесь тем что вы Dragon book видели.

Ошибка - я, как раз, ее не видел.
Мне очень стыдно, конечно, но так уж вышло.
Впрочем, я вру. Мне не стыдно.

> а то это как-бы анекдот напоминает про дзюдо, тайквандо и много других
> страшных слов

Ну а чего там страшного-то? Бывают LL(n) грамматики, а бывают еще
какие-то там, я бы предположил, что RR.

>
>>>
>>>>> далее если говорить о кластере то в контексте выборок списков шардинг
>>>>> сюда ложится только с кучей оговорок
>>>
>>>> Он здесь нинужен, я бы с этого начал.
>>>
>>> мы говорили о кластерах.
>>> кластера для чего нужны?
>
>> О каких именно? Об HA или о LB кластерах?
>
> мы говорили о кластерах вообще.

Ну - мы можем об авиационном кластере поговорить тогда. Или об автомобильном.

> вроде пока никто ничего не конкретизировал
>
>
>
>>> 2. размазывание данных (желательно с избыточностью) по кластеру
>>>
>>>
>>> и вот задача "показ лога" - она довольно типовая для бизнесов, а вот
>>> на кластера ложится плохо.
>
>> Ну и в каком именно месте она плохо ложится на кластера?
>> То, что в фидоэхе RU.PERL подписчики до сих пор не знают, как
>> использовать тот же HBase - это проблема кластеров, или, таки,
>> подписчиков RU.PERL?
>
> HBase и хадуп - это ацтой тот еще.

Разумеется.

> вообще все что Java - все ацтой.

Все так и есть.
Куда уж там JVM по своим свойствам до интерпретатора Perl.

> мне неинтересно это говно обсуждать особенно в таком ключе что дескать
> подписчики тупые.

Да я все понял уже.
Вы решили это не обсуждать, а доказать.
Джава - отстой, MySQL - отстой, HBase и Hadoop - отстой.
Пастернак, кстати, тоже говно то еще.
Это я удачно зашел.

> это вы уж без меня.
>
>
>> А я говорю - не делает!
>> Я же прав, иначе ведь быть не может?
>
> нет не правы

А я говорю - прав.
Пока мы метрики не представим измеримые, мы не добьемся ничего.
Очевидно.

>
>> Я к тому, что примеров, конечно, не будет? С планами запросов?
>
> примеров не будет. со времен mysql 5.0.1 я не использую mysql.

MySQL с тех пор в части планировщика не изменился совершенно.

> это уже три по моему года прошло.

3 года? С 5.0.1?
Круто.
С 5.0.1, я думаю, 13 лет уже прошло.
Но, повторюсь, даже 5.0.1 такие косяки не порол, они за гранью разумного.
Не надо считать разработчиков MySQL дебилами, некоторые из них -
долларовые миллионеры.

> и соответственно именно основываясь на планах запросов мы в свое
> время для него писали аналог внешнего with

"У нас есть такие ракеты..."

>
>>> расставить веса для seq_scan например итп итд
>
>> А еще можно засунуть в рот ствол ружья и нажать спусковой крючок
>> большим пальцем ноги.
>> Сегодня день отличных рецептов!
>
> если база решает что индекс ей использовать не хочется, то
> единственный способ заставить ее передумать - перераспределить веса
> критериев, влияющих на ее решение.

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

>
> я как-то не очень понимаю вашего веселья
> вы там видели обложку Dragon book. и от этого не можете остановиться
> веселиться?

Мое веселье объяснимо очень просто - уже несколько дней мне в почтовый
ящик падают мифы и легенды Древней Греции.
И я чиста зашел поинтересоваться: чем именно вызван этот поток?

> странно, очень страно
>
>>> всегда проще переписать запрос
>
>> Особенно, если он генереный тем же ORM.
>> Нет, не всегда проще переписать запрос, далеко не всегда.
>
> дык ORM же зло и это в этой рассылке доказали 5-6 писем назад,

Мнение этой рассылки относительно того, зло ORM или нет, является для
меня столь же важным, как и мнение кофемашины о причинах глобального
потепления. Тем более, с учетом смысла и значения слова "доказали". У
вас тут Хабрахабр, что ли? Доказанным считается утверждение, за
которое проголосует большая часть электората? На объективную истину
всем плевать?

> когда
> сделали заявку что ORM без возможности писать руками SQL запрос - в
> помойку.

Окей, штатный use case для ORM:
- наколбасить бизнес-логику методом "ххивп" руками джуниоров и стритовых дам,
- методом направленного поиска идентифицировать те 1.5 запроса,
которые требуют ручного вмешательства,
- переписать их в raw SQL, либо модифицировать иным способом,
- PROFIT

В помойку надо отправлять не ORM, а операторов ORM. И некоторых
создателей ORM, которые не ведают, что творят.

> а поскольку фича ORM писать SQL запросы руками становится для ORM
> настолько ключевой, делаем вывод что ни один из ORM с поставленной
> задачей не справляется.

Формально это совершенно верный вывод, но:
а) есть ORM проекты, в которых raw SQL возможен. Например - Hibernate.
б) есть огромная куча продуктов, в которых вообще нет 1.5 запросов,
требующих ручного вмешательства. Просто потому, что они не доросли до
нужного размера.

>
> поэтому о запросах генеренных ORM говорят уже только ламье и школота,
> под влиянием наркоты и Java

В одном письме видеть утверждения "ORM пользуется только ламье" и
"MySQL не умеет применять фильтр к driving table в очевиднейшем
случае" - это должно взрывать мой мозг, но я уже привык ко всему.
Впрочем, некоторые видят пони и говорят с цветами, так что я уважаю вашу веру.

--
SY,
Alex


>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From warstone на list.ru  Fri Jan 16 11:27:05 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 22:27:05 +0300
Subject: [Moscow.pm] =?utf-8?b?0JrQvtC90YbQtdC/0YbQuNGPIE9STdCw?=
Message-ID: <1421436425.648333753@f351.i.mail.ru>


Раз уж тут пошла такая пьянка... Давайте сделаем ORM для PostgreSQL с поддержкой асинхронности и возможностью прямого SQL запроса и конвертирования результатов в спец типы.

Идея основана на том, что EXPLAIN VERBOSE всегда расскажет какие поля и откуда взяты (даже в случае с WITH), вот допустим:

 EXPLAIN VERBOSE WITH foo AS (SELECT * FROM test) SELECT * FROM foo;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 CTE Scan on foo  (cost=21.60..44.80 rows=1160 width=40)
   Output: foo.id, foo.data
   CTE foo
     ->  Seq Scan on pg_temp_111.test  (cost=0.00..21.60 rows=1160 width=40)
           Output: test.id, test.data

Смысл в том, что на каждый raw запрос (с кешированием, понятно) запрашивать EXPLAIN этого запроса и по результатам строить аксессоры. Или не строить ))

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/2c518b4c/attachment-0001.html>

From pef-secure на yandex.ru  Fri Jan 16 12:08:01 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 16 Jan 2015 21:08:01 +0100
Subject: [Moscow.pm] =?utf-8?b?0JrQvtC90YbQtdC/0YbQuNGPIE9STdCw?=
In-Reply-To: <1421436425.648333753@f351.i.mail.ru>
References: <1421436425.648333753@f351.i.mail.ru>
Message-ID: <6197565.IVtKcrUBhx@rawen>

On Friday, January 16, 2015 22:27:05 Warstone на list.ru wrote:
> Раз уж тут пошла такая пьянка... Давайте сделаем ORM для PostgreSQL с
> поддержкой асинхронности и возможностью прямого SQL запроса и
> конвертирования результатов в спец типы.
> 
> Идея основана на том, что EXPLAIN VERBOSE всегда расскажет какие поля и
> откуда взяты (даже в случае с WITH), вот допустим:
> 
>  EXPLAIN VERBOSE WITH foo AS (SELECT * FROM test) SELECT * FROM foo;
>                                  QUERY PLAN
> ----------------------------------------------------------------------------
> - CTE Scan on foo  (cost=21.60..44.80 rows=1160 width=40)
>    Output: foo.id, foo.data
>    CTE foo
>      ->  Seq Scan on pg_temp_111.test  (cost=0.00..21.60 rows=1160 width=40)
> Output: test.id, test.data
> 
> Смысл в том, что на каждый raw запрос (с кешированием, понятно) запрашивать
> EXPLAIN этого запроса и по результатам строить аксессоры. Или не строить ))

Не совсем понятен смысл именно EXPLAIN. Для аксессоров достаточно сделать 
execute и ещё до фетча уже будет всё выдано в %fields = %{$sth->{NAME_hash}};
-- 
PEF Developer

From warstone на list.ru  Fri Jan 16 12:39:53 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Fri, 16 Jan 2015 23:39:53 +0300
Subject: [Moscow.pm] =?utf-8?b?0JrQvtC90YbQtdC/0YbQuNGPIE9STdCw?=
In-Reply-To: <6197565.IVtKcrUBhx@rawen>
References: <1421436425.648333753@f351.i.mail.ru>
 <6197565.IVtKcrUBhx@rawen>
Message-ID: <1421440793.285840448@f314.i.mail.ru>

 Смысл в том, что мы при произвольном запросе будем знать из какой таблицы эта колонка и можем, используя метаинформацию, заданную в схеме, конструировать свои типы данных, а не дефолтные Пгшные. Например у нас есть таблица UserId,(BIGINT) ACL(JSON), делая что-то типа: $db->query("SELECT * FROM users WHERE userid = ?", $userid)->ACL->check_rights_for("MyACLKey"). Или если у нас там id со связанной таблицей, то мы можем при обращении к этому полю прозрачно выполнить SQL запрос на выборку информации по этому полю. Вариантов море. И это довольно хороший сахар.


Fri, 16 Jan 2015 21:08:01 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Friday, January 16, 2015 22:27:05  Warstone на list.ru wrote:
>> Раз уж тут пошла такая пьянка... Давайте сделаем ORM для PostgreSQL с
>> поддержкой асинхронности и возможностью прямого SQL запроса и
>> конвертирования результатов в спец типы.
>> 
>> Идея основана на том, что EXPLAIN VERBOSE всегда расскажет какие поля и
>> откуда взяты (даже в случае с WITH), вот допустим:
>> 
>>  EXPLAIN VERBOSE WITH foo AS (SELECT * FROM test) SELECT * FROM foo;
>>                                  QUERY PLAN
>> ----------------------------------------------------------------------------
>> - CTE Scan on foo  (cost=21.60..44.80 rows=1160 width=40)
>>    Output: foo.id, foo.data
>>    CTE foo
>>      ->  Seq Scan on pg_temp_111.test  (cost=0.00..21.60 rows=1160 width=40)
>> Output: test.id, test.data
>> 
>> Смысл в том, что на каждый raw запрос (с кешированием, понятно) запрашивать
>> EXPLAIN этого запроса и по результатам строить аксессоры. Или не строить ))
>
>Не совсем понятен смысл именно EXPLAIN. Для аксессоров достаточно сделать 
>execute и ещё до фетча уже будет всё выдано в %fields = %{$sth->{NAME_hash}};
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/f14daa1d/attachment.html>

From i.petro.77.00 на gmail.com  Fri Jan 16 13:29:24 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Sat, 17 Jan 2015 00:29:24 +0300
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPICBEQkl4OjpTdHJ1Y3Q=?=
In-Reply-To: <CA+kq2xvfCEAp9aRJsmdD7ssq+UEOjG_5bj_2b2nTXwW0riPGWQ@mail.gmail.com>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
	<CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
	<20150116153605.GT6552@vdsl.uvw.ru>
	<CA+kq2xsFgeoBSeUETUbBRKRDJF_JPfv3qkA=Lppi-7TL=yNRFA@mail.gmail.com>
	<20150116180742.GV6552@vdsl.uvw.ru>
	<CA+kq2xvfCEAp9aRJsmdD7ssq+UEOjG_5bj_2b2nTXwW0riPGWQ@mail.gmail.com>
Message-ID: <20150116212923.GW6552@vdsl.uvw.ru>

> Мнение этой рассылки относительно того, зло ORM или нет, является для
> меня столь же важным, как и мнение кофемашины о причинах глобального
> потепления. Тем более, с учетом смысла и значения слова "доказали". У
> вас тут Хабрахабр, что ли? Доказанным считается утверждение, за
> которое проголосует большая часть электората? На объективную истину
> всем плевать?

Слоник в домене не твой ли ЖЖ?
и тупизм такой же точно и такие же безаппеляционные заявы с намерением
возвыситься над аудиторией

что, там уже совсем все ушли чтоли?


From alexclear на gmail.com  Fri Jan 16 13:52:52 2015
From: alexclear на gmail.com (Alex Chistyakov)
Date: Sat, 17 Jan 2015 01:52:52 +0400
Subject: [Moscow.pm] =?utf-8?b?djIg0L/RgNC+0YHRjNCx0LAg0L4g0YDQtdCy0Yw=?=
	=?utf-8?b?0Y4g0LzQvtC00YPQu9GPIERCSXg6OlN0cnVjdA==?=
In-Reply-To: <20150116212923.GW6552@vdsl.uvw.ru>
References: <1858407.iHouSzOesI@rawen> <1421329180.20345538@f361.i.mail.ru>
	<20150115194416.GM6552@vdsl.uvw.ru>
	<CA+kq2xsjV4=3Y2xfjKbUcxuA7JZpokbsQKqTTYURXbT+agNZWA@mail.gmail.com>
	<20150116090228.GP6552@vdsl.uvw.ru>
	<CA+kq2xuo6+vjqd3skoJGZYxSUAerqFR_jBkrSc_ccOLE9FZ3Tw@mail.gmail.com>
	<20150116153605.GT6552@vdsl.uvw.ru>
	<CA+kq2xsFgeoBSeUETUbBRKRDJF_JPfv3qkA=Lppi-7TL=yNRFA@mail.gmail.com>
	<20150116180742.GV6552@vdsl.uvw.ru>
	<CA+kq2xvfCEAp9aRJsmdD7ssq+UEOjG_5bj_2b2nTXwW0riPGWQ@mail.gmail.com>
	<20150116212923.GW6552@vdsl.uvw.ru>
Message-ID: <CA+kq2xvomNYJ3Qr2RMGDDhvY_7Ny2LkuJ2qAZg-R4cvxakBCDA@mail.gmail.com>

2015-01-17 0:29 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> Мнение этой рассылки относительно того, зло ORM или нет, является для
>> меня столь же важным, как и мнение кофемашины о причинах глобального
>> потепления. Тем более, с учетом смысла и значения слова "доказали". У
>> вас тут Хабрахабр, что ли? Доказанным считается утверждение, за
>> которое проголосует большая часть электората? На объективную истину
>> всем плевать?
>
> Слоник в домене не твой ли ЖЖ?

Ну - почти.
Мне тут, кстати, парни рассказали, кто вы - ну да, у нас как-то
получается раз в два года зарубаться. :)

> и тупизм такой же точно

И в чем мой тупизм?
Ну - объективно, с фактами?

> и такие же безаппеляционные заявы

Которые, наверное, легко опровергнуть, нет?
Почему я не вижу желающих?..

> с намерением
> возвыситься над аудиторией

...не потому ли, что аудитория - возомнившие себя звездами лошки?
Какие у вас основания считать себя звездами, коллеги, если вас
залетный бывший (БЫВШИЙ!) джавист с претензиями (необоснованными)
второй день на вашем же поле уделывает?
Что вы можете мне противопоставить, кроме невнятного мычания о том,
как планировщик MySQL делает неизвестную и необъяснимую магию, OMG.

> что, там уже совсем все ушли чтоли?

Ну - я так и знал, что ad hominem начнется, раз других аргументов и фактов нет.
Je suis slonik_v_domene, некоторым образом.
Сегодня все мы slonik_v_domene.

--
SY,
Alex


>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From mi на ya.ru  Fri Jan 16 14:12:05 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Sat, 17 Jan 2015 01:12:05 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
	=?koi8-r?b?ztTF0s7F1ME=?=
In-Reply-To: <CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
Message-ID: <8175871421446325@web20h.yandex.ru>

Макс, интересно, что
в Ubuntu
строка 
cpanm Genealogy-Gedcom-0.83.tgz
- работает,а
в windows 7 - нет, 
но работает так
cpanm RSAVAGE/Genealogy-Gedcom-0.83.tgz
только , если архив находится в папке,
правда это ровно по документации:
cpanm MIYAGAWA/Plack-0.99_05.tar.gz                       # full distribution path




13.01.2015, 21:37, "Maxim Vuets" <maxim.vuets на gmail.com>:
> Николай,
>
> 2015-01-13 19:24 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
>>  На работе перекты консольный доступ к инету, можно только скачивать с сайта.
>
> Не совсем понятно в чём здесь разница между "консольным доступом" и
> "скачиванием с сайта"?
>
> Может у вас http прокси на работе? И браузер о нём знает (например,
> https://ru.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol), а
> консольному приложению нужно явно об этом сказать. Например, через
> переменные окружения http_proxy и т.п.
>>  Написал следующий батник
>>
>>  https://github.com/mishin/Datastage-DsxParse/blob/master/scripts/install_perl_module.bat
>>
>>  file_src=File-Slurp-Tiny-0.003.tar.gz
>
> ...
>
> Я не вникал в логику твоего батника, но может стоит использовать
> хороший проверенный cpanm? Он умеет устанавливать дистр из локального
> тарбола:
>
>   cpanm ~/dists/MyCompany-Enterprise-1.00.tar.gz   # install from a local file
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением
Николай Мишин


From mi на ya.ru  Fri Jan 16 14:58:46 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Sat, 17 Jan 2015 01:58:46 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
	=?koi8-r?b?ztTF0s7F1ME=?=
In-Reply-To: <CAG6DbojPyUZj26scznK9ULUK_8fDd2r7GKfPNK=99bvSAy1YfA@mail.gmail.com>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
	<1131081421178700@web21h.yandex.ru>
	<CAG6DbojPyUZj26scznK9ULUK_8fDd2r7GKfPNK=99bvSAy1YfA@mail.gmail.com>
Message-ID: <8076721421449126@web12j.yandex.ru>

поставил cpanmini
cpanm https://cpan.metacpan.org/authors/id/R/RJ/RJBS/CPAN-Mini-1.111016.tar.gz
создал файл 
c:\Users\TOSH\Documents\GitHub\mirror\.minicpanrc 
с содержанием
local:  c:/Users/TOSH/Documents/GitHub/mirror
remote: http://mirrors.xmu.edu.cn/CPAN/
exact_mirror: 1
запустил 
cd c:\Users\TOSH\Documents\GitHub\mirror
cpanmini -C FILE .\.minicpanrc
и теперь он начал скачивать дистрибутивы 
в 
c:\Users\TOSH\Documents\GitHub\mirror\authors 
интересно, а я могу все эти 500Мб залить на гитхаб?,
а то на работе сеть перекрыта, флешку вставить нельзя

13.01.2015, 23:01, "Maxim Vuets" <maxim.vuets на gmail.com>:
> 2015-01-13 20:51 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
>>  Спасибо за совет
>>  1) почему-то cpanm не работает, запущу завтра и покажу ошибки, если они вообще будут
>
> Давай.
>>  2)в pac файле несколько прокси
>>  и неясно, как указать их все,
>
> А все указать и не удастся )-: pac файл это джаваскрипт-подобная
> программа, которую исполняет браузер для  маршрутизации твоих запросов
> на разные прокси сервера в зависимости от разных параметров (типа
> имени хоста или IP адреса).
>
> Но поскольку CPAN находится в пределах одного хоста, ты можешь явно и
> конкретно для cpanm устанавливать подходящий http_proxy.
>
> Как альтернатива, сделай себе один раз локальное зеркало при помощи
> https://metacpan.org/pod/distribution/CPAN-Mini/bin/minicpan (можно
> даже дома на нормальном интернете), и потом ставь пакеты оттуда:
>   cpanm --mirror /path/to/the/local/mirror --mirror-only Module::Name
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением
Николай Мишин


From maxim.vuets на gmail.com  Sat Jan 17 03:35:52 2015
From: maxim.vuets на gmail.com (Maxim Vuets)
Date: Sat, 17 Jan 2015 12:35:52 +0100
Subject: [Moscow.pm] =?utf-8?b?0YPRgdGC0LDQvdC+0LLQutCwINC80L7QtNGD0Ls=?=
	=?utf-8?b?0LXQuSDQv9C+IHdpbiDQsdC10Lcg0LjQvdGC0LXRgNC90LXRgtCw?=
In-Reply-To: <8076721421449126@web12j.yandex.ru>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
	<1131081421178700@web21h.yandex.ru>
	<CAG6DbojPyUZj26scznK9ULUK_8fDd2r7GKfPNK=99bvSAy1YfA@mail.gmail.com>
	<8076721421449126@web12j.yandex.ru>
Message-ID: <CAG6DbojU9ka6Gk14=NghPrLvhbtcs0giiTN=oodXX7bXe5r0ng@mail.gmail.com>

2015-01-16 23:58 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
> remote: http://mirrors.xmu.edu.cn/CPAN/

Неужели китайское зеркало ближе всего к тебе? (-:

> интересно, а я могу все эти 500Мб залить на гитхаб?,
> а то на работе сеть перекрыта, флешку вставить нельзя

500 МБ это размер чего? У меня полное зеркало занимает более 3 ГБ.

Такую кучу бинарников заливать на гитхаб, конечно, чревато проблемами.
https://help.github.com/articles/what-is-my-disk-quota/#rule-of-thumb-1gb-per-repository-100mb-per-file
Лучше уже просто на какой-то файлообменник.

Сурово у вас как-то. Неужели есть доступ к гитхабу, а к сипану нет? Я
бы этот вопрос выяснил с админами: тебе же сипан для работы нужен.

From mi на ya.ru  Sat Jan 17 06:45:36 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Sat, 17 Jan 2015 17:45:36 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
	=?koi8-r?b?ztTF0s7F1ME=?=
In-Reply-To: <CAG6DbojU9ka6Gk14=NghPrLvhbtcs0giiTN=oodXX7bXe5r0ng@mail.gmail.com>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
	<1131081421178700@web21h.yandex.ru>
	<CAG6DbojPyUZj26scznK9ULUK_8fDd2r7GKfPNK=99bvSAy1YfA@mail.gmail.com>
	<8076721421449126@web12j.yandex.ru>
	<CAG6DbojU9ka6Gk14=NghPrLvhbtcs0giiTN=oodXX7bXe5r0ng@mail.gmail.com>
Message-ID: <2320281421505936@web19g.yandex.ru>

Да, Макс, 3Гб получилось,
да мне уже как-то блокировали репозиторий на гитхабе с файлами > 100 М,
придется идти к админам

правда установить из зеркала под винду не получилось

cpanm --mirror c:\Users\TOSH\Documents\GitHub\mirror --mirror-only  Genealogy::Gedcom
! cannot open file '/.cpanm/sources/c%Users%TOSH%Documents%GitHub%mirror/02packages.details.txt.gz': No such file or directory opening compressed index
! Couldn't find module or a distribution Genealogy::Gedcom ()

изменение слешей 
cpanm --mirror c:/Users/TOSH/Documents/GitHub/mirror --mirror-only  Genealogy::Gedcom

дает туже ошибку

17.01.2015, 14:36, "Maxim Vuets" <maxim.vuets на gmail.com>:
> 2015-01-16 23:58 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
>>  remote: http://mirrors.xmu.edu.cn/CPAN/
>
> Неужели китайское зеркало ближе всего к тебе? (-:
>>  интересно, а я могу все эти 500Мб залить на гитхаб?,
>>  а то на работе сеть перекрыта, флешку вставить нельзя
>
> 500 МБ это размер чего? У меня полное зеркало занимает более 3 ГБ.
>
> Такую кучу бинарников заливать на гитхаб, конечно, чревато проблемами.
> https://help.github.com/articles/what-is-my-disk-quota/#rule-of-thumb-1gb-per-repository-100mb-per-file
> Лучше уже просто на какой-то файлообменник.
>
> Сурово у вас как-то. Неужели есть доступ к гитхабу, а к сипану нет? Я
> бы этот вопрос выяснил с админами: тебе же сипан для работы нужен.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением
Николай Мишин


From maxim.vuets на gmail.com  Sun Jan 18 14:00:22 2015
From: maxim.vuets на gmail.com (Maxim Vuets)
Date: Sun, 18 Jan 2015 23:00:22 +0100
Subject: [Moscow.pm] =?utf-8?b?0YPRgdGC0LDQvdC+0LLQutCwINC80L7QtNGD0Ls=?=
	=?utf-8?b?0LXQuSDQv9C+IHdpbiDQsdC10Lcg0LjQvdGC0LXRgNC90LXRgtCw?=
In-Reply-To: <2320281421505936@web19g.yandex.ru>
References: <952071421173464@web29h.yandex.ru>
	<CAG6DbojomQV00YJRsGW9k_CEBQjAc_ZNy7XA1u2_v==T7SXzTA@mail.gmail.com>
	<1131081421178700@web21h.yandex.ru>
	<CAG6DbojPyUZj26scznK9ULUK_8fDd2r7GKfPNK=99bvSAy1YfA@mail.gmail.com>
	<8076721421449126@web12j.yandex.ru>
	<CAG6DbojU9ka6Gk14=NghPrLvhbtcs0giiTN=oodXX7bXe5r0ng@mail.gmail.com>
	<2320281421505936@web19g.yandex.ru>
Message-ID: <CAG6DbogHeiy386UQNPGcSGSdPFL2T1NECUiWt5FU=Tae+Biigw@mail.gmail.com>

Николай,

2015-01-17 15:45 GMT+01:00 Nikolay Mishin <mi на ya.ru>:
> правда установить из зеркала под винду не получилось
>
> cpanm --mirror c:\Users\TOSH\Documents\GitHub\mirror --mirror-only  Genealogy::Gedcom
> ! cannot open file '/.cpanm/sources/c%Users%TOSH%Documents%GitHub%mirror/02packages.details.txt.gz': No such file or directory opening compressed index
> ! Couldn't find module or a distribution Genealogy::Gedcom ()

Путь в тексте ошибки выглядит очень странно )-: К сожалению, у меня
нет под рукой Windows машины, что бы помочь тебе продиагностировать
эту ошибку. Может быть, попробуй открыть баг на
https://github.com/miyagawa/cpanminus/issues. Или перемести зеркало в
директорию, что бы путь имела попроще, типа C:\cpan

Успехов!

From ruslan.zakirov на gmail.com  Tue Jan 20 01:36:27 2015
From: ruslan.zakirov на gmail.com (Ruslan Zakirov)
Date: Tue, 20 Jan 2015 13:36:27 +0400
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
In-Reply-To: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
Message-ID: <CAMOxC8tvcm69C+3=_b3q4n8uGJg5d2=+ocmO38NtU8ywNF757A@mail.gmail.com>

Marpa, Parse::RecDescent, Parse::Yapp, Parse::Eyapp.

Первый мне очень нравиться. Попрбуйте с MarpaX::Repa. "Репу" написал сам и
мне очень удобно с ним писать  парсеры ибо можно написать грамматику и не
определить все токены, то есть итеративно дополнять в процессе свой парсер
без фатальных ошибок на этапе компиляции парсера. В новых версиях Marpa
есть Scanless интерфейс - это самое близкое к Repa так как включает лексер
и самое простое для начала.

2015-01-14 12:34 GMT+03:00 Харпалёв Иван <ivan.kharpalev на gmail.com>:

> Доброго времени, могучий MoscowPM!
>
> Сейчас пишу небольшой язык.
> То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
> потренироваться, а потом в C, там типизация, там сложнее).
>
> Когда язык был совсем примитивный, я его парсил регэкспами и по
> рабоче-крестьянски собирал код на целевом языке.
> Но язык подростает. И рефакторить оказывается очень печально.
>
> Как я понимаю весь процесс работы транслятора состоит из стандартных
> стадий, например:
> токенизация
> построение дерева разбора
> сбор кода на целевом языке из полученного описания.
>
> В общем тория у меня хромает и очень интересна. Но первым делом практика.
> Скажите, чем строить дерево синтаксического разбора?
> что-то вроде
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
Best regards, Ruslan.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150120/5786ff50/attachment.html>

From chesnokov.ilya на gmail.com  Thu Jan 22 12:07:15 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 23 Jan 2015 00:07:15 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
Message-ID: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>

Всем привет.

А какие есть удобные Perl-модули для организации очереди задач?
Желательно с возможностью выбора бэкенда для хранения данных очередей
и задач.

Есть ли модули, которые в качестве бэкенда используют RabbitMQ?

Нужно по работе написать что-то подобное, но хочу для начала
промониторить существующие решения.

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

Спасибо.
-- 
Best regards,
Ilya Chesnokov

From mi на ya.ru  Thu Jan 22 12:12:11 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 22 Jan 2015 23:12:11 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?1dPUwc7P18vBIM3PxNXMxcog0M8gd2luIMLF2iDJ?=
	=?koi8-r?b?ztTF0s7F1ME=?=
Message-ID: <3798271421957531@web10g.yandex.ru>

спасибо call ptar спас отца русской демократии;)

From mi на ya.ru  Thu Jan 22 12:28:41 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 22 Jan 2015 23:28:41 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?88nO1MHL08nexdPLycogwc7BzMnaIM7BIFBlcmwu?=
	=?koi8-r?b?IPTSwc7TzNHUz9Iu?=
Message-ID: <3741531421958521@web19g.yandex.ru>

Руслан,
я тут понаписав парсеров на регулярках
с удовольсвием послушал бы про MarpaX::Repa
и как с помощью него распарсить скажем css
или html, если это, конечно, возможно,
ну для примера, как сделать грамматику для такой конструкции:

      BEGIN DSSUBRECORD
         Name "$APT_DBNAME"
         Prompt "DB2 Database"
         Default "BANKDATA"
         HelpTxt "Default DB2 database to use"
         ParamType "0"
         ParamLength "0"
         ParamScale "0"
      END DSSUBRECORD

если это вообще стоит делать,т.к. я просто
это распарсил такой функцией:

sub split_fields_by_new_line {
    my ($curr_record) = @_;
    my %fields_and_values = ();
    while (
        $curr_record =~ m/
(?<name>\w+)[ ]"(?<value>.*?)(?<!\\)"|
((?<name2>\w+)[ ]\Q=+=+=+=\E
(?<value2>.*?)
\Q=+=+=+=\E)
/xsg
      )
    {
        my ($value, $name) = ('', '');
        if (defined $+{name}) {
            $name  = $+{name};
            $value = $+{value};
        }
        elsif (defined $+{name2}) {
            $name  = $+{name2};
            $value = $+{value2};
        }
        $fields_and_values{$name} = $value;
    }
    return \%fields_and_values;
}



> Marpa, Parse::RecDescent, Parse::Yapp, Parse::Eyapp.
> 
> Первый мне очень нравиться. Попрбуйте с MarpaX::Repa. "Репу" написал сам и мне очень удобно с ним писать парсеры ибо можно написать грамматику и не определить все токены, то есть итеративно дополнять в процессе свой парсер без фатальных ошибок на этапе компиляции парсера. В новых версиях Marpa есть Scanless интерфейс - это самое близкое к Repa так как включает лексер и самое простое для начала.
> 
> 2015-01-14 12:34 GMT+03:00 Харпалёв Иван <ivan.kharpalev на gmail.com>:
> 
>> Доброго времени, могучий MoscowPM!
>>
>> Сейчас пишу небольшой язык.
>> То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы потренироваться, а потом в C, там типизация, там сложнее).
>>
>> Когда язык был совсем примитивный, я его парсил регэкспами и по рабоче-крестьянски собирал код на целевом языке.
>> Но язык подростает. И рефакторить оказывается очень печально.
>>
>> Как я понимаю весь процесс работы транслятора состоит из стандартных стадий, например:
>> токенизация
>> построение дерева разбора
>> сбор кода на целевом языке из полученного описания.
>>
>> В общем тория у меня хромает и очень интересна. Но первым делом практика.
>> Скажите, чем строить дерево синтаксического разбора?
>> что-то вроде
>>
>> --
>>
>> Moscow.pm mailing list
>>
>> moscow-pm на pm.org | http://moscow.pm.org
> 
> --
> Best regards, Ruslan.
-- 
С уважением
Николай Мишин
 


From vaneska.ru на gmail.com  Thu Jan 22 21:04:19 2015
From: vaneska.ru на gmail.com (=?UTF-8?B?0JjQstCw0L0g0KHQvtC60L7Qu9C+0LI=?=)
Date: Fri, 23 Jan 2015 09:04:19 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
Message-ID: <CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>

Привет.
Мы свою написали на редисе.
За неимением для Perl хороших решений и особых требований от нас к очереди.


22 января 2015 г., 23:07 пользователь Ilya Chesnokov <
chesnokov.ilya на gmail.com> написал:

> Всем привет.
>
> А какие есть удобные Perl-модули для организации очереди задач?
> Желательно с возможностью выбора бэкенда для хранения данных очередей
> и задач.
>
> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>
> Нужно по работе написать что-то подобное, но хочу для начала
> промониторить существующие решения.
>
> На данный момент вижу Minion с явной поддержкой различных бэкендов -
> можно попробовать к нему прикрутить все что нужно, конечно - но может
> еще что-то есть.
>
> Спасибо.
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
Иван
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/38f8bb48/attachment.html>

From maxim.vuets на gmail.com  Fri Jan 23 00:39:58 2015
From: maxim.vuets на gmail.com (Maxim Vuets)
Date: Fri, 23 Jan 2015 09:39:58 +0100
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
Message-ID: <CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>

2015-01-22 21:07 GMT+01:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> А какие есть удобные Perl-модули для организации очереди задач?
> Желательно с возможностью выбора бэкенда для хранения данных очередей
> и задач.

Мы написали и пользуемся вот этим:
https://metacpan.org/pod/Queue::Q::ReliableFIFO::Redis
Но там только Редис в качестве бекенда.

From dzirtik на gmail.com  Fri Jan 23 00:41:57 2015
From: dzirtik на gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQqdC10YDQsdC40L3QuNC9?=)
Date: Fri, 23 Jan 2015 12:41:57 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
Message-ID: <CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>

Привет, Вань. 5 февраля Moscow.pm может расскажете о своей очереди?))
23 янв. 2015 г. 8:04 пользователь "Иван Соколов" <vaneska.ru на gmail.com>
написал:

> Привет.
> Мы свою написали на редисе.
> За неимением для Perl хороших решений и особых требований от нас к очереди.
>
>
> 22 января 2015 г., 23:07 пользователь Ilya Chesnokov <
> chesnokov.ilya на gmail.com> написал:
>
>> Всем привет.
>>
>> А какие есть удобные Perl-модули для организации очереди задач?
>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>> и задач.
>>
>> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>>
>> Нужно по работе написать что-то подобное, но хочу для начала
>> промониторить существующие решения.
>>
>> На данный момент вижу Minion с явной поддержкой различных бэкендов -
>> можно попробовать к нему прикрутить все что нужно, конечно - но может
>> еще что-то есть.
>>
>> Спасибо.
>> --
>> Best regards,
>> Ilya Chesnokov
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
>
> --
> С уважением,
> Иван
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/6ccf875c/attachment-0001.html>

From vaneska.ru на gmail.com  Fri Jan 23 01:46:24 2015
From: vaneska.ru на gmail.com (=?UTF-8?B?0JjQstCw0L0g0KHQvtC60L7Qu9C+0LI=?=)
Date: Fri, 23 Jan 2015 13:46:24 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
	<CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
Message-ID: <CAMgEUECJPGNz=7pTmYz7NTef9HVNrHquA5zLhos1pxw5uEA6fw@mail.gmail.com>

Привет, Паша.
Расскажу.

23 января 2015 г., 11:41 пользователь Павел Щербинин <dzirtik на gmail.com>
написал:

> Привет, Вань. 5 февраля Moscow.pm может расскажете о своей очереди?))
> 23 янв. 2015 г. 8:04 пользователь "Иван Соколов" <vaneska.ru на gmail.com>
> написал:
>
> Привет.
>> Мы свою написали на редисе.
>> За неимением для Perl хороших решений и особых требований от нас к
>> очереди.
>>
>>
>> 22 января 2015 г., 23:07 пользователь Ilya Chesnokov <
>> chesnokov.ilya на gmail.com> написал:
>>
>>> Всем привет.
>>>
>>> А какие есть удобные Perl-модули для организации очереди задач?
>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>>> и задач.
>>>
>>> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>>>
>>> Нужно по работе написать что-то подобное, но хочу для начала
>>> промониторить существующие решения.
>>>
>>> На данный момент вижу Minion с явной поддержкой различных бэкендов -
>>> можно попробовать к нему прикрутить все что нужно, конечно - но может
>>> еще что-то есть.
>>>
>>> Спасибо.
>>> --
>>> Best regards,
>>> Ilya Chesnokov
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>
>>
>>
>> --
>> С уважением,
>> Иван
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением,
Иван
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/76066111/attachment.html>

From aml на rulezz.ru  Fri Jan 23 01:50:14 2015
From: aml на rulezz.ru (Alexander Lourier)
Date: Fri, 23 Jan 2015 09:50:14 +0000
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
	<CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
	<CAMgEUECJPGNz=7pTmYz7NTef9HVNrHquA5zLhos1pxw5uEA6fw@mail.gmail.com>
Message-ID: <CANLU1qECQi1aLehygMHjNywV_dwzLmvPKTAvkfJ3kEEwxw_sOQ@mail.gmail.com>

А запись будет?

On Fri Jan 23 2015 at 10:46:37 AM Иван Соколов <vaneska.ru на gmail.com> wrote:

> Привет, Паша.
> Расскажу.
>
> 23 января 2015 г., 11:41 пользователь Павел Щербинин <dzirtik на gmail.com>
> написал:
>
> Привет, Вань. 5 февраля Moscow.pm может расскажете о своей очереди?))
>> 23 янв. 2015 г. 8:04 пользователь "Иван Соколов" <vaneska.ru на gmail.com>
>> написал:
>>
>> Привет.
>>> Мы свою написали на редисе.
>>> За неимением для Perl хороших решений и особых требований от нас к
>>> очереди.
>>>
>>>
>>> 22 января 2015 г., 23:07 пользователь Ilya Chesnokov <
>>> chesnokov.ilya на gmail.com> написал:
>>>
>>>> Всем привет.
>>>>
>>>> А какие есть удобные Perl-модули для организации очереди задач?
>>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>>>> и задач.
>>>>
>>>> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>>>>
>>>> Нужно по работе написать что-то подобное, но хочу для начала
>>>> промониторить существующие решения.
>>>>
>>>> На данный момент вижу Minion с явной поддержкой различных бэкендов -
>>>> можно попробовать к нему прикрутить все что нужно, конечно - но может
>>>> еще что-то есть.
>>>>
>>>> Спасибо.
>>>> --
>>>> Best regards,
>>>> Ilya Chesnokov
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>
>>>
>>>
>>> --
>>> С уважением,
>>> Иван
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>
>
> --
> С уважением,
> Иван
>  --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/d38d07d8/attachment.html>

From dzirtik на gmail.com  Fri Jan 23 02:33:20 2015
From: dzirtik на gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQqdC10YDQsdC40L3QuNC9?=)
Date: Fri, 23 Jan 2015 13:33:20 +0300
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANLU1qECQi1aLehygMHjNywV_dwzLmvPKTAvkfJ3kEEwxw_sOQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
	<CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
	<CAMgEUECJPGNz=7pTmYz7NTef9HVNrHquA5zLhos1pxw5uEA6fw@mail.gmail.com>
	<CANLU1qECQi1aLehygMHjNywV_dwzLmvPKTAvkfJ3kEEwxw_sOQ@mail.gmail.com>
Message-ID: <CAJxdCZ49tiGVVghi0NHYrFvRfbVyCW+tNP3x2d9ZXMPbxDv-6g@mail.gmail.com>

Будет и запись и прямая трансляция!

23 января 2015 г., 12:50 пользователь Alexander Lourier <aml на rulezz.ru>
написал:

> А запись будет?
>
> On Fri Jan 23 2015 at 10:46:37 AM Иван Соколов <vaneska.ru на gmail.com>
> wrote:
>
>> Привет, Паша.
>> Расскажу.
>>
>> 23 января 2015 г., 11:41 пользователь Павел Щербинин <dzirtik на gmail.com>
>> написал:
>>
>> Привет, Вань. 5 февраля Moscow.pm может расскажете о своей очереди?))
>>> 23 янв. 2015 г. 8:04 пользователь "Иван Соколов" <vaneska.ru на gmail.com>
>>> написал:
>>>
>>> Привет.
>>>> Мы свою написали на редисе.
>>>> За неимением для Perl хороших решений и особых требований от нас к
>>>> очереди.
>>>>
>>>>
>>>> 22 января 2015 г., 23:07 пользователь Ilya Chesnokov <
>>>> chesnokov.ilya на gmail.com> написал:
>>>>
>>>>> Всем привет.
>>>>>
>>>>> А какие есть удобные Perl-модули для организации очереди задач?
>>>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>>>>> и задач.
>>>>>
>>>>> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>>>>>
>>>>> Нужно по работе написать что-то подобное, но хочу для начала
>>>>> промониторить существующие решения.
>>>>>
>>>>> На данный момент вижу Minion с явной поддержкой различных бэкендов -
>>>>> можно попробовать к нему прикрутить все что нужно, конечно - но может
>>>>> еще что-то есть.
>>>>>
>>>>> Спасибо.
>>>>> --
>>>>> Best regards,
>>>>> Ilya Chesnokov
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> С уважением,
>>>> Иван
>>>>
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>>
>>
>>
>> --
>> С уважением,
>> Иван
>>  --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С Уважением,
Щербинин Павел
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/94b987e4/attachment-0001.html>

From aml на rulezz.ru  Fri Jan 23 03:19:21 2015
From: aml на rulezz.ru (Alexander Lourier)
Date: Fri, 23 Jan 2015 11:19:21 +0000
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
	<CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
	<CAMgEUECJPGNz=7pTmYz7NTef9HVNrHquA5zLhos1pxw5uEA6fw@mail.gmail.com>
	<CANLU1qECQi1aLehygMHjNywV_dwzLmvPKTAvkfJ3kEEwxw_sOQ@mail.gmail.com>
	<CAJxdCZ49tiGVVghi0NHYrFvRfbVyCW+tNP3x2d9ZXMPbxDv-6g@mail.gmail.com>
Message-ID: <CANLU1qGUTcsKQCs7iPpPhnf+hf7+0XRKdvci_TkJ2VX18XEEng@mail.gmail.com>

Круто, спасибо!

On Fri Jan 23 2015 at 11:33:33 AM Павел Щербинин <dzirtik на gmail.com> wrote:

> Будет и запись и прямая трансляция!
>
> 23 января 2015 г., 12:50 пользователь Alexander Lourier <aml на rulezz.ru>
> написал:
>
> А запись будет?
>>
>> On Fri Jan 23 2015 at 10:46:37 AM Иван Соколов <vaneska.ru на gmail.com>
>> wrote:
>>
>>> Привет, Паша.
>>> Расскажу.
>>>
>>> 23 января 2015 г., 11:41 пользователь Павел Щербинин <dzirtik на gmail.com>
>>> написал:
>>>
>>> Привет, Вань. 5 февраля Moscow.pm может расскажете о своей очереди?))
>>>> 23 янв. 2015 г. 8:04 пользователь "Иван Соколов" <vaneska.ru на gmail.com>
>>>> написал:
>>>>
>>>> Привет.
>>>>> Мы свою написали на редисе.
>>>>> За неимением для Perl хороших решений и особых требований от нас к
>>>>> очереди.
>>>>>
>>>>>
>>>>> 22 января 2015 г., 23:07 пользователь Ilya Chesnokov <
>>>>> chesnokov.ilya на gmail.com> написал:
>>>>>
>>>>>> Всем привет.
>>>>>>
>>>>>> А какие есть удобные Perl-модули для организации очереди задач?
>>>>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>>>>>> и задач.
>>>>>>
>>>>>> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>>>>>>
>>>>>> Нужно по работе написать что-то подобное, но хочу для начала
>>>>>> промониторить существующие решения.
>>>>>>
>>>>>> На данный момент вижу Minion с явной поддержкой различных бэкендов -
>>>>>> можно попробовать к нему прикрутить все что нужно, конечно - но может
>>>>>> еще что-то есть.
>>>>>>
>>>>>> Спасибо.
>>>>>> --
>>>>>> Best regards,
>>>>>> Ilya Chesnokov
>>>>>> --
>>>>>> Moscow.pm mailing list
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> С уважением,
>>>>> Иван
>>>>>
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>>
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>>
>>>
>>>
>>> --
>>> С уважением,
>>> Иван
>>>  --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>
>
> --
> С Уважением,
> Щербинин Павел
>  --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/5d76b7eb/attachment.html>

From ruslan.zakirov на gmail.com  Fri Jan 23 03:20:25 2015
From: ruslan.zakirov на gmail.com (Ruslan Zakirov)
Date: Fri, 23 Jan 2015 15:20:25 +0400
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
	=?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+?=
	=?utf-8?b?0YAu?=
In-Reply-To: <3741531421958521@web19g.yandex.ru>
References: <3741531421958521@web19g.yandex.ru>
Message-ID: <CAMOxC8tOYoHShMYc6BSRr_Wq0QaP45q2JitEJXxRZWDjMFwF0w@mail.gmail.com>

2015-01-22 23:28 GMT+03:00 Nikolay Mishin <mi на ya.ru>:

> Руслан,
> я тут понаписав парсеров на регулярках
> с удовольсвием послушал бы про MarpaX::Repa
> и как с помощью него распарсить скажем css
> или html, если это, конечно, возможно,
>

С HTML сложно, но возможно, есть Marpa::HTML (не помню точное имя) который
делает парсинг согласно HTML5 стандарту (по словам автора модуля, он же
автор Marpa). Там все старшно внутри.


> ну для примера, как сделать грамматику для такой конструкции:
>
>       BEGIN DSSUBRECORD
>          Name "$APT_DBNAME"
>          Prompt "DB2 Database"
>          Default "BANKDATA"
>          HelpTxt "Default DB2 database to use"
>          ParamType "0"
>          ParamLength "0"
>          ParamScale "0"
>       END DSSUBRECORD
>
> если это вообще стоит делать,т.к. я просто
> это распарсил такой функцией:
>

cd ~/projs/mods/MarpaX-Repa/
git co master

cp examples/template.pl ttt.pl
vi ttt.pl

прикрепил

>
> sub split_fields_by_new_line {
>     my ($curr_record) = @_;
>     my %fields_and_values = ();
>     while (
>         $curr_record =~ m/
> (?<name>\w+)[ ]"(?<value>.*?)(?<!\\)"|
> ((?<name2>\w+)[ ]\Q=+=+=+=\E
> (?<value2>.*?)
> \Q=+=+=+=\E)
> /xsg
>       )
>     {
>         my ($value, $name) = ('', '');
>         if (defined $+{name}) {
>             $name  = $+{name};
>             $value = $+{value};
>         }
>         elsif (defined $+{name2}) {
>             $name  = $+{name2};
>             $value = $+{value2};
>         }
>         $fields_and_values{$name} = $value;
>     }
>     return \%fields_and_values;
> }
>
>
>
> > Marpa, Parse::RecDescent, Parse::Yapp, Parse::Eyapp.
> >
> > Первый мне очень нравиться. Попрбуйте с MarpaX::Repa. "Репу" написал сам
> и мне очень удобно с ним писать парсеры ибо можно написать грамматику и не
> определить все токены, то есть итеративно дополнять в процессе свой парсер
> без фатальных ошибок на этапе компиляции парсера. В новых версиях Marpa
> есть Scanless интерфейс - это самое близкое к Repa так как включает лексер
> и самое простое для начала.
> >
> > 2015-01-14 12:34 GMT+03:00 Харпалёв Иван <ivan.kharpalev на gmail.com>:
> >
> >> Доброго времени, могучий MoscowPM!
> >>
> >> Сейчас пишу небольшой язык.
> >> То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы
> потренироваться, а потом в C, там типизация, там сложнее).
> >>
> >> Когда язык был совсем примитивный, я его парсил регэкспами и по
> рабоче-крестьянски собирал код на целевом языке.
> >> Но язык подростает. И рефакторить оказывается очень печально.
> >>
> >> Как я понимаю весь процесс работы транслятора состоит из стандартных
> стадий, например:
> >> токенизация
> >> построение дерева разбора
> >> сбор кода на целевом языке из полученного описания.
> >>
> >> В общем тория у меня хромает и очень интересна. Но первым делом
> практика.
> >> Скажите, чем строить дерево синтаксического разбора?
> >> что-то вроде
> >>
> >> --
> >>
> >> Moscow.pm mailing list
> >>
> >> moscow-pm на pm.org | http://moscow.pm.org
> >
> > --
> > Best regards, Ruslan.
> --
> С уважением
> Николай Мишин
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/1fc58e05/attachment-0001.html>
----------- следущая часть -----------
A non-text attachment was scrubbed...
Name: ttt.pl
Type: text/x-perl-script
Size: 1778 bytes
Desc: отсутствует
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/1fc58e05/attachment-0001.bin>

From denis.fedoseev на gmail.com  Fri Jan 23 04:21:31 2015
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Fri, 23 Jan 2015 15:21:31 +0300
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
Message-ID: <CALE3dTUPGTXBuc84qMkGDRRotH-XMnJsaG1WkR0HGxmp2NRnuA@mail.gmail.com>

Я геарман использую. Но у него не очень гибкие настройки очереди.
On Jan 23, 2015 12:07 AM, "Ilya Chesnokov" <chesnokov.ilya на gmail.com> wrote:

> Всем привет.
>
> А какие есть удобные Perl-модули для организации очереди задач?
> Желательно с возможностью выбора бэкенда для хранения данных очередей
> и задач.
>
> Есть ли модули, которые в качестве бэкенда используют RabbitMQ?
>
> Нужно по работе написать что-то подобное, но хочу для начала
> промониторить существующие решения.
>
> На данный момент вижу Minion с явной поддержкой различных бэкендов -
> можно попробовать к нему прикрутить все что нужно, конечно - но может
> еще что-то есть.
>
> Спасибо.
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/bc82c0b0/attachment.html>

From pef-secure на yandex.ru  Fri Jan 23 04:38:14 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Fri, 23 Jan 2015 13:38:14 +0100
Subject: [Moscow.pm] PEF::Front - RFC
Message-ID: <3371208.g2OEIHMtT9@rawen>

Приветствую!

Прошу комментариев к моему веб-фреймворку. 

Репо: https://github.com/pef-secure/pef-front-psgi-dist
Wiki: https://github.com/pef-secure/pef-front-psgi-dist/wiki

Развёрнуто причины создания фреймворка попытался изложить тут: 
https://github.com/pef-secure/pef-front-psgi-dist/wiki/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D1%8B-%D0%B8-%D0%A6%D0%B5%D0%BB%D0%B8

Демонстрационное приложение: https://github.com/pef-secure/pef-front-demo
Посмотреть работу приложения можно по адресу: http://pef-demo.perlpowered.com

Очень коротко суть: меньше контроллеров, представление (View) умеет получать 
данные для генерации шаблона из модели самостоятельно, модель может быть 
локальной или удалённой.

Фреймворк может использовать одну или несколько удалённых моделей, а так же, 
иметь локальные обработчики. Фронтендов может быть несколько к одной удалённой 
модели. Разные фронтенды могут иметь разное предназначение, работать со своими 
собственными моделями. Например, несколько фронтедов работает с моделью 
"клиентский сайт", а отдельный фронтенд работает с моделью "администрирование 
сайта и клиентов". Релиз PEF::Core, реализующего удалённую модель, дело 
ближайших нескольких месяцев, идёт процесс перехода от POE к чистому EV.

Изначально, эта часть фронтенда была реализована на mod_perl2, но в связи с 
его застоем в плане адаптации к Apache httpd 2.4, было решено отказаться от 
mod_perl2 совсем и перейти на PSGI. Пристальное разглядывание внутренностей 
Plack/Dancer убедило меня в том, что "я могу лучше", поэтому, PSGI 
используется без Plack. Тривиальные тесты показывают, что при переходе от 
mod_perl2 к PEF::Front + uwsgi + Nginx скорость реакции фронтенда выросла 
значительно (вместо 10мс стало около 1мс в одних и тех же условиях). 

Основной API фреймворка достаточно стабилен, поскольку есть зависимые проекты, 
которые не должны сломаться при обновлениях. 

# Коротко суть. 

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

Автоматическая инсталяция URL для представлений позволяет начать работать над 
макетом страницы ещё до того, как программист модели изготовит необходимые 
методы, возвращающие реальные данные.

Методы модели автоматически доступны из шаблонов, AJAX, HTTP GET/POST. 

Существует "стандартная схема" URL, которая может быть модифицирована как 
угодно в настройках диспетчеризации.

# Возможности.

* ориентация на протокол PSGI
* язык шаблонов Template-Toolkit
* возможность иметь удалённую модель
* дополнительные функции шаблонизации, позволяющие получать данные из модели 
или манипулировать ответом
* отсутсвие отдельной сущности контроллеров, большая часть их функциональности 
декларируется в файлах формата YAML
* автоматизировнная схема назначения URL, с возможностью её модификации
* чёткое разделение обязанностей программистов фронтенда и бекенда
* декларативная настройка валидации входящих данных, редиректов, ожидаемых 
ответов модели
* поддержка загрузки файлов
* поддержка сессий
* поддержка авторизации по протоколу Oauth2
* поддержка локализации приложений

Главный недостаток на текущий момент -- слабая документация и слабое 
тестирование, но они так и останутся слабыми, пока не будет соратников. Над 
формальными тестами фреймворка работает человек, использующий фреймворк в 
своей работе. Эта работа ведётся в отдельном форке.
-- 
PEF Developer

From chesnokov.ilya на gmail.com  Fri Jan 23 05:37:03 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 23 Jan 2015 17:37:03 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
Message-ID: <CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>

23 января 2015 г., 11:39 пользователь Maxim Vuets
<maxim.vuets на gmail.com> написал:
> 2015-01-22 21:07 GMT+01:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
>> А какие есть удобные Perl-модули для организации очереди задач?
>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>> и задач.
>
> Мы написали и пользуемся вот этим:
> https://metacpan.org/pod/Queue::Q::ReliableFIFO::Redis
> Но там только Редис в качестве бекенда.

Насколько я помню, в букинге почему-то не любят ZeroMQ?
Не в курсе случаем, какие там проблемы с ним?

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org



-- 
Best regards,
Ilya Chesnokov

From stork2000 на yandex.ru  Sat Jan 24 11:03:12 2015
From: stork2000 на yandex.ru (Loginoff Nick)
Date: Sat, 24 Jan 2015 22:03:12 +0300
Subject: [Moscow.pm] =?koi8-r?b?98HLwc7TydEgUGVybC3Q0s/H0sHNzcnT1CArINfT?=
	=?koi8-r?b?oyDXz8vS1ccgOy0p?=
Message-ID: <9599671422126192@web7m.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150124/a5129886/attachment.html>

From ilay.sunmaster на gmail.com  Sat Jan 24 11:07:03 2015
From: ilay.sunmaster на gmail.com (Ilya Lomakin)
Date: Sat, 24 Jan 2015 22:07:03 +0300
Subject: [Moscow.pm] =?utf-8?b?0JLQsNC60LDQvdGB0LjRjyBQZXJsLdC/0YDQvtCz?=
	=?utf-8?b?0YDQsNC80LzQuNGB0YIgKyDQstGB0ZEg0LLQvtC60YDRg9CzIDstKQ==?=
In-Reply-To: <9599671422126192@web7m.yandex.ru>
References: <9599671422126192@web7m.yandex.ru>
Message-ID: <CAC5Kx4rFe7wxtGwz3TOQMS_JOTmg4J-fGJo6Gp2agb9dAdakWQ@mail.gmail.com>

Привет, это я.

2015-01-24 22:03 GMT+03:00 Loginoff Nick <stork2000 на yandex.ru>:

> Проект ?Бойцовский Клуб? - браузерная онлайн-игра ( http://combats.com ) .
>
> Требования:
> Отличное владение Perl, SQL.
> Опыт работы в области разработки web-приложений не менее 3-x лет.
> Опыт работы с системой контроля версий Git.
>
> Желательно:
> Опыт работы с PostgresSQL
> Знание Javascript и умение создавать интерфейсы под разные браузеры.
> Опыт работы с высоконагруженными системами
> Опыт работы в игровых проектах
>
> Задачи:
> Разработка нового игрового контента.
> Поддержка и оптимизация существующего кода.
>
> Условия:
> Уровень заработной платы - 120.000р (и более, если вы этого стоите)
> Офис: ст. м. Тульская (2 мин. пешком)
> Обеды в офисе
> Пятидневная рабочая неделя с 10 до 19 (время можно скорректировать).
> Оформление по ТК РФ.
>
> Кидайте резюме мне на прямую STork2000 на yandex.ru
> --
> С Уважением, Login|off Nick или STork.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150124/f3435c2e/attachment-0001.html>
----------- следущая часть -----------
A non-text attachment was scrubbed...
Name: Resume.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 19537 bytes
Desc: отсутствует
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150124/f3435c2e/attachment-0001.bin>

From mi на ya.ru  Sat Jan 24 11:34:22 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Sat, 24 Jan 2015 22:34:22 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?88nO1MHL08nexdPLycogwc7BzMnaIM7BIFBlcmwu?=
	=?koi8-r?b?IPTSwc7TzNHUz9Iu?=
In-Reply-To: <CAMOxC8tOYoHShMYc6BSRr_Wq0QaP45q2JitEJXxRZWDjMFwF0w@mail.gmail.com>
References: <3741531421958521@web19g.yandex.ru>
	<CAMOxC8tOYoHShMYc6BSRr_Wq0QaP45q2JitEJXxRZWDjMFwF0w@mail.gmail.com>
Message-ID: <9579371422128062@web13m.yandex.ru>

Руслан, супер, спасибо, работает,а я что-то и забыл про
use Regexp::Common qw /delimited/; !

23.01.2015, 14:21, "Ruslan Zakirov" <ruslan.zakirov на gmail.com>:
> 2015-01-22 23:28 GMT+03:00 Nikolay Mishin <mi на ya.ru>:
>> Руслан,
>> я тут понаписав парсеров на регулярках
>> с удовольсвием послушал бы про MarpaX::Repa
>> и как с помощью него распарсить скажем css
>> или html, если это, конечно, возможно,
>
> С HTML сложно, но возможно, есть Marpa::HTML (не помню точное имя) который делает парсинг согласно HTML5 стандарту (по словам автора модуля, он же автор Marpa). Там все старшно внутри.
>
>> ну для примера, как сделать грамматику для такой конструкции:
>>
>>       BEGIN DSSUBRECORD
>>          Name "$APT_DBNAME"
>>          Prompt "DB2 Database"
>>          Default "BANKDATA"
>>          HelpTxt "Default DB2 database to use"
>>          ParamType "0"
>>          ParamLength "0"
>>          ParamScale "0"
>>       END DSSUBRECORD
>>
>> если это вообще стоит делать,т.к. я просто
>> это распарсил такой функцией:
>
> cd ~/projs/mods/MarpaX-Repa/
> git co master
>
> cp examples/template.pl ttt.pl
> vi ttt.pl
>
> прикрепил
>> sub split_fields_by_new_line {
>>     my ($curr_record) = @_;
>>     my %fields_and_values = ();
>>     while (
>>         $curr_record =~ m/
>> (?<name>\w+)[ ]"(?<value>.*?)(?<!\\)"|
>> ((?<name2>\w+)[ ]\Q=+=+=+=\E
>> (?<value2>.*?)
>> \Q=+=+=+=\E)
>> /xsg
>>       )
>>     {
>>         my ($value, $name) = ('', '');
>>         if (defined $+{name}) {
>>             $name  = $+{name};
>>             $value = $+{value};
>>         }
>>         elsif (defined $+{name2}) {
>>             $name  = $+{name2};
>>             $value = $+{value2};
>>         }
>>         $fields_and_values{$name} = $value;
>>     }
>>     return \%fields_and_values;
>>
>> }
>>
>>> Marpa, Parse::RecDescent, Parse::Yapp, Parse::Eyapp.
>>>
>>> Первый мне очень нравиться. Попрбуйте с MarpaX::Repa. "Репу" написал сам и мне очень удобно с ним писать парсеры ибо можно написать грамматику и не определить все токены, то есть итеративно дополнять в процессе свой парсер без фатальных ошибок на этапе компиляции парсера. В новых версиях Marpa есть Scanless интерфейс - это самое близкое к Repa так как включает лексер и самое простое для начала.
>>>
>>> 2015-01-14 12:34 GMT+03:00 Харпалёв Иван <ivan.kharpalev на gmail.com>:
>>>
>>>> Доброго времени, могучий MoscowPM!
>>>>
>>>> Сейчас пишу небольшой язык.
>>>> То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы потренироваться, а потом в C, там типизация, там сложнее).
>>>>
>>>> Когда язык был совсем примитивный, я его парсил регэкспами и по рабоче-крестьянски собирал код на целевом языке.
>>>> Но язык подростает. И рефакторить оказывается очень печально.
>>>>
>>>> Как я понимаю весь процесс работы транслятора состоит из стандартных стадий, например:
>>>> токенизация
>>>> построение дерева разбора
>>>> сбор кода на целевом языке из полученного описания.
>>>>
>>>> В общем тория у меня хромает и очень интересна. Но первым делом практика.
>>>> Скажите, чем строить дерево синтаксического разбора?
>>>> что-то вроде
>>>>
>>>> --
>>>>
>>>> Moscow.pm mailing list
>>>>
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>> --
>>> Best regards, Ruslan.
>>
>> --
>> С уважением
>> Николай Мишин
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Best regards, Ruslan.
>
> ,
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением
Николай Мишин


From ilay.sunmaster на gmail.com  Sat Jan 24 11:58:23 2015
From: ilay.sunmaster на gmail.com (Ilya Lomakin)
Date: Sat, 24 Jan 2015 22:58:23 +0300
Subject: [Moscow.pm] =?utf-8?b?0JLQsNC60LDQvdGB0LjRjyBQZXJsLdC/0YDQvtCz?=
	=?utf-8?b?0YDQsNC80LzQuNGB0YIgKyDQstGB0ZEg0LLQvtC60YDRg9CzIDstKQ==?=
In-Reply-To: <CAC5Kx4rFe7wxtGwz3TOQMS_JOTmg4J-fGJo6Gp2agb9dAdakWQ@mail.gmail.com>
References: <9599671422126192@web7m.yandex.ru>
	<CAC5Kx4rFe7wxtGwz3TOQMS_JOTmg4J-fGJo6Gp2agb9dAdakWQ@mail.gmail.com>
Message-ID: <CAC5Kx4ou58BA-1CCNfsrc+iKme73HpnB_s5G15Q=4AbDoTmWaA@mail.gmail.com>

Упс! Окошечком ошибся. Сорри непричастным.

2015-01-24 22:07 GMT+03:00 Ilya Lomakin <ilay.sunmaster на gmail.com>:

> Привет, это я.
>
> 2015-01-24 22:03 GMT+03:00 Loginoff Nick <stork2000 на yandex.ru>:
>
>> Проект ?Бойцовский Клуб? - браузерная онлайн-игра ( http://combats.com )
>> .
>>
>> Требования:
>> Отличное владение Perl, SQL.
>> Опыт работы в области разработки web-приложений не менее 3-x лет.
>> Опыт работы с системой контроля версий Git.
>>
>> Желательно:
>> Опыт работы с PostgresSQL
>> Знание Javascript и умение создавать интерфейсы под разные браузеры.
>> Опыт работы с высоконагруженными системами
>> Опыт работы в игровых проектах
>>
>> Задачи:
>> Разработка нового игрового контента.
>> Поддержка и оптимизация существующего кода.
>>
>> Условия:
>> Уровень заработной платы - 120.000р (и более, если вы этого стоите)
>> Офис: ст. м. Тульская (2 мин. пешком)
>> Обеды в офисе
>> Пятидневная рабочая неделя с 10 до 19 (время можно скорректировать).
>> Оформление по ТК РФ.
>>
>> Кидайте резюме мне на прямую STork2000 на yandex.ru
>> --
>> С Уважением, Login|off Nick или STork.
>>
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150124/31727b9c/attachment.html>

From qalexx на gmail.com  Sat Jan 24 11:59:39 2015
From: qalexx на gmail.com (Alexander Q)
Date: Sat, 24 Jan 2015 19:59:39 +0000
Subject: [Moscow.pm] =?utf-8?b?0JLQsNC60LDQvdGB0LjRjyBQZXJsLdC/0YDQvtCz?=
	=?utf-8?b?0YDQsNC80LzQuNGB0YIgKyDQstGB0ZEg0LLQvtC60YDRg9CzIDstKQ==?=
References: <9599671422126192@web7m.yandex.ru>
	<CAC5Kx4rFe7wxtGwz3TOQMS_JOTmg4J-fGJo6Gp2agb9dAdakWQ@mail.gmail.com>
	<CAC5Kx4ou58BA-1CCNfsrc+iKme73HpnB_s5G15Q=4AbDoTmWaA@mail.gmail.com>
Message-ID: <CAEJuZgcdbey0TcDaSYC7AiqvL=LKQpsPwGtnzCNFoidhREJk+A@mail.gmail.com>

Да ничего, почитаем?

On Sat, Jan 24, 2015, 22:58 Ilya Lomakin <ilay.sunmaster на gmail.com> wrote:

> Упс! Окошечком ошибся. Сорри непричастным.
>
> 2015-01-24 22:07 GMT+03:00 Ilya Lomakin <ilay.sunmaster на gmail.com>:
>
>> Привет, это я.
>>
>> 2015-01-24 22:03 GMT+03:00 Loginoff Nick <stork2000 на yandex.ru>:
>>
>>> Проект ?Бойцовский Клуб? - браузерная онлайн-игра ( http://combats.com
>>> ) .
>>>
>>> Требования:
>>> Отличное владение Perl, SQL.
>>> Опыт работы в области разработки web-приложений не менее 3-x лет.
>>> Опыт работы с системой контроля версий Git.
>>>
>>> Желательно:
>>> Опыт работы с PostgresSQL
>>> Знание Javascript и умение создавать интерфейсы под разные браузеры.
>>> Опыт работы с высоконагруженными системами
>>> Опыт работы в игровых проектах
>>>
>>> Задачи:
>>> Разработка нового игрового контента.
>>> Поддержка и оптимизация существующего кода.
>>>
>>> Условия:
>>> Уровень заработной платы - 120.000р (и более, если вы этого стоите)
>>> Офис: ст. м. Тульская (2 мин. пешком)
>>> Обеды в офисе
>>> Пятидневная рабочая неделя с 10 до 19 (время можно скорректировать).
>>> Оформление по ТК РФ.
>>>
>>> Кидайте резюме мне на прямую STork2000 на yandex.ru
>>> --
>>> С Уважением, Login|off Nick или STork.
>>>
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>>
>>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150124/10699ee5/attachment.html>

From stork2000 на yandex.ru  Sat Jan 24 12:05:39 2015
From: stork2000 на yandex.ru (Loginoff Nick)
Date: Sat, 24 Jan 2015 23:05:39 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?98HLwc7TydEgUGVybC3Q0s/H0sHNzcnT1CArINfT?=
	=?koi8-r?b?oyDXz8vS1ccgOy0p?=
In-Reply-To: <CAC5Kx4ou58BA-1CCNfsrc+iKme73HpnB_s5G15Q=4AbDoTmWaA@mail.gmail.com>
References: <9599671422126192@web7m.yandex.ru>
	<CAC5Kx4rFe7wxtGwz3TOQMS_JOTmg4J-fGJo6Gp2agb9dAdakWQ@mail.gmail.com>
	<CAC5Kx4ou58BA-1CCNfsrc+iKme73HpnB_s5G15Q=4AbDoTmWaA@mail.gmail.com>
Message-ID: <9622461422129939@web24m.yandex.ru>

Вам в понедельник позвонят и пригласят на собеседование.

Ну если, вам тут не перехантит кто-нить)))

24.01.2015, 22:58, "Ilya Lomakin" <ilay.sunmaster на gmail.com>:
> Упс! Окошечком ошибся. Сорри непричастным.
>
> 2015-01-24 22:07 GMT+03:00 Ilya Lomakin <ilay.sunmaster на gmail.com>:
>> Привет, это я.
>>
>> 2015-01-24 22:03 GMT+03:00 Loginoff Nick <stork2000 на yandex.ru>:
>>> Проект ?Бойцовский Клуб? - браузерная онлайн-игра ( http://combats.com ) .
>>>
>>> Требования:
>>> Отличное владение Perl, SQL.
>>> Опыт работы в области разработки web-приложений не менее 3-x лет.
>>> Опыт работы с системой контроля версий Git.
>>>
>>> Желательно:
>>> Опыт работы с PostgresSQL
>>> Знание Javascript и умение создавать интерфейсы под разные браузеры.
>>> Опыт работы с высоконагруженными системами
>>> Опыт работы в игровых проектах
>>>
>>> Задачи:
>>> Разработка нового игрового контента.
>>> Поддержка и оптимизация существующего кода.
>>>
>>> Условия:
>>> Уровень заработной платы - 120.000р (и более, если вы этого стоите)
>>> Офис: ст. м. Тульская (2 мин. пешком)
>>> Обеды в офисе
>>> Пятидневная рабочая неделя с 10 до 19 (время можно скорректировать).
>>> Оформление по ТК РФ.
>>>
>>> Кидайте резюме мне на прямую STork2000 на yandex.ru
>>> --
>>> С Уважением, Login|off Nick или STork.
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>
> ,
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

 -- 
С Уважением, Login|off Nick или STork.

From sergle.ua на gmail.com  Mon Jan 26 03:48:04 2015
From: sergle.ua на gmail.com (Sergey Leschenko)
Date: Mon, 26 Jan 2015 13:48:04 +0200
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
Message-ID: <CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>

> Насколько я помню, в букинге почему-то не любят ZeroMQ?
> Не в курсе случаем, какие там проблемы с ним?

Пытался на YAPC::EU'2013 это узнать, мне ответили что слишком сложно в
случае когда нужно реализовать все с обработкой ошибок, таймаутов и
т.д.
Еще у них 2я версия использовалась (тогда).


2015-01-23 15:37 GMT+02:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> 23 января 2015 г., 11:39 пользователь Maxim Vuets
> <maxim.vuets на gmail.com> написал:
>> 2015-01-22 21:07 GMT+01:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
>>> А какие есть удобные Perl-модули для организации очереди задач?
>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>>> и задач.
>>
>> Мы написали и пользуемся вот этим:
>> https://metacpan.org/pod/Queue::Q::ReliableFIFO::Redis
>> Но там только Редис в качестве бекенда.
>
> Насколько я помню, в букинге почему-то не любят ZeroMQ?
> Не в курсе случаем, какие там проблемы с ним?
>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org



-- 
Sergey

From victor на vsespb.ru  Mon Jan 26 04:00:00 2015
From: victor на vsespb.ru (Victor Efimov)
Date: Mon, 26 Jan 2015 16:00:00 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
	<CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
Message-ID: <CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>

Для Ruby on Rails две последние самые популярные очереди - Resqueue и
Sidekiq - на базе Redis сделаны.

26 января 2015 г., 14:48 пользователь Sergey Leschenko
<sergle.ua на gmail.com> написал:
>> Насколько я помню, в букинге почему-то не любят ZeroMQ?
>> Не в курсе случаем, какие там проблемы с ним?
>
> Пытался на YAPC::EU'2013 это узнать, мне ответили что слишком сложно в
> случае когда нужно реализовать все с обработкой ошибок, таймаутов и
> т.д.
> Еще у них 2я версия использовалась (тогда).
>
>
> 2015-01-23 15:37 GMT+02:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
>> 23 января 2015 г., 11:39 пользователь Maxim Vuets
>> <maxim.vuets на gmail.com> написал:
>>> 2015-01-22 21:07 GMT+01:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
>>>> А какие есть удобные Perl-модули для организации очереди задач?
>>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
>>>> и задач.
>>>
>>> Мы написали и пользуемся вот этим:
>>> https://metacpan.org/pod/Queue::Q::ReliableFIFO::Redis
>>> Но там только Редис в качестве бекенда.
>>
>> Насколько я помню, в букинге почему-то не любят ZeroMQ?
>> Не в курсе случаем, какие там проблемы с ним?
>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>>
>> --
>> Best regards,
>> Ilya Chesnokov
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Sergey
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From warstone на list.ru  Mon Jan 26 04:02:06 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Mon, 26 Jan 2015 15:02:06 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
Message-ID: <1422273726.705343837@f309.i.mail.ru>


Раз комбатсы начали, надо продолжить... На этот раз мы ищем Perl'овиков.

В игровую компанию нужны Perl-спецы высшего уровня. 
  Требования:
*  Виртуозное знание Perl
  Желательно: 
*  Опыт работы со следующими технологиями: Catalyst, DBIx::Class, Moose, PostgreSQL
*  Опыт построения высоконагруженных серверов (TCP, RPC, load-balancing, HTTP)
*  Понимание производительности кода Perl (perl -MO=Concise,-exec, NYT::Prof и т.д.)
*  Опыт написания и оптимизации SQL запросов (EXPLAIN ANALYZE и т.д.)
  С чем предстоит работать: 
*  Серверная часть социальных игр.
*  Самописный фреймворк для общения с клиентом через TCP посредствам JSON.
*  Поддержка существующих (сначала поддержка и знакомство с технологиями, конечно) и разработка новых игр.
Условия: 
*  холодильник с едой и напитками, кофе-машина, консоль, пинг-понг
*  бесплатное обучение английскому языку в офисе (разные уровни, native speaker)
*  адекватная вашему уровню з/п (больших цифр не боимся, если вы реально сильны), ежеквартальный пересмотр з/п
*  предельный гуманизм в управлении (по своей воле от нас почти никто не уходит)
*  50% компенсация ДМС
*  50% компенсация абонемента в фитнес-клуб
*  полный рабочий день (гибкий график работы), удаленка не годится http://hh.ru/vacancy/11997386

Как-то так... Есть есть вопросы о работе, о людях и прочее, то я готов на них ответить.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/52b5cdb3/attachment.html>

From chesnokov.ilya на gmail.com  Mon Jan 26 04:19:51 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Mon, 26 Jan 2015 16:19:51 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
	<CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
	<CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>
Message-ID: <CANh0x-yA5PPHeu9RaYfROw2VMXJwOA-i5mmFSn31GQuJ1xC2-Q@mail.gmail.com>

26 января 2015 г., 15:00 пользователь Victor Efimov <victor на vsespb.ru> написал:
> Для Ruby on Rails две последние самые популярные очереди - Resqueue и
> Sidekiq - на базе Redis сделаны.

Да уж, что для Perl-программиста - модуль на CPAN, то для
Ruby-программиста - стартап.

-- 
Best regards,
Ilya Chesnokov

From aml на rulezz.ru  Mon Jan 26 04:28:38 2015
From: aml на rulezz.ru (Alexander Lourier)
Date: Mon, 26 Jan 2015 12:28:38 +0000
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
	<CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
	<CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>
	<CANh0x-yA5PPHeu9RaYfROw2VMXJwOA-i5mmFSn31GQuJ1xC2-Q@mail.gmail.com>
Message-ID: <CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg@mail.gmail.com>

Что мне не нравится в ZeroMQ - это надо точно знать IP ноды, которая делает
bind(), а все потом к ней connect(). И не дай бог, с этой центральной нодой
что-то случится. Фейловера нет.

On Mon Jan 26 2015 at 1:20:13 PM Ilya Chesnokov <chesnokov.ilya на gmail.com>
wrote:

> 26 января 2015 г., 15:00 пользователь Victor Efimov <victor на vsespb.ru>
> написал:
> > Для Ruby on Rails две последние самые популярные очереди - Resqueue и
> > Sidekiq - на базе Redis сделаны.
>
> Да уж, что для Perl-программиста - модуль на CPAN, то для
> Ruby-программиста - стартап.
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/07ea6002/attachment-0001.html>

From akovbovich на gmail.com  Mon Jan 26 05:05:57 2015
From: akovbovich на gmail.com (Andrey Kovbovich)
Date: Mon, 26 Jan 2015 17:05:57 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <1422273726.705343837@f309.i.mail.ru>
References: <1422273726.705343837@f309.i.mail.ru>
Message-ID: <CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>

Привет, вот бы офис еще в удобном месте...

26 января 2015 г., 15:02 пользователь Warstone на list.ru <warstone на list.ru>
написал:

>
> Раз комбатсы начали, надо продолжить... На этот раз мы ищем Perl'овиков.
>
> *В игровую компанию нужны Perl-спецы высшего уровня. *
>
>  *Требования:*
>
>    - Виртуозное знание Perl
>
>  *Желательно: *
>
>    - Опыт работы со следующими технологиями: Catalyst, DBIx::Class,
>    Moose, PostgreSQL
>    - Опыт построения высоконагруженных серверов (TCP, RPC,
>    load-balancing, HTTP)
>    - Понимание производительности кода Perl (perl -MO=Concise,-exec,
>    NYT::Prof и т.д.)
>    - Опыт написания и оптимизации SQL запросов (EXPLAIN ANALYZE и т.д.)
>
>  *С чем предстоит работать: *
>
>    - Серверная часть социальных игр.
>    - Самописный фреймворк для общения с клиентом через TCP посредствам
>    JSON.
>    - Поддержка существующих (сначала поддержка и знакомство с
>    технологиями, конечно) и разработка новых игр.
>
> *Условия: *
>
>    - холодильник с едой и напитками, кофе-машина, консоль, пинг-понг
>    - бесплатное обучение английскому языку в офисе (разные уровни, native
>    speaker)
>    - адекватная вашему уровню з/п (больших цифр не боимся, если вы
>    реально сильны), ежеквартальный пересмотр з/п
>    - предельный гуманизм в управлении (по своей воле от нас почти никто
>    не уходит)
>    - 50% компенсация ДМС
>    - 50% компенсация абонемента в фитнес-клуб
>    - полный рабочий день (гибкий график работы), удаленка не годится
>
> http://hh.ru/vacancy/11997386
>
> Как-то так... Есть есть вопросы о работе, о людях и прочее, то я готов на
> них ответить.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/f83eff5c/attachment.html>

From chesnokov.ilya на gmail.com  Mon Jan 26 05:16:27 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Mon, 26 Jan 2015 17:16:27 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
	<CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
	<CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>
	<CANh0x-yA5PPHeu9RaYfROw2VMXJwOA-i5mmFSn31GQuJ1xC2-Q@mail.gmail.com>
	<CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg@mail.gmail.com>
Message-ID: <CANh0x-yYYL2QCByfOmXBQyr=8GWsOWj7Bx4aYouN2_kHS5d22w@mail.gmail.com>

26 января 2015 г., 15:28 пользователь Alexander Lourier <aml на rulezz.ru> написал:
> Что мне не нравится в ZeroMQ - это надо точно знать IP ноды, которая делает
> bind(), а все потом к ней connect(). И не дай бог, с этой центральной нодой
> что-то случится. Фейловера нет.

А в RabbitMQ нет такой проблемы?

И еще - правильно я понял, что в Redis-based решениях (Queue::Q,
Resque с CPAN) воркер должен периодически опрашивать очередь на
наличие новых заданий?
Просто насколько я понял, в RabbitMQ это все делается асинхронно -
вешаем коллбэк на приход сообщения и бесконечно ждем...
(https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/perl/worker.pl)


> On Mon Jan 26 2015 at 1:20:13 PM Ilya Chesnokov <chesnokov.ilya на gmail.com>
> wrote:
>>
>> 26 января 2015 г., 15:00 пользователь Victor Efimov <victor на vsespb.ru>
>> написал:
>> > Для Ruby on Rails две последние самые популярные очереди - Resqueue и
>> > Sidekiq - на базе Redis сделаны.
>>
>> Да уж, что для Perl-программиста - модуль на CPAN, то для
>> Ruby-программиста - стартап.
>>
>> --
>> Best regards,
>> Ilya Chesnokov
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards,
Ilya Chesnokov

From warstone на list.ru  Mon Jan 26 05:21:52 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Mon, 26 Jan 2015 16:21:52 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>
References: <1422273726.705343837@f309.i.mail.ru>
	<CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>
Message-ID: <1422278512.4152304@f368.i.mail.ru>

 Мы на Авиамоторную по идеи должны переехать в феврале.


Mon, 26 Jan 2015 17:05:57 +0400 от Andrey Kovbovich <akovbovich на gmail.com>:
>Привет, вот бы офис еще в удобном месте...
>
>26 января 2015 г., 15:02 пользователь  Warstone на list.ru < warstone на list.ru > написал:
>>
>>Раз комбатсы начали, надо продолжить... На этот раз мы ищем Perl'овиков.
>>
>>В игровую компанию нужны Perl-спецы высшего уровня. 
>>  Требования:
>>*  Виртуозное знание Perl
>>  Желательно: 
>>*  Опыт работы со следующими технологиями: Catalyst, DBIx::Class, Moose, PostgreSQL
>>*  Опыт построения высоконагруженных серверов (TCP, RPC, load-balancing, HTTP)
>>*  Понимание производительности кода Perl (perl -MO=Concise,-exec, NYT::Prof и т.д.)
>>*  Опыт написания и оптимизации SQL запросов (EXPLAIN ANALYZE и т.д.)
>>  С чем предстоит работать: 
>>*  Серверная часть социальных игр.
>>*  Самописный фреймворк для общения с клиентом через TCP посредствам JSON.
>>*  Поддержка существующих (сначала поддержка и знакомство с технологиями, конечно) и разработка новых игр.
>>Условия: 
>>*  холодильник с едой и напитками, кофе-машина, консоль, пинг-понг
>>*  бесплатное обучение английскому языку в офисе (разные уровни, native speaker)
>>*  адекватная вашему уровню з/п (больших цифр не боимся, если вы реально сильны), ежеквартальный пересмотр з/п
>>*  предельный гуманизм в управлении (по своей воле от нас почти никто не уходит)
>>*  50% компенсация ДМС
>>*  50% компенсация абонемента в фитнес-клуб
>>*  полный рабочий день (гибкий график работы), удаленка не годится http://hh.ru/vacancy/11997386
>>
>>Как-то так... Есть есть вопросы о работе, о людях и прочее, то я готов на них ответить.
>>
>>--
>>Moscow.pm mailing list
>>moscow-pm на pm.org |  http://moscow.pm.org
>>
>
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/da79353e/attachment-0001.html>

From foxcool333 на gmail.com  Mon Jan 26 05:34:42 2015
From: foxcool333 на gmail.com (Foxcool)
Date: Mon, 26 Jan 2015 16:34:42 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <1422278512.4152304@f368.i.mail.ru>
References: <1422273726.705343837@f309.i.mail.ru>
	<CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>
	<1422278512.4152304@f368.i.mail.ru>
Message-ID: <54C64272.3050109@gmail.com>

Вот бы удобный офис в интернете.

From warstone на list.ru  Mon Jan 26 06:04:55 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Mon, 26 Jan 2015 17:04:55 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <1422278512.4152304@f368.i.mail.ru>
References: <1422273726.705343837@f309.i.mail.ru>
	<CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>
	<1422278512.4152304@f368.i.mail.ru>
Message-ID: <1422281095.887923302@f426.i.mail.ru>

 Наврал - Автозаводская.

Mon, 26 Jan 2015 16:21:52 +0300 от Warstone на list.ru <warstone на list.ru>:
>Мы на Авиамоторную по идеи должны переехать в феврале.
>
>
>Mon, 26 Jan 2015 17:05:57 +0400 от Andrey Kovbovich <akovbovich на gmail.com>:
>>Привет, вот бы офис еще в удобном месте...
>>
>>26 января 2015 г., 15:02 пользователь  Warstone на list.ru < warstone на list.ru > написал:
>>>
>>>Раз комбатсы начали, надо продолжить... На этот раз мы ищем Perl'овиков.
>>>
>>>В игровую компанию нужны Perl-спецы высшего уровня. 
>>>  Требования:
>>>*  Виртуозное знание Perl
>>>  Желательно: 
>>>*  Опыт работы со следующими технологиями: Catalyst, DBIx::Class, Moose, PostgreSQL
>>>*  Опыт построения высоконагруженных серверов (TCP, RPC, load-balancing, HTTP)
>>>*  Понимание производительности кода Perl (perl -MO=Concise,-exec, NYT::Prof и т.д.)
>>>*  Опыт написания и оптимизации SQL запросов (EXPLAIN ANALYZE и т.д.)
>>>  С чем предстоит работать: 
>>>*  Серверная часть социальных игр.
>>>*  Самописный фреймворк для общения с клиентом через TCP посредствам JSON.
>>>*  Поддержка существующих (сначала поддержка и знакомство с технологиями, конечно) и разработка новых игр.
>>>Условия: 
>>>*  холодильник с едой и напитками, кофе-машина, консоль, пинг-понг
>>>*  бесплатное обучение английскому языку в офисе (разные уровни, native speaker)
>>>*  адекватная вашему уровню з/п (больших цифр не боимся, если вы реально сильны), ежеквартальный пересмотр з/п
>>>*  предельный гуманизм в управлении (по своей воле от нас почти никто не уходит)
>>>*  50% компенсация ДМС
>>>*  50% компенсация абонемента в фитнес-клуб
>>>*  полный рабочий день (гибкий график работы), удаленка не годится http://hh.ru/vacancy/11997386
>>>
>>>Как-то так... Есть есть вопросы о работе, о людях и прочее, то я готов на них ответить.
>>>
>>>--
>>>Moscow.pm mailing list
>>>moscow-pm на pm.org |  http://moscow.pm.org
>>>
>>
>>-- 
>>Moscow.pm mailing list
>>moscow-pm на pm.org |  http://moscow.pm.org
>
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/5cede83c/attachment.html>

From warstone на list.ru  Mon Jan 26 06:05:26 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Mon, 26 Jan 2015 17:05:26 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <54C64272.3050109@gmail.com>
References: <1422273726.705343837@f309.i.mail.ru>
	<1422278512.4152304@f368.i.mail.ru> <54C64272.3050109@gmail.com>
Message-ID: <1422281126.246910734@f426.i.mail.ru>

 А вас в Гугль-то возьмут?


Mon, 26 Jan 2015 16:34:42 +0300 от Foxcool <foxcool333 на gmail.com>:
>Вот бы удобный офис в интернете.

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/df9cc254/attachment.html>

From foxcool333 на gmail.com  Mon Jan 26 06:34:02 2015
From: foxcool333 на gmail.com (Foxcool)
Date: Mon, 26 Jan 2015 17:34:02 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <1422281126.246910734@f426.i.mail.ru>
References: <1422273726.705343837@f309.i.mail.ru>
	<1422278512.4152304@f368.i.mail.ru> <54C64272.3050109@gmail.com>
	<1422281126.246910734@f426.i.mail.ru>
Message-ID: <54C6505A.4090207@gmail.com>

26.01.2015 17:05, Warstone на list.ru пишет:
> А вас в Гугль-то возьмут?
>
>
> Mon, 26 Jan 2015 16:34:42 +0300 от Foxcool <foxcool333 на gmail.com>:
>
>     Вот бы удобный офис в интернете.
>
>
чего?

-- 
http://foxcool.ru
foxcool на jabber.ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/6930c913/attachment-0001.html>

From foxcool333 на gmail.com  Mon Jan 26 06:38:22 2015
From: foxcool333 на gmail.com (Foxcool)
Date: Mon, 26 Jan 2015 17:38:22 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <1422281126.246910734@f426.i.mail.ru>
References: <1422273726.705343837@f309.i.mail.ru>
	<1422278512.4152304@f368.i.mail.ru> <54C64272.3050109@gmail.com>
	<1422281126.246910734@f426.i.mail.ru>
Message-ID: <54C6515E.3050209@gmail.com>

26.01.2015 17:36, Warstone на list.ru пишет:
> Ну вы хотите удобный офис в интернете. Как известно интернет - это 
> гугль. Шутка такая.
>
>
> Понедельник, 26 января 2015, 17:34 +03:00 от Foxcool 
> <foxcool333 на gmail.com>:
>
>     26.01.2015 17:05, Warstone на list.ru
>     <https://e.mail.ru/compose/?mailto=mailto%3aWarstone на list.ru> пишет:
>>     А вас в Гугль-то возьмут?
>>
>>
>>     Mon, 26 Jan 2015 16:34:42 +0300 от Foxcool <foxcool333 на gmail.com>
>>     <https://e.mail.ru/compose/?mailto=mailto%3afoxcool333 на gmail.com>:
>>
>>         Вот бы удобный офис в интернете.
>>
>>
>     чего?
>
>     -- 
>     http://foxcool.ru
>     foxcool на jabber.ru  <https://e.mail.ru/compose/?mailto=mailto%3afoxcool на jabber.ru>
>
>
А!
Не, если бы интернет стал эквивалентен гуглу, то это был бы жесткокий 
фэйл. (:

-- 
http://foxcool.ru
foxcool на jabber.ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/7168031b/attachment.html>

From akovbovich на gmail.com  Mon Jan 26 06:59:47 2015
From: akovbovich на gmail.com (Andrey Kovbovich)
Date: Mon, 26 Jan 2015 18:59:47 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLg==?=
In-Reply-To: <54C64272.3050109@gmail.com>
References: <1422273726.705343837@f309.i.mail.ru>
	<CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>
	<1422278512.4152304@f368.i.mail.ru> <54C64272.3050109@gmail.com>
Message-ID: <CAPTWO-YXbr6pNM8sNUUMbZKX2kJn3h8OZ=_Wx-OdbPUr5_iZAA@mail.gmail.com>

Ну знаешь, я сейчас в варшаве сижу в старбаксе в интернет офисе, и не
сказал бы, что сильно удобно :) А дома скучно.

26 января 2015 г., 16:34 пользователь Foxcool <foxcool333 на gmail.com>
написал:

> Вот бы удобный офис в интернете.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/01dc2a1f/attachment.html>

From foxcool333 на gmail.com  Mon Jan 26 07:01:57 2015
From: foxcool333 на gmail.com (Foxcool)
Date: Mon, 26 Jan 2015 18:01:57 +0300
Subject: [Moscow.pm] =?koi8-r?b?6d3FzSDwxczP18nLz9cu?=
In-Reply-To: <CAPTWO-YXbr6pNM8sNUUMbZKX2kJn3h8OZ=_Wx-OdbPUr5_iZAA@mail.gmail.com>
References: <1422273726.705343837@f309.i.mail.ru>	<CAPTWO-ZOhh+D=fkCsjqpaQy_qT=1-NKiHay3AkF-_C=Cy7quoA@mail.gmail.com>	<1422278512.4152304@f368.i.mail.ru>
	<54C64272.3050109@gmail.com>
	<CAPTWO-YXbr6pNM8sNUUMbZKX2kJn3h8OZ=_Wx-OdbPUr5_iZAA@mail.gmail.com>
Message-ID: <54C656E5.6050504@gmail.com>

26.01.2015 17:59, Andrey Kovbovich пишет:
> Ну знаешь, я сейчас в варшаве сижу в старбаксе в интернет офисе, и не 
> сказал бы, что сильно удобно :) А дома скучно.
>
> 26 января 2015 г., 16:34 пользователь Foxcool <foxcool333 на gmail.com 
> <mailto:foxcool333 на gmail.com>> написал:
>
>     Вот бы удобный офис в интернете.
>
>     -- 
>     Moscow.pm mailing list
>     moscow-pm на pm.org <mailto:moscow-pm на pm.org> | http://moscow.pm.org
>
>
>
>
Ну если брать в расчет такие соображения, то хорошо, чтобы был выбор у 
каждого. (:



-- 
http://foxcool.ru
foxcool на jabber.ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/5838e269/attachment.html>

From sergle.ua на gmail.com  Mon Jan 26 07:06:25 2015
From: sergle.ua на gmail.com (Sergey Leschenko)
Date: Mon, 26 Jan 2015 17:06:25 +0200
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
	<CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
	<CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>
	<CANh0x-yA5PPHeu9RaYfROw2VMXJwOA-i5mmFSn31GQuJ1xC2-Q@mail.gmail.com>
	<CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg@mail.gmail.com>
Message-ID: <CAJoOBmyfZhfLGz8-=9PjnAgBc=c+gb=hjbo3HFv2saNA_sAxEA@mail.gmail.com>

2015-01-26 14:28 GMT+02:00 Alexander Lourier <aml на rulezz.ru>:
> Что мне не нравится в ZeroMQ - это надо точно знать IP ноды, которая делает
> bind(), а все потом к ней connect(). И не дай бог, с этой центральной нодой
> что-то случится. Фейловера нет.

Так ZeroMQ это же конструктор а не сервер очередей.


-- 
Sergey

From victor на vsespb.ru  Mon Jan 26 11:43:39 2015
From: victor на vsespb.ru (Victor Efimov)
Date: Mon, 26 Jan 2015 23:43:39 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANh0x-yYYL2QCByfOmXBQyr=8GWsOWj7Bx4aYouN2_kHS5d22w@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAG6DbogCfrDWX=_rHDYkitY60-GpW7iGhLAVrr3mE_nXmmRWDQ@mail.gmail.com>
	<CANh0x-zmM9whJputNXmtM1=bKYfj7JaBf6U0DqPgPhUR8pgPeQ@mail.gmail.com>
	<CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=xvvp6Ps5wxMBaLkgDtD2Q@mail.gmail.com>
	<CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=Mpg@mail.gmail.com>
	<CANh0x-yA5PPHeu9RaYfROw2VMXJwOA-i5mmFSn31GQuJ1xC2-Q@mail.gmail.com>
	<CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg@mail.gmail.com>
	<CANh0x-yYYL2QCByfOmXBQyr=8GWsOWj7Bx4aYouN2_kHS5d22w@mail.gmail.com>
Message-ID: <CAF7QZD4fZmaHw2+_stWGKS=gWH1EGS3puyuqHDnKBqoYC+Qd5Q@mail.gmail.com>

26 января 2015 г., 16:16 пользователь Ilya Chesnokov
<chesnokov.ilya на gmail.com> написал:
>
> И еще - правильно я понял, что в Redis-based решениях (Queue::Q,
> Resque с CPAN) воркер должен периодически опрашивать очередь на
> наличие новых заданий?
> Просто насколько я понял, в RabbitMQ это все делается асинхронно -
> вешаем коллбэк на приход сообщения и бесконечно ждем...
> (https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/perl/worker.pl)
>

Не знаю на счёт этих решиний, но в самом редис всё с этим OK - есть
команды типа BLPOP. Про запуске команды клиент ждёт пока в очереди
что-то появится, потом моментально разблокируется, без всякого опроса
сервера (будет ли выглядеть API как коллбэк - это перпендикулярно). В
Rails Resque, Rails Sidekiq, и в очереди REGRU, про которую расскажет
Иван Соколов 5 февраля это и используется.

Можно самому посмотреть - взять исходник и погрепать blpop, brpop,
brpoplpush - если они есть, скорее всего всё ок.

From pavel на kuptsov.info  Mon Jan 26 23:54:29 2015
From: pavel на kuptsov.info (=?UTF-8?B?0J/QsNCy0LXQuyDQmtGD0L/RhtC+0LI=?=)
Date: Tue, 27 Jan 2015 10:54:29 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
Message-ID: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>

Для тех кто ищет работу - вот недавно предлагали такой вариант:

*Обязанности:*

   - Разработка и поддержка программного обеспечения.


*Требования:*

   - Мы работаем с FreeBSD (на серверах), modern perl, Mojolicious, Redis,
   Elasticsearch, git и некоторыми функциональными языками программирования.
   - Простое перечисление навыков и акронимов которые есть или которые
   нужны это не самое главное. Мы ценим профессиональных и опытных в своей
   области работы людей. Но мы также считаем что мотивация, желание работать и
   интеллект являются приоритетными и необходимыми качествами.
   - Мы ищем мотивированных сотрудников, которые способны общаться, думать
   и работать в команде.
   - Разговорный aнглийский язык.

*Условия:*

   - Полный рабочий день в нашем офисе в Монтевидео (Уругвай).
   - Хорошая заработная плата, помощь с имиграционными вопросами переездом
   и адаптацией.
   - Для начала мы предложим трёхмесячный контракт с последующей
   возможностью перехода на постоянную работу.

http://hh.ru/vacancy/12572494


--
Павел


> ------------------------------
>
> Subject: Нижний колонтитул дайджеста
>
> _______________________________________________
> Moscow-pm mailing list
> Moscow-pm на pm.org
> http://mail.pm.org/mailman/listinfo/moscow-pm
>
>
> ------------------------------
>
> Конец Дайджест списка рассылки Moscow-pm; том 87, выпуск 36
> ***********************************************************
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/cf849786/attachment.html>

From warstone на list.ru  Tue Jan 27 00:28:41 2015
From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=)
Date: Tue, 27 Jan 2015 11:28:41 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
 =?utf-8?q?Warstone=40list=2Eru=29?=
In-Reply-To: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
Message-ID: <1422347321.466436859@f28.i.mail.ru>

 Город хороший, да...


Вторник, 27 января 2015, 10:54 +03:00 от Павел Купцов <pavel на kuptsov.info>:
>Для тех кто ищет работу - вот недавно предлагали такой вариант:
>Обязанности:
>*  Разработка и поддержка программного обеспечения.
>
>Требования:
>*  Мы работаем с FreeBSD (на серверах), modern perl, Mojolicious, Redis, Elasticsearch, git и некоторыми функциональными языками программирования.
>*  Простое перечисление навыков и акронимов которые есть или которые нужны это не самое главное. Мы ценим профессиональных и опытных в своей области работы людей. Но мы также считаем что мотивация, желание работать и интеллект являются приоритетными и необходимыми качествами.
>*  Мы ищем мотивированных сотрудников, которые способны общаться, думать и работать в команде.
>*  Разговорный aнглийский язык.
>Условия:
>*  Полный рабочий день в нашем офисе в Монтевидео (Уругвай).
>*  Хорошая заработная плата, помощь с имиграционными вопросами переездом и адаптацией.
>*  Для начала мы предложим трёхмесячный контракт с последующей возможностью перехода на постоянную работу.
>http://hh.ru/vacancy/12572494
>
>
>--
>Павел
>
>>
>>------------------------------
>>
>>Subject: Нижний колонтитул дайджеста
>>
>>_______________________________________________
>>Moscow-pm mailing list
>>Moscow-pm на pm.org
>>http://mail.pm.org/mailman/listinfo/moscow-pm
>>
>>
>>------------------------------
>>
>>Конец Дайджест списка рассылки Moscow-pm; том 87, выпуск 36
>>***********************************************************
>
>
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/15359131/attachment-0001.html>

From dsimonov на gmail.com  Tue Jan 27 01:34:17 2015
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Tue, 27 Jan 2015 12:34:17 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
In-Reply-To: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
Message-ID: <CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>

27 января 2015 г., 10:54 пользователь Павел Купцов <pavel на kuptsov.info>
написал:

> Полный рабочий день в нашем офисе в Монтевидео (Уругвай).


60 часов на маршрутке от ближайшего метро?

---
Dmitriy V. Simonov
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/217a8a76/attachment.html>

From sergey.aleynikov на gmail.com  Tue Jan 27 01:58:01 2015
From: sergey.aleynikov на gmail.com (Sergey Aleynikov)
Date: Tue, 27 Jan 2015 13:58:01 +0400
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>
	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>
	<CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>
Message-ID: <CAKNj8S2dtdiqqJSxbafdDrFURL6iwxZFHrBa5CDE63E4g=C30A@mail.gmail.com>

Добрый день,

23 января 2015 г., 11:41 пользователь Павел Щербинин
<dzirtik на gmail.com> написал:
> 5 февраля Moscow.pm

А есть еще свободные слоты под доклады на ближайшей встрече?

Best regards,
Sergey Aleynikov

From chesnokov.ilya на gmail.com  Tue Jan 27 02:11:47 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Tue, 27 Jan 2015 14:11:47 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
In-Reply-To: <CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
	<CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>
Message-ID: <CANh0x-wAdCKePeiofzwS8VcJ85Y3NuH4R+bYm6GM2HkhxNiM-w@mail.gmail.com>

27 января 2015 г., 12:34 пользователь Dmitry Simonov
<dsimonov на gmail.com> написал:
>
> 27 января 2015 г., 10:54 пользователь Павел Купцов <pavel на kuptsov.info>
> написал:
>>
>> Полный рабочий день в нашем офисе в Монтевидео (Уругвай).
>
>
> 60 часов на маршрутке от ближайшего метро?

А зачем метро - там и так пробок нет ;)

> ---
> Dmitriy V. Simonov
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards,
Ilya Chesnokov

From greyhard на gmail.com  Tue Jan 27 02:27:04 2015
From: greyhard на gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQmNC70YzQuNC90YvRhQ==?=)
Date: Tue, 27 Jan 2015 14:27:04 +0400
Subject: [Moscow.pm] =?utf-8?b?0J/QsNGAY9C10YAg0L3QsCBtb2pvINGBINC90LU=?=
	=?utf-8?b?0YHQutC+0LvRjNC60LjQvNC4IElQ?=
Message-ID: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>

Здравствуйте.
Есть сервер с кучей айпи, Пытаюсь на mojo написать парсер что бы на каждый
запрос использовался разный айпи.

my $max_conn = 4;
Mojo::IOLoop->recurring(
    0 => sub {
        for ($active + 1 .. $max_conn) {
            return ($active or Mojo::IOLoop->stop)
                unless my $ip = shift @ips;
            ++$active;
            $ua->local_address($ip);
            $ua->get('http://myip.ru/?ip='.$ip => \&get_ip);
        }
    }
);


Вывод

http://myip.ru/?ip=193.124.18.205 > remote_ip: 193.124.18.205

http://myip.ru/?ip=193.124.44.44 > remote_ip: 193.124.44.44

http://myip.ru/?ip=151.248.125.194 > remote_ip: 151.248.125.194

http://myip.ru/?ip=193.124.16.139 > remote_ip: 193.124.16.139

----- а вот отсюда начинаются несовпадения между тем что я хочу и тем что
получаю

http://myip.ru/?ip=194.58.61.231 > remote_ip: 193.124.18.205

http://myip.ru/?ip=193.124.44.45 > remote_ip: 193.124.16.139

http://myip.ru/?ip=193.124.18.206 > remote_ip: 151.248.125.194

http://myip.ru/?ip=194.58.61.232 > remote_ip: 193.124.18.205

http://myip.ru/?ip=193.124.16.184 > remote_ip: 193.124.16.139
В итоге идет разброд и шатание между айпи через который я хочу сделать
запрос и айпи через который этот запрос реально проходит.

Не могли бы подсказать как это правильно реализовать ?

-- 
С уважением.
Ильиных Денис
Программист
Компания "GT-Shop.ru"
Телефон: +7(963) 995-7616
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/214be395/attachment.html>

From chesnokov.ilya на gmail.com  Tue Jan 27 02:37:04 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Tue, 27 Jan 2015 14:37:04 +0400
Subject: [Moscow.pm] =?utf-8?b?0J/QsNGAY9C10YAg0L3QsCBtb2pvINGBINC90LU=?=
	=?utf-8?b?0YHQutC+0LvRjNC60LjQvNC4IElQ?=
In-Reply-To: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
References: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
Message-ID: <CANh0x-wX2WpojVLBLA33wy+Z_j-CW1REJ6b1oJEvz-yzk6QabA@mail.gmail.com>

27 января 2015 г., 13:27 пользователь Денис Ильиных
<greyhard на gmail.com> написал:
> Здравствуйте.
> Есть сервер с кучей айпи, Пытаюсь на mojo написать парсер что бы на каждый
> запрос использовался разный айпи.
>
> my $max_conn = 4;
> Mojo::IOLoop->recurring(
>     0 => sub {
>         for ($active + 1 .. $max_conn) {
>             return ($active or Mojo::IOLoop->stop)
>                 unless my $ip = shift @ips;
>             ++$active;
>             $ua->local_address($ip);
>             $ua->get('http://myip.ru/?ip='.$ip => \&get_ip);
>         }
>     }
> );
>
>
> Вывод
>
> http://myip.ru/?ip=193.124.18.205 > remote_ip: 193.124.18.205
>
> http://myip.ru/?ip=193.124.44.44 > remote_ip: 193.124.44.44
>
> http://myip.ru/?ip=151.248.125.194 > remote_ip: 151.248.125.194
>
> http://myip.ru/?ip=193.124.16.139 > remote_ip: 193.124.16.139
>
> ----- а вот отсюда начинаются несовпадения между тем что я хочу и тем что
> получаю
>
> http://myip.ru/?ip=194.58.61.231 > remote_ip: 193.124.18.205
>
> http://myip.ru/?ip=193.124.44.45 > remote_ip: 193.124.16.139
>
> http://myip.ru/?ip=193.124.18.206 > remote_ip: 151.248.125.194
>
> http://myip.ru/?ip=194.58.61.232 > remote_ip: 193.124.18.205
>
> http://myip.ru/?ip=193.124.16.184 > remote_ip: 193.124.16.139
>
> В итоге идет разброд и шатание между айпи через который я хочу сделать
> запрос и айпи через который этот запрос реально проходит.

Похоже, что переопределение local_address() не работает для уже
соединившегося с хостом Mojo::UserAgent.
Попробуйте создать отдельного агента на каждый IP и выбирать
определенного агента для каждого запроса.

> Не могли бы подсказать как это правильно реализовать ?
>
> --
> С уважением.
> Ильиных Денис
> Программист
> Компания "GT-Shop.ru"
> Телефон: +7(963) 995-7616
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards,
Ilya Chesnokov

From snelius на tsu.ru  Tue Jan 27 02:40:16 2015
From: snelius на tsu.ru (Anatoly Y)
Date: Tue, 27 Jan 2015 16:40:16 +0600
Subject: [Moscow.pm] =?utf-8?b?0J/QsNGAY9C10YAg0L3QsCBtb2pvINGBINC90LU=?=
	=?utf-8?b?0YHQutC+0LvRjNC60LjQvNC4IElQ?=
In-Reply-To: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
References: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
Message-ID: <CAMGPQmu8LOA36a6d0sbuPG-CT_tJJtndgeQnT4WbC7n=gtKpCQ@mail.gmail.com>

Нужно покрутить маршрутизацию (iptables|ipfw). Чтобы пакеты возвращались на
тот ойпи откуда они ушли.

2015-01-27 16:27 GMT+06:00 Денис Ильиных <greyhard на gmail.com>:

> Здравствуйте.
> Есть сервер с кучей айпи, Пытаюсь на mojo написать парсер что бы на каждый
> запрос использовался разный айпи.
>
> my $max_conn = 4;
> Mojo::IOLoop->recurring(
>     0 => sub {
>         for ($active + 1 .. $max_conn) {
>             return ($active or Mojo::IOLoop->stop)
>                 unless my $ip = shift @ips;
>             ++$active;
>             $ua->local_address($ip);
>             $ua->get('http://myip.ru/?ip='.$ip => \&get_ip);
>         }
>     }
> );
>
>
> Вывод
>
> http://myip.ru/?ip=193.124.18.205 > remote_ip: 193.124.18.205
>
> http://myip.ru/?ip=193.124.44.44 > remote_ip: 193.124.44.44
>
> http://myip.ru/?ip=151.248.125.194 > remote_ip: 151.248.125.194
>
> http://myip.ru/?ip=193.124.16.139 > remote_ip: 193.124.16.139
>
> ----- а вот отсюда начинаются несовпадения между тем что я хочу и тем что
> получаю
>
> http://myip.ru/?ip=194.58.61.231 > remote_ip: 193.124.18.205
>
> http://myip.ru/?ip=193.124.44.45 > remote_ip: 193.124.16.139
>
> http://myip.ru/?ip=193.124.18.206 > remote_ip: 151.248.125.194
>
> http://myip.ru/?ip=194.58.61.232 > remote_ip: 193.124.18.205
>
> http://myip.ru/?ip=193.124.16.184 > remote_ip: 193.124.16.139
> В итоге идет разброд и шатание между айпи через который я хочу сделать
> запрос и айпи через который этот запрос реально проходит.
>
> Не могли бы подсказать как это правильно реализовать ?
>
> --
> С уважением.
> Ильиных Денис
> Программист
> Компания "GT-Shop.ru"
> Телефон: +7(963) 995-7616
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/f4d25ea4/attachment.html>

From dsimonov на gmail.com  Tue Jan 27 02:45:22 2015
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Tue, 27 Jan 2015 13:45:22 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
In-Reply-To: <CANh0x-wAdCKePeiofzwS8VcJ85Y3NuH4R+bYm6GM2HkhxNiM-w@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
	<CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>
	<CANh0x-wAdCKePeiofzwS8VcJ85Y3NuH4R+bYm6GM2HkhxNiM-w@mail.gmail.com>
Message-ID: <CAL9wMxX0Gj88np6qj8zmD1pLFh0j=sv2dZyXAinNXEs1gCYyaw@mail.gmail.com>

27 января 2015 г., 13:11 пользователь Ilya Chesnokov <
chesnokov.ilya на gmail.com> написал:

> > 60 часов на маршрутке от ближайшего метро?
>
> А зачем метро - там и так пробок нет ;)


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

---
Dmitriy V. Simonov
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/e412a615/attachment.html>

From shafiev на gmail.com  Tue Jan 27 02:49:41 2015
From: shafiev на gmail.com (Naim Shafiev)
Date: Tue, 27 Jan 2015 14:49:41 +0400
Subject: [Moscow.pm] =?utf-8?b?0J/QsNGAY9C10YAg0L3QsCBtb2pvINGBINC90LU=?=
	=?utf-8?b?0YHQutC+0LvRjNC60LjQvNC4IElQ?=
In-Reply-To: <CAMGPQmu8LOA36a6d0sbuPG-CT_tJJtndgeQnT4WbC7n=gtKpCQ@mail.gmail.com>
References: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
	<CAMGPQmu8LOA36a6d0sbuPG-CT_tJJtndgeQnT4WbC7n=gtKpCQ@mail.gmail.com>
Message-ID: <CAGYhLe167CXH5fVp=5v8DBt4jo8Eox6M9OcGOcuatfXd0qPj+Q@mail.gmail.com>

policy based routing - PBR это крайний случай . но на линуксе это довольно
просто .
On Jan 27, 2015 1:40 PM, "Anatoly Y" <snelius на tsu.ru> wrote:

> Нужно покрутить маршрутизацию (iptables|ipfw). Чтобы пакеты возвращались
> на тот ойпи откуда они ушли.
>
> 2015-01-27 16:27 GMT+06:00 Денис Ильиных <greyhard на gmail.com>:
>
>> Здравствуйте.
>> Есть сервер с кучей айпи, Пытаюсь на mojo написать парсер что бы на
>> каждый запрос использовался разный айпи.
>>
>> my $max_conn = 4;
>> Mojo::IOLoop->recurring(
>>     0 => sub {
>>         for ($active + 1 .. $max_conn) {
>>             return ($active or Mojo::IOLoop->stop)
>>                 unless my $ip = shift @ips;
>>             ++$active;
>>             $ua->local_address($ip);
>>             $ua->get('http://myip.ru/?ip='.$ip => \&get_ip);
>>         }
>>     }
>> );
>>
>>
>> Вывод
>>
>> http://myip.ru/?ip=193.124.18.205 > remote_ip: 193.124.18.205
>>
>> http://myip.ru/?ip=193.124.44.44 > remote_ip: 193.124.44.44
>>
>> http://myip.ru/?ip=151.248.125.194 > remote_ip: 151.248.125.194
>>
>> http://myip.ru/?ip=193.124.16.139 > remote_ip: 193.124.16.139
>>
>> ----- а вот отсюда начинаются несовпадения между тем что я хочу и тем что
>> получаю
>>
>> http://myip.ru/?ip=194.58.61.231 > remote_ip: 193.124.18.205
>>
>> http://myip.ru/?ip=193.124.44.45 > remote_ip: 193.124.16.139
>>
>> http://myip.ru/?ip=193.124.18.206 > remote_ip: 151.248.125.194
>>
>> http://myip.ru/?ip=194.58.61.232 > remote_ip: 193.124.18.205
>>
>> http://myip.ru/?ip=193.124.16.184 > remote_ip: 193.124.16.139
>> В итоге идет разброд и шатание между айпи через который я хочу сделать
>> запрос и айпи через который этот запрос реально проходит.
>>
>> Не могли бы подсказать как это правильно реализовать ?
>>
>> --
>> С уважением.
>> Ильиных Денис
>> Программист
>> Компания "GT-Shop.ru"
>> Телефон: +7(963) 995-7616
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/1784ef22/attachment-0001.html>

From chesnokov.ilya на gmail.com  Tue Jan 27 03:03:09 2015
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Tue, 27 Jan 2015 15:03:09 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
In-Reply-To: <CAL9wMxX0Gj88np6qj8zmD1pLFh0j=sv2dZyXAinNXEs1gCYyaw@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
	<CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>
	<CANh0x-wAdCKePeiofzwS8VcJ85Y3NuH4R+bYm6GM2HkhxNiM-w@mail.gmail.com>
	<CAL9wMxX0Gj88np6qj8zmD1pLFh0j=sv2dZyXAinNXEs1gCYyaw@mail.gmail.com>
Message-ID: <CANh0x-wJatz=295NVwD+RXreM5owts7RKN4+i5bJmUv02D4fNg@mail.gmail.com>

27 января 2015 г., 13:45 пользователь Dmitry Simonov
<dsimonov на gmail.com> написал:
>
> 27 января 2015 г., 13:11 пользователь Ilya Chesnokov
> <chesnokov.ilya на gmail.com> написал:
>>
>> > 60 часов на маршрутке от ближайшего метро?
>>
>> А зачем метро - там и так пробок нет ;)
>
>
> Там куда зовут перловиков, пробки должны быть по дефолту. Слишком дорогое
> удовольствие для дешёвых деревенек звать перловиков.

Аа, тогда надо перефразировать: 60 часов на маршрутке от ближайшего
метро - или 30 минут пешком.

> ---
> Dmitriy V. Simonov
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards,
Ilya Chesnokov

From rollant на gmail.com  Tue Jan 27 03:22:14 2015
From: rollant на gmail.com (Andrey Yuldashev)
Date: Tue, 27 Jan 2015 15:22:14 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
In-Reply-To: <CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
	<CAL9wMxVpA0AyDx5m9LLVxtpEX8oOD_X6KvHxPY6fkKJFyH3jjw@mail.gmail.com>
Message-ID: <CANt=LN2+=SWycOAvey22gwBXw79uXMM8B4ejK=rF6E9H3KJqnw@mail.gmail.com>

До ближайшего метро там три часа на пароме

2015-01-27 12:34 GMT+03:00 Dmitry Simonov <dsimonov на gmail.com>:

>
> 27 января 2015 г., 10:54 пользователь Павел Купцов <pavel на kuptsov.info>
> написал:
>
>> Полный рабочий день в нашем офисе в Монтевидео (Уругвай).
>
>
> 60 часов на маршрутке от ближайшего метро?
>
> ---
> Dmitriy V. Simonov
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/f2ee83e7/attachment.html>

From dmitry на eremeev.ru  Tue Jan 27 03:34:46 2015
From: dmitry на eremeev.ru (Dmitry Eremeev)
Date: Tue, 27 Jan 2015 14:34:46 +0300
Subject: [Moscow.pm] =?koi8-r?b?4SDXz9Qg18/a2M3J1MUg0MXSzM/XycvBINMg+sXM?=
	=?koi8-r?b?xc7Px9LBxME=?=
In-Reply-To: <CAGYhLe167CXH5fVp=5v8DBt4jo8Eox6M9OcGOcuatfXd0qPj+Q@mail.gmail.com>
References: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
	<CAMGPQmu8LOA36a6d0sbuPG-CT_tJJtndgeQnT4WbC7n=gtKpCQ@mail.gmail.com>
	<CAGYhLe167CXH5fVp=5v8DBt4jo8Eox6M9OcGOcuatfXd0qPj+Q@mail.gmail.com>
Message-ID: <123332B8-1B3F-4490-BEB8-40AC2B80456D@eremeev.ru>

Кум неспешно работу ищет, сюда не подписан, может договоритесь:
http://zelenograd.hh.ru/resume/51fec43dff01eb0b090039ed1f6261714d3335
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/5490ed53/attachment.html>

From greyhard на gmail.com  Tue Jan 27 03:36:42 2015
From: greyhard на gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQmNC70YzQuNC90YvRhQ==?=)
Date: Tue, 27 Jan 2015 15:36:42 +0400
Subject: [Moscow.pm] =?utf-8?b?0J/QsNGAY9C10YAg0L3QsCBtb2pvINGBINC90LU=?=
	=?utf-8?b?0YHQutC+0LvRjNC60LjQvNC4IElQ?=
In-Reply-To: <CAMGPQmu8LOA36a6d0sbuPG-CT_tJJtndgeQnT4WbC7n=gtKpCQ@mail.gmail.com>
References: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
	<CAMGPQmu8LOA36a6d0sbuPG-CT_tJJtndgeQnT4WbC7n=gtKpCQ@mail.gmail.com>
Message-ID: <CAEBNeas2rxfWArqB4aGSEFy9gipw9n_5bgCEdk7xJ227_QTnQA@mail.gmail.com>

Не могу понять причем тут (iptables|ipfw) так как если делать все в цикле
все запросы по очереди все работает нормально. Через какой айпи запрашиваю
тот айпи и получаю.

Вероятно был прав Илья что конкурентные запросы переписывают общий $ua и
поэтому надо подымать по отдельному экземпляру для каждого запроса ). Но
это мне ломает голову чуть чуть.


27 января 2015 г., 13:40 пользователь Anatoly Y <snelius на tsu.ru> написал:

> Нужно покрутить маршрутизацию (iptables|ipfw). Чтобы пакеты возвращались
> на тот ойпи откуда они ушли.
>
> 2015-01-27 16:27 GMT+06:00 Денис Ильиных <greyhard на gmail.com>:
>
>> Здравствуйте.
>> Есть сервер с кучей айпи, Пытаюсь на mojo написать парсер что бы на
>> каждый запрос использовался разный айпи.
>>
>> my $max_conn = 4;
>> Mojo::IOLoop->recurring(
>>     0 => sub {
>>         for ($active + 1 .. $max_conn) {
>>             return ($active or Mojo::IOLoop->stop)
>>                 unless my $ip = shift @ips;
>>             ++$active;
>>             $ua->local_address($ip);
>>             $ua->get('http://myip.ru/?ip='.$ip => \&get_ip);
>>         }
>>     }
>> );
>>
>>
>> Вывод
>>
>> http://myip.ru/?ip=193.124.18.205 > remote_ip: 193.124.18.205
>>
>> http://myip.ru/?ip=193.124.44.44 > remote_ip: 193.124.44.44
>>
>> http://myip.ru/?ip=151.248.125.194 > remote_ip: 151.248.125.194
>>
>> http://myip.ru/?ip=193.124.16.139 > remote_ip: 193.124.16.139
>>
>> ----- а вот отсюда начинаются несовпадения между тем что я хочу и тем что
>> получаю
>>
>> http://myip.ru/?ip=194.58.61.231 > remote_ip: 193.124.18.205
>>
>> http://myip.ru/?ip=193.124.44.45 > remote_ip: 193.124.16.139
>>
>> http://myip.ru/?ip=193.124.18.206 > remote_ip: 151.248.125.194
>>
>> http://myip.ru/?ip=194.58.61.232 > remote_ip: 193.124.18.205
>>
>> http://myip.ru/?ip=193.124.16.184 > remote_ip: 193.124.16.139
>> В итоге идет разброд и шатание между айпи через который я хочу сделать
>> запрос и айпи через который этот запрос реально проходит.
>>
>> Не могли бы подсказать как это правильно реализовать ?
>>
>> --
>> С уважением.
>> Ильиных Денис
>> Программист
>> Компания "GT-Shop.ru"
>> Телефон: +7(963) 995-7616
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением.
Ильиных Денис
Программист
Компания "GT-Shop.ru"
Телефон: +7(963) 995-7616
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150127/823a725a/attachment-0001.html>

From pef-secure на yandex.ru  Tue Jan 27 06:01:01 2015
From: pef-secure на yandex.ru (PEF Secure)
Date: Tue, 27 Jan 2015 15:01:01 +0100
Subject: [Moscow.pm] =?utf-8?b?0J/QsNGAY9C10YAg0L3QsCBtb2pvINGBINC90LU=?=
	=?utf-8?b?0YHQutC+0LvRjNC60LjQvNC4IElQ?=
In-Reply-To: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
References: <CAEBNeasA1-oXc32XC+TisuTvK_gXwsXj5MbVW=NbgErisiM_NQ@mail.gmail.com>
Message-ID: <1840943.xsXgNDv9kk@rawen>

On Tuesday, January 27, 2015 14:27:04 Денис Ильиных wrote:
> Здравствуйте.
> Есть сервер с кучей айпи, Пытаюсь на mojo написать парсер что бы на каждый
> запрос использовался разный айпи.
> 
> my $max_conn = 4;
> Mojo::IOLoop->recurring(
>     0 => sub {
>         for ($active + 1 .. $max_conn) {
>             return ($active or Mojo::IOLoop->stop)
>                 unless my $ip = shift @ips;
>             ++$active;
>             $ua->local_address($ip);
>             $ua->get('http://myip.ru/?ip='.$ip => \&get_ip);
>         }
>     }
> );
> 

Поскольку объект $ua один в раммках процесса, то каждый вызов  $ua-
>local_address($ip); переписывает данные объекта в то время, как $ua->get 
выполняются асинхронно. 
-- 
PEF Developer

From thecrux на gmail.com  Tue Jan 27 06:06:11 2015
From: thecrux на gmail.com (Vladimir Lettiev)
Date: Tue, 27 Jan 2015 17:06:11 +0300
Subject: [Moscow.pm] =?koi8-r?b?IOTM0SDUxcgsIMvUzyDJ3cXUINDF0szP18nLz9c=?=
In-Reply-To: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
References: <CAPcuxSbV57yAyvcxFD-Qu-KCJ+dwy9Z4_M4Hh5gw8PqCm=zMuw@mail.gmail.com>
Message-ID: <20150127140611.GA12427@mail.truecrux.org>

On Tue, Jan 27, 2015 at 10:54:29AM +0300, Павел Купцов wrote:
> Для тех кто ищет работу - вот недавно предлагали такой вариант:

Полгода назад в этом списке рассылки анонсировали https://perljobs.ru

Может туда дублировать поток вакансий, чтобы не затерялись?

-- 
Vladimir Lettiev aka crux ? theCrux на gmail.com

From akzhan.abdulin на gmail.com  Thu Jan 29 08:12:35 2015
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Thu, 29 Jan 2015 19:12:35 +0300
Subject: [Moscow.pm] =?utf-8?b?0JLQsNC60LDQvdGB0LjRjyBQZXJsLdC/0YDQvtCz?=
	=?utf-8?b?0YDQsNC80LzQuNGB0YIgKyDQstGB0ZEg0LLQvtC60YDRg9CzIDstKQ==?=
In-Reply-To: <9599671422126192@web7m.yandex.ru>
References: <9599671422126192@web7m.yandex.ru>
Message-ID: <CAGOcgF2Fa9Ry9m8bFf=gnVoZ6eM6_0HaxgXOG7AWN-kU2O5cnA@mail.gmail.com>

Когда-то ехал туда на собеседование, но перехватили в .masterhost :)

24 января 2015 г., 22:03 пользователь Loginoff Nick <stork2000 на yandex.ru>
написал:

> Проект ?Бойцовский Клуб? - браузерная онлайн-игра ( http://combats.com ) .
>
> Требования:
> Отличное владение Perl, SQL.
> Опыт работы в области разработки web-приложений не менее 3-x лет.
> Опыт работы с системой контроля версий Git.
>
> Желательно:
> Опыт работы с PostgresSQL
> Знание Javascript и умение создавать интерфейсы под разные браузеры.
> Опыт работы с высоконагруженными системами
> Опыт работы в игровых проектах
>
> Задачи:
> Разработка нового игрового контента.
> Поддержка и оптимизация существующего кода.
>
> Условия:
> Уровень заработной платы - 120.000р (и более, если вы этого стоите)
> Офис: ст. м. Тульская (2 мин. пешком)
> Обеды в офисе
> Пятидневная рабочая неделя с 10 до 19 (время можно скорректировать).
> Оформление по ТК РФ.
>
> Кидайте резюме мне на прямую STork2000 на yandex.ru
> --
> С Уважением, Login|off Nick или STork.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150129/4a306d4a/attachment.html>

From nordicdyno на yandex.ru  Thu Jan 29 08:53:02 2015
From: nordicdyno на yandex.ru (Orlovsky Alexander)
Date: Thu, 29 Jan 2015 19:53:02 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?98HLwc7TydEgUGVybC3Q0s/H0sHNzcnT1CArINfT?=
	=?koi8-r?b?oyDXz8vS1ccgOy0p?=
In-Reply-To: <CAGOcgF2Fa9Ry9m8bFf=gnVoZ6eM6_0HaxgXOG7AWN-kU2O5cnA@mail.gmail.com>
References: <9599671422126192@web7m.yandex.ru>
	<CAGOcgF2Fa9Ry9m8bFf=gnVoZ6eM6_0HaxgXOG7AWN-kU2O5cnA@mail.gmail.com>
Message-ID: <2079211422550382@web22h.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150129/aada9f12/attachment.html>

From dzirtik на gmail.com  Thu Jan 29 08:56:39 2015
From: dzirtik на gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQqdC10YDQsdC40L3QuNC9?=)
Date: Thu, 29 Jan 2015 19:56:39 +0300
Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?=
	=?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?=
Message-ID: <CAJxdCZ55GgtQL4E64P3X7-7LWQWFDk8o_o+SigdU260gzfX1aw@mail.gmail.com>

   -

   Perl-программисты из Moscow.pm <http://moscow.pm/> снова собирают
   единомышленников. За почти 8 лет существования Perl Mongers (от англ.
   ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном
   офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с
   первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы
   поделиться действительно полезным опытом. Однажды запланированное на 40
   минут выступление о ядре Perl так увлекло участников, что дискуссия
   растянулась на 3 часа, и все разошлись по домам только к полуночи.

   Предстоящая встреча заинтересует специалистов в e-commerce и тех, кто не
   понаслышке знаком с очередями. А ленивым программистам и тем, кто не любит
   делать лишнюю работу, будет полезен доклад о генерации кода.

   О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова,
   ex-СТО SHOP2YOU.RU <http://shop2you.ru/>. В e-commerce файлы формата
   Excel ? основной инструмент обмена данными. Они используются везде: для
   документов покупателям и транспортным компаниям, для отчетов менеджерам,
   для импорта и экспорта товаров в магазин, для обмена остатками между
   поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как это
   делать с документами разной структуры, а также поговорит о сложностях и их
   решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и
   модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template.

   ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ?
   выступления Ивана Соколова, teamlead REG.RU <http://reg.ru/>. Очередь ?
   один из наиболее используемых механизмов в программировании. Например, для
   интеграции с платежными системами или для обработки медиа-контента,
   загруженного пользователем, необходимо наличие очередей.

   В REG.RU тоже не обходятся без очередей. Поэтому потребность найти
   решение появилась достаточно давно. Учитывая специфику компании как
   доменного регистратора большинство существующих решений не подходило, и
   программисты решили ?написать свой велосипед?. Иван расскажет об
   архитектуре их очереди, ее возможностях, и в каких задачах она используется.

   ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены
   Шишкиной, ведущего программиста Деньги Mail.Ru <https://money.mail.ru/>.
   Она покажет практический пример лени как двигателя прогресса в отдельно
   взятом веб-проекте:

   - Надоело писать код? Будем думать, как его не писать!

   - Боремся с однотипным кодом. Боремся с неоднотипным кодом.

   - Код, которого не существует, и код, который существует.

   - Следите за руками: программируем на конфигах!

   - Как жить дальше?


   Что бы мы могли лучше организовать наше мероприятие, пожалуйста,
   зарегистрируйтесь здесь <http://corp.mail.ru/ru/press/events/48/>


-- 
С Уважением,
Щербинин Павел
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150129/137cfb74/attachment-0001.html>

From dim0xff на gmail.com  Thu Jan 29 09:29:06 2015
From: dim0xff на gmail.com (Dmitry L.)
Date: Thu, 29 Jan 2015 21:29:06 +0400
Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?=
	=?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?=
In-Reply-To: <CAJxdCZ55GgtQL4E64P3X7-7LWQWFDk8o_o+SigdU260gzfX1aw@mail.gmail.com>
References: <CAJxdCZ55GgtQL4E64P3X7-7LWQWFDk8o_o+SigdU260gzfX1aw@mail.gmail.com>
Message-ID: <CAKgzkX2uzR_ZB3h5+hMm5zv+BbQFbRHFFM=0k1PVqUD_3+s4ZA@mail.gmail.com>

Назад в прошлое!
On Jan 29, 2015 7:57 PM, "Павел Щербинин" <dzirtik на gmail.com> wrote:

>
>    -
>
>    Perl-программисты из Moscow.pm <http://moscow.pm/> снова собирают
>    единомышленников. За почти 8 лет существования Perl Mongers (от англ.
>    ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном
>    офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с
>    первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы
>    поделиться действительно полезным опытом. Однажды запланированное на 40
>    минут выступление о ядре Perl так увлекло участников, что дискуссия
>    растянулась на 3 часа, и все разошлись по домам только к полуночи.
>
>    Предстоящая встреча заинтересует специалистов в e-commerce и тех, кто
>    не понаслышке знаком с очередями. А ленивым программистам и тем, кто не
>    любит делать лишнюю работу, будет полезен доклад о генерации кода.
>
>    О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова,
>    ex-СТО SHOP2YOU.RU <http://shop2you.ru/>. В e-commerce файлы формата
>    Excel ? основной инструмент обмена данными. Они используются везде: для
>    документов покупателям и транспортным компаниям, для отчетов менеджерам,
>    для импорта и экспорта товаров в магазин, для обмена остатками между
>    поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как это
>    делать с документами разной структуры, а также поговорит о сложностях и их
>    решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и
>    модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template.
>
>    ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ?
>    выступления Ивана Соколова, teamlead REG.RU <http://reg.ru/>. Очередь
>    ? один из наиболее используемых механизмов в программировании. Например,
>    для интеграции с платежными системами или для обработки медиа-контента,
>    загруженного пользователем, необходимо наличие очередей.
>
>    В REG.RU тоже не обходятся без очередей. Поэтому потребность найти
>    решение появилась достаточно давно. Учитывая специфику компании как
>    доменного регистратора большинство существующих решений не подходило, и
>    программисты решили ?написать свой велосипед?. Иван расскажет об
>    архитектуре их очереди, ее возможностях, и в каких задачах она используется.
>
>    ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены
>    Шишкиной, ведущего программиста Деньги Mail.Ru <https://money.mail.ru/>.
>    Она покажет практический пример лени как двигателя прогресса в отдельно
>    взятом веб-проекте:
>
>    - Надоело писать код? Будем думать, как его не писать!
>
>    - Боремся с однотипным кодом. Боремся с неоднотипным кодом.
>
>    - Код, которого не существует, и код, который существует.
>
>    - Следите за руками: программируем на конфигах!
>
>    - Как жить дальше?
>
>
>    Что бы мы могли лучше организовать наше мероприятие, пожалуйста,
>    зарегистрируйтесь здесь <http://corp.mail.ru/ru/press/events/48/>
>
>
> --
> С Уважением,
> Щербинин Павел
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150129/f31107b3/attachment.html>

From mi на ya.ru  Thu Jan 29 15:48:59 2015
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 30 Jan 2015 02:48:59 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?99PU0sXewSBNb3Njb3cucG0gNSDGxdfSwczRIDIw?=
	=?koi8-r?b?MTM=?=
In-Reply-To: <CAJxdCZ55GgtQL4E64P3X7-7LWQWFDk8o_o+SigdU260gzfX1aw@mail.gmail.com>
References: <CAJxdCZ55GgtQL4E64P3X7-7LWQWFDk8o_o+SigdU260gzfX1aw@mail.gmail.com>
Message-ID: <10604161422575339@web28m.yandex.ru>

Паша, привет, я и так жду не дождусь поговорить про Perl,
так ты еще и так заинтриговал;)))
Выглядит, как красивая замануха на шоу на 1-м канале.
Хотя веб-трансляция же будет - так, что полноценное шоу,
кстати после очередной лекции на работе-
 чувствуешь, что макси-минимальный доклад -
 минут 40, дальше теряешь внимание, только, если это не Лари Волл,Руслан Закиров, Домиан Конвей, Павел Щербинин или Стив Джобс ;))))

29.01.2015, 19:56, "Павел Щербинин" <dzirtik на gmail.com>:
> *
>
> Perl-программисты из Moscow.pm снова собирают единомышленников. За почти 8 лет существования Perl Mongers (от англ. ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы поделиться действительно полезным опытом. Однажды запланированное на 40 минут выступление о ядре Perl так увлекло участников, что дискуссия растянулась на 3 часа, и все разошлись по домам только к полуночи.
>
> Предстоящая встреча заинтересует специалистов в e-commerce и тех, кто не понаслышке знаком с очередями. А ленивым программистам и тем, кто не любит делать лишнюю работу, будет полезен доклад о генерации кода.
>
> О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова, ex-СТО SHOP2YOU.RU. В e-commerce файлы формата Excel ? основной инструмент обмена данными. Они используются везде: для документов покупателям и транспортным компаниям, для отчетов менеджерам, для импорта и экспорта товаров в магазин, для обмена остатками между поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как это делать с документами разной структуры, а также поговорит о сложностях и их решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template.
>
> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? выступления Ивана Соколова, teamlead REG.RU. Очередь ? один из наиболее используемых механизмов в программировании. Например, для интеграции с платежными системами или для обработки медиа-контента, загруженного пользователем, необходимо наличие очередей.
>
> В REG.RU тоже не обходятся без очередей. Поэтому потребность найти решение появилась достаточно давно. Учитывая специфику компании как доменного регистратора большинство существующих решений не подходило, и программисты решили ?написать свой велосипед?. Иван расскажет об архитектуре их очереди, ее возможностях, и в каких задачах она используется.
>
> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены Шишкиной, ведущего программиста Деньги Mail.Ru. Она покажет практический пример лени как двигателя прогресса в отдельно взятом веб-проекте:
>
> - Надоело писать код? Будем думать, как его не писать!
>
> - Боремся с однотипным кодом. Боремся с неоднотипным кодом.
>
> - Код, которого не существует, и код, который существует.
>
> - Следите за руками: программируем на конфигах!
>
> - Как жить дальше?
>
> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, зарегистрируйтесь здесь
>
> --
> С Уважением,
> Щербинин Павел
>
> ,
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
С уважением
Николай Мишин


From ponizovsky на gmail.com  Fri Jan 30 04:46:47 2015
From: ponizovsky на gmail.com (Eugene Ponizovsky)
Date: Fri, 30 Jan 2015 15:46:47 +0300
Subject: [Moscow.pm] =?utf-8?b?0JHQsNCzINCyIEpTT046OlhTPw==?=
In-Reply-To: <op.xp2s0fxenlncg2@localhost>
References: <CAM4vdXC8wC5LYzyxFJhK_Va1aCYVLBBRtCvcTXBktKZt87UJgw@mail.gmail.com>
	<op.xp1kixywnlncg2@localhost>
	<CAF7QZD7vh7OE3vw7rbY6bG5je9tVoqkaMWWdO4nDwKoBYckCQg@mail.gmail.com>
	<op.xp2s0fxenlncg2@localhost>
Message-ID: <69C5B3C1-CA95-4BDA-88E2-D526F67F7954@gmail.com>

Приветствую.

Вот еще столкнулся со странным поведением JSON::XS (3.01).

Пытаюсь сериализовать объект, содержащий объекты, используя функцию FREEZE. Один из объектов содержит большое число аргументов (61 пара ключ-значение). При сериализации такого объекта скрипт падает с ошибкой "Segmentation fault" или метод encode() возвращает undef.

Иногда скрипт работает корректно. В этом случае незначительное увеличение кол-ва аргументов или уровня вложенности объектов снова приводит к выше описанному результату.

Cpanel::JSON::XS ведет себя также. Ошибка проявляется на разных машинах и OS (Linux, FreeBSD, OS X).

Пример:

#!/usr/bin/env perl

use 5.010000;
use strict;
use warnings;

use JSON::XS;

my $json_szr = JSON::XS->new();
$json_szr->allow_tags( 1 );

my @foo_params;
for ( 1 .. 61 ) {
  push ( @foo_params, "coo$_" => 1 );
}
my $foo1 = Foo->new( @foo_params );
my $foo2 = Foo->new( @foo_params );

my $bar1 = Bar->new(
  foo => $foo1,
);

my $bar2 = Bar->new(
  foo => $foo2,
  bar => $bar1
);

my $bar_json = $json_szr->encode( $bar2 );
if ( defined $bar_json ) {
  say $bar_json;
}


package Foo;

####
sub new {
  my $class = shift;
  my %params = @_;
 
  return bless \%params, $class;
}

####
sub FREEZE {
  my $self = shift;
  
  return %{$self};
}

####
sub THAW {
  my $class = shift;
  my $szr   = shift;

  return $class->new( @_ );
}


package Bar;

####
sub new {
  my $class = shift;
  my %params = @_;
 
  return bless \%params, $class;
}

####
sub FREEZE {
  my $self = shift;
  
  return %{$self};
}

> 29 нояб. 2014 г., в 10:42, TheAthlete <theathlet на yandex.ru> написал(а):
> 
> Согласен, что перекрывает, но здесь JSON::XS создан с методом
> convert_blessed, который говорит, что переданный обхект должен иметь метод
> TO_JSON. Объект модуля boolean имеет данный метод.
> 
> $  perl -MData::Printer -MCpanel::JSON::XS -Mboolean=-truth -E '$j =
> Cpanel::JSON::XS->new->convert_blessed; $b = (0 == 1); say
> $j->encode({false => $b}); p$b'
> {"false":false}
> boolean  {
>      Parents       Exporter
>      public methods (9) : boolean, false, import, isBoolean, isFalse,
> isTrue, TO_JSON, true, truth
>      private methods (1) : __ANON__
>      internals: 0
> }
> 
> $  perl -MData::Printer -MJSON::XS -Mboolean=-truth -E '$j =
> JSON::XS->new->convert_blessed; $b = (0 == 1); say $j->encode({false =>
> $b}); p $b'
> Modification of a read-only value attempted at -e line 1.
> 
> Насколько я понял, эта ошибка связана с приведением к строке булевых
> значений (Boolean stringify) в модуле boolean.
> 
> Данная ошибка была скорее всего исправлена в Cpanel::JSON::XS начиная с версии 2.3311 -
> https://github.com/rurban/Cpanel-JSON-XS/commit/a42d7b7ec05c9aad18ba9b0ef12c721c31a47317 <https://github.com/rurban/Cpanel-JSON-XS/commit/a42d7b7ec05c9aad18ba9b0ef12c721c31a47317>
> 
> Victor Efimov <victor на vsespb.ru <mailto:victor на vsespb.ru>> писал(а) в своём письме Fri, 28 Nov 2014
> 20:44:50 +0300:
> 
>> 28 ноября 2014 г., 18:41 пользователь TheAthlete <theathlet на yandex.ru> написал:
>>> Неделя багов в JSON::XS! :)
>> 
>> Почему это баг JSON::XS ?
>> 
>> use strict; use warnings;
>> use Test::More tests => 3;
>> use boolean -truth;
>> use JSON::XS;
>> my $json = JSON::XS->new;
>> is($json->encode({"hey" => !!0}), 'abc',  'JSON false works');
>> 
>> тоже фейлится. если
>> 
>> use boolean -truth;
>> 
>> закоментировать, то работает норм.
>> 
>> Это потому что опция
>> 
>> -truth
>> 
>> You can specify the -truth option to override truth operators to
>> return boolean values.
>> 
>> use boolean -truth;
>> print ref("hello" eq "world"), "\n";
>> 
>> 
>> перекрывает операторы Perl, чтобы они возвращали объект. Почему
>> считается что JSON::XS должен с этим работать ? Почему это не баг в
>> "boolean" ?
>> 
>> 
>>> Тоже столкнулся с багом в JSON::XS - при установке модуля boolean, который
>>> в зависимостях у Test::DBIx::Class, не был пройден тест json.t.
>>> Заглянув в issue данного модуля на github, нашел такой тикет:
>>> 
>>> json.t fails on many Linux systems -
>>> https://github.com/ingydotnet/boolean-pm/issues/5
>>> 
>>> Там некоторые советуют установить Cpanel::JSON::XS - установил и все
>>> заработало, хотя не у всех падает при установленном JSON::XS.
>>> 
>>> Если модифицировать тест:
>>> 
>>> use strict; use warnings;
>>> use Test::More tests => 3;
>>> use boolean -truth;
>>> my $HAVE_JSON = eval { require JSON::MaybeXS };
>>> SKIP: {
>>>      skip "JSON is missing", 3 unless $HAVE_JSON;
>>>      eval{
>>>          my $json = JSON::MaybeXS->new->convert_blessed();
>>>          is($json->encode({false => (0 == 1)}), '{"false":false}',
>>>              'JSON false works');
>>>        is($json->encode({true  => (1 == 1)}), '{"true":true}',
>>>            'JSON true works');
>>>        is(ref(boolean::TO_JSON(true)), 'SCALAR',
>>>            'Make sure we can call boolean::TO_JSON($b)');
>>>        }
>>> };
>>> 
>>> в следующий:
>>> 
>>> use strict; use warnings;
>>> use Test::More tests => 3;
>>> use boolean -truth;
>>> my $HAVE_JSON = eval { require JSON::XS };
>>> SKIP: {
>>>      skip "JSON is missing", 3 unless $HAVE_JSON;
>>>      my $json = JSON::XS->new->convert_blessed();
>>>      is($json->encode({false => (0 == 1)}), '{"false":false}',
>>>        'JSON false works');
>>>      is($json->encode({true  => (1 == 1)}), '{"true":true}',
>>>        'JSON true works');
>>>      is(ref(boolean::TO_JSON(true)), 'SCALAR',
>>>        'Make sure we can call boolean::TO_JSON($b)');
>>> };
>>> 
>>> и запустить, то тест сваливается с ошибкой "Modification of a read-only
>>> value attempted at test/json.t line 9"
>>> 
>>> Если заменить на Cpanel::JSON::XS или JSON::PP, то все ок
>>> 
>>> Вадим Власов <scripter.vrn на gmail.com> писал(а) в своём письме Wed, 26 Nov
>>> 2014 20:01:33 +0300:
>>> 
>>>> Исследуя новый сериализатор в JSON::XS наткнулся:
>>>> 
>>>> $ echo 'use strict;
>>>> use warnings;
>>>> use feature "say";
>>>> 
>>>> use JSON::XS;
>>>> my $j=JSON::XS->new->allow_tags;
>>>> 
>>>> say "JSON::XS: $JSON::XS::VERSION";
>>>> say "Types::Serialiser: $Types::Serialiser::VERSION";
>>>> 
>>>> my $t = $j->encode( Foo->new );
>>>> say $t;
>>>> 
>>>> my @t = $j->encode( Foo->new );
>>>> 
>>>> package Foo;
>>>> sub new { bless {}, $_[0]; }
>>>> sub FREEZE { ( 123, 456 ); }' | perl
>>>> *JSON::XS: 3.01*
>>>> *Types::Serialiser: 1.0*
>>>> *("Foo")[123,456]*
>>>> *panic: attempt to copy freed scalar c37a18 to c37a00 at - line 14.*
>>>> 
>>>> $ perl -MJSON::XS -wE 'say JSON::XS->new->allow_tags->encode( bless {},
>>>> Foo
>>>> ); package Foo; sub FREEZE{ return 123 }'
>>>> *Use of uninitialized value in say at -e line 1.*
>>>> *("Foo")[123]*
>>>> 
>>>> $ perl -MJSON::XS -wE 'say scalar( JSON::XS->new->allow_tags->encode(
>>>> bless
>>>> {}, Foo )); package Foo; sub FREEZE{ return 123 }'
>>>> *("Foo")[123]*
>>>> 
>>>> Проверили на разных машинах и на разных версиях perl-а - одно и то же.
>>>> 
>>> 
>>> 
>>> --
>>> Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
>>> 
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
> 
> 
> -- 
> Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ <http://www.opera.com/mail/>
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org <mailto:moscow-pm на pm.org> | http://moscow.pm.org <http://moscow.pm.org/>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150130/44bb720e/attachment-0001.html>

From ponizovsky на gmail.com  Fri Jan 30 04:57:13 2015
From: ponizovsky на gmail.com (Eugene Ponizovsky)
Date: Fri, 30 Jan 2015 15:57:13 +0300
Subject: [Moscow.pm] =?utf-8?b?0JHQsNCzINCyIEpTT046OlhTPw==?=
Message-ID: <943663F8-8579-4165-A899-3594810BA8B6@gmail.com>

Приветствую.

Столкнулся со странным поведением JSON::XS (3.01).

Пытаюсь сериализовать объект, содержащий объекты, используя функцию FREEZE. Один из объектов содержит большое число аргументов (61 пара ключ-значение). При сериализации такого объекта скрипт падает с ошибкой "Segmentation fault" или метод encode() возвращает undef.

Иногда скрипт работает корректно. В этом случае незначительное увеличение кол-ва аргументов или уровня вложенности объектов снова приводит к выше описанному результату.

Пример:

#!/usr/bin/env perl

use 5.010000;
use strict;
use warnings;

use JSON::XS;

my $json_szr = JSON::XS->new();
$json_szr->allow_tags( 1 );

my @foo_params;
for ( 1 .. 61 ) {
  push ( @foo_params, "coo$_" => 1 );
}
my $foo1 = Foo->new( @foo_params );
my $foo2 = Foo->new( @foo_params );

my $bar1 = Bar->new(
  foo => $foo1,
);

my $bar2 = Bar->new(
  foo => $foo2,
  bar => $bar1
);

my $bar_json = $json_szr->encode( $bar2 );
if ( defined $bar_json ) {
  say $bar_json;
}


package Foo;

####
sub new {
  my $class = shift;
  my %params = @_;
 
  return bless \%params, $class;
}

####
sub FREEZE {
  my $self = shift;
  
  return %{$self};
}

####
sub THAW {
  my $class = shift;
  my $szr   = shift;

  return $class->new( @_ );
}


package Bar;

# Аналогично Foo
?

С уважением
Евгений Понизовский


From mmm3 на bk.ru  Fri Jan 30 07:39:50 2015
From: mmm3 на bk.ru (=?UTF-8?B?0JzQsNC60YHQuNC8INCS0LvQsNC00LjQvNC40YDQvtCy0LjRhw==?=)
Date: Fri, 30 Jan 2015 18:39:50 +0300
Subject: [Moscow.pm] =?utf-8?b?0KfRgtC+INC/0L7RgdC+0LLQtdGC0YPQtdGC0LUg?=
 =?utf-8?b?0LTQu9GPINC+0L3Qu9Cw0LnQvSDRh9Cw0YLQsD8=?=
Message-ID: <1422632390.164683257@f338.i.mail.ru>

 Посоветуйте модуль который позволяет держать одновременно сотни тысяч  долгоживущих открытых HTTP-соединений с сервером. Нужно для онлайн чата. Есть какие то готовые варианты?


С уважением,

Максим
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150130/db63a880/attachment.html>

From denis.fedoseev на gmail.com  Fri Jan 30 10:44:24 2015
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Fri, 30 Jan 2015 21:44:24 +0300
Subject: [Moscow.pm]
 =?koi8-r?b?/tTPINDP08/XxdTVxdTFIMTM0SDPzszBys4g3sHU?=
 =?koi8-r?b?wT8=?=
In-Reply-To: <1422632390.164683257@f338.i.mail.ru>
References: <1422632390.164683257@f338.i.mail.ru>
Message-ID: <9E516914-9578-47D6-9FD8-F425493A5DD4@gmail.com>

Любая асинхронщина на плаке так может. Вопрос настройки ОС там намного интереснее. 

Sent from my iPad

> On 30 янв. 2015 г., at 18:39, Максим Владимирович <mmm3 на bk.ru> wrote:
> 
> Посоветуйте модуль который позволяет держать одновременно сотни тысяч долгоживущих открытых HTTP-соединений с сервером. Нужно для онлайн чата. Есть какие то готовые варианты?
> 
> 
> С уважением,
> 
> Максим
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

From aml на rulezz.ru  Fri Jan 30 12:06:28 2015
From: aml на rulezz.ru (Alexander Lourier)
Date: Fri, 30 Jan 2015 20:06:28 +0000
Subject: [Moscow.pm] =?utf-8?b?0KfRgtC+INC/0L7RgdC+0LLQtdGC0YPQtdGC0LUg?=
	=?utf-8?b?0LTQu9GPINC+0L3Qu9Cw0LnQvSDRh9Cw0YLQsD8=?=
References: <1422632390.164683257@f338.i.mail.ru>
	<9E516914-9578-47D6-9FD8-F425493A5DD4@gmail.com>
Message-ID: <CANLU1qGO0igwP4LwycWKm1KAdiYhd4A7UJXf7W_SUNrsPGfrUw@mail.gmail.com>

Если надо именно на перле, посмотрите Realplexor.

On Fri Jan 30 2015 at 19:45:34 Denis Fedoseev <denis.fedoseev на gmail.com>
wrote:

> Любая асинхронщина на плаке так может. Вопрос настройки ОС там намного
> интереснее.
>
> Sent from my iPad
>
> > On 30 янв. 2015 г., at 18:39, Максим Владимирович <mmm3 на bk.ru> wrote:
> >
> > Посоветуйте модуль который позволяет держать одновременно сотни тысяч
> долгоживущих открытых HTTP-соединений с сервером. Нужно для онлайн чата.
> Есть какие то готовые варианты?
> >
> >
> > С уважением,
> >
> > Максим
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150130/2e00be5c/attachment.html>

From i.petro.77.00 на gmail.com  Fri Jan 30 13:33:05 2015
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Sat, 31 Jan 2015 00:33:05 +0300
Subject: [Moscow.pm] =?utf-8?b?0KfRgtC+INC/0L7RgdC+0LLQtdGC0YPQtdGC0LUg?=
	=?utf-8?b?0LTQu9GPINC+0L3Qu9Cw0LnQvSDRh9Cw0YLQsD8=?=
In-Reply-To: <1422632390.164683257@f338.i.mail.ru>
References: <1422632390.164683257@f338.i.mail.ru>
Message-ID: <20150130213305.GB17407@vdsl.uvw.ru>

> Посоветуйте модуль который позволяет держать одновременно сотни тысяч
> долгоживущих открытых HTTP-соединений с сервером. Нужно для онлайн чата. Есть
> какие то готовые варианты?

Если говорить о чате и если говорить о переносимости (то есть в
частности о чатике с мобильника), то

1. вебсокеты (по нашей статистике) пока работают дай бог на 25%
мобильных девайсов
2. держать коннекты на мобильниках неодобряе множество мобильных
провайдеров.

поэтому
мы сваяли на тарантуле 1.5 лонгпулинг, который хорошо масштабируется
по нагрузке, персистентный итп.

тарантульная часть - в опенсорсе есть,
а http-сервер который над ним мы в опернсорс не выкладывали, но его
писать в общем минут 20-30.
главное чтобы асинхронник был под рукой какой-то.

From sergey.aleynikov на gmail.com  Fri Jan 30 14:34:36 2015
From: sergey.aleynikov на gmail.com (Sergey Aleynikov)
Date: Sat, 31 Jan 2015 02:34:36 +0400
Subject: [Moscow.pm] =?utf-8?b?0JHQsNCzINCyIEpTT046OlhTPw==?=
In-Reply-To: <69C5B3C1-CA95-4BDA-88E2-D526F67F7954@gmail.com>
References: <CAM4vdXC8wC5LYzyxFJhK_Va1aCYVLBBRtCvcTXBktKZt87UJgw@mail.gmail.com>
	<op.xp1kixywnlncg2@localhost>
	<CAF7QZD7vh7OE3vw7rbY6bG5je9tVoqkaMWWdO4nDwKoBYckCQg@mail.gmail.com>
	<op.xp2s0fxenlncg2@localhost>
	<69C5B3C1-CA95-4BDA-88E2-D526F67F7954@gmail.com>
Message-ID: <CAKNj8S1jx+TLv8+7hnvB73LNMh2vCqyVP8Ab7qAggozE8sKk5g@mail.gmail.com>

Добрый день,

> my $bar1 = Bar->new(
>   foo => $foo1,
> );
>
> my $bar2 = Bar->new(
>   foo => $foo2,
>   bar => $bar1
> );

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

Best regards,
Sergey Aleynikov

From kh.artur на gmail.com  Wed Jan 14 01:46:12 2015
From: kh.artur на gmail.com (Artur Kh)
Date: Wed, 14 Jan 2015 09:46:12 -0000
Subject: [Moscow.pm] =?utf-8?b?0KHQuNC90YLQsNC60YHQuNGH0LXRgdC60LjQuSA=?=
 =?utf-8?b?0LDQvdCw0LvQuNC3INC90LAgUGVybC4g0KLRgNCw0L3RgdC70Y/RgtC+0YAu?=
In-Reply-To: <CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
References: <CAMxGQeQdzjpkTsvBmSCs5vs1oh4N__XKuD8Jpp7hUVgT6--dMA@mail.gmail.com>
	<CAMxGQeQc=xbZv09=qov58RFBqxTRx-9d8QsQAaRfFJ70g4S-MQ@mail.gmail.com>
Message-ID: <etPan.54b63ad5.238e1f29.89aa@Kenobi>

Если я правильно понимаю, то возможно вам нужно что-то вроде этого: https://metacpan.org/pod/Marpa::R2
-- 
ak

From: Харпалёв Иван <ivan.kharpalev на gmail.com>
Reply: Moscow.pm group <moscow-pm на pm.org>>
Date: 14 January 2015 at 11:40:40
To: Moscow.pm group <moscow-pm на pm.org>>
Subject:  Re: [Moscow.pm] Синтаксический анализ на Perl. Транслятор.  

что-то вроде "f(1,2) + 3"  в {function=>'+', args=>[{function=>'f', args=>[1, 2]}, 3]}


14 января 2015 г., 12:34 пользователь Харпалёв Иван <ivan.kharpalev на gmail.com> написал:
Доброго времени, могучий MoscowPM!

Сейчас пишу небольшой язык.
То есть пишу транслятор из него в awk и С. (Сначала в awk, чтобы потренироваться, а потом в C, там типизация, там сложнее). 

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

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

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

--  
Moscow.pm mailing list
moscow-pm на pm.org | http://moscow.pm.org
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150114/461fef75/attachment-0001.html>

From gnatyna на yandex.ru  Mon Jan 19 04:52:32 2015
From: gnatyna на yandex.ru (Alexander Gnatyna)
Date: Mon, 19 Jan 2015 12:52:32 -0000
Subject: [Moscow.pm] =?utf-8?b?TERBUCwg0LAg0YHRgtC+0LjRgiDQu9C4INC+0LI=?=
	=?utf-8?b?0YfQuNC90LrQsCDQstGL0LTQtdC70LrQuD8=?=
In-Reply-To: <CALE3dTXfGhj7GR2gQ+otPu2CNBuaUeGCHa9Ur=o4ZQt34ipfBQ@mail.gmail.com>
References: <20150106174216.GK31138@vdsl.uvw.ru>
	<CALE3dTXfGhj7GR2gQ+otPu2CNBuaUeGCHa9Ur=o4ZQt34ipfBQ@mail.gmail.com>
Message-ID: <3387166.ufDjln6viN@localhost.localdomain>

Пользуем ldap для авторизации в redmine пользователей из CGPro, плюс 
авторизация на vpn тоже через ldap от CGPro. 
Групп нет, только авторизация.
Вообще вроде удобно, но потребовало чтения мануала и изучения логов, чтобы 
понять что делается не так.


В письме от 9 января 2015 01:05:03 пользователь Denis Fedoseev написал:
> У нас LDAP используется только для авторизации под доменной учеткой.
> 
> Если этого не требуется - то я бы заюзал какой-нибудь CAS и там все держал.
> 
> 6 января 2015 г., 20:42 пользователь Ivan Petrov <i.petro.77.00 на gmail.com>
> написал:
> 
> 
> > у нас вебпроект который сейчас включает в себя уже около 4
> > самостоятельных подпроектов, намечается еще несколько подпроектов.
> >
> >
> >
> > и вот мы между подпроектами испытываем необходимость в синхронизации
> > таблиц пользователей, групп, итп.
> >
> >
> >
> > соответственно что сделано сейчас:
> >
> >
> >
> > 1. сейчас все пользователи заводятся на одном проекте
> > 2. при каждом изменении профиля пользователя (или его появлении)
> > кладется таск в очередь и профиль воркером реплицируется в другие
> > проекты
> >
> >
> >
> >
> > далее поскольку у нас намечаются еще подпроекты, то стали задумываться
> > о какой-то единой централизованной системе-хранилище пользователей и
> > настроек.
> >
> >
> >
> > и вроде бы LDAP специально для этого предназначен.
> >
> >
> >
> > однако смотрю я на этот LDAP уже более внимательно, тесты какие-то
> > делаю и пока не могу точно определиться, а стоит ли овчинка выделки
> > или нет?
> >
> >
> >
> > 1. пользователи (objectClass), предопределенные в LDAP нам не подойдут
> > полностью, все равно придется свои атрибуты им делать. а ближе
> > посмотришь, так и лучше, вероятно, полностью с нуля objectClass
> > описывать (иначе там будет куча лишнего мусора)
> > 2. описание своих сущностей в LDAP оч геморное, плюс на OID надо пусть
> > и бесплатное но разрешение получать
> > 3. асинхронных коннекторов к LDAP я не нашел
> >
> >
> >
> > с другой стороны профитом может быть какая-нибудь скажем авторизация в
> > чем-нибудь. итп
> >
> >
> >
> >
> > кто использует LDAP в вебпроектах, расскажите что вы об этом думаете?
> >
> >
> >
> > я вот думаю, если сложить юзеров в (скажем) новый тарантул, то с его
> > бидирект репликацией он пожалуй может быть поудобнее LDAP потому что
> > бидирект, а не мастер-слейв.
> > плюс изменять (при необходимости) профили можно будет значительно
> > чаще, нежели в LDAP'е (вроде пока такой необходимости не
> > просматривается, но все же)
> >
> >
> >
> > в общем смотрю на LDAP и думаю.
> > толи это нужная штука, толи жутко навороченное бесполезное что-то.
> >
> >
> >
> > кто что думает?
> >
> >
> >
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> >
> >
> 
> 
> 
> 
> -- 
> С уважением, Денис Федосеев

From iskhartakh на gmail.com  Fri Jan 23 02:13:46 2015
From: iskhartakh на gmail.com (Anatoly Y.)
Date: Fri, 23 Jan 2015 10:13:46 -0000
Subject: [Moscow.pm] =?utf-8?b?0JzQvtC00YPQu9C4INC00LvRjyDQvtGH0LXRgNC1?=
	=?utf-8?b?0LTQuCDQt9Cw0LTQsNGHIC8g0YHQvtC+0LHRidC10L3QuNC5?=
In-Reply-To: <CANLU1qECQi1aLehygMHjNywV_dwzLmvPKTAvkfJ3kEEwxw_sOQ@mail.gmail.com>
References: <CANh0x-xNfRSmRt_5PoB7QyZHVZOfOWgdRPmAKf_S4DeYGQ_arQ@mail.gmail.com>	<CAMgEUEDp5r+5ASdJnXN2WH4iiKai9y0XjMJJNMfm2GjxbaiWkA@mail.gmail.com>	<CAJxdCZ4D0kwMig6tqq4iEsuxgJgY8YVKwHAYp8M+jn3KWY1o0Q@mail.gmail.com>	<CAMgEUECJPGNz=7pTmYz7NTef9HVNrHquA5zLhos1pxw5uEA6fw@mail.gmail.com>
	<CANLU1qECQi1aLehygMHjNywV_dwzLmvPKTAvkfJ3kEEwxw_sOQ@mail.gmail.com>
Message-ID: <02aa01d036f5$329e7fc0$97db7f40$@gmail.com>

Присоединяюсь к вопросу. И обязательно сюда кидайте ссылки на архивы материалов прошедших ивентов.

А то вроде уже много чего прошло и обещали записывать, а что-то не видать. Вроде внимательно следил :)

 

From: Moscow-pm [mailto:moscow-pm-bounces+snelius=tsu.ru на pm.org] On Behalf Of Alexander Lourier
Sent: Friday, January 23, 2015 3:50 PM
To: Moscow.pm group
Subject: Re: [Moscow.pm] Модули для очереди задач / сообщений

 

А запись будет?

 

On Fri Jan 23 2015 at 10:46:37 AM Иван Соколов <vaneska.ru на gmail.com <mailto:vaneska.ru на gmail.com> > wrote:

Привет, Паша.

Расскажу.

 

23 января 2015 г., 11:41 пользователь Павел Щербинин <dzirtik на gmail.com <mailto:dzirtik на gmail.com> > написал:

 

Привет, Вань. 5 февраля Moscow.pm может расскажете о своей очереди?))

23 янв. 2015 г. 8:04 пользователь "Иван Соколов" <vaneska.ru на gmail.com <mailto:vaneska.ru на gmail.com> > написал:

 

Привет.

Мы свою написали на редисе. 

За неимением для Perl хороших решений и особых требований от нас к очереди.

 

22 января 2015 г., 23:07 пользователь Ilya Chesnokov <chesnokov.ilya на gmail.com <mailto:chesnokov.ilya на gmail.com> > написал:

Всем привет.

А какие есть удобные Perl-модули для организации очереди задач?
Желательно с возможностью выбора бэкенда для хранения данных очередей
и задач.

Есть ли модули, которые в качестве бэкенда используют RabbitMQ?

Нужно по работе написать что-то подобное, но хочу для начала
промониторить существующие решения.

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

Спасибо.
--
Best regards,
Ilya Chesnokov
--
Moscow.pm mailing list
moscow-pm на pm.org <mailto:moscow-pm на pm.org>  | http://moscow.pm.org




-- 

С уважением,
Иван


--
Moscow.pm mailing list
moscow-pm на pm.org <mailto:moscow-pm на pm.org>  | http://moscow.pm.org


--
Moscow.pm mailing list
moscow-pm на pm.org <mailto:moscow-pm на pm.org>  | http://moscow.pm.org




-- 

С уважением,
Иван

--
Moscow.pm mailing list
moscow-pm на pm.org <mailto:moscow-pm на pm.org>  | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150123/630bf125/attachment-0001.html>

From pavel на kuptsov.info  Mon Jan 26 04:59:31 2015
From: pavel на kuptsov.info (=?UTF-8?B?0J/QsNCy0LXQuyDQmtGD0L/RhtC+0LI=?=)
Date: Mon, 26 Jan 2015 12:59:31 -0000
Subject: [Moscow.pm] =?utf-8?b?0JjRidC10Lwg0J/QtdC70L7QstC40LrQvtCyLiAo?=
	=?utf-8?q?Warstone=40list=2Eru=29?=
Message-ID: <CAPcuxSYtsQpyLXnuFUvBSap43=tomY7MX-TXdf_OSgTf3ROSmw@mail.gmail.com>

Для тех кто ищет работу - вот недавно предлагали такой вариант:

*Обязанности:*

   - Разработка и поддержка программного обеспечения.


*Требования:*

   - Мы работаем с FreeBSD (на серверах), modern perl, Mojolicious, Redis,
   Elasticsearch, git и некоторыми функциональными языками программирования.
   - Простое перечисление навыков и акронимов которые есть или которые
   нужны это не самое главное. Мы ценим профессиональных и опытных в своей
   области работы людей. Но мы также считаем что мотивация, желание работать и
   интеллект являются приоритетными и необходимыми качествами.
   - Мы ищем мотивированных сотрудников, которые способны общаться, думать
   и работать в команде.
   - Разговорный aнглийский язык.

*Условия:*

   - Полный рабочий день в нашем офисе в Монтевидео (Уругвай).
   - Хорошая заработная плата, помощь с имиграционными вопросами переездом
   и адаптацией.
   - Для начала мы предложим трёхмесячный контракт с последующей
   возможностью перехода на постоянную работу.

http://hh.ru/vacancy/12572494


--
Павел

26 января 2015 г., 15:28 пользователь <moscow-pm-request на pm.org> написал:

> Сообщения, предназначенные для списка рассылки Moscow-pm, необходимо
> отправлять по адресу
>         moscow-pm на pm.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
>         http://mail.pm.org/mailman/listinfo/moscow-pm
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
>         moscow-pm-request на pm.org
>
> Адрес человека, ответственного за этот список рассылки:
>         moscow-pm-owner на pm.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> Moscow-pm..."
>
>
> В этом номере:
>
>    1. Re: Модули для очереди задач / сообщений (Sergey Leschenko)
>    2. Re: Модули для очереди задач / сообщений (Victor Efimov)
>    3. Ищем Пеловиков. (Warstone на list.ru)
>    4. Re: Модули для очереди задач / сообщений (Ilya Chesnokov)
>    5. Re: Модули для очереди задач / сообщений (Alexander Lourier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Jan 2015 13:48:04 +0200
> From: Sergey Leschenko <sergle.ua на gmail.com>
> To: "Moscow.pm group" <moscow-pm на pm.org>
> Subject: Re: [Moscow.pm] Модули для очереди задач / сообщений
> Message-ID:
>         <CAJoOBmzm7zUoNSWiD-9WW4DU4i1a=
> xvvp6Ps5wxMBaLkgDtD2Q на mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> > Насколько я помню, в букинге почему-то не любят ZeroMQ?
> > Не в курсе случаем, какие там проблемы с ним?
>
> Пытался на YAPC::EU'2013 это узнать, мне ответили что слишком сложно в
> случае когда нужно реализовать все с обработкой ошибок, таймаутов и
> т.д.
> Еще у них 2я версия использовалась (тогда).
>
>
> 2015-01-23 15:37 GMT+02:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> > 23 января 2015 г., 11:39 пользователь Maxim Vuets
> > <maxim.vuets на gmail.com> написал:
> >> 2015-01-22 21:07 GMT+01:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> >>> А какие есть удобные Perl-модули для организации очереди задач?
> >>> Желательно с возможностью выбора бэкенда для хранения данных очередей
> >>> и задач.
> >>
> >> Мы написали и пользуемся вот этим:
> >> https://metacpan.org/pod/Queue::Q::ReliableFIFO::Redis
> >> Но там только Редис в качестве бекенда.
> >
> > Насколько я помню, в букинге почему-то не любят ZeroMQ?
> > Не в курсе случаем, какие там проблемы с ним?
> >
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >
> >
> >
> > --
> > Best regards,
> > Ilya Chesnokov
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Sergey
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Jan 2015 16:00:00 +0400
> From: Victor Efimov <victor на vsespb.ru>
> To: "Moscow.pm group" <moscow-pm на pm.org>
> Subject: Re: [Moscow.pm] Модули для очереди задач / сообщений
> Message-ID:
>         <CAF7QZD7Abq3spVRRSNmqqSiEkdu7F+pdZEjm5k3NyR7g_L=
> Mpg на mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Для Ruby on Rails две последние самые популярные очереди - Resqueue и
> Sidekiq - на базе Redis сделаны.
>
> 26 января 2015 г., 14:48 пользователь Sergey Leschenko
> <sergle.ua на gmail.com> написал:
> >> Насколько я помню, в букинге почему-то не любят ZeroMQ?
> >> Не в курсе случаем, какие там проблемы с ним?
> >
> > Пытался на YAPC::EU'2013 это узнать, мне ответили что слишком сложно в
> > случае когда нужно реализовать все с обработкой ошибок, таймаутов и
> > т.д.
> > Еще у них 2я версия использовалась (тогда).
> >
> >
> > 2015-01-23 15:37 GMT+02:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> >> 23 января 2015 г., 11:39 пользователь Maxim Vuets
> >> <maxim.vuets на gmail.com> написал:
> >>> 2015-01-22 21:07 GMT+01:00 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> >>>> А какие есть удобные Perl-модули для организации очереди задач?
> >>>> Желательно с возможностью выбора бэкенда для хранения данных очередей
> >>>> и задач.
> >>>
> >>> Мы написали и пользуемся вот этим:
> >>> https://metacpan.org/pod/Queue::Q::ReliableFIFO::Redis
> >>> Но там только Редис в качестве бекенда.
> >>
> >> Насколько я помню, в букинге почему-то не любят ZeroMQ?
> >> Не в курсе случаем, какие там проблемы с ним?
> >>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Ilya Chesnokov
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >
> >
> >
> > --
> > Sergey
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Jan 2015 15:02:06 +0300
> From: Warstone на list.ru <warstone на list.ru>
> To: Moscow.pm group <moscow-pm на pm.org>
> Subject: [Moscow.pm] Ищем Пеловиков.
> Message-ID: <1422273726.705343837 на f309.i.mail.ru>
> Content-Type: text/plain; charset="utf-8"
>
>
> Раз комбатсы начали, надо продолжить... На этот раз мы ищем Perl'овиков.
>
> В игровую компанию нужны Perl-спецы высшего уровня.
>   Требования:
> *  Виртуозное знание Perl
>   Желательно:
> *  Опыт работы со следующими технологиями: Catalyst, DBIx::Class, Moose,
> PostgreSQL
> *  Опыт построения высоконагруженных серверов (TCP, RPC, load-balancing,
> HTTP)
> *  Понимание производительности кода Perl (perl -MO=Concise,-exec,
> NYT::Prof и т.д.)
> *  Опыт написания и оптимизации SQL запросов (EXPLAIN ANALYZE и т.д.)
>   С чем предстоит работать:
> *  Серверная часть социальных игр.
> *  Самописный фреймворк для общения с клиентом через TCP посредствам JSON.
> *  Поддержка существующих (сначала поддержка и знакомство с технологиями,
> конечно) и разработка новых игр.
> Условия:
> *  холодильник с едой и напитками, кофе-машина, консоль, пинг-понг
> *  бесплатное обучение английскому языку в офисе (разные уровни, native
> speaker)
> *  адекватная вашему уровню з/п (больших цифр не боимся, если вы реально
> сильны), ежеквартальный пересмотр з/п
> *  предельный гуманизм в управлении (по своей воле от нас почти никто не
> уходит)
> *  50% компенсация ДМС
> *  50% компенсация абонемента в фитнес-клуб
> *  полный рабочий день (гибкий график работы), удаленка не годится
> http://hh.ru/vacancy/11997386
>
> Как-то так... Есть есть вопросы о работе, о людях и прочее, то я готов на
> них ответить.
> ----------- следущая часть -----------
> Вложение в формате HTML было извлечено&hellip;
> URL: <
> http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/52b5cdb3/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 Jan 2015 16:19:51 +0400
> From: Ilya Chesnokov <chesnokov.ilya на gmail.com>
> To: "Moscow.pm group" <moscow-pm на pm.org>
> Subject: Re: [Moscow.pm] Модули для очереди задач / сообщений
> Message-ID:
>         <
> CANh0x-yA5PPHeu9RaYfROw2VMXJwOA-i5mmFSn31GQuJ1xC2-Q на mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 26 января 2015 г., 15:00 пользователь Victor Efimov <victor на vsespb.ru>
> написал:
> > Для Ruby on Rails две последние самые популярные очереди - Resqueue и
> > Sidekiq - на базе Redis сделаны.
>
> Да уж, что для Perl-программиста - модуль на CPAN, то для
> Ruby-программиста - стартап.
>
> --
> Best regards,
> Ilya Chesnokov
>
> ------------------------------
>
> Message: 5
> Date: Mon, 26 Jan 2015 12:28:38 +0000
> From: Alexander Lourier <aml на rulezz.ru>
> To: "Moscow.pm group" <moscow-pm на pm.org>
> Subject: Re: [Moscow.pm] Модули для очереди задач / сообщений
> Message-ID:
>         <
> CANLU1qHbLQ3JbH8Yo2Q0Nvx5i8jCs0vAsEarJJOk4TqPbQn7Jg на mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Что мне не нравится в ZeroMQ - это надо точно знать IP ноды, которая делает
> bind(), а все потом к ней connect(). И не дай бог, с этой центральной нодой
> что-то случится. Фейловера нет.
>
> On Mon Jan 26 2015 at 1:20:13 PM Ilya Chesnokov <chesnokov.ilya на gmail.com>
> wrote:
>
> > 26 января 2015 г., 15:00 пользователь Victor Efimov <victor на vsespb.ru>
> > написал:
> > > Для Ruby on Rails две последние самые популярные очереди - Resqueue и
> > > Sidekiq - на базе Redis сделаны.
> >
> > Да уж, что для Perl-программиста - модуль на CPAN, то для
> > Ruby-программиста - стартап.
> >
> > --
> > Best regards,
> > Ilya Chesnokov
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> >
> ----------- следущая часть -----------
> Вложение в формате HTML было извлечено&hellip;
> URL: <
> http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/07ea6002/attachment.html
> >
>
> ------------------------------
>
> Subject: Нижний колонтитул дайджеста
>
> _______________________________________________
> Moscow-pm mailing list
> Moscow-pm на pm.org
> http://mail.pm.org/mailman/listinfo/moscow-pm
>
>
> ------------------------------
>
> Конец Дайджест списка рассылки Moscow-pm; том 87, выпуск 36
> ***********************************************************
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150126/bfb14ed3/attachment-0001.html>