Тоже верно. Но это уже другая проблема. Если сервис будет давать лучший результат, то на него перейдут. История с Tinder'ом как раз хорошо это показывает. Его начали отменять и переходить на альтернативные платформы.
Я работаю в сфере электроники. Не совсем IT, но близко. Мы помогаем делать железо на котором IT крутится (как IoT, так промышленное и автомобильное). Так же зачастую когда мы предлагаем решение, где софтовая составляющая входит к него часть. Я к.т.н.(PhD) и даже получил инженера года в регионе EMEA в своей компании. И при этом сталкиваюсь с большинством подобных проблем. Но, немного с другой стороны. Да, это другой рынок, но проблемы те же.
Главная проблема в том что HR вообще не понимают кого нанимают в 95%. Во всех случаях когда я устраивался куда-либо главной проблемой было пройти HR. Как только доходило до общения с кем-то кто понимает (руководитель отдела, например) и с кем доводилось общаться, он сразу же говорил "берём" и шёл раздавать люлей чтобы взяли. Ручное участие, к сожалению, необходимо, потому что бизнес процессы по найму выстраивал также человек, который не понимает кто реально нужен и делает систему найма общей в соответствии со своими KPI (закрыть быстрее, дешевле, найти звезду ck 100% попаданием, и т.п.). Людей в HR нанимают в соответствии с этими бизнес процессами, а в них зачастую не прописано что нужно разбираться в области в которой ты ведёшь найм. В итоге HR могут творить очень странные вещи, например коллеге, который тоже PhD сказали "у Вас нет профильного образования, зачем нам ваш диплом доктора?". При этом он в отрасли 12 лет и по списку его должностей и компаний становится ясно что опыт у него такой, что любой бы позавидовал. Но, резюме похоже даже не читали.
Вторая проблема в данном случае похожа на первую, но в этот раз с IT стороны. Те кто делал платформы для HR так же не понимают кого нанимают и как именно. Хотя, должны разбираться в этом лучше всех остальных, так как обладают крупнейшим массивами данными. Поэтому интерфейсы сделаны таким образом чтобы показать что платформа работает эффективно (генерирует тысячу откликов за час, позволяет сгенерировать описание вакансии из пары предложений при помощи ИИ, проанализировать резюме за 3 секунды и т.п.). Но, когда доходит до реальных задач оказывается что фильтров для реальной работы с массивом данных просто нет. Никто не видит в этом проблемы так как всё как было задумано. Так и появляется проблема "скрытых работников", которых много, но которых не видят. На Тиндере та же самая проблема, но чуть в другом виде. И в этом тоже нет проблемы для держателей платформ. Что интересно, в комментариях пишут примерно следующее
For Man Tinder is like a job Interview in a big tech, for woman is like shopping with infinity money
Решение достаточно очевидное, но трудно реализуемое. Для того чтобы починить систему необходимо чтобы тот кто писал для неё ТЗ понимал как должна работать система в целом и в деталях. Он должен прописать бизнес процессы, которые в дальнейшем реализуют программисты и будут использовать HR с конечными пользователями. Звучит немного в духе "давайте напишем свой HH с блек-джеком и профурсетками". Но, если задуматься, то только так оно и может работать. Если бизнес-аналитики и проджект менеджеры которые поддерживают платформу не видят проблемы в текущем положении то они и не будут ничего чинить. А они не увидят пока не погрузятся полностью и сами не пройдут весь процесс пару раз :)
Формат UUID используемый в Bluetooth описывается в ISO/IEC 11578. Сам UUID состоит из 2 основных частей: времени и уникального идентификатора (MAC). Если не погружаться глубоко, то см. ru.wikipedia.org/wiki/UUID
Пропустив 00000000-0000-1000-8000-00805F9B34FB через сервис www.famkruithof.net/uuid/uuidgen?typeReq=1 мы получаем первый день Григорианского календаря — Friday, October 15, 1582 at 12:00:00 AM
А последняя часть — MAC-адрес ПК на котором был сгенерирован базовый UUID. Это был HP (на момент регистрации Compaq) https://macaddress.webwat.ch/hwaddr/00:80:5F#simname.
ARM TrustZone — технология, которая позволяет исполнять критичный код в защищённой среде, собственно она поэтому и Trust Zone, что ей можно доверять. В тексте я даю ссылку на статью, где описывается принцип работы — habr.com/ru/company/dsec/blog/478948, чтобы ещё больше не увеличивать размер моей статьи.
CryptoCell — расширение ARM TrustZone, реализующее дополнительные функции аппаратно. В частности это хранилище ключей, ускорители шифрования, генератор случайных чисел, блоки проверки кода, ключей и безопасной отладки. Ссылку на официальное описание также привёл — community.arm.com/developer/ip-products/system/b/embedded-blog/posts/arm-trustzone-cryptocell-312-simplifying-the-design-of-secure-iot-systems
Nordic ответил, что вопрос важен для нескольких клиентов (в отслеживающих я уже троих насчитал) и они ждут решения от DSR.
Похоже, что Вы нашли какой-то баг, который не получается быстро поправить.
Главное, что вопрос не останется без ответа.
Nordic использует стек ZigBee от компании DSR Wireless www.dsr-zboss.com/#!/, основную часть написали, кстати наши соотечественники из Воронежа.
Поэтому можно в значительной степени сказать спасибо им.
Про ZigBee могу сказать, что практически всегда это вещь в себе, каждый затачивает её под себя. В итоге решения разных производителей между собой оказываются не совместимы, даже если формально имеют сертификаты. Поэтому в большинстве случаев от неё сейчас отходят. Больше идёт ориентация на BLE Mesh или Thread в зависимости от задачи. И там и там от SDK отзывы очень позитивные. Стек для BLE хвалят почти все, кого я встречал. Про Thread, как правило, говорят, что он проработан гораздо лучше, чем у конкурентов, несмотря на то, что база общая — OpenThread. Оба тезиса могу подтвердить на личном опыте. Поэтому крайне странно видеть комментарии подобного рода, что не работают такие очевидные вещи. Хотя не исключаю, что это в принципе это возможно. Конкретно с ZigBee я тоже опыта имел не много.
p.s. пришлите ссылку на DevZone, где Вам не отвечают. Я знаю, как их замотивировать =) Стандарт ответа — сутки. Сейчас из-за коронавируса возможно увеличение сроков, но не до таких размеров. Дело в чём-то ином.
Закрывать поддержку nRF5 SDK для существующих проектов Nordic не планирует. За это можно не волноваться. Они даже nRF9E5 до сих пор поддерживают, несмотря на то, что найти на сайте его не просто.
Относительно включения 52 семейства — никто не заставляет переходить новый SDK. Стоит рассматривать это сейчас скорее, как реализацию возможности запуска кода с 91 и 53 семейств на младших семействах. Тем, кто уже сделал проект на новом подходе, может быть интересно перенести его части в новых проектах на более слабые и дешёвые чипы.
Также отмечу, что nRF53 аппаратно ближе к nRF91, так как что проще было реализовать на новом SDK. Здесь всё логично.
Относительно того на чём работать легче — это выбор конкретного разработчика и совокупность его привычек. О чём собственно и статья.
От себя могу отметить, что с CC13xx/CC26xx знаком ещё с момента когда они только ещё появились (Preview были в 2014) и с ними развлечений предостаточно. Если тебе нужно запустить что-то простое, то всё работает до того момента, когда нужно расширить функционал или что-то более-менее серьёзно поправить. Также отмечу, что два ядра СС13xx/CC26xx, равно, как и у ST32WB55 — фиктивные. Для пользователя доступно только одно ядро, другое же является вспомогательным и не доступно для исполнения пользовательского кода. По сути на нём крутится радиостек и ты вызываешь функции для обработки радио. С этой точки зрения это прямые конкуренты nRF52, который использует такую же архитектуру, но не говорит, что у него 2 ядра. Cortex-M33 с его 2 настоящими ядрами — принципиального другая история. Сравнивать с ST и TI их можно будет, когда у них появятся аналогичные решения.
Про WB55 могу сказать, что их решение заметно отстаёт, как от Nordic, так и TI. Ответы на вопросы к последнему семинару (декабрь 2019) Компэла это прямо показали. Причём проблемы именно софтовые. Если железо сделано на уровне, то в плане ПО они традиционно выпустили Cube с GUI, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Тоже верно. Но это уже другая проблема. Если сервис будет давать лучший результат, то на него перейдут. История с Tinder'ом как раз хорошо это показывает. Его начали отменять и переходить на альтернативные платформы.
Я работаю в сфере электроники. Не совсем IT, но близко. Мы помогаем делать железо на котором IT крутится (как IoT, так промышленное и автомобильное). Так же зачастую когда мы предлагаем решение, где софтовая составляющая входит к него часть. Я к.т.н.(PhD) и даже получил инженера года в регионе EMEA в своей компании. И при этом сталкиваюсь с большинством подобных проблем. Но, немного с другой стороны. Да, это другой рынок, но проблемы те же.
Главная проблема в том что HR вообще не понимают кого нанимают в 95%. Во всех случаях когда я устраивался куда-либо главной проблемой было пройти HR. Как только доходило до общения с кем-то кто понимает (руководитель отдела, например) и с кем доводилось общаться, он сразу же говорил "берём" и шёл раздавать люлей чтобы взяли. Ручное участие, к сожалению, необходимо, потому что бизнес процессы по найму выстраивал также человек, который не понимает кто реально нужен и делает систему найма общей в соответствии со своими KPI (закрыть быстрее, дешевле, найти звезду ck 100% попаданием, и т.п.). Людей в HR нанимают в соответствии с этими бизнес процессами, а в них зачастую не прописано что нужно разбираться в области в которой ты ведёшь найм. В итоге HR могут творить очень странные вещи, например коллеге, который тоже PhD сказали "у Вас нет профильного образования, зачем нам ваш диплом доктора?". При этом он в отрасли 12 лет и по списку его должностей и компаний становится ясно что опыт у него такой, что любой бы позавидовал. Но, резюме похоже даже не читали.
Вторая проблема в данном случае похожа на первую, но в этот раз с IT стороны. Те кто делал платформы для HR так же не понимают кого нанимают и как именно. Хотя, должны разбираться в этом лучше всех остальных, так как обладают крупнейшим массивами данными. Поэтому интерфейсы сделаны таким образом чтобы показать что платформа работает эффективно (генерирует тысячу откликов за час, позволяет сгенерировать описание вакансии из пары предложений при помощи ИИ, проанализировать резюме за 3 секунды и т.п.). Но, когда доходит до реальных задач оказывается что фильтров для реальной работы с массивом данных просто нет. Никто не видит в этом проблемы так как всё как было задумано.
Так и появляется проблема "скрытых работников", которых много, но которых не видят. На Тиндере та же самая проблема, но чуть в другом виде. И в этом тоже нет проблемы для держателей платформ. Что интересно, в комментариях пишут примерно следующее
Решение достаточно очевидное, но трудно реализуемое. Для того чтобы починить систему необходимо чтобы тот кто писал для неё ТЗ понимал как должна работать система в целом и в деталях. Он должен прописать бизнес процессы, которые в дальнейшем реализуют программисты и будут использовать HR с конечными пользователями. Звучит немного в духе "давайте напишем свой HH с блек-джеком и профурсетками". Но, если задуматься, то только так оно и может работать. Если бизнес-аналитики и проджект менеджеры которые поддерживают платформу не видят проблемы в текущем положении то они и не будут ничего чинить. А они не увидят пока не погрузятся полностью и сами не пройдут весь процесс пару раз :)
Пропустив 00000000-0000-1000-8000-00805F9B34FB через сервис www.famkruithof.net/uuid/uuidgen?typeReq=1 мы получаем первый день Григорианского календаря — Friday, October 15, 1582 at 12:00:00 AM
А последняя часть — MAC-адрес ПК на котором был сгенерирован базовый UUID. Это был HP (на момент регистрации Compaq) https://macaddress.webwat.ch/hwaddr/00:80:5F#simname.
CryptoCell — расширение ARM TrustZone, реализующее дополнительные функции аппаратно. В частности это хранилище ключей, ускорители шифрования, генератор случайных чисел, блоки проверки кода, ключей и безопасной отладки. Ссылку на официальное описание также привёл — community.arm.com/developer/ip-products/system/b/embedded-blog/posts/arm-trustzone-cryptocell-312-simplifying-the-design-of-secure-iot-systems
Похоже, что Вы нашли какой-то баг, который не получается быстро поправить.
Главное, что вопрос не останется без ответа.
Поэтому можно в значительной степени сказать спасибо им.
Про ZigBee могу сказать, что практически всегда это вещь в себе, каждый затачивает её под себя. В итоге решения разных производителей между собой оказываются не совместимы, даже если формально имеют сертификаты. Поэтому в большинстве случаев от неё сейчас отходят. Больше идёт ориентация на BLE Mesh или Thread в зависимости от задачи. И там и там от SDK отзывы очень позитивные. Стек для BLE хвалят почти все, кого я встречал. Про Thread, как правило, говорят, что он проработан гораздо лучше, чем у конкурентов, несмотря на то, что база общая — OpenThread. Оба тезиса могу подтвердить на личном опыте. Поэтому крайне странно видеть комментарии подобного рода, что не работают такие очевидные вещи. Хотя не исключаю, что это в принципе это возможно. Конкретно с ZigBee я тоже опыта имел не много.
p.s. пришлите ссылку на DevZone, где Вам не отвечают. Я знаю, как их замотивировать =) Стандарт ответа — сутки. Сейчас из-за коронавируса возможно увеличение сроков, но не до таких размеров. Дело в чём-то ином.
Относительно включения 52 семейства — никто не заставляет переходить новый SDK. Стоит рассматривать это сейчас скорее, как реализацию возможности запуска кода с 91 и 53 семейств на младших семействах. Тем, кто уже сделал проект на новом подходе, может быть интересно перенести его части в новых проектах на более слабые и дешёвые чипы.
Также отмечу, что nRF53 аппаратно ближе к nRF91, так как что проще было реализовать на новом SDK. Здесь всё логично.
Относительно того на чём работать легче — это выбор конкретного разработчика и совокупность его привычек. О чём собственно и статья.
От себя могу отметить, что с CC13xx/CC26xx знаком ещё с момента когда они только ещё появились (Preview были в 2014) и с ними развлечений предостаточно. Если тебе нужно запустить что-то простое, то всё работает до того момента, когда нужно расширить функционал или что-то более-менее серьёзно поправить. Также отмечу, что два ядра СС13xx/CC26xx, равно, как и у ST32WB55 — фиктивные. Для пользователя доступно только одно ядро, другое же является вспомогательным и не доступно для исполнения пользовательского кода. По сути на нём крутится радиостек и ты вызываешь функции для обработки радио. С этой точки зрения это прямые конкуренты nRF52, который использует такую же архитектуру, но не говорит, что у него 2 ядра. Cortex-M33 с его 2 настоящими ядрами — принципиального другая история. Сравнивать с ST и TI их можно будет, когда у них появятся аналогичные решения.
Про WB55 могу сказать, что их решение заметно отстаёт, как от Nordic, так и TI. Ответы на вопросы к последнему семинару (декабрь 2019) Компэла это прямо показали. Причём проблемы именно софтовые. Если железо сделано на уровне, то в плане ПО они традиционно выпустили Cube с GUI, где можно быстро собрать проект для старта разработки. Но в реальных условиях предоставляемого функционала зачастую оказывается недостаточно.