Programming

안녕하세요. 생활코딩에 글을 올리는 것은 처음입니다.

https://semver.org/lang/ko/ 를 정리해서 프레젠테이션으로 만들어 봤습니다.

다만 약간 글자가 많아 번잡해 보입니다. 만드는데는 한 3시간 반정도 걸린듯 합니다. 많이 사용해주시면 감사드리겠습니다.

깃허브를 통해 배포하고 있습니다. 또한 MIT 라이센스로 배포되지만 일부 제약 사항에 대해서는 맨 마지막 장을 참고하여주시기 바랍니다.

아래 링크를 누르시면 바로 다운로드됩니다. PPT와 PDF 두 종류로 모두 제공합니다.
https://github.com/Shin-Jae…/…/raw/master/develop/유의적버전.pptx

https://github.com/Shin-JaeH…/…/raw/master/develop/유의적버전.pdf


유의적 버전

신재헌(Shin-JaeHeon)

20180902일 제작됨, v1.0.0

https://github.com/Shin-JaeHeon/ppt/blob/master/develop/유의적버전.pptx 

CC BY 3.0으로 배포되는 https://semver.org/lang/ko/의 내용을 참고 했습니다


  2. 목차

  • 유의적 버전이란?
  • 왜 유의적 버전을 사용해야 하나요?
  • 유의적 버전을 쓰는 방법
  • 우선순위
  • 이래서 유의적 버전을 사용하고 있습니다.
  • FAQ
  • 작성자 및 라이선스 안내

3. 유의적 버전이란?

버전을 통해 API의 변경을 표현하는 명세입니다

버전은 X.Y.Z (주.부.수)로 표현합니다

4. 왜 유의적 버전을 사용해야 하나요?

나날이 소프트웨어의 의존성은 증가하고 있습니다

어느 버전까지 호환되는지를 알아보는 것은 비용이 많이 듭니다

매번 Readme.md를 읽어볼 수는 없습니다

기존의 소프트웨어와 테스트를 하는 것은 귀찮고 힘들고 시간과 비용이 많이 듭니다

편하게 의존성 관리를 하고 싶으면 유의적 버전을 사용해야합니다

5. 왜 유의적 버전을 사용해야 하나요?

  명시적인 정의와 규칙이 존재합니다

앞으로도 계속해서 같은 규칙으로 버전을 작성할 것입니다

사용자에게 개발자의 의도를 쉽게 표현할 수 있습니다

시간과 비용을 절약할 수 있습니다

6. 유의적 버전을 쓰는 방법

버전은 숫자로 합니다

식별자는 한 글자 이상으로 합니다

숫자는 절대로 앞에 0을 붙이지 않습니다

  • O 1.2.3
  • X 1.2.03

표현은 X.Y.Z (주.부.수)

1.0.0은 공개 API를 정의합니다

7. 유의적 버전을 쓰는 방법

기존 버전과 호환되지 않으면 주 버전을 올립니다.

 기존 버전과 호환되면서 기능이 추가되면 부 버전을 올립니다

기존 버전과 호환되면서 버그를 수정한 것이면 수 버전을 올립니다

모든 버전은 증가합니다

8. 유의적 버전을 쓰는 방법

공개 API에 기존과 호환되는 새로운 기능을 추가하는 경우

반드시 부(x.Y.z | x > 0)버전을 올립니다

공개 API의 일부를 앞으로 제거(deprecate)할 경우에도 수 버전을 올립니다

부 버전이 올라가면 수 버전은 0부터 다시 시작합니다

수 버전(x.y.z | x > 0)은 반드시 기존과 호환되는 버그 수정의 경우

버그 수정은 잘못된 내부 기능을 고치는 것으로 정의합니다

9. 유의적 버전을 쓰는 방법

주 버전의 변경은 부 버전이나 수 버전급 변화를 포함할 수 있습니다

부 버전과 수 버전을 0으로 초기화합니다

특정 버전을 배포 후에는 절대로 내용을 변경할 수 없습니다

변경점이 생기면 반드시 새로운 버전으로 배포해야 합니다

주 버전 0(0.y.z)은 초기 개발을 위해 사용합니다

이 버전은 안정적이지 않은 편으로 보는 것이 좋습니다

