Yoongi Blog

 Java에서 기본적으로 지원하는 GUI 툴킷이다. AWT는 모든 자바 버전에서 제공하는 표준으로 가장 안정적이다 그리고 AWT를 사용하기 위한 별도의 설치 없이도 자바 런타임 환경이 있는 곳 어디에서나 사용할 수 있다.

 반면에 제한된 GUI 컴포넌트, 레이아웃, 이벤트를 가진 매우 단순한 툴킷이다. 그래서 더 많은 컴포넌트가 필요하다면 처음부터 구현해야 한다는 문제가 있다. 

 AWT 컴포넌트는 "쓰레드 보안"이 되어있다. 따라서 애플리케이션에서 어떤 쓰레드가 GUI를 업데이트 하는지 신경 쓰지 않아도 된다. 이로써 GUI 업데이트 문제가 없어진다. 하지만 AWT GUI는 느리게 실행된다. 

 

몇 일 전 치과가서 치료를 받는데 치과 선생님이 GTD 개념의 일정 관리 어플을 찾는데 좋은거 없냐고 물어봤다. 

GTD?? GTA는 알아도 GTD는 처음 들어봤다.. 무얼까? 궁금해서 다음과 같이 정리한다. 

 

 

GTD(Getting Things Done)의 교훈은 간단하다.

"시간을 관리하지 마라!"

우리가 관리할 수 있는 건 시간이 아니라 우리의 행동이란 것이다. 시간은 누구에게나 24시간 밖에 없다. 아무리 시간을 관리해도 절대적인 시간은 늘어나지 않는다. 이런 상항에서 시간을 쪼개서 일을 관리하는 것은 단지 스트레스 요인이 될 뿐이라는 것이다. 머릿속에 해야할 일이나 목표를 두 가지 이상 간직하고 있으면 그게 곧 스트레스가 된다. 지금 무언가를 하고 있어도 "다음에는 뭘 해야하는데..." 하는 생각이 자꾸 떠오르지 때문이다. 

 

GTD는 그런 스트레스를 없애라고 말한다. 우리가 어떤 일을 하는 것은, 그것이 긴급하고 중요한 일이기 때문이 아니다. 단지, "자연스럽게" 그 일을 해야할 때가 되어서 하는 것 뿐이다. 예를 들어 회사일은 대부분 집에서 처리하기 힘든 일이다. 그런데 자꾸 회사에서 해야할 일을 집에서까지 머릿속에 간직하고 있으면 그것 자체가 엄청난 스트레스가 된다. 그래서 GTD는 그런 목표라든지 일의 중요성 따위는 머릿속에서 지워버리고, 일의 흐름만 관리하라고 말한다. 그게 결과적으로 일을 빨리 처리하는 일이다. 스트레스 요인은 자꾸 일의 흐름을 방해하기 때문이다. 

 

 

 

위의 워크플로우에 대한 간단한 요점 정리는 다음과 같다.

• 모든 Stuff (만남약속, 읽어야되는 메모, 이메일, 청구서, 업무...)는 처음엔 INBOX로 들어간다.
• 한번 본 INBOX 아이템은 다시 INBOX로 들어가지 않는다.
• 모든 업무는 INBOX에 수집된 후 검토와 정리의 과정을 통해서 8가지 목적지 중 하나로 옮겨간다. 쓰레기, 보류, 참고, 프로젝트 수립, 프로젝트 계획, 특정한 일에 처리, 최대한 빨리 처리, 위임. (+바로 수행)
• 프로젝트( = 목표 + 목표): 목적를 달성하는데 필요한 2가지 이상의 행동들
• 프로젝트의 다음 행동내가 오늘 하루를 프로젝트에 제시한 목표를 달성하는데 투자한다면 당장 무엇을 해야할까? 에 대한 답
• 2분의 규칙: 2분안에 끝낼 수 있는 다음 행동들은 당장 실행한다.
• 수집함과 다음 행동이 비어있으면 아무것도 안해도 된다. 마음편히 쉬자!
• '시간 관리'는 없다. 아무리 관리해도 하루가 25시간이 되지 않는다. 우리가 관리할 수 있는 것은 잔신의 행동이다. 
• 매일 계획을 세우지 않는다. 계획은 실전에 수행되기 힘들다. 
• 일에 우선순위를 두지 않는다. 일은 중요한 것부터 먼저하는 것이 아니라 그 일을 할 수 있는 상황에 처했을 때 하는 것이다. 시간적 압박이 있는 일은 달력에 입력한다.
• 검토는 일정한 기간마다 정기적으로 하는 것이 아니고 필요한 만큼 한다. 하루에 5번 할 수도 있고, 일주일에 한번할 수도 있다.
• 메모하는 습관을 길러야한다. 머리속에 남은 미완의 과제들은 스트레스의 근원이다. 모두 적어서 수집합에 넣어버려야 한다. 만약 수집합에 넣지 않는다면 수집함을 비워도 시원하지 않고 찝찝함을 느끼게 된다. 

 

