지금의 기록이 미래의 자산이 된다.

Today's records become tomorrow's assets.

throw와 throws 차이

2022-12-05

devfancy

Java
- try-catch 문
- throw 와 throws 차이
  - throw
  - throws
- throw와 throws차이를 짚고 가기 이전에, try-catch 문에 대한 개념을 먼저 알고 가자.
try-catch 문
```
try {
     예외가 발생할 가능성이 있는 실행문
}catch (Exception 클래스명 e){
     예외 처리문
}
```
- try 블록에 실제 실행되어야 하는 코드가 들어가며 Exception이 발생할 가능성이 있는 코드가 들어간다.
- catch 블록에는 Exception이 발생하면 실행되는 코드가 들어갑니다. 즉 예외 처리를 하는 코드다.
throw 와 throws 차이

throw
- throw : 개발자가 의도적으로 예외를 발생시키는 것이다.
- throw라는 키워드를 이용하며, 주로 비즈니스 로직을 구현하는 과정 중 컴파일에는 문제가 없지만 해당 비즈니스 로직이 개발자가 의도한 대로 통과하지 못했을 경우 고의로 예외를 발생시켜야 할 때 사용한다.
- 다음 예시는 숫자가 아닌 경우 혹은 3미만 20 초과인 경우 예외를 발생시키는 경우다.
- 여기서 min은 3, max는 20을 의미한다.
- 예외가 발생하면, IllegalArgumentException()으로 처리된다.
- IllegalArgumentException() : 적합하지 않거나(illegal) 적절하지 못한(inappropriate) 인자를 메서드에 넘겨주었을 때 발생합니다.
- 이처럼 throw 키워드를 사용하면 개발자의 판단에 따라 강제로 예외를 발생시킬 수 있다.
throws
- throws : 메서드 내에서 예외 처리를 하지 않고 해당 메서드를 사용한 곳에서 예외 처리를 하도록 예외를 다른 곳으로 던지는 것이다.
- 즉, 예외를 전가시키는 것이다.
```
public class Test {
	public static void main(String[] args) {
		int a = 2;
		int b = 0;
		try {
			divide(a,b);
		} catch (ArithmeticException e) {
			e.printStackTrace();
		}

	}

	public static int divide(int a, int b) throws ArithmeticException {
		if (b == 0) {
			throw new ArithmeticException("0으로 나눌 수 없습니다.");
		}
		return a / b;
	}
}
```
- 여기서 divide 메서드는 예외를 자신이 처리하지 않고 throws 키워드를 통해 자신을 호출한 main 메서드에게 책임을 전가했다.
- 이 divide 메서드를 호출한 main 메서드에서 try catch 문을 통해 예외 처리를 진행했다.
정리하자면,

throw는 강제로 예외를 발생시키는 것이며, 개발자의 의도에 따라 강제로 예외를 발생시킬 수 있고, throws는 자신을 호출한 메서드에게 책임을 전가하여 호출한 메서드에서 예외 처리를 하도록 강요하는 것이다.
- throw를 사용하는 이유는 예외가 발생할 수 있는 코드가 있다는 것을 인지시키고 예외 처리를 강요하며, 여러 가지 발생 가능한 예외들을 호출한 메서드에서 한 번에 처리할 수 있게 하는 장점이 있다.
Read All

[Git] 커밋 메세지 규약 정리 (AngularJS)

2022-12-05

devfancy

Git

Git 커밋 메세지의 7가지 규칙
Subject Line (제목)
Message body (내용)
Message footer
- Breaking changes (주요 변경 내용)
- Referencing Issues (해결된 이슈?)
예시
Reference

Git 커밋 메세지의 7가지 규칙

제목과 분문을 빈 행으로 구분한다.
제목을 50글자 내로 제한한다.
제목 첫 글자는 대문자로 작성한다.
제목 끝에는 마침표를 넣지 않는다.
제목은 명령문을 사용하며 과거형을 사용하지 않는다.
본문의 각 행은 72글자 내로 제한한다.
어떻게 보다는 무엇과 왜를 설명한다.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

커밋 메시지의 각 줄은 100자를 넘을 수 없습니다. 이래야지 github와 다양한 git도구들에서 쉽게 메시지를 읽을 수 있습니다.

Subject Line (제목)

제목에는 변경사항에 대한 간결한 설명을 포함시킵니다.

Type에 들어갈 수 있는 항목들

feat (feature) : 새로운 기능 추가
fix (bug fix) : 버그 수정
docs (documentation) : 문서 관련 내용
style (formatting, missing semi colons, …) : 스타일 변경
refactor : 코드 리팩토링
test (when adding missing tests) : 테스트 관련 코드
build : 빌드 관련 파일 수정
ci : CI 설정 파일 수정
perf : 성능 개선
chore (maintain) : 그 외의 수정

Scope에 들어갈 수 있는 내용들

어디가 변경되었는지에 관하여 변경된 부분은 모두 들어갈 수 있습니다. $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, 등등…이 들어갈 수 있으며 scope는 생략 가능합니다.

Subject

명령형 현제 시제를 사용해야합니다. -> changed, changes가 아닌 change를 사용❗
첫 글자는 대문자가 아닌 소문자로 사용합니다.
문장 끝에 마침표(.)를 붙이지 말아야 합니다.

Message body (내용)

명령형과 현제 시제를 사용해야합니다.
변화에 대한 이유와 이전코드와 이후 코드의 차이점을 포함시켜야 합니다.

Message footer

Breaking changes (주요 변경 내용)

모든 주요 변경 사항

