2018년 4월 11일 수요일

CentOS7에 cmake 3.11.0 설치

wget https://cmake.org/files/v3.11/cmake-3.11.0.tar.gz
tar -zxf cmake-3.11.0.tar.gz
cd cmake-3.11.0
./bootstrap
make
sudo make install

2018년 1월 5일 금요일

Clang 3.9 빌드

Clang 3.9 빌드 (CentOS 기준)

  • 준비할 항목
wget http://llvm.org/releases/3.9.0/llvm-3.9.0.src.tar.xz
wget http://llvm.org/releases/3.9.0/cfe-3.9.0.src.tar.xz
wget http://llvm.org/releases/3.9.0/libcxx-3.9.0.src.tar.xz
wget http://llvm.org/releases/3.9.0/libcxxabi-3.9.0.src.tar.xz
 
unxz llvm-3.9.0.src.tar.xz
unxz cfe-3.9.0.src.tar.xz
unxz libcxx-3.9.0.src.tar.xz
unxz libcxxabi-3.9.0.src.tar.xz
  
tar -xvf llvm-3.9.0.src.tar
tar -xvf cfe-3.9.0.src.tar
tar -xvf libcxx-3.9.0.src.tar
tar -xvf libcxxabi-3.9.0.src.tar
  
# 아래에서 이 이름을 기준으로 빌드 방법을 설명할것이므로 변경하는게 좋음
mv llvm-3.9.0.src llvm
mv cfe-3.9.0.src clang
mv libcxx-3.9.0.src libcxx
mv libcxxabi-3.9.0.src libcxxabi

  •  llvm 빌드
mv clang ./llvm/tools
mkdir llvm.build
cd llvm.build
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local ../llvm
make
sudo make install
  • libcxx, libcxxabi 빌드
# 1st round to build libcxx without libcxxabi
cd libcxx
mkdir tmp
cd tmp
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local/ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..
make
sudo make install
cd ..
rm tmp -rf
cd ..
  
# Build libcxxabi with libc++
cd libcxxabi
mkdir tmp
cd tmp
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLIBCXXABI_LIBCXX_INCLUDES=../../libcxx/include ..
make
sudo make install
cd ../..
 
 
# 2nd round to build libcxx with libcxxabi
cd libcxx
mkdir tmp
cd tmp
# This time, we want to compile libcxx with libcxxabi, so we have to specify LIBCXX_CXX_ABI=libcxxabi and the path to libcxxabi headers, LIBCXX_LIBCXXABI_INCLUDE_PATHS.
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLIBCXX_CXX_ABI=libcxxabi -DLIBCXX_CXX_ABI_INCLUDE_PATHS=../../libcxxabi/include ..
make
sudo make install

2015년 12월 13일 일요일

chrome에서 세이프 서치 강제 우회법

검색엔진을 기존의  google이 아닌
Encrypted Google으로 신규 등록한 후 encrypted.google.com, https://encrypted.google.com/#q=%s 로 등록하면 됨

2015년 4월 1일 수요일

워터폴, 스크럼, 칸반 비교


  • 전통적인 개발방식 과 스크럼의 차이
전통적인 개발 방식인 폭포수모델(Waterfall)의 문제: 기획은 계속 변경된다
Waterfall의 해결책. 스크럼. 즉, 2~4주 단위로 끊어서 파일럿 형태로 프로젝트를 반복해서 진행하자


  • 워터폴: 

기획안은 바뀌는데 그렇다면 설계부터 다시 해야하나??


  • 스크럼

2주 단위로 잘라서 진행을 해보자. 2주 단위의 프로토 프로그램을 발전시켜서 최종 결과물을 만들자



  • 관련 참고자료:

* http://www.slideshare.net/BrandonK/agile-scrum?related=1
* http://www.slideshare.net/einsub/ss-27765585?next_slideshow=1



  • 칸반

스크럼의 문제점은?

  1. 우리는 추정을 정확하게 하지 못한다. 그런데 아웃풋은 2주만에 나와야 한다!
  2. 오버헤드. 스프린트 플래닝은 개발자들이 관계 없는 기능의 토론을 끝까지 앉아서 보게 만든다
  3. 스크럼은 업무 시간에 제한을 둠으로써 생산성을 끌어낸다고 하지만, 중요하다면 크기에 상관없이 완성해야 한다. 이슈들이 예상한것보다 커진다면 스프린트에 과부하가 걸린다
  4. 비현실적인 예측과 끊임없이 발생하는 틀린 추정 

