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

Я думаю, что многие разработчики знают, что цикл foreach в языке C# не так прост, каким он кажется на первый взгляд. Для начала давайте ответим на вопрос: «А что нужно, чтобы конструкция foreach успешно компилировалась?». Интуитивным ответом на этот вопрос кажется что-то типа: «Реализация классом интерфейса IEnumerable или IEnumerable<T>.». Однако, это не так, ну, или не совсем так.

Полный ответ на этот вопрос такой: «Для того чтобы конструкция foreach успешно компилировалась необходимо, чтобы у объекта был метод GetEnumerator(), который вернет объект с методом MoveNext() и свойством Current, а если такого метода нет, то тогда будем искать интерфейсы IEnumerable и IEnumerable<T>».

Причин у такого «утиного» поведения две.

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

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

В прошедний понедельник мне посчастливилось попасть на собеседование на Senior .Net Developer в одну международную компанию. Во время собеседования мне предложили пройти тест, где ряд вопросов был связан с .Net. В частности в одном из вопросов надо было дать оценку (истина/ложь) ряду утверждений, среди которых было и такое:

В .Net любой массив элементов, например int[], по умолчанию реализует IList, что позволяет использовать его в качестве коллекции в операторе foreach.

Быстро ответив на этот вопрос отрицательно и отдельно дописав на полях. что для foreach необходима реализация не IList, а IEnumerable, я перешел к следующему вопросу. Однако по дороге домой меня мучал вопрос: реализует ли массив все-таки этот интерфейс или нет?

Про IList я смутно помнил, что этот интерфейс дает мне IEnumerable, индексатор и свойство Count, содержащее число элементов коллекции, а также еще пару редко используемых свойств, типа IsFixedCollection(). Массив имеет свойство Length для своего размера, а Count в IEnumerable является методом расширения от LINQ, что было бы невозможно, если бы этот метод был реализован в классе. Таким образом, получалось, что массив не мог реализовывать интерфейс IList, однако какое-то смутное чувство не давало мне покоя. Поэтому вечером после интервью я решил провести небольшое исследование.

Валялся я на прошлой неделе в больнице. И так как обсуждать с дедушками в холле рецепт яблок, мочёных в капусте, и как хорошо на Покров гулять по заливным лугам — особого желания не было, пришлось придумывать себе развлечение.

Я задумался об игре «Жизнь», которую на Хабре не так давно вспоминали. Мне стало обидно за несчастные клетки, которые живут и умирают в зависимости от одних только начальных условий, и ничего сами для своего выживания сделать не могут. В результате я придумал расширение для правил игры, с которым можно моделировать не только изменение численности популяции, но и естественный отбор внутри неё.

Самые нетерпеливые сразу могут посмотреть, что получилось, а остальных прошу под кат за рассказом.

Приветствую вас, хабражители!

Недавно прочитал статью про игру Жизнь, и вспомнилось мне, что я в мае этого года начинал писать свой проект подобной направленности. Только вот интерес к нему за рутиной работы быстро угас, хотя написано было немало. И сейчас, вдохновлённый этой статьёй, я взял этот проект с пыльной полки и добавил несколько фич, о которых расскажу далее.
Вкратце, мой вариант имеет следующие условия:

• жизнь развивается на поле 256*256 клеток;
• на поле могут размещаться объекты трёх типов: живность, пища(назовем её травой) и камень (препятствие);
• живность представляет собой фактически модифицированную машину Тьюринга, если точнее, то это больше похоже на Автомат с магазинной памятью, т.е. живность является «процессором», выполняющим свой «генетический» код;
• живность имеет возможность совершать определенные действия (двигаться, есть, размножаться (пока только клонированием, мутации будут со дня на день, скрещивание в перспективе)), отдавая соответствующие команды;
• наступив на траву, живность её вытаптывает;
• для поглощения еды надо дать команду «Ешь в этом направлении!», находясь в соседней клетке;
• живность имеет память, что позволяет строить циклы, условия и т.п., т.е. полная по Тьюрингу (поправьте меня, если не прав!), объем памяти неограничен;
• живность может складывать и вычитать значения в уме, разрядность ограничена одним байтом;
• существует возможность реализации генетических алгоритмов (пока не реализовано).

Кому интересны подробности, прошу под кат!

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

Такая же проблема встала и передо мной при проектировании высоконагруженного сервера системы мониторинга транспорта на .NET. В итоге, было принято решение, что кэшам – быть. Кэши словарей стали храниться в обёртках над ConcurrentDictionary. Этот вариант был взят без особых исследований, поскольку является стандартным средством .NET для потокобезопасных словарей. Теперь настало время проверить производительность данного решения. Об этом, собственно, статья. Также в конце статьи будет небольшое исследование того, как устроен внутри ConcurrentDictionary.

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

