Today I Learned 12, 13일차
- 주특기 선택 멘토링 Q&A
- 알고리즘 ing
- deque vs list
- input() vs sys.stdin.readline()
- 느낀점
1. 주특기 선택 멘토링 Q&A
12일차에 주특기 선택 관련 멘토링이 있었다.
아무래도 비대면이라 혼자서 영상보고 공부하는 느낌이 강했는데 이번에 튜터님께서
최대한 항해99 매니저님들과 튜터님들을 잘 활용해보라고 하셨다. 김연아도 코치가 있다고!
맞다, 안그래도 유튜브에서 혼자 강의보는거랑 지금이 뭐가 다른가하는 자괴감이 들었지만
항해99에는 내 주변에서 쉽게 찾아볼 수 없는, 이미 현업에서 인정받은 개발자분들이 있고
그런 분들을 가까이서 보며 같이 일하고 있는 관계자분들이 계신다.
수많은 사람들은 워렌 버핏과 점심 한끼를 먹기위해 많이 돈을 쏟아붓는데
나는 지금 뭐하고 있는가라는 생각이 들었다.
벌써 13일차가 되었고 10일이 마치 하루처럼 금방 지나가고 있다.
남은 시간동안 나에게 주어진 이 기회들을 잘 활용해야 할 수 있도록 의식적으로 노력해야겠다.
물어보는 것도, 나 자신을 어필하는 것도 연습이니까.
2. 알고리즘 ing
To Do. 알고리즘 문제 정리해서 업데이트하기
- 6월 18일
| 문제 코드 | 문제명 |
|---|---|
| 11651 | 좌표 정렬하기2 |
| 2805 | 나무 자르기 |
| 10828 | 스택 |
| 10773 | 제로 |
- 6월 19일
| 문제 코드 | 문제명 |
|---|---|
| 1934 | 최소공배수 |
| 4949 | 균형잡힌 세상 |
| 1010 | 다리놓기 |
| 11050 | 이항계수1 |
3. deque vs list
deque
- double ended queue의 줄임말로 컨테이너의
양방향 (시작과 끝) 위치에 접근이 가능한 자료형이다. (leftpop(), pop()) - 원소들에 index로 직접 접근이 가능하며
앞, 끝에 삽입/제거가 빠르다.(stack, queue에 적합) - 단, 시작, 끝 위치가 아닌 위치에서 삽입,제거 수행 시 list에 비해 성능이 떨어진다.
list
- 컨테이너내
어느 위치에 있든 삽입, 제거가 빠르며 원소들의 순서 이동이 빠르다. - 단, index로 접근이 불가능하며
특정 원소에 접근 시 선형탐색을 이용해야하므로 비효율적이다.
참고 : http://egloos.zum.com/sweeper/v/2817817
4. input() vs sys.stdin.readline()
input()
- 입력값을 받으면
문자열을 변환 후 strip()를 진행하는 과정을 거친다. - 또한 input()을 사용하면 입력값을 받을 수 있는 prompt(일종의 입력창)를 가지고 있는데,
대량의 값을 받을 시입력을 받고 prompt를 띄우는 과정을 반복하므로 성능이 떨어질 수 밖에 없다. - 파이썬의 내장함수로 취급되며
입력된 값이 없을 시 오류가 발생한다.
sys.stdin.readline()
- input()과 동일하게 입력값을 받지만 strip() 과정이 없기에
개행문자(엔터 형태)를 받을 수 있다. - 또한, 입력값에 제한을 줘 문자의 수를 정할 수도 있다.
(ex. sys.stdin.readline(2) 일 시, 입력된 문자열 중 첫 두개의 문자만 출력) - sys 라이브러리에 속하는 file object로 취급되기에 prompt가 아닌 사용자의 입력만을 받는
buffer를 만들어 읽어들인다. - 입력된 값이 없을 시 빈 문자열로 반환한다.
sys란, c언어로 작성되어 있는 파이썬이 제공하는 모듈이다. (파이썬 인터프리터가 제공하는 변수와 함수를 직접 제어할 수 있게 해준다.)...공부 필요필요..
buffer란, 임시 저장 공간으로서 input,output를 수행할 때 속도차이를 극복하기 위해 사용된다. (prompt보다 효율적이라고 생각하면 될 듯..)
참고: https://velog.io/@gouz7514/%ED%8C%8C%EC%9D%B4%EC%8D%AC-input-vs-sys.stdin.readline
5. 느낀점
오늘은 토요일..나는 더이상 직장인도 아닌데 괜히 아침에 늦장부리고 싶었다.
하지만 다행히 알고리즘 스터디가 9시부터 있어 제 시간에 일어나 준비를 할 수 있었다.
역시 사람에게는 조금의 강제성은 필요한 거 같다.
어제, 멘토링을 통해 많은 조언을 얻었지만 동시에 힘이 쭉 빠졌었다.
나는 현재 누구보다도 나의 상황을 잘 알고있고 진지하게 고민한다고 생각했지만 튜터님과의 대화를 통해 수많은 고민들은 그저 겉핥기 였다는 것을 깨달았다.
면접도 아니고 그냥 나의 생각을 전달하면 되는데 나중에는 '잘 모르겠다', '그 부분은 생각을 안해봤다' 등
횡설수설하며 멘토링을 마무리하였다. 그 이유가 뭔지 다시 생각해보니 내가 다양한 관점으로 '고민'을 바라보지 못했던 거 같다.
순전히 고민에 의한 걱정만 하는 것이 아닌, 왜 그렇게 생각하는지, 그리고 그게 정말 그런건지 등 여러 관점으로 보는 법을 알지 못했던 거 같다.
현재 나의 고민은..나와 동일한 주특기를 선택한 사람들과 함께 과열된 경쟁을 하게될까 두려웠다. 왜냐하면 이미 많은 사람들이 관심을 가지고 있고 그 중에서는 실력이 특출난 분들도 계시기 때문이다. 이런 고민은 나의 국비학원 경험을 베이스로 생겼는데, 그 때 같이 공부한 전공 친구들은 모두 취업에 성공한 반면 나는 스프링 대신 RPA 개발자로 취업했기 때문이다. 그러다보니 항해99에서도 똑같은 일이 반복되지 않을까 하는 생각이 무의식적으로 자리잡고 있었던 거 같다.
지금 돌이켜 생각해보면 그때에 나는 정말 열심히했지만 잘하지는 못했다. 잘 따라간다고 생각했지만 여전히 이론적인 부분들은 많이 부족했고 그런 상태에서 보고싶은 거, 하고싶은 거만 했었다.
그러니까 사실, 스프링 개발자로서 취업을 못했던 것도 당연했던 거 같다.
그런데, 국비학원때의 나를 객관적으로 살펴보지도 않은데 고민만 주구장창해대니 당연히 멘토링때 내 생각을 제대로 전달하지 못하지..
나는 국비학원때의 나를 반복하고 싶지않다. 그러기 위해서는 정말 온전히 프로그래밍에만 집중해야하며 사용하는 기능 하나 하나에 물음표를 가지고 접근해야한다. 나는 할 수 있다! coder가 아닌 programmer로서 성장할 수 있도록 하루 하루를 능동적으로 임하자.
