Мы написали абстракции над серилогом только для того чтобы иметь возможность настраивать декораторы для каждого типа сообщения. Какие-то события подробнее логгируются, кто-то добавляет специфические Enrichers при вызове. Есть некоторые костыли в прокидывании динамически формируемого набора Enrichers с доступом к контексту класа, передаем Func внутрь вызова логера. А так да, согласен, структурный логгер это то что нужно, после всех "старичков"...
Это в общем-то детали. Понимаю я кмк все правильно. Если уж хочется позанудничать — под одной этикеткой докера скрываются несколько вещей — докер клиент ( это тот бинарник который ваши команды из консоли отправляет докер демону), докер демон — это который крутит сервис отвечающий на запросы клиента и роутит команды к конкретному контейнеру (выполняет их внутри конкретного контейнера) а еще внутри демона есть engine который как раз непосредственно отвечает за виртуализацию изоляцию и доступ к непосредственно вызовам ядра некоей ОС.
То что вы описали — технология управления это только докер клиент.
Клиенту пофиг с каким из демонов разговаривать — поэтому они так прозрачненько для пользователя "смотрят" и на локальные и на удаленные контейнеры.
Реализация демона у всех будет своя. И не факт что демон будет крутить только то ядро, на которой работает ось в которой он запущен. Свое ядро конечно дешевле — нет прослойки виртуализации, но если линуксовое или нано-серверное будет стартовать за 1-2 секунды и занимать 200 мб Ram — почему бы и нет.
Даже более того — не удивлюсь если через некоторое время появится технология которая позволит крутить windows containers на Linux — клиент и интерфейс демона тот же, транслировать команды — умеют, а что конкретно там внутри крутится и как оно изолировано — это вообще детали реализации. Если клиент отправляет команду на которую демон и контейнер правильно реагируют — пофиг на чем они, LXC, или какой-нить jail или NTNanoKernel-v100500… Как раз под это дело и ядро от нано-сервера подойдет…
А уж как будет выполнен Engine каждой платформе — это уже дело платформы. В том числе, что мешает крутить 2 ядра в одном engine? Клиент может вполне неплохо обеспечить прозрачное управление группой контейнеров не вдаваясь в детали, что половина из них linux а половина windows, на одной машине… Просто для неродных контейнеров поднимается отдельное легкое ядро и ура...
Второй в паблике вроде еще не появился, и для него нужна сборка Win 10 инсайдерская вроде. То что появилось — с легковесной но виртуалкой, то что будет в Win 10 Anniversary — Hyper-V Containers & Windows Containers — это кстати тоже не докер, это именно виндовые контейнеры которые управляются через докер клиента, но ядро там будет от Win. Но обещают вкусно — HyperV с отдельным ядром запускается за секунды, Windows Container как и докер — ~subsecond. Да и вообще — ждем нано сервер который для облака и по заверениям чуть ли не в 180 метров влазит целиком...
Забавно, что никто не учитывает объем который займет такая формула. А он может быть куда больше чем сама закодированная информация. А еще такая формула будет уникальна для каждого произведения...
Ну давайте попробуем рассмотреть некий очень частный вырожденный случай…
Итак, закодируем фразу "Мама мыла раму" в виде последовательности функций которые из пустой строки "" сделают нам эту фразу:
В принципе если рассуждать в терминах выполнимости — да, это выполнимо, до какой-то степени. В терминах эффективности — не эффективно.
С переходом от примитивных к более сложным функциям — объем кода уменьшится, вычислительная сложность увеличится.
В какой-то момент вы достигнете некоего предела сложности и у вас получится вариация свертки — алгоритм компрессии. Потом вы обнаружите что разные алгоритмы дают разные результаты на разных наборах данных, начнете использовать их комбинации и придумаете какой-нибудь кодек для определенного типа данных.
Поздравляю, вы выиграли пиво.
Причем он настолько неудобный, что каждый раз когда пользуюсь — плююсь и подавляю желание его выключить.
Они присылают только СМС, только на 2 минуты и никак не запоминают такую сессию, т.е. надо логиниться каждый раз. иногда по 2-3 раза если есть редирект из старого интерфейса в новый. Любая задержка с доставкой смс — не пустили, логинитесь 2 раза подряд и смс пришли в другом порядке — не пустили… они очень нехорошие редиски...
ну в подкасте там тонко делали упор на "в текущей реализации", так что я думаю на следующем билде для крутости анонсов — пообещают что-нибудь интересное. А то как-то мало фич в этот раз выдали, несмотря на то что они крутые для разработчиков — не все счастливы...
Точно… Я сначала прочитал это как goLive на ASP.NET, но в блоге на мсдн упомянуты Go Live и на core.
Там конечно есть аккуратная такая оговорка, что со следующим RC ваша Go Live превращается в тыкву
The duration of this license for the RC1 last until the next release candidate or the completed release of ASP.NET 5 (called an RTM release) that is currently scheduled for Q1 2016.
обсуждали это уже, графику не делают, только то что использует системные вызовы ядра.
Более того, "в текущей реализации" это заточено только под разработчиков и чтобы у них была консоль с набором инструментов в дополнение к "неприжившемуся" posh, даже сам bash доступен только в 10ке.
Это, конечно, все говорят, но вот я жду кто первый поставит "nginx на прод" под Win10 и будет кричать что падает и тормозит. (troll)
Ох уж эти паникеры, что в твиттере изнылись, что на хабре. Вообще так в любом bleeding edge — someone's eyes should bleed.
Побуду КО:
Если вы начали делать ставку в продакшене (или хотя бы в проектах которые должны выйти в этом году) на Core — вы ССЗБ.
Если вы поверили что такой массивный re-write сложной платформы не обойдется без отставаний и лаж в датах — или вы очень неопытны или см ССЗБ.
Майкрософт конечно тоже хороши — выпустить RC и поломать все в RC2. Но такое случается, как и случаются перевранные даты. К этому индустрия как-то привыкла… А вот лететь на bleeding edge — это все оттого, что все как-то разом забыли о поломанных совместимостях и сильно расслабились, надеясь что agile всех спасет.
На самом деле неудобства наступают тогда, когда у вас объекты-данные, особенно если внешние или сгенерированные — добавление объекта вызывает изменения в нескольких местах. Когда количество таких объектов переваливает за первый десяток ( геометрия, например, или любая messaging-based система) — все это начинает вызывать ощутимый дискомфорт даже при чтении, не говоря уже про сопровождение.
Мы тоже используем подобный паттерн для обработки "сообщений" к актерам в Orleans например. И тоже перед этим прошли через стадии var x = input as Foo, и enum внутри объекта.
Я бы сказал что тут пример немного неудачный — паттерн хорошо работает когда у вас event-sourcing система, которая отправляет большое количество разных типов сообщений и бывает нужно получать сообщения не своего базового типа или даже просто иметь возможность очень быстро прикрутить новую обработку без изменения кода в 10 разных местах. Вот тогда этот паттерн очень помогает — просто заводите тип и пишете новый обработчик типа, остальное уже трогать не надо. А еще можно вкрутить централизованный логгинг, пре и пост-хуки и все это буквально в 1-2 линии кода
Например
public async Task ReceiveMsg(MessageEnvelopeBase item)
{
await validate(item as dynamic);
await preProcessing(item as dynamic);
await handle(item as dynamic);
await postProcessing(item as dynamic);
await logging(item as dynamic);
}
// тут определяем осмысленные методы для обработки базового класса MessageEnvelopeBase
// А потом по необходимости пишем обработчики валидаторы и хуки для конкретных сообщений,
// уже больше не трогая центральную точку входа ReceiveMsg(MessageEnvelopeBase item)
Не то что бы это какой-то rocket-science но код выглядит намного элегантнее. Да и разделение логики и данных хорошее — легко тестировать при помощи разных генераторов данных...
Хмм, если почитать комментарии к вопросу на ServerFault — автор — тот еще тролль — «я сделал dd но перепутал if и of».
Вообще afaik, после знатного вопроса про perl (еще с 2004 года) дистибутивы или явно запретили rm -rf / или требуют дополнительного ключа. А уж тем более такой дистриб как CentOS 7 (судя по тегам на вопросе на который ссылается Independent (http://serverfault.com/questions/769357/recovering-from-a-rm-rf)
У кого есть CentOS 7 в виртуалке под рукой — проверьте.
Дим, а поделиться этим легендарным кодом который теперь проверяет «все правильно и надежно» слабо? А то ты его в статье упоминаешь несколько раз, так что вполне ожидаемо что в конце будет — «А вот вам правильный надежный кода». А там только «Теперь у нас есть код...»
Кстати так и непонятно, почему решение с установкой всех промежуточных сертификатов вручную не работает — по логике все эти загрузки и крипто-кэши дергаются только тогда, когда нету сертификата с определенным thumbprint в хранилищах. А если ты его устанавливаешь при развертывании роли — какие могут быть проблемы? Можешь развернуто рассказать что там в деталях ломается, если вы разобрались так глубоко.
По логике — сертификаты из csdef устанавливаются и развертываются до развертывания кода на IIS, иначе он бы ругался на попытку binding к неустановленному сертификату — зачем бы IIS вообще ходить к центру сертификации если все есть локально ( если только не за проверкой, не отозваны ли какие-либо сертификаты в цепочке.
Там у большого количества утилит есть выдача в разные Trace и TraceSource, но собирать их надо заранее да и разбираться в них то еще удовольствие =(.
Но в целом — это все обычно есть, просто нет сильно удобных инструментов сбора и анализа.
Я бы столько всего в CI настроил, будь у меня бесконечное количество времени, благо умею. А по факту — если хочется что-то сделать за разумное время\усилия — не всегда стоит выбирать супер-мега-комбайны. Из личного опыта — банальный Парето тут работает — если простыми решениями за 20% времени можно решить 80% проблем — это надо сделать. оставшиеся 20% отнимут 80% времени и могут вообще никогда за время жизни проекта не всплыть.
StyleCop умер, хватит пинать дохлую лошадь. В репо есть какая-то странная активность, но из всего — просто перевыложен релиз 2013 года. Посмотрите хистори и увидите. Если хотите стиля — запиливайте CodeFormatter, хватит травить джуниоров в профессии.
Решарпер — я знаю что у кого-то из команды он есть. Опять же или не поймал или не прислушались.
И да, я сделал статью в том же стиле что и другие обзоры, потому что это наиболее удобный формат для описания результатов проверки. Возможно, не очень удачно выбрал время публикации, т.к. статей с проверками за последнюю пару недель действительно оказалось много.
С интеграцией сложно, но исходно так было у всех — и решарпер не сразу сделал тулзы для консоли. Посмотрим на темпы развития.
А вот про качество — я, лично, никогда раньше не видел чтобы статический анализатор умел отлавливать не просто синтаксис, а именно паттерны, конкретно у нас — double-locking pattern. И не просто обнаруживать, но и рассказывать, что там может быть не правильно (хотя если я правильно понял других гуру — volatile там не нужен (валидно для .NET) и это скорей всего FP у PVS-Studio)
Если вы покажете что решарпер или СонарКуб такое умеют и из коробки — следующую проверку и статью я, честно, напишу про них.
Отлично, а есть где-либо статьи где можно про все это прочитать и как сонар настроить без излишних приседаний, а то там installation manual такой, что отпадает все желание его попробовать?
Почитав что нужно чтобы запустить анализ солюшена при помощи SonarQube, я готов отказаться от заявления, что современные анализаторы использовать легко. Не все. Там один процесс инсталляции и требований к машине — на пару дней работы… А сравнение результатов с PVS будет действительно интересно почитать.
И еще на всякий случай повторюсь — я написал статью со стороны проекта Orleans, а не со стороны команды PVS студии, но вы скорей всего не читали даже первого абзаца, а просто зашли покидаться «ссылочками».
А что не так с качеством? Или это tall-poppy syndrome на хабре? И еще, я, например, могу понять причины возникновения такого количества статей — наконец-то вышел анализатор для C# кода и все кто его ждал — бросились проверять проекты и продукты. Что плохого в том, что качество опен-сорс проектов улучшилось?
А можно сделать команды создания образа не скриншотами а текстом, вроде ограничения на количество символов нет.
Мы написали абстракции над серилогом только для того чтобы иметь возможность настраивать декораторы для каждого типа сообщения. Какие-то события подробнее логгируются, кто-то добавляет специфические Enrichers при вызове. Есть некоторые костыли в прокидывании динамически формируемого набора Enrichers с доступом к контексту класа, передаем Func внутрь вызова логера. А так да, согласен, структурный логгер это то что нужно, после всех "старичков"...
Это в общем-то детали. Понимаю я кмк все правильно. Если уж хочется позанудничать — под одной этикеткой докера скрываются несколько вещей — докер клиент ( это тот бинарник который ваши команды из консоли отправляет докер демону), докер демон — это который крутит сервис отвечающий на запросы клиента и роутит команды к конкретному контейнеру (выполняет их внутри конкретного контейнера) а еще внутри демона есть engine который как раз непосредственно отвечает за виртуализацию изоляцию и доступ к непосредственно вызовам ядра некоей ОС.
То что вы описали — технология управления это только докер клиент.
Клиенту пофиг с каким из демонов разговаривать — поэтому они так прозрачненько для пользователя "смотрят" и на локальные и на удаленные контейнеры.
Реализация демона у всех будет своя. И не факт что демон будет крутить только то ядро, на которой работает ось в которой он запущен. Свое ядро конечно дешевле — нет прослойки виртуализации, но если линуксовое или нано-серверное будет стартовать за 1-2 секунды и занимать 200 мб Ram — почему бы и нет.
Даже более того — не удивлюсь если через некоторое время появится технология которая позволит крутить windows containers на Linux — клиент и интерфейс демона тот же, транслировать команды — умеют, а что конкретно там внутри крутится и как оно изолировано — это вообще детали реализации. Если клиент отправляет команду на которую демон и контейнер правильно реагируют — пофиг на чем они, LXC, или какой-нить jail или NTNanoKernel-v100500… Как раз под это дело и ядро от нано-сервера подойдет…
А уж как будет выполнен Engine каждой платформе — это уже дело платформы. В том числе, что мешает крутить 2 ядра в одном engine? Клиент может вполне неплохо обеспечить прозрачное управление группой контейнеров не вдаваясь в детали, что половина из них linux а половина windows, на одной машине… Просто для неродных контейнеров поднимается отдельное легкое ядро и ура...
Эхх мечты мечты...
Второй в паблике вроде еще не появился, и для него нужна сборка Win 10 инсайдерская вроде. То что появилось — с легковесной но виртуалкой, то что будет в Win 10 Anniversary — Hyper-V Containers & Windows Containers — это кстати тоже не докер, это именно виндовые контейнеры которые управляются через докер клиента, но ядро там будет от Win. Но обещают вкусно — HyperV с отдельным ядром запускается за секунды, Windows Container как и докер — ~subsecond. Да и вообще — ждем нано сервер который для облака и по заверениям чуть ли не в 180 метров влазит целиком...
Забавно, что никто не учитывает объем который займет такая формула. А он может быть куда больше чем сама закодированная информация. А еще такая формула будет уникальна для каждого произведения...
Ну давайте попробуем рассмотреть некий очень частный вырожденный случай…
Итак, закодируем фразу "Мама мыла раму" в виде последовательности функций которые из пустой строки "" сделают нам эту фразу:
В принципе если рассуждать в терминах выполнимости — да, это выполнимо, до какой-то степени. В терминах эффективности — не эффективно.
С переходом от примитивных к более сложным функциям — объем кода уменьшится, вычислительная сложность увеличится.
В какой-то момент вы достигнете некоего предела сложности и у вас получится вариация свертки — алгоритм компрессии. Потом вы обнаружите что разные алгоритмы дают разные результаты на разных наборах данных, начнете использовать их комбинации и придумаете какой-нибудь кодек для определенного типа данных.
Поздравляю, вы выиграли пиво.
Причем он настолько неудобный, что каждый раз когда пользуюсь — плююсь и подавляю желание его выключить.
Они присылают только СМС, только на 2 минуты и никак не запоминают такую сессию, т.е. надо логиниться каждый раз. иногда по 2-3 раза если есть редирект из старого интерфейса в новый. Любая задержка с доставкой смс — не пустили, логинитесь 2 раза подряд и смс пришли в другом порядке — не пустили… они очень нехорошие редиски...
ну в подкасте там тонко делали упор на "в текущей реализации", так что я думаю на следующем билде для крутости анонсов — пообещают что-нибудь интересное. А то как-то мало фич в этот раз выдали, несмотря на то что они крутые для разработчиков — не все счастливы...
Точно… Я сначала прочитал это как goLive на ASP.NET, но в блоге на мсдн упомянуты Go Live и на core.
Там конечно есть аккуратная такая оговорка, что со следующим RC ваша Go Live превращается в тыкву
обсуждали это уже, графику не делают, только то что использует системные вызовы ядра.
Более того, "в текущей реализации" это заточено только под разработчиков и чтобы у них была консоль с набором инструментов в дополнение к "неприжившемуся" posh, даже сам bash доступен только в 10ке.
Это, конечно, все говорят, но вот я жду кто первый поставит "nginx на прод" под Win10 и будет кричать что падает и тормозит. (troll)
Ага, первый RC был неудачной идей, хотя они вроде и GoLive лицензий с ним не давали...
Ох уж эти паникеры, что в твиттере изнылись, что на хабре. Вообще так в любом bleeding edge — someone's eyes should bleed.
Побуду КО:
Если вы начали делать ставку в продакшене (или хотя бы в проектах которые должны выйти в этом году) на Core — вы ССЗБ.
Если вы поверили что такой массивный re-write сложной платформы не обойдется без отставаний и лаж в датах — или вы очень неопытны или см ССЗБ.
Майкрософт конечно тоже хороши — выпустить RC и поломать все в RC2. Но такое случается, как и случаются перевранные даты. К этому индустрия как-то привыкла… А вот лететь на bleeding edge — это все оттого, что все как-то разом забыли о поломанных совместимостях и сильно расслабились, надеясь что agile всех спасет.
На самом деле неудобства наступают тогда, когда у вас объекты-данные, особенно если внешние или сгенерированные — добавление объекта вызывает изменения в нескольких местах. Когда количество таких объектов переваливает за первый десяток ( геометрия, например, или любая messaging-based система) — все это начинает вызывать ощутимый дискомфорт даже при чтении, не говоря уже про сопровождение.
Мы тоже используем подобный паттерн для обработки "сообщений" к актерам в Orleans например. И тоже перед этим прошли через стадии var x = input as Foo, и enum внутри объекта.
Я бы сказал что тут пример немного неудачный — паттерн хорошо работает когда у вас event-sourcing система, которая отправляет большое количество разных типов сообщений и бывает нужно получать сообщения не своего базового типа или даже просто иметь возможность очень быстро прикрутить новую обработку без изменения кода в 10 разных местах. Вот тогда этот паттерн очень помогает — просто заводите тип и пишете новый обработчик типа, остальное уже трогать не надо. А еще можно вкрутить централизованный логгинг, пре и пост-хуки и все это буквально в 1-2 линии кода
Например
Не то что бы это какой-то rocket-science но код выглядит намного элегантнее. Да и разделение логики и данных хорошее — легко тестировать при помощи разных генераторов данных...
Вообще afaik, после знатного вопроса про perl (еще с 2004 года) дистибутивы или явно запретили rm -rf / или требуют дополнительного ключа. А уж тем более такой дистриб как CentOS 7 (судя по тегам на вопросе на который ссылается Independent (http://serverfault.com/questions/769357/recovering-from-a-rm-rf)
У кого есть CentOS 7 в виртуалке под рукой — проверьте.
Кстати так и непонятно, почему решение с установкой всех промежуточных сертификатов вручную не работает — по логике все эти загрузки и крипто-кэши дергаются только тогда, когда нету сертификата с определенным thumbprint в хранилищах. А если ты его устанавливаешь при развертывании роли — какие могут быть проблемы? Можешь развернуто рассказать что там в деталях ломается, если вы разобрались так глубоко.
По логике — сертификаты из csdef устанавливаются и развертываются до развертывания кода на IIS, иначе он бы ругался на попытку binding к неустановленному сертификату — зачем бы IIS вообще ходить к центру сертификации если все есть локально ( если только не за проверкой, не отозваны ли какие-либо сертификаты в цепочке.
Но в целом — это все обычно есть, просто нет сильно удобных инструментов сбора и анализа.
Первые три ссылки я знаю:
FxCop используется в Orleans (через www.nuget.org/packages/Microsoft.CodeAnalysis.FxCopAnalyzers), эпичный баг он не поймал. Или не-донастроен как надо или к его предупреждениям не прислушались.
Еще есть www.nuget.org/packages/Microsoft.CodeAnalysis
StyleCop умер, хватит пинать дохлую лошадь. В репо есть какая-то странная активность, но из всего — просто перевыложен релиз 2013 года. Посмотрите хистори и увидите. Если хотите стиля — запиливайте CodeFormatter, хватит травить джуниоров в профессии.
Решарпер — я знаю что у кого-то из команды он есть. Опять же или не поймал или не прислушались.
И да, я сделал статью в том же стиле что и другие обзоры, потому что это наиболее удобный формат для описания результатов проверки. Возможно, не очень удачно выбрал время публикации, т.к. статей с проверками за последнюю пару недель действительно оказалось много.
С интеграцией сложно, но исходно так было у всех — и решарпер не сразу сделал тулзы для консоли. Посмотрим на темпы развития.
А вот про качество — я, лично, никогда раньше не видел чтобы статический анализатор умел отлавливать не просто синтаксис, а именно паттерны, конкретно у нас — double-locking pattern. И не просто обнаруживать, но и рассказывать, что там может быть не правильно (хотя если я правильно понял других гуру — volatile там не нужен (валидно для .NET) и это скорей всего FP у PVS-Studio)
Если вы покажете что решарпер или СонарКуб такое умеют и из коробки — следующую проверку и статью я, честно, напишу про них.
PS: И мне не плевать, но вы же меня лучше знаете…
И еще на всякий случай повторюсь — я написал статью со стороны проекта Orleans, а не со стороны команды PVS студии, но вы скорей всего не читали даже первого абзаца, а просто зашли покидаться «ссылочками».