Skip to content

Latest commit

 

History

History
489 lines (397 loc) · 28.9 KB

README-season3.md

File metadata and controls

489 lines (397 loc) · 28.9 KB

TIL

Today I Learn

Day 1

  • 타노스 장애 처리를 하다보니 알던 것도 다시 검색하고 있는 자신을 발견하게 됨.
    • ps -aef | grep server | grep -v grep
      • 자기 자신을 grep 결과에서 빼고 싶을 때...
    • cat file | sed -e 's/^/prefix/' > new_file
      • prefix를 매 라인마다 앞에 넣고 싶을 때...
    • for i in {1..10}; do sth; done 을 ctrl+z; bg를 하면 지금까지 진행 중인 sth만 수행하고 종료된다. 끝까지 실행하고 싶으면 이 명령을 파일로 옮겨서 실행해야 함.

Day 2

  • Stderr/Stdout 이 출력되는 프로세스를 ctrl+z 후 bg를 하면 예외처리를 하지 않는 이상 에러를 뿜고 프로세스가 죽는다.
    • CMD > /dev/null 2>&1 을 뒤에 붙여 프로세스를 수행하도록 하자

Day 3

  • Ansible tip
    • 옛날 버전: ansible -i <server_list> -m shell -a "ls" -f 10 tset-sa[!1-3]-9[!0-9]
    • 최근 버전: ansible -i <server_list> -m shell -a "ls" -f 10 ~tset-sa[1-3]-9[0-9]$
    • 옛날 버전은 자동으로 regex를 적용시켜 줬지만, 최근 버전은 ~를 명시해야 regex를 적용시켜준다. 이게 없으면 <server_list>의 몇번째 매칭된 파일인지.. 등과 같은 형태로 패턴을 찾는다.
    • https://docs.ansible.com/ansible/latest/user_guide/intro_patterns.html#intro-patterns
      • 이걸 끝까지 안 읽어서 맨날 헤맸다..
      • Most people don’t specify patterns as regular expressions, but you can. Just start the pattern with a ‘~’

Day 4

class Solution:
    def commonChars(self, A: List[str]) -> List[str]:
        res = collections.Counter(A[0])
        for a in A:
            res &= collections.Counter(a)
        return list(res.elements())
        
  • 혹은 map에 단어별 개수를 저장해서 점점 필요한것만 남겨나가는 식으로 할 수 있음.

Day 5

Day 6

Day 7

  • C++의 unordered_map과 map의 차이
    • https://a.cyclic.dev/day05/ 를 보다가, map이 왜 tree로 만들어져있지?! 띠잉 하고 이것저것 뒤적여봤다. 결론은 ordered_map이 map인 셈... 요즘 cpp를 문제 푸는 용도로만 쓰다보니 그냥 무작정 unordered_map만 써대서 생각도 깊이 안 해봤었다.
    • 차이 설명 링크 여기 설명이 명확하다. 결론적으로 트리구조 자료 저장 방식과 맵 구조 자료 저장 방식의 차이를 이야기해준다.
    • GeeksForGeeks 여기 요약도 명료하다. 순서나 range가 필요한 경우, skewed된 경우, 등등... 은 map이 유리.
    • 반대로 말하면 tree 구조를 사용해야 할 때 map을 사용하면 편할 것 같다. 문제 풀 때 이런 일이 있으면 꼭 써보자.

Day 8

Day 9

Day 10

  • https://leetcode.com/problems/rotate-function

  • https://github.com/jereneal20/TIL/blob/master/ps/rotate-function.cpp

    • 복잡도 O(n)
    • 곱셈이 순차적으로 일어나기 때문에 하나의 답을 구한 후 한번의 연산으로 그다음 답을 구할 수 있다.
  • Integer promotion 버그

    • vector의 size를 구하면 이는 signed type의 값이다. 이때, 음수 값과 연산을 진행하는 경우 integer promotion이 발생해 값이 잘못 출력되는 경우가 발생한다.
  • 아래 코드의 결과를 예상해보자. -4일까? 아니다. -2가 강제 promotion 되어 양수로 바뀐 상태로 계산을 수행한다.

#include <vector>
#include <iostream>
using namespace std;

int main()
{
	vector<int> vec;
	vec.push_back(1);
	vec.push_back(1);

	cout << -2 * vec.size() << endl;
	return 0;
}

