Posts

요청 데이터의 Validation(타당성) 검사 Decorator로 요청 데이터 접근하기 HTTP 요청 3가지로 구성 Start line : POST /messages/5?validate=true HTTP/1.1 Headers : Host: localhost:3000, Content-Type: application/json Body : {"content": "hi there"} Nest의 경우 decorator 이용 POST /messages/5?validate=true HTTP/1.1 5 : @Param(‘id’) validate=true : @Query() Headers는 @Headers() Body 는 @Body() 위와 같이 decorator를 이용하면 된다. messages.controller.ts 의 컨트롤러를 다시 작성해 보자. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 // messages.controller.ts import { Controller, Get, Post, Body, Param } from '@nestjs/common'; @Controller('messages') // class decorator export class MessagesController { @Get() // method decorator listMessages() {} @Post() createMessage(@Body() body: any) { // @Body, @Param : argument decorator console.log(body); } @Get('/:id') getMessage(@Param('id') id: string) { console.log(id); } } 이제 API Client로 확인해보자. ...

Interfaces 속성 이름과 객체의 값의 type을 나타내는 새로운 type을 만드는 것 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 // 너무 긴 annotation const oldCivic = { name: 'civic', year: 2000, broken: true, }; const printVehicle = (vehicle: { name: string; year: number; broken: boolean; }): void => { console.log(`Name: ${vehicle.name}`); console.log(`Year: ${vehicle.year}`); console.log(`Broken? ${vehicle.broken}`); }; printVehicle(oldCivic); 인터페이스를 통해 간편하게 할 수 있다. ...

Class 클래스 : 어떤 ‘것’을 나타내는 필드(값)와 메서드(함수)를 가지는 객체를 만들기 위한 청사진 정의 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // 1) class 정의 class Vehicle { drive(): void { console.log('yeeeees'); } honk(): void { console.log('liverpool'); } } const vehicle = new Vehicle(); vehicle.drive(); vehicle.honk(); // 출력결과 // yeeeees // liverpool extends 다른 클래스의 메서드를 가져온다. ...

Type 정의 타입은 value가 가진 다양한 속성,메서드를 지칭하는 지름길이라고 볼 수 있다. 함수로서의 타입, 클래스로서의 타입 등등 이 있다. variable(변수) : string, number, boolean, null, undefined, object, function, array 등등.. “red” 를 보면 string 이다. string이 가진 모든 개체와 method들 이다. 두 방법으로 대답할 수 있다. 예를 들어, string은 charAt(), indexOf() 등 다양한 method를 가진다. 이걸 매번 다 설명하지 않고 모두를 통칭하기 위한 것이 Type 이다. 따라서 Type은 하나의 값이 가지는 다양한 속성과 메소드를 지칭하기 위한 지름길인 것이다. ...

Typescript 개념 Typescript = Javascript + A type system 이다. TS Type System의 특징은 다음과 같다. 개발 중 에러 포착 가능 type annotation 개발중에만 active된다 성능 최적화 없음 TS를 작성하지만 실제론 컴파일러에선 JS를 실행하는 것이다! 자세히 말하자면, 사실 JS를 작성하고 Type annotiation 추가하는 것이 TS를 작성하는 것. 이 과정을 풀어서 설명하자면 Typescript code = Javascript with type annotations -> Typescript Compiler -> Plain old Javascript 인 것이다. json 데이터 받아오기 교육용 Json 사이트 를 접속해서 밑의 resource에 todo를 들어가보자 ...

Arrays in Typescript Typed Arrays : 원소들이 동일한 타입의 값인 것 annotation 없어도 존재하는 원소들을 보고 inference 한다. 빈 배열은 inference할 수 없으므로 any타입이 된다. 1 2 3 4 5 6 7 8 // type annotation const carMarkers: string[] = ['ford', 'toyota', 'chevy']; // Date[] 타입으로 inference const dates = [new Date(), new Date()]; // 2차원. string[][] type이다. const carsByMake = [['f150'], ['corolla'], ['camaro']]; 특징 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // 배열에서 추출시 type inference 한다. const car = carMakers[0]; // string type const myCar = carMakers.pop(); // string type // 배열에 동일하지 않은 type의 값은 추가할 수 없다. carMakers.push(100); // string[]에 number를 넣으면 오류 발생 // 'map, 'forEach', 'reduce' 사용 carMakers.map((car: string): string => { return car.toUpeerCase(); }); // 다수의 type 사용. // const importantDates: (string | Date)[]로 inference 된다. const importantDates = [new Date(), '2030-10-10']; // annotation const importanteDates: (Date | string)[] = [new Date()]; Tuple 각 원소가 기록의 속성을 나타내는 배열과 같은 구조 ...

