Skip to content

부모 노릇으로부터의 자유 / 한국, 한국인, 한국사람, 한인사회

개인적으로나 회사내에서나 큰 변화를 겪고 있는 요즈음이다.

막 석달째 접어든 아기의 커가는 모습을 보며 자연스레 많은 생각을 하게 된다. 여기 독일환경에서 아이를 키우는 것이 왠지 탐탁치 않지만, 지금 한국 아이들의 실망스러운 면면을 보면 한국에서 애를 키우는 것이 좋을리 없다는 생각도 든다. (부모 입장에서건, 애들 입장에서건)

마침 관련된 좋은 글을 우연히 읽은 터라 링크해놓는다.
직접적인 관계는 없다만 많은 것을 느끼게 해주는 글이었다.

간단한 노후 재테크 – 부모 노릇으로부터의 자유

한국, 한국인, 한국사람, 한인사회

Tagged , ,

credit, debit

자주 헷갈리는 debit / credit 란 단어의 사용을 정리 좀 해보자.

먼저, credit는 가치 있고 득이 되는 것, 특히 동사로 쓰이면 가치 있는 것을 주는 것을 의미한다. 물론 그 반대는 debit이고.

1. 은행잔고 쪽에서 사용되는 예를 보면,

  • You have a credit balance of $300. → credit balance는 플러스 잔고를 의미.
  • I was relieved to see that my account was in credit. → 위와 비슷한 의미.
  • Interest will be levied if your account is in debt. → levy는 세금, 이자 따위를 부과한다는 의미이다.

2. 회계에서는 debit는 차변, credit는 대변으로서 ledger(원장)에서 각기 왼쪽, 오른쪽에 위치하게 된다.

3. 동사 또는 명사로 credit는 입금, debit은 출금의 의미로 많이 쓰인다. 아래 예를 보면,

  • Your account has been credited with $50000. → 당신 계좌에 오만 달러가 입금되었습니다. 같은 의미로, $50000 has been credited to your account.
  • You’ll be paid by direct credit into your bank account. → 보수는 당신의 은행 계좌로 바로 입금됩니다.
  • Interest is calculated daily and credited once a year.
  • The bank debited the money from my account.

여기서 조금 샛길로 빠지면, 은행으로 들어오면 credit, 나가면 debit이라 하더라도 accounting 관점에서는 조금 고려할 사항이 있다. 이에 대해 흥미로운 글이 있다.

4. 신용관계에서는 조금 복잡한데, 같은 빚이라도 가치가 있는 것을 주거나 받는다는 관점에서는 credit, 갚아야 할 부담이라는 관점에서는 debt를 쓴다.

  • The bank refused further credit to the company. → 은행이 더이상의 신용거래(융자)를 거절했다.
  • We bought that machine on credit. → 외상으로 샀다.
  • I need to pay off all my debts before I leave the country.

그밖에 credit는 인정, 칭찬 등의 의미가 있는데, 이는 논외로 하자.

젊음

젊음은 인생의 한 시기가 아니라 마음의 상태다.
그것은 장미빛 뺨도, 빨간 입술도 아니며 나긋나긋한 무릎도 아니다.
그것은 의지와 상상력이며 활력이 넘치는 감성이다. 그것은 삶의 깊은 샘에서 솟아나는 신선함이다.

젊음은 용기가 비겁함을 누르는 것을 뜻하며 안이함을 떨쳐 버리고 모험에 나서는 것을 뜻한다.
이런 성향은 때로는 20살의 청년에게서가 아니라 60살의 노인에게서 발견되기도 한다. 나이만 먹는다고 늙는 것이 아니다. 이상을 버릴 때 우리는 늙는 것이다.

나이는 피부에 주름살을 만들지만, 열정이 식어 버리면 정신에 주름살을 만든다. 걱정과 두려움과 자기불신은 용기를 꺾고 정신을 죽여 버린다.

60살이든 16살이든, 사람의 가슴 속에는 경이로움에 끌리는 마음, 미지의 것에 대한 꺼지지 않는 호기심 그리고 삶이란 게임에서 느끼는 기쁨이 있게 마련이다.
당신과 내 가슴의 한복판에는 무선전신국이 있다. 그 무선전신국이 인간과 신神에게서 오는 아름다움, 희망, 환호, 용기 그리고 힘의 메시지를 수신하는 동안은 당신은 젊은 것이다.

