Lots of Cs between B and D

📌 학습내용

● Spring

○ Security (로그인 및 회원가입, OAuth)

-> 클론코딩때는 프론트엔드(React)와 사용자 정보를 주고받아야 하는데 이 경우에는 같은 방법보다는 다른 방법이 쓰일 것같다.
다른 방법들에 대해 무엇무엇이 있는지는 아직 학습된 상황이 아니라 알 수 없지만, 다음주 WIL에 정리해서 기록하려 한다.

○ @Controller와 @RestController의 차이

  간단하게 생각을 하자면 RestController = Controller + ResponseBody라고 생각을 하면 될것같다.
  스린이인 나는 지금 단계에서 이렇게 이해했다.
"RestController는 JSON 형식의 출력을, Controller은 String 형식의 출력을 한다"
출력되는 형태만 봤을대는 RestController가 훨씬 다양하게 나타낼 수 있었다. List, Optional<> 등등
로그인 기능을 사용할 때에도 Controller 안에 model을 parameter로 써서 넘길 값(이 경우에는 로그인 된 아이디)을 model.addattribute에 넣어 attribute value로 보내줬다. 이렇게 보내준 값은 출력값에 String으로 쓰인 html 파일에서 나타낼 수 있는데, 이때 Thymeleaf Template Engine을 사용하여서 값을 받아줄 수 있었다.

해당 개념에 대한 정석진님의 블로그 _ https://github.com/strong1133/TIL/blob/main/spring/Controller%20vs%20RestController(21-03-25).md

○ 예외처리(if ... throw ... / orElseThrow ...)

혼자서 한참을 헤맸던 부분이다.(하루정도 걸렸던것같다.)
이 내용에 대한 정리는 좀 더 필요할것같아서 다음주 WIL에 올릴 계획이다.

○ ORM(Object Relational Mapping) _ ERD

JPA를 활용한 Entity 형성시 Entity가 하나 이상일 때 서로의 관계가 있을 경우 그 관계를 나타내보려 했다.결론적으로 말하자면 완전히 실현하지는 못했다. 분명히 개념적으로는 어느정도 이해가 됐다고 생각했는데, 직접적으로 Spring에서 Database를 활용해 나타내보려 하니까 미치도록 안되었다. 함께 항해중인 강상연님의 블로그를 보니, 내가 계속 답답해했던 부분은 invalid한 빨간 밑줄이 아니라 warning 개념의 주황색 밑줄이었다고 한다. 다시 봐야겠다ㅠ
다시 볼때는 더불어서 Model 외에 어떤 카테고리를 함께 다뤄야하는지도 생각해보는 시간을 가질 예정이다.

Spting Data JPA에 대한 추가정보 _ 강상연님 블로그 글  https://sanyoni.postype.com/post/9544578

📌 느낀점

●  어렵다.

- 이번주 강의 진행은 지난주에 사용했던 기능들에 대해 하드코딩의 형태로 비교 대조를 하면서 진행이 됐다.

짤막한 annotation 등으로 사용했던 기능들이 사실은 어떤 순서의 코드들인지 볼 수 있었는데, Java라는 언어에 익숙하지 않아서 그런지 둘의 관계성이라던가 각각의 코드에 대한 이해도가 좋지 못했다고 느꼈다. 이대로 가다가는 도저히 안될것같단느 마음에 자바를 별도고 공부하고 있는 그룹에 함께 할 수 있는지 물었다. 돌아오는 주부터는 게으름 싹 오려내고 주변의 부지런한 동료들 모습 보면서 많이 닮아가도록 해야겠다.

● 성장통

- 주어진 단위시간당 내가 모르는 것이 많아질수록 주변 사람을 통한 도움이 간절해지는걸 느꼈다. 하지만 이는 대학시절 솔루션을 보는 것과 같이 나에게 유익이 하나도 없다는  반문을 하면서 가급적 최대한 내가 한참 고민하고 해결해보려는 연습을 하고있다. 나뿐만 아니라 조원들과 이야기를 해도 같은 상황과 고민으로 씨름하고 있는게 보인다. 언제까지나 손을 빌릴 수는 없으니 내가 스스로 최대한 잘 정리해두는게 모범답안이 아닐까..

