Как надоели эти тематические статьи о повышении результативности, мотивации и прочей чепухе. Зачем люди их пишут? Чтобы помочь тем, кто запутался в себе? Для тех, кому тяжело сосредоточиться? Вряд-ли это так.

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

5-го декабря в рамках конференции TechCrunch в Москве пройдет Startup Battle, на которой мы приглашаем сразиться самые свежие и интересные стартапы.

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

Требования для участия в битве:

Привет всем. Основываясь на предыдущем опыте, считаю нужным сразу расставить все точи над ё. Описанная ниже методика — не мое изобретение. Однако из собственного опыта могу уверить вас, что она работает. Ровно так, как обещано.
Идея, описанная в посте, появилась давно (под катом есть история), в том виде, в каком расскажу ее я, по большей части она представлена в чудесных книгах Тони Бузана Use You Head и The Speed Reading Book (в последней много воды).

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

Написано с подачи пользователя cympak. Посвящается всем кто много читает: будь то деловые документы, художественные произведения или статьи на Хабре типа этой.

Прежде чем приступить к самому главному, прошу вас пройти тест из шести вопросов на Да/Нет.

1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
2. Медленная скорость чтения способствует лучшему пониманию текста?
3. Пропускать слова во время чтения — плохая привычка, ухудшающая понимание текста?
4. По умолчанию мы все читаем с «естественной» для нас скоростью, а следовательно, наилучшей?
5. Если вы не поняли слово или предложение, лучше перечитать его и понять?
6. Ваши глаза находятся в непрерывном движении во время чтения?
За результатами и, наконец-то, интересными штуками добро пожаловать под кат.

Здравствуй, Хабр!
Предлагаю твоему вниманию простой и в то же время эффективный метод борьбы с http DDoS. На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мбит/с (значение получено методом экстраполяции).

Способ реализация

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

Область применения

Борьба с Http DDoS на выделенном сервере или ВПС. Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.

SEO под DDoS-ом

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

Стоимость и эффективность

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

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

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

В начале

В данной статье речь пойдет о написании Ajax-приложения. Если говорить проще — то, о написании сайта – работающего без перезагрузок. Быстро, легко, доступно. В этой статье не будет рассматриваться код серверной стороны, будут только примеры, для лучшего понимания.
Меня давно интриговала тема написания сайта, в котором несколько компонентов (например, flash плееры) не перезагружаются с каждым переходом по ссылкам, а продолжают себе напевать песенки. И вот однажды, набравшись смелости — я начал думать насчет структуры такого вот приложения. Что в итоге получилось — читайте ниже.

Свершилось, ура! Теперь я имею почетный статус ZCE :)

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

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

Безусловно, мы верим в главенствующую роль контента, но, конечно, сегодня интересный контент — далеко не всё, что нужно сделать, чтобы создать успешный информационный проект. Важна аудитория проекта, причем не только её размер, но и степень вовлечённости, выражающаяся в стремлении оставлять комментарии, делиться контентом (ведь не зря нынче везде рассыпаны кнопки социальных сетей — в мире победивших социальных сетей их эффективность трудно переоценить) и даже работать в качестве авторов проекта. Чтобы обеспечить эту вовлеченность мы создаем собственные решения, которые делают «Лайфхакер» не похожим на остальные блоги. К примеру, мы создали спецпроект «Хакрадар», где собираем контент, который наши читатели публикуют в Twitter, а также недавно запустили свою собственную систему комментариев, которая помогла нам избавиться от множества «детских» болезней таких сторонних систем комментирования, как Disqus и Intense Debate (впрочем, это тема отдельного разговора).

Сейчас обычного компьютера вполне достаточно для создания качественной электронной музыки. Многие пробовали писать свою музыку, интересовались этой темой. Возникло желание поделиться своим опытом. Первая статья из серии будет на важнейшую тему — VSTi синтезаторы.

Что такое VSTi? Зачем нужны VSTi? Почему не хватит одних только семплов для создания качественной музыки?

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

Во-вторых: семплу нельзя так же просто изменять звучание как звуку синтезатора.

В-треьих: при игре с семплом при помощью миди-клавиатуры стоит учитывать возможные артефакты, такие как алиасинг, разная длительность нот.

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

Как же можно создавать свое звучание?

1. Суть оптимизации
2. Page load vs forced refresh
3. Потребуется автоматизация
4. Реализация серверной части
5. Оптимизация серверной части
6. Особенности google app engine
7. Исходный код
8. Резюме

Рассматривается пример реализации для Google App Engine / Python.

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

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

Для тех кто ни разу не использовал JMeter, рекомендую для начала почитать базовые обзоры, например, Простой нагрузочный тест с Apache JMeter. Когда я первый раз запустил данную программу, первая мысль была разобраться во всем методом «тыка», но как выяснилось это вообще нереально, и метод «тыка» неприменим к JMeter. Поэтому если хотите его использовать, то сразу открывайте мануал, поверьте, вам придется заглядывать туда очень часто, пока полностью не разберетесь, что и как. Я же здесь сейчас опишу самое очевидное и важное, а именно: как собственно создавать нагрузочные тесты. Если бы я в свое время сразу нашел подобную статью, то сэкономил бы без малого день на изучении этой софтины.

В качестве эпиграфа: "Выкиньте все из головы!" © D.Allen

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

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

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

Недавно в RSS пришла статья, которую хотел оформить переводом — So you just deleted your production database — what now?. Однако комментарии к статье, да и последний абзац заставили задуматься — а на сколько просто восстановить удаленную базу данных.
И дабы не плодить непроверенной информации — перевод перевоплотился в исследование метода восстановления информации из случайно удаленной базы MySQL.

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

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

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

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

В отличие от других протоколов передачи сообщений (XMPP STOMP или Memcache (MemcacheQ)) AMQP обладает большей гибкостью.

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный 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. Минусы оптимизации

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

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.