안테나가 내려지고 당신의 정신이 냉소의 눈雪과 비관의 얼음으로 덮이면, 당신은 나이가 20살이라도 늙은 것이다.
반면 안테나가 올라가 있고 그 안테나를 통해 낙관의 전파를 수신한다면, 당신은 나이가 80살이라도 젊은 채로 죽을 수 있는 것이다.

– 새뮤얼 울먼의 수필, 리더스 다이제스트 1991년 3월호에서 발췌

Tagged ,

Supremo, Maragogipe

그윽하고 약간 신 끝맛이 일품인 Supremo. 원두를 갈 때 향이 정말 기가 막힌, 가장 즐겨먹는 커피이다.

20100609_coffee2

얼마전 Supremo를 사면서 Maragogipe를 한 번 250g 사보았다. 멕시코 산, 일명 ‘엘리펀트 빈’이라고 한다는데 갈아보니 향이 Supremo 못지 않다.
맛은 약간 연해서 아침에 먹기 좋을 듯.

20100609_coffee1

사진에서는 그리 커보이지 않지만 콩이 꽤 크다.

Tagged ,

Pacifier

쭉쭉이 또는 공갈젖꼭지 – 영어로는 pacifier, 독일어로는 der Schnuller라고 한다.
아기용품 제조회사로 유명한 NUK는 Beruhigungssauger라고 해서 헷갈리게 하기도 한다.

아이가 너무 젖을 보채는 것 같아 공갈젖꼭지를 한 번 써보려고 BabyOne에 들렀는데 세상에나… 그 종류의 방대함에 질려버렸다. 공갈젖꼭지에 그렇게 많은 취향이 존재할 수 있는 것이다. (예를 들어 NUK의 제품들 일부를 한번 보기)

갈등 끝에 NUK 제품 중 ‘Soft’란 것을 사 와서 급하게 물렸는데 – 제대로 소독도 안 했지만 마음이 너무 급했다 – 잠깐 물더니 가차없이 뱉어버린다. 육아책을 보니, 엄마 젖꼭지와 혼란을 일으킬 수 있기 때문에 특히 신생아의 경우에는 쓰면 안된다고 한다. 거 참, 복잡하구먼.

추: 공갈젖꼭지의 소독법을 설명하는 페이지가 있었다. (사실 특별한 것은 없고, 그냥 끓는 물에 소독하면 됨)
여기 가 보면, 기본적이지만 꽤 괜찮은 다른 정보들도 비디오로 소개하고 있다.

Tagged ,

Package example in ABAP, 두번째

지난 번과는 반대로, subpackage가 superpackage의 object를 억세스하려 할 경우를 생각해보자.

20100610_package_inf_1

  1. SE80 open.
  2. 먼저 subpackage와 superpackage 양쪽에 Package Interface가 있나 확인해보자. 없으면 만들자.
  3. superpackage의 Package Interface를 더블 클릭. 두 개의 탭이 나오는데 ‘Exposed Objects’를 클릭, 노출할 object를 추가한다. (드래그 앤 드롭으로 쉽게 된다)
  4. 20100610_package_inf_2

  5. 다음에 바로 옆의 탭인 ‘Attributes’ 클릭. 하단에 ‘Visible for subpackages’에 체크한다.
  6. subpackage 이름을 더블 클릭, ‘Dependency Control List’ 탭을 연다. Add 버튼을 누르고 superpackage의 Package Interface를 추가한다.
  7. 20100610_package_inf_3

Tagged , ,

SWIFT MT103

  • SWIFT(the Society for the Worldwide Interbank Financial Telecommunication)는 표준화된 글로벌 금융 트랜잭션 개발을 위한 조직이다.
  • SWIFT 멤버는 목적에 따라 MT100 ~ MT999의 메시지를 생성하며 이는 SWIFT로 전달, 수신자(다른 SWIFT 멤버)로 전달된다.
  • SWIFT MT103은 다른 나라 은행으로의 payment를 위해 가장 보편적으로 사용되는 포맷이다. 기존 single payment를 위해 사용된 MT100의 향상된 버젼으로 무척 많은 옵션을 가지지만 이로 인해 너무 flexible하다는 문제가 생겨 요즘은 MT103+를 사용하는 추세다.
  • MT103과 MT103+ 메시지가 수신은행에서 올바르게 해석되기 위하여 파일 내에 포함된 ‘bank details’ (IBAN과 BIC details 포함) 은 반드시 정확해야 한다.
