sfex tistory blog

20201220

​

어제는 프로그램을 짜는데 해야 할 일 목록을 작성하고는 옆길로 샛다.

​

흔들리지 않고 즐거운 마음으로 처음부터 끝까지 몰입해서 프로그램을 완성시키는 방법은?

​

- 자고 일어났을 때처럼 깨끗해진 마음

- 최근에 입력된 자극, 단어 중 지금 목표와 관련이 적고 예전 관심사와 관련된 것,

당장 실행해야 하는 것은 아니지만 목표와 관련 있다고 유혹하는 것들을 처리하는 법,

우선 순위 정하고 미루는 법

- 코끼리를 생각하지 말아야 할 때 외우는 주문, 걱정거리나 잡념을 지우는 주문, 지금 실천하고 목표하는 것 되뇌기

- 프레임 좋은 습관 태도

- 지루한 그림과 글을 완성하는 힘, 태도, 마음가짐

- 목표와 그에 따른 하위 목표들 세우기

- 우선순위 정리, 정돈, 청소

- 코멘트, 주석과 실행 코드 번갈아 작성

- 주기적인 휴식, 충전, 동기부여, 자극, 명상

​

글을 완성하는 방법

​

https://m.hibrain.net/braincafe/cafes/1001/posts/321/articles/49701

​

대개 글쓰기를 싫어하는 미숙한 필자들은 일단 글쓰기를 시작해야 하는 단계가 되면 첫 문장을 시작하는 데에 상당한 어려움을 겪는다.

시행착오 전략에 따라 첫 문장을 쓰는 데에 많은 시간을 소비하는가 하면, 대번에 완벽한 초고를 써야 한다는 강박증으로 어려움을 겪기도 한다.

또 자료 수집이나 수집된 자료를 바탕으로 한 메모 없이 글을 써야 하기 때문에 순간순간 떠오르는 생각에만 의존해서 글을 쓸 수밖에 없다.

미숙한 필자들은 대개 글쓰기를 일련의 과정과 절차에 따라 수행하기보다는 글을 쓰는 데에 거의 시간을 들이지 않으면서 앉은 그 자리에서 떠오르는 생각을 중심으로 글을 완성해 버린다.

항상 시간에 쫓겨서 글쓰기를 시작하기 때문에 글을 꼼꼼히 고쳐 쓰는 경우가 거의 없으며 대개 초고가 그대로 제출본이 된다.

​

능숙한 필자의 쓰기 과정

​

- 글쓰기 과정 자체를 일련의 목표 지향적 활동으로 파악한다.

- 작업 구상 단계부터 자기 나름대로 목표 의식을 가지고 글의 핵심적 주제를 설정하고 이를 중심으로 사고의 흐름을 전개해 나간다.

- 일단 글쓰기의 주제와 방향이 잡히면 충분한 시간을 두고 일찌감치 글쓰기 과정에 착수하여 계획하기 단계에 많은 시간과 공을 들인다.

- 주제와 관련된 충분한 자료를 전략적으로 찾아서 읽고 이를 바탕으로 틈틈이 메모를 하고 개요를 작성한다.

- 머릿속에 있는 막연한 사고를 자료를 찾아서 읽어 나가는 과정을 통해서 더욱 구체화하는 것이다.

- 전략적인 사고를 하고 이를 바탕으로 글의 가닥을 잡아 나간다.

- 첫 문장을 어떻게 써야 할까를 고심하기보다는 고쳐 쓰기 단계를 염두에 두고 글에서 해야 할 이야기들의 내용을 중심으로 일단 초고 형태로 글을 쓴다.

- 글의 개요와 메모에 의지해서 글을 쓰기 때문에 글이 좀처럼 원래 목표했던 중심 생각에서 벗어나 엉뚱한 방향으로 나아가지 않는다.

- 능숙한 필자들은 계획하기 단계 못지않게 고쳐 쓰기 단계에 많은 시간을 들인다.

- 의미 구성 행위를 본질로 하는 글쓰기 능력은 단순히 의미를 문자 언어로 표현하고 전달하는 차원을 넘어서서 쏟아져 나오는 정보를 처리하고 이를 바탕으로 유용한 지식을 새롭게 창출해 내는 지식 생산 능력의 의미까지도 포함

- 표현 능력의 하나인 글쓰기 능력은 자신의 생각을 논리적인 언어로 정확하고 설득력 있게 전달할 수 있는 의사소통 능력일 뿐만 아니라 사고를 언어로 옮겨서 표현해 내는 고등 정신 기능을 바탕으로 하는 고차원적인 문제 해결 능력이라 할 수 있다.

​

리펙토링(일단 쓰고, 고쳐 쓰기)

프로그램 구조

- 입력. 변수 세팅

- 처리. 자동선택

- 출력. 다듬기

​

프로그램 작성 규칙

- 타인과 미래에 재활용하고 유지 보수할 자신을 위해

문법, 형식에 맞게 이쁘게 잘 짜자

- 꼼꼼하게 코멘트, 주석 달기

- 중간중간 오류 체크 추가

- 일단 즐겁게 프로그래밍하기, 과정과 일을 즐기기

- 넘어지는 것에 대한 두려움 없이 자신감 있게 시작하기

- 마주하는 수많은 오류와 난관은 당연한 것이므로 스트레스받지 말고 극복하기

- 원하는 것을 찾는 끈질긴 질문과 아이디어로 목표하는 기능 구현 달성하기

- 기능에 맞고 누가 봐도 보기 좋고 이쁜 디자인 찾기

1. 질문하고, 찾고, 선택하기 반복

2. 목표에 따른 하위 목표와 중간 결과물을 완성하는 성취감 반복

3. 모으고, 정리, 정돈, 청소, 비우고 버리기 반복

​

https://hoonihoon.tistory.com/entry/1-%EB%A6%AC%ED%8E%99%ED%86%A0%EB%A7%81%EC%9D%B4%EB%9E%80

1. 리펙토링이란?

- 소프트웨어를 보다 쉽게 이해할 수 있어야 하고, 동작 변화 없이 내부 구조를 변경하는 것.

​

2. 리펙토링의 목적?

- 프로그램을 빨리 작성할 수 있도록 도와준다.

- 코드 디자인을 개선해준다.

- Bad code -> Good code

​

3. Bad code 란?

같은 작업을 위해 더 많은 코드 사용, 중복이 많고 이해하기 어렵다.

유지 보수하기에도 어려운 코드.

​

4. 리펙토링은 언제 하는가?

틈틈이 계속, 기능 추가할 때, 버그 수정할 때, 코드 검토 시에.

​

5. 리펙토링을 할 수 없을 때는?

1) 디자인 실수가 있어 마음대로 리펙토링을 할 수 없을 때

2) 현재 설계된 구조가 보안 문제, 퍼포먼스 문제 등 중요사항으로 리펙토링을 기대할 수 없을 때.

