일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- Git
- 에프랩
- Round Robin
- 생활코딩
- spring
- 버전관리
- Depromeet
- github
- 마블 다이어그램
- Observable
- 파이썬
- Hot Publisher
- 큐시즘
- RxJava
- 자바스크립트
- flab
- OS
- CLI
- Hot Publish
- OOAD
- 원격 저장소
- 디프만
- js
- 건국대학교
- CPU Scheduling
- time slice
- spring boot
- Cold Publisher
- 멘토링 후기
- js 개발자라면 알아야하는 핵심 컨셉
- Today
- Total
목록전체 글 (46)
글쓰는 개발자

Stage 2030 Analysis에서는 크게 두 가지 To-Do가 있다. 하나는 외부 Actor가 시스템에 접근하기 위해 필요한 Interface 역할을 하는 Operation들을 시스템 수준에서 분석하고 찾아내는 것이고, 다른 하나는 개발에 참여하는 개발자들이 전체적인 시스템 도메인에 대해 파악하기 위한 시간을 가지는 것이다. 본격적인 시스템 해부 및 설계의 단계로 넘어가기 위한 중간 단계로써, 이 단계를 거치면서 개발의 방향성이 더욱 구체화된다. INDEX Use-Case Model Use Case System Operation Domain Model Traceability Analysis 1. Use-Case Model Use-Case Model은 사용자가 시스템에게 기대하는 행동을 Operati..

현대의 대부분의 OS들은 Round-Robin Algorithm의 변형 형태의 Algorithm을 통해 프로세스들에게 CPU를 공평하게 분배하려 한다. [OS] Virtualization #2.CPU Scheduling 대부분의 프로세스들이 I/O 작업을 더 많이 필요로 하는 I/O-bound job이긴 하지만, 여전히 CPU의 처리를 더 많이 필요로 하는 CPU-bound job 또한 있기 마련이다. I/O-bound job은 Response time이 중요하기 때문에 짧은 Time Slice를 가지는 Round-Robin이 꽤나 효과적인 반면, CPU-bound job은 Turnaround time이 더 중시되어서 상대적으로 긴 Time Slice를 가지는 Round-Robin algorithm이 더..

지난 포스팅 객체지향 개발 방법론(OOAD) : OOP, UP에서 OOP, UP에 대해 소개하였다. 이번 포스팅부터는 본격적으로 OOPT에 대해 소개하려 한다. OOPT의 첫 번째 단계인 Stage 1000 Planning 단계에서는 이름처럼 제작할 시스템에 대한 명칭, 전반적인 계획, 비전, 투입 금액 산정, 요구사항 정의 등의 스케치 작업들을 수행한다. 시스템 개발 측면에서 크게 할 일은 없고, 비즈니스와 관련한 내용들이 오히려 주를 이룬다. 회사 내에서는 프로젝트 착수전 보고 단계이며, UP에서는 feasibility study를 수행하는 Inception Stage로 대응될 수 있다. INDEX Activity 1001. Define a draft plan Activity 1002. Create ..

이전 포스팅인 [OS] Virtualization #1.Limited direct execution에서 OS가 다른 프로세스들보다 상위 권한을 가지고, 그렇게 주어진 권한을 통해 각종 컴퓨터 자원들을 프로세스 사이에서 적당하게 분배하는 것이 어떻게 구현되는지 간략한 수준으로 소개하였다. 이번 포스팅에서는 상위 권한을 가지게 된 OS가 각 프로세스들에게 CPU를 할당하는 정책인 CPU Scheduling 정책에 대해 소개하려 한다. INDEX Workload Assumptions Scheduling Metrics FIFO(First In, First Out) SJF(Shortest Job First) STCF(Shortest time to completion first) RR(Round-Robin) 1. ..

OS의 역할은 부족한 컴퓨터 자원을 효율적으로 분배하는 것이다. 한 프로세스가 CPU를 너무 오래 점유하면, OS는 프로세스로부터 CPU를 뺏어 다른 프로세스에 할당한다. 어떠한 데이터가 자주 사용되지 않는 경우, OS는 해당 데이터를 CPU로부터 더 먼 곳에 배치하고 자주 사용되는 데이터를 CPU에 더 가까이 배치하여 실행 속도를 향상시킨다. 또한 어떠한 유저가 프로그램 내에서 하드웨어를 제어하는 명령을 실행할 때에, 이것의 핸들링을 담당하기도 한다. 여기까지 OS의 역할을 아는 것은 좋은데, 다음과 같은 의문을 제기할 수 있다. '프로세스가 실행 중이라는 것은 CPU가 프로세스에 할당되어 있다는 뜻이고, OS 또한 작업 수행을 위해 CPU 할당을 받아야 하는 시스템 소프트웨어인데 어떻게 중간에 OS가..

