Кстати, есть ситуации когда формально код ревью есть, а фактически его нет. Т.е. код никто серьезно не читает, и все ждут когда кто-нибудь один подтвердит, чтобы потом успокаивать себя тем, что "ну он же посмотрел, значит все ок". Тем временем первый человек из категории тех, которые никогда ничего не находят на код ревью.
Там вроде не нарушены, а просто затронуты. Это чистая логика судопроизводства, все кодексы эту идею повторяют. Суд не может разрешить твои права, не обеспечив тебе право на участие в процессе (в каком-либо виде). Процесс - состязательный.
В общем тут истцы - не прокуратура. И я бы не рассматривал ситуацию как фильмы ужасов, где где главный антагонист всегда без особых хлопот оказывается за спиной у протагониста. Со стороны истца тоже много проблем и сложностей, там ниже кто-то уже указывал.
Если не заявит, то преюдиции не будет. В их же интересах заявить, иначе автор может просто на другой площадке это разместить, и вообще оспорить в рамках отдельного производства, а потом повторно разместить. Хотя могу каких-то ньюансов не знать, уже давно не практикую и тема не совсем моя. Это рассуждения чисто из теории процесса.
Сразу видно опытный человек, а не вот это вот всё (то что выше понаписано)! Пока что самый грамотный комментарий по юридической стороне вопроса, из тех что успел прочитать.
Я думаю его привлекут третьим лицом на стороне ответчика (это стандартная практика), если не соответчиком, суд предложит и вряд ли истец откажется, уж в качестве третьего лица точно.
У них емаил указан в контактах. Направление на него письма, является надлежащими ответом на их письмо (по форме). Содержание тоже адекватное: вы говорите информация недостоверная? - ок, укажите какая, мы исправим (ошибки, действительно, возможны). Но в целом, в суд они все равно могут подать, потому что физически могут и для них это небольшие затраты, а для автора все-таки неприятность и другим наука. Полагаю это будет арбитражный суд, там качественно дела разрешают, спасибо бывшему председателю А.А. Иванову, очень хорошую систему выстроил!
Тоже оценил "элегантность" решения. В dismiss теперь надо передавать параметр! Т.е. это не метод конкретного экрана блокировки или его родителя. Ну и также остался вопрос, с закрытием экрана блокировки PIN/PUK, а кто для него вызвал тогда метод?! Я бы скорее подумал, что все таки dismiss грохал весь стэк. И теперь сделали, чтобы метод грохал не весь стэк а только конкретный экран, который и был разблокирован. В общем медведя на велосипеде с костылем все вспомнили
Сеньор С++ - это самозванец? Любой адекватный собеседующий, понимающий дефицит спецов на рынке, с руками оторвет! Человек готов выучить новый язык, хочет расти и развиваться - просто золотой кадр. У многих в голове засела навязчивая идея - найти серебряную пулю, которая сразу закроет кадровый дефицит, а надо уметь работать с тем что есть на рынке. По моему опыту реально рабочих варианта два: 1) взять и выучить студента; 2) переучить спеца со смежной специальности.
Мне из последнего про операционки, архитектуру и обработку событий понравилась книжка Miro Samek - PSiCC2. Сначала я нашел его сайт (state-machine.com), потом статьи, потом книжку. Сам его фрэймворк мне не оч зашел по различным причинам, но идеи я использую. Его подход к использованию такого инструмента как RTOS мне ближе всего оказался.
Это просто наблюдение из жизни, у нас большая команда разработчиков, но большинство сходу не объяснят наследование приоритетов. Трудно сказать о чем это говорит, ну а RTOS используется потому что есть, "Я человек простой: вижу API - использую". Но про наследование приритетов реально не все вникают, а встретить его на этапе проектирования - вообще редкость, максимум это когда уже решаешь какую-то проблему с отзывчивостью.
В тех проектах где я работал(аю), данная проблема не проявлялась. Но и в целом я не сторонник большого количества задач в системе, где возникает необходимость мьютексов и такие запутанные случаи с ними. Последнее время я предпочитаю сбалансированный подход, стараясь внутри задачи организовать Event Driven архитектуру и минимизируя тем самым количество задач.
Мое личное наблюдение, что далеко не каждый разработчик знает чем отличаются мьютекс и семафор, и уж тем более сможет сходу объяснить зачем нужно наследование приоритетов на классическом примере из трех задач.
В TNeo мне больше понравилось то, что автор покрыл его тестами и внедрил фраймворк Ceedling. Также у него есть несколько статей по проведенным оптимизациям. И отдельно есть статья наподобие вашей про организацию прерываний и стэка прерываний, с особенностями реализации на PIC где нет таких удобств как у Cortex-M3.
Кстати, вот вы упомянули про аж целых два прерывания, а на самом деле нужно только одно и второе во фриртосе используется исключительно для поддержания совместимости с ядрами в которых есть ММU. И в порте для кортекса М3, например, vPortSVCHandler только один раз вызывается при старте планировщика, и более никогда. Они и сами, кстати, тоже самое что и я объясняют. Вообще supervisor call это именно для ММU, ну насколько я в этом для себя разобрался. То что вы смотрите на фриртос это хорошо, но для обобщения лучше иметь больше одного примера. Посмотрите еще на TNeo (это развитие энтузиастом проекта TnKernel).
Я бы даже больше сказал, что хороший спикер это хороший спикер, а хороший программист это хороший программист, эти области пересекаются, но не всгеда спикер именно представитель этого пересечения.
Это же физика, а не религия. Мало ли что кажется. Если предположить, что драйвер сможет с такой обратной связью работать, то ток через светодидиоды упадет примерно в 3.5 раза. Допустим светодиоды продолжат работать на условно линейном участке ВАХ, тогда электрическая мощность лампы упадет в 3.5-4 раза. И опять же если предположить что на этом участке светоотдача линейна, то и светвовой поток снизится в 3.5-4 раза. Но это все нужно проверять либо по документации, либо экспериментально.
Достаточно в назначении платежа указать что-нибудь подобное, и как минимум со счетом получателя возникнут проблемы в виде блокировки/ограничения транзакций. Где-то же была история, как кому-то отправили несколько переводов по 1р с соответствующими сообщениями, а он потом мучился, пытаясь разблокировать счет…
Давно было дело по памяти пишу. На stm32F102CBT делал устройство, которое цифрует сигнал и гонит данные по USB bulk. К сожалению нигде не записал результаты тестирования, но что-то в районе 7 000 000 b/s чистыми данными получилось выжать. Помню, что почти подобрался к теоретическому максимуму в 8 Mb/s. Размер bulk транзацкции у меня был 1024, и с учетом что каждый новый фрэйм стартует раз в 1мс, как раз и получается что чистых данных по bulk 8 Mb/s.
Кстати, есть ситуации когда формально код ревью есть, а фактически его нет. Т.е. код никто серьезно не читает, и все ждут когда кто-нибудь один подтвердит, чтобы потом успокаивать себя тем, что "ну он же посмотрел, значит все ок". Тем временем первый человек из категории тех, которые никогда ничего не находят на код ревью.
Там вроде не нарушены, а просто затронуты. Это чистая логика судопроизводства, все кодексы эту идею повторяют. Суд не может разрешить твои права, не обеспечив тебе право на участие в процессе (в каком-либо виде). Процесс - состязательный.
В общем тут истцы - не прокуратура. И я бы не рассматривал ситуацию как фильмы ужасов, где где главный антагонист всегда без особых хлопот оказывается за спиной у протагониста. Со стороны истца тоже много проблем и сложностей, там ниже кто-то уже указывал.
Если не заявит, то преюдиции не будет. В их же интересах заявить, иначе автор может просто на другой площадке это разместить, и вообще оспорить в рамках отдельного производства, а потом повторно разместить. Хотя могу каких-то ньюансов не знать, уже давно не практикую и тема не совсем моя. Это рассуждения чисто из теории процесса.
А вот и зря! Арбитражные суды очень качественно работают со времен господина Иванова! На личном опыте неоднократно убеждался!
Сразу видно опытный человек, а не вот это вот всё (то что выше понаписано)! Пока что самый грамотный комментарий по юридической стороне вопроса, из тех что успел прочитать.
Я думаю его привлекут третьим лицом на стороне ответчика (это стандартная практика), если не соответчиком, суд предложит и вряд ли истец откажется, уж в качестве третьего лица точно.
У них емаил указан в контактах. Направление на него письма, является надлежащими ответом на их письмо (по форме). Содержание тоже адекватное: вы говорите информация недостоверная? - ок, укажите какая, мы исправим (ошибки, действительно, возможны). Но в целом, в суд они все равно могут подать, потому что физически могут и для них это небольшие затраты, а для автора все-таки неприятность и другим наука. Полагаю это будет арбитражный суд, там качественно дела разрешают, спасибо бывшему председателю А.А. Иванову, очень хорошую систему выстроил!
Тоже оценил "элегантность" решения. В dismiss теперь надо передавать параметр! Т.е. это не метод конкретного экрана блокировки или его родителя. Ну и также остался вопрос, с закрытием экрана блокировки PIN/PUK, а кто для него вызвал тогда метод?! Я бы скорее подумал, что все таки dismiss грохал весь стэк. И теперь сделали, чтобы метод грохал не весь стэк а только конкретный экран, который и был разблокирован. В общем медведя на велосипеде с костылем все вспомнили
Сеньор С++ - это самозванец? Любой адекватный собеседующий, понимающий дефицит спецов на рынке, с руками оторвет! Человек готов выучить новый язык, хочет расти и развиваться - просто золотой кадр. У многих в голове засела навязчивая идея - найти серебряную пулю, которая сразу закроет кадровый дефицит, а надо уметь работать с тем что есть на рынке. По моему опыту реально рабочих варианта два: 1) взять и выучить студента; 2) переучить спеца со смежной специальности.
Мне из последнего про операционки, архитектуру и обработку событий понравилась книжка Miro Samek - PSiCC2. Сначала я нашел его сайт (state-machine.com), потом статьи, потом книжку. Сам его фрэймворк мне не оч зашел по различным причинам, но идеи я использую. Его подход к использованию такого инструмента как RTOS мне ближе всего оказался.
Придется другие комменты заплюсовать - замолить грехи)))
Это просто наблюдение из жизни, у нас большая команда разработчиков, но большинство сходу не объяснят наследование приоритетов. Трудно сказать о чем это говорит, ну а RTOS используется потому что есть, "Я человек простой: вижу API - использую". Но про наследование приритетов реально не все вникают, а встретить его на этапе проектирования - вообще редкость, максимум это когда уже решаешь какую-то проблему с отзывчивостью.
За ссылки, спасибо, почитаю!
В тех проектах где я работал(аю), данная проблема не проявлялась. Но и в целом я не сторонник большого количества задач в системе, где возникает необходимость мьютексов и такие запутанные случаи с ними. Последнее время я предпочитаю сбалансированный подход, стараясь внутри задачи организовать Event Driven архитектуру и минимизируя тем самым количество задач.
Мое личное наблюдение, что далеко не каждый разработчик знает чем отличаются мьютекс и семафор, и уж тем более сможет сходу объяснить зачем нужно наследование приоритетов на классическом примере из трех задач.
В TNeo мне больше понравилось то, что автор покрыл его тестами и внедрил фраймворк Ceedling. Также у него есть несколько статей по проведенным оптимизациям. И отдельно есть статья наподобие вашей про организацию прерываний и стэка прерываний, с особенностями реализации на PIC где нет таких удобств как у Cortex-M3.
Кстати, вот вы упомянули про аж целых два прерывания, а на самом деле нужно только одно и второе во фриртосе используется исключительно для поддержания совместимости с ядрами в которых есть ММU. И в порте для кортекса М3, например, vPortSVCHandler только один раз вызывается при старте планировщика, и более никогда. Они и сами, кстати, тоже самое что и я объясняют. Вообще supervisor call это именно для ММU, ну насколько я в этом для себя разобрался. То что вы смотрите на фриртос это хорошо, но для обобщения лучше иметь больше одного примера. Посмотрите еще на TNeo (это развитие энтузиастом проекта TnKernel).
Я бы даже больше сказал, что хороший спикер это хороший спикер, а хороший программист это хороший программист, эти области пересекаются, но не всгеда спикер именно представитель этого пересечения.
Это же физика, а не религия. Мало ли что кажется. Если предположить, что драйвер сможет с такой обратной связью работать, то ток через светодидиоды упадет примерно в 3.5 раза. Допустим светодиоды продолжат работать на условно линейном участке ВАХ, тогда электрическая мощность лампы упадет в 3.5-4 раза. И опять же если предположить что на этом участке светоотдача линейна, то и светвовой поток снизится в 3.5-4 раза. Но это все нужно проверять либо по документации, либо экспериментально.
Ошибка в обработчике ошибок, как мило)) ИМХО 90% кода обрабатывающего ошибки не работает, если этот код проверялся только в голове у программиста.
Не хватило только ошибки в протоколах безопасности, чтобы фэйл совсем эпичным вышел.