3) 코드가 처음부터 작성하는 게 나을 정도로 엉망인 경우

4) 현재 코드가 작동하지 않을 경우

5) 마감일이 가까울 경우.

​

6. 리펙토링 할 나쁜 코드는 왜 발생하는가?

- Copy & paste에 의해 중복 코드 발생.

- 잘못된 변수명, 함수에서 발생. (일관성이 중요 add, register, put, create )

- 특정 클래스 내의 메서드가 동작을 하기 위해 다른 클래스에 있는 정보를 많이 필요로 한경우 ( 메서드를 이동한다.)

- 나쁜 주석

- 너무 긴 메서드, 파라미터

​

7. 어떤 식으로 리펙토링을 시작해야 되는가?

- 찾기 쉬운 것부터 한다.

- 측정할 수 있는 것 (주석, 긴 메서드, 거대한 클래스, 긴 매개변수)

- 메서드가 하는 일 설명, 블록이 하는일 설명

python 리펙토링

https://python-guide-kr.readthedocs.io/ko/latest/writing/style.html

코드 스타일 — The Hitchhiker's Guide to Python

명쾌한 코드 파이썬으로 어둠의 마법을 부릴 수 있다면, 가장 명쾌하고 간단한 방법을 추천합니다. 나쁜 예 def make_complex ( * args ): x , y = args return dict ( ** locals ()) 좋은 예 def make_complex ( x , y ): return { 'x' : x , 'y' : y } 위의 좋은 코드 예시에서 x와 y는 호출자로부터 직접 값을 받아와 곧바로 딕셔너리로 반환합니다. 이 함수를 쓰는 개발자들은 첫 줄과 마지막 줄을 읽는 것만으로 무엇을 하는 함수인지 정확히 알 수...

python-guide-kr.readthedocs.io

​

http://pythonstudy.xyz/python/article/511-%ED%8C%8C%EC%9D%B4%EC%8D%AC-%EC%BD%94%EB%94%A9-%EC%8A%A4%ED%83%80%EC%9D%BC

예제로 배우는 파이썬 프로그래밍 - 파이썬 코딩 스타일

파이썬 코딩 스타일 PEP 8 파이썬 코딩 스타일 Python Enhancement Proposal 8 (PEP 8)은 파이썬 코딩 스타일에 대한 가이드를 제시하고 있다. PEP 8은 2001년 귀도 반 로썸에 의해 처음 제안되었으며, python.org 의 PEP 링크에 자세히 소개되어 있다. 파이썬 프로그래머들은 일반적으로 이러한 PEP 8 코딩 스타일에 따라 프로그래밍을 하고 있는데, 이러한 일관된 코딩 스타일을 적용하는 것은 자신의 코드를 명료하게 할 뿐만 아니라 특히 다른 개발자 혹은 커뮤니...

pythonstudy.xyz

​

2020-12-15

​

도메인 영역 언어

본질적으로 중요한 것은 내가 이해한 것으로 사고하고 설명하기,

도메인에 따라 용어가 다를 수 있고, 듣는 사람에 따라 이해하는 언어와 수준이 다르다.

​

달을 가리키는 손가락을 보는게 아니라 달을 봐야

​

MVP

model - process - view

​

강화학습

reset - step - render

​

MVVM

model - view - view model

​

DDD

domain - bounded contexts - entities, aggregates, services - microservices

​

빅데이터 분석 기사

빅데이터 분석 기획 - 빅데이터 탐색 - 빅데이터 모델링 - 빅데이터 결과 해석

데이터 - 정보 - 지식 - 지혜

​

시기별 단계별 기능별 영역이 있다

영역끼리 연결되거나 전달되는 것은 형식에 둘러싸인 본질

본질과 형식 둘 다 바뀔 수 있다. 자주 바꾸지 말아야 할 것은 형식(언어, 프로토콜)?

처음 설계할 때 본질의 변화와 추가적인 본질을 수용할 수 있는 형식을 잘 만들자?

​

DDD

https://medium.com/myrealtrip-product/what-is-domain-driven-design-f6fd54051590

도메인 주도 설계로 소프트웨어 만들기

최범균님의 Domain Driven Design 입문 강의 후기

medium.com

도메인 주도 설계에서 도메인이란 우리가 소프트웨어로 “해결하고자 하는 문제 영역”을 의미합니다.

.

일반적으로 UML(Unified Modeling Language)에서 자주 사용하는 “클래스 다이어그램(Class Diagram)”부터, 필요에 따라 “상태 다이어그램(State Diagram)”이나 “시퀀스 다이어그램(Sequence Diagram)”을 사용할 수도 있고, 아니면 UML이 아닌 다른 방식으로 표현해도 무방합니다.

다만 도메인 모델을 표현할 때 최대한 표현력을 가질 수 있게 단순히 속성만 나열하는 것이 아니라 행위를 통해​ 도메인 기능을 나타내도록, 그리고 실제로 사용하는 도메인 용어를 사용하도록 해야 합니다.

​

도메인 객체는 기본적으로 “엔티티(Entity)”와 “밸류(Value)”로 구분할 수 있습니다.

엔티티는 식별성과 연속성을 가지는 객체인데, 좀 더 풀어서 얘기하자면 고유한 식별자로 식별할 수 있으며 자신의 상태와 라이프사이클(Life cycle)을 가지는 도메인 객체입니다.

밸류는 개념적으로 묶을 수 있는 데이터 집합을 표현합니다. 도메인 주도 설계를 몰랐더라도 자주 들었던 “값 객체(Value Object)”라고 부르는 것이 바로 이것입니다. 밸류를 사용하면 각각의 데이터를 단일로 취급할 때보다 표현력을 향상시킬 수 있습니다.

더불어 엔티티와 밸류의 메서드(행위)​로 기능과 제약을 표현하고, 습관적으로 사용하는 setter/getter 메서드는 지양하라고 최범균님이 언급하셨는데,

// case 1

if (order.getStatus() == OrderStatus.DELIVERY_IN_PROGRESS)

