주연: 마리야 샤라에바/러시아, 2008년

발레리나를 꿈구는 소녀, 알리스는 바닷가에서 아빠가 오기를 기다린다. 아빠는 엄마와의 하룻밤 로맨스로 생긴 마도로스. 아빠는 절대로 올 수가 없다.

일식이 있던날, 소녀는 말을 잊어버리고 자기만의 세계로 빠져든다. 특수학교에서 자기가 소원을 바라는데로 이루어진다라는 것을 알게된다.

폭풍이 불던날, 도시로 떠나고 싶다고 생각을 했는데, 공교롭게 폭풍에 의해 마을이 다 날라가고 이재민이 되어 엄마, 할머니와 함께 모스크바로 떠난다. 학교를 들어가려고 했는데, 대기순번 1위. 들어가고 싶다고 생각하는순간 한 사람이 교통사고가 생기게 된다.

어느날 밤, 다리에서 떨어지는 남자를 구했고, 넓은 이마를 갖는 이 남자에게 사랑을 느끼고, 자기가 느끼는데로 이 남자는 이 소녀의 사랑의 대상이 된다. 

남자편 즉 샤샤는 어느날 길거리에서 소녀를 만나고, 이름도 성도 알 수 없는 소녀를 알게되고 화요일, 금요일 청소를 시키게 된다. 출장을 가러 비행기를 타러가는데, 토요일, 이 소녀가 갑자기 할머니가 쓰러져서 혼자서 감당을 못하니 도와달라고 한다. 한 창 전화를 하는 사이에 간단한 추돌 사고가 생기고, 이 덕분에 비행기를 못탄다. 이 비행기는 하늘에서 폭발. 토요일날에 왜 소녀가 자기 집에 왔고, 더우기 할머니는 왜 왔는가? 등등 의문을 품는 사이에 자기 여자친구가 오고 인어공주는 교통사고로 세상을 뜨게된다. 왕자는 인어공주가 거품이 되었는지도 모르고, 보드카와 도시의 환락속에서 세상을 계속 살게될듯하다.

영화속에서 겁나게 멋있게 담배를 피우면서 하는 대사 하나, 담배를 한 대 피우면 생명이 15분 짧아진다고, 그러나 사랑은 3분 지속이 되는듯하다.

숏다리영감..

예를 들어 네트웍 컨넥션을 맺을 때

만약 밀리세컨이 중요치 한다면, 밀리세컨을 555값을 주면, 플렉스에서 인식이 된다.

그런데 여기서 문제가 타임존 문제가 또 남는다.

즉, 닷넷에서 날짜를 잘 만들어줘도, 플렉스에서 9시간을 더하든가, 빼든가 해야한다.

2. 그렇다면, 날짜형식을 포기를 하고, yyyy-MM-ddThh:mm:ss 형식을 문자열을 주는 것으로 닷넷의 웹서비스를 바꾼다.

이것을 파싱하는 방법

창밖을 보니, 시간이 꽤 되었음직한데, 밖이 어둡다.

햇살이 조금 비치는 듯하여, 귀차니즘을 떨치고가방을 메고 캠프라인 등산신발을 묶고 지하철을 타고 독바위역으로 향하다.

김밥과 사과 한봉지를 사서 배낭에 넣고, 족두리봉을 향해가다.

가을은 북한산까지 내려와서 갈잎으로 산세를 바꿔놓고 있다.

하늘은 잔뜩찌푸리고, 바람이 세게 불고 있다.

조금 올라가다쉬고, 또 쉬고, 다섯번쯤 쉬다가 저멀리 향로봉이 보인다.

오늘 족두리봉, 향로봉 그리고 비봉을 지나 의상능봉을 돌아보겠다는 생각이였지만, 흥이 나지 않는다. 

한참을 쉬다가 흥이 돋기를 기다렸지만, 흥이 나지 않아, 발길을 되돌리다.

숏다리영감..

글을 쓰고 편집하는 에디터는 FckEditor를 사용한다. 웹 팜이 구성될 때는 이미지를 중계하는 게이트웨이를 만들어서 이미지 서버를 지원한다. 그림이 많이 올라갈 것을 대비해서 년도등으로 구별을 해서 한 폴더에 몇만개의 파일이 쌓지 않도록 하는 고민도 잊어서는 안된다.

계층형 게시판을 만들 때 답글을 어떻게 할 것인가 - 원글을 만드는 게시물을 만단위로 뛴다. 그래서 답글은 그 사이에 넣도록 한다. 게시물 숫자가 40만개를 지원할 수 있다.

게시글을 목록을 만들고 목록의 페이지네이션을 한다. 페이지 네이션을 할 때, 이 게시물의 페이지네이션을 하기 위해 전체 게시물 갯수를 알아야한다. 게시물 갯수를 무시하는 경우는, 검색같이 항상 그 결과가 달라지는 경우는 갯수만 표시하고 맨 마지막 페이지가기가 없다.

게시물 갯수가 10만건이 넘어가면 select count(*) 요따위 코딩을 하게되면, 게시물 갯수를 알기위해서 sql 서버의 CPU 시간을 1초 이상씩 잡아먹게된다. 게시물 숫자를 BBSID를 갖는 테이블에 count를 두고, 게시물이 하나 들어갈 때 마다 이 count를 넣고 뺀다. 그러면 게시물의 갯수는 이 테이블에서 읽어서 인덱스 스캔으로 찾으니 해결.

회원게시판이 있는데, 어떤 게시판은 회원이 탈퇴를 하게되면 이 게시물을 보여주지 않는 다고 하자. 클럽에 게시판이 5개가 있고 이 각 클럽에 해당하는 게시글의 카운트를 하나씩 빼면 해결

게시 목록을 30개씩 보여주고 300페이지를 조회한다고 하면, 9030개를 읽고 소트를 한 뒤 30개를 정렬해서 가지고오는데, 3000페이지가 되면 이것이 무척느리다. 게시판이 계층형으로 만들어져서 order by 뒤에 3개쯤 정렬 순서를 주니, CPU time을 진하게 잡아먹는다. 10만개 읽으니 CPU time 3000을 소비한다. 이것은 어떻게 할 것인가? 뾰족한 방법이 생각이 안난다.

혹자는 연말마다 게시글을 갈무리해서, 검색을 하면 2005년, 2006년 이런식으로 사용자에게 입력을 하도록 하는 곳도 있는데, 이것은 사용자의 편의성을 무시한 황제 프로그래머라는 생각이 들다.

 게시물이 백만개, 천만개가 넘을 때 게시물을 어떻게 일정한 시간으로 보여질 수 있는가? 고민이 된다.

파일 첨부를 만들 때는 이미 알려진 파일만을 등록하고 다운로드 받도록 한다. exe 파일 같은 흉폭한 것을 올려서 문제가 발생하면, 올리는 사람이 아니라 시스템이 처벌 받을 수 있겠다. MIME으로 알려진 문서만 등록시킨다. 첨부할 때 한글이름을 사용하면 좋은데, 이것은 표준이 없어서 깨질 수 있다. 한글 이름이 잘못될 수 있다. 훌륭하진 않지만 urlencode를 사용해서 한글 깨짐을 막아본다.

게시판을 하루면 만들겠다라는 생각이 이제는 석달은 걸리겠다라는 생각으로 후퇴하다.  주위에 게시판 만든다고 했을 때 관심도 없다가 남들 다 지나간 다음에 게시판 생각하는 것이 조금 삽질같다는 생각이 든다.

숏다리영감..