코린이 성장일기

1. 프로세스 처리 방법- 비효율적 : 프로그램1 -> CPU -> RESULT -> 프로그램2 -> CPU - RESULT (Sequential Program- 효율적인 방법 : - 병행처리 (Concurrency) 한개의 코어에서 여러프로그램을 돌아가면서 처리 / 다른 프로그램이 실행되는 Context Switching -  병렬처리 (Parallelism) 멀티코어에서 각각 코어가 여러 프로그램을 담당하여 처리 2. 프로세스 관련 리눅스 명령어 익히기ps // 프로세스 확인ps grep // 특정 프로세스 확인kill // 프로세스 종료 Ctrl + C : 프로세스 종료Ctrl + Z : 프로세스 일시중지 jobs : 실행중인 프로세스 확인fg %숫자 : jobs 에서 확인된 프로세스 번호를 다시 ..

1. 컴퓨터 구조 기초- 의사결정 및 계산 : CPU- 중/단기 기억 : RAM- 장기기억 : DISK (HDD, SDD 등) 2. 컴퓨터의 구조와 실행입력장치 -> CPU / RAM -> 출력장치 / DISK 3. CPU : Central Process UnitCPU = CU(Control Unit) + ALU(Arithmetic and Logical Unit) + Memory Unit(cache memory)- CU : 연산을 하기 위한 제어를 수행- ALU : 실제 연산을 수행- Memory : 저장소 역할1) clock frequency : cpu의 동작 속도 1Hz = 1 cycle/s2) multi core  4. RAM RAM : Random Access Memory - 역할 : Primar..

주간 보고 양식(토요일)이번 주 목표 달성 여부 및 다음 주 목표 설정 : 이번주는 기초주차가 마무리 되는 주차로, 마무리 프로젝트를 마치는것을 목표로 했다.  목표한 기능의 90프로 이상 달성한 것 같지만 아직 자잘한 버그 및 확인하지 못한 버그 들이 있을 것으로 생각된다. 부족한 점 : 강의를 들으면서 블로그에 저장한 내용들이 많았는데 막상 실전에 적용해보니 잘 안되는 경우도 많았고, 기억이 안나는 경우도 많았다. 그래도 프로젝트를 진행하며 복습한다는 느낌이었고, 다시 복습해보면서 주석도 꼼꼼하게 달아서 다음에 좋은 참고자료가 될 것 같다. 스스로 시도해본 것들 : 이번 프로젝트에서는 chat GPT를 많이 활용했다. 너무 의존하는 것은 안좋겠지만, 적당히 활용하면 좋은 도구로 사용할 수 있을 것 같..

중간 보고 양식(월~금요일)TO-DO LIST : 오늘의 할 일 작성배운 내용 요약 정리 : 강의 수강 후 배운 내용을 나만의 방식으로 정리1. firebase로 이미지 파일 다루기1-1. firebase Storage / 주소는 firebase console에 들어가면 확인 가능.import { initializeApp } from "firebase/app";import { getStorage } from "firebase/storage";// TODO: Replace the following with your app's Firebase project configuration// See: https://firebase.google.com/docs/web/learn-more#config-objectcon..

중간 보고 양식(월~금요일)TO-DO LIST : 오늘의 할 일 작성배운 내용 요약 정리 : 강의 수강 후 배운 내용을 나만의 방식으로 정리1. Firebase : 구글에서 제공하는 개발 플랫폼.- 서버 없이 DB, 인증, 이미지 업로드, 배포 등 기능 제공- 무료 제공 범위가 넓음- 실시간 DB지원- 빠르게 애플리케이션 제작 가능- 소규모 프로젝트에 적합 1-1. Prototype, POC(Proof of Concept),  MVP(Minimum Viable Product) 등을 만들때 주로 사용 2. firebase 시작- firebase 설치 : npm install -g firebase-tools- 로그인 : firebase login- 초기화 : firebase init- 배포 : firebas..

