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

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

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

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

Windows принято не любить. Однако, зачастую, фраза: «Книгу писателя не читал, но осуждаю» очень хорошо описывает эту ситуацию. Несмотря на укоренившееся презрение к «Винде», отдельные вещи в ней реализованы весьма удачно, и именно об одной из них мы хотели бы написать. Отдельные фрагменты WinAPI, хотя и были реализованы достаточно давно, по разным причинам, и часто незаслуженно, выпали из поля зрения широкой аудитории.
В этой статье речь пойдёт о встроенной в ОС реализации lock-free стека и сравнении его производительности с кросс-платформенными аналогами.

Для понимания этой статьи читатель должен иметь начальный опыт разработки windows-приложений в среде Qt Creator.
В примерах используются Qt Creator 3.0.0 (MinGW) и Qwt-6.1.0.

Qwt – графическая библиотека, позволяющая значительно упростить процесс визуализации данных в программе. Упрощение заключается в следующем: нет необходимости вручную прописывать элементы отображения, такие как шкалы координат, сетки, кривые данных и проч. Следует лишь задавать параметры этих элементов.
Аналогия: для того, чтобы построить график в Excel Вы выбираете данные и настраиваете параметры их отображения: минимум и максимум шкал, цвет кривых, подписи данных и др. За визуализацию отвечает Excel – сами элементы Вы не программируете.
Особо отмечу, что Qwt позволяет работать с достаточно большими объемами данных (я работал с 200 000 точек) без возникновения раздражающих «тормозов».
В данной статье мы будем отображать кривую на графике, масштабировать ее, перемещаться по графику, смотреть координаты курсора. Таким образом, мы реализуем минимальный функционал, необходимый для вывода и просмотра графиков. В последующих статьях наш графический редактор будет оснащен дополнительными возможностями.

MagicClass::getInstance().getFooFactory().createFoo().killMePlease();

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

Постановка

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

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

Упрощенный доступ к объектам. Информация, какой объект откуда можно получить чаще всего совершенно неинтересна. Более того, она отвлекает от базовой функциональности и способствует более сильному связыванию подсистем проекта, чем того хочется. Также нежелание программиста продумывать адекватные точки доступа к добавляемым сервисам может негативно сказаться на общей архитектуре системы. «В последние дни я получал почти все нужные мне объекты из модуля номер N, закину и эти туда же...».

Рабочий вариант с тестовым примером можно взять отсюда.

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

Причина побудившая автора к публикации

Первая версия описания алгоритма было послана мною в институт математики им. С. Л. Соболева Сибирского отделения РАН, откуда был прислан ответ что указанный алгоритм известен давно. Цитирую:

Одно из его первых упоминаний в книге Кереллера Nemhauser, Ullman, Discrete dynamic programming and capital allocation, Management Science, 15 p. 494-505, 1969.

Тем не менее я решил ознакомить сообщество с алгоритмом, т.к. в известных мне учебниках по дискретной математике я его не обнаружил (возможно плохо искал). В первой версии алгоритма была ошибка, указанная мне пользователем wataru. За это ему большое спасибо. Я постарался эту ошибку устранить. До алгоритма я дошел самостоятельно, так что надеюсь ничьих прав не нарушаю. Возможно кому нибудь описание будет интересно и пригодится.

Если вы знаете, что такое ICU, то, вероятно, вы не узнаете из этого поста ничего нового.

    Порой приходится слышать от товарищей, что на собеседовании их просили написать код, который бы обращал строку. И даже в Cracking the Coding Interview это второй вопрос в тестах. Однако, правильное, с моей точки зрения, решение выходит далеко за рамки библиотечного вызова или одного цикла while.

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

Доброго времени суток, хотел бы поделиться с сообществом своей небольшой библиотектой.
Я программирую на С/C++, и, к сожалению, в рабочих проектах не могу использовать стандарт C++11. Но вот пришли майские праздники, появилось свободное время и я решил поэкспериментировать и по-изучать этот запретный плод. Самое лучшее для изучения чего либо — это практика. Чтение статей о языке программирования научит максимум лучше читать, поэтому я решил написать маленькую библиотеку для асинхронного выполнения функций.
Сразу оговорюсь, что я знаю, что существует std::future, std::async и тп. Мне было интересно реализовать самому нечто подобное и окунуться в мир лямбда-функций, потоков и мьютексов с головой. Праздники — отличное время для велопрогулок.

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

Обмен сообщениями достаточно фундаментальная вещь в науке Computer Science. Будем рассматривать её в приближении к событийно-ориентированному программированию (event-driven). Терминология, возможности и реализации могут отличаться: события (events), сообщения (messages), сигналы/слоты (signals/slots) и callbacks. В целом суть, что с приходом события запускается ответная реакция.
Сама система обмена сообщениями в статье послужила демонстрацией вольной, но допустимой интерпретации ссылок/указателей, упрощающей код. Получившаяся система тривиальна и умеет только регистрировать обработчик на определённый код сообщения и посылать сообщения с таким кодом.
Допустим что обработчики нетривиальные, а сообщений немного. И что мы сами генерируем сообщения и они не приходят нам по сети, например. В таком случае хочется иметь что-то более удобное с явными объявлениями переменных в сообщении. Например, нечто подобное:

StringMessage* str_message = ...;
send(my_message);
...
void handle_message(const Message* message) {
	assert(message);
	const StringMessage* str_message = dynamic_cast<const StringMessage*>(message);
	assert(str_message);
	std::cout << str_message->message ...
}

