Apache Camel은 통합 프레임워크로, 여러 시스템 간의 메시지 라우팅 및 처리 로직을 정의하고 실행하기 위해 사용된다.서로 다른 시스템 간 데이터를 통합하고 처리할 수 있도록 Component 와 Java APIs 들의 집합으로 구성되어 있다. 즉, Camel

회고는 단순히 올해 있었던 일을 돌아보는 것이 아닌, 성장을 위한 과정이라고 한다.따라서 자신을 평가하기보다, 어떤 상황에서 적절한 행동을 할 수 있다는 기대와 신념을 갖는 즉, 효능감을 느끼는 방향으로 회고를 진행하는 것이 중요하다고 한다.이러한 회고는 두 가지 목적

오프라인 매칭 플랫폼 밥풀의 모니터링 서버는 구글 클라우드 VM 위에 구성되어 있습니다.그러던 어느날, 그동안 잘 접속되던 Grafana 대시보드에 로그인을 시도하니, 500 Internal Server Error 가 응답되었습니다.그라파나\_로그인\_오류당시 화면 캡

origin query오류해결Cause of the IssuePrepared Statement Compilation in H2: H2, unlike some other databases, attempts to compile prepared statements immed

포맷이라고 부를 수 있을 최소 요건을 갖춘 것 같아, 로그 기능을 적용한 버전을 재배포 하고 결과를 살펴봤습니다.확실히 정돈되어 보이고 로그가 쌓이는 모습에 기쁨도 잠시, 무언가 이상한 점이 눈에 띄었습니다. 바로, 어떤 클라이언트가 요청을 전송하든 CLIENT IP:

인터넷 통신클라이언트와 서버 사이에는 거리가 존재하고, 그 사이의 인터넷망을 거쳐야 통신할 수 있다.인터넷 망은 복잡하다. 수많은 중간 노드(서버)를 거쳐야 한다. 어떤 규칙으로, 어떤 방법으로 목적지에 도착할 수 있는지에 대한 물음으로 해당 강의는 시작된다.프로토콜프

밥풀 프로젝트의 인프라 작업에 대한 책임감에 의해 프로젝트를 진행하는 동안 주기적으로 AWS Billings 서비스를 팔로잉 하고 있었습니다. 그러던 어느날 Simple Storage Service에서 0.01 $ 가 과금 예정임을 발견했습니다. 얼마 되지 않는 비용도

별도의 유지보수 기간에 사용자들이 가장 자주 호출하는 프로필 페이징 API의 응답속도가 상대적으로 느리다는 것을 파악하고, 쿼리를 개선하는 것을 목표로 작업했습니다. 하지만 그 과정이 순탄치 못했습니다. 더미데이터 삽입 부터, 쿼리의 실행계획을 분석하고, 다양한

Babpool 프로젝트의 고도화를 위해, 기획 또는 사용자 경험상 미비한 부분을 보강하기 위한 미팅이 계속 진행 중 입니다. 그 중 밥 약속 요청 플로우에서 개선의 여지를 발견하였고 팀원들에게 공유한 내용은 다음과 같습니다.Sender(요청을 보내려는 사용자) A, B

왜 Auto_Increment 대신 랜덤 식별 값을 고려하게 되었는가 그동안 참여했던 웹 프로젝트에서도, 학습 과정에서 활용되었던 프로젝트에서도 자원을 식별하는 값의 전략으로 Auto Increment 를 사용해왔습니다. Auto Increment 전략은 테이블에

약 4일 전, 새로운 사이드 프로젝트의 인프라 구축을 담당하게 되어 AWS 신규가입을 했고, 1년간 프리티어 혜택을 이용할 계획이었습니다.우선 반드시 사용할 EC2와 RDS를 생성했고, EC2에 탄력적 IP를 발급받아 할당했습니다.과거(21년도)의 경험을 바탕으로 프리

데이터베이스 연동이 필요한 테스트를 통과하기 위해 Github Actions Market에서 검색되는 비공식 플러그인 getong/mariadb-action@v1.1을 사용해 MariaDB를 설치하였으나 SQLSyntaxErrorException 에러가 발생하며, 테스

북마크 관리 웹 프로젝트는 API 문서 생성 도구로 Spring REST Docs와 Swagger 를 결합한 형태를 선택했습니다.openapi3 으로 생성된 OpenAPISpec의 문서 파일(open-api-3.0.1.json)을 swagger-ui으로 호출하여 동적인

SSAFY와 독립적인 단체이며 수료생을 대상으로 운영되는 동문회로 수료생들의 정보, 문화, 취미 등의 교류를 이어나가는 네트워크이다. 이전까진 주요활동들이 수료생들에게만 한정되어 있었으나, SSAFY인들만의 장이 아닌 개발자들의 장으로 발전하기 위해 올해 처음 외부인에

어느덧 코드트리 블로그 챌린지의 마지막 8주차 이다. 2개월이란 시간이 순식간에 지나갔고, 코드트리에서 코테를 학습하는 행동이 주중 아침을 시작하는 루틴으로 자리잡혔다. 챌린지가 마감되어도 주차마다 진단테스트를 수행하고 저장소에 업로드하는 것을 유지해보면 의미있을 것

지난 6주차는 투 포인터를 학습하였고, 많은 난관을 맞이했다. 또한 TreeSet과 같은 자료구조에 대해 알지 못해 해설을 참고하는데도 어려움이 있었다.예상대로 실력진단 결과 점수가 낮아졌다. 이전에 완료하지 못한 유형을 다시 풀이할 수 있게 되어 오히려 좋다. 학습

지난 5주차 DP유형을 원할하게 풀이하지 못해 이번주차도 동일 유형을 학습하게 될 것이라 생각했다. 그러나 예상과는 다른 결과가 나타났는데..IM단계의 TwoPointer유형을 학습하라는 진단을 받았다.

지난 4주차에 학습하던 IL단계의 DFS/BFS유형을 완료하지 못했다. BFS의 돌 잘 치우기 문항부터 고전중이다. DP 문항을 접하고 테스트케이스 까진 통과하였으나 제출에서 실패하였다. (맞왜틀🤔?) 실력 진단 결과에 따라 이번 주차는 DP유형을 학습한다!

지난 3주차에서는 NH 단계의 DP를 학습했다. 이전 주차들과 달리 해설을 봤던 문항들이 많았으며, 직접 코드를 구현해보지 않아 경험이 부족함을 많이 느꼈다.슬프게도 진단 점수가 하락했다. 특히 DFS 유형으로 분류되는 실력진단 문제에서 return 문을 잘못된 부분에

지난 2주차에서는 NM 단계의 시뮬레이션2를 학습하여 dx, dy 를 활용한 방향전환 유형에 익숙해졌다. 이번 3주차는 NH 단계의 DP를 학습했다. 코드의 구현은 없었으나, 문제 유형을 익히고 점화식을 도출하는 과정을 학습하였다.