PostgreSQL AccessShareLock 이해 및 해제 가이드

AccessShareLock이란?

• Oracle의 TM LOCK과 유사: 데이터를 읽는 동안(SELECT) 테이블 구조 변경을 막기 위해 걸리는 락입니다.
• 성능에 미치는 영향: 일반적으로 성능 저하를 유발하지 않지만, 테이블 구조 변경 작업 시 방해가 될 수 있습니다.
• PostgreSQL에서의 역할: 데이터의 일관성 유지에 기여합니다.

Lock 조회 및 해제

1. Lock 조회:

SELECT  t.relname,
        l.locktype,
        page,
        virtualtransaction,
        pid,
        mode,
        granted
FROM pg_locks l,
     pg_stat_all_tables t
WHERE l.relation = t.relid
ORDER BY relation ASC;

• relname: 락이 걸린 테이블 이름
• locktype: 락 종류 (AccessShareLock 등)
• pid: 프로세스 ID
• mode: 락 모드

2. Lock 해제:

• 단일 프로세스 종료:

  SELECT pg_cancel_backend(PID);

  • 해당 PID의 프로세스만 종료합니다.
• 상위 쿼리까지 종료:

  SELECT pg_terminate_backend(PID) FROM pg_stat_activity;

  • PID와 관련된 모든 상위 쿼리까지 종료합니다.

3. 실행 중인 쿼리 상태 조회:

select * from pg_stat_activity;

주의 사항

• pg_terminate_backend는 강제 종료이므로 데이터 손실 가능성이 있습니다. 신중하게 사용해야 합니다.
• 락 해제 전 반드시 원인을 파악하고 해결하는 것이 좋습니다. 락이 자주 발생하는 경우, 쿼리 최적화나 데이터베이스 설정 변경이 필요할 수 있습니다.

요약

PostgreSQL의 AccessShareLock은 데이터 일관성을 위해 필요한 락입니다. 일반적으로 문제가 되지 않지만, 테이블 구조 변경 등 특정 상황에서 방해가 될 수 있습니다. 위의 SQL 쿼리를 사용하여 Lock을 조회하고 해제할 수 있으며, pg_terminate_backend를 사용할 때는 주의가 필요합니다.

더 자세한 정보는 PostgreSQL 공식 문서를 참고하세요.

핵심:

• AccessShareLock은 SELECT 시 걸리는 락으로, 일반적으로 성능에 영향을 주지 않습니다.
• Lock을 조회하고 해제하는 방법을 알아두면 문제 해결에 도움이 됩니다.
• pg_terminate_backend는 강력한 명령어이므로 신중하게 사용해야 합니다.

array_agg is an aggregate function 에러는 pg_get_functiondef가 aggregate 함수나 window 함수에 대해서 동작하지 않을 때 발생할 수 있습니다. 이 문제를 해결하려면 함수 정의를 얻는 다른 방법을 사용하거나, pg_proc에서 특정 조건을 추가로 설정해줘야 할 수 있습니다.

아래는 이 문제를 해결할 수 있는 개선된 쿼리입니다:

1. Aggregate 및 Window 함수 제외:

PostgreSQL에서는 집계 함수와 일반 함수가 모두 pg_proc에 저장되지만, 집계 함수와 window 함수는 pg_get_functiondef로 정의를 조회할 수 없습니다. 이를 필터링하려면 proisagg와 proiswindow 컬럼을 활용할 수 있습니다.

SELECT
    n.nspname AS schema_name,
    p.proname AS function_name,
    pg_get_functiondef(p.oid) AS function_definition
FROM
    pg_proc p
JOIN
    pg_namespace n ON p.pronamespace = n.oid
WHERE
    NOT p.proisagg -- 집계 함수가 아닌 것
    AND NOT p.proiswindow -- 윈도우 함수가 아닌 것
    AND pg_get_functiondef(p.oid) LIKE '%검색할_문자열%';

