Gulp.js – 빌드 자동화 도구 사용하기

Gulp.js ?

Node.js 의 여러 모듈중 하나로 코드난독화, 최적화 등의 빌드 기능을 쉽게 처리할 수 있게 도와준다.

설치

다음 명령어를 통해 gulp를 전역으로 설치한다.

$ npm install gulp – g

다음 명령어를 통해 설치되어 있는 gulp의 버전을 확인 할 수 있다.

$ gulp -v

더 자세한 설치 방법은 링크 참조.

사용

  • 의존성 패키지를 설치

$ npm install--save-dev gulp gulp-util

  • gulp 플러그인을 설치

npm install--save-dev gulp-uglify gulp-concat

코드를 최소화/압축하는 uglify와 자바스크립트 파일들을 하나로 합쳐주는 concat 플러그인을 설치했다.

  • 프로젝트의 루트 폴더에 gulpfile.js 파일을 생성

사용할 플러그인을 선언하는 코드를 추가한다.

var gulp = require('gulp');
vargutil = require('gulp-util');
var uglify = require('gulp-uglify');
var concat  = require('gulp-concat');

 

작업을 정의하는 task() 메소드를 추가한다.
gulp.task('js', function() {
    gulp.src('./**/*.js')
        .pipe(uglify())
        .pipe(concat('min.js'))
        .pipe(gulp.dest('./dist'));
});

gulp.src('./**/*.js') 으로 타겟이 되는 js파일목록을 프로젝트에 포함되는 모든 폴더로 지정한다.
이어지는 작업들은 은 .pipe() 메소드를 통해 정의한다.
.pipe(uglify()) : 코드 난독화
.pipe(concat('min.js')) : src()a로 지정된 파일목록을 하나의 파일로 만들어 min.js 에 저장
.pipe(gulp.dest('./dist'));: 저장할 경로를 지정

  • js 태스크를 실행한다.

$ gulp.task('js');

Nexus 3.x를 이용한 사설 NPM 저장소 만들기

Nexus – npm 저장소의 필요성

  •  npm 저장소에 프록시 역할을 해줌
  •  내부적으로 만든 node 모듈이나 라이브러리의 배포를 npm을 통해 쉽게 할 수 있음

Nexus 3.x – Linux(CentOS) 설치

Nexus 3.x 설치 관련 공식 문서

리눅스용 배포판의 경우 Java 8 Runtime Environment (JRE)가 필요하다. 설치 되어 있지 않을 경우 Oracle 웹 사이트 에서 최신 버전의 Java 8을 설치한다.

참고 – 생활코딩 – 리눅스에 Java 다운로드해서 설치하기

Nexus 3.x 버전을 다운 받은 후 압축을 해제한다. ( 3.9.0-01 버전 기준으로 설명함 )

$ wget https://sonatype-download.global.ssl.fastly.net/nexus/3/nexus-3.9.0-01-unix.tar.gz

$ tar -xvzf nexus-3.9.0-01-unix.tar.gz

압축을 해제하면 nexus 3-3.9.0-01 라는 Nexus Repository Manager 어플리케이션 폴더와 sonatype-work 라는 저장소, 설정, 캐시 등의 모든 데이터가 하위 폴더로 저장되는 폴더가 보인다.

Nexus가 사용하는 8081 포트를 열어준다.

$ firewall-cmd –zone=public –permanent –add-port=8081/tcp
$ firewall-cmd –reload\

Nexus를 실행한다.

$ ./nexus run

—————————————————————-
Started Sonatype Nexus OSS 3.9.0-01
—————————————————————-

실행에 성공하면 위에 문구가 나온다.

브라우저에서 서버주소와 포트번호를 입력하면 Nexus Repositoty Manager 관리자 페이지로 접속 할 수 있다.

1.PNG

기본 ID와 비밀번호는 admin / admin123 으로 설정되어 있다.

NPM 저장소 설정하기

Administration 탭으로 이동 후 Repositories 항목을 선택한다.

2.PNG

Repositrory 에서는 npm 뿐만 아니라 여러 format의 저장소를 만들수 있다.

