일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- terraform
- java
- 리뷰
- IAC
- restdocs
- 백엔드
- typeorm
- docker
- chai
- terraform cloud
- 도서
- TypeScript
- mysql
- 블록체인
- 이더리움
- gradle
- 글또
- nestjs
- blockchain
- spring
- ChatGPT
- nodejs
- class-transformer
- 유데미
- corretto
- Redis
- Nestia
- Database
- Mocha
- 온라인강의
- Today
- Total
목록분류 전체보기 (26)
끄적끄적
최근에 타입스크립트 타입 챌린지 라는 것을 알게 되어 하루에 한두문제씩 계속 공부중이다. 하지만 실상 개발할 때는 어떻게 활용해야 할까 고민도 많고 익숙하지 않아서 쓰는데 어려움이 많았다. 그래서 어디 적용해보면서 공부를 해볼까 고민하던 중 이전에 블록체인 private key 를 추출하는 개발을 했었는데, 이 때 BIP44 Path 를 이상하게 입력하는 바람에 오랜 시간 삽질했던 경험이 떠올랐다. 그래서 이를 직접적인 타입으로 잡아볼까 해서 한번 만들어 보았다. 참고로 BIP44 에서 path 는 아래와 같은 형식을 정의하고 있다. # purpose 는 BIP44 에서는 44 로 고정한다. m / purpose' / coin_type' / account' / change / address_index 이..
한국에서 nestjs 로 개발하는 개발자라면 typia 에 대해서 한번쯤은 들어봤을 것 같다. 이 라이브러리에서 문제로 지적하는 부분이 nestjs 공식문서 예시로 제시하는 class-validator 가 성능적으로 문제가 크다는 것이다. 때문에 이러한 느린 라이브러리의 문제로 "typescript(javascript) 가 느리다" 라는 잘못된 인식까지 퍼질 수 있다고도 한다. 특히나 대부분의 nestjs 개발자라면 class-transformer + class-validator 기반으로 request 검증을 할테고, 객체 transform 액션에도 class-transformer 를 적극적으로 활용하고 있을 것이라 느리다는 인식이 더 커질 수 있을 것 같다. 여기서 성능이 느려지는 가장 큰 이유중 하나..
이전 포스팅에서 이더리움 dApp 개발을 위해 Truffle 과 Ganache 를 세팅해 보았었다. 물론 Truffle 의 경우 현재도 많은 회사에서 사용중이지만 최근 트랜드에서는 블록체인 개발자 대다수가 개발 환경으로 Hardhat 을 사용한다. 둘 다 npm 을 활용해서 설치하는데 기간을 길게 보아도 Hardhat 사용자 수가 Truffle 을 넘어선지는 꽤 오래되었다. 또한 필자의 회사에서도 현재는 Truffle 보다는 Hardhat 을 주로 사용하고 있다. 공식 문서를 확인해보면 Hardhat 을 아래와 같이 설명하고 있다. smart contract 와 dApp을 편집, 컴파일, 디버그, 배포하는 데 필요한 다양한 요소로 구성되어 있는 이더리움 소프트웨어 개발 환경이다. 결국에는 trffule..
운영중인 서비스에서 Dead Lock 이 발생한다는 알람을 받은 적이 있었다. 트래픽이 없을 때는 문제 없었는데 최근 이벤트를 진행하면서 순간 트래픽이 몰리다보니 Gap Lock 에 의해 Dead Lock 이 발생하면서 예상치 못한 에러가 발생한 것이였다. 그래서 Lock 에 대해 다시 한번 공부하는 기회가 되어서 이에 대한 간단한 이야기와 회사에서 실제로 Dead Lock 을 어떤 방법을 활용해서 해결했는지 예시와 함께 정리해볼까 한다. 포스팅은 MySQL(InnoDB) 기준으로 작성하였고 PostgreSQL 의 경우 Lock 방식이 다르므로 적용되지 않는 다는 점은 기억하면 좋겠다. 들어가기 전에 포스팅에서 예시를 들기 위해 아래 ERD 의 구조를 사용하려 한다. 채팅방과 유저가 존재하며, 채팅방 참..
웹 백앤드 어플리케이션 개발을 할 때 대부분의 서비스에서 여러 테이블의 join 은 필수적으로 일어난다. 그런데 많은 테이블들을 join 하면서 성능이 떨어지는 경우가 많이 생긴다. 이를 해결하기 위해 join 되는 컬럼에 인덱스를 건 뒤, 그 인덱스를 타게 하기 위한 수많은 쿼리 튜닝 작업을 진행하곤 한다. 하지만 쿼리 튜닝 작업 전에 가장 기본적으로 성능 향상을 시킬 수 있는 방법이 있는데 db side 에서 join 을 사용하는 것이 아닌 application side 에서 join 을 진행하는 것이다. 이번 포스팅에서는 실제로 db side join 을 application side join 으로 변경하면서 성능 향상을 한 경험에 대해서 이야기할 생각이다. 들어가기 전에 본문으로 들어가기 전에 포..
요즘 ChatGPT 에 대해서 시끌벅적하다. 특히나 최근에 Micorsoft 에서 copilot 을 단순한 개발이 아닌 ms office 에 적용하기도 하면서 업무에 직접적으로 영향을 주기 시작하고 있고 ChatGPT Api 대신 ChatGPT 플러그인이 나오면서 일반인도 충분히 사용 가능하도록 출시되었다. 즉, 이제는 실생활에 밀접하게 적용되고 있다고 생각해 볼 수 있다. 이렇게 AI 와 대화하고 여러 의견 및 정답을 얻어가는 과정을 프롬프트 엔지니어링이라고 하는데 개인적인 생각에 앞으로 프롬프트 엔지니어링이라는 말은 사라지고 업무를 할 때 자연스럽게 써야하는 미래가 올 것 같다. 비유해보자면 과거에 펜과 종이를 통해 업무를 보다가 지금에 와서는 워드 및 한글 등을 통해 모든 업무를 컴퓨터화해서 보고 ..
필자는 보통 Nestjs 로 개발하는데 대부분 아래와 같은 형식으로 로거를 주입시켜 개발한다. export class WithdrawCommandHandler { constructor( private readonly assetRepository: IAssetRepository, private readonly logger: ILogger, ) {} } 그런데 최근에 사이드 프로젝트를 spring 으로 개발하고 있는데 대부분의 로거를 아래와 같인 Slfj 의 어노테이션을 활용한다. 그리고 컴파일하면 static logger 를 사용하도록 코드가 쓰여져 있음을 확인할 수 있다. @Service @Slf4j public class WithdrawCommandHandler { private final AssetR..
백엔드에서 다른 팀에게 API 문서를 전달하는 방법에는 여러가지가 있다. Swagger 를 사용해서 문서를 전달할 수도 있고 Postman 을 이용해서 API 문서화를 시킬 수도 있다. 자바(스프링) 진영에서는 Rest Docs 와 같이 테스트 코드를 강제화 해서 문서를 만들어내는 방식이 유행하는 것 같다. 하지만 어떻게 문서를 넘기던지간에 프런트 입장에서는 백엔드가 만들어진 문서를 보고 API DTO 들을 다시 만들어 내는 과정이 필수적이며 여간 귀찮은 작업이 아니다. 그런데 우리 회사는 백엔드는 node.js(Nest.js), 프런트는 react-native & react 로 모든 개발 언어를 Typescript 로 맞춰서 개발중에 있다. 그래서 작년 초에 프런트 개발자가 이런 요구를 해왔다. 어차피..
왜 시작했는가? 나는 현재 개발자 N년차에 접어들고 있는 흔하디 흔한 개발자다. 개발 블로그를 써야지 써야지 하고 생각만 하고 따로 방치해 둔지 오래 된 것 같다. 분명 개발을 처음 시작할 시기에는 이것 저것 공부한 것들을 전부 요약해서 글로 정리하는 습관이 있었는데 연차가 쌓이면 쌓일수록, 시간이 부족하다는 이유로, 정리를 잘 안해왔던 것 같다는 생각이 들어 글또를 신청했다. 물론 글또는 이전부터 알고는 있었지만 매번 글쓰기가 귀찮아서 신청하지 않다가 이번에는 글쓰기를 제대로 해보자는 생각으로 지원해서 함께할 수 있게 되었다. 합격 후에 슬랙에 참여했는데 생각보다 더 많은 사람들이 참여하고 있어 열심히 사는 사람이 많다는 것을 깨닫고 한번 더 내 자신을 반성하는 시간을 가질 수도 있었다. 무엇을 쓰고 ..
필자는 회사에서 테라폼을 이용해서 AWS 관리를 하는데 backend 는 여러가지 이유 때문에 S3 + dynamodb 를 활용한다. 그런데 테라폼 클라우드를 활용하면 백앤드 관리를 더 편하게 할 수 있다는 이야기가 있어 이번에 사이드 프로젝트를 하면서 한번 써보고자 했다. 시작하기 테라폼 클라우드를 사용하는 방법은 오히려 S3 를 활용하는 것보다 쉽다. 우선 테라폼 클라우드 홈페이지로 가서 계정을 생성하자. 그러면 organization 을 만들라고 할 것이다. 사용할 프로젝트의 organization 을 만들어주자 이제 필요한 workspace 를 만들라고 한다. 이 workspace 가 테라폼에서 작성할 각각의 인프라가 될 것이다. 예시로 vpc 하나를 만드는 테라폼 workspace 를 만들어보자..