일이 다 처리되었으면 다 잊어버리고 마음 편히 쉬는게 가장 중요하다.

그리고 중요한 부분은 액션과 프로젝트를 잘 구분하는 일이다. 예를 들어 "부자가 되자"란 목표가 있다고 해보자. 이 말은 자체로는 실행이 불가능하다. 과연 어떻게 부자가 되겠다는 것일까? 이런 만역한 목표를 마음속에 많이 간직할 수록 스트레스만 받는다. 

 

그렇다면 어떻게 해야할까?

 

일단 이런 항목은 프로젝트로 분류(부자가 되자! 프로젝트 수립)한다. 그리고 시간이 나면 프로젝트를 어떻게 실행할 수 있을지 생각해본다. 그래서 "부자가 되는 법을 써놓은 책을 찾아보자." 따위의 말을 생각해내면 일단 성공이다.(프로젝트 계획)이 말은 액션에 가까운 말이기 때문이다. 이런 식으로 계속 목표를 구체화시킨다. "인터넷 서점에 방문해서 경제/부자 키워드로 책을 검색한 후 가장 잘팔리는 책 목록을 뽑는다." 수준까지 내려가면 당장 실행할 수 있는 액션이 된다.그러면 이 일을 이제 처리하면 된다. 중요한 점은 그 책을 읽기 전까지는 다음 액션에 대해서 생각하지 않아야한다. 그걸 생각하기 시작하면 역시 또 스트레스가 된다. 위의 요약본에서도 언급했듯 프로젝트에서 우리가 답해야하는 질문은 딱 하나다. "내가 오늘 하루흫 온통 이 프로젝트에 제시한 목표를 달성하는데 투자한다면 당장 무엇을 해야할까?"

 

"논문을 쓰자"와 같은 프로젝트로 마찬가지다. 논문을 쓰려면 일단 주게가 있어야 하고, 관련 참고문헌을 찾아야 한다. 그리고 보통 그일이 끝나고 나서야 아이디어나 방법론을 정리할 수 있다. 이렇게 일을 쪼개서 액셕 별로 하나씩 처리해야 된다. 그냥 내가 전에 그랬던 것처럼 만역히 써야겠다. 라는 생각만 갖고 있으면 결국 스트레스만 받고 하나도 못 쓰는 것이다. 

 

