TIL - 0318

1. 알고리즘

• 11번가 코테 
• 1번은 매우 쉽고, 2번은 SQL, 3번은 어려운편에 속했다.
• 문제는 SQL에서 생겼다. 평소 SQL 코테 준비를 전혀 하지 않았던 탓에 꽤나 당황했고, 또 평소 Oracle만 사용했기 때문에 MySql로 작성하는게 쉽지 않았다. 그리고 영어로 문제가 나왔기 때문에 문제를 정확히 인지 못한 탓도 있을 것이다.
• 결론은 1주일에 하루라도 SQL 테스트를 풀어보자..참 아쉽다

---

 

2. 운영체제(공룡책)

*챕터2 - 운영체제 구조 (Operating System Structures)

2.2.4 인터페이스 선택

 일반적으로 사용자 인터페이스의 선택은 개인의 선호에 달려있다. 보통 컴퓨터 시스템 관리자와 시스템에 대해 깊게 이해하고 있는 사용자는 주로 CLI를(예를 들어 프로그래머들), 일반적인 사용자들은 사용자 친화적인 GUI를 사용한다. 그리고 휴대용 장치에선 터치스크린 방식이 주를 이룬다.

 

 CLI의 경우 원하는 작업에 대해 더 빨리 접근할 수 있는 장점이 있다. 예를 들어 반복적으로 사용하는 작업이 있다면 그 작업을 파일로 저장해 이 파일을 프로그램처럼 실행하는 방식으로 수행할 수 있다. 이러한 프로그램은 실행 가능한 기계어 코드로 컴파일 되지는 않지만 셸 스크립트(shell scripts)와 같은 명령어 라인 인터페이스에 의해서 번역되면서 실행될 수 있다.

 

 UI는 시스템마다 심지어 한 시스템의 사용자마다 다를 수 있다. 그러나 통상 실제 시스템 구조에서는 제외되었다. 따라서 유용하고 친밀한 UI를 설계하는 것이 운영체제의 직접적인 기능은 아니다.

 

 

2.3 시스템 콜(System Calls)

시스템 콜은 운영체제에 의해 사용 가능하게 된 서비스에 대한 인터페이스를 제공한다.

 

2.3.1 예제

 한 파일로의 데이터를 다른 파일로 복사하는 프로그램으르 작성한다고 가정해보자. 첫번째 방법은 명령의 일부로 두 파일의 이름을 전달하는 것이다. 

cp in.txt out.txt

이 명령은 in.txt(입력)를 out.txt(출력)에 복사한다. 두 번째 방법은 프로그램이 사용장게 이름을 요청하는 것이다. 대화형 시스템에서 이 방법은 일련의 많은 I/O시스템콜을 필요로 한다. 

https://twinjh.tistory.com/15

한 파일을 다른 파일에 복사 할 때 생기는 일련의 시스템콜을 그림으로 나타냈다.

 

2.3.2 응용 프로그래밍 인터페이스 (Application Programming Interface)

 간단한 프로그램이라도 운영체제의 기능을 아주 많이 사용하게 된다. 종종 초당 수천 개의 시스템콜을 수행하게 된다. 그렇다면 사용자(프로그래머)는 복잡하게 이러한 시스템콜을 매번 요청해야 할까? 아니다. 보이지 않는 뒷에서 API를 구성하는 함수들은 통상 응용 프로그래머를 대신해 실제 시스템콜을 호출해준다. API를 사용하는 이점 중 하나는 프로그램의 호환성이다. API에 따라 프로그램을 설계하는 응용 프로그래머는 자신의 프로그램이 같은 API를 지원하는 어느 시스템에서든 컴파일, 실행 된다는 것을 예상할 수 있다.

 

 시스템콜을 처리하는데 있어 중요한 또 다른 요소는 실행시간 환경(RTE)이다. RTE는 운영체제가 제공하는 시스템 콜에 대한 연결고리 역할을 하는 시스템 콜 인터페이스를 제공한다.이 시스템 콜 인터페이스는 API함수의 호출을 가로채어 필요한 운영체제 시스템 콜을 부른다. 운영체제 인터페이스에 대한 대부분의 자세한 내용은 API에 의해 프로그래머로부터 숨겨지고 RTE에 의해 관리된다. 그러므로 프로그래머(호출자)는 단지 API를 준수하고 시스템 콜의 결과로서 OS가 무엇을 할것인지만 이해하면 된다.

 

 시스템 콜은 사용되는 컴퓨터에 따라 다른 방법으로 발생한다. 필요한 정보의 유형과 양은 특정 운영체제와 호출에 따라 다양하다.

