Я добрался до кода широко известного клиента мгновенных сообщений Miranda IM. Вместе с различными плагинами это достаточно большой проект, размер которого составляет около 950 тысяч строк кода на C и C++. И, как в любом солидном проекте с историей развития, в нем имеется немалое количество ошибок и опечаток.

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

Краткое введение

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

Статья предназначена для начинающих студентов-программистов.

Друзья!

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

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

Бэкапил историю сообщений из Skype самописной утилиткой, год назад она работала отлично, а теперь стала люто тормозить. Это неприемлемо, тк. в том числе ради скорости экспорта она и была написана, поэтому полез в профайлер. По итогам узнал всякое и получил множественные просветления. Оказывается, breakpoint на функцию в подгруженной системной DLL ставить приходится с подвывертом, а не просто по имени, но таки можно и нетяжело. Оказывается, Skype API написан местами зверски криво, отчего и тормозища. Оказывается, чужие бинарники иногда можно очень легко подхачить и подоптимизить (слава MS Research!). Оказывается, профайлер может сильно врать, а не просто слегка подбрехивать. Ключевые слова для нетерпеливых: C++, VS, CodeAnalyst, Skype COM API, MS Research, Detours, SQLite; а для всех остальных подробности под катом.

«Вы счастливчики. Мы по три месяца жили в мешках из дерюги в грязных сараях. Мы вставали в шесть утра, стирали мешки, съедали по корке чёрствого хлеба и шли работать на мельницу, по 14 часов в день, с понедельника и до воскресенья, и когда мы возвращались домой, наш папа порол нас своим ремнем»
— Летающий цирк Монти Пайтона, Четыре йоркширца


Ленивая молодёжь.

Что может быть хорошего в тяжёлой работе?

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

Сегодня на ежедневном Stand-up'е я произнёс перед командой очень проникновенную речь о том, что мы пишем софт для людей и никого не интересует, насколько красиво код будет выглядеть изнутри, если пользователю будет неудобно с ним работать.

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

И, конечно же, я сразу же вспомнил концепцию о достаточно хорошем (good enough) ПО. Итак, вот её основной постулат: мы не стремимся сделать идеально, мы не пишем как попало, мы делаем достаточно хороший продукт.

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».

            Если посадить тысячу мартышек за тысячу пишущих машинок, то за тысячу лет они напишут эмулятор терминала. — вместо эпиграфа.

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

Потом пришла в голову мысль выпилить anyterm. Для этого нужно было посмотреть, как работают терминалки. Это было очень забавно и поучительно (желающие могут изучить исходный текст PuTTY). Главной проблемой в этом изучении было то, что они много рисуют на экран. Прямо в процессе обработки ввода. Отделить специфику DC от, собственно, того, что является консолью, было сложно.

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Года так 2 назад на одном из форумов по радиоэлектронике я попросил посоветовать, какой микроконтроллер изучать — и больше всего голосов было в поддержку AVR — популярных, 8-и битных МК, под которые легко писать, программатор можно сделать одной рукой (из проводов и резисторов)… Будущее было ясным и безоблачным, пока в 2009-м году не пошли новости про новые микроконтроллеры на ядре ARM Cortex-M0, которые должны были стоить меньше 1$ (во что в принципе никто не верил) и перекрыть кислород 8-и битным микроконтроллерам.

Сейчас на дворе середина 2011 года и пришла пора посмотреть, что и по какой цене у нас можно купить, и какая получается расстановка сил (цены — из terraelectronica.ru).

Командная оболочка (консоль) — пожалуй, самый архаичный элемент Unix, который остаётся почти в неизменном виде уже тридцать лет. Мы любим его, но кому-то кажется странным сидеть у монитора с миллионами пикселей, ежедневно глядя в консольное окошко образца 70-х годов, когда вся информация на компьютерах была исключительно в текстовом виде.


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

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

scope: начинающие системные администраторы, помощники системных администраторов и т.д. Опытным администраторам, а так же тем, кто имеет вполне конкретную специализацию будет если и интересно, то бесполезно.

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

Какие бывают системные администраторы?

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

Начать статью я хотел бы с констатации того факта, что прямо за окном находится 2011 год (пруфлинк), середина апреля. Напоминаю я это в первую очередь себе, поскольку меня периодически посещают в этом сомнения. Дело в том, что как по работе, так и ради хобби я часто читаю код на С++, написанный лет 10-20 назад (но поддерживаемый и поныне) или код написанный совсем недавно, но людьми, которые учились программировать на С++ те же 20 лет назад. И вот после этого у меня и возникает ощущение, что никакого прогресса за эти годы не было, ничего не менялось и не развивалось, а по Земле до сих пор бродят мамонты.

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

Жизнь — дерьмовая штука. По крайней мере, так считают многие «взрослые» люди, с которыми мне довелось общаться. Они постоянно жалуются на свою работу, неудовлетворительные отношения и раздолбаев-детей, которые никак не хотят становиться такими, какими хотят их видеть родители. Жизнь для этих людей — это бесконечная карусель разочарований, неприятностей и несбывшихся надежд. Они встают рано утром с больной головой, заливают в рот пару литров кофе и едут на работу в состоянии, которому позавидовали бы самые отъявленные зомби. Они ненавидят свою работу и считают, что их занятия бессмысленны и никому не нужны. Но, не смотря на это, они с упорством леммингов продолжают делать эту работу, день за днём, год за годом. Они продираются сквозь собственную жизнь, надеясь, что всласть поживут потом, когда отработают 10-20-30 лет. Так вот, это всё херня. Когда вам будет пятьдесят, вы настолько устанете от такой жизни, что единственным вашим желанием будет лечь и сдохнуть. Да и здоровье будет уже не то, потому что вы слили его, занимаясь всякой ерундой, до которой вам даже не было дела. Так что, когда вы выйдете на пенсию, вы не поедете в Африку охотиться на львов, потому что солнце плохо сказывается на вашем давлении. Вы также не поедете на Северный полюс, потому что у вас артрит и холод — не лучшее для него лекарство. Южный полюс отпадает ещё и потому, что вы недолюбливаете пингвинов, что неудивительно, учитывая ваш 30-летний стаж работы сисадмином. Так что же вам остаётся? Поездки на дачу и вечера в уютной компании телевизора, вот что. Прожив 30 лет в постоянной борьбе с самим собой, у вас просто не останется сил на то, чтобы оторвать задницу от дивана.

Сообщество жизненно важно любому проекту Open Source. Активное и живое сообщество явлется сердцем проекта. Однако, писать код под свободной лицензией не достаточно для привлечения пользователей и разработчиков к построению сообщества. В этой статье рассматривается то, что позволяет выстроить успешное сообщество OpenSource.

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

Работа заключалась в распознавании CAPTCHA, используемых крупными операторами сотовой связи в формах отправки SMS, и демонстрации недостаточной эффективности применяемого ими подхода. Чтобы не задевать ничью гордость, будем называть этих операторов иносказательно: красный, жёлтый, зелёный и синий.

Я уже около 20 лет программирую на Lisp и прочитал множество сообщений Usenet и статей в блогах, написанных Lisp — разработчиками. Я часто задавал себе вопрос — А существует ли типичный Lisp — разработчик, как существуют типичные представители наций или других групп людей?

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

Очередная статья про «азы программирования на C++» меня подтолкнула к мысли, что многие программисты не понимают сути объектно-ориентированного программирования (ООП).

iptables — интерфейс к файрволу Linux (netfilter). При большом количестве правил iptables нагрузка может быть достаточно высокой и создавать проблемы. В этой заметке я постараюсь описать, что влияет на производительность iptables и как ее повысить.