아주아슬

블로그 이사 후 첫 글

2011-01-20T23:23:00.003+09:00

이유는 모르겠지만 기존에 잘 쓰고 있던 텍스트큐브가 망했다.[............]

반강제로 블로거에 정착하게 되었는데,

굳이 다른 블로그 서비스로 이동하지 않고 텍스트큐브에서 지정해준 블로그로

이사한건... 뻔하잖아? 귀찮삼.

여튼 좀 써보다가 맘에 안들면 레알 이사를 가던가 해야겠다...

리호코는 긔엽구나!! - 아마가미 18화

2010-11-06T21:27:00.000+09:00

리호코는 긔엽구나!

리호코는 긔엽구나!!

리호코는 긔엽... 헑헑 리호코 허벅지! 절대영역 부왘!

리호코는 긔엽구나!!!

리호코는 긔엽구나!!!!

리호코는 긔엽구나!!!!!

리호코는 긔엽구나!!!!!!

리호코는 긔엽... 리호코 허벅지! 오버니삭스 너무 조타! 헑헑!

리호코는 긔엽구나!!!!!!!

리호코는 긔엽... 크구... 준이치 개새끼 씨발롬아!

리호코는 긔엽구나!!!!!!!!

리호코는 긔엽구나!!!!!!!!!

리호코는 긔엽... 자세 헑헑

리호코는 긔엽구나!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!

리호코는 긔엽...... 착하구나! ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

리호코는 긔엽구나!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!

리호코는 긔엽... 리호코 허벅지 헑헑

리호코는 긔엽구나!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!! 아 씨 너무 긔여워 ㅠㅠㅠㅠㅠ

리호코는 긔엽... 헑헑 리호코 목덜미도 섹시하긔!

리호코는 긔엽... 리호코 슴가 헑헑.

리호코는 긔엽구나!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽... 로리 버전조차도 긔엽구나!

리호코는 긔엽... 로리 버전조차도 긔엽구나!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽... 엉엉 이렇게 착할수가 ㅠㅠㅠㅠㅠㅠ

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!! 준이치 씨발롬아!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!! 준이치 씨발롬아!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!

리호코는 긔엽구나!!

리호코는 긔엽구나!!!

리호코는 긔엽구나!!!!

리호코는 긔엽구나!!!!!

리호코는 긔엽구나!!!!!!

리호코는 긔엽구나! - 아마가미 17화

2010-10-29T22:22:00.000+09:00

리호코는 긔엽구나!

리호코는 긔엽구나!!

리호코는 긔엽구나!!!

리호코는 긔엽구나!!!!

리호코는 긔엽구나!!!!!

리호코는 긔엽... 리호코 허벅지! 헑헑.

리호코는 긔엽구나!!!!!!

리호코는 긔엽구나!!!!!!!

리호코는 긔엽구나!!!!!!!!

리호코는 긔엽구나!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!

리호코는 긔엽... 저 몸 어디에 뺄 살이 있단 말이냐!

리호코는 긔엽구나!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽... 헑헑 리호코 알몸

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽... 슴가! 헑헑!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

리호코는 긔엽구나!

리호코는 긔엽구나!!

리호코는 긔엽구나!!!

VS 디버그에서 GetLastError 값 바로 확인하기

2010-10-29T18:24:00.000+09:00

Watch 창에서 @err, hr 이라고 입력하면

GetLastError 값이 출력된다.

우왕ㅋ굳ㅋ 안밎어먹게 기록해놔야징

SQL SERVER 동적 쿼리 sp_executesql

2010-10-27T01:09:00.000+09:00

사실 동적 쿼리는 안쓰는게 제일 좋고, 나도 안쓸려고 존나 지랄발광을 하지만

어쩔 수 없이 써야 할 때가 있다.

동적 쿼리를 실행시키는 방법은 크게 두가지가 있는데 하나는

그냥 exec 이고 다른 하나는 exec sp_executesql 이다.

둘 다 장단점이 있기는 개뿔이 exec sp_executesql 가 일반적으로 더 좋다.

exec sp_executesql 이 뭐가 더 좋은지는 검색하면 좔좔 나온다.

exec sp_executesql 구문은

처음 접하면 얼핏 이해하기가 힘든것 처럼 보이는데, 전혀 그렇지 않다.

혹시 exec 로 작성할 때 무한 CAST(@변수 as VARCHAR) 노가다를 해본 경험이 있거나

지금도 하고 있는 사람이 있다면 당장 exec sp_executesql 로 변경할 것을 권장한다.

exec sp_executesql를 사용할 때 가장 큰 장점은 내부적으로 뭐 어떻게 처리되는지 집어치우고

파라메터를 문자형으로 변환 하지 않고 그대로 넘길 수 있다는 점이다.

CAST(@변수 as VARCHAR)만 동적쿼리문에서 제거할 수 있는 것 만으로도 가독성이 극적으로 향상된다.

동적쿼리의 가장 지랄같은 점이 가독성을 좆같이 만들어버린다는 점인데, 그나마 어느정도 해결할 수

있는 방안이 exec sp_executesql 를 사용하는 것이다.

사용 시 주의할 점은, exec sp_executesql 사용하여 실행할 동적쿼리는 VARCHAR 형으로 작성하면

안되고 NVARCHAR 형으로 작성해야 한다는 점 정도?

동적쿼리를 짤 때의 고통.

C++ jsonCPP 의 파싱 버그

2010-10-04T16:54:00.000+09:00

C++ 용으로 애용되는 json 라이브러리인 jsonCPP 에는

사실 심각한 파싱 버그가 존재한다.

바로 parse 메서드인데

이게 제대로 된 json 이 아니라도 true를 리턴해버린다. -_-

예를 들어

{

"a" : 1

}

라는 json이 있다고 하면

{

"a" : 1

}}}}}}}}}}}}}}}}}}}}}}}}}

이런것도 parse 하면 true를 리턴해버린다. 샹 존나 아름답다 -_-

참고로 대괄호가 없어도 true를 리턴해주며 이런저런 상황이 존나많다.

여튼 false 리턴하게 하는게 더 힘들정도다 -_-

가장 좋은 방법은 파서를 직접 만드는 것이겠지만 그건 너무 귀찮고;

일단 간단하게 나마 어느정도 해결할 수 있는 방법은 size 를 체크해 주는 것이다.

그래도 일말의 양심은 있는지 잘못된 json 은 size 가 0 이 나온다.

아직까지 나온데 0 번대 버전이라(0.5.0) 그런거겠지.

버전 없을 하면 나아지지 않을까?

근데 버전업이 될 기미가 안보임 -_-

스테이츠맨이 갖고 싶다!!!!!!!!!!!!

2010-09-26T00:32:00.000+09:00

추석 연휴 때 정말 우연찮게 지인의 스테이츠맨을 빌려서 하루종일 운전했었다.

GM대우에서 수입했다가 소리소문 없이 망해버린 스테이츠맨.

여태 관심이라곤 쥐뿔도 없는 차량이었는데... 이번 기회에 운전하면서 완전히 반해버렸다.

스테이츠맨의 등급은 에쿠스, 체어맨과 같은 대형 세단. 크기만 따지면 제일 크다.

예전 회사에 다닐 때 몇 번 정도 뉴체어맨을 몰아본 적이 있었는데, 확실히 뉴체어맨보다 낫다.

에쿠스는 몰아본 적이 없어서 모르겠지만 체어맨보다 운전하기가 좆같다고 하니 비교해볼 가치도 없을듯.

국내 현지화에 실패해서 차량 내부의 인터페이스가 상당히 생소하다는게 큰 단점이긴 한데,

개인적으로는 큰 문제는 되지 않았다.

이 차는 직접 운전해봐야 진가를 느낄 수 있다. 체어맨이나 에쿠스처럼 뒷좌석에 앉았을 때 진가를 알 수

있는 차가 아닌것이다.

특히 대형 세단이면서도 중형 세단을 운전하는 감각 그대로 운전 할 수 있다는거에 정말 감탄을 금치 못했다.

체어맨 운전석에 앉으면 대형 세단의 크기와 시야 때문에 다소 위화감을 느끼게 되는데 스테이츠맨은

그런게 전혀 없었다. (스타렉스 같은 RV를 처음 몰아본다고 해도 기존의 운전감각에 위화감을 느끼지 않고 평범하게 운전이 가능하지만 만 대형세단은 다소 독특한 위화감이 있다. 나만 그런가?)

운전감각이 일반 세단의 그것과 동일하다고 해서 치고 나가는것 까지 동일하다는 이야기가 아니다.

배기량 답게 속도계는 아무 저항 없이 올라가고, 특히 저회전에서 터지는 토크는 일품!

솔직히 바이크를 탈 때도 마력은 낮지만 저회전에서 토크가 폭발하는 세팅의 엔진을 가진

바이크를 타본 적이 없어서 토크빨이라는걸 잘 느끼지 못했는데 그걸 스테이츠맨을 타보면서 처음 느꼈다.

정말 좋다. 더불어 운전을 그렇게까지 편하고 안정감있게 해줄 줄은 몰랐다.

차 전체적인 성격은 아주 묵직하다. 뭘 해도 묵직하다. 치고 나가는 것도 빠르게 치고 나가지만 그러면서도

묵직함은 유지된다. 스티어링도 상당히 묵직한데, 처음 잡았을 때는 다소 놀랐을 정도. 일반적인 국산차가

스티어링이 상당히 경쾌한것에 비하면 완전히 다르다.

'왜 이렇게 묵직허냐' 하고 처음에는 불평했지만 익숙해지니 이것만큼 편하고 재밌는게 없다.

여튼 이래저래 썻지만 결론은 정말 운전하기 좋은 차라는거다. 차 운전을 이만큼 재밌게 해본 적이

없었던 것 같다. 그것도 대형차에서 이런 재미를 느낄 줄이야.

스포츠카나 바이크처럼 빠르면서 휙휙 돌리는 재미와는 완전히 다르다.

느긋한 주행을 하면서도 충분히 재미있는 주행이 가능하다는걸 보여주는 멋진 차.

씨발 돈도 얼마 못버는데 정말 엄한 차에 반해버렸다. 이걸 어째...

바람피지 맙시다

2010-09-21T15:36:00.000+09:00

읽는 내내 통쾌함.

SQL SERVER 에서 동적 WHERE 절 만들기

2010-09-18T02:28:00.000+09:00

어제 쿼리를 존나 짜고 있는데, 기능 상 문제로 인해 WHERE 절만

조건에 따라 변하게 해야 하는 일이 있었다.

누구나 알다시피 특정 조건에 따라 WHERE 절만 조작하는 것 자체는 쉬운 작업이다.

단, 이게 ad-hoc쿼리가 아니라 프로시저 단에서 쿼리를 작성할 때는 문제가 달라진다.

프로그램 코드 상에서 ad-hoc 쿼리를 사용하면 아주 간단하게 해결 되는 예다.

(ad-hoc쿼리란 프로그램에서 직접 쿼리문을 작성해 호출하는 것을 말한다.)

string sql = "SELECT * FROM [dbo].[USERS] WHERE ";

if(hasCar())

sql += " CARNUMBER = " + carNumber;

if(possibleSuperSex())

sql += " AND SEXTIME >= " + sexTime;

뭐 이런 식으로 WHERE 절을 얼마든지 구성할 수 있다.

그럼 프로시저에서 저런 식으로 WHERE 절을 조건에 따라 구성할려면 어떻게 해야 할까?

가장 쉬운 방법으로는 T-SQL에서 스트링으로 쿼리문을 구성해 exec로 실행시키는게 있다.

DECLARE @sql VARCHAR(MAX);

SET @sql = "SELECT * FROM [dbo].[USERS] WHERE ";

IF @hasCar > 0

BEGIN

sql += " CARNUMBER = " + @carNumber;

END

IF @possibleSuperSex > 0

exec @sql;

뭐 이런 식으로 ad-hoc 에서 하던 것과 비슷하게 동적 쿼리를 구성하여 실행할 수 있다.

문제는 이게 상당히 ad-hoc 때와는 달리 상당히 귀찮은 작업이라는 점이다. 해본 사람은 알꺼다.

특히 프로시저 내에서는 그냥 스트링 같은데 쿼리를 담지 않고 평범하게 때리면 평범하게 잘 작동한다는걸

의식하기 시작하면 스트링에 쿼리를 동적으로 구성하는 일 자체가 짜증나기 시작한다.

쿼리가 길어지기라도 하면 어우 썅...-_-;

특히 나는 그냥 WHERE 절만 바꾸면 되는데 고작 이것땜시 쿼리 전체를 동적 쿼리로 작성하자니

이건 머 짜증이 머리끝까지 솟는다. 동적 쿼리만 구성 안하면 인텔리센스도 잘 작동하고, 알아서 쿼리 오류도

체크해주고 하는데! 그런 지원을 못받으니까 짜증이 날 수 밖에 없다.

그렇지만 동적 쿼리를 구성하지 않고 WHERE 절만 동적으로 작동하게 할 수 있는 방법이 있다.

별 다른 기법이 아니라 아주 기본적인 쿼리의 원리와 CASE WHEN 문만 이용한다면 WHERE 절을

동적으로 구성할 수 있다.

SELECT * FROM [dbo].[USERS]

WHERE CARNUMBER =

CASE @hasCar

WHEN @hasCar = 1 THEN @carNumber

ELSE CARNUMBER

END

AND

SEXTIME >=

CASE @possibleSuperSex

WHEN @possibleSuperSex = 1 THEN @sexTime

ELSE SEXTIME

END

이렇게 말이다. 원리는 컬럼 = 컬럼 은 TRUE 라는 점과 WHERE 안에도 CASE WHEN 문을

쓸 수 있다는 것.

동적 쿼리를 작성하지 않아도 되고, 또 동적쿼리 싫답시고 조건 마다 쿼리 전체를 적어줄 필요도 없어진다.

어제 그래도 나름 머리 싸매고 고민한 결과가 좋은 결과로 나타난 것 같아 기쁘다.

물론, 결정적인건 구글링이었지만.[...]

3년을 머리 싸매고 연구하고 고민해도 끝끝내 아웃풋을 못낸 케이스도 있음.

아마가미 - 리호코 사이좋음 안해도 된다!

2010-09-06T00:39:00.000+09:00

당췌 언제 루리웹서 연재가 언제 될려나 하고 목빠지게 기다리다 지쳐서

그럼 걍 내가 해봐야지 하고 시작한거였는데

내일부터 기존에 연재하시던 분이 리호코 사이좋음 루트를 연재하시는 것 같다능.

존나 발번역이라서 차마 연재는 못하겠다 싶었는데

레알 다행임.

이제 즐겁게 연재를 기다리는 일만 남았긔. 아싸.

그래도 여태까지 해놓은건 아까우니까 지우진 못하게따;

아마가미 - 리호코 사이좋음(10)

2010-09-05T23:41:00.000+09:00

준이치 : (후우... 드디어 점심시간이다.)

리호코 : 실례합니다아~, 타치바나군 있나요?

여자A : 타치바나군, 저기 부르는데?

준이치 : 예이예이.

준이치 : 무슨 일이야?

리호코 : 에헤헤헤헤헤.... 조금 상담하고 싶은 일이 있어서...

준이치 : 응, 괜찮아.

리호코 : 자, 잠깐 이쪽으로 와줘.

준이치 : 여기서 하면 안돼?

리호코 : 조금... 그래.

준이치 : (대체 뭐야...)

리호코 : 그... 으음...

준이치 : 뭔데

리호코 : 살쪘을지도...

준이치 : 에?

리호코 : 살쪄버린거 같다구!

준이치 : 에에?

리호코 : 그치?! 놀랐지?

준이치 : 아니, 리호코가 그런걸 신경쓴다는데 의외라서.

리호코 : 우에, 너무해~

준이치 : 뭐, 방금 말은 농담이었고... 그렇게 살찐것처럼은 안보이는데?

리호코 : 그, 그래?

준이치 : 내가 보기에는, 이지만.

리호코 : 그치만...