И вот я вспомнил что мне где-то встечалось понятиe Behavior-Driven Development и тесты написанные в этом стиле намного читабельнее и понятнее. По запросу «nunit bdd» гугл выдает совсем немного результатов, но этот пост навел меня на интересную мысль. Методы Given и When не дают четкого описания условия и тем более описать больше чем одно условие наглядно не получится. Я решил слегка доработать решение.

Вот, кстати, то самое имя теста:
CreateMonthlyPaymentInvoice_WhenCustomerIsRegularCompany_ShouldCreateMonthlyUsageInvoiceWithoutBankFee.
Жутко, правда?

Moles – это легковесный тул от MS Research, который умеет автоматически генерировать заглушки для интерфейсов и виртуальных методов, а также для sealed классов, невиртуальных и статических методов (!), путем генерации кода, которому позднее можно будет подсунуть нужный делегат, вызываемый вместо определенного метода. Первый тип заглушек называется стабы (stubs), а второй – молы (moles). Именно эту штуку я использовал для тестирования асинхронных операций, о которых я рассказывал ранее, но давайте обо всем по порядку.

Stubs

Давайте рассмотрим такой пример. Предположим, что мы понимаем ценность модульных тестов, а также таких принципов, как Dependency Inversion, и других безумно полезных принципов и паттернов (может быть всех остальных принципов S.O.L.I.D., а возможно даже и F.I.R.S.T.). И дело даже не в том, что мы фанаты тестов или дядюшки Боба, а просто потому, что мы знаем, что высокая связность – это плохо. Поэтому мы стараемся в разумных пределах уменьшить зависимости путем выделения интерфейсов с последующим «инжектом» их в конструкторы классов или в методы, которым эти интерфейсы необходимы для выполнения своих задач.

Идиома RAII (Resource Acquisition Is Initialization) берет свое начало в языке С++ и заключается в том, что некоторый ресурс захватывается в конструкторе объекта, и освобождается в его деструкторе. А поскольку деструктор локальных объектов вызывается автоматически при выходе из метода (или просто из области видимости) не зависимо от причины (нормальное завершение метода или при генерации исключения), то использование этой идиомы является самым простым и эффективным способом написания сопровождаемого C++ кода, безопасного с точки зрения исключений.

При переходе к «управляемым» платформам, таким как .NET или Java, эта идиома в некотором роде теряет свою актуальность, поскольку освобождением памяти занимается сборщик мусора, а именно память была самым популярным ресурсом, о котором приходилось заботиться в языке С++. Однако поскольку сборщик мусора занимается лишь памятью и никак не способствует детерминированному освобождению ресурсов (таких как дискрипторы операционной системы), то идиома RAII все еще применяется и в .NET, и в Java, пусть мало кто из разработчиков знает об этом замысловатом названии.

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

Так получилось, что год назад, мне пришлось написать билд-план с использованием ant. Он предназначался для нашего небольшого веб-проекта, исполнялся на Hudson и должен был производить: компиляцию, прогон NUnit тестов, подсчет % покрытия кода тестам, поиск дублирующегося кода и выявление основных стилистических несоответствий в коде. Но это вступление, а далее поговорим, о написании билд-плана для анализа файлов проекта, посредством FxCop.

И так! Поехали!

Рассмотрим некоторые части .Net Framework'a, выглядящие тривиальными, но вполне способными сделать ваш код более простым как в написании, так и в сопровождении.


Пишущие на .NET (а если вы этого не делаете, то зря читаете этот пост) наверняка время от времени используют для своих нужд структуру DateTime. Эта структура удобна для хранения дат, времени или даты/времени, относящихся к локальной временной зоне (или же к UTC).


Однако, бывают случаи, когда вам необходимо сохранить время в виде смещения, а не конвертировать его в локальное время. И вот здесь вам на помощь придёт структура, впервые появившаяся в .NET 3.5 — DateTimeOffset.

Замечания:
1. В предыдущей заметке "time zone" я перевёл как «временнАя зона», поскольку речь шла о часовых поясах США, имеющих специфическое название. В данном случае корректнее использовать "часовой пояс". Здесь используется более корректный перевод.

2. Небольшая врезка из Википедии даст вам понимание что такое UTC и чем оно отличается от GMT —

Всеми́рное координи́рованное вре́мя (UTC) — стандарт, по которому общество регулирует часы и время. Отличается на целое количество секунд от атомного времени и на дробное количество секунд от всемирного времени UT1.

