Привет, Хабр! Эта публикация — попытка развеять некоторые популярные мифы и легенды о MySQL. Я не ошибся с хабом, так как поводом для написания послужила публикация varanio Возможности PostgreSQL, которых нет в MySQL, и наоборот отсюда же. Сама публикация в части критики MySQL хоть и неидеальна, но вполне корректна, а вот комментарии к ней наводят на грустные размышления.

Вообще говоря, я собирался написать публикацию о возможностях MySQL, которые не реализованы или реализованы в PostgreSQL хуже. Но для того, чтобы не мешать много тем в одну публикацию, и учитывая довольно нелёгкую работу по сравнению того, что я знаю очень хорошо (MySQL) с тем, что я знаю очень плохо (PostgreSQL), такую публикацию я решил отложить на потом и для начала ответить сразу на многие комментарии из публикации varanio.

Приветствую!

Думаю что каждому из программистов попадалось приложение которое по тем или иным причинам блокировало UI. Причин у таких блокировок может быть множество, такие как: синхронные запросы к сервисам, выполнение долгих операций в UI треде и прочее.
В самом лучшем случае участки кода приводящие к блокировкам UI должны быть переписаны / исправлены, но это не всегда возможно по разным причинам и соответственно хочется получить некую серебряную пулю, которая сможет решить проблему с минимальной стоимостью.
О одной такой пуле и пойдет речь.

Подробности под катом.

Пришло время выложить вторую часть заметок по .NET.

Здравствуйте, дорогие читатели!

Не так давно мы занялись проработкой книги "Writing High-Performance .NET code", которая до сих пор не переведена на русский язык, хотя ей и скоро год.



Нас, конечно, не удивило, что такую книгу уже растаскивают на цитаты, однако выяснилось, что уважаемый автор Бен Уотсон даже выложил на сайте «Codeproject» целую статью, написанную по мотивам одной из глав. К сожалению, объем этого материала слишком велик для хабропубликации, однако мы решили все-таки перевести первую часть статьи, чтобы вы могли оценить материал книги. Приглашаем к прочтению и к участию в опросе. Кроме того, если все-таки целесообразно перевести и вторую часть — пишите в комментариях, постараемся учесть ваши пожелания.

Как известно, недавно была опубликована книга по паттернам проектирования за авторством Сергея Теплякова.

Дабы поддержать мною уважаемого нашего разработчика (сам Сергей, несмотря на переезд заграницу, всё ещё считает себя нашим — за пруфом идите к нему в блог), не пожалел денег и сразу же купил электронную версию. До этого я читал банду четырёх и Design Patterns Head First, поэтому, в принципе, есть с чем сравнить.
Книга занимает чуть более 300 страниц, что вполне можно осилить за неделю неторопливого чтения. Книга разбита на 4 части:

1. Паттерны поведения
2. Порождающие паттерны
3. Структурные паттерны
4. Принципы проектирования

Это краткое введение в криптографию под .NET для чайников, как и следует из заголовка. Здесь будут простые вещи и никаких углубленных знаний.

Использование исключений для контроля хода выполнения программы (flow control) — давняя тема. Я хотел бы суммировать этот топик и привести примеры правильного и неправильного использования исключений.

Код Serbench находится на GitHub.

Начало проекта

Этот бенчмарк проект начался со статьи “Serializers in .NET v.2” на GeeksWithBlogs.net. В статье было рассмотрено довольно много имеющихся под .NET сериализаторов. Но, чтобы превратить эту статью и соответствующий код в настоящий бенчмарк, надо было сделать несколько улучшений.

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

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

Статья «Навыки .NET-разработчика» была первым моим аналитическим исследованием востребованности навыков на рынке труда, в котором я показал потребности близкого к нам российского рынка в специалистах моей профессии. В этом материале я представляю сравнение с зарубежным рынком. Говорят, что наш IT-рынок в целом и используемые нами технологии в частности отстают от Запада на несколько лет. Давайте вместе посмотрим «за рубеж» и попробуем понять, так ли это и есть ли нам чему поучиться.

Тестовое приложение для тестирования сериализаторов было сделано на библиотеке NFX. Это Unistack библиотека. Честно говоря, я затрудняюсь назвать другой пример Unistack библиотеки. Может быть что-то похожее есть в виде ServiceStack. Хотя ServiceStack, в отличии от NFX, размазан по нескольким dll. Но самое главное, ServiceStack не является Uni, так как его части сделаны немножко по-разному, и он не покрывает такого глобального пространства, как NFX. Но целью данной статьи не является обсуждение концепции Unistack, а одна из особенностей использования NFX.

Как использование NFX повлияло на наше тестовое приложение? Давайте посмотрим.

Предыстория

Мой сын, как, наверное, все дети программистов, получил свою первую клавиатуру ещё когда не умел сидеть. Сейчас ему чуть меньше года, но он уже понимает разницу между «игрушечной» и «настоящей» (папиной) клавиатурой — если колотить по кнопкам настоящей, то на экране меняется картинка, а компьютер иногда издаёт какие-то звуки.



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

