Порой встречаются такие артефакты природы, что начинаешь невольно задумывать о разных конспирологических теориях и альтернативной истории. Сегодня я хотел бы поговорить о разных малоизвестных и не очень аспектах операционной системы MS-DOS. Историй про дос на хабре было огромное множество: краткие очерки, подробная хронология, мемуары ностальгирующих, но никто ни разу не отмечал про MS-DOS 4.0 от 1985 года. Я считаю это очень важным звеном развития операционных систем для IBM PC, но удивительно мало информации о таком важном переходном этапе. Это буквально утерянная ветка доса и найти про нее информацию большая проблема. Что бы вы подумали если бы услышали о поддержке в DOS вытесняющей многозадачности, виртуальной памяти, свопа, семафоров и IPC. Фантастика?

Всем привет.

В прошлую субботу — 19 апреля прошла очередная встреча C++ User Group. На этот раз мы встречались в Нижнем Новгороде.
На встречу пришло 82 человека, причём участники были не только из Нижнего Новгорода: Санкт-Петербург, Москва, Рязань, Саратов, Чебоксары, Екатеринбург, Великий Новгород. Меня немного пугает, что зарегистрировался, но не приехал участник из Иркутска. Надеюсь, с ним всё хорошо.

Всем привет!
Не так давно я писал о своей поездке на конференцию Meeting C++ в Дюссельдорфе. В процессе обсуждения поездки с разными людьми, в том числе на Хабре я понял, что не только мне не хватает живого общения с коллегами. Есть много встреч, конференций и семинаров, посвящённых разработке ПО и разным её аспектам. Но, в свете появления нового стандарта поменялось многое и обсудить это хочется не только в интернете, но и лично. То есть хочется поговорить именно о C++ и связанных вопросах: новый стандарт, тренды, boost, разные полезные либы, решения и прочее. Так за обсуждениями я как-то незаметно и внезапно для самого себя решил организовать C++ User Group в России.

Под катом кратко что из этого пока вышло.

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


АЧХ шума.

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

Официальный учебный курс «Введение в Linux» от Linux Foundation, который ранее стоил 2400 долларов, будет доступен бесплатно на платформе онлайн-обучения EdX. Записаться на курс можно уже сейчас. Платформа массового онлайн-обучения EdX была создана Массачусетским технологическим институтом совместно с Гарвардским университетом. На ней представлены уже больше 30 университетов. Теперь и Linux Foundation станет официальным партнёром EdX. Курсу присвоен код LFS101x. Он рассчитан на 40 — 60 часов обучения. Занятия начнутся в 3-м квартале 2014 года.

От переводчика: это вторая часть перевода статьи Olivier Goffart о внутренней архитектуре сигналов и слотов в Qt 5, перевод первой части тут.

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

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

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

В прошлом году специалисты SkyDNS и Айдеко подготовили и прочитали в Уральском федеральном университете (УрФУ) курс «Сетевое программирование в UNIX». Спецкурс предназначался для студентов математико-механического факультета УрФУ. «Мы анонсировали его как курс для тех, кто не боится UNIX и С», — рассказал Александр Патраков, ведущий разработчик компании SkyDNS.

Откровенно говоря, ранее я ни разу не занимался в серьезной мере методами тестирования программного обеспечения. Однако, понимаю, что для полной уверенности в том, что программа будет работать, нужно перепробовать всевозможные варианты её использования. Также очевиден для меня и тот факт, что сделать это не всегда возможно. Если имеются конкретные варианты использования, но невозможно проверить их всех в силу их количества, стараются построить набор, который покроет все самые используемые варианты. Но что делать, если использование всех вариантов равновероятно? Как за минимальное число времени обнаружить все ошибки, на которые есть большая вероятность наткнуться? Данная задача действительно известна, и с ней нередко сталкиваются, ну хотя бы, в Яндексе.

Чтобы стало понятно о чем идет речь, представим, что нам необходимо протестировать какую-либо программу или сайт. Очень хорош пример с тестированием веб-формы, скажем, для регистрации или для поиска. Возникает вопрос, с какими ошибками в ней скорее всего встретится пользователь? Пускай у нас в форме имеется 6 вопросов, для каждого из которых возможны 10 вариантов ответа. Допустим, на страницу зашел целый миллион пользователей, и каждый из них ответил уникально. Теперь представим, что в форме для заполнения ответами скрывается ошибка. Если ошибка обнаруживается только при определенной комбинации ответов на все 6 вопросов, то на неё наткнется лишь один человек. Если же ошибка вылетает при наборе определенных ответов на какие-то 3 вопроса, то количество людей, обнаруживших ошибку возрастет до тысячи. Очевидно, что чем меньше элементов в комбинации, требуемой для ошибки, тем больше людей с ней встретится. Соответственно, перед нами теперь стоит задача: если мы не можем обнаружить все ошибки, то давайте хотя бы найдем самые критичные, то есть те, на которые наткнется больше всего пользователей.
Таким образом, мы должны сформировать тест-кейсы (и чем меньше, тем лучше), при переборе которых мы наткнемся на самые легкодоступные ошибки. Допустим, у нас имеется множество вопросов A, которое мы задаем количеством вариантов ответа на каждый из них: А = {2, 3, 5, 2, ...}. Пусть n — количество вопросов, а 1≤m≤n — степень критичности ошибок, она же степень покрытия или глубина покрывающего набора. Чем меньше значение m, тем критичнее ошибка. Задавая степень покрытия мы строим тестовый набор, который позволит обнаружить все ошибки, степень критичности которых меньше данного m. Если m = n, то поиск ошибок сводится к перебору всех вариантов. Чем меньше задаем степень, тем меньше тест-кейсов будет сформировано и тем меньше ошибок мы найдем.

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

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

