Кельты - те ещё затейники

А вот вы знали, что обыкновенное ирландское имя Siobhán произносится “шивон” /ʃɪˈvɔːn/? А Tadgh произносится как “тайг” /taɪɡ/? Вот и я недавно узнал.

Я покопался немного в сети и у меня получился следующий список. Русская транскрипция составлена по принципу “Рабинович по телефону напел” - все нюансы (ударение, звуки, которые невозможно изобразить кириллицей, длина и тональность) - полностью потеряны. Фонетическая транскрипция (если указана) скопирована из Википедии. В квадратных скобках указана ирландская транскрипция, в косых - английская.

  • Ailbhe - “элвиа” [ˈalʲvʲə]
  • Aisling - “ашлин” [ˈaʃlʲɪŋ]
  • Aoibheann - “эйвин”
  • Aoibhlinn - “эйвлин” /ˈiːfə/
  • Aoife - “ифа” /ˈiːfə/
  • Caoimhe - “квива” /ˈk(w)iːvə/
  • Ciara - “киира” /siːˈɛrə/
  • Cliodhna - “клиона”
  • Deirdre - “диирдра” /ˈdɪərdrə/
  • Dianaimh - “дианаф”
  • Eilish - “эйлиш”
  • Kieran - “кирэн” [ˈciəɾˠaːn̪ˠ]
  • Méabh - “мэйв” [mʲeːv]
  • Niamh - “нииф” [ˈniːəv]
  • Odhrán - “оран”
  • Orlagh - “орла”
  • Roisin - “рошин”
  • Sadhbh - “сайв”
  • Saoirse - “сирша” [ˈsˠiːɾʲʃə]
  • Seoidín - “шоудиин”
  • Sinéad - “шинэйд” /ʃɪˈneɪd/
  • Áine - “ааню” [ˈaːnʲə]

В качестве бонуса - небольшая шутка, объясняющая особенности произношения:

After centuries of English occupation, we had to become inventive in how we pissed them off. Coming up with unpronounceable names was a great way to see the English make twits out of themselves and us to have a laugh at them

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

:-)

P.S. На самом деле - ирландский язык происходит из другой языковой группы.

Read On →

Mr Steven

До чего техника дошла! Кто-то снял мистера Стивена с новой сеткой для ловли обтекателя на видео:

1.8 миллионов

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

Вообще говоря, до начала поисков я предполагал, что придется перелопатить кучу страниц, отсеивая желтую прессу, прежде чем найдется достоверный источник информации. Но нет же, первый же запрос выдал статью, ссылающуюся на оригинальное исследование NASA Goddard Institute for Space Studies и Columbia University Earth Institute.

О чем же говорит это исследование? Количество предотвращенных смертей в период с 1971 по 2009 год оценивается в 1.84 миллиона. За год в период с 2000 по 2009 год предотвращается в среднем 76 тысяч смертей. Для сравнения в Германии, которая обязалась отказаться от ядерной энергии до 2022 года, использование ядерной энергии предотвратило около 117 тысяч смертей в период с 1971 по 2009 год (диапазон оценки - от 29 до 470 тысяч).

Сколько жизней было потеряно в следствие использования атомной энергетики? В мире за период с 1971 по 2009 годы авторы исследования насчитали 4900 смертей. Причем авторы отмечают (и подтверждают ссылками на работы других исследователей), что линейная модель, которую они использовали для оценки имеет тенденцию значительно завышать результат в случае аварий с малой интенсивностью радиоактивного фона (все аварии кроме Чернобыля, включая Фукусиму и аварию на Трехмильном острове). Оценка в 4900 смертей может быть завышена на два порядка.

В общем я не знаю, как с такими цифрами можно ратовать против атомной энергетики. Разница в 370 раз - это как бы over дофига.

Read On →

Трофей

Сегодня наконец получил эмблему посвященную запуску Falcon Heavy Demo. Эмблема раза в полтора больше, чем обычно. В неё вплетены нити, слетавшие на одном из боковых бустеров:

\m/

Почему я поменял свое мнение о ядерной энергии

Интересное выступление Майкла Шелленбергера с TEDx: “Почему я поменял свое мнение о ядерной энергии”. Майкл, в прошлом горячий противник ядерной энергетики, объясняет почему ядерная энергия чище, чем энергия ветра и Солнца.

Несколько цифр:

  • На каждый киловатт энергии добытой с помощью солнечных панелей в атмосферу выбрасывается в 4 раза больше углекислого газа, чем на киловатт добытый на атомной станции.
  • В пересчете на киловатт, солнечные панели генерируют в 300 раз больше отходов, чем атомная энергетика.
  • 84% всей ионизирующей радиации, которой подвержен “средний человек” имеет естественное происхождение; 15% - приходится на медицину. На атомные аварии включая Чернобыль и Фукусиму приходится меньше 0.3%.
  • Использование атомной энергии сохранило жизни 1.8 миллиону человек (за счет снижения загрязнения окружающей среды). Сжигание угля, кстати, приводит к большему количеству радиоактивных выбросов, чем атомная энергетика.

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

