.NET Tools. Інтерв'ю з Сергієм Шкредовым (JetBrains), Павлом Авсениным і Олександром Захаровим (DevExpress)


Деякі розробники програмують поглядом. Інші сліпі і програмують на слух\дотик. Окремим товаришам досить маркера і дошки. Але все-таки більшість .NET розробників користується Visual Studio для кодування і дебага, парочкою профайлеров, декомпилятором, плагіном для VCS, браузерних інструментами, R#\CodeRush, тулзой для контролю бази даних, баг-трекером, білд-системою і кавоваркою.
Мені вдалося поговорити з розробниками деяких з перерахованих засобів розробки.
Під катом — нудна і зовсім нецікава реклама, трохи Roslyn, трохи Rider, мінімум CodeRush, малість описані фічі C# 7.0, побіжно розглянуті перспективи .NET і один раз згадується PVS-Studio.



JetBrains представляв Сергій serjic Шкредов, автор численних фіч в ReSharper, адепт системного програмування, керівник .NET-напряму в JetBrains, а також один з розробників (користувачів) Rider.

– Добрий день, Сергій. Почнемо з початку, а саме з IDE. Зараз .NET світ лихоманить: вийшли нові версії .NET, нові версії студії, своїх перших користувачів знайшов Rider. Коли ситуація трохи заспокоїться?
– Добрий день. Сподіваюся, ніколи не зупиниться. Ми живемо в світі, який дуже швидко змінюється. І, на мій погляд, зараз .NET набагато більше порядку. MS розвиває його як платформу, що обслуговує всі MS-стеки розробки: відділи мобільного розробки, хмарною, WinPhone, десктоп — всі зацікавлені у розвитку платформи. Відчувається, що зараз розробка впорядковується: зменшується вплив окремих команд .NET розвивається як єдине ціле.
– У кожної платформи свої обмеження, не буде скорочуватися основа .NET, загальна для всіх?
– Як раз навпаки. Для інтеграції з .NET Standard кожна з платформ розвиває свої API, розширює їх. Мене дивує тільки живий Mono, я думав його замінить .Net Core. З іншого боку, Mono розвивається .NET Standard, що вселяє певні надії.
– Судячи з обговорень різних IDE на хабре, головні характеристики IDE — швидкість роботи, мінімум споживаної пам'яті\проца, швидкість завантаження проектів, ну і набір функцій. Є речі більш важливі?
– Звичайно. Продуктивність критична. IDE повинна швидко завантажуватися, завантажувати проекти, не блокувати UI; Отакі три кити, три критерії продуктивності.
Але при цьому кожна IDE підтримує якийсь стек технологій. Тобто, є розробники, вони вирішують типові завдання бізнес, зазвичай на одному стеку технологій. Відповідно, основне завдання IDE — полегшити роботу з цим стеком. Наприклад, ми Rider концентруємося зараз на кроссплатформної мобільного розробці і ASP.NET.
– Обрали найбільш популярний напрям?
– В тому числі. Крім популярності, ці стеки не так сильно приросли до MS. Багато OpenSource-утиліт, інструментів. Якщо взяти Office SharePoint або розробника — без VS практично неможливо що-небудь зробити. До речі, я забув згадати Unity. Аудиторія немаленька, але потреби у неї відрізняються від того, що ми звикли бачити в Web або мобільного розробці. Коду не так багато, і користь від IDE трохи менш помітна.
– Ви збираєтеся працювати ще й з ігровим движком?
– Ні, тільки з скриптовою. Грубо кажучи, Unity складається з двох частин: графічного движка і скриптів. З графікою працюють у Unity Studio, скрипти пишуть під MonoDevelop або VS. Ми допоможемо працювати зі скриптами.
– Раніше R# був обмежений .NET framework 3.5. Зараз це обмеження в силі?
– Ні, ми вже не підтримуємо версії VS менше 2010, занадто мало користувачів у них залишилося, так і для VS 2010 вимагаємо 4.0. Скоро будемо вимагати 4.5. Хотілося б .NET 4.6.2, але він встановлений далеко не у всіх наших користувачів… Так що в найближчі кілька років нічого не зміниться.
– Інструменти зараз все частіше і частіше ширяють у хмарах. Сервера, системи моніторингу, TFS, що перетворився в VSTS… Очікує нас хмарна IDE?
– Розробникам поки краще посидіти на десктопі, принаймні, я не бачу мотивації для переходу в хмари. Хіба що придалася б міні IDE для швидких фіксів без локального чекаута. Так, білд-ферми в хмари йдуть. Якщо у тебе часто виникає затики з чергою білдів, було б непогано мати можливість швидко додати декілька машин в build agents pool. При цьому тут теж потрібно враховувати. За нашими розрахунками, виходить дешевше ставити власні сервера.
– У вас TeamCity?
– Так, вся наша внутрішня інфраструктура живе на TeamCity. Для OSS-проектів ми теж використовуємо публічну інсталяцію TeamCity.
– Питання про аналізатори Roslyn. Найпростіший робочий аналізатор пишеться за кілька годин, проте далі найпростіших ж прикладів справа зазвичай не доходить. І це при наявності вже готових рішень, які можуть служити відмінною специфікацією. В чому проблема з цими аналізаторами?
– Писати просто, але яка мотивація авторів? Аналізатори — це кльова іграшка. Того ж ефекту можна було і раніше домогтися з допомогою R# SDK. Мабуть, єдина перевага аналізаторів Roslyn — це хороша інтеграція з Build процесом і IDE, це реально класно зроблено. Але як і у нас, там є великі проблеми з публічним API. Мова змінюється, а це означає, що аналізатори теж треба дописувати для нових конструкцій мови.
Open Source зазвичай контрибьютят або повністю готовий фреймворк, або з'єднання пару складних фреймворків для отримання готової тулзы. Придумати самий складний проект з аналізаторами важко: за фактом цінність такого проекту накопичується з кількістю аналізаторів. При цьому багато хто з них дуже схожі. У підсумку для отримання серйозного продукту потрібно запилити 100 майже однакових функцій. Методично, один за одним писати нудні шматки коду — звідки візьметься мотивація на це? Плюс, написати аналізатор правильно з першого разу важко, життєвий цикл немаленький. Тобто, ти пишеш аналізатор, релизишь його, получаев 15 реквестов на рідкісні баги. Досить важке заняття.
– тобто, за подібні речі варто братися з чисто фінансовими намірами? Найпростіша мотивація?
– Я чекав такого, що хтось візьметься. Ось, PVS-Studio взялися. Пиляють аналізатор за аналізатором.
– А що з продуктивністю аналізаторів?
– Сильно страждає. Наприклад, для роботи з інтерфейсами потрібно будувати індекс, який дозволяє швидко аналізувати десяток сценаріїв, інакше у нас буде десяток перевычислений. Якщо пиляти це Open Source — хтось повинен написати такий індекс, а потім десятки розробників доведеться якось до індексу коннектіться. Навіть за рахунок проблем комунікації це дуже складно.
– Розробники все більше і більше покладаються на свої інструменти. Крім знання безпосередньо мови (і пари платформ) зараз потрібно вміти працювати з VCS, дебагером, парою профайлеров, рефлектором, різними тулзами для рефакторінгу, тестовим фреймворком (а то й не одним), системою управління проектами, інструментами розробки в браузері, так і сам .NET мова постійно розвивається. Ми стаємо все більш залежними від інструментів і stackoverflow. Чи настане час, коли клас програміста буде визначатися знанням утиліт і плагінів, а не мови і бібліотек?
– Так, знання мов та алгоритмів знецінюється. Інструменти стають зручніше, частина роботи беруть на себе. Згадай старі добрі WinForms: треба було створити елемент, подцепиться до EventHandler, написати метод для обробки, змінити модель, отримати відповідь, змінити пару компонент, купу всього провалидировать. Нещодавно я писав на Kotlin c React, і майже не думав про UI. Змінив модель, віддав її на перемальовування, і фреймворк сам підхопив всі зміни. Зовсім інший підхід. Думаю, найближчим часом від програмістів будуть вимагати знання фреймворків, модних технологій, розуміння як писати скалируемый код, переносне. А алгоритми і структури даних — минуле.
– Це стосується тільки .NET світу? Вважаю, заперечення системних програмістів будуть дуже емоційними.
– Розробники компіляторів і високонавантажених рішень, звичайно, залишаться. Але зараз все більше і більше людей програмує просто з допомогою StackOverflow і задоволені цим.
– Розробка стала простіше?
– Зникла необхідність розбиратися в тому, як працює конкретний фреймворк. Точніше, фреймворки з'являються настільки швидко, що у тебе немає часу на їх вивчення, і ти змушений довіряти їх авторам.
– Сергію, ти не міг би розповісти про Team Tools (Hub, TeamCity, Upsourse, YouTrack)? Наскільки сильно ваш набір наблизився до VSTS і Atlassian стеку? Що нам чекати в майбутньому?
– Необхідні компоненти ми зібрали: YouTrace — баг трэкер, TeamCity — CI сервер і Upsource для код-рев'ю. При цьому нам конкурувати з конкурентами складно, наші продукти розрізнені. У продукті Hub ми організували User Managment, але залишилися інтеграцій — вагон.
– Як ви будете це виправляти?
– Поки що лише плани, публічних заяв не буде. Але ми розуміємо, що люди працюють в командах, і хочемо, щоб IDE знала про командах більше. Тобто, ти зайшов у студію, підключився до сервера — і в тебе IDE вже знає про твої проекти, тягаючи, баги і т. д.
– Rider. Рік тому ви не збиралися злазити зі студії, в січні ж анонсували свою IDE. Чого нам чекати від неї (крім швидкості\зручності)? Плагіни? Інтеграція з усім і вся? Інтеграції зі своїм Team Tools стеком?
– Ми поки не слезаем зі студії. Основні фічі R# і профиляторов працюють зі студією (і вештаються з Rider). Що до Rider — зараз вже зібрали значну власну базу. Є люди, які сидять на Rider місяцями, не відкриваючи студію (я в їх числі). Зараз ми розсилаємо посилання на свіжі білди нашим самим раннім користувачам private EAP, але вже днями збираємося відкрити публічний EAP, а значить Rider можна буде скачувати всім прямо з сайту. Для нас це важливий крок, кількість користувачів збільшилася на порядок. Дуже багато зусиль ми зараз докладаємо для досягнення стабільності, щоб білд\дебаг працював для будь-яких проектів і виживав на будь-яких системах.
Розділивши обробку коду і UI — ми отримали досить спритну, чуйну IDE. Над розширюваністю теж попрацювали, плагіни можна писати як до фронт-енду, так і до бек-енду. Зараз пиляємо аналізатор, що дозволяє визначати сумісність плагінів.
– Яка білд-система використовується для білду?
– MsBuild на Widows, можна використовувати XBuild на Mac і Linux (ми його не рекомендуємо, але в той же час розуміємо, що не все ще перейшли на крос-платфоменный MsBuild). У плані білд-системи ми нікуди не від MS не йдемо.
– тобто, помилок білду при міграції зі студії не буде?
– Саме так. За великим рахунком, немає ніякої міграції, відкриваєш все той же студійний .sln і продовжуєш роботу.
– Ви планували випустити реліз восени. Вийде?
– на Жаль. Поки плануємо реліз на початок наступного року. Продукт буде платний, і нам не хочеться соромитися того, за що беремо гроші.


