노션(Notion)은 프로젝트 관리 및 기록 소프트웨어이다. 회사의 구성원을 돕고 조직의 효율성과 생산성을 높이기 위해 마감일, 목표 및 과제를 조정하도록 설계되었다.

사건의 발단

노션을 쓴지도 벌써 2년째..! 위코드에서 개발을 배울 때 처음 접하며 사용하게 된 툴이다. 요즘엔 개발,디자인뿐만 아니라 많은 직군에서 사용하고 학생들도 많이 애용한다고 한다.

사실 노션을 보기좋게 꾸미고 관리하는거에 관심이 없었고 노션 자체의 템플릿이 아주 잘 나와서 칸반보드로 task나 workflow관리, 회의 스케줄 관리, develop wiki 같은 회사 업무 관련된 템플릿이나 포트폴리오 작성은 노션을 이용했지만 그 외 개인 일정이나 개인 task로 사용하지 않았다.

개발자답지않게 아날로그 인간이라서 그런지 몰스킨으로 불렛저널 손으로 쓱쓱 그려서 관리하는게 더 마음이 편했다. 껄껄,,.

그러다 우연히 개발 블로그에서 블로그 주인분이 노션을 커스터마이징한걸 봤는데...와우...

제가 쓰는 툴이랑 같은거 맞나요..? 뭐 유료버전 있는거 아니죠...

갑자기 툴 자체를 100% 활용하지 못하고 있다는 생각에 제대로 회의감 느끼고 본격 구글링에 돌입했다.

일단 다른 사람들이 꾸민 레퍼런스를 보고 싶어서 핀터레스트에 검색을 했는데 그만 알아보자.... 괜히 검색했다가 상처만 얻고 말았읍니다... 꾸미기 재능없을무...인가요....힝입니다...

저렇게 어메이징한 디자인을 바라진 않지만 그래도 내 기록,일기장으로 쓰려면 조금은 이뻐야 하니까 (자주 쓰는건 비싸고 이쁘고 맘에 들어야 한다는 곤조) 조금은 열정을 가지고 꾸며보자..!하띵...!!

사건의 해결책

widget으로 사기치자

indify

상단에는 내가 이미 커스텀한 위젯들이 뜨고 그 아래로 스크롤하면

indify에서 제공하는 위젯 커스텀 리스트가 뜬다.

나는 여기서 Button,Clock,Quotes 위젯을 만들었다.

Button

위 페이지에서 버튼을 클릭하면 타이틀을 정하는 모달창이 뜬다. 이름을 정해주면

버튼을 생성하는 페이지로 이동된다. 여기서 버튼의 아이콘과 이름을 정하고 원하는 컬러를 정한후 버튼의 링크를 기입하면 된다. advanced colors를 누르면 백그라운드와 아웃라인 컬러도 지정 할 수 있다. 또 Add button을 누르면 버튼이 추가로 생성되니 한 페이지에서 여러개를 만들수 있다. 더 아래로 스크롤을 하면 style 변경이 가능하다. 글씨체, 보더 라운딩정도, layout 등을 바꿀수 있다.

버튼 컬러는 지정 되어 있는 컬러에서만 고르고 마음대로 커스텀 못해도 style에 있는 옵션은 세세하게 바꿀수 있다.

내가 제일 좋았던건 다크모드!! 노션을 다크모드로 사용하고 있는 나는 하얀배경으로 내 노션을 망치고 싶지 않았기에(잘꾸미고 있던척) 이런 세심함이 감동 포인트였다.

요즘 제일 많이 이용하는것들 버튼으로 만들고 버튼위젯은 완성!

Clock

마찬가지로 title 정해주면 커스텀 페이지로 넘어간다. 시계 타입 옵션이 이렇게나 다양합니다,여러분!! 여기서 타입 고르고 아래에서 세세한 디자인을 할 수 있다. 나는 24h가 편하니까 체크하고 컬러는 요즘 오렌지에 꽂혀서 오렌지로~ 역시나 다크모드 적용하면 완성!

Quotes

타이틀 지정하고 넘어가면 커스텀 페이지로 이동한다.

이름답게 인용구들을 보여주는데 약간 life quotes로 생각하면 될 거 같다. 인생 명언,격언 느낌

옵션창을 누르면 여러 인스타그램이 나온다. 여기서 마음에 드는 인스타를 고르면 그게 내 위젯이 된다.

이왕 만드는거 내 타입으로 만들고 싶어서 하나하나 인스타에 검색했다.

이 분은 본인 사진이 너무 많아서 잘못 검색한줄 알고 당황했다🫥 피드를 더 보니까 하얗고 검은데 소소한 일러스트까지 오 약간 내 취향

내 픽은 rupikaur_ 너로 정했다!

노션에 적용하기

위젯을 만들면서 나오는 좌측칸 하단에 링크가 만들어졌을거다. 그걸 카피하고 노션으로 넘어간다. 기본 블록에서 임베드를 선택하면 링크 임베드가 뜬다. 입력창에 방금 카피한 링크를 넣어주면 끝~~!

Widgetbox

widgetbox 첫 페이지! 일단 뭐가 되게 많다. 근데 상단 세 개 말고는 업그레이드를 해야만 이용 가능하다. 뭐가 많아 근데 못생겼어. 유치해. 별로 안만들고 싶은데? 싶은 첫 인상 그치만 선입견 안돼 마인드로 Calender 만들기 돌입! 만들면서 첫 인상 평가 그지같이 한 거 후회 했읍니다. 넘이뻐.,,.이제 우리 위젯박스임

Calender

만들고 싶은 위젯 보드를 선택하면 indify와는 다르게 한 페이지에서 타이틀도 정하고 디자인까지 한다.

컬러,보더,보더라운드 모두 커스텀 가능하다. 근데 제가 뭐라고 했읍니까, 이제 우리 위젯박스라고 했읍니다. 그 이유는 바로 컬러...!!!! 컬러 픽커가 진짜 잘되어있다.. HEX값 직접 입력도 가능하고 첫 사진의 옵션에서 컬러하나 누르면 세세하게 컬러 조정도 가능하다. 최고야 진짜~ 마찬가지로 다크모드도 지원하니까 두 배로 좋다~~

노션에 적용하기

좌측 하단에 생긴 링크를 카피하고 노션 페이지로 넘어간다. 기본 블록에서 임베드를 선택하면 링크 임베드가 뜬다. 입력창에 방금 카피한 링크를 넣어주면 끝~~!

사기 적용샷

핀터레스트나 구글에서 보던 분들에 비하면 뭐 없지만 일단 위젯의 존재도 알았고 사용법도 알았으니 이것저것 만지면서 꾸며봐야지~ 몰스킨은 포기 못하지만 그래도 노션도 잘 이용 해봐야겠다!

🚨 Access to fetch at ‘https://api.lubycon.com/me’ from origin ‘http://localhost:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

개발자라면 한 번쯤은 만날 CORS ERROR

이번 서비스를 구축하면서 날 제일 힘들게 한 건 이 에러가 아닐까 싶다🫠 백엔드 개발을 다 마치고 프론트랑 연결하는 작업을 진행중인데 프론트엔드 개발자 분이 계속 이 에러가 뜬다고 하셨다.

Django Rest Framework를 사용해서 개발중인 나는 django-cors-headers도 install하고 settings에도 다 추가하고 할 수 있는 처리를 다 했음에도 계속 같은 에러가 떠서 혼돈 그 자체였다

