homebrew computer club

프로세스 프로세스는 ‘실행 중’인 프로그램 프로그램이 실행될 때 프로세스가 생성되고 PID를 부여받음. 프로세스를 생성하는 주체는 사용자가 될 수도 있고, 시스템이 될 수 있다. 프로그램과 프로세스는 동작을 하고 있는지, 하지 않고 있는지로 구분할 수 있다. 운영체제로부터 자원을 할당 받아 동작한다. 자원: CPU, Memory, IO, File 동작: CPU가 프로세스의 명령을 실행 사용자 및 시스템 프로세스가 존재 프로세스와 운영체제 프로세스 관리자 역할 프로세스를 생성 및 삭제 프로세스 실행(CPU 할당)을 위한 스케줄 결정 프로세스의 상태를 관리하며 상태 전이를 처리 프로세스의 상태 5-상태 모델(다섯 가지로 상태를 구분한 모델) 생성 처음 작업이 시스템에 주어진 상태. 즉, 프로그램을 이제 막 ..

논리적 모델링 단계 DBMS에서 사용하는 데이터 모델에 맞추어 데이터를 표현하는 과정 즉, ERD를 어떻게 RDBMS에 어떻게 담을 것인가 논의하는 과정 데이터 정의 언어 DDL로 기술된 개념 스키마 생성 관계형 모델(relation model) 1969년 에드가 F.코드에 의해 제안 릴레이션으로 데이터를 표현하는 모델 데이터 표현이 단순하고 직관적인 구조화 모델 현재 대다수 DBMS의 기초 Oracle, DB2, PostgresSQL, MySQL, MSSQL 등 릴레이션 구성 관계형 모델에서 표와 유사하게 2차원 구조로 데이터를 표현하는 구조를 릴레이션이라고 함. 스프레드 시트와 유사한 구조다. 관계형 모델은 위와 같은 표 형태로 구조화하고 저장하는 모델을 뜻한다. 일상생활에서 데이터를 저장하기 위해 ..

필요성 비즈니스적 관점 어떤 데이터를 저장해야 하는가? 어떤 데이터를 집어넣고, 집어넣지 않을지 결정하기 위해 비즈니스적 관점이 필요하다. 프로그래머의 관점 어떻게 데이터를 결정하는가? 어떤 데이터를 저장할 것인지 결정했으면, 그것을 어떻게 저장할지에 대한 관점이 필요하다. 모델링 단계 사용자 요구사항 분석 개념적 데이터 모델링 요구사항의 해석 오류를 방지 실세계 데이터를 개념적으로 일반화시켜 데이터 구조, 데이터 타입, 속성, 관계, 제약 조건 등을 이끌어내는 과정 논리적 데이터 모델링 → 개념 스키마 특정 DBMS의 구현 모델에 맞춰 데이터를 표현하는 과정 데이터 정의 언어(DDL)로 기술된 개념 스키마 생성 물리적 데이터 모델링 데이터베이스 파일 내부 저장구조, 파일 구성, 인덱스, 접근 경로 등을..

