но если запрещено, то написать код, отреверсив протокол - это тоже нарушение terms of service, так что по идее надо было менять hardware id плашета если делать по закону
а вот если делать свой софт, то единственный способ обойти ограничения - делать как Compaq, когда делал клон IBM PC - писать код на основе знаний полученный в результате знаний после реверс незаконно, это будет "кражей", поэтому они использовали практику "чистой комнаты".
поэтому 1. первая команда провела реверс инжиниринг архитектуры IBM PC и BIOS и написала детальное техническое задание 2. а вторая команда получила техническое задание и по нему уже сделала архитектуру Compaq
я думаю что это плохо, но, к сожалению, про это статья и есть есть два мира, один он очень классный - в нем девопс это философия, в нем вводят метрики оценки состояния трансформации, в нем развивается культура
и есть другой мир, в нем ищут 2 тысячи "девопс-инженеров" "писать пайплайны".
в первом мире все неплохо, статья про то как жить во втором мире :)
этот второй мир пытаются менять, это получается, но пока он есть и в нем рядовому сотруднику тоже как-то приходится жить и вот этим я поделился
в «Челябинске» и «Новосибирске» я выступал, так что можно считать, что это работа :D
а DOES — тут кстати интересно, что онлайновый формат, конечно, снижает ощущение «развлечения» от конференции, то есть получаются такие три дня поглощения информации, учитывая, что человек продуктивен обычно 5-6 часов чистого времени, а тут 8 часов докладов, получается тяжело)
А я ж не говорю что это идеальное решение. Ну и ООП не идеальное, все не идеальное. Просто жить с этим все равно придется. Можно не жить в микросервисах, можно держать инфраструктуру на FreeBSD, вопрос просто в том что:
— для тех, кому надо будет искать работу есть вопрос о том, какие навыки стоит иметь
— для тех, кому надо нанимать, надо понимать какой идеологии будут придерживаться люди и какие навыки, опять же, будут иметь.
Но вообще, это тема другой статьи :)
То что я во вступлении сказал, это скорее про то, что надо понять что это все не временно и надо учиться жить с тем, что породила эта идеология (толерантность к техническому долгу, которая может привести к проблемам в эксплуатации про которые раньше не думали).
Забавно когда коммент, который явно несет в себе дискредитацию начинается с фразы «не сочтите за попытку дискредитировать. Не понимаю, зачем это делать :)
Я хочу ответить на него только этим сообщением, потому что любой другой диалог будет развитием троллинга, который технически начинается с фразы „А я вот видел!“.
>Тяжесть в деньгах работодателя, который будет платить за обучение людей делать то же самое, но по новому.
имхо для новой компании эта проблема будет решена
я считаю что достаточно скоро написать helm/yaml деплоящий аппу в EKS/GKE будет неким базовым навыком разработчика
то есть я совсем не говорю что «технологии изменились, и то, на чем написан софт надо менять», я говорю «технологии изменились и их стоит учить», хотя бы по этим двум не-техническим причинам:
1. старым компаниям соврешенно резонно не менять стек, но — см. booking — рано или поздно на этот стэк станет сложно нанимать людей
2. рано или поздно людям со старым стэком станет сложно наниматься на новый стэк
>А вы расскажите, пожалуйста, какие конкретно проблемы решает ООП, чего в нем такого? Вот богатая стандартная библиотека решает, GC решает, ABI позволяет иметь богатую экосистему, reflection тоже очень сильно помогает. А само ООП, чем нам помогает, кроме того, что мы пишем «obj.method()» вместо «method(obj)»? Наследование, полиморфизм тривиально реализуются в любом вменяемом языке. ОО языки дают удобный синтаксис, но это маргинальное улучшение, по сравнению с упомянутой богатой стандартной библиотекой и прочими вкусностями.
ООП может быть вообще бесполезно. ФП может быть в сто раз лучше. Но проблема в том, что мир в 90-е пошел в ООП. И человек из 80-х отрицающий ООП, потому что «это какой-то новомодный тренд», будет прав, но выпадет из тренда. Я не пропагандирую в статье, что это _правильный_ путь. Но я пропагандирую, что если вы хотите соответствовать текущим технологическим тенденциям — это надо знать.
>K8s это «шедулер» и все, что в нем есть, сделано ради одной задачи — запустить сервис на подходящем свободном сервере.
В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?
>Доходит до истерических примеров. Приложения написанные на golang, и представляющие собой один бинарник упаковывают в докер.
Я согласен, это звучит дико, но мне кажется другого пути уже нет.
Exe-формат действительно не самый лучший формат на свете, я помню споры про него.
Но программистов проще учить «стандарту» и этот стандарт будет уже такой.
Тут хитрый вопрос.
Можно задать этот же вопрос про объектно-ориентированное програмирование, и ответ кстати будет примерно такой же. Зачем нужно ООП?
Чтобы большие команды могли проще создавать сложные многофункциональные приложения.
В 1990-е годы ожидалось что приложение будет выпускаться раз в несколько лет и монолитный ООП подходил, да и в целом — технологии не давали обновлять «части» приложения.
В 2010-е хочется обновлять приложение (оно теперь стоит на сервере) как можно быстрее. Если большая команда будет писать миллион фич в пределах одного приложения — это будет сложно, лучше приложение разделить. Поскольку люди имеют свойство делать глупости и ошибаться — лучше эти отдельные куски приложения сделать вообще отдельными приложениями, пусть каждый работает над своей частью. Эти приложения надо как-то менеджить — появился K8S. Для больших приложений (посмотрите на карту сервисов Netflix) это работает великолепно.
Почему так пишут даже маленькие приложения? Да фиг его поймет почему, можно по другому, но пишут. ООП тоже непонятно зачем для маленьких приложений было, но стало просто стандартом. Так и тут. Противно, в отличие от ООП (которое было до того как многие из нас стали айтишниками) произошло при нас, хочется брюзжать. На ООП, наверняка, также толпа справедливо брюзжала.
Да, хороший подход, нативный, и для прометеуса, и для кликхауса.
Но у нас количество метрик с одного источника — от 4 штук до нескольких сотен, и большая часть индивидуальна для конкретного заказчика.
И поскольку мы тестировали, в первую очередь, для себя и условием было минимум переписывания (а тем более — перепроектирования), то таблицы делали совместимыми с нашей текущей архитектурой с одним столбцом значений.
хотя блин что в личку, здесь наверное тоже интересно будет
вообще, можно отметить что этот набор советов, он в принципе подходит для набора рекомендаций «как сохранить психику в стабильности», что для депрессии, что для тревожности, что для бар итп.
мне вот, глядя на кучу людей (и на свое прошлое) жалко что это в школах не преподают
ну или позже хотя бы
ну или чтобы родители это объясняли, не знаю
чуть чуть есть, попробую тоже выложить)
спасибо вам, очень приятно)
о, классно, что поможет если надо будет, рад)
зависит от terms of service, но в целом да
но если запрещено, то написать код, отреверсив протокол - это тоже нарушение terms of service, так что по идее надо было менять hardware id плашета если делать по закону
а вот если делать свой софт, то единственный способ обойти ограничения - делать как Compaq, когда делал клон IBM PC - писать код на основе знаний полученный в результате знаний после реверс незаконно, это будет "кражей", поэтому они использовали практику "чистой комнаты".
поэтому
1. первая команда провела реверс инжиниринг архитектуры IBM PC и BIOS и написала детальное техническое задание
2. а вторая команда получила техническое задание и по нему уже сделала архитектуру Compaq
боже)) я проверил текст но не проверил заголовок, спасибо!!)
я думаю что это плохо, но, к сожалению, про это статья и есть
есть два мира, один он очень классный - в нем девопс это философия, в нем вводят метрики оценки состояния трансформации, в нем развивается культура
и есть другой мир, в нем ищут 2 тысячи "девопс-инженеров" "писать пайплайны".
в первом мире все неплохо, статья про то как жить во втором мире :)
этот второй мир пытаются менять, это получается, но пока он есть и в нем рядовому сотруднику тоже как-то приходится жить и вот этим я поделился
а DOES — тут кстати интересно, что онлайновый формат, конечно, снижает ощущение «развлечения» от конференции, то есть получаются такие три дня поглощения информации, учитывая, что человек продуктивен обычно 5-6 часов чистого времени, а тут 8 часов докладов, получается тяжело)
— для тех, кому надо будет искать работу есть вопрос о том, какие навыки стоит иметь
— для тех, кому надо нанимать, надо понимать какой идеологии будут придерживаться люди и какие навыки, опять же, будут иметь.
Но вообще, это тема другой статьи :)
То что я во вступлении сказал, это скорее про то, что надо понять что это все не временно и надо учиться жить с тем, что породила эта идеология (толерантность к техническому долгу, которая может привести к проблемам в эксплуатации про которые раньше не думали).
У меня в голове такая аргументация была, но я не мог ее сформулировать.
Я хочу ответить на него только этим сообщением, потому что любой другой диалог будет развитием троллинга, который технически начинается с фразы „А я вот видел!“.
имхо для новой компании эта проблема будет решена
я считаю что достаточно скоро написать helm/yaml деплоящий аппу в EKS/GKE будет неким базовым навыком разработчика
то есть я совсем не говорю что «технологии изменились, и то, на чем написан софт надо менять», я говорю «технологии изменились и их стоит учить», хотя бы по этим двум не-техническим причинам:
1. старым компаниям соврешенно резонно не менять стек, но — см. booking — рано или поздно на этот стэк станет сложно нанимать людей
2. рано или поздно людям со старым стэком станет сложно наниматься на новый стэк
ООП может быть вообще бесполезно. ФП может быть в сто раз лучше. Но проблема в том, что мир в 90-е пошел в ООП. И человек из 80-х отрицающий ООП, потому что «это какой-то новомодный тренд», будет прав, но выпадет из тренда. Я не пропагандирую в статье, что это _правильный_ путь. Но я пропагандирую, что если вы хотите соответствовать текущим технологическим тенденциям — это надо знать.
>K8s это «шедулер» и все, что в нем есть, сделано ради одной задачи — запустить сервис на подходящем свободном сервере.
В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?
Я согласен, это звучит дико, но мне кажется другого пути уже нет.
Exe-формат действительно не самый лучший формат на свете, я помню споры про него.
Но программистов проще учить «стандарту» и этот стандарт будет уже такой.
Можно задать этот же вопрос про объектно-ориентированное програмирование, и ответ кстати будет примерно такой же. Зачем нужно ООП?
Чтобы большие команды могли проще создавать сложные многофункциональные приложения.
В 1990-е годы ожидалось что приложение будет выпускаться раз в несколько лет и монолитный ООП подходил, да и в целом — технологии не давали обновлять «части» приложения.
В 2010-е хочется обновлять приложение (оно теперь стоит на сервере) как можно быстрее. Если большая команда будет писать миллион фич в пределах одного приложения — это будет сложно, лучше приложение разделить. Поскольку люди имеют свойство делать глупости и ошибаться — лучше эти отдельные куски приложения сделать вообще отдельными приложениями, пусть каждый работает над своей частью. Эти приложения надо как-то менеджить — появился K8S. Для больших приложений (посмотрите на карту сервисов Netflix) это работает великолепно.
Почему так пишут даже маленькие приложения? Да фиг его поймет почему, можно по другому, но пишут. ООП тоже непонятно зачем для маленьких приложений было, но стало просто стандартом. Так и тут. Противно, в отличие от ООП (которое было до того как многие из нас стали айтишниками) произошло при нас, хочется брюзжать. На ООП, наверняка, также толпа справедливо брюзжала.
Но у нас количество метрик с одного источника — от 4 штук до нескольких сотен, и большая часть индивидуальна для конкретного заказчика.
И поскольку мы тестировали, в первую очередь, для себя и условием было минимум переписывания (а тем более — перепроектирования), то таблицы делали совместимыми с нашей текущей архитектурой с одним столбцом значений.
вообще, можно отметить что этот набор советов, он в принципе подходит для набора рекомендаций «как сохранить психику в стабильности», что для депрессии, что для тревожности, что для бар итп.
мне вот, глядя на кучу людей (и на свое прошлое) жалко что это в школах не преподают
ну или позже хотя бы
ну или чтобы родители это объясняли, не знаю
Согласен со всем, есть забавная штука, но я про нее в личку приду)