체인의정석

코드리뷰를 모두 마치고 올렸는데 git conflict가 발생하였다. 이전에 계속해서 했던 작업이지만 오랜만에 하니 기억이 안나 다시 정리하도록 하겠다. 먼저 명령어의 실행 위치는 원본 소스가 아닌 코드리뷰를 받는 소스이다. 해당 소스에서 원본 소스를 머지해야 원본에서 업데이트 된 코드가 리뷰를 받아 적용이 되게 된다. git merge develop 해당 명령어를 내리면 다음과 같이 충돌이 발생하는데 이걸 모두 클릭해서 충돌을 해결해 주어야 한다. 충돌을 모두 해결하고 나면 해당 변경 사항들이 commit에 올라가게 된다. 여기서 한번 더 수정사항이 맞는지 체크를 한 후 수정사항이 맞다면 push를 해서 수정된 코드를 반영해주면 해결이된다. 이떄 또한 주의할 점은 push를 하고 나서 한번 소스를 실행..

자바스크립트에서 비교 연산을 할 때 "=="를 사용하는것은 좋지 않다. 이유는 다음과 같다. 암묵적인 형변화를 실시하기 때문에 데이터 타입 오류를 덮어버리는 효과를 가지고 있어서 오류에 대한 대응을 놓칠 수 있다고 본다. https://ui.toast.com/fe-guide/ko_ANTI-PATTERN#%EB%8F%99%EB%93%B1-%EB%B9%84%EA%B5%90-%EC%97%B0%EC%82%B0-%EC%8B%9C-%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%A7%80-%EC%95%8A%EB%8A%94%EB%8B%A4 안티 패턴 안티 패턴이란 습관적으로 많이 사용하는 패턴이지만 성능, 디버깅, 유지보수, 가독성 측면에서 부정적인 영향을 줄 수 있어 지양하는 패턴이다. 이..

nest.js 모듈을 써서 예외 처리를 하다가 보니 에러가 iterable하지 않는다는 말이 나와 찾아 보았다. https://docs.w3cub.com/javascript/errors/is_not_iterable Errors: Is Not Iterable - JavaScript - W3cubDocs Errors: is not iterable The JavaScript exception "is not iterable" occurs when the value which is given as the right hand-side of for…of or as argument of a function such as Promise.all or TypedArray.from, is not an iterable obje..

페이징 부분에 다음과 같은 실수를 하였다. 아래처럼 "|"를 하면 두 값에 대한 byte연산을 진행하게 된다. 이러한 비트 연산을 원래 의도에서 벗어났다. this.page = page | 1; this.rpp = rpp | 20; 따라서 다음과 같은 논리연산으로 해야 값이 비었을 때 기본값을 넣어줄 수 있게 된다. this.page = page || 1; this.rpp = rpp || 20; https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment Logical OR assignment (||=) - JavaScript | MDN The logical OR assignment (x |..

Controller 부분에서 아래와 같이 함수를 짜면 잘 보이지만 swagger에서는 잘 잡히지 않는다. @Param('ethAddress') ethAddress: string, @Query('쿼리파라미터1') 쿼리파라미터1?: string, @Query('쿼리파라미터2') 쿼리파라미터2?: string, @Query('쿼리파라미터3') 쿼리파라미터3?: number, 다음과 같이 optional 하게 주려고 해도 required로 나온다. https://github.com/nestjs/nest/issues/2169 Please Add `optional: boolean` to @Query route param decorator · Issue #2169 · nestjs/nest I'm submitting ..

이더리움 value의 경우 숫자가 커서 빅넘버처리를 안해주면 에러가 나게 된다. 단위가 너무 크기 때문인데 조사해본 결과 빅넘버 처리는 결과 목적에 맞는 모듈을 사용하는것이 정답이라고 한다. 타입스크립트도 사용하였으니 한번 유명한 ether.js를 찾아보았다. 처음 써보는데 너무 편리했다. 일단 ether.js 에서 사용하는 bignumber의 경우에는 elliptic로직에서 쓰이는것과 같은 방법이기 때문에 가장 안전하다고 한다. 오랜기간 서칭을 한 결과 몇가지 케이스에 대한 방안을 알 수 있었다. 1. 이더리움 단위로 만들 경우 //ethers.utils.formatEther( value ) ⇒ string const value = BigNumber.from("1000000000000000000"); ..

입력값을 수정하는 부분이 nest.js에서 매우 중요한데, 사실 이게 타입스크립트를 쓰는 이유이기도 한다. 타입스크립트를 사용하게 되면, 타입을 모두 지정해 줄 수 있어서 모든 request , response 그리고 그 안에 들어가는 요소들을 객체화 시키고 타입을 지정하여 모든 상황에 대한 예외를 잘 잡아 줄 수 있다. 1. Class validator 사용의 경우 이번 프로젝트를 구현하면서 가장 많이 사용한 것은 class-validator 이다. Validation Pipe 모듈의 경우 클래스 형태로 요청을 받아줄 때 사용가능하기 때문에 일반적인 string의 형태나 단일 타입에 적용 시킬 수는 없다. 따라서 조회를 쿼리 파라미터로 실행하는 경우 class-validator를 실행한다고 보면 된다...

1. 공통 예외처리 부분 에러 처리의 경우 결과적으로 invalid input과 internal server error로 나뉘었다. 여기에 대한 구조는 다음과 같다. @Get('/:ethAddress/경로') async 함수이름( @Param('ethAddress') ethAddress: string, . . . @Query('page') page?: number, ): Promise { //오류의 경우 공통 부분으로 빼두어서 관리 const 객체화된요청 = new RelatedTransactionsRequest( ethAddress, new Date(fromDate), . . page * 1, ); const errors = await validate(객체화된요청); //쿼리 파라미터가 있는 경우 va..