• Как защитить от перезаписи данных? Например форму для редактирования открывают два пользователя, и одновременно меняют его?

    @xfg
    Данную проблему решают оптимистической блокировкой.

    Оптимистическая блокировка не ограничивает модификацию обрабатываемых данных сторонними сессиями, однако перед началом предполагаемой модификации запрашивает значение некоторого выделенного атрибута каждой из строк данных (обычно используется наименование VERSION и целочисленный тип с начальным значением 0). Перед записью модификаций в базу данных перепроверяется значение выделенного атрибута, и если оно изменилось, то транзакция откатывается или применяются различные схемы разрешения коллизий. Если значение выделенного атрибута не изменилось — производится фиксация модификаций с одновременным изменением значения выделенного атрибута (например, инкрементом) для сигнализации другим сессиям о том, что данные изменились.
    (с) Википедия

    То есть в базе заводите поле version, его вытаскиваете вместе с остальными данными. Затем при обновлении UPDATE SET ..., version = version + 1 WHERE ... AND version = version.

    Соответственно если оба загрузили одну и ту же версию документа, то у второго обновление не пройдет, так как версия документа изменилась и от базы будет возвращено 0 изменений. На эту ситуацию кидаем что-то вроде throw ConcurrencyUpdateConflict, а дальше как-либо обрабатываем пытаясь пересохранить еще раз уже с учетом обновлений от предыдущего пользователя и тогда второй пользователь ничего о конфликте не узнает или же уведомляем его, что произошел конфликт и данные необходимо поправить. Как поступить - зависит от формы. Если несколько раз подряд не получилось автоматически разрешить конфликт, то всё равно в любом случае нужно пользователя уведомлять, что не вышло. Иначе это может крутиться долго.

    В Yii вроде такое из коробки есть, а в laravel с ходу google ничего из официальной документации не выдал. Но можно и самому сделать.
    Ответ написан
    Комментировать
  • Какие недочеты вы скажете по коду?

    @xfg
    Высокая цикломатическая сложность подобного кода. Бизнес-логика смешивается с DOM. Практически весь код дублируется.

    Такой код сложно поддерживать. Сложно читать. Сложно тестировать. Это действительно слабо. Всё же мы пишем для людей, а не для компьютера. Написать сложный код, очень просто. Написать простой код, очень сложно.
    Ответ написан
    2 комментария
  • Стоит ли идти учиться в ВУЗ будущему программисту?

    @xfg
    В ВУЗ идти не стоит. Зачем эта линейная алгебра, векторы, матрицы, определители. Скачай юнити, потыкай в неё мышкой и миллиард в кармане, а деньги за обучение потрать на ассеты.
    Ответ написан
  • Что быстрее освоить новичку: javascript + node.js или javascript + php?

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

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

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

    @xfg
    В PHP сообществе вообще не развиты вопросы проектирования и архитектуры. Большинство лепит, что придумает. PHP изначально родился для примитивных homepage, вобрал в себя всю несерьезность, низкий порог входа и как следствие довольно слабое комьюнити, что часто становится объектом для шуток.

    Искать ответы на вопросы проектирования и архитектуры нужно в Java. Например там почти каждый с самых азов слышал о де факто ставшей стандартом слоистой архитектуре, она же layered architecture, она же n-tier architecture и видел изображение похожее на это
    main-qimg-91d7188a63a833488f92239028d0ae
    Из которой нужно понять, что всю программу можно разделить на несколько слоев и зависимость между слоями должна быть направлена сверху вниз, но не наоборот. Таким образом, например фреймворк может быть инкапсулирован в presentation слой и в любой момент безболезненно заменен на другой, так как другие слои ничего о нем не знают. Вся бизнес-логика инкапсулирована в domain слой в виде plain old java object, который не зависит вообще не от чего, а также предоставляет интерфейсы (репозиториев например) для инфраструктурного слоя и только в этом слое фактически и будет тот самый настоящий ООП, который все так упорно пытаются найти. Никакого стороннего кода в бизнес-логике нет, а соответственно весь сторонний код можно в любой момент поменять, не трогая бизнес-логику вообще.

    Для этого нужно открыть какую-нибудь книгу, где за руку проведут с нуля до конкретного приложения построенного с использованием этой архитектуры. Например Implementing domain-driven design, хоть эта книга и о DDD, но я уже говорил, что слоистая архитектура это де факто. С опытом, будет понятно, что в более простых приложениях количество слоев можно уменьшить, понимая на какой компромисс придется пойти, что иногда можно объединить domain и часть infrastructure и получить всем известный шаблон Active Record или вообще выбросить эти слои и получить шаблон transaction script, когда для решения просто не требуется что-то более сложное. Придет понимание, как можно начать с transaction script и в итоге постепенно катиться в сторону domain layer, через active record или не через active record если это когда-нибудь понадобится и тому подобное. Cтанет понятно, зачем, как и когда использовать патерны о которых написал Мартин Фаулер в своей книге Patterns of Enterprise Application Architecture.

    Полученные знания можно применить к любому языку. В том числе и PHP. Будет хорошо, если уровень этого сообщества хоть чуть-чуть будет подтягиваться к уровню Java, вместо того чтобы бомбить пятиуровневые ифы создавая такую цикломатическую сложность, что все метрики кода горят ярче красного.
    Ответ написан
    Комментировать
  • Какой PHP-микро-фреймворк взять для простенького REST API с авторизацией, и чтобы не из "большой тройки"?

    @xfg
    Сделал бы на Express.js, но там тяжелые запросы к БД ожидаются, а в этих случаях ноду вроде использовать не рекомендуют.

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

    Не рекомендуют использовать node.js для сложных математических/физических и тому подобных расчетов требовательных к процессорному времени, что соответственно будет блокировать процесс пока процессор занят обсчитыванием этой задачи. Что вообще ни разу не про веб. И даже в таком случае, можно разделить такую задачу и выполнить её за несколько тиков или даже в дочернем процессе.
    Ответ написан
    1 комментарий
  • Какую DB для мессенджера выбрать?

    @xfg
    Популярные NoSQL решения не используют джойны поскольку это в любом случае ведет к сетевым походам на различные шарды. Даже если это скрыто от пользователя. Соответственно в распределенной системе вы не получите джойнов как в Postgre. Более того, если пытаться шардировать Postgre, у вас и там возникнет проблема джойнов между шардами и от подобных джойнов придется отказаться.

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

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

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

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

    @xfg
    На подобных форумах это всё обычно крадется через шеллы. Используя уязвимости загружается скрипт позволяющий выполнять удаленные команды на сервере. Иногда команду на сервере можно выполнить прямо из адресной строки браузера. Так или иначе все сводится к получению доступа к командной оболочке операционной системы с правами достаточными, чтобы выполнить бекап файлов/базы прямо в webroot для дальнейшего выкачивания их по http.

    На что обратить внимание, чтобы в последующем не найти свой проект на одном из этих форумов?

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

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

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

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

    @xfg
    Авторитетные книги и авторы в этой области отсутствуют. Статьи по основным темам есть:

    Игровой цикл
    Архитектура игры
    Архитектура игры на русском (видео)
    Определение столкновений
    Шейдеры
    Библиотека для работы с 3D графикой
    Библиотека для работы с физикой
    Пример игры на entity-component-system
    Действия над векторами

    Можно также поизучать матрицы преобразования (смещение, поворот, масштабирование), view matrix, perspective matrix, но в целом это уже реализовано в любой библиотеке для работы с 3d.
    Ответ написан
    1 комментарий
  • Какое направление выбрать для входа в разработку и есть ли этот самый выбор?

    @xfg
    - Реально ли за срок 2-3 месяца, выучить технологии\языки для фронтенда?
    - реально ли за аналогичный срок добиться того же результата, но изучая Java?

    Выучить технологии/языки и городить заборы из условных конструкций — реально, стать программистом — нет.
    Ответ написан
    Комментировать
  • Как лучше организовать рабочее окружение для веб разработчика?

    @xfg
    linux + docker + git вот и всё окружение.
    Ответ написан
    Комментировать
  • Каким образом правильнее всего спроектировать базу данных для истории изменения текстовых документов?

    @xfg
    Можно посмотреть на архитектуру CQRS + Event Sourcing. Вместо того, чтобы хранить состояние сущности, хранят произошедшие с ней события. Накатив эти события в порядке очереди на сущность всегда можно получить состояние сущности на любой момент времени.

    Упрощается работа с записью данных в хранилище, но усложняется чтение. Поэтому обычно еще используют CQRS с двумя хранилищами, одно для записи где хранится последовательность событий, другое для чтения, где хранится текущее состояние сущностей. WriteModel отправляет в брокер сообщение о произошедшем событии, ReadModel ловит это сообщение и обновляет свое состояние в базе данных. ReadModel можно всегда пересобрать заново с нуля по имеющимся событиям. Можно использовать денормализацию данных и писать в базу так, чтобы читать нужные данные используя простейшие запросы.

    Базы данных можно брать любые, хотя обычно для ReadModel используют стандартную реляционную или документоориентированную, а для WriteModel можно взять что-нибудь более специализированное, например event store, просто потому что все фишки реляционных субд для этой части приложения не требуются.

    Можно посмотреть примеры реализации event sourcing https://github.com/prooph/event-sourcing
    Ответ написан
    3 комментария
  • Какую специализацию выбрать прямо сейчас?

    @xfg
    сразу идти туда

    Меньше читать бесполезных статей в рунете о том как это сложно и больше делать. Попасть в компанию, которая делает проекты AAA класса с отсутствием знаний маловероятно, но во что-то попроще вполне. В статьях ясное дело гонят жуть, что нужно быть физиком-ядерщиком чтобы работать в геймдев. Всё сильно проще. Не все там сидят пишут заумные физические симуляции, сложные движки и делают игры с миллиардными бюджетами. Многие используют уже что-то готовое. Многие вообще ничего не используют кроме базовых знаний векторов, пары простейших алгоритмов столкновений и умения водить кистью в фотошопе для создания сплат карт, карт высот и прочего, чтобы затем написать пару шейдеров в 10 строк для генерирования игрового ландшафта по этим картам. Многие работают с 2D и делают всякие фермы. Многие вообще ничего не знают и тыкают мышкой в какое-нибудь unity.

    В рунете много людей имеющих типаж "что-то слышал", которые любят раздуть из любой ерунды гигантскую проблему. Таких если слушать, так даже лампочку в люстру вкрутить не получится.
    Ответ написан
    1 комментарий
  • Как работать с 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 и посмотреть реализации других разработчиков. Для этого нужно быть кем-то больше, чем "программистом сайтов".
    Ответ написан
    1 комментарий
  • Почему наши топ веб-студии не считают Wordpress серьезной CMS, а американские топовые студии делают на нем 50% сайтов?

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

    @xfg
    Да по хорошему нужно делать на микрофреймворке. Самый популярный из них slim. Весь остальной необходимый функционал собирают из библиотек. Но желательно иметь представление о многоуровневой архитектуре иначе будет спагетти-код. Без опыта да, лучше выбрать yii или laravel. Поскольку документация ответит на все ваши вопросы от старта и до релиза сайта. Но поскольку документация описывает RAD (rapid application development) будьте готовы, что на выходе получится спагетти-код. Но на микрофреймворке без опыта будет еще хуже.

    Выбирайте любой. Разницы особой нет. У yii сильное русскоязычное сообщество. Разработчики и сообщество иногда делятся информацией о том как строить многоуровневую архитектуру. Получите опыт и придет осознанное понимание что достаточно микрофреймворка.

    Обычный путь разработчика: plain php -> mvc framework -> microframework -> plain php
    Ответ написан
    1 комментарий
  • Какой JS фреймворк выбрать для full-stack?

    @xfg
    Лучшее что сейчас есть это koa или express для http протокола и socket.io для websocket протокола. PHP тоже от full-stack фреймворков движется в сторону микрофреймворков. Сегодня современный фреймворк это роутинг запросов реализованный на концепции мидлваров.

    Проблема спагетти-кода решается не фреймворком, а архитектурой. На сервере это обычно multilayered architecture. Бьете приложение на 4 слоя presentation, application, domain и infrastructure (еще могут называть data access layer или persistence layer). Контроллеры фреймворка куда попадает запрос пользователя это будет ваш самый верхний presentation слой. Слой инфраструктуры лучше собирать из отдельных библиотек, чем завязывать его на фреймворк. В таком случае не придется переписывать весь слой инфраструктуры из-за того, что фреймворк больше не развивается. Application и Domain слои используют Infrastructure слой через интерфейсы, тем самым абстрагируясь от конкретных реализаций. Таким образом вы всегда сможете заменить одну реализацию другой (паттерн Strategy) без изменения вышестоящих слоев. Presentation слой просто вызывает сервисы из application слоя и возвращает результат в html/json/xml/etc клиенту.

    Иногда упрощают до 3 или даже 2 слоев. Например если у вас CRUD приложение, тогда application и domain слои не нужны и вы можете оставить только presentation и infrastructure. Также если ваш application слой не делает ничего, кроме вызова domain слоя, то от него также можно избавиться оставив 3 слоя presentation, domain и infrastructure.

    Примеры реализации можно найти здесь и здесь. Они на Java. На javascript пока не встречал.

    Более подробно тему можно изучить взяв любую книгу на эту тему.

    Meteor не советую. Это не будущее. Это костыль. Они хотели сделать фреймворк для real-time приложений. Но фактически получилась просто платформа для стриминга произошедших изменений в mongo прямо на клиент.

    Sails это попытка сделать full-stack фреймворк. Но весь мир движется в обратном направлении.
    Ответ написан
    3 комментария
  • Как разместить большую MySQL-базу на нескольких серверах и как при этом будут работать индексы?

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