(이미 여러차례 언급을 했으나) 99일 동안의 항해를 드디어 시작했다.
왜 이름을 항해로 지었을까? 시작하기 전에는 몰랐다. 하지만 한 주를 보낸 지금은 어렴풋이 알 것 같다.
먼 바다 한가운데에서 시작해 99일간을 헤엄쳐야 무사히 섬으로 갈 수 있는듯 하다.
첫 느낌은 조난99 였다. 아무것도 모르는 상태에서 처음 만난 사람들과 뭘 만들어야 한다?
프로젝트를 어떻게 구상해서 어떻게 계획을 세워야 할지 감도 오지 않았고,
어디서부터 시작해야 하는지 엄두가 나질 않았다.
그렇게 프로젝트를 시작하고 하루하루 막막한 날을 보냈지만 결국 뭔가를 하긴 한 것 같다.
물론 추가하거나 고쳐야 할 부분도 많고, 시간이 더 있었으면 하는 아쉬움은 남았지만
'아무것도 모르는데 이게 되나?'에서 '진짜 이게 되네?'로 바뀐것 만으로도 뿌듯하다.
일정이 상당히 빡빡해서 첫 10조 팀원들과 많이 친해지지 못했는데 지금와서 생각해보면 아쉽다.
처음 어색했던 시간도 있었지만 프로젝트가 진행될수록 혼자 하는게 아니라 진짜 다행이란 생각이 들었다.
가능한 조별과제가 있다는걸 처음으로 알게 된 프로젝트였다.
4일간의 미니프로젝트 기간이 끝난 후 바로 알고리즘 주간이 시작되었다.
조도 바뀌고 진행방식도 바뀌니 꼭 게더에서 매주 새로운 게임에 참여하는 기분이다.
알고리즘, 수학의 정석에서 본 이후로 오랜만에 접하는 단어였다.
과연 알고리즘 문제를 내가 풀 수 있을까? 이거 완전 수학인데? 역시나 또 조난99 시작이다. 막막했다.
초심자를 위한 걷기 반에 속한 내가 처음 접한 문제는 두 정수 사이의 합( 난이도 하 ).
이걸 푸는데 (정확히는 풀기 위한 알고리즘 문제의 방식을 익히는데 ) 반나절이 걸렸다.
분명 많이 봤던 function 과 let 과 return과 console.log 들이 왜이렇게 새롭게 느껴졌는지 모르겠다.
그래도 한 번 익숙해진 알고리즘은 예상외로 꽤나 재밌었다. (물론 난이도 하 이다. )
어렵고 정답으로 가는 길이 멀긴 하지만, 그 길을 차근차근 설계하는 일이 퀴즈를 푸는 기분이다.
이런 마음가짐이 과연 계속 유지될 수 있을까?
알고리즘 문제를 접하면서 또 한가지 들었던 생각은 문법과 코드를 잘 알고 싶다는 것이었다.
분명 같은 문제를 푸는데 나는 왜 이렇게 코드가 길지? 어떻게 저런 생각을 하지?
세상에는 대단한 사람들이 너무 많다. 그런 생각이 들어 자바스크립트 문법강의를 열심히 듣고 있다.
항해 중의 첫 주말은 이렇게 끝나고 있다.
술도 먹고 싶고, 축구도 보고 싶은데 한 번 이라도 놀게 되면 이 기분 좋은 템포가 끊어질 것 같다.
마냥 즐겁지는 않지만, 나름대로 기분좋은 항해를 하는 중이다. (헤엄을 치는 중이다.)
내일부터는 알고리즘 문제풀기와는 별개로 CS스터디를 진행한다고 한다.
혹시 항해99에서 몸을 두 개로 분리시켜 줄 수 있는걸까? 기대해봐도 될 것 같다.
미니프로젝트 1일차 TIL : https://ji-coding.tistory.com/15
미니프로젝트 2일차 TIL :
미니프로젝트 3일차 TIL :
미니프로젝트 4일차 TIL :
알고리즘 1일차 TIL : https://ji-coding.tistory.com/23
알고리즘 2일차 TIL : https://ji-coding.tistory.com/25
마지막은 항해에서 내준 숙제 jwt 와 api 에 관한 내용이다.
처음 WIL을 써야 된다는 공지를 보고, 일기쓰는 것 까지 검사를 받아야하나? 생각했지만
TIL과 별개로 WIL을 쓰다보니까.. 나쁘지 않다.
뭔가 한 주를 정리하는 기분이 들어 꽤 열심히 쓰게 됐다.
아마 다음주에도 쓰게 되지 않을까 싶다.
1. jwt
Json Web Token 으로 웹에서 쓰이는 json 방식의 토큰이다.
jwt 인증방식의 과정
1. 사용자가 최초로 회원가입을 하면 DB에 정보가 저장된다.
2. 사용자가 로그인을 하면 서버는 DB를 통해 회원임을 확인하고
(header: 해당 토큰이 암호화된 방식(alg)과 타입 /
payload: 사용자의 고유 ID, 토큰 만료시간 등의 정보, /
verify signature: 암호화된 header, payload 와 secret key )
가 담긴 토큰을 사용자에게 발급한다.
3. 사용자는 정해진 시간만큼 토큰을 가질 수 있으며, 인증이 필요할 때 서버로 토큰을 보낸다.
4. 서버는 secret key 를 가지고 verify signature의 정보를 확인해 사용자를 검증한다.
5. 검증이 완료된 사용자의 data를 보여준다.
복잡한 내용을 좀 더 간략하게 표현하면
서버가 사용자에게 id와 토큰의 만료시간, 암호가 담긴 토큰을 지급하고
사용자는 토큰을 가지고 다니면서 인증이 필요할 때 토큰으로 이용하는 방식이다.
토큰은 시간이 지나면 사라진다.
참고:
https://tansfil.tistory.com/58?category=255594
https://brunch.co.kr/@jinyoungchoi95/1
2. api
필요한 데이터가 담긴 곳, 클라이언트가 서버에게 요청하는 주소(은행의 창구번호)
이건 내가 처음 웹개발 종합반을 들으면서 써놨던 api에 대한 설명이다. 하지만 위의 설명만으로는 부족하기 때문에 좀더 보충설명을 찾아봤다.
우선 UI(user interface)는 무엇일까? user는 사용하는 사람이다. interface는 '서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면'이라고 나온다. 잘 이해는 안가지만 매개역할을 하는 무엇인가라고 생각하면 좋을 것 같다. 그럼 UI란? 유저가 기계나 시스템에서 어떤 동작을 하려 할 때 도와주는 매개체이다. 예를 들어 스마트폰의 홈버튼은 사람을 홈화면으로 데려다주는 UI이다.
그렇다면 API(Application Programming Interface)는?
API 또한 interface가 들어간다. 다만 사람이 아니라 프로그램과 프로그램을 연결해주는 매개역할을 한다.
프로그램이 요청을 하면, 필요한 데이터가 담긴 곳에서 요청한 데이터를 가져다 준다.
참고
https://dev-dain.tistory.com/50