● Good Viber

- 나는 주변에 어떤 사람일까? 나는 어떤 가치를 전해줄 수 있을까?

이런 생각에 늘 사로잡혀있다. 여기서의 이런 생각은 나라는 자아를 건강하게 유지하는 가운데 주는 영향을 생각하는 것이다.

첫주부터 늘 주변 사람들에게 내가 도움을 줄 수 있는 그런 상상을 해오는데, 현실에서의 나는 늘 반대의 위치에서 도움을 바라고 있다.

푸념하면서 찡찡대는건 아닌지 익명 시트로 피드백좀 받아보고싶은 그런 마음이다.

주변 사람들이 뿜어내는 바이브가 좋은지 나쁜지가 나의 하루에 큰 영향을 준다고 느낀다. 항해를 하면서는 더더욱 그런것같다. 지금 굿바이브를 떠올렸을때 생각나는 사람들이 있다. 그분들의 장점을 닮아가고싶다.

📌 아쉬웠던 점

● 강의에 대한 연속성이 많이 부족했다. 

- 가장 두드러진 점으로는 튜터님이 바뀌었고, 그에 따라서 강의 진행방식이 너무 다르게 느껴졌다. 흐름에 대해 설명해주시는 내용은 많은 도움이 되었지만, 그런 설명이 지나면 바로 코드스니펫을 가지고 전체의 코드를 붙여넣다보니 어느 부분을 다루고 있는지 수시로 놓쳐서 나중에 가서는 도대체 어느 내용으로 어디를 다루고 있는지 알 수가 없다는 느낌을 크게 받았다. 시간이야 오래 걸리겠지만 초보일수록 강사님께서 하나하나 차례대로 구현해나가시는 식의 강의진행이 훨씬 낫다는걸 깨달았다.

● 부족함을 어떤 식으로 커버할것인지에 대해 (Curation)

- 검색을 통해 나의 부족함을 채워나가는 것은 가장 대세가 되었다. 하지만 쏟아지는 인터넷상의 정보가 과연 양질의 정보라고 믿을 수 있을까? 이런 것들에 대한 정보의 객관성은 어느정도 검증된 기관이나 공식 블로그가 아니라면 아무도 보장해주지 않는다. 따라서 한 블로그의 글을 보며 따라하다가 뒤집기가 일쑤였다. 하나의 에러나 기능에 대해 이런 블로그 참고 시도의 횟수가 많아질수록 뒤죽박죽의 알수없는 코드가 되어갔다. 차라리 이럴바에는 함께하고잇는 항해 크루원들끼리 좀 더 소통을 많이 하면서 정정이라도 원활하게 할 수 있는 방향으로 진행해보고 싶다.

● 동기부여

- 항해에서의 시간이 흐를수록 크루원들과 우연한 기회로 그 사람들이 개발공부를 하게 된 배경이나 이런것들을 접할 수 있게 되는 상황이 많아진다. 그 사람들의 이야기를 들으며 내 모습을 돌이켜보는데, 과연 그만큼 열심히 준비하고있는가? 나도 좀 더 뚜렷하게 목표를 잡아야 잡생각 없이 몰두할 수 있겠다는 생각을 했다. 다른 사람과의 비교를 통해서는 자극만 솎아내고, 본질적으로는 같은 주어진 시간 단위 안에서 내 스스로의 모습을 비교하는데 초점을 두어야겠다

🧐 좀더 공부해볼 개념

• p6spy
• Slf4j
• Template Engine (Mustache, Thymeleaf 등등..)
• Hibernate
• @RequestBody
• @Controller vs @RESTController
• Optional String
• @Bean
• xml과 jsp
• @ModelAndView
• Servlet
• IoC(Inversion of Control)
• DI(Dependency Injection)
• JPA Repository의 findbyId vs findallbyId
• JUnit 테스트

📌 학습내용

● Java & Spring 기본 용어와 개념 정리(주관적일 수 있음!)

● Web Service 구조 파악

서버를 배우는 지금의 상황에서 JPA, Repository, Service, Controller의 각각 기능과 DTO, Model의 역할을 익히는데 집중했다.

JPA

