읽기전

  • 데이터를 많이 들여다 보려고 노력하고 있는데, 이거 참 기본이 있어야지...

  • 특히 데이터를 어떻게 들여다 볼 것인가? 에 대한 고민이 필요해서 구매 한 책.

  • 기존 딥러닝 책들은, 이미 잘 정제 되어 있거나, 필요한 값들을 이미 선별해 둔 책이 많다.

  • 하지만, 실제 데이터들은 잘 정제되어 있지도, 어떠한 값을 딥러닝에 넣어야 할지도 모르니....

  • 에라, 모르겠다. 걍 딥러닝에 다 때려 박으면 되지 싶다가도,

    • 그래도 기본은 알아야지.
    • 필요한 것만 때려 박으면 더 잘 되겠지.
  • 싶어서 구매한 책

  • 이 책에 있는 대부분의 예제는 전체 소스코드가 나와 있지 않고, 설명이 생략 된 것도 꽤나 된다.

  • 그러므로 초보자가 읽기에 적당하지 않은듯 하다.

책 읽기

서문

옮긴이의 말

  • 하지만 너무나 다양한 데이터의 종류가 특성에 따라 경험적으로 수행돼 왔을 뿐, 이를 범용적으로 적용하는 방법에 대한 책이나 논문이 거의 없었다.
  • 머신 러닝 입문자들에게는 피처 엔지니어링에 대한 원리를 배우고 실습을 통해 실력을 높일 수 있는 좋은 기회가 될 것이며, 데이터 과학에 종사하는 분들에게는 그동안 경험적으로 수행해 오던 피처 엔지니어링 기법들을 암묵지에서 형식지로 정리하는 계기가 될 것이다.

들어가며

  • 모델은 피처(feature)를 입력으로 사용한다. 피처는 원시 데이터의 숫자적인 표현이다..
  • 피처 엔지니어링은 원시 데이터로부터 피처를 추출하고 이를 머신 러닝 모델에 적합한 형식으로 변환하는 작업이다.
  • 데이터와 모델은 매우 다양하기 때문에 피처 엔지니어링 방법으로 일반화 하기 어렵다.

1장 머신 러닝 파이프라인

데이터

  • 데이터, 모델, 피처, 모델 평가
    • 실제 세계의 현상에 대한 관측 결과
    • 데이터의 각 조각은 현실의 제한된 한 측면에 대한 창을 제공
    • 원시 데이터는 숫자가 아닌 경우가 많다. ( 앨리스가 수요일에 책을 샀다. )
    • 피처는 원시 데이터의 숫자적인 표현이다.
    • 우리가 해결하고자 과제에 적합한 모델에, 잘 들어 맞는 피처를 만들어야 한다.
    • 피처가 적으면 제대로 과제를 수행하지 못하고, 피처가 많아도 필요 없는 피처로 인해 모델의 학습에 많은 비용과 어려움이 있을 수 있다.
  • 원본 소스가 통찰력까지 가기는...
    • 소스 ->(추출 및 통합)-> 원시 데이터 -> (정제 및 변환) -> 피처 -> 모델링 -> 통찰력
    • 여기서 "정제 및 변환" 부분이 피처 엔지니어링 부분이다.

2장 숫자를 위한 멋진 트릭

  • 이미 숫자는 수학적 모델로 처리하기 쉬운 형식.
  • 하지만 좋은 피처는 데이터를 가장 두드러진 특징을 표현할 뿐만 아니라, 모델의 가정에도 맞아야 한다. 그러므로 피처 엔지니어링이 필요.
  • 고려사항
    • 값의 크기 : 양수? 음수?, 구간을 나눠야하나? 숫자가 누적되나?
    • 스케일 : 가장 큰 값, 가장 작은 값, 둘의 차이가 몇자리 수. 출력 값이 커질 수 있나? 출력값이 바이너리면?
    • 숫자 피처의 분포
    • 여러 피처를 조합해 더 복잡한 피처를 만들 수도 있음

스칼라, 벡터, 공간

  • 스칼라(scalar) : 단일 숫자 피처
  • 벡터(vector) : 방향이 있는 스칼라의 리스트, 벡터는 벡터공간내에 위치.
  • 벡터는 공간상의 한 점( 종종 원점에서 그 점까지의 선이나 화살표로 그린다. )

카운트 처리

  • 노래나 영화를 플레이 한 횟수 등 이런 카운트
  • 누군가가 조작하기가 쉬우므로, 그래도 사용할지, 존재 여부만 처리 할지, 몇개의 구간으로 나눌지 등을 고민해야 한다.

