데이터베이스

- Transaction

Transaction이란 데이터베이스의 상태를 변화(DB에 접근)시키기 위해 수행하는 작업 단위이다.

하나의 SQL 명령문도, 여러개의 명령문을 한번에 실행하는 것 모두 Transaction으로 4가지의 특성을 가진다.

1. Atomicity(원자성) : Transaction이 DB에 모두 반영되던가 아예 반영되지 말아야 한다.

2. Consistency(일관성) : Transaction의 작업 처리 결과가 항상 일관적이어야 한다.(작업 중에 참조하던 테이블이 변경된다 하더라도 Transaction 시작 시의 원본 테이블을 참조)

3. Isolation(독립성) : Transaction은 실행중인 다른 Transaction에 절대 끼어들 수 없다. 

4. Durability(영구성) : Transaction이 완료되었을 경우, 결과는 영구적으로 반영되어야 한다.

 

커밋을 완료해야 Transaction이 종료된다.

rollback을 통해 ctrl + z가 가능하지만 DDL문(CREATE, DROP, ALTER, RENAME, TRUNCATE)는 rollback이 불가능하다.

알고리즘

- 프로그래머스 : 피로도(Level 2, 완전탐색)

- next_permutation (c++ <algorithm>)

순열을 이용한 완전 탐색 문제인지라 c++ next_permutation을 이용하여 풀었다.

이 과정에서 next_permutation 함수의 작동방식을 배웠는데 가장 큰 원리는 주어진 벡터에 나열된 값에서 '더 내림차순 스러운 다음 순열을 찾는 방식'이다.

예를 들어 내가 {1,4,2,3} 벡터에 next_permutation을 호출하면 그 다음 내림차순스러운 {1,4,3,2} 그 다음에는 {2,1,3,4} 이런 방식이다. 

더 놀라운 점은 만약 {4,3,2,1} 벡터에 n_p를 호출하면 False를 반환하면서 그냥 끝난다. 어떤 벡터에 하든 모든 경우의 수 찾는 줄 알았는데 아니었다. 이제 활용 쉬울 듯 합니다^^. 더 오름차순스러운 순열을 원한다면 previous_permutation도 있다.

 

느낀 점

주말에 충격적인 바선생님 출몰로 시간 관리에 실패한 후, 오늘 허겁지겁 과제하느라 Spring 개념은 대강 훑고 지나갔다. 처음 듣는 용어들 많았는데 내일은 상세히 파악해봐야지

'TIL' 카테고리의 다른 글

[23.11.08]  (0) 2023.11.08
[23.11.07]  (1) 2023.11.07
[23.11.03]  (1) 2023.11.03
[23.11.02]  (0) 2023.11.02
[23.10.31]  (0) 2023.10.31

오늘 배운 것

Spring 기초

 - JDBC

JDBC는 자바에서 제공하는 표준 DB 연결 인터페이스이다.

원래는 DBMS 회사마다 connection, query 보내기, 데이터 받기 등등의 설정이 다 달라서 서버 측에서 설정을 일일이 해줘야 했었고 DBMS가 바뀔 때도 또 다시 설정을 바꿔주어야 했었다.

그러나 자바가 JDBC API를 제공하면서 부터 회사에서 이 인터페이스를 구현하는 코드를 라이브러리 형태로 배포해주기 때문에 우리는 DBMS 드라이버만 설치하면 편하게 설정이 완료된다.

 

 - 3-tier architecture

3-tier architecture는 서버를 프레젠테이션 계층 - 비즈니스 계층 - 데이터 계층으로 구분하여 개발하는 구조를 뜻한다.

처음에는 MVC와 차이점이 무엇인지 3-tier의 한 방법론이 MVC인지 헷갈렸는데 넘 좋은 글이 있었다.

https://co-no.tistory.com/120

요약하자면 MVC 패턴은 비즈니스 로직과 UI의 책임을 구분한다는 장점은 여전하지만. 비즈니스 로직의 크기가 커져가면서 Controller부분과 Model 부분을 더 세분화하여 개발하는 것이라 이해했다.

 

