원글 : http://developer.android.com/guide/topics/resources/providing-resources.html

응용 프로그램 리소스를 독립적으로 유지하기 위해, 코드에서 이미지와 문자열과 같은 리소스를 구체화해야 한다. 또한 특별한 이름이 붙여진 리소스 디렉토리들 내에서 그것들을 그룹화하여, 특정한 디바이스 구성(Configuration)을 위해 대안적인 리소스들을 제공해야한다. 안드로이드는 실행시간에 현재 구성에 바탕을 둔 적합한 리소스를 사용한다. 예를 들어 화면 크기에 따라 다른 UI 레이아웃을 사용하거나 셋팅된 언어에 따라 다른 문자열이 제공되기를 기대할 수 있다.

일단 응용 프로그램 리소스를 구체화하면, 프로젝트의 R 클래스 내에 만들어진 리소스 ID들을 사용하여 리소스에 접근이 가능하다. 응용 프로그램에서 리소스를 사용하는 방법은 Accessing Resources에서 확인할 수 있다. 이 문서는 어떻게 안드로이드 프로젝트 내의 리소스들을 그룹화 하고 특정 디바이스 구성을 위한 대안적인 리소스들을 제공하는지 보여준다.

리소스 유형 그룹화

프로젝트의 /res 디렉토리의 특정 하위 디렉토리에 각 타입의 리소스를 배치해야 한다.

MyProject/
    src/
        MyActivity.java  
    res/
        drawable/  
            icon.png  
        layout/  
            main.xml
            info.xml
        values/  
            strings.xml 

이 예에서 볼 수 있듯이, 하나의 이미지 리소스(icon.png), 두 개의 레이아웃 리소스(main.xml, info.xml), 하나의 스트링 리소스 파일들(strings.xml) 등 /res 디렉토리는 (하위 디렉토리들 안에) 모든 리소스를 포함한다. 리소스 디렉토리 이름은 중요하며 표 1에 설명되어 있다.  

표 1. 프로젝트 res/ 디렉토리 내에 지원되는 리소스 디렉토리

주의 : /res 디렉토리 내에 직접적으로 리소스 파일을 저장하지 않도록 한다. 이는 컴파일 에러의 원인이 된다.

리소스 타입들에 대한 더 많은 정보는, Resource Types 문서를 참조한다.

표 1에 정의된 하위 디렉토리들 내에 저장한 리소스들은 당신의 "디폴트" 리소스들이다. 즉 이 리소스들은 응용 프로그램의 기본 디자인과 컨텐츠를 정의한다. 그러나 다른 타입의 안드로이드 디바이스들은 다른 타입의 리소스들을 요구할지 모른다. 예를 들어 디바이스가 일반적인 화면보다 더 큰 화면을 졌다면, 추가 화면 공간을 용한 다른 레이아웃 리소스들을 제공해야 한다. 또 디바이스가 다른 언어로 셋팅되어있다면, 사용자 인터페이스에서 텍스트를 번역한 다른 스트링 리소스들을 제공해야 한다. 다른 디바이스 구성에 대해 다른 리소스들을 제공하기 위해, 디폴트 리소스뿐 아니라 대안적인 리소스들을 제공할 필요가 있다.

대안적인 리소스 제공

거의 모든 응용 프로그램은 특정 디바이스 구성을 지원하기 위해 대안적인 리소스들을 제공해야한다. 예를 들어, 다른 화면 밀도를 위해 대안적인 드로어블 리소스와 다른 언어를 위한 대안적인 스트링 리소스를 포함해야 한다. 실행 시간에 안드로이드는 현재 디바이스 구성을 발견하고 적합한 리소스들을 로드한다.

그림 1. 각각 다른 레이아웃 리소스를 사용하는 두 개의 다른 디바이스들 

리소스 셋에 대해 

1. <resources-name>-<config_qualifier> 내에 명명되어진 res/ 내에 새로운 디렉토리를 만들어라. 

ㅁ <resources_name>은 (표 1에 정의된)디폴트 리소스들에 대응하는 디렉토리 명이다. 

ㅁ <qualifier>는 (표 2에 정의된) 리소스가 사용되는 개인 컨피규레이션을 지정한 이름이다. 

대쉬로 각각 분리해서 <qualifier>를 하나 이상 추가할 수 있다. 