2. PostgreSQL 11 이상 (prokind 사용):

PostgreSQL 11 이상에서는 pg_proc에 prokind 컬럼이 추가되어, 함수 유형을 더 쉽게 필터링할 수 있습니다. prokind = 'f'는 일반 함수를 의미합니다.

SELECT
    n.nspname AS schema_name,
    p.proname AS function_name,
    pg_get_functiondef(p.oid) AS function_definition
FROM
    pg_proc p
JOIN
    pg_namespace n ON p.pronamespace = n.oid
WHERE
    p.prokind = 'f' -- 일반 함수만 선택
    AND pg_get_functiondef(p.oid) LIKE '%검색할_문자열%';

3. 특정 스키마에 대해서만 검색 (옵션):

SELECT
    n.nspname AS schema_name,
    p.proname AS function_name,
    pg_get_functiondef(p.oid) AS function_definition
FROM
    pg_proc p
JOIN
    pg_namespace n ON p.pronamespace = n.oid
WHERE
    p.prokind = 'f'
    AND n.nspname = '특정_스키마명'
    AND pg_get_functiondef(p.oid) LIKE '%검색할_문자열%';

위 쿼리 중 하나를 사용하면 pg_get_functiondef에서 발생하는 문제를 방지하고, 함수 정의를 성공적으로 검색할 수 있을 것입니다.

회사와 개인프로젝트의 계정을 분리한다던지, 개인 프로젝트와 스터디 그룹의 계정을 분리한다던지 한 컴퓨터에서 여러 Github 계정을 사용해야 할 경우가 있다. SSH를 활용하여 관리하는 방법을 사용하면 편하다.

기존에 ssh 키가 있는지 확인

  ls -al ~/.ssh

ssh 키를 생성 및 agent 등록

  # 2개의 키 생성하기
  ssh-keygen -t rsa -C "{private}@mail.com" -f "~/.ssh/{rsa file for private}"
  ssh-keygen -t rsa -C "{group}@mail.com" -f "~/.ssh/{rsa file for group}"

  # 키 생성 확인
  ls -al ~/.ssh

  # ssh-agent 실행 확인
  eval "$(ssh-agent -s)"

  # 생성한 키 등록
  ssh-add ~/.ssh/{rsa file for private}
  ssh-add ~/.ssh/{rsa file for group}

  # 등록한 키 확인
  ssh-add -l
  4096 SHA256:... {private}@mail.com (RSA)
  4096 SHA256:... {group}@mail.com (RSA)

ssh 설정 파일 수정

ssh 설정 파일은 ~/.ssh/config이다. 파일이 존재하지 않는다면 생성 후 진행한다.

  # 파일 존재 여부 확인
  cat ~/.ssh/config

  # 파일 생성
  touch ~/.ssh/config

  # 파일 수정
  vi ~/.ssh/config

  # IDLOOK
  Host github.com-{group_name}
    HostName github.com    
    User {group_github_name}
    IdentityFile ~/.ssh/{rsa file for group}

  # PRIVATE
  Host github.com-{private_name}
    HostName github.com
    User {private_github_name}
    IdentityFile ~/.ssh/{rsa file for private}

git 설정파일 수정

git user name과 user email 설정 파일을 각각 생성 수정한다

  touch ~/.gitconfig-{private}
  touch ~/.gitconfig-{group}

개인용

  vi ~/.gitconfig-{private}

  [user]
    name = {private_github_name}
    email = {private}@mail.com

업무용

  vi ~/.gitconfig-{group}

  [user]
    name = {group_github_name}
    email = {group}@mail.com

git 설정 파일에서 해당 파일을 읽어오도록 한다

  vi ~/.gitconfig

  [includeIf "gitdir:{개인 프로젝트 경로}"]
    path = .gitconfig-{private}
  [includeIf "gitdir:{그룹 프로젝트 경로}"]
    path = .gitconfig-{group}

