mac에는 파이썬 2.7이 기본 설치되어 있다. 

최신 파이썬 3.10 을 쓰고 싶어서 파이썬을 설치한다.

brew install python

파이썬 설치 경로를 확인한다. 

ls -l /usr/local/bin/python*

파이썬의 기본 symlink를 python3로 바꾼다. 

sudo ln -s -f /usr/local/bin/python3.10 /usr/local/bin/python

이 방법이 안먹혀서 zshrc의 python 명령이 python3을 가리키도록 변경했다. 

홈디렉토리에 zshrc 라는 설정파일이 있다. 

여기에 alias python="python3" 라는 별명을 붙여준다. 

즉, python을 입력하면 python3라고 인식하게 한다. 

source 명령은 스크립트 파일 속 내용을 실행하는 명령이다. 

cd ~ // 홈디렉토리로 이동 
echo alias python="python3" > ~/.zshrc 

//bash 이용자는 .bash_profile

source ~/.zshrc 
python -V

파이썬 버전을 다시 확인해보자. python 버전을 확인하면 python3 라고 잘 뜬다. 

zshrc 설정파일 내용을 확인하면 아래와 같다. 별칭을 붙인 것이다. 

참고 블로그

Mac OS python 기본 버전 변경하기

How to set Python3 as a defalut python version on MacOS

객체지향 설계 5원칙 - SOLID

SOLID는 개념이다.
객체 지향 프로그램을 구성하는 속성, 메서드, 클래스, 객체, 패키지, 모듈, 라이브러리, 프레임워크 등 다양한 곳에 적용된다.

SOLID 원칙에 대한 간단한 예제를 보며 이해해보자.

단일 책임 원칙 Single Responsibility Principle

“어떤 클래스를 변경해야 할 이유는 오직 하나뿐이어야 한다.” -로버트 C.마틴

하나의 클래스는 하나의 책임만 가져야 햔다.

예시) 속성이 SRP를 지키지 않은 경우,

class 사람 { 
    String 군번; 
… }

사람 로미오 = new 사람();
사람 줄리엣 = new 사람();

줄리엣.군번 = "15723491"; <- ??? 

사람 클래스를 여자 클래스와 남자 클래스로 분할하자.
단일 책임 원칙을 적용하는 것이다.

SRP를 지키지 않으면, if문을 불필요하게 많이 쓰게 된다.

데이터베이스에서도 테이블을 정규화하는 과정이 있다.
테이블과 필드에 대한 단일 책임 원칙의 적용이라고 할 수 있다.

객체지향 4대 특성 중, 단일 책임 원칙과 가장 관련 깊은 것은 뭘까?
추상화가 아닐까.
애플리케이션의 경계를 정하고, 추상화를 통해 클래스를 선별하고,
속성과 메서드를 설계할 때 반드시 SRP를 고려하는 습관을 들이자.

개방 패쇄 원칙 Open Closed Principle

“소프트웨어 엔티티(클래스, 모듈, 함수 등)은 확장에 대해서는 열려있어야 하지만, 변경에 대해서는 닫혀 있어야 한다” -로버트 C.마틴

—> 자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀 있어야 한다.

JDBC를 예로 들어보자.

JDBC를 사용하는 클라이언트는 DB가 Oracle에서 Mysql로 바뀌더라도, Connection을 수정할 필요가 없다.
DB를 교체할 때, 자바 애플리케이션은 JDBC인터페이스라는 완충 장치로 변화에 영향을 받지 않는다.

자바를 예로 들어보자.

자바 개발자가 작성한 코드가 윈도우에서 구동될 지, 리눅스에서 구동될 지 모른다.
신경 안써도 된다.
각 운영체제별 JVM이 윈도우에 맞게, 리눅스에 맞게 바이너리 코드를 번역해준다.

개발자가 작성한 코드는 운영체제의 변화에 닫혀있다.
각 운영체제별 JVM은 확장에 열려있는 구조가 되는 것이다.
자바 코드와 운영체제별 JVM 간에 목적 파일이라는 완충 장치가 있는 것이다.

