출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
유명한 자바책 중 하나인 이펙티브 자바입니다. 이제서야 보았습니다. 이책은 이펙티브 자바의 1판입니다.
책을 사고나서 제일 안타까운 것중 하나가 아직 다 보지도 않았는데 2판이 나왔을때 입니다. 다 보고난 후라면 2판이 나와도 그다지 안타깝지 않지만 기술서적이 소설책처럼 배송받아서 바로 보고 그러지 않다 보니 사놓고 못보는 책도 있고 좀 다른거 하다가 보기도 하는데 이펙티브자바는 책이 너무 오래되서(2003년도 책이죠) 어쩔까하다가 그래도 좋다는 얘기가 나와서 샀더니만 다 보기도 전에 2판이 등장해 주셨습니다. ㅡ..ㅡ
이 책은 자바라는 언어의 사용법을 설명하고하는 그런 책은 아닙니다. 이펙티브 자바라는 이름처럼 자바를 효과적으로 사용하는 방법을 알려주는 책으로 총 57가지 항목의 자바개발을 하면서 해야할 것과 하지 말아야 할 것을 설명해 주고 있습니다.
자바를 시작하면서 볼만한 책은 아니고 초보를 띄고 좀더 심도깊게 자바를 익히고자 한다면 옆에 두고두고 볼만한 책이라고 느껴집니다. 단순히 습관처럼 사용하고 왜 사용하지 모르던 것들을 간단한 소스코드와 함께 왜 하면 안되고 어떤 문제가 있는지. 어떻게 사용하면 어떤 효과가 있는지 자세하게 설명하고 있고 여기에서 나온 내용을 다 이해하지 못했음에도 불구하고 저자인 조슈아 블로치가 자바라는 언어에 대한 이해의 깊이를 느낄 수 있었습니다. 이런 식의 팁은 범위도 다양하게 제공하고 있기 때문에 한번에 다 적용하기는 무리라고 생각되기 때문에 자바개발을 하면서 옆에 두고 차례차례 적용해서 자신의 것으로 만들면 실력향상에 큰 도움이 되리라 생각됩니다.
물론 이 책은 2003년 5월에 나온 책이기 때문에 Java의 버전이 오래되었습니다. 1.4가 막 출시되었을 때 쯤인것 같고 책의 소스는 1.3을 기반으로 작성되었는데 지금은 Java 6을 쓰고 있기 때문에 오래된 내용도 있습니다. 그래서 이 책을 보는 것이 의미가 있을까 하는 생각도 하였었지만 많은 변화가 있었다고 하더라도 그 기반은 Java 1.3에서 이어진 것이기 때문에 현재 사용안한다고 하더라도 볼만한 가치가 있다고 생각됩니다.
개발도 습관이 중요하다고 생각하는데 초중반에 기본을 다질때 중요한 밑거름이 될 책입니다. 유명한 책은 괜히 유명한것은 아닌것 같군요. ㅎ 그래도 1.3기반으로 작성되어 있기 때문에 별은 4개만....
My Comment..
습관적으로 사용하지만 모르는 것들.. 꼭 내 얘기 같넹.. 블로그를 처음 시작하게 된 계기도.. 햄의 블로그를 지속적으로 다 읽어보는 이유도 다 거기에 있다.. 습관적으로 쓰고, 아웃풋을 위해서 무작정 쓰고나서는 모르던 것들을.. 나름 나만의 이해방식을 통해서 정리를 하려고 말이다.. 봐둔다면 좋은 습관으로 개선하는데 도움이 되지 않을까..
2016년 3월 3일 목요일
[EP]켄트 벡(Kent Beck) 초청 세미나 #2..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
점심시간을 이용한 싸인회가 진행되었습니다.
XP냐 TDD냐 고민을 좀 했습니다만 저한테는 XP보단 TDD가 더 인상적인것 같아서 TDD에다가 싸인을 받았습니다. 개발자의 싸인을 받는다는 것에 대해서는 고민되는 문제이기는 하지만 그냥 평범한 사람으로써 유명한 사람을 봤다는 것으로 봤을때 그리 심각하게 받아들일 이유도 없는 것 같아서 싸인받았습니다. 역자인 김창준씨 싸인도... ㅎㅎㅎㅎㅎ
오전에는 좀 Responsive Design에 대한 개념적인 배경을 설명하느라고 추상적인 얘기도 많았고 이름으로도 느껴지듯이 완전 쇼킹하게 새로운 것은 아니기 때문에 좀 뻔한 내용도 없잖아 있었습니다. 세미나장소 뒤쪽에서 포스트잇으로 진행된 회고에서도 오전이 너무 뻔한 내용이라는 지적도 있었습니다.
설계
디자인할 때는 리팩토링 얘기는 하지 않습니다. 리팩토링은 좋은 디자인 기법중의 하나이지만 맥락을 이해하지 못하면 어떤것이 좋고 나쁜지를 알 수 없기 때문입니다.
설계는 어떻게 하여야 하는가.
설계에는 불확실성이 많이 있습니다. 모든 것이 확실하다면 피드백이 필요없습니다.
디자인의 정의
디자인의 정의는 서로 이익을 주는 관계요소(Beneficially Relating Elements)입니다. 아키텍쳐를 포함해서 모든 것이 디자인이지만 상황마다 제약요소는 다릅니다. 반응적 디자인은 스케일의 변화에도 반응할 수 있습니다.
Coupling & Cohesion
커플링은 Designer에게 가치있는 개념입니다. 커플링은 한 요소의 변경이 다른것을 바꾸게 하는 것입니다. 잠재적으로 커플링 되어 있다고하더라도(이론적으로) 만약 절대 안바꾸게 된다면 커플링을 볼 수 없습니다. web site가 클수록 잠재적 커플링도 늘어납니다.
Cohesion은 커플링의 역입니다. 한 서브 엘리먼트의 변경이 다른 모두를 바꾸도록 요구하는 것으로 커플링이 높으면 코히즌은 낮아집니다. 커플링을 찾는 것은 어렵지만 코히즌은 찾기가 쉽기 때문에 코히즌을 늘리고 커플링을 낮춰야 비용이 내려갑니다.
(사실 커플링과 코히즌은 제가 경험도 적고 잘 개념을 이해하지 못했습니다. 들리는대로 정리하긴 했는데 사실 감은 잘 안왔습니다. 이부분에 대해서는 토비님의 변화의 비용으로 설명하는 결합(coupling)과 응집(cohesion)을 읽어보시면 더 도움이 되실듯 합니다.)
Responsive Designer의 구체적인 방법
드디어 반응적 설계에 대한 얘기가 본격적으로 나왔습니다.
안전한 단계 (Safe Steps)
변경할 때는 작은 단계로 변경합니다. 물론 너무 작으면 효율성이 저하됩니다. 안전성이 더 중요하기 때문에 안전성을 확보한 다음에 효율성을 생각합니다. 안전한 단계를 자동화(이클립스의 리팩토리등)하는 것이 방법이라고 할 수 있습니다. 이 단계를 연습을 통해서 더욱 빨리 할 수 있습니다.
가장 안좋은 것은 작업을 하다가 문제가 발견되어 지난 작업의 기억들을 더듬어서 다시 롤백하게 되는 것으로 이렇게 되면 영향이 어디까지 미치었는지도 파악하기 어렵고 Steady Flow of Feature를 방해하게 됩니다.
안전한 단계를 활용하여 속도를 높여야 합니다.
전략 (Strategies)
켄트벡이 작업을 하면서 실험적으로 디자인 변화한 것들을 카드로 적어서 그룹화 하니까 총 4가지로 분류되었습니다. 그 이전에는 디자인은 예술이라고 생각하고 있었지만 정리를 하고나서 보니 켄트벡이 오직 4가지전략만 사용하고 있었습니다. 이 4가지는 Leap, Parallel, Stepping Stone, Simplification입니다.
어떤 디자인을 사용할 지 보인다면 Leap과 Parallel을, 어떤 디자인을 사용할 지 알수 없다면 Stepping Stone, Simplification을 사용합니다.
Leap Strategy
자신이 원하는 구상의 디자인을 알 경우에 사용합니다. 일단 새로 만듭니다. 이는 효율성은 높고 쉽지만 리스크는 있습니다. Leap전략을 취했을 때 생각하지 못한 문제가 발생하게 되면 Debug하는데 오래 걸리게 됩니다. Kent는 Leap을 사용하는 빈도수가 다른 사람들보다는 적다고 합니다.
Parallel Strategy
이 경우도 역시 원하는 디자인을 알 경우에 사용합니다. Parallel전략은 예전 디자인과 새로운 디자인을 동시에 운영하는 방법으로 레가시를 교체하는데 주로 이용합니다. 안정성이 높습니다.
Stepping Stone Strategy
자신이 원하는 디자인을 모를 경우에 사용하며 정확히는 모르지만 어떤기능이 있으면 목적에 근접할 수 있을 것이라고 생각되면 그것을 만들는 식의 방법으로 접근합니다. Stepping Stone전략은 너무 많은 것을 만들 수 있는 오버엔지니어링의 위험이 있기 때문에 필요한 것만 만들도록 해야 합니다. 또다른 단점으로는 이 과정 중에는 피드백이 없습니다. 필요할 때마다 구축하는 방법으로 접근해야 합니다.
Simplification Strategy
자신이 원하는 디자인을 모를 경우에 사용하며 경험이 많은 사람들이 주로 이용합니다. 최종적인 디자인이 확정되지 않은 상태로 요구사항중에 어딘가에 기능의 핵심이 있기 때문에 요구사항을 제거해 나가면서 핵심을 찾는 식으로 접근합니다. 핵심부분을 구현하고 요구사항을 하나씩 차례대로 도입하는데 이 전략은 항상 할 수 있다는 장점이 있습니다. 예를 들어 9x9 스도쿠를 만들때 1x1스도쿠부터 만드는 식입니다.
이 전략의 위험요소는 많은 요구사항중에서 삭제할 요구사항을 어떻게 선정했느냐에 따라서 비용이 크게 달라집니다.
추가적으로 이쁜 디자인이 나오지 않는다면 그냥 추가해도 됩니다. 비록 나중에 이에 대한 대가를 치를 수도 있지만 가치가 있을수 있습니다. 위 4개의 전략이 적용된다면 적용하고 적용되지 않지만 필요한 기능이 있다면 그냥 구현합니다. 켄트벡의 사용빈도수로 보면 Parallel > Simplification > Leap > Stepping Stone 순입니다. 김창준님의 중간설명대로라면 Stepping Stone이 목적지를 출발지로 이끌어 오는 방법이라면 Simplification는 출발지를 목적지로 가깝게 가는 방법입니다.
리팩토링
기능추가와 리팩토링은 둘이 같이 할수는 없기 때문에 새 기능을 추가할 때는 추가만 하고 리팩토링을 할 때는 리팩토링만 합니다. 비헤이비어는 바꾸지 않고 구조만 바꾸어야 하면 리팩토링을 할 때는 Extract가 있으면 Inline도 있습니다. Responsive Designer는 이 두가지 모두가 가능해야 합니다.
리팩토링을 하는 기술적 접근으로는 Responsive Designer는 Isolate Change을 사용합니다. 무언가를 바꾸기 전에 먼저 고립시킨 뒤에 바꿉니다.(개념은 약간 이해되지만 해보기 전에는 설명만으로는 고립이란 것이 구체적으로 잘 이해되지 않더군요 ㅡ..ㅡ)
Responsive Designer는 어려운 변경은 하지 않습니다. 노력해서 변경을 쉽게 한 다음에 변경을 합니다.
Design is an island
디자인은 섬과 같아서 수면위로 올라오면 할만한 솔루션이고 이것이 산이 되면 더 좋지만 때로는 수면위로 올라온 섬의 수면이 높아질 수 있습니다.
시스템의 복잡성을 인정해야 합니다. 시스템을 완전히 컨트롤 가능하다고 생각하는 것보다는 낫습니다.
발표자료는 김창준님이 올려주셨습니다. 저작권은 CCL BY-NC-ND를 따른다고 합니다. 내용공유를 위한 사이트도 개설되었습니다.
개인적 생각
솔직히 다 이해하지는 못했기 때문에 정리한 내용도 좀 맥락이 끊기는 부분이 있습니다.
세미나 후에 보니 좋았다 안좋았다 의견이 반반정도인 것 같습니다. 글을 다 읽어본 것은 아니지만 안좋았다는 의견은 기존에 애자일의 방법론등에 비교해서 크게 다를것이 없는 너무 뻔한 내용뿐이었다는 것이 요지가 아닌가 싶습니다. 사람마다 기대치가 다르고 켄트벡이란 네임밸류에 대해서는 기대감이 컷기 때문에 실망도 크지 않았나 생각합니다.
저같은 경우는 나름 흡족했습니다. 제가 세미나를 참석하는 이유는 여러가지가 있는데 김창준님이 닫힌괄호라고 얘기한 것과 비슷한 기술적인 지식을 쌓기 위함이 그 첫번째입니다. 상당부분은 책이나 온라인과 경험을 통해서 얻을 수 있지만 다른 사람들은 어떻게 하는지도 궁금하고 혼자서는 배우지 못하는 부분이 확실히 있기 때문이고 다른 사람이 이미 경험하고 정리된 내용을 들어서 저는 그 중간의 시행착오를 거치지 않고 습득할 수 있는 장점이 있습니다.
또하나는 트랜드에 대한 파악입니다. 웹이든 기술적으로든 방법론적으로든 대세 혹은 추세를 파악하기 위함입니다. 이런 것은 좀 더 미래지향적인 준비이기도 하고 켄트벡의 세미나에서도 언급이 나왔지만 전체적인 큰 그림을 그릴 수 있으면 변화에 대응하기에 훨씬 유연하기 때문입니다. 또한 이런 것을 파악하면 각 상황이나 문제에 대한 통찰력을 가질 수 있습니다. 더욱이 켄트벡같은 경우에는 다른 사람과는 사물을 파악하는 통찰력이 더 낫다고 생각하기 때문에 당연하고 익숙한 것에 대한 선입견을 깨뜨릴 수 있는 통찰력을 배울 수 있습니다.
이런 점에서 이번 세미나는 듣고 "아~ 그렇구나"하는 깨달음을 얻는 세미나라기 보다는 좀 곰곰히 생각해 봄직한 완전히 추상적인 개념에서 약간은 더 구체적인 개념이 되었다고 할 수 있습니다. 저번에 에릭감마 세미나때도 그렇고 이번 세미나에서도 느껴지는 바이지만 아직도 IT에서는 실버블렛에 대한 환상이 좀 남아있지 않은가 하는 생각이 듭니다. 꽤나 놀랍게 다가웠던 애자일도 이젠 상당히 구체화되었고 TEST UNIT도 상당히 보편화 되어가고 있는듯 합니다. 이런 접근이 현실을 인정하고 유연하게 다가가는데 비해서 우리는 아직도 한방에 해결하려는 마음이 없잖아 있는듯 합니다. 개인적으로 "개발에서 실버블렛은 없다"가 정설(?)이 아닌가 싶습니다.
어쨌든 항상 듣고 생각하지만 말고 이젠 슬슬 적용을 해보아야 겠네요....
점심시간을 이용한 싸인회가 진행되었습니다.
 |  |  |
