У X еще должно быть какое-то ограничение. Оно как минимум не должно быть произвольным в диапазоне 2^80 до 2^81, а иметь шаг 2^n * i. Решение задачи будет отбросить 2^n и использовать только i.
Нет, если у вас есть функция, которая укажет в какую сторону двигаться, если вы взяли произвольное любое число, то легко найдете X за логарифмическую сложность.
Без конкретики, что из себя представляют проекты, кажется странным, зачем вам нужно подружить ужа с ежом. Если вам нужен на выходе exe-шник, то перепишите проект в desctop среде (в данном случае .NET).
Зачем вам серверная реализация проекта, когда вам не нужен сервер в качестве прокладки?
Можно повесить статичную плашечку на файл "Сей файл подписан и утвержден Ивановым Иван Иванычем 01.03.2023 12:04:45 находясь в добром здравии и уме". Важно, чтобы никто кроме авторизованных пользователей, кто отвечает за эту плашечку не мог ничего менять без согласования Иванова И.И.
Простая электронная подпись неотделима от системы, которая контролирует ее учет. Подписи можно доверять, если есть доверие к системе, которая сообщает ее статус.
Чисто на интуиции, я не доверяю современным системам охлаждения ноутов. Охлаждение четко выверено инженерами под определенный уровень тепловыделения. Если со временем, что-то ухудшается в сборке этой системы, то можно увидеть чудеса перегрева. Поэтому, как собрана система охлаждения - это попадает первым под подозрение, если проявляется такое. Хотя если ноут боязно вскрывать любыми путями, ввиду потери гарантии, то стоит поискать другие версии происходящего.
Руководитель и Исполнитель - это, по хорошему просто Человек.
А руководитель и исполнитель - это Роли (отдельная таблица). Осталось понять, если роль дается на задачу, то внешний ключ Роли идет на задачу, если Роль постоянна и не меняется от задачи к задаче - то на человека внешний ключ роли нужен.
Для вашей схемы достаточно указать в Расписании внешний ключ исполнителя, так как у вас что-то не так с сущностями Исполнители - они у вас "одноразовые" подучаются. Вам под каждую новую задачу придется вписывать нового исполнителя. Между Задачами и Исполнителями напрашивается отдельная сущность "Исполнитель задачи", в которой будут внешний ключ к Задаче и внешний ключ к Исполнителю - тем самым с помощью этой промежуточной таблицы реализуется связь "многим-ко-многим".
Если расписание нужно для фиксации периодов работы над задачей без детализации по исполнителям, то в записи расписания нужен только внешний ключ задачи. А исполнители подтянуться из сущности Исполнитель задачи.
Если выполнение каждой задачи нужно детализировать по разному набору исполнителей одной задачи, то вам нужно разбить сущность Расписание на две - "Расписание", и "Исполнитель задачи по расписанию"
Записи Расписание будет содержать внешний ключ на задачу, а запись "Исполнитель задачи по расписанию" внешний ключ к Расписанию и внешний ключ к Исполнителю задач (или к Исполнителю - не принципиально).
Пока не приведете свойства каждой сущности, то не понятно, какими связями должна обрасти сущность Расписание.
При анализе предметной области можно не доглядеть, допустим в сущности Задача - сущности Подзадача, у каждой из них могут быть отдельные исполнители. И не понятно, что хотите получить в расписании - фиксацию работы одного исполнителя, период времени работы над задачей?
Навыки корректного парсинга любых источников данных.
Идеально, если у вас есть в портфолио проект "серого" магазина-агрегатора, который корректно слизывает список товаров из официальных магазинов (естественно, не по их API, а по содержимому страниц. Естественно, без их ведома. Естественно, превозмогая изменяющуюся верстку страниц и структуру наполнения).
Сложно ли?
Делать не сложно. Сложно будет правильно формулировать вопросы заказчику по каждой мелкой детали в структуре входных документов. Особенно, по части:
- деталь структуры документа формируется полностью автоматически?
- зафиксирован ли стандарт формирования этой структуры?
- может ли человек вмешаться в структуру документа, без автоматических средств формирования такого документа - какие варианты бывают, какие корректные, какие ошибочные. Как детектить разного рода вмешательства?
И подобного рода вопросы вы должны уметь задавать и находить по ним решение, чтобы начать просто доставать корректные данные.
Если решите эту проблему, то вторую часть задачи - сформировать выходной документ будет уже проще.
Вы уверены, что хотите 1080 на 27+ диагонали?
Будете видеть сетку пикселей как во времена MS-DOS.
1080 комфортно смотрятся до 24 дюймов, дальше нужно увеличивать разрешение минимум до 2К.
Любо большой моник придется использовать только как телевизор или кинотеатр, для других целей 1080 в такой большой диагонали не целесообразен.
А где описание ваших попыток найти ошибку по логам PHP или по тому, что выдает функция mysqli_error()?
Если вы только пишете код (10% времени) и не проводите детективное расследование, как Шерлок Холс (90% времени), тратя время на эксперименты и поиск ошибок, то программистом никогда не станете.
На Q&A надо приходить с версиями таких изысканий.
Отключаете шлейф питания диска. Подгружаетесь с системы или с загрузочной флешки, где есть Виктория или подобная утилита, пока не запускаете ее. Вставляете шлейф питания (аккуратно, не перепутать полярность), и после инициализации диска (и определения его в системе, если запускали ОС) запустите утилиту. Пока диск активном состоянии снимите показания Смарта и попытайтесь запустить проверку диска.
