Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

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

Некоторые примеры

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

В некоторых сферах программирования нормально хотеть написать такую структуру данных или алгоритм, которые могут работать с элементами разных типов. Например, список дженериков или алгоритм сортировки, которому нужна только функция сравнения. В разных языках предложены всевозможные способы решения этой задачи: от простого указания программистам на подходящие общие функции (С, Go) до таких мощных систем дженериков, что они стали полными по Тьюрингу (Rust, C++). В этой статье я расскажу о системах дженериков из разных языков и их реализации. Начну с решения задачи в языках без подобной системы (вроде С), а затем покажу, как постепенное добавление расширений приводит к системам из других языков.

Цель: получить минимально работающий почтовый сервер, используя только Postfix и Dovecot, с минимальным изменением настроек по умолчанию. Получить каркас системы, на основе которого можно, в дальнейшем, настраивать спам фильтры, работу с базами данных, LDAP…
Почтовая система должна:

1. Поддерживать любое количество доменов и пользователей.
2. Обслуживать пользователей, не привязанных к локальным учетным записям.
3. Обеспечивать доступ к почтовым ящикам по протоколам POP3, IMAP с поддержкой TLS.
4. Обеспечивать отправку и прием писем по протоколу SMTP с поддержкой TLS.

Настройка проводилась в CentOS 6. Postfix 2.6.6, Dovecot 2.0.9. Никакие особенности ОС не применялись.

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

Блокировки интернета в России уже есть — это данность, с которой мы живем и должны жить дальше. А раз так, нужно разбираться, как это устроено технически, что может и не может провайдер. Филипп Кулин (schors) давно начал собирать информацию по этому поводу, участвовал в нормативной работе, ходил на разные совещания. В итоге сейчас больше него о блокировках в России знает только Роскомнадзор, но это не точно. Под катом краткая сводка актуального состояния дел.


О спикере: Филипп Кулин (schors) генеральный директор ООО «Дремучий лес» — небольшого российского хостера, занимающегося в основном shared-хостингом.

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

Подавляющее большинство провайдеров используют те или иные системы анализа трафика, чтобы блокировать конкретные URL, а не IP-адрес: аппаратные комплексы DPI, открытые DPI под Linux, прозрачные прокси-серверы. Этого вполне достаточно для блокировки ссылок в HTTP, но не все системы поддерживают анализ домена (параметра SNI) в HTTPS-трафике, из-за чего провайдерам с такими системами приходится блокировать HTTPS-ссылки реестра по IP-адресу.

Также в реестре есть сайты, внесенные по домену, без указания протокола. Некоторые провайдеры блокируют такие записи по IP-адресу, другие — только HTTP и HTTPS-протокол у этих доменов. Чтобы не покупать дорогие конфигурации DPI, которые могут анализировать весь огромный поток трафика, провайдеры пропускали через DPI только известные IP-адреса заблокированных сайтов, и обходились конфигурацией дешевле.

Однажды возникла необходимость в подчинённом, в рамках имеющейся инфраструктуры центре сертификации для 'выездного' использования — создания временных технологических сертификатов во время различных разъездов. Необходимо было сделать его мобильным и разумно, для данных целей, защищённым. Приемлемым был признан вариант с загрузочной флешкой с каким-нибудь *nix + openssl и типовым сценарием использования — имеющийся под рукой компьютер перезагружаем, вставляем флешку, загружаемся с неё, работаем, вытаскиваем флешку, перезагружаем компьютер. Секретные ключи данного ЦС, его файлы конфигурации, ключевые файлы для двухфакторной аутентификации могут быть вынесены на отдельные носители.

Начался выбора дистрибутива *nix. Требования были следующие:

• дистрибутив должен быть поддерживаемым в актуальном состоянии, в том числе и OpenSSL
• наличие i386 версии. Гигабайты памяти нам не понадобятся, а вот возможность запуска на нетбуке с x86 Intel Atom будет полезна
• запуск системы из оперативной памяти, либо корректный запуск и работа с r/o разделов. В идеале, корректная работа с флешки при включенной защите от записи (при использовании Qumo серии Yin & Yan)
• возможность компактной инсталляции
• желателен достаточно большой срок поддержки релиза

