Для начала несколько вещей о которых вы могли не слышать:

• Идентификаторы в C# могут включать в себя escape-последовательности Unicode символов (как например \u1234).
• Идентификаторы в C# могут включать в себя Unicode символы категории Cf (other, format), но при сравнении идентификаторов на идентичность эти символы игнорируются.
• Символ «Монгольский разделитель гласных» (U+180E) в зависимости от версии Unicode принадлежит либо категории Cf (other, format), либо категории Zs (separator, space).
• В .NET хранится свой собственный список Unicode категорий, независимый от оных в Win32.
• Roslyn является .NET приложением, и поэтому использует Unicode категории, прописанные в файлах .NET. Нативный компилятор (csc.exe) использует либо системные (Win32) категории, либо хранит в себе копию таблиц Unicode.
• Никакая из таблиц Unicode символов (ни .NET, ни Win32) точно следует какой-либо из версий стандарта Unicode.
• Компиляторы могут иметь баги.

Из всего этого вытекают некоторые проблемы…

Во всём виноват Владимир

Все началось с обсуждения на собрании технической группы ECMA на прошлой неделе. Мы рассматривали «нормативные ссылки», и в частности какую версию стандарта Unicode мы будем использовать. На тот момент спецификация ECMA-335 (4-ое издание) использует Unicode 4.0, а спецификация C# 5 от Microsoft использует Unicode 3.0. Я точно не знаю, учитывают ли разработчики компиляторов такие особенности. На мой взгляд было бы лучше, если ECMA и Microsoft не указывали конкретную версию Unicode в своих спецификациях. Пусть разработчики компиляторов используют самую свежую версию Unicode, доступную на текущий момент. Однако тогда компиляторы должны будут поставляться со своей личной копией таблицы Unicode, что немного странно, на мой взгляд.

Привет, Хабр!

В комментариях к моей статье История портативных игровых консолей. Часть 1 (До 2000 года) вы указали мне на отсутствие некоторых игровых консолей, которые были доступны в 1990-х. Поэтому я написал это дополнение.

Список консолей в этот раз:

• Brick Game
• Sega Nomad
• Game.com
• Visual Memory Unit для DreamCast
• Neo Geo Pocket
• Neo Geo Pocket Color
• WonderSwan
• WonderSwan Color

Статья про то, что делать тем, кто хочет переехать работать в США. Я предполагаю инженерные позиции, на которые проще всего получить визы, но, возможно, статья окажется полезна и другим специалистам.

Мой опыт несколько отличается от нижеописанного (я попала на работу в США после стажировки). Но за 4 года в США пообщалась с людьми, которые попали сюда разными путями и набрала кое-какой опыт. Так что если бы я очень хотела найти работу в США сегодня, то я бы действовала примерно так, как описано ниже.

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

Итак, мы открыли для себя Dependency Injection, уяснили все его плюсы и несомненные пользы и начали вовсю применять его в своих проектах. Давайте посмотрим, что же еще можно делать при помощи Dependency Injection на примере библиотеки Ninject.

Для работоспособности кода нам понадобится, помимо непосредственно Ninject, установить еще три расширения: Ninject.Extensions.Factory, Ninject.Extensions.Interception и Ninject.Extensions.Interception.DynamicProxy. Эти расширения доступны в NuGet с соответствующими идентификаторами.