Но хочется убрать проверочный код, не имеющий отношения к логике работы, под капот. Заменим поэтому указатель на ссылку, показав что в обработчик точно приходит объект, а не NULL nullptr. И пусть обработчик сразу принимает требуемый им тип сообщения.

void handle_message(const StringMessage& message) {
	...
}

Как осуществить задуманное и поддержать другие возможные классы сообщений?

Не так давно передо мной встала задача: написать кроссплатформенный сервер для обработки запросов по протоколу ssl. До этого я писал сервера для обычных, не шифрованных протоколов, но с ssl столкнулся впервые.
Беглый обзор интернета показал, что лучшим решением будет не велосипедостроение, а использование библиотеки OpenSSL.
В этой статье я не хочу рассматривать процесс установки OpenSSL на Linux и Windows, замечу лишь, что для Windows процесс этот оказался нетривиальным. А рассказать я хочу о том, как мне удалось скомпилировать в Visual Studio пример простейшего сервера, входящий в состав исходников OpenSSL.
Неискушенному читателю может показаться: «что тут особенного — создал проект, включил в него готовый исходник, запустил»… Однако обо всем по порядку.

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

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

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

Давным давно был язык С. И были в нем 2 функции управляющие памятью — malloc и free. Но это было слишком сложно.
Посмотрел на это Бьёрн Страуструп и решил что нужно сделать все проще. И изобрел С++. В дополнение к malloc/free там появились new/delete, деструкторы, RAII, auto и shared указатели.
Посмотрел на это Гвидо ван Россум, и решил, что С++ тоже не достаточно прост. Он решил идти другим путем и придумал Python, в котором даже malloc и free нет.
А тем временем норвежские троли создали на С++ GUI-библиотеку Qt, которая упрощает управление памятью для своих объектов за счет того, что сама их удаляет, когда посчитает нужным.
Phil Thompson расстроился, что отличной библиотеки Qt нету для замечательного языка Python. И решил их объединить проектом PyQt. Однако, как оказалось, если скрестить разные парадигмы управления памятью, обязательно вылезут побочные эффекты. Давайте посмотрим какие…

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

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

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

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

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

В предыдущих трех частях мы создали лексер, парсер и AST для нашего игрушечного языка IMP. Мы даже написали нашу собственную библиотеку парсеров комбинаторов. В этой, финальной статье мы напишем последний компонент интерпретатора — исполнитель.


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

Таким образом, мы написали лексер библиотеку комбинатора парсеров для нашего интерпретатора. В этой части, мы создадим структурные данные абстрактного синтаксического дерева (AST), и напишем парсер, используя нашу библиотеку комбинаторов, которые переводят список токенов, возвращенных лексером, в абстрактное синтаксическое дерево (AST). После того, как мы распарсим AST, запустить программу будет очень просто.

Как скоро я смогу вас заинтересовать, если скажу, что в этой статье речь пойдет о VPN-сервере, который может поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол «SSL-VPN», который неотличим от обычного HTTPS-трафика (чего не скажешь про OpenVPN handshake, например), может работать не только через TCP/UDP, но и через ICMP (подобно pingtunnel, hanstunnel) и DNS (подобно iodine), работает быстрее (по заверению разработчиков) текущих имплементаций, строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает как kernel-mode, так и user-mode NAT, IPv6, шейпинг, QoS, кластеризацию, load balancing и fault tolerance, может быть запущен под Windows, Linux, Mac OS, FreeBSD и Solaris и является Open-Source проектом под GPLv2?

То-то и оно. Такое пропустить нельзя.

Этот вопрос уже давно подробно изучен, и наиболее широкое распространение получил метод полярных координат, предложенный Джорджем Боксом, Мервином Мюллером и Джорджем Марсальей в 1958 году. Данный метод позволяет получить пару независимых нормально распределенных случайных величин с математическим ожиданием 0 и дисперсией 1 следующим образом:

где Z₀ и Z₁ — искомые значения, s = u² + v², а u и v — равномерно распределенные на отрезке (-1, 1) случайные величины, подобранные таким образом, чтобы выполнялось условие 0 < s < 1.
Многие используют эти формулы, даже не задумываясь, а многие даже и не подозревают об их существовании, так как пользуются готовыми реализациями. Но есть люди, у которых возникают вопросы: «Откуда взялась эта формула? И почему получается сразу пара величин?». Далее я постараюсь дать наглядный ответ на эти вопросы.

Concise Binary Object Representation (сжатое бинарное представление объекта) — формат данных, который был спроектирован таким образом, чтобы обеспечить максимально простой код реализации, формирования компактных выходных данных и возможность расширения формата без необходимости обмена информацией о версии.

Стандарт формата CBOR был официально анонсирован комитетом IETF в октябре 2013 года в новом документе RFC 7049, авторами которого являются Carsten Bormann и Paul Hoffman. Взглянув на имя первого автора, можно предположить другую причину происхождения аббревиатуры для названия формата, но возможно это просто совпадение. Формат CBOR получил MIME-тип application/cbor.

На данный момент существует, вероятно, сотни всевозможных бинарных форматов для представления структурированных данных, ряд которых стандартизирован, популярен и широко применяется (например, BER и DER для ASN.1, MessagePack и BSON). Все существующие стандарты решают поставленные перед ними задачи, и CBOR здесь не исключение. К формату было предъявлено семь важных требований, и, поскольку ни один из существующих форматов в полной мере не мог им удовлетворить, был создан новый (да, тут напрашивается картинка ).