Сейчас только ленивый не выпускает свои собственные подборки интересных материалов. Вот и я решил не отставать от мейнстрима и добавил новую и, надеюсь, постоянную рубрику в свой блог.
Подобные дайжесты обычно являются субъективными и прежде всего покрывают темы, которыми интересуется его автор. Данные подборки не будут исключениями и будут касаться прежде всего .NET-направления, дизайна/архитектуры, ну и разработки ПО в целом. При этом, в ней могут встречаться ссылки не только на новые материалы, но и на что-то довольно старое, и всем давно известное, но открытое автором сего блога лишь недавно. Главный критерий будет отдаваться не столько новизне, сколько качеству материала.
Итак, начнем.
Конференции/выступления
Connect 2015. 18-19 ноября
Майкрософт проводит две крупные девелоперские конференции в год. //BUILD весной и Connect – осенью. Опавшие листья и мерзкий дождь за окном намекают, что до весны еще далеко, а значит большая осенняя конференция не за горами.
Connect 2015 будет проходить на следующей неделе, 18-19 ноября. А это значит, что очень скоро будут интересные новости, громкие анонсы и всякое такое.
MVP Summit 2015. 2-5 ноября
Большая часть выступлений на MVP саммите проходят под NDA, но есть и исключения. Так, уже доступны 3 сессии из треков про ASP.NET. Вполне возможно, со временем будут доступны и ряд других не-NDA-шных выступлений.
DevLabs 2015. 18 октября
Понимаю, что не скромно ставить нашу онлайн конференцию наряду с коннектом и MVP-шным саммитом, но не сказать об этом нельзяJ. Почти месяц назад прошла конференция DevLabs по .NET и недавно стали доступны записи выступлений:
- Выступление Андрея Гордиенкова «Транзитивные зависимости: они не те, кем кажутся».
- Выступление Андрея Акиньшина «Учимся замерять время правильно»
- Мое выступление с темой «Пишем анализаторы на базе Roslyn»
- Выступление Алены @lenadroid Денисенко «Инновационные инструменты для распределённого программирования»
Build Stuff Ukraine 2015. 23-24 ноября
Совсем не .NET-я конференция, но, во-первых, там очень много интересного, а во-вторых, она проходит в Киеве. Там много крутых спикеров, а значит и интересных докладов. Если есть возможность, обязательно приходите!
Статьи
C#/.NET
- Outline of C# 7 demo at MVP Summit 2015-11-02
Текст выступления Нила Я-Еще-И-Джаву-Знаю Гафтера (Neal Gafter) на MVP саммите о новых возможностях будущей версии C#. В заметке покрыты две из них – локальные функции и паттерн-матчинг. Видео, к сожалению, не будет, ибо NDA. - Looking Ahead to C# 7 with Mads Torgersen
Видео с channel9 с Мэдсом Я-Знаю-Все-О-C# Торгесеном в главной роли. Отличный обзор того, что нас ждет в будущей версии языка C# и немного о том, что есть в текущей. - Proposal: Nullable reference types and nullability checking
Уже довольно старая публикация от Мэдса Торгесена о nullable/non nullable типах в C# 7. Два ключевых момента: ссылочные типы станут по умолчанию non nullable, и появится nullable reference типы (object?). При этом появится путь миграции старого кода. По сути, пока что команда разработчиков C# идет путем Eiffel-а, где было принято аналогичное решение. Забавно, что в разговоре с Мэдсом я упомянул о сходстве предложенного похода с подходом Eiffel-а и был очень удивлен, когда узнал, что Мэдс не в курсе этого дела. Great minds think alike и все такоеJ (это я про команду C# и Eiffel, если что). - Pattern matching in action using C# 6.0 by Tomas Petricek
Забавная статья Томаша F# Петричека о паттерн матчинге в текущей версии C#. Спойлеры: статья была опубликована 1-го апреля, но почитать все же интересно.
Общие вещи
- Software Leadership #9: On the Importance of Intellectual Honesty by Joe Duffy
Очередная статья Джо Конкурентное-Программирование Даффи о лидерстве. На этот раз о пользе честности и важности признания своего незнания. Да, предыдущие заметки из этой же серии тоже очень хороши. - Blogging about Midori by Joe Duffy
Помимо философского поста, Джо Я-Писал-ОС-ку-На-Менеджт-Языке Даффи начал серию постов о проекте Мидори (Midori), над которой он работал несколько лет до перехода в команду языков программирования.
Это был очень интересный проект, над которым трудились пара десятков ярчайших специалистов. Там была и операционка, менеджт язык системного уровня и много чего еще. Сверх интересное чтиво!
Новые релизы
- Уже месяц как вышел TypeScript 1.6
Из самого вкусного – кастомные type guard-ы с помощью которых можно хитро даункастить объекты к нужному типу и удобно работать с Union типами. - Building F# Type Providers by Dave Fancher at Pluralsight
На pluralsight-е появился интересный курс от Дейва А-Кто-Это-Такой Фанчера о тайп-провайдерах в F#. Если эта тема интересна, то курс точно пригодится.
З.Ы. Спасибо за внимание и если есть что-то интересное, чем хочется поделиться, то не стесняйтесь и публикуйте ссылки в комментариях.
>Proposal: Nullable reference types and nullability checking
ОтветитьУдалитьНо ведь это решение не гарантирует отсутствия NRE, в отличии от решения в Эйфеле. По сути они предлагают то, что уже умеет решарпер через [CanBeNull] и [NotNull] атрибуты. Куда как слабее решение.
Но ведь и Эйфель не гарантирует отсутствие NRE, правда. Особенно если целиться в платформу .NET, со всякими финализаторами, которые могут быть вызваны при наличии исключения в конструкторе базового класса.
УдалитьМне пока кажется, что подходы очень похожи. Тот же самый "Certified Attachment Pattern", когда внутри блока if (x != null) { } х считается non nullable. Те же самые правила attached/detached, что по умолчанию все сущности non nullable (a.k.a. detached). Те же правила definite assignment-а, которые в Эйфеле называются Variable Initialization Rule.
Я как-то не пойму, в чем столь грандиозные отличия от Эйфеля? В чем слабость-то?
>Но ведь и Эйфель не гарантирует отсутствие NRE, правда.
УдалитьЯ, возможно, не правильно понял пейпер, но мне кажется, что они как раз дают гарантию того, что если программа скомпилировалась, то она никогда не упадёт с NRE. "If a compiler accepts a program, it must guarantee the absence of void calls in any execution of the generated code." Т.е. они статически гарантируют что в attached переменной типа T никогда не будет void.
И отличие в том, что этот proposal не даёт такой гарантии. И warnings as errors не поможет. Например я пишу библиотеку на C#7 и в ней есть такой метод:
public int Length(string s)
{
return s.Length;
}
Должен ли я проверить s на null? Семантически указание типа string без ? значит что s не может содержать null. Но компилятор этого не гарантирует! Клиент, вызывающий метод, может вызвать Length(null) и проигнорировать ворнинг компилятора. И я как и раньше должен буду руками проверить s на null и кинуть ArgumentNullException если что. Поэтому я считаю такое решение слабым.
Я конечно понимаю, что в рамках дотнета дать такую гарантию очень сложно (невозможно?) из-за сотни хитрых кейсов и зоопарка языков. Но хотя бы в рамках C# и повседневной работы я хочу гарантии.
Команда C#/VB осознанно пошли на то, что void safate рулы должны выдавать предупреждения, а не ошибки, просто потому что ГАРАНТИРОВАТЬ отсутствие NRE - нельзя. Понятно, что хочется, но нельзя. И не в рамках .NET-а, а и в рамках C#-а.
УдалитьПри этом, для меня, как для разработчика, предупреждение и ошибка - квивалентные вещи. И для вас это должно быть тоже самое:) Просто есть возможность у любой диагностики настройками поднять приоритет, да и вообще, билд с ворнингами считается поломанным.
В целом, C# и Eiffel используют ровно один и тот же подход. В случае приведенного метода Length проверка не нужна, поскольку неправильное поведение будет отловлено компилятором. Если не будет отловлено и вы знаете, что вас будут потреблять не только C# 7, но и ранние версии (что бывает, на самом деле, не так и часто), то придется вернуться к старой проверке. Да, это не идеально, но это обратная совместимость, которую ломать нельзя. И это одна из причин, почему выдается предупреждение и почему тип аргумента s остается неизменным.
Вот классический пример почему гарантировать non nullability в C# нельзя:
class Base { public Base() {throw new Exception();}}
class Derived {
private /*not nullable*/object x;
public Derived() {x = 42;}
~Derived() {x.ToString(); // NRE}
}
Поскольку финализатор будет вызван для неполностью сконструированных объектов, то в финализаторе x будет null, хотя компилятор этого знать не может.
Про пример с финализатором - можно запретить иметь в классе с финализатором non nullable поля и свойства :) Есть ещё проблемы утекания не полностью проинициализированого объекта из конструктора, вызов виртуальных методов из родительского конструктора, код вида T t = default(T), инициализация массивов, ссылочные поля в структурах создаваемых через default() и т.д. Это всё вряд ли можно сделать по настоящему null safe без ломания обратной совместимости и поддержки со стороны CLR. Но в этом и слабость этого решения.
УдалитьОтсутствие гарантий значит что я не могу до конца положиться на компилятор и перестать думать о null safety. А что если автор сборки, которую я юзаю, забил на ворнинги? А что если я сейчас в одной из тех ситуаций, в которых компилятор пасует? И где вообще получить полный список таких ситуаций? Отличается ли набор недетектируемых проблем между разными версиями компилятора и разными компиляторами (Mono)?
Плюс фича в этом виде даёт иллюзию безопасности, что даже может привести к увеличению количества багов из-за не написаной проверки на null. И хорошо если результатом будет падение, а не сохранение невалидного объекта в базу.
Механизмы же обеспечения null safety (Certified Attachment Pattern etc) в С# и Эйфеле действительно очень похожи. Кстати вы не знаете других примеров добавления null safety во взрослые языки? Каким путём пошли там?
Вы в первом абзаце даете еще пару примеров, которые показывают, что команда C#/VB идут правильным путем. Можно, конечно, сказать, что давайте запретим передачу несконструированных объектов, запретим вызов виртуальных методов из базового класса (это еще один способ получить null у non-nullable типа) и все будет хорошо. Но, на практике, все равно гарантий не будет или стоимость обеспечения этих гарантий будет слишком высокой.
Удалить> А что если автор сборки, которую я юзаю, забил на ворнинги?
А вот тут мы возвращаемся к контрактному программированию. Если юзер уже перешел на C# 7.0, то сигнатура метода четко говорит о ее контракте: наличие null-а является недопустимым И означает баг в вызывающем коде. От этого защититься очень сложно. Вообще, ни один из существующих механизмов не предназначен для защиты от дурака. Я могу показать пару примеров с union-ами, которые без unmanaged кода будут ломать типизацию и изменять readonly переменные. Все это возможно, вопрос в другом: насколько легко ОСОЗНАННО пропустить подобное предупреждение компилятора? Если сделать это сложно, то фича годная. Если легко - то нет.
Камрады из C#/VB столкнулись с серьезной проблемой: как добавить в язык что-то, что гарантировать нельзя? Если пойти по пути ворнингов, вы будете недовольны. Если пойти по пути ошибок и запрещений, то другие будут недовольны. Это одна из главных проблем при добавлении таких фундаментальных фич в зрелый язык - кто-то будет недоволен. Приходится идти на компромиссы. Мне кажется, выбранный компромисс разумным и null safety улучшится, а не ухудшидся. Понятно, что у меня с предсказанием будущего плохо и все может оказаться по другому. Посмотрим.
> Кстати вы не знаете других примеров добавления null safety во взрослые языки? Каким путём пошли там?
Есть куча ФП языков и гибридов (типа Swift-а) с этими возможностями, но там они были изначально. Так что других примеров, я не знаю.
По поводу F#, не так давно вышел еще один курс по Type Providers: https://www.pluralsight.com/courses/accessing-data-fsharp-type-providers
ОтветитьУдалитьДа я вообще хотел добавить курс Томаша, поскольку видел его анонс, но как-то не наткнулся на него просматривая новые курсы на pluralsight-е.
УдалитьОбязательно добавлю его.
Похоже, на вопрос с nullable однозначного ответа нет. В Свифте сделали гарантию, но там теперь ад из ? и !
ОтветитьУдалитьВариант с предупреждениями и почти гарантированным string против string? мне нравится. Особенно учитывая обратную совместимость, это хороший компромис.
Если клиент игнорирует предупреждение Length(null), он получит NRE, если нет, не получит. Можешь включить warnings=errors, и будет строгая проверка.
Например. Я бы не стал инициализировать некоторые свойства класса в проекте с тестами, даже если при нормальной работе они все строго не null.
Вообще, практически все, что обсуждалось в видео с Мэдсом Торгесеном — фичи Свифта за последние два года (и в основном не оригинальные идеи, а все из других языков). Мне нравится, как языки сходятся к общему синтаксису.
С наступающим Новым Годом, Сергей! Всегда с удовольствием читаю твой блог. Желаю тебе в Новом Году больших успехов в нашем нелёгком деле и семейного счастья (ведь это также требует немалых усилий :))! Очень надеюсь, что когда-нибудь удастся вместе поработать или хотя бы пересечься на конфе!)
ОтветитьУдалитьСпасибо за поздравления и теплые слова! Тебя тоже с наступающим, и буду очень рад пересечься как появится такая возможность.
Удалить