Привет, коллеги!
Многие из нас занимаются настройкой рабочих серверов для веб-проектов. Я не буду рассказывать о том, как настроить Apache или Nginx: вы знаете об этом больше меня. Но один важный аспект создания frontend-серверов остается неосвещенным: это настройки подсистем безопасности. «Отключите SELinux», — вот стандартная рекомендация большинства любительских руководств. Мне кажется, что это поспешное решение, ибо процесс настройки подсистем безопасности в режиме «мягкой» политики чаще всего весьма тривиален.

Сегодня я расскажу вам о некоторых методах настройки подсистемы безопасности SELinux, применяемой в семействе операционных систем Red Hat (CentOS). В качестве примера мы настроим связку для веб-сервера Apache + mod_wsgi + Django + ZEO на CentOS версии 5.8.

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

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

Тем не менее я решил попробовать создать парсер для HTTP запроса на основе ДКА. Основная задача не просто проверить корректность HTTP запроса, а именно выделить во входной строке элементы соответствующие определенным значениям полей HTTP запроса. Автомат должен генерироваться из BNF правил (разбросанных по) RFC2616. Реализовано все на C#, автомат на выходе тоже на C#. Хотя понятно что когда автомат готов, сгенерировать его на любом языке, в любом виде не проблема.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2 и 3.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached.

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

Следующий пост будет посвящен тэгированию кэшей.

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

Мигрируйте с Maven 2 на Maven 3

Вы еще используете maven2? Странно. Одна только миграция на 3-ю версию может значительно ускорить процесс сборки. В моем проекте переход на Maven 3 дал прирост в скорости сборки на 10%. Вероятней всего за счет каких-то фиксов и оптимизаций, что были сделаны в новой версии (так как заявляют разработчики количество кода было существенно уменьшено и сильно отрефакторено). Миграция займет у Вас несколько минут и в большинстве случаев будет безболезненной. Хотя есть шанс, что некоторые конфигурационные файлы все же придется подправить.

Используем ядра и дополнительные потоки

В Maven 3 есть замечательная опция:

mvn -T 4 clean intall
mvn -T 2C clean install

В первом случае мы явно указываем, что хотим запустить процесс сборки на 4 потока. Во втором случае мы указываем, что на каждое ядро должно быть выделено по 2 потока для процесса сборки. Это одна из новых фич нового мавена — Parallel Builds. Эта фича анализирует граф зависимостей Вашего проекта
и распихивает модули по разным потокам, сборка которых может быть выполнена параллельно.
Для моего текущего проекта скорость сборки со вторым параметром (-T 2C) ускорилась на 20%. Правда тут есть один минус. Количество ресурсов, что будет потребляться для билда может значительно вырасти. В моем случае это +30% к потребляемой памяти.
Хочу сразу обратить внимание — если связанность модулей в Вашем проекте очень низкая — то
скорость сборки этой опцией можно увеличить на порядок.
Это, кстати, повод задуматься об Вашей архитектуре проекта. Ведь если билд занимает довольно много времени, то небольшой рефакторинг поможет уменьшить эту цифру. Хотя, конечно, это все очень индивидуально.
Вообще разработчики заявляют, что прирост в скорости сборки может быть 20-50%.

Вступление

Хорошо, когда твои подчиненные никогда не болеют, не умирают, всегда присутствуют на работе и выполняют твои распоряжения без предварительных приготовлений: «Вызвали — встань». Таковы, например, веб-сервисы, соблюдающие модель REST (которая, если отбросить специальную HTTP-терминологию, сводится к тому, что интерфейс сервиса фактически является интерфейсом контейнера данных).

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

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

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

Анатомия (объектная декомпозиция)

Модель конечного автомата включает следующие базовые сущности:

1. Состояние — это режим функционирования управляемой системы, отличный от других по предоставляемым возможностям. Таким образом, снапшоты кешей и буферов, варианты циклов «от забора и до обеда» и другие акциденции управляемой системы в понятие «состояния» не входят. В норме состояний должны быть считанные единицы; если счет пошел на второй десяток — скорее всего, управляемую систему следует раздробить или иерархизировать.
2. Условие — это логическое значение (true или false) на одном из «входов» системы. Суперпозиция состояний всех входов автомата однозначно определяет целевое состояние автомата. Таким образом, любой входной сигнал, значимый для состояния автомата, в конечном счете сводится к установке значения одного или нескольких условий.
3. Реакция — это отклик автомата на отличие текущего состояния от целевого. Принципиально различных видов реакции мы насчитали два с половиной: прямой переход между состояниями, маршрут и стоп-маршрут («кирпич»). Прямой переход может быть и пустой операцией (NOP) — например, в случае, если изменение входов вызвано уведомлением о завершении асинхронной операции.

На Хабре уже упоминалась данная тулза, но как-то в контексте других тем.

What is Fiddler?
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and «fiddle» with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.

To debug applications you've written in Java, .NET, or using WinHTTP, see this page.

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

