• Реверс-инжиниринг ОС?

    PO6OT: является. И разработка ведется с 95-ого года насколько я помню.
  • Как лучше разбить логику?

    классы мэнеджеры - это прямое нарушение SRP и запах процедурного программирования. Когда вы видите класс "UserManager" вы можете точно передать чем он занимается? Ну да, менеджит юзеров, а что это означает? И вы начинаете перечислять обязанности.

    Суть ООП сводится к тому, что у вас есть объекты, хранящие состояние, и они могут только обмениваться сообщениями. Причем чем меньше аргументов - тем лучше.

    Как упражнение - попробуйте предложить мне как сделать оформление заказа без единого класса менеджера, сеттеров, геттеров и прочего булшита? У вас есть только классы User, Product, Order и возможно OrderLine, который должен хранить некоторую информацию о продукте (хотя бы стоимость на момент оформления заказа) и количество заказанных штук.
  • Как лучше разбить логику?

    хотя потом всеравно геттеров и сеттеров наплодят... смысл тогда ООП загоняться.
  • Как лучше разбить логику?

    контроллер не должен содержать логику приложения. Это если вас интересует "как правильно". Он содержит точки входа для UI (Http как правило), то есть тупо конвертирует http запрос в вызов метода какого-то объекта (не будем называть это моделью для упрощения), и формирует http ответ на основе каких-то данных (которые тоже запрашивает у какого-то объекта а не лезет сам)
  • Как лучше разбить логику?

    имеет. Маленькими вещами проще управлять.
  • Почему термин DevOps часто упоминают в паре с термином Agile?

    Михаил:

    > докер все же - инструмент, а не модная самоцель

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

    > А если дебаг символы нужно убрать? Вы же не понесете их в прод?

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

    > А что, если нужно управлять зависимостями (которые не для сборки, а для работы)?

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

    > Поэтому его не стоит лепить где попало.

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

    > Докер отлично помогает в простых приложениях только.

    Ой ну ладно вам уже, больше похоже что вы бросаетесь в крайности. Мне как разработчику удобно работать с докером. Слил образ, поднял проект, все занимает пару минут. Если вдруг надо что-то админам подправить в инфраструктуре - пыщ пыщ и я просто сливаю новый базовый образ и продолжаю работать. Это удобно в большинстве случаев а не только в простых. Вопрос в том как вы организуете работу в команде и будет ли команде удобно. Я вполне допускаю вероятность при которой докер будет создавать больше проблем для команды.
  • Почему термин DevOps часто упоминают в паре с термином Agile?

    Михаил:

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

    2. а зачем в случае с docker паковать что-то в deb/rpm? Вот честно? Я до перехода на docker тоже в deb паковал но профита в этом по сравнению с возможностью собрать образ я не вижу.

    3. Не понял, зачем разворачивать контейнер в контейнере?

    p.s. докер не решает всех проблем, во всяком случае приведенный вами первый пункт - я сильно сомневаюсь что стоит даже пытаться это решать как-то с докером. Я думаю тут просто задача включает больше чем докер) А вот два других кейса - мне сложно тут согласится.

    p.p.s. Я использую докер не для изоляции процессов а что бы собрать образ, протестировать его и дистрибьютить между окружениями.
  • Почему термин DevOps часто упоминают в паре с термином Agile?

    Михаил: я думаю вы не сильно много потеряли. Хотя мне интересно было бы узнать контекст, а точнее ситуации в которых докер не оптимальное решение.
  • Дробное число прописью на php?

    Допустим число 0.00116 нужно преобразовать в строку


    Приведите примеры входных данных и желаемого результата.
  • Как работает CORS и JWT в Laravel?

    unfapable:

    сервер при успешном логине генерирует токен и отдает клиенту. Клиент его хранит у себя и отправляет с каждым запросом. Сервер проверяет подпись токена на каждый запрос.
  • Как работает CORS и JWT в Laravel?

    unfapable:

    > Это мне нужен запрос в API сделать, типа getMyToken

    это называется логин. То есть чувак вам должен email + password (или что вы там юзаете) прислать, что бы выдало токен.

    > написать что значит "подпись" и payload?

    jwt.io - тут наглядно что есть что и как работает. И можно потыкать.

    > При авторизации на клиенте, я не могу использовать токен этой авторизации при кроссдоменных запросов?

    почему не можете? можете спокойно.
  • Стоит ли все function собирать в одном файле?

    utyfua: еще в php до 7.1 был такой нюанс - когда у вас более 10К объектов и есть циклические ссылки - то тогда ужасно педалил сборщик мусора. Но это не только классов касается - просто ссылки в массивах так же педалить будут, просто это надо явно написать так еще.
  • Стоит ли все function собирать в одном файле?

    utyfua: что ж вы такое делали что в классы уперлись.
  • Стоит ли все function собирать в одном файле?

    utyfua:

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

    utyfua: делаем require всего в каком-нибудь autoload.php. Пусть opcache все тупо закэширует и пусть код все время лежит в памяти. Что бы интерпритатор не лазал на файловую систему на каждый запрос и все такое.

    include_once очень медленная штука. Подход когда у вас все инклуды будут прописаны в одном месте спасает. Это не очень явно с точки зрения управления зависимостями но в целом норм, особенно если мы функции выносим в нэймспейсы и делаем их use. Повторюсь - если вы что-то с нуля пишите - используйте php7, там это удобнее.

    xmoonlight: APC? opcache же, с версии 5.5 APC уже нет.
  • Стоит ли все function собирать в одном файле?

    Barmunk вот только не надо говорить что ООП это что бы "функции по классам раскидать". Да и зачем? подключили все файлики и opcache за нас все разрулил. Особенно если с composer-ом.

    utyfua: Возможно вы не правильно их использовали? Накладные расходы на "классы" не такие уж и большие. Особенно в свете PHP7+. Зато ООП позволяет более грамотно построить систему, спрятать состояние и уменьшить сложность.

    Просто никогда не говорите "никогда". Жизнь заставит. На процедурах с глобальным состоянием ничего сложного за адекватные сроки построить не выйдет.
  • Стоит ли все function собирать в одном файле?

    utyfua:

    1) какая разница? Код кешируется в opcache, количество кода не влияет на производительность. Важно что бы код можно было ооочень легко найти.

    2) найти - это древовидная структура. Когда все в одном файле - у вас все будет так или иначе со временем в перемешку.

    3) все что повторяется (именно в плане логики работы а не кода) - в отдельные функции. Много много маленьких функций со временем приведут вас к древовидной структуре проекта.