Вы не видите, скорее всего, потому, что это и не тур. Это отель. Туры в этот отель начинаются от указанной цены, сами туры внутри, за кнопкой.
Это общий тренд в отрасли среди агрегаторов, но, действительно, с пониманием у людей новых иногда возникают проблемы. Мы тоже с этим боремся, но хорошего решения пока не придумали :)
Вот уж кому, а Библиоглобусу я бы в этом вопросе не доверял. Ровно до момента подтверждения этой цены при бронировании. Многовато косяков за эти одним крупным партнёром
Давно поглядываю, но интересует вопрос с травмоопасностью этого вида транспорта. Интуитивно кажется, что падать с него приходится регулярно, в отличие от велосипеда. Или нет?
УЭК — это, по сути, просто банковская карта. Со слегка расширенными возможностями. Банковские карты принимают не везде. Более того, даже электричество есть не всегда и не везде :) А если получать идентификатор без спецсредств, то как защититься от того, что на вас запишут то, чего вы не покупали?
К тому же, недостатки УЭК будут такими же, как и прочих банковских карт — их будут регулярно терять. И пока вам её не восстановят (для паспорта сейчас это, на секундочку, 10 рабочих дней) — вы даже бутылку воды купить не сможете?
А детей всех лет с 8 вы тоже предлагаете ими обеспечить? Им надо под кожу вшивать, не иначе, а то точно потеряют.
Ну и ко всему прочему, ваша система не помогает собирать мусор. Если нашёлся человек, который бутылку-таки выбросил (ну, мало ли, неудобно ему было её нести), то кто и зачем отнесёт её на переработку?
Что вы подразумеваете под вопросом «как контролировать»? Что надо контролировать, и чем это отличается от контроля текущих акцизов на алкоголь и сигареты?
В предыдущем комментарии вы говорили об утилизации обычными гражданами, теми, кто продукцию в такой таре употребил. У них нет затрат на поиск. Транспортировка же, в общем случае, должна быть в тот же супермаркет, из которого бутылки/банки были принесены домой. Дополнительных усилий минимум.
Штрафы работают тогда, когда они чувствительны. 1/10 МРОТ — это 800р. Если вы выпиваете банку пива каждый день, за месяц с акцизом 30р это 900р. Так что порядок цифр что у вас, что у меня, вполне совпадает. Чтобы определить эффективную цифру, нужно провести нормальный анализ, которого мы с вами, полагаю, проводить не станем.
Для вашего варианта надо:
1. Дождаться реализации несуществующий системы аккаунтинга.
2. Придумать, как все граждане, которые могут купить молоко в магазине, будут пополнять этот счёт
3. Придумать, как заставить их это делать.
4. Придумать, как торговая точка будет идентифицировать гражданина (и к каким вашим данным при этом получит доступ)
5. Как-то разобраться с социальными отношениями (Пиво купил я, бутылку сдала жена. Или тёща. Или сосед по комнате).
6. Найти тех, кому будет выгодно организовывать точки приёма всего этого добра.
7. Найти тех, кому будет выгодно перерабатывать принятое.
Для моего варианта надо:
1. Взять с предприятия дополнительный налог за каждую бутылку продукции. Наверное, можно даже брать за каждую тонну стекла/алюминия/пластика в упаковке.
2. Вернуть этот налог предприятию, которое переработало эту тонну отходов во вторичку.
3. Всё. Дальше рынок всё сделает сам.
Зачем так сложно?
Акциза на тару будет достаточно. 10-20-30 рублей за стеклянную бутылку/алюминиевую банку. За переработанные бутылки/банки акциз возвращается.
Интересно, как планируется обеспечить защиту от повреждений кабеля, которым на иллюстрации связаны посадочный модуль и зонд? И как обеспечить правильное функционирование лебёдки с ним? Недавний пост lozga про тросовые системы наглядно показал, что размотать несколько километров троса даже в условиях открытого космоса проблема, а тут ещё ползти «5-40км», волоча его за собой…
Попробуйте представить так — каждому условному "пикселю" картинки, которую вы видите, соответствует условный "пиксель" в матрице глаза. Вы смотрите на стену. Если лазер проедет от края стены до другого края, вы получите засветку (и повреждение) разных "пикселей" в глазу. Если же лазер ведёт себя, как луч маяка, то на итоговой картинке он будет в одном месте, даже поворачиваясь — следовательно, засвечиваться будут одни и те же "пиксели" на матрице.
В ваших примерах слишком много субъективности. Безусловно, всем не угодишь — вам вот банку с собой таскать неудобно, а мне неудобно держать толстый и тяжёлый смарт в общественном транспорте одной рукой — у меня Note 4, у жены Note 3 в чехле, просто в чехле, даже без батареи. Он раза в два толще в результате и раза в полтора тяжелее, так что я не для красного словца говорю про неудобство. Зато в рюкзаке, который всегда при мне, место под банку выделить элементарно.
Опять же, «минимум день работать под нагрузкой» — нагрузка у каждого субъективная. Под моей обычной нагрузкой (~4 часа в день в браузере и с музыкой) мой смарт с небольшим запасом доживает до вечера. Но это только тогда, когда я не запускаю ингресс :) Тут уж, простите, и чемоданчика из ералаша не хватит на день.
Вы знаете, вот регулярно наблюдаю в обсуждениях сожаления на тему того, что смарты худеют якобы за счёт времени работы, и не могу понять сожалеющих. В чём необходимость аккумулятора в смартфоне какой-то особенно нетипичной для современного рынка ёмкости? Вам так необходимо именно в устройстве держать весь дневной (трёхдневный, недельный...) запас энергии? В продаже есть пауэрбанки на любой вкус и кошелёк, любой необходимой ёмкости, с возможностью заряжать почти любое из ваших устройств, которому требуется зарядка. Вот честное слово, куда больше ёмкости аккумулятора напрягает, когда 3.5мм разъём убирают, или аккумулятор делают несъёмным.
Это не совсем так. «Вкладывать, перекладывать» — это гораздо лучше, чем вывести деньги из бизнеса. В зависимости от того, куда вкладывается компания, это создаёт новые рабочие места, увеличивает ВВП, стимулирует развитие других отраслей (поставщики/потребители), развивает науку и инженерию (посмотрите на Интел и другие наукоёмкие производства), образование (отчётливо видно в IT, где свои будущие кадры компании зачастую учат сами), и ещё тысяча разных примеров.
На каждый не уплаченный в виде налога доллар компания вкладывает ±5 долларов в экономику. Плохо от этого может быть только тем, кто тот самый доллар собирался украсть.
В ваших рассуждениях есть рациональное зерно. Однако, вы столь же безапелляционно заявляете, что A/B не нужны, прямо в заголовке, как и те, «кто думает что A/B-тесты это просто/панацея/нужно всем и в любом проекте». Бросаться из крайности в крайность — это не то, чтобы не научный подход, это просто неразумно.
Давайте я выступлю адвокатом дьявола, и приведу несколько аргументов за A/B тесты, даже если они недостаточно хорошо учитывают все факторы. Так или иначе, все живые проекты меняют что-то. Раз уж вы в статье ведёте речь об интерфейсе, давайте этим «чем-то» он и будет.
Предположим, вы хотите изменить какой-то элемент управления. У вас даже есть видение того, как именно это нужно сделать, и почему это будет лучше, чем текущий вариант (и я со всей ответственностью уверяю, что эти два пункта далеко не всегда выполняются...). Подход с A/B тестированием означает, что вам нужно формализовать свою гипотезу. Это уже хорошо — если вам приходится описать то, что есть в голове, словами на бумаге или в задачнике, зачастую уже на этом этапе видны недочёты. Так или иначе вы с ними справитесь, задача уйдёт в разработку.
В результате вы наснимаете каких-то метрик. Возможно даже, эти метрики будут недостаточно качественными, не учтут каких-то факторов, и так далее. Однако, теперь вы можете оперировать данными! Не ощущениями, не желаниями левой пятки, а вполне конкретными цифрами. Естественно, если вы «эффективный менеджер», вы можете вывернуть цифры так, чтобы представить их, как нужный вам результат. Но, положа руку на сердце, что вам мешает без всяких тестов сделать то же самое? Такое отношение к делу — проблема конкретных людей и рабочих процессов, в которых они участвуют, но не инструмента A/B-тестирования.
Из вашей статьи я так и не понял, что конкретно вы пробовали, а что — ваши домыслы за фразами «представьте» и «может так получиться». Зато понял, что, с вашей точки зрения, у разработчиков может бомбить, когда вы предлагаете сделать отдельную страницу для новой формы регистрации с отдельным поведением. Вы знаете, я могу в такое поверить, только если в приведённом монологе каждое предложение было спустя пару дней после предыдущего. Потому что это бы показывало, что вы сами не знаете, что вам надо, и не в состоянии формализовать требования. В остальном — это обычная задача, никто с неё кипятиться не будет. То, что для минимизации наводок разумно показывать оба варианта сразу, разным пользователям — мне казалось достаточно очевидным, чтобы люди не пытались тестировать варианты по очереди.
Насчёт аналитики результатов — ну, да, это работа, которую должен работать человек, который в этом разбирается или, на худой конец, хочет научиться разбираться и прикладывает к этому усилия. Нет, A/B-тестирование — это не про то, чтобы генератор случайных чисел и два цвета кнопки повышали вам конверсию на 10%. Это инструмент, которому нужен мастер. Который понимает, что надо проверить, и как именно это надо сделать — например, какие метрики снимать в процессе.
В общем, вы уж простите, но описанных вами предположений явно недостаточно для того, чтобы «заколачивать крышку гроба».
Мне казалось, основная ценность информации вида «ваши пароли утекли» — не в том, чтобы защитить аккаунт в скомпрометированном сервисе, а в том, чтобы заменить тот же пароль на прочих ресурсах. Да, да, нельзя ставить одинаковые пароли, но иногда люди так делают :)
Всё нормально в этой функции. Комментирующие допускают типичную ошибку — не зная, что какие типы данных функция принимает, не уточнив, какой тип данных она должна вернуть, сразу вносят «оптимизации», экономя пару строчек кода.
А если всего лишь предположить, что функция обязана вернуть bool, то код выглядит совсем не бессмысленным. Потому что, на секундочку, в JS 1 && 2 — это 2, а не true (как раз кто-то там ниже спрашивал о языке, в котором && возвращает не bool… сюрприз!). Входные данные тоже могут быть разные — их может не быть (undefined), они могут быть не bool (тогда сработает приведение типов). Так что isPrepared совсем необязательно будет bool вообще.
И в результате, единственной оптимизацией, которая бы не изменила поведение функции, была бы замена блока if на return !!isPrepared;, с принудительным приведением типа двойным отрицанием. Тем, кто пишет на js регулярно, эта запись привычна. Для остальных, пожалуй, удачнее была бы запись return Boolean(isPrepared);
Если я правильно помню, какой-то из аппаратов (вроде бы, Кьюриосити) за время полёта намерял дозу радиации, лишь немного превышающую максимально допустимую для астронавтов за всю карьеру. А эта доза, в свою очередь, повышает риск возникновения злокачественных опухолей всего на 5%, что, согласитесь, не так страшно. Когда вы летите жить на другую планету, боюсь, у вас немного шансов умереть от рака :)
PS Тут напутал, там ошибся, а в итоге почти правильная цифра :) https://geektimes.ru/post/181608/
Это общий тренд в отрасли среди агрегаторов, но, действительно, с пониманием у людей новых иногда возникают проблемы. Мы тоже с этим боремся, но хорошего решения пока не придумали :)
К тому же, недостатки УЭК будут такими же, как и прочих банковских карт — их будут регулярно терять. И пока вам её не восстановят (для паспорта сейчас это, на секундочку, 10 рабочих дней) — вы даже бутылку воды купить не сможете?
А детей всех лет с 8 вы тоже предлагаете ими обеспечить? Им надо под кожу вшивать, не иначе, а то точно потеряют.
Ну и ко всему прочему, ваша система не помогает собирать мусор. Если нашёлся человек, который бутылку-таки выбросил (ну, мало ли, неудобно ему было её нести), то кто и зачем отнесёт её на переработку?
В предыдущем комментарии вы говорили об утилизации обычными гражданами, теми, кто продукцию в такой таре употребил. У них нет затрат на поиск. Транспортировка же, в общем случае, должна быть в тот же супермаркет, из которого бутылки/банки были принесены домой. Дополнительных усилий минимум.
Штрафы работают тогда, когда они чувствительны. 1/10 МРОТ — это 800р. Если вы выпиваете банку пива каждый день, за месяц с акцизом 30р это 900р. Так что порядок цифр что у вас, что у меня, вполне совпадает. Чтобы определить эффективную цифру, нужно провести нормальный анализ, которого мы с вами, полагаю, проводить не станем.
Для вашего варианта надо:
1. Дождаться реализации несуществующий системы аккаунтинга.
2. Придумать, как все граждане, которые могут купить молоко в магазине, будут пополнять этот счёт
3. Придумать, как заставить их это делать.
4. Придумать, как торговая точка будет идентифицировать гражданина (и к каким вашим данным при этом получит доступ)
5. Как-то разобраться с социальными отношениями (Пиво купил я, бутылку сдала жена. Или тёща. Или сосед по комнате).
6. Найти тех, кому будет выгодно организовывать точки приёма всего этого добра.
7. Найти тех, кому будет выгодно перерабатывать принятое.
Для моего варианта надо:
1. Взять с предприятия дополнительный налог за каждую бутылку продукции. Наверное, можно даже брать за каждую тонну стекла/алюминия/пластика в упаковке.
2. Вернуть этот налог предприятию, которое переработало эту тонну отходов во вторичку.
3. Всё. Дальше рынок всё сделает сам.
Акциза на тару будет достаточно. 10-20-30 рублей за стеклянную бутылку/алюминиевую банку. За переработанные бутылки/банки акциз возвращается.
Попробуйте представить так — каждому условному "пикселю" картинки, которую вы видите, соответствует условный "пиксель" в матрице глаза. Вы смотрите на стену. Если лазер проедет от края стены до другого края, вы получите засветку (и повреждение) разных "пикселей" в глазу. Если же лазер ведёт себя, как луч маяка, то на итоговой картинке он будет в одном месте, даже поворачиваясь — следовательно, засвечиваться будут одни и те же "пиксели" на матрице.
Опять же, «минимум день работать под нагрузкой» — нагрузка у каждого субъективная. Под моей обычной нагрузкой (~4 часа в день в браузере и с музыкой) мой смарт с небольшим запасом доживает до вечера. Но это только тогда, когда я не запускаю ингресс :) Тут уж, простите, и чемоданчика из ералаша не хватит на день.
На каждый не уплаченный в виде налога доллар компания вкладывает ±5 долларов в экономику. Плохо от этого может быть только тем, кто тот самый доллар собирался украсть.
Давайте я выступлю адвокатом дьявола, и приведу несколько аргументов за A/B тесты, даже если они недостаточно хорошо учитывают все факторы. Так или иначе, все живые проекты меняют что-то. Раз уж вы в статье ведёте речь об интерфейсе, давайте этим «чем-то» он и будет.
Предположим, вы хотите изменить какой-то элемент управления. У вас даже есть видение того, как именно это нужно сделать, и почему это будет лучше, чем текущий вариант (и я со всей ответственностью уверяю, что эти два пункта далеко не всегда выполняются...). Подход с A/B тестированием означает, что вам нужно формализовать свою гипотезу. Это уже хорошо — если вам приходится описать то, что есть в голове, словами на бумаге или в задачнике, зачастую уже на этом этапе видны недочёты. Так или иначе вы с ними справитесь, задача уйдёт в разработку.
В результате вы наснимаете каких-то метрик. Возможно даже, эти метрики будут недостаточно качественными, не учтут каких-то факторов, и так далее. Однако, теперь вы можете оперировать данными! Не ощущениями, не желаниями левой пятки, а вполне конкретными цифрами. Естественно, если вы «эффективный менеджер», вы можете вывернуть цифры так, чтобы представить их, как нужный вам результат. Но, положа руку на сердце, что вам мешает без всяких тестов сделать то же самое? Такое отношение к делу — проблема конкретных людей и рабочих процессов, в которых они участвуют, но не инструмента A/B-тестирования.
Насчёт аналитики результатов — ну, да, это работа, которую должен работать человек, который в этом разбирается или, на худой конец, хочет научиться разбираться и прикладывает к этому усилия. Нет, A/B-тестирование — это не про то, чтобы генератор случайных чисел и два цвета кнопки повышали вам конверсию на 10%. Это инструмент, которому нужен мастер. Который понимает, что надо проверить, и как именно это надо сделать — например, какие метрики снимать в процессе.
В общем, вы уж простите, но описанных вами предположений явно недостаточно для того, чтобы «заколачивать крышку гроба».
Эка вы интересно сравниваете КПД потребления топлива с одной стороны, и КПД производства другого "топлива"-электроэнергии с другой.
А если всего лишь предположить, что функция обязана вернуть bool, то код выглядит совсем не бессмысленным. Потому что, на секундочку, в JS 1 && 2 — это 2, а не true (как раз кто-то там ниже спрашивал о языке, в котором && возвращает не bool… сюрприз!). Входные данные тоже могут быть разные — их может не быть (undefined), они могут быть не bool (тогда сработает приведение типов). Так что isPrepared совсем необязательно будет bool вообще.
И в результате, единственной оптимизацией, которая бы не изменила поведение функции, была бы замена блока if на return !!isPrepared;, с принудительным приведением типа двойным отрицанием. Тем, кто пишет на js регулярно, эта запись привычна. Для остальных, пожалуй, удачнее была бы запись return Boolean(isPrepared);
Господа, уточняйте постановку задачи :)
PS Тут напутал, там ошибся, а в итоге почти правильная цифра :) https://geektimes.ru/post/181608/