Василий Банников

Зависит от того, зачем тебе этот ip нужен, и есть ли вообще этот белый адрес.
1. Сделать tcp-запрос на какой-нибудь свой сервер. И отправить в ответ, с какого адреса пришёл запрос.
Нужно свою инфраструктуру поднимать, либо пользоваться чужим API. (например https://ip-api.com/)
2. Явно спросить у пользователя - пользователь может любой написать, нужно проверять, если тебе именно он нужен
3. Посмотреть в какой-нибудь ipconfig - сработает только если компьютер напрямую в интернет воткнут и ему назначен глобальный ip.

В первый месяц мне дают задачу и просят дать точную оценку. А я не могу ее дать, потому что:
1. Я не понимаю еще работу действующих систем;
2. Я не понимаю какое количество систем нужно будет доработать, чтобы решить задачу;
3. Я не знаю насколько документация точно соответствует и нужен ли делать реверс-инжиниринг кода

И таких "не понимаю/не знаю" у меня первые 3-6 месяцев работы очень много

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

Если счёт на часы - говори "пару дней".
Если счёт на дни - говори "неделю или две".
Если счёт на месяцы - говори "через год/к осени/итд"
Ибо чем больше срок - тем больше неизвестность. Чем больше неизвестность - тем выше вероятность, что срок будет расти.
Если задача много времени требует - лучше разделить на несколько более достижимых целей и давать оценку следующей, после выполнения предыдущей.

К примеру "Сколько времени займёт сделать вот такой продукт?" (на первый взгляд - дофига) - отвечаешь "Proof of concept с вот такими минимальными фичами сделаем через столько-то"

1. Не сайт, но сборник задач: Rust koans. По сути своей - интерактивный учебник по синтаксису языка.
(UPD: на самом деле я думал про rustlings - это официальный сборник задач, а не koans)
2. Когда уже уверенно можешь писать код/знаком с синтаксисом - можешь попрактиковаться на leetcode и codewars.

Ну и лучше не на сайте сидеть, а нормальный редактор на компьютер установить, который будет давать подсказки по синтаксису и API.

"самой распространённой причины" не существует. Она будет сильно зависеть от конкретного продукта и процессов разработки.

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

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

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

4. Регресс. Разработчик нормально реализовал спецификацию, но тестировщик проверил только новую фичу и не стал проверять регресс - в итоге новая фича работает, а какая-то старая - сломалась, из-за того что её задели при разработке.

5. Несоответствие среды выполнения на этапе разработки, тестирования и в продакшене.
Например разрабатывали и тестировали на мощном железе, а при работе на слабом - всё плохо. Или сетевые задержки приводят к ошибкам, или на целевой машине стоит старая версия ОС, браузера, каких-то ещё зависимостей и поведение совсем меняется.

6. Во время разработки у заказчика поменялись планы. Старая спецификация больше не отвечает новым требованиям. Нужны доработки.

Чтобы минимизировать вышеперечисленное, нужно:
1. Плотное общение между разработчиком, аналитиком, и QA.
2. QA должен начинать тестирование ещё на этапе спецификации
3. Разработчик должен сообщать аналитику о всех случаях, когда он не может что-то реализовать или о каких-то пробелах.
4. Разработчик должен сообщать QA о возможном регрессе в других фичах.
5. Должны быть автотесты, чтобы уменьшить нагрузку на QA и чтобы минимизировать шанс на регресс
6. Тестирование должно обязательно производиться на том оборудовании и в том окружении, на котором система будет потом работать.
7. Чем чаще релизы - тем лучше.

Google authenticator ничего не сообщает сайтам, тк он просто реализует алгоритм/стандарт TOTP.
https://ru.m.wikipedia.org/wiki/Time-based_One-tim...

Если сильно не доверяешь Гуглу - ты можешь воспользоваться другим генератором кодов (Яндекс ключ, ms authenticator, authy), или вообще можешь для интереса попробовать написать свой скрипт, который по ключу будет генерировать такие же коды.

Разница в том что есть пользовательское соглашение, которое ты принимаешь в момент регистрации и установки.

Что сайт что приложение - это ПО, хоть и с немного разным способом дистрибуции.

nvidia и amd не производят свои видеокарты - они производят только чипы.
Затем эти чипы поставляются вендорам: (asus, msi, gigabyte, palit, и ещё куча других), которые на их основе уже соберут видеокарту.

Различия будут в качестве сборки, охлаждения, питания, размере, и, иногда, в чипах памяти.
У каких-то видеокарт будет разгон с завода.
А ещё в дизайне и количестве разъёмов для подключения мониторов.
Из этого будет складываться цена.

Например вот первые попавшиеся:
MSI GeForce GTX 1660 SUPER VENTUS XS OC 6GB
Palit GeForce GTX 1660 SUPER StormX 6GB

Они обе построены на одном и том же чипе (TU116-300-A1)
У меня почему-то вариант от Palit стоит немного дороже, хотя у варианта от MSI очевидно более мощное охлаждение и есть разгон с завода. В этом плане Palit выигрывает только в меньшем размере.

4 дня работаешь на нормальной работе, 1 день преподаёшь.
Преподавание - это 90% педагогики и 10% собственно программирования.
Прогрессировать, очевидно, будешь только в умении доносить какие-то знания до людей сильно глупее тебя (ну или хотябы в умении не сходить с ума от того что на паре студенты ничего не делают)

Когда ты создашь достаточно большой минус со своим мультиаккаунтом, то wb просто обращается в полицию и тебя мгновенно находят через запрос в банк "а кто этот платёж сделал"

Так что лучше либо не пользоваться wb, либо делать нормальные возвраты, либо не делать возвраты.

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

Так что тут выбора два:
1. Внимательно читать стандарты, сам текст закона, всякие регламенты и разъяснения от РКН итд.
2. Обратиться к какой-нибудь компании, которая на этом специализируется.

"Хостинг по 152 ФЗ" - это вершина айсберга, которая гарантирует только две вещи:
1. Ограничение физического доступа к серверам
2. Удаление данных, когда вы перестанете этими серверами пользоваться

Кажется, что данные не зашифрованные, а сжатые, тк там есть ещё поле compression и указан, видимо, исходный размер данных.
Число 2 означает, какой алгоритм шифрования использовался (видимо).

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

А вот если оно реально зашифровано, то никак не расшифровать - никакой из современных надёжных алгоритмов за адекватное время расшифровать нельзя.

PS: если бы не было скринов, то ответ был бы просто "нельзя", так как хэш абсолютно ничего тебе бы не сказал о том, как данные зашифрованы)

Варианта четыре:
1. Кастануть в any
2. Кастануть в конкретный тип
3. Использовать narrowing: Сделать проверки, что typeof item === "object" и что у него есть нужные свойства.
4. Если заранее знаешь, что у тебя item - это какой-то тип из нескольких, то вместо unknown можно сделать union

Вот ещё пример:
https://www.typescriptlang.org/play?target=9#code/...

Либо ограничение, либо индекс - собственно это и есть сам первичный ключ.

А то что около колонок - это просто подсказка о том, что эта колонка является PK.