페이지

2013년 1월 28일 월요일

xml catalog in Eclipse

xml catalog in Eclipse

History

  • 2013-01-28, initial version
  • 2013-06-04, using catalogue extension point

overview

eclipse는 xml의
  • element나 attribute의 자동완성 기능
  • validation 기능
을 제공한다. 이 기능을 사용하기 위해서는 그 xml문서의 문법책이라고 볼 수 있는 dtd 혹은 xsd파일이 있어야 한다.
보통 이런 xsd 파일은 http로 공개되어져 있고 eclipse 같은 훌륭한 IDE에선 그 파일을 가져와서 xml 파일은 validation할 수 있다.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
...
위 maven xml의 경우 http://maven.apache.org/xsd/maven-4.0.0.xsd 에 xsd가 있다. 그래서 대부분의 경우 xsd가 resolve가 되면 validation이 가능하다.
하지만 특정한 경우에 xsd를 override하고 싶은 경우가 있을 수 있다. 예를 들면
  • 내부 테스트 환경에서는 xsd위치가 다르다거나
  • 로컬에서 xsd를 바꿔가며 테스트 해보고 싶은 경우
  • 서버 이상으로 xsd에 접근을 못할 경우
그럴때 eclipse에서의 xml catalog를 사용해서 xsd를 override 할 수 있다.

xml fundamental

아래 설명을 이해하려면 최소한의 xml schema에 대한 지식이 있어야 한다.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   targetNamespace="http://example.org/publishing"
   xmlns:tns="http://example.org/publishing"
>

   <!-- type definitions -->
   <xsd:simpleType name="AuthorId">
      <!-- define value space details here -->
      ...
   </xsd:simpleType>

   <xsd:complexType name="AuthorType">
      <!-- define structural details here -->
      ...
   </xsd:complexType>

   <!-- global element/attribute declarations -->
   <xsd:element name="author" type="tns:AuthorType"/>
   <xsd:attribute name="authorId" type="tns:AuthorId"/>
   ...

</xsd:schema>
  • 위에서 xmlns:xxx는 xxx에대한 namespace정의다.
  • schema 에 있는 targetNamespace 는 이 스키마의 namespace가 http://example.org/publishing 이라는 것
  • xmlns:tns가 targetNamespace와 같은 것으로 한번 더 정의한 이유는 이 스키마 내부에서 특정 엘리먼트를 reference하기 위해서다. tns:AuthorType 이나 tns:AuthorId 처럼
위 xsd에 맞게 xml을 쓸때는 아래처럼 쓴다
<x:author xmlns:x="http://example.org/publishing"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://example.org/publishing pubs.xsd"
>
...
  • xmlns:x 가 위 xsd에서 정의한 nampspace이고 그것을 사용하고 있다
  • schemaLocation에서 <namespace> <xsd uri> pair를 한개 이상 정의할 수 있다

Defining xml catalog with dtd

Defining xml catalog with xsd

Preferences>XML>Xml Catalog 에서 xml catalog를 설정할 수 있다.
<c:Catalogue xmlns:c="http://www.eclipse.org/webtools/Catalogue" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eclipse.org/webtools/Catalogue http://www.eclipse.org/webtools/Catalogue/Catalogue.xsd ">
    <c:Book>
        <title>Professional XML Schema</title>
        <date>2001</date>
        <isbn>1-861005-47-4</isbn>
        <publisher>Wrox Press</publisher>
    </c:Book>
</c:Catalogue>
방법은 2가지
namespace name으로 할경우, xsi:schemaLocation은 xml에서 제거를 해야 동작한다
이렇게 정의한 xml catalog는 import/export도 가능하다.

Defining xml catalog using extension point

preference를 이용한 xml catalog는 설정은 자신의 eclipse workspace에만 적용되는 local한 것인 한계가 있다. 내가 개발한 plugin을 사용하는 사람에게 설정을 해주고 싶다면 extension point를 이용해서 설정을 하는것도 가능하다.
org.eclipse.wst feature에 있는 "org.eclipse.wst.xml.core.catalogContributions" extension point를 이용하면 된다. 예제는 org.eclipse.wst.standard.schemas plugin의 소스를 import해서 살펴보면 어떻게 정의하고 사용하였는지 알 수 있다.

ex>
             point="org.eclipse.wst.xml.core.catalogContributions">
                        id="org.tizen.nativecpp.misc.manifest.catalog">
                              name="http://schemas.tizen.org/2012/12/manifest"
                  uri="xsd/manifest.xsd">
           

         



2013년 1월 20일 일요일

scot anderson, 최고의 아빠(dad)