Іншого виробника, DevExpress, рекламували адепти парного програмування:

Павло pavsenin Авсенин
.NET-розробник, в епоху буму Flash втік в розробку додатків для соцмереж. Чотири роки тому він повернувся і з тих пір допомагає вибирати гарні імена для нових змінних в команді CodeRush. Великий любитель споглядати різні відмінності файли, особливо навесні.

Олександр alexandrz Захаров
Захопився комп'ютерами і програмуванням ще в ранньому дитинстві. Пройшов через ZX Spectrum, BASIC, Pascal, C, C++, Java, і в підсумку зупинився на C#.NET.
Зараз займається розробкою CodeRush в компанії DevExpress.

– Добрий день. Зараз .NET світ лихоманить: вийшли нові версії .NET, нові версії студії. У DevExpress майже всі продукти зав'язані як мінімум на один з цих компонентів, наскільки важко вам встигати за MS?
– Так, MS розвиває .Net Core, Xamarin, запускає Standard, і нас це радує. Технологія розвивається — значить вона живе. Що стосується підтримки — у нас свій підхід: ми стежимо за будь технологією з самого початку її існування, але серйозно починаємо з нею працювати тільки після деякої стабілізації. Ми дивимося, пробуємо, робимо білди, але публічно це не викладаємо. Так, ми спостерігали за .NET Core і не вживали активних дій до виходу релізу. Так що, всі зміни в порівнянні з RC нас не торкнулися. Крім того, що ми не витрачаємо сил на підтримку «не выстреливших» продуктів, за час очікування у нас накопичуються запити від клієнтів, що дозволяє нам точніше розставити пріоритети.
Хоча трапляються провали і у нас. Наприклад, ми витратили чимало ресурсів на підтримку мертвонародженого Silverlight.
останнім часом працювати стало простіше: багато речей лежить в OpenSource, є Early Access. Простіше стало реагувати на зміни, ми дізнаємося про них раніше.
– Іноді конкуренти створюють щось до вас. Наскільки вам допомагають їх продукти?
– У нас немає пріоритету швидкості, наша мета — якість. Ми посматриваем на рішення конкурентів, враховуємо їх успіхи і помилки, але свою стратегію намагаємося будувати, виходячи з запитів користувачів та їх відгуків.
– Питання про аналізатори Roslyn. Найпростіший робочий аналізатор пишеться за 5-10 вечорів, проте далі найпростіших прикладів справа зазвичай не доходить. І це при наявності вже готових рішень, які можуть служити відмінною специфікацією. В чому проблема з цими аналізаторами?
– По-перше, подібні аналізатори (по сотні штук в пакеті) .
По-друге, API — шикарне, але сам підхід иммутабельных дерев незвичний більшості розробників.
по-третє, один аналізатор дійсно пишеться за кілька годин, але зазвичай людям потрібен цілий спектр подібних речей, для чого вже бажана команда, бажано друкарська продукт заради грошей (це значно прискорює проект).
Чому ж в OpenSource досі такої команди не з'явилося?
– Сам MS розвиває свої рефакторинги. Думаю, ніхто не бажає з ними змагатися. Плюс, висить питання мотивації: реально великий і складний проект потрібно підтримувати, а розраховувати на підтримку в OpenSource ризиковано. Ось і виходить: маленький проект нікому не потрібен через нестачу функціоналу, великий з-за можливих ризиків із підтримкою.
– Коли ми пишемо аналізатор — ми кидаємо місце фиксеру, і він бігає за кодом вдруге. Як ви вирішує проблему повторних обчислень?
– Якщо ти бігаєш по синтаксису — проблем у тебе немає, це швидко. Якщо ж обробляється семантика — у Roslyn є свій кеш. В цілому проблема невелика. І потім, говорити про повторні обчисленнях у вакуумі безглуздо. Найчастіше треба заміряти кожен аналізатор окремо.
– DevExpress згадувався як контриб'ютор в Roslyn. Наскільки проект відкритий, наскільки він розвивається, які тренди зараз в його розвитку?
– Конкретно команда CodeRush не контрибьютила. У нас була одна ідея, але її вже серйозно пиляли, так що ми вирішили не втручатися.
Що до відкритості: долучитися до прекрасного може кожен, проект активно розвивається.
Кожен апдейт студії — апгрейд перформансу, іноді відкривають API. Так, у 3 превьюшке дозволили експорт комплишен-провайдерів для вставки автодополнений в основну сесію IntelliSense. Був API internal, став public. Зараз ще і сам C# активно пиляють до 7 версії (швидше б вже), додаються фічі, у тому числі з функціонального програмування. Ну, і рутина: фікси, перформанс, полірування API.
– Анонсований .NET standard 2.0. Він таки стане єдиним стандартом, або можна завантажувати картинку про 15 16 стандартів?
– Таки стане. .NET Core, Desktop, Xamarin — всі там будемо. Все залежить тільки від MS, бажання у них є, Roadmap є, так що свою роботу вони дороблять. З іншого боку, як видно з досвіду попередніх спроб, процес уніфікації складний і тернистий, платформ чимало. Швидше за все, доведеться зробити кілька спроб.
Напевно будуть складності. Раз API загальний а реалізація різна — з'являться недокументовані можливості, раз вони з'являться — їх будуть юзати, раз їх будуть юзати — код стане нестерпним. І хоч це буде косяк розробника — непереносимість з'явиться. Продуктивність під різними платформами буде відрізнятися. Можливо, з'явиться який-небудь виключення або атрибут NotSupportedPlatform.
Іншими словами, уніфікація закінчиться, але коли саме — тільки час покаже.
– На якому стандарті MS зупиниться? 4.5, 4.5, 4.5.1?
– Вони будуть працювати вічно. Не тільки тому, що їм вигідно над чим працювати, але і тому, що світ змінюється, відкриваються нові можливості. І з'являються нові конкуренти.
Зараз MS займається IoT, можливо, з'явиться .NET для кавоварок. Може, запилят .NET для браузерів, TypeScript натякає. Розробки в нативної компіляції ведуться. Можливостей — мільйон.
– Зараз почалася маркетингова хвиля месенджер-ботів. Чи чекають нас скайп-помічники адмінів\тестувальників\розробників?
– Вже є подібні речі. Наприклад, бот коннектітся до білд сервера, дивиться останні білди, якщо є червоні — шле повідомлення у Slack. З іншого боку — боти лише інтерфейс. Якщо є якийсь софт для завдання — його можна прикрутити до боту. Хіба що, є деяка складність з обробкою команд в месенджері, можуть знадобитися інтелектуальні утиліти.
– У DevExpress солідний набір інструментів, причому сильно розрізняються по «напрямку»: додаток для IDE, графіка, тестовий фреймворк, інструменти аналітики… При цьому вони здаються досить різнорідними. Наскільки важко підтримувати таке розмаїття?
– Основний напрямок: розробка компонентів для різних платформ. Графіка. Компоненти, контроли для WPF, WinForms, JS, etc. Решта — просто якийсь розвиток ідеї компонентів. Різноманітність є, але зазвичай є система і підтримує її команда. Так що основні проблеми виникають при кросспроектных комунікаціях.
– CodeRush підтримує всі популярні тестові фреймворки. Як ви боретеся з спокусою написати свій?
– Боротьба зі спокусою проста — у нас немає спокуси. Була думка зробити mock-фреймворк з можливістю підміняти непублічне API і поведінку типів з BCL, думка досі є, але пріоритети інші. Є nUnit, xUnit — нема чого з ними боротися, вони відмінно роблять свою роботу. Крім того, у нас були запити безперервного прогону тестів (тлі), але запитів цих небагато.
– Які інструменти популярні в конторі, яка розробляє інструменти?
– CodeRush. Хоча дехто не бачить користі в подібному інструментарії, принципово його не використовує. VS. nUnit, xUnit. Git, Mercurial. Багтрекер свій, Trello як планувальник, профиляторы — від PerView до dotTrace. Своє рішення для CI, засноване на CruiseControl. В цілому, зоопарк великий.
– Розробники все більше і більше покладаються на свої інструменти. Чи настане час, коли клас програміста буде визначатися знанням утиліт і плагінів, а не мови і бібліотек?
– Інструменти економлять час, і чимало. Можна називати себе програмістом не вміючи користуватися ними — велике питання.
Знову-таки, може, десь ще зберігся анахронізм з поділом на проектувальників, програмістів та тестувальників, коли проектувальник проектує архітектуру, віддає це черні, яка програмує і потім віддає код інший черні, яка тестує. У нас розробник робить усі ці речі сам, і вимоги до розробника відповідні.
– На співбесіді ви питаєте про його улюблені інструменти? Це критичний питання?
– Не критичний. Якщо людина чогось не знає: можливо, він цим не користувався, не було приводу. Навченість важлива. Вона визначає клас програміста.
– Чесно кажучи, я поки не стикався з функціональними мовами. Про оновлення .NET новини з'являються часто, а F# майже не згадується. Мова ще розвивається?
– мало Згадок з однієї простої причини: все необхідне вже на борту. З версії F# 3.0 там тільки косметичні зміни. Останнім часом MS намагається інтегруватися з Roslyn на рівні проектної моделі (Workspace API). До речі, інтерес до F# лише зростає. З'являються конференції, відео, пости. Є невелика, але віддане ком'юніті.
Хоча масштаб, звичайно, непорівнянний з C# (поки що). Якщо порівнювати кількості — на одного F# розробника припадає десять розробників C#. Просто з-за функціональної парадигми, не кожному вона зручна чи зрозуміла. Швидше за все, згодом F# наздожене C#, або увіллється в нього. Це не мова для фінансів, Machine Learning, це відмінний мова для всього.
– З'явиться CodeRush для F#?
– Зараз тулинг вбога, є Visual F# Power Tools — і все. Решта — точкові інструменти. З приводу CodeRush для F# — тут все залежить від запитів наших користувачів. Вони є, але їх поки не дуже багато. Можливо, після інтеграції з RoslynWorkspaceApi завдання стане простіше, і ми серйозно про це подумаємо.
– Наскільки реально використовувати CodeRush для навчання? Він підсвічує помилки, пропонує виправлення.
– Закріплення — можливо. Накосячілі — тут же отримав втик. Ввічливий. Щодо навчання — немає. Деякі джуни побачивши помилку — гуглят. Що, навіщо, чому так не можна, чому потрібно інакше. Решта не думаючи застосовують рефакторинг. Більш того, якщо багато покладатися на інструмент — в один момент перестаєш розвиватися. Навіщо, якщо розумна програма все зробить за тебе?
– CodeRush. У чому принципова відмінність від R#? Ви конкуруєте, або займаєте дві ніші?
– Це інструменти одного класу, інструменти продуктивності розробників, і вони займають одну нішу. За факт, що вони з'явилися майже одночасно. Коли тільки з'являлися перші студії — у MS був IntelliSense і все. Тоді і з'явилися CodeRush і R#.
– Майже 15 років історії?
– Так. Хоча зараз історія переписується. Один час продукти були схожі, чіплялися до студії, гальмували її. Тобто раніше студія розбирала код, і CodeRush\R# розбирав. Потім на стороні редактора потрібен доступ до компілятору, MS зробили CompilerAsService, у зовнішніх утиліт з'явилася можливість чіплятися до компілятор… коротше, два роки тому ми переписали все на Roslyn.
– Кілька років тому ви зробили ставку на Roslyn (на той момент ще сирий). Як ви думаєте, зіграла ваша ставка?
– Основні бажані плюшки ми отримали: вдалося уникнути подвійного розбору коду (а це подвійні обчислення і пам'ять). Плюс, зараз ми стали спокійніше сприймати нові фічі в C#, обробляти їх стало простіше. Не потрібно самостійно фиксить свої алгоритми розбору коду, автоматом виходить парсер і резолвер. Майже вся «рутина» зроблено, залишається тільки писати нові фічі. Тут складно говорити про виграш, думаємо, час покаже.
Ми порівнювали версії CodeRush (з Roslyn і без нього) — Roslyn версія забирає трохи більше оперативної пам'яті, але це не критично. Тобто, Roslyn дійсно жере багато пам'яті, але при обробці синтаксичних і семантичних дерев ми використовуємо лише його ресурси, сам CodeRush тепер нічого не додає. Коли ми починали перехід, иммутабельное дерево викликало багато питань. Передбачалося, що managed компілятор буде гальмівним. Але з'ясувалося, що дерева можна обробляти в декількох потоках, що прискорює обчислення. З приводу ж «сирого» Roslyn — на той час проекту вже було кілька років, писала його команда відмінних спеців, і видно було, що MS покращує його. «Незнайома» — може бути, але це поправимо. І так, коли ми серйозно взялися за переробку CodeRush, студія вже щосили крутилася на Roslyn і була цілком стабільною.
– Що щодо ідеї поділу UI і компілятора (як у Rider)?
– У JB є платформа для написання IDE. Популярна, одна з кращих. Є відповідні фахівці. У нас таких умов немає, так що цей варіант ми серйозно не розглядали. На наш погляд, .NET і MS нероздільні. Підтримувати свій компілятор — завдання трудомістке, і ми вирішили піти за MS.


Якщо ви прочитали ці інтерв'ю і вам мало — приходьте на DotNext 2016 Moscow . На конференції будемо говорити не тільки про тулзы: пройдемося і за перфомансу, і багатопоточності і багато чого ще:

.NET Core: State of the art
Squeezing the Hardware to Make Performance Juice
Інтелектуальні чатботы і когнітивні сервіси
Stack Overflow — it's all about performance!
Advanced Xamarin.Forms
C++ через C#
Продовжуємо говорити про арифметику
ASP.NET SignalR: Why it's Getting Really Crucial for Web Development
Exceptional Exceptions in .NET
Модифікація коду .NET у рантайме
End-to-end JIT
Performance tuning Stack Overflow tags
C# Scripting — why and how you can use your C# in places you never thought of before!
Multithreading Deep Dive
Зібрати все, або Знайомимося з Cake (C# Make)
WinDbg Superpowers for .NET Developers
Overview of the new .NET Core and .NET Platform Standard
Які знаходять уразливості в .NET платформі і як не повторити їх в своїх додатках
what's new in C# 7?
ETW — Monitor Anything, Anytime, Anywhere
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.