Google Chromium OS теперь open source

http://blog.chromium.org/2009/11/hello-open-source-developers-would-you.html

Удивительное дело, что еще остались люди, которые сомневаются, что open source - это единственная модель, с которой можно выживать при современном объеме и сложности софта.

Но вернемся к теме.

Chromium OS - загрузка за 4 секунды до получения браузера. Ну а параллельно можно грузить винды в виртуальную машину.



Вобщем, понеслась.

Git для борьбы с CVS

По долгу работы мне приходится участвовать процедуре следующего толка: есть ветка исходников, стабильность которой имеет чудовищную важность. Там не то, что сломать билд нельзя, там каждый коммит проходит несколько стадий автоматических проверок (компиляция на разных платформах разными компиляторами, прогон разнообразных анализаторов и т.д.) плюс надо получить подтверждение у как минимум четырех/пяти человек, которые должны проверить твой коммит. Процедура мучительная и долгая даже с технической точки зрения. Более того, процедура выстраивалась годами и основана на очень древней системе контроля версий (не будем называть ее всуе), поэтому возможности слияния и разрешения конфликтов в основном ручные. Она умеет нормально делать только check-out и check-in.

Как следствие того, что каждый коммит готовится, отлаживается и проверяется ощутимое время (благо это только bug fix'ы, размер которых обычно невелик), и даже формальная сторона вопроса может занять пару дней, и очень часто случается, что когда дело доходит непосредственно до команды "commit", все оканчивается конфликтом, так как кто-то уже успел потрогать твой кусок кода и залить это на сервер. И надо ручками сливать обновленную версию со своими изменениями. А если файл не один, то начинается головная боль.

Так как я только недавно в этой теме, то после второго же коммита решил упростить себе жизнь в плане слияния при конфликте.

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

В плане распределенных SCM я сейчас в основном работаю с mercurial, так как Google Code его поддерживает. Но все таки git - это невероятно мощный инструмент (правда когда в рабочем процессе не фигурирует Windows, ибо виндовая версия git'а портирована крайне криво).

По началу многое запутывает. Меня по первости крайне сбивала с толку идея staging area (или его еще называют - index). Эдакое промежуточное звено между локальными изменениями и самим репозиторием. Получается, что git diff может показывать три разные вещи: разницу между локальными изменениями и индексом (а не репозиторием - это будет по умолчанию, что обычно и вводит новичков в ступор), разницу между индексом и репозиторием и наконец разницу между локальными изменениями и репозиторием. Индекс (или staging area) позволяет при коммите выбирать, что именно из локальных файлов надо закоммитить, а не все подряд. В коммите участвуют только файлы, находящиеся в индексе. Причем самое интересное, что можно включать в индекс куски измененных файлов (например, я добавил в файл два новых класса, но закоммитить могу только выборочно один из них).

Вам уже нравится?

Или например, откат всех локальных изменений (очень частая операция) может быть выполнена как минимум двумя способами (через git checkout и через git reset), или откат уже сделанного коммита можно также провернуть минимум двумя путями (git reset или git revert) в зависимости от того, хотите ли вы видеть потом этот откат в истории.

Обилие функций и их некоторая непохожесть на общепринятые стандарты команд SCM немного обескураживают сначала. Но немного въехав в тему начинаешь ощущать всю мощь. Например, наличие staging area и git stash (когда можно временно заморозить текущее состояние, сделать какую-то быструю минутную работу и вернуться к основной теме) - весьма уникальные возможности git'a.

В плане GUI - gitk дает все необходимое.

Единственное, что надо выбрать по вкусу самостоятельно - это программу для проведения слияния при разрешении конфликта в графическом режиме. Тут у всех свои предпочтения.

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

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

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



Посты по теме:

• Какую распределенную систему контроля версий выбрать: Git, Bazaar или Mercurial?
• Travis Swicegood, "Pragmatic Version Control using Git"

Приглашения в Google Wave

Есть десяток приглашений в Google Wave.

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

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

И еще -- делитесь сами приглашениями, если они у вас есть или будут. Wave хорош, когда там есть люди.

Code review

Code review бесспорно является одним из ключевых моментов правильно организованного процесса разработки и поддержки софта.

Из лично опыта могу сказать, что весьма часто вторая пара незамутненных многочасовым смотрением на данный исходник глаз моментально замечает лажу, и в очередной раз удается избежать ночной fuck up, когда начинают валить письма от системы ночного тестирования, что туча QА тестов сломана из-за глупого недосмотра.

Perforce - отличная система для работы с реально большимы объемами репозиториев и кодовой базы в целом, но в ней нет встроенного механизма для code review. Google решили эту проблему сами.

В данном видео небезызвестный Гвидо ван Россум рассказывает о системе Mondrian, построенной на основе Perforce, которая применяется в Google для процесса code review.

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

Вести с полей эмулятора Радио-86РК на JavaScript

Когда есть немного времени, неспешно, с удовольствием, смакуя и присвистывая, развиваю эмулятор на JavaScript'е винтажного компьютера Радио-86РК.

Все как в старые добрые времена, только прямо в браузере (нажмите на картину ниже).



Текущая версия 0.6. Уже помимо самой эмуляции и набора игр есть встроенный ассемблер, на котором можно прямо в окне эмулятора писать и компилировать код для Intel 8080, и почти интерактивный дизассемблер, которым можно просматривать не только код, но и данные.

Несколько картинок (на них можно кликнуть).

Собственно, эмулятор (игра Volcano):



Ассемблер:



Дизассемблер:



Также постепенно дополнется список игр.

В плане браузеров я делаю в основном только под Хром, но говорят, что в Firefox и Safari тоже работает с разной степенью мини-глюков.

Удовольствие от этого проекта очень сложно объяснить. Тут что-то глубинное.

codepad.org

Открыл для себя codepad.org, и начал пользоваться с завидной регулярностью, когда надо быстренько что-нибудь попробовать - откомпилировать и запустить, а потом еще и показать кому-нибудь.

Искусственная типизация однородных параметров в C++

Допустим есть вот такой класс:

class Date {
 public:
  Date(int year, int month, int day) {
    ...
  }
};

К сожалению, не весь мир пользуется логичной нотацией Год/Месяц/День или День/Месяц/Год. Иногда люди пишут Месяц/День/Год. Хотя и первые два легко перепутать. Вот к чему я веду: где-то в далеком от описания класса коде кто-то пишет:

Date d(2009, 4, 5);

Что он этим хотел сказать? 4-е Мая или 5-е Апреля? Сложно быть уверенным, что пользователь такого класса когда-нибудь не перепутает порядок аргументов.

Можно улучшить дизайн? Да.

Например, так:

class Year {
 public:
  explicit Year(int year) : year_(year) {}
  operator int() const { return year_; }
 private:
  int year_;
};

И аналогично:

class Month { ... };
class Day { ... };

Интерфейс самого класса Date может быть таким:

class Date {
 public:
   Date(Year year, Month month, Day day);
   Date(Month month, Day day, Year year);
   Date(Day day, Month month, Year year);
}

И использовать класс надо так:

Date d(Year(2010), Month(4), Day(5));

или

Date d(Month(4), Day(5), Year(2010));

Результат будет всегда предсказуем и виден в вызывающем коде. Тут все inline'овое, так что эти три "лишние" класса никакого замедления не дадут.

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

Возражения есть?