분류 전체보기

우아한 테크코스 2주차를 진행했다. 2주차는 이전주보다 설계의 비중이 높아진게 느껴졌다. 숫자야구 게임을 구현하는 문제였다. 입출력 2주차에는 입출력이 가장 난관이었다. 입출력에 사용하는 라이브러리인 MissionUtils의 Console은 nodeJs의 readline을 사용하여 구현되었는데, 이게 비동기로 작동한다. 내가 하고 싶었던 것은 입력 받은 값을 선언해서 이후 코드에서 사용할 수 있게 하는 것이었다. const input = MissionUtils.Console.readLine(질문내용,어쩌구저쩌구....); play(input); 이런식으로 이후 입력값을 계속해서 사용할 수 있게 하고 싶었다. MissionUtils.Console.readLine("question", (input)=>{ ...

try catch throw new Error를 통해 발생 시킨 예외는 catch를 통해서 처리될 수 있다. throw된 Error는 catch를 만날때 까지 함수 밖으로 던져진다. 만약 catch가 없다면 return되며 프로그램이 종료된다. 이걸 이해한다면, Error를 처리한 후의 동작도 조작할 수 있다. 아래와 같은 코드가 있다고하자. function getError(){ throw new Error("에러"); } function test(){ try{ getError(); }catch(err){ console.log(err); console.log("제대로 꺼짐요"); } } 이러면 Error가 throw된 후에 test함수에서 해당 Error를 잡아서 console로 찍은 후에 제대로 꺼짐요..

비동기의 동기처리와 프로미스 프로미스를 통해 비동기메서드는 동기메서드처럼 값을 반환 할 수 있게 된다. 프로미스 생성 프로미스가 이행되거나 거부될때(fulfilled, rejected), 이벤트 큐에 처리된 처리기들이 호출된다. 프로미스는 아래와 같이 객체 형태로 생성할 수 있다. const promise=new Promise(); 프로미스의 상태와 조작 Promise의 인자들을 통해 Promise의 상태를 바꿀 수 있다. 프로미스는 pending, fulfilled, rejected의 세가지 상태를 가진다. 일단 프로미스가 호출되면 프로미스는 Pending상태이다. new Promise의 인자로 resolve와 reject가 있는데, 이 두 함수를 통해 resolve를 실행하면 fulfilled가 되고..

우아한 테크코스 1주차를 진행했다. 사실 저번주에 진행했는데 회고 글을 적는게 늦어져서 지금 적는다. 1주차는 구현보다는 알고리즘 구현에 가까운 문제였다. 그러나 구현은 구현이기때문에, 제한사항에 있는 오류를 최대한 반영할 수 있도록 설계하였다. 설계 지금까지 코딩을 할때는 설계보다는 구현에 초점을 맞춰서 했던 것 같다. 그러나 프리코스를 진행하면서 기능명세를 적고 이를 기반으로 구현했기때문에 설계에 보다 집중 할 수 있었다. 물론, 처음에는 익숙하지가 않아서 다 짜놓고 기능명세를 적는 경우도 있었지만.... 시간이 지나며 점점 익숙해질 수 있었다. 설계를 하면서 가장 많이 고민했던 점은 OOP의 클래스 개념을 도입할 것이냐 였다. 그러나 해당 미션은 기능 구현의 변동 범위가 적은 편이며, 이후에 추가 ..

우리는 세상을 보는 관점을 만들어내고, 그것을 사회 구성원들과 나누고, 믿으며 사회의 규칙과 질서를 만들어간다. 서양에서 기독교가 질서의 확립에 큰 도움을 미쳤다면, 동양에서는 철학이 사회의 규칙과 질서를 만드는 데에 기초가 되었다. 유교 가장 널리 퍼진 유교는 기본적으로 사람은 A 하다. 그러므로 B 해야 한다는 구조로, 근거를 제시하고 이후 행동을 제시하였다. 이렇게 제시된 행동은 사회의 질서를 바로잡고, 평화와 화합을 가져오는 데에 기여했다. 그러나 시간이 흐르며, 유교의 “마음에서 나온 예”는 변질되어 탁상공론, 보이는 것만 중요한 예만이 중요해져 버렸다. 이렇게 변질된 문화를 바로 잡기 위해서는 유교에 대한 제대로 된 이해도 필요하겠지만, 이것이 결국은 하나의 관점이라는 것을 이해할 필요가 있다..

린스타트업 창업은 존재가 모호한 보물을 찾아나서는 것과 같다. 창업은 길을 잃고 헤매며 존재하지 않을지도 모르는 보물을 찾아나서는 것과 같다는 점을 알게되었다. 고객은 자신도 자신이 무엇을 원하는지 정확하게 알지 못한다. 따라서 정확한 기준과 데이터가 없이는 창업에서 만들어낸 가치가 실재하게 될지 아닐지 장담할 수 없다. 또한 찾아낸 보물이 자신이 원하지 않는 것일 수도 있다. 이전까지 창업은 내가 하고 싶은 것을 만들어 내는 것, 취업은 타인이 시킨 일을 하는 것 이라는 편견에 조금이나마 사로잡혀있었다. 그러나 창업은 내가 하고 싶은 것을 하는 게 아니다. 고객이 원하는 것을 찾아내어 발전시키는 것이 창업이다. 이런 관점에서 창업과 취업은 크게 다르지 않다. 기준 보물을 찾기 위해서는 내가 어디로 가고..

any 사용하기 가능한 좁은 범위에서 any 사용하기 function f1(){ const x:any = express(); processBar(x); } // 보다는 function f1(){ const x= express(); processBar(x as any); 함수의 반환타입은 정의되어야 함수 내부의 any가 밖으로 빠져나가지 않게 할 수 있다. 객체 내부의 타입오류는 해당 부분에서만 as any를 사용하여 해결하자! @ts-ignore //@ts-ignore를 사용하면 any를 사용하지 않고 해결이 가능함 any를 구체적으로 변형해서 사용하기 any타입을 그대로 정규식이나 함수에 넣는 것은 권장되지 않는다. function getLength(array:any){} // ===refactor f..

타입설계 문서에 타입정보 쓰지 않기 ⇒ 타입은 ts로만 표기 생성은 엄격하게, 사용은 너그럽게 매개변수 타입은 반환타입에 비해 범위가 넓은 경향이 있음 ⇒ 선택속성과 유니온타입 매개변수와 반환타입의 재사용을 위해 기본형태(반환타입)와 느슨한 형태(매개변수타입)을 준비하는 것이 좋음 타입 주변에 null값 배치하기 한 값의 null 여부가 다른 값의 null 여부에 암시적으로 관련되도록 설계하면 안됨 API작성시에는 반환타입을 큰 객체로 만들고 반환타입 자체가 null이거나 null이 아니도록 설계해야함 strictNullChecks → null오류를 정확하게 찾아냄 유니온의 인터페이스보다는 인터페이스의 유니온을 사용 interface Layer{ layout:FIllLayout|LineLayout|Poi..

타입추론 타입 추론이 된다면 명시적 타입 구문이 필요하지 않음 비구조화 할당문은 모든 지역변수의 타입이 추론되도록 함 interface Product={ id:string, name:string, price:number } function logProduct(product:Product){ const {id,name,price}=product; } ⇒ 따라서 타입 정보가 있는 라이브러리에서 콜백함수의 매개변수 타입은 자동으로 추론됨 잉여 속성 체크 타입에 선언된 속성 외에 속성이 있는지 체크함 객체 리터럴에서만 잉여속성 체크가 동작함 따라서 엄격한 객체 리터럴 체크라고도 한다. 함수의 반환에 타입 명시 ⇒ 함수의 반환에 타입을 명시하면, 오류가 정확하게 표기됨 linter의 no-inferrable-ty..

인간은 어떤 상황에서도 자기 행동의 선택권을 가질 수 있다. 수용소에서의 일화를 보면, 인간에게 모든 것을 빼앗아가도 단 한 가지, 마지막 남은 인간의 자유, 즉 주어진 환경에서 자신의 태도를 결정하고, 자기 자신의 길을 선택할 수 있는 자유만은 빼앗아 갈 수 없다는 것을 알 수 있다. 이는 의미를 부여할 수 있는 자유를 뺏을 수 없다는 말이다. 수용소에서 삶의 의미를 잃은 사람들은 빠르게 목숨을 잃어나갔다. 하지만, 의미를 가지고 끝까지 살아갔던 저자는 결국은 살아남았다. 우리는 항상 고민과 권태 사이를 무수히 왕래한다. 권태는 우리를 우울로 이끌고, 삶을 의미 없게 만든다. 저자는 이를 실존적 공허라고 말한다. 실존적 공허를 이겨내기 위해서는 추상적인 삶의 의미를 추구해서는 안된다고 한다. 나는 이것..