Как вы, возможно, знаете, на днях в Украине и Польше начался Чемпионат Европы по футболу 2012 (кстати, команда России уже успела выиграть у Чехии со счётом 4:1). Мы решили (на фоне всяких казусов), что можем сделать пребывание гостей в нашей стране чуть-чуть комфортнее и выпустили для них специальные бесплатные приложения под iOs, Android и Facebook. Ничего сверх-навороченного, просто информация о:

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

Несколько недель назад Microsoft презентовал свою новую разработку — проект Casablanca. Для того, чтобы понять что это, нужно вернуться еще чуть дальше в прошлое, к прошедшей конференции Going Native 2012, где помимо обсуждения нового стандарта С++11 было сказано еще немало умных мыслей. Одна из них была в лекции Херба Саттера. Он заметил, что самой большой проблемой современного С++ является не всякие там сборщики мусора или синтаксис лямбда-выражений, а бедность стандартной библиотеки. Когда начинающий программист на Java или C# спрашивает у своего старшего коллеги, как ему послать\принять HTTP-запрос, распарсить XML\JSON, заархивировать\разархивировать ZIP-файл и т.д. — он получает конкретный, однозначный и работающий всегда ответ: «используй вот этот класс из стандартной библиотеки». Когда начинающий программист на С++ задаёт тот же вопрос — он слышит «ну, стандартных средств для этого нет, нужно или самому писать или вот есть какие-то библиотеки, но тут надо выбирать, тестировать, читать лицензии...». В результате мы имеем дикий зоопарк библиотек с разным уровнем производительности, часто паршивенькой кроссплатформенностью, кучу самописных велосипедов, трудности в переходе между проектами, потому что «раньше я использовал boost, а тут в проекте всё на Qt» и т.д. Херб Саттер высказал мысль, что основное, на чём следует сосредоточиться — это расширение стандартной библиотеки.

Так вот, Microsoft Casablanca — это первый набросок того, как это расширение могло бы выглядеть, что в него могло бы входить и как оно всё вместе могло бы работать. Никто пока не говорит о стандартизации Casablanca как расширения стандартной библиотеки С++, но уже сейчас его можно скачать в виде отдельной библиотеки (что-то вроде альфа-версии) и попробовать поизучать. Кроме того, Microsoft пропагандирует Casablanca как средство создания производительных сервисов для платформы Azure.

Ральф вошел в помещение ангара №1 в 8:30 утра, как делал это ежедневно уже несколько лет. Его взгляд сразу же устремился к центру зала, где на постаменте, окруженный множеством приборов и паутиной кабелей, находился смысл его работы. Собственно говоря, не только его — миллионов людей по всему миру. Первый инопланетный корабль. Полтора десятилетия назад он совершил аварийную посадку и был частично поврежден, оставив, однако, весьма много материала для изучения. Настоящим чудом стало то, что политики и учёные после этого события не переругались, а смогли организовать эффективное изучение свалившегося с небес подарка. На реверс-инжиниринг корабля были брошены лучшие умы планеты. Ральф, возглавляющий группу изучения приборов связи, стоял в ангаре и в который раз любовался стремительной, похожей на стрелу в полёте, формой корабля. Он вспоминал всё, что случилось за последние годы.

Вечер пятницы, я собираю вещи в привычную короткую командировку к заказчикам. Её отличает лишь новый маршрут: предстоит побывать в Осло и Стокгольме, плюс пересадка в Амстердаме. Я размышляю о том, какую валюту брать с собой. Представив у себя в кошельке салат из евро, норвежских и шведских крон, я понимаю: возиться с обменом валют мне надоело. В конце концов, Европа, цивилизация и всё такое. Решено: командировка будет безналичной! В посте заодно расскажу о нюансах платёжных карт и платёжных систем, о которых возможно не всем известно.

Итак, вооружившись дебетовой Visa Classic и резервом в евро на «чёрный день», я отправляюсь в дорогу.

Используй то, что под рукою, и не ищи себе другое...
Филеас Фогг

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

Данный вопрос не имеет простого решения — ведь для выбора правильной стратегии по защите бизнеса необходимо провести детальный анализ, уточнить цели и выбрать правильный подход для их достижения. Как правило, наиболее оптимальным подходом для средних и крупных компаний будет поэтапное внедрение системы безопасности: начав с защиты наиболее критичных активов, постепенно расширять область, включая менее приоритетные. Большие дела начинаются с малого, и чтобы получить гарантию того, что система безопасности будет развиваться в правильном направлении и достигнет требуемого уровня зрелости к определенному сроку, необходимо уделить особое внимание самим процессам, призванным защищать компанию. Такими процессами являются управление инцидентами, рисками, управление непрерывностью, управление доступом, контроль изменений и многие другие. Если компания уделяет достаточно внимания правильности исполнения таких процессов, то проект по построению системы безопасности практически обречен на успех.

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

