У меня немного другая история была, как-то 1.5 года оттимлидил на проекте где 3 ПМа сменилось, причем не с повышением, а с увольнением ПСЖ. Ситуацию они особо не контролировали, но служили неплохим буфером между заказчиком и командой разработки. Когда случались факапы (а случались они постоянно :)), они самоотверженно получали люлей, потому наверное и не выдерживали подолгу… Ну а в целом проект закончился успешно, стал хорошим пунктом в моем CV, и я благодарен этим ребятам за то что спасали мою нервную систему.
Поверьте, еще ни на одном месте работы я не встречался с тем, что качество ценится больше количества
Попробуйте поработать в компании, которая делает свой продукт и руководство которой понимает, что им жить с этим легаси еще не один год. Таких конечно меньше чем тех кто человеко-часы продает, но они есть.
Производительность «копипастера» часто падает до нуля при столкновении с нестандартной задачей/багом и и тогда оценить левел-апы становится очень просто. Один может решить задачу, а другой нет. Вопрос о квалификации и ЗП в такие моменты становится весьма очевидным.
Думаю, потому что мерж там по умолчанию --no-ff и не нужно вспоминать, с какой опцией -d или -D нужно удалять слитые ветки. Ну и в принципе, стандартизированный flow и инструменты для него освобождают мозг для более важных задач.
Хм, у нас RDS с multi-az mirroring, и трижды за последний год случались серьезные факапы с БД в которых failover не спас.
fixed
del
Интересно, а сравнение с AWS Kinesis проводилось?
Так лучше:
JS можно?
вот без eval:
уупс, только с одним разрядом и с положительными работает, сейчас поправлю
прошу прощения, в "кусте" )
Мой первый коммент в этой ветке:
Хорошо бы уметь держать контекст обсуждения в голове во время спора (конечно не в том случае когда хочется потроллить :))
Мы говорим о понятии stateless в контексте REST.
Эта информация не имеет никакого отношения к сессии, любому клиенту с таким запросом при отсутствии объекта вернется 201, а при наличии 200
Этот факт никак не связан с содержимым запроса, не нужно путать идемпотентность и statless
объекты
Так, это вопрос терминологии и понятия stateless в контексте REST
На сервере нет дополнительной информации (отсутствующей в запросе), которая позволила бы ответить на этот запрос как-то иначе.
Если кеширует — это не проблема, если изменяет из-за факта наличия сессии — то не REST
Сессионного вестимо
Модьярорсаг
У меня немного другая история была, как-то 1.5 года оттимлидил на проекте где 3 ПМа сменилось, причем не с повышением, а с увольнением ПСЖ. Ситуацию они особо не контролировали, но служили неплохим буфером между заказчиком и командой разработки. Когда случались факапы (а случались они постоянно :)), они самоотверженно получали люлей, потому наверное и не выдерживали подолгу… Ну а в целом проект закончился успешно, стал хорошим пунктом в моем CV, и я благодарен этим ребятам за то что спасали мою нервную систему.
Попробуйте поработать в компании, которая делает свой продукт и руководство которой понимает, что им жить с этим легаси еще не один год. Таких конечно меньше чем тех кто человеко-часы продает, но они есть.
Производительность «копипастера» часто падает до нуля при столкновении с нестандартной задачей/багом и и тогда оценить левел-апы становится очень просто. Один может решить задачу, а другой нет. Вопрос о квалификации и ЗП в такие моменты становится весьма очевидным.
Думаю, потому что мерж там по умолчанию --no-ff и не нужно вспоминать, с какой опцией -d или -D нужно удалять слитые ветки. Ну и в принципе, стандартизированный flow и инструменты для него освобождают мозг для более важных задач.
Хмм… На Хабре не любят git-flow?