paran0id

микрик для мыши распиновка

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

являясь собственно DBA последние сколько-то там лет...

Основная рутина:
- внесение изменений схемы данных без даунтайма собственно приложения
- выполнение каких-то массивных операций над данными (удалить половину данных из полутеррабайтной таблички, например)
- исследование проблем производительности со стороны базы
- решение в целом проблем на серверах баз, не только производительности
- текущее сопровождение: бекапы, репликация, переезды с одних серверов на другие, настройка новых серверов, минорные обновления базы
- major обновления базы
- заведение пользователей и организация прав доступа
- консультации разработчикам "как лучше сделать"
- консультации "так это работать не будет, придётся менять"

INPUT - для входящего трафика на саму машинку. Если у вас ДНС крутится в докере - то там уже отрабатывает цепочка FORWARD

А сложность начинается, как только задачи, стоящие перед ботом, перерастают уровень примера в документации видеотуториале пятилетней давности.

Нужно сделать несколько под-команд у команды. Напишу цепочку if-elif-else, делов то. Ой, а теперь простыня кода на пять экранов, в которой фиг чего найдёшь. Потому что нет привычки структурировать код.

Нужно, чтобы несколько команд/событий формировали цепочку (сценарий). Например, пользователь отправил тре сообщения, первое с именем, второе с возрастом, третье с адресом. Ой, а как это сделать вообще? Не зная понятия "конечный автомат" (finite state machine, FSM), очень трудно догадаться, как тут поступить.

Нужно, чтобы ботом могли пользоваться несколько человек. Ой, их данные перепутались! Потому что бот использует глобальные переменные.

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

Нужно добавить боту графический интерфейс - админку. Ой, а работает или интерфейс, или сам бот! Потому что нужно представлять, как устроено большинство GUI-фреймворков, и как устроена асинхронное приложение. А заодно понимать многопоточность, вопросы синхронизации действий между двумя потоками, и особенности работы с asyncio в многопоточных приложениях. Потому что одним потоком тут обойтись будет очень непросто.

Нужно хранить данные в БД. Ой, а почему у меня проблемы при записи в БД имени пользователя? А потому что погромист собирает SQL-запрос через форматирование строк. Надо было почитать доки, чтобы наткнуться на prepared statements, они же parameterized queries.

Нужно хранить данные в БД. Вот только данные имеют связи многие-ко-многим. Я знаю! Я буду просто добавлять или удалять столбцы в таблицу! Потому что не освоены даже азы проектирования БД. Тут уже nuff said. И да, я такое видел на этом сайте.

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

readelf -h /home/usr/qt-android/mylib.so

Я нашел ошибку: получается, что я использовал присваивание, а не знак равно

if (a = b) {} //Тут происходило, что a присваивало значение b
if (a == b) {}//А тут уже по условии a ровно b

ncdu /home