Еще как принудить. Да и там насколько смешные суммы, особо на фоне IT зарплат даже джунов, что любой чуточку вменяемый работодатель заплатит. Скорее не платят просто потому что эти положения про удаленную работу в ТК достаточно новые и где-то в бухгалтерии присутствует лень.
Вы не обязаны соглашаться с местом дворника. Если сокращают вашу ставку, то уведомление за 2 месяца + выходное пособие 1 месяц + можете еще 1 месяц потребовать если не устроились на работу (или даже 2, если вам с службе занятости не нашли работу). + есть некие соц гарантии, например, вас не могут сократить, если вы на больничном Ну и для работодателя это куча бумажной волокиты. И да, если работодатель сократил штатное расписание, а через два месяца после вашего увольнения ввел его обратно - через суд такое увольнение вполне вероятно может быть оспорено.
Причем тут измерения? Вы по ТД работали? 8 часов в день. Оклад платили вам?
А всякое “я больше работал и по выходным" или "я работал много меньше" - это уже ваш внутренний обменный курс. С точки зрения работодателя он покупал ваши 8 часов в день.
вы купили КАМАЗ, утром приходите чтобы груз перевозить, а он сам уехал в другой гараж потому что ему на борт красивую наклейку наклеили и новую резину поставили
Не купили, а договорились о временной работе на вас с подписанием договора. Камаз решил расторгнуть договор в оговоренном порядке из-за новой резины? Добро пожаловать в реальный мир.
Такая статистика у Яндекса ведется, я уверен, и жалобы "водитель попросил отменить заказ" тоже учитываются. Но мое сообщение было скорее про то, что водители - не рабы, они работают сдельно и очевидно, что хотят заработать больше тогда, когда это возможно. А государство... оно предоставляет общественный транспорт.
гпс спуфинг делается за очень небольшие деньги.
затраты водителя на возню с ним (не только установка, но и использование) не окупится, водители вообще нажимают ранее "на месте", что бы меньше ждать пассажиров, а то пока они выйдут...
Адекватный родитель может посчитать риск аварии в поездке и принять его
Как хорошо, что это зарегулировано не на уровне такси, а на уровне ПДД.
Водитель хочет заработать, удивительно! Вы решили схитрить, но водитель не дурак? Захватывающая история. Каждый преследует свои финансовые интересы, поразительно!
Так и не понял, в чем проблема? Если вы уже на точке ожидания, то вам хватит времени сесть, а если времени не хватило - пишите в поддержку, которая прекрасно видит где водитель что нажал и где вы находились. А если вы еще не дошли до точки ожидания - то какая вам разница где нажал водитель?
Это как, разыгрывать в лотерею раз в неделю "приз - вози два детских кресла"? Если таксисту не выгодно таскать кресла, это его право, причем тут Яндекс. Раз таксисты не возят кресла, значит им это не выгодно - малый спрос на услугу, который не оправдывает затраты на кресло и на забитый багажник. А вы опять предлагаете решать вашу проблему за чужой счет. Попробуйте заказывать "к определенному времени".
Как высшее образование учит вас работать с информацией, так алгоритмические задачи учат вас работать с задачами. Не даром на собеседованиях так много уделяют внимания тому, как вы работаете с условиями задачи и как прокладываете путь решения.
К тому же, то, что вы все же смогли подготовиться к подобному собеседованию с помощью решения подобных задач уже неплохо говорит о том, что вы обучаемы и что вы заинтересованы в этой работе.
Имхо, знание алгоритмов как таковых важно в этих собеседованиях по остаточному принципу. Тем более, ну нет там каких-то алгоритмов требующих серьезных научных изысканий, большинство задач на весьма базовые знания, а вот важно уметь применять эти знания в решении данной вам задачи (ровно как вы будете применять какие-то другие свои знания в решении продуктовых задач потом).
Хранение сообщений внутри сервиса нужно, что бы уметь повторять сообщения, которые не получилось отправить (ретрай) или что бы поддерживать pull схему, когда к тебе приходят за данными. Но брокер для этих целей не используют ибо у сервиса уже есть что-то, что выполняет его функции. База или просто хранение в памяти. Дополнительно кролик - не нужная сложность, ибо еще придется решать вопрос ошибок записи в этот локальный кролик, т.е. все-равно потребуется какая-то вторая очередь в памяти.
И с точки зрения этой задачи "доставки сообщения" сервису все-равно куда доставлять, в брокера или в другой сервис. Оба могут не принять сообщение. В обоих случаях нужно решать проблему ретраев.
По-этому, если у вас коммуникация "сервис-сервис", то брокер тут избыточен как "посередине", так и "внутри". Т.е. решалась какая-то несуществующая проблема.
Брокер же используют, когда нужна гибкость распределения одного сообщения по разным потребителям (кролик) или же когда нужен накопительный буфер для потоковой работы с данными (кафка).
И вот, для решения гибкого распределения сообщений вы говорите "давайте кролика заменим на сервис, который будет ходить в кролика". В принципе, такое даже делают, но не для того, что бы просто amqp на http заменить (у кролика есть http интерфейс, используйте если так amqp не любите), а решая более комплексные задачи от API композиции до сервис дискавери. А просто написать сервис, который конвертирует amqp кролика под капотом во внешний http - это какое-то усложнение не решающее никаких проблем.
Ваша сравнительна таблица, это такое натягивание совы на глобус, что прям скучно. То брокер сообщений домен размывает, то proto файлы кто-то запретил использовать для сообщений из кролика.
When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program — indeed, it's often impossible with languages such as Java that return only a single value.
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.
Как же любят старички вспоминать про KISS. Но принцип то не о том, что "делай как можно проще", а о том, что использовать и обслуживать механизмы должно быть просто. Сделал пуш, нажал кнопку - раскатилось, нажал другую - откатилось, вот KISS, и вся работа девопсов как раз про это. А то, что там под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту.
DTO не для хранения, а для передачи данных. Это передача данных в конкретном контексте. Ничего криминального в инкапсуляции сериализации нет. Вообще можно начать с Фаулера.
Поведение != методы. Сериализация/десериализация - это не поведение объекта. Это по сути то, для чего вообще создается DTO - передать его по каналам связи.
DTO не содержит бизнес логики, а не "логики вообще". Сериализация/десереализация - эта логика, которая очень подходит для инкапсуляции ее в DTO, ибо вообще вся суть DTO изначально - быть сериализованной.
Несомненно, законы работают только в том случае, если отстаивать свои права.
Компенсация пропорциональна рабочему времени, конечно.
Еще как принудить. Да и там насколько смешные суммы, особо на фоне IT зарплат даже джунов, что любой чуточку вменяемый работодатель заплатит. Скорее не платят просто потому что эти положения про удаленную работу в ТК достаточно новые и где-то в бухгалтерии присутствует лень.
Вы не обязаны соглашаться с местом дворника. Если сокращают вашу ставку, то уведомление за 2 месяца + выходное пособие 1 месяц + можете еще 1 месяц потребовать если не устроились на работу (или даже 2, если вам с службе занятости не нашли работу).
+ есть некие соц гарантии, например, вас не могут сократить, если вы на больничном
Ну и для работодателя это куча бумажной волокиты. И да, если работодатель сократил штатное расписание, а через два месяца после вашего увольнения ввел его обратно - через суд такое увольнение вполне вероятно может быть оспорено.
Компенсация за использование своего оборудования, интернета и электричества на удаленке предусмотрена ТК
Причем тут измерения? Вы по ТД работали? 8 часов в день. Оклад платили вам?
А всякое “я больше работал и по выходным" или "я работал много меньше" - это уже ваш внутренний обменный курс. С точки зрения работодателя он покупал ваши 8 часов в день.
т.е. вам в этой истории не платили денег за время?
Не купили, а договорились о временной работе на вас с подписанием договора. Камаз решил расторгнуть договор в оговоренном порядке из-за новой резины? Добро пожаловать в реальный мир.
"Никогда проблем не было" можно было бы написать на многих могилах.
Такая статистика у Яндекса ведется, я уверен, и жалобы "водитель попросил отменить заказ" тоже учитываются. Но мое сообщение было скорее про то, что водители - не рабы, они работают сдельно и очевидно, что хотят заработать больше тогда, когда это возможно. А государство... оно предоставляет общественный транспорт.
затраты водителя на возню с ним (не только установка, но и использование) не окупится, водители вообще нажимают ранее "на месте", что бы меньше ждать пассажиров, а то пока они выйдут...
Как хорошо, что это зарегулировано не на уровне такси, а на уровне ПДД.
Водитель хочет заработать, удивительно! Вы решили схитрить, но водитель не дурак? Захватывающая история. Каждый преследует свои финансовые интересы, поразительно!
Так и не понял, в чем проблема? Если вы уже на точке ожидания, то вам хватит времени сесть, а если времени не хватило - пишите в поддержку, которая прекрасно видит где водитель что нажал и где вы находились. А если вы еще не дошли до точки ожидания - то какая вам разница где нажал водитель?
Это как, разыгрывать в лотерею раз в неделю "приз - вози два детских кресла"? Если таксисту не выгодно таскать кресла, это его право, причем тут Яндекс. Раз таксисты не возят кресла, значит им это не выгодно - малый спрос на услугу, который не оправдывает затраты на кресло и на забитый багажник. А вы опять предлагаете решать вашу проблему за чужой счет. Попробуйте заказывать "к определенному времени".
Как высшее образование учит вас работать с информацией, так алгоритмические задачи учат вас работать с задачами. Не даром на собеседованиях так много уделяют внимания тому, как вы работаете с условиями задачи и как прокладываете путь решения.
К тому же, то, что вы все же смогли подготовиться к подобному собеседованию с помощью решения подобных задач уже неплохо говорит о том, что вы обучаемы и что вы заинтересованы в этой работе.
Имхо, знание алгоритмов как таковых важно в этих собеседованиях по остаточному принципу. Тем более, ну нет там каких-то алгоритмов требующих серьезных научных изысканий, большинство задач на весьма базовые знания, а вот важно уметь применять эти знания в решении данной вам задачи (ровно как вы будете применять какие-то другие свои знания в решении продуктовых задач потом).
Хранение сообщений внутри сервиса нужно, что бы уметь повторять сообщения, которые не получилось отправить (ретрай) или что бы поддерживать pull схему, когда к тебе приходят за данными. Но брокер для этих целей не используют ибо у сервиса уже есть что-то, что выполняет его функции. База или просто хранение в памяти. Дополнительно кролик - не нужная сложность, ибо еще придется решать вопрос ошибок записи в этот локальный кролик, т.е. все-равно потребуется какая-то вторая очередь в памяти.
И с точки зрения этой задачи "доставки сообщения" сервису все-равно куда доставлять, в брокера или в другой сервис. Оба могут не принять сообщение. В обоих случаях нужно решать проблему ретраев.
По-этому, если у вас коммуникация "сервис-сервис", то брокер тут избыточен как "посередине", так и "внутри". Т.е. решалась какая-то несуществующая проблема.
Брокер же используют, когда нужна гибкость распределения одного сообщения по разным потребителям (кролик) или же когда нужен накопительный буфер для потоковой работы с данными (кафка).
И вот, для решения гибкого распределения сообщений вы говорите "давайте кролика заменим на сервис, который будет ходить в кролика". В принципе, такое даже делают, но не для того, что бы просто amqp на http заменить (у кролика есть http интерфейс, используйте если так amqp не любите), а решая более комплексные задачи от API композиции до сервис дискавери. А просто написать сервис, который конвертирует amqp кролика под капотом во внешний http - это какое-то усложнение не решающее никаких проблем.
Ваша сравнительна таблица, это такое натягивание совы на глобус, что прям скучно. То брокер сообщений домен размывает, то proto файлы кто-то запретил использовать для сообщений из кролика.
Хочется такую крышечку сверху, а под ней pci-e, а доп питалово можно и отдельным блоком.
Хотя возможно USB4 поможет?
Ну я про эту статью https://martinfowler.com/bliki/LocalDTO.html
Экономия — ну тут я по сути цитирую P of EAA:
А DTO изначально задумывался для других целей, а именно для экономии дорогих внешних вызовов. То, о чем вы говорите — это по Фаулеру LocalDTO.
Как же любят старички вспоминать про KISS. Но принцип то не о том, что "делай как можно проще", а о том, что использовать и обслуживать механизмы должно быть просто. Сделал пуш, нажал кнопку - раскатилось, нажал другую - откатилось, вот KISS, и вся работа девопсов как раз про это. А то, что там под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту.
DTO не для хранения, а для передачи данных. Это передача данных в конкретном контексте. Ничего криминального в инкапсуляции сериализации нет. Вообще можно начать с Фаулера.
Поведение != методы. Сериализация/десериализация - это не поведение объекта. Это по сути то, для чего вообще создается DTO - передать его по каналам связи.
DTO не содержит бизнес логики, а не "логики вообще". Сериализация/десереализация - эта логика, которая очень подходит для инкапсуляции ее в DTO, ибо вообще вся суть DTO изначально - быть сериализованной.