• http의 url과 http method(GET, POST, PUT, DELETE)를 사용해서 API 가독성을 높인 구조화된 시스템 아키텍쳐

DRF를 사용하는 이유

• 웹 브라우저 API는 범용성이 크다. 개발을 쉽게 만들어준다.

• 인증 정책에 OAuth1, OAuth2 를 위한 추가적인 패키지가 추가되어 있는 경우

• 시리얼라이즈 기능을 제공해준다. (DB data -> JSON)

• 문서화 및 커뮤니티 지원이 잘 되어있다.

Serializer 란

Serializer란 말 그대로 직렬화하는 클래스로서, 사용자의 DB안에 사용자 프로필 사진, 이메일, 이름, 성별이 있다고 가정하면 사용자 모델 인스턴스를 JSON 형태 혹은 Dictionary 형태로 직렬화 할 수 있다.

user = User(email="user@user.user", name="user", sex="Female", profile_image="user.png")
UserSerializer(user).data{
    "email" : "user@user.user",
    "name" : "user",
    "sex" : "female",
    "profile_image" : "user.png"
}

• DRF의 serializer를 통해 모델 인스턴스를 직렬화 할 수 있다.

실 사용시에는 만약 사용자 정보를 열람하는 URL이 /serializer/user//가 있고 해당 View에서는 user_id의 해당하는 모델 인스턴스의 정보를 리턴한다고 가정하자.

그렇게 되면 만약 우리가 /serializer/user/1/ 이라는 URL로 요청을 했을시에 user_id가 1인 사용자의 정보를 JSON형태로 응답받을수 있을것이다.

이는 사용자 프로필 페이지에 접근했을때 사용하는 View라고 하면 사용자 페이지의 들어갈때마다 해당하는 사용자의 user_id만 URL에 입력해주게되면 각 사용자의 정보를 JSON형태로 응답 받을 수 있을 것이다.

ModelSerializer

class UserSerializer(ModelSerializer):

    class Meta:

        model =    User

        fields = ("email", "name", "sex", "profile_image",)

• DRF의 ModelSerializer를 사용해서 각 모델 인스턴스를 쉽게 직렬화 할 수 있게 된다. model_to_dict 필요없이!

• 모델 저장시에 데이터가 유효한지 검사할 수 있어서, DB 정보 저장시에도 Serializer를 가장 많이 이용한다.

GET

단일 행 결과를 반환, Query Set이 아닌 다일행 (모델타입)으로 나옴

ALL

전체 자료를 불러옴, Query Set 타입으로 반환

Filter

조건에 맞는 여러 행을 출력 타입은 Query Set으로 반환

장고 ORM (SQL 질의문)

OR 연산, AND 연산

ex 1) OR

queryset = User.objects.filter(
        first_name__startswith='R'
    ) | User.objects.filter(
    last_name__startswith='D'
)
queryset
<QuerySet [<User: Ricky>, <User: Ritesh>, <User: Radha>, <User: Raghu>, <User: rishab>]>

ex 2) OR (Q 객체 활용)

from django.db.models import Q
qs = User.objects.filter(Q(first_name__startswith='R')|Q(last_name__startswith='D'))

ex 1) AND (Q 객체 활용)

queryset_3 = User.objects.filter(
    Q(first_name__startswith='R') &
    Q(last_name__startswith='D')
)


queryset_1
<QuerySet [<User: Ricky>, <User: Ritesh>, <User: rishab>]>

NOT 연산

ex 1)

>>> queryset = User.objects.exclude(id__lt=5)
>>> queryset
<QuerySet [<User: Ritesh>, <User: Billy>, <User: Radha>, <User: sohan>, <User: Raghu>, <User: rishab>]>

ex 2) Q 객체 활용

>>> from django.db.models import Q
>>> queryset = User.objects.filter(~Q(id__lt=5))
>>> queryst
<QuerySet [<User: Ritesh>, <User: Billy>, <User: Radha>, <User: sohan>, <User: Raghu>, <User: rishab>]>

필드 값을 비교하여 항목 선택

In [27]: User.objects.create_user(email="shabda@example.com", username="shabda", first_name="Shabda", last_name="Raaj")
Out[27]: <User: shabda>

In [28]: User.objects.create_user(email="guido@example.com", username="Guido", first_name="Guido", last_name="Guido")
Out[28]: <User: Guido>

2개의 레코드 생성

• F 객체 활용

  In [29]: User.objects.filter(last_name=F("first_name"))
  Out[29]: <QuerySet [<User: Guido>]>

DOM = 웹페이지의 HTML을 계층화 시켜 트리구조로 만든 객체 모델

• 트리구조 예시

JS는 이 model로 웹페이지에 접근하고, 페이지를 수정할 수 있다.

DOM = HTML인 웹페이지와 스크립팅 언어를 서로 잇는 역할

• Example Image

왜 HTML을 접근해야 할까?

• Example Image

document객체는 DOM트리의 root node에 접근하게 해준다.

document객체로 element에 접근하듯이 element의 attribute에도 접근 가능

document.body.innerHTML = '내용 다 바꿈';

class, id도 추가하고 style도 수정 가능

요소의 내용은 innerHTML으로 접근하고 수정 가능

Es = ECMA Script의 줄임말로써 JavaScript를 표준화 시키려고 탄생 현재는 ES10버전 까지 탄생

ES6에서도 arrow_function에 대하여 학습하였다.

//ES5
function() {}


//ES6
() => {}

• 익명 함수의 기본적인 표현

ES6에서는 function이라는 키워드가 빠지고 소괄호만 남았다. 그리고 =>(arrow)가 추가되었다.

//ES5
function getName() {}


//ES6
const getName = () => {}

• 이름이 있는 함수를 만들 때의 표현

getName()

• 호출할 때는 둘 다 같다.

//ES5
const getName = function(name) {}


//ES6
const getName = (name) => {}
const getName = name => {}

• 인자를 받았을 때의 예시

