Redddy's Devlog

"한빛미디어 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다." 불과 2년전, 내가 러스트를 처음 배울 때만 하더라도 자바, 자바스크립트, 파이썬과 같은 다른 언어에 비해 러스트를 다루는 도서가 국내에 많이 없었는데, 요즘은 1~2 달에 한권씩 러스트 신간 소식이 들려온다. 러스트 관련 신간 소식을 들으면 목차를 살펴보는 편인데, 입문서, 초급자에 관한 도서는 많이 있지만 중고급 내용을 다루는 도서가 많이 없다는 것을 느꼈다. 문법 이외에 좀 더 심화 내용을 중점으로 다루는 도서를 찾고 있었는데, 그런 의미에서 이 도서가 그 고민을 조금 해소해주었다. 러스트로 갈아타기는 C, 파이썬, 자바스크립트 언어를 사용하다가 성능, 속도의 한계에 부딪혀 러스트로 갈아타기 위한 사람들을 위한 도서이다. 이..

The Rust Programming Language(the book이라고도 불린다)는 rust-lang에서 관리하는 공식 가이드 북이다. 러스트 설치 방법부터 시작하여 기본적인 문법, 자료형, borrow checker, generic과 trait, 스마트 포인터, 동시성 등등 전반적인 러스트를 설명하고 있다. 러스트를 처음 시작하는 분들을 위한 책이며, 처음 시작한다면 무조건 읽어야 하는 필독서다. '나는 영어로 된 거 읽기 불편해~'하는 분들을 위해 rust-kr 커뮤니티가 관리하는 한국 번역판도 있고, '아 나는 e북은 잘 안들어오더라~'하는 분들을 위해 종이책도 출판되어 있다. 이번 글에서 다루려 하는 내용은 #![feature(...)], feature 속성이다. feature 속성에 대해 설..

러스트에 기여하면서 배웠던 점들 알게 된 점들 깨달았던 점들을 남겨보려고 한다. 우선 러스트의 첫 PR은 문서 수정이였다. 코드 구경하다가 깨진 링크를 발견하였고 이를 수정하는 PR을 올렸다. 이렇게 한번 기여하고 나니까 뭔가 나도 좀 더 기여할만한 것들이 있는지 이슈를 둘러보기 시작하였다. 다른 이야기지만 이렇게 깨진 링크가 있는 Repository가 꽤 많이 있다는 것을 발견하고 러스트로 새로운 프로젝트도 만들어보고 있으니 많관부 (깃허브, 블로그) 이후 다른 오픈소스보다 알게된 점인데 러스트의 이슈 관리는 아주 잘 돼있는 편이었다. 라벨링도 다양하게 잘 되어 있었고, E-eazy처럼 난이도로 분리된 것도 있고, E-mentor처럼 멘토가 붙어서 도움을 준다는 이슈도 있었다. PR을 올리면 자동으..

🔈 문제koosaga와 cubelover가 "핌버"를 하고 있다. 핌버는 님 게임에 규칙을 추가한 게임이다. 핌버는 돌을 차곡 차곡 위로 쌓아올린 돌 더미 k개를 이용한다. 각각의 돌 더미에는 한 개 이상의 돌이 있다. 두 사람은 서로 턴을 번갈아가면서 핌버를 진행한다. 각 사람의 턴이 되면, 돌 더미 하나를 선택해 돌을 제거한다. 제거한 돌의 개수는 피보나치 수여야 한다. 전체 돌 더미에서 마지막 돌을 제거하는 사람이 게임을 이기게 된다.  게임은 koosaga가 먼저 시작한다. 두 사람이 최적의 방법으로 게임을 진행했을 때, 이기는 사람을 출력한다. 📝입력첫째 줄에 돌 더미의 개수 $N$ $(1 ≤ N ≤ 10^5)$이 주어진다. 둘째 줄에 각 돌 더미에 쌓여있는 돌의 개수 $P_i$ $(1 ≤ ..

서론코드포스를 참가하다보면 라운드 중일 때에는 Accept 떠서 기분좋게 다른 문제 풀러 갔지만, 시스텟 돌 때 TLE가 터지는 경우가 어떤 자료구조를 사용하면 99% 있다. 이유는 바로 해시 저격 때문이다. 우리는 해시 맵의 조회, 삭제, 삽입 연산이 $O(1)$이라고 알고 그렇게 사용해왔다. 하지만 이는 평균 시간복잡도이지 최악의 경우 $O(1)$을 보장해주지 못하고 $O(n)$이 된다. 파이썬에서 해시를 사용하는 dict와 set은 물론이고 collections의 Counter와 defaultdict 역시 해시 저격에 안전하지 않다. 본론해시 저격이 가능한 이유는 해시 충돌이 생기기 때문이다.먼저 해시 충돌에 대해 설명해보자면,,, 해시는 임의의 데이터를 고정된 크기의 값으로 변환해주는 과정이다. ..

[AWS] AWS에서 248달러 플렉스하기 - 1와 이어지는 글이다. 본론이제 NAT 게이트웨이 비용을 줄일 수 있는 방법을 찾아야 했다. 구글링해보고 친구한테도 물어보니까 NAT 인스턴스가  NAT 게이트웨이의 역할을 대신 해줄 수 있다는 것을 알았다.  둘의 주요 차이점은 NAT 게이트웨이는 AWS에서 자동 관리 해주지만, NAT 인스턴스는 사용자가 직접 관리해야한다. 그리고 NAT 게이트웨이는 NAT 트래픽 처리에 최적화된 소프트웨어를 사용하지만, NAT 인스턴스는 단순히 NAT으로 설정된 일반 AMI를 사용한다. 때문에 NAT 게이트웨이가 NAT 인스턴스 보다 고성능 및 확장성을 제공해준다.   AWS에서는 NAT 게이트웨이가 더 나은 가용성과 대역폭을 제공하고 관리에 소요되는 작업이 줄어들기 때..

서론우테코의 인프라 비용 지원이 끝나고 맞이하게 된 첫번째 달이었다. 그동안 한달에 많아봐야 70달러를 넘기지 않고 사용해왔기에, 이전하면서도 그정도 예상을 했었다. 하지만 우습게도 일주일 만에 50달러를 초과하였다. 🤑 그렇게 12월 한달간 총 248달러 사용하였다. 본론왜 이렇게 많이 나왔느냐?!! 인프라 이전 회의를 하면서 테스트 환경과 운영 환경을 동일하게 가져가기로 결론을 내렸다. 운영과 테스트의 환경이 달라 테스트에서 잡지 못했던 예외 상황들이 운영에 배포되고 나서 확인이 됐던 꽤 있었기에 이를 방지하고자 내린 결론이였다. 예를 들면, 테스트는 단일 서버라 세션 공유 문제를 겪지 않았는데, 운영은 다중 서버 환경이여서 로그인 과정에서 세션 공유 문제를 겪었다. 그리고 운영에서만 nginx를..

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

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

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