Просматривая материалы конференции GoingNative 2012 (которую всем программистам на С++ очень советую посмотреть), я обратил внимание на один пример кода:

#include <iostream>
struct  S { int  n; };
struct  X { X(int) {} };
void f(void*) {
    std::cerr << "Pointer!\n";
}
void f(X) {
    std::cerr << "X! \n";
}
int  main() {
    f(S().n);
}

Сможете ли вы, не подглядывая в ответ, сказать, что напечатает эта программа и самое главное, почему?

Под катом — предположение разработчика Clang из Google о том, почему этот код работает так, как он работает. Еще раз, кто не уловил: разработчик компилятора С++ из Google не знает этого точно, у него всего-лишь есть предположение.

	SomeFunction()
	{
	    ...
	    if (false)
	    {
	        ...
	    }
	    ...
	}
	

Зачем может быть нужен блок if (false)?

Предположим, что:

1. Это не ошибка и не забывчивость.
2. if и false — это именно оператор условия и логическая ложь, а не какие-то хитрости с макросами\строками и т.д.

Пару вариантов ответа под катом. Желающие высказать свои идеи приглашаются мимо отгадки сразу в комментарии.

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

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

Выходить из дому Антону совсем не хотелось. Но сегодня был особенный день. Сегодня его ждала Работа. Он спокойно собрался и вышел прямо в пелену городского тумана. Антон шел и думал о чём-то своём. Давно прошли те времена, когда перед выполнением заказа он переживал или терзался муками совести. В конце концов, его труд не был преступлением, хотя и был причиной ненависти многих людей. Это просто работа и кто-то должен её делать. У него получалось лучше многих.

Вступление

К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
В статье я описываю свой личный опыт оценки проектов, и,
конечно же, у вас могли быть другие ситуации и свои методы и
рекомендации оценивания.
Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:

• выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
  
• и презентацию Сергея Бережного
  «My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.
  

Статья содержит такие разделы:

• Украинские реалии при выполнении проекта
• Проблемы и их решения
• Подготовка к оценке
• Перечень работ для оценивания
• Оценка работ по написанию кода
• Цифры и коэффициенты из практики
• Пример расчета

Технология Windows Installer (MSI) является стандартом де-факто в мире системных администраторов, занимающихся распространением и поддержкой программного обеспечения для десктопных и серверных версий Windows. Формат MSI поддерживается всеми крупнейшими системами управления конфигурациями (Microsoft SCCM, CA Unicenter и многими другими), а для некоторых систем распространения ПО — является единственным поддерживаемым форматом.
Мой опыт работы с этой технологией — как теоретический, так и практический — приобретен за время работы в компании «Инфопульс Украина» и связан с созданием MSI-пакетов и подготовкой готовых MSI-пакетов к автоматической установке в корпоративной среде.

Всем доброго времени суток.
19 ноября 2011 года в Харьковском Национальном Университете Радиоэлектроники (ХНУРЭ) прошла конференция Mobile Professional Days.
Посвящена она была, цитирую: «вопросам создания современных мобильных приложений для мобильных платформ iOS, Android, Bada и WP7».
Основная аудитория, опять же, цитирую:

• программисты;
• руководители проектов;
• дизайнеры и специалисты по юзабилити;
• QA специалисты;
• студенты и преподаватели.

Вот именно на дизайнере и специалисте по юзабилити моё сердце и растаяло

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.


Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

Алгоритм построен на той идее, что в реальном мире сортируемый массив данных часто содержат в себе упорядоченные (не важно, по возрастанию или по убыванию) подмассивы. Это и вправду часто так. На таких данных Timsort рвёт в клочья все остальные алгоритмы.

Веб-сервисы в наше время становятся очень популярными. И это понятно, они универсальны. На их основе можно написать кроссплатформенное мобильное приложение на HTML5, сделать гаджет для рабочего стола Windows 7 или просто вывести на сайт список последних новостей.

Я бы хотел продемонстрировать, как можно, совмещая современные технологии, такие как REST-сервис, OData и jQuery, работать с SharePoint 2010 через его стандартный RESTful интерфейс на примере создания небольшой веб-части для поиска и просмотра данных о сотрудниках компании. Главная особенность моего примера — это отсутствие server-side программирования.