//ES5
function hi(text) {
  text += '하세요';
  return text;
}


//ES6
const hi = text => { 
  text += '하세요';
  return text 
};

• return하는 함수 예시

//ES5
function getName(name) {
  return name;
}


//ES6
const hi = name => { return name };
const hi = name => name;

• return 키워드를 생략 했을 시 예시

처음에 arrow_function을 접했을 때는 다른 언어의 lambda식과 비슷하다고 받아들여서 수월하게 이해할수 있었던 것 같다.

• 지하철 역과 노선을 관리하는 지하철 노선도 기능을 구현한다.

지하철 역과 노선을 CRUD기능을 이용하여 콘솔로 output을 출력하는 프로그램이었다.

처음에는 MVC패턴과 관련 기능을 숙지하려고 시간을 많이 쏟았다. 그리고 부족한 자바 공부를 위하여 내가 부족한 부분을 자바의 정석과 이해가 잘 안되면 인터넷 강의를 통하여 익혔는 데 시간을 너무 많이 개념부분에서 많이 쏟는 바람에 예외처리와 dumy data부분을 구현하지 못하였다.....

처음에는 프로그램을 구현하는 데 1주차와 2주차 미션에 비하여 난이도가 상당하다고 생각했다. 특히 Controller 비즈니스 로직을 구현해야하는 데 Section 구간에서 이해가 잘 안되어서 많이 고민했다.... 그렇게 시간이 많이 흘러서 결국 다른 분 PR을 보면서 공부하고 로직을 구현 했다ㅠㅠ

3주차 미션을 지나며

컨벤션

3주차까지 미션을 수행하면서 많은 것을 느끼고 배웠다. 특히 컨벤션 부분에서 여태까지 컨벤션이 이렇게 중요하다는 사실을 못 느꼈다. 솔직히 귀찮은 것들로 치부되어버려진 건 아닌 지 미션을 하면서 많이 생각했었다.

하지만 그건 우물안의 개구리라는 사실을 매주 미션을 거듭할 수록 느꼇다. 옛날에 읽은 네이비씰 승리의 기술에서 규율이 곧 자유다라는 사실이 와닿지 않았지만 이번 계기로 배웠다. 규율은 효율성을 높이고 사람을 강인하게 만들고 일상에서 적용할 경우 좋은 습관들을 만들어서 몸에 모든 부분에서 우리를 최적화 시킬수 있다라는 구절이 존재한다. 처음에 읽었을 때는 사람의 창의성과 개성을 방해하는 것 아닌가 라는 생각을 했지만 아니었다.여태까지 내가 겪었던 경험으로는 사람이 무언가 행 할때는 개인보다는 팀이 포퍼먼스가 갑절이 되었다. 내가 boss가 되어서 창의성과 효율을 느끼는 것 보다 팀에서 각자의 규율을 정하여서 행 할 때가 정말 창의성과 효율이 높았다. 여태까지 로직을 짜면서 내가 짠 코드는 내가 사용하는 것이 대부분이었다. 어떤 특정 단체에 속하여서 대규모 프로젝트를 하여 서로가 손발이 되어서 행하는 일이 없었던 나에게는 정말 단비 같은 기회였다. 앞으로도 컨벤션을 잘 지키며 팀원들과 조화롭게 코딩을 하면 정말 좋겠다.

이름을 통해 의도를 드러내라

여태까지 변수,메소드 등의 이름은 굉장히 축약하는 편이었다. 예를 들면 num,a,b,pw 등과 같이 의미가 없거나 추상적이어서 헷갈릴 때가 굉장히 많았다. 하지만 이름을 통해서 의도를 드러내니 확실히 가독성 측면에서 비약적으로 늘었다. 과거에는 내가 짠 로직을 일주일 지나면 남이 짠 코드처럼 느껴질 때가 있었다. 이걸 내가 짰다고? 라고 생각도 많이 했다.... 이번 프리코스를 통하여서 개발자로서의 약점을 많이 보완 할수 있는 계기가 되어서 정말 다행이다.

반복하지마라

의도적으로 반복하지 말아야겠다는 생각으로 로직을 구현하여서 공간 복잡도가 많이 개선되었다:)

값을 하드코딩 하지마라

처음에 짠 코드는 그냥 숫자 덩어리였다... 하드코딩을 뺀 덕분에 로직이 글처럼 읽히는 기분을 느꼈다....Good

구현할 기능 목록 작성

아직도 어렵다... 처음에는 한줄 쓰기도 힘들었다. 하지만 미션을 통하여서 내가 대략적으로 어떠한 구조로 구현할지 방향을 정하여서 코딩을 하게되어서 리팩토링 과정을 많이 줄일 수있게 되었다.

필드의 수를 줄이기 위해 노력한다.

파이썬으로 로직을 구현 할 때는 모든 값이 객체인 전제 조건하에 코드를 구현하여서 내가 객체지향인지 절차 지향인지 헷갈릴 때가 많았다 요번 기회에 객체 지향에 대하여 많은 배움을 얻어서 조금 더 객체지향적으로 코드를 구현 할 수있게되었다.

비즈니스 로직과 UI 로직을 분리해라

이 피드백이 처음에는 무슨 말인지 몰랐다. 일단 비즈니스 로직의 뜻을 몰랐다. 검색하여 찾아보니 MVC패턴까지 흘러들어왔다. 그래서 프로그램을 구현 할때에 좀 더 유지보수가 용이하게 구현 한것 같아서 좋았다. (아직 많이 부족하여 더 많이 공부해야....)

프리코스를 마치며

