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

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

Привет, меня зовут Мария, я Senior UX-copywriter в компании Каруна. Мы — большая компания, поэтому найм людей у нас дело привычное, регулярное и поставленное на рельсы. Мы как-то с HR-департаментом обсуждали этот процесс, и я предположила, что некоторые соискатели могут использовать все прелести технологий для улучшения портфолио, усиления резюме или даже для выполнения тестовых заданий. Так родилась идея эксперимента: смогу ли я только с помощью нейросетей устроиться в Каруну разработчиком? А в UX/UI команду? А графическим дизайнером или SERM/SEO специалистом?

Исходя из 8 лет опыта коммерческой разработки, 3 лет тимлидства, 5 компаний за плечами, могу утверждать: многие соискатели в IT сфере часто после собеседований сидят в ступоре и переваривают события, в частности из-за того, что обескуражены поведением интервьюеров или их неожиданными и странными вопросами. Есть ощущение, что время от времени полезно переосмысливать стандарты проведения техинтервью. В этой статье поделюсь своими наблюдениями о собесах в индустрии веб-разработки: кто проводит, кто на них приходит, почему кто-то остаётся после них недоволен. Рассуждения будут касаться скорее мелких и средне-крупных компаний РФ и ближнего зарубежья, занимающихся веб-разработкой, чем гигантов отрасли, не говоря уже про FAANG.

Среди программистов не утихают споры о том, надо ли знать "алгосики" для реальной работы, или же это просто некий странный ритуал для прохождения воронки собеседований в компании а-ля FAANG (MANGA). У нас в Каруне в разных командах есть разные мнения на этот счёт. Я, например, как тимлид Go-команды считаю, что некую элементарную базу знать точно бы не помешало, но всё же главное, чтоб человек был хороший.

Мнения могут различаться, но одно я знаю точно: разгадывать загадки бывает очень интересно. Я как-то из любопытства прорешивал задачки на hackerrank, и, если для решения простых задач тупо достаточно догадаться отсортировать данные или построить map (даже не надо ничего особо знать), то для некоторых придумать решение довольно проблематично.

Одна из таких задач — нахождение самой длинной общей подпоследовательности (longest common subsequence). Подобный алгоритм используется в реальной жизни, в таких программах как diff. Скажу сразу: я не смог решить задачу самостоятельно за разумное время (т.е. пока не надоело решать) и посмотрел алгоритм в Википедии.

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

Disclaimer: я точно не олимпиадник и не гуру алгоритмов, просто любопытствующий.

Привет, меня зовут Мария, и я senior UX‑писатель в Каруне. По долгу службы писать и придумывать концепции, слоганы, нейминги, интерфейсные тексты мне приходится много и на постоянной основе, поэтому, когда AI стали вполне осязаемыми сервисами, мы все прошли 5 стадий принятия: отрицание («Да не, да что нейросети могут»), гнев («GPT написал за 15 секунд то, что я пишу 2 часа!»), торг («Да это просто краткосрочный тренд, как взлетел, так и исчезнет»), депрессия («AI заберут мою работу»), принятие («Надо попробовать включить его в свою работу»).

И вот на этой точке я начала исследования методом проб и ошибок. Про особенности AI я рассказывать не буду, уже почти каждый причастный (и деепричастный:) написал и проанализировал и плюсы, и минусы. Предлагаю вместе со мной делегировать часть рабочих обязанностей трем различным нейросетям: Chat GPT, Балабоба и Rytr и посмотреть, станет ли мой перфоманс выше и качественнее. Каждый из AI имеет свои особенности, поэтому буду менять их, отталкиваясь от задачи.

Итак, вот мой список дел из расчёта 5/6 часов в день:

Привет, меня зовут Мария, и в этой статье я расскажу о полезных сервисах для генерации нейминга для вашего нового продукта/бренда/приложения/магазина (нужное подчеркнуть), а ещё оценим результат мозгового штурма от ИИ – чата GPT. Померимся креативами, так сказать. :)

Я работаю в Каруне, мы занимаемся созданием и поддержкой разных IT продуктов, поэтому цепляющие имена новых продуктов нам нужны постоянно. Не могу сказать, что у нас есть какая-то отдельная креативная бренд-команда и закрепленный флоу работы, поэтому прежде, чем обобщить наш опыт здесь, я обошла всех причастных и получила полезные лайфхаки, сервисы и общее видение.

