코딩하는 eroke

프레임워크

어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조
SW개발에 있어 하나의 뼈대 역할을 함

클래스와 라이브러리가 합쳐진 형태

프레임워크는 재사용 가능한 수많은 클래스들과 라이브러리들을 융합한 채로 처음부터 제공해 줌 여러 개의 표준을 만들지 않아도 됨 > 개발자의 피곤함을 덜어줌

물론 틀 위에 기능들은 구현해야함

라이브러리

소프트웨어 개발 시 사용되는 프로그램의 구성요소 (도구)
공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것
대상 환경(플랫폼)에서 바로 실행될 수 있는 형태로 제공됨 (≠완전한 프로그램)


API vs 라이브러리

• 라이브러리 : 실제 실행되어 기능을 수행하는 단편화된 프로그램
동작하는 완전한 프로그램이 아님
특정한 부분 기능만을 수행하도록 제작된 (컴파일되어 기계어/바이트코드의 형태로 존재하는)프로그램

• API : 프로그래밍 언어에서 라이브러리를 사용할 수 있도록 소스코드 수준에서 인터페이스를 노출시킨 것

따라서 라이브러리는 이 자체로는 실행할 수 없으며, 해당 라이브러리의 기능을 직접 호출하는 프로그램을 실행하거나, 사용자가 해당 라이브러리의 기능을 실행하는 API를 사용하는 프로그램을 직접 개발하면 실행할 수 있다.


라이브러리 종류

- 표준 라이브러리: 특정 언어의 개발 환경에 기본적으로 포함된 것
기본적인 기능 수행과 더불어 디버깅, 성능측정 등을 위한 별도의 API가 존재함

- 런타임 라이브러리: 프로그램이 실제 환경에서 실행되기 위해 필요한 모듈들
표준 라이브러리에서 기능 수행에 필요한 것들만 제공되거나, 스크립트의 실행기 등을 말함
(ex : Windows - .dll/ Java - .jar)



Reference - 나무위키

요즘 출퇴근하면서 요런 책을 읽고 있다.

모놀리식 아키텍처

기존의 웹 기반 애플리케이션
서비스 간 호출 = Call by Reference
• UI, 비즈니스로직, DB액세스로직, ... 모두가 하나의 애플리케이션 산출물로 패키징, 배포됨
• 각 팀의 변경이 있을 때마다 애플리케이션 전체를 빌드, 테스트, 배포해야함
• 애플리케이션 규모가 커질 수록 각 팀의 의사소통, 조정비용이 증가함

마이크로서비스

서비스 간 호출 = API
• 애플리케이션을 제한된 책임을 담당하는 컴포넌트로 분해 (전통적 복잡성 문제 해결)
• 느슨히 결합된 작은 분산 서비스
• 각 팀이 코드/ 인프라스트럭쳐 (앱서버, DB)를 독립적으로 가짐
• 팀 단위로 빌드, 테스트, 배포 가능 (상호독립적)
• 확장성, 회복성 향상
• http, json 같은 경량 프로토콜 사용 = 기술 중립적 = 다양한 언어, 기술 사용 가능

MSA : 마이크로 서비스 아키텍처

- SOA 사상에 근간을 둠
- 컴포넌트를 서비스로 정의 (구현)
- REST API 같은 표준인터페이스로 기능을 외부에 제공
- 서비스경계 = 도메인경계
- 서비스 : 독립적인 war파일로 개발, 독립된 톰캣 인스턴스에 배치
- 톰캣 인스턴스 : 횡적으로 스케일가능 (인스턴스 더함), 서비스 간 로드 분산시킴 (앞단에 로드밸런서 배치)
UX(Front-end) - 로드밸런서 - 톰캣(war)

• SOA(서비스 지향 아키텍처) : 엔터프라이즈 시스템 중심으로 고안됨
프로젝트 실패 원인 > ESB (Enterprise Service Bus)
: 메시지를 내부적으로 xml로 변환해서 처리함(EAI 통합기능 처리를 위해...) > 파싱에 대한 오버헤드 발생
> 대안= API Gateway = EAI기능 제거, API처리 기능에만 집중