{ // ...do something... order.setStatus(OrderStatus.DELIVERED); }

// case 2

if (order.isDeliveryCompletable())

{ // ...do something... order.completeDelivery(); }

저는 case 2가 case 1보다 무엇을 하고자 하는지 그 의도가 비교적 분명하게 느껴지고,

case 2처럼 만든 객체가 도메인 기능을 잘 표현하고 있는 도메인 객체라고 생각합니다.

애그리거트(Aggregate)

도메인 모델은 점차 복잡해지기 마련입니다. 서비스가 자랄수록 도메인 역시 함께 자라기 때문입니다. 이렇게 도메인 모델의 복잡도는 점차 증가하기 마련인데, 이러한 복잡도를 관리하기 위해 도메인 객체들의 묶음이자 집합체인 “애그리거트(Aggregate)”가 필요합니다. 애그리거트를 사용하면 우리가 다루는 도메인 객체를 좀 더 상위 수준으로 추상화할 수 있습니다.

이러한 애그리거트에는 포함된 객체들의 대표가 되는 “애그리거트 루트(Aggregate root)”가 필요합니다. 애그리거트에는 다수의 객체들이 포함되어 있고 이들은 함께 움직이면서 일관성을 유지해야 하는데, 만약 바깥에서 애그리거트 내부의 객체들에게 직접 접근해서 상태나 속성을 변경해버리면 일관성이 깨져버립니다.

따라서 애그리거트 바깥에서 애그리거트에 직접 접근할 수 있는 곳은 오직 애그리거트 루트 뿐이어야 합니다. 애그리거트 루트가 이러한 창구 역할을 하면서 애그리거트에 포함된 객체들의 일관성을 유지할 수 있습니다.

계층형 아키텍처(Layered Architecture)

계층형 아키텍처

계층형 아키텍처에서는 일반적으로 상위 계층이 하위 계층에 의존합니다. 표현 계층은 응용 계층에 의존하고, 응용 계층은 도메인 계층에 의존하는 방식입니다.

​

DIP(Dependency Inversion Principle)

​

예를 들어 “배송 알림” 기능은 고수준 모듈의 기능이고, “RDBMS에서 주문의 배송 정보를 조회하고, 주문자에게 메일로 배송 알림 메일을 전송한다”는 저수준 모듈의 기능이라고 할 수 있죠.

​

흔히 고수준 모듈이 저수준 모듈에 의존하도록 구현하는데, 이 경우 저수준 모듈의 변경이 곧 고수준 모듈의 변경으로 이뤄지곤 합니다.

고수준에서의 “배송 알림” 자체에 변경이 없어도, 저수준인 “메일로 배송 알림 메일을 전송한다”라는 저수준의 기능이 “SMS로 배송 알림 메시지를 전송한다”로 바뀐다면 고수준 모듈에서도 변경이 발생하는 것이죠.

이러한 단점을 극복하기 위해 의존 관계를 역전시켜서 저수준 모듈이 고수준 모듈에 의존하도록 구현하는 것을 DIP(Dependency Inversion Principle)라고 합니다.

저수준 모듈이 고수준 모듈을 의존

“배송 알림” 기능을 정의한 “배송 알리미” 인터페이스를 만들고, 저수준 모듈에서 “배송 알리미” 인터페이스를 구현한 저수준 모듈인 “메일 배송 알리미”나 “SMS 배송 알리미”를 만드는 것이죠.

이렇게 저수준 모듈이 고수준 모듈에 의존하도록 바꾸면 저수준 기능인 “메일로 배송 알림 메일을 전송”하던 것이 “SMS로 배송 알림 메시지를 전송”하는 것으로 바뀌더라도 고수준 모듈에서의 변경은 최소화할 수 있습니다.

이때 한 가지 주의사항이 있는데, DIP를 적용하는 목적은 고수준 모듈이 저수준 모듈에 의존하지 않고 반대로 저수준 모듈이 고수준 모듈에 의존하게 하려는 것이기에, 인터페이스를 도출할 때 저수준 모듈의 관점에서 도출하면 안 된다는 것입니다.

​

응용 서비스(Application service)

“응용 서비스(Application service)”는 도메인 객체를 이용하여 사용자의 요청에 알맞는 기능을 처리하고 결과를 반환하는 역할을 합니다. 표현 계층과 도메인 계층을 연결해주는 일종의 창구 역할이라고 볼 수 있습니다.

응용 서비스는 응용 계층에 속하기 때문에 도메인과 관련된 로직이 직접적으로 포함되지 않아야 합니다. 대신 도메인 계층에 포함된 도메인 객체들을 사용하여 도메인 기능을 처리하면서 흐름을 제어합니다. 이렇게 처리 흐름을 제어하는 역할을 하다보니 응용 서비스의 기능은 종종 트랜잭션의 단위가 되기도 합니다.

또한 응용 서비스는 표현 계층에 의존하지 않아야 합니다. 예를 들면 표현 계층의 기술인 HTTP 프로토콜에 대한 것(HttpSession, MultipartFile 등)은 응용 서비스에서 사용되지 않도록 해야 합니다.

​

응용 서비스의 전형적인 구현을 보자면,

1. 리포지터리로 사용할 도메인의 애그리거트 루트를 구하고,

2. 애그리거트 루트의 도메인 기능을 실행하고 처리 흐름을 제어하면서,

3. 처리 결과를 반환합니다.

​

응용 서비스에 대해서 최범균님이 언급하신 내용 중 하나는 “응용 서비스의 메서드 파라미터로 필요한 값들을 넘기는 대신 도메인 객체 자체를 넘기는 것은 최대한 지양하자”, 였습니다. 응용 서비스의 메서드 파라미터로 도메인 객체를 사용하다보면 도메인 객체에 원래는 필요하지 않던 속성들을 추가하기 마련이고, 이러한 속성들을 영속화에서 제외하는 경우 이를 위해 별도의 설정을 하는 등의 문제를 야기할 수 있기 때문입니다. 따라서 메서드 파라미터로 도메인 객체가 딱 들어맞는 경우에만 사용할 것을 권장하셨습니다.

또 하나 고민해볼 수 있는 내용으로는 “응용 서비스의 결과로 도메인 객체를 반환하는 것과 조회 전용 객체를 반환하는 것 중 어떤 것이 좋을까”, 입니다. 물론 각자 팀의 표준이나 구현 편의성, 성능 등 여러가지 상황을 고려하면 절대적인 답은 없겠지만 별도의 조회 전용 객체를 만들어 반환하는 편을 추천해주셨습니다.

​

리포지터리(Repository)

“리포지터리(Repository)”는 애그리거트의 영속성을 처리하기 위해 사용합니다.

리포지터리는 애그리거트 루트 단위로 존재해야 합니다. 애그리거트는 그 자체로 하나의 완전한 집합체이기 때문입니다. 따라서 영속화할 때 애그리거트 루트인 객체뿐만 아니라 애그리거트에 포함된 모든 객체를 함께 영속화해야 합니다. 물론 애그리거트를 저장소에서 조회하는 경우에도 애그리거트 루트와 애그리거트에 포함된 객체들을 전부 가져와야 하며, 삭제하는 경우도 마찬가지입니다.

따라서 “주문 애그리거트”가 있고 애그리거트 루트가 주문 객체라면, 주문 객체에 대한 리포지터리를 만들면 됩니다. 주문 애그리거트에 포함된 다른 객체인 “배송”이나 “주문 상품”, “주문자” 각각에 대해서 리포지터리를 만들 필요는 없습니다. 주문 리포지터리가 주문 애그리거트 전체의 영속성을 관리해주니까요.

최범균님은 JPA의 리포지터리를 사용하여 엔티티 객체를 로딩할 때 연관된 객체들을 기본적으로 EAGER 로딩하고, 필요한 경우에만 LAZY 로딩을 사용하기를 언급하셨습니다.

DDD

1. https://docs.microsoft.com/ko-kr/azure/architecture/microservices/model/domain-analysis

- 애플리케이션의 기능 요구 사항을 이해하기 위한 비즈니스 도메인 분석부터 시작합니다. 이 단계의 결과는 비공식적인 도메인 설명으로, 보다 공식적인 도메인 모델 세트로 구체화할 수 있습니다.

- 다음으로 도메인의 경계가 있는 컨텍스트 를 정의합니다. 각각의 제한된 컨텍스트에는 큰 애플리케이션의 특정 하위 도메인을 나타내는 도메인 모델이 포함됩니다.

- 제한된 컨텍스트 내에서 전술적 DDD 패턴을 적용하여 엔터티, 집계 및 도메인 서비스를 정의합니다.

- 이전 단계의 결과를 사용하여 애플리케이션에서 마이크로 서비스를 식별합니다.

​

제한된 컨텍스트 정의

​

도메인 모델은 현실 세계에 존재하는 항목 — 사용자, 드론, 패키지 등의 표현을 포함합니다. 그렇다고 해서 시스템의 모든 부분에서 동일한 항목에 대해 동일한 표현을 사용해야 한다는 것은 아닙니다.

예를 들어 드 론 복구 및 예측 분석을 처리 하는 하위 시스템은 유지 관리 기록, 진행 중, 연령, 모델 번호, 성능 특성 등 드 론의 여러 물리적 특성을 나타내야 합니다. 그러나 배달 예약에서는 그러한 특징을 고려하지 않습니다. 예약 하위 시스템은 드론의 가용 여부와, 수거 및 배달의 ETA를 알기만 하면 됩니다.

이 두 하위 시스템 모두에 대해 하나의 모델을 만들려고 하면 불필요하게 복잡해질 것입니다. 시간이 흘러 이 모델을 확장하게 되면 변경 사항이 개별 하위 시스템을 담당하는 여러 팀을 만족시켜야 하기 때문에 더 어려워집니다. 따라서 동일한 현실 세계 엔터티(이 경우 드론)을 두 가지 다른 컨텍스트에 표현하는 별도의 모델을 설계하는 것이 더 나은 경우가 종종 있습니다. 각 모델은 특정 컨텍스트 내에서 관련된 기능 및 특성만 포함합니다.

이 경우 바인딩된 컨텍스트의 DDD 개념이 재생 됩니다. 제한된 컨텍스트는 단순히 특정 도메인 모델이 적용되는 도메인 내의 경계입니다. 이전 다이어그램을 살펴보면 다양한 기능이 단일 도메인 모델을 공유하는지의 여부에 따라 기능을 그룹화할 수 있습니다.

경계가 있는 컨텍스트가 반드시 서로 격리될 필요는 없습니다. 이 다이어그램에서 경계가 있는 컨텍스트를 연결하는 실선은 경계가 있는 두 컨텍스트가 상호 작용하는 지점을 나타냅니다. 예를 들어 배송은 고객 정보를 가져오기 위해 사용자 계정을, 선단에서 드론을 예약하기 위해 드론 관리를 사용합니다.

​

Domain Driven Design 책에서 Eric Evans는 다른 경계가 있는 컨텍스트와 상호 작용할 때 도메인 모델의 무결성을 유지 관리하기 위한 여러 가지 패턴을 설명합니다. 마이크로 서비스의 기본 원칙 중 하나는 서비스가 잘 정의된 API를 통해 통신하는 것입니다. 이 방법은 Evans가 개방형 호스트 서비스와 게시된 언어라고 칭한 두 패턴에 해당합니다. 개방형 호스트 서비스란 하위 시스템이 다른 하위 시스템과의 통신을 위한 공식 프로토콜(API)를 정의하는 것입니다. 게시된 언어는 다른 팀이 클라이언트를 작성하는 데 사용할 수 있는 양식으로 API를 게시하여 이러한 개념을 확장합니다. 마이크로 서비스용 Api 디자인문서에서 openapi 사양 (이전의 Swagger)을 사용 하 여 JSON 또는 yaml 형식으로 표현 된 REST api에 대 한 언어에 관계 없는 인터페이스 설명을 정의 하는 방법을 설명 합니다.

​

2. https://docs.microsoft.com/ko-kr/azure/architecture/microservices/model/tactical-ddd

​

전술적 패턴 개요

​

이 섹션에서는 전술적 DDD 패턴에 대한 간략한 개요를 제공하므로 이미 DDD에 익숙하다면 이 섹션을 건너뛸 수 있습니다. 패턴은 Eric Evans의 책 5 – 6장과, Vaughn Vernon의 Implementing Domain-Driven Design(DDD 구현) 에서 더 상세히 설명합니다.

엔터티. 엔터티는 시간이 지나도 지속되는 고유의 ID가 있는 개체입니다. 예를 들어 뱅킹 애플리케이션에서 는 고객과 계좌가 엔터티입니다.

엔터티에는 엔터티를 조회하거나 검색하는 데 사용할 수 있는 고유의 식별자가 있습니다. 식별자가 항상 사용자에게 직접 노출되는 것은 아닙니다. 데이터베이스의 GUID 또는 기본 키가 될 수 있습니다.

ID는 여러 경계가 있는 컨텍스트를 포괄할 수 있고 애플리케이션의 수명을 넘어설 수 있습니다. 예를 들어 은행 계좌번호나 정부 발급 ID는 특정 애플리케이션의 수명 주기에 종속되지 않습니다.

엔터티의 특성은 시간이 지나면서 변화할 수 있습니다. 예를 들어 사용자 이름 또는 주소는 변경될 수 있지만 여전히 같은 사람입니다.

엔터티는 다른 엔터티에 대한 참조를 포함할 수 있습니다.

값 개체. 값 개체에는 ID가 없습니다. 해당 특성의 값으로만 정의됩니다. 값 개체도 변경할 수 없습니다. 값 개체를 업데이트하려면 항상 새 인스턴스를 만들어 기존 인스턴스를 대체합니다. 값 개체는 도메인 논리를 캡슐화하는 메서드를 갖을 수 있으나 이러한 메서드는 개체의 상태에 부작용을 주지 않아야 합니다. 값 개체의 대표적인 예로 색, 날짜 및 시간, 통화 값 등이 있습니다.

​

집계. 집계는 하나 이상의 엔터티에 대한 일관성 경계를 정의합니다. 한 집계에서 정확히 한 엔터티가 루트입니다. 조회는 루트 엔터티의 식별자를 사용하여 수행됩니다. 집계의 다른 엔터티는 루트의 자식 요소로, 루트의 다음 포인터에서 참조합니다.

집계의 목적은 트랜잭션 고정 항목을 모델링하는 것입니다. 현실은 매우 복잡한 관계로 얽혀있습니다. 고객이 주문을 접수하고, 주문에는 제품이 포함되어 있으며, 제품을 제공하는 공급자가 있는 등 이와 같은 관계가 계속 이어집니다. 애플리케이션이 몇 가지 관련 개체를 수정하는 경우 일관성을 어떻게 유지하나요? 고정 항목을 어떻게 추적하고 적용할까요?

전통적 애플리케이션에서는 데이터베이스 트랜잭션을 사용하여 일관성을 적용하는 경우가 종종 있었습니다. 그러나 분산형 애플리케이션의 경우 현실성이 떨어지는 경우가 많았습니다. 단일 비즈니스 트랜잭션이 여러 데이터 저장소에 걸쳐 있거나, 오래 실행되거나, 타사 서비스와 관련될 수 있습니다. 궁극적으로 이것은 데이터 계층이 아니라 도메인에 필요한 불변 항목을 시행하는 애플리케이션에 달려 있습니다. 이것이 집계가 모델링에서 갖는 의미입니다.

참고 집계는 자식 엔터티 없이 단일 엔터티로 구성될 수 있습니다. 집계를 만드는 것은 트랜잭션 경계입니다.

​

도메인 및 애플리케이션 서비스. DDD 용어에서 서비스란 상태를 유지하지 않고 일부 논리를 구현하는 개체입니다. Evans는 도메인 논리를 캡슐화 하는 도메인 서비스 와 사용자 인증 또는 SMS 메시지 전송과 같은 기술 기능을 제공 하는 응용 프로그램 서비스 를 구분 합니다. 도메인 서비스는 종종 여러 엔터티를 포괄하는 동작을 모델링하는 데 사용됩니다.

참고 서비스 라는 용어는 소프트웨어 개발에서 범위가 넓습니다. 여기에서는 그 정의가 마이크로 서비스와 직접적인 연관이 없습니다.

​

도메인 이벤트. 도메인 이벤트는 변경이 있을 때 시스템의 다른 부분에 이를 알리는 데 사용됩니다. 이름에서 알 수 있듯이 도메인 이벤트는 도메인 내의 이벤트를 나타내야 합니다. 예를 들어 "테이블에 레코드가 삽입"되는 것은 도메인 이벤트가 아닙니다. "배달 취소"는 도메인 이벤트입니다. 도메인 이벤트는 마이크로 서비스 아키텍처에서 특히 관련이 있습니다. 마이크로 서비스는 분산되고 데이터 저장소를 공유하지 않으므로, 도메인 이벤트를 통해 마이크로 서비스에서 서로 조정할 수 있습니다. 서비스 간 통신 문서에서는 비동기 메시징에 대해 자세히 설명 합니다.

​

DDD Aggregate

https://medium.com/@SlackBeck/%EC%95%A0%EA%B7%B8%EB%A6%AC%EA%B2%8C%EC%9E%87-%ED%95%98%EB%82%98%EC%97%90-%EB%A6%AC%ED%8C%8C%EC%A7%80%ED%86%A0%EB%A6%AC-%ED%95%98%EB%82%98-f97a69662f63

애그리게잇 하나에 리파지토리 하나

필자는 도메인 주도 설계Domain-Driven Design(이하 DDD) 빌딩 블록Building blocks[1]으로 애플리케이션을 구현하면서 엔티티ENTITY[2] 마다 리파지토리REPOSITORY를 만드는 것을 자주 보았는데 자세히 살펴보면…

medium.com

​

필자는 도메인 주도 설계Domain-Driven Design(이하 DDD) 빌딩 블록Building blocks[1]으로 애플리케이션을 구현하면서 엔티티ENTITY[2] 마다 리파지토리REPOSITORY를 만드는 것을 자주 보았는데 자세히 살펴보면 여러 엔티티를 묶어서 하나처럼 사용하는 경우가 대부분이었다. DDD에서는 이러한 연관 객체의 묶음을 애그리게잇AGGREGATE이라고 정의하고 애그리게잇에 포함된 특정 엔티티를 루트Root 엔티티라고 부른다. 그리고 ​리파지토리를 만들 때 애그리게잇 루트 엔티티에 대해서만 리파지토리를 제공하라고 한다.

이 글은 주문 도메인 예시를 통해 애그리게잇이 무엇인지 알아보고 왜 애그리게잇 루트에 대해서만 리파지토리를 제공해야 하는지에 대해 설명한다.

​

OrderService에 비즈니스 규칙을 구현함에 따라 OrderService는 Order 뿐만 아니라 연관된 LineItem, OrderPayment, ShippingAddress을 함께 참조하고 있다. 이런 경우 Order를 사용할 때 늘 비즈니스 규칙을 머릿속에 넣어두고 코딩해야 한다. 이 글에서는 이해를 위해 Order를 단순화했지만 실무에서는 Order는 훨씬 더 복잡한 연관 관계와 속성을 가진다. 복잡한 연관 관계를 가지는 Order를 모두 파악하고 사용하는 것은 쉬운 일이 아니다.

​

DDD의 저자 에릭 에반스Eric Evans는 “모델 내에서 복잡한 연관 관계를 맺는 객체를 대상으로 변경의 일관성을 보장하기란 쉽지 않다. 그 까닭은 단지 개별 객체만이 아닌 서로 밀접한 관계에 있는 객체 집합에도 불변식이 적용돼야 하기 때문이다.” 라고 말했다. 여기서 불변식Invariants은 데이터가 변경될 때마다 유지돼야 하는 일관성 규칙(비즈니스 규칙)을 뜻한다.

​

Order, LineItem, ShippingAddress, OrderPayment는 각각이 아닌 하나의 집합으로 다루어야 한다. 에릭 에반스는 이를 애그리게잇AGGREGATE으로 정의한다.

모델 내의 참조에 대한 캡슐화를 추상화할 필요가 있다. AGGREGATE는 우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음을 말한다.

각 AGGREGATE에는 루트(root)와 경계(boundary)가 있다.

경계는 AGGREGATE에 무엇이 포함되고 포함되지 않는지를 정의한다.

루트는 단 하나만 존재하며, AGGREGATE에 포함된 특정 ENTITIY를 가르킨다.

경계 안의 객체는 서로 참조할 수 있지만, 경계 바깥의 객체는 해당 AGGREGATE의 구성요소 가운데 루트만 참조할 수 있다.

— 도메인 주도 설계, 131쪽

애그리게잇에 포함된 특정 엔티티를 루트 엔티티라고 한다고 했다. Order, LineItem, ShippingAddress, OrderPayment 중 어떤 것이 루트 엔티티일까?

DDD에서는 루트 엔티티는 전역 식별성Global identity을 지닌 엔티티라고 말한다. 필자는 전자 상거래 사이트에서 주문 파트 개발자로 일한 적이 있다. 콜 센터나 상품 파트, 회원 파트와 협업할 일이 매우 많았는데 대부분 사람들이 주문 번호를 말하며 의사소통했다. 필자가 보기에는 이것이 바로 전역 식별성이다.

또한, 안영회 님은 상품 정보 다룰 때 BoundedContext 와 엔터티 글에서 애그리게잇을 언급하며 아래처럼 말했다.

이런 경우는 조회 작업의 주체로 쓰이는 엔터티와 그렇지 않은 엔터티가 존재할 수 있습니다.

DDD의 또 다른 빌딩블록인 Aggregate 가 떠오르는 지점입니다.

멋진 표현이다. “주체로 쓰이는 엔티티와 그렇지 않는 엔티티” 루트 엔티티는 주체로 쓰이는 엔티티이다.

​

결론적으로 이 글에서는 Order가 루트 엔티티가 될 수 있다.

​

빅데이터 분석 기사

​

빅데이터 분석 기획 - 빅데이터 탐색 - 빅데이터 모델링 - 빅데이터 결과 해석

​

데이터 - 정보 - 지식 - 지혜

​

1) 데이터(Data) : 가공하기 전, 관찰 수집한 객관적 사실 그 자체, Raw data, Microdata 등으로 불림

2) 정보(Information) : 가공된 데이터, Processed Data / 기술통계(평균 등)는 정보에 해당

