레이블이 프로그래밍인 게시물을 표시합니다. 모든 게시물 표시
레이블이 프로그래밍인 게시물을 표시합니다. 모든 게시물 표시
2018년 8월 28일 화요일

이오스 다이스(주사위) 토큰 BET의 전망

목차


이오스 주사위 흥하다

eosbetdice11 라는 계정에서 시작한 간단한 앱인 이오스 다이스는
이더롤이라는 게임을 모델로 시작한 아류작이었습니다만..
이오스 다이스
https://eosflare.io/account/eosbetdice11
오픈한지 고작 일주일 남짓
당시 초기자본이

계정 보관량 1000개
memory+cpu = 1500개
합이 2500개

정도였는데 지금은 무려
총합 22만개를 넘어가는 수익을 벌어들이고 있습니다.

어떤 게임이길래

이오스 주사위
허탈할 정도로 단순합니다.

로그인을 하고 이오스를 걸고 아래 주사위 숫자바를 정하고
돌리기만 하면 끝입니다.
정한 숫자보다 주사위의 숫자가 낮으면 이겨서 배당금을 가져가는거고
같거나 높으면 패해서 건 금액을 잃게 됩니다.
현재 최소배팅금액은 0.25 이더로 이오스 6천원시세로 1500원 정도입니다
승률이 높을수록 얻는게 적고 반대로 승률이 낮은 숫자일수록 배당금이
높아지죠.

이오스 카지노
최소위험일때 승률은 95%이며 배당금은 1.03배이고

이오스 다이스
최대위험의 승률은 고작 3%.. 대신 배당금은 32배입니다.

왜 인기가 있는가

그동안 암호화폐는 제대로된 서비스를 보여주지 못했습니다.
전부 가짜에 말뿐. 심지어 카지노 관련 코인들도 다 그랬습니다.
하지만 이제는 시장이 침체되고 사람들도 그런 말빨에 속아넘어가지
않게 되었습니다.
그럼에도 쉽게 제대로된 서비스가 나오지 못했는데
블록체인들의 성능적 한계와 수수료 문제 때문이었습니다
너무나 느린데다가 주사위를 한번 돌릴때마다 승패와 상관없는 수수료를
내야하니 이용자가 적을수밖에 없었죠.

하지만 이오스가 나오고 상황이 달라졌습니다.
일반 서비스와 겨뤄볼만한 퍼포먼스가 나오고 수수료가 무료라는 특성이
빛을 발한 것이죠. 일단 그 문제가 해결되자 블록체인과 암호화폐가 가진
장점도 극대화되기 시작했습니다.
실시간 배팅과 보상이 이뤄지고 당장 조작이 힘든 스마트 컨트랙트의 신뢰성이
합쳐졌으며 암호화폐의 법적 정의가 모호한 점을 들어
각종 제제에서도 자유로운 것입니다

그러자 그동안 가장 억압되어 있었던 도박류들이 크게 떠버린 것이죠.

BET 토큰

이들은 영리하게도 여기서 한발 더 나아가 토큰을 발행하여
이익을 극대화하고 있습니다.
eos dice
다이스를 한번 돌릴때마다 배팅한 만큼의 토큰을 승패에 관계없이
나눠주는 것이죠.
이 토큰은 지분의 역할을 하는데 이후 이 사이트가 얻은 모든 이익을
- 현재 걸린 22만 이오스를 - 토큰 보유자들에게 나눠줍니다.
당연히 다들 가지고 싶어하죠.
그런데 승패에 상관없이 주사위를 굴리기만 해도 준다니
1 이오스를 걸고 95% 승률로 마구 돌리기만 해도 상당량 얻을 수 있게 됩니다
그래서 초반에 사람들이 열심히 굴리는데 한몫했죠
현재는 1 이오스당 0.2 토큰으로 상당히 낮아졌으나 그래도 일단은
나오기에 베팅도 하고 토큰은 보너스로 받는 그런 심리를 일으켜줍니다.

eos bet token
이 토큰은 9월 후반에 공개판매를 앞두고 있고 11월 보유자들에게
첫분배가 이뤄질 예정입니다.
현재 실제로 돌아가는 서비스와 어마어마한 실적,
그리고 그것에 대해 실질적 혜택을 주는 토큰

지금까지의 어떤 코인들과도 차원이 다릅니다
만약 진짜로 11월 보유자들에게 상당한 이득이 돌아가게 된다면?
그땐 해당 토큰의 가격은 천정부지로 솟을겁니다.
침체된 코인계에서 비트코인의 영향력과 상관없이
세력들의 펌프질도 아닌 실제로 가치때문에 오르는 코인을 보게 될겁니다.
거래소들의 상장도 따논 당상이고요

리스크와 기대

당연하게도 리스크도 많습니다.
먼저 이 서비스가 도박이라는 것. 이게 최대의 리스크죠.
다만 지금은 초기단계라 제재가 들어오기전까지 상당히 오랫동안
이득을 볼 것이 기대됩니다.

두번째는 서비스에서 조작 논란이 불거질 가능성이 없진 않습니다.
아무리 블록체인이 신뢰성이 높다하더라도 블록체인과 짜서 올리는
프로그램의 신뢰성은 별개죠. 현재 소스코드도 공개되어 있지 않으므로
신뢰성에 대해서 좀 의문이 있는건 사실입니다.

마지막으로 거래소들의 토큰 상장 거부입니다.
하지만 현재 핫한 것이 분산거래소,
즉 탈중앙화 거래소들의 등장이 초읽기라는 것입니다.
분산거래소들은 일반 거래소들에 비해 법적인 문제에서 상당히 자유롭습니다.
그러므로 BET 토큰이 상장되지 않을 가능성은 거의 0에 수렴합니다.
현재는 토큰에 락이 걸려있어서 이동을 못해서 상장이 되어 있지 않지만
ico 이후 락이 풀리고 곧장 상장이 예상됩니다.

마치며

사실 도박으로 스타트를 끊었다는 것은 그리 자랑할만한 것은 아닙니다.
하지만 서비스와 이득, 그리고 분배를 내세운 토큰이 실제로 돌아간다는
것은 앞으로의 블록체인 산업 전반에 있어서 거대한 기폭제가 될 가능성이 있습니다
그점에서 무조건 잘되었으면 하는 바람입니다.

마지막으로 저의 리퍼럴 링크를 걸면서 마칩니다.

이오스 다이스 리퍼럴 링크

해당 링크를 타고 거래할 경우 서로간에 0.5%의 추가 이득이 있습니다 +_+
토큰 정보가 도움이 되었다면 한푼만 도와주세요-ㅅ= 굽신굽신

(추가) 10월 20일 현재 상황

불행히도 BET 토큰의 현재상황은 별로 좋지 않습니다.

본문에서 간과한 가장 큰 리스크 때문입니다.
이들이 로드맵을 지키지 않고 무단으로 ICO를 취소, 락도 풀지 않았으며
당연히 거래소 상장도 안됐습니다.
거기에 후발주자들이 빠르게 따라옴에 따라
상황들이 역전됐습니다.

역시 리스크의 최고봉은 개발자의 신뢰도였네요.

Written with StackEdit.

2017년 11월 26일 일요일

비트코인(블록체인) 초보 입문 - 비트코인의 개념

목차


돈이란 무엇인가

돈이 가치를 지니는 것은
뒤에 누군가가 중재해주기 때문이다.
카지노의 칩을 생각해보라
비트코인 초보 입문
이런 장난감이 가치를 지닐 수 있는건 해당 카지노가
보증을 서주기 때문이다.

마찬가지로 현실의 돈은 각각의 국가가 보증을
서줌으로써 가치를 지닌다.
만약 전쟁이라도 일어나면 해당 국가의 지폐가치가
확 떨어지는 것은 보증에 의심이 발생해서이다

결국 돈은 신뢰이다

가상화폐

게임 아이템 판매에 대해서 들어봤을 것이다
위에서 카지노도 언급했지만
해당 게임에 대해서 신뢰가 있고(문닫지 않을거라는..)
게임머니를 사고 싶은 자, 팔고 싶은 자..
즉 시장을 형성할 요건이 되면
저런 가상게임머니도 가치를 지니고 시세를 형성하게 된다
가상화폐 초보 입문

하지만 이러한 가상화폐들은 국가급 화폐들에 비하면
안정성이 비교도 안되게 떨어진다.
작게는 게임이 해킹을 당하는 것에서
크게는 아예 서비스중단을 할 수도 있다
그러면 해당 게임머니는 죄다 휴지조각이 되는 것이다

그래서 ‘가상화폐는 제대로된 화폐가 될 수 없다..’
라는 것이 지금까지의 인식이었다

비트코인의 등장

하지만 암호기술이 발전을 거듭하던 와중
엄청난 물건이 나와버렸다.
위의 게임서버 같은 것과 달리 해킹이 불가능하며
문을 닫을 염려도 없는
지금까지완 차원이 다른 가상화폐가 등장한 것이다

바로 비트코인의 등장이다

비트코인은 암호화기술의 결정체이고 실제 돌아가는 것도
전부 암호를 기반으로 함으로
앞서의 가상화폐와 달리 암호화폐라고 칭하게 되었다

그리고 해당 화폐를 기록하고 담당하는 프로그램을
지갑 프로그램이라고 하며
거래기록과 잔고등이 담긴 것을 블록체인이라고 한다.

게임으로 예를들자면
게임머니를 사용하기 위해서 당연히 게임프로그램을 깔고
게임서버에 접속해야된다.
이것을 지갑 프로그램이 담당한다.
그리고 게임서버측에서는 어딘가에 id에 따라 거래기록과
잔고를 기록해놓은 데이터가 있다.
그것을 참고해서 유저들에게 정보를 보여주는 것이다
이 기록물의 역할을 블록체인이 하며
앞으로 설명할 것이지만 이것은 해킹이 불가능한
강력한 보안을 자랑한다.

다음편은 왜 비트코인이 해킹불가능한지 알아보겠다

Written with StackEdit.

2017년 10월 30일 월요일

2FA와 OTP의 원리

목차


2FA (Two-Factor Authentication)

2FA는 이중인증이라고 불린다.

곧 소개할 OTP 처럼 코인계에선 무조건 필수이다.
정작 스팀 사이트에선 지원하지 않는게 엄청난 에러긴한데
그 대체로써 마스터 패스워드를 컴퓨터와 완전
분리해두는 방법이 있긴하니 숙지해두자.

여튼
보안인증에선 영역이 겹치지 않는 것들이 있는데
- 일반 패스워드
- 생체정보
- 그외의 도구(예를들면 차키)

같은 것이다.
이러한 영역중 두가지를 사용하면 2FA, 세가지를
모두 사용하면 3FA가 되는 것이다.

실생활 예를들면
집에 들어올때 전자식 도어라면 주로 패스워드식일텐데
패스워드가 털리면 도둑이 자유자재로 방문할 수 있다
그와 다르게 일반 자물쇠라면 이번엔 키가 털릴 경우
보안이 위험해진다.
그래서 양쪽을 다 달아놓는 것을 이중인증 시스템
2FA 라고 할 수 있다.

참고로 패스워드로도 열리고 키로도 열린다면
이것은 그냥 두가지 방식으로 다 열릴뿐..
인증을 두번 강제하지 않으니까
2FA라고 할 수 없다
(도리어 보안은 더욱더 약해진다)

OTP

이중인증이라고 그리 안전한 것은 아니다.

2fa 개념
미션 임파서블이란 절세의 도둑놈을 다룬 영화를 보면

