저자는 " 내가 정말 잘할 수 있을까? " 가 아닌 " 내가, 우리가 정말 매일매일 함께 자랄 수 있을까? " 와 같은 질문으로 발전시키길 기대한다고 하며 시작한다.

유니온 파인드(Union-Find)

며칠 전, Go개발자와 이야기를 나누다 Go의 Garbage Collection이 흥미롭다며 이야기를 꺼냈다. Go의 Garbage Collection은 사용하지 않는 메모리(가비지)를 Garbage Collector를 통해 삭제한 후 해당 메모리 만큼을 가비지를

Spring Batch Batch 는 일괄처리 라는 뜻을 가진다. 우리와 같이 이미 상품을 담아 DB에 저장된 모든 데이터들의 변동된 가격을 알아오기 위해서는 DB에서 데이터를 읽고, 스크래핑하고(가공), 변동되었다면 저장을 하게되는데 서비스 이용자가 많아질수록, 가

친구들끼리 돈을 모아 함께 친구 생일 선물하기 위해 공유 장바구니에 생일인 친구가 선호하는 카테고리별 아이템을 추천받아 담고, 각자 선물해 주고픈 선물들도 담았지만 아직 무엇을 살지 결정을 하지 못했다. 질질 오래 끄는 의사결정이 아닌 실시간으로 함께 모여 한순간에

사용자가 우리 앱에 상품을 담으면 해당 상품을 스크래핑 해온 후 스크래핑 해온 이미지를 대상으로 카테고리 분석을 통해 해당 사용자의 선호도를 추천해주는 기능을 추가하였다. 그런데 문제가 생겼다. 스크래핑 해온 이미지를 카테고리 분류를 위해 이미지 모델 분석 과정을 거치

나만무 시작한지 벌써 3주가 흘렀다. react-native와 spring framework를 사용해서 범용적인 서비스를 만들겠다고 하던 패기 넘치는 우리팀이 share extension이라는 입문자에게는 높았던 허들을 넘어 구현을 진행해나가고 있다. 최근에는 채팅을

우리 Send Wish 어플은 친구 생일선물, 부모님 생신 선물 등을 혼자 또는 함께 상품을 고를 때 해야하는 많은 의사결정을 도와주는 툴로써 만들어지고 있다! 함께 결정하기 위해 상품들을 한눈에 보면서 이야기 나누고 싶다는 의견을 받아들여 공유 장바구니 내부 채팅방을

우리가 코드로 구현해본 현재까지의 fat filesystem 세계관은 아래와 같다.

subdirectories 들어가기 전 50 fail을 만들어야한다고 하는데 어디서부터 문제일까? test case 하나하나 잡기에는 너무 많고, 모르겠을 땐 일단 흐름을 잡아보며 진행하다가 do_format에 dir_create(ROOT_DIR_SECTOR, 16)를

우리의 작은 똥 자랑을 다시 해보려 한다..💩

우리 핀토스의 기본 파일 시스템은 파일을 한 덩어리로 할당해서 외부 단편화에 취약하므로, n개의 블록이 가용함에도 n개의 블록 파일이 할당되지 못할 수 있다. 고로 디스크의 inode 구조를 수정해서 이 문제를 해결하자.

친구 등 고객을 유치해 상응하는 경험을 해봤으면 좋겠고, 서버 밖은 미친놈이다^^ 를 겪어봐야 안다고. 팀원들과 이전 프로젝트 all pass를 위해 cow 관련 코드를 뜯어 고친 끝에!! 🎉

우리가 생각한 반례는 테스트 케이스로 잡아주지 못하고, 우리가 생각 못한 반례에서 터지는 작고 예민한 pintos가 징글징글하다. 오늘은 동기가 공유해준 토스 개발자의 회고글을 마저 읽었다.

하드웨어가 PTE에서 해당 page가 물리 메모리에 존재하지 않음을 표현해야 한다. 하드웨어는 present bit를 사용해 각 PTE에 어떤 페이지가 존재하는지를 표현한다. present bit가 1이라면 물리 메모리에 해당 page가 존재한다는 것이고 0은 물리 메

💡 깨알 깃팁git commit --amend -m "이전 커밋 메세지와 다르게 수정하고 싶은 내용" 을 통해 바로 이전 커밋 메세지를 수정할 수 있다.

Lazy Loading은 메모리 로딩이 필요한 순간까지 미룬다. 게으름의 끝. 나도 그러고 싶다. 이는 페이지가 할당되어 해당 페이지 구조체가 존재하지만, 그에 매핑된 물리 프레임이 없고 내부의 실제 컨텐츠도 아직 로드되지 않은 것이다. 컨텐츠는 딱 필요한 순간에 로드

memory management

Running a user program의 큰그림을 그려보자 물리 메모리가 제한되어 있지만 많은 프로세스가 물리적 메모리를 사용하려한다. 물리적 메모리는 모든 프로세스의 페이지를 항상 저장할 만큼 크지 않은데 말이다. 해서 물리 메모리에 페이지가 필요하지 않으면 페이지

pintos의 코드가 2만줄 넘다 보니까 하나하나 test case 확인이 쉽지 않았다. 하나하나 확인이 불가해서 test가 맞는지에 대한 어려움을 겪었다.하지만 결국,fork는 구현하였지만 통과되지 않는 fork 관련 test case 확인하여 아직 구현하지 않아 통