B급코딩

FE 성능 최적화

B급 코딩 — Mon, 9 Oct 2023 17:42:01 +0900

프론트엔드의 성능 최적화

사용자가 필요한 UI를 지연과 불편함 없이 제공할 수 있는가가 프론트엔드의 성능을 점검하는 주요 목적이다.

기술적 영역에서의 프론트엔드 성능 최적화는 두 가지 영역으로 나눠 볼 수 있다.

로딩 성능
- 파일크기를 최소화 혹은 최적화 해야 함, (특히 이미지와 글꼴!)
- 컴포넌트, 이미지 등의 지연로딩과 사전로딩을 적절히 활용해야 함
- minifi를 통해 번들크기 최소화. (대부분의 번들러가 production 상태에서 제공함)
- 캐시를 활용해야 함, 서버에서 설정함. e.g cache-control header 활성화
- 서버에서 텍스트 압축을 활성화 해야 함. e.g. gzip 활성화
렌더링 성능
- 최근의 보편적인 화면주사율(화면갱신의 단위, 모니터에 따라 다름)인 60FPS 안에 화면 처리가 완료 되어야 안전함
- reflow와 repaint를 발생시키는 element의 크기, 넓이 그리고 위치의 변경은 최소화 해야 함

이어지는 내용들은 리액트 중심으로 정리함, 다른 라이브러리나 프레임워크에서도 비슷한 기능들을 제공하므로 큰 차이는 없음 또한 일반적인 JS에서도 사용가능한 기능들도 포함되어 있음

코드 분할

webpack-bundle-analyzer 와 같은 자바스크립트 번들 크기 분석도구를 이용해 최초화면에서 사용하지 않는 모듈 중 용량이 큰 모듈을 식별하고 이를 사용하는 컴포넌트나 페이지를 분할해서 번들 크기를 줄이는 것이 필요함

자체 번들 사이즈 줄이기

적절하게 번들을 잘 분할 했다면 번들 자체의 사이즈를 줄이는 것도 시도해 봐야한다. 사용하지 않는 모듈들에 대한 import를 줄이고 필요 없는 코드는 삭제 해야한다. https://bundlephobia.com/ 나 VS Code의 import cost 플러그인을 활용하여 사용한 라이브러리의 번들 사이즈를 확인하고 더 효율적인 사이즈의 라이브러리 교체 등을 고민해 봐야합니다.

React Server Component

번들크기 줄이는데 활용 가능, 동일한 api를 컴포넌트 트리에서 여러분 부르게 되는 api waterfall 현상을 막아줌

컴포넌트 및 모듈 지연로딩

컴포넌트 분할이 적용되면 동적로딩을 이용해 분할된 컴포넌트를 최초화면 로딩 이후 필요시 로드해서 사용해야 함.

동적로딩은 promise 기반으로 작성되어있고 react에서 제공하는 lazy와 suspense를 이용해 손쉽게 구현이 가능함,

지연로딩은 페이지 기반으로 구현하는 게 가장 손쉬우며, 컴포넌트나 모듈 단위로 적용하는 것도 가능함

컴포넌트 및 모듈 사전로딩

지연로딩이 적용되어 있을 경우, 최초로딩 후 해당 컴포넌트나 모듈을 필요시 로드하는 시간이 소요되므로 js 로드에 따른 불필요한 UI 지연을 막기 위해 사전로딩을 적용해서 보완할 필요성이 있음

분할된 번들의 크기가 충분히 작아서 번들로드에 소요시간이 짧을 경우, 특정 이벤트 발생을 예측하고 사전로딩을 적용하면 효율적임.
- 버튼의 마우스 오버의 경우, 높은 확률로 마우스 클릭을 예측할 수 있으므로 마우스 오버 이벤트 발생시 마우스 클릭시 호출할 컴포넌트를 미리 호드하는 것이 효율적인 방안.
분할된 번들의 크기가 클 경우, 최초 화면 로드 후에 해당 번들을 로드하는 것이 좋음
- react의 경우 useEffect를 사용해서 최초로드 후에 동적로드 되도록 구현 가능

이미지 크기 최적화

네트워크로 로드되는 실제 이미지 크기가 디스플레이되는 이미지 크기보다 과도하게 클 경우 이미지 크기 조절 필요

이미지 크기를 직접 줄이는 방법, 프론트엔드 번들에 포함되는 이미지라면 상황에 맞는 이미지로 크기나 확장자를 최적화 함.
CDN을 활용하는 방법, CDN이 콘텐츠 전진배치를 통해 네트워크 속도도 향상시키지만 파일확장자나 이미지 크기를 조절하는 용도로 사용이 가능함.
서버를 직접 사용해야 하는 경우, 서버에서 파일 확장자나 크기를 요청에 따라 변환해 줄 수 있는 기능을 서버에 추가 해야 함

비트맵 이미지의 경우, 압축률이 뛰어난 WebP 방식을 사용하는 것을 권장함.

브라우저에서 WebP 확장자를 지원하지 않은 경우를 대비해서 (하방지원 필요시) jpg 확장자의 이미지를 로드할 수 있도록 화면을 구현해서 브라우저 하방호환성을 지킬 필요가 있음

이미지 지연로딩

프론트엔드에서 이미지는 네트워크 자원을 가장 많이 소모하는 요소이다. 때문에 이미지의 크기가 화면의 성능에 영향을 줄 경우, 사용자가 인식하는 범위의 이미지를 먼저 로드하고 그 외의 이미지들의 불러오기는 지연시켜 네트워크 자원을 효율적으로 사용해야 한다. 단, UI요소는 지연로딩의 대상으로 삼지 않는 것이 일반적이다.

web API인 intersection Observer 사용을 권장하며, 브라우저 버전이 낮아서 intersection Observer 를 사용하지 못할 경우에는 뷰포트와 객체의 위치를 검토해서 지연로딩을 구현하는 방식을 채택해야 함

이미지 사전로딩

컴포넌트 지연로딩을 적용했을 때 (특히 모듈단위로 적용시) 컴포넌트 로드 전 UI용 이미지는 사전로딩을 통해 먼저 불러온 뒤 컴포넌트를 활성화 해야 UI에 어색함이 발생하지 않음 e.g. 모달창의 닫기 버튼이 모달창이 뜬 뒤에 나타나는 현상 방지

폰트 최적화

폰트의 로드 시점 관련

폰트가 로드되기 전까지 텍스트를 보여줄 지 여부에 따라 FOUT(flash of unstyled text) 방식과 FOIT(flash of invisible text) 방식으로 구분됨. 엣지 브라우저는 FOUT, 크롬은 FOIT이나 3초안에 로드되지 않으면 FOUT를 따름. 중요한 문자열은 FOUT 방식을 따르는 것이 사용자 경험에 좋을 수 있음. @font-face 의 font-display 속성으로 조절이 가능함

폰트의 파일 크기 관련

WOFF2, WOFF, TTF 의 순으로 용량이 커지므로 웹폰트를 사용하는 것이 효율적임, 단 브라우저의 종류와 버전에 따라 지원여부가 달라지므로 @font-face 의 src 속성을 이용해서 확장자 사용여부에 따라 적용될 수 있도록 구현 필요
특정 문자열에만 사용하는 폰트의 경우 서브셋으로 폰트를 추출해서 용량을 줄일 수 있음

CSS 애니메이션 최적화

크롬 개발자 도구의 performance 등을 이용해서 화면의 갱신주기 안에 애니메이션이 정상적으로 완료 되는지 확인해야 함. 렌더링 비용이 비싼 reflow나 repaint가 과도하게 발생해서 애니메이션이 지연되고 있다면, reflow나 repaint 를 발생시키지 않는 transform 이나 opacity 속성을 이용해서 애니메이션을 구현하는 것을 검토해 해야 함

CSS 최적화

불필요한 CSS 가 있는지 확인하고 제거해야 함. 사용하지 않는 CSS의 경우, purgeCSS와 같은 분석도구를 이용해서 제거할 수 있음. 중복된 CSS도 확인 후 제거해야 함

캐시

캐시관리는 서버에서 제공하는 응답 헤더의 cach-control을 통해 관리해야 함, 아래와 같이 관리하는 것이 일반적이며, 프로젝트 상황에 맞게 변경해서 사용해야 함

html => no-cache
js, css, image => public, max-age 1년
그 외 => no-store

캐시 사용 심화

- 검증 헤더와 조건부 요청

응답해더 : last

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면

• 304 Not Modified + 헤더 메타 정보만 응답(바디X)

• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신

• 클라이언트는 캐시에 저장되어 있는 데이터 재활용

• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

• 매우 실용적인 해결책

• Cache-Control: max-age

캐시 유효 시간, 초 단위

• Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

• Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨

(메모리에서 사용하고 최대한 빨리 삭제)

• 검증 헤더 (Validator)

ETag: "v1.0", ETag: "asid93jkrh2l"

Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

• 조건부 요청 헤더

If-Match, If-None-Match: ETag 값 사용

If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

프록시 캐시 관련 ( CDN )

프록시 서버에 저장되는 캐시를 public, 사용자 개인을 위한 브라우저에 저장되는 캐시를 private로 구분함.

• Cache-Control: public

응답이 public 캐시에 저장되어도 됨

• Cache-Control: private

응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)

N클라이언트 N서버 문제 - 서비스가 커지면 커질수록 발생할 수 밖에 없음

BFF (Back-end for Front-end)

프론트엔드만을 위한 백엔드 서비스를 만드는 기법 - 클라이언트 중심 메시지 처리 전략

grapql을 활용하여 underfetching과 overfetching 문제까지 해결

Endpoint를 일원화 하고 규격을 통일하여 불필요한 코드를 줄이고 유지보수성을 늘릴 수 있음

CROS문제를 해결하면서 BFF만 퍼블릭 네트워크에 나오면 되기 때문에 보안문제까지 해결 가능

[CI/CD Jenkins] Shared Libraries(공유 라이브러리) 활용

B급 코딩 — Mon, 9 Jan 2023 22:30:43 +0900

Jenkins(이하 젠킨스) 는 CI/CD 환경을 구축하기 위한 오픈소스 도구이다.

워낙 유명한 도구이니 자세한 설명은 생략하겠다.

요즘은 AWS, GCP, Azure에서 강력한 managed(지들이 운영하는) CI/CD 서비스를 내고 있고

Circle CI 등 유료 툴들이 나오면서 그 위상이 많이 떨어진게 사실이다.

하지만 특정 환경에 종속되는 CI/CD 환경 구축을 원하지 않거나,

비용적인 측면을 고려했을 때 무료 오픈소스라는 점에서 여전히 많이 선택되는 툴임은 분명하다.

젠킨스를 이용하는 방법과 방식에는 여러가지가 있겠지만 Pipeline을 사용하는 것이 대다수이다.

이번 포스팅에서는 젠킨스의 Pipeline 소스코드들을 모듈화해서 관리할 수 있는 Jenkins Library에 대해 다루겠다.

1. Jenkins 파이프라인

위 이미지는 Jenkins에서 CI/CD 환경 구축을 위해 "+ 새로운 item" 버튼을 누르면 나타나는 화면이다. (버전에 따라 조금 다를 수도 있다)

이 선택지들 중 앞서 언급한 대로 두번째 Pipeline을 많이 사용할 것이다.

Pipeline을 많이 쓰는 이유는 단계를 나눠 어플리케이션의 빌드 및 배포를 한 눈에 볼 수 있고 유지보수성이 뛰어나기 때문이다.

Pipeline은 step과 stage 별로 각 단계에 해야할 어플리케이션 빌드나 배포에 필요한 작업들을 나눠서 관리 할 수 있고,

코드 형태이기 때문에 필요한 상수들을 전역변수로 만들고 재사용할 수도 있다.

2. Jenkins Shared Libraries 개요

여기에 유지보수성과 확장성을 극대화 해주는 젠킨스 도구가 있다.

바로 Shared Libraries, 일명 공유 라이브러리이다.

이제부터 Pipeline과 함께 공유 라이브러리가 필요한 이유를 알아보자.

아래는 AWS환경에 EKS, 도커, sonarqube 정적 분석 등을 활용하여 배포하는 pipeline 코드 예시이다.

pipeline{
	agent any
    environment{
    	GIT_COMMIT_HASH = sh ( script: "git log -n 1 --pretty=format:'%H'", returnStdout:true)
        GIT_COMMIT_TAG = "${GIT_COMMIT_HASH.substring(0,8)}"
    	SYSTEM_NAME = sh (returnStdout:true,
        	script: """
            		basename \$(git remote get-url origin) | sed -e "s/.git\$//" | sed -e "s/\\nn//"
					""")
		def sonarqubeScannerHome = tool name:'SONARQUBE_SCANNER', thpe:'hudson.plugins.sonar.SonarRunnerInstallation'        
    }
	stages{
    
    	stage('step1 : Application Build') {
        
        	steps{
            	gradle 빌드 내용
            
            }
        }
        stage('step2 : SonarQube Analytics') {
        
        	steps{
            	sonar 실행 내용
            
            }
        }
        stage('step3 : Docker Image Build and ECR Push') {
        
        	steps{
            	docker 내용
            
            }
        }
        stage('step4 : Deploy EKS') {
        
        	steps{
            	EKS qovh
            
            }
        }
    }
	post{
    	success{
        	slack webhook
        }
        failure{
        	slack webhook
        }
    
    }


}

만약 시스템이 MSA구성이 되어 있고 spring 프레임워크를 사용하는 어플리케이션이 15개라고 하면 위 Jenkinsfile이 15개 이상이 필요할 것이다.

그러면 15개의 Jenkinsfile 내용이 얼마나 다를까?

거의 비슷할 것이며 반복적으로 기술할 내용이 많을 것이다.

이는 곧 어느 한 부분이 변경이 있다면 15개를 모두 고쳐야 한다는 뜻이다.

이것을 최소화 하기 위해 쓰이는 것이 공유 라이브러리다.

3. Jenkins Shared Libraries 구성

공유 라이브러리 프로젝트의 구조는 아래와 같다.

(root)
+- src                     # Groovy 소스 파일
|   +- org
|       +- foo
|           +- Bar.groovy  # for org.foo.Bar class
+- vars
|   +- foo.groovy          # 전역으로 foo변수 사용 가능
+- resources               # 라이브러리 내부에서만 쓰이는 리소스들
|   +- org
|       +- foo
|           +- bar.json    # 정직 데이터

우리가 주목해야하는 부분은 vars 이다.

여기에 공통이 되는 빌드부분, 소나큐브 검사 부분, 도커 빌드 부분, 쿠버네틱스 배포 부분을 넣어서 나눠서 관리하면 된다.

(root)
+- vars
|   +- applicationBuild.groovy          # spring 빌드 관련 파이프라인 코드
|   +- sonarQubeInspect.groovy          # 소나큐브 검사 관련 파이프라인 코드
|   +- dockerBuild.groovy               # 도커빌드 관련 파이프라인 코드
|   +- k8sDeploy.groovy                 # 쿠버네틱스 배포 관련 파이프라인 코드

이런 식으로 구성이 가능하다.

이 중 하나의 파일(dockerBuild.groovy)의 코드 구성을 간략하게 보면 아래와 같다.

// dockerBuild.goovy

def call(string systemName, string repoUrl) {
	
    def DOCKER_TAG = systemName.trim()
    def DOCKER_REPO = ${env.BASE_REPO_URL}+"/"+repoUrl.trim()
	
	sh"""
    	
        docker build -t ${DOCKER_TAG}
        docker tag ${DOCKER_TAG} latest
        docker push ${DOCKER_REPO}
        
    """

}

그리고 실제 Jenkinsfile에서는 아래와 같이 공유 라이브러리에 있는걸 불러다 쓰면 된다.

#!groovy
@Library('jenkins_library') _    //공유 라이브러리 import 부분, 젠킨스 설정에 있는 값
pipeline {
	agent any
    environment{
    	사용할 환경변수들
    }
	stages{
    	stage('clone'){
        	steps{
            	git clone           // 이부분도 공유라이브러리로 모듈화 가능
            }
        }
        stage('STEP1 : spring build'){
        	steps{
            	applicationBuild('systemName')   // 공유라이브러리로 만든 groovy 파일이름 호출
            }
        }
        stage('STEP2 : sonarQube inspect'){
        	steps{
            	sonarQubeInspect('systemName')   // 공유라이브러리로 만든 groovy 파일이름 호출
            }
        }
        stage('STEP3 : docker build'){
        	steps{
            	dockerBuild('systemName', 'respoUrl')   // 공유라이브러리로 만든 groovy 파일이름 호출
            }
        }
        stage('STEP4 : k8s deploy'){
        	steps{
            	applicationBuild('systemName', 'namespace', 'yamlPath')   // 공유라이브러리로 만든 groovy 파일이름 호출
            }
        }
    }
}

훨씬 간편해 졌다.

또한 공통되는 모듈이 중앙화 되었기 때문에 변화에 재빠르게 대응할 수 있게 되었다.

4. Jenkins Shared Libraries 사용을 위한 젠킨스 설정

젠킨스 공유 라이브러리 사용을 하려면 공유 라이브러리 프로젝트를 git에 레포를 하나 만들어서 올린다. 이후

젠킨스 설정에 들어가면 나오는 위와 같은 화면에서 해당 git 주소를 입력하고 Name 을 정하여 위 Jenkinsfile 코드의 맨 윗줄에 넣으면 사용할 수 있다.

[CI/CD Pipeline] docker BaseImage Pipeline 구축

B급 코딩 — Sun, 23 Oct 2022 23:41:36 +0900

도커 이미지 구조

빠른 서비스 제공과 트렌드 반영을 위해 대두되고 있는 DevOps 개념 때문에 CI/CD는 이제 필수가 되었다.

CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공하는 것을 의미한다.

이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부른다.

MSA가 도입되면서 어플리케이션은 많아지고 CI/CD 파이프라인도 증가했다.

또한 Docker, kubernetes 등 컨테이너 기반 배포가 도입되면서 CI/CD 파이프라인은 더욱 복잡해졌고 이것들 역시 관리 포인트가 되었다.

DevOps 개발자라는 직군이 나온 이유가 여기에 있는 듯 하다.

코드양이 많아지면 리팩토링을 통해 공통 모듈들을 도출하고 구조화 하듯 CI/CD 파이프라인도 관리 포인트가 늘어남으로써 리팩토링과 비슷한 과정들이 필요해 졌다.

이 과정들은 코드 리팩토링처럼 개발자에 따라 다르고 기업의 개발문화에 따라 많이 다를 것이다.

이번 포스트에서는 그 중 하나의 과정인 Docker Base Image 파이프라인에 대해 정리해 보겠다.

1. base image에 CI/CD 파이프라인이 필요한 이유

보통 Base Image라 함은 어플리케이션이 돌아갈 OS나 언어 환경으로 만들어진 이미지를 말한다.

Docker Hub에서 필요한 이미지를 검색해 Base Image로 사용하곤 한다.

dockerfile 예시

이렇게 Docker Hub에서 검색한 이미지를 도커 파일에 FROM으로 놓고 어플리케이션에 필요한 작업들을 기술한다.

이후 docker build 명령어를 활용해 커스텀 이미지로 빌드한 후

registry(docker hub, ECR 등)에 푸시하고 이를 배포하여 사용한다.

하지만 프로젝트에서 쓰일 베이스 이미지는 Docker Hub에서 바로 받아오는 형태로 쓰는 것보다 private registry에 올려두고 해당 이미지를 베이스로 사용하는 것이 좋다.

이유는 Docker Hub의 네트워크 문제 등으로 인해 베이스 이미지를 받아오는데 실패할 수 있기 때문이다.

만약 spring 프로젝트의 베이스 이미지를 adoptopenjdk/openjdk11를 쓴다고 하면

보통은 프로젝트 Dockerfile에

