Добрый день. Недавно меня заинтересовал модуль ngx_http_gzip_static_module, и я решил погонять мой домашний сервер немного с разными настройками сжатия nginx, чтобы убедится, действительно ли современные процессоры настолько быстрые, что можно ставить сжатие в 9-тку и не париться. В качестве подопытного файла выступала слитая главная страница lenta.ru – 170кб. Во время тестирования обнаружилась интересная особенность, которая изменила мои взгляды на выбор количества процессов nginx.

Думаю многие слышали о криптографии эллиптических кривых, о том
что работает она во много раз быстрее RSA и при несоизмеримо меньшей длине ключа обеспечивает несоизмеримо большую стойкость ко взлому. Если не слышали, то можно глянуть на wiki или почитать в книгах А.А. Болотова.
К сожалению, данный вид шифрования слабо распространен. Я постараюсь объяснить как им пользоваться и поможет мне в этом OpenSSL.

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

Видно, что популярным сегодня ключам RSA длиной 1024-2048 бит соответствует всего навсего 160-224битный ключ ECC (Elliptic Curve Cryptography)

Ну а чтобы понять какой RSA тормоз достаточно попробовать сгенерировать самый длинный из предложенных в таблице ключей (и пойти вздремнуть):

openssl genrsa 15360

Желающих прикоснуться к «next gen» криптографии, придуманной аж в 1985 году, прошу под кат.

Часто перед системными администраторами, как впрочем и перед множеством других околоайтишных людей, возникает необходимость в написании статей, кратких руководств и рецептов настройки оборудования и разного рода софта. В огромном числе подобного рода публикаций можно встретить упоминания о ip-адресах и доменных именах; при этом, фантазия авторов не знает границ, встречаются все виды невозможных с точки зрения двоичной арифметики адресов вроде «120.340.560.780/22» и доменов, к примеру «domen.ru», «test.net» и др.

Хочется предостеречь авторов от подобной практики, посколько это вносит сумятицу в документацию, особенно в случае правки статьи, составленной несколькими людьми, а так-же впрямую противоречит рекомендациям комитета IETF, имеющего на этот счет вполне четкие и формализованные рекомендации:

• Согласно RFC 2606 в качестве доменных имен для примеров в документации допустимо использование доменов и поддоменов: .example, example.com, example.net и example.org
• Согласно RFC 5735 в качестве «белых» ip-адресов для примеров в документации допустимо использование ip-диапазонов: 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24

Коллеги, давайте же писать документацию в соответствии с нашими собственными стандартами. Так оно, в итоге-то, лучше получается.

Сегодня речь пойдет о phpDaemon — асинхронном модульном демоне-фреймворке, который берёт на себя обработку I/O (libevent) и другие низкоуровневые задачи, присущие демонам. С его помощью легко писать правильные сетевые приложения с блэкджеком и шлюхами.
Из коробки идут сервера FastCGI, HTTP, CGI, FlashPolicy, Telnet, WebSocket (!) — да-да тот самый волшебный пендаль новый протокол от Google. И клиенты mysql, memcached, mongodb… И многое другое, полный список под катом. Работать с сетью действительно просто. Программист средней руки может написать, к примеру, IRC-бота за считанные часы.
В качестве наглядного примера я реализовал вот этот чат на phpDaemon + WebSocket + MongoDB + jQuery. Он наглядно демонстрирует преимущества этой технологии: доставка сообщений мгновенна, накладные расходы при обмене данными минимальны, высока производительность, приложение масштабируется горизонтально. Исходники этого чата (в данный момент 17 кб). Прошу заметить, чат тестировался и работает в Chrome, FF, IE6+, Iron, Safari.

Я делаю шаблоны на чистом HTML/CSS уже больше восьми лет. За это время я убедился, что различные соглашения и документирование помогают в работе. Конечно, они не спасают от периодических CSS-кошмаров. Они лишь делают их менее болезненными. Мое решение — следовать определенным принципам в написании стилей. Эти принципы образуют основание, на котором будет строиться все дальнейшее написание стилей, облегчая работу над растущим проектом.

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

Один из основных советов по безопасности — периодически менять свои пароли на разных сайтах — не является правильным с точки зрения пользователя.

Кормак Херли (Cormac Herley), один из ведущих исследователей Microsoft Research, опубликовал работу, в которой приводятся расчёты по соотношению трудозатрат и выгод от смены паролей. Оказалось, что эта процедура, в конечном счёте, не выгодна для пользователя, как и некоторые другие процедуры по безопасности, пишет NY Times.

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

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