•  API Gateway
- MSA의 주요 컴포넌트 (미들웨어) = SOA의 ESB 경량화 버전
1) 모든 API의 엔드포인트 통합 (like Proxy) 기능
Hub & Spoke 방식으로 서비스 간 호출 단순화 가능
(MSA는 API 엔드포인트=서버 URL이 각기 다름=사용자관점 불편해짐 >>> 통합필요)
2) 오케스트레이션 (like Mashup) 기능
여러 서비스를 묶어 하나의 서비스로 만듬 (넷플릭스)
3) 공통 기능 처리 기능
API 인증/로깅 같은 공통 기능 담당 > API는 비즈니스 로직에만 집중하도록 함
4) 중재 기능
xml, 네이티브 메시지포맷 -> json 상호변환
프로토콜 변환
서비스 간 메시지 라우팅

• MSA의 단점
서비스 호출(API통신)시 json/xml -> 프로그래밍 데이터 모델 (ex: java객체) 변환하는 오버헤드 발생
메모리 사용량 증가 (독립 서비스 독립 서버 분할 배치)
운영관점 대상 시스템, 필요 기술 증가
서비스간 트랜잭션처리 (모노리틱은 롤백) 구현필요 (복잡)



Reference
스프링 마이크로서비스 코딩 공작소 (존 카넬)

조대협의 서버 사이드 : 대용량 아키텍처와 성능 튜닝 (조대협)

GraphQL은 필요에 따라 REST API의 대안으로 원하는 컬럼만 요청이(POST) 가능하다

위처럼 타입 지정도 가능!

REST API vs GraphQL

• REST API
- URI 마다 하는 작업/정보가 정해져있음
- 받아야 하는 항목이 많고 정해져있는 경우에 용이
- 필요에 따라 데이터 요청 시 요청 여러번 해야하는 경우 있음
ex) 반의 정보와 학생들 명단 > 두 번 요청해야 함
- 비동기적 코드는 한 번의 요청보다 복잡해짐

• GraphQL
- 필요하지 않은 정보는 제외하고 body에 들어가는 정보로 유연하게 요청 가능 (구현 필요)
- 다른 depth들의 정보도 한 번에 요청 가능 = 클라이언트 구현 편함

같은 API 서버를 쓰더라도 사용자/기기/상황마다 필요로 하는 정보가 다른 서비스에 용이하다

GraphQL 정보요청, 삽입, 수정 방식 = POST

결론
REST API : 요청 단순(URI), 데이터 복잡
GraphQL : 요청 복잡(bracket), 데이터 효율적

백엔드서버에 둘다 구현 가능

GraphQL 구현
방법, 환경, 디테일 가지각색임
> 공식 사이트에 언어마다 라이브러리 제공
(C#/NET, Go, Groovy, Java, Python, Ruby, JavaScript, Kotlin, PHP, Scala, Swift.....)

1) app 이름으로 서버 생성
2) app.use에 인자 넣음 > 이 URI로 GraphQL 요청 받을 준비가 됨

- schema : 데이터 구조/표현법/관계

type Query{
메소드명 : [스키마명]
}

type 스키마명{
컬럼명 : 자료형, ...
}

- resolver : 각 메소드명의 요청마다 실제 작업이 어떻게 진행될지 구현 (하드코딩)

type Mutation{
db작업명(input : 스키마명Input) : Int
}

input 스키마명Input{
컬럼명 : 자료형,...
}

db작업명 : async ({input}) =>
const insertResultData = await new Promise((resolve) =>
connection.query( 쿼리 작성..)

return { idx : insertResultData.insertId }

조만간 얄팍한 코딩사전님 영상 보면서 꼭 실습을 해봐야겠다 ...!


Reference

• Interface : 상호작용

• API ( Aplication Programming Interface): SW가 다른 SW로부터 지정된 형식으로 요청, 명령받을 수 있는 수단

• REST API : 웹>서버, 앱>서버 에 주로 사용되는 서비스 형식(REST)의 API
기존에 복잡했던 SOAP 방식 대체
각 요청이 어떤 동작, 정보를 위한 것인지 그 요청의 모습 자체로 추론가능함

ex) URI : 자원을 구조와 함께 나타냄
https://(도메인)/classes/2/students/15
: 2반의 15번 학생
https://(도메인)/classes/2/students?sex=male
: 남학생 조건
https://(도메인)/classes/2/students?page=2&count=10
: 한페이지에 10명 지정, 즉 11~20번 학생 (2page)

