행복의 주문, 디리릿!!

내가 하고 싶은 것.

모든 로컬 브랜치의 변경사항 버리고, 리모트 브랜치와 동일하게 가지고 싶음

현재 로컬 변경 사항들(커밋 및 파일 변경 사항들은)은 다 없어져도 됨.

브랜치명 : apron

git checkout apron

git fetch --all

git reset --hard origin/apron

31장 웹은 세부사항이다.

UI와 애플리케이션 사이에는 추상화 가능한 또 다른 경계가 존재해야 한다. 애플리케이션의 업무 로직은 다수의 유스케이스로 구성되며, 각  유스케이스는  사용자를  대신해서  일부  함수를  수행하는  것으로 볼 수 있다. 각 유스케이스는 입력 데이터, 수행할 처리 과정, 출력 데이터를 기반으로 기술할 수 있고, 웹은 이와는 독립적으로 실행할 수 있도록 해야 한다.

32장 프레임워크는 세부사항이다.

프레임워크와 결합해서는 안된다. 결합도가 높아진다면 변경이 쉽지 않다. 적당한 거리를 두자. 프레임워크는 아키텍처의 바깥쪽 원에 속하는 세부사항으로 취급하자. 프레임워크가 아키텍처의 안쪽 원으로 들어오지 못하게 하라. 선택적으로 사용하자.

예를 들어 JAVA 스프링을 사용할 때에 @Autowired 어노테이션이 업무 객체 도처에 산재해서는 안된다. 업무 객체는 절대로 스프링에 대해 알아서는 안된다. 업무 객체보다는 main 컴포넌트에서 스프링을 사용해서 의존성을 주입하는 편이 낫다.....(?)

안 좋은 예 : https://stackoverflow.com/questions/15455878/how-to-autowire-business-objects-in-spring

좋은 예 : https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html

STEP 1

마지막 커밋에 수정할 사항들을 git add 하기

STEP 2

[option 1] git commit --amend

: 커밋 메시지를 수정을 위한 에디터가 켜진다. 커밋 메시지 수정이 필요한 경우 파일을 수정하고, 아니면 에디터 창을 닫으면 된다.

[option 2] git commit -m "memo" --amend

: -m 옵션을 주는 경우 마지막 커밋 메세지가 쌍 따옴표 안의 문장으로 대체된다.

STEP 3 : remote 브랜치로 force push 하기

[option 1] git push origin [branch-name] -f

[option 2] git push origin +[branch-name]

예제

[ option 1 ]

[ option 2 ] 

30장 데이터베이스는 세부사항이다

소프트웨어 시스템의 아키텍처와 데이터베이스의 관계는 건물 아키텍처와 문 손잡이 정도이다. 아키텍처 관점에서 데이터베이스는 엔티티가 아닌 세부사항이며, 데이터에 접근할 방법을 제공하는 유틸리티(=소프트웨어) 일 뿐인 것이다.

(엔티티 : 애플리케이션의 핵심적인 Business Rule을 담고 있는 객체로서 메서드/데이터 구조/함수 집합일 수 있다)

관계형 데이터베이스

디스크에서 1바이트 읽기 위해서는 Heads를 적절한 Track으로 옮기고 Sector가 돌아올 때 까지 기다린 후, 해당 섹터에서 4K를 모두 RAM으로 읽어 들여야 한다. 그리고 RAM 버퍼의 색인을 찾아서 필요한 바이트를 가져온다. 이 과정은 밀리초 단위의 시간이 걸린다. → 오래 걸리는 거임.

그래서 이러한 지연 시간을 완화하기 위해 색인/캐시/쿼리 최적화를 할 수 있는 접근 및 관리 시스템 필요해진 것이다. 그리고 시간이 지나며 뚜렷하게 구분되는 2가지의 유형(파일 시스템과 데이터베이스 시스템)으로 분리되었다. 이 두 시스템은 데이터를 디스크에 체계화해서 효율적으로 데이터를 저장/검색하게 한다.

디스크는 RAM으로 대체되고 있고 시간이 지나며 디스크는 플로피 디스크, CD처럼 소멸될 것이다. 하지만 디스크가 모두 사라지고, 모든 데이터가 RAM에만 저장된다면 데이터를 어떻게 체계화할 것인가? 이미 우리는 파일 시스템, RDBMS 뿐만 아니라, 연결 리스트, 트리, 해시 테이블, 스택, 큐 등의 데이터 구조와 포인터나 reference를 사용하여 데이터 구조를 변경하여 사용 중이다.

이처럼 데이터베이스가 세부사항인 이유는 시간이 지나며 데이터에 접근하는 방식들은 변화하게 되기에 그저 데이터에 접근하는 메커니즘에 불과하기 때문이다. 그래서 아키텍처의 관점에서는 데이터가 어떤 데이터의 형태인지, 더해 디스크의 존재 자체도 인식해서는 안된다.

성능은?

아키텍트 관점에서 성능은 저수준의 관심사

결론

체계화된 데이터 구조와 데이터 모델은 아키텍처적으로  중요하다.

데이터는 중요하다. 하지만 데이터베이스의 종류는 세부사항이다.

에러 메세지

/usr/bin/python3: No module named pip

해결책

python3

sudo apt-get install python3-pip

python2

sudo apt-get install python-pip