너무 많은 것을 배워서 즐거우면서 고통의 나날이었다. 서로 모순되는 말이라고 생각했지만 내가 성장하려면 내가 안주하는 것들에서 탈피하여 새로운 세계로 나아가야된다는 것을 느꼈다. 여태 코딩을 하면서 새로운 것의 고통이 괴로워서 현재 나의 위치에서 많이 안주해 있었다. 항상 성장하고 많은 것을 경험해보고 배워보고 싶다는 나의 생각과는 정반대로 움직이고 있었다. 배움의 고통을 매번 피하면서 지내며 늘 배우는 것을 좋아했는 데 어느 순간 새로운 것이 낯설고 두려워 많이 숨었다. 그리고 나태해진 자신을 발견하고 프리코스를 계기로 능동과 도전적으로 바꾸게 해준 계기가 되었다 . 3주동안 길지도 짧지도 않은 기간동안 많은 것을 배우며 느꼈다. 1주차때는 좌절을 많이 느꼈다. 나보다 128명 중에서 내가 꼴등 같았다(Fact) 그래서 너무 많은 겁을 먹었는 지도 모른다. 그런데 일단 떨어지더라도 최선을 다해서 뛰어보자라는 생각으로 미션을 진행했던 것 같다. 2주차..... 3주차도 동일하게 어차피 내가 꼴등인 거 뒤가 없으니 오프라인 테스트까지 최선을 다하자는 마인드로 계속 해왔던 것 같다.

랜덤값 1~9 기준으로 4이상 일시에 경주할 자동차가 전진하고 이하 일시 정지를 시동 횟수에 따라서 레이싱을 경주하여 최종 우승자를 가리는 콘솔 게임입니다.

1주차에는 메소드를 서로 분리하는 연습을 했다면 이번 과제는 클래스를 분리하는 목표로 진행하게 되었습니다.

README.md 에 대하여 피드백을 받은 사항에는