2fa 개념
망막패턴을 복사해서 콘텍트렌즈에 입힌후

OTP 개념
유유히 도둑질 하는 장면을 볼 수 있다

이렇듯 일반 패스워드뿐만 아니라
지문, 망막패턴도 얼마든지 털릴 수가 있다

그래서 미래지향적인 랩퍼들의 경우는
지문이 털릴 것을 방지하기 위해
현란한 손짓이나 역방향 손모양으로 보안에 신경을
쓰는 것을 볼 수 있다.

OTP 개념
위의 잘못된 예에서도 전모씨 옆의 래퍼는 기본적
보안을 철저히 지키는 모습이다.

즉, 다중 인증이라도 노출될 위험이 있으면 위험하다.

하지만 불행히도 노출의 위험은 항상있다
특히 입력의 순간만은 도저히 어떻게 할 수가 없다

그래서 노출돼도 되는 패스워드가 나오게 되었는데..

그것이 바로 1회용 패스워드

One Time Password

OTP 이다.

OTP 원리


OTP는 보통 1분마다 수학공식에 따라
숫자를 뱉어낸다.

예를들면

(A + 시간) X 2000 + A / 30 = OTP패스워드

뭐 이런식이다. 그 식은 저렇게 흐리멍텅하지 않고
절대 알수 없는 무시무시한 식으로써
역이 성립하지 않는다. 즉 해답을 보고 식을
유추하는 것이 불가능하다.

대신
처음에 OTP를 등록할때 주어지는 고유번호인
A를 알고 있으면 똑같은 답이 생성되게는 할 수 있다

그것을 이용해서
상대방 서버에 설치된 OTP와 똑같은 고유번호를
받아와서 자신의 폰에 깔린 OTP에 넣으면
저쪽과 똑같은 패스워드를 1분마다 생성하게 된다.

쉽게 예를들면
초침이 좀 빠르거나 느린 특제시계를
두개만 만들어서 초침까지 맞춘후 둘이서 나눠 갖는다.
그리고 접속할때 지금 몇초인지 불러서 서로가 일치하면
통과시켜주는..

OTP 개념
찌찌뽕 시스템이 바로 OTP인 것이다.

이 찌찌뽕 시스템은 저 특제시계를 탈취하지 않는한
현재 것이 노출된다고 다음 시간을 맞출 순 없다.

즉 서로 맞춰볼때 노출되더라도 그것은 그 순간뿐이니까
안전하게 되는 것이다.

Written with StackEdit.

2017년 10월 10일 화요일

코딩교육에 대한 기대감

목차


코딩교육

내년부터 코딩 교육이 의무교육이 됩니다.
코딩은 다른 공부에 비해 결과를 직접 바로바로
볼 수 있으므로 굉장히 재밌고
그러한 재미를 통해서 논리적 사고를 쌓는데
최고의 도구라고 할 수 있죠

한국패치

��내 아이 ‘코포자’ 안돼 - 네이버기사

그렇지만 이좋은 교육도 한국패치를 당하고 나면

코딩교육
이렇게 되어버립니다.
그리고 역시나 열라게 욕 얻어먹고 있는 중입니다.

하지만
전 이런 개떡 같은 한국패치가 있음에도
코딩교육의 파괴력을 가볍게 보고 있지 않습니다.

영어 같은 대실패의 역사가 되지 않을거란
확신이 있습니다.

왜냐면 코딩은..
재밌기 때문입니다.

물론 제의견에 대해서

반론도 만만치 않을건데..

그건 여러분이 시대를 잘못타서 열라 재미없는 방법으로
배웠으며 그런만큼 사용도 제대로 못했기 때문입니다.

영어도 그랬죠
영어는 정말 배운만큼 사용하기 힘든 과목입니다.
영어친구도 없고, 선생과 영어로 대화할 수도 없으며
영화에서 자신이 배운 수준만큼 듣기가 되지도 않습니다
무엇보다 익히는게 넘 재미없죠.

하지만 코딩은 다릅니다.
코딩은 딱 자신이 배운 수준만큼
즉시 눈으로 효과를 볼 수 있습니다.
상대 없이 학교,학원에서 실습이 가능하며
무엇보다 집에서도 가능하죠.

그리고 재미와 필요성을 찾기가 쉽습니다.

위에서 마인크레프트를 이용한 코딩

2박 3일 54만원짜리..

그거 걍 아래 사이트 가서
54만원을 직접 경험해보시길 바랍니다.
완전 날강도놈들인데..
심지어 자기들이 만든 교육자료도 아니거든요

https://studio.code.org/s/minecraft/stage/1/puzzle/1
여기로 가면 회원가입이고 뭐고 없이
바로 마인크래프트 게임화면을 이용해서
코딩을 배울 수 있습니다.

해보시면 이 툴이 얼마나 쉽고 재밌게
만들어져 있는지 아실겁니다.
게다가 한글지원도 완벽하며
편리하고 상세한 튜터리얼도 제공합니다.

한번 해봅시다.
코딩교육
위의 한글 도움말을 그대로 따라하시면 됩니다

코딩교육
왼쪽 짙은 회색 화면에서 코드조각을 가져와서 퍼즐에 연결합니다

코딩교육
그리고 실행을 누르면 자신이 연결한 코드조각 그대로 화면에서 결과를 보여줍니다

닭이 앞으로 가다가 왼쪽으로 슉 회전하죠.

어떻습니까?
용어도 외울필요 없고, 문법을 맞출 필요도 없으며
스펠링 틀릴 걱정도 없습니다.

그럼에도 불구하고 자신의 손으로 치킨을
움직인 겁니다.

이걸 보면 눈을 빛낼 애들이 꽤 있을겁니다.
그래도 애들은 애들이니까
키보드 물어뜯는걸 더 좋아할지도 모르죠

하지만 누군가는 저 치킨으로 포크댄스를 추게 만들거고
누군가는 후라이드 치킨으로 만드는 장면도
보여줄 겁니다.

그럼 키보드를 물어뜯던 애들도
한번은 더 관심을 가질 수 있습니다.

거기에 앞으로도 툴은 더 발전해 나갈겁니다.
특히 울나라는 교육용이라면 사족을 못쓰니까
뽀로로 코딩이 나올수도 있겠죠.
뽀로로로 봉댄스를 추게 만들면
코딩교육
뽀로로 좋아하는 애들은 미끼를 물고 코딩을 하게 될겁니다.
코딩교육
이미 해당 사이트에서 겨울왕국 케릭을 활용하는 교육도 있습니다

물론.. 저 화면에서
코딩교육
이걸로 연결하는 과정에서
코포자들이 속출하긴 할겁니다.

하지만 코딩은 자전거 같은거라서
한번 익힌 원리는 무슨언어를 쓰던 어디로 안갑니다.

언젠간..
자신이 하는 게임의 오토가 필요해지는 날
배운걸 120% 활용하게 될지도 모르죠

내년부터 시행되는 코딩 의무교육이
10년후면 영어랑 달리 상당한 결실을 맺을거라
전 그렇게 기대하고 있습니다.

Written with StackEdit.

2016년 10월 13일 목요일

컴퓨터와 프로그래밍의 개념원리

목차


컴퓨터와 프로그래밍은 긴밀하게 묶여있지만 그것이 어떻게 묶여있는지는
잘모르는 사람이 많다. 원래부터 흥미가 있었던 사람이나 전공에서 일정부분 진행하지 않는 이상 그 실체가 드러나지않기 때문이기도 하지만 근본적으론 한국교육 방식이 글러먹었기 때문이다
왜 그런가로 흥미 유발을 하고 그것을 해결해나가게 한후 그 이후에 더 쉽게 해결할 수 있는 도구의 존재를 가르쳐줘야지 도구먼저 주고 사용법만 주구장창 가르키니 뭘 해결해야되는지도 모르고 도구 메뉴얼만 달달 외우는 것이다.
그래서 초보자도 그럭저럭 이해가 갈 수 있도록 컴퓨터가 프로그래밍에 어떤 개념과 원리로 묶여있는지 한번 살펴보겠다

반도체


프로그래밍 언어의 가장 깊숙한 곳의 선조는 기계어이다
기계어는 0101010100001010100 정말 이런식으로 이진수 구성이다
그렇다고 암호 같은건 아니다 다만

001 은 go, 010은 back, 011은 stop, 100은...

이런식의 의미를 담고 있는 것이다. 왜 두가지 숫자로만 표현했냐면
컴퓨터의 기본 구성부품인 반도체가 표현 가능한게
전기가 통함, 전기가 안통함 요 두가지 이기 때문이다
저걸 저런식으로 길게 써주기보다 숫자로 표현하자..

전기가 통하면 1 안통하면 0

이렇게 해서 컴퓨터의 기계어는 이진수가 되었다
이러한 이진수는 얼핏보면 별 쓸모없는 것 같다. 그러나
한자리로는 0 1 두 수밖에 표현못하지만
두자리가 되면 01 10 11 10 이렇게 네가지나 표현 가능하고
세자리면 2의 3승인 8가지 표현이 가능하다
그래서 전기가 통하고 안통하고를 제어할 수 있는 소자가 한개면 꼴랑 두개 표현이지만
수백개쯤 되면 표현력이 폭발한다. 그리고 표현력이 늘어나면 속도도 빨라진다.
손가락 10개인 사람이 10을 표현하는데는 손가락 10개를 쫙펴면 되지만
1개인 사람은 10번 접었다폈다해야 되고 그동안 시간 손실이 발생하는 것처럼 말이다

최초의 컴퓨터라고 알려져있는 에니악(패소해서 딴 컴한테 최초를 줬지만..)에서 당시
그런 1과 0을 표현할 수 있는 소자가 진공관 이었다
진공관
18000개의 달하는 진공관이 장착되어 엄청난 표현력과 속도를 가지게 되었고
이것을 이용해 계산식, 숫자등을 대입해 강력한 연산을 할 수 있게되었다

하지만 저 댑따만한 것을 18000개나 달려니 당연히
에니악
컴퓨터의 크기도 커지게 되었고 진공관의 소음 발열 전력등이 감당이 안되었다

그러던 도중 나온것이 바로 반도체이다. 진공관 같은 기능을 하는 것을 아주 작은 소체
에서 재현해낸 것이다. 이어서 그것들을 연결해서 돌고 돌게 만드는 길을
회로(回路, Circuit)라고 이름 지었으며 전자가 다니는 길이라해서 전자회로가 되었다
그리고 그러한 회로와 반도체, 그리고 여러부품들을 결합해서
전기만 요기 조기 잘 넣으면 기능하게 되었으며 이것들이 보니까
집적회로
해당하는 기능을 가진 소자랑 길을 작게 만들어도 연산자체는 똑같이 나왔다

그래서 더 작게 만들자해서 나온것이 바로 회로모음집인
집적회로
집적회로(集積回路, Integrated Circuit)
이며 이걸 기술의 발전에 따라 먼지 한올 올라가면 망하는 정도로 작게작게 만들어
조그마한 조각(Chip)에 올려놓은 것이 바로

마이크로 칩
마이크로 칩 (microchip) 이시다

아날로그와 디지털

왜 그럼 0과 1만 표현하는 놈으로 만들었을까.
0부터 10까지 있는 놈으로 많이 배치하면 2진수짜리랑 비교가 안될 것이 아닌가..