아이를 키우다보면 참 어렵다고 느낄때가 많다. 어떻게 해야 좋은 아빠가 되는것인지, 좀 더 친해지려면 어떻게 해야하는지 자신감을 키워주고 싶을때 어떻게 해야하는지..
요즘 아들과 티격태격하는 나를 보더니 와이프가 빌려온 책이다. 내용도 좋고,  번역의 질도 좋다. 아마존에서 찾아보니 dad란 제목으로 parenting 부분에서 베스트셀러였다. 역시나 라고 생각했다.
약간 의외였던 것은 저자는 엄마가 집에서 아이들을 돌봐야 한다고 생각하는 것이였다. 우리의 생각과 다르지 않은 이유에서. 할머니와 베이비시터가 엄마 같은 사랑을 줄 수 있을까 생각해보면 나도 그 의견과 다르지 않다. 하지만 와이프의 커리어가 단절되는 부작용도 무시할 수 없다. 어려운 문제다.

이 책을 감히 요약해보면 이렇게 된다.

먼저 훌륭한 아빠가 되겠다는 비전을 세워야 한다. 사람은 비전이 없으면 스스로를 억제하지 못하기 때문이다.(p21)
아이들과 시간이 아닌 관계를 쌓고(양보다 질), 그 관계를 위해선 신뢰라는 기초공사를 단단히 해야 한다.(p56)
그 신뢰를 얻기위해 가장먼저 할 것은 아내를 사랑하는 일이다. 아이들의 인생에서 가장 중요한 엄마를 사랑하지 않는 아빠를 아이들이 어떻게 신뢰할 수 있을까. 훌륭한 남편 다음이 훌륭한 아빠의 자격이 있다. (p72)
아내의 사랑을 얻기위한 방법들:
. 퇴근해 집에 온후 15분은 아내를 위한 시간으로 할애하라
. 아내의 필요를 충족하라(아이와 함께 엄마의 선물을 준비)
. 이혼을 입에 올리지 말고
. 아내와 정기적으로 데이트 하고
. 사랑한다고 소리내어 말하고
. 애정을 표시하고
. 아내와 한편이 되어라

가족과 좋은 추억을 쌓아라.
명심하라. 인생이란 추억거리를 만다는 과정이다. 가족의 추억을 만드는 것은 아빠의 책임이다. 어릴때 다양한 추억을 만들어주고 함께 시간을 보낸다면, 아이들은 커서도 당신과 계속해서 추억이 될 시간을 함께 부내고 싶어할 것이다. 가족에게 멋진추억을 심어주지 않았으니 멋진 추억을 수확한다는 것은 당연히 불가능하다.(p126)
. 아이들이 어릴때부터 당신과 함께 보내는 시간을 소중하게 여긴다면, 당신이 나이가 들었을때 그들도 당신과 보내는 시간을 소중히 여길 것이다.(p134)

아이들과의 약속은 꼭 지켜야 한다. 신뢰의 문제이므로..
약속을 할때는 지킬 수 있다는 확신이 있을때에만 하라(p168)


아들의 사랑의 언어를 파악하고 그 언어로 사랑을 말하자. (사람마다 사랑을 표현하는 방식과 느끼는 방식이 다르다)
5가지 사랑의 언어
. 선물
. 도움
. 함께 보내는 시간
. 격려
. 애정표현

듣기는 속히 하고 말하기와 성내기는 더디하라(p215)

말다툼에서 이기는 유일한 방법은 말다툼을 피하는 것이다.(p225) 왜냐하면 상대방의 의견이 틀렸다는 것을 설득했다 하더라도 그의 의견은 변하지 않기 때문이다. (p226)


격려와 칭찬을 통해 아이의 자존감을 키워줘야 한다. 능력이 있든 없든 매력이 있든 없든 계속해서 우리에게 좋은 말들을 해주는 머릿속 녹음기를 우리는 자존감이라고 부른다.(p257)

예를 들면 이렇게 말해주며 같이 꾸준히 야구 연습을 해준다. 그러다 보면 진짜 실력이 좋아질 것이고.. 뭐든 노력하면 이렇게 할 수 있구나 란 것을 느끼게 해주면 된다.
- 야구못하겠어요.
+ 아들아 너는 아주 잘하고 있어. 넌 뭐든 노력하면 잘하잖니? 이번주에 조금만 더 연습하면 돼. 방금전에 네가 잡아냈던 공 기억하지? 정말 대단했어
- 하지만 아빠. 난 매번 삼진아웃 당하는 걸요.
+ 아들아, 지난 번에 아빠랑 같이 봤던 야구 경기 기억나? 세계 최고의 타자인 새미소사도 삼진아웃 당했잖니(p260)
. 내가 내 자신을 어떻게 보느냐에 따라서 세상이 나를 어떻게 보느냐가 결정된다. (p266)

낳아준 아빠 -> 부양하고 보살피는 아빠 -> 관계를 쌓는 아빠 로 진화해 가야 한다(283)


