talismanovIT
СтатистикаВсем привет! Меня зовут Александр и я обожаю IT, Я в этой сфере уже больше 10 лет, прошел путь от младшего разработчика до Тех лида кластера(30 человек), архитектора решений и до руководителя разработки.
- Последний пост
- 9 авг.
- Последнее чтение
- 13 авг.
- Постов за неделю
- 0
- Всего постов
- 26
- Тип
- открытый
- Язык
- русский
- В каталоге с
- 13 авг.
- 1/24сутки в ленте
- 149
- 1/48двое суток
- 170
- 1/72трое суток
- 184
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
#дайджест_новинок_в_разработке #июль_2026 #java #spring #golang #nodejs #csharp #kotlin #react #postgres #kubernetes #k8s #redis #kafka #clickhouse #дайджест Всем привет! Только нашел время, чтобы сделать со своим "помощником" свежий дайджест о новинках в мире разработки за Июль 2026. Собрал только новое, что не указывал ранее в предыдущем посту - https://t.me/talismanovIT/97 Всем хорошего дня! P.S. если есть желание расширить список тем, то пишите в комментариях
📣 Подборка вакансий в ИТ-вертикали ДОМ.PФ и Банка ДОМ.PФ Собрали актуальные позиции — выбирайте свою 👍 🟢ИТ-лидер Java в команду домена B2C. Владеть технической частью продукта end-to-end - от архитектурного видения до продакшна и его поддержки. Отвечать за весь цикл поставки. Вести команду разработчиков. Подключаться к решению сложных задач. 🟢 Владелец продукта в команду ипотечных продуктов. Управлять продуктовым бэклогом: приоритизация, декомпозиция, подготовка задач к разработке. Руководить кросс-функциональной командой полного цикла (около 10 FTE + UX/UI). Определять продуктовые параметры и roadmap с учётом ресурсных ограничений. Улучшать клиентский путь и повышать конверсии на всех этапах воронки. 🟢 Системный аналитик (Внедрение ЦФТ). Анализировать входящие бизнес-требования. Проектировать бизнес-процессы и архитектуру решений по функциональным направлениям: РКО юридических и физических лиц, платежи юридических и физических лиц. Сопровождать реализацию и вывод доработок на всех этапах производства. Обеспечивать технологическую поддержку 3-го уровня. 🔹 Тех в Максе
особенно обратите внимание на ит-лидера(техлида) в b2c. Мои бывшие коллеги и они классные, если чувствуете в себе силы, то кидайте резюмешки на хх.ру
без подписи
без подписи
#java #spring #golang #nodejs #csharp #kotlin #react #postgresql #kubernetes #redis #kafka #clickhouse #dev #дайджест 🚀 Всем привет! Хайп на агентах, домашние дела и загруз на работе приводят к тому, что просто некогда узнавать новое! Работаешь работу и на этом всё, а ведь раньше знал все новшества в новой версии языка программирования или фреймфорка. Подписки на айти блоги порой превращаются в поток информационного мусора, который ты просто перестаешь читать (у меня именно так, я не успею и уже не хочу читать те каналы или новости сайтов, которые читал раньше). Но всё же надо поглядывать, а что же нового в стэке твоей команды и у коллег по цеху. Я запряг "помощника" и собрал: 1) Что нового в мире разработки ПО — дайджест за месяц (июнь–июль 2026) 2) Что нового в разработке ПО за последний год (июль 2025-июль 2026). Оба дайджеста выложу pdf-файлами после поста Этот пост не "контент ради контента" В Первую очередь делаю его для себя, чтобы быть больше "в теме" Поэтому выбрал то, с чем работают мои разработчики на текущем месте или будут в ближайшее время, а именно Java, Spring, Go, Node.js, .NET, Kotlin, React, Postgres, Kubernetes, Redis, Kafka, ClickHouse. Это как раз довольно интересный формат, когда и компиляция некоторых разных вещей в одном месте и есть возможность подглядеть новшества в стэке "соседа". Киллер фичой данной публикации считаю сравнение "ДО" и "ПОСЛЕ" в обзоре нового за последний месяц. P.S. к сожалению за выходные времени нашлось только на первые 100 страниц "Эластика в действии", обзор и свое мнение по первым главам будет позже P.S.S. сделал сначала в powerpoint для наглядности, но идеальный слайд на винде оказался ужасным на телефоне, поэтому, ради читателей с телефона, перевел в pdf. Приятного прочтения и хорошего дня!
Не нашел перевод на русский, но у нас много и читающих на английском. Если сможете закинуть в комментарии русских перевод, то закиньте плиз.🙏🏻
Пора расчехлять! Изучал эластик много раз за последние 3 года по статьям и развлекался с развернутым за меня, сравнивал с другими БД и делал стандарт хранения данных по поручению руководителя архитектуры на прошлом месте работы. Сейчас же нужно помочь ребятам из разработки и затянуть его к нам в инфру (отстоять необходимость перед подразделением инфры и эксплуатации) и провалидировать то, что мы не монстра делаем и не костылим на ровном месте.
#ai #agents #llm Всем привет. Про ИИ-агентов сейчас не пишет только ленивый, слово «agent» лепят на всё подряд, и кажется, что это космическая магия с кучей фреймворков. Разочарую (или обрадую): Агент - это LLM в цикле с инструментами. Всё. Обычный запрос к LLM - «спросил -> получил ответ», один проход. Агент - это когда мы даём модели право самой решать, что делать дальше, и крутим её в цикле, пока она не скажет «я закончила». Составных частей всего 4: 1️⃣ Цикл - крутим модель, пока не остановится. Сколько шагов сделать, решает она, а не ты. 2️⃣ Инструменты - функции, которые мы ей дали: почитать файл, сходить в базу, дёрнуть API. Её руки. 3️⃣ Контекст - системный промпт + история сообщений. Её память в пределах задачи. 4️⃣ Модель - мозг. Главный сдвиг в голове: в обычном коде ты пишешь алгоритм — сделай A, потом B. С агентом ты пишешь не алгоритм, а среду: вот инструменты, вот правила, вот забор — а как решать, модель придумает сама. Весь агент на псевдокоде: loop: ответ = LLM(промпт, история, инструменты) если ответ просит инструмент: результат = выполнить(...) добавить результат в историю иначе: вернуть ответ # модель закончила Серьёзно, всё. Это цикл на 7 строк. Вся соль в одной строчке: результат инструмента кладём обратно в историю и снова спрашиваем модель. Так она сама строит план по ходу дела: посмотреть файлы -> прочитать нужный -> ответить. Мы план не писали — только дали инструменты и отошли. Два забора, без которых получится «vibe-агент», жгущий деньги: 1️⃣ Потолок по шагам — иначе агент уйдёт в бесконечный цикл и спокойно сожжёт бюджет, пока вы спите. 2️⃣ Песочница инструментам — дал «читать файлы», ограничь рабочей папкой, а то модель сходит куда угодно, например за /etc/passwd . Вот и вся магия: цикл, инструменты, контекст, модель. Многие из вас это знали, кто-то сильно раньше меня стартанул в этой теме, но если кому-то было полезно, то буду рад реакциям. Всем спокойной ночи 😉
Всем привет! Хотел поделиться событием, которое далось мне нелегко(несколько бессонных ночей и немного головной боли), но, судя по отзывам и реакциям разработчиков, того стоило. Когда я приходил на позицию Head of Engineering, я очень хотел добавить соревновательности, сплочённости и вовлечённости во вверенных мне подразделениях. В самую первую неделю в разговоре с одним подразделением, я услышал: «А что именно будет меняться с твоим приходом? А то очередной руководитель приходит и говорит, что он самый главный для нас, мы рассказываем о болях, а ничего не меняется». Изменилось то, что впервые был проведён турнир среди бэкенд-разработчиков с заданием, которое можно выполнять на любом языке. Тем самым я собрал на турнире и ребят, которые пишут на нашем основном языке (Java), и тех, кто работает на Kotlin, C#, Golang, Node.js, Python.🖥🖥🖥🖥 Я довольно долго переносил его — и не потому, что хотел, чтобы о нём забыли и тем самым негласно отказался от своего обещания. Просто была огромная нагрузка: работа без выходных и бессонные ночи. В итоге выбрал, наверное, один из самых подходящих моментов и собрался. Переносить в очередной раз очень не хотел. Обсудил то, что хочу сделать, с замом, и у него появилась куча вопросов, которые я уже держал в голове: - Какое задание дать? - Что делать с LLM и агентами — стоит ли их запрещать? - Как всех синхронизировать и где складировать результат работы коллег? - Как долго должно проходить такое мероприятие? - Как собирать и запускать тот код, который напишут? - Как проверять корректность? - Как оценивать результаты? - За что штрафовать? (Невнимательность, некорректность и т.д.) - Что дать на вход? (Какие требования и насколько проработанные?) и т.д. Честно, я бы не справился без своего зама. Чтобы всё успеть, мне нужно было вообще не спать перед турниром, а я и так поспал часа три, и ещё надо было игнорировать рабочие встречи, а этого я сделать не мог. Турнир был в 16:00, а ночью я лишь успел сформировать всё задание, попытаться написать его руками и сгенерировать два решения — на Java и на Go. За полчаса до турнира у нас всё ещё не было отточенного задания. Я хотел усложнить его для ИИ и перевести часть задания из текста в изображения, чтобы сдвинуть фокус в сторону разработчиков без ИИ, но просто не успели. Также нужны были примеры с Dockerfile'ами, которые мы делали под разные стеки, чтобы их можно было просто скопировать в корень. За 5 минут до турнира мы только всё доделали. Я хотел, чтобы первые 10 минут встречи все собирались, пока я объяснял задание и что будет на турнире, а ровно в 16:10 я запушил бы описание задач и начался бы турнир. Поскольку сложно одновременно вести встречу, отвечать на вопросы и вовремя присылать задание, я попросил зама помочь. К слову, про задание никому не говорил до последнего момента, чтобы наверняка не было никакой утечки и нечестного состязания. Какие-то организационные вопросы были понятны до старта, а какие-то проявлялись по ходу дела. Например, чтобы удобно тестировать всех, как blackbox и не вникать в сборку и запуск каждого языка и фреймворка, пришлось попросить всех написать Dockerfile'ы 🖥, а местами и docker-compose'ы — чтобы просто запустить на моём компьютере( да да, я выкачивал пол интернета зависимостей, которых у меня не было локально, чтоб аж место на диске закончилось) и проверить работу. А дальше началось самое интересное: многие справились с кодом, но, как показало соревнование, нашей точкой роста является культура DevOps и именно сборка образа. И хоть ребята все скилловые и умеют поднимать окружение локально в Docker, но написать Dockerfile или docker-compose смогли не все — хотя мы с замом положили прямо в репозиторий очень много примеров Dockerfile'ов, с которыми ребята могли работать. В целом, я рассуждал так, что если я не могу собрать артефакт и запустить его, это как будто человек не справился. Но хотелось проверить, что ребята умеют писать код в первую очередь (или генерировать его 😁). Поэтому я ввёл систему штрафов: те, кто сделал работу идеально, не штрафуются, а если есть проблема со сборкой, то минус 5 баллов. И тем самым я увидел, что большое количество разработчиков всё-таки зарешало все задачи. Да, Dockerfile'ы и docker-compose'ы либо генерируются, либо делаются зачастую DevOps-инженерами — это нормально, что разработчик не помнит всё наизусть и может ошибиться. Это очень похоже на настройку Maven в первый раз при устройстве на работу или настройку Spring Security в новом сервисе. Сделал один раз и забыл. Разбор и оценка работ коллег оказались очень болезненными: с работы я выехал пораньше, около 18:30, в 19:30 был дома и до 4 утра собирал работы ребят, чинил сборку, проверял и на самом деле уже видно, что многие активности просто невозможны без агентов. Если бы я пытался сам отлаживать и исправлять Dockerfile'ы, перезапускать и снова тестировать, то, наверное, ещё неделю сидел бы вечерами. Можно много чего рассказать про это мероприятие, но хочу отметить: я объявил его с немаленьким призовым фондом из своих денег, и нашлись люди, которые решили поддержать и увеличить его. Отдельное им спасибо. А самое интересное для меня — то, что я знаю довольно многих разработчиков в компании и среди них очень много сильных ребят, но в топ-3 оказались люди, с которыми я толком никогда не общался и не мог думать о них как о победителях. А значит, турнир прошёл честно и не предвзято. Конечно я не получил какую-то всеобщую любовь и признание от ребят из разработки, но даже того, что мне в личку написало порядке 10 человек и все они сказали "спасибо за турнир, было интересно" более чем достаточно. Всем хорошего вечера и желаю выспаться перед рабочей неделей! 😊
#ai #git #автоматизация #claude #bash 🔥 Экономь 10–20 минут на пуше веток с помощью простого скрипта Разрабатываешь с CLI‑ассистентом (например, Claude) и часто пушишь изменения в несколько задач одновременно? Возможно ты решил сделать подвиг за ночь и закрыть кучу багов, возможно вышел в выходные под много задач, а релиз на носу. Ручной перебор веток — это скучно и долго. Особенно когда нужно залить 5–7 веток, а сплит‑туннелирование не настроено для корп впна. Выход есть — небольшой bash‑скрипт, который автоматически переключит и запушит все указанные ветки. 📜 Скрипт push_branches.sh #!/bin/bash set -e REPO="C:/YOUR_WORKSPACE_FOLDER/REPO_NAME" BRANCHES=( "ABC-00001" "ABC-00002" "ABC-00003" "ABC-00004" "ABC-00005" "ABC-00006" "ABC-00007" ) cd "$REPO" for BRANCH in "${BRANCHES[@]}"; do if git show-ref --verify --quiet "refs/heads/$BRANCH"; then echo ">>> Пушим $BRANCH ..." git checkout "$BRANCH" git push origin "$BRANCH" && echo "✓ $BRANCH запушена" || { echo "✗ Ошибка при push $BRANCH — остановка"; exit 1; } else echo "--- $BRANCH не найдена локально, пропускаем" fi done echo "" echo "Все ветки успешно запушены." ⚙️ Как использовать 1️⃣ Сохрани код в файл push_branches.sh (в любой папке). 2️⃣ Замени REPO на путь к твоему локальному репозиторию. (а лучше попроси агента) 3️⃣ Замени список BRANCHES на свои ветки. (также лично я просил агента) 4️⃣ Открой Git Bash (или любой bash‑совместимый терминал), перейди в папку со скриптом и выполни: bash ./push_branches.sh Если ветка не найдена локально — скрипт её пропустит. При ошибке пуша процесс остановится, чтобы ты успел разобраться. ✅ Преимущества 🚀 Экономия времени — вместо 10–20 минут рутины — один запуск. 🧠 Идеально для AI‑кодинга — попроси Claude написать код в каждой ветке, а потом одной командой залей всё. 🔒 Безопасно — проверка существования ветки и остановка при ошибке. Попробуйте — это реально прикольно и работает. Если вам интересно пообсуждать пайплайн разработки с CLI от списка задач в джире до готовых веток, то могу попытаться это сделать в будущих постах. Для этого ставьте - ❤️ Всем хорошего дня!
🔥 Знакомый TechLead посоветовал крутой ресурс — system-design.space. Говорит, сам там в свободное время прокачивается по теме System Design'a и главное бесплатно. Что там есть: • Библиотека из 284 глав в 4 форматах: конспекты книг, разборы реальных кейсов, документальные материалы и авторские статьи. • Граф знаний, который показывает связи между темами — от базовых концепций к сложным. • Персональные треки под твой уровень, специализацию и свободное время — сайт сам соберёт маршрут. • Отслеживание прогресса, чтобы видеть, сколько уже пройдено и что ещё предстоит изучить. В общем, отличная штука, чтобы системно подойти к подготовке к интервью или просто прокачать скиллы в архитектуре и проектировании систем. Всем хорошего вечера!
#kafka #java #spring #asyncapi #plugin #github Всем привет! Давно хотел сделать свой gradle плагин, всё время не было сил или времени. Вдохновился я openapi спецификаций и генерацией исходников по спеке. Сейчас расскажу, как создается и публикается свой gradle плагин по шагам. Обычно java разработчики подключают зависимости и плагины и не публикуют ничего в opensource. Все библиотеки, которые делают разработчики оседают в корпоративном nexus'e, а публикацию туда настроили за них DevOps-инженеры. Я решил это исправить и сделал AsyncAPI Generator — Gradle плагин, который генерирует Spring Kafka consumer'ов и producer'ов из AsyncAPI 3.x спецификации. Без npm, без pip, чистая JVM. Шаг 1 — Создаём структуру плагина Gradle плагин — это обычный Java проект, но с одной особенностью: в build.gradle применяем id 'java-gradle-plugin' plugins { id 'java-gradle-plugin' } gradlePlugin { plugins { myPlugin { id = 'io.github.username.my-plugin' implementationClass = 'com.example.MyPlugin' } } } Плагин состоит из трёх ключевых классов: — Plugin<Project> — точка входа, вызывается при apply — Extension — DSL для настройки (myPlugin { ... }) — DefaultTask — задача, которая делает полезную работу Шаг 2 — Локальная проверка через composite build Перед публикацией нужно проверить что плагин работает. Публиковать в Maven каждый раз — долго. Решение: composite build. В тестовом проекте прописываем в settings.gradle: pluginManagement { includeBuild('../my-plugin') // путь к плагину локально } И всё — Gradle сам подхватывает плагин из исходников. Никакого publishToMavenLocal. Шаг 3 — Регистрируемся на plugins.gradle.org Переходим на plugins.gradle.org → Login через GitHub. В профиле: API Keys → Generate API Key Копируем два значения в gradle.properties плагина: gradle.publish.key=GPPK-xxxx gradle.publish.secret=GPPK-yyyy ⚠️ Этот файл добавляем в .gitignore — секреты не должны уходить в репозиторий. Шаг 4 — Добавляем publishing плагин plugins { id 'java-gradle-plugin' id 'com.gradle.plugin-publish' version '1.3.1' } gradlePlugin { website = 'https://github.com/username/my-plugin' vcsUrl = 'https://github.com/username/my-plugin' plugins { myPlugin { id = 'io.github.username.my-plugin' displayName = 'My Plugin' description = 'Что делает плагин одной строкой' tags.set(['kafka', 'spring', 'codegen']) } } } com.gradle.plugin-publish автоматически генерирует POM, sources jar и javadoc jar. Шаг 5 — Требования Portal перед публикацией Portal проверяет несколько вещей, иначе вернёт ошибку или отклонит при модерации: ❌ Версии SNAPSHOT и beta — не принимаются. Только финальные: 1.0.0, 2.3.1 ❌ Без website и vcsUrl — не пройдёт ❌ Без описания и тегов — не пройдёт ✅ Namespace должен принадлежать тебе. Самый простой вариант — io.github.username (GitHub аккаунт). Никаких DNS не нужно. Шаг 6 — Публикуем ./gradlew publishPlugins Эта одна команда: Компилирует плагин Генерирует javadoc и sources jar Загружает всё на Portal Создаёт страницу плагина Через пару минут плагин доступен всем: plugins { id 'io.github.talismanovit.asyncapi-generator' version '1.0.0' } Шаг 7 — Что проверить перед публикацией (security checklist) Я прогнал статический анализ и нашёл несколько вещей, которые легко пропустить: 🔴 Path Traversal (CWE-22) — если плагин пишет файлы на диск, путь формируется из входных данных (например, из YAML-файла пользователя). Злой basePackage: ../../../../etc/ мог записать файлы куда не надо. Фикс — проверяем getCanonicalPath() перед записью. 🟡 Silent file deletion — File.delete() возвращает boolean, который легко проигнорировать. Используем Files.delete() из NIO — он бросает IOException при ошибке. 🟡 Configuration Cache — getProject() нельзя вызывать внутри @TaskAction. Gradle кэширует граф задач и при повторном запуске Project недоступен. Убираем вызов — задача становится CC-совместимой. Результат Плагин живёт тут: 👉 plugins.gradle.org/plugin/io.github.talismanovit.asyncapi-generator Исходники: 👉 github.com/talismanovIT/asyncapi-generator На mvnrepository.com появится через несколько часов — они индексируют с Portal автоматически. P.S. держу пальчики, чтобы завтра апрувнули plugin на plugins.gradle.org и можно было привычным образом выкачать и проверить Всем хорошего вечера!
#docker #postgres #pg_dump Всем привет. Как всегда давно не писал и меня уже ругают за это, поэтому решился и выделил часик. Думаю 99% разработчиков в нынешнее время умеет поднимать базу в докере для локальной работы. Но многие ли выгружали дамп базы, которая развернута у вас локально в docker'e? Думаю единицы. Для чего это может быть нужно? 1️⃣ Вы вели долго локальную разработку и имеете хорошие тестовые данные 2️⃣ отлаживались на заливке реальных данных (дергаете чужое апи. Например хедхантера) и условно имеете эталон. 3️⃣ А возможно вы вашу базу, как слепок вы хотите as is пролить например на DEV среду. Причин может быть много, но хотя бы несколько из них я привел. И так, а как же это сделать? Для начала сделаем docker ps и увидим какие контейнеры подняты в докере. Одним из этих контейнеров должен быть ваш postgres затем сделаем docker exec в наш контейнер и сделаем дамп, например так: $ docker exec my_db_container pg_dump -U postgres -F c my_db_name > db_backup.dump Разберем куски этой команды для большего понимания, ведь нельзя серьезным специалистам совсем не понимать какие команды они выполняют. Мы же не джуны с LLM и не занимаемся vibe devops'ингом. 1️⃣ docker exec - выполнение команды внутри работающего контейнера 2️⃣ my_db_container - это название контейнера, которое вы видите в NAMES, когда сделали docker ps. Вместо названия вы могли указать CONTAINER_ID в виде хэша. 3️⃣ pg_dump - утилита postgres'a для создания резервных копий 4️⃣ -U - указание пользователя 5️⃣ -F - указание формата выходного файла 6️⃣ с - кастомный формат pg_dump (сжатый, работает быстрее для больших баз, бинарный) Как альтернативы есть -F p - plain text SQL, -F d - directory (папочка с файлами) и -F t - tar архив 7️⃣ my_db_name - имя вашей базы данных, которую надо дампить 8️⃣ > db_backup.dump - перенаправление вывода в файл (это уже выполняется на хосте, не в контейнере) Проверяем, что дамп создался. $ ls | grep backup db_backup.dump Теперь, если мы очень хотим проверить, что всё с дампом хорошо или хотим залить другую базу поднятую в контейнере, то можем просто поднять рядом еще один postgres $ docker run -d \ > --name postgres_restore \ > -e POSTGRES_PASSWORD=mysecretpassword \ > -e POSTGRES_DB=my_db_name \ > -p 5433:5432 \ > postgres:latest 459976e27aa85a913a77f13c3dcc4c900c5324485250dbf206f5e5fff6620dfa проверяем, что база поднята $ docker ps | grep postgres_restore 459976e27aa8 postgres:latest "docker-entrypoint.s…" 22 seconds ago Up 22 seconds 0.0.0.0:5433->5432/tcp postgres_restore заливаем дамп в новую базу $ docker exec -i postgres_restore pg_restore -U postgres -d my_db_name < db_backup.dump Если вы работаете на винде, как и я, но любите грепать, как линуксоид, то просто используйте Git Bash, у многих кто работает с гитом он есть. Да и не сложно установить. Есть хоть кому-то было интересно или полезно, то жду реакции. Всем спокойной ночи :)
Иногда знакомишься с подчиненными впервые при "пожарах", у меня так было много раз и сейчас снова ровно такой случай. Сроки горят, команда героически справляется трудясь сверхурочно. Самое приятное, что люди с первых минут производят приятное впечатление, которое никуда не уходит спустя дни. Ребята просто профессионалы и качественно делают свою работу. У меня всё. 😅
Всем привет! Сегодняшний день для меня является знаковым. Я перестал быть Solution Architect и перешел внутри ГК ДОМ.РФ на позицию Head of Engineering. 🍾🍾🍾 Впереди много челленджей и большое желание снять головную боль у наших СЕО и СТО. Планирую развивать наши инженерные команды, улучшить коммуникации с нашими архитекторами и devops’ами, улучшать качество наших систем, обеспечить предсказуемость time-to-market и многое другое. Всем спасибо за внимание и хорошего вечера😊
💻 Локальный эмулятор AWS В марте 2026 года LocalStack Community Edition перестал быть бесплатным в полном смысле слова. Теперь нужен токен авторизации, CI-поддержка только в платных тарифах, а обновления безопасности заморожены. Floci — это open-source замена. Без регистрации, без ограничений в CI. Запускается одной командой. Floci эмулирует больше 20 AWS-сервисов, в том числе те, которых не было в бесплатном LocalStack. S3, SQS, DynamoDB, SNS, Lambda, IAM, STS, Cognito, API Gateway v2, ElastiCache с IAM-аутентификацией, RDS (PostgreSQL и MySQL), Kinesis, KMS. Все 408 SDK-тестов проходят. Минимальный docker-compose.yml: services: floci: image: hectorvent/floci:latest ports: - "4566:4566" volumes: - ./data:/app/data Все сервисы доступны на http://localhost:4566. Регион и учётные данные могут быть любыми. Если вы использовали LocalStack в CI или локальной разработке и не хотите переходить на платный тариф, Floci закрывает эту потребность. ➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера
Какая же годнота. Многих кто хотел поиграться с AWS отпугивали регистрация, VPN и привязывание карты. А тут можно поднять локально эмулятор и пощупать. Отмазок больше будто бы нет. Или все еще есть?😅
Всем привет. Я долго думал и решился, перехожу на Junior Golang Developer. Буду писать на модном языке Шутка) С 1ым апреля🤣
Всем привет! Вспоминаю смешное собеседование, которое проводил лет 5 назад будучи тимлидом котлинистов. Девушка - кандидат на роль мидл разработчика сходу говорит, что она на проекте, который на поддержке и что если бы проект развивался, как раньше, то она была бы там тимлидом. На что я сказал, что тимлид уже у нас есть) Начинаем собеситься, дошли до коллекций в java (она только на нем писала) и тут она начинает рассказывать, как она круто применила TreeSet и что слова все стали отсортированы от А до Я. Я такой: "Это конечно круто, а что там под капотом у TreeSet?" Она: "В смысле под капотом?" Я: "Ну что за структура?" Она: "Дерево" Я: "А какое именно дерево?" Она: "ну в смысле какое дерево?" Я: "Бинарное? Не бинарное? Сбалансированное? Не сбалансированное?" Она: "Не бинарное и несбалансированное" Я: "Увы, но дважды не угадала" 😅😂🤣 На всякий случай приведу справку, что TreeSet - это бинарное самобалансирующееся дерево на основе красно-черного дерева. Помню, что я не рекомендовал её брать в организацию, прям слабенький мидл была, но её все равно взяли.🤣 И помню, что мидлом джавистом тогда она хотела 220-250 гросс. История чистая правда. Надеюсь немного поднял настроение. Всем хорошего дня.