• 기능 목록을 클래스 설계와 구현, 함수(메소드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다.

README.md 파일을 작성하면서 클래스를 기준으로 너무 상세하게 작성한 것 같습니다. 클래스 이름과 메소드의 input/output은 언제라도 변한 다는 것을 인지 하지 못하고 기능 구현 목록 정리에 집중을 하지 못 한것 같습니다.

MVC 패턴으로 나누보려고 했습니다.

기능을 구현한 car 클래스와 cars 클래스가 view로직도 같이 담당하여 너무 많은 책임이 부담 되었습니다. outView 클래스를 새로 만들어 model을 담당하는 car과 cars의 출력 메소드들을 나누어서 분산 시키고 Game 클래스 즉 컨트롤러에 더 많은 로직을 구현 해야 됬는 데 MVC 패턴을 좀 더 자세히 학습해야 할 것 같습니다. 책임과 역할 등을 제대로 분배를 못 해준 것 같아서 아쉽습니다ㅠㅠ

그리고 1주차와 동일한 피드백인 원시값과 문자열을 하드 코딩하지 말라는 피드백을 듣고 똑같은 하드 코딩을 한 것 같습니다. 3주차 과정에서는 완벽히 하드코딩을 제외하려 노력 해 보아야겠습니다.

메소드명과 변수명등이 아직 의미가 추상적인 면이 많은 것 같습니다. 옛날에는 그냥 지나쳐버렸던 변수명이나 메소드명이 이렇게 가독성에 중요한 역할을 하는 지 이번 프리코스에 깨달았습니다.

명명을 축약적인 것은 원래 지양하는 편 이었지만 추상적인 메소드와 변수를 많이 사용했던 것 같습니다. 아직도 사용하는 것 같아서 많이 고쳐야할 것 같습니다....

java api 또한 잘 활용을 하지 못한 것 같습니다. stream과 같은 api를 활용해 보고 싶었지만 개념이 이해가 되지않아 로직을 많이 길어진 것 같습니다.

그리고 마지막 피드백으로 객체에게 메시지를 보내라는 피드백은 아직 이해가 되지않아서 자세히 공부해서 3주차 과제에 적용을 해보고 싶습니다.

마지막 과제만을 남겨 두었는 데 정말 짧은 시간이었던 같습니다. 후회 없이 노력 했는 지 되돌아 보았는 데 아쉬운 부분들이 조금 남은 것 같습니다. 남은 기간 최선을 다해서 후회 없이 오프라인 테스트까지 치루었으면 좋겠습니다!

자바 콘솔로 구현하는 숫자 야구 입니다.

처음에는 우아한 테크 docs에 있는 클린 코드 원칙을 최대한 지키며 할려고 했습니다. 하지만 처음부터 완벽히 구현 기능들을 REAME.md로 써내려가는 과정이 굉장히 힘들었습니다.

제가 시도 했던 방식을 처음 방식으로 진행할려고 했습니다. 처음부터 완벽히 구상하려니 막막 했습니다. 3일 동안은 아무것도 구상하지 못 하고 계속 삽질만 했던 것 같습니다. (자바 문법도 완전하지 못 한채로 완벽한 프로그램을 구상하려는 멍청한 생각을 계속 ....)

그래서 3일동안 밤새 고민한 끝에 나온 생각이 스케이트 보드부터 만들고 리팩토링을 하자였습니다.

애자일에 대하여 공부도 하고 적용(?) 같은 것도 해보았지만 그건 django처럼 완벽히 만들어진 framework를 주로 하더보니 애자일 방식을 완전히 숙지하지 못 했습니다.

그리고 4일차에 일단 간단한 기능 구현 목록을 만들고 메소드를 작은 단위로 쪼개어서 서로 return 값으로 메소드를 상호작용을 하려하니 못하겠더군요. 그래서 그냥 한 스크립트에 다 구현 했습니다. 그리고 스크립트를 다시 보면서 어떻게 한가지 기능 메소드로 쪼갤가를 고민하여서 최대한 메소드를 분리하고 class를 개념에 맞게 나누었습니다.

클래스로 나눈 것은 7가지로 나누었습니다.

Application Class

클린 코드 원칙인 else 예약어를 지양하라는 말씀에 switch 구문으로 작성했는 데 피드백 받았을 때 어리석은 판단이었구나를 느꼈습니다. 그리고 다시 숫자 야구를 한다면 이 로직을 Game Class에 구현 할 것 같습니다. 그리고 또한 게임 시작과 게임 종료 그리고 default 값을 각각의 메소드로 구현 할 걸이라고 글 쓰면서 후회 중 입니다....

Computer Class

아쉬움이 많은 클래스인 것 같습니다. List 콜렉션을 완벽히 이해를 못하여서 (파이썬에 너무 익숙해진 것 같네요..) 쓰는 데 많이 애를 먹고 시간이 촉박하여 그냥 배열 형태로 작성하였는 데 리팩토링 할 시에는 콜렉션을 써서 List 형태로 바꾸고 그리고

모든 원시값이나 문자열을 포장한 줄 알았는 데 실수를 했습니다... 이것 또한 바꾸고 싶네요.

그리고 중복숫자검사에 Overlap이라는 단어를 썼는 데 Duplicate가 더 적합한 것 같습니다.

inputRandomNumberArray 또한 두가지 기능을 수행하는 메소드 만든 것 같습니다. 두가지 메소드로 나누어 활용하는 것이 좋을 것 같습니다.

Game Class

Application Class에 있는 기능들을 여기다가 추가 해야할것 같습니다.

Hint Class

음.... 이 메소드는 몇가지 일을 하는 지 지금 봐도 알수없네요.....

strike와 ball을 판단하는 메소드를 추가하고 각각의 상황에 맞는 출력문을 메소드를 추가하여 구현하는 부분을 해야했는 데 아쉬움이 많이 남습니다.

그리고 indent가 3을 초과해 버렸습니다. hashmap을 이용하여 key와 value를 비교하면 좀 더 나은 로직이 되었을 텐데 2중 for문을 돌려버렸네요.

Player Class

List 콜렉션을 활용하고 파라미터를 Scanner 데이터 타입으로 매개변수를 주고 받았으면 중복된 모듈을 덜 import 했을 텐데 매개변수 활용을 못 한 것 같습니다.

그리고 예외처리는

• 텍스트가 들어갔을 시

• 0이 들어갔을 시

• 3자리 수 이상이 들어 갔을 시

• 중복된 숫자가 들어갔을 시

로 구상 하였지만 조금 디테일한 예외처리까지 생각 못 한 것 같아 아쉽습니다.

처음에 자바를 전체적으로 완벽히 하고 로직을 구현 해야지라는 생각에 계속 발목을 잡았던 것 같습니다. 그리고 자바의 정석이라는 책을 다 보고 완벽하다고 생각했는 데 그것 또한 아니었습니다. 학교 생활에서는

• 기억

• 이해

• 응용

• 분석

• 평가

• 창작

6단계가 차례대로 학습 했던 것 같습니다. 그래서 1주차 미션에서 자바의 모든 것을 기억하고 이해할려니 감당이 안되더군요. 개발자가 될려면 학습 메커니즘을 바꾸어서 역순으로 진행하여서 내가 부족하고 필요한 기술들을 학습하는 데 포커스를 두어야 될 것 같습니다.

그리고 클린 코드 원칙을 조금이나마 지키면서 많은 깨달음을 얻은 것 같습니다.

• 소프트웨어로 해결하고자 하는 문제 영역을 도메인 이라고 부른다.

도메인 모델링이란?

• 소프트웨어 컴포턴트가 아니라 실세계 개념 클래스들의 표현이다.

• 소프트웨어 클래스 또는 책임을 갖고 있는 소프트웨어 객체를 나타내는 다이어그램 집합이 아니다.

관련 도메인의 개념 클래스 또는 실세계 객체들의 시각적 표현

개념 클래스

하나의 생각, 사물 혹은 객체로 세가지 측면에서 고려

• 상징 : 개념 클래스의 단어 또는 이미지

• 의도 : 개념 클래스 정의

• 확장 : 개념 클래스가 적용되는 예제 집합

도메인 모델과 분해

• 도메인의 명확한 이해

• 객체의 분할

• 사람의 생각과 소프트웨어의 표현과의 차이 수렴

• 객체지향과 구조적 분석의 차이는 함수의 분할이 아니라 개념 클래스의 분할에 있다.

기본 성공 시나리오 (기본 흐름)

1. 고객은 사려는 상품이나 서비스를 갖고 POS 계산대 도착한다

2. 출납원은 새로운 판매를 시작한다.

3. 출납원은 품목 식별자를 입력한다.

4. 시스템은 품목을 기록하고 품목 설명, 가격, 합계를 보여준다. 가격은 가격 룰에 의해 계산된다.

5. 시스템은 세금을 포함한 총액을 보여준다.

type : subject

body

footer

Commit Type

• feat : 새로운 기능 추가

• fix : 버그 수정

• docs : 문서 수정

• style : 코드 포맷팅, 세미클론 누락, 코드 변경이 없는 경우

• refactor : 코드 리펙토링

• test : 테스트 코드, 리펙토링 테스트 코드 추가

• chore : 빌드 업무 수정, 패키지 매니저 수정

Subject

• 군더더기 없이 간략하게, 소문자로 작성하고 마침표를 붙이지 않는다.

• 과거 시제를 사용하지 않고 명령어 작성

Body

• 선택사항이기 때문에 모든 커밋에 본문 내용을 작성할 필요는 없다.

• 부연 설명이 필요하거나 커밋의 이유를 설명할 경우 작성 해준다.

Footer

• 선택 사항이기 때문에 모든 커밋에 꼬리말을 작성할 필요는 없다.

• issue tracker id

클론 프로젝트에서 Sns 기능을 담당

Language : Python FrameWork : Django DB : Mysql

APi 기능

1. Ootd_View (실제 구현)

   (GET 요청)

   ootd의 페이지의 경우에는 Insta 처럼 여러 개의 카드 게시판들이 List 형태로 존재 그것에 대하여 데이터를 응답을 위해 List Comprehension 을 적용하여 List 형태로 묶음

   (POST 요청)

   ootd의 페이지를 등록하기 위한 엔드 포인트로써 실제 사이트의 존재하는 모든 정보를 담음

2. Ootd_Detail_View (실제 구현)

   (GET 요청)

   ootd의 상세 게시판을 드러가기 위해서 처음에는 프론트의 요청(json)에서 바디에 ootd_id를 넣은 상태에서 진행 하였지만 get방식으로는 body에 정보를 실을 수없어 엔드 포인트를 RESTFUL한 방식으로 path 파라미터를 사용하여 엔드 포인트 뒤에 integer을 입력하여 Json Body에 ootd_id를 대체

3. OotdCommentView (실제 구현)

   (POST 요청)

   엔드 포인트에 ootd_id를 path 파라미터를 이용하여 실음 내용과 로그인 데코레이터를 이용하여 회원가입이 된 유저만 등록 할 수 있도록 구현

   예외처리 : KEY_ERROR, OotdNotExist(게시판에 대한 id가 없을 때)

4. CommentView (API로만 존재 test 완료)

   (POST 요청)

   path 파라미터를 이용하기 위하여 댓글의 대한 id를 엔드포인트에 실음 post 요청시 해당 댓글의 대댓글을 다는 구조로써 댓글 자신의 외래키를 만들어 대댓글을 표현

   (PUT 요청)

   댓글 수정 기능

   (DELETE 요청)

   댓글 삭제 기능

5. ReCommentView (API로만 존재 test 완료)

   (PUT 요청)

   대댓글 수정 기능

   (DELETE 요청)

   대댓글 삭제 기능

6. LikeView (실제 구현)

   (POST 요청)

   게시판과 User 사이의 중간 테이블을 생성하여 해당 게시물의 좋아요의 개수나 좋아요의 리스트를 표현

   (DELETE 요청)

   해당 게시물의 좋아요 삭제 기능

7. FollowView (API로만 존재 test 완료)

   (POST 요청)

   User User 사이의 중간 테이블을 생성하여 데코레이터를 활용하여 로그인 된 유저가 해당 user_id를 엔드포인트로 요청하여 follow를 하는 기능

   (DELETE 요청)

   해당 유저의 팔로우 삭제 기능

• 클론 프로젝트를 마치며..

  처음에는 페이지의 구조대로 데이터 응답을 이해 할려니 굉장히 머리가 복잡했다. 카테고리, 게시판들 여러 버튼들을 데이터의 모두 뿌려줄 생각을 하니 로직의 틀이 안 잡혔다. 하지만 페이지의 대한 기능들로 세분화 하여 App 중심의 생각을 하니 수월하게 로직을 구현 할 수 있었던 것 같습니다. 프로젝트를 진행하며 팀원들과 정말 즐거운 시간을 보낸 것 같습니다. 같이 에러와 씨름하고 성공적으로 통신했을 때 같이 기뻐하며 팀플레이를 느낄 수 있었습니다.

• header 파라미터

  • 보통 인증(Authentication;, 특정 identity 제공)과 권한 부여(authorization;, 특정 action 허용)

path 파라미터

• 엔드포인트의 일부, ex) 아래의 엔드 포인트에서 {user}와 {bicycled}에 각각 값이 들어간다

