일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- class-transformer
- 블록체인
- nodejs
- corretto
- java
- Database
- 도서
- Mocha
- 리뷰
- ChatGPT
- mysql
- spring
- blockchain
- chai
- Redis
- gradle
- Nestia
- terraform cloud
- 온라인강의
- restdocs
- 백엔드
- terraform
- IAC
- nestjs
- 이더리움
- TypeScript
- 글또
- typeorm
- docker
- 유데미
- Today
- Total
목록분류 전체보기 (26)
끄적끄적
[컴퓨터 밑바닥의 비밀]개발자라면 CS 지식은 지속적해서 공부하는 것이 매우 중요하다고 생각한다. 특히나 컴퓨터 내부가 어떻게 돌아가는지를 이해해야 동시성과 같은 어려운 개발 상황에 처하게 되었을 때 문제 해결법에 대한 힌트를 쉽게 얻을 수 있을 것이다. 이 책은 제목 그대로 컴퓨터가 어떻게 돌아가는지에 대해서 설명해주는 책으로 개인적으로는 CS 관련 책 중 깊이도 있고 이해하기도 쉽게 적어놓은 것 같았다. 우선 번역이 깔끔하게 잘 되어있다는 점이 가장 큰 장점이 아닐까 싶다. 가끔 기술 번역서의 번역이 잘못되어 있을 때 책을 읽는 것 자체가 어려운 경우가 있는데 전부 다 읽었을 때도 그런 느낌은 전혀 들지 않았다. 특히 CS 관련된 책의 경우 아무래도 기술적인 내용이 많기 때문에 중간중간 툭툭 끊길 ..
[화이트 해킹 101: 윤리적 해킹 기초부터 배우기!] 개발할 때 반드시 적용해야 할 부분 중 하나가 시큐어 코딩이다. 물론 기본적인 옵션인 CORS, XSS 등을 구현하는 것은 어렵지 않지만, 이러한 해킹이 가능한 원리에 대해서 항상 궁금했었다. 이 Udemy 강의는 필자와 같이 해킹에 대해서 잘 알지 못하는 사람들이 처음 접해도 쉽게 따라갈 수 있도록 만든 기초강의이다. 물론 강의가 기초 강의임에도 시간이 상당히 길었기 때문에 가볍게 들으려고 했던 필자의 기대와는 달리, 강의를 듣는 데에는 꽤 많은 개인 시간이 필요했었다. 그러나 강의가 긴 만큼 이전에 들은 다른 강의와 비교했을 때 초보자가 듣기에는 더 적합한 강의라는 생각이 들었다. 강의는 초반에 실습환경을 구축하는 것부터 시작한다. 이때 설치해..
최근에 필자가 속해있는 회사에서 nestia 를 사용하도록 서버 리펙토링을 완료했다. 참고로 nestia 란 라이브러리는 Nestjs 를 조금 더 쉽게 쓸 수 있도록 해주며 성능적으로도 훨씬 빠르게 만들어 주는 라이브러리로, 한국에 있는 개발자 분이 개발한 멋진 라이브러리다. 이전 포스팅에서 nestia sdk 에 대해서 간단하게는 남겼지만 모노레포 지원이 잘 안되는 이슈로 이는 적용 못했지만 굳이 sdk 를 쓰지 않더라도 가독성 및 생산성 면에서 훨씬 좋아지는 경험을 했기에 이번에 포스팅을 남겨보고자 한다. DTO 를 Interface 로 변경 기존에 class-transformer, class-validator 를 활용했을 때의 코드를 우선 확인해보자. 아래 코드가 왜 나오는지 이해하기 위해서는 n..
[Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기] 개발할 때 자주 찾아보고 어려워하는 부분이 동시성과 병렬성 부분이다. 특히나 처음 개발을 접하는 사람들은 이 두 용어 자체를 헷갈려 할 정도이며 최근 트랜드는 하나의 서버가 아닌 scale out 을 통해 여러 서버를 사용하기도 한다. 물론 이 강의는 이 부분을 다룬 강의는 아니며 오로지 하나의 프로그램에서 Java Thread 사용법을 알려주는 강의 이다. 필자는 Typescript 를 메인 언어로 다루고 있어 정확히는 잘 모르지만, Java 를 사용하는 대부분의 개발자들은 이미 Spring (boot) 를 통해 추상화된 상태로 쓰레드를 사용하고 있기 때문에 Thread 를 다룰 일이 크게 없다고 생각할 수 있다. 그러나 Spring 을 ..
작년 초에 선착순 NFT 판매 이벤트를 개발해야 한 적이 있었다. 당시 선착순 이벤트의 경우 Redis 에서 분산락 알고리즘으로 제공하는 redlock 을 활용해서 개발하는 경우가 대부분이였으며 정보도 많았었다. 당연히 필자 또한 빠르게 개발하기 위해 이를 활용했었다. 그러나 이벤트가 종료된 후에는 선착순 판매가 아닌 단순히 상품(NFT)을 열어두고 판매하는 상황이 대부분이게 되었다. (사실 이벤트 때도 많은 인원수가 몰리지 않아 실망했던 기억이 있다.) 시간이 흐르면서 레디스 자체가 성능적으로 큰 필요가 없는 경우가 대부분이라는 사실을 알게 되어 쓸데 없는 비용을 줄이기 위한 작업을 진행하기로 했다. 요구사항 자체는 간단했다. 기존 비즈니스 로직은 건드리지 않을 것 언제든 선착순 이벤트로 바뀔 시 빠..
테스트를 하다보면 예외사항을 테스트해야 하는 경우가 자주 생긴다. 이 때 필자의 경우 어떻게 예외 테스트를 하고 있는지에 대해 이야기를 해보고자 한다. 이 포스팅에서는 커스텀한 에러를 던지고 있으며 그 형태는 아래와 같다고 가정하자. export class CustomError extends Error { name: string; message: string; code: string; stack?: string; constructor(code: string, message: string, name?: string, stack?: string) { super(message); this.name = name || code; this.message = message; this.code = code; if (..
이번 포스팅에서는 조금 오래된 개념인 Repository 패턴, 그 중에서 추상화에 대한 이야기를 해보고자 한다. 원래 이전부터 쓸까 했지만 이제는 많은 개발자들이 대부분 이 개념을 인지하고 있다고 생각해서 건너뛰었었다. 하지만 최근에 어떤 개발자와 이야기 할 때 아래와 같은 대화를 나눈적이 있었다. A : Nest에서 TypeOrm 0.2 에서 TypeOrm 0.3 으로 마이그레이션하기 어려워요. 필자 : 아 connection 이 datasource 로 바뀌어서 조금 달라지긴 했더라고요. A : 특히나 TypeOrm 0.2 @EntityRepository 가 삭제되어서 마이그레이션 할 때 고려할 부분이 많아요. 필자 : 혹시 TypeOrm 에서 제공하는 Repository 를 도메인에서 직접 사용해서..
백엔드를 개발하다보면 가장 흔하게 처리해야 하는 부분중 하나가 페이지네이션 부분이다. 그 중에서도 요즘에는 커서 기반의 페이지네이션 처리를 많이 수행하며 단순히 sequence 로만 처리하는 것이 아니라 여러 조건하에서 정렬할 필요가 있다. 그 때 커서 페이지네이션 처리를 하다보면 중복된 커서 데이터에 의해 특정 레코드를 건너띄는 경우가 자주 발생하며 이를 처리할 필요가 있다. 이번 포스팅에서는 이런 문제에 대한 예시와 해결방법들에 대해서 정리해볼 생각이다. 들어가기 전에 들어가기 전에 테스트를 할 테이블을 정의했다. 상품이라는 테이블이 있으며 seq 를 PK 로 가지고 있으며 price 와 created_at 을 인덱스로 가지면서 이를 활용해 상품을 최신순 혹은 가격순으로 정렬하고자 한다. 또한 테..
Nestjs 를 개발하다보면 custom parameter decorator 를 개발할 필요가 있다. 물론 공식 문서 예제로 주어지는 @User 와 같은 형태가 존재하고 이를 자주 사용하곤 하지만 Nest 문서에서 주어진 것만 가지고 개발하기에는 한계점이 존재한다. 그래서 이번 포스팅에서는 nestjs 에서 기본적으로 제공하는 함수를 활용하는 것이 아닌 메타데이터를 직접 사용해서 custom parameter decorator 를 만드는 작업을 진행해보도록 한다. Documentation | NestJS - A progressive Node.js framework Nest is a framework for building efficient, scalable Node.js server-side applic..
현재 회사의 대부분 서버는 Docker를 기반으로 배포되고 있다. 그런데 이 때 특정한 서버에서 배포 시마다 운영에는 문제 없는 에러 로그가 지속적으로 발생하는 이슈가 있었다. 물론 이 문제로 인해 다른 로직에 오류가 발생한 적은 없었기 때문에, 그 동안 다른 개발 작업에 집중하다가 최근에 조금 여유가 생겨 이 이슈를 조사해보기로 했다. 결론부터 이야기 하자면 문제의 원인은 docker stop 명령 실행 시 docker 는 컨테이너에 TERM signal (SIGTERM) 을 보내고 10 초 동안에도 종료되지 않았다면 Kill signal (SIGKILL) 을 보내 강제로 종료시키는 과정에서 발생했다. 컨테이너는 SIGTERM 시에 모든 리소스를 정리하고 종료되어야 하지만, DB 리소스는 정리되었으나 ..