10. 유의적 버전을 쓰는 방법

정식 배포를 앞둔(pre-release) 버전의 표기 방법

수 버전 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 사용할 수 있습니다

식별자는 아스키 문자, 숫자(앞에 0을 붙이지 않습니다), 붙임표로 하고 한 글자 이상으로 합니다

  •   [0-9A-Za-z-]

예시

  • 1.0.0-alpha
  • 1.0.0-alpha.1
  • 1.0.0-0.3.7
  • 1.0.0-x.7.z.92

정식 배포 전 버전은 보통 버전보다 우선순위가 낮습니다

정식 배포 전 버전은 아직 불안정할 수 있습니다

연관된 일반 버전에 대한 호환성 요구 사항이 충족되지 않을 수 있습니다

11. 유의적 버전을 쓰는 방법

빌드 메타데이터의 표기 방법

수 버전이나 정식 배포 전 식별자 뒤에 표현할 수 있습니다.

더하기(+) 기호를 사용합니다

식별자는 아스키 문자, 숫자, 붙임표로 하고 한 글자 이상으로 합니다

  •   [0-9A-Za-z-]

빌드 메타 데이터는 버전 간의 우선순위를 판단하는데 사용하지 않습니다

빌드 메타 데이터만 다른 두 버전의 우선순위는 같습니다

예시

  • 1.0.0-alpha+001
  • 1.0.0+20130313144700
  • 1.0.0-beta+exp.sha.5114f85

12. 우선순위

우선순위의 계산 방법

주, 부, 수 버전, 정식 배포 전 버전의 식별자를 나누어 계산합니다

빌드 메타 데이터는 우선순위에 영향을 주지 않습니다

차이가 나는 부분이 나타나면 결정됩니다

주, 부, 수는 숫자로 비교합니다

  • 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1

13. 우선순위

주, 부, 수 버전이 같은 경우 정식 배포 전 버전이 표기된 경우가 더 낮습니다

반드시 마침표로 구분된 식별자를 차례대로 비교하면서 차이점을 찾습니다

숫자로만 구성된 식별자는 수의 크기로 비교합니다

알파벳이나 붙임표가 포함되면 아스키 문자열 정렬을 합니다

숫자로만 구성된 식별자는 어떤 경우에도 문자와 붙임표가 있는 식별자보다 낮습니다

앞선 식별자가 모두 같은 배포 전 버전의 경우에는 필드 수가 많은 쪽이 더 높습니다

예시

  • 1.0.0-alpha < 1.0.0-alpha.1
  • 1.0.0-alpha.1 < 1.0.0-alpha.beta
  • 1.0.0-alpha.beta < 1.0.0-beta
  • 1.0.0-beta < 1.0.0-beta.2
  • 1.0.0-beta.2 < 1.0.0-beta.11
  • 1.0.0-beta.11 < 1.0.0-rc.1
  • 1.0.0-rc.1 < 1.0.0

14. 이래서 유의적 버전을 사용하고 있습니다

Car이라는 라이브러리가 있다고 예를 들면,

이 라이브러리는 유의적 버전이 적용된 Engine이라는 라이브러리에 의존합니다

Car라는 라이브러리를 만들었을 때 Engine은 3.1.0 이었다면,

Car는 Engine이 3.1.0일 때 처음으로 추가된 기능을 사용했습니다

그러므로 Engine의 의존성으로 3.1.0 이상, 4.0.0 미만으로 지정할 수 있습니다

이제 Engine의 3.1.1 버전과 3.2.0 버전이 공개되었다면,

패키지 관리 시스템에 그 버전을 넣을 수 있습니다.

또한 기존의 소프트웨어와 호환될 것이라고 알 수 있습니다.

15. FAQ

초기 개발 단계에 0.y.z 버전 관리 방법은 무엇인가요?

가장 간단한 방법은 최초 개발 배포를 0.1.0으로 합니다

그리고 이후 배포마다 부버전을 올리는 것입니다

언제 1.0.0을 배포해야 할지 어떻게 알 수 있나요?

 소프트웨어가 실 서비스에 쓰이기 시작했다면 1.0.0이라 여길 수 있습니다

