Seorenn

요즘 노무현 전 대통령 서거와 관련한 음모설, 일명 시해설이 떠돌고 있다. 일단 얼핏 봐서는 거의 맞아 떨어지는 말 같아서 더 화제가 되는 내용이다. 검/경/정 이런 곳에선 물론 이런 설이 퍼지는 것에 경계하고 있겠지.

우선 개인적으로 음모론은 조심하자는 주의이다. 이런 음모가 있지만 이걸 그대로 기정사실로 받아들여선 안된다는 이야기다. 사실이 아닌 내용이 기정사실이 되어버린다면 돌아가신 노 전대통령은 어떻게 생각하실까 말이다. 어쨌든 재미삼이 음모론을 거론하는 건 문제될 게 없다. 그러나 그걸 기정사실화 하지 말 것, 그리고 루머일 수도 있다는 것을 확실하게 밝힐 것.

검찰이든 경찰이든 이런 음모론이 나왔다면 이게 맞다 틀리다 라는 걸 빨리 해명해야 할 것이다. 그냥 허위사실이니 무근이니 그러고 딱 잘라 버리면 역효과가 생긴다. 음모론이 더 퍼질거야.

더욱 중요한 것. 해명에는 증명이 필요하고 증명에는 증거가 필요하겠지. 즉, 객관적으로 이해가 가능하게 해명하라는 말이다. 그리고 전부 캐 내려고 하지 말고 밝혀진 것이 하나라도 있으면 단 하나라도 빠르게 해명을 해야겠지? 그래야 음모론의 항목이 점점 사라지니 음모론의 힘이 약해질 거라고 생각한다.

음모론의 확산은 이런 대응이 아니고서야 풀릴 수가 없다. 설마 또 검열로 잡아들이려고 할까. 허위사실 배포 혐의로 잡아 쳐 넣으려고 할 까봐 걱정된다. (현재 정부는 이런건 서슴없이 할 것 같다는 느낌)

그런데 만약 해명을 못 한다면 어떻게 하지? 음모론이 퍼지는 것 보다도 더 무서운게 해명을 못 하는 것이다. 그렇게 되면 이미 퍼진 음모론은 더 크게 팽창에서 여기저기 난리가 나겠지?

한동안 눈에 띄지 않아서 사라진 줄만 알았던 DMB의무탑재건이 아직도 공중을 빙빙 돌고 있나보다.

휴대폰 DMB 의무 탑재 추진? "없던 일로…":

요약하여, 단말기가격 인상 및 소비자 선택권 침해 사유로 안된다라는 방통위 의견, 그리고 이로 인해 도산 위기의 DMB업체들한테는 별로 안좋겠지 라는 내용이다.

소비자인 개인 입장에선 당연히 DMB의무탑재는 말도 안되는 이야기다. 그런데 아직도 거록되고 있다. 무슨 생각으로 이런 안을 검토하라 시킨건지 대한민국 대통령이라는 이명박의 의도가 지금까지도 계속 궁금하다.

DMB업체의 고난은 수요를 예측 못 하고 난립한 업체들의 문제이니 운명으로 따라야 할 것이다. 소비자 입장에서 이런건 챙길 필요는 없다. 기사의 의도가 뭔지는 모르겠지만 일반 소비자를 위한 기사는 아닌 것 같다.

여론은 분명 'DMB의무탑재'에 반대하는 의견이 많다고 느낀다. 실제로 인터넷 등에서 이에 찬성하는 글을 읽어 본 적이 없다. 거의 반대하는 이들이 대부분이지 않을까. 그런데 왜 아직도 결정을 못 하고 있는 건지 답답하다. 얼른 결정 좀 내려보시오. 느려터진 분들. (업종에 따른 개인적인 이야기 하나 더, 그 따위로 느긋하게 일 처리하면 이 계통에선 굶어죽기 딱이다. 알간?)

지금까지 반말로만 쭈욱 써 오던 블로그였지만 노 전 대통령께 한해서만큼은 도저히 반말을 쓸 수가 없습니다. 그 분이 죄를 지었던 짓지 않았던 사실이 무엇이든 간에, 존경하던 분이 생각지도 않았던 행동을 하셔서 충격을 심하게 받았습니다. 하지만 지금은 다른 말을 할 수는 없을 것 같네요.

부디 편히 쉬시길...

