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

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

image: пузырьки

Цель: недорого собрать систему поддерживающую проброс PCI-устройств в виртуальную машину (c IOMMU). Создать полноценное рабочее место, поднять виртуальный маршрутизатор и еще полезные мелочи.

Рассмотрим простую задачу: есть некоторый достаточно большой неизменный набор чисел, к нему осуществляется множество запросов на наличие некоторого числа в этом наборе, необходимо максимально быстро эти запросы обрабатывать. Одно из классических решений заключается в формировании отсортированного массива и обработке запросов через бинарный поиск. Но можно ли добиться более высокой производительности, чем в классической реализации? В этой статье мне хотелось бы рассказать про Cache-Conscious Binary Search. В данном алгоритме предлагается переупорядочить элементы массива таким образом, чтобы использование кэша процессора происходило максимально эффективно.

Добрый день, жители Хабра!
Сегодня мы будем писать фреймворк с названием Mechanic Framework для удобной разработки игр под андроид.

Что нам потребуется:

• Установленные Eclipse и Android SDK
• Приличное знание Java либо другого С-подобного языка. Лучший пример – C#
• Терпение

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

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

Захотелось мне посмотреть, как работает реализация .NET на Linux. Решено было развернуть Ubuntu Server на нашем гипервизоре, установить свежий пакет mono и через nginx запустить ASP.NET MVC4 сайт.

На официальном сайте mono готовый пакет для Ubuntu только 2-х летней давности. С этого момента начались поиски в сети путей осуществления задуманного. Результатом полученного опыта стал скрипт для автоматического развертывания на голой Ubuntu Server 12.04.3 или 13.04 всего необходимого для запуска сайтов ASP.NET MVC4:

• Соберем из исходников и установим mono 3.2.1
• Добавим monoserve скрипт в init.d для автоматического запуска сайтов и управления ими.
• Установим nginx 1.4.1
• Создадим и настроим простой сайт, чтобы проверить работоспособность всей связки.

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

Добрый день, хабр!
Наверное, у всех системных администраторов была проблема определения имени компьютера пользователя. То есть мы знаем имя сотрудника, но какой у него компьютер, без понятия. И, зачастую, попытка заставить пользователя определить имя компьютера вызывает мучение. Они вместо этого называют имя пользователя, mail, номер телефона, все что угодно, только не имя компьютера. А попытка объяснить пользователю где находится информация о системе вызывает баттхерт сотрудника и лютую ненависть. Можно, конечно, было бы написать какую-нибудь утилитку, позволяющая отображать имя компьютера на рабочем столе или где-нибудь еще на видном месте, но для этого надо каждый раз объяснять где находится эта информация. Немного упрощает задачу, но не решает ее полностью. Тем более что я склоняюсь к тому, что пользователю и во все положено не знать имя компьютера, на котором он сидит. В результате было решено сделать определение имени компьютера современным, удобным, правильным и, главное, автоматическим.


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

Аннотация

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

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

Сразу оговорюсь, что примеры приводятся применительно к языку C# и платформе .NET. Соответственно, в других языках/платформах подходы и реализации могут отличаться.

Итак…

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

Всем привет.

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

Речь пойдет, конечно, о коде.

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

Да и давайте признаемся — все мы любим писать “фреймворки”, которыми пользуемся потом сами и которыми пользуются другие. Это добавляет немного куража нашей повседневной деятельности.

И тут автор ловит себя на том, что поступает неправильно, начиная описывать ситуации — все и так понимают, о чем речь. А описать нужно технологии и процесс. Поэтому давайте просто остановимся на абстрактной мысли, что внезапно нашлось много кода, который может быть полезен коллегам и его хорошо бы сделать легкодоступным. Также примем во внимание вторую, куда менее приятную, мысль, что в “зрелых” проектах можно найти большое количество copy-paste кода, значительно понижающего сопровождаемость. Да и работу над такими проектами приятной назвать трудно. И с этим надо что-то делать.

И мы решили с этим что-то делать.

Предыстория

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