Попытайтесь повторить это сами

Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.

Минутка банальности.

yum -y install nginx

На всякий пожарный, создадим бэкап исходного конфига.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf

А теперь можно и похимичить!

В последних дистрибутивах Linux довольно много всяких полезных плюшек в папке /etc, однако мало кто ими грамотно пользуется. Здесь я расскажу про часть из них применительно к последней стабильной версии Debian, и приведу пример реализации переключения на резервный канал.
Все попытки найти банальную автопереключалку приводили к связке из 1-2 скриптов, написанным «под себя» и мало поддающимися настройке. К dhcp не был привязан ни один из них, а значит любые манипуляции на стороне провайдера требовали вмешательство в настройки. Сам писал такие в свое время, но вот теперь решил на новой системе оформить это красиво – так, как это задумывали разработчики Debian, а именно – меняем файлы конфигурации, добавляем свои скрипты и не трогаем те, что нам предоставила система.

За время моей работы, я сталкивался с широким кругом задач. Одни задачи требовали монотонной работы, другие сводились к чистому креативу.

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

Оптимизация – это, в первую очередь, поиск оптимального плана запроса. Однако, что делать в ситуации, когда стандартная конструкция языка выдает план, который очень далек от оптимального?

С такого рода проблемой я столкнулся, когда применял конструкцию UNPIVOT для преобразования столбцов в строки.

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

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1
Часть 2

Логарифмы

Если вы знаете, что такое логарифмы, то можете спокойно пропустить этот раздел. Глава предназначается тем, кто незнаком с данным понятием или пользуется им настолько редко, что уже забыл что там к чему. Логарифмы важны, поскольку они очень часто встречаются при анализе сложности. Логарифм — это операция, которая при применении её к числу делает его гораздо меньше (подобно взятию квадратного корня). Итак, первая вещь, которую вы должны запомнить: логарифм возвращает число, меньшее, чем оригинал. На рисунке справа зелёный график — линейная функция f(n) = n, красный — f(n) = sqrt(n), а наименее быстро возрастающий — f(n) = log(n). Далее: подобно тому, как взятие квадратного корня является операцией, обратной возведению в квадрат, логарифм — обратная операция возведению чего-либо в степень.

Вам часто приходится иметь дело со склонением имён пользователей на русском языке? При рассылке писем, при отображении страниц и упоминаний, при генерации рекламных объявлений? Скорее всего, приходится изворачиваться и писать все сообщения в именительном падеже — Иванов Пётр Сергеевич.

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

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

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

(Да, пост во многом пересекается с постом Распределенный аудиоплеер на Odroid U2, но чуть проще в настройке)

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

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

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

Каждый раз, когда я смотрю на диаграммы Ганта [1], меня мучает один и тот же вопрос. Как? Вот как можно быть уверенным, что ресурс А, выполнит задачу Б за 5 дней? Нет, я понимаю, что есть исторические данные, есть, не побоюсь этого слова, статистика. Но вот как можно на основе всего этого делать уверенные прогнозы? Я не понимаю.
Если для вас термины «взаимозависимость событий» и «статистические отклонения» говорят что-то не только по отдельности, но и в совокупности, то статья вас вряд ли заинтересует. А вот если эти термины, употребленные в одном контексте, не говорят вам в чем проблема диаграмм Ганта, то приглашаю под кат, где на простом примере мы это и обсудим.

Хочу просто поделиться недавно найденным сервисом для работы с регулярными выражениями. Да, это еще один сервис. Но у него есть особенность — он позволяет не только составлять регулярные выражения, но и помогает разбирать уже написанные — эдакий regexp-декомпилятор.
Сервис называется Regex101.

Благодаря кодам Рида-Соломона можно прочитать компакт-диск с множеством царапин, либо передать информацию в условиях связи с большим количеством помех. В среднем для компакт-диска избыточность кода (т.е. количество дополнительных символов, благодаря которым информацию можно восстанавливать) составляет примерно 25%. Восстановить при этом можно количество данных, равное половине избыточных. Если емкость диска 700 Мб, то, получается, теоретически можно восстановить до 87,5 Мб из 700. При этом нам не обязательно знать, какой именно символ передан с ошибкой. Также стоит отметить, что вместе с кодированием используется перемежевание, когда байты разных блоков перемешиваются в определенном порядке, что в результате позволяет читать диски с обширными повреждениями, локализированными близко друг к другу (например, глубокие царапины), так как после операции, обратной перемежеванию, обширное повреждение оборачивается единичными ошибками во множестве блоков кода, которые поддаются восстановлению.