XP냐 TDD냐 고민을 좀 했습니다만 저한테는 XP보단 TDD가 더 인상적인것 같아서 TDD에다가 싸인을 받았습니다. 개발자의 싸인을 받는다는 것에 대해서는 고민되는 문제이기는 하지만 그냥 평범한 사람으로써 유명한 사람을 봤다는 것으로 봤을때 그리 심각하게 받아들일 이유도 없는 것 같아서 싸인받았습니다. 역자인 김창준씨 싸인도... ㅎㅎㅎㅎㅎ
오전에는 좀 Responsive Design에 대한 개념적인 배경을 설명하느라고 추상적인 얘기도 많았고 이름으로도 느껴지듯이 완전 쇼킹하게 새로운 것은 아니기 때문에 좀 뻔한 내용도 없잖아 있었습니다. 세미나장소 뒤쪽에서 포스트잇으로 진행된 회고에서도 오전이 너무 뻔한 내용이라는 지적도 있었습니다.
설계
디자인할 때는 리팩토링 얘기는 하지 않습니다. 리팩토링은 좋은 디자인 기법중의 하나이지만 맥락을 이해하지 못하면 어떤것이 좋고 나쁜지를 알 수 없기 때문입니다.
설계는 어떻게 하여야 하는가.
설계에는 불확실성이 많이 있습니다. 모든 것이 확실하다면 피드백이 필요없습니다.
- 피드백 : 매우 중요한 부분이고 많은 레벨에서의 다양한 피드벡이 필요합니다. TDD는 API의 품질을 피드백 받을수 있는 매우 좋은 방법입니다.
- 용기 : 두려울 수도 있지만 나아가야 합니다.
- 모호성 : 모호성이 있음을 인정해야 합니다. 초보자는 모호한 부분도 모두 정리하려고 하고 고수는 모호성을 인정하기 때문에 때론 놔두기도 합니다. 이것은 모호함때문에 소스가 지저분해질 수 있지만 모호함때문에 이것을 수정한 것이 얼마나 유지될 수 있을지 알 수 없습니다. 지금은 추한 부분이 있지만 시간이 지나면 방법이 보이게 되고 정리할 수 있습니다.
디자인의 정의
디자인의 정의는 서로 이익을 주는 관계요소(Beneficially Relating Elements)입니다. 아키텍쳐를 포함해서 모든 것이 디자인이지만 상황마다 제약요소는 다릅니다. 반응적 디자인은 스케일의 변화에도 반응할 수 있습니다.
Coupling & Cohesion
커플링은 Designer에게 가치있는 개념입니다. 커플링은 한 요소의 변경이 다른것을 바꾸게 하는 것입니다. 잠재적으로 커플링 되어 있다고하더라도(이론적으로) 만약 절대 안바꾸게 된다면 커플링을 볼 수 없습니다. web site가 클수록 잠재적 커플링도 늘어납니다.
Cohesion은 커플링의 역입니다. 한 서브 엘리먼트의 변경이 다른 모두를 바꾸도록 요구하는 것으로 커플링이 높으면 코히즌은 낮아집니다. 커플링을 찾는 것은 어렵지만 코히즌은 찾기가 쉽기 때문에 코히즌을 늘리고 커플링을 낮춰야 비용이 내려갑니다.
(사실 커플링과 코히즌은 제가 경험도 적고 잘 개념을 이해하지 못했습니다. 들리는대로 정리하긴 했는데 사실 감은 잘 안왔습니다. 이부분에 대해서는 토비님의 변화의 비용으로 설명하는 결합(coupling)과 응집(cohesion)을 읽어보시면 더 도움이 되실듯 합니다.)
Responsive Designer의 구체적인 방법
드디어 반응적 설계에 대한 얘기가 본격적으로 나왔습니다.
안전한 단계 (Safe Steps)
변경할 때는 작은 단계로 변경합니다. 물론 너무 작으면 효율성이 저하됩니다. 안전성이 더 중요하기 때문에 안전성을 확보한 다음에 효율성을 생각합니다. 안전한 단계를 자동화(이클립스의 리팩토리등)하는 것이 방법이라고 할 수 있습니다. 이 단계를 연습을 통해서 더욱 빨리 할 수 있습니다.
가장 안좋은 것은 작업을 하다가 문제가 발견되어 지난 작업의 기억들을 더듬어서 다시 롤백하게 되는 것으로 이렇게 되면 영향이 어디까지 미치었는지도 파악하기 어렵고 Steady Flow of Feature를 방해하게 됩니다.
안전한 단계를 활용하여 속도를 높여야 합니다.
전략 (Strategies)
켄트벡이 작업을 하면서 실험적으로 디자인 변화한 것들을 카드로 적어서 그룹화 하니까 총 4가지로 분류되었습니다. 그 이전에는 디자인은 예술이라고 생각하고 있었지만 정리를 하고나서 보니 켄트벡이 오직 4가지전략만 사용하고 있었습니다. 이 4가지는 Leap, Parallel, Stepping Stone, Simplification입니다.
어떤 디자인을 사용할 지 보인다면 Leap과 Parallel을, 어떤 디자인을 사용할 지 알수 없다면 Stepping Stone, Simplification을 사용합니다.
Leap Strategy
자신이 원하는 구상의 디자인을 알 경우에 사용합니다. 일단 새로 만듭니다. 이는 효율성은 높고 쉽지만 리스크는 있습니다. Leap전략을 취했을 때 생각하지 못한 문제가 발생하게 되면 Debug하는데 오래 걸리게 됩니다. Kent는 Leap을 사용하는 빈도수가 다른 사람들보다는 적다고 합니다.
Parallel Strategy
이 경우도 역시 원하는 디자인을 알 경우에 사용합니다. Parallel전략은 예전 디자인과 새로운 디자인을 동시에 운영하는 방법으로 레가시를 교체하는데 주로 이용합니다. 안정성이 높습니다.
Stepping Stone Strategy
자신이 원하는 디자인을 모를 경우에 사용하며 정확히는 모르지만 어떤기능이 있으면 목적에 근접할 수 있을 것이라고 생각되면 그것을 만들는 식의 방법으로 접근합니다. Stepping Stone전략은 너무 많은 것을 만들 수 있는 오버엔지니어링의 위험이 있기 때문에 필요한 것만 만들도록 해야 합니다. 또다른 단점으로는 이 과정 중에는 피드백이 없습니다. 필요할 때마다 구축하는 방법으로 접근해야 합니다.
Simplification Strategy
자신이 원하는 디자인을 모를 경우에 사용하며 경험이 많은 사람들이 주로 이용합니다. 최종적인 디자인이 확정되지 않은 상태로 요구사항중에 어딘가에 기능의 핵심이 있기 때문에 요구사항을 제거해 나가면서 핵심을 찾는 식으로 접근합니다. 핵심부분을 구현하고 요구사항을 하나씩 차례대로 도입하는데 이 전략은 항상 할 수 있다는 장점이 있습니다. 예를 들어 9x9 스도쿠를 만들때 1x1스도쿠부터 만드는 식입니다.
이 전략의 위험요소는 많은 요구사항중에서 삭제할 요구사항을 어떻게 선정했느냐에 따라서 비용이 크게 달라집니다.
추가적으로 이쁜 디자인이 나오지 않는다면 그냥 추가해도 됩니다. 비록 나중에 이에 대한 대가를 치를 수도 있지만 가치가 있을수 있습니다. 위 4개의 전략이 적용된다면 적용하고 적용되지 않지만 필요한 기능이 있다면 그냥 구현합니다. 켄트벡의 사용빈도수로 보면 Parallel > Simplification > Leap > Stepping Stone 순입니다. 김창준님의 중간설명대로라면 Stepping Stone이 목적지를 출발지로 이끌어 오는 방법이라면 Simplification는 출발지를 목적지로 가깝게 가는 방법입니다.
리팩토링
기능추가와 리팩토링은 둘이 같이 할수는 없기 때문에 새 기능을 추가할 때는 추가만 하고 리팩토링을 할 때는 리팩토링만 합니다. 비헤이비어는 바꾸지 않고 구조만 바꾸어야 하면 리팩토링을 할 때는 Extract가 있으면 Inline도 있습니다. Responsive Designer는 이 두가지 모두가 가능해야 합니다.
리팩토링을 하는 기술적 접근으로는 Responsive Designer는 Isolate Change을 사용합니다. 무언가를 바꾸기 전에 먼저 고립시킨 뒤에 바꿉니다.(개념은 약간 이해되지만 해보기 전에는 설명만으로는 고립이란 것이 구체적으로 잘 이해되지 않더군요 ㅡ..ㅡ)
Responsive Designer는 어려운 변경은 하지 않습니다. 노력해서 변경을 쉽게 한 다음에 변경을 합니다.
Design is an island
디자인은 섬과 같아서 수면위로 올라오면 할만한 솔루션이고 이것이 산이 되면 더 좋지만 때로는 수면위로 올라온 섬의 수면이 높아질 수 있습니다.
시스템의 복잡성을 인정해야 합니다. 시스템을 완전히 컨트롤 가능하다고 생각하는 것보다는 낫습니다.
 |  |
발표자료는 김창준님이 올려주셨습니다. 저작권은 CCL BY-NC-ND를 따른다고 합니다. 내용공유를 위한 사이트도 개설되었습니다.
개인적 생각
솔직히 다 이해하지는 못했기 때문에 정리한 내용도 좀 맥락이 끊기는 부분이 있습니다.
세미나 후에 보니 좋았다 안좋았다 의견이 반반정도인 것 같습니다. 글을 다 읽어본 것은 아니지만 안좋았다는 의견은 기존에 애자일의 방법론등에 비교해서 크게 다를것이 없는 너무 뻔한 내용뿐이었다는 것이 요지가 아닌가 싶습니다. 사람마다 기대치가 다르고 켄트벡이란 네임밸류에 대해서는 기대감이 컷기 때문에 실망도 크지 않았나 생각합니다.
저같은 경우는 나름 흡족했습니다. 제가 세미나를 참석하는 이유는 여러가지가 있는데 김창준님이 닫힌괄호라고 얘기한 것과 비슷한 기술적인 지식을 쌓기 위함이 그 첫번째입니다. 상당부분은 책이나 온라인과 경험을 통해서 얻을 수 있지만 다른 사람들은 어떻게 하는지도 궁금하고 혼자서는 배우지 못하는 부분이 확실히 있기 때문이고 다른 사람이 이미 경험하고 정리된 내용을 들어서 저는 그 중간의 시행착오를 거치지 않고 습득할 수 있는 장점이 있습니다.
또하나는 트랜드에 대한 파악입니다. 웹이든 기술적으로든 방법론적으로든 대세 혹은 추세를 파악하기 위함입니다. 이런 것은 좀 더 미래지향적인 준비이기도 하고 켄트벡의 세미나에서도 언급이 나왔지만 전체적인 큰 그림을 그릴 수 있으면 변화에 대응하기에 훨씬 유연하기 때문입니다. 또한 이런 것을 파악하면 각 상황이나 문제에 대한 통찰력을 가질 수 있습니다. 더욱이 켄트벡같은 경우에는 다른 사람과는 사물을 파악하는 통찰력이 더 낫다고 생각하기 때문에 당연하고 익숙한 것에 대한 선입견을 깨뜨릴 수 있는 통찰력을 배울 수 있습니다.
이런 점에서 이번 세미나는 듣고 "아~ 그렇구나"하는 깨달음을 얻는 세미나라기 보다는 좀 곰곰히 생각해 봄직한 완전히 추상적인 개념에서 약간은 더 구체적인 개념이 되었다고 할 수 있습니다. 저번에 에릭감마 세미나때도 그렇고 이번 세미나에서도 느껴지는 바이지만 아직도 IT에서는 실버블렛에 대한 환상이 좀 남아있지 않은가 하는 생각이 듭니다. 꽤나 놀랍게 다가웠던 애자일도 이젠 상당히 구체화되었고 TEST UNIT도 상당히 보편화 되어가고 있는듯 합니다. 이런 접근이 현실을 인정하고 유연하게 다가가는데 비해서 우리는 아직도 한방에 해결하려는 마음이 없잖아 있는듯 합니다. 개인적으로 "개발에서 실버블렛은 없다"가 정설(?)이 아닌가 싶습니다.
어쨌든 항상 듣고 생각하지만 말고 이젠 슬슬 적용을 해보아야 겠네요....
[EP]켄트 벡(Kent Beck) 초청 세미나 #1..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
지난 4일 애자일컨설팅과 (주)STA컨설팅의 주최로 켄트 벡(Kent Beck)의 초청 세미나가 한국과학기술회관에서 있었습니다. 켄트벡은 XP(Extreme Programming)와 TDD(Test Driven Development)로 유명하신 분으로 한국에는 처음 오신 것으로 알고 있습니다.
켄트벡의 유명세가 있는데 초반에 반응이 좀 뜸하길래 회사 분위기도 살피고 여유있게 있다가 보니 허락받고 신청하니까 대기자로 들어가서 하마터면 못 갈뻔했습니다. 흔치않은 기회였는데... 대기자가 너무 많아서 1일에 추가 세미나로 200명을 더 개최하고 2일전에 대기자차례가 돌아와서 참여하게 되었습니다. 지원은 받기 힘든 상황이라 약간 세기는 했지만 과감히 자비로 비용을 부담하고 갔다왔습니다.
세미나는 켄트벡이 최근에 연구중이라는 "Responsive Design: Wehn, How, and What(반응적 설계: 언제, 어떻게, 무엇을)"에 대해서 진행되었습니다. 말자체로 살짝 느껴지기는 하지만 좀 생소하기는 한 말입니다. Responsive Design.... 켄트벡의 수준이 높기도 하고 그전에 들리는 얘기로도 켄트벡의 세미나는 약간 추상적인 얘기도 많이하고 공부해놓고 가야된다고 해서 어느정도 이해를 할 수 있을지 가기전에 좀 고민되기도 했습니다.
켄트벡 소개 : 내가 보는 켄트벡(김창준)
세미나는 애자일 컨설팅의 김창준님이 켄트벡을 간단히 소개하는 시간으로 시작되었습니다.
먼저 동양과 서양 사람들의 생각하는 방식의 차이가 있다는 얘기를 하셨는데 강아지, 소, 풀 3가지중에서 다른 것을 하나 고르라고 하면 동양사람들은 맥락적인 행위로 판단을 하고 서양사람들은 존재론적으로 생각하기 때문에 동양사람들은 강아지를 고르고 서양사람들은 풀을 고른다는 얘기였습니다. (저는 강아지를 고르게 되더군요. 흠....)
켄트벡이 스스로 꼽은 자신의 키워드는 아래 3가지였습니다.
김창준님이 본 Kent Beck는 2가지였습니다.
단순성에 대한 집착 : 터무니 없이 단순한 생각에서 멍청할 정도로 극단적으로 적용합니다.
인간적 성숙을 위한 노력 : 이부분은 XP책의 2판부터 나타나기 시작했으면 "책임감 있는 개발"이란 말을 많이하기 시작했다고 합니다.
마지막으로 세미나를 열린 괄호와 닫힌 괄호에 비교하셨습니다. 닫힌 괄호는 단편(?)적인 지식을 쌓는 것이고 열린 괄호는 명확히 지식적으로 얻은 것은 없는 것 같지만 무언가 해봐야 겠다는 생각이 들게 되는 세미나인데 켄트벡의 세미나는 이런 에너지와 실험으로 이어지는 열린괄호에 가깝다는 것이었습니다.
(30분정도의 짧은 시간이었지만 생각해 봄직한 말들이었습니다. 김창준님은 2년전 P-Camp때 처음 뵈었었는데 그때도 느꼈지만 참 말씀 잘하시더군요.... 부럽;;; ㅎ)
오전 세션
켄트벡의 오션세션이 이어졌습니다.
반응적 설계(Responsive Design)은 책으로 나올 예정인데 "Structured Design"이란 책을 보고 많은 영감을 받았고 여기서 기본적인 내용을 잡았다고 합니다. 이 책의 저자들과 얘기해서 기본적인 것을 바탕으로 내용을 업데이트하고 켄트벡의 생각을 넣어서 새로 만드려고 하는 것이 Responsive Design의 시작이라고 합니다.
디자인이 왜 중요한가 하면 여러가지 증상(Symptom)들이 근본적으로 디자인인 경우가 많습니다. 예를 들어서 테스트하기가 어려워서 더 복잡한 것을 해결할 수 있는 테스트툴을 만들수 있지만 표면적인 증상만 보지 말고 한걸음 물러나서 디자인을 보게 되면 근본적으로는 디자인의 문제인 경우가 많습니다. "어떤 디자인이면 이 문제를 해결할 수 있을까?"라는 고민을 하게 되면 쉽게 증상을 해결할 수 있는 경우가 많습니다. 또한 팀작업의 경우에도 같은 파일의 수정에 대한 문제같은 경우 팀웍의 문제일 수도 있지만 왜 같은 파일을 수정해야 되게 되었는가에 대한 고민을 할 필요가 있습니다. 쉽지 않고 어려운 문제지만 할 필요가 있습니다.
디자인 공부는 아래의 3가지의 초점을 맞추어서 합니다.
SW에 대해서 생각하기에 적합한 시기인지에 대해서 생각해 볼 필요가 있습니다. 현재 SW 디자인에서 큰 변화가 일어나고 있습니다. 기존에 적용되었던 것이 이제 통하지 않고 있기 때문에 차세대 SW 디자인에 대한 스킬이 필요한 때입니다.
디자인 스킬은 큰 변화가 왔을 때 큰 능력을 발휘합니다.
현재 큰 변화로는
효율성
디자인은 효율적이어야 합니다. 효율성은 작은 Scale로 볼수도 있고 큰 Scale로 볼 수도 있습니다. 공장으로 본다면 공장전체는 효율적이지만 기계단위 별로는 효율적일 때도있고 아닐때도 있을 수 있습니다. 효율성외에 초기에 얼마만큼의 디자인 비용이 드는가에 대해서도 고려해야 합니다. 그리고 또하나의 큰 비용은 변화에 대한 비용이기 때문에 이에 대한 부분을 줄이려고 노력해야 합니다. 반응적 설계는 변화에 대한 비용을 줄일 수 있습니다.
설계는 모든 환벽한 정보에 기반해서 하지 않기 때문에 실수에 대한 비용도 있습니다. 또한 현재 하는 일때문에 하지 못하는 것에 대한 기회비용도 있습니다. 프로젝트 초기에는 해당프로젝트의 가능성을 잘 모르기 때문에 기회비용이 클 수 있는데 초기투자를 줄여서 프로젝트가 진행되면서 확실해 졌을때 더 많이 투자함으로써 기회비용을 줄일 수 있습니다. 반응적 설계는 효율은 높이고 비용은 줄이는 것입니다.
디자인할 때는 아래 3가지의 균형이 중요합니다.
어떤 부분에 너무 깊게 관여되어 있으면 시야가 좁아지기 때문에 한걸음 물러나서 큰그림을 봐야합니다.
글이 길어져서 글을 나누어야 겠습니다.
지난 4일 애자일컨설팅과 (주)STA컨설팅의 주최로 켄트 벡(Kent Beck)의 초청 세미나가 한국과학기술회관에서 있었습니다. 켄트벡은 XP(Extreme Programming)와 TDD(Test Driven Development)로 유명하신 분으로 한국에는 처음 오신 것으로 알고 있습니다.
켄트벡의 유명세가 있는데 초반에 반응이 좀 뜸하길래 회사 분위기도 살피고 여유있게 있다가 보니 허락받고 신청하니까 대기자로 들어가서 하마터면 못 갈뻔했습니다. 흔치않은 기회였는데... 대기자가 너무 많아서 1일에 추가 세미나로 200명을 더 개최하고 2일전에 대기자차례가 돌아와서 참여하게 되었습니다. 지원은 받기 힘든 상황이라 약간 세기는 했지만 과감히 자비로 비용을 부담하고 갔다왔습니다.
세미나는 켄트벡이 최근에 연구중이라는 "Responsive Design: Wehn, How, and What(반응적 설계: 언제, 어떻게, 무엇을)"에 대해서 진행되었습니다. 말자체로 살짝 느껴지기는 하지만 좀 생소하기는 한 말입니다. Responsive Design.... 켄트벡의 수준이 높기도 하고 그전에 들리는 얘기로도 켄트벡의 세미나는 약간 추상적인 얘기도 많이하고 공부해놓고 가야된다고 해서 어느정도 이해를 할 수 있을지 가기전에 좀 고민되기도 했습니다.
켄트벡 소개 : 내가 보는 켄트벡(김창준)
세미나는 애자일 컨설팅의 김창준님이 켄트벡을 간단히 소개하는 시간으로 시작되었습니다.
먼저 동양과 서양 사람들의 생각하는 방식의 차이가 있다는 얘기를 하셨는데 강아지, 소, 풀 3가지중에서 다른 것을 하나 고르라고 하면 동양사람들은 맥락적인 행위로 판단을 하고 서양사람들은 존재론적으로 생각하기 때문에 동양사람들은 강아지를 고르고 서양사람들은 풀을 고른다는 얘기였습니다. (저는 강아지를 고르게 되더군요. 흠....)
켄트벡이 스스로 꼽은 자신의 키워드는 아래 3가지였습니다.
- 개발자가 작성하는 TEST
- 패턴
- XP (Extreme Programming)
켄트벡을 소개하는 김창준님
| 
등록하면서 받은 물건들
|
김창준님이 본 Kent Beck는 2가지였습니다.
단순성에 대한 집착 : 터무니 없이 단순한 생각에서 멍청할 정도로 극단적으로 적용합니다.
인간적 성숙을 위한 노력 : 이부분은 XP책의 2판부터 나타나기 시작했으면 "책임감 있는 개발"이란 말을 많이하기 시작했다고 합니다.
마지막으로 세미나를 열린 괄호와 닫힌 괄호에 비교하셨습니다. 닫힌 괄호는 단편(?)적인 지식을 쌓는 것이고 열린 괄호는 명확히 지식적으로 얻은 것은 없는 것 같지만 무언가 해봐야 겠다는 생각이 들게 되는 세미나인데 켄트벡의 세미나는 이런 에너지와 실험으로 이어지는 열린괄호에 가깝다는 것이었습니다.
(30분정도의 짧은 시간이었지만 생각해 봄직한 말들이었습니다. 김창준님은 2년전 P-Camp때 처음 뵈었었는데 그때도 느꼈지만 참 말씀 잘하시더군요.... 부럽;;; ㅎ)
오전 세션
켄트벡의 오션세션이 이어졌습니다.
반응적 설계(Responsive Design)은 책으로 나올 예정인데 "Structured Design"이란 책을 보고 많은 영감을 받았고 여기서 기본적인 내용을 잡았다고 합니다. 이 책의 저자들과 얘기해서 기본적인 것을 바탕으로 내용을 업데이트하고 켄트벡의 생각을 넣어서 새로 만드려고 하는 것이 Responsive Design의 시작이라고 합니다.
디자인이 왜 중요한가 하면 여러가지 증상(Symptom)들이 근본적으로 디자인인 경우가 많습니다. 예를 들어서 테스트하기가 어려워서 더 복잡한 것을 해결할 수 있는 테스트툴을 만들수 있지만 표면적인 증상만 보지 말고 한걸음 물러나서 디자인을 보게 되면 근본적으로는 디자인의 문제인 경우가 많습니다. "어떤 디자인이면 이 문제를 해결할 수 있을까?"라는 고민을 하게 되면 쉽게 증상을 해결할 수 있는 경우가 많습니다. 또한 팀작업의 경우에도 같은 파일의 수정에 대한 문제같은 경우 팀웍의 문제일 수도 있지만 왜 같은 파일을 수정해야 되게 되었는가에 대한 고민을 할 필요가 있습니다. 쉽지 않고 어려운 문제지만 할 필요가 있습니다.
디자인 공부는 아래의 3가지의 초점을 맞추어서 합니다.
Introspectively : 자기반성적으로 내면을 봅니다. 나는 어떻게 하는지... 어떤걸 해보았는지...
Empirically : 경험적으로 잘된 것과 잘안된 것은 인식해야 합니다.
Quantitatively : 정량성
SW에 대해서 생각하기에 적합한 시기인지에 대해서 생각해 볼 필요가 있습니다. 현재 SW 디자인에서 큰 변화가 일어나고 있습니다. 기존에 적용되었던 것이 이제 통하지 않고 있기 때문에 차세대 SW 디자인에 대한 스킬이 필요한 때입니다.
디자인 스킬은 큰 변화가 왔을 때 큰 능력을 발휘합니다.
현재 큰 변화로는
- 무어의 법칙의 종료 : 여태는 SW개발자가 HW성능향상에 중독되어 HW가 향상되기를 기다리면 퍼포먼스문제가 해결되었으나 이제는 그렇지 않습니다.
- Scale : 스케일이 점점 커지고 있어서 디자인으로 해결해야 합니다.
- Cloud : 클라우드로의 이동이 이루어지고 있어서 쉬웠던 것들이 어려워지고 어려웠던 것들이 쉬워지고 있습니다.
- PC-Client : 과거에는 모든 것이 Server에 들어가고 Client는 조악했지만 이제는 상황이 바뀌었습니다.
 |  |
