Диапазон цен довольно большой. Начинаются цены от 1$ за штуку (без батарейки). И потолок цены — около 80$, но это уже не маячок, а гораздо более продвинутая штуковина, там бывают всякие дополнительные датчики (например, освещенности и температуры) и др. В нашем случае все эти излишества были не нужны, поэтому обошлись одним из самых доступных вариантов.
С батарейкой тоже по-разному. Большинство производителей утверждают, что маячок работает от одной батарейки до двух лет. Но, во-первых, это зависит от батарейки, а во вторых, от настроек мощности маячка. У нас пока не было возможности подождать два года, но месяца два уже маячки работают на одной батарейке и на максимальной мощности. Будем следить за развитием событий)
Наши маячки никогда не спят, поэтому необходимости будить их не было. По поводу других моделей сказать не могу. В принципе, возможно с мобильного приложения убрать мощность на минимум или выставить на максимум. Можно там же поменять кое-какие другие настройки. Ну и в остальном они не очень умные.
Если мы не получаем новости от маячка больше N дней, это повод задуматься: он или установлен в каком-то очень неудачном месте, или его там больше нет. В любом случае, нужно идти и проверять, что там.
Наверное, можно было бы немного проапгрейдить маячки, чтобы они сами нам что-то отправляли, но это было бы существенно дороже.
Мониторить — в каком именно смысле? По большому счету, мы их уже мониторим:
— получаем от пользователей информацию о видимых им маячках (можем заметить, если какой-то из маячков появился в странном месте или наоборот, пропал)
— время от времени API запрашивает у приложения информацию об уровне заряда батареи маячков
Это покрывает практически все потребности в отслеживании маячков. По крайней мере, пока.
Вам удалось с помощью этих примеров разубедить людей, действительно уверовавших в теории заговоров?)
Как правило, если человек уже зацепился за какую-нибудь бредовую идею (хоть нибиру, хоть жидомасоны и пр.), так просто он с этой темы не свернет.
Кажется, наиболее целесообразно делать не ночные смены, а плавающее время начала дневной смены. Т.е. давать возможность прийти в любое время с 9 до 12, например. Это оставляет возможность выспаться тем, кто поздно лег, позволяя при этом проводить совместные совещания. Полное разделение дневной и ночной смены может убить коммуникации в команде. Кроме того, введение ночных смен с фиксированным временем начала решит только проблемы совсем уж классических сов. Мне кажется, очень много людей, у которых в сутках просто чуть больше часов. И им нужно не поменять день на ночь, а обеспечить чуть больше свободы в выборе времени начала дня.
Цензура сама по себе — лучшая пропаганда терроризма. Так что лучше без нее.
Нецензурируемый интернет без пропаганды терроризма и прочего появится только тогда, когда сами негативные явления себя изживут. Так что мне кажется, возможные решения тут лежат вообще вне плокости IT.
В случае если водитель ведет себя невнимательно на дороге или начинает засыпать, она (система), снимая данные с положения и движения глаз водителя, будет принимать меры, а именно: не находится ли машина впереди слишком близко, либо не отклоняется ли автомобиль с дороги.
Это все очень круто, но не удалось понять по тексту, что именно система будет делать, если водитель все-таки заснет? Бить его по щекам?
Спасибо за любопытную статью!
Согласна практически со всем, но хотелось бы дополнить про роль use cases в ЧТЗ. Все-таки, один use case может включать в себя несколько единиц функциональности (features), и хорошо бы их отдельно описывать. Кроме того, кейсы могут ветвиться (либо, если структура нашего документа не допускает ветвления, они могут частично дублировать друг друга). Получается исчерпывающее описание, но зачастую сложное для обобщенного восприятия разработчиками.
Я предпочитаю делать список вариантов использования перед формированием ТЗ (естественно, после интервьюирования представителей заказчика), потом делать сам документ с описанием отдельных функций, а там уже, при необходимости, можно ссылаться на документ с вариантами использования. Ну и, как Вы правильно отметили, нет ничего лучше использования user cases для тестирования :)
Я оптимист, наверное. И мне каждый раз кажется, что опуститься в пучину идиотизма еще глубже просто не получится.
Хотя разумнее, наверное, перестать надеяться, что кто-то поумнеет, а вместо этого начать прием ставок на то, каким будет их следующий шаг. Кстати, веселенький может выйти тотализатор.
Да. И при личном присутствии самого кота Василия.
На самом деле, надеюсь, депутатам кто-нибудь расскажет про подтверждение персональных данных при регистрации доменов.
Начинание очень хорошее, такие материалы нужны, но здесь пока неоправданно сложное изложение для восьмилеток. В таком возрасте должно быть просто, весело и увлекательно.
Во-первых, стиль:
Однострочный комментарий представляет собой строку, начинающуюся...
Можно же написать «Однострочный комментарий — это строка, которая ....»
Во-вторых, содержание:
Комментарий это область кода, не интерпретируемая PHP. В комментарий можно заключить любую информацию, при этом она не помешает исполнению PHP скрипта.
Сначала нужно объяснить ребенку, что значит «интерпретируемая». Кроме того, фраза о том, что в комментарий можно заключить любую информацию, слишком абстрактна для детского восприятия. Нужно привести пример, зачем ему, ребенку-программисту, это понадобится.
Многострочный комментарий может быть вложен в однострочный, как и однострочный может быть вложен в многострочный.
Однострочный комментарий может быть вложен в однострочный.
Многострочный комментарий НЕ может быть вложен в многострочный.
Это важные вещи, но они не нужны на том этапе, когда ребенок делает первые шаги в программировании. Сейчас важно увлечь, показать, что программирование — это про изобретение замечательных штук, а не про запоминание кучи правил. Когда будет интересно — будет мотивация. Когда будет мотивация, ребенок сможет запомнить какие-то детали.
А как же старое доброе чтение по диагонали? Обычно сначала быстро просматриваю статью, чтобы понять, интересна ли она, а потом читаю подряд. Думаю, многие поступают примерно так же. С этой технологией такое исключено: или читай все, или не читай вообще. Ну и всегда бывает нужна возможность остановиться на каком-то абзаце, перечитать или вернуться выше по тексту. Пока непонятно, чем будут заменены эти привычные механизмы чтения и восприятия текстовой информации в целом.
Боюсь, если уже удалось отнять у человека пистолет и приставить к нему, то для преступника нет проблемы в том, чтобы этот пистолет оказался на достаточном расстоянии от руки владельца, чтобы можно было выстрелить.
Я не говорю, что можно дать гарантию всегда и на все. Да и веб-разработка не ограничивается использованием закрытых систем, в которых можно наткнуться на такой баг и утратить возможность влиять на ситуацию. Речь о том, что разработчик в состоянии очертить рамки, в которых он может гарантировать работоспособность кода, и в этих рамках можно что-то обещать. Да, тут будет много ограничений. Ну а куда деваться, эти риски есть и в других сферах, это не повод отказываться от гарантий вообще.
С батарейкой тоже по-разному. Большинство производителей утверждают, что маячок работает от одной батарейки до двух лет. Но, во-первых, это зависит от батарейки, а во вторых, от настроек мощности маячка. У нас пока не было возможности подождать два года, но месяца два уже маячки работают на одной батарейке и на максимальной мощности. Будем следить за развитием событий)
Наши маячки никогда не спят, поэтому необходимости будить их не было. По поводу других моделей сказать не могу. В принципе, возможно с мобильного приложения убрать мощность на минимум или выставить на максимум. Можно там же поменять кое-какие другие настройки. Ну и в остальном они не очень умные.
Наверное, можно было бы немного проапгрейдить маячки, чтобы они сами нам что-то отправляли, но это было бы существенно дороже.
— получаем от пользователей информацию о видимых им маячках (можем заметить, если какой-то из маячков появился в странном месте или наоборот, пропал)
— время от времени API запрашивает у приложения информацию об уровне заряда батареи маячков
Это покрывает практически все потребности в отслеживании маячков. По крайней мере, пока.
Как правило, если человек уже зацепился за какую-нибудь бредовую идею (хоть нибиру, хоть жидомасоны и пр.), так просто он с этой темы не свернет.
Нецензурируемый интернет без пропаганды терроризма и прочего появится только тогда, когда сами негативные явления себя изживут. Так что мне кажется, возможные решения тут лежат вообще вне плокости IT.
Это все очень круто, но не удалось понять по тексту, что именно система будет делать, если водитель все-таки заснет? Бить его по щекам?
Согласна практически со всем, но хотелось бы дополнить про роль use cases в ЧТЗ. Все-таки, один use case может включать в себя несколько единиц функциональности (features), и хорошо бы их отдельно описывать. Кроме того, кейсы могут ветвиться (либо, если структура нашего документа не допускает ветвления, они могут частично дублировать друг друга). Получается исчерпывающее описание, но зачастую сложное для обобщенного восприятия разработчиками.
Я предпочитаю делать список вариантов использования перед формированием ТЗ (естественно, после интервьюирования представителей заказчика), потом делать сам документ с описанием отдельных функций, а там уже, при необходимости, можно ссылаться на документ с вариантами использования. Ну и, как Вы правильно отметили, нет ничего лучше использования user cases для тестирования :)
Хотя разумнее, наверное, перестать надеяться, что кто-то поумнеет, а вместо этого начать прием ставок на то, каким будет их следующий шаг. Кстати, веселенький может выйти тотализатор.
На самом деле, надеюсь, депутатам кто-нибудь расскажет про подтверждение персональных данных при регистрации доменов.
Во-первых, стиль:
Можно же написать «Однострочный комментарий — это строка, которая ....»
Во-вторых, содержание:
Сначала нужно объяснить ребенку, что значит «интерпретируемая». Кроме того, фраза о том, что в комментарий можно заключить любую информацию, слишком абстрактна для детского восприятия. Нужно привести пример, зачем ему, ребенку-программисту, это понадобится.
Это важные вещи, но они не нужны на том этапе, когда ребенок делает первые шаги в программировании. Сейчас важно увлечь, показать, что программирование — это про изобретение замечательных штук, а не про запоминание кучи правил. Когда будет интересно — будет мотивация. Когда будет мотивация, ребенок сможет запомнить какие-то детали.