Пользовательские Истории. Искусство гибкой разработки ПО

Тонюсенькая книжка Джеффа Паттона, которую я с огромным усилием воли впихнул в себя за три недели. Вроде как позиционируется для начинающих, объясняется на примерах и даже есть несколько полезных мыслей которые я для себя извлек. Однако, сама книга была явно написана по методологии Агиле без какой-то четкой структуры. Выглядит как набор историй из какого-то блога. Не рекомендую.

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

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

Триада из владельца, дизайнера, программиста чтобы создать полезное, удобное и реалистичное.

Изредка оценка снайперски точна, клиента получает то что просил, а просил он именно то, что ему было нужно

Высоконагруженные приложения. Программирование масштабирование поддержка

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

Project Unicorn

Джин Ким написал великолепное продолжение крутейшей книги Проект Феникс. Только на этот раз акцент смещен с devops на разработку. Половину книги разговор идёт про проект Феникс и полнейший хаос творящийся в нём, меня это ввело в заблуждение, что я аж полез проверять, не перечитываю ли я предыдущую книгу.

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

Я лично это наблюдал подобную трансформацию несколько раз и даже в какой-то мере поучаствовал лично.

Джин в книге сформулировал пять идеалов и провел проект по каждому из них:

«The First Ideal—Locality and Simplicity

The Second Ideal—Focus, Flow, and Joy

The Third Ideal—Improvement of Daily Work

The Fourth Ideal—Psychological Safety

The Fifth Ideal—Customer Focus»

Ну и просто интересное сравнение:

«Good timing for an outage, Maxine thinks as she walks back to the war room. Virtually all the Dev managers are already in there, so it should be pretty easy to figure out which part of the code is causing the problem. It’s like having a heart attack at a cardiologist convention—lots of qualified doctors are around.»

Итог: книга великолепная, 10 из 10.

Understanding ES6

Последний раз я активно писал фронтенд в 2008-2011 годах. Когда вместо браузера был IE6, вместо реакта и ангуляра был jQuery, а javascript был ужасным языком. С тех пор все поменялось: комитет договорился и в диком темпе начал чинить язык, который пребывал в заморозке все эти годы, впилив в него кучу вещей. Мне остро захотелось нагнать современный язык.

Для таких как я, вылезших из пещеры и запутавшихся в непонятном версионировании языка Николас Закас и написал эту книгу. Электронная версия доступна бесплатно на leanpub. Книга очень достойна.

На момент написания этого поста (лето 2018 года) завершается работа над 9-й версией стандарта. Но это уже никого не парит, потому что все используют Babel, который освобождает от зависимости от бразуеров и позволят использовать самые новые фичи, которые даже не стандартизированы, генерируя код, который пойдет на всех браузерах. За текущим развитием языка можно следить (и участвовать) в репозитории комитета.

P.S. шпаргалка на GitHub по современному JS

В восторге от Erlang

После курса OCaml продолжаю погружаться в эзотерику. На этот раз выбор пал на Erlang. Сначала расскажу про два курса по три недели на площадке FutureLearn от университета Kent, а затем общее впечатление об языке.

Первый курс – Functional Programming in Erlang мне показался достаточно простым. После OCaml-а мозги были достаточно вывернуты чтобы решать задачи паттер-матчингом и оптимизировать для хвостовой рекурсии. Синтаксис воспринимался интуитивно, главное отличие от OCaml – Erlang не типизированный язык и, как следствие, отсутствую алгебраические типы. Когда, началась третья неделя у меня возник вопрос: а где, собственно, хваленая распределенность. Как оказалось, для этого был отдельный курс.

Для того, чтобы пройти квалификационный тест и получить сертификат, нужно было заплатить порядка $80. При этом, изначальная цена была $60, на которую накинули налоги и доставку сертификатов из англии – все это вы узнаете непосредственно при оплате. После оплаты открывается тест: 10 вопросов, по 3 попытки на каждый вопрос. Итого – 30 баллов которые превращаются в проценты. Сделал 1 ошибку и набрал 98%. Сертификат шел примерно месяц.