- IOC(제어의 역전)와 DI(의존성 주입)

IOC는 외부에서 구현체를 주입(DI)받아 강한 결합을 막고이는 코드 유지보수의 효율성을 높여준다.(의존성 주입시 어떤 인터페이스를 주입할 지 한번만 갈아끼우면 됨.)

우리는 DI 디자인 패턴을 통하여 IOC 설계 원칙을 지킨 것.

알고리즘

- 프로그래머스 : 카펫(Level 2, 완전탐색)

느낀 점

처음 들어보는 내용이 나오면서 좀 오래 걸리는데 이제 구현을 따라치는 것만으로는 이해가 어려운 수준에 온 것 같다.

다양한 글들을 읽어보며 수준높은 이해를 해야할 듯 하다.

'TIL' 카테고리의 다른 글

[23.11.07]  (1) 2023.11.07
[23.11.06]  (0) 2023.11.06
[23.11.02]  (0) 2023.11.02
[23.10.31]  (0) 2023.10.31
[2023.10.27]  (0) 2023.10.27

오늘 배운 것

Spring 기초

- MVC 패턴

Model, View, Controller로 구성된 디자인 패턴으로 Spring에서는 이를 채택하고 있음.

Model의 역할은 비즈니스 로직 + DB에서 데이터를 넣었다 뺐다.

View의 역할은 사용자가 보는 것 + 사용 인터페이스

Controller의 역할은 Model과 View의 상호작용을 제어

 

이 친구가 front controller 방식을 채택한 servlet 작동방식

  1. 요청이 들어왔어요
  2. 디스패처 서블릿이 이 요청을 분석함. 이 분석한 데이터을 토대로 핸들러 매핑을 통해 컨트롤러 요청을 찾아주게 된다. 핸들러 매핑에는 api path와 controller 메서드가 매칭되어 있음. ex) GET /api/hello면 HelloController의 hello() 함수를 호출하도록.
  3. 이 매칭된 정보를 디스패처 서블릿이 확인한 다음에. 해당하는 컨트롤러에 요청을 전달(dispatcher) . 서블릿을 다 만들어주지 않아도 컨트롤러에 해당하는 클래스를 만들고 @Getmapping 선언해 놓고 연결 잘 해주면 되는구나!
  4. 요청에 대한 처리가 완료되었으면 결과 + 뷰에 대한 정보를 모델에 담아준다. 뷰에 대한 정보 예시. 로그인 하고 마이페이지를 요청했는데 거기 마일리지가 나와야할 것 아니냐. 이걸 컨트롤러에서 디비 연동해서 몇 포인트 있는지 알려준다는 뜻. + mypage.html 이 이름 자체.
  5. 뷰 리졸버에서 뷰에 대한 정보들을 받아와서 뷰에 적용을 함
  6. 뷰 반환

DispatcherServlet이 적절한 컨트롤러에 요청을 전달해주어서 Servlet을 많이 만들 필요가 없어지고 controller 로직에 집중이 가능.

알고리즘

- 프로그래머스 : 소수 찾기(Level 2, 완전탐색)

느낀 점

알고리즘 스터디 시작, 하루 한 문제, 성공적.

'TIL' 카테고리의 다른 글

[23.11.06]  (0) 2023.11.06
[23.11.03]  (1) 2023.11.03
[23.10.31]  (0) 2023.10.31
[2023.10.27]  (0) 2023.10.27
[23.10.25]  (0) 2023.10.25

오늘 배운 것

웹 동작 방식

- IP주소, 브라우저, DNS

- HTTP : 송,수신 측의 통신규약이 프로토콜이고, HTTP는 웹에서 가장 많이 쓰이는 프로토콜이다.

- API : 서버의 창구 역할, 다른 소프트웨어와 통신하기 위해 따라야 하는 규칙

- 서버의 역할 : 예전에는 document를 잘 주는 게 서버의 역할이었지만 인터넷 발달이 고도화 되면서 이제는 json같은 데이터만 넘겨주고 DOM 구성은 프론트 단에서 잘 처리한다.

