J2EE? JavaEE?

변명이지만 아주 오랫동안 자바를 하지 않아서 자바 진영에서 사용하는 단어도 헷갈린다.
그중에서 J2EE 와 JavaEE. 같은 것으로 알고 있었지만, 확실히 하기 위해서 찾아보았다.

검색 결과, 역시 위키. 위키에 다 나온다. (설명된 위키 페이지 바로 가기)

간단하게 설명하자면 J2EE 1.4 버전까지는 J2EE 라고 불렀지만, 다음 버전부터는 개명을 해서 JavaEE 라고 부른다. 즉, J2EE 1.4 다음은 JavaEE 5라는 것!

자바 버전명에 대해서 자세한 내용도 역시 다른 위키 페이지에 있다. 자바쪽은 이름 외우기도 힘들다. 버전에 대한 위키의 내용을 옮겨 왔다.

자바의 버전은 보통 Java SE 또는 JDK/JRE의 버전으로 말한다.

JDK(Java Development Kit)는 표준 라이브러리를 포함하며, JDK 버전이 바뀜에 따라 이 라이브러리가 확대되고 API가 바뀐다. 초기 1.0/1.1 버전에서 JDK/JRE의 명칭을 사용하다가 Java 1.2가 발표되면서 J2SDK/J2RE라고 개명하여 사용했으나 기존의 명칭으로 사용하는 사람들이 많아 현재는 다시 JDK/JRE의 명칭으로 돌아왔다. 또한 J2SE(Java2 Standard Edition)라는 명칭 또한 Java SE(Java Standard Edition)으로 변경되었다. ^[2]

자바 버전 체계의 메이저 버전(소숫점 위)이 계속 1.x로 고정되어 마이너 업데이트로 여기는 경우들이 있어 1.5 버전부터 5.0(1.5), 6(1.6)의 형태로 제품 버전을 코드 버전과 별개로 발표하고 있다.^[3]

언어 자체는 자바 언어 명세(Java Language Specification, JLS)에서 정의되며, 판(edition)으로 구분한다. JDK가 확장되는 동안 언어는 2판에서 거의 변화가 없었으나, JDK 5와 함께 바뀐 JLS 3판에서 제네릭(generic) 타입, 애너테이션(annotation) 같은 기능이 도입되면서 상당히 바뀌었다.

