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.

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