Google Test — это фреймворк от Google для юнит-тестирования кода на С++. Общей архитектурой он слегка напоминает общепринятые boost::test и CppUnit, хотя слегка отличается в деталях (как по мне — в лучшую сторону). Большая обзорная статья этого фреймворка уже как-то пробегала на Хабре, но нынче она в каком-то побитом состоянии (код не отображается), да и кажется мне слишком сложной для начала работы. Поэтому я коротко опишу «Hello world» на Google Test, указав на несколько потенциальных проблем, с которыми вы можете столкнуться, используя Google Test при разработке под Visual Studio.

Возможно, вы уже знакомы с обобщёнными константными выражениями. Если нет — можете почитать о них, например, вот здесь). В этой статье я хочу поделиться своим опытом в использовании объединений (unions) в константных выражениях.

Объединения не очень популярны в ООП из-за той бреши в безопасности типов, которую они открывают, но иногда они предоставляют некоторые незаменимые возможности, которые лично я оценил при работе с Fernando Cacciola над черновиком std::optional.

Какой хороший программист наш Вася! Всегда опрятно одет, вежлив и предупредителен, хороший семьянин и душа компании. Что? Как он, собственно говоря, программирует? Хм… Постойте… А мы и не знаем. Никто никогда толком результатов его работы и не видел-то. Получается, Вася — не очень хороший программист? Ну ладно.

Вот Петя — точно хороший спец. Его код реально существует, компилируется, что-то делает. Показатель? Показатель. Правда, работает Петя не над тем, что по проекту надо, а над тем, что ему взбредет в голову. Иногда оно совпадает с общими целями, но чаще — нет. Выходит, и Петя наш — не идеал? Выходит так.

Мир разработчиков программного обеспечения разделен на два лагеря. Знатоки языков поют дифирамбы мощи высокоуровневого программирования — функциям высшего порядка, метапрограммированию, аспектно-ориентированному программированию, рефлексии и т.д. Знатоки инструментов имеют хорошие навыки использования утилит для сборки и отладки, документирования и автодополнения, рефакторинга и тестирования. Знатоки языков склоняются к использованию для разработки текстовых редакторов типа emacs, vim или подобных — они хорошо подходят для почти любых языков, включая новые. Знатоки инструментов выбирают IDE, такие как Visual Studio, Eclipse, или IntelliJ, включающих в себя целые наборы специализированных средств разработки.



Новые языки программирования, такие, к примеру, как Laszlo или Groovy, и новые расширения языков, такие как AOP, обычно доступны только для использования средствами универсального текстового редактора, пока не получат полноценную поддержку в какой-нибудь IDE. Спустя какое-то время, если язык действительно «выстрелил», эта поддержка, несомненно, появится. Это происходит не потому, что сделать нужный инструментарий слишком сложно. Это происходит потому, что вложение усилий в разработку языка и вложение усилий в разработку средств для него находятся в несколько ортогональных плоскостях и порой даже вытесняют друг друга. И вот почему.

Иногда бывает любопытно подсмотреть, что пересылают туда-сюда разные Android-приложения по HTTP и HTTPS протоколам. Иногда даже при разработке собственного ПО удобно видеть весь трафик в реальном времени. Для реализации этих задач давно придумано много хороших программ, таких, к примеру, как Charles или Fiddler2. На самом деле их намного больше, вот только две вышеуказанные дают возможность нормально просматривать не только HTTP, но и HTTPS.

Трудности начинаются тогда, когда речь заходит о перехвате трафика между Андроид-устройством и внешним сервером. В случае незашифрованного (HTTP-протокол) трафика всё весьма тривиально (вот и инструкция есть) — разрешаем Fiddler2 внешние соединения, в Андроиде устанавливаем прокси сервером адрес нашей машины с Fiddler2 — и вуаля, всё работает. А вот на настройку перехвата HTTPS-трафика у меня ушло чуть больше времени.

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

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

Временами я задумываюсь — а вот представим, что собрать такую капсулу нужно прямо сегодня. И вот нам с вами поручили отобрать её часть — какое-то количество программного обеспечения (мы ведь тут на Хабре разбираемся, да?), которое бы по вышеуказанным критериям можно было поместить в такую капсулу. Что выбрать?

Одна из вещей, которая делает классические русские романы столь тяжелыми для чтения (для иностранцев) это то, что главные герои имеют кучу имён. К примеру, в романе "Братья Карамазовы" один из персонажей — Алексей Фёдорович Карамазов (Alexei Fyodorovich Karamazov), которого по ходу текста называют также Алёша, Алёшка, Алёшенька, Алёшечка, Алексейчик, Лёша и Лёшенька (Alyosha, Alyoshka, Alyoshenka, Alyoshechka, Alexeichik, Lyosha и Lyoshenka)

«Программирование в стиле русских романов» — это антипаттерн, возникающий в ситуации, когда одна вещь имеет много имён. Для какой-нибудь программы у вас может быть путь в системе контроля версий, путь на диске, имя проекта, имя исполняемого файла и т.д. Все они могут иметь одинаковые (однокоренные) имена или наоборот — называться каждая по-своему. Например, синонимами. Или вообще разными словами. Так уж вышло по историческим причинам, что бинарник foo.exe получается при компиляции проекта bar, лежащего в папке baz и т.д.

Пошаговая инструкция с примерами

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

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

Поэтому, ответы на эти вопросы здесь найдут те, кто выполняют такую задачу впервые.

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

Некоторые из моих студентов — гики. У них уже есть достаточно много опыта в программировании, иногда даже на столь экзотических языках, как Clojure. Я надеюсь, что их время, потраченное на мои занятия, будет столь же полезно, как и для менее опытных учеников. Даже продвинутые студенты обычно много ещё не знают о построении сложных программных систем.

