Мне наоборот мучительно претит снобизм а-ля «молодой человек, вы понимаете, что шампанское — это только произведенное в...».
Это так, к сожалению, обычно и выглялит :D Но иногда таки нужно это объяснить, и вот тут ты сам начинаешь ходить по тонкому льду, пытаясь не провалится в бессмыссленный пафос. :D
Ну я занудствовал в разрезе истории, чтобы было понятно. Полагаю, что далеко не все имеют нужный набор знаний, а историю донести хотелось :)
Ну а по факту конечно речь идет о международной торговле, что делается внутри конкретной страны никому дела нет. Но, например, мне это (когда шампанским называют все подрят) режет слух и обычно говорит о уровне подготовки человека в этих вопросах.
Хотя сейчас даже крупные винопроизводители уже стали потихоньку двигатся в правильном направлении и сами доносят до людей правильные названия.
Ну а поповоду слов-марок на самом деле это довольно большая беда, я видел совершенно безумный вгляд у людей, которые в первые видят именно Xerox :D
А про российское виноделие есть две совершенно фиерические байки, обычно связанные с Львом Голициным, человеком, несомненно, сделавшим очень много для виноделя страны в свои годы. Немного веселья для сообщетсва :)
Минутка занудства: Шампань и Коньяк защищенные имена и могут производится только во Франции в соответсвующих регионах. Все остальное официально — просто игристое вино и бренди (или другие имена, придуманные в других странах).
Очень хотелось написать художественный текст (а я слышал эпичные истории, можно расписывать на несколько печатных листов), но не люблю длинные полотна, поэтому чуть более структурно, думаю каждый может составить историю лично для себя :)
Первая байка — про игристое.
Лев Голицын (заменяем на любого другого видного деятеятеля, в комментаниях выше есть пример с купцами Елисеевыми) появляется в Крыму/Краснодарском крае/любом винном регионе России (заменяется локальным геоположением рассказчика)
Видит потенциал земли, высаживает виноград/Находит заброшенные виноградки и возраждает их
Производит вино, затем игристое (диапазон времени обычно указывается в диапазоне от 3 до 10 лет)
Игристое анонимно отправляется на Всемирную выставку в Париже (обычно называют 1900 год как самый красивый, но это не принципиально)
Игристое насколько нравится французам, что выигрывает град при и получает эксклюзивные права называться Шампанским.
Вторая история — про Коньяк.
На самом деле история максимально короткая :D Все пункты те же самые, заменяются только имена (хотя про Голицына тоже есть), игристое на бренди, а Шампанское на Коньяк. Слышал, что такие же байки травят в Дагестане, но это только на правах чужих слов.
В Поргуталии, как уже писали выше рассказывают историю примерно как (опуская детали) убрали на хранение под крышу (заметьте не на прямое солнце) и забыли на несколько лет. Нашли, открыли — и вот оно.
История про корабли обыно рассказывается в разрезе портвейнов и путешествия вина из Порту в Голландию (документально подтвержденные факты).
Беда и огорчение конечно, очень жаль, Mercurial мне идеалогически нравился больше чем git. Получается публичных хостингов с hg не осталось?
Уже представлю свою миграцию 20+ проектов на hg, связанных между собой подрепозиториями, в git… Ну и хостинг конечно после этого будет уже не BitBucket, хоть с ним было и неплохо все эти годы
Если не вдаваться в детали — git позволяет сделать к кодом что угодно. Mercurial в этом плане гораздо строже и дает по рукам сразу если вдруг что. А именно это важно в энтерпрайзе в первую очередь.
Я в целом не хочу сказать что git плох — это отличная и гибкая система. Как писали выше — основная ее проблема в том, что она слишком гибкая и для использования ее в командой разработке гарантировано необходимы дополнительные сервисы аля github.
Ну нас вся основная документация живет вместе с проектом в mercurial/git на bitbucket. Или в отдельных репозиториях. Местного функционала pull request + возможность комментировать прямо в коммитах на конкретные строчки хватает за глаза.
В моем представлении это все — таки функционал контроля версий, а не системы сборки документации.
Это следует только приветствовать:) Я всеми частями тела за plaintext документирование. Чтобы не устраивать к комментах байки у костра на тему «как сверстать прилично выглядящую доку в asciidoc и не умереть» скажу только, что для простых документов типа заметок или «статей» лучше брать asciidoctor — написан на ruby, ставится и работает из коробки одной командой.
Как только встает вопрос «а давайте сделаем Руководство Пользователя/ТЗ по ГОСТ/любой многостраничный документ с требованием к оформлению и печати» придется идти к оригинальному asciidoc и бекэнду в виде docbook+pdf. А там еще ряд веселья по настройке. pdf, повторюсь, отдельная боль, избегайте ее по возможности в начале:)
На момент годичной давности asciidoctor имел зачатки pdf рендера в виде отдельного модуля, но на что — то большее, чем простой набор страниц, он не был способен.
Если вдруг будут нужны какие — то детали по системе или, может быть, примеры документаций — стучитесь в личку, помогу чем смогу :)
Сам сейчас, подготавливаю материалы для презентации в нашей группе разработке, о ведении технической документации для проекта. (asciidoc + plantuml)
Перевел всю тех документацию по актуальным проектам на эту схему года 3 — 4 назад. Если не ударяться в дизайн схем (хотя он вроде бы настраиваемый), то инструмента вполне достаточно для работы.
Несомненно, отдельное веселье собирать для документации прилично выглядящий pdf, но это тема большой и очень нецензурной статьи.
На всякий случай добавлю, что с использованием плагина для asciidoc код plantuml можно писать прямо в тексте документации (а не генерить картинки отдельно и вставлять ссылками, как делает автор поста)
Спасибо за статью, полезно посмотреть что и как, у самого руки не так часто доходят:) В дополнение к статье добавлю свеженькое видео от Jason Turner на схожую тему — Negative Cost Structs
Хоть и не принято на Хабре писать неинформативные комменты типа «спасибо», но все — таки — спасибо за труд и статью, читается на одном дыхании! Давно посматриваю на Исландию одним глазом, но все не решиться никак…
Это было или слишком давно (хотя я, вроде, на AsciiDoc уже много лет) или Вы что — то путаете. Прекрасные ссылки на что угодно, единственное для «что угодно» нужно делать именованный якорь.
Добавлю про AsciiDoc. У себя в работе применяю ее как систему генерации документов для программ (хелп + инструкция пользователя). Для инструкций используем бекэнд AsciiDoc в DocBook + FOP, на выходе вполне сносный pdf с оглавлением и всем прочим.
Да, кроме официальных тулсетов есть реализация AsciiDoc на Ruby: asciidoctor. Со сложными документами там пока неважно (приемлемый pdf получить можно, но гибкости в настройке не хватает), но гораздо проще в установке и использовании для простых целей (небольшие статьи, одностраничники, простые pdf)
Внезапно осознал свои 34 года и 19 лет опыта с путем Паскаль -> дельфи -> C++ по «Энциклопедии профессора Фортрана». Спасибо за это, пойду перечитаю, дома где — то бумажная хранится :)
Ради интереса сходил проверить как там сейчас дела (обычно для версионности все — таки использую что — нибудь посерьезней) — превью и версии файлов есть (можно ручками посмотреть и восстановить выбранную), но встроенного дифа и сравнения версий так и не появилось, что есть печаль.
Одно время существовала Pixelapse — система типа Google/Yandex Drive, но с версионностью и поддержкой превьюшек. Более того — организации фалов в проекты.
Но с этого года они перешли под крыло Dropbox. В результате на текущий момент Dropbox обещает поддержку превью для psd и прочих радостей. Также он обладает встроенной версионностью файлов.
Да, бесплатного места не очень много, но рекомендую попробовать на досуге :) Но для чего — то более серьезного конечно нужно начинать работать с какой — нибудь полноценной системой контроля версий.
Проверено неделю назад, решение работоспособно. Особенности — используется rsync вместо маунта образа диска, что, при наличии прямой сети с малинкой, в разы ускоряет деплой и модулей Qt и, собственно, своих приложений.
Кто — то спрашивал про производительность:
демо виджет OpenGL от разработчиков Qt отрабатывает на 60 fps без проблем.
собственное приложение на виджетах + несколько фреймов на Qml с Osm картами — тормозов также не замечено.
Тоже подкину ссылочку. Не совсем шоу, но все — таки. Ребята из Node устраивают игры сами с собой. Да, лица менее известные, но сами истории, декорации, модели и съемки (с какого — то момента) вполне смотрибельны. Нужный плейлист на канале
Это так, к сожалению, обычно и выглялит :D Но иногда таки нужно это объяснить, и вот тут ты сам начинаешь ходить по тонкому льду, пытаясь не провалится в бессмыссленный пафос. :D
Ну а по факту конечно речь идет о международной торговле, что делается внутри конкретной страны никому дела нет. Но, например, мне это (когда шампанским называют все подрят) режет слух и обычно говорит о уровне подготовки человека в этих вопросах.
Хотя сейчас даже крупные винопроизводители уже стали потихоньку двигатся в правильном направлении и сами доносят до людей правильные названия.
Ну а поповоду слов-марок на самом деле это довольно большая беда, я видел совершенно безумный вгляд у людей, которые в первые видят именно Xerox :D
Минутка занудства: Шампань и Коньяк защищенные имена и могут производится только во Франции в соответсвующих регионах. Все остальное официально — просто игристое вино и бренди (или другие имена, придуманные в других странах).
Очень хотелось написать художественный текст (а я слышал эпичные истории, можно расписывать на несколько печатных листов), но не люблю длинные полотна, поэтому чуть более структурно, думаю каждый может составить историю лично для себя :)
Первая байка — про игристое.
Вторая история — про Коньяк.
На самом деле история максимально короткая :D Все пункты те же самые, заменяются только имена (хотя про Голицына тоже есть), игристое на бренди, а Шампанское на Коньяк. Слышал, что такие же байки травят в Дагестане, но это только на правах чужих слов.
История про корабли обыно рассказывается в разрезе портвейнов и путешествия вина из Порту в Голландию (документально подтвержденные факты).
Уже представлю свою миграцию 20+ проектов на hg, связанных между собой подрепозиториями, в git… Ну и хостинг конечно после этого будет уже не BitBucket, хоть с ним было и неплохо все эти годы
Я в целом не хочу сказать что git плох — это отличная и гибкая система. Как писали выше — основная ее проблема в том, что она слишком гибкая и для использования ее в командой разработке гарантировано необходимы дополнительные сервисы аля github.
В моем представлении это все — таки функционал контроля версий, а не системы сборки документации.
Как только встает вопрос «а давайте сделаем Руководство Пользователя/ТЗ по ГОСТ/любой многостраничный документ с требованием к оформлению и печати» придется идти к оригинальному asciidoc и бекэнду в виде docbook+pdf. А там еще ряд веселья по настройке. pdf, повторюсь, отдельная боль, избегайте ее по возможности в начале:)
На момент годичной давности asciidoctor имел зачатки pdf рендера в виде отдельного модуля, но на что — то большее, чем простой набор страниц, он не был способен.
Если вдруг будут нужны какие — то детали по системе или, может быть, примеры документаций — стучитесь в личку, помогу чем смогу :)
Перевел всю тех документацию по актуальным проектам на эту схему года 3 — 4 назад. Если не ударяться в дизайн схем (хотя он вроде бы настраиваемый), то инструмента вполне достаточно для работы.
Несомненно, отдельное веселье собирать для документации прилично выглядящий pdf, но это тема большой и очень нецензурной статьи.
На всякий случай добавлю, что с использованием плагина для asciidoc код plantuml можно писать прямо в тексте документации (а не генерить картинки отдельно и вставлять ссылками, как делает автор поста)
Да, кроме официальных тулсетов есть реализация AsciiDoc на Ruby: asciidoctor. Со сложными документами там пока неважно (приемлемый pdf получить можно, но гибкости в настройке не хватает), но гораздо проще в установке и использовании для простых целей (небольшие статьи, одностраничники, простые pdf)
Но с этого года они перешли под крыло Dropbox. В результате на текущий момент Dropbox обещает поддержку превью для psd и прочих радостей. Также он обладает встроенной версионностью файлов.
Да, бесплатного места не очень много, но рекомендую попробовать на досуге :) Но для чего — то более серьезного конечно нужно начинать работать с какой — нибудь полноценной системой контроля версий.
Добавлю для истории ссылку по на последний корректный мануал про кросскомпиляции и сборке Qt 5.x для RPi2
https://wiki.qt.io/RaspberryPi2EGLFS#Step_by_step
Проверено неделю назад, решение работоспособно. Особенности — используется rsync вместо маунта образа диска, что, при наличии прямой сети с малинкой, в разы ускоряет деплой и модулей Qt и, собственно, своих приложений.
Кто — то спрашивал про производительность:
Нужный плейлист на канале