Exception #09 ищутся докладчики
Иван Пирог
Иван Пирог
Уважаемые коллеги!29 сентября 2008 года состоится девятый всепитонистский семинар Exception #09.
Mkdir
Кожевин?
Дима, что скажешь? Если у нас будет два доклада сугубо по Python и
один в твоём стиле, думаю все были бы очень довольны =)
Alexander Solovyov
> ATTENTION! Ищутся докладчики. Кто желает проявить себя?
ДОУ? Если интересно послушать, то порассказывать мне таки
интересно. :)
--
Alexander
slav0nic
надеюсь видео я посмотрю В)
интересно
- django 1.0, какая-нибудь жирная апликуха на джанге, например satchmo
или ещё что-то (правда хз что про них рассказывать%))
- python success story
- чего-нить про асинхронную обработку событий
- Parallel Python и тп про распараллеливание задач
- распределение нагрузки в веб приложениях и тп на тему "highload"
- про гуи чё нить, например "аспекты MVC в wxPython" или чего-то из
этой серии)
- game dev
- pyrex
- pypy
- использование генераторов
- python в администрировании
- cherrypy и тп вещи альтернативные фреймворкам (достоинства и
недостатки)
- защита сорцев/использование питона в shareware софте
- twisted тож можно
- unitest, debug и тп
- работа в команде, VCS бла бла (можно и не сильно про питон В) )
да, я много чего хочу))
зы: на конфе врядли буду :) поэтому хочу видео ...
Vsevolod Solovyov
> Уважаемые коллеги!
> 29 сентября 2008 года состоится девятый всепитонистский семинар Exception
> #09.
--
Vsevolod Solovyov
Иван Пирог
Андрей Светлов
именно про то, как у нас все организовано.
Другие темы тоже интересны, но стройного доклада по ним пока не вижу.
А по этим двум - можно.
Иван, если я буду - извести как можно скорее. По опыту знаю, пару
недель нужно ходить с практически готовой темой, обкатывая ее в
голове. Иначе получается не очень хорошо.
Сегрей Щетинин, так будет ли доклад о trellis? Мне очень интересно...
Vsevolod Solovyov
>> Судя по календарю - скорее-таки 27-го. Потому что 29 сентября -
>> понедельник.
> Запоздалый коммент по поводу 29-го. Чуть выше я уже исправился :)
Ага, если зайти через groups.google.com, то исправление есть, а на
почту мне не приехало.
> ЗЫ: Кстати, вот лично ты какие темы хотел бы услышать?
Да каких-то особенных предпочтений нет. Хотя про треллис было бы
интересно послушать. А про Джангу не очень - чисто по той причине, что
я и так про неё "всё" знаю ;)
--
Vsevolod Solovyov
Dmitry Kozhevin
Да каких-то особенных предпочтений нет. Хотя про треллис было бы
Про треллис? А что это такое?
Dmitry Kozhevin
Александр Локшин
качественным эксепшеном по просторам питона :-)
(наверняка с ним уже кто-то "игрался")... Если верить сайту python.org
- релиз будет в октябре этого года.
Кроме того интересно было бы послушать про Bazaar VS Mercurial VS Git
Ivan Fedorov
только не писать кусок кода на C/C++...
Andrii V. Mishkovskyi
>
>
> надеюсь видео я посмотрю В)
>
> интересно
> - python success story
Это уже не интересная тема, по-моему.
> - чего-нить про асинхронную обработку событий
> - Parallel Python и тп про распараллеливание задач
Я тебе могу на pyth...@c.j.r рассказать про multiprocessing и asyncore. :)
[skipped]
> - использование генераторов
PEP-342 перевести, что ли?
[skipped]
> - защита сорцев/использование питона в shareware софте
boost.python :)
[skipped]
Список однако, неслабенький. Тут на несколько конференций можно растянуть. :)
>
> да, я много чего хочу))
> зы: на конфе врядли буду :) поэтому хочу видео ...
>
> >
>
--
Wbr, Andrii Mishkovskyi.
He's got a heart of a little child, and he keeps it in a jar on his desk.
andrey dmitrenko
python 3.0, наверное, не очень интересно. Я думаю, гораздо интереснее
было бы послушать о python 2.6 - промежуточный релиз, ну и более
близок к реальности, как мне кажется. Ну или о будущем вообще.
Вообще можно посвятить ексепшн django 1.0 - релиз все-таки. Может быть
даже еще раз пригласить светоча джанго - Ивана Сагалаева :)
Ну и мне как ДБА было бы интересно послушать о python versus
databases: всяческие ORM, нативные бд, сравнения и т.д. Сам я только
попробовал SQLAlchemy, и немного работаю с cx_Oracle, sqlite3...
Хотелось бы про twisted, но это уже было на одном из прошлых
семинаров, а я пропустил :(
Вот.
Андрей.
Сергей
По Trellis могу рассказать много интересного, только не понял будет ли
мастер-класс или всё-таки доклад? Ну и тема обширная, я вот недавно
вдруг обнаружил что и для асинхронной обрабоки там есть задел (с
генераторами) =) удивительно. Т.е. если будет решено что докладу или м-
классу быть, то нужно еще выяснить что рассказывать а что опустить.
Приблизительно я понимаю что будет интересней, но нужно
удостовериться.
По темам голосую против python *.*, django, mg. Темы по-моему уже
обсосаны дальше некуда.
Высокие нагрузки, масштабируемость, тестирование, отладка, работа в
команде аналогично, но что-нибудь короткое вроде последнего доклада на
Exc#08 может быть и интересно.
Про PyPy, если кто-то лазил глубоко, то я за такой доклад всеми руками
и ногами.
> про гуи чё нить, например "аспекты MVC в wxPython" или чего-то из этой серии)
основ.
> cherrypy и тп вещи альтернативные фреймворкам (достоинства и недостатки)
в т.ч. еще не написаных? Заодно на вопросы ответить было бы удобней.
Ну или если кто еще такое практикует, тоже интересно какой баланс
нашли.
Alex Koshelev
Если вы не против, то я хотел бы приехать опять и что-нибудь про
джангу рассказать На этот раз не так скучно и поверхностно:)
Тут многие уже про джангу 1.0 упоминали. По большому счету на большой
доклад эта тема не катит. Можно рассказать про то что в релизной
джанге есть, а чего до сих пор нет. Но это минут на 15-20 от силы -
эдакая врезочка между докладами. Такой обзор для ленивых и кто просто
не следит за развитием джанги.
Но у меня есть ещё одна идея для доклада - оптимизация приложений.
Т.е. именно какие-то способы, советы, трюки по улучшению
быстродействия. Среди них:
- Выбор сервера метода деплоя проектов.
- Архитектура. Дробление функционал на приложения и когда это плохо.
С кодом.
- Правильные запросы через ORM. Тут тоже с кодом. Рассказать и
показать про extra, select_related
- Разумная денормализация. Обновление значений по сигналам.
- Техники кеширования(тоже много кода):
- по таймауту
- по сигналам. Тут у меня своя наработка есть
- пачками по сигналам. Тут тоже интересный опыт есть
- Механизмы убер-кеширования - на стороне веб-сервера и гибридные
варианты.
Одно но - в лимит 45 мин. реально не уложиться.
Что думаете? Будет интересно?
Sergey Schetinin
> С кодом.
А можно про этот пункт хоть очень коротко но сейчас? Интересно.
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter
andrey dmitrenko
2008/9/4 Alex Koshelev <daev...@gmail.com>:
> Привет, питонисты!
>
> ...
Сергей
думал речь про SOA.
Mkdir
On 4 сент, 11:00, Сергей <mal...@gmail.com> wrote:
> Привет всем!
> По Trellis могу рассказать много интересного, только не понял будет ли
> мастер-класс или всё-таки доклад?
привычке написал.
Так что, никаких ограничений аля только доклад или только мастер-класс
нет.
Я бы поддержал тему Trellis, по-моему очень интересно.
Предложение от Alex Koshelev по оптимизации приложений тоже интересно
(как по мне).
Насколько я помню по седьмому эксепшену, докладчик он хороший, просто
готовился в спешке, наверное :)
Алекс, сможешь сделать мастер-класс по оптимизации? Кто "за"? Есть
вообще желающие послушать мастер-класс по оптимизации приложений?
Андрею Светлову респект за инициативность! На каждый семинар он готов
предложить по 3-4 темы :-)
Nikolai Zamkovoi
интересненького.
<skipped>
Dmitry Kozhevin
использовал технику "программирования плашмя"
так что мини-какбы-доклад "как добиваться успехов лежа на диване" есть
:)
Андрей Светлов
процесса и свой импортер модулей.
On Sep 4, 12:29 am, Ivan Fedorov <ivan.fedo...@gmail.com> wrote:
Иван Пирог
недавно сделал за полторы недели то на что другие программеры просили полгода ;)
использовал технику "программирования плашмя"
так что мини-какбы-доклад "как добиваться успехов лежа на диване" есть
:)
О, это супер! =)
В ходе разговора с Димой, дополнительно решили провести параллельное обсуждение тем в интерактивном формате Open Space (спасибо Алексею Кривицкому за показательный пример!). Этот формат позволит нам параллельно обсуждать такие темы как Django 1.0, Mercurial, впечатления людей о бете Python 3.0, поговорить об ORM, об оптимизации Django-приложений, etc.
Open Space будет делиться на 4 спейса, в каждом из которых обсуждается одна тема. Кому интересно послушать о Django 1.0, тот присоеденится к соответствующему спейсу. Интересующиеся практическим опытом работы с Python 3.0 beta смогут обсудить его в своём спейсе и т.д.
Каждый спейс имеет своего ведущего. Это может быть человек, который хочет рассказать о своём опыте в определённой сфере или же, наоборот, ищущий ответы на свои вопросы. Ведущий задаёт тему опенспейса и делает небольшое вступление, затем происходит обсуждение данной темы с участниками в течении определённого времени.
Должно быть интересно... :)
Подведя итоги, у нас может получиться примерно такой набросок программы:
1. Мастер-класс (о Trellis? Сергей, выступишь?)
2. Кофе-брейк
3. Доклад Димы Кожевина о прокачивании скилов до "диванного уровня" (или как-то так)
4. Снова кофе-брейк
5. Open Space - 4 спейса, в каждом можно обсудить по 2 темы, итого 8 тем
Что скажете?
Vsevolod Solovyov
> Подведя итоги, у нас может получиться примерно такой набросок программы:
> 1. Мастер-класс (о Trellis? Сергей, выступишь?)
> 2. Кофе-брейк
> 3. Доклад Димы Кожевина о прокачивании скилов до "диванного уровня" (или
> как-то так)
> 4. Снова кофе-брейк
> 5. Open Space - 4 спейса, в каждом можно обсудить по 2 темы, итого 8 тем
> Что скажете?
Отлично! :-)
--
Vsevolod Solovyov
Иван Пирог
On Sep 4, 12:29 am, Ivan Fedorov <ivan.fedo...@gmail.com> wrote:
> slav0nic <slav0n...@gmail.com> writes:
>
> > интересно
> > - защита сорцев/использование питона в shareware софте
>
> IMHO на основе стандартного интерпретатора защита невозможна. Ну если
> только не писать кусок кода на C/C++...
Кусок очень маленький и простой. Нужен свой запускач питоновского
процесса и свой импортер модулей.
Sergey Schetinin
Ну да, а чё =)
На выходных набросаю в общих чертах что такое треллис, во что там
можно углубиться, чему именно собираюсь уделить внимание и закину
сюда. По отзывам, если нужно будет, скорректирую. На сколько времени
рассчитывать?
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
Alex Koshelev
Идея с опенспейсами интересная, но мне кажется очень трудно в таком интерактивном режиме оставаться в теме. Начнутся вопросы по смежным областям и разговор превратиться кулуарную беседу. Или может быть я не очень хорошо себе представляю процесс.
Иван Пирог
> 1. Мастер-класс (о Trellis? Сергей, выступишь?)Ну да, а чё =)
На выходных набросаю в общих чертах что такое треллис, во что там
можно углубиться, чему именно собираюсь уделить внимание и закину
сюда. По отзывам, если нужно будет, скорректирую. На сколько времени
рассчитывать?
Nikolai Zamkovoi
зависит от ведущего. Кто-нибудь уже проводил openspac'ы\учился их
проводить? А то может получится каша.
Если проводил, то ок, я за опенспейс. Trellis тоже кажется
многообещающим. Диванные скилы - заинтриговали %)
Иван Пирог пишет:
<skipped>
Vsevolod Solovyov
> Идея с опенспейсами интересная, но мне кажется очень трудно в таком
> интерактивном режиме оставаться в теме. Начнутся вопросы по смежным областям
> и разговор превратиться кулуарную беседу. Или может быть я не очень хорошо
> себе представляю процесс.
Ну будет же главный Опенспейса. Ему дадут дубинку, и он будет
охаживать ею отклоняющихся от темы :D
--
Vsevolod Solovyov
Alex Koshelev
Тогда при входе надо всем вместе с бейджами выдавать каски;)
Иван Пирог
Идея с опенспейсами интересная, но мне кажется очень трудно в таком интерактивном режиме оставаться в теме. Начнутся вопросы по смежным областям и разговор превратиться кулуарную беседу.
Sergey Schetinin
> Нормально будет?
Да, думаю в самый раз.
Про диванный уровень интересно =)
Про опенспейс, никогда не видел и не учавствовал, но вот такая мысль
возникла. Можно ли чтобы ведущие сначала за минуты 3 по очереди
рассказали свою тему, чтобы было яснее к кому кучковаться?
С другой стороны всё равно темы будут разные и скорей всего будет
сразу ясно что интересно и что нет. В общем какой в этой теме
передовой опыт?
Еще помню давно разговоры шли про lightning talks на екзепшне. Не в этот раз?
Alex Koshelev
Dmitry Kozhevin
Идея с опенспейсами интересная, но мне кажется очень трудно в таком интерактивном режиме оставаться в теме. Начнутся вопросы по смежным областям и разговор превратиться кулуарную беседу. Или может быть я не очень хорошо себе представляю процесс.
Dmitry Kozhevin
Второе правило опенспейса - правило ног - идешь туда куда тебе нравится ;)
Alexander Solovyov
> В общем и целом, давайте вместе обсудим возможные темы и яростно грянем
> качественным эксепшеном по просторам питона :-)
Про треллис - реально интересно, про джангу, если честно, не очень. :D
А то тема про джангу есть почти на каждом эксепшене (на трёх последних
была), и надо кагбе и другим темам дать волю.
--
Alexander
Dmitry Kozhevin
Алексея, предлагаю себя в том же качестве на эксепшене.
И так как мой "доклад" традиционно расчитан на 20 минут думаю его
совместить со вступительной речью перед опенспейсом и второй кофе
брейк сделать перманентным в течение всего опенспейса. Ваня, это
возможно? Что скажете, соратники?
> 1. Мастер-класс (о Trellis? Сергей, выступишь?)
>
> 2. Кофе-брейк
>
> 3. Доклад Димы Кожевина о прокачивании скилов до "диванного уровня" (или
> как-то так)
>
> 4. Снова кофе-брейк
>
> 5. Open Space - 4 спейса, в каждом можно обсудить по 2 темы, итого 8 тем
>
Sergey Schetinin
2008/9/4 Dmitry Kozhevin <dmitrik...@gmail.com>:
--
Иван Пирог
Ну отлично, только тогда еще докладов добавить бы.
2008/9/4 Dmitry Kozhevin <dmitrik...@gmail.com>:
> В связи с тем что я был фасцилитатором (ведущим) на опенспейсе у
> Алексея, предлагаю себя в том же качестве на эксепшене.
> И так как мой "доклад" традиционно расчитан на 20 минут думаю его
> совместить со вступительной речью перед опенспейсом и второй кофе
> брейк сделать перманентным в течение всего опенспейса. Ваня, это
> возможно? Что скажете, соратники?
--
Alexander Solovyov
> 1. Мастер-класс (о Trellis? Сергей, выступишь?)
> 2. Кофе-брейк
> 3. Доклад Димы Кожевина о прокачивании скилов до "диванного уровня" (или
> как-то так)
> 4. Снова кофе-брейк
> 5. Open Space - 4 спейса, в каждом можно обсудить по 2 темы, итого 8 тем
>
> Что скажете?
--
Саня
Vsevolod Solovyov
> Про треллис - реально интересно, про джангу, если честно, не очень. :D
> А то тема про джангу есть почти на каждом эксепшене (на трёх последних
> была), и надо кагбе и другим темам дать волю.
Ну, если про джангу будет одна из восьми тем на опенспейсе, то
нормально. Всё равно не удержатся, чтоб не поговорить :)
--
Vsevolod Solovyov
Андрей Светлов
Лично мне она не очень-то интересна, но существует армия
поклонников...
On Sep 4, 7:28 pm, "Vsevolod Solovyov" <vsevolod.solov...@gmail.com>
wrote:
> 2008/9/4 Alexander Solovyov <alexander.solov...@gmail.com>:
Андрей Светлов
1. Мастер-класс Сергея о Trellis
3. Доклад Димы Кожевина о прокачивании скилов до "диванного
уровня" (или как-то так)
"ведущих". Да, и хорошо бы большие плакаты - "здесь говорят о том-то".
Чтобы недостатки "организационной" части не превратили хорошее
начинаение в непонятно что.
Сам такого зверя не видел ни разу, может опытные товарищи что
посоветуют...
В свою очередь готов попробовать. Мне очень интересно поделиться
"организацией техпроцесса".
Сейчас работаю над довольно большим проектом (несколько десятков
разработчиков, десяток-другой тестеров, админы, аналитики, прочие.
Всех - за сотню переваливает). Большое количество подпроектов и
направлений, частично связанных между собой. Релизы и патчи. Миграция
схемы базы данных (немаловажная часть). Автоматические unit-tests и
regression-test, а еще есть dev-acceptance.
Под это все пришлось создать свою инфраструктуру. Могу рассказать о
том, как все это работает у нас. И какие средства пришлось написать.
До этого таких масштабов не было, и большая часть проблем была скрыта
за горизонтом.
По моему - как раз тема для поговорить, поделиться опытом и
поспрашивать других - вдруг что интересное и полезное расскажут.
Защита кода, написанного на питоне, от копирования и заимстования
исходников - куда менее интересная вещь (но и у нас начались подобные
разговоры - отложили в папку "до востребования")
Alex Koshelev
Кажется, остановились на
1. Мастер-класс Сергея о Trellis
2. Кофе-брейк4. Снова кофе-брейк, плавно переходящий в Open Space - 4 спейса, в
3. Доклад Димы Кожевина о прокачивании скилов до "диванного
уровня" (или как-то так)
каждом можно обсудить по 2 темы, итого 8 темOpen Space остался открытым. Кажется, нужно заранее выделить темы и
"ведущих". Да, и хорошо бы большие плакаты - "здесь говорят о том-то".
Чтобы недостатки "организационной" части не превратили хорошее
начинаение в непонятно что.
Сам такого зверя не видел ни разу, может опытные товарищи что
посоветуют...
Получается, что есть какой-то гуру-ведущий, вокруг которого топчется народ, он что-то вещает, отвечает на вопросы. Как это регламентировать не понимаю. Ведь разговоры в компании заинтересованных людей могут длиться очень долго, перетекая из темы в тему - не затыкать же рты, отбиваясь от "вне-темных" вопросов в конце концов:)
Dmitry Kozhevin
какое время какой вопрос обсуждается.
Каждая зона организуется вокруг флип-чарта.
Кто-то сидит, кто-то стоит, кто-то переходит из зоны в зону.
Ведущий не обязательно гуру, просто заинтересованое лицо.
Мы все достаточно сознательные товарищи чтобы говорить на заданую
тему, но если тема меняется - ТАК ТОМУ И БЫТЬ. Строгих правил нет.
На Agile Gathering мы обсуждали совершенно разные вопросы от
конкретных инструментов тестирования, до способов повысить личную
продуктивность. В некоторых местах собиралось 10-15 человек, в тоже
время в другом месте могло быть 50 человек. Все немного сумбурно, но
очень интересно.
Сессия может быть похожа на доклад, на мастер класс, а может быть
обсуждением.
Может быть один ведущий, а может быть 5.
Как хороший кофе брейк, только наличие расписания и флип чартов
здорово повышает продуктивность.
Будет классно!
2008/9/5 Alex Koshelev <daev...@gmail.com>:
Иван Пирог
Может быть один ведущий, а может быть 5.
Как хороший кофе брейк, только наличие расписания и флип чартов
здорово повышает продуктивность.
Будет классно!
Недавно читал о том, что когда люди одной профессии в большом количестве собираются на конференциях и у там у них есть возможность общаться друг с другом на профессиональные и околопрофессиональные темы, то мотивация этих людей значительно возрастает. Большинству такое общение даёт вдохновение. Взаимообмен информацией и опытом в результате заставляют "застоявшуюся реку" течь снова :) Новая информация, мнение собратьев по профессии на те или иные инструменты - все это мотивирует человека к дальнейшему росту.
По-моему, очень здорово :)
Alex Koshelev
Есть четыре ( в нашем случае) зоны. И расписание - в какой зоне в
какое время какой вопрос обсуждается.
Каждая зона организуется вокруг флип-чарта.
Кто-то сидит, кто-то стоит, кто-то переходит из зоны в зону.
Ведущий не обязательно гуру, просто заинтересованое лицо.
Мы все достаточно сознательные товарищи чтобы говорить на заданую
тему, но если тема меняется - ТАК ТОМУ И БЫТЬ. Строгих правил нет.
На Agile Gathering мы обсуждали совершенно разные вопросы от
конкретных инструментов тестирования, до способов повысить личную
продуктивность. В некоторых местах собиралось 10-15 человек, в тоже
время в другом месте могло быть 50 человек. Все немного сумбурно, но
очень интересно.
Сессия может быть похожа на доклад, на мастер класс, а может быть
обсуждением.
Может быть один ведущий, а может быть 5.
Как хороший кофе брейк, только наличие расписания и флип чартов
здорово повышает продуктивность.
Будет классно!
Понятно.
Но тогда получается, что этот OS был на каждом из ексепшенов. Поскольку всегда после докладов собирались люди и обменивались мнениями, задавали вопросы и обсуждали что-то. Тут получается всё будет так же только чуть более организовано.
Не плохо. Должно быть действительно интересно.
Dmitry Kozhevin
> всегда после докладов собирались люди и обменивались мнениями, задавали
> вопросы и обсуждали что-то. Тут получается всё будет так же только чуть
> более организовано.
> Не плохо. Должно быть действительно интересно.
Именно !
PavloShevelo
> 2008/9/3 slav0nic <slav...@gmail.com>:
>>
>>
>> надеюсь видео я посмотрю В)
>>
>> интересно
> [skipped]
>> - python success story
>
> Это уже не интересная тема, по-моему.
А моє IMHO - ця тема вічна ;)
>
> Список однако, неслабенький. Тут на несколько конференций можно растянуть. :)
>
Це дууууже добре! :)
Sergey Schetinin
Иван Пирог
Мне всё еще хочется lightning talks =) Не будет?
Sergey Schetinin
минут, потом пару минут на вопросы и выходит следующий. И так раз пять
подряд.
http://en.wikipedia.org/wiki/Lightning_Talk
2008/9/5 Иван Пирог <ivan....@gmail.com>:
--
Sergey Schetinin
2008/9/5 Sergey Schetinin <mal...@gmail.com>:
Dmitry Kozhevin
> Скорострельные доклады. Когда человек выходит и делает доклад за пять
> минут, потом пару минут на вопросы и выходит следующий. И так раз пять
> подряд.
кофе-брейка.
Sergey Schetinin
тем про которые интересно послушать 5-10 минут, а целый доклад или
м-класс нет. Точно также очень много людей у которых найдется тема и
время для подготовки такого короткого доклада, в отличие от доклада
подлиннее.
Также для такого формата хорошо подходят всякие post-mortem втч
неудавшихся проектов.
Вот в одной из статей на которые ссылается википедия отличный список
возможных тем:
What can you say in five minutes?
Here are some suggestions:
1. Why my favorite module / add-on package is X.
2. I want to do cool project X. Does anyone want to help?
3. Successful Project: I did project X. It was a success. Here's
how you could benefit.
4. Failed Project: I did project X. It was a failure, and here's why.
5. Heresy: People always say X, but they're wrong. Here's why.
6. You All Suck: Here's what is wrong with our community.
7. Call to Action: Let's all do more of X / less of X.
8. A Funny Thing happened to me on the Way to the Mailing List /
Newsgroup / Web Forum.
9. Wouldn't it be cool if X?
10. Someone needs to do X.
11. Wish List
12. Why X was a mistake.
13. Why X looks like a mistake, but isn't.
14. What it's like to do X.
15. Here's a useful technique that worked.
16. Here's a technique I thought would be useful but didn't work.
17. Why add-on package X sucks.
18. Comparison of similar add-on packages X and Y.
19. Why we should be paying more attention to X.
20. My Favorite Feature
Такого у каждого найдется очень много.
2008/9/5 Dmitry Kozhevin <dmitrik...@gmail.com>:
--
Dmitry Kozhevin
мастре-классом ;)
2008/9/5 Sergey Schetinin <mal...@gmail.com>:
Sergey Schetinin
Например http://us.pycon.org/2008/conference/schedule/
2008/9/5 Dmitry Kozhevin <dmitrik...@gmail.com>:
--
Dmitry Kozhevin
После ОС уже ничего не хочеться. Может только пива. И
2008/9/5 Sergey Schetinin <mal...@gmail.com>:
Dmitry Kozhevin
Диктатор, пусть он и решет ;)
Sergey Schetinin
Еще б спринт куда-то впихнуть! (шутка)
2008/9/5 Dmitry Kozhevin <dmitrik...@gmail.com>:
>> Обычно их вроде ставят "на закуску".
> В общем я не уверен когда лучше это сделать. У нас тут есть свой
> Диктатор, пусть он и решет ;)
>
> >
>
--
Sergey Schetinin
чтобы уловить о чем речь.
Прочитайте доку и ответьте пожалуйста на вопросы
http://docs.google.com/Doc?id=dgcpmzth_13f2pqqwck
* Насколько трудно для понимания что вообще происходит?
* Насколько интересно что происходит уровнем глубже?
* Понятно ли зачем это всё?
* Возникают ли каверзные вопросы? (в подходе есть нетривиальные
побочные эффекты которые очень здорово учтены и нейтрализованы. есть
ли догадки в чем могут быть проблемы?)
* Углубляться ли в практические примеры?
* Стараться ли во всей полноте описать базовые возможности системы?
* Углубляться ли в более навороченные возможности?
* Например есть возможность зависить от таких вещей как прошествие
момента во времени. Т.е. правила могут составлять расписания
пересчета. Например если balance_warning висит сутки, акк блокируется
совсем. Еще парой строчек.
* Есть поддержка структур данных, без примера трудно понять, но в
общем слежение за срезами множеств например. Т.е. правило
пересчитывается если меняется что-то в этом срезе а не "хоть что
нибудь".
Потом добавлю вопросов и разовью доку, пока плиз ответьте на эти.
Vsevolod Solovyov
> * Насколько трудно для понимания что вообще происходит?
Примеры достаточно простые, поэтому и понять просто.
> * Насколько интересно что происходит уровнем глубже?
Очень :)
> * Возникают ли каверзные вопросы? (в подходе есть нетривиальные
> побочные эффекты которые очень здорово учтены и нейтрализованы. есть
> ли догадки в чем могут быть проблемы?)
Немножко есть. Например, что если у нас такой код:
class MoneyAcc(Component):
balance = attr(100)
min_balance = attr(50)
print_value = attr("zzz")
@maintain
def watch_balance(self):
if self.balance < self.min_balance:
print self.print_value
То есть, при первом вычислении, при проверке зависимостей, у нас не
дёргается print_value. Определяется это как-то или нет? То есть, если
поменять print_value, вызовется ли обработчик?
> * Стараться ли во всей полноте описать базовые возможности системы?
> * Углубляться ли в более навороченные возможности?
Думаю, не стоит. Времени не хватит :-)
> * Например есть возможность зависить от таких вещей как прошествие
> момента во времени. Т.е. правила могут составлять расписания
> пересчета. Например если balance_warning висит сутки, акк блокируется
> совсем. Еще парой строчек.
> * Есть поддержка структур данных, без примера трудно понять, но в
> общем слежение за срезами множеств например. Т.е. правило
> пересчитывается если меняется что-то в этом срезе а не "хоть что
> нибудь".
Круто! ;-)
--
Vsevolod Solovyov
Sergey Schetinin
>> побочные эффекты которые очень здорово учтены и нейтрализованы. есть
>> ли догадки в чем могут быть проблемы?)
>
> Немножко есть. Например, что если у нас такой код:
>
> class MoneyAcc(Component):
> balance = attr(100)
> min_balance = attr(50)
> print_value = attr("zzz")
>
> @maintain
> def watch_balance(self):
> if self.balance < self.min_balance:
> print self.print_value
>
> То есть, при первом вычислении, при проверке зависимостей, у нас не
> дёргается print_value. Определяется это как-то или нет? То есть, если
> поменять print_value, вызовется ли обработчик?
Вопрос отличный. Но до категории каверзных еще далеко =)
Ответ: зависимости вычисляются КАЖДЫЙ РАЗ. Т.е. при первом вычислении
print_value в зависимости не попадет. Его изменения будут
игнорироваться. Когда исполнение дойдет до print ... то появится
зависимость от него и при его изменении watch_balance персчитываться
будет! Когда условие в ифе перестанет выполняться зависимость исчезнет
=))
Но! делать принт в @maintain нельзя, там не должно быть побочных
эффектов, т.к. правило может пересчитываться несколько раз при
некоторых условиях. Побочные эффекты надо писать в @perform
>> * Стараться ли во всей полноте описать базовые возможности системы?
>> * Углубляться ли в более навороченные возможности?
>
> Думаю, не стоит. Времени не хватит :-)
Угу, но надо как-то показать что кроличья нора ведет глубоко. То же
асинхронное прогр.
>> * Например есть возможность зависить от таких вещей как прошествие
>> момента во времени. Т.е. правила могут составлять расписания
>> пересчета. Например если balance_warning висит сутки, акк блокируется
>> совсем. Еще парой строчек.
>> * Есть поддержка структур данных, без примера трудно понять, но в
>> общем слежение за срезами множеств например. Т.е. правило
>> пересчитывается если меняется что-то в этом срезе а не "хоть что
>> нибудь".
>
> Круто! ;-)
--
Sergey Schetinin
чем состоит дилемма.
С одной стороны библиотека неинтересна если не ясно кому это надо и
чем она лучше чего-то другого.
С другой стороны диферамбы без обьяснения как этим пользоваться и как
оно работает неубедительны (плюс неформат для м-класса).
Например мой последний доклад похоже страдал перегибом в сторону
обьяснений о том почему протоколы и peak-rules это здорово. В итоге
экономия на сложных примерах создала у кого-то впечатление что это
"энтерпрайз", бесполезная бодяга или еще что-то нехорошее. Так что
главный вопрос:
* Что вызывает больше вопросов:
* зачем это всё?
* куда это приткнуть?
или
* как этим пользоваться?
* как оно работает?
Dmitry Kozhevin
> * зачем это всё?
> * куда это приткнуть?
> или
> * как этим пользоваться?
> * как оно работает?
Первый общечеловеческий вопрос - Что это дает мне? Мне это системному
администратору и/или разработчику. В формате задача - решение без -
решение с.
Второй вопрос "как этим пользоваться" плавно вытекает из предыдущих use cases.
"Как оно работает" - тема для ОС.
Sergey Schetinin
> Первый общечеловеческий вопрос - Что это дает мне? Мне это системному
> администратору и/или разработчику. В формате задача - решение без -
> решение с.
Тема безусловно не из простых поэтому администраторы врядли смогут применить.
Также под большим вопросом, к сожалению, демонстрация варианта "без".
Во-первых это заняло бы раза в 2-3-4 дольше чем демонстрация того же
"с" (в чем собственно и сок). Кроме того очень многое, из того что
можно показать, "без" вообще не делается. То есть конечно всё можно и
на машине Тюринга сделать, но я думаю понятно что такие "альтернативы"
это несерьезно.
Вот кто-нибудь предложите альтернативу да хоть последнему примеру из доки?
Я конечно понимаю что это минус обьяснений, но тут действительно нужно
будет просто показывать полезные примеры и аудитория должна понимать
что иначе такой же семантики добиться почти нереально. Если будет
непонятно нужно будет обьяснять, но side-by-side сравнение не
получится.
> "Как оно работает" - тема для ОС.
Ага, согласен, в м-классе лезть в это не буду, максимум упомяну термины.
Sergey Schetinin
(повторить несколько раз)
Потом новая задача и аналогичный цикл. Итд.
2008/9/8 Sergey Schetinin <mal...@gmail.com>:
Dmitry Kozhevin
> Спасибо за ответ.
>
>> Первый общечеловеческий вопрос - Что это дает мне? Мне это системному
>> администратору и/или разработчику. В формате задача - решение без -
>> решение с.
>
> Тема безусловно не из простых поэтому администраторы врядли смогут применить.
состоянием своего зоопарка host/services?
В связке с twisted ?
> Также под большим вопросом, к сожалению, демонстрация варианта "без".
> Во-первых это заняло бы раза в 2-3-4 дольше чем демонстрация того же
> "с" (в чем собственно и сок). Кроме того очень многое, из того что
> можно показать, "без" вообще не делается. То есть конечно всё можно и
> на машине Тюринга сделать, но я думаю понятно что такие "альтернативы"
> это несерьезно.
Не верю! ;)
> Вот кто-нибудь предложите альтернативу да хоть последнему примеру из доки?
>
class MoneyAcc(Component)?
Я попробую предложить достойную замену. С django dispatcher.
Sergey Schetinin
> Т.е. я не смогу использовать trellis для того чтобы следить за
> состоянием своего зоопарка host/services?
> В связке с twisted ?
Я наверное отстал от жизни. Администраторы програмят на Twisted? =) Ну
можно конечно следить, только я не очень вижу где тут обработка
событий (только логироние?). Если подскажешь, попробую показать как и
треллис применить.
>> Также под большим вопросом, к сожалению, демонстрация варианта "без".
>> Во-первых это заняло бы раза в 2-3-4 дольше чем демонстрация того же
>> "с" (в чем собственно и сок). Кроме того очень многое, из того что
>> можно показать, "без" вообще не делается. То есть конечно всё можно и
>> на машине Тюринга сделать, но я думаю понятно что такие "альтернативы"
>> это несерьезно.
> Не верю! ;)
Ну вот тем не менее =) Так чтоб сразу с козыря зайти, где еще в основе
транзактная память?
>> Вот кто-нибудь предложите альтернативу да хоть последнему примеру из доки?
>>
> class MoneyAcc(Component)?
> Я попробую предложить достойную замену. С django dispatcher.
Ок, отлично.
Sergey Schetinin
2008/9/8 Sergey Schetinin <mal...@gmail.com>:
ем
Dmitry Kozhevin
>>> Тема безусловно не из простых поэтому администраторы врядли смогут применить.
>> Т.е. я не смогу использовать trellis для того чтобы следить за
>> состоянием своего зоопарка host/services?
>> В связке с twisted ?
>
> Я наверное отстал от жизни. Администраторы програмят на Twisted? =) Ну
> можно конечно следить, только я не очень вижу где тут обработка
> событий (только логироние?). Если подскажешь, попробую показать как и
> треллис применить.
модная и востребованная сейчас тема это управление виртуальными машинами.
событий тут куча - change of running state, change level of consumed
resources and so on.
>>> Также под большим вопросом, к сожалению, демонстрация варианта "без".
>>> Во-первых это заняло бы раза в 2-3-4 дольше чем демонстрация того же
>>> "с" (в чем собственно и сок). Кроме того очень многое, из того что
>>> можно показать, "без" вообще не делается. То есть конечно всё можно и
>>> на машине Тюринга сделать, но я думаю понятно что такие "альтернативы"
>>> это несерьезно.
>> Не верю! ;)
> Ну вот тем не менее =) Так чтоб сразу с козыря зайти, где еще в основе
> транзактная память?
ну я таких слов не знаю
мне бы чтоб работало и легко сопровождалось. ;)
Dmitry Kozhevin
>> можно конечно следить, только я не очень вижу где тут обработка
>> событий (только логироние?). Если подскажешь, попробую показать как и
>> треллис применить.
> администраторы используют python. ;)
> модная и востребованная сейчас тема это управление виртуальными машинами.
> событий тут куча - change of running state, change level of consumed
> resources and so on.
выделять больше ресурсов, или уведомлять админа.
многие задачи растянуты по времени и нужно отслеживать прогресс -
напр. резервное копирование или перемещение виртуальной машины на
новый хост.
Sergey Schetinin
> модная и востребованная сейчас тема это управление виртуальными машинами.
> событий тут куча - change of running state, change level of consumed
> resources and so on.
Спасиб, так понятней. Ну в общем неплохой пример на самом деле может
получиться. Конечно без реальной связки с поллингом состояний /
привязки к уведомлениям, но саму модель менеджмента можно компактно
реализовать. Причем тут естественным образом получится MVC. Настолько
естественным, что можно вообще не знать что за MVC и зачем. А
реализацию (-ии) привязывать к универсальной модели. Отлично!
Следующий пример буду писать на эту тему. Еще раз спасибо за
подсказку.
> ну я таких слов не знаю
> мне бы чтоб работало и легко сопровождалось. ;)
Ну вот в сложных системах это имеет значение. Сходу пример не приведу,
но по ходу дела будет ясно что это отлавливает ошибки которые обычно
не ловятся так просто, дает опять таки новые фичи и всё такое.
Специально на это заезжать не собираюсь, но думаю что по некоторым
темам надо будет упомянуть.
bialix
> Кроме того интересно было бы послушать про Bazaar VS Mercurial VS Git
Что именно интересно? Вменяемого доклада никто не представит,
поскольку практически никто не работал плотно со всеми 3мя системами.
Вкратце:
по популярности/скорости работы места распределяются так:
1) git
2) hg
3) bzr
по удобству использования:
1) bzr
2) hg
3) git
pako
> но по ходу дела будет ясно что это отлавливает ошибки которые обычно
> не ловятся так просто, дает опять таки новые фичи и всё такое.
> Специально на это заезжать не собираюсь, но думаю что по некоторым
> темам надо будет упомянуть.
посмотрел доку - по простым примерам сходу понятно, что это, для чего
можно использовать.
после этого не трудно и самому придумать и "решить" другие простые
примеры.
а вот что возникает в сложных системах - проблемы с порядком вызова
триггеров,
каскады и бесконечные циклы @perform,
как это привязать к СУБД, когда вместо присвоения значения переменной
происходит sql запрос?
Но в первую очередь: как такой сильно связный код тестировать/
поддерживать.
треллис видимо классная библиотека, но кажется что она страдает той же
проблемой что АОП:
для простых задач хорошо, но много не дает (выигрыш пропорционален
размеру задачи).
для сложных - человек не может в голове держать тот сложный неявный
граф зависимостей.
и если в треллисе нашли решение этой проблемы - вот об этом надо и
рассказать.
Sergey Schetinin
>> Ну вот в сложных системах это имеет значение. ...
>
> а я наоборот хотел бы именно это послушать.
> посмотрел доку - по простым примерам сходу понятно, что это, для чего
> можно использовать.
> после этого не трудно и самому придумать и "решить" другие простые
> примеры.
Оно то так, но к сожалению рассказывать надо с нуля. Если бы дать
народу вначале какое-то время пропитаться основами, то можно было бы
делать совсем другой доклад.
Поэтому попробую обрисовать ответы сейчас.
> а вот что возникает в сложных системах - проблемы с порядком вызова
> триггеров,
Система находит правильный порядок пересчета зависимостей, но для того
чтобы это было возможно, необходимо чтобы правила были без побочных
эффектов, т.е. чтобы в процессе "обучения" правильному порядку их
можно было откатывать.
> каскады и бесконечные циклы @perform,
@perform единственный тип правил в которых допустимо иметь побочные
эффекты, они вызываются в последнюю очередь и от них зависеть нельзя,
поэтому цикл тут невозможен (в них также не позволяется менять
структуры Trellis).
А вот циклы @compute / @maintain возможны, но они ловятся на первой
итерации -- каждое правило пересчитывается не более одного раза за
транзакцию (не считая откатов).
Также возможны конфликты, когда разные правила в течение одной
транзакции устанавливают ячейку в разные значения, например:
class C(Component):
a = attr(0)
b = compute(lambda self: self.a + 1)
c = attr()
@maintain
def rule_a(self):
self.c = self.a
@maintain
def rule_b(self):
self.c = self.b
Такие случаи также отлавливаются и сразу выдают ошибку.
Вот улавливания таких моментов заставляют увидеть некоторые
архитектурные ошибки, т.к. если обычно в одно и то же место могут
писать разные части кода, то это даже если случается race condition,
то вместо понятной ошибки мы видим "какой-то редкий дикий баг". А тут
всё сразу видно.
Таким образом Треллис, благодаря вот таких архитектурным требованиям,
скорей облегчает отладку.
> как это привязать к СУБД, когда вместо присвоения значения переменной
> происходит sql запрос?
Это будет выглядеть как присваивание переменной результатов запроса =)
Если полей много, то просто внутри @modifier (т.е. одной транзакцией).
А вот с получением / подпиской / отпиской от внешних событый уже
интересней. Например в последнем примере в доке wx.Window.Bind(..)
вызывается тогда когда появляется зависимость от соотв.
button_clicked[..], когда зависимости исчезнет, будет Unbind.
Правила @compute к этому тоже идейно близки. В отличие от @maintain
они вычисляются только при доступе или автоматически, если есть
слушатели. Поэтому в них запрещено менять структуры (в отличие от
@maintain), чтобы наличие слушателей не меняло поведение компоненты.
> Но в первую очередь: как такой сильно связный код тестировать/
> поддерживать.
Так вот, благодаря некоторым исходным требованиям каждую компоненту
можно отлично тестировать отдельно. Конечно какие-то ошибки могут
проявляться только в больших связках, но никаких эмержентных свойств
при соединении правильно написаных компонент быть не должно. Одна из
интересных возможностей это использование при тестировнии заглушек
вместо живых UI компонентов. Таким образом можно тестировать всё
приложение в целом не дергая UI библиотеку, которая тестированию
обычно ужасно мешает.
> треллис видимо классная библиотека, но кажется что она страдает той же
> проблемой что АОП:
> для простых задач хорошо, но много не дает (выигрыш пропорционален
> размеру задачи).
> для сложных - человек не может в голове держать тот сложный неявный
> граф зависимостей.
>
> и если в треллисе нашли решение этой проблемы - вот об этом надо и
> рассказать.
Я выше обрисовал некоторые полезные свойства и конечно хотел бы
рассказать об этом подробней, (разжевывать базовые примеры не самое
интересное), но как всё получится даже не знаю.
Иван, как думаешь?
Если есть вопросы, задавайте еще, очень помогает вспомнить чтож надо
бы рассказать.
pako
> итерации -- каждое правило пересчитывается не более одного раза за
> транзакцию (не считая откатов).
доклада.
то слова "транзакция" в ней вообще нету.
Для базовых примеров разжевывать транзакции не понадобилось, но похоже
они настолько важны, что рассказ без транзакций будет совсем
helloworld.
Sergey Schetinin
> доклада.
Черновик на первые 15 минут.
> то слова "транзакция" в ней вообще нету.
> Для базовых примеров разжевывать транзакции не понадобилось, но похоже
> они настолько важны, что рассказ без транзакций будет совсем
> helloworld.
Да. Там в доке упомянуто про уровни, транзактная память нижний из них,
но всё равно проявляется везде и для использования библиотеки
транзакции понимать необходимо. Вот поэтому я всё думаю как бы
рассказать чтобы было ясно и зачем это надо и основы использования и
вот такую информацию про то как всё работает дать и дойти бы до
продвинутых тем еще (там масса интересного).
Было бы здорово если бы в аудитории все могли быстро понять основы, но
это врядли. В общем, пожалуй, вместо того чтобы тянуть треллис на
уровень админов пусть лучше админы тянутся. Буду составлять план с
более стремительным углублением в сложные темы, и если кто будет
оправдывать своё непонимание тем что это "энтерпрайз", то так и будет.
Когда будет план пришлю сюда.
Arvid
> * Насколько трудно для понимания что вообще происходит?
> побочные эффекты которые очень здорово учтены и нейтрализованы. есть
> ли догадки в чем могут быть проблемы?)
> момента во времени. Т.е. правила могут составлять расписания
> пересчета. Например если balance_warning висит сутки, акк блокируется
> совсем. Еще парой строчек.
> общем слежение за срезами множеств например. Т.е. правило
> пересчитывается если меняется что-то в этом срезе а не "хоть что
> нибудь".
>
долго, главное чтоб в распечатке было
Dmitry Kozhevin
>>>
>> class MoneyAcc(Component)?
>> Я попробую предложить достойную замену. С django dispatcher.
>
> Ок, отлично.
не было django на лаптопе который взял с собой, так что написал пример
с использованием Louie - более продвинутой версии PyDispatcher.
---
easy_install Louie
---
#! /usr/bin/python
# -*- coding: utg-8 -*-
"""
There is another (no Trellis) way dealing with events.
Analog for example from http://docs.google.com/View?docid=dgcpmzth_13f2pqqwck
"""
import louie
class BalanceChangedEvt(louie.Signal):pass
class MoneyAcc(object):
def __init__(self):
self.balance = 0
self.interest_rate = None
self.state = 'red'
self.rate = None
def _get_balance(self):
return self._balance
def _set_balance(self, val):
self._balance = val
louie.send(BalanceChangedEvt, self)
balance = property(_get_balance, _set_balance)
class AccManager(object):
interest_rate_levels = ((500, 0.03), (1000, 0.05), (5000, 0.06))
min_balance = 50
@classmethod
def balance_changed(cls, **kw):
account = kw['sender']
if account.balance < cls.min_balance:
account.state = 'red'
else:
account.state = 'green'
#too lazy for calculating a rate
louie.connect(AccManager.balance_changed, BalanceChangedEvt)
---
>>> acc = MoneyAccount()
>>> acc.balance = 49
>>> print acc.state
'red'
>>> acc.balance += 2
>>> print acc.state
'green'
Сережа, это то что ты хотел увидеть?
Sergey Schetinin
Не для придирки а просто для обьяснения сразу укажу на то, чего этот
пример не делает.
1. отслеживается изменение только одного атрибута. т.е. для других
атрибутов нужны новые события. т.е. как есть не проходит вот этот тест
acc = MoneyAcc(balance=200)
assert not acc.balance_warning
acc.min_balance = 500 # тут нет никакого события
assert acc.balance_warning # и потому AssertionError
2. не следит за *изменением* значения, т.е. для семантики как у
треллис нужно было бы писать
def _set_balance(self, val):
if self._balance != val:
self._balance = val
louie.send(BalanceChangedEvt, self)
это мелочи конечно, но сильно влияет на то как именно треллис используется
3. нет транзактности и потому нет внешней валидации. т.е. ошибка в
обработчике не откатит изменение и оставит систему в неконсистентном
состоянии.
2008/9/21 Dmitry Kozhevin <dmitrik...@gmail.com>:
--
Sergey Schetinin
событый в том случае если источники событий будут разными обьектами.
Например:
class Policy(Component):
min_balance = attr(200)
class Acc(Component):
balance = attr(1000)
policy = attr(Policy())
# вообще правильней с lazy init:
# policy = make(Policy, writable=True)
@maintain
def watch_balance(self):
if self.balance < self.policy.min_balance:
raise ValueError("Can't withdraw funds")
acc = Acc()
# acc.policy = Policy(min_balance=2000)
# так корректней, но для примера точней следующее
acc.policy.min_balance = 2000
========================
Traceback (most recent call last):
File "trel.py", line 19, in <module>
acc.policy = Policy(min_balance=2000)
File "c:\work\_other_\checkouts\trellis\peak\events\trellis.py",
line 777, in __set__
.............
File "trel.py", line 15, in watch_balance
raise ValueError("Can't withdraw funds")
ValueError: Can't withdraw funds
Т.е. тут источник события, обьект Policy понятия не имеет о Accounts
которые его используют. Откуда эта инфа попадет в обработчик события?
Полагаю можно делать экземпляры обработчкиков вместе с экземплярами
Account. Но как решить вопрос изменения множеств подписчиков когда
меняется значение атрибута .policy?
2008/9/21 Sergey Schetinin <mal...@gmail.com>:
Сергей
http://self.maluke.com/#exc09
Dmitry Kozhevin
просто класс!
То о чем вы говорили может СИЛЬНО изменить способ того как мы программируем.
А то о чем вы не говорили, но куда направили внимание, еще больше ;)
2008/9/28 Сергей <mal...@gmail.com>:
Sergey Schetinin
помолчать -- приглашайте снова =)
К слову, спасибо всем участникам обсуждения в этой ветке.
Ивану без которого вообще ничего этого не было бы (хотя я всё равно
считаю что он постороил "ракету" и её надо "запускать", а он медлит).
Тебе Дим за постоянную обратную связь и предложения.
И отдельно Андрею. Если бы не его помощь (по собственной инициативе
кстати) то вышло бы совсем не то. Большое спасибо!
2008/9/28 Dmitry Kozhevin <dmitrik...@gmail.com>:
--
Dmitry Kozhevin
> На здоровье. (Интересно а про что не говорили? Я могу про это еще
> помолчать -- приглашайте снова =)
отсутсвовал.
> считаю что он постороил "ракету" и её надо "запускать", а он медлит).
а что ты имеешь в виду?
Sergey Schetinin
больше, выше, сильнее и притом не хуже. Ну и всякие смежные темы, он в
курсе.
2008/9/28 Dmitry Kozhevin <dmitrik...@gmail.com>:
--