리스코프 치환 원칙 Liskov Substitution Principle

“서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다. ” -로버트 C.마틴

상속을 떠올려 보자.
상속은 계층도/조직도가 아니다. 분류도를 떠올려야 한다.
하위 클래스 is a kind of 상위 클래스 ex)참새는 새의 하나의 종류다.
구현 클래스 is able to 인터페이스 ex) 구현 분류는 인터페이스 할 수 있어야 한다.

참고 ) 인터페이스 할 수 있어야 한다. 의 의미?
AutoCloseable - 자동으로 닫힐 수 있어야 한다
Cloneable - 복제할 수 있어야 한다

“하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는 데 문제가 없어야 한다. “

고래와 박쥐는 포유류에 포함된다.
참새와 비둘기는 조류에 포함된다.
포유류와 조류는 동물에 포함된다.

고래는 포유류의 역할을 할 수 있다.
참새는 조류 역할을 할 수 있다.
참새는 동물의 역할을 할 수 있다.

결국, 리스코프 치환 원칙은 상속의 특성을 바르게 활용하면 얻게 되는 것이다.

인터페이스 분리 원칙 Interface Segregation Principle

단일 책임 원칙을 떠올려 보자.
하나의 클래스는 하나의 역할만 갖도록 했다.

의존 역전 원칙 Dependency Inversion Principle

작성중.

1. 목표 

centos에 아파치 설치하기 (환경은 centos 7.5)

아파치 포트 변경 

아파치 서비스 시작하고, 정상 시작됬는지 확인하기 

2. 문제 내용  

아파치 서비스가 안켜진다. 에러 내용은 Permission denied 

3. 원인 및 해결 과정 

SELinux 보안 정책을 변경함 

아파치 설치 

yum 업데이트하고, httpd를 설치한다. 

rpm -qa | grep httpd
yum -y update
yum -y install httpd
httpd -v

아파치 설정파일 열고 포트 변경 

설정파일 위치 

/etc/httpd/conf/httpd.conf

아파치 서비스 재시작

service httpd start

Redirecting to /bin/systemctl start httpd.service 리다이렉팅 왜 될까 ? 

service start 명령을 실행하면, 

Redirecting to /bin/systemctl start httpd.service  되는데, 

service 는 CentOS 6이전 버전 명령이고, 

systemctl 은 CentOS 7이후 버전 명령이다. 예전 버전 명령을 치더라도 redirecting 해서 systemctl로 실행시킨다는 것이다. 

netstat -tulpn으로 확인 

네트워크 인터페이스, 라우팅 테이블, 네트워크 접속 정보를 볼 수 있는 netstat 

옵션에 tulpn 을 줫는데, 

t == tcp 

u == udp 

l == LISTEN중인것 

p == PID/프로그램 이름 

n == port number 

아파치 서비스를 켜고 제대로 켜졌는지 확인하는데, Permission error 가 나면서 안켜진다. 

systemctl status httpd.service -l

semanage를 이용하여 SELinux 설정을 변경한다. 

SELinux 동작모드는 3가지가 있다 

enforce, permissive, disable

centos 설치하면 defalut로 enforce 모드다.

setenforce 0 명령으로 permissive로 변경한다. 

setenforce 0 

service httpd start

만약, centos에서 semanage가 없으면 설치한다.

yum install policycoreutils-python

참고 포스팅

CentOS SELinux 설정 및 해제하기

아파치(Httpd) Permission Denied 오류 처리 

netstat 명령 

CentOS systemctl 과 service 

abstrcat 키워드

추상 메서드 : 선언부는 있는데 구현부가 없는 함수
추상 클래스: 추상 메서드를 하나라도 포함한다면 추상 클래스로 선언해야 한다.

추상 클래스는 new를 사용하여 인스턴스를 만들 수 없다.
추상 클래스를 ‘하위 클래스’에서 오버라이딩할 메서드를 추상클래스로 만들어둔다.
추상 클래스는 하위 클래스에게 메서드 구현을 강제한다. 오버라이딩 강제.

생성자

인스턴스를 만들 때 new 키워드를 사용한다.

