#웰컴 스프링 #바이 파이싼!

  1. 그 이름도 어렵다는 spring을 배우기 시작했다.

진도를 따라가는것 조차 버겁지만.. 잠이 많은 나를 반성하게 만드는 일주일이다.

노션을 통해 정리한 내용을 하나씩 옮겨보려고 한다.

  1. 자바란 무엇일까? -> 내가 아는 자바는 이클립스를 사용해 jsp,html로 웹페이지를 만들거나

    -> 이클립스 안에서 java언어로 문제해결기법을 응용한 문제 해결들

  2. 생각보다 어렵지 않았다. ->? becuse 상속과 캡슐화에 대한 지식은 Skip 해버린것..

개발자적인 생각을 가진 지금에서야 상속과 캡슐화는 아름답고 개발자를 살게해주는 아주 좋은 놈들이란걸,,, 뒤늦게 깨닫는다.

OOP의 대표적인 언어로 모듈 형식의 프로그래밍을 캡슐로 묶거나 한 개체를 현실에 빗대어 언어로 표현한다 로 정의 할 수 있엇다.

스프링은 Java언어를 사용하는 프레임워크로, 아직 단어에 대한 지식이 부족한 상태이다.

java로 넘어와서, java는 객체 단위로 프로그램을 진행하며 이 행위를 상향식 접근 방식이라고 한다.

이식성이 높아서 서로 다른 환경(OS) 이어도 캡슐화, 상속성, 다형성을 100% 제공해준다.

인터프리터 언어임과 동시에 컴파일 언어이다 -> 잘 몰랐는데 build이후에 생기는 폴더를 보면 알 수 있다.

개발의 편의성에 몰빵된 언어로 언어 자체의 이해를 위해선 대표적인 프로그래밍 언어들 가운데 손에 꼽게 어렵다

기본레이어는 MVC (Model View Control)과 유사하다 CSR 으로

  1. Controll
    • 클라이언트의 요청을 받고 요청에 대한 처리는 서비스에게 전담한다.
    • 클라이언트에게 응답을 한다
  2. Service
    • 비지니스 로직을 처리한다 이때 비지니스 로직은 서버에서 사용자의 요구사항 처리를 말한다.
    • DB에 접근하여 정보가 필요할 때 Respository에 전달한다.
  3. Respository
    • DB를 관리한다. ` EX) 연결, 해제 ,자원관리`
    • DB의 C,R,U,D 작업 처리

image

ㄱ. Annotation -> Java코드에 @로 시작하여 클래스나 메소드 선언문 바로 위에 사용된다.

-> 어노테이션은 코딩 할떄는 @로 표시만 하면 되지만, 컴파일 될 때 약속했던 특별한 의미를 가지게 되는데, 어노테이션 같은 경우에는 방대한 양을 가지기 떄문에 필요한 부분은 서칭하며 해결하자.

ㄴ. Class -> 앞서 말하듯 Java는 Class 단위로 수행한다.

-> 예를들면 동물 카테고리에 강아지와 고양이가 있다.

-> 이 강아지에는 강아지를 구성하는 action과 element가 존재하는데.

-> Dog 라는 변수에 Animal 이라는 틀에 담기게 되는 것 처럼 말이다.

ㄷ. OOP란 -> Object-Oriented-Programming 으로 질서 없는 호출과 실행을 배제하고, 현실 세계에 최대한 빗대어 프로그램을 작성하기 위해 사용된다.

ㄹ. Constructor -> 생성자로써, 클래스명과 똑같은 이름을 가진 메소드를 칭하고, 클래스 변수를 새롭게 만들 떄 사용한다.

`ex : 호빵맨이 머리를 타치거나 먹고 새로운 호빵맨 머리를 장착하듯..`
호빵맨= new 호빵맨

새로운 머리를 장착 할 때마다 this로 연결 해주는것이 Constructor의 핵심이 되지 않을까..