/service/myresource/user/{user}/bicycles/{bicycleId}

query string 파라미터

• 엔드포인트에서 물음표(?) 뒤에 등장하는 query 파라미터는 아래의 형식으로 지닌다.

/surfreport?days=3&units=metric&time=1400

• 가끔 path 파라미터와 query 파라미터 중 무엇을 사용할지 고민하곤 하는데, REST API의 모범을 준수하자면 path 파라미터는 특정 리소스를 정의할 필요가 있을 때, query 파라미터는 정렬 혹은 필터링이 필요할 때 사용

• 쿼리를 실행할 때 추가적인 관련 객체 데이터를 선택하여 외래키 관계를 팔로우 할 QuerySet을 반환한다.

# models
from django.db import models

class City(models.Model):
    # ...
    pass

class Person(models.Model):
    # ...
    hometown = models.ForeignKey(
        City,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )

class Book(models.Model):
    # ...
    author = models.ForeignKey(Person, on_delete=models.CASCADE)

Book.objects.select_related('author__hometown').get(id=4) 호출하면 관련 Person과 관련 City가 캐시된다.

prefecth_related()

• 지정된 각 조회에 대해 단일 배치에서 관련 객체를 자동으로 검색하는 QuerySet을 반환 select_related와 비슷 하지만 전략은 완전히 다름

select_related는 SQL join을 생성하고 SELECT 문에 관련 객체의 필드를 포함시켜 작동한다. 그렇기 때문에 select_related는 동일한 DB 쿼리에서 관련 객체를 가져온다. 그러나 많은 관계가 조인하여 발생하는 큰 결과셋을 피하기 위해 select_related는 외래키와 one-to-one 관계로 제한한다.

• prefetch_related는 각 관계에 대해 별도로 조회하고 파이썬에서 joining을 수행

• select_related에서는 할 수 없는 many_to_many, many_to_one 객체에서도 사용 가능

기본 QuerySet의 결과 캐시와 지정된 모든 관련 객체를 메모리에 완전히 불러온다. 일반적으로는 DB에서 쿼리가 실행 된 후에도 필요한 모든 객체를 메모리에 로드하지 않는다.

리눅스란?

• 라이너스 토발즈가 개발한 Unix 기반 운영체제
• 오픈 소스
• 단양한 이유로 서버는 linux 기반으로 운영되고 있음
• 구글에서 배포하는 안드로이드 역시 리눅스의 한 https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F286e2928-58ad-41b0-a14f-8b52af397882%2FUntitled.png?table=block&id=bbdfadc8-6bdb-4531-868e-512397369362&width=1640&userId=96541d16-4b5c-4942-a615-6e56f66826fc&cache=v2갈래

언제 쓰이는 지?

