W.C.- 에세이

우연히 뉴스를 보다 

http://www.itworld.co.kr/slideshow/86068

이곳의 뉴스를 보게 되었다.

나 역시 개 허접 개발자이긴 하지만 흥미가 나는 내용인데 

'다른 개발자는 어떻게 프로그래밍을 할까'라는 주제다.

내가 과연 어디까지 적용하고 쓰고 있는지 한번 보기로 했다.

어디까지나 나에 관한 이야기란 걸..

탭보다는 스페이스

코드를 들여 쓰기를 할때 탭을 쓰느냐 스페이스를 쓰느냐는 오랜 논쟁거리라고 한다.

난 전혀 논쟁인줄 몰랐지만.. 뭐 난 언제나 탭을 썼으니.. 

그런데 놀랍게도 요즘 개발자들은 스페이스를 선호 한다고 한다 ㅎㅎ

깃허브(GitHub)에 그렇다고 하는데.. 음.. 난 모르겠다. ㅎㅎ

일단 가독성에서는 탭이 나은거 같은데.. 어디까지나 개인적인 주관 이지만 ㅎ

라인 최대 길이는 80자

이것도 오랜 전통이라고 하는데.. 족보 없는 개발자인 나로서는 처음 듣는 소리다 ㅎㅎ

초기 시절에 모니터의 해상도에 기인한 부분이긴 한데 잘 지켜 진다고 한다.

나두 지키려고 지키는 건 아니지만 보기가 힘들어서 ㅎㅎ 왠만하면 한줄로 길게 안쓰려고 하니..

나름 지키고 있는 셈인거 같다.

빈 괄호는 생략

보통 함수 메서드를 정의 하거나 호출 할때 인수는 괄호 안에 들어 간다고 하는데.. 음 

간단하게 말하면

function abc() 요걸

function abc 이렇게 쓴다는 말이다.

루비에서 많이 이렇게 쓴다고 하는데.. 음. 그래도 난 요즘 자바를 쓰니 아무래도 괄호가 있는게 더 편하다.

인수 정의 앞뒤로 스페이스 두지 않기

이런 것도 암묵적인 규칙이었다니.. ㅎㅎ 몰랐네 몰랐네 예전에는 앞뒤로 스페이스를 두었다고 하는데.. ㅎㅎ

가독성 면에서는 좋은 스페이스가 있는게 좋은데 요즘은 또 그렇지 않나 보다.

자꾸 가독성 보다는 코딩의 시간을 줄일려고 하는 일들이 많아지는 거 같다.

좋은 건가 나쁜건가..

처음이 아닌 마지막에 쉼표

이 음.. 이것도 그냥 습관적으로 마지막에 쉽표를 썼던 건데.. 처음에 붙이는 사람도 있었구나.. 

뭐 사람마다 다른 거니..

char[] a ={a,

b,

c}

이렇게 한다는 거다

스네이크_케이스(snake_case)보다 캐멀케이스(camelCase) 규칙을 선호

음..이 건 또 무슨 소리야? 라는 말이 나오는 생소한 단어들 ㅎㅎ

역시 구글 신에게 물어 봐야지

찾았다~

PascalCase: BackColor처럼 연결된 단어의 첫 글자는 대문자로 표기해야한다.

camelCase: backColor처럼 연결된 단어의 첫 글자는 소문자로, 이후 연결된 단어들의 첫 글자는 대문자로 표기한다.

Uppercase: System.IO나 System.Web.UI처럼 2글자 이하인 식별자(Identifier)를 전부 대문자로 쓴다.

snake_case: '_'(언더바를 사용한다) 

음.. 정말 난 가짜 개발자인가 보다.. ㅎㅎ 아무튼 이런 것들이 있다고 하는데 캐멀을 많이 쓴다고 한다.

근데 나두 모르게 캐멀을 많이 쓰고 있는 거 같기는 하다. ㅎㅎ

중괄호만으로 구성되는 라인은 없음

말로 풀어 놓으니 이해하기가 어렵다.

즉

class {

}

를 쓰고

class

{

}

를 안쓴다는 말~ 밑에 껄 쓰면 왠지 초보 처럼 보여서 나도 쓰지 않는다 ㅎㅎ

가끔 MongoDB에서 쿼리를 잘 못 수행 할 경우가 있다.

그렇게 되면 DB 성능이 너무 쳐지고 다른 작업의 동작에도 영향을 끼지게 된다.

MongoDB를 재시작 할 수도 없을 때?

어떻게 해야 될까?

다행이 MongoDB에서는 현재 진행중인 Operation을 확인 하고 취소 할 수 있는 기능이 있다.