В результате в финал вышли два дистрибутива — Alpine Linux и OpenBSD. Всё бы хорошо, и не было бы смысла писать эту статью, как ВНЕЗАПНО уточнились требования к операционной системе — потребовалась полная поддержка русского текста в Unicode в системной консоли. На ввод и на вывод.

Ну всё, приплыли. Оба финалиста выбыли из соревнования. Alpine Linux в силу используемой в нём компактной библиотеки C, а OpenBSD… ну, у неё другие сильные стороны. Однако это требование позволило иначе взглянуть на доступные дистрибутивы, и в фаворитах неожиданно оказалась FreeBSD. Консольный драйвер vt (ранее известный как newcons) поддерживает Unicode «из коробки», русские шрифты идут в комплекте, вышеописанные критерии в сумме исполняются достаточно полно. Бонусом можно реализовать возможность оффлайнового бинарного обновления системы на флешке.

Началось изучение возможности компактной инсталляции стандартными способами. Готовые наборы — tinybsd, nanobsd, picobsd произвели впечатление «старый, древний, ещё древнее». Одни только расчёты секторов, головок, цилиндров для разных типов флешек в picobsd… Прям времена MFM, RLL, ST-506…

Творения отдельных энтузиастов, различные miniBSD, easyBSD, mfsBSD выглядели поинтереснее, но в итоге всё равно было решено поиграть в доброго доктора Франкенштейна.

В данном примере мы сделаем загрузочную флешку с:

• компактной инсталляцией FreeBSD 10.1
• русифицированной системной консолью в Unicode
• корневым разделом, монтирующимся в памяти
• разделом для скриптов и файлов конфигурации нашего ЦС
• шифрованным разделом для секретных ключей ЦС
• FAT разделом для обмена с внешними системами запросами на сертификат и подписанными сертификатами
• возможностью оффлайнового обновления системы
• возможностью выбора ядра при загрузке (минимальное + GENERIC)
• возможностью выбора образа системы при загрузке (эталонный + обновлённый до последней версии FreeBSD)

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

Идея

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

Вывод

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

Ansible – популярный инструмент для автоматизации настройки и развертывания ИТ-инфраструктуры.

Основные задачи, которые решает Ansible:

• Управление конфигурациями. Максимально быстрая и правильная настройка серверов до описанной конфигурации.
• Провижнинг. Управление процессом развертывания новых облачных серверов (например через API, с помощью Docker или LXC).
• Развертывание. Инсталляция и обновление ваших приложений без простоя наилучшим образом.
• Оркестрация. Координация компонентов вашей инфраструктуры для выполнения развертываний. Например проверка, что веб-сервер отключен от балансировщика нагрузки, до апгрейда ПО на сервере.
• Мониторинг и уведомления.
• Логгирование. Централизованный сбор логов.

По сравнению с другими популярными инструментами автоматизации ит-инфраструктуры, Ansible не требует установки клиентских приложений на обслуживаемые сервера, что может сократить время настройки перед развертыванием инфраструктуры. Для работы Ansible подключается к обслуживаемым серверам по SSH.

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

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

Туманное болото сегодняшних игроков рынка хостинга, озаряемое иногда вспышками покупок и поглощений, междоусобиц феодалов-магистралей, плещущегося и шумящего периодически 6%-ого .masterhost и бойкая, упорная, эксцентричная, бескомпромиссная Евросеть…

Что может значить это, пока безобидное, объявление для рынка хостинга?

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

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

Что это значит для хостеров? Новый датацентр, новые возможности. Для .masterhost — крупный конкурент. Или крупнейший партнёр.

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

В-третьих, это может означать, что Евросеть будет сбывать массово дешёвые сервера. Вот это будет феерическое зрелище. Кто тут спрашивал, почему на западе так, а у нас вот этак? Это для вас.

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

Что это значит для пользователя? Много серверов вкусных и разных.

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

Остаётся пожелать Евросети удачного вхождения в этот бизнес.

Не смог пройти мимо этой рекламной войны и вставил своё веское слово:

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Статья основана на codelab с сайта Go, но не ограничивается им. По ходу прочтения статьи можно будет узнать о структурах данных Go, динамических массивах, использовании библиотек http, template, regexp для создания веб-приложения, шаблонизации и фильтрации ввода, соответственно.

Для понимания статьи необходимо немножко уметь программировать, не пугаться слов unix и веб. Основы языка будут изложены в статье.