다음과 같은 제네릭 클래스가 있다. class Cup 위 코드에서 타입 파라미터 T 는 variance 한정자(out 또는 in )가 없다. 이럴 때는 기본적으로 invariant(불공변성)이다. invariant라는 건 제네릭 타입으로 만들어지는 타입들이 서로 관련성이 없다는 뜻. 말하자면 Cup 과 Cup , Cup 은 전혀 관계없다. 불공변성 관계 fun main() { val anys: Cup = Cup //Error: Type mistach val nothings: Cup = cup() // Error } 만약 어떤 관련성을 원한다면 out 또는 in 이라는 variance 한정자를 붙인다. out 은 타입 파라미터를 covariant(공변성)로 만든다. 이는 A가 B의 서브타입일 때 Cup 가..

Job의 라이프사이클을 이해하는 것은 잡을 구조화하고 실행 시에 발생하는 상황을 이해하는 데 중요하다. 잡을 정의할 때 실제로 하는 일은 잡과 관련된 청사진을 제공하는 것이다. 자바 클래스 코드 작성이 JVM에서 인스턴스를 생성하는 청사진을 정의하는 일인 것처럼 잡을 정의하는 것은 스프링 배치가 잡의 인스턴스를 생성하는데 필요한 일종의 청사진이다. 잡 실행은 job runner에서 시작한다. job runner는 잡 이름과 여러 파라미터를 받아들여 잡을 실행시킨다. 스프링 배치는 두 가지 잡 러너를 제공한다. CommandLineJobRunner: 이 잡 러너는 스크립트를 이용하거나 명령행에서 직접 잡을 실행할 때 사용한다. CommandLineRunner는 스프링을 부트스트랩하고, 전달받은 파라미터를 ..

배치 프로그램 정해진 시간에 일괄 작업을 처리한다(대체로 대용량) 배치 프로그램은 보이지는 않지만 늘 존재한다. 서비스 운영 관점에서 주기적으로 작업을 처리하려면 배치 프로그램을 사용해야 한다. 배치 프로그램이 필요한 상황 필요한 데이터를 모아서 처리해야 할 때 ex. 월별 거래 명세서 생성 일부러 지연시켜 처리할 때 ex.주문한 상품을 바로 배송처리 하지 않고 일정 시간 뒤 처리 자원을 효율적으로 활용하기 위해 트래픽이 적은 시간 대에 서버 리소스를 활용 데이터 처리 배치 프로그램 사용 예시 각 서비스의 데이터를 데이터 웨어하우스에 저장할 때 ETL(Extract-Transform-Load, 추출 - 변환 - 저장) 아마존에서 연관 상품을 추천하는 것처럼 데이터 모델을 만들 때 유저 리텐션, 액티브 상..

한 번도 취업을 해야겠다는 생각을 해본 적이 없었다. 내가 취업을 할 수 있을 거라는 생각도 못했다. 대한민국에서 고졸로 살아가는 일은 만만치 않은 일이고 취업 시장에 대해서는 깔끔하게 포기했었다. 아무도 가격을 매기지 않았지만 나 스스로 이 시장에서 내 가격표는 0원이라고 생각했다. 어쨌거나 그런 생각은 프로그래밍을 공부하면서도 이어졌다. 나름대로 2020년을 치열하게 보냈지만, 내가 정말로 돈을 받고 일하는 개발자가 될 수 있을까 계속해서 의심했다. 2020년 회고 마지막 문장에 “내년 오늘은 개발자로서의 첫 회고를 쓸 수 있었으면 좋겠다”고 썼다. 작년 오늘 내가 바랐던 대로 나는 개발자로서 회고를 쓴다. 1, 2월에는 포트폴리오로 사용할 마지막 프로젝트를 진행했다. 처음으로 도메인을 달고 이게 내..

테스트 대상이 되는 오브젝트 기능만을 충실하게 수행하면서 빠르게 자주 테스트를 실행할 수 있도록 사용하는 오브젝트를 통틀어서 테스트 대역test double이라고 한다. 이를테면 회원가입 비즈니스 로직에 회원가입을 축하한다는 메일을 보내는 로직이 포함되어 있다고 가정하자. UserService class UserService( private val mailSender: MailSender ) { fun signUp(user: User) { //가입 로직 //... //회원가입 메일 전송 val mailMessage = SimpleMailMessage() mailMessage.setTo(user.email) mailMessage.setFrom("useradmin@ksug.org") mailMessage.s..

캡슐화를 위반한 설계를 구성하는 요소들이 높은 응집도와 낮은 결합도를 가질 확률은 극히 낮다. 따라서 캡슐화를 위반한 설계는 변경에 취약할 수밖에 없다. 데이터 중심 설계가 변경에 취약한 이유는 두 가지다. 너무 이른 시기에 데이터에 관해 결정하도록 강요한다. 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다. 데이터 중심 설계는 객체의 행동보다 상태에 초점을 맞춘다 데이터 중심 설계를 시작할 때 던지는 첫 번째 질문은 "이 객체가 포함해야 하는 데이터가 무엇인가?"이다. 데이터는 구현의 일부다. 데이터 주도 설계에서는 설계를 시작하는 처음부터 데이터를 결정하도록 강요하기 때문에 너무 이른 시기에 내부 구현에 초점을 맞추게 된다. 데이터 중심 설계에 익숙한 개발자는 일반적으로 데이..

'상태'와 '행동'을 하나의 객체로 모으는 이유는 객체 내부 구현을 외부로부터 감추기 위해서다. 여기서 구현이란, 나중에 변경될 가능성이 높은 어떤 것을 가리킨다. 객체지향이 강력한 이유는 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치를 제공하기 때문이다. 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고, 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있다. 변경될 가능성이 높은 부분을 구현이라고 부르고, 상대적으로 안정적인 부분을 인터페이스라고 부른다. 객체 설계는 변경 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스만 의존하도록 해야 한다. 이것이 캡슐화다. 캡슐화의 정도가 응집도와 결합도에 영향..