Как я бросил все и стал читать книжки PRO GIT... и придумал три классификатора.

Этот пост начинается с рассуждений о важности инфраструктуры... системе принятия решений..., потом я планировал здесь разобрать пример работы переводчиков book progit, однако решил написать о процессах самообучения на примере progit.
Получилось несколько простых классификаций (работа с открытыми проектами, стадии изучения, стадии завершенности проекта обучения), которые надеюсь использовать

Слово "Инфраструктура" и понятия стандарта Microsoft¶

В открытых стандартах (проектного управления) корпорации Майкрософт мне понравился подход, в котором задачи разработки софта отделялись от задач обеспечения инфрастуктуры разработки. Идея гениальная..., мне не хватало сообразительности (и в инженерах, и в директорах) разделять их. Я в лучшем случае включал инфраструктурные задачки в общий план проекта, как задачи развития, или это были такие же "текущие задачи", как, например, доставка накладных, инкассация выручки, ввод накладных в компьютер...
Не буду здесь распространятся на эту тему, а назову только одну причину - инфраструктурные задачи должны решать специалисты... , которых (как правило) нет в штате.

Можно привести пример с большим оборонным предприятием, в котором один сисадмин, который (естественно) не контролирует права доступа и установку софта.
А в бухгалтерии сервер - это компьютер главбуха..., а главбух на старый виндовс поставил новую версию 1С. И вся бухгалтерия подвисла... точнее "тормозит"...
А сисадмин кричит, что надо вызывать франчайзеров 1С. Какая знакомая картина... Выгоняют сисадмина
А когда я им сказал, что сисадмин прав..., надо всю систему (менеджмента) менять... как они удивились.

Моя инфраструктура - это мои основные трудозатраты¶

Заканчивается третий месяц, как я решил изучить Пайтон и написать библиотеку для парсинга. Написать - это громко сказано, скорее приспособить чужие для моих конкретных (секретных) проектов.
Проекты - это вполне конкретные исследования. Пожалуй, надо привести пример. Возьмем задачку "О выборах", данные подтасованы или нет? Есть таблицы из Центризбиркома, их нужно почистить, сравнить с другими таблицами... Потом рассчитать статичтические характеристики, построить диаграммы, написать тексты, провести обсуждения, еще посчитать, и снова построить диаграммы...
Поскольку некоторые исследования планируется "продавать", то нельзя забывать о рекламе, о привлечении сподвижников, сотрудников, консультантов, экспертов, покупателей (самое главное).
Все эти работы трудоемки сами по себе - постановка задачи, сбор и обработка информации, обсуждения, переговоры, реклама...
Выход только один - сначала подготовить "инструменты" и правила сотрудничества. Причем, инструментов появляется много, а вот с правилами все очень сложно...

Но можно ли "бросить все" и заняться только построением инфраструктуры?¶

Какие напрашиваются аналогии? 1. Ехать на автомобиле, или его ремонтировать... 2. Играть в теннис или тренировать удары... Первая метафора менее удачна, поскольку здравый смысл обычно подсказывает нам "что-то стучит в движке, надо остановиться", т.е. о выборе (ехать-ремонтировать) не задумываемся. А во втором случае все наоборот, тренировать удар у стенки скучно, долго... и, как правило, непродуктивно ... как показывает практика, просто скопировать чужую технику нельзя, нужен хороший тренер (специалист), либо умение "изобретать велосипеды"... так что после нескольких самостоятельных тренировок здравый смысл молчит, но работают хотелки, страсти, желания... мы просто "хотим играть"... и не хотим тренироваться.
Поэтому большая часть теннисистов любителей "просто играют" и остаются "чайниками" всю жизнь, и проигрывает тем, у кого "поставлен (натренирован) удар, подача...

Очевидно, что часто приходится "отвлекаться" на инфрастуктуру, но как это лучше делать?¶

Git - это система взаимодействия программистов при разработке и тестировании кода. ... ??? ... Нет, вариантов взаимодействия может быть много, и для всех (почти?) удалось разработать универсальную систему хранения кода...
Git - это, как минимум, книга 270 в страниц. Зачем мне сейчас изучать, как в Linux сохраняют работу кодеров? Я неделю "пробовал" сервис, потом искал, потом нашел и читал (заглотил) эту книгу, разве я уже не "бросил все"? Куда меня занесло?

Отвлекаться нужно и интересно, но где прервать цепочку самообучения?¶