Хочу начать с того, что мне жутко надоели презентации со стандартным лейаутом: сверху шапка с темой, потом набор пунктов, снизу футер ну и справа и/или по центру картинка может какая-то или диаграмма.

Скучно!

Где же креатиффность? Неужели не хочется не просто раскрыть свою тему, а сделать это так, чтоб даже тем, кому не интересна тема, будут заинтересованны подачей материала? Блин, мы ж веб-девелоперы, так почему же мы создаем презентации в левых программах, а не там, где мы лучше всех?

Что же я хотел сказать таким страшным заголовком?

На самом деле — все просто.

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

В этой статье я расскажу о том, как реализовать это на примере движка mediawiki.

Как показывает независимое исследование, около 67 процентов Web-разработчиков на Хабрахабре пишут свои CMS. За свою жизнь ваш покорный слуга написал около пяти-шести CMS-велосипедов, и в процессе работы была с жадностью перерыта масса информации о структуре и принципах работы других CMS, а также придумано несколько своих. Мир CMS полон разнообразных модулей, расширений, компонентов, компонент, плагинов. О том, как разработчики CMS позволяют расширять функционал, и какие термины для этого используются, я и хочу рассказать. Сразу предупреждаю, что нижеследующая информация может и запутать, поэтому термины, которые в контексте разных CMS имеют разные значения, несут в скобках номер, указывающий на то или иное значение. Некоторые принципы, изложенные здесь, могут заставить сморщиться кого-либо. В списке, в основном, перечислен функционал, расширяющий систему. Синтаксис, используемый в примерах, в большинстве случаев выдуман.
Надеюсь, список поможет с организацией принципов работы собственных CMS, подкинет идею или просто заинтересует. Те, кому скучно, могут попробовать угадать, какая именно CMS имелась в виду в каждом конкретном случае (дабы избежать холивара, названия CMS в самом списке не используются, да и в конкретных случах термины могут содержать несколько иное значение).

Достаточно регулярно на хостинге не оказывается предустановленной библиотеки для той или иной программы. И не всегда хостер удовлетворяет просьбу установить библиотеку требуемой версии. Бывает, что библиотека есть, но устаревшая. Или сломался у хостера сервер, он перекинул сайт на другой, а там более новая версия библиотеки, не совместимая с той, на которой работает программное обеспечение сайта (пользователи Django прекрасно поймут меня). Что делать? Искать опять новый хостинг? Всегда быть готовым переписать свою программу под другую версию библиотеки? Наш путь — поставить её самостоятельно. В самом крайнем случае, придётся просто переустановить её. Кроме бинарных модулей PHP почти все библиотеки для популярных веб-технологий можно поставить к себе в домашний каталог не трогая хостера и не завися от него. Кстати сказать, это можно делать не только на шаред-хостинге, но также и на виртуальных серверах — проекты становятся слабо зависящими от того, кто и как настраивал виртуальный сервер. Сложно?

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Последнее время в области веб-разработок стал набирать популярность язык программирования Python. Однако, массовому распространение Python мешает проблема эффективного запуска приложений на этом языке. Пока, в большинстве случаев, это удел выделенных или виртуальных серверов. Модульные языки в отличии от монолитного в базовой функциональности php на каждый запрос подгружают как минимум runtime-библиотеку, а как максимум — ещё несколько десятков запрашиваемых пользователем модулей. Поэтому классический подход наподобие mod_php для Python и Perl не очень уместен, а держать приложение постоянно в памяти было дороговато. Но время движется, техника стала мощнее и дешевле, и уже достаточно давно можно спокойно говорить о постоянно запущенных процессах с приложением в рамках массового хостинга.

О чём тут

Время от времени, в сети появляются различные предложения как запустить приложение на Python. Например, недавно хостинг Джино уникально поправил mod_python и предложил хостинг именно с его помощью. Следом за ним, некий хостинг Locum вообще отринул mod_python с его безопасностью (создаётся впечатление, что суть самобытная безопасность — это единственная проблема АйТи на пути к нирване) и провёл победоносное тестирование modwsgi против fastcgi. Комьюнити же, судя по проведённому мною поиску, разрывается между mod_python и FastCGI. Причём, FastCGI обычно имеется ввиду тот, что идёт в поставке Django — flup. Являясь популярным хостингом Python-приложений, мы не смогли пройти мимо и решили внести свою лепту в эту священную войну.