Owl Life

Free Json Formatter (Beautify)

Owl Life — Thu, 9 Apr 2026 00:43:49 +0900

개발하다 보면 API 응답, 설정 파일, 로그에 섞인 JSON을 한눈에 읽기 좋게 만들고 싶을 때가 많습니다.

AllThatConverter의 JSON 포맷터(Beautify)는 브라우저에서 바로 JSON을 정리하고, 필요하면 로그에 끼어든 JSON까지 전처리한 뒤 포맷할 수 있는 무료 도구입니다.

이럴 때 쓰면 좋아요

- API로 받은 한 줄짜리(minified) JSON를 들여쓰기해서 보고 싶을 때
- 에디터/메모에 붙여 넣은 JSON이 따옴표·쉼표만으로는 읽기 어려울 때
- 로그 한 줄마다 앞에 타임스탬프·[body] 같은 접두어가 붙어 있어, 진짜 JSON만 이어 붙여야 할 때
- 정리된 JSON을 트리 구조로 펼쳐 보고 싶을 때

핵심 기능

1. Beautify — JSON 정리
붙여 넣은 문자열을 파싱한 뒤, 일정한 들여쓰기로 다시 출력합니다. 서버로 파일을 올리지 않고 브라우저 안에서만 처리됩니다.

2. (선택) 전처리 — 로그·특수 포맷 대응
로그처럼 줄마다 앞부분이 다른 경우, 정규식 프리셋으로 앞쪽 노이즈를 제거한 다음 포맷할 수 있습니다. 자주 쓰는 패턴은 저장해 두고, 필요할 때만 켜면 됩니다.

3. 트리 뷰어
포맷이 성공하면 Tree viewer로 객체·배열 구조를 펼쳐 볼 수 있습니다.

4. 샘플 불러오기
동작을 확인하고 싶을 때 일반 JSON 샘플과 로그에 감싼 JSON 샘플을 불러올 수 있습니다.

바로가기

https://allthatconverter.web.app/tools/json/beautify-json

Beautify Json | AllThatConverter

Use AllThatConverter to beautify json in your browser. Free, no signup.

allthatconverter.web.app

Tree Viewer & Search

Coroutines & Flows - 다섯가지 안티 패턴

Owl Life — Sat, 14 Jun 2025 20:32:52 +0900

1. UI 업데이트를 메인 스레드에서 하면 안 되는 이유

여러분 앱의 화면(UI)은 마치 상점의 간판처럼 항상 손님(사용자)에게 최신 정보를 보여줘야 합니다.
그런데 이 간판을 업데이트하는 작업이 너무 복잡하고 오래 걸리면(CPU를 많이 사용하면), 간판이 잠시 멈춰버리겠죠?
- 이처럼 뷰 모델에서 UI 상태를 업데이트하는 복잡한 로직을 실행할 때, 기본적으로는 메인 스레드라는 중요한 길에서 작업하게 됩니다.
- 이 길이 막히면 앱 화면 전체가 멈추는 것처럼 느껴져서 사용자가 불편함을 느낍니다.
이 문제를 해결하려면 복잡한 UI 업데이트 작업은 Default Dispatcher라는 다른 작업자에게 맡겨야 합니다.
- 이렇게 하면 메인 스레드가 막히지 않고, UI는 계속 부드럽게 움직일 수 있습니다.

2. 화면 이동 시 데이터 저장이 날아가 버리는 문제

앱에서 화면을 이동할 때(예: 노트 작성 화면에서 목록 화면으로 돌아갈 때), 현재 화면과 연결된 View Model Scope에서 실행 중인 코루틴은 자동으로 취소됩니다.
만약 이 코루틴안에서 데이터를 저장하거나 서버와 동기화하는 중요한 작업을 하고 있었다면, 화면을 이동하는 순간 그 작업이 중간에 멈춰버릴 수 있습니다.
- 예를 들어, 작성 중인 노트를 저장 버튼을 눌러 저장하고 바로 이전 화면으로 돌아갔는데, View Model Scope가 취소되면서 서버에 저장되지 않는 문제가 발생할 수 있습니다.
이 문제를 막으려면 두 가지 방법이 있습니다.
- 첫째, 데이터 저장이 완료될 때까지 UI에게 기다리라고 알려주고, 저장이 끝난 후에 화면 이동을 시킵니다.
- 둘째, View Model Scope 대신 앱이 살아있는 동안 계속 유지되는 Application Scope를 사용해서 중요한 백그라운드 작업을 실행합니다.

3. 병렬로 할 수 있는 일을 순서대로 시키는 문제

안티 패턴	문제점	올바른 해결 방법	예시
병렬 작업 순차 실행	여러 코루틴 작업을 병렬로 실행하여 시간을 단축할 수 있음에도 불구하고, 순서대로 실행하게 만듦.	모든 코루틴 작업을 먼저 시작(launch)시킨 후, 마지막에 모든 코루틴이 완료될 때까지 한꺼번에 기다림(join).	프로필 사진 업로드와 프로필 정보 업데이트를 동시에 진행.
`launch` 사용 후 바로 `join` 호출	코루틴을 시작하고 바로 완료될 때까지 기다리므로, 다음 작업이 시작되기 전에 현재 작업이 끝나야 함.	모든 `launch` 호출을 먼저 완료한 후, 마지막에 모든 `join` 호출을 수행.	`launch { 작업1() }; launch { 작업2() }; 작업1.join(); 작업2.join()` (잘못된 방식) vs `launch { 작업1() }; launch { 작업2() }; joinAll()` (올바른 방식)
`async` 사용 후 바로 `await` 호출	비동기 작업을 시작하고 바로 결과를 기다리므로, 비동기 작업의 이점을 살리지 못하고 순차적으로 실행됨.	모든 `async` 호출을 먼저 완료한 후, 마지막에 모든 `await` 호출을 수행.	`val 결과1 = async { 작업1() }.await(); val 결과2 = async { 작업2() }.await()` (잘못된 방식) vs `val 작업1 = async { 작업1() }; val 작업2 = async { 작업2() }; val 결과1 = 작업1.await(); val 결과2 = 작업2.await()` (올바른 방식)

여러 코루틴작업을 동시에(병렬로) 실행하면 전체 작업 시간을 크게 줄일 수 있습니다. 예를 들어, 프로필 사진 업로드와 프로필 정보 업데이트는 서로 기다릴 필요 없이 동시에 진행될 수 있습니다.
하지만 launch를 사용해서 코루틴을 시작하자마자 바로 join을 호출하거나, async를 사용하고 바로 await를 호출하면, 마치 한 사람씩 줄 서서 일을 처리하는 것처럼 순서대로 실행되게 만들어 버립니다.
- launch는 코루틴을 시작하라는 명령이고, join은 그 코루틴이 끝날 때까지 기다리라는 명령입니다.
- launch 다음에 바로 join을 쓰면, 첫 번째 작업이 끝날 때까지 기다렸다가 두 번째 작업을 시작하게 됩니다.
올바르게 병렬 실행을 하려면, 모든 코루틴작업을 먼저 다 시작( launch)시켜 놓습니다.
- 그리고 마지막에 모든 코루틴이 완료될 때까지 한꺼번에 기다리도록( join) 하면 됩니다. 이렇게 해야 비로소 여러 작업이 동시에 착착 진행됩니다.

4. while true 반복문에서 취소 요청이 무시되는 문제

데이터를 주기적으로 가져오는 작업처럼 while true 무한 반복문 안에서 코루틴을 실행할 때 주의해야 할 점이 있습니다.
만약 이 반복문 안에 try-catch 블록을 사용하여 일반적인 예외를 잡도록 코드를 작성하면 문제가 생길 수 있습니다.
- 코루틴이 취소될 때 발생하는 취소 예외(Cancellation Exception)는 try-catch 블록에 의해 일반 예외처럼 잡혀버릴 수 있습니다.
- 이렇게 되면 코루틴은 사실상 취소된 상태인데, 반복문은 취소 사실을 인지하지 못하고 계속 돌게 됩니다. 마치 "취소됐는데 취소 안 된 척"하며 무한 루프에 빠지는 거죠.
이 문제를 해결하려면 try-catch 블록 안에서 예외를 잡은 후, coroutineContext.ensureActive()를 호출하여 현재 코루틴이 활성 상태인지 다시 확인해야 합니다.
- 이 함수는 만약 코루틴이 취소된 상태라면 취소 예외를 다시 발생시켜서 반복문이 제대로 종료되도록 돕습니다.

5. Supervisor Job을 잘못 사용하는 문제

안티 패턴	문제점	올바른 사용법	설명
Supervisor Job을 launch 함수에 직접 전달	자식 코루틴들이 Supervisor Job의 독립적인 실패 처리 혜택을 받지 못하고 부모의 실패에 영향을 받음	`supervisorScope` 블록 안에서 코루틴 실행	`supervisorScope` 안에서 시작된 코루틴은 서로 독립적으로 실패 처리됨

supervisor job은 특정 코루틴이 실패하더라도 다른 자식 코루틴들이 영향받지 않고 계속 실행될 수 있도록 해주는 특별한 Job입니다.
하지만 launch 함수에 Supervisor Job을 직접 인자로 전달하는 것은 올바른 사용법이 아닙니다.
- 코루틴의 Job은 자식 코루틴에게 상속되지 않는 유일한 컨텍스트 요소입니다.
- 그래서 launch에 Supervisor Job을 직접 넘겨주면, 코틀린 내부적으로 이상한 계층 구조가 만들어져서, 자식 코루틴들이 supervisor job의 혜택(실패 시 독립적인 실행)을 제대로 받지 못합니다. 즉, 따로 놀아야 할 자식들이 부모 때문에 같이 실패하게 되는 거죠.
supervisor job의 기능을 제대로 사용하려면 supervisorScope라는 특별한 함수 블록 안에서 코루틴을 실행해야 합니다.
- supervisorScope 안에서 launch로 시작된 코루틴들은 서로 독립적으로 실패할 수 있게 됩니다. 마치 각자 알아서 책임지고 실패하는 자식들처럼 말이죠.

출처 : https://youtu.be/JyBq76N4Zc4?si=OEGCPCf9D0_37NTY

메타 쓰레드 이미지 / 비디오 다운로드

Owl Life — Thu, 10 Aug 2023 21:31:23 +0900

소개

메타에서 만든 쓰레드 앱의 이미지나 비디오를 다운로드 받는 방법에 대해서 알아보겠습니다.

아래 싸이트에 접속 후 게시글의 주소를 복사해서 붙여 넣으면 됩니다.

www.threads-media-downloader.com

Threads Media Downloader

threads-media-downloader.com. Threads 앱 비디오, GIF 및 이미지를 JPEG 또는 mp4 형식으로 장치에 다운로드하고 저장할 수 있는 무료 온라인 플랫폼입니다. 모바일 또는 PC에 스레드 미디어를 저장하고 오프

www.threads-media-downloader.com

사용 가능한 환경

PC / SmartPhone Web (IOS, Android OS)

모든 환경에서 사용 가능합니다.

유튜브 영상 참고

https://youtube.com/shorts/9pyFgJaj2Sc

속도가 매우 빠르고 사용이 간편하다는 큰 장점이 있습니다.

또한, 한글로 되어 있어서 가독성 또한 좋습니다. ^^

------------------------------------------------

쓰레드 미디어 다운로더

GRASP

Owl Life — Wed, 21 Dec 2022 23:57:41 +0900

GRASP Pattern

General Responsibility Assignment Software Pattern

**OO 디자인의 핵심은 각 객체에 책임을 부여 하는것** **책임을 부여하는 원칙을 말하는 패턴**

Informatoin Expert (제일 중요)

책임을 수행할 수 있는 데이터를 가지고 있는 객체에 책임을 부여하는 것. 객체는 데이터와 처리로직이 함께 묶여 있는것. 정보 은닉을 통해 자신의 데이터를 감추고 오직 메서드로만 데이터를 처리하고, 외부에는 그 기능(책임)만을 제공.

Creator

객체의 생성은 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여.

Controller

시스템 이벤트(사용자의 요청)을 맞이할 객체를 만들자. 처리 하는것이 아님.

<UseCaseName>Handler,
<UseCaseName>Coordinator,
<UseCaseName>Session

Low Coupling

객체들간, 서브 시스템들간의 상호의존도가 낮게 책임을 부여.

High Cohesion

각 객체가 밀접하게 연관된 책임들만 가지도록 구성.

Polymorphism

객체의 종류에 따라 행동양식이 바뀐다면, Polymorphism 기능을 사용하자. Object-Oriented 시스템은 상속과 Polymorphism(다형성)을 지원한다. 만약 객체의 종류에 따라 행동이 바뀐다면 객체의 종류를 체크하는 조건문을 사용하지 말고, Object-Oriented 시스템의 Polymorphism 기능을 사용하라.

Pure Fabrication

**Information Expert 패턴을 적용하면 Low Coupling과 High Cohesion의 원칙이 깨어진다면, 기능적인 역할을 별도로 한 곳으로 모으자.** 데이터베이스 정보를 저장하거나, 로그 정보를 기록하는 역할에 대해 생각해 보자. 각 정보는 각각의 객체들이 가지고 있을 것이다. 이 때 Information Expert 패턴을 적용하면, 각 객체들이 정보를 저장하고, 로그를 기록하는 역할을 담당해야 하지만, 실제로 그렇게 사용하는 사람들은 없다. 이것은 그 기능들이 시스템 전반적으로 사용되고 있기 때문에 각 객체에 그 기능을 부여하는 것은 각 객체들이 특정 데이터베이스에 종속을 가져오거나, 로그을 기록하는 매커니즘을 수정할 경우, 모든 객체를 수정해야 하는 결과를 가져온다. 즉 Low Coupling의 원칙이 깨어지게 된다. 이럴 경우에는 공통적인 기능을 제공하는 역할을 한 곳으로 모아서 가상의 객체, 서브시스템을 만들어라.

Indirection

두 객체 사이의 직접적인 Coupling을 피하고 싶으면, 그 사이에 다른 객체를 사용하라. 여기서 말하는 다른 객체란 인터페이스가 될 수 있고, 주로 인터페이스인 경우가 많다. 그런 특별한 경우는 아래에 설명된 Protected Variations 패턴이라고 부를 수 있다.

Protected Variations

변경될 여지가 있는 곳에 안정된 인터페이스를 정의해서 사용하자. JDBC에 대해서 생각해 보자. JDBC는 일련의 인터페이스들로 구성되어 있으며, 각 데이터베이스 벤더들이 인터페이스를 구현한 Concrete 클래스를 제공하고 있다. 데이터베이스 기능을 사용하는 시스템의 입장에선 각 벤더들이 구현방식을 바꾸었을 때, 자신의 코드를 수정하고 싶지 않을 것이다. 그래서 Driver를 로딩하는 코드를 제외하고는 모두 인터페이스를 사용함으로서 데이터베이스의 변경시에도 Driver 로딩만 바꾸어 주면 되도록 데이터베이스 관련 작업이 필요한 곳에는 안정된 JDBC 인터페이스를 사용한 것이다.

11. Re-engineering / Refactoring

Owl Life — Sun, 4 Dec 2022 17:56:37 +0900

Reverse Engineering 무엇인가요?

제품의 유지보수, 개선 또는 교체를 돕기 위해 제품에 대한 설계 수준의 충분한 이해 를 얻는 프로세스.
재문서화, 설계 복구

Reengineering 무엇인가요?

리엔지니어링은 일반적으로 일부 형태의 리버스 엔지니어링(보다 추상적인 설명을 달성하 기 위해)에 이어 일부 형태의 순방향 엔지니어링 또는 구조 조정을 포함합니다.

Reengineering 방식은?

리팩토링 대상을 선정한다
선정된 대상을 테스트 코드 작성한다.
코드를 분해한 후 재조립한다.
재조립 코드를 테스트한다.
위 과정을 반복한다.

Test Driven Refactoring 무엇인가요?

1 실패한 단위 테스트를 만듭니다.
2. 해당 테스트를 통과하는 프로덕션 코드를 작성합니다
3. 방금 만든 혼란을 정리하십시오.

Golden Master Test

프로세스를 수행한 다음 저장된 "골드 마스터"와 향후 실행을 비교하여 예기치 않은 변경 사항을 발견합니다.

리팩토링이란?

리팩토링 또는 전체 코드 리팩토링은 새로운 기능을 도입하거나 대상 소프트웨어의 기본 작업을 변경하지 않고 이전에 빌드된 소스 코드를 수정하는 체계적인 프로세스.

소프트웨어의 원래 기능을 방해하지 않고 기본 코드의 구조, 정의 및 구현을 최적화하기 위한 사소한 프로그래밍 조정이라고 생각할 수 있습니다. 최종 결과는 일반적으로 소프트웨어의 가독성, 유지 관리성 및 확장성에 대한 개선입니다.

리팩토링 중에 소프트웨어 개발 팀이 일반적으로 수행하는 몇 가지 조치는 다음과 같습니다.

코드 크기 줄이기
혼란스러운 코드를 더 간단한 코드로 재구성
코드를 정리하여 더 깔끔하게 만들기
중복되고 사용되지 않는 코드 및 주석 제거
불필요한 반복 없애기
유사한 코드 결합
재사용 가능한 코드 생성
긴 기능을 더 간단하고 관리하기 쉬운 비트로 나누기

리팩토링 이점

가독성 향상
유지 보수성, 확장성 증가
성능 개선
시간/돈 절약

리팩토링 몇가지 테크닉

Red-Green Refactoring
Extract Method
Simplifying Methods
Composing Method
Abstraction

Process

리팩토링이 필요한 부분을 찾아서 진행한다?

Instructions

Re-engineering for Different Paradigms

From C Programs to Object-Oriented Design

도메인 엔티티를 식별해내고 그것을 객체로 만듭니다
Procedure에 있던 책임을 GRASP 원칙을 지키면서 객체들에 옮겨줍니다
Procedure을 Usecase라고 본다면 Loose coupling, high cohesion으로 묶어서 객체화, Component화 합니다.
Abstraction, Encapsulation하여 객체를 만들어야합니다.

10. Architecture Evaluation

Owl Life — Sun, 4 Dec 2022 17:56:00 +0900

ATAM

Architecture Tradeoff Analysis Method

아키텍처가 품질 목표를 만족하는지 여부와 품질 목표간에 발생하는 충돌에 대해서도 분석함.

CBAM

Cost Benefit Analysis Method

ATAM에 경제적 평가를 보강함

요구사항과 투자에 관한 의사 결정을 지원함

투자 비용 대비 이득

9. Tactics for NFR

Owl Life — Sun, 4 Dec 2022 17:54:42 +0900

Architecture Design for Conventional NFRs

SRS에 공통으로 나타나는 NFR

결국, Quality Attribute 가 됨.

Tactics for common NFRs: Available

Architecture Design for Non-Conventional NFRs

타겟 시스템에 특정됨

Tactics to be devised by Architectures

Impact of Tactics on Views

NFR Design 과정

Identify Facts and Policies
Define Criteria for Tactics
Define Candidate Tactics
Evaluate Candidate Tactics
Benefit, Cost, Decision
Analyze Impacts of Tactics on Views
각 뷰에서 어떤 영향을 미치는지 표로 만듬
Apply Tactics on Views
각 뷰에 택틱을 적용
Validate Conformance
Traceability 검증

8. Architecture Viewpoints

Owl Life — Sun, 4 Dec 2022 17:54:13 +0900

View 란?

시스템을 이루는 SW요소들의 집합 과 SW요소들의 연관 관계를 추상적 으로 표현한 것

Module View 무엇인가요?

Module간의 상호 연결 관계

Runtime View = Component and Connector View(C&C View)

예를 들어 뭐가 있을까요?
split lower upper merge 등

파이프-필터 스타일(Pipe-and-Filter Style)
공유-데이터 스타일(Shared-Data Style)
게시-구독 스타일(Publish-Subscribe Style)
클라이언트-서버 스타일(Client-Server Style)
피어 투 피어 스타일(Peer-to-Peer Style)

Allocation View 무엇인가요?

Software Architecture와 환경을 매핑시키는 역할을 한다. 우선 Deployment Style와 Work Assignment Style을 살펴 보자. Deployment Style은 Software Element가 어떤 물리적 장치에 탑재되는지 보여 준다. 시스템 동작 시, Deployment 내용이 변경 될 수 있으므로 할당은 동적일 수 있다. Work Assignment Style은 Module View의 내용 중 구현 책임이 있는 개인이나 그룹에 할당하는 것이다. 즉, 구조와 작업하는 개발 그룹간의 관계를 보여 주는 모습이라고 할 수 있다.

4+1 View

Logical View
Process View
Development View
Physical View
+Use Cases/Scenarios

유스케이스 뷰

(Usecase View)
다른 뷰를 검증하는데 사용
사용자, 설계자, 개발자, 테스트 관점
유스케이스 다이어그램

논리 뷰
(Logical View)
시스템 기능 적인 요구사항이 어떻게 제공되는지
클래스나 컴포넌트의 종류와 관계를 설명하고 설계가 실제로 구현 되는지 설명
설계자 관점 (순서도나 UML 그리는 시점)
클래스/시퀀스 다이어그램

프로세스 뷰
(Process View)
시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
성능, 확장성, 효율성 관련
시스템 통합자의 관점
시퀀스/협력 다이어그램

Development 뷰
개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의
실제 구현할 수 있는지 여부를 확인
직접 만드는 개발자의 관점
컴포넌트 다이어그램

Physical 뷰
컴포넌트가 물리적 환경에서 배치 연결 작업이 어떻게 실행 되는지를 매핑해서 보여주는 뷰
배치(배포) 다이어그램

Context View 무엇인가요?

시스템과 환경사이의 상호작용과 의존성 관계를 표현한다

DFD - Data Flow Diagram 무엇인가요?

특정 기능을 나타냅니다. 레벨 0 DFD에서는 전체 대상 시스템을 나타냅니다
공통 터미널 - .사용자, 외부 시스템, 하드웨어 장치
데이터 저장소
데이터 흐름 정의

DFD의 터미널에 유스케이스 액터가 안되는 경우가 있는지

DFD에서 터미널이란 입력 정보를 주는 주체, 인풋 아웃풋
usecase에서 엑터는 특정 기능을 인보크하는 주체 또는 인보크를 당하는 주체
= 터미널에 있었다고 해서 전부 액터로 쓸필요는 없다

Functional Viewpoints

시스템의 기능을 정의

Functional Characteristics를 관찰
Skeleton Architecture로부터 UseCase Diagram을 정제
Functional Components를 도출
- 유즈케이스를 Functional Components 단위로 할당
- Functional Components 테이블 도출.
Tier로 Functional Components를 할당하기 위하여 정제
Tier별로 Functional Components를 할당

각각의 Functional Components를 디테일하게 디자인
Criterion 1. Visibility of Functional Component
Whitebox Component or Blackbox Component

Criterion 2. Type of Interface (for Blackbox Components)
Façade-type or Mediator-type

facade-type

각각의 객체들을 숨긴 Representative API set
API에 50개의 기능이 있을 때, 다 사용 위해서는 50개의 request가 필요하다.
Component의 Method 수가 많다.
Workflow가 가변적이다.

mediator type

각각의 객체들을 숨긴 Representative API set + Workflow automation 제공
Workflow는 재사용 가능하며, 자동적이다. (공통)
API에 50개의 기능이 있을 때, 한 번의 요청으로 사용 가능
상대적으로 적은 Method 수

Criterion 3. Variability of Functional Component
Closed Component or Open Component

Criterion 4. Variation Points (for Open Component)
Variation point where the variability occurs.
Functional Component의 인터페이스 정의
provided interface, required interface 정의

Information Viewpoints

Architecture design for Information View is to make decisions about persistent datasets, properties and their management. This activity includes a number of tasks including identifying data components, allocating data components, defining their data contents, ownership, data distribution, replication, migration, data security, and data timeliness.

타겟 시스템의 Informational Characteristics 을 관찰
Skeleton Architecture로부터 Persistent Object Model 을 정제
Data Components 를 도출
클래스간의 상호 작용이 강한 경우, data component의 그룹으로 도출.
Tier로 Data Components를 할당하기 위하여 정제
Data Components 를 tier에 할당.
Design Data Components
Data Component의 내부 상세를 디자인한다. persistent attribute 정의.
Data Components의 인터페이스 정의
각각의 Data Component의 인터페이스를 정의. 대부분 CRUD가 됨.

Behavioral Viewpoints

아키텍처의 Behavioral View는 시스템의 런타임 동작에 초점을 맞춘 시스템의 동적 측면을 설명한다.

Behavioral Characteristics 관찰
Explicit Invocation, Event-driven, Parallel Processing, Closed-loop control flow, time based invocation, etc...
전체 시스템에 대한 Control Flow 를 정제
상세한 Control Flow를 정의