준이치 : 그러니까 그렇게 신경 안써도 괜찮을것 같은데?

리호코 : 그치만 안된다구~!

준이치 : 갑자기 왜그래;

리호코 : 좀 있으면 신체검사 하잖아?

준이치 : 아아, 그렇지. 그게 왜?

리호코 : 신체검사라는건 숙녀에게 있어서 정말 큰일이라니깐~!

준이치 : 그런건가... 그래서?

리호코 : 에?

준이치 : 그래서 리호코는 어쩔건데?

리호코 : 아, 응. 그래서 있지. 다이어트 하는 것 좀 도와줬으면 싶은데...

준이치 : 다이어트인가...

리호코는 수영 보충 수업도 받고있잖아?

그런데도 안빠지는거야?

리호코 : 안되는것 같애... 그거랑.

리호코 : 시간 얼마 안남았으니까 즉효성이 있는게 아니면...

준이치 : 즉효성이라니...

다이어트라는건 그렇게 해서 되는게 아니잖아.

리호코 : 그건 알고있지만서도...

준이치 : 평소에도 절제하지 않더니, 최근 소문의 초특성 어쩌구 파르페만 먹어제꼈으니 이렇게 된거다.

리호코 : 안먹었다니깐!

준이치 : 그랬냐.

리호코 : 경천동지풍림화산 파르페 말하는거지?

........이게 아니라, 다이어트 할려고 하는데 파르페 이야기는 하지 말아줘어.

준이치 : 아 미안미안. 그래서 다이어트 계획같은건 있어?

리호코 : 응. 조사해본 바로는 말야...

.................

준이치 : 음음 과연.

리호코 : 혼자서 하면 아무래도 중간에 포기할 것 같으니까 준이치가 감독해줬으면 해서.

준이치 : 그런가. 그런거라면 엄하게 하지 않으면 안되겠군.

리호코 : I gotcha!

준이치 : 오~, 오랜만에 듣는구만 그거.

'알겠어!' 라는 의미였지 그거.

리호코 : 5학년때쯤에 왠지 모르게 유행했었지~

준이치 : 뭐였지 그 애니.

리호코 : 에또, 분명히 [으랏차차 전사 소로] 였을꺼야.

준이치 : 으랏차차... 으랏차차...

으랏차차라고 하는 부분이 잘 기억이 안나.

리호코 : 으~~~응....

리호코 : ...랄까, 이런거 말하고 있을 때가 아니야!

준이치 : 그렇네. 미안.

좋아. 그렇다면 지금부터

[리호코의 푸둥푸둥 다이어트 대작전] 을 개시한다!

리호코 : 라져~!

준이치 : 좋다! 그럼 먼저...

리호코 : 맨손체조부터 하겠습니다 Sir!

준이치 : 그럼 맨손체조부터 할까.

리호코 : 네에~~

준이치 : (라고는 했지만... 어떻게 해야 할까...)

　　　　(책이든 뭐든 조사해봐야겠군.)

이렇게 해서 리호코의 다이어트를 도와주기로 했다.

아마가미 - 리호코 사이좋음(9)

2010-09-05T22:44:00.000+09:00

준이치 : .....

(크리스마스를 좋아하는 여자애랑 보낸다...)

(그러기 위해서는 나 자신의 매력을 키울 필요가 있을터! )

(생각해보면 저번 주는 별 생각 없이 지냈지만 오늘부터의 나는 다르다!)

(일단 체력을 단련해서 여자애에게 어필할 수 있도록 하자!)

(착실히 노력하는게 중요한 법이지.)

(좋아! 그럼 바로...)

준이치 : (옷을 갈아입고...)

(좋아, 마라톤 시작!)

*선택지

근처를 달린다. <- 선택

멀리 달려본다.

준이치 : (근처를 빙글빙글 돌아볼까.)

준이치 : 헉헉...

준이치 : (헉헉...)

준이치 : (디, 디지겠다...)

리호코 : 아...

리호코 : 흐응...

준이치 : (지, 질것 같으냐~~!)

..... 이렇게 근처를 달려보았다.

좋아! 앞으로도 차근차근 노력해나가자!

리호코 사복 헑헑.

아마가미 - 리호코 사이좋음(8)

2010-09-05T17:48:00.000+09:00

준이치 : (리호코는 차도부에도 교실에도 없고...)

준이치 : (우짤까나...)

리호코 : 준이치, 지금 돌아가는거야?

준이치 : 에?

준이치 : 아아 리호코.

리호코는 안돌아가?

리호코 : 오늘은 수영 보충이 있어서...

준이치 : 그렇군.

리호코 : 요즘은 수영부원한테서 배우고 있어.

준이치 : 수영부...

그거... 어떤 녀석이야? 혹시 성추행이라도 당한다면...

리호코 : 에?

리호코 : 아, 에헤헤. 여자야.

준이치 : 에... 아, 아아. 그렇구나.

(여자 수영부원이라니... 설마...)

혹시 그 수영부원은 몇학년이야?

리호코 : 3학년이야. 눈매가 좀 무서운것 같아도 상냥한 선배야.

준이치 : 아, 설마하니 츠카하라 선배인가.

리호코 : 응, 맞아맞아맞아. ......잘 알고 있네.

준이치 : 이런저런 일이 있어서 조금.

리호코 : 흐~응... 그렇구나...

준이치 : 왜, 왜그래?

리호코 : 에?

준이치 : 에? 가 아니라. 잘 배우고 있어?

리호코 : 아.... 응응. 츠카하라 선배가 잘 가르쳐서 주셔서 말이지. 이 정도면 보충도 확실하다고 생각해.

준이치 : 그런가, 잘되었네.

리호코 : 응, 정말 살았다니깐.

리호코 : 그럼 보충 받고 올께

준이치 : 아아, 힘내.

준이치 : (츠카하라 선배가 가르쳐주고 있었구나.)

(츠카하라 선배라면 어쨋든 안심이지.)

아마가미 - 리호코 사이좋음(7)

2010-09-05T17:25:00.000+09:00

준이치 : ( 오옷! 있다! 분명히 남아있어 스페셜! )

아줌마! 스페셜 남아있죠!?

아줌마 : 그래 있단다. 스페셜 정식이면 되니?

준이치 : ( 좋아! 해냈다! 드디어 먹어보는구나! )

아줌마! 스페셜! 빨리요!

아줌마 : 아하하, 그렇게 안달하지 않아도 된단다. 자, 오래 기다리셨습니다.

준이치 : (우오오오오! 드디어 스페셜을 손에 넣었어!)

준이치 : (굉장하다! 엄청 좋은 냄새! )

(냠냠... 으음 정말 훌륭한 맛이다...)

(이 맛을 대체 어떻게 표현하면 좋단 말인가...)

(그래 예를들면...)

(B정식이 150만큼 맛있다고 하면 스페셜은 50000 정도랄까...)

(그렇다곤 해도, 곁들인 음식만으로도 이렇게 맛있다니... 메인디쉬는 대체 어느정도일까...)

.........

준이치 : (후우... 왠지 세상이 달라보여.)

(맛있는 식사란건... 좋구나...)

리호코 : 왠지 행복해보이는 얼굴을 하고 있네~

준이치 : 역시 눈치챘어? 어쨋든 지금의 나는 만족스러우니까...

리호코 : 만족스럽다니... 아, 설마?

준이치 : 그래! 소원이었던 스페셜을 드디어 먹었다는거지!

리호코 : 오오~~~ 축하해~

준이치 : 핫 핫 핫

리호코가 말했던게 뭔지 잘 알겠더라고. 그건 맛있어, 학교음식의 레벨이 아니라구.

리호코 : 글치이~

준이치 : 접시를 수놓는 곁들임 음식들...

리호코 : 응응

준이치 : 메인디쉬의 존재감이란 그야말로 기품이 넘쳐흘러...

리호코 : 그리고 도저히 잊혀질 수 없는게...

보통 때 나오는 접시보다 훨씬 귀여운 접시!

준이치 : 그 말대로다.

그리고 재료가 듬뿍 들어간 된장국!

리호코 : 에? 된장국?

준이치 : 에?

리호코 : 그리고 또 미니 디저트도 맛있지~

준이치 : 그래 그 말대로... 에? 디저트?

준이치 : ...........???

리호코 : ...........

준이치 : 그건 다른메뉴잖아? 나는 스페셜 이야기를 하고 있는거라구.

리호코 : 스페셜... 인거지? 스페셜 런치. 미니디저트 포함.

준이치 : 런치?

리호코 : 아!

혹시 말인데...

리호코 : 스페셜이 올 가을부터 스페셜 런치랑 스페셜 정식 2개로 나뉘어진거 몰랐던거야?

준이치 : 뭐시라!?　지, 진작 말해줬어야지!

리호코 : 에? 나는 분명히 '런치' 라고 말했었는데...

준이치 : 에? 잠깐 기다려봐...?

(그 때 분명히...)

준이치 : 으음... 리호코는 뭐 먹었어?

리호코 : 나는 무려! 스페셜 런치를 먹었지!

준이치 : 에엣! 스페셜?

(스페셜 런치라니... 나오자마자 매진된다는 인기메뉴인 그 '스페셜' 말인가?!)

아직 스페셜이 남아있진 않겠지...

마, 맛은 어땟냐?!

리호코 : 정~~말로 맛있었어~! 행복이란 이런걸 말하는구나 싶더라니깐!

준이치 : 부, 분명히 그랬던것 같은 기분이 드는군...

리호코 : 그치?

준이치 : 으으... 그렇다곤해도...

헷갈리잖아! 어째서 스페셜이라는게 두 개나 있는거야!

리호코 : 아하하하...

준이치: 그렇다면... 내가 먹은건 가짜라는 이야기...?

(아냐... 잠깐! 진정하고 생각해보자!)

(스페셜 정식이 스페셜 런치에게 패배했다고 정해진게 아냐!)

리호코는 스페셜 런치랑 스페셜 정식 둘 다 먹어본 적 있어?

리호코 : 에헤헤, 있지롱~

준이치 : 저, 저기 리호코. 조금 물어보고 싶은게 있는데...

나는 스페셜 정식이 50000 정도로 맛있다고 생각한다만, 스페셜 런치는 얼마 정도로 맛있는거냐?!

리호코 : 엣또...

항상 먹는 라면은 얼마정도야?

준이치 : 라면은... 130 맛있음 정도일려나?

리호코 : 그렇다면... 30만 맛있음 정도?

준이치 : 그... 그런 바보같은!

뭐, 뭔가 착각한거겠지? 리호코의 혀가 고장났다던지...

리호코 : 고장안났다구~ 너무하네.

리호코 : 므으~~

준이치 : 그치만, 그것말고는 생각할 수 없어! 그정도로 차이가 있을리가...

리호코 : 아이고~ 안타깝네요~....

그렇습니까, [정식] 인 것입니까... 런치가 아니라 [정식] 인 것이군요.

오호호호호호.

준이치 : 너... 너 이녀석... 이렇게 되었다면...

*선택지

울면서 도망간다

리호코를 원망한다

엄청나게 실망한다 <- 선택

(엄청 우울한 음악으로 바뀜)

준이치 : 하아... 안되는구나 나는...

리호코 : 에? 어, 어라?

준이치 : 나는 스페셜 런치도 먹을 수 없는 짚신벌레 같은 놈이야...

리호코 : 그, 그렇지 않다니깐.

　　　　반달말 정도는...

준이치 : 어디가 틀린거야. (* 둘 다 미생물입니다 -_-)

리호코 : 엽록체가 있다던가... 생긴게 멋지다던가...

준이치 : 혹시 위로해주는거야?

리호코 : 우..... 위로로는 들리지 않은거야?

준이치 : 그닥.

리호코 : 으응... 그럼 이거 줄테니깐 힘내!

준이치 : 핑크 초코 프프리코라니

리호코 : 에헤헤헤... 안될...까나?

준이치 : 넌 대체 과자를 몇개씩이나 가지고 다니는거야.

리호코 : 오늘은 4개밖에 갖고 있지 않아~

준이치 : 충분히 많거든!

리호코 : 에헤헤헤헤

준이치 : 왜 거기서 웃는거야

리호코 : 네가 다시 밝아진것 같아서 다행이다 싶어서.

준이치 : 읔...

그렇군. 고마워.

리호코 : 에헤헤, 다행이다.

준이치 : 그럼 답례로 뭔가 마실거라도 사줄께. 뭐 마실래?

리호코 : 으응~ 그럼 난 코코아 마실래.

준이치 : 코코아 좋아하는구나... 그럼 가자.

리호코 : 응. 가자가자.

참고 :

울면서 도망간다를 선택하면 진짜 울면서 도망갑니다. 주인공의 비밀기지로.

리호코를 원망한다를 선택하면 별 일 없이 그냥 무난히 마무리.

아마가미 - 리호코 사이좋음(6) 매칭대화

2010-09-05T03:25:00.000+09:00

- 일상 이야기

리호코 : 저기저기, G맨 이라는 뜻 알고 있어?

준이치 : G맨의 뜻? 그건...

선택지

*알고 있다

*모른다 <- 선택

준이치 : 몰라.

리호코 : goverment man 의 약자로 FBI 수사관을 말하는거라구~

준이치 : 헤에~

리호코 : 그치만 최근에는 그저 단속하는 사람도 G맨이라고 부르나봐.

준이치 : 흐응. 그럼 풍기위원은 풍기G맨이겠네?

리호코 : 오오~~! 역시 아는게 빨라!

준이치 : 고마워. 그건 그렇고 왜 이런 이야기를?

리호코 : 요즘 친구랑 토막상식 겨루기가 유행이야.

준이치 : 토막상식 겨루기...?

리호코 : 응. 이런저런 이름의 유래라던가, 곰을 만났을 때의 대처법이라던가.

준이치 : 과, 과연. 지식량을 겨루는거군.

(그렇지만 어디다 써먹을 수 있을지 모르는 토막상식이구만...)

- 음식 이야기

리호코 : 어제 그리운 과자를 먹었어~

준이치 : 그립다니... 봄에 먹는 떡이라던가?

리호코 : 그런거 말고... 젤리나 한천 비숫한거.

준이치 : 나타데코코 말하는거?

리호코 : 으~응... 왜 그, 할머니가 주는 것 같은 과자.

준이치 : 아아! 그 색깔이 4개인... 에또...

리호코 : 젤리나 한천같은거지?

준이치 : 확실히 그렇게 말할 수 밖에 없군.

리호코 : 옛날부터 신경쓰였던건데, 그건 젤리일까 한천일까?

준이치 : 한천은 아니라고 생각해.

리호코 : 그치~ .... 라는 이야기였습니다!

준이치 : 뭐셔 그건.

리호코 : 아하하.

- 음악 이야기

준이치 : 유명인이랑 만난 적 있어?

리호코 : 한 번도 없어~ 앞으로도 그런 찬스는 없지 않을까나?

준이치 : 아냐아냐, 의외로 만날 수 있을 지도.

(역주 : ...리호코의 배드 엔딩 암시가 이런 곳에서 나올 줄이야...-_-)

- 일상 이야기

준이치 : 리호코는 치과....

리호코 : 싫어싫어싫엇!

준이치 : 역시나.

리호코 : 초등학생때 갔었던 치과가 트라우마가 되어버렸어~

준이치 : 아아, 그 치과... 생긴것 만큼이나 무서웠지.

리호코 : 그렇지~?

리호코 : 삐걱삐걱 소리 나는 마루에, 안에서 의사선생님이

리호코 : '어디가 아픈 걸까나~'

리호코 : 라고 했어!

준이치 : 거기 판자로 된 마루 였으니까...

리호코 : 의자도 오래된 거라서... 엄청 무서웠었어.

준이치 : 그치만 솜씨는 좋잖아? 우리 엄마도 '거기 괜찮아' 라고 말했었어.

리호코 : 그럴지도 모르지만... 그래도 좀 더 밝게 해주지 않으면 무섭단 말야.

준이치 : 그럼 실수로라도 충치가 생기지 않도록 조심하는 수 밖에.

