alekssamos

<input type="text" id="textarea">

// Код воркера в виде строки
const workerCode = `
  self.onmessage = (event) => {
    const largeArray = event.data;
    
    // Выполнение тяжелой обработки массива
    for (let i = 0; i < largeArray.length; i++) {
      // Например: largeArray[i] = someProcessing(largeArray[i]);
      largeArray[i] *= 2; // Пример обработки: удваиваем каждый элемент
    }

    // Отправка обработанных данных обратно в главный поток
    self.postMessage(largeArray);
  };
`;

// Создание Blob из строки с кодом воркера
const blob = new Blob([workerCode], { type: 'application/javascript' });
// Создание объекта Worker из URL на Blob
const worker = new Worker(URL.createObjectURL(blob));

// Обработка сообщений от воркера
worker.onmessage = (event) => {
  const processedArray = event.data;
  console.log('Обработанный массив:', processedArray);
  // Можно обновить интерфейс или использовать данные
};

// Пример массива для обработки
const largeArray = new Array(1e6).fill(15);

function debounce(func, delay) {
  let timeout;
  return function(...args) {
      clearTimeout(timeout);
      timeout = setTimeout(() => func.apply(this, args), delay);
  };
}

const handleInput = debounce(() => {
  worker.postMessage(largeArray);
}, 300); // Вызываем через 300 мс после окончания ввода

// Пример добавления обработчика для textarea
textarea.addEventListener('input', (event) => {
  console.log(event.target.value);
  handleInput();
});

На первом скрине, похоже, атака через "Stacked Queries". Хацкер надеется, что вы не отфильтровали входящие данные.

Допустим у вас из бройзера приходит ID товара. И в программе запрос:

SELECT * FROM products WHERE productid={нефильтрованный ID};

Хакер отправляет вместо ID товара следующее:

1; SELECT pg_sleep(25)

В результате получится запрос:

SELECT * FROM products WHERE productid=1; SELECT pg_sleep(25);

И ваш сервер при каждом таком запросе будет спать 25 секунд. И порядочное количество таких запросов в случае удачи атаки смогут повесить вам там всё.

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

window.addEventListener('DOMContentLoaded', function() {
    let game = localStorage.getItem('game');
    document.getElementById('game').innerHTML = game;
});

Проверка с помощью атрибута pattern срабатывает непосредственно перед отправкой формы. Кроме того, это не запретит ввод символов, отличных от цифр, а лишь покажет уведомление в случае несоответствия. Вашу же задачу можно решить несколькими способами.
Первый вариант: <input type="number" />. Из особенностей: он допускает ввод некоторых символов, отличающихся от цифр (например, "+" и "e").
Второй вариант: перехватывать событие onChange у поля ввода:

const [value, setValue] = useState('')

const handleInputChange = (e) => {
  setValue(e.target.value.replace(/\D/g, ''))
}

<input value={value} onChange={handleInputChange} />

в Pyrogram документации не нашел подобного

Все верно, Pyrogram не настолько гибкий по прокси, в сравнение с Telethon. Используйте внешний менеджер подключений/проксей и не будите зависеть от конкретной библиотеки, например:

import asyncio
from pyrogram import Client
from pyrogram.errors import PyrogramError

class ProxyManager:
    def __init__(self, app, max_retries=5, retry_delay=1, proxy=None):
        self.app = app
        self.max_retries = max_retries
        self.retry_delay = retry_delay
        self.proxy = proxy
        self.client = None

    async def connect(self):
        for attempt in range(1, self.max_retries + 1):
            try:
                print(f"Connection attempt #{attempt}")
                self.client = Client(**self.app, proxy=self.proxy)
                await self.client.start()
                print("The connection was established successfully.")

            except PyrogramError as e:
                print(f"Connection error: {e}")
                if attempt == self.max_retries:
                    print("The maximum number of connection attempts has been reached, stop!")
                    break

                await asyncio.sleep(self.retry_delay)

    async def disconnect(self):
        if self.client:
            await self.client.stop()
            print("Connection is closed.")

app = {
    'api_id': 'YOUR_API_ID',
    'api_hash': 'YOUR_API_HASH',
    'session_name': 'your_session_name'
}

proxy = {
    'scheme': 'http',  # or 'socks5'
    'hostname': 'your.proxy.hostname',
    'port': 1080,
    'username': 'user',
    'password': 'password'
}

# test run
async def main():
    manager = ProxyManager(app, max_retries=3, retry_delay=2, proxy=proxy)
    await manager.connect()
    await manager.disconnect()

