Наверное, мнение не репрезентативное. Но есть примеры (нечасто), когда хочется дать чаевые, и я себя не сдерживаю. К примеру, недавно ехал из аэропорта (на Убере), и водитель
Сразу предложил самостоятельно загрузить весь багаж, чтобы я не испачкался
Как только я сел на заднее сидение, мгновенно подвинул сидение передо мной до упора вперед, чтобы мне было больше места для ног
Ехал в город по самой скоростной полосе (хотя таксисты редко так делают, считая, что дополнительное топливо и износ машины не стоит выигранного времени)
Спросил перед тем, как включить музыку
Поэтому таким давать приятно, и мне приятно осознавать, что таким образом фиксирую правильное поведение. И, соответственно, автоматические чаевые обесценивают такие дополнительные усилия со стороны водителя
Интересно, как вес оценки высчитывают. Если водитель или пассажир 50% контрагентов 1-2* ставит, то его силу голоса погасит алгоритм? А то вспоминается одна преподаватель физики, которая принимала вступительный экзамен по принципу "на 5 знает Бог, на 4 я, а вы все хорошо, если 3 заслужили"
Киевский предприниматель Евгений Чопенко ждал Uber в Харькове 40 минут. Несколько водителей подряд отменяли заказ, но наконец-то машина приехала.
«Цеховая политика – отказывать клиентам с безналичным расчетом», – рассказал водитель такси. Местные таксисты сговорились не только не брать клиентов по безналу, но и мстить таким, ставя плохие оценки в приложении. После поездки Чопенко заметил, что его рейтинг просел с 4,87 до 4,79.
Так водители экономят на комиссии сервиса, объясняет таксист Андрей. По безналичке со счета таксиста Uber списывает четверть стоимости сразу. Выплату комиссии с расчетов наличными можно затягивать на неопределенный период. Таксисты влезают в долги перед сервисом, пока их аккаунт не заблокируют. Потом создают новый.
Но из моего опыта, редко встретишь водителя Убер (по крайней мере в Киеве), который именно на бензине, а не на газу, ездит. Так что может быть, что баг в переводе в итоге дает фичу
Да, мерзко. Особенно, когда ссылка еще и выглядит, как prosto?utm_source=content&utm_medium=blog&utm_campaign=habr&utm_content=znakomstvo.
И так же referer: habr.com/ru/article/488364, зачем еще раз о рекламности напоминать? А вообще да, ссылка на сайт собачников нужнее, как по мне. Ведь нагуглить сервис по его названию вроде задач ж не особо сложная
Тут логично оценить уровень водителя нейросетью, и, в зависимости от этого, включать те или иные алгоритмы (подозреваю, что обгоняющие шумахеры водят не так, так путающие педали пенсионеры), хотя, вангую, будут случаи, когда внук-гонщик сел за машину 90 летней бабушки…
А в самом деле, решение вполне логично (хотя, описывая размышления, и стоит поставить тег «сарказм»).
Учитывая, что вентиляторы не тратят много энергии, а сервера HPE, по видимому, предназначены для дата-центров (и шум тоже некритичен), то единственной причиной, зачем стоит включать вентиляторы не на 100% являются диски (сам знаю, как-то 3 новых серверных диска испортил вибрацией на самосборном 1U сервере, пока не поставил улитку на камень + х2 вентиляторов, и не пустил их последовательно). Поэтому, если сервер без дисков, и портить в нем вибрацией нечего, то, логично, что вопрос уже стоит не «почему 100%?», а «почему не 100%?»
А вот хз. Вопрос спорный. Такие выпускники для работы бок о бок с роботами на складе Амазон, — не по сеньке шапка. А бухгалтера, линейные менеджеры, банковские клерки, — вполне могут и роботами начать заменяться к моменту выпуска текущих первокурсников.
Подозреваю, что директор уже не первому мастеру звонил, и все остальные отказывались. Может, ещё и говорили что-то из разряда "был бы 95й, я бы без вопросов сделал все, а так ищи дураков".
По сути, само возникновение и спрос на такую технологию показывает, как сильно прогнила система университетского образования с лекторами, парами, аудиториями на 100+ людей, и насколько она не то, что отстала от современного мира, а пошла куда-то в другую сторону...
Мы год назад тестировали clickhouse vs postgresql + cstore vs MSSQL с CCI для сложных OLAP запросов на железе выше среднего (1 машинка с 128 ядер, 512 ram, nvme). И тогда вывод был такой:
1. Cstore не умеет эффективно параллелить на больше, чем 8 потоков + он не в ядре -> отсутствие нормального кеширования -> избыточная и неоправданная нагрузка на диск. Так что, совсем не то.
2. Clickhouse реально сделан при понимании всей боли от работы с традиционными субд -> множество функций типа ArgMax именно из разряда «как же хотелось такое же в других СУБД». Очень крутой паралеллизм на простых запросах. Но, увы, стоит дать что-то принципиально сложнее простого group by, и привет однопоточный план -> для реальных задач очень просто нарваться на запрос, который будет шуршать неделю.
3. Тёплый ламповый MSSQL, на удивление, хорош на таблицах с кластерным колоночным индексом (даже планы заметно лучше и параллельнее для одинакового запроса, одинаковой схемы, но при колоночном хранении данных). Да, пролицензировать лицензией за ядро космос (а лицензия за сервер это ограничение на 20 ядер), и да, кластера, как в CH, не поднимешь. Вообщем, для себя сделал вывод, что если исполняются два условия, — данные помещаются на одной железке (а сейчас железки на 8 сокетов, 12ТБ памяти и дисковой подсистемой с перфомансом в 25ГБ/сек это реальность) и стоимость лицензии не пугает, то это лучшее решение на рынке под ряд бигдатных задач.
Ну и, ещё несколько вариантов даже не тестировали. Среди них:
1. Hadoop, spark — команда хорошо владела SQL, и переучиваться на map reduce в явном виде, — сильная потеря темпа. Об решениях SQL over spark/hadoop для сложных запросов ничего хорошего не слышал.
2. Vertica, teradata, — отличный способ крепко и наверняка сесть на иглу консалтинга (ведь как такового рынка состоявшихся специалистов по этим технологиям нет, а найти молодого способного с горящими глазами и мечтой изучить Вертику задача нетривиальная). Нет, спасибо.
Так те же яйца, только в профиль. Протолкнут закон, что надо хранить. Пусть не в США, но прецеденты мы знаем. И да, платность не защитит от создания АПИ, но заставит очень бережно его использовать. Ведь за израсходованные миллионы долларов налогоплательщиков за излишние запросы могут потом и спросить.
И при этом пользователи реально останутся в выигрыше, а то ведь, не сделай такого, и органы рано или поздно API захотят, и начнут по 100500 запросов в день кидать…
Все от критериев и бизнес-модели зависит, увы. Если менеджер отвечает за делание разовых аутсорс проектов на фикс прайсе, которые получены по субподряду от более успешных аутсорсеров, то для него это не то, чтобы очень хороший программист, а просто лучший. Да, могут вопросы к менеджеру, почему он так себя не уважвет, что таким занимается, но это уже выходит за рамки поста и обсуждения.
Поэтому таким давать приятно, и мне приятно осознавать, что таким образом фиксирую правильное поведение. И, соответственно, автоматические чаевые обесценивают такие дополнительные усилия со стороны водителя
Интересно, как вес оценки высчитывают. Если водитель или пассажир 50% контрагентов 1-2* ставит, то его силу голоса погасит алгоритм? А то вспоминается одна преподаватель физики, которая принимала вступительный экзамен по принципу "на 5 знает Бог, на 4 я, а вы все хорошо, если 3 заслужили"
Так а в чем смысл тогда? Как бы себя водитель не вел, — от конкретного пассажира он получит одинаковые чаевые вне зависимости от желания пассажира?
«Цеховая политика – отказывать клиентам с безналичным расчетом», – рассказал водитель такси. Местные таксисты сговорились не только не брать клиентов по безналу, но и мстить таким, ставя плохие оценки в приложении. После поездки Чопенко заметил, что его рейтинг просел с 4,87 до 4,79.
Так водители экономят на комиссии сервиса, объясняет таксист Андрей. По безналичке со счета таксиста Uber списывает четверть стоимости сразу. Выплату комиссии с расчетов наличными можно затягивать на неопределенный период. Таксисты влезают в долги перед сервисом, пока их аккаунт не заблокируют. Потом создают новый.
Взято тут
И так же referer: habr.com/ru/article/488364, зачем еще раз о рекламности напоминать? А вообще да, ссылка на сайт собачников нужнее, как по мне. Ведь нагуглить сервис по его названию вроде задач ж не особо сложная
Тут логично оценить уровень водителя нейросетью, и, в зависимости от этого, включать те или иные алгоритмы (подозреваю, что обгоняющие шумахеры водят не так, так путающие педали пенсионеры), хотя, вангую, будут случаи, когда внук-гонщик сел за машину 90 летней бабушки…
Что-то пост сильно SEO статьи с ключами напоминает...
Учитывая, что вентиляторы не тратят много энергии, а сервера HPE, по видимому, предназначены для дата-центров (и шум тоже некритичен), то единственной причиной, зачем стоит включать вентиляторы не на 100% являются диски (сам знаю, как-то 3 новых серверных диска испортил вибрацией на самосборном 1U сервере, пока не поставил улитку на камень + х2 вентиляторов, и не пустил их последовательно). Поэтому, если сервер без дисков, и портить в нем вибрацией нечего, то, логично, что вопрос уже стоит не «почему 100%?», а «почему не 100%?»
А вот хз. Вопрос спорный. Такие выпускники для работы бок о бок с роботами на складе Амазон, — не по сеньке шапка. А бухгалтера, линейные менеджеры, банковские клерки, — вполне могут и роботами начать заменяться к моменту выпуска текущих первокурсников.
Подозреваю, что директор уже не первому мастеру звонил, и все остальные отказывались. Может, ещё и говорили что-то из разряда "был бы 95й, я бы без вопросов сделал все, а так ищи дураков".
По сути, само возникновение и спрос на такую технологию показывает, как сильно прогнила система университетского образования с лекторами, парами, аудиториями на 100+ людей, и насколько она не то, что отстала от современного мира, а пошла куда-то в другую сторону...
1. Cstore не умеет эффективно параллелить на больше, чем 8 потоков + он не в ядре -> отсутствие нормального кеширования -> избыточная и неоправданная нагрузка на диск. Так что, совсем не то.
2. Clickhouse реально сделан при понимании всей боли от работы с традиционными субд -> множество функций типа ArgMax именно из разряда «как же хотелось такое же в других СУБД». Очень крутой паралеллизм на простых запросах. Но, увы, стоит дать что-то принципиально сложнее простого group by, и привет однопоточный план -> для реальных задач очень просто нарваться на запрос, который будет шуршать неделю.
3. Тёплый ламповый MSSQL, на удивление, хорош на таблицах с кластерным колоночным индексом (даже планы заметно лучше и параллельнее для одинакового запроса, одинаковой схемы, но при колоночном хранении данных). Да, пролицензировать лицензией за ядро космос (а лицензия за сервер это ограничение на 20 ядер), и да, кластера, как в CH, не поднимешь. Вообщем, для себя сделал вывод, что если исполняются два условия, — данные помещаются на одной железке (а сейчас железки на 8 сокетов, 12ТБ памяти и дисковой подсистемой с перфомансом в 25ГБ/сек это реальность) и стоимость лицензии не пугает, то это лучшее решение на рынке под ряд бигдатных задач.
Ну и, ещё несколько вариантов даже не тестировали. Среди них:
1. Hadoop, spark — команда хорошо владела SQL, и переучиваться на map reduce в явном виде, — сильная потеря темпа. Об решениях SQL over spark/hadoop для сложных запросов ничего хорошего не слышал.
2. Vertica, teradata, — отличный способ крепко и наверняка сесть на иглу консалтинга (ведь как такового рынка состоявшихся специалистов по этим технологиям нет, а найти молодого способного с горящими глазами и мечтой изучить Вертику задача нетривиальная). Нет, спасибо.
Представил. Как апворк, только репутация при этом не фармится)
Нет, чтобы продать за $1, или в опен сорс отдать...