Самокат без электротяги на тротуаре/велодорожке — достаточно безопасная штука. Ну что такое скорость 15 км/ч? И падать с него невысоко. Да, можно колесом в невидимую яму залететь и навернуться через руль, но это большая редкость.
Из моноколесников большинство катается в шлеме и роллерной защите. Из электросамокатчиков — да, редко, если это не семьи с детьми. Но даже тут падение безопаснее, чем с велосипеда, потому что ноги свободны. А дальше каждый сам выбирает между удобством и риском. Наверное, не все правильно оценивают риск, возможно коллективный опыт еще не накопился (не говоря уже о личном).
Если горка крутая, но короткая, то можно обойтись обычным самокатом без электротяги. 5 км с обычными городскими препятствиями типа бордюров и подземных переходов — чуть больше 20 минут.
Если длинная горка, то катить вверх своими силами долго тяжеловато (точнее, жарковато). Выбор между электросамокатом и колесом — если вообще без общественного транспорта, то с самокатом проще (с ОТ колесо выигрывает по компактности). Самокат более устойчив, на нем можно спокойно преодолевать бордюры. На колесе предел — 2-4 см, дальше лично мне жалко колесо (правда вешу не так мало, 90 с рюкзаком).
Если будте брать самокат, обязательно прикиньте, будет ли он вас обливать грязью в мокрую погоду. Увы, это делают даже некоторые модели "топовых" Micro. Для покатушек это пофиг, а с работы дождь может застать врасплох.
Да и вообще водитель слева сидит в машине. Обочина справа, он за впереди идущим автомобилем не так много видит. Если велосипедист впереди с скоростью X, а автомобиль чуть позади со скоростью 3X, то вот вам и "встреча" непосредственно в момент маневра.
Это и про съезды всякие тоже, где появляется новая полоса и водитель перестраивается на нее.
Еще цена, простота ТО и помещаемость в прихожей. Но главное — да, с ним можно в метро войти спокойно (даже складывать часто не обязательно). Для Москвы актуально комбинировать личный и общественный транспорт, т.к. совсем без ОТ очень большие дистанции получаются, типа 40 км на работу в одну сторону.
По ответам сведущих складывается впечатление, что можно будет ездить круглый год, если маршрут будет оперативно чиститься от снега и грязи. Посмотрим.
Учтите, что только очисткой дело не обходится, и всегда есть песок или противогололедный реагент. Все это довольно оперативно может сожрать ваше средство транспорта.
А если нет ничего, то скользко. Хотя если у вас под маршрутом теплотрасса проходит, то ок;)
Отличные советы, подтверждаю как заядлый самокатчик и теперь моноколесник. Разве что про обочину — это очень зависит от маршрута: загруженность и ширина тротуара, качество обочины, интенсивность движения.
Еще 5 копеек насчет езды по тротуару:
а) Опасны пешеходы, идущие к том же направлении (к тебе спиной), они тебя не видят и могут внезапно остановиться, повернуть или strafe-нуться. Чтобы избежать фрага, объезжать их подальше или снижать скорость до пешеходной, оценивать возможные траектории (типа рядом магазин или развилка).
б) Пешеходы будут обходить те же люки и ямы на дороге, которые вы объезжаете.
в) К собаке может прилагаться поводок до хозяина, идущего по противоположной части тротуара. влететь в него даже на небольшой скорости — проблемы для всех троих. Вечером/ночью поводок фиг заметишь. Встречая собак, всегда предполагаю, что поводок есть, пока не убедишься в обратном.
г) Дети, дети, дети. Кроме непредсказуемости высокая цена ошибки (так что включаем сюда коляски). Но радость на детских лицах от вида проезжающего рядом моноколесника — бесценна;)
д) Если видно, что не получится безопасно объехать пешехода — "Позвольте, пожалуйста, проехать" (желательно не над ухом, а издалека!).
P.s. Небольшая байка. "Давным-давно, когда был еще неопытен", как-то ехал на велике небольшой отрезок пути по тротуару (по дороге там нельзя). Девушка стоит под крыльцом магазина, никого не трогает, и вдруг внезапно широко шагает на тротуар не глядя. Дисковый тормоз отлично сработал — мы с велом встали на дыбы в сантиметрах перед ней и я радостно воткнулся в тротуар в позе ныряющего с трамплина. Каска, перчатки, опыт айкидо — отделался всего лишь связками на кисти. Девушку, к счастью, только ветерком обдуло.
Так ведь и МНК, и байес вычисляют результат не точно. У МНК есть вполне просто вычисляемая статистическая погрешность — можно использовать стандартное отклонение. У байеса, наверное, тоже можно в каком-то виде погрешность определить. Кстати, интересно, в каком?
В целом спасибо большое за статьи, очень понятное введение для такой неинтуитивной темы!
У пользователя где? На телефоне, который он завтра потеряет, оставшись без своих треков?
Впрочем, если сервис использует геолокацию только для своей внутренней кухни (типа показать ближайшие банкоматы), то я с вами согласен.
Спасибо за хороший анализ.
Интересно, что у вас достаточно сильно развилась система постановки задач, при этом в ней до сих пор не появилась оценка трудоемкости задач на этапе планирования — у вас оценка ставится только при начале работы над задачей. А это ведь базовый прием — тот же planning poker в Scrum и т.п.
Уверен, что вы не могли его не попробовать на более раннем этапе. Более вероятно, что попробовали и, не получив ожидаемого результата, отказались. Если так, то можете поделиться опытом — какие были результаты, почему отказались?
Очень забавно эти французские словечки закрепились для аварийных радиопереговоров. Уже упомянутый Mayday, а также Pan-pan (от фр. «pahn» — поломка) для серьезных, но прямо не угрожающих жизни проблем и Sécurité для сообщениях об опасностях для навигации. Это для судов, но Pan-pan, судя по Википедии, в авиации тоже используется.
Особенно забавно звучит отмена (Mayday cancel) или передача по цепочке (Mayday relay), особенно если дальнейшее сообщение с конкретикой (координаты, что случилось, ...) передается на русском или другом «местном» языке — смесь французского, английского и нижегородского.
Некоторые едут на пляж отдыхать, а некоторые — в альплагерь. На Гиктаймсе "матрасный" отдых, а на Хабре суровые русские программисты отдыхают, читая про зубодробительные нововведения C++20. Что не уменьшает полезности этих постов и возможности прийти к ним с конкретным запросом через поиск.
1) Это не код, а блок-схема. Вероятно, она была нарисована, когда авторы совсем запутались в написанном коде;)
2) В этой блок-схеме есть два очевидно отдельных куска с разделением в "What's the user's channel notification pref for this device". При этом нижнюю часть скорее всего можно упростить, т.к. есть пересечение у channel и global notifications (например Mentions). Также если делать не единственные точки выхода (YES/NO), то из схемы пропадёт куча объединяющих стрелочек и она станет не такой страшной.
3) Главное, эта схема описывает реальную сложную бизнес-логику. Ее тоже не стоит переусложнять (пользователю будет непонятно), но это другой случай. Описывающий эту логику код поместится на 1-2 страницах, и с учетом хорошей документации в этом нет проблем. Но есть еще код, который вытаскивает из внутренних структур значения переменных, которые тут в if'е. Если он подмешан к коду бизнес-логики, то именно тогда и получается простыня, требующая рефакторинга.
Да. И что? Идеальных не бывает, у всех свои слабые стороны. Если бы это было критической проблемой для бизнеса, бизнес бы закрылся, а если он живет, значит директор берет чем-то другим (например адекватным планированием все остальное время и пониманием рынка).
Так директор в статье не от желания пропиариться или самоутвердиться так себя ведет. У человека факап, он расстроен и нервничает (больше всех руководителей, естественно, с нее же спрашивают). Ведет себя нелогично поэтому.
Ну так и мы себя тоже не всегда логично ведем, когда на эмоциях. Но это, по крайней мере по нашему мнению, не мешает нам в целом быть хорошими специалистами и полезными сотрудниками.
Области видимости — это не проблема, а благословение, позволяющее экономить сложность.
Если вы выносите в функцию вроде бы обособленный кусок кода, а он тащит с собой 5-10 параметров, значит что-то тут не так. Например, математические расчеты перемешаны с логгированием, получением/записью данных и пр. Другой случай — у вас есть блок данных, которые везде приходится таскать вместе (скажем, длина, ширина и кисть рабочей области рисования), тогда имеет смысл выделить класс-контекст.
Именно выделение функции позволяет такие проблемы обнаружить, и почти всегда после рефакторинга понимаешь, что новый код стал более понятным и чистым.
Еще лучше с длинными простынями. Часто при распутывании таких "нетривиальных" случаев оказывается, что покрыты не все результаты ветвления и в некоторых случаях получатся странные результаты либо явные расчетные или инфраструктурные (забыли считать/модифицировать общие данные) ошибки.
Самокат без электротяги на тротуаре/велодорожке — достаточно безопасная штука. Ну что такое скорость 15 км/ч? И падать с него невысоко. Да, можно колесом в невидимую яму залететь и навернуться через руль, но это большая редкость.
Из моноколесников большинство катается в шлеме и роллерной защите. Из электросамокатчиков — да, редко, если это не семьи с детьми. Но даже тут падение безопаснее, чем с велосипеда, потому что ноги свободны. А дальше каждый сам выбирает между удобством и риском. Наверное, не все правильно оценивают риск, возможно коллективный опыт еще не накопился (не говоря уже о личном).
Если горка крутая, но короткая, то можно обойтись обычным самокатом без электротяги. 5 км с обычными городскими препятствиями типа бордюров и подземных переходов — чуть больше 20 минут.
Если длинная горка, то катить вверх своими силами долго тяжеловато (точнее, жарковато). Выбор между электросамокатом и колесом — если вообще без общественного транспорта, то с самокатом проще (с ОТ колесо выигрывает по компактности). Самокат более устойчив, на нем можно спокойно преодолевать бордюры. На колесе предел — 2-4 см, дальше лично мне жалко колесо (правда вешу не так мало, 90 с рюкзаком).
Если будте брать самокат, обязательно прикиньте, будет ли он вас обливать грязью в мокрую погоду. Увы, это делают даже некоторые модели "топовых" Micro. Для покатушек это пофиг, а с работы дождь может застать врасплох.
Да и вообще водитель слева сидит в машине. Обочина справа, он за впереди идущим автомобилем не так много видит. Если велосипедист впереди с скоростью X, а автомобиль чуть позади со скоростью 3X, то вот вам и "встреча" непосредственно в момент маневра.
Это и про съезды всякие тоже, где появляется новая полоса и водитель перестраивается на нее.
Еще цена, простота ТО и помещаемость в прихожей. Но главное — да, с ним можно в метро войти спокойно (даже складывать часто не обязательно). Для Москвы актуально комбинировать личный и общественный транспорт, т.к. совсем без ОТ очень большие дистанции получаются, типа 40 км на работу в одну сторону.
Потоотделение очень индивидуально. Я потел при ходьбе всегда, даже в те годы, когда по 3 раза в неделю занимался спортом.
Учтите, что только очисткой дело не обходится, и всегда есть песок или противогололедный реагент. Все это довольно оперативно может сожрать ваше средство транспорта.
А если нет ничего, то скользко. Хотя если у вас под маршрутом теплотрасса проходит, то ок;)
Отличные советы, подтверждаю как заядлый самокатчик и теперь моноколесник. Разве что про обочину — это очень зависит от маршрута: загруженность и ширина тротуара, качество обочины, интенсивность движения.
Еще 5 копеек насчет езды по тротуару:
а) Опасны пешеходы, идущие к том же направлении (к тебе спиной), они тебя не видят и могут внезапно остановиться, повернуть или strafe-нуться. Чтобы избежать фрага, объезжать их подальше или снижать скорость до пешеходной, оценивать возможные траектории (типа рядом магазин или развилка).
б) Пешеходы будут обходить те же люки и ямы на дороге, которые вы объезжаете.
в) К собаке может прилагаться поводок до хозяина, идущего по противоположной части тротуара. влететь в него даже на небольшой скорости — проблемы для всех троих. Вечером/ночью поводок фиг заметишь. Встречая собак, всегда предполагаю, что поводок есть, пока не убедишься в обратном.
г) Дети, дети, дети. Кроме непредсказуемости высокая цена ошибки (так что включаем сюда коляски). Но радость на детских лицах от вида проезжающего рядом моноколесника — бесценна;)
д) Если видно, что не получится безопасно объехать пешехода — "Позвольте, пожалуйста, проехать" (желательно не над ухом, а издалека!).
P.s. Небольшая байка. "Давным-давно, когда был еще неопытен", как-то ехал на велике небольшой отрезок пути по тротуару (по дороге там нельзя). Девушка стоит под крыльцом магазина, никого не трогает, и вдруг внезапно широко шагает на тротуар не глядя. Дисковый тормоз отлично сработал — мы с велом встали на дыбы в сантиметрах перед ней и я радостно воткнулся в тротуар в позе ныряющего с трамплина. Каска, перчатки, опыт айкидо — отделался всего лишь связками на кисти. Девушку, к счастью, только ветерком обдуло.
Так ведь и МНК, и байес вычисляют результат не точно. У МНК есть вполне просто вычисляемая статистическая погрешность — можно использовать стандартное отклонение. У байеса, наверное, тоже можно в каком-то виде погрешность определить. Кстати, интересно, в каком?
В целом спасибо большое за статьи, очень понятное введение для такой неинтуитивной темы!
А вы доверяете авторам руткита? Или "ручками" ломаете?
Пользуюсь их мультиваркой уже лет пять и год — хлебопечкой. Без нареканий.
Но давайте не будем тут статистические исследования проводить;)
У пользователя где? На телефоне, который он завтра потеряет, оставшись без своих треков?
Впрочем, если сервис использует геолокацию только для своей внутренней кухни (типа показать ближайшие банкоматы), то я с вами согласен.
Спасибо за хороший анализ.
Интересно, что у вас достаточно сильно развилась система постановки задач, при этом в ней до сих пор не появилась оценка трудоемкости задач на этапе планирования — у вас оценка ставится только при начале работы над задачей. А это ведь базовый прием — тот же planning poker в Scrum и т.п.
Уверен, что вы не могли его не попробовать на более раннем этапе. Более вероятно, что попробовали и, не получив ожидаемого результата, отказались. Если так, то можете поделиться опытом — какие были результаты, почему отказались?
Особенно забавно звучит отмена (Mayday cancel) или передача по цепочке (Mayday relay), особенно если дальнейшее сообщение с конкретикой (координаты, что случилось, ...) передается на русском или другом «местном» языке — смесь французского, английского и нижегородского.
Некоторые едут на пляж отдыхать, а некоторые — в альплагерь. На Гиктаймсе "матрасный" отдых, а на Хабре суровые русские программисты отдыхают, читая про зубодробительные нововведения C++20. Что не уменьшает полезности этих постов и возможности прийти к ним с конкретным запросом через поиск.
1) Это не код, а блок-схема. Вероятно, она была нарисована, когда авторы совсем запутались в написанном коде;)
2) В этой блок-схеме есть два очевидно отдельных куска с разделением в "What's the user's channel notification pref for this device". При этом нижнюю часть скорее всего можно упростить, т.к. есть пересечение у channel и global notifications (например Mentions). Также если делать не единственные точки выхода (YES/NO), то из схемы пропадёт куча объединяющих стрелочек и она станет не такой страшной.
3) Главное, эта схема описывает реальную сложную бизнес-логику. Ее тоже не стоит переусложнять (пользователю будет непонятно), но это другой случай. Описывающий эту логику код поместится на 1-2 страницах, и с учетом хорошей документации в этом нет проблем. Но есть еще код, который вытаскивает из внутренних структур значения переменных, которые тут в if'е. Если он подмешан к коду бизнес-логики, то именно тогда и получается простыня, требующая рефакторинга.
Да. И что? Идеальных не бывает, у всех свои слабые стороны. Если бы это было критической проблемой для бизнеса, бизнес бы закрылся, а если он живет, значит директор берет чем-то другим (например адекватным планированием все остальное время и пониманием рынка).
Так директор в статье не от желания пропиариться или самоутвердиться так себя ведет. У человека факап, он расстроен и нервничает (больше всех руководителей, естественно, с нее же спрашивают). Ведет себя нелогично поэтому.
Ну так и мы себя тоже не всегда логично ведем, когда на эмоциях. Но это, по крайней мере по нашему мнению, не мешает нам в целом быть хорошими специалистами и полезными сотрудниками.
Области видимости — это не проблема, а благословение, позволяющее экономить сложность.
Если вы выносите в функцию вроде бы обособленный кусок кода, а он тащит с собой 5-10 параметров, значит что-то тут не так. Например, математические расчеты перемешаны с логгированием, получением/записью данных и пр. Другой случай — у вас есть блок данных, которые везде приходится таскать вместе (скажем, длина, ширина и кисть рабочей области рисования), тогда имеет смысл выделить класс-контекст.
Именно выделение функции позволяет такие проблемы обнаружить, и почти всегда после рефакторинга понимаешь, что новый код стал более понятным и чистым.
Еще лучше с длинными простынями. Часто при распутывании таких "нетривиальных" случаев оказывается, что покрыты не все результаты ветвления и в некоторых случаях получатся странные результаты либо явные расчетные или инфраструктурные (забыли считать/модифицировать общие данные) ошибки.
Промазал веткой, ответ на https://habrahabr.ru/post/353160/#comment_10750384