리호코 : 정말이지 콩닥콩닥 무섭다니깐.

- 음식 이야기

준이치 : 배달시켜 먹어본 적 있어?

리호코 : 종종 시켜먹어~ 소면이라던가 라면이라던가 피자라던가... 그리고 카레라던가.

준이치 : 여러가지 시켜먹네.

리호코 : 어머니가 요리하기 귀찮아하시니깐

리호코 : 아, 벌써 이런 시간이네.

준이치 : 아, 정말이네.

리호코 : 너랑 이야기하고 있으면 시간이 빨리 흘러간다니깐.

준이치 : 아하하 그러게.

리호코 : 에헤헤, 그럼 다음에 또 봐~

아마가미 - 리호코 사이좋음(5)

2010-09-05T01:55:00.000+09:00

준이치 : (뭔가 볼 일이 있었던것 같은데 대체 뭐였는기 기억이 안나...)

??? : 우왓!

찰싹!

준이치 : 우앗!

아 정말... 뭐하는거야 리호코.

리호코 : 왜 그렇게 멍~ 하게 있는거야?

준이치 : 분명히 멍~하게 있긴 했지만 말야...

보자마자 춉을 날리는건 여자로서 좀 이상하지 않아?

리호코 : 에헤헤, 항상 너한테 당하기만 했으니까, 복수!

준이치 : 내가 하는 것은 태클이라니깐!

찰싹!

리호코 : 촙이랑 뭐가 다른거야아~!

준이치 : 태클당할 짓도 안했는데 촙을 먹이는 것은 폭력이라고 부른다구.

리호코 : 그렇구나~ 폭력은 좋지 않은거야.

　　　　...가 아니라! 나도 딱히 태클 당할 짓 하지 않았어!

준이치 : 아하하하하핫.

리호코 : 아 정말~

리호코 : 그러고보니깐 말야

준이치 : 응, 뭔데?

리호코 : 햄까스 어땟어?

준이치 : 햄까스? 아아, 그 B정식 말하는거구나.

　　　　'맥 빠지는 정식' 이란 느낌일까...

3개 중에서 2개가 양파였거든...

리호코 : 그랬구나~

준이치 : 하아... 스페셜... 한 번이라도 좋으니까 스페셜 먹어보고 싶다...

리호코 : 맛있다구~ 뺨이 녹아버리는 느낌이야! 궁극의 메뉴라구!

준이치 : 과연... 전혀 모르겠다.

준이치 : TV의 'おいしん坊将軍' 처럼 좀 더 풍부한 어휘를 사용해서 전달해주지 않으면...

* おいしん坊将軍 : 일본 방송 프로그램에 나오는 인물인듯...

리호코 : 므으...

준이치 : 전신을 사용해서 흘러넘칠 만큼의 맛있음을 표현하는거 말이지, 리호코라면 가능하잖아?

리호코 : 에에~~ 그런거 몰라. 하다못해 시범이라도 보여주지 않으면 할 수 없어~

준이치 : 시범이라고? 할 수 없구만...

그럼 내가 몸을 사용해서 표현해 보여줄테니 거기서 잘 보라구.

리호코 : 정말!?

...그런데 몸으로 표현?

준이치 : 잘봐둬... 읏차...

리호코 : .........어디가 스페셜?

준이치 : 아직, 아직이다. 지금부터라구.

리호코 : 오, 오오오~

준이치 : 다시 한 번... 왼쪽 발을 오른손으로 꽉 잡아 고정시킨 다음... 그야말로... 스페에...셔어어얼!

리호코 : 오오~~ 굉장하다! 확실히 스페셜하게 맛있다는건 그럼 느낌일지도!

준이치 : 헉, 헉... 그렇지?

역시 사람의 마음을 흔들기 위해서는 이 정도는 하지 않으면 안되지.

으랏...차...

후우...

그렇지만, 내가 가면 언제나 매진되어 있을것 같아.

리호코 : 평소의 행실이 결과를 가져오는 법이지요.

준이치 : 그렇다면 리호코보다 나에게 찬스가 와야 되는거 아냐?

리호코 : 그건... 그렇네.

준이치 : 아니, 거기서는 태클을 걸어야지.

리호코 : 아, 지금 타이밍에 태클을 걸어야 하는거구나~

리호코 : 으~응... 나도 아직 멀었어.

준이치 : 수행이 부족하구만.

리호코 : 에헤헤헤헤헤

카나에 : 아, 사쿠라이 찾아다녔어.

리호코 : 아, 카나에. 무슨 일이야?

카나에 : 차도부의 선배가 우리반까지 와서 널 찾아 다녔어.

리호코 : 무슨 일일까... 응, 고마워.

카나에 : 아, 마침 잘 되었다. 타치바나.

준이치 : 에?

카나에 : 우메하라가 널 찾고 있더라.

준이치 : 우메하라가? 뭐지...

카나에 : 뭔가 수학이 어쨋더라... 였던가?

준이치 : 아! 오늘 프린트 회수 당번이 나였어!

고마워 카나에.

카나에 : 빨리 가보는게 좋을거라고 생각해.

준이치 : 그럴꺼 같애. 가르쳐줘서 고마워.

카나에 : 괜찮아

리호코 : 엣또

준이치 : 그런 이유로 난 이만 갈께.

리호코 : 응. 나도 선배가 있는 곳으로 갈꺼니까.

준이치 : 아아, 또 보자.

리호코 : 또 봐~

준이치 : (그러고보니 리호코는 차도부였지...)

(어떤 모습을 하고 있을지 상상도 안가는구만...)

아마가미 - 리호코 사이좋음(4)

2010-09-04T01:08:00.000+09:00

준이치 : (후우... 배고파 죽겠네...)

(오늘은 뭘 먹을까. 평범하게 라면? 아냐 B정식도...)

??? : 준이치~ 지금부터 점심 먹는거야?

준이치 : (이 목소리는...)

준이치 : 리호코냐. 선생님한테 부탁 받아서 자료실에 잠깐 갔었거든.

리호코 : '어이~, 이거 자료실에 반납해라~'

리호코 : ...였겠지?

준이치 : 안비슷해... 　시키시마 선생님의 흉내냐?

리호코 : 에에~, 그래도 시키시마 선생님이라고 알 수 있었으니까 비슷한거 아냐?

준이치 : 그런 말버릇 쓰는 사람은 시키시마 선생님밖에 없으니깐.