바이너리 변환

  • '견고한 척도'(통계 용어에서 "견고함"은 해당 기업이 매우 다양한 조건하에서도 잘 작동함을 말한다. 라는 말이 있는데.. 이걸 이쪽 세상에서는 로버스터(robust)라는 용어를 훨씬 더 많이 사용한다.
  • 데이터의 값이 너무 많이 차이가 나면, 그냥 1 과 0 으로 나눠 주는것도 가능하다.

양자화 또는 비닝

  • 비닝(binning)은 구간화 정도로 생각하면 되겠다.
  • 양자화랑 비슷한 듯.
  • 쉽게 말하면, 값을 구간을 두고 정리 한다는것. ( 10대, 20대, 30대 등 )
  • 고정폭 비닝
    • 나이를 가지고 할 것이라면, 10대, 20대로 할 수도 있지만, 삶의 단계에 맞게, 초등학교, 중학교, 고등학교, 대학교의 나이로 나누는것이 더 좋을 수도 있다.
    • 여러 자리수라면, 0 ~ 9, 10 ~ 100, 100 ~ 1000 등으로 나눌 수도 있다.
  • 분위수(quantile) 비닝
    • 그냥 고정폭 비닝은, 중간에 빈 값이 많으면 데이터가 없는 구간이 너무 많다.
    • 걍 전체 값의 1/2이나 1.4 단위, 혹은 1/10 단위로 나눠서 배치한다.

로그 변환

  • 작은 숫자가 많고, 큰 숫자가 듬성 듬성 적게 데이터가 존재한다면, 작은 숫자들을 좀 더 잘게 쪼개야 하고, 큰 숫자를 좀 더 모아줘야 한다.
  • 이럴때는 로그 변환을 사용하면 된다.
  • log10(x) 는
    • 1 ~ 10 사이의 숫자를 0 ~ 1 사이로 배치
    • 10 ~ 100 사이의 숫자를 1 ~ 2 사이로 배치
    • 100 ~ 1000 사이의 숫자를 2 ~ 3 사이로 배치 할 수 있다.
  • 즉, 큰 수의 변화량을 작은 변화량으로 바꿀 수 있어, 상대적으로 작은 숫자의 변화량을 더 잘 표현할 수 있게 된다.
  • 뒤에 Box-Cox 라는것도 나오는데, 잘 모르겠지만, 결국 데이터를 잘 분산한다는것에 목적이 있는 듯 하다.

피처 스케일링 또는 정규화

  • 위도나 경도는 피처의 숫자 값에 한계가 있음. 하지만 카운트는 한계가 없음.
  • 모델이 입력 피처의 스케일링(값 범위)에 민감하다면, 피처를 적절히 스케일링 해 주어야 한다.
  • 이걸 피처 스케일링, 혹은 피처 정규화(normalizataion)이라고 부른다.

min-max 스케일링

  • 제일 작은 값을 0, 제일 큰 값을 1로 변환
  • min-max scailing

표준화(분산 스케일링)

  • 피처 표준화(standardization) : 모든 데이터 포인트에 대한 피처의 평균을 빼고 분산으로 나눈다.
  • 그래서 분산 스케일링이라고도 부름
  • 스케일링된 피처의 결과는 평균이 0, 분산이 1
  • 즉 0을 중심으로 좌우로 적절히 데이터를 배치한다.

l2 정규화

  • 원본 피처 값을 유클리드 노름(norm)으로 불리는 l2 노름으로 정규화한다.(나눈다)
  • 원본 값 / (모든 데이터에 제곱을 한 뒤, 이를 모두 더하고, 다시 제급근(루트)를 씌워 준다.)
  • 자세한건 나도 모르니깐 통과.
  • 이상과 같은 피처스케일링은, 피처의 분포의 모양을 바꾸지는 않는다. 다만 분포에 대한 스케일만 변경한다.
  • 예를들면 원본 데이터를 이용해서 만든 그래프와, min-max를 이용해서 만들어진 그래프의 모양은 동일하다. 다만, 피처의 스케일만 달라져 있는 것이다.
  • 입력 피처들의 기준이 다를때는 비슷하게 만들어 주는것이 좋다. 방문자 수가 100만명 단위인데, 구매자 수가 100명 단위라면, 균형을 맞춰줄 필요가 있다.
  • 그렇지 않으면 모델 학습 알고리즘에서 수치 안정성 문제를 일으킬 수 있다.

상호작용 피처

  • 한개의 피처만을 사용하는것이 아니라, 두개의 피처를 모두 사용하는 방법.
  • 예를들면, "서울"에서 "30대" 같은것.
  • 고객의 위치만으로 예측하는것, 혹은 고객의 나이만으로 예측하는것 보다는, 둘 다의 값으로 예측하는것이 더 정확
  • 하지만, 더 복잡한 계산이 필요. 어떤 피처들 선택할 것인가도 문제.

피처 선택

  • 필요 없는 피처는 제거하는것이 모델의 복잡성을 줄일 수 있음.
  • 그러면 정확도는 거의 저하시키지 않고, 빠르게 연산 할 수 있을 것임.
  • 어느 피처가 중요한지 알아 내기 위해서, 오히려 전체 학습 시간이 오래 걸릴 수도 있음.

필터링

  • 피처와 목표 변수 사이의 상관관계, 상호 정보량등을 계산해 크게 영향을 미치지 않는것을 걍 제거.
  • 쉽게 할 수 있지만, 내가 필터링 할 피처를 잘못 선택할 수도 있다.
  • 아예 해당 데이터를 사용하지 않을 것이므로, 유용한 필터를 제거 할 수 있으므로, 보수적으로 선택해야 한다.

레퍼메소드

  • 비용은 많이 들지만, 피처의 하위 집합을 시험해 볼 수 있도록 해 줌.
  • 정보량이 많지 않을 수도 있지만, 조합했을 경우 유용한 것일 수 있으므로 실수를 방지 해 줌.

내장 메소드

  • 모델 학습 과정의 일부로서 피처 선택을 수행
  • 의사결정트리는 각 학습 단계에서 트리를 분할하기 위한 피처를 선택하게 되어 있음.
  • 선형 모델 학습에 사용하는 l1 정규화도, 모델 학습 과정의 일부로 피처를 선택하게 되어 있음.
  • 레퍼메소드 방식보다 강력하지 않지만, 비용이 절감
  • 필터링과 비교 했을 때 보다는 모델에 적합한 피쳐를 선택,
  • 필터링과, 내장 메소드 사이의 적절한 균현을 이룸
  • 이 책의 설명 범위가 벗어난다면서, 여기에 대한 설명을 다른곳을 찾아 보라고 함.

요약

  • 일반적인 숫자 피처에 대한 피처 엔지니어링을 설명
  • 통계적인 머신러닝에서 모든 데이터는 결국 숫자 피처로 귀결
  • 결국 몇가지 숫자 피처 엔지니어링 기법이 필요

3장 텍스트 데이터: 플래트닝, 필터링, 청킹

  • 문장이 있다면, 어느 부분을 추출해야 하나?
  • 단어 카운트 총계를 기초로 하는 가장 단순한 표현인 BoW
  • 텍스트와 매우 깊은 연관이 있는 변환 tf-idf

bag-of-x: 자연어 텍스트를 평면 벡터로 변환

  • 결과가 단순하고 해석 가능할때가 가장 좋음, 단순해야 시도해 보기 좋고, 디버깅이 쉽다.
  • 우선 단순하게 시작하고, 필요한 경우 복잡성을 더하도록 하자.
  • 문서를 분류하는 작업은 종종 단어 카운트 통계만으로도 충분함.
  • 특정 단어의 존재 유무가 문서의 주제를 잘 나타내는 지표가 됨.

BoW

  • Bag of word
  • 단어별 단어가 노출되는 갯수를 테이블로 만든것.
  • 이러한 단어별 카운트의 분포에 따라서 문서가 어떠한 특징을 가지는지 알 수 있다.
  • 텍스트는 원래 플랫(flat)한 구조이나, BoW는 단어가 몇번 나오는지만 저장해 둔다.
  • 텍스트는 순서(Sequance)를 가지나, BoW는 순서도 없다. 단어별 계층 구조도 없다.
  • 오직 등장한 횟수만...
  • 이렇게 단어와 등장 횟수를 피처를 만들고, 어떠한 문장을 분석해 보도록 하자.
  • 각 단어가 1개의 차원이 된다. 등장 횟수가 해당 피처의 값이 된다.
    • 특정 문장에서 cute라는 단어와 puppy라는 단어가 각각 몇번 나왔는지를 x, y로 두면 그 문장이 2차원의 어느 위치에 있는지 알 수 있다.
    • 특정 문장에서 cute, puppy, extremely 이라는 단어가 각 몇 번 나왔는지를 x, y, z로 두면 그 문장이 3차원에서 어느 위치에 있는지 알 수 있다.
    • 각 단어와 등장한 횟수가 피처가 되고, 문장이 어느 위치에 있는지 알 수 있다.
  • 반대로 각 문장 자체를 피처로 두고, 단어들을 배치해 볼 수도 있을 것이다. 이러한 것은 bag-of-documents 라고 한다. ( 자세한건 4장에 설명 된다고... )
  • BoW는 문장을 단어로 분해 할 때 의미가 파괴 될 수 있다. not bad의 경우 '나쁘지 않다.'라는 뜻인데, 분해를 해 버리면 둘다 나쁘다라는 의미를 표현하게 된다.
  • 이러한 문제를 일부 해결 하기 위해 bag-of-n-grams를 사용한다.
  • BoW는 유용한 경험적 방법이지만, 텍스트의 정확한 의미를 파악하는것과는 거리가 멀다.

bag-of-n-grams

  • BoW는 단어 당 하는건데, 여기는 n개의 연속된 단어로 하는거다. 1개로 되어 있으면, 1-gram, unigram 이다.
  • 중첩된 시퀀스를 n-gram이라고...
  • "Emma knocked on the door'를 2-gram으로 나타내면
    • Emma knocked
    • knocked on
    • on the
    • the door
  • 로 나타낼 수 있다.
  • 하지만 당연히 BoW 보다 훨씬 더 많은 피처 갯수가 생긴다.

정제된 피처를 위한 필터링

  • 단어를 사용할 때는 필요한 정보(시그널)과 노이즈(필요 없는 정보)를 분리해야 함.

불용어

  • 분류와 검색은 텍스트이 대한 깊은 이해를 요구하지 않음(의미까지 명확하게 파악하지 않아도 된다는 뜻일까?)
  • 분류와 같은 섬세하지 않은 작업에서 대명사, 관사, 전치사의 가치는 그다지 크지 않다.
  • 하지만 섬세한 의미론적 이해를 요구하는 감성 분석에서는 매우 다를 수 있다.
  • 영어의 불용어 리스트는, 파이썬 NLP 패키지인 NLTK에 수 많은 언어에 대해 불용어 리스트를 가지고 있다.

빈도 기반 필터링

  • 얼마나 단어가 나오는지를 확인하면, 상용어를 필터링 하기 쉽다.
  • 빈출 단어
    • 또한 단어가 너무 많이 나와도 의미를 파악하기 어려울 수 있다.
    • 의사 회의록은 'House of Commons(하원)'이라는 단어가 많이 나와서 house라는 단어가 너무 많이 나옴.
    • 이를 어떻게 처리 할 것인가를 정하는게 어렵다. 또한 얼마나 많이 등장 할 때만 의미를 부여/제거 할 것인가? 를 정하는것도 쉽지는 않다.
  • 희귀 단어
    • 잘 알려있지 않은 단어거나, 철자가 틀린 것일 수도 있음.
    • 통계적인 모델에서는, 한 두번 나오는건 잡음(노이즈-noise)에 가깝다.
    • 아주 적은 횟수가 등장하는 단어 때문에, 분류를 잘못 할 수도 있다.
    • 또한, 이러한 단어들을 모두 포함해서 연산을 하게 되면 필요 없는 계산을 많이 해야 한다.
    • 책에서 설명하는 Yelp 데이터 160만개 리뷰는 35만개의 고유 단어가 포함되어 있고, 약 23만개의 단어가 1개 혹은 2개의 리뷰에서만 나온다. 즉, 60%의 단어가 크게 의미를 가지지 않을 수도 있다는 뜻이다.
    • 이러한 피처를 모두 모델을 만들때 추가하게 되면, 계산 비용과 저장 비용이 많이 들게 된다. 그러므로 이러한 단어들을 적절히 제거해 주어야 한다.
    • 텍스트의 문장이 매우 짧은 경우, 통계적 의미를 찾기 어려울 수 있기 때문에, 이러한 문장을 제외해야 할 수도 있다. 하지만 트위터는 짧은 문장만을 가질 수 있으므로, 다른 방식의 기법을 사용해야 한다.
  • 어간 추출
    • 어간(語幹) : 활용어의 활용에서 변하지 않는 부분. '읽는다, 읽느냐, 읽고…' 등에서의 '읽'. 어간에 어미 '-다'를 붙인 것을 기본형이라고 하여 사전의 표제어로 올림. 줄기.
    • 단어를 공백이나 구둣점으로 잘라서 세면, 같은 의미를 가진 단어를 모두 따로 카운트 하게 된다. 'swin', 'swinging'은 의미가 비슷하지만 서로 다르다고 카운트 된다.
    • 통계적인 데이터로 처리 할 때에는 어간(stem)을 추출해서 단어의 기본형으로 변환하여 저장하는것이 좋은 경우가 많다.
    • 하지만, news 와 new는 전혀 다른 의미를 가지지만, 같은 new로 어간 추출이 될 수도 있다. 그러므로 항상 어간 추출을 사용해야 한다는것은 아님을 명심하자.

의미의 단위: n-grams에서 구문까지

파싱과 토큰화

  • 문자열에 의미가 있는 텍스트가 아닌게 많다.
  • 또한, 의미를 구분해 주는것도 있을 것이다. 이메일의 from, to 등.
  • 단어를 쪼갤때, 공백, 구둣점 등으로 나누면 된다.
  • n-grams으로 n개를 쪼갤때는, 문서가 아니라 "문장" 단위로 되어야 한다.
  • 즉, 마침표가 있으면 n-grams를 늘리면 안된다.
  • 하지만, word2vec 과 같이 복잡한 것을 할 때는, 단락에 적용할 수도 있다.
  • 암튼, 그냥 상황에 따라서 잘 나눠서 하면 된다는것 같다.

구문 탐색을 위한 연어 추출

  • 연어. 연달아 적힌 단어가 의미를 가질 수 있다.
  • strong tea는 "진한 차" 인데, 두 단어를 쪼개면, "물리력이 강하다"와 "차"로 나눠진다. 그러므로 의미가 달라진다. 이러한것을 연어라고 한다.
  • 'cute puppy'는 'cute'와 'puppy'의 의미를 합쳤을때 동일한 의미를 가진다. 이런건 연어가 아님.
  • 연어가 꼭 연속되어 나오라는 법도 없고, 모든 연속된 단어가 연어라는 법도 없다.
  • 그래서 너무 어려움. 통계적인 기법을 사용한다.
빈도 기반 방법
  • 많이 나타나는 n-grams을 보는 법. bigrams등의 빈도수를 실제로 확인해 보고, 의미 있는것을 찾을 수 있다.
연어 추출을 위한 가설 검증
  • 책에 나오는 복잡한 내용은 생략...
청킹과 품사 태깅
  • 주제를 찾는 경우에는 명사에 가장 관심이 있을 수 있음.
  • 즉, 품사를 찾아야 함.
  • 걍 형태소 분석을 한다는것으로 보인다. 통과. ㅋㅋㅋ

요약

  • Bag of Word
    • BoW, 단어를 하나씩 Bag에 넣는것
    • 단순 검색에는 좋으나, 문맥이 유지 되지 않아 의미를 파악하기 어려움
  • Bag of n grams
    • n-gram을 Bag에 넣는것, 연속된 단어를 n개 조합해서 저장
    • 하지만 연속된 단어 n개의 조합이 너무 많아서 데이터 양이 너무 많음
    • 데이터 양이 많다면, 의미를 가지는 데이터를 더 찾기 어려울 수 있다.
  • 연어(구문, 상용구) 추출
    • 연속된 구문을 보고 의미가 있고, 없는 것들을 통계적으로 추출할 수 있다.
  • 이 장에서 설명한 문장을 처리하는 방법은, 문장을 쪼개 단어의 bag으로 만들게 된다. 그러므로 이러한 방식으로는 문장의 의미를 구체적으로 파악하기는 어렵다.

4장 피처 스케일링의 효과: BoW에서 tf-idf로

  • BoW 는 필요 없는 단어들이 강조 될 수 있다. "is", "the", "and" 는 문장에서 너무 많이 나올 것이다.
  • 하지만, 문장에서 "happy", "gloomy" 등은 자주 등장하지는 않지만, 문장의 의미를 잘 표현한다. 이러한 것들을 잘 찾아 주는 방법을 찾아야 한다.

tf-idf: BoW 비틀기

  • tf-idf : term frequency-inverse document frequency
  • tf-idf : 용어 빈도 - 역 문서 빈도
    • 각 단어의 카운트를 해당 단어가 나타나는 문서의 수로 나눈 정규화 카운트
    • (하나의 문서에서 해당 단어 카운트)*log((전체 문서 수)/(해당 단어가 나타나는 문서의 수))
    • 전체 문서가 5개 일때, 모든 문서에 'is'가 들어간다고 하면 위 공식의 뒷 부분이 log(5/5) = log(1) = 0이다. 그러므로 위의 공식의 결과는 0 이다.
    • 'is'는 tf-idf 를 이용해서 처리하면 0이 된다. 즉, 모든 문서에 나오는 단어의 의미를 제거할 수 있다.

tf-idf 테스트

  • 자세한 내용은 생략
  • 학습을 시킬때, 데이터 카테고리별 갯수가 차이가 많이 나면 당연히 결과가 좋지 않을 것이다. 그러므로 데이터 카테고리별 갯수를 세고, 작은 쪽에 맞춰 주어야 한다.
  • 테스트셋에 트레이닝셋에 존재하지 않는 정보가 있다면, 당연히 테스트셋의 결과를 제대로 확인 할 수 없을 것이다.
  • 충분히 많은 양의 데이터라면, 테스트셋에만 존재하는 데이터는 "희귀"한 데이터 일 수도 있다. 그러므로 이때는 "그냥 무시"하는 방법을 써도 되는지 검토해 볼 필요가 있다.
  • 이 장에는... 머신러닝 관련되는 이런저런 이야기가 나온다. 난 걍 통과.

심층 분석: 무슨 일이 일어나고 있는가?

  • 생략

요약

  • 피처 스케일링을 통해 정보가 많은 단어는 강조되고, 상용어는 가중치가 낮아진다.

5장 범주형 변수: 로봇닭 시대에 달걀 개수 세기

  • 범주형 변수(categorycal variable)
  • 카테고리나 레이블(label)을 나타내는 방법
  • 범주형인지 아닌지 알아 내는건 쉬움. 연속적인지 아닌지를 판단하면 됨.
    • 주가 10달러와 15달러는 연속적인 값.
    • "정치", "경제", "사회"는 연속적이지 않은 값.
  • 문서 코퍼스(corpus)의 어휘도 각 단어가 구분되므로 커다란 범주형이라고 볼 수 있음.
  • 하지만 같은 단어가 여러번 나타날 수도 있으니, 이를 카운팅 할 수 있음.

범주형 변수 인코딩

  • 범주는 일반적으로 숫자가 아님. 예를 들면 "빨간색","검은색","파란색" 등이다.
  • 제일 쉬운 방법은 숫자를 1씩 증가시키면서 매길 수 있을 거다. 하지만, 이렇게 하면 값의 크기가 의미가 생길 수 있다. 그러므로 다른 방법을 찾아 보자.

원-핫 인코딩

  • 00001000, 1000000, 00100000 와 같이 여러개 중에 한개만 켜지는거(아니깐 생략)

더미 코딩

  • 원-핫 인코딩은 1개는 무조건 1이어야 하나, 더미 코딩은 모두 0 인게 있음.
  • 모두 0 인게 기준 범주.(기준 범주와 다른 애들과의 차이를 쉽게 볼 수 있다.)

이펙트 코딩

  • 더미 코딩의 모두 0 인것이, 모두 -1로 되는 것
  • 뭔 말인지 모르겠으니깐 통과. ㅎ.

범주형 변수 인코딩의 장단점

  • 원-핫 인코딩, 더미 코딩, 이펙트 코딩의 처리 방법은, 범주의 수가 매우 커지면 성능이 급격히 떨어진다. 수가 매우 많은 범주형 변수를 처리하기 위해서는 또 다른 전략 필요.

대규모 범주형 변수 처리

  • 피처 해싱 : 문자열, 숫자등을 해싱해서 변환, 매핑. 단점 : 원본 피처에 대한 정보가 사라져 더 이상 해석하기 어려워짐.
  • 빈 카운팅 : 어려우니깐 생략

요약

  • 책에 잘 정리 되어 있으니, 책 참고.

6장 차원 축소: PCA로 데이터 패케이크 납잡하게 만들기

  • 주성분 분석(PCA, Principal Component Analysis), 피처 차원 축소
  • 어려운건 다 생략하고...

직관

  • 차원 축소 : 핵심 정보는 유지하면서, '쓸모없는 정보'를 제거하기 위한 것
  • 수학적으로 새로운 피처 공간에서 데이터포인트들의 분산이 최대로 되게 한다.

수식 유도

  • 생략

PCA의 활약

  • MNIST 데이터중 8x8 로되어 있는 저해상도 데이터는, 64차원의 데이터를 갖는다.
  • pca_tranformer = PCA(n_componets=0.8)로 하면, 전체 분산의 최소 80%를 설명하는 수준에서 자동 선택.
  • 화면에 출력 결과, 3차원의 데이터만으로 비슷한 숫자들을 가깝게 그룹지은것을 볼 수 있음.

화이트닝과 ZCA

  • 모르겠으니깐 생략.

PCA의 고려사항과 한계

  • 차원 축소를 위해 PCA를 사용할 때는 얼마나 많은 주성분(k)을 사용할 것인지를 확인해야 한다.
  • PCA는 변환이 매우 복잡함. 결과 또한 해석이 어려움. 계산 비용도 많이 듬. 데이터 포인트나 피처의 수가 매우 많다면 수행하지 않는것이 좋다.
  • 데이터가 스트리밍으로 들어오면 PCA를 수행하기 어려움 ( 지금까지의 값으로 분산이 크도록 해 두었는데, 새로 들어온 값이 그것을 깰 수도 있다. )
  • 카운트에 사용하지 않는것이 좋다. 이상치(아웃라이어)들이 있기 때문에, 상관 관계가 쉽게 깨질 수 있다. 사용하고 싶다면, log등을 사용해서 처리하는 방법을 찾거나 하면 된다.

사용 예

  • PCA 변환은 데이터에서 정보를 제거한다. 따라서 이 정보로 모델을 학습할 때는 계산 비용이 적게 들지만, 정확도는 떨어질 수 있다.
  • PCA를 사용한 멋진 애플리케이션 : 시계열 데이터의 이상 탐지, 재무 모델링, 주가의 상관관계 패턴...(모르겠음 ㅋ )

요약

  • PCA에 대해 기억해야 할 두가지 핵심
    • 메커니즘 : 선형 투영
    • 목표 : 투영된 데이터의 분산 최대화
  • PCA는 모델 중심 피처 엔지니어링의 한 예. 분산이 데이터가 가지고 있는 정보를 적절하게 표현한다는것.
  • PCA는 잘 알려진 차원 축소 기법. 하지만 큰 계산 비용이 들고 결과물을 해석할 수 없다는 제약.
  • PCA 특히 피처들 사이의 선형 상관관계가 있을 때 전처리 단계로써 유용.

7장 k-평균 모델 스태킹을 통한 비선형 피처 생성

  • PCA는 데이터가 평평한 팬케이크 모양의 선형 부분 공간에 있을때 유용
  • 데이터가 휘어진 곡면으로 이뤄진(스위스 롤 같은) 경우. 결국은 2D 평면이 둥글레 말려 3D로 된 것임.
  • 피처 엔지니어링의 목적은 피처의 차원을 낮게 만드는것이 목적이 아니라, 과제를 수행하기 적합한 피처를 얻는 것
  • 가까이 있는것들을 모으는 클러스터링 방법을 사용할 수 있다.
  • 클러스터의 수가 원래의 피처 수 보다 작으면, 차원이 축소 되었다고 볼 수 있다.

k-평균 클러스터링

  • 비슷한 공간상에 놓여진 데이터를 그룹화 하는것.
  • 비지도 학습
  • 유클리드 기하학으로 두 점 사이의 거리를 측정 하여 근접성을 측정한다.
  • k-평균은 각 데이터 포인트가 오직 하나의 클러스터에만 할당되는 하드 클러스터링
    from sklearn.cluster import KMeans
    # 10개의 클러스터로 나눈다.
    clusters = KMeans(n_clusters=10, ramdom_state=1).fit_predict(numpy_array);

곡면 분할로서의 클러스터링

  • 스위스 롤 형태의 데이터를 KMeans 클러스터링으로 할때 k가 너무 작으면 클러스터가 잘 나눠지지 않는다.

분류를 위한 k-평균 피처 생성

  • 목표 변수를 사용하면, 그 값을 기준으로 클러스터링을 할 수 있다.(?)
  • 생략

장단점과 몇 가지 사항들

  • 생략

8장 피처 생성 자동화: 이미지 피처 추출과 딥러닝

  • 예전 방식에 대한 설명과, 딥러닝에 대한 설명을 모두 진행

가장 단순한 이미지 피처(그리고 이것이 동작하지 않는 이유)

  • 이미지를 검색하려고 한다마녀, 이미지 데이터 베이스에서 비슷한 이미지를 찾아야 한다.
  • 단순히 이미지에 있는 개별 픽셀 색상 값을 가지고 처리 할 수 없음. 이미지 간의 차이를 어떻게 계산 할 것인지를 결정하는것이 핵심

수동 피처 추출: SIFT와 HOG

  • 이미지 그래디언트(인접픽셀과의 차이)를 활용해서 벡터를 구한다.
  • ... 생략 ...

심층 신경망으로 이미지 피처 학습

  • Fully Connected Network, Convolution, ReLU, Normalization, Max Pooling 설명
  • AlexNet 설명
  • 이 분야에서의 엄청난 발전에도 불구하고 이미지 피처 생성은 아직 과학보다는 예술에 가깝다.
  • 10년 전에 사람들은 이미지 그래디언트, 테두리 탐지, 방향 탐지, 공간 단서, 스무딩, 정규화 등을 사용해 피처 추출을 수작업으로 진행했다.
  • 요즘은 딥러닝 아키텍트가 동일한 아이디어를 캡슐화 하는 모델을 작성하기는 하지만, 파라미터들은 학습용 이미지를 통해 자동으로 학습된다. 마법은 여전히 존재하며, 단지 모델의 더 깊숙한 곳에 추상화돼 숨어있을 뿐이다.

9장 다시 피처로: 학술 논문 추천 시스템 구축

  • 실제 예제를 사용해서 데이터 피처링을 해 보자

항목 기반 협업 필터링

  • 생략

첫 번째 단계: 데이터 가져오기, 정제하기, 피처 파싱하기

  • 단순 두 개의 피처만 사용해서 항목 유사도(코사인유사도)를 구했는데. 시간이 엄청 오래 걸렸다.
  • 데이터 갯수가 너무 많으니 계산하는데 시간이 너무 오래 걸림.
  • 현재의 방식은 반복적인 엔지니어링을 위해서 너무 느리다.

두 번째 단계: 피처 엔지니어링과 더 똑똑한 모델

  • 출간년도를 비닝으로 처리. 10년 단위로 비닝을 해서 피처 공간을 156에서 19로 줄임.
  • 데이터 프레임을 희소 배열로 변환
  • 위와 같이 하면 누락된 데이터가 매우 많을 것이다. 더 많은 정보를 가진 피처를 선택할 수 있는지 살펴 봐야 한다.

세 번째 단계: 추가 피처 = 추가 정보

  • 기존의 피처에서 추가로 초록(abstract)과 저자(authors)를 추가 할 수 있음
  • 초록(abstract)이나 제목의 경우 명사구나 stem(어근)을 구해서 처리 할 수도 있다.

발단

오랜만에 네이버 카페 남궁성의 코드 초보 스터디에 갔는데, 재미난 질문이 있어서 정리를 해 본다.

게시물 및 책 내용

책 내용

  • 책의 일부
    • append를 연결해서 사용하면 메서드 체인이 발생해 메모리 누수가 발생할 가능성이 있다.
  • 위 내용에 대한 설명
    • 모든 메서드가 하나의 체인으로 연결되며 이 메서드에 사용된 모든 인자도 연결되므로 비효율적인 메모리 점유가 발생
    • 하지만 메소드 체인으로 서로 연결된 메서드는 결국 연결된 모든 메소드의 스택이 종료되기 전까지 점유한 메모리를 반환하지 않으며, 메서드에 전달된 인자 또한 모든 메서드가 종료되기 전까지 메모리 상에 유지된다.
    • 나머지 연관된 메서드와 인자가 모두 생존하면서 메모리를 점유할 가능성이 높다.

논란?

  • 우리가 일반적으로 아는 지식을 기반으로 하면, append 메소드가 호출되고, return 되면, append 메소드 안에서 사용한 모든 메모리를 해제 된다.
  • append 메소드 내에서 사용된 Stack 영역의 메모리는 당연히 해제되고, append 메소드 내에서 사용된 heap 영역의 메모리 역시 return 값으로 할당되고 해제 된다.
  • 그런데 왜 책에서는 저렇게 어려운 말을 적었을까? 라는 궁금함이 생겼다.

진짜 다를까? 진짜 확인해 보자.

  • 정확한것을 확인해 보려면, bytecode를 까 보면 되지 않을까? 라는 생각이 들어 실제로 bytecode를 비교해 보기로 했다.

메소드 체인 형태의 bytecode 확인

  • 코드

    Object o1 = new Object();
    Object o2 = new Object();
    // ....
    sb.append("A").append("B").append(o1.toString()).append(o2.toString())... 
  • bytecode

  • bytecode를 분석해 보자.

    1. local variable로 되어 있는 o1 aload로 "메모리의 stack"영역으로 load
    2. invokevirtual로 toString() 메소드를 호출
    3. 그리고 다시 o2에 대해서 위의 1과 2를 반복
    4. 그리고 o3 에 대해서 위의 1과 2를 반복
    5. 그리고 제일 마지막에 pop 를 단 한번만 호출
  • 즉, pop을 딱 한번만 호출

일일이 호출한 경우 bytecode 확인

  • 코드

    Object o1 = new Object();
    Object o2 = new Object();
    // ....
    sb.append("A").append("B")
    sb.append(o1.toString());
    sb.append(o2.toString());
  • bytecode

  • bytecode를 분석해 보자.

    1. aload_1
    2. aload_2
    3. invokevirtual
    4. 로 메모리를 stack에 데이터를 올린뒤, append()가 끝나면 pop으로 데이터 날림
    5. 위 1, 2, 3, 4를 반복
  • 즉, append() 명령이 종료된 시점에 매번 pop을 호출

결론

  • 위 두가지 경우로만 확인해 본다면, 결과적으로 bytecode 상으로는 확연히 다르게 동작한다는것을 알 수 있다.
  • 문제는 메모리의 Stack 영역에 n개의 데이터가 올려져 있다는 것이다.

메소드 체인 형태의 호출에서 비효율적인 메모리 점유가 발생할 수 있나?

  • 맞다. 비효율적인 메모리 점유가 발생할 수 있다.
  • 필요 없는 variable을 stack에 올려 두는것은 비효율적인 메모리 점유가 발생할 수 있다.
  • 우리가 일반적으로 알기에는 method내에 정의된 variable들만 stack 영역에 들어 가는것으로 알고 있다.
  • 하지만, method내에서 호출된 또 다른 메소드의 return값(invokevirtual)도 stack 영역에 보관해야 한다. 그래야 호출한 method에서 그 값을 사용할 수 있을 것이기 때문이다.
  • 그렇기 때문에, 메소드 체인 형태의 호출 방법에서는 pop을 단 한번만 호출하기 때문에, 메소드 체인이 끝나기 전까지, return 값들의 reference count가 여전히 1일 것이다.
  • reference count 가 1이기 때문에 당연히 GC를 할 수 없는 상태가 될 것이므로,
  • 비효율적인 메모리 점유가 발생할 수 있다.

메소드 체인 형태의 호출에서 누수가 발생할 수 있나?

  • 정확하게 말하면 아니다. 누수란 회수 하지 못한 메모리라고 생각한다.
  • 하지만, bytecode에서 발견할 수 있다시피, 해당 Line이 종료되면 pop되므로 메모리는 반드시 회수된다.
  • 누수가 발생할 수 있냐는 질문에는, 아니라고 말하는게 맞을 듯 하다.

메소드 체인 형태의 호출은 성능상 문제가 발생 할 수 있나?

  • 발생할 수도 있다.
  • 코드의 처리 속도
    • 메소드 체인 형태의 호출은 bytecode가 훨씬 더 간결하다.
    • 그렇기 때문에 메소드 체인 형태의 호출이 속도면에서는 훨씬 빠를 것이다.
  • 하지만, GC가 문제가 될 수 있다.
    • pop을 매 함수마다 호출하나, 최종에 한번만 호출하나 어차피 할당되어야 할 객체와 풀여야할 객체다.
    • 하지만, pop이 제일 마지막에 호출 된다면
    • 그 전까지 할당된 메모리를 풀지 않기 때문에
    • 메모리가 부족할 확률이 조금 더 높아진다.
    • 메모리가 부족하면, GC가 동작하게 된다
    • 이로 인해서 성능상 문제가 발생할 수 있다.

메소드 체인 형태의 호출은 "반드시" 성능상 문제가 발생할 수 있나?

  • 아닐 수 있다.
  • 성능에 문제가 발생할 수는 있지만, 반드시 성능에 영향을 미친다고 볼 수 없다.
  • 위의 bytecode만을 본다면, 반드시 성능에 영향을 미친다고 볼 수 있다.
  • 문제는 컴파일러다.
    • JVM은 bytecode를 검토/실행하는 스펙이다.
    • bytecode를 생성하는것은 컴파일러의 몫이다.
    • 컴파일러의 구현은 스펙이 없다.
    • 그러므로 모든 컴파일러가 같은 bytecode를 생성한다는 보장이 없다.
    • 컴파일러의 구현에 따라 어떠한 bytecode가 나올지 알 수 없으므로
    • 반드시 성능 문제가 발생한다고 볼 수는 없다.

너무 오랜만에 Java쪽 자료를 찾아봐서.. 정확한 결론인지는 모르겠다. 하지만 오랜만에 이런거 찾아보고 정리하니 재미있었다. ㅋ.

혹시나 잘못 된 정보가 있다면, 언제든지 지적 부탁드립니다. ^_^

이것저것

공부하기

  • 데이터를 많이 모아 보려고 하고 있다.
  • 데이터를 모으는것은 그냥 모으면 되지만, 이것들을 어떻게 활용 할 것인가에 대한 고민...
    • 데이터를 "처리"하는 부분
    • 데이터를 "분석"하는 부분
    • 데이터를 "활용"하는 부분
  • 으로 나뉘어 질텐데, 우선 텍스트를 쉽게 분석? 할 수 있는 엘라스틱 스택에 대해서 공부 하기로.

읽기

  • 우선 이 책은 초보자를 위한 책은 아님이 확실하다.
  • 엘라스틱 서치의 많은 것을 알려 주기는 하지만, 설명이 장황하고, 구체적이다. 초보가 보기에는 정보가 너무 많아, 너무 어렵게 느껴 질 것으로 판단된다.
  • 이 글에서는, 책의 순서가 뒤죽 박죽이 될 수도 있겠다.

02장 일래스틱서치 시작하기

  • ubuntu 에서 apt로 elasticsearch를 설치하면, 9200 포트에 접근이 되지 않는 경우가 있다.

    • /etc/elasticsearch/elasticsearch.yml 파일에서 network.host 부분을 0.0.0.0으로 변경해 준다.
  • p57 kibana에서 REST API 호출하기

    • GET /라고 입력한 뒤, 초록색 삼각형()을 누르면 해당 쿼리가 실행된다고 한다.
    • 더 쉬운 방법이 있다. 실행하고 싶은 쿼리가 있는 곳으로 커서을 옮긴 뒤, Ctrl + Enter를 입력하면, 커서가 있는 위치의 명령이 수행된다. 이걸 쓰도록 하자.
    • kibana Dev Tools 에서 쿼리를 입력하는 도중 문제가 있으면, 에러 표시()를 해 주므로, 쉽게 사용할 수 있다.
      • 아래는 json의 key 부분인 params"로 감싸지 않아서, 문제가 있다고 알려줌.
      • 단, 모든 에러를 모두 찾아주는건 아니니깐.. 그건 어쩔 수 없음. ㅋ.
  • 엘라스틱 서치에서 REST API의 동작이 ... 뭔가 .. 좀 이해하기 어렵다.

    • 보통 POST는 "추가/생성"의 의미를 가지고, PUT은 "수정(혹은 생성?)"의 의미를 가지는데, 이책의 예제들을 보면, 그게 좀 모호하다.
      • POST
        • id 지정 없이 데이터를 추가하고 싶은 경우(서버가 알아서 id를 할당)
        • id 가 있고, 데이터를 수정하고 싶은 경우 (응???)
      • PUT
        • 인덱스를 새로 만들고 싶은 경우
        • id를 지정해서 도큐먼트(데이터)를 추가하고 싶은 경우
  • p60 가운데 그림

    • 노드 이라고 되어 있는데, 아마도 인덱스가 되어야 할 것이다.
    • 실제 노드에 대한 설명은 64, 64 페이지에 나온다.
  • p78 가운데 업데이트 API 예제

    • POST /catalog/product/1/_update { 에서 마지막 {를 빼야 한다.
    • 다음줄에 {가 또 나오기 때문이다.
    • Kibana에서 입력할 때도 _update뒤에 {가 있으면, 아래와 같이 에러가 발생한다.
  • p 82 인덱스의 매핑을 지정하기 위해서 mappings를 사용하는 부분.

    • mappings로 되어 있어서, 여러개의 type을 넣어 보고 싶어서 시도 했으나, 한개의 인덱스에 여러개의 type을 넣으니 에러가 발생했다. 이상하다, 분명히 인터넷에 여러개의 type을 넣는 예제( [Elasticsearch] Multi types into Index. )도 있는데 말이다.

    • 근데 왜 mappings일까?

      • 한국 엘라스틱에서 올린 글( 미처 못 다한 이야기들 - Elastic{ON} Tour Seoul )에서 이유를 찾을 수 있다.

        • 타입(Type) : 엘라스틱 서치 6.0부터는 타입이 하나로 제한됩니다. 단, 5.x에서 만들어진 인덱스는 6.0으로 업그레이드 했을 때도 그대로 여러 타입을 사용할 수 있습니다.

      • 즉, 이전에는 mappings가 정확한 의미를 잘 표현한 것이고, 6.x에서 달라졌으나, 그 이름을 그대로 활용하는 상태라고 이해된다. 그냥 mapping이라고 하나 추가해도 될 듯 한데...

  • p83 기존 인덱스에 타입 매핑 생성

    • 인덱스를 생성한 후에도 인덱스 타입을 추가할 수 있다.라는 말이 있는데, 이게 상황에 따라 다르다.

    • 이전 페이지인 p 82 에서 이미 catalog에 대해서 my_type이라는 타입을 만들어 두었다.

    • 위에 설명한 mappings에 대한 설명을 적용하면, 한개의 인덱스에서는 두개의 타입을 넣을 수 없다. 그러므로 이미 my_type이라는 타입을 넣어 두었으므로, p 83에서 추가하려고하는 catalog 타입을 넣으려고 하면, 아래와 같이 에러가 발생한다.

    • 그러므로, 정확한 설명은 인덱스를 생성하고, 타입을 추가하지 않은 경우, 나중에 타입을 추가할 수 있다. 라고 되어야 한다. 이를 모두 자세히 나열하면 아래와 같은 것이다.

      • DELETE /catalog로 먼저 생성해둔 catalog 인덱스를 삭제
      • PUT /catalog인덱스만 생성
      • PUT /catalog/_mapping/category { ... }category 라는 타입을 추가하면서 mappings까지 설정
      • GET /catalog/_mapping/을 통해서 category라는 타입mappings가 잘 설정 되었는지 확인.
    • 일반적으로 mapping을 만들때, 전문검색(full text search)할 대상의 typetext 로 주게 된다. 예를들면 뉴스의 내용은 전문검색이 필요하므로 typetext로 설정해야 할 것이다.

  • p88 JSON 응답 형식 부분

    • 기본적으로 모든 요청에 대한 응답은 형식이 없다. .. 어떠한 형식도 지정되지 않는다. 부분의 번역이 언뜻 이해하기 어렵다.
    • 단 한줄로 json응답이 오면 응답 형식이 없는 상태이고, 엔터와 탭으로, 예쁘게 json 응답이 오는것을 응답 형식이 있는 상태라고 해석하고 있다.
    • 아마도, "포맷(format)"을 "형식"이라고 번역했지 않을까 생각해 본다.
    • 기술 서적이라면(적어도, 이정도의 고난이도?? 기술을 다루는 책이라면.. 모든것을 번역할 필요가 있을지 의문이다... )
    • 책에서는 ?pretty=true를 사용했지만, 단순히 ?pretty만 사용해도 json 형태의 응답이 예쁘게 출력 된다.
    • 또한 JSON 형식 뿐만 아니라, yaml 형태로 출력 할 수도 있다. ?format=yaml를 이용해서 쿼리를 날리면 된다.
  • p90 GET /_search의 결과물 부분

    • 책에서는 나오지 않지만, 실제로 쿼리를 실행하면, 우리가 만든 category 뿐만 아니라, 우리가 만들지 않은 .kibana_1이라는 인덱스를 발견할 수 있다.
    • 이건 말 그대로 kibana용 인덱스이다. 언제 이런게 만들어졌나고?
    • kibana를 최초로 실행시키면 아래의 로그를 볼 수 있다.

03장 유사도 검색

  • 이후 부터 용어라는 말이 나오는데, 영어로는 term이다. ( 사실 이미 p73 등에서 등장한 말이다.) 역색인시 사용하는 key 정도로 이해하고 우선 넘어 가면 될 듯 하다. ( key일래스틱 서치와 같이, 여러개의 단어로 이루어져 있을 수도 있을것 같다. - 정확하지 않음.)

  • p94 전문검색 이라는 용어가 나오는데, 全文검색이다. 영어로는 Full Text Search

  • 텍스트 분석기는 아래의 3가지 과정은 순차적으로 거친다

    1. 문자 필터(Character filters) : 0개 이상 - 문자열 치환 등 문자열 처리
    2. 토크나이저(Tokenizer) : 정확히 1개 - 문자열을 쪼개주는 역할, 역색인 만들때 사용
    3. 토큰 필터(Token filters) : 0개 이상 - 쪼개진 문자열을 다시 처리하는 역할, 각 토큰으로 들어온 문자열을 소문자로 바꾸거나, 불용어(The, a, an, is ...)를 없애주는 등의 처리 가능
  • 토크나이저(Tokenizer)는 문자열을 잘라주는 역할인데, 표준분석기, 언어분석기, 공백분석기 등이 있다.

  • 이 중에서 제일 재미난건 언어 분석기인데, 사실상 이 놈의 핵심인것 같다.

  • 재수좋게도, 2018년 8월 24일에 엘라스틱에서 공식 한국어 분석 플러그인 '노리'를 만들었다. 아싸!!

    • 용량이 작다.
    • 속도가 빠르다.
    • 공식지원이니 설치가 편하다.
  • 설치하는 방법과 간단한 사용방법은 Elasticsearch 6.4 기본 한글 형태소 분석기 노리 (nori) 설명 및 사전 추가하기를 방문해서 확인해 보자.

  • REST api로는 아래와 같이 호출해 보면, 아래와 같이 주요 단어를 잘 뽑아 주는것을 확인해 볼 수 있다.

  • 뉴스 관련 데이터로 몇가지 테스트를 해 보았다.

    • 뉴스의 카테고리는 category라는 이름으로 그냥 text로 만들었고, title과 contents는 "nori" 분석기를 달도록 설정했다.

    • 이후 news/article type에 30여개의 document를 추가 했다.

    • 뉴스 데이터 category에 "경제"를 넣어 두고, 검색할때 "category" : "경제" 를 검색하면 아래와 같이 잘 찾아 진다.

    • 하지만 "category" : "경제적"을 검색하면 제대로 찾아 지지 않는다.

    • 이제 contents에도 똑같이 경제를 검색해 보자. "경제"라는 글자가 contents에 있는 경우에는 당연히 잘 검색 된다.

    • 이제 contents에 경제적을 검색해 보자. "nori" 분석기가 잘 동작했다면, "경제적"이라는 전체 단어가 아니라, "경제"라는 단어만 있어도 잘 검색해 줄 것이다. 아래 결과를 보면 "경제"가 들어간 결과 뿐만 아니라, 경제를도 잘 검색 된다는것을 알 수 있다. 즉, 분석기가 글자를 잘 분석해서 역색인 했다는것을 알 수 있다.

구조화된 데이터 검색

  • 반면, 비슷것을 찾아주는게 아니라 정확하게 색인 된 것만 찾으려면 term 을 사용해서 찾으면 된다.

    • match를 사용하는 위의 예제에서는 경제적을 검색어로 써도 경제를 찾거나, 경제를을 찾아준다.하지만 정확하게 색인된 것만 찾으려면 term을 사용하자
    • term을 사용해서 경제적을 찾으며 아무것도 찾아지지 않는다는것을 알 수 있다.
    • 그렇다면 contents에 실제로 있는 경제를이라는 검색어를 term을 사용해서 검색하면 어떻게 될까? 아래와 같이 검색 되지 않는다.
    • term색인된 것만을 검색한다. nori 분석기에서는 경제를을 색인한것이 아니라, 경제만 색인 했기 때문에 term을 사용했을때 경제를이라는 검색어로는 찾아지지 않는것으로 보인다.
    • term을 사용하여 경제를 찾으면 제대로 찾아 지는것을 알 수 있다.
  • title이나 contents 필드는 text 타입으로 설정해 두었다. 그러므로 match로 검색을 하면 nori 분석기를 통해서 비슷한 것도 찾아 준다. 하지만 만약 category 필드와 같이 keyword 타입으로 설정해 두었다면, nori 분석기등을 통하지 않고 "정확한 것"만 검색하도록 된다.

전문 텍스트 검색

  • match검색시 검색어에 오타가 있을 경우를 대비한 fuzziness값을 줄 수도 있다.

    • fuzziness에 1, 2 등의 값을 주면, 몇 글자가 틀려도 알아서 찾아 준다.
    • 예를 들어 경조라고 잘못 검색어를 입력해도,공조, 경찰, 경제등을 찾아 준다.
  • 반면 match에는 여러 검색어에 정확하게 맞는 쿼리를 보내고 싶을 때는 match_phrase를 사용한다. 구글에서 " " 로 감싸서 쿼리하는것과 비슷하다.

    • 단, 검색어에서 순서는 정확하게 맞지만, 일부 단어가 생략되는것을 허용하려면 slop 값을 조정하면 된다.
  • 그외 이것 저것은 생략. 나중에 필요할 때 찾아 보자

04장 일래스틱서치 분석

Metric 집계

  • Aggregation(어그리게이션)을 여기서는 집계라고 부른다. 쉽게 생각하면 걍 숫자 랑 관련되는 통계?를 내는것이라고 생각하자.
  • 숫자 관련 통계는 합계(sum), 평균(avg), 최소(min), 최대(max), 이상의 4개를 모두 한번에 보여 줄 수 있는 통계(stats)가 있다. 아래는 이미지 데이터에서 각 이미지 용량의 합계, 평균, 최소, 최대 값을 출력한 것이다.
  • 제곱, 분산, 표준편차, 표준편차 구간등을 한꺼번에 보여 줄 수 있는 확장통계(extended_stats)도 있다.
  • 만약 데이터를 구성할때, 자식을 가지도록 구성했다면, aggs를 사용할때, nested라는걸 사용해서 처리해야 한다. ... (아.. 어려워... ) 아래는 이미지 데이터에서 각 이미지 해상도의 너비와 높이에 대한 통계 정보를 출력한 것이다.
  • unique한 값의 갯수를 세고 싶을때는 cardinality를 사용하면 된다. 아래는 이미지 데이터에서 unique한 Tag 갯수를 출력한 것이다. 이미지 데이터에 있는 Unique한 Tag 갯수는 약 10만개다.

Bucket 집계

  • 문자열 데이터 버켓팅에서 Terms 집계 : 관련 내용은 아래에 나오는 fielddata 관련 부분을 확인해 보면 예제를 볼 수 있다.
  • 숫자 데이터 버켓팅에서 재미난게 있다. histogram 집계인데, 일정 간격으로 숫자를 쪼개서 갯수를 세어주는게 있다. 아래는 이미지 데이터에서 이미지를 2Mbyte 단위의 용량별로 갯수를 센 결과를 출력한 것이다.
  • 일정 간격이 아니라, 특정 간격으로 나눠서 보고 싶다면, rangeranges, 그리고 from, to를 사용하면 된다. 단, to의 값은 포함하지 않는다. 자세한건 생략.ㅋ. 책을 찾아 보도록 하자. ( 170페이지 참고 )
  • 그 이외에, A이면서 B인 경우 갯수 세기, 시간별로 쪼개서 확인하고, 지리적 위치를 기반으로 쪼개서 확인하기 등이 있다. 자세한건 책으로... ㅋ

05장 로그 데이터 분석 (아직 안 읽음)

로그스태시 아키텍처

  • 로그스태시는, "입력", "필터", "출력"으로 이루어 진다. 즉, 이 세가지로 데이터를 처리 할 수 있다.
  • 로그스태시는 기본적으로 파이프라인 단계별로 이벤트를 버퍼에 담기 위해 인 메모리 바운드 큐를 사용한다. 로그스태시가 불안정한 상태로 종료되면 인메모미레 저장된 이벤트는 손실 된다. 데이터 손실 방지를 위해서 영구 큐를 사용해 실행중인 이벤트를 디스크에 유지할 수도 있다.(LOGSTASH_HOME/config/logstash.yml 파일에서 queue.type:persisted 설정, RAM을 1GB사용하는데 변경하려면 LOGSTATSH+HOME/config/jvm.options에 Xms, Xmx를 변경 가능)
  • p210 윗쪽 예제에서 mutate{ 를 닫아두는 } 가 없다. 그러므로 잘 닫아 주어야 한다.
입력 플러그인(Input Plugin)
  • File
    • p216 각 파일의 모든 변경 사항을 추적하고, 마지막으로 읽은 위치를 기반으로 해당 시점 이후 데이터만 전송한다. ... 각 파일에서 현재 위치는 sincedb라는 별도로 분리한 파일에 기록한다. 따라서 로그스태시를 중지하고 다시 실행해도 로그스태시가 실행되지 않은 순간에 추가된 행을 빠뜨리지 않고 중단된 부분부터 작업을 수행할 수 있다.
    • 여러 파일을 설정할 수도 있고, 각종 옵션을 조정하며, 입력으로 사용할 위치(Line?)도 정할 수 있다.
  • Beat
    • 일래스틱비트에서 발생하는 이벤트를 수신할 수 있음.
  • JDBC
  • IMAP : IMAP 서버에서 이메일을 읽을 수 있음. host, password, user 필수.
출력 플러그인(Output Plugin)
  • Elasticsearch : 권장하는 방법. 자동으로 localhost:9200 사용. 필요하다면 각종 옵션으로 다른곳에 저장 가능.
  • CSV
  • Kafka : 카프카 토픽에 이벤트를 작성할 때 사용. 필수 매개변수는 topic_id
  • PagerDuty : 알림을 보낼 수 있는 서비스에 연동 가능
코텍 플러그인(Codec Plugin)
  • Input전이나, Output후에 변환을 할 수 있는 기능
  • JSON : 입력 플러그인에서 JSON 데이터를 디코딩, 출력 플러그인에서 데이터를 JSON으로 인코딩 할 수 있음. 여러줄로 이루어져 있는 JSON인 경우, json_lines 코덱을 사용
  • rubydebuga
  • Multiline : 여러행에 걸친 데이터를 단일 이벤트로 병합하는데 유용한 플러그인. 여러행에 걸쳐 있는 스택트레이스 또는 단일 이벤트 정보를 처리할 때 매우 편리하다.
인제스트 노드
  • 이전 일래스틱서치에서는 데이터를 사전 변환하려고 하면 별개의 프로그램을 이용해서 처리해 주었어야 했는데, 이제 인제스트 노드라는게 나왔다.
  • 인제스트 노드는 일래스틱서치에서 색인을 생성하기 전에 도큐먼트를 사전 처리하고, 도큐먼트를 풍부하게 해 주는 경량 솔루션.
  • 이 기능 덕분에 로그스태시 필터 부분을 제거하고 자체적으로 로그 데이터를 처리하고 변환할 수 있게 되었다.
  • gsub, grok, convert, remove, rename 등 20개가 넘는 내장 프로세서 보유
  • 내장 프로세서를 조합해서 _ingest/pipline으로 PUT 해서 파이프라인을 정의할 수 있다.
  • 대신 정의된 파이프라인을 사용해서 데이터를 밀어 넣어야 한다. ( .../mytype/1?pipeline=somepipeline { .... })
  • 파이프라인이 잘 동작하는지 확인하기 위해서 시뮬레이트 해 볼 수 있는데, endpoint에 그 정보를 주면 된다. (.../_ingest/pipeline/somepipeline/_simulate { ... } )

06 로그스태시를 활용한 데이터 파이프라인 구축

로그스태시를 사용한 로그 구문 분석 및 강화

필터 플러그인
  • CSV 필터 : CSV 파일을 쪼개고, 컬럼 이름을 정의 하는 등의 작업 가능
  • Mutate 필터 : 필드 변환, 게저, 수정, 이름변경 등
  • Grok 필터 : 불규칙한 데이터를 분석해 구조화하고, 구조화된 데이터를 쉽게 쿼리하고 필터링 하는데 자주 사용되는 강력한 플러그인. 간단히 말해, 특정 행에서 정규식 기반의 패턴이 일치하도록 하는 방법
  • Date 필터 : 시간을 처리(포맷 정의 가능)
  • Geoip 필터
    • ip주소로 위치 정보를 추가하는 필터(GeoLite2 City - Maxmind 회사 제품, CCA ShareAlike 4.0 라이선스 - 데이터베이스 사용)
    • 문자열로 된 IP를 Geoip 필터를 통하면, 위도, 경도, 나라, 도시명 등이 나옴.
  • UserAgent 필터 : 웹브라우저의 UserAgent를 분석

비트 소개

  • 엣지 서버에서 에이전트로 설치되는 경량 데이터 수집기.
  • 립비트라는 라이브러리로 구성되어 있음.
  • 비트는 입력, 출력, 옵션 설정, 이벤트 처리, 로깅 구현이 되어 있고, 데이터를 일래스틱서치, 로그스태시, 레디스, 카프카 등으로 보낼 수 있도록 API를 제공함.
  • 로그스태시와 비트의 차이점
    • 비트는 경량 에이전트로 더 적은 자원 소모(비트는 일반적으로 Go 언어로 작성되어, JVM이 필요 없이 동작 가능)
    • 비트는 엣지 서버에 설치해서 사용하는것이 일반적임
    • 하지만 비트는 이벤트 변환 및 분석, 즉 로그스태시에서 제공하는 강력한 기능은 없음.
    • 로그스태시는 여러 자원에서 데이터를 수집하고 변환하는 가공 및 입력, 필터, 출력 플러그인 제공.
    • 로그스태시는 자원에 더 초점을 두고 있으며, 일래스틱 스택 외에 독립된 제품으로도 사용 가능
    • 로그스태시는 데이터 처리를 위해 이벤트를 수신하는 엣지 서버보다는 전용 서버에 설치하는것이 좋다.
일래스틱비트
  • 파일비트 : 로컬파일에서 로그 수집
  • 메트릭비트 : 운영체제 및 서버에서 실행중인 서비스 메트릭을 주기적으로 수집. 아차피, 몽고DB, 레디스 등 다양항 서비스의 멭릭을 수집. 모니터링하기 좋음.
  • 패킷비트 : 실시간 네트워크 패킷 분석기. 애플리케이션 서버간 네트워크 트래픽을 캡처하거나 HTTP, Mysql, Redis, 맴캐시등의 프로토콜 해석 가능. 요청 응답 상관관계 기록 가능
  • 하트비트 : 서비스 활성 상태 여부, 서비스 가능 여부 모니터링. 주기적으로 실행중인 서비스 상태를 모니터링 가능, ICMP, TCP, HTTP 지원
  • 윈로그비트 : 윈도우 플랫폼에 특화된 비트. 윈도우 API를 사용해 여러 이벤트를 수집.
  • 오디트비트 : 6.0 버젼에 새로 구현. 사용자 활동 모니터링, 니룩스의 auditd를 건드리지 않고 데이터 분석 가능. 실시간으로 변경되는 파일을 설정한 출력으로 보내 잠재적인 보안 정책 위반 행위를 식별하는데 사용 가능.
커뮤니티 비트
  • 스프링부터. 레디스 로그, 엔진엑스 상태, mysql 결과, 몽고DB, 구글애널리틱스, Apache, 아마존 제품 데이터 수집

파일비트

아키텍처
  • Prospectors : 로그를 읽을 파일 목록을 구분하는 역할

  • Harvester : 실제 로그를 읽는 역할, 하나의 Harvester가 개별로 파일을 담당하며 파일을 열고 닫는다. 마지막 읽은 위치를 레지스트리에 관리한다.

  • Spooler : Harvester가 읽은 데이터를 전달 받는다. 이벤트를 집계하고 설정한 출력으로 전달한다.

  • 파일 비트는 이벤트가 지정한 위치로 최소 한 번은 데이터 손실 없이 전달 되도록 보장한다.

  • 파일비트가 일래스틱서치에 저장 될 때는 filebeat-YYYY.MM.DD 패턴의 index에 저장하게 된다.

  • Prospectors 설정

    • input_type, path등을 설정 할 수 있다.
    • 재미난건 exclude_lines 라는 설정을 하면 정규식과 일치하는 행을 제거한다는것이다.
    • 단순히 파일의 선택뿐만 아니라, 내용을 읽어 보고 전달 할지 말지를 전할 수 있다는것이다.
  • 출력 설정 : 일래스틱서치에 넣을때, 정의해 둔 파이프라인을 통해서 넣을 수도 있다.

  • 모듈 : 자주 사용되는 형태의 데이터를 수집, 구문분석하는데 사용된다. ( Apache2, Auditd, MySQL, Nginx, Redis, Icinga, System )

07 키바나를 활용한 데이터 시각화

  • 키바나는 node.js로 실행되는 웹 어플리케이션.
  • 키바나는 일래스틱서치와 같은 버젼을 사용하는 것을 권장. 마이너 버젼도 같은것으로 사용하도록 하자.
  • 기타 생략

08 일래스틱 엑스팩

  • 최근에는 엑스팩이 아니라, Elastic Stack 확장 기능으로 이름을 바꾸었다.
  • 엑스팩은 보안, 알림, 모니터링, 보고서, 머신러닝, 그래프 기능을 제공
  • 기본적인 기능은 무료이나 머신러닝, 그래프 등은 유료
  • 일래스틱서치 클러스터는 일반적으로 여러 노드로 구성되어 있으므로 클러스터에 속한 각 노드의 엑스팩을 설치해야 한다.
  • 키바나에서도 엑스팩을 설치해야 한다.
  • 엘라스틱서치는 내장 보안 기능이 없다. 그러므로 누구나 엘라스틱서치에 접근할 수 있음. 이러한 문제를 해결하기 위해서 일반적으로는 일래스틱서치 앞단에 방화벽을 두거나, 엔진엑스, HAProxy등 리버스 프록시를 사용해서 보안을 강화 한다.
  • 하지만, 엑스팩을 사용하면 사용자 인증 및 권한 관리, 노드 클라이언트의 인증 및 채널 암호화, 감시 등을 지원한다.
  • 키바나에서 사용자 추가/삭제, 권한 관리 가능(심지어 도큐먼트의 필드별로도 권한 관리가 가능하다. )
  • Watcher라는 구성요소는 일래스틱서치에 저장된 데이터의 변경 사항이나 이상징후를 자동으로 감지하고 적절한 조치를 취할 수 있는 기능 제공. 알림 기능을 설치하면 기본적으로 활성화 됨.

09 일래스틱 스택 운영 환경에 적용하기

일래스틱 스택 설정

  • 역색인을 필요로하는 메모리 관련 작업
  • RAM에 저장할 수 있는 데이터가 많아질수록 성능이 좋아진다. 하지만 데이터 타입에따라 연산이 다를 수 있으므로 항상 그러한것은 아니다.
  • 일래스틱서치는 비교적 쉽게 수평 확장 가능
    • 초기에는 CPU 코어 8개, RAM 16GB 혹은 32GB로 사용하는것이 좋다.
    • 어차피 일래스틱서치의 JVM Heap이 32GB 이상 메모리를 잡을 수 없다.
    • 그러므로 64GB 이상의 RAM을 가진 인스턴스를 사용할 필요가 없다.
    • 오히려 무거운 집계 연산을 수행하는 경우에는 SSD를 사용하는것이 좋다.
  • 운영체제는 리눅스를 추천하나, 어느것을 써도 무방하다.
  • 일래스틱서치 노드 설정
    • JVM Heap 크기
      • -Xms-Xmx를 동일하게 설정한다. 힙이 많으면 좋겠지만, 그 만큼 Full GC도 많이 일어난다. Full GC가 일어나면 일래스틱 서치가 잠시 멈출 것이다.
      • 설정할 수 있는 RAM의 최대 크기는 32GB다.
      • 주의사항 : 일래스틱서치의 JVM에 총 메모리 기준 50% 이상을 할당하지 말아야 한다. 아차피 루씬의 파일 시스템 캐시에 충분한 메모리가 필요하기 때문. 궁극적으로 일래스틱서치 노드에 저장되는 데이터를 아파치 루씬 인덱스로 관리.
      • 확장이 필요하다면, 노드를 추가하는 방법을 선택할 것
    • 스와핑 비활성화 : Swapping을 설정하면 OS가 메모리의 내용을 Disk로 옮기는 동작을 하게 됨. 그러므로 동작이 늦어 질 수 있음
    • 파일 디스크립트 : 리눅스 및 맥 OS는 프로세스가 파일을 유지할 수 있는 파일 디스크립터 개수에 제한이 있음. 기본적으로 이 값이 매우 낮기 때문에 변경을 고려해야 한다.
    • 스레드풀 및 가비지 컬렉터 : 색인, 검색, 집계 등 다양한 연산을 할 때 JVM의 Thread Pool을 사용한다. JVM의 Thread Pool 이나 가비지 컬렉터의 설정을 변경하면 일반적으로 악영향을 미치므로, 되도록이면 스레드풀과 가비지 컬렉터 설정을 변경하지 않고 사용하는것이 좋다.
  • 클라우드 환경 사용시 고려사항(대표적으로 AWS)
    • 인스턴스 타입 선택 : 시작하기 적당한 것은 m3.2xlarge(CPU 8core, 30GB RAM, 80GB SSD 2개)
    • 포트(port)를 노출하지 않도록 변경
    • 프록시 요청 : 요청 제어시 엔진엑스 또는 아파치와 같은 리버스 프록시 활용
    • 로컬 주소에 Http 바인딩 : 인스턴스가 VPC 내에 위치 할 것이므로, 클라이언트와 통신할 필요가 없는 노드는 쿼리를 Http를 이용해서 수신.
    • EC2 검색 플러그인 설치 : 같은 네트워크에서 다른 노드를 찾는 방법
    • S3 저장소 플러그인 설치 : 정기적 백업을 위해 저장해 둘 공간
    • 주기적인 스냅숏 저장

인덱스 별칭

  • 원래 만들어 둔 인덱스의 이름을 변경해야 하는 경우, 기존에 배포된 애들이 문제가 될 수가 있다.
  • 이때는 별칭을 생성해서, 기존의 애들은 잘 동작하게 하고, 새로운 이름으로 사용 할 수도 있다.
  • 원본 데이터 이름이 A, B, C 로 3개가 있다고 하면, 별칭은 data라는 이름으로, 원본을 변경해 가면서 작업을 진행할 수도 있을 것이다.

기타

  • 인덱스를 만들고 나면 샤드 갯수를 변경할 수 없음. 처음 만들때 잘 정해야 함.
  • 단일 인덱스에 대규모 데이터를 저장하는것 보다, 시간 기반 인덱스를 여러개 만들어서 보관하는것이 더 편리하다.
    • 1개월씩의 데이터를 각기 다른 인덱스로 만들었을때, 6개월이 지난 데이터를 삭제하는것은, 그냥 6개월이 지난 인덱스를 지우면 되기 때문이다.

10 데이터 분석 애플리케이션 구축

  • 실제 데이터를 가지고 시각화 하는것까지 구축하는 예(생략)

11 서버 인프라 모니터링

  • 매트릭비트 설치 및 운영 방법
  • Mongodb, 시스템메트릭 등에 대한 설명(생략)

기타 정보

실제로 해 보면서 겪었던 문제 정리

  • fielddatatrue로 주게 되면 역색인 정보를 바로 검색해 볼 수 있다.

    • 뉴스에 나오는 용어를 찾기 위해서는 contents의 역색인 정보를 뒤져야 하는데, 이걸 그냥 뒤져 볼 수 있는 방법이 없다.
    • vectorterms 인가 하는 방식을 쓸 수 있는데, 그건 id가 지정된 경우에만 사용할 수 있다.
    • mapping을 생성할때, 에 "fielddata" : true를 주게 되면, 역색인 정보를 바로 검색해서 볼 수 있다.
    • 역색인 정보를 검색하려면 아래와 같이 호출하면 된다.
  • 하지만 fielddatatrue로 주면, 메모리 문제가 부족하다면서 검색이 안되는 경우도 있다.

    • 엘라스틱 서치를 띄울때 메모리를 더 주면 해결 되더라.
    • /etc/elasticsearch/jvm.options 파일에서 -Xms-Xmx 값을 더 늘려 주도록 하자.
    • 내가 설치 했을때는 1g로 되어 있었다. 2g 정도로 주니깐 어느정도는 잘 동작하더라.
  • 20만건 정도의 데이터를 엘라스틱서치에 넣는데는 얼마나 걸릴까?

    • http request의 POST 방식으로 데이터를 하나씩 넣어 보았더니, 668초가 소요되었다.
    • logstash 로 json 파일을, console에 로그를 찍어 가면서 넣어 보았더니, 350초가 소요되었다.
    • logstash 로 json 파일을, console에 로그를 찍지 않고 넣어 보았더니, 70초가 소요되었다.
    • 그러니 나 처럼 무식하게, http POST로 데이터를 밀어 넣지 말고, logstash를 좀 공부하도록 하자.
    • 그리고, console에 log를 찍는것은 생각보다 오랜 시간이 걸린다는것을 알 수 있다. http request POST방식으로 데이터를 넣을때, console에 log를 일일이 출력하면 몇배로 더 늦어진다. 그러니 로그는 필요한 만큼만 찍자.

아!! 짜증난다!!!

요 몇일 집에서 OpenCV와 nodejs(typescript)를 이용해서 이것저것 해 보고 있다. 근데... 분명 어제 만들었던 코드가 오늘은 안 돌아 갔다. 그래서 typescript로 만들어 두었던, class와 호출되는 함수를 모두 풀어서 1개의 함수로 작성했더니 잘 된다... -_-

아아! 도대체 뭐가 문제일까?

뭐가 문제일까?

1개의 함수로 풀어 두었던 코드들과 기존의 코드를 비교 했지만, 알 수 없는 이 문제... 도대체 뭐가 문제일까? 결과적으로 문제는 async와 await를 잘못 사용한 것이었다.

문제 해결

내가 만든 코드는 아래와 같다.

////////// 함수 정의
public init():void {
  //...
}
public async captureDetectFace(dir:string, maxCounter:number):Promise<FaceAddResult> {
  //...
}
public destroy():void { 
  //... 
}

/////////// 함수 호출
let fr:FaceRecog = new FaceRecog();
fr.init();
fr.captureDetectFace("..", 10);
fr.destory();

함수 중에 caputreDetectFace 함수는 async 함수로 만들어 두었는데, 함수를 호출 할 때는 생각도 없이 그냥 fr.captureDetectFace("..", 10)의 형태로 호출을 했다. 그렇기 때문에, 해당 함수의 결과(Promise)를 대기하지 않고, 바로 fr.destory()를 호출하게 된다.

fr 인스턴스가 destory 되어버렸기 때문에, fr.captureDetectFace()함수 안에서 fr 인스턴스를 사용하려고 할 때 문제가 되는 것이었다.

고치는 방법은 너무나 간단하다. fr.captureDetectFace("..",10)으로 호출할게 아니라, await fr.captureDetectFace("..",10) 처럼 await를 붙여 주면 해결 되는 문제 였다.

아! 멍청이!

기껏 코드를 다 작성하고, 문제를 찾지 못하고 있었는데... 참... javascript의 세계는 참 어렵다. 개념부터 다르니.

왜 이글을 적냐면...

그냥 적어두는 과정을 거치면, 더 잘 기억할 것 같아서 적어둔다. ㅋ.

그럼 안녕. ㅋ.

책 읽기

이것저것

  • 책의 내용을 시작하기 전에 이것저것 설명이 나오는데 이 중에서 웹 퍼블리셔라는 용어가 나온다.
    • Q. 저는 웹 퍼플리셔로 일하고 있는데 프런트 엔드 개발자로 커리어를 전향하고 싶어요. 이 책이 도움이 될까요?
    • 프런트 엔드 개발자는 뭔 줄 알겠는데, 웹 퍼플리셔라는 용어를 처음 들어봐서 정리.
    • 웹 퍼블리셔에 대한 설명은 웹 퍼블리셔의 역할 - 프론트 앤드 개발자와 차이점를 방문해서 확인해 보면 쉽게 그림으로 되어 있다.
    • 간단히 정리하면, 예전에 디자이너가 그림을 그리고, 개발자가 코딩을 해야 할 때 중간에 HTML화(?) 시키는 영역이 발전했다고 보면 된다고 한다.
    • 최초에는 HTML화 시키는 일만 했겠지만, 지금은 웹 접근성등을 지켜야 하기 때문에 더 많은 고려를 해야 하는 영역이 되었다고 한다.
    • 하지만 웹퍼블리셔를 돌아보다라는 글을 확인해 보면, 웹 퍼블리셔가 프론트엔드 개발자와 비슷한 개념으로 혼용되고 있는듯 하기도 하다.
    • 뭐.. 암튼 그럼. ㅋ.

읽으면서 정리하기

Vue.js 필수 기술 살펴보기

Vue.js 소개

Vue.js란 무엇인가?

Vue.js의 특징

  • 20페이지 아래쪽 화면 요소를 꾸미는 HTML, CSS 코드와 데이터베이스에서 데이터를 가져와 제어하는 Java 코드가 한 파일에 섞이면서 가독성이 현저하게 떨어졌습니다. 라는 말
    • 이 문장에서 Java는 꼭, Java만들 뜻하는게 아니라, 서버사이드의 코드를 뜻하는것이라고 생각하는게 맞는것 같다. Java나 PHP 등 웹 서버쪽 코드 라고 하는게 더 좋을듯 하다.

개발 환결 설정 및 첫 번째 프로젝트

뷰 학습을 위한 개발 환경 설정하기

Hello Vue.js! 프로젝트 만들기

  • 37 페이지 중간, 뷰 개발자 도구쪽에서 아래와 같이 '파일 URL에 대한 엑세스 허용' 체크 박스에 체크합니다. 라는게 있는데, 요즘에 크롬이 업데이트 되어서 화면이 좀 다르다.
  • 아래의 그림을 참고하여 켜 주면 된다.
  • 옵션을 키고나면 아래와 같이 Toolbar에 Vue 아이콘이 활성화 되고, 개발자 도구 영역에 Vue 라는게 생긴다. 그리고 Vue의 데이터 상태 같은 것도 확인할 수 있다.

화면을 개발하기 위한 필수 단위 - 인스턴스 & 컴포넌트

뷰 인스턴스

  • 46 페이지 마지막 단락 부분에 만약 여기에 값을 변경하는 로직을 넣더라도 화면이 다시 그려지지는 않습니다. 라는 말
    • 이 말을 이해하는데 오래 걸렸다.
    • 여기서 설명하는 부분은 beforeUpdate 이벤트(?) 이다.
    • 원래 일반적인 동작에서는 값을 변경하면 화면을 새로 그려야 한다.
    • 이 시점은 아직 새로 그리기 직전이니, 원래 그릴려고 하는 값을 강제로 변경하는 코드를 넣는다고 하더라도, 바뀐 값을 이용해 1번만 그린다. 즉, 원래 값을 강제로 바꾸었다고 해도, 다시 그릴려고 시도하지는 않는다. 는 의미로 받아들이면 될 듯 하다.
    • 책을 읽을때도 좀 이해하기 어려웠는데, 이걸 글로 표현하려고 하니... 어렵네? ㅋ
    • 음... 좀 이상하다. 실제로 beforeUpdate에서 message 값을 변경해 보면, 무한루프 에러가 발생한다. ;; 음.. 아직 뭔 말인지 이해가 잘 되지 않는다. ;;;
    • 여기에서 설명하는 그려지지 않습니다.라는 말은, 가상 DOM에 node를 추가하는것인지, Real DOM에 node를 추가하는것인지 모르겠다. ;;; 암튼 그려준다라는 말의 용어가 좀 더 명확해야 할 듯 하다. 뒤의 내용을 차츰 읽어 가면서, 추후 이 내용에 대한 업데이트를 하겠다.

뷰 컴포넌트

뷰 컴포넌트 통신

상용 웹 앱을 개발하기 위한 필수 기술들 - 라우터 & HTTP 통신

뷰 라우터

뷰 HTTP 통신

화면을 개발하기 위한 기본 지식과 팁 - 템플릿 & 프로젝트 구성

뷰 템플릿

  • 102 페이지 둘째, 복잡한 연산은 인스턴스 안에서 처리하고 화면에는 간단한 연산 결과만 표시해야 합니다. 라는 부분.
    • 간단한 연산 결과만 표시하는것을 권장합니다.라고 읽는게 좋다.
    • 안되는게 아니고, 권장하는것이기 때문에 결과만 표시해야 합니다.라는 말이 정확하지 않다.
    • 물론 그 다음 페이지인 103페이지 두번째 단락에서는 뷰에서 이러한 방식을 권하는 이유는 이라고 설명이 적혀 있긴 하다.

뷰 프로젝트 구성 방법

Vue.js 실전 투입!

실전 애플리케이션 만들기

할 일 관리 앱 살펴보기

프로젝트 생성하고 구조 확인하기

컴포넌트 생성하고 등록하기

  • 137 페이지의 중간 부분에 보면, components를 등록하는 부분이 있다.
    • 그런데 그것만 코드를 넣으면 에러가 난다.
    • 그 페이지 제일 마지막에 있는 import 관련 코드도 같이 적어야 한다.
    • 이 책의 설명이 좋긴 한데, 한 개의 코드 덩어리에서 설명해야 하는 부분을, 두개 이상의 덩어리로 나눠서 설명하는 경우가 있다. 이런 부분이 책을 좀 읽기 어렵게 만드는 경향이 있다.

컴포넌트 내용 구현하기

  • 151 페이지의 아래쪽 예제에서 <li v-for='todoItem in todoItems'>{{ todoItem }}</li> 부분
    • vue 2.2.0 이상에서는 v-bind:key필수로 있어야 한다.
    • 그러므로 vue 2.2.0 이상을 쓰면 아래와 같이 코드를 바꿔야 한다.
    • <li v-for='todoItem in todoItems' v-bind:key='todoItem'>{{ todoItem }}</li>

기존 애플리케이션 구조의 문제점 해결하기

더 나은 사용자 경험을 위한 기능 추가하기

  • 페이지 171의 중간에 있는 :key 속성은 v-for 디렉티브를 사용할 때 지정하는 게 좋습니다. 부분
    • 이미 바로 위인 151 페이지의 내용에 대한 설명에 적어 두었다. vue 2.2.0 이상에서는 :key속성은 필수이다.

Vue.js 고급 개발자 되기

뷰 중.고급 레벨로 올라가기 위한 지식

뷰 개발을 위한 웹팩

뷰 개발을 위한 ES6

뷰 CLI에서 사용하는 NPM

지금 당장 실무에서 써 먹는 Vue.js

뷰와 제이쿼리를 같이 사용해도 되나요?

개발 기간이 너무 짧은데 기존 레거시 고드에 어떻게 뷰를 바로 적용하죠?

뷰에 UI 라이브러리와 차트를 어떻게 연동할까요?

뷰로 프로그레시브 웹 앱을 개발하려면 어떻게 시작해야 하죠?

Vue.js

공부하기...

  • Vue.js 를 공부 해 보려고 책을 구매 했는데.. 아직 도착 안했다.
  • 그럴줄 알고, 온라인에 한글로 되어 있는 Vue.js 가이드 문서를 출력했다.
  • 링크 : https://kr.vuejs.org/v2/guide/installation.html

읽기

설치방법

시작하기

시작하기

  • <script src="https://cdn.jsdelivr.net/npm/vue"></script>를 보면, 주소의 끝이 vue로만 끝나고 'js' 확장자가 붙지 않는데, 실제로 다운로드 받아 보면 javascript 파일이 다운로드 된다.
    • 심지어 response header에서도 javascript가 전달 된다고 정보가 온다.
  • 영어 문서를 보면, 아래의 내용이 더 있다. 한국어 문서에는 빠져 있는 내용이다. 개발할때는 아래 코드를 쓰는것이 도움이 될 거란다.

    <!-- development version, includes helpful console warnings -->
    <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
    

선언적 렌더링

  • 텍스트 보간 이외에도 다음과 같은 엘리먼트 속성을 바인딩 할 수 있습니다.를 보면 보간이라는게 나온다.

    • 여기서 나오는 보간은 영어로는 interpolation이다. 텍스트 끼워넣어 교체하기 이외에도 다음과 같은 엘리먼트 속성을 바인딩 할 수 있습니다. 정도로 읽으면 될 거다.

컴포넌트를 사용한 작성방법

  • v-bind:key="item.id" 부분이 있다.

    • 그 직전의 코드는 v-bind:todo="item"인데, 이 코드의 뜻은 item의 값(속성)을 Component안에서 todo라는 이름으로 사용할 것이라는거다.
    • 그렇다면 v-bind:key="item.id"라는 코드는 item.id를 Component안에서 key라는 이름으로 사용할 것이라고 예상이 된다. 하지만 실제로 key를 출력해 보면 제대로 출력 되지 않는다.
    • v-bind:key는 특별한 의미를 가지고 있기 때문에 원하는대로 처리 되지 않는 듯 하다.
    • 자세한건 뒤에 내용을 보면서 추후 업데이트 하겠다.

Vue 인스턴스

속성과 메소드

  • 유념할 점은, data에 있는 속성들은 인스턴스가 생성될때 존재한 것들만 반응형이라는것입니다. 라는 부분
    • 말그대로 Vue 객체를 생성하는 시점에 mapping 된 sturcture에 존재하는 속성들만 연동된다는 말이다.
    • 추후에 data에 속성을 추가해도, 그 값은 연동되지 않는다.
    • 근데, 그 다음 내용을 보면 $data라는 특별한 속성에 대해서 이야기가 나온다.
    • 생각해 보면 Vue 컴포넌트 내부에서 $data의 값을 이용해 연동 시킨다고 생각할 수도 있다. 하지만 주의해야 한다.
    • Vue 객체를 생성할때 mapping된 structure가 $data로 매핑되는것이다. 그렇기 때문에 vm.$data.b = 3와 같이 값을 넣는다고 해도, 추후에 컴포넌트는 만든 이후에 설정된 속성이므로 "연동"되지 않는다.
    • 그러므로 책에서 설명하듯이, 나중에 사용하려고 하는 속성들은 미리 data 의 속성으로 추가해 두어야 한다.
    • 만약 뒤늦게 반응형 속성을 추가하고 싶다면 '객체 변경 감지에 관한 주의사항' 부분을 읽어 보면 Vue.set(...)를 사용할 수 있다는것을 알려 준다.

인스턴스 라이프사이클 훅

  • options 속성이나 콜백에 ... 와 같은 화살표 함수 사용을 지양하기 바랍니다. 부분
    • 화살표를 이용한 함수사용시 this 에 대해서 다르게 동작할 수 있다.
    • 일반적인 function() 정의 안에서 this를 사용하면, 해당 function이 호출되는 Context(부모객체?)의 this를 따라가게 된다.
    • 하지만 () => { } 형태 안에서 this를 사용하게 되면, 해당 function을 정의한 Context(부모객체?)의 this를 따라가게 된다.
    • 위 말이 뭔 말인지 잘 모르겠으면 화살표 함수의 링크를 방문하여 읽어보면 된다. 자바스크립트에 대해서 잘 모른다면, 꼭 읽어 보는것이 좋다.

템플릿 문법

보간법(Interpolation)

  • 위에서 이야기 했듯이, "끼워 넣어 바꾸기" 정도로 해석하면 된다.
  • v-once 디렉티브를 사용하여 데이터 변경시 업데이트 되지 않는 일회성 보간을 수행할 수 있지만, 같은 노드의 바인딩에도 영향을 미친다는 점을 유의해야 합니다. 부분
    • 말 그대로, "v-once"로 설정된 tag 하위들은, {{msg}} 의 부분도 업데이트 되지 않는다는 말이다.
    • 한번 출력(?)되고 나면 app.msg="ccc"와 같이 값을 바꾼다고 해도, 업데이트 되지 않는다.
  • 실제로 Vue.js는 모든 데이터 바인딩 내에서 JavaScript 표현식의 모든 기능을 지원합니다. 부분
    • 쉽게 말하면 {{ msg }} 부분이나 v-bind:disabled="isButtonDisabled" 부분이나, v-bind:id="'list-'+id" 부분이나, v-if='seen', v-bind:href='url' 등 부분에서 값을 넣어 주는 '' 부분의 코드가 실행 되거나, 그 값이 할당 된다고 보면 된다.
      • 예 1 : v-if='seen'라는 코드가 있을때, seen이라는 변수의 값이 false 면, 해당 tag가 실제로 렌더링 되지 않는다.
      • 예 2 : <a v-bind:href='url'>라는 코드가 있을때, url이라는 변수의 값이 href에 할당 되는것으로 생각하면 된다. 예를 들면 <a href="http://naver.com"> 과 같이 변경 될 것이다.

계산된 속성과 감시자

계산된 속성

  • 하지만 차이점은 계산된 속성은 종속성에 따라 캐시된다는 것 입니다. 부분
    • 캐시되는 정보는 return value 이다.
    • 즉 해당 함수에서 console.log(..)를 출력한 뒤, return 'aa'라고 정의를 하면, 최초 값을 사용할 때는 console.log(..)가 출력 되지만, 그 이후 다시 해당 값을 사용하면 log가 출력되지 않는다.
    • 하지만 return value를 만들때, 변수를 사용한다면, 현재의 변수 값을 이용해서 반환된다. 변수 값이 바뀌면, return value 역시 바뀐다는것을 주의해야 한다.

폼 입력 바인딩

기본 사용법

  • 체크박스 설명중에 <label for="checkbox" ...> 부분에 대한 설명

    • 해당 label이 어느 tag와 연관이 있는지 연결해 주는 것이라고 생각하면 된다.
    • 지금은 for="checkbox" 라고 했으므로, 지금 HTML에서 id가 checkbox인 아이와 연관 되는 label이라는 뜻이다. type이 아니라 id가 checkbox인것과 연동된다는거다.
    • 이렇게 해 두면, <input> 위치가 아니라, <label>위치를 클릭해도, <input>을 누른것 처럼 동작하게 연결 할 수 있다.

      수식어

  • .lazy 설명 중에 .lazy 수식어를 추가하여 change 이벤트 이후에 동기화 할 수 있습니다. 라는 말.

    • v-model은 input text의 값이 변경되면 실시간으로 model 의 값도 같이 변경되도록 되어 있다.
    • change 이벤트는 input text에 값을 입력하는 도중이 아닌, 입력후 다른 곳으로 focus를 옮긴 이후나, 엔터를 입력하는 등의 상황에 발생한다.
    • 그러므로 말 그대로 실시간으로 적용하고 싶지 않은 경우에만 사용하면 된다.

이후 내용들...

  • 가이드 문서만 읽기에는 너무 어렵다. 
  • 소스들이 등장하기는 하는데, 전체의 소스가 아니라 소스 일부만을 설명이 나오는경우가 있어, 명확하게 파악하기 어려운 경우가 있다. 이후 중요하거나 이해를 꼭 해야 하는 부분만 정리 하도록 한다.
  • 나머지는 Do It! Vue.js 입문 책을 구매 했으니, 그 책에서 다시 정리 하던지 하자.



[도서]Do it! Node.js 프로그래밍

정재곤 저
이지스퍼블리싱 | 2017년 03월

내용     편집/구성     구매하기

책 읽기

  • 책 자체는 크기도 크고 두껍기도 하다. 하지만 안의 글자 크기가 작아서 많은 양의 정보가 담겨 있다. 아마도 책을 좀 작게 만들었거나, 읽기 쉽도록 글자를 좀 크게 했으면, 소위 "바이블"이라고 불리는 책 두께가 되었을듯...
  • 책 초반에는 아주 작은 정보까지 책에 나오고는 있으나, 그 작은 정보들을 아주 간단한 설명으로 퉁쳐 버리거나 설명하지 않은 부분에 대해서도 많은 단어들을 등장 시킨다.
    • 예를 들면 18 페이지의 작은 "주의" 박스에서는 "세션"이나 "쿠기"등의 단어를 사용하는데. 여기에 대한 설명은 없다. 그 전에는 "용어"칸을 통해서 조금 어렵다고 생각되는 단어들을 모두 설명하고 있는데 말이다.
    • 초보자들을 위한 책이라서, 세세한 설명이 달려 있는거 치고는, 설명이 부족하다. 그렇다고 설명이 안 달려 있는것도 아니니.
    • 만약 초보자가 해당 책을 읽는다면, 잘 모르는 단어가 나왔을때는 그냥 과감히 무시하고 넘어 가는것이 좋겠다. 설명 자체는 세세하게 잘 되어 있으니, 모르는 단어들은 아마도 책 뒷 부분에 설명이 나올듯 하다.

이것저것

읽으면서 정리하기

31페이지

  • 31페이지에 보면, 이런 문제를 해결하기 위해서 만든게 노드입니다라는 말이 있는데, 이 설명은 좀 이상하다고 생각된다. 노드의 특성이 비동기 입출력이지, 비동기 입출력을 위해서 노드를 만들었다고 적혀 있으니 말이다. 뭐.. 내가 모르는 무언가가 있는건가?

78 페이지

  • basename()에 대한 설명으로 파일 패스에서 파일의 확장자를 제외한 이름을 반환합니다.라고 되어 있는데 잘못된 설명이다. 기본적으로 basename은 파일의 반환하는 함수이고, 두번째 인자에 따라서 확장자를 제거해 주던지 아니면, 그대로 두던지 한다. 심지어 80페이지의 실제 출력 결과물에서도 확장자가 제거 되지 않고 nodepad.exe가 출력 된다.

84 페이지

  • 그리고 문자열은 큰 따옴표(" ") 또는 작은 따옴표(' ')를 사용하여 표기합니다. 라고 되어 있다. 이쪽 세상에서는 큰 따옴표보다는 작은 따옴표를 훨씬 더 많이 쓴다. 이 책에서 나오는 예제들도 대부분(?) 작은 따옴표를 사용하고 있다.

94 페이지 ~ 96 페이지

  • 94 페이지부터 96페이지까지 있는, push, pop, shift, unshift 관련 예제들은 의도를 제대로 표현하지 못한다. 이 함수들은 배열에 어느곳을 기준으로 아이템을 추가/삭제하는지가 중요한데, 예제에서는 단순히 배열의 count 만 하고 있다. 정확하게 동작하는지 확인해 보려면, 최소한 push, pop, unshift 를 사용하기 직전과, 사용한 직후에 console.dir(Users); 라도 있어야 확인할 수 있다.
  • 96 페이지 이후에 나오는 delete, splice, slice 의 경우에는 console.dir(Users); 로 화면에 객체 정보를 출력해 해당 함수들이 잘 동작하는지 확인하도록 예제가 만들어져 있다.

105 페이지

  • 사소하긴 하지만, 예제의 제일 아래쪽줄 바로 윗줄에 '객체의 walk(10)을 호출합니다.' 라고 되어 있는 부분에서 객체의 앞에 공백이 하나 들어가야 한다. 107 페이지의 결과에서는 Person.name 과 '객체의' 라는 글자 사이에 공백이 있다.

107 페이지

  • prototype에 대한 설명이 너무 퉁 쳐서 되어 있다. 메모리를 효율적으로 관리한다라고 하기에는 내부 동작이 복잡하기 때문에 이해하고 넘어 가는 것이 좋다. 오승환님의 글 : [Javascrip] 프로토타입 이해하기 라는 글을 보면 이해하기 쉽게 잘 설명 되어 있다. 물론 초보자라면 읽어도 이해하기 어려울 수 있으니, 그 때는 그냥 패스.

109 페이지

  • 이 작업을 쉽게 할 수 있도록 노드에서 미리 만들어둔 모듈이 url 모듈입니다. 라는 말이 있다. 실제로 url 모듈이 이러한 역할을 하지만, url 모듈에서는 "한글 도메인"을 "영문 도메인"으로 바꾸는 다른 기능들도 가지고 있다. 그러므로, 정확하게 바꾸자면 노드에서 미리 만들어 둔 url 모듈을 사용하면 이 작업을 쉽게 할 수 있다. 고 되는게 정확하겠다. 맞다. 그냥 꼬투리 잡는거다. ㅋㅋ.

119 페이지, 120 페이지

  • readFile(filename, [encoding], [callback]) 이라고 되어 있는데, 정확한 스펙은 readFile(filename, [options], callback) 이다. options에는 encoding을 적을 수 있기 때문에 그 부분은 적당히 맞다고해도, callback은 반드시 필요한데, [callback]으로 표시해서 마치 생략할 수 있는 것 처럼 표기 했다. 그러므로 수정되어야 한다. writeFile, open, read, write, close 모두 callback을 생략해서는 안된다.

127 페이지

  • 주의 상자에 기존 output2.txt 파일을 삭제한 후 output.txt 파일을 output2.txt 파일로 복사하는 과정이 비동기 방식으로 처리되므로 화면에 출력되는 순서는 다를 수 있습니다. 라고 되어 있는데.. 단순히 출력만 다른게 문제가 아니다.
  • 파일을 삭제하는 fs.unlink 역시 비동기로 동작된다. 즉, 언제 파일이 지워질지 모르는 상태에서 다음 코드인 infile.pipe(outfile)을 수행하게 된다. 이 때 fs.unlink보다 infile.pipe(outfile)이 먼저 실행 완료되면, 파일을 "복사"를 한 뒤, 파일을 "삭제"하게 되므로 복사가 제대로 되지 않을 수 있다.
  • 그러므로 단순이 출력만 다른 문제가 아니라, 코드 자체가 오류를 일으킬 수 있도록 되어 있다는것이 문제다.
  • 제대로 수정할 것이라면, fs.unlink의 callback 함수 안에서 복사하는 동작을 넣어야 한다고 생각된다.
  • 아님 말고. ㅋ

137 페이지

  • server.listen(port, host, '50000', function() { ... 부분에서 좀 잘못 된 부분이 있다. 물론, '50000'의 위치에 들어가야 하는 정보는 backlog 라는 값이 되어야 하는데, API 정의상에서는 이 값이 <number>여야 한다.
  • 물론 코드를 동작시켰을때, 잘 동작할 수도 있다. javascript의 오묘한 형 변환이 있기 때문이다. ㅎ. 물론 난 실제로 코드를 동작시켜서 확인해 보지는 않았다. ㅎㅎ.

145 페이지

  • 이 파일을 실행한 후 웹 브라우저에서 요청을 보내면 같은 결과를 볼 수 있습니다. 라고 되어 있다. 같은 결과를 볼 수 있는것이지 실제로 같은 응답을 보낸것은 아니다.
  • pipe를 이용해서 데이터를 바로 쏴 버리면, 현재 보내는 파일의 content-type을 보내지 않게 되므로, 웹 브라우져가 알아서 보여주는것이다.
  • 헤더 정보가 없는 응답

  • 그렇기 때문에 책에서도 이 방법으로 코딩을 했을때 헤더를 설정할 수 없는 등의 제약이 생기므로 필요할 때만 사용하길 권합니다. 라고 적어 둔 것이다.

  • 헤더도 제대로 셋팅하고 파일도 전달 하고 싶다면, infile.pipe(res); 바로 윗 줄에 res.writeHead(200, {'Content-Type': 'image/png'});를 추가해 주면 Content Type 헤더도 제대로 전달 할 수 있다.

  • 헤더 정보가 잘 추가 되어 있는 응답

149 페이지

  • 정박사의 한마디 부분 중 GET 방식은 헤더 부분에 요청 정보들을 넣어 보내고라는 부분이 있다. 정확하게 말하면 GET 방식은 URL 부분에 요청 정보를 전달하는것이다.
  • GET 이던 POST던 상관없이(심지어 PUT이나 DELETE에도) 헤더 부분에 요청 정보를 넣어 보낼 수 있다.
  • 초보를 위한 책이기 때문에, 이 모든것을 구체적으로 설명할 수 없다는것을 독자는 이해해야 한다.
  • 클라이언트에서 어떤 Method를 쓰던 request 헤더에 부가적인 정보를 보내고, 서버에서 그 정보를 받아서 처리하겠다고 약속하면 된다.

164 페이지

  • 첫 번째 코드 예제 중에서 app.use('/public', static(path.join(__dirname, 'public'))); 부분이 잘못 되었다.
  • 코드의 직전 설명에서는 [public] 폴더에 있는 모든 파일을 웹 서버의 루트 패스로 접근할 수 있도록 만들고 싶다면 이라고 표현되어 있다. 이 말대로 동작하려면 코드는 app.use(static(path.join(__dirname, 'public'))); 이 되어야 할 것이다.
  • 다음 페이지의 3번째 예제는 설명이 제대로 되어 있다.
  • 167 페이지의 예제에서도 app.use('/public', static( ... ) )으로 되어 있는데, 이 역시 app.use( static( ... ) )로 되어야 한다.
  • 그리고 static 이라는 이름의 변수를 쓰는건 좋지 않다. 오해를 일으킬 수도 있고, 추후 TypeScript 등을쓰게 되면 또 문제가 된다. 그러므로 static이라는 이름의 변수는 피하도록 하자.
  • 참고로 Express 4.x 이후로는 express.static 미들웨어를 기본으로 제공한다고 한다. 그래서 코드를 쓸 때 그냥, app.use(express.static('public')); 형태로 쓰면 된다. 여러 디렉토리를 설정할 수도 있다고 한다.
  • express.static

168 페이지

  • 아래쪽을 보면 서버 코드에서 use() 메소드로 설정한 함수는 login.html 문서에 접근했을때는 호출되지 않습니다. 라고 되어 있다. 근데... 잘은 모르지만... 아마도... 이 설명은 잘못 되었다.
  • 서버 코드에서 app.use( '/public', static(...)) 부분이 실행되었기 때문에, public 디렉토리에서 login.html을 찾아서, 웹 브라우져로 내려 주었기 때문에, 웹브라우저에서 해당 HTML을 볼 수 있게 된 것이다.
  • 그러므로 정확하게 말하면 서버코드에서 app.use( static(...) ) 메소드로 설정한 함수가 동작했고, 그 다음 app.use() 함수는 호출 되지 않습니다. 라고 이해하는게 좋겠다.
  • 그렇다면 왜, app.use(static(...)) 다음에 우리가 정의한 미들웨어는 실행되지 않는가? 바로, static(...) 함수 안에서 error가 나지 않는 이상 next() 함수를 호출하지 않도록 코드가 만들어져 있다. 관심이 있다면 직접 소스 코드를 확인해 보자.

262 페이지

  • 세번째 줄 I accept th license terms -> I accept the license termse가 빠진 듯 하다.

276 페이지 277 페이지

  • 276 페이지 select ?? from ?? where id = ? and password = ? 부분과 227페이지 SQL문 안에 들어 있는 ?? 또는 ? 기호를 대체한 후 다음과 같은 SQL 문을 만들어 냅니다. 에서 어떤때는 ?? 를 쓰고, 어떤때는 ?를 쓰는데 이건 오타가 아니다.
  • ?? 는 '' 없이 그냥 값이 대체 될 때 사용되고, ?는 ''를 감싸서 대체 된다.
  • 277 페이지 중간에 있는 select id, name, age from users where id = 'test01' and password = '123456' 을 보면 잘 알 수 있다.

348 페이지

  • 마지막 예제에서 <h2><% = title %></h2>가 있는데 %=를 붙여 적어야 한다. 즉, <h2><%= title %></h2> 가 되어야 함.
  • 그 외, 다른 곳에서도 <% =와 같이 띄워쓰는 코드들이 보이는데 이것은 모두 오타이다. 그러므로 다 붙어 있다고 생각하면 된다.
  • 그리고 여기에서 <%를 쓰는 경우와 <%=를 쓰는 경우가 있는데, 이것에 대한 자세한 사용법은 ejs홈페이지 에서 Tags 부분을 확인해 보면 좋다.

8장 뷰템플릿 적용하기...

  • 뷰 템플릿은 ejs와 pug에 대한 설명이 나온다.
  • 기존에 HTML을 알고 있는 사람이라면 ejs가 훨씬 더 직관적이다. 반면 pug는 pug만의 문법을 따라야 한다는 불편함이 있다.
  • 물론 pug가 HTML tag를 모두 적지 않아도 된다는 장점이 있지만, 요즘에는 대부분 IDE 툴에서 HTML 자동 완성을 제공해 주므로, 크게 차이가 나지 않을 것으로 보인다.
  • 암튼 난 ejs 가 훨씬 더 편해 보인다. 예전에 php를 해서 그런지 ejs가 훨씬 더 익숙해 보인다.

373 페이지

  • 두번째 예제 박스에서 passport.use(new LocalStrategy( 부분은 passport.use('local', new LocalStratgy(로 바꾸는것이 책을 읽는데 좀 더 수월하다. 다음장인 374 페이지의 윗 부분 그림에도 스트래티지 설정이라는 부분에 보면 'local'을 설정해 둔 것을 볼 수 있다.
  • 다만 'local'을 생략했다고 해서 잘못 동작하는것은 아닌데, passport.use()함수를 호출할 때, Strategy의 이름을 설정해 주지 않는다면, Strategy에서 name 값을 얻어와 셋팅하도록 되어 있기 때문이다.
  • https://github.com/jaredhanson/passport/blob/master/lib/authenticator.js
  • LocalStrategy의 코드를 보면 자신의 name 값을 설정하는 코드를 찾을 수 있다.
  • https://github.com/jaredhanson/passport-local/blob/master/lib/strategy.js
  • 그러므로 passport.use(new LocalStrategy(로 설정했다고 해도, 가져다 쓸 때는 passport.authenticate('local', ...) 으로 호출 할 수 있게 된다.

427 페이지

  • attach(httpServer, options)는 정확하게 하면, attach(httpServer[, options])이다. 즉, Options는 생략 가능. 물론 책에서 일일이 설명하기 어려우니 생략했을 것이라고 생각한다. 글쓴이보고 뭐라고 하지 말길...
  • 그 아래에 있는 listen(httpServer, options) 역시 마찬가지다.

431 페이지

  • 예제 중에서 socket.on(... 부분의 코드에서 들여쓰기가 잘못 되어 있으니 주의해서 볼 것.

435 페이지

  • 예제나 책 설명 중에 recepientrecipient의 오타이다. 하지만 책 전반에 걸쳐 오타인 recepient를 사용했으니, 실제 코드에서는 별 문제가 없을 것으로 예상된다.
  • 나도 자주 틀리는 단어라.. ㅎㅎ. 이해가 된다. ㅋㅋㅋㅋㅋ.

481 페이지

  • 이 callback 함수는 두 개의 파라미터를 전달받을 수 있는데, 첫 번째 파라미터는 오류 전달을 위해 사용하고 두번째 파라미터는 정상적인 데이터를 전달 할 때 사용합니다. 라고 설명되어 있다.
  • 487 페이지에 실제로 에러가 난 상황을 가정하고, 첫번째 파라미터에 "정보"를 넘기고 있는것을 볼 수 있다. 481 페이지의 내용을 대충 읽으면, 487 페이지의 내용을 이해하기 어려울 수 있을것 같아, 기록해 둔다.

484 페이지

  • 제일 아래 표에서 result : 응답 데이터가 배열 객체로 들어 있습니다. 라고 되어 있다.
  • 여기서는 성공한 경우에 대한 정보만 표로 나타내고 있다. 실패한 경우에는 error이라는 속성에 정보가 채워져 있다. 이 내용은 489 페이지에 설명되어 있다.
  • 다만 실패한 경우에 대한 설명은 표로 설명되어 있지 않아 놓치기 쉬울 것 같이 기록해 둔다.

621 페이지

  • 예제의 하단을 보면 Entities : Entities 부분이 있다.
  • 또한, 622 페이지 ejs 예제를 보면 var entities = new Entities(); 코드가 있다.
  • 뜬금 없이 갑자기 Entities를 사용하고 있는데, 이건 책에 코드가 누락되어 있기 때문이다.
  • 619 페이지 코드에서 제일 윗 줄에 .... 위치에 다음의 코드가 들어가야 한다. var Entities = require('html-entities').AllHtmlEntities;.
  • 인터넷에세 예제를 다운로드 받아보면 추가 되어 있으나, 책에서는 생략되어 있어 의아하게 생각할 수 있는 부분이다.
  • 책에서는 Entitites에 대한 설명을 아예 없다.
  • html-entities 모듈은 HTML을 인코딩/디코딩 시켜주는 역할을 한다. 설치는 npm install html-entities --save로 설치 할 수 있다.


[도서]타입스크립트 마스터 2/e

나단 로젠탈 저/김유성 역
에이콘출판사 | 2018년 03월

내용     편집/구성     구매하기

서두

자바스크립트를 공부하고, 실제로 사용하려고 했지만, 너무나 어려웠다. 가장 어렵다고 생각한 부분이 "자동완성"을 제대로 지원하지 않는것.

Type이 정확하지 않기 때문에, 내가 parameter로 전달해야 하는것도 명확하지 않았고, 모든것을 다 알고(혹은 외우고) 호출해야 하는 일이 어려웠다.

그래서 타입스크립트를 공부해 보기로 결심.

에이콘 출판사의 "타입스크립트 마스터 2/e - 예제로 배우는 타입스크립트"를 구매 했다.

출판사에 있는 정오표에 표시된 것 말고도 잘못 된 곳이 보여, 이곳에 정리해 두고자 한다. 지금 발견한건 딸랑 하나라.. 나중에 더 추가 될 수 있을지 모르겠다.

책을 다 읽었다. 당근 완벽하게 모든 내용을 이해한건 아니다. ㅋㅋ 아래 내용중 내가 잘 모르는 상태로 "잘못됐다"라고 이야기 하는것도 있으니, 이 글을 읽는 사람이 잘 가려서 읽기를 바란다.

책 후기

  • TypeScript의 문법은 거의 java와 비슷하다. 좀 다른게 있다면.

    • 변수나 함수의 type을 정의 할 때, 변수명 뒤 쓰는 형태 public id : string;
    • interface 정의에 field도 정의할 수 있음 interface A { id:string }
    • field에 접근할 때, get set 키워드를 통해서 hooking 할 수 있음 get id() { return this._id; }
    • 읽기 전용 속성은 final 대신, readonly readonly name: string;
    • 여러개의 type을 받고 싶을때는 Object 대신 any var a : any = "aa"
    • 여러개의 정해진 type(Union)을 받고 싶을때는 Object 대신 | var a : string|number;
    • 함수의 파라미터에서 같은 타입의, 다른 갯수에 대한 오버로딩시 모두 각각 정의하는 대신 ? 사용 funnction a( b: string, c?: string, d?: string) { ... }
    • 함수의 파라미터에서 타입이 다른 오버로딩시 모두 각각 정의하는 대신 아래 문법 사용

        function a ( b: string, c: string) : string;
        function a ( b: number, c: number) : number;
        function a ( b: any, c: any) : any {
            // code
        }
      
    • 상속 받은 클래스의 생성자에서는 반드시 super()를 수동으로 불러줘야 한다. Java에서는 super()가 자동으로 호출 되지만, 타입스크립트는 그렇지 않음. 자동으로 호출해 주자는 건의(?)가 많았지만, JavaScript의 super-set이라는 등의 이유로 안된듯 하다.

정오표 및 이해하기 어려운 곳 설명

3장 인터페이스, 클래스, 상속

216 페이지

  • Simple Class는 id, name의 속성과 -> Simple Class는 id 속성과
    • Simple Class에는 name 속성이 없다.

156 페이지

  • myClosure; -> myClosure();
    • 예제 소스에서 의도한것은 myClosure라는 함수가 실행되는것을 의도한 것이다(p157페이지의 상단 설명). 그러므로 함수 실행을 위해서 마지막에 () 를 붙여 주어야 한다.

159 페이지

  • 제일 아래의 예제 처음에 아래의 코드 추가

    enum PersonCategory {
        Audlt,
        Infant,
        Child
    }
    
    interface IPerson {
        Category: PersonCategory;
        canSignContracts(): boolean;
        printDetails(): void;
    }
    
  • 아마도 PersonCategory에 관한 enum과, IPerson이라는 interface 관련 코드가 아예 빠진것 같다. p160 내용이나, 그 뒤의 예제 결과등을 참고하면, 위의 코드가 있어야 될 듯 하다.

174 페이지

  • 제일 아래의 예제 코드에서 static staticName: string; -> static name: string;
    • 다음페이지에 나오는 출력 결과물과, 설명을 보면 코드상의 속성 이름이 staticName이 아니라 name이 되어야 한다.

203 페이지 (오타아님)

  • 유창한 구문으로 함수에 프라미스를 -> 플루언트 구문으로 함수에 프라미스를
    • Fluent의 번역을 "유창한"이라고 했다. 그래서 오히려 이해하기 어렵다. fluent 에 대한 개념은 여러 라이브러리의 사용에서 나오므로, 그냥 "플루언트"라고 그대로 적는게 어떨까 싶다. "데코레이트"도 그대로 사용했으니깐. 324페이지에도 "유창한"이라고 적혀 있으니, 이후에 나오는건 모두 걍 fluent라고 생각하면 된다.

226 페이지

  • containsErros 메서드와 ErrorHelper.trace 메서드를 -> ErrorHelper.containsErrors 메서드와 ErrorHelper.trace 메서드를
    • ErrorHelper는 containsError와 trace 메소드를 모두 가지고 있는데, 한쪽에만 ErrorHelper의 메소드인것 처럼 적어 두었다.

261 페이지

  • 정의에 모델 속성을 할당하려면 model: NoteModel 구문이나 -> 정의에 모델 속성을 할당하려면 model = NoteModel 구문이나
    • 260페이지의 마지막에서 이미 model: NoteModel은 오류가 발생한다고 적혀 있다. 그러므로 261페이지의 내용은 model = NoteModel 이 되어야 한다.

274, 463 페이지 (오타아님)

  • MVC는 모델-뷰-컨트롤러의 두 문자 집합으로 -> MVC는 모델-뷰-컨트롤러의 앞 글자의 집합으로
  • 객체지향 모범 사례의 두 문자를 모은 SOLID 디자인 -> 객체지향 모범 사례의 앞 글자를 모은 SOLID 디자인
    • 두 문자는 머리 두(頭)를 이야기 한 것으로 보인다. 그러므로 읽기 쉽게 "앞 글자" 라고 적어두는게 더 읽기 좋겠다.

323 페이지

  • Jasmine uses a simple format for writing tests. Consider the following TypeScript code: -> 삭제
    • 이미 위에 한글로 해석이 되어 있는데, 코드 쪽으로 설명이 내려와 있다. 그러므로 삭제

334 페이지, 335 페이지

  • doCallback 함수 -> doCallBack 함수
    • 예제에서는 "B"지만, 설명에서는 어떤 때는 "B", 어떤 때는 "b"로 사용한다. 그러니 잘 읽어내도록 하자. 심지어, 334페이지 아래쪽에는 let doCallback 으로 변수를 하나 만들어서 쓰고 있어서 더 혼동이 될 수 있다. 예제를 만들때 요런 점도 좀 고려해서 만들었으면 좋았을 텐데...

341 페이지, 342 페이지

  • jasminjquery -> jasmin-jquery
    • 라이브러리 이름이니 정확하게 "-"를 포함해서 적어야 한다.

363 페이지

  • Id: 0, DisplayName: "none"}}); -> { Id: 0, DisplayName: "none"}});
    • SelectedItem의 값으로 Id와 DisplayName을 넣는 Struture를 넣어야 하는것으로 보인다. 그렇게 되려면 "{"를 제일 앞에 추가해 줘서 객체(?) 형태로 만들어야 한다.

09장 타입스크립트 호환 프레임워크 테스트 는 생략함

  • TypeScript 자체를 공부하기 위해서 책을 보는것이라. 지금 당장은 테스트용 프레임워크를 열심히 볼 필요는 없다고 판단. ㅋ. 그래서 걍 이 부분은 읽지도 않고 패스함.ㅋ.

417 페이지

  • mod1.print(); -> m1mod1.print();
    • 첫번째 예제에서 let m1mod1 으로 정의해서 쓰고 있기 때문에, 다음줄에 있는 코드는 당연히 m1mod1.print(); 가 되어야 한다.

426 페이지 (오타아님)

  • 글 내용을 보면, "main.js파일에서는..." 이런 내용이 나오는데, 어디에도 그 main.js 파일을 찾을 수 없다. 그냥 작가가 있다고 생각하고 이야기 한 것인지 모르겠다. 그래서 책 내용을 읽을때, 독자도 상상력을 가지고 읽으면 될 것 같다.

429 페이지

  • 항목 이름은 'jasmineboot'로 -> 항목 이름은 'jasmine-boot'로
    • 소스코드에서는 물론이고, 직전의 설명에서도 'jasmine-boot'로 설명 되고 있다.

432 페이지

  • 다음 AMD 오류인 filenot-found 오류일 수 있다. -> 다음 AMD 오류인 file-not-found 오류일 수 있다.
    • 이전 설명에서도 file-not-found 와 같이 중간에 모두 - 을 넣어 두었다.

436 페이지 (오타아님)

  • 중간에 보면 http-server를 실행하고 결과를 보여주는 설명이 있는데, http-server를 설치하는 방법은 설명도 안 해 줬다. ( 설마.. 9장에서 해 줬나? ). http-server를 설치하려면 console(cmd)창에서 아래의 명령을 입력해 주면 된다.
  • npm install http-server -g
  • 그 이후 http-server를 실행시키면 된다.

448 페이지, 451 페이지, 565 페이지 등 (오타이님)

  • {{{body}}}

    • handlebars 템플릿은 일반적으로 {{ }} 처럼, 이중 괄호를 2개만 쓴다. 그런데 예제에서는 {{{ }}} 에 대한 설명 없이 body만 {{{body}}}로 사용중이다.
    • handlerbars는 {{ }} 를 사용하게 되면, 단순 String으로 치환하는것 이외에, HTML Tag와 관련되는것들을 모두 화면에 출력할 수 있도록 치환해 준다. 예를 들어 title이 "제목은 귀여워 >_<" 와 같다면, "제목은 귀여워 &gt;_&lt;" 와 같이 치환한다.
    • 하지만 {{{ }}} 를 사용하면 치환하지 않고, 그대로 String이 들어가게 된다. 여기에서는 {{{body}}} 영역에 각종 HTML 코드(<p> 나 <br>등)가 들어가야 페이지 HTML 페이지 구성을 할 수 있기 때문에 {{{ }}}를 사용한 것이다.


+ Recent posts