В предыдущей статье “Jira без боли” (ч1, ч2) был небольшой эпизод про интеграции с другими сервисами через инструмент автоматизации n8n (читается как нейтн).

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

https://habr.com/ru/post/699602/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699602

В предыдущей статье я рассказал, как мы наводили порядок в Jira, готовились к масштабированию и переезду всех бизнес команд в этот инструмент, и как после переезда обеспечивали коллег необходимыми инструментами, которых в Jira нет из коробки: шаблонами, чек-листами, инструментами аналитики, WIP лимитами, и прочим.

После этого перед нами появились новые вызовы — многие проблемы бизнеса всё ещё не решались, или решались с помощью откровенных костылей. Поэтому нам предстояло превратить Jira в настоящий звездолёт.

https://habr.com/ru/post/696648/?utm_source=habrahabr&utm_medium=rss&utm_campaign=696648

Найм профессионального программиста — это слишком дорого, да и программирование — совсем не быстрый процесс. А бизнесу всегда нужно "вчера" и желательно бесплатно. Поэтому всё более популярным становится no-code подход: вы не пишете код, а просто, используя кнопки в интерфейсе и мышку, компонуете своё приложение. Звучит красиво. Так можно создать типовое приложение, накидав туда компоненты. Вот пример рекламной статьи no-code системы Bubble, в которой, по сути, говорят, что для стартапа программисты уже не нужны, по крайней мере — на начальном этапе.

Или если у вас есть условный эксель, где вы можете выделить нужные строки и посчитать их сумму, построить график, и т.д. — вам не надо это всё программировать на каком-либо языке. Всё делается в пару кликов. Это тоже no-code.

Но что же будет, если этот подход разовьётся до небес? Можно ли будет его использовать для всё более и более сложных систем? Можно ли выкинуть программистов на улицу?

Вопрос некорректен

https://habr.com/ru/post/681504/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681504

Привет! Меня зовут Мария, и я UX-писатель в IT-компании Karuna. До этого я работала редактором и контент-менеджером в геймдеве и немного в банковской сфере, где впервые начала задумываться о необходимости UX-исследований — проще говоря, проверок продуктовых гипотез.

К большому сожалению, во многих российских компаниях до сих пор нет понимания того, что такое UX/UI, и какие специалисты трудятся в этой сфере, поэтому про проведение исследований вообще нет и речи: выявили целевую аудиторию, разработали фичу по вкусу и интуиции команды, и всё на этом. А после релиза выясняется, что пользователи не хотят идти по тому сценарию, что придумала для них команда. А что хочет юзер? Как та или иная фича решает его проблему? Как в будущем не тратить ресурсы на разработку того, что никого не интересует?

https://habr.com/ru/post/681098/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681098

Если в вашей компании интерфейсные тексты пишет первый освободившийся оператор разработчик/дизайнер/менеджер/HR/доставщик пиццы, и получается не очень, то эта статья для вас.

https://habr.com/ru/post/676490/?utm_source=habrahabr&utm_medium=rss&utm_campaign=676490

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

К счастью, во многих случаях в проекте уже есть какая-нибудь база данных, которую можно использовать для этих целей. СУБД сама управляет блокировками, и многие проблемы решаются сами, "под капотом". Например, если два инстанса попытаются обновить одну и ту же строку в таблице, то эта строка не превратится в кашу. СУБД автоматически возьмет нужный лок, и тот, кто пришёл вторым, просто будет ждать, пока этот лок не будет снят.

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

Для решения подобных проблем в PostgreSQL есть так называемые необязательные блокировки (advisory locks), т.е. локи, которые берутся, исходя из логики приложения, а не автоматики хранения/выдачи данных в БД.

https://habr.com/ru/post/674730/?utm_source=habrahabr&utm_medium=rss&utm_campaign=674730

У любого современного продукта — если он успешен — есть тот момент жизни, когда он из гадкого стартапа вдруг становится вполне себе прекрасным “энтерпрайз монолит платформ систем легаси”. Без тестов, без мониторинга, с highload и, конечно же, уймой родовых травм, вызванных быстрым развитием.

На критическую бизнес логику тесты будут написаны сами, без них никуда. Мониторинг и хайлоад — это курица и яйцо. После того, как у вас появится кто-то один из этой пары, на горизонте появится и второй. А вот все те, казалось бы, “удачные” и “быстрые” решения, заложенные при рождении, придётся исправлять. И если кодовую базу можно спокойно переписать (ну или хотя бы закидать костылями), то вот база данных — это одна сплошная горячая точка. Запросы и миграции, которые легко проходили на момент становления вашего продукта, легко могут сейчас положить прод, потому что ваша база теперь под постоянной нагрузкой, а ещё она неприлично раздулась.

Привет! Меня зовут Константин, и в Каруне я работаю backend-разработчиком. Данная статья — компиляция ряда сложностей, с которыми мы столкнулись, и методик для их решения. Вся проблема громоздких таблиц в том, что они, как визит к стоматологу — неожиданно, дорого, больно и ужасно вариативно.

https://habr.com/ru/post/670388/?utm_source=habrahabr&utm_medium=rss&utm_campaign=670388

В инете полно списков мудрых вдохновляющих цитат. Это всё здорово, но порой скучновато. Представляешь себе, как человек морщит лоб, изо всех сил делает одухотворённое лицо и выдаёт идеальную шедевральную мысль. Скукота.

Мне больше нравится, когда люди, на которых все равняются или идеализируют их идеи, внезапно в каком-то высказывании показывают себя с очень практической или человеческой стороны. Или подсвечивают особенности другой эпохи. После чего в голове наступает некоторое просветление.

Кент Бек

Кент Бек, создатель методологии "Разработка через тестирование" (TDD), как-то написал:

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

(источник)

https://habr.com/ru/post/663906/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663906