FROM adoptopenjdk/openjdk11
CMD ["./mvnw", "clean", "package"]
ARG JAR_FILE_PATH=target/*.jar
COPY ${JAR_FILE_PATH} app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

이런 형태로 기술할 것이다.

하지만 위에서 언급했듯이 맨 위 From 절을 프로젝트에서 가지고 있는 private registry에 올려둔 base 이미지를 사용하는 것이 좋다.

Docker Hub에서 adoptopenjdk/openjdk11 이미지를 pull 받아서

docker tag 명령어를 이용해 이미지 이름을 base-spring-image로 변경하고 ECR에 push 한다.

AWS ECR 화면

위 화면처럼 ECR에 base-spring-image가 올라왔다면

프로젝트 dockerfile에서도 FROM 부분에 ECR의 URI 부분을 적어두면 프로젝트 이미지 빌드때도 해당 ECR에 있는 base image를 가져와서 도커 빌드를 수행할 것이다.

하지만 이 방법은 한번의 명령어를 서버에 접속해 수행한 것 뿐이다.

만약 이 작업을 다시 해야한다면 어떨까?

만약 MSA로 구성된 spring 프로젝트 20개 컨테이너에 git이 필요하게 됬다면 어떨까?

모든 프로젝트의 Dockerfile에 git 설치 명령을 넣어서 새로 빌드할 것인가?

좀 더 현실적으로 aws의 로깅 서비스인 cloud watch에서 서버의 health 로그를 수집하려 하면 프로젝트 20개 컨테이너에 해당 agent를 설치해야한다.

앞선 예시처럼 모든 프로젝트 Dockerfile에 설치 명령을 넣어서 빌드해야할까?

이는 매우 비효율적이고 CI/CD 사상에서도 벗어나 있다.

처음부터 Dockerfile 형태로 base image를 정의해두었다면 여기에만 프로젝트 공통으로 해야할 명령을 수행한 후 이미지 빌드를 하면 전체 프로젝트에 적용되게 된다.

2. 구성 예시

아래는 spring 베이스 이미지의 예시이다.

FROM adoptopenjdk/openjdk11

초기에는 프로젝트의 기반이 되는 docker hub의 base image만 만들어 둔다. 파일명은 spring.dockerfile

이를 pipeline-template란 이름의 Git 레포지토리를 만들고 Docker라는 폴더 아래 두고 커밋해 둔다.

pipeline-template

ㄴDocker

ㄴspring.dockerfile

이제 spring 프로젝트의 컨테이너에 공통적으로 필요한 사항은 이 파일을 업데이트하여 처리한다.

만약 AWS Cloud Watch Agent를 설치한다면

FROM adoptopenjdk/openjdk11
RUN curl -O https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
RUN dbkg -i -E ./amazon-cloudwatch-agent.deb

위처럼 cloud watch agent를 다운로드 받아서 실행시키는 명령을 실행한다.

이 폴더 구조는 프로젝트에 만약 빅데이터 컨테이너들이 들어와 python 기반의 베이스 이미지가 필요하다면

python.dockerfile로 만들어두고 같이 관리하면 된다.

3. 젠킨스 설정

젠킨스에 item을 하나 만들고 베이스 이미지 빌드, 푸시과정을 버튼하나로 자동화 해보자

pipeline 으로 도커 베이스 이미지를 컨트롤 할 item을 생성한다.

pipeline{

	agent any
    
    parameters{
    
    	string(name:"BASE_IMAGE_TYPE", defaultValue:"spring", description:"base image type")
    }
    
    stage('Clone') {
             
            steps {
                echo 'Clone'
                git branch: 'master', credentialsId: 'credentail id', url: 'pipeline template git 주소'
            }
    }
	stage('Docker Push') {
    
    	steps{
        
        	sh '''
            //registry 로그인
            aws ecr get-login-password --region 리전값 | docker login --username AWS --password-stdin ECR주소
            cd docker
            //도커 빌드
            docker build -t base-spring-image ${params.BASE_IMAGE_TYPE}.dockerfile
            //도커 태그
            docker tag base-doc-image:latest ECR주소/base-doc-image:latest
            docker push ECR주소/base-doc-image:latest
            '''
        }
    
    }
}

이 item 빌드를 시작하면 parameter로 base image type을 받는다

여기에 base image type을 어떤 것으로 할 것인지 결정하면 된다.

그러면 Docker push 스테이지에서 해당 값으로 된 dockerfile을 빌드하게 된다.

만약 python 베이스 이미지에 작업을 했따면 parameter로 python을 넘기면 된다.

이렇게 하면 베이스 이미지를 지속적으로 배포할 수 있는 체계가 만들어 진 것이다.

프로젝트 컨테이너 전체에 영향을 줘야하는 작업이나 베이스 이미지 수정 등을 하나의 dockerfile만 수정한 뒤 해당 파이프라인을 수행하면 베이스 이미지가 수정되고 이를 통해 프로젝트 dockerfile이 수정된 베이스 이미지를 기반으로 컨테이너를 생성하게 될 것이다.

쿠버네틱스로 가는 발판② - GCP에서 Docker(도커) 활용기

B급 코딩 — Sat, 4 Jun 2022 16:26:01 +0900

지난 포스팅에서 도커의 기반이 되는 컨테이너 기술과 기본적인 도커의 개념들을 살펴봤다.

쿠버네틱스로 가는 발판① - Docker(도커) 기본 개념

회사에서 새로운 프로젝트를 들어가면서 쿠버네틱스를 사용할 일이 생겼다. 지금까지 프론트엔드를 기반으로 개발 커리어를 쌓아왔는데 백엔드를 깊게 파볼 기회가 생겼다. 본 프로젝트에 들

bgradecoding.tistory.com

이번 포스팅에서는 직접 GCP(Google Cloud Platform)에 도커를 설치해보고 도커의 라이프싸이클을 직접 명령어로 실행해 볼 것이다.

일단 GCP에 VM 인스턴스를 하나 생성하자.

앞 포스팅에서도 언급했듯이 도커는 컨테이너 기술을 활용한 소프트웨어로 리눅스 커널 기능을 활용하기 때문에 다른 OS보다는 리눅스 계열에서 사용하는 것이 좋다.

GCP 콘솔에 접속하여 Compute engine 메뉴에 접속하여 VM 인스턴스를 클릭하면 아래와 같은 화면이 나온다.

여기서 인스턴스 만들기를 클릭한다.

대부분 기본으로 세팅하고 OS를 우분투로 바꿔준다.

인스턴스가 생성되면 SSH를 눌러 터미널을 실행시킨다.

터미널이 나오면 sudo su 명령어를 통해 루트 권한을 얻는다

(이 포스팅의 명령어들을 설치 시를 제외하고는 sudo를 붙이지 않는다. 루트 권한이 없다면 sudo를 붙여서 수행해야한다.)

이제 도커를 설치하자.

아래 명령들을 순차적으로 실행하자.

$ sudo apt-get update

$ sudo apt-get -y install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

Docker의 Official GPG Key 를 등록한다.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

stable repository 를 등록해줍니다.

echo \ "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

$ sudo apt-get update

$ sudo apt-get install docker-ce docker-ce-cli containerd.io

docker --version

위 명령어를 실행했을때 도커 버전이 출력되면 설치는 성공적으로 끝난 것이다.

이제 부터 도커 라이프사이클에 맞춘 명령어들을 수행해 보겠다.

먼저 도커 허브에 있는 nginx 이미지를 다운로드 받아 컨테이너로 실행시켜보겠다.

도커 허브 레지스트리에서 nginx를 pull 받는다.

docker pull nginx

다운 받은 이미지를 컨테이너화 한다.

docker create -p 80:80 --name nx nginx

( 앞의 80이 VM 포트이고 뒤의 80이 컨테이너의 포트이다. )

생성된 컨테이너를 확인한다.

docker ps -a

해당 컨테이너 ID로 컨테이너를 메모리에 띄운다.

docker start 42ac654b8b45

브라우저에 외부 IP 80포트로 접속해 보면 nginx가 실행된 것을 볼 수 있다.

이후 중지 명령과 삭제 명령들을 차례로 수행한다.

docker stop 493979b3a04d

docker rm 493979b3a04d

docker rmi nginx

컨테이너가 실행되고 있는 중에는 이미지가 삭제되지 않으니 주의해야 한다.

rmi -f 옵션을 이용하면 컨테이너가 떠있어도 강제 이미지 삭제가 가능한다.

이번에는 RUN 명령어를 통해 Create와 Start를 함께 수행해 보자

레지스트리에서 tomcat 이미지를 다운로드 한 후 아래 명령을 수행해 보자.

docker run -d --name tc -p 80:8080 tomcat

브라우저를 통해 잘 실행되는 것을 볼 수 있다.

이외 몇가지 유용한 명령어들이 있다.

컨테이너 내부 셸 실행

docker exec -it tc(수행중인 컨테이너 이름) /bin/bash

컨테이너 로그 확인

docker logs tc

기본적인 로그나 에러로그를 확인이 가능하다.

로컬 파일을 컨테이너로 복사, 컨테이너 파일을 로컬로 복사, 컨테이너간 파일 복사

docker cp <path> <to container>:<path>
docker cp <from container>:<path> <path>
docker cp : <from container>:<path> <to container>:<path>

임시 컨테이너 생성

docker run -d -p 80:8080 --rm --name tc tomcat

--rm 옵션을 주면 컨테이너를 내리는 순간 삭제된다.

다음 포스팅에서는 해당 명령어들과 추가적인 명령어들을 가지고 DB를 가진 서비스 하나를 도커로 실행해보도록 하겠다.

쿠버네틱스로 가는 발판① - Docker(도커) 기본 개념

B급 코딩 — Tue, 31 May 2022 01:25:34 +0900

회사에서 새로운 프로젝트를 들어가면서 쿠버네틱스를 사용할 일이 생겼다.

지금까지 프론트엔드를 기반으로 개발 커리어를 쌓아왔는데 백엔드를 깊게 파볼 기회가 생겼다.

본 프로젝트에 들어가기 전에 쿠버네틱스에 대한 전반적인 내용을 정리하며 공부해 볼 계획이다.

찾아보니 쿠버네틱스 자격증도 존재하는 것을 알게 되었다.

이 자격증 취득을 목표로 일단은 달려볼 생각이다.

1. 컨테이너(Container) 기술

도커는 컨테이너 기술을 지원하는 여러 프로젝트들 중 하나이며 가장 인기 있는 녀석이다.

- 컨테이너 기술의 역사
2000년대 중반 리눅스에 내장된 LXC(LinuX Container)를 시작으로 계속 존재해 왔음
도커와 클라우드 기반 컴퓨팅 시대가 도래하면서 각광받기 시작한 기술

도커는 이러한 컨테이너 기술의 표준이라고 볼 수 있을 정도로 많이 쓰인다.

- 컨테이너 개념
어플리케이션을 구동하는 격리된 컴퓨팅 환경

예전에는 아래와 같은 말들을 많이 했다.

"인스턴스 하나 만들어서 서비스 띄우자."

"VM 하나 새로 만들어서 스케일 업하자."

새로운 어플리케이션을 구동하기 위해 가상화를 이용하자는 의미이다.

기본적으로 이 가상화를 위해서는 하이퍼바이저 기반의 OS(운영체제)들이 필요했다.

이는 매우 무겁고 유연하지 못한 방법이였다.

이에 비해 도커 등을 활용한 컨테이너 기술은 운영체제를 제외하고 어플리케이션 실행에 필요한 모든 파일 및 환경들만을 패키징 한 형태로 서비스를 구동한다.

기존 하이퍼바이저와 Guest OS가 하던 역할을 도커 엔진이 하게 된 것이다.

이처럼 도커 엔진을 활용한 컨테이너는 가상머신처럼 하드웨어를 전부 구현하지 않기 때문에 빠른 실행이 가능하다.

또한 하이퍼바이저가 차지하던 공간을 더 활용해 어플리케이션에 투자할 수 있게 되었다.

이러한 컨테이너 기술이 가능한 기술적 베이스는 리눅스 커널에 있다.

커널은 메모리나 저장장치 내에서 운영체제의 주소 공간을 분리하여 필요한 여러 서비스를 제공하는 역할을 한다.

정확히는 리눅스 커널의 네임 스페이스와 cgroups를 이용하여 가상화가 가능하다.

- 리눅스 네임 스페이스
각 프로세스가 파일 시스템 마운트, 네트워크, 유저, 호스트 네임 등에 대해 시스템에 독립 뷰를 제공하는 기능
이 기술로 프로세스 별 간섭이 없기 때문에 하나의 OS에서 라이브러리 충돌 등이 일어나지 않게 어플리케이션을 동작 시킬 수 있음.

- 리눅스 컨트롤 그룹(cgroups)
프로세스로 소비할 수 있는 리소스 양(CPU, 메모리, I/O, 네트워크 대역대, device 노드 등)을 제한하고 컨트롤 할 수 있는 기능
이 기술을 활용하여 프로세스 별 리소스 분배를 하고 어플리케이션을 여러개 동작 시킬 수 있음.

2. Docker(도커)

앞서 언급했듯이 컨테이너 기반의 가상화 기술은 계속 존재해 왔다.

이러한 소프트웨어에는 OpenVZ, LXC, Lunix vServer, FreeBSD Jail, Solaris Zones, Docker 등이 있으며, 그 중 최근 가상화 및 클라우드 컴퓨팅 영역에서 가장 주목받고 있는 것이 바로 도커이다.

요즘 백엔드 개발 및 아키텍처 방식으로 각광받는 MSA(Micro Service Architect) 역시 도커를 유명하게 하는데 한 몫 했다.

도커는 PaaS, SaaS와 같은 다양한 클라우드 서비스 모델과 같이 사용이 가능 하다.

도커의 주요 개념들을 보자면 이미지와 컨테이너를 들 수 있다.

Java 언어와 비교하자면 class를 작성해두고 new를 통해 인스턴스를 생성하는 것과 비슷하다.

이미지는 class이고 인스턴스는 컨테이너로 볼 수 있다.

- 이미지 : 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 만든 하나의 파일
- 컨테이너 : 이미지를 격리하여 독립된 공간에서 실행한 가상 환경

개발한 소스코드들의 레파지토리(github 등)가 존재하듯 도커의 이미지들에도 레지스트리가 있다.

도커 허브가 대표적이며 이곳에 만들어 둔 이미지를 pull 하거나 commit 할 수 있다.

Docker Hub Container Image Library | App Containerization

Build and Ship any Application Anywhere Docker Hub is the world's easiest way to create, manage, and deliver your team's container applications.

hub.docker.com

도커는 이러한 장점들을 많이 가지고 있지만 기존의 모놀리틱 애플리케이션이 서비스가 커지면서 겪어온 한계들과 마찬가지로 한계가 있다.

서비스가 커지면 커질 수록 관리해야 하는 컨테이너의 양이 급격히 증가하여 관리가 어려워 진다.

이에 따른 배포 및 컨테이너 배치 전략이 필요하고 스케일-인, 스케일-아웃에 어려움을 가지고 있다.

이런 문제를 해결하기 위해 등장한 것이 쿠버네틱스다.

쿠버네틱스는 좀 더 레벨업을 한 이후에 개념부터 차근차근 알아 볼 계획이고 도커의 실제 사용법에 대해 좀 더 알아보자.

1) 도커 설치

도커는 앞서 설명했듯이 컨테이너 기술을 기반으로 동작하고 이 컨테이너 기술은 리눅스 커널을 사용한다.

따라서 리눅스 이외의 OS에서 도커를 설치하려면 결국 하이퍼바이저 위에 리눅스 OS를 띄워서 사용해야한다.

매우 번거로운 작업이 아닐 수 없다.

도커를 맛보기로 사용해 볼 때는 여러 클라우드 서비스의 무료 티어(AWS free Tier, GCP 가입 크리딧 등)을 이용해 리눅스에서 연습해 보는 것을 권장한다.

설치는 우분투를 기준으로

$ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh

반드시 관리자 권한을 사용하여 설치한다.

2) 도커 라이프사이클

도커는 원하는 이미지를 레지스트리에서 pull 해와서 이미지를 다운로드하면서 시작된다.

다운받은 이미지를 create하여 컨테이너로 만들고 start하여 메모리에 띄운다.

사용이 끝나면 메모리에 떠 있는 컨테이너를 stop 하고 컨테이너를 rm으로 삭제하고

이미지까지 삭제하려면 rmi를 수행한다.

이때 컨테이너를 만든 이후 필요한 것들을 추가하여 커스텀 하면 해당 컨테이너를 이미지화 해서 commit 할 수 있다.

이를 push하여 레지스트리에 저장해 두고 다른곳에서 pull해서 쓸 수 있다.

이것이 간단한 도커의 라이프 사이클이다.

다음 포스팅에서는 실제 우분투 환경에서 도커 명령어를 사용하여 도커 라이프 사이클들을 직접 돌려보겠다.

[React] Flux 패턴과 MVC 패턴 (feat. Redux)

B급 코딩 — Fri, 8 Apr 2022 23:01:24 +0900

프로그래밍 개발에는 여러가지 디자인 패턴이 존재한다.

특정 프레임워크를 사용하면 코드의 가독성 및 유지보수성, 개발용이성 등을 고려해 특정 디자인 패턴을 사용자에게 강제화 하기도 한다.

대표적으로 Java 진영의 Spring Framework가 있다. 이는 MVC 디자인 패턴을 어느정도 강요하여 개발을 유도한다.

프론트 엔드 개발이 복잡해지면서 백엔드 쪽에서만 논의되어 오던 디자인 패턴을 자연스럽게 프론트에서도 고민하게 되었다. 현시점 가장 인기있는 프론트엔드 개발도구인 React는 Flux 패턴이란 것을 지향하고 있다.

Facebook: MVC Does Not Scale, Use Flux Instead [Updated]

This article has been updated based on community and Jing Chen (Facebook)’s reaction. (See the Update section below.) Facebook came to the conclusion that MVC does not scale up for their needs and has decided to use a different pattern instead: Flux.

www.infoq.com

위 글에서처럼 페이스북(현 메타)은 MVC 패턴이 스케일업 하기에는 좋지 않고 그래서 Flux 패턴을 개발했다고 한다.

MVC는 규모가 커질수록 controller의 규모가 커지면서 V와 M 사이의 데이터 복잡도, M들간의 종속 업데이트로 개발이 어려워진다.

Flux는 데이터가 한방향으로 흘러 직관적이고 규모가 커져도 각 역할에 맞는 개발이 가능하다고 말한다.

하지만 이에 반하는 의견을 가진 개발자 집단도 존재하여 아직도 무엇이 정답이다라는 결론은 나오지 않은 상태이다.

정답이 과연 존재하는가도 의문이긴 하다.

1. 자바스크립트 간단 MVC를 적용하기

간단한 Todo 리스트 관리를 MVC 패턴에 맞게 작성해 보았다.

원칙은 View에서는 Dom을 그리는 것만을 집중한다.

Model은 todo 리스트가 가지고 있는 데이터의 상태 관리에만 집중한다.

controller는 유저의 행위를 이벤트로 감지하고 이를 데이터 변화가 있을시 model에 알려주고 view를 새로 그리게 하는 역할을 한다.

먼저 간단한 html을 작성해 준다.

todo List를 출력하는 영역과 입력하는 영역만 있다.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>todo MVC</title>
  </head>
  <body>
    <h1>To Do Manage MVC</h1>
    <input type="text" id="todo" />
    <button id="registerBtn">register</button>

    <h3>Todo List</h3>
    <ul id="todolist"></ul>
    <script type="text/javascript" src="./app.js"></script>
  </body>
</html>

다음으로 app.js에 MVC를 모두 작성했다.

먼저 TodoModel이다.

class TodoModel {

  constructor() {
    // todo list를 관리 할 array 변수를 관리한다.
    this.todoList = [];
  }


  // 투두 리스트를 가져갈 수 있는 메소드를 만든다.
  getTodoList() {
    return this.todoList;
  }

  // 투두가 추가 될때 리스트에 추가하는 메소드를 만든다.
  pushTodoListData(todo) {
    this.todoList.push(todo);
  }
}

다음으로 TodoView이다.

class TodoView {
  constructor(model) {
    this.model = model;
  }

  //컨트롤러 접근이 필요한 화면 요소를 만들어 준다.
  inputArea = document.getElementById('todo');
  todolist = document.getElementById('todolist')
  registerBtn = document.getElementById('registerBtn')


  //todo가 새로 생겼을 때 화면 요소를 추가하여 리턴해 주는 메소드
  createListItemNode(todo) {
    const listItemNode = document.createElement("li");
    const textNode = document.createTextNode(
      todo
    );
    listItemNode.appendChild(textNode);

    return listItemNode;
  }

  // todo가 추가되었을때 리스트 화면을 그리는 메소드
  registerTask(parentNode, childNode) {
    parentNode.appendChild(childNode);
  }
}

마지막으로 TodoController이다.

class TodoController {
  constructor(model, view) {
    this.model = model;
    this.view = view;
    this.registerEventListener(model, view);
  }


  //버튼이 클릭되었을 때를 감지한다.
  registerEventListener(model, view) {
    const registerationBtn = view.registerBtn;
    registerationBtn.addEventListener("click", () => {
      this.addTodoListData(model, view);
    });
  }

  //이벤트가 일어났다고 model과 view에 알린다.
  addTodoListData(model, view) {
    const currentInputData = view.inputArea.value;
    const todoItemNode = view.createListItemNode(currentInputData);
    const todoListParentNode = view.todolist;
    model.pushTodoListData(currentInputData);
    view.registerTask(todoListParentNode, todoItemNode);
    
  }
}

MVC 패턴에서 각 요소에 맞게 todo리스트 등록, 출력 기능을 만들어보았다.

사실 이정도의 기능만 가지고는 MVC 패턴이 스케일업시 안좋다는걸 알 수 없다.

이 기본 구조아래 기능들의 추가를 상상해 보았다.

todo를 완료 했다는 상태 업데이트 기능이 추가되면 어떻게 변할까?
Model의 단순 배열이 객체 배열로 바뀌면서 Model에는 업데이트 메소드가 생기고 View에도 적절한 출력 메소드가 생길 것이다.
Controller는 상태에 따른 분기가 생길 것이고 View나 Model보다는 많은 로직이 생길 것이다.

확실히 MVC패턴의 단점 중 하나로 나오는 Controller의 규모가 커진다는 상상할 수 있었다.

그렇다면 View와 Model의 양방향 데이터 바인딩으로 인한 개발복잡성 증가도 생길까?

만약 todo의 진행중과 완료 영역이 나눠져 있고 todo를 마우스로 드래그앤드롭 형태로 옮긴다면 어떻게 변할까?
이때 모든 이벤트를 controller에서 감지하게 한다면 불필요한 코드도 많아지고 controller는 대혼돈의 멀티버스 수준이 될 것이다.
View의 이벤트를 바로 Model에 반영하도록 바꾼다면 코드는 줄겠지만 Facebook이 말한 Model과 View의 복잡도가 늘어날 것이다.

이런 기능들이 하나 둘 늘어나 Facebook같은 규모가 된다면 충분히 페이스북이 말한 MVC의 단점이 들어날만 하다고 생각이 된다.

2. React로 Flux패턴 적용해 보기

React는 자바스크립트 UI 라이브러리로 부모 컴포넌트에서 자식 컴포넌트로 props를 내려주는 단방향 데이터 바인딩에 가깝다고 할 수 있다.

Flux | Flux

Application architecture for building user interfaces

facebook.github.io

그래서 데이터가 한방향으로만 흐를 수 있도록 action을 통해서 데이터를 바꾸고 이를 하나의 store가 통제하는 flux 패턴이 더 어울리는 것처럼 보인다.

이번에는 조금 더 업그레이드 된 todo를 React와 Context API를 활용해서 구현해 보았다.

Index.jsx

import React, { useCallback, useReducer } from "react";
import Header from "./components/header";
import TodoList from "./components/list";
import TodoInput from "./components/input";

const initialState = {
  todos: [
    {
      id: 1,
      todoName: "오늘의 할 일",
      todoStatus: "done",
    },
    {
      id: 2,
      todoName: "Blog 글쓰기",
      todoStatus: "doing",
    },
    {
      id: 3,
      todoName: "github 잔디심기",
      todoStatus: "doing",
    },
  ],
};

function reducer(state, action) {
  console.log(action, state);
  switch (action.type) {
    case "ADD_TODO":
      return {
        todos: state.todos.concat({
          ...action.todos,
          id: state.todos.length + 1,
        }),
      };
    case "REMOVE_TODO":
      return {
        ...state,
        todos: state.todos.filter((todo) => todo.id !== action.id),
      };
    case "UPDATE_TODO":
      return {
        ...state,
        todos: state.todos.map((todo) =>
          todo.id === action.id
            ? {
                ...todo,
                todoStatus: todo.todoStatus === "done" ? "doing" : "done",
              }
            : todo
        ),
      };
    default:
      return state;
  }
}

function countTodo(todos) {
  return todos.filter((todo) => todo.todoStatus === "doing").length;
}

export const TodoDispatch = React.createContext(null);
export const TodoState = React.createContext(null);

const Jinho = () => {
  const [state, dispatch] = useReducer(reducer, initialState);
  const { todos } = state;

  const countTodoFunction = useCallback(() => countTodo(todos), [todos]);

  return (
    <TodoState.Provider value={state}>
      <TodoDispatch.Provider value={dispatch}>
        <div className="container">
          <Header count={countTodoFunction(todos)} />
          <TodoList />
          <TodoInput />
        </div>
      </TodoDispatch.Provider>
    </TodoState.Provider>
  );
};

export default Jinho;

TodoList.jsx

import React, { useContext } from "react";
import TodoItem from "./TodoItem";
import { TodoState } from "../../../jinho";

const TodoList = () => {
  const { todos } = useContext(TodoState);

  return (
    <>
      {todos.map((todo) => (
        <TodoItem
          key={todo.id}
          todoId={todo.id}
          todoName={todo.todoName}
          todoStatus={todo.todoStatus}
        />
      ))}
    </>
  );
};

export default TodoList;

TodoItem.jsx

import React, { useContext } from "react";
import { TodoDispatch } from "../../../jinho";

const TodoItem = React.memo(function TodoItem(props) {
  const { todoId, todoName, todoStatus } = props;
  const dispatch = useContext(TodoDispatch);
  return (
    <li>
      <input
        type="checkbox"
        checked={todoStatus === "done" ? true : false}
        onChange={() => dispatch({ type: "UPDATE_TODO", id: todoId })}
      />
      <span>{todoName}</span>
    </li>
  );
});

export default TodoItem;

TodoInput.jsx

import React, { useContext, useRef } from "react";
import { TodoDispatch } from "../../../jinho";

const TodoInput = React.memo(function TodoInput() {
  const dispatch = useContext(TodoDispatch);
  const inputRef = useRef();
  return (
    <>
      <input type="text" ref={inputRef} placeholder="할 일을 입력하세요" />
      <button
        onClick={() =>
          dispatch({
            type: "ADD_TODO",
            todos: { todoName: inputRef.current.value, todoStatus: "doing" },
          })
        }
      >
        추가
      </button>
    </>
  );
});

export default TodoInput;

코드들의 핵심은 dispatch시 보내는 action과 index.jsx가 가지고 있는 initialState 즉 store에 데이터를 업데이트 하고 그것을 바탕으로 view가 업데이트 된다는 것이다.

내 생각에는 Flux는 MVC와 아예 다른 패턴이 아니라 MVC 패턴의 업그레이드 버전 처럼 보인다.

controller 역할을 하는 Dispatcher가 action으로 좀더 직관적이고 자세한 명령을 받아서 수행하는 것이 controller의 복잡도 증가를 줄이고 Model과 View 사이를 느슨하게 해 준 것으로 보인다.

하지만 아래 글을 보면 다른 의견들도 상당히 있다.

Facebook: MVC Does Not Scale, Use Flux Instead

Posted in r/programming by u/Fapmate • 418 points and 378 comments

www.reddit.com

좀 더 대규모의 개발에서 디자인 패턴에 대한 고민들을 더 해봐야 하겠지만 Flux는 Flux대로 괜찮다고 생각한다.

아무리 MVC의 짭이고 Facebook이 MVC를 잘못 적용한 것이라고 해도 각 단계의 직관성을 줬다는 측면과 현 시점 가장 인기있는 자바스크립트 라이브러리와 잘 맞는다는 측면에서 그렇게 생각한다.

3. Redux, 또 다른 Flux?

Flux 패턴을 활용한 React의 전역 상태관리 방식으로 Redux가 많이 채택된다.

Redux는 Reducer, action, store로 구성된다. 완벽하게 flux 패턴을 따라 구현되지는 않았지만 기본 사상은 같은 선상에 있다고 볼 수 있다.

Redux는 Dispatcher를 명시적으로 생성하지 않고도 Flux를 구현할 수 있도록 작성되었으므로 Dispatcher를 생략할 수 있다. 실제 디스패치 동작은 스토어의 dispatch 메소드를 호출하여 실행한다.

앞서 Flux 형태를 만들어본 Context API와 비교했을 때 많은 부가 기능들을 지원한다.

Context API는 공식문서에도 나와있듯이 props drilling을 위한 것이지 전역 상태관리를 지원하는 기능이 아니다.

대규모의 애플리케이션에서는 결국 redux와 같은 전역상태관리 tool 필요하다.

4. 마무리

사실 React를 적용하는 큰 규모의 프로젝트를 경험해보지 못한 경험으로 디자인 패턴에 대한 생각을 말하기에는 무리가 있을 수 있다.

하지만 React를 쓰는 개발자로서 최적의 개발패턴이 무엇인지에 대한 고민은 끊임없이 해야한다고 생각한다.

결국 MVC를 활용해 간단한 애플리케이션을 만들면 효율성이 증가하는 것이고, 확장성을 고려해 redux등을 활용한 flux 패턴을 이용했다면 시간은 오래 걸려도 추후에는 더 빛을 볼 수도 있다.

결국 정답은 없는 듯 하다. 적절한 상황에 맞는 문제해결 능력. 결국 코딩보다는 문제해결 능력인가 보다.

jquery의 시대는 이제 끝난것인가?(w/ Google Tag Manager)

B급 코딩 — Mon, 28 Feb 2022 01:21:49 +0900

2021년 stackoverflow survey에서 드디어 React.js가 웹 프레임워크 1위를 차지 했다.

그동안 왕좌의 자리를 굳게 지켜온 jquery가 밀려난 첫 해이다.

Vue와 Angular 역시 여전히 jquery의 자리를 위협하고 있고 Svelte의 성장도 눈여겨 볼만 하다.

이 외 jquery에 대한 상황은 그닥 좋지 않다.

많은 부분을 jquery에 의존하던 bootstrap도 2019년 jquery를 완전히 걷어 내겠다고 선언했다.

개발자들의 인식 또한 점점 jquery는 구시대의 유물처럼 취급되고 있다.

그럼 이제 jquery는 쓸모없어지는 것인가

과거의 영광이 재현될 일은 없어 보인다.

엔터프라이즈 환경에서 웹기술을 활용한 화면을 만들때 React는 매우 효율적이고 유지보수, 타입스크립트와의 연계, 컴포넌트 기반 개발 방법론 등과 매우 잘 어울려 한동안은 왕좌를 굳게 지킬 듯 하다.

하지만 jquery가 쓸모없다고 필자는 생각하지 않는다.

write less, do more.

위 jquery의 캐치프레이즈처럼 적은 코드로 더 많은 것을 할 때 쓰일 수 있다.

바로 디지털 고객경험 같은 곳에서다.

1. 디지털 고객경험 솔루션들의 대두

망할 코시국이 전세계를 덮치면서 디지털화는 가속화 되었다.

안그래도 성장하고 있는 분야였지만 제대로 부스터를 달아준 격이다.

디지털화의 가속은 디지털 고객경험들을 다양화, 다각화 시켰고 기업들은 이것을 고객들에게 잘 제공하기 위한 방안이 필요했다.

디지털 고객경험을 돕기 위한 솔루션들도 시장에 다양하게 쏟아졌다.

채널에서 고객의 행동을 수집하고 분석하는 솔루션, 개인 맞춤형으로 채널을 개인화 해주는 솔루션, 마케터들의 캠페인이나 광고를 도와주는 솔루션 등이 생겨났고 기업들은 이 솔루션들을 적극 도입해서 활용하는 중이다.

대표적인 솔루션이 Google Analytics(이하 GA)이다.

자신이 이용하는 사이트에 들어가서 Wappalyzer라는 크롬 확장프로그램을 통해 사이트에서 돌아가고 있는 솔루션들을 확인해봐라.

대부분 분석으로 GA와 유사한 툴들을 사용중일 것이다.

GA를 설치하는 행위를 태깅이라고 하는데 이를 도와줄 Google Tag Manager(이하 GTM)도 여기에 속한다.

GTM은 GA말고도 개인화나 A/B TEST를 위한 Google Optimize에 대한 설치도 도와주고 구글의 마케팅 솔루션들을 대부분 연결해서 사용할 수 있다.

솔루션들이 워낙 다양하고 다각화 되어 있어 셀 수도 없을 만큼 많지만 설치의 측면에서는 구글의 솔루션들과 크게 다르지 않은 방식을 가진다.

GTM은 사실 마케터들이 개발자들의 도움없이 GA 등의 솔루션을 설치할 수 있게 도와주는 솔루션이란 타이틀을 가졌지만 개발자가 쓰면 더 파워풀해 지는 것은 사실이다.

해당 이미지는 GTM의 맞춤 HTML 태그 화면이다.

여기에 원하는 코드들을 작성해서 채널에 배포할 수 있다.

그렇다. GTM은 단순히 GA 설치용도로만 쓸 수 있는 툴 그 이상이다.

복잡한 배포절차 없이 빠르게 기능들을 시험하고 그 결과를 측정할 수 있다.

애자일과 A/B테스트가 기본이 되어 가는 스피드전에서 매우 큰 메리트이다.

바로 여기에서 jquery는 빛이 난다.

2. GTM에서 jquery로 할 수 있는 예시들

화면단에 무엇인가 변경을 가하려면 필수적으로 자바스크립트를 써야한다.

특히나 많이 써야할 기능은 문서객체(DOM)을 컨트롤 하는 작업과 객체에 이벤트를 핸들링 하는 작업이다.

이 두 기능이야 말로 jquery가 가장 write less하고 do more할 수 있는 측면이다.

여기에서 만큼은 자바스크립트 코드가 아무리 모던화 되었고 많은 기능들이 추가되었어도 jquery의 코드양을 따라오지 못한다.

jquery는 신규 프로젝트에서는 배제될 수도 있지만 지금 운영 중인 많은 사이트에는 그 역사가 긴 만큼 거의 다 포함되어 있다.

없더라도 cdn방식으로 간단한 삽입이 가능하다.

그럼 디지털 고객경험관리 솔루션에서 할 수 있는 작업의 예시를 몇가지 살펴보자.

1. GA에서 특정 버튼을 눌렀을 때 이벤트 수집을 하려고 한다.

해당 버튼이 click되었을 시점을 알기 위해 해당 Dom 객체에 접근해야 한다.

HTML 속성으로 id값이 주어져 있다면 그마다 쉽게 자바스크립트로 접근이 가능할 것이다.

하지만 그렇지 않다면 document.getElementsByClassName 등의 함수를 사용하고 자식노드나 부모노드 접근과 같은 함수등을 조합해서 해당 객체에 접근해야한다.

jquery를 활용한다면 $ 문법으로 적은 코드양으로 작성이 가능하다.

2. Google Optimize에서 긴 텍스트를 줄여서 보여주고 버튼을 하나 달아서 이것을 원본/줄임으로 바꿔서 볼 수 있는 이벤트를 적용해서 A/B테스트를 진행한다.

해당 기능을 자바스크립트를 활용하여 작성한다면 정말 코드가 길어질 것이다.

텍스트 길이를 줄이는 것부터 버튼을 만들고 해당 버튼에 클릭이벤트를 바이딩 하는 것까지 많은 함수들을 써야할 것이다.

jquery를 활용한다면 on를 활용해 이벤트 바잉딩이 쉽고 코드양 역시 적어진다.

3. 오래된 사이트의 개편을 앞두고 신규 사이트에 들어갈 기능들의 사용자 선호도를 알아보고 싶어 기존 사이트에 스크롤을 따라다니는 목차를 적용한다.

해당 기능역시 html을 insert 하는 것부터 스크롤 이벤트 바인딩과 CSS 컨트롤까지 해야한다.

자바스크립트를 활용한다면 정말 긴 코드가 생성될 것이다.

jquery는 앞서 말한 장점들을 활용해 짧은 양의 코드로 이를 해결할 수 있다.

이외도 할 수 있는 일은 무궁무진하다.

채널에 대한 대응이 속도전이 되면서 대규모의 기능 개발을 적용하지 않는 이상 jquery는 큰 역할을 할 수 있다.

특히 앞서 언급했듯이 Dom에 대한 컨트롤과 이벤트 핸들링은 자바스크립트 코드와 비교할 수 없게 적기 때문이다.

3. GTM등 솔루션에서 사용할 만한 jquery 기능

1) Dom 접근

jquery를 사용하면 손쉽게 HTML 요소를 선택하여, 선택된 요소의 값들을 가져올 수 있다.

jquery에서는 요소를 선택하기 위해 대부분의 CSS 선택자뿐만 아니라 몇몇 비표준 선택자까지 제공하고 있다.

$('.cname')  //jquery로 class명이 cname인 dom에 접근

document.getElementsByClassName('cname')  //자바스크립트 활용

예시처럼 자바스크립트를 썼을 때와는 비교할 수 없을 정도로 효율적이다.

dom접근만 잘해도 많은 기능들을 구현할 수 있어 jquery가 많이 활용된다.

class말고 더 많은 요소에 대한 접근 법은 아래 링크를 참고하면 된다.

Selectors | jQuery API Documentation

Select all elements that are in the progress of an animation at the time the selector is run. Selects elements that have the specified attribute with a value either equal to a given string or starting with that string followed by a hyphen (-). Selects elem

api.jquery.com

2) 이벤트 바인딩

특정 버튼이 클릭되었을 때 요소를 숨기거나 특정 위치로 이동하거나 할 때 이벤트 바인딩이 필요하다.

jquery에서 이 기능에 필요한 문법은 on과 "click"이라는 매개변수 뿐이다.

var hiddenBox = $( "#banner-message" );
$( "#button-container button" ).on( "click", function( event ) {
  hiddenBox.show();
});

위 처럼 손쉽게 컨텐츠 보이기 이벤트를 바인딩 했다.

"click" 말고도 "scroll", "resize", "mouseover" 등 필요한 이벤트를 바인딩해서 손쉽게 기능을 추가할 수 있다.

이벤트들에 대한 것은 아래 링크를 참고하면 된다.

Events | jQuery API Documentation

Attach a handler to an event for the elements. Bind an event handler to the “blur” JavaScript event, or trigger that event on an element. Bind an event handler to the “change” JavaScript event, or trigger that event on an element. Bind an event han

api.jquery.com

3) Data

이 기능을 사용하면 이벤트 바인딩과 함께 특정 데이터들을 특정한 dom요소에 저장해두었다가 동적으로 활용할 수 있다.

대표적으로 특정 텍스트들을 줄여서 보여주다가 더보기 버튼을 누르면 원래 텍스트를 전부 보여주는 기능이 있다.

<p id="writing">
이 것은 예시 글입니다. 정말 길어요.이 것은 예시 글입니다. 정말 길어요.이 것은 예시 글입니다. 정말 길어요.이 것은 예시 글입니다. 정말 길어요.이 것은 예시 글입니다. 정말 길어요.이 것은 예시 글입니다. 정말 길어요.이 것은 예시 글입니다. 정말 길어요.
</p>



$('#writing').each(function() {
  
    var fullTxt = $('#writing').html() + ' <a href="#" id="less">줄이기</a>';
    var shortTxt = shortTxt = cutByLen(fullTxt, 40) ++ '... <a href="#" id="more">더보기</a>';
    
    $(this).html(shortTxt);   //초기 세팅을 줄인 글자로
    $(this).data('full', fullTxt);   //full이라는 키로 원본 텍스트 저장
    $(this).data('short', shortTxt);  //short이라는 키로 줄인 텍스트 저장
  }
});

// 버튼 클릭 이벤트 바인딩
$('#writing').on('click', '#more', function(e) {
  e.preventDefault();
  $(this).closest('.text').html($(this).closest('.text').data('full'));
  $(this).closest('.text').find('#less').focus();
});

$('#writing').on('click', '#less', function(e) {
  e.preventDefault();
  $(this).closest('.text').html($(this).closest('.text').data('short'));
  $(this).closest('.text').find('#more').focus();
});

data 기능에 대한 자세한 사항은 아래 링크를 참고하면 된다.

Data | jQuery API Documentation

Remove from the queue all items that have not yet been run. Store arbitrary data associated with the matched elements or return the value at the named data store for the first element in the set of matched elements. Execute the next function on the queue f

api.jquery.com

3마무리

jquery는 분명히 하향세를 탄 라이브러리 이다.

하지만 12년 가까이를 개발자들과 함께 하며 견고한 생태계를 가지고 있고 지금도 활용되는 곳이 많다.

고객경험관리 측면에서 GTM 등을 활용한 채널관리를 하고 있다면 빠른 대응을 위한 jquery 사용이 큰 장점을 가질 것이다.

NodeJS+Express+Typescript MVC 패턴(w/ Mysql)

B급 코딩 — Sun, 13 Feb 2022 11:50:19 +0900

지난 포스팅을 통해 Typescript를 활용하여 NodeJS와 Express 백엔드 서버 개발환경을 세팅하는 방법을 알아봤다.

Typescript로 Node+Express API 서버 개발환경 세팅

Node JS와 Typescript의 등장이 가지는 의미 자바스크립트는 웹브라우저에서 HTML문서를 동적으로 컨트롤 하기 위해 만들어졌다. 근본부터가 프론트엔드인 이 언어는 브라우저들의 춘추전국

bgradecoding.tistory.com

이것을 베이스로 웹 프레임워크에서 많이 사용하는 MVC 패턴을 만드는 방법에 대해 알아보자.

MVC 패턴은 디자인 패턴 중 하나이다.

사실 주니어 시절에는 이걸 왜 쓰는지 잘 알지 못했다.

주니어 시절은 자신이 맡은 기능만을 구현하면 되기 때문에 서비스 전체 코드에 대한 전반적인 사항들을 알기 힘든게 가장 큰 이유였던 거 같다.

처음 유지보수를 위해 프로젝트에 투입되었을 때 Spring 프레임워크로 된 서비스 코드들을 접했다.

특정 기능들을 JSP 화면부터 따라가면서 DB 조회하는 부분까지 코드 분석을 하는데 많은 시간이 걸렸다.

그러면서 드는 생각은 왜 이렇게 코드들을 쪼개놨을까 하는 불만이였다.

한 기능을 담당하는 코드를 한곳에 두면 새로 투입되는 개발자들이 편할텐데 이런 작업이 왜 되어 있을까....

지금 생각하면 참 부끄럽다.

그 이후 많은 프로젝트들에 투입되며 복잡한 기능들을 구현하고 여러 개발자들과 협업하다 보니 잘 짜여진 디자인 패턴이 가지는 힘을 새삼 느끼게 되었다.

그래서 이제는 간단한 토이 프로젝트나 빠른 백엔드 서버 구현에도 MVC 패턴을 고수하는 편이다.

당장은 혼자 개발하지만 시간이 흘러 다시 소스코드를 봐야한다면 결국 미래의 나와 협업하는 것이 되기 때문이다.

잡설이 길었다.

Typescript 기반의 Node Express 백엔드 서버에 MVC 패턴을 적용해 보자.

1. MVC 패턴이란?

MVC 패턴이란 Model, View, Controller 의 약자이다.

어플리케이션을 구성할 때 각자 맡은 역할대로 소스코드를 구분하여 코딩하고 유지보수 및 신규기능 추가를 더 수월하게 하겠다는 의도이다.

자동차 공장을 생각해보자.

옛날에는 자동차 한대를 만드는 데 모든 부품을 만드는 사람들이 한곳에서 작업을 해 하나의 완성된 자동차를 만들었다.

하지만 이제는 효율화를 위해 엔진, 자동차 외부, 바퀴, 자동차 문 등으로 섹션을 나누어 작업한다.

이런 효율성을 IT로 가져왔다고 생각하면 편하다.

Model은 데이터에 관련된 행위들만 담당하고

View는 화면에 관련된 행위들만 담당하고

Controller는 사용자 요청에 대한 행위들만을 담당한다.

MVC는 지금처럼 Front-End 분야가 크기 전에 만들어진 개념이다.

따라서 모든 것을 서버단에서 처리하던 시절이기에 위 같은 구성을 만들었다.

지금은 백엔드를 구성하더라도 Rest API만을 주는 서버를 만들고 화면에 대한 것은 React나 Vue 등으로 따로 구성하는 것이 대부분이다.

그렇다면 MVC 패턴은 고대의 유물 같은 것이 아닐까?

결론적으로 그렇지는 않다.

개발자들은 실제 화면(View)가 백엔드에 없더라도 화면과 직접적으로 통신하는 부분을 View단으로 개념화 해서 MVC 패턴을 사용하고 있다.

이것은 프론트엔드 쪽에서도 마찬가지이다.

화면 내에서도 사용자의 요청을 받아드리는 부분이 있고 백엔드와 통신해서 데이터를 핸들링 해야할 부분이 있다.

실제 React에서도 MVC 패턴을 채용해 많이 개발한다.

그렇다면 Rest API를 주는 목적은 NodeJS+Express 서버는 MVC를 어떻게 구현해야 할까

2. NodeJS + Express MVC 구성 개념

Express에서는 Router라는 것을 제공하여 화면과 최전방에서 상호작용하는 것을 처리한다.

이것을 View단이라고 생각한다.

이후 화면에서 들어온 요청에 맞는 데이터 조회, 수정, 삭제 등의 작업을 지휘할 controller 부분을 따로 빼준다.

그리고 실제 DB에서 데이터를 핸들링 하는 행위를 하는 model 부분을 빼서 관리하면 된다.

이렇게 하면 필요한 로직들을 어느 모듈에 적용해 놔야 하는지 어느정도는 감이 생길 것이다.

예를 들어 DB를 연결하고 Pool을 생성해 쿼리 작업을 하는 쪽은 model에 있어야 한다.

화면에서 온 데이터들에 대한 validation 처리를 view, 즉 router에서 하는게 좋다.

3. 실제 구성

이 구성은 Typescript를 기반으로 하고 DB로는 Mysql을 사용했다.

Sequelize를 사용하는 것이 좋지만 토이프로젝트나 작은 규모의 플젝이라면 DB를 직접 핸들링하는 일이 많으므로 쿼리를 활용한 DB 작업을 하도록 하겠다.

어플리케이션의 admin기능 중 admin 유저들을 등록하고 admin 유저들을 조회하는 기능을 만들것이다.

프로젝트 폴더 구성은 다음과 같다.

폴더 네이밍은 그렇게 중요하지 않다.

MVC 패턴의 개념을 이해했고 해당 기능별로 모듈을 나눠서 구성하기만 하면 된다.

Controller : 말그대로 Controller를 담당하는 모듈들을 가지고 있다.

Data : 여기서 Model을 담당하는 모듈들을 가지고 있다.

Model : 혼동이 있을 수 있지만 여기는 Typescript를 사용하기 때문에 생기는 데이터의 타입들에 대한 정의 부분이다.

routes : View를 담당하는 부분이다.

util : 기타 자주 쓰이는 공통모듈들을 관리한다.

app.ts : 실제 중심이 되는 Main 모듈이다.

다시한번 언급하지만 폴더명은 필자가 개인적으로 작업하기 편하게 명명한 것들이다.

플젝에서는 플젝의 네이밍 규칙에 따르고 개인은 취향대로 바꿔도 전혀 상관없다.

app.ts 부터 살펴보자.

import express from "express";
import adminRouter from "./routes/admin";

const app = express();
app.use(express.json());
app.use(express.urlencoded({ extended: false }));

app.use("/admin", adminRouter);

app.listen(8000, () => {
  console.log("**----------------------------------**");
  console.log("====      Server is On...!!!      ====");
  console.log("**----------------------------------**");
});

매우 심플하다.

adminRouter에 요청을 위임하고 8000 port로 서버를 기동시켰다.

다음은 MVC 중 View에 해당하는 router인 /routes/admin.ts 모듈을 살펴보자.

import express, { Request, Response, NextFunction } from "express";
import * as adminController from "../controller/admin";

const router = express.Router();

router.get("/admin", adminController.getAdmin);
router.post("/admin", adminController.createAdmin);

export default router;

Router에서는 http 메소드에 따라 get으로 온 요청은 Controller의 조회쪽으로 post 요청은 생성 쪽으로 역할을 위임한다.

또한 여기서 @types/express-validator 등을 사용하여 화면에서 받은 데이터들의 유효성 검증을 미들웨어 형식으로 해주면 된다.

Getting Started · express-validator

express-validator is a set of [express.js](http://expressjs.com/) middlewares that wraps

express-validator.github.io

다음으로 /controller/admin.ts 이다.

import { Request, Response } from "express";
import { PostAdmin, GetAdmin } from "../model/admin";
import * as adminData from "../data/admin";


// 생성 후 insertId를 리턴하도록 설계
export async function createAdmin(req: Request, res: Response) {
  const newAdminInfo: PostAdmin = req.body;
  const insertId = await adminData.createAdmin(newAdminInfo);
  res.status(201).json({ inserId: insertId });
}

//모든 admin user 들을 배열로 전송하도록 설계
export async function getAdmin(req: Request, res: Response) {
  const adminInfo: Array<GetAdmin> = await adminData.getAdmin();
  res.send(adminInfo);
}

리턴하거나 Model 쪽에 넘겨줘야할 데이터의 타입을 정의한 model들(폴더명)을 import해오고 데이터를 핸들링 하는 Model에 해당하는 data를 호출해 준다.

DB조회하는 부분으로 async 방식을 활용해 동기적으로 처리 될 수 있도록 구성한다.

다음은 MVC 중 Model에 해당하는 /data/admin.ts 이다.

import { db } from "./database";
import { PostAdmin, GetAdmin } from "../model/admin";

export async function createAdmin(newAdminInfo: PostAdmin): Promise<string> {
  const {
    adlvno,
    adid,
    adpw,
    adname,
    adress,
    findpass_que,
    findpass_ans,
    email,
    tel,
    depart,
    duty,
  } = newAdminInfo;

  const query: string =
    "INSERT INTO tb_admin VALUES(2,?,?,?,?,?,?,?,?,?,?,?,NOW(),NOW())";
  return db
    .execute(query, [
      adlvno,
      adid,
      adpw,
      adname,
      adress,
      findpass_que,
      findpass_ans,
      email,
      tel,
      depart,
      duty,
    ])
    .then((result: any) => result[0].insertId);
}

export async function getAdmin(): Promise<Array<GetAdmin>> {
  const query: string =
    "SELECT ta.adlvno, ta.adid, ta.adname, ta.email, ta.depart, tal.lvname, ta.duty from tb_admin as ta, tb_admin_level as tal where ta.adlvno=tal.adlvno";
  return db.execute(query).then((result: any) => result[0]);
}

DB에 테이블이 두개다. admin 유저를 관리하는 tb_admin, admin 등급을 관리하는 tb_admin_level

다음으로 DB 연결에 필요한 /data/database.ts 파일이다.

import mysql from "mysql2";

const pool = mysql.createPool({
  host: process.env.DB_HOST, // 호스트 주소
  user: process.env.DB_USER, // mysql user
  password: process.env.DB_PASSWORD, // mysql password
  database: process.env.DB_DATABASE, // mysql 데이터베이스
  port: 3306,
});

export const db = pool.promise();

보안을 위해 .env 파일을 활용해 DB 정보들을 가져온다.

다음으로 type을 정의해둔 /model/admin.ts 이다.

export type PostAdmin = {
  adlvno: number;
  adid: string;
  adpw: string;
  adname: string;
  adress: string;
  findpass_que: string;
  findpass_ans: string;
  email: string;
  tel: string;
  depart: string;
  duty: string;
};

export type GetAdmin = {
  adid: string;
  adname: string;
  email: string;
  depart: string;
  duty: string;
  lvname: string;
};

여기까지 NodeJS+Express에 Typescript로 MVC 패턴을 구성해 보았다.

디자인 패턴은 협업과 프로젝트 유지보수에 중요한 역할을 한다.

MVC 말고도 다양한 패턴이 존재하니 한번쯤 적용해 보는 것도 나쁘지 않을 것이다.

Typescript로 Node+Express API 서버 개발환경 세팅

B급 코딩 — Mon, 7 Feb 2022 23:52:13 +0900

Node JS와 Typescript의 등장이 가지는 의미

자바스크립트는 웹브라우저에서 HTML문서를 동적으로 컨트롤 하기 위해 만들어졌다.

근본부터가 프론트엔드인 이 언어는 브라우저들의 춘추전국시대를 거쳐면서

‍ ‍ ‍ -> (IE.... MS.... ㅂㄷㅂㄷ)

여러 개성이 강한 자식들로 분화되었다가 자바스크립트족 대통합 운동으로 표준화되어 지금에 이르렀다.

Node JS가 나오면서는 자신의 근본인 브라우저 태생 족보 를 찢어버리고 백엔드의 영역까지 침범하기 이르렀다.

심지어 보통의 웹사이트에 필요한 데이터 CRUD 기능을 만들때는 다른 백엔드 태생 언어들의 장점을 뛰어넘기도 하는 청출어람을 보여준다. 물론 요즘 핫한 머신러닝광의 연계나 그래픽 요소가 많은 작업, 실시간성 대규모 트레픽 데이터 처리 등에는 역시 자신의 한계가 드러난다. 앞서 언급했듯이 노멀한 웹사이트의 백엔드 구축에는 Node JS와 Express 프레임워크(Java + Spring 같은 조합)이 꽤 괜찮은 방안이 되어 버렸다.

IE(그 이름하여 Internet Explorer)로 개발자들을 개고생 시킨 것이 미안했는지 Microsoft가 관리하고 있는 오픈소스 Typescript의 등장도 NodeJS를 백엔드 서버로 이용하는데 꽤 의미가 있다.

Typescript의 자세한 내용은 아래서 확인해보고 백엔드에서의 등장 의미만 집어보면.

JavaScript With Syntax For Types.

TypeScript extends JavaScript by adding types to the language. TypeScript speeds up your development experience by catching errors and providing fixes before you even run your code.

www.typescriptlang.org

자바스크립트에서 prototype으로 흉내내던 객체지향 프로그래밍이 Typescript에서 더 견고해졌다.

이것은 내가 많이 하다 버리는 토이프로젝트 따위의 개발이 아니라 실제 수많은 고객들에게 서비스하는 Enterprise환경에 맞게 개발할 수 있다는 의미이다.

따라서 이 두개가 조합되면 따로 먹어도 맛있는 짜장면과 탕수육이 같이 먹으면 최고의 조합이 되듯 백엔드 서버 구성을 큰 규모로, 더 효율적으로 할 수 있다는 결론에 이른다.

Node JS + Express (with) Typescript 기본 구성

1) 시작!!! init!!

npm init

물론 nodejs는 기본적으로 설치하고 위 명령어를 실행해야 한다.

해당 명령어를 입력하면 여러 옵션들을 입력하라고 나온다.

package name: (nodeExpressTypeGood) // 프로젝트 이름
version: (1.0.0)                    // 프로젝트 버전
description:                        // 프로젝트 설명
entry point: (index.js)             // 프로젝트 시작 파일(자바의 main메소드)
test command:                       // 테스트를 위한 명령어
git repository:                     // 연결된 git repo 주소
keywords:                           // 프로젝트 관련 해시태그?
author:                             // 제작자
license: (ISC)                      // 라이센스 종류

상황에 맞게 입력하면 된다.

입력하지 않을 시 기본 값으로 세팅되어 넘어간다.

마지막으로 yes 세글자를 넣으면 시작된 것이다.

2) 필수 모듈 설치

npm i express typescript @types/express
npm i -D nodemon ts-node

실제 서버 구동시 필요한 모듈 3가지

- express : NodeJS를 사용하여 서버를 개발할 때 서버를 쉽게 구성할 수 있게 만든 프레임워크

- @types/express : express는 원래 자바스크립트로 만들어 졌다. 이를 타입스크립트 환경에서 쓰기 위해 express 내부의 변수들, 함수들의 타입을 정의한 ~d.ts 파일이 포함된 형태

- typescript : 타입스크립트 사용을 위해 설치

개발시 필요한 모듈들 (-D 옵션을 붙여서 설치)

- nodemon : 노드 서버를 실행하고 소스코드를 수정하면 다시 재시작해야하는 번거로움을 자동으로 해주는 고마운 모듈 ❤️

- ts-node : Node.js용 TypeScript 실행 엔진 및 REPL

여기까지는 몇개의 모듈을 더 설치한거 빼고는 자바스크립트로 백엔드 구성할 때와 별반 다르지 않다.

이제부터 진짜 타입스크립트 세팅이다.

3) 타입스크립트 시작!! init!!!

tsc --init

Typescript가 정상적으로 설치되어 있다면 위 명령어가 실행되고 tsconfig.json 파일이 생성될 것이다.

npm init은 package.json을, tsc --init은 tsconfig.json을 생성한다.

해당 파일을 열어보면 많은 옵션들이 보일 것이다.

필수적인 옵션들만 설정해 준다.

{
"target" : "es6",
"module" : "commonjs",
"outDir" : "dist"  //타입스크립트가 자바스크립트로 빌드된 파일들 모아두는 폴더명
....
}

보통 주석처리되어 있는 outDir의 주석을 풀고 원하는 위치로 설정하면 된다.

그외 다른 옵션들에 대한 설명은 위 타입스크립트 공식 홈페이지에 있고 만들어지는 tsconfig.json에도 주석으로 간단히 설명되어 있다.

이것으로 서버 세팅에 관련된 작업은 끝이다. 이제 코딩을 해서 API 서버를 만들어 보자.

✔️ 타입스크립트 코드 작성

간단하게 HTTP의 GET 메소드 API 하나에 타입스크립트스러운 객체 하나를 리턴해 보는 코드를 작성해 보자.

프로젝트 경로에 app.ts 파일을 만들고 아래와 같이 코딩한다.

import express, { Request, Response } from "express";

const app = express();

type Data = {
  name: string;
  age: number;
  url: string;
};

const sendData: Data = {
  name: "name",
  age: 3,
  url: "tistory.com",
};

app.get("get", (req: Request, res: Response) => {
  res.send(sendData);
});

app.listen(8080)

이제 만든 서버 모듈이 잘 돌아가는지 확인해 보자

✔️ 서버 실행

서버를 실행하기 위해서는 package.json의 script 부분을 수정해야 한다.

설치해둔 ts-node가 활약할 시간이다.

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "nodemon app",
    "dev": "nodemon --watch \"*.ts\" --exec \"ts-node\" app.ts"
  },

위와 같이 dev 명령에 해당하는 명령어를 package.json에 넣고

npm run dev

를 실행한다.

그리고 브라우저에 http://localhost:8080/get를 입력하면

{"name":"name","age":3,"url":"tistory.com"}

해당 json이 잘 오는것을 확인할 수 있다.

[DB] MySQL Workbench ERD 추출(SSL 에러 해결)

B급 코딩 — Sat, 22 Jan 2022 15:20:59 +0900

IT 산업에서 일을 하다보면 반드시 DB라는 존재와 엮이게 된다.

Front-End 개발자라면 보통 DB를 직접 마주하기 보다는 API를 통해 마주한다.

Rest API나 Graphql로 DB에 저장되어 있는 데이터를 Back-end에서 주는대로 받아 가공하여 화면에 보여주기 때문이다.

하지만 Back-end 개발자는 DB에 직접 붙어야 할 일이 대다수이다.

데이터를 저장하고 삭제하고 수정하는 일을 대부분 하기 때문이다.

1. ERD란? ERD의 필요성

이렇게 알아야하거나 관리해야할 DB의 테이블이 한두개라면 문제가 없다.

테이블이 50개, 100개 더 많다면 어떨까?

데이터가 어떤 식으로 저장되어 연결되어 있는지, DB구조가 변경되었다면 어떻게 이력관리가 되는지 문서 없이는 관리하기 힘들 것이다.

그래서 ERD라는 것이 필요하다.

ERD는 Entity Relationship Diagram 의 약자로 쉽게 그림으로 테이블의 관계들을 설명해 놓은 것이다.

개체-관계 모델 - 위키백과, 우리 모두의 백과사전

데이터 모델링 분야에서 개체-관계 모델이란 구조화된 데이터에 대한 일련의 표현이다. 서로 관계된 두 개의 엔티티 "구조"화된 데이터를 저장하기 위해 데이터베이스를 쓴다. 이 데이터의 "구

ko.wikipedia.org

개발자는 이 그림을 통해 DB가 어떻게 구성되어 있는지 혹은 어떻게 변경되었는지 한눈에 파악할 수 있다.

하지만 이 ERD가 프로젝트 시작시점이나 요구사항 분석때 그려진다면 좋겠지만 없는 경우도 있고 업데이트를 하지 않아 있어도 더이상 사용하지 못할 수준일 수 있다.

또한 토이프로젝트 등으로 작은 규모에서 ERD를 그리고 시작하기에는 공수가 너무 많이 든다.

이에 Mysql DB에서는 기존의 DB에서 MySQL Workbench란 프로그램을 사용하여 ERD를 쉽게 뽑아낼 수 있다.

2. MySQL Workbench에서 ERD 뽑아내기

MySQL Workbench는 DB Server Management 프로그램이다.

성능에 대한 모니터링, 테이블 구조 변경, 신규 데이터베이스 생성 등을 할 수 있다.

그 중 하나의 기능으로 ERD를 뽑아내는 기능이 있는 것이다.

먼저 MySQL Workbench를 설치한다.

Mysql 설치시 디폴트 옵션으로 설치하면 이미 설치되어 있지만 그게 아니라면 홈페이지에서 다운로드 받아 MySQL Workbench를 따로 설치해 주어야 한다.

MySQL :: Download MySQL Workbench

Select Operating System: Select Operating System… Microsoft Windows Ubuntu Linux Red Hat Enterprise Linux / Oracle Linux Fedora macOS Source Code Select OS Version: All Windows (x86, 64-bit) Recommended Download: Other Downloads: Windows (x86, 64-bit), M

dev.mysql.com

설치 후 MySQL Workbench를 실행한다.

"Database" -> "Reverse Engineer..." 메뉴를 선택한다.

그러면 아래와 같은 화면이 나온다.

연결할 DataBase가 있는 DB 정보들을 넣어준다.

- Hostname

- Port

- Username

- Password

여기서 로컬 환경의 DB나 개발환경 DB의 ERD를 가져오는 경우라면 대부분 SSL 설정이 되어 있지 않아 다음 스텝에서 에러를 만나게 된다.

이걸 방지하려면 Advanced 탭으로 이동하여 useSSL=0을 아래와 같이 입력해 준다.

그리고 Next 버튼을 누른다.

에러 없이 작업이 완료 된다.

Next를 누른다.

이제 ERD를 그릴 DataBase를 선택해 준다.

그리고 Next를 누른다.

작업이 정상적으로 완료되는 것을 볼 수 있다.

Next를 누른다.

이제 마지막 단계 이다.

Excute> 를 누른다.

Finish를 누른다.

위와 같이 ERD가 생성되는 것을 볼 수 있다.

토이 프로젝트나 PoC성 프로젝트를 하면 거의 DB를 MySQL로 많이 활용하는데 이것을 활용해서 ERD를 그리고 간다면 더 퀄리티 있는 프로젝트가 될 수 있을 것이다.

Javascript로 GA 데이터 전송법 ( Tistory Blog에 활용 하는 법 )

B급 코딩 — Thu, 20 Jan 2022 22:26:16 +0900

Google analytics(이하 GA)를 활용할 때 개발을 최소화 하기 위해 Google Tag Manager(이하 GTM)를 활용한다.

GTM은 DataLayer 라는 객체에 데이터가 Push되면서 GA로 이벤트는 보내는 방식을 사용한다.

이때문에 사이트가 복잡한 구조로 되어 있거나 랜더링 속도가 느린 환경 등에서 데이터 수집이 잘 일어나지 않는 경우가 있다.

이런 경우에는 결국 GTM을 거치지 않고 바로 GA로 데이터를 전송하는 코드로 해결할 수 있다.

바로 gtag.js의 함수를 활용하는 것이다.

물론 MP(Measurement Protocol)이 속도적 측면에서는 가장 빠르긴 하다.

GA 스크립트나 GTM 스니펫 없이 데이터를 전송할 수 있다?Measurement Protocol

보통 Google Analytics(GA)로 데이터 수집을 한다면 사이트에 GA 스크립트(analytics.js) GTM 스니펫 코드를 활용하여 사용자의 행동데이터를 수집하는 것이 일반적이다. 하지만 사용자들의 환경은 시시각

bgradecoding.tistory.com

하지만 MP(Measurement Protocol)는 사이트 소스코드의 많은 부분을 수정해야하고 구글이 기본적으로 수집하는 데이터들이 누락될 수 있다.

그래서 절충안인 gtag.js의 함수를 활용해 GA에 데이터를 전송해 보자.

1. GA 스니펫 코드 import

일단 GA의 gtag()함수를 사용하기 위해서는 스니펫 코드를 사이트에 심어야 한다.

스니펫 코드는 GA 대시보드에서 '관리' 메뉴에 들어가 추적정보를 누르면 확인할 수 있다.

코드 부분만 떼어 내면 아래와 같다.

<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=<트레킹 ID>"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', '<트레킹 ID>');
</script>

보통 이 코드를 복사하여 추적할 모든 웹페이지의 <HEAD>에 첫 번째 항목으로 붙여 넣는다.

Tistory 블로그의 경우 플러그인을 통해 해당 스니펫 코드가 블로그에 심어진다.

※ 수집 확인 방법 (Omnibug)

GA로 데이터가 잘 전송되고 있는지 확인하는 툴로 Omnibug가 있다.

Omnibug는 발신 디지털 마케팅 도구 요청을 디코딩하고 표시하는 브라우저 확장 프로그램이다.

GA 데이터도 확인이 가능하고 Adobe analytics나 기타 솔루션들의 데이터도 확인이 가능하다.

설치 후 F12를 눌러 개발자 도구를 열고 탭에서 omnibug를 선택하고 사이트에 접속하면

위와 같이 데이터가 가는 것을 확인할 수 있다.

2. 페이지뷰 수집

MPA(Multiple Page Application) 형태로 기존에 많이 사용하던 SSR(Server side rendering)을 이용하는 사이트의 경우 GA가 자동으로 페이지뷰를 수집한다.

하지만 SPA(Single Page Application) 구조이면서 별도의 SSR(Server side rendering)이 없다면 소스코드를 활용해서 페이지뷰를 잡을 수 있다.

아래와 같이 gtag() 함수를 통해 페이지뷰를 수집할 수 있다.

gtag('event', 'page_view', {
  page_title: '<Page Title>',
  page_location: '<Page Location>',
  page_path: '<Page Path>',
  send_to: '<GA_MEASUREMENT_ID>'
})

티스토리의 경우 MPA(Multiple Page Application) 구조로 되어 있어 플러그인만 설치하면 자동적으로 페이지뷰를 수집하게 된다.

3. 이벤트 수집

GA로 페이지뷰만 수집한다면 그것은 GA를 30%도 사용하지 않는 것과 같다.

GA는 페이지뷰 이외에도 웹에서 일어나는 많은 행동들을 수집할 수 있다.

수집하고자 하는 이벤트가 일어날 때 아래 코드를 실행하면 된다.

gtag('event', <action>, {
  'event_category': <category>,
  'event_label': <label>,
  'value': <value>
});

페이지뷰와 거의 비슷한 형태이다.

하나의 예시로 클릭이 일어날 때 해당 이벤트를 함수로 잡아서 코드를 실행시켜주면 된다.

4. 티스토리 블로그에서 관련글 클릭 이벤트 수집 방법

앞서 이야기 했듯이 티스토리 블로그에서는 페이지뷰만이 기본으로 수집된다.

블로그 특성상 페이지뷰 만으로도 어느정도의 분석이 가능하지만

블로그 본문 글 맨 끝에 달리는 관련글을 클릭하는 이벤트를 수집한다면 어떨까?

본문글과 어떤 관련이 있는 글들이 클릭되는지 알 수 있고

해당 글들을 같은 카테고리로 묶어 페이지 체류 시간을 늘릴 수 있을 것이다.

방법은 간단하다

스킨 편집을 열고 html 편집을 누른다.

티스토리는 그렇게 복잡하지 않은 html 형태를 가지고 있고 아래 태그별로 영역이 나눠져 있는 형태이다.

Tistory 블로그 태그 종류와 설명
<s_article_rep>	글정보
<s_ad_div>	관리
<s_tag_label>	해시태그
<s_permalink_article_rep>	퍼머링크
<s_index_article_rep>	인덱스
<s_article_related>	관련글
<s_article_next>	다음글
<s_article_prev>	이전글

우리는 관련글 부분에 이벤트 수집을 할 예정이기 때문에 <s_article_related>태그부분을 찾는다.

<li class="item_related"> 부분이 클릭되면 실행되는 이벤트 리스너를 하나 만든다.

이 코드는 되도록 아래쪽에 위치하게 해서 html이 모두 렌더링 된 다음에 이벤트 바인딩을 할 수 있도록 한다.

<script>

var clickEle = $('.list_related li');
clickEle.click(function () {
	
	gtag('event', '관련글 클릭', {
  'event_category': $(this).index(),
  'event_label': this.getElementsByClassName('box_content')[0].innerText
});
})
</script>

이제 관련글을 클릭하여 이벤트가 가는지 확인해 본다.

Omnibug로 이벤트가 가는걸 확인할 수 있다.

마무리

GA를 코드로 활용하는 방법에 대해 알아보았다.

GTM을 써서 수집하는 것도 좋지만 역시 개발자는 코드로 작성하는게 편하고 작업하는 맛이 난다.

개인적으로 운영하는 서비스나 웹사이트가 있다면 GA를 코드 형태로 심어 서비스 분석을 해보는 것도 좋을 듯 하다.

[React] 이미지 사용의 모든 것(feat. SVG, SVGO)

B급 코딩 — Fri, 14 Jan 2022 00:32:03 +0900

웹사이트를 제작하다보면 필수적으로 이미지 파일을 사용해

화면을 구성해야 하는 일이 생긴다.

(안 생긴다면 그 사이트 제작은 지금 끝내라)

Front-End 라이브러리로 React를 사용한다면

이미지를 사용하는 방식이 여러가지일 것이다.

어떤 상황에서 어떤 방식이 맞는지,

혹은 사용법이 정확한지 알기 힘들다.

그래서 이번 포스팅에서는 리엑트에서 이미지를 활용하는 법에 대해 정리하고자 한다.

1. Pubilc 폴더에 이미지 파일 위치시키고 활용

❗️제일 간편하고 직관적인 방법이다.

Create React App으로 프로젝트를 생성하면

Public 폴더에 index.html을 비롯한 정적 파일이 있다.

여기에 images 폴더를 만들고 이미지 파일을 넣어둔다.

그리고 실제 이미지를 활용할 소스 코드에서는 아래와 같이 활용한다.

import React from 'react'

export default function ImageTrain() {
	return(
    	<div>
        	<img src={'/images/lesme.jpg'} alt='오류이미지' />
        </div>
    );
}

별도의 경로 설정 없이 Public 폴더에 있는 경로 그대로 사용할 수 있어 직관적이다.

2. src (소스)폴더 내에 이미지 파일을 위치시키고 활용

1) 정적 활용

소스 폴더(src) 내에 images 폴더를 만들고 이미지 파일을 위치시킨다.

이후 이것을 활용하는 소스코드에서는 이 이미지가 있는 위치까지 상대경로로 올라가야 한다.

import React from 'react'
import lesMeImg from '../../images/lesme.jpg'

export default function ImageTrain() {
	return(
    	<div>
        	<img src={lesMeImg}  alt='오류이미지' />
        </div>
    );
}

상대경로는 매우 힘든일이 아닐 수 없다.

따라서 위와 같이 활용해야 할 경우에는 craco 설정을 통해 @image로 image경로를 prefix로 지정해 두고 사용하는 것이 편한다. 아래는 craco에 대한 설명이다.

[React] 상대경로 지옥에서 벗어나기 (craco)

개요 React는 기존의 Vanilla JS( 프레임워크를 쓰지 않은 순수 JavaScript )나 Jquery 사용시 불편했던 개발자의 욕구를 충분히 충족시켜주며 성장을 계속하고 있다. 하지만 인간은 편안함에

bgradecoding.tistory.com

2) 동적 활용

craco로 상대경로 지옥은 벗어나도 위와 같은 방법은 사용하려는 이미지가 많아 질수록 import 지옥에 빠지게 된다.

따라서 이미지를 동적으로 많이 활용해야할 때는 require() 함수를 사용하는 것이 좋다.

import React from 'react'

export default function ImageTrain() {
	return(
    	<div>
        	<img src={require('../../images/lesme.jpg').default} alt='오류이미지' />
        </div>
    );
}

위와 같이 import 없이도 이미지가 있는 경로에 접근할 수 있다.

주의해야할 점은 뒤에 .default를 꼭 붙여야한다.

require() 함수 자체는 객체를 리턴하기 한다.

img 태그의 src는 이미지 경로가 있는 string이 필요하기에

.default를 붙여 필요한 값의 형태만 받아야 한다.

3) 귀찮음에도 import? 짱 편한 require()?

import를 사용해서 이미지를 불러오는 경우에는 웹팩 같은 모듈 번들러가 사용하지 않는 이미지나 모듈들을 알아서 빼고 빌드한다.

하지만 require()를 사용하는 경우 불필요한 이미지나 모듈을 불러올 수도 있다.

성능을 고려하여 잘 사용하면 되겠다.

4) CSS Background Image 문법 활용

이미지를 사용하는 방법 중 <img> 태그를 이용하는 방법도 있지만 CSS 문법 중 backgroundImage를 활용하는 방법도 있다.

import React from 'react'
import lesMeImg from '../../images/lesme.jpg'

export default function ImageTrain() {
	<div style={{ width:900, height:500,
                backgroundImage:"url("+lesMeImg+")"}} ></div>
}

위와 같이 import를 활용해서 css문법으로 활용할 수 있다.

3. CDN(Contents Delivery Network) 활용

보통 규모가 있는 프로젝트라면 이미지 같은 컨텐츠 파일을 관리하고 내려주는 서버(CDN)가 따로 존재할 것이다.

이런 구조에서는 이미지 파일이 더 이상 React 프로젝트 내부에 존재하지 않고 url 형태 이미지 경로를 활용해야 한다.

간단하게 <img> 태그의 src에 주소만 넣으면 이미지를 불러 올 수 있다.

import React from 'react'

export default function ImageTrain() {
	<div>
		<img src={'https://cdn.image1.com/kind3/images1'} alt='오류이미지' />
    </div>
}

CSS 문법 중 backgroundImage를 활용하는 방법도 아래와 같이 url()형태로 활용하면 된다.

import React from 'react'

export default function ImageTrain() {
	<div>
		<div style={{ width:800, height:500,
                backgroundImage:"url(https://cdn.image1.com/kind3/images1)"}} ></div>
    </div>
}

4. SVG 활용 및 SVGO, SVG Viewer

SVG(Scalable Vector Graphics)는 확장가능한 벡터 그래픽이다.

픽셀을 이용하여 그림을 그리는 png jpg 파일들과 다르게 벡터를 기반으로 이미지를 표현한다.

그러다보니 크기를 조절함에 따라 깨지는 것이 없고, 용량이 작아 웹에서 자주 사용하는 이미지 형식이다.

리엑트에서 SVG를 사용하는 방법은 이미지 활용 방식과 같은 방법과 조금 다른 방법이 있다.

첫번째 방법은 아래와 같이 img 태그에 import한 SVG 파일을 활용하는 것이다.

import React from 'react'
import lesMeImg from '../../images/lesme.svg'

export default function ImageTrain() {
	<div>
		<img src={lesMeImg}  alt='오류이미지' />
    </div>
}

두번째 방법은 SVG를 import할 때 ReactComponent로 받아와 속성을 수정할 수 있도록 하는 방식이다.

import React from 'react'
import { ReactComponent as lesMeImg } from '../../images/lesme.svg'

export default function ImageTrain() {
	<div>
		<lesMeImg fill="white" />
    </div>
}

보통 개발 툴로 VSC(Visual Studio Code)를 활용할 것이다.

jpg나 png 등의 이미지 파일은 VSC에서 열어서 확인해 볼 수 있지만 SVG는 기본적으로 소스코드만 확인해 볼 수 있다.

이를 이미지 형태로 확인해 보려면 Extention을 하나 깔면 확인할 수 있다.

SVG Viewer를 설치하여 SVG의 이미지 형태를 확인하며 사용하자.

마지막으로 SVGO라는 도구를 소개한다.

SVGO(SVG Optimizer)는 SVG 벡터 그래픽 파일을 최적화하기위한 Nodejs 기반 도구이다.

GitHub - svg/svgo: ⚙️ Node.js tool for optimizing SVG files

⚙️ Node.js tool for optimizing SVG files. Contribute to svg/svgo development by creating an account on GitHub.

github.com

포토샵, 일러스트레이터 등의 다양한 그래픽 디자인 도구에서 출력된 SVG 파일은 우리가 실제 이미지로 활용하려는 소스코드 이외에 불필요한 정보를 가지고 있어 성능을 저해한다.

SVGO는 이것들을 제거해 주는 도구이다.

SVG를 많이 만들어서 사용하는 프로젝트라면 이것을 활용해 성능을 올려주는 것이 좋다.

아래 명령어로 설치한다.

npm install svgo
yarn add svgo

이후 모든 svg파일을 한번에 최적화를 진행하는 명령어로 손쉽게 성능을 올려줄 수 있다.

svgo *.svg

기타 다른 옵션들은 공식 홈페이지를 참고하면 된다.

마무리하며

정리하다 보니 리엑트에서 이미지를 활용하는 방법이 꽤 많이 있었다.

리엑트 라이브러리 자체가 개발자를 많이 타서 성능이 꽤 왔다갔다 하는 것을 인지한다면 용량이 꽤 큰 이미지에 대한 활용은 매우 중요하다고 생각한다.

활용법들을 잘 알아두고 적재적소에 코드로 구현해야 겠다.

Google Analytics API 사용법 ②

B급 코딩 — Sun, 9 Jan 2022 21:24:41 +0900

출처 : https://www.optimizesmart.com/how-to-use-google-analytics-api-without-any-coding/

GA를 활용하여 행동데이터를 수집하고 대시보드를 통한 분석 이외에 API 호출을 통한 데이터를 전송받아 대시보드에서는 나타낼 수 없는 표나 그래프를 작성하거나 해당 데이터를 이용하여 통계분석 등에 사용할 수 있다.

지난 포스트에 이어 이번 포스트에서는 연동을 위한 설정 이후 실제 데이터를 가져오는 방법에 대한 가이드이다.

Google Analytics API 사용법 ①

GA를 활용하여 행동데이터를 수집하고 대시보드를 통한 데이터 분석을 할 수 있다. 하지만 정형화된 솔루션이기 때문에 한계가 있다. 커머스 산업 중심으로 보여지는 전자상거래 대시보드들은

bgradecoding.tistory.com

1. GA에 설정된 맞춤 정의 가져오기

GA 구성을 진행하면 해당 계정에 여러 정보를 만들어야 한다.

GA에서 기본적으로 제공하는 Dimension을 제외하고도

사용자가 필요에 의해 만드는 Custom Dimension(맞춤 측정기준), Custom Metric(맞춤 측정항목)이 있을 것이다.

이외에도 Conversion 요소로 잡는 Goals(목표)과 다양한 그래프 구성을 위한 Segment(세그먼트) 등이 있다.

GA API를 사용하면 이것들을 조회해 올 수 있고 추가, 삭제, 업데이트도 가능하다. 하지만 추가, 삭제, 업데이트의 경우 GA 대시보드에 주는 영향이 클 수 있어 조회만을 API를 활용하는 것을 권장한다.

1) Custom Dimension(맞춤 측정기준)

GA의 UA 버전에서 20개(무료 버전)까지 제공하는 값으로 이벤트 수집시 카테고리, 액션, 라벨으로만 수집하기에는 수집범위가 넓을때 해당 값을 만들어 사용한다.

GA API를 활용하여 이 값들을 가져오도록 하자

지난 글의 Sample 코드를 조금만 변형하고 새로운 메소드를 사용하면 손쉽게 가져올 수 있다.

역시 파이썬을 사용한다.

from apiclient.discovery import build
from oauth2client.service_account import ServiceAccountCredentials
from googleapiclient.errors import HttpError
from googleapiclient import sample_tools
 
 
def get_service(api_name, api_version, scopes, key_file_location):
    """Get a service that communicates to a Google API.
 
    Args:
        api_name: The name of the api to connect to.
        api_version: The api version to connect to.
        scopes: A list auth scopes to authorize for the application.
        key_file_location: The path to a valid service account JSON key file.
 
    Returns:
        A service that is connected to the specified API.
    """
 
    credentials = ServiceAccountCredentials.from_json_keyfile_name(
        key_file_location, scopes=scopes)
 
    # Build the service object.
    service = build(api_name, api_version, credentials=credentials)
 
    return service
 
 
# Define the auth scopes to request.
scope = 'https://www.googleapis.com/auth/analytics.readonly'
key_file_location = 'API JSON 파일 상대경로' #지난 포스트 참고 ( 예시 : ./JSON명 )
 
 
# Authenticate and construct service.
service = get_service(
    api_name='analytics',
    api_version='v3',
    scopes=[scope],
    key_file_location=key_file_location)
 
 
dimensions = service.management().customDimensions().list(
    accountId = 'GA 보기 ID' #지난 포스트 참고,
    webPropertyId = 'GA 트레킹 ID' #지난 포스트 참고( 예시 : UA-어쩌고 )
).execute()
 
 
# 받아온 값을 출력하기 위한 부분
for dimension in dimensions.get('items', []):
    print('Dimension Name '+str(dimension.get('index')) +
          ' ===== ' + dimension.get('name'))

해당 코드 실행 결과는 아래와 같다.

API를 호출한 GA는 현재 이 블로그와 연결이 되어 있다.

Dimension Name 1 ===== 포스트 제목
Dimension Name 2 ===== 포스트 태그명
Dimension Name 3 ===== 검색어
Dimension Name 4 ===== 포스트 카테고리

설정해둔 맞춤 측정항목을 잘 가져오는 것을 알 수 있다.

2) Custom Metric( 맞춤 측정항목 )

Dimension과 다르게 수치값을 저장하는 Custom Metric 또한

GA를 구성하면서 많이 만들어서 사용한다.

Dimension GA API와 마찬가지로 조회, 수정, 삭제, 업데이트가 가능하지만
역시 조회만 사용하기를 권장한다.

from apiclient.discovery import build
from oauth2client.service_account import ServiceAccountCredentials
from googleapiclient.errors import HttpError
from googleapiclient import sample_tools
 
 
def get_service(api_name, api_version, scopes, key_file_location):
    """Get a service that communicates to a Google API.
 
    Args:
        api_name: The name of the api to connect to.
        api_version: The api version to connect to.
        scopes: A list auth scopes to authorize for the application.
        key_file_location: The path to a valid service account JSON key file.
 
    Returns:
        A service that is connected to the specified API.
    """
 
    credentials = ServiceAccountCredentials.from_json_keyfile_name(
        key_file_location, scopes=scopes)
 
    # Build the service object.
    service = build(api_name, api_version, credentials=credentials)
 
    return service
 
 
# Define the auth scopes to request.
scope = 'https://www.googleapis.com/auth/analytics.readonly'
key_file_location = 'API JSON 파일 상대경로' #지난 포스트 참고 ( 예시 : ./JSON명 )
 
 
# Authenticate and construct service.
service = get_service(
    api_name='analytics',
    api_version='v3',
    scopes=[scope],
    key_file_location=key_file_location)
 
 
dimensions = service.management().customDimensions().list(
    accountId = 'GA 보기 ID' #지난 포스트 참고,
    webPropertyId = 'GA 트레킹 ID' #지난 포스트 참고( 예시 : UA-어쩌고 )
).execute()
 
 
# 받아온 값을 출력하기 위한 부분
for metric in metrics.get('items', []):
    print('Metric Name =============== ' + metric.get('name'))

해당 코드를 실행하면 Custom Metric을 조회해 올 수 있다. 결과는 아래와 같다.

Metric Name =============== 포스트 총 조회수

이것을 GA에서 확인해 보자

위와 같이 설정된 맞춤 측정기준과 측정항목을 잘 가져온 것을 볼 수 있다.

나머지 사항들( 목표, 세그먼트 )도 똑같은 방식으로 가져온다.

https://developers.google.com/analytics/devguides/config/mgmt/v3/parameters

위 링크를 참조하면 필요한 코드들을 얻어서 GA의 계정정보들을 조회해 올 수 있다.

2. 실제 수집 데이터 조회하기

GA에서 수집된 데이터는 대시보드를 통해 필터를 걸거나 Dimension들을 조합하여 데이터를 볼 수 있다.

하지만 한정된 대시보드 화면에서는 필터를 거는 것도 제한적이고 원하는 시각화 화면을 그리는 것도 불가능하다

하지만 GA API를 이용하면 데이터 가공 및 시각화의 제한에서 벋어날 수 있다.

몇가지 케이스를 통해 데이터를 가져오는 쿼리에 대해 알아 보자

아래 코드는 지난 포스트의 샘플 코드 중에서 실제 데이터를 가져오는 쿼리 부분만 변경한 것이다.

# 샘플 코드에서 쿼리 부분의 코드만 설명한다.
 
result = service.data().ga().get(
    ids='ga:보기ID',
    start_date='2022-01-05',
    end_date='2022-01-07',
    metrics='ga:totalEvents',
    filters='ga:eventCategory=~^post_click*',
    sort='-ga:totalEvents',
    dimensions='ga:pagePath, ga:eventCategory'
).execute()

파라미터 하나하나에 대한 설명은 아래와 같다.

( ids, start_date, end_date 는 직관적이고 넣을 값이 고정적이여서 생략한다. )

1) metrics
파라미터로 보내는 Dimension에 대한 수치 값을 설정하는 영역이다.

metrics='ga:totalEvents',

위 예시는 해당 Dimension에 대해 총 이벤트 수를 가져오라는 의미이다.

ga:users 값을 넣으면 해당 Dimension에 총 사용자 수를 가져오라는 의미이다.

2) dimensions
파라미터로 보내는 metrics의 기준이 되는 값을 설정하는 영역이다.

dimensions='ga:pagePath, ga:eventCategory'

위 예시는 totalEvent 수를 가져오는데 pagePath 별로 eventCategory 별로 조회하라는 의미이다.

GA API에서 제공하는 metrics과 dimensions은 대시보드에서 쓸 수 있는 모든것을 그대로 쓸 수 있다.

API에 넣어야할 metrics과 dimensions은 아래 링크를 참고하면 된다.

UA Dimensions & Metrics Explorer

The Dimensions & Metrics Explorer lists and describes all of the dimensions and metrics available through the Core Reporting API. Explore all of the dimensions and metrics – Search or browse by group. Select a dimension or metric for additional details s

ga-dev-tools.web.app

3) filters
조회하는 Dimension에 조건을 거는 것이다.

SQL문에서 where 절과 같다고 생각하면 쉽다.

filters='ga:eventCategory=~^post_click*'

위 예시는 eventCategory가 post_click으로 시작하는 dimension만 조회하라는 의미이다.

4) sort
조회하는 Dimension이나 metric 에 순서를 부여하는 것이다.

SQL문에서 order by 절과 비슷하다고 생각하면 쉽다.

sort='-ga:totalEvents',

위 예시는 totalEvents를 기준으로 내림차순으로 정렬하라는 의미이다.

-를 붙이면 내림차순이고 -를 없애면 오름차순이 된다.

API 파라미터들에 대한 정의를 아래 링크에서 확인할 수 있다.

Core Reporting API - Reference Guide | Analytics Core Reporting API | Google Developers

Core Reporting API - Reference Guide This document provides the complete reference for both query and response for the Core Reporting API version 3.0. There is an updated version of the Google Analytics Reporting API. We recommend migrating your code today

developers.google.com

Google Analytics API 사용법 ①

B급 코딩 — Wed, 5 Jan 2022 01:50:32 +0900

출처 : https://www.optimizesmart.com/how-to-use-google-analytics-api-without-any-coding/

GA를 활용하여 행동데이터를 수집하고 대시보드를 통한 데이터 분석을 할 수 있다.

하지만 정형화된 솔루션이기 때문에 한계가 있다.

커머스 산업 중심으로 보여지는 전자상거래 대시보드들은 다른 산업에서 쓰기에는 무리가 있고

여러개의 필터링을 걸어서 비교할 수 있는 대시보드는 만들 수 없다.

또한 레거시 DB에 있는 데이터를 GA데이터와 합쳐서 분석하기에도 한계가 분명하다.

이 한계를 뛰어 넘기 위해 빅쿼리를 이용하는 방법이 있지만 비용 문제가 수반된다.

(GA4는 빅쿼리가 무료 연결되고 무료로 어느정도 쓸 수 있지만 제한이 있다)

이를 극복할 수 있는 방안이 API를 활용하는 것이다.

API 호출을 통해 전달받은 데이터로 대시보드에서는 나타낼 수 없는 표나 그래프를 작성할 수 있고

해당 데이터를 이용하여 수준높은 통계분석도 가능하다.

본 포스팅에서는 연동을 위한 설정 작업과 간단한 샘플 코드를 통해 API가 연동 되는지 확인하는

절차를 다룬다.

다음 글에서 실제 데이터를 필터링, 정렬, 타케팅 하는 법을 알아본다.

1. 서비스 계정 추가 및 API 키(JSON) 내려받기

일단 GA API를 사용하기 위해서는 GCP 콘솔에서 서비스 계정을 추가하고

API를 호출할 때 필요한 키를 JSON 형태로 다운로드 받아야 한다.

GCP 콘솔에 접속한다. https://console.cloud.google.com/

프로젝트가 생성되어 있다면 기본 프로젝트 화면이 보일 것이고

프로젝트 생성을 안했다면 프로젝트 생성부터 해준다.

첫 화면에서 "프로젝트 설정으로 이동" 을 클릭한다.

이후 좌측 메뉴에서 "서비스 계정"을 선택하고 상단에 "서비스 계정 만들기"를 클릭한다.

이후 나타나는 입력 화면에서 필수사항들만 입력해준다.

원하는 대로 입력하면 된다. 그런 이후 완료를 누른다.

이후 생성된 서비스 계정에서 "키 관리"를 클릭해 준다.

"새 키 만들기"를 클릭해 준다.

이후 뜨는 모달창에서 JSON 형태로 만들기를 클릭한다.

그럼 JSON 파일 하나가 다운로드 될 것이다.

이 파일은 다시 받을 수가 없으므로 잘 보관해야 한다.

이제 다운받은 JSON 파일을 열어보자.

열면 키-값 형태로 여러 줄의 데이터가 보일 것이다.

이 중 client_email이라는 키의 값을 복사한다. 편의상 값을 aaabbbbccccc.iam.gserviceaccount.com이라 하겠다.

이제 API 호출을 이용할 GA 속성에 접속한다.

"관리" 메뉴에서 "계정 엑세스 관리"를 누르고 우측 상단에 있는 사용자 추가를 눌러준다.

이후 aaabbbbccccc.iam.gserviceaccount.com 이 값을 추가해 주고 표준역할을 "뷰어" 이상으로 설정해 준다.

이후 다시 GCP 콘솔에 접속해서 GA API 사용을 허용해 준다.

해당 메뉴로 들어간 후 API 라이브러리에서 GA API를 찾아서 사용을 클릭한다.

2. 샘플 코드

Google에서는 GA API로 활용할 수 있는 서비스 언어로 3가지를 제공하고 있다.

Python, PHP, Java 이다.

자세한 내용은 아래 링크를 참고하기 바란다.

What Is The Core Reporting API - Overview | Analytics Core Reporting API | Google Developers

Access Google Analytics report data to build custom dashboards, automate complex reporting tasks, and integrate your data with other applications.

developers.google.com

여기서는 편의를 위해 Python을 활용한다.

일단 .py 파일을 하나 생성하고 같은 위치에 다운로드한 JSON 파일을 둔다.

이후 API 호출에 필요한 라이브러리를 pip 명령어를 통해 다운로드 한다.

pip install --upgrade google-api-python-client
pip install oauth2client

이제 샘플 코드를 작성해 보자.

from apiclient.discovery import build
from oauth2client.service_account import ServiceAccountCredentials
from pprint import pprint
 
def get_service(api_name, api_version, scopes, key_file_location):
 
 
    credentials = ServiceAccountCredentials.from_json_keyfile_name(
            key_file_location, scopes=scopes)
 
    # Build the service object.
    service = build(api_name, api_version, credentials=credentials)
 
    return service
     
     
# Define the auth scopes to request.
scope = 'https://www.googleapis.com/auth/analytics.readonly'
 
# 다운로드 받은 JSON의 위치를 상대경로로 선언
key_file_location = './다운받은.json'
 
# Authenticate and construct service.
service = get_service(
        api_name='analytics',
        api_version='v3',
        scopes=[scope],
        key_file_location=key_file_location)
         
# Get a list of all Google Analytics accounts for this user
accounts = service.management().accounts().list().execute()
 
if accounts.get('items'):
    # Get the first Google Analytics account.
    account = accounts.get('items')[0].get('id')
 
    # Get a list of all the properties for the first account.
    properties = service.management().webproperties().list(accountId=account).execute()
     
     
     
# 일주일간 세션수와, 페이지뷰수 받아오기
# ids의 값은 GA의 보기의 ID 값이다.
result = service.data().ga().get(
            ids='ga:보기의id값',
            start_date='7daysAgo',
            end_date='today',
            metrics='ga:sessions,ga:pageviews').execute()

코드를 실행하면 결과가 오는 것을 볼 수 있다.

ids에 들어갈 ga보기 id 값은 아래와 같이 확인할 수 있다.

다음 글에서는 본격적으로 데이터를 가져와 보겠다.

Google Analytics API 사용법 ②

GA를 활용하여 행동데이터를 수집하고 대시보드를 통한 분석 이외에 API 호출을 통한 데이터를 전송받아 대시보드에서는 나타낼 수 없는 표나 그래프를 작성하거나 해당 데이터

bgradecoding.tistory.com

[React-Typescript] form 지옥에서 벗어나기 (formik)

B급 코딩 — Thu, 30 Dec 2021 01:17:55 +0900

출처 : https://formik.org/

React로 서비스를 개발하다보면 사용자 입력을 받아 처리하는 서식, 즉 form 형태를 많이 만들어야 한다.

대표적인 form으로는 모든 서비스에 거의 다 있는 로그인 기능이다.

아래는 React에서 Typescript 기반으로 작성한 단순한 로그인 form 예시다.

import React, { ReactElement } from 'react';


interface LoginForm {
  email: string;
  password: string;
}

export default function Login() {
	
  const [email, setEmail] = React.useState('')
  const [password, setPassword] = React.useState('')
  
  const handleSubmit = (values: LoginForm) => {
    console.log('go login');
  };
  return(
  
  <>
  
  <form onSubmit={handleSubmit}>
  
    <input value={email} handleChange={(e) => 
    {setEmail(e.target.value)}} />
    
    <input value={password} handleChange={(e) => 
    {setPassword(e.target.value)}} />
    
    <button type="submit">login</button>
    
  </form>
  
  </>
  );
}

지금은 input이 두개뿐이여서 state를 세팅하는 로직이 handleChange 함수에 두개 들어가있다.

하지만 회원가입 화면이라면 어떨까?

우리는 똑같은 코드를 입력 칸만큼 해야하는 지옥에 빠져들게 된다.

로그인 화면도 단순하게 id, password를 입력하는 input 태그와

로그인 버튼만 만들면 다가 아니다.

id, password 입력이 정상적으로 이루어 졌는지 체크하는 로직이 필요하고

id가 글자제한이 있다면 제한글자까지만 써지게 하는 로직도 필요하다.

만약 id가 email 형태라면 해당 형식에 맞는지 체크해야하기도 한다.

이것이 앞선 예시처럼 회원가입 화면이였다면?

더욱 더 많은 체크로직으로 코드는 매우 복잡해질 것이다.

이 노가다 작업을 많이 개선해줄 Formik에 대해 알아보자.

1. Formik 소개

Formik은 React의 장황한 form을 3가지 측면에서 도와주는 작은 라이브러리다.

form state 안팎에서 값 가져오기
유효성 검사 및 오류 메시지
form submit 처리

현재 시점에 비슷한 라이브러리들과의 다운로드 수를 비교해보면 1위를 달리고 있다.

formik이 다른 라이브러리들에 비해 성능 측면이나 추론, 리펙토링에서 우위를 점하고 있다.

설치하기

yarn add formik
or
npm install formik

2. 기본 Formik 사용하기 ( /w Typescript )

Formik을 사용하지 않고 만들었던 로그인 화면을 유효성 검사를 도와는 yup라이브러리와 함께 개선해보았다.

import React, { ReactElement } from 'react';
import { Form, Formik, Field, ErrorMessage } from 'formik';
import * as Yup from 'yup';


//유효성 검사를 위한 yup 라이브러리 기능을 변수에 담는다.
const ValidationSchema = Yup.object().shape({
  email: Yup.string().email().required('email은 필수항목입니다.'),
  password: Yup.string().required('password는 필수항목입니다.'),
});


//로그인에 사용될 변수의 타입을 정의한다.
interface LoginForm {
  email: string;
  password: string;
}

export default function Login() {

  const handleSubmit = (values: LoginForm) => {
    console.log(values);
  };
  
  <Formik
   initialValues={{ email: '', password: '' }}
   validationSchema={ValidationSchema}
   onSubmit={handleSubmit}>
     <Form>
        <Field
        name="email"
        type="email"
        placeholder="Email"
        className="border-0 px-3 py-3 placeholder-blueGray-300 text-blueGray-600 bg-white rounded text-sm shadow focus:outline-none focus:ring w-full ease-linear transition-all duration-150"
        form={''}
        />
        <ErrorMessage name="email" component="div" className="text-xs text-red-500 py-1" />
                   
        <Field
         name="password"
         type="password"
		 className="border-0 px-3 py-3 placeholder-blueGray-300 text-blueGray-600 bg-white rounded text-sm shadow focus:outline-none focus:ring w-full ease-linear transition-all duration-150"
		 placeholder="Password"
		/>
		<ErrorMessage name="password" component="div" className="text-xs text-red-500 py-1" />
		<button
		className="bg-blueGray-800 text-white active:bg-blueGray-600 text-sm font-bold uppercase px-6 py-3 rounded shadow hover:shadow-lg outline-none focus:outline-none mr-1 mb-1 w-full ease-linear transition-all duration-150"
		type="submit">
		Sign In
		</button>
     </Form>
	</Formik>
  );
}

이렇게 하면 setState를 입력란 마다 붙이지 않아도 되며

유효성 체크와 에러메시지까지 잡을 수 있다.

앞서 언급했듯이 이는 입력란이 많을 수록 더욱 빛을 바란다.

위부터 차분히 살펴보자

1) <Formik> 컴포넌트

이 컴포넌트에는 initialValues와 onSubmit은 필수 값이다.

initialValues는 form의 입력란에 들어갈 value의 초기값이다.

onSubmit은 제출 시에 실행될 함수다.

yup을 사용하면서 들어가는 속성값으로 validationSchema가 있다.

yup은 유효성 체크에 정말 뛰어난 라이브러리이다.

해당 기능들을 더 알고 싶다면 아래 문서를 참고하라.

yup

Dead simple Object schema validation

www.npmjs.com

2) <Form>, <Field> 컴포넌트

<Form>컴포넌트는 html에서 <form>태그와 비슷한 역할을 한다.

이 컴포넌트 아래 <Field>컴포넌트를 두고 props로 name을 initialValues의 키값으로 세팅하면

우리가 setState를 했던 것과 해당 값을 가져와서 유효성 검사를 하는 것이 모두 자동 설정된다.

3) <ErrorMessage> 컴포넌트

우리가 yup에서 정의했거나 미리 yup에서 정의해둔 에러메시지를 표시해주는 곳이다.

어떤 component에 메시지를 표시할 것인지와 className으로 스타일을 지정해 줄 수 있다.

3. Formik의 다양한 활용

위에서 예시로 든 코드는 Formik의 간단한 활용이였다.

이제 더 다양한 방법으로 Formik을 활용해 보자.

import React, { ReactElement } from 'react';
import { Form, Formik, Field, ErrorMessage, FormikProps } from 'formik';
import * as Yup from 'yup';

interface LoginForm {
  email: string;
  password: string;
  checkbox: string;
  radio: Array<string>;
}

const ValidationSchema = Yup.object().shape({
  email: Yup.string().email().required('email은 필수항목입니다.'),
  password: Yup.string().required('password는 필수항목입니다.'),
});

export default function FormikPractice() {
  const handleSubmit = (values: LoginForm) => {
    console.log(values);
  };

  return (
    <Formik
      initialValues={{ email: '', password: '', checkbox: '', radio: [] }}
      validationSchema={ValidationSchema}
      onSubmit={(data: LoginForm, { setSubmitting }) => {
        setSubmitting(true);
        handleSubmit(data);
        setSubmitting(false);
      }}>
      {(props: FormikProps<LoginForm>) => {
        const { values, touched, errors, handleBlur, handleChange, isSubmitting } = props;
        return (
          <Form>
            <div className="relative w-full mb-3">
              <label className="block uppercase text-blueGray-600 text-xs font-bold mb-2">Email</label>
              <Field
                name="email"
                type="email"
                placeholder="Email"
                onChange={handleChange}
                className="border-0 px-3 py-3 placeholder-blueGray-300 text-blueGray-600 bg-white rounded text-sm shadow focus:outline-none focus:ring w-full ease-linear transition-all duration-150"
                form={''}
              />
              <ErrorMessage name="email" component="div" className="text-xs text-red-500 py-1" />
            </div>

            <div className="relative w-full mb-3">
              <label className="block uppercase text-blueGray-600 text-xs font-bold mb-2">Password</label>
              <Field
                name="password"
                type="password"
                className="border-0 px-3 py-3 placeholder-blueGray-300 text-blueGray-600 bg-white rounded text-sm shadow focus:outline-none focus:ring w-full ease-linear transition-all duration-150"
                placeholder="Password"
              />
              <ErrorMessage name="password" component="div" className="text-xs text-red-500 py-1" />
            </div>

            <div className="relative w-full mb-3">
              <Field name="checkbox" type="checkbox" value="formikcheckbox" />
            </div>

            <div className="relative w-full mb-3">
              <Field name="radio" type="radio" value="formik1" />
              <div>formik1</div>
              <Field name="radio" type="radio" value="formik2" />
              <div>formik2</div>
              <Field name="radio" type="radio" value="formik3" />
              <div>formik3</div>
              <Field name="radio" type="radio" value="formik4" />
              <div>formik4</div>
            </div>

            <div className="text-center mt-6">
              <button
                className="bg-blueGray-800 text-white active:bg-blueGray-600 text-sm font-bold uppercase px-6 py-3 rounded shadow hover:shadow-lg outline-none focus:outline-none mr-1 mb-1 w-full ease-linear transition-all duration-150"
                type="submit"
                disabled={isSubmitting}>
                Sign In
              </button>
            </div>
          </Form>
        );
      }}
    </Formik>
  );
}

위는 Formik으로 활용할 수 있는 예시를 담은 코드이다.

몇가지 포인트를 살펴보면

1) FormikProps의 사용

2.번 예시에서 들었던 소스와 비교했을 때 가장 먼저 변한 것이 Formik 컴포넌트 아래 함수형태로 시작한 것이다.

이는 Form 컴포넌트 안에서 FormikProps를 활용하기 위한 것으로

소스에서 확인 할 수 있듯이 values, handleBlur, handleChange, isSubmitting 등을 가져다 쓸 수 있다.

2) 버튼 두번 클릭 방지

Formik을 쓸 때 편한 기능 중 하나인 두번 클릭 방지 기능이 있다.

isSubmitting을 button태그에 disabled에 달아두었다.

이를 submit함수에서 비동기 처리 전에 true로 세팅했다가 끝나면 false로 세팅하는 것을 볼 수 있다.

button에서 이 값을 참조하여 disable처리가 되어 두번 클릭을 방지 한다.

3) 다양한 input 활용

입력란은 단순 text input 태그만 존재하는 것이 아니다.

체크박스도 존재하고 라디오 버튼도 존재한다.

initialValues에 추가된 checkbox와 radio가 그 예시이다.

checkbox는 선택을 하면 값이 배열 형태로 온다. 선택을 하지 않으면 빈 string이 온다.

radio버튼은 만들어진 4개 중 선택한 값만 온다.

마무리

지금까지 Formik을 React-typescript에서 사용하는 방법에 대해 알아봤다.

Formik은 정말 form작성에 없어서는 안될 라이브러리이다.

설명에 언급하진 않았지만 이것을 활용하면 회원가입시 아이디중복 체크를 하는 서버통신 유효성 체크까지

추론이 쉽게 붙일 수 있다.

그 외 다양한 활용 방법들은 공식문서를 참고하자.

Formik

React hooks and components for hassle-free form validation. The world's leading companies use Formik to build forms and surveys in React and React Native.

formik.org

프로그래밍의 근본, 알고리즘 (feat. 코딩테스트)

B급 코딩 — Mon, 27 Dec 2021 23:58:59 +0900

프로그래밍은 문제 해결능력이다.

프로그래밍은 매우 복잡한 과정이며 조합의 결과물이다.

지금 세상에는 배워야할 언어도, 라이브러리도, 프레임워크도, 심지어 SaaS 서비스까지 그 수는 헤아릴 수없을 정도이다.

프로그래밍의 전체 과정은 이를 잘 조합해서 서비스를 만드는 과정이다.

간단한 웹사이트 만들기에도 많은 결정사항들과 조합이 따라온다.

일단 비즈니스를 웹에 잘 녹이는 의사결정부터 해야한다. 여기만 해도 벌써 머리가 아플 것이다.

기능정의 부터 사용자 친화적 UI/UX, 사이트맵 등등이 따라온다.

기술적으로 들어가면 프론트앤드는 무엇으로 할것인지

백엔드는 어떤 언어와 프레임워크의 조합으로 갈 것인지

협업 툴은 무엇을 사용할지

인프라는 어떻게 구성할지

아니면 그냥 SaaS 서비스를 활용할지

결정해야할 포인트도 수백가지고 그것들의 조합을 따지면 거의 무한대에 가깝다.

웹사이트 제작에도 수많은 결정을 해야한다.

결국 프로그래밍을 하여 서비스를 만드는 것은 적절한 선택으로 문제를 해결해 가는 능력으로 귀결된다고 본다.

여러 매체들에서 프로그래머에게 가장 중요한 역량은 무엇인가를 물으면 모두들 문제해결 능력을 이야기하는 것이

결국 이 복잡한 단계들에 대한 해결이 기다리고 있기 때문이다.

그럼 그 능력을 얻기위해 무엇을 해야할까?

더많은 선택지들을 배우고 장단점을 알면 되는 것일까?

그러다 내가 배운 선택지들이 인기가 없어지고 사장되면 또 다른것을 배워야 하는것인가?

결국 해답은 근본에 있다고 생각한다.

컴퓨터 공학이 나온 이후로 계속해서 베이스 지식으로 강조되는 영역, 바로 알고리즘이다.

알고리즘이란 무엇인가?

알고리즘이란 단어를 한번쯤 수학 책에서 몇가지 도형과 선으로 만들어진 형태로 접해보았을 것이다.

알고리즘을 위키피디아에서는 아래와 같이 정의한다.

"알고리즘이란?, 셈법은 수학과 컴퓨터과학, 언어학 또는 엮인 분야에서 어떠한 문제를 풀어내기 위해 정해진 일련의 절차나 방법을 공식화한 형태로 표현한 것, 계산을 실행하기 위한 단계적 절차를 의미한다. 즉, 문제풀이에 필요한 계산절차 또는 처리과정의 순서를 뜻한다."

간단하게 말하면 어떤 입력을 어떤 출력으로 변환하는 일련의 계산과정이라 정의할 수 있다.

우리가 접하는 대부분의 프로그래밍 문제들에서

알고리즘을 정의해 보면 "수에 대한 문제를 풀기 위한 명확하고 유한한 방법의 절차"이다.

"수에 대한"이 의문일수도 있겠지만 결국 컴퓨터는 0과1로 모든것을 해결하는 도구이다.

요즘 뜨고 있는 딥러닝 문제도 결국은 이미지를 수로 바꿔서 처리하고

자연어 처리도 형태소 분석등을 통해 결국 수로 바꿔서 문제를 처리한다.

주어진 조건 맞게 적절한 출력을 하기위한 계산과정을 설계해 나가는게 알고리즘을 만드는 과정이고

이것이 결국 문제해결 과정을 닮아 있다.

알고리즘을 만드는 과정과 문제해결 과정

「어떻게 문제를 풀 것인가(How to Solve It)」 책에서 소개하는 문제 해결 과정

1) 문제를 이해한다.
2) 어떻게 풀지 계획을 세운다.
3) 계획을 수행해서 문제를 해결한다.
4) 어떻게 풀었는지 돌아보고, 개선할 방법이 있는지 찾아본다.

알고리즘을 만드는 과정은 아래와 같이 정리할 수 있다.

1) 주어진 문제를 이해한다.

2) 흐름과 처리를 조합해 계산과정을 설계한다.

3) 처리마다 수를 추적하며 검증한다.

4) 더 나은 과정을 고려해 본다.

※ 흐름과 처리
프로그래밍 기초단계는 사실 크게 3가지로 이루어져 있다고 생각한다.
조건문, 반복문, 변수 가 그것이다.
이를 조합하여 더 복잡한 문법들이 만들어진다고 본다.

처리는 결국 변수이다.
입력, 연산, 출력 모두 변수를 가지고 이루어지기 때문이다.
흐름은 조건문과 반복문이다.
프로그래밍이 대부분 위에서 아래로 순차적으로 흐르고 그 안에서 어느부분은 반복하고 분기처리 할 것인지가 관건이다.

매우 유사한 것을 볼 수 있다.

기업에서 코딩 테스트를 기본 소양으로 제시하는데도 이 이유가 맞닿아 있을 것이다.

입사한 이후에도 계속해서 사내 테스트를 시행하여 알고리즘 문제를 해결하여 평가하는 이유도 마찬가지 이다.

알고리즘을 만드는 과정 자체가 문제해결 능력을 기르는 연습이 되기 때문이다.

Atomic Design Pattern (feat. React, Vue, Flutter)

B급 코딩 — Sun, 26 Dec 2021 23:21:53 +0900

출처 : https://uxdesign.cc/grouping-components-in-atomic-design-systems-4d6e2095ea45?gi=48b4cf4fec10

현재 프론트엔드 분야에서 제일 잘 나가고 있는 자바스크립트 라이브러리 및 프레임워크를 뽑으라면

누구도 주저없이 React와 Vue를 뽑을 것이다.

또한 얼마전 2.0을 발표한 Flutter 역시 모바일 분야에서 그 입지를 다지고 있다.

위에서 언급한 3가지( React, vue, Flutter )가 공통적으로 가지는 특징이 있다.

바로 Component 중심 설계 패턴으로 되어 있다는 것이다.

예전의 UI 개발은 하나의 페이지를 통으로 설계하는 방식이 대부분이였다.

이는 기능별 재사용성 및 페이지 상태에 따른 .class 분기나 CSS 상속 등을 고려하여 작업했다.

하지만 컴포넌트 중심 설계 패턴 라이브러리와 프레임워크들이 유행하면서

컴포넌트들을 잘 쪼개서 설계하고

이를 합쳐 하나의 페이지를 만드는 방식으로 UI개발 패러다임의 전환이 일어났다.

1. Atomic Design 방법론이란?

Atomic Design은 화학의 개념을 웹에 도입하여 인터페이스를 세분화한 디자인 방법론이다.

화학에서 유기체를 분자로 나눌 수 있고 분자는 다시 원자로 나누는 환원주의적 철학을

프로그래밍 요소로 변환한 것이다.

출처 : https://uxdesign.cc/grouping-components-in-atomic-design-systems-4d6e2095ea45?gi=48b4cf4fec10

기본적으로 ATOMS(원자들) -> Molecules(분자들) -> Organisms(유기체) -> Templates(템플릿) -> Pages(페이지)

로 구성하여 설계한다.

2. Atomic Design의 구성요소

1) Atoms

화학에서처럼 가장 작은 단위의 컴포넌트이다( 물론 화학에는 양성자, 중성자, 전자 등이 또 존재하지만... )
가장 기본이 되는 요소이기 때문에 많은 가능성을 가지고 있어야 한다.

계속해서 화학을 예로 들어보면
수소 원자만 해도 수소 두개가 합쳐져 수소기체가 될 수도 있고 산소 원자와 합쳐져 물이 될 수도 있다.
이처럼 수소원자 온도, 압력 등의 환경에 따라 여러가지로 변할 수 있다.

개발에서도 마찬가지이다.
원자로 만들어지는 컴포넌트는 어느곳에 들어갈 수 있도록 다양한 state가 포함되어 만들어져야 한다.
단순 Input 태그만 하더라도 그 안의 타입이 password인지 text인지,
또는 입력을 할 수 있는지, disable 시킬 것인지를 폭넓게 고려해서 만들어야 한다.
고유의 특성만을 가지고 있어야 한다.

화학에서 원자는 각 원자의 고유한 특성을 가지고 있지만 원자끼리 합쳐져 분자가 됬을때
물질의 특성을 띄게 된다.

개발에서도 원자 컴포넌트들은 해당 컴포넌트가 가지는 고유 역할만을 특징으로 가지고
CSS적인 요소가 변할 수 있도록 설계되어야 한다.

2) Molecules

원자들이 합쳐져 조금 복잡한 기능을 하는 컴포넌트이다.

물 분자는 가운데에 산소원자가 위치가 하고 양옆에 수소원자 2개가 동일한 각도를 가지고 위치한다.
이처럼 분자 컴포넌트도 원자들에게 기능 및 CSS적인 요소를 줄 수 있다.

분자만의 특성들을 가지고 있지만 재사용성을 생각하여 개발하는 것이 중요하다.

3) Organisms

분자들을 합치거나 때로는 분자와 원자를 합쳐서 생성하는 컴포넌트이다.
유기체가 완성되면 하나의 기능을 수행할 수 있는 컴포넌트가 완성된다.
유기체 하나를 너무 특화시키기 보다는 재사용성을 고려하는 것이 좋다

물분자들이 모여서 만들어진 물은 여전히 설탕을 녹여 설탕물이 될 수 있고
소금이 녹아 소금물이 될 수도 있다.

4) Template

템플릿은 화학의 은유를 깨고 유기체들의 레이아웃을 잡는 역할을 한다.
이는 곧 페이지의 그리드를 정해주는 것이다.

5) Pages

마지막 단계로 템플릿을 이용하여 각 그리드에 컴포넌트를 그려 페이지를 완성한다.

아래는 인스타그램을 예시로 작성된 Atomic Design 이다.

3. 장단점

장점

컴포넌트 중심의 환원주의적 사고가 React, Vue, Flutter 등과 잘 어울린다.
여러 명의 개발자가 같이 개발할때 협업이 용이할 수 있다. ( 일관된 컴포넌트 관리체계 수립 )
신규 투입자나 주니어 개발자가 페이지 레이아웃을 이해하는데 소요되는 시간이 적다.
잘 설계되면 가독성이 올라간다.
재사용 가능한 컴포넌트가 많은 큰 규모의 프로젝트에서 개발생산성을 높일 수 있다.

단점

아직은 시장에 기존 마크업 방식의 디자인이 익숙한 디자이너들이 많아 개발자의 역할이 많아질 수 있다.
일관성 있는 컴포넌트 개발이 이뤄지지 않으면 코드가 산으로 갈 수 있다.
재사용 컴포넌트가 많이 존재하지 않는다면 초기 시간이 많이 들 수 있어 개발 생산성이 떨어진다.

코멘트

StoryBook과 함께 컴포넌트를 잘 설계한다면 뛰어나 React, Vue 프로젝트 기반이 될 수 있다.

참고문서

https://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces

Atomic Design Methodology | Atomic Design by Brad Frost

Learn how to create and maintain digital design systems, allowing your team to roll out higher quality, more consistent UIs faster than ever before.

atomicdesign.bradfrost.com

개발자가 이해하는 북극성 지표(North Star Metric)

B급 코딩 — Sun, 26 Dec 2021 00:42:58 +0900

출처 : https://growwithward.com/north-star-metric/

개발을 도와주는 SaaS(Software-as-a-Service)형 서비스가 많아지면서

과장을 조금 보태면 비즈니스만 알고도 제품이나 서비스를 런칭할 수도 있다.

디지털 마케팅은 점차 고도화 되고 있고 제품 혹은 서비스에 대한 측정은 이제 기본이 된 시대이다.

그러면서 마케터, 데이터 사이언티스트, 개발자 간의 경계가 명확했던 선은 점점 희미해지고 있다.

또한 데이터를 통한 조직 경영이 활발해지면서 조직의 지표관리가 확대되고 있다.

한마디로 개발자도 개발만 해서는 안되는 시대가 되었다.

하지만 기본적으로 개발실력은 베이스가 되어야 한다.

방망이도 제대로 못잡는 타자가 투수가 던지는 공을 연구하겠다며 투구폼 분석을 하고 있는건 어불성설이다.

개발이 기본이라는 전제 아래 내가 개발하고 있는 혹은 운영하고 있는 제품이나 서비스가

어떤 방향으로 나아가고 있는지 아는것은 매우 중요하다.

혹은 타부서(기획팀, 사업팀, 마케팅팀)와 협업시에도 이것에 대한 이해는 큰 도움을 준다.

제품이나 서비스가 나아가고 있는 방향을 알려주는 대표적인 지표 중 하나인 북극성 지표에 대해 살펴보고자 한다.

1. 북극성 지표(North Star Metric)란 무엇인가?

북극성 지표는 우리가 만들고 있는, 혹은 운영하고 있는 제품이나 서비스가

사용자들에게 전달하는 핵심적인 가치를 반영한 숫자라고 이해할 수 있다.

따라서 경영자들이 보는 매출, 영업이익 같은 지표는 북극성 지표라고 할 수 없다.

이는 비즈니스 모델 관점에서의 경영지표기 때문이다.

몇가지 북극성 지표의 예시를 들어보면 아래와 같다.

이제 북극성 지표에 대해 어렴풋이 감이 올 것이다.

핵심은 그 제품의 주요 기능과 관련있다는 것이다.

실제로 새로운 제품이나 서비스를 기획할 때 관련된 모든 팀( 개발팀 포함 )을 모아서 북극성 지표를 만들고

모든 팀이 같은 지표를 보고 각자의 일을 얼라인 할 수 있게 한다.

개발팀은 북극성 지표를 만들어 질 때나 이미 정해진 것을 보았을 때

1) 해당 지표를 어떻게 하면 효율적으로 측정할 것인지 ( 측정 솔루션은 어떤 것이 좋은지 )

2) 제품이나 서비스의 기능이 정해진 북극성 지표에 상충하는 기술적 측면( UI/UX관점, 성능 관점, 데이터 taxonomy관점 등 )은 없는지

3) 해당 지표를 위해 실행할 수 있는 A/B test에 대한 준비는 되어 있는지

등을 고민하고 의견을 낼 수 있어야 한다.

하지만 북극성 지표는 매우 큰 의미의 지표이다.

거시적 관점에서 위와 같은 의견을 낼 수 있겠지만 실제 업무와 맵핑하는 것은 쉽지 않다.

2. 북극성 지표의 세부적 활용 ( Input Metrics )

북극성 지표를 정의했다면 자연스럽게 이를 달성하기 위한 투입 지표(Input Metrics)들이 정해질 것이다.

출처 : https://www.reforge.com/blog/north-star-metric-growth

수능시험에서 올 1등급이라는 결과를 가져오려면 참고서 선택, 강의 선택, 공부 계획 등의 투입 전략이 필요하다.

북극성 지표도 마찬가지이다.

북극성 지표라는 큰 지표를 상승시키기 위해서는 하위의 여러 투입 전략이 필요하다.

Spotify의 예시를 보자

출처 : https://www.reforge.com/blog/north-star-metric-growth

투입 지표와 실제 업무를 연관시켜 생각해 보자.

Recommendations이 하나의 투입지표로 정해져 있다.

이 지표를 늘리기 위해 우리는 공유 기능을 만들 수 있다.

이미 있다면 공유할 수 있는 채널을 늘리는 것을 검토해 볼 수도 있다.( 기존의 카카오톡 뿐이였다면 인스타그램, 트위터 등으로 확장 설계 )

북극성 지표보다 훨씬 쉽게 매칭이 가능하다.

또한 협업에 있어 같은 방향을 보고 타팀과 생산적인 커뮤니케이션이 가능해 진다.

언제나 싸우는 기획팀과도 기획팀이 적용하고자 하는 기능이 어느 투입지표와 맞닿아 있는지 이해하고

그것에 대한 개발팀적인 고민과 우선순위를 말하며 대화한다면 의미없는 싸움이 되지 않을 것이다.

3. 북극성 지표를 대하는 개발자의 자세

개발자가 업무를 수행할 때 이 기능이 기술적으로 가능한지, 공수가 얼마나 드는지, 영향범위가 얼마인지

파악하는 것은 매우 중요하다.

하지만 이것만을 주장하며 개발팀만의 길을 걷는다면 제품이나 서비스, 크게는 회사 측면에서 바람직하지 않다.

이것은 개발팀만의 문제는 아니다.

모든 팀이 자신들의 목표를 가지고 있고 존재의 이유가 있다.

이들이 모두 자신들의 입장만을 대변한다면 어떻게 될까?

제품이나 서비스가 산으로 가는건 시간문제이다.

북극성 지표는 아래 3가지 측면에서 이런 문제를 줄여준다.

- 바라보는 방향성 : 북극성 지표는 이름 그대로 길을 찾을 때 방향을 알려주는 북극성과 같은 것이다.

회사 전체가 동일한 방향을 볼 수 있고 궁극적으로 모든 사람이 동일한 목표를 가지고 일할 수 있게 해준다.

- 명확성 : 모든 사람들이 제품이나 서비스가 잘 나아가고 있는지 한 눈에 확인이 가능하다.

- 고객 중심 : 구성원 간의 이득이 아닌 실제 서비스나 제품을 사용하는 고객의 관점에서 성장을 체크할 수 있다.

따라서 개발자도 해당 지표에 대한 이해가 필요하다.

지표가 만들어질 때부터 참여하여 적극적인 기술적 관점의 의견을 내는 것이 매우 중요하다.

이미 만들어진 지표도 큰 의미의 방향성을 제시해 준다는 점에서 좀 더 비즈니스에 가까운 개발 업무를 수행할 수 있을 것이다.

4. 북극성 지표에 대한 참고 자료

좋은 북극성 지표를 위한 8단계 체크리스트

출처 : https://growwithward.com/north-star-metric/

Amplitude가 만든 제품의 3가지 비즈니스 형태

출처 : https://amplitude.com/blog/product-north-star-metric

GA 스크립트나 GTM 스니펫 없이 데이터를 전송할 수 있다?Measurement Protocol

B급 코딩 — Fri, 24 Dec 2021 01:34:48 +0900

구글의 Measurement Protocol Image

보통 Google Analytics(GA)로 데이터 수집을 한다면

사이트에 GA 스크립트(analytics.js) GTM 스니펫 코드를 활용하여 사용자의 행동데이터를 수집하는 것이 일반적이다.

하지만 사용자들의 환경은 시시각각 다양해지고 있다

실제로 고객의 요구에 따라 웹사이트를 폐쇠망에서 운영하거나 키오스크 같은 웹이 아닌 환경을 만들 수도 있다.

이런 경우에는 GA를 포기해야하는 것인가? 그렇지 않다.

GA 스크립트, GTM 스니펫 코드 없이도 각 채널에서 사용자의 행동 데이터를 수집할 수 있다.

바로 그 주인공이 Measurement Protocol이다.

1. Measurement Protocol이란?

구글은 공식적으로 이 Measurement Protocol을 지원하고 있다.

https://developers.google.com/analytics/devguides/collection/protocol/v1

Measurement Protocol Overview | Analytics Measurement Protocol | Google Developers

Send raw user interaction data to Google Analytics using HTTP requests.

developers.google.com

Measurement Protocol은 사실 계속해서 우리도 모르게 이루어 지고 있었다.

GA로 데이터 수집을 하는 한 사이트에서 브라우저 개발자 도구로 Network 탭을 살펴보면 아래와 같다.

한 사이트에서 보여지는 GA 전송 프로토콜의 일부

우리가 정의한 트리거로 발생한 이벤트들이

최종적으로 www.google-analytics.com으로 뒤에 파라미들이 붙어서 GET방식으로 통신이 이뤄진다는 것을 알 수 있다.

감이 오는가?

그렇다. 우리는 코드로 http통신 모듈을 사용할 수 있고, 뒤에 파라미터를 어떤 키와 값으로 보내는지 알면

굳이 GA스크립트나 GTM을 활용해 GA를 설치할 필요가 없는 것이다!

왜 편한 방법을 두고 코딩을하는 어려운 방식으로 가냐고 반문할 수 있다.

하지만 Measurement Protocol을 활용한다면 여러 곳에서 GA를 설치하여 사용할 수 있게 된다.

2. Measurement Protocol은 어떻게 활용되는가?

1) 폐쇠망에서의 활용

www.google-analytics.com으로 가는 방화벽이 막혀있는 곳에서도 GA를 활용할 수 있게 된다.

웹서버에서 프록시 기능을 활용하는 것이다.

우리가 운영하는 사이트 주소가 aaa.com이라면 폐쇠망 환경에서 aaa.com으로 가는 방화벽은 열려있을 것이다.

GA로 보내는 이벤트 정보를 aaa.com/collect?v= 으로 뒤 파라미터만 세팅하여 aaa.com도메인으로 보낸다.

그럼 해당 요청을 받은 웹서버에서 collect?로 들어오는 요청을 앞에 도메인만 www.google-analytics.com으로 바꿔서

구글 쪽으로 보내는 것이다.

해당 방식으로 폐쇠망 뿐만아니라 브라우저 정책 등으로 행동데이터 수집을 차단해 놓은 곳에서도

해당 방식을 활용하여 GA로 데이터 수집이 가능한 것이다.

2) 웹이 아닌 환경

만약 수집해야 할 데이터가 클라이언트 단로는 내려오지 않고

외부시스템과 처리 후 DB에만 저장되어 백엔드에만 있는 정보라면 수집을 포기해야 할까?

역시 Measurement Protocol을 활용할 수 있다.

백엔드를 구성하고 있는 프레임워크에서 http통신 모듈을 활용하여 www.google-analytics.com으로 해당 데이터를

파라미터로 붙여서 보내면 되는 것이다.

3) 성능을 위해

클라이언트 환경이 IPTV나 VDI 위에서만 돌아가는 열악한 환경이라면 역시 Measurement Protocol을 활용할 수 있다.

GA스크립트나 GTM은 통신을 위해 한단계를 더 거처 직접 통신을 하는 것보다 성능이 떨어질 수 밖에 없다.

간단하고 성능 좋은 코드를 작성하여 GA로 보내는 Measurement Protocol을 코드화 하는 것이 열악한 클라이언트에서는

효율적인 행동데이터 수집 방법이 될 수 있다.

3. 그래서 어떻게 쓰는건데?

이제 www.google-analytics.com/collect? 뒤에 붙을 파라미터들만 알면 Measurement Protocol을 활용할 수 있을 것이다.

이 파라미터들은 key와 value 쌍으로 표현되고 있다.

당연히 GET방식으로 이어져있어 &로 이어진다.

GA스크립트나 GTM을 통해 보냈던 데이터들이 Measurement Protocol의 key-value쌍으로 변하면 어떻게 되는지

아래 링크를 보면 잘 나와있다.

https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters?hl=en

Measurement Protocol Parameter Reference | Analytics Measurement Protocol | Google Developers

Measurement Protocol Parameter Reference This document lists all of the parameters for the Measurement Protocol. General Required for all hit types. The Protocol version. The current value is '1'. This will only change when there are changes made that are

developers.google.com

몇가지만 예를 들어보겠다.

아래가 파라미터들에 대한 예시이다.

v는 버전을 의미하며 거의 1로 정해진다.

tid는 GA계정을 만들고 속성을 만들면 나오는 트레킹 아이디이다.

cid는 쿠키를 통해 수집하는 ga의 사용자 구분값이다.

t는 GA의 수집형태로 예시에 나와있는 것처럼 pageview가 될 수도 있고 event나 social등이 될 수 있다.

이렇듯 Measurement Protocol은 필요한 GA의 데이터를 파라미터화해서 URL에 붙여 보내면 된다.

나머지 파라미터들은 위 링크를 참고하기 바란다.

4. 마무리

지금까지 Measurement Protocol에 대해 알아보았다.

Measurement Protocol은 활용할 수 있는 방법은 무궁무진하다.

자신들이 관리하는 서비스를 보면서 이것을 활용해 데이터를 수집할 수 있는 눈이 떠질 것이다.

이는 GA만 해당하는 것이 아니다.

adobe를 비롯해 지금 나오고 있는 행동데이터 수집 솔루션들이 각자 다른 이름으로 Measurement Protocol을 제공한다.

server-to-server 등이 결국은 GA의 Measurement Protocol과 비슷한 방식이다.

따라서 Measurement Protocol을 제대로 익혀두면 데이터 수집에 큰 도움이 될 것이다.

[React] 상대경로 지옥에서 벗어나기 (craco)

B급 코딩 — Mon, 14 Jun 2021 00:52:48 +0900

개요

React는 기존의 Vanilla JS( 프레임워크를 쓰지 않은 순수 JavaScript )나 Jquery 사용시

불편했던 개발자의 욕구를 충분히 충족시켜주며 성장을 계속하고 있다.

하지만 인간은 편안함에 금방 익숙해지고 새로운 불편함을 또 찾고 그것을 고쳐내려 한다.

오늘은 React에서 개발한 프론트엔드 프로젝트 규모가 방대해져 import 해야 할 대상을 상대경로로

../을 무한 반복하여 찾는 불편함을 해소할 craco에 대해 알아보고자 한다.

상대경로 지옥

- 페이지 컴포넌트 import

보통 App.js나 App.ts에 각 url에 따라 이동할 페이지 컴포넌트들을 정의 한다.

스타일에 따라 layout으로 분리하거나 몇개로 쪼개서 관리할 수 있겠지만

각 url에 맞는 페이지 컴포넌트들을 임포트 해줘야 하는 일은 피할 수 없다.

../../pages/user/Login
../../pages/user/Logout
../../pages/user/Setting
../../pages/main/Main

똑같이 반복되는 ../../을 얼마나 더 쳐야하는 것인가?

- action들, reduer들, store들?

redux를 사용한다면 해당 action, reduer, store들을 사용하는 곳에서 모두 import해야하는 것도 피할 수가 없다.

역시다 ../../../ 이라는 쩜의 지옥에서 헤매이는 우리자신을 볼 수있다.

절대경로로 관리 할 수는 없는 것인가?

이렇게 쩜의 지옥에서 우리는 벗어날 수 없는 것인가? 그냥 page는 페이지대로, redux모듈들은 리덕스 모듈 대로,

그 외 서버를 호출하는 api들이 모여있는 service는 서비스대로, data의 타입을 위해 만든 model모듈은 모델 모듈 대로

그렇게 절대경로로 지정하여 사용할 수 는 없는 것인가?

없다면 이 글을 시작도 안했겠지만...

Craco를 활용한 절대경로 설정

먼저 잘 안하는 방법부터 소개한다. 관심이 없다면 이 부분은 넘어가도 좋다.

eject 명령어를 사용해서 webpack config를 직접 수정하는 방법이다. 하지만 한번 eject를 수행하게 되면 이전의

개발환경으로 돌아갈 수 없게 된다. 때문에 특별한 사유가 아닌 이상 eject는 하지 않는 것을 권장한다.

이제부터가 찐이다.

craco라는 모듈을 사용하는 쉬운 방법을 소개한다.

gsoft-inc/craco

Create React App Configuration Override, an easy and comprehensible configuration layer for create-react-app - gsoft-inc/craco

github.com

Create React App Configuration Override의 약자라고 한다. 중요하지 않다.

우리를 쩜의 지옥에서 벗어나게 해주는 방법이 중요하다.

그 외 자세한 사용법은 github를 참고 하시길.

01. 설치

npm, yarn, typescript 등 자신의 프로젝트 상황에 맞춘 설치를 진행한다.

npm i --save craco-alias @craco/craco


yarn add craco-alias @craco/craco

02. package.json 변경

기존 파일

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "stop": "taskkill -F -IM node.exe"
  },

변경 후

  "scripts": {
    "start": "craco start",
    "build": "craco build",
    "test": "craco test"
  },

위와 같이 수정하여 craco로 프로젝트가 실행될 수 있도록 한다.

03. croco config 추가

프로젝트 root 경로에 craco.config.js 파일을 신규로 생성한다.

그리고 아래와 같이 작성한다.

const CracoAlias = require("craco-alias");

module.exports = {
  plugins: [
    {
        plugin:CracoAlias,
        options:{
            source : "tsconfig",
            tsConfigPath : "tsconfig.paths.json",
        }
    }
  ]
};

craco를 사용하기 위한 설정 파일이라 생각하면 된다.

04. tsconfig.json 수정

tsconfig에 다음과 같은 사항을 추가한다.

{
  // 추가 부분 시작
  "extends": "./tsconfig.paths.json",
  // 추가 부분 끝
  "compilerOptions": {
    ·······(생략)
  },
  "include": [
    "src"
  ]
}

tsconfig.json에서 모두 관리 할 수도 있지만 가독성과 유지보수성을 위해 따로 파일을 만들어 관리한다.

05. alias 추가

이제 다 왔다.

위에 "./tsconfig.paths.json" 없는 파일을 extends 시켰으니 이 파일을 만들어 줘야한다.

역시 프로젝트 root 경로에 tsconfig.paths.json를 생성하고 paths 설정을 프로젝트에 맞게 한다.

{
    "compilerOptions": {
        "baseUrl": "./",
        "paths": { // 아래 부분들을 자유롭게 추가 수정하여 자신만의 절대경로 생성 가능
            "@images/*":["src/images/*"],
            "@action/*":["src/_actions/*"],
            "@reducer/*":["src/_reducers/*"],
            "@store/*":["src/_store/*"],
            "@model/*":["src/model/*"],
            "@page/*":["src/page/*"]
        }
    }
}

06. 사용방법

import React from 'react';
import { BrowserRouter as Router, Switch, Route } from "react-router-dom";
import { createMuiTheme, ThemeProvider } from '@material-ui/core/styles';

//App.js의 router에서 페이지 컴포넌트 import시 쩜의 지옥에서 벋어난 것을 확인가능
import ProjectList from '@page/main/ProjectList';   


const theme = createMuiTheme({
  palette: {
    primary: {
      main: '#212121',
    },
    secondary: {
      main: '#f44336',
    },
  },
});

function App() {
  return (
    <>
    <ThemeProvider theme={theme}>
    <Router>
    
            <Switch>
          <Route exact path="/">
            <ProjectList/>
          </Route>
        </Switch>
        </Router>
        </ThemeProvider>
    </>
  );
}

export default App;

지금까지 craco를 활용한 상대경로 .. 쩜의 지옥에서 벗어나는 방법에 대해 알아보았다.

create-react-app으로 프로젝트를 만들어서 개발하는 경우가 많을텐데 그때 복잡한 webpack을 수정하지 않고

적용할 수 있는 좋은 방법이라 생각된다.

[React] 무작정 React 시작하기

B급 코딩 — Sat, 3 Apr 2021 20:19:32 +0900

React 설치

이 글에서는 무작정 리액트를 시작하는 법을 포스팅 하겠다.

윈도우라면 cmd창을, 맥이라면 터미널 앱을 연다

아래와 같이 설치를 진행한다.

npm install -g create-react-app
create-react-app my-app

cd my-app
npm start

create-react-app 은 리엑트 프로젝를 만들기 위해

따로 설정해야할 기본 세팅을 자동으로 해주는 세트아이템 정도로 생각하면 된다.

프로그래밍을 배우기 위해 컴퓨터를 사는데 메인보드, 그래픽카드, 램 등을 따로 사서 조립해도 되지만

편리함을 위해 조립 PC를 살 수도 있다.

create-react-app는 리액트를 하기위해 필요한 여러 라이브러리를 편리하게 세팅해주는

조립PC라고 생각하자.

npm start를 실행하면 아래와 같은 화면에 브라우저에 나온다.

자 이제 반은 끝났다.

필수 라이브러리 설치

리액트 어플리케이션을 만들때 필요한 라이브러리는 요구사항에 따라 많아질 수 있겠지만

몇가지 필수 라이브러리는 설치하고 개발을 시작하는 것이 좋다

1. react-router-dom

우리가 웹 어플리케이션을 만들게 되면 페이지가 하나인 어플리케이션을 만들지 않을 것이다.

여러 페이지를 만들고 그것이 유기적으로 왔다갔다 하는 어플리케이션을 구성할 확률이 높다.

그럴때 리액트 어플리케이션의 이동을 담당하게 될 라이브러리가 react-router-dom 이다

npm install react-router-dom

설치 후 소스에 라우팅 세팅을 해준다.

보통 page 소스를 다 모아두는 pages 폴더를 만들고 아래에 페이지 소스들을 만든다.

위처럼 구성한 이후 App.js로 들어가보자

import './App.css';
import { BrowserRouter as Router, Switch, Route } from "react-router-dom"; //router모듈 import
import Home from './pages/Home'            //만든 Home 페이지 소스 import

function App() {
  return (
<Router>    
	<Switch>
      <Route exact path="/" component={Home}/>   {/* 경로에 따른 페이지 구성 */}        
      {/* <Route path="/a" component={Home}/> */}
      {/* <Route path="/b" component={Home}/> */}
    </Switch>
