• Как назвать этот процесс?

    @Akela_wolf
    Extreme Programmer
    А первый проект прям проект-проект или по сути скрипт сборки второго проекта?
    Пока выглядит так, что эти три проекта (2-4) суть модули какой-то системы. А первый - часть buildscript этой системы.

    По крайней мере так было бы в моем мире JVM и Gradle.
    Ответ написан
  • Какой стек технологий выбрать для высоконагруженного MVP?

    @Akela_wolf
    Extreme Programmer
    Писать надо на том, что знаешь. От языка способность держать высокую нагрузку зависит слабо - есть вполне себе хайлоад (лично видел, платежная система), написанный на PHP.
    Для серьезного хайлоада важнее другая характеристика: не скорость работы, а стоимость ошибки. Если ваш хайлоад "ляжет" из-за какой-то ошибки (да еще с потерей части данных) - это будет очень-очень-очень плохой экспириенс для пользователей. А если это будет происходить неоднократно - потеря посетителей вам гарантирована.
    Поэтому у меня для хайлоада приоритеты:
    1. Надежность
    2. Скорость разработки
    3. Производительность

    Итак, по пунктам.
    Надежность. Это про то, насколько строго язык отлавливает ошибки программиста и насколько просто на нем написать подверженную ошибкам муть. Насколько просто будет сопровождать код, написанный на данном языке. В этом пункте ключевые слова "архитектура", "покрытие тестами" и "статическая типизация". Первые два пункта - это про любой язык, так как реализуются на уровне процессов разработки. Из предложенного списка языков статическую типизацию обеспечивают Java (Kotlin) в мире JVM и Typescript (не Javascript) в мире Node.js

    Скорость разработки. Это про наличие большого количества готовых библиотек и про богатые возможности языка для выражения требуемых программисту структур данных и алгоритмов. Тут фавориты те же: Java/Kotlin и Typescript. На мой взгляд, JVM-мир сложнее, но дает все-таки больше возможностей (тот же Spring обеспечивает создание бинов за пару аннотаций).

    Производительность. Не могу сказать о Node.js - не тестировал на производительность, но JVM обеспечивает очень хорошую скорость. Еще один немаловажный момент: очень часто в хайлоаде приложение чего-то ждет. Например, отправив запрос в БД ожидает ответа. А в это время могло бы обрабатывать другой запрос другого пользователя, а получив ответ из БД - вернуться к обработке первого (reactive programming). Для этого у нас есть разные реактивные фреймворки для той же Java (Reactor, Vert.x и т.п.) и, что особенно приятно, корутины в котлине, которые позволяют писать асинхронный код почти настолько же просто как и синхронный. На Javascript с их async/await тоже можно такое писать, хотя возможностей все-таки поменьше чем в Котлине.
    Опять же, с корутинами достаточно легко и просто реализуется многопоточность, в ноде с ней не все так просто (хотя она тоже есть).

    Таким образом, мой личный выбор для хайлоада: JVM и Kotlin.
    Альтернативный вариант: Node.js и Typescript.

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

    P.S. Также Kotlin является официальным языком для Android, поэтому можно подумать о том чтобы писать и мобильное приложение и сервер на одном языке.
    Ответ написан
    Комментировать
  • MVC (PHP): правильно ли понимаю слои?

    @Akela_wolf
    Extreme Programmer
    Модель - собственно данные с которыми работает программа. Они составляют основу программы и, вообще говоря, ничего не должны знать о контроллерах и прочем взаимодействии с пользователем. Теоретически к слою данных можно обратиться откуда угодно - хоть из скрипта, хоть через рест, хоть через вебсокеты, хоть через интерфейс десктопного приложения и т.д. Сервисы, в которых у вас бизнес-логика находятся рядом с моделью и составляют ядро приложения. Либо этих сервисов нет и вся бизнес-логика в модели (такое тоже может быть)

    Контроллер - собственно слой, отвечающий за взаимодействие с пользователем (причем конкретный способ взаимодействия - через рест или веб)
    Представление - тоже рядом, это преобразованные данных модели в то как они отдаются пользователю. Если мы говорим про рест - там может не быть представления как такового, могут отдаваться сразу модели. А может и быть - тут все зависит от конкретной задачи

    Хранение - слой, отвечающий за сохранение данных модели в БД/файлы/куда-нибудь еще. Модель, как чистая бизнес-логика, обычно не должна знать про то как и куда её данные сохраняются. Есть просто интерфейсы - прочитать данные, записать данные. А за ними реализация работы с БД и прочими хранилищами.

    Это я написал так, как полагается делать в теории, как описывает Роберт Мартин в книге "Чистая архитектура". Понятно что в реальности (а мы говорим про PHP), все это вряд ли будет настолько четко разделено в коде. Но в голове вот такое разделение на Контроллер(представление) - Модель - Хранение я держать советую.
    Ответ написан
  • Зачем в интерфейсах логика?

    @Akela_wolf
    Extreme Programmer
    1. Класс может иметь поля (состояние), интерфейс нет. Вот это первое и главное различие
    2. Интерфейс не может иметь протектед и приватные методы, класс - может.

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

    Еще посмотрите extension functions в Котлине - придуманы с той же идеей, хотя имеют свои преимущества (легко добавить к существующему интерфейсу/классу) и недостатки (нельзя перекрыть в производном классе)
    Ответ написан
    Комментировать
  • JDBC, почему нельзя использовать один Connection для нескольких методов в разрезе многопоточности?

    @Akela_wolf
    Extreme Programmer
    1. Синхронизация между потоками. Если оба потока начнут посылать запросы в БД через один коннекшен - могут начаться спецэффекты (тут нужно курить "потокобезопасность" коннекшена)
    2. Транзакции в БД. Запросы через один коннекшен будут в одной транзакции. Если для вас это ОК - то все ок. Если же разные потоки требуют разных транзакций - то придется каждому потоку выдавать свой коннекшен.
    100 пользователей и 100 потоков - это слегка разные вещи. Я бы в первую очередь посмотрел сюда - по потоку на каждого пользователя для меня выглядит подозрительно. Если это веб, то у вас от каждого пользователя приходит запрос, обрабатывается, отправляется ответ. Все. Если от пользователей приходит мало запросов - это может делать и один поток. И даже в случае вебсокетов - все равно не нужно держать по потоку на пользователя.
    Ответ написан
    Комментировать
  • Архитектура. Насколько правильно хранить в Entity данные, не относящиеся к БД?

    @Akela_wolf
    Extreme Programmer
    В принципе можно, никто вас за такое не расстреляет. Проблемы - тут все зависит от масштаба вашего приложения и требований к дальнейшей поддержке и изменениям в коде. Чего-то прямо серьезного, что вылезет всегда или почти всегда я в этой истории не наблюдаю.
    Ответ написан
    Комментировать
  • Какие символы разрешить в логине (имени пользователя)?

    @Akela_wolf
    Extreme Programmer
    Я бы разрешил латинские и русские буквы (если сайт включает русскоязычную аудиторию, конечно), пробел, дефис и подчеркивание, а также цифры и спецсимволы. Минимальная длина - 3-4 символа, максимальная длина - на ваше усмотрение (12-16 символов или даже больше).

    Логин регистронезависимый (то есть star guardian и Star Guardian - одинаковый логин). Также сделал бы список запрещенных логинов, таких как root, admin, moderator, support, helpdesk и т.п., которые можно использовать для социальной инженерии, чтобы представиться кем-либо из администрации сайта.
    Ответ написан
    Комментировать