변경 사항에 대한 설명 (description of the change)
변경사유 (justification)
마이그레이션 참고 사항 (migration notes) 과 함께 footer에 언급되어야 합니다.

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.
    To migrate the code follow the example below:
    Before:
    scope: {
      myAttr: 'attribute',
      myBind: 'bind',
      myExpression: 'expression',
      myEval: 'evaluate',
      myAccessor: 'accessor'
    }
    After:
    scope: {
      myAttr: '@',
      myBind: '@',
      myExpression: '&',
      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
      myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }
    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

Referencing Issues (해결된 이슈?)

해결되 이슈는 커밋 메시지 하단에 Closes #<이슈번호>와 함께 기록해야합니다.

이슈가 하나인 경우
Closes #234

이슈가 여러개인 경우
Closes #123, #245, #992

예시

feat($browser): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Breaks $browser.onHashChange, which was removed (use onUrlChange instead)

fix($compile): couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Closes #392
Breaks foo.bar api, foo.baz should be used instead

feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected

New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.

Closes #351

style($location): add couple of missing semi colons

docs(guide): updated fixed docs from Google Docs

Couple of typos fixed:
- indentation
- batchLogbatchLog -> batchLog
- start periodic checking
- missing brace

feat($compile): simplify isolate scope bindings

Changed the isolate scope binding options to:
  - @attr - attribute binding (including interpolation)
  - =model - by-directional model binding
  - &expr - expression execution binding

This change simplifies the terminology as well as
number of choices available to the developer. It
also supports local name aliasing from the parent.

BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.

To migrate the code follow the example below:

Before:

scope: {
  myAttr: 'attribute',
  myBind: 'bind',
  myExpression: 'expression',
  myEval: 'evaluate',
  myAccessor: 'accessor'
}

After:

scope: {
  myAttr: '@',
  myBind: '@',
  myExpression: '&',
  // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
  myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.

Reference

Read All

클래스 다이어그램 그리는 기능

2022-12-03

devfancy

IntelliJ
- 다이어그램 그리기
- 개발을 하면서 내가 짠 코드들을 머릿속으로 온전히 이해하기가 쉽지 않다.
- 그리고 개발이 시작하기 전, 끝난 이후에 구현한 것에 대한 클래스 다이어그램을 직접 그리는 시간이 오래 걸리는 경우가 있다.
- 이런 경우 ‘IntelliJ에서 제공하는 다이어그램 기능을 쓰면 시각적인 이해 + 시간 절약 이 되지 않을까?’ 하는 마음으로 해당 포스팅을 작성하게 되었다.
다이어그램 그리기
- 우아한테크코스5기의 4주차 미션 다리 건너기 를 예시로 가져왔다.
Read All
8. The Multi-Level Feedback Queue(MLFQ)

2022-11-30

devfancy

OS
이 글의 사진과 내용은 공룡책 과 컴퓨터학부 수업인 운영체제 강의자료를 기반으로 작성했습니다.

Multi-Level Queue

멀티-레벨 큐(MLQ)
- MLQ란 준비 큐를 여러 개로 분할해 관리하는 스케줄링 기법을 말한다. 즉 프로세스들이 CPU를 기다리기 위해 한 줄로 서는 것이 아니라 여러 줄로 서는 것이다.
- MLQ는 일반적으로 성격이 다른 프로세스들을 별도로 관리하고, 프로세스의 성격에 맞는 스케줄링을 적용하기 위해 ready queue를 별도로 두게 된다.
- 미래를 예측하기 위해 과거를 배우는 스케줄러이다.
ML(F)Q : Basic Rules
- ML(F)Q는 다수의 개별 queue를 유지한다.
  - 각각의 queue는 다양한 우선순위 레벨을 부여받는다.
- Rule 1 : Run-time이 짧은 job에게 우선순위(priority)를 부여한다.
- Rule 2 : 만약 우선순위가 같으면, 라운드 로빈 스케줄링(RR)을 사용한다.
- ML(F)Q Example : Static Snapshot
- MLQ는 관찰된 동작에 따라 작업의 우선순위를 변경한다.
- Example 동작 :
  - job은 I/O를 기다리는 동안 CPU를 반복적으로 양도한다.
    - 대화형(interative) 프로세스의 동작은 다음과 같습니다.
    - 우선순위를 높게 유지(단시간 슬라이스 포함) -> 응답 시간 향상
  - job이 장시간 동안 CPU를 집중적으로 사용한다.
    - 일괄(batch) 작업의 동작은 다음과 같습니다.
    - 우선순위 감소(긴 시간 슬라이스 포함) -> 소요 시간 단축
- 이러한 방식으로 MLQ는 프로세스가 실행될 때 프로세스에 대해 학습하고, 따라서 job의 기록을 사용하여 미래의 동작을 예측합니다.
Multi-Level Feedback Queue

멀티레벨 피드백 큐(MLFQ)
- MLFQ는 CPU를 기다리는 프로세스를 여러 queue에 줄 세운다는 측면에서 MLQ와 동일하나, 프로세스가 하나의 queue에서 다른 queue로 이동 가능하다는 점이 다르다.
Read All
7. Scheduling

2022-11-30

devfancy

OS

Read All

46/58

지금의 기록이 미래의 자산이 된다.

throw와 throws 차이

try-catch 문

throw 와 throws 차이

throw

throws

[Git] 커밋 메세지 규약 정리 (AngularJS)

Git 커밋 메세지의 7가지 규칙

Subject Line (제목)

Type에 들어갈 수 있는 항목들

Scope에 들어갈 수 있는 내용들

Subject

Message body (내용)

Message footer

Breaking changes (주요 변경 내용)

Referencing Issues (해결된 이슈?)

예시

Reference

클래스 다이어그램 그리는 기능

다이어그램 그리기

8. The Multi-Level Feedback Queue(MLFQ)

Multi-Level Queue

ML(F)Q : Basic Rules

Multi-Level Feedback Queue

7. Scheduling