Polpid's Pensieve

건담의 귀요미 시리즈 중 하나인 GUNCANNON ^^

조립도 정말 쉽고 부품도 얼마 안되서 30분도 안걸린것 같다. 

그렇지만 정말 귀엽다 ^^

작지만 뭔가 강해보이는게 특징. ^^ 발도 뭉뚱해서 정말 귀엽다. ㅋㅋ

원문 : Putting Developers to the Test 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7965279979

역시나 이번에도 허접하게

화이트 보드와 맨홀 뚜껑은 좋은 개발자를 찾는데 전혀 도움이 되지 않는다. 

 당신이 세계에서 가장 유명한 요리사 중 한 명이라고 가정해보자. CIA를 졸업하고 4성급 레스토랑을 운영하고 있다. 그리고 Food Network에서 방영하는 쇼에 출연하고 있다. 이제 당신은 실리콘 벨리에 카페테리아를 창업하기 위해 면접을 하고 있다. CEO와 간단한 대화를 마치고 그녀는 당신을 건물 밖으로 데리고 나간다. 그리고 그녀는 말한다. "나는 당신이 어떻게 일하는지 보고 싶습니다. 나에게 음식을 만들어주세요". 

"알겠습니다" 라고 대답을 하고 당신은 다시 묻는다. "주방은 어디 있나요?" 

"아니요. 나는 당신이 이 공원에서 장작을 찾은 다음에 서로 마찰시켜서 불을 만들고 창으로 사슴을 사냥한 후 그것을 불 위에 놓고 요리를 하는 모습을 보고 싶습니다. " 

나는 최근에 몇몇 회사들과 면접을 진행하면서 대부분의 기업들이 직원들의 잠재력을 평가하는데 사용하는 프로세스를 보고 웃게 되었다. 그들은 회의실에 앉혀놓고 프로그래밍과 관련된 문제를 제시하고 화이트 보드에 그것을 풀어보라고 한다. 

이것은 오늘날 소프트웨어 엔지니어가 실제로 하는 일과는 거리가 멀다. 이것은 마치 지원자에게 면접관의 초상화를 그리라고 하는 것과 마찬가지다. 나는 적어도 12가지 언어를 구사할줄 안다. 하지만 그 모든 것을 내 머릿 속에 담고 있지는 않다. 만약 내가 자바로 개발을 한다면 이클립스를 사용할 것이다. 만약 iOS 앱을 만든다면 Xcode를 사용할 것이다. 그리고 명령어, 스페이스를 치면서 메서드를 자동으로 찾아주는 기능을 사용할 것이다. 또는 javadoc을 보거나 웹에서 메서드 사용법을 찾을 것이다. 

Larry Wall은 프로그래머의 자질 중 하나가 게으름이라고 말한다. 여기서 게으름이란 작업을 완료하는데 최소한의 작업을 수행한다는 의미이다. 당신이 개발자를 구할 때 그가 얼마나 효율적인지, 그리고 얼마나 좋은 코드를 만드는지 알고 싶을 것이다. 만약 그가 검색을 통해서 5분 안에 문제의 해결책을 찾아낼수 있다면 검색 없이 몇 시간 동안 문제를 해결하려는 사람보다 더 낫다고 평가할 수 있다. 화이트 보드는 이것을 평가할 수 없다. 

내가 했던 가장 인상 깊었던 면접은 ITA에서 했던 면접이었다. 그들은 나에게 PC를 주고 개발 관련 문제를 풀어보라고 했다. 면접관은 내가 코딩을 하는 2시간 이상을 내 옆에서 지켜봤다. 나는 내 마음대로 무료로 제공하는 IDE를 다운로드 받고 웹을 검색하고 일반적으로 하는 일들을 진행했다. 면접이 끝나고 그들은 나에 대해 무엇을 알았을까?

• 내가 문제를 풀기 위한 툴을 설치할 줄 아는가. 
  
  
• 문제를 내가 어떤 방법으로 접근 하는가. 
  
  
• 문제를 풀기 위해 관련된 정보를 어떤 식으로 찾는가. 
  
  
• 내 코딩 스타일은 어떤가.