3) 지식(Knowledge) : 정보에 기반에 찾은 규칙(if A than B), 패턴이 지식에 해당

4) 지혜(Wisdom) : 지식에 유연성(Flexible)을 추가한 것, 시나리오에 기반에 맥락(Context)이나 상황에 맞게 규칙을 적용하는 것 - 지식의 축적과 아이디어가 결합한 창의적 산물

​

https://r-book.tistory.com/19

[ADsP 자격증] 1-1. 데이터와 정보(데이터-정보-지식-지혜)

제 1과목 데이터 이해 / 1. 데이터의 이해 / 1-1. 데이터와 정보 < 데이터의 정의 > 데이터는 사물, 현상, 사건, 인간관계 등에 관한 관찰 기록이다. 1) 재료, 자료, 논거라는 뜻인 Datum의 복수형 2) 컴퓨터 용어..

r-book.tistory.com

※ 지식 순환 과정(프로세스)

1) 공통화(Socialization) : 암묵지 → 암묵지

2) 표출화(Externalization) : 암묵지 → 형식지

3) 연결화(Combination) : 형식지 → 형식지

4) 내면화(Internalization) : 형식지 → 암묵지

​

분석 기획

​

https://gaiag.tistory.com/37

3-1 데이터 분석 기획의 이해

