В этой статье я расскажу о минах, заложенных под производительность, а также об их обнаружении (желательно ещё до взрыва) и обезвреживании.

Так уж случилось, что с Oracle организация наша работает давно и плотно. Сам я познакомился с Oracle Database ещё во времена 6-ой версии и, с тех пор, какого либо дискомфорта не испытывал. Всё испортили рыночные отношения. С недавних пор, мы начали замечать, что Заказчик гораздо благосклоннее смотрит на наши проекты если в них используются бесплатные СУБД. О портации одного из таких проектов и будет мой рассказ... 

Добрый день!

Некоторое время назад меня попросили «помочь с Экселем», а потом и работа подвернулась такая, так что за последние пару месяцев я узнал много полезного, чем и хочу поделиться в догонку к недавней статье.

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

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

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

Доброго! Как и обещал здесь — напишу о своём опыте создания скрипта для программы Adobe Photoshop. Опыт этот не претендует на 100% верное руководство к действиям — просто я так сделал, и всё работает.

Тут будет не показательное программирование, а скорее некоторые шишки, из-за которых он создавался день, а не 10 минут:)

Здравствуйте, уважаемые читатели. Моя СУБД не является портом никакой из существующих СУБД на PHP (в отличие от C#-SQLITE, к примеру), а является уникальной разработкой. Основным отличием от существующих движков, вроде TxtSQL, является поддержка индексов. Если используется только PRIMARY INDEX, скорость вставки на моём ноутбуке достигает 5000/сек. Для PHP, как мне кажется, это вполне неплохо.

Я администратор доски объявлений и видимо усилия по поддержанию уникального контента (TBD – тема отдельного типика) не проходят зря т.к. я заметил нехорошую тенденцию к сграблению объявлений через RSS ленту, разбор html-страниц сайта т.е. контент серым личностям нравиться.

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

Первый и действенный метод борьбы – посмотреть в ping IP сайта, ворующего контент и заблокировать его, что помогало только первое время. Но иногда мне просто нехватало времени на выявление «воришек», да и некоторые сайты стали добавлять использование прокси-серверов.

Как настоящий программист я принялся искать автоматизированное решение и быстро нашел его. Достаточно вспомнить, что одним из важнейших различий вэб-сервера и компьютера пользователя в сети Интернет является наличие у сервера открытых портов, обслуживаемых HTTP/SMTP/POP-серверами. Т.е. если недопускать копирование контента с IP имеющих открытые наружу порты, то это будет хорошее препятствие.

Чтобы начать выявлять серых личностей и их сайты оказалось достаточно такого PHP-кода:

//$ip – это может быть $_SERVER["REMOTE_ADDR"] и $_SERVER["HTTP_X_FORWARDED_FOR"]
$fp = @fsockopen($ip, 80, $errno, $errstr, 1);
if( $fp !== FALSE )
{
//тут логируем, что данный IP имеет открытый HTTP-порт т.е. вероятно это сервер
}

Следует обратить внимание, что поле HTTP_X_FORWARDED_FOR устанавлиается в случае, если пользователь ходит через обычный прокси. Но это поле может быть и подделкой, поэтому нужно проверять IP как указанное в HTTP_X_FORWARDED_FOR, так и в REMOTE_ADDR.

Поскольку на доске объявлений происходит установка сессии для каждого посетителя, то проверка выполнялась только на 2-м хите для каждого уникального IP.

Пробный запуск скрипта на 1 сутки показал высокую эффективность – 4 сайта-грабителя были выявлены и обезврежены. Отловлено IP с открытым 80-м портов – более 2000! Поэтому для анализа IP использовался WHOIS сервис любезно предоставленный nic.ru и еще один скрипт. Ну что-же, у них защиты от автоматических сканеров нет и хорошо ;)

Теперь все, кто находятся в моем бан-листе получают текст объявления вроде «Данное объявление было незаконно скопировано с сайта xxxx, что является нарушением авторских и смежных прав. Пожалуйста, не пользуйтесь сайтами ворующими контент т.к. такие сайты могут использоваться для распространения скрытых вредоносных программ, а также могут собирать конфиденциальную информацию о вас.» ;)

