FAQ

Под какой лицензией разрабатывается проект?

Была выбрана лицензия BSD, как позволяющая наиболее простым образом распространять код, разработанный на его основе. Коммерциализация рассматривается только в виде продажи поддержки решений, разработанных на её основе.

Почему лицензия не LGPL?

Лицензия LGPL не защищает от появления похожих продуктов для других языков программирования, а перспективы данного проекта нами амбициозно оцениваются, как: «обеспечивающий преимущество языка программирования, при всех прочих равных».

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

На какой стадии разработки находится библиотека?

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

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

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

Возможно ли моё участие в проекте?

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

Какие требования к разработчикам?

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

Как может выглядеть моё участие в проекте? Скажу сразу: я не умею составлять документацию!

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

Поэтому приветствуются вопросы любой степени каверзности. Ответы на некоторые из них имеют неплохой шанс быть помещены в этом разделе без указания авторства задавшего, поэтому их каверзность все же варьируйте в этой связи. Или присылайте с соответствующей пометкой в любой части сообщения. Например может быть выполнена так: «P.S. не для FAQ».

(2011-08-11): Пока наполнение раздела основной документации выполнено лишь частично, обсуждать пока — не наберется и на пятиминутный разговор. Если есть идеи или вопросы, то давайте обговорим. Мне интересно получать представлении о другом подходе к ORM специфике. Пока что: в личке — grossho at gmail. Обращение на «ты», по имени «Владимир» (Владимир Степанов aka GrossHo) — думаю устроит обе стороны. Если поток сообщений перерастет в нечто, с чем я перестану справляться, то придется перенести общение в новостные группы. Уже открытые нити общения туда дублироваться не будут в виду изначальной персонализации сообщений при составлении.

Это всё, чем я могу помочь?

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

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

Какие навыки мне будут полезны для участия в разработке по данному проекту?

Поскольку речь идет о ORM и Python, то в первую очередь пригодились бы навыки работы с разными СУБД под Python. Желательно иметь навыки программирования в Си (да, без плюсов), и в Cython — что аналогично.

Что касается требований по качеству знаний, то тут все гораздо сложнее. С одной стороны, человек — который преследует своей целью обучению именно этих навыков, был бы нам полезен, даже если он не полностью разбирается во всех вопросах. С другой стороны даже минимальное сопровождение людей отнимает массу времени. Возможно именно по этой причине программист переходя на должность менеджера программных проектов одновременно с этим перестает делать взносы в код проекта: перестает быть «играющим тренером», числясь в прежней лиге в несколько ином качестве.

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

Про основные алгоритмы: какой быстрей, а какой меньше потребляет памяти — знать необходимо, но необязательно.

Теперь о том, что знать необязательно, и какие навыки вовсе были бы нежелательны. Представим некоторого человека, не знающего про пузырьковую сортировку (что, конечно же — допустимо), но постоянно пользующегося quicksort — и теперь абсолютно всё данные сортируются именно этой функцией. Иногда для убыстрения сортирует даже то, что сортировать в данном конкретном случае вовсе не обязательно, аргументируя тем, что он быстрый, и данные после него — становятся быстрыми в девяти случаев из ста. В общем, когда наблюдается тенденция под один особенно хорошо работающий случай подгонять всю базу проекта без оглядки на другие аспекты творимого — для данного проекта, боюсь, этот навык никак не пригодится.

Почему проект ведется на русском языке?

Мы связываем это с тем, что UTF8 теперь стал доступен даже кухарке... :)

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

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