제 1절 분석 기획 방향성 도출 분석기획 : 실제 분석 수행 전, 수행할 과제의 정의 및 의도했던 결과를 도출할 수 있도록 관리할 사전 방안을 계획하는 작업 어떠한 목표(What)를 달성하기 위해서(Why) 어떤 데이..

gaiag.tistory.com

- 목표 시점 별 분석 기획 방안

- 과제 중심적인 접근 방식 : 과제 단위로 명확한 해결 위해 Quick - Win 방식

- 장기적인 마스터 플랜 방식 : 분석 문화 내재화를 위해 전사적이고 장기적 관점이 바람직함

- 문제해결을 위한 단기적인 접근방식과 분석과제 정의를 위한 중장기적인 마스터 플랜 접근 방식 융합

- 의미있는 분석 : 분석기술, IT 및 프로그래밍, 분석 주제 도메인 전문성, 의사소통, 마스터 플랜 도출

- 분석가 3가지 기본 역량 + 프로젝트 관리 역량, 리더십 역랑 필요

​

​

빅데이터를 분석하기 위한 방법론 : 계층적 프로세스 모델(단계-태스크-스탭)

1) 분석 기획

가. 비즈니스 이해 및 범위 실행 : 비즈니스 이해, 도메인 문제점 파악

- 프로젝트 범위 정의서 SOW