Однако не стоит просто блокировать все IP имеюшие открытые наружу порты. Оказывается существуют домашние сети, где по 80-му порту открывается статистика прокси-сервиса (да, каждому гостю!), где детально перечислен список любимых сайтов этой аудитории с количеством хитов/Мб и кто сколько тянул…

Дополнительная информация:

1. Для анализа хождений через прокси-сервера следует анализировать порты – 8080, 1080, 3126.
2. Поиск дубликатов (имею премиум, личное мнение – сервис очень часто не прав) — http://www.copyscape.com/

Прошу Ваши идеи и комментарии в тред!

Ранее я уже писал об азах текстового поиска, теперь хочу продолжить и написать о том, как развиваются алгоритмы в сторону эффективности.
Итак, как Майкл Рабин и Ричард Карп разогнали алгоритм?

14 повседневных применений FFmpeg.

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

О чем топик?

В этой статье я расскажу о реализациях разного функционала (преимущественно, на веб-сервисах) для обеспечения безопасности пользователей на примере «гигантов» современной IT индустрии. Данный материал будет полезен разработчикам, архитекторам, тим-лидам и менеджерам при постановке задач схожего функционала. Реализации в статье разработаны командами профессионалов, проверены временем и сотнями миллионами пользователей (а также большим количеством хакеров), хоть и никаких гарантий, что именно данный вариант реализации — абсолютно правильный и 100% безопасный, конечно же нет. Информация основана на личном анализе этих ресурсов.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

В одном из комментариев здесь была просьба рассказать подробнее об индексах, и так как, в рунете практически нет сводных данных о поддерживаемых индексах различных СУБД, в данном обзоре я рассмотрю, какие типы индексов поддерживаются в наиболее популярных СУБД

Это продолжение статьи о использовании расширения оператора SELECT — конструкции Model. Из первой части вы уже имеете представление о предназначении и некоторых особенностях её применения, а также знакомы с половиной синтаксиса. Далее будет разобрано несколько сложных примеров, а также дан анализ области применения и производительности.

Любой разработчик, имеющий дело с генерацией отчётности из баз данных, регулярно сталкивается с построением громоздких запросов. Часто это бывает связано с ошибками проектирования БД, и, ещё чаще, со сложностями преобразования извлекаемых данных. К последним можно отнести применение итерационных методов вычисления, подсчёт промежуточных итогов по подгруппам, расчёты, в которых используются значения соседних строк выборки, сложное форматирование строк и подобные задачи. Такие преобразования часто выносятся с уровня БД на уровень сервера приложений или клиента, что сказывается на производительности и удобстве сопровождения кода. Для решения этих задач SQL СУБД Oracle предоставляет аналитические функции и оператор MODEL — о нём и пойдёт речь в этой статье.

Алгоритм возможно не новый, и не является идеалом, но, на удивление, работает. Никаких графов и корелляции.

Для начала, стоит отметить, что сравнение очень приблизительно (по крайней мере, на данном этапе), временами две совершенно разные фотографии оказываются похожими процентов на 60%, так же не учитываются жесткие модификации (повороты, инверсия, обрезка) – для этого нужно доводить и доводить. Лично для меня самым главным оказались два параметра: скорость, независимость от разрешения изображения и возможность сравнивать «изображения» прямо в базе данных.

Хочу поделиться простым, но эффективным алгоритмом определения нечетких копий документов. Есть много статей об использовании для этой цели алгоритма шинглов. Ходят слухи, что большие поисковые системы используют очень похожий алгоритм у себя. Однако, все признают, что шинглы плохо подходят для коротких (3-5 предложений) документов. А в моей задаче надо было работать именно с такими документами. В качестве решения предлагают закольцовывать текст, чтобы как бы сделать из него длинный, но мне кажется, что это не очень правильное решение, точность распознавания дублей все равно будет низкая.

Итак, описание алгоритма, который я использовал:

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

О чём речь?

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

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

В этом обзорном посте я бы хотел рассмотреть незаметные для пользователя методы защиты от ботов.

Методы защиты