Случайно попалось упоминание о хостинге Scaleway.

Плюсы:

• 4 ядра
• 2 гигабайта оперативки
• 50 гигабайт SSD диск
• bare-metal! (то есть, нет никаких, даже чисто теоретических накладных расходов на виртуализацию)
• за все это всего 3 евро в месяц! Очень дешево!

Но есть особенность: это ARM процессор. Да-да! Это 4-ядерный ARM процессор.

В очередной раз упражняясь в практике TDD на Java я создал небольшой учебный проект, в котором показал, что если тесты проходят, то это еще не значит, что код выполняется правильно. На самом деле, разработка модульных тестов, в которых учитываются различные варианты входных данных это кропотливая работа. Для решения возникшей проблемы нашел для себя библиотеку junit-quickcheck, опытом использования которой спешу поделиться.

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

Только что получил анонс, что на AWS стали доступны инстансы нового поколения Amazon EC2 High I/O. Данные типы инстансов базируются на новом поколении процессоров Intel Ivy Bridge. Каждый виртуальный CPU (vCPU) соответствует одному аппаратную потоку исполнения (hyperthread) процессора Intel Xeon E5-2670 v2 (Ivy Bridge).

Вот табличка:

При офомлении исходного текста все мы пользуемся каким либо Code Convention. Хорошо, когда внутри компании есть документ, который описывает эти соглашения. Если нет, то приходится пользоваться каким-то общеизвестным, который нам кажется стандартным. Хотя, конечно, понятие его стандартности весьма относительно. Лучше все таки иметь такой документ внутри компании, что бы не было разнологласий в команде.

Один из вопросов, который возникает при формировании такого документа — правая граница в исходном тексте. Раньше было принято использовать правую границу 80 (а то и 76) символов. Но сейчас мониторы широкие. Может быть можно и не ограничивать? Или все таки надо ограничивать? Вот, например, и совсем недавно, в этой статье данный вопрос вызвал довольно большую полемику. Под катом мое видение этого вопроса + опрос.

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

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

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

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

В данной статье представлен опыт использования системы версионного контроля subversion и системы отслеживания изменений Trac в рамках учебного процесса по дисциплине «Лингвистическое и программное обеспечение САПР» на каф. КСУП ТУСУР. Показаны преимущества, которые получили студенты и я, как преподаватель, от использования этих систем в учебном процессе.