</Router>
  );
}

export default App;

위와 같이 라우트 세팅을 해주면 된다.

이제 프로젝트에 필요한 페이지 소스를 pages 아래 만들면 '/이름' 형태로 만든 페이지의 주소를 정해주고

route에 추가해주면 된다.

2. axios

다음은 axios이다. 이것은 ajax 통신을 통해 서버의 데이터들을 받아오는 통신 모듈이다.

웹 어플리케이션 내부에서 모든 데이터를 가지고 기능을 수행하는 프로젝트는 아예 없을 것이다.

대부분 백엔드가 따로 있고 그곳에서 데이터를 받아서 페이지를 구성하는 방식으로

진행될 것이다.

그럴때 꼭 통신 모듈이 필요하기 때문에 axios를 설치해 준다.

npm install axios

pages 폴더 아래 통신 모듈을 관리할 service 폴더를 만들어 주고

BaseService.js 파일을 생성해 준다.

여기에 기본적으로 필요한 통신 모듈을 정의해 둘 것이다.

import axios from "axios";

export default class BaseService {

  static getInstance() {
    if (!BaseService.instance) {
      BaseService.instance = new BaseService();
    }
    return BaseService.instance;
  }
  config={
    method: '',
    url: '',
    headers: {'Content-Type':'application/json'},
    data: {}
  }