Вторым фактом, поразившим меня до глубины души стало отсутствие электронной версии сертификата. Нет, ссылка на красивый сайт с анимацией и градиентами, где отображаются заветные проценты у них есть. Но она не в формате А4. У нас с саппортом состоялась переписка на предмет: я заплатил чертовы 80 баксов, дайте мне PDF-ку или PNG-шку, все что угодно, где мне объяснили что нужно дождаться бумажной версии и отсканить её. Фейспалм. Ладно, отсканю, что поделать.

Второй курс Concurrent Programming in Erlang начался через пару недель после первого. Я решил посмотреть содержимое и, забыв о том что я на третьей неделе, начал проходить курс. Через пару видеофрагментов, было предложено написать балансировщик запросов. У меня упала челюсть. Один кролик плюс один кролик будет два кролика, а теперь посчитайте интеграл. Эээээ, ШТОА?! Написал в комментариях все что я о них думаю, а затем заметил что я на третьей неделе. Либо остался осадочек, либо второй курс был действительно ниже качеством: авторы попытались взять набор лекций Джо Армстронга и и накидали вокруг других лекций с заданиями. При этом задания были сильно сложнее. В рамках курса две недели разбиралось "ванильное" параллельное программирование, а на третьей неделе была бегло рассмотрена платформа OTP. Бесплатный тест из пяти вопросов я сдал с кучей ошибок и поэтому платил очередные $80 за сертификат скрепя сердце. В итоге на 10 вопросов допустил три ошибки и заработал набрал 90%. Теперь жду очередной сертификат. Еще одним фейлом оказалось то, что у них сломалось автоматическое размещение сертификата на LinkedIn – впрочем обещали поправить.

Теперь про сам язык. В отличие от OCaml, где пяток французов играются в своей песочнице, Erlang у меня создал впечатление серьезного, консистентного языка с полноценной платформой. При этом ядро языка осталось очень простым. Курс по Clojure я дропнул примерно на половине, потому что я понял: на этом языке, в который налепили кучу сахара, и где нужно запоминать стопицот конструкций, у меня писать нет никакого желания.

JOE ARMSTRONG: I mean, it's maybe not apparent, but we've got 15 people in Ericsson who have built that stuff for 20 years. So there's something like 250 man years of work in it. It's big. На этом можно ставить точку и уходить смеяться над хипстерами с nodejs которые рассказывают про параллельный код.

JOE ARMSTRONG: But if you think about it, we are doing something that nobody else is doing. You see, we are running concurrent programs and looking for the bottlenecks in it. Other people are running sequential programs and looking for the concurrency in it. So we're already 20 years ahead. Адепты Sсala начали пилить Akka – некое подобие Эрланга c 2009 года, при этом сам Erlang не стоит на месте и у разработчики хотят адаптировать на географически распределенные облака

JOE ARMSTRONG: So the typical use case was 10 relatively powerful machines inside a corporate firewall. The usage patterns, we weren't thinking of millions of machines loosely connected, with a lot of security problems.

и работу Erlang на голом железе.

FRANCESCO CESARINI: I'm loving the whole discussion of microservices. We've been doing it for a long time. But to add to what Joe is saying, you know, I'm seeing a lot happening, running Erlang on the bare metal, running an Erlang-based OS, Erlang on Zen. And what's happening is that-- it's still on an experimental level, and I don't think we'll see any production code for another probably three, four, maybe five years, but integrating a soft switch into the Erlang VM, and then using software defined networking principles.

Дополнительным фактором в пользу Erlang является то, что он хорошо взаимодействует с другими языками, например C. При этом Erlang берет на себя коммуникационную часть, а непосредственно код может выполняться на более быстрых/удобных с вычислительной точки зрения языках.

Итог: я в восторге.

