Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Попытки отражения garbage-collected структур на ужасный неуправляемый С++

Если вы вдруг решили сконвертировать C# в C++, то большинство задач конверсии – тривиальны. int меняется на int32_t, string на std::wstring (хотя на самом деле просто string для большинства людей которым unicode не нужен). Ну и так далее. Различия в большинстве случаев несущественны.

Основной задачей, как ни странно, является конверсия reference типов, т.к. в C# можно создавать массивы, дженерики и просто ref-типы и пускать все на самотек дескать “когда-нибудь освободится”, а вот на C++ так делать нельзя. Напомню, что в С++ есть вот такие варианты:

  • Аллоцировать вещи на стеке. К сожалению, за исключением примитивных типов, в C# никто так не делает. Чтобы C#ный объект который кто-то аллоцировал через new аллоцировать в С++ коде на стеке, нужно быть увереным что объект маленький и что он действительно только вот тут, в локальном scope, что его никто не потребляет. Зато стек почистится по мере выхода их скоупа, что как бы неплохо.

  • Аллоцировать вещи вручную через new/delete: это нереально в принципе т.к. если идти по этому пути, то у каждого типа может быть свой набор ссылок на весь мир, ну и… вы поняли. Получится ад. Не вариант.

  • Использовать умные указатели так, как их нужно использовать. То есть например если у вас есть фабрика которая порождает объекты и выдает их наружу, то вы можете возвращать unique_ptr. И так далее. Одна лишь проблема: как понять какой указатель нужен? Опять нужен глубинный анализ, а это сложно.

  • Использовать везде shared_ptr, т.к. это как раз тот указатель, который можно либерально копировать повсюду и при этом не получить ситуацию когда вы пытаетесь вызвать что-то у объекта, который уже был перемещен куда-то.

Инициализация и присваивание

Отдельной пролемой стоят всякие инициализации и присваивания. Например, представим что вы создаете человека, и передаете строку. Принято ведь писать

class Person
{
  string name;
public:
  Person(const string& name) : name(name) {}
};

Опаньки! А мы-то думали что все не-примитивные объекты будут shared_ptr. В результате получается, что

  • Все типы которые мы считаем “маленькими” (а это включает всякие int, float и так далее) передаются by value

  • Строки и прочие типы которые нормально себя ведут в нынешней системе типов мы передаем как const ref

  • А вот все остальное – да, проблуем использовать shared_ptr

Полноценный пример

Давайте типичный пример с человеком у которого есть адрес:

struct Address
{
  int HouseNumber;
  string StreetName;
  Address(int houseNumber, const string& streetName)
    : HouseNumber(houseNumber), StreetName(streetName) {}
};

Я намеренно использую struct и C#-ное именование а также не использую properties т.к. автосвойство C# можно смело конвертировать в поле C++ without loss of generality. Так вот, у нас есть адрес который берет const string& во втором аргументе и это как бы правильно.

Теперь посмотрим на человека, который обладает адресом:

struct Person
{
  int Age;
  string Name;
  shared_ptr<Address> HomeAddress;
  Person(int age, const string& name, shared_ptr<Address> homeAddress)
    : Age(age), Name(name), HomeAddress(homeAddress) {}
};

Вроде тоже неплохо. Сразу понятно что подсовывать Address нам не нужно, и что нам нужна “управляемая” версия. Теперь все это можно потреблять:

auto address = make_shared<Address>(221, "Baker St");
auto person = make_shared<Person>(40, "Sherlock", address);
cout << person->Name << endl;

Более того, мы можем не нервничать насчет удаления address если его “хозяин” надоел и его грохнули:

shared_ptr<Address> addr;
{
  auto address = make_shared<Address>(221, "Baker St");
  auto person = make_shared<Person>(40, "Sherlock", address);
  addr = person->HomeAddress;
}
cout << addr->StreetName << endl;

Ну ок, вроде оно как-то работает. Хотя тут мне подумалось… а ведь по идее можно и адрес было передавать как const shared_ptr<Address>&, не так ли?

Ладно, что там следующее?

Массивы

Массивы – это вообще больное место. В C# есть два разных типа – прямоугольные [,] и угловатые [][], в С++ существует только 2й вариант. Но проблема даже не в этом. Проблема в том, как вообще представить N-мерный массив чего либо через умный указатель.

Начнем с простого: у человека несколько имен и это как-то нужно хранить. Тут, самое безопасное – это vector<string>. В принципе, со строками мы можем себе позволить такой вот расклад когда мы копируем by value. Но как насчет набора адресов?

Одномерный набор адресов в C# подразумевает конверсию как List<T> так и T[] в vector<shared_ptr<T>> – конечно, для тех типов где shared_ptr нужен, т.е. не для для примитивов или string:

