Ответы пользователя по тегу PHP
  • Где хранить IP пользователей?

    @egorinsk
    На 1 IP могут быть десятки. сотни, тысячи пользователей. Например, у Гугл есть специальный алгоритм определения числа пользователей за IP. Можете погуглить PDF.

    Но в вашем случае, это излишне сложно — хватит ограничения на 1 голос с IP.

    Хранить — сделайте таблицу вида user_ip INTEGER(...), article_id, vote. Такая таблица, в случае правильнйо расстановки индексов, работает быстро и легко кешируется в случае надобности.
    Ответ написан
    1 комментарий
  • PHP класс роутера

    @egorinsk
    Ошибка тут одна главная — дурацкие названия. Что еще за DRouter и MCA?

    Также, почему параметры module/action пишутся в request? Также, нафига делать unset локальным переменным? Думаете, счетчик ссылок без этого не обнулится? Также, неявный addcslashes надо заменять на явное экранирование спецсимволов — или заменить ограничивающие ругулярку слеши на другой символ.

    Код так себе, но в популярных фреймворках примерно такой же, так что сойдет.

    Я бы сделал индекс для ускоренного поиска роута без тупого перебора всех регулярок. Это так примитивно.

    Также, я не понимаю, откуда взялась мода делать HTTP-редиректы и ответы через выбрасывание исключений. Кто придумал это? Какому из паттернов это соответствует?
    Ответ написан
  • Какой фрэймворк учить и по каким мануалам?

    @egorinsk
    CakePHP уродливый внутри и давно устарел. Сейчас все юзают Yii. Kohana — не самостоятельный фреймворк, а улучшенная версия CI. Symphony — вроде тяжелый и оверинженеренный монстр, который включает в себя неуклюже скопированный из Java ORM.

    Есть также мнение, что лучше всего было бы вообще перейти с PHP и недофреймворков на что-то серьезное, например Java (Гугл использует Java и С++ для своих сервисов, например) или хотя бы python, если яву не осилить.
    Ответ написан
    8 комментариев
  • Замена обычных кавычек на кавычки-елочки

    @egorinsk
    Это либо нельзя, либо крайне сложно сделать 1 регуляркой. Вам надо написать парсер HTML (можно воспользоваться впрочем встроенным в PHP DOM, но использовать готовые решение — для слабаков), который будет бить входной поток на тег, содержимое аттрибута, текст между тегами, а вот уже в содержимом аттрибутов и тексте между тегами менять вид кавычек.

    Надо учесть, что в HTML кавычка также может быть представлена как §quot;
    Ответ написан
    1 комментарий
  • Подскажите PHP Template Engine

    @egorinsk
    > 1) у которого есть URL Router

    А менеджер транзакций встроенный не требуется? Тогда это все делается встроенными средствами PHP:

    if ($url == Url::URL1) {
    echo «Hello»;
    } else {
    echo «World»;
    }
    Ответ написан
    Комментировать
  • Как выбрать случайный документ

    @egorinsk
    У документов есть целочисленные последовательные id? У нас, в Mysql на PHP это решается просто: получаем max_id и min_id, генерируем 20 рандомных чисел в этом диапазоне и выбираем SELECT * FROM table WHERE id IN (20 random numbers) LIMIT 1. Работает замечательно, через индексы, без всяких извращений.
    Ответ написан
  • xdebug бесконечный trace

    @egorinsk
    Напишите, с какими опциями настроен xdebug и каким образом с ним взаимодейтвует IDE. Так трудно сказать. По идее, xdebug можно настроить так, чтобы трейс делалася только при наличии определенного параметра в query string.
    Ответ написан
    Комментировать
  • Книга по php/mysql

    @egorinsk
    Как всегда в таких случаях, рекомендую php.net/manual
    Ответ написан
  • Расскажите про лучшие практики построения простых веб приложений на PHP+JS+jQuery?

    @egorinsk
    AJAX-приложения делаются не так и давно, потому найти собранные воедино best practices не так-то просто. Многие наработки просто не выложены в паблик, а используются разработчиками для каких-то своих проектов. Потому надо проявить старание и разобраться самому.

    Сначала посмотрите на то, что делают другие. Но здесь важно не брать плохие примеры (например, монстров типа Zend Framework и ExtJS. jQueryUI, кстати тоже уродливая вещь — вы его исходники смотрели?) Посмотрите, как написан клайентсайд у вконтакта. Посмотрите у фейсбука (хотя там код пожат, но разобраться можно). Посмотрите библиотеку Zforms. Посмотрите Google Closure Library (у Гугла есть чему поучиться, особенно в плане организации кода, посмотрите обязательно).

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

    Теперь о теории. При построении более-менее сложных AJAX-приложений приходится решать примерно те же проблемы, что и на серверной части, а именно:

    — разделение кода на слабосвязанные компоненты (чтобы, меняя один из них, не ломать все остальное). Сюда входит как организация 3-звенной архитектуры (например, MVC), так и разбиение на модули, динамическая подгрузка модулей (посмотрите yepnope.js и сделайте то же, но проще). Выбор средства взаимодействия модулей — Dependency Injection или система событий (паттерн Observer). Мне больше нравится Observer.

    — организация хранилища данных — нужен какой-то модуль для получения данных с сервера с кешированием, проверкой актуальности, возможно с блокировками и нотификацией об изменениях. Посмотрите, например, как ведет себя Гугл Докс если открыть в 2 окнах 1 документ и править его. Нужна серверная половинка для приема/валидации/выдачи данных.

    — организация View: это решение вопроса о выборе шаблонов (jQuery Templates для начинающего — вполне пойдут), создание системы виджетов (чтобы например можно было вставить виджет графика в виджет формы и все работало) — я не знаю, правда, ни одной нормальной библиотеки виджетов, пишите сами.

    — роутер и контроллер — ну это элементарно пишется без всяких библиотек. Не знаете, как — посмотрите, как сделано у вконтакта.

    — повторное использование кода — копипаст недопустим.

    Также, есть проблемы специфичные именно для клиентсайда:

    — необходимость уменьшения числа запросов (неправильно: грузим диалог, обнаруживаем, что ему нужны CSS и JS файлы и грузим их) — лучше это делать одним запросом. То же про запросы к хранилищу: выбирайте все одним запросом. Несколько AJAX-запросов — это треш и ужас, особенно при пинге 100-200 мс.

    — необходимость минимизации объема и скорости работы JS-кода. Ради нее надо отказываться от тяжелых/перегруженных библиотек типа ExtJS, kendo и jQueryUI.

    — склеивание/сжатие JS файлов — элементарщина, можно склеивать хоть bash-скриптами (или make), плюс можно применить тулзы типа Google Closure Compiler. Разберитесь, как они работают.

    — необходимость создания адаптивной верстки — для этого есть библиотеки типа Modernizr, но по моему, это перегруженный монстр. Мне, например, хватает простого инлайн-скрипта, включаемого сразу после body, который ставит классы with/without-js, with-css3, with-ie, в итоге пользователи современных браузеров экономят трафик и видят rounded corners и CSS gradients, а пользователи ИЕ скачивают их в виде картинок.

    А, вот скрипт, если кому интересно: paste2.org/p/1947136

    — необходимость поддержки навигации средствами браузера — посмотрите библиотеку history.js (хотя имхо, ее тоже стоило бы урезать раза в 2-3, там много лишнего).

    Ну и для закрепления знаний нужна естественно практика.

    Напишите

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

    2) Сделайте форму редактирования/добавления данных в этот грид с валидацией.

    3) А теперь сделайте так, чтобы он работал при пропадающем интернете (то есть, вы добавляете какие-то данные, они сохраняются, выживают при закрытии браузера и отправляются, когда соединение восстанавливается)

    4) если не испытываете отрицательных эмоций по отношению к вконтакту — решите эту задачу: vk.com/page-1_42054413. Она хорошо подходит для отработки навыков разработки AJAX-приложений.

    Что касается PHP, в AJAX-приложении он просто служит бекендом и умным хранилищем данных, не более. Слепите простейший ORM, его вполне хватит.

    P.S. И никогда не повтоярйте ошибок, которые делают косолапые разработчики Хабра. Размер textarea для комментариев должен вмещать минимум 20-25 строк.
    Ответ написан
    1 комментарий
  • Проблема с производительностью сайта

    @egorinsk
    Нужно смотреть, что происходит во время запроса, в идеале отпрофайлить его, а там уже делать выводы.
    Ответ написан
  • Правильная email рассылка

    @egorinsk
    Для начала, почитать рекомендации для вебмастеров GoogleMail, Yahoo и mail.ru в разделе помощи. Сделать тестовые аккаунты для проверки получения во всех популярных сервисах почты. Настроить правильно обратный DNS для рассылающих почту серверов. Проверить IP серверов в спамхаусе. Указывать приавильный обратный адрес. Убедиться в отсутствии открытых релеев. При возможности, добавить DKIM и подобные технологии. У mail.ru есть какая-то функция специально для проверки проблем с рассылками.

    Также, необходимо рассылать почту только явно попросившим это пользователям. Предусмотреть возможность отписки в 1 клик от рассыки, возможно через List-unsubscribe.
    Ответ написан
  • Cookies в PHP, как?

    @egorinsk
    1) Изучите основы протокола HTTP, в частности что такое response headers
    2) Почитайте про output buffering

    По идее, вообще ни первая, ни вторая схемы не должны работать. Куки должны ставиться до начала любого вывода. MySQL тут не причем.
    Ответ написан
    2 комментария
  • CMS своими руками

    @egorinsk
    Автор, а что гуглить. Есть минимум 3 способа: расковырять простую Open-Source CMS (проблема: найти CMS с хорошей архитектурой и аккуратным кодом), устроиться в компанию, у которой есть своя CMS (а она есть почти у каждой студии), и наконец, написать самому правильно.

    Маны нужны не по написанию CMS, а по используемым продуктам и технологиям.

    Сначала надо определиться с задачей. Установите и попользуйтесь несколькими CMS, просто чтобы увидеть особенности их работы. (если вы не можете это сделать — вам надо изучать основы установки и настройки apache/mysql/whatever, а не CMS писать. Уходите практиковать эти навыки). Также, есть хороший сайт, где установлены демки десятков CMS и можно их посмотреть, не устанавливая.

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

    CMS обычно состоит из 2 частей — т.н. «админки» (запароленный раздел, где меняется конфигурация сайта, добавляются материалы) и публичной части сайта, которую видят пользователи.

    Если вы еще не бросили эту затею, перейдем к следующему пункту. Проектирование архитектуры и написание CMS. Чтобы хорошо писать сложную CMS, нужен опыт и понимание того, как вообще писать сложные программы. Нужно глубокое знание HTTP/HTML/CSS/JS/SQL. А именно:

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

    Что еще надо знать. Во-первых, надо иметь представление что значит MVC или 3-звенная архитектура.

    M в MVC — это Model. CMS скорее всего будет хранить данные в БД — надо знать, что такое и как пишется DBAL (гуглите: PDO), плейсхолдеры в запросах, возможно, Table Gateway, ознакомиться с тем, что такое ORM, и почему PHP-ные ORM так тормозят. Если будете делать модельки, не храните значения полей в публичных свойствах — это неудобно и нарушает инкапсуляцию. Храните их в приватном массиве $attributes.

    V is for View. Надо знать, что такое шаблонизаторы (прочтите мануал по Smarty, Django Templates, HAML и XSLT, чтобы иметь общее представление, какие они бывают). Для PHP хорошие варианты — использовать чистый PHP или XSLT, если осилите. Smarty — устаревший тормозной хлам, Twig тоже имеет недостатки. И не стоит ставить шаблонизатор, только, чтобы писать {$a} вместо [?= $a =].

    Не смешивайте логику (сложные вычисления, обращение к БД) и шаблонизацию. Лучше сделайте 2 файла: один с кодом, другой с шаблоном. В идеале, шаблонизатор получает от контроллера значения переменных и, кроме хелперов, никакого другого кода не вызывает.

    C — контроллеры. Но это самая простая часть, контроллер — это просто класс с методами типа viewAction(), editAction() и роутер, который смотрит на УРЛ и вызывает нужный контроллер. Посмотрите, как устроен Zend_Controller и Zend_Front_Contriller, и сделайте так же, но попроще. выкинув 90% функционала — он вам не понадобится.

    Нужно как-то сделать систему компонентной без сильных связей: чтобы ядро могло работать и без модулей, а добавление модуля не требовало дописывания кода в ядро. Почитайте про Dependency Injection, а также Observer (observer — это когда мы делаем функцию addEventListener()).

    Не используйте хуки, как в Друпал. Это дурной и порочный путь, взятый видимо из древных времен и программирования на Си.

    Что еще. Освоив все эти понятия, у вас в принципе не будет сложностей написать CMS, но почитайте еще мои советы по тому, как писать правильный код с исп. ООП: habrahabr.ru/qa/17158/#answer_70869

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

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

    @egorinsk
    file_put_contents(LOG_FILE_NAME, $logMessage, FILE_APPEND); — class и public static function log можете вписать сами.
    Ответ написан
    5 комментариев
  • Как выполнить mysql запрос в php не дожидаясь его окончания?

    @egorinsk
    system('nohup script.php&') — что-то вроде этого, но это раюотает только в linux и создает лишнюю фоновую задачу нагрузку на БД.
    Ответ написан
    2 комментария
  • MVC в PHP??????

    @egorinsk
    Что значит аналоги MVC? Есть модификации MVC типа MVVM или MVP (по сути, примерно то же), есть 3-tier архитектура (но вряд ли вы захотите ее делать на PHP).

    Я осваивал MVC на примере CakePHP (хотя сам фреймворк мне не нравится, он тупой, но как учебный пример годится). Просто прочтите прилагаемый к нему мануал, где приведен пример, как сделать блог с использованием подхода MVC.

    Паттерны вам пока не нужны. Все паттерны описаны в какой-то книге Мартина Фаулера (вот список: martinfowler.com/eaaCatalog/, там есть перевод на русский, но он плохой ), но, чтобы их понять, надо сначала иметь определенный опыт написания кода и разбора чужого кода. Если его у вас нет, для вас эти паттерны будут чем-то чужеродным и непонятным (много умных слов, а зачем это нужно, если можно по-простому написать).

    Если вас (вдруг) интересуют паттерны, чтобы писать более аккуратный, качественный, профессиональный и поддерживаемый код, тут лучше руководствоваться общепризнанными принципами:

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

    — KISS (делай как можно проще) — выбирай самый простой способ реализации, если есть несколько вариантов, и если это не грозит проблемами в будущем.

    — не ориентируйся и не используй фичи из PHP4. Он умер.

    — не полагайся только на HTML5/CSS3. Еще не у всех есть айпады с маками, и живы ИЕ8, ИЕ7 и ИЕ6.

    — пиши свой код, так, как будто после тебя его будет поддерживать псих-маньяк, который знает, где ты живешь. То есть, не пиши такие вещи, которые трудно/невозможно понять другому человеку. Думай о том, кто будет читать твой код. Изредка в сложных местах ставь комментарии. Не раскидывай логику выполнения действия по 10 файлам. Не делай файлы больше 500-1000 строк.

    — давай правильные названия классам, функциям, константам и переменным. Не используй транслит ($chisloPokupatelei). Не знаешь английский — вооружись Яндекс.Словарями/Гуглотранслейтом. Выбери и следуй стандарту кодирования (рекомендую Zend Coding Standard).

    — код на функциях можно легко превратить в ООП-код путем превращения функций в статические методы и объединения в классы.
    Ответ написан
    6 комментариев
  • Демон на PHP — как извне менять параметры?

    @egorinsk
    > Как можно сообщить демону, что параметры изменились и необходимо перезапустить запрос?

    Самый простой способ — демон слушает соединение и получает по нему команды.
    Ответ написан
    Комментировать
  • Авторизация, сессии (php, mysql)?

    @egorinsk
    Лучше всего вам разобраться как например сделаны сессии в том же PHP по умолчанию. Касательно вопроса (session_id хранится в куках, его можно подменить) — а вы делайте этоот session_id из 32-64 букв, знаков и цифр. Подменить-то такой ид можно, но сначала надо его подобрать, а это годы работу суперкомпьюетров.
    Ответ написан
  • Вопрос по View (PHP MVC)?

    @egorinsk
    Кто мешает вынести общие части (шапка, подвал, сайдбар) в отдельные подшаблоны и инклудить их? Или можно как в джанге, использовать наследование шаблонов, сделать базовый шаблон и расширять его понемножку. Правда. реализацию наследования придется писать самому, так как те шаблонизаторы, вроде Twig, что ее поддерживают, на мой взгляд, неоптимальны и кривоваты.

    Также, вопрос, кто запрещает для разных действий использовать (если требуется) один шаблон? Никто не запрещает.

    В любом случае, писать по 2 раза/кописпастить код — это неправильно.
    Ответ написан
    1 комментарий