Одной из особенностей Pixel Buds 2a стала возможность заменить аккумулятор в кейс.
Из всех ненужных вещей, кажется самая ненужная но очень хорошо будет продаваться как эко, зеленая забота :) Не знаю что за инфа там у инженеров гугл, но у меня за 2 года у 3 комплектов вышли из строя аккумуляторы - у наушников, не в чехле :D
Я более менее понимаю что такое "Технический писатель". Меня мучало любопытство что такое "техпис", и кто самостоятельно, без принуждения готов себя так называть 😁
Serverless — это модель облачных вычислений, при которой разработчики могут запускать код без необходимости управлять серверами.
Контейнерные среды, приложения запущенные в контейнерах - это serverless, включая Kubernetes, который является лишь решением для облегчения управления этими контейнерами.
А статьи о Serverless, которые говорят только об одном типе serverless, вводят в заблуждение новичков, которые на этих статья обучаются.
Просто хочется напомнить Serviceless !== Functions (lambda). Например в статью можно добавить еще 100500+ вариантов для serverless: AWS ECS, AWS EKS, Google GKE, Google Cloud Run, Azure Container Instances, Azure AKS, Red Hat OpenShift. Ухх много всего.
Читая все эти коменты, про "нерационально", "лучше купить", складывается ощущения что пипл оговаривает себя этим заняться, либо жалуется что сам так не сможет, но вслух. :)
Но ведь основная (или все) DIY проекты это не про это. Это про "отлично провести время".
Да нет же, читать легко и весело, я это в предыдущем комментарии указал.
А хотел сказать я, что топить за то что DevOps не должен писать, а только настраивать, это как утверждать что пекарь не должен тесто замешивать, а должен печь. Я вообще считаю, что девопс не должен ни писать, ни настраивать, а должен с детьми, внуками развлекаться, тусить с семьей и друзьями. Но меня никто не слушает :D
Не эксперт в теме, но "dev" в DevOps, идет от develope, т.е. разрабатывать.
Исследование, проведенное Microsoft, выявило, что title case помогает улучшить читабельность заголовков на 13%, так как заглавные буквы легче воспринимаются глазом.
Остановится, сделать шаг назад, после 10 лет работы и траты кучи ресурсов, разве это не достаточно сложное решение для "нерешительного" человека? Айв и компания, хотела очередную "терку" выпустить, ради галочки в резюме?
Representations переводится как «представление». У клиента есть своё представление о ресурсе. Оно может меняться. Как мы помним из нашего примера, мы могли несколько раз изменять свой заказ. Для этого мы озвучивали свое представление того, как должен выглядеть наш заказ официанту, а тот, в свою очередь, повару.
Насколько я понимаю пример и REST, "мы" озвучивали "состояние" (S из REST) нашего заказа. А представление (R из REST) это немного другое. Использую то же пример, офицант и повар может иметь разные представления одного и тоже ресурса "https://ресторан/повар/заказы/заказ_для_столика_№4", например application/vnd.best.restaurant+waiter и application/vnd.best.restaurant+cook
Запросы офицанта
PUT https://ресторан/повар/заказы/заказ_для_столика_№4
content-type: application/vnd.best.restaurant+waiter
accept: application/vnd.best.restaurant+waiter
{
"первое блюдо": "суп с говядиной",
"горячее": "индейка в сливочном соусе",
"напиток": "лимонный компот"
}
GET https://ресторан/повар/заказы/заказ_для_столика_№4
accept: application/vnd.best.restaurant+waiter
{
"первое блюдо": "суп с говядиной",
"горячее": "индейка в сливочном соусе",
"напиток": "лимонный компот",
"статус": "в прогрессе"
}
Запросы повара (тот же ресурс - УРЛ, но другое представление - более понятное для повара)
GET https://ресторан/повар/заказы/заказ_для_столика_№4
accept: application/vnd.best.restaurant+cook
{
"первое блюдо": {
"название": "суп с говядиной",
"ингридиенты": ["10 грамм говядины", "500 грамм лука"]
},
"горячее": {
"название": "индейка в сливочном соусе",
"ингридиенты": ["индеейка или индеец", "соус по вкусу"]
},
"напиток": {
"название": "лимонный компот",
"ингридиенты": ["растворитель сока, со вкусом лимона", "вода"]
},
"статус": "в прогрессе"
}
Вайб-хакерство какое-то. Вот уж "сокрытие" данных, аналоговнет.
Из всех ненужных вещей, кажется самая ненужная но очень хорошо будет продаваться как эко, зеленая забота :) Не знаю что за инфа там у инженеров гугл, но у меня за 2 года у 3 комплектов вышли из строя аккумуляторы - у наушников, не в чехле :D
Я более менее понимаю что такое "Технический писатель". Меня мучало любопытство что такое "техпис", и кто самостоятельно, без принуждения готов себя так называть 😁
> Я техпис
Я очень далек от UI, от дизайна, но решил прочитать статью. Очень хочется узнать что такое "техпис", и чем он занимается :)
Тут я вслух прокричал "конечно стоит выбрасывать любую идею если она делает синтаксис сложнее"
Никаких допущений.
Контейнерные среды, приложения запущенные в контейнерах - это serverless, включая Kubernetes, который является лишь решением для облегчения управления этими контейнерами.
А статьи о Serverless, которые говорят только об одном типе serverless, вводят в заблуждение новичков, которые на этих статья обучаются.
Просто хочется напомнить Serviceless !== Functions (lambda). Например в статью можно добавить еще 100500+ вариантов для serverless: AWS ECS, AWS EKS, Google GKE, Google Cloud Run, Azure Container Instances, Azure AKS, Red Hat OpenShift. Ухх много всего.
Читая все эти коменты, про "нерационально", "лучше купить", складывается ощущения что пипл оговаривает себя этим заняться, либо жалуется что сам так не сможет, но вслух. :)
Но ведь основная (или все) DIY проекты это не про это. Это про "отлично провести время".
Жду следующей статьи.
можно! подтверждаю!
Да нет же, читать легко и весело, я это в предыдущем комментарии указал.
А хотел сказать я, что топить за то что DevOps не должен писать, а только настраивать, это как утверждать что пекарь не должен тесто замешивать, а должен печь. Я вообще считаю, что девопс не должен ни писать, ни настраивать, а должен с детьми, внуками развлекаться, тусить с семьей и друзьями. Но меня никто не слушает :D
Не эксперт в теме, но "dev" в DevOps, идет от develope, т.е. разрабатывать.
Интересно, весело, занимающее, но много.
Остановился на "Теги: devops разработка observability"
Ответьте пожалуйста кто дочитал, есть ответ на вопрос "Если все будут использовать, откуда они появятся эти сервисы"? Спасибо.
Карма
Я не возмущаюсь автором, я возмущаюсь пропагандой, на хабре.
Автор пропаганды, который упомянул всех "врагов", и "тактично" пропустил 4-е место, просто смешон и противен.
А тебе желаю удачи.
Вы смешны и противны, одновременно.
А мне крупно повезло что я не работаю с GraphQL. И кажеться уже никогда не буду работать.
И все же почему-то Microsoft выбрал sentence title ;)
Чем это читается хуже?
зачем это дважды читать? в коде и еще раз в yaml настройках?
Остановится, сделать шаг назад, после 10 лет работы и траты кучи ресурсов, разве это не достаточно сложное решение для "нерешительного" человека? Айв и компания, хотела очередную "терку" выпустить, ради галочки в резюме?
Насколько я понимаю пример и REST, "мы" озвучивали "состояние" (S из REST) нашего заказа. А представление (R из REST) это немного другое. Использую то же пример, офицант и повар может иметь разные представления одного и тоже ресурса "https://ресторан/повар/заказы/заказ_для_столика_№4", например
application/vnd.best.restaurant+waiterиapplication/vnd.best.restaurant+cookЗапросы офицанта
Запросы повара (тот же ресурс - УРЛ, но другое представление - более понятное для повара)
Где-то я уже такое видел. Зато как красиво продали "runes" :)