'분류 전체보기'에 해당되는 글 1246건

프로젝트 중에 사용자 로그인 관련해서 현재 시스템이 Join 되어 있는 AD 상의 도메인명을
아는 방법에 대해서 잠깐 고민한적이 있다.
특히 MOSS 내에서 사용자 관련 하여 추가 하거나, 특정 정보 중 로그인 정보를 넣어야  하는 경우 두가지 방법으로 처리했다.
한가지는 web.config 에 Application값으로 넣어버리기.
web.config에다 직접 도메인 명을 넣어, 필요할 때마다 읽을 수 있도록 했다.
다른 한가지는 코드에 직접 박아 static 변수로 만들어 버리기.
좀 후진 방법이지만.. 나름 쓰기 편해서...

그런데, 사실 위의 방법으로 할 때, 타 시스템으로 해당 코드의 포팅 작업을 할 때,
좀 귀찮긴 하다. web.config를 수정하거나 코드를 수정해야 하니까.
게다가, 해당 값을 읽어오는 메소드를 추가적으로 짜야 되니 그것 또한 짜증이였다.

이를 간단하게 해결해주는 부분이 있으니...
바로
System.Environment.UserDomainName

위의 프로퍼티를 사용하면 현재 사용 중인 AD 도메인 명을 돌려준다.

P.S. Form 인증일 때, 사용하는 Provider 이름을 가져오는 방법에 대해서는 조금더 고민해봐야 겠다.

예전에... 인디아나 존스가 들고 다니는 그 가죽 가방에 대한 묘한 로망이 있었다.
사실 그런 가죽 가방 좀 담기는 뭐하긴 했다. 통짜 가죽으로 요즘 가방 처럼 안에
조그만한 포켓이나, 지퍼 따위는 전혀 없는
그냥 통짜로 된 그런 가방이였다.

그런데, 이번에 남대문 돌아다니다, 그냥 들고다닐 만한 손가방을 찾다가,
그런 풍의 엔티크 기분이 물씬 풍기는 가방을 찾아내 그 가방을 낼름 사버렸다.
( 무쟈게 비쌌다. 웬지 사기 당한 기분이긴 하지만, 그래도 가방은 좋다. )

전체적으로 인조인지 진짜인지 모를 두꺼운 가죽으로 만들어져 있었다.
가죽 스럽게 색깔도 갈색으로 무쟈게 정감가는 색이였다.
일단 때가 더 타면 절정에 이르지 않을까 싶다.

진짜 주머니 따위는 없고, 오로지 통짜로 된 구성이라서 내부도 썰렁하다.
오로지 하나의 통짜내에 알아서 물건을 넣어야 한다. 그래도, 가죽 자체가 딱딱 튼튼해서,
걍 그럴싸하게 배치하면 물건은 크게 흔들리지 않는다.

결정적으로 나의 마음을 한마디로 가로챈 부분은 바로 잠금쇠!
요즘 뭔놈의 가방에 자석 단추들을 달아서, 비싼거든 싼거든 전부 자석으로 마무리해버렸다.
심지어는 죔쇠 같은 것을 만들어놓고, 죔쇠는 장식으로 쓰고 자석으로 마무리 한 제품도 봤다.
(게다가 명품이라고 드럽게 비싸기 까지...)

그런데 이 가방은 엔티크 하게 잠그는 부분까지 걸작이였다.
돌아가는 고리로 딱 잠그는... 게다가 잠금 쇠가 놋쇠같은 분위기 팍팍.
껍데기도 마음에 들고, 이놈의 고리 정말이지 묘한 매력을 좔좔.....

요즘 세상... 이쁜 가방, 편리한 가방, 이런것들 무자게 나온다.
하지만 난 역시 이런 엔티크 하고 심플한 가방이 좋다.!!!!
 
사실 이 가방 팔던 주인장도, 이 가방에 대해서는 거의 설명 없이 다른 천때기 가방에
지퍼 달리고, 주머니 많고, 묘한 색의 가방만을 자꾸 들이밀었다.
그래서 난, 일단 참을성 깊게 그 묘한 가방들의 설명을 끝까지 듣고, 저 가방 달라고 했다.

사용 2일째.. 너무 마음에 든다!

이제야 겨우 알았어.
숨쉬는 건, 살아 있다는 건, 정말 멋진일이야.
가끔은 울어도, 눈물쯤은, 그런 눈물쯤 은
괜찮은 거야.
이제 즐겨봐.