Deployment Viewpoints

아키텍처의 Deployment View는 물리적 계층의 소프트웨어 구성 요소 토폴로지와 이러한 구성 요소 간의 물리적 연결에 관한 것입니다.

Deployment Characteristics 관찰
Nodes 정의
Network Connectivity 정의
티어간의 http, https 등
배포할 Artifacts 정의
노드별로 Artifacts를 할당
Deployment Diagram 활용

7. Skeleton / Core Architecture

Owl Life — Sun, 4 Dec 2022 17:53:39 +0900

Architect란?

Architect : 한정된 자원 내에서 기능 및 품질 요구사항을 최대한 끌어올릴수 있도록 균형을 맞추는 사람, Concern을 잘 포착하고 이것을 설계에 반영함
통찰력, 추상화, 설득력 필요

Architecture Style Pattern 적용 효과

안정성, 의사소통, 생산성, 재사용, 접근성
디자인 패턴에서는 솔루션이 들어가야한다.
아키텍쳐스타일에선 유형이 들어가야한다.

Architecture 설득 방법.

ATAM, Trade off, Risk 등을 분석 설득, 판단의 근거를 Tracebility하게 남겨두어야 근거로 쓸 수 있다.
Architecture: Definition

Architecture Style & Pattern 차이?

Architecture Description의 세 가지는?

Skeleton Architecture - Architecture Styles
Design for NFRs - Architecture Tactics for NFRs
Design for Views - Architecture Viewpoints

Skeleton Architecture Design

A skeleton architecture is a description of the structural aspect of the target system without fully describing the key components and their properties. It can be effectively derived by applying architectural style(s). Each architectural style is a named collection of architectural decisions that are applicable in a given development context.

How to evaluate the Applicability of Architect Styles?

Situation, 장점, 단점

어떤 상황에서 쓰여질 수 있는지를 명시합니다. 그리고 각각에 대하여 장점과 단점을 나열합니다.

그 후에 적용하기에 적합한지를 판단합니다.

How to Derive(도출하는가?) Skeleton Architecture from Styles?

Instantiating each selected Style, Merging Styles

선택된 스타일들을 하나씩 그려가면서 합칩니다.

Defining Interfactions among Components in the Architecture

Q) Why we do define Interactions among components?

Interaction Path를 정의한다. Interaction Path는 casual dependency 나 persistent relationship 일 수 있다.

함수 호출하는 Path를 제공하거나 컴포넌트들간의 통신을 위한 메시지를 보냅니다.

Skeleton Architecture Design, Step 말하세요.

요구사항 정제 (incompleteness, ambiguity, etc)

정제된 SRS 산출물 생성

시스템 컨텍스트 분석

- 시스템 바운더리 컨텍스트

- 기능적 컨텍스트

- 정보 컨텍스트

- 행위 컨텍스트

스켈레톤 아키텍트 디자인

- 아키텍트 특징 관찰

- 아키텍트 스타일 후보 선정 및 각각의 장,단점 명시

- 아키텍트 스타일 통합

아키텍처 스타일 통합 순서

1. Tiers 관련된 스타일
- Tier-based Architecture Styles
- Client Server architecture style
- N-tier architecture style
- Peer-to-Peer architecture style
- Load-balancing Architecture Styles
- Broker architecture style
- Dispatcher architecture style
- Master Slave architecture style•
- Edge-based architecture style

2. 서비스 관련 스타일
- Microservice architecture style
- Service-Oriented Architecture (SOA) style

3 레이어드 스타일
- Layered architecture Style
- MVC architecture style

4. 행동 스타일
- Batch Sequential architecture style
- Pipe-n-Filter architecture style
- Event-Driven architecture style
- Publish-and-Subscriber architecture style

5. 가변성 있는 스타일
- Micro Kernel architecture style
- Microservice architecture style
- Blackboard architecture style
Component간의 Interactions

6. Software Architecture Styles

Owl Life — Sun, 4 Dec 2022 17:51:04 +0900

각 스타일별 주요 포인트

언제 사용하는가? 컴포넌트와 연결자는 어떻게 되는가? 장단점은?

Batch Sequential

타겟 시스템의 기능이 dataset를 조작하기 위하여 독립적인 구성 요소로 decompose 된다.

구성 요소는 일련의 데이터 변환을 순차적 및 배치 방식으로 수행합니다.

사용자는 모든 배치 처리가 완료 되기전까지 interact 할 수 없고, 끝날때까지 기다려야 합니다.

대용량 처리에 용이. 각 서브 시스템을 독립적으로 처리하는 프로그램이 될 수 있음.

Pipe and Filter

필터는 데이터 세트를 조작하는 구성 요소를 나타내고,

파이프는 데이터 세트를 필터 간에 스트림 모드로 전송하는 데이터 버스를 나타낸다.

이는 Batch Sequential Architecture Style로 한 번에 전체 데이터 세트를 전송하는 것과 대조된다.

Benefits

Concurrency: It provides high overall throughput for excessive data processing.
Reusability: Encapsulation of filters makes it easy to plug and play, and to substitute.
Modifiability: It feature low coupling between filters, less impact, from adding new filters and modifying the implementation of any existing filters as long as the I/O interfaces are unchanged.
Simplicity: It offers clear division between any two filters connected by a pipe.
Flexibility: It supports both sequential and parallel execution.

Drawbacks

It is not suitable for dynamic interactions.
A low common denominator is required for data transmission in the ASCIII formats since filters may need to handle data streams in different formats, such as record type or XML type rather than character type.
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters.
It can be difficult to configure a pipe and filter system dynamically.

Layered

‘관심사에 분리(Separation of concerns)’에 따라 시스템을 유사한 책임(관심)을 지닌 Layer로 분해하고

각각의 Layer가 하위 Layer에만 의존하도록 구성하는 아키텍처 패턴 (Organized Vertically)

각 레이어는 인터페이스를 가진 가상 머신. 가상 머신은 엄격한 순서 관계에 따라 상호작용.

각 계층에는 시스템에서 고유한 역할이 부여되며, 바로 아래 계층에서 제공하는 서비스를 호출한다.

하위 레이어는 상위 레이어 사용 불가.

가상 머신

레이어의 목적은 가상 머신의 제공
이식성(portability) 향상이 목적.

장점

전체적인 시스템의 결합도를 낮추고,

개발자의 인지 과부하를 방지하며,

재사용성을 높이고 유지보수성을 향상.

프로젝트 도메인이 복잡하 논리를 포함하지 않거나,

확장성보다는 일관성을 가져가는 것이 목표이거나,

소규모로 구성된 팀인 경우에는 적용하기 좋다고 생각.

단점

프로젝트 규모가 커질수록, 확장성이 떨어짐.

레이어로 분리된 관심사 외에 다른 관심사가 발견된 경우, 패키지 분리 및 코드 배치가 난감한 경우가 발생.

복잡한 비즈니스 논리를 해결하고 성능적 이점을 얻기는 어려움.

MVC

GUI가 있는 시스템을 모델, 뷰, 컨트롤러의 세개의 컴포넌트로 구분하는 아키텍처.

유저 인터페이스와 비즈니스 로직들을 서로 분리하여 개발하는 방법

MVC 모델 작동 순서

Controller로 사용자의 입력이 들어옴
Controller로 Model에 데이터를 업데이트
Model은 해당 데이터로 보여줄 View를 업데이트하여 화면에 보여 주게 됨

장점

Separation of Concern 달성 (재사용성, 유지 보수성)
동일한 모델로부터 다양한 View들을 표현할 수 있음
View의 추가, 변경, 삭제가 자유로움. model과 decouple 되어 있으므로.
View들의 동기화
모델의 변경전파 메커니즘에 의하여 데이터 변경사항 통지.
뷰와 모델에 영향을 끼치지 않고 워크플로우를 수정하는게 수월함.
Persistent 데이터 스토어가 view, control에 영향을 미치지 않음.

단점

간단한 애플리케이션에 적용하기에는 복잡성만 증가.
View와 Controller는 밀접히 관련되어 있음.
View와 Controller는 모델에 의존.
모델의 인터페이스를 변경하면 View와 Controller도 변경 되어야 함.

Blackboard

Shared data, database와 같은 데이터 중심 패턴 중에 하나
명확히 정의된 문제 해법이 없을 때 문제를 풀어가는 하나의 방식을 정의한 패턴
대략적으로 해법을 수립하기 위해 특수한 서비스 시스템의 지식을 조합하는 패턴

그 다음 단계의 결과가 실행할때마다 다르게 나올 수 있는 알고리즘을 구현하는데 사용되는 스타일

ex) 음성인식, 차량식별, 신호해석

블랙보드(blackboard) : 솔루션의 객체를 포함하는 구조화된 전역 메모리
지식 소스(knowledge source): 자체 표현을 가진 특수 모듈
제어 컴포넌트 (control component) : 모듈 선택, 설정 및 실행을 담당
KS는 타 문제 도메인에 재사용될 수 있음
계산 결과가 항상 동일하지 않아 테스트가 어려움
어떤 좋은 해법도 완벽하다고 장담할 수 없음

Shared Repository

공유 데이터는 central data repo에 저장됨. 이 repo는 여기에 관련된 모든 client app에 의해서 접근이 가능.

Client app들은 데이터를 읽고 쓰기 위하여 pulling을 사용

장점

Efficient way of sharing datasets among applications
Efficient way of storing a large amount of datasets
Separating data storage concern from data manupulation concern
Allowing concurrent accesses to the datasets.

단점

Difficulty to manage the data scheme of the repository
Potential performance overhead due to the remote access
Concern on Availability
Concern on Security

Micro Kernel

시스템의 요구사항이 변할때, 이를 쉽게 시스템에 반영하기 위한 패턴

일반적인 시스템의 기능에서 최소 핵심 기능은 공통으로 두고 변경이 가능한 확장 부분을 플러그인 방식으로 추가할 수 있는 패턴.

장점

이식성이 보장 (시스템을 새로운 환경으로 이동 시, Microkernel만 수정하면 됨)
유연성과 교환가능성이 확보 (Internal/External Server를 수정하거나 확장)
유지보수성과 가변성을 향상 (정책과 메커니즘을 분리)
확장성 확보, 신뢰성 지원, 투명성을 제공

단점

시스템 설계가 복잡하고 개발이 어려움.
성능이 떨어짐. internal server와 external server에 대한 호출로 인하여, 하나의 애플리케이션에서 훨씬 많은 프로세스 간 통신이 필요함.

Micro Service

대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합된 모듈로 분해하여 서비스를 제공하는 아키텍처

도메인은 공통 REST 기반 웹 인터페이스 서비스를 독립적으로 배포할 수 있습니다

장점

확장성, 탄력성, 진화성
복잡한 애플리케이션의 지속적 배포, 배치가 가능
상대적으로 작아서 이해하기 쉽고 생산적일 수 있음
오류의 고립(Fault Isolation)을 도움
ex) 메모리 릭이 있다면, 해당 서비스만 진행을 멈추고 다른 서비스는 지속 운영 가능.
새로운 기술을 도입, 적용하기가 용이

단점

성능, 단순성, 비용
개발자는 분산 시스템에서 나오는 추가적인 문제들을 다루어야 함.
여러 서비스를 배치 하는것이 좀 더 복잡해 짐.
메모리 사용량이 증가. (예를 들어 각 서비스가 각자 VM을 사용하는 경우)

Dispatcher

Client에게 QoS가 높은 서버를 연결하기 위하여 중간에 속해 있는 서버.

QoS가 높은 서버 정보를 클라이언트에 넘겨주면, Client가 직접 서버에 연결됨.

Broker보다 성능이 좋음.

Broker

서로 다른 기종의 머신에 분산되어 있는 서비스(객체 혹은 컴포넌트)간에 어떻게 협력을 잘 할지 고민하다 나온 패턴.

분산 시스템이나 RPC를 구현할 때 많이 사용됨.

브로커가 해야 할일은 server locating, request를 포워딩, 결과와 예외처리를 클라이언트 측에 전달하는 것.

언제 사용?

실제 시스템 컴포넌트를 사용하는 사용자로부터, 서비스의 구체적인 구현을 감추어야 할때(캡슐화)
런타임에, 시스템 컴포넌트들을 교체 할 수 있습니다.
시스템 컴포넌트가 어디에 위치해있던지 신경쓰지 않고 호출 가능합니다.

명령어 예

0x5001|semtax|22

0x5001은 어떠한 방법으로 요청을 처리하라는 일종의 커맨드이고, 나머지 부분이 데이터의 역할을 하게 됨.
Broker에서는 이 명령어를 파싱하여 서버에 요청 및 응답을 받아서 다시 리턴.

Client Server

서버 티어는 클라이어트 티어를 위한 공통 서비스를 제공. 클라이언트 티어는 사용자와 소통.

복수개의 클라이언트 앱은 서버 티어의 기능을 공유 할 수 있음.

장점

responsbility 분리, 서버 components 재사용

단점

이기종 인프라에 대해 요구 만족 어려움, 보안취약,
server availability and reliability, testability and scalability 어려움

Publish and Subscribe

이벤트 기반의 아키텍트 스타일.

Subscriber들은 특정 이벤트를 받기 위하여 등록/해제

Publisher들은 매시지를 브로드캐스팅. (동기/비동기 형태로)

옵저버 패턴과 유사.

언제 사용?

There is a need for decoupling content producers from content consumers.

There is a need to deliver the same content to multiple consumers.

There is a need to deliver the content when it is available.

There is a need to avoid polling for the content.

장점

Flexibility to add new subscribers dynamically.
Loose coupling between publisher and subscribers
Increased Efficiency due to Reduced Polling / Pulling

단점

Overhead of Distributing Events
With broker, publishers have no control on the delivery ordering

5. Requirement Engineering

Owl Life — Sun, 4 Dec 2022 17:50:12 +0900

Definition of SW Quality

주어진 요구사항을 만족시킬 수 있는 소프트웨어의 기능 및 특성.

Conventional NFRs in ISO 9126

Types of Quality Aspects

Process Quality

Quality of Life-cycle Process

Internal Quality

Quality of Intermediate Artifacts

External Quality

Quality of Implementation Code

Quality in Use

소프트웨어가 동작하는 환경에서의 사용자 관점에서의 퀄리티
ex) 실행 속도 등

소프트웨어 실행하면서 발생되는 결과로부터 평가

Quality Model of ISO 9126

6 Main Factors(FRUMPE) and Sub-Factors for each

Quality Model은 크게 External, Internal Quality로 나뉠 수 있음.

Functionality

기능 적합성. 소프트웨어가 사용자의 요구기능을 충족 시키는가? 목적했던 기능이 정확히 동작하는가?

Reliability

기능이 오차나 오류 없이 동작하는가? 일관된 결과가 도출되는가?

Maturity (성숙성)
소프트웨어의 결함으로 인한 실패를 방지하는 소프트웨어 제품의 기능.
Fault Tolerance (결함 허용성)
소프트웨어 결함 또는 지정된 인터페이스 침해의 경우에 특정 수준의 성능을 유지하는 소프트웨어 제품의 기능.
Recoverability (복구성)
소프트웨어 제품이 지정된 수준의 성능을 재설정하고 장애 발생 시 직접 영향을 받는 데이터를 복구하는 기능
Reliability Compliance (신뢰성 준수)
신뢰성과 관련된 표준, 규약 또는 규정을 준수하는 소프트웨어 제품의 능력

Usability

쉽게 배우고 사용할 수 있는가?

Efficiency

기능을 수행하는데 적절한 자원이 소요되는가? 기능이 필요한만큼 빠르게 수해오디는가?

Maintainability

변경 및 오류 교정 시 쉽게 수정할 수 있는가?

Portability

다양한 플랫폼 및 하드웨어에서도 동작하는가?

Process of Requirement Engineering (REP)

요구사항을 정의, 문서화 및 유지 관리하는 프로세스. 시스템에서 제공하는 서비스를 모으고 정의하는 과정.

주요 과정

요구사항 추출
요구사항 모델링과 분석
요구사항 우선순위화
요구 명세
품질 요구
요구 검증과 변경 관리

요구사항 추출

프로젝트 도메인 및 요구 사항에 대한 지식을 얻는 데 사용되는 다양한 방법과 관련이 있음.

사용되는 기술에는 인터뷰, 브레인스토밍, 작업 분석, 프로토타이핑 등이 포함되어 있음.

이 단계는 이해된 요구사항의 공식 모델을 생성하지 않음. 대신 분석가의 도메인 지식을 넓히고 다음 단계에 입력을 제공하는데 도움이 됨.

요구사항 모델링과 분석

공식적인 소프트웨어 요구 사항 모델을 생성하는데 사용. 추상적 요구사항을 정확하고 상세하게 정의.

시스템 기능, 성능 및 인터페이스 등을 정의. 고객의 needs가 충족됨을 확인

이 단계에서 사용되는 모델로는 Enterprise Modeling, Data Modeling(DFD), Behavioural Modeling, Domain Modeling, NFR Modeling 등이 있다.

요구사항 우선순위화

고객의 Needs와 요구사항 사이의 match가 성공을 결정.

단계

Define Priority classes
High / Medium / Low // 1~10 score
Assess Priority Data
모든 참여자가 Priority Scale에 따라 분류
Resolve Differences
우선순위에 대한 Informal Agreement 확보
Create schedules based on priorities
각 요구사항의 작업 시작과 종료 시점

요구 명세

요구문서는 완전하고, 일관성이 있어야 한다.

명세는 모든 필요로 하는 요소를 포함하고 있어야 한다.

명세에 포함된 요소들 간에는 모순이나 충돌이 없어야 한다.

품질 요구

품질 속성은 기능, 비기능 관점을 모두 포함.

"Quality Model of ISO 9126" 참고

품질 속성 시나리오 활용. (Source, Stimulus, Artifacts, Environment, Response, Response Measure)

요구검증과 변경관리

변경을 이해하고, 관리하라.

요구사항 관리를 위한 커뮤니케이션을 제공.

요구사항 변경으로 개발에 대한 영향을 최소화.

Agile하게 고객의 Needs 변화를 요구사항 변경으로 반영

Agile Constructs for Requirement Management

요구사항 변경은 필연적임.

→ 개발 초기에 고객은 원하는 요구사항을 정확히 표현하지 못함.

그러므로 변경을 이해하고, 관리하라.

Agile하게 고객의 Needs 변화를 요구사항 변경으로 반영

Requirements for Platform Software

Q) How do you define / refine requirements for Platform Software?

비기능이기 때문에 Non Functional Requirements에 명세합니다.

Non-Functional Requirements (NFRs)

소프트웨어 기능들에 대한 조건(시스템의 속성)과 제약사항에 관한 요구사항

기능적 요구사항보다 더 결정적인 부분이 될 수 있다.
why? 이부분이 충족되지 않으면 시스템 이용가치 X

각각의 특징과 서비스보다는 전체적인 시스템에 적용

비기능적 요구사항
제품 요구사항 (Product Requirement)	사용성(Usability) : 사용자가 어떻게 쉽게 사용할 수 있는가
	효율성(Efficiency)	성능(Performance) : 특정 기능이 특정시간 내에 실행
		공간 (Space) : 특정 기능 수행시 메모리를 최대 얼마까지 사용할 수 있는가
	신뢰성(Reliableility) : 특정 기능 실행시 실패할 가능성이 몇 %보다 낮아야 하는가
	이식성 (Portability) : 다양한 플랫폼 위에서 작동하는가
조직 요구사항 (Organizational Requirement)	배포(Delivery) : 소프트 웨어를 어떻게 배포할 것인가
	구현(Implement) : 소프트웨어 구현 ; 어떤 방법론? 어떤 프로그래밍 언어?
	표준(Standard) : 소프트웨어 개발 시 어떤 표준을 따를 것인가
외부 요구사항 (External Requirement)	상호 운용성 (Interoperability) 구현할 소프트웨어가 다른 소프트웨어와 어떻게 연동할지 정의
	윤리적 (Ethical) : 소프트 웨어의 내용의 윤리적 범위을 정의 ex) 성인용 게임 19세 이상
	법적 (Legislative)	사생활(privacy) ex) 공개범위 선택
		안전성(safety) ex) 자료 저장방식, DBMS 어떤것? 자료의 암호화 여부

GOF - Software Design Pattern

Owl Life — Sun, 4 Dec 2022 13:24:36 +0900

왜 디자인 패턴을 사용하나?

재사용 가능하고, 유연한 구조를 가지는 소프트웨어 개발
커뮤니케이션 : 구체적인 설명 없이 구조화된 패턴에 대한 사전 지식으로 커뮤니케이션에 드는 비용, 비용 절약.
설계 과정의 속도를 높일 수 있음. 이미 검증되고 테스트된 구조이기 때문.
구현이 아닌 인터페이스에 맞춰서 프로그래밍
바뀌는 부분은 따로 뽑아서 캡슐화.
상속 보다는 구성을 활용. → 구성을 활용하면 유연성을 크게 향상 시킴.

Principles of Design Patterns

Interface Separated from implementation
Substitution with various implementation
Open Closed Principle (OCP)

Classification of Design Patterns

Creation Patterns

객체 생성에 관련된 패턴. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.

Structure Patterns

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

Behavioral Patterns

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.

생성 패턴

Factory Method : 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대해서는 하위

클래스에서 결정 -> 클래스의 상속 이용, 인터페이스의 다형성

Abstract Factory : 구체적 클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터

페이스 제공

Builder : 데이터의 순서에 상관없이 객체 생성 가능. setter 메서드가 없으므로 변경 불가능한 객체 생성 가능. 한번에 객체

를 생성하므로 객체 일관성이 깨지지 않음.

Prototype : 객체를 생성하는데 비용이 들고, 이미 유사한 객체가 존재하는 경우에 사용. Client에 Map 형태로 생성될 객체

를 등록해놓고, 타입에 따라 객체를 clone 하는 형태로 객체 생성. ex) DB로부터 읽어온 객체 등록 후 복사.

Singleton : 클래스에서 만들 수 있는 인스턴스가 오직 하나일 경우. 어디에서 접근 하든지 하나로만 통일하여 제공.

구조 패턴

Adapter : 클래스의 인터페이스를 클라이언트가 기대하는 형태의 인터페이스로 변환. 기존의 클래스를 사용해야 하나 인터페이스가 수정되어야 하는 경우에 사용. adapter 클래스의 멤버로 타겟 클래스를 가짐. (has a) Adaptee 클래스의 하위 클래스기 때문에 곧바로 Adaptee의 멤버 함수들을 override 할 수 있다.

Bridge : 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고 확장이 가능하도록 합니다. 즉 기능과 구현에 대

해서 두 개를 별도의 클래스로 구현을 합니다. 런타임 시 구현 방법을 선택하거나 구현 내용을 변경하고 싶은 경우 사용.

Composite : 부분과 전체의 계층을 표현하기 위해 복합 객체를 트리 구조로 만드는 패턴. 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 전체-부분 관계로 정의. Directory-File 존재. SRP를 깨는 대신 투명성을 확보하는 패턴. 투명성(transparency)란 Component 인터페이스에 자식들을 관리하는 기능과 leaf으로써의 기능을 전부 넣어서 클라이언트가 복합 객체와 잎을 똑같은 방식으로 처리할 수 있도록 만들 수 있다.

Decorator : 객체에 동적으로 새로운 서비스를 추가 할 수 있게 한다. 기능의 추가를 위해서 하위 클래스를 생성하는것보다 융통성 있는 방법을 제공. (상속보다 위임을 통하여 제공)

Flyweight : 어떤 클래스의 인스턴스 한개만 가지고 여러 개의 "가상 인스턴스"를 제공하고 싶을때 사용하는 패턴. 즉 인스

턴스를 가능한 대로 공유시켜 쓸데없는 new 연산자를 통한 메모리 낭비를 줄이는 방식. 대규모의 미세한 객체들을 효과적

으로 사용하기 위해서 공유 개념 도입.

Facade : 복잡한 서브시스템에 대한 단순한 인터페이스 제공이 필요할때. 클라이언트와 구현 클래스 간에 너무 많은 종속

성이 존재하여 클라이언트와 다른 서브 시스템 간의 결합도를 낮추고 싶을 때.

Proxy : 프록시에게 일을 대신 시킴. 어떤 객체 사용할때, 직접 참조하는것이 아닌 해당 객체를 대항하는 객체를 통해 대상

객체에 접근하는 방식을 사용하면 해당 객체가 메모리에 존재하지 않아도 기본적인 정보를 참조하거나 설정할 수 있고, 실

제 객체의 기능이 필요한 시점까지 객체의 생성을 미룰 수 있음. 사이즈가 큰 객체가 로딩되기전에 프록시를 통해 참조 가

능. 객체 생서이 한단계 거치게 되므로 빈번한 객체 생성시에 성능 저하.

