꿀팁 저장소

Input에서 한글입력을 막는 방법에는

여러가지 접근 방법이 있다.

절대적인 방법을 발견하여 메모해둔다.

1. Input타입이 text인 경우에는 정규식을 통해 체크하여 원하는 문자열 입력방지를 실시할수있다.

예를들어, 숫자만 입력받고싶다면

const regExp = /[a-z|ㄱ-ㅎ|ㅏ-ㅣ|가-힣]/g;

이런식의 정규식으로 입력값을 체크해서 입력을 방지하면 된다.

그리고 실제로 가능한 방법이다.

그러나,  우리는 사용자의 입력 편의성을 위하여 input타입을 number로 잡아줘야한다.

그때는 숫자외 다른 입력값을 입력했을때 정규식이 바보가된다.

인지를 못한다.

왜 그런가하고 타겟의 값을 콘솔에 찍어보았다.

console.log(e.target.value)

결과: 

분명히 실제로는 "123ㄱ"라고 화면에 나타나 있지만 결과에는 빈값이 출력되었다.

그러니 정규식이 캐치할래야 할수가 없는 상황이었다.

2. 정규식이 안먹히면 어떻게하지? 키코드를 사용해야하나?

원하는게 안먹히면 우리들은 발상의 전환을 시도한다.

하지만, 헛탕일 켤뿐 안된다는것을 미리 밝히는 바이다.

3. 그래서 어떻게 해야되는가?

input태그에  onchange이벤트를 걸었다면 아래와 같은 방법으로

숫자입력만 받는 방법이 가능하다.

const isNotNumber = () => {
  const regExp = /[a-z|ㄱ-ㅎ|ㅏ-ㅣ|가-힣]/g;
  return regExp.test(value);
}

<input 
  type='text'
  onchange={e => {
    if (e.nativeEvent.data && isNotNumber(e.nativeEvent.data) {
      e.preventDefault();
      return null;
    }
    
    ...something
  }}
/>

매우 아름다운 방법으로 생각된다.

e.nativeEvent.data에는 놀랍게도 내가 지금 입력한 그 키값이 나타난다.

3이라면 3, t라면 t가 말이다.

backspace는 null이 나타난다. 따라서 null인 경우에는 허용을 해줘야한다.

사실 그동안 숫자만 입력받는 코드를 짜뒀다고 했는데

자꾸 한글이 입력된다는 리포트를 받아서 당황스러웠던적이 있다.

코드는 거짓말을 하지않는다...

나의 실책일뿐~~ ㅎㅎ

이 방법이 유효하지 않다거나 더 좋은방법이 있다면 댓글을 달아주시면 정말 감사하겠습니다.

여기다가

사용중인 정규식을 하나하나 저장하고 업데이트 하고자한다.

매번 새로 짤 필요도 없고...

1. 이메일

/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,5})+$/

2. 휴대폰

/^01(?:0|1|[6-9])[0-9]{4}[0-9]{4}$/

EC2와 NGINX만 쓸때는 너무나도 자연스러웠던것이

LoadBalancer를 쓰면서 추가적인 조치가 필요해졌다

EC2 + NGINX 구성에서는 늘 사용자 요청의 대문역할은 NGINX였고,

NGINX에 HTTP -> HTTPS Redirect 설정을 해두면 자연스럽게 처리되었다.

다만, 이번에 사용자의 증가로 Load Balancer를 적용한 이후로는 해당 코드는 무효했었다.

대문이 NGINX가 아니라 Load Balancer가 되어버린것이다.

따라서,  HTTP -> HTTPS Redirect설정을 Load Balancer에서 해주었다.

너무나도 간단하고 친절하게 되어있으므로 겁먹을 필요없다.

1. EC2 -> 로드밸런서 -> 대상 클릭 -> 하단에 탭중 리스너 -> HTTP 내용중 "규칙 보기/편집"을 클릭하여 해당화면으로 진입.

2. 연필탭 클릭 -> 왼쪽에 뜬 연필 한번 더 클릭 -> 기본 설정 지우고 "리다이렉션 설정" -> HTTPS / 443


참고자료
stackoverflow.com/questions/24603620/redirecting-ec2-elastic-load-balancer-from-http-to-https

[초기설정]

1. key파일을 이용해 root 계정으로 로그인

2. sudo passwd 입력

3. 새 암호 입력

4. 새 암호 확인

[변경]

1. root 계정으로 로그인

2. passwd 입력

3. 새 암호 입력

4. 새 암호 확인

끝...

Node는 기본적으로 싱글스레드 기반이기 때문에

내부적으로 서버를 Fork해서 여러 스레드를 쓰는 방법을 지원해준다.

바로 cluster.

기본적으로 내장되어있으며 그 위력은 어마어마하다.

그런데 linux에서 cluster를 실행한 코드를 pm2로 실행하다보니

