즐겁게 개발

mysql에서는 아래 모두 같은 결과 지원select DATE_FORMAT(now(), '%Y-%m-%d') from dual;select DATE_FORMAT(now(), "%Y-%m-%d") from dual;근데 mariadb에서는 아래와 같은 결과select DATE_FORMAT(now(), '%Y-%m-%d') from dual; // 2024-07-04select DATE_FORMAT(now(), "%Y-%m-%d") from dual; // [42S22][1054] (conn=11683) Unknown column '%Y-%m-%d' in 'field list'

지난번 Lock 관련해서 문제 해결을 고민하면서 Redis를 사용한 방법도 고민하지 않은 것은 아니지만, Redis를 사용한다고 했을 때 구축하는 것도 비용이고 관리포인트가 하나 더 늘어나기 때문에 제외했었는데, 또 다른 문제가 발생했고, Redis를 사용하여 해결하면 참 쉬울 것 같은데 Redis를 정말 사용할지 고민이 된다. 이제 갓 오픈하는 서비스이니 우선 간단하게 시작하자는 마음으로 최대한 Redis를 안 쓰고 해결할 수 있는 방법을 찾는 게 맞는가, 아니면 Redis를 사용하면 간단하게 해결될 문제이니 사용하는 것이 맞는가.

문제길이가 n인 배열 nums에서 n/2번 이상 등장하는 숫자를 반환한다. n/2번 이상 등장하는 숫자는 반드시 존재한다고 가정하며, 아래 조건일 때 시간복잡도 O(n), 공간복잡도O(1)으로 해결해야 한다.n == nums.length1 -10^9 나의 접근법Boyer-Moore 과반수 투표 알고리즘을 사용했다.class Solution { public int majorityElement(int[] nums) { int count = 0; int candidate = 0; for (int num : nums) { if (count == 0) { candidate = num; } ..

내가 처음 모니터링 시스템에 대한 필요성을 느꼈던 건 2022년 4월쯤이다.(https://dakafakadev.tistory.com/154) 그 이후로 이것저것 모니터링 시스템을 찾아보았고, 듣고 있던 강의 내용 중에 Prometheus + Grafana를 잠시 알려주긴 했지만(https://dakafakadev.tistory.com/240) 실전에 사용은 못하고 있던 터에 이번 서비스 모니터링을 위해 드디어 사용해보게 되었다. 우선 프로메테우스와 그라파나를 내 로컬에서 도커로 띄워서 서버에서 설정한 내용으로 잘 돌아가는지 확인한 후 VM을 생성하여 연동했다. 진짜 너무 이상하다싶을 정도로 간단하게 설치 완료. 설치를 다 하고 팀원들과 팀장님께 이러한 게 있다고 보여드렸는데, 팀장님이 알고는 있었지만 ..

서비스 오픈을 위해 개발에 힘쓰던 중 동시성 문제를 해결해야할 상황이 왔다. 개발중인 서비스는 가계부인데, 거래가 입력되거나 수정되거나 삭제될 때마다 금액에 대한 업데이트를 정확하게 해줘야할 필요가 있었다. 그러나 고려해야 할 사항은 아래 두 가지가 있었다.첫번째, 서버의 스케일 아웃을 고려해야 한다.두번째, 서버 개발에는 최소의 비용이 들어야 한다. 첫번째 사항인 서버의 스케일 아웃을 고려하면 당연히 소스코드 내에서 처리하는 것은 불가능했고, 비관적 락, 낙관적 락, Named Lock, 혹은 분산 시스템을 사용하여 락을 구현하는 방법 등 여러 가지 방법이 있었는데 내가 선택한 방법은 Named Lock이었다. 비관적 락의 경우, 실제로 로우나 테이블 단위로 데이터에 락을 거는 방법인데, 충돌이 빈번하..

우리 팀이 워크샵을 가게 되어 마이리얼트립에서 상품을 구매하게 되었고, 좀 더 싸게 사보고자 쿠폰 다운로드 버튼을 눌렀는데 '쿠폰을 받지 못했습니다. 다시 시도해주세요.'라고 뜨며 다운로드가 되지 않았다. 그래서 혹시나 해서 확인해본 개발자도구에는 콘솔에 엄청나게 많은 에러가 찍혀있었다.그래서 바로 마이리얼트립에 제보를 했다.지인이 마이리얼트립에 다녔던 관계로 지인을 통해서도 마리트에 이슈를 접수했는데, 핫픽스로 처리하고 있다는 이야기까지만 들었다. 며칠 후 다시 쿠폰 다운로드를 해보니 잘 받아졌다. 우리 팀 워크샵을 위한 상품은 이미 결제했지만...그리고 예약 상세 화면에서 세부사항에 저렇게 JSON 형태로 데이터를 보여주는게 맞나 싶어서 그것도 제보하긴 했는데 아무래도 수정이 안된걸로 봐서는 버그는 ..

처음 내가 서버 개발을 담당하게 되었을 때, 생각보다도 간단했던 기능에 약간 기운이 빠지기도 했다. 서버는 단순히 데이터 동기화의 역할만 해주면 될 뿐이라고 알게 되었을 때 데이터 동기화 기능만 만들어주고 이후엔 서버 개발에선 빠질 것 같았다. 실제로 앱 개발 팀장님이나 우리 팀장님이나 그렇게 얘기를 하셨고. 내가 서버를 맡기 전까지 서버를 담당하신 앱 개발 팀장님께 인수인계받은 내용으로는 앱 개발 팀장님이 이미 설계하신 API가 있었고, RequestBody의 대략 형태를 그려보자면 아래와 같았다. 의미를 풀어서 써보자면, data로 type의 작업을 task의 정보를 가지고 한다는 의미이다. 그 말인즉, 엔티티는 엄청 많은데 그 많은 엔티티의 작업을 처리하는 엔드포인트가 하나였다.{ "job":..