• Имеет ли смысл разбивать значения свойств товаров по разным таблицам?

    unfilled
    @unfilled
    EAV (entity-attribute-value) и быстродействие - это, в общем случае, понятия прямо противоположные. Например, вы захотите сделать выбор всех товаров со свойством "Вес" и значением свойства 500 грамм - никакие индексы вам не помогут (точнее мало помогут), при достаточно большом количестве товаров и свойств.
    В обоих случаях (всё в одной EAV-таблице, всё в EAV-таблицах по типам данных) у вас возможен мусор в базе, т.к. не будут работать никакие ограничения целостности (FK, CHECK, DEFAULT).
    Если вы всё-таки хотите работать с EAV, можно сделать таблицу Entity|Attribute|Value_str|Value_int|Value_boolean. Какой, кхм, сорт выбирать - имхо, разницы нет.
    Ответ написан
    5 комментариев
  • PSR-0 или PSR-4, и как правильно построить структуру проекта?

    delphinpro
    @delphinpro Куратор тега PHP
    frontend developer
    /path/to/project/ это путь к проекту и данный путь нигде не фигурирует, это та директория из которой запускается основной index.php

    Нет. Этот корневая директория проекта. Из нее запускается композер. В ней же обычно лежит DOCUMENT_ROOT каталог, в котором уже и находится точка входа index.php. Также здесь лежат директории vendor (для сторонних пакетов) какой нибудь application/ для ваших файлов.

    Давайте попробую объяснить на примере.

    Пусть будет такая структура, например.

    60926735302a7422195552.png

    в vendor - вам ничего самому писать не нужно. Этот папка для композера.
    public_html - в ней только index.php и все ваши css, images, js. Это папка на которую указывает DOCUMENT__ROOT в настройках домена вашего сервера. Только эти файлы доступны "по интернету".
    application - здесь все ваши самописные php файлы.
    (На остальные каталоги не обращаем внимания, в корне проекта можно располагать все что вам удобно, это не будет доступно из web)

    Под такую структуру написан подобный composer.sjon
    {
      "require": {
        "php": ">=5.5.9",
        "slim/slim": "2.*",
        "twig/twig": "~1.18",
        "slim/views": "^0.1.3",
        "robmorgan/phinx": "^0.4.4",
        "illuminate/database": "^5.1"
      },
      "minimum-stability": "stable",
      "autoload": {
        "psr-4": {
          "MyName\\MyProject\\": "application"
        }
      }
    }

    Тут вроде бы все просто. В require перечислены используемые пакеты. Поясню только autoload. Автозагрузка по стандарту PSR-4. Указано пространство имен ваших файлов и папка в которой они лежат.
    Если ваш класс MyClass лежит в папке application - то у него должно быть пространство имен \MyName\MyProject (полное имя класса получается \MyName\MyProject\MyClass). Если ваш класс MyController лежит в папке application/Mvc/Controllers, то, соответственно \MyName\MyProject\Mvc\Controllers\MyController.

    При этом вам не нужно заморачиваться и писать автозагрузчик. Просто выполните команду php composer.phar install (или php composer.phar dumpautoload для пересборки аавтозагрузчика) и подключите файл автозагрузчика в index.php
    include '../vendor/autoload.php';

    Не использовать композер не имеет смысла, т.к. это очень просто. Просто скачайте файл https://getcomposer.org/composer.phar в корень проекта и пользуйтесь (см выше).
    Ответ написан
    5 комментариев
  • PSR-0 или PSR-4, и как правильно построить структуру проекта?

    27cm
    @27cm
    TODO: Написать статус
    Первый вопрос который меня интересует это PSR-0 или PSR-4. На сколько я понял по состоянию на 21 октября 2014 года PSR-0 был помечен как устаревший.

    PSR-4 не замена PSR-0, а дополнением к нему.
    github.com/php-fig/fig-standards/blob/master/accep...


    про PSR-3 я вообще как-то не нашел русскоязычной информации, словно такого стандарта нет

    Видать, не перевели. Читайте в оригинале:
    github.com/php-fig/fig-standards/blob/master/accep...


    /path/to/project/ это путь к проекту и данный путь нигде не фигурирует, это та директория из которой запускается основной index.php

    Да, это пусть к PHP файлам проекта. Но index.php обычно выносят в отдельный каталог (например, /public), а все классы проекта хранятся, например, в /src (или /lib или ещё как угодно). В конфигурации веб-сервера запрещают отправлять запросы к любым файлам, не лежащим в /public, благодаря этому /public/index.php является единственной точкой входа для внешних запросов.


    ./vendor это папка назначение которой я не понимаю

    Это папка для сторонних библиотек, используемых в вашем проекте. Используется composer'ом. Внутрь лезть особо причин нет, composer сам решит как ему там всё разложить. Свои классы вы туда тоже не должны писать.


    в итоге честно говоря я запутался в том как правильно надо строить свои каталоги, какие папки обязательные какие нет, когда использовать src, когда lib, когда tests, почему в некоторых структурах приходится дважды указывать имя поставщика и имя пкета и т.д.

    src и lib - скажем так, синонимы. Кому как больше нравится. Главное, что внутри лежат сами PHP файлы проекта, следующие стандарту PSR-4. Лежат там только файлы, написанные авторами проекта. Поэтому нет смысла класть vendor внутрь src (или lib).
    test - каталог для тестов проекта.
    В папке vendor имя поставщика и имя проекта могут совпадать, вот они и дублируются.

    Так как вы изобретаете свой велосипед, то и структуру каталогов делайте свою, или посмотрите на популярные CMS/фреймворки, но везде будет по-разному. Joomla, WordPress, Yii, Zend Framework, Symfony.

    Я придерживаюсь такой структуры:
    /config                     Глобальные настройки проекта.
    /data                       Временные файлы. Например:
    /data/cache	            Файлы кеша.
    /data/logs	            Логи.
    /data/tmp	            Прочие временные файлы.
    /module                     Модули проекта. Например:
    /module/Backend	        
    /module/Backend/config      Настройки модуля.
    /module/Backend/src	    Файлы PHP модуля. Например:
    /module/Backend/src/Backend/Path/To/ExampleClass.php
    /module/Backend/test	    Unit-тесты модуля.
    /module/Backend/view	    Шаблоны модуля.
    /module/Frontend/...
    /public/index.php
    /public/css
    /public/font
    /public/img
    /public/js
    /vendor


    Возможно, я ошибаюсь, но самая главная ваша беда в том, что вы решили разрабатывать собственную CMS, не поработав с существующими, не выявив достоинства и недостатки их архитектур и структур каталогов.
    Ответ написан
    7 комментариев
  • Ставить ли jira на домашний сервер или на сервер который предоставляет atlassian?

    tonymadbrain
    @tonymadbrain
    doam.ru
    Домашний сервер это определенные трудности, как раз в том что все нужно будет делать руками или просить кого-нибудь (предоставляя при этом ему root доступ на свой сервер). Если у вас знаний маловато в этой области, то не советую.
    Если не секрет, jira потому что уже пользовались? Багтрекеров полно, и если уж ставить на свой сервер то я бы советовал redmine. А если в облаке, то не поленитесь и посмотрите триальные версии всех кто предоставляет такие услуги.
    Ответ написан
    6 комментариев
  • Как правильно настроить имя узла IP обратной петли в Linux?

    ifaustrue
    @ifaustrue
    Пишу интересное в теллеграмм канале @cooladmin
    Если я правильно понял вопрос, то речь про PTR запись для белого адреса. При такой реализации правильнее сделать следующее:
    1. В доменах прописать почтовым сервером какой то один узел из определённого домена
    DNS seconadrysite:
    MX mail.primarysite 10
    2. В днс для primarysite создать:
    DNS primarysite:
    A mail.primarysite X.X.X.X
    MX mail.primarysite 10
    3. У провайдера вашего интернета создать запись PTR:
    X.X.X.X mail.primarysite

    Есть так же вариант создать для каждого домена свой MX и свою запись PTR, но не все провайдеры способны это поддержать, потому и пишу "правильнее", но не "единственный возможный вариант".
    Ответ написан
    8 комментариев
  • Полноценный web сервер на ubuntu: нужны мануалы, советы и ответы на вопросы?

    kotomyava
    @kotomyava
    Системный администратор
    Не стоит вообще читать пошаговые мануалы. Надо читать документацию на конкретные программы и понимать, что делаешь и учиться...

    2. "Из коробки" работает с ключами. Настройки не требует для этого, только ключи сгенерить (man ssh-keygen)

    3. Документация и примеры есть на соответствующих сайтах, например для postfix www.postfix.org/docs.html, или apache www.apache.org/. Если вы не можете настроить соответствующие приложения используя такую информацию, вам просто не нужно в принципе этим заниматься.

    4. Если у вас там будет несколько своих сайтов, панелька вам не нужна - будет только мешать. А если вы про всякие вебмины и прочие примочки для управления именно сервером, это не нужно в принципе.

    5. У вас многое пропущено. Например, работу сервера надо мониторить. Логи надо, как минимум просматривать, но лучше анализировать. С простейшими атаками бороться автоматически, и многое другое. Подумайте 10 раз, стоит-ли вам настраивать сервер вообще, если у вас возникают вопросы даже по элементарным вещам?
    Ответ написан
    7 комментариев
  • Полноценный web сервер на ubuntu: нужны мануалы, советы и ответы на вопросы?

    dmitryrublev
    @dmitryrublev
    Веб-разработчик, зануда
    По-моему, вы усложняете себе задачу.
    Рассмотрите вариант с использованием ISPConfig, его может хватить для решения основных задач.
    Вы получите веб-интерфейс, раздельный доступ по FTP, электронную почту для доменов, и т.д.
    По поводу попадания в блеклист - не очень понял, что произошло. По электронной почте, рекомендую прописывать SPF записи в DNS.
    Ответ написан
    3 комментария
  • Какую лицензию выбрать для web-ресурса

    @CAMOKPYT
    Если продукт закрытый то продукт закрытый, собственная лицензия, пишите там все что хотите. А насчет используемых библиотек смотрите их лицензию, в вашем случае надо знать только то что лицензия позволяет вести коммерческую деятельность и позволяет не раскрывать исходники, то есть из выше названного абсолютно все.
    Ответ написан
    Комментировать
  • Как защитить открытый PHP код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Качественной защиты не будет. Если ваш продукт будет интересен кому-либо, его взломают и он рано или поздно появится на варезах разных.

    Жадность это плохо, если хотите что бы люди реально покупали - делайте продукт как SaaS с возможностью купить отдельно для установки на локали. Либо можно бросить силы на поиски нуленых версий и просить удалить раздачи.
    Ответ написан
    4 комментария
  • Как защитить открытый PHP код?

    Люди платят за качество, так что лучше бы время потратили на улучшение продукта, а не на защиту исходников, которые все равно сломают при необходимости.
    Ответ написан
  • Как защитить открытый PHP код?

    oxyberg
    @oxyberg
    Продуктовый дизайнер ВКонтакте
    Обфускация, проверка лицензии у сервера, SaaS (ну, для вас не подойдет).
    Ответ написан
    Комментировать