1) Фотоманипуляции
2) Работа с интерфейсом (сайт и мобильное приложение)
3) Типографика
4) Создание иллюстраций и векторные фишки
UPD 1: Небольшое тестирование производительности и стабильности.

Итак, поехали.

Итак, вот они результаты нашего последнего конкурса. Спасибо всем, кто принял участие.
В принципе, задачка была совсем не сложной (она такой и планировалась) и целых 56 человек с ней справились. Вот имена людей, которые сделали это первыми:

• @sefus_ru (он же sefus)
• @AbsolutePlus (он же MrLoki)
• @mp_Inside (аккаунт на Хабре не найден)

Под катом можно найти решение задачи и ссылки по теме.

Итак, дата выхода Diablo III уже отмечена красным в календаре, игровой класс выбран, напарники найдены, а на работе взят отпуск? Если единственное, чего не хватает для счастья — это лицензии на саму игру, то вот он шанс её получить. Мы разыгрываем 3 лицензии на Diablo III и получат их первые трое, кто напишет в твиттер сообщение с определённым текстом и хештегом — куда уж проще, правда? Удачи всем!

Ах да! «А что же писать?» — спросите вы? Текст сообщения и хештег легко можно получить с картинки под катом. Срок конкурса — 2 суток с момента публикации данного топика. Имена победителей будут опубликованы в пятницу, 13-го апреля.

Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.

Итак, время для верного ответа на ранее опубликованную задачку. Спасибо всем поучаствовавшим. Первым же комментарием к посту была вывешена вот эта ссылка. Я, признаться, верил, что она появится не сразу и позволит чуть-чуть продлить интригу. Но Хабр есть Хабр и на каждую хитрую гайку тут найдется свой болт с левой резьбой — и это прекрасно, за то его и любим.

Однако не так был прост конкурс, чтобы его можно было выиграть одной лишь ссылкой на MSDN — там объясняются лишь знаки 1, 2, 3, 7 и 8. А вот что означают и чем друг от друга отличаются 4, 5 и 6 — в этом и была сама задача. К сожалению, многие посчитали первый комментарий верным ответом и отказались от дальнейшего участия. А зря. Прошу под кат.

Многие из вас, возможно, видели всякие загадочные знаки на полях. Нет, не те что на картинке слева :). Я имею в виду значки на полях редактора кода в Visual Studio. Наиболее известными являются иконки точки останова (Breakpoint) и закладки (Bookmark) . Но есть и другие. Я предлагаю небольшой конкурс: вот 8 значков, которые могут появиться на полях редактора кода в Visual Studio 2010 (без всяких плагинов). Первый, кто верно объяснит их все, получит от меня инвайт на Хабр.

Пишите ответы комментариями к этому топику, а у кого нету аккаунта на Хабре — пишите куда угодно и бросайте ссылку в твиттер с хештегом #VsMisterySigns — обещаю всё прочитать. Ответы удобно нумеровать в соответствии именам интовских переменных в коде. Срок приёма ответов — сутки с момента публикации. Объявление победителя — в течение суток по окончанию приёма ответов, развёрнутой статьей в этих же хабах.

P.S. Обратите внимание, №4 и №6 — это не глюк в задании, это разные значки, обозначающие разные вещи. Смотрите внимательно. Все претензии — к дизайнерам Visual Studio.

Upd. Дискуссия в твиттере поактивнее комментов. Дерзайте, друзья, у всех есть шансы.
Upd2. Ставки сделаны, ставок больше нет. Результаты.

Продолжая тему работы с Windows Installer, сегодня предлагаю поговорить о готовых инсталляторах, предоставляемых производителями ПО – для их обозначения широко применяется термин «vendor MSI».

Как вы помните из прошлой статьи, Windows Installer является промышленным стандартом установочных файлов и используется в большинстве систем развертывания приложений. Vendor MSI очень удобны для системных администраторов, занимающихся развертыванием ПО в корпоративных сетях. Казалось бы, достаточно взять из документации установочные параметры, использовать их в командной строке или трансформе – и дело сделано. Всё ли так просто?

Предлагаю заглянуть внутрь нескольких vendor MSI и разобраться с их устройством.

Просматривая материалы конференции 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 рвёт в клочья все остальные алгоритмы.