• 서버

  1. 안정적 (ex 블루 스크린 => 서버 중단)
     2. 유연성 (오픈 소스 => 사용자가 소스코드를 비교적 쉽게 변경 가능
     3. 무료 > 비용문제로 인하여 많이 사용 => 오픈 소스 활성화 => 풍부한 생태계
  4.원래 CLI(Command Line Interface) 기반 5. 사용자들을 위해 GUI(Graphic User Iterface) 기능 추가

• 서버(로컬 서버, AWS 등에 설치된 인스턴스 등)에 설치된 리눅스 환경을 사용할 수 있다 Ex) 우리가 만든 프로젝트를 AWS EC2 등을 통해 배포하려고 하는데 해당 서버는 순수한 우분투 외에는 아무 것도 깔려 있지 않은 상태 만약gir을 GUI를 통해서만 사용할 줄 안다면 여러가지 프로그램과 환경설정, 그 프로그램들의 확장 프로그램을 모두 설치 한후에야 사용 가능

핵심 개념

FHS (Filesystem Hierarchy Standard)

각 폴더 별 특징

• /

  • 루트 폴더. 최상위 경로. /기호로 접근 가능

• /bin & /sbin

  • 윈도우 : C드라이브/windows/system32 폴더

  • Binary의 약자. OS의 최소한의 구동을 위해 필요한 프로그램이 들어있는 폴더 cat , chmod,chown,cp,date,echo,kill,ln,ls,mkdir,etx 와 같은 기초적인 프로그램들 포함

  • /boot

  • 윈도우 : C드라이브/windows/system32 폴더, boot.ini

  • 부트로더 같이 시스템 부팅에 필요한 파일들이 위치.

• /home

  • 윈도우 : C드라이브/Users/사용자명 ⇒ 바탕 화면, 다운로드, 내 문서
  • 유저의 공간. 가장 빈번하게 사용하게 되는 경로. Home 디렉토리 이외의 다른 디렉토리 들은 주로 system directory 라고 하는데, 즉 리눅스의 운영과 관리에 관련한 파일들이 존재하는 디렉토리들. ~ 기호로 접근할 수 있다.

• /usr

  • 윈도우 : C드라이브/Users/사용자1
  • user의 약자. 각 유저 이름에 해당하는 폴더이름이 존재. 각 폴더마다 bin, sbin, shared, lib과같이 각 유저들이 사용할 수 있는 폴더가 생성되어 있음. 각각의 유저별로 다른 파티션으로 존재하기 때문에 다른 사용자들이 사용할 수 있도록 마운트할 수 있지만 이 경우 수정할 수는 없음.

• /etc

  • etc 폴더에는 시스템 전체에서 사용하는 설정 정보 등 엑스트라 데이터들이 저장됨.

• /cdrom

  • 윈도우 : E, F 드라이브
  • cdrom을 위한 마운팅 포인트. 잘 사용되지 않음.

• /media & /mnt

  • Media는 OS에서 자동으로 마운팅해주는 포인트, Mnt는 사용자가 직접 마운트하는 경로로 사용됨. 예를 들어 컴퓨터에 USB꽂아 OS에 자동으로 마운팅된다면 주로 Media 폴더, 외부에 있는 디스크등을 직접 명령어를 통해 마운트한다면 Mnt 디렉토리에 위치하게 됨.

• /dev

  • device의 약자. 모든 것은 파일이다 라는 모토에 맞게 키보드, 마우스, 프린터등과같은 디바이스들은 파일 또는 디렉토리의 형태로 dev 폴더 안에 존재. 읽기 쓰기도 가능하며 디렉토리 어디서든 접근 가능.

Path

• / : root 디렉토리

• ~ : home 디렉토리

• 절대경로 : Absolute path => 절대적 경로 경로를 표현하는 방식이 root디렉토리 부터 시작한다는 점 (Ex /home/eun/bin)

• 상대결로 : Relative paith. 현재 자신의 위치를 기반으로 움직이는 경로 (Ex cd..)

  • . : 현재 경로
  • .. : 상위 경로

• 누가 서비스를 사용하는지를 확인하는 절차

웹사이트에 사용자 아이디와 비밀 번호를 넣어서, 사용자를 확인하는 과정

• API도 마찬가지로 API를 호출하는 대상을 확인하는 정차가 필요 => API 인증

인가 (Authorization)

• 해당 리소스에 대해서, 그 리소스를 사용할 권한이 있는 지 체크하는 권한 체크 과정

/user라는 리소스가 있을 때, 일반 사용자 권한으로는 내사용자 정보만 볼 수 있지만, 관리자 권한으로는 다른 사용자 정보를 볼 수 있는 것과 같은 권한 차이

네트워크 레벨 암호화

• 인증과 인가 과정이 끝나서 API를 호출하게 되면,네트워크를 통해서 데이털가 왔다갔다 하는데, 해커등이 중간에 이 네트워크 통신을 낚아 채서(감청) 데이터를 볼 수 없게 할 필요가 있음

네트워크 프로토콜단에서 처리하는 것을 네트워크 레벨의 암호화 EX) HTTP에서의 네트워크 레벨 암호화는 일반적으로 HTTPS 기반의 보안 프로토콜을 사용

메시지 무결성 보장

• 메시지가 중간에 해커와 같은 외부 요인에 의해서 변조가 되지 않게 방지하는 것

• 무결성을 보장하기 위해서 많이 사용하는 방식은 메시지에 대한 Signature를 생성 메시지와 같이 보낸 후에 검증하는 방식

EX) 메시지 문자열이 있을 때, 이 문자열에 대한 해쉬코드를 생성해서, 문자열과 함께 보낸 후 수신 쪽에서 받은 문자열과 이 받은 문자열로 생성한 해쉬코드를 문자열과 함께 온 해쉬코드와 비교하는 방법

API Key 방식

• 특정 사용자만 알 수 있는 일종의 문자열

API를 사용하고자 할 때, 개발자는 API 제공사의 포탈 페이 등에서 API Key를 발급 받고, API를 호출할 때 API Key를 메시지 안에 넣어 호출