  async fnRest(method, url, requestBody){
    
    this.config.method = method    
    
    this.config.url = 'https://exampleURL.com/' + url      //뒤에 붙여서 필요한 호출

    this.config.data = requestBody
    try {
      console.log("axios request url : " + url + ", requestBody : " + requestBody)
      const response = await axios.request(this.config)
      console.log(response)
      if (response.status === 200) {
        return response.data
      } else {
        const noResponseError = {
          successOrNot: 'N',
          statusCode: 'NO.RESPONSE',
          data: {}
        }
        throw noResponseError
      }
    } catch (errorResponse) {
      if (errorResponse && (errorResponse).error) {
        const errors = {
          successOrNot: 'N',
          statusCode: 'ERROR.RESPONSE',
          data: errorResponse.data
        }
        throw errors
      } else {
        const unknownError= {
          successOrNot: 'N',
          statusCode: 'UNKNOWN.SERVER',
          data: {}
        }
        throw unknownError
      }
    }
  }


}

위와 같이 통신 모듈을 정의해 둔다. 기본적인 에러처리와 해더 세팅, POST인지 GET인지 등을 구분하는

메소드 세팅 등을 기본적으로 해준다.

그리고 통신이 필요한 순간 이 클레스의 인스턴스를 가져와 호출에 사용하도록 한다.