아무런 생성자를 만들지 않으면, 자바는 인자가 없는 기본 생성자를 자동으로 만들어준다.
인자가 있는 생성자를 만든다면, 자바는 기본 생성자를 만들어주지 않는다.

클래스 생성 시의 실행 블록, static 블록

클래스가 스태틱 영역에 배치될 때 실행되는 코드 블록이 static 블록이다.

static 블록에서 사용할 수 있는 속성과 메서드는 static 멤버 뿐이다.

객체 멤버는 클래스가 static 영역에 자리잡은 후에, 객체 생성자를 통해 힙에 생성된다.

순서가 아래와 같다.

1) static 영역에 객체 멤버 자리잡음
2) 객체 인스턴스가 힙에 생성됨

클래스의 static 블록이 실행되고 있을 때는 해당 클래스의 객체는 하나도 존재하지 않기 때문에 static 블록에서는 객체 멤버에 접근할 수 없다.

왜 프로그램이 처음 실행될 때 클래스 정보를 static 영역에 로딩하지 않고, 해당 클래스가 처음 사용될 때 로딩할까?

스태틱 영역도 메모리이기 때문이다.
최대한 늦게 생성하고 최대한 빨리 반환해야 메모리를 효율적으로 쓸 수 있기 때문이다.

final 키워드

마지막이라는 뜻이다. 클래스, 변수, 메서드에 붙일 수 있다.
final 클래스 : 상속할 수 없다.
final 변수 : 값을 변경할 수 없다. 상수.
final 메서드 : 오버라이딩을 금지한다.

instanceof 연산자

인스턴스는 클래스를 통해 만들어진 객체다.
이 객체가 특정 클래스의 인스턴스 인지 여부를 묻는다.
결과로 true/ false를 반환한다.

package 키워드

네임스페이스를 만들기 위해 사용한다.

interface 키워드와 implements 키워드

인터페이스는 public 추상메서드와 public 정적 상수만 가질 수 있다.
구현을 강제해야 하니까 추상메서드를 가지는 것이다.
정적 상수는 클래스명으로 접근할 수 있는 상수다.

자바 람다는 무엇인가?

변수에 함수를 할당한다.
함수는 로직이다.
즉, 람다는 변수에 저장할 수 있는 로직이다.
( C++의 함수포인터, 자바스크립트에서 함수를 저장하는 변수를 비교하여 배우자. )

자바 람다는 인터페이스를 기초로 하고 있다.

자바 8 이전까지의 인터페이스는 public 추상 클래스와 public 정적 상수만 가질 수 있었다.
자바 8 부터는 디폴트 메서드라고 하는 객체 구상 메서드와 정적 추상 메서드를 지원할 수 있게 언어 스펙이 바뀌었다.

this 키워드

객체가 자기 자신을 지칭할 때 쓰는 키워드이다.

지역 변수와 속성(객체 변수, 정적 변수) 의 이름이 같은 경우, 지역변수가 우선한다.
객체 변수와 지역 변수가 이름이 같은 경우, 객체 변수를 사용하려면 this를 접두사로 사용한다.
정적 변수와 지역 변수가 이름이 같은 경우, 정적 변수를 사용하려면 클래스명을 접두사로 사용한다.

super 키워드

자신의 바로 위 상위 클래스의 인스턴스를 지칭하는 키워드다.

김영한님의 모든 개발자를 위한 HTTP웹 기본지식 강의를 듣고 요약했습니다.

지금은 HTTP 시대

HTML 문서를 연결하는 프로토콜로 시작했다.
HTML, IMAGE, 음성, 영상, 파일, JSON ... 모두 HTTP 를 쓴다.
서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

HTTP 역사

HTTP 1.1 에 대해 공부하는 것이 중요하다.
대부분의 기능과 내용이 1.1에 있기 때문이다. 2와 3은 성능 개선 관련이고 상대적으로 내용이 적다.

HTTP 1.1 - 가장 많이 사용, 우리에게 가장 중요한 버전
HTTP 2 - 2015 성능 개선
HTTP 3 - 성능 개선을 위해 TCP 대신에 UDP 사용