Давайте возьмем простой пример и попробуем пройти весь путь – от кодирования до получения исходных данных на приемнике. Пусть нам нужно передать кодовое слово С, состоящее из двух чисел – 3 и 1 именно в такой последовательности, т.е. нам нужно передать вектор С=(3,1). Допустим, мы хотим исправить максимум две ошибки, не зная точно, где они могут появиться. Для этого нужно взять 2*2=4 избыточных символа. Запишем их нулями в нашем слове, т.е. С теперь равно (3,1,0,0,0,0). Далее необходимо немного разобраться с математическими особенностями.

Поля Галуа

Многие знают романтическую историю о молодом человеке, который прожил всего 20 лет и однажды ночью написал свою математическую теорию, а утром был убит на дуэли. Это Эварист Галуа. Также он несколько раз пытался поступить в университеты, однако экзаменаторы не понимали его решений, и он проваливал экзамены. Приходилось ему учиться самостоятельно. Ни Гаусс, ни Пуассон, которым он послал свои работы, также не поняли их, однако его теория отлично пригодилась в 60-х годах ХХ-го века, и активно используется в наше время как для теоретических вычислений в новых разделах математики, так и на практике.

Примечание переводчика: После публикации статьи с автором связался коммерческий директор из King.com, создателя Candy Crush Saga, и прояснил несколько моментов, после чего автор добавил пару замечаний. Добавленные абзацы отмечены курсивом.

Принудительная монетизация

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

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

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

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

Предисловие

Эта статья является продолжением предыдущей части «Пишем свой отладчик под Windows». Очень важно, чтобы Вы её прочитали и поняли. Без полного понимания того, что написано в первой части, Вы не сможете понять эту статью и оценить весь материал целиком.
Единственный момент, оставшийся неупомянутым в предыдущей статье, это то, что наш отладчик может отлаживать только машинный код. У Вас не получиться начать отладку управляемого (managed) кода. Может быть, если будет четвёртая часть статьи, я в ней также рассмотрю отладку и управляемого кода.
Я бы хотел показать Вам несколько важных аспектов отладки. Они будут включать в себя показ исходного кода и стека вызовов (callstack), установки точек останова (breakpoints), входа внутрь исполняемой функции (step into), присоединение отладчика к процессу, установка системного отладчика по умолчанию и некоторые другие.

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

В предыдущих статьях с фотографиями кристаллов микросхем (1, 2, 3) — в комментариях писали о том, что было бы неплохо разобрать простую микросхему по деталям — чтобы было понятно «что есть что» на самом низком уровне, и где там «магический дым» прячется. Я долго не мог выбрать микросхему, в схеме которой можно было бы разобраться за несколько минут — но наконец решение было найдено: ULN2003 — массив транзисторов Дарлингтона.

Несмотря на свою простоту, микросхема до сих пор широко используется и производится. ULN2003 состоит из 21 резистора, 14 транзисторов и 7 диодов. Применяют её для управления относительно мощной нагрузкой (до 50 вольт / 0.5 ампер) от ножки микроконтроллера (или других цифровых микросхем). Каноническое применение — для управления мощными 7-и сегментными светодиодными индикаторами.

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

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

Напомню цель проекта: научиться изготавливать несложные кремниевые цифровые микросхемы в «домашних» условиях. Это никоим образом не позволит конкурировать с серийным производством — помимо того, что оно на порядки более совершенное (~22нм против ~20мкм, каждый транзистор в миллион раз меньше по площади), так еще и чудовищно дешевое (этот пункт не сразу стал очевиден). Тем не менее, даже простейшие работающие микросхемы, изготовленные в домашних условиях будут иметь как минимум образовательную и конечно декоративную ценность.

Введение

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

Распечатать в порядке возрастания все несократимые дроби, знаменатель которых не превосходит заданного числа $$.

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

Такое решение верное, и задача прошла все назначенные ей тесты. Однако мой преподаватель сказал, что задачу можно решить намного красивее. Так я и познакомился с замечательной конструкцией: деревом Штерна — Броко.

В 2012 году вся общественность, более или менее причастная к информационной безопасности, пристально следила за выборами нового стандарта хеширования данных SHA-3. На хабре достаточно широко освещалось это важное событие: публиковались результаты каждого раунда конкурса (раз, два, три), приводилось описание нового стандарта, и даже объяснялось почему новый стандарт так крут.
Однако, за всем этим ажиотажем совсем незамеченным осталось другое, не менее значимое событие: 1 января 2013 года в РФ также сменился стандарт хеш-функции.
Итак, встречайте: полное описание нового стандарта и его реализация на C#. Как говорится, лучше поздно, чем никогда.