[출처: http://mcfrog.org/tt/846]

/ [:: root]

- 마운트되는 리눅스 파일 시스템이 있는 최상위 디렉토리

- 시스템의 근간을 이루는 가장 중요한 디렉토리

- 파티션 설정 시 반드시 존재하여야 함

- 절대 경로의 기준이 되는 디렉토리

/bin [:: binary]

- 리눅스의 기본 명령어(binary)들이 들어있는 디렉토리

- 시스템을 운영하는데 기본적인 명령어들이 들어 있음

/sbin [:: system binary]

- 시스템 관리에 관련된 실행 명령어들이 들어있는 디렉토리

- 시스템 점검 및 복구 명령, 시스템 초기 및 종료 명령 등 시스템 관리에 관련된 실행 파일들이 존재

/lib  [:: library]

- 프로그램들이 의존하고 있는 라이브러리 파일들이 존재

- /lib/modules : 커널 모듈 파일들이 존재

- 대부분의 라이브러리들은 링크로 연결되어 있음

/etc 

- 시스템 환경 설정 파일이 있는 디렉토리

- 네트워크 관련 설정, 사용자 정보 및 암호정보, 파일 시스템 정보, 보안파일, 시스템 초기화 파일들 중요 설정 파일들이 위치한 디렉토리

/dev [:: device]

- 장치 파일들이 있는 디렉토리

- 장치 파일은 일반 파일과는 다른 특수 파일로서, 마치 파일을 읽고 쓰므로서 하드웨어를 제어할 수 있다.

/mnt[:: mount]

- 다른 장치를 마운트할때 일반적으로 사용하는 디렉토리

- 임시로 마운트되는 파일시스템들이 위치할 곳 (mount point)

/boot 

- 부팅에 핵심적인 커널 이미지와 부팅 정보 파일(부팅 이미지, 시스템 맵, 모듈 정보 등)을 담고 있는 디렉토리

- /etc/lilo.conf에서 지정한 커널 부팅 이미지 파일이 들어 있으며 부팅시 매우 중요한 디렉토리

- 임베디드 시스템에서는 /boot 디렉토리가 없는 경우가 많다.

---

이러한 불편함을 해결하기 위해서 부팅시 자동으로 마운트 시키기 위해서 아래 파일을 편집하면 된다. 

편집에 앞서 자동으로 마운트 시킬 파티션의 UUID를 알아야 한다. UUID는 다음과 같은 실행으로 알 수 있다. 

마운트 시킬 파티션의 UUID를 확인하고 마운트할 위치를 생성하고, 권한을 777로 변경한다. 

~/.config/user-dirs.dirs

국내 모바일 클라우드 컴퓨팅 서비스 

국외 모바일 클라우드 컴퓨팅 서비스

• 애플 - MoblieMe
• 마이크로소프트 - MyPhone
• 구글 - Gmail, GoogleApps

본 내용은 <클라우드 충격> 책 내용을 많이 포함하고 있습니다. 

위의 정의를 정리하면 다음과 같다. 

거대한 컴퓨터 자원은 크게 고도의 확장성과 추상화된 컴퓨터 리소스라는 두 개의 특징을 가지고 있다. 

'고도의 확장성'이란, 급격한 트랙잭션의 증가나 이용자수 변화에 대해 신속하고 유연하게 처리능력을 증감할 수 있는 컴퓨팅 자원을 말한다. '추상화된 컴퓨터 리소스'란, 계산처리가 구체적으로 어떤 기종의 컴퓨터에서 수행되는지, 해당 컴퓨터가 어느 데이터센터에 존재하는지 등을 사용자는 신경 쓸 필요가 없다는 것이다. 

클라우드 컴퓨팅은 그리드 컴퓨팅과 유틸리티 컴퓨팅의 개념과 유사하다. 그리드 컴퓨팅? 유틸리티 컴퓨팅? 이것들은 또 무엇일까? 이제 이것들에 대해서 알아 보도록 하자.

그리드 컴퓨팅이란 네트워크상의 컴퓨터나 데이터등의 리소스를 가상화해서 통합하고, 필요에 따라서 가상 컴퓨터를 동적으로 생성하기 위한 구조를 말한다. 즉, 네트워크에 연결된 복수의 컴퓨터를 모아서 하나의 거대한 컴퓨터로 간주하고, 고도의 연산 또는 내용량의 연산을 수행하는 것을 말한다. 그리드 컴퓨팅의 특징은 집중 관리되고 있지 않은 분산된 자원을 조화시키고, 개방 표준형 프로토콜이나 인터페이스를 이용한다는 점이다. 

다시 말하면, 그리드 컴퓨팅은 네트워크로 연결된 다양한 조직이 관리하고 있는 이기종 컴퓨터 리소스를 모아서 하나의 거대한 컴퓨터로 간주해서, 대규모 과학기술적 계산등을 분산처리시키는 점에 주안을 두고 있었다고 할 수 있다. 하지만 이기종의 컴퓨터의 사용가능한 리소스는 일률적이지 않기 때문에 이 개념을 실현하기 어려웠다.

반면에 클라우드 컴퓨팅 경우, 컴퓨터 리소스는 아마존 등의 서비스 제공자에 의해 집중 관리되고, 클라우드를 구성하는 컴퓨터도 거의 균일화되어 있다. 

다음 표는 그리드 컴퓨팅과 클라우드 컴퓨팅의 차이를 보여주는 것이다. 

	그리드 컴퓨팅	클라우드 컴퓨팅
컴퓨터의 위치와 관리 주체	지리적으로 분산되어 있고, 각기 다른 조직이 관리	지리적으로 분산되어 있지만, 중앙에서 단일 조직 관리
컴퓨터 구성	이기종 혼재	동일기종이 많음
표준화 단체	존재	X
기술 표준	리소스 관리나 스케줄링, 데이터관리, 보안 등의 기술표준이 존재	X
상호 접속성	중시	고려되지 않음
용도	과학기술적 계산, 대규모 연산처리등 병렬성이 높은 애플리케이션	과학기술적 계산 등과 함께 웹 애플리케이션 등 광범위한 용도로 이용 가능

유틸리티 컴퓨팅이란 전력이나 수도 등이 각기 콘센트에 플러그를 꽂고 꼭지를 틀기만 하면 이용할 수 있는 것과 마찬가지 정도로 용이하게 컴퓨터 리소스를 이용할 수 있고, 요금도 전력,수도 등과 마찬가지로 실제로 이용한 만큼을 지불한다. 이러한 정의는 클라우드 컴퓨팅과 다르지 않다. 하지만, 지금까지 일부에서 제공되는 유틸리티 컴퓨팅 서비스에서는 이용 가능한 컴퓨터의 스펙은 미리 공개되고 물리적인 위치에 관해서도 분명히 규정되어 있는 경우가 대부분이다. 반면에 클라우드 컴퓨팅에서 사용자가 이용하는 컴퓨터데 대한 내부 구조를 의식하지 않고 보다 이용하기 쉬운 서비스로 구현되어 있다.