난관에 봉착했다.

에러가 발생한다.

cluster가 설정된 코드를 실행할수없었다.

그런데 node의 공식문서에서 방법을 찾았다.

문서의 일부 내용을 발췌했다.

======================================================

PM2 사용

애플리케이션을 PM2에 배치하면, 애플리케이션 코드를 수정하지 않고도 클러스터링을 활용할 수 있습니다. 먼저 여러분의 애플리케이션이 stateless인지 확실하게 해야합니다. 어떠한 로컬 데이터도 프로세스에 저장되지 않아야 합니다. (세션이나 웹소켓 같은 것들 말입니다).

PM2로 애플리케이션을 실행하고 있을 때, 특정한 수의 인스턴스에 실행하는 클러스터 모드를 켤 수 있습니다. 머신의 가용 CPU 수같은 것들이 특정한 수입니다. 애플리케이션을 끌 필요 없이 pm2 커맨드라인 명령을 이용해 클러스터에 있는 프로세스의 수를 직접 바꿀 수도 있습니다.

아래와 같은 방법으로 클러스터 모드를 킵니다.

# Start 4 worker processes

$ pm2 start app.js -i 4 # Auto-detect number of available CPUs and start that many worker processes

$ pm2 start app.js -i max

이 수는 PM2 프로세스 파일 (ecosystem.config.js나 그와 유사한 파일) 안의 exec_mode를 cluster나 instances를 설정해서 수정될 수 있습니다.

실행이 시작되면, app으로 이름지어진 애플리케이션을 아래와 같은 방법으로 스케일링 할 수 있습니다.

# Add 3 more workers

$ pm2 scale app +3 # Scale to a specific number of workers

$ pm2 scale app 2

PM2의 클러스터링에 관한 추가 정보는 PM2 문서의 Cluster Mode를 참고해주세요.

======================================================

사용자 기반 서비스를 만들다보니 Textarea에서 라인별 글자수 제한 및 총 라인 제한을 해야할 일이 생겼다

아래와 같은 코드로 해당 문제를 처리하였다.

필요한 사람들을 위해 공유한다.

const textareaLimitWordAndRow = (text, limitWordPerline, limeLines) => {
  let lines = text.split('\n');
  const charlimit = limitWordPerline; // 글자수 제한

  for (let i = 0; i < lines.length; i++) {
    if (lines[i].length <= charlimit) continue;
    let j = 0;
    let space = charlimit;
    while (j++ <= charlimit) {
      if (lines[i].charAt(j) === ' ') space = j;
    }
    
    lines[i + 1] = lines[i].substring(space + 1) + (lines[i + 1] || '');
    lines[i] = lines[i].substring(0, space);
  }

  return lines.slice(0, limeLines).join('\n');
};

구글에서 제공해주는 도구들을 이용해 체크해보니 운영중인 웹사이트 로딩속도가 어마어마하게 느렸다

모바일 기준으로 19.7

경악스러웠다.

당장 손볼수 있는것들을 손봤고 약 2배정도 빠른 속도를 얻어 방법을 공유한다.

이미 되어있던 퍼포먼스 관련 설정들

1. 서버 로드밸런스

2. 부분적으로 적용한 이미지 cloud front

추가한 퍼포먼스 관련 설정들

1. Nginx - gzip

2. Webpack - compression

3. Code spliting

4. 전체 이미지 cloud front 적용

이 중에서 가장 쉽고 큰 효과를 얻은것은 gzip이 아닌가싶다

주의할점은 클라이언트와 웹서의 서버가 분리되어있다면 양쪽 모두에 설정해주어야 한다는 점이다.

코드는 간결하다. nginx.conf 파일에 아래의 내용을 설정한다.

http {
...

gzip  on;

gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript application/javascript text/xml application/xml application/xml+rss text/javascript;

...
}

코드 스플리팅은 react의 lazy/suspense를 이용해서 간단히 설정해주었다.

코드를 너무 작은단위로 나눠도 호출하는 시간에서 손해가 발생하기 때문에 webpack plugin 설정에 아래와같이

최소 크기를 설정해주었다

...,
plugins: [
  ...,
  new webpack.optimize.MinChunkSizePlugin({
    minChunkSize: 512000, // 50kb
  }),
  ...          
]

compression은 역시 plugin 에서 간단히 추가했다.

[
  new CompressionPlugin({
    filename: '[path][base].gz',
    algorithm: 'gzip',
    test: /\.js$|\.css$|\.html$/,
    threshold: 10240, // 10kb
    minRatio: 0.8,
  }),
]

Rest API서버와 DB서버가 각기 다른 서버에서 운영되는건 매우 흔한일이며

지극히 정상적인 일이라고 볼수있다.

서비스의 규모가 절대로 커질일이 없는것이 아니라면 일단은 분리하는게 좋다는 생각이다.