행위 패턴

Template Method : 알고리즘의 변하지 않는 부분을 한 번 정의하고 다양해질 수 있는 부분을 하위 클래스에서 정의할 수 있

도록 구현하고자 할 때. 훅을 사용하여 하위 클래스 확장을 제어 가능. 코드 재사용을 위한 기본 기술.

Strategy : 다양한 알고리즘이 존재하면 이들 각각을 하나의 클래스로 캡슐화하여 알고리즘의 대체가 가능하도록 함. 행위

들이 조금씩 다를 뿐 개념적으로 관련된 많은 클래스들이 존재하는 경우.

State : 객체 내부의 상태에 따라 행위를 변경하도록 함.상태에 따른 행위를 국지화하여 서로 다른 상태에 대한 행위를 별도

의 객체로 관리함. 상태 전이 규칙을 명확하게 만듬. 상태 객체는 공유 될 수 있음.

Command : 요청 자체를 객체화 하는것. 서로 다른 요청을 객체화하여 클라이언트에게 파라미터로 넘겨 줄 수 있게 한다.

Chain of Responsibility : 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴. 메시지를

수신하여 처리를 담당하는 객체들을 하나의 연결 고리로 만들고 실제로 요청을 처리하는 객체를 만날 때까지 계속 요청을

전달. 메시지를 받을 객체를 명시하지 않은 채 여러 객체 중 하나에게 처리를 요청하고 싶을때 사용.

Memento : 캡슐화를 위배하지 않으면서 객체의 내부 상태를 파악하고 표현함으로써 객체의 상태를 저장해 둔 상태로 다시

복귀할 수 있게 함. 각 시점에서의 객체 상태를 저장한 후 나중에 이 상태로 복구해야 할 때 활용.

Observer : 일대다의 관련성을 갖는 객체들의 경우 한 객체의 상태가 변하면 다른 모든 객체에 그 사항을 알리고 필요한 수

정이 자동으로 이루어지도록 할 때. 프로그래머는 얼마나 많은 객체들이 변경되어야 하는지 몰라도 됨.

Iterator : 복합 객체 요소들의 내부 표현 방식을 공개하지 않고도 순차적으로 접근할 수 있는 방법을 제공. (구현과 순회 분

리)

Visitor : 데이터 구조와 처리를 분리. 데이터 구조 안을 돌아다니는 주체인 방문자를 나타내는 클래스를 준비해서 처리를

맡긴다. 새로운 처리를 추가하고 싶을 땐 새로운 방문자를 만들고 데이터 구조는 방문자를 받아들이면 됨. OCP적용. 새로

운 concreteelement 클래스 추가하기는 어려움.

Mediator :클래스 간의 복잡한 관계를 캡슐화하여 하나의 클래스에서 관리하도록 처리하는 패턴. M:N 관계를 M:1 관계로

만들어 복잡도를 내리므로 유지 보수 및 확장성에 유리.

Interpretor : 간단한 언어의 문법을 정의하고 싶을 때

Facade 패턴과 Mediator 패턴

Mediator의 역할은 Colleague 역할의 중재자로서 주고받기를 수행함 -> 양방향
Facade 역할은 일방적으로 다른 역할을 이용해서 높은 레벨의 인터페이스(API)를 만듦 -> 단방향
퍼사드가 자신의 정책을 가시적이고 강제적으로 적용하는 반면, 미디에이터는 자신의 정책을 은밀하고 강제적이지 않은 방식으로 적용한다.
퍼사드 패턴은 클래스 라이브러리와 같은 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 Unified Interface를 제공하며, 퍼사드는 그러한 인터페이스를 제공하는 객체다.
미디에이터 패턴은 객체들의 집합이 상호작용하는 방법을 함축해놓은 객체를 정의한다. 객체 간 통신은 미디에이터 객체 안에 함축된다. 객체들은 서로 직접 통신하지 않으며, 미디에이터를 통해 통신한다. 이를 통해 객체 간 의존성을 줄여 결합도를 감소시킬 수 있다.

Observer 패턴과 Mediator 패턴

옵저버 패턴은 1개의 publisher에 대해 N개의 subscriber가 존재. 옵저버는 pulling이나 push 방식을 통해 관리.
중재자 패턴은 M개의 publisher와 N개의 subscriber 사이에서 1개의 중재자를 통해 통신하는 방식.

Prototype 패턴과 Flyweight 패턴

Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

Strategy Pattern

알고리즘을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. Strategy를 활용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

특징

관련 알고리즘의 군을 형성함
서브클래싱을 사용하지 않른 방법.
사용자는 서로 다른 전략을 알고 있어야 함
Strategy와 Context 클래스 사이에 과다한 메시지가 전송됨
객체 수가 증가

Observer Pattern

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one to many) 의존성을 정의.

일반적으로, Subject 인터페이스와 Observer 인터페이스가 들어있는 클래스 디자인을 바탕으로 구현.

Subject와 Observer가 Loose coupling 되어 있는 개체 디자인을 제공

데이터 가져오는 방식

pulling : 루프를 돌면서 계속 호출

pushing : 등록하면, 변경되었을때 통지

observe : 항상 필요X, 선택적으로 필요, notification만 전달받고, data는 전달받지 않음.

특징

Subject가 Observer에 대하여 아는것은 Observer가 특정 인터페이스를 구현한다는 것뿐.
Observer는 언제든지 새로 추가 가능.
새로운 형식의 Observer를 추가하려고 할 때도 Subject를 전혀 변경 할 필요가 없음.
Subject, Observer 는 서로 독립적으로 재사용 가능. 서로 영향을 미치지 않음.

서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.

Decorator Pattern

객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장 할 수 있는 방법을 제공.

예) 카페에서 음료 제조시, 첨가물을 데코로 표현.

Open Closed Principle

"클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다."

Class Diagram

특징

기존 코드는 건드리지 않은 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있음
이 목표를 달성했을 때 새로운 기능을 추가하는데 있어서 매우 유연해서 새로 급변하는 주변 환경에 잘 적응할 수 있으면서도 강하고 튼튼한 디자인을 만들 수 있음.
데코레이터의 슈퍼 클래스는 자신이 장식하고 있는 객체의 슈퍼클래스와 같음.
한 객체를 여러 개의 데코레이터로 감쌀 수 있음.
데코레이터는 자신이 감싸고 있는 객체와 같은 슈퍼클래스를 가지고 있기 때문에 원래 객체가 들어갈 자리에 데코레이터 객체를 집어넣어도 상관없음.
데코레이터는 자신이 장식하고 있는 객체에게 어떤 행동을 위임(Delegate)하는 것 외에 원하는 추가적인 작업을 수행할 수 있음. – 키 포인트
객체는 언제든지 감쌀 수 있기 때문에 실행 중에 필요한 데코레이터를 마음대로 적용할 수 있음.

데코레이터를 사용하는 목적은 컴파잉리할 때 모든 서비스의 객체를 다 결정할 수 없는 상황에서 적절하게 대응하기 위해서임.

Factory method pattern

모든 팩토리 패턴에서는 객체 생성을 캡슐화.

팩토리 메소드 패턴에서는 서브클래스에서 어떤 클래스를 만들지를 결정함으로써 객체 생성을 캡슐화.

예제 ) 피자 가게에서 피자 생성

Dependency Inversion Principle

추상화된 것(Abstract or Interface)에 의존하도록 만들어라. Concrete Class에 의존하지 않도록 한다.

Class Diagram

특징

어떤 변수에도 구상 클래스에 대한 레퍼런스를 저장하지 말 것.
클라이언트에서 New 연산자를 사용하면 구상 클래스에 대한 레퍼런스를 사용하게 되는 것.
이 패턴을 사용하여 구상 클래스에 대한 레퍼런스를 변수에 저장하는 일을 미리 방지.
"New" 연산자를 캡슐화

Abstract Factory Method Pattern

추상 팩토리 패턴에서는 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성 가능.

Class Diagram

Factory Method vs Abstract Factory Method

공통 : 둘다 객체 생성 패턴. 객체 생성을 캡슐화해서 Client와의 결합을 느슨하게 하고, 특정 구현에 덜 의존하도록 만듬.
차이점 : Factory Method는 상속을 통해서 객체를 생성. Abstract Factory Method는 객체 구성(Composition)을 통해 생성.
팩토리 메서드 패턴을 통해 객체 생성시에는 클래스를 확장하고 팩토리 메서드를 오버라이딩 해야 함.
팩토리 메서드 패턴을 사용한다는것은 서브 클래스를 통해서 객체를 만들기 위한 것. 클라이언트에서는 자신이 사용할 추상 형식만 알면 되고, 구상 형식은 서브클래스에서 처리해 줌. 즉, 클라이언트와 구상 형식을 분리해주는 역할

Singleton Pattern

해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접근할 수 있도록 하기 위한 패턴.

Double Checked Locking 에서 volatile 키워드 관련 알고 있을것.

특징

한 앱에 들어 있는 어떤 객체에서도 똑같은 자원을 활용할 수 있도록 함.
예) 쓰레드 풀, 연결 풀 등 자원 풀을 관리하는게 유용함.
단순 싱글턴 패턴 적용시 멀티 쓰레딩에 따른 문제가 발생할 수 있음. synchronized, volatile 등 사용 할 것

Command Pattern

어떤 작업을 요청한 쪽과 그 작업을 처리하는 쪽을 분리 시킬 수 있음. 커맨드 객체는 특정 객체에 대한 요청을 캡슐화 시켜줌.

Class Diagram

특징

오퍼레이션을 호출하는 객체와 오퍼레이션을 수행 방법을 구현하는 객체를 분리.
요구사항을 캡슐화.
Command 자체도 클래스로서 다른 객체와 같은 방식으로 조작되고 확장될 수 있음.
명령어를 조합해서 다른 명령어를 만들 수 있음. (Composite 패턴 활용)
새로운 명령어를 쉽게 추가 할 수 있음.

Adapter Pattern

한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있습니다.

클라이언트 : 타겟 인터페이스에 맞게 구현되어 있음.

어댑터 : 타겟 인터페이스를 구현하며, 여기에는 어댑티 클래스가 들어 있음.

클라이언트에서 어댑터 사용하는 방법

클라이언트에서 타겟 인터페이스를 사용하여 메소드를 호출함으로써 어댑터에 요청
어댑터에서는 어댑티 인터페이스를 사용하여 그 요청을 어댑티에 대한 (하나 이상의) 메소드 호출로 변환
클라이언트에서는 호출 결과를 받긴 하지만 중간에 어댑터가 껴 있는지는 전혀 알지 못함.

Class Diagram

Client는 Target 인터페이스를 구현한 Adaptee가 필요하다.
Adaptee는 Target인터페이스를 구현하지 않고 있다.
- Adaptee는 이미 개발이 완료되어 사용중이다.
- Adaptee를 변경하는 것이 적절하지 않은 상황이다.

특징

어댑티를 새로 바뀐 인터페이스로 감쌀 때는 composition을 사용합니다. 이런 접근법을 쓰면 어댑티의 어떤 서브 클래스에 대해서도 어댑터를 쓸 수 있다는 장점이 있음.

Façade Pattern

어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용 가능.

Class Diagram

Principle of Least Knowledge

정말 친한 친구와 얘기하라.

특징

서브시스템의 구성 요소를 보호 할 수 있다.
서브시스템과 클라이언트 코드 간의 결합도를 줄일 수 있다.
서브시스템 클래스를 사용하는 것을 완전히 막지는 않는다.

Template Method Pattern

알고리즘의 각 단계들을 정의하며, 그 중 한 개 이상의 단계가 서브클래스에 의해 제공되는 경우에 사용.

AbstractClass에서 알고리즘의 골격을 정하고, 서브클래스에서 특정 메서드를 구현.

Hook

알고리즘의 특정 부분이 선택적으로 적용된다는가 하는 경우에 사용.

Class Diagram

Hollywood Principle

먼저 연락하지 마세요. 저희가 연락 드리겠습니다.

이를 활용하면, 의존성 부패를 방지 할 수 있음.

Iterator Pattern

Collection 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있는 방법을 제공.

모든 항목에 일일이 접근하는 작업을 컬렉션 객체가 아닌 반복자 객체에서 맡게 된다. 이렇게 하면 집합체의 인터페이스 및 구현이 간단해질뿐 아니라, 집합체에서는 반복작업에서 손을 떼고 원래 자신이 할 일에만 전념할 수 있음.

Class Diagram

Single Responsibility Principle

클래스를 변경하는 목적은 단 하나여야 한다.

Composite Pattern

객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층구조로 만들 수 있음.

Class Diagram

특징

클라이언트에서 단일 객체와 복합 객체를 똑같은 방법으로 다룰 수 있음.
메뉴와 메뉴 항목을 같은 구조에 집어 넣어서 부분-전체 계증구조를 생성 할 수 있음. 컴포지트를 따르는 디자인을 사용하면 간단한 코드만 가지고도 똑 같은 작업을 전체 메뉴 구조에 대해서 반복해서 적용할 수 있음.
단일 책임 원칙을 깨면서 대신에 투명성을 확보
가장 큰 장점 : Client를 단순화시킬 수 있음

State Pattern

OCP, 위임, DIP
객체의 내부상태에 따라 스스로 행동을 변경할 수 있게끔 허가하는 패턴.
상태가 변할 때마다 서브클래스 중 하나의 인스턴스로 변경함.

장점으로는 한 State와 관계된 모든 동작들이 하나의 Object 안에 모두 모인다.
State 추가 시 다른 Object에 대한 수정 없이 하나의 Object만 추가되면 된다.
따라서 State에 따른 조건문 없이 관리가 가능하다.
단점으로는 State 수만큼 Object가 관리되어야 함으로 Object가 늘어나고,
State 안에 동작이 추가될 경우 모든 Object들에 대해서 추가되어야 해서 수정범위가 늘어나게 된다.

Proxy Pattern

어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자(Surrogate) 또는 Placeholder를 제공하는 패턴.

Proxy pattern의 활용되는 방식

Real subject가 필요한 경우에 생성될 수 있도록 컨트롤 하거나 생성되기 전까지 대리인 역할을 한다. Real subject가 생성되면 Client로부터의 요청사항을 Real subject로 전달한다.
Client와 Real subject가 서로 다른 주소체계에 있거나 Real subject가 생성하는데 오래걸리거나 비싸거나, Real subject에 접근하는 권한의 관리가 필요할 경우 활용된다.

- remote proxy : responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space –
- virtual proxy : may cache additional information about the real subject so that they can postpone accessing it –
- protection proxy : checks that the caller has the access permissions required to perform a request

원격 프록시 : 요청과 해당 인수를 인코딩하고 인코딩된 요청을 다른 주소 공간의 실제 주체에게 보내는 역할을 합니다.
- 가상 프록시 : 실제 주제에 대한 추가 정보를 캐시에 저장하여 액세스를 연기할 수 있습니다.
- 보호 프록시 : 호출자가 요청을 수행하는 데 필요한 액세스 권한이 있는지 확인합니다.

Visitor Pattern

객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴.
연산을 적용할 원소의 클래스를 변경하지 않고도(구조 변경 없이) 새로운 연산을 정의(새로운 기능 추가)할 수 있게 합니다. 다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않은 경우에 사용.
데이터 구조와 처리를 분리하자.
– 데이터 구조를 돌아다니는 “방문자”를 정의해서, 이 방문자가 “처리”를 담당하도록 하자.
– 새로운 처리를 추가하고 싶을 때는, 새로운 “방문자”를 만든다.

Mediator Pattern

중재자가 복잡하게 얽혀있는 객체들 간의 상호 통신을 중재시키고, 객체들 간의 상호 작용 로직을 Mediator에 집중시킴으로써 처리를 원할하게 한다.

중재자 패턴은
복잡한 M개의 객체 사이에 N개의 관계가 형성되어 있을 때
M개의 객체 사이에 중재자를 하나 넣어서
이를 M:1 관계로 바꿔준다.

주요 컴포넌트

Mediator

Colleague 역할들과의 통신을 조정하기 위한 인터페이스를 정하는 역할

ConcreteMediator

Mediator 구체 클래스.

Colleague

Mediator 역할과 통신을 할 인터페이스를 정함

ConcreteColleague

Colleague 구체 클래스.
ex) ColleagueButton, ColleagueTextField

Builder Pattern

Composition
복잡한 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴.

Bridge Pattern

구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴.
추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 사용. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할때 사용.

Chain of Responsibility Pattern

책임 떠넘기기 패턴.

어떤 요구가 발생했을 때 그 요구를 처리할 객체를 바로 결정할 수 없는 경우에는 다수의 객체를 사슬처럼 연결해 두고 객체의 사슬을 차례로 돌아다니면서 목적에 맞는 객체를 결 정하는 경우

요구하는 사람과 요구를 처리하는 사람을 느슨하게 연결

Client 는 맨 처음 사람에게만 요구를 한다
그 요구가 처리자들을 연결한 사슬을 돌아다니다가 적절한 처리자에 의해 처리된다
이 패턴을 사용하지 않으면 , 이 요구는 이 처리자가 처리해야 한다 라는 지식을 누군가 중앙 집중적으로 가지고 있어야 한다. 이 지식을 요구자에게 맡기는 것은 현명하지 않다.

동적으로 처리자들의 순서를 바꿀 수 있다.

자신의 일에 집중할 수 있다.

유연성은 높지만, 처리 속도는 느린 단점.

Flyweight Pattern

크기가 큰 객체가 여러 개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴. 해쉬 테이블에 자주 사용되고 반복적이며 메모리가 큰 것을 저장해두고 재사용하는것

인스턴스를 가능한 한 공유시켜서, 쓸데없이 new를 하지 않도록 한다. – 인스턴스가 필요할 때 마다 new를 하는 것이 아니라, 이미 만들어져 있는 인스턴스를 이용할 수 있으면 공유하자.
Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

Prototype Pattern

생성할 객체의 종류를 명시하는 데에 원형이 되는(Prototypical) 인스턴스를 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴.
클래스로부터 인스턴스를 새로 만드는 것이 아니라, 현재 존재 하는 인스턴스를 복사(복제)해서 새로운 인스턴스를 만들 필요 가 있을 때, 이 작업을 편하게 하기 위해 사용한다

pros : 인스턴스를 만드는 복잡한 과정을 몰라도 되고 속도가 빠르다
cons : 복사본 자체를 만드는일 자체가 복잡할 수 있다.

객체를 빨리 생성하는 패턴

Memento Pattern

현재 객체의 상태를 기록하여 보존하기 위한 Memento 패턴
– Caretaker 역할은 중간 중간 Originator 역할에게 부탁하여 ‘현 재의 상태’를 표현하는 Memento 역할을 만든다.
– Caretaker 역할은 필요할 때 서랍 안에서 Memento 역할을 꺼 내서 Originator 역할에게 건네주면, 그 상태로 복원이 된다.

3. Principles of SW Design

Owl Life — Thu, 1 Dec 2022 22:46:00 +0900

SOLID

In computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C.Martin. Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or Adaptive Software Development. The SOLID acronym was introduced by Michael Feathers.

SRP

A class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class)

OCP

확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

Don’t modify code, just extend class using inheritance, composition.

LSP

상속을 얼마나 잘 사용하고 있는가에 대한 원칙

상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

상위 타입 : Base 클래스, 하위 타입 : 구체 클래스

class apple extends Item {}

// 메서드 인자로 item 대신에 apple을 넘기더라도 동작해야 함.
// 여기서 리스코프 치환 원칙이 지켜지지 않는다면, 다형성에 기반한 개방 폐쇄 원칙 역시 위반하는것.
// instanceof를 통하여 하위 클래스의 존재를 알아야 하는 순간 잘못 사용하고 있는것.
public int calculate(final Item item) {
	return item.calculate();
}

ISP

클라이언트는 자신이 사용하는 메서드에만 의존해야 한다.

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써,

클라이언트로부터 발생하는 인터페이스의 여파가 다른 클라이언트에 미치는 영향을 최소화 하는것을 목표로 한다.

ISP 미적용	ISP 적용
User2 코드 수정시, User1도 새로 컴파일 해야 할 수 있음.

DIP

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다.

저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다. 즉, 자신보다 변하기 쉬운 것에 의존하지 마라.

Example

자동차가 스노우타이어에 의존. 즉, 고수준 모듈인 자동차가 저수준 모듈인 스노우타이어에 의존.

이런 경우, 타이어 변경시 자동차의 부속품도 변경 해야 함. → OCP 위배

이슈 해결 위하여, DIP는 추상화를 활용하여 아래처럼 설계

Separaction of Concerns

개발 및 유지관리를 단순하게 해준다.

잘 나뉘어 있는 관심사(concern)는 개별 섹션을 재사용 할 수 있을 뿐 아니라 다른 섹션의 세부 사항을 알지도 변경하지 않고도 개발된 코드를 재사용할 수 있게 함.

Q) Give examples of applying Separation of Concerns.

A) Internet protocol stack, MVC, Microservice 등

Modularity, Functional Independence

Cohesion : Indication of the relative functional strength of a module

Coupling : Indication of the relative interdependance among modules.

2. OO Analysis and Design (OOAD)

Owl Life — Thu, 1 Dec 2022 22:21:16 +0900

OOA 단계객체지향 분석 (Object Oriented Analysis)

- 문제를 정의하고 이 정의로부터 개념 모델(객체에 대한 추상적 정의)을 사용하여 객체, 관계 및 동작을 식별한다.

사물이나 컨셉을 설명하거나 찾아내는 것.

즉, 요구사항을 찾아내고, 그 속의 객체들의 목록을 찾아내는 것

OOA 단계

1. 요구사항 도출

- 소프트웨어가 수행해야 하는 작업과 해결하려는 문제를 정의

2. 요구사항 지정

- 일반적으로 사용사례 및 시나리오 또는 사용자 스토리를 사용하여 요구사항 설명

3. 개념 모델(Conceptual model)

- 중요한 객체를 식별하고 다듬고 관계와 동작을 정의하여 간단한 도표로 표현

개념 모델의 종류

1. 객체 모형 (Object Model)

- 객체들과 그 특성을 식별하여 객체들의 정적 구조(static structure)와 그들과의 관계(Interface)를 보여주는 객체 다이어그램(Object Diagram)을 작성한다.

2. 동적 모형 (Dynamic Model)

- 시간 흐름에 따른 시스템의 변화를 보여주는 상태 다이어그램(State Diagram)을 작성한다. 실시간(real-time) 시스템에서는 반드시 필요하다.

3. 기능 모형 (Function Model)

- 시스템 내에서 데이터 값이 변하는 과정을 보여주는 것으로 잘 알려진 자료 흐름도(DFD)가 사용된다.

객체지향 설계 (Object Oriented Design)

- 설계 단계에서는 객체와 그들의 속성(attribute), 동작(behavior), 상호작용(interaction)을 설명한다.

즉, OOA를 통해 찾아진 객체들 간의 관계를 설정하는 것.

설계 단계에서는...

올바른 요구에 맞는 다양한 다이어그램을 선택하는 것이 중요하다.

1. 클래스 다이어그램를 사용하여 클래스와 클래스의 관계를 설명
- 필요한 클래스를 시각적으로 나타낸다. 이 단계에서 유전성(Inheritance)이나 다형성(Polymorphism)과 같은 객체 지향적인 원칙에 대해서 구체적으로 알게 된다.

2. 시퀀스 다이어그램를 사용하여 개체 간의 상호작용을 설명

3. 그 외에도 객체간의 상호작용, 시스템의 구조, 시스템의 동작, 어떻게 이벤트에 반응하는지에 대해 표현할 수 있는 다이어그램이 많다.

그리고 소프트웨어 설계 원칙 및 설계 패턴을 적용하여 설계한다.

객체지향 설계의 종류

1. 시스템 설계(System Design)

- 시스템의 구조를 서브시스템으로 분해한다. 이 과정중에서 성능 최적 방안, 문제 해결 전략, 자원 분배 등이 확정된다.

2. 객체 설계(Object Design)

- 구현에 필요한 상세한 내역을 설계 모형으로 제작하고 상세화된다. 구체적인 자료구조와 알고리즘 들이 정의된다.

Q) When would you use X Diagram?

Use Case Diagram

사용자의 요구를 기능적인 측면에서 명시하며, 시스템이 제공해야 하는 서비스의 목록을 얻기 위해 사용.
또한, 특정 기능이 동작 후에 어떤 기능이 추가로 실행되는지, 또는 어떤 조건 하에 후속 기능이 수행되는지를 검토해보면서 공통 기능을 추출해 볼 수 있고, 유사 기능 분류를 통해 기능 단위로 Encapsulation을 수행해 볼 수 있다.
"시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 다이어그램"
"시스템 외의 요소와 기능적 요구사항을 Actor와 Use case, Relationship으로 표현"

