1. Android 개발 시 에뮬 대신 VM 타겟을 이용하는 방법

    http://blog.saltfactory.net/186

  2. 죄송합니다. 짧게 쓸 시간 여유가 없어서 길게 씁니다

    — 

    summary: 편지를 짧게 쓸 시간 여유가 없어서 길게 쓸 수 밖에 없었다는 말에는 인사이트가 담겨 있다. 한국 사회도 투입되는 input으로 사람들의 노력을 판단하는 문화가 아니라, 보여지는 output의 명료성이나 간결성에 더 많은 가치를 두는 문화가 정착되었으면 좋겠다. 그렇게 하는 것이 더 힘든 일이기 때문이다.

    http://mbablogger.net/?p=5383

  3. 개발 가격 측정 기준

    http://www.hoons.net/Board/free/Content/52867

    어디에나 트레이드오프가 존재한다.ㅋ 

    빠른 스피드+싼가격= 안이쁨.

  4. 터파기 시작

    비가 왔다 갔다 해서 고생했다- _ -

    굴삭기 소리가 예상외로 커서 옆집에 디게 미안함; 

    미리 과일들고 인사하러 가서 다행이다.

    임시 전기랑 수도관 사용 신청도 이제 승인 났고 지대로 공사 시작하나보다.ㅎㅎ

    철근도 주문했는데 자재 주문할 때는 절대로 일시불 하지 말라시는 아버님 말씀.

    쓸 만큼만 주문해서 돈도 계약금 중도금 잔금 이런식으로 나눠서 주라고 하심.

    하자 등 문제 있을 경우 돈을 다 주면 해결이 잘 안된다고 한다.

    철근 주문해서 현장에 가져다 놨는데 3일째 비가온다.ㅋㅋㅋ 망했당.

    현장 소장 아저씨는 집이 대전인데 자재 지킨다고 집에도 못가시고=_=;;; 

    빨리 주문하지 말고 날씨 봐가면서 그때그때 주문할것;; 

    낼은 다행히 비가 그쳐서 비만 맞고 있던 철근을 드디어 넣기로 함- -;;; 

    아버님은 부산에 내려가 계셔서 내가 사진찍고 철근 사이즈 확인해달라고 해야된당. 아 떨려.>.<

  5. 공사 시작 전에 준비해야할 것

    현장 소장님 경비, 자재 보관할 컨테이너, 폐기물 처리 신청서, 임시 전기, 레미콘 챙겨야됨.

    이 중 임시 전기는 한전 직원이 나와야 하므로 허가에 5~7일 정도 걸린다고 하니 공사 시작 일주일 정도 전에 반드시 신청할 것.

  6. 착공신고

    건축 허가 후 착공 신고를 역시 건축사 사무소에서 진행함

    * 착공 신고 시 건축주가 제출해야 하는 것

    1. 건축 허가 표지판

    2. 건축 허가 표지판을 공사 장소에서 촬영한 사진

       하루만에 급하게 표지판 만들고 공사 장소에서 촬영한다고 힘들었다.

        이거 도대체 왜 필요함..ㅠㅠ 

    3. 이거 제출하면 며칠 있다 착공계가 나온다. 본인이 구청 건축과 가서 찾아오면 됨. 

    건축과 가서 찾아오는데 담당자분이 “어디서 오셨어요?” 라고 물으셔서 “부천요” 라고 대답해서 본의 아니게 담당자분을 매우 즐겁게 해드렸던 기억이 있다. “건축주요 또는 사무소요(건축사 사무소)”가 정답..=_=; 

    4. 공사를 직영하는 경우 착공 신고 후 공사 들어가기 전에 반드시 산재 고용 보험에 가입해야한다. 근로복지공단에서 두 보험을 한꺼번에 가입할 수 있다. 

    근로복지공단 자료마당에서 보험관계성립신고서를 작성한 후 공사하는 지역 관할의 근로복지 공단에 팩스를 보내면 5일 정도 후에 보험금 영수증이 날라옴. 납부하면 됨.

  7. 건축 허가

    1. 아버님과 건축사 사무소에서 설계한 걸 건축사 사무소에서 기흥 구청에 건축 허가 신청함
    2. 허가 난 후 건축사 사무소에서 전화와서 구청에서 허가증 및 허가증 받을 때 냈던 비용 영수증 모두 팩스로 보내달라고 함. (지방세 납입, 국민채권 구입—> 샀다가 그 자리에서 되팔아도 됨)

    건축 허가까지는 우리가 뭔가 할 게 없었음. 다된 거 그냥 찾아오기만 하면 됐음.

  8. 울 집 공사 진행 상황

    진행 상황 한번 써놔야지

  9. REST API

    REST (Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 그는 하이퍼텍스트 전송 프로토콜 (HTTP)의 주요 저자들 가운데 한사람이다. 그 뒤로 이 개념은 네트워킹 문화에 널리 퍼졌다.

    엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 네트워크 아키텍처 원리란 리소스를 정의하고 리소스에 대한 주소를 지정하는 방법에 대한 개괄을 말한다. 간단한 의미로는, 도메인 지향 데이터를 HTTP위에서SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 당연히 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP프로토콜을 사용하지 않은 채로 또 월드 와이드 웹에서 전송하지 않고도 아주 커다란 소프트웨어 시스템을 설계하는것도 가능하다. 또한 리모트 프로시져 콜을 이용하는 대신에 간단한 XML과 HTTP 인터페이스(REST 원리에 부합하지는 않지만)를 이용해 설계하는것도 가능하다. 현실 세계에서의 REST 용어에 대한 이러한 두가지 의미는 기술 토론에서 종종 혼란을 야기한다.

    필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

    REST의 지지자들은 웹이 몇 가지 핵심 설계 원칙의 직접적인 결과로서 확장성과 성장성을 갖게 되었다고 주장한다.

    • 응용 프로그램의 상태와 기능들은 리소스들로 나뉜다.
    • 모든 리소스는 하이퍼미디어 링크를 사용하는 공통 문법을 이용하여 유일한 방식으로 주소를 지정한다.
    • 모든 리소스들은 클라이언트와 리소스 사이의 상태 전송을 위한 유일한 인터페이스를 공유한다. 다음과 같이 이루어져 있다.
      • 잘 정의된(well-defined) 명령어들의 제약 집합.
      • 콘텐츠 종류와, 코드 온 디멘드를 부분적으로 지원하는 제약 집합
    • REST 아키텍처에 적용된 6가지 제한 조건 (개별 컴포넌트의 구현은 자유롭게 디자인할 수 있다)
      • 클라이언트 / 서버 구조 - 유니폼한 인터페이스로서 분리되어야 한다
      • 무상태 (Stateless) - 각 요청 간 클라이언트의 컨텍스트가 서버에 저장되어서는 안된다
      • 캐시 처리 가능 (Cacheable) - WWW 에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
        • 잘 관리되는 캐싱은 클라이언트-서버간 interaction 을 부분적으로 또는 완전하게 제거하여 scalability 와 performance 를 향상시킨다.
      • 계층화(Layered System) - 클라이언트는 보통 대상 서버에 직접 붙었는지, 또는 중간의 intermediary 서버와 붙었는지를 알 수 없다. Intermediary 서버는 로드 밸런싱을 가능하게 하거나 공유 캐시를 제공함으로써 시스템 scalability 를 향상시키는데 유용하다.
      • Code on demand (optional) - Java applet 이나 JavaScript 의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
      • Uniform Interface - 아키텍처를 단순화시키고 decouple 시켜서 클라이언트, 서버 각 파트가 독립적으로 개선될 수 있도록 해준다.
    • REST 인터페이스의 원칙에 대한 가이드
      • 리소스의 구별
        • 개별적인 리소스는 요청에서 구별된다 - 웹 기반의 REST 시스템에서의 URI 의 사용을 예로 들 수 있다. 리소스 그 자체는 클라이언트로 리턴되는 representation 으로부터 개념적으로 분리되어 있다. 예를 들어, 서버는 그 데이터베이스를 전송하지 않는다, 단지 아마 어떤 데이터베이스 레코드를 나타내는 HTML, XML 이나 JSON 등이 요청에서 구체적으로 요구되거나 서버의 구현에 따라서 예를 들어, 프랑스어로, UTF-8 로 인코딩되어 보내질 것이다.
      • 이들 representation을 통한 리소스의 조작
        • 클라이언트가 어떤 메타데이터가 첨부된 상태로 어떤 리소스의 representation을 가지고 있을 때, 만약 승인이 있다면, 서버에 있는 그 리소스를 변경 또는 삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
      • 자기-서술적 메시지
        • 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다 - 예를 들어 어떤 파서를 불러야 하는지. 그 한 예는 MIME type 과 같은 인터넷 미디어 타입의 사용을 들 수 있다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기-서술적이 아니다. 예를 들어, 단순히 “application/xml” 이라는 미디어 타입은, 코드 다운로드가 사용되지 않으면, 그 내용을 가지고 무엇을 해야할지에 대해 충분히 알려주지 못한다.
      • 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어
        • 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되어지는 representation에서 구별되어 질 수 있어야 한다. 충분한 컨텍스트 속에서의 URI 를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.
    • REST 의 주요한 목표
      • 컴포넌트의 상호 연동 상의 확장성 (scalability of component interactions)
      • 인터페이스의 범용성 (Genrality of interfaces)
      • 컴포넌트의 독립적인 배포 (Independent deployment of components)
      • 지연을 감소시키고, 보안을 강화하고, 레거시 시스템을 인캡슐레이션 시키는 중간 컴포넌트 (Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

    출처 : http://ko.wikipedia.org/wiki/REST

    REST란 대규모 네트워크 시스템을 위한 아키텍처로 2000년 Roy Fielding의 박사 학위 논문에서 처음 제안되었다. REST는 원래 웹과 같은 대규모 네트워크 시스템을 위한 원칙들의 모음을 말하는 것이지만, 요즘에는 XML과 HTTP를 사용하는 단순한 웹 기반 인터페이스(즉, REST의 원칙을 따르는 Web Services)를 지칭하기도 한다.

    Representational State Transfer은 잘 디자인된 웹 어플리케이션이 어떻게 동작하는 지에 대한 이미지를 떠올리게 하가 위한 용어이다. 웹 페이지들의 네트워크가 있고 사용자가 링크를 선택하면 다음 페이지가 보여진다. 즉 웹을 Virtual State Machine이라고 생각하면 링크를 선택함으로써 State가 변하고 Next State Representation(다음 페이지)가 보여지게 된다. 

    참고 : http://jsjang.tistory.com/62

  10. 상구랑 넘 똑같아서.ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 저런 색 팬티도 있는데.ㅋㅋㅋ

    상구랑 넘 똑같아서.ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 저런 색 팬티도 있는데.ㅋㅋㅋ