• Как реализовать принцип единственной обязанности?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Это хороший вопрос.

    Начнем с того, что согласно принципу единственной обязанности в контроллере никакого добавления в БД быть не должно.
    Контроллер, вообще, это самая ничтожная часть веб-приложения. Его задача - получить данные из НТТР запроса и передать их в модель и потом передать ответ браузеру. Тупо "подай-принеси".
    А вот модель уже и должна записывать в базу, проверять валидность данных и совершать все прочие телодвижения.

    чтобы сформировать абстракцию, надо знать задачу не на уровне огрызка туманной фразы, "ряд дополнительных методов и запросов, нужных для формирования фильтров в магазине". Что за запросы? При чем здесь фильтры вообще? Как реализован интерфейс с БД - это ОРМ, прямая работа с БД, что-то ещё?

    Судя по информации из комментов, тут пригодится хелпер сервис. Отдельный класс, который реализует добавление товара.

    То есть контроллер дергает валидатор и смотрит ответ.
    Если есть ошибка валидации, то показывает форму обратно
    Если ошибок нет - дергает сервис на добавление товара и потом редиректит куда-нибудь

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

    В принципе, валидацию тоже можно в сервис, но тогда надо продумать обратную коммуникацию с контроллером.

    Самое главное что тут надо понимать - что Модель - это не интерфейс по взаимодействию с одного класса с одной таблицей в БД (как это до сих пор считается большинством), а вся совокупность логики - классов и модулей - реализующих бизнес-логику приложения. То есть, в модель входят и мапперы, и сервисы, и репозитории и все что угодно - кроме интерфейсов взаимодействия с внешним миром, таких как контроллеры.
    Ответ написан
    7 комментариев
  • Как лучше организовать рабочее окружение для веб разработчика?

    @xfg
    linux + docker + git вот и всё окружение.
    Ответ написан
    Комментировать
  • Какие сборщики проектов сейчас используют?

    if(куча скриптов) use(webpack);
    else use(gulp);

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

    anton_lazarev
    @anton_lazarev
    webpack
    Ответ написан
    Комментировать
  • Javascript фреймворки - дань моде или быстрота и удобство?

    @devunion
    И я вставлю 5 копеек о пользе Vue. Несколько лет назад начинал изучать Angular. Пришел к выводу, что есть идеи интересные, но как-то все сделано через одно место. Плюнул. Продолжал использовать jQuery (надеюсь, что необходимость использования jQuery или подобных библиотек вопросов не вызывает. Оптимизировать производительность можно долго и эффективно уже потом, когда это реально понадобится. В большинстве случаев до оптимизации дело вообще не доходит). Потом посмотрел Vue. Понравилось. Стал использовать в различных проектах. Раньше начинал делать простые проекты на jQuery т.к. необходимости тащить фреймворк вроде бы как и нет. В дальнейшем оказывалось, что при развитии проекта jQuery уже не удовлетворял всем потребностям. Переписывал на Vue. Наверное, в будущем буду сразу все писать на Vue и не заморачиваться.

    Вывод: попробуйте, не пожалеете!
    Ответ написан
    Комментировать
  • Javascript фреймворки - дань моде или быстрота и удобство?

    @maxbublik
    JS фреймворки уже несколько лет - это будни фронтэнда, и это не мода, и это никуда не уйдет. Также как никуда не уйдет традиционная верстка. Они будут жить вместе. Четкую границу между веб-сайтами и веб-приложениями провести нельзя, но суть вопроса автора вопроса понятна.

    Конечно же, делать простой лендинг на чем-то типа Angular/React - это клиника. Хотя если нужны интерактивные блоки, очевидно лучше использовать Vue, чем городить что-то на jQuery. Vue как раз хорош тем, что его можно задействовать только для отдельных виджетов, а весь остальной сайт продолжай писать как тебе угодно.

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

    Короче, если вы верстаете но на JavaScript ничего сложней jQuery вы не умеете, то вы в заднице. И каждый год вы все глубже.
    Ответ написан
    Комментировать
  • Зачем использовать Vue вместе с Laravel?

    Добавили, чтобы вы jquery спагетти не использовали. Vue (как и другие js фреймворки) сокращает количество кода на клиенте и уменьшает его запутанность.

    Для примера вы создаете админку для магазина. У вас есть следующие варианты:
    1. Делать статическую страницу. На клиенте никакой логики, все вычисляет сервер. При новой покупке администратор должен будет обновить страницу.
    2. Писать динамический фронтэнд с использованием vue, angular и чего угодно остального. Бэкэнд шлет вам уведомления через вэбсокеты о новых заказах без перезагрузки страницы.
    2.1 Вы берете jquery и сначала все идет хорошо. Первые полчаса. Затем ваш код обрастает огромным количеством обработчиков событий. Если товар заканчивается на складе, его надо убрать из таблицы, затем если заказ отменяется, его надо вернуть в таблицу. Вы его вернули, но почему-то кнопка в строке с ним, вызывающая модальное окно перестала реагировать на события, потом еще что-то случилось и еще. Проблемы с jquery растут как снежный ком и вы проклинаете свое решение создать динамическую админку.
    2.2 Вы используете современный js фреймворк. Vue в этом плане хорош низким порогом изучения. Вы загружаете определенные обхекты и в зависимости от их свойств vue сам строит таблицы (с проданными и непроданными товарами), скрывает лишние элементы (не показывать такую-то кнопку, если товар всего 1), отправляет плагинам команды на обновление при изменении объектов и следит за тем, чтобы события, которые отваливались при jquery подходе работали.

    Я не сказать что спец в javascript, но (именно поэтому) меня vuejs на текущем проекте очень выручает.
    Ответ написан
    Комментировать
  • Насколько у меня правильный код ООП php?

    @D3lphi
    Здесь плохо всё, к сожалению.

    Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

    Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

    Вы каждый раз повторяете строки с подготовкой запроса, биндингом параметров, отправкой запроса и тд. Не думали, что неплохо бы было написать какую-нибудь обертку и выполнять запросы как-нибудь так:
    $result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

    ?

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

    Зачем вы используете свойства, если можно обойтись обычными локальными переменными:
    $this->orderID = (int) strip_tags($orderID);
    $this->column = (string) strip_tags($column);
    $this->value = (string) strip_tags($value);

    ?

    Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
    strip_tags($orderID);
    ?

    Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:
    if (!is_string($arg)) {
        throw new InvalidArgumentTypeException('string', $arg);
    }

    Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

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

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

    Желаю успехов!
    Ответ написан
    1 комментарий
  • Что делать веб разработчику, если уже всё придумано?

    AgentProvocateur
    @AgentProvocateur
    Правильно заметили, что есть люди-исполнители, а есть люди-генераторы идей. Нужно реально взглянуть на себя и...принять это. Быть профессиональным исполнителем гораздо кошернее, чем быть генератором провальных идей. По статистике, 9 из 10 стартапов провальны...зачем пополнять собой этот список? Если ты - рыба, то многого ли ты добьешься от фрустрации по поводу неумения залезать на дерево?

    Самый верный путь к рабочей идее:
    1. Проработать в какой-либо сфере достаточное количество времени;
    2. Познать её изнутри на собственной шкуре;
    3. Выявить в ней боли/проблемы/недостатки;
    4. Решить их с помощью прикладного навыка (программирования);
    5. Обкатать в собственной работе;
    6. Упаковать решение и реализовать коллегам по сфере;
    ...
    7. PROFIT!

    Далее...даже если завтра в голову залетит рабочая идея, готов ли ты её реализовать? У тебя есть команда, готовая работать минимум полгода-год бесплатно на время создания беты, тестов, обкатки, раскрутки? Она сможет действительно реализовать всё как надо? Если нет команды, имеются ли у тебя средства на зарплатный фонд хотя бы для 5 человек на эти полгода-год? А с учетом налогов и отчислений (+30% к зарплате на руки)? У тебя есть условия для работы этих 5 человек? Есть ли у тебя сумма на маркетинговое исследование твоей идеи (или лучше облажаться на авось)? Есть ли у тебя хотя бы миллион на первичный трафик из директа? Или надеешься донести свой стартап до пользователей путём емэйл-спама?)) Я не указал и доли того, что потребуется для реализации небольшого web-сервиса, даже при наличии действительно рабочей идеи. Может быть, идеи не прут именно потому, что ты просто не готов к их реализации, и неча порожняка гонять?)

    Как выглядит стартап глазами романтичного юноши, начитавшегося глянцевых историй успеха:
    1. Придумать гениальную идею;
    2. Закодить в гараже в одну харю или в паре с дружбаном;
    3. Разместить на сервере и получать от мира благодарности, признание и мешки денег.

    Как выглядит стартап на самом деле:
    1. Пахота минимум 10 лет в одном направлении/сфере;
    2. Наработка профессионализма, идей, контактов, связей, клиентской базы, понимания всех нюансов сферы;
    3. Угон базы, угон клиентов на себя, переманивание лучших коллег/сотрудников, оформление юрлица, открытие "своего дела" на рабочей идее)))

    К примеру, "икона стиля" стартаперов - Павел Дуров, он идеолог? Нет! Прикол в том, что он именно стырил рабочую идею (также, как тырят клиентскую базу у работодателя), собрал команду, создал для неё условия, привлек корешей-евреев с еврейскими ресурсами, бюджетами и влиятельной питерской крышей, и обеспечил этому всему грамотный проект-менеджмент и маркетинг. Дело в идее? Нет, дело в реализации:)

    А если серьезно, сайт - это просто промо-материал, как билборд, только интерактивный и в интернете. Языки веб-разработки - такие же инструменты, как молоток для изготовления билбордов. Веб-разработчик - нифига не носитель уникальных знаний (который просто обязан повторить успех Цукерберга, иначе не тру), и всего-лишь современный слесарь, изготавливающий технологичные интерактивные промо-материалы. А теперь представь слесаря, который завидует предпринимателям, которые заказывают у него билборды, и вскидывает руки к небу с криком "Доколе??")) Смешно? Смешнее только реплики других слесарей на тему "если нет идей, значит меняй профессию"))

    P.S. Понимаю, что вряд ли отметишь мой ответ решением, ведь тебе хочется подбадриваний вида "Не сдавайся! Ищи и обрящешь! Не опускай руки и всё получится! Вот тебе ссылочки, вот тебе инструкции!", а не режущей глаза суровой реальности. Но в некоторых случаях действительно полезно осознать своё место в пищевой цепочке - антилопа или гепард, слесарь или архитектор, промо-изготовитель или промо-заказчик и т.д. И исходя из этого уже взращивать свои амбиции, комплексы и фрустрации. Повторюсь - в стремлении стать самым крутым слесарем нет ничего постыдного, и даже в финансовом плане может оказаться куда выгоднее и стабильнее других амбициозных вариантов.
    Ответ написан
    4 комментария
  • Что делать веб разработчику, если уже всё придумано?

    dom1n1k
    @dom1n1k
    "Всё уже придумано" - это конечно ерунда.
    Если посмотреть на мир более пристально, то оказывается, что в большинстве инструментов/приложений/систем/етц есть серьезные минусы. И почти всегда можно сделать лучше.
    Ответ написан
    Комментировать
  • Что делать веб разработчику, если уже всё придумано?

    Stalker_RED
    @Stalker_RED
    Идеи приложений: https://www.reddit.com/r/AppIdeas/
    Идеи вообще: https://www.reddit.com/r/Lightbulb/
    Подобных списков десятки. Бесплатно, без СМС.
    Ответ написан
    9 комментариев
  • PhpShorm - анализатор кода сходит с ума?

    @deliro
    За 5к-строчные пхп файлы автора нужно предавать анафеме. А код сжигать дотла.
    Ответ написан
    9 комментариев
  • Как получить заказы по web scraping и какие навыки улучшить?

    @WapGeaR
    Программист
    Я бы не доверился человеку со ставкой 8$/час, попробуйте хотя бы 15
    Ответ написан
    6 комментариев
  • Какие еще действия предпринять для увеличения скорости выборки в MySQL?

    @remzalp
    Программер чего попало на чем попало
    Фрагмент запроса "a.ID IN (ннн,нн)" уже выбирает максимально быстрым методом по первичному ключу всю необходимую информацию, которая дальше дофильтровывается.

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

    Следующий вопрос - а не пора ли оптимизировать настройки сервера - кэш, память. Начиная с mysqltuner.com , заканчивая вдумчивым анализом манов и статистики использования.

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

    И еще для тестов без кэширования ребутить сервер не надо. Используйте:
    SELECT SQL_NO_CACHE a.ID FROM articles a WHERE ...
    Ответ написан
    Комментировать
  • Какой самый лучший и быстрый способ перенести базу данных на новый сервер?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Не ипите мозг ни нам и никому!
    1. Тестируете скорость канала или курьера-админа с HDD и метод в лабе.
    2. Вешаете на паблик объявление, что переезд базы через 3-4 дня и сервис будет недоступен, т.к. Вы переносите базу объёмом 30Гб целиком и ставите сервис в режим READ-ONLY в этот интервал! (это обязательно нужно писать, чтобы у людей не возникло чувства, что у вас сервис работает со сбоями!). Пишите ориентировочный срок возобновления работы: дата-время.
    3. Готовитесь как положено к этому!
    4. Ставите READ-ONLY для базы (+объяву сверху в GUI) или заглушку (если RO невозможно сделать из-за БП), что ведутся работы по переносу базы.
    И спокойно делаете ПОЛНЫЙ ДАМП и потом ВОССТАНАВЛИВАЕТЕ ЕГО на новом сервере.

    А вообще - нужно иметь чёткое разделение:
    1. структура базы (это само собой)
    2. таблицы и данные системы/приложения (публикации, доступы, админка, CMS, логи и прочее, т.е. всё, что правится владельцами сервиса или самой системой)
    3. таблицы и данные пользователей (аккаунты, комментарии и т.д.)
    Только тогда Вы сможете чётко контролировать запросы и перенести в "прозрачном" режиме данные для пользователей без остановки сервиса.
    Т.к. для переноса данных одного пользователя - нужно гораздо меньше времени.

    Да, и обратите внимание на бегемота от dimonchik2013 ! => Это главное!
    Ответ написан
    Комментировать
  • Как правильно строить работу с git?

    @aol-nnov
    это личное дело каждой команды. можно, например, git flow
    Ответ написан
    4 комментария
  • Где хранить файлы для работы?

    На работе:
    1. Создать аккаунт на bitbucket.org
    2. Создать там пустой проект
    3. Гитом клонировать его в локальную папку
    4. Скопировать в папку свои файлы
    5. Занести node_modules в gitignore-файл
    6. Сделать коммит
    7. Сделать push


    Дома:
    1. Склонировать гитом проект в локальную папку
    2. запустить npm install
    3. и работать

    P.S. Bitbucket позволяет создавать приватные git-репозитории бесплатно, в отличие от github. Поэтому выбираем его.
    Ответ написан
    6 комментариев
  • Воровство дизайна, что будет?

    serjikz
    @serjikz
    web-developer
    По собственному опыту - в интернете делается поуши копий сайтов. Страшно представить сколько копируется каждый день. Особенно видно по Landing Page для сезонных товаров всяких. Кто-то скопировал у кого-то потом у этого тоже скопировали и тд и тп, а потом поди докажи, что ты это вообще копировал, а не сам делал. Но это относительно LP.
    На счет больших и известных сайтов (скопировать хабр к примеру) - я бы не брался за такую работу если там полная копия. Почему? Это бредятина и заказчик псих, нет ни денег ни ж... поднимать не хочет чтоб своё что-то сделать, а с такими заказчиками терпеть не могу работать.
    Если с основательным количеством переделок - это уже не копия, а скажем так рерайт)) За него же не сажают в тюрьму))
    Ответ написан
    Комментировать
  • Каким должен быть контрольный список знаний для Junior PHP(2016)?

    Uwe_Boll
    @Uwe_Boll
    Я Злой и Страшный Уве Болл в Разработке знаю Толк
    где компилятор?
    7112_20.jpg
    Ответ написан
    Комментировать