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

Как правило, настроенный должным образом сервер 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

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

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

Под катом я расскажу как мы тестируем мобильные приложения.

Когда проект маленький, особых проблем с ним не возникает. Список задач можно вести в текстовом файле (TODO), систему контроля версий, по большому счёту, можно и не использовать, для раскладки файлов на живой сервер их можно просто скопировать (cp/scp/rsync) в нужную директорию, а ошибки всегда можно посмотреть в лог-файле. Глупо было бы, например, для простенького сервиса с двумя скриптами и тремя посетителями в день поднимать полноценную систему управления конфигурациями серверов.

С ростом проекта требования растут. Становится неудобно держать в TODO-файле несколько десятков задач и багов: хочется приоритетов, комментариев, ссылок. Появляется необходимость в системе контроля версий, специальных скриптах/систем для раскладки кода на сервер, системе мониторинга. Ситуация усугубляется, когда над проектом работает несколько человек, а уж когда проект разрастается до нескольких серверов, появляется полноценная инфраструктура («комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы», Wikipedia).

На примере нашего сервиса "Календарь Mail.ru" я хочу рассказать о типичной инфраструктуре и жизненном цикле разработки среднего по размерам веб-проекта в крупной интернет-компании.

Здравствуйте! Моя основная область деятельности — разработка мобильных приложений (iOS, Android). И большая часть приложений, использует взаимодействие с другими пользователями, хранение данных и другие задачи требующие наличие единого сервера. Поэтому для большей части приложений приходится писать свой велосипедbackend. А так как я, в основном являюсь мобильным разработчиком, то написание этого сервиса всегда становится небольшой проблемой — приходится задействовать веб-разработчика или искать подходящий BaaS сервис, даже если надо написать всего пару запросов.
Поэтому было принято решение, попробовать найти инструмент, позволяющий в короткие сроки написать небольшой веб-сервис, который можно было бы использовать в мобильном приложении.

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

В июле мы вместе с ведущими IT-Kompot и релиз-инженерами Badoo Владиславом Черновым и Олегом Оямяэ записали выпуск подкаста «Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение».
Так как прошлый подкаст вызвал интерес у слушателей и читателей, то этот подкаст мы тоже превратили в статью.

О чем говорили:
Процесс разработки и выкатки релизов в компании Badoo. Используемые инструменты.

• GIT Workflow. Каждая задача в отдельной ветке;
• Использование JIRA, TeamCity и AIDA;
• Формирование релиза и выкатка двух релизов в день. Проблемы и их решения (откат, патчи и т.д.).

Автоматическое тестирование. Рецепт быстрого прогона большого количества тестов.

• Что мы используем;
• Как гоняем тесты;
• Code Coverage;
• Пускалка. 18000 тестов за 3,5 минуты.

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

Вы все еще публикуете проект вручную? Тогда мы идем к вам

Под катом гайдлайн по внедрению CI для .NET проектов «с нуля», включающий:

1. Автоматические ежедневные сборки
2. Уведомления о проблемах
3. Интеграцию с баг-трекером и системой контроля версий
4. Версионирование продукта
5. Версионирование базы данных
6. Автоматизированные выкладки и бекапы

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

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

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

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

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

Рабочий процесс Гитхаба

Приветствую, хаброжители!
В этой статье я хочу поделиться опытом развертывания кластера Master-slave на СУБД PostgreSQL. Отказоустойчивость достигается с помощью возможностей pgpool-II (failover, online recovery).
pgpool — это прекрасное средство для масштабирования и распределения нагрузки между серверами и, думаю, немногие знают о возможностях автоматического создания failover на ведомом сервере при отказе ведущего и как добавить новые мощности в уже работающий кластер без отключения всего кластера.

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

Так, день за днём я насобирал небольшую коллекцию батареек, которые сильно облегчили мне жизнь. Чем и спешу поделиться:

В подборке инструменты, плагины и другие полезности, облегчающие работу с Twitter Bootstrap. Предыдущая подборка.