Github 계정에 SSH 키를 등록

생성한 ssh 키를 각각 두개의 github 계정에 등록해준다.

우측 상단 Github Profile > Settings > 좌측 SSH and GPG keys > 우측상단 New SSH Key
타이틀은 편하게, Key type은 Authentication Key, Key 부분에 생성한 키를 복사해서 붙여 넣는다.

  # shell에서 명령어로 복사하는 방법
  pbcopy < ~/.ssh/{rsa file for private}

  # shell에서 명령어로 출력한 후 terminal에서 복사하는 방법
  cat ~/.ssh/{rsa file for private}

Github 등록 확인

  ssh -T git@github.com-{private_name}

로컬로 Github 레포지토리 복사

복사시 https가 아닌 ssh로 한다

  git clone git@github.com-{private_name}:{user-name}/{repository-name}.git

로컬이 이미 레포지토리가 있을 경우 주소 변경

  # 기존 리모트 url 확인
  git config --get remote.origin.url
  git@github.com:{A}/{B}.git
  # 리모트 url 변경
  git remote set-url origin git@github.com-{private_name}:{A}/{B}.git

  # 동작 확인
  git pull

clone, pull등 git 명령어 결과에서 에러가 나올 경우 ssh를 디버깅 모드로 시도

  GIT_SSH_COMMAND="ssh -v" git fetch

DL;DR

모든 내용은 git manual에 있다.https://git-scm.com/docs/git-config#_conditional_includes

참고

• https://git-scm.com/docs/git-config#_includes
• https://git-scm.com/docs/git-config#_conditional_includes
• https://www.lesstif.com/gitbook/git-ssh-verbose-mode-125305437.html

1. 테스트 프로세스

테스트 프로세스는 테스트와 관련된 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 모든 구성요소를 엮어주는 역할을 함.

테스트 프로세스 5 단계

  계획/제어 -> 분석/설계 -> 구현/실행 -> 완료/리포팅 -> 마감

테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 5단계로 구성.

1. 계획과 제어 :
   테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의.
   테스트 제어는 계획 대비 실제 신행 상황을 비교하는 지속적인 활동.
2. 분석과 설계 :
   테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환.
3. 구현과 실행 :
   테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트스를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시져를 명세화.
4. 완료 조건과 리포팅 :
   초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가.
5. 테스트 마감 :
   완료된 테스트에서 발견된 사실 및 수집된 데이터, 경험을 취합하고 축적.

2. TC 작성 절차

  문서 수집 -> TC 작성 -> 내부 검토 -> 커버리지 분석 -> 승인

1. 참조 문서 수집 :
   테스트 계획서에 명시된 테스트 케이스 작성 지침과 수준을 고려,
   테스트 설계에 필요한 분석 및 설계 문서 수집.
2. TC 작성 :
   테스트 설계 기법을 이용하여 TC를 작성.
3. 내부 검토 :
   PM, 아키텍트, 디자이너, 기획자, 개발자, QA 담당자가 작성된 TC의 적정성 검토.
4. 요구사항 대비 커버리지 분석 :
   TC가 어느 정도 요구사항을 반영하는가에 대한 분석.
   기본적으로 테스트 가능한 요구사항은 모두 TC에 반영되어있는지 확인.
5. 승인 :
   작성된 TC를 클라이언트(현업), 기획자 및 PM에게 승인을 받음.

3. TC 구성요소

• 식별 번호 :
  TC의 고유 식별자.
• 이슈 번호, 제목 :
  제목과 이슈 번호를 기입. (Redmine NO., Jira NO.)
• 요약 (Description) :
  TC의 목표 등 요약된 정보
• 사전 조건 (Precondition) :
  테스트 수행에 필요한 조건 및 실행환경. (선행 조건, 전제조건)
• 종속성 (Dependencies) :
  테스트 요구사항 또는 기타 TC에 대한 의존성 판단.