struct Person
{
  int Age;
  vector<string> Names;
  typedef vector<shared_ptr<Address>> AddressCollection;
  AddressCollection Addresses;
  Person(int age, const vector<string>& names, const AddressCollection& addresses)
    : Age(age),
      Names(names),
      Addresses(addresses)  {  }
};

Ну а тут можно воспользоваться любезно предоставленым typedef’ом и проинициализировать все это счастье в стиле С++11:

auto person = make_shared<Person>(23, 
  vector<string>{"Janes", "Jimmy"},
  Person::AddressCollection{ 
    make_shared<Address>(123, "Hull Rd"), 
    make_shared<Address>(23, "Sesame St.")});
for (auto addr  : person->Addresses)
{
  cout << addr->StreetName << endl;
}

А что же насчет std::array или например boost::shared_array? Ну, std::array на самом деле требует (сразу!) известную длину. То есть если у вас в C# написано например что int i = new int[3] то тогда да, вам повезло:

struct Person
{
  array<shared_ptr<Address>, 2> HomeAndWorkAddresses;
  explicit Person(const array<shared_ptr<Address>, 2>& home_and_work_addresses)
    : HomeAndWorkAddresses(home_and_work_addresses)
  {
  }
};

От кода выше в принципе уже должно тошнить, но для тех кто не понял в чем соль, вот то, как выглядит инициализация сего счастья:

array<shared_ptr<Address>, 2> addresses = { {
  make_shared<Address>(123, "London Rd"),
  make_shared<Address>(23, "Shirley Ave")
} };
auto person = make_shared<Person>(addresses);
cout << "Work: " << person->HomeAndWorkAddresses[1]->StreetName << endl;

Нда, мне определенно не нравится std::array. В большинстве случаев, мне кажется, лучше всего использовать vector<T>, vector<vector<T>> и так далее.

Полузаключение

На самом деле, то, что я описал – это верхушка айсберга. Например, допустим что мы допускаем хранения vector<string> но ведь по сути дела для передачи этой коллекции куда либо (а мало ли зачем?) мы не можем передавать ее by value (это расточительно!), и с другой стороны, она не shared_ptr<T>, то есть единственный наш вариант – это передавать ее как const vector<T>&. Хмм, а вообще это не такая уж и плохая идея.

Вообщем, в этом посте я для себя вывел набор (вполне вероятно ошибочных) правил по тому, как конвертировать reference-конструкты C# в нечно С++ное чем можно хоть как-то управлять. Возможно в последствии построить поверх всего этого какие-то дополнительные оптимизации. Посмотрим…

Written by Dmitri

30 Январь 2015 at 1:20

Опубликовано в Programming

Tagged with , ,

Итоги 2014

personal efficacy treeСловами не передать какое нужно нынче количество усилий чтобы вот так взять и написать блог-пост. Вот сижу тут под новый год, а меня все постоянно отвлекают: например, человек только что прислал вот такую фотку (вам не покажу ибо бред). Мне кажется полное забрасывание информацией – это стало уже комильфо, в то время как мы должны, по идее, от людей которые нам что-то постоянно кидают, ну если не отстреливаться ружьем то хотя бы делать /alertsoff. Также, если вдруг вы еще помните черную магию batch-файлов, можно тупо настрочить

taskkill /f /im skype.exe
taskkill /f /im chrome.exe

И это уже закроет 99% информационного шума. Все, кажется можно начинать.

.NEXT

Вообще, .NET конференция – это была моя давняя мечта. А в этом году их было аж две: в апреле в СПб на 300 человек, и в Москве совсем недавно на 400. На обеих конфах top-3 места по докладам взяли сотрудники JetBrains, и если на первой конфе нас было очень много, то на второй – там уровень докладчиков был еще выше и соответственно конкуренция была серьезная.

Я в Top-3 не попал, зато попали

  1. Роман Белов: Memory & Performance. Tips & Tricks
  2. Дмитрий Иванов: Принципы построения многопоточных десктопных .NET-приложений на примере ReSharper
  3. Дино Эспозито: ASP.NET vNext: What it means to you and what it means to Microsoft

Дино был нашим keynote speaker на конференции, и в целом слушателям он понравился. Думаю и на будущие конференции его можно звать, хотя естественно хочется «повышать градусность» и звать других известных спикеров тоже. Получится это или нет – покажет время.

Пока план .NEXT – повторять то, что уже работает (2 эвента в год, один в СПб, другой в Мск). Я бы конечно хотел сделать что-нибудь за пределами: буду думать про Хельсинки, хотя опыта организации международной конфы у меня пока нет. И самое главное, совершенно непонятны финансовые риски и возможные доходы.