효율성
디자인은 효율적이어야 합니다. 효율성은 작은 Scale로 볼수도 있고 큰 Scale로 볼 수도 있습니다. 공장으로 본다면 공장전체는 효율적이지만 기계단위 별로는 효율적일 때도있고 아닐때도 있을 수 있습니다. 효율성외에 초기에 얼마만큼의 디자인 비용이 드는가에 대해서도 고려해야 합니다. 그리고 또하나의 큰 비용은 변화에 대한 비용이기 때문에 이에 대한 부분을 줄이려고 노력해야 합니다. 반응적 설계는 변화에 대한 비용을 줄일 수 있습니다.
설계는 모든 환벽한 정보에 기반해서 하지 않기 때문에 실수에 대한 비용도 있습니다. 또한 현재 하는 일때문에 하지 못하는 것에 대한 기회비용도 있습니다. 프로젝트 초기에는 해당프로젝트의 가능성을 잘 모르기 때문에 기회비용이 클 수 있는데 초기투자를 줄여서 프로젝트가 진행되면서 확실해 졌을때 더 많이 투자함으로써 기회비용을 줄일 수 있습니다. 반응적 설계는 효율은 높이고 비용은 줄이는 것입니다.
디자인할 때는 아래 3가지의 균형이 중요합니다.
- Latency (지연)
- Throughput (처리량)
- Variance (변화)
어떤 부분에 너무 깊게 관여되어 있으면 시야가 좁아지기 때문에 한걸음 물러나서 큰그림을 봐야합니다.
글이 길어져서 글을 나누어야 겠습니다.
[Book] 스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
애자일(Agile) 개발방법론 중의 하나인 스크럼(Scrum)에 대해서 설명한 책으로 스크럼의 초기틀을 만든 켄 슈와버가 직접 책을 썼습니다. 아시다시피 애자일에는 여러가지 방법론들이 있고 XP, RUP, 린소프트웨어등이 있고 스크럼도 그중의 하나입니다. 애자일이라는 이름 밑에 모여있는 만큼 비슷한 점들을 가지고 있습니다.
스크럼이란 것이 무엇인지, 스크럼의 실천방법, 그리고 실제 팀에 적용하는 방법, 스크럼이 어떤 효과를 가져오는지에 대해서 자세하게 설명할 수 있습니다. 스크럼 자체가 아주 심플하기 때문에(이론 자체는...) 책의 내용도 어렵지 않고 읽기는 쉬운편입니다.
애자일방법론의 대부분 강조하듯이 스크럼도 역시 같은 얘기를 하고 있습니다. "팀의 목표는 프로젝트의 성공이고 가치창출이지 외견상 드러나는 새로운 방법론의 성공적인 도입만이 되어서는 안됩니다."라고 역자인 박일님이 하신 얘기대로 가장 중요한 부분이라고 생각합니다. 애자일을 도입하게 되면 실천방법이나 방법론에 집착하게 되어 기본정신을 망각하게 되는 것이 가장 조심해야 되는 것이 아닌가 싶습니다.
스크럼은 팀의 생산성과 유연성에 최대한 초점이 맞추어져 프로젝트 진행의 불필요한 장애물을 제거하고 프로젝트 성공만을 위해서 팀이 진행되도록 합니다. 그렇게 하기 위해서 소프트웨어의 요구사항이 우선순위로 정렬된 목록인 제품 백로그(Product Backlog)를 작성하고 이 제품 백로그는 누구나 항목을 제출할 수 있지만 제품 책임자(Product Owner)만이 우선순위를 부여할 수 있습니다. 그리고 팀은 스프린트(Sprint)라고 부르는 30일의 반복주기를 단위로 개발을 진행하며 제품백로그에서 한 스프린트에 할 수 있는 일을 선택하여 진행하게 됩니다. 꼭 30일일 필요는 없지만 경험상 30일이 최적이었으며 특별한 이유가 있는 것이 아니면 30일로 스프린트를 진행하고 경험해본뒤에 팀에 맞게 기간을 수정하라고 합니다. 그리고 스크럼 마스터(Scrum Master)는 팀원들이 프로젝트 진행에 최대한 집중할 수 있도록 도우며 매일 일일 스크럼(Daily Scrum)라고 하는 짧은 현황회의를 진행합니다.
스크럼 팀은 자기조직적인 팀으로 구성되어야 하며 스크럼 마스터는 팀원들을 위해서 장애물을 해결해 주고 필요자원이 충분히 공급되도록 돕지만 팀내부문제를 해결해주려고 해서는 안된다고 하고 있습니다. 스크럼 회의에서는 오직 어제 무엇을 했는가? 오늘은 무엇을 할것인가? 장애요소가 있는가만을 얘기하고 다른 얘기로 회의가 길어지지 않도록 하며 특별히 회의가 필요한 경우에는 일일 스크럼 후에 회의를 소집해서 진행토록 합니다. 일일 스크럼을 통해서 프로젝트의 진행상태가 공유되며 프로젝트외의 일을 하고 있지는 않은지 무엇이 프로젝트를 방해하고 있는지를 파악도록 하고 있습니다. 사람들은 수직적 구조에서 수동적으로 일하는 것에 익숙해져 있지만 스크럼팀은 자기조직적으로 프로젝트가 진행되어야 합니다.
다른 애자일 방법론이 잘못되었다는 것은 아니지만 다른 애자일방법론의 페어코딩 등 구체적인 실천강령에 대해서 어려움을 토로하는 사람들도 많이 보았었는데 스크럼은 디테일한 부분은 자유롭게 놔두면서 가이드라인만 제공하는 듯한 느낌이라서 스크럼에 다가가기에는 그렇게 어렵지 않아보였습니다.
다만 다른 애자일방법론과 마찬가지로 현실적용에서는 약간 괴리감이 있는 것은 동일한 것 같습니다. 스크럼 자체의 의도와 방법들은 지극히 동감하지만 실제 적용에 대해서는 고민이 되게 마련입니다. 일단 가장 큰 걱정은 스크럼이 말하는 것이 되려면 팀이 전권을 가져야 합니다. 제품백로그에 요구사항에 대한 처리가 강요되는 것을 팀이 거부할 수 있어야 하고 프로젝트 진행외에 팀이 다른 회사일등을 하는 것을 스크럼마스터가 막을 수 있어야 합니다. 심지어 기간이 모자라면 기능을 줄이는 것도 가능해야 하는데 과연 회사에서 스크럼팀에 이런 신뢰와 전권을 주는 것이 가능할까 하는 생각입니다.
그것 자체도 정말 쉽지 않은 일이지만 혁신이나 실험을 위해서 그렇게 허락해 준다고 하더라도 스크럼이 얘기하는 것처럼 스크럼을 적용하는 것 만으로 성공적인 결과를 항상 보여줄 수 있냐는 것은 쉽게 확신할 수는 없는 얘기도 특히 처음 도입한다면 더욱 그렇습니다. 저도 물론 애자일 방법론들이 더 좋은 방법이라고 생각은 하고 있습니다만 그건 장기적으로 익숙해 진뒤의 이야기지 적용하면 성공!식의 실버블렛은 아니라고 생각합니다.
머 책만 읽은 뒤에 비관적으로 보려는 것은 아니지만 애자일관련 책을 읽을때마다 읽으면서는 공감하지만 현실을 생각하면 한숨이 나오는 것은 어쩔수 없는것 같습니다. 책중에서 인상에 남는 말은 스크럼의 기본 원칙중 하나인 "가능한 것을 하라(the art of the possible)"입니다. 불가능한 것에 시간을 허비하기 보다는 가능한 것부터 처리하라는 것입니다.
My Comment..
가능한 것을 하라.. 이 부분은 나도 격하게 공감이 가는 대목이다.. 진짜 현실에서는 위와 같은 내용들을 실현하기란 쉽지 않다.. 친구 회사에서 애자일 방법론에 의해서 프로젝트 관리가 된다고 해서 햄의 포스팅을 조금 더 유심히 봤는데.. 친구가 말한것처럼 어제 무엇을 했는지.. 오늘 무엇을 할것인지에 대해서 오전마다 회의를 짤막하게 한다고 한다.. 좀 부럽기도 하고, 나도 한 번 그런 회의에 참석을 해보고 싶다.. 후기를 통해서 조금이나마 어떠한 방법론인지 더 알게 된 듯 하다..
 | 스크럼 -  마이크 비들.켄 슈와버 지음, 박일.김기웅 외 옮김/인사이트 |
