gihub для совместной работы студентов

Добрейшего!

На Хабре опубликовали интересную заметку - Системы управления версиями как инструмент совместной работы студентов. Ещё один интересный пример использования гитхаба не по прямому назначению :) про другой я недавно писал.

Мне, как преподавателю, решение представляется интересным. Повторю здесь то, что написал в комментариях.


Положительные стороны:
- Централизованное хранилище заданий и результатов. Во многих ВУЗах этого до сих пор нет, а тут - всё под рукой. И не будет типичных проблем накануне сессии из серии "у меня вчера вылетел жесткий диск, что смог, то восстановил, поставьте-хотя-бы-тройку!!!" :)
- Обучение системам контроля версий и багтрекингу. Очень правильно.
- Практика командного взаимодействия. Сначала - между преподом и студентом, потом обязательно начинается работа внутри группы. К тому же многие учебные программы имеют курсовые или лабораторные, прямо предназначенные для коллективной работы.

Отрицательные стороны:
- Необходимость наличия интернета. Да, для многих ВУЗов это до сих пор проблема. Кроме того, есть компьютерные классы, где выход в интернет запрещён или невозможен по техническим причинам.
- Привязка с конкретному инструменту. git и те тулзы, которые доступны на гитхабе - на них свет клином не сошелся. Есть, к примеру, ещё и централизованные VCS, они всё ещё имеют немалое право на существование, особенно коммерческие решения. В общем, получится очень однобоко, а это не есть правильно с точки зрения учебного процесса.
- Работа на стороннем сервисе. Пользователь не контролирует данные, находящиеся на сервисе. Но поскольку данные эти - не несут коммерческой инфы и их утрата не окажет большого влияния на учебу в целом (есть локальные копии), то минус это небольшой.
- Нет гарантии, что гитхаб не изменит свою политику и не ограничит подобные варианты использования.

А вообще - интересно.

Узелок на память: upgrade Mercurial 1.8 для Ubuntu 10.04

Добрейшего.

Набрёл на относительно недавний свой коммент к статье, решил, что стоит запомнить исходную статью в бложике.

Вводная. В общем, не так давно я таки поставил себе Убунту и начал с энтузазизьмом её заселять и осваивать на предмет замены Виндоуз в кажестве десктопа. И поскольку с некоторых пор активно использую для личных нужд Mercurial (параллельно с Subversion, да) - поставил и его туда.

Проблема. С Убунтой 10.04 (на мой новый ноут встала только она, 10.10 залазить не хотела) идет Ртутный версии то ли 1.5, то ли 1.6. Я же использовал к тому времени 1.8 и, как выяснилось, старые версии с репами от более новых версий работать отказываются. Убунтовый тул для апгрейда показывал, что в Убунтовых репозиториях доступна только старая версия.

Решение. Немного погуглив, нашел отменный рецепт решения, и довольно простой, в убунтовом стиле, я бы даже сказал. Собственно, это 3 строчки

> sudo add-apt-repository ppa:mercurial-ppa/releases
> sudo apt-get update
> sudo apt-get install mercurial

Проверяем результат с помощью

> hg --version


Кому надо ещё проапгрейдить TortoiseHg - в статье и про это есть.

Пример описания процесса создания релизов

Добрейшего!

Не так давно (ну хорошо, почти год назад) я решил сформулировать для себя задачи по улучшению инфраструктуры разработки. Проще говоря - надо было уже начать что-то менять в SCM-процессе, и не только в нём.

Упоминавшаяся там команда Ф - достаточно обособленная, но самая крупная, и задачи решает самые разнообразные. Так вот, один из разработчиков нашел время и описал процесс построения билдов и всего, что с этим связано. Фактически, описан процесс выпуска релизов от  получения исходников до начала развёртывания. Применяется много практик из continuous integration, но ими не ограничивается, а сам процесс описывается для Java.

Рекомендую ознакомиться для общего развития. Даже если ваш процесс отличается или вы только собираетесь что-то внедрять, заметка и названия тулов дадут направление, куда смотреть.

eTraxis теперь доступен в облаке

Добрейшего

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

Собственно, хотелось поделиться радостной новостью - eTraxis теперь доступен не только в виде исходников для самостоятельного развертывания у себя в команде. Теперь это ещё и сервис, работающий по модели SaaS - https://www.etraxis.com/.

Любой желающий может зарегистрироваться и получить свой поддомен (т.е. проект), где он получит возможность создавать до двух шаблонов своего workflow и до 5 пользователей. Специально для сервиса была переработана документация - теперь это несколько онлайн-презентаций с рассказами о том, как надо работать с системой. Можно заимпортировать готовый шаблон и начать работу.

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

Да, кстати, регистрация и использование - бесплатны. Что, конечно же, не мешает ткнуть благодарным пользователям на кнопочку Donate и перечислить малую толику :)

В общем - не сидим, регаемся и начинаем работу. :)

SCM - в массы, или Книжка, которую пишут в github

Добрейшего.

На Хабре сегодня зацепил взгляд заголовок, содержащий слова "литературное произведение, создаваемое с помощью GitHub". В мозгу сработало ключевое слово - и вот я уже читаю о том, как на github энтузиаст начал писать книжку научно-фантастического уклона.

По итогу порадовал сам факт, что контроль версий начал выходить за рамки традиционного применения. Фраза "разветвление сюжета" заиграла новыми красками :)

