Preface

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

1. Систематизировать материал по данному направлению, обсудить некоторые несостыковки в терминологии
2. Полностью разобрать фундамент, на котором строятся приложения для обслуживания множество клиентов
3. Выработать стратегию для будущего приложения на python которое должно обслуживать множество клиентов
4. Создать четкую картину в голове (недаром говорят понимаешь — когда можешь объяснить)

Недавно на хабре появилось сразу два материала, посвященных языкам из «большой четверки тьюринговых трясин»: про алгоритм Маркова и Brainfuck. Думаю, для полноты картины будет интересно сравнить эти эзотерические системы с еще одним важным алгоритмическим примитивом — машиной Поста, которой я как раз занимаюсь.

Машина Поста (wiki; для простоты оттуда же взят вариант синтаксиса) похожа на всем известную машину Тьюринга, однако обладает интересными особенностями. Она содержит лишь 6 команд, кроме того, в ячейки-биты памяти могут записываться лишь 2 символа (двоичное кодирование информации). «Естественно», никакой дополнительной памяти, не зря же эзотерикой зовется!

Таким образом, при программировании на машине Поста помимо необходимости совладать с оккамовским синтаксисом надо думать о том, как записать на ленте все промежуточные результаты, не потеряв по пути обратную тропинку к остаткам входных данных. Почему «остаткам»? Зачастую ввиду отсутствия дополнительной памяти приходится обрабатывать входные данные итеративно (а иногда и рекурсивно). Надеюсь, вышеизложенное убедительно доказывает, что написание привычных алгоритмов на машине Поста — неплохая разминка для мозгов и весьма увлекательное занятие.

Добрый день. Хотелось бы поделиться с Вами очень интересным вариантом ненормального прграммирования — составлением нормальных алгоритмов Маркова. Этот вариант программирования может служить великолепным умственным отдыхом от привычных языков и сред программирования.
Студенты, которых я имею возможность учить, кричат криком, что это сложно, но только до первого собственными руками сделанного рабочего алгоритма, потом это перетекает в очень интересные алгоритмические задачки.
Собственно, к теме этого поста: наша задача написать нормальный алгоритм Маркова для деления двух целых чисел с точностью 4 знака после запятой(для задания чисел пользуемся унарной системой исчисления). Например, вход: |/||||, выход: 0.25.
При этом у нас есть только одна операция — замена одной подстроки в исходной строке на другую. Кому интересно что это такое и как это работает — добро пожаловать под кат.

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


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

Доброго времени суток, уважаемые Xабровчане!

В этой статье я хочу рассказать о том, как в С++ можно делать преобразование данных времени компиляции (типов) в данные времени выполнения (целые значения) и обратно.

Пример:

int nType = ...;
 
if( boost::is_base_of< ISettable, /* ... magically resolve type hidden by nType here ... */ >::value )
{
    // Do something
}
else
{
    // Do something else
}

Весь этот топик направлен на то, чтобы понять, что же надо написать вместо «magically resolve type hidden by nType here».

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

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

Что я подразумеваю под термином «человек-клавиатура»? Представьте себе на минуту, что вместо набора на клавиатуре или использования мыши, вам приходилось бы просить человека выполнить какую-нибудь задачу.
«Зайди в мою электронную почту».
«Покажи первое сообщение».
«Прокрути немного вниз».
«Прокрути чуть больше вниз».
«Я хочу ответить на это письмо».
Представляете себе, насколько страшное воздействие на производительность и удобство использования компьютером окажет такой интерфейс! Для такой простой задачи как «проверка e-mail» требуется 2 человека – вы и «человек-клавиатура», что повлечет за собой двойные затраты, двойные ошибки, проблемы в коммуникации между ними. Тем не менее, несмотря на глупость этого примера, похожие ситуации возникают довольно часто в бизнесе, при взаимодействии между сотрудниками, которые решают и ставят задачи друг друга.

Здесь расскажу о том, как из 5ти летнего Samsung R45 с видеокартой ATI Radeon Express 200M, у которой нет Pixel Shader 3.0, на которой современные игры либо вообще не идут, либо идут с 2 FPS на минимальных настройках, сделать достаточно мощную машину для игр и экспериментов по программированию.

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

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



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

С проблемой медленной отдачи статического контента рано или поздно сталкивается каждый сисадмин.

