이 글은 Mikro-ORM의 소개 글을 간단하게 번역 및 정리한 글이다.
Nest.js에 어떤 ORM을 사용할지 고민하던차에 Mikro-ORM을 발견하게 되었고 사용하기로 결정했다. Prisma, Typeorm 등이 있는데 이를 배제한 이유는 어떤 부분은 개인 취향, 어떤 부분은 테스트의 불편함 등이다.
어찌되었든 현재는 Nest.js 기반의 monorepo에 mikro-orm을 이용하여 개발을 막 시작하였다.
짧은 영어실력과 한정된 시간에 만든 문서라 틀린점이 있을 수 있다.
난 Closure를 사용하지 않는다. 하지만 이에 대해 질문을 너무 받아서 공부하여 정리한다.
Closure는 함수안에서 함수를 호출하는 것이며 이때 변수 scope을 유지하는, 즉 실행 컨텍스트를 유지될때 를 말한다. 즉 함수와 scope을 같이 들고 다닌다고 생각하면 된다.
더 풀어쓰면 함수 A안에 함수 B를 선언하여 리턴할때 B가 A내의 scope(변수, 함수 값)를 기억하게 되어 함수 A밖에서도 해당 scope의 값을 사용할 수 있는 것이다.
요새 DB 관련이야기를 많이 보고 질문도 받아서 공부한걸 정리했다.
DB는 언제봐도 어렵고 새롭다.
API 서버를 개발하게되면 서비스 기능과는 연관이 없지만 추가해야하는 기능이 있다.
바로 context 추적을 위한 request마다의 id 부여이다. 이는 http api 서버 뿐 아니라 단위 작업을 처리하는 애플리케이션이라면 어떤 곳에서든 필요하다.
보통은 http request가 처음 인입된 시점에 request에 임의의 id를 부여하고 해당 request에 의해 발행되는 log마다 이 id를 같이 기록하게 한다.
이를 통해 장애 발생시 로그를 볼때 해당 request의 log만을 쉽게 찾아 볼 수 있다.
문제는 node.js는 그동안 이 작업이 매우 불편했다는 것이다.
개발자로서 회사에서 일을 하다보면 가장 많이 듣는 이야기중 하나가 “OO님 지라 티켓 보셨나요? 대충 어느정도 걸릴거 같으세요?”와 같은 일정 산정, 또는 일정 관리일 것이다.
어떤 경우에는 하루면 되요, 일주일이면 되요 등과 같이 답이 쉽게 나오기도 하고 어떤 것은 “글쎄요…“와 같이 답이 나오지 않기도 한다.
장애 처리 티켓이 아닌 이상 대부분은 후자가 많은거 같다. - 내 경험 한정해서 말이다. -
회사에서는 항상 일정 관리가 되어야하고 일정을 예측할 수 있어야 한다고 나도 생각한다. 다만 개발을 함에 있어 어떠한 경우에는 이 일정 산정이 꽤나 어렵거나 아주 불가능한 수준이라고도 생각한다.
회사에서 개발을 하다보면 혼자가 아닌 여럿이서 하기 마련이다. 여럿이 일을 하는 조직에서 내가 리딩을 맡았을때 다른 분들에게 자주 이야기하는 것들을 정리했다.
쓰고보니 개발자 규칙이라기보다 회사원 규칙이라고 하는게 더 어울려보이긴한다.
요즘 일을 할땐 보통 커밋을 먼저 하는 편이다.
무슨 말인고 하니, 우선 내가 이번에 작성할 기능을 정하고, 그리고 개행하나 정도 추가한 커밋을 한다.
이때 커밋 메세지를 작성할때 제목에는 지라 티켓 번호와 간단한 설명을, 그리고 세부 내용에는 만들 로직에 대한 설명을 메세지로 작성한다.
그리고 내가 작성한 내역에 대해 코드를 추가하면서 지속적으로 commit –amend를 하여 커밋 하나를 완성하는 방식으로 일을 하고 있다.
Heap과 Stack에 대한 이야기가 잠시 나온다.
작성한 코드를 컴파일 하여 실행시키면 코드는 Stack, Heap, Code, Data 영역에 올라가게 된다.
이 챕터에서는 Stack과 Heap에 대해서만 알면된다.
간단히 말하면 미리 할당될 사이즈를 알아서 컴파일시 메모리에 할당되는 변수는 Stack에, 할당할 메모리 사이즈를 미리 예측하지 못하여 runtime 시점에 메모리를 할당해야하는 변수는 Heap에 위치한다고 생각하면 편리하다.
이 글은 Rust Tutorial 을 읽고 학습한 내용을 정리한 글입니다. 번역해주신 분께 감사드립니다.