Как известно, при использовании интерфейса IEnumerable<> там, где подразумевается коллекция, могут случаться проблемы (см. например Проблемы использования IEnumerable и LINQ против LSP). К счастью, в .NET v4.5 в 2012-м году (немного поздновато, но лучше поздно, чем никогда), появились интерфейсы IReadOnlyCollection<>, IReadOnlyList<>, IReadOnlyDictionary<> (далее буду их обобщённо называть IReadOnly-интерфейсы). В отличие от IEnumerable<>, IReadOnly-интерфейсы дают возможность достаточно и без лишних требований обозначать функциональность коллекции, что и позволяет их рекомендовать для использования вместо IEnumerable<> везде, где подразумевается чтение коллекции. Но тут встречается одно затруднение. Одним из важных компонентов, потребляющим и создающим коллекции, является LINQ и, особенно, его часть «LINQ к объектам». К сожалению, IReadOnly-интерфейсы появились через 5 лет после LINQ, и в нём не используются. Все входные и выходные коллекции LINQ-операций имеют базовый тип IEnumerable<>, исходя из ограниченных возможностей которого, многие операции подразумевают лишние затраты: полный последовательный перебор или даже создание промежуточных копий входных коллекций. Более того, возвращая из операций тот же IEnumerable<>, LINQ требует при дальнейшем использовании результата опять использовать полный перебор и создание промежуточных копий. В связи с этим, у меня давно зрела мысль «подружить» LINQ с IReadOnly-интерфейсами.

Помните, у Урсулы Ле Гуин в «Волшебнике Земноморья»: «Никогда не спрашивайте человека о его имени. Никогда не называйте своего». К сожалению, Entity Framework «из коробки» совершенно не руководствуется этим замечательным правилом, и при генерации классов на основании схемы базы данных (стратегия Database First) именует классы, свойства классов и навигационные свойства именно так, как именуется соответствующая таблица в БД.

А что делать, если есть задача разработать новый проект к уже существующей базе данных, в которой таблицы именуются по некоторому шаблону, скажем, по шаблону t_tablename (напр. t_order_product). А в проекте принято совершенно другое соглашение об именах, и разработчики желают видеть «человеческие», с их точки зрения, имена (OrderProduct). Конечно, можно выкрутиться из ситуации, приняв соответствующее административное решение, однако иногда очень не хочется идти наперекор чувству прекрасного.

Вступление

Веб разработка, а именно фронт-энд разработка становится, как и традиционная бэк-энд разработка, все комплекснее и мудренее. Множество проектов нуждаются в большем, нежели банальная закачка пары JS и CSS файлов по FTP. Сейчас мы можем наблюдать так называемый процесс сборки фронт-энда, который может включать компиляцию SASS и LESS, сжатие CSS/JS, запуск JSHint или JSLint и многое другое. Эти сборочные задачи и процессы координируются такими инструментами как Gulp или Grunt. Так же клиентскими библиотеками можно управлять используя различные системы управления пакетами как npm или bower.