하지만 하나의 소재가 여러표현을 하는 것도 찾기 힘들며 그것이 무슨 표현을 하고 있는지를
파악하고 표준화 하는 것은 더더욱 힘들다. 사람들 끼리도 ‘니가 말한게 그런뜻인줄 몰랐다’
라며 엇나가기 일쑤인데 하물며 소재가 10가지 표현을 가지며 그 크기가 나노 단위라면 표현을 잘못 해석하는
일이 빈번할 것이며 그 결과는 블루스크린의 향연일 것이다
즉, 두가지의 표현을 확실하게 하는 놈을 왕창 때려박는 것이
여러표현을 하되 불확실한 놈을 몇개 박는 것보다 훨씬 나은 것이다

그러한 예로써 아날로그와 디지털의 장단점을 볼 수가 있다

아날로그는 현실의 현상을 아주 스무스하게 표현한다
손을 내렸다 올렸다 이게 아니라 손이 어디까지 올라갔다 어디까지 내려갔다를
디즈니 애니처럼 부드럽게 표현하기 위해 선연결처럼 끊김없이 표현한다

아날로그와 디지털

예를들면

전기가 0.01볼트 일때 0.01
전기가 0.02볼트 일때 0.02
...
전기가 1.15볼트 일때 1.15
전기가 1.16볼트 일때 1.16

이런식으로 디테일하게 표현할 수 있다
하지만 비가 온다던지해서 전송도중의 전압이 눈꼽만큼 상승하거나 하강해도
그 잘못된 데이터가 바로바로 반영된다 그리고 그 결과로 노이즈가 자주 발생한다

아날로그TV에서의 노이즈

하지만 디지털의 경우 두가지 수로 표현하는 대신
미세하게 깎이거나 더해지는 잘못된 오류를 쿨하게 무시할 수 있어
완벽하게 맛탱이 간 데이터가 아닌담에야 거의 100%에 달하는 정확도를 자랑한다

전기가 0.01볼트 일때 0
전기가 0.02볼트 일때 0
...
전기가 1.15볼트 일때 1
전기가 1.16볼트 일때 1

또한 처음부터 데이터를 보낼때
0.15를 그대로 보내서 0.15을 온전히 받는 것과
0 1 0 1 0 이렇게 순서대로 따로따로 0과 1을 끊어보내서 그것을 01010으로 합치는 것과
는 난이도 자체가 다르다

예를들면
아날로그와 디지털의 차이
적당히 숙성된 빵(1.4)을 보내달라해서 보냈는데 먼거리 후 도착했을때 고객이 보기에
그게 너무 숙성된 빵(1.6)이 되었을 수가 있다. 즉 요구했던거랑 다른 데이터가 왔으므로 실패인것이다
반면 밀가루(0)를 보내거나 빵(1)을 보내거나 둘중 하나로 하기로 하고 먼거리 후 도착했을때
빵이 좀 변하거나(1.6) 하는 건 문제가 아니다 밀가루(0)만 아니면 약속이 지켜지는 것이다

대신 디지털은 확실히 데이터간의 명확한 단절이 있는 만큼 연결되고 세밀한 표현에선
아날로그가 앞선다. 예를들면 음질 같은 것에 대해 많은 이들이 아날로그를 선호하는 것은 그러한 이유다


매니아들은 디지털 싫어하는 사람이 많다

프로그래밍 개념

컴퓨터는 저런식의 두가지 단순표현 소자를 그럭저럭 모아서 더 많은 걸 할 수 있는
애들로 만든 회로를 다시 더 모으고 모아서 집적시키고 거기서 더 모으고 모아서
완전 필살 압축한 칩들을 다시 몇개 더 모아서 CPU, 메인보드, 그래픽 카드를 만든 것을
다시 조립한 것이다

프로그래밍 언어도 01 = go 이런걸 모으고 모으고 모으고 또 모으다보니
0101010010101010010101 이렇게 되어버렸던 것이다.
근데 이짓하기 귀찮으니까 이것을 다시 0101000101010101 = go home 으로 압축했고
이런식으로 압축한 여러문장들을 섞어서 새로운 명령을 만들었는데 그마저도 귀찮다고
go home and see tv and wash and sleep = rest 같이 더 압축되어 고급언어가 된것이다.
이제 이 rest를 번역기(컴파일러 compilor)를 통해서 압축풀면 차례대로 복원하여 결국 무수한 0101 같은 걸로 이뤄진 exe 파일 같은 걸로 만들어진다. 이걸 컴파일 과정이라고 한다

그리고 exe를 실행시 거기에 적힌 기계어의 0과 1을 따라서 전자들이 반도체의 신호등 아래 여기저기 엔지니어들이 설계한 길을 돌아댕기는 것이 컴퓨터와 프로그래밍 언어의 실체라고 할 수 있다

요 길을 논리적으로 잘 만드는 것을 논리회로라 하며
그러한 길을 다니는 녀석들.. 즉 전기알갱이인 전자들을 잘 드라이빙하게 특성과 미끼들을 공부하는 것이 전자공학이며 걔네들이 돌아댕기면서 내뿜는 자기장도 곁들이면 전자기학이 된다. 그리고 얘네들이 어디서 얼만큼 가고 어디서 넘어지고 하는걸 수치로 계산하는 것이
공학수학이다

공책이 종이로 만들어졌다는 걸 알고 책을 사용하는 사람과 공책을 이루는 것이 종이란 것을 모르고 사용하는 사람은 차원이 다른 사용을 보여준다. 전자는 찢어지지 않게 힘조절도 하고 혹은 한페이지는 찢어서 알림메모용으로 쓸수도 있을 것이다 하지만 후자는 쓰다가 공책이 찢어지면 그 원인이 뭔지 몰라서 헤멜것이고 페이지를 찢어 알림메모용으로 쓴다거나 하는 응용은 상상도 못할 것이다.
프로그래밍 역시 마찬가지인데 더 깊게 알면 좋겠지만 이런식으로 어느정도의 개념만 잡아도 이해의 향상은 실력의 향상과 직결될 수 있을 것이고 무엇보다 훨씬 재미가 있을 거라 믿는다

Written with StackEdit.

2016년 6월 16일 목요일

Git 시작하기 4 - reset

목차

git reset 명령어

저번에는 git commit으로 백업을 진행시켰다
(무려 1년도 넘은 저번편이지만..)
백업을 하는 이유 중 하나는
바로 되돌리기를 위해서이다

그 되돌리기를 하는 명령어가 바로 reset 이다
명령어부터 대놓고 쉽다

이걸로 끝이면 좋겠지만 불행해도 쪼끔 더 복잡하다
reset은 3가지 영역으로 나뉜다
앞서 시작하기 3에서 3가지 영역이란걸 잠시 봤던적이 있을것이다

일반인-> 오디션 -> 연예인
작업디렉토리 -> stage area(index) -> Head (committed)

이런거

reset은 애가 섬세해서 단번에 연예인->일반인으로 끝나는게 아니라
연예인->안연예인.. 오디션합격->불합격.. 일반인->백수
이딴식으로 작동한다.
우리는 빠른 고수가 되기위해서 마공을 수련했기에 지금와서
저런걸보면 주화입마에 걸릴뿐이다
어차피 우리한테 필요한것은 백업했던것을 되돌리는 것

저런거 다 집어치우고
reset --hard
만 알면 된다.
좀더 자세히 쓰자면
git reset --hard HEAD~1
이것이 바로 이전의 백업본으로 돌아가는 명령어다
참고로 대소문자는 관계없다

만약 저명령어의 마지막 부분을 head~2 로 변경하면 어떻게 될까?
이전 이전의 백업본으로 바꾼다.
즉 저 숫자가 몇번 뒤로 가는가를 나타낸다
하지만 왠만한 범재들은 자신이 얼마나 뒤로 돌아가야할지
기억하고 있지 않다.

여기서 그동안 commit 하면서 써온 메세지들이 빛을 발한다
git 시작하기
세월이 흘러 이제 git bash에서 한글 지원 잘되는듯

git log를 치면 지금까지 커밋한 것들이 주루루 나오는데
메세지에 써넣은 것도 나온다
보통 메세지에는 ‘뭐뭐를 변경했음’ 이런식으로 써놓아서
어느 버전에 어떤 변경점이 있는지를 알게 해놓는게 정석이다

그것을 보고 뒤로 돌아가면되는데
위에 보면
commit 3abced8a8~~~생략~
이런식으로 노란색으로 요상한 영어랑 숫자가 쓰인 것을 볼 수 있을 것이다
이것들은 각 백업본의 식별자로써 4-5자만 치면 정확하게 그 버전으로
복귀할 수 있다
예를들면 second 버전으로 돌아가고 싶다.. 이럴때
git reset --hard 8a26f
요렇게만 치면 바로 된다

정리하면 한두번 이전으로 가고 싶을땐
head~숫자 (참고로 바로이전에만 가고 싶은땐 head^ 라고해도 된다)
정확하게 가고 싶을땐 로그 참고해서 id 4-5자만 쳐주면 된다

다시 원상태로 reflog

만약 reset으로 돌아갔는데
아무래도 괜히 온것 같다는 후회와 절망이 앞을 가린다면?
그래도 걱정할 것이 없다
commit 만 해줬으면 git에서
데이터는 왠만하면 잃어버리기 힘들다
특히나 우리처럼 마공으로 배워서 제한적으로 써왔다면
오히려 지워버리는 것이 엄청난 능력이다

앞서 log는 단순히 commit 의 역사만 보여주지만
head를 가지고 장난친 것 자체를 다 보여주는 명령어가 있다

reflog다

git 시작하기

이것도 앞서 log 처럼 각각의 행동에 ID가 붙어있는데
역시나 한 다섯자쯤 쳐주면 된다

위에서 HEAD@{8}을 보면 reset --hard head~3을 이용해서
뒤에서 3번째 백업본으로 돌아간 것을 볼 수 있다
그럼 바로 전 상태로 돌아가고 싶으면?
바로 밑에 아이디를 쳐주면 된다

git reset --hard 3abce

이로써 백업과 다시 되돌리기에 대해서까지 했고
이걸로도 왠만한 작업들에 마구 응용할 수 있을 것이다

다음에는 branch(가지치기) 혹은
온라인상에 업로드 시켜서 집에서 한 작업을
다른곳에서도 손쉽게 다운로드하고 git 작업을
이어나갈 수 있게 하는 방법을 알아보겠다

Written with StackEdit.

2015년 2월 26일 목요일

유니티 - 카메라 컴포넌트 설명

목차


Clear Flags

화면의 어디를 클리어 시킬 것인지를 정한다
라고 유니티 공식에 설명되어 있는데
이름도 거지같고 설명도 거지같아서 정확히 뭘 하는지 이해하는 거 자체가 거지같다
클리어가 Skybox이면 Skybox를 클리어한다? 실상 나타나는건 그 반대로 Skybox만 남긴다
반면 Depth Only의 경우는 진짜로 그 Depth만 남긴다.. 이러니 개판이지..
그러니 그냥저냥 알고 넘기자

Skybox

스카이 박스라 불리는 배경전용 셰이더로 빈공간을 채운다

Solid Color

빈공간을 단색으로 칠한다

Depth Only