• Java Persistence API. 엄밀히 말하면 Spring Data JPA와는 동일한 개념이 아니다(Spring Data JPA가 좀 더 하위개념이라고 볼 수 있다.)
• Java 언어와 SQL 언어의 통역을 담당한다. JPA의 문법을 조금 익힌다면 Spring 내에서 별도로 SQL언어를 사용해가면서 데이터 연결, CRUD, 연결 해제를 직접 할 필요 없이 JPA가 그 기능을 대신 해준다.

Repository

• Spring Framework의 해당 프로젝트에서 어떤 방식으로 SQL을 불러들일지에 대해 정리해놓는 Interface.
• Interface는 멤버변수 없이 멤버메소드만 존재하는 클래스이다.

Service

• Business Logic을 구현하는 계층이다.
• 데이터에 대한 가공이 필요한 경우 service에서 처리된다.(CRUD중 Update)
• 이 때 불러오는 변수들은 final로 선언해준다.

Controller

• 서버의 계층중 Client와 가장 가까운 계층
• Return 값으로 JSON을 반환하여 client와 통신(@RestController)을 하거나, parameter로 페이지 구현에 필요한 정보를 담아 return 값을  html파일명의 string 값을 나타낼 수 있다(@Controller)

● Java Spring으로 나만의 항해 블로그 만들기

- FindbyId라는 Repository method와 Optional이라는 자료형에 대해 익숙하지가 않아 폭풍검색으로 몇일을 허비했다..

이 방황 덕분(?)에 Java Template Engine의 Thymleaf로 페이지를 구현하는 뜻밖의 소득도 있었다.

/*ArticleViewController.java 클래스 파일*/

@RequiredArgsConstructor
@Controller
public class ArticleViewController {

    private final ArticleRepository articleRepository;

    @GetMapping("/api/articles/detail/{id}")
    public String readOneArticle(Model model,Article article, @PathVariable Long id) {
        model.addAttribute("article", articleRepository.findById(article.getId()).get());
        return "articleview.html";
    }
}

📌 느낀점

● Week1의 미니프로젝트 데자뷰

- 항해를 시작하고 첫주 미니프로젝트의 과제로 했던 웹어플리케이션이 많이 생각났다.

가장 뚜렷한 차이가 있었다면 당연히 Python Flask FrameWork로 구현했던 과거와는 달리 이번에는 Java Spring Framework로 구현을 했다는 것.

JSON으로 데이터를 주고받는 방식은 아직도 많이 서툴다고 느꼈다.

이번 한주에서 가장

SSR(Server Side Rendering)과 CSR(Client Side Rendering)

● 교류를 통한 성장

- 

● 절차적 -> 객체지향

- 

📌 아쉬웠던 점

● '어떻게 질문(검색)할지 감이 잡히지 않는 것'

- 무슨 언어를 배우든 걸음마 단계에서 가장 껄끄러운 상황 아닐까? 학습 내용의 맨 마지막부분에 언급했던 Repository.findById로 Optional 값을 받는 부분에서 2일 이상을 고스란히 바쳤다. 수많은 시도의 검색으로 결국 해결을 했다.

함께 배우고 있는 사람들이 하나같이 하는 말이 이렇게 직접 부딪히며 해결하는 에러는 기억에 오래 남는다고 하던데.. 다시는 이런 문제로 같은 실수를 반복하지 않아야겠다🔥

● 시간효율

- 오전9시부터 오후9시까지 온전히 코딩을 하기에는 집중력이 흐트러지는 순간이 꽤 자주 있었다. 그러다보니 오후9시 이후로 미련을 가진 채 좀 더 하다가 애매하게 잠든게 다반사였던 한주였다. 그날그날의 목표를 좀 더 세분화해서 단위시간 활용 효율을 높여야겠다.

● 깃허브..

- 죽이됐든 밥이됐든 그날그날 작업했던 코드들을 꾸준히 올리려고하는데, 이것역시 습관화가 잘 안된다. Readme 작성, gitignore등등 개인 Repository 관리에 대한 부분과 협업시 고려해야할 Branch merge 등등도 평생공부가 될것같으니 기본을 잘 다져나가야겠다.

🧐 좀더 공부해볼 개념

