С адресом можно решить, добавив специальные команды — установить адрес, сбросить адрес (эту можно сделать широковещательной), прочитать адрес. Чтобы выполнялось последнее, городить полноценный двусторониий обмен даже не нужно, достаточно, добавив транзисторный ключ, шунтировать линию на определенное время при поступлении этой команды. Мастер-устройство, слушая линию, узнает, есть ли для определенного адреса отклик. Перебрав по очереди все адреса, мастер устройство таким образом узнает, устройства с какими id есть на шине. Можно сделать и команду — отзовись, кто без номера — тогда, пока на шине есть хоть один такой слейв, мастеру придет ответ.
Чтобы эффективнее работать с лининей (и проще шунтировать на слейвах), я бы перешел на аткивный низкий уровень, подтягивая на мастере к +12 резистором, а коммутируя транзистором к земле. На слейвах входной транзисторный каскад можно было бы вообще убрать, ограничив напряжение например стабилитроном и высокоомным резистором, а в конце линии прицепить согласующий резистор того же номинала, что и резистор подтяжки в мастере. Тогда подключенные модули не привносили бы сопротивления в линию, являясь высокоомными, а не токовыми входами. Сейчас 254 входных резистора по 30 кОм дают практически 120 Ом нагрузки
Отлично решена проблема синхронизации в условиях, когда оконечные устройства необходимо сделать максимально дешевыми. И наличие технологического режима при старте с постоянной 1 на линии данных — прямо промобразец! Еще бы вообще избавиться от необходимости прошивать константы индивидуально — можно было бы изготавливать массово. Кстати, для большей стабильности можно использовать манчестерское кодирование — там допустимая ошибка — 25%, т.к. бит гарантированно имеет либо 1 переход в течение времени своей передачи.
Насколько я помню выводы, сделанные вдвоем с приятелем из анализа этой системы примерно в те же годы:
а) ID карты хранится не только на ней самой, но и на сервере;
б) любой misbehavior карты в аппарате приводит к немедленному отказу в сервисе на данном аппарате и посылке ID на добавление в черный список (который видимо распространяется по всей сети оконечных устройств);
в) ID можно вынуть из черного списка, позвонив в службу поддержки и сообщив о проблеме в обслуживании;
г) общение с сервером идет в асинхронном режиме, для начала разговора карта валидируется в оффлайне, после прихода отрицательного ответа с сервера соединение разрывается с потерей для СПТ в худшем случае 1-2 единиц;
д) по завершении разговора единицы с карты в бекграунде передаются на сервер — поэтому например появление ее с первозданным количеством единиц в другом таксофоне рано или поздно приводит к событиям б) и г);
е) скорее всего, подобные misbehaviors обрабатываются статистически с привязкой к местам расположения таксофонов (с особым коэффициентом для общаг технических вузов и вблизи от них ;) — с передачей точек, где частота «сбоев» явно выше среднестатистической, в СБ СПТ и далее;
Все «большие» СУБД поддерживают статистику по таблицам и индексам — это по сути, функция плотности вероятности на всем диапазоне индексируемых значений. Соответственно, если ожидается выборка по диапазону, покрытому индексом, планировщик интегрированием плотности по диапазону находит ожидаемое количество строк. Если же вы делаете неиндексируемый table scan, например по вхождению подстроки, данных об ожидаемом количестве записей планировщику принципиально взять неоткуда, и он может сильно ошибиться. Поэтому, а также из-за конечной точности ожидаемых оценок, я смотрю на эти данные, как на информацию к размышлению при анализе и оптимизации запросов к БД, но не стал бы основывать на них логику реализуемой системы.
первичный ключ нужно стараться делать как можно более коротким, поэтому неоправданное использование bigint и GUID там, где достаточно инта — плохая практика. Должны быть веские аргументы их использования — например, частые массированные вставки и удаления, накручивающие identity-генератор, межбазная синхронизация, требующая GUID, использование FILESTREAM файлгруппы итд. И потом, число 100000 взято с потолка — в качестве иллюстрации того, что даже практически необрабатываемое человеком за разумное время количество записей занимает не так уж много памяти под ключи. Если на серверах приложения мало памяти — ограничьте выборку по фильтру 25000 записей — для конечного пользователя это то же самое, что 100000
Это чисто интерфейсное решение, не нужно его пытаться решать на стороне базы данных.
так это решение и не зависит от способа пагинации. Нужно лишь при выборке массива ключей сделать select top 1001 и посмотреть, сколько ключей приехало. Все преимущества отсутствия повторной фильтрации при навигации при этом остаются
Последние 4 цифры всех номеров телефонов обрезаются
лучше бы заменяли на последовательный счетчик уникальных номеров, свой для каждого юзера — типа +7 921 932 AAAA, + 7 921 932 AAAB итд c хранением и резолвом маппинга на клиентском телефоне. На сервере действительно не нужно знать, на какие конкретно номера звонил данный абонент, а вот тот факт, что он разговаривал с одними и теми же лицами, может впоследствии пригодиться (например для обсчета семейных аккаунтов или активации бонусов на другой номер). Если критична живучесть маппинга при смене телефона — его можно хранить/восстанавливать с сервера в зашифрованном составным ключом виде
Интересно, а вы строите граф связности звонков, чтобы, например, понять, что для мужа и жены можно включить опцию Первый номер? Умеете ли обрабатывать другие тарифные опции и вовремя распределять Мегафон-бонусы?
Вообще задача оптимизации тарифа страшно интересная и неоднозначная, если делается не в лоб — то есть не на буквальной интерпретации биллинга за прошлый месяц, а базируясь на построенной статистической модели. Варианты ответа системы в данном случае будут вероятностными — скажем, ожидаемая стоимость vs толерантность к изменению профиля. Тариф при этом может быть не 100% оптимальным для профиля, в точности соответствующего прошедшему месяцу, зато быть устойчивым к статистическим выбросам.
И еще — применяя алгоритмы machine learning к профилям, можно выделить типичные классы пользователей, а значит, рекомендовать на будущее конфигурации, типичные для этих классов. Пример — школьник, который практически не разговаривает в летнее время, а с сентября по май строчит SMS-ами.
Штука клевая, достойна музея электронных раритетов 155ла3. Судя по масштабу шкалы, однако, она одноразовая (либо трубка просто переворачивается) и рассчитана на весь срок службы прибора. Исходя из предела в 2500 часов подозреваю, что индикатор применялся в ламповой технике для оценки необходимости профилактической замены ламп.
Однако, чтобы привести ее масштаб в соответствие с масштабом разряда обычных аккумуляторов, рабочий ток через такой кулонометр придется увеличить на три порядка — т.к. тот объем переноса ртути, который при номинальном токе достигался, скажем, за 2000 часов, должен произойти всего за несколько — иначе шкала прибора будет неинформативной. Подозреваю, что при такой интенсивности электрохимической реакции трубка просто взорвется.
Ччто использовали в качестве средства выделения вектора признаков для детектируемых лиц? В качестве классификатора?
Какая достигнута практическая разрешающая способность системы — то есть какой уровень false positive / false negative при каком количестве людей в базе.
Как проводится (до)обучение классификатора при поступлении нового класса (лица)? Нового сэмпла известного класса? Как боретесь с переобучением и противоречащими данными?
Магнитное поле — штука капризная. Нужно защититься от внешних полей раз, гарантированно точно собрать поле нужного проводника — два, компенсировать нелинейность датчика — три. Кроме того, нужна сама микросхема датчика. Если пользовались токовыми клещами *постоянного* тока, то наверняка видели, как их показания пляшут в зависимости от ориентации относительно земли и самого провода. Чтобы все это работало стабильно — нужен хороший магнитно-экранированный конструктив, где провод закреплен относительно кольцевого магнитопровода, а в зазоре — датчик Холла. В итоге стоимость такого датчика превысит стоимость всей остальрой части системы. Провод- шунт на порядок проще. И импульсы тока в основной цепи ему не страшны — при сопротивлении шутна в 1 миллиом чтобы создать импульс величиной в 1 вольт на входе АЦП, через него должен пройти ток в 1000 Ампер. Но диодная защита входов у меня все равно есть ;)
Еще имхо хорошо бы уметь читать между строк и иметь достаточное воображение, чтобы дополнить или предугадать, в какую сторону затем пойдет изменение требований.
Для многокомпонентных систем (особенно, разрабатываемых разными отделами, чужих компонент, или модулей, общающихся с внешним миром) — нужно подразумевать наличие способов доказательно защитить свою часть от нападок соседей (пригодится при отладке и сдаче всей системы) — то есть заранее заложится на детальное логирования обмена, средства усточивости к некорректным данным итд.
Образно говоря, прочитав в ТЗ указание на постройку двухэтажного дома, и зная алчность хозяина, не забыть оставить сверху хвосты арматуры на случай постройки третьего этажа, и фундамент сделать с запасом ;)
С интегральными VTF-преобразователями все не так однозначно — в моем случае падение напряжение на шунте находится в диапазоне 0-50 милливольт, а выходная частота — 0-50 Гц. Интегральные же преобразователи обычно работают с более широким диапазоном как входного напряжения, так и выходной частоты — это потребует операционного усилителя на входе и делителя частоты на выходе — считайте, плюс еще два корпуса. Кроме того, ноль операционников плывет — нужна калибровка. В моей же реализации калибровка нуля делается автоматически программно при подаче питания — attiny позволяет внутри замкнуть входы дифференциального усилителя, чтобы затем считать код смещения нуля и далее вычитать его из измеренных значений. Все это в программе есть.
Чтобы эффективнее работать с лининей (и проще шунтировать на слейвах), я бы перешел на аткивный низкий уровень, подтягивая на мастере к +12 резистором, а коммутируя транзистором к земле. На слейвах входной транзисторный каскад можно было бы вообще убрать, ограничив напряжение например стабилитроном и высокоомным резистором, а в конце линии прицепить согласующий резистор того же номинала, что и резистор подтяжки в мастере. Тогда подключенные модули не привносили бы сопротивления в линию, являясь высокоомными, а не токовыми входами. Сейчас 254 входных резистора по 30 кОм дают практически 120 Ом нагрузки
а) ID карты хранится не только на ней самой, но и на сервере;
б) любой misbehavior карты в аппарате приводит к немедленному отказу в сервисе на данном аппарате и посылке ID на добавление в черный список (который видимо распространяется по всей сети оконечных устройств);
в) ID можно вынуть из черного списка, позвонив в службу поддержки и сообщив о проблеме в обслуживании;
г) общение с сервером идет в асинхронном режиме, для начала разговора карта валидируется в оффлайне, после прихода отрицательного ответа с сервера соединение разрывается с потерей для СПТ в худшем случае 1-2 единиц;
д) по завершении разговора единицы с карты в бекграунде передаются на сервер — поэтому например появление ее с первозданным количеством единиц в другом таксофоне рано или поздно приводит к событиям б) и г);
е) скорее всего, подобные misbehaviors обрабатываются статистически с привязкой к местам расположения таксофонов (с особым коэффициентом для общаг технических вузов и вблизи от них ;) — с передачей точек, где частота «сбоев» явно выше среднестатистической, в СБ СПТ и далее;
Вообще задача оптимизации тарифа страшно интересная и неоднозначная, если делается не в лоб — то есть не на буквальной интерпретации биллинга за прошлый месяц, а базируясь на построенной статистической модели. Варианты ответа системы в данном случае будут вероятностными — скажем, ожидаемая стоимость vs толерантность к изменению профиля. Тариф при этом может быть не 100% оптимальным для профиля, в точности соответствующего прошедшему месяцу, зато быть устойчивым к статистическим выбросам.
И еще — применяя алгоритмы machine learning к профилям, можно выделить типичные классы пользователей, а значит, рекомендовать на будущее конфигурации, типичные для этих классов. Пример — школьник, который практически не разговаривает в летнее время, а с сентября по май строчит SMS-ами.
Однако, чтобы привести ее масштаб в соответствие с масштабом разряда обычных аккумуляторов, рабочий ток через такой кулонометр придется увеличить на три порядка — т.к. тот объем переноса ртути, который при номинальном токе достигался, скажем, за 2000 часов, должен произойти всего за несколько — иначе шкала прибора будет неинформативной. Подозреваю, что при такой интенсивности электрохимической реакции трубка просто взорвется.
Какая достигнута практическая разрешающая способность системы — то есть какой уровень false positive / false negative при каком количестве людей в базе.
Как проводится (до)обучение классификатора при поступлении нового класса (лица)? Нового сэмпла известного класса? Как боретесь с переобучением и противоречащими данными?
Для многокомпонентных систем (особенно, разрабатываемых разными отделами, чужих компонент, или модулей, общающихся с внешним миром) — нужно подразумевать наличие способов доказательно защитить свою часть от нападок соседей (пригодится при отладке и сдаче всей системы) — то есть заранее заложится на детальное логирования обмена, средства усточивости к некорректным данным итд.
Образно говоря, прочитав в ТЗ указание на постройку двухэтажного дома, и зная алчность хозяина, не забыть оставить сверху хвосты арматуры на случай постройки третьего этажа, и фундамент сделать с запасом ;)