(말해봐) 
슬픔에 빠져 허우적 대고 있었을때,
널 만났지, 불만 많은 나 같은 사람과는
너무 다른 모습에 얄미웠지만, 넌 너무 밝았어
웃고 말았지 나도 모르게 웃고 말았어
마음을 바꿀준비가 되어있어야~만 모두 바꿀수 있어
세상을 뒤집어 놓을 바람이 불어오는 걸 느껴야돼 자신을 벗어나

이제야 겨우 알았어.
숨쉬는 건, 살아 있다는 건, 정말 멋진일이야.
가끔은 울어도, 눈물쯤은, 그런 눈물쯤 은
괜찮은 거야.
이제 즐겨봐.

(말해봐)
나도 알아, 나처럼 쉬운일이 아니라는 걸
너도 알아, 어디까지 믿어도 되는 건지.
우리모두 알지만, 한번 믿어보는거야
개같은 내인생
달콤한 인생
장미빛 인생

이제야 겨우 알았어.
숨쉬는 건, 살아 있다는 건, 정말 멋진일이야.
가끔은 울어도, 눈물쯤은, 그런 눈물쯤 은
괜찮은 거야.
이제 즐겨봐.

라라라라라~~~~~~
장~미빛 인생~~~~

보통 ASP.NET 기반의 Web Application을 개발하다 보면, DLL들을 많이 이용하게 되는데,
만일 그 DLL의 일부 코드 수정을 반영 하려면 IIS 서비스를 다시 시작해야 한다.
그래서 보통 IISRESET.EXE 라는 명령어를 이용해 아예 서비스를 내렸다가,
다시 시작하곤 한다.

그러나 단순 DLL의 로직 몇가지 변경 때문에, IISRESET을 하기에는 비용이 비쌀 수 있다.
Web Publishing에 관련 된 대부분의 서비스를 내렸다가 다시 올리는 작업이기 때문에,
Reset 하는 시간도 많이 걸리는데다, IIS를 통해 데이터를 끌어 올리는 비용도 만만치 않다.

이에 IIS 6.0 대 부터는 Application Pool 이라는 것이 있어, 그 Application Pool 만
정리해 주면 새로운 DLL로 올려줄 수 있도록 제공하게 된다.

보통은 INETMGR을 띄워 해당하는 Application Pool 에서 오른쪽 버튼을 클릭해서 재생(혹은 Recycle)을 선택하면 되는데, UI 도구를 사용하는 것이라, 조작이 좀 귀찮긴 하다.

Utility 네임 스페이스 안에 있는 수많은 Utility 중에서 또 하나 기가 막히게 자주 쓰는 도구가 있으니 바로 Encoder 다. 언어별 Encoder는 아니고, URL과 HTML에 대한 Encoder다.

간혹 HTML 내용이 있을 때, HTML 소스 그대로를 출력해주어야 할 때가 있다.
그렇다고 우리가 번역하기엔 그 내용도 만만치 않고 귀찮다. 그 때 해주는 Encoder가 아래와 같다.

string Microsoft.SharePoint.Utilities.SPEncode.HtmlEncoder(원본 HTML이 담긴 string 내용)

위의 메소드를 쓰면 < 같은 것이 &lt; 이런식으로 바꿔 주게 된다. 거기서 Encoding된 내용을 웹브라우저에서 보면 <로 바뀌어 보이게 된다.

역으로 Encoding 된 것을 바꿔주는 것이 아래이다.

string Microsoft.SharePoint.Utilities.SPEncode.HtmlDecoder(원본 HTML이 담긴 string 내용)

두번째는 URL 인코더다.
간혹 URL을 통해 GET 메소드에 사용할 값을 넘겨 줄떄가 있다. 그 때 URL 내에 이상한 문자가 들어가면 안되는 경우가 있다.
예를 들어 "http://www.hind.pe.kr/test.php?value1=크크크 호호호호&value2=I&you" 라는 URL이 있을 때 value1에는 한글 가득한데다 그 안에 공백 문자가 있고, Value2에는 I와 you 사이에 & 이라는 문자가 있다. 이러면 명백한 오류. 그러나 그 값들은 꼭 넘어가야 한다고 할때... 처리해 주는 도구가 바로 아래이다.

string Microsoft.SharePoint.Utilities.SPEncode.UrlEncoder(원본 값이 담긴 string 내용) 

저것을 사용하면 크크크 호호호호 라는 값이 #FF02#F022..... 형태로 바뀌는 것을 볼 수 있을 것이다. ( 간혹 아예 value1=크크크 호호호호 라는 것을 통채로 인코딩하시는 분들이 있는데 그건 오해이자 막가는 것이다. 크크크 호호호호 만 인코딩 해줘야 한다. )

물론 이 역함수는 아래와 같다.