3. Material-UI

다음은 Material-UI 다. 이것은 자주 쓰이는 html 화면 및 그에 맞는 기능을 만들어 놓은

라이브러리이다.

체크박스를 만들려면 input 태그를 시작으로 타입을 체크박스로 두고 이것을 체크했을때의 이벤트 등을

새로 정의해야한다. 또한 스타일도 CSS를 활용해 체크가 됬을때와 안됬을때를 나눠 적용해야한다.

Material-UI를 쓰면 이 작업이 반 이상 줄어든다.

설치해 두고

npm install @material-ui/core

npm install @material-ui/icons

아래 공식문서를 보면서 필요한 화면과 기능을 가져다 쓰면 된다.

Installation - Material-UI

Install Material-UI, the world's most popular React UI framework.

material-ui.com

이렇게 무작정 시작하는 리액트 환경 구성을 해보았다.

다음 포스트 부터는 화면들을 하나씩 만들어 보며

리액트의 감을 익혀보겠다.

[React Native] React만 알고 React Native를 배울때 꼭 알아야할 3가지

B급 코딩 — Sun, 14 Feb 2021 21:04:58 +0900

JavaScript와 TypeScript가 인기 언어로 급부상하면서 자바스크립트 라이브러리들이 다양하게 출시되었고

그 중 2021년 현재 왕좌를 차지하고 있는 녀석은 React 이다.

