📝 회고/✅ 22년 회고42 [일일 회고] 22.05.23 - "AWS VPC, 숙박앱 프로젝트와 Events storming, Boris diagram, Snap-E" 📚 배운 것 AWS VPC 코드스쿼드 호눅스의 마스터 클래스 시간에 Network와 AWS의 VPC에 대해 이론과 실습을 배웠다. CIDR(Classless Inter-Domain Routing) CIDR는 클래스 없는 도메인 간 라우팅 기법으로, 기존 네트워크 클래스(A, B, C, ...)를 대체하였다. 기존 네트워크 클래스의 고정된 네트워크/호스트 개수를 유동적으로 변경하게 만들 수 있게 prefix를 커스텀 설정할 수 있다. 기존 네트워크 클래스를 대체했다고 생각 못하고 있었다. VPC AWS - VPC(Virtual Private Cloud)이란? : AWS에서 독립된 가상 네트워크 만들기 글을 쓰며 VPC 기본은 요약했었다. 부족했던 내용을 호눅스가 채워줬다. NAT을 사용하여 private .. 2022. 5. 23. [일일 회고] 22.05.18 - "DB 트랜잭션, JPA를 배우기까지" 📚 배운 것 DB 트랜잭션에 대하여 코드 스쿼드 호눅스의 마스터 시간에 DB 트랜잭션에 대해 배웠다. 무척 값진 시간이었다. Jim Gray 소개 Jim Gray는 DB 발전에 큰 기여를 했다. 세계 최초의 관계형 데이터베이스인 System-R을 개발했다. 트랜잭션, 2 Phase Locking, Granularity Locking 개념을 제안했고 1992년 명저 "트랜잭션 처리: 개념과 기법(Transaction Processing: Concepts and Techniques)" 를 썼다. 트랜잭션의 성질 A: Atomicity(원자성) : all or nothing C: Consistency I: Isolation D: Durability 트랜잭션이란 트랜잭션은 작업의 완전성을 보장한다. 여러 읽기/.. 2022. 5. 19. [일일 회고] 22.04.19~20 - "Mockup API 서버, 기능 요구사항 분석과 개발 기간 결정, 테스트 코드 전도(?)" Mockup API 서버 상황 반찬가게 웹 개발 프로젝트를 시작됐다. 기획서만 주어졌다. API, DB 설계할 시간 없이 프론트, 백엔드 개발이 시작됐다. 문제 API, DB 설계안 없이 시작하다 보니 프론트 개발자는 단순 view, 디자인을 그릴 수 있었지만 비즈니스 로직을 구현할 수 없었다. API 서버가 없기 때문이다. 백엔드 입장에서 당장 API 서버를 제공해주고 싶었지만 API, DB 설계할 시간과 서버 구현할 시간도 필요했다. 해결 Mockup API Sever를 도입하기로 했다. Mockup API는 코딩 없이 비교적 간단하게 만들 수 있었기에 프론트엔드와 함께 설계하며 만들 수 있었다. 백엔드 입장에서 프론트엔드가 원하고 필요한 API 피드백을 빠르게 받을 수 있고, 프론트엔드는 실 AP.. 2022. 4. 20. [일일 회고] 22.04.18 - "협업하기, 상황에 맞는 아키텍처와 FE/BE 배포, DB 모델링" 📚 배운 것 쇼핑몰 웹 협업 프로젝트 시작 with FE & BE 이번에는 프론트엔드와 백엔드, 총 4명이 모여 반찬가게 쇼핑몰 웹 애플리케이션 프로젝트를 시작했다. 어색한 분위기를 탈피하고자 웃고 떠들고 힘이 나는 말을 의도적으로 했다. 협업을 위해 그라운드 룰을 정했다. 이젠 함께 룰 정하는 것이 익숙해졌다. 저번 프로젝트에서 클라이언트 개발자가 View 개발에 부담을 느낀다고 했다. View 개발 집중을 도와주기 위해 공통 업무를 백엔드에서 주로 맡았었다. 이번 클라이언트 개발자는 여유가 있어 보였다. 이번엔 모두가 즐겁고 의견을 말할 수 있는 분위기를 만들 수 있겠다는 생각이 들었다. 혼자 하면 10분이면 할 수 있는 일을 굳이(?) 작은 일로 나누었다. 프로젝트에 함께 한다는 유대관계를 쌓는게 .. 2022. 4. 18. [일일 회고] 22.04.13 - "DB 정규화와 프로젝트 코드 리뷰" DB 정규화 오늘은 호눅스 마스터 클래스 시간에 DB 정규화에 대해 이야기 나눴다. 무척이나 유용한 시간이었고 다소 수학적일 수 있는 접근을 말로 풀어 설명해준 호눅스에 감사함을 보내며 간단히 정리한다.(틀릴 수 있다) 데이터베이스 설계 데이터베이스 설계란 테이블을 만드는 과정이다. 테이블을 만드는 과정은 애트리뷰트(속성)를 어떻게 묶을 것인지 결정하는 것이다. 좋은 테이블을 설계한다는 것은 애트리뷰트를 잘 묶는 방법이다. 잘 설계된 테이블이란 다른 테이블의 애트리뷰트 값을 읽어오는 것은, 외래키의 참조를 통해서만 가능해야 한다. 잘못된 테이블 설계의 문제점 1. 데이터 중복 발생 하나의 테이블에 모든 속성이 들어있을 수 있다. 하지만 공간이 낭비된다. (현대는 저장비용이 저렴해 문제가 되지 않을 수 있.. 2022. 4. 13. 이전 1 2 3 4 5 ··· 9 다음