HTTP의 기반 프로토콜

TCP기반으로 동작: HTTP/1.1, HTTP/2
UDP기반으로 동작: HTTP/3

현재 HTTP 1.1 을 주로 사용하고 있지만, HTTP2, 3도 점점 늘어나고 있다.

HTTP 특징

4가지 특징에 대해 이해해보자.

• 클라이언트 서버 구조

• 무상태 프로토콜(stateless)
• 비연결성
• HTTP 메시지로 요청/응답

클라이언트 서버 구조

클라이언트와 서버를 분리하는 것이 매우 중요하다. (예전에는 안그랬다)

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답을 기다린다.
• 서버는 요청에 대한 응답 메시지를 만들어서 보내준다.

클라이언트와 서버를 분리하는 것의 장점?

비즈니스 로직과 데이터를 전부 서버가 관리한다.
클라이언트는 UI와 사용성에 집중할 수 있다.
클라이언트가 PC만 서비스 하다가 Phone 이 필요해지면, application에 필요한 UI를 새로 만드는 것에 집중하면 된다. 클라이언트가 비즈니스 로직을 고민할 필요 없다.

클라이언트/서버가 분리된 구조를 통해 각각 독립적으로 진화할 수 있다는 것이 장점이다.

무상태 :stateless

서버가 클라이언트의 상태를 보존하지 않는다.
컨텍스트(context)를 모른다.

상태유지 무상태 이해를 위한 예시

고객이 물건을 구매할 때 점원과 대화하는 상황을 상상해보자.
고객은 클라이언트이고, 점원은 HTTP 서버 역할과 같다.

상태유지(stateful) 예시

고객 "이 노트북 얼마인가요?"
점원A "100만원 입니다."

고객 "2개 구매할께요."
점원A **"200만원 입니다. 신용카드, 현금 중에 어떤 걸로 결제하시나요?" **

-> 점원이 상황의 문맥(context)를 알고 있다.
따라서 점원은 100만원 x 2개 = "200만원 입니다." 라고 대답해줄 수 있다.

무상태(stateless) 예시

고객 "이 노트북 얼마인가요?"
점원A "100만원 입니다."

고객 "2개 구매할께요."
점원B **" ?? 무엇을 2개 구매하시겠어요? " **

-> 점원이 상황의 문맥(context)을 모른다.
무상태라면, 고객이 요청할 때마다 새로운 점원이 고객을 응대하는 것과 같다.

[중요]stateful과 stateless 차이

상태유지

• 중간에 다른 점원으로 바뀌면 안된다.
• 항상 같은 서버가 유지되어야 한다.
• 클라이언트 A는 계속 서버1과 통신해야 한다.

무상태

• 서버가 장애가 나면? 중간에 다른 점원(서버)으로 바뀌어도 된다.
• 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
• 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

무상태의 강점은 서버1이 장애 나도 서버2가 대신 응답해줄 수 있다는 것이다.
서버가 클라이언트의 상태를 저장하지 않기 때문이다.
스케일 아웃 즉, 수평 확장에 유리하다.

[중요] stateless의 실무 한계

모든 것을 무상태로 설계 할 수도 있는 경우도 있고 없는 경우도 있다.

• 무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면
• 상태유지: 로그인한 사용자의 경우.

    결제 과정이 필요하는 경우. 
    **브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지한다. **

무상태와 상태유지는 전송 데이터의 양에 차이가 있다.
상태 유지 시, 데이터의 양이 더 적을 수 있다.

따라서 ‘상태 유지’는 최소한만 사용해서 개발하자.

무상태(stateless)는 데이터 전송량이 좀 더 많다.
애플리케이션 설계 시, 되도록이면 무상태로 설계하는 것이 좋다.

비연결성

HTTP는 기본이 연결을 유지하지 않는 모델이다.
일반적으로 초 단위 이하의 빠른 속도로 응답한다.

연결을 유지하면?

클라이언트가 서버와 연결 유지하면 계속 서버가 자원을 소모하고 있게 된다.

연결을 유지하지 않으면?