Итак, с чего начать, если нужно быстро и круто? Или действовать по старинке руками — качественнее всего? Давайте разбираться.

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

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

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

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

Конечно, рядовым пользователям от использования Jira бывает больно, и это даже порождает целые сайты вроде — https://ifuckinghatejira.com/. Я же попытаюсь рассказать, как жить с Jira без боли хотя бы для бизнеса.

На протяжении последних трёх лет в компании Karuna я помогал масштабировать и адаптировать Jira под растущие потребности.

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

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

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

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

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

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

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

Меня зовут Константин, недавно в Каруне я стал тимлидом и тут я поделюсь причинами, почему не стоит необдуманно падать в управленческую бездну.

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

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

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

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

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

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

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

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

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

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

1. Иметь минимальный функционал эксплорера блокчейна прямо в телеграме: просматривать транзакции и статистику сети.
2. Удобно отслеживать баланс нескольких кошельков и получать уведомления о поступлениях/списаниях с кошелька.
3. Получать актуальную цену + график.
4. Иметь калькулятор доходности майнинга.
5. Иметь кран для активации новых кошельков.

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

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

Кент Бек

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

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

Привет! Меня зовут Ксения Потапова, и я – SMM & Community Team Lead в одном из проектов, над которым работает Каруна. Моя команда занимается развитием брендовых сообществ. Мы выбрали не самый типичный фокус для SMM – это retention. Для нас, безусловно, важно, чтобы аудитория бренда расширялась и знакомилась с ним через каналы,но сделали ключевой задачей социальных сетей удержание и вовлечение текущей клиентской базы ещё до того, как COVID сделал это трендом бизнеса.

Social media  сейчас буквально везде: сделать покупку чего угодно из любой точки мира, заказать услуги и найти специалистов, пройти мастер-класс по игре на укулеле, узнать о марафонах желаний и тут же о них забыть. Пандемия только усилила запросы аудитории на эти площадки и их возможности. В соцсетях сидят более 53% населения всего мира (We are social&Hootsuite report), поэтому свою ЦА в них точно найти сможет любой бизнес.

Вспомните, сколько ваших знакомых стали вести TilTok в первую волну карантина, и как активно в нем стали развиваться бренды? 

Мы в Каруне, как и многие тогда, ушли на удалёнку и прошли все стадии принятия: от онлайн-квизов и кулинарных мастер-классов до Нового года в онлайне. Потом ситуация волнами менялась, мы частично возобновили работы в офисе. И когда поняли, что не можем больше держать в себе, как у нас весело живётся, несмотря ни на что — пошли покорять TikTok. Если вы ещё не знаете, как правильно посвящать новичков в IT-шники, что с ними делается, когда они переходят в Senior-ы и почему спальня в офисе — это прям must have, очень рекомендую посмотреть. 

Привет! Меня зовут Наталья. В Каруне я пишу в команде высоконагруженные сервисы на Elixir.

Это третья компания, в которой я работаю на Elixir. До этого я писала на Ruby. Если посмотреть свежее исследование Хабр Карьеры по зарплатам, можно увидеть — зарплаты рубистов растут, а Elixir там нет. Более того, есть истории о том, как люди возвращались с Elixir обратно на Ruby. Я считаю, что на это сильно влияет вход в язык. Elixir классный, но в первые месяцы знакомства с ним мне самой так не казалось. Настолько классный, что я не хочу назад. В этой статье я расскажу про трудности перевода перехода.

Golang приложение в кластере kubernetes

Привет! Я — golang разработчик в Каруне. Kubernetes сегодня — звезда среди систем оркестровки и контейнеризации приложений. Важно понимать, как с ним работать. Поделюсь примером демонстрационного api приложения, которое написано на golang, и покажу способы взаимодействия с ним.

Всем привет! В прошлом посте мы с вами разобрали механизмы создания библиотек с помощью Angular libs, а также научились настраивать их работу в приложении и друг с другом и даже вынесли наши ассеты в одну из таких библиотек.

В этом посте хочу продолжить тему разделения функционала на библиотеки и, как апофеоз, рассказать о сборке двух, похожих визуально, но разных по функциональности приложений из одного набора библиотек. А так же осветить механизм работы tree shaking при использовании Angular Libs.