UTC было введено вместо устаревшего среднего времени по Гринвичу (GMT). Новая шкала времени UTC была введена, поскольку шкала GMT является неравномерной шкалой и связана с суточным вращением Земли. Шкала UTC основана на равномерной шкале атомного времени (TAI) и является более удобной для гражданского использования.

Часовые пояса вокруг земного шара выражаются как положительное и отрицательное смещение от UTC.

Следует помнить, что время по UTC не переводится ни зимой, ни летом. Поэтому для тех мест, где есть переход на летнее время, меняется смещение относительно UTC.


Теперь продолжим разбираться со структурами, обслуживающими такие сущности, как дата и время.

Через некоторое время после публикации твита о Noda Time, меня начали спрашивать, какой смысл в использовании Noda Time — люди верили, что поддержка дат и времени в .NET вполне хороша. Я конечно не видел их код, но подозреваю, что практически любая кодовая база, имеющая дело с датами, станет яснее, если будет использовать Noda Time, а также, вполне возможно, станет более корректной благодаря подходу, с помощью которого Noda Time заставляет вас принимать некоторые, не очевидные в .NET, решения. В этой заметке мы обсудим недостатки .NET API, обеспечивающего работу с датами и временем. Моё отношение к этой теме выглядит несколько предвзятым, но я надеюсь, что эта заметка не выглядит неуважительно по отношению к команде, работающей над BCL (Base Class Library — прим. переводчика) — поскольку, кроме всего прочего, они работают в условиях, заставляющих их принимать во внимание взаимодействие с COM и т.п.

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

Написание качественной магистерской диссертации полноценно охватывающей все разделы проведенного исследования, основной работы, анализа и апробации результатов является сложной и комплексной задачей, ежедневно с различным успехом решаемой множеством студентов по всему миру. К сожалению, изучение существующей литературы [1, 2], посвященной тематике написания диссертационного исследования, указывает на отсутствие материалов описывающих практический опыт применения различных методов и инструментов, позволяющих не только оптимизировать работу над диссертацией, но и улучшить качество конечного результата.
В данной статье рассмотрим семь практических методов и инструментов, применение которых позволит обеспечить целостное структурирование и систематизацию задач, знаний и различных данных получаемых в ходе работы с диссертацией:

1. Формирование структуры задач.
2. Поиск литературы в каталогах.
3. Сбор, обработка и систематизация информации.
4. Формирование списка литературы.
5. Составление плана по вехам.
6. Определение предмета исследования.
7. «Summary» для научного руководителя.

Если вы .NET программист, то вы наверняка объявляли и использовали события в своем коде. Несмотря на это, не все знают, как события работают внутри и какие особенности связаны с их применением. В этой статье я попытался описать работу событий как можно более подробно, включая некоторые частные случаи, с которыми редко приходится иметь дело, но про которые важно и\или интересно знать.

Однажды мне захотелось управлять одним из домашних компьютеров удаленно, но при этом взаимодействовать с текущим пользователем, но компьютер был довольно слабый и при запуске например TeamViewer’а нагрузка процессора поднималась до 98% и компьютер начинал заметно тормозить. Попробовал стандартный RDP, но тогда «выбивался» текущий пользователь и для входа локально приходилось набивать пароль. Но чуть позже мне случайно попалась команда shadow.

Любому разработчику известен архитектурный шаблон слоев. При всей его незамысловатости он позволяет эффективно прятать реализацию и абстрагировать компоненты разного уровня. Слои нижнего уровня могут изменяться без особого риска испортить работу приложения, облегчен рефакторинг. Единственное очевидное условие, которое вы должны соблюдать – это придерживаться принятой архитектуры. Но иногда бывает, что программист нет-нет да и соблазняется вызвать пару методов «через голову». Например из слоя интерфейса обратиться прямиком в слой базы данных. Не будем здесь искать злого умысла, может этот случай был связан со спешкой при выпуске срочного исправления для заказчика. Но постепенно количество таких небольших «грешков» может свести на нет принятую когда то стройную архитектуру и вы опять окажетесь со «спагетти кодом». Вылавливать такие случаи несоответствия кода архитектуре слоев на большой системе может быть очень затруднительно. К счастью в Visual Studio 2010 (редакций Premium и Ultimate) есть инструменты, которые могут значительно облегчить эту задачу.

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

Представьте себе модель данных, которая имеет сотни сущностей. Работа с диаграммой модели хотя бы на 200 сущностей может быть сильно затруднена, работа может быть медленной и такая диаграмма не очень управляема.



Но теперь, с появлением Entity Framework 5.0 и Visual Studio 2012, вы можете иметь множество раздельных диаграмм одной и той же модели данных. И это даже круче чем новая возможность раскрашивать различные сущности в разные цвета.