요청/응답 만 하고, 연결을 끊어버려서 최소한의 자원만 사용한다.

비 연결성의 한계와 극복

1. 비연결성 이라면, 요청을 보낼 때 마다 TCP/IP 연결을 새로 맺어야 한다.

-> 3 way handshake 시간 추가된다.
사용자 입장에서는 시간이 단점이 된다.

2. 웹브라우저로 사이트를 요청하면 다운로드 받을 것이 많다.

HTML 뿐만 아니라 자바스크립트, css, image 등 많은 자원이 함께 다운로드 된다.

지금은 HTTP 지속 연결로 문제 해결

이전에는 HTML 응답, 이미지 응답, Javascript 응답.. 각각 연결해야 했었다.
하나의 페이지에는 HTML 말고도 이미지도 있고 여러개가 있는데, 하나 받을 때 마다 새로운 연결을 요청해야 했다.

이제는 Persistent connections 라는 지속 연결로 문제를 해결하고 있다.
한 번 연결이 되면, HTML와 이미지 여러개 등의 다운로드를 할 만큼의 시간동안 연결이 유지된다.
http/2, http/3에서 더 많은 최적화되고 있다.

stateless 를 기억하자

서버 개발자들이 가장 어려워하는 업무가 뭘까?

같은 시간에(일제히) 딱 맞추어 발생하는 대용량 트래픽에 대응하는 것이다.
ex) 명절 KTX예약, 수강신청, 선착순 이벤트

이것만 기억하자. "최대한 stateless 로 설계하자"
어떻게든 머리를 쥐어짜서 stateless로 설계해야 대응할 수 있다!

HTTP 메시지

요청 메시지와 응답 메시지 구조의 차이를 이해하자.

Request 요청 메시지

요청, URL, version
body 본문을 가질 수 있다.

HTTP 요청한것
헤더값
공백라인 CRLF
응답메시지

요청메시지에서 시작라인

start-line은 요청이냐 응답이냐에 따라 다르다.

요청메시지에서 시작라인은 request-line
응답메시지에서 시작라인은 status-line

요청메시지는 request-line이라고 한다.
request-line: method SP(공백) request-target SP. HTTP-version

(여기서 SP는 스페이스 라는 뜻이다. )

http 메서드 : 서버가 수행해야 할 동작 지정
종류 : GET, POST, PUT, DELETE…
GET: 리소스 조회
POST: 요청 내역 처리

요청대상 : 절대경로로 시작한다.
요청대상: 절대경로 “/“로 시작하는 경로

응답메시지의 시작라인

응답메시지의 시작라인은 status-line으로 되어 있다.

status-line 구성

HTTP-version SP
status-code SP
reason-phrase CRLF

(여기서 SP는 스페이스 라는 뜻이다. )

HTTP version: HTTP 1.1 / 2/3

HTTP 상태코드 : 요청의 결과를 의미한다.

200 성공
*400 클라이언트 요청 오류
500 서버 내부 오류 *
이유 문구: 사람이 이해할 수 있는 상태코드 설명글

HTTP 헤더

header-field: field-name:OWS
(OWS: 띄어쓰기 허용 )

HTTP 전송에 필요한 모든 부가정보를 포함한다.
HTTP 1.1을 기준으로 학습하자.

읽을 거리 :
MDN HTTP 개요

오늘 한 일 

용역 일 본격시작하기 전에, C를 다시 보고 있다. 

헷갈리는 함수들이랑 잊어버린 문법들이 왜이렇게 많은건지. 

다시 정리하고 나니깐 보람있었다. 

오늘 한 일 

알고리즘 문제 5개를 풀었다.

조합을 이용한 문제가 있었는데, 옛 기억이 나서 풀 수 있었다. 순열, 조합 문제를 복습해야겠다. 

요즘 github에 커밋하고 푸시하는 재미가 쏠쏠하다. 

스터디를 해서 그런 것 같다. 역시 코딩은 같이 해야 재미가 난다. 

간간히 C++ 을 배우고 있는데 진도 빼는데 속도를 올려야겠다.