박종명의 아름다운 개발 since 2010.06

아이들, 학생들은 흔히 말한다

내가 크면...

그리고 어른들은 흔히 말한다

내가 조금만 더 어렸다면...

지금 이 순간.

인생의 전체 획이 아닌, 현재 주어진 환경에서도 "만일 XXX 하다면..."을 부르짖고 있는 건 아닌지 반성해 본다

사이트에 보면 별 다섯개로 평점을 부여하도록 하는 곳이 많다.

총 5개의 별 중 1~5 까지 별을 선택해서 평점을 주게 된다.

이렇게 평점을 준 사용자들의 모든 점수를 합해서 평균을 내면 소수점 평점이 나올 수 있다

그리고 요즘 대부분의 사이트에서는 이런 소수점까지 고려해서 UI에 표시해 준다

다시말해,

대략 평균 평점이 4.2 점이라면 아래 그림과 같이 다섯번째 별표에도 그 비율만큼 색이 채워지도록 한다.

갑자기, 이런 표현에 대한 UI 구현이 궁금해졌다

편하게 구현하려면 어떻게 해야 할까?

만일 소수점을 무시하고 반올림하거나 절삭하는 거라면, 총 두 개의 별표 이미지(주황색, 회색)만 있으면 되고 평점에 맞춰 노출하면 그만이다.

그런데 여기서는 평점의 소수점까지 고려해서 별표 이미지를 그 비율로 채워줘야 한다.

그래서...

CODE PROJECT의 평점 부분을 살펴 봤다

아래 그림처럼 평점이 4.21이다.(이런 세심한... 소수점 두 자리씩이나... ㅡ.ㅡ;)
그리고 별표 이미지 중 마지막 별표를 보면, 대략 0.21의 비율만큼 채워져 있다

이제 소스를 보자. 아래 그림은 별표 이미지와 크롬 개발자 도구로 본 HTML 코드이다.

별표가 다 채워진 이미지와 그렇지 않은 이미지, 총 두개의 이미지를 사용하고 있다. 각 이미지의 너비는 139px이다.

 이 두 이미지를 차례로 선언하여 겹치게 하고, div 요소의 너비(width)와 적당한 CSS로 처리한 것을 확인할 수 있다. 각 너비의 산출은 이미지 실제 너비 크기에 대비하여 총점 비율로 계산하면 쉽게 낼 수 있다

이 코드에서는 총 이미지 크기(139px) = 채운 이미지(124px) + 빈 이미지(15px)로 조절되었다

거의 2주 간격으로 도서관에 간다.

책 대여 기간이 최대 2주이기 때문이다.

한번 가면 두 권을 빌린다.

어떨땐 3,4권도 한번에 빌려봤는데, 욕심임을 깨닫고 두 권씩 빌려온다.

그런데 두 권째 책은 꼭 다 못 보고 반납하게 된다.

대략 2주에 책 1.5권인 셈이다.

따지고 보면 일주일에 책 한권을 못 본다는 것이, 바쁜 일상만을 탓 할게 아니란 생각이 든다.

지금.. 이순간... 토요일에 반납 예정인, 다 보지 못한 두 권째 책을 봐야 겠다...

현재 카테고리에 맞지 않는 영역이지만....

관리도 안될게 뻔한 카테고리를 새로 만들고 싶지 않아 ASP.NET MVC 카테고리에 꺼적인다

ASP.NET MVC로 DB 관련 개발할 때,

EntityFramework 나 LING to SQL을 사용하곤 한다

근데 이 두 넘은 다 좋은데, 저장 프로시저의 다중 결과 셋을 지원하지 않는다.

음.. 지원하지 않는다기 보다는 자동으로 생성되는 designer.cs에만 의존하면 그렇다고 해야 정확한 표현인 듯 싶다.

예를 들어,

게시판 글 보기 페이지일 경우, 글 내용과 해당 글에 대한 댓글 정보를 하나의 프로시저에서 두 개의 결과 셋으로 반환하도록 할 경우 처음으로 반환된 결과 셋이 자동으로 바인딩 되는 것이다