각 format의 저장소는 3가지 type을 가질수 있다.

  • proxy : 외부의 다른 경로를 proxy하는 역할.
  • hosted : 자체 모듈 저장소
  • group : proxy 와 hosted 들을 묶을 수 있는 단위 집단. 나열하는 순서가 라이브러리 탐색의 우선순이가 됨.

Create repository 버튼을 눌러 npm (hosted) 를 선택하고 다음 선택하여 자체 모듈 저장소를 만든다.

3.PNG

npm (proxy ) 를 선택하고 다음 선택하여 proxy저장소를 만든다.

4.PNG

npm (group) 를 선택하고 다음 선택하여 위에 만든 두개의 저장소를 묶어준다.

5.PNG

내부 NPM 저장소 사용하기

사용

npm 의 –registry 명령어를 사용하면 기본 저장소 대신 지정된 저장소를 사용할 수 있다.

npm –registry http://192.168.0.45:8081/repository/npm-group/ install ~

(192.168.0.45 는 알맞은 서버주소로 바꿔준다.)

각각 프로젝트에 .npmrc 파일을 만들어 저장소의 아래와 같이 위치를 지정하면 –registry 명령어 없이도 지정된 저장소를 사용할수 있다.

registry=http://192.168.0.45:8081/repository/npm-group/

배포

내부적으로 만든 라이브러리를 배포할때는 group 대신에 hosted 저장소를 사용해야한다.

배포에 앞서, login 명령어를 통해 로그인한다. 따로 아이디를 만들지 않았으면 기본으로 설정되어 있는 admin으로 로그인 한다. 이때 email주소는 기본정보와 달라도 상관 없다.

npm –registry http://192.168.0.45:8081/repository/npm-private/ login

6.PNG

public 명령어를 통해 pacage.json에 설정된 name 과 version으로 프로젝트를 배포할 수 있다.

npm –registry http://192.168.0.45:8081/repository/npm-private/ publish

한번 배포된 프로젝트는 버전을 다르게해야 재배포 할 수 있다.

package.json 에 아래 옵션을 넣어주면 publish의 저장소 위치를 지정 할 수 있다.