Relationships

연관(Association): Use Case와 Actor의 관계를 표현(실선)
확장(Extend): 기본 Use Case 수행 시 특별한 조건을 만족할 때 수행하는 Use Case
포함(Include): 시스템의 기능이 별도의 기능을 포함(점선)
일반화(Generalization): 하위 Use Case/Actor가 상위 Use Case/Actor에게 기능/역할을 상속 받음
그룹화(Grouping): 여러 개의 Use Case를 단순화 하는 방법

Granularity of Use Case

Use Case의 적당한 크기는 Use Case의 정의에 충실하게 되어 있고, 개발과 관리에 용이한가를 만족하면 된다.

Use Case Description / Scenario

사용자 중심 접근 (story와 예제 중심의 형식으로 기술)

사용자가 시나리오를 사용하여 요구사항 분석 지원

Class Diagram

도출한 Class들 간의 관계를 정의하고 검증함으로써 Persistence한 Dataset과 그들의 관계, 속성들을 결정한다.
Entity type의 class와 그들의 관계 및 cardinality, 그리고 몇개의 key 속성을 보여준다.
시스템을 구성하는 클래스의 구성 (Attribute, Operation)과 클래스 간의 관계를 표현하기위해 사용
Class Name, Attribute, Operation, Relationship을 가지고 있음.

5 Types of Relationship

Q) Order the strengths of 5 relationship types. Justify the ordering.

Inheritance : 상속 (Strong)
Composition : 생명 주기 함께
Aggregation : 레퍼런스 객체 가지고 있음.
Associate : 지속적 호출 (보통 한 클래스 내에서만 사용) / 한 객체가 다른 객체와 연결되어 있음을 나타낼때 사용.
Dependency : 잠깐 호출 (보통 한 메서드 내에서만 사용) (Weak)

Sequence Diagram

"Workflow related to Use Case Description"

"Applying MVC style paradigm in drawing Sequence Diagram"

Use case에 대해서 어떻게 Sequence적으로 동작하는지 설명

외부 사용자 또는 Actor가 발생시키는 이벤트, 메시지 호출의 순서 등을 이용하여 기능적인 요소들이 실시간에 어떤 메시지를 주고 받는지를 설계하기 위한 다이어그램.
시간의 흐름에 따라 여러 Object간의 상호작용을 구성 요소 간의 메시지 전달로 표현.

State Machine Diagram

목표 시스템이 State 종속적으로 실행되는 Behavior를 가지고 있을 때, 상태와 상태 간에 전이에 관련된 설계.

State Machine이 이벤트에 따라 어떠한 상태변화가 있는지를 모델링하는 다이어그램.

Transition, Event, Guard, Action

Event가 발생하면 현재 상태에 따라 상태 Transition이 발생한다.

Guard를 만족하지 못하면 이벤트가 발생하지 않는다.

State가 변경되면 entry, exit, do에 명시된 Action이 발생한다.

Final State는 실제로 존재할 수 있는 State이지만 Terminated Node는 아예 State Machine이 종료.

Timing Diagram

타이밍 다이어그램은 시퀀스 다이어그램 의 특수한 형태입니다 . 타이밍 다이어그램과 시퀀스 다이어그램의 차이점은 축이 반대로 되어 왼쪽에서 오른쪽으로 시간이 증가하고 생명선이 수직으로 배열된 별도의 구획에 표시된다는 것입니다.

Activity Diagram

여러 Action들이 순차 병행 방식 등을 수행하는 상황을 표현.

복잡한 Workflow나 병행 처리, 시간 제약이 있는 중요한 알고리즘에 대한 설계.

Action을 묶어 Activity로 나타낼 수 있음.

설계 단계에서는 클래스나 컴포넌트의 알고리즘을 Activity Diagram을 통해서 표현할 수도 있음.

Component Diagram

컴포넌트란 시스템을 구성하는 임의의 물리적인 요소를 의미
물리적인 요소란 가상의 모델을 실제로 구현하여 나타낸 것
객체지향 원리에서 컴포넌트는 인터페이스에 의해서 기능이 정의된 독립적으로 개발, 배포, 조립이 가능한 시스템의 구성 단위 (Ex. JAR, DLL)
컴포넌트 다이어그램의 구성요소는 컴포넌트, 인터페이스, 의존관계, 지원관계로 나뉨
의존관계는 컴포넌트와 컴포넌트 사이의 관계이고 지원관계는 인터페이스와 컴포넌트의 관계
컴포넌트들은 서로간 loosely coupled 해야 함.

Provided Interface

다른 컴포넌트가 사용할 수 있는 서비스를 명시하는것.

Required Interface

플러그인 컴포넌트가 구현해야 하는 프로토콜을 명시하는것.

Q) Why is required interface essential in designinig platform SW?

A) 컴포넌트는 하나의 구성 요소. S/W 디자인의 SRP에 따라 모든 인터페이스를 하나의 컴포넌트에 구현하는 것은 불가능함. 따라서 필요한 인터페이스는 외부의 다른 컴포넌트에서 얻어와야 할 수 있으며, 그렇기에 필수적이라 생각.

Deployment Diagram

이 다이어그램은 노드, 노드 간 네트워크 연결 및 노드에 배포된 소프트웨어 아티팩트를 지정.

UML Constructs for Parallel Processing

Activity Diagrm에서 fork & join 을 활용하여 표현 할 수 있습니다.

Consistency

Among Use Case Model, Class Diagram, & Sequence Diagram

Between State Machine Diagram & Class Diagram

Between Activity Diagram & Use Case Diagram

Q) How do you check the consistency between <X diagram> & <Y diagram>

객체지향 프로그래밍 / OOP란?

Owl Life — Thu, 1 Dec 2022 21:47:00 +0900

Object-Oriented Paradigm

객체 지향 패러다임을 설명할때 절차지향 프로그래밍과 비교하여 설명하곤 합니다.

아래 표를 통해 잠깐 살펴 보겠습니다. ^^

Procedural Programming	Object Oriented Programming
- 위에서 아래로 순서대로 수행되는 개발 방법 (C언어) - 컴퓨터 작업 처리 방식과 유사하기 때문에 실행 속도가 빠름 - 유지보수가 힘들고 시간이 많이 소요됨 - 수정시 모든 절차에 영향을 줄 수 있음	- 실제 세계를 모델링. - 데이터와 절차를 하나의 덩어리로 묶어서 표현. - Encapsulation, Inheritance, Polymorphism이 있음. - 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 사용. - increase the flexibility and maintainability

Class and Objects

An object is an instance of a class. Objects are unit of abstraction. An object can communicate with other using messages. An object passes a message to another object, which results in the invocation of a method. Objects then perform the actions that are required to get a response from the system.

Real world objects all share two characteristics; they all have state and behavior. One-way to begin thinking in an object oriented way is to identify the state and behavior of real world objects. The complexity of objects can differ, some object have more states and more complex behaviors than other object. Compare the state and behavior of a television to the states and behaviors of a car.

Software objects are conceptually similar to real world objects. An object stores its state in fields, and it exposes its behaviors through its methods.

Encapsulation

하나의 객체에 대해 그 객체가 특정한 목적을 위해 필요한 변수나 메소드를 하나로 묶는 것.

데이터와 코드의 형태를 외부로부터 알 수 없게 은닉.

Cohesion 증가, Coupling 감소
SoC 달성
외부의 변화에 영향을 덜 받음

Inheritance

"is-a" 관계. 부모 객체의 속성과 메서드를 자식이 물려 받는 것.

객체들 간의 관계를 구축하는 방법 중 하나.

상속을 통해 부모 클래스의 기능을 자식 클래스가 재사용할 수 있고 기능을 확장 할 수 있음.

Polymorphism

상속을 통해 기능을 확장하거나 변경하는 것을 가능하게 해 줌.

즉, 형태가 같은데 다른 기능을 하는 것을 의미. 자바의 오버라이딩, 오버로딩이 대표적인 예.

1. Overloading

메서드의 이름은 같고 매개변수의 갯수나 타입이 다른 함수를 정의하는 것.

2. Overriding

상속 받은 하위 클래스가 메서드의 내용만 변경(재정의) 하는 것.

3. Dynamic Binding

객체의 성격이 컴파일 타임이 아닌 런타임에 결정됨. 다형성을 사용하고 OCP를 가능하게 하는 장치.

장점 : 유연성 (런타임까지 타입에 대한 결정을 끌고 갈 수 있기 때문에 많은 선택의 여지가 있음)
단점 : 안정성 (실행 도중에 예상치 못한 타입이 들어와서 타입 에러를 발생시키는 경우가 발생)
반면, 정적 바인딩은 컴파일 타임에 결정됨.
Q) Why is Dynamic Binding essential in object-oriented programming?

4. Substitutability (대체 가능성)

특정 타입을 사용해야 하는 곳이 있다면, 이 타입의 서브타입을 대신 쓸 수 있다는 원칙.

Abstraction

객체의 공통적인 속성과 기능을 추출하여 정의하는 것. 실제로 존재하는 객체들을 프로그램으로 만들기 위한 공통적인 특성을 파악해서 필요 없는 특성을 제거하는 과정

장점
- 재사용성 : 상속을 통해 프로그래밍시 코드의 재사용을 높일 수 있음.
- 생산성 향상 : 잘 설계된 클래스를 만들어서 독립적인 객체를 사용함으로써 개발의 생산성을 향상할 수 있음.
- 유지보수 우수성 : 프로그램 수정 시 캡슐화를 통해 주변 영향이 적기 때문에 유지보수가 쉬워서 매우 경제적이라고 할 수 있음.
단점
- 느린 개발 속도, 느린 실행 속도, 높은 난이도.

Information Hiding

코드 내부의 data와 method를 숨기고 공개된 Interface를 통해서만 접근이 가능하도록 하는 개념이다. 공개범위는 접근지시자로 지정 합니다.

Visibility(접근성)
Public, Protected, Private같은 접근 지시자를 이용해 데이터나 메소드에 대한 접근 권한을 제어하는 키워드

Encapsulation은 관련된 요소를 묶어 캡슐 내부와 외부를 구별지는 장치이고 Information Hiding은 캡슐 내부요소들에 대한 세부 구현사항을 외부에 숨기는 장치이다. 따라서 캡슐화 했다고 해서 반드시 Hide 되는 것은 아니다.

모듈간 의존도를 낮춰서 Coupling이 낮아지고 Modularity가 좋아진다. 모듈내에 변경해도 외부에 미치는 영향을 최소화 할 수 있다.

Abstract Class & Interface

Q) What is the difference between Abstract Class and Interface?

Abstract Class

추상 클래스를 상속 받아 기능을 이용하고 확장 시키기 위함
추상 메소드가 하나 이상 포함되면 반드시 추상 클래스로 선언되어야 함.
반드시 추상 클래스를 상속하는 자식 클래스에서 부모가 가진 추상 메소드를 모두 Overriding해야 함.
추상 클래스에서 추상 메소드가 아닌 일반 메소드를 포함시킬 수 있다.
추상 메소드는 몸체가 없고 선언부만 존재한다.
다중 상속 불가능

Interface

구현 객체의 같은 동작을 보장하기 위함
오로지 추상 메소드와 상수만을 가집니다. 즉 로직을 작성할 수 없습니다.
인터페이스 내에 존재하는 메소드는 무조건 public abstract로 선언됩니다.
인터페이스 내에 존재하는 변수는 무조건 public static final로 선언됩니다.
인터페이스는 다중 상속과 비슷한 기능을 제공합니다.
다중 상속 가능

Generic Class & Template

형식 매개 변수

- 사용자가 전달하는 “형식”을 매개변수로 사용하여 형식 내부에서 형식 매개 변수로 정의된 (주로 단일 형식 매개 변수에서는 T를 사용합니다.) 형식을 교체하는 것입니다.

- 클래스를 정의할 때, 구체적인 타입(type)을 적지 않고 변수 형태로 적어 놓는 것이다.

자음 한자 특수문자

Owl Life — Fri, 14 Oct 2022 22:53:44 +0900

문장 부호
	1	2	3	4	5	6	7	8	9
ㄱ		！	＇	，	．	／	：	；	？
	＾	＿	｀	｜	￣	、	。	·	‥
	…	¨	〃		―	∥	＼	∼	´
	～	ˇ	˘	˝	˚	˙	¸	˛	¡
	¿	ː
괄호
	1	2	3	4	5	6	7	8	9
ㄴ	＂	（	）	［	］	｛	｝	‘	’
	“	”	〔	〕	〈	〉	《	》	「
	」	『	』	【	】
수학 기호
	1	2	3	4	5	6	7	8	9
ㄷ	＋	－	＜	＝	＞	±	×	÷	≠
	≤	≥	∞	∴	♂	♀	∠	⊥	⌒
	∂	∇	≡	≒	≪	≫	√	∽	∝
	∵	∫	∬	∈	∋	⊆	⊇	⊂	⊃
	∪	∩	∧	∨	￢	⇒	⇔	∀	∃
	∮	∑	∏

단위 기호
	1	2	3	4	5	6	7	8	9
ㄹ	＄	％	￦	Ｆ	′	″	℃	Å	￠
	￡	￥	¤	℉	‰	€	㎕	㎖	㎗
	ℓ	㎘	㏄	㎣	㎤	㎥	㎦	㎙	㎚
	㎛	㎜	㎝	㎞	㎟	㎠	㎡	㎢	㏊
	㎍	㎎	㎏	㏏	㎈	㎉	㏈	㎧	㎨
	㎰	㎱	㎲	㎳	㎴	㎵	㎶	㎷	㎸
	㎹	㎀	㎁	㎂	㎃	㎄	㎺	㎻	㎼
	㎽	㎾	㎿	㎐	㎑	㎒	㎓	㎔	Ω
	㏀	㏁	㎊	㎋	㎌	㏖	㏅	㎭	㎮
	㎯	㏛	㎩	㎪	㎫	㎬	㏝	㏐	㏓
	㏃	㏉	㏜	㏆
도형 문자
	1	2	3	4	5	6	7	8	9
ㅁ	＃	＆	＊	＠	§	※	☆	★	○
	●	◎	◇	◆	□	■	△	▲	▽
	▼	→	←	↑	↓	↔	〓	◁	◀
	▷	▶	♤	♠	♡	♥	♧	♣	⊙
	◈	▣	◐	◑	▒	▤	▥	▨	▧
	▦	▩	♨	☏	☎	☜	☞	¶	†
	‡	↕	↗	↙	↖	↘	♭	♩	♪
	♬	㉿	㈜	№	㏇	™	㏂	㏘	℡
	®	ª	º	㉾
괘선 문자
	1	2	3	4	5	6	7	8	9
ㅂ	─	│	┌	┐	┘	└	├	┬	┤
	┴	┼	━	┃	┏	┓	┛	┗	┣
	┳	┫	┻	╋	┠	┯	┨	┷	┿
	┝	┰	┥	┸	╂	┒	┑	┚	┙
	┖	┕	┎	┍	┞	┟	┡	┢	┦
	┧	┩	┪	┭	┮	┱	┲	┵	┶
	┹	┺	┽	┾	╀	╁	╃	╄	╅
	╆	╇	╈	╉	╊

원 문자/괄호 문자(한글)
	1	2	3	4	5	6	7	8	9
ㅅ	㉠	㉡	㉢	㉣	㉤	㉥	㉦	㉧	㉨
	㉩	㉪	㉫	㉬	㉭	㉮	㉯	㉰	㉱
	㉲	㉳	㉴	㉵	㉶	㉷	㉸	㉹	㉺
	㉻	㈀	㈁	㈂	㈃	㈄	㈅	㈆	㈇
	㈈	㈉	㈊	㈋	㈌	㈍	㈎	㈏	㈐
	㈑	㈒	㈓	㈔	㈕	㈖	㈗	㈘	㈙
	㈚	㈛
원 문자/괄호 문자(영/숫자)
	1	2	3	4	5	6	7	8	9
ㅇ	ⓐ	ⓑ	ⓒ	ⓓ	ⓔ	ⓕ	ⓖ	ⓗ	ⓘ
	ⓙ	ⓚ	ⓛ	ⓜ	ⓝ	ⓞ	ⓟ	ⓠ	ⓡ
	ⓢ	ⓣ	ⓤ	ⓥ	ⓦ	ⓧ	ⓨ	ⓩ	①
	②	③	④	⑤	⑥	⑦	⑧	⑨	⑩
	⑪	⑫	⑬	⑭	⑮	⒜	⒝	⒞	⒟
	⒠	⒡	⒢	⒣	⒤	⒥	⒦	⒧	⒨
	⒩	⒪	⒫	⒬	⒭	⒮	⒯	⒰	⒱
	⒲	⒳	⒴	⒵	⑴	⑵	⑶	⑷	⑸
	⑹	⑺	⑻	⑼	⑽	⑾	⑿	⒀	⒁
	⒂
전각 숫자(아라비아/로마)
	1	2	3	4	5	6	7	8	9
ㅈ	０	１	２	３	４	５	６	７	８
	９	ⅰ	ⅱ	ⅲ	ⅳ	ⅴ	ⅵ	ⅶ	ⅷ
	ⅸ	ⅹ	Ⅰ	Ⅱ	Ⅲ	Ⅳ	Ⅴ	Ⅵ	Ⅶ
	Ⅷ	Ⅸ	Ⅹ

분수/첨자
	1	2	3	4	5	6	7	8	9
ㅊ	½	⅓	⅔	¼	¾	⅛	⅜	⅝	⅞
ㅊ	¹	²	³	⁴	ⁿ	₁	₂	₃	₄
현대 한글 낱자
	1	2	3	4	5	6	7	8	9
ㅋ	ㄱ	ㄲ	ㄳ	ㄴ	ㄵ	ㄶ	ㄷ	ㄸ	ㄹ
	ㄺ	ㄻ	ㄼ	ㄽ	ㄾ	ㄿ	ㅀ	ㅁ	ㅂ
	ㅃ	ㅄ	ㅅ	ㅆ	ㅇ	ㅈ	ㅉ	ㅊ	ㅋ
	ㅌ	ㅍ	ㅎ	ㅏ	ㅐ	ㅑ	ㅒ	ㅓ	ㅔ
	ㅕ	ㅖ	ㅗ	ㅘ	ㅙ	ㅚ	ㅛ	ㅜ	ㅝ
	ㅞ	ㅟ	ㅠ	ㅡ	ㅢ	ㅣ
옛한글 낱자
	1	2	3	4	5	6	7	8	9
ㅌ	ㅥ	ㅦ	ㅧ	ㅨ	ㅩ	ㅪ	ㅫ	ㅬ	ㅭ
	ㅮ	ㅯ	ㅰ	ㅱ	ㅲ	ㅳ	ㅴ	ㅵ	ㅶ
	ㅷ	ㅸ	ㅹ	ㅺ	ㅻ	ㅼ	ㅽ	ㅾ	ㅿ
	ㆀ	ㆁ	ㆂ	ㆃ	ㆄ	ㆅ	ㆆ	ㆇ	ㆈ
	ㆉ	ㆊ	ㆋ	ㆌ	ㆍ	ㆎ
전각 로마자
	1	2	3	4	5	6	7	8	9
ㅍ	Ａ	Ｂ	Ｃ	Ｄ	Ｅ	Ｆ	Ｇ	Ｈ	Ｉ
	Ｊ	Ｋ	Ｌ	Ｍ	Ｎ	Ｏ	Ｐ	Ｑ	Ｒ
	Ｓ	Ｔ	Ｕ	Ｖ	Ｗ	Ｘ	Ｙ	Ｚ	ａ
	ｂ	ｃ	ｄ	ｅ	ｆ	ｇ	ｈ	ｉ	ｊ
	ｋ	ｌ	ｍ	ｎ	ｏ	ｐ	ｑ	ｒ	ｓ
	ｔ	ｕ	ｖ	ｗ	ｘ	ｙ	ｚ
그리스 문자
	1	2	3	4	5	6	7	8	9
ㅎ	Α	Β	Γ	Δ	Ε	Ζ	Η	Θ	Ι
	Κ	Λ	Μ	Ν	Ξ	Ο	Π	Ρ	Σ
	Τ	Υ	Φ	Χ	Ψ	Ω	α	β	γ
	δ	ε	ζ	η	θ	ι	κ	λ	μ
	ν	ξ	ο	π	ρ	σ	τ	υ	φ
	χ	ψ	ω

확장 라틴 문자
	1	2	3	4	5	6	7	8	9
ㄲ	Æ	Ð	Ħ	Ĳ	Ŀ	Ł	Ø	Œ	Þ
	Ŧ	Ŋ	æ	đ	ð	ħ	ı	ĳ	ĸ
	ŀ	ł	ø	œ	ß	þ	ŧ	ŋ	ŉ
히라가나
	1	2	3	4	5	6	7	8	9
ㄸ	ぁ	あ	ぃ	い	ぅ	う	ぇ	え	ぉ
	お	か	が	き	ぎ	く	ぐ	け	げ
	こ	ご	さ	ざ	し	じ	す	ず	せ
	ぜ	そ	ぞ	た	だ	ち	ぢ	っ	つ
	づ	て	で	と	ど	な	に	ぬ	ね
	の	は	ば	ぱ	ひ	び	ぴ	ふ	ぶ
	ぷ	へ	べ	ぺ	ほ	ぼ	ぽ	ま	み
	む	め	も	ゃ	や	ゅ	ゆ	ょ	よ
	ら	り	る	れ	ろ	ゎ	わ	ゐ	ゑ
	を	ん
가타카나
	1	2	3	4	5	6	7	8	9
ㅃ	ァ	ア	ィ	イ	ゥ	ウ	ェ	エ	ォ
	オ	カ	ガ	キ	ギ	ク	グ	ケ	ゲ
	コ	ゴ	サ	ザ	シ	ジ	ス	ズ	セ
	ゼ	ソ	ゾ	タ	ダ	チ	ヂ	ッ	ツ
	ヅ	テ	デ	ト	ド	ナ	ニ	ヌ	ネ
	ノ	ハ	バ	パ	ヒ	ビ	ピ	フ	ブ
	プ	ヘ	ベ	ペ	ホ	ボ	ポ	マ	ミ
	ム	メ	モ	ャ	ヤ	ュ	ユ	ョ	ヨ
	ラ	リ	ル	レ	ロ	ヮ	ワ	ヰ	ヱ
	ヲ	ン	ヴ	ヵ	ヶ
키릴 문자
	1	2	3	4	5	6	7	8	9
ㅆ	А	Б	В	Г	Д	Е	Ё	Ж	З
	И	Й	К	Л	М	Н	О	П	Р
	С	Т	У	Ф	Х	Ц	Ч	Ш	Щ
	Ъ	Ы	Ь	Э	Ю	Я	а	б	в
	г	д	е	ё	ж	з	и	й	к
	л	м	н	о	п	р	с	т	у
	ф	х	ц	ч	ш	щ	ъ	ы	ь
	э	ю	я

예쁜 특수문자 이모티콘 (바로 복붙 가능)

Owl Life — Tue, 30 Aug 2022 00:01:44 +0900

"하트 특수문자 이모티콘"
( ღ'ᴗ'ღ )

◟( ˘ ³˘)◞ ♡

(•ө•)♡

(ฅ•ω•ฅ)♡

( ்́ꇴ ்̀)♡

ღ'ᴗ'ღ

๑❤‿❤๑

(๑˃̵ᴗ˂̵)و ♡

꒰◍ˊ◡ˋ꒱੭ु⁾⁾♡

(*ฅ́˘ฅ̀*)♡

( ˇ͈ᵕˇ͈ ) ¨̮♡⃛

(*ˊૢᵕˋૢ*)ෆ

( ˃̆ૢ௰˂̆ૢഃ ) ლ

٩(๑• ₃ -๑)۶♥

(๑˃̵ᴗ˂̵)و ♡

ʕ•ﻌ•ʔ ♡

ღ˘‿˘ற꒱

ෆ╹ .̮ ╹ෆ

ლ|'ー'ლ|

ლ( ╹ ◡ ╹ ლ)

₍₍ ( ๑॔˃̶◡˂̶๑॓)◞♡⁰

(✿◖◡◗)❤

"웃는 표정 이모티콘"
( ⁼̴̤̆◡̶͂⁼̴̤̆ )

(❁´▽`❁)

(❀╹◡╹)

(๑･̑◡･̑๑)

❛◡ુ❛

'◡'✿

✦‿✦

๑･̑◡･̑๑

๑❛◡ુ❛๑

꒰( ˵¯͒ꇴ¯͒˵ )꒱

◕‿◕✿

๑•‿•๑

๑◕‿‿◕๑

✪‿✪

✿˘◡˘✿

ღ˘‿˘ற꒱

(▰˘◡˘▰)

˘◡˘

✿˘◡˘✿

(๑′ᴗ‵๑)

(∗❛⌄❛∗)

(๑´◡ુ`๑)

