Какие я обнаружила сферы применения GPT чата в своей работе:

1. Работа с лексикой:
— подготовка списка слов (wordlist) по уровням языка на основе текста или видео;
— подбор определений к словам на английском языке и примеров, либо переводов на русский язык (далее готовый список можно вставить, например, в Quizlet и получить готовые карточки), форматирование текста;
— создание упражнения с пропущенными словами;
— генерирование текста на основе списка слов;
— подбор синонимов и антонимов к словам из списка.

2. Работа с грамматикой:
— генерирование примеров грамматической структуры;
— создание заданий на раскрытие скобок;
— создание серии упражнений.

3. Проверка домашних заданий и анализ письменных работ (например, эссе).

4. Генерирование вопросов для обсуждения.

5. Создание плана урока или серии уроков.

6. Генерирование картинок по теме для оформления материалов с помощью дружественной GPT чату нейросети DALL-E.

7. Поиск ответов на вопросы студентов и создание материалов для постов в соцсетях.

В этой подборке представлены полезные малоизвестные консольные Linux утилиты. В списке не представлены Pentest утилиты, так как у них есть своя подборка.

Осторожно много скриншотов. Добавил до ката утилиту binenv.

binenv — cамая интересная утилита для установки новых популярных программ в linux, но которых нет в пакетном менеджере.

Дано

• кластер k8s

• много приложений, которые пишут свои логи в stdout/stderr, а контейнерный движок (в данном случае docker) складывает их в файлы

• fluent-bit, запущенный на каждой ноде k8s. Он собирает логи, фильтрует их и отправляет в Loki

• loki - хранилище логов от Grafana Labs

В чём заключается проблема

При просмотре логов через Grafana (источник - Loki) видно, что логи приходят с сильной задержкой или часть логов вообще отсутствует. При просмотре через kubectl logs все логи на месте.

Kubernetes является фактическим лидером среди систем оркестрации. С ростом популярности микросервисной разработки Kubernetes проявил себя незаменимым инструментом для управления крупномасштабными приложениями и их развёртыванием. Правда, с обилием возможностей, которые предоставляет Kubernetes, этой системой подчас непросто управлять.

В этой статье мы заострим внимание на журналах аудита Kubernetes, чтобы записи всех протекающих событий в нашем кластере можно было заполучить по щелчку пальцев.

В данной статье я постарался изложить на что обратить внимание при написании оператора на golang и на нюансы, которые описываются вскользь или вовсе не описываются в официальном туториале или других статьях подобного вида.

Всем привет. Меня зовут Добрый Кот Telegram.

В этой статье расскажем, как развернуть кластер чистыми бинарями и парочкой конфигов.

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

Привет. Меня зовут Григорий Рочев. Хотел бы поделиться сравнением Prometheus like агентами для сбора метрик (нигде я такого определения не встречал, но почему бы их так не назвать?). Рассматривать буду prometheus в режиме agent mode, grafana agent, VictoriaMetrics agent (далее vmagent) и немножко пройдусь по netdata agent.

Привет! Меня зовут Григорий, я техлид в Cloud Infrastructure Team в Сравни. Моя команда отвечает за observability системы и облачную инфраструктуру. Не так давно мы полностью обновили наш стек мониторинга. Хочу рассказать, как у нас организовано хранение long-term метрик без использования Object Storage.

Мы в Сравни долгое время использовали связку Prometheus + Thanos для мониторинга и хранения данных. Для Thanos мы использовали схему с sidecar’ом. Эта схема работала довольно неплохо, но с ростом проекта — росло и потребление ресурсов. Со временем задачи по scrape samples уже потребляли значительные ресурсы. Когда только на Prometheus стало уходить больше 30 ядер vCPU и 100 гигабайт RAM, мы начали искать способы оптимизации потребления ресурсов. 

Первым делом определили требования, которые необходимы для системы мониторинга:
- должно поддерживаться развертывание в Kubernetes;
- система должна быть способна переезжать из одного Kubernetes-кластера в другой без потери данных;
- нужна поддержка downsampling;
- возможность построить high availability систему;
- в идеале, чтобы система требовала очень мало внимания на обслуживание ;)

Мы поизучали варианты, и сперва показалось, что будет хорошей идеей взять стек VMAgent + Thanos receiver. Как несложно угадать из названия статьи, этого у нас не получилось. Недавно я увидел в одном профессиональном чате, что коллеги захотели использовать такой же стек и по тем же причинам, что и мы. Поэтому решил поделиться нашим опытом и рассказать, к чему мы в итоге пришли.