빈공간을 투명처리한다.
카메라 두 대 이상을 한 화면에 합성할때 주로 사용한다.
아래 설명해놨지만 카메라의 Viewport를 수정하지 않는 이상 카메라를
10대를 놔도 한화면에 각 카메라의 영상을 가져와서 depth 순서대로 차곡차곡 쌓는다
당연히 화면에 투명한 부분이 없으면 뒤의 화면은 암것도 안보이게 되므로
이러한 처리가 반드시 필요하다
이는 또한 밑에서 설명할 Culling Mask와 같이 사용하는 것이 일반적이다
사용예를 하나 들어보자
적외선모드를 키면 벽넘어의 인물을 보이게 할려고 한다.
이때 벽을 랜더링 속성을 꺼버린다거나 하는 수가 있지만 일일이 벽들을 찾아서
그런 짓을 하기가 번거롭기도 하고 성능상으로도 문제가 될 수 있다
이것을 카메라 두 대로 처리하면 매우 간단히 처리가 된다
메인 카메라와 서브카메라를 두고 서브는
모든 사물의 모습을 끄고 단지 인물만 보이도록 해놓는다
그런 후 서브카메라를 Depth Only 설정으로 두고 켜버리면 벽안에 있든 말든
장소든 상관없이 화면 젤 위에 다 노출되게된다. 그런 점을 이용해서
일단 서브카메라를 꺼놓다가 적외선 모드 이런 것을 쓸때만 딱 키면
depth only
위에서처럼 벽넘어의 모습을 탐색하는 것 같은 효과를 줄 수 있는 것이다

Don’t Clear

이건 화면을 새로 갱신하지 않고 이전의 화면 위에다가 다시 그린다
덕분에 오브젝트가 움직이면 잔상이 화면에 잔뜩 남게 된다
일반적으로 게임에 사용하진 않지만 셰이더를 따로 만들어서 스파의 초필살기의
잔상처럼 쓸 순 있는 것 같기도한데.. 해보니까 2D 쪽은 뭔가 잘 안된다. 걍 패스

Background

위의 Clear flags에서 solid Color를 적용할때 나오는 색

Culling Mask

보여질 레이어들. 디폴트는 모든 레이어가 체크되어 있는데 체크를 끄면
해당 레이어의 물체들은 카메라 화면에서 안보이게된다. (모습만.. 그외는 그대로다)

Projection

원근과 직교 투사방식
원근은 가까운 건 크게, 멀리있는 것은 작게 보이는 방식이고
직교는 그딴거 없다.
화면상에 뭔가 보이는 방식은 카메라의 시야각안에서 평면으로 싹뚝짤라서 나오는 방식이다
Perspective
Perspective
A부분을 싹뚝 잘라서 가져오면 가까울수록 빨간 시야각이 좁으므로
화면이 작아서 상대적으로 물체가 차지하는 비중이 크다
B부분은 화면이 커져서 상대적으로 물체가 차지하는 비중이 작다

Orthographic
Orthographic
처음부터 시야각엄청 넓으면서 동일한 Orthographic 방식은 거리가 멀어도 항상
동일한 물체 크기를 가지게된다

Orthographic

Clipping Planes

위에서 싹뚝 자르는 것은 전지역에 걸쳐서 촘촘히 이뤄지는데
무한정 그러다간 컴터 터질 것이고 시작 평면과 끝 평면을 정해놓고 그 안의 것만
랜더링한다. 이 사이에 안들어가면 화면상에 보이지 않게된다

Viewport Rect

위의 perspective 화면을 보면
Perspective
사실은 이래야 정상이다. 화면 크기 자체가 달라지는 것이다
하지만 그렇게하면 화면상에 표현하는데 온갖 에로사항이 꽃피게 되고..
의도에도 맞지 않는다
그래서 뷰포트(Viewport )라는 모두에게 적용되는 가상의 화면이 필요하게 되었다
뷰포트는 모두가 같은 화면에서 단지 오브젝트의 비중으로 화면을 정하며
비중은 백분율.. 즉 0부터 1까지만 허용한다

  • X : 가로 원점
  • Y : 세로 원점
  • W (Width) : 가로 넓이
  • H (Height) : 세로 높이

이렇게 되어 있는데 하나의 카메라는 하나의 뷰포트만을 가지며
기본값은 항상 현재 화면의 전체크기이다.
그래서 기본값으로는 카메라가 10대라도 다 겹치게 되는 것이다
하지만 값을 변경하여 카메라 각각의 화면을 보이게 할 수 있다
viewport
xy를 0.7정도로 wh를 0.2 정도로한 미니맵용 카메라

Depth

오브젝트들이 순서가 있듯이 카메라의 보여지는 순서

Rendering Path

랜더링 패스를 지정한다.

Target Texture (Unity Pro only)

카메라 화면을 게임상 오브젝트의 텍스쳐에다가 붙여 넣을 수 있다
야구장에서 중계스크린이 붙어 있는 것 같은 효과

HDR

HDR 랜더링을 한다.

Written with StackEdit.

2015년 2월 21일 토요일

프로그래밍과 프로그래밍언어의 개념

목차


내가 처음 프로그래밍이란 용어를 접했을때의 이미지는
프로그래밍이란
이랬다.-ㅅ-
뭐 비슷한 점도 있지만 실제로 여기에 무슨 우주적 신비가 깃들어 있다거나 하진 않고 충분히 이해가능한 것이다
그래서 초보입장에서 네오랑 만나지 않게 한번 설명해보겠다

프로그래밍(Programming) 용어적 의미

먼저 IT계열은 항상 미쿡인이나 영어를 주식으로하는 나라들이 너무너무 부럽다
이들은 언어적 이점으로 인해 비영어권보다 몇배나 쉽게 프로그래밍을 배우기 때문이다
그에 관한 글 - 프로그래밍에서 용어와 영어의 중요성

Programming : 계획하는 것, 남이 할 일을 짜주기

프로그래밍의 경우 위와 같은 뜻을 지닌다
우린 컴터를 부려먹는다. 한데 부려먹을 컴터는 사실상 백치나 다름없다
그래서 우린 컴터가 할일을 일일이 계획을 짜서 건네줘야한다
그것을 ‘프로그래밍 한다’ 라고 한다
근데 얘는 외국인이므로 한글로 계획을 짜줘봐야 못알아듣는다
그래서 컴터의 고향언어로 짜줘야한다
그러한 언어를 프로그래밍 언어라고 하는 것이다

기계어와 컴퓨터

이제 프로그래밍에 대해서 대충 알게되었다
그럼 컴퓨터의 고향언어로 짜주면 그만이다
컴퓨터의 고향언어는 뭘로 되어 있을까
바로 기계어이다
(기계어에 관해서 더 자세히 알아보고 싶다면
[언어] 프로그래밍 언어의 역사 를 읽어보길 바란다
아주 재밌고 유익하다)

이건 또 무슨 거창한 외계언어일까 생각될 것이다
하지만 기계어는 이름과 달리 유치원생급 언어이다
아주 짧은 지시어들로 이루어져 있는데
가, 멈춰,
이런식이고 이들은 001, 1010 이렇게 0과 1로 이루어져있다
예를들면

stop - 000000
go - 000001
threeGo - 000010
Godolii - 111111

이런식이다. 왜 기계어가 이런식인지는
컴퓨터와 이진수 여기에 따로 설명해 두었다
여하튼 이런 기계의 언어로 해야할 일을 적어 놓으면
그게 바로 프로그래밍인 것이다
그럼 첫번째 프로그래밍을 해보겠다

10 - 오른발
01 - 왼발
11 - 앞으로

이걸로 ‘걸어라’ 라는 프로그래밍을 해보겠다

10 11 01 11… 반복

프로그래밍 개념
나 이짤 맨날 써먹는듯

새로운 프로그래밍 언어의 등장

엄청 쉽다. 근데 왜 어렵게 변했을까? 1
우리집 개 이름이 다롱이 인데.. 얘는 밥먹자 소리 안해도
밥의 낌새가 느껴지면 밥그릇앞에 대기해있다
견공지능의 위대함이다

하지만 컴터에겐 어림도 없다

밥먹자~ 라는 지시가 아니라 위의 걷기로 밥그릇 앞에까지
가게 해야한다. 위의 앞으로 라는 것도 어느정도 앞으로 가야되는지
정해야하고 1cm라고 치면 1m 전진에 아래와 같은 코드가 펼쳐진다

10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 ......
... (존내반복) .... 01 11 11 11 11 11 11 11 11 11 11 11.....

노가다도 노가다지만 어느 순간이 되면 이제 뭐가뭔지 알 수 없는 단계에 이르른다
그나마 저긴 꼴랑 3개의 지시어만 썼을뿐이고 지시어에 2자리만 사용할리도 없다
0000101010011 이런게 명령어 1개인 경우가 수두룩 하단것이다
저런걸 위에처럼 쓴다면 절대 못알아보게 된다

그래서 저딴 코드를 짜던 사람들이 더 이상 못살겠다며
인간답게 살아보자며 만든 것이 어셈블리어이다
그것은 숫자로 표현되던 기계어를 다음과 같이 표현하기로
약속하는 것을 말한다. 즉 어셈블리어의 문법을 창조했다

011110 011110
mov mov

근데 당연히 mov mov 이렇게 해놓으면 컴터가 알아들을리가 없다
그래서 mov라고 해놓으면 011110 으로 번역해주는 유틸을 만들었고
이제는 기계어를 쓸 필요가 없어졌다2
한데 이 어셈블리어도 상당히 기계어에 가까운 원시적 언어라
밥먹어라 ~ 라고하면

mov mov mov mov mov mov mov mov mov mov

이짓 하기가 일쑤다 (물론 코드자체는 상당히 다르다 걍 개념적으로)
그래서 더더욱 개공지능에 가깝게 만든 언어들이 나오고
이들은 위의 코드를

moveToEat

이런식으로 더욱 발전시켰다.
또한 각자의 방식, 용도에 따라 더더욱 분류가 되었고
오늘날에 이르러 프로그래밍 언어는 그 수도 장난이 아니게되었다

다만 ‘밥먹자’ 라는 개념이 전세계 어디서나 있듯이
프로그래밍 언어도 공통적인 개념에서는 크게 벗어나지 않아
하나의 프로그래밍 언어를 익히면 다른 언어의 문법에는 쉽게 접근할 수 있게된다 (특히 C를 익히면 어떤 언어든 접근이 쉽다)

Written with StackEdit.


  1. 참고로 레지스터니 메모리관리니 이런건 일단 제외한다. 이 글을 읽을 사람이 그런거 보면 메트릭스로 다이빙하는 수가 있으니까.(사실 나도 모른다는게 더 큰 이유) ↩
  2. 그것을 어셈블러 라고 하는데 그 후의 언어에는 일반적으로 컴파일러 로 퉁친다 - 더 자세한건 위키참조 ↩
2015년 2월 20일 금요일

컴퓨터와 이진수

목차


이진수란

두 가지의 표현방식을 가지는 것을 이진법이라 한다
세 가지라면 삼진법, 네 가지라면 사진법이다

수업시간에 질문하기를 손을 들고 내리는 방식으로 정의하면
이진법이다. 손을 든다, 내린다 두가지이므로..
일주일은 요일을 표현하는 7진법이다

그러한 진법들의 각 표현에다가 수로 대응한 것이 진수이다
이진수의 경우 두 가지 표현의 각각에
0과 1을 할당했다

위의 질문하기에 대입하면

0 - 손내리기
1 - 손올리기

로 볼 수 있다
여기까지만 보면 이들의 가치에 의문을 가지게 되지만
오른손 왼손으로 보게 되면 표현수가 극적으로 늘어나게 된다

00 - 오른손 내리고 왼손 내리기
01 - 오른손 내리고 왼손 올리기
10 - 오른손 올리고 왼손 내리기
11 - 오른손 올리고 왼손 올리기

어떤 표현을 할 수 있는 것을 하나 추가할때마다
표현 가짓수는 제곱으로 늘어나게 되어