포스트맨이나 브라우저 상에서 접근하는건 가능하지만 프론트엔드에서 버튼을 클릭해서 함수로 접근하면 안된다? 이게 무슨 홀리ㅅ..같은 경우인가 흐엉

구글링을 하고 이것저것 유추를 해본 결과 우리는 ngrok을 이용해서 포트포워딩을 하고 그 포트포워딩이 된 주소로 테스트를 돌리고 있었다.

그게 문제였던거 같다! ngrok은 자동으로 https 처리를 해주는데 그걸로 인해 cors error가 생기는 문제였다!

사실 이게 맞는지도 잘 모르겠다! 이것저것 시도하고 django에서 ssl처리를 했는데도 안돼서

EC2에 gunicorn으로 배포를 한 후 테스트를 할 때는 너무나 잘 되는걸 보니 문제는 저거였구나라고 유추하는거일뿐...

험난하고 어려운 개발자의 길 화이팅,,,..

Secure tunnels to localhosts : 방화벽 넘어서 외부에서 로컬에 접속 가능하게 하는 터널 프로그램

Djano를 이용해 만든 서비스의 테스트를 위해 외부에 공개해야 하는 경우가 생겼다. 포트포워딩 방법을 찾다가 많이들 사용하는 공유기를 이용한 포트포워딩을 사용하려고 했는데 회사가 공유오피스를 사용하여 그 방법은 불가능 하다는 결론이 나서 다른 방법을 찾다가 ngrok을 발견했다.

사용방법

설치

brew install ngrok/ngrok/ngrok

가상환경에 접속하여 brew install 했다.

token발급

공식 사이트에 들어가 회원가입을 하면 토큰을 준다. 발급을 받는다. 터미널에 명령어를 입력한다.

ngrok authtoken <token>

runserver

여기서 오류가 한 번 났었다.

ngrok http 8000

ngrok로 냅다 열었더니 runserver가 되지 않았다. 원인은 django runserver를 안해서였다.

순서는 djaogn runserver -> ngrok 포트 열기 이 순서로 진행해야 한다.

django를 기반으로 REST API 서버를 만들기 위한 라이브러리 API는 웹뿐만 아니라 앱과 같은 다양한 플랫폼의 백엔드 서비스를 위해 JSON과 같은 규격화된 데이터를 제공한다. 결국 DRF를 사용하면 기존 자체적인 웹템플릿에게 바로 데이터를 전달해 주었던 django 프로젝트에서, JSON과 같은 양식으로 다양한 플랫폼의 클라이언트에게 데이터를 제공해줄 수 있는 API 서버 프로젝트가 만들어지게 되는 것이다.

Django REST Framework 설치 및 실행

pip install djangorestframework===version

django와 동일하게 pip install을 통해 설치한 후

setting.py에 app 등록을 한다.

Django에서 달라진 점

DRF는 Response를 제공한느 API의 형태로 결과물이 나온다. 그렇다는건 django에서 만들었던 템플릿의 형태가 아닌, JSON과 같은 형태의 응답을 제공할 텐데 그렇다는건 템플릿을 대신할 무언가가 필요하다는 것이다. 기존 뷰에서 템플릿으로 데이터를 제공했다면 DRF에서는 serializer가 그 역할을 수행한다.

방법1

PostSerializer에서 PostFile을 보여주기 위해 nested serializer를 사용했다.

보이지 않는다.

방법2

코드를 수정해보겠다. PostFileSerializer의 fields에서 postfile -> postfile_set으로 변경했다.

file의 아이디가 보인다.

방법3

이번에는 SerializerMethodField()를 사용해봤다.

원하는대로 출력된다.

1번은 왜 안되는걸까?🫠

개념

Partition

논리적인 데이터 element를 다수의 entity로 쪼개는 행위

즉 큰 table이나 index를 관리하기 쉬운 partition이라는 작은 단위로 물리적인 분할을 하는 것을 의미한다. 물리적인 데이터 분할이 있더라도 DB에 접근하는 application의 입장에서는 이를 인식하지 못한다.

배경

• 서비스의 크기가 점점 커지고 DB에 저장하는 데이터의 규모 또한 대용량화 되면서, 기존에 사용하는 DB 시스템의 용량(storage)의 한계와 성능(perfomance)의 저하를 가져오게 되었다.
• 즉, VLDB(Very Large DBMS)와 같이 하나의 DBMS에 너무 큰 table이 들어가면서 용량과 성능 측면에서 많은 이슈가 발생하게 되었고, 이런 이슈를 해결하기 위한 방법으로 table을 '파티션(partition)'이라는 작은 단위로 나누어 관리하는 '파티셔닝(partitioning)'기법이 나타나게 되었다.
• '파티셔닝(partitioning)'기법을 통해 소프트웨어적으로 데이터베이스를 분산 처리하여 성능이 저하되는 것을 방지하고 관리를 보다 수월하게 할 수 있게 되었다.

목적

1. 성능(Performance)

• 특정 DML과 Query의 성능을 향상시킨다. 주로 대용량 Data WRITE 환경에서 효율적이다. 특히, Full Scan에서 데이터 Access의 범위를 줄여 성능 향상을 가져온다. 많은 INSERT가 있는 OLTP 시스템에서 INSERT 작업을 작은 단위인 partition들로 분산시켜 경합을 줄인다.

2. 가용성(Availability)

• 물리적인 파티셔닝으로 인해 전체 데이터의 훼손 가능성이 줄어들고 데이터 가용성이 향상된다. 각 분할 영역(partition별로)을 독립적으로 백업하고 복구할 수 있다. table의 partition 단위로 Disk I/O을 분산하여 경합을 줄이기 때문에 UPDATE 성능을 향상시킨다.

3. 관리용이성(Manageability)

• 큰 table들을 제거하여 관리를 쉽게 해준다.

DB 파티셔닝(Partitioning)의 장단점

장점

관리적 측면

• partition 단위 백업, 추가, 삭제, 변경 전체 데이터를 손실할 가능성이 줄어들어 데이터 가용성이 향상된다. partition별로 백업 및 복구가 가능하다. partition 단위로 I/O 분산이 가능하여 UPDATE 성능을 향상시킨다.

성능적 측면

• partition 단위 조회 및 DML수행 데이터 전체 검색 시 필요한 부분만 탐색해 성능이 증가한다. 즉, Full Scan에서 데이터 Access의 범위를 줄여 성능 향상을 가져온다. 필요한 데이터만 빠르게 조회할 수 있기 때문에 쿼리 자체가 가볍다.

단점

• table간 JOIN에 대한 비용이 증가한다.
• table과 index를 별도로 파티셔닝할 수 없다. table과 index를 같이 파티셔닝해야 한다.

• https://docs.djangoproject.com/en/4.0/howto/deployment/
• https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/#run-manage-py-check-deploy

배포 환경에서는 보안을 위해 secret-key,debug,allowed-hosts,databases를 변경하는게 좋다고 나와있다.

이번 프로젝트를 위해서 나는 위의 네가지를 바꾸기로 했다.

1.settings.py 분리를 위해 먼저 package 폴더를 만든다.

폴더의 구조는 아래와 같이 만든다.