• 서버는 메시지 안에서 API Key를 읽어 이 API가 누가 호출한 API인지를 인증하는 흐름

문자열 판단

• re 모듈을 사용 => match 함수에 정규 표현식 패턴과 판단할 문자열을 기입

re.match('패턴', '문자열')

문자열이 맨 앞에 오는지 맨 뒤에 오는지 판단

• ^문자열 => 문자열이 맨 앞에 오는 지 판단

• 문자열$ => 문자열이 맨뒤에 오는 지 판단

지정된 문자열이 하나라도 포함되는 지 판단

• 문자열|문자열

• 문자열|문자열|문자열|문자열

범위 판단

• [0-9]* => 문자(숫자)가 0개 이상인지

• [0-9]+ => 문자(숫자)가 1개 이상인지

문자가 한개만 있는 지 판단하기

• 문자? => 문자(범위)가 0개 또는 1개인지 판단

• [0-9]? => 숫자(범위)가 0개 또는 1개인지 판단

• .=> .의 위치가 1개 있는지 판단

문자 개수 판단

• 문자{개수}

• (문자열){개수}

• [0-9]{개수}

• (문자){시작개수, 끝개수}

• (문자열){시작개수, 끝개수}

• [0-9]{시작개수, 끝개수}

숫자와 영문 문자를 조합해서 판단

• a-z

• A-Z

• 가-힣

특정 문자 범위에 포함되지 않는지 판단

• [^범위]*

• [^범위]+

ORM (Objects Relational Mapper)

• 객체 지향적인 방법을 사용하여 데이터베이스의 데이터를 쉽게 조작 가능

ORM은 파이썬과 데이터베이스의 SQL 사이의 통역사

쿼리문이 없어도 Model Class을 통해서 객체를 만들고 이객체를 통해서 DB에 접근

ORM의 장점

• 빠르고 불필요한 것들을 자동으로 처리

• 선언문할당 종료같은 부수적인 코드가 줄고 객체에 대한 코드만 작성하니 가독성이 좋다

• 유지 보수와 재사용성

ORM의 단점

• ORM 라이브러리를 따로 공부가 필요

• 규모가 크거나 복잡한 프로젝트는 sql이 더 효율적

• SQL문을 추상적으로 구현하여, 복잡한 쿼리는 비효율적인 SQL 구문이 생성됨

QuerySet (쿼리셋)

• 전달받은 모델의 객체 목록

쿼리셋은 데이터베이스의 여러 레코드를 나타낸다

from .models import Category
Category.objects.all()

>>> <QuerySet [<Category: 제목1>, <Category: 제목2>] >

• objects => Model Manager

DB와 Django Model 사이의 QueryOperation(질의 연산)의 인터페이스 역할

QuerySet Method

.all()

• 테이블 데이터를 전부 갖고온다. 해당 쿼리셋의 모든 요소를 반환한다.

.values()

• 쿼리셋의 내용을 딕셔너리로 각 개체정보를 갖는 리스트 형태로 반환

#1
>>> Blog.objects.filter(name__startswith='Beatles')
<QuerySet [<Blog: Beatles Blog>]>

#2
>>> Blog.objects.filter(name__startswith='Beatles').values()
<QuerySet [{'id': 1, 'name': 'Beatles Blog', 'tagline': 'All the latest Beatles news.'}]>

.filter()

• 특정 조건에 맞는 Row들을 갖고오기 위해서 사용되는 메소드

.get()

• 하나의 Row만 갖고오기 위해서 사용되는 메서드

.get()은 쿼리셋이 아니라 모델 객체를 반환하는 메소드

.count()

• 데이터의 갯수(Row의 수)를 세기 위해 사용되는 메서

• 속성-값으로 이루어진 오브젝트를 전달하기 위해 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷

개방형 표준이란? 공개 표준은 기술표준이 문서가 공개되어 있으며 사용이 자유로운 경우 사용하는 용어

비동기 브라우저/서버 통신 (ALAJ)을 위해, 넓게는 XML(AJAX가 사용)을 대체하는 주요 데이터 포맷

JSON의 사용

1. 브라우저 확장 프로그램 또는 웹 사이트를 포함하는 JavaScript 기반 응용 프로그램을 작성할 때 사용

2. JSON 형식은 네트워크 연결을 통해 구조화 된 데이터를 직렬화 및 전송하는데 사용

JSON 데이터 타입

Number => JavaScript에서 배정되는 정밀한 부동 소수점 형식
String => 큰 따옴표를 사용한 유니코드
Boolean => true 또는 false
Array => 연속된 값들의 정렬
Value => string, number, true 또는 false, null 등
Object => 정렬되지 않은 key:value 콜렉션
Whitespace => 토큰쌍 사이에서 사용 가능
null => 비었음

• 정의하기 (define) : 0개 또는 1개 이상의 매개변수를 갖는다.
• 호출하기 (call) : 0개 또는 1개 이상의 결과를 얻는다.

함수 정의하기 => def

def "함수이름"(매개변수):
    pass  

인수와 매개변수

• 함수로 전달한 값을 인수라고 부른다.

• 인수와 함수를 호출하면 인수의 값이 함수 내에서 해당하는 매개변수에 복사된다.

함수 외부에서는 인수라고 하지만 내부에서는 매개변수라고 한다.

유용한 None

• None은 아무것도 없다는 것을 뜻하는 파이썬의 특별한 값

불리언 값의 False처럼 보이지만 다른 값을 의미 빠뜨린 빈 값을 구분하기 위해 None을 사용

위치 인수

• 값을 순서대로 상응하는 매개변수에 복사하는 위치 인수 (positional argument)

매우 일반적이지만 위치 인수의 단점은 각 위치의 의미를 알아야한다

키워드 인수

위치 인수의 혼란을 피하기 위해 매개변수에 상응하는 이름을 인수에 지정

• 위치 인수와 키워드 인수를 섞어서 쓸 때는 위치 인수가 먼저 와야한다.