P.S. легендарный Erlang The Movie, где почти 30 лет назад (за 10 лет до java) демонстрировалась подмена кода на работающей системе без разрыва связи. Вашему левому уху понравится, если вы будете слушать в наушниках.

Проект Феникс

Или Роман о том, как DevOps меняет бизнес к лучшему. Великолепная книга, читается на одном дыхании. Написана с оглядкой на Цель Голдрата. Изначально я даже подумал что это третья книга из цикла книг о TCO Голдрата "Необходимо, но не достаточно", но оказалось что нет.

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

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

Сюжет книги – остросюжетный детектив. Главному герою необходимо распутать клубок противоречий за 90 дней, прежде чем инвесторы не разделят и не распродадут активы. Как и в Цели успешного начальника небольшого отдела делают выдвиженцем для решения невыполнимой задачи: починить этот хаос. Неподалеку находится мудрый советчик, который не говорит что делать, но помогает главному герою задавать Правильные Вопросы.

Итог: отличная книга, маст рид.

Город IT 2016

18-20 ноября в Томске проходила IT конфа: веб, машинное обучение – но это ерунда. Труъ разработчики ездят на конфы не за знаниями, а за чадом кутежа и новыми знакомствами. Сами доклады, кстати, были так себе. Хозяйка трехкомнатной квартиры видимо не поверила, что нас будет 11 человек и сильно удивилась когда мы все таки заломились. Не меньшее удивление у неё вызвало отсутствие разгрома.

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

Scratch для детей

Когда я читал эту книгу я вспоминал свой шестой класс, русифицированный бейсик на 386 компе и рыдал. На скратче (есть форк Snap! без флеша но с лямбдами) и на Kodu (только на windows) можно начать программирование лет с шести. Абсолютная легкость создания игра, с моей точки зрения, тут далеко не самая главная фича. Главное тут то, что сразу же закладывается правильная ментальная модель происходящего: главный игровой цикл, отправка сообщений, независимые агенты реагирующие на события. У меня на то, чтобы впитать эту концепцию на примере формочек в VB ушло несколько лет – тут это доступно прямо вот из коробки, на совершенно естественном уровне. Книга великолепна если вы хотите своего ребенка познакомить с программированием, перевод книги очень качественный, хотя русификация самого скретча далека от идеала и в некоторых местах даже пришлось сравнить с оригиналом, чтобы убедиться, что переведено правильно.

Хотя в книге и есть домашние задания, но сильно не хватает списка идей для реализации.

Introduction to Functional Programming in OCaml

Закончил курс Introduction to Functional Programming in OCaml в Université Paris Diderot. По крайней мере хватило сил закончить в отличие от clojurecourse.by который я тупо дропнул на середине. Никакой бумажки не дали, как это было на Coursera. Сделал вывод, а скорее подтвердил то, что было на Машинном Обучении: отсутствие в непосредственной доступности ментора приводит к колоссальным затратам времени и усилий на решение элементарных проблем, для меня онлайн-обучение элементарно не работает. Когда, после после пары часов отчаяния и созерцания кода, находишь элементарную опечатку (в силу непривычного синтаксиса), необходимо обладать железобетонной мотивацией для продолжения.

По поводу самого OCaml. С этим можно жить, но я слабо представляю в задачах крупнее небольших утилит заточенных под конкретную задачу. По ощущениям развитие платформы остановилось где-то в 2000-х на уровне междусобойчика французов. Использовать OCaml в обозримой перспективе я не буду. Функциональные подходы абсолютно органично вошли задолго до этого курса, когда я впервые подключил guava. Строгая типизация (в понимании OCaml) чересчур строгая для моих задач. Объектная ориентированность прибита гвоздями видимо в дань моде.

