I have received the following email from Google:
One of the social networking service from Google, Google Wave, is sunsetting in 2012. I think the concept and thought will be integrated into the new service, Google+.
But, how come this email from "Google Wage <wave-noreply@google.com>"? Is he too busy to check the mistyping? ^_____^
Thanks Google for making us smile even at the last moment! 
Now, it is very easy to implement hash algorithm in Java. You need only java.security package which is included in basic Java package. It means you don't need to install any other classes or packages. Here is the example for MD5 algorithm:
String source = "Java Hash MD5";
MessageDigest md = MessageDigest.getInstance("MD5");
md.update(source.getBytes());
byte[] hashValue = md.digest();
That's all you need. Not you get the hash value as byte array for source string.
If you want to use other algorithm like SHA256, then you need to change only the parameter when you get the instance of MessageDigest class. Here is the source:
String source = "Java Hash SHA-256";
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(source.getBytes());
byte[] hashValue = md.digest();
Happy Coding!
오래만에 암호화 관련 코딩을 하는데, 이제 정말 편해졌구나. 해쉬값을 얻을 때, 전혀 걱정할 일이 없네. 유명한 해쉬 알고리즘들이 이미 자바 기본 패키지 안으로 다 들어와 있어서, 그냥 3~4줄 코딩하면 해쉬값을 얻을 수 있다.
예제는 위에 있습니다~ 
I was trying to save my "SecretKey" into Java KeyStore. In the specification of KeyStore class in Java, you can save the following 3 types into KeyStore according to the KeyStore class specification (http://docs.oracle.com/javase/1.5.0/docs/api/java/security/KeyStore.html):
However, if I try to save KeyStore.SceretKeyEntry using setEntry(...) method, then the following exception came out:
java.security.KeyStoreException: Cannot store non-PrivateKeys
We can store our non-PrivateKeys using KeyStore.SecretKeyEntry according to class specification, but why they say that we cannot store non-PrivateKeys?
You can solve this problem simply. You need to change the type of KeyStore. Basically I used the "JKS" type when I get instance of KeyStore:
//JKS means Java KeyStore.
ks = KeyStore.getInstance("JKS");
Somehow, this default type of KeyStore does NOT support saving non-PriateKeys. If you change the type into "JCEKS", then the same source code is working properly without the exception.
// JCEKS means Java Cryptography Extension KeyStore.
ks = KeyStore.getInstance("JCEKS");
I think it is better to use "JCEKS" as a default. The "JCEKS" type KeyStore has much stronger protection and implementation than "JKS" type. Please see the following JCE Reference Guide: http://docs.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html. Before Java 2 SDK release 1.4, the JCE(Java Cryptography Extension) package was optional. So you need to include the JCE package to use "JCEKS" KeyStore type. It was a burden to both development and deploy side. However, JCE has been integrated into the Java 2 SDK since the 1.4 release. So if you are using recent Java 2 SDK version like 1.5. or 1.6, feel free to use better "JCEKS" KeyStore type.
Happy coding!
저 에러 때문에 고생 많이했다. 스펙상으로는 분명히 아무 문제가 없는데, SecretKey임에도 불구하고 non-PrivateKey라고 에러를 내다니... "JKS"를 "JCEKS"로 간단하게 고치고 나니 쌩쌩 잘 돌아가는 걸 보고 희열을 느끼면서도 허무하기도 하다. 동일한 에러를 만나시는 분들은 시간 허비 많이 하지 않으시고 해결책을 찾으시기를...
오늘 인터넷 서핑을 하다가 다음과 같은 글을 보게 되었다.
Naming Conventions in Java - How to name Methods,Classes and Variables
When writing programs in the Java language, there are a set of standard conventions which should be followed. These are followed in almost all kind of projects. Beginners in Java language are not used to utilizing the namingconventions but as one writes code in modern day IDE’s these naming practices become a habit.
자바 언어로 프래그램을 작성할때, 몇 가지 표준 규칙들을 지켜주는 것이 좋다. 어떤 분야의 프로젝트를 진행중이건 간에 이러한 규칙들을 지켜주어야 한다. 자바 언어를 시작한지 얼마 되지 않았다면 이런 네이밍 규칙들이 생소하고, 적용하기에 익숙하지 않을 수도 있지만, 요즘 많이 사용되고 있는 통합 개발 환경(IDE)에서도 이러한 네이밍 규칙들을 지키고 있으므로 노력해서 습관이 될 수 있도록 하는 것이 좋다.
자바에서의 네이밍 규칙에 대해서 이야기 하고 있는 짧은 글이다. 특히 메서드(Methods), 클래스(Classes), 변수(Variables) 이름을 짓는 규칙에 대해서 이야기 하고 있다. 사실 이 글에서는 아주 일부분인 네이밍 규칙(Naming Convention)에 대해서만 언급하고 있지만, 사실 자바 프로그래밍 언어가 발표되고 얼마되지 않아서 자바 코딩 규칙에 관한 문서가 발표되었고, 13년 전인 1999년 4월 20일에 마지막으로 수정된 문서가 있다. (그 당시에는 링크가 Sun이었는데 지금은 Oracle이다.)
Code Conventions for the Java Programming Language
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (HTML 버전 바로가기)
이 글을 보니 11년 전인 2001년도에 프로젝트에 적용하려고 번역해 놓은 문서가 떠올랐다.
[PDF 버전] Korean: Code Conventions for the Java Programming Language (한글) [PDF], 역자: 오광신
[HTML 버전] http://www.javastudy.co.kr/docs/lec_ProgrammingGuide/okshin/JavaCodeConventions.htm (자바스터디에 아직도 링크가 살아있다.)
왜 자바 코딩 규칙이 필요한가가 문서 초반에 나오고 있다. 자바를 만든 Sun에서 말하는 그 이유를 소개하면서 글을 마치고자 한다. 자바를 처음 시작하는 분이라면, 처음이 아니지만 한번도 자바 코딩 규칙에 대해서 들어본 적이 없는 자바 개발자라면 어렵지 않은 내용이니 꼭 한번 정독하시기를 추천한다.
- 80% of the lifetime cost of a piece of software goes to maintenance.
소프트웨어를 개발하는 일련의 모든 과정에 들어가는 비용 중 80%가 유지보수에 쓰여진다.- Hardly any software is maintained for its whole life by the original author.
소프트웨어의 유지보수를 그 소프트웨어를 직접 개발한 개발자가 담당하는 경우는 거의 보기 힘들다.- Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
코드 규칙을 지키면 다른 개발자가 그 소스코드를 처음 보았을 때, 더 빠른 시간안에 완벽하게 이해할 수 있도록 도와주기 때문에, 소프트웨어의 가독성이 높아진다.
PS. 예전 문서를 지금 보니 여기 저기 손댈 곳이 많아 보인다. 조만간 깔끔하게 업데이트를 해야겠다.
이미지 출처 : 알라딘 - 천국의 열쇠
끝머리의 시작
기묘한 천직天職
성공하지 못한 보좌신부
중국에서 일어난 일
귀국
시작의 끝머리
옮긴이의 말
저자 : A. J. 크로닌 (Archibald Joseph Cronin) - 1896년 스코틀랜드 덤바턴셔 카드로스에서 태어났다. 일곱 살에 아버지를 여읜 후 외가에서 가난하고 고독한 어린 시절을 보냈다. 1914년 글래스고 의과대학에 진학한 그는 대학을 졸업하던 해 제1차 세계대전이 발발하자 해군 군의관으로 입대했고 전쟁 후에는 인도행 선박의 촉탁의로 일했다. 1921년부터 삼 년 동안 남웨일스 탄광촌에서 의사로 근무했는데, 이때의 경험은 훗날 <성채>를 쓰는 데 많은 영향을 주었다. 웨일스와 런던에서 차례로 개업한 크로닌은 의사로서 성공 가도를 달렸지만 1930년 십이지장 궤양이 발병해 고향 스코틀랜드에서 요양하며 어린 시절부터 꿈이었던 소설 쓰기를 시작한다. 1931년 발표한 첫 소설 <모자 장수의 성>은 출간 즉시 경이로운 반응을 불러일으키며 ‘전후 최고의 소설’이라는 평가를 받았다. 이에 힘입어 전업 작가로 나선 크로닌은 발표하는 작품마다 큰 성공을 거두었고, 대표작 <성채>(1937), <천국의 열쇠>(1942)를 비롯하여 <별들이 내려다보다>(1935), <풋내기 시절>(1944) 등은 영화로도 만들어졌다. 1981년 숨을 거둘 때까지 지칠 줄 모르는 필력을 과시한 크로닌의 작품들은 생생한 인물 묘사와 극적인 플롯, 종교적 정신에 입각한 휴머니즘으로 지금까지도 폭넓은 인기를 누리고 있다.
작년 말부터 읽기 시작해서 어제 다 읽었습니다. 651쪽이나 되는 거대한(?) 분량이지만, 소설이기 때문에 그렇게 어렵지 않게 읽을 수 있습니다. 소설이지만 정말 치점 신부의 실제 전기를 읽는 것 처럼 설득력이 있고 흡수력이 있습니다. 제목도 그렇고 한국의 상황으로 봤을때는 천주교인이나 개신교 믿음을 가지신 분들이 읽어도 좋지만, 여러 서평들에서 나오듯이 종교가 없지만 관심이 있으신 분들도 쉽게 빠져들 정도로 대부분의 사람들이 공감하는 부분들을 다루고 있습니다.
사실 이 책을 다 읽는다고 해서 천국의 열쇠가 무엇인지 확실해 지지는 않습니다. 하지만 무엇인가 정말 깊게 생각할 무엇인가를 던져줍니다. 생각을 하고 고민을 하게 만들어주는 좋은 책이라고 생각합니다. 느낀 것들에 대해서 더 깊게 얘기하기에는 제 믿음과 글 쓰는 실력이 너무 부족해서, 책을 읽다가 무엇인가를 던져주는 부분들을 인용하면서 마칩니다. "개신교를 믿는 사람들만 천국에 가? 그럼 천구교인들은?" 이런 질문들을 한번이라도 해 보신 분들은, 꼭 한번 읽어보세요!
같은 하느님을 제각기 서로 다른 방법으로 예배한다 해서, 왜 사람들은 서로 미워하지 않으면 안 되는 것일까? 그것은 그에게 온몸을 얼어붙게 하는 수수께끼였다. - 23 페이지
"신부님, 종파란 것은 우연히 생겨난 것이니까 하느님께서는 그리 중요하게 여기시지 않으리라 생각됩니다만..." - 103 페이지
이 일은 확실히 신앙의 기적이다. 그렇다. 믿는다는 그것 자체가 기적인 것이다. 요르단의 물, 루르드의 물, '마리아의 우물'의 물. 어느 물이든 간에 그것은 조금도 문제가 안 된다. 웅덩이의 흙탕물이라도 그것이 신의 얼굴을 비추는 거울이라고 믿는다면, 믿는 마음에는 보답이 있는 것이다. - 155 페이지
"클로틸드 수녀님, 신앙에 의심을 품어서는 안 됩니다. 하느님은 당신의 기도에 응답해 주신 겁니다. 누구든 하느님의 뜻대로 움직이는 도구에 불과한 거예요... 우리도 그렇습니다."그는 문득 웃음을 띠었다."노자가 말한 것을 잊지 말도록 하십시오. '종교는 많지만 진리는 하나이며 우리는 모두 한 형제다.'라는 말을..." - 222 페이지
교리에 관한 쓸데없이 복잡한 이론은 모두 깨끗이 치워버렸다. 솔직한 이야기로 인간이 금요일에 고기를 먹었다고 해서 영원한 불에 태워지다니, 내게는 믿어지지 않는 일이다. 그보다는 근본적인 것을 알고 있다면, 곧 하느님에 대한 사랑이라든가, 이웃에 대한 사랑 등 - 그것으로 족하지 않은가! - 563 페이지
"종교의 좋고 그름은 거기 몸담은 자의 생활을 보면 제일 잘 알 수 있어요. 신부님, ... 당신은 당신의 모범으로 저를 정복하셨습니다." - 611 페이지
Finally, new Kinect for Windows is coming! In CES(Consumer Electronics Show) Keynote 2012 today, Steve Ballmer announced that the Kinect for Windows will be official on 1st Feb, 2012.
마침내 윈도우용 키넥트가 발표되었네요. 오늘 열린 2012 CES 기조연설에서, 스티브 발머가 윈도우용 키넥트를 2012년 2일 1일에 정식 출시한다고 발표했습니다.
You can see the whole keynote from LIVE FROM MICROSOFT'S FINAL CES KEYNOTE. And you can get the details for new Kinect from Kinect for Windows coming February 1st with 'near mode' — not for use with Xbox 360.
오늘 기조연설을 보고 싶은신 분들은 LIVE FROM MICROSOFT'S FINAL CES KEYNOTE 를 참고하세요. 그리고 새로 발표된 윈도우용 키넥트에 대한 좀 더 자세한 기사는 Kinect for Windows coming February 1st with 'near mode' — not for use with Xbox 360 을 보시면 됩니다.
Here is the summary & keyword for new Kinect for Windows:
오늘 발표된 윈도우용 키넥트의 특징들과 키워드를 정리해봅니다:
In the near future, we can open the folder and move the files in computer waving our hands like in the movie "Minority Report".
"마이너리티 리포트"에서 보았던 손으로 컴퓨터 폴더를 열고 파일을 옮기던 것이 조만간 현실로 다가올 것 같네요.
Image Source : Why the 'Minority Report' Interface is Far from Practical
오늘 본 글 중에서 소프트웨어 개발자들의 이력서와 관련된 내용의 글이 있어서 공유합니다. 원본의 영어가 어렵지 않으니 원본을 확인하시면 더 큰 도움이 되리라 생각합니다.
원문 : How to make your CV Not Suck from Trisha's Ramblings
사실 이력서에 대한 정답은 없는 것 같습니다. 왜냐하면 이력서를 보는 사람들이 모두 다르기 때문에, 사람마다 이력서를 보는 기준이 다르기 때문이라고 생각합니다. 어떤 사람들은 이력서가 몇장이냐에 대해서 중요하게 생각해서 4장 이상 넘어가면 그냥 버린다는 사람들도 있고, 장수는 별로 중요하지 않다고 생각하는 사람들도 있는 것 같습니다. 하지만 대부분의 사람들이 중요하게 생각하는 것들에 대해서는 신경쓰고 이력서를 작성할 때 그렇게 작성하도록 노력하는 것이 좋을 것 같습니다.
원문에서 저자가 중요하게 생각하는 포인트들을 요약해 보도록 하겠습니다. 제 개인적인 생각들이 들어갈 수도 있으니 이상하다고 생각되는 부분들에 대해서는 원문을 참조해 주세요~
이미지 출처 : 구글 이미지 검색
철자를 틀리지 말자!
영문 이력서에서도 중요한 이야기이지만 한글 이력서를 작성할때도 놓치지 말아야 할 부분이라고 생각합니다. 잘 모르겠거나 헷갈리는 부분들이 있으면 꼭! 사전을 참고해서 작성하도록 해야 합니다. 섣부른 판단은 금물! 기술의 발달로 요즘 많이 사용되는 워드 프로그램들의 경우 철자가 기본적인 문법이 틀렸을 때 빨간줄로 표시를 해 줍니다. 이력서를 봤을때 이 빨간 줄이 특별하게 사용되는 용어들을 제외한 다른 부분에서 나타난다면 아주 큰 감점 요소가 되겠죠.
영어 대문자를 사용해야 하는 곳에는 꼭 영어 대문자를 사용하자!
한국어와는 달리 영어에는 대소문자가 있습니다. 가끔씩 아주 기본적인 것들을 놓치는 경우가 있습니다. 문장의 시작은 대문자로 해야 하는데, 문장의 시작에 소문자가 오는 경우가 있습니다. 그리고 내 자신을 얘기할 때 보통 소문자 i 보다는 대문자 I를 사용합니다. 영문 이력서를 작성할 때, 이런 기본적인 것들은 지켜주세요.
문법을 지키자!
인터넷 상에서 한글도 마찬가지인데 영어도 문법이 안 지켜지는 경우가 많이 발생하고 있습니다. 하지만 이력서의 경우 나 자신을 표현하는 것이므로 문법을 꼭 지켜야 합니다. 영어가 익숙하지 않다면, 영어 사전이나 문법책을 많이 참고하시고, 마지막에는 영어 원어민으로부터 리뷰를 받는 과정이 꼭 필요하다고 생각합니다. 원어민이 리뷰를 해 줄 경우, 문법적으로는 맞지만 사용하지 않거나 다른 표현을 더 많이 사용하는 부분들에 대해서는 추가로 교정을 받을 수 있습니다.
예를 들어 우리말로 "남의 떡이 더 커 보인다."라는 표현을 할 때, 이 말을 그대로 번역하면 의사소통에 어려움이 발생할 수도 있습니다. 미국의 경우 땅이 커서, 집이 크고 집마다 잔디밭이 있어서 그런지 "The grass always looks greener on the other side." (다른 집에 있는 잔디가 항상 더 푸르게 보인다.)라고 표현을 합니다. 이렇게 표현하는게 나의 뜻을 더 정확하게 전달할 수 있는 방법이라고 생각합니다.
스프링 프레임워크(Spring Framework)의 어떤 버전을 사용했는지에 대해서는 크게 신경쓰지 않는다.
이 부분에 대해서는 논란의 여지가 있을 수 있기도 한데, "어떤 버전을 사용했는지 언급하지마."라기 보다는 버전보다 더 중요한 것들에 대해서 신경을 쓰라는 조언으로 이해하시면 좋을 것 같습니다. 소프트웨어 개발자들의 이력서도 대부분 처음에는 헤드헌팅 회사들의 헤드헌터들이 먼저 보기 때문에 내가 사용할 수 있는 기술들을 나열하는 것도 좋은 방법입니다. 하지만 너무 이력서 이곳 저곳에 언급하지 말고, 한곳에 모아서 내가 사용할 수 있는 기술들과 프로그램들에 대해서 언급하는 것이 좋습니다. 한눈에 볼 수 있게 말이죠.
하지만 헤드헌터를 통해서 실제 이력서를 리뷰하는 실무진들에게 이력서가 넘어가게 되면, 그들은 어떤 프로그램이나 어떤 프레임워크를 사용해 봤는지를 더 중요하게 보지 굳이 버전까지는 중요하게 보지 않는 경우도 많습니다. 버전 하나 하나에 너무 민감하게 작성하실 필요는 없고, 내가 어떤 프로그램이나 어떤 프레임워크를 사용해 보았는지가 잘 나타나면 좋을 것 같습니다.
당신이 어떤 열정을 가지고 있는지 알고 싶어한다.
예전에는 취미나 흥미를 보지 않고 그냥 넘겨버리고는 했는데, 요즘에는 취미가 흥미에 대해서 이력서에 아예 언급을 안 하는 것이 더 나을 수도 있다. 취미나 흥미 때문에 실무진들에게 쓸데없는 선입견을 주는 경우가 발생할 수 있기 때문이다.
대신 소프트웨어 개발자로서 블로그를 가지고 있거나 어떤 오픈 소스 소프트웨어에 참여하고 있는지, 또는 자바 유저 그룹 같은 곳에서 활동하고 있는지 등을 통해서 당신이 어떤 열정을 가지고 있는지 알고 싶어한다. 이력서에 이런 종류의 열정들이 없다고 해서 그 이력서를 미리 탈락시키지는 않지만, 이런 열정들이 이력서에 나타난다면 당연히 큰 영향을 줄 수가 있다.
테크놀로지(Technology)쪽에만 관심이 있는 사람인지 비지니스에도 눈을 열고 있는지 알고 싶어한다.
사실 좋은 팀을 꾸려나가기 위해서는 테크놀로지쪽에만 관심을 가지는 사람, 그리고 테크놀로지 부분이 조금은 부족하지만 비지니스를 이해하고 관심을 가지는 사람, 아니면 그 중간 정도에 위치하는 사람, 모두가 필요한 건 사실이다. 또 다른 기준으로는 사람과 프로세스가 있다. 사람과의 관계를 더 중요시 하는 사람이 있을 수도 있고, 프로세스를 더 중요시 하는 사람이 있을 수도 있다.
사실 테크놀로지에만 관심이 있는 사람이라고 해서 그 사람의 이력서를 탈락시켜버리지는 않지만, 그 테크놀로지들이 어떻게 비지니스를 만들어가는가에 대해서 관심이 있고 그러한 부분들을 이력서에 언급하는 경우에 더 끌리게 된다.
즉, 이력서에 그냥 자기가 사용했던 테크놀로지들에 대해서만 쭉 언급하기 보다는, 실제 요구사항이 어떠한 것이었고, 그 요구사항들을 만족시켜주기 위해서 어떤 테크놀로지들을 사용했으며, 그렇게 만들어진 제품을 통하여서 어떤 비지니스가 이루어졌는지 잘 풀어서 쓸 경우에 더 매력적인 이력서가 될 수 있다.
당신의 이력서를 보고 있는 회사들이 당신의 뒤를 몰래 캐 보기도 한다.
사실 짧은 시간안에 이력서를 검토해야 하기 때문에, 지원자의 페이스북이나 인터넷에서의 활동들을 확인하지 못하는 경우도 많다.
하지만 지원자가 직접 쓰거나 번역한 책이 있다면 아마존(Amazon)에 가서 책에 관해서 그리고 책 서평들을 읽어볼 것이다. 또한 다른 출판물이나 소스 코드가 인터넷에 있다면 찾아볼 용의도 있다. 만약 지원자가 다니고 있는 회사에 아는 사람이 있다면 링크드인(LinkedIn)을 통해서 그 사람이 어떤 사람인지 알아보려고 할 것이다. 이력서 만으로는 확신이 안 선다면 당연히 링크드인을 통해서 좀 더 알아볼 것이다.
그렇게 때문에 소프트웨어 개발자라면 인터넷 공간에서의 활동에 대해서 긍정적으로 생각하고 참여할 필요가 있다. 특히 직장에서의 인간관계를 나타내주는 링크드인과 같은 서비스를 잘 활용한다면 인터뷰와 합격의 기회에 한 발 더 다가갈 수 있다.