Задачи окружают нас повсюду — и дома, и на работе, и во всяческих аспектах нашей повседневной жизни. У каждого со временем появляются собственные приёмы и методики работы со списками задач. Кто-то предпочитает модные приложения и продвинутые программы, кто-то по старинке всё записывает в бумажный ежедневник. А некоторые вообще не занимаются специальным планированием, но при этом чудесным образом всё успевают.

За долгие годы работы в IT такие методики и принципы выработались и у меня. Например, «Принцип пустого почтового ящика». Или «Принцип постепенного проявления». Они проверены временем и помогают мне успешно ориентироваться в окружающем потоке задач. В этой статье я хочу поделиться с вами этими принципами. Возможно, какие-то из них покажутся вам полезными и пригодятся.

• SBC — нормальный кодек
• У наушников есть свой эквалайзер и пост-процессинг на каждый кодек отдельно
• aptX не настолько хорош, как о нём говорят рекламные анонсы
• LDAC — маркетинговое фуфло
• Качество звука в режиме разговора всё ещё низкое
• В браузер можно встроить аудиоэнкодеры на C, скомпилировав в WebAssembly через emscripten, и они не будут особо тормозить.

Друзья, всем привет! Как известно, в Kubernetes у каждого pod’а есть ограничение на  использование памяти (limits.memory), и, как показывает опыт, далеко не всегда очевидно, как JVM-приложение интерпретирует эту настройку, что порой может приводить к OOMKill.

Вам 20 лет. Вы заканчиваете универ по какой-нибудь прекрасной специальности вроде "Программной инженерии". Вы учитесь на все пятерки, пишете научные статьи, получаете академическую и еще какую-нибудь именную стипендию с крутым названием, ездите по студенческим конференциям и олимпиадам, привозя оттуда призы и охапки мерча. Футболку с последнего чемпионата по программированию вы носите, не снимая (зимой - прямо поверх свитера), и все ваши канцтовары отмечены логотипом Microsoft.

В один прекрасный день научный руководитель предлагает вам остаться в аспирантуре, обещая завидную перспективу. Преподавание с первого же года, стипендия в 10 тысяч, а после защиты надбавка за ученую степень. Ну где еще будешь получать 10 тысяч за научные статьи, думаете вы и...

Всем привет. Как вы все знаете после определенных событий у нас случился ресурсный кризис. И появился запрос на оптимизацию потребляемых ресурсов.

Темой и станет оптимизация потребления ресурсов микросервисов и уменьшение времени выполнения наших запросов.

Можно любить Go за многое: за простоту и строгость, за горутины и каналы, за реализацию параллельного и асинхронного программирования, за продвинутый планировщик, за аллокатор с большим количеством оптимизаций, за высокую производительность.

Но, по сообщениям некоторых пользователей, у программ, написанных на Go, течёт память. Issue-трекер языка Go на github по запросам «high memory usage», «memory leak», «out of memory» выдаёт сотни и тысячи тикетов. А в самом популярном вопросе на stackoverflow по словосочетанию «golang memory» автор пытается разобраться, почему потребление оперативной памяти в рантайме в 4 раза превышает количество реально сделанных аллокаций. Обращения, в которых люди рапортуют о перерасходе оперативной памяти в Go, стали массовым явлением.

Что же это — утечки памяти, вызванные программистскими ошибками, или ожидаемое поведение рантайма языка? Мы попытаемся разобраться в причинах этого явления и сформулировать общие рекомендации, которые помогут в отладке проблем с потреблением памяти.

Часть 1
Часть 2
Часть 3
Часть 4

В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run – нашу собственную программу, которая будет принимать на входе команду (вместе с её аргументами, если таковые имеются) и разворачивать контейнер для её выполнения, изолированный от остальной системы, подобно тому, как вы бы выполнили docker run для запуска из образа.

Всем привет. Меня зовут Добрый Кот Telegram.

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей по сертификатам k8s.

Хочу поделиться с вами некоторым мыслями на тему сертификатов в кубе.

Что спрашивают на собеседовании Golang разработчика? Асинхронщина? Контексты? Вторая часть статьи с вопросами и ответами, собранными на собеседованиях.