주의 : 다수의 한정자를 덧붙일 때, 표 2에 목록으로 만들어진 동일한 차수 내에서 그것들을 배치해야 한다. 한정자가 틀리게 지시받으면, 리소스들은 무시된다. 

2. 이 새로운 디렉토리 내에 각각의 대안 리소스들을 저장하라. 리소스 파일들은 디폴트 리소스 파일들과 정확히 동일한 이름을 지정해야 한다. 

예를 들어, 여기 디폴트 리소스와 대안 리소스가 있다: 

res/
    drawable/   
        icon.png
        background.png    
    drawable-hdpi/  
        icon.png
        background.png 

hdpi 한정자는 고밀도 스크린을 가진 디바이스에 대한 디렉토리 내의 리소스들을 나타낸다. 각 드로어블 디렉토리들 내의 이미지들은 특정한 스크린 밀도를 위해 크기에 따라 분류된다. 그러나 파일 이들들은 정확하게 동일하다. 이 방법으로, icon.png나 background.png 이미지를 참조하는데 사용하는 리소스 ID는 항상 동일하다. 그러나 리소스 디렉토리 이름 내에 한정자로 디바이스 구성 정보를 비교하며 안드로이드는 현재 디바이스와 가장 잘 맞는 리소스 버전을 선택한다. 

안드로이드는 몇몇의 구성 한정자를 제공하고 당신은 대쉬로 각 한정자를 분리시킴으로써 하나의 디렉토리 이름에 다수의 한정자를 추가할 수 있다. 표 2는 유효한 구성 한정자를 우선 순위 차례대로 목록으로 보여준다. 리소스 디렉토리에 대해 다수의 한정자를를 사용한다면, 그것들이 표에 리스트된 순서대로 디레곹리 이름에 그것들을 추가해야 한다. 

퍼옴 : http://blog.naver.com/PostView.nhn?blogId=mad_ai&logNo=130165607607

Primitive type과 Reference type 그리고 Object 클래스

Primitive type (원시타입)

● 자바 언어에 내장된 기본 유형 
● 자바는 정수, 실수, 논리, 문자 방식의 primitive type을 지원한다. 
● wrapper class는 각 primitive type을 클래스로 만든 것이다. 
● stack 메모리에 저장됨. 

■ byte 

• 8 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -128 ~ 127
• 2의 보수로 메모리에 저장됨
• 기본값 : 0
• wrapper class : Byte

■ short 

• 16 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -32,768 ~ 32,767
• 2의 보수로 메모리에 저장됨
• 기본값 : 0
• wrapper class : Short

■ int 

• 32 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -2,147,483,648 ~ 2,147,483,647
• 2의 보수로 메모리에 저장됨
• 주로 사용
• 기본값 : 0
• wrapper class : Integer

■ long 

• 64 비트 크기에 부호있는 정수
• 범위는 -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
• 2의 보수로 메모리에 저장됨
• 기본값 : 0L
• wrapper class : Long

■ float 

• 32 비트 크기에 실수
• IEEE 754 표준을 따릅니다.
• 부동소수점 방식으로 메모리에 저장됨
• 화폐와 같이 정확한 값을 요하는곳에 double을 사용하면 안됨
• 기본값 : 0.0f
• wrapper class : Float

■ double 

• 64 비트 크기에 실수
• IEEE 754 표준을 따릅니다.
• 부동소수점 방식으로 메모리에 저장됨
• 화폐와 같이 정확한 값을 요하는곳에 double을 사용하면 안됨
• 기본값 : 0.0d
• wrapper class : Double

■ boolean 

• true와 false의 두 가지 값을 가지는 논리형
• 참 / 거짓 상태를 판별하기 위한 간단한 flag로 boolean을 사용합니다.
• 1bit의 정보를 표현하지만, 사용하는 메모리 크기는 정확히 정해져 있지 않습니다.
• 기본값 : false
• wrapper class : Boolean

■ char 

• 16 비트 유니 코드 문자
• 범위는 0 ~ 65,535 혹은 '\ u0000' ~ '\ uffff'
• 기본값 : ‘\u0000’
• wrapper class : Character

Reference type