나. 프로젝트 정의 및 계획 수립 : 프로젝트 범위 확정 단계, 진행의 기준선 설정

- 데이터 분석 프로젝트 정의 : 목표, KPI 등을 구체화한 정의서 작성, 평가 기준 설정

- 프로젝트 수행 계획 수립 : 수행 계획서 WBS 작성(목적, 배경, 기대효과, 방법, 일정, 조직, 방안 등)

다. 프로젝트 위험 계획 수립 : 인프라 구축 병행, 기존 시스템과 인터페이스 동반 등의 위험 요소

- 데이터 분석 위험 식별 : 산출물, 정리자료, 전문가 판단을 활용 → 위험식별, 우선순위 설정

- 위험 대응 계획 수립 : 위험 관리 계획서 (회피, 전이, 완화, 수용 로 구분된 대응 방안 수립)

2) 데이터 준비

가. 필요 데이터 정의 : 모든 사람이 함께 작성

- 데이터 정의 : 다양한 원천 데이터 소스로부터 데이터 정의서 작성

- 데이터 획득방안 수립 : 데이터 수집에 따른 구체적 방안 수립 (내/외부 데이터 획득 방안)

나. 데이터 스토어 설계 : 프로젝트 별로 필요한 데이터 정의하여 전사 차원의 스토어 설계서

- 정형 데이터 : 구조화된 형식, DBMS 사용, 논리적 물리적 설계 구분하여 설계

- 비정형 데이터 : 하둡, NoSQL사용, 논리적 물리적 설계 구분하여 설계

다. 데이터 수집 및 정합성 점검 : 품질 통제와 품질 보증 프로세스 수행

- 데이터 수집 및 저장 : 크롤링 ETL도구, API, 스크립트 프로그램 등 이용, 데이터 스토어 저장

- 데이터 정합성 점검 : 품질점검을 통한 정합성 확보, 보완작업 진행

3) 데이터 분석 : 수립된 프로젝트 목표를 달성하기 위해, 적당한 데이터셋이 없음 준비단계 반복 수행

가. 분석용 데이터 준비 : 데이터셋 준비

- 비즈니스 룰 확인 : 프로젝트 목표 확인, 비즈니스 룰 파악

- 정형, 비정형 데이터 추출 → 분석 가능하도록 구조화된 형태로 구성, 작업공간에 분리

나. 텍스트 분석 : 비정형 데이터 존재할 경우, 정형데이터와 통합 모델링 수행

- 텍스트 데이터 확인 및 추출 : 비정형 데이터 데이터 스토어 확인 후 추출

