Пользователь
YAML (.yml) — популярный язык для конфигурационных файлов, широко используемый DevOps в подходе «Инфраструктура как Код» (IaC). Несмотря на то, что работать с ним бывает проще, чем с тем же JSON (особенно в контексте взаимодействия с большими объемами данных), иногда использовать его бывает трудно. В этой статье мы рассмотрим несколько советов, которые помогут упростить процесс создания и редактирования yml-файлов.
Spring Cloud Config позволяет хранить настройки конфигурации сервисов в git-репозитории и управлять настройками централизованно.
В этой статье поговорим об обновлении параметров, получаемых с сервера конфигурации.
Экономичное отопление. Как утеплить дом и не разориться?
Каждый городской житель мечтает о загородном доме.
Тишина, свежий воздух!
И тут же вы едете смотреть участок земли в превосходном живописном и экологичном месте.
Вопрос стоимости отопления загородного дома‑ это та проблема, которую начинают решать уже ввязавшись в стройку на уже купленном участке земли в живописном месте.
И тут внезапно выясняется, что газа нет!
Что это означает?
Это означает, что у вас в наличии 15 кВт подключенного электричества на все хозяйственные нужды, включая отопление.
15кВт — много это или мало?
Ответ как обычно прячется в самом вопросе, а именно: Смотря для чего?
Ниже приведён проект реального одноэтажного дома. (см.рис.1–2)
Привет, Хабровчане!
JVM работает как хорошо отлаженный механизм, автоматически распределяя и освобождая память. Это и есть суть Garbage Collection. Это процесс, который автоматически находит и удаляет объекты, которые больше не используются вашим приложением. Благодаря этому, разработчики могут сосредоточиться на логике приложения, не беспокоясь о ручном управлении памятью.
Знание того, как работает GC и JVM, необходимо каждому Java-разработчику. Правильное управление ресурсами напрямую влияет на производительность и стабильность приложений.
Это вторая статья из цикла. В первой, вводной, я рассказывал, как устроены метрики для сервисов, чем отличаются от логов, и какую задачу вообще решают. Теперь подробнее про то, как их готовить.
Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.
Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.
В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.
Но есть ещё три других, собственно, не-REST-бэкенда. С ними тоже полезно научиться работать: во-первых, для общего развития, во-вторых, будете знать, как подступаться к их тестированию, на случай, если ваша команда вдруг решит поработать на одном из них.
Под катом — разбор тестирования первого из этой тройки, GraphQL. Все примеры в посте я делал с помощью Postman, он достаточно популярен и доступен, чтобы вы при желании могли всё быстро в нём повторить.
Привет! Продолжаем цикл статей про тестирование не-REST-бэкенда, в прошлый раз мы говорили о GraphQL, теперь пришло время WebSocket.
Итак, что такое WebSocket?
Википедия сообщает, что это «протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером, использующий постоянное соединение».
Что тут важно — что это протокол (со всеми вытекающими последствиями для протокола), который использует постоянное соединение.
Работу по WebSocket в обычной жизни можно представить примерно так.
Вы живете в квартире вместе с семьей, решили поработать, ушли в отдельную комнату и закрыли за собой звуконепроницаемую дверь (ну а как еще работать-то). В общем, сидите, работаете, и вообще не слышите происходящего в квартире. Заметите только, если вам кто-то постучить в дверь.
И тут к вам в дверь стучит, скажем, жена, вы открываете, и она говорит, что ей надо уехать по делам вместе с остальными членами семьи, вы в доме за старшего, и надо будет встретить курьера, который скоро приедет.
ОК, что вам делать в такой ситуации?
Всем привет! В последнее время я вплотную занимаюсь исследованием возможностей systemd и решил поделиться результатом исследований с сообществом, в виде небольшого (или большого, как пойдёт ;-) цикла статей. Итак первым номером нашей программы будет запуск юнитов по различным событиям происходящим во время работы ОС. В качестве исследовательской платформы будет выступать Manjaro Linux c systemd v247.2. И... да. Некоторые события, вынудили меня написать внеочередную статью, которая «взлетела на вершину хит-парада», а опрос показал, что тема актуальна и вызывает интерес, так что погнали!
Про когнитивные искажения много пишут и много говорят.
Однако всегда не хватало более чёткого понимания, как именно это влияет на профессиональную деятельность, мою и моих коллег. Какие решения я как тимлид и программист принимаю неправильно. Что мне подправить, на что обратить внимание.
Поэтому я решил взять справочник когнитивных искажений и поискать примеры из реальной IT-жизни по каждому пункту.
Если вам интересно, добро пожаловать под кат.
Ладно, по каждому пункту — это я погорячился, так как я нашел аж 176 видов искажений. Поэтому выберу рандомно лишь некоторые из них.
LDAP, или Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения и получения данных из каталога с иерархической структурой. Обычно используемый для хранения информации об организации, ее активах и пользователях, LDAP является гибким решением для определения любого типа сущностей и их свойств.
Для многих пользователей LDAP может показаться сложным для понимания, поскольку он опирается на своеобразную терминологию, имеет иногда необычные сокращения, и часто используется как компонент более крупной системы, состоящей из взаимодействующих частей. В этом тексте мы познакомим вас с некоторыми основами LDAP, чтобы у вас была хорошая основа для работы с технологией.
Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 25 лет работы с разными СУБД, в том числе, которую создавал своими руками. Не так много даже опытных программистов и архитекторов, которые знают все термины, технологии, какие подводные камни и куда идёт движение. Тема поистине огромная, поэтому в рамках одной статьи не раскрыть даже верхний уровень информации. Если кто-то не встретит свою любимую СУБД или её невероятный плюс, который стоит упомянуть, то прошу в комментариях указать и этим дополнить общую картину, что поможет другим разобраться и понять лучше предметную область. Поехали!
Open Source DBMS vs Commercial DBMS
Для начала приведён график с сайта, db-engines.com, по моим ощущениям, неплохо отслеживающим тренды БД. Именно этот график добавил желания написать статью о текущем положении дел.
Какое-то время назад на Хабре была небольшая волна постов на тему «Почему я [не] выбрал Linux». Как порядочный фанатик я стриггерился, однако решил, что продуктивнее что-нибудь рассказать о своей любимой системе, чем ломать копии в комментариях.
У меня сложилось впечатление, что многие пользователи GNU/Linux слабо представляют, из чего сделана эта операционная система, поэтому утверждают, что она сляпана из попавшихся под руку кусков. В то же время, архитектура большинства дистрибутивов является устоявшейся и регламентируется рядом стандартов, включая стандарт графического окружения freedesktop.org и Linux Standard Base, расширяющий стандарты Unix. Мне при знакомстве с GNU/Linux несколько лет назад для погружения не хватало простой анатомической карты типичного дистрибутива, поэтому я попробую рассказать об этом сам.