Tagged ,

The Iterator Pattern (in ABAP)

20100606_iterator

Iterator를 사용해서 구현과는 분리하여 하나 하나 요소들을 셀 수 있다.
아래 소스를 보면 loop를 돌 때 Iterator의 메소드만 이용하고 있으며 Aggregate 클래스가 어떤 식으로 구현되어 있는가 – 배열이든, 벡터든, Internal Table이든 – 는 상관없다. 즉 나중에 Aggregate의 요소 관리 방식을 얼마든지 바꿀 수 있다는 이야기.
이를 위해 아래와 같은 것들이 필요하다.

  • Iterator 인터페이스.
  • Aggregate 인터페이스. Iterator 인터페이스 타입의 객체를 리턴하는 메소드를 제공.
  • ConcreteIterator. Iterator 인터페이스를 구현한다. 구체적으로 어떤 놈을 어떻게 돌아야하는지 알고 있어야 하기 때문에 ConcreteAggregate의 객체를 내부에 가지고 있다.
  • ConcreteAggregate. Aggregate 인터페이스를 구현한다. 자신을 인자로 넘겨주면서 ConcreteIterator를 생성한다.

헷갈리기 쉬운게 Next()와 hasNext()인데,

  • Next() 호출시 현재 요소를 리턴하면서 내부적으로 다음 위치로 이동하게 된다.
  • hasNext()는 최후의 요소를 얻기 전에는 true를 리턴하고 최후의 요소를 얻은 후에는 false를 리턴한다. 다음에 Next()를 호출해도 괜찮은지 조사하는 메소드로 이해하면 된다.

아래는 해당 소스.


*&---------------------------------------------------------------------*
*& Report  ZP_ITERATOR
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*

REPORT  zp_iterator.

*PARAMETERS:

*----------------------------------------------------------------------*
*       INTERFACE lif_iterator
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
INTERFACE lif_iterator.
  TYPE-POOLS abap.

  METHODS: has_next RETURNING value(r_flag) TYPE abap_bool,
           next RETURNING VALUE(r_obj) TYPE REF TO object.

ENDINTERFACE.                    "lif_iterator

*----------------------------------------------------------------------*
*       INTERFACE lif_aggregate
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
INTERFACE lif_aggregate.

  METHODS iterator RETURNING VALUE(r_it) TYPE REF TO lif_iterator.

ENDINTERFACE.                    "lif_aggregate

*----------------------------------------------------------------------*
*       CLASS lcl_book DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_book DEFINITION.

  PUBLIC SECTION.
    METHODS: constructor IMPORTING i_name TYPE string,
             get_name RETURNING value(r_name) TYPE string.

  PRIVATE SECTION.
    DATA m_name TYPE string.

ENDCLASS.                    "lcl_book DEFINITION

*----------------------------------------------------------------------*
*       CLASS lcl_bookshelf DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_bookshelf DEFINITION.

  PUBLIC SECTION.
    INTERFACES lif_aggregate.
    METHODS: get_book_at IMPORTING i_idx TYPE i
                         RETURNING VALUE(r_book) TYPE REF TO lcl_book,
             append_book IMPORTING i_book TYPE REF TO lcl_book,
             get_length RETURNING value(r_last) TYPE i.

  PRIVATE SECTION.
    DATA: m_books TYPE STANDARD TABLE OF REF TO lcl_book,
          m_last TYPE i.

ENDCLASS.                    "lcl_bookshelf DEFINITION

*----------------------------------------------------------------------*
*       CLASS lcl_bookshelf_it DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_bookshelf_it DEFINITION.

  PUBLIC SECTION.
    INTERFACES lif_iterator.
    METHODS constructor IMPORTING i_bookshelf TYPE REF TO lcl_bookshelf.

  PRIVATE SECTION.
    DATA: m_bookshelf TYPE REF TO lcl_bookshelf,
          m_idx TYPE i VALUE 1.

ENDCLASS.                    "lcl_bookshelf_it DEFINITION

*----------------------------------------------------------------------*
*       CLASS lcl_book IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_book IMPLEMENTATION.

  METHOD constructor.
    m_name = i_name.
  ENDMETHOD.                    "constructor

  METHOD get_name.
    r_name = m_name.
  ENDMETHOD.                    "get_name

ENDCLASS.                    "lcl_book IMPLEMENTATION