사용자들이 믿고 쓸 수 있는 안정한 API가 있으면 1.0.0일 것입니다

하위 버전 호환성에 대해 우려하기 시작했다면 이미 1.0.0일 수 있습니다

16. FAQ

유의적 버전 짓기가 빠른 개발을 방해하지 않을까요?

주 버전 0이 신속한 개발을 위한 것입니다

만약 API를 매일같이 바꾸고 있다면 0.y.z 버전을 쓰거나

별도의 다음 번 주 버전 배포를 앞둔 개발 브랜치를 사용해야 합니다

17. FAQ

주 버전을 사소한 이유로 매번 올리면 금새 버전이 42.0.0이 되어버리지 않나요?

의존하는 코드가 많은 소프트웨어에, 호환되지 않는 변화를 가볍게 도입해서는 안됩니다

주 버전을 업그레이드하는데 필요한 비용이 어마어마해질 수 있습니다

바뀌는 부분에 인한 여파와 그 비용과 혜택을 충분히 평가해야 합니다

18. FAQ

공개 API 전체를 문서로 만드는 것은 일이 너무 많지 않나요?

다른 사람들이 쓰라고 만든 것을 적절히 문서로 만드는 것은 책임입니다

효율적인 프로젝트를 유지하기 위해 복잡성을 관리하는 일 중요한 일입니다

유의적 버전을 사용하고 잘 정의한 공개 API가 편리합니다

19. FAQ

부버전을 올렸는데, 실수로 호환되지 않는 변경이 들어갔습니다.

유의적 버전 명세를 어겼다는 사실을 알게 되면, 즉시 문제를 해결하도록 합니다

호환성이 깨진 부분을 복구해서 새 부버전을 배포합니다

이 경우라도 이미 배포된 버전을 변경해서는 안됩니다

필요한 경우라면 문제가 되는 버전을 문서로 표시하여 이용자로 하여금 주의하도록 합니다

20. FAQ

공개 API는 유지한 채 내부의 의존성 변경은 가능한가요?

  공개 API에 영향을 주지 않으므로 호환된다고 여깁니다

변화가 수 버전 수준인지 부 버전 수준인지 결정하는 것은

버그를 수정하고자 한 작업인지

새로운 기능을 추가하기 위해서인지

후자의 경우, 추가적인 코드를 예상할 것입니다

그렇다면 부 버전의 증가는 당연합니다

21. FAQ

실수로 버전 증가와 맞지 않게 공개 API 변경을 했습니다

수 버전 배포에서 잘못된 코드가 들어가서 깨지게 된 경우에

공개 API가 원래 의도했던 대로 사용될 수 있게 바꾸는 작업에 영향받는 사람이 많다면

수정사항이 엄밀히 따지면 수 버전 배포로 여겨져야 한다 하더라도

주 버전 배포를 하는 것이 최선일 것입니다

유의적 버전은 어떻게 버전이 바뀌는지 의미를 전달하는 것이 전부입니다

변경이 사용자에게 중요한 의미가 있다면, 버전 번호로 잘 알릴 수 있도록 합니다

22. FAQ

제거하는 기능에 대해서는 어떻게 할까요?

문서를 업데이트해서 사용자들에게 변화를 알립니다.

해당 기능이 제거될 거라 표시된 새 부 버전을 적절한 시기에 배포합니다

새 주 버전에서 완전히 기능을 제거하기 전에 제거될 것이라 표시한 부 버전 배포를 진행합니다

사용자들이 원활하게 새로운 API를 사용할 수 있도록 해야 합니다

23. FAQ

유의적 버전의 문자열 길이 제한이 있습니까?

  없더라도 255자의 버전 문자열은 지나치게 긴 것임이 틀림없습니다

간결할 수록 버전을 읽기가 편리합니다

24. 작성자 및 라이선스 안내

유의적 버전 명세는

그라바타(Gravatars)의 창시자이자 깃허브(GitHub)의 공동창업자인

톰 프레스턴-베르너(Tom Preston-Werner)가 작성했습니다.

  유의적 버전의 한국어 번역은

