Там можно скачать архив буквально для каждого комита. Создавать и хранить их явным образом было бы расточительством.
Проблема в том, что многие используют атрибуты версионирования исходников: теги, хеши комитов и даже названия веток в гите --- в качестве идентификатора сборки или версии дистрибутива.
То, что так делать не стоит, теперь пишут на каждом углу - очевидно, что кроме самих исходников, на результат влияет текущая конфигурация сборочного пайплайна, версии инструментов и т.п.
В случае с архивами, 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, под видом важной и ответственной работы. Спустя год с ними становится интересно разговаривать. В общем, по графику и этапам похоже на армейский онбординг, когда ещё служили два года.
Насколько вообще безопасно пользоваться бесплатными сервисами в интернете. Отформатировать так JSON конечно удобно, или документ преобразовать в нужный вид. У вас есть какие-то политики, для работы с какими данные можно использовать такие инструменты, а для каких - категорически нельзя?
Кто в теме, с ними можно сразу говорить прошлом опыте и разном таком, может что интересное расскажет.
А попался fryer - something (as a young chicken) suitable for frying - перед началом жаркого, но конструктивного разговора, затруднительный вопрос подкорректирует амбиции и подправит самооценку до ниже плинтуса.
Если в ходе собеседования вам покажется, что кандидат чем-то не подходит, то будет вполне легитимный повод отказать (откажете без повода - это дискриминация - может и по судам затаскать). Ну здорово же?
Скорее в части ее трактовок. Почему-то некоторые считают, дескать раз спринты по 2 недели, то в таком скрам-роддоме теперь нужно и детей вынашивать за это же время, а не 9 месяцев как обычно. В результате начинают выдавать если и живых, то сильно недоношенных.
Нет, чтобы релизить каждые 2 недели детей вам нужно не это. А нужен буфер из почти (без двух недель) готовой работы.
Просто разбейте работу на двухнедельные этапы и определите критерии качества в конце каждого из них, чтобы можно было оценить завершенность. Если все в пределах нормы - идете дальше. Если заметите, что-то не так, вы можете скорректировать или прервать и взяться за другое. В этом и состоит гибкость если сравнивать с классическим водопадом.
Проблема в желании вогнать в границы спринта работу на принципиально разных стадиях, устроив команде микроводопад со всеми его недостатками. В начале спринта BA рискуют не успеть наделать задач, а QA в конце - недотестировать.
Сдвиньте декомпозицию и анализ сторей на полспринта до начала нового, а тестирование с релизом на полспринта после - и не будет ни у кого ни каких простоев.
У разработчиков в начале спринта появится время на багфикс и возможность знакомиться новыми задачами, собирая PoC на уровне happy path и обратную связь. QA в это время тестируют результаты предыдущей итерации, и готовят отчёты к релизу. Во второй половине - дев команда доводит код до продакшн состояния, реализуя сценарии отработки сбоев, покрывая юнит тестами. QA вместе с PO и TL прорабатывают сценарии и тесткейсы на следующий спринт.
Думаю параллели стоит проводить не с ЧГК, а с тюремным фольклором - загадками-приколами, - где, как гласит молва, подобные методики отбора ньюкамеров - с каверзными вопросами с порога - применяются десятки, если не сотни, лет. Если там это прижилось, значит тут есть рациональные моменты. По логике вопрос должен быть уже хорошо изучен.
Там можно скачать архив буквально для каждого комита. Создавать и хранить их явным образом было бы расточительством.
Проблема в том, что многие используют атрибуты версионирования исходников: теги, хеши комитов и даже названия веток в гите --- в качестве идентификатора сборки или версии дистрибутива.
То, что так делать не стоит, теперь пишут на каждом углу - очевидно, что кроме самих исходников, на результат влияет текущая конфигурация сборочного пайплайна, версии инструментов и т.п.
В случае с архивами, 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, под видом важной и ответственной работы. Спустя год с ними становится интересно разговаривать. В общем, по графику и этапам похоже на армейский онбординг, когда ещё служили два года.
Прочитал, посмотрел на картинки и задумался:
Может быть в школе для детей пусть лучше уж остаются квадратными? Жизнь на самом деле конечно сложная штука. //sarcasm
Если серьезно, статья просто шедевр. Снимаю шляпу за проделанную работу.
Насколько вообще безопасно пользоваться бесплатными сервисами в интернете. Отформатировать так JSON конечно удобно, или документ преобразовать в нужный вид. У вас есть какие-то политики, для работы с какими данные можно использовать такие инструменты, а для каких - категорически нельзя?
Кто в теме, с ними можно сразу говорить прошлом опыте и разном таком, может что интересное расскажет.
А попался fryer - something (as a young chicken) suitable for frying - перед началом жаркого, но конструктивного разговора, затруднительный вопрос подкорректирует амбиции и подправит самооценку до ниже плинтуса.
Если в ходе собеседования вам покажется, что кандидат чем-то не подходит, то будет вполне легитимный повод отказать (откажете без повода - это дискриминация - может и по судам затаскать). Ну здорово же?
Скорее в части ее трактовок. Почему-то некоторые считают, дескать раз спринты по 2 недели, то в таком скрам-роддоме теперь нужно и детей вынашивать за это же время, а не 9 месяцев как обычно. В результате начинают выдавать если и живых, то сильно недоношенных.
Нет, чтобы релизить каждые 2 недели детей вам нужно не это. А нужен буфер из почти (без двух недель) готовой работы.
Просто разбейте работу на двухнедельные этапы и определите критерии качества в конце каждого из них, чтобы можно было оценить завершенность. Если все в пределах нормы - идете дальше. Если заметите, что-то не так, вы можете скорректировать или прервать и взяться за другое. В этом и состоит гибкость если сравнивать с классическим водопадом.
Проблема в желании вогнать в границы спринта работу на принципиально разных стадиях, устроив команде микроводопад со всеми его недостатками. В начале спринта BA рискуют не успеть наделать задач, а QA в конце - недотестировать.
Сдвиньте декомпозицию и анализ сторей на полспринта до начала нового, а тестирование с релизом на полспринта после - и не будет ни у кого ни каких простоев.
У разработчиков в начале спринта появится время на багфикс и возможность знакомиться новыми задачами, собирая PoC на уровне happy path и обратную связь. QA в это время тестируют результаты предыдущей итерации, и готовят отчёты к релизу. Во второй половине - дев команда доводит код до продакшн состояния, реализуя сценарии отработки сбоев, покрывая юнит тестами. QA вместе с PO и TL прорабатывают сценарии и тесткейсы на следующий спринт.
Думаю параллели стоит проводить не с ЧГК, а с тюремным фольклором - загадками-приколами, - где, как гласит молва, подобные методики отбора ньюкамеров - с каверзными вопросами с порога - применяются десятки, если не сотни, лет. Если там это прижилось, значит тут есть рациональные моменты. По логике вопрос должен быть уже хорошо изучен.
fuzzy это не то же самое, что nondeterministic - в плане логики в ней как раз все довольно четко.