그럼에도 개발속도와 편의성 측면에서 한 서버에서 API서버와 DB를 운영하고는 하는데 (제가 그랬습니다...)

두 서버를 분리시키고 데이터 마이그레이션하는 방법에대해 소개하도록 하겠습니다.

1.  DB서버 생성 및 몽고 환경 셋업

이 부분에서 사실 제일많은 시간비용이 소모됩니다.

왜냐면 1~10까지 구구절절 설명해주는 자료가 많이 부족하기 때문이죠.

아래와 같은 작업을 해야합니다.

1) EC2환경설정

2) 몽고디비 설치

3) 몽고디비 실행

4) 몽고디비 관리자 계정 설정 및 readwrite계정 추가

5) .conf파일 수정

6) 몽고디비 재실행

7) DB서버에 연결 테스트

8) 데이터 덤프 및 마이그레이션

1) EC2환경설정

여기서 할것은 보안그룹설정인데요

몽고의 기본포트인 27017포트를 개방해줍니다.

2) 몽고디비 설치

각 OS마다 설치방법은 다르지만, 설치와 관련해서는 Mongo에서 매우 친절하게 안내해주고있으니 참고하시기 바랍니다

docs.mongodb.com/manual/installation/

3) 몽고디비 실행

실행, 정지, 재실행, 상태확인에 대해서 간단히 명령어를 알아보도록 하겠습니다.

두가지 버전이 있는데요, systemctl / service 두개의 키워드를 통해 가능합니다.

(실행) stystemctl start mongod

(중지) systemctl stop mongod

(재실행) systemctl restart mongod

(상태확인) systemctl status mongod

일단 설치했으면 실행해줍니다.

systemctl status mongod 를 입력해 정상적으로 동작중이며, mongo를 입력했을때 몽고디비로 진입된다면

잘 설치 및 실행되었다고 볼 수 있습니다

4) 몽고디비 관리자 계정 설정 및 readwrite계정추가

여기서 많이 헤매게됩니다.

기본적으로 로컬에 있는 몽고에서는 해주지않아도 되는데 (단, 하지않았을때 보안의 위험이있습니다)

리모트 서버의 DB에 연결하려면 반드시 계정설정을 해주어야됩니다.

외부에서 연결을 요청하면 몽고에서 사용자 권한을 확인하기 때문입니다.

먼저, 관리자 계정을 생성해주어야합니다.

관리자 계정이란 정말로 슈퍼어드민을 의미하며 DB를 드랍,추가 하는것까지 가능하니 계정관리에 주의해야합니다.

몽고에는 기본적으로 admin이라는 db가 생성되어있는데요. 다음과 같은 절차를 밟도록 하겠습니다.

가) admin db 사용: use admin

나) 어드민 계정 생성: db.createUser({ user: 'admin', pwd: '패스워드', roles: [{ role: 'root', db: 'admin' }] })

다) 생성된 계정 확인: db.getUser('admin')

라) 일반 readwrite계정 생성: db.createUser({ user: 'manager', pwd: '패스워드', roles: [{ role: 'readWrite', db: 'myFirstDb' }, { role: 'readWrite', db: 'mySecondDb' } ] })

마)  생성된 계정 확인: db.getUser('manager')

5) .conf 파일 설정

거의 다 왔습니다. 리모트에서 연결해주기 위해서는 보안설정을 셋업한 상태로 몽고를 실행해주어야만 합니다.

방법은 두가진데요. 제가 확실히 말씀드릴수 있는건 .conf 파일 설정이니 이것을 따르시길 추천드립니다.

mongod.conf 파일은 기본적으로 /etc/mongod.conf 경로에 생성됩니다.

몽고를 설치했지만 해당위치에 mongod.conf파일이 보이지 않는다면 찾아보시기 바랍니다.

mongod.conf 파일에서 아래의 파트를 정확하게, 아주 똑같이 작성합니다.

net:
  port: 27017
  bindIp: 0.0.0.0

security:
  authorization: enabled

(mongod --auth 라는 방법도 있다는데 제가 확신할수없어 아주 개인적으로 권장하지 않습니다.)

여기서 0.0.0.0은 모든 IP에서의 요청을 받겠다는 의미인데, 보안계정을 생성해주었으니 믿고 가도록 합니다.

API서버 주소인 13.x.x.x,192.x.x.x 등을 입력할수도 있다고 하지만 에러가 나는 경험을 했습니다.

관련하여 아시는 분이 있다면 댓글 부탁드립니다.

6) 몽고디비 재실행

systemctl restart mongo

재실행 했다면 반드시 상태도 확인해주세요

systemctl status mongo

여기까지 잘 되셨나요?

7) DB서버에 연결 테스트

자, 대망의 연결 테스트입니다.

