Aragorn

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

print(f'{(10 + 20) / 100:.40f}')  # 0.2999999999999999888977697537484345957637
print(f'{0.1 + 0.2:.40f}')  # 0.3000000000000000444089209850062616169453
print(30 / 100 == 0.1 + 0.2)  # False - результаты отличаются!

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

# вывести значения переменных rub и kop2 
# как числа с плавающей точкой (f), 
# округлив их до 0 знаков после запятой.
print(f'{rub:.0f} {kop2:.0f}')

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

total_sum = 1234  # тыт ты рассчитываешь сумму в копейках, я написал число для простоты
rub = total_sum // 100  # оператор // выполняет деление нацело, отбрасывая остаток
kop = total_sum % 100  # оператор % выполняет нахождение остатка от деления
print(rub, kop)  # и rub и kop - целые числа, поэтому погрешности от плавающей точки нет

Как я понял, это ты и пытался сделать, просто не осилил нагуглить оператор деления с остатком.

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

from decimal import Decimal
x = Decimal(30)
print(x, x / 100)  # 30 0.3
print(Decimal('30') / 100 == Decimal('0.1') + Decimal('0.2'))  # True - результат один и тот же!

Думаю, в твоём случае лучше подойдёт вариант 2.

Нужен ли javascript для WEB пентестера?

Нужен, для поиска уязвимостей, анализа клиентской логики, обхода ограничений (например, формы), изучения скрытой информации в коде и манипуляций с dom. Это помогает выявлять xss, инъекции и другие проблемы безопасности.

Нужно ли WEB пентестеру знать еще и WEB? Я имею ввиду те знания, которыми обладает стандартный WEB разработчик (помимо языков программирования).

Базовый набор:
- html/css для понимания структуры и стилей веб-приложений.
- http/https, куки, заголовки, cors, rest и сокеты.
- Основы OWASP Top 10 (XSS, CSRF, IDOR и др.).
- Браузерные DevTools, Burp Suite, ZAP, Postman.
- Базово популярные библиотеки и фреймворки (react, vue, angular).
- Методы минификации и обфускации js кода, а так же способы его анализа.

Что-то последнее время стало много вопросов на эту тему...

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

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

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

К сожалению, плюсов не бывает без минусов :) Хотелось бы о них тоже поподробнее - не чтобы отговорить, а чтобы предупредить.

- Цена, комплекутха, ЗиП. Новое серверное железо очень дорогое. Сервак за пол-лимона - это как здрассьте. "Для себя" обычно берут бу железо. Это довольно распространенный метод, так что существуют специальные конторы, торгующие бу серверным железом. Насколько оно старое? Обычно не моложе пяти лет. Почему пяти? В крупных конторах есть регламенты, по которым железо списывается по истечении определенного срока, обычно он пять лет. Списывается, независимо от состояния, даже если оно идеальное. Бу сервер можно прикупить за вполне приемлемые деньги (разумеется имея в виду, что винты нужно брать новые и не десктопные, а именно рейдовые). Комплектуху и ЗиП покупать можно в тех же конторах.

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

- Шум. такого понятия как

тихий серверный шкаф

не существует. От слова совсем. Потому что шкаф - для серверной. Даже самый тихий сервер (а я подбирал именно по "тихости") даже при самых низких оборотах кулера (в BIOS - 4500 об/мин) - довольно заметно шумит. Кроме того, если температура повышается, сервер автоматически кладет на настройки BIOS и повышает скорость вращения кулеров - в итоге у меня сервер в людбое время устойчиво негромко гудит и периодически взвывает - потому что перегревается.

- Комфортная температура. Для сервера и человека - она разная и поэтому запросто получится, что Вам придется выделить серверу отдельную комнату :D

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

- Изнашиваемые части. Про ЗиП было уже сказано - так вот, не забывайте, что сервер содержит части, которые ломаются :) Кулеры, винты - все это нужно будет покупать :)

- Интернет-канал. Для физиков как правило flat-rate не предоставляют (ну либо заломят, как с юрика), поэтому держать там нагруженный сайт Вы не сможете - он будет адово тормозить. Хотя обычный сайт работать будет (если пров дает белые IP).

- Анти-вирус, анти-ддос, анти-спам, анти-все-остальное. Все это придется делать самому либо просто забить. Разумеется, профессиональному админу это сделать несложно.

- Настройка, резервное копирование. Фактически повторение предыдущего пункта - спихнуть нее на кого, сами, все сами...

