읽은 이유 최근 혼자 공부하는 운영체제 + 컴퓨터 구조라는 책을 읽었다. 책 내용은 OS 전반적인 내용을 쉽게 잘 설명해 주었지만 추상적이라 그걸 알아서 어디에 써먹을 수 있을까? 하는 의문이 들었다. 또, 백엔드 개발자에게 OS가 중요하다는 말이 자주 나와서 왜 알아야 할까 궁금하여 읽었다. 들어가기 전에 이 책에서는 백엔드 개발자가 OS를 공부해야 하는 이유에 대해서 우선 말한다. 우리가 생각했을 때 OS는 계층화가 잘 이루어져 있어서 좌측과 같이 예쁜 모델로 생각하기 쉬워 애플리케이션 레벨만 혹은 바로 그 아래 레벨만 잘 알면 되겠지 생각하기 쉽지만, 사실은 계층들 끼리 복잡하게 섞여 있어 저 밑바닥까지 이해하지 못하면 해결할 수 있는 문제를 만날 수 있다. 그 문제를 만났을 때 대처할 수 있도록 ..

궁금증이 생긴 이유 docker 위에 db를 띄우고 spring 애플리케이션을 실행시킨 상황에 lsof 명령어를 수행했다. 그런데 이때 예상하기론 mysql ps 정보만 떠야하는데, 그것 외에 여럿 많은 정보를 볼 수 있었다. mysql과 java의 연결, 그리고 개수가 10 * 2인 걸 봐서 대충 connection pool이겠거니 싶었다. (Hikari CP의 default connection 수는 10개. 클라이언트 -> 서버 / 서버 -> 클라이언트 스레드가 각 존재해야 하므로 * 2) 그런데 localhost 다음에 보이는 포트 번호는 뭐지? 하는 궁금증이 들었다. 나는 분명 3306 포트로 mysql을 띄웠는데 왜 처음보는 포트들이 등록되어 있고, 또한 왜 각자 다른 포트들이 등록되어 있나 궁..

최근 Kotlin을 사용하면서 TestStep을 선언할 때 확장 함수를 적극적으로 활용하고 만족하고 있다. 그러다가, 확장 함수를 멤버 함수로 선언할 수 있지만 그 경우 외부 파일에서 호출할 수 없기에 궁금증이 생겨 몇가지 실험을 해보았다. 우선 확장 함수를 최상단에 선언했을 때의 경우이다. 디컴파일한 코드를 보면 최상위에 파일명에 해당하는 클래스를 선언하고, 그 안에 정적 메서드를 선언한 것을 볼 수 있다. 그에 반해, 멤버 함수로 확장 함수를 선언할 경우 다음과 같게 된다. 정적 메서드가 아닌 인스턴스 메서드가 된다. Kotlin in Action을 보면 이런 말이 나온다. JVM이 클래스 안에 들어있는 코드만을 실행할 수 있기 때문에 컴파일러는 이 파일을 컴파일할 때 새로운 클래스를 정의해준다. ...

해시를 공부하다 보면 해시 충돌(Hash Collision)에 대해 공부할 수 밖에 없다. 물론 해시 함수를 만들 때 input과 output이 항상 1:1로 고정할 수 있으면 좋겠지만, output을 저장할 곳에 대한 물리적인 조건을 고려할 수밖에 없기 때문이다. 예를 들어, input이 들어올 수 있는 경우의 수는 100만가지인데, 정작 저장할 원소의 수는 10개라고 하자. 그러면 해시 충돌을 막기 위해 (input과 output을 1:1로 고정하기 위해) 배열의 크기로 100만으로 잡으면 이건 엄청난 낭비이다. 따라서 보편적으로 해시를 만들 때, 해시 함수를 적용한 output에 저장하는 테이블의 크기(m, 버켓의 크기)으로 나머지 연산을 수행해서 저장하도록 만든다. - output = hash(i..

부동소수점을 이해하려면 우선 디지털과 아날로그의 차이부터 이해해야 한다. 우리가 살고 있는 아날로그 세상의 수는 연속적(sequential)하지만, 디지털 세계의 수는 이산적(discrete)이다. 여기서 연속적이라는 의미는 값이 딱 나눠떨어지는 것이 아니라 무한대의 소수가 존재할 수 있다는 의미이다. 예를 들어 0.111011101110...과 같은 수가 존재할 수 있다. 이산적이라는 것은 손가락 하나, 둘과 같이 연속적인 것이 아닌 딱딱 떨어지는 수들이 존재함을 의미한다. 디지털 세계는 우리가 모두 알다시피 0과 1로 이루어져 있다. 따라서 디지털 세계에서 아날로그의 소수를 표현하기 위해 노력들을 해왔는데, 그중 하나가 IEEE 754다. 이는 부동소수점(floating point)을 정의한 표준이다..

p.7 우리가 어떤 현상을 인식했을 때 문제가 있다고 생각하는 이유는 그것이 '우리가 바라는 것'에 비해 무언가 부족하기 때문이다. 문제 해결사의 일은 어떤 형태로든 그 차이를 제거할 수 있는 방법을 찾아내는 것이며, 그 첫 단계는 불만족한 현상을 해결 가능한 형태의 문제로 표현하는 것이다. p. 21 실제로 자연스러운 일상의 문제를 단 한가지로 완벽하고 명백하게 정의하는 것은 불가능하다. 또 문제에 대한 어떤 공통된 이해 없이 나온 해결안은 여지없이 '엉뚱한' 문제에 대한 해결안이 되고 만다. ... 누구의 문제인가? ... 당신 문제의 본질은 무엇인가? p. 55 해결책이 있다고 해서 문제가 정의됐다고 보지 말라. 특히 그것이 당신 자신만의 해결안일 경우에는 더욱. p. 61 정확히 정의 내렸다고 결..