add-in 디버깅

어쩌다보니 엑셀 add-in을 만들어 볼 기회가 생겼는데
내가 만든 add-in이 load 되는 시점에 에러가 발생하는 경우 디버깅이 힘들더라.

그래서 여기저기 찾다보니 두가지 괜찮은 방법이 있어 정리


1. 환경변수를 추가
VSTO_SUPPRESSDISPLAYALERTS 추가
값은 0으로 설정

그러면 add-in에서 발생한 에러를 alert 해줌..


2. 레지스트리 편집
HKLM\SOFTWARE\Microsoft\Fusion에
다음과 같이 추가
DWORD 타입으로 EnableLog 추가, 값은 1
DWORD 타입으로 ForceLog 추가, 값은 1
DWORD 타입으로 LogFailure 추가, 값은 1
string 타입으로 LogPath 추가, 값은 원하는 경로(예, C:\Fusion)

이렇게 하면 add-in에서 발생하는 에러에 대해서 C:\Fusion\Default 하위에 Application 이름으로 폴더가 생기고
html 형태로 에러가 로깅됨..


자 이제 디버깅을 할 수 있으니 문제를 해결하면 됨..

by 언이 | 2011/01/27 15:51 | IT/개발 | 트랙백

신용/체크 카드 신청기

모 카드사에 신용카드 하나와 체크카드 하나를 발급 받으려고 온라인으로 신청을 시작했다.
카드사 사이트에서 카드를 검색하는 짓은 번거롭기 때문에
네이버에서 검색~

분명 체크카드로 검색했고 최상단에 나오는 링크를 따라가서 신청완료
룰루랄라 하고 신용카드도 연이어 신청~

여기서 문제 하나.
내 기존의 정보(직장주소 등등)와 신청 정보가 달랐는데
신청하는 내용으로 내 정보를 바꿀 수 없어 귀찮긔
(그렇다고 개인정보 변경 페이지까지 일일이 찾아가서 고치기는 더 귀찮긔)

마눌님의 요청으로 이루어진 카드 발급이라 완료보고 올린 후 문제점 발견.
내가 신청한 체크카드는 알고보니 걍 신용카드였던 것!!
이건 네이버의 삽질인가? 카드사의 삽질인가?
키워드 검색도 제대로 못하다니...

게다가 일반 신용카드는 교통카드 기능 여부를 확인할 수도 없고
체크카드는 교통카드와 비교통카드로 아예 신청 이전 단계에서 선택해야하고
(개념적으로 카드를 선택한 후 기능을 선택해야 하는 것이 아닐까?)
카드 신청이 완료되면 내가 신청한 정보를 조회조차 할 수 없었다.

뭐... 이건 모 카드사의 사이트가 거지같기 이를데 없어 그런 걸로 생각할 수 있겠지만
이런저런 삽질과 정보를 추적해 보겠다고 아까운 1시간여를 허비해야 했던 것이다.
(내가 멍청한걸까? 나 늙은거야? ㅜㅜ)

그 외에도 자잘한 불필요한 정보들로 인해 혼란을 주는 문구들이 수두룩했지만
카드 신청내내 짜증이 넘쳐났기 때문에 더 나쁘게 느꼈을수도 있으니 패스..

여튼 마눌님의 미션은 완료했지만 왠지 모를 찜찜함이 밀려오는구나..

결론..
다시는 카드 신청 따위 하고 싶지않군.
혹여 카드 신청을 해야한다면 고객센터로 전화를 해야겠다;;;;;;

by 언이 | 2011/01/19 16:18 | 일상 | 트랙백

로이스터를 위하여..

로이스터를 위하여

글 쓰신 분이 나랑 연배도 비슷하고
모태꼴빠인 것도 똑같고.. 그러네..

이상하게 이기고 병신같이 지던 롯데를
여전히 병신같지만 가을에도 야구하게 해준 로이스터를
더 병신같이 보내버려야 하는 마음이 안타깝다.

만약 김재박이 오면 홍성흔은 타격왕이나 해라.
그 이상은 기대 안된다.

by 언이 | 2010/10/15 11:08 | 일상 | 트랙백 | 덧글(2)

SQL Server에서 Connection Pooling의 장점

1. SQL Server connection overhead를 감소시켜 준다.
데이터베이스와의 연결 과정 자체가 비용이 큰데
풀링을 통해 커넥션을 재활용하니까 당연한거고..