Очень часто вес приложения, которое мы выкладываем на сервер достигает неприлично больших размеров из-за включения в него всех нужных зависимостей. У меня в конечном итоге приложения занимают от 20 до 50 метров. Деплой таких war-ов на удаленный сервер, на Tomcat, дело не одной минуты, а при плохой связи и вовсе становится проблематичным. Класть библиотеки в ${tomcat.home}/lib дело очень неблагодарное и зачастую опасное. Мы на фирме немного погуглили и нашли очень приятное решение на DZone. Хочу с вами поделиться…

Java характеризуется динамической загрузкой классов. Для поиска и загрузки используется механизм делегирующих classloader'ов. В Java SE окружении их количество ограничивается 2-3, но в серверах приложений оно приближается к 10 иерархическим classloader'ам. Этим объясняется большое время запуска (обычно от минуты) и деплоя приложений.

В JBoss AS 7 разработчикам удалось сильно сократить время запуска (пустой appserver запускается за 3-4 секунды на рабочей станции). Этому способствовала новая система загрузки классов в данном сервере приложений. Такой подход всё же обладает своими недостатками.

Данная статья касается механизма загрузки классов в различных окружениях, особенностях работы с JBoss AS 7, сопряжения с системой сборки Apache Maven и IDE IntelliJ IDEA.

Upd. Если вы знаете, что такое BCrypt, можете дальше не читать. Если вы используете PHP 5.5+ то можете прочитать эту статью. Ниже же я изобрел свой велосипед, рабочий, но с двумя рулями, задний запасной. Молод был, горяч.

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

• Хранить пароли в БД в открытом виде.
• Использовать обычные хэши crc32, md5, sha1
• Использовать функцию crypt()
• Использовать статическую «соль», конструкции вида md5(md5($pass))
• Использовать уникальную «соль» для каждого пользователя.

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

В этой статье будет описано архитектурное решение низкого уровня облачной платформы Hivext, а именно уровня дата центров и взаимодействия между собой серверов разного типа.
Напомним, что проект Hivext — предназначен для более эффективного использования ресурсов (временных и финансовых) при разработке “богатых” интернет приложений (Rich Internet Application) и предоставляет широкий набор готовых взаимосвязанных сервисов.
Благодаря компании IT-GRAD мы получили возможность бесплатного разворачивания дополнительной копии платформы в Питерском дата центре (ДЦ). Нам выделили виртуальный хостинг на базе VMware vSphere 4. Работать с таким хостингом можно и через веб интерфейс и через десктоп клиент, все довольно удобно.

На данный момент Hivext развернута в 3-х территориально разнесенных ДЦ: Киев (Украина), Житомир (Украина) и Санкт-Петербург (Россия). Конфигурация платформы внутри каждого ДЦ построена по определенной структуре.

Предлагаю, так сказать, заглянуть под капот нашей платформы.

Про полезность подхода TDD (разработка через тестирование, test driven development) не слышал только ленивый или глухой. Но сегодня мы не будем обсуждать всю его полезность и красоту, а также проблемы и недостатки. Сегодня мы попробуем посмотреть, как разрабатывать unit-тесты для spring приложений. Также мы немного тронем ручное управление транзакциями в unit-тестах.

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Надоело отправлять пользователям подтверждения аккаунта и сброса пароля по утере на почту?
Пользователи уходят, устав заполнять вашу форму регистрации?
Вы точно уверены, что у посетителей вашего сайта есть аккаунт на Facebook или Вконтакте?
Не хотите хранить никакие персональные данные?
Ваши пользователи устали вводить логин и пароль?
Вашим пользователям лень даже нажать на кнопку «Войти»?
Видели, как это сделано на stackoverflow и хотите так же, и даже лучше?

Ниже о том, как сделать вход на ваш сайт ненавязчивым, автоматическим, и без особых затрат.

Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.

Предположим, у вас есть большое приложение написанное на Java. Это может быть web-сервлет размещенный в контейнере или standalone-сервис. В процессе разработки (да и во время эксплуатации) возникает необходимость отслеживать процессы, протекающие в JVM: работу garbage collector, использование памяти, жизненный цикл потоков, а так же иные специфичные для вашего проекта показатели посредством MBean. Самый простой вариант — использовать профилировщик. Но увы, проблемы не случаются по расписанию, и невозможно заранее знать, когда нужно подключить профилировщик, а держать его постоянно включенным тоже не вариант. В таких случаях идеальное решение — непрерывный мониторинг. О нем и пойдет речь. Но для начала пара слов о классической профилировке.

Так много говорят о системных администраторах, разработчиках, тестировщиках… Захотелось поговорить про тех, без кого не обходится ни одна энтерпрайз-разработка. Build Manager, так-же известный как Release Engineer, остается героем в тени — мало кто о нем знает.

Сегодня все большую популярность приобретает test-driven development(TDD), техника разработки ПО, при которой сначала пишется тест на определенный функционал, а затем пишется реализация этого функционала. На практике все, конечно же, не настолько идеально, но в результате код не только написан и протестирован, но тесты как бы неявно задают требования к функционалу, а также показывают пример использования этого функционала.

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

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

Я не претендую на автора каких-либо оригинальных идей, и возможно многим все, о чем будет рассказано в статье, знакомо. Но если вам все еще интересно, то добро пожаловать под кат.