-> 생산성 그래프는 끝이 급격하게 뾰족해진다
-> 막바지에 '최선을 다했다'고 말하기 위해 미친듯이 달리게 됨
-> 그 다음주에 회복할 시간을 가져야 하므로 생산성을 망가트린다.


  • 스크럼과의 차이점

한번에 진행되는 일의 수를 제한
우선 순위가 낮은 이슈들을 아래배치
동시에 개발이 진행될수 있는 아이템의 수를 제한


  • 관련 참고자료:

* http://pitzcarraldo.github.io/articles/2014/05/08/goodbye-scrum-hello-kanban/
* http://postgame.tistory.com/455
* http://www.jundols.com/wordpress/?p=493 (영어)


  •  칸반 관련 무료 툴

* http://www.todo2.co.uk/
* http://kanboard.net/
* https://taiga.io/


  •  회고

우리가 사용한다면?
서스테이닝 용의 프로젝트는 아닐지도 모른다. 그러나 신규 프로젝트라면 일부 채용하는것도 좋아보인다
룰을 100% 따르는 게 중요한게 아니라 적절히 자기 형편에 맞게 사용하면 될 것 같다

2012년 4월 22일 일요일

windows 7 D드라이브에 설치하기


윈도우즈7 설치 후 설정 전 shift + F10을 눌러서 cmd 윈도우를 호출하여 아래의 명령들을 실행한다.


  • 유저 프로파일 복사
  • 프로그램 파일 폴더 복사

robocopy "C:\Users" "D:\Users" /E /COPYALL /XJ
robocopy "C:\Program Files" "D:\Program Files" /E /COPYALL /XJ
기존 폴더를 삭제한 후 링크를 생성한다

  • 프로그램 파일

rmdir "C:\Program Files" /S /Q
mklink /J "C:\Program Files" "D:\Program Files"


  • 유저 프로파일

rmdir "C:\users" /S /Q
mklink /J "C:\users" "D:\users"
참고 자료)
http://www.welog.net/gbbs/bbs/board.php?bo_table=windows&wr_id=48
http://blog.tinywolf.com/271
http://blog.naver.com/PostView.nhn?blogId=sneezer77&logNo=40116367562

2012년 3월 28일 수요일

심즈, 심시티를 만든 윌 라이트의 TED  강연











스포어를 플레이한지 3-4년이 지나긴 했지만.. 모노리스가 있었단 말인가? 나도 참 호기심이 부족했군. ㅠㅠ

2010년 12월 3일 금요일

1.0 데이터 주도적 설계의 마법

제1부
프로그래밍 기법들

1.0 데이터 주도적 설계의 마법
아이디어 #1 기본
필요할때마다 텍스트를 읽어서 처리할수 있는 시스템을 만드는게 좋다
(최종 출시 시점에서는 이진 파일을 이용하겠지만, 개발 단계는 텍스트 파일을 사용하여 편집/수정이 쉽게 한다)

아이디어 #2 최소한의 원칙
상수들을 하드 코딩 하지 말고 텍스트 파일에 넣어야 한다

아이디어 #3 하드 코딩을 아예 없애라
게임을 단일한 용도로 설계하지 말고 최대한 범용적인 기능성을 담당하도록 분리한다

아이디어 #4 게임의 흐름은 스크립트로 제어할 것
게임 안에서의 어떠한 장면을 연출할 때는 스크립트를 사용하는 것이 좋다
단순한 원인-결과 로직 역시 스크립트의 대상이 된다
스크립트를 채용하면 시스템의 설계를 상당히 단순화시킬 수 있다

아이디어 #5 스크립트 남용의 해악
스크립트를 사용할때의 원칙: 로직과 데이터의 분리
복잡한 로직은 코드에, 데이터는 코드 외부에.

스크립트는 데이터의 성격과 로직의 성격을 함께 가지고 있다는 위험성이 있다.

경계가 애매하다는 것이 문제
로직이 복잡하면 코드에 넣어라
스크립팅 언어는 게임 개발에 필요한 시간과 자원을 너무 소비하지 않도록 해야 한다

아이디어 #6 데이터의 중복을 피해라
여러곳에서 쓰일 데이터를 전역적인 데이터로 만들어라

아이디어 #7 데이터를 만들어 내는 도구를 작성할 것
제대로 된 도구를 만들어 두면 게임 개발 속도가 훨씬 빨라진다.