Показаны сообщения с ярлыком git. Показать все сообщения
Показаны сообщения с ярлыком git. Показать все сообщения

четверг, 15 марта 2012 г.

Выпуск 8. Hello GIT!

Очередной спец. выпуск.


Hello GIT!

Как я уже писал в новостях Русофта у нас построена вся инфраструктура для использования GIT вместо SVN.

На GIT уже успешно переехал ЕИС, в ближайший месяц-два переедет PortalEngine (движок ЕИС).

Ниже предлагаю части письма, которые я писал нашему ген. директору, когда обосновывал переход на GIT. Они ответят вам на вопрос "Зачем GIT, какой от него PROFIT?" (с нетехнической точки зрения). На многие технические вопросы для программистов я уже ответил в Вики.



Git

GIt - это система работы с исходным кодом (аналог используемого нами сейчас SVN). У неё есть важные технические отличия от SVN.

Углубляться в них не буду. Главное, что они позволяют добавиться нескольких преимуществ в разработке:

  • Возможность изолирования изменения по одной или нескольким задачам (в т.н. "ветку"). При это над веткой может работать несколько человек, а по её готовности и проверке она "вливается" в основной код (основную ветку).
  • Что в свою очередь позволяет более гибко выпускать обновления и исправления на рабочем сервере. Сейчас нередко ситуация когда нужно выпускать очередное обновление, а какая-то одна задача тормозит процесс, но простым способом "выкинуть" её из текущего кода. С Git таких проблем нет. 
  • GIT упрощает Hot Fixes, когда на уже выпущенной на рабочий сервер версии есть ошибки и нужно внести изменения. С SVN часто бывало, что наша разработка уже ушла вперёд и просто так протестировать и выложить исправления мы не можем. С GIT это решается более просто.
  • GIT "поощряет" часты и маленькие "коммиты" (фиксацию изменений), в отличии от SVN где коммит часто у разработчика результат работы за день-два. Чем меньше коммит, чем проще в последующем анализировать историю при поиске ошибок и объединения изменений.
  • В GIT возможна организации различных хитрых подходов к разработке. Например, когда в production (рабочую) версию системы разработчики не могут сами внести изменения, а только через руководителя проекта. Он проверяет изменения и после этого подтверждаю их внесение. Для начала у нас будет коммунизм, но со временем я буду вводить некоторые "бюрократические" схемы.
  • GIT быстрее чем SVN, хотя для нас это не особо критично.
  • С GIT в случае падения сервера с репозиторием, мы сможем полноценно продолжить работу, ничего не потеряв (один из нас может "назвать" себя сервером и работать, как раньше).

Чтобы перейти на GIT код ЕИС переписывать никак не нужно, но нужно поменять некоторые автоматические утилиты, которые мы используем при разработке и которые были завязаны на SVN:

  • сбор ядра Pe
  • обновление ядра в ЕИС
  • сбор обновлений для рабочего ЕИС



P.S.

