http://webnewage.org/2012-01-23T02:58:20+03:00Новые записи блога 'Александр Кошелев'2012-01-23T02:58:20+03:00Александр Кошелевhttp://webnewage.org/2012/01/23/application-server/

<p>Всё чаще стал себя ловить на мысли, что нам в питонячей вселенной не хватает классического сервера приложений.</p> <p>От него хочется совершенно банальных вещей:</p> <ul> <li>Менеджмента конфигураций</li> <li>Абстракции над хранением данных</li> <li>Возможности легкого добавления точек входа и компонентов</li> <li>Инфраструктуры для отложенного выполнения задач</li> <li>Каких-то батареек типа библиотеки с хелперами</li> <li>Простой интеграции с другими системами</li> <li>Предсказуемых внутренних процессов и возможности на них влиять (явная и контролируемая инициализация например)</li> </ul> <p>Самое интересное, что почти всё это есть как отдельные компонеты, но нет среды которая могла бы их объединить или предложить своё комплексное решение. При этом, конечно, этот сервер должен быть достаточно легким и не давить своим весом на пугливые умы опытных разработчиков.</p> <p>Эта ситуация мне очень что-то напоминает. Да, это похоже на мир веб-фреймворков. Они, зачастую, как раз закрывают эту нишу. Я уже не один раз приходил к выводу, что проще продолжать использовать веб-фрейморк даже в тех задачах, где нет непосредственой вебной составляющей. Тем более, если он уже применяется и его окружение уже содержит нужный контектс для функционирования других компонентов.</p> <p>Кажется, что отсутствие такого сервера приложений не продлится вечно и через какое-то время появится новый интересный игрок в этой нише. И как всегда, приходится бить себя по рукам, чтобы не ввязаться в его написание «на следующих выходных»:-)</p>

2011-04-02T23:18:51+03:00Александр Кошелевhttp://webnewage.org/2011/04/02/encoding-problem/

<p>Доброго времени суток!</p> <p>Сразу скажу, что я не программист, и питон вижу второй раз в жизни.</p> <p>Мой скрипт вместо русских букв выводит кракозябры. Думаю решение легкое, но я его не знаю.</p> <p>Надеюсь общий смысл я смог передать. Очень похоже, что кодировка windows-1251. Но <code>decode('cp1251')</code>, <code>decode('windows-1251')</code>, <code>encode('cp1251')</code>, <code>encode('windows-1251')</code>,  <code>decode('utf-8')</code>, <code>encode('utf-8')</code> не помогли.</p> <p>На <a href="http://docs.djangoproject.com">http://docs.djangoproject.com</a> я практически все просмотрел, ничего полезного не нашел и понимаю, что я совсем запутался.</p> <p>Хотелось бы увидеть рабочие строчки.</p> <p>PS: Сильно не ругайте, только учусь.</p> <hr /> <p><em>Надеюсь вы поняли, что это я решил изобразить типисный вопрос в питончий форум:-)</em></p>

2010-03-28T10:03:08+04:00Александр Кошелевhttp://webnewage.org/2010/03/28/fdd-forum-driven-development/