그래서 Web에서 React를 많이 쓰고 배워서 모바일 개발을 위해 React Native(이하 RN)을 배우고 싶어하는

개발자들이 많을 것으로 생각된다.

React Native는 React와 문법이 매우 흡사하다.

또한 앱에 대한 전반적인 관리를 expo라는 뛰어난 관리 체계가 대신해줌으로써

React를 안다면 RN에 충분히 도전할 수 있다.

그래도 React와 RN은 다른 기기에서 구동되기 위해 다르게 만들어진 라이브러리이다.

React만 알고 RN에 도전할 때 주의해야할 3가지 사항을 알아두고 도전한다면 더 배움이 수월할 것이다.

1. 웹 컴포넌트들은 앱의 사망을 부른다.

말 그대로이다.

RN은 모바일에서 구동되기 위한 앱을 만드는 라이브러리로 웹에서 쓰는 컴포넌트들을 가져다가 쓰면

빌드때는 아무런 문제가 없다가 런타임때 앱이 사망하여 꺼지게 된다.

위 코드처럼 RN코드에 html 태그인 <div></div>를 넣어도 빨간 줄이 가지 않는다.

이렇게 expo의 Run in web browser에서 구동해도 에러가 나지 않는다.

당연히 웹 브라우저에서 돌아가는 태그이기 때문이다.

하지만 이것을 앱에서 구동하는 순간

위와 같은 에러를 마주하게 된다.

사실 자신이 조심해서 웹 컴포넌트들을 배제하고 RN 개발을 한다면 나오지 않을 에러지만

서드파티를 도입할 때 주의해야 한다.

해당 서드파티 라이브러리가 RN만을 위한 것인지, 웹 컴포넌트들을 써서

해당 Exception을 일으키지 않을지 잘 따져보고 도입해야 한다.

2. 웹개발에 사용되는 API라고 해서 RN에서 모두 사용할 수 있는 것은 아니다.

필자는 웹사이트에서 쓰이는 REST 통신 API를 이용하여 앱을 만들고 있었다.

Web에서는 https://www.example.com:9090/getUser 라는 API를 통해 통신하고 있었고 문제가 없었다.

하지만 RN에서 호출하면 계속해서 Network Error가 발생하였다.

해당 API 서버는 노드서버에 ssl 인증서를 포함해서 https 통신으로 전송되고 있던 API였다.

이를 해결하기 위해 웹서버인 아파치에 proxy를 걸어서 노드 서버로 리다이렉트 되도록하여 해결했다.

이 역시 expo의 Run in web browser에서 구동해도 나오지 않는 에러이다.

RN을 개발할 때는 에뮬레이터나 실제 모바일 기기로 개발 결과를 보면서 개발하는것이 필수적이다.

3. 네이게이션 설계를 거의 완벽하게 하고 개발에 도입하는 것이 좋다.

RN에서 제일 많이 쓰이는 네이게이션을 위한 서드파티는 react navigation이다.

[React Native] ② Navigation 설정 및 프로젝트 구조 잡기

React Navigation React Native(이하 RN)에서 네비게이션을 구현하는데 사용되는 많은 라이브러리들이 존재한다. 그 중 대표적인 것이 React Navigation이다. 난 이것을 사용해 지난 포스팅에 생성한 RN 프로젝

bgradecoding.tistory.com

이것을 설정할때 미리 앱에 사용될 화면을 설계하고 그 화면이 어떤 navigation을 가질지

예상한 다음 개발을 시작하는 것이 좋다.

아니면 나중에 개발을 진행하다가 프로젝트 구조를 다시 뜯어고쳐야하는 경우가 많이 생긴다.

예를 들어 앱의 메인화면에는 Tab 네비게이션과 drawer 네비게이션이 혼재하면서

상세화면은 stack만 나오는 화면일 경우 메인화면, 상세화면을 stack으로 먼저 적용하고

tab, drawer를 적용하려면 매우 힘들어 진다.

일단 drawer를 먼저 적용하고 그 안에 메인 네비게이션 컴포넌트를 stack으로 짜고

다시 그 위에 tab 네비게이션을 적용하는게 베스트이다.

자세한 내용은 아래 공식 문서에서 확인할 수 있다.

Nesting navigators | React Navigation

Nesting navigators means rendering a navigator inside a screen of another navigator, for example:

reactnavigation.org

TypeScript로 Stack 구현하기 (feat. 배열Array 사용하지 않기)

B급 코딩 — Sun, 24 Jan 2021 01:56:01 +0900

TypeScript를 사용하여 Stack을 구현해 보겠다. 배열(Array) 타입을 쓰면 너무 쉬우니 배열을 쓰지 않고 해보자.