모든 일에 있어 가장 중요한 일은 개요(또는 목차)를 잡는 것이라고 생각한다. 개요를 잡고 무언가를 시작하게 되면, 큰 문제에 직면하더라도 그것을 조각내서 단순화하여 생각할 수 있고 개요 간의 관계 또한 선명하게 살필 수 있으며 전체 맥락도 빠르게 파악할 수 있는 등의 여러 가지 장점이 많다고 생각하기 때문이다. 이 개요라는 것은 비단 문장에서뿐만 아니라 어떤 영역에서든 적용될 수 있고, 각 영역에서 정의하는 그들만의 단어로 표현되는 듯하다. 소프트웨어 개발에 있어서 이러한 개요는 '설계'라는 단어로 표현할 수 있지 않을까. 무턱대고 각종 IDE를 실행하여 일단 코드를 써 내려가는 것보다는, 먼저 시스템에 대한 도메인을 파악하고, 아키텍처를 잡고 각 모듈들간의 관계에 대해 파악하는 등의 일련의 '개요 잡..

티스토리에서 포스팅을 하다 보면, 생각보다 많이 발생하는 에러가 맞춤법 검사 시 글쓰기 화면이 멈춰버리는 현상이다. 이 경우 화면이 아예 먹통이 되어 버리기 때문에, 새로고침을 해주어야 하는데 새로고침을 하면 여태 작성하던 글이 다 날아가버리기 때문에 티스토리 사용자 입장에서 굉장히 힘들고 화나는 경우가 아닐 수 없다. 그러다 최근에 개발자 모드를 활용하여 이 문제를 해결한 경험이 있어 공유하고자 한다. 보통 아래와 같은 글쓰기 화면에서 포스팅을 할 것이다. 그러다 '맞춤법 검사'를 클릭하면 자바스크립트 로드 에러로 인해 화면이 먹통이 되고, 화면 아래쪽의 '완료'가 아예 사라져 보이지 않거나 보여도 클릭이 안 되는 현상이 발생한다. 문제 해결의 원리는 개발자 모드를 통해 저 완료 버튼을 강제로 활성화시..

이번 학기에는 컴퓨터공학과의 핵심 과목 중 하나인 운영체제를 수강하였다. 운영체제를 수강하면서, 모든 파트에서 컴퓨터가 어떠한 방식으로 돌아가는지 배울 수 있어 정말 많이 배운 수업이었다. 기본적으로 운영체제의 역할은 '자원 관리'에 그 초점이 있다고 생각한다. 컴퓨터의 운용에 있어 물리적으로 충분한 자원이란 존재하지 않는다. 아무리 고성능 컴퓨터를 사용한다 할지라도 무한정의 프로세스를 허용하지는 않으므로, 컴퓨터의 자원을 효율적으로 활용하여야 한다. 컴퓨터 하드웨어의 구조적 효율을 통해 일정량의 자원 관리를 꾀할 수는 있겠으나, 하드웨어 단독으로 그것을 해결하는 데에는 분명한 한계가 있다. 따라서 이 문제를 소프트웨어와의 상호 작용을 통해 해결하여야 하는데, 이때 등장하는 시스템 소프트웨어가 바로 운영..

해당 주제로 포스팅을 하려고 보니 문득, 처음으로 학교에서 C언어 기반의 팀 프로젝트를 했던 시절이 기억난다. 각자 역할을 나누어 개발을 하고 다시 그 코드를 병합했을 때, 우리의 코드는 톱니바퀴처럼 맞물려 하나의 코드가 되고, 우리의 논리들은 하나의 논리가 되어 처음부터 끝까지 도미노처럼 멋지게 완성될 거란 희망을 품고 병합을 했을 때에, 우리는 우주 대폭발을 방불케 하는 코드 대폭발을 경험하였고, 코드의 엔트로피는 한없이 증가하여 손댈수록 돌아올 수 없는 강을 건너기만 할 뿐이었다. 그 덕분에 학점란에 고스란히 새겨진 C+라는 학점은 아직까지도 성적표에 남아 작성자를 괴롭히고 있다. 그때부터가 아니었을까? 코드를 나누기 전에, 어떻게 나눠야 다시 병합할 때 최소한의 에러와 논리 오류만 가져갈 수 있을..

어느덧 github을 통해 하나의 repository를 업로드하고, 그것을 다른 환경에서 동일하게 동기화하는 작업의 막바지에 다다랐다. 이전 포스팅에서, git clone 명령어를 통해 저장소를 다른 PC에 복제해보았다. 복제된 저장소는 다음과 같이 구성될 것이다. 즉 현재 맨 위의 세 개의 저장소가 모두 동일한 파일 구성을 가지게 되는 것이다. 이제 다른 PC에서도 저장소의 내용을 내려받아 수정할 수 있는 상태가 되었다. 복제된 저장소에서 한참 작업을 하여, 작업 내용을 File4.txt에 저장했다. Repository의 내용이 변경되었으므로, git status를 통해 working tree를 확인하면 File4가 untracked 상태일 것이다. 이전과 동일한 방식으로, Local Repositor..