• p6spy
• Slf4j
• Template Engine (Mustache, Thymeleaf 등등..)
• Hibernate
• @RequestBody
• @Controller vs @RESTController
• Optional String
• @Bean
• xml과 jsp
• @ModelAndView
• Servlet
• IoC(Inversion of Control)
• DI(Dependency Injection)
• JPA Repository의 findbyId vs findallbyId

Written by Joony-up

@브라운핸즈 도곡점

2021.03.28 19:30-21:28

📌 학습내용

● 알고리즘 개념 심화

- 브루트포스

- 그리디알고리즘

- 분할정복

   BOJ 2630, 1992

- 백트래킹

   BOJ 15650, 9663

- 다이나믹 프로그래밍

    BOJ 1003, 11053, 9183, 1932, 1149, 9461, 2679, 11054

● Python 문법

- list.sort() 와 sorted(list) 의 비교

- split() 과 join()의 비교

- zip()

● Java & Spring 관련

- IntelliJ IDE 설치 및 실행

- Java

   Java 기초문법

   Java Class

- H2 Database : 서버가 작동되는동안에만 CRUD가 가능한 데이터베이스. 가벼운 용도의 학습용으로 좋음

- ARC(Advanced REST Client) : 주소, method, header, body 등의 조작을 통해 서버응답내용을 확인하는 툴

📌 느낀점

● 알고리즘 개념을 알고 문제를 푸는것과 모르고 푸는 것의 차이

지난주때도 느꼈던 점이지만, 이번주는 좀 더 수시로 들었던 생각이다. 특히 좀 더 난이도가 어려워진다 싶은 개념의 문제들은 여지없이 하나 이상의 개념을 떠올려 함께 녹여내야 하는 문제들이었다. 예를들어, DFS를 배울때는 재귀함수의 구조를 활용하거나 Stack의 구조를 활용했다. BFS를 배울때는 Queue의 구조를 활용했다. BackTracking 알고리즘도 재귀구조를 구현해야 보다 더 직관적인 알고리즘이 된다. 분할정복 또한 재귀구조를 활용한 Dynamic Programming이라고 느꼈다.

개인적으로 느끼기에 이번주에 새로이 학습해보라고 하셨던 개념들 중 브루트포스나 그리디알고리즘의 경우는 별 어려움 없이 문제를 풀며 '이런걸 그렇게 부르나보다'라는 식으로 이해를 했다면, 그 외의 분할정복, BackTracking, DynamicProgramming 등은 여기저기 열심히 뒤져가며 그 개념을 익혔다.

● 개념 이해 ≠ 응용

이어서 느낀 점 중 꽤 큰 부분인데, 개념을 간단하게 설명하는건 그리 어렵지 않게 느껴졌다. 하지만 구체적으로 알고리즘 문제에서 이 개념을 코드로 구현해야 하는 상황이 되자 매끄럽게 이어지지 않았다. 전역범위에 어떠한 것들을 선언해놔야 할지, 탈출조건이나 유망함수는 어떻게 설정해놔야 정확히 작동을 할지에 대해서는 문제를 풀면서 심도있게 고민해보는게 훨씬 유익하다고 느꼈다.

● 좋은 동료란?

역시나 마지막 느낀점은 소프트스킬에 관한 부분이다.

이번 조에서 나는 또 조장이 되었고, 과연 내가 스케줄을 잘 분배해서 활발히 교류할 수 있을까라는 마음의 기대 반, 걱정 반이었다.

걱정을 했던 이유는 계속해서 하차하는 조원들을 봐왔기 때문도 있다. 그래서 이번에는 내가 부지런히 진도를 빼서 조원들에게 최대한 설명해줄 수 있는 준비가 되어야겠다는 마음으로 임했다.

이번 조원들은 뭔가 다가가는데 있어서 서로 다른 느낌을 받았다. 한명은 다른 팀원들까지 초대해서 우리조의 채팅공간을 더더욱 활성화시켰고, 그 덕분에 겪어보지 못했다면 어쩌면 쭈욱 삭막했을 항해도 동료들에 대해 조금이나마 알아갈 수 있는 시간을 만들어주었다.