리호코 : 므으...(む～～～～～～）

아, 그것보다 뭐 먹을건데?

준이치 : 으음... 리호코는 뭐 먹었어?

리호코 : 나는 무려! 스페셜 런치를 먹었지!

준이치 : 에엣! 스페셜?

(스페셜 런치라니... 나오자마자 매진된다는 인기메뉴인 그 '스페셜' 말인가?!)

아직 스페셜이 남아있진 않겠지...

마, 맛은 어땟냐?!

리호코 : 정~~말로 맛있었어~! 행복이란 이런걸 말하는구나 싶더라니깐!

준이치 : 그정도인거냐... 부럽다...

리호코 : 에? 준이치 혹시...

준이치 : 그래. 실은 나 아직껏 스페셜을 먹어본 적이 없어...

리호코 : 앗 하는 사이에 전부 팔려버리니깐~

준이치 : 그래! 그럼 스페셜을 목표로 해서 다녀오마!

리호코 : 다녀와~

.................

리호코 : 어떻게 되었어?

준이치 : 보는 대로지.

리호코 : B정식...

준이치 : 스페셜은 매진이었어...

리호코 : 맥 빠지네~

준이치 : 아아, 맥 빠져.

리호코 : 그치만 B정식도 맛있다구?

나 햄까스 좋아하거든~

준이치 : 리호코는 점심 막 먹었지?

안준다?

리호코 : 안먹어~

준이치 : 그래그래 착하지. 착한 아이에게는 상으로 이 채소절임을 주마.

리호코 : 아하하, 고마워. 그럼 이거, 답례.

준이치 : 초콜렛이네. 쌩큐.

리호코 : 별 말씀을요~

준이치 : 그건 그렇고...

리호코 : 왜에?

준이치 : 리호코는 항상 과자를 가지고 다니는구나.

리호코 : 그런가?

준이치 : 그러니까 신체가 포동포동하게 되버리지.

리호코 : 포동포동이라니... 뭐라는거야 이녀석아~!

준이치 : 이 이상 리호코가 살쪄버리면 좋지 않으니까 이 초콜렛은 받아두지.

리호코 : 그건 고맙네요. 가 아니라 살찌지 않았어!

따라해보세요!

준이치 : 아하하, 미안미안. 살찌지 않았어, 안쪗다구.

리호코 : 좋아요!

리호코 : 아하하... 그것보다 빨리 먹지 않으면 식어버려.

준이치 : 아, 이런.

리호코 : 에헤헤, 그럼 나중에 봐.

준이치 : 아아, 잘 가.

(자, 그럼 밥먹자 밥.)

준이치 : (...........)

(..... 햄까스 3개인줄 알았더니, 2개는 양파잖아 이거...)

(오늘 B 정식은 꽝이었다...)

아마가미 - 리호코 사이좋음(3) 매칭대화

2010-09-04T00:10:00.000+09:00

준이치 : 아, 리호코.

리호코 : 응? 왜에?

준이치 : 시간 있으면 이야기라도, 라고 생각했지.

리호코 : 좋아~ 그럼 이야기 하자.

- 일상 대화

준이치 : 연하장의 준비는 이미 하고 있는거야?

리호코 : 일단 감자도장은 만들어 놓았어.

*일본에서는 연하장을 보낼 때 감자를 깎아서 도장을 만드는 풍습이 있습니다.

http://www.kisnet.or.jp/garuru/camp/039rep_02.html

준이치 : 리호코의 감자도장은 상당히 기대가 되는데.

리호코 : 에헤헤, 필생의 역작을 만들고 있습죠.

- 공부 이야기

준이치 : 공부라고는 해도, 말장난(語呂合(わ)せ)은 재미있지.

리호코 : 아, 응. 그건 조금 좋아할지도.

나아~ 맛가~루 시프스 크라크 였었나?

* 주기율표 외우는 말장난.

준이치 : 주기율 말장난이군.

리호코 : '마가루' 랑 '크라크' 씨는 그렇다고 쳐도...... '시푸스' 는 대체 왜 있는거야~! 캬오~!

준이치 : 지, 진정해 리호코.

그래도 그정도로 임팩트가 있으니깐 잘 잊어버리지 않게 되잖아?

리호코 : 응... 그치만...

리호코 : ...주기율표 말장난에서 원래 원소 기호로 기억을 해내지 못하니깐

시험에는 전혀 도움이 되질 않는다구.......

준이치 : 아아... 그거 애통하군...

-음식 이야기

준이치 : 리호코는 매실 장아찌 잘 먹어?

리호코 : 할머니가 시골에서 보내주는 매실 장아찌는 좋아해~

준이치 : 헤에~ 가게같은데서 파는 거랑은 달라?

리호코 : 응. 가게에서 파는 매실장아찌와는 다르게 무지하게 시큼해.

준이치 : 으... 상상하는 것만으로도 침이 고인다.

리호코 : 아하하.

- 변태 이야기

준이치 : 여자 애들끼리 옷 갈아 입을 때엔 감추거나 해?

리호코 : 사람에 따라서... 일까나.

준이치 : 참고로 리호코는 어떤데?

리호코 : 체육 시간에는 그렇지만, 수영 시간에는... 이 아니고 그런 질문 하지마!

준이치 : 미, 미안.

리코호 : 정말... 어쩔 수 없다니깐...

- 음악 이야기

준이치 : 집에서 음악을 들을 때는 언제야?

리호코 : 듣고싶은 라디오 프로가 방송되지 않을 때랑, 책을 읽을 때.

라디오를 들으면서 음악을 들으면 이도저도 안되니깐~

매칭 대화 끝

리호코 : 아, 벌써 이런 시간이네.

준이치 : 어, 정말.

리호코 : 너랑 이야기 하고 있으면 시간이 빨리간다니깐~

준이치 : 아하하, 그러게.

리호코 : 에헤헤헤. 그럼 다음에 봐~

아마가미 - 리호코 사이좋음(2)

2010-09-03T01:20:00.000+09:00

준이치 : 여, 리호코.

리호코 : 하오~~~

준이치 : 그 인사는 아직도 유행이냐?

리호코 : 으으응, 벌써 한 물 갔어.

준이치 : 유행이란 빨리 바뀌는구만.

리호코 : 마아, 그런거지요.

카나에 : 그런거지.

리호코 : 아, 카나에.

카나에 : 저기, 너네는 언제나 같이있는거 아냐?

준이치 : 그런가?

리호코 : 그런거 아니야~

카나에 : 그래?

준이치 : 옛날과 비교하면, 말이지만.

카나에 : 헤에~ 자세히 듣고싶은걸.

준이치 : 예전에는... 초딩때는 그야말로 매일 같이 있었던거 같군.

리호코 : 그랬지~

준이치 : 근처의 과자가게에 갈 때는 항상 리호... 사쿠라이가 따라왔었으니깐.

카나에 : 헤에~

리호코 : 그치만~, 옛날에는 반대였었어.

카나에 : 반대라니?

리호코 : 준이치가 항상 내 뒤를 졸졸 따라다녔었지이.

카나에 : 오호~

준이치 : 잉? 무슨 말을 하는거야.

리호코 : 진짜라니까안~ 초등학교... 2학년 정도까지.

준이치 : 그런 일이 있었던가...

리호코 : 있었다구~

카나에 : 어떤 남자아이였어?

리호코 : 무슨 일이 있으면 말이지

'리호짱 리호짱, 어떡하지?'

........라면서 물었었거든~

준이치 : (.......기억이 날듯 말듯한...)

카나에 : 헤에~....

근데 어째서 이~런 사쿠라이로 되어버린거지?

리호코 : 이~런 이라니...

준이치 : 으음... 정신이 들고보니 이렇게 되었어.

리호코 : 정신이 들고보니... 라니...

카나에 : 그렇군 그렇구나. 너도 고생이 많았네~

준이치 : 이야~ 알아줘서 기쁘다.

리호코 : 으그~~~~~~(む～～～～～～～)

카나에 : 미안미안.

그래서 지금은 이런 느낌인거네.

준이치 : 그래그래.

카나에 : 그런가, 앞으로도 사쿠라이를 돌봐주지 않으면 안되겠네.

준이치 : 그래 맞아. 에휴 할 수 없지... 라니깐.

리호코 : 아......

준이치 : 왜 그래? 사쿠라이.

리호코 : 에엣? 으으응, 아무것도 아니야~

카나에 : 아무것도 아닌거네~?

리호코 : 그치~

카나에 : 그치~

준이치 : (여자애들끼리의 대화는 종종 따라갈 수가 없어...)

카나에 : 자자, 다음 수업은 교실 이동이야 사쿠라이.

리호코 : 얼레, 그랬나?

준이치 : 으이그, 제대로 좀 해.

카나에 : 아하하, 그럼 나중에 또 보자.

리호코 : 또 봐~

준이치 : 응. 그럼 나중에.

준이치 : 후우...

(글쿠만, 어릴 때는 그랬었지...)

(언제부터 지금처럼 된걸까...)

종소리

준이치 : (...앗차, 이런걸 생각하고 있을 떄가 아니지. 수업 시작하겠다.)

아마가미 - 리호코 사이좋음(1)

2010-09-01T02:24:00.000+09:00

아는 사이 - 사이 좋음으로 갈 예정.

시발 생각보다 존나 빡심...

우메하라 : 여 대장. 오늘은 뭐 먹을꺼야?

준이치 : 그러게... 역시 라면이나 먹을래.

우메하라 : 역시 그렇구만. 밥 먹은 뒤에 혹시 다른 일 있냐?

준이치 : 아니 딱히 없는데.

우메하라 : 그거 다행이군. 그럼 나중에 테라스로 와라.

준이치 : 상관없긴 하지만, 밥 먹으면서 하기엔 좀 그런 이야기냐?

우메하라 : 지금 식당 붐비잖아?

준이치 : 아, 그렇군. 그럼 나중에.

우메하라 : 오우, 부탁한다.

준이치 : (오늘 라면은 상당히 희한했지.)

(...설마하니 차슈의 재고가 다 떨어질 줄이야...)

(그렇지만, 대신 들어간 토핑이 새우튀김이라니... 보통은 있을 수 없지 않나.)

(확실히 다 먹긴 했지만 말야...)

* 챠슈 : 일본 라면 위에 올리는 돼지고기.

우메하라 : 오우, 귀찮게 해서 미안하군.

준이치 : 그래서 무슨 일이야?

우메하라 : 좀 상담하고 싶은 일이 있다.

준이치 : 괜찮다만... 혹시 연애 상담이라면 상담해줄 만큼의 경험이 없다고?

우메하라 : 그건 알고있지.

준이치 : 어이어이... 그렇게 딱 잘라서 말하지 말아줘.

우메하라 : 하하하, 뭐 농담은 이정도로 해두고.

이번에 우리 가게에서 디저트를 내놓거든.

어떤게 좋을거 같냐?

준이치 : 과연. 디저트인가.

그건 확실히... 랄까, 우메하라네 집은 분명히 초밥집이었지.

우메하라 : 그래서 곤란하다고. 아버지가 '네게 맡기마' 라고 말해버려서.

준이치 : 헤에~ 대단한데.

우메하라 : 그저 아버지 자신이 귀찮으니까 나한테 미룬것 뿐이야.

그래서 뭔가 없을까?

준이치 : 디저트인가.... 으음...

아, 그건 어때. 한때 유행했던 투명하면서 탱탱한거.

우메하라 : 젤리 말하는거? 과연...

준이치 : 아니 젤리 말고. 엥? 몰라?

우메하라 : 젤리 말고? 그럼 한천인가?

* 한천

준이치 : 아니야! 왜 그 오징어회같은...

우메하라 : 오, 오징어!? 으으음...

리호코 : 무슨 일이야? 둘 다 어렵다는 얼굴을 해가지곤...

준이치 : 아아, 리호코냐. 마침 좋을 때에 왔네.

리호코 : 응? 뭔데?

준이치 : 우메하라에게 설명해줬는데 말야...

왜 그 오징어회같은...

리호코 : 나타데코코?

*나타데코코 : 후르츠 통조림 안에 있는 코코아같은걸 말합니다. 흰거...

준이치 : 그래 그거! 역시 리호코!

우메하라 : 어, 어째서 그 말만으로도 알 수 있는거지?

디저트라는 말도 안했는데...

리호코 : 뭐 그거야, 오랫동안 알고 지냈으니깐~

우메하라 : 하아... 굉장하구만.

나는 '오징어회' 라고 들으면 오징어밖에 떠오르지 않아.

리호코 : 초밥집을 하고 있으니깐 그런가봐.

우메하라 : 아니 잠깐있어봐... 또 하나 오징어회랑 비슷한게 떠올랐어.

준이치 : 뭔데?

우메하라 : 개복치회.

리호코 : 개복치?

개복치라면 저 바다 안에서 멍~~~~~~ 하니 있는 그거?

우메하라 : 아아.

준이치 : 랄까, 개복치를 먹을 수 있다는게 놀랍다 야...

우메하라 : 신선한 개복치는 레알 맛있어.

안타깝게도 우리 가게에서는 취급안하지만.

리호코 : 후헤에~~~~.....

개복치인가아아....

준이치 : .........리호코.

리호코 : 우아?

준이치 : 침.

리호코 : 후에엣?!

리호코 : 에헤헤헤헤....

준이치 : 참나 으이그...

카나에 : 하오하오~ 사쿠라이~

리호코 : 아, 카나에짱. 하~오~~~

준이치 : ............

우메하라 : ............

준이치 : 머여 그 인사는.

카나에 : 에? 지금 우리반에서 유행하고 있는거야.

우메하라군 하오~

우메하라 : 하, 하오~

리호코 : 에헤헤헤, 준이치, 하오~~~~~~

준이치 : ........하오~

카나에 : 뭐하고 있었던 거야?

준이치 : 실은 우메하라가...

...............

우메하라 : ...라는거지.

카나에 : 흐응... 역시 소꿉친구라는건 척 하면 알아듣는 사이인거네.

우메하라 : 정말 그런가벼.

준이치 : 뭐, 오래 알고 지냈으니깐.

카나에 : 나라고 해도 가~끔은 사쿠라이가 뭘 말하는지 이해를 못하곤 하는데.

준이치 : 아니, 리호코.... 가 아니라 사쿠라이가 말하는 건 나라도 가~끔은 알아듣기가 힘들지.

카나에 : 아, 역시 그렇구나. 사쿠라이의 사고회로는 특별하니깐.

리호코 : 아 뭐야아~ 둘 다.

우메하라 : 미엔 사쿠라이. 이건 나도 커버 쳐줄 수가 없어.

리호코 : 에에~~~

카나에 : 라고는 말하지만, 나보다는 그래도 타치바나군이 사쿠라이를 더 잘 알고 있지 않겠어?

잉꼬부부라고 해야하나...

준이치 : 에?

우메하라 : 어느쪽이냐고 하면, 부부만담 콤비라는 느낌이지.

리호코 : 머라카노~!

준이치 : 어이어이... 그래선 진짜로 만담이잖아..

카나에 : 아하하하하핫, 정말이네.

둘이서 콤비 짜보면?

의외로 먹힐지도~

리호코 : 그래? 그러면 태클거는 연습을 하지 않으면 안되겠네~

준이치 : 아니, 사쿠라이에게 연습은 필요 없을것 같은데.

리호코 : 에? 나의 태클은 이미 프로급?

준이치 : 사쿠라이는 보케 쪽이니깐.

*보케 : 만담 콤비에서 바보짓으로 태클 당하는 역할.

리호코 : 에에에에~~~

우메하라 : 그럼 다음 코너도 부디 즐겁게...(*おあとがよろしいようで)

카나에 : ...멋진 태클이다.

*おあとがよろしいようで :

1인 만담에서 쓰이는 표현으로 굳이 번역하자면 '다음 코너를 즐겁게 즐겨주세요' 정도가 됩니다.

우메하라는 준이치와 리호코의 만담을 받아 넘긴 개그를 한 셈.

특이한 코드를 가진 캐릭터들

2010-08-24T23:17:00.000+09:00

- 허세모에

- 변태신사

- 로리변태할멈

- 봇간모에

- THE 부처

- 장애모에

- 병신간지

- 사신간지

급속도로 호전 중

2010-08-13T10:04:00.000+09:00

약 먹기 시작한지 이제 한 달이 다 되어 가는데...

그저께부터 갑자기 상태가 급속도로 좋아지기 시작했다.

그건 좋은데

그에 대한 반작용인지

24시간 내내 졸음이 쏟아져 참기가 힘들엉... -_-...

어쨋든 낫고 있는 것 같아서 천만 다행이다.

고통스럽다...

2010-07-25T16:28:00.000+09:00

Sean횽의 말을 듣고 양재역 운화한의원에 찾아가서 진단받고

약 먹은지 5일째...

레알 고통스럽다. 아토피가 이렇게까지 심해질 줄이야.

이 얼굴 꼬라지랑 말로 설명하기 힘든 고통...OTL.

얼굴에 통증이 크게 심하다거나 한 건 아닌데 이 말로 설명할 수 없는 감각을 뭐라해야 할 지 모르겠다.

정말 집에서 한 발자국도 나가기가 싫다.

이 얼굴로 내일 어떻게 출근하지...?

정말 약먹고 의사 말대로 레알 아토피가 심해지니 믿음이 가긴 가는데...

길면 4-5개월까지 더 심해질 수도 있다는데...

그 기간동안 참아낼 수 있을지 의문이다. 무섭다.

SQL SERVER 계정의 암호가 만료되었습니다

2010-07-08T19:54:00.000+09:00

오늘 잘 돌아가는 서버가 갑자기 접근이 안된다고 에러를 내뱉어내길래

순간 존나 시껍했었다.

원인은 SQL SERVER 에서 계정을 강제 만료 시키기 때문이다.

관리자로 접속한 다음, 계정 관리하는데 가서 강제 만료 시키는 옵션의 체크를 해제하면 된다.

나 자신의 작명 센스에 대해 반성해본다.

2010-07-06T21:15:00.000+09:00

누구든 변수명이라던지 파일이름을 처음 지을 때 많은 고민을 하게 된다.

고민의 종류는 다 똑같다. 어떻게 하면 알아보기 쉽게 만들 수 있을까?

그리곤 이후 추가될 변수, 파일들을 위하여 자신만의 규칙을 정한다.

(물논, 회사나 프로젝트에 따라 이 규칙이 첨부터 정해져있는 경우도 있으나 주관은 반드시 들어가게 마련)

그래서 탄생한 첫 변수, 첫 파일의 이름은 보통 아주 훌륭하다. 두세번째까지도 일반적으로

훌륭한 작명이 나온다.

문제는 그 이후다.

자꾸 변수와 파일을 추가하다보면 앞서 정했던 규칙에 도저히 맞출래야 맞출 수 없는 상황이 발생하게 된다.

더욱 큰 문제는 규칙에 적용할 수 있는 상황보다 도저히 규칙에 맞출 수 없는 상황이 훨씬 더 많다는 것이고.

결국 이러다보면 규칙이라는 통일성이 우선시되고 '누구나 알기 쉬운 이름'을 짓는건 뒷전이 된다.

개발자 자신도 이러한 괴리에 대해 아주 찝찝해하고 잘못되었다는걸 알고 있지만 중간에 고치기는 쉽지않는 노릇이다.

지금 내가 그렇다. -_-

그래서 난 최근에 작명의 제일 앞에붙는 대전제 하나만 통일시키고(예를들면 웹서버용이면 이름 제일 앞에 web이 붙고

일반서버용이면 svr이 붙는다던지) 그 이후는 그냥 '알기 쉽게'라는 목표로 이름을 지을려고 노력중이다.

근데 이게 옳은건지 모르겄다.

실장님 왈 : 작명이 반 이상이다.

pdb 파일

2010-06-01T21:25:00.000+09:00

VS 로 컴파일하면 pdb 파일이 생성되는데,

Program Database 라는 파일이다.

프로그램 디버깅 정보가 담겨있으며, 뭔가 사고가 터졌을 때 pdb 파일이 존재한다면

어느 라인에서 문제가 터졌는지까지 알 수 있다.

exe 파일과 pdb 파일은 세트이며, 이 두 개가 있으면

소스코드 통째로 건네는 것이나 다름없다고 하니 주의할 것.

게임 세션의 보안

2010-05-11T18:32:00.000+09:00

클라이언트가 과연 레알 클라이언트인지 식별할 수 있어야 한다.

안전한 클라이언트 식별 방법으로는

- IP주소로 인증

- 인증 토큰 사용

- 암호화 이용

IP 주소 인증

- 패킷의 원본 IP주소와 포트번호와 테이블에 저장해둔 클라이언트의 IP, 포트번호를 체크하여 인증

- 전송 도중 패킷이 조작되지 않아야 안전함.

- TCP를 사용하거나 서버들 사이에서 연결을 주고 받는 경우에는 포트가 항상 같다고 보장할 수 없음.

TCP는 연결된 컴퓨터마다, 각 연결마다 새 포트를 할당하기 때문.

인증 토큰 식별

- 플레이어가 로그인 시 해당 로그인 세션의 만료시간을 결정

- 클라이언트 ID, 만료시간, 서버만이 아는 Key를 사용하여 하나의 해시를 계산하고 그 해시와

클라이언트 ID, 만료시간, Key 를 하나로 묶은 인증 토큰을 클라이언트로 발급.

- 클라이언트는 서버에게 자료를 보낼 때 패킷에 인증 토큰을 포함시킴. 서버가 발급한 해시와 동일하면

인증 성공.

- 세션의 만료시간이 지나면 시간을 연장하여 해시를 갱신한 다음 새 토큰을 클라이언트에게 발급.

암호화 사용

- 서버와 클라이언트가 공통의 비밀을 공유하면 그것을 하나의 키로 사용할 수 있다.

예를들면 평문 패스워드. 물론 별도의 키와 합쳐 해시로 이용하는게 좀 더 안전.

- 클라이언트는 서버에게 암호화되지 않은 클라이언트 ID, 패킷 자료를 공통의 비밀로 암호화한 것,

그리고 암호화되지 않은 자료의 체크섬으로 이루어진 패킷을 보낸다.

- 서버는 공통의 비밀을 이용하여 해독하고 체크섬을 확인.

- 암호화할 자료는 반드시 일련번호를 포함. 그래야 동일 패킷이 연달아 전송되어도 각자 다르게 암호화가

되며, 따라서 패킷을 가로채서 복사본을 여러 개 보내는 식의 공격을 좀 더 잘 견딜 수 있다.

from GPG 7권

게임 로그인의 보안

2010-05-11T18:19:00.000+09:00

게임 로그인을 안전하게 만들려면 다음과 같은 문제점들을 조심해야 한다.

- 안전치 않은 패스워드

- 안전치 않은 패스워드 저장

- 패스워드 스니핑

- 키보드 스니핑

- 부주의한 사용자

- 다중 로그인

패스워드를 DB에서 어떻게 저장, 복구할 것인가

- 복구 가능한 패스워드

- 단방향 해시 패스워드

- 공개키 기반구조

from GPG 7권

게이트웨이 주소 얻기

2010-04-29T14:53:00.000+09:00

자바에서는 게이트웨이의 주소를 얻을 수 있는 방법이 존재하지 않는다.

따라서 다음과 같은 트릭으로 게이트웨이 주소를 얻는다.

private String getRouterIP()

{

String _255 = "(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)";

String exIP = "(?:" + _255 + "\\.){3}" + _255;

// Regexp to find the good line

java.util.regex.Pattern pat = java.util.regex.Pattern.compile("^\\s*(?:0\\.0\\.0\\.0\\s*){1,2}("+exIP+").*");

Process proc;

try {

// netstat

proc = Runtime.getRuntime().exec("netstat -rn");

java.io.InputStream inputstream =

proc.getInputStream();

java.io.InputStreamReader inputstreamreader =

new java.io.InputStreamReader(inputstream);

java.io.BufferedReader bufferedreader =

new java.io.BufferedReader(inputstreamreader);

// Parsing the result

String line;

while ((line = bufferedreader.readLine()) != null) {

java.util.regex.Matcher m = pat.matcher(line);

// This is the good line

if(m.matches()){

// return the first group

return m.group(1);

}

// can't find netstat

} catch (java.io.IOException ex) {

//java.util.logging.Logger.getLogger(NetworkManager.class.getName()).log(Level.SEVERE, null, ex);

System.out.println(ex.getMessage());

}

return null;

}

자바로 간단하게 MD5 해쉬 얻기

2010-04-26T21:17:00.000+09:00

import java.security.MessageDigest;

import java.security.NoSuchAlgorithmException;

...

private MessageDigest md;

...

try

{

this.md = MessageDigest.getInstance("MD5");

}

catch (NoSuchAlgorithmException e)

{

System.out.println(e.getMessage());

}

...

public String getHash(String s)

{

byte[] data = s.getBytes();

this.md.update(data);

return toHexString(this.md.digest());

}

private String toHexString(byte[] byteData)

{

StringBuffer sb = new StringBuffer();

for (int i = 0; i < byteData.length; ++i)

{

String hex = Integer.toHexString(byteData[i] & 0xFF);

if (hex.length() == 1) {

hex = "0" + hex;

}

sb.append(hex);

}

return sb.toString();

}

끗.

서울 생활 3일째, 마음이 아프다

2010-04-21T22:17:00.000+09:00

서울에 온지 이제 3일째가 되었다.

첫날에 경서랑 통화하고 어제는 통화를 하지 못했다.

그리고 조금 전에 경서랑 통화했는데...

그 씩씩하던 애가 보고싶다고 전화기 붙잡고 말 못잇고 우는데...

너무 고맙기도 하고 안타깝기도 하지만 마음이 아프다.

내가 동생 하나는 잘둔듯. 우왕ㅋ굳ㅋ

드디어 서울을 갑니다.

2010-04-13T14:01:00.000+09:00

꿈에도 그리던 게임업계로 이제 갑니다. ( ^o^)/

화이팅! 힘내자!

아싸!!

오쿠이 마사미 한국 콘서트!!!!!!!!!!!!!

2010-04-06T01:09:00.000+09:00

으아아아악 진짜 한다!!!!

내가 무지무지무지무지무지*100 좋아하는 오쿠이 마사미!

설마 한국에서 단독공연 할 일은 없을꺼라고 생각했는데!!!!

이번에 한다능!!!!!

으아아악 우왕ㅋ굳ㅋ

내 주위에 마사미 팬이 없어서 같이 갈 인간이 없는게 너무나 아쉽지만

까짓거 혼자 가주겠엉!

마사미 만세!!!

홈페이지 : http://blackseal.co.kr/okui2010

예외 처리는 언제하여야 하는가?

2010-03-26T12:30:00.000+09:00

예외는 의외의 상황을 위해 남겨두어야 한다. 잡히지 않은 예외는 프로그램을 종료시킬 것이라

가정하고, '모든 예외 처리기를 제거해도 이 코드가 여전히 실행될까.' 하고 자문해 보자.

만약 그 답이 '아니오.' 라면 아마도 예외가 비예외적인 상황에서 사용되고 있는 것이다.

예외는 예외적인 문제에 사용하라.

실용주의 프로그래머를 읽다가 인상적이길래 블로그에 기록...

바보와 시험과 소환수

2010-03-19T18:52:00.000+09:00

웹서핑 도중에 우연히 발견하고 그림체가 맘에 들길래 보기 시작한 바보와 시험과 소환수.

근데 기대 이상으로 아주 재미있다. 내용은 그냥 판타지 학원 코믹물.

제작비도 아끼고 제작시간도 줄이고 웃기기까지 한 일석삼조의 연출

이 애니에서 가장 볼만한 것이라면 역시 위의 두 바보콤비의 바보 개그. 정말 오랜만에 제대로 된 개그로 승부하는 애니가 나왔다.

츠...츤데레!

그 다음 볼만한 것이라면 역시 미나미의 츤데레 액션! 상당히 정석적인 츤데레 캐릭터다.

최근 애니들의 츤데레 경향이 '츤' 만 강조되고 '데레' 의 액션이 약해지고 있는데, 그 아쉬움을 한 방에 날려주는 미나미!

미나미의 데레 액션은 아주 GOOD! 물론 츤 액션도 GOOD! 최근에 등장한 츤데레 캐릭중에서는 최고!

위에 적은 것들뿐만 아니라, 백합 + 게이 + 여장남자 + 변태 등등 나를 비롯한 많은 사람들이 부담스러워 하는 속성들도 바보 라는 공통적인 속성에 묶어서 아주 코믹하게 그려내고 있다.

이번 분기 작품 중에서는 최고의 수작이라고 생각된다.

저번 분기의 하늘의 유실물도 그렇고 이번 분기의 바시소도 그렇고, 크게 기대하지 않았던 작품들이 계속해서 개념작으로 등장하고 있는듯.

어쌔신 크리드2 질렀다

2010-03-02T18:19:00.000+09:00

예전부터 해보고 싶던거였는데...

어제 홈플러스에서 질렀음. 52000원... 비싸 OTL

근데 재밌더라 확실히.

괜히 대작이 아니야...

FM2010 역사적인 대역전극. 만세!

2010-02-28T02:08:00.000+09:00

조금전에 내 FM 인생 사상 최고의 역전극이 나왔다. 아직도 흥분이 가라앉지가 않는다. 우왕ㅋ굳ㅋ
까먹기전에 얼른 기록해놔야짘ㅋ.

게임 결과부터.

3-4 승리

3-4 로 역전승. 그러나 단순한 역전승이 아니었다.

3-0 에서 3-4으로 역전

그것도 전반에 세골 연속으로 먹어 3-0 이 된 상황에서 4골을 몰아쳐서 3-4 으로 역전! 워 내가 진짜
이럼 게임을 만들어내다니.

둘 다 4-4-2 플랫

컴터나 나나 가장 흔하게 이용되고 있는 4-4-2 플랫 전술을 들고 나왔다. 컴터의 노리치는 어떤지 모르겠으나 나는 베스트 멤버를 가동시켰다.

평소 전술 그대로

사실 노리치에 비해 전력이 조금 약세에 있어서 4-5-1을 들고 나갈까 고민했었지만 최근 4연승을 달리는 등 팀의 기세가 매우 좋았으므로 기존의 전술을 밀고 나가기로 했다. 사실 초반에 수비에 치중하기 위해서 수비형LB인 Bloom를 기용하고 싶었지만, 체력상태가 회복되지 않았으므로 공격형LB 인 Ateba 를 그대로 기용. 위 사진은 경기 후에 캡쳐한거라 체력상태가 모두 좋지 않다.

상대팀 전력 보고서에, 상대팀이 주로 득점을 하는 시간은 전반 중반이고 주로 실점을 하는 시간은 후반의 중후반이었다. 후반에 실점이 잦은 팀이라면 그 팀의 체력상태가 좋지 않다는 것을 의미하기에, 난 전반은 천천히 수비하며 체력을 비축한 뒤, 후반에 맹공하는 작전을 선택하였다.

결국 나의 판단은 처음엔 완벽한 미스였다. 경기시작 30분만에 3골 처먹고 GG쳐야할 상황가지 몰렸다.

첫번째 골 먹히는 장면

상대팀의 Gimenez가 Hawley에게 좋은 패스를 연결. 우리팀의 RB인 Brayford 가 Hawley를 프리하게 냅둔것이 원인이다. 물론 여기에는 Bratford 바로 밑에 있는 Godsmark의 어정쩡한 위치선정도 한몫했다.
시발 뭐가 Godsmark 야 -_-

Davies 의 중거리슛.

첫번째골 먹고 얼마 지나지 않아 Davies의 중거리슛으로 또 먹혔다. 상황은 Davies가 자기팀 공격수와 2:1 패스를 통하여 상황을 만들었는데, 우리팀 MF인 Murphy가 Davies의 첫번째 패스 이후 공을 쫓다가 Davies를 놓쳐버렸다.

Gimenez에게 어이없게 먹힌 골 -_-

그리고 또 다시 얼마 안되서 세번째 골. 자막을 보면 알겠지만 Hawley가 헤딩슛 한게 골문으로 향하지 않고 엉뚱하게 Gimenez에게 향해버렸다. 근데 씨발 Gimenez를 마크해야할 Brayford는 또 멍때리고 있다 -_-.
그래서 한 골 또 그냥 헌납. 물론 같이 멍때리고 있던 Camara도 실점에 한 몫했다.

세 골 먹힌 뒤의 나의 심리상태

Brayford 의 최대 약점은 한 번 실수로 무너지기 시작하면 겉잡을 수 없이 무너진다는 점인데, 이번 게임에서도 여실히 드러나고 있다. 압박감 대처능력이 꽝...
그러나 어쩌겠는가. 이번 게임에선 대안이 없다. 교체 가능한 RB를 서브 명단에 올려두지 않았으니...

이번 시즌 리그1로 승격되면서 수비진을 보강하지 못한 결과가 이 게임에서 나타나고 있었다. 전반적으로 공격적인 영입을 성공시킨 공격진 덕에 시즌 내내 득점은 원할하게 이루어졌으나, 보강하지 못한 수비진 덕택에 실점도 끊이지 않고 있었다. 그나마 이번시즌에 미들스보로와 임대제휴를 체결하여 리그1에서 뛰기엔 아까운 골키퍼인 Steel 을 임대하여 수비진의 붕괴를 막고 있는 형편.

아... 시발 대책을 어떻게 세워야 하나 하고 고민하고 있는 와중에 전반 종료 직전, 두개의 행운이 날아왔다.

Tutte 발리슛!

전반전에 마지막으로 얻은 코너킥 찬스에서 상대팀이 헤딩으로 걷어낸걸 Tutte 가 그대로 논스톱 발리슛으로 연결! 골!!!!! 스크린샷으로는 설명이 안되지는 조낸 쩌는 골이었다. 중거리슛도 안좋은녀석이 이런 슛을 넣어주다니...ㅠ

그리고 이어지는 행운. 전반 내내 우리 수비진을 휘젓고 다니던 Gimenez가 부상으로 이탈했다!

아싸!!!

하프타임. 여전히 두 골차. 뭔가 대책을 세워야 했다. 사실 후반에 두골차를 따라붙는다는건 어지간해서는 일어나지 않는 일이다. 하물며 그걸 뒤집는다는건...

전반의 문제점은 너무나 많아서 뭘 어떻게 대처해야할지 감이 안잡혔다. 3골 다 다른상황에서 나왔고, 그 3골은 윙백 붕괴, 중앙 미들 붕괴, 중앙 수비 붕괴의 현장을 모두 보여주었다. 그러고보니 킬패스에 의한 필드골, 중거리포, 헤딩슛 골고루 다 맞았네...-_-

공격에 있어서는 양쪽 윙 버로우. 중앙도 한 번 밀리기 시작한 이후로 회복이 안되고... 그러다보니 공격진도 따라서 버로우. 이건 뭐 팀을 통째로 바꿀 수도 없는 노릇이고...

하프타임에 취한 조치는 팀전술을 공격적으로 변경, 패스는 다이렉트로 하도록.
그리고 ML, MR 을 AML, AMR 위치로 옮겼다. 사실 윙이 그렇게 강하지 않은 우리팀의 특성상 측면돌파를 이용한 골은 잘 나오지 않는 편이다. 그래도 윙이 완전히 죽어버리면 우리팀의 장점인 중앙미들 - 강력한 투톱 역시 죽기 때문에... 어떻게든 윙에 변화를 줘보기로 했다.

또한 상대팀인 노리치는 후반 막판에 실점을 많이 하기 때문에, 교체멤버의 극대화를 노리기 위해 전반전이 개판이었음에도 불구하고 하프타임때 교체를 단행하지 않았다.

하지만 후반이 되어서도 상황은 나아지지 않았다. ML, MR을 AML, AMR로 올리면서 생긴 공간을 컴퓨터가 이용하기 시작했다. Brayford 와 Ateba 의 풀백 수비는 번번히 뚫리기 일쑤. Steel의 신기에 가까운 선방으로 간신히 실점만 면하는 상황들이 후반 초반에 계속 연출되었다.

65분 경. 이젠 결단을 내릴 때가 왔다. 난 시합 중 전술의 극적인 변화를 선호하는 타입은 아니었지만 두 골을 따라붙으려면 어쩔 수가 없다.

교체를 실시.

일단 65분에 먼저 LB였던 Ateba를 빼고 수비가 강한 Bloom을 투입하고 LB의 전술을 수비로 변경하였다.
점수가 뒤진 마당에 왠 수비 강화? 물론 다 생각이 있어서 한 것이다.

그리고 곧이어 MR인 Godsmark를 빼고 전형적인 타겟형 스트라이커인 Paterson을 투입. 동시에 ML인 McManus를 빼고 중앙미들인 Michel-King 을 투입하였다.

즉, 양 윙을 모두 빼버리고 4-3-3 으로 전환한것.

교체 이후의 포메이션.

4-3-3 플랫이 되었다! 별 다른 활약을 펼치지 못하는 윙을 빼버리고 중앙과 공격진을 강화하였다.
이 과정에서 필연적으로 왼쪽 측면 수비에 가담해야할 Murphy의 부담을 줄이고자 Bloom 을 투입하고 수비임무만 맡겨버린것. 사실상 왼쪽 측면 공격은 포기했다.

오늘 계속 삽질중인 Brayford 도 Tutte가 좀 더 오른쪽으로 치우치게 되면서 수비 부담이 줄었다.(Godsmark의 수비능력은 제로였기 때문)

중앙은 전형적인 수미인 Michel-King을 투입하여 약화될지 모르는 중앙미들수비를 보강.
결국 이 전술은 Murphy의 공격력을 극대화 시키기 위한 전술인 것이다.

그리고 이 판단은 200% 이상 적중했다!

Paterson 골!

4-3-3 으로 변경한지 5분만에 골이 터졌다! 상대적으로 공간이 여유로워진 Murphy 가 Patterson에게 멋드러진 패스를 연결한것. 그리고...

Paterson 또 골!

2분만에 또 골이 터졌다! 이번에도 Paterson! 교체멤버의 극대화를 노린게 그대로 맞아들가고 있었다. 이번 골은 오른쪽 측면에서부터 시작되었는데, Tutte가 오른쪽으로 치우치게 되면서 상대적으로 여유가 생긴 Brayford의 오버래핑에 의한 크로스가 시발점이었다.

휑~ 하니 비어버린 공간을 찾아 오버래핑항 Brayford가 Zola의 위치를 확인하고 여유롭게 크로스를 올렸다. 이 과정에서 Zola와 상대수비가 경합했는데 사실 볼은 수비수가 걷어냈으나 걷어냈는데 거기에 Paterson이 있었던것. 쓰리 톱이니깐!

Murphy의 마무리

곧이어 또 역전골! 역습에 의한 쓰리톱의 질주에서 나온 골이었다. Sofiane 의 스루패스를 Paterson이 따라잡아서 헤트트릭을 완성하는가 싶었지만 상대 골키퍼의 선방이 있었다. 그렇지만 Murphy가 있었다!
튀어나온 공을 잡아서 가볍게 슛. 골인!

4-3-3으로 전환하고 12분만에 3골을 작렬시켜버렸다. Murphy에게 여유가 생기자마자 팀 공격력이 폭발한것. 물론 교체해 들어와서 두 골을 기록하고 헤트트릭 직전까지간 Paterson 이 MVP를 먹긴 하였지만, 그래도 후반의 모든 공격의 시발점은 Murphy였다.

노리치의 오른쪽 윙은 Bloom 을 뚫지 못했고, 왼쪽 윙은 Tutte와 Brayford의 협력 수비에 효과적으로 차단되었다. 안그래도 조루성향이 강한 노리치는 내가 역전하고 난 이후에 이렇다할 찬스도 만들어내지 못하였다.

그나저나 이렇게까지 내가 약점을 파고들 수 있을지는 몰랐다... 여튼 기분 너무 좋다. 최고였엉.

지는게 싫어(負けず嫌い) 캐릭터들

2010-02-25T00:24:00.000+09:00

난 지는게 싫어(負けず嫌い-마케즈키라이) 캐릭터들을 참 좋아한다.
이유는 업ㅂ다. 걍 좋더라.
분명 하나의 고정속성으로 정착할만한 속성이라고 생각되는데, 어째 츤데레에 묶여
같이 취급되면서 츤데레 캐릭터라면 당연히 따라오는 속성 정도로 묻혀버린 감이 있다;

여튼 마케즈키라이 캐릭터는 매력이다. 모에스럽단 말야.

내가 알고 있는 마케즈키라이 캐릭터들을 한 번 나열해보자.
당연하지만 남캐는 취급 안함.

- 텐도 아카네
마케즈키라이 캐릭터의 대표주자라고 하면 역시 이 분 아니겠음! 아카네 만세.

- 란마
남자 란마는 껒여.

-츤데레포
최근의 마케즈키라이 캐릭터 중에서는 히나기쿠랑 더불어 독보적인 위치에 올라있는 츤데레포.
츤데레 + 강력함 + 마케즈키라이 + 수집덕후 등등... 모에요소의 총집합. 속바지만 빼면.

-토나미 유마
투하트2의 유마. 드물게도 대놓고 마케즈키라이 모에를 정면에 내세운 캐릭터였지만 인기는 조트망.

- 토오사카
오버니삭스계의 최정점에 위치하고 계신 이분도 마케즈키라이. 본편에서는 적극적으로 속성이 출현하진 않지만 역시 HA와 동인소재로 가장 많이 애용되는 HW루트 이후의 동인지, 동인소설에서는 극강의 마케즈키라이 포스.

- 토모
마케즈키라이라기 보단 그냥 폭주바보지만 어쨋든...[...] 지기만 싫어하고 노력은 안하는 대표적인 캐릭터. 아즈망가에서는 카구라가 마케즈키라이 캐릭터에 가깝지만 속성이 묘사가 거의 안되므로 패스.

-에도마에 루나
루나짱 하앍. 아주 정석적인 츤데레 + 마케즈키라이.

- 미야미야
아주 드물게도, 마케즈키라이 속성을 지니고 있으면서 츤데레가 아닌 캐릭터. 만세!

- 히나기쿠
말이 필요 업ㅂ다.

- 드릴
가장 최근에 등장한 작품 중에서는 얘가 그나마 마케즈키라이 속성이 강렬하게 표현되는 캐릭터.

- 스쿨드
져버리면 질질 짜는 캐릭터의 대명사... 였던거 같은데 이젠 잘 기억이...[...]

머릿속에 당장 생각나는건 이정도일려나.

최종보고회 종료

2010-02-24T12:33:00.000+09:00

대구공원 프로젝트의 최종보고회가 오늘 있었다.
모든 것은 무난하고 안전하게 잘 돌아갔다.

이제 이 프로젝트의 종료와 함께 이 회사도 퇴사한다.
무사히 끝나니... 조금은 뿌듯하네. 예전에 했던 프로젝트들 완료했을때와는
느낌이 다르다...

여튼 끝났다.
돌이켜보면 이런저런일도 있었지만...

끝이 좋으니 정말 좋은 형태로 퇴사를 하게 되는 것 같다.

오사카 긔엽긔

2010-02-22T22:23:00.000+09:00

오사카 긔엽긔

D3D 공부 시작부터 버그가...

2010-02-22T20:13:00.000+09:00

D3D 공부를 시작했는데... 뭐 첨부터 버그가 떡 하니...

난 육면체를 그리라고 시켰는데....

육면체를 그리긴 하되 화면 갱신이 안되는 것이었다.
대체 뭘 잘못했는지 쉽사리 찾지를 못했는데... Draw 함수 자체는 잘못된게 없었기 때문이었다.

VOID Application::Draw(VOID)
{
m_pd3dDevice->Clear( 0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(0,0,255), 1.0f, 0 );

SetupMatrices();

if( SUCCEEDED( m_pd3dDevice->BeginScene() ) )
{
box->Draw(m_pd3dDevice);
m_pd3dDevice->EndScene();
}
m_pd3dDevice->Present( NULL, NULL, NULL, NULL );
}

문제는 Z버퍼를 사용하는데 내가 설정을 하나 빼먹었더라... 이거.

m_d3dpp.EnableAutoDepthStencil = TRUE;

이걸 빼먹으니... 화면 갱신이 안되네.
찾아보니 아무래도 Z버퍼를 관리할 것인지 여부를 결정하는 속성인듯 하다.

블루레이 레코더 장착

2010-02-22T00:09:00.000+09:00

HL(히타치 LG)의 BH10NS30을 장착!

우왕ㅋ굳ㅋ 이제 내컴에서 블루레이 구울 수 있다능 ㅋ

익수형 땡큐땡큐

객체지향과 패턴

2010-02-15T20:40:00.000+09:00

객체지향이란

- 공통점 묶기
- 조금만 알기

패턴이란

- 끊임없는 리팩토링의 결과

'패턴 그리고 객체지향적 코딩의 법칙' 의 책을 사서 읽는 도중에 나온 말인데...
저 말만으로도 책 산 가치가 있는 듯.

도키메모4를 질렀다!

2010-01-28T00:29:00.000+09:00

우월한 미야코 여신님. 얘만 아니었어도 PSP 안질렀어...

도키메모4 질렀다! 내가 이 겜 할려고 PSP까지 지른거 아니겠엉.

사용자 이름을 불러주는 음성합성 기능은 감동. 상당히 자연스러운 수준이었다.
그 이쁜 목소리로 '아스루군~' 하는데 캬... 이래서 덕 라이프가 좋구나 싶더라니까.

게임은 아직 초반밖에 진행 안했지만 상당히 만족. 재미있다.
PSP지른 돈이 헛되지 않았어.

단지 표정을 자연스럽게 처리해준다는 모션 포트레이트라는 기능 때문에
화면이 다소 이글이글 거리는 느낌이 난다.

그나저나... 마키 생일선물 선택할 때 미소를 선물했더니
표정 싸~해지면서 돌아오는 반응

"필요업ㅂ어 그딴거..."

2D 게임 여자도 금전 선물만 밝히는 더러운 세상.

츤데레포 16화

2010-01-24T23:57:00.000+09:00

이번 화는 내용전개도 뭔가 조금 이상하고,

작붕까진 아니지만 그림체도 살짝 일관성을 잃은듯 하고...

눈에 들어오는건 코노리의 우월함밖에 없구나.

우월하다 코노리.

예외처리 되지 않은 예외를 핸들링 해보자

2010-01-18T16:04:00.000+09:00

try ~ catch 문 처리를 하지 않은 곳에서 예외가 발생하면
늘상 보는 그 예외창이 뜨는데...

그 때 발생하는 예외를 핸들링 할 수 있는 방법이 있다.

프갤 물다횽 글 보고 검색하다가 일본웹에서 검색하다가 해결법을 찾았다능...

아래는 코드.
이걸 이용하면 예외 나도 걍 무시하게 만들어버릴 수도 있다.

public Form1()
{
InitializeComponent();

//AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

// ThreadException이벤트·핸들러를 등록한다
Application.ThreadException += new
ThreadExceptionEventHandler(Application_ThreadException);

// UnhandledException이벤트·핸들러를 등록한다
Thread.GetDomain().UnhandledException += new
UnhandledExceptionEventHandler(Application_UnhandledException);

}

// 미처리 예외를 캐치 하는 이벤트·핸들러
// (Windows어플리케이션용)
public static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
{
ShowErrorMessage(e.Exception, "Application_ThreadException에 의한 예외 통지입니다.");
}

// 미처리 예외를 캐치 하는 이벤트·핸들러
// (주로 콘솔·어플리케이션용)
public static void Application_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
Exception ex = e.ExceptionObject as Exception;
if (ex != null)
{
ShowErrorMessage(ex, "처리되지 않은 예외가 발생했다능");
}
}

public static void ShowErrorMessage(Exception ex, string extraMessage)
{
MessageBox.Show(extraMessage + " \n――――――――\n\n" +
"아주아슬의 처리되지 않은 예외의 처리\n\n" +
"에러 내용\n" + ex.Message + "\n\n"
);
}

void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
//Process.GetCurrentProcess().Close();
}