오늘의 Trouble shooting

오늘은 Login 부분을 조짐 해버렸다.

  1. login_check(f)

    • @wraps(f)의 첫 사용.. 두근두근

    • acces_token을 발급하고 header단에 보내버리기

access_token = request.headers.get("Authorization") - 너무 간단하게 해결했다. request를 이용해서 headers 단에 Authorization 해버리기..

  - 또! g를 이용해 전역보다 더 큰 전역으로 만들어버리기

  ` g.user_id = user_id `

userinfo에 token값을 받아 user를 특정 할 수 있는 키들들 매번 서버에서 처리했는데 서버리스 대비를 위해 서버사이드 랜더링을 제거하는 과정에서 Auth 이슈를 한번에 처리하기 위해 코드를 수정했다.

  1. ajaxSetup

    • 만능 해결사 느낌으로 다가온 ajaxsetup은.. 사실 이빨빠진 호랑이였다.

    • 내가 튜터님이 설명하는대로 들었을떄는 페이지 생명주기에 맞게 시작되는 부분부터

    소멸하는 단까지 모든 page에 ajax를 뿌려주는 줄 알았는데 클라이언트 단위로 ajax를 해왔다.

    그래서 document.ready단으로 처리해줫는데 맨처음에는 다른 함수가 실행되고 실행했는데 오류가 빈번하게 일어나서 맨처음 화면이 실행되자마자 체크하도록 맨윗부분으로 이동시켰다.

` 잠시만?! 그러면 ajaxsetup을 함수로 만들고 … 코드 한줄로 줄이면?! 꼭 해봐야겟다..`

  1. async
  • 처음 써봣다. 무지 쉽더라

빵을 만들기전에 오븐을 예열해두는것이 효율적이듯 함수 호출도 똑같다. main_page에서 user_id를 받아와 user의 til을 작성했는지 체크하는 구문에서 user_info를 토큰에서 받아왓는데 서버리스 사태로 token이 비어버리니 flag를 어디서 따와야하나 막막했다. user_id를 g.user_id를 통해 id를 login이후 접근시에 headers단에 접근하여 받아오고 til을 체크하는 함수에 넣고 돌렸는데 주구장창 에러만 떳다.

-> 지금 생각하니 멍청햇지.

user_id를 받아오지도 않앗는데 til을 작성했는지 찾고있으니.. 오류가 뜰 수 밖에. 그래서 제일 처음 실행되어야할 user_id를 받아오는 함수에 async를 달고 다음 함수가 호출되는 부분에 await를 걸어줫다, 호출되는 함수에는 async: false를 꼭 추가해줘야한다. 하향식도 , 상향식 접근도 아닌 python은 무근본으로 비동기 접근방식이기 떄문에 async남발은 해결 할 수 없는 이슈인듯하다.

  1. localStorage.setItem
  • 앞서 cookie 로 정체없이 떠돌던 우리의 token은 서버리스 환경에 대응하기 위해 == (서버리스는 url이 전국구다) localStorage에 적재했다. 생각보다 간단했다. 발급된 token을 setitem으로 token을 localStorage에 박제해버렸다. 크크크
  1. xhr.setRequestHeader(‘Authorization’, localStorage.getItem()
  • xhr // httprequest중에서도 header단에 접근하기 위해 사용된다 이부분에 대한 학습은 더 필요하다, 꼭 더욱 더 알아보도록 하자. request를 이용해 header단에 있는 Authorization:localStorage.getItem()을 통해 token을 검사하고 검증이 완료된 상태 이기 떄문에 “검사”만 진행한다.

쓰다보니 많은 시간이 지나버렸다. 남들은 정보글도 적고 til도 넉넉하게 적던데… —

오늘은 기분이 너무 좋다.

팀원들간의 협업이 너무 잘 되는 것 같다

나만의 착각이 아니길 빌면서.

이번달 목표는

image 잔디심기!!