애자일(Agile) 개발방법론 중의 하나인 스크럼(Scrum)에 대해서 설명한 책으로 스크럼의 초기틀을 만든 켄 슈와버가 직접 책을 썼습니다. 아시다시피 애자일에는 여러가지 방법론들이 있고 XP, RUP, 린소프트웨어등이 있고 스크럼도 그중의 하나입니다. 애자일이라는 이름 밑에 모여있는 만큼 비슷한 점들을 가지고 있습니다.
스크럼이란 것이 무엇인지, 스크럼의 실천방법, 그리고 실제 팀에 적용하는 방법, 스크럼이 어떤 효과를 가져오는지에 대해서 자세하게 설명할 수 있습니다. 스크럼 자체가 아주 심플하기 때문에(이론 자체는...) 책의 내용도 어렵지 않고 읽기는 쉬운편입니다.
애자일방법론의 대부분 강조하듯이 스크럼도 역시 같은 얘기를 하고 있습니다. "팀의 목표는 프로젝트의 성공이고 가치창출이지 외견상 드러나는 새로운 방법론의 성공적인 도입만이 되어서는 안됩니다."라고 역자인 박일님이 하신 얘기대로 가장 중요한 부분이라고 생각합니다. 애자일을 도입하게 되면 실천방법이나 방법론에 집착하게 되어 기본정신을 망각하게 되는 것이 가장 조심해야 되는 것이 아닌가 싶습니다.
스크럼은 팀의 생산성과 유연성에 최대한 초점이 맞추어져 프로젝트 진행의 불필요한 장애물을 제거하고 프로젝트 성공만을 위해서 팀이 진행되도록 합니다. 그렇게 하기 위해서 소프트웨어의 요구사항이 우선순위로 정렬된 목록인 제품 백로그(Product Backlog)를 작성하고 이 제품 백로그는 누구나 항목을 제출할 수 있지만 제품 책임자(Product Owner)만이 우선순위를 부여할 수 있습니다. 그리고 팀은 스프린트(Sprint)라고 부르는 30일의 반복주기를 단위로 개발을 진행하며 제품백로그에서 한 스프린트에 할 수 있는 일을 선택하여 진행하게 됩니다. 꼭 30일일 필요는 없지만 경험상 30일이 최적이었으며 특별한 이유가 있는 것이 아니면 30일로 스프린트를 진행하고 경험해본뒤에 팀에 맞게 기간을 수정하라고 합니다. 그리고 스크럼 마스터(Scrum Master)는 팀원들이 프로젝트 진행에 최대한 집중할 수 있도록 도우며 매일 일일 스크럼(Daily Scrum)라고 하는 짧은 현황회의를 진행합니다.
스크럼 팀은 자기조직적인 팀으로 구성되어야 하며 스크럼 마스터는 팀원들을 위해서 장애물을 해결해 주고 필요자원이 충분히 공급되도록 돕지만 팀내부문제를 해결해주려고 해서는 안된다고 하고 있습니다. 스크럼 회의에서는 오직 어제 무엇을 했는가? 오늘은 무엇을 할것인가? 장애요소가 있는가만을 얘기하고 다른 얘기로 회의가 길어지지 않도록 하며 특별히 회의가 필요한 경우에는 일일 스크럼 후에 회의를 소집해서 진행토록 합니다. 일일 스크럼을 통해서 프로젝트의 진행상태가 공유되며 프로젝트외의 일을 하고 있지는 않은지 무엇이 프로젝트를 방해하고 있는지를 파악도록 하고 있습니다. 사람들은 수직적 구조에서 수동적으로 일하는 것에 익숙해져 있지만 스크럼팀은 자기조직적으로 프로젝트가 진행되어야 합니다.
다른 애자일 방법론이 잘못되었다는 것은 아니지만 다른 애자일방법론의 페어코딩 등 구체적인 실천강령에 대해서 어려움을 토로하는 사람들도 많이 보았었는데 스크럼은 디테일한 부분은 자유롭게 놔두면서 가이드라인만 제공하는 듯한 느낌이라서 스크럼에 다가가기에는 그렇게 어렵지 않아보였습니다.
다만 다른 애자일방법론과 마찬가지로 현실적용에서는 약간 괴리감이 있는 것은 동일한 것 같습니다. 스크럼 자체의 의도와 방법들은 지극히 동감하지만 실제 적용에 대해서는 고민이 되게 마련입니다. 일단 가장 큰 걱정은 스크럼이 말하는 것이 되려면 팀이 전권을 가져야 합니다. 제품백로그에 요구사항에 대한 처리가 강요되는 것을 팀이 거부할 수 있어야 하고 프로젝트 진행외에 팀이 다른 회사일등을 하는 것을 스크럼마스터가 막을 수 있어야 합니다. 심지어 기간이 모자라면 기능을 줄이는 것도 가능해야 하는데 과연 회사에서 스크럼팀에 이런 신뢰와 전권을 주는 것이 가능할까 하는 생각입니다.
그것 자체도 정말 쉽지 않은 일이지만 혁신이나 실험을 위해서 그렇게 허락해 준다고 하더라도 스크럼이 얘기하는 것처럼 스크럼을 적용하는 것 만으로 성공적인 결과를 항상 보여줄 수 있냐는 것은 쉽게 확신할 수는 없는 얘기도 특히 처음 도입한다면 더욱 그렇습니다. 저도 물론 애자일 방법론들이 더 좋은 방법이라고 생각은 하고 있습니다만 그건 장기적으로 익숙해 진뒤의 이야기지 적용하면 성공!식의 실버블렛은 아니라고 생각합니다.
머 책만 읽은 뒤에 비관적으로 보려는 것은 아니지만 애자일관련 책을 읽을때마다 읽으면서는 공감하지만 현실을 생각하면 한숨이 나오는 것은 어쩔수 없는것 같습니다. 책중에서 인상에 남는 말은 스크럼의 기본 원칙중 하나인 "가능한 것을 하라(the art of the possible)"입니다. 불가능한 것에 시간을 허비하기 보다는 가능한 것부터 처리하라는 것입니다.
My Comment..
가능한 것을 하라.. 이 부분은 나도 격하게 공감이 가는 대목이다.. 진짜 현실에서는 위와 같은 내용들을 실현하기란 쉽지 않다.. 친구 회사에서 애자일 방법론에 의해서 프로젝트 관리가 된다고 해서 햄의 포스팅을 조금 더 유심히 봤는데.. 친구가 말한것처럼 어제 무엇을 했는지.. 오늘 무엇을 할것인지에 대해서 오전마다 회의를 짤막하게 한다고 한다.. 좀 부럽기도 하고, 나도 한 번 그런 회의에 참석을 해보고 싶다.. 후기를 통해서 조금이나마 어떠한 방법론인지 더 알게 된 듯 하다..
[HTML]띄어쓰기 없을 경우 테이블 레이아웃 깨지지 않게 하기..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
이제 웹표준에 대한 인식도 전보다는 나아진 편이긴 하지만 아직도 테이블 레이아웃은 많이 사용되고 있고 DIV + CSS형태로 코딩을 한다고 하더라도 게시판부분에 한해서는 table태그를 아직은 많이 쓰고 있는 편입니다. 사실 상황에 따라서는 편한 부분이 있는 것도 사실이고 레이아웃 전체를 테이블로 잡는 것이 안좋다는 거이지 테이블 사용자체를 막는 것은 아니기 때문에 게시판의 경우에는 쓰일 수도 있다고 생각하고 있습니다.
어쨌든 그런 논란에 대해서 얘기하고자 하는 것은 아니고 게시판에서 테이블 레이아웃을 사용할 경우 글이나 코멘트같은 경우는 사용자한테 입력을 받는 데 이럴 경우 사용자가 띄어쓰기를 하지 않고 글을 쓸 경우 테이블 레이아웃이 깨지는 문제가 있습니다. 아래와 같은 경우입니다.
제가 테스트해본 결과로는 Opera 9.63, Firefox 2.0, Firefox 3.0에서만 위처럼 깨져서 나왔습니다. 나온 모양으로 봐서는 table-layout만 적용되고 word-wrap은 지원하지 않아서 저렇게 나온듯 합니다.
위에 보듯이 완전한 해결책은 아니라고 할 수 있습니다. 지원안되는 브라우저도 있고 표준속성도 아니기 때문입니다. 다만 IE유저에 비해서 업데이트를 충실하게 해준다고 볼 수 있는 타 브라우저에서 FF 2.0이나 FF 3.0은 과거 버전이라서 다행이라고 할 수 있지만 Opera에서 안되는 것은 약간 아쉽네요.
제가 퍼블리셔가 아니라서 아직 명확한 해결책은 못찾았네요. 더 좋은 방법이 있으시면 알려주시면 감사하겠습니다.
이제 웹표준에 대한 인식도 전보다는 나아진 편이긴 하지만 아직도 테이블 레이아웃은 많이 사용되고 있고 DIV + CSS형태로 코딩을 한다고 하더라도 게시판부분에 한해서는 table태그를 아직은 많이 쓰고 있는 편입니다. 사실 상황에 따라서는 편한 부분이 있는 것도 사실이고 레이아웃 전체를 테이블로 잡는 것이 안좋다는 거이지 테이블 사용자체를 막는 것은 아니기 때문에 게시판의 경우에는 쓰일 수도 있다고 생각하고 있습니다.
어쨌든 그런 논란에 대해서 얘기하고자 하는 것은 아니고 게시판에서 테이블 레이아웃을 사용할 경우 글이나 코멘트같은 경우는 사용자한테 입력을 받는 데 이럴 경우 사용자가 띄어쓰기를 하지 않고 글을 쓸 경우 테이블 레이아웃이 깨지는 문제가 있습니다. 아래와 같은 경우입니다.
Html
흔한 경우는 아니지만 사용자의 입력을 조정할 수도 없으니 이렇게 될 경우 레이아웃이 깨져버리게 됩니다. 띄어쓰기가 있을 경우는 단어별로 줄바꿈이 자동으로 되지만 위처럼 띄어쓰기 없어서 하나의 단어로 브라우저가 하나의 단어로 인식하면 위처럼 width를 120px로 지정하였음에도 400px도 넘어가게 늘어났습니다. 예쁘게 디자인된 페이지라면 다른 부분까지도 다 밀려서 보기 흉하게 되어버리지요.
<table width="200px" border="1"> <tr> <td style="width:120px">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</td> <td style="width:80px">fefefe</td> </tr> </table>
흔한 경우는 아니지만 사용자의 입력을 조정할 수도 없으니 이렇게 될 경우 레이아웃이 깨져버리게 됩니다. 띄어쓰기가 있을 경우는 단어별로 줄바꿈이 자동으로 되지만 위처럼 띄어쓰기 없어서 하나의 단어로 브라우저가 하나의 단어로 인식하면 위처럼 width를 120px로 지정하였음에도 400px도 넘어가게 늘어났습니다. 예쁘게 디자인된 페이지라면 다른 부분까지도 다 밀려서 보기 흉하게 되어버리지요.
Html
위처럼 테이블에 스타일을 주어서 해결할 수 있습니다. table-layout을 fixed로 고정시키고 word-wrap에 대한 속성을 break-word로 지정하였습니다. 하지만 CSS 2.1 Specification을 보면 table-layout에 대한 속성은 정의되어있지만 word-wrap에 대한 속성은 정의되어 있지 않습니다. word-wrap는 CSS 2표준이 아니라는 이야기이지요. 이 속성은 IE에서 지원하는 속성으로 알고 있습니다.
이렇게 스타일을 주면 아래처럼 지정된 width이상이 되면 자동으로 줄바꿈이 되어 테이블의 레이아웃이 깨지지 않습니다.
<table width="200px" border="1" style="table-layout: fixed; word-wrap:break-word;"> <tr> <td style="width:120px">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</td> <td style="width:80px">fefefe</td> </tr> </table>
위처럼 테이블에 스타일을 주어서 해결할 수 있습니다. table-layout을 fixed로 고정시키고 word-wrap에 대한 속성을 break-word로 지정하였습니다. 하지만 CSS 2.1 Specification을 보면 table-layout에 대한 속성은 정의되어있지만 word-wrap에 대한 속성은 정의되어 있지 않습니다. word-wrap는 CSS 2표준이 아니라는 이야기이지요. 이 속성은 IE에서 지원하는 속성으로 알고 있습니다.
이렇게 스타일을 주면 아래처럼 지정된 width이상이 되면 자동으로 줄바꿈이 되어 테이블의 레이아웃이 깨지지 않습니다.
word-wrap이 CSS표준도 아니지만 테스트 해 본 결과 IE외에도 꽤 많은 브라우저가 지원하고 있었습니다. IE 6, IE 7, IE8은 당연히 지원되고 Firefox 3.5, Safari 4, Google Chrome 2.0에서 모두 정상적으로 잘 나왔습니다.
제가 테스트해본 결과로는 Opera 9.63, Firefox 2.0, Firefox 3.0에서만 위처럼 깨져서 나왔습니다. 나온 모양으로 봐서는 table-layout만 적용되고 word-wrap은 지원하지 않아서 저렇게 나온듯 합니다.
위에 보듯이 완전한 해결책은 아니라고 할 수 있습니다. 지원안되는 브라우저도 있고 표준속성도 아니기 때문입니다. 다만 IE유저에 비해서 업데이트를 충실하게 해준다고 볼 수 있는 타 브라우저에서 FF 2.0이나 FF 3.0은 과거 버전이라서 다행이라고 할 수 있지만 Opera에서 안되는 것은 약간 아쉽네요.
제가 퍼블리셔가 아니라서 아직 명확한 해결책은 못찾았네요. 더 좋은 방법이 있으시면 알려주시면 감사하겠습니다.
[EP]Erich Gamma와 함께 여는 개발자 세상 세미나 #2..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
20분간의 Coffee Break뒤에 1시간가량의 "에릭에게 무엇이든 물어보세요"라는 Q&A시간이 있었습니다. 아무래도 워낙 유명하신 분이니 처음에는 질문이 약간 주춤하는 듯 하더니 나중에 시간이 모자랄만큼 질문이 쏟아졌습니다. 제가 잘 모르는 부분도 있고 이해못한 것도 있어서 다 정리는 못하고 이해한 정도로만 정리하였습니다.
Q. 애자일을 팀에 적용하려면 찬성하는 사람도 있지만 반대하는 사람도 있는데 어떻게 도입을 하는가?
Q. 요구사항에 대한 특별한 관리법이 있는가?
Q. 한국에서 개발자들의 처우는 별로 좋지 않은데 다른 나라의 개발자 문화는 어떠한가?
Q. RTC가 너무 기능이 많아서 시러하는 사람도 있는데 이런 사람들은 어떻게 설득하는가?
Q. 에릭감마가 디자인 패턴의 세계를 열었으나 소프트웨어 크리에이티브 책을 보면 대개 직관에 의해서 설계를 한다는 이야기가 있다. 현실의 세계는 너무 다양하기 때문에 경험에 의존하여 한다는 것이고 실제 Problem Domain의 정의가 여렵기 때문이다. RTC도 어떤 표준을 제공한다고 할 수 있는데 현실에 맞추기에는 어렵지 않은가?
Q. API설계시 어떤 기준을 가지고 정의하는가?
Q. 엔터프라이즈 아키텍쳐에서는 실제 구현되는 소프트웨어와 문서가 동일하지 않은 것이 가장 큰 불만중의 하나인데 Jazz에서는 이 문제를 어떻게 해결하는가?
Q. Jazz 대쉬보드가 Dojo로 만들어졌는데 사용해 보니 Dojo가 좀 느린 편인데 Jazz에서 사용할 때 속도 개선방법들이 있는가?
Q. 투명성(Transparency)에 대해서...
Q. Jazz를 디자인할 때 가장 중점둔 것은 무엇인가?
Q. 퀄리티 매니저를 만드는 이유는 무엇인가?
Q. 개발자에게 창의력이란?
Q. Jazz가 PMS(Project Management System)인데 실제로 쓰이고 있는 곳이 있는가? 한국에서는 개발자들은 RTC나 Trac같은 툴로 인수인계가 가능하고 도움이 되지만 산출물로 문서작업을 많이 하게 되는데 해외에서는 문서가 아닌 이런 툴로 산출물의 역할을 하기도 하는가?
Q. 당연한 방향이기는 하지만 Eclipse가 점점 커지고 있고 Plugin 개발자는 알아야 될 것도 많고 인수인계를 해야할 내용도 점점 많아지고 있다. 반갑지많은 않은 일인데 계속 이런 방향으로 진행될 예정인가? 그리고 Eclipse나 RTC 개발자가 이런 방향을 바라보는 자세는 어떠해야 하는가?
네임밸류가 역시 있어서 그런지 세미나 끝나고 싸인회도 하더군요. 이럴 줄 알았으면 싸인받을 책이라도 하나 준비해 가는 건데 그랬습니다. 에릭감마랑 사진도 찍어주었는데 부끄러워서(?) 싸인만 받아왔습니다.
세미나 참가선물로 준 마우스 패드의 에릭감마의 싸인을 받아왔습니다. 아까워서 쓰지도 못하겠군요... 패턴책이라도 하나 가져가져 싸인받았어야 했는데 아쉽군요. ㅎ
PS. IBM에서 이 행사의 동영상 다시보기를 제공해 주는군요. - 09.10.30 -
20분간의 Coffee Break뒤에 1시간가량의 "에릭에게 무엇이든 물어보세요"라는 Q&A시간이 있었습니다. 아무래도 워낙 유명하신 분이니 처음에는 질문이 약간 주춤하는 듯 하더니 나중에 시간이 모자랄만큼 질문이 쏟아졌습니다. 제가 잘 모르는 부분도 있고 이해못한 것도 있어서 다 정리는 못하고 이해한 정도로만 정리하였습니다.
Q. 애자일을 팀에 적용하려면 찬성하는 사람도 있지만 반대하는 사람도 있는데 어떻게 도입을 하는가?
A. 반감이 있는 사람과 1:1로 함께 개발을 해보는 것이 좋다. 그 사람이 장점을 직접 경험해 보아야 깨닫는다.
Q. 요구사항에 대한 특별한 관리법이 있는가?
A. 요구사항은 항상 바뀔 수밖에 없다. 쉽지 않은 문제다.
Q. 한국에서 개발자들의 처우는 별로 좋지 않은데 다른 나라의 개발자 문화는 어떠한가?
A. 문화권별로 차이는 있지만 스트레스가 많은 업무이다. 항상 과도한 업무를 진행할 수는 없기 때문에 집중적으로 일하는 시기와 릴렉스 할 수 있는 시기가 파도처럼 번갈아가면서 오는 것이 좋다.
Q. RTC가 너무 기능이 많아서 시러하는 사람도 있는데 이런 사람들은 어떻게 설득하는가?
A. 중요한 것은 자기 일을 공유안하면 안되다는 이해가 필요하다는 것이다. 이것은 팀 차원의 개념 공유가 필요하고 RTC는 개별 팀원별로는 없고 팀레벨의 리포트만 있기 때문에 개인을 감시하기 위한 것은 아니다.
Q. 에릭감마가 디자인 패턴의 세계를 열었으나 소프트웨어 크리에이티브 책을 보면 대개 직관에 의해서 설계를 한다는 이야기가 있다. 현실의 세계는 너무 다양하기 때문에 경험에 의존하여 한다는 것이고 실제 Problem Domain의 정의가 여렵기 때문이다. RTC도 어떤 표준을 제공한다고 할 수 있는데 현실에 맞추기에는 어렵지 않은가?
A. 과거의 일로 배우는 것은 중요하다고 생각하며 경험과 직관 모두에 의존해야 한다. 경험이 많을수록 어떤 Pattern이 떠오르게 되지만 경험이 없으면 알려진 Pattern등으로 다른 사람의 경험을 활용할 수 있다. Pattern을 이용해도 이것을 Template처럼 어디에나 적용하려고 하면 안되고 Pattern에서 시작해서 상황에 따라 적용해야하며 이런 점에서 패턴과 직관이 완전히 다른 얘기는 아니다.
책에 나오지 않은 패턴도 생각해야하고 책이 나온지 오래됐기 때문에 실제로 너무 오래된 패턴들도 많은 것이 사실이다.
Q. API설계시 어떤 기준을 가지고 정의하는가?
A. 사용의 용의성과 이해하기 쉬움이 가장 큰 기준이다. API의 사용 용이성을 평가하기 가장 좋은 방법이 Unit Test이며 또한 고객의 피드백도 좋은 방법이 된다.
Q. 엔터프라이즈 아키텍쳐에서는 실제 구현되는 소프트웨어와 문서가 동일하지 않은 것이 가장 큰 불만중의 하나인데 Jazz에서는 이 문제를 어떻게 해결하는가?
A. 현재 RTC는 Construction과 Development의 협업에 대해서만 초점을 맞추고 있다. 차후 계획은 가지고 있지만 아직은 안되고 있다.
Q. Jazz 대쉬보드가 Dojo로 만들어졌는데 사용해 보니 Dojo가 좀 느린 편인데 Jazz에서 사용할 때 속도 개선방법들이 있는가?
A. CSS모듈처리, 압축 등 상당히 많은 튜닝을 가했으며 쉽지 않은 작업니다.
 |  |