• 수행 절차 (Test Step) :
  TC를 수행하기 위한 정확한 단계.
• 기대 결과 (Expect Result) :
  절차대로 진행 시 테스트 통과 여부를 결정하는 기대 결과.
• 실제 결과 (Actual Result, PASS / FAIL) :
  테스트 수행 후 실제 결과.
• 비고 (Remark, Note, Comment) :
  기타 비고 사항을 기입.
• 그 외 :
  우선순위, 모듈 이름, 테스트 설계자, 설계일, 테스트 수행자, 수행일 등

구성 요소는 조직이나 프로젝트에 따라 변경/추가/삭제 될 수 있다.

4. TC 작성 시 주의 점 및 장/단점

주의점

• 절차의 누락 :
  테스트 절차를 정확하게 입력하지 않을 경우 테스트 수행의 어려움이 생기는 테이스 발생 가능.
• 장황한 설명 :
  TC 작성 시 상세하고 충분한 정보를 제공해야 하지만, 너무 많은 단어와 불필요한 설명으로 소통의 오류 유발 가능.
• 전문 용어의 과다 사용 :
  TC 작성 시, 직군간 소통이 불가능한 전문용어를 과다사용시 테스트 수행에 어려움이 있을 수 있음.
• 분명하지 않은 PASS/FAIL 기준 :
  테스트 수행 후 테스트 결과가 통과인지 실패인지 예상 결과에 정확히 기입하지 않아 결과 판단에 어려움 유발 가능.

단점

• TC 작성 시간이 수행 시간보다 오래 걸릴 수 있음.
• 기능 변화에 따른 TC 변경 :
  기능을 자주 변경한다면 추후 테스트 케이스의 통제에 어려움이 생기게 될 수 있음.
• 배경 지식 판단의 어려움 :
  TC를 작성하는 사람은 테스트 하는 기능을 잘 알고 있으나, 테스트 수행자는 배경 지식이 없을 경우 테스트 수행 시간이 길어지거나 수행에 어려움이 있을 수 있음.

장점

• 이력 참조 :
  TC는 어플리케이션 런칭 후에도 사용, 유지보수 팀과 추후 어플리케이션의 버전을 담당자의 테스트 이력 참고가 가능.
• 테스트 진행 상황 추적 :
  TC를 문서화 하면 수행한 TC의 수, 통과/실패 수, 과업 범위 별 케이스 수, 테스트 커버리지 등의 정보를 추적/확인 가능.
• 반복성 :
  잘 작성된 TC는 누구나 반복적으로 수행 가능.

5. TC 정렬

TC의 정렬은 업부의 효율과 연결될 수 있다. 테스트의 흐름, 테스트 환경 등을 고려해서 정렬 하도록 하자.

흐름이 이어지는 TC 정렬

환경이 비슷한 TC 정렬

GIT

git : Linux 커널 소스를 관리하기 위해 리누스 토발즈가 직접 개발한 분산형 버전관리 도구.
분산형이라는 의미는 여러 클라이언트들이 각자의 컴퓨터에 저장소를 반들어 중앙 서버의 전체 사본을 가지고 작업하는 것임.

SVN과 차이점

1. SVN

   • 중앙 서버에서 소스코드와 히스토리를 관리함

2. GIT

   • 소스를 여거 개발 PC와 저장소에 분산해서 저장
   • 로컬에서 버젼을 관리하기 때문에 SVN에 비해 빠름

GIT의 장점

1. 같은 파일을 여러 명이 동시 작업하는 병렬 개발 가능
   (브랜치를 통해 개발한 뒤, merge 하는 방식으로 개발 진행 가능)
2. 분산 관리이기 때문에 중앙저장소에 문제가 생겨도 원상복구 가능

Git 기본 용어

