Программирование на PHP бэкэнда различных сервисов. Так же работа с JavaScript, CSS, HTML, XML/XPath/XSLT, GIT, WebDriver. Парсинг сайтов, в том числе работающих только с поддержкой JavaScript.
Настройках/использование в работе nginx, php-fpm, apache, pure-ftpd, postgresql, redis.
Контакты
Местоположение
Россия, Самарская обл., Самара

Достижения

Все достижения (33)

Наибольший вклад в теги

Все теги (210)

Лучшие ответы пользователя

Все ответы (510)
  • В чем принципиальное отличие unique (constraints) от unique index?

    alekciy
    @alekciy
    Вёбных дел мастер
    Разница в том, что ограничения (сonstraints) призваны обеспечивать целостность данных, а индексы (index) — скорость доступа к данным. Это две абсолютно не связанные сущности. Причем если первое — часть SQL стандарта, то второе нет (ибо ни как не связанно с функциональностью языка, введение индексов — вынужденная мера). Разработчик сам решает, в каких случая применить эти механизмы и использование одного вовсе не требует использование другого.

    Теперь касательно уникальности (unique). В данном случае при добавлении ограничения уникальности (unique constraint) Postgresql сам навешивает на указанное поле индекс. Это просто особенность реализации в данной СУБД. Разработчики решили, что вот так оно будет работать и все тут (причем небезосновательно). В другой же схожей ситуации они решили, что разработчик сам думает, нужно ли ему использовать этих два механизма вместе, или нет. Я говорю об ограничении целостности по внешнему ключу (foreign key). В Postgresql индексы по полям с данным видом ограничения не создаются (Индексы по внешним ключам в Postgresql). А, к примеру, в MySQL создаются. Это особенность реализации в MySQL.

    Поэтому важно просто понимать, что это не связанные вещи, просто в некоторых реализациях они «сцеплены» между собой и создание некоторых видов ограничений приводит к автоматическому созданию индекса.
    Ответ написан
  • Как сайты понимают, что их посетил бот на Selenium, а не реальный юзер?

    alekciy
    @alekciy
    Вёбных дел мастер
    Вариантов много. Из простого:
    • по User-Agent
    • по IP адресу через отслеживание количества запросов с одного адреса
    • по используемым публичным прокси (многие такие сервисы явно сообщают, о себе кто они)
    • и т.д.

    Из сложного:
    • отслеживают перемещение мыши
    • ведут аналитику на о типичных поведениях пользователя и ищуют анамалии


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

    alekciy
    @alekciy
    Вёбных дел мастер
    Крайне рекомендую postfix, тем более для изучения есть очень хороший перевод на русский по данному серверу: Postfix. Подробное руководство

    Несмотря на то, что поначалу меня смущало, что он разбит на ряд независимых по сути программ (в отличие от того же exim), т.е. в top нет единого процесса «почтовый сервер», но ознакомившись с ним более детально, особенно с архитектурой пришел к выводу, что это идеальный почтовик. Поэтому лично для себя давно уже вопрос выбора почтовика не возникает.
    Ответ написан
  • Где найти софтверную компанию для разработки сложного проекта?

    alekciy
    @alekciy
    Вёбных дел мастер
    Прямо какой-то филиал фри-ланс.ру :D такие каменты я вижу обычно там.
    Ответ написан
  • В чем основные отличия mySQL от Postgre?

    alekciy
    @alekciy
    Вёбных дел мастер
    Использую обе РСУБД. Предпочитаю Postgresql, хотя конечно начинал с MySQL. Из того, что на практике приводит к такому предпочтению:
    1) Отсутствие проблем на по сути пустом месте. Из последнего было, в одной базе есть таблицы с большим количеством текстовых полей. При вставке в одно из них чуть меньше 200 символов он отказывался ссылаясь на то, что переводите на динамические. И я значит должен начать курить тему движков мускула и выяснять, что мне оказывается нужна Barracuda. При той же InnoDb. Хочется спросить такого черта.
    Или вот еще вспомнил. При попытке записи в поле данных, больше чем это возможно для данной колонки он делает запись тупо обрезав лишнее. И проблему могут не заметить очень долго вплоть до момента когда подниматься из бэкапа поздно, там все уже битое.
    Или вот взять и сменить могут дефолтные значение переменных в рамках минорной версии. База после накатки апдейтов и ребута может просто не подняться. На хабре даже была статься по этому поводу.
    В общем множество подобных ситуаций после которых так и хочется воскликнуть "какого черта?!". Со слоном я не помню ни одной такой ситуации.
    2) RETURN во вставках/обновлениях. Можно получить в ответе любое поле такого запроса. И ни каких тебе танцев с LastInsertId.
    3) В последних версиях есть UPSERT которого очень не хватало.
    4) В целом более строгий подход и нет ощущение бардака.
    5) После запуска Postgres Pro появилась полностью руссифицированная документация. Помогает вкатиться в тему новичкам.

    Из минусов некоторое время было отсутствие адекватного UI клиента. Но после того, как стал использовать PhpStorm эта проблема была закрыта.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (22)