Ну да, ну да, классическое "не делайте как вам удобно, делайте как удобно нам". Мне вот удобно, раз синхронизация работает, для мобильной и десктопной версии одну закладку на сайт иметь, а не плодить их на все случаи жизни.
Не вижу, где тут может быть проблема.
Проблема в удобстве. Чтоб пробежаться по списку новостей в мобильной версии нужно выполнять СЛИШКОМ много действий.
Вы просто разными сайтами пользуетесь.
Вот лично я почитываю, к примеру, Фонтанку. На странице со списком новостей за 24 часа — 3 колонки. Собственно, нужный мне список — средняя колонка. Во время поездки в метро покачивает, мелкий шрифт читать просто невозможно. Если увеличить масштаб до комфортного размера шрифта, колонка не умещается в ширину экрана. Опера при этом после изменения масштаба умещает одну эту колонку в ширину с переносом текста.
Да. Но ровно это же можно написать и «Я просто сказал, что это не всегда не верно.» Задачи разные. Решения разные.
Да. Именно поэтому главное требование к МК, озвученное вами, не главное. Оно всего лишь одно из возможных.
А для управления станком с ЧПУ или автомобильном ЭБУ… Сомневаюсь. Скорее элемент ненадежности.
Элемент ненадёжности — сложный код. Да, от сложного кода тоже можно добиться заданной надёжности, и я не сомневаюсь, что у вас это получается. Но сил на это нужно тратить больше, чем можно было бы.
А я за грамотное проектирование. Если крайне важно удобство разработки и сопровождения, и ради этого можно пожертвовать стоимостью и производительностью
А не всегда это жертва. Я вот разработкой железа не занимался, на выбор МК, а соответственно и на цену железа, повлиять не мог. Работал с тем, что дают. Ресурсов для FreeRTOS не хватало (а может и хватило бы, но ужиматься очень не хотелось) только на одной плате, где был MSP с 512 байтами ОЗУ.
Не плодите очередного монстра «типа легко поддерживаемого». Это не так. Совсем. Этот код только кажется простым и понятным (а соответственно легко поддерживаемым). Причем только Вам.
Нет, этот код и есть простой и понятный. Не нужно обработку чего-либо руками разбивать на мелкие операции, хранить лишние стейты, иметь общий бесконечный цикл, откуда делается управление вообще всем. Код задачи делает только то, что должен.
Я писал и без FreeRTOS. И с нуля, и дорабатывал чужие проекты. И возвращаться к этому я бы не хотел. Может, у меня просто не было учителя, обладающего вашей мудростью =)
И Вы считаете, что раз Вам не надо — значит и никому не надо?
Нет, это вы считаете, что раз вам надо, значит всем надо. Это же вы озвучили главное требование к МК. Я просто сказал, что это не всегда верно.
Если вся логика сделана на обработчиках прерываний
Я вроде не писал такого
А если нет, то время реакции — это не только время обработчика. Это время IPC (те же очереди с почтовыми ящиками) и время за которое нужная задача увидит приход данных, обработает их и отреагирует. Вот и вся недолга.
Да. И когда задач нужно выполнять много "одновременно", кто-то должен следить за переключением. Либо программист, либо система. Когда ресурсов хватает, я за второй вариант. Легче писать, легче поддерживать, легче тестировать отдельно от других задач.
Да и упрощение кода… Господа, блин, неужели я единственный кого коробит xTaskCreate(...) и типы с именами TaskFunction_t?
Это уже вкусовщина, да и к простоте кода не относится. Но лично у меня многое из FreeRTOS было спрятано внутри классов-обёрток.
главное требование к которым максимально быстрое реагирование на «внешние раздражители»
Далеко не всегда это нужно. В моей практике не было ни одного проекта, где бы требовалось "считать такты".
FreeRTOS это просто переключалка задач по сути, на время реакции (если речь о прерываниях) она не влияет, там накладные расходы — память (стек у каждой задачи свой) и процессорное время в момент переключения контекста. Зато она позволяет очень сильно упростить код.
Область видимости на самом деле не предлагают выбирать, если загружать документ сразу в чатике. Но да, похоже, мои сведения устарели, по крайней мере последние загруженные мной в личных сообщениях документы закрыты для поиска.
Как это неуменьшенную? Разве ВК умеет отдавать фотки разрешением больше, чем 2560*xxxx?
В ВК можно передавать фотки как документы, тогда они не будут пережиматься. Но документы доступны любому желающему через поиск.
Немножко про свой опыт напишу. На прошлых работах несколько раз делал свои шаблонные библиотечки для работы с периферией МК. Использовался IAR, как-то ограниченно поддерживавший c++ (для Renesas 78K0R и в 2017 всё было ещё очень плохо). Сейчас наверное то же самое делать было бы гораздо удобней.
Для начала хотелось избавиться от того, что мне не нравилось в чужих проектах, написанных преимущественно на голом си. Самое неприятное — работа с периферией обычно делалась напрямую через регистры, и код был сильно размазан по проекту. Просто взять и найти поиском, где идёт общение с каким-нибудь устройством, или определить, с каким именно идёт работа в данной конкретной строчке без комментариев было очень непросто. Или вот в порт одного устройства скармливались константы, определённые для совершенно другого. И компилятор проглатывал. Код даже работал, пока не приходилось что-то менять. Там же, где работа с оборудованием как-то абстрагировалась, генерировалось много лишнего и обычно неиспользуемого кода.
В первых версиях (для LPC2xxx от NXP) я всю работу с периферией реализовывал самостоятельно и был полностью доволен результатом. Всё оборудование описывалось в одном условном "hardwarecfg.cpp" как глобальные объекты и инициализировалось в конструкторах. Ещё помню, сначала даже использовал дурацкий хак, чтоб размещать эти объекты за пределами ОЗУ дабы сэкономить место. Были реализованы классы для gpio, uart, spi, adc, pll, таймеров, но доступны они были только через тайпдефы внутри класса cpu и зависели от его настроек. Ну то есть при смене процессора могло получиться так, что новый не имеет нужного порта, и компилятор сразу об этом скажет. Разные константы считались в компайлтайме (например для настройки скорости uart нужно было три константы выбрать просто полным перебором, без этого можно было вычислить лишь очень грубое приближение), а ещё проверки всякие вроде ограничения на частоту процессора при включенной поддержке usb. А классы для внешнего оборудования использовали в свою очередь объекты внутреннего.
Первый раз я понял, что что-то не учёл, когда пришлось добавлять поддержку МК того же семейства, но с совершенно по-другому устроенной частью периферии. Пришлось переписать библиотеку.
На другой работе пришлось работать с упомянутыми в начале 78K0R. Уж не помню почему, может из-за особенностей использования прерываний, а может просто потому что постепенно переделывал старые проекты, но я сделал библиотечку гораздо проще. Теперь уже ничего не зависело от проца и его настроек, а мои классы использовали функции, генерируемые конструктором библиотек от производителя. Большой минус — если поменять проц, компиляция могла сломаться просто оттого, что в моей библиотеке инстанцировались шаблоны для несуществующего оборудования =( Но основной упор был сделан на то, чтоб вместо реального железа можно было очень легко подсунуть что-нибудь другое. В итоге последние проекты отлаживались по большей части полностью на ПК. Особенно это помогло отлаживать устройства, общающиеся с соседними и перемещающиеся в пространстве сообща — в железе такое отлаживать больно. И вот этому, я считаю, нужно уделять внимание при разработке подобных библиотек в первую очередь.
Вот самые-самые последние версии Chrome я не пробовал, но почему-то мне кажется, что не выпилили. Когда на странице включены некоторые эффекты, активно используется аппаратное ускорение, и сглаживание переключается на grayscale. Попробуйте добавить стиль
Есть возможность. Нужно запустить браузер с ключом --debug-packed-apps и открывать devtools через контекстное меню мыши.
edit: прошу прощения, забыл, что ветка о версии под Android
Не только в IT. Вспомнился крик души Александра Маркова:
Дорогие литературные редакторы, работающие с текстом после научной редактуры! Спасибо вам за то, что вы стараетесь сделать текст лучше. Но, пожалуйста, запомните уже наконец: НЕ НАДО ПО ВСЕМУ ТЕКСТУ МЕНЯТЬ "ИСКОПАЕМЫЕ ОСТАТКИ" НА ИСКОПАЕМЫЕ ОСТАНКИ"! В палеонтологии говорят и пишут "ископаемые остатки".
Не знаю, что там у ФВ, но Nokia это делает в соответствии с местным законодательством.
Избранные компании — это те, чьи решения прошли сертификацию в ФСБ.
Edit: наверное надо было уточнить, я имел в виду больше не сами "коробочки" СОРМ, а их поддержка в телеком-оборудовании и ПО.
Те же Ericsson и Huawei точно так же поддерживают СОРМ. Не только МТС, а все остальные операторы в РФ точно так же используют СОРМ. В других странах есть свои аналоги СОРМ и они точно так же обязательны к поддержке, если компания хочет присутствовать на соответствующем рынке.
Фразу "сотрудник компании подключил свой рабочий диск со старыми документами к домашнему ПК" наверное стоит понимать как "синхронизировал с домашним ПК по сети". Вынимать диск из компа смысла нет — он шифрованный, а внешние накопители не поощряются. С другой стороны, рсинк тоже не одобрен вроде.
Ну да, ну да, классическое "не делайте как вам удобно, делайте как удобно нам". Мне вот удобно, раз синхронизация работает, для мобильной и десктопной версии одну закладку на сайт иметь, а не плодить их на все случаи жизни.
Проблема в удобстве. Чтоб пробежаться по списку новостей в мобильной версии нужно выполнять СЛИШКОМ много действий.
Вы просто разными сайтами пользуетесь.
Вот лично я почитываю, к примеру, Фонтанку. На странице со списком новостей за 24 часа — 3 колонки. Собственно, нужный мне список — средняя колонка. Во время поездки в метро покачивает, мелкий шрифт читать просто невозможно. Если увеличить масштаб до комфортного размера шрифта, колонка не умещается в ширину экрана. Опера при этом после изменения масштаба умещает одну эту колонку в ширину с переносом текста.
Да. Именно поэтому главное требование к МК, озвученное вами, не главное. Оно всего лишь одно из возможных.
Элемент ненадёжности — сложный код. Да, от сложного кода тоже можно добиться заданной надёжности, и я не сомневаюсь, что у вас это получается. Но сил на это нужно тратить больше, чем можно было бы.
А не всегда это жертва. Я вот разработкой железа не занимался, на выбор МК, а соответственно и на цену железа, повлиять не мог. Работал с тем, что дают. Ресурсов для FreeRTOS не хватало (а может и хватило бы, но ужиматься очень не хотелось) только на одной плате, где был MSP с 512 байтами ОЗУ.
Нет, этот код и есть простой и понятный. Не нужно обработку чего-либо руками разбивать на мелкие операции, хранить лишние стейты, иметь общий бесконечный цикл, откуда делается управление вообще всем. Код задачи делает только то, что должен.
Я писал и без FreeRTOS. И с нуля, и дорабатывал чужие проекты. И возвращаться к этому я бы не хотел. Может, у меня просто не было учителя, обладающего вашей мудростью =)
Нет, это вы считаете, что раз вам надо, значит всем надо. Это же вы озвучили главное требование к МК. Я просто сказал, что это не всегда верно.
Я вроде не писал такого
Да. И когда задач нужно выполнять много "одновременно", кто-то должен следить за переключением. Либо программист, либо система. Когда ресурсов хватает, я за второй вариант. Легче писать, легче поддерживать, легче тестировать отдельно от других задач.
Это уже вкусовщина, да и к простоте кода не относится. Но лично у меня многое из FreeRTOS было спрятано внутри классов-обёрток.
Далеко не всегда это нужно. В моей практике не было ни одного проекта, где бы требовалось "считать такты".
FreeRTOS это просто переключалка задач по сути, на время реакции (если речь о прерываниях) она не влияет, там накладные расходы — память (стек у каждой задачи свой) и процессорное время в момент переключения контекста. Зато она позволяет очень сильно упростить код.
Задеприкейтили?
Он не проверил, не будет ли последовательность меняться в будущем
Область видимости на самом деле не предлагают выбирать, если загружать документ сразу в чатике. Но да, похоже, мои сведения устарели, по крайней мере последние загруженные мной в личных сообщениях документы закрыты для поиска.
Дохнущий айбиэмовский винт стал поводом для девушки, с которой я познакомился в Фидонет, прийти ко мне в гости за помощью. Поженились в итоге.
Как это неуменьшенную? Разве ВК умеет отдавать фотки разрешением больше, чем 2560*xxxx?
В ВК можно передавать фотки как документы, тогда они не будут пережиматься. Но документы доступны любому желающему через поиск.
Немножко про свой опыт напишу. На прошлых работах несколько раз делал свои шаблонные библиотечки для работы с периферией МК. Использовался IAR, как-то ограниченно поддерживавший c++ (для Renesas 78K0R и в 2017 всё было ещё очень плохо). Сейчас наверное то же самое делать было бы гораздо удобней.
Для начала хотелось избавиться от того, что мне не нравилось в чужих проектах, написанных преимущественно на голом си. Самое неприятное — работа с периферией обычно делалась напрямую через регистры, и код был сильно размазан по проекту. Просто взять и найти поиском, где идёт общение с каким-нибудь устройством, или определить, с каким именно идёт работа в данной конкретной строчке без комментариев было очень непросто. Или вот в порт одного устройства скармливались константы, определённые для совершенно другого. И компилятор проглатывал. Код даже работал, пока не приходилось что-то менять. Там же, где работа с оборудованием как-то абстрагировалась, генерировалось много лишнего и обычно неиспользуемого кода.
В первых версиях (для LPC2xxx от NXP) я всю работу с периферией реализовывал самостоятельно и был полностью доволен результатом. Всё оборудование описывалось в одном условном "hardwarecfg.cpp" как глобальные объекты и инициализировалось в конструкторах. Ещё помню, сначала даже использовал дурацкий хак, чтоб размещать эти объекты за пределами ОЗУ дабы сэкономить место. Были реализованы классы для gpio, uart, spi, adc, pll, таймеров, но доступны они были только через тайпдефы внутри класса cpu и зависели от его настроек. Ну то есть при смене процессора могло получиться так, что новый не имеет нужного порта, и компилятор сразу об этом скажет. Разные константы считались в компайлтайме (например для настройки скорости uart нужно было три константы выбрать просто полным перебором, без этого можно было вычислить лишь очень грубое приближение), а ещё проверки всякие вроде ограничения на частоту процессора при включенной поддержке usb. А классы для внешнего оборудования использовали в свою очередь объекты внутреннего.
Первый раз я понял, что что-то не учёл, когда пришлось добавлять поддержку МК того же семейства, но с совершенно по-другому устроенной частью периферии. Пришлось переписать библиотеку.
На другой работе пришлось работать с упомянутыми в начале 78K0R. Уж не помню почему, может из-за особенностей использования прерываний, а может просто потому что постепенно переделывал старые проекты, но я сделал библиотечку гораздо проще. Теперь уже ничего не зависело от проца и его настроек, а мои классы использовали функции, генерируемые конструктором библиотек от производителя. Большой минус — если поменять проц, компиляция могла сломаться просто оттого, что в моей библиотеке инстанцировались шаблоны для несуществующего оборудования =( Но основной упор был сделан на то, чтоб вместо реального железа можно было очень легко подсунуть что-нибудь другое. В итоге последние проекты отлаживались по большей части полностью на ПК. Особенно это помогло отлаживать устройства, общающиеся с соседними и перемещающиеся в пространстве сообща — в железе такое отлаживать больно. И вот этому, я считаю, нужно уделять внимание при разработке подобных библиотек в первую очередь.
Видел, как пьяную бабульку полицейские до дома подвезли. А она им вслед материлась потом долго.
Вот самые-самые последние версии Chrome я не пробовал, но почему-то мне кажется, что не выпилили. Когда на странице включены некоторые эффекты, активно используется аппаратное ускорение, и сглаживание переключается на grayscale. Попробуйте добавить стиль
Упражнения на координацию — это да. Было, например, исследование о влияние занятий на батутах на когнитивные способности пожилых.
Есть возможность. Нужно запустить браузер с ключом
--debug-packed-appsи открывать devtools через контекстное меню мыши.edit: прошу прощения, забыл, что ветка о версии под Android
Не только в IT. Вспомнился крик души Александра Маркова:
Не знаю, что там у ФВ, но Nokia это делает в соответствии с местным законодательством.
Избранные компании — это те, чьи решения прошли сертификацию в ФСБ.
Edit: наверное надо было уточнить, я имел в виду больше не сами "коробочки" СОРМ, а их поддержка в телеком-оборудовании и ПО.
Те же Ericsson и Huawei точно так же поддерживают СОРМ. Не только МТС, а все остальные операторы в РФ точно так же используют СОРМ. В других странах есть свои аналоги СОРМ и они точно так же обязательны к поддержке, если компания хочет присутствовать на соответствующем рынке.
Фразу "сотрудник компании подключил свой рабочий диск со старыми документами к домашнему ПК" наверное стоит понимать как "синхронизировал с домашним ПК по сети". Вынимать диск из компа смысла нет — он шифрованный, а внешние накопители не поощряются. С другой стороны, рсинк тоже не одобрен вроде.
Не в истории она ищется на другом браузере, а в списке открытых вкладок — меню под кнопкой со значком облака.