• repository : 저장소를 의미함
  저장소를 통해 소스, 히스토리, 태그의 관리가 가능하며, 저장소를 통해 작업자가 변경한 소스의 히스토리 확인 가능
• working tree : 저장소의 어느 한 시점을 바라보는 작업자의 현재 시점
• staging area : 저장소에 커밋하기 전에 커밋을 준비하는 위치
• commit : 현재 변경된 작업 상태에서 점검이 끝나면 확정하고 저장소에 저장하는 작업
• head : 현재 작업중인 branch를 가리킴
• branch : 가지 또는 분기점
  작업을 할 때 원본을 복사해서 branch에서 작업을 한 후 완전할 때 merge하여 작업함
• merge : 다른 branch의 내용을 현재 branch로 가져와 병합하는 작업.

git 주요 명령어

ropository 생성

• git init : 깃 저장소 초기화
• git clone {url} : 원격 저장소 복사

상태 확인

• git status : 작업 디렉토리에 변경된 파일 확인하기
• git diff : 변경된 파일들의 변경된 내용 확인
• git log : 변경 이력 보기

브랜치 작업

• git branch : 로컬 브랜치 목록 확인

• git branch -r : 원격 브랜치 목록 확인하기

• git branch -av : 로컬과 원격 브랜치 목록 확인하기

• git branch -m {old_name} {new_name} : 브랜치 이름 변경하기

• git branch {new_branch_name} : 브랜치 생성

• git checkout {branch_name} : 브랜치 변경하기

• git branch -d {branch_name} : 브랜치 삭제

반영

• git add . : 모든 변경사항을 커밋 준비 "스냅샷"
• git add {file} : 특정 파일의 변경사항을 커밋 준비
• git commit -m '{message}' : 메세지와 함께 커밋하기
• git commit --ammend : 마지막 커밋 메세지 수정하기 (push한 commit에는 하지 말것)

취소

• git reset --hard HEAD^ : 이전 commit 취소, 변경사항 폐기
• git reset --soft HEAD^ : 이전 commit 취소, 변경사항 유지
• git reset --soft merge : merge 취소하기
• git reset --hard HEAD && git pull : 변경사항 폐기 후 원격 저장소의 최신 코드로 덮어쓰기
• git revert {commit_code} : 커밋 되돌리기

동기화 하기

• git fetch {remote} : 원격 저장소의 최신사항 가져오기
• git pull {remote} {branch} : 원격 저장소의 최신사항을 가져와서 병합하기
• git pull --rebase : 원격 저장소의 변경사항을 가져오고 초기화 하기
• git push : 원격 저장소에 변경사항 발행하기
• git merbe {branch} : 브랜치 병합하기
• git rebase {branch} : 리베이스 하기

브랜치의 변경사항 임시저장

• git stash : 임시로 변경사항 저장하기
• git stash pop : 임시 변경사항 불러오기
• git stash list : 임시 변경사항 보기

계정

• git global user.name "user_name" : git 계정 name 저장/수정
• git global user.email "user_email" : git 계정 email 저장/수정

구글에서 제공하는 웹페이지 품질 개선을 위항 오픈 소스 자동화 툴.
성능, 접근성, 권장사항, SEO, PWA 에 대한 검사 가능.

중요 측정 항목

• FCP (First Contentful Paint)
  • 페이지 로드가 시작된 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링되는 시점까지의 시간 측정.
  • 1.8초 이하 권장
  • FCP
• LCP (Lagest Contentful Paint)
  • 페이지가 로드되기 시작한 시점부터 가장 큰 텍스트 믈록 또는 이미지 요소가 화면에 렌더링되는 시점 까지의 시간 측정.
  • 2.5초 이하 권장
  • LCP
• INP (Interaction to Next Paint)
  • 페이지에서 이루어지는 모든 탭, 클릭, 키보드 상호작용의 지연 시간.
  • 상소작용 수를 기반으로 페이지의 최악 상호작용 지연시간을 페이지의 전반적인 응답성으로 판단.
  • INP