로컬 서버에서 테스트하셔도 전혀 무방합니다.

연결 주소는 아래와 같이 작성합니다.

mongod://아이디:패스워드@도메인혹은아이피:27017/디비명

예제입니다.

mongod://manager:openpassword@cup.camil.com:27017/coffee

API서버에서 직접 연결을 체크해봐도 좋고

MongoBB Compass같은 툴을 통해 연결을 시도해 봐도 괜찮은 방법입니다.

후자의 경우 다른 코드에서 발생하는 에러와 분리하여 테스트할 수 있다는 장점이 있습니다.

8) 데이터 덤프 및 마이그레이션

여기는, 기존의 DB가 있는경우에만 진행해주시면 됩니다.

기존의 API서버에서 먼저 데이터를 덤프하는데요, 덤프란 기존의 데이터를 백업하기위해 카피한다고 생각하시면 됩니다.

BSON 타입으로 하는방법과 JSON 타입으로 하는방법 2가지가 있는데요.

여기서는 속도가 더 빠르다고하는 BSON 타입을 채택하여 진행하도록 하겠습니다.

아래의 명령어를 사용하면 내 현재 위치(경로)에 dump라는 폴더 내에 데이터가 덤프가 됩니다.

mongodump --host 127.0.0.1 --out /data/db/backup

덤프된 데이터를 FileZila와 같은 프로그램을 이용해 새 DB서버로 이전해줍니다.

이 때, 덤프된 파일들을 어디로 이전하는지 정확히 위치를 체크하도록 합니다.

* /home/root/  정도의 경로에 backups폴더를 생성하여 이전하는것을 추천드립니다.

데이터를 옮겼다면, 콘솔에서 해당 경로로 이동합니다.

위와 같이 했다면

cd /home/root/backups

가 되겠죠?

마지막입니다. 데이터 마이그레이션을 진행해주면 되는데요, 지금 디비가 텅텅 비어있으니 간단히 처리할 수 있습니다.

단, 진행 전 잠시 mongod.conf 파일의 security파트를 주석처리 하도록 합니다.

#security:
  #authorization: enabled

systemctl restart mongo

systemctl status mongo

몽고의 상태가 정상이라면 마이그레이션을 진행합니다.

mongorestore --host 127.0.0.1 --port 27017 --db 복구하려는 db명 덤프된 디렉터리 위치

예제입니다.

mongorestore --host 127.0.0.1 --port 27017 --db coffee ./coffee

*********** 수정***********

덤프될 디렉터리 위치를 잡을 필요없이 간단히 아래와 같이 복원가능합니다.

mongorestore -d db db

************************************

정상적으로 마이그레이션 됐는지를 먼저 체크해볼까요?

mongo

show databases

>> coffee DB가 존재하나요?

use coffee

show collections

>> collection들은 잘 이전되었나요?

잘 되었다면 다시 security설정을 해줍니다.

security:
  authorization: enabled

systemctl restart mongo

systemctl status mongo

============================

고생하셨습니다. 여기까지입니다.

이 글이 몽고 원격 연결 및 마이그레이션의 성지가 되기를 바라며

부족한 글 많은 분들의 댓글로 꽉꽉 채워지기를 바라겠습니다.

지금 운영중인 회사의 사이트가 모바일 가로모드에서 옆으로 돌아가는게 너무나도 싫어서 막는방법에 대해서 알아봤다.

1. meta tag설정

2. css 트릭

3. jquery 트릭

4. vanila javascript 설정

5. manifest 설정

결론부터 말하면 다 소용없었다.

MDN에 보면 screen orientaion과 device orientation이 다름을 명확히 구분하고있고

screen과 달리 device에 대해서는 별다른 방법이 없는것들만 나타나있다.

여기서 screen과 device의 가로모드가 어떻게 다르냐고 한다면

device가 landscape(가로)/portrait(세로)가 돌아감에 따라 screen이 함께 돌아가는데

screen은 그에맞게 css를 통해 어느정도 맞춰줄수있지만(@media쿼리 활용)

device가 돌아가는것 그 자체에 대해서는 아직까지는 대응할(막아버릴) 방법이 없어보인다.

앱이 내 소유물이라 하면 브라우저는 내 소유물이 아니라 이런 환경적인 부분의 설정에있어서는 한계가 있는걸까?

라는 아쉬움이 남는다.

브라우저가 돌아가는것을 막는 좋은 방법을 알고계신분이 있다면, 댓글 달아주시면 감사하겠습니다.

종종 캐시로인해 .gitignore의 untracking파일이 제대로 안먹힐때가 있다.

이때는 간단히 캐시를 제거해주는것 만으로 해결이 가능하다.

git rm -r --cached .

git add .

git commit -m "fix untracked files"

git push

commit까지 진행하고나면 untracking파일들이 삭제되는걸 볼수있다.