다른 한명은 뭔가 목적지향적이랄까? 정해진 팀 문제풀이 공유시간마다 빠짐없이 성실히 임해주었다. 그 외의 교류는 사실상 할 수가 없었는데, 덕분에 문제풀이 공유라는 본질에 집중할 수 있었던 시간을 만들어주었다. 

이번 한주를 그렇게 함께 보내면서 스스로에게 문득 들었던 질문이었다. 좋은 동료란 어떤 유형의 동료일까? 어느 유형이 더 생산적이라고 할 수 있을까? 어느 한쪽이 절대적으로 맞다고 할 수 있을까?

📌 아쉬웠던 점

어쩌다 보니 6일간격으로 두통이 찾아오고 있다. 마음의 여유가 많이 부족한 탓인지 두통을 한번 겪고나면 엄청난 압박감이 밀려온다. 알고리즘 튜터님이 멘토링시간에 말씀해주셨던 멘탈싸움이라는게 이런건가 라는 생각도 해보면서 좀더 자기관리를 철저히 해야겠다는 생각이 든다.

또하나 아쉬웠던 점은 역시나 시간활용에 관한 부분인데, 주어진 시간에 몰입도를 높여 학습하면 시간을 좀 더 효율적으로 쓸 수 있지 않았을까 라는 생각을 한다.

Github는 늘 나를 괴롭게 한다.. 완전한 이해 없이 계속 그때그때 임기응변식으로 찾아가면서 쓰다보니 CLI 기반의 명령에 애를 먹고 있다. 깃허브나 개발블로그에 꾸준한 노력을 기울이고 있는 다른 사람들을 보며 팁좀 들으며 나도 습관화를 해야겠다.

Java Spring이라는 주특기를 골랐는데, 분명히 상당히 버거울것이라는 예상은 했지만 막상 부딪쳐보니 상상 이상의 버거움이 느껴진다.

문득 1주차때 뭣도 모르고 가져다 쓰던 기능과 개념들에 대해 이제는 언제든 복습할 수 있도록 최소한의 메모라도 해둬야겠다는 생각으로 '🧐좀 더 공부해볼 개념'을 추가했다.

🧐 좀 더 공부해볼 개념

● 출력형식(formatting)

- signed char & unsigned char

- integer with size

●Rest

- RestController

● Controller, Service, Domain

- 각각의 개념과 역할의 범위에 대해 공부해보기

● Dto

- 존재목적에 대해 이해하기

Written by Joony-up

@브라운핸즈 도곡점

2021.03.21 20:00-21:25

📌학습내용

● 알고리즘 전반에 관한 개념

- 기본수학

- 이분탐색

- 재귀함수

- 스택 & 큐

- DFS, BFS

- 동적 프로그래밍(Dynamic Programming)

● 소프트스킬

- 팀원들과의 대화 & 이해

📌느낀점

● Communication

정확히 어느 단계에 있고 어느걸 이해했으며 어느게 부족한지를 서로 투명하게 이야기하는 것이 생각보다 쉽지 않다는 것을 느꼈다.
음.. 질문을 할때조차 내가 어느 개념을 어떻게 어디까지 이해하고 질문하는가가 매순간 연습이라고 느꼈다.
이번 팀의 팀원들은 알고리즘에 대한 이해도 면에서 뚜렷한 차이가 있었다.
컴퓨터에 대해 잘 알고계신 한명과 파이썬 기본문법에 대한 필요성을 느끼고 개인 보충학습에 좀더 초점을 둔 한명, 그리고 그 중간에 내가 있었다.
처음에 내가 또 조장인줄 알고 깝죽댔던 해프닝도 있었지만, 그 덕에 초반에 서로의 상황에 대해서도 좀 이야기를 나누면서 둘째 주를 시작했다. 첫날까지는 그럭저럭 세명이 속도를 비슷하게 맞추어 나갔다는 느낌이 있었는데, 둘째날부터 간격이 좀 벌어지기 시작했다.현격한 속도차이와 함께 우리팀 세명은 각자에게 맞는 중점을 두고 그거에 전념했다고 생각한다.

● Personal Optimization

