Думаю, что все знают, что такое модульные тесты, все знают или, по крайней мере, слышали, что такое непрерывная интеграция, и многие программируют на C++. Но я столкнулся с тем, что в интернете не так много информации о том, как же это все объединить и заставить работать вместе. Эта статья является попыткой дать новичками пошаговую инструкцию, которая позволит сделать первый шаг в создании модульных тестов для C++ проектов и организовать покоммитный прогон модульных тестов при помощи CI сервера.
Update: План:

1. Напишем HelloWorld
2. Настроим сборку HelloWorld на Jenkins
3. Напишем модульный тест для HelloWorld
4. Настроим прогон модульных тестов на Jenkins

Внимание: много букв и скриншотов, половина из которых избыточны. Особенно для тех кто уже в теме.

От переводчика

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

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


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

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:

«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

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

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

В самом Model View Controller шаблоне нет ничего плохого. Он решает ту проблему, для которой его придумали — это разделение логики обработки запроса пользователя и логики представления информации.

Это заняло много времени, друзья. Прошло около трех месяцев с последнего обновления, но не волнуйтесь, сегодня ожиданию наступил конец.
После многочисленных задержек, в том числе и на борьбу с гриппом, мы рады представить вам Bootstrap 2.3.

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

В 2011-2012 телекоммуникационный мир шагнул в эру 100G. В смысле, массово шагнул, повсеместно. Если уважаемым хабрачитателям будет интересно, каким образом это произошло – немного знаний под катом.

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

• Как вывести список всех сетевых папок на компьютере (компьютерах)
• Создаем отчеты о размерах сетевых папок
• Определяем владельцев файлов
• Находим дату создания файлов выявляем «старые» файлы и файлы, созданные за определенный промежуток времени)

Итак, под катом вы найдете перевод статьи File Server Management with Windows PowerShell.

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

Наблюдая со стороны это тестирование, я накопил некоторый объём информации, который, как я думаю, будет небезынтересен.

«Покой — это ложь. Есть только страсть.
Через страсть я познаю силу.
Через силу я познаю могущество.
Через могущество я познаю победу.
Через победу мои оковы рвутся.
И Великая Сила освободит меня.»
— Кодекс ситов

Я хочу поговорить о темной стороне кода и о том, к чему это приводит. Что я понимаю под темной стороной кода? С моей точки зрения — это такой код, который был написан программистами, которые поддались желанию написать кое-как, исходя из своих собственных целей, а не целей продукта. Они оставили покой (размеренное написание кода согласно практикам) в угоду страсти (код ради кода). А если есть темная сторона, то есть и ее представители — Темные властелины, Дарты. Вот о них мы сегодня и поговорим.

Данная статья является продолжением первой части.
Продолжаем мучить Boost.Python. В этот раз настала очередь класса, который нельзя ни создать, ни скопировать.
Обернём почти обычную сишную структуру с необычным конструктором.
И поработаем с возвращением ссылки на поле объекта C++, так чтобы сборщик мусора Python его не удалил ненароком. Ну и наоборот, сделаем альтернативный вариант, чтобы Python прибрал мусор после удаления того, что ему отдали на хранение.
Поехали…

Intro

Внедрение своего кода( динамически ) в чужие процессы — штука достаточно интересная. Это может служить как во благо, так и во зло. Хотя, понятие «зло», местами, весьма абстрактно в информационном мире, я не могу провести точную границу между тем, что «плохо», а что «хорошо», тем более, если это касается внедрения кода…

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

Писать DLL Injector мы будем на C++ в среде Microsoft Visual Studio 2010. Для создания динамически подключаемой библиотеки можно использовать любой инструмент, который вам по душе. Я же для создания библиотеки выбрал CodeGear RAD Studio 2009, язык Delphi( Object Pascal ).

Как же работает DLL Injection ?

Схема работы данного метода проста:

