Ответы пользователя по тегу Веб-разработка
  • Почему на одних сервисах просят сначала email, а потом пароль, а на других сразу оба?

    @xfg
    Началось всё с того, что помимо стандартной формы входа на сайт также стали появляться кнопки входа через социальные сети. Например вы зарегистрировались на целевом сайте используя свой аккаунт на твиттере. Затем какое-то время не пользовались целевым сайтом, после чего вернулись и... Вы точно помните что у вас уже есть аккаунт на данном сайте, но вы не помните какой способ входа вы использовали. Перед вами с десяток различных кнопок. Какую из них нажимать? Думаю, история знакомая многим.

    Так вот в какой-то момент появилось исследование суть которого в том чтобы изменить форму входа таким образом, чтобы пользователю теперь было достаточно указать только email-адрес, а дальше система сама определит через какой провайдер был зарегистрирован пользователь на сайте с этим email-адресом и в зависимости от этого может либо отобразить пароль для ввода, сделать редирект на сайт провайдера для подтверждения входа или сразу аутентифицировать пользователя на целевом сайте, если пользователь уже авторизован и имеет необходимые разрешения для целевого сайта на сайте-провайдере (например на twitter.com).

    Таким образом это ничто иное как улучшение взаимодействия с пользователем. Но как и всё в мире имеет определенные недостатки. Например теперь можно узнать зарегистрирован ли определенный пользователь на определенном сайте зная лишь только его email адрес или номер телефона. То есть страдает конфиденциальность.

    Пример реализации можно увидеть на сайте yandex.ru.
    Ответ написан
    Комментировать
  • Как вы разрабатываете свои приложения?

    @xfg
    Я TDD использую. Без тестов совершенно не понимаю сделал задачу или еще нет и все вокруг кажется недоделанным. Здесь же поделил крупную задачу на ряд небольших, написал тесты, написал код и четко чувствуешь момент, когда можно переходить к следующей задаче. Но я не в релизе, поэтому я плохой пример, так как делаю потому что интересно сделать бесконечно масштабируемое full-websocket приложение с использованием 3d и слоистой архитектурой из всех этих умных книг по объектно-ориентированному программированию, а не потому что жажду миллиард. За это время уже сбился со счета сколько сменил фреймворков, баз данных и даже поменял язык в итоге. За это время успел родиться AngularJS (тот что 1.x) и умереть, а я все пишу :)
    Ответ написан
    1 комментарий
  • Как вы относитесь к использованию транзакций в Laravel?

    @xfg
    Транзакции повторяют из-за дедлоков. Это такое состояние, когда одновременно выполняются 2 транзакции и первая транзакция блокирует запись, которая нужна второй транзакции, а вторая транзакция блокирует запись, которая нужна первой транзакции. В итоге ни одна из транзакций не может завершиться. Это состояние называется deadlock. В этом случае одна из транзакций должна откатиться, чтобы другая имела возможность успешно завершиться. Так вот, эта транзакция, которую откатили попробует еще 3 раза выполниться, прежде чем окончательно вылетит с исключением.

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

    Вообще на более продвинутом уровне принято сохранять не более одной сущности (объекта) внутри одной транзакции. Таким образом вы получаете худые транзакции и отсутствие дедлоков. Производительность вашего приложения возрастет, но вместе с тем, вы получите проблему атомарного сохранения нескольких сущностей (объектов) в рамках одной бизнес-операции как это происходит в микросервисной архитектуре. Проблему можно решить использованием шаблона saga, но в целом это уже совершенно иной уровень знаний и вникать в это наверное не стоит, если вы делаете что-то небольшое.
    Ответ написан
    4 комментария
  • Самый простой способ реализовать real time MySQL (без firebase!) базу данных для маленького приложения?

    @xfg
    Базу данных можно выбрать любую. Она не играет роли в realtime приложениях. Позвольте вам немного объяснить. Для передачи данных между клиентом и сервером в браузере существует всего два протокола. HTTP и Websocket. Firebase не магия и также использует их. Если браузером не поддерживается Websocket, то firebase откатывается на HTTP. Используя общераспространенный подход к разработке на PHP у вас не получится использовать websocket протокол поскольку типичные PHP приложения не живут дольше 1 запроса. Соответственно да, в таком варианте остается только ajax. Но точно также работает и firebase если в браузере нет поддержки websocket, так работает facebook, telegram и много всего остального. Они используют long-polling. Клиент отправляет запрос к скрипту на сервер, скрипт в цикле опрашивает хранилище mysql или более продвинутый вариант mysql+redis (чтобы не грузить запросами mysql) и пока данных не будет, цикл так и продолжит крутиться, для клиента это просто выглядит как повисший запрос к серверу. Как только данные появляются, они отправляются на клиент, соединение разрывается, а клиент сразу же отправляет новый запрос.

    Есть развитие этой идеи. Называется HTTP Streaming. Отличие от long-polling в том, что после отправки данных клиенту соединение не разрывается, а сервер продолжает отправлять последующие данные по этому же соединению. Соединение разрывается по таймауту. Минус в том, что прокси-сервера могут кешировать небольшие пакеты данных и данные нужно раздувать например пробелами, чтобы пакет данных достигал минимального размера и был способен пробить кеш прокси-сервера. Плюс в том, что если у вас данные для клиента появляются скажем с переодичностью раз в секунду, то не будет происходить постоянного открытия-закрытия соединения как при long-polling.

    Есть вариант, когда можно реализовать небольшую прослойку на socket.io. Ваше PHP приложение пишет данные для клиента например в redis. Приложение на socket.io подписывается на redis. Когда PHP что-то отправляет в redis, то socket.io мгновенно об этом узнает и рассылает это событие по websocket протоколу всем подключенным клиентам. Минусы. Раздуваете стек. Нет консистентности данных между записью в основное хранилище (mysql/postgre/mongo/etc) и redis. Соответственно может возникнуть ситуация, когда данные записали, но в redis событие не ушло. Поменяете местами, будет наоборот, событие есть, данных в базе нет.

    Вариантов в целом очень много. Всё это называется Comet. Вам проще всего реализовать long-polling.

    А реал-тайм база, которая умела пушить данные клиенту по tcp протоколу (но не в браузер) была и называлась она rethinkdb.com. Ныне не развивается. IP в России заблокирован. На сайт можно сходить по VPN.
    Ответ написан
    3 комментария
  • Что быстрее освоить новичку: javascript + node.js или javascript + php?

    @xfg
    Для новичков PHP проще. PHP вида "запрос-ответ-умер" прощает многое. Можно писать как угодно и при этом не иметь утечек памяти поскольку всё должно быть подчищено за разработчиком по завершению скрипта, а если нет, то проблема не ваша, а связующего ПО.

    Node.js ничего не прощает, не понимаете как работает event loop считайте, что не понимаете в какой последовательности будет выполнен код. Возможны утечки, захват процессорного времени, неэффективное использование многоядерного процессора.

    Но многие используют Javascript на клиенте, никогда не слышали про event loop, их код бесконечно ест память и большинство об этом даже не знают, что не мешает вешать себе регалии сеньоров и мидлов. Если похожий подход то можно прямо сейчас начать писать боевой код на node.js. Как-то оно всё равно будет работать.
    Ответ написан
    Комментировать
  • Какие технологии использовать для реалтайма?

    @xfg
    как посылать данные из PHP в ноду?

    Отправляй не в ноду, отправляй в базу. В redis например. Есть готовое решение https://github.com/socketio/socket.io-redis

    Со стороны php https://github.com/rase-/socket.io-php-emitter
    Возможно придется форкнуть эту библиотеку и немного подправить под современную версию socket.io, так как библиотека автором не поддерживается.
    Ответ написан
    Комментировать
  • Почему наши топ веб-студии не считают Wordpress серьезной CMS, а американские топовые студии делают на нем 50% сайтов?

    @xfg
    1c битрикс вкладывает денежные средства в маркетинг на территории СНГ. WP ничего не вкладывает. Отсюда результат. Веб-студии вообще сложно ассоциировать с дизайном, юзабилити или программированием. Вся их деятельность это купить, соединить и продать. На их место должны придти IT компании с онлайн сервисами. Делать на потоке штучный продукт невозможно, а любой конвеер можно автоматизировать.
    Ответ написан
    4 комментария
  • Как правильно настраивать дев-окружение для веб-разработки?

    @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 и продакшн сервера. Примерно так в общих словах устроена веб разработка.
    Ответ написан
    22 комментария
  • Как реализовать проект от а до я, с созданием сайта, серверной части, мобильных приложений под ios,android и windows phone?

    @xfg
    Обратитесь в несколько аутсорсинговых компаний. Скажите, что нужен прототип такого сайта, максимально дешевый, только основной функционал. Посмотрите какие работы они уже делали. Если понравятся и устроит цена, заключайте договор и пусть делают. Не нужно прямо сейчас делать моб. приложения или дорогой сайт, который будет проектировать какой-то там умный архитектор. Сейчас нужно проверить бизнес-идею и в случае не успеха выйти с минимальными потерями. Если сайт будет хоть какие-то копейки приносить, выбросить прототип и сделать всё заново, будет не жалко. Все так делают. Сайт который вы приводите в пример переписывали 4 раза и в период с 2006 по 2011 год он помоему не приносил никакого существенного дохода. Вместо моб. приложений лучше подумайте, как такой сайт наполнить первоначальным контентом. На пустой сайт никто ходить не будет. Нужны источники-доноры на первое время, пока у сайта нет своих пользователей.
    Ответ написан
    Комментировать
  • Есть идея по защите от спама, но сработает ли?

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

    Ваше решение обладает излишней сложностью для ботов общего назначения и в то же время не сильно затруднит работу программисту, который будет писать целевого бота под ваш сайт. Достаточно скрытого поля через css и на сервере убедиться, что оно осталось незаполненым. Поможет избежать спама от ботов общего назначения. С целевыми ботами и ручными спамерами борются кто как используя комплекс мер, регистрируют по номеру телефона, привлекают пользователей к борьбе со спамом, выдают капчу на подозрительную активность и прочее Можете проанализировать большие сайты, если интересно. Но если ваш сайт не является таким же интересным для спамеров, то и усложнять так всё не имеет смысла.
    Ответ написан
    3 комментария
  • Как вы относитесь к такому тестовому заданию?

    @xfg
    Ctrl + S в браузере. Результат отправить заказчику.
    Ответ написан
    1 комментарий
  • Меньше стек технологий, больше шанс устроиться на удаленную работу?

    @xfg
    Есть вакансии в веб-студиях, где нужен человек, который уже готовую верстку поставит на wordpress/bitrix, установит нужные модули и редко (почти никогда) напишет свой модуль. В общем ставят задачу собрать сайт и отдать контент-менеджеру. В такой вакансии будет указан стек технологий, но по факту, всё что нужно знать, это куда воткнуть вывод данных в html и как загрузить своё поделие на сервер по ftp. Таких вакансий в PHP довольно много, можно устроиться с минимальным набором знаний.

    С другими языками сложнее, там нет конвеерных веб-студий делающих сайты на цмс за 1 день, как в PHP. Там как правило командой делают нетипичный проект некоторое время для решения бизнес-задач и к таким разработчикам требования значительно выше, знания алгоритмов, архитектуры, паттернов, системы контроля версий, фреймворков, TDD и т.п.
    Ответ написан
    2 комментария
  • Как правильно организовать структуру постоянно изменяющегося проекта?

    @xfg
    Для энтерпрайза с обширной бизнес-логикой подойдет DDD. Перевести за раз уже существующий проект с огромным функционалом и костылями будет нереально. Можно попробовать небольшими итерациями. Уровень команды тоже должен соответствовать, поскольку при строительстве такой архитектуры точно будет использоваться добрая половина паттернов описанная в книге PoEAA.
    Ответ написан
    Комментировать
  • Не убьёт ли WebAssembly node.js?

    @xfg
    WebAssembly это низкоуровневый язык программирования. Никто на нем в здравом уме не будет писать. Это почти тоже самое, как пытаться писать веб с помощью ассемблера. В него просто будут компилировать код с других языков, сейчас пока только C и C++, позже будут и другие. Он нужен, чтобы ускорить клиент-сайд, поскольку javascript медленный для всяких там 3D игр и всего такого. В общем походу скоро php захватит и клиент :)

    Кроме того, эта идея уже была ранее реализована в asm.js от компании Mozilla. Разработчики сделали на C++ демку 3d игры скомилировали её в asm.js, общественность немного поигралась и всё заглохло. Революции не произошло.
    Ответ написан
    5 комментариев
  • Как узнать почему падает сайт?

    @xfg
    Читать логи веб-сервера/базы данных и других демонов, которые принимают участие в работе сайта. Есть сервисы куда можно вываливать все эти логи, чтобы проще было мониторить работу системы.
    Ответ написан
    Комментировать
  • Должен ли верстальщик заниматься созданием (разработкой) шаблонов страниц?

    @xfg
    Я бы верстальщика заменил на фронтенд разработчика. Бекенд разработчика избавил бы вообще от работы с шаблонами. Они оба программисты и могут друг друга вполне понимать. От бекендера нужен API. От фронтендера трансляция этого API в удобный веб интерфейс для пользователя. Верстальщик больше подходит для верстки бумажных материалов, где-нибудь в типографии или для создания статичных веб страниц. Когда сайт динамический, то верстальщик только ломает весь процесс.
    Ответ написан
    7 комментариев
  • Где искать заказчиков дизайнеру сайтов, если умеешь работать только в фотошопе и вёрсткой не владеешь?

    @xfg
    нет денег на повышение уровня квалификации

    С помощью чего вы собираетесь повышать квалификацию?
    Есть же самообучение. Нужны заинтересованность и время. Курсы, семинары, мастер-классы это впервую очередь бизнес. В конечном счете ваш учитель или учитель вашего учителя изучал всё самостоятельно и не платил за это деньги. Большинство программистов изучает самостоятельно.
    Ответ написан
    Комментировать
  • С помощью чего писать тесты для сайта?

    @xfg
    Из популярных для юнит-тестов
    mocha
    jasmine
    Для end-to-end тестов
    nightwatch
    protractor

    Да, можно тестировать как клиентскую часть, так и серверную. На клиентской части когда пишешь юнит-тесты может возникнуть проблема с DOM, так как не очень понятно, как мокать такие зависимости. Поэтому клиент сайд фреймворки, такие как angular пропагандируют подход к написанию кода таким образом, чтобы бизнес-логика никогда не перемешивалась с DOM. Таким образом всю важную бизнес-логику можно будет покрыть юнит-тестами, без всяких проблем.

    Функциональные (end-to-end) тесты эмулируют поведение пользователя через реальный браузер. То есть end-to-end тест нажимает кнопочки, заполняет поля, ходит по ссылкам. Эти тесты более медленные, чем юнит-тесты. Изменения в верстке страницы могут их поломать. Но они более высокоуровневые, дают убедиться, что страница работает именно так как предполагалось. Не зависят от кода, а следовательно не имеют проблем с DOM в отличие от юнит-тестов.

    Лично я пишу только юнит-тесты. И не пишу интеграционные и функциональные. Юнит-тесты очень быстрые, можно в автоматическом режиме прогонять при каждом сохранении файла проекта. В тоже время они дают приемлемый уровень уверенности в том, что билд проекта скорее будет работать, чем нет. Если писать все типы тестов, то можно выстрелить себе в ногу. Будет медленее. Будет больше проблем с исправлением кучи всяких разных тестов.
    Ответ написан
    1 комментарий
  • Что все-таки должен уметь делать frond-end-разработчик?

    @xfg
    Бекендер предоставляет api для манипулирования данными, а ваша задача эти данные отобразить конечному пользователю. Взаимодействие с сервером ваша задача. Вы делаете полностью клиент. На каком фреймворке или без, вам решать. Но в подавляющем большинстве случаев пишут classic websites, где клиентская часть генерится на сервере и клиент соответственно писать не нужно, поэтому весь сайт делает бекендер, отдать можно только верстку верстальщику, а фронтендер в таком проекте не нужен.

    Фронтендер такой же программист. Скажем у фейсбука есть API, вас просят написать веб клиент к этому api. И вы должны это сделать. На выходе должен быть готовый продукт, которым уже может пользоваться конечный потребитель. Это фронтендер. Это его отличает от верстальщика, задача которого картинку напилить в html.
    Ответ написан
    Комментировать
  • Правильно ли я использую PHP-DI?

    @xfg
    Неправильно. Внедряйте зависимости, а не контейнер. Вы нарушаете Закон Деметры. Будут те же самые проблемы при классическом подходе к юнит-тестированию, как если бы вы вообще ничего не внедряли и инстанциировали все зависимости прямо в классе.
    Ответ написан
    Комментировать