Пользователь
Всем привет! В этой статье мы хотим поделиться нашим опытом использования полезной платформы Graylog, которая ежедневно помогает собирать, надежно хранить и анализировать логи с десятков серверов, окутанных заботой нашей поддержки :)
Это первая часть статьи, в которой мы расскажем почему выбор пал на Graylog, как его установить и произвести базовую настройку.
Если вы используете Zabbix для мониторинга ваших инфраструктурных объектов, но логи пока не покрыты мониторингом и не собираются в единое хранилище, то эта статья для вас. Расскажем о новом бесплатном анализе логов monq Collector.
Если у вас есть свой бизнес или вы работаете в бизнес-подразделении более-менее крупной компании, особенно на руководящей позиции, вы, скорее всего, сталкивались с заказной разработкой программного обеспечения или столкнетесь с ней, когда захотите улучшить свои результаты. Под заказной разработкой я подразумеваю не только контрактные отношения с подрядной организацией, но ваших собственных штатных IT-шников.
Перед началом разработки, как водится, нужно составить план - ресурсы, сроки, деньги - все как у людей. Вы приходите на встречу с легким сердцем: задача небольшая, нужно всего-то добавить пару форм и отчет, а вы, хоть и не специалист, но понимаете, что это не может быть сложным. Но все меняется, когда разработчики называют сроки.
— Два месяца? На простейший функционал? Это неприемлемо! — вы пытаетесь давить, пугать, просить, торговаться; разработчики явно нервничают, но сроки не двигают. В итоге вы приходите к какому-то компромиссу, который не нравится никому, злые и недовольные.
Мы попробуем разобраться, почему так происходит и откуда берутся эти огромные сроки и оценки. К написанию этой статьи меня подтолкнул недавний кейс: наш диалог с заказчиком дошел, казалось, до абсурда. Причем — уверен — заказчик думал так же. В этой статье я разберу наш реальный кейс и на его примере станет понятно, что стоит за непониманием и конфликтами, с которыми сталкивалось большинство заказчиков. Эта статья — в первую очередь для тех, кто выступает в роли заказчика.
Вчера на Хабре вызвал шумиху пост об ужасных неудобствах Mac. В комментариях много было сказано о неинтуитивности macOS: мол, зачастую без гугления не поймёшь, как что-то сделать. И даже не узнаешь, что это вообще возможно сделать. И всё это значит, что с UX что-то не так.
Тут возникает вопрос «а поняли бы мы Windows без гугления, если бы не были знакомы с ней с детства?» Но я хочу не ввязываться в бесконечные споры «какая ОС лучше» а подойти конструктивнее. Действительно, при переходе с Windows возникает ряд неинтуитивных моментов. И чтобы при этом не приходилось гуглить кучу разных вопросов или читать длиннющие пользовательские руководства, я решил описать в одном тексте самые главные вещи, которые приходят мне в голову.
Надеюсь, кому-то на Хабре это поможет и сделает переход менее болезненным. А если вы сами давно пользуетесь Mac, дополняйте в комментариях, наверняка я что-то ценное упустил.
В этом посте я собираюсь показать вам, как потенциально утроить производительность вашего приложения Node за счет управления несколькими потоками. Это важный учебник, в котором показанные методы и примеры дадут вам все необходимое для настройки эффективного управления потоками.
Доброго времени суток, друзья!
Представляю вашему вниманию руководство по Sequelize.
Sequelize — это ORM (Object-Relational Mapping — объектно-реляционное отображение или преобразование) для работы с такими СУБД (системами управления (реляционными) базами данных, Relational Database Management System, RDBMS), как Postgres, MySQL, MariaDB, SQLite и MSSQL. Это далеко не единственная ORM для работы с названными базами данных (далее — БД), но, на мой взгляд, одна из самых продвинутых и, что называется, "battle tested" (проверенных временем).
ORM хороши тем, что позволяют взаимодействовать с БД на языке приложения (JavaScript), т.е. без использования специально предназначенных для этого языков (SQL). Тем не менее, существуют ситуации, когда запрос к БД легче выполнить с помощью SQL (или можно выполнить только c помощью него). Поэтому перед изучением настоящего руководства рекомендую бросить хотя бы беглый взгляд на SQL. Вот соответствующая шпаргалка.
Это третья и последняя часть руководства, в которой мы поговорим об областях видимости ассоциаций, полиморфных ассоциациях, транзакциях, хуках, интерфейсе запросов, подзапросах, индексах, а также о многом другом.
Я постараюсь быть максимально лаконичным (надеюсь, без ущерба для полноты изложения материала). Я также постараюсь излагать материал максимально простым языком. Большинство примеров, приводимых в руководстве, заимствованы из официальной документации.
Последние пару лет я помогаю клиентам нашего облака внедрять DevOps-практики и делюсь своим опытом инженера DevOps. К сожалению, вопросы про информационную безопасность возникают у клиентов зачастую тогда, когда уже что-то произошло. У меня как у любителя киберзащиты постепенно накопилась целая подборка ИБ-кейсов, которыми хочется поделиться.
В статье собрал правила безопасности контейнеров, о которых часто забывают, но потом снова вспоминают на поучительных примерах.
В экосистеме Node.js существует довольно много библиотек и фреймворков, которые пользуются определенной популярностью в сообществе. Но ни один из инструментов не решил главную проблему, с которой сталкиваются разработчики, когда пытаются писать бэкенд на Node.js. Это проблема выбора архитектуры.
Хочу обратить ваше внимание на относительно молодой фреймворк Nest.js. Из коробки он предлагает заранее предопределенную архитектуру, которая заточена под максимально удобную поддержку и масштабируемость вашего приложения. Заложенные архитектурные подходы проверены временем и давно используются в других, более зрелых платформах: Java(Spring), Python(Django), PHP(Laravel) и прочих.
Авторы Nest.js не скрывают, что их вдохновил один из популярных фреймворков для клиентских приложений — Angular.js, а его авторы ориентировались на походы, используемые в Java и C#. Если вы знакомы с Angular.js, то увидите в Nest.js много схожих идей.
Продолжаем серию публикаций «werf vs...», которая вдохновлена часто задаваемыми вопросами. В первой статье мы объяснили, чем werf отличается от Helm. Теперь черед сравнения с еще более базовой утилитой — Docker.
Нас нередко спрашивают: зачем собирать образы с werf, если уже есть Docker с Dockerfile? Обычно мы отвечаем, что werf — не только про сборку. Утилита участвует в полном цикле CI/CD для доставки приложения в Kubernetes, а Docker при этом тоже используется, но как вспомогательный инструмент. Понятно, что такого объяснения недостаточно, нужны подробности.
Этот материал главным образом для тех, кто мало или совсем не знаком с werf, но знает Docker и хотя бы немного работал с ним. Для начала, как и в случае с Helm, попробуем разобраться, есть ли смысл в противопоставлении двух решений.
Автоматическое распознавание речи (STT или ASR) прошло долгий путь совершенствования и имеет довольно обширную историю. Расхожим мнением является то, что лишь огромные корпорации способны на создание более-менее работающих "общих" решений, которые будут показывать вменяемые метрики качества вне зависимости от источника данных (разные голоса, акценты, домены). Вот несколько основных причин данного заблуждения:
В данной статье мы развеем некоторые заблуждения и попробуем немного приблизить точку "сингулярности" для распознавания речи. А именно:
В этой статье есть 3 основных блока — критика литературы и доступных инструментов, паттерны для проектирования своих решений и результаты нашей модели.
На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):
Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc?
Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.
Привет, Хабр! Как и многие другие, в прошлом году мне пришлось внезапно мигрировать из тесного привычного офиса к себе домой. Я и раньше работал из дома, когда была такая нужда. Но чтобы несколько месяцев подряд — такое со мной случилось впервые. Появилось свободное время, которое я сначала не знал, куда девать. Но потом приспособился, начав изучать вещи, до которых раньше не доходили руки.
Я поковырялся в инвестиционных играх на бирже, познакомился с облачным геймингом, а ещё успел почитать о том, что за зверь такой появился, про который из каждого умного утюга говорят — Kubernetes. Начав с блога Фланта, я убедился, что конкретно мне и конкретно сейчас эта штука не нужна, но выглядит она интересно.
Почитал, одобрил и забыл, да вот только буржуйский Facebook про меня забывать не хотел. И где-то с неделю показывал мне рекламу с самыми наивыгодными предложениями этого самого кубернетиса. В результате я в очередной раз продемонстрировал моральную слабость и решил лично познакомиться с этим зверем.
