We will find a way, we always have.

-interstellar

분류 전체보기 301

[SpringBoot] actuator로 헬스 췤

문제 상황문제는 이사하는 도중 발생했다. 새집으로 이사를 하게되어 서브넷부터 EC2, RDB 등등 새로 다시 만들고 깃허브 액션 러너도 새 인스턴스를 바라보도록 변경하고 러너를 실행했더니 원인모를 일이 발생했다. 헬스체크가 안되는 것이였다.   wait for new enviroment to be healthy 에서 하는 작업은 5초 간격으로 /actuator/health로 curl을 날려서 "UP"이 되기를 기다리는 작업이다. 이전에는 약 20초 정도 걸리던 작업이였는데, 아무리 기다려도 UP이 되지 않았다.  인스턴스에서 접속해서 localhost:8080(혹은 8081)로 curl 날려도 요청이 잘 가는데, /actuator/health로 요청을 보내면 응답이 오지 않았다.  원인 파악/actuat..

Spring 2024.12.09

[우테코] 코딩해듀오의 미래

제목을 거창하게 짓긴 했는데, 우테코가 끝난 후의 코딩해듀오 팀의 계획을 남겨보려 한다. 우선 우리 팀은 우테코가 끝난 후에도 프로젝트를 이어가기로 했다. 그래서 요즘은 인프라 이사를 하고 있다. 하면서 느끼는 것인데 우테코의 인프라 비용 지원이 사라지게 되니 더 꼼꼼하게 스펙을 따져보게 되는 것 같다. 그리고 이상한 요청은 없었나 혹은 해킹당하지 않았으려나 AWS에 로그인을 자주 하게 된다. 백엔드 쪽에선 SSE로 구현했던 타이머 동기화 기능을 SSE 걷어내고 웹 소켓 도입 중이다. 타이머 뿐만 아니라 투두, 링크도 동기화가 됐으면 좋겠다는 피드백이 있어 서버와 클라이언트의 양방향 통신이 필요해졌다. 코드 쪽에서도 구조가 어색한 부분이 있어 이부분도 개선하고 싶다. (바쁘다는 핑계로 미뤄뒀던...)테스..

[대회] KUPC Open contest 후기

11월 24일 KUPC Open contest가 있었다.오픈컨 치르고 남겨보는 후기...A구현 문제였는데 문제 잘못읽고 1틀 먹고 시작했다. 문제를 꼼꼼히 읽자...B굉장히 재미있는 애드혹 문제였다. 아이디어 떠올리는 과정이 흥미로웠다. 역시 애드혹 문제는 노트 필수.C누적합 문제였는데, 아이디어는 금방 떠올랐으나 러스트 문법이 어색하여 구현이 조금 늦어졌다.D처음에는 투포인터가 떠올랐으나 구현하다보니 브루트포스가 되었다.오픈컨 후기를 적은 이유는 각잡고 러스트를 사용해서 대회에 참여한게(중간에 탈주하긴 했지만) 이번이 처음이였기 때문이었다.파이썬과 비교 했을 때 코드 타이핑 속도가 확실히 차이난다는 것을 느꼈다. 머리속으로는 파바박 이만큼 나가있는데 러스트 코드 피지컬이 못따라와서 답답함을 느끼기도 하..

[우테코] 베타테스트하러 부산간 썰 푼다 - 2

베타테스트10월 9일 드디어 베타 테스트 당일 날이다! 장소는 엘리스Lab을 대여하여 사용했다. 생각했던 것보다 굉장히 넓었고, 최신식 장비가 빵빵했다.   맥에 개발환경 세팅을 하면서 베타테스트 참여자분들을 기다렸고, 몇 분이 늦으셔서 예정 되었던 시간 보다는 조금 늦게 행사가 시작됐다.  간단하게 우리 코딩해듀오 서비스를 소개한 후 미션과 함께 페어 프로그래밍을 진행했다. 다들 컴퓨터 한대 두고 페어 프로그래밍을 하는 것을 보니 레벨1,2의 기억이 새록새록 떠올랐다.  하지만 넋놓고 바라만 보고 있지는 못했다. 운영서버에 문제가 발생한 것이다🚨 원인 모를 이유로 API 요청들이 무한 pending 상태에 빠져버렸다.  시도해본 방법은 두 가지이다.  1. 인스턴스 스케일업 베타테스트 하기 전에, 코..

[우테코] 베타테스트하러 부산간 썰 푼다 - 1

(오블완 챌린지 쓸 소재가 거의다 떨어져서 임시저장된 글들을 뒤져보는데 "베타테스트하러 부산간썰 푼다"라는 제목만 있고 내용은 비어있는 글을 발견하여 오늘 끝을 보기로 했다.) 우리 프로젝트를 모르는 사람에게 우리 페이지를 뙇 보여주었을 때, 이 프로젝트는 무엇을 위한 프로젝트인가? 하고 의문을 가지기가 쉽다. (데모데이때 받았던 피드백이기도 하여 docs 페이지를 구현하는 방식으로 피드백을 수용했었다) 그리고 페어 프로그래밍이라는 전제하에 사용이 되는 사이트다보니까 접근성도 떨어진다. 그래서 내린 결론이 우리가 미션을 제공해주고 페어 프로그래밍을 시켜 코딩해듀오 서비스를 사용해보도록 강제하는 베타테스트를 해보는 것이였다.  훨씬 이전부터 계획했었으나 여러 이슈로 연기되어 10월 9일 한글날에 베타테스트..

