А кто-то может сказать кратко, как сейчас обстоят дела с LTO7/8? Потому что нормальный интерфейсы начинаются только с этих версий, а мучаться с FC (LTO5/6) никакого желания нет вообще.
Когда я смотрел пару лет назад, стоимость одного привода болталась где-то около 2000$, какие-то подвижки появились в плане цены? И еще сразу - если брать БУ, то где лучше? EBAY?
Кастомизировать можно через переменные/классы и это будет праильно, нативно и без костылей. Человек выше все праавильно написал.
И чтобы не быдь голословным и чтобы отстали от человека выше:) вот тотже шейп, что и в статье (правда абсолютно непонятно, где такую всрат..ю форму можно применить):
Чтобы получить заготовку, можно, например, в Inkscape (бесплатно) отрисовать любую форму или заготовки форм, материлизовать все трансформации и сохранить как "Optimized SVG", затем открываете SVG текстовым редактором и то что в path переносите в cli-path: path( "вот сюда" ), используя CSS-пременные, можно сделать любой конструктор.
Это следование стандартам, лучшая оптимизация и не изобретение своего велосипеда. Читать документацию иногда реально полезно.
Запрос должен быть представлен одной функцией, и абсолютно все равно, откуда она будет вызвана.
Если реально устройство очень тяжёлое по количеству модулей и сами модули самостоятельные, то может и есть смысл делать очередь PM, но тогда надо учитывать то, что модули могут иметь разное время обработки этих событий, и надо дожидаться их статуса, вплоть до того, что модуль сможет отменить уход в сон или что-то ещё (из-за ошибки или из-за того что-то обрабатывает).
Но в 99% эмбедеда этого нет, и решается централизованной фй, а все модули ведомые. Никчему переусложнять это дело.
Вроде очевидно, что данные нужно хранить там, где они не должны теряться, и в качестве защиты crc хранить, не сходится - нулевой ресет и переинициализация.
Для этого для каждого самостоятельного модуля заводится статус в массиве статусов, так кроме этого ещё какая-то телеметрия может для конкретного модуля храниться - например чем модуль в данный момент инициализирован.
Модем - типичный модуль, мало того - основной цпу - такойже модуль и там тоже хранится его текущее состояние - например сон, или глубокий сон или вообще обесточка.
Не понял, в чем проблема по наступлению любого пробуждения, просто проверить состояние кнопки/зарядки/чего-то ещё и согласно приоритету на каждое действие решить что делать?
Если нужна последовательность действий типа показать, что заряд на 0 и упасть в сон - для этого есть очереди (на томже ESP), если их нет, то примитивно они реализуются на массиве и 2х функциях - потребителе, и поставщике.
Ага, а у меня другие карты, может быть с этим связано, а вы разбирали этот кейс? Нет фоток внутренностей? Может там термопад можно засунуть между корпусом и картой? Я, конечно, тоже еще поковыряю его, но я его не открывал, так как проблем не было с ним.
Хабр медленно из технического ресурса превращается в ресурс для домохозяек :(
Ибо технари, кто хочет разобраться - либо прочитают, либо сами спросят LLM, а те из них, кто не хочет - не будут задерживаться на кусках кода, а буду читать суть статьи. А хомяки да, они не понимают - ни статьи, ни кода, ни сделать ничего не могут, ага.
Вобщем, uBlock > Open the dashboard > My filters, добавить: ! HABR, remove "code explainer" button habr.com##.code-explainer
А для редакции хабра дарю ссылку на бесплатную иконку, которая должна всплывать на куске кода только при наведении на него курсора. Почему такой простой UI элемент превратился в такое - я даже представить не могу, здраво объяснимо это может быть только каким-то профитом от сего действа, а не заботой об аудитории.
@Boomburum скажи,что тебя в заложники взяли там и заставляют все это делать - мы придем спасать)
Ну и, честно, как технарь технарям - решили выкатить новую фичу как можно быстрее - понимаю, но добавьте или хотябы пообещайте своим пользователям, что потом, в профайле, добавится ее включение/отключение. Ну или не удивляйтесь потом оттоку аудитории и тому, что половина контента сайта в адблок попадает, в том числе и то, что не должно.
Инженерия тут не причем - понятно дело, что если возникла необходимость решения математической нестандартной задачи (ибо стандартные типа sort и тд давно уже живут ф библиотеках и фреймворках), то необходимо посмотреть, а как ее лучше решить не "в лоб" (перебор - это, например, в лоб).
И вот тут нужно либо воспользоваться математиком, который подскажет куда копать, или как раз таки спросить у ЛЛМ - именно не код написать, а про алго и оптимальные пути его решения, потом самому переложить это в код.
И, имхо, правильный инженер должен поступит именно так.
Затем, в сухом остатке остается знание, что при возникновении такого типа задач нужно воспользоваться таким-то алгоритмом. Не нужно инженеру или программисту знать наизусть кучу вещей, которые могут не понадобиться вообще. Нужно лишь понимание где может возникать бутылочное горлышко - а для этого нужна лишь базовая логика, остальное можно будет уточнить или проверить.
Ну и, иногда, решения "в лоб" работают лучше, чем куча хитростей и сложный алго - это тоже надо понимать.
Все-таки если не лезть в дебри, то оно вполне, ИМХО (а дебри везде есть, это как времена в английском;))
Соглашусь, что в Паскале проще - но есть еще один нюанс, который я учитывал, давая эту рекомендацию - все-таки хорошо учить не мертвому языку, Си в этом плане куда лучше. И есть потом куда развиваться (я про плюсы и дебри).
Если про == я могу согласиться, то что не так с открывающей скобкой в блоке? B про "мутнейшее описание сложных конструкций" можно подробней? - прямо очень интересно, без всякого сарказма.
Ну, уж ) генераторы/итераторы и декораторы - это как раз не магия, а хороший синтаксический сахар (за который как раз этот язык можно и нужно любить).
Магия - это не очевидное поведение.
Например, в Python значения "по-умолчанию" у фии, которые не являются примитивом, сохраняются между вызывами этой функции, ну или то, что округление по-умолчанию - "бухгалтерское".
Лапша - например, задекларировано, что все есть объект, но при этом чтобы посчитать кол-во символов в строке нужно сделать "len( строка )" вместо "строка.len" и тд. Т.е. есть собственные базовые фии вызываются иногда "из объекта", а иногда "на объект", всякие магические названия вроде __main или не менее магические названия приавтных членов класса, геттеров/сеттеров, кваргсы и тд - те когда нет четкой и жесткой структуры работы.
Я преподавал и много, для себя вывел следующее - лучший язык для понимания - это Си, без плюсов.
Потому как там четкая система типов, указатели (очень важная штука для хорошего программиста), а при левелапе можно и ООП настоящее дать, но уже в плюсах.
То, что в статье - полностью согласен.
Про Python могу очень много плохого наговорить с аргументами, его преподносят часто как "гораздо лучший, чем лапшистый и с кучей магии PHP", а по факту лапши и магии там в разы больше. Я не люблю ни тот, ни тот, но, к сожалению, ввиду того что Python преподается практически во всех университетах мира, он стал стандартом де-факто, увы.
А кто-то может сказать кратко, как сейчас обстоят дела с LTO7/8? Потому что нормальный интерфейсы начинаются только с этих версий, а мучаться с FC (LTO5/6) никакого желания нет вообще.
Когда я смотрел пару лет назад, стоимость одного привода болталась где-то около 2000$, какие-то подвижки появились в плане цены? И еще сразу - если брать БУ, то где лучше? EBAY?
Оно реально и делается за 5 минут.
Кастомизировать можно через переменные/классы и это будет праильно, нативно и без костылей. Человек выше все праавильно написал.
И чтобы не быдь голословным и чтобы отстали от человека выше:) вот тотже шейп, что и в статье (правда абсолютно непонятно, где такую всрат..ю форму можно применить):
clip-path: path( "m14.065 2.4e-4c-7.7921 0-14.065 6.2732-14.065 14.065v27.491c0 7.7921 6.2735 13.997 14.065 14.065l62.031 0.54156c18.869 0.15509-1.4926-18.141 22.957-17.76 19.856 0.3092 19.105-4.2759 19.002-9.8528l0.18552-14.485c0.0998-7.7914-6.2732-14.065-14.065-14.065z" );Чтобы получить заготовку, можно, например, в Inkscape (бесплатно) отрисовать любую форму или заготовки форм, материлизовать все трансформации и сохранить как "Optimized SVG", затем открываете SVG текстовым редактором и то что в path переносите в cli-path: path( "вот сюда" ), используя CSS-пременные, можно сделать любой конструктор.
Это следование стандартам, лучшая оптимизация и не изобретение своего велосипеда. Читать документацию иногда реально полезно.
Запрос должен быть представлен одной функцией, и абсолютно все равно, откуда она будет вызвана.
Если реально устройство очень тяжёлое по количеству модулей и сами модули самостоятельные, то может и есть смысл делать очередь PM, но тогда надо учитывать то, что модули могут иметь разное время обработки этих событий, и надо дожидаться их статуса, вплоть до того, что модуль сможет отменить уход в сон или что-то ещё (из-за ошибки или из-за того что-то обрабатывает).
Но в 99% эмбедеда этого нет, и решается централизованной фй, а все модули ведомые. Никчему переусложнять это дело.
Вроде очевидно, что данные нужно хранить там, где они не должны теряться, и в качестве защиты crc хранить, не сходится - нулевой ресет и переинициализация.
Для этого для каждого самостоятельного модуля заводится статус в массиве статусов, так кроме этого ещё какая-то телеметрия может для конкретного модуля храниться - например чем модуль в данный момент инициализирован.
Модем - типичный модуль, мало того - основной цпу - такойже модуль и там тоже хранится его текущее состояние - например сон, или глубокий сон или вообще обесточка.
При таком подходе понять, что делать элементарно.
Не понял, в чем проблема по наступлению любого пробуждения, просто проверить состояние кнопки/зарядки/чего-то ещё и согласно приоритету на каждое действие решить что делать?
Если нужна последовательность действий типа показать, что заряд на 0 и упасть в сон - для этого есть очереди (на томже ESP), если их нет, то примитивно они реализуются на массиве и 2х функциях - потребителе, и поставщике.
Ага, а у меня другие карты, может быть с этим связано, а вы разбирали этот кейс? Нет фоток внутренностей? Может там термопад можно засунуть между корпусом и картой? Я, конечно, тоже еще поковыряю его, но я его не открывал, так как проблем не было с ним.
По ссылке несколько вариантов, включая и Type A.
А перегрев когда Вы ловили? Всмысле сколько времени у вас шло копирование, прежде чем перегрев наступал? - т.к. я не замечал такого на этом ридере.
Вот в хорошем алюминиевом корпусе и практически по такойже цене https://aliexpress.ru/item/1005007008726811.html
По-моему это проще и удобней.
«Сбер»: проект «Вжух»
Можно было только заголовок опубликовать )))
Как-то так все там и работает...
Хабр медленно из технического ресурса превращается в ресурс для домохозяек :(
Ибо технари, кто хочет разобраться - либо прочитают, либо сами спросят LLM, а те из них, кто не хочет - не будут задерживаться на кусках кода, а буду читать суть статьи.
А хомяки да, они не понимают - ни статьи, ни кода, ни сделать ничего не могут, ага.
Вобщем, uBlock > Open the dashboard > My filters, добавить:
! HABR, remove "code explainer" button
habr.com##.code-explainer
А для редакции хабра дарю ссылку на бесплатную иконку, которая должна всплывать на куске кода только при наведении на него курсора. Почему такой простой UI элемент превратился в такое - я даже представить не могу, здраво объяснимо это может быть только каким-то профитом от сего действа, а не заботой об аудитории.
@Boomburum скажи,что тебя в заложники взяли там и заставляют все это делать - мы придем спасать)
Ну и, честно, как технарь технарям - решили выкатить новую фичу как можно быстрее - понимаю, но добавьте или хотябы пообещайте своим пользователям, что потом, в профайле, добавится ее включение/отключение. Ну или не удивляйтесь потом оттоку аудитории и тому, что половина контента сайта в адблок попадает, в том числе и то, что не должно.
Можно поспорить?
Инженерия тут не причем - понятно дело, что если возникла необходимость решения математической нестандартной задачи (ибо стандартные типа sort и тд давно уже живут ф библиотеках и фреймворках), то необходимо посмотреть, а как ее лучше решить не "в лоб" (перебор - это, например, в лоб).
И вот тут нужно либо воспользоваться математиком, который подскажет куда копать, или как раз таки спросить у ЛЛМ - именно не код написать, а про алго и оптимальные пути его решения, потом самому переложить это в код.
И, имхо, правильный инженер должен поступит именно так.
Затем, в сухом остатке остается знание, что при возникновении такого типа задач нужно воспользоваться таким-то алгоритмом. Не нужно инженеру или программисту знать наизусть кучу вещей, которые могут не понадобиться вообще. Нужно лишь понимание где может возникать бутылочное горлышко - а для этого нужна лишь базовая логика, остальное можно будет уточнить или проверить.
Ну и, иногда, решения "в лоб" работают лучше, чем куча хитростей и сложный алго - это тоже надо понимать.
Жди - щас сюда ворвется главный евангелист и псевдосеньор гно-молла и начнет кричать что вот мол - это мол хорошо, а это, мол, все плохо :D
Хотя, исходя из парадигмы, это должно работать и в его поделии.
Ну и не забарсывайте это дело - вещь шужная и полезная в текущем зоопарке фреймворков.
Все-таки если не лезть в дебри, то оно вполне, ИМХО (а дебри везде есть, это как времена в английском;))
Соглашусь, что в Паскале проще - но есть еще один нюанс, который я учитывал, давая эту рекомендацию - все-таки хорошо учить не мертвому языку, Си в этом плане куда лучше. И есть потом куда развиваться (я про плюсы и дебри).
Если про == я могу согласиться, то что не так с открывающей скобкой в блоке? B про "мутнейшее описание сложных конструкций" можно подробней? - прямо очень интересно, без всякого сарказма.
Ну, уж ) генераторы/итераторы и декораторы - это как раз не магия, а хороший синтаксический сахар (за который как раз этот язык можно и нужно любить).
Магия - это не очевидное поведение.
Например, в Python значения "по-умолчанию" у фии, которые не являются примитивом, сохраняются между вызывами этой функции, ну или то, что округление по-умолчанию - "бухгалтерское".
Лапша - например, задекларировано, что все есть объект, но при этом чтобы посчитать кол-во символов в строке нужно сделать "len( строка )" вместо "строка.len" и тд. Т.е. есть собственные базовые фии вызываются иногда "из объекта", а иногда "на объект", всякие магические названия вроде __main или не менее магические названия приавтных членов класса, геттеров/сеттеров, кваргсы и тд - те когда нет четкой и жесткой структуры работы.
Делал на ATTINY85, BluePill для такого это даже не оверинженеринг, а гораздо хуже )
А где я писал, что что-то не описано в документации? )
Ну и описанная магия магией быть не перестает.
Я преподавал и много, для себя вывел следующее - лучший язык для понимания - это Си, без плюсов.
Потому как там четкая система типов, указатели (очень важная штука для хорошего программиста), а при левелапе можно и ООП настоящее дать, но уже в плюсах.
То, что в статье - полностью согласен.
Про Python могу очень много плохого наговорить с аргументами, его преподносят часто как "гораздо лучший, чем лапшистый и с кучей магии PHP", а по факту лапши и магии там в разы больше. Я не люблю ни тот, ни тот, но, к сожалению, ввиду того что Python преподается практически во всех университетах мира, он стал стандартом де-факто, увы.