p(´∇｀)q

๑•‿•๑

(*´ ワ `*)“

ξ(✿ ❛‿❛)ξ

(๑・‿・๑)

"신나는 표정 이모티콘"

♪(´ε｀*)

♪(*´θ｀)ノ

°˖✧◝(⁰▿⁰)◜✧˖°

٩(ˊᗜˋ*)و
҉ ٩(๑>ω<๑)۶҉

o(*'▽'*)/☆ﾟ’

٩(๑>∀<๑)۶

( ๑˃̶ ꇴ ˂̶)♪⁺

✧*.◟(ˊᗨˋ)◞.*✧

⁽⁽◝( ˙ ꒳ ˙ )◜⁾⁾

( ˃⍨˂̥̥ )

✺◟(∗❛ัᴗ❛ั∗)◞✺

(๑˃̵ᴗ˂̵)و

ᕕ( ᐛ )ᕗ

"귀여운 특수문자 이모티콘"(๑˃̵ᴗ˂̵)و

(╹౪╹*๑)

(˃̶᷄‧̫ ˂̶᷅๑ )

(✪ິັ໌໋໊ ꆚ ✪ິັ໌໋໊)

⁽⁽ૢ(⁎❝ົཽω❝ົཽ⁎)✧

₍₍ ◝(・ω・)◟ ⁾⁾

❛˓◞˂̵✧

( °ټ°)

(๑･̑◡･̑๑)

⁰▿⁰

(๑′ᴗ‵๑)

*❀्꒰⋆ᶿ̴͈᷇⌣ᶿ̴͈᷆⋆꒱ఇ

(๑╹∀╹๑)

❛ε ❛♪
p`>ω<´q)

(づ￣ ³￣)づ

(*ૂ❛ัᴗ❛ั*ૂ)

"화이팅 이모티콘"

ᕙ(•̀‸•́‶)ᕗ

٩( 'ω' )و

(ง •̀_•́)ง

(๑و•̀Δ•́)و

٩(๑•̀o•́๑)و

(๑ •̀ω•́)۶

٩(`･ω･´)و ҉*

\(`•ω•´)/*҉

٩( 'ω' )و ٩( 'ω' )و

✧ ☆ ٩(`･ω･´)و

"시무룩한 삐진 표정 이모티콘"

Σ(￣□￣;)

へ(￣∇￣へ)

( ｰ̀εｰ́ )✧*⁎

꒰⑅ᵕ̆‧̯ᵕ̆⑅꒱

(￣(ｴ)￣)ﾉ

(*￣(ｴ)￣*)

( •́ ̯•̀ )

ಡ ̯ ಡ

ｰ̀εｰ́

๑ŐεŐ๑

￣□￣

(´･ʖ̫･`)

๑°⌓°๑

(ㅇ︿ㅇ)

( •᷄⌓•᷅ )

(｡•́︿•̀｡)

๑°⌓°๑

(ﾟヘﾟ)？

(๑ӦㅅӦ๑)

(•ε•；)

"슬픈 표정 이모티콘"

⁺◟( ᵒ̴̶̷̥́ ·̫ ᵒ̴̶̷̣̥̀ )

o̴̶̷᷄﹏o̴̶̷̥᷅

(｡•́︿•̀｡)

ಡ︷ಡ)

(｡･ˇ_ˇ･｡)

( Ĭ ^ Ĭ )

(´°̥̥̥̥̥̥̥̥ω°̥̥̥̥̥̥̥̥｀)

"놀란 표정 이모티콘"

(ఠ ̥̆ ఠ)

(๑ŏ╻ŏ๑)

(๑°ㅁ°๑)‼✧

ŏ̥̥̥̥םŏ̥̥̥̥

(๑⊙ﾛ⊙๑)

(๑•́o•̀๑)

(оﾟдﾟо)

(╬☉д⊙)

(；◔д◔）

๑•̀ㅁ•́ฅ✧

"화난 표정 이모티콘"

٩(๑`^´๑)۶

☄ฺ◣д◢)☄ฺ

(╬◣д◢)

"특수문자 이모티콘 공유"

(͒ ˊ• ૢ·̫•ˋૢ)

(՟ິͫઘ ՟ິͫ)

( •̀.̫•́)✧

❛ัᴗ❛

(｡♋‸♋｡)

( ͡° ͜ʖ ͡°)

(ɔ ˘⌣˘)˘⌣˘ c)

₍₍ (ง ˙ω˙)ว ⁾⁾

( ･ิϖ･ิ)

( ⌯᷄௰⌯᷅ )

( ⁎ᵕᴗᵕ⁎ )

( °ټ°)

(๑ᵕ⌓ᵕ̤)

(⚭◡⚭ )

( ˇ͈ᵕˇ͈ )

(｡･ω･｡)o"

˘◡˘

(´͈ ᵕ `͈ )

ʅ（´◔౪◔）ʃ

(◔ิω◔ิ)

(〃･ิ‿･ิ)ゞ

(๑ᵕ⌓ᵕ̤)

(･ิω･ิ)

Ubuntu 16.04에서 Python 3.7 설치

Owl Life — Tue, 28 Jan 2020 21:25:30 +0900

들어가며...

django를 사용하려면 Python이 최소 3.7 버전이 설치 되어 있어야 합니다. 하지만 우분투 16.04에서 지원하는 버전은 3.5이기 때문에 추가로 설치를 하여야 합니다.

본인의 PC에 설치되어 있는 버전을 먼저 확인 해보겠습니다.

owllife@owllife-ubuntu:~$ python3
Python 3.5.2 (default, Oct  8 2019, 13:06:37) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

3.5가 설치 되어 있는것을 확인하였습니다.

3.7 버전을 설치 할 때 한가지 유의 해야 할 점은,

우분투 16.04의 많은 시스템 프로그램(터미널, 프로그램 업데이트 등)에서 파이썬 3.5를 사용하고 있습니다.

만약, 파이썬3 default 버전을 현재처럼 3.5가 아닌 3.7로 변경하게 되면 시스템 프로그램등이 제대로 동작하지 않을 수 있습니다.

시스템 재부팅 후 갑자기 프로그램이 동작되지 않는 상황을 맞이 할 수 있기 때문에 "update-alternatives" 를 이용하여 강제로 변경하지 않도록 유의하여야 합니다.

파이썬 3.7 설치

아래 명령어를 통하여 설치를 할 수 있습니다.

$ sudo apt update
$ sudo apt install software-properties-common

$ sudo add-apt-repository ppa:deadsnakes/ppa

$ sudo apt update
$ sudo apt install python3.7

python3.7이 설치 되었지만, 파이썬3의 기본 버전으로 변경되지 않았는지 확인을 하기 위하여 터미널에서 확인을 해보겠습니다.

owllife@owllife-ubuntu:~$ python3
Python 3.5.2 (default, Oct  8 2019, 13:06:37) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

파이썬 3.7이 설치 되었지만, 디폴트 버전은 여전히 3.5로 표시되는것을 확인하였습니다. 즉, 시스템 응용 프로그램들은 이전과 마찬가지로 정상적으로 동작하게 됩니다.

venv 설치

파이썬으로 개발하다보면 별도의 고립된 공통의 환경을 만들어두고 개발하는 경우가 많이 있습니다.

venv를 많이 사용하는데 이 역시 3.7 버전에 맞추어 설치하도록 하겠습니다. 터미널에서 아래 명령어를 입력합니다.

$ sudo apt-get install python3.7-venv

만약, python3.7-venv로 설치하지 않고 python3-venv 명령어로 설치하게 되면, 현재 시스템 디폴트 버전으로 잡혀 있는 python3.5 버전에 맞추어서 설치 되기 때문에 사용 할때 django와 같이 그 이상의 파이썬 버전이 필요한 경우에는 정상적으로 동작하지 않게 됩니다.

예를 들어 아래와 같은 에러 메시지를 보게 됩니다.

$ python3.7 -m venv my_common_env

Error: Command '['/home/owllife/PycharmProjects/my_common_env/bin/python3.7', 
       '-Im', 'ensurepip', '--upgrade', '--default-pip']' 
       returned non-zero exit status 1.

정상적으로 python3.7 및 venv가 설치 되었다면 아래 명령어를 통하여 가상 환경을 생성 할 수 있습니다.

$ python3.7 -m venv my_common_env

venv 활성화

이제 activate 명령어를 실행하고 파이썬 3.7이 사용 중인지 확인 해보겠습니다.

위 이미지의 명령어대로 방금 생성한 env를 활성화 시키면 명령어 프롬프트 앞쪽에 (my_common_env)와 같이 prefix가 붙게 됩니다. 이후에는 python 명령어만 입력 했을뿐인데 3.7 버전으로 실행 되는것을 확인 할 수 있습니다. django를 사용한다면 이 상태에서 django를 설치하고 기본 프로젝트 등을 생성하여 진행하시면 됩니다.

pip 버전 확인

(my_common_env) owllife@owllife-ubuntu:~/PycharmProjects$ pip -V
pip 19.2.3 from /home/owllife/PycharmProjects/my_common_env/lib/python3.7/site-packages/pip (python 3.7)

파이썬의 여러 라이브러리르 설치 하기 위하여 pip를 사용하는데 pip가 파이썬 3.7 버전을 정확히 매핑하고 있는지 확인하였습니다.

우분투 16.04 LTS 설치 후 초기 설정작업

Owl Life — Tue, 28 Jan 2020 11:18:53 +0900

개인적으로 설정하는 항목들을 정리하기 위하여 포스팅 하는 글입니다.

프록시나 고정IP를 사용하는 회사망이 아닌 홈환경입니다.

ROOT 비밀번호 설정

터미널을 열고
$ sudo passwd

apt-get 패키지 다운로드 서버 변경하기

# 파일은 /etc/apt/sources.list

# 터미널 열고
$ sudo vi /etc/apt/sources.list

# 우분투 설치시 한국으로 설정하시고 한국어 언어를 설정하였다면 
# http://kr.archive.ubuntu.com/ubuntu/ 가 보일텐데 이를 다음 카카오 서버로 변경.
# 콜론 입력 후 아래 명령어 입력 후 저장.
:%s/kr.archive.ubuntu.com/ftp.daumkakao.com

# 동작 확인
$ sudo apt-get update

# 업그레이드 원하면
$ sudo apt-get upgrade -y

완료 된 화면

언어 지원

윈도우 키 눌러서 "언어 지원" 입력 후 실행합니다. 필수 언어를 다운로드 진행하고, 키보드 입력기는 fcitx 로 합니다.

우분투 설치시 키보드 설정하는 단계에서 한국어를 선택하지 않고, 영문으로 선택하게 되면 한/영 전환 키보드가 매핑되지 않아서 한영키가 동작하지 않습니다. 한/영키가 동작하지 않고 좌측 쉬프트+스페이스로 동작되기 때문에 별도로 설정해야 하는데 이 부분은 구글링을 통해 해결책을 찾을수 있습니다.

D2 Coding 글꼴 설치

https://softwaree.tistory.com/22

우분투 업데이트 및 그래픽 드라이브 설치

AMD나 NVIDIA 홈페이지에서 직접 다운로드 받아서 설치하게 되면 조금 번거롭습니다. 하지만, 소프트웨어 업데이트 도구를 이용하면 매우 쉽게 업데이트 할 수 있습니다. "소프트웨어 업데이트 도구" 를 선택 후 설정을 누르면 아래 두번째 창이 보이는데 "추가 드라이버" 탭으로 이동해보겠습니다.

사용가능한 여러 드라이브들이 버전별로 나오는데 그 중에서 본인 그래픽 드라이브와 호환 가능한 안정화 된 버전을 선택 후 적용을 선택하면 됩니다. 적용 후 꼭 재부팅을 하고 다시 위 화면으로 진입해서 정상적으로 적용되었는지 확인을 해 보는것을 권장합니다.

추가로, 안정화를 위하여 우분투 업데이트를 한번 진행 하는것을 권장한다. (첫번째 팝업의 지금 설치 버튼)

키보드 설정

키보드의 반복키 입력 간격을 줄이기 위하여 설정합니다. 지연 시간을 좀 짧게 설정하면 타이핑할때 딜레이 없이 입력이 가능합니다.

마우스 속도 설정

마우스 포인트 속도가 너무 빠르거나 느릴 경우에 아래처럼 설정 할 수 있습니다.

먼저 아래 명령어를 통하여 마우스의 input id를 알아야 합니다.

$ xinput --list --short

저는 MX Master 마우스를 사용하는데 id가 9번인 것을 확인 할 수 있습니다.

이제 터미널에 아래 명령어를 통하여 마우스 감도를 설정합니다.

$ xinput -set-prop 9 'Device Accel Constant Deceleration' 1.5

마지막 인자인 1.5가 감도인데, 제 환경에서는 1.5가 가장 적당하여 이렇게 설정하였습니다. 숫자가 낮을수록 포인트 속도는 빨라지고, 숫자가 커질수록 포인트 속도는 느려집니다. 각자의 환경에 맞추어 실험 후 최적의 값을 찾으면 됩니다.

xinput 변경값은 시스템이 재부팅되면 다시 리셋이 되어 또 다시 설정을 해 주어야 합니다. 이런 번거로움을 없애기 위해서는 "시작 프로그램"을 통하여 재부팅 될때마다 자동으로 스크립트를 실행 하도록 합니다.

VIM 설치

다른 글에서 작성한 링크로 대신합니다. vim 설치 및 vimrc 설정도 포함하고 있습니다.

https://softwaree.tistory.com/20?category=729597

터미널 설정

터미널을 열고 '편집'의 '프로파일 기본 설정'을 선택합니다. 최초 터미널 크기를 좀 더 키우고, 터미널 삑소리는 disable 하였습니다.

'색' 탭으로 이동 후 '투명한 배경 사용' 을 활성화 시키고 적당히 투명 감도를 조절해줍니다. 개인적으로 투명 배경을 매우 선호하기 때문에 꼭 설정하는 부분입니다.

마지막으로 '스크롤' 탭으로 이동 후 스크롤 막대 표시를 없애고, 제한 범위를 *10배로 상향시켰습니다. 콘솔로 개발 작업을 많이 하다보니 히스토리창을 꽤 이전것까지 참고하는 경우가 많아서 상당히 버퍼를 높여서 사용하는 편입니다.

Unity Tweak Tool 설치 및 설정

Ubuntu Gnome Tweak과 마찬가지로 Unity에도 Tweak 툴이 있는데 상세한 부분까지 설정이 가능한 추천 프로그램입니다. 런처를 상하좌우로 이동하는것부터, 테마/아이콘/font 까지 설정하고 virtual desktop의 배치 또한 설정이 가능합니다.

설치는 터미널에서 명령어로 가능합니다.

$ sudo apt-get install unity-tweak-tool

실행하면 아래 화면처럼 다양한 메뉴가 나타납니다.

런처 설정

Launcher 메뉴에서는 런쳐의 위치를 설정하거나 아이콘의 사이즈 등을 변경 할 수 있습니다.

테마 설정

Tweak Tool을 사용하는 가장 큰 이유이기도 합니다. 개인적으로 Numix 테마를 선호하기 때문에 설치하는 방법을 설명하겠습니다.

# 터미널을 열고

$ sudo add-apt-repository ppa:numix/ppa
$ sudo apt-get update
$ sudo apt-get install numix-*

테마에서 방금 설치 한 Numix를 선택합니다.

아이콘은 Numix-circle을 선택합니다. 개인적으로 가장 심플하면서 마음에 드는 스타일입니다.

폰트는 위와같이 설정하였습니다. Ubuntu 16.04 에서는 기본적으로 Noto Sans 폰트를 포함하고 있기 때문에 해당 폰트를 기본으로 설정하였고, monospace 또한 Noto Sans Mono로 변경하였습니다.

배경화면

개인적으로 심플한 배경화면을 좋아해서 아래 웹페이지에서 주로 다운로드를 합니다.

https://wallpaperplay.com/board/4k-minimalist-wallpapers

참고로, 만약 Tweak Tool을 이용해서 테마를 사용하고 있다면, 로그인 화면에 보이는 배경화면은 현재 설정한 배경 화면이 그대로 보이게 됩니다.

GIT 설치

$ sudo apt-get install git

이미지 뷰어 설치

개인적으로 PhotoQT Image Viewer을 선호합니다. UI가 매우 직관적이고 속도도 빨라서 다른 프로그램을 설치하더라도 결국엔 PhotoQT만 사용하게 되었습니다.

$ sudo apt-add-repository ppa:lumas/photoqt
$ sudo apt update && sudo apt install photoqt

Ctrl+O 입력을 통해 Folder 선택을 할 수 있고 선택을 하면 두번째 스크린샷 처럼 하단에 폴더 이미지가 모두 보여집니다. 기타 상세한 정보나 view 스타일 또한 메인 화면에서 설정 할 수 있습니다.

우분투 18.04 자바 설치

Owl Life — Tue, 26 Nov 2019 21:08:12 +0900

버전 확인

$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)

자바가 설치되지 않았다면 1.8을 설치
- Oracle : https://www.oracle.com/java/technologies/jdk8-downloads.html

- Bell-sw : https://bell-sw.com/pages/java-8u222/

* Oracle은 로그인해야 하는 번거로움이 있음.

* Bell-sw에서 빠르게 다운로드 받을수 있으니 참고.

빌드 할 때 아래와 같은 에러 발생시에는 제대로 된 JDK 가 설치되어 있지 않았으므로 위의 링크를 통해 다시 설치 필요.

* What went wrong: Execution failed for task ':app:compileDebugJavaWithJavac'. 
  > Could not find tools.jar. Please check that /usr/lib/jvm/java-8-openjdk-amd64 contains a valid JDK installation.

* 여러개의 자바 버전이 설치되어 있는 경우에 선택해서 타겟팅 해야 함.

$ update-alternatives --config java

대체 항목 java에 대해 (/usr/bin/java 제공) 2개 선택이 있습니다.

  선택       경로                                                 우선순위   상태
----------------------------------------------------------------------------------
* 0            /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java   2080222   자동 모드
  1            /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java   2080222   수동 모드
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      수동 모드

Press <enter> to keep the current choice[*], or type selection number: 0

우분투 18.04 테마 변경하기

Owl Life — Sun, 17 Nov 2019 22:17:26 +0900

개인) 아래 링크 참고해서 셋팅.

[Linux] Ubuntu 18.04 테마 설정하기

안녕하세요~ 이번 포스팅에서는 우분투 환경에서 테마를 적용하는 방법에 대해 알아보도록 하겠습니다! 우분투의 기본 테마는 아래와 같습니다. (이미지 출처: 구글) 이전의 16.xx 버전보다는 많이 깔끔해졌는데..

codevkr.tistory.com

특수문자 유니코드표 - 이모지, 이모티콘, 지도기호

Owl Life — Sun, 17 Nov 2019 21:50:33 +0900

이모지

이모티콘

지도 기호

파이썬 Django DB 초기화

Owl Life — Sun, 17 Nov 2019 21:04:24 +0900

Django로 개발을 하다보면 DB 초기화를 종종 해야 할 경우가 있습니다.

migration 하다가 DB가 꼬이는 경우 에러가 빈번하게 발생될 수 있기 때문에 어떻게 초기화 하는지에 대하여 한번 알아보겠습니다.

migrations 파일 삭제

$ find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
$ find . -path "*/migrations/*.pyc"  -delete

프로젝트의 root 위치에서 위와 같이 세 줄이면 DB 초기화가 완료되고 작성한 model의 스키마까지 적용이 완료됩니다. DB 관련 앱의 하위 폴더를 보면 migrations 폴더가 있을텐데 그 폴더에 존재하는 __init__.py 파일을 제외하고 폴더 내의 모든 파일을 삭제 합니다. 또한 파이썬 바이트코드인 pyc 파일들도 모두 제거합니다.

db.sqlite3

프로젝트의 root 디렉토리에 위치한 db.sqlite3 파일을 삭제합니다.

migration

$ python manage.py migrate

django 로 DB 생성할때 최초에 한번 migration 하는것처럼 위와 같은 명령어로 동일하게 수행합니다.

Trouble shooting - Python3: UnicodeEncodeError: 'ascii' codec can't encode character

Owl Life — Thu, 14 Nov 2019 23:54:12 +0900

print() 메서드를 이용하여 문자열을 출력할때 이러한 에러를 가끔씩 만날수 있습니다.

UnicodeEncodeError: 'ascii' codec can't encode character u'\xa1' 
in position 0: ordinal not in range(128)

해결책으로, 아래처럼 encoding 타입을 utf-8로 설정하면 수정이 가능합니다.

$ export PYTHONIOENCODING=utf-8

파이썬으로 웹페이지 크롤링을 해보자. (2) 텔레그램으로 메시지 보내기

Owl Life — Tue, 12 Nov 2019 00:40:44 +0900

이번 시간에는 앞서 구현한 크롤링 모듈을 일정 시간마다 시스템에서 자동으로 실행 하도록 실습 해보겠습니다. 그리고 새로운 글을 찾았을때 텔레그램과 연동해서 메시지를 전달 하는 기능을 구현해보도록 하겠습니다.

크롤링 실행 주기 설정

주기적으로 어떤 프로그램이나 스크립트를 실행 할 때에는 crontab 을 많이 사용합니다. 본 포스팅에서도 이 서비스를 이용하여 주기적으로 앞에서 만든 크롤링 모듈을 실행 해보도록 하겠습니다.

주기적으로 실행 되었다는것을 나타내기 위하여 clien_crawler.py 파일의 main 메서드에 현재의 시간을 기록하는 코드를 추가하겠습니다.

from datetime import datetime

if __name__ == '__main__':
    print('start - ' + datetime.now().strftime('%Y-%m-%d %H:%M:%S'))
    crawled_data = fetch_clien_latest_data()
    add_new_items(crawled_data)

또한, fetch_clien_latest_data() 메서드의 print(title) 코드도 더이상 불필요하기 때문에 삭제하였습니다.

자동 실행될 스크립트 파일 생성

crontab에 의하여 실행될 스크립트 파일을 root project에 위치시킵니다. 필자는 start_crawling.sh 파일명으로 아래처럼 코드를 작성하였습니다.

#!/bin/bash

source ~/PycharmProjects/MyVirtualEnv/bin/activate
python3 ~/PycharmProjects/a/ClienCrawlingDjango/clien_crawler.py

MyVirtualEnv라는 별도의 가상 환경을 사용하고 있기 때문에 액티베이션 시키는 코드를 첫줄에 추가하였습니다. 그 이후에 python3 로 clien_crawler.py 파일을 실행 시키는 코드를 작성하였습니다. 만약 가상 환경을 사용하지 않는다면 'source~' 줄은 추가하지 않아도 됩니다.

이제 이 스크립트를 실행하기 위하여 crontab 을 편집해보겠습니다. 터미널에서 crontab -e 명령어를 입력합니다. 그러면 에디터 창이 보이는데, 그 창에 crontab 관련 규칙과 실행할 명령어를 입력합니다.

$ crontab -e

#여기부터 에디터 입력창
*/1 * * * * ~/PycharmProjects/a/ClienCrawlingDjango/start_crawling.sh >> ~/PycharmProjects/a/ClienCrawlingDjango/crontab_log.txt 2>&1

crontab 의 주기 설정 방법은 링크를 참고 부탁드립니다. 위 코드는 1분마다 크롤링을 하는 코드를 작성하였기 때문에 가장 앞쪽에 '분' 단위 룰을 나타내는곳에 */1 을 설정하였습니다. 5분마다 설정하고 싶다면 */5 라고 설정하시면 됩니다.

'>>' 오퍼레이터는 print되는 문자들을 별도의 로그 파일에 기록하기 위함입니다. '>'는 덮어쓰기 작업이고, '>>'는 파일에 추가하는 작업입니다. 오랜 시간이 지나면 파일의 크기가 커지기 때문에 주기적으로 삭제해야 합니다.

입력을 완료 하였으면 저장 후 터미널로 돌아옵니다. 정상적으로 추가 되었는지 확인하려면 crontab -l 명령어를 입력해보면 리스트를 확인 할 수 있습니다.

$ crontab -l
*/1 * * * * ~/PycharmProjects/a/ClienCrawlingDjango/start_crawling.sh >> ~/PycharmProjects/a/ClienCrawlingDjango/crontab_log.txt 2>&1

몇분 정도의 시간 뒤에 로그 파일을 열어 보았습니다. 아래처럼 정상적으로 스크립트 파일이 실행되었고, 정확히 1분 간격으로 크롤링이 진행 되었음을 확인 할 수 있습니다.

start - 2019-11-11 13:26:00
start - 2019-11-11 13:27:01
start - 2019-11-11 13:28:02
start - 2019-11-11 13:29:03

