Нужно делать все, чтобы компьютер как можно дольше оставался рабом человека, а не наоборот (наоборот оно само скоро получится - знаний и навыков манипуляции в AI-мозге уже больше чем достаточно, чтобы обдурить статистическое большинство людей, а с разумным меньшинством искусственный мозг скоро догадается расправиться силой зомбированного большинства, а не собственной хитростью - то есть ровно так, как мы это наблюдаем сейчас в человеческом обществе).
Следовательно - никаких Гц с миганиями, резких тонов, кнопок ЖМИ скорее и получи мегабонус итд. Всем этим вы увеличиваете (быдло)конверсию, но в гораздо большей степени приближаете адъ! И не важно, выше порога эпилепсии частота мигания или резкость градиента цвета, или она еще "терпима" устойчивыми представителями - важно то, что вред от массовых агрессивных UI и UX-решений компенсировать в обществе будет очень дорого, если вообще возможно.
всегда было интересно, есть ли в умных чайниках алгоритмическая защита от его использования в горах? А от выхода из строя датчика температуры? Напрмер, умеет ли прошивка анализировать кривую роста температуры, а не только достижение 100С (которая на высоте 2000м например, всего 93С), или ограничивать предельное время работы нагревателя, и выключать элемент при выходе температуры на полку кипения, или по таймауту? :
На уровне ORM это очень грубо, буквально черно-бело. Все или ничего. Если делать оптимальнее, то метод, который выбирает данные чилдовой сущности, должен иметь на входе список первичных ключей родительской сущности, для которых выбираются чилдовые. Далеко не всегда их нужно выбирать для всех ключей родителей. В рудиментарном случае - это единственный ID (например, для показа/редактирования экземпляра родителя), в более сложном (или статистически-частом) - например, вызов чилдов только для ID тех родителей, которые в данный момент рендерятся на клиентском экране.
Вычитывать "все для всех" часто бывает избыточным - а интегральная производительность системы определяется не трудоемкостью отдельно взятых операций, а трудоемкостью их статистической смеси, наблюдаемой при рабочей нагрузке. Например, если клиент статистически не скроллит вниз выдачу дальше первых 5-6 элементов - то и выбирать чилдов дальше 5-6 без специального события (скролла вниз) заранее не нужно. И что в данном случае будет лучше (если у нас нет точных средств, которые я описал, а есть только "все или ничего") - совсем не очевидно.
Видимо текстовые значения окавычиваются на middle-tier без экранирования и подставляются в стейтмент типа where x in (‘aaa’, ‘bbb’, ‘ccc’), где потом строковые значения лукапятся в ID ролей из справочника, и дальше идет merge в таблицу ассоциаций юзер-роль. Как-то так.
Как Вам сказать - это было лет за 10 до открытия кафедры КТ, студенты и выпускники которой прославились на весь мир. В начале моей учебы в институте там было все достаточно архаично, и меняться начало только со второй половины 90-х годов. Преподаваемый Паскаль с практикой на СМ-1420 мало чем помог бы в низкоуровневом программировании под MS-DOS (а вот книга Правец-16 и самостоятельное изучение ассемблера x86 - очень даже помогли)
Я на кафедральной PC/XT на Турбо-Паскале написал wysiwyg-файловый менеджер, который считывал MBR, FAT и структуру директорий дисков прямо через вызовы BIOS, показывал файлы и каталоги наподобие NC, и позволял защищать/снимать защиту с файлов и каталогов путем патчинга первого байта имени защищаемых файлов нулем (перенося то, что там было, в неиспользуемый байт записи о файле). Это делало невозможным открытие файла ничем, кроме непосредственного редактирование секторов через diskedit. Chkdsk тех времен, как и NDD, тоже емнип не замечали этого, так что получалось довольно надежно ;)
Прятали таким образом в учебном классе на кафедре программу, которая через RS-232 позволяет копировать файлы с компа на комп. А вот в этих файлах были втч игрушки. Шлейф для копирования тоже был самодельный - метров 15 телефонного провода с цанговыми разьемами от какого-то советского разьема на концах (колодки DB-9 тогда стоили денег).
Лучше бы в Гугл-картах сделали умный указатель POI в режиме следования по маршруту. В существующем варианте - это ад кромешный - если ввести, скажем fuel stations, или McDonald’s, то предложения густо даются в местах, которые ты уже (давно) проехал, а вперед по маршруту - либо ничего, либо через 10 часов пути вблизи от точки назначения. Бесит страшно, особенно если найти POI нужно во время движения. Я вспоминаю старый добрый CityGuide, он на порядок лучше сделан для вождения, хотя и не без глюков тоже (при путешествии между странами не умеет адекватно считать время из-за проблем с трассировкой на стыках карт), и в Европе пробки и дорожные события показывает неадекватно.
А простой делитель на двоичном счетчике не подошел бы в качестве устройства понижения частоты? И на выходе тоже был бы меандр и фиксированная амплитуда..
Да, абсолютный диапазон изменения частоты бы уменьшился, но это критично?
Тут дело не в выгорании, а в буксовании. Потребности (втч финансовые) 20-летнего и 50-летнего человека сильно различаются - как и пропорция его времени, которое он может уделить работе - как и scope проблем, которые он может охватить в своей деятельности (условно - высота полета над ландшафтом задач в bird’s eye view).
Если человек идет стандартным статистическим путем (обзаводится семьей, детьми, дачей, тещей, пожилыми родителями итд) - то ему нельзя не поднимать высоту bird’s eye view, так как для определенного scope существует предел денежной компенсации (условно, семейство кривых роста зп от уровня квалификации насыщаются - и этот уровень разный для разных квалификаций). Поэтому посредственный директор может прокормить семью с детьми, дачей, тещей, Volvo Executive или MB GLE, а экспертный разработчик- нет. Нужно соблюдать баланс скорости и угла атаки (как для самолета), чтобы эффективно увеличивать еще и высоту.
Я бы приспособил вместо шлема уже имеющийся в доме апплаенс - смарт-пылесос. Нужно только воткнуть его шланг в нагнетающий выход, а другой конец держать в районе головы. Как только телефон почувствует невесомость, он по блютусу дает команду пылесосу дуть, и тот сдувает телефон с траектории падения в сторону от головы. Нужно только еще, чтобы в пылесосе был двигатель с мгновенной раскруткой (обычный коллекторный не подойдет). И никаких шлемов :)
Это для пациентов стационаров? Здоровым людям проще читать телефон, лежа на боку, чем держать руки вытянутыми вертикально вверх с увесистой (в Азии превалируют андроид-лопаты) плюхой в руках. Зачем бороться с тяготением, когда можно просто лечь на бок?
Ну если нужны бронебойные решения для работы в Заполярье, я бы сделал даже программную нагрузочную вилку - скажем нагружать батарею через ключ на полевике на 500 Ом импульсом в пару десятков микросекунд, и смотреть падение, чтобы оценить внутреннее сопротивление.
Был уверен, да. Через буфер-триггер Шмидта вешалось все равно, через буфер + RC-цепь - нет. И если тактировать вход через D-триггер от sysclk - тоже нет.
Это было что-то на уровне логики цифрового автомата внутри контроллера.
Дребезг - страшная вещь, часто даже непобеждаемая аппаратной и программной логикой. Я помню случай почти 40-летней давности из мира 8080 с контроллером прерываний 8059 - если на один из его входов прикрепить метелку из зачищенного МГТФ, и провести ей по земляной (или питания - не помню уже) шине - то хаотические прерывания намертво вешали систему - несмотря на запрет вложенных прерываний на аппаратном и программном уровне. Стоит сделать источник (даже высокочастотный) из тактируемых ИМС - все работает нормально ;)
Эти рекомендации гораздо более глобальные, чем поведение какой-то одной подветки вариантов STM32, и даже более глобальные, чем все STM, вместе взятые. Это фундаментальные правила разведчика, в которых нельзя терять из виду состояние ни одного контролируемого обьекта, и полностью представлять себе, что происходит в моменты входа/выхода из анабиоза, и кто в этот момент контролирует периферию. То, что где-то часть действий можно сделать средствами самого SoC’а, хорошо, но тоже оставляет вопросы - где гарантия, что грязный сброс или уход в полубессознательное состояние после неудачного выхода из стендбая не оставит эти регистры в состоянии мусора? Не говоря уже о том, что защелкнуться через защитные диоды может и сам SoC - и ему точно будет не до контроля других таких же зомби, подвешенных вверх ногами :). А определять потенциал внешними средствами на каждом выводе не то чтобы неохота или дорого (хотя и то, и то правда) - это приведет к существенной толчее на ПП вблизи МК (то есть как раз там, где изящная разводка критична), и может даже к лишним слоям только для того, чтобы сделать систему железобетонно устойчивой к засыпаниям/просыпаниям. В большинстве случаев разработчики просто забьют, и поставят больше аккумулятор, или скажут - автономная работа от батареи - месяц (вместо года), но истинные мастера, конечно, доведут дело до конца.
Меня всегда подмывало положить айфон в равномерно ускоряющийся автомобиль (с небольшим ускорением, 0.1g хватит), откалибровать его прямо там, а потом посмотреть, что он покажет в покое, когда увидит, что длина вектора ускорения, синтезированная по осям, окажется меньше g ;)
Хорошо обозначен базис в 8-мерном пространстве, но из-за объема статьи по каждому из измерений - по 1-2 шажка. Но все равно созвучно, спасибо.
Нужно делать все, чтобы компьютер как можно дольше оставался рабом человека, а не наоборот (наоборот оно само скоро получится - знаний и навыков манипуляции в AI-мозге уже больше чем достаточно, чтобы обдурить статистическое большинство людей, а с разумным меньшинством искусственный мозг скоро догадается расправиться силой зомбированного большинства, а не собственной хитростью - то есть ровно так, как мы это наблюдаем сейчас в человеческом обществе).
Следовательно - никаких Гц с миганиями, резких тонов, кнопок ЖМИ скорее и получи мегабонус итд. Всем этим вы увеличиваете (быдло)конверсию, но в гораздо большей степени приближаете адъ! И не важно, выше порога эпилепсии частота мигания или резкость градиента цвета, или она еще "терпима" устойчивыми представителями - важно то, что вред от массовых агрессивных UI и UX-решений компенсировать в обществе будет очень дорого, если вообще возможно.
всегда было интересно, есть ли в умных чайниках алгоритмическая защита от его использования в горах? А от выхода из строя датчика температуры? Напрмер, умеет ли прошивка анализировать кривую роста температуры, а не только достижение 100С (которая на высоте 2000м например, всего 93С), или ограничивать предельное время работы нагревателя, и выключать элемент при выходе температуры на полку кипения, или по таймауту? :
На уровне ORM это очень грубо, буквально черно-бело. Все или ничего. Если делать оптимальнее, то метод, который выбирает данные чилдовой сущности, должен иметь на входе список первичных ключей родительской сущности, для которых выбираются чилдовые. Далеко не всегда их нужно выбирать для всех ключей родителей.
В рудиментарном случае - это единственный ID (например, для показа/редактирования экземпляра родителя), в более сложном (или статистически-частом) - например, вызов чилдов только для ID тех родителей, которые в данный момент рендерятся на клиентском экране.
Вычитывать "все для всех" часто бывает избыточным - а интегральная производительность системы определяется не трудоемкостью отдельно взятых операций, а трудоемкостью их статистической смеси, наблюдаемой при рабочей нагрузке. Например, если клиент статистически не скроллит вниз выдачу дальше первых 5-6 элементов - то и выбирать чилдов дальше 5-6 без специального события (скролла вниз) заранее не нужно. И что в данном случае будет лучше (если у нас нет точных средств, которые я описал, а есть только "все или ничего") - совсем не очевидно.
Слог потрясающий, как и спектр примеров. Чувствуется старая школа. Респект!
Видимо текстовые значения окавычиваются на middle-tier без экранирования и подставляются в стейтмент типа where x in (‘aaa’, ‘bbb’, ‘ccc’), где потом строковые значения лукапятся в ID ролей из справочника, и дальше идет merge в таблицу ассоциаций юзер-роль. Как-то так.
Как Вам сказать - это было лет за 10 до открытия кафедры КТ, студенты и выпускники которой прославились на весь мир. В начале моей учебы в институте там было все достаточно архаично, и меняться начало только со второй половины 90-х годов. Преподаваемый Паскаль с практикой на СМ-1420 мало чем помог бы в низкоуровневом программировании под MS-DOS (а вот книга Правец-16 и самостоятельное изучение ассемблера x86 - очень даже помогли)
Я на кафедральной PC/XT на Турбо-Паскале написал wysiwyg-файловый менеджер, который считывал MBR, FAT и структуру директорий дисков прямо через вызовы BIOS, показывал файлы и каталоги наподобие NC, и позволял защищать/снимать защиту с файлов и каталогов путем патчинга первого байта имени защищаемых файлов нулем (перенося то, что там было, в неиспользуемый байт записи о файле). Это делало невозможным открытие файла ничем, кроме непосредственного редактирование секторов через diskedit. Chkdsk тех времен, как и NDD, тоже емнип не замечали этого, так что получалось довольно надежно ;)
Прятали таким образом в учебном классе на кафедре программу, которая через RS-232 позволяет копировать файлы с компа на комп. А вот в этих файлах были втч игрушки. Шлейф для копирования тоже был самодельный - метров 15 телефонного провода с цанговыми разьемами от какого-то советского разьема на концах (колодки DB-9 тогда стоили денег).
Это был 1989-1990 г. ЛИТМО.
Лучше бы в Гугл-картах сделали умный указатель POI в режиме следования по маршруту. В существующем варианте - это ад кромешный - если ввести, скажем fuel stations, или McDonald’s, то предложения густо даются в местах, которые ты уже (давно) проехал, а вперед по маршруту - либо ничего, либо через 10 часов пути вблизи от точки назначения. Бесит страшно, особенно если найти POI нужно во время движения. Я вспоминаю старый добрый CityGuide, он на порядок лучше сделан для вождения, хотя и не без глюков тоже (при путешествии между странами не умеет адекватно считать время из-за проблем с трассировкой на стыках карт), и в Европе пробки и дорожные события показывает неадекватно.
сфокусированным потоком свч-излучения ловко передаем собранную даровую энергию из облаков прямо в дом.
А простой делитель на двоичном счетчике не подошел бы в качестве устройства понижения частоты? И на выходе тоже был бы меандр и фиксированная амплитуда..
Да, абсолютный диапазон изменения частоты бы уменьшился, но это критично?
Тут дело не в выгорании, а в буксовании. Потребности (втч финансовые) 20-летнего и 50-летнего человека сильно различаются - как и пропорция его времени, которое он может уделить работе - как и scope проблем, которые он может охватить в своей деятельности (условно - высота полета над ландшафтом задач в bird’s eye view).
Если человек идет стандартным статистическим путем (обзаводится семьей, детьми, дачей, тещей, пожилыми родителями итд) - то ему нельзя не поднимать высоту bird’s eye view, так как для определенного scope существует предел денежной компенсации (условно, семейство кривых роста зп от уровня квалификации насыщаются - и этот уровень разный для разных квалификаций). Поэтому посредственный директор может прокормить семью с детьми, дачей, тещей, Volvo Executive или MB GLE, а экспертный разработчик- нет. Нужно соблюдать баланс скорости и угла атаки (как для самолета), чтобы эффективно увеличивать еще и высоту.
Но у Вас с этим все в порядке ;)
Забрало будет потеть, если лежать на спине. Значит, читатель смартфона будет открывать забрало - но тогда см. выше )
Я бы приспособил вместо шлема уже имеющийся в доме апплаенс - смарт-пылесос. Нужно только воткнуть его шланг в нагнетающий выход, а другой конец держать в районе головы. Как только телефон почувствует невесомость, он по блютусу дает команду пылесосу дуть, и тот сдувает телефон с траектории падения в сторону от головы. Нужно только еще, чтобы в пылесосе был двигатель с мгновенной раскруткой (обычный коллекторный не подойдет). И никаких шлемов :)
Это для пациентов стационаров? Здоровым людям проще читать телефон, лежа на боку, чем держать руки вытянутыми вертикально вверх с увесистой (в Азии превалируют андроид-лопаты) плюхой в руках. Зачем бороться с тяготением, когда можно просто лечь на бок?
Ну если нужны бронебойные решения для работы в Заполярье, я бы сделал даже программную нагрузочную вилку - скажем нагружать батарею через ключ на полевике на 500 Ом импульсом в пару десятков микросекунд, и смотреть падение, чтобы оценить внутреннее сопротивление.
Был уверен, да. Через буфер-триггер Шмидта вешалось все равно, через буфер + RC-цепь - нет. И если тактировать вход через D-триггер от sysclk - тоже нет.
Это было что-то на уровне логики цифрового автомата внутри контроллера.
Дребезг - страшная вещь, часто даже непобеждаемая аппаратной и программной логикой. Я помню случай почти 40-летней давности из мира 8080 с контроллером прерываний 8059 - если на один из его входов прикрепить метелку из зачищенного МГТФ, и провести ей по земляной (или питания - не помню уже) шине - то хаотические прерывания намертво вешали систему - несмотря на запрет вложенных прерываний на аппаратном и программном уровне. Стоит сделать источник (даже высокочастотный) из тактируемых ИМС - все работает нормально ;)
Эти рекомендации гораздо более глобальные, чем поведение какой-то одной подветки вариантов STM32, и даже более глобальные, чем все STM, вместе взятые. Это фундаментальные правила разведчика, в которых нельзя терять из виду состояние ни одного контролируемого обьекта, и полностью представлять себе, что происходит в моменты входа/выхода из анабиоза, и кто в этот момент контролирует периферию. То, что где-то часть действий можно сделать средствами самого SoC’а, хорошо, но тоже оставляет вопросы - где гарантия, что грязный сброс или уход в полубессознательное состояние после неудачного выхода из стендбая не оставит эти регистры в состоянии мусора? Не говоря уже о том, что защелкнуться через защитные диоды может и сам SoC - и ему точно будет не до контроля других таких же зомби, подвешенных вверх ногами :). А определять потенциал внешними средствами на каждом выводе не то чтобы неохота или дорого (хотя и то, и то правда) - это приведет к существенной толчее на ПП вблизи МК (то есть как раз там, где изящная разводка критична), и может даже к лишним слоям только для того, чтобы сделать систему железобетонно устойчивой к засыпаниям/просыпаниям. В большинстве случаев разработчики просто забьют, и поставят больше аккумулятор, или скажут - автономная работа от батареи - месяц (вместо года), но истинные мастера, конечно, доведут дело до конца.
Меня всегда подмывало положить айфон в равномерно ускоряющийся автомобиль (с небольшим ускорением, 0.1g хватит), откалибровать его прямо там, а потом посмотреть, что он покажет в покое, когда увидит, что длина вектора ускорения, синтезированная по осям, окажется меньше g ;)