А может мне кто-нибудь объяснить, в чем фишка каждую неделю делать анализ этого мессенджера, если в конечном итоге все равно никто не знает, что происходит на бэкенде?
Вскоре все успокоятся и желающих "потыкать веточкой" поубавится. Большая часть пользователей будет убеждена, что в коде ничего страшного не найдено, исследователи не получая должного хайпа затихнут. Бдительность усыплена, теперь можно в обновлениях вливать дополнительную функциональность, благо разрешения есть.
Коллеги как то делали на ПЛК110 Овен только обжарку кофе. Ну так не хватило 6МБ
Это промышленное. Если сравнивать с этим, то тогда и по теме - управление теплицами на ферме. Здесь же - домашняя поливалка цветов и пользователь не видевший ничего сложнее лейки.
Память, в которую влезут абсолютно все рецепты в мире, стоит как несколько чашек кофе.
Пользователю дома не нужны все рецепты мира. После того как он наиграется, в работе остаются 2-3 ежедневных рецепта. Можно использовать как маркетинговую фишку, но, сомневаюсь, что всей емкостью будут активно пользоваться.
Ему бы теперь "упаковку рюкзака" решать в этой задаче, когда посуды больше чем влезает. И чтобы отмылось. Кучей навалить это у меня любой в семье может.
Практических советов и конкретных рекомендаций и не ожидалось. Хорошая аналогия чтобы оценить свою ситуацию. Достаточно понять - стабильно и хорошо, или равновесие неустойчивое. Или нащупать причины нынешних неудобств. Большего не надо для начала.
Этот был первый. Работал пока резинки не сгнили и не стерлись. Менялись аккумуляторы, умелец сразу же перепаял светодиоды на синенькие. Неубиваемая. Сменилась только когда вышла нокия такая же резиновая с цветным экраном, и тоже жила очень долго.
Для дома я бы в аварийной ситуации просто обесточивал систему. Слишком мокро - возможно будет выливаться из горшка. Слишком сухо - возможно трубка полива вывалилась из горшка и льет на пол. Лучше цветочки засохнут, чем залить соседей. Но это моё субъективное мнение.
Для себя - все цветы в поддоне, объем заведомо больше резервуара. Объем резервуара достаточен для всего срока отсутствия. Датчик протечки в поддоне, контроль уровня в резервуаре, мониторинг питания, контроль объема налива - при выходе за допустимые значения СМС на телефон "я сделал все что мог", переход в аварийный режим (смотря какой отказ) и попытка дотянуть пока едет помощь.
Понимаю, что тут перебор по функциональности и паранойя зашкаливает, но у меня это игрушка, я так пар после работы спускаю.
А то ведь такой ужас! Снимает пользователь видео, а ему вдруг смартфон заявляет, что память закончилась. Очень интересно, какой же дизайн собрались предложить для этого Вы? )))
О, как это знакомо. Контролировать объемы, не допускать переполнения, предупреждать о нехватке ресурсов - все правильно. Сложно - придумать как это сделать на языке пользователя, чтобы было понятно, не мешало работать и не приводило к неожиданным проблемам.
Было у меня на каком-то предыдущем смартфоне. Программы просто наедались, рос кэш, росли данные. И какая-то мелкая но очень нужная, хоть и редкоиспользуемая программка в одном из своих экранов просто выдавала пустой список вместо моих данных. Через аккаунт на сайте я все вижу, а клиент не показывает. Хорошо, я интуитивно глюки чую (работа такая), память подосвободил, к жизни вернул.
Сумеете предложить грамотный дизайн поливалки с наращиваемым количеством горшков, чтобы любая домохозаяйка справилась - отлично. Требования - любое (пока памяти хватит) количество горшков и любое расписание на каждый (элемент расписания, будильник, тоже отъедает память). Управление - только через меню. Уровень подготовки - нулевой, т.е. не сложнее бытовой техники на кухне.
Я с такими случаями сталкивался. Проще - сразу сказать что 10 горшков, в каждом по 3 расписания. Хочешь больше - бери второе устройство. Хотя как программист я знаю, что можно 15 горшков втолкать с 1 расписанием. Или 5 горшков, но где-то 10 расписаний, где-то 1...
При большом количестве датчиков я бы предпочёл насосам гидроаккумулятор и электромагнитные клапаны, что позволило бы подключать цепочкой, а не звездой. Но это уже дело вкуса.
Думаю, тут достаточно будет резервуара приподнятого на пару метров и самотека. Качать в резервуар по поплавку. В общую магистраль импульсный счетчик воды. Лить в каждый горшок по количеству. Повторная поливка по высыханию, но опять по количеству - этим избегаем проблему перелива из-за медленного смачивания. Аварийные ситуации типа "всегда сухо" или "всегда мокро" переводит горшок в поливку строго определенным минимальным количеством, чтобы только цветок не сдох.
Пользователь: меняет настройки. Программа: падает, настройки несовместимы с количеством памяти. Представить могу, конечно. Но такие шедевры , слава Б-у, не попадались.
Программы попадались, это еще меньшее из зол.
А вот когда так начинает вести себя устройство с 5 кнопками... Хорошо, если есть кнопка (или способ) сброса к заводским настройкам.
Тут чего-то разделили пользователя и программиста. В данном примере есть только программист. Он сконфигурировал поливайку, она либо при компиляции не влезла в память, либо при первом запуске завалилась.
У пользователя никаких вариантов нет, кроме того, что уже умеет устройство. Поддерживает 10 датчиков, значит в нем уже есть память под них. Даже если сейчас только 2 подключено. Было бы странно докупив еще комплект датчик+насос и выбрав в меню большее количество получить красную лампочку.
В большом количестве случаев похожие задачи (перебрать и переупаковать) вытекают из-за несогласованности части программ. И приходится для чуть ли не каждой функции городить конвертеры. Растет код, падает производительность, растет сложность. А ИИ начинает прятать эти проблемы ("да я тебе щас конвертну, не парься"). В итоге после рефакторинга весь этот код конвертаций и сложных переборов выкидывается, модуль худеет чуть ли не вдвое, ускоряется и перестает глючить. Не говоря уже о повышении удобства дальнейшей работы.
Дополню. Посмотрел графики разряда аккумуляторов. Если две банки дают 5.35, то одна, скорее всего дает половину - 2.675, а на графиках это уже за пределами линейного участка разряда, и дальше крутое пике в ноль. И это уже не рекомендованное состояние по разряду - сильно влияет на износ.
Я упоминаю конкретные случаи, в которых использование динамического выделения памяти не оправдано.
Если у меня две не пересекающиеся задачи, например, показать меню и сохранить настройки, которые требуют по 1Кб памяти, то разумно размещать их временные данные в структурах размещенных по одному и тому же адресу в статически выделенном буфере. Зато я точно знаю, что на эту память больше никто не претендует. И сюрпризов не возникнет, что в очередной запрос у меня почему-то окажется свободными только 900 байт.
Ну и я рассуждаю про себя, а не про пользователя. Для удобства пользователя пусть выделяет себе память динамически, это его задачи.
Конкретно, если рассматривать поливалку, если ей не хватит памяти при статической инициализации, то никакая динамика ее не спасет.
Встречал интересные случаи, когда вроде бы человек оперировал только строками (с динамическим выделением), но из-за интересного расположения переменных в стеке вызова и перекрывающемся времени жизни и немного гуляющего размера МК приходил к ситуации сегментирования кучи. И привет.
Неприятность динамического выделения в двух местах. Первое - это сегментирование. Второе - это привычка им пользоваться забывая про первое.
Если заниматься оптимизацией, то светодиодны для такой игрушки не нужны - есть же целый дисплей. Энкодер тоже лишний - кнопки на "пультиках" вполне выполняют роль навигации. Первая - перемещение по меню, вторая - выбор пункта. Попробуйте заставить ИИ внести изменения в существующий код чтобы исключить эти аппаратные элементы из работы. В проекте очень важна сопровождаемость (возможность вносить изменения).
Трюк с полностью созданием нового кода по новому ТЗ не считается. Представьте, что вы уже внесли в код ручные доработки и хотите их сохранить.
Вскоре все успокоятся и желающих "потыкать веточкой" поубавится. Большая часть пользователей будет убеждена, что в коде ничего страшного не найдено, исследователи не получая должного хайпа затихнут. Бдительность усыплена, теперь можно в обновлениях вливать дополнительную функциональность, благо разрешения есть.
"Была колбаса докторская, стала любительская..."
Это промышленное. Если сравнивать с этим, то тогда и по теме - управление теплицами на ферме. Здесь же - домашняя поливалка цветов и пользователь не видевший ничего сложнее лейки.
Пользователю дома не нужны все рецепты мира. После того как он наиграется, в работе остаются 2-3 ежедневных рецепта. Можно использовать как маркетинговую фишку, но, сомневаюсь, что всей емкостью будут активно пользоваться.
Ему бы теперь "упаковку рюкзака" решать в этой задаче, когда посуды больше чем влезает. И чтобы отмылось. Кучей навалить это у меня любой в семье может.
Практических советов и конкретных рекомендаций и не ожидалось. Хорошая аналогия чтобы оценить свою ситуацию. Достаточно понять - стабильно и хорошо, или равновесие неустойчивое. Или нащупать причины нынешних неудобств. Большего не надо для начала.
Этот был первый. Работал пока резинки не сгнили и не стерлись. Менялись аккумуляторы, умелец сразу же перепаял светодиоды на синенькие. Неубиваемая. Сменилась только когда вышла нокия такая же резиновая с цветным экраном, и тоже жила очень долго.
Мне теперь на Дзэне искать ответ, как при отключениях перебросить денег со счета на карту, чтобы оплатить покупку?
Для себя - все цветы в поддоне, объем заведомо больше резервуара. Объем резервуара достаточен для всего срока отсутствия. Датчик протечки в поддоне, контроль уровня в резервуаре, мониторинг питания, контроль объема налива - при выходе за допустимые значения СМС на телефон "я сделал все что мог", переход в аварийный режим (смотря какой отказ) и попытка дотянуть пока едет помощь.
Понимаю, что тут перебор по функциональности и паранойя зашкаливает, но у меня это игрушка, я так пар после работы спускаю.
О, как это знакомо. Контролировать объемы, не допускать переполнения, предупреждать о нехватке ресурсов - все правильно. Сложно - придумать как это сделать на языке пользователя, чтобы было понятно, не мешало работать и не приводило к неожиданным проблемам.
Было у меня на каком-то предыдущем смартфоне. Программы просто наедались, рос кэш, росли данные. И какая-то мелкая но очень нужная, хоть и редкоиспользуемая программка в одном из своих экранов просто выдавала пустой список вместо моих данных. Через аккаунт на сайте я все вижу, а клиент не показывает. Хорошо, я интуитивно глюки чую (работа такая), память подосвободил, к жизни вернул.
Сумеете предложить грамотный дизайн поливалки с наращиваемым количеством горшков, чтобы любая домохозаяйка справилась - отлично. Требования - любое (пока памяти хватит) количество горшков и любое расписание на каждый (элемент расписания, будильник, тоже отъедает память). Управление - только через меню. Уровень подготовки - нулевой, т.е. не сложнее бытовой техники на кухне.
Я с такими случаями сталкивался. Проще - сразу сказать что 10 горшков, в каждом по 3 расписания. Хочешь больше - бери второе устройство. Хотя как программист я знаю, что можно 15 горшков втолкать с 1 расписанием. Или 5 горшков, но где-то 10 расписаний, где-то 1...
Думаю, тут достаточно будет резервуара приподнятого на пару метров и самотека. Качать в резервуар по поплавку. В общую магистраль импульсный счетчик воды. Лить в каждый горшок по количеству. Повторная поливка по высыханию, но опять по количеству - этим избегаем проблему перелива из-за медленного смачивания. Аварийные ситуации типа "всегда сухо" или "всегда мокро" переводит горшок в поливку строго определенным минимальным количеством, чтобы только цветок не сдох.
Программы попадались, это еще меньшее из зол.
А вот когда так начинает вести себя устройство с 5 кнопками... Хорошо, если есть кнопка (или способ) сброса к заводским настройкам.
Множество пользовательских рецептов - хорошо.
"Пользовательских рецептов 3 из 10 возможных. 7 свободно.
[ДОБАВИТЬ][УДАЛИТЬ]"
- допустимая картинка на экране.
Неужели это не диагностический режим? Это допустимо на этапе конфигурирования. Но это не для "пользователя".
Для устройства, которое используется еще кем-то кроме его создателя, это плохой дизайн.
Не предлагать. Придумайте интерфейс пользователя заново.
Тут чего-то разделили пользователя и программиста. В данном примере есть только программист. Он сконфигурировал поливайку, она либо при компиляции не влезла в память, либо при первом запуске завалилась.
У пользователя никаких вариантов нет, кроме того, что уже умеет устройство. Поддерживает 10 датчиков, значит в нем уже есть память под них. Даже если сейчас только 2 подключено. Было бы странно докупив еще комплект датчик+насос и выбрав в меню большее количество получить красную лампочку.
Это про вас пугают, что будете заменены ИИ, да?
В большом количестве случаев похожие задачи (перебрать и переупаковать) вытекают из-за несогласованности части программ. И приходится для чуть ли не каждой функции городить конвертеры. Растет код, падает производительность, растет сложность. А ИИ начинает прятать эти проблемы ("да я тебе щас конвертну, не парься"). В итоге после рефакторинга весь этот код конвертаций и сложных переборов выкидывается, модуль худеет чуть ли не вдвое, ускоряется и перестает глючить. Не говоря уже о повышении удобства дальнейшей работы.
Дополню. Посмотрел графики разряда аккумуляторов. Если две банки дают 5.35, то одна, скорее всего дает половину - 2.675, а на графиках это уже за пределами линейного участка разряда, и дальше крутое пике в ноль. И это уже не рекомендованное состояние по разряду - сильно влияет на износ.
Я упоминаю конкретные случаи, в которых использование динамического выделения памяти не оправдано.
Если у меня две не пересекающиеся задачи, например, показать меню и сохранить настройки, которые требуют по 1Кб памяти, то разумно размещать их временные данные в структурах размещенных по одному и тому же адресу в статически выделенном буфере. Зато я точно знаю, что на эту память больше никто не претендует. И сюрпризов не возникнет, что в очередной запрос у меня почему-то окажется свободными только 900 байт.
Ну и я рассуждаю про себя, а не про пользователя. Для удобства пользователя пусть выделяет себе память динамически, это его задачи.
Конкретно, если рассматривать поливалку, если ей не хватит памяти при статической инициализации, то никакая динамика ее не спасет.
Встречал интересные случаи, когда вроде бы человек оперировал только строками (с динамическим выделением), но из-за интересного расположения переменных в стеке вызова и перекрывающемся времени жизни и немного гуляющего размера МК приходил к ситуации сегментирования кучи. И привет.
Неприятность динамического выделения в двух местах. Первое - это сегментирование. Второе - это привычка им пользоваться забывая про первое.
Если заниматься оптимизацией, то светодиодны для такой игрушки не нужны - есть же целый дисплей. Энкодер тоже лишний - кнопки на "пультиках" вполне выполняют роль навигации. Первая - перемещение по меню, вторая - выбор пункта. Попробуйте заставить ИИ внести изменения в существующий код чтобы исключить эти аппаратные элементы из работы. В проекте очень важна сопровождаемость (возможность вносить изменения).
Трюк с полностью созданием нового кода по новому ТЗ не считается. Представьте, что вы уже внесли в код ручные доработки и хотите их сохранить.