- 텍스트 데이터 분석 : 용어 사전 확보, 텍스트 시각화 도구 활용 의미 전달 명확

다. 탐색적 분석

- 탐색적 데이터 분석 : 기초통계랑 산출, 데이터 자체 특성(중심성, 분포성, 산포성) 기초자료 준비

- 데이터 시각화 : 시스템화를 위한 시각화, 사용자 인터페이스, 프로토타입 활용

라. 모델링 : 가정설정을 통해 통계 모델을 만들거나, 기계학습을 이용한 수행 모델 만드는 것

- 데이터 분할 : 데이터 셋을 훈련용과 테스트용으로 분할, 교차검증, 앙상블 기법 적용

- 데이터 모델링 : 분류, 예측, 군집 등의 모델 만들어 운영 시스템 적용, 통합 모델링 수행

- 모델 적용 및 운영 방안 : 알고리즘 설명서 작성, 의사코드 수준의 상세한 작성 필요, 모니터링

마. 모델평가 및 검증 (모델평가검증서)

- 모델 평가 : 정의서 평가 기준에 따라 객관적 평가, 별도이 데이터 활용해서 분석

- 모델 검증 : 검증용 데이터 이용 모델 검증 작업 실시, 보고서 작성, 실 운영용 데이터로 최종 검증

바. 모델적용 및 운영방안 수립

4) 시스템 구현

가. 설계 및 구현 : 소프트웨어 개발 생명주기 SDLC와 기업내 시스템 방법론 커스터마이징하여 적용

- 시스템 분석 및 설계 : 응용시스템 구축 설계 프로세스 진행

- 시스템 구현 : BI 패키징 활용, 운영시스템의 커스터마이징 통해 설계된 모델 구현

나. 시스템 테스트 및 운영 : 운영중인 시스템에 적용하거나 프로토타입을 구현하고자 하는 경우

- 시스템 테스트 : 단위/통합/시스템 테스트 실시, 객관성과 완전성 확보

- 시스템 운영 계획 : 운영자, 사용자를 대상으로 필요한 교육을 실시하고 시스템 운영계획 수립

5) 평가 및 전개

가. 모델 발전 계획 수립 : 모델의 생명주기 설정하고 주기적 평가 실시, 업데이트 자동화 방안

- 모델 발전 계획 : 지속적인 운영과 기능 향상을 위한 발전계획 수립, 계속성 확보

나. 프로젝트 평가 및 보고 : 분석 기획 단계의 목적 달성 여부 평가, 자산화 진행

- 프로젝트 성과 평가 : 정량적, 정성적 성과로 나눠 성과 평가서 작성

- 프로젝트 종료 : 최종 보고서 작성, 지식 자산화 실행, 의사소통 절차에 따른 보고

20201209

​

생각은 머리속 언어, 이미지, 소리, 경험에 의해 기억된 객체들, 등이 어우러져서 이루어 지는 듯.

그런데 꿈이나 생각속의 나와 객체들이 어떻게 자율적으로 반응하지?

​

통계적인 뉴런에 연결돼 있어서?

통계적 뉴런이기 때문에 제어하려면 평소 인풋 기억과 내면의 대화를 잘 관리해야 할 듯

​

평소에 자기 전 하루의 도전을 정리하고 질문하기

아침에 눈뜨면 어제 과거를 되돌아보고 반성하고 미래를 상상하며 대비하며 생각하기

​

머신러닝 뉴럴넷도 마찬가지 평가 함수가 질문이고, 학습 데이터를 인풋으로 기억(학습) 만들기.

이것들을 잘 이용해서 인공신경망을 제어하는 것

​

- 언어 모델이 어떻게 번역 분류 질의 등의 문제를 해결하는가?

- 다이내믹 프로그램을 자동으로 짜게 하려면?

- 핵심 기능 단순한 프로그램이 기능을 추가함에 따라 어떻게 복잡해지는가?

​

[출처] https://www.kakaobrain.com/blog/118

​

- 언어 모델이 어떻게 자연어 처리 문제들(번역, 요약, 분류, QnA 등)을 해결하는가?

pretrain -> embedding -> fine tuning

(추천 동영상입니다 음미하시면 꼭 자연어 처리에 한정되지 않고 머신러닝 문제들을 어떻게 해결하는지 프레임을 보실 수 있을 것 같습니다)

https://youtu.be/DaAObh3sGnQ

​

- 다이내믹 프로그래밍

[출처] https://new93helloworld.tistory.com/220

​

​

1 분할 정복 가능

2 작은 문제의 답을 큰 문제에 재활용(이전의 답을 재활용)

위의 동영상에도 이전에 학습한 문장을 벡터로 만들어 검색한다는 내용이 있는데..

https://youtu.be/FmXZG7D8nS4

​

​

- 복잡한 프로그램을 어떻게 단순화할지? 추상화, 객체지향(OOP)

​

https://youtu.be/NcvX9SzUlcs

​

https://youtu.be/vrhIxBWSJ04

​

https://youtu.be/eLSlhuwDqF8

​

5가지 클래스 설계의 원칙(SOLID)

https://www.fun-coding.org/PL&OOP2-1.html

​

python 디자인 패턴

https://www.fun-coding.org/PL&OOP2-2.html

​

어제는 간단한 프로그램인데도 유튜브 동영상을 보면서 따라 하는데 오류와 넘어야 하는 난관과 극복해야 하는 문제점이 생겼다.

​

잘 만든 프로그램에는 간단해 보여도 눈에 보이지 않는 최적화를 위해 고심한 노력이 담겨있다.

Dacon, kaggle 문제풀이 또한 그러하다.

​

프로그래밍 실력을 키우기 위해 간단한 프로그램이나 프로젝트부터 따라 하기가 필요하다.

익숙해지거나 이해한 후에야 내 나름의 응용이 가능한 것 같다.

​

웹툰 만화가들도 틈틈이 따라 그리며 연습한다고 했다.

남을 보고 따라 한다는 것은 좋은 배움의 한 가지 방법인 것 같다.

​

또 한 가지 단계 단계 매듭지을 수 있는 성과들을 목표로 노력하는 것이 가시적이고 달성 여부를 쉽게 알 수 있고 뭔가 남길 수 있어서 좋다.

​

코딩 배우기 후기 관련

https://youtu.be/ufupPuN8VVw

웹툰 작가 따라 그리기 관련

https://youtu.be/oe5yNe2bh9Q

조코딩

https://www.youtube.com/channel/UCQNE2JmbasNYbjGAcuBiRRg

나도코딩

https://www.youtube.com/channel/UC7iAOLiALt2rtMVAWWl4pnw

생활코딩

https://www.youtube.com/user/egoing2

​

노마드 코더

https://nomadcoders.co/

어제 따라 한 프로그램

https://youtu.be/gMRee2srpe8

​

Dacon 심리성향예측 배울만한 공유 코드