시작할때만 하더라도 나는 문제를 푸는데 우선순위를 두었지만, 한 문제에 3~4시간 이상을 쏟게된 후에 개념 정립에 대한 필요성을 느끼고 강의를 듣는데 집중했다. 항해라는 하나의 프로그램과 커리큘럼으로 이루어진 하나의 타임라인에 맞추기 위해 개인의 학습방법을 끊임없이 수정해야하는 시간을 보내고 있다고 생각한다. 누구나 지원을 하고 도전을 할 수 있지만, 일단 발을 들여놓으면 그 간격을 스스로 얼마나 잘 메꿔나갈 수 있느냐 또한 이 상황의 중요한 포인트라는걸 느꼈다. 

● 서있는 편안함

하루종일 앉아서 컴퓨터 앞에만 있다보니까 생전 처음 느껴보는 허리의 불편함이 있었다.

급하게 책상위에 놓을 수 있는 스탠딩데스크를 당근마켓에서 구매했다.

또 하루종일 알고리즘과 씨름하느라 머리가 무거울때는 나가서 호수도 한바퀴 뛰고 돌아와 앉는다.

개발능력만큼이나 중요한 자기관리의 중요성을 느꼈다.

📌아쉬웠던 점

스콧 애덤스의 "더 시스템(The System)"에는 최적화와 단순화를 비교하는 다음과 같은 글이 쓰여있다.

단순화를 좋아하는 사람은 조금 더 노력하면 더 나은 결과를 얻을 수 있다는 사실을 알면서도 쉬운 길을 택한다. 최적화를 좋아하는 사람은 일이 꼬이면 예상치 못한 문제가 발생할 수도 있다는 사실을 알면서도 최선의 해결책을 찾는데 힘을 쏟는다.(p.104)

다른 사람들과 소통해야 하는 상황에서는 단순화가 무조건 옳다고 해도 과언이 아니다. 단순한 계획과 복잡한 계획 중에서 어떤 것이 더 좋을지 모르겠다면 단순한 계획을 선택하라(p.108)

최적화는 구체적인 목표가 있고 자기 힘으로 모든 걸 이뤄내야 한다고 생각하는 사람에게 필요한 전략이다. 단순화는 일반적으로 세상을 시스템이라는 관점에서 바라보는 사람에게 어울린다. (p.109)

스스로 좀 젠체한다는 생각을 했던 한주였다. 분명 알고리즘 문제풀기는 내가 처음 접했지만 첫주를 무사히 마무리했다는 생각에 크게 안도한 마음도 있었고, 과거 학생시절에 봐왔던 유형의 문제해결방법 찾기를 오랜만에 보니 의욕이 앞섰다.

초반에는 가급적 최대한 깊게 씨름해보고 해결하고싶었던 마음때문에 아침마다 팀원들과 함께 세웠던 문제풀이 공유 시간마다 시간을 조금 더 달라는 부탁을 하곤 했다. 하지만 시간이 흐르면서 처음 접하는 알고리즘 개념이 늘어나자 검색을 통해 문제에 대해 완성된 코드를 보며 이해하고 팀원과 서로의 의견을 공유하는 데 초점을 두는 방향으로 접근법을 수정했다.

내가 조장의 역할을 수행할때와 조원으로 있을 때 나의 성향이 좀 달라진다는 모습을 느꼈다.

조장의 역할에 있을땐 전체를 보고 좀 더 책임감있게 마감을 지키려다보니 단순화에 초점을 두었다면, 조원으로 있을땐 내 스스로에게 기대하는 완벽성때문에 최적화(글에서는 최적화라는 단어로 표현되었지만 완벽주의라고 표현을 하고 싶다)를 바라본다. 이는 팀원의 역할에 머무를 때 나는 내 스스로의 욕심때문에 좀 더 개인적인 성향이 된다고 느꼈던 한주였던 만큼, 이후로 구성되는 팀에서는 내 욕심을 뒤로하고 어떻게 하면 팀에 좀 더 도움이 되고 팀이 더 잘 될 수 있을까에 초점을 두는데 집중해야겠다.

지금 이 글을 쓰는 시점에서 이번 한주를 함께 했던 팀원 한명의 하차 소식을 접했다. 내가 더 도울수 있는게 없었을까라는 생각에 아쉬움과 안타까움이 또 밀려온다ㅠㅠ 주변을 도울 수 있는 사람이 되기를 다시한번 다짐해본다 👊