Синтаксис не взрывает мозг как в clojure, хотя к отдельным вещам можно и придраться, но небольшой набор простых инструментов и набор из базовых типов списка и кортежа, на котором строятся всё богатство возможностей, – это они сделали правильно. Паттерн-матчинг и алгебраические типы данных – это реально очень круто, раньше не сталкивался, а вот тут прочувствовал как код становится очень выразительным. В groovy конструкция switch даже не смотря на то, что может матчить энумы, значения, типы просто рядом не стояла. При помощи наследования можно отдаленно сымитировать алгебраические типы и я примерно даже представляю как можно было бы сделать пародию на паттерн-матчинг через рефлекшен и лямбды, но все-равно не будет статических проверок и деструктуризация даже в груви примитивна на уровне раскидать плоский tuple по переменным.

Из плюсов, F# очень похож на OCaml, скорее всего код на haskell мне теперь будет понятен. Записал себе на будущее – пощупать scala. Итого польза от прохождения курса – 4 из 5. Мозги немного повернулись и познакомился с новыми для себя концепциями.

Руководство по Java 8 от Шилдта

Продолжаю листать учебники по Java. В отличии от цикла Head First, Шилдт написал классическое серьезное руководство. Шилдта выгодно отличает от всех остальных книг то, что он освещает возможности, добавленные в Java 8. В частности, лямбды, а это – на минуточку, game-changer, меняющий очень многое в языке, стандартной библиотеке и вообще в подходе к решению типовых задач на низком уровне.

Книга написана для тех, кто уже знаком с программированием вообще и ООП в частности. Руководство для начинающих почти полностью входит в полное руководство, за исключеним задач. Поэтому, если вы торопитесь, берите 700-страничное руководство для начинающих, если под рукой нужен обстоятельный справочник, то берите полное, 1500-страничное.

Последний раз, когда щупал джаву, мы сидели на 6-й и только только начинали смотреть на 7-ю. Поэтому обновил для себя возможности 8-й. Хотя и вижно было что книга постоянно дописывалась, и на восьмую было уделено не так много места.

Программист – прагматик

Очень странная книга. Обо всем и ни о чем. Ощущение, что технические вещи, попытались пересказать чрезмерно упрощенным языком для людей далеких от профессии. С одной стороны все советы дельные, с другой – язык которым они донесены очень странный, плюс на это наложился перевод, который был сделан явно до появления устоявшейся терминологии. Зачастую приходилось угадывать о чем идет речь.

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

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

Хотя это и не полный отстой вида "Как пасти котов", но читать эту книгу сейчас сродни статье Go to statement considered harmful Дейкстры – индустрия согласилась и пошла дальше. По конкретным техническим вопросам лучше почитать специализированные книги: Dependency Injection и The Art of Unit Testing.

Изучаем SQL

Продолжаю тему рекомендаций, на этот раз SQL. Опять же, намеренно язык я не изучал. Знакомство с базами данных начал с Access, и еще в школе внезапно понял нормальные формы. В старших классах купил тоненький учебник "SQL в примерах и задачах" Астаховой. Сам учебник очень смутно помню, но судя по отзывам это переработанный и адаптированный старый добрый учебник "Понимание SQL" Грабера.

Я намеренно не стал смотреть талмуд Дейта. Помимо Грабера для изучения рекомендуют учебник Бьюли. С него я и решил начать. Язык изучается на примере безнадежно устаревшей MySQL 4. Справедливости ради даются отсылки к Oracle и MSSQL, но почему-то совершенно обделен вниманием PostgreSQL. Рассмотрены все необходимые конструкции SQL92. Огорчило, что очень мало внимания уделено консистентности данных.

В книге не хватает информации про:
1. ACID
2. нормальные формы и денормализацию данных
3. транзакции и уровни изоляции
4. движок базы данных и оптимизатор
5. структуры данных которые используются для хранения данных/индексов
6. оконные функции из SQL:2003.

Итог, минимально необходимая информация есть, но явно недостаточная для полноценной работы с современными базами данных. Придется читать другие книги.

