mayton2019

В 2000х годах хакеры, используя метод радужных таблиц (rainbow tables) научились находить пароль по известному хешу
за вполне короткое время если обладали заранее расчитанной базой этих таблиц. И если они знали
какая хеш-функция работала. Особенно для Windows NTLM у них ловко выходило. И при условии
что пароль был корткий. До 8 символов например. Для большего пароля база росла экспоненциально.

Противостоять этому методу можно было легко. Для каждой единицы программного обеспечения
нужно было создать соль (salt) и на уровне алгоритма и добавлять ее к паролям везде. Логику алгоритма
аутентификации это вообще не меняло но зато отбрасывало злоумышленников во времени намного назад.

Теперь стандартные наборы таблиц не работали. Им нужно для вашего софта персонально генерить свой сет
таблиц. Даже на видеокартах этот процесс очень долгий и сами таблички занимают много гигабайт. Короче
никому это было не нужно и salt является надежным убийцей радуги.

В криптографии есть аналогия с вектором инициализации IV для симметричных шифров.

В процессе обучения сигмоид очень важен т.к. он обеспечивает сходимость алгоритма. Направление грубо говоря.

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

Практически если у тебя уже есть софт и модель то замена одно функции на другую в коде это дело одной
минуты. Лямбду заменить. Или еще один класс унаследовать.

Тут пишут https://go.dev/tour/methods/9 весьма сухо.

Interfaces
An interface type is defined as a set of method signatures.
A value of interface type can hold any value that implements those methods.

Судя по всему Google не особо заинтересован описывать детали реализации интерфейса.
Возможно на реализацию нет спеки. И Google планирует в будущем ее изменять.

Как рассчитывать движение, работу двигателя и так далее?

Это - вопрос на мильон. Я думаю что если здесь собрать ракето-конструкторов - все они не сойдутся
на единой формуле расчета. Каждое конструкторское бюро конструирует их опираясь на свой
опыт. И мне кажется что там главной движущей силой расчета были ограничения чем формулы.
Например какое топливо? Как горит? Как долго горит? Насколько его хватит? Когда отделять
первую ступень? Да тут даже нет формулы. Бесконечно большое число испытаний. Наблюдения.
Привязка к ограничениям.

По игре-симулятору.

Чтоб полет был реалистичным - надо ХОТЯ-БЫ соблюсти все реальные физические свойства этого полета. Расстояния. Массы земли и луны. Скорость ракеты. Ускорение ракеты. Влияние атмосферы земли.

Это кажется пустяк но если ты хочешь делать симулятор то надо сделать его так чтоб полет хотя-бы не длился 30 секунд. Это уж будет слишком "не по лунному сценарию".

Как процедурно сгенерировать реалистичную поверхность Луны?

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

Я использовал Apache Velocity https://velocity.apache.org/ он правда не для кодо-генерации,
а для отчетов, но в некоторых простых кейсх подходит. В шаблон можно добавлять проверки условий и циклы.

Есть еще Mustache https://mustache.github.io/ , он более простой. Там просто строковые замены. Но, поддерживает все языки разработки для запуска.

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

Используй логгирование как здесь пишут https://developer.android.com/studio/debug/logcat чтобы подтвердить что твой метод действительно вызван 5 раз.

Такой эффект может быть в инженерной графике когда стоят близко два полигона. Параллельно друг к другу
и расстояние между ними настолько маленькое что глубины и точности Z-buffer не хватает чтобы определить
что показывать ближе. Вот. Но тут еще артефакт воспризводится на прозрачных объектах. И это странно.

Решением может быть просто увеличение физических размеров объектов. Вот у тебя размер задан в чем.
Допустим в сантиметрах. Сделай все в милиметрах. Или в микронах.

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

В ВУЗах такой программы обычно нет. Мы учили лет 20 назад ОА и СД (оснонвы алгоритмов и структур данных).

Ваш список - чудовищно длинный. Если по нему расписать все - то примерно хватит на 5 лет учебы.
Я сомневаюсь что вы будете планировать с таким горизонотом. Я предложу выкинуть следующее.

- Алгебра
- Геометрия

