Контакты
Местоположение
Россия, Свердловская обл., Екатеринбург

Достижения

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

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

Все теги (68)

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

Все ответы (120)
  • Как вы планировали своё учебное время?

    @xfg
    В любом длительном деле главное заинтересованность. Вам нужно начать делать любой интересный для вас проект. В процессе, когда вам требуется сделать то или иное для вашего проекта, вы гуглите, читаете, делаете и даже что-то запоминаете. Изначально по любому вопросу будет требоваться гугл, но очень скоро обнаружите, что уже изучили добрую половину API языка javascript, спроектировали и сверстали несколько UI экранов вашего проекта.

    Радуйтесь маленьким победам. Когда вы делаете интересный лично для вас проект, вы понимаете зачем вы сейчас читаете тот или иной материал. Вы практикуетесь, вы решаете реальные задачи. Я никак не планировал учебное время, я 15 лет назад захотел свой сайт, открыл блокнот, нашел в сети учебник по html читал и сразу делал свой сайт. Потом захотел бекенд и открыл php.net, далее возникло желание, чтобы код был не просто лапшой, а имел какую-то структуру так познакомился с различными фреймворками. Потом захотел, на свой код тесты и так познакомился с TDD/BDD. Далее захотел независимую от фреймворка бизнес-логику и так познакомился с DDD. Ну и так далее.

    Английский учил также. Сразу взял интересную мне статью и запоминал все важные незнакомые в ней слова. Иногда что-то о попадавшихся грамматических конструкциях читал если смысл предложения оставался не понятным зная все слова. Важно то, что я никогда не изучал всё сразу, только то, что нужно мне прямо сейчас, для решения моей задачи.

    Если задуматься, все наши предки делали примерно также. Сначала была задача, а только потом они искали решение этой задачи. Человек захотел подняться в небо и только потом, он искал решение. Не наоборот. И это был не боинг.
    Ответ написан
  • Как правильно настраивать дев-окружение для веб-разработки?

    @xfg
    Не думайте о доменах. Вы смешали администрирование и программирование. Не нужно никакого dev сервера. Делайте работу на локальной dev машине, отправляйте изменения в удаленный репозиторий и всё. Можете вообще не устанавливать nginx/apache и т.д. на локальную dev машину, чтобы не забивать голову всякими доменами, а проект запускать под встроенным PHP сервером например из корня проекта и тогда будете обращаться к вашим сервисам по адресу localhost:port/service1/index.php, localhost:port/service2/index.php и т.д.

    Домены будете создавать уже на продакшене. В простейшем случае склонируете на продакшн машину удаленный репозиторий проекта и в конфигах nginx нужно будет написать что-то типа такого

    server {
      server_name company.com;
      root /home/www/company/frontend;
     ...
    }
    server {
      server_name admin.company.com;
      root /home/www/company/backend;
     ...
    }
    server {
      server_name service1.company.com;
      root /home/www/company/service1;
     ...
    }
    server {
      server_name service2.company.com;
      root /home/www/company/service2;
     ...
    }


    Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз...

    Так и делают. Разработчикам не нужен никакой dev сервер. Они клонируют репозиторий, делают что-то локально у себя и отправляют изменения в удаленный репозиторий. Для тестеров и всяких менеджеров просто поднимают так называемый stage-сервер где они и тестируют приложение, но это тоже самое что и продакшн сервер, просто доступ к нему только внутри компании. Можно настроить continuous integration чтобы все изменения из репозитория в master ветке автоматически бы приводили к деплою приложения на stage и продакшн сервера. Примерно так в общих словах устроена веб разработка.
    Ответ написан
  • Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

    @xfg
    Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

    Интернет забит вопросами о том как жить без транзакций в NoSQL. Но бизнес-процессы в реальной жизни не являются транзакционными. Вы не можете человека, который покушал в вашем ресторане, а теперь отказывается платить по счетам заставить сделать роллбек вашей еды. Фактически посетитель вам бросил эксепшен. И даже если вам удастся извлечь еду из вашего посетителя, то маловероятно, что она будет готова к последующему употреблению. Но можно взыскать с него все затраты через суд и придти таким образом в согласованное состояние. Любому бизнесмену это очевидно. Но программисту нет. Он хочет транзакционно. Но пишет систему для автоматизации бизнес-процессов. Парадокс.
    Ответ написан
  • MVC php на пальцах?

    @xfg
    Модель - это любая ваша бизнес-логика, всякие вычисления и запросы к бд. То есть то, без чего приложение впринципе не имеет смысла.

    Контроллер - это посредник между моделью и видом. Он запрашивает данные (вызывает методы) у модели и затем передает их в вид.

    Вид - с помощью полученных данных от контроллера рисует пользовательский интерфейс.

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

    Нужна одна точка входа. Клиент всегда запрашивает только index.php, оно там внутри на основе данных из запроса решает какой контроллер создать и какой метод из контроллера выполнить. Всё.
    Ответ написан
  • Как работать с websocket в php без библиотек?

    @xfg
    Прочитать соответствующий RFC https://tools.ietf.org/html/rfc6455 чтобы понять, как происходит рукопожатие и какие байты в переданном сообщении за что отвечают. После этого будет понятно как написать реализацию. Я досконально уже не помню, но фактически от клиента приходит обычный http запрос с определенными заголовками, сервер разбирает этот запрос и если всё ок, то сохраняет открытое соединение в массив, если нет, то отправляет соответствующий ответ и закрывает соединение. Дальше по открытому соединению начинает сыпаться поток байтов от клиента их нужно разбирать, чтобы понять длину сообщения, сами данные переданные в фрейме, закончился фрейм или еще нет и тому подобное. Обратно также кодировать данные в поток байтов и отправлять по открытому соединению. Каждый байт в переданном фрейме несет определенный смысл. Обо всем этом подробно написано в RFC, но на английском. Вообще это хорошо примерно понимать как работает, но глупо писать такую низкоуровневую реализацию, когда есть готовые. Такие вещи развивают и поддерживают годами. Вы же не пишите HTTP серверы, а берете готовые вроде nginx и тому подобное.

    В каком месте можно полученные данные подготовить к записи в бд.

    Как сделать, что бы на стороне клиента, один websocket отвечал за сообщения, другой за статьи. (Или за эти два действия отвечает один websocket, тогда как мне на сервере это различать).

    Вебсокет это низкоуровневая штука, для передачи потока байтов от клиента на сервер, в отличии например от HTTP, где есть заголовки и тело сообщения. Поверх вебсокета нужно делать еще один протокол или самописный или выбрать один из готовых. Это проще говоря, то как выглядят ваши фреймы (сообщения), которые вы отправляете с клиента на сервер и назад. Например клиент может отправлять такой фрейм:
    ["id", "controller/action", {param1: value1, param2: value2}]

    в ответ получать
    ["id", "OK"]
    если запрос был обработан успешно или
    ["id", "ERR", {error: "action not found"}]
    если произошла ошибка. По переданному id в массиве, можно понимать, к какому запросу относится ответ.
    Для уведомлений (событий) сервер может отправлять клиентам что-то такое
    ["user_added", {user: {...}}]
    и т.д. Этот протокол необходимо придумать самому или выбрать из готовых (популярных пока нет) и написать его реализацию (клиентскую и серверную часть) или опять же взять уже готовую.

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

    Но это уже всё должно быть, просто возьми real-time фреймворк. Там за тебя написали и websocket сервер и протокол поверх него и экшены уже есть. Всё низкоуровневое уже готово. Бери и пиши приложение. В nodejs самый популярный это например https://github.com/socketio/socket.io, а в php я не знаю, но уверен, что тоже есть что-то популярное.

    Своё написать не получится, без опыта и без попыток сделать приложение на чем-то готовом. Нужно как минимум прочитать RFC и посмотреть реализации других разработчиков. Для этого нужно быть кем-то больше, чем "программистом сайтов".
    Ответ написан

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

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