IT밸리에 프로그래머 면접으로 부터 촉발된 문자열 뒤집기 및 관련된 포스팅들. 재미있다. 오랫만에 정말 프로그래머들 끼리 놀 만한 주제가 아닐까.

재미있는건 약간 집어치우고, 내가 면접관이라면 실무면접(?)을 이런 식으로 해 보고 싶다.

1. 대충 아무 문제나 낸다.
   
2. 커피 한잔 마시고 오면 대충 풀었겠지.
3. 답안지를 보자. 단, 그냥 대충 보자.
   
4. 코드가 잘 돌아가는지 문법 에러는 없는지 등은 신경쓰지 말자. (pseudo 수준으로 봐야겠지)
   
5. 코드를 이해하지 말고 대충 면접자에게 물어보자. '이 코드는 왜 이렇게 짰어요?'
6. 응답자의 대답을 듣고 코드가 제대로 이해되는지 생각해보자.
7. 면접자의 설명을 듣고 코드의 목적과 방법이 이해가 된다면 실무에선 합격선이라고 판단하자.
8. 코드 동작에 문제가 있을 것 같다면 그 문제를 찾을 수 있는지 물어보자.
9. 문제를 찾아서 해결하는지 확인해보자.
10. 해결했는가?
11. 난해한 코드라면 난해하다고 이야기 해 주고 그 내용을 이해하는지 확인해보자.
12. 이해했는가?
13. 나이스 가이~~~~
    

- 이 사람이 처음 제출한 답이 틀렸다고 하더라도 이 사람은 충분히 발전할 가능성을 가지고 있다. - 라는 판단 방법으로 이런식의 생각을 해 봤지.

실무에 있어서 이해하기 좋은 직관적인 코드를 짠다면 정말 좋은 프로그래머 라고 생각한다. 하지만 경력이 많아야 그게 가능하겠지 대학이나 대학원 갓 졸업한 이들을 대상으로 그런것까지 요구하기엔 세상에 사람이 너무 없을 것 같다. (학교 다니면서 이것 저것 다 해본 베테랑급 프로그래머라면 이런거 신경 쓸 필요도 없겠지)

그렇다면 단순하게, 그 사람이 만든 코드가 막상 보기엔 난해하더라도 설명을 통해(혹은 주석을 통해) 이해가 가능할 정도의 코드를 만든다면 그 사람은 여러 사람들과 프로젝트를 진행하는 능력의 기본은 된다고 생각한다.

문제의 답이 틀렸냐 맞냐를 크게 따지는 건 중요한 걸 놓치는 거라고 생각한다. 문제를 발견하고 발견한 문제를 고칠 수 있다면 오류를 신경쓰지 말자. 머릿속의 생각을 코드로 제대로 풀어내지 못 한다면 그것이야 말로 진짜 오류다.

물론 실무에 관한 이야기다. 면접에서 다른 여러가지 요건이 있어서 이것 만으로 사람을 판단하는건 무리겠지.

기사 링크: 고장 나고, 문제 있어도 우린 '국산IT보다 외산IT'

그냥 정리해 볼까.

• 캐논의 모 디카에서 문제가 나왔음에도 그 제품을 많이 산다: 문제가 발견되기 전에 많이들 샀겠지. 그래서 사용자들의 대응이 화제가 되었고 결국 어떻게든 A/S로 처리되는 결말을 맞이했다는 건 알겠지. 자 그럼? 이제 문제 해결된 제품이 나오겠지. 그럼 사도 되잖아.
  
• 소니의 모 스마트폰은 문제 투성이임에도 산다: 세미콜론 문제나 안테나 문제는 해명이 나올걸 보면 크게 문제라곤 생각지 않아. 근데, 이 폰은 국내에서 인기가 없었다는 걸로 유명한데 많이들 샀을까?
  
• 애플의 모 플레이어 인기는 기능면에서 딸려도 식을 줄 모른다: 응 맞아. 구입하자 마자 사용하는 기계는 기능면에서 딸릴지도 몰라. 근데 생각할게 그것뿐이야?
• 매장에서 외산을 권한다: 이건 내 알바 아니야 -_-
  

자. 내가 크게 하고싶은 말은 이거다.

"제품을 평가할 때 기능만으로 평가하는건 심각한 문제다. 기능에 더불어 제품 자체의 디자인과 편리성, UI의 디자인과 편리성. 그리고 확장성도 고려해야 되지 않겠냐?" (특히 아이팟 터치에 이르러서는 소프트웨어나 악세사리를 추가로 구매/설치해서 기능을 확장할 수도 있는 점은 고려하지 않고 있지? 국내에는 애플광신도가 타국에 비해 적다는 점도 생각하면 어떤 영향이...?)