asyncio.run(main())

Обнаружил некую защиту "на лоха", а значит request и обычный selenium не справятся, буду использовать selenium + selenium-stealth (пример от сюда) + chrome + socks5 (рабочий, на момент теста):

import time
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.chrome.options import Options
from selenium_stealth import stealth

proxy = '45.132.75.19:23820'

options = Options()
options.add_argument('--proxy-server=socks5://' + proxy)
options.add_argument("--disable-blink-features=AutomationControlled")
options.add_argument("window-size=1920,1080")
# options.add_argument("--incognito")
options.add_argument("--disable-extensions")
options.add_argument("--disable-plugins-discovery")
options.add_argument("--start-maximized")
options.add_experimental_option("excludeSwitches", ["enable-automation"])
options.add_experimental_option('useAutomationExtension', False)

executable_path = './chromedriver-121.0.6167.85.exe'

service = Service(executable_path=executable_path)
driver = webdriver.Chrome(service=service, options=options)

stealth(driver,
        languages=["en-US", "en"],
        vendor="Google Inc.",
        platform="Win64",
        webgl_vendor="Intel Inc.",
        renderer="Intel Iris OpenGL Engine",
        fix_hairline=True,
        run_on_insecure_origins=True,
        user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.85 Safari/537.36',
        )

try:
    driver.get('https://allegro.pl/kategoria/laptopy-491')
    time.sleep(30)
    print(driver.page_source)
finally:
    driver.quit()

Chromedriver качать здесь, он должен совпадать с мажорной версией Вашего Chrome браузера, который будет использовать Selenium.

1. Вебсокеты - это сложновато.
2. Вебсокеты на PHP - вдвойне сложно. Проблема в том, что PHP задуман как скриптовый язык, т.е. скрипт выполняется заканчивает свою работу. А вебсокет - это постоянное соединение, т.е нам надо, чтобы программа постоянно крутилась в фоне. Вебсокеты можно реализовать на PHP, но, как персонально мне кажется, проще будет выучить Go )) , или же, как в ответе уважаемого Артём , сделать сервер на ноде.
3. Если ваш чат не такой супер-функциональный, как чат в мессенджерах, то вместо вебсокетов можно обойтись SSE (Server Sent Events). SSE так же требует постоянного соединения, но всё работает через HTTP, и это ну прямо намного проще. Единственный недостаток - это то, что SSE работает только в одну сторону: от сервера в браузер. Т.е. запросы из браузера можно получать обычным POST запросом, а отдавать обратно информацию уже через SSE.

С SSE есть два пути:
1. Написать сервер самому, используя какую-то простую библиотеку вроде этой https://github.com/hhxsv5/php-sse
2. Но я бы сделал ещё проще. Есть такой великолепный проект под названием Mercure https://mercure.rocks
Это отдельный сервис на Go, задача которого как раз поддерживать SSE соединение и отправлять сообщения в браузеры. Сервис сидит в фоне, а браузеры подписываются на события через EventSource буквально в три строчки, как описано тут https://mercure.rocks/docs/getting-started
Прелесть этого в том, что для того, чтобы отправить сообщение всем браузерам из кода на PHP, вам надо просто сделать обычный POST запрос на специальный адрес этого сервиса Mercure с телом самого сообщения и его id. Т.е. вам не надо делать никаких долгоживущих процессов на PHP, всё будет работать как раньше.

Т.е. подытожим:
- Браузеры пользователей подписываются на события в Mercure
- Пользователь 1 отправляет текстовое сообщение обычным POST запросом на обычный PHP сайт.
- PHP сайт получает этот POST запрос, определяет, что его надо отправить Пользователю 2, и отправляет соответствующее сообщение обычным POST запросом в сервис Mercure
- Mercure отправляет сообщение Пользователю 2 через SSE, на которые он подписан.
- Сообщение появляется у него на страничке

Главная сложность в том, что для каждого исходника требуются индивидуальные настройки.
Амплитуда сигнала это одно, а воспринимаемая громкость - совсем другое.
В индустрии это называют RMC, не понимая порой что это значит.
Многие понимают RMS как воспринимаемую громкость в то время как это всего лишь среднеквадратичное значение уровня сигнала.
Ухо (восприятие) работает несколько иначе. Как именно хорошо описано в учебнике Алдошиной
А порой даже в рамках одного трека параметры требуется автоматизировать.
В этом случае повезло. Получилось без автоматизации, но это просто случайность.
Результат

Я использовал плагины waves:

