Кирилл Горелов

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

вот самый полный список со списками, есть группировка по тематике и всё такое.
по плюсам, например, сразу несколько чатов нашлось поиском по странице
https://github.com/goq/telegram-list

"Run you fools!" (c)
Единственная причина связываться с Битриксом - это вендор-лок на его систему.
То, что они потроха своего чудовищного продукта называют модным словом "фреймворк" - это маркетинг и... только маркетинг.
Если вы готовы работать с фреймворком - берите фреймворк. Настоящий, нормальный фреймворк, как Симфония или Ларавель. А на копролит Битрикса даже не оглядывайтесь.

- Базовый репозиторий со всеми основными (одинаковыми) компонентами.
- Ru репозиторий, который подключает основные компоненты + отдельно те, которые индивидуально под Ru сегмент.
- En репозиторий, который подключает основные компоненты + отдельно те, которые индивидуально под En сегмент.

Аналогично и микро сервисы я бы организовал.

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

Здесь есть несколько ключевых технологий, которые используются для обеспечения этого:

Масштабируемость: Эти сервисы обычно используют облачные сервера, которые могут быть быстро масштабированы в зависимости от нагрузки. В современных облачных решениях, таких как AWS, Google Cloud, Azure и другие, можно автоматически добавлять или удалять серверы в зависимости от текущего количества пользователей и их действий.

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

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

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

Данные, которые покупатель прописывает в договоре, являются персональными данными? Если я заключаю договоры - я автоматически становлюсь оператором?

Если ты данные из договора ещё как-то электронно обрабатываешь - да.

Данные, которые потенциальный покупатель оставляет мне на сайте, чтобы я ему перезвонил или написал письмо - это персональные данные? Если есть кнопка обратного звонка и форма запроса, я уже оператор персональных данных?

В такой комбинации - скорее всего да.
Хотя вроде были случаи, когда суд считал, что нет.
Ключевой момент в том, что пользователь неиронично может захотеть ввести в эти поля свои ПД: личный номер, почту в которой транспортом написаны ФИО, и своё им.
Я бы уточнил у юриста или в РКН.

Если после звонка/письма я буду удалять запросы от клиентов - я перестану быть оператором персональных данных (при условии, что на предыдущие вопросы ответ был "Да")?

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

Данные клиентов, отправленные покупателями для целей тех.поддержки - это персональные данные и я становлюсь оператором?

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

Где-то мелькал коммент, что если данные собираются в рамках договора, то это не считается сбором персональных данных - так ли это?

Это так, но см п1 - если ты захочешь ещё как-то данные из договора использовать - ты станешь оператором.

Если ты сохранишь на компьютере скан договора - ты тоже будешь оператором.

Если это так, то я могу в предмете договора все эти случаи прописать и таким образом избежать превращения в оператора персональных данных?

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

Не собирай у клиентов ПД тоже.

Вы пытаетесь решить несуществующую проблему.
1. Нет никакой проблемы в том что два разных приложения (клиент и сервер) имеют разную нумерацию.
2. semver нужен только если у тебя есть какой-то контракт, который тебе нужно соблюдать. Если контракта нет - можно использовать просто номера релизов.

Есть же хороший паттерн для этого.
Dockerfile

FROM python:3.10-alpine
WORKDIR /app

ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

COPY ./src/requirements.txt .
RUN pip install --no-cache-dir -r /app/requirements.txt

COPY ./src .

Тут упаковываете в образ свой проект.

И в docker-compose собираете требуемые сервисы. Nginx, Postgre, Redis и т.д.
docker-compose

version: '3'
services:
  db:
    image: postgres:15-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    expose:
      - 5432
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}

  api:
    build:
      context: .
    command: uvicorn main:app --host 0.0.0.0
    ports:
      - 8080:8000
    environment:
      - DATABASE_DSN=${DATABASE_DSN}
    restart: always
    depends_on:
      - db

volumes:
  postgres_data:

И что бы руками каждый раз инфраструктуру не разворачивать пользуемся Github Actions, при взаимодействии с репозиторием он может прогнать тесты, собрать новый образ, залить все на прод сервер и развернуть.

ExecStart=/usr/bin/python3.7 -m uvicorn sql_app.main:app --host xx.xx.xxx --reload

Как вариант

let container = document.createElement("div");
let p = document.createElement("p");
container.appendChild(p);
let btn = document.createElement("button");
btn.innerHTML ='hhh'
btn.onclick = ()=>{console.log('hi')}
p.after(btn);

В силу некоторых обстоятельств не могу идти работать full-time

Тогда никак. Серьëзная разработка = командная разработка. Да и рост без команды очень медленный и ограниченный.

Давно была похожая проблема, на stackoverflow нашел решение, что нужно раздачу статики и апи делать отдельно.
Вот пример, из моего кода. Здесь без jinja2, но суть та же

app = FastAPI()
app_api = FastAPI()

app.mount("/api", app_api)
app.mount("/", StaticFiles(directory="static", html=True), name="static")

@app.get('/', response_class=HTMLResponse)
async def main_page():
    return HTMLResponse('index.html')


@app_api.post('/login', response_class=JSONResponse)
async def login(
    username: str = Body(...),
    password: str = Body(...)
):
    ...

В ASP.Net есть управление доступом на основе политик безопасности(Policy Based Authorization).

В политике описываются правила доступа к ресурсу(объекту, странице, контроллеру и тд). Сами правила в свою очередь могут состоять из абсолютно любых условий(роль, id, лунная фаза…)

Если я правильно понял Вашу задачу, то нужен примерно такой же механизм. Можете поискать подобные решения для php.

Вот ваша память: https://www.dns-shop.ru/product/6188d462bf2a3332/o...
Она на 2666.

Хм. Там как в банковской карте - последняя цифра контрольная. 9 цифр + 1.
Тоесть всего 1 млрд корректных номеров и 9 млрд некорректных которые никогда
никому не выдадут. Отключи в своей системе контроль этой цифры и бери рандомное
из диапазона вот этих некорректных.

Путаем причину и следствие.

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

Других причин нет.

Да, это картельный сговор. Да, это санкции-херанкции. Да, мозилла, гугл и M$ изначально не хотели добавлять российские CA в доверенные - а добавили бы - так с началом Донбасской спецоперации непременно бы выкинули.

В РФ есть CA. Просто, чтобы их сертификаты стали валидными - их корневые нужно добавлять в каждое устройство.

Есть два вида отечественных сертификатов:
1. Сертификаты с криптографией по ГОСТ (признаются как криптографическая защита) - сертификат выдается одним из аттестованных центров, поддерживается в Яндекс Браузер с установленным CryptoPro, криптография не совместима с международными стандартами.
2. Сертификаты Национального Удостоверяющего Центра - можно получить через Госуслуги, совместимы с международными стандартами и поддерживаются в любых браузерах, но только в российских браузерах (Яндекс Браузер, Атом) корневой удостоверяющий центр добавлен в доверенный, в остальных придется это сделать вручную.

Потому что выпуск публичных SSL-сертификатов зиждется на доверии всех участников удостоверяющим центрам. А нашим какое доверие?