P.S. если вы читали какую-то книгу по базам-данных/SQL не сильно привязанную к какой-то конкретной базе данных (я знаю про Кейта), а если по новым версиям SQL то вообще круто. Если эта книга показалась вам очень хорошей, оставьте комментарий.

Цикл Head First по Java

Столкнулся с проблемой порекомендовать книгу по Java. Изучал я, как сейчас помню, на ИНТУИТе. В самом начале карьеры я блуждал в потемках: на огромное количество вопросов приходилось искать ответы, зачастую, методом тыка. Сейчас с позиции опыта решил почитать доступные книги. Решил посмотреть на цикл Head-First Something. Я думал что это тоненькие брошюрки, а оказались здоровенные талмуды по 600 страниц каждый. Не смотря на несерьезный стиль изложения, освещены очень много важных вопросов, ответы на которые сэкономили бы мне очень много времени, если бы я прочитал эти в самом начале. Все три книги можно рассматривать как единый цикл, все ссылаются другна друга и все примеры приведены для Java. Книги являются учебниками, а не справочниками, с отличными примерами и заданиями. Однозначный must-read для новичков.

Введение в Машинное Обучение

Друг очень рекомендовал курс "Введение в Машинное Обучение" от Школы Анализа Данных Яндекса, и, поскольку моя работа напрямую связана с анализом данных, мне стало очень интересно пройти этот курс.

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

В описании курса было заявлено 3-4 часа в неделю, на протяжении 7 недель. По факту это выливалось в потерянные субботы на протяжении двух месяцев. Очень серьезная инвестиции собственного времени. Больше всего времени уходило, на решение домашних заданий. Особенно, когда возникали какие-то проблемы с питоном (уровня перепутал знак функции или невнимательно переписал формулу). Очень не хватало опыта работы с инструментами (ipython, jupyter), с библиотеками (pandas, numpy, scikit-learn). Непосредственно работа с данными была простая как дверь: загружаем данные, вызываем библиотечный метод, делаем прогноз. Тем более, что описание было представлено в лабораторной.

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

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

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

Java Puzzlers

По диагонали проглядел книгу в которой рассматриваются "особые случаи". Книга написана для Java 5 и издана до того как я вообще познакомился с джавой. 95 загадок, может дюжину-другую я разгадал потому что сталкивался на практике. Все советы относятся к двум категориям: читайте доки/спеки и не надо умничать. Отдельный совет используйте стандартное форматирование - это позволит избежать нескольких выносящих мозг ситуаций.

Я бы не советовал тратить на книгу время, максимум краем глаза. Посмотрите лучше это эпичнейшее видео ruby-wat (нужно некоторое время на загрузку). Или вот groovy версия. Смотреть живое видео гораздо веселее чем читать.

Про огромный маленький мир

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

Как-то получилось что у меня в ленте несколько лет назад оказалось толпа белорусов из программерской тусовки, среди них был +Pavel Drobushevich

На работе мы решили перейти с YouTrack на TargetProcess. ТР оказался весьма нетривиален и наворочен. Чтобы разобраться в некоторых деталях разработчиков собрали на вебинар, и Steven показывал как они сами работают с TP.

Каково же было мое удивление, когда я увидел знакомую аватарку, а потом вспомнил: Павел писал как он перешел в команду TP. В этот момент меня просто накрыло: специалист из Америки показывает разработчку из России как работать с их системой на примере разработчика из Белоруси. Какова вероятность того что два разработчика знают друг друга, пусть и заочно. В этот момент весь мир показался мне Pale Blue Dot.

Domain Specific Language

Я уже писал про свои эксперименты с DSL, захотелось подтянуть матчасть и прочитать классический труд. Книга на самом деле состоит из двух книг: первая - введение в DSL и обзор различных техник, вторая - типичный список паттернов, в которую Мартин собрал всё что только можно. Первая часть на пять, позволяет структурировать знания, вторую - тупо пролистал по диагонали.