Q. 투명성(Transparency)에 대해서...
A. 투명성은 양방향이 중요하다. 팀장이 팀원들의 일에 대해서 알고 팀원들은 팀장의 일에 대한 정보를 알아야 한다.
Q. Jazz를 디자인할 때 가장 중점둔 것은 무엇인가?
A. 실제 존재하는 Pain Point를 해결하는 것이 목적이었으며 버전에 대한 의존성에 대해 많은 고민이 있었으며 이것을 REST베이스와 Loose Coupling으로 해결을 했다. 최초부터 완벽한 디자인은 없으며 계속 진화해 나아가야 하며 사실 처음 디자인한 것은 너무 복잡해서 확장이 불가능했으며 피드백 받아서 심플하게 변경하였다. 디자인은 쉽지 않은 일이다.
Q. 퀄리티 매니저를 만드는 이유는 무엇인가?
A. 테스트 관리는 좀 더 협업이 필요하다. 개발과 테스트는 보통 협업이 잘 안되고 있으며 테스터는 왜 이렇게 개발했는지 모르고 개발은 테스트하기 위해서 기다리고 있다는 것 조차 모른다. 협업이 목적이다. 이미 나온 테스트툴들도 많기 때문에 이런 툴들과의 통합도 필요하며 고객이 툴을 선택해서 REST로 통합하는 구조가 궁극적인 목표이고 이것이 OSLC이다.
A. A에서 B로 가는 길을 찾는데 피드백을 받고 테스트를 하면서 가장 효율적으로 가는 것이며 이게 문제를 해결하는 방법이다. 개발자라는 Job이 흥미로운 이유는 어떤 때에는 이미 한 것을 다시 하기도 하지만 어떤 때에는 완전히 새로운 것을 한다는 것이다. 그래서 행복감을 느낀다.
Q. Jazz가 PMS(Project Management System)인데 실제로 쓰이고 있는 곳이 있는가? 한국에서는 개발자들은 RTC나 Trac같은 툴로 인수인계가 가능하고 도움이 되지만 산출물로 문서작업을 많이 하게 되는데 해외에서는 문서가 아닌 이런 툴로 산출물의 역할을 하기도 하는가?
A. Jazz는 플랫폼이고 그 위에 많은 Product가 올라간다. RTC는 애자일을 서포트하는 역할이며 전통적인 방법론을 지원하는 툴은 따로 또 있다. 애자일만을 위해서 RTC라는 툴을 분리한 이유는 애자일은 초기에 설계하는 방식부터 접근방법자체가 완전히 다르기 때문이다. Jazz가 산출물을 위한 리파지토리도 제공하기 때문에 도움이 될 것이다.
Q. 당연한 방향이기는 하지만 Eclipse가 점점 커지고 있고 Plugin 개발자는 알아야 될 것도 많고 인수인계를 해야할 내용도 점점 많아지고 있다. 반갑지많은 않은 일인데 계속 이런 방향으로 진행될 예정인가? 그리고 Eclipse나 RTC 개발자가 이런 방향을 바라보는 자세는 어떠해야 하는가?
A. 이런 추세를 바라고 있는 것은 아니지만 피할 수는 없다. 이런 문제는 이클립스 팀도 충분히 인식하고 있으며 고민하고 여러가지 실험도 하고 있다. 궁극적인 추구는 역할(Role) 베이스로 가는 것인제 Role에 대한 정의가 쉽지 않아서 진행이 빠르지는 않다. 반가운 것은 점점 웹UI로 옮겨가는 단계이기 때문에 좀더 쉬워질 가능성이 높아지고 있다.
또하나 중요한 것은 이클립스 베이스로 Role에 맞게 UI를 변경가능하도록 되어야 한다. 이미 이런 기술을 가지고 있으며 복잡성을 해결하기 위한 방법중 하나이다.
네임밸류가 역시 있어서 그런지 세미나 끝나고 싸인회도 하더군요. 이럴 줄 알았으면 싸인받을 책이라도 하나 준비해 가는 건데 그랬습니다. 에릭감마랑 사진도 찍어주었는데 부끄러워서(?) 싸인만 받아왔습니다.
세미나 참가선물로 준 마우스 패드의 에릭감마의 싸인을 받아왔습니다. 아까워서 쓰지도 못하겠군요... 패턴책이라도 하나 가져가져 싸인받았어야 했는데 아쉽군요. ㅎ
PS. IBM에서 이 행사의 동영상 다시보기를 제공해 주는군요. - 09.10.30 -
[EP]Erich Gamma와 함께 여는 개발자 세상 세미나 #1..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
IBM에서 에릭감마를 초청해서 "Erich Gamma와 함께 여는 개발자 세상"이라는 제목으로 세미나를 열었습니다. 에릭 감마는 아시는 분은 아시겠지만 GoF(Gang of Four)중의 한명입니다. GoF는 Design Patterns (번역서)책의 저자로 이 디자인패턴이 프로그래밍의 새로운 지평을 역사적인 서적입니다.(라고 하더군요. 내공이 딸려서 아직 못읽어봤네요.) 어쨌든 이 책을 지은 에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vissides) 이렇게 4명을 Gang of Four라고 부릅니다. 역사적인 분들이시죠.. ㅎㅎㅎㅎㅎ
그 중의 에릭 감마는 제가 제일 좋아하는 IDE이기도 한 Eclipse의 창시자로 지금도 Eclipse 개발그룹을 이끌고 있습니다. 2주전에 에릭감마가 온다는 얘기를 듣고는 냉큼 신청해 놓고는 눈치보다가 이번주에는 바쁜일도 없고 해서 허락을 맡고 갔다 왔습니다. GoF중의 한명인 랄프 존슨도 지난주 토요일(15일)에 국내에서 세미나가 있었습니다. 다음 달에는 켄트벡이 온다는 소식이 들리던데.... 평생 한번 볼 수나 있을까 했던 분들이 갑자기 대거 한국에 오시는군요. ㅎㅎ
행사는 위와같은 순서로 진행되었습니다.
세미나 처음에는 IBM 이승재 사업부장의 간단한 환영사와 한국소프트웨어진흥원 SW공학단의 이상은님의 축사로 시작되었습니다. 근데 머 말이 축사이지 왜하는지 알 수 없는 소프트웨어공학에 대한 PPT로 이어졌습니다. ㅡ..ㅡ
어쨌든 이어서 드디어 기다리던 에릭감마의 "협업을 위한 개방형 소프트웨어 개발 플랫폼 Jazz 및 협업 개발 환경 솔루션 RTC 소개"가 이어졌습니다.
에릭감마가 진행한 PPT는 "how (8 years of) eclipse changed my views on software development"라는 제목이었는데 파일로까지는 제공해 주지 않아서 에릭감마가 QCON 2008에서 한 PPT를 가져왔습니다.(작년에 한거라서 7 years이네요.. ㅎ) 약간 변경되긴 했는데 대부분은 거의 비슷하더군요.
포스팅 뒤에 IBM에서 발표자료를 보내주었습니다. IBM사이트에서 PDF 다운로드가 가능합니다 첨부했던 작년자료도 올해 발표자료로 교체하였습니다.
Eclipse 개발
발표는 이클립스에 대한 설명부터 이어졌습니다. 처음에는 이 얘기를 왜 하나 했는데 이클립스를 개발하면서 겪은 경험을 토대로 개념이 발전되면서 구성된 것이 Jazz라고 할 수 있는것 같습니다. 이클립스가 앞으로 Jazz가 된다는 것은 아니고 이클립스 개발이 진행되면서 에릭 감마가 구상한 시스템이 Jazz라는 형태로 실체화 된 것 같습니다.
이클립스를 만들고 사용하면서 바뀐 생각들부터 얘기하고 있습니다. 이클립스는 2000년에 시작되었습니다. 건물을 예로 들면 건물의 위치, 구조, 전선, 가구들의 수명이 다릅니다. 벽이나 구조, 땅 등은 수십년에서 수백년을 가지만 가구들같은 경우는 몇년마다 바뀌기도 합니다. 이클립스도 이렇게 레이어마다 수명이 다르게 구성되어야 하고 그 기반시스템(Structure foundation)을 플러그인(plug-in) 아키텍쳐로 결정하였습니다. 그리고 이 플러그인은 API에 의존적입니다.
그래서 API가 중요했고 API의 디자인이 필요했습니다. 그리고 UI는 계속 진화하고 있습니다. 여기서 중요한 결론은 모듈화가 중요하고 모든 것은 플러그인이고 API는 거대한 약속인데 안정성이 중요하고 너무 많은 것을 정의하려고 하지는 않았습니다.
이클립스 3.4에서는 API의 Baseline를 선택할 수 있게 되어 있는데 API는 계속 발전하여야 하는데 버전에 종속되지 않는 것이 좋다는 결론이 나왔습니다. 마치 인터넷 처럼 URL과 HTTP로 정의되고 각 요구들이 Link로 연결이 됩니다. 그래서 API스타일을 REST스타일로 변경하였습니다. 이것이 실체화 된것이 OSLC입니다. 이클립스는 Jazz로 발전하고 Jazz는 RTC로 구체화 됩니다.
Eclipse의 오픈소스화
2002년에는 이클립스에게 큰 변화가 생기는데 이클립스의 오픈소스화가 결정됩니다. 그 이전까지는 스위스 은행처럼 폐쇄적인 방식이었습니다. 그래서 개발자와 사용자간의 소통이 없었고 사용자들이 무언가를 물어보아도 알려줄 수 없다는 대답만 할 뿐이었습니다. 하지만 에릭감마는 개발자와 사용자의 커뮤니티를 믿고 있습니다. 그래서 2002부터 오픈소스화가 결정되어 그뒤로는 오픈소스로 진행이 됩니다.
이클립스팀은 선적(Shipping)을 중요하게 생각합니다. 일정 퀄리티이상이 되었을 경우에만 선적을 하며 얼마나 선적했냐가 팀의 공헌도를 증명하게 됩니다. 오픈소스화가 되니까 공개적으로 기술적인 논의를 하는 것이 솔직히 좀 두려웠었다고 합니다. 이 과정에서는 오픈소스는 투명한 사용자 커뮤니티와 개발자간의 피드백이 선순환 되는 아주 훌륭한 이 모델이며 오픈소스프로젝트에 제한은 없기 때문에 이 모델을 상용에 적용하여 개방형 상용개발을 할 수 있습니다.
개방형 상용개발(Open Commercial Development)을 Jazz에 적용하였고 사용자 피드백으로 품질을 향상시킬 수 있었습니다. Eclipse Way Practices는 특별한 것은 없습니다. 여러가지 방법론등이 있는데 그 방법론 자체는 중요하지 않고 어떻게 조합하는 가가 중요합니다. 그렇게 해서 점진적으로 가치(Value)를 증가시켜야 합니다. 그래서 원하는 Value(보통은 일정)을 극대화 할 수 있도록 하였습니다.
위 화면은 에릭감마가 강조하였던 그림입니다. 과거에는 빨간줄처럼 되었다면 이제는 늘어지지 않게 반복주기를 촘촘하게 함으로써 스트레스를 줄입니다. 반복적이고 적응되어가는 계획, 디자인/리펙토링, 통합과 테스팅, 딜리버링과 데모, 피드백, 학습등을 끊임없이(continuous) 수행되어야 할 일들입니다. (이건 애자일에서 얘기하는 것을 말한것 같군요.)
JAZZ와 Team Concert
하지만 이클립스에서 어려운 점(Pain Points)들이 있었습니다. 그것은 협업(Collaboration), 개발(Development), 프로젝트 관리(Project Management)입니다.
이클립스를 만들때에는 한명의 개발자에게 초점을 맞추었었습니다. 하지만 지금은 팀과 팀의 협업에 초점을 맞추어야 합니다.그것이 Jazz와 Team Concert입니다. Open Lifecycle services Interrations위에 Jazz Team Server가 올라가고 그 위에 많은 툴들이 올라가고 서로 Intergration이 가능합니다. RTC(Rational Team Concert)가 그중 하나입니다.
RCT의 개발은 4년전부터 이클립스 팀에 의해서 시작되었습니다. 소스관리, Work Item, 빌드, 프로젝트 상태들이 통합되어 있습니다. Invitation메일을 받고 팀원들이 가입을 할 수 있으면 일정, 현재 하는 질, 진행사항, 테스트, 소스코드, 일 할당, 결정 추적, 소스리뷰등이 통합되어 있습니다. 이 모든 것을 Jazz의 대쉬보드에서 볼 수 있습니다. (보통은 문서로 만들어서 잘 안읽어보게 되는)팀내의 룰이나 프로세스를 강제해서 새로온 참여한 팀원들에게 강제할 수 있습니다.
목표는 팀작업의 효율성을 높이는 것입니다. 문제가 생길 경우 Jazz의 대쉬보드를 통해서 쉽게 파악할 수 있습니다. 개인적인 대쉬보드와 팀의 대쉬보드뿐만 아니라 팀들의 팀단위(프로젝트 레벨)의 대쉬보드도 제공하고 있습니다.
오기전에 Jazz와 RTC(Rational Team Concert)에 대해서 좀 공부를 했었는데 내용이 복잡해서 대충 감정도만 잡았습니다. 에릭감마가 만든 Jazz는 개방형 협업 개발플랫폼이고 RTC는 Jazz플랫폼에 올라가는 Product중 하나로 애자일개발에 맞게 구성된 솔루션입니다.
생각보다 양이 많아져서 포스팅을 나눠야겠습니다.
아무래도 Jazz플랫폼과 RTC라는 툴에 대한 세미나 였기 때문에 툴 사용법을 가르쳐 주는 것을 의도에 맞지 않았을 때고 가볍게 시연을 해주기는 했지만 협업플랫폼이라는 타이틀도 규모가 크고 RTC자체가 기능이 너무 많아서 시연정도로 다 파악하기엔 무리였습니다. 결국 제대로 어떤 툴인지 파악하기 위해서는 실제로 사용을 점 해보아야 할 것 같습니다.
My Comment..
해당 포스팅은 가져올까 말까 고민을 했었다.. 시간이 꽤 흐르기도 했서 이제와서 가져온다고 도움이 될까라는 생각을 하면서 안갖고 와도.. 햄의 포스팅은 다 읽어보고 있기에 읽어봤는데.. 햄의 말처럼 Eclipse 의 창시자고, 대부분의 개발자가 쓰는 Eclipse 에 대해서 여러가지 설명들이 있어서.. 어떻게 개발이 되어간건지.. 탄생한건지.. 어떤 기타 히스토리가 있었는지 봐두면 좋을 듯 해서 가져왔다..
IBM에서 에릭감마를 초청해서 "Erich Gamma와 함께 여는 개발자 세상"이라는 제목으로 세미나를 열었습니다. 에릭 감마는 아시는 분은 아시겠지만 GoF(Gang of Four)중의 한명입니다. GoF는 Design Patterns (번역서)책의 저자로 이 디자인패턴이 프로그래밍의 새로운 지평을 역사적인 서적입니다.(라고 하더군요. 내공이 딸려서 아직 못읽어봤네요.) 어쨌든 이 책을 지은 에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vissides) 이렇게 4명을 Gang of Four라고 부릅니다. 역사적인 분들이시죠.. ㅎㅎㅎㅎㅎ
그 중의 에릭 감마는 제가 제일 좋아하는 IDE이기도 한 Eclipse의 창시자로 지금도 Eclipse 개발그룹을 이끌고 있습니다. 2주전에 에릭감마가 온다는 얘기를 듣고는 냉큼 신청해 놓고는 눈치보다가 이번주에는 바쁜일도 없고 해서 허락을 맡고 갔다 왔습니다. GoF중의 한명인 랄프 존슨도 지난주 토요일(15일)에 국내에서 세미나가 있었습니다. 다음 달에는 켄트벡이 온다는 소식이 들리던데.... 평생 한번 볼 수나 있을까 했던 분들이 갑자기 대거 한국에 오시는군요. ㅎㅎ
행사는 위와같은 순서로 진행되었습니다.
세미나 처음에는 IBM 이승재 사업부장의 간단한 환영사와 한국소프트웨어진흥원 SW공학단의 이상은님의 축사로 시작되었습니다. 근데 머 말이 축사이지 왜하는지 알 수 없는 소프트웨어공학에 대한 PPT로 이어졌습니다. ㅡ..ㅡ
어쨌든 이어서 드디어 기다리던 에릭감마의 "협업을 위한 개방형 소프트웨어 개발 플랫폼 Jazz 및 협업 개발 환경 솔루션 RTC 소개"가 이어졌습니다.
에릭감마가 진행한 PPT는 "how (8 years of) eclipse changed my views on software development"라는 제목이었는데 파일로까지는 제공해 주지 않아서 에릭감마가 QCON 2008에서 한 PPT를 가져왔습니다.(작년에 한거라서 7 years이네요.. ㅎ) 약간 변경되긴 했는데 대부분은 거의 비슷하더군요.
포스팅 뒤에 IBM에서 발표자료를 보내주었습니다. IBM사이트에서 PDF 다운로드가 가능합니다 첨부했던 작년자료도 올해 발표자료로 교체하였습니다.
Eclipse 개발
발표는 이클립스에 대한 설명부터 이어졌습니다. 처음에는 이 얘기를 왜 하나 했는데 이클립스를 개발하면서 겪은 경험을 토대로 개념이 발전되면서 구성된 것이 Jazz라고 할 수 있는것 같습니다. 이클립스가 앞으로 Jazz가 된다는 것은 아니고 이클립스 개발이 진행되면서 에릭 감마가 구상한 시스템이 Jazz라는 형태로 실체화 된 것 같습니다.
이클립스를 만들고 사용하면서 바뀐 생각들부터 얘기하고 있습니다. 이클립스는 2000년에 시작되었습니다. 건물을 예로 들면 건물의 위치, 구조, 전선, 가구들의 수명이 다릅니다. 벽이나 구조, 땅 등은 수십년에서 수백년을 가지만 가구들같은 경우는 몇년마다 바뀌기도 합니다. 이클립스도 이렇게 레이어마다 수명이 다르게 구성되어야 하고 그 기반시스템(Structure foundation)을 플러그인(plug-in) 아키텍쳐로 결정하였습니다. 그리고 이 플러그인은 API에 의존적입니다.
그래서 API가 중요했고 API의 디자인이 필요했습니다. 그리고 UI는 계속 진화하고 있습니다. 여기서 중요한 결론은 모듈화가 중요하고 모든 것은 플러그인이고 API는 거대한 약속인데 안정성이 중요하고 너무 많은 것을 정의하려고 하지는 않았습니다.
이클립스 3.4에서는 API의 Baseline를 선택할 수 있게 되어 있는데 API는 계속 발전하여야 하는데 버전에 종속되지 않는 것이 좋다는 결론이 나왔습니다. 마치 인터넷 처럼 URL과 HTTP로 정의되고 각 요구들이 Link로 연결이 됩니다. 그래서 API스타일을 REST스타일로 변경하였습니다. 이것이 실체화 된것이 OSLC입니다. 이클립스는 Jazz로 발전하고 Jazz는 RTC로 구체화 됩니다.
Eclipse의 오픈소스화
2002년에는 이클립스에게 큰 변화가 생기는데 이클립스의 오픈소스화가 결정됩니다. 그 이전까지는 스위스 은행처럼 폐쇄적인 방식이었습니다. 그래서 개발자와 사용자간의 소통이 없었고 사용자들이 무언가를 물어보아도 알려줄 수 없다는 대답만 할 뿐이었습니다. 하지만 에릭감마는 개발자와 사용자의 커뮤니티를 믿고 있습니다. 그래서 2002부터 오픈소스화가 결정되어 그뒤로는 오픈소스로 진행이 됩니다.
이클립스팀은 선적(Shipping)을 중요하게 생각합니다. 일정 퀄리티이상이 되었을 경우에만 선적을 하며 얼마나 선적했냐가 팀의 공헌도를 증명하게 됩니다. 오픈소스화가 되니까 공개적으로 기술적인 논의를 하는 것이 솔직히 좀 두려웠었다고 합니다. 이 과정에서는 오픈소스는 투명한 사용자 커뮤니티와 개발자간의 피드백이 선순환 되는 아주 훌륭한 이 모델이며 오픈소스프로젝트에 제한은 없기 때문에 이 모델을 상용에 적용하여 개방형 상용개발을 할 수 있습니다.
개방형 상용개발(Open Commercial Development)을 Jazz에 적용하였고 사용자 피드백으로 품질을 향상시킬 수 있었습니다. Eclipse Way Practices는 특별한 것은 없습니다. 여러가지 방법론등이 있는데 그 방법론 자체는 중요하지 않고 어떻게 조합하는 가가 중요합니다. 그렇게 해서 점진적으로 가치(Value)를 증가시켜야 합니다. 그래서 원하는 Value(보통은 일정)을 극대화 할 수 있도록 하였습니다.
위 화면은 에릭감마가 강조하였던 그림입니다. 과거에는 빨간줄처럼 되었다면 이제는 늘어지지 않게 반복주기를 촘촘하게 함으로써 스트레스를 줄입니다. 반복적이고 적응되어가는 계획, 디자인/리펙토링, 통합과 테스팅, 딜리버링과 데모, 피드백, 학습등을 끊임없이(continuous) 수행되어야 할 일들입니다. (이건 애자일에서 얘기하는 것을 말한것 같군요.)
JAZZ와 Team Concert
하지만 이클립스에서 어려운 점(Pain Points)들이 있었습니다. 그것은 협업(Collaboration), 개발(Development), 프로젝트 관리(Project Management)입니다.
이클립스를 만들때에는 한명의 개발자에게 초점을 맞추었었습니다. 하지만 지금은 팀과 팀의 협업에 초점을 맞추어야 합니다.그것이 Jazz와 Team Concert입니다. Open Lifecycle services Interrations위에 Jazz Team Server가 올라가고 그 위에 많은 툴들이 올라가고 서로 Intergration이 가능합니다. RTC(Rational Team Concert)가 그중 하나입니다.
RCT의 개발은 4년전부터 이클립스 팀에 의해서 시작되었습니다. 소스관리, Work Item, 빌드, 프로젝트 상태들이 통합되어 있습니다. Invitation메일을 받고 팀원들이 가입을 할 수 있으면 일정, 현재 하는 질, 진행사항, 테스트, 소스코드, 일 할당, 결정 추적, 소스리뷰등이 통합되어 있습니다. 이 모든 것을 Jazz의 대쉬보드에서 볼 수 있습니다. (보통은 문서로 만들어서 잘 안읽어보게 되는)팀내의 룰이나 프로세스를 강제해서 새로온 참여한 팀원들에게 강제할 수 있습니다.
목표는 팀작업의 효율성을 높이는 것입니다. 문제가 생길 경우 Jazz의 대쉬보드를 통해서 쉽게 파악할 수 있습니다. 개인적인 대쉬보드와 팀의 대쉬보드뿐만 아니라 팀들의 팀단위(프로젝트 레벨)의 대쉬보드도 제공하고 있습니다.
오기전에 Jazz와 RTC(Rational Team Concert)에 대해서 좀 공부를 했었는데 내용이 복잡해서 대충 감정도만 잡았습니다. 에릭감마가 만든 Jazz는 개방형 협업 개발플랫폼이고 RTC는 Jazz플랫폼에 올라가는 Product중 하나로 애자일개발에 맞게 구성된 솔루션입니다.
 |  |  |
