ThunderCat

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

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

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

У меня все грузится на ура, при том что я нахожусь за пределами РФ... Возможно временные глюки, терзайте техподдержку.

Подозреваю что вы криво пытались объяснить что вам нужно событие смены вкладки?

document.addEventListener("visibilitychange", function() {
    if (document.hidden){
        console.log("Browser tab is hidden")
    } else {
        console.log("Browser tab is visible")
    }
});

Нет первый запрос вообще не работает.

Не бывает "не работает", если код присутствует в странице - он исполняется. Соответственно в результате будет либо ошибка в консоли, которую можно посмотреть, либо результат выполнения, который вы не видите, по тому что не все учли в коде.
В первом случае - смотрите ошибки, исправляйте.
Во втором случае - используйте отладчик или хотя бы console.log для отслеживания состояния переменных и выполнения кода.
Так же можно проверить что ваш код отправляет на сервер и что принимает с сервера в разделе нетворк инструментов разработчика.

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

Что делать в таких случаях? Во первых - сделать var_dump($_SESSION) и посмотреть что там лежит. Подозреваю что нужных ключей в этом массиве нет (или же они не там где вы их ищете, ну или называются иначе). Так же, неизвестно как вы делаете логин, и что при этом попадает в сессию (кстати - зачем хранить пароль в сессии - отдельная загадка). Рекомендую провернуть ту же операцию - проверить что в сессии после логина, ну и в коде логина убедиться что туда добавляются эти ключи.

https://towardsdatascience.com/8-examples-to-query...

Шорт теги?

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

Файлы при нажатии на раздел хочу отображать в попап окне.

Какого типа документы вы хотите размещать? С картинками и попапом еще ок, что будет с, например, вордовским доком/ехелем?

По описанию сильно похоже на вики движок.

Можно я внесу немного конструктивной критики в ваш вопрос, ну и сделаю некоторые выводы, возможно вам они будут полезны...

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

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

Общая концепция выглядит приблизительно так:
Будет много разных баз данных, в которых будет храниться информация разного типа, текстовая, . Каждая база будет содержать информацию по разным темам.

Информация графическая, видео и аудио типов чаще всего не хранится в бд. Если вы не программист/архитектор IT структур - поручите вопросы архитектуры и структурирования данных кому-либо из команды, кто в этом разбирается (если таковые есть).

Отдельно будет полнотекстовая поисковая система объединяющая информацию из всех источников.

В принципе не особо зависит от стека, тут больше архитектурно-проектировочная задача.

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

Тоже самое - больше архитектура, нежели стек.

Посоветуйте пожалуйста какой стек технологий для разработки выбрать, с учётом некоторых условий:
- Язык(и) программирования современные и содержащие подробную информационно-документальную базу и популярные сообщества поддержки.

На сегодняшний день есть 4-5 хорошо распространенных языка, используемых в вебе: пхп, ява, жс, питон, в меньшей степени c#, руби, голанг, остальные больше экзотика, нежели мэйнстрим.

- Высокая производительность и многопоточность.

Которая в вебе не особо нужна, хотя практически все вышеперечисленные языки в той или иной мере многопоточность поддерживают. Опять же - сразу "видны уши" вашей недостаточной компетентности в вопросах разработки высоконагруженных проектов. Дело в том что в 99% случаев код именно языка программирования особо не нагружен. Больше всего процессорного времени будет съедаться запросами к бд и внешним сервисам. Код просто прослойка между фронтом и бд, чаще всего просто выполняющая задачи CRUD прослойки.

- Простая масштабируемость.
- Актуальность на ближайшие 2-3 года.

Везде подходит

- Интеграция с проектами написанными на других языках.

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

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

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

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

Редко когда приходится настолько сильно заморачиваться. Особенно с блоками. Очевидно что основное отличие слайдера 1 от 2 - количество "строк", "slider-two-line" например. Так же можно именовать по паренту, типа "slider-in-header" "slider-in-news".

document.write так то устаревшая фигня, использовать не рекомендуется. Обычно создают контейнер для добавления элемента, или добавляют в body в конец через createElement и append().

Если на сайте есть форма с чувствительными данными (пароль, номер карты и тд) хром проверяет наличие похожих доменов и может посчитать ваш сайт фишинговым, на основании похожести.

Для такой задачи вообще не принципиально. В данном случае технические характеристики никакой роли не играют, так как функционала по сути нет. Берите любую цмс, по предпочтениям можно определиться только поработав с ними. Если есть опыт работы с какой-то конкретной цмс - берите ее, на качестве конечного результата это никак не скажется (по теореме Эскобара). Разве что если вы найдете готовый подходящий шаблон под конкретную цмс, есть смысл уже с ней тогда работать.

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

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

Так, давайте прикинем что нам нужно для реализации. Программная часть собственно нас не сильно интересует, так как на фоне прочих затрат найм какого-нибудь Линуса Торвальдса на пару месяцев вообще теряется в общей сумме.

1) Хранилище. По примерным оценкам в мире в цифровом виде около 500 000 000 оригинальных музыкальных композиций. Учитывая ремиксы и каверы - можно смело брать миллиард. Средний вес композиции среднего качества - 5 Мб. То есть порядка 5 петабайт, если хранить не в лучшем качестве. Учитывая что это должно иметь какое-то резервное хранение (у нас тут серьезный сервис все-таки), умножаем на 2 (10 петабайт). При стоимости около 2 центов за гиг в месяц, 10 000 000 Гб * $0,02 = $200 000 в месяц хранение. Ну, бюджетненько в целом.

2) БД, которая хранит данные обо всех этих композициях. Стоимость хранения будет поменьше, но думаю к 20-50К все равно где-то выйдет.

3) Другой вопрос - где брать эти данные, так как не все музыкальные файлы содержат полное описание композиции. На перебор 1 миллиарда записей и сортировки их по жанрам, альбомам, исполнителям, дате выпуска и т.д. уйдет некоторое время. Допустим 50% композиций будут иметь нормальное описание, остается все те же 500 миллионов композиций на обработку. Пусть на каждую понадобится 2 минуты работы, внести данные в поля (хотя их еще как-то найти надо, но допустим), тогда получим 1 миллиард минут. Это 1900 лет работы, или 16 666 667 часов. Час работы самого дешевого индуса - 3 бакса/час. 16 миллионов * 3 - давайте округлим до 45 миллионов. Даже если сократить этот пункт в 10 раз - выйдет под 4 миллиона. Рабский труд сегодня дорог как никогда...

4) Теперь платформа которая будет всем этим ворочать, так как у нас в сервисе должны же какие-то пользователи завестись вроде. Ну, на сервера можно смело отложить небольшую сумму, тоже где-то 20-30К, для начала сойдет.

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

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

По итогу на год:
$200 000 * 12 = $2 400 000 хранилище
$20 000 * 12 = $240 000 бд
$20 000 * 12 = $240 000 сервера приложения
$4 000 000 работы
Итого: чуть меньше 7 миллионов баксов.

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