К пешеходам приравниваются лица, передвигающиеся в инвалидных колясках без двигателя, ведущие велосипед, мопед, мотоцикл, везущие санки, тележку, детскую или инвалидную коляску, а также использующие для передвижения роликовые коньки, самокаты и иные аналогичные средства.
Для велосипедиста, таки, как раз надо спешиваться, т.к. вести велосипед не равно ехать не велосипеде. К тому же в там перечислены «велосипед, мопед, мотоцикл». Не думаете же вы, что мотоциклист тоже может ехать по пешеходному переходу не спешиваясь?
Для самоката да, спешиваться не обязательно, но здравый смысл подсказывает, что в ПДД подразумевается обычный самокат, средняя скорость которого 8-12 км/ч, + пешеход должен удостоверится, что его видят и пропускают, а для этого перед переходом нужно, как минимум сбавить скорость. Вылет же на переход на электросамокате на скорости 25-30 км/ч — это ИМХО злоупотребление надоработками ПДД, которое может привести к печальным последствиям.
Лично, я в соответствии с ПДД на пешеходных переходах спешиваюсь, благо на самокате это сделать гораздо проще, чем на велосипеде. На большинстве переходах (в Питере), как правило, бордюр опущен для заезда инвалидных колясок. Но даже если и нет, ничего страшного в том, чтобы поднять на секунду 12 килограммовый самокат, нет. Вот подземный переход без рельс для колясок напрягает уже сильнее, особенно когда надо вверх :) Но таких очень мало.
Иногда комментирую старый код, который потом долго живет в проекте. Причина такая: Иногда сваливается баг и данные на которых его можно воспроизвести, под отладкой я смотрю входные данные в функции, исправляю чтобы все работало и благополучно об этом забываю. Через полгода или позже приходит новый баг с другими данными для воспроизведения, я снова под отладкой смотрю в чем проблема в той же функции и снова исправляю… на первый вариант, написав его один в один, как он был изначально. Поэтому иногда оставляю комментарии:
Среднестатистического пользователя вообще не волнует будет ли закрыт процесс или нет, он даже может не знать, что это такое. Ему важно, чтобы файлы с которыми он работал были сохранены и корректно закрыты. Если процесс повисит в памяти ещё какое-то время (особенно если памяти много) — ничего страшного не будет, даже наоборот, время запуска документов ассоциированное с этим приложением уменьшится и пользователь от этого только выиграет. При этом когда памяти останется мало, приложение может выгрузиться окончательно. Такое умное поведение программы у пользователя вызовет лишь положительные эмоции.
Давайте разделим приложения на два типа:
1) Приложение которые запускаются пользователем вручную, у которых есть главное окно в котором и работает пользователь, при закрытии которого приложение обычно завершает свою работу.
2) Приложения, которые, как правило, стартуют самостоятельно, показывая лишь иконку в трее. При двойном щелчке по иконке в трее или при щелчке по одному из пунктов трей-меню приложения, оно может показывать какие-то окна. Но при их закрытии приложение не должно никуда деваться из трея.
Т.е. грубо говоря, если при запуске приложения было показано окно, то при его закрытии, приложение в 99% завершает свою работу. Если же при запуске, никаких окон показано не было, и окна появлялись уже после взаймодействия с трей-значком, то при их закрытии приложение завершать свою работу не должно.
Но бывают и исключения, например, когда пользователю не нужно приложение в автозагрузке, и при запуске оно показывает главное окно, но при его закрытии уходит в трей, т.к. является ещё и фоновым сервисом.
Во всех случаях при нажатии кнопки закрыть окно — оно закрыватся. Было ли при этом завершено приложение? А должно ли пользователя это вообще волновать? И что значит приложение было завершено? Завершен ли процесс? А что если трей-иконка и окна открытые, при нажатии на нее это разные процессы? Можно ли считать приложение завершенным, если закрывая окно, процесс их породивший завршится, при этом другой процесс того же программного продута останется висеть с иконкой в трее? А если при закрытии главного окна приложения, оно не завершается еще какое-то время, чтобы при последующем запуске не тратить время на загрузку ресурсов? Возвращаемся к изначальному вопросу: должно ли пользователя это волновать, и если у него нет проблем с производительностью ОС? ИМХО — нет.
Но это же все равно не решает проблемы разного поведения кнопки закрыть. Например для дополнительных окон, кнопка закрыть будет закрывать только окна, для основного окна кнопка закрыть будет завершать приложение. Причем зачастую при закрытии главного окна работа приложения завершается, несмотря на то, что у приложения были открыты и другие окна. Мне кажется так, как сейчас уже сделано оптимально. Нужно понимать что окно — это не приложение, а всего лишь его часть, не всегда обязательная, т.к. не любое приложение обязано иметь пользовательский интерфейс. Кнопка закрытия всегда закрывает окно и если после этого приложению больше нечего делать — оно закрывается. А если у него осталась другая функциональность — оно продолжит работу. Такое понятие, как «свернуть в трей», придумали зря. Чаще всего, у приложения всегда висит иконка в трее, независимо от открытых окон. Такое приложение есть ничто иное как сервис, который позволяет показать некоторые окна с информацией и после их закрытия также продолжит работу. Почему это должно быть не так? И тогда сразу следующий вопрос: а если приложения из трея, по клику или из меню запустит другой процесс в котором будут окна, должно ли оно будет завершиться когда эти окна будут закрыты? :)
Тогда надо делать две кнопки «закрыть окно» и «закрыть приложение», но что делать если было закрыто последнее окно приложения и у него нет иконок в трее? Все равно ведь придется закрывать приложение :) Если только у последнего окна приложения, которое завершится после его закрытия, оставлять только кнопку «закрыть приложение» и не делать кнопку «закрыть окно».
Если окон несколько, никто ведь не ждет, что закрывая одно из окон, закроется вообще все приложение. Закрывается конкретно то окно, у которого была нажата кнопка. Вопрос возникает, когда «главное» окно было закрыто. Но во первых, не все приложения имеют «главные» окна, во вторых, если основная задача приложения работать в фоне, то закрытие главного окна не должно быть причиной для прекращения работы всего приложения. Если я закрыл окно торрента, это не значит, что не хочу чтобы они качались. Это значит, что я не хочу больше видеть его окно и я нажимаю его закрыть. Именно закрыть, не свернуть потому, что при сворачивании я ожидаю, что оно должно остаться на панели задач вместе с другими свернутыми окнами, а оно мне там не нужно. Я хочу его закрыть, полностью. Но чтобы торренты при этом продолжали качаться.
Иногда бывает ситуация, когда окно это не вся программа, а только вспомогательная её часть. Например вся программа сидит в трее, и что-то там делает (например, ожидает хоткеев для каких-то действий). Дваждый щелкнув по иконке в трее, я открываю окно настроек. Это единственное окно этой программы. Выставив настройки как мне надо, я нажимаю «применить», а затем закрываю окно настроек. И вот меньше всего я ожидаю, что при этом вся программа прекратит свою работу :) Да и вообще, крестик значит — закрыть окно. Вы его нажимаете, окно закрывается? Закрывается! Какое отношение закрытие окна имеет к прекращению работы программы? Тогда уже надо делать не кнопку «свернуть в трей», а кнопку «завершить программу»
У меня, в свое время, тоже была мысль сделать блокировщик, позволяющий делать SingleWrite и MultipleRead, и насколько я был рад тому что это уже сделано, настолько и разочарован, что увы, только в Висте. Подобную реализацию под XP видел, но мне в ней не понравилась одна вещь: если в потоке блокировщик уже открыт на чтение, то при открытии в нем же на запись будет дедлок. Вечное ожидание того, что количества ридеров будет равно нулю, т.к. один из ридеров и есть этот самый поток. Отчасти соглашусь, что при открытом на чтение объекте, открывать его на запись в том же потоке архитектурно неверно. Но тем не менее не хотелось бы попадать в дедлок в этой ситуации и я сделал похожую реализацию с использованием TlsSetValue и TlsGetValue чтобы записать в поток кол-ко его собственных ридеров для блокировщика и если оставшееся число открытых ридеров ему равно — то можно открывать на запись или выпадать в ассерт (мол, ты что творишь, ирод!)
С вашим примером я полностью согласен, но есть одно но: у вас идет речь об обслуживании людей, а в этом случае, действительно, недопустимо планировать свое время способом отличиным от жесткого графика работы. Кассир на кассе также не может скопить большую очередь, а потом быстро-быстро обслужить всех, или сотрудник поддержки, отвечающий на звонки, не может покинуть свое рабочее место без веской причины, т.к. не может знать, в какой момент времени могут понадобится его услуги. Но в случае же, когда человеку ставится задача, которая должна быть сделана к определенному сроку и её выполнение не завязано на других людей, то что плохого, в том, что он сам решает, в каком темпе и с какими интервалами ему работать? Чем неторопливая работа, равномерно распределяющаяся на весь период выделенного времени, лучше нескольких промежутков времени максимально сосредоточенной и эффективной работы (при условии, что качество выполненной работы в обоих случаях одинаково)?
Как по мне, так оценивать работу человека можно только по её результатам, а не по процессу. Какое работодателю дело до того, как сотрудник управляет своим временем? Кто-то работает не торопясь, примерно с одинаковой скоростью, а кто-то предпочитает взрываться на короткое время и работать по максимуму, но потом ему требуется большее время на восстановление в которое он делает то, что ему хочется. Возьмем простой пример:
У вас есть склад и есть мешки не далеко от склада (например с картошкой, по 10кг в каждом), и мешков этих очень много и все их надо перетащить на склад. Для решения этой задачи вы нанимаете трех грузчиков.
— Двое из них берут по одному мешку, и не торопясь, экономя силы (оценив объем работы), носят на склад. В результате чтобы отнести мешок на склад и вернуться за следующим, уходит 3 минуты.
— Третий же, наоборот, хватает сразу по два мешка на плечи, старается быстрее отнести их на склад, и успевает сделать это за 2 минуты.
Первые два работает по принципу: 30 минут носят мешки и потом 5 минут курят/отдыхают. Третий же, из за большой нагрузки, работает 20 минут, а потом отдыхает 40 минут.
Если вы, как наниматель, будете периодически выглядывать в окно проверяя работу нанятых грузчиков, то перед вашим взором сложиться простая картина: двое работают, третий постоянно ничего не делает, курит, ковыряется в телефоне, просто сидит/лежит/отдыхает или вообще куда-то ушел.
А теперь давайте посчитаем производительность труда:
— Рабочий из первой группы за полчаса относит 10 мешков, 5 минут курит, относит ещё 10 мешков ещё за полчаса и снова 5 минут курит. Получается, что за 21й мешок он возьмется только спустя 70 минут с начала работы.
— Третий же сразу относит 20 мешков, за 20 минут, отдыхает 40 минут и 21й мешок он берет уже спустя 60 минут с начала работы. И на деле оказывается, что его производительность выше, чем производительность его коллег, не смотря на то, что большую часть времени он ничего не делает.
Так что, ИМХО, слежение нужно устраивать только за теми сотрудниками, которые не справляются с поставленными задачами вовремя.
Я думаю, что мы сойдемся на том, что у каждого этот момент индивидуален. Кому-то нравится когда свет включен везде. Кому-то нет. В большинстве случаев всеми движет желание сэкономить и привычка уходя откда-то гасить свет. Я на практике убедился, что отучить женщину постоянно выключать везде свет — трудно, но можно :) Естественно не надо доводить все это до абсурда, и систему надо настраивать так, чтобы удобно было всем. Если человек спит, то в спальне, которая легко исключается из общего выключателя, как и детская комната, при наличии детей. Лично я переживу, если те люди, которые спят у меня в туалете, в ванной, в коридоре и на кухне останутся недовольны. Ввиду малого их количества. Ноль человек.
Для таких случаев как раз и сделаны отдельные выключатели. И если человек приходит домой поздно, и зная, что все уже спят, включает свет во всем доме — это уже вопрос скорей не технический, а клинический.
Так я и говорю, с кнопками — проблема остается, худо-бедно гарантия появляется только при автоматизации или управления со смартфона (и да возможны задержки).
А вообще, после того, как я заменил лампочки на диодные, я посчитал потребление всей квартиры при свете включенном везде и вышло меньше 100 ватт. Раньше столько потребляла одна лампочка — теперь все. Поэтому я больше не замораиваюсь с выключением света. Нет, выключатели я все равно сделал, но ещё есть один общий — при входе в квартиру — включить/выключить свет везде. Именно им я и пользуюсь. ради 100-150 рублей в месяц нет смысла от всей этой экономии, зато как приятно идти по квартире, где всегда светло. Автоматика только помогает просыпаться с утра плавно включая свет, задоно вырубает свет на кухне после десяти вечера, а то занавески зеленые и свет начинает очень привлекать тлю. Ну и прочие мелочи, которые легко автоматизировать.
Ну это уже будет совсем другая система, которая будет стоить совсем других денег.
Впринципе и сейчас уже можно обойтись без обратной связи, используя сервер с приемником и передатчиком. У сервера будет философия простая — ему не надо знать текущее состояние каждого блока, ему достаточно знать в каком состояни должен быть каждый блок. И он постоянно (с какой-то периодичностью) будет посылыть всем блокам их состояния — рано или поздно каждый блок его примет, даже если будут осечки. Соответственно все выключатели будут завязаны на приемник этого же сервера, который получив сигнал от выключателя — поменяет у себя в хранилище состояние соответствующего блока на нужное и продолжит рассылать команды. Тогда останется вариант, что не всегда может доходить сигнал от выключателя до сервера, но зато вся автоматизация и управление со смартфона будет работать как часы.
Да, обратная связь бы nooLite не помешала, но я пока слабо представляю, как она может выглядеть без серьезных переделок. Я вижу 2 варианта:
1) Обратная связь позволяет запросить у устройства его текущее состояние и получить ответ. Выключателям это не особо нужно, достаточно сделать новый USB свисток, умеющий сразу и отправлять и получать + доработать силовые блоки + доработать их роутер. Но т.к. таким функционалом люди пользуются мало — не думаю, что они будут это делать.
2) Команды будут отправляться до тех пор, пока не будет получено подтверждение, что гарантирует доставку. На мой взгляд это самый нужный функционал. Но, во первых, придется оборудовать выключатели «хвостами» приемниками, которые испортят их внешний вид. Во вторых непонятно как будет работать подтверждение, когда один выключатель привязан к нескольким силовым блокам, и понятия об этом не имеет, ведь привязка храниться только на блоке. Придется ещё и переделывать механизм привязки.
Для велосипедиста, таки, как раз надо спешиваться, т.к. вести велосипед не равно ехать не велосипеде. К тому же в там перечислены «велосипед, мопед, мотоцикл». Не думаете же вы, что мотоциклист тоже может ехать по пешеходному переходу не спешиваясь?
Для самоката да, спешиваться не обязательно, но здравый смысл подсказывает, что в ПДД подразумевается обычный самокат, средняя скорость которого 8-12 км/ч, + пешеход должен удостоверится, что его видят и пропускают, а для этого перед переходом нужно, как минимум сбавить скорость. Вылет же на переход на электросамокате на скорости 25-30 км/ч — это ИМХО злоупотребление надоработками ПДД, которое может привести к печальным последствиям.
1) Приложение которые запускаются пользователем вручную, у которых есть главное окно в котором и работает пользователь, при закрытии которого приложение обычно завершает свою работу.
2) Приложения, которые, как правило, стартуют самостоятельно, показывая лишь иконку в трее. При двойном щелчке по иконке в трее или при щелчке по одному из пунктов трей-меню приложения, оно может показывать какие-то окна. Но при их закрытии приложение не должно никуда деваться из трея.
Т.е. грубо говоря, если при запуске приложения было показано окно, то при его закрытии, приложение в 99% завершает свою работу. Если же при запуске, никаких окон показано не было, и окна появлялись уже после взаймодействия с трей-значком, то при их закрытии приложение завершать свою работу не должно.
Но бывают и исключения, например, когда пользователю не нужно приложение в автозагрузке, и при запуске оно показывает главное окно, но при его закрытии уходит в трей, т.к. является ещё и фоновым сервисом.
Во всех случаях при нажатии кнопки закрыть окно — оно закрыватся. Было ли при этом завершено приложение? А должно ли пользователя это вообще волновать? И что значит приложение было завершено? Завершен ли процесс? А что если трей-иконка и окна открытые, при нажатии на нее это разные процессы? Можно ли считать приложение завершенным, если закрывая окно, процесс их породивший завршится, при этом другой процесс того же программного продута останется висеть с иконкой в трее? А если при закрытии главного окна приложения, оно не завершается еще какое-то время, чтобы при последующем запуске не тратить время на загрузку ресурсов? Возвращаемся к изначальному вопросу: должно ли пользователя это волновать, и если у него нет проблем с производительностью ОС? ИМХО — нет.
У вас есть склад и есть мешки не далеко от склада (например с картошкой, по 10кг в каждом), и мешков этих очень много и все их надо перетащить на склад. Для решения этой задачи вы нанимаете трех грузчиков.
— Двое из них берут по одному мешку, и не торопясь, экономя силы (оценив объем работы), носят на склад. В результате чтобы отнести мешок на склад и вернуться за следующим, уходит 3 минуты.
— Третий же, наоборот, хватает сразу по два мешка на плечи, старается быстрее отнести их на склад, и успевает сделать это за 2 минуты.
Первые два работает по принципу: 30 минут носят мешки и потом 5 минут курят/отдыхают. Третий же, из за большой нагрузки, работает 20 минут, а потом отдыхает 40 минут.
Если вы, как наниматель, будете периодически выглядывать в окно проверяя работу нанятых грузчиков, то перед вашим взором сложиться простая картина: двое работают, третий постоянно ничего не делает, курит, ковыряется в телефоне, просто сидит/лежит/отдыхает или вообще куда-то ушел.
А теперь давайте посчитаем производительность труда:
— Рабочий из первой группы за полчаса относит 10 мешков, 5 минут курит, относит ещё 10 мешков ещё за полчаса и снова 5 минут курит. Получается, что за 21й мешок он возьмется только спустя 70 минут с начала работы.
— Третий же сразу относит 20 мешков, за 20 минут, отдыхает 40 минут и 21й мешок он берет уже спустя 60 минут с начала работы. И на деле оказывается, что его производительность выше, чем производительность его коллег, не смотря на то, что большую часть времени он ничего не делает.
Так что, ИМХО, слежение нужно устраивать только за теми сотрудниками, которые не справляются с поставленными задачами вовремя.
Количество проживающих тут роли не играет. Светло будет всем одинаково. Играет роль количество прописанных :)
Хотя, нет, это только для средней нормы. По счеткику это тоже не важно.
А вообще, после того, как я заменил лампочки на диодные, я посчитал потребление всей квартиры при свете включенном везде и вышло меньше 100 ватт. Раньше столько потребляла одна лампочка — теперь все. Поэтому я больше не замораиваюсь с выключением света. Нет, выключатели я все равно сделал, но ещё есть один общий — при входе в квартиру — включить/выключить свет везде. Именно им я и пользуюсь. ради 100-150 рублей в месяц нет смысла от всей этой экономии, зато как приятно идти по квартире, где всегда светло. Автоматика только помогает просыпаться с утра плавно включая свет, задоно вырубает свет на кухне после десяти вечера, а то занавески зеленые и свет начинает очень привлекать тлю. Ну и прочие мелочи, которые легко автоматизировать.
Впринципе и сейчас уже можно обойтись без обратной связи, используя сервер с приемником и передатчиком. У сервера будет философия простая — ему не надо знать текущее состояние каждого блока, ему достаточно знать в каком состояни должен быть каждый блок. И он постоянно (с какой-то периодичностью) будет посылыть всем блокам их состояния — рано или поздно каждый блок его примет, даже если будут осечки. Соответственно все выключатели будут завязаны на приемник этого же сервера, который получив сигнал от выключателя — поменяет у себя в хранилище состояние соответствующего блока на нужное и продолжит рассылать команды. Тогда останется вариант, что не всегда может доходить сигнал от выключателя до сервера, но зато вся автоматизация и управление со смартфона будет работать как часы.
1) Обратная связь позволяет запросить у устройства его текущее состояние и получить ответ. Выключателям это не особо нужно, достаточно сделать новый USB свисток, умеющий сразу и отправлять и получать + доработать силовые блоки + доработать их роутер. Но т.к. таким функционалом люди пользуются мало — не думаю, что они будут это делать.
2) Команды будут отправляться до тех пор, пока не будет получено подтверждение, что гарантирует доставку. На мой взгляд это самый нужный функционал. Но, во первых, придется оборудовать выключатели «хвостами» приемниками, которые испортят их внешний вид. Во вторых непонятно как будет работать подтверждение, когда один выключатель привязан к нескольким силовым блокам, и понятия об этом не имеет, ведь привязка храниться только на блоке. Придется ещё и переделывать механизм привязки.