Приветствую молодую часть Хабрахабра.

Как вы можете догадаться из названия топика, речь пойдёт об абитуриентах, кто в эти выходные делает выбор — МГУ или ВШЭ, а может между чем-то ещё.

Я успешно отучился 2 (UPD: 4) курса на факультете программной инженерии ВШЭ, давно хотел написать небольшой рекламный пост.
Рекламщик из меня плохой, да и вопросов для обзора придумать самостоятельно не смог.

Зато в эти дни меня часто стали спрашивать примерно так

Привет! Ты с ПИ ВШЭ? Если да, то можешь ответить на несколько вопросов по поводу ПИ (я абитуриент, надо определиться окончательно в ближайшие дни).

И я подумал, почему бы не ответить подробно и не выложить на хабр. Вопросы довольно специфичные и относятся к первым двум курсам.
Предполагается, что вы уже знакомы с НИУ-ВШЭ и, в частности, с факультетом ПИ.
Данная статья была актуальна пару лет назад, сейчас многое изменилось в лучшую сторону, а ещё Яндекс и Высшая школа экономики открывают факультет Computer Science.

Работая в сфере ИТ, волей-неволей замечаешь огромное количество ошибок в различном программном обеспечении. Будь то ошибки мировых вендоров Microsoft, или же в прикладных бизнес-решениях фирмы 1С, или же в хваленных Apple с детской фатальной ошибкой "1 января 1970". Что уж говорить про небольшие компании с небольшим штатом программистов?

Насколько ошибки в ПО являются естественным процессом? Давайте разберёмся. Всё ниже является исключительно авторским мнением, в том числе классификация, возможность применения теории конечного автомата, наблюдения. 

В первые дни работы программистом на Python все мы сталкиваемся с разными типами багов в нашем коде, которые после нескольких болезненных часов в StackOverflow оказываются не багом, а фичей Python'а. Ниже приведены 5 самых распространенных ошибок, которые делают большинство начинающих программистов на Python. Давайте немного о них узнаем, чтобы сэкономить несколько часов, задавая вопросы на страницах и в группах в Facebook.

Группа греческих учёных под руководством Диомидиса Спинеллиса провела интересное исследование чувствительности десяти популярных языков программирования к ошибкам и опечаткам при наборе текста программы. Ущерб от таких ошибок иногда может составлять многие миллионы, и способность языка обнаруживать их как можно раньше очень важна для разработки надёжных программ. Для тестирования использовались несколько примеров из проекта Rosetta Code — вики, на которой собраны реализации множества задач и алгоритмов на разных языках. На основании статистических данных о популярности языков, а так же некоторых практических соображений (наличие свободного компилятора и примеров на Rosetta Code) были выбраны следующие языки и компиляторы:

Язык	компилятор/среда
C	gcc 4.4.5
C++	g++ 4.4.5
C#	mono 2.6.7, CLI v2.0
Haskell	ghc 6.12.1
Java	OpenJDK 1.6.0_18
JavaScript	spidermonkey 1.8.0
PHP	PHP 5.3.3-7
Perl	perl 5.10.1
Python	python 2.6.6
Ruby	ruby 1.8.7

Продолжу экскурсию по ошибкам в программах и демонстрацию полезности статического анализа кода.

Это мой последний пост про пока недоступную для скачиванию версию PVS-Studio. Планирую, что через неделю вы уже сможете попробовать первую beta-версию с новым набором правил общего назначения.

Рассмотрим два проекта. Первый — Fennec Media Project. Это универсальный медиа-плеер ориентированный на воспроизведение аудио и видео в высоком разрешении. В комплект исходных кодов входит множество модулей расширения (plugins) и кодеков, но анализироваться будет только сам плеер. Исходный код последней на данный момент версии 1.2 Alpha доступен здесь.

Второй проект — qutIM. Это кроссплатформенный клиент мгновенного обмена сообщениями с открытым исходным кодом. Был проанализирован код на момент начала ноября 2010 года. Набор исходных кодов был предоставлен мне одним из разработчиков, но вы также можете скачать исходный код с официального сайта. Этот разработчик, кстати, присутствует здесь — gorthauer87.

У компилятора и сторонних инструментов статического анализа кода есть общая задача — выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.

В качестве испытуемого на этот раз выступит проект Notepad++ версии 5.8.2.

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

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

Совсем недавно cppcheck помог найти уязвимость в проекте Xorg, которая существовала там почти 23 года! Он помог уже тысячам программистов по всему миру, на официальном сайте можно найти информацию о найденных с помощью cppcheck уязвимостях в программах, и этот список постоянно растёт. Итак, если вы хотите знать, почему нужно использовать cppcheck всегда и везде — прошу под кат.