nesteruk_alt_enter

Технологии

Что могу сказать? Я вам не Thoughworks Technology Radar, у меня спектр применения всякого технологического счастья очень узкий.

Тем не менее, в плане .NET развитие очень интересное: много чего ушло в open-source и есть подозрение что вообще весь .NET станет cross-platform т.к. иначе никто на нем писать не будет. Ведь популярность всяких там Node и иже с ним никуда не делась: все хотят все гнать на Linux и точка. Я конечно этому очень рад т.к. для меня ASP.NET MVC это идеальный тул, хотя сейчас набегут рубисты и скажут что «все это уже было». Ну ок.

Помимо развития .NET, продолжается прогресс в степях С++: в этом году я пару раз выступал на встречах C++ User Group Russia, а в следующем году будет конференция (программа, как видите, формируется) и я буду там делать доклад и еще на будке немного (не всю конфу, увы).

Вообще, очень интересно заниматься двумя продуктами (CLion и ReSharper C++) которые в какой-то мере конкурирую друг с другом по feature set, хотя и покрывают разный технологический стек. Я конечно фанат «конвергенции» когда разные разработки можно свести в один большой продукт, но в данном случае боюсь этому не бывать.

Для тех кому С++ «до лампочки» скажу лишь что этот язык – живее всех живых, и что бы не творилось в мире в плане популярности языков, как минимум 3 конкретные индустрии – game dev, embedded и quant finance – использовали и будут использовать именно C/C++. Меня конечно из всего этого интересует последняя (финансовая математика), поэтому я сейчас в процессе обкатывания библиотек (таких как QuantLib) под вышеупомянутыми продуктами.

Как ни странно, в этом году я не смог попользоваться ни D ни F#. Вообще мне кажется что с учетом прогресса в С++ (а также того факта что рано или поздно, ну может лет через 5, вы сможете шипить C# native), использование альтернативных языков хоть и возможно, но скорее «для души» нежели ради денег.

Гаджеты

В этом году не удалось попробовать ничего нового. 13-дюймовый айпад так и не зарелизили, а больше ничего перспективного и не было. Да, единственное, я наконец-то перешел на Blackberry, но в отличии от других людей, которые считают что писать блог-посты про то «как я перешел на WP/Android/iOS» это уместно, для меня это – ниже плинтуса. Так что и не надейтесь. Скажу так: BB Q10 меня всем устраивает, и точка.

А, да, к концу года Intel устроил распродажу Xeon Phi по $200 штука. Вот вам вполне гаджет, но поскольку нынешние разработчики о performance знают лишь краем уха, все это мимо цели. Наверное потому такая и цена, да.

Социалочка

Как человек которые сидит по 16 часов в день (с перерывами) за компом, моя социальная жизнь ограничена всякими эвентами вроде .NEXT, NDC London, выступлениями на user-группах в таких злачных местах как Таллинн или Рига, ну вот собственно и всё. И не то чтобы я планирую как-то это status quo менять.

Чего вообще пропало из жизни так это всякие посиделки с родственниками. Мне кажется в 21-м веке никто никому не нужен, и люди тебе в основном звонят только когда им чего-то от тебя надо. Да, это тотальная деградация, но с другой стороны, следует признать что не все люди вот прям такие интересные. Я например достаточно унылый: я могу разве что деньги обсуждать.

Политика и экономика

В этом году случился какой-то эпик фейл в РФ. Все уже надеялись что отношения с западом будут как-то но развиваться, и тут нате вам Украина. Причем весь разлад поначалу пошел именно на экономической почве: правительство Украины не захотело подписывать договор с ЕС, а люди взяли и смекнули что это как бы плохо, т.к. что покупать у РФ и таможенного союза – непонтятно, а вот в ЕС есть печеньки, Amazon.de и иже с ними.

Дальше последовал «захват» Крыма, сакнции, и хоть все и трубят изо всех дыр что де сакнции бессмысленные и на нас не влияют, но факт таков, что среднестатистический россиянин потерял как минимум 50% покупательной способности, если не больше. Так что санкции оказались не просто болезненными, а прям катастрофическими. Поэтому USDRUB на момент написания этого поста выглядит вот как-то так:

usdrub_epic_fail

Больше всего мне кажется народ офигел от сбитого Боинга (строго говоря, год оказался горазд на падения азиатских самолетов, да и паромам тоже не повезло). Я сам в тот момент летел из СПб в UK (хорошо что не не над Украиной маршрут), прилетаю, включаю BBC, а там такое… я бы тоже озверел, наверное. Ну и конечно тот поток лжи и откровенных фейков на федеральных каналах, не говоря о бреде вроде превратить США в гору радиоактивного пепла… позор, просто позор… ну как так можно позориться-то, а?