물론 MongoDB 자체에 접속이 안돼면... 말짱 헛일이지만..

MongoDB에 접속이 될 경우라 가정하고!

==>db.currentOp()

위 명령을 수행하면

 "inprog" : [

                {

                        "opid" : 114730890,

                        "active" : true,

난 공대생이다.

하지만 코딩과는 거리가 먼 전자 정보 통신을 전공 한 사람이다.

그리고 학교 수업보다는 음악이나 글에 더 관심이 많았고 아무 것도 수업도 그다지 열심히 듣지 않았다.

그런데 아이러니 하게도 지금 프로그래머이다.

솔직히 실력은 개뿔... TV 드라마나 영화에 나오는 프로그래머처럼 순식간에 해킹을 하고 메모장에다가 여러줄의 코딩을 하는 그런 프로그래머와는 거리가 멀다.

솔직히 난 인터넷이 없으면 코딩을 할 수가 없고..

구글신이 없었으면 이미 포기 했을 지도 모른다.

난 돈을 벌기 위해 이 일을 시작했고!! Ctrl+C 와 Ctrl+V를 애용하는 코더다!!

어쩌면 지금 우리 사회가 만들어 낸 불량 제품이기도 하다. 

많은 언어를 원리도 알지 못한채 이상한 프로그램들을 만들어 냈고 지금도 쓰고 있다.

여전히 시간에 쫓기며 게을러 터져서 프로그램보다는 음악이나 글쓰고 그림 그리는게 좋으니..

컴퓨터앞에 앉으면 공상부터 하는 사람이다!

그래서 이 게으름을 쫓아내고 조금더 전문성을 가져 볼까 하고

일주일에 한번씩 글을 쓰려고 한다.

Java 언어에 대해서 말이다.

솔직히 시중에 있는 Java 책도 읽어도 의미를 잘 모르는 나이기에..

시간이 많이 걸릴지도 모르지만

그래도 한번은 도전할 만 하기에 시도해 보기로 했다.

게을러 지지 말자!

화이팅!

MongoDB는 ObjectID란 것이 있다.

{ "_id" : ObjectId("51f1dd7cf6d140526e6f9280")

이런 식으로 _id 필드에 값을 지정하지 않으면 임의의 유니크 값으로 들어 간다.

이 값이 인덱스로도 무조건 자동 등록!!

그럼 요놈의 ObjectID란 놈을 살펴 보자

여기에는 타임 스탬프 값이 있다.

앞자리 8자리는 타임 스탬프 값이라고 보면 된다.

간단하게 ObjectID를 생성해보자

일단 현제 TimeStamp를 구한다.

어려우면 

http://www.epochconverter.com/

이 사이트 가면 된다.

타임 스탬프 값을 가져와서 아래와 갘이 임의로 ObjectId를 생성할 수 있다.

16진수로 변경한 것이 앞자리 8자리 이다.

뒤에 것은 임의로 mongoDB가 자동 생성! 여기서 MongoDB Object ID 구성을 더 보자면

이렇게 구성되 있다고 한다.

MachineID와 Process ID는 랜덤하게 생성 된다

진짜 인지 굼금하면 소스 확인 ㄱㄱ~

이제 ObjectID의 정체를 알았으니 활용도 가능하다.

특별히 _id 값을 입력하지 않았다면

ObjectID에 데이터 저장 시간이 포함 된다는 이야기!!!

입력 시간을 기준으로 데이터를 검색 할 수 있다는 이야기 이다. 별다른 Index 지정 없이!

이렇게 범위 검색이 가능하다는 거

MongoDB에서는 또 ObjectId에서 날짜를 추출하는 함수를 제공한다.

요렇게~ 

구해 진 값을 보건데 이건 UTC로 저장 되는 걸 확인

활용 할려면 UTC인지 local Time 인지 잘 구분해서 해야 하는군

간단하 Java 활용 코드를 보자면

int mtime = 1374820967;

String m = Inetger.toHexString(mtime);

String rm = m + "0000000000000000";

ObjectId id = new ObjectId(rm);

이런 식으로 생성해서

쿼리에 응용해주면 된다!

주기 적인 Hive batch 작업이 필요하게 되었다.

새벽 시간에 데이터 통계 작업을 해야 하는데 새벽마다 hive server를 구동 시킬수도 없고

그래서 찾아보았다

역시 답은 간단하게 나왔다.

nohup bin/hive --service hiveserver >> hiveserver.log &

이렇게 해주면 된다.

그러면 관련 로그가 hiveserver.log에 쌓이게 된다.

근데 하이브 작업이 많아지면 log 파일이 커지게 되는 단점이...