특정 제품이 인기있다면 왜 인기있는지 부터 파악하고 기사를 쓰셔야 하지 않겠나? 그리고 제목도 좀 잘 골라야 하지 않겠냐? 이건 제목으로 낚고 기사로 바보짓 하는 꼴이지 뭐.

ps. 개인적으로 봤을 때 IT쪽 기사는 너무나 편향된 기사가 많은 것 같아. 그냥 기자가 무식한 걸지도 모르겠지만. 아니, 그냥 광고성일지도... -_-?

<VS root path>\VC\vcpackages\feacp.dll
이 파일 지우던가 이름을 바꿔부러. 최고여~!

ps. 그냥 자료 백업 용 -_-;

자자 또다시 올라온 병신기사 까자.

"PC방서 'IE8' 깔려있다면 주의하세요"

인터넷 사용 후 로그아웃 혹은 실행되는 웹브라우저를 모두 닫지 않으면 다음 사용자가 자신의 로그인 정보를 그대로 확인할 수 있기 때문이다.

"IE8, 로그아웃 안하면 개인정보 노출"

이번에 제기된 취약점은 PC방 등 공개된 장소에서 인터넷 사용 후 로그아웃 또는 실행중인 브라우저를 모두 종료하지 않을 경우, 로그인 상태가 그대로 유지된다는 것이다.

인용한 내용은 동일해. 즉, IE8으로 특정 웹사이트에서 로그인 한 후 로그아웃 하거나 브라우저를 모두 종료하지 않으면 로그인 정보가 그대로 남아서 개인정보가 노출될 수도 있으니 위험하다는 이야기.

이게 왜 병신기사냐 하면, 사실 이건 IE6 혹은 그 이전부터도 이어지고 있는 기술 상의 문제이고, 현재 거의 대부분의 브라우저가 지원하는 쿠키 등을 이용하는 브라우저 인증 방식의 기본 기술의 문제점이 아직까지도 이어오고 있기 때문이거든. 그래서 웹사이트 자체적으로 특정한 방법으로 로그인 세션을 알아서 단절하는 솔루션 등을 개발해서 사용하기도 하고 있어.

결론적으로 말해서 IE8의 문제가 아니라 현재 통용되는 거의 모든 웹브라우저가 이런 현상을 가지고 있으며 이런 문제를 해결하려면 IE8이든 파이어폭스든 크롬이든 회원제 웹사이트 이용을 끝낸 후 브라우저를 모두 종료하거나 로그아웃 하는 버릇을 들여야만 해. 다시 말하지만 IE8만의 문제가 아니고 이전부터 존재하던 문제를 세삼 거론하기에 병신같은 기사라고 까는 거야. 아예 대놓고 IE8까는 기사 같거든.

그보다 원천적인 문제는, 국내 회원제 웹사이트는 너무 많은 개인 정보를 가지고 있다는 점이 더 중요하지 않겠냐. 하루빨리 회원제 웹사이트에서 주민등록 번호 수집을 금지하고 과도한 개인정보를 수집하지 못 하게 막아야 하는게 더 중요하지 않겠냐. 보고 있나 정부?

추신) 물론 내 개인적인 지식으로 쓴 글이야. 틀렸다면 욕해도 환영. :)

하이닉스반도체가 영화 5~6편을 1초만에 다운로드받을 수 있을 정도의 초고속 데이터 전송속도를 갖춘 모바일 D램을 개발했다.

[1초면 영화 6편 다운로드 '뚝딱'] ????????????????? 아니 그래서 뭐 어쩌라구? 이건 아무리 봐도 인터넷 속도에나 어울릴만한 기사 제목인걸? 기사의 초점이 뭔가 어긋난거 아니야? 램 내부의 전송속도 가지고 그렇게 강조할 만한게 되? 램 보다는 램과 CPU, 각종 I/O 장치 끼리의 전송 속도도 함께 맞아 떨어져야 하는것 아니겠냐구.

하아- 이거 다시 '병신기사' 태그를 살려야겠구만. ㅇ_ㅇ