Тем временем… в магазинах, где и изначально-то нормальной еды не было (в РФ нормальная еда только в ресторанах, на прилавках ее нет), теперь вообще все плохо. Хуже может быть только голод и еда по талонам, как в 90е – и не стоит зарекаться что их не будет. Но с другой стороны в магазинах и телевизоров-то нет (упс!) а это значит что все такие богатые-шоколадные и вообще все супер, хотя когда у меня на графике USDRUB добил до 80, я думал что вот оно – market crash, дальше дефолты, девальвация и гори оно все огнем. А доллар за 500 это не так нереально как может показаться. И эти рынки не закрыть, разве что можно сделать рубль неконвертируемым, но это такой же адъ как и отключение SWIFT (которое, кстати, еще может случиться). Поразительно что каналы вроде RBC могут еще шутить (хотя улыбаться определенно не время):

Ну да ладно, про РФ забудем, ну ее – вот в Штатах все вообще шоколадно: DJIA бьет рекорды, NASA планирует лететь на Марс, Elon Musk продолжает выпускать новые модели Tesla (единственная машина, которую вообще стоит покупать), ну и капиталиация Apple или Google теперь больше чем весь рынок РФ. Так что повод для оптимизма в плане инвестиций есть. Ну и шортить USDRUB никто не запрещает… хотя как не запрещает, в Британии уже косяки с этим.

Итого

Как-то действительно получилось в этот раз. И я не в коей мере не ставлю себе целью на следующий год написать 100500 статей. Мне бы книгу дописать. Кстати, одну уже сделал, вот ловите, MATLAB Succintly (бесплатно и про MATLAB). А сейчас я как бы пишу серьезную книгу для Apress, тему не скажу, не просите. Может и не допишу вообще, т.к. денег в этом мало, а тщеславие можно тешить и по-другому.

Еще, я почти уверен, что я убью devtalk.net и spbalt.net. Касательно первого — один блог-пост за год (wordpress так говорит!) это не стоит того, а что касается spbalt.net то извините, но поскольку никто все еще не готов ничего рассказывать на встречах юзергрупп (а я насильно заставлять никого не буду!) то имеем что имеем. Впрочем, имхо .NEXT-а должно хватать. Но если не хватает — велкам в личку!

И еще, я сейчас занят небольшим e-learning проектом, так что что-нибудь я точно вам покажу в следующем году. Когда – это вопрос.

С Новым Годом! ■

Written by Dmitri

31 Декабрь 2014 at 12:31

Опубликовано в Technology

Неожиданные изменения в экосистеме .NET

Думаю многие из вас смотрели вчерашний Connect(); — там Microsoft в очередной раз показывали что происходит в плане технологий и инструментария для разработки. Но мало кто ожидал что .NET (конечно не весь, а только некое «ядро») будет выпущен в опенсорс, да еще с гарантией отказа от судебного преследования.

На текущий момент у нас, правда, уже много всего в Open Source, включая языки C#/F#/VB.NET, ASP.NET а также (удивительно) Entity Framework, не говоря о более мелких проектах вроде MEF. Так вот, теперь о ядро дотнета, включая такие сакральные вещи как GC (сборщик мусора, чей алгоритм держался в строжайшем секрете) теперь тоже идут на GitHub (да-да, не на CodePlex а туда, где реально сидят разработчики).

.NET Core

Вот что уже было выложено на GitHub:

  • Immutable Collections — те самые немутабельные коллекции о которых я писал.

  • SIMD — т.е. поддержка длинных регистров которые используются для SSE/AVX. Что ж, хорошо! Пока что доступ к SIMD возможен только через С++, правда основная головная боль по использованию SIMD уже ушла благодаря умным компиляторам. Писать assembler или использовать intrinsics нужно только в очень крайних случаях.

  • AssemblyMetadataReader — всякие там CustomAttribute и иже с ним. Странно как-то отделять это от всего остального, ну да ладно.

  • XDocument и XmlDocument — ну то есть поддержка Xml и в частности моего любимого (хоть и бажного, увы) System.Xml.Linq.

Одна из идей всего этого – нечто под названием Core CLR, т.е. возможность шипить некое ядро CLR вместе с вашей собственной программой. Это даст некую отвязку от ситуации когда ваше ПО не поставить, не выкачав предварительно из интернета еще 100Мб файлов .NET Framework 4 (по собственному опыту). И да, урезанная версия .NET Framework проблему эту не решила, увы.

Visual Studio Community

Основная пробема была и есть что VS бесплатной редакции не дает шипить ПО и не дает ставить плагины. Проехали! Теперь VS Community – новая редакция, которая

  • Поддерживает расширения

  • Позволяет распостранять ПО в коммерческих целях