물론 이런 상황이라면 글 내용은 OUTPUT 변수로 받고 댓글 리스트는 결과셋으로 받아서 해결 가능하다. 실제로 이렇게 사용한 적이 꽤 많다.

그러나 문제는 정말로 리스트형태의 결과 셋이 여러 개일 경우이다. 이젠 더 이상 OUTPUT 반환 값에 의존할 수 없게 되었다.

저장프로시저의 시나리오는 대략 이렇다.

1. OUTPUT 변수로 몇 가지 값을 반환한다

2. 3개의 결과 셋(레코드 셋이라는 표현을 좋아하는 사람이 있다)도 같이 반환한다

그러니깐, 의미적으로 총 3가지 형태의 결과값을 받고 싶은 게다

(OUTPUT 반환 값 + 결과셋1 + 결과셋2 + 결과셋3)

물론 결과셋의 개수는 중요치 않다. 두 개 이상의 결과셋을 반환한다는 게 중요하다

이제 이 프로시저를 LINK to SQL로 연동해서 결과를 처리하고 싶다

먼저 desiner.cs 가 자동 생성한 아래의 코드를 보자

매우 복잡한(?) 코드에 의미 두지 말자. designer.cs 가 자동 생성해 준 코드를 그대로 옮긴 것이니..

그리고 저장프로시저의 원형에 의미도 두지 말자. 그냥 대충 다중 셋을 반환하는 저장프로시저라고 생각하면 된다. 중요한 것은 ISingleResult를 반환한다는 점이다. 그래서 다중 결과 셋의 첫 번째 결과만 바인딩 되는 것이다.

그렇다면 해결책은 ISingleResult가 아닌 다중 셋을 반환할 수 있도록 IMultipleResults을 반환하면 된다.

이를 위한 새로운 메서드를 정의해야 하는 데, designer.cs가 자동 생성한 클래스를 사용할 생각은 말아야 한다. DB 연동이 추가/제거/변경 될 경우 이 클래스는 다시 생성되기 때문에 자신의 코드가 모두 사라질 수 있기 때문이다.

그렇기 때문에 파티셜 클래스 기법을 이용하면 된다.

designer.cs가 생성한 클래스와 동일한 이름으로 파티셜 클래스를 선언하고 다중 셋을 반환할 수 있도록 다음과 같이 작성할 수 있다

자동생성된 이전의 코드와 거의 유사한 것을 알 수 있다

다른 점이라면 IMultipleResults 타입을 반환한다는 점과, 다중 셋의 결과를 자동으로 바인딩 하기 위한 클래스 선언이 있다는 점이다.

LINQ to SQL을 사용하면서 다중 결과 셋에 대한 목마름이 있었던 사람은 위의 코드만으로도 그 즉시 적용가능하리라 본다.

잃어버린 줄 알았던 필통을 찾았다

지난 주, 필통을 뒀을 만한 모든 곳을 샅샅히 뒤져 봤지만 찾을 수 없었다

내 방 책상과 사무실 책상, 그리고 차안...

있을 만한 곳을 모두 뒤진 후... 잃어버렸구나 하며 안타까워 했다

오늘 아침, 가방에서 뭔가를 꺼내려다, 가방 밑에 깔려 있는 필통을 발견했다

이건 뭐... 멍하니.. 덤덤하니.. 여기 있었네.. 한다...

왜 가방안을 뒤져볼 생각을 하지 못했을까?

어쩌면 많은 문제들의 해결책도, 이처럼 의외로 단순한 곳에 있을지 모른다는 생각으로 미화시켜 본다 ㅎㅎ

필통이 주는 교훈!!!  - 2012.11.05 오전에 사무실에서...

MVC 기반의 사용자 화면에서는 다중 입력 폼(form)을 허용한다.

사실 허용한다기 보다는 일반적인 HTML 페이지의 동작을 그대로 수용한 것이다