*----------------------------------------------------------------------*
*       CLASS lcl_bookshelf IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_bookshelf IMPLEMENTATION.

  METHOD get_book_at.
    READ TABLE m_books INDEX i_idx INTO r_book.
  ENDMETHOD.                    "get_book_at

  METHOD append_book.
    APPEND i_book TO m_books.
  ENDMETHOD.                    "append_book

  METHOD get_length.
    r_last = lines( m_books ).
  ENDMETHOD.                    "get_length

  METHOD lif_aggregate~iterator.
    CREATE OBJECT r_it TYPE lcl_bookshelf_it EXPORTING i_bookshelf = me.
  ENDMETHOD.                    "lif_aggregate~iterator

ENDCLASS.                    "lcl_bookshelf IMPLEMENTATION

*----------------------------------------------------------------------*
*       CLASS lcl_bookshelf_it IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_bookshelf_it IMPLEMENTATION.

  METHOD constructor.
    m_bookshelf = i_bookshelf.
  ENDMETHOD.                    "constructor

  METHOD lif_iterator~has_next.
    IF m_idx <= m_bookshelf->get_length( ).
      r_flag = abap_true.
    ELSE.
      r_flag = abap_false.
    ENDIF.
  ENDMETHOD.                    "lif_iterator~has_next

  METHOD lif_iterator~next.
    r_obj = m_bookshelf->get_book_at( m_idx ).
    ADD 1 TO m_idx.
  ENDMETHOD.                    "lif_iterator~next

ENDCLASS.                    "lcl_bookshelf_it IMPLEMENTATION

*----------------------------------------------------------------------*
*       CLASS demo DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS demo DEFINITION.

  PUBLIC SECTION.
    CLASS-METHODS: main.

ENDCLASS.                    "demo DEFINITION

*----------------------------------------------------------------------*
*       CLASS demo IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS demo IMPLEMENTATION.

  METHOD main.
    DATA: lr_bookshelf TYPE REF TO lcl_bookshelf,
          lr_book_1 TYPE REF TO lcl_book,
          lr_book_2 TYPE REF TO lcl_book,
          lr_book_3 TYPE REF TO lcl_book,
          lr_book_4 TYPE REF TO lcl_book,
          lr_book_5 TYPE REF TO lcl_book,
          lr_it TYPE REF TO lif_iterator,
          lr_book TYPE REF TO lcl_book,
          lv_str TYPE string.

    CREATE OBJECT: lr_bookshelf,
                   lr_book_1 EXPORTING i_name = 'Around the world in 80 days',
                   lr_book_2 EXPORTING i_name = 'Bible',
                   lr_book_3 EXPORTING i_name = 'The Lord of the Rings',
                   lr_book_4 EXPORTING i_name = 'Jonathan Livingston Seagull',
                   lr_book_5 EXPORTING i_name = 'The Keys of the Kingdom'.

    lr_bookshelf->append_book( lr_book_1 ).
    lr_bookshelf->append_book( lr_book_2 ).
    lr_bookshelf->append_book( lr_book_3 ).
    lr_bookshelf->append_book( lr_book_4 ).
    lr_bookshelf->append_book( lr_book_5 ).

    lr_it = lr_bookshelf->lif_aggregate~iterator( ).

    WHILE lr_it->has_next( ) = abap_true.
      lr_book ?= lr_it->next( ).
      lv_str = lr_book->get_name( ).
      WRITE: / lv_str.
    ENDWHILE.
  ENDMETHOD.                    "main

ENDCLASS.                    "demo IMPLEMENTATION

START-OF-SELECTION.
  demo=>main( ).
Tagged , , ,

Audio Physic의 Sitara, 그리고 Marantz 앰프

Nubert 스피커를 구입하기로 굳게 마음을 먹었건만, 지난 월요일(17일) 갑자기 Audio Physic을 꼭 들어봐야겠다는 생각이 들었다.
이것도 인연因緣인가 싶다. 지난 High End 전시회에서 처음 접했을 때 느낌 – 어떤 꾸밈도 없이 있는 소리 그대로를 재현하려 하는, 수수하다고 할까 심플하고 모던하다고 할까 – 이 의외로 강한 인상을 남겼나보다.

공교롭게도 근방에 Audio Physic 스피커를 취급하는 가게는 일전에 방문했던 ‘Expert Galerie’였다. 아내도 지난 전시회를 계기로 오디오에 대한 관심이 많아진 터라 꽤 흥미를 가지고 같이 방문했다.