Многим разработчикам и тестеровщикам, использующим Visual Studio, известен Брайан Келлер (http://blogs.msdn.com/b/briankel/ ) с его регулярно обновляемой виртуальной машиной, которая содержит последнюю версию Visual Studio и всю необходимую инфраструктуру для изучения и оценки всех возможностей средств разработки. Эта виртуальная машина сопровождается набором лабораторных работ aka.ms/VS13ALMVM, которые уже помогают оценить возможности средств разработки или даже научиться использовать новые возможности о которых вы либо не знали, либо не пользовались раньше.

Лабораторные работы — на английском языке, и каждый раз, когда мы рассказывали об этом наборе лабораторных и виртуальной машине, нас просили сделать эти лабораторные работы доступными на русском языке.

Сегодня мы рады сообщить, что благодаря ahriman, мы запустили проект по локализации этих лабораторных работ. Встречайте — первый набор из 4-х локализованых лабораторных работ, которые покрывают тему управления тестированием в Visual Studio 2013!

Привет всем!

Сегодня поговорим о новых возможностях, касающихся уведомлений в Windows/Windows Phone 8.1. Обсудим какие типы уведомлений существуют, каким способом их организовать в своем приложении, а также отметим одну из главных новинок для Windows Phone устройств — Центр уведомлений (Action Center).

Здравствуйте. Прошло много времени после моих постов на хабре (тык, тык) на тему Consulo. Ниже расскажу, что изменилось за это время.

Для тех, кто пропустил мои посты:

Consulo — это форк IntelliJ IDEA Community Edition, который имеет поддержку .NET(C# на текущий момент), Java, Javascript(NodeJS), и многое другое. Проект собрал множество открытых плагинов в себе. При этом код остался открытым.

Повсеместно принято, что в «серьезных» CRUD приложениях база данных становится во главу угла. Ее проектируют самой первой, она обрастает хранимыми процедурами (stored procedures), с ней приходиться возиться больше всего. Но это не единственный путь! Для Entity Framework есть Code First подход, где главным становится код, а не база. Преимущества:

• Никакого генерированного кода
• База — это снова просто хранилище. Над ней не надо дрожать, дропается легко и без проблем.
• Простейшая установка среды разработки. Выкачал код и запустил — никакой возни с бэкапами.

Есть и пара недостатков, но они скорее связаны с Entity Framework, а не с Code First подходом как таковым; о них чуть позже.

Ниже я покажу на примере, насколько просто разрабатывать с Code First подходом.

Привет Всем!

Представляю вашему вниманию новый инструмент от Microsoft «Windows App Studio» — конструктор для создания приложений. Сегодня расскажу о том, как обычному пользователю стало доступно создание приложений для Windows и Windows Phone. И немного о том чем этот инструмент может быть полезен разработчику.

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

Эта статья входит в серию статей по улучшению производительности в .NET. Первую статью можно найти здесь.

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

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

• Вы пишете новый код и решили делать это немного лучше и с экономией
• Вы дошли до этапа, когда начались оптимизации и рефакторинг, поэтому просматриваете и меняете участки кода, которые выполняются очень часто
• Вы пишете высокопроизводительную систему и экономите на спичках

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

Не знаю почему, но информации об этом новом класса в .NET Framework, действительно немного. Документация MSDN почти ничего не говорит о способах использования SynchronizationContext. Должен сказать, изначально я и сам плохо представлял назначение этого класса и как его использовать. После продолжительного изучения вопроса я наконец понял его назначение и решил написать эту статью чтобы помочь разобраться другим разработчикам.

Xamarin — продукт, дающий возможность используя .NET писать приложение сразу под 3 мобильные платформы — Android, iOS и Windows Phone. Не так давно в продукт добавлена новая технология — Xamarin.Forms, позволяющая писать один XML-файл с разметкой на все платформы сразу. Но насколько эта технология готова к использованию в продакшене?

Миграции в Entity Framework (EF) представляют собой строго типизированный подход для выполнения распространенных операций, таких как создание, изменение и удаление таблиц, столбцов, индексов, и т.д. Однако реализация базовых операций достаточно ограничена и не поддерживает весь спектр параметров, которые поддерживает та или иная СУБД.

До EF 6, единственным способом обхода данного ограничения было использование операции Sql, которая позволяет выполнить произвольную команду SQL при выполнении миграции. В EF 6 также появилась возможность реализации пользовательских строго типизированных операций.

Привет, хабр.

Я разрабатываю плагин под Java приложения для запуска кода на .Net. Проект открытый, выложен на GitHub. И в какое-то время я решил, что хорошо бы найти Continious Build & Test такой, чтобы я смог в нем собирать продукт.

После небольших поисков мне попалось на глаза довольно интересное и простое решение.

Disclaimer: я не имею никакого отношения к разработке этого продукта, не знаю автора и т.д. Мне просто понравился этот сервис, и я решил написать пост.

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

Переведено в Alconost.

Платформы WPF и Silverlight используют язык разметки XAML для описания элементов пользовательского интерфейса, шаблонов и стилей. Если вы разрабатываете одновременно под разные XAML платформы, то естественно, возникает желание иметь общие файлы разметки для этих платформ.

Разметка в WPF и Silverlight очень схожа, но имеются досадные отличия, которые сильно осложняют ее шаринг. В нашей компании эта проблема была решена несколько лет назад в виде внутреннего инструмента, который называется WPF2SL.

WPF2SL слишком специфичен, чтобы быть полезным широкой публике, поэтому мы не планируем его публиковать. В этой статье я расскажу об особенностях XSLT преобразований применительно к разметке XAML и о некоторых сложностях и особенностях, с которыми мы столкнулись.