• TBT (Total Blocking Time)
  • 사용자가 화면에서 페이지를 이용(상호작용)할 수 있기 전까지 브라우져가 상호작용을 차단하는 시간.
  • 50 ms 권장
  • TBT
• CLS (Cumulative Layout Shift)
  • 레이아웃 변경 횟수.
  • 콘텐츠 로딩으로 인해 사용자가 읽던 위치를 잃거나 잘못된 링크 또는 버튼을 클릭하게 되는 레이아웃의 변경 횟수.
  • 0.1 점 이하 권장
  • CLS
• TTFB (Time to First Byte)
  • 리소스 요청과 응답의 첫 번째 바이트가 도달하는 시작점간의 시간의 측정도.
  • TTFB

결과 요약 항목

• Performance : 웹페이지의 로딩 속도와 같은 성능 측정.
• Accessibility : 접근성 지표 (버튼 간의 간격이나 글 폰트 싸이즈 등)
• Best Practices : 권장 사항을 따라 개발되었는지 확인.
• SEO (Search Engine Optimization) : 검색엔진 최적화 지표.
• PWA (Progressive Web App) : 웹과 네이티브 앱의 기능 모두 이점을 가지도록 만들어진 서비스인지 확인.

아이젠하워 매트릭스

• 업무의 우선순위를 먼저 해야 할 일, 계획해야 할 일, 위임할 일, 하지 않아도 될 일 4단계로 분류

업무 우선순위

1. 자신의 업무를 모두 나열
2. 각 업무의 긴급성과 중요도 판단
3. 업무를 4개의 카테고리로 분류
   1. 긴급하고 중요한 일 - 먼저 해야할 일
   2. 긴급하지 않지만 중요한 일 - 계획해야 할 일
   3. 긴급하지 않지만, 중요하지 않은 일 - 위임할 일
   4. 긴급하지도, 중요하지 않은 일 - 하지 않아도 될 일
4. 아이젠하워 매트릭스에 따라 우선순위 확인하고, 일정 계획

아이젠하워 매트릭스

1. 중요하고 급한 일 - 먼저 한다
   명확한 결과가 따르며 장기 목표에도 영향을 주는 업무로서, 가장 먼저 해야 하는 업무입니다.
   이 카테고리 안의 업무들은 미루지 않고 바로 처리하는 것이 좋습니다.
2. 중요하지만 급하지 않은 일 - 계획한다
   장기 목표에 영향을 미치지만 당장 처리하지 않아도 되는 일입니다.
   긴급하지 않기 때문에 신중하게 준비하고 계획하여 완성도를 높일 수 있습니다.
   중요하고 급한 일을 해결한 뒤 이 카테고리 안의 업무를 처리합니다.
   이 업무들을 마냥 미뤄두지는 않도록 주의해야 하며, 집중력을 발휘하여 수행할 수 있도록 합니다.
3. 중요하지 않지만 급한 일 - 위임한다
   바로 처리되어야 하지만 장기 목표에는 영향을 미치지 않는 업무입니다.
   이러한 업무는 에너지 소모가 많지만 특별한 기술은 요하지 않는 잔업인 경우가 많습니다.
   꼭 본인이 직접 하지 않아도 되는 일이기 때문에, 다른 사람에게 위임하거나 대체 시스템을 마련하도록 합니다.
4. 중요하지도 급하지도 않은 일 - 하지 않는다
   목표를 달성하는 데 방해가 되는 일입니다.
   업무 목록에서 삭제하도록 합니다.

긴급한 일과 중요한 일을 구별하는 법

• 긴급한 일
  • 즉시 해야 하는 일로, 기한 안에 처리하지 못하면 명확한 결과가 나타납니다.
    • 예) 기한이 임박한일, 장애, 긴급 지시사항, CS 이슈 등