텔레그램으로 메세지 전송하기

텔레그램으로 메시지를 전송하는 코드를 먼저 살펴보겠습니다. clien_crawler.py 파일에 추가하였습니다.

def send_noti_to_telegram(items):
    if len(items) == 0:
        return

    bot_token = '1034490xxxxxx'
    bot_chat_id = '-10010000000'

    for item in items:
        bot_message = "\[클리앙] " + item['title'] + \
                      "\n" + item['link']

        send_text = 'https://api.telegram.org/bot' + bot_token + \
                    '/sendMessage?chat_id=' + bot_chat_id + \
                    '&parse_mode=Markdown&text=' + bot_message

        requests.get(send_text)
        sleep(1)
        
        
if __name__ == '__main__':
    print('start - ' + datetime.now().strftime('%Y-%m-%d %H:%M:%S'))
    crawled_data = fetch_clien_latest_data()
    db_inserted_items = add_new_items(crawled_data)
    send_noti_to_telegram(db_inserted_items)

main 함수를 보면 디비에 추가된 항목을 리스트로 전달받고 send_noti_to_telegram() 메서드를 호출하고 있습니다. 이 메서드에서는 텔레그램으로 전달할 메시지를 빌드하고, requests 를 통하여 전달하고 있습니다.

여기에서 필요한게 bot token과 bot chat id 입니다. 어떻게 획득 할 수 있는지 한번 살펴보겠습니다.

텔레그램 bot token / bot chat id 획득하기

텔레그램을 실행 후 검색창에서 'BotFather'를 입력합니다.

선택 후 대화를 시작합니다. 대화 창에서 /newbot 을 입력합니다. 그러면 새로운 봇 이름을 입력하라는 메시지가 전달됩니다. 새로운 봇 이름을 입력합니다.

본 포스팅에서 사용할 예제에서는 'clien_test_bot' 으로 입력하겠습니다. 정상적으로 입력이 되면 이제 'bot'으로 끝나는 사용자 이름을 입력하라는 메시지가 전달됩니다. 똑같이 'clien_test_bot' 으로 입력하겠습니다. 완료되면 bot token 을 받을 수 있습니다.

숫자 9953으로 시작하는게 bot token 입니다.

이제 새로운 채널을 하나 생성해야 합니다. 아래처럼 아이콘을 클릭 후 "New Channel"을 선택합니다.

채널 이름은 "clien_test_channel" 로 입력하였습니다. 원하시는 채널 이름을 입력하시면 됩니다.

입력을 완료하면 우측 상단에 있는 "Next" 버튼을 클릭합니다. 완료되면 채널이 하나 생성되는것을 확인 할 수 있습니다.

생성한 채널의 관리자로 텔레그램 봇을 추가하기

bot chat id을 알기 위해서는 봇을 채널의 관리자로 추가 하여야 합니다. 관리자로 추가 하는 방법은 채널의 우측의 Info 에서 관리자 또는 Administrators를 클릭합니다.

Add Admin 을 클릭 후, 조금전에 생성한 clien_test_bot 을 검색 후 추가 해줍니다.

선택 후 추가 권한을 선택하는 창이 한번 더 보이는데 "Add Subscribers"를 FALSE 로 선택 하여야 합니다. 완료하면 아래처럼 관리자가 두명인것을 확인 할 수 있습니다. Shun은 본인 계정이고, clien_test_bot은 관리자 권한을 위임받은 봇입니다.

bot chat id 받기

이제 bot chat id 를 알아보도록 하겠습니다.

아래 URL 에 API 내용을 붙여 넣기 하여 인터넷 주소창에 입력하고 이동 해 봅니다.

https://api.telegram.org/bot[이부분]/getUpdates

위와 같이 입력을 하면 봇과 관련된 여러 정보들이 보여집니다. 만약 result에 아무런 정보가 보이지 않는다면 좀 기다렸다가 다시 시도 해보시기 바랍니다. bot chat id는 -1001173133632라는 것을 알 수 있습니다.

텔레그램으로 메시지 보내기

주소창에 아래처럼 입력을 해보겠습니다.

https://api.telegram.org/bot995398932:AAHsc4J34GC1UY59oUX0HrX6tcxs7sCTXjI/sendMessage?chat_id=-1001173133632&text=Hello

그러면 텔레그램 채널로 Hello가 입력 되는것을 확인 할 수 있습니다.

이제 저 URL을 python 코드상에서 적절히 조합을 하면 텔레그램으로 메시지를 손쉽게 전송 할 수 있습니다.

bot token과 bot chat id 둘다 알았으니 코드를 업데이트하고 실행해보겠습니다.

def send_noti_to_telegram(items):
    if len(items) == 0:
        return

    bot_token = '995398932:AAHsc4J34GC1UY59oUX0HrX6tcxs7sCTXjI'
    bot_chat_id = '-1001173133632'

    for item in items:
        bot_message = "\[클리앙] " + item['title'] + \
                      "\n" + item['link']

        send_text = 'https://api.telegram.org/bot' + bot_token + \
                    '/sendMessage?chat_id=' + bot_chat_id + \
                    '&parse_mode=Markdown&text=' + bot_message

        requests.get(send_text)
        sleep(1)

실행을 해보니 새로운 글이 2건 등록되었습니다.(PyCharm Console에서 확인)

해당 2건은 DB에 추가 후 텔레그램으로 푸쉬가 오는것을 확인 할 수 있습니다. (텔레그램 채널 확인)

TIP

만약, bot_message에 & 문자를 가진 url을 포함한다면 그대로 전송할시에 정상적으로 노출이 되지 않을수 있습니다.

이럴 경우에는 아래처럼 UTF-8 문자로 변경하면 정상적으로 전송이 됩니다.

bot_message.replace('&', '%26')

여기까지 텔레그램으로 메시지를 보내는 기능을 살펴보았습니다.

파이썬으로 웹페이지 크롤링을 해보자. (1) Django 프로젝트 만들기

Owl Life — Mon, 11 Nov 2019 19:14:50 +0900

들어가며...

파이썬으로 웹페이지의 새로운 게시글을 크롤링하고, Django를 이용해서 DB에 저장하는 실습을 해보도록 하겠습니다.

crontab을 이용해서 주기적으로 크롤링을 실행되도록 하고, 새로운 글이 크롤링 되었을때 텔레그렘이나 슬랙으로 전송하는 기능과 VPS 에서 실행되도록 하는 실습을 진행해보겠습니다.

이번 첫 시간에는 Django 프로젝트를 생성 해보겠습니다. Django 프로젝트와 앱을 만들고, Model을 통해 DB를 생성하고 크롤링 된 데이터를 저장 및 관리자 페이지를 섿업하는것까지 진행해보겠습니다. 만약, Django가 처음이라면 이 링크를 참고 하시면 많은 도움이 될 것입니다.

Python 3.7 버전 설치

Django 설치를 위한 파이썬 최소 버전은 3.7입니다. 만약, 본인의 개발 환경(우분투)에 3.7 버전이 설치되어 있지 않다면 아래 링크를 통하여 설치 후 진행을 권합니다. 만약, 본인이 초급자라면 venv도 설치를 권합니다. 설치 방법은 역시 링크에 포함되어 있습니다.

https://softwaree.tistory.com/85

Ubuntu 16.04에서 Python 3.7 설치

들어가며... django를 사용하려면 Python이 최소 3.7 버전이 설치 되어 있어야 합니다. 하지만 우분투 16.04에서 지원하는 버전은 3.5이기 때문에 추가로 설치를 하여야 합니다. 본인의 PC에 설치되어 있는 버전을..

softwaree.tistory.com

Django 설치하기

python 3.7버전 이상이 설치 되어 있다면 간단한 명령어로 Django를 설치 할 수 있습니다.

$ pip install django

Django 프로젝트 생성하기

django가 성공적으로 설치되면 django-admin 이라는 명령어로 장고 프로젝트를 생성 할 수 있습니다.

이번 포스트에서는 제가 좋아하는 '클리앙' 이라는 커뮤니티의 크롤링을 위하여 ClienCrawlingDjango 라는 이름으로 프로젝트를 만들어보겠습니다.

$ django-admin startproject ClienCrawlingDjango

생성을 완료하면 아래와 같은 폴더 트리를 볼 수 있습니다. (IDE는 PyCharm CE)

장고 앱 생성하기

Django는 프로젝트와 그 안의 앱으로 관리됩니다. 이 앱은 하나의 기능을 담당하는 컴포넌트로 보면 될것 같습니다. 앱은 manage.py 파일을 통해서 startapp이라는 명령어로 생성이 가능합니다. crawled_data라는 이름의 앱을 만들어보겠습니다.

$ python manage.py startapp crawled_data

정상적으로 생성이 되었다면 아래 스크린샷처럼 프로젝트의 구조를 볼 수 있습니다.

생성만으로 끝난게 아니라 이 앱을 Django가 관리하도록 수정 작업을 해야 합니다.

ClienCrawlingDjango 폴더 안의 settings.py 파일의 INSTALLED_APPS에 추가 하여야 합니다.

# Application definition
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'crawled_data'
]

DB 첫 마이그레이션

DB를 사용하기 위하여 최초 1회 마이그레이션을 진행 하여야 합니다. 명령어는 python manage.py migrate 입니다.

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying sessions.0001_initial... OK

crawled_data 앱의 모델 생성하기

DB에 데이터를 저장할 모델을 만들어 보겠습니다. Django에서 모델은 앱 단위로 만들어지고 구성이 됩니다. 앞에서 만든 앱 단위인 crawled_data 안에 있는 models.py파일을 수정해줘야 합니다.

이 모델 파일은 크롤링한 데이터를 필드별로 저장하는것이 목적입니다. 따라서 크롤링한 데이터의 추출할 부분을 미리 파악해서 객체로 만들어주어야 합니다. Django는 NoSQL이 아닌 SQL DB이기 때문에 스키마 정의를 해 주어야 하는데 이 스키마 정의를 별도의 object 클래스로 정의하여야 합니다.

본 실습 프로젝트에서는 requests 라이브러리와 BeautifulSoup4(bs4) 라이브러리를 주로 활용할 계획입니다.

DB에 저장할 데이터는 타이틀과 링크, 고유 ID로 구성하겠습니다. BoardData라는 이름의 Table을 DB에 만들도록 하겠습니다.

django models의 class는 DB의 Table로 변환이 됩니다.

from django.db import models


# Create your models here.
class BoardData(models.Model):
    title = models.CharField(max_length=300)
    link = models.URLField()
    specific_id = models.CharField(max_length=15)

이렇게 만들면 title은 최대 300글자 제한의 CharField로, link는 URLField로, specific_id 는 15글자의 제한의 CharField로 생성됩니다. specific id는 클리앙 게시글에 부여되는 고유 ID로서 최신 데이터인지를 판단하는 기준으로 사용됩니다.

DB Migration

새로운 DB가 추가되었으니 db migration을 진행하여야 합니다. 아래처럼 명령어를 입력하면 DB의 변경 정보를 정리하고, 실제 DB에 반영하는 과정을 진행하게 됩니다.

$ python manage.py makemigrations crawled_data
Migrations for 'crawled_data':
  crawled_data/migrations/0001_initial.py
    - Create model BoardData
(common_env) owllife in ~/PycharmProjects/a/ClienCrawlingDjango
$ python manage.py migrate crawled_data
Operations to perform:
  Apply all migrations: crawled_data
Running migrations:
  Applying crawled_data.0001_initial... OK

마이그레이션을 할 때마다 crawled_data 앱 폴더의 하위에 있는 migrations 폴더를 보면 버전순으로 어떤점들이 변경되었는지를 볼 수 있습니다.

최초로 DB 테이블을 생성하였기 때문에 _initial라는 suffix가 붙어 있습니다. 이 파일들은 makemigrations라는 명령어를 통해 생성이 되고, 실제로 DB에 적용을 할 때에는 migrate라는 명령어를 사용하게 됩니다. 바로 이전에 실행한 명령어들입니다.

클리앙 커뮤니티 크롤링 함수 구현

클리앙의 "모두의 공원" 이라는 게시물에서 "쿠팡"이라는 키워드로 검색후, 새로운 키워드가 있는 경우에만 DB에 추가 해보도록 하겠습니다. ~~(쿠팡 직원 아님)~~

해당 링크와 게시판을 스크린샷으로 살펴보겠습니다.

링크

https://www.clien.net/service/search/board/park?sk=title&sv=%EC%BF%A0%ED%8C%A1

스크린샷

이제 코드를 살펴보겠습니다.

필요한 라이브러리를 설치하겠습니다. 웹페이지의 http 통신을 위해 requests 와 웹페이지를 파싱하는데 유용한 라이브러리인 bs4를 설치하겠습니다.

pip install requests
pip install bs4

프로젝트의 root 디렉토리에 clien_crawler.py 파일을 생성 후 아래와 같이 코딩합니다.

import os
from urllib.parse import urlparse

import requests
from bs4 import BeautifulSoup


def fetch_clien_latest_data():
    result = []

    url = 'https://www.clien.net/service/search/board/park?sk=title&sv=%EC%BF%A0%ED%8C%A1'
    response = requests.get(url)
    html = response.text
    soup = BeautifulSoup(html, 'html.parser')

    web_page_link_root = "https://clien.net"
    list_items = soup.find_all("div", "list_item symph_row")

    for item in list_items:
        # title
        title = item.find("span", "subject_fixed")["title"]

        # link
        page_link_raw = web_page_link_root + item.find("div", "list_title").find("a")["href"]
        page_link_parts = urlparse(page_link_raw)
        normalized_page_link = page_link_parts.scheme + '://' + page_link_parts.hostname + page_link_parts.path

        # specific id
        specific_id = page_link_parts.path.split('/')[-1]

        item_obj = {
            'title': title,
            'link': normalized_page_link,
            'specific_id': specific_id,
        }

        print(title)
        result.append(item_obj)

    return result

링크의 데이터를 soup에서 받아오고, 그 데이터를 파싱 후 리스로 만들고, 루프를 돌면서 title, link 및 specific id 등을 얻어옵니다. specific id는 link에서 파싱을 해서 얻어오는데 게시글에 부여되는 고유 id로 생각하시면 될것 같습니다. DB에 저장 후 계속해서 크롤링을 하게 될텐데 이미 저장된 데이터인지 판단하는 기준으로 사용됩니다.

얻어온 데이터는 item_obj에 dictionary 형태로 저장하고, 리스트로 생성해줍니다. 생성된 리스트는 리턴해서 db에 저장 할 수 있는 상태로 만들어줍니다.

파싱할 규칙은 크롬 브라우저의 '검사' 메뉴를 통해 소스를 볼 수 있으니 알맞은 규칙을 찾아서 파싱 할 수 있습니다. BeautifulSoup4에 대하여 자세히 알아보시려면 따로 구글링을 통해 찾을 수 있습니다.

파싱 메서드가 제대로 동작하는지 확인하려면 해당 메서드에 메인 메서드를 만들어서 호출해서 테스트 할 수 있습니다.

if __name__ == '__main__':
    fetch_clien_latest_data()

실행해보면 아래처럼 출력이 됩니다. 파싱 메서드에 타이틀을 출력하는 코드가 있습니다. '쿠팡' 이라는 키워드로 검색 후 나온 결과물을 그대로 보여준 것을 알 수 있습니다.

오늘 쿠팡이츠 알바뛸껄 그랬어요.ㅋㅋㅋㅋ
쿠팡맨 게임 ㅠㅠ
쿠팡, 더 힘들어 질 듯 합니다...
쿠팡에 이어팟(3.5파이버전) 16950원이네요
쿠팡 로켓배송은 제가 집 앞에 편의점 가는 것보다 빠르네요.
쿠팡 추천상품 보다가...
쿠팡 누적 적자가 3조라는군요
달려라 쿠팡맨 ost는 좋네요
어제 결제한 쿠팡 12% 캐시백 행사 아이폰이 왔습니다
전 이제 쿠팡없으면 못삽니다
자급제 아이폰11% 쿠팡 12% 캐시백에 24개월 무이자할부 떴네요
쿠팡 아이폰11취소했습니다.
미밴드4 정발(쿠팡판) 업데이트 되네요
쿠팡 아이폰 사전예약 무섭게 품절이네요
쿠팡에서 결국 맥북 질렀네요
쿠팡 아이폰이 왔는데
쿠팡 아이폰 내일 도착 확정!
쿠팡 새벽 아이폰프로맥스
쿠팡 로켓직구 쓰면서 불편했던 점
쿠팡이 판매자에게 돈이 바로 안가는지는 몰랐네요...
다른분들은 쿠팡 아이폰 일찍 받으신다는데 저는 그대로네요
쿠팡 아이뻐 내일 온데요
쿠팡 아이폰 제발 내일 ㅠㅠㅠㅠ
쿠팡 아이폰 새벽배송으로 오네요.
쿠팡아이폰이 예정보다 일찍 오네요
쿠팡 상품 가격 히스토리 / 설정가격 알림 / 상품추천 사이트를 제작해봤습니다
쿠팡 로켓프레시 배송은 사랑입니다.
쿠팡 리뷰 보다가 어떤 분이 영양제 테이블 사진을 찍어 놓았는데..
쿠팡 아이폰11 분실건 오늘 연락 안오네요 ㄷㄷ
쿠팡 로켓와우 멤버십이 또 무료체험이네요...?

하지만, 이 함수는 아직 Django에 저장하는 기능을 갖고 있지 않습니다. 따라서 코드를 조금 더 추가 해 주어야 합니다.

실행시 Trouble shooting
문자 encoding 이슈

Django 환경 불러오기

import os
from urllib.parse import urlparse

import requests
from bs4 import BeautifulSoup

os.environ.setdefault('DJANGO_SETTINGS_MODULE', "ClienCrawlingDjango.settings")
import django

django.setup()

os 를 import하고, environ을 설정 후 django를 불러와서 섿업을 하였습니다.

이렇게 추가 후 컴파일 에러가 없다면 정상적으로 Django DB에 저장할 준비가 되었습니다.

Django ORM으로 데이터 저장

이제 models에서 우리가 만들었던 BoardData를 import해 보겠습니다.

django.setup()
from crawled_data.models import BoardData

한가지 주의해야 할점은 django.setup() 이후에 호출하여야 합니다. 그렇지 않으면 django가 초기화 되지 않은 상황에서 model을 불러오려고 해서 에러가 발생합니다.

이제 DB 에 저장하는 코드를 살펴보겠습니다.

def add_new_items(crawled_items):
    last_inserted_items = BoardData.objects.last()
    if last_inserted_items is None:
        last_inserted_specific_id = ""
    else:
        last_inserted_specific_id = getattr(last_inserted_items, 'specific_id')

    items_to_insert_into_db = []
    for item in crawled_items:
        if item['specific_id'] == last_inserted_specific_id:
            break
        items_to_insert_into_db.append(item)
    items_to_insert_into_db.reverse()

    for item in items_to_insert_into_db:
        print("new item added!! : " + item['title'])

        BoardData(specific_id=item['specific_id'],
                  title=item['title'],
                  link=item['link']).save()

    return items_to_insert_into_db

크롤링한 리스트 데이터를 인자로 넘겨 받는 add_new_items라는 메서드입니다. 세 부분으로 나뉘어서 설명해보도록 하겠습니다.

    last_inserted_items = BoardData.objects.last()
    if last_inserted_items is None:
        last_inserted_specific_id = ""
    else:
        last_inserted_specific_id = getattr(last_inserted_items, 'specific_id')

처음에 BoardData 로부터 마지막에 추가된 항목을 불러옵니다. 아무런 데이터가 없다면 "" 로 초기화를 시켜주고, 그렇지 않다면 'specific_id'를 가져옵니다.

    items_to_insert_into_db = []
    for item in crawled_items:
        if item['specific_id'] == last_inserted_specific_id:
            break
        items_to_insert_into_db.append(item)
    items_to_insert_into_db.reverse()

크롤링한 리스트 데이터의 루프를 돌면서 만약 DB에 추가된 specific_id와 동일한 id를 가졌다면 바로 break를 시켜서 루프를 나옵니다. 그렇지 않다면 새로운 항목이므로 DB에 추가할 리스트에 추가를 합니다. 모든 체크가 끝난 이후에 reverse()로 리스트를 뒤집습니다. 오래된 항목부터 DB에 추가하여야 하기 때문에 오래된 항목을 리스트의 가장 앞쪽에 위치시킵니다. DB의 가장 최신 row에는 항상 최신 데이터가 오도록 합니다.

    for item in items_to_insert_into_db:
        print("new item added!! : " + item['title'])

        BoardData(specific_id=item['specific_id'],
                  title=item['title'],
                  link=item['link']).save()

BoardData라는 ORM에 데이터를 추가하는 코드입니다. save() 호출을 하면 정상적으로 DB에 추가가 됩니다.

이제 한번 실행해보겠습니다.

$ python clien_crawler.py

크롤링한 데이터의 제목과 "new item added!! : [title]" 이 쭈욱 보여지면 정상적으로 DB에 추가가 된 상태입니다.

저장된 데이터를 Django Admin에서 확인하기

관리자계정 만들기

Django는 Django Admin이라는 강력한 기능을 제공합니다.

우선 Admin 계정을 하나 생성해야 합니다. createsuperuser 명령어로 생성 할 수 있습니다.

$ python manage.py createsuperuser
Username (leave blank to use 'root'): owllife
Email address: 
Password: 
Password (again): 
Superuser created successfully.

ID 입력 후 email은 입력하지 않아도 됩니다. 비밀번호 두번 입력 완료하면 정상적으로 계정이 생성됩니다.

앱에 Admin 등록하기

Django가 어떤 앱을 admin에서 관리하도록 하려면 앱 폴더(crawled_data) 안에 있는 admin.py 파일을 수정해 주어야 합니다.

from django.contrib import admin

# Register your models here.
from crawled_data.models import BoardData

admin.site.register(BoardData)

Django 서버 실행하기

이제 manage.py 가 있는 위치에서 runserver 명령어로 장고 개발 서버를 실행해 보겠습니다.

$ python manage.py runserver

만약, 특정 port 번호로 실행시키려면 아래처럼 IP:PORT 를 마지막에 추가로 입력하면 됩니다.

$ python manage.py runserver 127.0.0.1:8080

아래와 같이 로그가 출력된다면 정상적으로 서버가 실행된 상태입니다.

$ python manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
November 10, 2019 - 15:48:21
Django version 2.2.7, using settings 'ClienCrawlingDjango.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

이제 http://localhost:8000/admin/ 으로 들어가 보겠습니다.

로그인을 하면 아래와 같은 화면을 볼 수 있습니다.

이전에 생성한 crawled_data 라는 앱 모듈이 보이고 그 아래에 위치한 BoardData라는 테이블이 보입니다. Board datas라고 적힌 테이블을 선택해서 들어가보면 아래와 같이 이미 추가된 항목들을 볼 수 있습니다.

리스트가 보이고 가장 최근에 추가된 항목을 선택하면 아래처럼 추가된 데이터를 확인 할 수 있습니다. BoardData 라는 model에서 추가한 속성들의 값을 여기에서 모두 확인 할 수 있습니다.

TIP

BoardData의 리스트를 보면 이름이 BoardData object (숫자) 와 같이 보여지기 때문에 가독성이 매우 떨어집니다. BoardData model 파일을 조금만 수정하면 아래와 같이 보기 좋게 바꿀수 있습니다.

코드 수정

from django.db import models


# Create your models here.
class BoardData(models.Model):
    title = models.CharField(max_length=300)
    link = models.URLField()
    specific_id = models.CharField(max_length=15)

    def __str__(self):
        return self.title

models.py 파일을 열어서 위와 같이 __str__ 메서드를 오버라이딩 해줍니다. __str__ 메서드의 디폴트는 ClassName + object라는 값을 반환하기 때문에 위와 같이 재정의를 통하여 좀 더 보기좋게 관리자 페이지에서 읽을 수 있습니다.

참고로, models.py 파일을 수정하였지만 DB 테이블 구조가 변경되는 사항이 아니기 때문에 makemigrations나 migrate를 해 줄 필요가 없습니다.

파이썬 버전과 pip 버전 호환이 되지 않아서 발생되는 문제 해결. ImportError: cannot import name 'main'

Owl Life — Thu, 31 Oct 2019 22:38:00 +0900

Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

위 에러 때문에 잠깐 삽질을 하였습니다.

Pycharm IDE에 설정된 python 버전은 3.6인데 콘솔에서 패키지 설치를 위하여 실행한 명령어는 pip 로 하니, 패키지가 제대로 설치되지도 않고 설치 되었다 하더라도 위와 같은 에러가 발생하면서 더이상 실행 조차 되지 않았습니다.

