Одна из новых возможностей C++11 — спецификатор constexpr. С помощью него можно создавать переменные, функции и даже объекты, которые будут рассчитаны на этапе компиляции. Это удобно, ведь раньше для таких целей приходилось использовать шаблоны. Но тут все не так просто. У тех, кто не так хорошо знаком с constexpr, может сложиться впечатление, что теперь не будет никаких проблем с расчетами на этапе компиляции. Но на constexpr-выражения наложены серьезные ограничения.

В первой части будет рассказано про constexpr, о том, какие будут изменения в стандарте C++14, а во второй части будет пример использования constexpr: библиотека, которая считает результат математического выражения в строке.
С помощью нее можно будет написать следующий код:

constexpr auto x = "(4^2-9)/8+2/3"_solve;
std::cout << "Answer is " << x;

И ответ в виде дроби будет получен на этапе компиляции:
Answer is 37/24
Сразу предупреждаю, код этой библиотеки сложно понять.
Кому эта тема интересна, добро пожаловать под кат!

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

Когда вы будете искать сотрудников, помните, что нанимаете скорее совладельца, нежели работника. Их уровень компетентности в каких-либо вопросах должен быть на голову выше вашего. В противном случае вы нанимаете себе проблему, которую придется вам решать самостоятельно и при этом расти будет очень сложно.

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

В чем суть:
Во-первых, все исполнители в нашей команде – это фрилансеры. Они достаточно самостоятельны, постоянно развиваются профессионально, их не нужно заставлять работать, они уже мотивированны и ведут образ жизни, который им нравится.

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

В-третьих, вся работа выполняется сдельно, существуют премии, бонусы, но не оклады, что заставляет участников команды быть заинтересованными в высоких результатах, в больших объемах работы.

Я разработал около сотни проектов, в том числе — стартапов. Многие из них достигали пика и умирали, некоторые работают до сих пор. Делал как B2C, так и B2B.

В последнее время наблюдается поток вопросов от знакомых и друзей, которые делают одни и те же ошибки. Я хотел бы рассказать о своем опыте в посте тезисов. И если он будет успешен — продолжить серию.

Если лень читать — ролик, выражающий основной дух и главный смысл, находится внизу. Ролик вызовет восхищение — отлично, идите делать очередной релиз. Ролик вызовет отторжение — читайте пост до другой реакции сколько угодно :)

1. Важнее всего — желание

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

Как вы, наверное, догадались, эта статья посвящена lock-free очередям.

Очереди бывают разные. Они могут различаться по числу писателей (producer) и читателей (consumer) – single/multi producer — single/multi consumer, 4 варианта, — они могут быть ограниченными (bounded, на основе предраспределенного буфера) и неограниченными, на основе списка (unbounded), с поддержкой приоритетов или без, lock-free, wait-free или lock-based, со строгим соблюдением FIFO (fair) и не очень (unfair) и т.д. Подробно типы очередей описаны в этой и этой статьях Дмитрия Вьюкова. Чем более специализированы требования к очереди, тем, как правило, более эффективным оказывается её алгоритм. В данной статье я рассмотрю самый общий вариант очередей — multi-producer/multi-consumer unbounded concurrent queue без поддержки приоритетов.

Сегодня столкнулся с прекращением работы антивируса Microsoft Security Essentials на Windows XP. Как известно, 8 апреля 2014 года закончилась поддержка Windows XP, поэтому в Microsoft решили отключить и антивирус для этой системы. Сообщения о том, что MSE будет работать ещё год для этой системы, не оправдались — доступная в виде дистрибутива версия 4.4.304.0 работает, однако новая версия 4.5.216.0, которая автоматически устанавливается с обновлениями безопасности, выключает антивирус и предупреждает пользователя о том, что ОС устарела и от неё пора бы избавиться. Но слишком много людей пользуются этой системой и этим удобным антивирусом, поэтому я нашёл решение, которое позволяет антивирусу работать дальше.

