Python vs Ruby в Web

Являясь хоть и человеком не с огромным опытом за плечами, однако интересующийся web-технологиями, и работающим в этой области, то хотелось высказать свое мнение, в ответ на частый спор, или "холивор": Python vs Ruby. И в частности, я беру область именно веб-программирования и рынок веб-фреймворков. Здесь, я не хочу разглагольствовать, принимать чью-либо сторону из-за "православных" взглядов. Я просто хочу высказать свою точку зрения, и прошу не призывать меня к "холивору".
Тем, кому все таки моя точка зрения интересна, то прошу под кат.

Web-фреймворки и XMPP-боты

Тут как то в сидел, и думал для некоторых вещей написать бота на Python. И почему-то у меня всплыла мысль о том, почему нет фреймворков для написания ботов.
В процессе опроса juick'овчан, выяснилось, что такую попытку делали, и взяли за пример Flask, с его структурой. И почему то, мне эта идея очень понравилась.
А ведь правда, если рассмотреть поближе. Ведь зачастую, боты выполняют самые различные задачи, и зачастую могут иметь очень сложную структуру, которая еще больше усложняется тем, что сам по себе протокол XMPP довольно сложен, и так сходу написать структуру бота без поллитра - банально сложно.

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

Что может дать нам фреймворк? Фреймворк может скрыть event-систему внутри, от разработчика, предоставив интерфейс для работы с ней. Основной задачей разработчика бота является создание функций, которые будут обрабатывать те или иные команды, не отвлекаясь на внутреннюю реализацию. Разработчик должен писать код, который будет вызываться по некоторым событиям. Чем не реализация MVC для веб-фреймворка? Очень похоже на систему роутинга. Только вместо URL, мы имеем контекст события и команду. Те же Action выполняют код, а при помощи шаблонизатора можно удобно генерировать ответ на запросы.

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

Мысли немного скомканы, но надеюсь более менее понятны. =)

Карты, деньги, два ствола... Нет... Ruby, Rails, метапрограммирование

Нынче уже некоторое время пишу под Rails. С сожалением смотрю на себя, ибо все таки Python опыт - это опыт Python, но не Ruby. Добрался до некоторой задачи, и захотелось упростить некоторые вещи в шаблоне, а стандартные средства routes не устраивают. Точнее устраивают, но не совсем полностью. Спасибо Печорину Андрею, который подсказал некоторый выход из ситуации, и навел меня на метапрограммирование, которое, как оказалось хорошо применяется в Ruby.
Ничего серьезного, или дико умопомрачительного я не опишу, но покажу, что даже злостный eval (да-да, питонисты, да и вообще, сразу косо посмотрят на меня), может быть полезен, и он довольно таки вписался в Ruby. Точнее был красиво вписан туда.

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

Впечатления от Ruby On Rails 3

Уже больше недели безвылазно сижу в Chromium, Sublime Text2 и консоли. На подходе дедлайн по дипломному проекту, а у меня еще куча работы. После месяца упорных трудов с Flask, понял таки, что писать на нем большой проект с нуля - мне просто не по зубам. Не тот масштаб, и многое делать придется в ручную.
Ввиду того, что уже давно поглядываю на всем известные и нагремевшие Ruby On Rails, решил таки посмотреть, что там и как. По основным требованиям мне нужна была хорошая поддержка MongoDB, а также просто хорошие инструменты разработки для быстрого старта. На Python, среди таких инструментов мог бы оказаться Django, но вот проблема поддержки MongoDB - к сожалению актуальна в некотором плане.
Для начала осмотрелся с драйверами для MongoDB. Сразу подвернулся Mongoid. Взглянул на доки, пускай местами скудные, и во многом с ссылками на ActionRecord, но вещь оказалась более чем достойна внимания. Это поставило точку в моих терзаниях. С горькими слезами по тому, что таки на Python даже MongoKit не умеет таких прелестей, на какие способен Mongoid, я скрепя сердце создал новый проект на рельсах.

Поведение MongoKit для DBRef

Столкнувшись с проблемами в MognoKit при использовании вложенных массивов DBRef'ов и словарей с ними, у меня порой возникали ошибки при получении данных с этих документов. Я решил немного разобраться в этом поведении. Решил я идти не путем чтения кода, потому что, это заняло бы очень много времени, а так сказать, экспериментальным путем.

Начну по порядку. По умолчанию, когда вы имеете вложенные DBRef, то вы не можете явно искать по полям вложенных документов, так как база видит только DBRef. Например, если у вас есть документ поста блога, и в качестве автора DBRef на документ пользовательского аккаунта, то вы можете найти все посты автора используя запрос {'author.$id': author._id}.