기본 매개변수 값 지정

def menu(wine, entree, desert='pudding'):
    return {'wine' : wine, 'entree' : entree, 'desert' : desert}

>>> menu('chardonny', 'chicken')
{'wine' : chardonny, 'entree' : chicken, 'desert' : desert }

desert 인수를 입력하면 기본값 대신 입력한 인수(doughnut)가 쓰인다

파이썬 기술 면접 등장 예제

기본 매개변수값을 지정한 경우

def buggy(arg, result=[]):
    result.append(arg)
    print(result)

>>> buggy('a')
['a']

>>> buggy('b')
['a','b']

지정 안한 경우

def works(arg):
    result=[]
    result.append(arg)
    return result

>>> works('a')
['a']

>>> works('b')
['b']

내부 함수

def outter(a, b):
    def inner(c,d):
        return c+d
    return inner(a,b)

>>> outter(4,7)
11

• 내부 함수 = 반복문이나 코드 중복을 피하고자 또 다른 함수내에 어떤 복잡한 작업을 한번 이상 수행 할때 유용하게 사용

클로저

• 클로저 = 다른 함수에 의해 동적으로 생성, 외부 함수ㅜ로부터 생성된 변수값을 변경하고 저장 가능 함수

익명 함수 : lambda

def edit_story(words, func):
    for word in word:
        print(func(word))


>>> stairs = ['thud', 'meow', 'thud', 'hiss']

def enliven(word):
   return word.capitalize() + '!'

edit_story(stairs, enliven)

Thud!
Meow!
Thud!
Hiss!

람다를 사용

edit_story(stairs, lambda word: word.capitalize() + '!'

제네레이터

• 제네레이터 = 시퀀스를 생성하는 객체

제네레이터 = 한 번만 순회 할수있다. 리스트, 셋, 문자열, 딕셔너리는 메모리에 존재 제네레이터 = 해당 값을 즉석에서 생성하고 이터레이터를 통해 한 번에 하나씩만 전달 제네레이터 = 모든 값을 기억하지 않으므로 제네레이터는 다시 돌릴 수 없다.

데커레이터

• 가끔 코드를 바꾸지 않고 사용하고 있는 함수를 수정하고 싶을 대 ex) 함수에 전달된 인수를 보기 위해 디버깅 문을 추가

Decorator => 하나의 함수를 취해서 또 다른 함수를 반환하는 함수

재귀 함수

• 자기 자신을 호출하는 함수

• 테이블을 올바른 형태로 만들고 분리

제1정규형

• 반복되는 데이터를 가로(열 방향)가 아닌 세로(행 방향)로 늘리는 것

제1정규화에서는 테이블 분할과 기본키 지정이 이루어진다.

제2정규형

• 부분 함수 정속성을 찾아내서 테이블을 분할하는 것

  • ex) 함수 정속성이란? 키값을 이용해 데이터를 특정지을 수 있는 것

제3정규형

• 중복하는 부분을 찾아내어 테이블을 분할 하는 수법

정규화의 목적

중복되거나 반복되는 붑분을 찾아내서 테이블을 분할하고 기본키를 작성해 사용하는 것

하나의 데이터는 한곳에 있어야한다

• 데이터를 저장 및 보존하는 시스템

• 어플리케이션에서 데이터가 메모리상에서만 존재 애플리케이션 종료하면 메모리가 날라가 버림

• 그래서 나온것이 데이터 베이스 (장기 기간동안 보존하기 위해서 데이터 베이스 사용!

• 일반적으로 database => 관계형 데이터베이스(RDBMS)와 NoSQL로 명칭되는 비관계형 database

관계형 데이터베이스

Relational Database Management System

• 관계형 데이터란 서로 상호관련성을 가진 형태로 표현한 데이터

  • 모든 데이터들이 2차원 테이블로 표현

  • 각각의 테이블은 column 과 row 로 구성됨

  • 칼럼은 테이블의 각 항목

  • 로우는 각 항목의 실제 값

  • 각 로우는 저만의 고유의 키(Primary Key) 존재 Primary Key를 통해서 해당 로우를 찾거나 인용(reference)

테이블들의 상호관련성

• one to one

테이블의 기록된 유저는 유저 정보 카테고리의 하나의 정보를 가짐

• one to many

하나의 정보를 여러 관계를 가질 수 있음

ex) 각 고객은 여러 제품을 구매할 수 있지만 구매된 제품의 주인은 오직 한 고객뿐

• many to many

ex) 책은 여러 작가에 의해 쓰일 수 있고 작가들은 여러 책을 쓸 수 있다.

왜 테이블을 연결하는 가?

• 하나의 테이블의 모든 정보를 다 넣으면 동일한 정보들이 불필요하게 중복되어 저장됨

• 더 많은 디스크를 사용

• 잘못된 데이터가 저장 될 가능성 많음

• 여러 테이블에 나누어서 저장한 후 필요한 테이블 끼리 연결 시키면 2가지 문제 해결 가능

1. 중복된 데이터를 저장하지 않음으로 디스크를 더 효율적으로 씀
2. 서로 같은 데이터지만 부분적으로 틀린 데이터가 생기는 문제가 없어짐
3. 이것을 nomalization (정규화)

ACID(Atomicity, Consistency, Isolation, Durability)

• 원자성, 일관성, 고립성, 지속성

• 원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다. 예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안된다. 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것이다.

• 일관성(Consistency)은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다. 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단된다.

• 고립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없다. 공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건이다. 자세한 내용은 관련 문서를 참조해야 한다.

• 지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미한다. 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.

트랜잭션 (Transaction)

• ACID를 제공함으로 따라서 트랜잭션(일련의 작업들을 한번에 하나의 unit으로 실행하는것) 기능을 제공하다.

  • 트랜잭션은 일련의 작업들이 마치 하나의 작업처럼 취급되어서 모두 다 성공하거나 아니면 모두 다 실패하는걸 이야기 한다.

  • Commit & rollback