Day 11

Day 12

Day 13

Day 14

Day 15

Day 17

Day 18

Day 19

Day 20

Day 21

Day 22

Day 23

Day 24

Day 25

Day 26

Day 27

Day 28

Day 29

Day 30

Day 31

Day 32

Day 33

Day 34

Day 35

Day 36

Day 37

Day 38

Day 39

Day 40

Day 41

  • 39일자의 문제를 BFS with B&B로 풀었다. 수학으로 푸는 방법은 라그랑주의 네수 정리에 의한 것이었다...

Day42

Day 43

  • Day 40의 N 솔루션이 있다는 말은 사실 사기였다. N^2인데 best case에 N이 가능한 솔루션이었을 뿐. 퀵소트의 left right를 가르는 로직을 이용하면 된다는 논지인데, 구현해보는건 좋을 것 같긴하다. 동시에 퀵소트 구현도 한번....

Day 44

  • 이래도 되는걸까 싶을정도로 쉬운 문제 2개 풂. 하지만 모음에는 소문자 모음 뿐만 아니라 대문자 모음도 있다는 사실을 간과함..

Day 45

  • 노동자의 날이니 쉬어가는 차원에서 지금까지 어떤 문제들을 풀었는지 간략하게 살펴봄. medium 문제들을 더 풀고 열어두고 해결 못한 leetcode 페이지들을 이해하고 꺼야하는데.. 하는 생각만 반복합니다.

Day 46

Day 47

Day 48

Day 49

  • 어제 문제 다시 풂. 시간복잡도는 줄어들지 않지만 최적화를 더 하면 되는거였음. 시간복잡도도 줄일 수 있는데, 각 조건에 대해 각각 배열을 만들고 어차피 가장 첫번째것만 쓰기 때문에 그거만 저장하는 것으로 가능.

Day 50

  • https://leetcode.com/problems/3sum/
    • 이 솔루션으로는 안된다. 두개의 index를 l r에서 중앙으로 오면서 값을 찾는 로직으로 풀 수 있는데, 왜그게 특정 값 x를 찾아낼 수 있는지 모르겠다. 고민중...

Day 51

  • 50일차 문제를 풀었음. 뭔가 다른 사람에게 설명하긴 좀 껄끄럽지만, 여하튼 이해하고 코드로 구현은 완료.

Day 52

Day 53

  • 52일 문제를 좀 끙끙댄 후에야 겨우 풀었다. 스택을 써서 펌핑 시켰는데.. string shift가 많은데 이것밖에 없나 고민 중.

Day 54

  • container-with-most-water 문제가 이전에 푼 유형과 비슷해보이는데.. 점화식으로 풀면 되는건데 맞는지 확신이 없고...

Day 55

  • 기존에 푼 문제들을 다시 한번 풀어보는 중. 솔루션이 얼마나 명확하게 생각나는지로 분류도 써두는게 좋을 것 같다

Day 56

Day 57

Day 58

Day 62

Day 63

Day 64

Day 68

Day 69

Day 70