생각보다 양이 많아져서 포스팅을 나눠야겠습니다.
아무래도 Jazz플랫폼과 RTC라는 툴에 대한 세미나 였기 때문에 툴 사용법을 가르쳐 주는 것을 의도에 맞지 않았을 때고 가볍게 시연을 해주기는 했지만 협업플랫폼이라는 타이틀도 규모가 크고 RTC자체가 기능이 너무 많아서 시연정도로 다 파악하기엔 무리였습니다. 결국 제대로 어떤 툴인지 파악하기 위해서는 실제로 사용을 점 해보아야 할 것 같습니다.
My Comment..
해당 포스팅은 가져올까 말까 고민을 했었다.. 시간이 꽤 흐르기도 했서 이제와서 가져온다고 도움이 될까라는 생각을 하면서 안갖고 와도.. 햄의 포스팅은 다 읽어보고 있기에 읽어봤는데.. 햄의 말처럼 Eclipse 의 창시자고, 대부분의 개발자가 쓰는 Eclipse 에 대해서 여러가지 설명들이 있어서.. 어떻게 개발이 되어간건지.. 탄생한건지.. 어떤 기타 히스토리가 있었는지 봐두면 좋을 듯 해서 가져왔다..
[JS]Javascript에서 String을 Number타입으로 바꾸기..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
누가 물어봐서 찾아본 김에 그냥 정리합니다. 아시다시피 Javascript는 명시적인 타입정의가 없습니다. int나 String같이 타입을 명시해서 변수를 정의하지 않고 그냥 var타입으로 정의하면 Javascript가 알아서 적절한 타입을 지정합니다. 명시적인 타입이 없다는건 때론 타입때문에 헷갈리기도 하고 원치 않는 결과가 나타나기도 합니다.
그래서 보통은 약간 편법적인 방법으로 String을 Number로 바꾼다던지 Number를 String으로 바꾼다던지 합니다.
또한 아래처럼 parseInt()나 parseFloat()를 이용해서도 형변환을 할 수 있습니다. 함수명에서 알 수 있듯이 parseInt()는 Integer타입으로 변환을 하고 parseFloat()는 Float타입으로 변환을 합니다.
API정의를 보면 위처럼 정의되어 있습니다. parseInt()에서 radix는 기수로 parse할 때 기준이 되는 진수입니다. 정수로 파싱하는 parseInt에만 정의되어 있습니다. 2~ 36진수까지를 정의할 수 있고 optional값으로 없을 경우 10진수로 parse합니다.
누가 물어봐서 찾아본 김에 그냥 정리합니다. 아시다시피 Javascript는 명시적인 타입정의가 없습니다. int나 String같이 타입을 명시해서 변수를 정의하지 않고 그냥 var타입으로 정의하면 Javascript가 알아서 적절한 타입을 지정합니다. 명시적인 타입이 없다는건 때론 타입때문에 헷갈리기도 하고 원치 않는 결과가 나타나기도 합니다.
그래서 보통은 약간 편법적인 방법으로 String을 Number로 바꾼다던지 Number를 String으로 바꾼다던지 합니다.
1
2
3
4
5
6
7
8
9
| // 숫자를 스트링로 바꾸기
var tt = 2
tt += "";
alert(typeof tt); // Result : string
// 스트링을 숫자로 바꾸기
tt = "2"
tt *= 1;
alert(typeof tt); // Result : number
|
위의 방법이 가장 간단하게 형변환을 하는 방법입니다. 쉽게 자바스크립트의 자동형변환을 이용한 겁니다. 숫자타입에 문자열을 더하면 결과가 문자열이 되고 문자열에 숫자를 곱하면 숫자타입이 되는 특성을 이용해서 결과는 달라지지 않게 타입만 변환되도록 한 것입니다.
해본 사람을 보면 알기는 하겠지만 잘 모르는 사람이 보면 어떤 의도로 한 소스인지 명확하지 않은 단점이 있기도 하고 좀더 명시적으로 타입변환이 필요할 때가 있습니다.
JavaScript
타입변환을 하는 함수인 Number()와 String()을 이용한 소스입니다.
1
2
3
4
5
6
7
8
9
10
11
| // 숫자를 스트링로 바꾸기
var tt = 2
alert(typeof tt); // Result : number
tt = String(tt);
alert(typeof tt); // Result : string
// 스트링을 숫자로 바꾸기
tt = "2"
alert(typeof tt); // Result : string
tt = Number(tt);
alert(typeof tt); // Result : number
|
타입변환을 하는 함수인 Number()와 String()을 이용한 소스입니다.
또한 아래처럼 parseInt()나 parseFloat()를 이용해서도 형변환을 할 수 있습니다. 함수명에서 알 수 있듯이 parseInt()는 Integer타입으로 변환을 하고 parseFloat()는 Float타입으로 변환을 합니다.
JavaScript
parseInt()나 parseFloat()는 형변환 자체가 목적은 아니기 때문에 얘기가 나온 김에 좀 더 살펴보겠습니다. parseIn()와 parseFloat()는 정수와 실수로 파싱해 주는 역할을 하고 있습니다.
1
2
3
4
5
6
7
8
9
| var tt = "2"
alert(typeof tt); // Result : string
tt = parseInt(tt);
alert(typeof tt); // Result : number
tt = "2"
alert(typeof tt); // Result : string
tt = parseFloat(tt);
alert(typeof tt); // Result : number
|
parseInt()나 parseFloat()는 형변환 자체가 목적은 아니기 때문에 얘기가 나온 김에 좀 더 살펴보겠습니다. parseIn()와 parseFloat()는 정수와 실수로 파싱해 주는 역할을 하고 있습니다.
parseInt(string, radix)
parseFloat(string)
parseFloat(string)
API정의를 보면 위처럼 정의되어 있습니다. parseInt()에서 radix는 기수로 parse할 때 기준이 되는 진수입니다. 정수로 파싱하는 parseInt에만 정의되어 있습니다. 2~ 36진수까지를 정의할 수 있고 optional값으로 없을 경우 10진수로 parse합니다.
JavaScript
Javascript에서 "0"으로 시작하는 숫자는 8진수 "0x"로 시작하는 숫자는 16진수로 정의되고 있기 때문에 5번라인에서 9가 8진수에서 사용할 수 없기 때문에 의도하지 않은 0이 나왔습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| parseInt("123.456"); // 123
parseInt("100mile"); // 100
parseInt("w25"); // NaN
parseInt("05"); // 5
parseInt("09"); // 0
parseInt("0x35"); // 53
parseInt("1101", 2); // 13
parseInt("09", 10); // 9
parseInt("10", 8); // 8
parseFloat("123.456"); // 123.456
parseFloat("100.5mile"); // 100.5
parseFloat("w25"); // NaN
parseFloat("05"); // 5
parseFloat("09"); // 9
parseFloat("0x35"); // 0
|
Javascript에서 "0"으로 시작하는 숫자는 8진수 "0x"로 시작하는 숫자는 16진수로 정의되고 있기 때문에 5번라인에서 9가 8진수에서 사용할 수 없기 때문에 의도하지 않은 0이 나왔습니다.
[DEV]알고 있어야 할 8가지 정규식 표현 from nettuts+..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
nettuts+에 Vasili이 쓴 유용한 정규식 표현에 대한 글을 올려서 내용 정리합니다. 정규식만 잘 써도 Validation이나 String을 다루기가 무척 편할텐데 쓸때마다 헷갈리고 약간은 어렵게 느껴지고 쉽게 다가가지지 않는게 정규식인것 같습니다.
Vasili는 정규식에 대해서 잘 모르면 Regular Expressions for Dummies 스크린캐스트 시리즈를 보기 권하고 있습니다. 시간내서 보면 꽤 도움이 될듯 합니다. 자리 잡고 스크린캐스트 보게는 잘 안되는것 같습니다. 글을 읽어도... ㅎㅎ
정규표현식을 공부해도 막상 적용하려면 약간 막막하고 헷갈리기 마련인데 웹개발할 때 보통 많이 사용할 만한 내용을 위주로 설명해 주었기 때문에 이해하기도 쉽고 활용해서 쓰기에 꽤나 유용할 듯 보입니다. (위에도 간단히 밝혔지만 nettuts+의 올라온 포스팅을 번역,정리한 내용입니다.) 간단한 정규표현식 문법은 전에 올린 포스팅을 참고하시면 될 것 같습니다.
Matching a Username
C-like
문자열의 시작부분을 찾는 ^ 다음에 소문자(a-z)나 숫자(0-9), 언더스코어(_), 하이픈(-)가 나올 수 있고 {3, 16}은 앞의 캐릭터들( [a-z0-9_-] )이 최소 3개에서 15개 이하로 나와야 하고 문자열의 끝을 의미하는 $가 마지막에 나옵니다.
Match되는 스트링 : my-us3r_n4m3
Match되지 않는 문자열 : th1s1s-wayt00_l0ngt0beausername (너무 김)
Matching a Password
C-like
mod_rewrite나 pretty URL을 사용해 본적이 있다면 이 정규표현식을 사용하게 될 것입니다. 시작 문자열인 ^가 처음에 나오고 뒤이어 소문자, 숫자, 하이픈(-)이 한개 또는 한개이상(+기호)나오고 마지막으로 문자열의 끝인 $가 나옵니다.
Match되는 스트링 : my-title-here
Match되지 않는 문자열 : my_title_here (언더스코어( _ ) 가 포함되어 있음)
Matching an Email
C-like
문자열의 시작인 ^로 시작하고 첫번째 그룹(괄호 안)에서 1개 또는 그 이상의 소문자, 숫자, 언더스코어( _ ), 점(.), 하이픈(-)가 나옵니다. escape하지 않은 점(.)은 다른 문자를 의미하기 때문에 점(.)은 이스케이프 해줍니다.(\.) 그 뒤에 앳 기호(@)가 나오고 그 다음 1개또는 그 이상의 소문자, 숫자, 언더스코어( _ ), 점(.), 하이픈(-)으로 구성된 도메인명이 옵고 그 후 점(이스케이프된)이 소문자와 점으로 된 2~6개의 문자열이 옵니다. 2~6개로 한 이유는 .co.kr이나 .ny.us같은 국가 TLD(Top-Level-Domain)때문이며 마지막으로 문자열의 끝($)인 옵니다.
Match되는 스트링 : john@doe.com
Match되지 않는 문자열 : john@doe.something (TLS가 너무 김)
Matching a URL
nettuts+에 Vasili이 쓴 유용한 정규식 표현에 대한 글을 올려서 내용 정리합니다. 정규식만 잘 써도 Validation이나 String을 다루기가 무척 편할텐데 쓸때마다 헷갈리고 약간은 어렵게 느껴지고 쉽게 다가가지지 않는게 정규식인것 같습니다.
Vasili는 정규식에 대해서 잘 모르면 Regular Expressions for Dummies 스크린캐스트 시리즈를 보기 권하고 있습니다. 시간내서 보면 꽤 도움이 될듯 합니다. 자리 잡고 스크린캐스트 보게는 잘 안되는것 같습니다. 글을 읽어도... ㅎㅎ
정규표현식을 공부해도 막상 적용하려면 약간 막막하고 헷갈리기 마련인데 웹개발할 때 보통 많이 사용할 만한 내용을 위주로 설명해 주었기 때문에 이해하기도 쉽고 활용해서 쓰기에 꽤나 유용할 듯 보입니다. (위에도 간단히 밝혔지만 nettuts+의 올라온 포스팅을 번역,정리한 내용입니다.) 간단한 정규표현식 문법은 전에 올린 포스팅을 참고하시면 될 것 같습니다.
Matching a Username
1 2 | // Pattern /^[a-z0-9_-]{3,16}$/ |
문자열의 시작부분을 찾는 ^ 다음에 소문자(a-z)나 숫자(0-9), 언더스코어(_), 하이픈(-)가 나올 수 있고 {3, 16}은 앞의 캐릭터들( [a-z0-9_-] )이 최소 3개에서 15개 이하로 나와야 하고 문자열의 끝을 의미하는 $가 마지막에 나옵니다.
Match되는 스트링 : my-us3r_n4m3
Match되지 않는 문자열 : th1s1s-wayt00_l0ngt0beausername (너무 김)
Matching a Password
C-like
username부분과 아주 유사합니다만 유일하게 다른 부분은 글자수가 3~16자가 아니라 6~18자라는 부분( {6,18} )입니다.
Match되는 스트링 : myp4ssw0rd
Match되지 않는 문자열 : mypa$$w0rd (달러($)표시가 포함되어 있음)
Matching a Hex value
1 2 | // Pattern /^[a-z0-9_-]{6,18}$/ |
username부분과 아주 유사합니다만 유일하게 다른 부분은 글자수가 3~16자가 아니라 6~18자라는 부분( {6,18} )입니다.
Match되는 스트링 : myp4ssw0rd
Match되지 않는 문자열 : mypa$$w0rd (달러($)표시가 포함되어 있음)
Matching a Hex value
C-like
이번에서 문자열의 시작을 찾는 ^로 시작합니다. 그 다음 number sign(#)은 뒤에 물음표(?)가 있기 때문에 옵션입니다. 물음표(?)는 그 앞에 나온 캐릭터가(여기서는 number sign)이 선택사항(있어도 되고 없어도 되는)임을 의미합니다. 그 다음에 나오는 그룹(괄호 안에 있는)에서 2가지 경우를 가질 수 있습니다. 첫번째는 a와 f사이의 소문자나 숫자가 6번나오는 것입니다. 세로바(|)는 3개의 a와 f사이의 소문자나 숫자가 대신 나올수도 있음을 으미합니다. 마지막으로 문자열의 끝을 의미하는 $가 위치합니다.
6개의 문자열을 앞에 둔 이유는 #ffffff같은 Hex값을 파서가 잡아내도록 하기 위한 것으로 반대로 3개의 문자열 검사를 앞에 두었다면 파서는 뒤의 3개의 f는 빼로 오직 #fff만을 잡아냈을 것입니다.
Match되는 스트링 : #a3c113
Match되지 않는 문자열 : #4d82h4 (h 가 포함되어 있음)
Matching a Slug
1 2 | // Pattern /^#?([a-f0-9]{6}|[a-f0-9]{3})$/ |
이번에서 문자열의 시작을 찾는 ^로 시작합니다. 그 다음 number sign(#)은 뒤에 물음표(?)가 있기 때문에 옵션입니다. 물음표(?)는 그 앞에 나온 캐릭터가(여기서는 number sign)이 선택사항(있어도 되고 없어도 되는)임을 의미합니다. 그 다음에 나오는 그룹(괄호 안에 있는)에서 2가지 경우를 가질 수 있습니다. 첫번째는 a와 f사이의 소문자나 숫자가 6번나오는 것입니다. 세로바(|)는 3개의 a와 f사이의 소문자나 숫자가 대신 나올수도 있음을 으미합니다. 마지막으로 문자열의 끝을 의미하는 $가 위치합니다.
6개의 문자열을 앞에 둔 이유는 #ffffff같은 Hex값을 파서가 잡아내도록 하기 위한 것으로 반대로 3개의 문자열 검사를 앞에 두었다면 파서는 뒤의 3개의 f는 빼로 오직 #fff만을 잡아냈을 것입니다.
Match되는 스트링 : #a3c113
Match되지 않는 문자열 : #4d82h4 (h 가 포함되어 있음)
Matching a Slug
C-like
1 2 | // Pattern /^[a-z0-9-]+$/ |
mod_rewrite나 pretty URL을 사용해 본적이 있다면 이 정규표현식을 사용하게 될 것입니다. 시작 문자열인 ^가 처음에 나오고 뒤이어 소문자, 숫자, 하이픈(-)이 한개 또는 한개이상(+기호)나오고 마지막으로 문자열의 끝인 $가 나옵니다.
Match되는 스트링 : my-title-here
Match되지 않는 문자열 : my_title_here (언더스코어( _ ) 가 포함되어 있음)
Matching an Email
C-like
1 2 3 | // Pattern /^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/ |
문자열의 시작인 ^로 시작하고 첫번째 그룹(괄호 안)에서 1개 또는 그 이상의 소문자, 숫자, 언더스코어( _ ), 점(.), 하이픈(-)가 나옵니다. escape하지 않은 점(.)은 다른 문자를 의미하기 때문에 점(.)은 이스케이프 해줍니다.(\.) 그 뒤에 앳 기호(@)가 나오고 그 다음 1개또는 그 이상의 소문자, 숫자, 언더스코어( _ ), 점(.), 하이픈(-)으로 구성된 도메인명이 옵고 그 후 점(이스케이프된)이 소문자와 점으로 된 2~6개의 문자열이 옵니다. 2~6개로 한 이유는 .co.kr이나 .ny.us같은 국가 TLD(Top-Level-Domain)때문이며 마지막으로 문자열의 끝($)인 옵니다.
Match되는 스트링 : john@doe.com
Match되지 않는 문자열 : john@doe.something (TLS가 너무 김)
Matching a URL
C-like
이 정규표현식은 위에 나온 정규표현식의 최종본이라고 할 수 있습니다.
첫번째 그룹은 모두 옵션인데 이것은 URL이 "http://"나 "https://" 또는 둘다 없이 시작하도록 한다. s뒤에 물음표(?)는 URL이 http와 https를 모두 허용한다. 이 그룹전체를 선택사항으로 하기 위해서 뒤에 물음표(?)를 추가했습니다.
다음은 도메인명으로 한개이상의 숫자, 문자열, 점(.), 하이픈(-)뒤에 또다른 점(.)이 오고 그 뒤에 2~6개의 문자와 점이 옵니다. 이어지는 부분을 추가적인 파일과 디텍토리에 대한 부분으로 이 그룹에서는 갯수에 관계없이 슬래쉬(/), 문자, 숫자, 언더스코어(_), 스페이스, 점(.), 하이픈(-)이 나올 수 있으며 이 그룹은 많은 수의 디렉토리와 파일과 매치됩니다. 물음표(?)대신 별표(*)를 사용한 것은 별표는 0 또는 1이 아닌 0 또는 1개이상을 의미하기 때문입니다. 만약 물음표(?)를 사용했다면 오직 한개의 파일/디렉토리만 매치될 수 있었을 것입니다.
그 뒤에 슬래시(/) 매치되지만 이것은 선택사항이며 마지막으로 문자열의 끝($)이 나타납니다.
Match되는 스트링 : http://net.tutsplus.com/about
Match되지 않는 문자열 : http://google.com/some/file!.html (느낌표가 포함되어 있음)
Matching an IP Address
1 2 | // Pattern /^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w_\.-]*)*\/?$/ |
이 정규표현식은 위에 나온 정규표현식의 최종본이라고 할 수 있습니다.
첫번째 그룹은 모두 옵션인데 이것은 URL이 "http://"나 "https://" 또는 둘다 없이 시작하도록 한다. s뒤에 물음표(?)는 URL이 http와 https를 모두 허용한다. 이 그룹전체를 선택사항으로 하기 위해서 뒤에 물음표(?)를 추가했습니다.
다음은 도메인명으로 한개이상의 숫자, 문자열, 점(.), 하이픈(-)뒤에 또다른 점(.)이 오고 그 뒤에 2~6개의 문자와 점이 옵니다. 이어지는 부분을 추가적인 파일과 디텍토리에 대한 부분으로 이 그룹에서는 갯수에 관계없이 슬래쉬(/), 문자, 숫자, 언더스코어(_), 스페이스, 점(.), 하이픈(-)이 나올 수 있으며 이 그룹은 많은 수의 디렉토리와 파일과 매치됩니다. 물음표(?)대신 별표(*)를 사용한 것은 별표는 0 또는 1이 아닌 0 또는 1개이상을 의미하기 때문입니다. 만약 물음표(?)를 사용했다면 오직 한개의 파일/디렉토리만 매치될 수 있었을 것입니다.
그 뒤에 슬래시(/) 매치되지만 이것은 선택사항이며 마지막으로 문자열의 끝($)이 나타납니다.
Match되는 스트링 : http://net.tutsplus.com/about
Match되지 않는 문자열 : http://google.com/some/file!.html (느낌표가 포함되어 있음)
Matching an IP Address
C-like
자, 저는 거짓말을 하지 않습니다. 이 정규표현식은 제가(Vasili) 작성하지 않았고 이곳에서 가져왔습니다.
정규식이 첫번째로 잡아낸 그룹은 실제로 매치된(captured)된 그룹이 아닙니다. 왜냐하면 ?: 가 그안에 위치하고 있기 때문입니다. ?:는 파서가 이 그룹을 잡아내지 않도록 합니다. 또한 이 잡히지 않는 그룹은 3번 반복되기를 원합니다.(그룹의 끝에 {3}) 이 그룹은 또다른 서브그룹과 점(.)을 담고 있고 파서는 점(.)이 뒤에 있는 서브그룹을 매치하려고 찾습니다.
서브그룹은 또다른 잡히지 않는(non-captured) 그룹입니다. 이것은 0~5가 뒤에 오는 "25"거나 0~4와 모든 숫자가 뒤에 오는 "2"이거나 옵션이 0 또는 2개의 숫자가 이어지는 숫자들의 문자셋의 묶음입니다.
이 3가지가 매치된 이후에 다음 캡쳐되지 않는 그룹으로 들어갑니다. 이것은 0~5가 이어지는 "25" 또는 0~4와 함께 오는 "2" 그리고 마지막에 다른 숫자(0이나 두자리 숫자)가 옵니다.
마지막 문자($)와 함께 이 복잡한 정규표현식이 끝납니다.
Match되는 스트링 : 73.60.124.136
Match되지 않는 문자열 : 256.60.124.136 (첫번째 숫자는 250~255이어야 함)
Matching an HTML Tag
1 2 3 | // Pattern /^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/ |
자, 저는 거짓말을 하지 않습니다. 이 정규표현식은 제가(Vasili) 작성하지 않았고 이곳에서 가져왔습니다.
정규식이 첫번째로 잡아낸 그룹은 실제로 매치된(captured)된 그룹이 아닙니다. 왜냐하면 ?: 가 그안에 위치하고 있기 때문입니다. ?:는 파서가 이 그룹을 잡아내지 않도록 합니다. 또한 이 잡히지 않는 그룹은 3번 반복되기를 원합니다.(그룹의 끝에 {3}) 이 그룹은 또다른 서브그룹과 점(.)을 담고 있고 파서는 점(.)이 뒤에 있는 서브그룹을 매치하려고 찾습니다.
서브그룹은 또다른 잡히지 않는(non-captured) 그룹입니다. 이것은 0~5가 뒤에 오는 "25"거나 0~4와 모든 숫자가 뒤에 오는 "2"이거나 옵션이 0 또는 2개의 숫자가 이어지는 숫자들의 문자셋의 묶음입니다.
이 3가지가 매치된 이후에 다음 캡쳐되지 않는 그룹으로 들어갑니다. 이것은 0~5가 이어지는 "25" 또는 0~4와 함께 오는 "2" 그리고 마지막에 다른 숫자(0이나 두자리 숫자)가 옵니다.
마지막 문자($)와 함께 이 복잡한 정규표현식이 끝납니다.
Match되는 스트링 : 73.60.124.136
Match되지 않는 문자열 : 256.60.124.136 (첫번째 숫자는 250~255이어야 함)
Matching an HTML Tag
C-like
이 포스팅에서 가장 유용한 정규표현식 중의 하나입니다. 이것은 어떤 HTML태그도 매치할 수 있고 일반적으로 라인의 첫번째에서 시작합니다.
첫번째로 오는 것은 태그이름입니다. 이것은 반드시 한개이상의 문자가 되어야 하며 첫번째로 잡히는 그룹이기도 합니다. 이것은 닫는태그를 잡았을 때 찾아야 할 값입니다. 다음에는 태그의 속성입니다. 이것은 >를 제외한 어떤 문자도 올 수 있습니다. 옵션사항이지만 1개이상의 캐릭터와 매치되기를 원하기 때문에 별표가 사용되었습니다. 플러스기호는 속성과 값을 이루고 별표는 원하는 만큼의 속성(attribute)가 매치될 수 있도록 합니다.
다음으로 세번째 non-capture그룹이 오는데 내부에 >기호가 담길 것이고 컨텐츠부분과 닫는태그가 있습니다.(공백과 슬래시(/), > 기호) 첫옵션은 문자들에 이어지는 >기호를 찾습니다. \1은 캡쳐된 첫번째 그룹에서의 내용을 표현하는데 사용됩니다. 이 경우에는 태그의 이름이 됩니다. 이제 태그이름이 매치되지 않으면 자신의 닫는태그를 찾기를 원합니다. 이것은 "/>"가 이어지는 한개이상의 공백이 필요합니다.
Match되는 스트링 : <a href="http://net.tutsplus.com/">Nettuts+</a>
Match되지 않는 문자열 : <img src="img.jpg" alt="My image>" /> (속성은 >기호를 가질 수 없음)
내용은 아주 좋은데 급하게 작성했더니 번역이 영 그렇네요. 원문가서 보시길....(은근슬쩍 급하게 해서 번역이 이런 척... ㄷㄷㄷ)
1 2 | // Pattern /^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$/ |
이 포스팅에서 가장 유용한 정규표현식 중의 하나입니다. 이것은 어떤 HTML태그도 매치할 수 있고 일반적으로 라인의 첫번째에서 시작합니다.
첫번째로 오는 것은 태그이름입니다. 이것은 반드시 한개이상의 문자가 되어야 하며 첫번째로 잡히는 그룹이기도 합니다. 이것은 닫는태그를 잡았을 때 찾아야 할 값입니다. 다음에는 태그의 속성입니다. 이것은 >를 제외한 어떤 문자도 올 수 있습니다. 옵션사항이지만 1개이상의 캐릭터와 매치되기를 원하기 때문에 별표가 사용되었습니다. 플러스기호는 속성과 값을 이루고 별표는 원하는 만큼의 속성(attribute)가 매치될 수 있도록 합니다.
다음으로 세번째 non-capture그룹이 오는데 내부에 >기호가 담길 것이고 컨텐츠부분과 닫는태그가 있습니다.(공백과 슬래시(/), > 기호) 첫옵션은 문자들에 이어지는 >기호를 찾습니다. \1은 캡쳐된 첫번째 그룹에서의 내용을 표현하는데 사용됩니다. 이 경우에는 태그의 이름이 됩니다. 이제 태그이름이 매치되지 않으면 자신의 닫는태그를 찾기를 원합니다. 이것은 "/>"가 이어지는 한개이상의 공백이 필요합니다.
Match되는 스트링 : <a href="http://net.tutsplus.com/">Nettuts+</a>
Match되지 않는 문자열 : <img src="img.jpg" alt="My image>" /> (속성은 >기호를 가질 수 없음)
내용은 아주 좋은데 급하게 작성했더니 번역이 영 그렇네요. 원문가서 보시길....(은근슬쩍 급하게 해서 번역이 이런 척... ㄷㄷㄷ)
[JS]prototype.js의 엘리먼트(Element) 다루기(insert, update, remove)..
출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
항상 뭘하다보면 자기 중심적으로 생각하게 되는것 같습니다. 상대방의 입장에서 생각해야 되는데 그게 쉽지 않습니다. 더군다나 웹에서는 상대방(?)의 대한 정보가 보통은 전무한 편이라서 더 자기중심적으로 생각하게 되는 경우가 많죠.
초창기에 개발에 대해 전혀 모를때 인터넷에 있는 많은 정보들을 볼 때 가장 답답한 부분중 하나가 설명하는 사람이 당연히 내가 알꺼라고 생각하고 그냥 넘어가는 부분을 정작 나는 몰라서 그사람의 설명이나 소스까지 도달하기도 어려웠다는 것이지요. 머 그렇다고 항상 모든 것을 다 설명한다는 것도 어렵겠지만 블로그에서는 최대한 자세하게 쓰려고 하고 있기는 하지만 좀 초심을 잃어버린 생각이 들었습니다. 그리고 새로 알게된걸 항상 포스팅으로 하게되지는 않고 그러다 보면 포스팅타이밍을 놓쳐버린 것들도 많죠.
쿡이님의 질문을 받으면서 생각난 김에 JS로 엘리먼트를 다룰때 가장 많이 사용할 추가, 삭제에서 prototype.js가 지원하는 부분에 대해서 다시 한번 정리합니다.
prototype.js에는 Element 클래스가 있습니다. HTML의 DIV, INPUT, LI같은 엘리먼트에 관련된 클래스입니다. Element의 API문서를 보면Element클래스가 지원하는 많은 메서드를 볼 수 있습니다. 엘리먼트와 관련된 속성에 대한 것이라든지, 추가, 삭제, 생성등등의 기능을 지원하고 있습니다.
일반적인 방법
일반적으로는 innerHTML을 이용하는 것이 간단하면서도 편하기 때문에 많이 사용합니다.
사실 설명할 내용도 없긴 하지만 innerHTML은 이름 그대로 해당 엘리먼트의 안에 있는 HTML을 의미하고 있습니다. 내부 HTML을 새로지정하면 새로 지정하는 내용으로 replace가 됩니다. 기본의 innerHTML값과 새로추가할 HTML스트링을 문자열로 이어붙혀서 다시 innerHTML으로 할당해서 HTML의 구조를 동적으로 바꾸는 것입니다. js를 실행하면 HTML이 아래와 같은 모습이 됩니다.
같은 기능을 DOM으로 구현한 것입니다. 엘리먼트 만들고 속성추가하고 TextNode만들어서 A엘리먼트 안에 넣은 다음에 추가한 것입니다. 메서드로 다양하게 다룰 수 있기는 하지만 저 간단한 소스도 소스로는 꽤 복잡하게 작성되고 있고 한눈에 어떻게 동작할 것인지를 파악하기가 쉽지 않고 복잡한 HTML의 경우에는 훨씬 복잡하게 됩니다. innerHTML에 비해서 특정엘리먼트만 지우는 remove관련 메서드도 지원하고 있기는 하지만 브라우져의 따라 DOM Level 1/2의 지원차이가 있습니다.
DOM은 Dom Test Pages에서 지원여부를 테스트해 볼 수 있고 PPK의 W3C DOM Compatibility에서 브라우져별 차이를 파악할 수 있습니다.
prototype.js 이용하기
당연히 prototype.js를 로드해야하고 그 후에 다음과 같이 사용하면 됩니다.
너무 간단한 코드라서 그냥 한 코드블럭에 다 썼습니다. 첫줄 insert만으로 위에서 설명했던 기능과 동일한 기능을 합니다. update는 replace의 기능을 합니다. 2번째 줄을 실행하면 Div안에 link2만 존재하게 되겠고 remove를 실행하면 testDivision DIV자체가 삭제되어버립니다. 간단한 기능만 소개했지만 그외에도 Element관련 다양한 기능을 제공하고 있습니다. prototype.js내부적으로 크로스 브라우징을 지원하기 때문에 브라우저호환에 대해서 큰 걱정없이 사용할 수 있습니다.
추가적으로 좀 더 세밀하게 컨트롤 할 수 있는 기능을 제공하고 있습니다.
위 코드처럼 JSON형태로 사용해서 insert되는 위치를 지정해 줄 수 있습니다. 사용할 수 있는 position값은 top, bottom, before, after입니다. 이걸 이용하면 쉽게 원하는 위치에 엘리먼트의 삽입/삭제가 가능합니다.
좀 복잡한 HTML의 경우에는 script.aculo.us의 Builder을 사용하는 것도 괜찮은 방법 같습니다.
항상 뭘하다보면 자기 중심적으로 생각하게 되는것 같습니다. 상대방의 입장에서 생각해야 되는데 그게 쉽지 않습니다. 더군다나 웹에서는 상대방(?)의 대한 정보가 보통은 전무한 편이라서 더 자기중심적으로 생각하게 되는 경우가 많죠.
초창기에 개발에 대해 전혀 모를때 인터넷에 있는 많은 정보들을 볼 때 가장 답답한 부분중 하나가 설명하는 사람이 당연히 내가 알꺼라고 생각하고 그냥 넘어가는 부분을 정작 나는 몰라서 그사람의 설명이나 소스까지 도달하기도 어려웠다는 것이지요. 머 그렇다고 항상 모든 것을 다 설명한다는 것도 어렵겠지만 블로그에서는 최대한 자세하게 쓰려고 하고 있기는 하지만 좀 초심을 잃어버린 생각이 들었습니다. 그리고 새로 알게된걸 항상 포스팅으로 하게되지는 않고 그러다 보면 포스팅타이밍을 놓쳐버린 것들도 많죠.
쿡이님의 질문을 받으면서 생각난 김에 JS로 엘리먼트를 다룰때 가장 많이 사용할 추가, 삭제에서 prototype.js가 지원하는 부분에 대해서 다시 한번 정리합니다.
prototype.js에는 Element 클래스가 있습니다. HTML의 DIV, INPUT, LI같은 엘리먼트에 관련된 클래스입니다. Element의 API문서를 보면Element클래스가 지원하는 많은 메서드를 볼 수 있습니다. 엘리먼트와 관련된 속성에 대한 것이라든지, 추가, 삭제, 생성등등의 기능을 지원하고 있습니다.
일반적인 방법
1 2 3 | <div id="testDivision" name="testDivision"> <a href="#">Link 1</a> </div> |
간단한 HTML을 가지고 보겠습니다. 엘리먼트를 핸들링할때 JS에서 제공하는 2가지방법이 있습니다. innerHTML을 이용하는 방법과 DOM을 이용하는 방법입니다.일반적으로는 innerHTML을 이용하는 것이 간단하면서도 편하기 때문에 많이 사용합니다.
1 2 3 | var htmlStr = "<a href='#'>Link 2</a>"; var obj = document.getElementById("testDivision"); obj.innerHTML = obj.innerHTML + htmlStr; |
사실 설명할 내용도 없긴 하지만 innerHTML은 이름 그대로 해당 엘리먼트의 안에 있는 HTML을 의미하고 있습니다. 내부 HTML을 새로지정하면 새로 지정하는 내용으로 replace가 됩니다. 기본의 innerHTML값과 새로추가할 HTML스트링을 문자열로 이어붙혀서 다시 innerHTML으로 할당해서 HTML의 구조를 동적으로 바꾸는 것입니다. js를 실행하면 HTML이 아래와 같은 모습이 됩니다.
1 2 3 4 | <div id="testDivision" name="testDivision"> <a href="#">Link 1</a> <a href="#">Link 2</a> </div> |
두번째 방법은 DOM입니다. DOM은 Document Object Model의 약자로 표준이 정해져 있고 대부분의 브라우저가 지원하고 있습니다. 엘리먼트를 추가/삭제같은 DOM Level 2에 정의가 되어 있습니다.(DOM Level 1에서 추가확장되어 현재는 대부분 Level 2를 지원하고 있는 것으로 알고 있습니다.) 이름대로 DOM을 다루기 위해서 만들어진 것이기 때문에 다양한 메서드를 제공하고 있고 좀 더 세련된 느낌의 사용법을 가지고 있습니다.1 2 3 4 | var elem = document.createElement("a") elem.setAttribute("href", "#"); elem.appendChild(document.createTextNode("Link 2")); document.getElementById("testDivision").appendChild(elem); |
같은 기능을 DOM으로 구현한 것입니다. 엘리먼트 만들고 속성추가하고 TextNode만들어서 A엘리먼트 안에 넣은 다음에 추가한 것입니다. 메서드로 다양하게 다룰 수 있기는 하지만 저 간단한 소스도 소스로는 꽤 복잡하게 작성되고 있고 한눈에 어떻게 동작할 것인지를 파악하기가 쉽지 않고 복잡한 HTML의 경우에는 훨씬 복잡하게 됩니다. innerHTML에 비해서 특정엘리먼트만 지우는 remove관련 메서드도 지원하고 있기는 하지만 브라우져의 따라 DOM Level 1/2의 지원차이가 있습니다.
DOM은 Dom Test Pages에서 지원여부를 테스트해 볼 수 있고 PPK의 W3C DOM Compatibility에서 브라우져별 차이를 파악할 수 있습니다.
prototype.js 이용하기
당연히 prototype.js를 로드해야하고 그 후에 다음과 같이 사용하면 됩니다.
1 2 3 | $("testDivision").insert("<a href='#'>Link 2</a>"); $("testDivision").update("<a href='#'>Link 2</a>"); $("testDivision").remove(); |
너무 간단한 코드라서 그냥 한 코드블럭에 다 썼습니다. 첫줄 insert만으로 위에서 설명했던 기능과 동일한 기능을 합니다. update는 replace의 기능을 합니다. 2번째 줄을 실행하면 Div안에 link2만 존재하게 되겠고 remove를 실행하면 testDivision DIV자체가 삭제되어버립니다. 간단한 기능만 소개했지만 그외에도 Element관련 다양한 기능을 제공하고 있습니다. prototype.js내부적으로 크로스 브라우징을 지원하기 때문에 브라우저호환에 대해서 큰 걱정없이 사용할 수 있습니다.
추가적으로 좀 더 세밀하게 컨트롤 할 수 있는 기능을 제공하고 있습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | $("testDivision").insert({top:"<a href='#'>Link 2</a>"}); // 결과 // <div id="testDivision" name="testDivision"> // <a href="#">Link 2</a><a href="#">Link 1</a> // </div> $("testDivision").insert({bottom:"<a href='#'>Link 2</a>"}); // 결과 // <div id="testDivision" name="testDivision"> // <a href="#">Link 1</a><a href="#">Link 2</a> // </div> $("testDivision").insert({before:"<a href='#'>Link 2</a>"}); // 결과 // <a href="#">Link 2</a> // <div id="testDivision" name="testDivision"> // <a href="#">Link 1</a> // </div> $("testDivision").insert({after:"<a href='#'>Link 2</a>"}); // 결과 // <div id="testDivision" name="testDivision"> // <a href="#">Link 1</a> // </div> // <a href="#">Link 2</a> |
위 코드처럼 JSON형태로 사용해서 insert되는 위치를 지정해 줄 수 있습니다. 사용할 수 있는 position값은 top, bottom, before, after입니다. 이걸 이용하면 쉽게 원하는 위치에 엘리먼트의 삽입/삭제가 가능합니다.
좀 복잡한 HTML의 경우에는 script.aculo.us의 Builder을 사용하는 것도 괜찮은 방법 같습니다.
피드 구독하기:
글 (Atom)