비록 2진법이라도 모스부호 처럼 모든 문자를 표현 가능하게
되는 것이다

컴퓨터에서의 이진수

컴퓨터는 자신의 의사표현 방식이 이진수이다
정확히는 반도체 하나의 표현방식이 이진수이다
앞서 말했듯이 모이고 모이면 대규모 표현이 가능해진다고 했다
그래서 반도체를 왕창 때려박아놓은 컴터가 각종 다양한 표현이 가능한 것이다

근데 왜 이진수 방식일까. 이왕이면 10진수가 가능한 부품을
왕창 때려넣으면 지금과는 비교가 안될 것이다

그것은 기계란 것을 창조해내는 과정에 있어서
뭔가를 작동하게 하는 것도 힘들지만 뭔가를 표현하게 하는것은
더더욱 힘들기때문에 생겨난 방식이다
예를들어 당신에게 여러개의 증기기관을 주고
숫자를 시각적으로 표현하라 하면 어떻게 하겠는가?
상당히 머리 아플것이다

그래도 한개 작동하면 1번 번호판을 내리고 두개 작동하면
2번 번호판 내리게 하고.. 이런식으로 무게추와 톱니바퀴
이용해서 어찌어찌 만들면 될것이다

그런데 증기기관 가지고 그런짓하긴 골때린다
그런 가운데 힘을 전달하는 매체로서 가장 탁월한 것이 나왔고
그것이 전기다.
위의 것을 전기로 바꾸면 전기볼트가 일정이상 넘어가면
뭐가 작동하고 하는 아날로그 식으로 할 수 있을지도 모른다
하지만 그러한 아날로그식 제어는 주변환경의 영향이 극심하고
제어 자체가 매우 힘들다.
그래서 현재 가능한 부품으로 최대한 주변영향을 배제하면서
명확한 결과를 낼 수 있는 방법을 고민해보니

전기가 통하면 1, 전기가 안통하면 0

전기가 통하는가 안통하는가로 따지는 이진법이 짱이었던 것이다
그리고 그런 부품을 왕창 때려박으니 그럭저럭
표현이 풍부해지게되었다. 하지만 진공관 같은 거대한 부품을
그런 수로 때려박으니 부피와 무게가 감당이 안되게 컸었다
세월이 흘러흘러 똑같이 통하고 안통하고를 제어할 수 있으면서도
부피와 무게가 머리카락보다 작게 할 수 있는 반도체를 만들게 되었고
이제 그런 부품 크기가 작아짐에 따라 컴터도 역시 작아지게되었다

아래의 동영상이
컴퓨터의 표현과 2진법의 관계를 잘 나타내줄 것 같다 ^^

벨브(1작동,0잠금)를 여러개 배치해서 표현하는 물 그래픽


Written with StackEdit.

xpath 의 개념과 문법

목차


xpath의 개념

우린 파일을 찾을때 탐색기를 이용한다
탐색기는 미지의 장소를 그냥 탐험하는게아니라
길, 즉 path를 따라가서 원하는 곳을 찾아내는데
C:\windows\System32\important\왜가리
위와 같은 형식이고 이것이 윈도의 path 문법이다

마찬가지로 xml도 원하는 태그나 속성을 쉽게 찾기 위해
path문법을 만들게 되었고 xpath라 명명하게되었다

xpath의 Node

xml도 윈도처럼 단순히 파일과 디렉토리만 딸랑 있다면 매우좋았을 것이나
불행히도 <body style="sexy" class="top"> -ㅠ- </body> 이런식으로
우리가 찾아야할 것은 body라는 태그 하나로 끝나는 것이 아니다
각 태그에는 속성도 있고 속성값도 있고 태그의 내용물도 있다
그래서 이걸 어찌해야하나 고민하다가
그냥 모조리 node 라는 단위로 퉁쳐버렸다
<body style="sexy" class="top"> -ㅠ- </body>
위는 5개의 노드로 이뤄졌다고 할 수 있다
이렇게 노드로 만들고 나니 각 노드들 중에 동일한 타입들이 존재했다.
xml을 완전히 분해해봤을때 6가지 타입만 있으면 xml은 쫑이었다
그래서 노드들을 더욱 찾기쉽게 각 타입마다 이름을 붙여주었는데
그 과정에서 얘네들을 전부 포함하는 가상의 타입이 하나 추가되었다. 그게 다음과 같다

노드명 설명
root node 1 xml 자체를 표현하는 가상 노드
element node 태그
attribute node 속성
text node 태그 내용
namespace node xmlns: 로 시작하는 태그
processing-instruction node <?xml version="1.0" encoding="UTF-8" ?>
이렇게 <? 태그로 시작하는 애들을 말한다
comment node 주석문

7공주도 아니고 성질나게 많지만 다행이
자주 사용하는 것은 element와 attribute 노드이고
xpath의 사용법도 이들에 집중되어 있으니
element node, attribute node, text node
요렇게만 알고 있어도 끝이다

xpath 문법

자 이제 한번 xml의 신비로운 육체를 탐험해보자..-ㅅ-
너무 신비로운 나머지 쪼매 복잡한데
다 때려치우고 쉬운것만 맛보자
그것만으로도 왠만한건 다 해치울 수 있다

element node

<?xml version="1.0" encoding="UTF-8"?>

<bookstore>

<book>
  <title lang="en">Harry Potter</title>
  <price>29.99</price>
</book>

<book>
  <title lang="en">Learning XML</title>
  <price>39.95</price>
</book>

</bookstore>

위에서 book 태그를 찾아 들어가고 싶다면?
윈도처럼 쓰면 아래와 같은데
/bookstore/book
윈도에선 book 이라는 이름 하나는 하나만 찾는다는 소리지만
xpath에서는 NodeName 은 기본적으로 모든(ALL)을 뜻한다.
왜냐.. 윈도에는 같은 이름 디렉토리를 못만드는 반면 xml은
같은 태그를 줄창 만들 수 있으니까..-ㅅ-;;

하지만 원하는 것만 찾는 방법도 필요할터..
그래서 조건을 걸때를 위해 [] 대괄호를 제공해준다
아래는 첫번째 book만 찾아준다
/bookstore/book[1]

수식도 쓸 수 있다
/bookstore/book[price>35.00]

자.. 다시 해석하면
모든 bookstore 아래의 모든 price 의 값이 35 이상인 모든 book
이 되시겠다2
또한 //book 이렇게 쓰면 모든 book을 찾아준다
bookstore//book 이럴 경우는 bookstrore 안쪽의 모든 book을 찾는다
즉, 아래쪽의 모든 것을 찾을땐 //을 쓴다
book 그냥 이렇게 쓸 경우 현재 있는 곳에서 모든 book을 찾는다
저 위의 예제에서 저렇게 쓰면 암것도 못찾는다
book은 bookstore 아래에 있기 때문이다

attribute node

여기서 날카로운 사람이면 의문을 가질 수 있을 것이다
위에서 7개의 노드가 있다고 했는데 이런식이면
저건 Element 노드만 찾는게 아닌가.. 라고..
맞다. 앞서 말했듯이 xpath는 7개 노드 만들긴 했는데
딴건 워낙 잘 안쓰니까 가장 잘 쓰는 Element 노드는 위에처럼
걍 써도 되는 특권을 줬고
그 다음 잘 쓰는 Attribute 노드의 경우 앞에 @를 붙인다
//@lang
이럴 경우는 모든 곳에서 lang Attribute 노드를 찾는다
참고로 lang 속성을 가진 Element 노드를 찾는게 아니다
정확히 Atrribute 노드만 반환한다

그럼 저 속성을 가진 Element 즉, 태그를 찾고 싶다면?
앞서의 조건을 걸려면 [] 대괄호를 쓴다고 했다 그대로 하면된다
//title[@lang]
이러면 lang 속성을 가진 title 태그 노드를 반환한다

text node

마지막으로 또 하나의 중요한 노드인 Text 노드를 찾고 싶다면?
text()
를 사용한다. text 노드는 태생 자체가 엘리먼트 노드인 태그안에만 존재하기 때문에 문법도 일단 처음에 엘리먼트 노드가 나와야만 한다
//title/text()
모든 title 태그 안에 있는 Text 노드 추출

//text()
모든 태그안의 text 추출

xpath 테스트

그외에도 선택자로 찾기도 있고 그런데 여기까지 알았으면
그것들을 사용하는 것도 크게 어렵진 않다
문법을 참고한 후
http://www.w3schools.com/xpath/xpath_syntax.asp

이 사이트에서 연습해보면 xpath를 자유자재로 사용가능하게되고
이제 인간 XML 탐색기로 거듭나게 될 것이다 +_+
http://www.xpathtester.com/xpath

Written with StackEdit.


  1. w3school에서는 Document node라 되어 있는데 그런 노드는 없다. http://www.w3.org/TR/xpath/ 참조 ↩
  2. 어? 위의 book[1]은 그럼 book의 value가 1인거 아닌가요?
    라고 할 수 있는데 숫자만 쓰여졌으면 걍 순서고
    직접적으로 element랑 비교수식이 있으면 자동으로 값과 비교된다
    머리아프니 걍 그런줄 알고 넘어가자 ↩
2015년 2월 7일 토요일

유니티 Mathf.Lerp Mathf.LerpAngle

목차


Mathf.Lerp 선형보간법

Interpolation 이라는 용어가 있는데 보간법(補間法)이라고 한다

본인은 수학도 잼병이고 이런 용어도 너무 약하다
거기다 검색해보니 너무 고차원적이라 간신히 흰것은 웹페이지 바탕화면이고
검은것은 글씨라는 것 정도만 해석 가능했다
그래도 어쩌랴 궁금한걸..;;;

일단 용어부터 시작하겠다
보간.. 간격을 보충한다는 말이다. 여기서부터 슬슬 복잡하게 전개되는데
본인은 그런건 관심없고 용도만 관심있으므로 최대한 내 맘대로 설명하겠다

어떤 두점 사이에서의 위치를 수학공식이나 법칙에 따라
t 라는 진행시간에 어디에 있을지 예측해내는 것이다

예를들면 친구가 놀러온다고 했을때
‘어디쯤 왔을려나? 아까 출발했으면 대충 xx슈퍼앞이겠네’
이게 보간법이다.
내 집(시작점)과 친구집(끝점)을 알고 있고 칭구의 속도라거나 길이라거나
내가 알고 있으므로 위치 예측이 가능하다
물론 지그재그로 온다거나 하면 예측공식은 더더욱 복잡해지는데
그냥 직선으로 온다고 가정하는 것을 선형보간법(Lerp)이라고 한다
그리고 여기서 t 라는 값은 진행시간 혹은 진행과정인데
그런걸 나타내는데는 역시 백분율이 짱이다
그래서 출발을 0으로 두고 도착을 1로 둔다.
그냥 정수로 했으면 나 같이 단순한 사람은 평화를 만끽했을텐데 아쉽게도
더욱 정밀한 걸 원하는 사람이 많아서 실수(float)로 0과 1사이가 되었다
대충 0은 0%, 0.5는 50%, 1은 100% 라고 생각하자

이제는 Mathf.Lerp 의 설명이 좀 쉽게 된다

Mathf.Lerp(float from, float to, float t);

from은 시작점, to는 끝점, t는 진행률이다
당연히 t가 0일때 반환값은 from 이고 1일땐 to를 반환한다
0.5일땐 from과 to의 중간값을 반환한다

예를들어

Mathf.Lerp(10f, 20f, 0.2f);

이면 10과 20의 20% 지점인 12를 반환한다.