Моё погружение в Git началось с ... того, что... код с библиотекой (не вспомню название, надо посмотреть в дневнике...) я начал пробовать Python под Linux (зарузка с флешки, возможности и настройки persistence, установка и обновление софта, затем всплыли задачи обмена файлами между компьютерами, в частности, как организовать облачные хранилища. Удаленные диски ЖРУТ ресурсы обмена с винчестером и тормозят все... поэтому решил понять, как работает GitHub... ...Посмотрел в дневнике (именно так его и надо называть !!!) - все началось с Sockets... и я еще забыл про библиотеку Patterns... Судя по датам в дневнике, я начал отвлекаться на инфраструктурные задачи с 6 марта... а сегодня 24 марта ...

Дневник - это даже не конспект¶

Очевидно, что конспект - это скелет (хребет, основа) того нового предмета, который ты изучаешь. У студента "скелет предмета" формируется во время сессии... Запоминается еще и послеовательность тем, что на какой странице... Потом полистал конспект, и все быстро вспомнилось (само). Но с изучением Git все было по другому... Сначала я просто хотел быстро понять принципы работы нового сервиса, но мне вместо этого попадались консольные команды... я начал все это конспестировать. Так что процесс изучения записан, но это скорее бессистемные поиски того, что и как изучать..., так что в дальнейшем этот пост не понадобится - там только ссылыки на видеоролики в конце, а сначала просто лог моих "тыканий"
Можно ли использовать этот пост для пробуждения ассоциаций? Там есть еще примеры команд..., но в идеале нужна четкая инструкция именно для моих нынешних нужд.
Ясно, что именно тот пост я опубликую. Но пока не знаю, стоит ли публиковать подобные логи (elog) процесса моего обучения... По крайней мере, из eloga ясно, что меня ждут две задачи (сокеты и паттернс)
Хорошо бы описывать ... нет, не постановку задачи..., а историю задачи... Почему я этим занялся, на что рассчитываю, основные источники, что знаю, что надо узнать, когда вернусь "для доучивания"
Может быть сделать рубрики со словами-тегами. Например "Выводы Git", чтобы потом задавать поиск по этому словосочетанию.

Насколько глубоко нужно изучать новый материал?¶

Ага, вот оно... Не пытаться написать ответы сразу, сформулировать вопросы, потом позаниматься, описать, что нашел, ссылки, выводы, предложения на будущее. Например "ToDo:", чтобы потом можно было искать по этим словам в тексте. Получается, что elog очень будет нужен для быстрой справки по состоянию моих "знаний" и для переспективного "мягкого" планирования... Зачем планировать? Пока знаю два подхода - Диаграма Ганта (директиваное планирование) и Scrum (Agile)... Но это все в группе. А если нет гарантий, что к открытому проекту присоединится народ (волонтеры)? Как вообще работать с открытыми проектами? Это уже другой вопрос.

Как вообще работать с открытыми проектами? Вот первые наброски:¶

Сначала, вопросы для ядра (центра зарождения) проекта:
1. Почему я этим заинтересовался? (Проблема, подпроблема...)
2. Что я надеюсь узнать и как много времени потратить на это?
3. Классификация проблемы (задачи) в проекте(стандарт Майкрософт).
Теперь вопросы о том, кого и как привлечь:
1. Какие навыки понадобятся
2. Какие специалисты понадобются (сочетания навыков)
3. Чем заинтересовать специалистов?
Затраты (времени и денег) на привлечение волонтеров, спонсоров
1. Создание инфраструктуры коммуникаци и принятия решений.
2. Собственно коммуникации.
3. Разработка и подготовка системы формальных институтов.

Здесь напрашивается мысль, что GIT важен для меня не только, как склад файлов. Меня еще интересуют правила и возможности сотрудничества, мотивы участников открытых проектов. Хорошо бы разработать универсальную инфраструктуру. Есть движки для сайтов опросов, обучения, багтрекеры..., а еще популярные StackOverFlow..., ну и Git вот начинаю понимать...
Этот процесс "понимания" идет подспудно за освоением. Потому оставим понимание социумов на "потом", а здесь сосредоточимся на моем осовении именно GIT.
Сначала попробуем использовать универсальный шаблон стадий:

Мое изучение Git можно разделить на стадии¶

1. Что это такое (основные понятия, ...)
2. Принципы работы (модель, теория - связи, границы)
3. Система команд управления (консольные команды)
4. Пракатикумы (формирование навыков управления)
5. Шаблоны, инструкции, регламенты (для частных случаев)

А теперь кратко отчитаемся о трудозатратах и получим классификацию "Стадии завершенности проекта обучения"¶

Сначала о процессе. Он законспектирован в следующем посте. Как видно из конспекта, началось все с двух статей, потом видео, а потом я нашел книгу, а потом перевод этой книги.
**Статья (пост) -> Видео -> Книги -> Базовая книга(Справочник) -> Регламент (HowTo)*

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

Как работали переводчики книги¶

Завершён перевод книги «Pro Git» / Хабрахабр
Я хочу помочь с переводом Pro Git. Вам нужны переводчики?
Последняя версия перевода книги за 24.03.2013 доступна в форматах pdf, epub и mobi.
ru The entire Pro Git book, written by Scott Chacon
Tutorials ...official...

In []:

Посты чуть ниже также могут вас заинтересовать