이전 개발 환경인 ASP.NET WebForm에서는 서버 측 폼을 기반으로 작업을 많이 했으며 한 페이지에 오직 하나의 서버 폼이 존재할 수 있었다

MVC환경에서는 서버 측 폼이라는 개념을 사용하지 않기에 (일반적인 HTML 규칙과 같이) 다중 폼의 사용이 가능한 것이다.

그리고 MVC에서는 폼 입력에 대한 유효성 체크와 유효성 메시지 노출을 자동화 시켜 주는 편리한 기능도 있다

그런데 이 둘(다중 폼 & 유효성 체크)을 조합해서 사용하다 보면, 의도치 않는 결과를 만나곤 한다

예를들어, 다중 폼 환경에서 특정 하나의 폼의 유효성 체크가 다른 폼의 유효성 체크와 통합되어 표시되는 현상 같은 것이다.

두 개의 폼의 입력 필드 이름을 다르게 해서 각각의 입력 컨트롤의 유효성 실패 표시는 쉽게 구분할 수 있으나

@Html.ValidationSummary와 같은 유효성 메시지를 각 폼에 독립적으로 사용하고자 할 때는 기대처럼 동작하지 않는다. (파샬뷰로 분리된 다중 폼이라고 해도 결국 하나로 합쳐지기 때문에 현상은 동일하다)

이에 대한 솔루션을 제공하는 아티클이 있다

ASP.Net MVC: Validation a on page with multiple forms

간단하게 설명하자면,

필드 이름을 폼 마다 (접두어를 두어) 구분하고, 사용자 정의 HtmlHelper를 만들어서 자신의 이름과 일치하는 폼에 대해서만 유효성 체크 Summary(ValidationSummary)를 반환하도록 한 것이다. 그리고 뷰에서는 이 사용자 정의 HtmlHelper를 통해 유효성 메시지를 표시하도록 한다.

이러한 접근 방식이 마음에 들지 않는다면, 다음과 같이 설계 할 수 있겠다

1) 다중 폼을 사용하지 않기

2) 다중 폼을 사용하되, MVC 유효성 체크에 의존하지 않기

3) 위 아티클의 방식을 나름 응용해서 사용하기

(입력 폼에 자동 모델 바인딩을 사용할 경우, 입력 필드 이름에 의존적이기 때문에 필드 이름을 변경하는 게 불편할 수도 있다)

힘드셨겠어요... ㅠ.ㅠ

부산 본가 거실 창을 통해 본 바다 풍경...

언젠가부터 부산은 그리운 도시가 되었다. 항상 다녀오면 나 자신을 다시 되돌아 봐야 한다는 생각이 들게 해 준다

다시 일상으로 오면 그 마음이 점차 퇴색되는 것을 반복하지만 이제 기록하고 연습하기로 했다

저 넓은 바다와 같이 내 마음도 평안하고 넓어졌으면 하는 바램이다

국립중앙박물관에 비치된 조선시대 책으로, 시경을 풀이한 해설책이라고 한다

시경은 중국 고대의 시를 모은 책으로, 오경중의 하나이다. 사서오경은 과거 공부의 핵심 교재였다.

이 책에는 밑줄을 긋고 방점을 찍으며 공부한 흔적이 남아 있어 옛 선비들의 공부 모습을 짐작할 수 있다. - 국립 중앙 박물관

옛 조선시대 선비의 공부 흔적인 남아 있는 책을 보니 묘한 느낌이 들었다

그 시절 이 책에 밑 줄을 그으며 공부한 선비의 환경, 생각, 느낌들이 수 백년이 지난 후 박물관에 서 있는 나에게 전달되는 듯 하여 말로 형용할 수 없는 감정을 느끼게 되었다

이렇듯 과거는 어떠한 매개체를 통해 미래로 연결되는 듯 하다

짐승은 죽어 가죽을 남기고 인간은 이름을 남긴다 했는데,

꼭 이름이 아니러다로 어떠한 흔적이라도 남기는 것이 좋은 것 같다