<p>Это такая новая техника разработки ПО. Она же "MDD" (mailing-list-driven development), и она же "CDD" (chat-driven development). Я конечно же немного утрирую, но не могу отделаться от этого ощущения. На программистских форумах, рассылках, jabber/irc конференциях очень часто можно встретить топики от одного и того же человека, который разрабатывает какой-то "проект". Он последовательно задает вопросы и по этим же вопросом можно достаточно детально узнать о проекта и более того можно стать его автором даже в больше степени, чем вопрошающий. По крайне мере складывается такое впечатление.</p> <p>Замечаешь это не сразу, а постепенно вопрос за вопросом вырисовывается картина того что же делает человек. Получается он ведет разработку, получая ответы и внедряя их в свой код (который хочется надеяться есть), проходит так весь путь написания проекта. И с большой долей вероятности в конце он прийдет на этот же форум и похвастается сделанным. И только изредка скажет спасибо участникам, которые по сути и написали этот проект.</p> <p>Иногда случается так что в очередном вопросе ты видишь свой же код, данный в ответ на вопрос заданный ранее, но уже как-то измененный и "не работающий". Ну ты понимаешь -- не работает он потому, что автор его не осознал и попытался как-то наобум изменить, что конечно не получилось. Это подтверждение того, что проект и состоит из таких снипетов, иначе он бы не работал никак, т.к. человек явно не квалифицирован достаточно.</p> <p>Доходит до того что после какого-то количества подобных вопросов уже можно сравнительно легко предугадать какой будет следующей и с какой проблемой. Поразительно. </p> <p>Это всё забавно и любопытно, но в это же самое время грустно. Люди которые практикуют подобного рода процесс разработки, не хотят сами разбираться в вопросе, искать ответы самостоятельно и главное думать сами. Им гораздо проще задать вопрос нa форуме, чем пойти с ним в гугл и в первой же ссылке выдачи найти на него ответ. Это удивительно. Но удивление это уже у меня прошло -- увы, такого рода эпопей становится всё больше и больше. И некоторые особо дружественные форумы и рассылки вот этой своей отзывчивостью только провоцируют такой поведение.</p>

2010-03-23T04:45:02+03:00Александр Кошелевhttp://webnewage.org/2010/03/23/devconf-python-2010/

<p>Какие у вас планы на 17-18ое мая этого года? Пока не знаете? Тогда я могу вам предложить интересное занятие на эти дни.</p> <p>В означенные дни в Москве пройдет первая российская конференция <a href="http://devconf.ru/">DevConf</a>, которая соберет множество веб-разработчиков из различных "вселенных".</p> <p>Среди прочих вселенных (секций), там будет своя, отдельная, уютная и посвященная <a href="http://devconf.ru/python/">Python</a>. Не знаю как вы, а я о чем-то подобном уже давно мечтал.</p> <p>Если вы хотите послушать доклады, поучаствовать в мастер-классах и пообщаться с интересными людми, обменяться опытом и приобрести новые контакты в сообществе, то вы обязательно должны поучаствовать. Регистрация уже открыта, так что не теряйте время и заполняйте <a href="http://devconf.ru/register/index/python/">форму</a>.</p> <p>Поверьте, такие мероприятия проходят не часто и если вы хотите быть в курсе последних трендов в Python мире, то оно того стоит чтобы поучаствовать.</p> <p>На данный момент мы активно ищем докладчиков и формируем программу. Если у вас есть интересные мысли и желание поделиться ими с сообществом, то регистрируйтесь и <a href="http://devconf.ru/python/offers/add/">предлагайте свои доклады/мастер-классы</a>. Если у вас возникнут какие-то вопросы, то можете смело задавать их мне, т.к. я являюсь членом оргкомитета и отвечаю за питонячью секцию.</p> <p>Call to arms!</p>

2010-03-13T20:08:25+03:00Александр Кошелевhttp://webnewage.org/2010/03/13/choose-http-walker/

