Года 4-е назад на одном проекте был соблазн использовать Pulimni именно из-за поддержки в нем обычных языков программирования. Но потом все же выбор был сделан в пользу Terraform из-за его понятности и близости DevOps инженерам. С Pulimni, к сожалению, все намного сложнее было. Не скажу, как сейчас обстоят дела. Но в компании, где работаю, тоже Terraform. Да и в объявлениях о работе Pulumni упоминается нечасто.
У нас прямо в правилах коммуникации прописано, что никаких приватов с ожиданием ответа в Slack. Пишешь все, что хочешь сказать сразу. И, желательно, одним сообщением. Но даже это не всегда помогает
ИМХО если платеж делается клиентом в режиме реального времени, то решение о повторном запросе лучше предоставить ему самому.
Другое дело, если речь идёт о каких-то повторяющихся платежах. То да, повтор нужно делать. Причем при любом раскладе. Не хватает денег на счету, отправляется уведомление клиенту и повтор через несколько часов или на следующий день.
Ну и ID транзакции слать всегда, о чем автор собирается написать.
Последний метод — Clone, который позволяет забрать что-то из арены обратно в heap даже после удаления. Ведь если обратиться к памяти арены после ее освобождения, данные будут битыми и все сломается.
Имеется ввиду, что забрать в хип можно до освобождения арены и эти данные будут доступны после освобождения арены, так?
При выборе фреймворка для долгоиграющего коммерческого проекта надо смотреть не только на скорость этого самого фреймворка, но и на стратегию развития. Как я вижу, в настоящее время она отлично прописана и исполняется в Laravel, Symfony, CakePHP. У них ясный релиз-цикл, которому они следуют. Плюс смотреть насколько развито и активно коммунити.
А насчет чистого PHP. Работать он будет быстрее конечно. Только вот поддерживать и расширять такое решение еще то удовольствие. И, как показывает практика, все равно скатываются в написание собственного фрейморка. А это чревато большими проблемами в долгосрочной перспективе.
Тут, насколько я понимаю, речь идет не о достоинствах или недостатках конкретного облачного провайдера. А о том, что этот самый провайдер может в какой-то момент заблокировать или вообще удалить Вашу инфраструктуру по каким-то своим соображениям.
Лично я бы даже используя AWS использовал бы Terraform для развертывания инфрастурктуры. CloudFormation и AWS CDK поянтное дело предоставляют больше возможностей. Но с Terraform будет гораздо проще перейти куда-то еще. Плюс Terrafrom позволяет не только с облаками работаеть, но и с сервисом логов Sumo Logic, к примеру, или Grafana.
ИМХО пример так себе. Да и Терраформ для этих целей более подходящий вариант. А вот как поставить необходимый софт на виндовую EC2, к примеру, было бы намного интереснее.
План развития сотрудника может и не коррелироваться с планами проекта, на котором он работает. Может из разрабов он желает расти в админа, или ему QA нравится, или аналитика. А насчет 1 на 1 в точку. В принципе при регулярном их проведении можно и не проводить отдельного перформанс ревью ИМХО
Мы сделали проще. В PR при создании или любом последующем коммите добавляем план, сгенерированный Терраформом. При мерже, идет автоматический apply. Крутится все на self-hosted runners, прибитых к AWS аккаунтам. Так что никаких кредов не нужно.
Года 4-е назад на одном проекте был соблазн использовать Pulimni именно из-за поддержки в нем обычных языков программирования. Но потом все же выбор был сделан в пользу Terraform из-за его понятности и близости DevOps инженерам. С Pulimni, к сожалению, все намного сложнее было. Не скажу, как сейчас обстоят дела. Но в компании, где работаю, тоже Terraform. Да и в объявлениях о работе Pulumni упоминается нечасто.
Чтобы увидеть микроменеджмент данном конкретном случае не нужно было столько времени тратить. В первые пару недель уже должно быть понятно.
Вопрос возникает, почему держат такого начальника при том, что сроки все время срываются и текучка опытных инженеров большая.
То, что намешано - это печально. Очень трудно успевать и там, и там. Так как знания и умения из разных областей. Как уже указывали в комментарии выше
У нас прямо в правилах коммуникации прописано, что никаких приватов с ожиданием ответа в Slack. Пишешь все, что хочешь сказать сразу. И, желательно, одним сообщением. Но даже это не всегда помогает
ИМХО если платеж делается клиентом в режиме реального времени, то решение о повторном запросе лучше предоставить ему самому.
Другое дело, если речь идёт о каких-то повторяющихся платежах. То да, повтор нужно делать. Причем при любом раскладе. Не хватает денег на счету, отправляется уведомление клиенту и повтор через несколько часов или на следующий день.
Ну и ID транзакции слать всегда, о чем автор собирается написать.
В одной крупной известной компании раз в полгода надо проходить Полиграф. И это не оборона или разведка.
Если использовать мультистейжевую сборку, то на последнем этапе, где запускается собранный сервис, слои, созданные на этапе сборки не будут доступны.
Как раз ИИ должен думать и проявлять чувства. То, что сейчас выдаётся за ИИ им ещё не является. Но кто знает, как оно повернется в ближайшем будущем.
Было бы интересно узнать, как сломали Слак Диснея. Убер сломали украденными кредами сотрудника. Сам Слак тут явно не причем
Спасибо за интересную статью!
А можно по-подробнее насчет сжатия?
А что насчёт полного vacuum? Он все также лочит таблицы?
Спасибо за интересную и познавательную статью!
Имеется ввиду, что забрать в хип можно до освобождения арены и эти данные будут доступны после освобождения арены, так?
Отличное выступление на эту тему - https://youtu.be/0UmUgaJwEr0. Там ещё аналогия классная с засыпанием приведена.
При выборе фреймворка для долгоиграющего коммерческого проекта надо смотреть не только на скорость этого самого фреймворка, но и на стратегию развития. Как я вижу, в настоящее время она отлично прописана и исполняется в Laravel, Symfony, CakePHP. У них ясный релиз-цикл, которому они следуют. Плюс смотреть насколько развито и активно коммунити.
А насчет чистого PHP. Работать он будет быстрее конечно. Только вот поддерживать и расширять такое решение еще то удовольствие. И, как показывает практика, все равно скатываются в написание собственного фрейморка. А это чревато большими проблемами в долгосрочной перспективе.
Тут, насколько я понимаю, речь идет не о достоинствах или недостатках конкретного облачного провайдера. А о том, что этот самый провайдер может в какой-то момент заблокировать или вообще удалить Вашу инфраструктуру по каким-то своим соображениям.
Лично я бы даже используя AWS использовал бы Terraform для развертывания инфрастурктуры. CloudFormation и AWS CDK поянтное дело предоставляют больше возможностей. Но с Terraform будет гораздо проще перейти куда-то еще. Плюс Terrafrom позволяет не только с облаками работаеть, но и с сервисом логов Sumo Logic, к примеру, или Grafana.
За статью - спасибо! Познавательно
ИМХО пример так себе. Да и Терраформ для этих целей более подходящий вариант. А вот как поставить необходимый софт на виндовую EC2, к примеру, было бы намного интереснее.
Попадалась статья про VictoriaMetrics. Как она в лучшую сторону отличается от того же Prometheus. Вот думаю попробовать хотя бы в качестве концепта.
Спасибо за развернутый комментарий. Можно немного подробнее про защиту от лазанья в продакшен? Про drift detection уже нагуглил. Спасибо за наводку.
План развития сотрудника может и не коррелироваться с планами проекта, на котором он работает. Может из разрабов он желает расти в админа, или ему QA нравится, или аналитика. А насчет 1 на 1 в точку. В принципе при регулярном их проведении можно и не проводить отдельного перформанс ревью ИМХО
Мы сделали проще. В PR при создании или любом последующем коммите добавляем план, сгенерированный Терраформом. При мерже, идет автоматический apply. Крутится все на self-hosted runners, прибитых к AWS аккаунтам. Так что никаких кредов не нужно.