담당자에게 Sitara 셋팅을 부탁한 다음, Nubert Shop에서 테스트해보았던 CD들 – 굴드의 골드베르그 변주곡, 번스타인의 브람스 1번 교향곡, 하이든의 실내악 등등 – 을 들어보았다.
결정은 어렵지 않았다. 어떤 류의 음악이든 훌륭한 소리를 보여주었던 Cardeas보다는 못해도, 들어보면 들어볼수록 강한 확신을 주는 – 바로 이거다, 이 스피커를 사면 절대 후회하지 않을 것이다 – 제품이 바로 Sitara였다.
막판에 같은 Audio Physic의 ‘야라’와 Focal의 ‘Chorus 826′을 두고 약간 마음이 흔들리긴 했지만, 주로 듣는 고전음악에서는 Sitara가 월등한 소리를 들려주었다. 야라는 팝음악에서 더 다이나믹한 소리를 들려주었고, Chorus 826에서는 최상은 아니더라도 Focal의 성격이 살아있는 음을 들을 수 있었다. (Chorus의 경우 2,300유로를 1,500유로에 할인해서 판다는 말에 많이 끌리긴 했다)

스피커를 결정하고 나니 앰프가 문제였다. Audio Physic을 취급하는 이 가게는 상대적으로 제한된 종류의 앰프만 취급하고 있었고, 나는 한꺼번에 구입 하기를 원했기 때문이다. (여기도 흥정을 한다)
야마하나 캠브리지 오디오도 고려하다가 결국 로텔과 마란츠를 들어보기로 결정했다. 특히 로텔에 기대를 많이 했는데 평도 좋았거니와 Sitara와 잘 어울린다는 이야기를 들은 적이 있었다.

사실, 스피커가 중요하지 앰프가 소리를 크게 좌우한다고 생각하진 않았다. 하지만 목요일에 다시 방문해서 비교 청음을 해보니, 리시버와 일반 앰프는 정말 틀리다, 이건 막귀도 알 수 있겠다 – 는 것을 새삼 느꼈다.
게다가, 적어도 로텔과 Sitara는 아니었다. Sitara의 투명하고 청명함을 이 앰프는 다 지워버리고 있었다.
반면 마란츠의 앰프는 내가 좋아하는 Sitara의 장점을 잘 살려주고 있었다. 오히려 약간의 가미 – 따뜻함 – 가 있는 듯 하긴 했지만.

지난 주말 물건을 가져와서 셋팅을 마치고 듣고 있자니, 그냥 좋다는 생각밖에 안 든다.
무척 행복하다.

Tagged , ,

Defining Exception Classes

모든 exception class는 아래 3가지 class들 중 하나의 subclass가 되어야 한다. 이 3개의 class들은 CX_ROOT로부터 파생된 것이지만, 내가 직접 CX_ROOT로부터 파생된 class를 만들어 사용할 수는 없다.

  • CX_STATIC_CHECK
  • CX_DYNAMIC_CHECK
  • CX_NO_CHECK

언제 어떤 것을 사용하느냐 – 를 생각해보자. 약간씩 틀리긴 하다.

20100528_exception

Subclasses of CX_STATIC_CHECK
The relevant exception must either be handled, or propagated explicitly using the RAISING addition. If this is not the case, the syntax check displays a warning.
If you define your own exception classes, CX_STATIC_CHECK is defined as the superclass by default.

Subclasses of CX_DYNAMIC_CHECK
You must either handle them or explicitly propagate them using the RAISING addition. The difference is that this is not statically checked. No syntax warning is reported if the exception is neither handled nor propagated. If the exception is then raised, a runtime error occurs.
Typical examples of this situation are the predefined exceptions CX_SY_… for errors that occur in the runtime environment. These are usually subclasses of CX_DYNAMIC_CHECK.

Subclasses of CX_NO_CHECK
The corresponding exceptions cannot be propagated explicitly using the RAISING addition. These exceptions can be handled. Otherwise they are automatically propagated. Neither a syntax warning nor a runtime error is caused directly where it is raised. Instead all exceptions that are not handled somewhere in the call hierarchy are propagated up to the highest call level. If it is not caught there either, a runtime error occurs at that point.
Some predefined exceptions with the prefix CX_SY_… for error situations in the runtime environment are subclasses of CX_NO_CHECK.

여기를 참고하도록.

Tagged