아이들은 자기행동의 결과를 예상할수 있을때 훨씬 안정적이고 행복하게 지낼수 있다. 그러므
로 훈육에 일관성이 있어야 한다. (p312)

아이가 무언가 실수를 했을때는 이런 패턴으로 말을 하자.
유리잔에 우유가 들어있을때는 조심해서 행동해야지. 자 흘린 우유는 네가 치우렴. 유리잔에 든 우유를 네 스스로 책임지지 못한다면 할 수 있을때까지 빨대를 사용할 거야(332)

통계적으로 책을 처음 한번 읽으면 전체 내용의 20파센트만 기억한다고 한다.(348) 그러니 이책을 몇번 더 읽으라

2013년 1월 19일 토요일

git

내가 여지껏 써본 revison control software(RCS) 는 소시적 MS SourceSafe , Rational ClearCase, Perforce, Git 등이 있다.

Clearse에서 Peforce로 처음 바꿨을때 그 속도에 감탄했었다.  Peforce가 빨랐다기 보다는 ClearCase가 너무나 느렸던 탓이다. 실제로 Perforce와 SVN의 속도를 비교해보면 p4가 더 빠르긴 하지만 큰 차이는 없는 것으로 알고 있다.

git을 반년정도 써오고 있는데 지금까지는 아주 basic한 workflow만 써오다가, 복수개의 remote 서버를 추가해서 로컬 브랜치로 만들고 각 브랜치 간의 머지 및 integration을 로컬에서 할 수 있음을 알고는 git의 강력함을 느꼈다.

시나리오를 만들어 보면

  • git remote 서버들
    • team의 master 서버인 origin
    • 오픈소스여서 대외적으로 공개될 git인 rsa
  • 로컬 브랜치들
    • develop : origin/develop
    • release : origin/release
    • rsa : rsa/master
  • workflows
    • dev 에 비교적 unstable한 코드들을 넣고  커미하고 자가 검증
    • integration을 하기 위해 최신 develop 브랜치 로 release로 overwrite하고 integration build를 만들어서 검증팀에 주고 디펙 수정
    • 각 마일스톤 별로 release criteria를 만족하면 rsa로 push
    • rsa에서 디펙 어싸인이 되면 rsa브랜치에 quick fix를 하고 develop 브랜치에 머지
    • release 디펙 어싸인되면 release브랜치에 quick fix를 하고 develop에 머지
위 workflow를 git이 아닌 p4로 한다고 생각하면 일이 생각보다 복잡해진다.
  1. 우선 develop/ release, rsa의 working copy를 만들어야 한다. 대부분의 코드는 같을 것이기 때문에 여기서 많은 하드 공간이 낭비된다. git은 같은 hash를 가지면 그것을 브랜치 간에 share하기 때문에 엄청난 효율을 가질 수 있다. perforce도 서버단에서는 같은 오브젝트임을 알지만 로컬에  N번의 working copy를 sync해야 하는 것은 어쩔 수 없는 비효율
  2. 1에서 만약 rsa가 물리적으로 다른 서버라면 서버단에서도 같은 오브젝트가 아닌 다른 오브젝트로 인식할 것이므로 또 비효율이 발생할 수 있다.
위 시나리오에서 브랜치가 더 늘어나고 remote더 늘어날 수록 개발자가 감당해야 하는 복잡함은 perforce쪽이 더 많아 진다. peforce 대신에 Centralized RCS 로 단어를 바꿔도 같은 뜻이 된다. 즉, Centralized계열의 한계라고 볼 수 있다.

게다가 훌륭한 code review툴인 gerrit까지 무료로 쓸 수 있지 않은가
RCS가 git으로 천하통일 될 수 밖에 없는 이유 되겠다.






2013년 1월 15일 화요일

돈으로 의지를 살 수 있는가

요즘 레슨을 받으며 느끼는 것이 있다.

레슨을 받으면
불과 이십분만에 땀을 뻘뻘 흘리고 숨이 차다.
근데 이것을 혼자서 이렇게 해보려고 하면 절대 이런강도가 나오지 않는다.
너무 힘들면 그만해 버리기 때문이다.

PT도 마찬가지
PT할때는 운동도 잘되고 근육붙는게 눈에 보인다.
하지만 PT가 끝나고 혼자 헬스장을 다녀보면
그 근육들은 금방 풀어져 버린다.
한번씩 빠지기도 하고
음식 조절에도 실패하기 때문에

돈을 내고 레슨/PT을 받으면
내가 지불한 돈의 가치때문에
빠뜨리지 않고 하게 되고
강사가 극한으로 잘 이끌어 준다.

이는
돈으로 강사의 시간을 사서 나의 시간을 save하는 것이며
한편으로는
나약한 의지를 돈으로 사는 것이다.

매일 운동 하는게 힘들다면
적지않은 돈을 지불하고 운동을 해보자
의지가 충만해질테니까