Иногда мы бываем просто ленивыми. Особенно, когда доходит дело до написания кода. И хоть круглые скобки в вызове функции не приводят к избыточности, иногда все же они могут утомлять, особенно когда javascript-метод не нуждается в передаваемых ему аргументах. Иногда это просто надоедает.

Решил я найти для себя сервис, позволяющий хранить GPS треки путешествий и прогулок, просто рисовать на карте маршруты будущих поездок и делиться ими с друзьями. Из требований — привязка фото к маршруту, различная статистика по поездке, возможность рисовать маршруты в браузере. Обязательно — загрузка треков в формате GPX или NMEA, приятным бонусом было бы наличие приложения для iPhone.
Перебрав достаточно много подобных сервисов — решил выделить три (хорошее число, да) наиболее интересных и многофункциональных, обзор этих сервисов я и хочу представить вашему вниманию.

Я устал испытывать определённые опасения за сохранность данных на выделенном сервере, наблюдая за происходящим у хостеров последнее время… 3FN, Agava, Hosting.UA, МакХост — тенденция получается очень нехорошая.

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

Хочу поделиться с общественностью простейшей реализацией.

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

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

Шаг 1. Создаём группу-маркер и добавляем себя в неё

Создаём группу (В нашем случае группа будет называться noinet):
sudo groupadd noinet

Добавляем в неё текущего пользователя:
sudo gpasswd -a `id -un` noinet

Является ли оффлайн-BTL хорошим топливом для ускорения нового онлайн-проекта? Задавшись этим экзистенциальным вопросом, мы решили устроить эксперимент.

Дано

Наш дорогой стартап под названием GoritBilet.ru. Совсем недавно мы открыли этот интернет-сервис, призванный помочь людям скорее избавиться от горящих билетов или же, наоборот, приобрести их по приятной цене. Простая и удобная доска объявлений, генерируемая пользователями, позволяет быстро разместить информацию о своем предложении, которое тут же появляется на главной странице. В то же время, выставляя на продажу один билет в силу изменившихся планов, тот же самый пользователь может найти для себя что-то новое, начиная от приглашения в аквапарк и заканчивая раундтрипом до Гоа и обратно. Последний как раз ждет своего нового хозяина прямо сейчас, всего за 15000 рублей, искушение не из легких.

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

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

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

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

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

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

Это первая часть статьи из официального блога автора любимого всеми нами языка. Поэтому повествование ведется от лица самого Гуидо ван Россума. Вторая часть здесь.

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

Это продолжение статьи из официального блога автора любимого всеми нами языка. Поэтому повествование ведется от лица самого Гуидо ван Россума. Первая часть здесь.

Введение и обзор

Вступление.

Python сейчас является одним из самых популярных некомпилируемых языков программирования, наравне с Perl, Tcl, PHP и Ruby. Хотя он чаще всего рассматривается, как «скриптовый язык», на самом деле это вполне полноценный язык программирования, подходящий для решения большинства стандартных задач и занимающий одну ступень с Lisp или Smalltalk (впрочем, как и со многими другими). В настоящее время Python используется фактически для всего — от одноразовых простеньких скриптов до больших расширяемых веб-серверов, работающих по 24 часа семь дней в неделю. Он используется для разработки GUI-приложений и баз данных, клиент-серверных веб-приложений и тестирования. Python используется учеными, пишущими приложения под быстрейшие в мире суперкомпьютеры, и детьми, которые в первый раз учатся программировать.

Оказывается, записывать сессии работы в терминале — совсем просто. Программа script, входящая в пакет util-linux-ng может записать все ваши действия в файл. В выходном файле ( по умолчанию он называется «typescript» ) сохраняется полный лог вашей работы за терминалом, включая вывод консоли. Можно использовать его в разных целях, начиная с записи студенческих лабораторных работ и заканчивая слежением за тем, кто и что делал за вашим терминалом.

Но самое интересное — возможность последующего проигрывание этого лога в реальном времени с помощью perl-скрипта под названием scriptreplay

Существует такая возможность: в меню правой кнопки в наутилусе создать новый документ. Но не многие знают, что вместо простого пустого документа можно создавать заранее разработанные, написанные, в общем, что-то из шаблонов. Значит если Вам необходимо постоянно использовать одно и тоже, будь-то документ Word, HTML, PHP, XML да и еще Бог весть чего, милости просим:)

Все помнят недавнюю статью про занимательную капчу на сайте Школьного Портала?
Сколько радости нам приносили эти слова:


Написал на PHP компактный генератор слов, работающий по такому же принципу.