private void button1_Click(object sender, EventArgs e)
{
object aaa = null;
aaa.ToString();
}

내가 찾았던 일본 웹 사이트 :
http://www.atmarkit.co.jp/fdotnet/dotnettips/320appexception/appexception.html

하아... 이번 주 왜 이래...

2010-01-09T13:22:00.000+09:00

일은 존나 바빳고...

통발러브는 텍크 8강에서 탈락하고...

랜디존슨도 은퇴하고... 하아...

엉엉 랜디존슨... 아직 1~2년은 충분히 뛸 수 있는데...ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

랜디옹 은퇴한다니 왜 이렇게 기분이 서글프다냐.

랜디옹 수고하셨습니다.

전차장님이랑 대화...

2010-01-02T11:57:00.000+09:00

12월 31일에... 전차장님이랑 술을 마셨다.

그래도 날 나쁘지 않게 보셨는지 갑자기 술 한잔 하자고 하시더라공.
술 마시면서 이런저런 이야기들을 많이 해주셨는데...

대충 정리하자면

1. SI는 막장 중에 개막장. 100개 중에 99개는 나쁜 점 뿐이다.
2. SI가 좋은 점이 딱 하나가 있는데, 실력은 속성으로 쌓인다.

3. PM의 가장 중요한 능력은 PM 자기 자신이 살 길을 찾는 능력이다.
4. PM이 자기 살 길을 열기 위해서는 이슈를 터트릴 시기를 조절할 줄 알아야 한다...
어차피 이슈는 반드시 터지게 되어 있는데, 이걸 언제 터뜨리냐를 조절 할 수 있어야 된다는 이야기.