https://dacon.io/competitions/official/235647/codeshare/1789?page=1&dtype=recent&ptype=pub

말하는 톰 앱입니다.

​

- 음성인식 추가 컴포넌트를 사용합니다. 기본으로 지원하는 음성인식은 구글 음식인식화면이 뜨고, 추가 컴포넌트는 화면에 표시 없이 인식...

​

- 텍스트를 음성으로 출력 컴포넌트를 활용합니다.

앱 구상

​

[참고 앱]

https://youtu.be/f8cGYGmMWFQ

기본기능

1. 음성인식

2. 인식한 문장을 음성으로 출력

앱 제작

​

1. 화면 디자인

- 구글 음성인식 대신 사용할 음성인식 컴포넌트를 설치합니다.(귀찮으시면 기본으로 지원하는 음성인식 사용하시면 됩니다.)

https://community.appybuilder.com/t/voice-recognition-extension-without-google-dialogue/21052

첨부파일

​

- 인터넷에서 talking tom animated gif 로 적당한 이미지를 검색하고 webviewer component 의 home url로 설정합니다.

​

​

2. 블록 코딩

- 버튼을 누르면 음성인식 시작

- 음성인식이 완료되면 웹페이지를 말하는 그림으로 바꾸고, 인식된 문장(text)를 음성으로 출력

- 음성출력이 끝나면 1초 뒤 웹페이지를 원래 그림으로 바꿈.

​

3. 실행 화면

4. 소스 파일(aia)

관련글 : 앱인벤터 소개

https://blog.naver.com/sfex/221994450104

현재 자체 component로 구현이 안 된 목록 드래그 위치 변경 기능을 webviewer의 javascript 실행 기능을 활용하여 구현한 것입니다.

- webviewer를 통해 javascript를 실행하실 수 있습니다.

- 간단한 로컬DB 사용법을 알 수 있습니다.

앱 구상

[참고 앱]

http://puravidaapps.com/sortable.php

App Inventor Tutorials and Examples: Sortable | Pura Vida Apps

A Sortable List using Drag-and-Drop with App Inventor and jQuery UI The example displays an App Inventor list in a jQuery UI Sortable . Thank you furf , together with your jQuery UI Touch Punch library we can use drag and drop on the mobile device to order the list items manually. 

기본기능

1. 드래그로 목록 순서를 변경

2. 목록 순서를 휴대폰에 저장

앱 제작

1. 화면 디자인

- 필요한 파일들을 올려주세요.

jquery-ui.css

ui-lightness-jquery-ui.css

ui-icons_ef8c08_256x240.png

jquery-1.7.2.min.js

jquery-ui.min.js

jquery.ui.touch-punch.min.js

2. 블록 코딩

- WebViewer에 띄울 html file을 셋팅하는 루틴

- 로컬 DB를 읽어오기, 자료가 없으면 목록을 초기값으로 설정

- 순서바꾸기를 터치하면 webviewer를 띄우고 html에 전달할 목록을 셋팅 후 web page javascript 실행

- 저장버튼을 터치하면 webviewer를 감추면서 webviewer의 CurrentPageTitle을 통해 결과값 가져오고 로컬DB에 저장

3. 실행 화면

4. 소스 파일(aia)

관련글 : 앱인벤터 소개

https://blog.naver.com/sfex/221994450104

휴대폰 화면보다 큰 이미지를 배경으로 드래그 스크롤 하면서 동작하는 앱을 만들 때 사용하면 좋겠습니다.

​

- 기본 원리는 canvas 위쪽과 왼쪽에 크기 조절용 component (VerticalArrangement, HorizontalArrangement, Image, 등) 을 두고 이것의 크기를 조절하면 canvas 중에서 휴대폰 화면에 보이는 부분이 정해지는 원리입니다.

앱 구상

​

[참고 앱]

https://appinventor.mit.edu/explore/blogs/karen/2018/03.html

Responsive Design: Drag a Canvas larger than screen size

​

기본기능

​

1. 화면보다 큰 이미지를 canvas 배경으로 설정하고 드래그 스크롤 가능하도록 한다.

2. canvas에 image sprite를 추가하고 드래그하여 움직일 수 있도록 한다.

앱 제작

​

1. 화면 디자인

​

​

2. 블록 코딩

​

- 변수 설정

- canvas 크기를 결정할 배경 이미지 크기

- 처음 휴대폰 화면크기

- 위치 조절용 component의 최대 크기

- 시작하면 init 함수 호출

​

- canvas 크기와 배경 이미지 설정

- 전체 화면크기는 배경 이미지 * 2

- 보이는 부분을 결정하는 크기 조절용 component (sH, sW) 크기 설정

- 크기 조절용 component (sH, sW) 최대 크기 저장

​

- canvas를 드래그했을 때 image sprite를 드래그한 것이 아니라면 (빨간 box)

- 드래그한 만큼 크기 조절용 compnent 크기 변경

​

- image sprite 드래그하여 위치 변경

​

3. 실행 화면

​

4. 프로그램 소스(aia)

관련글 : 앱인벤터 소개

https://blog.naver.com/sfex/221994450104

[make app] app inventor 소개

python 을 처음 접할 때 설치, 등 여러 가지 문제를 줄이면서 간편하게 빨리 python을 실행해볼 수 있는 것이 google colaboratory입니다.(사용법 : https://ndb796.tistory.com/312 )(제약은 있지만 GPU, TPU 실습도 가능...)

​

대부분 웹에서 정보를 가져오려고 할 때 beatifulsoup를 이용해서 각 사이트에 맞게 잘라서 가져오는 방법을 주로 사용합니다.

​

뉴스 형식의 데이터를 가져오는 python newspaper라는 library를 이용하면 어떻게 작업을 쉽게 할 수 있는지 살펴보고자 합니다.

​

일단 사용법을 살펴보고 블로그 등 일반 사이트에도 적용해서 실습해 보겠습니다.

​

​

참고사이트

- https://holwech.github.io/blog/Automatic-news-scraper/

- https://github.com/codelucas/newspaper

​​

실습 내용

- https://colab.research.google.com/drive/13vdr-le3jzjGWpKMbBRkijJ8mfthdU_J?usp=sharing

​​

정리

- newspaper library를 이용해서 간단하게 웹페이지 내용을 가져올 수 있습니다.

- 사용법

from newspaper import Article

url = 'https://news.chosun.com/site/data/html_dir/2020/07/02/2020070204391.html'
article = Article(url)
article.download()
article.parse()
article.nlp()

# 제목
article.title

# 저자
article.authors

# 날짜
article.publish_date

# 내용
article.text

# 주요 이미지
article.top_image

# 동영상
article.movies

# 키워드
article.keywords

# 요약
article.summary

- 네이버 블로그는 잘 안되고, tistory는 잘 작동합니다.