После интересного разговора с одним из таких студентов я подумал о роли доверия между учителем и учеником. Студент вынужден верить, что его профессор знает достаточно, чтобы его учить. Большинство студентов действительно в это верит, основываясь на авторитете университета или учёной степени лектора. Это делает работу преподавателя слегка полегче, да :). Если учитель будет вынужден перед каждым уроком, для каждого отдельного ученика доказывать свою квалификацию и право преподавать предмет — дела пойдут намного медленнее.

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

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

Уже достаточно давно украинская налоговая (а также другие органы) стали принимать документы в электронном виде. Для сдачи таких документов они должны быть подписаны электронной цифровой подписью. Дело двигалось достаточно медленно – подписи стоили денег, учиться их применять всем было лень, хороших программ не было и т.д. За последний год-полтора, всё, как ни удивительно, резко изменилось:

• Появились нормальные законы и открытые стандарты – программу для формирования документов теперь может написать любой (и их действительно уже написано много)
• Налоговая стала выдавать подписи бесплатно
• Опять-таки бесплатно оказывается техподдержка
• Одна и та же подпись может использоваться во всех гос. органах
• Налоговая стала намекать, что скоро бумажные документы принимать не будет (это не правда, но людей подстёгивает)

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

Что этот пост делает на Хабре? Многие айтишники зарегистрированы как частные предприниматели и должны примерно 5 раз в год тратить по полдня на сдачу отчетов в налоговую. Теперь это время можно будет свести к 5-10 минутам. Кроме того, мы уделим некоторое внимание вопросам информационной безопасности всего этого механизма.

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

Замечали ли вы, как мало в нынешней культуре уделяется внимания профессии IT-шника? Казалось бы — всё вокруг пропитано интернетом, социальные сети объединили людей, мобильные технологии перевернули мир и т.д. Но где же творцы всего этого великолепия? Где книги о них? Где фильмы, комиксы? Где постеры с выдающимися разработчиками над кроватями подростков? Где фантики жвачек и брендированные игрушки? Где фан-клубы и подражатели? Нету этого всего. Из книг есть разве-что Ник, а из фильмов — Социальная сеть (да и они на самом деле не о программистах, а о магии и бизнесе, соответственно — это людям интереснее). Всё остальное — либо истории про хакеров в духе «мы взломаем Пентагон за 25 секунд», либо посты на гиковских ресурсах вроде Хабра, либо финансовые сводки о том, сколько кто-то там заработал денег на IPO. А всё почему? А потому что в массовом сознании людей работа программиста выглядит неинтересной и скучной. Вот такой, как на картинке справа

Стол, стул, компьютер. Изо дня в день. Скучно. При этом есть много профессий, люди которых 90% времени проводят так же. Ну, например, архитекторы небоскрёбов или инженеры космических кораблей. Но в результате работы архитектора получается настоящее здание, которым пользуются многие люди, в результате работы инженера получается какой-нибудь модный марсоход, которым все восхищаются. А результат работы программиста остаётся там же, где и происходил процесс его создания — в байтах на диске компьютера и в голове у автора. И потому он не так хорошо заметен остальным людям. А что им заметно? См. картинку выше.

Мне хотелось бы объяснить другим людям, не связанным с ИТ-технологиями, что видят они совсем не то, что происходит на самом деле. Вот заходите вы в комнату, где сидит человек пять «компьютерщиков». Все что-то там набирают, кнопают кнопки, усиленно пялятся в экраны. Но это только их тела. Самих их здесь нет. А где же они?

Об эмуляторе Android под названием Bluestacks на Хабре уже писали. Но писали или в общем, или мало, или сухо. Тем временем проект подрос и ныне вполне пригоден для использования при тестировании и отладке приложений под Android. Зачем это делать? А затем, что Bluestacks работает намного, нет, даже намного-намного быстрее стандартного эмулятора из Android SDK. Под катом я расскажу о нюансах использования Bluestacks, настройке отладки из-под Eclipse, приведу пару замеров скорости работы и расскажу о нескольких ложках дёгтя в бочке мёда.

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

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

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

На днях исполняется год нашему блогу на Хабре. И мы решили отметить это дело! Нет, ну не так, как вы подумали. Хотя так, конечно, тоже. Но сейчас не об этом.

Нам очень хочется подарить всем нашим читателям какие-то подарки, но подарок у нас только один (зато хороший), поэтому мы решили разыграть его в небольшом конкурсе для программистов. Условия конкурса и описание приза — под катом. Задания не отнимут много времени, шанс выиграть есть у всех.

Часто ли Вы сталкивались с таким явлением, как нерациональное распределение обязанностей? Сколько раз приходилось наблюдать за тем, как один человек «на все руки мастер» выполняет работу за пятерых? А так называемый «специалист, занимающийся не понятно чем» — знакомо? Такие варианты, а также им подобные нередко приходилось видеть ранее в отечественных реалиях. Этот же «совок» многим приходится наблюдать, и что хуже, чувствовать на своей личной шкуре и поныне во многих госструктурах.

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

Именно из-за «бугра» до нас дошла любопытная аббревиатура под названием RACI. При этом, зачастую перед ней можно наблюдать разного рода умности а-ля «матрица» или «модель». Что это и с чем его едят, попытаюсь объяснить читателю далее. Возможно, кому-то уже повезло работать в коллективах, где каждый знает свои обязанности и область ответственности – за таких людей можно только порадоваться. При этом лично я верю, что далеко не у всех всё идеально в сфере разделения полномочий. Для таких людей данная статья может оказаться полезной.