김대현(http://hatemogi.com/)님이 했습니다

번역과 관련된 의견은 한국어판 유의적 버전 깃허브 프로젝트에 이슈를 남겨주세요

이 프레젠테이션은

신재헌(https://github.com/Shin-JaeHeon)이 제작했습니다

관련된 의견은 깃허브에 이슈를 남겨주세요

MIT 라이선스로 배포되지만 반드시 아래의 내용이 포함되어야 합니다.

  •   https://github.com/Shin-JaeHeon/ppt/blob/master/develop/유의적버전.pptx
  •   CC BY 3.0으로 배포되는 https://semver.org/lang/ko/의 내용을 참고했습니다.
  •   제작자 : 신재헌(Shin-JaeHeon) (한/영 표기가 필수입니다)


'Programming' 카테고리의 다른 글

유의적버전에 대해 정리한 프레젠테이션을 배포합니다.  (0) 2018.09.03
robots.txt  (0) 2017.08.15
SHA란?  (0) 2017.08.15

robots.txt

2017.08.15 23:48

robots.txt는 웹 크롤러같은 로봇들의 접근을 제어하기 위한 규약이다. 한마디로 검색엔진봇이 접근하지 말아야하는 경로같은것을 의미한다.

참고로 robots.txt는 권고사항임으로 지키지 않는 봇이 나타날 순 있다. robots.txt는 웹사이트의 루트경로에 있어야한다. (a.com/robots.txt)

디텍토리의 뒤에는 반드시 /을 붙여야하는데, 아래와같이 사용할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
User-agent: abc
Allow: /abc/def/ 
 
User-agent: abc
Disallow: /abc/def/
 
User-agent: *
Allow: /
 
User-agent: *
Disallow: /
 
cs

첫번째는 User-agent가 abc인 봇이 /abc/def/에 접근하는것을 허용한다는 뜻이고,

두번째는 User-agent가 abc인 봇이 /abc/def/에 접근하는것을 불허한다는 뜻이다.

세번째는 모든 봇에대해 모든 경로를 허용하는 것이고,

네번째는 모든 봇에게 모든 경로를 불허하는 것이다. (즉, 사이트 크롤링 금지)

'Programming' 카테고리의 다른 글

유의적버전에 대해 정리한 프레젠테이션을 배포합니다.  (0) 2018.09.03
robots.txt  (0) 2017.08.15
SHA란?  (0) 2017.08.15

SHA란?

2017.08.15 23:29

SHA는 미국 NSA(국가안보국)가 제작한 해시 암호알고리즘이다.

SHA-0 부터 최신버전인 SHA-3이 존재한다. 그러나 SHA-0과 SHA-1은 보안상 위험하기때문 보안이 중요한 곳에서는 사용해서는 안된다.

SHA는 눈덩이 사태를 일으키기 때문에 조금이라도 값이 다르면 전혀 다른값이 튀어나오게된다.

알고리즘별 속도

Skylake에서 다양한 해시 함수의 속도 측정[각주:1]

"apple"의 해시값을 구해보면 아래와 같다.

SHA-1 : D0BE2DC421BE4FCD0172E5AFCEEA3970E2F3D940 

SHA-256 : 3a7bd3e2360a3d29eea436fcfb7e44c735d117c42d1c1835420b6b9942dd4f1b

SHA-512 : 844D8779103B94C18F4AA4CC0C3B4474058580A991FBA85D3CA698A0BC9E52C5940FEB7A65A3A290E17E6B23EE943ECC4F73E7490327245B4FE5D5EFB590FEB2


  1. http://keccak.noekeon.org/ [본문으로]

'Programming' 카테고리의 다른 글

유의적버전에 대해 정리한 프레젠테이션을 배포합니다.  (0) 2018.09.03
robots.txt  (0) 2017.08.15
SHA란?  (0) 2017.08.15

DB백업하기

2017.08.15 20:47

::: 서버 DB가 날라가서 쓰는글 :::

MariaDB나 Mysql에서 사용할 수 있다.


mysqldump -u[userId] -p[password] --all-databases > backup.sql

위의 명령어는 서버의 모든 데이터베이스를 backup.sql로 저장하는것이고,

mysqldump -u[userId] -p[password] --databases [DatabaseName] > backup.sql

위의 명령어는 특정 데이터베이스를 backup.sql로 저장하는것이다.


복원하려면 mysql 접속후에 아래의 명령어를 사용하면된다.

mysql> source dump.sql


DB백업과 파일백업은 필수입니다.

'Programming > SQL' 카테고리의 다른 글

DB백업하기  (0) 2017.08.15

 RPC framework라는것을 배웠는데, 참 편리한거 같다.

 RPC는 Remote procedure call의 약자로 원격으로 프로시저를 호출한다고 할 수 있다. 또한 네트워크나 콜방식에 상관없이 프로그래머가 원격으로 함수를 실행할 수 있게 해준다. 또한 IDL을 사용한다.

게임서버에 RPC Framework를 적용한것에 배웠다.

먼저 페이스북에서 만든 Thirft다.

Thrift (θrift)
•“scalable cross-language services development” 를 위해 Facebook
에서 개발, RPC framework 로 사용됨
•다양한 언어를 지원 ( http...[각주:1]

Thrift
•Server, Processor, Protocol, Transport 로 구성
•Thrift 를 통해서 code 생성을 하면 RPC Client 코드도 생성
•서버 / 클라이언트 의 가장 큰 차이는 당연하...[각주:2]

간단히 Register - Login 서버를 짠다고 치면 아래와 같이 짤 수 있다.

othello.thrift
namespace csharp othello
struct User {
1: optional i64 id=0;
2: optional string token="";
3: optional strin...[각주:3]

먼저 왼쪽에는 유저와 플랫폼 타입을 설정했다.  ※Thrift는 Unsigned를 구별하지 않는다.

그다음 위쪽 동그라미는 , exception을 통해 에러를 반환할 수 있게한다.

그다음 아랫쪽 동그라미는 서비스 부분으로 User Register의 input parameter을 설정하고 thorows도 설정한다.

othello.server.py
import asyncio
import thriftpy
from aiothrift.server import create_server
# ...
othello = thriftpy.load(...[각주:4]

다음은 서버부분인데, 이 부분은 제대로 이해는 안되었으나 이해한 바로는 서버를 생성하고, 서비스를 넣어주며, 핸들러를 받고, 서버설정을 하고, 프로토콜을 넣어준다.

아래코드는  Login과 Register을 받으면 코드를 실행하고 user를 반환하게되는데,  아래 이미지에 있는 설명 처럼 db_transaction을 작성함으로써 processor에 반영하고 오류발생시 db를 rollback하는 것 까지 완료하였다.othello.server.py
class Dispatcher:
# ...
@db_transaction
def Login(self, platform_type, platform_token):
# ...
return use...[각주:5]

  1. 저작자 : 박준철, https://www.slideshare.net/joongom/python-rpc-framework-78718414 [본문으로]
  2. 저작자 : 박준철, https://www.slideshare.net/joongom/python-rpc-framework-78718414 [본문으로]
  3. 저작자 : 박준철, https://www.slideshare.net/joongom/python-rpc-framework-78718414 [본문으로]
  4. 저작자 : 박준철, https://www.slideshare.net/joongom/python-rpc-framework-78718414 [본문으로]
  5. 저작자 : 박준철, https://www.slideshare.net/joongom/python-rpc-framework-78718414 [본문으로]

https://www.slideshare.net/hongjoo/speaker-diarization


# What us Speajer Diarization

    * Audiotrack 

    * Segmentation : 분리

    * Clustring : Speacker별로

# Time domain vs Frequency domain

    * TimeDomain -> Frequency domain(3D)

# Feacture Extraction

    * 20~30ms단위로 쪼갬 

    * 10ms 정도로  overlaping되게 움직임

# Time domain to Frequency domain

    * 고음역대 -> 저음역대(8khz미만으로 이동) Mel 스펙트럼

# Chromagram

    * 12음계로 쪼개서 그 피치를 표시

# Mel-Frequency Cepstral Coefficients

    * Scale

# Segmentation

    * Wave -> Cromagram

    *  2~5s 간격으로

    * 각 음계별로 가장 maximum 부분을 구별해낸다.

    * 12 * N개의 매트릭스를 만들 수 있다.

# Clustring

    * k-means

        * 가까운것들을 묶고 센터를 정해서 계속 샌트로이드가(Centroids) 일정한 위치가 되도록 

        * 썩 좋은 방법은 아니다.

        * 남자와 여자들이 많을때에는 피치가 구분이 잘 안된다. 

        * 피치가 섞이는것은 좋지 않다.

        * 동시에 말하는 경우 : 구별이 힘들다.

# Use MFFC

    * 가변적인 Segmentation

    * Speaker와 Speaker사이에 변환되는 지점을 찾는다.

    * 두사람의 목소리들을 MFCC의 가옵션 그래프를 그리면 다르게 나르게 난다.

    * 프레임이 흐를때 바뀌는 부분을 찾느다.

# Bayesian Inforamtion Criterion

    * MOdesl selection;

    * 주어진 모델에서 그것이 발견될 확률을 구하는것.

    * 이 모델이 이 데이터에 적합하는가를 구하는 function과 비슷.

    * Window를 왼쪽에서 오른쪽으로 움직이면서 모델이 한인안 경우와 2개 경우의 BIC 더 좋은지 찾는다.

    * BIC가 Maximum되는 부분이 Speacker가 바뀌는 부분

    * Code

        * rang_n_cluster : 클러스트 구별

    * 맨 왼쪽의 그래프는 (maximum = 1 minmum = 0)으로 그린것으로, 0으로 가까울수록 적합한 Cluster의 갯수임을 알 수 있다.

# Agglomerative CLustring

    * 제일 가까은 cluster를 merge하고 이 과정을 계속 반복하여 모든 데이터가 하나의 cluster가 될때까지 돈다.

    * linkage : Cluster와 Cluster의 거리를 구하는 방법을 정의

    * Code

        * arr 설명 : fst | sec | dis | 갯수

# Hierarchical Clustering & Dendrogram

    * Dendrogram을 그려보면 어디서 끊어야할지(예: 5번같은경우는 이상하다. 그런데 대부분 1미만이다. 5번만 클러스트 한개를 차지한다.)

# Agglomerative CLustring

    * 색깔별로 같은 사람의 목소리라고 치면

    * BIC값을 제일 가까운것을 뽑아서 계속 묶는다. △BIC(C9,C10) < 0일때까지만 묶어도된다. (∴ Speacker = 3)

Python Django 와 AWS로 쇼핑몰 만들기

쇼핑몰의 특징 :  제품에 딸린 정보가 많음.

    * 제품

    * 장바구니

    * 관리연동

    * 관리자 페이지

    * 매출 통계

    * 비동기 작업 / 작업 스케출링


직접 개발의 장점

    * 차별화된 UI/UX

    * 자유도 높은 프로모션/이벤트 가능

    * 방문 고객에 대한 세밀한 분석


왜 직접 개발해야하는가? 고민해볼 것들:

    * 유지보수 이슈 발생

    * 타 솔루션보다 좋은가?


기본 프로세스

   고객 : 제품 > 장바구니 > 결제

   관리자 : 관리자페이지 / 매출 통계 / 비동기작업

   메일링 등등


제품

    * 제품의 정부(고객 side, 물류 side, 관리자 side 30개 이상의 attribute 필요

    * 하나의 모델에 넣을경우 유지보수가 어려움


카테고리 기능은 필수!

    * 3depth 이상의 복잡한 구조의 경우 Foreign key : Foreign key Hell

# Django-mptt


장바구니 : 주문을 위한 시작점

        * 상품담기, 수량변경, 삭제

    Django-carton : 장바구니 라이브러리(Session 기반)


추가적인 요구사항(주문총액/상품종류에 따른 배송비 처리기능 구현)


로그인 한 유저에 대해 JSON serialize로 DB저장

    * 분석가능


PG직접연동은 하지말것 : 지옥문


I'mport;(아임포트)를 사용하는것이 좋음


Django admin

    * 대상 : 개발자 or 최종관리자(MD)

    * Django-Grappelli : 보완

    * Django-summernote : Summernote의 Django Add-on

    * Django Firn Assets.


직접 개발

    * Admin LTE (Bootstrap 기반)


매출 통계

    * Djpoango aggregation

    * cacheops

    * Google chart

DevOps  - Cloud 필수



+ Recent posts

티스토리 툴바