1. CSR : Client Side Rendering 의 약자. - 렌더링이 클라이언트 쪽에서 일어난다. - 서버는 요청을 받으면 요청에 해당하는 HTML과 JS를 보내주고 클라이언트는 이것을 받아서 렌더링을 시작한다.- 서버에서 아무 처리 없이 클라이언트로 보내주기때문에 모든 리소스가 다운로드 되고나서 사용자가 내용을 볼 수 있다. 2. SSR : Server Side Rendering의 약자- 서버 쪽에서 렌더링이 일어난다.- 서버에서 이미 렌더링 가능한 상태로 전달하기 때문에 다운로드 되는 동안 사용자는 다운로드 되는 만큼 내용을 볼 수 있다.  3. CSR과 SSR의 차이 1) 로딩시간 : 첫 페이지를 로딩하는 경우는 SSR이 필요한 부분만 불러오기 때문에 SSR이 빠르지만, 다른 페이지로 이동..

1. 인증과 인가 1) 인증 : 사용자가 서버에 로그인을 요청하면 서버가 해당 사용자가 맞는지를 검증하는 과정. 로그인 등 증명과 관련.  2) 인가 : 인증 이후에 인증된 사용자에 대한 자원 접근 권한 확인 절차. 글 작성, 수정, 삭제 등 권한과 관련. 2. HTTP의 비 상태성 (Stateless) 서버는 클라이언트의 상태를 저장하지 않기 때문에 클라이언트의 요청이 있을 때 마다 새로운 인증 절차를 거쳐야 한다.하지만 이렇게 되면 서버에 요청을 보낼때마다 로그인을 하도록 요청을 해야 하는데 이는 매우 불편한 방식이다.  3. 인증 과정1) 세션 기반 인증세션 기반 인증은 사용자의 인증 정보를 서버에서 저장하고 있는 방식이다. 클라이언트가 로그인을 하면 서버는 인증 정보를 서버의 세션 저장소에 저장하..

def login(response:Response....):     access_token = manager.create_access_token(    data={"sub": {"id": user["id"], "name": user["name"], "email": user["email"]} } )    # access_token 발급 response.set_cookie(key="access_token",value=access_token,httponly=True)   1. 서버에서 쿠키 설정: 서버에서 사용자 인증 후, JWT 토큰을 생성하고 이를 쿠키에 저장해야 합니다. 이를 위해 HTTP 응답 헤더에 **Set-Cookie**를 설정하여 토큰을 전달합니다. FastAPI에서는 response.set_c..

배운 내용 요약 정리 : 강의 수강 후 배운 내용을 나만의 방식으로 정리1.  웹 프레임워크 1-1. SVELTE vs React1-2. 번들러 (ex. vite[비트])1-3. Firebase : 백엔드 구축 없이 백엔드 역할. / 실시간 DB, 이미지파일 업로드, 유저인증(소셜 로그인) 1-4. 배포!! 2. 번들러가 왜 필요한가?1) Java Script - 간단한 동작을 위해 만들어짐- 모듈 방식이 없는채로 탄생- 하나의 파일을 여러사람이 개발한다면? 관리도 힘들고 찾아가기도 힘들고...2) 모듈 방식이 필요하다- CommonJs라는 모듈 방식이 처음 도입.- npm의 등장으로 모듈을 모두가 공유할 수 있게 됨.- node.js, npm 등이 탄생. 3) 번들러의 탄생- 여러개의 파일을 하나로 합..

배운 내용 요약 정리 : 강의 수강 후 배운 내용을 나만의 방식으로 정리1. JWT란?- JSON Web Token의 약자로, 유저 인증과 관련된 기술.- Base64로 인코딩 되어 있음- JWT는 사용자 정보를 토큰에 포함시킴.(세션은 사용자 정보를 서버측에서 DB를 통해 관리)- 특정 시간이 지나면 refresh token 발급으로 보안성 향상1-1 Refresh Token1) Access Token의 유효기간은 짧다. (ex. MS:60days, Amazon:1hour)2) Refresh Token의 유효기간은 길다. (ex. MS : 1year)3) 평소에 API 통신할 때는 Access Token을 사용하고, Refresh Token은 Access Token이 만료되어 갱신될 때만 사용한다.즉,..