- REST(ful) API : REST는 소프트웨어 아키텍처의 일종이고 api 설계만 적절하게 해줘도 RESTful 하다고 말할 수 있다. (URL 고유하게 만들고, 적절한 HTTP 메소드 활용한다면)

- DB의 역할은 데이터를 성능 좋게 이용하기 위함

서버에 대한 이해

- 새로운 데이터를 처리하는 부분(Presentation 계층) - 서비스 로직을 처리하는 부분(Domain계층) - 기존의 데이터를 이용하는 부분(data access 계층) 으로 레이어드

- Presentation 계층 : 사용자와 상호 작용 처리. CLI, HTTP 요청, HTML 처리. URL 매핑해서 특정 함수가 호출되게 하는 것. 스프링에선 @Controller

- Domain 계층 : 핵심 로직이 포함된 계층. '유효성 검사' 및 '계산'. 서버 프레임워크가 유능해지면서 Domain 계층에만 집중할 수 있게 됨. 스프링에선 @Service

- Data Access 계층 : (대부분) 서버 외부에 있는 DB와 소통하는 계층. 스프링에선 @Repository

DB 기초

- in-memory DB는 서버가 멈추면 데이터도 휘발됨

- SQL : Structured Query Language. 표준이 존재하나 DBMS회사별로 약간의 차이가 있음. DDL, DCL, DML로 구성

- DDL : Data Definition Language. Data Definition Language 테이블이나 관계의 구조를 생성하는 데 사용
CREATE, ALTER, DROP, TRUNCATE - DB와 테이블을 생성, 수정, 삭제

- DCL : Data Control Language - 데이터의 사용 권한을 관리

GRANT, REVOKE - 사용자 또는 ROLE에 대해 권한을 부여, 회수

- DML : Data Manipulation Language - 테이블에 데이터를 검색, 삽입, 수정, 삭제
INSERT, SELECT, UPDATE, DELETE

- 데이터의 무결성 (data integrity) : 완전한 수명 주기를 거치며 데이터의 정확성과 일관성을 유지하고 보증

- 개체 무결성 : PRIMARY KEY와 관련. 모든 테이블이 primary key를 가져야 하며 primary key로 선택된 열은 고유해야 하고 NULL 은 허용하지 않는다.

- 참조 무결성 : FOREIGN KEY와 관련. PRIMARY KEY와 FOREIGN KEY 간의 관계가 항상 유지되어야 함. 예를 들어 참조되고 있는 속성 값(PRIMARY KEY를 가진)은 함부로 삭제될 수 없음.

- 범위 무결성 : 한 컬럼에 대해 NULL의 허용 여부와 타당한 데이터 값들을 지정. 자료형, 규칙과 제약, 값 범위들을 제한

- ERD : Entity Relationship Diagram. 개체-관계 모델. 테이블 간의 관계를 설명해주는 다이어그램으로 API를 효율적으로 뽑아내기 위한 구조도.

- CASCADE, JOIN, CONSTRAINT 등등...

느낀 점

팀원분들 잘 만난 것 같아 1차적으로 기분이 좋지만 내가 듣지도 않고 졸업해버린 DB가 나와서 좀 헷갈린다. JOIN도 기본적인 것만 다뤘는데 실습 쿼리짜기에서 틀린 부분도 있고 불안하지만 화이팅.

'TIL' 카테고리의 다른 글

[23.11.03]  (1) 2023.11.03
[23.11.02]  (0) 2023.11.02
[2023.10.27]  (0) 2023.10.27
[23.10.25]  (0) 2023.10.25
[23.10.24]  (0) 2023.10.24

오늘 한 일

팀 프로젝트

- 팀 프로젝트 마무리 및 KPT 회고

인텔리제이 Ultimate에는 클래스 다이어그램을 그려주는 기능이 있다.

github에서 fork하지 않은 채 contributor가 되면 내 repository에 뜨지 않는다.

알고리즘

- 백준 1967 트리의 지름(Gold 4, DFS)

강연

- 좋은 개발자가 되기 위한 비밀.

