Задать вопрос
  • С чего начать изучать game dev?

    @nrgian
    Проблема была как реализовать систему кустарного поиска пути, в юнити например есть готовая система с кратчайшим путем.

    Именно об этом я и написал, как о самой большой проблеме:
    Потом перейди на Пэкмена, там логику преследователей писать будет непросто.

    То, что что-то там есть в Unity - совсем не важно.
    Это довольно простая задача, как раз подходящая чтобы набить руку начинающему.
    Не нужно использовать Unity на этом этапе.
  • ИП. Графический дизайн. Paypal. Клиенты в США. Как обеспечить себе нормальный бизнес?

    @nrgian
    ipswitch,
    Платить налоги, платить взносы в фонды, даже если ничего не заработали

    Да ладно. Это платится как процент с заработка.
    Исключение - только т.н. фиксированный платеж (насколько помню около 30 000 в год), если ты ИП.

    За любое неверное движение есть риск словить блокировку счёта, спасибо финмониторингу.

    Финмониторинг включается от разового платежа в 600 000 рублей и выше.

    заморачиваться с транзитными счетами и валютным контролем

    первый раз разобраться - потом все примитивнейше.

    Есть риск поиметь необходимость покупать и обслуживать онлайн-кассу с ФН и ОФД.

    При отсутствие нанимаемого персонала, то есть при работе в одного - не нужно.
  • Заработок с фриланса на PayPal, как быть?

    @nrgian
    nathantothe,
    люди говорят пейпал не трогают тк у них своя система и они итак процент нормальный берут.


    при чем тут сколько Палка себе процентов берет?
    если Палка не платит за вас с этих 13% налога НДФЛ (а тогда она должна брать больше 13%, ведь не за свой же счет) - то это все так же незаконно

    не трогают, потому что суммы небольшие/нерегулярные
  • Активация программы через привязку к железу, как?

    @nrgian
    Пытаюсь узнать номер процессора, материнской платы и т.д. НО ! Кажды антивирус ругается на это ! Почему ?


    Нам на кофейной гуще погадать как именно ты это делаешь?
  • Как шифровать данные в облачное хранилище BlackBlaze?

    @nrgian
    Если я правильно понял, в Blackblaze B2 не шифруются хранимые данные.

    А это и не важно. Если Backblaze шифрует, то он и может расшифровать. Вне вашего ведома.
    То, в каком виде это хранится на сервере - тоже неважно, ведь доступ, кроме вас, гипотетически все равно никто не получит.

    А во время передачи там все шифруется.
    То есть по пути не перехватить.
  • Могут ли два микросервиса выполняющие схожую безнес логику, обращаться к одной базе данных?

    @nrgian
    razer96,

    А чем с точки зрения производительности будет лучше, если будет больший трафик идти на один сервис?

    Если я верно понял то, что вы собираетесь создать, то основная нагрузка у вас будет прежде всего на СУБД, а вовсе не на те микросервисы, что будут принимать внешний трафик.

    От того, что перед СУБД у вас будет стоять 100 микросервисов - система не будет работать лучше, ибо самым узким местом останется база данных, которая одна-единственная.

    Одним из способов хоть каким-то способом снять с неё нагрузку будет - разделить эту БД по функционалу. Тогда можно будет размещать такие меньшие по размерам отдельные мини-БД на отдельных физических серверах.

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

    При этом, если вам для выполнения одного-единственного запроса понадобится собрать данные с нескольких таких мини-БД и объединить их, то ключевым моментом является возможность параллельного независимого выполнения нескольких запросов к нескольким этим мини-БД (напрямую в СУБД или опосредованно через микросервисы).

    Если же логика вашей системы заставит запросы к таким мини-БД придется делать последовательно - проблема по производительности останется.
  • Могут ли два микросервиса выполняющие схожую безнес логику, обращаться к одной базе данных?

    @nrgian
    razer96,
    А чем с точки зрения производительности будет лучше, если будет больший трафик идти на один сервис? Из описанной мною ситуации, думаете это будет лучше?


    По описанной вами схеме:

    В кратце. Есть один сервис( дадим ему условное имя А ) на котором крутится сервер Socket.io, и он обрабатывает все ивенты сокета и частично ему нужен доступ к базе данных со всей логикой связанной с комнатами?
    И есть второй сервис( дадим ему условное имя В), который полностью реализует бизнес логику комнат и их функционала.


    Вижу только одно достоинство:

    Что можно масштабировать количеством отдельно сервисы А и сервисы B.
    То есть можно сделать очень много А и очень мало В или же наоборот.

    Однако по характеру описанной вами нагрузки (из того, где именно и какой функционал реализован) видно, что при таком разделении вы имеете кучу накладных расходов.

    Но при этом, насколько я понял из вашего описания, если А+В будут работать в одном большом сервисе - этих накладных расходов не будет.

    Да, вы не сможете масштабировать отдельно А или отдельно В.
    Но если в ненагруженном состоянии А/В жрут мало ресурсов - то это неважно.

    Другими словами:

    • Создали вы сервис А+В.
    • Функционал компоненты А в таком А+В потребовал отмасштабироваться до 100 экземпляров.
    • При этом автоматически будет отмасштабирована и компонента В, так как она тоже часть единого сервиса А+В. Она будет отмасштабирована до 100 экземпляров, хотя ей этого и не надо было бы, а хватило бы и 5 экземпляров.
    • При этом, если компонента В всегда и безусловно откусывает, к примеру, по 2 гигабайта оперативной памяти вне зависимости от нагрузки - разумеется, в данной ситуации это будет разбазариванием ресурсов.
    • Вам потребуется 2*100 гигабайтов, хотя хватило бы 2*5 гигабайтов.
    • Однако, если компонента В не резервирует под себя много ресурсов (тех же ресурсов оперативной памяти), пока они ей реально не понадобятся, то такой проблемы не будет.

  • Могут ли два микросервиса выполняющие схожую безнес логику, обращаться к одной базе данных?

    @nrgian
    Andrey Shatokhin,
    А если сделаете с общей бд - так и не упростят они у вас ничего.

    Строго говоря, если предположить, что сервис выполняет какую то сложную обработку внутри себя, без обращения к внешней СУБД - то как раз упростят.

    Но это маловероятно.

    Скорее всего, затык будет именно в обращении к БД, как вы и написали.
  • Могут ли два микросервиса выполняющие схожую безнес логику, обращаться к одной базе данных?

    @nrgian
    razer96,

    Но если оно того требует? Просто например один сервис должен держать до 5000-10000 одновременных соеденений по WebSocket, и если этот же сервер еще будет и обрабатывать бизнес логику принимая примерно 100-200 http запросов в секунду, хотя данную бизнес логику может выполнять и другой сервис, так как большая часть этой логики ни как не должна напрямую взаимодействовать с Socket.io сервером. Как быть тогда?

    Это всё решаемо и в монолитной архитектуре.
    И даже еще более эффективно по возможностям той же аппаратуры на удержание высокой нагрузки.

    Вы пытаетесь резать на микросервисы вертикально - по этапам обработки запроса в длинной цепочке.

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

    @nrgian
    razer96,
    Я просто читал о подобных исключениях, когда два микросервиса обращались к одной базе

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

    и идея было именно в том, что у них была тесно связанная бизнеслогика.

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

    @nrgian
    drboboev,
    Ерлан Ибраев,
    grinat,
    можно, как json, если данных мало и не надо фильтровать, то все будет ок, иначе не ок.

    В PostgreSQL тип данных JSONB, не путать с JSON.
    Можно фильтровать, там индексы сами создаются.
    "Умное" индексирование JSONB
  • Почему всем так нужен Doctrine, если он много не умеет?

    @nrgian
    что долгое время он(а) считалась самым сложным (или одним из самых сложных) PHP-фреймворков, с довольно высоким порогом вхождения, что в свою очередь возводило её в ранг некоего "идола", отличающего "опытного" разработчика от тех, кто в силу различных причин Symfony осилить не смог (или не захотел).

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

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

    Но на фоне других серьезных фреймворков, - упомянутый вами не сложен.
  • Starlink от SpaceX - прощай звездное небо, кошмар астронома?

    @nrgian
    Могу предположить что падать будут через полгода

    Да ну:

    Спутник Космос-2251 запущен в 1993 году. Выведен из эксплуатации спустя 2 года. Однако это не означает, что он "упал".

    Ибо в 2009 году состоялось столкновение спутников Космос-2251 и Iridium 33
  • Starlink от SpaceX - прощай звездное небо, кошмар астронома?

    @nrgian
    Вероятность врезаться в такой спутник примерно такая... если бы на планете было не 8 миллиардов человек, а 12 000 ... всю жизнь искать кого-то и не встретить ни одного человека.


    Как-то вы вольно с вероятностями обращаетесь.

    https://www.mk.ru/science/2016/05/13/kosmicheskiy-...
    Около 10 лет назад я проводил расчеты — и получалось, что на расстоянии в 400 км от Земли вероятность того, что кусок мусора пробьет насквозь стенку космического корабля, составляет примерно 1 инцидент на 15 лет


    Это пробить. А вероятность просто встретится куда как выше:

    Астронавт Тимоти Пик выложил 12 мая 2016 в интернет снимок окна иллюминатора Международной космической станции с трещиной, которая образовалась из-за космического мусора. Пик пояснил, что иногда такое происходит
  • Почему не могу смотреть трансляцию на твиче даже в качестве 160?

    @nrgian
    Yan, от вас это не зависит.

    у youtube много местных кэширующих серверов.
  • Для чего все-таки нужны интерфейсы?

    @nrgian
    makarychev13,
    сейчас бы для такого вопроса go приплетать. Там вообще интерфейсы хуже всего реализованы (ИМХО)

    Что-то конкретное имеете ввиду?

    Имхо, интерфейс вещь настолько простая или, даже можно сказать, примитивная, что сделать там что-то лучше или хуже - невозможно.
  • Для чего все-таки нужны интерфейсы?

    @nrgian
    Да какой это костыль.
    Вполне себе полезная вещь.

    Как пример, есть и в других языках - в Java, где наследование множественное имеется; в Go, где классов вообще нет.
  • Вы часто делали тестовые задания? Как относитесь к ним?

    @nrgian
    За мою историю абсолютно все кто выдавали мне тестовые задания

    В ваших фантазиях?
    Вы же еще студент, судя по ответам.
  • Как запретить пользователям доступ к txt файлу?

    @nrgian
    Александр,
    Как я знаю, в файле htaccess можно запретить доступ к файлу, только вопрос в том, будет ли работать при этом с ним php и что за команда.

    PHP работает с файлами.
    А htaccess запрещает доступ по ссылкам веб-сервера.

    Это вообще о разном.

    Просто разметить файлы за пределами каталога DocumentRoot
  • Как передавать данные с различных датчиков?

    @nrgian
    Методом "POST, в БД, браузером" - это плохой подход.
    Датчики с полноценным доступом к http - жрут уйму электроэнергии, вы замучаетесь батарейки менять.