2. 데이터베이스 성능에도 도움을 준다.
DSN을 통해 SQL Server와 커넥션을 맺을 때,
기본적으로 MDAC 드라이버는 동적 T-SQL을 SQL Server의 임시 저장 프로시저로  변경한다.
임시 저장 프로시저는 Tempdb에 저장되는데
커넥션 풀링을 하지 않으면 커넥션이 새로 연결될 때마다 Tempdb에 필요한 임시 저장 프로시저를 새로 생성하게 된다.
임시 저장 프로시저의 생성은 파싱과 컴파일의 비용이 소모되기 때문에 비용이 발생하고
불필요하게 임시 저장 프로시저를 계속 만들어야 하므로 SQL Server의 성능에 악영향을 끼치게 되는 것이다.

두 번째 이유는 별로 생각안해봤는데
보다보니 나와서 정리.

by 언이 | 2010/09/02 15:07 | IT/개발 | 트랙백

스트록시 시선은 어디를 향할 것인가?

네이버 카페에 유사한 질문이 올라왔길래 고민을 해본다.

1. 수구를 본다.
2. 1적구를 본다.
3. 수구의 진행방향(이하 라인)을 본다.

먼저 수구를 본다함은 수구의 당점을 보는 것을 의미할 것이다.
당점을 보고 친다는 것은 스트록이 불안정하여 시선을 당점에 고정시키지 않으면 정확한 당점을 공략하지 못한다는 의미일 것이다.
혹은 이미 엎드릴 때 큐선의 진행방향이 확고하고 수구의 진로가 정확하기 때문에 당점에만 집중하면 된다는 의미일 수도 있다.
개인적으로 자세가 불안정한 날(웨이트로 인해 팔이 떨린다거나 등등)에는 이 방법을 쓴다.
대신 당점에 집중하다보니 스트록 미스가 발생할 확률은 그만큼 올라가는 것도 느낄 수 있다.

다음으로 1적구를 본다함은 두께를 본다는 것을 의미하는 것으로 생각된다.
사실 나는 이 표현은 완전히 잘못된 표현이라고 생각한다.
1적구를 본다는 것은 일단 빈쿠션을 완전히 배제한 표현이고
커브나 스쿼드로 인해서 오조준을 해야할 경우 수구의 진행과 내 시선을 일치시키지 않아도 된다는 가정을 하고 있다.
그리고 두께라는 것은 공 하나를 가지고 형성되지 않는다.
두 개의 공이 있어야만 두께라는 것을 만들어낼 수 있고
그러려면 수구의 진행을 알아야 한다.(수구의 라인을 수구 지름만큼 확장했을 때 1적구에 충돌되는 면이 두께다.)
멈춰있는 1적구와 이동하는 수구 중 컨트롤이 힘든 것은 당연히 수구이다.
그런데 1적구를 보고친다는 것은 아무래도 잘못된 표현이 아닐까 싶다.

마지막으로 라인을 보고 친다는 의미는 좁게는 수구가 1적구까지의 진로를 보는 것이고
넓게는 득점을 위한 진행 전체를 보는 것이라고 볼 수 있다.
하지만 여기까지 확장을 하기에는 시선처리의 범위를 넘어서는 것 같고..
좀 더 시선에 집중에서 의미를 찾아보자면 큐선과 수구의 진행방향이 일치되었다고 가정할 때
큐선의 연장선이 바라보는 테이블 쿠션의 포인트를 바라본다고 봐도 무방할 듯 하다.
이 경우 몇 가지 이득이 있는데
1) 수구의 포인트를 정확하게 계산할 수 있다.
2) 1적구의 두께를 정확하게 공략할 수 있다.
3) 1적구의 두께로 인해 1적구와 수구의 분리각을 정확하게 계산할 수 있다.

물론 내가 3번의 경우로 시선처리를 하기 때문에 높은 점수를 주는 것일 수 있다.
나름의 방법으로 최선의 득점루트를 찾아내고 확률을 올린다면 사실 시선을 어디에 두거나 큰 의미를 두기는 힘들 수도 있다.
하지만 간만에 재미있는 주제에 대해서 얘기할 수 있는 기회가 되었기에
스스로 정리를 해보고자 글을 남겨본다.

PS. 그나저나 난 스트록 연습을 좀 더 해야하는데..

by 언이 | 2010/06/29 15:19 | 당구 | 트랙백

◀ 이전 페이지          다음 페이지 ▶