심볼이란 프로그래머가 결정하는 이름이라고 보자. 심볼 네이밍이란 이런 심볼의 이름을 짓는 작업이다. 소스코드에서 함수, 메소드나 변수 등의 네이밍을 보면 (다들 잘 아시겠지만) 몇 가지 특징으로 묶어진다.

• 자바스러운 네이밍: 언더라인은 일체 쓰지 않고 대소문자로 붙여쓰는 스타일. 예를 들자면 SetThisValue 등등...
• vc++에서 변수는 헝가리안 노테이션이 기본. 거기다 자바스럽게 이름을 짓는다. 예를 들자면 szText 등등...
• 클래스는 대부분 대문자로 시작해서 소문자로 마무리하는 자바스타일: CFile(vc++ 스타일), SomeModule 등...
• 소문자와 언더라인으로 구성되는 POSIX 스타일: C 표준 라이브러리나 C로 구현된 류, 혹은 Python이나 Ruby 의 일부 모듈의 메소드 등등. 예를 들어 fgets, some_action 등등...
• 그 외에 대문자만 쓰거나 언더라인을 앞에 잔뜩 붙이는 등의 분류. 좀 특별하니 무시: 주로 상수나 typedef 정의 형태로 쓰이기도 하나 그건 역시 코더 마음.
  

이미 헝가리안 노테이션은 많은 이야기가 오고 갔지만, 이를 주로 쓰는 MS에서 조차도 안쓰는게 좋겠다는 말을 한 것으로 안다. 물론 출처 불명이고 특정 책에서 얻은 지식일 뿐이다. 개인적으로 생각하기에도 가독성을 해치는 주범이라고 생각한다. 그리고 철학(?)적으로도 맞지 않다. 간단한 이유로, 변수이름에 타입이 고정되어 버린다는 점이다. OOP에서는 변수도 객체이기에 이는 맞지 않기도 하지. 헝가리안 노테이션은 C++로 C스타일 코딩을 하게 되는 주범이다.

자바스러운 네이밍은 주로 메소드나 함수 네이밍에 많이 쓰인다. 그리고 자바뿐만 아니라 C++이나 각종 OOPL류에서 많이 쓰이고 있다. 공백을 따로 표현하지 않고 단어단위로 대소문자로 구분해서 붙여쓰기에 코딩 자체는 편하고 가독성도 나름 있다. 하지만 개인적으론 좀 싫어하는 스타일이다. 붙여서 쓰다 보니 가끔 헷갈리게 만드는 문자들 끼리 붙어서 곤혹스럽게 만들기도 한다. 그리고 이런 식으로 이름이 만든 경우 대체로 약자를 안쓰기에 이름이 길어진다. SetVariable 이라는 이름과 setvar(혹은 set_var) 라는 이름의 네이밍 차이는 명백하다.

클래스명의 네이밍은 대체로 거의 비슷한 듯 하다. 대문자C로 시작하는 헝가리안 스타일은 최악이라고 보지만 그 외에 대부분 자바스러운 스타일이 대체로 쓰인다. 굳이 불만은 없다.

C스러운 네이밍, 소문자와 숫자 그리고 언더라인으로 구성된 네이밍은 윈도우 계열에선 거의 안쓰이는 것 같다. vc++ 때문이겠지. 하지만 유닉스/리눅스 계열로 가면 갈 수록, 순수 C로 구성되어 있을 수록 이런 소문자 네이밍은 더 많이 쓰인다. 이런 네이밍의 특징은 함수 이름이 길어지지 않도록 약자를 많이 쓴다는 점이다. 그리고 붙여쓸 경우 모호함을 피하기 위해 언더라인을 간혹 쓴다. 개인적으론 약자 해석이 안될 때 불만이 있긴 하지만 가독성은 제일 좋다고 생각한다.

제목을 분쟁이라고 적었는데, 개인적으로 자바스러운 것과 C스러운 것 사이에서 종종 고민하기 때문이다. 물론 개인적인 기호는 C스러운 것이지만 다른 사람들이 자바스러운 것을 쓸 때를 생각해서 일부러 자바스럽게 쓰기도 한다. 그랬다가 고치기도 하고 (이클립스 리팩토링 기능 만세!)...

굳이 뭐가 좋다고 주장할 필요는 없겠지. 이런건 개인 기호로 남기거나 아니면 팀 회식(???)으로 결정해야 될지도 모를 사항이니깐.

그래도 역시 내 출신성분(...)으로 봐선 C스러운게 역시 최고다. ;ㅅ;