느낀 점

팀 프로젝트 마무리하면서 이것저것 수정하면서 오후까지 보냈다. 오늘 새로운 개념을 배운 것은 없지만 주말에 글 하나 쓰면서 뇌 건강을 챙겨야겠다.

'TIL' 카테고리의 다른 글

[23.11.02]  (0) 2023.11.02
[23.10.31]  (0) 2023.10.31
[23.10.25]  (0) 2023.10.25
[23.10.24]  (0) 2023.10.24
[23.10.23]  (0) 2023.10.23

오늘 한 일

Git

- 팀원 분의 git 특강

오늘 오전에 설계 다 끝내기로 했는데 내가 또 git 오류가 나서 다시 git 공부에 들어가고 팀원분이 특강도 해주셨다.

내가 헷갈린 부분은 local과 origin(forked된 repository)의 branch를 동일하게 여겼다는 것이다.

 

내가 작업중인 branch로 원본 repo에 올라가있는 코드를 받아오기 위해서는

git fetch upstream(원본 repo의 별칭으로 내가 지정해둔 이름이다)    명령어를 통해 업데이트된 내용이 있는지 확인한다. 그 후

git merge upstream/dev(가져오고 싶은 branch 명)  으로 병합하면 된다.

 

내 작업물을 push하고 싶을 때는 add commit 후 git push origin jdh(branch명) 하면 내 forked repo에 올라가고 그러면 github 웹페이지 내에 pull request가 뜬다. wkdehdgk159/jdh에서 원본 repo/원하는 branch 인지 꼭 확인할 것.

객체지향 이모저모

- 객체지향 설계의 느낌적인 느낌

우리 호텔 예약 프로그램의 큰 설계는 이런 구조이다.  호텔(완전 주인님) - Handler(로직을 수행하는 직원들) - dao(데이터를 조회, 전달만 해주는 노예느낌). 그리고 나머지 객체들이다. 패키지로 구분하자면 domain(수동적으로 정보만 가진 친구들), handler, dao 로 구성되어 있다. 느낌적인 느낌?

느낀 점

걸출한 디자인 패턴 들에 비해서는 보잘 것 없지만 그래도 각자의 역할 + 역할의 무게에 따라 구분해놓으니 뭔가 있어보이는 느낌적인 느낌?? 좋다.

'TIL' 카테고리의 다른 글

[23.10.31]  (0) 2023.10.31
[2023.10.27]  (0) 2023.10.27
[23.10.24]  (0) 2023.10.24
[23.10.23]  (0) 2023.10.23
[23.10.20]  (1) 2023.10.20

오늘 한 일

Git

- 팀 프로젝트 구현 전 fork + pull request 작동확인

오늘 하루종일 git 공부만 했다. fork 이후 내 remote repo에서 local branch에서 어쩌구 저쩌구.. 정리해보겠다.

 

https://seungwubaek.github.io/tools/git/contributing_using_pull_request/

 

Git을 이용한 협업: Fork 부터 Pull Request 까지

Git은 쉽고 효율적인 버전 관리를 통해 커뮤니티(Github)에 공유된 Open Source 프로젝트 또는 개인 및 단체의 Private Source에 접근, 생성, 수정 할 수 있도록 하는 도구이다. 이 포스트에서는 Github에 업

seungwubaek.github.io

1. 3층 구조. 원본 repository(upstream) - forked repository(origin) - local repository(내가 작업할 branch가 있는 repo)

2. push할때는 upstream이 아닌 origin에 해줘야 진정한 의미의 (허락을 받는) pull reqeust

3. 다른 협업자로 인해 upstream에 수정사항이 생겼다면 git pull + git push origin branch1 으로 수정사항 반영

 

https://velog.io/@gth1123/git-pull-push%EC%9D%98-%EC%9D%98%EB%AF%B8

 

git pull, push와 origin의 의미