Инструменты

Bootstraptor — подборка большого количества бесплатных и премиум тем, в том числе Starter Kit, на основе Bootstrap.

Многие пользователи СУБД PostgreSQL знают, что сервер во время своей работы собирает разнообразную статистику, но не все знают, что ее полезно анализировать и как ее извлекать для этого. В этом небольшом тулките собраны несколько полезных запросов, дающих некоторое представление о том, как использовать это «скрытое знание», которое постоянно копится. Эти запросы можно использовать для мониторинга состояния PostgreSQL (ручного или с помощью плагинов для систем мониторинга вроде Nagios, Cacti или Zabbix), для поиска узких мест в работе сервера и многих других подобных задач. Помните, что это лишь верхушка айсберга; в документации можно найти описания нескольких десятков системных представлений, которые также могут быть полезны администратору PostgreSQL.

Впервые столкнувшись с MapReduce, я продолжительное время искал реальные примеры применения. Пресловутый поиск слов в тексте, встречающийся в каждой второй статье о MapReduce, искомым примером считать не будем. Наконец, на двух курсах по Big Data на Coursera, я нашёл не только живые примеры, но теоретическую подоплёку для более глубокого понимания происходящего. Возможность применить полученный багаж знаний не заставила себя долго ждать.

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

Это перевод 1.17 версии руководства от Rafe Kettler.

Содержание

1. Вступление
2. Конструирование и инициализация
3. Переопределение операторов на произвольных классах
   • Магические методы сравнения
   • Числовые магический методы
4. Представление своих классов
5. Контроль доступа к атрибутам
6. Создание произвольных последовательностей
7. Отражение
8. Вызываемые объекты
9. Менеджеры контекста
10. Абстрактные базовые классы
11. Построение дескрипторов
12. Копирование
13. Использование модуля pickle на своих объектах
14. Заключение
15. Приложение 1: Как вызывать магические методы
16. Приложение 2: Изменения в Питоне 3

Вступление

Что такое магические методы? Они всё в объектно-ориентированном Питоне. Это специальные методы, с помощью которых вы можете добавить в ваши классы «магию». Они всегда обрамлены двумя нижними подчеркиваниями (например, __init__ или __lt__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

Запуск нового проекта, будь то технологичный стартап, мелкий бизнес либо совместное предприятие в виде крупной корпорации — это всегда проект из разряда «пан или пропал». В соответствии с многолетней формулой, вы пишите бизнес план, расхваливаете его инвесторам, собираете команду, выводите продукт на рынок и начинаете продавать настолько интенсивно, насколько это возможно. И скорее всего где-то в этой последовательности событий вас ждет неизбежный провал. Перевес не в вашу пользу: новое исследование, проведенное Шикхаром Гошем из Гарвардской Школы Бизнеса, показывает, что 75% всех стартапов терпит неудачу.

Однако недавно появилась важная противодействующая сила, которая может сделать процесс по запуску компании менее рискованным. Данная методология называется «бережливый стартап»: в ней при разработке проекта проведение исследований превалирует над детальным планированием, обратная связь с потребителем — над интуицией, итеративная разработка — над традиционным «большим предварительным проектированием». Несмотря на то, что данной методологии всего несколько лет, ее концепции, такие как «минимальный жизнеспособный продукт» и «повороты» — pivots — быстро укоренились в мире стартапа, и бизнес-школы уже начали приспосабливать к ним свои учебные планы.

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

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

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

Моё первое знакомство с коллегой-блоггером по имени Phil Gerbyshak состоялось, когда я опубликовал весьма подробный комментарий о том, что воспринимаю энерджи-менеджмент (управление энергией) и тайм-менеджмент (управление временем) как независимые друг от друга вещи, обе из которых следует использовать полноценно. Я также дал понять, что склонен считать подход тайм-менеджмента превосходящим энерджи-менеджмент по части пиковой производительности.

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

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

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)