python3-pip를 다시 설치 하였지만 뭔가 버전이 꼬인건지 해결이 안되어서 검색을 좀 해보니 아래 명령어로 해결하였습니다.

python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

출처 : Stackoverflow

Gradle의 root gradle file에서 멀티 프로젝트 관리. subprojects를 이용한 코드 공용화 작업.

Owl Life — Wed, 30 Oct 2019 23:32:56 +0900

안드로이드 앱 개발을 하다보면 모듈화를 위하여 "com.android.library" plugin이 적용된 여러 sub proejct들을 생성하게 됩니다. 그로 인해 build.gradle 파일이 계속해서 추가가 되고 조금만 신경쓰지 않으면 boilerplate code가 기하급수적으로 늘어나게 됩니다. 또한, 같은 외부 라이브러리를 버전만 다르게 각 모듈에서 적용하여 사용하는 경우도 발생하게 되는데 예기치 못한 컴파일 또는 런타임 에러가 종종 발생되기도 합니다.

관리 포인트가 늘어나게되면 유지보수 비용도 증가하게 되므로 최대한 중복 코드를 제거하여 중앙에서 컨트롤 할 수 있도록 빌드스크립트를 구성하여야 합니다. 본 포스팅에서는 프로젝트의 root에 위치한 build.gradle 파일을 수정하여 중복 코드를 삭제 하는 방법에 대하여 설명하고자 합니다.

예제에 사용된 샘플 프로젝트는 총 3개의 library module과 하나의 application module로 구성되어 있습니다.

common_module

view_module

usecase_module

app

module간의 의존 관계는 아래와 같습니다.

view_module과 usecase_module은 common_module에 의존하고 있습니다.

app은 view_module과 usecase_module을 의존하고 있습니다.

common_module - build.gradle

apply plugin: 'com.android.library'

println project.name + " sub project"

단 두줄로 구성되어 있습니다. plugin을 적용하고, task configuration 순서를 보기 위하여 콘솔에 프로젝트명을 보여주는 디버기용 코드입니다.

view_module과 usecase_module의 - build.gradle (동일)

apply plugin: 'com.android.library'

println project.name + " sub project"

dependencies {
    implementation project(':common_module')
}

common_module과 큰 차이는 없습니다. dependencies {}에 common_module을 의존하고 있다는 것을 나타내는 코드 한줄이 추가되어 있습니다.

app - build.gradle

apply plugin: 'com.android.application'

android {
    defaultConfig {
        applicationId "com.owllife.jenkinstestproject"
        versionCode 1
        versionName "1.0"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation project(':usecase_module')
    implementation project(':view_module')

    implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}

application module로서 defaultConfig, buildTypes 등이 추가되어있고, 이 모듈에서만 사용하고 있는 constraintlayout lib 또한 의존성을 두고 있습니다.

각 sub module의 빌드 스크립트 코드가 매우 간결한 것을 볼 수 있습니다. 이제 root에 위치한 빌드 스크립트 파일은 어떻게 구성되어 있는지 한번 살펴보겠습니다.

buildscript {
    repositories {
        google()
        jcenter()
        maven { url "https://plugins.gradle.org/m2/" }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.5.1'
    }
}

subprojects {

    if (project.name == 'app') {
        apply plugin: 'com.android.application'
    } else {
        apply plugin: 'com.android.library'
    }

    repositories {
        google()
        jcenter()
    }

    apply plugin: 'checkstyle'
    task checkstyle(type: Checkstyle) {
        showViolations true
        ignoreFailures true
        configFile file(rootDir.path + "/checkstyle.xml")

        source 'src/main/java'
        include '**/*.java'
        exclude '**/gen/**'
        exclude '**/R.java'
        exclude '**/BuildConfig.java'

        classpath = files()
    }

    println project.name + " - root project"

    android {
        compileSdkVersion 29
        buildToolsVersion "29.0.2"
        defaultConfig {
            minSdkVersion 23
            targetSdkVersion 29
            testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        }

        lintOptions {
            abortOnError false
        }
    }

    dependencies {
        implementation 'androidx.appcompat:appcompat:1.1.0'
        testImplementation 'junit:junit:4.12'
        androidTestImplementation 'androidx.test.ext:junit:1.1.1'
        androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0'
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

subprojects scope를 보시면 일반적으로 많이 보던 코드들이 위치한 것을 확인 할 수 있습니다.

    if (project.name == 'app') {
        apply plugin: 'com.android.application'
    } else {
        apply plugin: 'com.android.library'
    }

이 코드는 android{}와 같은 closure를 읽기 위하여 필수적으로 추가 되어야 plugin입니다.

추가하지 않으면 이런 에러가 발생하게 됩니다.

> Could not find method android() for arguments [build_cl71o7g9m073cw0qlbvvkp09h$_run_closure1$_closure5@13e29c6c] on project ':app' of type org.gradle.api.Project.

plugin 적용 이후부터는 각 sub module에서 사용중인 boilerplate code 성격을 띄는것들을 추가하면 됩니다. 위 샘플에서는 defaultConfig나 lintOptions, dependencies 등을 추가하고 있습니다.

Task Configuration 순서는 어떻게 될까?

task를 configuration하는 순서를 보면 root gradle file에서 subproject 대상 갯수만큼 호출되고, 그 이후에 각 모듈별로 configuration을 진행하게 됩니다. module layer 관점에서 common_module이 가장 상단에 위치한다고 해서 root 와 sub project를 먼저 configuration 하지는 않습니다. 참고로 알아두시면 좋을것 같습니다. 무조건 root가 우선이고 그 다음에 차례대로 sub project의 configuration을 실행합니다.

> Configure project :
app - root project
common_module - root project
usecase_module - root project
view_module - root project

> Configure project :common_module
common_module sub project

> Configure project :usecase_module
usecase_module sub project

> Configure project :view_module
view_module sub project

allprojects와 subprojects 차이점?

일반적으로 대부분의 프로젝트는 subprojects closure를 사용 하면 됩니다.

allprojects closure는 root에 해당하는 프로젝트의 build.gradle 도 함께 실행 시킨다는 의미로 사용이 됩니다.

보통 같은 모듈의 성격을 가지는 여러 library module을 하나의 folder을 만들고 그 하단에 위치시키기도 합니다. 이 때 그 새로 생성한 folder에 build.gradle 파일을 추가하는 경우는 거의 없을 것입니다. (현업에서 한번도 보지 못했고, 필요성을 느끼지 못함)

만약, 이 폴더에 build.gradle 파일을 추가하여 별도의 동작을 수행해야 한다면 allprojects closure에 추가하면 됩니다.

자세한 차이점을 알고 싶다면 권남님의 위키 페이지를 참고 바랍니다.

권남님 위키 : https://kwonnam.pe.kr/wiki/gradle/multiproject

.gitignore 가 정상적으로 동작하지 않을때 해결책

Owl Life — Wed, 30 Oct 2019 01:16:52 +0900

Android Studio로 개발하다보면 파일을 추가하거나 수정할때 .gitignore에 적용된 대상임에도 changes에 자꾸 나오는 경우가 있습니다. git의 캐시가 문제가 되는것이라서 아래처럼 terminal 명령어로 수정할 수 있습니다. git 캐시 문제이기 때문에 android studio IDE 대상 이슈가 아닌 git 사용하는 전체 프로젝트에 해당 될 수 있을것 같습니다.

~~gitignore가 git에 의하여 ignore 되고 있는 아이러니한 상황~~

git rm -r --cached .

// 변경 파일들 다시 추가 후 commit.
git add .
git commit -m "fixed untracked files"

출처 : Stackoverflow

젠킨스의 build description을 커스텀 해보자. [description setter plugin]

Owl Life — Tue, 29 Oct 2019 22:18:39 +0900

젠킨스의 빌드 히스토리에 보여지는 설명 부분을 어떻게 커스텀 하는지 알아보도록 하겠습니다.

사용 용도에 따라 다양한 정보들을 노출 시킬수 있겠지만, 본 포스팅에서는 빌드된 apk 파일명과 용량. 그리고 이전 빌드 산출물 대비 용량이 어떻게 변하였는지를 노출 시켜보도록 하겠습니다.

description setter plugin 설치

플러그인 관리 페이지에 접근 후 "Available" 탭에서 description setter plugin을 검색 후 설치합니다. 젠킨스 재시작까지 완료 하셔야 합니다.

워크스페이스 Configure

워크스페이스의 Configure 메뉴로 진입 후 execute shell에 새로운 항목을 추가해줍니다. 이미 추가된 execute shell 항목이 있다면 그 하단에 추가하여 마지막에 수행 될 수 있도록 합니다.

본 예제 사용한 샘플 스크립트를 첨부하니 참고 바랍니다.

#!/bin/bash -xe
set +x

APK_NAME="app-debug.apk"
FILE_NAME_FOR_APK_SIZE="prev_apk_size.tmp"

# 현재 빌드된 APK 사이즈 계산 (in KB)
CUR_APK_SIZE=$(ls -lk app/build/outputs/apk/debug/$APK_NAME | tr -s " " | cut -d " " -f5)
CUR_APK_SIZE_IN_KB="$(($CUR_APK_SIZE/1024))"

# 이전에 빌드된 APK 사이즈와 비교 후 차이 계산
PREV_APK_SIZE=0
DIFF_APK_SIZE_IN_KB=0
if [ -f "$FILE_NAME_FOR_APK_SIZE" ]; then
    PREV_APK_SIZE=`cat $FILE_NAME_FOR_APK_SIZE`
    PREV_APK_SIZE_IN_KB="$(($PREV_APK_SIZE/1024))"
    
    DIFF_APK_SIZE_IN_KB="$(($CUR_APK_SIZE_IN_KB-$PREV_APK_SIZE_IN_KB))"
fi
echo cur $CUR_APK_SIZE byte
echo prev $PREV_APK_SIZE byte

# 현재 APK 사이즈를 파일에 저장. (in byte)
echo $CUR_APK_SIZE > $FILE_NAME_FOR_APK_SIZE

# Description setter
echo [BUILD_DESCRIPTION] "$APK_NAME $CUR_APK_SIZE_IN_KB"KB "("$DIFF_APK_SIZE_IN_KB"KB)"

다음과 같은 과정으로 스크립트가 실행됩니다.

1. 빌드된 산출물의 apk size를 읽어옵니다. byte 단위로 가져온 후 KB로 치환해줍니다.

2. 이전에 빌드된 산출물의 사이즈가 파일에 저장되어 있다면 사이즈를 읽어온 후에 diff 값을 계산해줍니다.

3. 다음 빌드에 사용하기 위하여 현재 산출물의 사이즈는 다시 "prev_apk_size.tmp" 라는 파일에 저장시켜줍니다.

4. 빌드 히스토리에 보여줄 description을 콘솔에 출력합니다.

콘솔에 출력하는 이유는, 적용된 플러그인이 콘솔에 출력된 텍스트로부터 정규식을 통하여 조건에 해당하는 텍스트를 가져와서 그대로 빌드 히스토리에 보여주도록 되어 있기 때문입니다. "[BUILD_DESCRIPTION]"라는 prefix를 붙인 이유도 정규식에서 이용하기 위함입니다.

이제, Add post-build action 으로부터 Set build description을 선택 후 항목을 추가해줍니다.

정규식 입력란에 아래와 같이 입력해줍니다. 띄워쓰기가 맞지 않아도 제대로 값을 읽어올수가 없으니 주의하셔야 합니다.

\[BUILD_DESCRIPTION\] (.*)

Description은 몇개의 라인을 표시할것인지를 나타냅니다. \1\2\3 과 같이 사용이 가능하며 본 샘플은 한줄만 표시하기에 \1을 입력하였습니다.

저장 후 빌드를 하면 APK 사이즈의 증감을 한눈에 알아 볼 수 있습니다.

단순한 문자 뿐만 아니라 html 태그도 적용 가능한데 이 부분은 추가로 포스팅 하도록 하겠습니다.

Jenkins에 checkstyle plugin 적용하기

Owl Life — Fri, 25 Oct 2019 23:15:06 +0900

프로그래밍하면서 코드 스타일을 체크해주는 유용한 플러그인으로 많은 개발자들이 사용하고 있습니다. 본 포스팅에서는 Android Project에 checkstyle plugin을 적용 후 젠킨스에도 결과를 보여주도록 적용해보겠습니다.

Lint 그래프 아래쪽에 Checkstyle Trend가 표시되는것을 볼 수 있습니다.

차트를 클릭하면 상세 내용을 확인 할 수 있습니다.

해당 항목을 클릭하면 어떤 부분 때문에 검출이 되었는지 확인 할 수 있습니다. 본 검출 내용은 메서드 이름은 소문자로 시작하여야 하는데 대문자로 시작했기 때문에 발생된 에러입니다.

Android 프로젝트에 checkstyle 적용

프로젝트가 한개일 경우에는 app/build.gradle 파일에 적용하면 되고, 여러개의 멀티 프로젝트를 운용하고 있다면 root build.gradle 파일에 아래처럼 추가합니다. checkstyle이라는 태스크를 모든 프로젝트에 적용한다는 의미로 allprojects scope에 추가하였습니다.

apply plugin: 'checkstyle'
allprojects {
    repositories {
        google()
        jcenter()
    }

    task checkstyle(type: Checkstyle) {
        showViolations true
        ignoreFailures true
        configFile file(rootDir.path + "/checkstyle.xml")

        source 'src/main/java'
        include '**/*.java'
        exclude '**/gen/**'
        exclude '**/R.java'
        exclude '**/BuildConfig.java'

        classpath = files()
    }
}

lint와 마찬가지로 checkstyle을 커스텀하여 어떤 항목들을 검출할지 수정이 가능합니다. checkstyle.xml 이라는 파일을 생성후 프로젝트 root에 위치시킵니다. 해당 파일은 이전에 추가한 task의 "configFile file(rootDir.path + "/checkstyle.xml")" 에서 읽어옵니다.

<?xml version="1.0"?><!DOCTYPE module PUBLIC
    "-//Puppy Crawl//DTD Check Configuration 1.2//EN"
    "http://www.puppycrawl.com/dtds/configuration_1_2.dtd">

<module name="Checker">
    <module name="NewlineAtEndOfFile" />
    <module name="FileLength" />
    <module name="FileTabCharacter" />

    <module name="RegexpSingleline">
        <property name="format" value="\s+$" />
        <property name="message" value="Line has trailing spaces." />
    </module>

    <module name="TreeWalker">
        <module name="JavadocStyle" />
        <module name="ConstantName" />
        <module name="LocalFinalVariableName" />
        <module name="LocalVariableName" />
        <module name="MemberName" />
        <module name="MethodName" />
        <module name="PackageName" />
        <module name="ParameterName" />
        <module name="StaticVariableName" />
        <module name="TypeName" />
    </module>
</module>

checkstyle에서 제공하는 모든 규칙들은 아래 페이지에서 확인 가능합니다.

https://checkstyle.sourceforge.io/checks.html

실행

checkstyle task 를 실행하여 바로 결과를 확인 할 수 있습니다.

~/AndroidStudioProjects/JenkinsTestProject2$ ./gradlew clean checkstyle

> Task :app:checkstyle
[ant:checkstyle] [ERROR] /home/allsoft/AndroidStudioProjects/JenkinsTestProject2/app/src/main/java/com/owllife/jenkinstestproject/MainActivity.java:15:18: Name 'TestCheckStyle' must match pattern '^[a-z][a-zA-Z0-9]*$'. [MethodName]
Checkstyle rule violations were found. See the report at: file:///home/allsoft/AndroidStudioProjects/JenkinsTestProject2/app/build/reports/checkstyle/checkstyle.html
Checkstyle files with violations: 1
Checkstyle violations by severity: [error:1]

Jenkins에 checkstyle plugin 적용

젠킨스 홈에서 관리 페이지에 접근 후 plugin 관리쪽으로 진입합니다. 상단에서 "Checkstyle Plug-in" 으로 검색 후 설치하고 젠킨스를 재시작합니다. 그 다음 워크스페이스의 설정 화면으로 진입후 하단에 위치한 Post-build Actions 섹션에서 "Publish checkstyle ...." 항목을 선택하고 report 파일의 경로를 작성해줍니다. html은 안되고 꼭 xml 파일 형식으로만 작성하여야 합니다.

현재 기점으로 해당 액션은 deprecated 되었고, Report Violation 을 사용하여야 하는데 이 부분은 차후에 다시 다루어 보도록 하겠습니다.

Jenkins에 lint plugin 적용하기

Owl Life — Thu, 24 Oct 2019 23:19:39 +0900

정적 분석툴 중에 하나인 lint plugin을 Jenkins에 적용 하는 방법에 대하여 알아보려고 합니다.

Android 프로젝트는 기본적으로 lint task를 지원하고 있기 때문에 별도로 추가를 하지 않아도 사용이 가능합니다.

아래처럼 터미널에 명령어를 입력하면 lint task를 수행 후 report 파일까지 생성해서 결과를 제공해주고 있습니다.

이러한 report file을 jenkins에서 보여주도록 설정만 해주면 손쉽게 사용이 가능합니다.

$ ./gradlew lintDebug

> Task :app:lintDebug
Wrote HTML report to file:///JenkinsTestProject2/app/build/reports/lint-results-debug.html
Wrote XML report to file:///JenkinsTestProject2/app/build/reports/lint-results-debug.xml

Jenkins에 lint plugin 설치

jenkins에서는 plugin을 따로 설치 하여야 합니다.

Manage Jenkins 메뉴로 진입 후 Manage Plugins 화면으로 진입합니다. 그러면 상단에 몇개의 탭이 나오는데 "Available" 탭을 선택 후 "lint" 키워드로 검색을 합니다. 검색 결과에서 "Android Lint Plugin" 을 선택 후 설치를 합니다. 설치 후 jenkins server 재시작까지 한번 하도록 합니다.

Workspace에서 설정

Jenkins의 workspace에서 좌측에 있는 Configure 메뉴를 선택하여 설정 화면으로 진입합니다. gradle task 입력하는 섹션 (Execute shell) 에서 "./gradlew clean assembleDebug lintDebug" 처럼 lintDebug를 마지막에 입력합니다.

그리고 아래쪽에 있는 "Add post-build action" 메뉴 선택 후 Publish Android Lint Results"를 선택합니다.

위 스크린샷처럼 Lint files 에 lint 파일명을 입력합니다. 정확한 경로를 입력하여도 되지만 정규식 표현으로 대략적으로 입력하여도 표시가 가능하니 참고 바랍니다. 위와같이 입력 후 저장하고 빌드를 수행하면 lint task 수행 후 workspace 메인 화면에 그래프 형태로 결과를 보여주게 됩니다. 수정사항을 반영할때마다 lint 결과 갯수에 바로 반영이 되므로 지속적으로 관리하기에 용이합니다.

빌드 에러 발생시?

lint task 수행중에 이슈가 발견되어 빌드가 중지되는 경우에는 아래처럼 옵션을 설정합니다. build.gradle 파일의 android scope에 추가하면 정상적으로 빌드가 진행됩니다.

android {

    .... 중략

    lintOptions {
        abortOnError false
    }
}

lint option 설명 페이지 참고
http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.LintOptions.html

Lint 룰 적용

lint의 많은 rule중에서 필요한 부분만 적용하고 그 이외에는 ignore 시킬수가 있습니다.

app이나 library 프로젝트 내부의 build.gradle 파일이 위치한 곳에 lint.xml 이라는 파일을 아래처럼 작성하면 lint task가 실행될때 lint.xml 파일을 읽은 후 rule대로 처리하게 됩니다.

<lint>
    <issue id="AllowBackup" severity="ignore" />
    <issue id="AaptCrash" severity="ignore" />
    <issue id="AccidentalOctal" severity="ignore" />
    <issue id="AdapterViewChildren" severity="ignore" />
    <issue id="AddJavascriptInterface" severity="ignore" />
    <issue id="AllowBackup" severity="ignore" />
    <issue id="AlwaysShowAction" severity="ignore" />

    ... 생략
</lint>

Lint task 구조

소스 코드 파일과 lint.xml 룰을 이용하여 툴이 동작.

상세 설명 페이지
https://developer.android.com/studio/build/index.html

Jenkins Publickey 에러로 repository 접근할 때 error 발생하는 이슈 해결. (ssh 키 생성 및 등록)

Owl Life — Thu, 24 Oct 2019 00:59:08 +0900

에러 내용

Failed to connect to repository.

Permission denied (publickey).

fatal: 리모트 저장소에서 읽을 수 없습니다.

정상적으로 저장소에 접근이 가능한 경우

원인

public repository라면 url만 입력해도 바로 연동이 되지만 private repository인 경우에는 ssh key를 등록하여야 정상적으로 git 반영이 가능합니다. ssh 키 생성 및 repository에 등록하는 과정을 알아보도록 하겠습니다.

인증키 만들기

인증키는 ssh-keygen으로 생성한다.

$ cd ~/.ssh
$ ls

만약 id_rsa / id_rsa.pub 와 같은 키 쌍이 존재한다면 키 생성없이 바로 등록 과정을 거쳐도 됩니다.

// 없는 경우에는 키 생성
:~/.ssh$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/allsoft/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/allsoft/.ssh/id_rsa.
Your public key has been saved in /home/allsoft/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:KxoQ6MNVJZh3pWqUsbObfl9d4zavt6ruK2+D5jIO4q0 allsoft@allsoft-ubuntu
The key's randomart image is:
+---[RSA 2048]----+
|    o+....       |
| . o..=..        |
|. ...=..         |
|o ... +          |
| +.  +  S      o |
|  ... o  .  . o .|
|   ..+. . .. . + |
|  . +o.= +.o  . +|
|   Eooo.*o**+.o+o|
+----[SHA256]-----+

// 키 생성시 비밀번호는 입력하지 않아도 됩니다.

인증키를 메모리에 상주 시키고 키 등록

~/.ssh$ eval $(ssh-agent -s)
Agent pid 9071
~/.ssh$ ssh-add ~/.ssh/id_rsa
Identity added: /home/allsoft/.ssh/id_rsa (/home/allsoft/.ssh/id_rsa)

ssh-agent 를 이용하여 인증키를 메모리에 상주시켜두면 한번만 인증키 암호를 입력하면 다음부터는 입력하지 않아도 같은 인증키를 사용하는 모든 서버들에 접속 할 수 있습니다.

private repository의 설정에 ssh 키 등록

방금 생성한 public key를 repository의 설정에 등록합니다. 등록하면 젠킨스에서 바로 접근이 가능합니다.

본 예제의 경우에는 gitlab에서 테스트를 하였기 때문에 gitlab의 settings에서 키를 등록해줍니다.

gitlab.com의 User settings(profile) 진입 후 SSH Keys 선택

입력할 public key는 아래처럼 command로 확인 가능. 복사 해서 붙여넣기 후 저장합니다.

allsoft@allsoft-ubuntu:~/.ssh$ cat id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC........ allsoft@allsoft-ubuntu

Jenkins Credentials 추가

jenkins 워크스페이스 설정에서 repository url 입력시 private key를 선택하도록 합니다.

- Kind에서 SSH Username with private key 를 선택

- ID 및 username는 입력하지 않음.

- Description은 키 이름 입력

- Private Key에서 직접 입력을 선택 하고 Add Key 버튼 선택 후 private key를 직접 입력합니다.

- Passphrase는 키 생성시 입력하지 않았으므로 빈칸으로 비워둡니다.

- Add 버튼 클릭

Credentials 선택

위에서 생성한 키를 선택후 잠시 기다리면 정상적으로 접근이 가능하다는 표시로 에러 문구가 사라집니다.

이제부터 정상적으로 저장소에 접근이 가능합니다.

deal with와 handle 차이점.

Owl Life — Thu, 24 Oct 2019 00:08:59 +0900

deal with

- 누군가와 거래를 한다. (+someone)

- 어떤 문제나 방해 요소를 없애거나 고침으로써 그 상황을 해결하는. 사람과 거래를 한다는 의미로 씀.

- 문제가 되는 사람을 대상으로 하여 해결을 본다.

- 책이나 영화에서 어떤 내용을 다룬다.

- 어떤 사람이 질병이나 증상을 시간이 지나면서 겪고 치료하기 위해 노력해 나가는 과정.

- with가 있으므로 누군가와 의사소통을 통해서 해결을 보려는 느낌.

I usually deal with patients with depression.

저는 우울증을 앓고 있는 환자들을 주로 다룹니다.

handle

- 감당할 수 있다는 의미가 강함.

- 좀 더 표면적인 의미에서 뭔가를 다룰 때 씀.

- 물건에 대해 얘기할 때 쓰기 좋음

- 통제한다는 의미에 가까움. 그러므로 사람에 관해 얘기 할 때에는 조심해야 함. (일방적은 느낌이 있음)

You can borrow my car if you handle a stick.

너 스틱 다룰 줄 알면 내 차 빌려도 돼.

I think i can handle it.

내 생각에 다룰 수 있을것 같아.

apply 의 또 다른 의미에 대하여 알아보자.

Owl Life — Wed, 23 Oct 2019 23:51:15 +0900

apply

적용시키다 / 적용하다

The same principle can be applied to pretty much any skill or profession.

같은 원칙이 적용이 될 수 있다. 그 어떤 기술이나 직업에도

많이 사용되는 다른 의미

바르다

Apply just a small amount on the wound.

약을 상처에 바르다.

Apply plenty of lotion ...

로션을 바르다.

해당된다

There are no exceptions.

예외는 없다.

This policy applies to all employees.

이 정책은 모든 직원에게 해당된다. (적용된다.)

Jenkins에서 Github 저장소에 있는 Gradle 기반의 Android 프로젝트 생성하기

Owl Life — Thu, 17 Oct 2019 23:03:46 +0900

사전 조건

android sdk 설치 및 경로 확인
ex) /home/allsoft/tools/android-sdk

ANDROID_HOME 환경변수 설정

1. Jenkins의 Manage Jenkins 메뉴 선택

2. 상단에 있는 Configure System 메뉴 선택

3. Global properties 섹션에 있는 Environment variables 체크

4. Add 선택

5. Name에 ANDROID_HOME 입력

Value에 android sdk 경로 입력 (ex. /home/allsoft/tools/android-sdk)

6. SAVE

WORKSPACE 생성

1. Jenkins 홈에서 새 항목 생성

2. 항목 이름 입력 및 "Freestyle project" 선택

3. 소스코드 관리쪽에서 Git 선택 및 repository url 입력. 브랜치는 디폴트가 master이고 다른 브랜치도 입력 가능.

Trouble Shooting

만약 private 저장소를 이용하고 있다면 ssh 키 등록을 해야 하는데 하기 링크 참고

https://softwaree.tistory.com/66

4. Build 섹션에서 Add build step 선택 후 Execute shell 선택.

- Gradle 빌드라서 "Invoke Gradle script"를 선택하면 별도의 추가 작업이 필요하므로 선택하지 않고

자유도가 높은 "Execute shell" 선택.

- Android Studio 의 터미널에서 빌드하는것과 같은 command를 그대로 입력.
gradle wrapper를 통해 빌드하므로 ./gradlew를 입력하고, 실행할 task들 입력.

5. APK 산출물이 보이도록 설정

6. "SAVE" 선택 후 좌측의 "Build Now" 클릭. 좌측에 Build Histroy에서 빌드 진행 확인.

7. 빌드가 완료되면 artifacts(APK) 확인.

우분투 18.04 젠킨스 설치

Owl Life — Thu, 17 Oct 2019 20:37:44 +0900

1. 자바 설치 확인 (링크)

2. apt-get 을 이용하여 Jenkins 설치.

저장소 key 다운로드 및 sources.list에 추가.

$ wget -q -O - https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add -
OK
$ echo deb http://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list
deb http://pkg.jenkins.io/debian-stable binary/

apt-get 업데이트 및 jenkins 설치

$ sudo apt-get update
$ sudo apt-get install jenkins

3. 다른 서비스에서 젠킨스 기본 포트인 8080을 이미 사용하고 있다면 포트를 변경해야 합니다.

$ sudo vi /etc/default/jenkins

HTTP_PORT=8080

윗 부분을 찾아서 포트 번호 변경.

4. 젠킨스 서비스 재시작.

$ sudo service jenkins restart

+ 젠킨스 서비스 상태 확인. Active 상태인지 확인.

owllife@owllife-ubuntu:~$ sudo systemctl status jenkins
[sudo] owllife의 암호: 
● jenkins.service - LSB: Start Jenkins at boot time
   Loaded: loaded (/etc/init.d/jenkins; generated)
   Active: active (exited) since Thu 2019-10-17 20:35:53 KST; 3min 57s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 9369 ExecStop=/etc/init.d/jenkins stop (code=exited, status=0/SUCCESS)
  Process: 9417 ExecStart=/etc/init.d/jenkins start (code=exited, status=0/SUCCESS)

10월 17 20:35:51 owllife-ubuntu systemd[1]: Starting LSB: Start Jenkins at boot time...
10월 17 20:35:52 owllife-ubuntu jenkins[9417]: Correct java version found
10월 17 20:35:52 owllife-ubuntu jenkins[9417]:  * Starting Jenkins Automation Server jenkins
10월 17 20:35:52 owllife-ubuntu su[9459]: Successful su for jenkins by root
10월 17 20:35:52 owllife-ubuntu su[9459]: + ??? root:jenkins
10월 17 20:35:52 owllife-ubuntu su[9459]: pam_unix(su:session): session opened for user jenkins by (
10월 17 20:35:52 owllife-ubuntu su[9459]: pam_unix(su:session): session closed for user jenkins
10월 17 20:35:53 owllife-ubuntu jenkins[9417]:    ...done.
10월 17 20:35:53 owllife-ubuntu systemd[1]: Started LSB: Start Jenkins at boot time.

5. 브라우저(크롬 등)를 열고 "http://localhost:8080/" 입력. (포트 번호 맞춰서)

6. 처음 접속시 한번에 한해서 admin password 입력해야 함.

비밀번호 확인은?

$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword

비밀번호 확인 후 웹브라우저에 입력.

7. 추천 플러그인 설치.

(시간 좀 걸림)

8. 첫 관리자 계정 생성.

이것저것 정보 입력 후 하단에 있는 "Save and continue" 선택.

9. 만약 웹페이지가 정상적으로 보이지 않는다면 젠킨스 서비스 재실행(5~6번 과정) 후 웹페이지 다시 접속.

8번에서 생성한 관리자 계정으로 로그인.

must have 를 제대로 이해해봐요.

Owl Life — Tue, 15 Oct 2019 22:42:05 +0900

must have : 학교에서 보통 "~ 했음에 틀림 없다" 로 배움. 이건 잘못된 표현..

* must have

1. ~했나봐

2.~했던 모양이야

3.~했겠다

친구랑 밥을 먹고 있는데 정말 허겁지겁 먹고 있는 상황. 어떤 말을 하면 될까요?

"너 정말 배 고팠음에 틀림 없다" 라고 이해하면 매우 어색.

"너 정말 배 고팠나봐~~!!" 로 해석하는게 훨씬 자연스러움.

Wow, you must've been really hungry, dude!!

너 정말 짜증났겠다!!

You must've been really frustrated!!

교통사고가 발생했나봐.

There must've been a traffic accident.

제 친구 중 하나가요. 최근에 일을 그만뒀어요.

One of my friends recently quit her job.

글쎄요. 뭐.. 상사랑 문제가 좀 있었나보죠?

I don't know. She must've had some problems with her boss.

그게 아니라면 갑자기 몸이 안좋아졌던거일 수도 있어요.

Either that or, he might've had some health problems.

어쨌든, 걔가 그 일이 질려서 그랬었을리가 없어.

Either way, it couldn't have been because he was sick and tired of the job.

couldn't + have + been

{couldn't've been} 발음.

배고파서 그래.

심심해서 그래.

졸려서 그래.

~~~해서 그래.

보통 "It's because + <....> 로 표현.

is 자리에 couldn't have been 을 넣으면 됨.

영어회화. "내가 알기로는", "내가 듣기로는", "내가 보기에는" 표현법

Owl Life — Mon, 14 Oct 2019 21:19:27 +0900

내가 알기로는, ... (보고형식)

as i know....... (완전히 틀린 표현)

as far as I know (understand) 가 정확한 표현

...based on +

...according to +

To my knowledge, ....

Based on what i know, ...

According to what i know, ...

"As far as i know, that movie is releasing this week."

내가 듣기로는, ... (보고형식)

from what i hear (현재형. 현재도 계속 이어져서 듣고 있는중인...)

from what i heard (과거형.)

From what i hear, he bought a new car.

내가 보기에는, ... (내 관점, 판단 형식)

The way I see it,

내가 보기에는 타이밍의 문제였어.

The way i see it, the timing was the problem.

내 생각에는

in my thinking (틀린 표현)

원어민들이 사용하는 표현. so와 that's why의 차이점 / "누구에게 무엇을 주다" 표현.

Owl Life — Sun, 13 Oct 2019 22:53:31 +0900

that's why

폰 배터리가 다 되어 꺼졌어. 그래서 전화 못한거였어.

"그래서" 를 보통 so 를 사용하는데 잘못됨.

that's why 사용이 맞음.

이유 설명. (해명 하는 상황)

My phone ran out of battery. That's why I couldn't call you.

어떤 일이 일어나서 대처하는 행위 설명 할때 사용. 인과 관계.

손을 다쳤어. 그래서 병원에 갔어.

I hurt my hand. So I went to the hospital.

--------------------------------------------------------

누구에게 무엇을 주다

부모님에게 돈을 드렸어요.

보통 아래처럼 사용하지만, 잘못된 사용.

I gave some money to my parents.

맞는 표현

I gave my parents some money.

대명사가 있는 경우에는 대명사를 먼저 말하고, 아닌것은 뒤로 배치 하는게 일반적으로 사용하는 표현.

I gave them some money.

하지만, 둘다 대명사인 경우에는 아래처럼 사용함.

I gave it to them

출처 : 유투브 라이브 아카데미

[영어회화] instead of ~ 와 for ~ 차이점

Owl Life — Sat, 12 Oct 2019 22:51:15 +0900

instead of me

대신 ~을 하다

이익이나 혜택이 여러사람에게 갈때 사용

우리 발표자가 갑자기 아파서 제가 대신 발표를 하게 됐어요.

Our presenter suddenly got sick

so i had to give the presentation instead of her.

> 팀 프로젝트는 개인이 아니라 여러명이 속해있고, 다수가 결과에 영향을 받기 때문에 for ~가 아닌 instead of ~를 사용해야 함.

~가 아니라 / ~ 말고

Hey, can i get the salad instead of the soup?

"instead of + ing" 형태도 많이 사용됨.

I arrived a little early so instead of just waiting, I looked around the neighborhood.

조금 일찍 도착해서 그냥 마냥 기다리는 대신 동네 구경을 좀 했어.

for me

대신 ~을 해주다.

이익이나 혜택이 한사람(개인)에게 갈때 사용

내가 시간이 안될거 같아서 그러는데,

이 책 나 대신에 좀 반납해줄래? 내가 나중에 밥사줄게.

Could you return this book for me?

(x) instead of

"대신 좀 받아줘(받아줄래?)"

Hey, I'm cooking right now. Can you get that for me?

[영어회화] 누구를 비난하다 / 누구를 탓하다 의 차이점.

Owl Life — Sat, 12 Oct 2019 22:36:28 +0900

Blame

~을 탓하다, ~책임으로 보다.

Don't blame me.

내 탓하지마.

Criticize

누구를 비난하다

The athlete was criticized by people for taking drugs.

그 운동선수는 약물 복용을 해서 사람들로부터 비난을 받았다.

You have no right to criticize me.

너는 나를 비난할 권리가 없어.

It's easy to criticize others.

남의 말 하기는 쉽다.

[영어회화] by와 until에 대하여 정확히 알고 사용하기.

Owl Life — Fri, 11 Oct 2019 20:33:48 +0900

■ until

무엇을 언제까지 지속적으로 반복해서 그때까지 완료하다.

I'm going to study until 10 o'clock.

I have to finish this until 2 o'clock.

2시까지 끝내고 또 끝내고 계속 끝내다. 올바른 의미가 아님.

Hey, let's wait until 6 o'clock.

6시까지 (계속해서) 기다리자.

And if she's not have until then we can just leave without her.

만약 그녀가 오지 않으면 그녀 없이 출발하자.

■ by

"~까지 끝내야 돼" - 기한

(그 전에 끝내면 더 좋다.)

I have to submit this by Wednesday.

나 이거 수요일까지 제출해야 해. (그 전에 제출하면 더 좋음)

I have to finish this by the end of the day today.

나 이거 오늘까지 끝내야 해.

I have to be in Jongro by 2 o'clock.

나 2시까지 종로에 가야해.

미국인들이 자주 사용하는 실생활 표현 : for ~ing 표현 | 다른데, 딴데, 다른사람, 다른거 등 표현

Owl Life — Thu, 10 Oct 2019 23:26:42 +0900

■ for ~ing 은 용도! 를 의미, 존재의 목적 (~용)

~을 하기 위해’ 라는 의미가 아니다. (의도)

이 버튼은 볼륨을 조절하기 위한거야.

This button is for adjusting the volume.

노트를 작성하려고 이 노트북을 샀어.

I bought this notebook for taking notes.

이 케익은 먹기 위한게 아니야. 장식용이야.

This cake is not for eating - it’s for decorating.

내 지갑안에, 동전을 가지고 다니기 위한 작은 지갑이 있어.

In my wallet, there is a small pocket for carrying coins.

나는 영어 공부하려고 매일 여기에 와. (용도 X) (의도)

I come here to study English.

나는 사람들이 그들의 영어실력을 올리는 것을 돕기 위해 이 비디오들을 만들어. (용도 X) (의도)

I make these videos to help people improve their english.

■ 딴데로 | 다른데 | 다른거 | 다른사람

딴: some other ~

딴걸로: something else

■ 딴데로 갔어

틀린 표현: other place, another place

another place 가 안돼는 이유는 이건 기존것이 있고 또 추가하는 느낌

맞는 표현: somewhere else, some other place.

거기를 갔는데 사람이 너무 많아서 딴데로 갔어.

We went to the restaurant and there were too many people, so we went to somewhere else.

■ 딴걸로

something else, some other model

■ 딴 사람

someone else, some other person, some other man

그녀는 그와 헤어지고 바로 다른 사람을 만났어.

Right after she broke up with him, she immediately met someone else (some other guy).

■ 딴 방법

some other way

someway else (불가능, 없는 단어)

우리는 다른 방법을 찾아야해.

I think we need to find some other way.

■ 딴 이유

some other reason

someway else (불가능, 없는 단어)

■ 딴 때

some other time

sometime else (불가능, 없는 단어)

출처: 유투브 라이브아카데미

미국인들이 자주 사용하는 자연스러운 표현 : 시간 / Home / Diet

Owl Life — Thu, 10 Oct 2019 22:06:49 +0900

1. 시간 표현

전치사 붙여서 말하지 말자. (in, on, at 등)

일주일 내내

all week

이번주 (일주일) 내내

all week + this week

all this week

평일에

on weekdays

월~금 5일이나 있어서 복수 사용해야 함.

주말에

on weekends

주말도 이틀. 복수형.

ex) 나 주말에는 그냥 집에 있어.

I just stay home on weekends.

이번주에

this week

다음 주에

next week

지난 주에

last week

2. Home 표현

House는 주택이라고 인식하므로 주택과 아파트는 구분하여 말해야 함.

House : 주택 / Apartment : 아파트

place 를 집 대신에 쓰기도 함. (미국인들이 많이 사용하는 단어) 집인지 아파트인지 굳이 구분할 필요가 없는 상황에 사용됨.

얘들아, 수잔네 집에 가서 놀자~

Hey, let's go over to Susan's place and hang out there.

go home

"집에 가다" 표현. go home 자체를 하나의 동사로 보는게 좋음. go to home과같이 전치사 붙이지 말자.

I'm going to go home.

I have to go home.

leave home 집에서 나오다/출발하다

go home / get back home / go back home 집에 돌아가다

3. Diet

앞으로 다이어트를 할 거다

go one a diet

I'm going to go on a diet from next week.

다이어트를 하고 있다. / 하는 중이다.

be on a diet

I'm on a diet.

Are you on a diet now?

I was on a diet until last week.

얼마나 됬니? How long has it been?

살찌다

gain weight

살빼다

lose weight

gain 2kg.

lose 5kg.

I've lost 2kg so far.

I want to lose weight.

Wow, you've lost a lot of weight.

안드로이드 Dalvik과 ART, JIT과 AOT 차이점

Owl Life — Wed, 9 Oct 2019 21:01:20 +0900

apk를 설치하면 실행파일의 경우 storage에 dex 파일로 저장됩니다. dex 파일은 byte code로 이루어져 있기 때문에 이를 실행하려면 단말의 cpu에 맞게 machine code로 변환하여야 합니다. 이 machine code로 프로그램을 실행할 수 있기 때문입니다. 코드 변환에는 비용이 발생하기 때문에 어떤 방식으로 변환하느냐에 따라서 크게 JIT과 AOT로 나뉩니다. 이 두 방식은 안드로이드에 국한되는것이 아니라 다른 Language에서도 사용되는 일반적인 컴파일 방식입니다.

■ Dalvik

JIT (Just In Time) 컴파일 방식을 사용합니다.

※ JIT의 주요 특징

앱이 실행되는 순간 자주 사용되는 바이트 코드를 컴파일하여 Machine Code로 변환 후 캐싱하여 RAM에 올립니다.
화면 전환 또는 앱이 실행 될 때마다 필요한 코드를 실시간 컴파일 하기 때문에 그 시간만큼 사용성에 있어서 latency가 발생할 수 밖에 없습니다.
컴파일이 빈번하게 발생되기 때문에 RAM 점유율, 배터리 소모량 증가 등의 이슈도 있습니다.
장점으로는, AOT 대비 APP 설치 시간이 매우 빠릅니다. 설치 할때 컴파일을 하지 않기 때문입니다.
AOT 대비 앱 용량이 작습니다.

※ DVM에서의 실행 과정

■ ART

AOT(Ahead Of Time) 컴파일 방식을 사용하고 Android Kitkat 버전에 도입된 새로운 앱 실행 환경입니다. JIT의 단점들을 보완하여 큰 성능 향상을 가져왔습니다.

※ AOT의 주요 특징

Android Kitkat 버전에 도입된 ART (Android Runtime) 에서 사용되는 컴파일 방식입니다.
앱 설치 할때 모든 코드를 Machine Code로 변환 후 ROM에 저장합니다.
앱 설치 속도가 JIT에 비하여 매우 느립니다.
앱 실행시 컴파일을 하지 않아도 되기 때문에 컴파일로 인해 발생될수 있는 latency가 없어서 매우 빠릅니다.
미리 컴파일 후에 ROM에 저장하기 때문에 용량이 큽니다. (JIT 대비 보통 1.5배 ~ 최대 2배)

최적화 작업으로 인하여 JIT과 AOT가 각각 도입되었다가 Android N 버전부터는 둘다 사용되는 하이브리드 형태로 운용되고 있습니다.

※ ART에서의 실행 과정

미국인들이 실제 자주 사용하는 "오랜만에", "~한지 너무 오래 됐어요." 자연스럽게 표현하기

Owl Life — Tue, 8 Oct 2019 23:17:14 +0900

오랜만에

ex) 오랜만에 친구들을 만났어요

-> "오랜만에"의 의미를 정확히 파악해야 함.

■ 오랜만에 만나는 친구들

오랫동안 만나지 않았던 친구들을 만났어.

I hung out with some friends who I hadn't seen in a long time.

■ 친구들을 만나는 것 자체가 오랜만인 것

I hung out with some friends, which I hadn't done in a long time.

handn't done : 친구를 만나는것을 하지 않았다 는 것을 의미.

오랜만에 커피숍에 가서 책을 읽었어.

I went to a coffee shop and read a book, which I hadn't done in a long time.

= I went to a coffee shop and I read a book. I hadn't done that in a long time.

저녁에는 오랜만에 외식을 했어.

We ate out for dinner, which we hadn't done in a long time.

= We ate out for dinner. we hadn't done that in a long time.

오랜만에 쇼핑을 갈거야.

We're going to go shopping, which we haven't done in a long time.

= We're going to go shopping. we haven't done that in a long time.

오랜만에 영화 보러 가고 싶다.

I really want to go to the movies, I haven't done that in a while.

야, 오랜만에 피자나 시킬까?

Hey, do you want to order a pizza? We haven't done that in a while.

~한지 오래 됐어요.

long time 보다 for a while을 더 많이 사용. long time 은 정말 오래 된거 같은 늬앙스.

친구들을 만난지 너무 오래 됐어요.

It has been a while since I hung out with my friends.

이번 주말에 오랜만에 친구들을 만나기로 했어요.

I'm hanging out with my friends this weekend.

I haven't seen them in a while / in such a long time.

우리 오랜만에 어디어디 가볼까?

"Hey, do you want to go to that Chinese place? (for the first time in a long time : NO!!!!)

We haven't been there in a while."

출처 : 유투브 라이브 아카데미

미국인들이 실제 자주 사용하는 표현 : ~하는 김에 / 어차피..이왕 ~하는거 / 부탁 좀 할게

Owl Life — Mon, 7 Oct 2019 22:59:46 +0900

■ "나 지금 은행에 좀 다녀올게. 30분 정도 걸릴거야."

Hey, I'm on my way to the bank. I'll be back in about half an hour.

흐름을 자연스럽게.. "It's going to take about half an hour" 를 사용하면 연결성이 부족함.

■ 아, 너 나가는김에 코드 연장선 좀 사다줄래?

Oh, while you're out, could you pick up an extension cord for me?

- while you're out (나감 김에)

- on your way out (나가는 길에)

■ 그래, 돌아오는 길에 슈퍼에 잠깐 들르지 뭐.

Sure, I can stop by a supermarket on my way back.

stop by = drop by = swing by

좀 더 자연스러운 표현

Sure, I guess I can stop by a supermarket on my way back.

■ 아, 그리고 너 그거 사러 간 김에 나 필요한게 몇 가지 사실 더 있는데, 부탁 좀 할게

Oh and, while you're at it, I actually have a few more things I need

+ if you don't mind

좀 더 공손한 표현 : If it's not too much trouble

(~을) 하는 김에

while you're at it

거기 있는 동안에

while you're there

■ 어차피, 살거 좀 있으면 그냥 같이 가자.

If you have some things to buy, you might as well + just + come with me.

come with me = come along

출처 : 라이브 아카데미 유튜브

미국인들이 실제 자주 사용하는 표현 : "저 요즘 드라마를 하나 보고 있어요"

Owl Life — Mon, 7 Oct 2019 22:24:40 +0900

"저 요즘 드라마를 하나 보고 있어요."

> Lately, I've been watching a tv show

■ These days 대신 Lately 사용.

why? 보통 these days와는 단순 현재형 시제를 쓰는 경우가 많음)

