Зато есть бонус: если ты любопытен и умеешь задавать правильные вопросы – с помощью ИИ гораздо легче разобраться в новой для тебя теме. Просто шаг за шагом уточняя детали (каждый его ответ рождает новые вопросы).
Я помню (не в деталях, конкретные задействованные регистры уже могу назвать неправильно), но это не глубокое понимание, а просто технические детали, которые как раз можно спросить у ИИ. Глубокое понимание – это скорей принципы построения и вещи типа "как работает кэш", когда "знание некоторых принципов компенсирует незнание некоторых фактов".
Ну вот если мне не изменяет склероз (лучше проверить по докам) – ahk имеет возможность фильтровать на уровне приходящих в систему скан-кодов, т.е. может win и shift не то что отжать, а даже не нажимать (задерживаем их обработку, если через 0.1с не пришла F... или пришло что-то другое – пропускаем).
AHK2 под виндой, насколько я помню, вполне умеет такие вещи обрабатывать (предполагая худший вариант – когда кнопка посылает три скан-кода нажатия и три скан-кода отпускания). Правда, и нажатый руками Win+Shift+F23 обработает так же, но это можно пережить)))
На линуксе – ну, наверное, если нет какого-то готового фильтра, прокидывающего события клавиатуры через userspace (ну типа как FUSE прокидывает файловую систему).
Да, базовый набор кнопок (закрыть немедленно, не дать закрыться, вызов саппорта) есть, конечно. И все системы безопасности. На самом деле даже кнопки этажей есть, но они спрятаны за панелькой, открывающейся ключом. Т.е. обслуживающий персонал может, зайдя в лифт, отогнать его на нужный этаж.
Для 99% задач условно-публичный сервер вполне подойдёт (нет принципиальных отличий от несекретных чатов того же телеграма – тоже без e2e-шифрования). Проблемы будут скорее технические – скорость и т.п.
Привыкаешь. А я ещё живу всего на пятом и дома чаще ходил наверх пешком (сейчас обленился) – так что в итоге, когда привычка сформировалась, бывало смешно: захожу в лифт и жду, когда он поедет – я же помню, что в лифте ничего нажимать не надо :-)
Представить легко, но было бы ещё очень неплохо на каждом этаже иметь весь набор кнопок для всех этажей.
Работаю в здании, где так. Регулярно кто-нибудь садится не в тот лифт и приезжает не на тот этаж. Если это кто-то из аборигенов – чертыхается, выходит, вызывает лифт (если повезёт – назначит тот же, на котором приехал, пока он ещё на этаже). Если из гостей (или доставщики) – офигевает от происходящего (без ключ-карты он не может вызвать лифт на нужный этаж), приходится ему подсказать, что надо вызывать на 0 и идти к консьержу, чтобы тот снова вызвал лифт на нужный этаж.
Смоделируйте. Можете даже вначале собрать статистику по соседям (для минимальной модели достаточно частоту вызовов с каждого этажа, лучше отдельно утром и вечером).
Получите, грубо говоря, два числа – среднее время ожидания и расходы. И тогда уже сможете с цифрами в руках говорить. Вангую, что председатель близок к правде, с одной поправкой: на первый этаж вызовов гораздо больше – примерно столько же, сколько на все остальные вместе, и зачастую удобно (особенно вечером) свободный лифт держать именно там.
Реализация Destination dispatch у, если не путаю, Otis (возможно, Schindler, буду завтра на работе – гляну) – отвратительна. Два человека подходят на первый этаж, вызывают лифт на 25 и 26 – им назначают разные лифты (один из них едет, допустим на 22 и 26, другой на 25). Одного человека лифт уже забрал, второму неизвестно сколько ждать.
Не надо исправлять проблему. Надо её не создавать. Инварианты (если удаётся их выписать) позволяют избежать создания проблемы при движении по шагам. Это даже для человека проще (некая формальная фигня, которая всегда работает), не говоря о железном болване.
Да, безусловно. Доверять ему нельзя, всё нуждается в проверке. Но, проверяя – тоже учишься.
Основная проблема – надо знать, о чём спрашивать.
Зато есть бонус: если ты любопытен и умеешь задавать правильные вопросы – с помощью ИИ гораздо легче разобраться в новой для тебя теме. Просто шаг за шагом уточняя детали (каждый его ответ рождает новые вопросы).
Я помню (не в деталях, конкретные задействованные регистры уже могу назвать неправильно), но это не глубокое понимание, а просто технические детали, которые как раз можно спросить у ИИ. Глубокое понимание – это скорей принципы построения и вещи типа "как работает кэш", когда "знание некоторых принципов компенсирует незнание некоторых фактов".
Компаниям безусловно выгодна быстрая и дешёвая разработка. Ну а тут, как известно, "быстро, дёшево, качественно – выберите 2 из 3".
Скорость не сохраняется, часть энергии уйдёт на разгон клина. Система из трёх уравнений с тремя неизвестными ждёт :-)
С вращением шара задачка становится ещё интереснее.
Импульс только для одной (x) компоненты сохраняется. Третье уравнение – что приращение импульса шара направлено перпендикулярно поверхности клина.
Ну вот если мне не изменяет склероз (лучше проверить по докам) – ahk имеет возможность фильтровать на уровне приходящих в систему скан-кодов, т.е. может win и shift не то что отжать, а даже не нажимать (задерживаем их обработку, если через 0.1с не пришла F... или пришло что-то другое – пропускаем).
AHK2 под виндой, насколько я помню, вполне умеет такие вещи обрабатывать (предполагая худший вариант – когда кнопка посылает три скан-кода нажатия и три скан-кода отпускания). Правда, и нажатый руками Win+Shift+F23 обработает так же, но это можно пережить)))
На линуксе – ну, наверное, если нет какого-то готового фильтра, прокидывающего события клавиатуры через userspace (ну типа как FUSE прокидывает файловую систему).
Да, базовый набор кнопок (закрыть немедленно, не дать закрыться, вызов саппорта) есть, конечно. И все системы безопасности.
На самом деле даже кнопки этажей есть, но они спрятаны за панелькой, открывающейся ключом. Т.е. обслуживающий персонал может, зайдя в лифт, отогнать его на нужный этаж.
AutoHotkey что, её не обрабатывает?
Для 99% задач условно-публичный сервер вполне подойдёт (нет принципиальных отличий от несекретных чатов того же телеграма – тоже без e2e-шифрования). Проблемы будут скорее технические – скорость и т.п.
Некомпетентность – основа современной журналистики.
Привыкаешь. А я ещё живу всего на пятом и дома чаще ходил наверх пешком (сейчас обленился) – так что в итоге, когда привычка сформировалась, бывало смешно: захожу в лифт и жду, когда он поедет – я же помню, что в лифте ничего нажимать не надо :-)
Судя по всему, автор тоже запутался :-)
Работаю в здании, где так. Регулярно кто-нибудь садится не в тот лифт и приезжает не на тот этаж. Если это кто-то из аборигенов – чертыхается, выходит, вызывает лифт (если повезёт – назначит тот же, на котором приехал, пока он ещё на этаже). Если из гостей (или доставщики) – офигевает от происходящего (без ключ-карты он не может вызвать лифт на нужный этаж), приходится ему подсказать, что надо вызывать на 0 и идти к консьержу, чтобы тот снова вызвал лифт на нужный этаж.
Единственное – насчёт "вниз ничего не стоит" вы неправы. У лифта есть противовес, и он тяжелее пустого лифта.
Смоделируйте. Можете даже вначале собрать статистику по соседям (для минимальной модели достаточно частоту вызовов с каждого этажа, лучше отдельно утром и вечером).
Получите, грубо говоря, два числа – среднее время ожидания и расходы. И тогда уже сможете с цифрами в руках говорить. Вангую, что председатель близок к правде, с одной поправкой: на первый этаж вызовов гораздо больше – примерно столько же, сколько на все остальные вместе, и зачастую удобно (особенно вечером) свободный лифт держать именно там.
Реализация Destination dispatch у, если не путаю, Otis (возможно, Schindler, буду завтра на работе – гляну) – отвратительна. Два человека подходят на первый этаж, вызывают лифт на 25 и 26 – им назначают разные лифты (один из них едет, допустим на 22 и 26, другой на 25). Одного человека лифт уже забрал, второму неизвестно сколько ждать.
Раньше deep seek галлюцинировал сильно больше конкурентов.
Не надо исправлять проблему. Надо её не создавать. Инварианты (если удаётся их выписать) позволяют избежать создания проблемы при движении по шагам. Это даже для человека проще (некая формальная фигня, которая всегда работает), не говоря о железном болване.