Многие программисты очень любят обвинять компилятор в различных ошибках. Поговорим немного об этом.

Захотелось написать несколько небольших заметок о том, как программисты на Си/Си++ играют с огнем, не подозревая об этом. Первая заметка будет про попытки явно вызвать конструктор.

1. История первая: воспоминание

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

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

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

Хотел бы начать перевод с маленького опроса. Вопрос к .NET разработчикам пишущим на языке программирования C#.

Опрос в конце перевода.

Сегодня я смотрел внутренний список разработчиков языка C#. Один из вопросов был о поведении выражения «x += x++», а именно, каким должно быть правильное поведение. Я думаю этот вопрос более чем интересный, поэтому решил посвятить ему запись в своем блоге. Но для начала, НИКОГДА НЕ ПИШИТЕ ТАКОЙ КОД.

ОК, мы можем начать…

Можно ли прочесть «программу на лето» за неделю и изучить рекомендованную литературу к экзамену за одну ночь? Разбираемся в вопросе, который всегда был актуален для студентов.

Зачастую необходимо выбрать среди множества альтернатив, при этом каждая обладает различными преимуществами. И как же выбрать лучшую, имея мнение десятков, а то и сотен экспертов?

Недавно в СМИ разошёлся интересный факт: при общении с репортёром Wired сотрудник Facebook попросил отключить смартфон, чтобы соцсети было сложнее зафиксировать факт их общения. Для этого в Facebook могли бы использовать спутниковую навигацию или микрофон, хотя для предотвращения слежки достаточно было бы их отключить. Вероятно, в телефоне есть что-то ещё, чего стоит бояться. Современный смартфон напичкан сенсорами: 2-3 камеры, датчик освещённости, акселерометр, гироскоп, GPS и ГЛОНАСС, магнитометр и другие. Как исследователи из НАСА, использующие для удалённого ремонта космических аппаратов датчики не по назначению, злоумышленники могут много узнать о владельце смартфона, получив доступ к одному или нескольким сенсорам. Речь идёт не о случаях физического взлома гаджетов с помощью установки чипов или добавления проволоки, а о решении сенсорами таких задач, как слежка за пользователями, прослушка или получение пинкода.


Иллюстрация к приложению PlaceRaider, создающему 3D-модель помещения из сделанных без ведома пользователя кадров

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

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

image: эволюция

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

Он, имея сложность не более O(n log n), ускоряется в случае сортировки частично упорядоченных данных и имеет сложность O(n), если данные изначально отсортированны. Но это не единственный алгоритм с такими заявленными свойствами. Существует еще как минимум два более-менее известных метода с похожей сложностью — это Smoothsort и сортировка Шелла.

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

Так сложилось, что последние полгода я активно занимался тестами производительности и мне кажется, что в этой области IT царит абсолютное непонимание происходящего. В наше время, когда рост вычислительных мощностей снизился (vertical scalability), а объем задач растет с прежней скоростью, проблема производительности становится всё острее. Но прежде, чем броситься на борьбу с производительностью, необходимо получить количественную характеристику.

Краткое содержание статьи:

• Простейший тест: способы измерения теста, выбор статистики (квантили, медиана, среднее).
• Параметризованный тест: оценка сложности алгоритма, применения МНК к оценки линейности теста.
• Тесты на многоядерных машинах: сложность экстраполяции результатов тестов на многоядерные машины, закон Амдала и целесообразность измерений.
• Поведенческий тест: каким, при заданной модели поведения пользователей, будет время ожидание запроса и что может привести к коллапсу системы. Пропускная способность (throughput) и как его считать.
• Удивительное статическое распределение результатов performance теста.

Хватит менять размер окна браузера, хватит его насиловать! Готов спорить, вы не раз слышали это. Хорошо, возможно и не слышали. Но если вы профессионально занимаетесь разработкой адаптивных сайтов, вы понимаете о чем я: любое изменение DOM или правка CSS, и вы снова начинаете тянуть край браузера вперед, назад, тестируя изменения и просматривая ничего ли не сломалось.

Целью ваших движений является имитация экранов различных устройств.

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

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

Для тестирования я выбрал реально адаптивный сайт PajamasOnYourFeet.com, сайт построено на основе HTML5 шаблона, бесплатно предоставленным EGrappler.

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

Как с мусором поступают в Японии, США и других странах? Насколько эффективны мусоросжигающие заводы? Как дать вторую жизнь пластиковым бутылкам, алюминиевым банкам и картону? Как много мусора перерабатывают в России?


Кадр из фильма «Валл-И»