Web
В этой статье я поделюсь своим опытом разработки юнит-тестов внутри базы данных под управлением PostgreSQL. А также расскажу, зачем мне потребовалось доработать расширение pgTap.
pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.
Уверен, что читатель, по крайней мере, знаком с техникой разработки через тесты. Поэтому не буду пускаться в описание теории юнит-тестирования. Благо литературы на эту тему более чем достаточно. Тем не менее, чтобы быть понятым, приведу некоторые детали ниже.
Холодная и беспристрастная как лезвие скальпеля опытного хирурга математика доказывает порой крайне неочевидные вещи... В современных веб-приложениях service-layer не нужен?!
Привет, Хабр, это моя первая статья. Меня зовут Константин, я системный инженер в компании ГНИВЦ. Здесь я хотел бы вам рассказать, что такое Envoy и как с его помощью можно упростить жизнь разработчикам и повысить надёжность взаимодействия микросервисов, минуя инфраструктуру для кого-то страшного и непонятного Kubernetes, а используя простой и старомодный Docker. Также эта статья поможет познакомиться с Envoy поближе и узнать, как он шагает в ногу с таким проектом как Istio.
Одна из злободневных тем, которая постоянно вызывает жаркие споры в комментариях — перевод технических текстов, в том числе терминов. Кто-то уверен, что переводить нужно, кто-то резко против, есть и те, кто считает, что оригинальные термины в русском тексте должны быть написаны по-английски.
Независимо от выбранного подхода, сложно поспорить с тем, что переводов плохого качества действительно очень много. Одна из причин заключается в том, что переводящие текст люди — не обязательно переводчики.
Я — переводчик и программист, и написала эту статью для тех, кто пытается разобраться в том, что же такое перевод и как сделать текст более качественным и точным. Здесь в упрощенном виде показан процесс перевода на примере одного из терминов, чтобы у тех, кому интересна такая деятельность, появилась как минимум пища для размышлений. Те же, кто ругает неумелые русскоязычные переводы, прочитав мою статью, смогут ругаться со знанием дела. Или, возможно, поймут, почему переводчик сделал именно такой выбор, и передумают его критиковать.
В современном мире разработка программного обеспечения стала неотъемлемой частью бизнес-процессов, требующей не только высокой производительности, но и надежной защиты от угроз безопасности. В этом контексте DevSecOps выступает как ключевая парадигма, интегрируя принципы безопасности непосредственно в процессы разработки и поставки. Особое внимание уделяется инструментам, способствующим обеспечению безопасности приложений на каждом этапе их жизненного цикла. В данной статье мы сосредоточим взгляд на сочетании двух мощных технологий — Kubernetes и SonarQube, и рассмотрим, как их совместное использование в рамках DevSecOps способствует созданию надежных и безопасных решений.
SonarQube представляет собой мощный инструмент статического анализа кода, который активно внедряется в практики DevSecOps для обеспечения высокого уровня безопасности и качества программного обеспечения. Этот инструмент разработан с целью выявления потенциальных уязвимостей, дефектов кода и проблем производительности на ранних этапах разработки.
Хотя подключение GPT к интерфейсу Gradio кажется тривиальной задачей, у некоторых новичков возникают трудности, поэтому мы максимально подробно расписали весь процесс создания чат-бота.
В статье рассказано, как вам может помочь утка при работе с данными, с OLAP-нагрузкой и как она может плавать в вашем Data Lake. Вы узнаете всё самое важное про DuckDB и сможете попрактиковаться в работе с DuckDB.
Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.
Глава про архитектурные решения сильно нас зацепила, потому что в своей работе мы напрямую столкнулись с описанными в ней проблемами.
Не можете найти концов, почему было принято то или иное решение? Рассказываете коллегам по сто раз одно и то же? Обсуждения в мессенджерах превращаются в срачи на десятки сообщений?
Знакомо? Нам тоже. Но мы смогли победить эти проблемы.
Под катом выжимка из главы и нашего выпуска, а также практический опыт Dodo Engineering, как правильно оформлять и хранить архитектурные решения.