Проявляется это приблизительно так: иногда 3Kb картинка грузится так, как будто бы она весит 3Mb, на ровном месте начинают «залипать» (отдаваться очень медленно) css-ы и JavaScript-ы. Вы нажимаете ctrl + reload — и уже, вроде, проблемы нет, потом спустя всего несколько минут все повторяется опять.

Не всегда истинная причина «тормозов» очевидна и мы косо поглядываем то на nginx, то на хостера, то на «забитый» канал, то на «тормозной» или «глючный» браузер :)

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

В этой статье я предложу Вам свое решение этой проблемы, основанное на практическом опыте использования SSD дисков совместно с web-сервером nginx.

В этой заметке я опишу методы увеличения производительности линуксового маршрутизатора. Для меня эта тема стала актуальна, когда проходящий сетевой трафик через один линуксовый маршрутизатор стал достаточно высоким (>150 Мбит/с, > 50 Kpps). Маршрутизатор помимо роутинга еще занимается шейпированием и выступает в качестве файрволла.

Это название документа, который создан в результате исследования, заказанного Евросоюзом. Ссылку на этот документ в формате PDF я нашёл в блоге у Ивана Бегтина (того самого, который открыл п0дмену букв на российском сайте госзакупок)

Я загорелся идеей перевести этот документ на русский, чтобы было чем тыкать в лицо господам чиновникам, которые закупают тривиальное ПО на 1 млн. баксов, например. Т.е. чтобы на вопрос «о чём вообще речь?» можно было давать ссылку на этот документ.

Но, будучи человеком достаточно ленивым, сразу понял, что переводить PDF, сохраняя форматирование, будет для меня непосильной задачей. Поэтому написал в организацию, которая проводила исследование (OSOR.eu), письмо с просьбой переслать мне документ в ODT. Почему в ODT — потому что в метаданных PDF было указано, что он экспортирован из ОО.

В общем, переписка длилась порядка 2 недель, и я всё-таки добился своего. Не знаю, каким образом, но документ этот они нашли и переслали мне.

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

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

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

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

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

Программа и данные

Чтобы было понятно, на чём следует концентрироваться при оптимизации, слайд из доклада «Создание программных систем в Google и его уроки»:

День 16 ноября 2010 года навсегда войдёт в историю Creative Commons в России. В этот день по предложению вашего покорного слуги на официальном сайте Creative Commons появились русские переводы т.н. «Commons Deed» (краткого объяснения лицензий). Так как русский язык на территории бывшего СССР является lingua franca, теперь все русскоязычные люди из бывших республик могут легко понимать условия лицензий Creative Commons! Пожалуйста, обновите ссылки в ваших проектах (в Википедии ссылки уже обновлены).

• Creative Commons Attribution 3.0 Unported
• Creative Commons Attribution-ShareAlike 3.0 Unported
• Creative Commons Attribution-NoDerivs 3.0 Unported
• Creative Commons Attribution-NonCommercial 3.0 Unported
• Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
• Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
• CC0 (CCZero)
• Public Domain Mark
• Copyright-Only Dedication* (based on United States law)
  or Public Domain Certification

Белорусские переводы также доступны.

Стандарт OSSIRIUS SCS 702 задаёт порядок применения компактных настенных шкафчиков при построении структурированных кабельных систем коммерческих зданий, оптимизирован под задачи обслуживания объектов до 130 000 кв.м. (при охвате в 368 метров) и до 1000 пользователей, что определяет набор правил, решений и технологий, вошедших в него. При этом максимальное число пользователей ограничивается 50 000.

Стандарт OSSIRIUS SCS 702 является открытым и независимым. Положения стандарта формируются и изменяются исключительно в ходе публичных обсуждений в пределах, заданных положениями международных стандартов ИСО/МЭК 11801, ANSI/TIA/EIA-568B и российским стандартом ГОСТ Р 53246-2008.

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

Навигация по основам Linux от основателя Gentoo:

Часть I

1. BASH: основы навигации (вступление)
2. Управление файлами и директориями
3. Ссылки, а также удаление файлов и директорий
4. Glob-подстановки (итоги и ссылки)

Часть II

1. Регулярные выражения (вступление)
2. Назначения папок, поиск файлов
3. Управление процессами
4. Обработка текста и перенаправления
5. Модули ядра (итоги и ссылки)

Часть III: 1, 2, 3, 4

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

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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