• 클래스 타입(class type), 인터페이스 타입(interface type), 배열 타입(array type), 열거 타입(enum type)
• Ball 클래스의 참조형 변수를 선언 : Ball b; → Ball 클래스 인스턴스를 생성 후 참조형 변수에 할당 : b = new Ball(); → heap 메모리에 저장.
• 힙 메모리에 생성된 인스턴스는 메소드나 각종 인터페이스에서 접근하기 위해 JVM의 Stack 영역에 존재하는 Frame에 일종의 포인터(C의 포인터와는 다르다.)인 참조값을 가지고 있어 이를 통해 인스턴스를 핸들링한다.
• 그래서 참조형 클래스 사용 시 아래의 변수 할당 방식을 사용시 할당된 변수가 변경되는 원소스에 해당되는 변수도 같이 변형된다. 그래서 원소스에 해당되는 인스턴스와 별개로 할당 변수를 사용하기 위해서는 clone 내지 별개의 힙 메모리에 복사를 하여 사용하는 것이 안전하다.

• JVM과 메모리 구조 챕터에서 생성과 소멸 등의 과정 참조

Object Class

• 클래스 계층구조의 루트 클래스
• Primitive type이 아닌 모든 type(배열 포함)이 Object 클래스를 직접, 간접적으로 상속합니다.
• Object 클래스는 JVM(특히 Execute Engine / Garbage collector)에서 클래스 인스턴스의 생성과 소멸 등의 생명주기(life cycle)을 관리할 수 있게 한다.
• 클래스의 생성자 Object 클래스의 finalize(), wait() 등 대부분의 메소드가 JVM에서 클래스를 핸들링하기 위해 사용되는 메소드다.
• 참조형 변수(클래스)들은 기본적으로 Object를 상속하기 때문에 모든 클래스의 인스턴스의 라이프사이클을 관리할 수 있게 된다.

• Object 클래스의 메소드

String 클래스

• 문자열을 primitive type 처럼 사용할 수 있도록 String 클래스를 특별하게 처리함. 즉, String 클래스는 일종의 Primitive 타입(원시타입)처럼 사용 가능하지만 원시타입에는 속하지 않는다.
• String 클래스는 값이 변경되지 않으며, 값을 변경하는 함수가 있지만, 이 함수는 값이 다른 String 클래스 객체를 생성한다. (immutable object)
• String s = “aaa”; 와 같이 큰따옴표를 사용하여 생성자를 호출할 수 있다.
• String 클래스만이 + 연산자를 통해 문자열 연결
• String 비교시 equals() 함수 사용
• String class의 사용 예제 : 첨부 소스 참조

http://www.gliderwiki.org/wiki/79  펌

보통 안드로이드 프로젝트를 개발할 때는 git이란 형상관리도구를 사용합니다.

git에 소스를 반영할 때는 여러 사람이 반영하게 되므로, 보통 Code Rule을 몇 가지 정해놓고 반영하도록 하는데요..

그 중에 에러를 최소화하기 위해 tab 대신에 space로 반영하도록 하는 사항이 있습니다.

코드 가독성을 위해 tab으로 들여쓰기를 보통 사용하는데,

Eclipse에서 이 tab을 누르거나, 자동 들여쓰기 기능을 할 때, Space로 바꿔주는 기능이 있습니다.

아래 2가지 방법 중 1번으로 안될 경우, 2번까지 적용하시면 됩니다.

1년 6개월 쯤 사용한 블루투스 HBS-900 에 문제가 생겨서 LG서비스 센터에 맡겼습니다.

예전에는 블루투스 제품은 LG서비스센터에서 담당하지를 않았는데, 현재는 처리해준다고 합니다. ^^

사실 3주 정도 전 쯤에 맡겼는데, 전혀 이상을 감지를 못했죠... 그냥 멀쩡하다고 다시 받아왔는데 문제가 있는데 없을리가...
거기 서비스센터 지점이 못하는 지점이라는 생각이 들었고, 일단은 넘어갔습니다..

하지만, 문제 증상이 전원이 자꾸 꺼지고 켜지고를 반복하는 때가 있는 문제여서, 도저히 참기가 힘들어

이번엔 다른 지점을 찾아가봤습니다.

증상을 좀 더 자세히 하니, 맡기고 체크해본다고 해서 맡겼죠..

그리고 2~3일 후에 연락이 오더니, 이어폰 단선 문제라고 하더니 

한쪽만 갈면 22500원, 두쪽다 갈면 38500원이라고 하더군요..