1) поиск и получение дескриптора нужного процесса
2) выделение памяти в процессе и последующая запись пути в DLL`ке по адресу, где произошло выделение памяти
3) создание нового потока в виртуальном пространстве процесса, дескриптор которого был получен.

Boost.Python во всех отношениях замечательная библиотека, выполняющая своё предназначение на 5+, хотите ли вы сделать модуль на С++ для Python либо хотите построить скриптовую обвязку на Python для нативного приложения написанного на С++.
Самое сложное в Boost.Python — это обилие тонкостей, поскольку и C++ и Python — два языка изобилующие возможностями, и потому на стыке их приходится учитывать все нюансы: передать объект по ссылке или по значению, отдать в Python копию объекта или существующий класс, преобразовать во внутренний тип Python или в обёртку написанного на C++, как передать конструктор объекта, перегрузить операторы, навесить несуществующие в C++, но нужные в Python методы.
Не обещаю, что в своих примерах опишу все тонкости взаимодействия этих фундаментальных языков, но постараюсь сразу охватить как можно больше частоиспользуемых примеров, чтобы вы не лазили за каждой мелочью в документацию, а увидели все необходимые основы здесь, или хотя бы получили о них базовое представление.

Предыдущий пост с описанием фреймворка maxmertkit получил большой отклик. Фреймворк особенно понравился, почему-то, японцам, но наилучшую конструктивную критику и помощь я получил от хабрасообщества. Теперь к делу.
Нынешние фреймворки, включая мой, имеют модульную структуру. Но все эти модули в некоторой степени являются зависимыми друг от друга. Это плохо. Именно эту проблему я и хочу решить.

Сегодня произошел большой шаг вперед в развитии Team Foundation Services — облачного сервиса Microsoft для разработчиков. Последние несколько месяцев команда TFS вела работу над новыми возможностями которые делают эти сервисы еще проще, удобнее и эффективнее. Одним из самых громких нововведений является интеграция популярной системы контроля версий Git с сервисами TFS. Работа на этом не прекращается и в обозримом будущем будет добавлено еще много интересных функций.

Данная статья написана под влиянием книги Дэвида Коупленда «Build Awesome Command-Line Application in Ruby» (купить, скачать и изучить дополнительные материалы). Большая её часть будет посвящена проектированию дизайна CLI-приложений вне зависимости от используемого языка. По ходу будут обсуждаться и вещи специфичные для ruby, но не страшно, если вы его не знаете, кода будет не слишком много. Можно считать эту статью довольно подробным обзором вышеупомянутой книги с вкраплениями собственного опыта. Книжку рекомендую!

Для начала я задам вопрос. Если посмотреть на сообщества IT-шников, можно заметить, что несмотря на обилие программ с красивым графическим интерфейсом, приложения командной строки остаются весьма популярны. Почему?
Ответов несколько. Во-первых, это красиво удобно — если вы можете описать задачу командой в командной строке, то её гораздо проще автоматизировать, чем если вам приходится анализировать передвижения мыши и клики на разные пункты меню. Во-вторых, это даёт возможность комбинировать программы невероятным числом способов, чего сложно добиться с помощью графических интерфейсов.
В значительной степени философия Unix базируется на том принципе, что множество маленьких утилит, каждая из которых умеет делать свою конкретную задачу — это лучше, чем одна многофункциональная программа-универсал. И это одна из причин успеха Unix-систем в мире IT-шников.
Наверное, каждый понимает, что обычного пользователя вряд ли удастся сманить от GUI к CLI, давайте сосредоточимся на нас, «компьютерщиках» и конкретизируем наши пожелания к CLI-приложениям.

Здравствуйте!

Это вторая часть статьи о работе c кластерным хранилищем в Proxmox. Сегодня поговорим о подключении хранилища к кластеру.

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

В нашем случае проблема организации общего хранилища сводится к двум аспектам:

1. У нас есть блочное устройство, отдаваемое по сети, к которому будут иметь доступ несколько хостов одновременно. Для того, чтобы эти хосты не подрались за место на устройстве, нам нужен CLVM — Clustered Logical Volume Manager. Это то же самое, что LVM, только Clustered. Благодаря CLVM каждый хост имеет актуальную информацию (и может ее безопасно изменять, без риска нарушить целостность) о состоянии LVM-томов на Shared Storage. Логические тома в CLVM живут точно так же, как в обычном LVM. В логических томах находятся либо KVM-образы, либо кластерная FS.
2. В случае с OpenVZ у нас есть логический том, на котором расположена файловая система. Одновременная работа нескольких машин с некластерной файловой системой ведет к неминуемым ошибкам в работе всего — это лебедь, рак и щука, только хуже. Файловая система обязательно должна знать о том, что она живет на общем ресурсе, и уметь работать в таком режиме.

В качестве кластерной файловой системы мы используем Global File System 2.

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

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

Для начала, несколько фактов, которые относятся ко всем работникам интеллектуального труда. Задача, прерванная по ходу выполнения, занимает в два раза больше времени и содержит вдвое больше ошибок, чем та же задача, которая выполнялась без прерывания (Czerwinski:04). Офисные сотрудники вынуждены отвлекаться при выполнении 57% задач (Mark:05). Опросы говорят о том, что сотруднику требуется в среднем 15 минут, чтобы вернуться в нормальный ритм после того, как его отвлекли (vanSolingen:98).