개발일지 시작의
내일부터 알고리즘 화이팅!
개발 업무내용
발표회 참석 후 KPT회고
오늘의 이슈/고민..그리고 해결한 내용
- jinja2에서는 result[“word”] 이렇게 안쓰고 result.word .만 찍어도 가져올 수 있음
- {{result.definition|safe}}-> | 문법, 정수로 가져오고 싶을 때 |int 이렇게 쓰는 것처럼 safe는 파이프 앞의 값이 안전하니까 태그 무시하지말고 그대로 가져오라는 뜻
- 외계어 나올때 .encode(‘ascii’,’ignore’).decode(‘utf-8’) 이걸로 아스키 코드값이 아니면 무시하고 맞으면 문자열로 바꿔주라는 뜻
- 크롬에서 ⌘ + ⇧ + R : 캐시 무시하고 다시 로딩(크롬에서 로딩 시간을 줄이기 위해 캐시에서 가져올때가 있는데 css같이 static에 들어있는거 수정했을때 바로 반영이 안되면 이걸로 캐시무시하고 새로 다시 받아오기)
- ⌘ + , : 파이참 인터프리터
- 셀레니움 : 동적인 웹페이지(html이 로드되고나서 ajax를 이용해 정보를 가져와 페이지 내용을 바꿔주는 것)를 스크래핑 할 때는 브라우저에 띄운 후 가져와야함 -> ex) 좋아요 수는 html이 로드된 후 서버에 요청해 실시간으로 숫자를 가져와 띄워줌 -> 스크래핑 할 때 request는 서버에 요청한 데이터가 html에 채워지기 전에 가져오기 때문에 셀레니움 씀
드디어 발표회를 끝으로 2차 프로젝트를 마무리했다. 1차와는 다르게 백엔드를 많이 해봐서 즐거웠다. 2차까지 마무리하고 나니 1차때 프론트를 열심히 한 만큼 그때 예쁘게 구성해놨던 시작 페이지가 아주 마음에 들어서 대단히 만족스럽다.👍 백엔드를 열심히 하다보니 get과 post방식에 좀 더 익숙해졌다.
다음에 우리 프로젝트를 spring으로 바꾸는걸 의식해서 좋았던 점과 안 좋았던 점이 있었다. 좋았던 점은 db에 대해 많은 시간을 할애해 고민했고 그만큼 pymongo에 대해 공부할 수 있었던 것과 nosql과 sql을 비교하면서 생각해봤던 것이다. 안 좋았던 점은 spring으로 바꿀 때 힘들까봐 2차 프로젝트 시작부터 괜히 진을 뺀 것... 튜터님과 상담을 통해 2차 프로젝트는 1차때 못다한 기능 구현에 집중하는 것이 좋겠다는 조언을 듣고 아주 열심히 기능 구현에 힘썼다.
그래도 아쉬운게 있다면 to do list를 삭제할 때 delete말고 post로 한 것인데 알고리즘을 공부하며 시간이 난다면 수정해봐야겠다. 그리고 기능 하나를 완성할때마다 깃허브에 커밋을 해야했는데 기능 구현하는게 재밌어서 계속 하다보니 push나 pull하기전만 커밋을 했다. 그러다보니 다른 팀원들에 비해 커밋 수가 너무 적은게 아쉽다... 다음에는 새롭게 추가할 기능, bug 등 변경 사항을 전부 깃 이슈로 등록해서 바로바로 커밋해서 pr올려야지!
그리고 하다가 막힐때 혼자 해결하려고 오래 고민해봤는데 이것보다는 고민 시간을 조금 줄이고 팀원에게 물어보거나 구글링으로 여러 사람의 코드를 읽어보는게 더 나았다. 여러명의 코드를 읽어보는게 특히 도움이 많이 됐는데 같은 결과를 내는 것이라도 사람들마다 생각하는게 조금씩 달랐기 때문이다. 다양한 시점으로 문제를 바라보는 연습이 됐다. 그래서 들었던 생각이 매주 금요일 테스트를 보고나서 답안 코드뿐 아니라 다른 사람들의 코드도 보고 싶다는 것이다. 아니면 팀원들과 어떤 방식으로 접근을 했는지 이야기를 나눠보는 것도 나쁘지 않을 듯하다. 이제 알고리즘 공부를 시작하면서 팀이 바뀌게 됐는데 우리 버스타조 팀원들과 알고리즘 문제에 대한 의견을 나누지 못하게 된 건 아쉽지만 새로운 팀원들과 함께 이야기하며 더 다양한 관점을 경험해 볼 수 있겠지.
To-do List
심화 강의 복습, 알고리즘 강의 듣고 문제풀기