И я объясню почему. Когда вы идете в ВУЗ - вы уже знаете алгебру и геометрию. Это курс школьной
программы и я не вижу смысла его подмешивать к компьютерным науками. Если вы по каким-то причинам
алгебру не знаете. То я вообще не вижу смысла вам дальше двигаться. Вы не будете понимать доказательтв
и выводов формул в других науках поэтому выкидываем.

Далее выкидываем.

- Теория игр
- Динамика
- Расписания

Теория игр - это факультатив. Почитаете книжки на досуге. Не включают обычно в базовые программы.
Не знаю зачем выделять отдельно расписания? Это может быть просто подраздел какой-то другой
оптимизации. Динамика ... хм... Что за динамика? Упругого тела? Непонятно. Разверните опредление.

- Строки

Выкидываем строки. Это первое занятие по Turbo Pascal. За 15 минут вы узнаете что такое строки.
Никаких особых знаний там нет. Алгоритм КМП и Боуер Мур - пойдет в ОЯ и СД.

Графы - я не буду выкидывать. Но они идут как подраздел дискретной математики.
Теория множеств. Дискретка. Графы. Это обычно один предмет.

Далее.

- Алгоритмы на последовательностях

Я не знаю что это такое. Приведите пример. Возможно это имеет другие названия? Автоматы? Сети? Цепи?

- Комбинаторика

Тоже идет как подраздел дискретной математики.

Итого в сухом остатке у нас остается 4 предмета.

- ОЯ и СД из программы любого ВУЗа
- Дискретная математика из ВУЗа
- Линейная алгебра
- Численные методы (да это реально настоящий предмет ВУЗа и притом достаточно плотный). Семестр как минимум.

Структуры данных - поглощаются ОЯ и СД. Вот. Остается Линейная Алгебра. Я ее не знаю куда положить.
Я не изучал ее отдельно как предмет. Возможно это и где-то выделяется в науку. Говоря о последовательности
изучения этих 4 предметов - я могу просто сослаться на методички ВУЗов. Ищите их. Ищите учебные планы.
Некоторые из этих наук я думаю можно учить параллельно.

Посмотри ключик
-fsanitize=thread

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

Да. Go - хороший язык. По крайней мере в нем есть типизация.
Кроме того этот язык востребован на ниве devops и и микро-сервисов.
Значит приток задач будет постоянно.

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

Для большинства обычных пользователей-обывателей интернета которые сидят в телефонах, домашних проводных интернетах, кафешках с wifi, невозможно зафиксировать постоянный IP. Он у них меняется либо раз в сутки либо по сеансу.

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

Задача неизвестного IP:port частично решена в торрент-протоколах. Там пользователи "отмечаются" раз в несколько минут по трекерной ссылке и таким образом трекер владеет информацией о свежих парах IP:port которые присуствуют в сети. Вот. Эта схема тоже рабочая. Но нужен вот еще один сервис для трекинга.

Дырки могут быть связаны с механикой кеширования sequence для каждого сеанса mysql.
По сути если 10 сеансов хотят быстро и без конкуренции вставлять в таблицу то они должны
прочитать пачку номеров. Например первый сеанс с 1 по 10 и второй с 11 по 20 и так далее.
В разных БД это реализовано по разному но это в целом - механика оптимизации скорости.
И если сеанс закрылся и недочитал 7, 8, 9 номер то и хер с ним. Диапазон уже был использован
как туалетная бумага.

У тебя-же нет желания доставать из ведра грязную бумагу и еще раз ее использовать?

Эти два запроса - какая-то безсмыслица.

SELECT Town FROM users WHERE user_id = (?)

UPDATE users SET 'Town' = (?)

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

На протяжении 20 лет я наблюдаю за базами данных и механизмами стриминга событий, слежениями
и прочее. Так вот. Это все НЕ РАБОТАЕТ. Не работает по причине идеологии ACID. Вы не можете операцию
DML считать основанием для генерации события. Потому что DML это не транзакция. Если мы фиксируем
DML commit/rollback операцией - то при этом неочевидно что должна видеть стриминговая платформа.

Она не может откатывать события в обратную сторону. Такой механизм технически дорог. Поэтому
основанием для стриминга событий может быть только событие внутри приложения. PHP, Node, Java e.t.c.
вот там и генерируйте события.

А база данных здесь вообще не помошник. Сканировать таблицу по скедулеру тоже не надо. Это дорого
и не реал-тайм.