Web
- Саш, админы говорят, что у нас 400 полетели адово. Глянь, в чем проблема.
- Странно… все же было хорошо.
Пару часов спустя...
- Коллеги, и в очередной раз у нас изменены контракты без согласования и оповещения! Это уже не первый случай!
Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.
Волшебный сказ с лубочными картинками.
Далеко ли, близко ли, высоко ли, низко ли, а летает нонче в небе жар-птица павлин из самого из города Муничинска. И где перо она потеряет, там картинки лубочные множатся, да не на бересте, а на бумаге белёной, да все больше с девками грудастымя вида неблагонравного, да воинами суровыми из земель былинных. Вельми старательно те лубки выведены, хотя с перстами иногда и перебор случается. Смотрит народ на картинки те и только губами причмокивает, да крестятся православные на земные чудеса удивляючись.
Старожилам однако ведомо, что не трогала длань человечая тех листов с рисунками странными. Добрый дух вложили создатели в птицу-жар павлина заморского, да размаху не пожалеючи, пожелали чтоб кажнее пёрышко наделилося силою сказочной. Каждый может перо то волшебное подобрать на лугу или в заводи и сдружиться с тем духом загадочным, да с поклоном и с помощью техники рисовать те картинки лубочные
Дисклеймер: Не беспокойтесь. С Wednesday все в порядке. Пострадала только косичка и потом, мы же с вами знаем что это не её кровь.
Сегодня в сообществе ИТ архитекторов, поддерживающих подход “Архитектура как код”, все чаще появляются упоминания о его перспективах выйти на уровень нового индустриального стандарта. Можно было бы сказать, что любое общество должно быть амбициозным и видеть себя в “Центре Вселенной”. Поэтому, не стоит об этом раньше времени статьи написывать. Но важно заметить, что архитекторы облечены ролью и должностью существенно влиять на решения о выборе стека и подходов в крупных компаниях. Поэтому, кажется, важно уже сегодня рассказать, что лежит в основе таких предположений.
Здравствуй, читатель! Этой статьей я не хочу тебя сильно грузить. Не буду рассказывать про то, как устроены нейроны, как проявляются наши эмоции через нейромедиаторы и синапсы, про каждую часть головного мозга в отдельности. Тебя как человека, который сознательно хочет развиваться, не надо утомлять лишней информацией. Поэтому расскажу про главное - алгоритм работы и три мозга (системы) внутри одного. Еще, пожалуй, коснемся того, что такое энергия и как она расходуется при функционировании нашей природной операционной системы.
Теория ограничений (ТОС) — это управленческая методология, предложенная Элияху Голдраттом в 1984 году в его книге «Цель». Она базируется на простом, но мощном принципе: любая система, будь то производство, бизнес‑процесс или команда разработки, всегда ограничена одним или несколькими узкими местами. Эти ограничения или «бутылочные горлышки» сдерживают общую эффективность системы и являются теми ключевыми элементами, которые необходимо обнаружить и устранить для значительных улучшений.
В условиях разработки продуктов, где скорость поставки, качество и удовлетворение клиентов критически важны, применение теории ограничений может привести к существенным улучшениям процессов и результатов. Давайте рассмотрим, как ТОС работает на практике и каким образом она может помочь командам разработки.
Я, Александра Брызгалова — практик, консультант и сертифицированный эксперт по Теории Ограничений. Специализируюсь на том, что обучаю компании и команды принимать решения, приближающие к цели, и помогаю внедрять в управленческие практики теорию ограничений (ТОС). В этой статье расскажу и покажу, какие ошибки мы допускаем, когда формулируем проблемы, и дам практический инструмент, который поможет их избежать. А ещё покажу примеры ошибочных формулировок и более эффективных.
В этой статье на примере JSON-схемы и спецификации OpenAPI рассматривается проектирование метода REST API с пагинацией, предназначенного для запроса данных из БД.
Данный текст преимущественно ориентирован на начинающих системных аналитиков и всех, кто интересуется проектированием IT-систем.
Давненько я не публиковал новостей по развитию инструмента описания архитектуры кодом. А похвастаться есть чем. Сегодня я исправлю свою досадную оплошность.
Из этой статьи вы узнаете о типах требований и рассмотрите пример их оформления, познакомитесь с основными методами их сбора, рассмотрите основные типы диаграмм (Use Case, Sequence, State, Class, ER-diagram, BPMN) и инструменты, используемые при их документировании.
Предыдущая статья: Системный аналитик. Краткий гайд по профессии. Часть 1
SWOT-анализ — метод стратегического планирования. Он представляет собой анализ четырёх групп факторов, которые влияют на компанию/проект: сильные стороны (strengths), слабые стороны (weaknesses), возможности (opportunities) и угрозы (threats).
Cтатья будет полезна разработчикам и инженерам по ИБ, желающим повысить уровень безопасности приложений за счет внедрения проверок, запрещающих вносить в ПО сторонние компоненты с известными уязвимостями.
В статье рассмотрим внедрение CodeScoring Johnny применительно к Azure DevOps Server в процесс анализа запросов на вытягивание (pull requests) для целей композиционного анализа.
При написании этой статьи я вновь пришел к мысли, что каждый ИТ-шник и ИБ-шник должен быть хоть чуточку разработчиком для более эффективного решения своих задач
Привет! Меня зовут Максим Соколов, я — аналитик в команде “Управление доступностью товаров и категорий”. В нашей команде была выделена отдельная подгруппа, которая создавалась специально под новый продукт-фичу для селлеров. Сразу стало понятно, что для реализации нового функционала требуется разработка нового микросервиса. Командой разработки было принято решение интегрироваться по gRPC, но мне до конца не было понятно, почему выбор именно такой. И тут я решил разобраться подробнее!
До этого я занимался анализом доработок по уже существующему функционалу, поэтому не задавался вопросом, почему выбран тот или иной путь реализации API. Но здесь-то всё с нуля, а специалисту, который дебютирует в этом выборе, становится ещё трудней.
Могу сказать, что выбор технологии для проекта — задача непростая, требующая совместного участия разных участников технической команды: аналитик, разработчик, тимлид, архитектор.
На свете много статей про проектирование API, в которых описаны архитектурные стили, протоколы, технологии. Информации — огромное количество, иногда она даже противоречивая, поэтому новичку тяжело подступиться к теме.
В этой статье я хочу дать точку входа для джун/мидл системных аналитиков, которые хотят разобраться в межсервисной интеграции. Мы пройдёмся по HTTP, REST, RPC и gRPC, разберёмся в их значениях. Выясним, почему эти аббревиатуры появляются, когда происходит проектирование API, и попробуем понять, когда и что следует применять.
Также по ходу статьи буду оставлять ссылки на хорошие (по моему мнению) статьи для более глубокого погружения в поднимаемые темы.
Все мы любим ничего не делать работать с хорошо документированным API. С помощью стандартов API Blueprint или Swagger можно получить читаемую машиной и человеком документацию, а значит и инструменты проверки API на основе этой документации.
Apiary предлагает интерактивные инструменты для проверки API вручную, подставляя нужные параметры в формы, генерируемые на основе документации. Но можно извлечь гораздо больше пользы, если API будет проверяться автоматически. Это избавляет от необходимости писать отдельные тесты на каждый интерфейс, но накладывает определенные ограничения на структуру и качество самой документации.
В этом tutorial поговорим о утилите Dredd на примере API от GitHub.
Каждая компания непрерывно производит и хранит кучу данных, и это вызывает множество проблем. Объёмы хранилищ не бесконечны, как и ресурсы железа. Вот только оптимизация обработки и хранения данных не всегда приносит желаемые результаты. Как всё настроить так, чтобы значительно сократить объём занимаемый ими на диске?
У нас получилось! Мы снизили количество данных на диске в 3 раза, при этом ускорив их обработку. И сейчас расскажу как. Меня зовут Александр Маркачев, я Data Engineer команды Голосовой Антифрод в beeline. В статье затронем тему форматов ORC и Parquet, как их правильно использовать и хранить, чтобы всем было хорошо.
Моя полная петиция на грин-карту по программе талантов EB-1A. 557 страниц, 7 критериев, одобрена с первой попытки без RFE. Все мои рассуждения по выбору критериев, подготовке и описанию доказательств, переводам, оформлению и отправке.