Зачем нужен DSL? - ... two main ones: improving productivity for developers and improving communication with domain experts. A well- chosen DSL can make it easier to understand a complicated block of code, thus improving the productivity of those working with it. It can also make it easier to communicate with domain experts, by providing a common text that acts as both executable software and a description that domain experts can read to understand how their ideas are represented in a system. This communication with domain experts is a benefit more difficult to achieve, but the resulting gain is much broader because it helps unclog one of the worst bottlenecks in software development—the communication between programmers and their customers.

Главная идея: разделение на Internal и External DSL, необходимость для DSL Semantic Model, которая строится поверх Domain Model. Картинка которая объясняяет необходимость в DSL: даже скомпилированный код нуждается в движущихся частях, которые и обеспечиваются DSL. Здесь же корень стремлений вынести бизнес-логику в СУБД (результат немного предсказуем).

Идеальный вариант языки вида Ruby/Groovy, которые содержат богатые возможности для написания DSL. В любом случае, DSL очень просто можно реализовать практически где угодно, если архитектура приложения будет достаточно продумана: разделение на статическое API и движущиеся части в виде конфигов.

Про языки и DSL

Я уже как-то писал про инсайты, приходящие именно в тот момент, когда ты готов услышать их. Хотя большой вопрос: каков вклад счастливой случайности? Может это знание, как тайные знаки всегда было рядом, а ты их смог увидеть и понять, только когда стал готов, а случай подвернется рано или поздно.

Редактирование истории в git

Этот пост что-то вроде Advanced mercurial но для git. Рано или поздно все сталкиваются с двумя проблемами: у меня куда-то пропали коммиты и я запушил не туда. Во втором случае есть простой случай, когда никто не успел спулить и когда неправильный кормит у всей команды. Все опасаются применять команды с ключами --hard и --force, но это совсем не страшно, если понимаешь, что все обратимо и ты понимаешь чего хочешь достичь этими командами.

Концептуальное отличие от mercurial: в git коммит обязательно должен принадлежать бранчу (без бранча коммит становится detached head), а бранч может быть только один. В mercurial ветки могут быть анонимными, более того может быть несколько веток с одним именем. Чтобы коммит стал виден, должен существовать путь до него из какого-либо бранча. То самое отличие кроны и корневой системы (почему-то именно такая аналогия приходит в голову). В mercurial чтобы коммит был доступен должен существовать путь до него от 0-го коммита, а имена и прочее это мелочи. Соответственно и можно четко проследить начало и конец любой ветви, в отличии от git, где коммиты эфемерные дельты болтающиеся по узлам DAG. Хорошо это или плохо - зависит от, но в централизованной разработке мне больше импонирует mercurial с долгоживущими и вполне материальными ветвями, хотя это не значит что там нельзя редактировать историю - дельта алгебра везде одна. Git же заточен именно под распределенность и множество центральных узлов - помимо ветки foo-branch, обязательно есть origin/foo-branch или another/foo-branch с четким разделением откуда приехал коммит - в mercurial же именование веток сквозное по всем репозиториям, если стянули изменения то они уже ваши и отделить где чьё не получится.

Дальше пойдет описание трех сценариев в демке с github. Демка пошагово демонстрирует работу Алисы и Боба с общим репозиторием. Запускаем, читаем комментарии, жмем батон. Демка должна работать на unix-like системах где есть bash. Кстати, ознакомьтесь со статьей tonsky - прольет свет на внутренности git.

Пол года с Groovy и Grails

Пол года уже как пишу на Groovy/Grails и пора бы уже сформулировать отношение к этим вещам в письменном виде. Сравнивать буду, естественно, с Python/Django. Совсем немного пощупал cherrypy/jinja когда готовил олимпиаду для студентов, но они не сильно отличаются.
TL;DR версия: groovy восхитителен, джависты, для мелких тасков крутейшая штука, берите и используйте, grails не нравится потому, что рвет связность кода, особенно заметно на больших масштабах и совершенно немодульный.

Дальше будет описание отдельных аспектов и иногда сравнение.