• 중요한 일
  • 당장 하지 않아도 되지만, 장기적인 목표에 도움이 되는 일입니다.
    • 예) 신 기능 스터디, 프로젝트 계획, 3rd Party 솔루션 도입

참고자료

https://1891ghaon.tistory.com/117

업무의 우선순위 7단계

1. 모든 업무가 포함된 하나의 작업 목록을 만들기
   1. 효과적으로 우선순위 정하는 첫 단계는 업무의 전체 범위를 파악하는 것부터 시작합니다.
   2. 모든 업무가 기록되면 각 업무의 중요성, 긴급성, 소요 시간, 보상을 적습니다.
2. 중요한 사항 식별하기 : 진정한 목표 이해하기
   1. 우선순위를 정하는 일은 즉각적인 '시간 관리 전략'처럼 보일 수 있지만 장기적인 '목표 달성 전략'이기도 합니다.
   2. 설정된 목표(큰 그림)를 위해 자신이 어떤 일을 하고 있는지 이해해야 미래 결과와 가장 관련이 있는 업무를 파악할 수 있습니다.
   3. 최종 목표에 영향을 주지 않는 작업으로 하루를 채우는 것은 시간 낭비입니다.
      항상 목표를 염두해 두고 있어야 합니다.
3. 긴급한 사항을 강조 표시하기
   • 할 일 목록에서 마감일이 눈에 띄도록 하면 신속하게 완료해야 하는 작업을 알 수 있습니다.
   • 공식적으로 필요하지 않은 경우에도 마감일을 설정해야 합니다. 그렇지 않으면 중요한 작업을 계속 미루게 될 것입니다.
4. 중요성 및 긴급성을 바탕으로 우선순위를 정한다.(아이젠하워 매트릭스)
   • 중요하고 긴급한 일 : 먼저 수행합니다.
   • 중요하지만 긴급하지 않은 일 : 전략적 계획을 세우고 완료일을 정합니다.
   • 긴급하지만 중요하지 않은 일 : 일을 축소하거나 권한을 위임합니다.
   • 긴급하지도 중요하지도 않은 일 : 할 일 목록에서 삭제합니다.
5. 우선순위가 겹치는 것은 피한다
6. 한 번에 하나의 중요한 작업에 집중해야 합니다.
   여러 가지의 우선 순위를 계속 시도하고 관리하는 것은 성과 저하로 이어집니다.
7. 시간과 노력을 고려한다
8. 할 일 목록이 너무 많아 부담스럽다면 최소한의 시간과 노력이 드는 작업에 우선순위를 두고 신속하게 진행하세요.
   작업을 정리하면 여유와 함께 작업을 추진할 수 있는 성취감이 생깁니다.
9. 끊임없이 검토하고 현실을 반영해라
10. 업무 목록과 우선순위를 자주 검토하는 것이 '통제력 및 집중력 유지'에 중요합니다.

참고자료

• https://www.jobindexworld.com/contents/view/6918

인터넷 속도를 측정하기 위해서 fast.com등 여러 사이트를 이용한다.

맥 터미널에서 명령어 하나로 간단하게 인터넷 속도를 측정할 수 있다.

networkQuality

윈도우를 사용하는 분들과 협업을 하다보면 윈도우에서 작성된 텍스트 파일이 UTF-8이 아닌 MS-949 (CP-949) 인코딩으로 작성된 파일을 받을 때가 있다. 국제 표준인 UTF-8을 이용해 주시면 감사하겠지만, 어쩔 수 없이 내가 인코딩을 변경 해 줘야 한다.

CP-949에서 UTF-8로 인코딩을 변경하는 것은 터미널에서 간단하게 처리 할 수 있다.

iconv -c -f {원본 인코딩} -t {변환 인코딩} {원본 파일} > {저장 파일}

MIXIN

• mixin in wikipedia
• mixin from JS
• mixin from dart
• mixin from vue
  • 1
  • 2