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

О том, что такое двойная буферизация много написано здесь и здесь.

Здесь можно почитать, как реализуется ДБ на Java.

Я расскажу, как реализуется двойная буферизация на C#. Многое из того, что здесь написал можно прочитать в MSDN, но без деталей реализации.

Ручное управление двойной буферизацией (далее ДБ)

Для ручного управления двойной буферизацией, .NET Framework предоставляет следующие 3 класса:

• BufferedGraphics – обеспечивает буфер для временного хранения графики и средства вывода её на полотно контрола.
• BufferedGraphicsContext — обеспечивает создание нового объекта BufferedGraphics на основе объекта Graphics;
• BufferedGraphicsManager – предоставляет дефолтный BufferedGraphicsContext.

Одним из наиболее заметных дополнений в C# 4 является dynamic. Об этом рассказано много и не раз. Но всегда выпускается из виду DLR (Dynamic Language Runtime). В данной статье мы рассмотрим внутреннее устройство DLR, работу самого компилятора, а также дадим определение понятиям статически-, динамически- типизированный язык со слабой и сильной типизациями. И, конечно же, не останется без внимания техника PIC (Polymorphic Inline Cache), используемая, например, в Google V8 engine.

При разработке бизнес-приложений постоянно стоит проблема хранения данных в репозитории совместно с проектом. Особенно эта тема актуальна для корпоративных ERP, CRM, многабукав и так далее систем.
Для чего это нужно:

• Для целей тестирования
• Для совместной разработки
• Для каких-то программных алгоритмов, оперирующих этими данными

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

Наступил долгожданный конец мая, который принёс нам не только жаркую погоду, но и возможность принять участие в DevCon'12 – ежегодной конференции от Microsoft, традиционно проходящей в загородном формате!

По такой же доброй традиции мы являемся одним из основных партнёров Microsoft в организации этой конференции и очень рады, что наши совместные усилия по поддержке российских разработчиков ПО не проходят даром!

Инициализаторы объектов (Object Initializers) – это полезная возможность языка C#, которая позволяет инициализировать необходимые свойства объекта прямо во время его создания. Поскольку синтаксически эта «фича» очень близка к инициализации объекта с передачей параметров через конструктор, многие разработчики начинают забивать на принципы ООП (в частности на понятие инварианта) и использовать ее, где только можно.

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

// position передается извне или настраиватся каким-то образом
long position = -1;
using (var file = new FileStream("d:\\1.txt", FileMode.Append)
                        {
                            // Мы точно знаем, что нужные данные расположены
                            // с некоторым сдвигом!
                            Position = position
                        })
{
    // Делаем чего-то с файлом
}

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

В честь окончания весны и для поддержания Украинского .NET комьюнити Сиклум вновь приглашает всех киевлян и гостей столицы на мероприятие целиком и полностью посвященное разработке на .NET – уже традиционный Ciklum .NET Saturday!

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

1. Виталий Домников – «F# — To Iterate is Human, to Recourse Divine»
2. Евгений Жарков – «Windows 8 Metro App: JavaScript Dark Side»
3. Александр Иванитский – «Introduction to XAML — a markup language for WPF, Silverlight and Metro applications»
4. Петр Афанасьев – «A journey to perfect API: ASP.NET Web API inside!»

Винни Пух: Ой, что это случилось с твоим хвостом?
Иа: А что с ним могло случится?
Винни Пух: Его нет.
Иа: Ты не ошибся?
Винни Пух: Хвост или есть или нет совсем! Тут нельзя ошибиться.
Иа: А что же тогда там есть?
Винни Пух: Ничего!

У нас в проекте, в одном из серверных компонентов, после очередного рефакторинга начала течь память. Казалось бы .NET, F#, менеджед код, сборка мусора, все дела, но память, куда-то утекала. Ценой бессонных ночей и попорченных нервов, источник утечки был найден. Оказалось что проблема вызвана куском кода, который был, чуть ли не один к одному скопирован из учебника по F#.

Все дело было в хвостовой рекурсии, вернее, как оказалось в ее отсутствии в неожиданных местах.

Скоро выходит Team Foundation Server 11. Это новый крупный выпуск, который включает в себя много нового как для разработчиков, так и для менеджеров проектов, тестировщиков и аналитиков.
В Team Foundation Server 11, вводится новая версия, которая называется Team Foundation Server Express.

В этой публикации будет рассказано именно о бесплатной редакции Express. Публикация предназначена для начинающих разработчиков и тех, кто еще не работал с Team Foundation Server.