Напомню, что с удовольствие опубликую в блоге любые ваши рассуждения на темы, которые могут быть полезны сотрудникам Русофт (с оговоркой, что блог публичный, поэтому обойдетесь без откровенных indside'ов).

пятница, 27 января 2012 г.

Выпуск 6. Короткий

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



Продуктивность




Программирование

вторник, 13 декабря 2011 г.

Выпуск 5. Поток, зона комфорта и алгоритмы сортировки

В этот раз коротко.


Ещё раз про поток

Я уже упоминал поток раньше, вот вам ещё немного по этой теме:


Git победил

В непростом бою Git vs Mercurial для использования в проекте ЕИС победил Git.

Причины: 
  • в данный момент - лучшая интеграция в PHPStrorm и многие другие инструменты для разработки,
  • хорошее руководство в виде GitHowTo и Pro Git.
К Mercurial я по прежнему отношусь очень хорошо, во многих аспектах он лучше Git.


Зона комфорта

Не хочу пересказывать слова умных людей, вот вам две ссылки и цитата:

<...> человек в своей зоне комфорта пребывает в бездействии по отношении ко всему новому, ко всему непривычному, к новому опыту, к новым знаниям, ко всему, что может вызвать хотя бы малейший дискомфорт <...>.
Поэтому зону комфорта нужно расширять за счет огромнейшей зоны дискомфорта. Ведь именно в зоне дискомфорта лежат наши пока не достигнутые цели, пока необретенные знания, новый опыт и много-много всего другого.
 
(Мария Евграшина, tim.com.ua) 
Зона комфорта и бездействие от незнания
Зона комфорта и точки бифуркации

Развитие не возможно без преодоления трудностей!

Алгоритмы сортировки

Во-первых, интересный ресурс sorting-algorithms.com, где можно визуально посмотреть и оценить различные алгоритмы сортировки, их производительность для различных входных данных.

Во-вторых, статья про один из самых молодых общих алгоритмов сортировки TimSort, обладающий хорошей скоростью. Он уже заменил классический Qsort в python и java. По сути TimSort является удачной комбинацией ранее известных принципов.


Совет

Как ускорить вход по ssh - заметка в вики.


среда, 16 ноября 2011 г.

Выпуск 4. Супермены, будьте реалистами


I'm a superman!

Супермены (они же "герои", они же "трудоголики"), распространённая проблема, которую я встречал в своей жизни не раз. Кто они? Это люди, которые готовы работать до потери сил, в любой день, в любое время. Они могут сидеть на работе по 12 часов и ещё работать в выходные. При этом некоторым из них нравиться осознавать мазохистский факт того, что они делают что-то невозможное. Им нравится факт того, что они ничего не жалеют ради любимой работы.

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

<...> трудоголизм не только не обязателен, он глуп. Работать больше не значит больше заботиться об успехе бизнеса или больше выполнять. Это значит только то, что вы больше работаете. 
В итоге трудоголики создают больше проблем, чем решают. Во-первых, подобный стиль работы не может быть стабильным долгое время. И когда человек «перегорит», а это обязательно случится, последствия будут очень серьезными.  
<...> Трудоголики даже создают кризисы. Они не пытаются стать более эффективными, потому что на самом деле любят работать внеурочно. Им нравится чувствовать себя героями. Они создают проблемы (часто неосознанно), чтобы затем просто начать больше работать.
<...>На самом деле трудоголики не выполняют больше, чем нетрудоголики. Они могут заявлять, что являются перфекционистами, но это означает только трату времени на шлифовку незначительных деталей вместо того, чтобы переходить к следующей задаче. 
<...> Трудоголики – не герои. Они не берегут время, они просто сжигают его. Настоящий герой уже давно дома, он нашел более быстрый способ завершить свои дела.

Это часть из книги "Rework: бизнес без предрассудков", о ней и её предшественнице "Getting real" ниже.


Getting real, Rework

Это две книжки от известной компании 37signals (ага, та самая, которая создала BaseCamp и фреймворк Ruby on Rails).

Первая - "Getting real" крайне рекомендуется всем, особенно разработчикам и руководителям проектов. Книга состоит из 91 эссе, разбитых на 16 глав, и содержит много конкретных советов, как сделать лучше то, чем вы занимаетесь. Также это очередная книжка_которая_учит_нас_жить, но в отличии от многих других, делает это изящно и не навязчиво. Книга сделана короткой, намеренно короткой (прочитав книгу становится понятно, почему). При этом по количеству единиц смысла она превосходит многие многостраничные безнес-трактаты, которые мне приходилось читать.

Книга доступна свободно на сайте авторов, в том числе в переводе на русский.


Вторая - "Rework: Бизнес без предрассудков". Является идеологическим продолжением первой книги, но в основном с уклоном в бизнес сферу и управление персоналом. Стоит оговорится, что книга не столь однозначная, как Getting Real. Некоторые считают что это взгляд на бизнес из песочницы. Книга наделала не мало шума, есть как и фанаты, так и ярые противники. Я по какой-то причине не осилил её дочитать :) , возможно повторю попытку в ближайшее время.

Книгу можно подобрать на флибусте или купить в Озоне. Более подробное описание есть у М-И-Ф, которые её и издали в России.


DVCS: GIT & Mercurial

Прочитал две "канонические" книги про распределённые системы контроля кода: "ProGit" и "Mercurial: The Definitive Guide".

Как книжка мне больше понравилась "ProGit", как система контроля ревизий - Mercurial. Для тех кто, просто хочет узнать, что такое DVSC, лучше начать с ProGit, без этого в "Mercurial: The Definitive Guide" будет не понятно около половины текста :)

Я сейчас для себя начал активно использовать обе эти системы, чтобы понять на практике их отличия. После нового года, участь перехода на DVCS ждёт всех кто работает над ЕИС. Кто не спрятался, я не виноват.

Книги доступны полностью свободно и в разных форматах:
ProGit - сайт, на английском, в переводе на русский.
Mercurial: The Definitive Guide - сайт, на английском, в переводе на русский.