서버에 REST API로 요청 보낼때=HTTP 규약에 따라 신호 전송
- GET/ DELETE/ (BODY) POST/ PUT/ PATCH
body=get, delete 보다 정보를 많이, 비교적 안전하게 보낼 수 있음

• REST API의 보안

1) 인증
- API key : 특정 사용자만 아는 문자열. 클라이언트가 같은 키 공유 > 보안 취약

- API token : id/pw로 사용자 인증 후에 API호출 기한이 있는 토큰 발급 > 토큰으로 사용자 인증
= pw 유출의 연쇄적인 보안 문제 방지

token 방식 :
HTTP Basic Auth : 헤더에 id/pw 인코딩형태(Base64)로 인증
Digest Access Authentication : Base64 인증 단점 보강. 클라이언트가 인증 요청 시 서버로부터 nonce (난수) 발급 받음
id/pw를 nonce를 이용해 해시화, 서버에 전송

2) 인가 : 사용자 권한 체크 (해당 리소스에 대해 사용자가 리소스 사용 권한 있는지)

3) 네트워트 레벨 암호화 (https 보안 프로토콜)



• RESTful :
CRUD를 목적에 따라 구분해서 사용해야 함
URI 는 동사가 아닌 명사로 이뤄져야 함!
(restful api design guidelines 참고)

이어서...
GraphQL : 용도에 따라 REST API의 대안으로 사용됨


Reference
1)

2) 조대협의 서버사이드 : 대용량 아키텍처와 성능 튜닝

SSH 키를 이미 사용 중이라면 다른 git, gitlab 등에서 새로운 SSH키를 사용해야 할 수 있다.

1) SSH 키 생성

Window > Preference > General > Network Connections > SSH2

Key Management의 "Generate RSA key"로 키를 생성한다.

Save Private Key로 키 저장 후 그림에 표시한 노란 부분 텍스트를 전체 복사해 github의 Setting > SSH 키에 등록한다.

2) EasyShell

이클립스 우측상단의 돋보기 아이콘 클릭 후 Marketplace 검색 > EasyShell 플러그인을 설치하면

이클립스에서 git을 커맨드창으로 실행하는 것처럼 사용할 수 있다.

3. Branch 변경

프로젝트 git init 시 기본적으로 그림처럼 master branch를 사용한다.

이클립스에서 브랜치를 추가/변경하려면

프로젝트 우측클릭 > Team > Switch to 에서 설정 가능하다.

• 추가 : "New branch"
• 변경 : "other" > "Remoe Trachking"의 브랜치 선택 후 checkout 

이클립스에서 sun.misc.BASE64Encoder 를 import 하면 access 에러가 발생한다.

Window > Preferences > Java > Compiler > Errors/Warnings > Deprecated and restricted API > Forbidden reference = Warning  (Default=Error)

위처럼 지정 후 Apply 한다.

다시 컴파일 시에도 에러가 발생하면

1) Project > Clean 

2) Problems > errors > Delete

위 단계를 수행한 뒤 다시 컴파일하면 된다.

Warning은 발생하지만 잘 실행된다.

DBeaver에서 Tibero DB에 접속하려면 드라이버 관리자에 Tibero 드라이버를 추가해주어야 한다. 

경로 : 상위탭 > 데이터베이스 > 드라이버 관리자 (Driver Manager) > New

1. 아래 내용 입력

• Driver Name : Tibero
• Class Name: com.tmax.tibero.jdbc.TbDriver
• URL Template : jdbc:tibero:thin:@{host}[:{port}]:{database}
• Default Port : 8629

2. DBeaver lib 경로 (C:\Program Files\DBeaver\jre\lib)에 tibero6-jdbc.jar 파일 추가 

3. Libraries 에 tibero6-jdbc.jar 파일 추가 (위 DBeaver lib 경로의 tibero 파일!)

Connection 새로 추가하면 Tibero가 등록된 것을 볼 수 있다.

IP, DB, 계정정보를 입력하고 Test Connection을 해보면 잘 접속되는 것을 볼 수 있다.

문제 : 

오랜만에 그리디 문제도 풀어봤다.

그리디로 풀어야되는데 감잃고 고냥 조합으로 구하다가 메모리 초과로 실패 한번 띄우고 정렬해서 다시 풀었다.. (반성중)