사실 이어폰 문제도 약간 있긴 했지만, 그것보다 전원이 문제라고 얘기하고 일이 있어서 일단 끊고 하루가 지났습니다..

다음날 다시 연락을 했더니, 이번엔 이어폰 문제가 아니라 넥밴드 쪽에 있는 서브보드 부분이 문제여서 

전원에 문제가 난다고 하더라고요.. 이어폰은 아직 큰 문제가 아니라는 판단에 이어폰은 그대로 뒀습니다.

서브보드가 넥밴드와 붙어있는거라서, 넥밴드도 같이 갈아야 된다고 하더로고요...

28500원인데, 임직원 할인받고 21400원으로 처리되었습니다. ㅎㅎ

HBS-900모델부터 이어폰이 깔끔하게 안으로 감기게 하는 기능이 추가된 모델인데, 
줄감기 기능으로 인해 넥밴드 안쪽에 있는 부품에 충격이 가는 단점이 있는 것은 아닐까 하는 생각이 듭니다.

그래도 참 편리하게 쓰고있는 전자제품이죠 ㅎㅎ

** 캐시 삭제 후 블로그 방문 시 조회수는 올라가나... 저품질?

어뷰징 공격 : http://blog.naver.com/so_ing0927/220618583937

http://blog.naver.com/ghdy797979/220646217154

구글 페이지랭크 : http://hothotdog.tistory.com/14

                    http://gong6587.tistory.com/1485

블로그순위 : http://kcsdbma.tistory.com/188

유투브 조회수 (플러그인 툴 이용) : http://blog.naver.com/kk890428/220252977377

네이버 검색엔진 알고 : http://zinicap.pe.kr/220590605330

                         http://blog.naver.com/blogbyjenny/220419337112

아래 기사를 참고

대한상공회의소와 맥킨지가 지난 9개월간 국내기업 100개사, 4만여명의 임직원을 대상으로 한국 기업의 조직건강도와 기업문화를 종합진단한 결과가 나왔다.

15일 상의와 맥킨지가 발표한 '한국기업의 조직건강도와 기업문화 종합보고서'에 따르면, 국내기업의 조직건강은 글로벌기업에 견줘 '약체'로 평가됐다. 특히 중견기업 대다수가 글로벌기업에 비해 절대 약세인 것으로 드러났다.

조직건강도 진단은 맥킨지 조직건강도(OHI, Organizational Health Index) 분석기법을 활용했다. 리더십, 업무시스템, 혁신분위기, 책임소재 등 조직경쟁력에 영향을 미치는 제반사항을 평가·점수화해 글로벌 1800개사와 비교했다.

조사대상 100개사중 글로벌기업보다 약체인 기업은 최하위수준 52개사 포함, 77개사로 집계됐다. 중견기업은 91.3%가 하위수준으로 평가돼 조직건강에 적신호가 켜졌다. 반면 상위수준으로 진단을 받은 기업은 최상위 수준 10개사 포함 23개사에 그쳤다. 세부영역별 진단결과를 보면 Δ리더십 Δ조율과 통제(시스템) Δ역량 Δ외부 지향성 등 4개 영역이 취약한 반면, Δ책임소재 Δ동기부여 등 2개 항목은 우수한 것으로 확인됐다.

조직건강을 바라보는 경영진과 직원간 시각차도 뚜렷했다. 경영진은 자사의 조직건강을 최상위 수준(71점)으로 평가한 반면, 직원들은 최하위 수준(53점)으로 진단하며 상반된 인식을 보였다. 세부항목별로는 Δ리더십 Δ문화 및 분위기 Δ방향성 항목에서 큰 격차를 나타냈다.

지속적인 성과창출을 가능케 하는 차별적인 조직운영 모델을 뜻하는 '지속성장 DNA' 확보 여부를 조사한 결과에서는 '지속성장 DNA'를 갖고 있는 국내기업은 50%로 글로벌기업 66%보다 낮았다.

최원식 맥킨지 서울사무소 대표는 "우리 기업은 아직도 제조혁신 역량을 중시하고 선도기업 캐치업을 도전목표로 설정해 빠른 실행을 하는 기존의 성공방정식에 머물고 있는 것으로 해석된다"며 "급변하는 시장패러다임에 부응해 능동적인 변신과 다양한 사업기회 포착이 힘들다"고 지적했다.


© News1 최진모 디자이너

... 중략

