Думаю у каждого свой опыт. Я в детстве катался на Каме - неубиваемый агрегат и каких-то проблем с тормозами не помню. Ну то есть может они и были, но это не воспринималось как проблема. Простая конструкция, прямая посадка, мягкое сиденье - что ещё нужно чтобы погонять с пацанами во дворе? На зиму можно сложить, закинуть в гараж или кладовку, весной только смазать и снова можно кататься.
Через много лет увлёкся ПВД для тех кому за 150, появился GT с Shimano XTR, контактными педалями и гидравликой. Это агрегат совершенно другого класса, для других целей, требующий понимания как это все работает, отдельного ухода и регулировки после каждой покатушки. Ну и если просто прокатиться во дворе, то он ацки неудобный. В последствии отдал детям, они его естественно разломали в первый же день приложившись кассетой о бордюр.
Насколько мне известно, Форвард и так собирают велики из китайских комплектов. "Кама" это скорее что-то ностальгическое из детства, как Гостья из будущего по телику, или мороженое за 20 коп. По-моему нормальный ход, если по дороге не оптимизировали качество изготовления.
Это называется Schema-based Contact Testing. Подход находится выше юнит тестов потому, что использует данные снаружи. Но ниже E2E - их можно выполнять в изоляции локально или на CI - без развертывания приложения и его зависимостей. Удобно, когда у вас много микросервисов со своими релизными циклами и развертывание всего стека в рамках CI невозможно или нецелесообразно. По смыслу это близко к статистикой проверке типов, где Swagger (OpenAPI, AsyncAPI) вступают в роли унифицированной (платформонезависимой) нотации описания интерфейсов.
Возможность сгенерировать Swagger не отменяет подход, когда Swagger пишется вначале руками (API-first approach). В процессе разработки вы можете использовать сгенерированное описание для проверки соответствия реализации исходной спецификации.
Условия, на которых банк оказываем услуги (не обнуляет ваши счета, начисляет проценты по вкладам и так далее) зависели бы от того, как банк фактически обходится с вашими средствами, а не от того, на каких условиях вы заключили с ним контракт (договор, условия обслуживая и т.п.).
Как будто в жизни так не бывает? У меня летом в банке сняли 30 дополнительных $ за swift перевод просто потому, что у них в зависимостях имплементации что-то поменялось.
Ну что-то sh-образное в линуксах обычно идёт из коробки, а остальное нужно ставить отдельно. Не велика проблема на самом деле. Но на практике тут стена из здравого смысла, личных предпочтений, прошлого опыта, когнитивных искажений и корпоративных стандартов.
По результатам патентных воин между айти гигантами в конце нулевых (или около того), линуксы стали получать с миру по нитке права на использование различных патентов, а *bsd - нет.
Корпоративным пользователям, вместе с обожаемой труъ-админами бесплатной операционной системой, достались не иллюзорные риски попасть на патентные отчисления и судебные разбирательства. Поэтому они быстро развернулись в сторону линуксов. А фря превратилась в нишевый продукт для энтузиастов, любителей труъ-свободы или острых ощущений.
Там можно скачать архив буквально для каждого комита. Создавать и хранить их явным образом было бы расточительством.
Проблема в том, что многие используют атрибуты версионирования исходников: теги, хеши комитов и даже названия веток в гите --- в качестве идентификатора сборки или версии дистрибутива.
То, что так делать не стоит, теперь пишут на каждом углу - очевидно, что кроме самих исходников, на результат влияет текущая конфигурация сборочного пайплайна, версии инструментов и т.п.
В случае с архивами, git справедливо пишут, что для данного инструмента они могут гарантировать лишь идентичность содержимого после распаковки, но не самих архивов.
Это типичная проблема API, когда клиенты привязываются к каким-то особенностям, на которые явно ни кто не рассчитывал. Как вариант, решается версионированием API. Но это совсем другие деньги в плане разработки и поддержки, а процесс миграции может растянуться на годы.
PowerShell не часть POSIX (aka Portable Operating System Interface). Поэтому на *nix, коих зоопарк, это весьма нишевая штука, ниша которой понятна одному лишь Майкрософту.
Вакансия на ручное, а требуется автоматизация? Дело в том, что описание вакансии составляется с прицелом на будущее. То есть прямо сейчас, возможно и не требуется писать автоматизированные тесты, но в будущем есть большая вероятность, что такая необходимость появится.
Нужны тестировщики, которые умеют автоматизировать свою работу уже прямо сейчас, пользуетесь готовыми решениями. Там нет задачи автоматизировать все подряд. Чаще это какая-то рутина, связанная с прогоном стабильных регрессионных сценариев, которые они выполняют из раза в раз. Для тестирования Web приложений есть no-code/low-code инструменты, где достаточно понимать программирование буквально на уровне школьной программы.
Поэтому все сводится к удовлетворению потребностей клиента, которые превращаются в деньги.
Я думаю это только верхушка айсберга. Клиент готов платить больше пока потребность не удовлетворена, и ни кто не хочет платить за уже оказанную услугу. Поэтому конечно, для клиентов создаются ситуации, когда они получают удовольствие. Но решение, закрывающее его потребности (в ваших услугах) - вопрос дискуссионный.
Если исходным драйвером, когда клиент обращается в компанию, являются какие то его страдания, то чтобы он потом снова вернулся, ситуация должна повторяться. Поэтому в целом клиент должен страдать, а вы давать ему облегчение, но только на время.
В каких-то случаях страдания создаются естественным путём. Например голод, и вы этим пользуетесь, если продаете еду. В других - их нужно создавать искуственно (иначе клиенты к вам не вернутся). Я не имею ввиду какой-то криминал. Это могут быть механики в играх или соцсетях, создающие у пользователей чувство неудовлетворённости. Например комменты, на которые нужно обязательно ответить последним. =)
Да, согласен. Скорее всего там больше одной причины и разного профита для заинтересованых. Сейчас ещё много беженцев, в т.ч. высококвалифицированных, готовых работать за небольшие деньги. Расчистить места, чтобы через пару месяцев заполнить в разы дешевле, тоже нормальный ход.
Цель компании --- удовлетворять потребности клиента.
Цель компании, как правило, -- зарабатывать деньги. А удоворять или не удаворять клиента это уже прием. У кого-то одни приемы получаются лучше, другие хуже. У кого-то наоборот. Собственно поэтому они там все и собрались в эту компанию, поскольку в одиночку ни у кого не получается - каждому чего-то не хватает.
Выполнимым --- неким неочевидным способом. Проблема на стороне Петрова.
Если смотреть от лица задачи, которая рискует быть не выполненной, то проблема она одна общая у всех участников этого междусобойчика. В вашей трактовке Петров становится крайним. Но это замечание ни как не приближает к решению проблемы, поэтому выглядит так же нелепо, как безапелляционные реплики самого Петрова, которого вы критикуете)
Профессионал знает границы своих возможностей. Любитель узнает их в процессе.
Что для этого делает Петров? Он поступает самым худшим из возможных способов:
Нет, — говорит Петров.
Он не понял задачу. Но вместо того, чтоб начать задавать уточняющие вопросы — он начинает утверждать — что задача неразрешима.
Петров как профессионал, понимающий границы своих собственных возможностей, сразу ответил "нет". Будь он любителем поговорить, то устроил бы процесс с вопросами и познанием. Не понимаю, какие у вас к нему претензии.
Умение выяснять требования и договариваться это вообще говоря отдельный скил. Он может быть развит у специалиста, а может и нет если такая работа не входит в его функции и ему за это не платят.
В The Verge главными причинами увольнений назвали давление инвесторов и ориентацию на показатели доходности в расчёте на одного сотрудника
За то несколько предыдущих лет нанимали, чтобы показать инвесторам рост поголовья сотрудников (head count). Минус 7-10% это возврат к численности, условно, на начало предыдущего года. Пока цифры на уровне чисто гигиенических.
Если предполагать какой то глобальный заговор, там есть момент. Сотрудников увольняют не с пустыми карманами. Компенсации достигают размера окладов за 6 месяцев. У айтишников это порядка 50 тыс. Умножив на 100 тыс уволенных, получается около 5 ярдов долларов. Сами же уволенные, как пишут, довольно быстро находят себе новую работу. Может это такой экстравагантный способ вбросить деньги в локальную экономику из сфер, где их просто излишки, без особых социальных последствий и не включая печатный станок?
Зависит от масштаба проекта. У нас работа джуна первые полгода это в основном ходить и приставать ментору со своими вопросами. Если речь про разработку, то полноценно на этом этапе они загружают лишь CI, пытаясь продраться через SAST и замечания от более опытных ребят на код ревью. Ну и попутно узнают для себя много нового и интересного. Через полгода им уже можно давать разный toil, под видом важной и ответственной работы. Спустя год с ними становится интересно разговаривать. В общем, по графику и этапам похоже на армейский онбординг, когда ещё служили два года.
Думаю у каждого свой опыт. Я в детстве катался на Каме - неубиваемый агрегат и каких-то проблем с тормозами не помню. Ну то есть может они и были, но это не воспринималось как проблема. Простая конструкция, прямая посадка, мягкое сиденье - что ещё нужно чтобы погонять с пацанами во дворе? На зиму можно сложить, закинуть в гараж или кладовку, весной только смазать и снова можно кататься.
Через много лет увлёкся ПВД для тех кому за 150, появился GT с Shimano XTR, контактными педалями и гидравликой. Это агрегат совершенно другого класса, для других целей, требующий понимания как это все работает, отдельного ухода и регулировки после каждой покатушки. Ну и если просто прокатиться во дворе, то он ацки неудобный. В последствии отдал детям, они его естественно разломали в первый же день приложившись кассетой о бордюр.
Насколько мне известно, Форвард и так собирают велики из китайских комплектов. "Кама" это скорее что-то ностальгическое из детства, как Гостья из будущего по телику, или мороженое за 20 коп. По-моему нормальный ход, если по дороге не оптимизировали качество изготовления.
Это называется Schema-based Contact Testing. Подход находится выше юнит тестов потому, что использует данные снаружи. Но ниже E2E - их можно выполнять в изоляции локально или на CI - без развертывания приложения и его зависимостей. Удобно, когда у вас много микросервисов со своими релизными циклами и развертывание всего стека в рамках CI невозможно или нецелесообразно. По смыслу это близко к статистикой проверке типов, где Swagger (OpenAPI, AsyncAPI) вступают в роли унифицированной (платформонезависимой) нотации описания интерфейсов.
Возможность сгенерировать Swagger не отменяет подход, когда Swagger пишется вначале руками (API-first approach). В процессе разработки вы можете использовать сгенерированное описание для проверки соответствия реализации исходной спецификации.
Как будто в жизни так не бывает? У меня летом в банке сняли 30 дополнительных $ за swift перевод просто потому, что у них в зависимостях имплементации что-то поменялось.
Ну что-то sh-образное в линуксах обычно идёт из коробки, а остальное нужно ставить отдельно. Не велика проблема на самом деле. Но на практике тут стена из здравого смысла, личных предпочтений, прошлого опыта, когнитивных искажений и корпоративных стандартов.
По результатам патентных воин между айти гигантами в конце нулевых (или около того), линуксы стали получать с миру по нитке права на использование различных патентов, а *bsd - нет.
Корпоративным пользователям, вместе с обожаемой труъ-админами бесплатной операционной системой, достались не иллюзорные риски попасть на патентные отчисления и судебные разбирательства. Поэтому они быстро развернулись в сторону линуксов. А фря превратилась в нишевый продукт для энтузиастов, любителей труъ-свободы или острых ощущений.
Там можно скачать архив буквально для каждого комита. Создавать и хранить их явным образом было бы расточительством.
Проблема в том, что многие используют атрибуты версионирования исходников: теги, хеши комитов и даже названия веток в гите --- в качестве идентификатора сборки или версии дистрибутива.
То, что так делать не стоит, теперь пишут на каждом углу - очевидно, что кроме самих исходников, на результат влияет текущая конфигурация сборочного пайплайна, версии инструментов и т.п.
В случае с архивами, git справедливо пишут, что для данного инструмента они могут гарантировать лишь идентичность содержимого после распаковки, но не самих архивов.
Это типичная проблема API, когда клиенты привязываются к каким-то особенностям, на которые явно ни кто не рассчитывал. Как вариант, решается версионированием API. Но это совсем другие деньги в плане разработки и поддержки, а процесс миграции может растянуться на годы.
PowerShell не часть POSIX (aka Portable Operating System Interface). Поэтому на *nix, коих зоопарк, это весьма нишевая штука, ниша которой понятна одному лишь Майкрософту.
Нужны тестировщики, которые умеют автоматизировать свою работу уже прямо сейчас, пользуетесь готовыми решениями. Там нет задачи автоматизировать все подряд. Чаще это какая-то рутина, связанная с прогоном стабильных регрессионных сценариев, которые они выполняют из раза в раз. Для тестирования Web приложений есть no-code/low-code инструменты, где достаточно понимать программирование буквально на уровне школьной программы.
5 примеры вообще антипаттерн. В своё время они изгоняли map/reduce в пользу list comprehension где это возможно и добавили правило в pylint.
Я думаю это только верхушка айсберга. Клиент готов платить больше пока потребность не удовлетворена, и ни кто не хочет платить за уже оказанную услугу. Поэтому конечно, для клиентов создаются ситуации, когда они получают удовольствие. Но решение, закрывающее его потребности (в ваших услугах) - вопрос дискуссионный.
Если исходным драйвером, когда клиент обращается в компанию, являются какие то его страдания, то чтобы он потом снова вернулся, ситуация должна повторяться. Поэтому в целом клиент должен страдать, а вы давать ему облегчение, но только на время.
В каких-то случаях страдания создаются естественным путём. Например голод, и вы этим пользуетесь, если продаете еду. В других - их нужно создавать искуственно (иначе клиенты к вам не вернутся). Я не имею ввиду какой-то криминал. Это могут быть механики в играх или соцсетях, создающие у пользователей чувство неудовлетворённости. Например комменты, на которые нужно обязательно ответить последним. =)
Да, согласен. Скорее всего там больше одной причины и разного профита для заинтересованых. Сейчас ещё много беженцев, в т.ч. высококвалифицированных, готовых работать за небольшие деньги. Расчистить места, чтобы через пару месяцев заполнить в разы дешевле, тоже нормальный ход.
Цель компании, как правило, -- зарабатывать деньги. А удоворять или не удаворять клиента это уже прием. У кого-то одни приемы получаются лучше, другие хуже. У кого-то наоборот. Собственно поэтому они там все и собрались в эту компанию, поскольку в одиночку ни у кого не получается - каждому чего-то не хватает.
Если смотреть от лица задачи, которая рискует быть не выполненной, то проблема она одна общая у всех участников этого междусобойчика. В вашей трактовке Петров становится крайним. Но это замечание ни как не приближает к решению проблемы, поэтому выглядит так же нелепо, как безапелляционные реплики самого Петрова, которого вы критикуете)
У каждого есть "свой" клиент с которым удобно работать. Если диалога не получается, не тратьте время и отпустите с миром.
Петров как профессионал, понимающий границы своих собственных возможностей, сразу ответил "нет". Будь он любителем
поговорить, то устроил бы процесс с вопросами и познанием. Не понимаю, какие у вас к нему претензии.Умение выяснять требования и договариваться это вообще говоря отдельный скил. Он может быть развит у специалиста, а может и нет если такая работа не входит в его функции и ему за это не платят.
За то несколько предыдущих лет нанимали, чтобы показать инвесторам рост поголовья сотрудников (head count). Минус 7-10% это возврат к численности, условно, на начало предыдущего года. Пока цифры на уровне чисто гигиенических.
Если предполагать какой то глобальный заговор, там есть момент. Сотрудников увольняют не с пустыми карманами. Компенсации достигают размера окладов за 6 месяцев. У айтишников это порядка 50 тыс. Умножив на 100 тыс уволенных, получается около 5 ярдов долларов. Сами же уволенные, как пишут, довольно быстро находят себе новую работу. Может это такой экстравагантный способ вбросить деньги в локальную экономику из сфер, где их просто излишки, без особых социальных последствий и не включая печатный станок?
Зависит от масштаба проекта. У нас работа джуна первые полгода это в основном ходить и приставать ментору со своими вопросами. Если речь про разработку, то полноценно на этом этапе они загружают лишь CI, пытаясь продраться через SAST и замечания от более опытных ребят на код ревью. Ну и попутно узнают для себя много нового и интересного. Через полгода им уже можно давать разный toil, под видом важной и ответственной работы. Спустя год с ними становится интересно разговаривать. В общем, по графику и этапам похоже на армейский онбординг, когда ещё служили два года.