Read On →

Как я провел прошлую пятницу

Расскажу как я провел прошлую пятницу. Провел я её пытаясь понять, почему простой как доска тест-кейс не работает.

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

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

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

Read On →

Skyrora

Ха. Прислал письмо рекрутер из британско-украинского ракетного стартапа Skyrora. Насколько я понимаю - деньги британские, а спецы южмашевские. Судя по сайту - вполне себе приличный ракетный стартап. Первая суборбитальная версия ракеты в разработке; вторая, орбитальная, в планах. Больше про компанию ничего не знаю, но все равно приятно, что в Украине есть такие стартапы. Было бы здорово, если бы у них получилось завоевать свое место под солнцем.

Рекрутер попросил пропиарить позицию Software Architect/C++ Developer, который будет заниматься системой управления ракеты-носителя. Позиция открыта в Днепре. Есть желающие дерзнуть? :-)

Read On →

SubGit

Получил непрошенное подтверждение тезиса про вред реализации веток через операцию копирования в Subversion. Вторую неделю бодаюсь с импортом SVN в Git с помощью SubGit. SubGit довольно неплохо с этим справляется. Особенно хорошо то, что он может постоянно синхронизировать SVN и Git, делая переход с одного на другой плавным и безболезненным. Он даже со всякими противоестественными манипуляциями со структурой веток в SVN репозитории справляется.

Но и на старуху найдется свой Раскольников. При создании одного из зеркал был указан не корневой адрес SVN, а https://foobar/svn/xyz. Зеркало прекрасно жило своей зеркальной жизню, пока не было обнаружено, что часть истории отсутствует. Для её восстановления родился план - заново импортировать все из корня (https://foobar/svn), а затем, уже на стороне Git, - сшить старую и новую историю вместе.

Отличный был план. И, что самое главное, и SubGit и Git все эти фокусы позволяют и поддерживают. За одним маленьким исключением… Как выяснилось, менять адрес с https://foobar/svn/xyz на https://foobar/svn категорически не получается. Вернее получается, но результат выходит как-то не очень. SubGit пытается импортировать историю (и находит все правильные коммиты, что характерно), но затем пытается заново засунуть их обратно в SVN. SVN кричит “что вы в меня это пихаете?” SubGit ужасно смущается, бормочет многоэтажные стек-трейсы в лог и заодно сносит master к праотцам.

Эх… Буду теперь с git replace возится…

Read On →

Трассировка команд в Git

Недавно разбирался почему клонирование большого репозитория в 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 проводит больше всего времени.

Read On →

Ошибки дизайна

А давайте про ошибки в дизайне поговорим. Тем более, что задним умом мы тут самые умные… Я в последнее время много играюсь с миграцией Subversion на Git и многие их косяки так в глаза и лезут.

Начнем с Subversion. Во времена массового перехода с CVS на Subversion, одним из главных аргументов “за” была поддержка директорий и операций копирования/перемещения в Subversion. Было видно, что разработчикам поддержка копирования очень пришлась по душе. Насколько пришлась, что и ветки в Subversion создаются через копирование, а структура репозитория по-умолчанию - это знаменитые три директории trunk, branches и tags.

Я догадываюсь как принималось это решение. Что-нибудь в духе “прикиньте, одна операция поддерживает и копирование, и ветки, и метки. Не нужно писать новый код для отдельного пространства имен веток. У нас уже есть этот код”. Но если пересчитать набитые шишки, то становится понятно, что решение было так себе… не очень… совсем хреновое решение это было, как оказалось.

Почему? А вот почему. Корректная работа с путями файлов, не смотря на кажущуюся простоту, - это постоянный источник багов. Казалось бы, что тут может быть сложного, но в результате получается как с указателями - нет, нет, а обязательно один потеряется. А Subversion заставляет с путями работать.

Скажем количество шагов в пути для trunk и branches/foobar разная. Это значит, что любой скрипт должен это корректно обработать. Не существует способа найти все ветки в произвольном репозитории. Операция копирования не обязательно означает создание ветки - а значит без какого-нибудь соглашения не обойтись. Ну а мы знаем насколько хорошо люди выдумывают совместимые стандарты.

Использование копирования для создания веток автоматически означает, что Subversion создать рабочую копию из людой директории в репозитории. Отличная оптимизация, когда нужно выкачать один файл, но, опять же, это означает, что скрипты не могут делать массы полезных предположений о структуре репозитория. Практически сразу же вся эта гибкость запрещается и создается wiki страничка “чекаут делается так, а ветки называются только так, а всех кто делает не так - прибью нафиг”.

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

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

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

Вы будете смеяться, но это реальная проблема. Особенно, когда мигрируешь с Subversion на Git.

Но ведь оно раньше работало. Я мог сделать так и так.

Полностью согласен, но, на кой, простите, вам это нужно делать именно таким способом?

Но ведь это единственный правильный способ. Мы так всегда делали…

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

Read On →