비교해서 말하자면 화이트보드에서 설명하는 방법은 요즘 개발자들이 사용하는 툴들에 대해서 정보를 얻을 수 없는 상태에서 얼마나 기억을 하느냐에 대한 테스트밖에 되지 않는다. 만약 당신이 지원하려고 하는 일자리가 인터넷이 없는 사막이 아니라면, 당신이 얼마나 좋은 개발자인지 알리기에는 부족할 수 밖에 없다. 

당신은 이것들이 나 혼자만의 의견이라고 생각하겠지만 구글 또한 그들의 수수께끼 같은 문제들을 푸는 것이 애플리케이션의 품질을 결정하는 데에 영향을 준다고 인정하고 있다. 누군가가 어떻게 일을 잘하는지에 대한 가장 좋은 지표는 그들과 함께 일을 하면서 보는 것이다. 2시간 정도의 짝 프로그래밍은 당신에게 화이트보드를 사용하는 것보다 지원자에 대한 정보를 많이 알려줄 것이다.

...

객체를 상속받는 null 객체를 만들고

null일 경우 get method에 대한 처리 해줌

Singleton Pattern : 해당 클래스의 객체가 하나만 만들어지고 어디서든지 그 객체에 접근할수 있도록 한다.

(출처 : http://www.phpbuilder.com/columns/Singleton-PHP5/Octavia_Anghel112310.php3)

구현 방법은 간단하다.

1. public class Singleton {
2.     private static Singleton singleton;
3.     private Singleton(){};
4.    
5.     public static Singleton getInstance(){
6.         if (singleton == null){
7.             singleton = new Singleton();
8.         }
9.         return singleton;
10.     }
11. }

그런데 위와 같은 방법은 문제가 있다.

멀티 쓰레드 상에서 if문을 여러 client가 통과할 가능성이 있다는것이다.  그렇게 되면 유일한 객체가 아닌 singleton객체가 여러개 생성이 될수 도 있다.

그래서 찾은 방법이 synchronized를 사용하는것.

그런데 또 문제 발생... synchronized를 사용할 경우 멀티 쓰레드 상에서 성능 문제를 발생 시킬수 있다. singleton객체를 별로 안쓴다면 크게 문제가 없겠지만.

그래서 또 나온 방법이 DCL.  Double-Checked Locking

1. public class Singleton {
2.     private volatile static Singleton singleton;
3.     private Singleton(){}; 
4.     public static Singleton getInstance(){
5.         if (singleton == null){
6.             synchronized (Singleton.class) {
7.                 if (singleton == null){
8.                     singleton = new Singleton();
9.                 }
10.             }
11.         }
12.         return singleton;
13.     }
14. }

위에 코드처럼 singleton이 null 인 경우에만 synchronized를 적용한다면 속도에는 크게 지장이 없을것이다.

그리고 java1.4 이후에서 나온 volatile을 선언해 두면 해당 변수가 사용될때 한번 확인해서 동기화 시켜준다. 

Strategy Pattern, 전략 패턴이라고 한다.

전략이라는 것은 여러 분야에서 쓰인다. 특히 스포츠에서 많이 들을 수 있는 단어이다. 그리고 언제나 전략은 한가지일 수는 없다. 딱히 한가지 방법만 있다고 한다면.. 전략이라고 하기에는 좀 부족하지 않을까. 그냥 공식? 이라고 하는 편이 나을지도 모르겠다. 

이렇게 전략은 항상 다양하게 존재한다. 상황에 따라서 전략을 바꿀수도 있다. 이러한 사상(?)을 담은 패턴이 Strategy 패턴이다.

클래스 다이어크램을 보면 Context 클래스가 존재하고 AStrategy 인터페이스가 존재한다. 그리고 AStrategy 인터페이스를 구현한 ConcreteStrategy 클래스들이 존재한다. 상황에 따라서 ConcreteStategy 클래스를 변경한다!라는 것이다. 

여기에서 주의깊게 봐야할 점은 Context 클래스에 존재하는 AStrategy : aStrategy 이다. Context클래스는 AStrategy를 가지고 있으나 직접 생성하지는 않는 관계이다. (색칠하지 않은 마름모 모양 : Aggregation). 하지만 저 멤버변수를 사용하기 위해 내부에 set메소드를 가지고 있음으로써 사용자가 직접 ConcreteStrategy를 set 할수 있게 만든다. 

따라서 사용자는 기존 코드를 변경하지 않고도 Stategy를 set만 함으로써 전략을 변경 할 수 있다. 

Arrays.asList(array);

이렇게 하면 array를 List로 변환해 준다.

나름 유용할듯. ^^

이것 이외에도 sort도 사용할수 있다.

Arrays.sort(array)

배열 정렬시킬때 잘 써먹을듯 하다. 

Retention Annotation은 meta Annotation이 얼마동안 유지되는지를 정한다.

사용법은 아래와 같다

Retantion(RetentionPolicy.SOURCE) : Annotation이 소스 코드에만 존재하고 class 파일이나 runtime 시에 나타나지 않는다.

Retantion(RetentionPolicy.CLASS) : compiler가 class파일에 기록은 하지만 runtime시에 나타나지 않는다. Retantion을 명시하지 않으면 default가 CLASS이다.

Retantion(RetentionPolicy.RUNTIME) : compiler가 class파일에 기록을 하고 runtime시에 영향을 준다.

Annotation을 지정할 때에 특정 field나 method에 한정해서 지정해 줄 수 있다.

@Target(ElementType.FIELD)

위와 같이 사용하게 되면 해당 Annotation은 Field에만 사용할 수 있게된다.

FIELD 이외에도 다른 타입들이 존재한다.

TYPE(Class, interface..)
METHOD
PARAMETER
CONSTRUCTOR
LOCAL_VARIABLE
ANNOTATION_TYPE
PACKAGE

여러개를 사용하고 싶을 때에는 다음과 같이 Array형태로 지정한다.

@Target({ElementType.FIELD,ElementType.METHOD })

---

거침없이 배우는 라즈베리 파이

저자

에벤 업튼, 가레스 할퍼크리 지음

출판사

지앤선 | 2013-03-27 출간

카테고리

컴퓨터/IT

책소개

라즈베리 파이의 공동 개발자 에벤 업튼이 직접 저술한 책!▶ 현...

---

라즈베리 파이가 뭐지??

일단 컴퓨터다. 나도 이책을 보면서 처음알게 되었는데. 모양은 컴퓨터 같이 생기지는 않았고 보통 데스크탑 컴퓨터 뜯어보면 나오는 메인보드의 축소판 정도로 생겼다. 실물을 본적은 없지만. ^^

그런데 왜 라즈베리 파이지?

라즈베리(Raspberry)는 컴퓨터 회사들 사이에 과일 이름을 따는 오랜 전통이 있어서 붙인거고 파이(PI)는 파이썬에서 따온거라고 한다. 느낌이 팍! 오지는 않지만 그래도 독특한 이름이 기억에 남게된다. 

책을 보고 있자면 대학때 어렴풋이 배웠던 마이크로 프로세서를 떠올리게 한다. 그래도 그때보다는 알아듣기 쉽고 다루기 쉬워보인다. 

책 내용도 처음 설치부터 시작해서 주변기기를 설정하고 어떻게 사용하는지에대해서 설명을 해주고 있다. 컴퓨터 조립하기 가이드 같은 책과 같은 구성이다. 그래서인지 라즈베리 파이를 가지고 있지 않은 나에게는 읽기가 좀 힘들었던 책이다. 이런건 직접 실습을 해가면서 하는게 재미있는데 말이다. 

하지만 실제로 사용하는 초보자들에게는 좋은 가이드가 될수 있는 책이다. 

아직은 여유가 없어서 해보지는 못했지만 나중에라도 한번쯤 다시 접해보고 싶다.