Единственный нюанс – эта штука имеет ограничения по размеру компании. То есть это как бы для «небольшого бизнеса». На самом деле, все немного туманно:

In non-enterprise organizations, up to 5 users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or > $1MM in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.

Понятие «enterprise» еще нужно объяснить, но по крайней мере любая команда из 5 человек может смело брать и использовать, и при этом поставить на студии ReSharper без каких-либо проблем.

ASP.NET vNext

Дино Эспозито обещал на киноуте .NEXT как раз и рассказать поподробнее про ASP.NET vNext, но тот факт что эта технология теперь едет и на Linux/OSX — это серьезно. У меня, например, все сайты используют ASP.NET (большинство – MVC, но один старый сайт 2003 года все еще на WebForms), и мне развитие ASP.NET только на руку – я вряд ли буду изучать такие вещи как Node/Ruby/PHP/whatever.

С другой стороны, я признаю что все классные фреймворки где-то за пределами .NET области: я про WordPress по сравнению с Orchard, например. Мне разработчики написали, что Orchard не будет работать с моим IIS 6 (да, у меня старый IIS, и что?), а мои попытки использовать .NETные блогодвижки, в т.ч. всякий адъ вроде N2… не, ну хорошо что такие фреймворки есть, но я честно, не фанат.

Что меня радует так то, что скорее всего мы увидим C# Native на не-Windows системах. А вот это уже интересно, т.к. нужно оно не только для вебного быстродействия, но и для того чтобы в некоторых случаях можно было не страдать с С++ (хотя я уже практически привык).

C++

Да, над С++ тоже поработали (что неудивительно), добавив помимо всего прочего поддержку мобильной разработки на С++ (не забываем, что теперь и Microsoft производит Android-телефоны, если что), ну и конечно же некоторые подвижки в плане C++11/14/17, такие как generic лямбды, await, и много всего другого.

Заключение

Не знаю насчет C++, а вот за .NET беспокоиться не стоит. Такая демократизация на руку всем, и я доволен что >10 лет назад я выбрал направление, которое пока и не думает умирать.

Если вас впечатляют эти подвижки и хочется «проникнуться» средой .NET, то все просто: приходите на .NEXT 8 декабря. Это большая .NET конфа в Москве. Там буду я, коллеги из комманды ReSharper, многие известные эксперты (в т.ч. много людей из «топа» .NET-секции Хабра), и много .NET разработчиков. До встречи!

Written by Dmitri

13 Ноябрь 2014 at 12:30

Опубликовано в .NET

Фотоотчет с конференции .NEXT

Я должен признаться, что я редко участвую в конференциях. Во встречах юзер-групп – да, бывает, но на конференции меня мало кто зовет (хотя доклады я подаю постоянно). Поэтому тот факт что я не только участвовал в конференции спикером но еще и принимал участие непосредственно в организации – это исключение из правил. А если учесть что конференция была в России — вообще курьез!

То что следует ниже – это небольшой фотоотчет о том что же собственно было, а также немного инфы о том кто на картинках. Основная программа пероприятия находится на http://dotnext.ru, но читать ее наверное не так интересно.

Итак, поехали.

Общая часть

Прежде всего, вот он – Алексей Федоров, человек без которого бы ничего этого не произошло. Алексей организует много конференций, в т.ч. Joker и JPoint, также именно он придумал логотип .NEXT (все варианты от дизайнеров были унылыми). Вообщем, respect!

Собственно сам киноут делал я :) рассказывал про то как эволюционируют процессы разработки, что нового и интересного, под конец поотвечал на вопросы зрителей, в очередной раз показал в деталях поддержку в R# интерфейса INotifyPropertyChanged :)

Далее в главном зале доклад делал Станислав Сидристый – рассказывал он про детали реализации CLR. Очень хардкорно, и насколько я знаю он теперь делает мероприятие в Москве, workshop как раз в продолжение этой темы.

Впрочем, меня там уже не было т.к. я в это время был у нашей «будки» вместе с еще одним соорганизатором конференции – Филиппом Торчинским:

Будка выглядит как-то одиноко, но на самом деле в перерывах там была масса людей, у меня даже голос сел после нескольких часов общения.

Часть 1я

Тем временем, конференция разделилась на 2 трека. В большом зале делал доклад Сергей Шкредов, тим лид команды ReSharper. Доклад был про организацию системы зависимостей в большом продукте, а Решарпер по меркам индустрии о-о-очень большой продукт, 300+ проектов.

В малом зале в это время выступал Рома Здебский, обсуждались новости с недавно прошедшей конференции BUILD. Многие пришли к нам как раз за этим докладом. Ну и конечно после конференции Рома еще долго общался с посетителями в кулуарах.

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