Чтобы процесс освоения компьютера стал для детёныша более увлекательным, я решил написать ему простенькую игру. Будучи программистом со стажем, весь процесс решено было построить «правильно».

Требования

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

Функциональные:

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

Не функциональные:

• Мне должно быть не стыдно за написанный код.
• Код должен быть ценен сам по себе.
• Архитектура и все решения должны быть «правильными» — как в заказном проекте.

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

В качестве языка программирования и среды разработки были выбраны C# и Visual Studio, так как они обеспечивали исполнителю наибольшую скорость работы.

Перевод статьи «NHibernate Basics» с сайта codeproject.com.

Ведение

Nhibernate это решение для Объектно Реалицонного мапинга для платформы .NET. Этот фреймворк позволяет делать мапинг Объектно ориентированных моделей к традиционным БД. Его основное преимущество маппирование классов .Net к таблицам БД и от типов данных CLR в типы SQL.

Как указано в заголовке нашей статьи, мы посмотрим: Как загружать бизнес объекты из БД и сохранять измененные объекты обратно в БД.

Есть у меня в проекте некий интерфейс IT и factory метод типа

interface IT {}
public IT CreateT(IA a, IB b, IC c, Type concreteType)
{
    // куча говнокода, который создает объект типа concreteType, определяемого в месте вызова в рантайме.
}

Классы, реализующие IT, имеют конструкторы с разными сигнатурами, принимающими какую-то комбинацию объектов типов IA, IB или IC, поэтому с ростом количества реализаций IT, код их создания начинал пахнуть все сильнее, и, наконец, было принято решение его выкинуть и заменить простым кодом с Unity, примерно такого содержания:

private static IT CreateITInternal(IA a, Type targetType)
{
    using (UnityContainer cont = new UnityContainer())
    {
        cont.RegisterInstance<IA>(a, new ExternallyControlledLifetimeManager());
        cont.RegisterType(typeof(IT), targetType, new ExternallyControlledLifetimeManager());
        return cont.Resolve<IT>();
    }
}

(для простоты я оставлю только ссылки на IA, чтобы не загромождать код. Unity нам тут нужен только для облегчения инстанциирования объектов и мы не хотим давать ему контролировать время жизни никаких объектов, поэтому использован ExternallyControlledLifetimeManager)
Код написан, тесты написаны, все зелено, все работает, выкатывам в продакшен. И тут началось…

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

Пролог

В начале 2015 года я решил написать свою первую игру. В качестве движка я, не долго думая, выбрал Unity3D, так как у меня был опыт в C# и JavaScript, и знакомые, которые могли помочь. Я вспомнил одну мини-игру, в которую я играл в детстве, и решил сделать нечто похожее. Установил себе Unity и поставил себе цель сделать рабочий прототип за пару недель, параллельно изучая движок.

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

Подробно о преобразовании асинхронного кода, осуществляемого компилятором

Механизм async реализован в компиляторе C# при поддержке со стороны библиотек базовых классов .NET. В саму исполняющую среду не пришлось вносить никаких изменений. Это означает, что ключевое слово await реализовано путем преобразования к виду, который мы могли бы написать и сами в предыдущих версиях C#. Для изучения генерируемого кода можно воспользоваться декомпилятором .NET Reflector или ILSpy. Это не только интересно, но и полезно для отладки, анализа производительности и других видов диагностики асинхронного кода.

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

Например, мы захотели создать незатейливую RPGMMO-шечку «убийцу WoW», и у нас уже почти все готово. Мы уже нафантазировали, какая в игре будет крутая механика боя и система умений. Дело осталось за малым – абстрактные мысли превратить в конкретные значения. Причем, каким-то образом, сочетание этих значений должно убедить игрока в том, что фраза «баланс – говно» — это не про нас.

Введение в проблему

Здравствуйте, дорогие читатели!

Мысли о создании серии простых уроков «концептуальные идеи для новичков игродева» появились у меня спонтанно, где-то в 2:00 по Московскому времени во время создания своего нынешнего проекта. Ну нет, это так мне кажется, что спонтанно, но, наверное, это мое подсознание так среагировало. Среагировало потому, что все больше юных (коим я и сам являюсь) и очень юных программистов решают заняться созданием игр. Как мне кажется, общая тенденция молодежи-программистов (и людей, интересующихся сферой программирования) плавно перешла от создания сайтов и модных блогов к созданию развлекательных продуктов. Я начинаю замечать это и среди своих знакомых, которые одно время говорили, что, мол игры — это не серьезное программирование, но теперь уже проявляют настоящий интерес к этой среде.

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

Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.

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

Они не просто не используют вашу программу, нет, они ее удаляют! Но почему? Вы запускаете приложение и начинаете его тестировать, изучать снова и снова, выискивая возможную проблему. Но все работает отлично, явных причин нет. В чем же дело? Давайте попробуем разобраться.