Mathf.LerpAngle

Mathf.LerpAngle 은 위의 Mathf.Lerp 메서드의 각도버전으로
작동방법은 비슷하다
하지만 두가지가 다른데
첫째로 각도버전이므로 시작값과 끝값이 360도 범위를 벗어나면 안된다
벗어날 경우 NULL인지 예외발생인지 모르겠지만 여튼 작동하지 않는다
둘째로 Mathf.Lerp로 루프문을 돌릴 경우
Lerp( 300, 350, t) 이러면 t의 비율로 점점 300이 350으로 다가선다
이건 아무 문제가 없다. 그런데 각도는 360이 한계다
그래서 그걸 넘으면 다음과 같은 일이 생길 수 있다
Lerp( 300, 0, t)
300이 360을 향해 다가서다가
갑자기 0으로 돌아선 목표를 따라 이번엔 반대방향에서 다가서는 것이다
이 경우 물체가 회전을 하다 360을 넘으면 급격히 반대방향으로
도는 현상을 볼 수 있다
하지만 Mathf.LerpAngle은 그런 것을 내부에서 잘 처리해준다

이제 실사용예를 보자

float lerpAngle = Mathf.LerpAngle (tr.eulerAngles.y, target.eulerAngles.y, smooth * Time.deltaTime);

//간소화

float 목표각도 = Mathf.LerpAngle(나의 현재각도, 타겟의 현재각도, 민감도);

아래쪽의 간소화대로 설명하면
주로 얘는 LateUpdate() 같은데 쓰이는데 여튼 계속 업뎃함수로 무한 루프를 돈다
그럼 목표각도는 나의 각도와 타겟의 각도 사이의 값을 주는데
민감도 값이 100% (실제 float값으론 1.0f) 면 당연히 타겟 각도를 바로 돌려주어서
업뎃 한번에 타겟과 동일 각도를 유지하게 된다
반대로 민감도 값이 낮으면 낮을 수록
(그렇다고 0을 먹이면 각도 변화는 없으니 하지마-_-;;)
목표각도가 타겟의 각도에 쪼금씩 접근하게 된다.

예를들어 0.5를 먹이고 A(나) 와 B(목표)가 각각 0도 100도 라면

  1. 50도, 100도 - 변화량 100도의 절반인 50도
  2. 75도, 100도 - 변화량 50도의 절반인 25도
  3. 87.5도, 100도 - 변화량 25도의 절반인 12.5도

이런 식이다. 나름 목표에 가까워지면서 자연스럽게 느려지는 효과도
부가적으로 얻을 수 있는 것이다

아.. 수학 실타..;ㅁ;…

주의점

Lerp를 목표수치에 정확하게 도달하는지 검출하는 식으로 사용하면 안된다.
예를들어 아래 문장을 무한루프를 돌렸을때
from = Mathf.Lerp(from, to, T);
최종적으로 from이 to 값이 되진 않는다는 것이다
T가 1이 아닌이상 매우 가까워지긴 하지만 닿진 않는다
또한 거리 보간 효과를 노리고
sqrMagnitude 와 같이 사용하는 것은 금물이다.
sqrMagnitude 는 제곱값이기 때문에 float.Epsilon 과 비교했을시
최소값에 도달하지 않아서 원하는 결과가 나오지 않을 수가 있다
….ㅠㅠ;; 본인얘기임..

Written with StackEdit.

2015년 2월 6일 금요일

안드로이드 merge 와 include 레이아웃 기법

목차


merge태그와 include태그 소개

안드로이드의 레이아웃의 멋진 기법으로
include와 merge 라는 것이 존재한다
공식홈피와 블로그에서도 소개해놨따
http://developer.android.com/training/improving-layouts/reusing-layouts.html
http://android-developers.blogspot.kr/2009/02/android-layout-tricks-2-reusing-layouts.html

또한 요런 사이트도 있다
안드로이드 merge의 단점 (일어)
일어지만 중국어나 아랍어가 아닌게 어딘가

몰라도 상관없지만 알면 매우 편리한 기법이라고나 할까..
나 같은 귀차니즈머한테는 특히나..

include 태그

똑같은 태그를 또 쓰는 걸 좋아하는 사람은 없을 것이다
그래도 메뉴라거나 할려면 어쩔 수 없다
리스트뷰라면 뷰를 복제복제 해주니 나름 편한데 그런 방법이 없을까

라면 뭐.. 뻔하게도 include 다

마구 써야할 뷰를 하나 정의해주고
그것을 include 태그에 넣어주면 쿠킹완성

예를들어보자

설명이피료해
이런 화면을 만들어 줄려면
TextView를 여섯개나 도배해야한다. 근데 패턴이 있다
시작과 끝 시간.. 그럼 저것을 따로 만들어 보자

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    >

    <TextView
        android:id="@+id/txt_startTime"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginBottom="30dp"
        android:text="공부 시작 시간"
        android:textSize="20dp"
        />

    <TextView
        android:id="@+id/txt_endTime"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@id/txt_startTime"
        android:layout_marginBottom="30dp"
        android:text="공부 끝 시간"
        android:textSize="20dp"
        />
</RelativeLayout>

custom_timeset.xml
설명이피료해
이렇게 된다.

이걸 include를 사용해서 마구 붙여주면된다

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              android:orientation="vertical"
              android:layout_width="match_parent"
              android:layout_height="match_parent"
              android:padding="100dp"
    >
    <include
        android:id="@+id/include_layout"     <!-- 아이디 설정 가능 -->
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        layout="@layout/custom_timeset"      <!-- xml을 적는데 주의점 android빼고 -->
        />
    <include
        android:id="@+id/include_layout2"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        layout="@layout/custom_timeset"
        />
    <include
        android:id="@+id/include_layout3"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        layout="@layout/custom_timeset"
        />
</LinearLayout>

올ㅋ
설명이피료해
이렇게 되었다

결국.. ViewGroup을 따로 만들어놓고는 재활용하는 것이다
여기서 id가 어떻게 되는 것인지 궁금할 수가 있다

View include01 = findViewById(R.id.include_layout);
View include02 = findViewById(R.id.include_layout2);
View include03 = findViewById(R.id.include_layout3);

TextView tv1 = (TextView) include01.findViewById(R.id.txt_startTime);
TextView tv2 = (TextView) include01.findViewById(R.id.txt_endTime);
TextView tv3 = (TextView) include02.findViewById(R.id.txt_startTime);
TextView tv4 = (TextView) include02.findViewById(R.id.txt_endTime);
TextView tv5 = (TextView) include03.findViewById(R.id.txt_startTime);
TextView tv6 = (TextView) include03.findViewById(R.id.txt_endTime);

이런식으로 사용하면 된다
id가 겹치지만 윈도우에서 A폴더 B폴더 이름만 다르면 각 폴더안 내용물의
이름이 같아도 상관없는 것처럼 상위 뷰계층의 id안에서 findViewById를 하기에
문제가 없다

하지만 위에 보는것과 같이 코드가 더 추가되며
include 를 함으로써 뷰계층이 깊어진다

merge 태그

include를 쓸려면 반드시 감싸줄 ViewGroup이 존재해야만 한다
하지만 그것은 한편으론 뷰계층을 더 깊게하여 부하를 가중 시킨다

항상 레이아웃 디자인에 있어서 레이아웃의 중복은
좋지 않다.

그것을 위해서 나온것이 merge 태그로써
위에서 RelativeLayout 대신에 merge를 사용할 수 있다

<?xml version="1.0" encoding="utf-8"?>
<merge
    xmlns:android="http://schemas.android.com/apk/res/android"
    >
    <TextView
        android:id="@+id/txt_startTime"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginBottom="30dp"
        android:text="공부 시작 시간"
        android:textSize="20dp"
        />
</merge>

이렇게 되면 include 되는 순간 merge 태그는 사라지고
그안의 내용물만 바로 붙여지게 된다
include의 최대 단점이 사라지게 되는 것이다
대신 merge의 슈퍼울트라 단점이 있는데
merge는 뷰 그룹을 생성하지 않음으로써 include와 달리 id 사용이 제한적이다
무슨 소리냐면
View include01 = findViewById(R.id.include_layout);
여기서 include01 이 NULL로 떨어진다는 것이다
아까 말했듯이 merge 태그가 사라짐으로써 include 할때 붙여주는 id도 함께
날아간다. 그렇게 되면 붙여주는 include 마다의 구분이 사라지게됨으로써
각 merge 의 내용물 뷰 역시 같은 id로 둘 수 없게된다
결국 include와 똑같은 효과를 볼려면
merge 로 만드는 뷰도 3개 만들어야한다는거..
노가다를 줄인답시고 하는건데 노가다가 배로 늘어버린다 -_-

그럼 왜 이런 정신나간 태그가 존재하는가

이 경우는 같은 xml이 아니라 각각의 xml에서
똑같은 형식이 딱 1개! 만 필요할때 써주면 편하다
즉, 액티비티가 5개 있는데
각 액티비티마다 무시무시한 분량의 태그가 있는데 그것이 똑같이 생겼다면
merge로 만들어두고 각각 하나씩 붙여주면 되는 것이다

여기서 또하나 ViewStub 이라는게 있는데 걍 없는셈 치자 ^^
잘 쓰지도 않는거…

Written with StackEdit.

2015년 2월 2일 월요일

동기와 비동기 개념

목차


동기와 비동기는 완벽하게 용어적으로 차이가 있지만
실제 그 차이가 뭔지는 이상하게도 파악하기가 쉽지 않다
그래서 동기와 비동기의 차이점과 개념을 정리해 보았다

동기(synchronous)

싱크로 되었다.. 라는 말은 들어본적이 있을지도 모른다
더 쉽게 싱크로나이즈드 스위밍은 들어봤을 것이다
동기
이런거다

똑같이 움직이는 것이다

하지만 프로그래밍에서의 동기화란 현실과 좀 차이가 있다
현실에서의 동기화란 둘이 나란히 발을 맞춘다
정확하게는 속도를 서로간에 조절해서 일정한 속도로 나아가게 된다
그리곤 따뜻한 미소를 교환한다

컴터의 경우는 그딴 것 없다. 차가운 미소를 지은후 A 프로그램이
초고속으로 혼자가버린다. B 프로그램은 열심히 따라가는 수밖에 없다
그럼 이딴게 무슨 동기화인가 싶을 것이다
앞서 말했듯이 현실과 다른 방법으로 동기화를 한다
예를들면 토끼와 거북이처럼 토끼가 낮잠을 처자줌으로써 거북이와 만나게 되듯이
어느지점에서 강제로 한쪽이 다른 한쪽이 올때까지 대기하게 되는 것이다.

비동기(asynchronous)

현실에서 비동기는 엇박자가 나는 것을 말하지만
역시나 프로그래밍에서 비동기도 좀 다르다.
프로그래밍에서의 비동기는 그냥 각자 갈길을 가다가
‘살아있냐?’ 라는 뜬금포 메세지를 날리는 것을 말한다
혹은 불의의 일격을 당한다고 생각해도 된다

그래서 데이터를 비교적 안정적으로 받을 수 있는 동기식과 달리
비동기식은 상대방에게 스파이를 심어놔서 데이터가 넘어올때
통보가 오도록 조작해야한다

개념정리

둘의 공통점은 대기를 타던, 불의의 일격을 날리던
서로간에 데이터는 주고 받는다는 것이다.
전혀 관계없이 따로따로 논다면 애시당초 동기니 비동기니
그런 구분조차없다.