“publishConfig”: { “registry”: “http://192.168.0.45:8081/repository/npm-private/” }

배포된 모듈 및 라이브러리는 nexus 관리자 페이지의 브라우저 탭을 통해서 확인 가능하다.

7.PNG

[버전관리] Base

버전 관리(version control, revision control) 란?

동일한 정보에 대한 여러 버전을 관리하는 것을 말한다. 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는데 사용된다. 그러한 문서의 변경 사항들에 숫자나 문자로 이뤄진 (“개정판 번호”나 “개정판 레벨”이라고도 불리는) “버전”을 부여해서 구분한다. “버전”을 통해서 시간적으로 변경 사항과 그 변경 사항을 작성한 작업자를 추적할 수 있다. 간단한 버전 관리 방법으로는 처음 작성한 코드에 버전 번호 1을 부여한다. 변경 사항이 생기면, 버전 번호를 2로 증가시킨다. 이처럼 추후 변경 사항이 발생 시마다 버전 번호를 1씩 증가시킨다.

소프트웨어 엔지니어링에서는 일반적인 소프트웨어 소스 코드만을 관리하는 내역을 주로 버전 관리라고 정의하게 된다. 일반적으로 산업 공학이나 이전 생산 기반 제조 공학 등에서 소프트웨어 쪽으로 넘어오는 학문적 관심에 의해 이전 생산 공학에서 사용하던 개념을 가져오게 되었고, 그에따라 버전 관리(Software Version Management)와 형상 관리(Software Configuration Management)의 개념들이 따라왔다고 볼 수 있겠다.

한국의 경우, 대부분의 서적들이 일본어를 거쳐 중역(重譯)되면서 오역된 경우가 많고 관련된 분야에 대해 정확하거나 깊은 이해 없이 단순 소개하며 넘어간 경우가 대부분이라 아직도 정확한 버전 관리와 형상 관리의 구분이나 이해가 없다고 보는 것이 맞다.

버전 관리 소프트웨어 도구들은 거의 모든 소프트웨어 개발 프로젝트에서 필수적인 요소로 인식되고 있다.

[출처 : 위키백과]

 

빌드관리는 정해진 형식이 없다. 작업자와 해당 버전에 대한 규정을 정해놓고 진행하면 된다.

간단한 예를 들자면 작업용 빌드의 g0.001.0721.03라는 버전이 존재

g0 : google 빌드한 0번째 버전 [대규모 업데이트 등]

001: 등록한 횟수

0721: 날짜

0.3: 세번째로 빌드한 버전

 

배포용 빌드의 버전은 작업용빌드와 순서만 맞춰주면 된다.

Unity3D Create And Download AssetBundle

에셋번들의 생성부터 적용과정, 간단한 관리에 대한 설명과

프로젝트에 에셋 번들을 적용하는 과정에서 생긴 이슈에 대한 글입니다.

에셋 번들의 사용 목적

대부분의 개발자들은 다음과 같은 목적으로 AssetBundle을 적용하려 할 것입니다.

  • 클라이언트 APK를 Resource와 분리시킨다. (APK 용량 감소를 통한 마켓 업로드)
  • Resources폴더의 파일을 최대한으로 줄여 메모리(RAM) 사용량을 감소시킨다.
  • 에셋 번들 버전 업데이트를 통해 APK 교체없이 Prefab, Model 데이터를 변경한다.

제작시 고려 사항

  • 에셋 번들의 데이터 및 버전은 어떻게 관리될 것인가 ?
  • Network와의 연결이 불안정할 경우 예외는 어떻게 처리할것인가 ?
  • Android, IOS 에서 파일 관리는 어떻게 이루어질 것인가 ?
  • Prefab간 상호 의존 (Dependence)에 따른 로딩 순서 및 로딩은 어떻게 이루어 질 것인가?

제작 과정

  1. 에셋 번들 생성 스크립트
  2. 에셋 번들 Export
  3. NAS 또는 HTTP 업로드 후 다운로드
  4. 더 개선할 방향 및 Dependence 관리

에셋 번들 생성 스크립트

구글에 검색시 대표적으로 나오는 코드중 한개입니다.

캡처

주의 : Project/Editor 폴더에 해당 스크립트를 생성해야 합니다. 그렇지 않을경우 에러가 발생합니다.

해당 코드를 생성, 저장 한뒤 유니티 에디터를 확인하면 다음과 같은 메뉴가 생성됩니다.Button.png

앞으로 이 버튼을 이용해서 에셋 번들을 생성하게 됩니다.

에셋 번들 Export

에셋 번들을 생성하고자 하는 프리팹을 선택한뒤 Inspector 창을 보면 다음과 같은 부분이 보입니다.

Inspector

Prefab으로 만들어져 있는 대상에서만 다음과 같이 보이게 됩니다.

밑의 AssetBundle을 보면 hawaii_couse라고 되어있습니다. 현재 이 프리팹은 추출하게 되면 hawaii_couse라는 에셋 번들로 추출됩니다. 사진과 같이 설정하기 위해서 먼저 AssetBundle 오른쪽의 hawaii_couse가 적혀있는 칸을 클릭하세요

AssetBUndle2

아직 설정이 되어있지 않다면 None으로 되어있을 것입니다. New버튼을 누른다음 자신이 원하는 이름으로 설정해 주세요 원하는 이름을 작성한뒤 엔터를 누르면 해당 이름으로 설정됩니다.

  1. 사용하지 않는 이름은 지우고 싶다면 Remove Unused Names를 클릭하면 자동으로 사용하지 않는 이름을 모두 지워줍니다.
  2. 한개의 에셋 번들에 여러 프리팹의 데이터를 담고싶다면 프리팹들의 에셋 번들 이름을 같은 이름으로 설정하면 됩니다.

설정이 끝났다면 방금 만든 메뉴버튼을 클릭, 파일로 Export 합니다. 추출된 파일은 Project 탭에서 AssetBundles 폴더에 담기게 됩니다. 추출이 끝났다면 탐색기에서 다음과 같은 파일들을 확인할 수 있습니다.

탐색기.PNG번들은 1개 생성되었지만 파일은 8개 있습니다. 여러분이 실질적으로 사용할 파일은 hawaii_couse 입니다. 다른 이름으로 지정했다면 해당 이름으로 생성된 파일입니다. manifest, manifest.meta, meta 파일은 실질적으로 사용할 일이 없으며 버전 관리가 필요할 경우 AssetBundles 파일을 이용하면 좀더 간편하게 할 수 있습니다. (에셋 번들을 생성할때 번들들에 대한 정보가 들어있습니다.)

NAS 또는 HTTP 업로드 후 다운로드

서버가 구축되어 있지 않거나 간단한 테스트를 원하는 상태라면 NAS를 연결, 이용하거나 CAFE24와 같은 호스팅센터를 이용해서 파일을 업로드 하세요. 유니티에서 에셋번들 데이터를 다운로드 하기 위해서는 URL 주소가 필요합니다. 단순히 실험만 할것이라면 file://C:\Users 와같은 경로로 설정해도 테스트는 할 수 있습니다. 이번 문단에서는 NAS 또는 HTTP에 있을때 받는 과정을 살펴보겠습니다.

현재 에셋 번들을 받을 수 있는 다양한 다운로드 방법이 있습니다. UnityWebRequest를 이용할 수도 있지만 LoadFromCacheOrDownload를 통해서도 쉽게 적용이 가능합니다. 후자의 방법을 이용해서 구현하면 다음과 같은 코드가 나오게 됩니다.

AssetBundle.PNG

Caching 준비가 되길 기다린뒤 준비가 된다면 WWW를 이용해 다운로드 하게 됩니다. url은 에셋번들을 업로드한 주소를 넣으면 됩니다. (파일에서 업로드 할 경우 file:// + 파일 경로를 입력해주면 됩니다) version을 따로 관리하지 않는다면 1을 넣어서 테스트하면 됩니다.

LoadFromCacheOrDownload는 여러분이 빌드할 기기의 스토리지에 에셋번들 파일을 저장하게 됩니다. version이 같은 파일이 이미 존재할 경우 다운로드 하지 않고 캐쉬에 있는 데이터를 사용하게 됩니다. version이 더 높을경우 해당 에셋 번들을 다운로드 합니다. (주의 : 구버전의 캐쉬 데이터를 자동으로 지워주지 않습니다.)

이제 번들을 다운로드 받았으니 인스턴스로 생성해보겠습니다.

인스턴스화bundle.LoadAsset함수를 실행한뒤 Instance로 만들 Prefab의 이름을 넣어주세요. 이때 Prefab의 이름은 Project뷰 또는 Hierarchy뷰에서 보이는 이름 그대로 작성하면 됩니다. Instantiate(bundle.LoadAsset(prefabName)) 과 같이 생성해도 되며 사진과 같이 다른 GameObject에 담아둔뒤 복제해서 사용 해도 됩니다. 주의할점은 밑의 bundle.Unload() 함수입니다.

bundle.Unload(false)를 실행하게 되면 에셋 번들 데이터는 메모리에서 해제됩니다. 하지만 현재 씬에 오브젝트가 사용되고 있다면 해당 오브젝트는 씬내에서 그대로 유지됩니다 (주의 : Unload 한뒤 bundle.LoadAsset을 다시 실행하게 되면 로드되지 않습니다. 그 이유는 이미 Unload했기 때문입니다. 만약 다시 생성을 원한다면 AssetBundle을 이전과 같이 로딩하거나 어느곳에서 참조를 가지고 있어야합니다.)

bundle.Unload(true)를 실행하게 되면 에셋 번들 데이터 뿐만이 아니라 현재 생성된 Instance 들도 모두 null로 전환됩니다. 일반적인 상황에서는 bundle.Unload(false)를 많이 사용합니다.

이러한 방법을 통해서 에셋 번들을 통해 인스턴스를 간단하게 생성해 봤습니다.

더 개선할 방향 및 의존성(Dependence) 관리

에셋 번들은 만드는 것보다는 관리되어지는게 더 중요합니다. AssetBundle Using Pattern 이라고 검색하면 다양한 문서들을 참고할 수 있습니다. 이 문단에서는 간단하게 소개하겠습니다.

에셋 번들을 어떠한 기준으로 쪼갤것인가 ?

에셋 번들 안에 들어있는 프리팹 한개가 변경된다면 여러분은 해당 파일을 업데이트 해줘야 할것입니다. 대체적으로 에셋번들은 두가지 방법으로 나뉩니다. 1. 적은 용량으로 여러개의 에셋 번들을 구성 2. 큰 용량으로 적은 개수의 에셋 번들을 구성

주의할점은 에셋번들을 관리하는 것 뿐만이 아니라 에셋 번들을 Unity에서 로드할때 파일 입출력으로 인한 오버헤드가 발생된다는 점입니다. 실질적으로 로드할 데이터는 적지만 파일이 여러개 나뉘어져 있다면 파일 입출력에 더 많은 시간을 사용 -> 로딩시간 증가로 이어질 것입니다. 반대로 큰 파일로 구성되어 있다면 업데이트마다 다운로드에 많은 시간이 소요될것입니다.

“나무”라는 프리팹을 A가 사용하고 B도 사용하는 상황에서 에셋번들로 각각 추출하면 어떻게 될까요 ? A에도 나무의 데이터가 담기고 B도 나무의 데이터가 담기게 됩니다. 이렇게 상호 의존하는 상황이 생겼을때는 어떻게 해야할까요 ? 에셋번들이 다른 에셋번들을 참조해야 하는 상황일 수도 있습니다. 하지만 유니티에서는 자체적으로 이러한 의존성(Dependence)에 맞춰 순서를 변경, 로드 해주지는 않습니다. 이는 전적으로 개발자가 Custom Loader를 만들어서 해결해야 합니다.

에셋 번들 브라우저.PNG현재 유니티 스토어에 있는 번들 브라우저를 이용하는 것도 좋은 방법일 수 있습니다. 트리구조로 상호 의존 관계를 명확하게 한뒤 중복되는 요소를 최대한 줄여 에셋번들 용량 증가를 방지할 수도 있습니다. 해당 에셋은 5.6이상에서 사용되며 다양한 툴들이 많이 나와있고 Unity에서도 해당 부분을 인지하고 좀더 편하게 개선되는 과정이니 기다리면 더 좋아질 수 있습니다.

지금까지 단순한 방법으로 에셋 번들을 생성, 인스턴스화 해봤습니다. 더 발전한다면 적은 에셋번들의 개수로 용량 증가 없이 효율적으로 관리가 가능해질 것입니다.

애자일 개발방법론

게임개발에 반드시 도입되어야 하는 개발방법론이라고 생각합니다.

게임은 정말 다양한 아이디어와 기술의 집합체라고 생각합니다. 하지만 그만큼 직접 눈으로 보고 플레이하기 전에는 확인해보기 어려운 내용이 많습니다.

 

프롬더레드에서는 애자일 프로세스를 점진적으로 도입하여 추후 모든 프로젝트의 기본 개발 프로세스로 정착해 나갈 예정입니다.

추가로 애자일 프로세스에 대해 잘 정리한 글이 있어 공유 드립니다.

(하지만 애자일이 천하무적은 아닙니다. 제대로 파악하지 않고 덤비면 open the hell gate. 다음 번에는 애자일의 단점과 불편한 진실에 대해서도 공유 드리겠습니다.)

 

애자일 개발방법론 (Agile Development Methodology)

이 글은 한글 번역본입니다.

(출처: http://agilemethodology.org/)

애자일이란?

애자일은 방법론이 아닙니다!

애자일은 기민한, 좋은 것을 빠르고 낭비없게 만든다는 뜻인데요,

애자일 방법론은 전통적 프로젝트 관리 방법인 폭포수 모델,

혹은 순차적인 개발방법을 대체하는 또 다른 방법입니다.

애자일 처리 방법은 반복적인 일과 경험에 의거한 피드백을 통해서

예측 불가능한 일에 대응할 수 있도록 도와줍니다.

(출처: www.livnara.com)

스크럼이란?

스크럼은 애자일 개발 과정의 하나로, 단순함과 융통성 때문에 가장 인기있는 방법론입니다.

이러한 인기 덕분에, 많은 조직들이 “스크럼”을 한다고 하는데요,

사실 “정확한 스크럼”방법론을 이용하는 것은 아닙니다.

스크럼의 정확한 정의는 경험에 의거한 피드백, 팀의 자가적인 관리,

그리고 짧은 반복을 통해서 적합한 제품 테스트에 중점을 두는 개발방법론입니다.

스크럼은 애자일 방법론을 이용하지 않는 조직에게는 맞지 않을 때가 많습니다.

(출처: en.wikipedia.org)

스크럼은 세 가지 역할이 있는데요, 제품 책임자, 팀, 그리고 스크럼 마스터 입니다.

이는 Michale James의 The Scrum Training Series에 설명되어 있습니다.

전통적인 프로젝트 관리자의 역할은 이 세가지로 나누어져 있습니다.

또한, 스크럼은 다섯개의 진행 방법이 있습니다:

제품 백로그(Backlog Grooming), 스프린트 계획(Sprint Planning), 일일 스크럼(Daily Scrum),

스프린트 검토 회의(Sprint Review Meeting), 그리고 스프린트 후행 회의(Sprint Retrospective Meeting)입니다.

스크럼 개발방법론을 시작하는 방법 중 하나는 Scrum Training Series인데요,

(Scrum Training Series: http://scrumtrainingseries.com/)

애자일 방법론을 진행할 수 있는 인기있는 방법들을 다루고 있습니다.

또한, 6페이지의 Scrum Reference Card를 다운 받을 수 있습니다.

(출처: svsg.co)

애자일의 역사

1970년 Winston Royce 박사가 논문(“Managing the Development of Large Software Systems”)에서

애자일에 대해 발표하며, 전통적인 순차적 개발 방법을 비판했습니다.

그는 소프트웨어는 자동차를 조립라인에서 생산하는 것과 다르게 개발되어야한다고 주장했습니다.

자동차는 일련의 차례를 기반으로 생산이 되어서, 각각의 단계가 마무리 되어야만 다음 단계로 넘어갈 수 있습니다.

Royce 박사는 이러한 단계적인 방법을 반대하면서,

개발자들이 먼저 프로젝트의 필요사항들을 수집하고,

모든 아키텍쳐와 디자인을 완료한 후에, 코딩을 작성하는 방법 반복적으로 해야한다고 주장했습니다.

Royce 박사가 특히 전통적 방식에 반대하는 이유는 순차적으로 일을 하게되면,

각각의 단계의 일을 수행하는 사람들 사이에서 소통이 없어지기 때문입니다.

 

(출처: vesti-kareliya.ru)

애자일 개발방법론과 비교해보았을 때, “폭포수 모델” 혹은 순차적 개발 방법이

최적화된 방법과는 거리가 멀다는 것을 알 수 있습니다.

첫 번째로, 전통적 방식은 디자인이나 코딩 전에 프로젝트에 필요한 모든 요인들을 다 파악할 수 있다고 가정합니다.

다시 말하자면, 과연 소프트웨어가 실행되기도 전에 필요한 모든 부분을 개발자 팀에게 알려줄 수 있을까요?

소프트웨어 기능을 실행해보고 나서 더 쉽게 알려줄 수 있지 않을까요?

많은 소프트웨어 개발자들은 지금까지 더 어려운 방식으로 일을 해왔습니다.

프로젝트 과정 끝에 그 개발자 팀은 요구된 소프트웨어를 다 만들었을지도 모르지만,

그 동안 비즈니스 사회는 크게 달라져서 완성 되고 난 시점에서 그 프로젝트는 가치가 떨어졌을 것입니다.

이 경우에서 회사는 많은 돈과 시간을 투자했지만 누구도 원하지 않는 소프트웨어를 만든 것입니다.

이를 해결할 수 있는 방법이 바로 애자일 개발방법론을 사용하는 것입니다.

(출처: designshack.net)

왜 애자일 개발방법론을 써야 할까요?

애자일 개발방법론은 개발 주기를 통해 프로젝트의 방향과 목표를 가늠하도록 도와줍니다.

이는 반복적인 주기(스프린트)를 거쳐서 이루어지는데요,

과정 후에 마지막에 실행 가능한 제품을 발표합니다.

단축된 일의 반복과 제품 기능에 중점을 두기 때문에

애자일 개발방법론은 “반복적”이고 “증가적”이라고 표현됩니다.

폭포수 모델에서 개발자들은 한 번의 기회만으로 프로젝트의 모든 측면을 검토해야합니다.

반면에 애자일 패러다임에서는 일정한 주기를 통해 계속적으로 모든 측면을 재검토 할 수 있습니다.

예를 들어서 2주마다 프로젝트의 목표를 재검토 했을 때 고쳐야 할 점이 있다면,

처음과는 또 다른 방향으로 전환할 기회가 있는 것이죠.

(출처: agilefellow.com)

이러한 “inspect-and-adapt” 개발방법은 개발 비용과 시간을 크게 줄여줍니다.

개발자들은 소프트웨어를 개발하는 동시에 필요한 부분을 수집하기 때문에.

초반에 정보 과다로 인해 분석을 하지 못하는 일은 생기지 않습니다.

애자일 개발방법론은 회사가 적합한 제품을 만드는 것을 도와줍니다.

아직 다 완성되지 않은 소프트웨어가 시장에 출시되는 것을 막고,

제품의 출시를 계속해서 재검토하고 다시 계획을 세우게 만들어

다시 개발을 통해서 그 가치를 최적화할  수 있도록 도와줍니다.

또한 시장 경쟁령을 갖추도록 만들어줍니다.

애자일 방법론을 이용하는 개발은 제품의 시장 적합성을 보존하며,

팀의 일이 헛수고가 되지 않도록 보장합니다.

출처: http://flearning-blog.tistory.com/230 [플러닝 Flearning]

 

 

Unity3D Terrain Performance Test

02
Unity Built-in terrain 사용 제작
01
유니티 내장 터레인 사용(Mesh Resolution 최하로 제작)  Profiler : Terrain Draw Calls 13, Tree Draw Calls 24 , Vert 19000

보여지는 것에 비해 비용이 비싸보인다…그래서 자체 제작

03
Profiler : 토탈 배치 23 버택스 40400, 하지만 Static Batches 4, 배칭된 버택스 32200의 CPU Instancing

terrain,mountain 은 3 Textures Blend Shader를 만들어서 적용 제작 하였다.

04
Terrain and Tree :  Draw Calls 3 Vert 8000

단순 비교

내장기능 터레인 제작 : Total Batches 37 , Verts 19000

외부기능 터레인 제작 : Total Batches 3, Verts 8000

Bluetooth 4.0(ble) 자전거용 Profile

Fitness Machine Service ( FTMS ) – org.bluetooth.service.fitness_machine
Assigned Number : 1826
UUID : 00001826-0000-1000-8000-00805f9b34fb

Indoor Bike Data – org.bluetooth.characteristic.indoor_bike_data
Assigned Number : 2AD2
UUID : 00002AD2-0000-1000-8000-00805f9b34fb
Type : org.bluetooth.characteristic.indoor_bike_data
Property : Notify

Field Format Byte Index Unit(Exponent)
Flags 16 bit 0,1
Instantaneous Speed uint 16 2,3   km/h ( Decimal, -2 )
Average Speed uint 16 4,5 km/h ( Decimal, -2 )
Instantaneous Cadence uint 16 6,7  rpm ( Binary, -1 )
Average Cadence uint 16 8,9  rpm ( Binary, -1 )
Total Distance uint 24 10,11,12 meter
Resistance Level sint 16 13,14
Instantaneous Power sint 16 15,16  watt
Average Power sint 16 17,18  watt
Total Energy uint 16 19,20 calorie
Energy Per Hour uint 16 21,22  calorie
Energy Per Minute uint 8 23  calorie
Heart Rate uint 8 24  bpm
Metabolic Equivalent uint 8 25  ( Decimal, -1 )
Elapsed Time uint 16 26,27  second
Remaining Time uint 16 28,29  second

Total byte : 30

 

Cycling Speed and Cadence – org.bluetooth.service.cycling_speed_and_cadence
Assigned Number : 1816
UUID : 00001816-0000-1000-8000-00805f9b34fb

CSC Measurement – org.bluetooth.characteristic.csc_measurement
Assigned Number : 2A5B
UUID : 00002A5B-0000-1000-8000-00805f9b34fb
Type : org.bluetooth.characteristic.csc_measurement
Property : Notify

Field Format Byte Index Unit(Exponent)
Flags 8 bit 0
Cumulative Wheel Revolutions uint 32 1,2,3,4
Last Wheel Event Time uint 16 5,6   second( Binary, -10 ) , 1/1024s
Cumulative Crank Revolutions uint 16 7,8
Last Crank Event Time uint 16 9,10 second( Binary, -10 ), 1/1024s

Total byte : 11