Чет ору: https://m.habr.com/ru/post/456558/ Кто еще не заклеил камеру бумажкой: все, пора)
Хабр
Сканер портов в личном кабинете Ростелекома
Сегодня я совершенно случайно обнаружил, что личный кабинет Ростелекома занимается совершенно вредоносной деятельностью, а именно, сканирует локальные сервисы на моём компьютере. Так как добиться...
Долго тут вынашивал одну мысль, которой в итоге решил поделиться:
Каждый руководитель в определенный час Ч слышит от инженера что-то типа "ну это не поддерживается в текущей архитектуре, надо это переделать, то перенастроить, тут хранилище жопой сделано и ваще все не по феншую. На все про все надо каких-то пол-года и будет прям конфетка." Дальше обычно идет басня про НФТ а-ля нагрузки держать будем и изменения вноситься будут сами и ваще TTM упадет до 1 дня. На вопросы можно ли это имплементить итеративно и/или распараллелить между несколькими инженерами обычно ответ отрицательный.
Так вот, это не так! Все что разрабатывается дольше того самого человекомесяца отлично бьется отдельные стори. Как минимум на MVP и на все остальное(что уже не маловажно, т.к. позволяет оценить продуктовую ценность, проверить идею и т.д. и т.п.). Более того, все что оценено больше чем в человекомесяц отлично параллелится(только не за неделю до релиза, а сразу). Если не параллелится(вот совсем никак), то тут уже должны возникнуть вопросы к реализуемому дизайну и архитектуре.
Почему же инженер так поступает? Нет, он вам не враг и тоже хочет сделать хороший продукт. Дело в том, что у вас с ним совсем разные консерны. Вы хотите получить больше денег, удержать продукт на плаву, занять рвнок и т.д., а вот он хочет совсем другого: он хочет вносить меньше регрессии, хочет не просыпаться по ночам от звонков pagerduty и, конечно, хочет рассказать за кружечкой что его бенчмарки показали результат в 100500rps. И, конечно же, он хочет быть уверен, что все это будет сделано именно так как он этого хочет, потому что он знает и умеет, а вот остальные -- не факт! И для этого ему надо войти в пресловутое состояние потока и не отвлекаться на другие задачи, тем более, что так будет быстрее и эффективнее.
Мораль сей басни такова: 1. товарищи продуктологи, взаимодействуйте с IT как можно чаще! Доносите до них важность и ценность своей работы. Максимально обосновывайте свои консерны и обозначайте цели, стоящие перед вами как перед командой и кампанией. IT -- это не просто инструмент, это люди, со своим мнением, целями и видением. И очень важно, что бы это видение было консистентным
2. Товарищи инженеры, будет очень здорово, если вы постараетесь влезть в шкуру тех самых аналитиков/менеджеров/CTO, которые ставят вам задачи(тем более, что сейчас очередной виток моды на T-shaped😜)
Каждый руководитель в определенный час Ч слышит от инженера что-то типа "ну это не поддерживается в текущей архитектуре, надо это переделать, то перенастроить, тут хранилище жопой сделано и ваще все не по феншую. На все про все надо каких-то пол-года и будет прям конфетка." Дальше обычно идет басня про НФТ а-ля нагрузки держать будем и изменения вноситься будут сами и ваще TTM упадет до 1 дня. На вопросы можно ли это имплементить итеративно и/или распараллелить между несколькими инженерами обычно ответ отрицательный.
Так вот, это не так! Все что разрабатывается дольше того самого человекомесяца отлично бьется отдельные стори. Как минимум на MVP и на все остальное(что уже не маловажно, т.к. позволяет оценить продуктовую ценность, проверить идею и т.д. и т.п.). Более того, все что оценено больше чем в человекомесяц отлично параллелится(только не за неделю до релиза, а сразу). Если не параллелится(вот совсем никак), то тут уже должны возникнуть вопросы к реализуемому дизайну и архитектуре.
Почему же инженер так поступает? Нет, он вам не враг и тоже хочет сделать хороший продукт. Дело в том, что у вас с ним совсем разные консерны. Вы хотите получить больше денег, удержать продукт на плаву, занять рвнок и т.д., а вот он хочет совсем другого: он хочет вносить меньше регрессии, хочет не просыпаться по ночам от звонков pagerduty и, конечно, хочет рассказать за кружечкой что его бенчмарки показали результат в 100500rps. И, конечно же, он хочет быть уверен, что все это будет сделано именно так как он этого хочет, потому что он знает и умеет, а вот остальные -- не факт! И для этого ему надо войти в пресловутое состояние потока и не отвлекаться на другие задачи, тем более, что так будет быстрее и эффективнее.
Мораль сей басни такова: 1. товарищи продуктологи, взаимодействуйте с IT как можно чаще! Доносите до них важность и ценность своей работы. Максимально обосновывайте свои консерны и обозначайте цели, стоящие перед вами как перед командой и кампанией. IT -- это не просто инструмент, это люди, со своим мнением, целями и видением. И очень важно, что бы это видение было консистентным
2. Товарищи инженеры, будет очень здорово, если вы постараетесь влезть в шкуру тех самых аналитиков/менеджеров/CTO, которые ставят вам задачи(тем более, что сейчас очередной виток моды на T-shaped😜)
Forwarded from Записки админа
📘 И продолжая тему подписок. Чуть больше месяца назад, Red Hat на своём сайте запустили раздел "Enable SysAdmin" - блог для сисадминов с различными статьями разной степени полезности.
Бывалым админам часть материалов там будет и так знакома, а вот тем, кто приходит к тем же devops практикам из разработки (без админской базы), обратить внимание на эти публикации будет полезно.
#линк #напочитать
Бывалым админам часть материалов там будет и так знакома, а вот тем, кто приходит к тем же devops практикам из разработки (без админской базы), обратить внимание на эти публикации будет полезно.
#линк #напочитать
I hate overtime
#hype #cvdriven Пока ничего не происходит займусь некропостингом! Древняя, но всегда актуальная статья, про то что надо задачи решать а не кодить ради кода: https://link.medium.com/K8CxRXxWDV
#cvdriven
Новые технологии -- это всегда хорошо и круто, но, так же, всегда надо понимать область применения и ограничения этих самых технологий(ваш кэп), что бы не заставлять девопсов поднимать кластер кафки ради 100 сообщений/сек.
Новые технологии -- это всегда хорошо и круто, но, так же, всегда надо понимать область применения и ограничения этих самых технологий(ваш кэп), что бы не заставлять девопсов поднимать кластер кафки ради 100 сообщений/сек.
#books
Кстати про кафку: в книжке Гвен Шапиры для юных кафковедов на первых же 50 страницах описаны юз-кейсы и проблема Linkedin, для решения которой кафку, собственно, и придумали...но кого это останавливает, правда?
Кстати про кафку: в книжке Гвен Шапиры для юных кафковедов на первых же 50 страницах описаны юз-кейсы и проблема Linkedin, для решения которой кафку, собственно, и придумали...но кого это останавливает, правда?
Forwarded from CatOps
HashiCode: Terraform remote state backend locking
Awesome article from Daniel Mangum which started a blog post series that his called "HashiCode" where he do deep dives into the source code for HashiCorp tools!
First episode covers everything from
Also, these posts will be a great place to get started if you want to get involved in contributing in the open source community.
#terraform
Awesome article from Daniel Mangum which started a blog post series that his called "HashiCode" where he do deep dives into the source code for HashiCorp tools!
First episode covers everything from
.tfstate files to Go polymorphism patterns, all in search of how Terraform handles locking with the S3 remote state backend.Also, these posts will be a great place to get started if you want to get involved in contributing in the open source community.
#terraform
Как написать самый хреновый софт, который только видел мир. Часть 1
В свое время Хоар назвал изобретение null pointer "ошибкой на миллиард долларов". Может быть и так, но чаще всего NPE -- это просто последствия кривых рук и политики "оттягивания конца". Каждый слышал про fail early, но, почему-то, в боевом коде все предпочитают тянуть до последнего, откладывая или вообще исключая проверку предусловий(описаных тем же самым Хоаром). В результате получается хрупкий код, кидающий NPE отовсюду. Гораздо хуже, если в результате отсутствия проверки предусловий нарушается консистентность данных: допустим, нам надо сохранить профиль пользователя. Профиль состоит из инфы, улетающей в базу, и аватарки, хранящейся в S3. И вот наш замечательный код, естественно без предусловий, сохраняет инфу в базу, а аватарку пользователь не выбрал. И при сохранении в сторадж у нас летит NPE. Хорошо, если мы умышленно сделали аватарку опциональной, но что если нет? В этом случае у нас будет наполовину сохраненный пользователь. И решать такие проблемы придется руками.
Да, пример надуманный, но ситуация страшная. Программирование по контракту и валидация контрактов классов -- единственное что может спасти код от хаоса(если, конечно, вы не любите просыпаться от PagerDuty по ночам)
В свое время Хоар назвал изобретение null pointer "ошибкой на миллиард долларов". Может быть и так, но чаще всего NPE -- это просто последствия кривых рук и политики "оттягивания конца". Каждый слышал про fail early, но, почему-то, в боевом коде все предпочитают тянуть до последнего, откладывая или вообще исключая проверку предусловий(описаных тем же самым Хоаром). В результате получается хрупкий код, кидающий NPE отовсюду. Гораздо хуже, если в результате отсутствия проверки предусловий нарушается консистентность данных: допустим, нам надо сохранить профиль пользователя. Профиль состоит из инфы, улетающей в базу, и аватарки, хранящейся в S3. И вот наш замечательный код, естественно без предусловий, сохраняет инфу в базу, а аватарку пользователь не выбрал. И при сохранении в сторадж у нас летит NPE. Хорошо, если мы умышленно сделали аватарку опциональной, но что если нет? В этом случае у нас будет наполовину сохраненный пользователь. И решать такие проблемы придется руками.
Да, пример надуманный, но ситуация страшная. Программирование по контракту и валидация контрактов классов -- единственное что может спасти код от хаоса(если, конечно, вы не любите просыпаться от PagerDuty по ночам)
#eda
Тут интервью с Udi Dahan'ом(евангелистом CQRS и т.д. и т.п) подъехало: https://www.infoq.com/articles/cloud-transactions-dahan Много всего про messaging, consistency и транзакционность.
Кстати у дядьки крутой блог, стоящий того что бы его упомянули хотя бы из-за http://udidahan.com/2011/04/22/when-to-avoid-cqrs/
Тут интервью с Udi Dahan'ом(евангелистом CQRS и т.д. и т.п) подъехало: https://www.infoq.com/articles/cloud-transactions-dahan Много всего про messaging, consistency и транзакционность.
Кстати у дядьки крутой блог, стоящий того что бы его упомянули хотя бы из-за http://udidahan.com/2011/04/22/when-to-avoid-cqrs/
InfoQ
How Do We Think about Transactions in (Cloud) Messaging Systems? An Interview with Udi Dahan.
Do today's cloud-based messaging services have different transactional support than those that preceded it? If so, what are the implications? In this interview with distributed systems expert Udi Dahan, we explores the question.
Forwarded from CatOps
Chernobyl DevOps: Software Engineering, Disaster Management, and Observability -- статья о том, что DevOps культура может вынести из Чернобыльской трагедии.
+ обсуждение на Reddit. Не конкретно этой статьи, но скорее впечатлений systems engineers от просмотра сериала от HBO
#culture #devops
+ обсуждение на Reddit. Не конкретно этой статьи, но скорее впечатлений systems engineers от просмотра сериала от HBO
#culture #devops
Medium
Chernobyl DevOps: Software Engineering, Disaster Management, and Observability
On August 14, 2003, at 3:41 PM Eastern Daylight Time, nothing happened. One minute later, the lights went out.
Статья от Фланта про гитОпс: https://habr.com/ru/company/flant/blog/456754/ как всегда подробно и с личным опытом)
Хабр
GitOps: сравнение методов Pull и Push
Прим. перев.: В сообществе Kubernetes явную популярность набирает тренд под названием GitOps, в чём мы лично убедились, посетив KubeCon Europe 2019. Этот термин...
Forwarded from AvitoTech
Что мы в Авито знаем о микросервисах?
Рассказывает Вадим Мадисон, руководитель разработки System Platform → http://bit.ly/2ZDqiLS
Пост будет полезен тем, кто ориентирован на создание большой микросервисной архитектуры и тем, кто уже столкнулся с проблемами быстрого роста. Заходите в комментарии поговорить о растущих объемах, сложности и рисках микросервисной архитектуры.
Рассказывает Вадим Мадисон, руководитель разработки System Platform → http://bit.ly/2ZDqiLS
Пост будет полезен тем, кто ориентирован на создание большой микросервисной архитектуры и тем, кто уже столкнулся с проблемами быстрого роста. Заходите в комментарии поговорить о растущих объемах, сложности и рисках микросервисной архитектуры.
#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 2
Из всех мейнстримовых принципов проектирования, мейнстримового SOLID'а, всяких DRYев и прочих GRASP'ов, я наиболее нежные чувства питаю к KISS(keep it simple, stupid) или, по-русски, принципу наименьшего удивления. Как-то коллега сказал: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте", но, тема в том, что все эти изменения входных параметров по ссылке(ну ее кортеж же возвращать?!), передача нескольких значений как разделенных запятыми строк, название переменных в стиле item1, item2 и т.д. заставляют глаза даже психически здорового человека наливаться кровью.
Более того, этот код не сможет опознать даже сам автор через пару недель.
Хз что мотивирует писать такое, но лечится это даже не ударом книжки Макконела по голове, а соблюдением четырех основных правил(два из которых можно забить в линтер):
1. Иммутабельность -- тут все просто. Надо стараться, по возможности, оперировать неизменяемыми объектами и переменными(это касается как кода, так и API, если что! Безумно бесят GET-запросы, которые insert'ы в базу делают)
2. Чистота -- результат функции должен быть детерменирован(т.е. при передаче одних и тех же параметров мы гарантировано получим один и тот же результат). Если это не возможно, то это должно быть понятно из названия функции/метода. Это правило лежит в основе CQS Бертрана Меера.
3. Адекватный нейминг. Тут все ясно, но на всякий случай: из названия должно быть понятно что лежит в переменной, из названия должно быть понятно что делает функция
4. Закон Деметры. Спорная штука, но ИМХО, очень сильно улучшающая читаемость кода, если применять без фанатизма
Понятно, что в начале придется много сил затратить на ревью, холивары с "и так сойдет" и т.д., но результат стоит того
Как написать самый хреновый софт, который только видел мир. Часть 2
Из всех мейнстримовых принципов проектирования, мейнстримового SOLID'а, всяких DRYев и прочих GRASP'ов, я наиболее нежные чувства питаю к KISS(keep it simple, stupid) или, по-русски, принципу наименьшего удивления. Как-то коллега сказал: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте", но, тема в том, что все эти изменения входных параметров по ссылке(ну ее кортеж же возвращать?!), передача нескольких значений как разделенных запятыми строк, название переменных в стиле item1, item2 и т.д. заставляют глаза даже психически здорового человека наливаться кровью.
Более того, этот код не сможет опознать даже сам автор через пару недель.
Хз что мотивирует писать такое, но лечится это даже не ударом книжки Макконела по голове, а соблюдением четырех основных правил(два из которых можно забить в линтер):
1. Иммутабельность -- тут все просто. Надо стараться, по возможности, оперировать неизменяемыми объектами и переменными(это касается как кода, так и API, если что! Безумно бесят GET-запросы, которые insert'ы в базу делают)
2. Чистота -- результат функции должен быть детерменирован(т.е. при передаче одних и тех же параметров мы гарантировано получим один и тот же результат). Если это не возможно, то это должно быть понятно из названия функции/метода. Это правило лежит в основе CQS Бертрана Меера.
3. Адекватный нейминг. Тут все ясно, но на всякий случай: из названия должно быть понятно что лежит в переменной, из названия должно быть понятно что делает функция
4. Закон Деметры. Спорная штука, но ИМХО, очень сильно улучшающая читаемость кода, если применять без фанатизма
Понятно, что в начале придется много сил затратить на ревью, холивары с "и так сойдет" и т.д., но результат стоит того
Wikipedia
Command–query separation
principle that every method should either be a command that performs an action, or a query that returns data to the caller, but not both; asking a question should not change the answer
Котаны, если кто не в курсе, то вчера по всем восточным европам моргал интернет. Причина -- BGP оптимизации, которые просочились "наружу". Естественно, проблема затронула всех провайдеров облачных сервисов, в том числе и CloudFlare.
Меня в данной ситуации удивляет не столько масштаб бедствия(с каждым бывает), сколько поток токсичности со стороны сообщества в сторону Cloudflare. Говно случается! Пару месяцев назад Яндекс.Облако потеряло клиентские виртуалки. За несколько дней до этого Azure уронило DNS. Про фиаско GitLab с Postgres до сих пор все вспоминают. Цимес в том, что аварии неизбежны и все что можно сделать пост-фактум -- это максимально быстро восстановиться и, конечно же, научиться на своих ошибках.
P.S. блейма от Cloudflare в сторону Verizon я тоже не понимаю
P.P.S. вот статья-постмортем от cloudflare про причины аварии: https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
Меня в данной ситуации удивляет не столько масштаб бедствия(с каждым бывает), сколько поток токсичности со стороны сообщества в сторону Cloudflare. Говно случается! Пару месяцев назад Яндекс.Облако потеряло клиентские виртуалки. За несколько дней до этого Azure уронило DNS. Про фиаско GitLab с Postgres до сих пор все вспоминают. Цимес в том, что аварии неизбежны и все что можно сделать пост-фактум -- это максимально быстро восстановиться и, конечно же, научиться на своих ошибках.
P.S. блейма от Cloudflare в сторону Verizon я тоже не понимаю
P.P.S. вот статья-постмортем от cloudflare про причины аварии: https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
The Cloudflare Blog
How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today
Today at 10:30UTC, the Internet had a small heart attack. A small company in Northern Pennsylvania became a preferred path of many Internet routes through Verizon (AS701), a major Internet transit provider.
#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 3
Учитывая современную тенденцию к распределенным архитектурам, кол-во команд разработки в кампании неуклонно растет. А учитывая, что статичность этих команд до сих пор остается влажной мечтой разработчиков, то девелоперу часто приходится вникать и вносить изменения в код, автором которого он не является. Ситуация сильно упрощается, если все команды придерживаются "принципа наименьшего удивления", о котором я писал выше, но, порой и этого бывает не достаточно.
Представьте ситуацию: вы залазите в код сервиса, предположим, написанного на java, а там весь код на венгерской нотации. Пример смешной, а ситуация страшная) Особенно учитывая, что для всех мейнстримовых языков есть уже выработанные конвенции.
Кароч, котаны, есть конвенции, их придумали далеко не лохи и следовать им очень даже стоит(аргументы "я привык" не оч канают, особенно когда ваш венгерский джава код вылезет на собеседовании). Более того, стоит согласовать конвенции(включая кастомные правила) с коллегами и раз и навсегда зашить их в статический анализатор и вуаля! кол-во багла и wtf\сек со стороны коллег резко сократится
Как написать самый хреновый софт, который только видел мир. Часть 3
Учитывая современную тенденцию к распределенным архитектурам, кол-во команд разработки в кампании неуклонно растет. А учитывая, что статичность этих команд до сих пор остается влажной мечтой разработчиков, то девелоперу часто приходится вникать и вносить изменения в код, автором которого он не является. Ситуация сильно упрощается, если все команды придерживаются "принципа наименьшего удивления", о котором я писал выше, но, порой и этого бывает не достаточно.
Представьте ситуацию: вы залазите в код сервиса, предположим, написанного на java, а там весь код на венгерской нотации. Пример смешной, а ситуация страшная) Особенно учитывая, что для всех мейнстримовых языков есть уже выработанные конвенции.
Кароч, котаны, есть конвенции, их придумали далеко не лохи и следовать им очень даже стоит(аргументы "я привык" не оч канают, особенно когда ваш венгерский джава код вылезет на собеседовании). Более того, стоит согласовать конвенции(включая кастомные правила) с коллегами и раз и навсегда зашить их в статический анализатор и вуаля! кол-во багла и wtf\сек со стороны коллег резко сократится
Forwarded from DocOps
Курс по документированию REST API на русском языке.
Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы.
Оригинальный Documenting APIs: A guide for technical writers and engineers — наверное, самый полный и полезный открытый курс по документированию. Он рассчитан на технических писателей, разработчиков и студентов. Для техписателей этот курс — точка входа в документирование кода и API, очень интересную область работы, за которую ещё и неплохо платят. Разработчики из этого курса научатся структурировать информацию и понятно описывать свой код и API.
Читайте переведённый курс по документированию REST API, рекомендуйте его коллегам, ставьте звёзды репозиторию. Шлите пуллреквесты с правками, наконец. :)
Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы.
Оригинальный Documenting APIs: A guide for technical writers and engineers — наверное, самый полный и полезный открытый курс по документированию. Он рассчитан на технических писателей, разработчиков и студентов. Для техписателей этот курс — точка входа в документирование кода и API, очень интересную область работы, за которую ещё и неплохо платят. Разработчики из этого курса научатся структурировать информацию и понятно описывать свой код и API.
Читайте переведённый курс по документированию REST API, рекомендуйте его коллегам, ставьте звёзды репозиторию. Шлите пуллреквесты с правками, наконец. :)