Наверняка, многие из вас слышали или знают по собственному опыту, что системы контроля версий плохо дружат с бинарными файлами, большими файлами и в особенности — с большими бинарными файлами. Здесь и далее речь идет о современных популярных распределенных системах контроля версий вроде Mercurial и GIT.

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

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

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

Решение написано на C#, использует API Amazon Web Services и показан пример настройки для Mercurial репозитория. Код открыт, ссылка будет в конце статьи. Все написано более или менее модульно, так что добавление поддержки чего-то кроме Amazon S3 не должно составить труда. Могу предположить, что для GIT настроить будет так же легко.

 

Alexandre Mutel — создатель самой быстрой и самой полной .NET обертки для DirectX, единственной, поддерживающей Windows 8 Metro, работает R&D разработчиком игрового движка в SiliconStudio, участник французской демо-группы FRequency.

В последнее время мы слышим много шума о возвращении идеи «Going Native» после эры управляемых языков, таких как Java и .NET. В прошлом году, когда WinRT был только представлен, начали появляться недалекие комментарии, которые утверждали, что что .NET умер, а С++ возвращается во всей своей красе — истинный и единственно верный способ для разработки приложений, в то время, как JIT начинает все чаще появляться в мире скриптовых языков (JavaScript активнее всех использует преимущества JIT). Любой код так или иначе станет нативным перед выполнением — разница лишь в длине пути, по которому он пройдет, чтобы стать нативным, и насколько оптимизированным он будет. Значение слова «native» немного изменилось и стало неразрывно связано со словом «производительность». Даже будучи сильным пропагандистом управляемого языка [C#], его производительность на самом деле ниже хорошо написанного С++ приложения. Получается, мы должны просто принять этот факт и вернуться к C++, когда такие штуки как WinRT будут для нас основой межязыкового взаимодействия? По правде говоря, я бы хотел, чтобы .NET умер, и этот пост о том, почему и зачем.

 

О Bitcoin я узнал относительно недавно, но он меня сразу подкупил своей идеей p2p. Чем глубже я зарывался в их Wiki, тем больше проникался этой идеей. Ее реализация красива и элегантна с технической точки зрения.

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

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

С SharpDevelop я знаком, наверное, уже около года. На моем мягко говоря не топовом ноутбуке он чувствует себя превосходно и при этом умудряется решать большинство поставленных перед ним задач. Но как и любое другое средство разработки, не всесилен. Время от времени приходится обращаться к Visual Studio и другим инструментам. Иногда выручают самописные Project Templates и File Templates. Иногда — подключение консольных утилит через меню Tools. Но хотелось бы чего-то большего.

SharpDevelop — это, как известно, Open Source. Так что ничего не мешает взять его код и переписать, как вздумается. Но оставим это на крайний случай. У SharpDevelop есть замечательная возможность писать для него плагины или AddIns, как называют их авторы. Поэтому сегодня остановимся на плагинах и разберем, как они работают и как их писать. Для примера напишем простой плагин для поддержки Microsoft Moles Isolation Framework.

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

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

В первой части мы начали моделирование игры в шашки с помощью Alan.Platform. Мы создали библиотеку элементов, к которой добавили один элемент, оператор, управляющий расположением шашек. Также с помощью конструктора мы создали две шашки, расположенные по углам платформы. Все это можно было лицезреть в консоли, в виде текста, который был любезно составлен ObjectDumper'ом.

Как бы ни был хорош ObjectDumper — нашему мозгу трудно разглядеть доску для игры в шашки среди пар ключ-значение. Поэтому нужно создать графическое представление для модели. Этим мы в ближайшее время и займемся.

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

Глядя на эти требования, у меня возникают следующие мысли:

• модульность, подгружаемые библиотеки с расширениями;
• конфигурация через XML;
• представление модели в виде дерева объектов;