В вашем JSON 'е нет ни поля id, ни Css стилей.

А так, чтобы получить из них нужные вам поля. Достаточно просто импортировать файл JSON и пройтись по нему , допустим, через forEeach

import myJson from './example.json'
//Some code.....
myJson.forEach(element => console.log(element.id));

Как-то так?
Когда запускаем одно аудио, мы отключаем остальные, кроме текущего

<audio id="audio1" src="music.mp3"></audio>
<audio id="audio2" src="music2.mp3"></audio>

const audioElements = Array.from(document.getElementsByTagName('audio'));

  const stopOtherAudio = (currentAudio) => {
    audioElements.forEach((audio) => {
      if (audio !== currentAudio) {
        audio.pause();
        audio.currentTime = 0;
      }
    });
  };

  audioElements.forEach((audio) => {
    audio.addEventListener('play', () => stopOtherAudio(audio));
  });

Проблема в неполной документации VK REST API. В ней ничего не сказано про то-что по каким-то причинам сервису по загрузке видео не нравится Transfer-Encoding: chunked

Аналогичные сервисы VK по загрузке фото, аудио или документов пока не замечены в подобном.

После модификации кода использующего java httpclient и указанием конкретного Content-Length (что выключает chunked режим) - все заработало.

Надеюсь кому-то будет полезно.

Зависит от компании. бычно фронт занимается своими делами, а бэк своими.

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

В худшем случае, это поддержка какого-нибудь сайта, где rest api и не пахнет.

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

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

Бэк часть:

• Не рабочая концепция проекта.
  
• Не профессиональная архитектура. Обычно используется архитектура вида валидатор-контроллер-сервис-репозиторий. В данном случае это был бы ProductsService (директория products + класс в ней ProductsService). Также в этом сервисе лежал бы класс репозитория этого сервиса, где хранились бы методы запросов к базе данных. Запрос бы попадал в валидатор, затем в контроллер, оттуда в сервис, а сервис бы вызывал соответствующий метод в репозитории.
  
• База данных. Нет внешнего ключа у продукта к категориям.
  
• Нет типизации. Это нужно для статичных анализаторов, проверяющих код на ошибки. Пример public string $name - как свойство класса. public function getById(int $id) - как метод класса
  
• Нет валидации запроса. Например, что поля формы должны не содержать определённые символы, или быть конкретного типа. (Очистка от тэгов , используемая в модели, должна находится ещё до того как запрос попадёт в контроллер.)
  
• Коды и текстовки раскиданы по разным файлам. Всё должно лежать в одном файле, классе, куда будут обращаться все классы за результатом.
  
• Отсутствует MVC. В каждом файле создаётся новый класс, и дескриптор подключения, хотя это повторяющееся действие нужно вынести в отдельный класс.
  
• Коды ответа. Не соответствуют действительности. При создании не нужно возвращать 200. 200 подразумевает, что в ответе есть дополнительные данные. Правильный вариант 201
  

Фронт часть:

• JQuery это рудимент.
  
• Bootstrap не используется, если есть нормальный отдел разработки.
  
• Стили страницы не разбиты на верхнюю и нижнюю части.
  
• Не используется отложенная загрузка скриптов.
  
• Вместо файлов JS для каждого типа CRUD достаточно одного JS файла
  
• HTML код в JS. Загрузка JS это одна из самых затратных операций. Чем больше размер файла, тем выше время загрузки. Что сильно отщутимо на мобилке.
  
• Везде используется POST запрос. В restfull api POST для создания, GET - для получения, DELETE - для удаления, Patch - для обновления части модели, PUT - Для обновления всех полей модели.
  

Этого курса достаточно, чтобы сделать востребованный на рынке restfull api проект.

Перевод и не нужен по сути. По ссылке, которую вы привели, есть таблица кодов погоды. Достаточно будет перевести их вручную и подобрать иконку, а в коде ориентироваться на ID.

Например, такой код сейчас вернет код 721:

weather = mgr.weather_at_place('London,GB')
print(weather.weather.weather_code)

По таблице это `haze` (туман). Пусть ему соответствует такой смайл: U+1F32B

Дальше уже можно сделать свой словарь с юникодом и ID погоды. Где ключи словаря - ID, а значения - юникоды.

weather_emojis = {721: '\U0001F32B', 500: '\U00001111'} # и тд

И отправлять уже так:

emo = weather_emojis[w.weather_code]

В результате это уже одна строчка кода (ну плюс еще одна на словарь), и полная независимость от языка