5. 개발자의 필수 스킬은 분석,설계,코딩이 아니라 인간관계. 여기서 인간관계란 팀원이랑 잘 지내고 술 잘 마시고
   하는 레벨이 아니라... 프로젝트 팀에서 보이지 않는 주도권을 잡을 수 있어야 한다는 소리.
   어차피 한 프로젝트에 개발자는 몇 명 이상이 있는데... 그 몇 명 중에서 자신이 주도권을 잡아야 한다.
   이 주도권이라는걸 잡게 되면 해당 프로젝트에서 자신은 빠져서는 안되는 존재가 될 수 있고, 이걸 바탕으로 자신의
   상품가치를 높여 나가야 한다... 이건 설계,분석,코딩 능력과는 무관하다.

6. 주도권이라는걸 잡기 위해서는 프로젝트 초반에 열심히 일하는게 중요. 보통 SI 프로젝트는 '초반에 열심히 일해서 뭐하냐...
어차피 시간 지나면 요구사항 바뀌고 그럼 엎어야 되고 나중가면 힘들어지는건 마찬가지인데' 라는 의식이 팽배함.
그렇지만 생각보다 초반에 (해야 할 일이 아닌) 할 수 있는 일은 정말 많다고... 하다못해 문자열 파싱하는 기준 같은거라도
자기자신의 기준에 프로젝트 팀을 맞추게 할 수 있는 시간이 초반에 있다고 함.

7. 남은 인생을 개발관련에 올인 할 꺼 아니면 팀원에게서 욕먹더라도 일찍 퇴근하는것이 가장 현명함...

등등...

들려주신 이야기는 더 많았었는데 기억이 잘 안나네...-_-

res://C:\WINDOWS\system32\shdoclc.dll

2009-12-26T12:57:00.000+09:00

JSP에서 서블릿이나 특정 페이지 호출 시에
페이지 주소 앞에 res://C:\WINDOWS\system32\shdoclc.dll 이 붙어버려서
404에러가 떠버렸었다.

WAS 는 제우스4.2 였다.

원인은 web.xml에 있었는데, 이게 실서버랑 완전 동일한 web.xml 을 사용하고 있어도
정작 우리 테스트 섭쪽에는 적용이 안되는것이었다.

참고로 테스트섭과 실서버의 환경은 컴퓨터 사양을 제외하곤 완전히 동일했다.

여튼 web.xml 에 다음 부분을 추가해주자 잘 실행이 되었다.

<servlet-name>WorkerServlet</servlet-name>
<servlet-class>jeus.servlet.servlets.WorkerServlet</servlet-class>
<load-on-startup>-1</load-on-startup>
<init-param>
<param-name>PackageSeparator</param-name>
<param-value>.</param-value>
</init-param>
</servlet>

<servlet-mapping>
<servlet-name>WorkerServlet</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>

couldn't resolve all exception handlers in method

2009-12-21T18:24:00.000+09:00

JAD 1.5.8을 사용하여 디컴파일 할 때,
몇몇 클래스는 couldn't resolve all exception handlers in method 메시지를 내보내며
제대로 디컴파일 되지 않는 경우가 있다.

원인은 콕 하나로 찝어 말할 수 없다. 여러 원인이 있기 때문이다.

그 원인 중 하나는, try~catch~finnaly 문을 재구성 하지 못할 때 발생한다.
내가 경험한 바로는 finally 문이 들어가 있을 때 이 에러를 뱉는 확률이 높은 것 같다.

여튼 내가 가졌던 문제는 이것이었다. finally 문을 제대로 재구성 할 수 없는 것.
이건 JAD로는 뭔 짓을 해도 안되더라...

해결책은 다른 디컴파일러를 사용하는 것이다.
나는 JD-GUI 를 이용하여 디컴파일 했다.

감탄 나올 정도로 완벽하게 디컴파일 되서 나왔다.

디씨 차단 당했다

2009-12-16T04:11:00.000+09:00

읭읭 ㅠㅠ

시댕 평소엔 활동 안하더니 왜 그 한 새벽중에 들러서 알바질이야 -_-+

새벽에 수위 찔끔 있는 덕짤 좀 올렸거로서니...

새벽 3시 넘어서 차단 당하다니 -_-

JAD 사용하기

2009-11-16T14:33:00.000+09:00

자바 디컴파일러 JAD 사용하기.
이클립스 플러그인 형태로 말고 걍 커맨드 창에서 쓰는 법.

jad -sjava 디컴파일할자바클래스

*.class 로 하면 해당 폴더의 모든 class가 디컴파일 된다.

오오 후못후 블루레이!!!!!

2009-11-09T23:30:00.000+09:00

후못후 블루레이가 나왔을 줄이야!!!!!

우왕ㅋ 굳ㅋ

후못후 2기 좀 안내주나 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

아 씨발 졌어 ㅠ

2009-11-09T13:48:00.000+09:00

1월 말까지 하기로 했어 아놔 -_-

관둔다능

2009-11-04T11:08:00.000+09:00

1월 14일까지.

기간은 더 줄면 더 줄었지(더 줄여주면 나는 땡큐베리감사고)

저 날을 넘길 일은 절대 없을 것.

C#과 자바에서 finally 문은...

2009-10-28T12:31:00.000+09:00

점심시간인데 점심도 못먹고... 그래서 블로그에 뻘글이나 하나 쓴다능.

C#과 자바에서 finally 문은...
try 문이나 catch 문 내에서 return 을 만나도 실행이 된다.

이러한 특성을 이용하여
C++에서의 소멸자의 역할을 어느정도 finally 가 수행하게 할 수 있다.
물론 객체가 파괴될 때 실행되는게 아니라서 좀 다르긴 하지만...

이것이 finally문 안에 각종 객체의 해제를 수행하는 이유다.

미끄럼틀타야짘ㅋㅋㅋㅋ

2009-10-26T21:43:00.000+09:00

미끄럼틀 타야짘ㅋㅋㅋㅋㅋㅋㅋㅋ

이거 존나 좀 짱이지 않음? ㅋㅋㅋㅋㅋㅋ

제우스 기동 시 가상메모리 어쩌구 하면서 기동이 안될때

2009-10-23T11:51:00.000+09:00

어제 제우스 환경을 추가로 VM에 세팅했었는데...
시댕 설정 분명히 다 제대로 잡아줬는데 동작 안하는게 아닌가.

그러나 분명 출력 메시지에는 제우스가 성공적으로 기동되었다고 떳으므로
설마 제우스가 기동 자체가 되지 않았다고는 생각을 못했었다.

근데 분명 웹투비는 잘 돌아가는데 제우스 연결이 안된다...
시발 분명히 제우스 기동시 다 OK 메시지 뜨고 라이센스 인증까지 떳는데.

...설마 훼이크인가? 실제로는 기동이 안되었다던지...

라고 생각해서 로그를 뒤지기 시작했다.

아니나 다를까... 로그 존나게 읽다보니

Error occurred during initialization of VMCould not reserve enough space for object heap

라는 메시지가 떠있는게 아닌가.

말 그대로 힙영역 부족... 라는 메시지. 한마디로 '메모리 모잘라 ㅅㅂ. 이딴 컴터에서는 날 못돌림ㅋ'
인것이다.

여튼 뭐... 그렇다고 메모리를 더 꼽을 수는 없는 노릇.

윈도우 가상메모리를 최소 1024 - 최대 2048 까지 늘려주니 잘 해결되었다.

결론 : 제우스 메모리 존나 많이 처먹음 ㅅㅂ.

SQL 비교연산자 != 는 사실 표준이 아냐.

2009-10-21T17:07:00.000+09:00

프갤에 심심해서 글 싸지른 내용인데... 적고보니 블로그에도 적어두는게 좋겠다 싶었음.

여튼 SQL Where 절 비교연산자인 != 는 사실 표준이 아냐.

표준은 오직 <> 뿐임.