많이 사용하는 git cli는 암기해서 사용하고 있었다.git push origin 브랜치 이름git pull origin 브랜치 이름origin이 항상 들어가서 local에서 현재 내가 위치한 브랜치로 생각했었다.git push origin \[브랜치

velog.io

4. git origin의 의미는 = remote repository

git push origin [branch] = git이 push (현재 브랜치를)  origin의 [branch]로

git pull origin [branch] = git이 pull (현재 브랜치로) origin의 [branch]를

느낀 점

시간 쏟은 거에 비해선 아직도 잘 모르겠다.. fast forward는 뭐이며 FETCH_HEAD는 무엇이며. 블로그나 공식문서에서 하라는 대로 했는데 오류가 나고. 막무가내로 도전해보기 보다는 근본적인 작동원리를 더 살펴봐야겠다. 깃 특강 복습가자

'TIL' 카테고리의 다른 글

[2023.10.27]  (0) 2023.10.27
[23.10.25]  (0) 2023.10.25
[23.10.23]  (0) 2023.10.23
[23.10.20]  (1) 2023.10.20
[23.10.19]  (0) 2023.10.19

오늘 한 일

내배캠 자바 개인 과제

- 키오스크 과제 모범답안 확인

 

- 모범답안 중 클래스 뒤에 붙는 context란?

잘 정리해주신 글이 있었다.

https://pflb.tistory.com/30

 

Context가 뭐죠?

개발을 하다 보면 Context라는 용어를 자주접하게 된다.기능적으로만 이해하고 갑자기 의미가 궁금해서 찾아보았다.하단의 내용은 스택 오버플로우에 필자와 같은 질문과 그에대한 답변이다.질

pflb.tistory.com

요약하자면 context는 어떤 행위를 위한 정보들을 지칭한다. 이것은 필수적일 수도 있고 도움을 주는 선에서의 정보일 수도 있다.

java에서 제공하는 interface 중에도 context라는 친구가 있다고 한다.

시간관계 상 간략하게 읽어보니 이름과 객체를 binding하는 역할이라는데 내일 더 읽어봐야겠다.

 

- 자료구조 활용의 중요성

 

객체지향 이모저모

- 객체지향의 5가지 설계원칙

https://mangkyu.tistory.com/194

 

[OOP] 객체지향 프로그래밍의 5가지 설계 원칙, 실무 코드로 살펴보는 SOLID

이번에는 객체 지향 프로그래밍의 5가지 핵심 원칙인 SOLID에 대해 알아보고자 합니다. 실제로 애플리케이션을 개발할 때 어떻게 적용할 수 있을지 구체적인 예시를 들어 살펴보고자 합니다. 아

mangkyu.tistory.com

실무 코드로 봐서 그런지 이해는 잘 되지만 직접해본 건 아니라 막연하다. 이번 모범답안을 이 설계원칙을 지켰는지 비판적으로 바라보며 분석해야겠다.

 

알고리즘

- 백준 10026 적록색약(Gold 5, BFS)

느낀 점

모범답안을 보니 역할 분담을 잘 했다고 느꼈고 동시에 이게 최선일까?라는 의문도 동시에 들었다. 한 클래스에서 모든 로직을 구현한 나로서는 각각의 기능들마다 하나의 클래스가 존재해야 한다고 막연하게 생각했고 또 이 많은 클래스들을 패키지로도 잘 분류해야한다 생각했었다.

그러나 모범 답안을 보니 이 위대한 분은 그러지 않고도 각각의 역할을 깔끔하게 정리했다는 생각이 들면서도 App 클래스가 긴 것에 대해서는 좀 더 분할할 수 있지 않았을까라는 생각은 든다.

근데 사실 모두까기 인형이지 내 코드보다 훨씬 나으니 좋은 교보재라고 생각하고

다음 과제가 무엇일지는 모르겠으나 이번 모범답안을  살펴보면서 객체 지향에 대한 감을 더 잡았으면 좋겠다.

'TIL' 카테고리의 다른 글

[2023.10.27]  (0) 2023.10.27
[23.10.25]  (0) 2023.10.25
[23.10.24]  (0) 2023.10.24
[23.10.20]  (1) 2023.10.20
[23.10.19]  (0) 2023.10.19

+ Recent posts