<p>Как оказалось в питоне нет однозначно подходящего варианта. Всего-то хочется удобно дергать какие-то API и иногда стягивать файлы.</p> <p>Есть несколько библиотек, многие из которых друг друга используют и заимствуют функционал. Но вот чего-то одного, удовлетворяющего достаточно простым (ведь так?) требованиями, нет.</p> <p>Требования же эти такие:</p> <ul> <li>поддержка http/https</li> <li>возможность использовать любые http verb</li> <li>возможность отослать body запроса с произвольным Content-Type</li> <li>поддержание коннекта между запросами (keep-alive)</li> <li>работа с куками</li> <li>стандартная аутентификация</li> <li>file-like интерфейс к body ответа</li> <li>кеширование</li> <li>conditional get</li> <li>обработка низкоуровневых ошибок и оборачивание их в какой-то дженериковый <code>HTTPError</code> и наследников.</li> <li>возможность добавить в конвейер запроса хуки, чтобы можно было какие-то действия производить с отсылаемыми данными, либо результатом.</li> <li>возможность задать таймаут хотя бы для соединения </li> </ul> <p>Ну и пара экзотических хотелок:</p> <ul> <li>поддержка http pipelinening</li> <li>возможность делать запросы асинхронно</li> </ul> <p>Ведь не невозможного хочется. Но что мы имеем.</p> <h3><code>httplib</code></h3> <p>По сути основа всех питонячих "ходилок" по http. Находится в стандартной библиотеке. Главная особенность -- позволяет присоединиться к http серверу и делать запроса к его урлам в рамках одного соединения.</p> <pre><code>connection = httplib.HTTPConnection('example.com') result = connection.request('GET', '/foo') # ... result = connection.request('GET', '/bar') # ... connection.close() </code></pre> <p>Возвращает file-like объект и с недавних пор позволяет задать таймаут для соединения. Тут фичи заканчиваются и мы остаемся наедине с низкоуровневым интерфейсом.</p> <h3><code>urllib2</code></h3> <p>Стандартная высокоуровневая обертка над httplib представляющая из себя конвейер хендлеров, в которых можно организовать пре- и пост-процессинг запроса и ответа. Хендлеры также позволяют ходить не только на http ресурсы, но и на ftp, и в файловую систему. Хендлерами так же делается обработка кук и кеширование.</p> <p>Поскольку это обертка над <code>HTTPConnection</code>, то ответ получается тоже в file-like объекте. Но создать keep-alive соединение не дадут и задать таймаут стало возможно только недавно.</p> <h3><code>httplib2</code></h3> <p>Сторонняя разработка претендующая на универсальность и поддержку уникальных фич. Поддерживает кеширование, поддержку авторизации и обработку редиректов. Умеет держать коннект. Основная проблема -- пытается загнать весь ответ в строку и вернуть её. Не имеет стандартных способов внедрения middleware.</p> <h3><code>pycurl</code></h3> <p>Поскольку этот питонячий биндинг предоставляет практически голый интерфейс, то главная проблема -- API ужасен и приходится какие-то свои враперы писать на каждом углу. Хотя потенциально умеет всё.</p> <h3><code>***</code></h3> <p>В сухом остатке факт -- инструментов казалось бы много, но ни один не удовлетворяет всем требованиям. Идеальным решением было какое-то объединение всех перечисленных библиотек в одну. Либо на базе httplib/pycurl реализация высокоуровневой обертки, которая соответствовала бы требованиям. Но таких нет.</p> <p>Кто виноват и что делать?</p>

2010-02-21T23:08:38+03:00Александр Кошелевhttp://webnewage.org/2010/02/21/and-even-with-fogbugz-not-happened/