В малом зале доклад делал Алексей Садомов. Алексей – в прошлом один из активных участников Петербургской Группы Alt.Net – приехал к нам из Финляндии. Рассказывал он про интеграцию ASP.NET MVC приложений с Yandex.Market.

На этом этапе был кофе-брейк…

Часть 2я

После перерыва, в главном зале Влад Чистяков, наш коллега из JetBrains Moscow, рассказывал про фреймворк Nitra.

В это же время, Юлия Фаст из компании М13 (тоже кстати из Москвы) рассказывала про автоматизацию приемочного тестирования с помощью Fitnesse и TeamCity.

Далее, в главном зале был еще один доклад по TeamCity, уже непостредственно от сотрудника команды TeamCity. Евгений Кошкин расскывал про feature branches и их роль в процессе непрерывной интеграции.

А в малом зале, доклад проводил… я! Ну, как вы знаете, на любом эвенте бывают косяки и в этом случае, докладчик Виталий Баум (кстати тоже один из основателей Петербургской Группы Alt.Net) не смог к нам приехать, поэтому доклад мы делали по Скайпу. Виталий рассказал про то, как их компания использует Windows Azure для автоматизации управления функционалом автомобилей, а я в это время играл роль «ведущего телемоста» :)

Далее, Роман Белов (тоже из JetBrains) рассказал про профилировщик памяти dotMemory.

…а Станислав Сидристый в это время сделал короткий доклад на тему использования Xamarin для кроссплатформенной разработки.

Ну и в заключение, Антон Оникийчук (еще один человек из нашей ALT.NET тусовки) рассказал про использование TDD для MVVM приложений…

…а Павел Цытович из Luxoft Training в это время рассказал про использование WF для построения WCF сервисов. Я правда почему-то думал что WF уже умер в силу невостребованности, а оказывается нет.

Заключение

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

Мысли о следующией .NET конференции уже витают в облаках, но я пока обещать ничего не могу в силу огромных геополитических рисков. Надо еще посмотреть, выключат ли VISA/Mastercard 1го Июля, введут ли выездные визы, отменят ли двойное гражданство? Кто знает, кто знает…

Да, и кстати, вот все видеозаписи с конференции:

Written by Dmitri

18 Май 2014 at 15:13

Опубликовано в Events

Tagged with

Мысли о выборе технологий

Мне кажется, что идеальной состояние любой технологически ориентированной компании — это диверсификация. Иначе просто рискуешь нарваться на то что ты внезапно нерелевантен. Хороший пример – это разработчики Windows Mobile (это то, что предшествовало Windows Phone) — их по сути всех «кинули», и все их скилы (там .NET Compact Framework и иже с ним) внезапно стали бесполезны.

Я тут думал на тему того, на базе чего имеет смысл сегодня начинать писать новый продукт. Идеи у меня конечно все направлены в сторону «веба», т.к. и ежу понятно, что идеальная стратегия для конечного пользователя – это «облако», даже если это облако приватное, т.е. существует в пределах инфраструктуры компании, а не отдано «на аутсорс» всяким Amazon, Microsoft и так далее.

Так вот, все равно, в большинстве случае, на стороне сервера я прихожу к тому, что единственный возможный вариант для создания back-end’а чего бы то ни было это С++, и что все Java/.NET решения особого смысла для высокотехнологичных решений (а не решений в стиле «база для веб-мордочки») не имеют. Агрументация моя примерно такая:

  • Мы просто не можем позволить себе ограничивать себя в плане операционной системы. А это значит что можно использовать только то, что работает везде. Следовательно, сразу «отпадает» .NET т.к. при всей возможной опенсорсности Roslyn, использовать Mono я пока как-то не хочу.

  • Мы не можем себе позволить использовать новые, непроверенные, экспериментальные языки. Мне нравится язык D, например, но ему нужено еще очень много времени чтобы библиотеки во-первых починить где они не работают а во-вторых чтобы появились те либы, которых не хватает; ну и конечно вопрос с инструментарием и поддержкой тоже не решен.

  • Единственный способ воспользоваться интересным железом, которое на сервере совсем не зазорно размещать, это C/C++. Хотя по правде сказать, у Java есть поползновения сделать поддержку GPU на базе Aparapi (этот фреймворк в свое время поставляла ATI для использования OpenCL из Java), но GPU – это ведь только одна, причем не самая гибкая, технология ускорения вычислений.