옛날 RDBMS 에서는 != 를 지원하지 않았던 것도 있었던 듯 하다.

지금은 왠만하면 다 지원하는 듯.

결국 뭘 쓰든 상관없다는 이야기.

아슬라이브러리 -- 문자열 관련

2009-10-20T12:42:00.000+09:00

1년전쯤에 만들어두었던 아슬라이브러리.

자주 이용했거나, 또는 자주 이용하게 될 것 같은 기능들을 만들어서 묶은 것들임.

혹시 분실할까봐 블로그에 올려둔다. 물런 99.99% 직접 만든거라능.

일단 문자열 관련.

namespace AsulLib
{
/// <summary>
///
/// C#의 문자열 관련 작업의 귀차니즘을 줄여보고자 만든 라이브러리입니다.
/// 평소에 졸랭 귀찮아하던 문자열 작업들을 묶었습니다.
/// 이 클래스의 모든 메서드는 static 메서드입니다.
/// </summary>
static public class CS_String
{
/// <summary>
///
/// 전달받은 targetStrArray내에서 중복된 문자열을 제거한 배열을 리턴합니다.
/// </summary>
/// <param name="targetStrArray"></param>
/// <returns></returns>
static public string[] StrDistinct(string[] targetStrArray)
{
string[] tempArray = new string[targetStrArray.Length];
LinkedList<string> lnkStrs = new LinkedList<string>();
targetStrArray.CopyTo(tempArray, 0);
//Array.Copy(targetStrArray, tempArray, targetStrArray.Length);
Array.Sort(tempArray);

int count = 0;
string tempstr = "";

foreach (string str in tempArray)
{
if (str != tempstr)
{
lnkStrs.AddLast(str);
++count;
}
tempstr = str;
}

string[] rtnArray = new string[lnkStrs.Count];
lnkStrs.CopyTo(rtnArray, 0);
return rtnArray;
}

/// <summary>
///
/// targetStrArray내에서 str과 일치하는 콘텐츠의 개수를 리턴합니다.
/// </summary>
/// <param name="targetStrArray"></param>
/// <param name="str"></param>
/// <returns></returns>
static public int CountStrInArray(string[] targetStrArray, string str)
{
//졸랭 무식한 코드지만 이렇게 해도 속도 졸라 짱 빠르다.
//참 세월 좋다...

int count = 0;
foreach (string s in targetStrArray)
{
if (s == str)
++count;
}

return count;
}

/// <summary>
///
/// targetStr의 제일 우측에서부터 length길이만큼의 문자열을 리턴합니다.
/// targetStr의 길이가 length보다 작을 경우에는 targetStr을 그대로 리턴합니다.
/// </summary>
/// <param name="targetStrArray"></param>
/// <param name="length"></param>
/// <returns></returns>
static public string CutRight(string targetStr, int length)
{
string cutedString = "";
cutedString = targetStr;
if (cutedString.Length < length)
return cutedString;

cutedString = cutedString.Substring(cutedString.Length - length);

return cutedString;
}

/// <summary>
///
/// targetStr의 제일 우측에서부터 length길이만큼의 문자열을 제외한 targetStr을 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="length"></param>
/// <returns></returns>
static public string CutRightReverse(string targetStr, int length)
{
string cutedString = "";
cutedString = targetStr;
if (cutedString.Length < length)
return cutedString;

cutedString = cutedString.Substring(0, cutedString.Length - length);

return cutedString;
}

/// <summary>
///
/// targetStr의 좌측에서부터 length길이만큼의 문자열을 리턴합니다.
/// targetStr의 길이가 length보다 작을 경우에는 targetStr을 그대로 리턴합니다.
/// </summary>
/// <param name="targetStrArray"></param>
/// <param name="length"></param>
/// <returns></returns>
static public string CutLeft(string targetStr, int length)
{
string cutedString = "";
cutedString = targetStr;
if (cutedString.Length < length)
return cutedString;

cutedString = cutedString.Substring(0,length);

return cutedString;
}

/// <summary>
///
/// targetStr의 좌측에서부터 length길이만큼의 문자열을 제외한 targetStr을 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="length"></param>
/// <returns></returns>
static public string CutLeftReverse(string targetStr, int length)
{
string cutedString = "";
cutedString = targetStr;
if (cutedString.Length < length)
return cutedString;

cutedString = cutedString.Substring(length);

return cutedString;
}

/// <summary>
///
/// targetStr의 우측에서부터 mark가 있는 지점까지의 문자열을 리턴합니다.
/// ex) abcde*efg 일 경우 mark가 * 이면 efg를 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="mark"></param>
/// <returns></returns>
static public string CutRightMark(string targetStr, char mark)
{
int index;
string cutedString = "";
cutedString = targetStr;

index = targetStr.IndexOf(mark);
cutedString = cutedString.Substring(index + 1);

return cutedString;
}

static public string CutRightMarkReverse(string targetStr, char mark)
{
int index;
string cutedString = "";
cutedString = targetStr;

index = targetStr.IndexOf(mark);
cutedString = cutedString.Substring(0, index);

return cutedString;
}

/// <summary>
/// ##AsulLib##
///
/// targetStr의 우측에서부터 mark가 있는 지점까지의 문자열을 리턴합니다.
/// markInclude가 true이면 mark를 포함하여 리턴합니다.
/// ex) abcde*efg 일 경우 mark가 * 이면 *efg를 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="mark"></param>
/// <returns></returns>
static public string CutRightMark(string targetStr, char mark, bool markInclude)
{
int index;
string cutedString = "";
cutedString = targetStr;

index = targetStr.IndexOf(mark);
if(markInclude)
cutedString = cutedString.Substring(index);
else
cutedString = cutedString.Substring(index + 1);

return cutedString;
}

/// <summary>
///
/// targetStr의 좌측에서부터 mark가 있는 지점까지의 문자열을 리턴합니다.
/// ex) abcde*efg 일 경우 mark가 * 이면 abcde를 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="mark"></param>
/// <returns></returns>
static public string CutLeftMark(string targetStr, char mark)
{
int index;
string cutedString = "";
cutedString = targetStr;

index = targetStr.IndexOf(mark);
cutedString = cutedString.Substring(0, index);

return cutedString;
}

/// <summary>
/// ##AsulLib##
///
/// targetStr의 좌측에서부터 mark가 있는 지점까지의 문자열을 리턴합니다.
/// markInclude가 true이면 mark를 포함하여 리턴합니다.
/// ex) abcde*efg 일 경우 mark가 * 이면 abcde* 를 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="mark"></param>
/// <returns></returns>
static public string CutLeftMark(string targetStr, char mark, bool markInclude)
{
int index;
string cutedString = "";
cutedString = targetStr;

index = targetStr.IndexOf(mark);
if (markInclude)
cutedString = cutedString.Substring(0, index + 1);
else
cutedString = cutedString.Substring(0, index);

return cutedString;
}

/// <summary>
///
/// targetStr의 좌측에서부터 position번째 mark가 있는 지점까지의 문자열을 리턴합니다.
///
/// ex) abcde*efg*hjk 이고 mark가 *, position이 2 이면 abcde*efg 를 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="mark"></param>
/// <returns></returns>
static public string CutLeftMark(string targetStr, char mark, int position)
{
int index = 0;
string cutedString = "";
cutedString = targetStr;

for(int i = 0 ; i < cutedString.Length ; ++i)
{
if (position == 0)
break;
if (cutedString[i] == mark)
--position;
index = i;
}

cutedString = cutedString.Substring(0, index);

return cutedString;
}

/// <summary>
///
/// targetStr의 좌측에서부터 position번째 mark가 있는 지점까지의 문자열을 리턴합니다.
/// MarkInclude가 true이면 mark도 포함하여 리턴합니다.
/// ex) abcde*efg*hjk 이고 mark가 *, position이 2 이면 abcde*efg* 를 리턴합니다.
/// </summary>
/// <param name="targetStr"></param>
/// <param name="mark"></param>
/// <returns></returns>
static public string CutLeftMark(string targetStr, char mark, int position, bool MarkInclude)
{
int index = 0;
string cutedString = "";
cutedString = targetStr;

for (int i = 0; i < cutedString.Length; ++i)
{
if (position == 0)
break;
if (cutedString[i] == mark)
--position;
index = i;
}

cutedString = cutedString.Substring(0, index);

return cutedString;
}

/// <summary>
///
/// array1과 array2를 합친 문자열 배열을 리턴합니다.
/// </summary>
/// <param name="array1"></param>
/// <param name="array2"></param>
/// <returns></returns>
static public string[] SumStringArray(string[] array1, string[] array2)
{
if (array1 == null || array1.Length < 1)
{
return array2;
}

if (array2 == null || array2.Length < 1)
{
return array1;
}

string[] sumStrs = new string[array1.Length + array2.Length];

int i = 0;
foreach (string s in array1)
{
sumStrs[i] = s;
++i;
}
foreach (string s in array2)
{
sumStrs[i] = s;
++i;
}

return sumStrs;
}

static public string[] CreateStringArrayByStrings(params string[] strs)
{
return strs;
}

/// <summary>
/// strArray내에서 removeStr을 제거한 문자 배열을 리턴합니다. strArray내에서 removeStr이 여러 개면 모두 제거합니다.
/// </summary>
/// <param name="removeStr"></param>
/// <param name="strArray"></param>
/// <returns></returns>
static public string[] RemoveStrInStringArray(string removeStr, string[] strArray)
{
int i = 0;
LinkedList<string> newstring = new LinkedList<string>();

foreach (string s in strArray)
{
if (s != removeStr)
newstring.AddLast(s);

++i;
}

string[] returnstringarray = new string[newstring.Count];
newstring.CopyTo(returnstringarray, 0);

return returnstringarray;
}

/// <summary>
/// strArray내에서 removeStr을 제거한 문자 배열을 리턴합니다. onlyFirstRemove가 true이면 첫번째 removeStr만 제거합니다.
/// </summary>
/// <param name="removeStr">제거할 문자열입니다.</param>
/// <param name="strArray">제거할 문자열이 들어있는 문자열 배열입니다.</param>
/// <param name="onlyFirstRemove">이 값이 true이면 발견되는 모든 removeStr 에서 첫번째 값만 제거합니다.</param>
/// <returns></returns>
static public string[] RemoveStrInStringArray(string removeStr, string[] strArray, bool onlyFirstRemove)
{
int i = 0;
LinkedList<string> newstring = new LinkedList<string>();

bool FirstRemoved = false;

if (onlyFirstRemove)
{
foreach (string s in strArray)
{
if (s != removeStr || FirstRemoved)
newstring.AddLast(s);

else if (s == removeStr)
{
FirstRemoved = true;
}

++i;
}
}

else
{
foreach (string s in strArray)
{
if (s != removeStr)
newstring.AddLast(s);

++i;
}
}

string[] returnstringarray = new string[newstring.Count];
newstring.CopyTo(returnstringarray, 0);

return returnstringarray;
}

/// <summary>
/// inputData 문자열의 값이 숫자인지 체크합니다.
/// </summary>
/// <param name="inputData"></param>
/// <returns></returns>
public static bool IsNumeric(string inputData)
{
//foreach (char c in inputData)
//{
//    if (!Char.IsDigit(c))
//    return false;
//}

//return true;
double check;
return double.TryParse(inputData, System.Globalization.NumberStyles.Any, null, out check);
}

/// <summary>
/// startMark와 endMark를 제거한 문자열을 리턴합니다.
/// ex) string a = "(%테스트입니다.%)";
///    string b = RemoveSplitMark(a, "(%", "%)");
/// 결과 : b에는 테스트입니다. 가 저장.
/// </summary>
/// <param name="source"></param>
/// <param name="startMark"></param>
/// <param name="endMark"></param>
/// <returns></returns>
public static string RemoveSplitMark(string source, string startMark, string endMark)
{
int lenStartMark = startMark.Length;
int lenEndMark = endMark.Length;

int indexStartMark = source.IndexOf(startMark);
int indexEndMark = source.IndexOf(endMark);

int lenReturn = indexEndMark - indexStartMark - lenEndMark;

if (lenReturn < 0)
return source;

return source.Substring(indexStartMark + lenStartMark, lenReturn);
}
}
}

지적행정 RPC 연결

2009-10-19T17:43:00.000+09:00

준비물 : 전달받는 odet40.jar.
   그리고 따로 받는 java 파일들.(java파일은 어떤 서비스를 이용하느냐에 따라
   전달받는 java 파일이 다르다. 그러나 대부분 거의 비슷한 구조를 취함.)
   받는 java 파일의 이름은 lrg_st서비스번호_c.java 의 구조를 취하고 있다.

그 외에는? 필요 업ㅂ다. odet40.jar 파일과 따로 받은 java파일만 있으면 OK.

사용법 : 극히 간단하다. 전달받은 java 파일에 있는 메서드에 인자만 맞춰서 던져주면 알아서
결과를 가져온다. 그저... 내가 삽질한 것은 lrg2.env 파일을 어떻게 사용하느냐에 대해
전혀 감을 못잡았던것 뿐.
같이 전달 받은 문서에는 lrg2.env 파일의 내용만 적혀있을 뿐 사용법에 대해 일절 나와
있지 않았다.

1. lrg2.env 파일을 서버컴터 적당한 곳에 생성한다. 난 C:\ 에 생성.

2. lrg2.env 파일을 적절하게 편집. 시청 또는 관공서에게 전달받은 문서에 편집방법이 나와 있을 것이다.

3. JSP에서 전달받은 java 클래스의 메서드를 인자에 맞게 호출해도 아예 전송 시도도 못하고 에러가
   났다. 이유를 몰라서 존나 뻘짓. 원인은 lrg2.env 파일.

4. 전달받은 java 클래스의 메서드를 호출하기 전, Environment.setEnv(lrg2.env파일경로) 를
   호출하여 lrg2.env 파일을 등록.

5. 신호가 잘 갈 것이다.

6. 이제 값만 얻어오면 된다... 근데 전달하는 인자에 값을 얻어오는데 이게 전부 ArrayObject 형이다.

7. 이름만 보면 자바에서 기본적으로 지원하는 형처럼 보인다... 속지 마라. 이건 odet40.jar 에서 제공하는
자료형이다.

8. 그럼 실질적으로 사용하기 위해선 적절한 자바 자료형으로 변환시켜줘야 한다. 어떤 자료형으로 변환해야
하는지는... 에러메시지 보고 찾아내는 수 밖에 업ㅂ다.

대부분은 문서에 char 형이라고 되어 있는데, 당연하지만 자바에서는 문자열을 말한다.
근데 문자열형으로 변환시키면 안된다. 에러메시지를 보면 LJava.lang.String 어쩌구... 로 나오는데,
이건 String 을 말하는게 아니고 String[] 형을 말한다. String[] 형으로 변환하자.

9. 단일 값인 경우 [0] 번째 값을 가져오면 OK... 끝.

그럴 일은 절대로 없겠지만... 지적행정 RPC검색하다가 찾아오시는 분들,
odet40.jar 파일이나 자바 클래스 파일... 저한테 달라고 하시면 안됩니다.
반드시 관공서에 공식요청해서 얻어야합니다.

캠퍼 3화...

2009-10-17T01:43:00.000+09:00

내가 이걸 왜 보고 있을까

...그래도 3화까지만 보자 했었는데,

3화 봤으니 이제 진짜 안봄. (그러나 4화가 나오면 또 볼 것 같은 이 불길한 예감)

...동성물은 나한테 버겁다;;;

미라쥬650 첫 날... 만신창이.

2009-10-12T09:13:00.000+09:00

10월 10일 토요일...

아침 7시 집에서 나와서 8시 차로 서울로 출발... 광명 9시 반 도착. 구로디지털에 10시 반 도착.
판매자 만남... 화기애애 분위기... 오토바이 상태도 좋은 것 같음... 거래 성립.
내 통장에서 초거액이 빠져나감.

11시 반 오토바이 몰고 대구로 출발... 1번국도 타고 가다가
용인가는 길을 놓쳐서 그냥 대전까지 직행...
대전 3시 도착... 대전에서 길 3시간 헤멤... 시발...