Stack(이하 스택)이 무엇인지는 위키에 잘 나와있다.

스택 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 스택(stack)은 제한적으로 접근할 수 있는 나열 구조이다. 그 접근 방법은 언제나 목록의 끝에서만 일어난다. 끝먼저내기 목록(Pushdown list)이라고도 한다. 스택은

ko.wikipedia.org

기본 설계

일단 스택이라는 클레스에는 많은 것이 필요할 수 있겠지만 기본적으로 3가지가 필요하다

size    //지금 스택에 얼마나 많은 value들이 있는지 알려주는 변수

push(string):void    // string 값 하나를 스택에 넣는 함수

pop():string         // 스택의 젤 위에 있는 값을 리턴하는 함수

이 포스팅에서는 위 3가지를 스택에 구현해 보겠다.

또한 스택에 넣을 수 있는 데이터 타입도 string으로 제한하겠다.

key Point

스택을 구현함에 있어 다른 언어도 마찬가지겠지만 push로 들어오는 값들을 잘 쌓고, pop으로 나갈때 그것을 다시 정렬해서 메모리에 가지고 있는 것이 중요하다.

이러한 방식을 생각하는 것이 중요하다.

담아둘 객체 OneStack을 value와 below라는 값을 가진 Type으로 만들어 주고

이 below에 다시 자기 자신 객체Type(OneStack)을 넣는 것이다.

감이 오는가?

꼬리 물기 라고 생각하면 된다.

이제 다음 value가 push되어 들어오면 지금 메모리에 올라가 있는 개체를 그대로 below로 보내고

새로들어온 값을 value에 저장하면 되는것이다.

pop을 하게 되면 지금 있는 객체의 value값을 리턴하고 below에 있는 객체를 지금 객체로 가져오면 되는 것이다.

구현

key Point를 바탕으로 구현해보자

//객체 지향 설계에 맞게 stack을 디커플링하게 쓰기 위해서 interface를 정의한다.

interface Stack {

  size(): number;
  
  push(value: string): void;
  
  pop(): string;
  
}


/**
* 그리고 꼬리 물기를 할 OneNode 타입을 선언해 준다.
* below를 보면 자기 자신을 Type으로 갖는 걸 볼 수 있다.
*/

type OneNode = {

  value: string;
  
  below: OneNode | null;
  
}


//실제 수행될 메소드들이 정의된 DoStack class를 정의한다.
//생성자와 실제 데이터들이 올라갈 top이란 변수를 위에 만든 OneNode 타입으로 만들어 준다.

class DoStack{

  private top: OneNode;
  
  constructor() {
    this.top = null;
  }
	//구현
    
}

이후 Dostack 클레스 안에 들어갈 push 메소드를 구현해 보자.

  push(valueString: string) {
  
  //top에 들어오는 값이 처음인지를 판단해 준다.
  //처음이라면 들어온 값을 그대로 value에 담아주면 된다.
  
    if (this.top === null) {
      const node: OneNode = {
        value: valueString,
        below: null,
      };
      this.top = node;
 
 //만약 들어온 값이 처음이 아니라면
 //지금의 객체를 below로 보내고 들어온 값을 value에 세팅하면 된다.
    } else {
      this.top.below = {
        ...this.top,
      };
      this.top.value = valueString;
    }
  }

이제 pop 메소드를 구현해 보자

  pop(): string {
  
  	//값이 없을때는 Error를 발생시켜 준다.
    if (this.top === null) {
      throw new Error("Not Exist value");
    }

//값이 2개 이상 있을때 현재 value 값을 리턴해주고
//top객체에 below를 세팅하면 된다.
    if (this.top && this.top.below !== null) {
      const returnValue: string = this.top.value;

      this.top = this.top.below;

      return returnValue;
      
      
//값이 1개 이면 현재 value를 리턴하고 top을 null로 만들어 준다.      
    } else {
      const returnValue: string = this.top.value;

      this.top = null;

      return returnValue;
    }
  }

마지막으로 size 함수를 구현해 보자.

 
 //지금 메모리에 있는 top객체를 복사하여 below를 계속 끌어올리면서 count를 올려주면 된다.
 
 size() {
    let size = 0;
    let cloneNode: OneNode = this.top;
    if (this.top) {
      while (cloneNode !== null) {
        size += 1;
        cloneNode = cloneNode.below;
      }
    }
    return size;
  }

모든 구현 사항을 모아 보면 아래와 같다.

interface Stack {
  size(): number;
  push(value: string): void;
  pop(): string;
}

type OneNode = {
  value: string;
  below: OneNode | null;
}

class DoStack implements Stack {

  private top: OneNode;
  constructor() {
    this.top = null;
  }

  size() {
    let size = 0;
    let cloneNode: OneNode = this.top;
    if (this.top) {
      while (cloneNode !== null) {
        size += 1;
        cloneNode = cloneNode.below;
      }
    }
    return size;
  }

  push(valueString: string) {
    if (this.top === null) {
      const node: OneNode = {
        value: valueString,
        below: null,
      };
      this.top = node;
    } else {
      this.top.below = {
        ...this.top,
      };
      this.top.value = valueString;
    }
    console.log(this.top);
  }

  pop(): string {
    if (this.top === null) {
      throw new Error("Not Exist value");
    }

    if (this.top && this.top.below !== null) {
      const returnValue: string = this.top.value;

      this.top = this.top.below;

      return returnValue;
    } else {
      const returnValue: string = this.top.value;

      this.top = null;

      return returnValue;
    }
  }
}


// test Area

const stack: Stack = new DoStack();

stack.push("a");
stack.push("b");
stack.push("c");

console.log("size===============" + stack.size());

console.log(stack.pop());
console.log(stack.pop());
console.log(stack.pop());

테스트 결과를 실행해 보면

마지막에 넣은 C부터 차례대로 출력되고 size도 3개가 들어가 있을 때 3으로 출력되는걸 알 수 있다.

[React Native] ③ React-Native-Elements UI 기틀 및 테마 설정

B급 코딩 — Wed, 20 Jan 2021 17:54:57 +0900

지난 포스팅까지 해서 우리는 네비게이션까지 장착한 자동차를 얻은 것이다.

[React Native] ② Navigation 설정 및 프로젝트 구조 잡기

bgradecoding.tistory.com

이제 차의 겉면을 장식할 차례이다. 디자인도 예쁘게 뽑고 썬텐도 해야한다.

그것을 도와줄 친구가 바로 React Native Elements 이다.

React Native Elements | React Native Elements

Cross Platform React Native UI Toolkit

reactnativeelements.com

React Native(이하 RN)을 위한 UI 라이브러리는 여러가지가 있다.

그중 2020년을 기준으로 많이 사용된 순을 확인해보면 아래와 같다.

1. React Native Elements : Github Stars: 19,500

2. Material Kit : GithubStars: 4,700

3. React Native Base : GithubStars: 14,300

4. Vector Icons : GithubStars: 14,000

5. React Native Paper : GithubStars: 6,600

6. Gifted Chat : GithubStars: 9,800

7. Ignite CLI : GithubStars: 6,600

8. React Native Material UI : GithubStars: 3,600

9. React Native Maps : GithubStars: 11,500

10. Lottie : GithubStars: 13,400

10. Teaset : GithubStars: 2,500

출처

11 Top React Native Component libraries to Use in 2020

React Native was released in 2015 by Facebook, allowing developers to use React JS with native platfo...

dev.to

순위가 이렇고 Document도 깔끔하고 많이 쓰이는 React-Native-Elements를 사용해서 프로젝트의 디자인 구성을 잡아 보도록 하겠다.

설치

일단 React-Native-Elements를 설치하자

yarn add react-native-elements

# or with npm

npm install react-native-elements

yarn을 사용한다면 위 명령어를 사용하고 그게 아니라면 npm으로 설치하면 된다.

이제 React-Native-Elements를 적용해 보자

프로젝트 구조 잡기

우리가 앱을 만들때 버튼이 필요하거나 이미지가 필요하거나 기타 UI적인 요소들이 필요할 때 마다

React-Native-Elements의 component를 가져다가 개발하면 된다.

초기에 세팅해야할 것은 테마이다.

테마는 기본적으로 프로젝트에서 제일 많이 쓸 색이나 폰트 기본적인 UI component 디자인 등을 전역으로 해두고

디자인을 빠르게 적용할 수 있다.

일단 프로젝트의 App.tsx를 열어 보자

import React from "react";
import { NavigationContainer } from "@react-navigation/native";
import { createStackNavigator } from "@react-navigation/stack";
import * as pages from "./src";
import { ThemeProvider } from "react-native-elements";
import { mainTheme } from "./src/resource/style/MainTheme";

const Stack = createStackNavigator();

function App() {

  return (
  
    <ThemeProvider theme={mainTheme}>
    
      <NavigationContainer>
      
        <Stack.Navigator initialRouteName="Landing">
        
          <Stack.Screen
            name="Landing"
            component={pages.Landing}
            options={{ headerShown: false }}
          />
          
          <Stack.Screen
            name="Login"
            component={pages.Login}
            options={{ headerShown: false }}
          />
          
        </Stack.Navigator>
        
      </NavigationContainer>
      
    </ThemeProvider>
    
  );
  
}

export default App;

ThemeProvider를 import한다.

그런 다음 아래와 같이 프로젝트 구조에 style 폴더를 따로 만들 것이다.

그 밑에 MainTheme.ts 파일을 만든다.

export const mainTheme = {
    colors: {
      primary: 'rgba(45, 185, 176,1)',
      secondary:'white'
    },
    Text: {
      style: {
        fontStyle: "italic",
      }
    }
  };

그 후 자신이 프로젝트에서 주로 사용할 디자인들에 대한 정의를 해두면 된다.

일단 colors에 primary를 지정해 주면 해당 component에 직접 css를 가하지 않는 이상 primary 색으로 나타난다.

secondary는 그 다음으로 많이 사용할 색을 지정해두어 변수로 secondary만 넘겨주면 자동으로

secondary 색으로 변한다.

Text의 폰트로 무료 폰트들을 다운로드 받아서 resource 폴더에 옮겨두고 그 경로를 fontStyle로 지정해 두면 된다.

기본 내장된 폰트를 쓸 경우에는 위 코드처럼 italic 등을 지정해 두면 자동으로 그 폰트를 사용하게 된다.

이것을 위의 App.tsx에서 전역으로 <ThemeProvider theme={mainTheme}> 감싸두었기 때문에 기본적인 디자인은

자동으로 적용되는 것이다.

이렇게 해서 프로젝트의 베이스가 될 구조를 잡아 보았다.

이제 앱을 만들때 많이 쓸만한 화면 구조등을 모듈화 해서 적용해 놓고

몇개의 props만 바꾸면 적용 될 수 있도록 개발해 보겠다.

[React Native] ② Navigation 설정 및 프로젝트 구조 잡기

B급 코딩 — Wed, 20 Jan 2021 00:13:00 +0900

React Navigation

React Native(이하 RN)에서 네비게이션을 구현하는데 사용되는 많은 라이브러리들이 존재한다.

그 중 대표적인 것이 React Navigation이다.

난 이것을 사용해 지난 포스팅에 생성한 RN 프로젝트에 적용할 것이다.

[React Native] React Native 설치 (feat. expo)

개요 핸드폰으로 사용하는 어플리케이션은 개발적인 측면에서 3가지로 나눌 수 있다. Native App, hybrid App, Web App이 그것이다. 성능적인 측면에서는 Native App을 따라올 것이 없다. 하지만 각 OS에 맞

bgradecoding.tistory.com

React Navigation은 무려 공식 문서도 제공한다.

React Navigation | React Navigation

Routing and navigation for your React Native apps

reactnavigation.org

이제 React Navigation를 적용해보자

일단 패키지를 설치한다.

npm install @react-navigation/native

npm install @react-navigation/stack

이제 이 네비게이션을 바탕으로 App.tsx를 수정해 보자

import React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createStackNavigator } from '@react-navigation/stack';
import * as pages from './src'

const Stack = createStackNavigator();

function App() {
  return (
    <NavigationContainer initialRouteName="Landing">
      <Stack.Navigator>
        <Stack.Screen name="Landing" component={pages.Landing} options={{ headerShown:false }} />
        <Stack.Screen name="Login" component={pages.Login} options={{ headerShown:false }}/>
      </Stack.Navigator>
    </NavigationContainer>
  );
}

export default App;

위와 같이 앱의 새로운 화면이 생길때마다 그 화면으로 갈수 있는 네비게이션을 등록하고 화면을 개발할 것이다.

options={{ headerShown:false }} 이것은 Navigator를 사용하면 디폴트로 나오는 위 네비게이션 해더를 없애는 옵션이다.

매우 촌스럽게 생기고 요즘 앱에 많이 없는 것이 빼주도록 하겠다.

initialRouteName="Landing"은 앱이 처음 실행될때 첫 화면으로 무엇을 할지를 설정해 주는 옵션이다.

import * as pages from './src' 이 import문으로 인해 src밑에 있는 페이지들을 모두 한번에 가져오는 구조가 가능하다.

일단 src를 만들고 각 기능별로 폴더 구조를 나눠봤다. 지금은 편의상 로그인과 비즈 폴더만 만들었다.

그리고 src 밑에 index.ts 파일을 만들고

import Landing from './login/Landing'

import Login from './login/Login'


export{

    Landing,
    
    Login
    
}

src 밑에 오는 페이지들을 export 해줬다.

이것으로 기본적인 네비게이션 구조와 프로젝트 구조를 잡았다.

이를 바탕으로 앱 만들때 기본 프로젝트로 바로 시작할 수 있는 base App을 계속 완성해 볼 생각이다.

다음 포스팅때는 디자인 요소를 책임질 React Native UI Library를 설치하고 기본적인 디자인 구조를 잡아보겠다.

[React Native] ① React Native 설치 (feat. expo)

B급 코딩 — Tue, 19 Jan 2021 20:37:53 +0900

개요

핸드폰으로 사용하는 어플리케이션은 개발적인 측면에서 3가지로 나눌 수 있다.

Native App, hybrid App, Web App이 그것이다.

성능적인 측면에서는 Native App을 따라올 것이 없다. 하지만 각 OS에 맞는 언어를 배워야한다.

특히나 IOS는 집에 사과농장을 차리지 않아 익숙하지 않은 개발자라면 더더욱 고난이도의 앱 개발이 될 것이다.

그래서 나온 것이 hybrid App이다.

한가지 방법으로 두가지 OS를 모두 개발할 수 있는 플랫폼으로 개발한 앱을 말한다.

그 중 오늘 다뤄 볼 아이는 React Native(이하 RN)이다.

문법이 React와 매우 흡사하고 자바스크립트나 타입스크립트를 어느정도 아는 사람이라면 러닝커브가 그렇게

높지 않다.

Expo

RN을 말한다면서 갑자기 왠 Expo인가 싶을 것이다.

나같은 B급 개발자에게 무지하게 필요한 아이다.

React로 따지면 create-react-app과 같은 것이다. 복잡한 세팅을 한방에 해주는 고마운 아이다.

또한 개발에 있어 많은 편의성을 제공한다.

특히 IOS 앱을 한번이라도 빌드해본 사람이라면 그 거지같음을 잘 알고 있을 것이다.

인증서와 프로비저닝 세팅의 맛을....

Expo를 사용하면 핸드폰에 Expo앱을 깔고 바로 빌드해서 테스트를 해볼 수 있다.

무려 IOS도 말이다.

정말이지 엄청난 Tool이다.

- Expo 설치

npm install -g expo-cli

expo를 command로 실행할 수 있게 되었다.

이제 본격적으로 RN 앱을 만들어 보자

- 프로젝트 생성

expo init rnbase

위 명령어를 수행하면 Choose a template 라며 선택사항을 고르는게 나온다.

난 요즘 핫한 타입스크립트로 세팅하기 위해 blank (TypesScript)를 선택했다.

조금 기다리면 세팅이 완료된다.

VSCode로 프로젝트를 열어보면 위와 같은 구조가 나온다.

이제 앱이 잘 동작하는지 실행해보자

npm을 통해 실행하면 다음과 같은 명령들이 실행되고

브라우저에 해당 주소를 치면 위와 같이 개발 툴이 실행된다.

빨간 부분 중 원하는 것을 누르면 원하는 방법으로 앱을 실행해 볼 수 있다.

그리고 아래 QR을 Expo앱에서 찍으면 핸드폰에서 바로 디버깅이 가능하다.

여기서는 가볍게 확인을 위해 Run in Web browser를 눌러 브라우저에서 확인해 보겠다.

브라우저에서 개발자 모드 F12를 누르면 빨간색 부분처럼 버튼이 보일 것이다. 이것을 누르면

모바일 화면처럼 확인이 가능하다.

App.tsx 모듈을 열어 보자

export default function App() {
  return (
    <View style={styles.container}>
      <Text>Open up App.tsx to start working on your app!</Text>
      <StatusBar style="auto" />
    </View>
  );
}

이 부분에 <Text></Text> 태그 안의 글씨를 바꿔 보자

export default function App() {
  return (
    <View style={styles.container}>
      <Text>Hello React Native!</Text>
      <StatusBar style="auto" />
    </View>
  );
}

위와 같이 변경 사항이 바로 적용되는 것을 볼 수 있다.

다음 포스팅에서는 프로젝트 구조를 잡아보고 React에서도 중요한 페이지 이동에 쓰이는 Navigation 세팅을 해보겠다.

nest js란? 기초 설치, 설계, 특징

B급 코딩 — Sat, 16 Jan 2021 16:19:28 +0900

개요

Node js는 프론트에서 끄적이던 자바스크립트를 서버단으로 가져와 훌륭한 백엔드를 구성할 수

있도록 도와준 고마운 아이였다.

하지만 인간은 그것으로 끝나지 않고 끊임없이 Node js의 불편한 점들을 개선할 프레임워크들을 만들어 왔다.

그래서 Node js 계열에도 몇가지 웹 프레임워크가 생겨났다.

그 중 대가리를 뽑으라면 역시 Express 일 것이다.

하지만 Express도 프레임워크단에서 지원해 주는 기능이 매우 협소했다. 편리함을 추구하는 닝겐들에겐

그 next를 원하게 했다. 그래서 등장한 아이가 Nest JS 이다.

NestJS는 NodeJS 프레임워크인 Express나 Fastify 위에 올라타 해당 프레임워크의 기능도 쓸 수 있으면서

나름의 체계를 가지고 독자적인 프레임워크 규칙들을 제시한 훌륭한 웹 프레임워크다

Nest JS의 주요 특징

1. Typescript 활용 가능

그렇다. Nestjs는 기본적으로 Typescript를 지원한다.

무근본 자바스크립트에 근본을 담은 Typescript는 글을 쓰는 현 시점까지 매우 가파르게 성장 중이다.

이런 근본을 Express에 도입하려면 매우 복잡스런 과정들로 인해 개발자란 직업에 협오를 갖게 한다.

하지만 Nest JS는 기본이 근본인 것이다.

2. OOP, FP, FRP

OOP ( Object Oriented Programming )
FP ( Functional Programming )
FRP ( Functional Reactive Programming )

NestJS는 이 3가지를 모두 지원한다.

먼저 OOP. 가장 오래되고 프로그래밍에 기초적인 철학으로 많이 퍼져있는 객체지향 프로그래밍이다.

사실 OOP가 좋은 방식인지는 개인적으로 많은 의문을 가지고 있지만 수많은 엔터프라이즈 시스템들이 이 방식으로

소프트웨어를 생산하고 있으니 OOP인 곳에 NestJS를 도입해도 문제될 것은 없다.

다음으로 FP입니다.

wiki에 따르면

함수형 프로그래밍(functional programming)은 자료 처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나

라고 한다.

람다식의 개념을 생각하면 될것이다. 자바스크립트에서도 아래와 같은 문법이 많이 쓰이니 이것을 지원하는 것은

당연한 것이겠다.

sayHi = name => alert("Hi, " + name);
sayHi("B급 코딩");

다음으로 FRP이다.

간단하게 말하면 FP를 하던중 Async한 상황을 만나게 될때 프로그래밍 하는 기법이다.

이는 서버에서 데이터를 받아와서 다양한 화면구성을 만들때만 해도 꼭 필요한 방식이다.

따라서 NestJS는 이 모든 프로그래밍 철학을 잘 구현하도록 지원하고 있다.

머 요즘 프로그래밍 언어가 거의 다 제공하는 것이긴 하지만..

3. 협업에서의 체계성

웹 사이트를 만들때면 많은 개발자들이 협업을 해야하고 프로그래밍 특성상 개인의 성향이 매우 많이 표출되어

머지된 소스코드들은 이미 산으로 가기 마련이다.

이를 위해 Java는 Spring을 사용하여 최소한의 규칙들을 지키게 하였고,

Python의 Django도 마찬가지이다.

여기에 Node에는 NestJS가 있다고 해도 과언이 아니다

밑에서 보겠지만 Cli를 통해 생성되는 컨트롤러, 모듈, 서비스 등의 구조 기반으로 최소한의 규칙들을 정해둔 것이다.

코드의 일관성은 유지보수에 매우 중요한 요소이다.

자바스크립트로 백엔드를 구성한다면 반드시 고려해봄직 하다.

NestJS 설치

자 이제 설치해 보자.

매우 간단하다.

일단 Node JS가 설치되어 있어야 한다.

그리고 아래의 명령어를 수행한다.

npm i -g @nestjs/cli

이제 설치는 끝났다.

간단한 Cli 확인을 위해 nest를 커멘드 창에 쳐보자.

쭉 살펴보니 프로젝트를 만들려면 일단 application 생성을 해야할 것으로 보인다.

아래와 같이 application을 generate하는 명령을 수행한다.

nest g application

그러면 프로젝트의 이름을 물어온다. 이름을 대충 정해서 넣어보자.

그럼 위 구조를 가진 프로젝트가 생성된다.

이제 package.json을 확인해 보자.

만들어진 프로젝트 실행에 관련된 사항들이 scripts 안에 보일 것이다.

이제 프로젝트에 필요한 모듈들을 다운로드 하자

npm install을 실행해준다.

npm run start

그 다음 위 명령을 통해 만들어진 프로젝트를 확인해보자.

명령 수행 뒤 브라우져에 localhost:3000을 입력하면 nest가 우리를 반겨주는 것을 볼 수 있다.

다음 nest 시간에는 간단한 프로젝트 구조를 설명해 보고 DB연동을 통해 간단한 API를 만들어 보겠다.

② GA 설치시 개발자가 고려해야 할 사항 5가지

B급 코딩 — Sat, 9 Jan 2021 23:12:34 +0900

개요

지난번 포스팅 때 간단한 GA 설치법을 알아보았다.

① 구글 애널리틱스 기초 및 설치(feat. 개발자를 위한 GA)

1. 구글 애널리틱스(이하 GA)란? 요즘 GA는 여러곳에서 많이 들어봤을 것이다. 구글이 2005년 3월 웹분석 전문 업체인 어친 소프트웨어(Urchin Software)를 인수한 후 그해 11월 구글 애널리틱스 서비스를

bgradecoding.tistory.com

하지만 이것만으로는 사용자가 어느 페이지에 들어왔는지 정도만 알 수 있지 GA를 온전히 다 사용할 수 없다.

하나의 예시로 사용자가 특정 버튼을 얼마나 많이 클릭했는지만 알려고 해도 추가 코딩이 필요하다.

그래서 이번 포스팅에서는 GA 기본 설치 이후

추가적인 분석을 위해 필요한 개발 작업에서 꼭 알아둬야할 사항들을 준비했다.

1. SPA(single page architecture) 구조

GA 기본설치만으로도 사용자가 어느 페이지에 들어왔는지 정도는 알 수 있다고 언급했다.

하지만 이것은 GA를 설치하는 웹이 MPA(multi page architecture) 구조일때만 맞는 말이다.

SPA 구조일 경우 GA 기본 설치만으로는 최초 로딩된 페이지에만 사용자가 머무는 것으로 집계된다.

따라서 추가적인 조치가 필요한데 페이지가 로딩될 때 가상페이지뷰 형태를 GA에 전달해주는 코딩이 필요하다.

예시로 A사이트의 url이 a로 메인페이지에 들어갔을때 브라우저에 보이는 url이 a일 것이다.

하지만 A사이트의 로그인 페이지로 이동해도 SPA 구조에서는 브라우저의 url이 a로 바뀌지 않을 수 있다.

바뀌더라도 SPA 구조라면 GA는 이것을 하나의 페이지로 인식한다는 것이다.

이럴 때 A사이트에 메인페이지가 로딩 될때 이것을 메인페이지라고 알려주는 가상페이지뷰 데이터를 전달하고

로그인 페이지가 로딩 될때 이것을 로그인페이지라고 알려주는 가상페이지뷰 데이터를 전달하게 코딩해야 한다.

따라서 GA 설치에 SPA 구조는 더 많은 공수가 소요된다.

프로젝트를 수행할 때 반드시 고려해야할 요소이다.

특히나 React, Vue 등의 SPA를 위한 framework가 유행하는 요즘 가상페이지뷰 형태의 GA 설치는 필수일 것이다.

2. 크로스 도메인

하나의 웹 서비스에 도메인 두개가 같이 공존하는 경우가 있다.

차세대 프로젝트를 진행하다가 구버전을 꼭 써야하는 경우 iframe 형태로 구 기능을 이식한다던지의

이슈로 충분히 생길 수 있는 상황이다.

GA 기본 설치때 경험했듯이 GA는 URL 기반으로 데이터를 수집한다.

위 같은 상황에서는 두개의 도메인을 하나의 서비스로 인식하게 하는 작업이 필요하다.

혹은 하나의 웹서비스가 두개의 도메인으로 서버스 될때 하나의 GA로 모이게 하는 작업이 필요하다.

이는 GA의 설정을 통해 꼭 해결해야 하는 이슈이다.

3. 쿠키 (cookie)

GA 설치시 일용할 양식은 매우 중요.....

배고파서 나온 헛소리다...

wiki에 따르면

쿠키란 하이퍼 텍스트의 기록서의 일종으로서

인터넷 사용자가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를 통해

인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일을 일컫는다.

GA의 주요 지표 중 하나가 USER라는 지표이다.

이는 곧 사용자를 뜻한다. USER는 웹서비스를 사용하는 사용자의 브라우저에 쿠키를 기반으로 집계된다.

사용자가 GA가 설치된 웹사이트에 방문하면 GA는 브라우저 쿠키에 Client ID를 발급해 저장한다.

그래서 사용자가 여러 브라우저를 쓰거나, 브라우저 쿠키를 주기적으로 지운다면 GA는 다른 사용자로 인지하게 된다.

이 점을 충분히 마케터나 고객들에게 인지시켜야 한다.

4. GA 데이터 내부 DB 적재 가능 여부

결론부터 말하자면 가능하다.

GA의 데이터를 모아서 머신러닝의 데이터로 이용하거나 좀 더 심도있는 자체적 분석을 원하는 고객들이 있을 수 있다.

이때 GA 데이터를 끌어오길 원할 것이다.

이는 GA에서 API를 제공하고 있다.

따라서 스케줄러를 사용한 배치 형태로 구현할 수도 있고,

원할 때 구글 스프레드시트 형태로도 데이터를 긁어 올 수 있다.

5. 크롬 확장 프로그램 WASP

크롬 브라우저가 갑자기 ant-man과 wasp에 나오는 wasp 처럼 작아져서 GA에.....

헛소리다. 마블빠여서 WASP란 단어가 반가웠다...

크롬의 확장 프로그램 중 WASP라는 프로그램이 있다.

이것을 이용하면 GA 설치 이후 GA에 데이터가 잘 전달되고 있는지 확인할 수 있다.

개발 이후 테스팅을 통한 검증은 coding에서 매우 중요하다.

해당 프로그램을 잘 숙지해서 프로젝트시 데이터 전송 검증으로 사용하면 GA 설치가 더 수월해진다.