출처는 아래와 같음.

http://news.naver.com/main/ranking/read.nhn?mid=etc&sid1=111&rankingType=popular_day&oid=421&aid=0001941270&date=20160315&type=1&rankingSeq=3&rankingSectionId=101

http://blog.naver.com/pureshower?Redirect=Log&logNo=220395901740

http://blog.naver.com/xinfra/80172458285

http://mainia.tistory.com/2006

http://blog.naver.com/rlawlss/80140113577

http://nekomimi.tistory.com/483

http://mainia.tistory.com/2052

http://taehoonkoo.tistory.com/132

http://www.boannews.com/default.asp

-> 보안관련 뉴스

http://isms.kisa.or.kr/kor/intro/intro01.jsp

-> ISMS 인증제도

http://www.kisa.or.kr/public/laws/laws3.jsp 

-> kisa 정보보호 가이드

1. Stack Buffer overflow 공격

1) strncpy() 사용해서 버퍼만큼만 복사하거나, if문으로 문자열 크기 비교체크해서 복사하면 해결

    process가 메모리에 로딩되었을 때의 메모리 구조에는 몇몇의 영역으로 구분되어있다.

       이는 low address부터 나열하면 다음과 같은 순서이다.

       Code Area (실행코드 위치, 기계어)

       Data Area (초기화 된 정적변수 및 전역변수)

       BSS Area (초기화 되지 않은 정적변수 및 전역변수)

       Heap (동적메모리 할당)

       Stack (함수를 처리하기 위한 영역, 함수 내 로컬변수, 함수의 매개변수)

위 영역 중에 Stack 영역에서 Buffer overflow 를 이용한 공격방법은 아래와 같다.

예를들어 어떤 프로세스의 main함수에서 func() 함수를 호출될 때,

func() 함수 처리 후 돌아왔을 때 수행되어야할 주소 RET를 저장하고,

func() 함수를 기준으로 하기위해 기존의 main함수의 EBP 레지스터를 저장하고,

func() 함수의 로컬변수 등 처리를 위한 데이터들이 stack에 push/pop 되어가며 수행되다가

func() 처리가 끝나면, 위에서 저장했던 RET, EBP를 불러와서 기존 main함수로 되돌아 오게 된다.

위 과정에서 RET를 임의의 주소로 덮어쓸 수 있다면,

해커는 이를 악용해서 공격용 process를 미리 메모리에 로딩해놓고, 이 process의 주소로 덮어쓰게 하여,

새로운 shell을 root권한으로 실행하는 등의 행위로 root권한을 획득할 수 있게 된다.

위 공격을 하려면 2가지 조건이 전제되어야 한다.

1) 공격에 이용하려는 프로세스는 root 소유이고, setuid가 설정되어 있어야 한다.

2) 악용하기 위한 공격용 process를 미리 메모리에 로딩해놓아야 한다.

*  CPU에는 여러 레지스터가 있지만, 아래 3가지를 참고하자.

1) ESP : 스택 연산이 발생하는 스택 프레임의 최상위 포인터 (EBP를 기준으로 상대위치 의미)

2) EBP : 해당 스택 프레임의 베이스 포인터

3) EIP : 다음에 실행할 명령어의 주소값을 가지고 있다. (= Program Count)

2. Race Condition 공격

   1) A 프로세스가 /tmp 디렉토리에 tmp.dat 라는 파일을 생성하고 오픈해서 write를 한다고 하고,
      A프로세스가 root소유의 프로세스이고, tmp.dat 라는 파일에 root권한을 가지도록 setuid를 한다고 가정.

      이 시점을 캐치하여, 공격용 프로세스를 통해 tmp.dat라는 동일한 이름의 파일을 심볼릭 링크파일로 해서 
      /etc/shadow와 같이 중요한 파일에 링크를 건 파일을 생성시킨다.

   2) 위 과정에서 A 프로세스와 공격용 프로세스가 tmp.dat라는 파일을 누가 먼저 생성 시키는지의 race가 발생하게 된다.
      정상적인 경로를 통해 A 프로세스가 먼저 tmp.dat 파일을 생성시키면,
      공격용 프로세스는 이 파일을 지우고, 자신이 생성시킨 파일을 수행하도록 유도할 것이다.

  ** 여기서도 마찬가지로 공격에 이용하려는 A 프로세스는 root 소유이고, setuid가 설정되어 있어야 한다.