string Microsoft.SharePoint.Utilities.SPEncode.UrlDecoder(원본 값이 담긴 string 내용)

하나씩 하나씩 진기로운 도구들이 숨겨져 있어서 나름 재미를 뽐내는(?) SharePoint 인것 같다.

P.S 사실 알고 보면, .NET Framework 내에서도 위와 같은 작업을 해주는 Method들이 있다.

주의 : 이 작업은 MS SQL 2005에만 해당 되며, SQL 2000 혹은 다른 DBMS를 사용중이라면 아래의 쿼리 내용을 수정/편집 해야 한다.

MOSS 2007을 유지 관리하다 보면 데이터베이스 파일 크기에 대해 주의를 기울이게 되는데, 이를 미리 파악하기 위한 쿼리를 만들어 보았다. 하지만, 절대 아래의 쿼리가 튜닝된 데이터는 아니다. SELECT 만 좀 할 줄 아는 사람이 이것 저것 문서보면서 만든 쿼리이기 때문에, 성능상 문제가 되는 경우 알아서 편집을 해야 할 것이다.

아래의 쿼리를 Microsoft SQL Server Management Studio 에서 실행한다.

CREATE table #tot_resultSize
(
name sysname,
fileid smallint,
filename varchar(500),
filegroup varchar(50),
size nvarchar(13) null,
maxsize varchar(50),
growth varchar(50),
usage varchar(50)
)
DECLARE @cmd varchar(500);
DECLARE @name varchar(255);
--SET @name = 'WSS_CONTENT_80'
--INSERT #tot_resultSize  select @cmd = 'use ' +  quotename(@name) + N' exec sys.sp_helpfile'

DECLARE DBLits CURSOR
FOR select name from sys.databases ORDER by name;
OPEN DBLits;
FETCH NEXT FROM DBLits
INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
select @cmd = 'use ' +  quotename(@name) + N' exec sys.sp_helpfile'
INSERT INTO #tot_resultSize exec (@cmd)
FETCH NEXT FROM DBLits
INTO @name
END
CLOSE DBLits;
DEALLOCATE DBLits;
SELECT name, (convert(decimal, LEFT(size, LEN(size)-2))/1024/1024) as size FROM #tot_resultSize WHERE filegroup = 'PRIMARY'
SELECT name, (convert(decimal, LEFT(size, LEN(size)-2))/1024/1024) as size FROM #tot_resultSize WHERE filegroup IS NULL
DROP TABLE #tot_resultSize

이 내용을 보면 쿼리가 두 종류가 나오는데, 위쪽 결과 물이 데이터 파일, 아래쪽 결과물이 로그 파일들이다.

위의 목록을 모두 긁어서 복사한 뒤, Excel 파일에 붙여 넣기 해서, Excel로 정리해서 보면 보고하기도 좋고, 자신이 관리 처리하기 좋을 것이다.

코딩 습관이라는 것은 다들 개인적인 사상이 있고, 개인적인 취향이 있기 때문에,
무어라 따지기 힘든 것이 있다.

사실 내가 작성한 코드도 1달 정도 지나면 어느새 비판하고 싶은 내용이 많은 코드로 변해가고
스스로 짜증을 내며 나름대로 리팩토링을 한다.

왜 이런 생각을 가지고 쨨냐,
그것 말고 이미 다른 이들이 구현해 놓은 것은 없냐,
좀 더 효율적으로 처리하는 방법은 없냐,
코드의 길이가 너무 길게 되어 있지 않냐,
변수 이름이 알아보기 힘들지 않냐,
함수 이름이 알아보기 힘들지 않냐,
디버깅 하기에 어려울 정도로 너무 한줄에 다닥 다닥 붙이지 않냐, 등등..

그런데 그 중에서 내가 제 1 로 치는 최악의 코딩는

  같은 로직의 같은 코드를 계속 반복해서 넣은  코드

이다.

일단, 수정을 하나 할때, 미묘하게 변수 이름 하나만 달랑 틀린 코드가
반복해서 나열되어 있으면, 코드도 길어지고 복잡해지고,
수정하나 할때 그 반복된 만큼 수정하고...

특히나 단순 반복 작업을 제대로 못하는 나에게는 지옥과도 같은 코드다.
( 똑같은 것 반복 되어 있으면 내가 어디까지 수정했는지 까먹는 스타일...)

사실 단순 반복 작업은... 컴퓨터가 하는 것이라고 생각하는 나로써는 진짜 돌아버릴 코드다.
지금 그 단순 반복 작업을 유도하는 코드를 수정 중에... 짜증나서 쓴다.