지난 밤, 하얗게 뜬 눈으로 보냈다

오랜만에 찾아온 완전에 가까운 불면의 시간과 지겨운 사투를 벌였다

시계를 보기가 두려워, 참다 참다 보게 된 시간이 오전 5시...

얼마 후 창밖으로 날이 밝아 오자, 짜증이 밀려 들었다

참을 청하려 자세를 수 차례 바꿔보기도 하고, 꼬리에 꼬리를 무는 생각의 끈을 끊으려 해 봤지만 무용지물!

11시 넘어 먹은 홍삼액이 문제였던지.. 10시 넘어 1시간 가량 탄 자전거가 문제였던지.. 9시까지 이어진 업무에 대한 고찰이 문제였던지.. 이렇게 완전한 불면이 오다니...

이 아침, 몽환적인 몸과 마음으로 일을 시작한다 ㅎ

확실히 컨디션이 안 좋으면, 자전거 탈때 오르막이 훨씬 힘들게 느껴지는 듯 하다

그래도 자전거 출근의 신선함을 놓기 싫어 무거운 몸을 가벼운 자전거에 실어 왔다

점심시간에 잠시 낮잠을 청해야 겠다

열심히 커뮤니케이션즈라는 곳에서 희망메시지라는 제목으로 2012 남은 휴일을 정리해서 메일로 보내줬더군!

총선 임시휴일은 지났고...

음.. 5월은 어린이 날이 토요일이랑 겹쳤지만 이틀의 휴일이 있구먼. 6월은 하루.

이런! 7월은 달력만 봐도 무미건조하구만. 8월.. 그렇다 치고

9월 추석.. 이런 줸장.. 토,일요일이 다 겹쳤어?? 미쳐...

달력 밑에 달린 코멘트들이 성질 부추기지만 익살 스럽군.. ㅎ

'아무나 하면 된다'에 아무나가 과연 누구일까?

프로젝트를 진행하다 보면 특정 그룹에 업무를 부여할 때가 있다.

근데 그 그룹에 특정 1인을 지목하기가 애매한 경우 그룹 전체에 부여하게 된다.

그러나 그 일은 한 사람이 맡아서 하면 될만한 일일 경우 간혹 다음 공식으로 귀결되는 경우가 있다

"아무나 = 아무도"

즉 아무나 하면 된다는 것은 아무도 하지 않는다는 씁쓸한 결과이다.

초등학교때 교과서에 이런 글이 기억날 것이다.

어느 화목한 가정에서 아버지가 가족이 모두 모인 저녁 시간에 바지 밑단을 좀 잘라 줬으면 하고 부탁했다. 그날 밤 엄마는 물론이고 자식들도 스스로 자신이 솔선수범하여 그 일(바지 밑단을 자르는 일)을 해 버리는 바람에 아침에 아버지는 반바지가 되어 버린 바지를 입어야 했다. 이 일을 자랑스럽게 여긴 아버지는 옆집 아저씨한테 이 말을 하자 그 옆집 아저씨도 자기도 한번 가족을 테스트(?) 해보 싶어졌다.

 

옆집 아저씨도 가족이 다 모인 저녁에 바지 밑단을 잘라 줬으면 하고 부탁했다.

다음날 아침, 설레이는(?) 맘으로 바지를 입어 봤더니 바지는 여전히 길게 축~ 늘어져 있던게 아닌가. 옆집 가족은 일종의 화목하지 않은 가정의 사례로 '누군가 하겠지' 하고는 다른사람에게 떠 넘긴 것이다.

이 이야기는 가족의 화목이라는 주제를 다룬 것이지만 여기서도 '아무나=아무도' 현상이 보이는 것이다.

프로젝트를 진행하다 보면 모든 팀이 한 가족처럼 화목(?)하지는 않다. 화목하지 않은 근원 이유를 제거하는 것이 가장 좋지만 여기서는 그러한 원론적인 해결을 논하려 하는 것이 아니다.