⭐️ package 폴더(디렉터리) 안에 init.py 파일이 있으면 해당 폴더는 패키지로 인식된다. 그리고 기본적으로 init.py 파일의 내용은 비워 둘 수 있다.⭐️ (참고:https://dojang.io/mod/page/view.php?id=2449)

base.py에는 공통 항목 develop.py에는 개발모드에서만 필요한 항목 product.py에는 운영모드에서만 필요한 항목

2.기존의 settings.py의 위치를 settings 폴더로 이동하고 이름을 변경한다.

파일의 위치가 변경 되었으니 base_dir도 수정해준다.

개발모드와 운영모드에서 다르게 설정할 항목들은 base.py에서 삭제해야한다.

위에서 언급한 secret-key,debug,allowed-hosts,databases 항목들 각각 삭제해주고 각 모드의 파일에 추가한다.

개발모드 (develop.py)

운영모드 (product.py)

운영모드에서는 추후에 배포하면 allowed host 부분을 수정해주어야한다. 또한 민감한 정보들은 환경변수 처리를 해준다.

3. settings.py 를 호출하는 부분을 변경한다.

개발모드에서는 manage.py에서 호출하고 운영모드에서는 wsgi.py에서 호출한다.

manage.py 수정

product.py 수정

django 공식 홈페이지 https://docs.djangoproject.com/en/dev/topics/auth/customizing/#a-full-example

참고 페이지 https://dev-yakuza.posstree.com/ko/django/custom-user-model/

컬럼 변경이 없는 경우 Proxy 컬럼 변경이 있고 기본 User 테이블을 사용하는 경우 Profile 컬럼 변경이 있고 별도의 인증 테이블을 생성하는 경우

• 인증 컬럼으로 username 컬럼 사용하면 Abstract User
• 인증 컬럼으로 username 컬럼 사용 안하면 Abstract BaseUser

Virtual Environment이란 가상환경을 말한다. 가상 환경은 독립된 공간을 만들어주는 기능

가상환경을 사용하는 이유

• 파이썬 가상환경을 사용하는 이유는 여러 프로젝트를 진행하는데 있어,분리된 버전 및 패키지 설치 환경을 가질수 있기 때문이다.
• 예를 들어, 하나의 로컬환경에서 파이썬 가상환경 없이 A라는 파이썬2 기반의 장고1.5 버전 프로젝트를 진행하고 그에 필요한 다양한 라이브러리들을 pip를 사용하여 설치했다고 가정했을때 A프로젝트를 진행하는 중에 B라는 파이썬3 기반의 장고2.2 버전 웹개발 프로젝트를 작업하라는 지시를 받았다. 그렇게 되면 사용자는 동시에 필요한 패키지 및 언어의 버전을 모두 설치하고 수동으로 관리해야 하는 어려움이 발생한다.
  이때 가상환경을 사용하면 각 프로젝트별로 독립적인 파이썬 버전 및 라이브러리가 설치된 개별적인 환경을 가지게 된다. 이는 개발 도중에도 편리하지만 나중에 배포 관리를 하는데 있어서도 편리하다.
• 그리고 시간이 지남에 따라 패키지들이 업데이트되는데, 이것저것 업데이트를 하다 보면 서로 의존적인 패키지들 사이에 버전이 맞지 않아 호환이 되지 않는 경우들이 생긴다. 그렇다고 특정한 프로젝트 하나를 위해 언제 지원이 끊길지 모르는 예전 버전의 패키지를 로컬에 계속 유지할 수도 없고, 패키지가 업데이트되어 호환성 문제가 생길 때마다 프로젝트의 코드를 일일이 수정하는 것도 실질적으로 불가능하다.

가상환경 선택

• 파이썬의 대표적인 가상환경 프로그램은 conda와 virtualenv가 있다.
• conda는 미니콘다(Miniconda)와 아나콘다(Anaconda)로 나뉜다. 아나콘다는 수학과 과학 분야에서 사용되는 여러 패키지들을 묶어놓은 파이썬 배포판에 포함되어 있는 패키지 매니저이자 가상환경 관리 프로그램이다.
• 아나콘다는 기존 파이썬에 비해 매우 용량이 크지만 데이터 분석을 위한 다양한 라이브러리를 갖춘 파이썬을 배포한다. 아나콘다는 가지고 있는 라이브러리의 용량이 크고 과정상 필요하지 않은 것들이 많아 파이썬이나 패키지에 익숙하지 않은 비개발자에세 추천한다. 나는 프로젝트 진행시 미니콘다를 선택하여 사용하였다.

미니콘다 설치

• 미니콘다 설치프로그램 다운로드

#Mac 버전
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-MacOSX-x86_64.sh

#Ubuntu 버전
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh

chmod -R 755 Miniconda3-latest-Linux-x86_64.sh

./Miniconda3-latest-Linux-x86_64.sh

• 설치는 위와 같이 명령어를 수행 후 진행한다.

• wget 명령어가 실행이 안 될 경우, 아래와 같이 Mac / Ubuntu에 따라 brew / apt 명령어를 실행한다.

미니콘다 명령어

• conda 가상환경 목록을 보는 명령어

conda env list

• conda 가상환경 만들기

#파이썬3 버전의 환경만들기 
conda create -n "가상환경이름" python=3.8

• conda 내가 만든 가상환경으로 활성화하기

conda activate "가상환경이름"

• conda 실행된 가상환경 비활성화하기

conda deactivate

• conda 가상환경 삭제하기

conda env remove -n "가상환경이름"

• conda 가상환경 익스포트하기(배포용 yaml만들기)

conda env export> "가상환경이름.yaml"

• conda 익스포트한 가상환경 임포트하기

conda env create -f "가상환경이름.yaml" 

• 가상환경명은 프로젝트 명으로 통일하는 것으로 권장한다.

HITS에서는 기존에 분자 구조와 합성을 CLI를 통해 진행하였다. 근데 그 진행 방법은 전공자만 이해할 수 있는 방법으로 비전공자와 직무에 종사하고 있지 않은 사람들은 확인하기 어렵고 접근 자체가 어렵다는 단점이 있었다.

분자를 합성하고 구조물을 확인하기 위해 프로그램을 구매하는 사람들은 전공자나 직무 관련자도 있지만 그렇지 않은 사람도 존재하기에 좀 더 진입장벽이 낮은 GUI로 구현하기로 하였다.

나는 유저가 분자 구조를 문자나 파일 형태로 올리면 그것을 백엔드 API로 연결하여 받아온 정보를 유저에게 보여주는 작업과 로그인,로그아웃 등의 프론트엔드 전반과 백엔드 일부를 담당하였다.

프로젝트를 진행하며 배운 점과 어려웠던 점, 회고를 늦었지만 글로 남기며 복기하려고 한다.

• 프레임워크
• 상대적으로 낮은 러닝커브
• 생산성이 뛰어남
• 친절한 공식문서
• 가볍고 빠른 개발에 추천
• template, script, style로 구성된 Single File Component
• typescript 지원이 완벽하지 않다
• 사용성과 생산성이 높다
• 양방향 데이터플로우(단방향도 가능)
• virtual DOM

장점

• 점진적인 프레임워크 : 라이브러리 기능 + 프레임워크 기능

    - 라이브러리 기능 : 화면단 데이터 표현에 관한 기능들을 중점적으로 지원
    - 프레임워크 기능 : 라우터, 상태관리, 테스팅 등을 쉽게 결합할 수 있는 형태로도 제공

• Template과 Render Function을 모두 사용할 수 있는 옵션

• 간편한 Syntax와 프로젝트 설정

• 빠른 렌더링과 더 작은 용량 두 라이브러리가 어떻게 application data(state)를 처리하는지 살펴보면:

    this.setState({
    message:this.state.message.split('').reverse().join('')
    });

  React에서 state는 불변의 속성을 갖는다. 그래서 직접적으로 변경 X. 만약, 상태를 변경하고 싶다면 위 처럼 setState()를 사용해야한다. 현재와 이전 상태를 비교해 언제, 어떻게 다시 DOM을 렌더링 할 지 결정하기 때문에 불변하는 속성이 필요하다.

반대로, Vue에서 data는 변경될 수 있다.:

this.message = this.message.split('').reverse().join('');

state에 새로운 객체를 추가했을 때, Vue가 해당 객체의 모든 속성을 확인하고나서 getter, setter로 변환한다. Vue의 reacivity system이 모든 상태를 모니터링하여 변경이 일어날 때마다 자동으로 DOM을 다시 렌더링한다.

더 인상적인 부분은 Vue에서 state를 간단하게 변경할 수 있을 뿐만 아니라, Vue의 렌더링 시스템이 React보다 빠르고 더 효율적인 부분이다.

React

• 라이브러리
• 전역 상태 관리, 라우팅, 빌드 시스템 지원 안함 (라이브러리)
• 뷰보다 세세하게 컴포넌트화하여 재사용성 높음
• typescript 지원
• 트랜드와 범용성이 높다
• 선언형
  • 선언형과 명령형
• 단방향 데이터플로우
  • 데이터가 UI로 흐르는 구조. 데이터가 변했을때 UI가 업데이트 된다.
• virtual DOM

장점

• Component를 사용해서 효율적으로 재사용이 가능하고 유지보수가 용이
  • Component는 UI를 구성하는 개별적은 뷰 단위로 전체 앱은 각 Component들이 결합해서 만들어지게 되는데 무엇보다 각 Component들은 앱의 다른 부분, 또는 다른 앱에서 쉽게 재사용이 가능하다. React의 목표는 성능보다는 유지 가능한 앱을 만드는 것.
• 생태계가 넓고 다양한 라이브러리 사용 가능
  • Vue에 비해 사용자가 많고 facebook에서 만든 만큼 커뮤니티와 자료가 방대함
• 라이브러리이기 때문에 다른 프레임워크나 라이브러리와 혼용 가능
  • 다른 프레임워크나 라이브러리와 함께 사용할 수 있고 이미 개발된 서비스에서도 일정 부분에서만 선택적으로 적용이 가능하여 단계적으로 React로의 변경이 가능함
• virtual DOM을 활용하여 빠른 렌더링이 가능하다
  • DOM은 브라우저가 화면을 그리기 위한 정보를 담고있는 문서 객체이다. JQuery처럼 실제 DOM을 변경할 경우, 변경할 부분이 일부분이더라도 DOM 전체를 다시 렌더링 해야하고, 이는 성능 저하로 직결 된다는 단점이 있다. React는 렌더링 시 virtual DOM, 즉 가상 DOM을 먼저 만든다. 그 후 실제 DOM과 비교를 하여 변경이 있는 부분(하위 컴포넌트)만 대체를 하기 때문에 리소스 낭비를 줄일 수 있다.
  • virtual DOM 브라우저 렌더링
• 단방향 데이터 바인딩을 통함 디버깅 용이(다른 라이브러리에 비해 안정성이 높음)
  • react 내에서의 데이터의 흐름은 부모(parent)에서 자식(child)으로 단방향적이다. 그렇기 때문에 디버깅이 용이하며 다른 라이브러리에 비해 안전성이 높다.
• 리액트 네이티브를 활용하여 앱 개발 가능
  • 리액트 네이티브는 네이티브 모바일 앱을 만들기 위한 프레임워크로서 리액트를 기반으로 개발되었다. 리액트 라이브러리가 웹 개발자나 하이브리드 앱 개발자에게 유용하고 관심을 끌게 하는 기술이라면 리액트 네이티브는 모바일 개발자들이 몹시 주목할 기술이다.

단점

• 프레임워크의 MVC 패턴과 비교하였을때 V(view)만을 관리한다.
  • View 부분만을 관리하기 때문에 다른 부분은 써드파트 라이브러리(third party library)를 이용하거나 직접 구현해야한다.
• 진입장벽이 낮지 않다
• 단점(모듈)

React를 선택해야 하는 경우

• 빠른 일정 안에 엔터프라이즈 수준의 가벼우면서도 현대적인 애플리케이션을 개발해야 할 때
• 웹 사이트 개발 솔루션을 안전하게 보호할 수 있는 유연한 프레임워크가 필요할 때
• 크로스 플랫폼(cross-platform) 애플리케이션이나 싱글 페이지 애플리케이션(SPA)을 개발할 때
• 기존의 앱에서 기능성을 확장할 때
• 강력한 커뮤니티 지원과 솔루션이 필요할 때

Vue를 선택해야 하는 경우

• 시장 진입 단계에서 필요한 프레임워크를 선택할 때
• 작고 가벼운 애플리케이션을 개발할 때
• 기존의 프로젝트에서 현대적이지만 제한된 리소스를 가진 프레임워크로 마이그레이션을 해야할 때
• 기업이 아니라 사용자 커뮤니티의 지원을 받는 프레임워크를 원할 때

필요에 따른 선택

Vue.js와 React는 모두 대화 형 사용자 인터페이스를 구축하기위한 훌륭한 도구이다. 다음 프로젝트에 더 적합한 것을 선택하려면 특정 사용 사례, 비즈니스 요구 사항, 환경, 개발자 가용성, 예산 및 작업중인 기간을 포함하여 여러 요소를 고려해야한다.

Vue는 가볍고 배우기 쉽고 작성하기 쉽다. 친숙한 템플릿 구문과 구성 요소 사용으로 인해 기존 프로젝트를 Vue로 통합하거나 마이그레이션하는 것이 더 빠르고 원활하다. 이러한 이유로 Vue.js는 스타트 업에 적합하지만 대규모 애플리케이션에서도 잘 사용될 수 있다.

Vue에는 상태 관리, 라우팅 또는 서버 측 렌더링을위한 공식 패키지가 있으며,이 패키지는 최신 지원과 함께 시스템 전체에서 동기화를 보장한다. Vue CLI 4 및 Vue UI를 사용하면 프로젝트를 설정하고 배포를 준비하는 것이 매우 빠르다. 이를 통해 빠르고 효율적인 방식으로 MVP를 구축 할 수 있다.

반면 React는 JS 분야의 베테랑이다. 기업 지원, 대규모 커뮤니티 및 더 큰 에코 시스템을 갖춘 React는 복잡한 엔터프라이즈 급 애플리케이션 을 구축하는 데 적합하다. 또한 숙련 된 React 개발자로 인해 취업 시장이 호황을 누리고 있으므로 전문가가 부족하지 않을 것이다. 성숙도와 커뮤니티이기 때문에 도움을 요청하고 신속하고 상세한 답변을 얻는 것이 어느 정도 보장된다.

React는 oven (오븐) 이다. 케이크를 굽는 과정에서 분명히 추가적인 tools가 필요하지만 이것은 필요한 것을 만드는 과정에서 tools를 선택하는 유연함을 줄 수 있다. 내가 기술적인 회사에서 능력있는 몇몇 senior 개발자들과 함께 일을 하고 있다면 React는 좋은 선택이다.

Vue는 쉽고 효율적인 방법으로 요리를 정말 빠르게 만들 수 있다. 만약 startup 회사에서 새로 생긴 팀에서 엄격한 deadline을 가지고 있다면 나는 VueJS를 좋아할 것이다.

Call Stack

call stack은 함수의 호출을 저장하는 자료구조이다. 어떤 함수를 호출하면 스택에 쌓고 또 다른 함수를 호출하면 그 다음 스택에 쌓으면서 가장 위에 쌓은 함수를 먼저 처리한다.

var func1 = () => {
  func2();
  console.log('Call func1');
}
var func2 = () => {
  func3();
  console.log('Call func2');
}
var func3 = () => {
  console.log('Call func3');
}
func1();

//return
//Call func3
//Call func2
//Call func1

가장 늦게 호출하여 위에 쌓인 함수가 가장 먼저 호출되어 출력된다.

Call Stack은 싱글 스레드이기 때문에 하나만 존재한다.즉,한 번에 하나의 일만 한다. 프로그램의 어느 위치에 있는지를 기록하는 자료구조. 스택에서 실행되는 함수가 처리 되는데 긴 시간이 걸린다. 그로인해 다른 작업을 할 수가 없으므로 브라우저가 멈추게 된다. 이와 같은 현상을 해결하기 위해 비동기 콜백을 사용하고, 그 도움을 주는 요소들이 바로 event queue, event loop이다.

Memory Heap

memory Heap은 객체를 저장하는 곳이다. 예제에서 선언한 함수 func1,func2,func3는 모두 Memory Heap에 저장된다.

Web API

web API는 브라우저에서 제공하는 API들이다.

Callback Que

Callback Que는 함수를 저장하는 자료구조이다. 콜백함수나 비동기적으로 실행되는 함수들이 쌓여 호출되기를 기다리는 공간이다. 보통 Web API와 연계되어 인자로 넘어간 콜백 함수들이 추가된다. (Web API는 우리가 아는 DOM,AJAX,setTimeOut 같은 호출만 가능한 함수들이 있다. 즉,AJAX를 이용해 통신을 한다고 하면 인자로 넘긴 콜백함수가 AJAX의 함수가 실행되고 난 뒤에 이벤트 큐에 추가되는 방식이다. Call stack과는 다르게 가장 먼저 들어온 함수를 먼저 처리한다. 특정 이벤트에 따른 콜백 함수를 정의하면, 콜백 함수는 Callback Que에 저장된다.

Event Loop

Evnet Loop는 call stack이 다 비워지면 callback que에 존재하는 함수를 하나씩 호출 스택으로 옮기는 역할을 한다. 콜 스택이 비어있고 이벤트 큐에 작업이 있으면 제일 앞에 있는 작업을 콜스택에 추가한다. 이러한 반복을 tick이라고 한다.

Example

var func1 = () => {
  setTimeout(()=> {
    console.log('2초 뒤에 실행하는 콜백함수')
  },2000);
}
var func2 = () => {
  for (var i=-; i<8000000000; i++){
  }
  console.log('약 5초가 걸리는 함수')
}
func1();
func2();

//return
//약 5초가 걸리는 함수
//undefinded
//약 2초 뒤에 실행하는 콜백함수

약 5초 뒤에 '약 5초가 걸리는 함수'라는 문자열이 출력되고 바로 이어 '2초 뒤에 실행하는 콜백함수'라는 문자열이 출력된다.

출처1 출처2

애자일은 기민한, 좋은 것을 빠르고 낭비없게 만든다는 뜻이다. 구체적인 개발 프로세스가 아닌 개발 지침, 철학에 가깝다.

‘애자일(Agile)’이란 용어는 소프트웨어 개발 방식의 하나로 통용되던 말이다. 작업 계획을 짧은 단위로 세우고 시제품을 만들어 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론이다. 이와 반대되는 개념이 전통적 개발 방법론이라 할 ‘워터폴(Waterfall) 방식’이다. 우리 기업에 익숙한 이 방식은 장기적 관점에서 계획을 정교하게 세우고 사전에 단계별로 정해놓은 기준을 충족하지 않으면 다음으로 넘어가지 않는 특징이 있다.

변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적 개발 방법으로 문서화보다 코드, 프로그램, 소프트웨어 자체를 중요시 한다. 환경의 빠른 변화에 대응하는 것이 중요하다.

애자일 선언문(Agile Manifesto)

프로세스와 툴보다 개인과 개인간의 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를

개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선 작동하는 소프트웨어가 포괄적인 문서보다 우선 고객과의 협업이 계약 협상보다 우선 변화에 대응하는 것이 계획을 따르는 것보다 우선

Agile 방법론의 종류

• 익스트림 프로그래밍(Extreme Programming, XP)
• 짝 프로그래밍(Pair Programming)
• 테스트 주도 개발(Test Driven Development, TDD)
• 스크럼(Scrum)

1. 익스트림 프로그래밍(Extreme Programming, XP)

• 좋은 실천 지침들(good practices)을 적극적으로 적용
• XP의 실천 지침
  • 작고 빈번한 릴리즈 - 빠른 피드백과 지속적인 개선
  • 고객도 개발 팀의 일원
  • 프로세스 중심이 아닌 사람 중심의 작업
  • 짝 프로그래밍(pair programming)
  • 단순한 설계와 테스트 주도 개발(Test Driven Development, TDD)
  • 리팩토링을 통한 코드 품질 개선

2. 짝 프로그래밍(Pair Programming)
   • 두 사람이 짝이 되어 한 사람이 코딩을, 다른 사람은 검사를 수행
   • 30분마다 역할 교체
   • 장점
   • 코드에 대한 책임 공유
   • 비형식적 검토 수행
   • 코드 개선을 위한 리팩토링 장려
   • 생산성 - 두 사람이 짝을 이뤄 개발하지만 각각 개발하는 경우에 비해 생산성이 떨어지지 않는다.

3. 테스트 주도 개발(Test Driven Development, TDD)

• 테스트 케이스를 먼저 작성하고 이를 통과하는 코드를 개발
• Task 별로 테스트 케이스를 만듦
• 요구사항 ➡️ 스토리 카드 ➡️ Tasks
  • 요구사항은 스토리 카드로 표현되고 스토리 카드는 태스크들로 분해됨
  • 요구사항 - 코드 관계가 명확해 짐
• 통합 테스트를 강조하며 통합 과정에서 기존 소프트웨어에 오류 유입 방지

4. scrum

   Scrum

   scrum이란

   스크럼은 복잡한 제품을 개발(배포)하고, 유지하기 위한 프레임워크. 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크(기법)이다.

Scrum의 주요 역할

1. 제품 책임자(Product Owner) 비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토한다. 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영한다.

• 제품 백로그(요구사항) 관리/설명
• 제품 백로그의 우선순위 관리
• 만족스럽게 개발되었는지 확인

2. 스크럼 마스터(ScrumMaster) 일반적인 프로젝트 관리자들과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할을 한다. 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야한다.

• 팀을 보호하고 장애 요소를 해결
• 일일 스크럼 회의를 진행
• 모니터링 및 Tracking

3.개발 팀 (Developer) 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀으로 주로 5~7명으로 이루어진다. 개발팀에는 따로 리더가 정해져 있지 않으며, 팀원들이 자기 조직화(self-organization)되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정한다.

Scrum 주요 용어

제품 백로그(Product Backlog)

개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리

사용자 스토리(User Story)

과거 요구사항 명세처럼 업무 범위를 구체화하기 위한 개발자 입장이 아닌, User Story는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지를 설명 예를 들면,

완료 기준(Definition of Done), 인수 기준(Acceptance Criteria)

사용자 스토리를 완료시키기 위한 조건 명세(Given, When, Then)

스프린트(Sprint)

계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택

잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP)

팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품

스프린트 계획 회의(Sprint Planning Meeting)

스프린트 목표와 스프린트 백로그를 계획하는 회의(4주 스프린트 기준 8시간 정도 수행)

스프린트 백로그(Sprint Backlog)

각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

칸반 보드(Kanban Board) : 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판

일일 스크럼 회의(Daily Scrum Meeting)

매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의(매일 15분 정도 수행)

스프린트 리뷰(Sprint Review)

스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토(4주 스프린트 기준 4시간 정도 수행)

스프린트 회고(Sprint Restospective)

스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선(4주 스프린트 기준 3시간 정도 수행)

스크럼 진행 순서

1.PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다. 2.PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다. 3.스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다. (해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.) 4.스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다. 5.매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다. 6.제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다. (해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.) 7.다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.

agile참고 scrum참고 scrum참고2

1. 겉으로 드러난 기능은 그래도 두고, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업
2. 리팩토링 기법을 연달아 적용해서 겉으로 드러나는 기능은 그대로 둔 채 소프트웨어 구조를 변경한다.

리팩토링의 목적은 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것이다. 그리고 리팩토링은 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않는다.

리팩토링이 필요한 이유

리팩토링은 소프트웨어의 모든 문제를 해결하는건 아니지만 코드를 쉽게 이해할 수 있게 도와준다. 리팩토링은 다양한 용도로 사용이 가능하다.

1. 소프트웨어를 이해하기 더 쉬어진다.

소프트웨어 개발 프로젝트는 대부분 동료 팀원과 함께 진행하게 된다. 
따라서 특정 코드를 작성할 때 동료 개발자를 고려해야 한다. 
리팩토링을 하면 코드를 더 파악하기 쉬워진다. 
기능은 정상 동작하지마 구조가 완전하지 못한 코드에 대해 실시한다. 
불필요한 부분을 제거하다 보면,본연의 목적에 충실해지는 코드가 완성된다.

2. 버그를 찾기 쉬워진다.

리팩토링 작업을 하면 전체 코드를 살펴보게 되고, 코드를 파악하기 쉽게 변경하다 보면 버그 발견도 쉬워진다.

3. 프로그래밍 속도 개선

깔끔한 설계는 개발 속도를 높이기 위한 핵심이다. 
설계가 깔끔하지 않으면 시간이 지날수록 속도는 더디게 된다. 
반면에 깔끔한 설계는 소프트웨어 개발 속도를 적절히 유지 시키는데 반드시 필요하다. 
리팩토링을 하면 설계가 깔끔해지며 새로운 기능을 추가하는 작업을 빨리 진행할 수 있다.

리팩토링은 어떨때 하는가

리팩토링은 일부로 시간내서 하는 작업이 아닌, 일상적으로 틈틈히 진행해야 하는 작업이다. 다른 작업을 해야 하는데 리팩토링을 통해 그 작업을 쉬워지게 하기 때문이다.

같은 작업이 세번 반복될 때

어떤 작업이 세번 반복된다면 리팩토링을 필수로 해야한다.

기능을 추가할 때

리팩토링이 필요한 첫번째 상황은 소프트웨어에 새로운 기능을 추가할 때이다. 
새로운 기능을 추가하려면 기존 코드를 분석해야한다. 
기존 코드는 나 혹은 동료가 작성했을 것이다. 
코드의 기능을 파악하고 리팩토링이 필요한지 고민하고 리팩토링 작업을 진행한다.

두번째 상황은 설계가 지저분해서 어떤 기능을 추가하기 힘들때이다. 
특정 기능을 추가하려고 보니 기존에 설계된 구조에서는 어렵다고 판단되면 리팩토링을 진행한다. 
과거에는 이 기능이 들어온다고 생각하지 못했을 수 있기에 설계를 수정하고 리팩토링을 진행한다.

버그를 수정할 때

버그를 수정할 땐 주로 코드를 이해하기 쉽게 만들면서 리팩토링을 한다. 
버그가 발생한 기능에 해당되는 코드를 쉽게 파악하기 위해서 리팩토링을 작업하게 된다. 
그 과정을 통해 버그가 발생한 지점을 찾기가 수월해진다.

코드를 검수할 때

코드 검수는 개발 팀원 모두가 전체 코드를 파악하게 되고, 
선베 개발자가 후배에게 지식을 전수하는 효과도 얻게된다. 
리팩토링을 하면 다른 사람이 개발한 코드를 검수하는게 수월해진다. 
의견만 제시하는 것이 아닌 아이디어가 실제 구현하면 도움이 될지 고민하고 가능하다고 판단되면 리팩토링을 실시할 수 있다.

리팩토링 관련 문제들

리팩토링을 장점을 얻으려면 리팩토링 작업을 하는 것도 중요하지만 과정을 모니터링 하는 것도 중요하다.

데이터베이스

리팩토링에서 문제되는 부분 중 하나는 데이터베이스이다. 
수 많은 비즈니스 애플리케이션은 데이터베이스 스키마와 강력하게 결합되어 있다. 
이러한 점 때문에 데이터베이스 수정이 어려워진다. 
또한, 데이터 이전 문제가 발생할 수 있다. 
데이터베이스와 객체 모델의 상호 모델의 상호 의존을 최소화하려고 해도, 
데이터베이스 스키마를 수정하면 데이터를 이전해야 하는데 이 작업은 시간이 오래거릴 뿐만 아니라 위험성이 높다.

인터페이스 변경

인터페이스를 건드리지 않고 내부의 구현 코드를 수정할 수 있는 것이 객체의 장점 중 하나이다. 
하지만, 인터페이스를 수정하면 어떤 문제가 발생할지 예측이 불가능하다. 
리팩토링에서 불안한 점은 상당수의 리팩토링이 인터페이스를 건드린다는 것이다.

리팩토링을 어렵게 하는 설계를 수정하는 일

설계 자체에 오류가 있거나 설계에 대한 결정이 나중에 바뀌었을 때 
혹은 수정이 힘든 사항에도 대부분 리팩토링으로 해결된다.

리팩토링하면 안 되는 상황

코드를 처음부터 새로 작성해야 하는 상황일 때는 리팩토링을 하지 말아야 한다. 기
존 코드가 복잡한 경우에 리팩토링을 할 수 있지만, 차라리 새로 코드를 작성하는 것이 쉬울 수 있다. 
일정이 임박한 경우에는 리팩토링을 하지 않는 것이 좋다. 
일정이 없는 상황에서 리팩토링을 진행하면, 예상한 일정보다 늦게 결과물이 나올 수 있다. 
일정이 임박한 경우가 아니라면 리팩토링을 반드시 해야 한다.

참고: https://lelecoder.com/106 [lelecoder]

rebase는 사전 의미와 같이 base를 재설정한다는 의미이다. 여기서 말하는 base는 branch의 base를 의미한다. branch는 base 지점을 가지고 있어 base에서부터 코드를 수정한다. git history를 살펴보면 branch의 base가 어디 있는지 확인할 수 있다.

깃에서 작업을 위해 master에서 새로운 branch를 따서 작업을 할 때, 협업 상황에서는 다른 사람이 master에 commit하는 상황이 발생하게 된다. 그런 경우 현재 내가 작업하고 있는 master는 현재의 master와는 다른 상황이 발생하게 된다. 이 경우 rebase를 통해 이때까지 commit된 상태의 최상단으로 현재 내가 작업하고 있는 master를 옮길수 있다.

merge 와 rebase

merge 와 rebase 의 경우 모두 git의 코드를 합치는 방법이지만 서로 추구하는 방향에 따라서 다르게 사용한다. Merge는 branch를 통합하는 것이고, Rebase는 branch의 base를 옮긴다는 개념이라고 이해하면 되겠다.

그래서 둘 중에 하나만 쓰는 것이 아니라 두가지가 존재한다.

1. Merge만 사용한다.
2. Rebase와 Merge를 사용한다.

merge 장점

• 이해하기 쉽다.
• 원래 브랜치의 컨텍스트를 유지한다.
• 브랜치 별로 커밋을 분리해서 유지해준다.
• 원래 브랜치의 커밋들은 변경되지 않고 계속 유지되어 다른 개발자들의 작업과 공유대는 것에 대해 신경 쓸 필요가 없다.

  merge 단점

• 모든 사람들이 같은 브랜치에서 작업하기 때문에 머지해야 할 때는 merge가 커밋 히스토리상으로 전혀 유용하지 않고 어지럽기만 하다.

rebase 장점

• 단순한 히스토리
• 여러 개발자들이 같은 브랜치를 공유할 때 커밋을 합치는 가장 직관적이고 깔끔한 방법

  rebase 단점

• 충돌상황에서 다소 복잡하다. 커밋 순서대로 rebase를 하는데, 각 커밋마다 충돌해소를 순서대로 해주어야 한다. SourceTree가 가이드하기는 하지만, 역시 복잡한 것은 사실이다.
• 해당 커밋들을 다른 곳에 푸시한 적이 있다면 히스토리를 다시 쓰는 것에 부작용이 발생한다. Mercurial에서는 간단히 푸시를 할 수 없다. git에서는 push할 수 있으나 나 혼자 쓰는 리모트 브랜치에서만 가능하다. 만약 다른 사람이 그 브랜치를 체크아웃 받은 후 내가 리베이스 한다면 꽤 혼란스럽게 될 것이다.

• JavaScript에는 변경 가능 및 불변의 개념이 없지만 Python에는 변경 가능 및 불변 데이터 유형이 있다.

• JavaScript는 원시 바이트 조작에 대한 내장 지원을 제공하지 않으므로 UTF-16으로 인코딩되어야하지만, 인코딩 형식을 지정하지 않는 한 Python 소스 코드는 기본적으로 ASCII
• JavaScript는 중괄호를 사용하는 반면 Python 언어는 들여 쓰기를 사용한다.
• JavaScript 객체에는 속성을 정의 할 수있는 기본 속성으로 구성 할 수있는 속성이 있으며 - - Python 프로그래밍 언어에서는 속성을 정의하는 데 getter 및 setter 함수가 사용된다.
• JavaScript는 웹 사이트 또는 기본 애플리케이션을 구축하는 데 도움이되는 반면 Python은 데이터 분석, 기계 학습 및 수학 집약적 인 작업과 관련된 작업을 위한 것이다.
• JavaScript는 프로토 타입 기반 상속 모델을 사용하는데 반면 Python은 클래스 기반 상속 모델을 사용한다.

python

고급 객체지향 프로그래밍 언어이다. 동적 바인딩 및 입력과 결합된 데이터 구조가 내장 되어있어 신속한 애플리케이션 개발에 좋다. 모듈 및 패키지에 대한 지원을 제공하므로 시스템 모듈화 및 코드 재사용 가능하다. 가독성과 단순성에 중점을 둔 언어이다.

장점

• 배우고, 읽고, 유지하기 쉬움

• 수정이 쉽다. 파이썬은 인터프리터 언어이기 때문에 컴파일 언어와 다르게 프로그램 수정후 코드를 다시 컴파일 해야 할 필요가 없다.

• 라이브러리가 아주 많음

• 절차적, 객체지향, 함수형, 관점형 프로그래밍이 모두 가능

• 인터프리터에 저수준 모듈을 포함 가능

• 대규모 프로그램에 대한 이상적인 구조와 지원을 제공

• 테스트 및 디버깅의 대화형 모드를 지원

• 높은 수준의 동적 데이터 유형을 제공하고 동적 유형 검사도 지원

• Python 언어는 Java, C 및 C ++ 프로그래밍 코드와 통합 가능

• 배포가 간편한 정적으로 연결된 바이너리

  단점

• 속도 파이썬은 다른 언어에 비해 2~10배 정도 느리다. 여러가지 이유가 있지만 그 중 하나는 dynamical type이다. 파이썬은 변수들의 데이터 타입을 정해줄 필요가 없다. 파이썬이 알아서 그 일을 처리하는데 그 과정이 파이썬에게 큰 부담이 된다고 한다. 그래서 프로젝트가 점점 커지고 소스 코드가 길어질수록 속도는 점점 느려진다.

  또 하나의 문제는 인터프리터 언어라는 점이다. 파이썬은 기계어로 컴파일해서 실행파일을 만들어 실행하는 컴파일 언어와는 다르게 코드를 한 줄씩 읽어 내려가며 실행하기 때문에 다른 컴파일 언어보다 느리다는 단점을 가지고 있다.

• scope 파이썬은 dynamical scope로 동작한다. 이 의미는 특정한 변수를 정한 후 계산식을 통해 동명의 변수가 나왔을때 파이썬은 소스 가장 아래에 있는 변수를 가져온다. 이 특성의 문제점은 소스 코드가 길어졌을때 발생하는데 보통 코드가 길어질수록 많은 변수들을 사용한다. 이 때 자신도 모르게 같은 변수를 2번 이상 사용하면 본인이 계획한대로 결과가 나오지 않는 상황이 발생할 수 있다.

• 런타임 에러 파이썬은 다른 언어들과 달리 실행할 때마다 컴파일을 진행한다. 이런 특성(동적)이 안좋은 성능을 불러오고 많은 테스트를 요구한다.

• 모바일 모바일 컴퓨팅이 약하여 앱 개발에 사용되지 않음

  JavaScript

• 크로스 플랫폼 언어

• 클라이언트 측 및 서버 측에 널리 사용됩니다.

• 컴파일 과정이 따로 필요가 없으며 바로 화면에 적용 가능

• 언어를 적극적으로 지원하는 대규모 커뮤니티가 있다.

• 인터프리터 언어로서 동적이며 타입을 명시할 필요가 없다.

• 객체 기반의 스크립트 언어

• 동일 단일 페이지 애플리케이션(SPA)

단점

• 브라우저 상에 소스가 노출되어서 보안에 취약
• 브라우저 상에서 소스 변경 가능. 사용자가 임의로 기능을 실행하거나 악용할 가능성이 있다.
• 한정된 객체와 객체 함수 제공
• 다중 프로세서 다중 스레딩 기능이 없다.

브랜디 인턴십 과정에서 진행한 프로젝트 데이터를 로컬로 옮기는 작업을 했다. 요금이 자꾸 청구가 돼서.,,,😂

mysqldump를 명령해보았다.

그랬더니 오류 폭탄💣

급하게 해결법을 알아냈다. 참고

참고

이것은 mysqldump 8에서 기본적으로 활성화 된 새로운 플래그 때문입니다. --column-statistics = 0을 추가하여 비활성화 할 수 있습니다.

참고 글을 살펴보니 두 가지의 해결 방법이 나왔다.

[1] --set-gtid-purged=OFF 옵션을 추가하여 해결 가능 [2] --column-statistics=0 옵션을 추가하여 해결 가능

명령어를 추가해서 입력해보았다.

파일이 잘 생성 되었고 SQL query문이 잘 입력된 것을 확인할 수 있었다. local의 mysql에서 새로운 database를 생성한다.

그 후에 SQL 파일에 있는 쿼리문을 생성한 데이터베이스에 넣어주는 작업을 한다. 테이블이 정상적으로 생성된 것을 확인할 수 있다.

4주간의 브랜디 인턴십이 끝이났다. 하루는 참 느리고 한 달은 참 빨리 지나갔다. 이번 인턴십을 진행하며 스스로 많이 반성하고 배운 바가 크다.

음, 차분히 다시 생각해보자면 첫 일주일은 팀을 짜고 팀끼리 모델링을 하느라 정신이 없었다. 모델링이 대충 가닥이 잡히고 마무리 될 즈음엔(물론 모델링은 마무리가 없다는걸 나중에 다시 느꼈지만😂) 위코드에서 배워온 Django가 아닌 flask로 기능 구현을 해야했기에 flask 공부에 들어갔다.

근데 장고의 늪에 빠져도 제대로 빠진건지 flask가 도저히 감이 오질 않았다. 공부할게 산더미인데 감기몸살까지 와서 주말내내 앓아 누워있다가 코로나 검사를 받으러 갔다. 설상가상 노트북까지 말썽이어서 정말...기계도 사람도 고장난 닷새였다...

거의 일주일을 통으로 날린 나는 '할 수 있을까'라는 의심과 번아웃이 동시에 찾아왔고 마음이 안잡혀서 효율없는 시간만 보냈다. 그 알 수 없는 무기력함은 다신 겪고 싶지 않을만큼 힘들었다😭 머리로는 로직이 다 이해가 되고 내가 어떻게 기능구현을 하면 되겠구나 감이 오는데 코드 한 줄 쓰지 못하는 내가 너무 못났다고 느껴졌다...

그러다 문득 나의 마인트셋이 잘못 되었다는 생각이 들었다.

내가 처음 위코드에 들어간 이유, 내가 코딩을 배우기 시작한 이유... 근본적인 것들을 생각했다. 나는 좋은 개발자가 되고 싶었다. 내가 생각하는 좋은 개발자는 함께 일하고 싶은 개발자, 배움을 게을리 하지 않는 개발자였다.

근데 그 때의 나는 브랜디의 인턴 과제에 빠져 내가 왜 개발을 시작했는지, 내가 그 자리에 왜 있는지는 잊고 그 상황에만 연연하고 있었다. 나의 목적은 브랜디에 취업!이 아닌데도 그 알 수 없는 부담감에 방향성을 잃고 무기력함에 빠져 스스로 자신감을 떨어뜨리며 온갖 부정적인 생각으로 내 발목을 잡고 있었다.

그걸 깨달으니 나만의 기준과 방향을 잡아야겠다고 생각했다.

그 때 세운 내 첫 번째 기준은 새로 배우는 프레임워크로 내가 원하는 기능구현을 하는 것이었다. 피드백을 받고 반영을 해야하는건데 첫 술에 배부르려고 욕심 부린 탓에 코드를 제대로 못짜는거라고 생각했다. 그래서 평가를 받는게 먼저가 아니라 내 코드를 생각하는게 우선이라고 기준을 정했다.

두 번째 기준은 팀원들에게 항상 나이스하게 행동하자는 것이었다. 부정적인 마음은 녹 같다. 녹은 쇠에서 생긴 것인데 점점 그 쇠를 먹는다. 그리고 주변 사람들에게도 영향을 준다. 나의 무기력한 모습에 팀원들도 분명 부정적인 영향을 받았을거라 생각했다. 그걸 생각하니 어우...내가 그러고 있으면 안된다라는 생각에 정신이 확 차려졌다. 팀원들에게 항상 나이스 할 것, 그리고 내가 맡은 바를 다 할 것. 마음 먹었다.

세 번째는 이렇게 열심히 하는 나를 칭찬하자는 것이었다. 사람 마음이 참 무서운게 부정적인 마음에 휩싸여서 스스로를 질책할때는 정말 내가 못하는 사람 같았고 스스로에 대한 의심 때문에 내 코드를 짜지 못했다. 근데 세번째 기준을 세우는 순간 코드가 써졌다. 물론 엄청 효율적이고 멋진 코드는 아니었지만 그래도 뭐! 그걸 해낸, 노력한 나를 칭찬했다.

이번 기업협업에서는 기능구현이나 코딩에 관한 배움도 컸지만 스스로의 방향성과 마인드셋의 중요성에 대한 배움이 컸다.

개발자로 살아가면 내가 인턴십에서 느낀 이런 감정은 늘 따라올거 같다.

그 때마다 이번 4주간의 경험을 생각하며 길 잃지 말고 이겨내야지

👩🏻‍💻팀 구성

Front-end 1명, Back-end 3명

🗓 프로젝트 기간

2020.11.16 - 2020.12.10

🛠 Skills

• Python
• Flask
• pymySQL
• Bcrypt
• Aquery
• MySQL

✂️ Tools

• Git & Github
• postman
• workbench

Modeling

구현사항

< backend - python / flask >

• Aquerytool을 사용하여 modeling
• 초기 세팅 config.py 에 데이터베이스 정의, secret key, algorithm 작성, app.py에 데이터베이스 연결, pymysql.connect을 이용한 db 접속 & 해제 설정
• MVC layered pattern(Dao, Service, View)
• Flask-request-validator 를 이용한 유효성 검사
• validate-params 데코레이터를 통한 error handling
• blueprint를 이용한 url관리
• user validator 데코레이션을 통한 account type 분류와 유효성 검사
• account type에 따른 상품리스트 필터링
• 프론트엔드에서 보내주는 정보로 상품 리스트 필터링 구현
• account type에 따른 엑셀 다운로드 구현
• 상품 등록 페이지 구현
• 상품 등록시 이미지 유효성 검사와 S3 업로드
• 상품 등록시 상품 이력 테이블 동시생성

기억에 남는...

데코레이터를 통해 url을 관리하고 유효성 검사를 하는 부분. url을 파일로 관리하는 장고와 달라서 더 기억에 남는다.

query문에 조건을 달아서 나누는 부분이 기억에 남는다.

error exception 처리와 rollback

여러 값을 OR 관계로 묶어 나열하는 조건을 WHERE 절에 사용할 때 쓸 수 있는 키워드로 조건의 범위를 지정하는 데 사용된다.

값은 콤마( , )로 구분하여 괄호 내에 묶으며, 이 값 중에서 하나 이상과 일치하면 조건에 맞는 것으로 평가된다.

example

# OR조건 
WHERE Condition = 'A' OR Condition = 'B'

# IN조건
WHERE Condition IN ('A','B')

✔️IN조건 장점

• 목록에 넣을 값이 여러개 일때, IN 연산자가 OR보다 쓰기도, 보기도 이해하기도 쉽다.
• IN을 사용하면 조건 순서를 보다 쉽게 관리 할수 있고, 연산자 수도 줄어든다
• IN 연산자가 OR 연산자 보다 실행 속도가 빠르다
• IN 연산자안에 다른 SELECT문을 넣을 수 있다.