간신히 올바른 길 찾아서 대전을 뜬 시각이 저녁 6시.

그러나 대전 출발 30분만에 국도에서 오토바이 멈춤. 고장...
시발 기어를 넣어도 차가 안가...-_- 클러치가 나갔음... 엔진 상태만 체크하고 클러치까지 체크하지 못한
나의 패배...

국도 시발... 아무것도 없는 휑 한데서 오토바이는 꿈쩍도 안하고... 미침. 당연히 아직 보험에 가입 되지 않았으므로
보험회사에 전화도 못해...
119에 전화하니까 '아 씨 그런걸 왜 우리한데 그러냐' 는 차가운 말만 내뱉고 끊음. 다시 119에 전화걸어서 그럼 제발 내가
위치한 지역이랑 지역번호만이라도 가르쳐 달라고 애걸. 아직 충청도인거랑 충청도 지역번호가 041인거 확인...

114신공으로 근처 오토바이 센터에 전화질... 안받거나 다 거절당함.
답이 없어서 오토바이 세워두고 걍 좀 걷다보니 주유소가 하나 나옴.
그 주유소 아저씨에게 애걸복걸 사정 설명을 하여 근처 마을의 센터에 전화...
센터 아저씨가 선뜻 OK. 덕택에 근처 마을의 센터까지 오토바이 이송 성공...

센터 아저씨는 오토방구 뜯어보고 월요일에 전화해준다고 함... 넘 고마워서 굽신굽신.

난 택시 타고 기차역으로 고고씽...
기차역에 무궁화호 잡아타고 출발. 그러나... 무궁화호는... 무궁화호가 아니었어.
세상에 간이역까지 100% 다 서는 무궁화호는 첨 타봤다... 그냥 비둘기호라 그러지...

넘 힘들었다능... 마음도 몸도 통장도 만신창이. 에휴...

캠퍼 2화...

2009-10-11T14:54:00.000+09:00

하아...

까놓고 말해서...

...재미없엉. 소재가 특이하면 머해... 재미가 없는데... OTL

프갤 레아님의 조언

2009-10-08T14:01:00.000+09:00

프갤에 가볍게 '겜쪽으로 이직하고싶엉ㅋ' 이라는 글을 썻는데
레아님이 답변을 너무나 잘해주셔서 블로그에 정리.

Rhea : XNA는 기본적으로 위저드 코드에서 타이머와 업데이트 루틴을 만들어줍니다. 그래서 이쪽 개념을 알수 없으므로 C++을 추천합니다.

Rhea : 그리고 자원관리나 다른 측면에서도 C++을 추천합니다. XNA를 준비하는 곳이 아니라면 보편적이진 않아요.

Rhea : 그런데 모든 개발자가 DX를 잘하는건 아닙니다. 분야는 많으니 게임 회사라고 꼭 게임을 준비하란 법은 없습니다.

Rhea : 어느 파트에 대한 지원인지 먼저 생각해보시길 바랍니다.

Rhea : 메인스킬을 Win32 C/C++로 잡았다는 가정하에, 클라 엔진, 클라툴, 클라 컨텐츠, 서버, 공용기술 쪽으로 나눠집니다.

Rhea : 클라엔진 : 인터페이스를 적극활용한 셰이더 기반 엔진을 만드세요. 셰이더만 넣는 이펙터도 있는데 한국엔 없다고 보면 됩니다. 물론 MAX SDK랑도 친해야 합니다.

Rhea : 클라 컨텐츠 : 가장 머릿수가 많음. C/C++의 내공이 필수. 포폴시 엔진 자체보다 객체관리, 다양한 게임 기법 코드의 활용에 중점을.

Rhea : 서버 : 대용량 처리기술, DBA 스킬 피수. PKI같은 보안쪽 스킬이 있음 매력도 상승. 현실적으로 신입이라면 NAT을 뚫는 P2P 엔진이 포폴로 좋음.

Rhea : 공용툴 : 일반 Win32 개발자로 보면됨. ActiveX, 웹언어(PHP, JSP, ASP), 소켓 등, 넓고 깊은 기술도 요구. 괜찮은 Win32 기반 애플이면 포폴 OK

Rhea : 툴개발자 : 다양한 Win32로 무엇이든 만들수 있어야함. DX관련도 당근 들어가니 필수. 포폴로 맵에디터 정도면 OK

Rhea : 그외 네트워크쪽을 어필하고 싶으면 잉여 개초보들처럼 IOCP 같은거 따지지말 것. 어차피 포폴이나 면접으로 증명이 안되기 때문이야.

Rhea : 대부분이 모르는데... 구글코드의 프로토콜 버퍼같은 패킷 라이브러리 있으면 아주 좋음.

Rhea : ㄴ물론 직접제작이 당연하지. 장단점 설명할수 있어야 하고.

힘내자능.

오라클 SQL 구문의 WHERE IN 절은 무한대일까?

2009-10-07T14:04:00.000+09:00

조건에 맞는 값들을 한 번에 가져올 경우 자주 이용하게되는 IN 절.
이 WHERE [컬럼명] IN 절에서 조건을 과연 무한대로 줄 수 있을까?

결론만 말하자면 무한은 아니다라는 것이다.

오라클9i 의 경우 IN 절에 들어갈 수 있는 최대 조건은 1000개이다. (10g는 실험을 안해봤엉ㅋ)

1000개를 넘어서는 조건을 IN 절에 집어넣으면 예외를 뱉어내면서 수행이 안된다.

그럼 AND 절과 OR 절도 1000개일까?
그렇진 않다. AND절은 테스트 안해봤지만 OR절은 최소한 4000개까지는 문제 없었다. AND도 마찬가지일듯.

지번 쪽 쿼리를 하다보니 한 방에 1000개 넘는 지번들을 던져주는 일이 있는데
IN절로는 해결이 안되더라.

어쨋든 OR도배로 해결은 했지만... 한계가 있을 것 같은데. 한 공원에 4천개 이상 지번이 들어가는 경우는
거의 없을테니 괜찮지 싶다. 한계에 봉착하게 되면... 뭐... 그건 그 때 가서 생각하자[...]

Little Endian과 BigEndian

2009-10-05T23:53:00.000+09:00

아 씨, 밑에 캠퍼 포스팅 쓰고 잘려고 했는데... 저 포스팅 쓰고나니 포스트 개수가 44개네.[...]
그래서 하나 더 쓰고 잘려고 억지로 포스팅. 쓸 것도 없는데 -_-

리틀 엔디언과 빅 엔디언은 무엇인가?

C++ 을 이용하여 메모리를 직접 다루지 않거나 또는 네트워크쪽 프로그래밍을 하지 않는 이상
그닥 자주 접할 수 있는 개념은 아니지 싶다.(아마도)

나 같은 경우는 SHP파일의 구조를 공부하다가 알게 되었다. (SHP파일의 헤더 정보는
빅 엔디언과 리틀 엔디언이 혼용되어있다.)

여튼 이래저래 잡설 치우고 결론만 이야기하면
메모리에 데이터가 저장된 순서이다.

예를 들면 0x1234 라는 값을 메모리에 저장시킨다고 하면... 리틀 엔디언은 저 형태 그대로
저장이 된다. 즉 메모리에는 12 34 라고 저장이 되는것.

빅 엔디언의 경우는 34 12 의 형태로 저장이 된다.

우리가 흔히 사용하는 x86 인텔 계열의 CPU의 메모리 저장 방식은 빅 엔디언이다.

도스 시절에 PC머시기 툴이었더라... 여튼 그걸로 겜 세이브 파일을 조작 해 본 경험이 있는 사람은
어렴풋이 알 것이다. 능력치 123 을 수정하기 위해 찾아갔더니 23 01로 저장되어 있던 모습을 기억한다면
당신은 도스 세대.

리틀 엔디언의 장점은, 눈에 보이는데서 명확히 나타난다. 즉, 사람이 읽는 순서와 동일한 형태로 메모리에
저장이 되므로 알아보기가 쉽다. 또한, 큰 정수(Int32)에서 작은 정수(Int16) 같은 형변환 시에 별도의
처리가 필요치 않으므로 형변환시 패널티가 없다.(그냥 값의 뒷 16비트만 읽기만 하면 끝이니깐)

빅 엔디언의 장점은, 정렬된 큰 수에 대한 비교를 빨리 할 수가 있다.(큰 자릿수가 먼저 저장되니까)

여튼 포스팅 끝.

알고횽 말 듣고 급수정
: 설명이 뒤 바뀌었다. -_- 여기서 리틀로 설명한게 빅이고, 빅으로 설명한게 리틀이다.

캠퍼... 오오 괜찮네 이거.[...]

2009-10-05T23:16:00.000+09:00

스...슴가가 생겨버렸어!

머리카락도 길어졌엉!

몸매도 쩔어졌엉!

아 시발 나 어쩌면 좋냐능...

이번 달 신작이던가...? 캠퍼.

아주 그냥 대놓고 덕스럽게 만들었더만... 좋다능.[...]

정말 보기 힘든 진짜 TS물이라 관심이 가서 보기 시작. 첫느낌은 나름 괜찮은 듯.

여장남자 TS물들은 싫어서 본 적이 없는데... 진짜 성별이 바뀌는 애니가 나올 줄이야.

소설이야 TS물의 레전드인 묵향이 있다만... 애니나 만화에선 안보이던건데.

나름 괜찮은듯?[...]

C# 4.0 dynamic 이란거 신기하네

2009-10-05T00:30:00.000+09:00

뭔가 존나게 획기적이라는건 알겠다능...(루비같은 동적언어에서는 이미 쓰이고 있다고 하지만...
동적언어를 한 번도 본 적이 없ㅋ엉ㅋ)

타입 체크를 런타임에 한다는게 존나 신기함.

사실 지금 프로젝트(JSP)를 하기 이전에는 .net 2.0만 만져와서
3.5 도 잘 모르는 마당에 4.0에서 또 뭔가 큰게 추가되니 당황스럽다능...

여튼 다이나믹이라는게... 내가 이해하기로는 기존 프로그래밍이랑은 정반대의 개념인거 같은데,

기존에는 int 형 변수 a 가 있다면, a는 int형이니까 정수를 담는 변수인건데...
이게 dynamic으로 선언되면 저 관계가 반대가 되는것 같다.

즉, a 에 정수가 들어있으니까 a는 int형이다... 라는걸로 이해.

클래스 변수일때도 마찬가지여서, 해당 변수가 무슨 클래스 타입인지는 신경쓸 필요 없이
그 변수가 무슨 일을 하는지만 알면 되는... 뭐, 그렇게 할 수 있도록 해주는것 같다.

아래는 간단히 dynamic 연습용으로 만든 코드. 여튼 dynamic을 사용하면 이딴 짓이 가능해진다.

class CA
{
public void print()
{
MessageBox.Show("CA_print");
}
}

class CB
{
public void print()
{
MessageBox.Show("CB_print");
}

public void print2()
{
MessageBox.Show("CA_print2");
}
}

public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void print(dynamic b)
{
b.print();
}

private void button1_Click(object sender, EventArgs e)
{
dynamic a = 10;
int b = a;
//MessageBox.Show(a.GetType().ToString());

print(new CA());
print(new CB()); //이 두 문장은 아무 문제 없이 실행된다.
}
}

위에서 //MessageBox.Show(a.GetType().ToString());    이 문장에서 주석제거하고 실행하면
System.Int32라고 아주 정확하게 나온다. 거 참 신기할세.

호로가 졌엉... ㅠㅠㅠㅠㅠㅠㅠ

2009-10-01T00:28:00.000+09:00

설마하니 우시오한테 패배하리라곤...ㅠㅠ

작년 우승자라는 이유때문에 심심찮게 호로 견제해야 한다는 목소리가 이번 최모토 기간
내내 있었는데...

그게 결국 클라나드 진영이랑 만나면서 폭발.

엉엉 호로 ㅠㅠㅠㅠㅠㅠ

C/C++ 에서 왜 int a[100][100][100] 은 에러인가?

2009-09-30T16:13:00.000+09:00

회사 게시판에 잠시 냈던 퀴즈. 아무도 안풀더라.

#include<stdio.h>

int main()
{
    int a[100][100][100];
    return 0;
}

이렇게 하고 컴파일하여 실행시키면 에러가 뜬다. 스택 오버 플로우 에러가.
win32 환경에서 int 는 4바이트. 이걸 [100][100][100]으로 선언하였으니

4 * 100 * 100 * 100 = 400만 byte.
4000000 byte / 1024 = 3906Kb / 1024 = 3.81MB

컴퓨터에 꽂혀있는 램은 2기가.
대체 왜 에러가 나는 것인가?

이것은 사실 C 입문서만 차분히 읽어보아도 어느정도 답을 유추할 수 있는 문제이다.

메모리는 크게 두 영역으로 구분할 수 있는데 하나는 스택영역이고, 다른 하나는 힙 영역이다.
스택 영역에는 함수의 복귀 주소와 지역변수가 저장되고, 힙 영역은 자유 메모리 공간으로
new 로 생성되는건 모두 힙영역에 생성된다.

에러는 스택 오버플로우. 한마디로 스택 영역에 초과할당 하였다는 소리다. 그럼 대체
스택 영역의 메모리는 얼마인가?

win32 환경에서의 프로그램별 스택영역은 기본적으로 1메가로 할당되어진다. 1메가 스택 영역에
3.81메가를 할당할려고 하니 오버플로우 에러가 튀어나오는 것.

그럼 스택 영역은 무조건 1메가인가? 꼭 그렇지만은 않다. 컴파일 시, 컴파일러 옵션에서 스택영역의
사이즈를 지정해줄 수 있다. 그렇지만 1메가 이상의 스택영역을 사용할 일은 거의 없다.

이것에 대해 공부를 하다보면 생각보다 많은 것을 이해할 수 있게 된다.
대체 왜 C# 과 자바에서는 배열을 굳이 new 로 생성하게 하였는가에서부터(이것은 이 글을 제대로만
읽었다면 쉽게 이해할 수 있다)
지역변수가 왜 해당 함수를 벗어나면 사라지는지(스택에 저장되므로 당연히 사라지는 것이다)등등.

사실 아주 기초적인 것이지만, 많은 사람들이 모르고 넘어간다.
나도 마찬가지이다. 좀 더 기초적인 부분에 관심을 가지고, 공부를 해야할 필요성은 이런 걸 공부하면서
더더욱 크게 느껴지기 마련이다.

제우스4.2 에서 JSP파일 적용이 안될 때

2009-09-29T15:55:00.000+09:00

개발 컴퓨터에서 JSP파일의 내용을 갱신하고 그것을 제우스 서버에 덮어씌웠을 때,
분명히 파일은 바뀌었는데 실행해보면 파일을 교체하기 이전의 결과가 나오는 경우가 있다.

나 같은 경우는 컴퓨터의 날짜의 문제였다. 모종의 이유로 서버의 날짜를 되돌렸었는데,
그것 때문에 문제가 발생.

그 이후 날짜를 정상적으로 되돌리고, 컴퓨터를 리부팅 한 후, 제우스 서버를 기동시키니 문제가
해결되었다. 존내 시껍했다.

블로그 이ㅋ사ㅋ

2009-09-29T15:35:00.000+09:00

뇌이버에서 텍스큐브로 이ㅋ사ㅋ.

어차피 잘 안하는 블로그짓이지만

뇌이버가 그냥 맘에 들지 않아서

이ㅋ사ㅋ

delegate 를 string 메서드명 으로 설정하기

2009-09-29T15:28:00.000+09:00

class Schedule
{
.....
private delegate void DeleWorkSchedule();
.....

public void setSchedule(string 메서드명)
{

Type type = this.GetType();

System.Reflection.MethodInfo mi =
type.GetMethod(메서드명, System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.Public);

Delegate ds = DeleWorkSchedule.CreateDelegate(typeof(DeleWorkSchedule), this, mi, false);

DeleWorkSchedule d = (DeleWorkSchedule)ds;
d();

}

}

우왕ㅋ굳ㅋ