Начинаю эксперимент

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

Цель эксперимента — показать, что на практике автор может работать не только не благодаря, но даже вопреки копирайту (см. разрешение на использование размещаемых здесь текстов). Другими словами, что взаимодействие автора и читателя вполне можно построить на основе добропорядочных (если хотите, даже дружеских) отношений. Когда автор отдаёт свои труды не с целью наживы, а из хорошего отношения к потенциальному читателю. А читатель в свою очередь платит автору за них не потому, что «иначе не дадут», а из благодарности и взаимного хорошего отношения к автору. Если, конечно, автор своей работой такое отношение заслужил.

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

Связаться со мной можно посредством этого сайта или по электронной почте t тчк t на unixforum тчк org. Отблагодарить за труды — по следующим реквизитам WebMoney: Z920987209732, R366536208721 или U419674034221 (если вам удобнее другие способы, доступные в Украине, напишите мне о них). Если вы хотите помочь, но не имеете возможности или желания помогать деньгами, вы можете, к примеру, сообщить об этом эксперименте как можно большему числу людей, которым это может быть интересно.

Приятного чтения.

Читать далее

Реклама
Рубрика: организационное | 4 комментария

DVCS: критерий для выбора

Часть первая: общие выводы.

Когда передо мной изначально встал вопрос выбора распределённой системы управления версиями (далее dvcs — distributed version control system), больше всего меня удивило полное отсутствие в сети каких-либо «подсказок». Из двух наиболее известных систем каждый пишущий о них делал выбор для себя, но либо не мог его мотивировать в принципе, либо ограничивался общими малозначащими фразами вроде «mercurial проще в освоении» или «git более функционален».

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

Начну с выводов, а затем уже отдельно остановлюсь на некоторых технических подробностях. В качестве «предвывода» простая аналогия: управление файлами. Здесь mercurial можно сравнить с мощным расширяемым файловым менеджером. Много наперёд написанного функционала. Если чего-то не хватает, можно писать собственные расширения на питоне. Но если вам «всё время хочется странного» и при этом питон — не самый любимый ваш язык, то через какое-то время вам может стать там тесно. С другой стороны, git — это командная строка bash (или zsh, выбрать по вкусу). Многие ваши экзотические желания реализовать куда легче, и в большинстве случаев это делается почти без дополнительных движений. Но начинающего может немного обескуражить. Некоторые достаточно повседневные вещи, которые в mercurial практически на виду, здесь не так очевидны.

В git вы почти всегда самостоятельно выбираете, каким именно способом решить конкретную задачу. В mercurial зачастую возможно «единственно верное» решение; вполне разумное, даже красивое — но не совсем ваше. В каких-то ситуациях такая определённость выбора полезна, в каких-то вредна.

Хочу сразу предостречь от одного неверного вывода, который как бы напрашивается из этой аналогии: использовать mercurial как ступеньку для последующего перехода на git. Они подразумевают достаточно различный стиль работы, да и в деталях реализации имеется несколько ключевых отличий. Одним словом, осваивать git после плотной работы с mercurial будет не проще, чем с нуля — только сложности в других местах будут выскакивать. Какой из них выбрать для личных задач, зависит от вашего стиля работы. Надеюсь, приведенная аналогия сможет вам в этом выборе помочь.

Второй вывод — уже относительно коллективной разработки. Вспоминая известную работу Эрика Реймонда, mercurial больше подходит для соборного стиля разработки, тогда как git — это однозначно базарный стиль. Иначе говоря, отличная сфера применения mercurial — корпоративный отдел разработки, а также коммерческий или полу-коммерческий проект. Где существует жёсткий регламент работ, чёткое распределение ролей и типовых задач, незыблемые сроки сдачи и железная дисциплина. Здесь, к примеру, простота освоения важнее двусторонней совместимости: новому сотруднику всё равно спустят сверху, с какой системой ему работать; а во многих случаях он ни одной из них знать не будет. В свободных проектах наоборот: если в проект хочет влиться человек, привыкший к другой системе, ему будет удобно работать с общим хранилищем, не меняя своих привычек. Там вообще как правило довольно мало жёстких ограничений. Каждый может работать в своём хранилище совершенно по-своему, в общее выдавая только выборочные коммиты. В git всё это значительно проще. Git даёт больше свободы действий, mercurial лучше страхует от неосторожных или необдуманных движений (впрочем, как и в жизни: дополнительные свободы — это всегда повышение ответственности).

Mercurial — это твёрдость, git — гибкость. Многие скажут, что твёрдость это основательность. Другие считают, что гибкость это развитие. И все по-своему правы.

Рубрика: анализ | Метки: , , | 2 комментария