В предыдущих своих заметках я описал основу, на которой строятся lock-free структуры данных, и базовые алгоритмы управления временем жизни элементов lock-free структур данных. Это была прелюдия к описанию собственно lock-free контейнеров. Но далее я столкнулся с проблемой: как построить дальнейший рассказ? Просто описывать известные мне алгоритмы? Это довольно скучно: много [псевдо-]кода, обилие деталей, важных, конечно, но весьма специфических. В конце концов, это есть в опубликованных работах, на которые я даю ссылки, и в гораздо более подробном и строгом изложении. Мне же хотелось рассказать интересно об интересных вещах, показать пути развития подходов к конструированию конкурентных контейнеров.
Хорошо, — подумал я, — тогда метод изложения должен быть такой: берем какой-то тип контейнера — очередь, map, hash map, — и делаем обзор известных на сегодняшний день оригинальных алгоритмов для этого типа контейнера. С чего начать? И тут я вспомнил о самой простой структуре данных — о стеке.

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

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

Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом 'пережитке прошлого' (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.

На одном из давних тренингов мы отрабатывали кейс “Сотрудник не присылает вовремя отчеты”. Кейс абсолютно не привязанный к реальной жизни — ведь такого же не бывает, чтобы люди не присылали вовремя отчеты, верно?

И вот одному менеджеру не досталось пары, и я встал играть роль сотрудника. До этого всем пар хватало, поэтому к роли сотрудника я был не очень готов…

Моим собеседником оказался молодой человек, назовем его Егор, технический директор небольшой компании.

Цель кейса — донести до сотрудника обратную связь, что отчеты надо присылать вовремя. Егор начал сразу с места в карьер:

— Александр, как же так, почему Вы не присылаете мне отчеты?

Я стоял, думал-думал, чего сказать. И потом ляпнул первое, что пришло в голову:

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

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

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

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

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

От использования шаблонов в С++ лично меня всегда отпугивало отсутствие стандартных механизмов задания ограничений параметров. Другими словами, когда разработчик пишет функцию

template <class T>
bool someFunc(T t)
{
	if (t.someCheck()) {
		t.someAction(0);
	}
}

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

В данной статье рассматривается идея и практическое руководство по создания многопользовательской рабочей станции (multiseat) с использованием виртуализации KVM, с возможностью удаленного управления через libvirt. С помощью этого руководства возможно создать два и более рабочих мест как в офисе, так и дома, которым может потребоваться возможность полного использования графической подсистемы компьютера. Причем можно на одном системном блоке реализовать одновременно работу различных операционных систем Windows, Linux, Mac OS X, остальное по вкусу.

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

Да и вообще написание диссертации иногда полезно и с профессиональной точки зрения, когда, например, занимаешься наукоемким бизнесом (то, к чему в итоге я сам и пришел) и хочется впечатлить клиентов глубиной, шириной и высотой познаний и регалий.

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

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

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

Менеджер продукта – все еще редкий зверь в российских и украинских IT компаниях. И если внутри команд, где менеджер продукта существует, его роль вопросов не вызывает (если он, конечно, занимается делом), то знакомые в других компаниях, на конференциях, друзья, от разработчиков до менеджеров проектов задают массу любопытствующих вопросов. Вопросы очень разномастные – от того, о чем собственно работа, и как устроен процесс работы над продуктом в нашей команде, до того, где поучиться, что почитать, и где вообще берут на работу продакт менеджеров.

Самый популярный вопрос «а что почитать, если я хочу заниматься продуктом» побудили меня собрать в одно целое список книг, которые очень помогли мне в разное время, от первых шагов в продуктах до работы с классной командой профессионалов, которым, как я надеюсь, со мной уютно.

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

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

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

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Приветствую хабросообщество!
Наверно каждый кто профессионально разрабатывает ПО или просто увлекается программированием, рано или поздно приходил к необходимости создавать пользовательский интерфейс для своей программы. И если не рассматривать нативные для платформ окружения и языки такие как C# для Windows или Objective-C для Mac OS X которые изначально содержат средства для визуализации интерфейса, то выбор оказывается не очень богатым, особенно если мы не горим желанием платить деньги за средства разработки GUI или желаем добиться кроссплатформенности.
В своем первом посте на Хабре я бы хотел рассказать о таком фреймворке как JUCE. Поиск по Хабру выдал всего 2 статьи где данный фреймворк только упоминается, но ни какой детальной информации не приводится. Думаю что тем кто только начинает осваивать кроссплатформенные GUI приложения на C++ будет интересно узнать об альтернативе таким монстрам как Qt или таким старичкам как GTK+

Не так давно в boost-1.53 появился целый новый раздел — lockfree реализующий неблокирующие очереди и стек.
Я последние несколько лет работал с так называемыми неблокируюшими алгоритмами (lock-free data structures), мы их сами писали, сами тестировали, сами использовали и втайне ими гордились. Естественно, у нас немедленно встал вопрос, переходить ли с самодельных библиотек на boost, и если переходить, то когда?
Вот тогда у меня и возникла в первый раз идея применить к boost::lockfree кое-какие из методик которыми мы испытывали собственный код. К счастью, сам алгоритм нам тестировать не придется и можно сосредоточиться на измерении производительности.
Я постараюсь сделать статью интересной для всех. Тем кто еще не сталкивался с подобными задачами будет полезно посмотреть на то что такие алгоритмы способны, а главное, где и как их стоит или не стоит использовать. Для тех кто имеет опыт разработки неблокирующих очередей возможно будет интересно сравнить данные количественных измерений. Я сам по крайней мере таких публикаций еще не видел.

Больше года прошло с того момента, как я начал писать проект jNode, и вот пришла пора первого релиза. Это вовсе не значит, что все это время проект был неиспользуемым, вовсе нет — только в российском регионе как минимум 5 узлов используют jNode. Но все это время проект был в стадии unstable. Хочешь использовать — скачай исходники, собери их, настрой конфигурационный файл и заполни базу данных начальными значениями. И никак иначе.

Но теперь ( наконец-то! ) пришла пора восстановить справедливость и дать возможность всем желающим поднять свой узел в Фидо просто и без проблем с минимальным приложением усилий. Кстати, я знаю, что Фидо мертво, все полимеры давно закончились, а мы — кучка старых ( и молодых ) маразматиков.

13 января Компьютерная команда экстренной готовности США (US-CERT) выпустила предупреждение о новом способе DDoS-атак. Зараженные компьютеры отправляют запрос monlist с поддельным IP-адресом отправителя к NTP-серверу. Запрос monlist возвращает список из последних 600 клиентов ntpd. Таким образом, небольшим запросом от зараженного компьютера к жертве отправляется большой поток UDP. В этом и заключается сущность амплификации.

Незащищенный NTP-сервер становится невольным промежуточным звеном атаки.
Атаке подвержены версии ntpd до 4.2.7p26 (стабильная сейчас 4.2.6p5).

Проверить свой сервер на уязвимость можно выполнив команду

ntpdc -c monlist адрес_сервера

Если команда выдает список клиентов (а не «timed out, nothing received»), значит система уязвима.