Тоже самое поведение, и вызывало ошибки, когда я пытался получить внутренние данные именно пользовательского аккаунта. MongoKit dereference'ит только при явном запросе документа, будь он вложен в массив, или просто поле объекта. Поэтому, иногда нужно идти на ухищрения, и не паниковать, если возникают ошибки KeyError, или unicode не имеет метода или поля.

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

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

Приятного использования MongoKit.

P.S. Постараюсь выложить в дальнейшем код, для демонстрации. Если будет время, или не забуду.

MongoAlchemy - Внимание! Опасность!

Как и обещал, покопался малость в MongoAlchemy. Больше всего меня волновал вопрос поддержки отношений в базе. MongoAlchemy имеет поле DocumentField, как раз для встраивания документов.

Для проверки его работы, я решил написать небольшой тест. С двумя документами, который включает один в другой. В итоге, выяснил, что на самом деле, это не DBRef вовсе. MongoAlchemy просто копирует документ в другой документ, а не вставляет DBRef, и не dereference его.

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

Исследуя эту проблему, я не упустил возможность заглянуть в трекер MongoAlchemy на GitHub. У них уже пятый месяц висит задача на реализацию поддержки DBRef, и судя по всему, оно еще не реализовано.

Вывод: используйте MongoAlchemy аккуратно. Если ваш проект гарантирует то, что данные в базе не будут требовать отношений, то можете ее использовать. Но в любом случае, преимуществом будет использовать MongoKit, который на данный момент является лучшей ORM для MongoDB.

Краткий обзор ORM для MongoDB на Python

Постепенно интересуясь альтернативами MongoKit, я решил глянуть на альтернативы, и на то, что они предлагают. К сожалению, на данный момент, альтернатив в области Python MongoDB ORM мало, и они, не будем кривить душой, пока слабы. Но даже для их молодости, они уже вполне юзабельны, и могут использоваться. Во многом, здесь заслуга самой MongoDB, и разработчиков PyMongo.

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

I2P - свободный интернет

Тут в Juick, от пользователя @godfrey, проскочила просьба, перепостить его краткий FAQ, по вопросам, что такое I2P. За славой я не гонюсь, а идея такой анонимной сети в общем-то интересна, хотя лично я, пока не пользуюсь ей, по разного рода причинам. Но тем не менее. Под катом, краткий сборник формата вопрос-ответ о I2P.

Оригинал статьи: http://godfreystone.livejournal.com/837.html. По словам автора, там вероятно будут публиковаться еще несколько статей, касательно I2P.

Flask Tips - пред и пост обработка запроса на основе аргументов URL Rule

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

Объект Request в Flask, позволяет получить доступ к аргументам, полученным после парсинга URL. К примеру, у нас имеется Rule('/user/<username>'). При получении запроса, совпадающего с этим правилом, в request будет создан не пустой словарь request.view_args, который будет содержать аргументы для view. Но иногда, есть задачи, когда на основе этих аргументов требуется выполнять какую-то одну и ту же обработку в нескольких view, либо требуется, чтобы такая обработка была выполнена перед выполнением самого view, или возможно постобработка.

В Flask, приложение имеет возможность задать пост и пред обработчики, как уровня приложения, так и уровня модуля (если модули используются в приложении), и при последнем варианте, модуль может объявлять свои обработчики уровня приложения. Все они выполняются после создания объекта _RequestContext, объекты которого будут доступны, при запросе из в обработчиках. Это request, session, g и остальные. Поэтому, в обработчиках можно задействовать и request.view_args.

Рассмотрим на примере. Пример взят из моего дипломного проекта.

HTML5 - куда смотрят разработчики браузеров?

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

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

Для начала стоит посмотреть на поддержку стандарта на HTML5 Test. Я посмотрел свой Chromium 10.0.602.0 (68214) и Opera 11.01 (1190). Хром еще как то, Опера - слабо. Откровенно слабо по баллам.

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

Немного впечатлений от MongoDB, и WSGI-инструментария, в ходе разработки дипломного проекта

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

Конечно, все не так просто на деле, и с такого масштабного уровня, я опустился на более приземленный. Всего лишь bug tracker.

По пути, пришлось решить множество задач, которые с одной стороны и далеки от самой разработки, с другой стороны, они решают практически все в разработке дипломного проекта, как ПО. Задачи были связаны с выбором инструментальных средств, и вообще того, на чем это все будет держаться и строится. Благодаря этому, приобрел много опыта и главное впечатлений, от пробы того или иного инструментария. В основном, это касалось выбора хранилища данных, и инструментария для построения WSGI-приложения (с Python и WSGI, я определился уже очень давно, так как нравится и язык, и сама идея WSGI, и имеющиеся на данный момент инструменты, позволяют быстро и легко создавать приложения, при этом не мучаясь с организацией приложения, как это происходит в PHP, к примеру).

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