[자바] static과 static final의 유무에 따른 실행시간

백준 질문게시판을 구경하고 있었는데 재미있는 글이 올라왔다.모듈러 1,000,000,007를 static으로 두었을 때와 static final로 했을 때의 수행속도가 두배이상 차이난다는 글이었다.우선 static과 static final의 공통점은 둘 다 모든 객체가 해당 멤버 값을 공유한다. 차이점은 static final은 상수라는 점이다. 때문에 재할당이 불가하고 해당 값이 primitive type이라면 변경도 불가하다. 개념적인 차이점은 이제 알겠다. 그렇다면 바이트코드에선 어떠한 차이점을 가져오는지 살펴보자.  예를 들어 위와 같은 코드가 있다. (m,a,b는 입력받는 값이라고 생각하자.) MOD가 static final 일 때 바이트 코드이다.   아래는 MOD가 static 일 때 코드이..

[Rust] 러스트의 꽃, 소유권

러스트를 배우면서 가장 신기했던 부분은 바로 소유권이였다. 러스트 소유권에는 세가지 규칙을 따른다. 각각의 값은 소유자 (owner) 가 정해져 있다.한 값의 소유자는 동시에 여럿 존재할 수 없다.소유자가 스코프 밖으로 벗어날 때, 값은 버려진다 (dropped). 소유자 개념을 이해하기 위해 한가지 예시를 들어보겠다.   위 코드는 "레디"라는 문자열 객체를 만든 다음 tmp라는 변수에 할당을 해준다음 name을 출력하는 코드이다.  자바로 작성하면 아래와 같다.   자바에서는 아무런 문제 없이 돌아가지만 이 코드가 러스트에선 에러가 발생한다.    에러 발생 이유는 바로 소유권 때문이다.  처음에는 name이 힙 메모리에 저장된 문자열 "레디"를 소유하게 된다. 그 다음 tmp = name을 실행하면..

[Rust] 러스트에게 반한 점, immutable & mutable 변수

러스트에선 let 이라는 키워드를 사용하여 변수를 선언한다.    기본적으로 타입 추론을 해주고, 타입을 명시할 수도 있다.  러스트는 상당히 많은 타입 종류를 가지고 있는데, 이건 다음번에 이야기 해보도록 하고 이 글에서 이야기 하고 싶은 것은 immutable과 mutable이다.  자바를 사용하면서 이런글까지 쓸 정도로 final을 숨 쉬듯 써왔다. 로컬 변수, 파라미터, 필드 등등 붙일 수 있는 변수들에는 전부 final을 붙여왔었는데, 붙이면서도 애매했던 점은 사실 final을 붙여도 불변은 아니라는 것이였다. 재할당은 막을 수 있지만, 그 값 안의 있는 값들이 변경되는 것은 막을 수 없었다.  뿐만 아니라 final을 붙여도 값이 추가되는 것을 막을 순 없다.  위 코드는 문제없이 잘 돌아간다..

[LeetCode] 2516. Take K of Each Character From Left and Right

🔈 문제You are given a string s consisting of the characters 'a', 'b', and 'c' and a non-negative integer $k$. Each minute, you may take either the leftmost character of s, or the rightmost character of s.Return the minimum number of minutes needed for you to take at least $k$ of each character, or return -1 if it is not possible to take $k$ of each character. 💫 예시Input: s = "aabaaaacaabc", k = 2..

[독서] 자바 / 스프링 개발자를 위한 실용주의 프로그래밍 - 7

10. 도메인소프트웨어 공학에서 말하는 '도메인'은 애플리케이션이 해결하고자 하는 문제 영역을 의미한다. 다시 말하면 사용자들이 겪는 문제 영역이 바로 도메인이다. 그리고 문제 영역이 곧 비즈니스 영역이므로 도메인은 비즈니스 영역을 의미하기도 한다. 따라서 도메인은 문제 영역이자 비즈니스 영역이다.  같은 맥락으로, 개발자의 역할은 단순히 요구사항에 맞는 애플리케이션을 개발해 주는 것이 아니라 고객이 겪는 문제 상황을 소프트웨어로 해결해주는 사람이라고 볼 수 있다. 즉, 개발자는 도메인을 분석하고, 고객이 겪는 문제를 인지하고, 이에 맞는 도메인 솔루션을 개발해줄 수 있어야 한다. 개발만 잘한다고 좋은 개발자가 아닌 것이다 :) 스프링 같은 프레임워크나 JPA는 애플리케이션의 핵심이 될 수 없다. 때문에..

카테고리 없음 2024.11.19