이상으로 GA 설치시 개발자가 알아야할 사항들에 대해 정리해 보았다.

해당 웹사이트의 비즈니스적인 요소로 GA 설치 고려사항은 마케터들이나 의사결정자들이 해야할 사항이다.

개발자들은 시스템의 구조와 GA 설치 가능여부,

마케터나 의사결정자들이 원하는 분석이 가능여부에 대한 고려를 시스템적으로 해야한다.

위 5가지 사항들을 먼저 살피면 GA 설치가 원활할 것이다.

[React]별점(Star Rating) 기능 구현 (React + Typescript)

B급 코딩 — Fri, 8 Jan 2021 02:11:07 +0900

개요

별점을 주는 기능은 매우 흔하게 쓰이는 컴포넌트지만 구현하기는 꽤 까다로운 기능이다.

마우스를 별에 가져가면 별점이 자동으로 올라가게 만들거나, 클릭을 통해 별점을 지정하는 등 다양하게 만들 수 있다.

React에는 react-star-rating-component

react-star-rating-component

React component for star (or any other icon based) ratings

www.npmjs.com

위와 같은 라이브러리가 있다.

하지만 Typescript를 지원하지 않아서 React + Typescript 프로젝트를 진행하거나 간단한 구현을 원한다면 이 포스팅을 참고 하시길 바란다.

Html 요소

별점을 나타내는 html 요소에는 많은 방법이 있다. 실제 이미지를 만들어서 사용해도 되고 svg를 활용해도 된다.

필자는 간단한 기능 구현을 위해 <i>태그를 활용하겠다.

<i className='item-rating pointer zmdi zmdi-star'>  <!-- 채워진 별 -->

<i className='item-rating pointer zmdi zmdi-star-outline'>  <!-- 빈 별 -->

동작 원리

필요한 화면 요소를 구했으니 이제 이것을 동적으로 잘 바꾸기만 하면 된다.

마우스 오버나 클릭시에 html의 className을 변하게 하면 되는 것이다.

그러기 위해서는 className을 State로 관리하는 것이 좋아 보인다.

별점의 만점을 몇 점으로 할 것인지 정해서 마우스 오버나 클릭이라는 이벤트가 일어나면 해당 수만큼 반복문을 이용하면 별점 기능을 구현할 수 있을 것이다.

소스 코드

별다른 미들웨어들을 쓰지 않고 기본적인 React 컨포넌트와 반복문, 조건문을 사용하여 구현해 보겠다.

여기에 필요에 따라 라이브러리를 추가하여 더 세부적인 기능 구현을 하면 되겠다.

import React, { ReactElemnet, useEffect } from 'react'    //필요 library import



const StarRating : React.FC = ():ReactElement => {

// 별점을 className을 관리할 배열 변수를 type을 정해서 선언한다.
  let starRatingState : Array<string> = []

// 별점 className을 state로 관리하기 위해 useState를 사용해 state를 선언한다.
  const [starRatingOnOff, setStarRatingOnOff] = React.useState(starRatingState)


//mouseOver시 호출될 function 정의
  function mouseOverStarRating( inx : number ){
     let tempStarRating : Array<string> = []
     for( let i =0; i< 5; i++ ){
        if( i < inx ){
            //inx보다 앞에 있는 별은 모두 채워지게 한다.
        	tempStarRating.push( 'item-rating pointer zmdi zmdi-star' )
        }else{
            //inx보다 뒤에 있는 별은 빈 상태로 놔둔다.
        	tempStarRating.push( 'item-rating pointer zmdi zmdi-star-outline' )
        }
     }
     setStarRatingOnOff(tempStarRating) //새로운 state를 세팅한다.
  }



// 화면이 렌더링 될때 먼저 수행하기 위해 useEffect를 사용한다.
  useEffect(() => {
    //5점 만점으로 처음에는 별이 다 빈 상태임으로 5개를 모두 outline으로 만든다.
    for( let i =0; i< 5; i++ ){
    	starRatingState.push( 'item-rating pointer zmdi zmdi-star-outline' )
    }
    setStarRatingOnOff(starRatingState)

  },[])

  return (
     <i className={starRatingOnOff[0]} onMouseOver={()=>mouseOverStarRating(0)} />
     <i className={starRatingOnOff[1]} onMouseOver={()=>mouseOverStarRating(1)} />
     <i className={starRatingOnOff[2]} onMouseOver={()=>mouseOverStarRating(2)} />
     <i className={starRatingOnOff[3]} onMouseOver={()=>mouseOverStarRating(3)} />
     <i className={starRatingOnOff[4]} onMouseOver={()=>mouseOverStarRating(4)} />
  )
}

마우스 오버에 따라 별점이 움직이는 React 컴포넌트를 완성했다.

클릭시 별점이 부여되게 하려면 html i 태그에 있는 onMouseOver함수를 onClick으로 바꾸면 된다.

두가지를 모두 넣고 싶으면 모두 선언해 주면 된다.

여기에 최종 부여된 별점이 몇 점인지 관리 하는 state를 만들어 서버에 저장할때 보내주면 된다.

간단한 별점 기능을 구현해 보았다.

① 구글 애널리틱스 기초 및 설치(feat. 개발자를 위한 GA)

B급 코딩 — Mon, 4 Jan 2021 03:37:26 +0900

1. 구글 애널리틱스(이하 GA)란?

요즘 GA는 여러곳에서 많이 들어봤을 것이다.

구글이 2005년 3월 웹분석 전문 업체인 어친 소프트웨어(Urchin Software)를 인수한 후

그해 11월 구글 애널리틱스 서비스를 출시한 후로 꾸준한 성장세를 보였고,

이제 이 서비스가 설치되어 있지 않은 사이트나 앱을 찾기 어려울 정도이다.

GA는 한마디로 정의하면 로그 분석 도구이다.

웹이나 앱에 방문한 사용자들이 어디를 클릭하고 어디를 보고 있는지에 대한 분석으로

운영자들에게 비즈니스를 더 성장할 수 있는 인사이트를 주는 것이다.

2. 구글 애널리틱스(GA)가 각광받는 이유

과거에는 모든 비즈니스가 오프라인에서 일어났다. 그래서 비즈니스 운영자들은 매장을 잘 꾸며야했다.

또 매장에 잘 방문하게끔 하는게 매우 큰 목표이고 관심사였다.

그래서 매장앞에서 호객 행위도 하고 인테리어에 공을 들이기도 했다.

하지만 디지털화와 더불어 온라인 비즈니스가 성행하게 되었고,

킹시국과 맞물려 거의 모든 비즈니스가 온라인으로 가고 있다.

<오프라인 매장 꾸미기에서 온라인 채널을 꾸며야하는 시대>

그래서 비즈니스 운영자들이 이제는 오프라인 매장 꾸미기를 온라인에서 해야하는 시대가 되었다.

그렇다면 일단 사용자들이 온라인 웹이나 앱에서 무슨 행동을 하는지 알아야 했고 거기에 맞는 사이트 개선 및 앱 개선이 이뤄지는 것이다.

그래서 이러한 인사이트를 주는 로그 분석 툴이 각광받게 된 것이다.

이런 툴은 많은 종류가 있다.

<출처: https://w3techs.com/ >

구글 애널리틱스는 그 중에서도 높은 사용률을 보이고 있다.

3. 마케터도 아니고 비즈니스 운영자도 아닌 개발자가?

그렇다. 우리는 개발자이다.

사실 이건 마케터들이 제품의 판매량이나 콘텐츠 소비량을 늘리는 전략을 짤 때 더 필요하다.

그런데도 이런 인사이트 제공 툴에 대해 알아야할까? 답은 YES다

이렇듯 로그분석이 기본이 되어버린 시대에서 어느 구축 프로젝트에 가던 이 툴에 대한 설치는 필수이다.

그럼 설치법만 구글링으로 보고 하면 되는게 아닐까? 답은 No다

단순 설치는 사실 비개발자도 따라하는게 가능할 정도로 쉽다. 태그하나만 넣으면 끝이기 때문이다.

하지만 좀 더 복잡한 분석을 하고 싶고 운영되는 시스템의 특성을 고려한 설치는 여전히 개발자의 몫으로 남아있다.

ex) SPA 구조의 페이지 뷰 설정, 크로스 도메인 설정 등

그래서 우리는 이 툴을 알아야 한다.

대충 이 툴에 어떤 메뉴가 있고 어떤 분석을 제공해서,

우리는 어떤 데이터를 이 툴에 보내주는 코드를 심어야하는지 대충은 알 필요성이 있다.

4. 가입 및 설치

이 블로그에 구글 애널리틱스를 설치해 보고 애널리틱스가 어떻게 돌아가는지 쭉 포스팅할 예정이다.

같이 이 툴을 마스터 하고 혹 다른 툴을 프로젝트에서 설치할 상황이 생겨도 GA 지식을 베이스로 유연한 설치가 가능했으면 한다.

일단 준비물 : 구글 계정, 크롬 브라우저

Google analytics 페이지에 접속합니다.

위와 같은 화면이 나오면서 우리를 격하게 환영해 준다.

측정시작 버튼 Click!

<측정 시작을 하면 나오는 페이지>

계정 설정에서 계정 이름에 원하는 이름을 넣는다.

나머지 체크박스는 그대로 둔다.

다음 버튼을 눌러 속성 설정으로 넘어간다.

<속성 설정 화면>

속성 이름을 넣고 시간대와 통화를 대한민국으로 설정한다.

따로 원하는 시간대와 통화가 있다면 그것으로 설정한다.

로그를 분석해서 보고서 형태로 올려주는 시간대와 나중에 비즈니스에 적용했을 때 매출 분석 등에 표현 될 통화 정보이니 필요에 맞게 설정한다.

- 계정, 속성은 무엇인가?

GA 계정 구조가 3단계로 되어 있다. 계정, 속성, 보기가 그것이다.

이는 큰 기업들이 GA를 관리하는데 편리함을 주기 위해 계층 구조를 사용한 것인데

계정은 하나의 기업이라고 보면된다.

속성은 그 기업이 가지고 이는 웹, 앱 등의 채널에 하나씩 맵핑된다.

삼성전자라는 계정에 삼성전자 홈페이지 속성, 삼성전자 앱 속성이 있는 것이다.

보기는 속성을 분석한 보고서이다.

삼성전자 홈페이지 속성에 여러가기 보기 보고서가 있는 것이다.

!!!! 주의해야할 점

꼭 고급옵션보기 버튼을 눌러야한다.

<속성 설정의 고급옵션보기 버튼을 누르면 나오는 옵션>

여기서 꼭 유니버설 애널리틱스 속성 만들기를 On으로 해주는 것이 좋다.

그러면 위와 같은 화면이 나오고 우리의 블로그 주소를 넣어주면 된다.

아래 라디오 버튼도 유니버설 애널리틱스 속성만 만들기로 바꿔준다.

이와같이 하는 이유는 구글이 애널리틱스 4라는 것을 업데이트 했다.

이것은 기존의 앱과 웹을 나눠서 사용자 로그 분석을 했던 것을 합쳐서 하겠다는 철학 아래 시작된 업데이트 이다.

하지만 아직 널리 사용되지 않고 있고 지금 구글링을 해서 나오는 GA에 대한 정보는 모두 유니버설 애널리틱스 속성으로 만든 정보들이다.

따라서 이렇게 해야 정보를 얻기도 편하다.

또한 애널리틱스 4는 아직 베타단계여서 나중에 언급할 구글 마케팅 플랫폼과의 연동이 잘 되지 않는 것으로 보인다. ( 필자는 옵티마이즈라는 솔루션과의 연동을 하다가 계속 에러가 발생했다. )

<비즈니스 정보 설정 화면>

그 이후 비즈니스 정보를 자신에 맞게 선택해 준다. ( 별로 중요하지 않다. )

만들기 버튼을 클릭한다.

<약관 계약 화면>

위와 같은 약관 계약 화면이 나온다. 대한민국으로 바꾸고 모두 동의 한 후 동의함 버튼을 클릭한다.

<설정 완료 후 화면>

모든 설정을 완료하면 위와 같은 화면이 뜰 것이다. 이제 블로그 혹은 사이트에 GA를 설치하고 분석을 수행할 수 있다.

추적 ID는 속성에 부여되는 고유값으로 잘 간수 하길 바란다.

사이트와 같은 경우 아래의 gtag.js 추적 코드를 html의 <head> 태그 안에 넣으면 설치는 끝난다.

티스토리 블로그의 경우 GA 플러그인을 제공하고 있다.

관리자 메뉴에서 플러그인 메뉴를 클릭하면 GA 플러그인이 보일 것이다.

플러그인을 누르면 추적 ID를 입력하는 란이 나온다. 여기에 아까 GA 콘솔에 있던 추적 ID를 입력한다.

그리고 적용을 누르면 모든 설치는 완료된다.

다시 GA 콘솔로 돌아와서 홈 메뉴를 누르면 현재 활성 사용자가 1로 바뀌면서 제대로 설치되었음을 확인할 수 있다.

다음 포스팅에서는 GA 콘솔에서 제공하고 있는 보고서를 간단히 알아보고 GA가 데이터를 수집하는 방식에 대해 알아보겠다.

끝!

[기술] 머신러닝 기초 (feat. Deep Learning)

B급 코딩 — Sun, 3 Jan 2021 02:19:49 +0900

IT 업계에서 날이 갈수록 Hot해 지고 있는 기술을 고르자면 바로 머신러닝일 것이다.
정말 이제는 안쓰는 곳을 찾기 힘들정도로 많은 곳에 뿌리를 내리고 있다.

들어가기

머신러닝, A.I., 딥러닝, 빅데이터, 모델링 등등등등

요즘 우리를 괴롭게 하는 용어들이다. 이것들을 수학을 모르면서 아는 척 했다가 먼지 나게 털릴 듯한 느낌이 든다.

하지만 그렇지 않다!

머신러닝 분야가 학계에서 연구하는 분야에만 머물러 있다가 산업계에서 쓰이기 시작한 이유는 쉬워져서 이다.

산업계에서 가장 중요한 것은 무엇인가? 바로 효율이다. 머신러닝이 수학 개념을 모두 알아가는 시간이 들고 적용하기 어려웠다면 절대 산업계에서 수용하지 않았을 것이다. 차라리 머신러닝을 대신할 알바를 더 썼겠지.

고로 우리도 머신러닝을 아는척 해볼 수 있다.

개요

어린아이들은 무언가를 하다가 잘 안되면 부모를 찾아 처리해 달라고 한다.

예로부터 인간은 도구의 자식들이였다.

인간 사회가 발전하면서 더이상 걷기만으로는 이동의 효율이 나지 않아 바퀴달린 이동수단들을 만들기 시작했고, 발전을 거듭할 수록 가야할 거리는 늘어나 급기야 비행기를 만들어 하늘을 날기 시작했다.

머신러닝도 마찬가지다.

인간 사회가 정보화 시대에 접어들면서 인간들을 데이터라는 것을 쌓기 시작했다.

데이터를 기반으로 결정을 내리면 더 객관적이고 안정적이며 최적화된 결론에 도달할 수 있다는 것을 알았기 때문이다.

그 결과 데이터는 미친듯이 많아지고 더이상 수량을 셀 수 없어 빅데이터라는 용어를 만들어 내고

비교 및 분석해야할 데이터가 너무 많아져 이것도 기계에게 부탁하기 위해 만든 것이 바로 '머신러닝' 되겠다.

용어 정리

일단 효율적인 아는척을 위해 잠시 혼재되어 있는 단어를 세척해 보자

일단 제일 큰 개념은 AI다. 그 아래 머신러닝이 있고 그 아래 딥러닝이 있는 것이다.

유식하게 고1 수학 수준 정도로 부분집합 관계라고 말하면 되겠다.

<터미네이터 명장명과 알파고>

AI가 무엇인지는 아놀드 형이 "아윌비백"을 외칠 때부터 우리에게 친숙한 소재가 되어있었다.

최근 구글이라는 IT 아이언맨이 만든 자비스... 아니 알파고도 AI를 점점 더 친숙한 존재로 인식하게 했다.

그래서 우리가 주목해야할 부분은 머신러닝 부터이다.

마치 구글 번역기를 읽어 주는 듯한 기계가 학습하는 것이라고 말해서는 안된다.

앞서 머신러닝이 나오게 된 배경에서 말했듯이 겁나게 많은 데이터들을 가지고 먼가 결정을 하는 체계를 만드는 것이 머신러닝이다.

체계라는 단어를 좀 더 멋있게 모델이라고도 한다.

내가 갑자기 랩을 하고 싶어 쇼미더 머니에 지원한다고 해보자

과연 이게 잘하는 짓인지 알고 싶어( 정상적인 사고를 한다면 결과를 당연히 알지만 꿈에 취하면 답도 없다. )

머신러닝을 이용한다.

기계는 수많은 데이터를 보고 이를 판단할 것이다. 내가 초딩때 음악경진대회 수상경력만 보고 쇼미더 머니에 나가라고 판단하진 않는다는 것이다.

음색, 성량, 생긴 꼬라지 등등을 모두 분석해 나가지 말라는 결론을 내려줄 것이다.

이렇게 다양한 데이터들을 가지고 판단의 근거를 만들어 내는 과정 때문에 러닝(학습)이란 단어가 붙은 것이다.

딥러닝은 머신러닝을 하기 위한 하나의 방법이다.

서울에서 여수를 가는 방법은 자동차도 있고, 기차도 있고, 비행기도 있고, 걸어서도 있다.

머신러닝에도 다양한 기법이 존재한다.

딥러닝은 그 중 하나인 것이다. 이는 인공신경망이라는 기술을 써서 학습의 효과를 높이는 방식으로

요즘 Hot 하기 때문에 머신러닝과 많이 혼재되서 쓰이고 있다.

머신러닝의 어려움

머신러닝에는 매우 치명적인 약점이 있다.

그 근본은 보면 답은 간단하다. 바로 데이터가 후지면 모델도 후져진다는 것이다.

이 때문에 데이터 과학은 점차 더 성행하고 있고 라벨링이란 이름의 노가다 작업을 알바들을 고용해서 기업들이 하고 있는 것이다.

여기까지다.

우리는 이제 회의시간에 혼재되고 있는 단어를 정리해 줄 수 있고 머신러닝을 하려면 결국 데이터가 중요하다는 것까지

아는 척할 수 있다.

다음에는 머신러닝의 종류와 그 기법

그리고 이 분야에서 제일 핫한 라이브러리인 Tensorflow도 다뤄보겠다.

[인프라] 도커(Docker) 기초 개념

B급 코딩 — Sun, 3 Jan 2021 02:17:57 +0900

오늘은 인프라 쪽과 관련한 용어를 아는척 해보겠다.
그 이름하여 도커.

<Docker 공식 이미지> 출처 : https://www.docker.com/get-started

Docker는 백앤드 영역에 서식하는 개발자라면 한번쯤은 들어봤을 용어이다.

과연 이것이 무엇에 써야하는 물건이며 회의시간에 Docker라는 용어가 나왔을 때 아는 척 할 수 있는 스킬을 익혀보자.

들어가기

도커는 wiki에 따르면 '도커는 리눅스의 응용 프로그램들을 소프트웨어 컨테이너 안에 배치시키는 일을 자동화하는 오픈 소스 프로젝트로' 라고 시작한다면 아는 척에 실패한 것이다.

우리는 개발자 답게 도커 전체를 통상적으로 이야기 하는 정의보다 곁다리적인 장점을 먼저 말해야한다.

<docker를 활용한 CI/CD 예시>

출처 : https://www.researchgate.net/figure/CI-CD-Architecture-using-Docker_fig1_331131851

도커는 사실 개발자의 편의성을 위해 만들어 진 것이다.

더 자세히 말하자면 IT 시스템 운영자, SM 업무를 하는 사람들을에게 배포를 쉽게 해주는 역할을 해준다.

물론 시스템 초기 개발자 SI 업무를 하는 사람에게도 매번 배포를 하는 노가다를 쉽게 줄여준다.

그래서 요즘 도커가 이렇게 Hot함에도 불구하고 이 글을 쓰고 있는 시점의 한국 IT 생태계는

도커의 필요성을 고객(IT를 직접 운영하지 않는)이 잘 느끼지 못한다.

하지만 개발자의 편의성은 곧 IT 시스템의 안정화로 이어지고 장애가 날 확률을 줄여준다.

고로 도커는 IT 시스템을 운영하는 사람이든 고객이든 좋은 가치를 줄 수 있는 아이다.

개요

도커를 한마디로 정의하면 vm의 어플리케이션화이다.

VM을 올리려면 생각보다 복잡하다.

쉬운 예로 디자인에 혹해서 Mac을 샀다가 은행업무 때문에 window를 같이 설치하는 불쌍한 중생들을 많이 목도했을 것이다. 이것과 같은 이치이다.

서비스를 하나 더 늘리기 위해 같은 물리서버에 os를 하나 더 올려서 다시 웹서버부터 was, DB 등을 설정하는 것이다.

하지만 도커는 이것을 어플리케이션화 했다.

즉 하나의 리눅스(대표적으로, 다른 os도 가능)에 도커를 설치하고 그 안에 내가 만들고 싶은 웹 어플리케이션들을 물리 서버의 메모리가 허락하는한 계속 만들 수 있다.

더이상 인프라 담당자가 vm을 올려주기 까지 기다리고 port 작업을 해주고 기본적인 os 환경 구성을 해줄때까지 기다릴 필요가 없다는 것이다!

도커는 엑셀이다?!

이해를 돕기 위해 도커를 엑셀에 비유하겠다.

윈도우에 깔리는 어플리케이션 중 하나가 엑셀이다

리눅스(주로 웹서버를 위한, mac os나 window 서버에도 설치 가능하다)에 깔리는 어플리케이션 중 하나가 도커가 된다.

고로 설치도 간단하다.

curl -fsSL https://get.docker.com/ | sudo sh

우분투를 기준으로 위 명령어만 치면 설치가 된다. (윈도우에서 install.exe를 더블클릭하는 것과 같다.)

우리는 효율적인 문서 작업을 위해 다른 사람이 만들어 놓은 엑셀 템플릿 파일을 다운 받아서 쓰기도 한다.

우리는 효율적인 서버 구성을 위해 다른 사람이 만들어 놓은 도커 스크립트를 이용한다.

엑셀 파일을 더블클릭해서 사용하듯이 아래의 명령어로 도커 스크립트를 실행하여 서버로 사용할 수 있다.

<도커 허브 공식 이미지>

다른 사람들이 만든 엑셀 템플릿 등을 해피캠퍼스 등의 사이트로 공유한다.

다른 사람들이 만든 도커 스크립트는 도커허브를 통해 공유한다.

나중에 도커의 기본적인 사용법에 대해서도 다뤄보겠다.

이 글이 도커로 고통 받는 자들의 고통을 1이라도 줄여 줄 수 있길 바란다.

[개발언어] 파이썬(python) 아는척 하기 (feat. 기초)

B급 코딩 — Sun, 3 Jan 2021 02:14:36 +0900

IT 업계에 있다보면 하루가 다르게 나오는 신기술들과 업데이트로 인해 머리 속 빈공간이 남아나지 않는 느낌을 받는다.
그렇다고 모든 것을 공부할 수도 없는 노릇. 그 기술이 주된 업무가 아니라면 회의나 이메일, 대화 속에 등장하는 신기술을 아는척 해서 스마트한 IT인의 이미지, 언제나 공부하는 성실한 이미지를 구축해 보자.

<파이썬 공식 이미지>

개요

그렇다. 그녀석이다.

요즘 최고의 주가를 올리고 계신 그 언어 Python(파이썬)

<프로그래밍 언어 순위>출처 : https://www.tiobe.com/tiobe-index/

1등만 기억하는 더러운 세상에 3등이 머 그리 대단하냐고 할 수 있지만

C나 Java는 프로그래밍 언어계의 단군 할아버지를 뛰어넘는 웅녀 수준의 조상급임을 감안하면

파이썬의 성장세는 매우 매섭다.

이게 다 데이터 시대가 도래해서 그렇다. 빅데이터를 이용한 분석과 머신러닝이 판치고 있는 이 세상에서

그것을 잘 다룰 수 있는 언어가 강세를 띄는 것은 {핸드폰 = 아이폰}과 같은 진리이다.

고로 개발의 세계와 조금만 관계된 곳에 있다면 파이썬이란 용어와 필연적으로 마주치며

헤어진 옛 연인처럼 스치듯 안녕할 수 없을 것이다.

언어 기본 특징

일단 누군가 파이썬에 대해 물어 온다면 밝은 함박 웃음을 머금고

언어가 너무 배우기 쉽다. 라고 먼저 말해라

사실 프로그래밍 언어에 쉬운게 어디있는가. 결국 깊게 들어가면 다 어렵다

하지만 파이썬은 실제로 쉬운 구석이 조금 있다.

첫째 변수 선언 시 형(string, int 등) 지정이 없다.

a = 1
b = "abc"
c = [1,2,3]

조금 더 있어 보이고 싶다면 동적인 데이터 타입 결정 지원이 가능한 게 편하다. 정도로 말해준다.

어느 변수든 앞에 var만 쓰면 다 해결되던 노근본 언어 그 옛날 자바스크립트와 비슷한 특징이다.

둘째 {}가 없이 띄어쓰기로 함수나 클레스, 반복문, 조건문 단위가 맞춰진다.

if 4 in [1,2,3,4] :

	print('4가 존재한다')

lang = ['java', 'python', 'c', 'go']

for i in lang : 

	if i in ['java', 'c'] :
    
    	print('웅녀')
        
    elif i in ['go', 'python'] :
    
    	print('X세대')

이것은 상당히 편한 부분이다. 띄어쓰기가 곧 문법이니 코드도 알아서 가독성 높게 정렬된다.

코드에 가독성은 사뿐히 무시하고 5살 아이의 스케치북 마냥 자신의 정렬 세계를 구축하는 개발자라면 파이썬이 해당 습관을 고치는데 도움을 줄 수 있다.

개발 IDE (tool)

Java에겐 이클립스가 있고 C#에겐 Visual Studio가 있다.

파이썬에게는 PyCharm(파이참)이 있다.

파이참은 큰 규모의 파이썬 프로젝트를 할 때 매우 유용하다.

하지만 요즘 개발 툴은 VSC (Visual Studio Code)로 안되는게 없다. 매우 훌륭한 툴이다.

파이썬 개발 역시 VSC에서 가능하다.

대표 Web framework

Java에게 Spring이 있다면 python에게는 Django(장고)와 Flask(플라스크)가 있다.

파이썬으로 Web을 개발한다면 10에 9명은 Django를 사용할 것이다.

왜냐면 너무나도 편해요. React의 create-react-app과 같은 논리다.

create-react-app를 사용하면 React를 사용할 때 개발자가 webpack 등의 세팅을 할 필요가 없다.

Django 역시 매우 무거운 프레임워크로 대부분 필요한 세팅들을 자체적으로 가지고 있어 개발자에게 시몬스 침대같은 편안함을 제공한다.

Flask는 그에 반해 라꾸라꾸 침대 같은 편리함이라 보면 된다. 시몬스와 같은 편안함은 없지만 설치를 통해 복도, 사무실 어디서든 잠을 청할 수 있는 유연성을 가진다.

그런 점 때문에 Flask는 Django에 비해 매우 가볍다.

TensorFlow (텐서플로)

필자 생각에 파이썬의 인기에 30% 정도는 이 라이브러리가 하지 않았나 싶다.

구글 브레인팀에서 만든 데이터 흐름 프로그래밍 도구이다. 머신러닝에 많이 사용되고 있다.

이 라이브러리가 파이썬 API를 제공한다. 현 시점에는 자바스립트에서도 제공되지만 정석은 파이썬이였다.

파이썬과 함께 많이 따라오는 라이브러리이니 한번 봐두면 괜찮다. TensorFlow

그 외

파이썬 공식 아이콘은 뱀 대가리 두개이다.