3. Format String 공격

   1) process가 메모리에 로딩되었을 때의 메모리 주소에 잘못된 데이터를 덮어씀으로 인한 공격
   2) printf 계열의 함수 사용 시 틀리지 않고 쓰면 해결, %n은 변수의 주소값 이다.

안드로이드에는 BroadcastReceiver 라는 Callback 이벤트를 처리해주는 컴포넌트가 제공됩니다.

쉽게말해서, A라는 앱을 만들었는데, 

문자가 왔을 때 어떤 데이터를 받고 싶다던가 배터리가 50% 이하가 되었을 때 뭔가 변화를 주고 싶다고 한다면

SMS 앱이나 배터리체크 앱에서 어떤 이벤트를 데이터와 함께 날리게 되고,

A에서는 그 이벤트와 데이터를 받아서 원하는 기능을 처리하도록 할 수 있다는 것입니다.

위에서 언급한 이벤트처리를 복잡하지 않고 쉽게 처리해주는 녀석이 BroadcastReceiver 라는 컴포넌트 인 것입니다.

아래에 2가지 방법에 대한 예시를 올립니다.

1. BroadcastReceiver 클래스를 상속  (AppWidgetProvider 도 가능, 아마 BroadcastReceiver를 가지고 있겠지..)

   onReceive() 를 Override해서 기능 정의

   androidManifest.xml에 등록되어 있어야 함.

  * androidManifest 이용해서 등록하면, 명시적으로 해제해줄 수는 없다. (unRegisterReceiver 불가능)
    (onReceive() 메소드가 완료되면 가비지 컬렉션 대상이 되서 해지될지도... 언제 될지는 모름...)

2. Actvity, Service, ContentProvider에 registerReceiver() 내에서 등록한다. 

   * onDestory() 에서 this.registerReceiver() 해줬던것을 해제가능 (메모리 누수 방지 효과도 있음)

2015년 7월에 매해 열리는 서울장애인 IT챌린지가 있었습니다.

회사에서 많이 후원하는 봉사활동이어서, 자원신청하여 참가하였죠.

하는 업이 IT관련이며, 이를 이제는 사명으로 생각하고 있기에
사회에 조금이나마 공헌도 하고 싶었습니다.

청각이 약하신분, 팔,다리가 불편하신분, 뇌에 장애가 있으신분 등 다양한 분들이 참가하는 자리였습니다. :)
한글, 파워포인트, 인터넷 활용 능력이 주 대회였죠 ^^

대회에 몰두하는 모습이 보기좋습니다. ㅎㅎ

IT 대회 뿐 아니라, 장기자랑의 시간도 있었습니다. ^^

어디서 많이본 토끼와 곰이죠?

네이버에서 후원하는 상품들이 많았습니다.

IT챌린지 참여자들과 봉사자분들 단체 샷, 가운데 잘보시면 강원래씨가!!

IT라는 도구가 인류에 편리한 도구로써 활용되고, 악용되지는 않았으면 좋겠습니다.

하루 온전히 자고 일어나니, 여독이 풀렸는지 상쾌하게 여행을 시작한 날이었다.
컨디션도 좋았고, 개인적으로 이번 여행에서 기대를 많이 했던 것이 지브리 박물관이었다.

그리고.. 그 기대를 충족시켜주었다! 
내부 사진을 못찍게 했던가..
아무튼 내부 사진은 없는데, 애니메이션이 어떻게 만들어지는지 굉장히 상세하고 재밌게 보여준다.

캐릭터 상품들을 사고 싶은 유혹이 많았는데, 가격이 쎄서 사지는 않았다..
(사실 이때, 갓 대학을 졸업해서 주머니 사정이..)

전날 밤, 깨알같은 계획#1 (삼보 에버라텍 노트북..)

전날 밤, 깨알같은 계획#2 (와이파이가 잡혔던 숙소!)

평일 오전 미카타역으로 가는 열차안. 텅텅 비어있었다..

주위에 사람들이 없더니, 지브리박물관 가는 버스엔 줄이 꽤 서있었다...

어디서 많이본 고양이? :)

입구에선 더욱 많은 사람들이 줄서있다..

이거 국내에선 못구할뻔했는데,
같이 여행간 친구의 일본친구가 간단하게 편의점? 에서 예매 해주었었다..

