Недавно разбирался почему клонирование большого репозитория в Git занимает так
много времени. Текущая версия ответа “ну репозиторий же большой, что ж вы
хотели-то?” звучит логично, но все равно руки чешутся найти какую-нибудь
глупость и ускорить этот процесс раза в два. Пока что-то не очень получается…
Пока копался в недрах наткнулся на то, что Git содержит встроенную трассировку
команд. Трассировка включается через переменные окружения вида GIT_TRACE_XXX.
Если значение переменной true, 1 или 2 - отладочные сообщения будут
писаться в stderr. Если значение переменной - абсолютный путь, начинающийся с
/, то отладочные сообщения будут писаться в этот файл.
Поддерживаются следующие категории сообщений:
GIT_TRACE: общие сообщения, которые не попали в другие категории.
GIT_TRACE_PACK_ACCESS: отладка обращений к .pack файлам.
GIT_TRACE_PACKET: трассировка пакетов для сетевых операций.
GIT_TRACE_PERFORMANCE: выдает информацию о производительности - в основном
меряет время, затраченное различными операциями.
GIT_TRACE_SETUP: выводит информацию о рабочей копии и окружении.
Разные категории сообщений могут писаться в один файл. Новые сообщения
дописываются в конец файла.
Возможность писать сообщения в файл особенно удобна. К примеру, я добавил
export GIT_TRACE_PERFORMANCE=/home/<user>/git_trace.log в .zshrc и теперь
если Git неожиданно замирает на ровном месте, tail -n30 ~/git_trace.txt выдает
мне сводку где Git проводит больше всего времени.
А давайте про ошибки в дизайне поговорим. Тем более, что задним умом мы тут
самые умные… Я в последнее время много играюсь с миграцией Subversion на
Git и многие их косяки так в глаза и лезут.
Начнем с Subversion. Во времена массового перехода с CVS на Subversion,
одним из главных аргументов “за” была поддержка директорий и операций
копирования/перемещения в Subversion. Было видно, что разработчикам поддержка
копирования очень пришлась по душе. Насколько пришлась, что и ветки в Subversion
создаются через копирование, а структура репозитория по-умолчанию - это
знаменитые три директории trunk, branches и tags.
Я догадываюсь как принималось это решение. Что-нибудь в духе “прикиньте,
одна операция поддерживает и копирование, и ветки, и метки. Не нужно писать
новый код для отдельного пространства имен веток. У нас уже есть этот код”. Но
если пересчитать набитые шишки, то становится понятно, что решение было так
себе… не очень… совсем хреновое решение это было, как оказалось.
Почему? А вот почему. Корректная работа с путями файлов, не смотря на кажущуюся
простоту, - это постоянный источник багов. Казалось бы, что тут может быть
сложного, но в результате получается как с указателями - нет, нет, а обязательно
один потеряется. А Subversion заставляет с путями работать.
Скажем количество шагов в пути для trunk и branches/foobar разная. Это
значит, что любой скрипт должен это корректно обработать. Не существует способа
найти все ветки в произвольном репозитории. Операция копирования не обязательно
означает создание ветки - а значит без какого-нибудь соглашения не обойтись.
Ну а мы знаем насколько хорошо люди выдумывают совместимые стандарты.
Использование копирования для создания веток автоматически означает, что
Subversion создать рабочую копию из людой директории в репозитории. Отличная
оптимизация, когда нужно выкачать один файл, но, опять же, это означает, что
скрипты не могут делать массы полезных предположений о структуре репозитория.
Практически сразу же вся эта гибкость запрещается и создается wiki страничка
“чекаут делается так, а ветки называются только так, а всех кто делает не так -
прибью нафиг”.
Теперь давайте про Git. Линус выбрал другую крайность. Вместо того, чтобы
оставить поддержку копирования для файлов, но сделать нормальные ветки, он
сделал нормальные ветки, но выкорчевал поддержку операций копирования. За одно
под раздачу попали пустые директории.
Объяснение, как я его понимаю, тут такое - ни копирование, ни пустые директории
с точки зрения самой системы контроля версий не несут полезной информации. Они
совершенно не нужны чтобы корректно отслеживать версии исходного кода. Более
того, эффективное использование Git подразумевает, что никто не анализирует
историю изменений коммит за коммитом. Вместо этого история - это просто такая
база данных, хранящая связи между изменениями в коде, и работать с ней нужно как
с базой данных - с помощью языка запросов, оперируя большими наборами коммитов
(т.е. ветками). Полноценная поддержка операции копирования означает, слияние
веток требует анализа каждого коммита между этими ветками (медленно). Git же
обходится только анализом начального и конечного состояния дерева файлов,
пропуская промежуточные состояния.
Что же тут плохого, спросите вы? В данном случае проблема упирается в психологию
людей. Да, соглашается подавляющее большинство разработчиков, - поддержка
копирования и пустые директории в принципе не нужны. Но! Мы к ним так привыкли.
Мы хотим линейную историю, явную поддержку копирования и пустые директории.
Нам без них не уютно.
Вы будете смеяться, но это реальная проблема. Особенно, когда мигрируешь с
Subversion на Git.
Но ведь оно раньше работало. Я мог сделать так и так.
Полностью согласен, но, на кой, простите, вам это нужно делать именно таким
способом?
Но ведь это единственный правильный способ. Мы так всегда делали…
У нас на работе есть коробка с плюшевыми медведями - специально для таких
случаев. Когда ситуация заходит в тупик и разумные аргументы уже не помогают в
дело вступают плюшевые медведи. Коллеге, чью любимую фичу пришлось отдать в
жертву прогрессу, на руки выдается плюшевый медведь - дабы облегчить тяжесть
утраты.
SpaceX will try to bring rocket upper stage back from orbital velocity using
a giant party balloon …
… and then land on a bouncy house.
SpaceX попробует затормозить верхнюю ступень с орбитальной скорости с помощью
гигантского надувного шара …
… и затем посадит на надувной домик.
Я вот прямо чувствую как зашевелились волосы и открылись геморройные язвы у
чуваков, которые ловлей обтекателя занимаются. Мы еще их толком ловить не
научились, а тут в очередной раз вылезла идея ловить целую ступень. Нам вот
такая штука нужна:
История модификаций Falcon 9 описывает все известные модификации Falcon 9 -
начиная с v1.0 до еще не летавшей Block 5. Я тоже узнал кое-что новое - никогда
раньше не слышал про v1.0 Block 2. В статье, само-собой, не обошли мимо вопрос
запутанной номенклатуры. В разное время официально1 ракета называлась:
Falcon 9
Falcon 9 v1.1
Falcon 9 Full Thrust
Falcon 9 Block 3
Falcon 9 Block 4
Falcon 9 Block 5
В ходу был еще наверное с десяток имен, часть из которых придумали в Интернете.
По этому случаю на мониторе одного из коллег до сих пор висит длинная цепочка из
post-it листков с надписью в духе “Falcon 9 v1.1 Full Trust Service Pack 1 Block A”.
Любой желающий может добавить вагон в конец паровоза.
Другая статья со ссылкой на анонимного инсайдера утверждает, что причиной
аварии при запуске суперсекретного Zuma в январе, все таки, совершенно случайно,
и почти невероятно, но таки наверняка был адаптер полезной нагрузки, коий
Northrop Grumman приобрела у третьей стороны. Адаптер был значительно
модифицирован и троекратно испытан на земле. Не смотря на это, после выхода на
орбиту адаптер не смог отделить спутник от второй ступени и тот был сведен с
орбиты вместе с ней.
Юмор ситуации заключается в том, что эта “утечка” один-в-один совпадает
начальным анализом аварии, опубликованном в первые дни после аварии. Легкий
наброс от Tom McCuin так и не смог превратится в мало-мальски достоверную
версию. Похоже, что Northrop Grumman таки придется выпустить публичный отчет о
происшедшем. 3.5 миллиарда народных денег, все-таки.
Этот калькулятор позволяет рисовать красивые графики, но главная фишка состоит
совсем не в этом. Он позволяет создавать интерактивные графики, наглядно
показывающие как меняется функция при изменения параметров.
Например, на графике ниже можно перетаскивать точки из исходной выборки и
посмотреть как в результате меняется линейная регрессия:
А на следующем графике можно посмотреть как увеличивается точность аппроксимации
функции в зависимости от количества членов ряда Тейлора:
У 3Blue1Brown, кстати, было очень наглядное видео, объясняющее принцип
построения ряда Тейлора:
В одном из самых больших парков Кито (столица Эквадора) стоит покрытый
граффити Douglass DC-6:
Согласно вики, этот DC-6 отправился в свой первый полет в США 15 февраля
1946 года и, до превращения в монумент в 2007 году, принадлежал Эквадорским
военно-воздушным силам. Памятник называется “Самолет фантазии” (что объясняет
граффити) и был установлен на потеху детям.
Часто, когда речь заходит про космический софт, можно слышать “ну уж там-то код
компилируется со всеми предупреждениями”, или “ну уж там-то наверняка запускается
статический анализатор кода и все ошибки исправляются”, или “ну уж там то тесты
покрывают код на 100%”. Как вы скорее всего уже догадались рая нет. Вернее, рай
в планах был, но из-за превышения сметы успели достроить только ад. К счастью,
костры успели развести только под половиной котлов, поскольку часть дров
заменили бетонными шпалами, а расположение котлов забыли задокументировать.
Сайт NASA Lessons Learned полон таких историй. Сегодня мы пройдемся по
результатам исследования Flight Software Engineering Lessons за авторством
Ronald Kirk Kandt опубликованное на конференции AMCIS 2009 (Americas Conference
on Information Systems). Автор исследования просуммировал результаты других
работ, посвященных трудностям процесса разработки программного обеспечения, а
также результаты расследования аварий реальных космических аппаратов.
12 января 2005 года с мыса Канаверал стартовал зонд Deep Impact, созданный для
изучение внутреннего состава кометы 9P/Темпеля. Зонд достиг кометы в июле 2005
года, после чего разделился на импактор и пролетную часть. 4 июля 2005 года
370 килограммовый импактор успешно столкнулся с ядром кометы на скорости около
10.3 км/с, выбросив в космос здоровенное облако пыли:
Согласно измерениям, проведенным космическим аппаратом Stardust в 2011
году, диаметр кратера, образовавшегося в результате столкновения, составил около
150 метров.
По завершению основной миссии, NASA направило зонд Deep Impact к комете
103P/Хартли в рамках расширенной миссии “EPOXI”. Пролет этой кометы
состоялся 4 ноября 2010 года:
В конце 2011 года, аппарат был отправлен на перехват астероида
(163249) 2002 GT пролет которого должен был состоятся в 2020 году. Однако
в августе 2013 года контакт с аппаратом был потерян:
3 сентября 2013:
… Связь с аппаратом утеряна между 11 и 14 августа (связь с аппаратом
поддерживается раз в неделю). Последний сеанс связи был проведен 8 августа.
Проведенное расследование позволило установить причину неполадки. Дальнейшие
усилия направлены на определение лучшего способа восстановить связь с
аппаратом.
23 сентября 2013:
… все попытки передачи низкоуровневых аппаратных команд не увенчались
успехом. На этом все возможные сценарии восстановления связи с аппаратом были
исчерпаны. Мы рекомендовали NASA объявить аппарат утерянным. NASA официально
заявило об утере аппарата в четверг 19 сентября.
