Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере. После этого можно будет поговорить предметно.
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.
Реально, по номеру телефона? )))))) Вобщем, очередной коммерческий и бесполезный пост из цикла "Я СДЕЛАЛЪ!" не проанализировав нормально рынок, т.к. бесплатного очень много и все работает, часть вообще в докер завернута, нужно только стянуть и запустить.
Из быстрого без головняка это AMMY (кторому пророчили смерть бесчетное количество раз) и ASPIA от нашего соотечественника (очень много именно нужных функций без мишуры и свистелок, малый размер файлов, есть linux/mac/win).
ASPIA вполне пригодна для энтерпрайза, исходники открыты, бесплатна и вообще без своих сервреров, для пробивки NATa в комлекте есть утилитка, разворачивающаяся в полпинка.
И я работаю и ни разу не было необходимости в переносе по словам. Ни у меня, ни у коллег по цеху. Все решается либо wordwrap-ом, либо стрелками.
Там, где нужно больше, нужно использовать IDE с предпросмотром того же MD, а не консольный инструмент, абсолютно не проходящий для данной задачи, насиловать.
А зачем нужно в техническом редакторе фича из полновесного текстового редактора?
Оно и висело 9 лет, потому что технарям оно не нужно от слова "совсем". А остальные не в курсе про FAR :)
Фича это еще и производительность жрет, так как и навигация и выделение становится не тривальной задачей, а редакором FAR можно открывать многомегабайтные файлы - он должен быть прост, как валенок и быстр настолько, насколько он может быть.
Давайте туда еще карту навигации засунем, висящие переносы и ударения :)
Как раз переносы по словам в JSON - это будет дикая боль, говорю как бэкэндер, который JSON-портянки каждый день смотрит. Редактор в FAR - это быстро пробежаться по JSON, причем обычно с word-wrap и вообще без скроллинга, а если надо изучать - открывать надо в соответствующем редакторе, с возможностью скрывать узлы и тд - текстовый редактор вообще не для этого.
Логи точно также отлично смотрятся с word-wrap, а также с помощью ctrl+стрелочки во вьювере, которые сразу скроллируют куда нужно.
Вобщем, каждому инструменту свое, не надо из любого редактора текста пытаться сделать IDE.
А вот что реально не хватает - это форматтеров, как раз того самого, минимизированного до одной строки JSON, у меня для этого бьютификатор прикручен через LUA, а вот нативный был-бы удобнее.
Во-первых рок - очень плохой выбор для неокрепшего ума, поскольку очень эмоционально заряжен, и смысл содержит в словах и образах, а то и вообще скрытый и его необходимо понять. В языках подобная конструкция называется матом. Вобщем, для ребенка очень не очень.
Во-вторых зачем тут MP3? MicroFAT и WAV-out через PWM за глаза - композиций-то чуть-чуть, SD меньше 8 гигов уже и не достать, кратко - ATMEGA/ATTINY + SD + усилок (возможно даже и без него, если негромко и динамик правильный). Алго - композиция доиграла или книжку закрыли - упали в глубокий сон. Для минимизации размера я бы вообще ATTINY85 взял, но там есть проблема с количеством ножек и определением страницы, в вашем случае 1 ножки в режиме ADC + нескольких сопротивлений хватило бы за глаза.
А кто-то может сказать кратко, как сейчас обстоят дела с 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 и тд давно уже живут ф библиотеках и фреймворках), то необходимо посмотреть, а как ее лучше решить не "в лоб" (перебор - это, например, в лоб).
И вот тут нужно либо воспользоваться математиком, который подскажет куда копать, или как раз таки спросить у ЛЛМ - именно не код написать, а про алго и оптимальные пути его решения, потом самому переложить это в код.
И, имхо, правильный инженер должен поступит именно так.
Затем, в сухом остатке остается знание, что при возникновении такого типа задач нужно воспользоваться таким-то алгоритмом. Не нужно инженеру или программисту знать наизусть кучу вещей, которые могут не понадобиться вообще. Нужно лишь понимание где может возникать бутылочное горлышко - а для этого нужна лишь базовая логика, остальное можно будет уточнить или проверить.
Ну и, иногда, решения "в лоб" работают лучше, чем куча хитростей и сложный алго - это тоже надо понимать.
Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере.
После этого можно будет поговорить предметно.
да, да, никогда такого не было и вот опять )))
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.
Реально, по номеру телефона? ))))))
Вобщем, очередной коммерческий и бесполезный пост из цикла "Я СДЕЛАЛЪ!" не проанализировав нормально рынок, т.к. бесплатного очень много и все работает, часть вообще в докер завернута, нужно только стянуть и запустить.
Из быстрого без головняка это AMMY (кторому пророчили смерть бесчетное количество раз) и ASPIA от нашего соотечественника (очень много именно нужных функций без мишуры и свистелок, малый размер файлов, есть linux/mac/win).
ASPIA вполне пригодна для энтерпрайза, исходники открыты, бесплатна и вообще без своих сервреров, для пробивки NATa в комлекте есть утилитка, разворачивающаяся в полпинка.
Речь идёт о том, что при вордврапе в вашем случае отрезается не ровно а по границе слова, это понятно.
Я же говорил про стандартный вордврап.
И я работаю и ни разу не было необходимости в переносе по словам. Ни у меня, ни у коллег по цеху. Все решается либо wordwrap-ом, либо стрелками.
Там, где нужно больше, нужно использовать IDE с предпросмотром того же MD, а не консольный инструмент, абсолютно не проходящий для данной задачи, насиловать.
А зачем нужно в техническом редакторе фича из полновесного текстового редактора?
Оно и висело 9 лет, потому что технарям оно не нужно от слова "совсем". А остальные не в курсе про FAR :)
Фича это еще и производительность жрет, так как и навигация и выделение становится не тривальной задачей, а редакором FAR можно открывать многомегабайтные файлы - он должен быть прост, как валенок и быстр настолько, насколько он может быть.
Давайте туда еще карту навигации засунем, висящие переносы и ударения :)
Как раз переносы по словам в JSON - это будет дикая боль, говорю как бэкэндер, который JSON-портянки каждый день смотрит. Редактор в FAR - это быстро пробежаться по JSON, причем обычно с word-wrap и вообще без скроллинга, а если надо изучать - открывать надо в соответствующем редакторе, с возможностью скрывать узлы и тд - текстовый редактор вообще не для этого.
Логи точно также отлично смотрятся с word-wrap, а также с помощью ctrl+стрелочки во вьювере, которые сразу скроллируют куда нужно.
Вобщем, каждому инструменту свое, не надо из любого редактора текста пытаться сделать IDE.
А вот что реально не хватает - это форматтеров, как раз того самого, минимизированного до одной строки JSON, у меня для этого бьютификатор прикручен через LUA, а вот нативный был-бы удобнее.
Все, что скажу дальше - мое ИМХО)
Во-первых рок - очень плохой выбор для неокрепшего ума, поскольку очень эмоционально заряжен, и смысл содержит в словах и образах, а то и вообще скрытый и его необходимо понять. В языках подобная конструкция называется матом. Вобщем, для ребенка очень не очень.
Во-вторых зачем тут MP3? MicroFAT и WAV-out через PWM за глаза - композиций-то чуть-чуть, SD меньше 8 гигов уже и не достать, кратко - ATMEGA/ATTINY + SD + усилок (возможно даже и без него, если негромко и динамик правильный). Алго - композиция доиграла или книжку закрыли - упали в глубокий сон. Для минимизации размера я бы вообще ATTINY85 взял, но там есть проблема с количеством ножек и определением страницы, в вашем случае 1 ножки в режиме ADC + нескольких сопротивлений хватило бы за глаза.
В-третьих - картинки, ну про них уже сказали.
А кто-то может сказать кратко, как сейчас обстоят дела с 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
Хотя, исходя из парадигмы, это должно работать и в его поделии.
Ну и не забарсывайте это дело - вещь шужная и полезная в текущем зоопарке фреймворков.