- Изменить IP практически невозможно, уж не говоря о его регулярной смене.

На мой взгляд, длина пути здесь не виновата. Вы эту папку средствами же винды создали, она существует, вы её видите, можете с ней выполнить какие-то действия - значит, скорее всего, она корректна.
Замедлять работу проводника могут разные факторы. Вот первое, что приходит в голову:
1) Проблемы с диском. Начиная с того, что он просто медленный (особенно, если это hdd), заканчивая его неисправностью. Проверить диск, как минимум посмотреть SMART.
2) Проблемы с контекстным меню. Туда прописываются программы все, кому не лень. Дальше может быть, что какая-то конкретная программа медленно работает с большими списками файлов. Или их (программ) просто очень много. Ещё бывает, что и программы-то уже нет, а битая ссылка на неё в меню осталась - тоже к тормозам приводит. Посмотрите, всё ли в контекстном меню Вам действительно нужно. Для работы с контекстным меню есть специальные утилиты.

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

Твоя цель - оффер, и все посторонние мысли о справедливости, какая компания, какое тестовое и т.д. Они только отвлекают и мешают.

когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно

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

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

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

Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.

Инкапсуляция защищает не от хакеров, а от неправильного использования объектов.
Как пример - у тебя может быть класс "Заказ" и у него может быть какой-то статус (оплачен/ждёт оплаты/отменён итд).
При этом у тебя могут быть правила типа: уже оплаченный заказ не может стать вдруг неоплаченным, а отменённый заказ нельзя взять обратно в работу.
Тогда логично будет сделать поле статуса приватным (не доступным для изменения извне напрямую), а менять его только через методы, где будет происходить вся валидация.
(В некоторых языках такие правила принято описывать на уровне типов, чтобы даже валидаций никаких было делать не нужно)

Приватные поля объекта - это его состояние.
Методы объекта - это способы его использования.

Если у тебя в объекте появляется поле x и методы getX / setX (или авто геттеры/сеттеры в C#), то значит, что у тебя и нет явных причин делать это поле приватным, кроме соблюдения общепринятых соглашений.

Переписать код инициализации приложения из оконного режима в полноэкранный. Либо добавить действие для F11 в меню и его код:
https://yandex.ru/search/?text=Python+Tk+fullscreen

В файле .\Lib\idlelib\editor.py в класс EditorWindow добавить функцию

def toggle_fullscreen(self, event=None):
        self.state = not self.state  # Just toggling the boolean
        self.top.attributes("-fullscreen", self.state)
        return "break"

И где-то до self.top = top = вставить self.state = False и после
вставить self.top.bind("<F11>", self.toggle_fullscreen)

Если надо меню скрыть - то гуглите как и скрывайте в этой же функции.

С Олиферов.

Сам спросил, сам и отвечу.
Лишний раз подтвердилась народная мудрость, чтобы найти ответ, надо правильно сформулировать вопрос. Гугл помог найти решение по запросу "busybox wget is shitty". Я не силён в английском, поэтому не стану углубляться семантику этих слов. Кому надо, тот сам поймёт.

Теперь ближе к теме.

У busybox wget есть давняя неисправнось в некой сущности "Support HTTPS using internal TLS code". Попросту говоря эта часть безнадёжно устарела и не работает в 2025 году.
Решение проблемы:
Скомпилировать busybox с отключённой опцией

-> Networking Utilities
    -> wget (41 kb) (WGET [=y])
      FEATURE_WGET_HTTPS [=n]

и со включённой опцией "Try to connect to HTTPS using openssl"

-> Networking Utilities
    -> wget (41 kb) (WGET [=y])
      FEATURE_WGET_OPENSSL [=y]

И ещё добавить алиас:
alias wget='wget --no-check-certificate'
Тогда busybox-овский wget станет сам без лишних пинков работать с https.

Почему так? Ве́домо только разработчикам busybox.

Не индексирует или не ранжирует?
Собственно, Google в последние годы очень обленился в принципе. Сканирование, обработка, ранжирование данных – достаточно затратные процессы, и тратить деньги компания явно не очень хочет. Там сейчас вообще всё очень медленно и трудно, так что при отсутствии явного поискового спроса и понятного для поисковика контента на индексирование можно особенно не рассчитывать.
Ну, или как минимум подождать. Можно попробовать ускорить процессы - всё теми же ссылками, которые могут попасть в индекс и дать хоть какой-то трафик.
Собственно, да, URL вне индекса:

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