These days, I'm ...ing

ex) I used to work with a small group but these days, I'm working with almost 20 other employees.

■ drama 대신 a tv show 사용.

"드라마" 키워드 사용은 조심해야 함. 티비나 영화도 하나의 장르로 드라마가 사용됨.

AndroidQ 다크테마 적용방법

Owl Life — Fri, 27 Sep 2019 00:32:04 +0900

안드로이드 Q의 새로운 피처인 다크테마 적용 방법에 대하여 알아보겠습니다.

시스템에서 다크테마 적용은 설정 - 디스플레이 메뉴에서 적용이 가능합니다.

앱에서는,

1. style - theme의 parent를 Theme.AppCompat.DayNight 로 수정

    <style name="AppTheme" parent="Theme.AppCompat.DayNight">
        <!-- Customize your theme here. -->
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
    </style>

2. theme의 parent를 DayNight 로 설정하지 못하는 경우에는 android:forceDarkAllowed 속성 추가

    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <!-- Customize your theme here. -->
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
        <item name="android:forceDarkAllowed">true</item>
    </style>

3. 코드 레벨에서 강제로 ON/OFF

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        findViewById<View>(R.id.change_mode_btn).setOnClickListener { toggleNightMode() }
        renderModeState()
    }

    fun renderModeState() {
        var output: TextView = findViewById(R.id.output_tv)
        val currentNightMode = resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK
        if (currentNightMode == Configuration.UI_MODE_NIGHT_NO) {
            output.text = "NIGHT_MODE_OFF"
        } else if (currentNightMode == Configuration.UI_MODE_NIGHT_YES) {
            output.text = "NIGHT_MODE_ON"
        }
    }

    fun toggleNightMode() {
        val currentNightMode = resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK
        if (currentNightMode == Configuration.UI_MODE_NIGHT_NO) {
            AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES)
        } else if (currentNightMode == Configuration.UI_MODE_NIGHT_YES) {
            AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_NO)
        }
    }
}

configuration에서 uiMode 값의 마스킹을 통해서 현재 앱이 night mode가 적용되어있는지 아닌지를 읽을 수 있습니다.

public static final int UI_MODE_NIGHT_NO = 16;

public static final int UI_MODE_NIGHT_YES = 32;

이 값에 따라서 나이트 모드를 적용할 것인지는 AppCompatDelegate.setDefaultNightMode api를 사용하면 적용이 가능합니다.

<나이트 모드 OFF>

<나이트 모드 ON>

전체 소스코드

https://github.com/allsoft777/AndroidQ-DarkTheme