그리디와 정렬은 뗄 수 없다는 사실!!! 잊지말자!!!!

풀이 1

N=int(input())
t=list(map(int,input().split()))
G=[]

for i in range(N):
    G.append((i+1,t[i]))
G.sort(key=lambda x: x[1])
#print(G)
tmp=res=0
for x,y in G:
    tmp+=y
    res+=tmp
print(res)

파이썬 sort()는 lamba를 이용해서 정렬 조건을 추가할 수 있다.

다중 조건일 때는 튜플을 이용하자  G.sort(key = lambda x : (x[0], -x[1]))

풀이 2

n=int(input())
p = list(map(int,input().split()))
p.sort()

res=[0]*n
res[0]=p[0]
for i in range(1,n):
    res[i] = res[i-1]+p[i]

print(sum(res))

나중에 보니 굳이 튜플로 풀지 않아도 되는 문제여서 다시 풀었다. (속도도 개선됨!)

문제 : 

Solution

import sys
from collections import deque
dq=deque()
op=deque()

N=int(input())
x=int(input())

for i in range(1,x+1):
    dq.append(i)
    op.append('+')

maxx=dq[-1]
dq.pop()
op.append('-')

for i in range(N-1):
    x=int(input())
    while x>maxx:
        maxx+=1
        dq.append(maxx)
        op.append('+')
    if len(dq)==0:
            print("NO")
            sys.exit(0)
    while x<dq[-1]:   
        dq.pop()
        op.append('-')    
    dq.pop()
    op.append('-')

for x in op:
    print(x)

자기 자신도 빼주는게 중요하당

1년 전 C++로 풀었을 땐 틀렸는데 올해 파이썬 시작하고 다시 풀어보니 맞았다,,8ㅅ8

꾸준히 공부하니 조금씩 성장하는게 느껴진다 무야호 ~

문제 :

한 달 전까지 못 풀던 문제를 다시 도전해보았다.

단순 위상정렬로만 접근해서는 틀린다고 나온다 ㅠㅠ 

건물들은 동시에 여러 개를 지을 수 있으므로 의존성 있는 건물 중 오래 걸리는 시간으로 갱신하며 계산되어야 한다..

Solution 1 : 2차원 배열

from collections import deque
N=int(input())
val=[0]*N

G=[[0]*N for _ in range(N)]
degree=[0]*N
dq=deque()

for i in range(N):
    tmp=list(map(int,input().split()))
    val[i]=tmp[0]
    for j in range(1,len(tmp)-1):
        G[i][tmp[j]-1]=1
        degree[i]+=1

res=[0]*N
for i in range(N):
    if degree[i]==0:
        dq.append(i)
        res[i]=val[i]        

while dq:
    x=dq.popleft()
    for i in range(N):
        if G[i][x]==1:
            degree[i]-=1
            res[i]=max(res[i],res[x]+val[i])
            if degree[i]==0:dq.append(i)        

for x in res:
    print(x)

res[i]=max(res[i],res[x]+val[i]) << 이 부분이 핵심이다

첫 번째 풀이는 2차원 배열에 연결성을 부여해 접근하였다.

파이썬의 defaultdict 을 이용하면 선행되어야 하는 건물에 의존적인 건물들을 추가하여 풀이할 수 있다.

개인적으로 첫 번째 풀이가 맘에 들지만 아래처럼 접근해야 하는 경우도 있을 것 같아 추가한다.

Solution 2 : defaultdict

from collections import deque, defaultdict
N=int(input())
val=[0]*N

G=defaultdict(list)
degree=[0]*N
dq=deque()


for i in range(N):
    tmp=list(map(int,input().split()))
    val[i]=tmp[0]
    for j in range(1,len(tmp)-1):
        G[tmp[j]-1].append(i)
        degree[i]+=1

res=[0]*N
for i in range(N):
    if degree[i]==0:
        dq.append(i)
        res[i]=val[i]        

while dq:
    x=dq.popleft()
    for y in G[x]:
        res[y]=max(res[y], res[x]+val[y])
        degree[y]-=1
        if degree[y]==0:
            dq.append(y)

for x in res:
    print(x)

이런식으로 선행되어야하는 건물: [의존건물들] 로 딕셔너리가 형성된다. 

(defaultdict는 딕셔너리를 리스트처럼 사용할 수 있게 해주는 라이브러리)