Если посмотреть цифры по 1 и 2 шагу, то получается даже джуны в большей свой части послали это схему. Как я пониманию на прохождение теста согласился только каждый шестой претендент. Еще столько же прошли его.
В полученном чеке содержится вся информация
Нет, не вся. Есть ряд реквизитов чека которые позволяют его однозначно идентифицировать. При этом расширенная информация ОФД оператором может у себя храниться, а может и не храниться. В налоговую же уходят только данные не выходящие за значение тегов описанных в спецификации ФФД. А там довольно небольшой объем данных.
Частичную. Налоговую интересуют только поступившие суммы и используемый режим для автоматического расчета налогов. Поэтому ни состава заказа, ни тем более названия конкретных товаров там нет.
Все на столько плохо в плане полноты инфы, что когда делаешь сверку чеков которые есть в ОФД (и налоговой), то сопоставить их со своими реальными чеками проблематично. На столько, что пришлось ID заказа писать в тег 1086. Ни во что другое его вписать невозможно в принципе.
Далеко не все. Более того, список тегов которые уходят в ОФД довольно небольшой, количество данных в них тоже жестко лимитировано. Потому что они хранятся внутри ФН который имеет ограниченный объем. По крайне мере сейчас ФНС просто интересует контроль финансовых потоков в цепочке поставки товаров. Что бы тратить как можно меньше сил при начислении налогов/сборов/поборов продавцам. И своей цели они добились, собираемость сильно повысилась. Онлайн кассы сейчас можно видеть даже на простых овощных лотках на улице.
Вопросы которые им задают кандидаты типовые. Через Х собесовов в паре с техспецом и последующими консультациями они на базовом уровне уже в курсе и могут вполне адекватно отвечать на вопросы.
А при кролинге от первой к 50-ой переходить удобно? Скролишь и материшься… Потому что при нормально сделанном пейджинге можно ходить как последовательно "назад" и "далее" по страницам, так и задать конкретный номер сразу.
А это можно решить как и в бесконечном скроле кнопкой сверху "появились новые комментарии, показать?" (в ВК так сделано). Я это к тому, что и при пейджинке и при бесконечно скроллинге добавление новых сущностей сдвигает последовательность.
До HTTP/2 это вполне себе было решение на сайтах где большое количество картинок. И даже сейчас бывают применяются эту технику, т.к. задержки на HTTPS все равно в итоге меньше, чем блокирование в ожидании освобождении потока.
Мы же пытаемся улучшить пользовательский опыт, а не писать код ради кода, так? А пользователя мало интересует что внутри, ему нужно что работало. А оно не работает.
Вообразим, что мы едем на авто и оно дергается. Разве нас интересуют оправдания производителя, почему оно так себя ведет? Нет. Мы хотим просто нормально ехать.
До потолка прибыльности на этом рынке. Сами же про это упоминали. При этом когда эта прибыльность владельца перестанет устраивает, он закроет проект и всех уволит несмотря на какую угодность полезность.
А откуда мы на собесе знаем о простоях? Если сервис доступен снаружи, то его можно конечно помониторить. Но это означает, что вы как соискатель целенаправленно метите именно в этом место. Но хорошо. Предположим, что такое место нашлось. Отмониторили. Проблема есть. Что бы реально понять, в чем дело и что нужно исправить придется в проект погрузиться. Еще до приема на работу, а это сложно реализуемое.
Можно конечно просто пообещать снизить простой в 10 раз. Обещать не мешки ворочать. Но вот только пока ты это обещание не выполнишь, ЗП до Х не поднимут, так? А если поднял, но в 9 раз? А еще есть кейс, когда бизнес параметр простоя не интерисует, им заказы подавай. А про простой ни кто не думал вообще, потому что ни кто его не изменял. В общем поле этих вариаций бесконечно. А каждый из них потенциальная мина на которой разработчик подрывается. Не говоря уже о варианте, когда заказчик декларирует надобность в одной, а реально ему нужно другое.
Поэтому нет этой эфимерной "пользы". Есть человек который что-то умеет и может это подкрепить опытом прошлых проектов ("рекомендательное письмо"). И есть вилка которую он хочет. А с другой стороны человек с проблемой и бюджетом. Который хочет это проблемы решить и готов из этого бюджета отломить кусок Х. Где-то на рынке они встречаются и достигают термодинамического равновесия.
Fail2Ban это не фаервол.
Частичную. Налоговую интересуют только поступившие суммы и используемый режим для автоматического расчета налогов. Поэтому ни состава заказа, ни тем более названия конкретных товаров там нет.
Все на столько плохо в плане полноты инфы, что когда делаешь сверку чеков которые есть в ОФД (и налоговой), то сопоставить их со своими реальными чеками проблематично. На столько, что пришлось ID заказа писать в тег 1086. Ни во что другое его вписать невозможно в принципе.
Далеко не все. Более того, список тегов которые уходят в ОФД довольно небольшой, количество данных в них тоже жестко лимитировано. Потому что они хранятся внутри ФН который имеет ограниченный объем. По крайне мере сейчас ФНС просто интересует контроль финансовых потоков в цепочке поставки товаров. Что бы тратить как можно меньше сил при начислении налогов/сборов/поборов продавцам. И своей цели они добились, собираемость сильно повысилась. Онлайн кассы сейчас можно видеть даже на простых овощных лотках на улице.
А у вас разница в ЗП между джуном и синьором в 3 раза? Допустим, условный джун получает на руки 40к, а синьор 120к?
А при кролинге от первой к 50-ой переходить удобно? Скролишь и материшься… Потому что при нормально сделанном пейджинге можно ходить как последовательно "назад" и "далее" по страницам, так и задать конкретный номер сразу.
А это можно решить как и в бесконечном скроле кнопкой сверху "появились новые комментарии, показать?" (в ВК так сделано). Я это к тому, что и при пейджинке и при бесконечно скроллинге добавление новых сущностей сдвигает последовательность.
До HTTP/2 это вполне себе было решение на сайтах где большое количество картинок. И даже сейчас бывают применяются эту технику, т.к. задержки на HTTPS все равно в итоге меньше, чем блокирование в ожидании освобождении потока.
Ну вот у меня есть сомнения, что в 2 часа реально уложиться. Более того. Возникло впечатление, что и сам автор в этот срок не уложился.
Т.е. это не результат прямого замера, так? Это просто предположение, сколько это будет занимать у тех, кто этим начнет пользоваться.
Это давно уже решено запросам на поддомены.
А это прямо ровно засеченное время на реализацию или примерное?
Вообразим, что мы едем на авто и оно дергается. Разве нас интересуют оправдания производителя, почему оно так себя ведет? Нет. Мы хотим просто нормально ехать.
Прошло почти 5 лет. Как этот акум поживает?
Вот мы и пришли к тому, что эфемерной ценности нет. Есть "деньги вперед". А что в итоге получиться покажет только практика реального сотрудничества.
До потолка прибыльности на этом рынке. Сами же про это упоминали. При этом когда эта прибыльность владельца перестанет устраивает, он закроет проект и всех уволит несмотря на какую угодность полезность.
А откуда мы на собесе знаем о простоях? Если сервис доступен снаружи, то его можно конечно помониторить. Но это означает, что вы как соискатель целенаправленно метите именно в этом место. Но хорошо. Предположим, что такое место нашлось. Отмониторили. Проблема есть. Что бы реально понять, в чем дело и что нужно исправить придется в проект погрузиться. Еще до приема на работу, а это сложно реализуемое.
Можно конечно просто пообещать снизить простой в 10 раз. Обещать не мешки ворочать. Но вот только пока ты это обещание не выполнишь, ЗП до Х не поднимут, так? А если поднял, но в 9 раз? А еще есть кейс, когда бизнес параметр простоя не интерисует, им заказы подавай. А про простой ни кто не думал вообще, потому что ни кто его не изменял. В общем поле этих вариаций бесконечно. А каждый из них потенциальная мина на которой разработчик подрывается. Не говоря уже о варианте, когда заказчик декларирует надобность в одной, а реально ему нужно другое.
Поэтому нет этой эфимерной "пользы". Есть человек который что-то умеет и может это подкрепить опытом прошлых проектов ("рекомендательное письмо"). И есть вилка которую он хочет. А с другой стороны человек с проблемой и бюджетом. Который хочет это проблемы решить и готов из этого бюджета отломить кусок Х. Где-то на рынке они встречаются и достигают термодинамического равновесия.