Конечно, инициатору ещё предстоит столкнуться с массой проблем, порождённых таким демократическим подходом. Чего будут стоить "форки" сюжета, заe которыми будет трудно уследить даже дотошному читателю. Однако - может получиться занятно.

Начинаю ждать кино, выложенное в Mercurial на Google Code через YouTube ;)

P.S. И почему мне упорно вспоминается "t" Пелевина? :)

Управление изменениями и кессонная болезнь проектов

Добрейшего!

Давно зрела мысль написать что-нибудь разумное, доброе, вечное. Бойся своих желаний!

Итак, для сайта OpenQuality.ru написал программную статью Управление изменениями и кессонная болезнь проектов. Получилось много и подробно - спасибо редактору сайта Юрию за правильно поставленные вопросы и предложения. Статья, как можно понять из названия - про то, как управлять изменениями в проекте и как изменяющийся масштаб проекта влечет за собой то, что у людей принято называть декомпрессионной болезнью (кессонкой).

В общем, читаем и высказываемся в комментариях к статье.

Используем git для управления сайтом

Добрейшего.

Я достаточно давно работаю в отрасли разработки приложений для веба, поэтому всегда с двойным интересом читаю материалы о применении SCM для веб-разработки. Поэтому этот материал особенно порадовал: Using Git to manage a web site, что означает примерно "Как с помощью гита управлять веб-сайтом".

Идея, в общем-то, не нова. Берём git, создаем репо у себя и репо на сервере, где лежит сайт. Далее с помощью напильника и механизма хуков (hooks) настраиваем, чтобы при получении очередной дельты через push, локальная копия исходников сайта обновлялась из репозитория. Разработчик меняет код, делает push на сервер, там срабатывает хук, который разворачивает новые исходники в ту директорию, где у вашего сайта DocumentRoot.

Думаю, что-то аналогичное можно придумать и для Mercurial.

Для тех, кто использует распределённые системы контроля и пишет под веб, это хорошее решение.

Как выбирали между Mercurial и git для Google Code

Добрейшего.

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

С самого начала своей работы проект Google Code поддерживал только Subversion. Надо полагать, в виду его распространённости - ведь после заката CVS именно он стал стандартом де-факто среди бесплатных систем контроля версий. Проблемой выбора распределённой VCS команда озадачилась в 2008 году, в результате чего появилось вот это эссэ: Analysis of Git and Mercurial. Для тех, кто до сих пор поленился хоть немного изучить английский, есть народный перевод. Несмотря на мелкие неточности и стилистические ошибки, вполне можно понять, о чём речь.

Как видно на сайте Гугл.Кода, выбор пал на Ртутного. Причины - в тексте. Также встречал примерно следующее мнение - мол, приверженцы Subversion обитают на SourceForge, фанаты git - на github, ну и Гугл решил в чужой огород не лезть и взял под крыло Hg. Почему бы нет. К тому же, Python, на котором написана бОльшая часть Hg, весьма любим в компании.

P.S. Первый же коммент к оригинальному тексту вопрошает - почему Bazaar даже не рассматривали? Думаю, в первую очередь из-за его меньшей распространённости. Однако, прочитав очередной Bazaar hate speech, подумал, что не только поэтому :) Хотя это субъективное мнение, конечно.

Update: git таки появился среди поддерживаемых систем, не прошло и полгода: http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem

Книги // Software Configuration Management Patterns

Добрейшего.

Атака на книжную полку продолжается. На этот раз под раздачу попала ещё одна книжку из числа тех, что выбрал себе для детального ознакомления. Называется Software Configuration Management Patterns: Effective Teamwork, Practical Integration, авторы - Стёпа Берчук (Stephen P. Berczuk) и Брэд Эпплтон (Brad Appleton). На русский можно перевести как "Шаблоны управления конфигурацией ПО: Эффективная работа команды, практическая интеграция."

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

Как и в любой другой области знаний, в SCM есть свои устоявшиеся практики, методики и просто удачные способы сделать работу эффективной. Соответственно, кто-то должен был уже упорядочить всё это в одном источнике. Авторы же имеют большой опыт не только разработки ПО, но и управления конфигурациями, так что именно они и взялись за задачу.

Книги // Adapting Configuration Management for Agile Teams

Cigarettes and coffee, man, that's a combination.

(c) "Coffee and Cigarettes", Jim Jarmush

Сам я не курящий, однако для книжки, про которую пойдет речь, это вполне подходящий эпиграф. Потому как книжка - про соединение двух очень связанных областей - это гибкие методологии разработки (a.k.a. Agile) и управление конфигурацией (a.k.a. SCM).

Однако, обо всём по порядку. Не так давно я делал обзор книг по SCM. Заинтересовавшие книжки приобрёл и начал планомерно с ними знакомиться. В первую очередь ознакомился с трудом Боба Айелло Configuration Management Best Practices. Книжка была стоящей, как и ожидалось. Боб, как выяснилось, немного знает русский (работал волонтёром в ER и часто бывал на Брайтон Бич ;) ) и с помощью знакомого русофила ознакомился с отзывом, после чего сильно благодарил.

Следующей в прочтение попала книга Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed за авторством Марио Морейры (Mario E. Moreira). Название можно перевести как "Применение SCM в командах с гибкими методиками разработки: в равновесии между устойчивостью и скоростью". Что по-русски, что по-английски - одинаково громоздко, однако смысл понятен.

Перед прочтением опасался, что книжка будет похожа на героев старого анекдота про морскую свинку, однако опасения были напрасными.