if has("autocmd")
  au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$") | exe "normal! g`\"" | endif
endif

Day 74

Day 76

  • 잔디콘 데이
    • Perlin noise: gradient noise, https://en.wikipedia.org/wiki/Perlin_noise
      • 수식을 간단하게라도 이해하고 싶었는데.. 위치를 참고한 바에 따르면, grid에 일정 간격으로 랜덤을 뿌린 다음, 해당 랜덤 사이들에는 scale을 둬 점차적 변화를 만들어낸다. 라고 볼 수 있는듯하다.
    • Caucal Inference: chain/fork/collider
      • 통계 모집단의 변수가 결과에 영향을 미치는데, 이게 잘못된 결론을 유추하게 될 수 있음.

Day 78

  • 요즘 높은 성과/성취를 얻는다고 생각하지 못하고 퍼포먼스가 떨어지는 것 같다고 느끼는 이유?
  1. (비슷한 연차인) 옆에 퍼포먼스가 너무 좋은 사람이 있다 - 질문같은걸 하기 고년차보다 어렵다?
  2. 프로젝트가 폭파된 적이 있어서, 중요하지 않은 프로젝트 장기간 진행으로 인해 성취도가 낮아졌다 - 최근 프로젝트 선택과 예측를 잘 해야겠다고 깨달음. 누가 정해주는게 아니라.
  3. 옆에 질문을 잘 받아주지 못하는 사람이 있다 - 질문을 열심히/다양한 방법으로 해보고 있지만 효과는 미미한..
  4. 업무가 약간 루즈/한가해져서 집중력이 떨어진다, 데드라인이 하드하지 않다 - 작년에 데드라인을 확실하게 했으면 좋겠다는 요구를 하였는데 다른 일정등이 발생했을 때 그것을 지키기 힘들어진 케이스가 있었음. 하지만 소프트 데드라인 자체는 업무 능률 향상에 도움이 되었음.
  5. 미뤄뒀던 업무 처리를 업무로 느끼지 못하고 있다 - 평가로서 반영되기 힘들기 때문?
  6. 내가 잘하고 있는지에 대한 기준이 명확하지 않다
  7. 평가 및 피드백이 명확하지 않다

Day 79

  • 다른 사람들의 생각/조언/이야기
    • 잘 하는 사람과의 협업은 뭔가 이상적인 것이 아니라, 그 사람 옆에 붙어서 코드 짜는걸 같이 보는 것 부터 시작 할 수도 있다.
    • 욕심이 너무 큰거다?
    • 자잘한 운영 업무나 과도한 외부 요청 등이 퍼포먼스 저하로 이어지기도 한다.
    • 피드백/질문에 취약한 리더는 좋은 리더가 아니다. 그 사람이 바뀌도록 노력하거나, 그럼에도 더 꼼꼼하게 질문하거나, 그러함을 인정하거나.

Day 81

  • 면접에서 사용되는 OOP key features
  • 추상화 / 캡슐화 / 상속 / 다형성
    • 주어진 문제를 잘 모델링 하자. 어떻게 모델링하는 것이 좋을지 명세를 명확히하고.
    • Data hiding. 멤버 변수들을 protected 등으로 관리. Python의 경우 _와 _ _로 protected와 private을 만들 수 있음.
    • Data와 method를 같이. 클래스 설계를 해야한다.
    • Has 관계와 inherit 관계를 명확하게 설명하자.
    • Dynamic binding의 유용성

Day 82

Day 85

OOP 디자인

  • 명세 구체화 -> 어떤것들이 필요한지?? 너무 많은걸 담지 않도록 심플하게 시작하자. -> 구성(변수)적인 요소, 기능(함수)적인 요소 들을 정리

  • UI가 필요한 것이라면 그려서 그것에 대해 컨센선스를 맞추자. 꼭 UI적인게 아니라도 그림으로 그려서 일자척으로 이게 어떤건지 알도록

  • 면접관이 원하는게 디자인인지, 클래스/인터페이스 설계인지를 명확하게 물어보도록 하자( 어디에 중점을 두고 있는건가요?)

  • 클래스 설계시 주의점들 -> 해당 클래스에 필요한 변수들 -> 변수들을 쓸 땐 이것들을 어떻게 set/사용할지 함수들도 같이 써야 함 -> 함수들을 쓸 땐 input arguments들은 어떤 것들이 될것인지 잘 생각해보고.

  • 상속 관계 설계시 -> abstract class 설계시 이게 왜 필요한지 잘 생각해보고. -> 일반적으로 dynamic binding이 필요하기 떄문. 어떤 공통된 함수를 상속된 클래스마다 다르게 불러야 하는 것이므로 그 함수가 뭔지 잘 살펴보자 -> loadObject() 함수라던지. -> 상속관계가 좋은지, 그냥 type을 has-A로 가지고 있는 설계가 좋은지 장단점에 대해 이야기 한 후 진행.

Day 86

Day 87

Day 91

Day 92

Day 93

Day 94

Day 98

  • https://leetcode.com/problems/trapping-rain-water
    • 영기의 도움으로 풂.. 천천히 생각해서 물을 그때그때 채울 수 있는만큼 채워가면 된다.
    • 1주일이 지났는데도 풀이가 명료한 방식이라 코딩할 때 좀 고생이긴하지만 풀 수 있었다는..

Day 99

Day 100

  • 지금까지 풀었던 전체 문제들 다시 머리로 풀어보기. 생각보다 엄청 많네요.. OOP나 함께자라기, 중간중간 팁도 있고요. TIL로 연습한 것들 잘 활용 할 수 있으면 좋겠군요