@StrangeAttractor Ну, теоретически, конечно - да. Но в случае с JPEG это давно стало практически не актуально, т.к. файл обрабатывается целиком, т.е. когда все данные "уже есть" (как правило, на носителе с произвольным доступом). Для примера, в том же MP3 метаданные вполне себе стандартно могут находиться в хвосте и никого это особенно не смущает. Такой подход принципиально важен только для стрима или для носителя с последовательным доступом, типа магнитной ленты. При поблочном чтении или в памяти (где прыжок на любое смещение практически ничего не стоит) никакого принципиального преимущества, кроме морального удовлетворения, он не дает :)
@barkalov Ну, по сути вопроса мне, например, просто не до конца понятен физический смысл требуемого ограничения... Если указанная сила F - развиваемая двигателем тяга, а "ограничение" подразумевает, что эта тяга просто не должна превысить некоторый заданный предел, то рассуждения кажутся мне справедливыми, ибо мощность двигателя (в терминах ньютоновской механики) есть способность двигателя развить определенную тягу (момент силы). Для грубой модели такой подход сойдет.
Более реалистичной была бы модель, учитывающая 1. инерционность двигателя (грубо - если пилот скачкообразно переведет РУД на взлетный режим, изменение F займет некоторое время) и нелинейность зависимости производимой тяги от, скажем, количества сжигаемого топлива (или чего-то другого, выступающего в модели в качестве управляющей величины).
Вспомните "автомобильные" графики зависимости развиваемого крутящего момента от оборотов двигателя внутреннего сгорания. (Не считая себя великим физиком, рискну тем не менее предположить, что аналогичное явление должно наблюдаться для реактивного двигателя на сжимаемом рабочем теле).
Я бы, для начала, задался вопросом, а на кой там вообще сдался Докер? Т.е. помимо того, что это модно и круто - в чем конкретно его предполагаемая роль в данной системе?
@demon123 Что делать? Ну, можно и дальше продолжать тыкаться вслепую... но проще и быстрее - разобраться, что есть что, в этой "волшебной" команде:
-classpath - после этого должен следовать полный путь к (одному или нескольким) jar-файлу, который должен быть доступен во время компиляции (т.е. файлов, содержащих все классы, использованные в исходнике в import). В данном случае это servlet-api.jar. (Если влепить туда пробелов и пр. ерунды, компайлер будет ругаться, т.к. не узнает в этом пути к файлу! Если файл недоступен или не содержит все нужные классы, компайлер тоже будет ругаться!)
Даллее: -d - после этого следует имя папки, куда будут складываться готовые .class -файлы (результаты компиляции).
Даллее: путь к файлу с исходником (тому, который должен компилироваться).
В зависимости от того, из какой папки вызывается компайлер, пути к файлам могут быть абсолютными или относительными (относительно папки).
Теперь, вооружившись этими секретными знаниями, потрудитесь скопировать вот это:
Гы... вот именно этим и прекрасна квантовая физика... в ней практически все как бы и да, и, как бы, одновременно нет - смотря с какой стороны посмотреть. Короче, Инь с Янем нервно курят в сторонке :)
@dimoncomeon Собственно, ограничение вытекает из сути SNMP и систем мониторинга, не предназначенных для "непрерывного" снятия данных. Вообще-то для отслеживания проблем в быстротекущих процессах существует механизм trap-ов. По идее, агент может собирать данные и анализировать их локально, и только в случае обнаружения проблемы (например, при выявлении тренда в среднеквадратичном отклонении) посылать соотв. trap. Если он будет их тупо слать каждую секунду (и если таких агентов будет много), это создаст нехилый спам в сети. С другой стороны, если система мониторинга будет слать get раз в секунду, это может задидосить сам девайс. Ну, и наконец, при большом количестве девайсов, которые нужно опрашивать, проблемы возникнут уже у планировщика запросов, не говоря о том, что такое количество данных еще нужно где-то хранить (например, в БД). Вот почему подавляющее большинство систем мониторинга и агентов заточены под потоки данных максимум раз в 30-60 с.
По сути вопроса, если речь про Андроид, то там все просто, как угол дома - там за это дело отвечает WifiManager, конкретнее см. константу EXTRA_NEW_RSSI. Т.к. для локализации нужен уровень сигнала нескольких AP, нужно периодически выполнять скан и собирать RSSI всех видимых (известных) AP. Хотя, в принципе, можно подойти к вопросу и с обратной стороны - брать RSSI на стороне AP (как конкретно - зависит от ОС AP). Теоретическая разр. способность RSSI в dBm - 1 байт, а какая будет битность реально, сильно зависит от конкретного железа и драйвера. По опыту: среднестатистические производители относятся к этому делу без фанатизма, ибо для отображения нескольких "столбиков" (хороший-плохой "прием") особая точность не требуется. Этот момент, кстати - один из безчисленных подводных камушков, о которые спотыкаются, как только от академической статейки нужно перейти к конкретной реализации :)
Далее по теме... не стоит безоговорочно доверять эпитетам типа "дешевые технологии". Дело в том, что авторы обзоров берут их, как и цифры типа 1-2 метра, из рекламных проспектов производителей, которые, в свою очередь, выводят их из теоретических формул. А на практике все выглядит несколько печальнее. Если из списка в статье выделить только WiFi-технологии, то победитель, бесспорно, Ekahau, с их заявленными "1м", "90% в радиусе 2м" и "низкой стоимостью". Я имел непосредственное удовольствие использовать эту приблуду (наряду с другими прочими из списка) в конкретных проектах и знаю истинную цену таким заявлениям.
На практике хорошо, если positioning engine может в 90% случаев определить положение с точностью "до комнаты", а в оставшихся 10% - "до этажа". Стоимость 1 транспондера у них 95-190€ плюс грубо столько же за лицензию на трекинг 1 транспондера. И это - без учета стоимости AP (которых нужно много и которые должны быть размещены на местности определенным образом), зарядных станций, ИК-маячков, интеграции и эксплуатации этого чуда... которая, кстати, работает ровно до того момента, как где-нибудь поднимут дополнительные AP, передвинут мебель или станут чаще/реже закрывать массивные двери или опускать жалюзи. Тогда нужно заново калибровать модель. По поводу "высокой надежности" могу только добавить, что когда в сети начинают пропадать UDP пакеты (а такое случается в реальных сетях даже при штатной нагрузке), система косячит так, что мама не горюй. Вот такая вот "точная, дешевая и надежная" технология :)
@yetiman Мне кажется, мы говорим о несколько разных вещах. Проблема автора вопроса в том, что ему мужно конкретно подключить девайс к системе мониторинга по SMTP (вероятно, чтоб отследить проблемы с WiFi). Вы же, видимо, хотите получать RSSI для локализации девайса в помещении. Если я прав, то нужно отметить две вещи.
Первая: само по себе получение данных на Андроиде (как и на любой другой ОС) - задача тривиальная. Инфу выдает драйвер через стандартное API.
Второе соображение печальнее и заключается в том, что тема локализации в помещении через WiFi RSSI - баян. На этом поприще перепробовали все мыслимое и немыслимое - от банальной трилатерации и поиска патернов в heatmaps, и до скрещивания RSSI с интеграцией данных от гироскопа, вспомогательных IR/US/RFID маячков и распознавания образов в сигнале с камеры (ключевое слово sensorfusion). Этим активно занимались не только авторы статьи, но еще пару сотен исследовательских и коммерческих проектов разной степени серьезности, и все уперлись в то, что через WiFi получить практически пригодные результаты с приемлемыми затратами нереально. Это связано со спецификой распространения сигнала на этих частотах. (Уже на 433 МГц получаются на порядки более стабильные результаты, причем, на порядки проще и дешевле.)
Tему прожевали и выплюнули уже лет пять как. Сейчас она интересна разве что для каких-нибудь лабораторных работ для студентов или занимательных рассуждений о еще одной попытке скрестить фильтр Калмана с триангуляцией на основе какой-нибудь заковыристой модели распространения радиоволн... короче: практическая польза стремится к нулю.
Проблема, похоже, не решится до тех пор, пока кто-нибудь не напишет нормальный конфигурируемый агент под Андроид :( По поводу 30с - это вообще проблема системы мониторинга. Я сам собирался написать такую штуку, но потом, по разным причинам, решил проблему иначе - прямым сбором данных на девайсе. Так что, видимо, либо ждать появления добровольцев, либо самому закатать рукава... и - вперед в светлое будущее :)
SET @prev=-1;
SET @rank=1;
SELECT @rank:=@rank+if(@prev > points,1,0) AS rank, user, @prev:=points
FROM users
ORDER BY points DESC;
Я специально не привожу это в качестве ответа, т.к. это - отвратительный костыль.
А ВОТ - статейка на эту тему. Там это преподностися, как великая мудрость... и оно, действительно, поучительно - разобраться с этим один раз... но только для того, чтоб НИКОГДА так не делать :)
@zelenin Не лишним, а делать там, где такие вещи нужно делать :) На чистом SQL эта задача в принципе не решаема. Ее можно бы было "решить", полагаясь на некоторые особенности реализации переменных в MySQL, но это а. не переносится, б. не сопровождается и в. может вдруг перестать работать.
@DmitriyEntelis@partyboy Обратите также внимание на то, что если, как в примере, обе записи с points=13 действительно должны получить одинаковое место (в примере 3), то это будет несколько сложнее и больше похоже на довольно таки грязненький хак без гарантии работоспособности в будущих версиях :) Тогда это было бы однозначно правильнее делать на стороне php.
@Petroveg Ну, это - да, безусловно. Вот были бы они программистами, у большинства были бы общеизвестные прозвища. Но на это надеяться не приходится. Как и на телефоны - Вы абсолютно правы!
Однако, оказалось, что отчества достаточно :) (Интересно было бы посчитать вероятность появления в одной фирме тёзок-однофамильцев с совпадающими первыми буквами отчества.)
Так вот как просто, оказывается! Изменить 150 адресов и переделать визитки - не проблема?.. ОК. На всякий случай: не забудьте при переходе прописать алиасы для "старых" адресов, иначе все, у кого они сохранены в адресных книгах, могут неприятно удивиться.
@iiil Хм... Но один из них все равно же будет чувствовать себя дискрименированным - не по цифровому, так по буквенному признаку :) @Petroveg У меня тоже возникала аналогичная идея, только не с погонялами, а с внутренними номерами телефонов. У них наверняка же есть внутренние телефоны, которые им так или иначе запоминать. Но потом подумал, что и то и другое - disclosure, и может быть не одобрено безопасностью :)
Если я правильно понял из комментов, там на самом деле все намного серьезнее - там не только отчества совпадают, но еще и одинаковые должности в одном отделе. Ну, ладно, адреса... как они их сами-то различать станут - вот что любопытно!
@Natann Не сочтите за занудство, но можно пруф этого утверждения в студию?
RFC 5322, например, на эту тему отмалчивается, просто считая локальную часть специфической для домена. RFC 5321 что-то там гундит насчет кейс сенситив, но на это, вроде как, дружно забили.
Ход мысли был таков, что используя точку и указанную структуру, мы просто неявно следуем правилам URI (и, кстати, если добавить слева схему "mailto:", то таки и получаем валидный URI). Если Ваше утверждение верно, в этой логике должна быть какая-но ошибка. Какая же? Вы можете сослаться на какие-то RFC или аналогичные нормативы, регламентирующее это самое сочинение имен ящиков?
По общей идее URI, домены перечисляются справа налево от генерализации к специализации. 2 - более специальный атрибут, чем имя-фамилия, так что, если по правилам, то нужно бы было 2.ivan.ivanov. Но такое, конечно, никто не запомнит, да и имя, начинающееся с цифры, будет проблематично для многих регулярных выражений. Tак что 2 нужно лепить где-то слева, и остается - только после имени :)
Мне кажется, что в примере для иллюстрации сути parent_id уже излишне, т.к. полиморфизм сущности/связи собственно выражен полем morph. (Kонкретную связь, в принципе, можно было бы даже вынести в отдельную связующую таблицу... или n таблиц. Хотя, это, конечно, сделало бы пример сложнее...)