주간기록 날짜 2023년 9월 25일 ~ 2023년 10월 01일 계획 책너두 : 클린코드, Real MySQL 8.0 1권, 코딩 인터뷰 완전정복 매일 알고리즘 3문제 9월 27일 : 알고리즘 스터디 9월 30일 : 코딩 테스트 10월 1일 : 48시간 과제 테스트 결과 책너두 5기 클린코드 종료 회고 자소서 지옥 끝나니 코테, 인적성 지옥 몰려온다. 심화 데브캠프 열심히 해보자.

책너두 6기 24일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.247 ~ p.257 내용정리 08 인덱스 8.3.7 B-Tree 인덱스의 가용성과 효율성 쿼리의 where 조건이나 group by, 또는 order by 절이 어떤 경우에 인덱슬르 사용할 수 있고 어떤 방식으로 사용할 수 있는지 식별할 수 있어야 한다. 8.3.7.1 비교 조건의 종류와 효율성 다중 칼럼 인덱스에서 각 칼럼의 순서와 그 칼럼에 사용된 조건이 동등 비교("=")인지 아니면 크다(">") 또는 작다("<") 같은 범위 조건인지에 따라 각 인덱스의 칼럼의 활용 형태가 달라지며, 그 효율 또한 달라진다. ...

책너두 5기 48일차 로버트 C. 마틴의 클린코드 p. 437~ p.446 내용정리 부록 A 동시성 2 다중 스레드 코드 테스트 변수의 현재 값을 기억한다. 스레두 두 개를 새엉하여 각 스레드가 해당 변수에 관한 메서드를 호출한다. 의도에 맞게 값이 변경되었는지 확인한다. 의도와 다르게 변한것이 확인될 때까지 반복한다. 위와 같은 테스트는 아주 드물게 문제가 발생하기 때문에, 일억 번은 돌려야 한다. 따라서 많은 시간이 소모된다. 이를 대체하기 위한 방법들은 다음과 같다. 몬테 카를로 테스트 ...

책너두 6기 23일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.237 ~ p.246 내용정리 08 인덱스 8.3.4.4 인덱스 스킵 스캔 데이터베이스 서버에서 인덱스의 핵심은 값이 정렬돼 있다는 것이며, 이로 인해 인덱스를 구성하는 칼럼의 순서가 매우 중요하다. 기존에 루스 인덱스 스캔이 비슷한 최적화를 수행했지만 새로 도입된 인덱스 스킵 스캔은 용도가 훨씬 넒어졌다. 단점 Where 조건절에 조건이 없는 인덱스의 선행 칼럼의 유니크한 값의 개수가 적어야 함 : 개수가 많으면 인덱스에서 스캔해야 할 시작 지점을 검색하는 작업이 많이 필요해져 쿼리의 처리 성능이 오히려 더 느려질 수 있다. 쿼리가 인덱스에 존재하는 칼럼만으로 처리 가능해야 함(커버링 인덱스) : 이후 버전에서 개선될 것으로 보임 8.3.5 다중 칼럼(Multi-column)인덱스 현재 까지는 1개의 칼럼만 포함된 인덱스 두 개 이상의 칼럼으로 구성된 인덱스를 다중 칼럼 인덱스(복합 칼럼 인덱스)나 “Concatenated Index"라고 함 다중 칼럼 인덱스에서는 인덱스 내에서 각 칼럼의 위치(순서)가 상당히 중요하다. 8.3.6 B-Tree 인덱스의 정렬 및 스캔 방향 인덱스의 키 값은 항상 오름차순이거나 내림차순으로만 정렬되어 저장된다. 8.3.6.1 인덱스의 정렬 인덱스를 생성하는 시점에 인덱스를 구성하는 각 칼럼의 정렬을 오름차순 / 내림차순 으로 설정 가능 정렬 순서를 혼합할 수 있음. 8.3.6.1.1 인덱스 스캔 방향 인덱스 생성 시점에 오름차순 또는 내림차순으로 정렬이 결정되지만 쿼리가 그 인덱스를 사용하는 시점에 인덱스를 읽는 방향에 따라 오름차순 또는 내림차순 정렬 효과를 얻을 수 있다. 8.3.6.1.2 내림차순 인덱스 인덱스 역순 스캔이 인덱스 정순 스캔에 비해 느리다. 인덱스를 내림차순 정렬하는 쿼리가 소량의 레코드에 드물게 실행되는 경우라면 내림차순 인덱스를 굳이 고려할 필요는 없다. 많은 레코드를 조회하면서 빈번하게 실행된다면 내림차순 인덱스가 더 효율적일 수도 있다. 많은 쿼리가 인덱스의 앞쪽만 또는 뒤쪽만 집중적으로 읽어서 인덱스의 특정 페이지 잠금에서 병목이 예상된다면 쿼리에서 자주 사용되는 정렬 순서대로 인덱스를 생성하는 것이 잠금 병목 현상을 완화하는데 도움이 된다.