почему, дать ORMке явное указание подгрузить связи (те же ленивые например) - вполне себе частый юзкейс джоинов. просто там не надо писать ни условие, ни сущности, просто указываешь какую связь заджоинить.
Если речь идёт о раздаче на безлимитном тарифе (они остались как архивные, насколько я знаю), то позиция МТС вполне логична.
то это все равно изменение условий договора в одностороннем порядке. но раньше оверселлинг видимо прокатывал просто, а теперь если все хотят пользоваться безлимитом безлимитно то видимо уже не пролезает и приходится вертеться. могут же канал ограничивать на устройство, например, а не доп. деньги списывать, это как раз ближе к примеру с трубой фиксированного размера.
Аналогия такая себе, потому что если эти 4 живут в отдельных квартирах, то в целом потребляют они +- столько же, сколько живя вместе. И денег платят столько же. В этом и суть оплаты по счетчику.
Если у вас команда из одного разработчика - нужен ли ей тимлид? Разработчик не должен оценивать задачу в одно лицо, если есть команда, точно также как и должен быть процесс контроля качества (ревью, тесты) и эти процессы не должны быть завязаны на тимлида, т.к. он тоже может захотеть поболеть, в отпуск, уволиться. Иначе это не команда, а просто набор рандомных людей, обобщенных по какому-то признаку.
И если все эти процессы есть, то собрать фидбек на разработчика от коллег можно и не будучи разработчиком. Да, это сложней, чем если сидеть с палкой над каждым лично. Зато эффективней, чем микроменеджмент.
Джуну надо объяснять что и как делать, как это влияет на бизнес и пр. Не может делать без объяснения даже типовые задачи команды, нужен постоянный контроль и корректировка
Мидл уверенно выполняет типовые задачи на потоке, с небольшим контролем и вводными
Сен решает нетиповые задачи + способен контролировать как минимум предыдущих двоих
Все остальное - это в общем, градации и натягивание этого на разные масштабы коллективов и других сов на глобус
Ну, тут есть один момент. Телефон, мыло, логин-пароль - это все хорошо. но вы же не запрашиваете их на каждый запрос, на каждое открытие странички, скачивание ресурса и тд. Поэтому если ваше приложение реализует постоянные обмены с сервером после авторизации - вы наверняка используете что-то из перечисленного в статье. Это первый момент.
Второй момент - номер телефона (особенно в связке с email) - это ПД. Что несколько усложняет честную реализацию такой аутентификации
Для разных грейдов может быть важен разный набор Х, поэтому можем и ответить. + иногда доучиваем\обучаем с нуля по месту. поэтому факт знания Х может быть несущественнен с точки зрения собеседовать или нет, но как имеющийся навык может выделить человека среди других кандидатов
Ну "не узнаете нового" и "не будет сюрпризов" - это все-таки немного разные утверждения, не находите? Резюме может быть банально недостаточно детальным, человек не указал там например, что работает с Х, а нам это может быть важно и мы спросим (и окажется он умеет).
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Вот эту мысль, честно говоря, не понял совсем. Следует ли из этого, что собеседование как этап избыточно, если есть другой (доверенный) источник, подтверждающий достоверность резюме?
Я лично кучу раз узнавал на собеседовании гораздо больше, чем заявлено в резюме
Чтобы получить доступ к исходникам, не обязательно что-то взламывать. Я вот, слава богу, на каждой работе, где был, мог выполнять свои трудовые обязанности без таких выкрутасов :D
Вы как-то выдергиваете цитату из контекста (в т.ч. контекста статьи). Малина была порекомендована в контексте описанного в статье, а именно с точки зрения безопасности и контроля над устройством как альтернатива (разновидность) этой же внешней приставки.
Я, вроде, нигде не рекомендовал ПК. приставка - это android tv или прочее подобное. По сути тот же смарт ТВ, но во внешнем от телевизора исполнении. DLNA - это конечно хорошо, но по сравнению с полноценным медиа-клиентом типа плекса или jellyfin - ни в какое сравнение
продажа [реализация] товара: Передача покупателю товаров на определенных условиях, в том числе по договору купли-продажи или иным аналогичным договорам.
т.е. даже там это два разных определения. потому что при торговле (как услуги) помимо продажи товара могут быть осущствлены другие действия (оказаны другие услуги) - например доставка, примерка, возврат товара и пр.
ну и не забываем, что это некий ГОСТ, применимость которого под вопросом, а не гражданский кодекс, который обязателен к применению
Ну вообще, я пытался развить мысль про две кассы (ручную платную и автоматическую бесплатную).
не это может быть должным образом оформлено, да, но вас должны об этом заранее уведомить, что оплачивая товар на этой кассе вам надо будет оплатить услугу. и у вас всегда должен быть альтернативный способ заключить договор купли-продажи без дополнительных расходов по цене, указанной на ценнике. пока это условие соблюдается - вам хоть вип зал могут сделать за денюжку, чтобы вы ожидали свою покупку в комфорте.
но повторюсь, чаще всего кассир - это легаси прибор по работе с наличкой, т.к. все эти умные автоматы ее не принимают. а наличку у нас принимать обязаны (типовые магазины, насколько мне известно, но тут я слабо знаю). и, пока у вас наличка, у вас должен быть способ купить товар по ценнику за наличку -> касса с бесплатным кассиром.
Ну, логично и правильно, да. платная услуга - чек. В этом и есть прямое отличие от услуг продавца лимонада. В общем, пока вы только подкрепляете мою позицию )
ну здесь как раз другая история, там сбер ничего не продавал, а оказывал как раз таки финансовые услуги, ну и очевидно хотел иметь с этого какой-то гешефт, а не оказывать их бесплатно.
Не знаю, что вы хотели сказать этой ссылкой, но большинство современных фреймворков дают этот паттерн из коробки без всяких json-rpc. Фактически в них json-rpc - это второй уровень роутинга (сначала по http пути, а потом уже телу запроса), что только усложняет работу
не, здесь я лишь предложил, как бы (по моему мнению) было бы правильно реализовывать загрузку блобов в парадигме, когда у вас вся экосистема приложения построена вокруг json-rpc
Оказывается, что не всегда можно отвязать, либо надо структурировать (делить на два) API, исходя из протокола, а не бизнес-логики.
Звучит таки как критика протокола (json-rpc)? Потому что для фронта использовать json-rpc действительно не самая хорошая затея, например, и с этим сложно спорить, там куча аргументов против.
почему, дать ORMке явное указание подгрузить связи (те же ленивые например) - вполне себе частый юзкейс джоинов. просто там не надо писать ни условие, ни сущности, просто указываешь какую связь заджоинить.
то это все равно изменение условий договора в одностороннем порядке. но раньше оверселлинг видимо прокатывал просто, а теперь если все хотят пользоваться безлимитом безлимитно то видимо уже не пролезает и приходится вертеться. могут же канал ограничивать на устройство, например, а не доп. деньги списывать, это как раз ближе к примеру с трубой фиксированного размера.
Аналогия такая себе, потому что если эти 4 живут в отдельных квартирах, то в целом потребляют они +- столько же, сколько живя вместе. И денег платят столько же. В этом и суть оплаты по счетчику.
Если у вас команда из одного разработчика - нужен ли ей тимлид? Разработчик не должен оценивать задачу в одно лицо, если есть команда, точно также как и должен быть процесс контроля качества (ревью, тесты) и эти процессы не должны быть завязаны на тимлида, т.к. он тоже может захотеть поболеть, в отпуск, уволиться. Иначе это не команда, а просто набор рандомных людей, обобщенных по какому-то признаку.
И если все эти процессы есть, то собрать фидбек на разработчика от коллег можно и не будучи разработчиком. Да, это сложней, чем если сидеть с палкой над каждым лично. Зато эффективней, чем микроменеджмент.
У меня простой критерий, что :
Джуну надо объяснять что и как делать, как это влияет на бизнес и пр. Не может делать без объяснения даже типовые задачи команды, нужен постоянный контроль и корректировка
Мидл уверенно выполняет типовые задачи на потоке, с небольшим контролем и вводными
Сен решает нетиповые задачи + способен контролировать как минимум предыдущих двоих
Все остальное - это в общем, градации и натягивание этого на разные масштабы коллективов и других сов на глобус
Ну, тут есть один момент. Телефон, мыло, логин-пароль - это все хорошо. но вы же не запрашиваете их на каждый запрос, на каждое открытие странички, скачивание ресурса и тд. Поэтому если ваше приложение реализует постоянные обмены с сервером после авторизации - вы наверняка используете что-то из перечисленного в статье. Это первый момент.
Второй момент - номер телефона (особенно в связке с email) - это ПД. Что несколько усложняет честную реализацию такой аутентификации
Для разных грейдов может быть важен разный набор Х, поэтому можем и ответить. + иногда доучиваем\обучаем с нуля по месту. поэтому факт знания Х может быть несущественнен с точки зрения собеседовать или нет, но как имеющийся навык может выделить человека среди других кандидатов
Ну "не узнаете нового" и "не будет сюрпризов" - это все-таки немного разные утверждения, не находите? Резюме может быть банально недостаточно детальным, человек не указал там например, что работает с Х, а нам это может быть важно и мы спросим (и окажется он умеет).
Вот эту мысль, честно говоря, не понял совсем. Следует ли из этого, что собеседование как этап избыточно, если есть другой (доверенный) источник, подтверждающий достоверность резюме?
Я лично кучу раз узнавал на собеседовании гораздо больше, чем заявлено в резюме
Чтобы получить доступ к исходникам, не обязательно что-то взламывать. Я вот, слава богу, на каждой работе, где был, мог выполнять свои трудовые обязанности без таких выкрутасов :D
Вы как-то выдергиваете цитату из контекста (в т.ч. контекста статьи). Малина была порекомендована в контексте описанного в статье, а именно с точки зрения безопасности и контроля над устройством как альтернатива (разновидность) этой же внешней приставки.
Я, вроде, нигде не рекомендовал ПК. приставка - это android tv или прочее подобное. По сути тот же смарт ТВ, но во внешнем от телевизора исполнении. DLNA - это конечно хорошо, но по сравнению с полноценным медиа-клиентом типа плекса или jellyfin - ни в какое сравнение
угу и прямо там же ниже
т.е. даже там это два разных определения. потому что при торговле (как услуги) помимо продажи товара могут быть осущствлены другие действия (оказаны другие услуги) - например доставка, примерка, возврат товара и пр.
ну и не забываем, что это некий ГОСТ, применимость которого под вопросом, а не гражданский кодекс, который обязателен к применению
не это может быть должным образом оформлено, да, но вас должны об этом заранее уведомить, что оплачивая товар на этой кассе вам надо будет оплатить услугу. и у вас всегда должен быть альтернативный способ заключить договор купли-продажи без дополнительных расходов по цене, указанной на ценнике. пока это условие соблюдается - вам хоть вип зал могут сделать за денюжку, чтобы вы ожидали свою покупку в комфорте.
но повторюсь, чаще всего кассир - это легаси прибор по работе с наличкой, т.к. все эти умные автоматы ее не принимают. а наличку у нас принимать обязаны (типовые магазины, насколько мне известно, но тут я слабо знаю). и, пока у вас наличка, у вас должен быть способ купить товар по ценнику за наличку -> касса с бесплатным кассиром.
Ну, логично и правильно, да. платная услуга - чек. В этом и есть прямое отличие от услуг продавца лимонада. В общем, пока вы только подкрепляете мою позицию )
ну здесь как раз другая история, там сбер ничего не продавал, а оказывал как раз таки финансовые услуги, ну и очевидно хотел иметь с этого какой-то гешефт, а не оказывать их бесплатно.
а так, че ж вы дальше не продолжили. есть же еще MAC адреса, роутинг по AS\BGP и прочие приколы на других уровнях
приложение обо всем этом уже обычно не знает
Не знаю, что вы хотели сказать этой ссылкой, но большинство современных фреймворков дают этот паттерн из коробки без всяких json-rpc. Фактически в них json-rpc - это второй уровень роутинга (сначала по http пути, а потом уже телу запроса), что только усложняет работу
не, здесь я лишь предложил, как бы (по моему мнению) было бы правильно реализовывать загрузку блобов в парадигме, когда у вас вся экосистема приложения построена вокруг json-rpc
Звучит таки как критика протокола (json-rpc)? Потому что для фронта использовать json-rpc действительно не самая хорошая затея, например, и с этим сложно спорить, там куча аргументов против.