'아무나' 라는 애매한 설정이 결국 아무도 하지 않는 현상에 초점을 맞추려 한다.

심리학에 보면 '다수의 무지'라는 것이 있다.

수십명의 목격자가 지켜보는 가운데 처참하게 살해된 살인 사건에서의 교훈으로 '모두의 책임은 아무의 책임도 아닌 상태'가 되어버린다는 것이다. 그래서 위험한 상황이 발생하면 그냥 '도와 주세요'가 아닌 '그기 누구 나 좀 도와주쇼!'가 되어야 한다는 것이다.

특정 그룹이지만 특정인이 하면 되는 일은 그 일을 할 사람을 분명하게 지목해 주는 것이 좋다.

물론 위의 화목한 가정처럼 "아무나 = 전부다"의 공식이 성립하는 분위기라면 (바지 밑단이 과도하게 잘린 사소한 실수를 제외하고는) 더할 나위 없이 좋겠지만 우리네 프로젝트 환경이 꼭 그렇지는 않다는 것이다.

누구를 탓하기 이전에 좀더 정확하고 명확한 업무 부여가 필요하며 나아가 프로젝트에 참여하는 모든 구성원이 스스로 솔선수범하여 일을 척척 해 나가는 것이 중요하다.

그것이 프로젝트의 재미이지 않겠는가...

블로그 정체성을 재정립 할 시기가 온 것 같다.

2010년 6월 KTH의 차세대 게임 플랫폼단으로 입사하면서 맡게 된 모바일 관련 프로젝트의 온라인 노트 용도로 첫 개설한 이 블로그(당시 블로그 이름은 '모바일 플랫폼 프로젝트 노트' 였다)는 프로젝트의 방향성이 바뀌면서 좀더 추상화시키고 실명을 이름에 포함시키는 것으로 변화를 한번 주었다.

=> 블로그 실명제!!!

그로부터 약 2년이 좀 못되는 시간 동안 개인적으로 많은 변화가 있었으며 더 이상 블로그의 기존 이름에 걸맞는 글만을 작성하기가 힘들어졌다. 직무는 보다 추상화되었으며 개인적 역량 개발 분야도 조금의 변화가 필요하며 큰 틀에서의 관심분야는 여전히 동일하지만 그것을 이뤄내는 과정의 측면은 좀 더 다양해 졌기 때문에 블로그 정체성을 더 추상화할 필요성이 생겼다.

새술은 새부대에... 라는 관점에서 새로운 블로그를 만들까라는 생각도 해 보았지만, 글쎄올시다...

나의 관심분야, 직무 수행 분야가 큰 틀에서는 몇 가지로 나눠질 수 있겠지만 결국 나 하나에서 가지를 치는 것이라면 굳이 블로그를 나눌 필요가 있을까 하는 의문과 과거에 새롭게 만든 몇 개의 블로그(사이트)를 관리해 본 경험상 오히려 관리, 사용에 혼란이 있음을 느꼈기 때문이기도 하다.

모바일 플랫폼과 진보하는 웹에는 여전히 관심이 지대하며 추가로 예전부터 사랑해왔던 '닷넷' 그리고 주요 직무 분야인 프로젝트 관리와 관련된 개인적 로그(Log)를 여기, 하나의 블로그에 담아 나갈 예정이며 이러한 블로그의 정체성에 비추어 보면 기존 이름은 더 이상 어울리지 않는다는 결론이다.

블로그의 정체성과 이름이 무에 그리 중요하겠냐 하겠지만, 이것은 누구를 위한 것도 아닌 나 자신을 위해 꽤 중요한 작업이라 본다.

'박종명의 IT Log', '박종명의 개발자의 느린 걸음' 등 몇 가지 생각해 봤는데 직접적인 의미 전달은 꽤 적절하지만 맘에 들지 않는다. 뭔가 스스로의 자극이 필요한 듯 나에게 주는 신선한 느낌이 필요했다.

그래서 더 많은 고민 없이, '박종명의 아름다운 개발'로 결정했다.