<p>Выбор идеального или приближенного к таковому тикет-трекера для личных проектов это просто какая-то мука. Сколько я уже их перепробовал -- и Trac пытался поднимать, и на bitbucket пытался вести таски по проекту. Все не прет. Bitbucket вообще в последнее время не радует своей нестабильностью и баговатостью, в том числе и в трекере.</p> <p>Требования у меня-то простые. Трекер должен помогать мне держать в актуальном состоянии фичи для реализации и баги для исправления. Все просто и чтобы без лишних рюшечек.</p> <p>Наверно самым удобным для меня сейчас является баг-трекер на Google Code. Там у меня есть один активный проект (<a href="http://code.google.com/p/djapian/">Djapian</a>), в котором довольно много всего приходится делать именно в тренере. Как-то так сложилось, что он даже в некоторой степени превратился в форум -- там задают вопросы, а я на них отвечаю с резолюцией <code>Invalid</code>. Мне это не очень нравится, зато я накопил опыт его использования. И метки мне там нравятся, и возможность добавить в фавориты какие-то таски, и разумные провязки с репозиторием кода. Да, по workflow наверно самый для меня подходящий. Только вот проектов больше там у меня не предвидится. Во-первых они там все публичные, что не всегда удобно, а во-вторых ни svn, ни даже hg уже не вставляют…</p> <p>В отчаянии решил попробовать FogBugz. Читал много положительных отзывов и имя автора предвещало что-то интересное. Зарегистрировал бесплатный аккаунт и пробовал потрекать там один из своих "домашних" проектов. Всё там ни как у людей, хотя конечно чуть получше чем в Trac. И даже удобно через API постись тикеты. Но что-то не то. Этот трекер как будто из другого мира, типа той же Jira (не к ночи упомянутой). Jira вообще отбила всякое желание иметь с ней дело где-то кроме работы, где она уж так сложилось что прижилась:-(</p> <p>Осталось только попробовать трекер на GitHub. Есть чувство что мы можем сработаться… Надеюсь. Тем более git вдохновляет всё больше.</p> <p>А вам какой трекер по душе?</p>

2010-02-20T20:41:35+03:00Александр Кошелевhttp://webnewage.org/2010/02/20/into-one-basket/

<p>Один из самых часто задаваемых вопросов на форумах по Джанге -- как на одной странице выводить информацию из разных информационных блоков (<a href="http://softwaremaniacs.org/forum/django/19475/">пример</a> такой ветки или <a href="http://softwaremaniacs.org/forum/django/20087/">вот</a> совсем свежий). Давайте попробуем разобраться в стандартных способах решения данной задачи. Я специально не хочу рассматривать тут какие-то сторонние решения просто из-за того, что их много и они не интересны с точки зрения изучения классических методик применения возможностей Джанги.</p> <p>Основной проблемой с которой сталкиваются вопрошающие -- как получить все нужны данные в одной вьюхе и зачастую из разных приложений. Это усугубляется тем, что у большинства в подсознании сидит необходимость разделения приложений на максимально независимые компоненты. И это правильное желание. Другое дело, что не надо этим принципом злоупотреблять. Если всё-таки ваши приложения нуждаются друг в друге достаточно сильно, то нет ничего плохого в том чтобы иметь в них перекрестные импорты и заимствовать функционал (в том числе по получению данных) так или иначе. Другое дело что таком случае стоит подумать о том, что возможно они настолько жестко связаны, что должны быть единым целым, т.е. одним приложением по сути. Но и даже в этом случае имеет смысл как-то чуть-чуть отделить общие данные от локальных.</p> <p>Обычно исходной целью стремления получить данные из разных приложений являются всякие виджеты, информеры и прочие "портальные" элементы, которые применятся в современных сайтах и зачастую повторяются в разных разделах. Причем обычно они либо везде выглядят одинаково, либо отличаются от страници к странице, но представляют одни и теже данные.</p> <p>Итак, Джанга предоставляет вам два разных по сути способа "собрать" на одной странице данные из нескольких компонентов. </p> <p>Первый это <a href="http://docs.djangoproject.com/en/dev/ref/templates/api/#id1">контекст процессоры</a>. Вообще контекст процессоры можно применять для многих прикладных задачи, т.к. по сути они просто добавлять в контекст некоторые глобальные данные. Удобны он ещё и тем, что подключаются в настройках проекта и могут поставляться вместе с отдельными приложениями. </p> <pre><code>def app_globals(request): return {'app_data': …} </code></pre> <p>Но тут надо помнить, что контекст процессоры глобальны и добавляют данные в контекст всегда, конечно если вы во вьюхах используете <code>RequestContext</code>, и вы не пытаетесь совсем хитрым образом обрабатывать разные <code>request</code>.</p> <p><a href="http://docs.djangoproject.com/en/1.1/howto/custom-template-tags/#writing-custom-template-tags">Шаблонные теги</a> намного более гибкие и позволяют не просто протолкнуть куда-то данные из приложения, а предоставить ещё возможность для их визуального представления.</p> <p>Я не люблю теги тупо проталкивающие данные в контекст, например такие:</p> <pre><code>def do_app_data(parser, token): return AppDataNode() class AppDataNode(template.Node): def render(self, context): context['app_data'] = ... return '' </code></pre> <p>Их поведение не всегда очевидно и они как бы не придерживаются идеи того, что теги что-то из себя возвращают в документ и не имеют побочных эффектов. При таком их использовании они просто изменят контекст и рендерят пустую строку. Иногда это удобно, но я скептически отношусь к таким ситуациям и предпочитаю их избегать.</p> <p>Кстати, то что в хелпере <code>simple_tag</code> нельзя получить контекст мне кажется очень разумным -- так не провоцируется его изменение.</p> <p>Гораздо эффективней использовать <a href="http://docs.djangoproject.com/en/1.1/howto/custom-template-tags/#inclusion-tags">inclusion</a> теги. Они позволяют и данные подготовить, и сразу выплюнуть их в шаблон в котором они будут отрисованы и попадут в вывод. При этом достигается максимальная изолированность логики, что очень хорошо сказываться на архитектуре системы.</p> <pre><code>@register.inclusion_tag('app_widget.html') def app_widget(): #... </code></pre> <p>В дополнение, при использование флага <code>takes_context=True</code> можно получить весь контекст, при необходимости взять оттуда какие-то дополнительные данные или даже прокинуть его целиком в шаблон виджета.</p> <p>Преимуществ применения шаблонных тегов куча. Их можно подгружать только в тех шаблонах, где предполагается вывод иммено этих данных. Теги позволяют четко разделить функционал внутри системы и не делать засоряющих всё контекст процессоров или функций которые как-то дополняют контекст внутри вьюхи. Их можно добавлять, удалять и редактировать отдельно от вьюх. Так же иногда удобно их применять в ситуациях, когда требуется отрисовать шаблон не зависимо от веб-запроса -- например при отправки каких-то уведомлений на почту, либо ещё чего-то так же оторванного от request/response конвейера. Также теги легко распространяются совместно с отдельными приложениями.</p> <p>Надо признать, что сейчас в Джанге вся шаблонна подсистема достаточно в грязном состоянии и уже зреет её существенный рефакторинг, который принесет более удобные пути создания теов различной сложности и приведет к общему знаменателю всякие техники этих тегов применения.</p>

2010-01-22T05:11:54+03:00Александр Кошелевhttp://webnewage.org/2010/01/22/django-couchdb-not-takes-off/

<p><a href="http://github.com/42/42-django-couchdb">django-couchdb</a> это ДБ бекэнд для Джанги с поддержкой CouchDB, разработанный командой 42cc.</p> <p>Начиная новый проект, я очень рассчитывал на это решение, но увы оно совсем не оправдало надежд. Основная цель была, используя CouchDB не отказываться от стандартной джанговской админки и попробовать её заставить работать при помощи это бекэнда. Любовь к админке обусловлена тем, что она уже написана и её не надо изобретать с квадратными колесами нам самим, то что наши контент-менеджеры уже отчасти привыкли к ней и не хочется сбивать им workflow.</p> <p>Авторы django-couchdb не скрывают что эта их реализация больше академическая и какого-то реального юзкейса у них не было. Что и проявилось в итоге.</p> <p>Сразу надо сказать, что на данный момент основная гитхабовская ветка не работает с текущей Джангой и свежим CouchDB. Это связано с тем, что в Джанге в последнее время серьезно переработали внутренний API бекэндов баз дынных, а новый CouchDB чуть более строг с структуре документов чем раньше. </p> <p>Но ладно, завести этот бекэнд вполне можно, что силами <a href="http://zloygod.livejournal.com/">Кости Меренкова</a> мы и сделали. Как и предполагалось, заработал базовый ORM, админка, а следовательно и приложения из contrib.</p> <p>Пожив какое-то время с таким решением, мы поняли, что во многих местах для нашей задачи оно избыточно, а в других просто неудобно из-за некоторых архитектурных особенностей: </p> <p>Список того что нам не подошло:</p> <ul> <li>Для каждой модели создается своя база в CouchDB. Пока не очень понятно, действительно ли это нам так нужно, но у нас все сущности живут в одной базе. Пока один из предполагаемых юзкейсов -- имитация классических джоинов <a href="http://wiki.apache.org/couchdb/EntityRelationship#One_to_Many:_Separate_documents">известным паттерном</a>. Плюс ещё вопрос психологии и каких-то представлений о том как оно "должно быть".</li> <li>Для каждой модели есть документ описывающий констрейнты -- типа уникальности того или иного поля. Это нужно для мимикрии под стандартное поведение ДБ бекэнда Джанги, но для нас это совсем излишне.</li> <li>Из-за того что по дефолту в CouchDB айдишники документов это хеши, то для того чтобы походить на классический бекэнд, django-couchdb пытается сам генерировать и раздавать возрастающие числовые ключи для документов. Нам это не нужно и тем более в trunk'е CouchDB уже есть механизм переопределения этого дефолтного поведения. CouchDB сам может генерировать числовые идентификаторы.</li> <li>django-couchdb хоть и зависит от couchdb-python библиотеки, но имеющимся там вью-сервером не пользуется и генерирует JavaScript код на лету для временных вьюх. Тут проблема даже не в том, что это JS код, а в том что это при мало-мальски больших объемах данных жутко медленно. Это вообще постулат серьезного использования CouchDB -- только постоянные вьюхи работают! Временные исключительно могут пригодится для отладки на малых объемах. У нас данных уже много и поэтому нас такой подход совсем не устраивает.</li> <li>Ну и вообще нам не нужен бекэнд.</li> </ul> <p>Какое-то время мы пытались как-то подтачить этот бекэнд под себя, но в итоге решили от него совсем отказаться. Было очевидно что он для нас действительно избыточен и мы можем попробовать пойти другим путем.</p> <p>И попробовали. Родилась у нас такая штука, которая позволяет, по средствам написания простого адаптера с оговоренным набором методов, динамически создавать модель, провязывать какую угодно логику для доступа к её объектам и заставить тем самым работать админку.</p> <p>Поскольку весь код наш и его значительно меньше, то мы решили остаться на ней. Получилось всё очень даже не плохо. Пришлось правда в паре мест применить манкипатчинг, но оно того стоило. Теперь мы имеем простой механизм связывания какого угодно источника данных с джанговской админкой. Кстати, в процессе реализации я окончательно осознал, что админка очень хорошо продуманная система внутри, которая позволяет очень гибко себя изменять.</p> <p>Что до contrib, то он конечно отвалился. Но не весь и то что нам нужно мы смогли зареюзать.</p> <p>django-couchdb хороший пример как можно делать бекэнд для нереляционных хранилищ, но у нас он не взлетел. А если учесть не очень специфичные наши требования, то не взлететь он может у многих. Хотя есть шанс довести его до ума и превратить во что-то более реальное. Может попробуете?:-)</p>

2010-01-04T00:43:18+03:00Александр Кошелевhttp://webnewage.org/2010/01/06/python-libraries-for-counchdb/

<p>По большому счету кроме urllib2 больше ничего и не надо. Но если хочется каких-то более удобных оберток над CouchDB REST API то есть из чего выбрать. Мне на глаза попадались три различные реализации и в начале разработки проекта пришлось потратить время на то чтобы выбрать подходящую.</p> <p>Сразу оговорюсь, что все они очень похожи и делают одинаковые вещи - оборачивают в объекты основные сущности, которые предоставляет API -- сервер, база, документ и вьюха. Все совместимы с последним релизом самого CouchDB -- 0.10.</p> <p>Первая из библиотек -- <a href="http://code.google.com/p/couchdb-python/">couchdb-python</a>. Самая старая из появившихся. Можно сказать референсная реализаци. Имеет все полезные абстракции и даже чуть боьлше. Это "больше" заключается в возможности задать схему документа в декларативном Django-like стиле и реализация питонячьего view-сервера. Первое нужно чтобы как-то структурировать документы и работу с ними, а второе для того чтобы использовать python как язык для map/reduce обработчиков вместо штатного JavaScript. Умеет работать как с simplejson так и с быстрой cjson библиотекой. Так же хочет чтобы балы httplib2.</p> <p>Следующий кандидат это <a href="http://couchdbkit.org/">couchdbkit</a>. Умеет практически всё тоже самое, но имеет чуть больше хелперов и экстеншенов с адаптерами к популярными библиотекам вроде Django. Тянет за собой в зависимостях restkit (как видно из названия -- REST-клиент библиотека от того же автора) и умную библиотеку для выбора оптимального json пакета в системе. Недостатком является отсутствие view-сервера (хотя обещают, что "на днях" появится) и начало синдрома "большого проекта" у автора.</p> <p><a href="http://github.com/mikeal/couchquery">couchquery</a> -- из всех самая мало известная. Есть все базовые вещи плюс view-сервер как <a href="http://github.com/mikeal/couchdb-pythonviews">отдельный пакет</a>. Откровенно говоря, самая слабая из всех.</p> <p>В итоге я всё-таки выбрал couchdb-python. Написал какие-то вспомогательные функции по менеджменту баз и вьюх. Провязал их с подсистемой тестирования в Джанге. Понравилась работать со схемами -- всё довольно просто и прозрачно, и дает возможность легко наворачивать функционал вокруг.</p> <p>Возможно вы знаете ещё какие-то интересные реализации или аргуметы за/провит описанных мною, поэтому прошу поделить вашим опытом. Чем вы руководствовались и как выбирали CouchDB библиотеки для своих проектов?</p>

2009-12-10T12:11:00+03:00Александр Кошелевhttp://webnewage.org/2009/12/19/in-the-beginning-should-retrain-all/

<p>Прежде чем <a href="http://softwaremaniacs.org/blog/2009/11/30/gotta-rewrite-everything/">"всё переписать"</a>, надо рассказать людям - а что это вообще такое! Многие не понимают ни как правильно писать в асинхронном стиле, а вообще всей этой парадигмы.</p> <p>Уже достаточно давно мой способ знакомства с новой технологией это подписка на список рассылки и внимательное изучение вопросов, ответов и вообще общего духа сообщества. Так случилось что на рассылку node.js я подписался до знаменитого поста Саймона и смог увидеть резко возросший интерес к теме.</p> <p>Как это обычно бывает набежало сразу куча восторженных людей и пошли многокилометровые споры о том какой MVC фреймворк надо на базе этого сделать и какой шаблонный движок реализовать. Уже плохо. Но когда люди участвующие в подобных спорах вдруг, так, невзначай, приходят и задают с виду безобидные, но выносящие мозг вопросы как <a href="http://groups.google.com/group/nodejs/browse_thread/thread/7710c85e82689450/b1a8450fe13c6a89#b1a8450fe13c6a89">этот</a> или <a href="http://groups.google.com/group/nodejs/browse_thread/thread/957ca77629aa47e8/5f89671baa06a7f0#5f89671baa06a7f0">этот</a>, то опускаются руки и кажется что в нашем разработческом мире не всё хорошо.</p> <p>Люди не понимают сути. Совсем. Причем им как бы интересна технология. Встает вопрос почему? Да модно просто. Такое происходит уже не в первой рассылке которую я наблюдаю. Так же было с CouchDB например. </p> <p>Кстати, что я заметил -- эти люди в основном пишут на... ruby. Ну не важно:-)</p> <p>Не понимают они, что новые технологии это не только модный buzzword но и ещё теория. Не всегда легка. Это ещё и зачастую поворот мозгов в нужном направлении. А значит надо вначале учить и поворачивать. А уже потом приложатся и конкретные решения в рамках таких технологий и инфраструктура вокруг них.</p>