즉, 데이터를 받는 방식을 말하는 것이 바로
동기식과 비동기식이다.
말해줄때 데이터를 받는 두가지 방식! 이렇게 말해주면 땡스하지만
단순히 비동기 프로그래밍.. 이런식이라 이해가 어려웠던 것이다

또한 현실에선 정보를 주고 받는데 이 둘에 차이를 둘 의미가 없을만큼
편하게 주고 받는다. 그래서 더욱 이해가 어렵다

실상 프로그래밍의 세계가
구리고 원시적이고 말미잘지능의 미개한 세계라서
커뮤니케이션에 목숨을 걸어야한다는 것을 알기전엔 말이다

서로 하이파이브 한답시고 힘껏 손을 날렸는데
상대는 아직 주머니에서 손을 빼지도 않은 비동기 상태여서
귀싸대기 맞는 엄청난 에러가 시도때도 없이 발생하는 세계라는 것이다
(다른 말로는 Null pointer 에러라고도 한다-ㅅ-;;;
객체도 안만들었는데 데이터 날아와서 개망)

즉, 이쪽의 사람지능이 하이파이브할려고 손들면
저쪽의 사람지능이 알아서 손을 빼드는 뛰어나고 아름다운게 현실세계라면
플그램 세계는 인형 두개 가지고 이쪽 손 내가 들게 하고
저쪽 손도 내가 들어서 정확한 타이밍에 하이파이브 시키게
끙끙대야한다는걸 명심하자

Written with StackEdit.

2015년 2월 1일 일요일

컴파일과 빌드의 개념

보통 초보들.. 특히 최근에 시작한 초보들은
컴파일과 빌드의 차이를 모르는 경우가 많다
왜냐면 툴들이 워낙 좋아져서
그 둘을 동시에 Run 하나로 퉁치기 때문이다

당연히 본인도 Compile, Build 에 대해서 잘 몰랐고
그닥 알고 싶지도 않았지만 안드로이드 스튜디오라는 툴을 쓰면서
강제로 알아야만 하게 되었다 ..;ㅁ;

컴파일(compile) : 소스의 문법을 분석해 기계어로 번역
빌드(build) : 번역된 것과 그외 잡다한걸 모아서 실행 가능한 파일로 만듦

보통 IDE(통합 개발 환경.. 걍.. 이클립스나 visual studio 같은 거..) 에서
프로그램을 짠 후 실행 시켜서 확인을 할때

주로 Run 이라는 메뉴를 쓸 것이다
그 Run 이란 명령어는 사실 [Build + 실행] 을 수행한다
그런데 여기서 또 사실 [Build = Compile + 잡다] 이다
고로 결국 컴파일과 빌드 모두 수행한다

그때 만약 문법에 오류가 있으면 컴파일 에러가 나고
문법은 괜찮은데 있어야할 파일이 없으면 빌드 에러가 나지만
이것도 Error!! 로 끝난다

결국
초보인 우리는 IDE의 편리한 메크로 기능때문에
‘Run 했더니 에러가 났엉’
정도밖에 인식을 못했고 그렇기에 컴파일과 빌드의 차이를 모르는 것이다

하지만 알고보면 그렇게 어려운 것도 아니다. 앞서 말한듯이 하나는 번역전문이고
하나는 그것을 포함한 실행파일을 만들어주는 모든 작업을 말한다

추상적인 예를들면
영어로 된 대본이 3장이 있다.
이것을 한국어로 해서 봉투에 넣어 배우한테 주면 임무 완료라고 하자
그런데
이것을 번역하는데 왠 인도어가 들어 있거나
철자가 틀리거나 하면 번역이 막혀버린다.. 이것이 번역불가.. 즉 컴파일 에러가 된다
한편 그런게 없어서 대본 3장을 완벽히 번역 했다
그래서 이제 3장을 봉투에 넣을려고 하는데 봉투가 없다!
혹은 봉투에 넣어 가져갔는데 배우가 튀었다!!
이것이 빌드에러이다

좀더 직접적인 예를들면
컴파일은 현재 내가 짠 프로그래밍 언어를 진정한 기계들이 알아듣는 기계어로
번역해주는 과정이다. 그렇게 번역된 기계어로 컴터는 명령을 수행할 수 있게된다
그런데 그 명령중에 ‘빤스를 가져와라’ 이런게 있으면
컴터는 이렇게 빌드에러를 낸다
‘빤스라는 리소스를 찾을 수가 없습니다. 먹는건가요?’
그럴때를 대비해서 빤스를 손에 쥐어주고
This is Pantsuuuuuuuuuuuuuuuuu!!!
라고 정확하게 알려줘야한다. 그렇게 명령을 수행할때 필요한 것들을
바리바리 싸주는 것이 빌드이다

즉, 컴터가 빵셔틀인건 맞는데 ‘야채빵 사와라’ 이러면 강력한 인공지능이
발휘되어 진짜 야채빵 사오는 현실의 빵셔틀과 달리
‘그게 모죠? 에러입니다’ 이러는 애가 바로 컴터다..
그러므로 ‘야채빵을 사와라’ 라고 할려면 야채빵을 손에 쥐어주던가
아니면 야채빵이 있는 장소를 말해주고
그 장소에 손수 야채빵을 준비해주는 빌드작업을 해줘야한다

또한 빌드 라는 것은
더욱 큰 개념, 즉 ‘완성과정’ 이라는 개념으로 확장해서 의미하는 경우도 많다
실행파일을 내놓는다는 것을 넘어 버그잡고 피드백 나누고 작업 주고받고 마케팅에 출시까지
포함해서 빌드시스템이라고 하는 경우다.

여하튼
프로그램이라는 것에서 컴파일은 번역 하나이지만
빌드는 소스와 그림, 아이콘 같은 것도 연결해줘야하고
다른 사람이 만든 라이브러리도 가져와서 관리하는 둥 훨씬 복잡하므로 따로
Gradle 같은 빌드자동화 툴이 나오기도 한다

Written with StackEdit.

2015년 1월 25일 일요일

Git 시작하기 3 - commit

목차


git commit 명령어

global 설정

추적도 되었겠다. 이제 백업만 하면 된다
그것을 해주는 명령어가 바로 git commit 이 되시겠다

일단 git commit을 쳐보자