open() 시스템 콜을 호출하는 사용자 응용프로그램의 처리

 운영체제에 매개변수를 전달하기 위해서 세가지 일반적인 방법을 사용한다.

• 레지스터 내에 전달
• 레지스터 보다 더 많을 경우 메모리내 블록, 테이블에 저장 -> 주소가 레지스터에 저장
• 프로그램에 의해 Stack에 저장되고, OS에 의해 꺼내진다.

일부 운영체제는 블록이나 스택방법을 선호하는데, 이 방법들은 전달되는 매개변수들의 개수나 길이를 제한하지 않기 때문이다.

https://tyen.tistory.com/4

 

* API : 각 함수에 전달되어야 할 매개변수들과 프로그래머가 기대할 수 있는 반환 값을 포함하여 응용프로그래머가 사용 가능한 함수의 집합을 명시한다.

 

* RTE(Runntime Environment) : 컴퓨터가 실행되는 동안 프로세스나 프로그램을 위한 소프트웨어 서비스를 제공하는 가상 머신의 상태를 말한다. 운영체제 자체에 속하거나 운영체제에서 작동하는 소프트웨어를 뜻할 수 도 있다.

 

 

사진 출처 : https://twinjh.tistory.com/15

 

 

---

3. 후니의 쉽게 쓴 시스코 네트워킹

* Part5

Section 5

기본 게이트웨이(Default Gateway) : 내부 네트워크에 요청한 MAC주소가 없는 경우 외부 네트워크로 나가기 위한 문

즉, 라우터의 이더넷 인터페이스가 된다.

 

라우터에는 인터페이스별로 각각 IP주소를 배정하지만, 스위치나 허브는 하나씩 배정하거나 배정할 필요가 없다. 단, 같은 IP주소를 사용하면 안된다.

 

Section 6

서브넷 마스크(Subnet Mask) 를 사용하는 이유 

• 브로드캐스트 영역 나누기 -> 영역이 너무 크면 정상적인 통신이 불가능해진다.
• IP주소의 낭비 방지

서브넷 마스크 또한 네트워크 영역을 나누는 것이기 때문에 각 네트워크는 라우터를 통해서만 통신 가능하다.

---

4. 김영한의 Spring 로드맵

자바 코드로 직접 스프링 빈 등록하기

package hello.hellospring;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import hello.hellospring.repository.MemberRepository;
import hello.hellospring.repository.MemoryMemberRepository;
import hello.hellospring.service.MemberService;

@Configuration
public class SpringConfig {

	@Bean
	public MemberService meberService() {
		return new MemberService(memberRepository());
	}
	
	@Bean
	public MemberRepository memberRepository() {
		return new MemoryMemberRepository();
	}
}

자바 코드로 빈 설정하는 방식과 컴포넌트 스캔을 통한 방식에는 각각의 장단점이 있다.

자바 코드로 설정하는 경우는 중간에 변경사항이 생기면 설정 파일(해당 프로젝트에선 SpringConfig class)만 수정하면 된다는 장점이 있다.

컴포넌트 스캔은 여러군데 수정할 사항이 생긴다. 하지만 컴포넌트 스캔 방식은 자바 코드 방식보다 사용하기 쉽고 편리하다는 장점이 있다.

 

  DI 방식 3가지

• 필드 주입 -> @Autowired MeberService meberService; 와 같은 형태로 주입 -> 외부에서 수정이 불가해지고 테스트 코드 작성 시 객체 수정이 불가해진다.
• setter 주입 -> public으로 사용되기 때문에 다른 곳에서 호출될 수 있는 가능성 때문에 사용을 잘 안하게 됐다.
• 생성자 주입 -> 현재 가장 많이 사용되는 주입 방법. 단,  의존관계가 실행중에 동적으로 변하는 경우 문제 발생(거의 없음)

좀 더 깊은 내용은 https://programforlife.tistory.com/111 (생성자 주입을 써야하는 이유)를 읽어보자.