천공의 섬 라퓨타라고 하면 아시려나?

지브리박물관 옆 이노까시라온시 공원으로 가는 길 #1

지브리박물관 옆 이노까시라온시 공원으로 가는 길 #2

이노까시라온시 공원 #1

이노까시라온시 공원 #2

반말과 존댓말이 여전히 왔다리 갔다리 하네요..^^;;
지브리박물관은 일본여행을 다시 간다면, 한번 더 가보고 싶다고 생각된 곳 중에 하나입니다.

3일째 오후엔 아사쿠사로의 여행이 이어집니다..

아키하바라를 뒤로 하고, 오다이바로 이동합니다. ^^
모노레일을 타고, 바다풍경을 보며 열차가 달렸는데 사진은 없네요..;;

아키하바라를 떠나기 전, 전자제품 상점들을 여럿 둘러봤습니다.

이번 저녁도 간단히 규동으로...
자판기로 표를 뽑고 사먹었던 것 같은데, 일본은 자판기 문화가 발전한듯..
아기자기 하고 소소한 맛이 있다!

레인보우 브릿지 입니다.. 부산의 광안대교가 생각나네요..ㅋㅋ

요런 자유의 여신상 모조품도 있습니다. 중간엔 도쿄타워도 보이네요.

FUJI 티비 본사 입니다.
요건 먼가 계획은 했으나, 너무 늦어져 관광은 못했네요.

한인 민박집이 많은 오쿠보에서 숙소를 잡았습니다.
늦은 시간 가로등이 많고, 참 밝네요..

자기전에 야식을 먹을려고...ㅋㅋㅋ

겨울바다여서 꽤 추웠습니다.
야간 버스이동 후 첫날이라 많이 피곤했는데도, 첫 해외여행이라 열정이 가득!

3일째 도쿄여행은 지브리박물관, 이노까시라온시 공원, 아사쿠사, 롯뽄기 편입니다.. :)

와... 2010년에 여행 갔던 것을 2012년에 한번 쓰고, 근 4년이 지나고 다시 이어서 씁니다..
그 동안 블로그 관리가 띄엄띄엄이라, 반말했다 존댓말했다가 등등 많은 양해 부탁드립니다.

물론 현재 여기 블로그에 일본여행 사진을 보고싶어서 올 사람은 거의 없겠지만.. 그래도 다시 시작하려고 합니다..ㅋㅋ
여행 간지 6년이 지났으니.. 자세한 지역 명칭 등이 잘 기억나지 않네요.. 
약간은 대략적으로 포스트 해야겠습니다. ㅠㅠ

혹시나 이전 글 처럼 혹시, 누군가 이 블로그를 보고 정정해야될 명칭이 있다면 댓글 부탁드립니다. ㅡㅡ;

이 사진으로 감이 오실진 모르겠지만, 네.. 아키하바라 입니다.. :)
게이머즈라는 랜드마크격? 으로 보이는 건물이었습니다.

사실 학창시절동안 일본 게임과 애니메이션에 많은 영향을 받아왔었습니다.. (PC 게임, PS게임 등)
도쿄역에서 가깝기도 하고, 게임과 애니메이션의 본고장? 같기도 한 곳이라 찾아가 보았습니다.

처음 궁금했던건, 말로만 듣던 오타쿠가 있나 해서 두리번 거렸었네요 ㅎㅎ..
아쉽게도 뚱뚱하고 안경낀 변태? 같은 모습의 사람은 못봤던 것 같네요..ㅋㅋ

점심은 간단하게 우동과 튀김으로.. 

건물만 봐도 게임으로 가득할 것 같은.....

이런 코스프레같은 복장을 입은 사람도 있고..

이런 기모노 복장을 입은 사람도 있었습니다..

야간 버스를 타고 오사카에서 도쿄로 건너와서 그런지, 오후에 꽤 힘들었던 기억이 나네요..
확실히 애니메이션과 게임 문화로 유명한 나라답게 수 많은 캐릭터 상품들과 게임들이 있었습니다.

우리나라엔 이런 거리를 보진 못한 것 같은데, 코엑스가 약간 비슷하려나..

우리나라도 우리나라를 잘 나타낼 수 있는 문화로 타 나라에 영향력을 많이 끼쳤으면 좋겠네요 :)

다음 편엔 2일째 저녁 오다이바 입니다!!