Можно, конечно, использовать целый набор языков программирования — все равно в вебе придется использовать JS, например — но мне кажется что если использовать С++ как основу, то уже распыляться не имеет особого смысла. .NET и Java являются языками производительности (productivity languages), но мне кажется что они скорее являются языками лени. Конечно, разработка на С++ на первом этапе медленнее, зато преимущества, мне кажется, очень даже существенны:

  • Инструментарий (профиляторы, анализаторы) намного более зрелый

  • Библиотеки тоже намного более зрелые

  • Возможность оптимизации для конкретной архитектуры. (Надеяться на то векторизацию от какого-нть JIT компилятора – наивно.)

  • Намного более вменяемые подходы к параллелизации, как на декларативном (OpenMP) так и императивном уровне.

  • И да, тот факт что специфичные устройства (в моем случае – Tesla, Xeon Phi и FPGA) — всем могут быть запрограммированы на С++. Хотя в последнем случае все сложнее, т.к. OpenCL, который доступен для этих целей, мне пока не импонирует. Но рано или поздно придется и на него посмотреть.

Нравится вам это или нет, но типичные процессы рано или поздно все-таки перетекут в «удаленные» структуры, которые будут выделять на наши тривиальные задачи намного бо́льшие ресурсы чем те, которые может предоставить ваш ноутбук или рабочая станция. А соответственно, все эти кластеры тоже нужно программировать так, чтобы взаимодействие между машинами было наиболее прозрачным. И для этих целей у нас есть такие вещи как MPI, которые позволят строить гетерогенные сети как из машин, так и из устройств вроде Xeon Phi.

Конечно все это идиллия, и C#/Java программисты будут ругаться и плеваться от одного вида ручного управления памятью. Но зато если вы с самого начала работаете с ручным выделением/уничтожением, умными указателями и соответствующими паттернами использования, то вас уже ничего не должно пугать.

Written by Dmitri

18 Апрель 2014 at 23:40

Опубликовано в Technology

Мысли об облачных IDE

Мне кажется что никто на сегодняшний день не понимает, что такое облачные IDE. Если посмотреть на то, что люди реально пишут, получается у них следующее

  • Редактор в облаке который пусть и имеет подсветку синтаксиса, но остается достаточно рудиментарным и не обладает даже сотой долей набора фич, которые нужны современным пользователям всяких IDE.

  • Возможность сразу использовать 100500 языков, т.к. все компиляторы уже установлены и настроены. (Только в большинстве случаев разработчик использует один язык, но выбор – это все равно хорошо.)

  • Возможность компилировать и запускать программы в облаке соответствующий код в sandbox-е, так чтобы нельзя было снести к чертям всю систему. EdX даже умудрился сделать подобную штуку для CUDA, что не тривиально.

  • Коллаборативные возможности вроди sharing (a la GitHub Gist), ветвления (как в IdeOne) и прочие возможности, которые являются фактически source control-ом.

Социальная составляющая кодинга, как показывает GitHub – это очень хорошо. Но не хватает понимания того, что на практике нужны еще и

  • Работающий отладчик, который непонятно как делать в облаке т.к. это существенно понижает возможность разделения ресурсов: пока у меня стоит задетый breakpoint никто не имеет права трогать эту машину.

  • Поддержка тестирования — хочется иметь возможность запускать вагон тестов и фактически использовать серверную часть не только для continuous integration (это слишком просто), но именно для continuous testing в стиле NCrunch и подобных

  • Поддержка профилирования — это проще чем отладка и в принципе должно быть как-то реализуемо.

  • Поддержка деплоймента — чтобы готовые приложения сами разворачивались, клались в NuGet, и все такое

  • Поддержка мониторинга — раз уж на то пошло, почему бы не мониторить приложения и выдавать статистику по ним? Кстати, именно это уже делается в VS Monaco/Azure.

Основная проблема с Cloud IDE – это то что все забыли зачем облако. То есть облака рассматриваются как «социальный дропбокс», хотя на самом деле, облако – это место где хорошо масштабируются ресурсы. Зачем нужны ресурсы?

  • Во-первых, на (общих) серверах можно ставить более серьезное железо. Если учесть что разработчики для всех целей кроме CI не используют все мощности компа постоянно, покупка 32-процессорных систем с FusionIO и прочими вещами уже не кажется такой страшной.

  • Многие вещи параллелизуются. Например компиляция. Я уже какой год использую IncrediBuild вместо встроенного MSBuild. В облаке можно отмасштабировать компиляцию пропорционально размеру проекта.

  • Тестирование. Опять же, если тестов много, их можно параллелить. Так, отдельный разработчик может в моменте протестировать гигантский проект, потому что облако эластично и даст ему на это ресурсы.

  • Тестовое покрытие (code coverage) – тоже штука дорогая и в принципе на него можно выделать машины побыстрее.