그럼 git가 넌 누구냐 (-ㅅ- om
라고 강렬하게 물어온다

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address

그렇다. git을 사용하기 위해선 이름과 이메일을 기입해야한다
이유는 원래 git는 혼자서 가계부 만들려고 존재하는게 아니라
여러명을 대상으로 한다.
그리고 세상일이 그렇듯 여러사람이 작업하면 산으로 가는일이 많다
A가 수정하고 B가 수정하고 이러다가 어느날 갑자기 패망했을때
팀장이 길길이 날뛰며 ‘어떤 새끼가 이거 마지막에 수정했어?!?’
라고 한다면.. 사건은 미궁에 빠지고 김전일이 필요하게 된다

그래서 git는 누군가가 commit을 실행할때 반드시 그 정보를 기록한다
거기에 같은 팀이 아니라면 이름만 적어놓으면 또 찾기가 힘들다
email 주소는 그걸 위해 존재하는 것이다

근데 매번 commit때마다 그것을 적어주는 것은 너무 귀찮으므로
미리 설정파일에다가 설정해주면 일단 자기컴에선 항상 그 정보가 쓰이게된다

Run (이봐 실행해봐 라는 뜻-ㅅ-; 아래껄..)

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

잠깐 앞에의 오류메세지를 살펴보자 git가 얼마나 친절하고 착한지 알 수 있다
오류메세지뿐만 아니라 각종 status로 보거나 다른 명령어 치거나 할때마다
조언을 해준다. 문제는 영어라서 아무도 자세히 읽어보지 않는다는데 있지

저기 조대로 쳐주면 된다.

git commit -m

이제 정말 백업 준비완료
하지만 git commit만 치면 vi라는
초보자에겐 악몽과도 같은 편집기가 열린다

commit 했을때 백업이 되는데.. 백업할때 파일 이름 안짓고
백업하는 사람은 없을것이다
그것과 마찬가지로 메세지를 적어준다. 단, 파일 이름 적을때보다
훨씬 자세하고 알기 쉽게 적을 수 있는데
그런걸 하라고
git가 지딴엔 친절하게 메모장 같은 걸 열어주는 것이다
하지만 오지랖이 넓으면 오지랖퍼가 되는 법!
이 vi라는 편집기가 git보다 더 어렵다 (익히면 좋긴하다..)

그래서 우리는 어차피 쓸것도 그닥 없으니까

git commit -m “시작함다”

라고 해보자. -m은 message의 약자다.
물론 빼기 하나 더 붙여서 --message 하고 싶으면 해도된다
그리고 뒤의 "따옴표 안의 것이 자신이 백업할때 적고 싶은 정보다

이제 git status를 다시 쳐보면 아무것도 안나올 것이다
그 말은 현재 백업버전이 최신이라 아무것도 백업할 필요가 없다는 것을 의미한다

git add의 비밀과 git의 3단계 시스템

자 이번엔 AV list 파일에 파란 하늘을 새로 기입하였다
파일을 저장하면 파일이 변경되었음을 알려준다

git커밋

오호라~ 잘 추적하는구나
하면서 git commit -m "하늘이 푸르구나" 로 다시 백업을 시도한다
근데..

위랑 거의 동일한 메세지가 나오며 백업이 전혀 작동하지 않는다

그 이유는 git 시작하기 1에서 나왔던 add 명령어가
가진 출생의 비밀때문이다

얘가 사실은 추적에 등록하는 것 외에 또하나의 역할이 있는데
그것은 commit시 백업될 애들을 명단에 추가하는 것이다
무슨 명단?
그것을 알려면 이전에 잠깐 언급한 3단계 시스템을 이해해야한다
쉽게 말하면

일반인-> 오디션 -> 연예인
작업디렉토리 -> stage area(index) -> Head (committed)

이렇게 보면 된다-ㅅ-;;;
연예인이 될려면 일반인에서 일단 오디션에 뽑혀야한다
마찬가지로 백업이 될려면 일단 백업할 명단에 추가해야만 한다

왜 그냥 백업하지 않고 한단계 더 단계를 추가했을까?

그 이유는 여러가지가 있지만 일단 지금은 편리성과
좀더 정리된 commit을 위한 장치.. 라고 정도만 알고 있자

실제로 지금은 몰라도 전혀 상관없다
또한 우린 그것을 건너뛸 예정이다.

git commit -am

위의 3단계 때문에 우린 비록 추적하고 있는 파일이라고 해도
git add를 해주지 않으면 그 파일을 백업할 수가 없다

그럼 매번 git add 후 git commit 해야하나

그런 것을 쉽게 하기위해 우린 또 옵션을 사용할 수 있다
바로
git commit -a -m "설명"
의 -a 옵션이다
이 옵션을 추가하면 add 필요없이 무조건 수정한 모든 파일을
commit 해준다

이제는 그냥 수정후 백업하고 싶을때
저 명령어로 한번에 해결할 수 있을 것이다
저걸 더욱 쉽게 할려면
git commit -am "설명"
처럼 아예 연속적으로 붙여버릴 수도 있다.

다음편은 백업을 했으니 일이 잘못되었을때 복구할 방법을 보겠다

Written with StackEdit.

2015년 1월 22일 목요일

유니티 - Time.deltaTime

델타의 용어뜻

delta : an incremental change in a variable

불행히도 네이버 사전에는 없고
그냥 구글을 뒤져보면 여러뜻중에 저런 것이 있다
사실 우리도 지겹게 보아온 단어다
수학에서.. 델타가 어쩌구..
간단히 변화값이다. 혹은 경과값이라고 할 수 있다

유니티의 Time.deltaTime

여기서 유니티의 문서를 보면 Time.deltaTime을
이렇게 정의해놨다

The time in seconds it took to complete the last frame

바로 전프레임이 완료되기까지걸린 시간이다
1초 걸렸으면 1이 되고 10초 걸렸으면 10이 된다

즉, 컴터가 느릴수록 deltaTime이 커지는 특성이 있다
deltaTime 자체의 정보도 유용하지만 저 특성을 이용하면
컴퓨터의 성능차를 해결할 수가 있는 핸디캡으로 쓸 수 있다

델타타임의 용도1 - 성능보정

이건 쉬움

초인밥과 우리가 그림 경쟁을 벌이고 나면
다 부질없어 보이고 공허하고 뭐 그렇다

게임 역시 그렇다. 성능이 짱짱인 밥 같은 컴터랑
구석기 시대에 쓰던 컴터가 아무런 보정도 없이 맞붙으면
‘실력은 되는데 렉 때문에..’
라는게 정말 현실이 된다

하지만 그런 개소리를 방지하기위해
똥컴과 최신컴을 강제로 맞추는 방법이 있다

위에서 말한 핸디캡 바로 Time.deltaTime 이다

시간과 프레임의 개념

먼저 확실히 해둬야 할 것이
시간과 프레임의 개념이다
바로 시간은 누구에게나 공평하게 흐르지만
프레임은 그렇지 않다는 것이다

프레임이란 건
연속된 그림을 빠르게 넘기는 것에 비유할 수 있다
밥 형님은 복잡한 그림도 금방 금방 그려서 넘어갈 수 있다
하지만 우린 성능이 딸려서 빨리빨리 못그린다
그래서 화면이 버벅거리는 것처럼 보이는 것이다
결국 성능에 따라 1초에 10프레임이 나올 수도 있고
100프레임이 나올 수도 있다

만컴은 공평해야 한다

버벅거리는 것은 어쩔 수 없지만
결과가 성능에 따라 좌우되는 것만은 절대 안된다
상대랑 결투를 하는데 다른 이유가 아니라
컴퓨터 성능때문에 이쪽이 칼질 1번할 동안
저쪽은 30번해서 내가 걸레가되면 겜 할 맛이 날리가 없다

그래서 각 프로그램이 실행될땐 각 컴터성능에 따라 한프레임에 나오는
결과값을 보정해줘야한다

그럼 각 컴터의 성능은 어떻게 측정할까.
성능이라고 하면 당연히 빠르기이다. 그리고 우린 그 속도의 공식을 알고 있다
바로

컴터의 속도는 그렇다치고 거리가 뭥미 할 수 있지만
거리도 있다. 바로 프레임이다.
10초동안 10000 프레임을 달린 컴이
10초동안 100 프레임을 달린 컴보다 훨 빠르다
즉, 위의 식은 아래처럼 될 수 있다

우리가 하고자하는 것은 똑같은 10초의 시간동안 성능이 좋은 컴과
나쁜컴이 동일한 결과를 내는 것이다
초당 10프레임의 컴과 초당 20프레임의 컴의 결과를 같게 할려면?
결과값(처리한 프레임)이란건 속도x시간 이다
여기서 성능에 따라 다른 건 속도니까 각자의 속도로 나눠버리면
결과값 = 시간
이 되어 이제 시간과 결과값이 비례하게 된다.

근데 우린 주로 Update문에서 작업을 많이 한다
Update문은 한 프레임이다
그러므로 한 프레임의 속도는 이 된다
여기서 우린 1 프레임 실행 시간은 이미 알고 있다
바로 Time.deltaTime 님이시다

자 그럼
이게 1프레임의 속도이고 이대로 나눠주면 되는데
Time.deltaTime 은 속도의 역이므로 그대로 곱해주면 된다

시간, 속도 제어

Time.deltaTime은 각 프레임마다 곱해주면 성능에 관계없이
시간마다(프레임이 아니라) 동일한 결과를 낼 수 있게하는 편리한 놈이다

한데 한프레임의 시간을 알 수 있으면
시간이나 속도 제어도 할 수 있다

1프레임에 0.1초 걸린다고 하면 10초간 뭔가 하고 싶을때

deltaTime * frame = 10
frame = 10 / deltaTime

이렇게 몇 프레임이 걸리는 지 알수 있다
한데 우린 몇 프레임 걸리는 것보다 1프레임당 어떻게 해줘야되는지가
궁금하다.
가장 간단한건 아래처럼 목표 프레임 수를 구하고
매프레임 목표프레임이 되었는지 검사하는 방법이다

int frame = (int)(10 / Time.deltaTime);
float no = 0;
void Update(){
    if(frame != now){
        now++;
        작업내용...
    }
}

한데 Mathf.Lerp 같은 메서드들이 백분율로 작업해줘야하는 것들이라서
(Mathf.Lerp 에 관한 내용은 여길 참조)
보통 1 프레임당 걸려야 할 시간 이라는 기준으로 작업한다
그래서 을 수행하는 시간으로써
결국

이렇게 되어 매 프레임마다 목표시간을 나눠주게 된다.
예제는 다음과 같다

float movingTime = 10.0f;
float progress = 0.0f;          // 진행 백분율
void Update(){
        if(progress < 1){
            progress += Time.deltaTime / movingTime;
            작업내용..
        }
    }

Mathf.Larp 를 쓸 경우

float movingSpeedOrTime = 10.0f;
...
void Update(){
        from = Mathf.Larp(from , to, Time.deltaTime / movingSpeedOrTime);
        ...
    }

Written with StackEdit.

2015년 1월 17일 토요일

Git 시작하기 두번째

목차


Git의 기묘한 화면

앞서 Git 시작하기를 통해 Git를 시작하진 않고
버전 관리 시스템의 기본을 알게 되었다. -ㅅ-;

하지만 Git가 무슨 과학자들의 기묘한 발명품 같은게 아니라
누구나 일상적으로 사용할 수 있단 걸 설명하기 위해서 였다

그렇긴하지만 그래도 여전히 Git는 어려워 보일 수 있다

특히 윈도우의 ‘그래픽을 톡톡 클릭’(GUI)에 익숙해 있다면
git의 기묘한 모험

이런 git의 기본화면은 매우 가만히 있어야겠다는 생각을 들게 만든다

Git는 어렵지 않아요

하지만 실제 Git의 가장 귀찮은 부분들은 윈도상에서도 아주 쉽게 할 수 있고
위와 같은 화면상에서 git를 사용하는 부분도 매우 간단하다

오히려 조금만 사용해보면 윈도 프로그램이 더 짜증날 정도다

git는 무시무시한 3가지 영역으로 나눠져 있는데
그걸 설명해주면 곧바로 ‘Git는 사실 졸라 어려워요’ 가 되기때문에
일단 넘어가고

앞서 과정에서 수동으로 했던 부분을 Git셔틀이 얼마나 잘 해주는지
그것부터 하나하나 알아보자

Git 전용 백업 폴더 만들기

자 그럼 기본은 백업이고
백업을 할려면 폴더가 필요하다. git에게 시켜보자

git 초보
자.. 위의 파일들이 내가 버전관리를 하고 싶은 파일들이다
자꾸자꾸 수정해나가야하는 파일들인데 간혹 완전 꼬여서
어느 시점으로 컴백해야 할 필요가 있는 파일들이다

여기서 오른쪽 버튼을 누르면 Git 메뉴가 3개가 보인다
git초기화
백업 폴더를 만들고 관리를 시작하겠다는 것이 바로
Git Init Here 이다.
git 전용 백업폴더인 .git 가 만들어진다. 근데 안보인다. 왜냐 숨김폴더기 때문
모든 일은 git가 다 할테니 안보이는 편이 더 깔끔하다
참고로 .git 폴더를 지워버리면 다시 평범하게 돌아간다

Git에게 명령을 시켜보자

백업폴더가 형성됨과 동시에 이제 백업폴더를 가진 이 디렉토리에서
git가 활성화 된다

기트메뉴
그럼 오른쪽 버튼을 눌렀을시 앞서와 달리 git 메뉴가 변경된다
이것들도 굉장히 편리한 메뉴들이지만 지금 봐봤자
무서운걸 경험할 뿐이다. 그냥 가만히 있자

이제부터 우리는 처음에 봤던 기묘한 화면으로 작업을 해야한다
근데 겁먹을 필요는 없다
뻥좀 보태서 카카오톡보다 쉽다

Git Bash를 눌러서 git 명령어 화면을 열도록 하자
현재 폴더가 있는 곳에서 시작하는데
모든 git 명령어는 무려!!
git로 시작한다

라이코스 이리와
라이코스 손!
라이코스 잘했어!

대략 이런거랑 비슷하다고 보면된다
git babmuger 이렇게 쓰인다 (물론 저딴 명령어는 없다)

그리고 우리가 쓸 명령어는 5개도 되지 않는다 (물론 개초보 기준)

git status
git add
git commit

외울 필요도 없다.. 몇번쓰다보면 그냥 쓰니까

git status - 보고해 git!

git status는 현재 상황을 알려준다
당장 쳐보자
설명이피료해
올ㅋ
진정하자 아직 당황할때가 아니다
침차케

git가 외국애라서 한글이 딸린다. 1
그래도 사용시 지장은 없다

git add - 스토킹을 시작합니다

git add 가계부.txt 

를 해보자. 아무 반응이 없을것이다. 무소식이 희소식이라고
git는 잘되면 가만있고 잘 안되면 화낸다
그래서 git status 로 직접 살펴보자
설명이피료해
딱봐도 추가되었다는 것을 알수 있다. 한글걍 쓰면된다

근데 뭐에 추가가 되었다는 걸까..
Git 시작하기에서 말한 중요한 것중 하나가
통짜로 백업시 용량이나 시간을 감당할 수 없다는 것이었다
그래서 딱 수정한 파일만 살짝 빼내서 백업하면 된다고 설명했다
놀라운 발견이지만 그 수정된 파일이 뭔지 찾는 노가다는 전혀 놀랍지 않다

그래서 git에게 스토킹을 시키는 것이다
이제 저 add 된 파일은 git 스토킹 명단에 올라가서 영원히 고통받는다

git 명령어 옵션

근데 어차피 git질할 폴더에껀 대부분 다 추적할 파일들이다
(물론 그 중에 제외할 필요도 있다. 그건 나중에..)

‘그냥 다 추적해줌 안됨? 귀찮.. ‘

그런 분을 위해서

git add --all   

이 있다 (- 가 두개다)
의미는 몽땅 추가해다.

git의 각 명령어는 이런식의 옵션을 가지는데 명령어 뒤에 -? 를 붙이면
어떤 옵션이 있는 지 친절히 가르쳐준다(영어로-_-). 지금은 걍 무시하자.
저 위의 옵션은 누가봐도 이해 할 것이다
참고로 - 한개이면 -A -f 이런식으로 한자짜리 약자를 주로 쓴다
두개이면 위에처럼 --all --force 어느정도 단어를 적게된다
본인도 초보이므로 아래쪽을 선호한다.

설명이피료해

이제 전부 스토킹 명단에 추가되었다

남은 건 백업! 그건 다음편에..

Written with StackEdit.


  1. 덤으로 Git Commit Tool이나 GUI 등의 툴도 한글이름이 들어간 폴더에선 작동을 안한다 ↩