JDK 7에서는 자바 언어에 상당한 변화가 계획되어 있었으나 JDK 7로 예정되었던 변화가 JDK 7와 JDK 8으로 나눠지면서 JDK 7에는 상대적으로 사소한 언어 특성만이 추가되었다. 구체적으로 이진수 표기 추가, 가독성을 위해 수 표기에 밑줄(underscore)을 허용, 스위치 문(switch에서 문자열 사용, 제네릭 타입 객체 생성 시 타입 추론(type inference), 자동 자원 해제를 위한 try 문법, 여러 예외 타입을 동시에 잡도록 허용하는 문법 등이 추가되었다.

7장(키-벨류 코딩, 키-벨류 옵저빙)

7장을 보고 난 다음 든 생각은 "이런 것도 모르면서 iPhone 개발을 하려고 생각했었나?" 이다. stackoverflow 에서 "OSX 개발자는 대부분 이 책에서부터 시작했다"는 말이 맞을 정도로 interface builder를 사용하면서 가장 궁금한 부분을 알려 준다.

interface builder를 거의 사용하지 않았지만, 한 번씩 사용하면서 안타까웠던 게 "내가 생성한 변수를 여러 가지 UI component와 어떻게 연결 못 시키는가?" 였었다. 그런데 7장에서 이것을 알려 준다.

처음 키-벨류 코딩, 키-벨류 옵저빙이라고 해서 sqlite 인가했었는데, 말 그대로 변수에 바인드를 걸고, 특정 UI Component를 바인드된 변수에 옵저버로 등록하는 것이다. 이렇게 하려면 키-벨류 코딩이 필요하다.

그리고 setter와 getter를 쉽게 사용할 수 있게 만드는 프로퍼티에 대해서 설명하고 있다. 프로퍼티의 속성은 다른 책에서도 설명되어 있지만, 보기 좋게 정리되어 있어서 옮겨 본다.

• assign : 단순히 대입만 한다. 포인터가 아닌 스칼라형(정수형이나 실수형)에 사용
• strong : 말 그대로 strong 하게 연관 관계를 맺는 것이다. strong으로 엮여 있는 것은 메모리에서 해제되는 것이 방지됨
• weak : strong의 반대. 메모리에서 해제되면 자동으로 nil 값으로 설정됨
• copy : 프로퍼티 대상이 문자열일 때나 뮤터블 서브클래스를 이용하는 클래스를 사용할 때 주로 이용
• nonatomic : getter, setter에 lock을 걸지 않음(스레드로 돌지 않을 때)
• atomic : getter, setter에 lock을 걸 때(스레드로 돌 때 접근 경쟁을 막기 위해서)
• readwrite : 기본값으로 설정되는 것. 프로퍼티가 read, write 모두 가능
• readonly : 프로퍼티가 read만 가능하게 만들 때(setter가 무시됨)

noatomic, atomic은 스레드 프로그램에서 필수인데, 프로퍼티의 속성으로 쉽게 처리 가능할 수 있게 만든 게 눈에 띈다.

마지막으로 키 경로(Key Paths) 에 대해서 설명하고 있는데, 이건 기억해 두면 추후 코딩량을 많이 줄이게 될 것으로 예상한다.

8장으로 넘어가 보도록 하자. 짧게 챕터가 구성되어 있으니 짬짬이 시간을 내 보는 처지에서 아주 좋다.

6장(도우미 객체)

6장은 Delegate와 도우미객체에 대해서 설명하고 있다. (그동안 도우미 객체와 Delegate가 같은 것으로 생각하고 있었는데, 잘못 알고 있었다. 기본 component들을 사용하지 않았으니, 잘못 알고 있었어도 이상 없이 코딩할 수 있었었다.)

한 번씩 샘플로 TableView를 사용 때, Delegate 외에 DataSource 라는 이상한 놈을 사용했는데, 이것이 도우미 객체이다. 자신과 특정한 일을 하는 것을 분리하는 패턴이 정말 유용하게 보인다.

그런데 책에 문제점이 눈에 띈다. 번역의 문제인지 원본의 문제인지 모르겠지만, 예제 코드가 책에 나온 데로 하면 제대로 돌지 않는다. iOS 개발도 하지 않고 OSX 개발을 전혀 하지 않은 경우는 좀 헤맬듯싶다. 대신 헤매다 보면 기능에 대해서 보다 정확하게 알 수 있다.

대신 6장 마지막에 나오는 연습 문제는 괜찮다. 2개의 연습 문제를 해결 할 수 있다면 protocol 사용하기 전의 Delegate 에 대해서 충분히 이해했다고 생각하면 된다.

6장은 좀 실망을 안고, 7장으로 고고싱~

5장(타깃/액션)

5장의 2장에 연속된 내용이다. 2장에서 간략하게 설명한 것에 대해서 5장에서 자세하게 설명하고, interface builder의 또 다른 사용법에 대해서 알려 준다.

interface builder의 또 다른 사용법인 Assistant Editor를 이용하는 것은 예전에 아주 감탄하면서 본 것이었는데, 그동안 까맣게 잊고 있었다.

디버깅의 한 방법으로 Zombie Object를 생성할 수 있는 것을 알려주는데, 앞으로 요긴하게 사용할 것으로 생각된다.

또한, 예제로 TTS를 이용한 것을 보여주는데 함수 호출 한 줄로 TTS가 되다니. 정말 간단하다. 근데 영어만 되어서 ㅜㅜ

마지막으로 연습 문제를 하나 제시하는데, 책만 제대로 보면 아주 쉽게 만들 수 있다. 5장까지 공부한 내용을 최종 정리하는 연습 문제 인 것 같은 느낌이 드는데, 6장부터는 보다 새로운 것을 알려 줄 것 같은 기대가 생긴다.

스프링....토비의 스프링 3.1

내년 목표 중의 하나인 스프링을 공부하기 위해서 책을 샀다. (사실 Spring Framework 이 대체 뭐기에 요즘 Java 하면 Spring이라는 말밖에 나오지 않게 만들었는지가 많이 궁금했다. 얼마나 좋은 Framework 이길래.) 많은 분이 스프링의 교과서라고 불리는 "토비의 스프링".

그런데....그런데....
책을 받아 보고, 책 두께에 그냥 질려 버렸다. 1권, 2권 통틀어서 대략 1,700페이지 정도로 보이는데, 대체 이걸 어떻게 봐야 할지 난감하다. 책을 받아본 순간에, 20년도 더 된 고등학생 시절에 맨투맨 영어 참고서 처음 봤을 때와 같은 느낌을 받았다. 그때 맨투맨 영어 참고서가 6권짜리로 기억난다.

아무튼, 목표를 새웠으니 보긴 봐야 할 텐데, 쉬엄쉬엄 보자. 1권에서 책장 빠르게 넘겨 가면서 제목 정도만 훑어 봤지만, 내용은 알찬듯하다. 화이팅!

4장(메모리 관리)

Objective-C도 C이기 때문에 메모리 관리가 중요하다. C 개발할 때부터 메모리 문제 발생하면 디버깅할 때 무진장 머리 아프다고 생각해서, 메모리 문제는 가장 중요하게 체크 하고 웬만하면 이런 상황을 만들지 않거나 최소화하려고 노력해 왔다. 때문에, 예전 Objective-C 책이나 iPhone 개발 책을 볼 때 가장 주의 깊게 본 부분이다.

그동안 iOS 개발을 하지 않아서 Objective-C에서 특징적인 메모리 관리 부분을 다 잊어버리고 있었는데, 4장에서 아주 쉽게 떠올릴 수 있게 도와주었다. 그리고 iOS5에서 ARC가 왜 필요한지에 대해서 이해하게 되었다. ARC 처음 볼 때는 좋은 점을 몰랐는데, 요즘 iOS WRT 급하게 만든 경험으로 ARC가 프로그램 구현에서 많은 부분을 도와주었다는 것을 깨닫게 되었다.

4장에서는 ARC 부터 시작 하지 않고, 예전 고전적인 메모리 할당, 해제 부터 시작하고 있는데 ARC 를 제대로 이해하기 위해서는 이 부분이 상당히 중요하다. ARC 란게 컴파일러가 자동으로 코드를 넣어 주는 것이기 때문에, 고전적인 메모리 관리에 대해서 알고 있어야 ARC 결과에 대해서 개발자가 상상을 할 수 있다.

예전에 공부한 것과 더불어 복습을 하자면 메모리 관리의 룰은 다음과 같다.

[reference count 가 증가 하는 경우]

• alloc
• new
• copy(mutableCopy 포함)

위의 세 가지 경우는 무조건 reference count 가 증가 한다. 또한 개발자가 강제로 reference count 를 증가 시키려면 retain 을 사용하면 된다.

reference count 가 증가한다면 반대로 reference count 를 감소 시켜 줘야 하는데, 이럴때 사용하는 것이 release 이다. 고전적인 메모리 관리는 위의 세 경우 일때는 쌍을 맞추어서 release 를 시켜 줘야 한다.

또한 NSArray object 와 같은 경우는 object 를 array 에 push 할때 자동으로 add 되는 object 를 retain 시키고, pop 할때 자동으로 release 시키게 된다.(NSDictionary 등 기본으로 제공되는 object set 인 경우는 언급 하지 않았지만, 동일하게 retain, release 하게 될 것으로 예상 된다)

autorelease 에 대해서, 이게 정말 제대로 이해가 되지 않았는데 이번에 어느 정도 이해하게 되었다.(주위에 OSX 개발자가 없어서 제대로 이해한 것인지 자신은 없지만, 추후 개발 할때 알게 될 것으로 생각하며 제대로 이해 했다고 그냥 생각 하자 ^^;)

autorelease 로 release 된 것은 release 예약이라고 볼 수 있는데, 예약 해 둔게 과연 어느 시점에 실행될지 정확하게 이해하지 못했는데, "이벤트 루프의 끝" 이라는 말에서 정확하게 이해 되었다. 

java 에서는 object 의 메소드 호출이라고 말을 하는데, Objective-C 에서는 메소드 호출이 아니라 object 로 메시지를 보낸다고 말을 한다. 결국 object 로 메시지 이벤트를 발생 시키는 것으로 보여진다. 즉, "이벤트 루프의 끝" 이란 것은 object 로 메시지 보낸 것이 완료 되었을때 라는 말과 동일한 것이 아닐까 한다.

그리고 임의로 autorelease pool 을 사용하는 이유는 개발자가 임의로 autorelease pool 을 만들고, 임의로 생성된 autorelease pool 에 autorelease 를 예약하고 이벤트 루프가 끝나기 전에 예약된 release 를 실행 시키기 위해서라고 보여 진다.

마지막으로 ARC 에 대해서...iOS 개발에 대해서 제대로 공부 하기 시작 했을때가 iOS5 때 부터 였다. ARC 가 최초로 적용 될때 인데, 그때 다른 개발자의 블로그를 보면 "이해하기 힘들다", "사용하기 힘들다", "코드가 상상이 안간다" 등등의 이유로 ARC 를 사용하지 않고 개발을 한다는 말이 많았는데, 물론 라이브러리 들이 ARC 로 되어 있지 않다는 것도 큰 이유 중의 하나 였다.

그런데, 그 당시 그냥 스치고 지나간 말인 ARC 를 사용하므로 인해 reference count 보다는 "객체의 관계" 에 더욱 신경 쓸 수 있다는 말이 있었다. reference count 는 그냥 프로그램 코딩상의 관점이고, "객체의 관계"는 좀 더 고차원적인 설계의 문제이다.(어떻게 보면 같을 수 있지만......^^;) 아무튼 좀 더 폭 넗게 생각해서 프로그램을 할 수 있게 되었다는게 중요하다.

아무튼 4장도 다시 공부를 시작하는 입장에서 예전 기억을 떠올리는 많은 도움이 되었다.

타임캡슐(2013년형) 3TB 설치기

예전에 회사에서 프린터를 구입 할때, 네트웍 카드가 없는 프린터(HP LaserJet P3010)를 구입해서 그 동안 MS윈도우 PC 하나에 USB 로 프린터를 붙여서 사용하고 있었다.

그런데, MS윈도우 서버가 필요해서 프린터가 붙어 있는 컴퓨터의 MS윈도우 버전을 올리고 난 다음 부터 프린터가 되었다 안 되었다...지 마음대로 돌고 있는 상태 였다. 내가 사용하는 맥북에서도 프린터기를 이용할 수 없는 상태 ㅜㅜ

마침 회사에서 장비 살수 있는 기회가 있어서 3TB 짜리 애플 타임캡슐과 맥미니 서버 풀 옵션으로 구입하게 되었다. 그런데, 안 좋은 소리 들어 가면서 이렇게 구입 하게 만들어 놨더니, 다른 사람이 중간에 쏙 끼어 들어 구입한 장비를 가져 가는 사태가 발생 했다. 짜증 이빠이 되어서 타임 캡슐 까지 던져 줬는데....설치 못한다고 한마디 하고 케이스 뜯지도 않고 있는 상황을 보다 못해서, 그냥 내가 설치 하기로 하였다. 아오~ 욕나오는....

아무튼, 회사 네트웍 구성 때문에 타임 캡슐을 무선랜 기능 끄고 설치 해야 해서 약간 헤맷다. 더더군다나 나도 처음 사용하는 것이 었기 때문에.....

그럭저럭 설치해서 타임 캡슐 잡히고 프린터 까지 이젠 정상적으로 동작하게 되었다.
타임 캡슐 설정은 다음과 같다. 혹시 동일하게 사용하는 사람 있으면 참조 하면 된다.

<Fig1. 맥북에서 본 AirPort 유틸리티 화면>

1번 그림에서 흰색의 타임캡슐을 클릭하면 설정 할수 있는 팝업이 뜬다.

<Fig2. 설정 들어가기 직전>

일렬 번호는 삭제 했다....^^;
편집 버튼을 누르면 타임캡슐의 설정 화면이 나온다. 총 5개 탭메뉴로 구성 되어 있다.

<Fig3. 베이스 스테이션 설정>

베이스 스테이션 설정에서 타임 캡슐의 이름을 주고, 패스워드 설정을 한다.

<Fig4. 인터넷 설정>

타임 캡슐 설치 메뉴얼을 보면 WAN 포트에 LAN 선을 꼽아라고 되어 있는데, 타임 캡슐을 공유기 모드로 사용하지 않아야 하기 때문에 WAN 포트에 랜선을 꼽지 않고 일반 랜 포트(타임 캡슐 뒷면 구멍중 가장 위의 구멍)에 랜선을 꼽았다. Fig4 는 회사 공유기로 부터 IP 받아온 상태 화면이다.

<Fig5. 무선 설정>

무선은 그냥 죽였다. 주위 다른 사무실, 회사 내부 등등 워낙 WI-FI 가 많아서 신호 방해 하지 않기 위해서 그냥 죽였다. 휴대기기에서 프린터 사용하려고 하면 그때 생각 해보기로 했다. 또한, 무선 끄더라도 동일망 내라면 휴대기기에서도 프린터 사용 가능 할 것으로 생각 된다.

<Fig6. 네트워크 설정>

무선을 끄면 자동으로 라우터 모드가 "끔(브리지 모드)" 로 바뀐다. 그냥 그대로 두면 된다.

<Fig7. 디스크>

마지막으로 디스크...파일 공유 활성화 시키고, 공유 디스크 보안은 "계정 사용" 으로 바꿨다. 3TB 짜리라도 아무나 접속해서 막 쓰면 관리하기도 힘드니....

맥에서야 아무런 문제 없이 잘 사용되는데, 이젠 MS 윈도우 에서 프린터 할 수 있게 한번 해 보도록 하자.

MS 윈도우는 Bonjour 프린터 마법사 프로그램 설치가 필요하다. 다음 사이트로 가서 다운로드 가능하다.

http://support.apple.com/kb/DL999

다운로드 받은 것을 설치하면(바탕 화면에 아이콘 생성 하도록 최종 선택), 바탕화면에 Bonjour 프린터 마법사 아이콘이 보인다. 아이콘 클릭해서 실행 시키면, 프린터기가 보일 것이다.

선택해서 설치하면 되는데, 프린터 드라이버를 물어 본다. 이건 상황에 맞게 선택 하면 된다.(회사 프린터기는 HP LaserJet P3010 이어서 "HP LaserJet P3011/P3015 PCL6 Class Driver" 을 선택 했다)

프린터기 설치 이후, 제어판으로 가면 설치된 프린터기가 보일 것이다.(만일 안 보이면 당연히 제대로 설치가 안된 것.....해결 방법? 이렇게 발생하지 않어서 아직 모른다는 흐흐...)

개인적으로 하나 사서 집에 있는 iptime 있는 자리를 대신하고 싶은데, 이러면 와이프에게 엄청난 소리 들을것 같은 불길한 예감이 흐흐흐...내년에 생각해 보도록 하자!