• Использование Visual Studio Application Insights — опыт инженера по тестированию
    0
    Сценарий очень простой — есть Worker Role, помимо всего остального, внутри ее крутится OWIN self-hosted WebAPI. Этот webapi используется как в Angular так и в настольном приложении. Хочется с него собирать телеметрию которая специфична для web — время от начала запроса до first-byte-sent, корреляцию по пользователю — какие запросы от него приходят, как активно он ходит по сайту итд. Ну и видеть статистику по клиентам, браузерам, ОС (это для web запросов, для desktop еще не думали что хотим видеть, но как минимум версию приложения, скорей всего X-Version или что-то такое будем слать).
    В общем ничего невозможного нету, но есть одна загвоздка, как я понял — есть nuget package для всего что хостится на IIS — т.е. в виде HttpHandler, вроде есть не очень понятная бета версия для очередной беты asp.net 5, реализации в виде owin middleware ( для self-hosted и non-IIS серверов) — я не нашел и судя по вот этому ответу от сотрудника MSFT — не сильно планируется.

    Я понимаю что можно написать свою middleware в которой надо дергать AI напрямую, через TelemetryClient или если чуток получше — через serilog +serilog.AI sink. Но так можно логгировать куда угодно, и потом долго и мучительно настраивать диаграммы и чарты в каком-нибудь портале. Но тогда зачем грызть гранит AI.

    Value Application Insights для меня в том что это настроенная связка — клиент который знает что собирать для web запросов и сервер с уже настроенным набором стандартных диаграмм и correlation id. И вот пока не понятно, как задействовать это на полную катушку, а не как «тупой логгер». Может я что-то не понимаю и можно взять версию для ASP.NET 5 и вкрутить в OWIN pipeline? Вроде как сигнатуры middleware похожи, но все- таки отличаются немного (поправьте если я тут не прав, глубоко в asp.net vNext еще не смотрел)…
  • Использование Visual Studio Application Insights — опыт инженера по тестированию
    0
    А скажите, планируется ли поддержка AI в OWIN-Self Hosted сценариях. А то хочется чтобы была диагностика такая же как и для IIS, а не вручную вызывать API во всяких фильтрах. Даже для беты ASP.NET 5 уже есть, а для такого стабильного стека как OWIN — нету.
  • Как сделать красивую документацию для Web API, за которую будет не стыдно
    +5
    А вас не смущает что внешняя красивость достигается через кучу кастомных тегов и описаний в коде? Почему никто не думает о читабельности кода? тот же Swagger — просто стандартный формат описания, из него можно и документацию сгенерить красивую (генераторов статичного красивого html — завались) так и сгенерить автоматический прокси для вызова этого api в коде.

    Внизу уже упомянули что написание отдельной документации для каждого метода, помимо стандартной — утомляет. Это на самом деле — проблема в long-run. Когда проект только начинается — все радостно пишут документацию, когда ближе к окончанию, или даже через полгода — все уже начинают забивать на документацию. Хорошо еще если есть настрой написать стандартную доку, не говоря уже про специальную отдельную доку для генератора. В итоге — гладко было на бумаге…
    Мне больше импонирует подход swagger (вернее разных пакетов генерящих swagger описание по коду) — выяснить максимум о коде и представить это в виде стандартного описания. А уж пользователь-разработчик сам решит что ему генерить — красивую документацию или прокси или CRUD интерфейс.
  • Пишем Custom MSBuild Task для деплоя (WMI included)
    0
    А с версии 4.0 — можно писать вообще inline — msdn.microsoft.com/en-us/library/dd722601.aspx, мсбилд сам его скомпилирует и подключит в контекст скрипта.
    За примером можно сходить сюда.

  • Как работает API нашего IaaS-провайдера
    +1
    Это не совсем приложение, это довольно популярный формат описания api, который позволяет автоматически генерировать запросы в правильном формате. Посмотрите swagger.io
    Например на .NET для генерации интерфейса типа вот такого petstore.swagger.io к WebAPI нужно просто добавить пакет swashbuckle, и все.
    Для генерации клиента к чужому api который имеет описание в формате swagger — вызвать утилиту autorest с парой параметров — и она сгенерирует строго типизированные классы и методы на C#.

    Если пользовались раньше WSDL — это все то же самое только без SOAP & XML, и все кросс-платформенно для REST API

    Помимо этих плюшек, большое количество приложений и сервисов поддерживают Swagger, например PostMan, Runscope и другие…
  • Как работает API нашего IaaS-провайдера
    +1
    Мне кажется большинство таких постов уйдут в прошлое тогда, когда компании начнут использовать swagger для описания своих REST API. А из него и документацию можно сгенерить, и клиентов на разных языках, и просто фронтэнд чтобы поиграть с вызовами. Swagger это прекрасный аналог WSDL для RESTful api

    У вас есть?
  • Обмен сообщениями в Microsoft Azure, или Как общаться в облаках
    +1
    Ответ на ваш вопрос — если сообщение не помещается в 64Кб — стоит задуматься над архитектурой и тем что вам слишком много данных нужно передавать. Сообщение это больше команда — краткое указание. А по факту — сложите ваши большие данные в блоб и в сообщение засуньте ссылку по которой блоб можно скачать или его ID.

    И еще — 20 000 сообщений в секунду для очереди — это не опечатка? вот тут msdn.microsoft.com/library/azure/hh697709.aspx говорят только про 2000 сообщений в секунду на очередь, 20 000 это вроде предел на весь аккаунт…
  • Обзор ServiceStack.OrmLite — micro-ORM для .NET
    0
    От Object-Relational Mapper — да, мне необходим именно маппер, потому что все остальное оно делает хуже чем нативный интерфейс.
    Ну и удобный способ исполнять мои запросы на языке базы данных. А не универсальный комбайн-переводчик с свистоперделками. Уже все вроде наелись с EF и признались — создание суррогатных языков, пусть даже с автокомплитами и все такое — всегда генерит худший результат (и если смотрели в профайлере — сильно худший) чем обычный SQL, который lingua franca реляционных БД.
  • Обзор ServiceStack.OrmLite — micro-ORM для .NET
    +1
    Что то POCO ( plain old class objects) тут и не пахнет, все эти аттрибуты и navigation property засоряют модель. Пример работы с POCO — PetaPoco, берем любой класс и в него маппим результат SQL запроса. И не надо fluent городить — SQL для общения с базой — самый правильный и родной вариант.
  • Visual Studio Extensibility. Часть первая: MSBuild
    0
    Эти системы (я про fake &psake) направлены на другое — это просто обертка, которая прячет от вас функциональную часть сборки. Мсбилд — возможность заглянуть и понять что происходит под капотом. Просто не понимая что внутри — невозможно модифицировать систему чтобы она делала что нужно вам, всегда будут ритуальные пляски — а вот такой плагин добавим, а вот такой модуль, а еще их надо вызвать в строгом порядке, а между вызовами очистить вот эту папку. Это называется культ карго.

    Да, мсбилд использует не самый дружественный синтаксис, да, весь каскад импортов и переопределенных свойств может вызвать мигрень, да, половина таргетов для не основных продуктов написана криворукими идиотами, но понимание самой системы сборки дает вам знание о том, что происходит когда вы вызываете msbuild ./mylib.csproj. А также вы знаете как повлиять на это, в любой билд системе. И это кстати совсем не хардкор 8-)

    PS про TFS — ппкс, и спасибо за наводку, как то пропустил что появились детали 2015…
  • Visual Studio Extensibility. Часть первая: MSBuild
    –1
    А еще есть TFS — вообще гуй есть и можно в workflow в drag-and-drop стиле редактировать, не то что ваши тестикулярные скриптовые языки. Типа ура…

    Обычно, необходимость в скриптовых и императивных языках возникает когда в команде многие не способны ( в силу ограниченности кругозора) понимать XML мсбилда и его декларативность. Ну это в общем проблемы команды, а не мсбилда. Хоть на batch пишите, только все эти обвязки — как забивать гвозди микроскопом — от непонимания.
  • Visual Studio Extensibility. Часть первая: MSBuild
    +1
    Ок. т.е. получается в данном случае они не только используют свойства как способ хранения, но и используют такой же синтаксис? Или все-таки они заимствуют синтаксис из мсбилда, потому что само строковое значение будет интерпретироваться\разворачиваться не студией, а мсбилдом? Кто их разворачивает, эти «макросы»? Если второе — то все-таки это сущность билда, а не макрос студии.
  • Visual Studio Extensibility. Часть первая: MSBuild
    +1
    Классно, спасибо за пояснения, как работает мсбилд я знаю неплохо, а вот такие детали про проектные системы и их проекции на систему сборки — очень полезны.
    Кстати такой технический вопрос — можно ли убедить студию что ей нужно отрисовать содержимое файла Х как набор свойств проекта в GUI (т.е. убедить ее в том, что «проектная система — C#, но вот тут отрисуй пожалуйста используя другой компонент, из CPS» ), или это все жестко связано с расширениями и внутренними Guid? А то я сейчас покопался — и обнаружил что куда-то пропал графический редактор свойств в С#, похоже раньше это мне какое-то расширение делало… Не то что бы очень надо, просто любопытно, можно ли так обмануть систему…
  • Visual Studio Extensibility. Часть первая: MSBuild
    0
    и да, проект становится проектом «студии» если у него соответствующий ProjectGuid, а не невинные импорты
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
    
  • Visual Studio Extensibility. Часть первая: MSBuild
    +1
    То, что они где-то находятся в IDE — не определяет их предназначение. Вы такими выдуманными обозначениями запутаете читателей еще больше, а потом опять будем видеть жалобы на то, что кто-то потратил уйму времени (как автор) просматривая targets мсбилда и все равно ничего не понял.

    Да, статью я читал. На соглашения я указал потому, что если им следовать — можно получить некоторые встроенные в msbuild(и поставляемые targets) ништяки. Если не следовать — можно сделать все то же самое, но руками и через «мучения».
  • Visual Studio Extensibility. Часть первая: MSBuild
    +2
    $(BlaBlaBla) — это не макрос, это способ адресации Свойства (Property) в MSBuild.

    Вообще все остальное, включая ваши наборы свойств выглядит как мало относящееся к MSBuild. Props и Targets это просто «соглашения», можете именовать как угодно, но студия любит их и например может дать возможность редактировать ваши собственные props в окне свойств проекта.

    int19h А в чем отличия этой Common Project System от стандартной системы сборки проектов в MSBuild? И почему декларативное описание свойств не будет работать? Мсбилд всегда так работает, ну или я не правильно понимаю ваше высказывание.
  • Entity Framework: повышаем производительность при сохранении данных в БД
    0
    Поддержу предыдущего комментатора, по работе вынужден сталкиваться с EF, даже 6тая версия — какие-то наборы архитектурных костылей. Когда была возможность выбирать — использовал PetaPoco и Даппер — ничуть не жалею. Вообще громоздить абстракцию поверх и так уже абстрактного языка SQL — это коряво. А все эти трекинги объектов и контексты — ну не знаю, для меня это издевательство и переусложнение простой задачи — прочитать данные или записать данные. SQL надо знать и надо им пользоваться, а не придумывать велосипеды чтобы его избежать. А аргументы про то как легко сменить базу данных когда у вас есть абстракция — вот честно, кто хоть раз на больших проектах менял базы данных ???
  • Jump Start в PowerShell (часть II)
    +1
    Для JumpStart будет очень полезно, если вы расскажете в подробностях про Pipeline PoSH, ибо очень важная и большая часть.
    И как это все интегрированно с .NET тоже полезно знать (но это уже не совсем фундаментальные основы).

    Продолжайте, неплохие материалы в итоге получатся.
  • Jump Start в PowerShell (часть II)
    +1
    ну не то что бы совсем экспертом, можно вполне не программировать под .NET, но успешно пользоваться PoSH. Хотя не отрицаю — знание .NET хорошо помогает, ибо по сути это скриптовый язык для .NET =)
  • Подробное описание возможностей разработки с Microsoft Azure Cloud Services
    +1
    Откуда ж вы, в Microsoft, копируете эту несусветную глупость про то, что Staging окружение надо использовать для тестирования ??? У вас там что где-то есть список официально распространяемых неработающих и идиотских практик?

    НЕ используйте staging для тестов, это не только физически «трудно» в силу таких очевидных косяков как отсутствие правильных bindings на сайтах в staging — ваши сайты в staging получают те же bindings что и продакшен, а реальный домен — guid.cloudapp.net, т.е. если у вас binding не *:80\443 — без шаманских плясок вы не достучитесь до своих сайтов в staging слоте.

    И заканчивая тем, что при активном стейджинге он у вас будет таскать сообщения из очереди, «тестовый» слот будет писать в продакшен базу, блобы и таблицы. А если вы используете миграции Entity Framework (отдельные грабли) — еще и получите измененую Production базу и с большой вероятностью — P1 Incident в придачу.

    Забудьте вы про тестирование в Staging пожалуйста, Staging предназначен для уменьшения времени простоя и гладкого обновления — загрузили новую, оттестированную версию в стейджинг, прогрели, убедились что все инстансы запустились и работают как надо — переключили ее в продакшен, старую остановили.

    За все остальные варианты использования Staging — бейте своих разработчиков по рукам стальной линейкой, чтобы неповадно было.

    А Microsoft должно быть стыдно, что пишете такие практики.

    И еще маленькое имхо — думаю что Cloud Services будут выводиться из обращения — во первых на смену им пришли легковесные websites+webjobs, во-вторых грядет Docker — куда более правильная идея контейнерных приложений.
  • Ультра-легкий переключатель раскладки клавиатуры
    +1
    Так было раньше. И даже это не совсем так — студия все равно загружала в себя движок мсбилда и прогоняла все через его пайплайн, за исключением пары проектов (которые уже морально устарели имхо). Т.е. тогда было 2 хоста для движка — студия и msbuild.exe. Это приводило к тому, что окружение проектов отличалось — студия подсовывала кучу переменных окружения.

    Но сейчас это не так — студия, по крайней мере современные ее версии, собирает проекты при помощи честного msbuild.exe, причем можно увидеть отдельные параллельные процессы msbuild.exe запущенные студией с определенными параметрами.

    Да, солюшен это не мсбилд скрипт, но его преобразование происходит в msbuild.exe, а не в devenv.exe

    В итоге — всё собирается одним и тем же движком, просто вызывается(лся) этот движок из разных врапперов — msbuild.exe и devenv.exe. Теперь один враппер вызывает другой, вместо того чтобы хостить Core engine в себе. Это и есть принципиальная разница?

    PS: Господа минусующие, зачем портите дискуссию?
  • Ультра-легкий переключатель раскладки клавиатуры
    –1
    Вообще не такие уж и разные.
    За исключением нескольких проектов, студия для сборки не нужна, но возможно не все разработчики это знают.
  • Ультра-легкий переключатель раскладки клавиатуры
    +1
    А собрать мсбилдом из консольки не позволяют убеждения?
  • Статистика российских IT-специалистов на stackoverflow.com и github.com
    +16
    Да, менталитет. Сам еще тоже не до конца избавился от такого мышления.

    На самом деле взгляд на такие вещи как «делиться знаниями» или «сделать хорошо другим» за пределами России довольно сильно отличается от «привычного». Тут принято делиться знаниями (конечно не всеми подряд) потому что это не только поднимает вашу собственную репутацию в сообществе, но и в целом — улучшает само сообщество. Быть умным в компании слабых разработчиков — не интересно. Да, это прям полирует личное эго, но ты все равно понимаешь — один ты не вытянешь проект, а коллеги — ну слабоваты, просто потому что не знают, не умеют и вообще — все делают не так. В итоге — вы круты, они лохи, но проект получается говенный просто потому, что все за ними вы исправить не можете.

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

    Точно также и кодом\знаниями делиться. Вы делитесь — вас замечают, репутация растет, люди про вас слышат и приходят к вам — есть возможность набрать в компанию хороших специалистов, а не остатки на рынке.

    Фундаментальное отличие — тут это работает, тут люди ценят репутацию, тебя помнят, делаешь ли ты хорошее или плохое. И да — тут позвонят по всем предоставленным контактам, референсы проверят, репутацию подтвердят. И да — посмотрят ваш код на гитхабе, почитают посты в корпоративных блогах и т.д.

    Понятно что всегда есть желание «монетизировать» свой код, более того — тут это проще и легче. Но вот что трудно принять, так это то, что если ты сам чувствуешь что не в силах сам вытянуть\продуктизировать что-то — отдай, поделись, будет лучше всем. Менталитет — «лучше пусть у меня корова сдохнет, но у соседа вдвойне» (не поделюсь но и сам вытянуть не смогу) — реально плох.
  • Как работает CPU: интерактивный урок для начинающих
    +2
    Самое лучшее объяснение о том, как именно ( и почему так) работает процессор можно найти в книге «Код. Тайный язык информатики» (Code: The Hidden Language of Computer Hardware and Software) от Чарльза Петцольда.
    До этого меня мучали всеми этими схемами в институте — и я это ненавидел. После книги — все понял.

    И кстати переведена она достаточно качественно.
  • Windows Identity Foundation — для ASP.NET MVC проектов
    0
    Хмм, ADFS — это сервис для федерации разных Identity Providers между собой, и хотя он вполне неплохо работает в контроллируемой среде — никакие linkedin\facebook\google не будут федерировать свои IdProviders с левыми серверами. Он разве умеет в чистом виде быть STS-RP и объединять что-либо кроме стандартного WS-*\SAML 2.0?

    А предложенное решение (вернее Thinktecture Identity Server который выполняет роль STS-RP) — вполне может это все объединить, в итоге можно запилить вполне приличный Single Sign On experience для пользователей аутентифицированных в разных фейсбуках\гугл+\линкединах и прочей OpenId \ OAuth2 братии.
    К тому же Thinktecture Identity Server куда более легковеснее ADFS, не говоря уже про то, что ADFS сути прибит намертво к AD, которая однако не бесплатная…
  • Теперь любой сайт может узнать адрес вашей страницы в VK?
    +1
    А чем профили пользователей в Хроме не устраивают?
  • Отложенное чтение: OpenSource-альтернатива
    0
    Посмотрите на Calibre — там была такая функция с дайджестами\фидами.
  • Отложенное чтение: OpenSource-альтернатива
    0
    В конце посмотрите на fact checklist — Offline viewing of articles and webpages есть у обоих.
    У меня были проблемы с вышеупомянутым Best View, когда сохранялась не статья а ссылка и покет пытался перечитать «актуальную» версию из инета, если статья убрана — прилетал облом. Выключив этот режим — не испытываю проблем с оффлайн чтением даже исчезнувших статей.

    Я вообще смутно понимаю в чем суть этого «бэкапа» как фичи, мб это имеется ввиду что сохраняются оригинальные копии и можно увидеть если были изменения. Не очень внятно описанная фича tbh
  • Отложенное чтение: OpenSource-альтернатива
    0
    Вроде все также сохраняет. У него только появился странный режим — best view, который каждый раз перечитывает статью, видать с использованием последнего парсера… т.е. если статью убрали в черновики — она внезапно «выпадает» из покета.
  • Zero Downtime Upgrade для приложения в Microsoft Azure. Часть 1: PaaS
    +1
    Пожалуйста, не используйте стейджинг окружение для тестов!
    Никогда не делайте этого — единственное предназначение стейджинг окружения — более гладкое обновление продакшена (с чем он справляется но средненько).

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

    Итак краткий перечень самых толстых граблей:

    1. Обновление базы в результате миграций (привет от EF) — ваш стейджинг слот может содержать миграции которые несовместимы с тем что в продакшене. Засунули новый пакет, прогрели — получили сломаную базу в продакшене.

    2. Vip Swap обратно — возможно. но тоже есть риски. Если вы поломали базу продакшена предыдущим действием — откатиться просто так не получится — вам нужно сделать даунгрейд миграции. А ее то на продакшене еще нету ( потому как она новая и есть только в пакете стейджинга)

    3. Несколько сайтов — если у вас несколько сайтов в одной роли (например админка или сайты с разной авторизацией) — работать с ними в стейджинге — невозможно, Hostheader не прописываеся никому кроме основного, т.е. достучаться до админки в стейджинг слоте — нельзя ( это если вы вдруг захотите починить что-то откатом миграции через админку ;) )

    4. Очереди. Сделали вы воркер роль, которая при старте начинает таскать сообщения из очереди. Вроде все как МС рекомендовал. Заливаете в стейджинг для тестирования — обнаруживаете что есть бага (ну вы же «тестируете» — это нормально). Ан нет — воркер в стейджинге таскает те же сообщения что и продакше. Ну т.е. из продакшен очереди. Т.е. часть сообщений в очереди было стырено стейджингом, успешно слито по причине бага и кто-то что-то недополучил в продакшене.

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

    Всегда используйте отдельно сконфигурированное тестовое (а можно и девелоперское) окружение. Да это будет дороже, и даже если вы считаете что вырванные на жо..голове волосы отрастут — клиенты попавшие в такие ситуации будут очень обижены на вашу «технологическую платформу».
  • Менеджеры паролей — краткий обзор
    –1
    А вы поинтересуйтесь, как ластпассовцы мониторят свою инфраструктуру на предмет активностей и утечек. Там сео как раз такой суровый параноик — я доверяю уже несколько лет — проблем не было. Единственный security инцидент который был за это время у LastPass — какая-то необъяснимая активность в их системе и отправка 120 байт наружу привела к рекомендации — сменить пароль и перешифровать с большим количеством раундов.
    Я спокойно отношусь к тому что мои пароли в облаке. Уж лучше они будут в облаке такого параноика чем в general-usage облаках как дропбоксы и скайдрайвы.
  • Менеджеры паролей — краткий обзор
    0
    А форм филлер из ластпасса в последнее время не конфликтует с разными автокомплитами?
  • Результаты тестирования облачных хранилищ Amazon, Google, HP, Microsoft и Rackspace
    +4
    Эмм, а не смущает автора, что отчету уже год с хвостиком? В корпоративном яммере висит ссылка на тот же самый отчет, датированная 20 февраля 2013 года.
  • Лёгкий способ писать iOS приложения на вебе
    +1
    да, вполне просто если держать самое большое число всегда в углу

  • Как я использовал BitTorrent Sync между офисами в РФ и Китае
    0
    Ээх, Даже в развитых странах есть проблемы с интернетом. Я бы сказал что в России интернет один из самых лучших по отношению цена-качество (и количество доступной выделенки). Радуйтесь ;)
  • Высоконагруженные системы: решение основных проблем
    +1
    Добрый день, а не покажете код PerfWatch?
  • Питерская конференция для .NET-разработчиков
    +4
    Сделайте пожалуйста видеозаписи докладов и презентаций, для тех кто не может посетить конференцию.
    Заранее спасибо.
  • Git и Visual Studio: как правильно приготовить
    0
    Хмм, у нас не сильно отличается — */_NCrunch_* и все работает.
    Студия вроде его тоже не подхватывает, коллега вроде не жалуется. А какая конкретно проблема — гит игнорирует а студия нет?
  • Git и Visual Studio: как правильно приготовить
    +2
    Извините, но правильно готовить Git (можно и без VS) нужно хотя бы вот так — GitExtensions.

    А то у вас от всех этих свистелок и перделок встроенных в студию Solution Explorer все еще тормозит в 2013 версии.
    Кстати те кто у нас работают с Git\TFS через студию — чаще всех других забываю закоммитить все файлы и обычно ломают проекты. Любой завалящийся внешний клиент не в курсе про замудренные структуры solution, и честно показывает что изменилось в рабочей копии, а студия вечно пытается мухлевать.
    Единственное что правильно сделали — gitignore который покрывает большинство ненужных в репозитории файлов — За это большое спасибо.