В этом посте я поразмышляю на тему статического полиморфизма в С++, архитектурных решениях, строящихся на его основе. Рассмотрю интересную идиому — CRTP. Приведу несколько примеров ее использования. В частности, рассмотрю концепцию MixIn классов. Пишу, чтобы систематизировать собственные знания, но может быть и вы сможете найти что-то интересное для себя.

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

Я зашел на сайт всем известной российской фриланс-биржи и увидел, что за год моего отсутствия там ничего не изменилось: платят — мало, просят — много и так далее. Так у меня родилась идея посмотреть, что происходит на западе. Я нашел на Хабре статьи про иностранные биржи Odesk и Elance, почитал, подумал, как все сложно, и благополучно забыл про эту затею.

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

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

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

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

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



Читает курс Андрей Райгородский. Доктор физико-математических наук. Профессор кафедры математической статистики и случайных процессов механико-математического факультета МГУ им. М. В. Ломоносова. Заведующий кафедрой Дискретной математики ФИВТ МФТИ. Профессор и научный руководитель бакалавриата кафедры «Анализ данных» факультета инноваций и высоких технологий МФТИ. Руководитель отдела теоретических и прикладных исследований компании «Яндекс». (Ещё больше можно узнать в статье о нём на Википедии).

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

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

TLDR: как определять, есть ли в типе метод с данным именем и сигнатурой, а также узнавать другие свойства типов, не сойдя при этом с ума.

Здравствуйте, коллеги.
Хочу рассказать о SFINAE, интересном и очень полезном (к сожалению*) механизме языка C++, который, однако, может представляться неподготовленному человеку весьма мозгоразрывающим. В действительности принцип его использования достаточно прост и ясен, будучи сформулирован в виде нескольких чётких положений. Эта заметка рассчитана на читателей, обладающих базовыми знаниями о шаблонах в C++ и знакомых, хотя бы шапочно, с C++11.
* Почему к сожалению? Хотя использование SFINAE — интересный и красивый приём, переросший в широко используемую идиому языка, гораздо лучше было бы иметь средства, явно описывающие работу с типами.

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

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

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

Test Driven Development (TDD) – неоспоримо выдающаяся техника, дающая ряд преимуществ. Прикладные разработчики, причём вне зависимости от масштаба проекта и количества вовлеченных специалистов, в широкой массе не следуют TDD. Но есть и ярые сторонники такого подхода, причём они готовы апеллировать не только к здравому смыслу или производственной необходимости, но и на безоговорочно успешные примеры его внедрения. Одним из таких апологетов является Александр Люлин, который не только рассказывает о степени позитивного влияния TDD на разработку, но и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники вплоть до исходных кодов и примеров сценариев (в своем блоге). Однако главный тормоз на пути следования принципам TDD стоит, что предсказуемо, набор чисто психологических установок. В режиме «жёсткого разговора» мы пообщаемся с Александром на тему необходимости Test Driven Development.

Test Driven Development – попытка следования моде? Слепое копирование чужих подходов?

Давайте «сразу определимся». Я не использую TDD в его классическом понимании. И не надо здесь цитировать «википедию»! Вообще, вряд ли кто-то из профессионалов рассматривает энциклопедические статьи в качестве руководства к действию. Мы свой подход «выстрадали» в рамках реализации успешного проекта, поэтому за нами реальный опыт, а не «тупое использование чужих идей». Скорее, мы используем синтез из TDD и собственных представлений о том, как нужно разрабатывать ПО. Даже если эти «внешние идеи» исходят от очень умных людей, их следует критически осмыслить и адаптировать к реальной компании, существующей команды и стратегии развития и обеспечения качества. Но я далее буду говорить «TDD», имея ввиду тот процесс “разработки через тестирования», который близко соотносится с энциклопедическим Test Driven Development, но идёт гораздо дальше него.

TDD — это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?

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