Думаю идея понятна – эластичный рост облака до объема задачи позволит разработчику получать больше информации о своих наработках, и получать эту информацию быстрее (и в идеале – непрервыно). Но самое интересное я оставил напоследок, а именно:

  • Более глубокий анализ кода, включая спекулятивный анализ – это когда мы например меняем код в нужном (как нам кажется) направлении, перепрогоняем все тесты (ибо ресурсы позволяют) и замеряем перформанс дабы понять что лучше работает.

  • Перекрестный анализ проектов на предмет использования того или иного API. Мне почему-то кажется, что modus operandi взаимодействия с типовой библиотекой «шаблонизируется», и тем самым может быть использован для предоставляния пользователю более умных подсказок.

  • Можно использовать специализированное железо (например Xeon Phi) – возможность, которая недоступна большинству разработчиков ввиду дороговизны а также невозможности втиснуть такую карту в типичный MBP. (В теории, можно строить специализированное железо для ускорения задач программирования, но боюсь индустрия на такое не способна – не хватает кругозора и понимания вещей.)

Я надеюсь что рано или поздно можно будет использовать эти и другие возможности в облаках и на кластерах тоже. Когда – понятия не имею. Но мысли пока вот такие. А как еще можно использовать облако для разработки? Напишите в комментариях. ■

Written by Dmitri

10 Март 2014 at 23:23

Опубликовано в Development

Tagged with , , , ,

Мысли о «новом» обещанном нам C#

Как вы понимаете, Microsoft сейчас толком не до языковых фич т.к. сам компилятор переделали и даже уже сами переключились на Roslyn в процессе разработки, что как бы намекает на большие планы на 2014. Соответственно, те фичи которые Мадс осветил на NDC London не являются системообразующими, поэтому получите список:

  • Первичный конструктор в стиле class Size(int cx, int cy) { ... }, где как вы догадались, cx и cy это значения которые потом можно присвоить пропертям. Позволяет писать new Size(320,240), и вообще своровано с F#.
  • Возможность задавать значения readonly свойствам в стиле public int Width { get; } = cx. Даже не знаю что тут сказать – у меня часто свойства еще и в UI используются, а там все равно будет поле, так что нет разницы. (Ждите от Roslyn автореализации INPC? Не дождетесь.)
  • Property expressions, т.е. возможность писать property get без собственно блока get{}, return и прочих излишеств:
    public int Area => Width * Height;
    
  • Та же тема для методов. Фактически, просто удаление скобочек и return, но я уже вижу как новички пихают в эти стейтменты всякий мусор:
    public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
    
  • params IEnumerable, потому что когда хочется неограниченное число аргументов, то IEnumerable удобнее чем массив? На самом деле, могли как в D попробовать делать вещи через convention over configuration, т.е. вместо ключевого слова params просто сказать, что если есть только один параметр и он IEnumerable<T> или T[], то давать пользователям передавать массив через Foo(a,b,c) – и все были бы довольны.
  • Monadic null checking означает что вместо person.With(x => x.Address).With(x => x.HouseName) можно написать person?.Address?.HouseName, и везде будут проверки на null. Шикарно конечно, может немного поздновато, к тому же как показала практика, проверка на null – это не единственный concern, которых можно вкладывать в цепочки из лямбд.
  • Вывод типов для конструкторов, т.е. вместо Tuple.Create(foo,bar) можно наконец-то писать new Tuple(foo,bar)
  • Инлайновые декларации для out параметров по мне так самый большой фейл, пожалуй. Идея в том чтобы можно было писать
    if (foo.TryGetValue(out int x))
    {
      // use x, it's already been declared!
    }
    

    Ну и конечно идея в том что если параметров возврата несколько, то это как бы упрощает жизнь. Знаете что еще упрощает жизнь?

    let (x1,x2) = SolveQuadratic(1,10,16);
    

    И не важно, получили ли мы кортеж из (x1,x2) или просто две переменных – главное что результат метода записывается в том месте, в котором вы ожидаете, а не в аргументе, где декларации переменной – явно не место.

  • Импорт типа в пространство имен: уже хорошо, сделаем using System.Math чтобы не пользоваться поистине невменяемыми с точки зрения здравого смысла конструкциями вроде Math.Sin(). Хотя это только полумера: еще нужно удалить заглавные буквы (ну зачем они?), добавить оператор возведения в степень (с целочисленной перегрузкой), и уже будет можно дышать. Но разве ж кто-то об этом думает?

Ничего из списка выше особо не впечатляет. Гораздо интересней сам Roslyn (все же надеюсь что он будет «готов» к VS2014), ну и как это не странно, С++ сейчас развивается как-то быстрее, причем без всякого переписывания компилятора. ■

Written by Dmitri

21 Декабрь 2013 at 13:36

Опубликовано в C#

Отслеживать

Get every new post delivered to your Inbox.

Join 111 other followers