Искал информацию по алгоритмам оценки стойкости паролей, нашел на Хабре топик со ссылкой на Microsoft Password Checker. Как оказалось, проверка стойкости производится с помощью небольшого JS-скрипта, поэтому появилось желание подробно задокументировать алгоритм проверки. Кому-то может быть нужно прояснить, почему делается тот или иной вывод, а кому-то — улучшить алгоритм.

Статья написана для тех, кто уже хоть немного знаком с архитектурой Zend Framework. Если кому-нибудь будет интересно — опишу работу с формами более подробно в отдельной статье.

Для загрузки файлов на сервер с помощью форм в Zend Framework Form есть элемент Zend_Form_Element_File. У него есть фильтр «Rename», который позволяет переименовать закачаный файл. Но есть минус — мы не можем просто указать новое имя для файла, чтобы сохранилось его расширение. Как это сделать? А как быть, если мы используем setMultiFile?

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

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

• создать паука, выполняющего GET запросы,
• извлекать данные из HTML документа,
• обрабатывать и экспортировать данные.

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

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

Всем привет. Сегодня я хотел бы ещё раз поговорить о замечательном deploy-ере Capistrano.

Напомню, что Capistrano — это Open Source-ный инструмент для выполнения скриптов на нескольких серверах, который в основном используется для web приложений. Он позволяет автоматизировать процесс развертывания новой версии на одном или нескольких web серверах и включает поддержку таких задач, как например изменение базы данных.

Capistrano написан на Ruby и является «модулем» (или компонентном, не знаю как лучше) фреймворка Ruby on Rails.

Данный топик по большей части является переводом туториала со страницы проекта на github-е с некоторыми дополнениями, изменениями и сокращениями специфичными для php (или для «не RoR»). Здесь не будут рассматриваться вопросы работы с несколькими серверами и базой данных, это всего лишь небольшое пособие для начинающих.

Итак, допустим на нашем локальном компьютере в паке /path/deploy/from находится приложение написанное на языке php. У этого приложения есть git репозиторий находящийся по адресу example.net/project.git с актуальным кодом. Также у нас есть хостинг по адресу example.com с ssh доступом и папкой /path/deploy/to куда мы собираемся залить наши файлы. Мы не хотим постоянно возиться с ftp клиентом и решили потратить несколько часов для того, чтобы разобраться в деплойере capistrano. Давайте приступим.

Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.

Суть CI заключается в постоянной (например, после каждого commit'а) сборке и тестировании разрабатываемого ПО в максимально приближенной к боевой среде с целью как можно более раннего обнаружения ошибок и оповещения о них разработчиков. Сама идея CI принадлежит Martin Fowler, подробно описавшему её в своей статье.

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

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

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



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

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.

Что такое OAuth 2.0

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

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

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

Как часто бывает, зацепив одну, на первый взгляд, маленькую тему, с желанием быстро все узнать и все настроить, приходится закапываться в дремучие дебри и читать не одну статью и/или мануал. Так и получилось у меня в этот раз. Изначально было желание просто узнать, как обновлять порты (или исходные тексты портов) чтоб при желании, устанавливать не устаревшее ПО, но пришлось закопаться немного по глубже.
Эта статья предназначена только для новичков во FreeBSD, опытные профи тут вообще ни чего нового, думаю, для себя не найдут. По этому, если вы на «ты» с этой системой, можете смело пропускать дальнейший текст.
Информации на эту тему хватает, но из 6-10 заметок и статей я взял, так скажем, лучшие наработки и опыт, и записал их в одну, с ссылками на более полные статьи, так что при желании можно получить более подробную информацию по каждому пункту.
Содержание статьи:
1) Выбор ПО для обновления исходных текстов.
2) Процесс обновления исходных текстов системы и портов.
3) Обновление системы(ядро и мир).
4) Обновление портов при помощи pkg_*, portupgrade, portdowngrade.
5) Заключение
6) Дополнительная литература.

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

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

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

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

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

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

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

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

SEO под DDoS-ом

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

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

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

Транспортная задача (классическая) — задача об оптимальном плане перевозок товара со складов в пункты потребления на транспортных средствах.

Для классической транспортной задачи выделяют два типа задач: критерий стоимости (достижение минимума затрат на перевозку) или расстояний и критерий времени (затрачивается минимум времени на перевозку).

Под катом очень-очень много текста, т.к. рассказывается один из вариантов решения данной задачи «в картинках» для тех, кто мало знаком с графами. Листинг прилагается.

Прелюдия

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

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

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

Cегодня мы поговорим о компонентах для высокопроизводительной и масштабируемой архитектуре на основе сервера memcached, а именно — распределённой базе для хранения данных MemcacheDB и системы очередей сообщений MemcacheQ.



Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.