« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : Next »
http://insightbook.springnote.com/pages/1717332


지은이 : 켄 슈와버(Ken Schwaber), 마이크 비들(Mike Beedle) / 옮긴이 : 박일, 김기웅
정가 : 18,000원

260쪽 / 판형 : A5 / 1판
출간일 : 2008년 10월 6일
ISBN-13 : 978-89-91268-47-0


책소개
스크럼의 대부인 켄 슈와버가 쓴 <<스크럼>>은 소프트웨어 시스템 개발 프로젝트에서 기술과 프로세스를 관리/운영하는 실천 방법 중 높은 생산성을 검증받은 스크럼의 기본적인 이론들을 소개하고 있습니다. 특히, 어떻게 스크럼 팀을 조직하여 일일 스크럼 회의와 스크럼 프로젝트 계획을 하는지와 스크럼을 이용한 백로그 추적과 프로젝트 완료 등을 어떻게 해야 하는지 등에 관한 스크럼의 실천법이 저자들의 20년간의 다양한 경험 사례를 통해 이해할 수 있게 설명되어 있습니다.



“스크럼은 다르다”

애자일 소프트웨어 개발 방법론이 유연한 소프트웨어 시스템의 미래를 여는 열쇠라고 말한다면, 스크럼은 급변하는 비즈니스 환경에서 소프트웨어 개발과 관리를 가장 효과적으로 해내는 전위대라고 말할 수 있을 것입니다. 이 책에는 기존의 것들을 단순히 우려먹는 그렇고 그런 방법론이 아니라 수십 년 간의 경험을 통해 얻은 저자들의 철학과 이론, 그리고 실천법들이 다양하고 심층적인 사례와 함께 온전히 담겨 있습니다.



“스크럼은 불편하다”

스크럼은 외견상 간단하게 보이는 방법론이지만 우아한 기술과 헌신적인 실천을 요구합니다. 그러니 적용하자마자 잠재되어 있는 문제점들이 폭로되어 이러저러하게 조직의 쓴맛을 보게 됩니다. 그래서 스크럼은 불편합니다. 허나 성공하는 프로젝트를 만끽하려면 넘어야 할 산입니다. 신뢰와 헌신, 믿음과 용기, 개방과 공유라는 스크럼의 가치를 통해 그 ‘불편’을 돌파해 보십시오.



“스크럼은 통한다”

소프트웨어 개발은 항상 새로운 제품을 만드는 창조적인 행위입니다. 이러한 새로운 제품을 개발하는 과정에서 넓고 깊은 연구와 창발적인 활동은 두말하면 잔소리죠. 그러려면 새로운 지식을 창출하고 스스로 자기 조직화를 잘 할 수 있는 관점과 실천이 필요합니다. 스크럼은 소프트웨어 개발의 패러다임을 바꾸는 새로운 세계관을 보여줍니다. 이 책에서 스크럼의 세계관을 투영한 소프트웨어 개발의 다양한 관점을 - 시스템 역학적, 인류학적, 복잡계 과학적, 정신분석적, 패러다임 전환적 관점 등 - 확인하십시오. 왜 스크럼은 통하는지 바로 알아챌 것입니다.

그밖에 이 책을 통해 스크럼을 바로 사용할 수 있는데 그 덤으로 이런 것을 얻습니다.



1. 기존에 실행되고 있는 엔지니어링 실천방법과는 상관없이 소프트웨어 개발에 스크럼을 바로 적용시킬 수 있다.

2. 애자일 프로세스의 이론의 기본적 맥락을 이해할 수 있다.

3. 왜 애자일 프로세스를 사용해야 하는지 알 수 있다.

4. 애자일 프로세스를 어떻게 구현하고 관리하는지 알 수 있다.

5. 스크럼 래퍼를 통해서 익스트림 프로그래밍과 공명할 수 있다.


크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/02/12 16:14 2009/02/12 16:14
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3994

네이버 API - http://dev.naver.com/

네이버 API - http://dev.naver.com/

: OpenAPI 제공.



http://dev.naver.com/nforge

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/02/10 11:07 2009/02/10 11:07
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3979

날마다 새로워진다면 우리는 얼마나 발전할 수 있을까?
끊임없이 노력하면 어느 순간 한단계 발전한다는 점은 불변의 진리다.
내가 닮고 싶어하는 사람들은 하나같이 지독하다 싶을 정도로 끊임없이 노력한다.
꾸준히 노력하기 위해서는 구체적인 목표를 세우고 매일 실천하는 것이 중요하다.

하나, 일신우일신(日新又日新)하기 위해 구체적으로 꾸준히 하는 것을 만들어라.
- 날마다 새로워지려면.

둘, 살아남기 위해 새로운 일에 도전하라.

셋, 분명한 가치관을 가지기 위해 글을 써라.

넷, 주변에서 스승을 찾자.

다섯, 애정을 가지거나 좋아하는 일을 찾자.

여섯, 긍정적으로 말하고 행동하라.


* 균형잡힌 사고와 발언을 위한 지침

* 스승을 찾는 법

* 애자일 프랙티스 가이드라인
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/02/10 11:01 2009/02/10 11:01
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3978

균형잡힌 사고와 발언을 위한 지침 - http://younghoe.info/232

최근 들어 대립하지 않으려는 의지는 균형감을 자꾸 생각하게 한다.
합리적인 판단과 조화로운 결정 사이에는 많이 차이기 있지만
여기서 그것에 대해 긴 이야기를 늘어놓고 싶지는 않다.


최근 몇 차례 한 가지 기술적 이슈에 대해 자문 요청을 받았다.
자문을 할 수록 내가 정말 하고 싶은 말은
'나는 A라는 툴을 싫어한다.'에 가깝다는 것을 알았다.
(물론, 최대한 완곡하게 이야기 하면서, 내면에서는 그렇게 말하려는 욕구를 달래고 있다.)


기술과 툴 자체에 대해 공부하는 위치에 서면
스스로 세운 어떤 기준에 부합하지 못하는 기술/툴에 대해서는 비판적이 될 수 밖에 없다.
그것이 나를 위한 항변이지만...

반대 편으로 돌아서보자.
A가 아니라면 대체할 수 있는 뭔가가 있어야 한다.
사실 A에 완전한 비교 우위를 점하는 어떤 툴을 써보지 않은 이상
다른 어떤 툴도 지지하기는 힘들다.


또한, A라는 툴을 공급하는 업체와 그 직원들까지 생각하면 더 신중하게 발언해야 하기에
섣불리 A가 나쁘다라고 말할 수도 없다.


이런 류의 자문은 대개 급작스러운 순간에 구두로 물어오는 경우가 많아
말을 하면서 판단도 해야 한다.


여기서 최선 안은 무엇일까?


몇 차례 이런 경우를 겪으면서 내가 도출한 몇 가지는 아래와 같다.


1. 직접 해보지 않은 단순한 느낌이나 어디선가 들은 얘기는 언급하지 않는다.
모호한 지식을 풀어놓다 보면 스스로의 선호가 개입되기 쉽고
자칫 별 근거도 없는 주관적인 의견을 내놓을 수 있다.


2. 가능한 구체적으로 언급한다.
자문을 받는 의뢰인은 몰라서 묻는 것이다. 따라서, 오해의 소지가 존재한다.
구체적일수록 오해의 폭은 작고
추상적일수록 오해의 폭은 크다.


3. 차분하게 발언의 폭을 조절하여 리듬을 유지하라.
혹시 상대가 조급하여 질문 공세를 하게 되면
호흡 조절없이 정신없이 답변할 수 있다.
이렇게 되면 여유를 잃어 충분히 생각하면서 발언할 기회를 놓친다.
답변 와중에 한번 쯤 웃을 수 있는 여유를 갖을 수 있다면
분명 더 진솔한 답을 낼 수 있다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/02/04 18:07 2009/02/04 18:07
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3959

스승을 찾는 방법 [펌]

스승을 찾는 방법 - http://younghoe.info/219
스승을 찾는 방법 2nd Edition - http://younghoe.info/599

스승을 찾는 방법

가끔 사람들은 이렇게 묻곤 한다.
'그런 것들은 누구한테 배웠어요?'

누구한테 배웠는지 확실하지 않다.
보고 배운 것이라고 해도
경험을 통해 내 것으로 만들기 전에는 '배운 것'이라고 할 수 없다.
그것은 마치 수학 공식을 다 외워도 문제를 풀지 못하는 것과 같은 이치다.

예전에는 나의 식견을 훨씬 뛰어넘는 사람에게 배움을 얻게 되면
입에 침이 마르도록 그를 칭송했다.
그 즈음에는 내 것으로 만든 것은 아무 것도 없었다.
결국 배운 것이 없었다. 마치 TV의 등장 인물 대하듯... 주변의 스승을 대한 것이다.

최근에 쭉쭉빵빵 여자분 외에 뵙고 싶은 분이 있다. ^^
모처에서 프로젝트를 진행할 때
본인의 사고 틀에 맞춰서 작업을 하게 하여
주변 사람들에게 고통을 맛보게 한 분이다.
당시 회식 뒷풀이나 티타임/흡연시간에 단연 화제의 주인공으로 회자되던 분인데...

나는 그 분을 통해서 많이 성장했다.

만일 주변에 멘토가 없다고 아쉬워하는 분이 있다면
다시 한번 둘러보라고 얘기해주고 싶다.

스티브 잡스만이 인생의 스승이 되는 것은 아니다.
노력하면 스승을 찾는 법을 체득할 수 있다. :)

스승을 찾는 방법 2nd Edition

스승을 찾는 방법이라는 글을 쓴 적이 있다. 벌써 9개월 전의 글이다.
요즘 일터에서 또 한 사람의 스승을 만난다. (사실 여러 사람의 스승이 존재하는데 그 중에 개인적인 취향으로 한 사람을 지정하고 싶은 것이지도 모른다.)

스승의 사전적 정의가 어떤지 모르지만, 자신의 성장에 도움을 주는 사람을 스승이라고 봤을 때, 흥미롭게도 다수의 스승은 '스승'이라는 이름을 갖고 등장하지 않는다.('선생'이나 '교수'를 포함해서...)

돌아보면 내 인생에 등장한 인물 중에서 스승이라는 역할에 가장 어울리는 사람들은 선생이나 교수는 아니다. 그 인물의 모든 모습이 스승이 아니라 어떤 특징이 스승 역할을 했다.(신을 만난 것이 아닌 이상 당연한 것이리라.)

얘기가 거창해져 버렸다. 원래는 요즘 스승 역할을 해주는 특정 인물에 대해 쓰고자함이었다. 그런데 예전에 써둔 글이 생각 나서 연장선으로 정리한다.

그 분에 최근에 많은 것을 전수해주셨는데 그것을 간단히 정리해두고 싶다.
1. 자연원리에 입각한 사고, 그리고 실천
2. 지속적인 프로세스 개선(생활화)
3. 단시간에 특정 목적에만 초점을 맞춘 실행

또한, 두 가지 중요한 개념에 대해 메모해둬서 향후에 누군가와 함께 논의할 여지를 만들어둔다.
1. MECE
2. FFF

애초에 하고자 한 이야기는 위 두 단란이다.

그리고, 이왕 연작으로 글을 썼으니 결론을 지어보자. 지금 막 떠오르는 스승 진선미(?)를 두고 생각해보면 다음과 같은 공통점을 발견할 수 있다.
첫번째는 스승은 어김없이 내가 준비가 되어 있을 때 나타났고(스승을 만나려고 준비한 것은 아니다)
두번째는 그들(혹은 그들이 가진 스승으로써의 특징)은 감탄할만한 일관성을 지니고 있다는 점이다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/02/04 17:59 2009/02/04 17:59
Response
No Trackback , a comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3958

애자일 프랙티스 가이드라인

참고 : http://insightbook.springnote.com/pages/411012


『애자일 프랙티스: 빠르고 유연한, 개발자의 실천 가이드』의 가이드라인을 요약 자료.



비난은 버그를 수정하지 못한다.

손가락질 하는 대신, 가능한 해결책을 제시하라. 중요한 것은 긍정적인 결과다.



땜질식 수정에 빠지지 말라.

깔끔하고 모든 것이 드러나도록 코드에 정력을 쏟아라.



사람이 아니라 아이디어를 비평하라.

누구 아이디어가 더 나은지를 입증하는 것이 아니라 해결책에 도달하는데 자부심을 가져라.



올바른 일을 하라.

정직하라. 그리고 진실을 얘기할 용기를 가져라. 때로 이렇게 한다는 것이 어려울 수도 있지만, 그렇기 때문에 용기가 필요한 것이다.



기술 변화를 따라 가라.

모든 분야에서 전문가가 될 필요는 없지만, 업계가 어디로 가는지 알고 있어야 하고, 그에 맞춰서 경력과 프로젝트 계획을 세워야 한다.



여러분 자신과 팀에 대한 기대치를 높여라.

도시락 회의를 통하여 모든 사람의 지식과 숙련도를 올리고 사람들이 화합하게 하자. 즉, 팀이 흥미를 보이는 기술이나 프로젝트를 이롭게 할 기술을 도입하자.



새로운 기술을 배우고 예전 기술은 버려라.

새 기술을 배울 때, 여러분을 방해할 낡은 습관을 버려라. 결국 구형 차보다는 새 차가 훨씬 낫다.



계속 왜냐고 물어보라.

여러분이 들은 얘기들을 액면 그대로 받아들이지 마라. 쟁점이 되는 내용의 핵심을 이해할 때까지 계속 질문하라.



일이 쌓이기 전에 부딪쳐라.

사건들 사이에 꾸준하고 반복적인 간격을 유지해야 일상적으로 되풀이되는 일을 해결하기 쉽다.



고객이 결정하도록 하라.

개발자, 관리자, 비즈니스 애널리스트가 비즈니스에 치명적인 결정을 내려서는 안 된다. 사업주가 이해할 수 있는 언어로 세부 내용을 설명하고 사업주가 결정하도록 하라.



좋은 설계는 지도다. 스스로 진화하게 하자.

설계는 바른 방향으로 인도한다. 그것은 허물 수 없는 경계가 아니다. 특정한 방식을 강요해서는 안 된다. 여러분이 설계(혹은 설계자)에게 인질로 잡혀서는 안 된다.



필요에 따라 기술을 택하라.

먼저 무엇이 필요한지 정하라. 그러고 나서 그 특정한 문제에 기술 사용 여부를 판단하라. 어떤 기술의 사용에 결정적인 질문을 하고 진실하게 답해 보라.



프로젝트를 항상 릴리스 가능하게 하라.

프로젝트를 항상 컴파일할 수 있고, 실행할 수 있으며, 테스트하고 당장에 배치할 수 있게 하자.



일찍, 자주 통합하라.

코드 통합은 주요 위험 요인이다. 이 위험을 완화시키려면, 일찍 통합하고 규칙적으로 계속 통합해야 한다.



시작부터 애플리케이션을 자동 배치하라.

의존성 테스트를 위해 다양한 구성의 머신에 애플리케이션을 설치할 때, 이 자동 배치를 사용하라. 품질보증은 애플리케이션 뿐 아니라 배치를 테스트해야 한다.



분명히 보이게 개발하라.

애플리케이션이 개발 도중 항상 눈에 띄게 하고 고객의 마음에 들게 하라. 고객과 접촉하고 매 주 또는 2주에 한 번씩 데모를 사용하여 피드백을 미리 구하라.



점진적으로 개발하라.

최소의 유용한 기능 단위로 묶어서 제품을 릴리스하라. 각 추가기능의 개발에 1~4주 정도의 반복 주기를 사용하라.



실제 일을 기초로 해서 견적하라.

실질적인 견적을 내기 위해 팀이 현재 프로젝트를 고객과 함께 수행하도록 하라. 고객이 기능과 예산을 조절하도록 하라.



자동화된 단위테스트를 사용하라.

좋은 단위테스트는 문제를 즉시 경고한다. 견고한 단위테스트가 자리 잡지 않았다면 설계나 코드 변경을 하지 말자.



만들기 전에 사용하라.

테스트 주도 개발을 설계 툴로써 사용하자. 테스트 주도 개발은 여러분을 더 실용적이고 더 간단한 설계로 인도할 것이다.



차이는 다른 결과를 만든다.

지속적 통합 툴을 사용해서, 지원하는 플랫폼과 환경의 조합마다 단위테스트를 실행하자. 문제가 여러분을 부르기 전에 능동적으로 문제를 찾자.



핵심 비즈니스 로직에 해당하는 테스트를 만들자.

고객이 이러한 테스트를 격리해서 검증하게 하고, 일반적인 테스트 수행의 일부로 이러한 테스트를 자동적으로 시험하게 하자.



얼마나 많은 일이 남았는지 측정하라.

현실성이 떨어지는 측정 기준으로 자신이나 팀을 기만하지 말자. 해야 할 작업의 백로그를 측정하자.



모든 불평은 진실을 담고 있다.

진실을 찾아, 진짜 문제를 해결해라.



독창적이지 않고, 명확하게 코드를 작성하자.

코드를 읽는 사람에게 의도를 명확하게 표현하자. 읽기 쉽지 않은 코드는 독창적이지도 않다.



이야기하는 주석.

잘 고르고, 의미 있는 이름을 사용해서 코드를 문서화하라. 메서드의 목적과 제한 조건을 설명하는 주석을 사용하라. 좋은 코드를 대신하려고 주석을 사용하지 말자.



능동적으로 트레이드오프를 평가하자.

성능, 편의성, 생산성, 비용, 적시 릴리스를 고려하자. 성능이 적당하면, 다른 요소를 향상시키는데 집중하자. 하찮거나 미미한 성능이나 우아함을 위해서 디자인을 복잡하게 하지 말자.



짧은 수정/빌드/테스트 주기 안에서 코드를 작성하자.

긴 주기 동안 코딩을 하는 것보다 짧은 주기에서 코딩을 하는 편이 더 낫다. 유지보수하는데 더 명확하고 간단하며 쉬운 코드를 만들 것이다.



동작하는 가장 단순한 해결책을 만들자.

패턴, 원칙, 기술을 사용해야 하는 부득이한 사정이 있을 때만 패턴, 원칙, 기술을 포함하자.



클래스에 집중하고 컴포넌트를 작게 유지해라.

커다란 클래스나 컴포넌트 혹은 다방면에서 잡다한 클래스를 만들고픈 유혹을 피해라.



묻지 말고, 말해라.

다른 객체나, 컴포넌트의 일을 떠맡지 마라. 객체나 컴포넌트에 무엇을 하는지 알리고, 자신의 일에 충실해라.



코드를 교체해서 시스템을 확장하자.

인터페이스 계약을 존중하는 클래스를 교체해서 기능을 추가하거나 강화하자. 위임은 언제나 상속보다 바람직하다.



문제와 해결책의 로그를 보존하자.

문제를 해결하는 일의 일부는 나중에 해결책을 찾고 적용할 수 있도록 해결책의 상세 내용을 보존하는 것이다.



경고를 에러처럼 다루자.

경고가 있는 코드를 체크인 하는 것은 에러가 있는 코드나 테스트에 실패한 코드를 체크인하는 것만큼 나쁘다. 체크인한 코드는 빌드 툴에서 어떤 에러도 만들어서는 안 된다.



문제를 격리해서 공격하라.

문제를 해결할 때 문제를 주위와 분리시켜라. 특히 큰 애플리케이션의 경우에 말이다.



모든 예외를 처리하거나 전달하라.

예외를 덮어 두지 말자. 임시로라도 말이다. 코드가 실패할 수 있다고 생각하며 작성하자.



유용한 에러 메시지를 제공하자.

에러의 상세 내용을 알아내기 쉬운 방법을 제공하자. 문제가 생겼을 때 문제에 대해서 할 수 있는 한 많은 지원과 관련된 상세 정보를 제공하라. 그렇지만 이 정보와 함께 사용자를 파묻지는 말자.



스탠드 업 미팅을 사용하자.

스탠드 업 미팅은 팀을 같은 곳에 둔다. 회의를 열성적이면서 짧고, 집중적으로 유지하자.



좋은 디자인은 활동적인 프로그래머로부터 진화한다.

진짜 통찰력은 활동적인 코딩 작업에서 나온다. 코드를 작성하지 않는 아키텍트를 기용하지 말자. 시스템의 현실을 알지 못하는 아키텍트는 설계를 할 수 없다.



코드 공동 소유를 강조하자.

개발자들을 순환시켜 전체 시스템의 다른 영역에 있는 서로 다른 모듈이나 태스크를 교차해서 개발시키자.



멘토가 되자.

아는 것을 공유하는 데 즐거움이 있다. 얻은 만큼 베풀어라. 더 나은 목표를 달성하기 위해서 다른 사람을 자극하자. 팀의 전체적인 역량을 향상시키자.



다른 사람에게 문제를 해결할 기회를 주자.

다른 사람에게 해결책을 주는 대신에 올바른 방향을 알려주자. 그 과정에서 모두 뭔가를 배울 수 있다.



준비 되었을 때만 코드를 공유하라.

다른 사람이 쓸 수 있도록 준비되지 않은 코드는 절대 체크인하지 마라. 컴파일이 안 되었거나 단위테스트를 통과하지 못한 코드를 고의적으로 체크인


하는 것은 프로젝트의 범죄적인 태만 행위로 간주해야 한다.



모든 코드를 리뷰하자.

코드 리뷰는 코드 품질을 개선하고 에러를 낮추는데 매우 가치 있는 것이다. 코드 리뷰를 올바르게 했다면, 리뷰는 실용적이고 효과적일 수 있다. 다른 개발자로 하여금 작업이 끝날 때마다 코드 리뷰를 하게 하자.



다른 사람에게 계속해서 알리자.

여러분이 조사한 좋은 자료나 자신의 상황, 아이디어를 발표하자. 다른 사람이 일의 상황을 물을 때까지 기다리지 말자.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/01/29 11:52 2009/01/29 11:52
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3938

에디트플러스 - 세로 선택영역

Alt + C -> 드래그 하면 됨.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/01/21 20:40 2009/01/21 20:40
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3912

정규식

파일이나 문자열 내에 포함되어 있는 특별한 패턴(또는 특별한 조건을 만족하는 문자열)을 검색하기 위해 미리 정의된 다양한 특수 문자들의 조합을 정규식(regular expression)이라 한다. 정규식에서의 특수 문자(special character)는 다음과 같다.


(1) ^ (caret) : 라인의 처음이나 문자열의 처음을 표시

예 : ^aaa (문자열의 처음에 aaa를 포함하면 참, 그렇지 않으면 거짓)

(2) $ (dollar) : 라인의 끝이나 문자열의 끝을 표시

예 : aaa$ (문자열의 끝에 aaa를 포함하면 참, 그렇지 않으면 거짓)

(3) . (period) : 임의의 한 문자를 표시

예 : ^a.c (문자열의 처음에 abc, adc, aZc 등은 참, aa 는 거짓)

a..b$ (문자열의 끝에 aaab, abbb, azzb 등을 포함하면 참)

(4) [] (bracket) : 문자의 집합이나 범위를 나타냄, 두 문자 사이의 "-"는 범위를 나타냄

[]내에서 "^"이 선행되면 not을 나타냄

이외에도 "문자클래스"를 포함하는 [:문자클래스:]의 형태가 있다.

여기에서 "문자클래스"에는 alpha, blank, cntrl, digit, graph, lower,

print, space, uppper, xdigit가 있다.

이에 대한 자세한 내용은 C언어의 를 참조하면 된다.

예를 들어 [:digit:]는 [0-9]와 [:alpha:]는 [A-Za-z]와 동일하다.

이외에 [:<:]와 [:>:]는 어떤 단어(숫자, 알파벳, '_'로 구성됨)의 시작과 끝

을 나타낸다.

예 : [abc] (a, b, c 중 어떤 문자, "[a-c]."과 동일)

[Yy] (Y 또는 y)

[A-Za-z0-9] (모든 알파벳과 숫자)

[-A-Z]. ("-"(hyphen)과 모든 대문자)

[^a-z] (소문자 이외의 문자)

[^0-9] (숫자 이외의 문자)

[[:digit:]] ([0-9]와 동일)

(5) {} (brace) : {} 내의 숫자는 직전의 선행문자가 나타나는 횟수 또는 범위를 나타냄

예 : a{3} ('a'의 3번 반복인 aaa만 해당됨)

a{3,} ('a'가 3번 이상 반복인 aaa, aaaa, aaaa, ... 등을 나타냄)

a{3,5} (aaa, aaaa, aaaaa 만 해당됨)

ab{2,3} (abb와 abbb 만 해당됨)

[0-9]{2} (두 자리 숫자)

doc[7-9]{2} (doc77, doc87, doc97 등이 해당)

[^Zz]{5} (Z와 z를 포함하지 않는 5개의 문자열, abcde, ttttt 등이 해당)

.{3,4}er ('er'앞에 세 개 또는 네 개의 문자를 포함하는 문자열이므로 Peter, mother 등이 해당)

(6) * (asterisk) : "*" 직전의 선행문자가 0번 또는 여러번 나타나는 문자열

예 : ab*c ('b'를 0번 또는 여러번 포함하므로 ac, ackdddd, abc, abbc, abbbbbbbc 등)

* (선행문자가 없는 경우이므로 임의의 문자열 및 공백 문자열도 해당됨)

.* (선행문자가 "."이므로 하나 이상의 문자를 포함하는 문자열, 공백 문자열은 안됨)

ab* ('b'를 0번 또는 여러번 포함하므로 a, accc, abb, abbbbbbb 등)

a* ('a'를 0번 또는 여러번 포함하므로 k, kdd, sdfrrt, a, aaaa, abb, 공백문자열 등)

doc[7-9]* (doc7, doc777, doc778989, doc 등이 해당)

[A-Z].* (대문자로만 이루어진 문자열)

ike.* (직전의 선행문자가 '.'이므로 like에 0 또는 하나 이상의 문자가 추가된 문자열이 됨, like, likely, liker, likelihood 등)

(7) + (asterisk) : "+" 직전의 선행문자가 1번 이상 나타나는 문자열

예 : ab+c ('b'를 1번 또는 여러번 포함하므로 abc, abckdddd, abbc, abbbbbbbc 등, ac는 안됨)

ab+ ('b'를 1번 또는 여러번 포함하므로 ab, abccc, abb, abbbbbbb 등)

ike.+ (직전의 선행문자가 '.'이므로 like에 하나 이상의 문자가 추가된 문자열이 됨, likely, liker, likelihood 등, 그러나 like는 해당안됨)

[A-Z]+ (대문자로만 이루어진 문자열)

(8) ? (asterisk) : "?" 직전의 선행문자가 0번 또는 1번 나타나는 문자열

예 : ab?c ('b'를 0번 또는 1번 포함하므로 abc, abcd 만 해당됨)

(9) () (parenthesis) : ()는 정규식내에서 패턴을 그룹화 할 때 사용

(10) | (bar) : or를 나타냄

예 : a|b|c (a, b, c 중 하나, 즉 [a-c]와 동일함)

yes|Yes (yes나 Yes 중 하나, [yY]es와 동일함)

korea|japan|chinese (korea, japan, chinese 중 하나)

(11) \ (backslash) : 위에서 사용된 특수 문자들을 정규식내에서 문자를 취급하고 싶을 때 '\'를 선행시켜서 사용하면됨

예 : filename\.ext ("filename.ext"를 나타냄)

[\?\[\\\]] ('?', '[', '\', ']' 중 하나)


정규식에서는 위에서 언급한 특수 문자를 제외한 나머지 문자들은 일반 문자로 취급함


정규식은 Unix의 대표적인 유틸리티인 vi, emacs, ed, sed, awk, grep, egrep 등에서 사용할 수 있다. 다음은 grep에서 정규식을 활용한 예를 보여 주고 있다.

(1) $ 명령어 | grep '정규식'

<= 명령어의 결과를 grep이 입력받아 정규식을 이용하여 패턴을 찾아냄

예 : $ who | grep 'hgkim' <= hgkim이라는 사용자가 login 해 있는지를 알아봄

$ ls -al | grep '^d.*' <= ls -al 의 결과 'd'로 시작하는 라인(즉 디렉토리들)

만을 출력

$ ls -al | grep '^d.*' <= ls -al 의 결과 'd'로 시작하는 라인(즉 디렉토리들)

만을 출력

$ ls -al | grep '^[^d]..x..x..x' <= 디렉토리는 제외하고("[^d]") 누구나

실행가능한 파일("..x..x..x")들 찾기

(2) $ grep '정규식' 파일이름

<= 파일을 입력받아 정규식을 이용하여 패턴을 찻아냄

예: $ grep 'telnet' /etc/inetd.conf


이외의 명령어들도 grep과 유사한 형태로 이용된다. 따라서 정규식을 잘 이용하면 유닉스의 활용이 배가 될 것이다.



PHP에서는 정규식과 관련하여 다음의 네가지 함수를 제공한다.


int ereg(string givenPattern, string givenString, array matched);

- givenString을 "string1stringAstring2stringBstring3 ... string9stringI" 로 주어져 있다고 하자. 이때 stringA, stringB, ... , stringI는 NULL 이어도 상관이 없다(즉 givenString은 "string1string2string3 ... string9" 인 경우임).

- givenString이 위와 같이 주어진 경우,

givenPattern은 "(pattern1)stringA(pattern2)stringB(pattern3) ... (pattern9)stringI"로 입력하여야 한다. 즉 pattern1, pattern2, ..., pattern9는 각각 string1, string2, ... , string9에서 찾고자하는 정규식인 것이다.

- 이때 pattern1이 string1에서 발견한 패턴은 $matched[1]에 저장되고, pattern2가 string2에서 발견한 패턴은 $matched[2]에 저장되고, ..., pattern9가 string9에서 발견한 패턴은 $matched[9]에 저장된다. PHP3의 경우 ereg에서는 최대 9개 까지의 pattern을 찾을 수 있도록 설정되어 있음에 유의하자.

- 그리고 $matched[0]에는 $matched[1]stringA$matched[2]stringB ... $matched[9]stringI가 저장된다.

- ereg가 반환하는 값은 $matched[0]에 저장된 문자열의 개수이다.

- ereg는 case sensitive

- eregi는 case insensitive


예1 :

코드 => print(ereg ("(.*)ef([abc].*)","abcdefabc",$matched));

print("
");

while (list($a,$b)=each($matched))

if ($b)

print("$a, $b
");

결과 => 9

0, abcdefabc

1, abcd

2, abc

예2 :

코드 => print(ereg ("(.*)d(.*)e(.*)qrs(.*)","abcdefghijklmnopqrstuvwxyz",$matched));

print("
");

while (list($a,$b)=each($matched))

if ($b)

print("$a, $b
");

결과 => 26

0, abcdefghijklmnopqrstuvwxyz

1, abc

3, fghijklmnop

4, tuvwxyz

예 3 :

코드 => $date="1999-11-17";

if (ereg("([0-9]{4})-([0-9]{1,2})-([0-9]{1,2})", $date, $regs))

print("$regs[3].$regs[2].$regs[1]");

else print("Invalid date format: $date");

결과 => 17.11.1999

예 4 :

코드 => $joomin="711011-1234567";

if (ereg("([0-9]{2})([01]{1}[09]{1}[0-3]{1}[0-9]{1})-([12]{1}[0-9]{6})",$date, $regs))

print("Valid");

else print("Invalid format: $joomin");


int eregi(string givenPattern, string givenString, array matched);

- ereg의 'case insensitive' 버젼


예 :

코드 => $email="xs9_tx-abc.yyy_c@cne.kyungsung.ac.kr";

eregi("(^[_\.0-9a-z-]+)@(([0-9a-z][0-9a-z-]+\.)+)([a-z]{2,3}$)",$email,$matched);

while (list($a,$b)=each($matched))

if ($b) print("$a, $b
");


결과 => 0, xs9_tx-abc.yyy_c@cne.kyungsung.ac.kr

1, xs9_tx-abc.yyy_c

2, cne.kyungsung.ac.

3, ac.

4, kr



코드 => eregi("^[_\.0-9a-z-]+@([0-9a-z][0-9a-z-]+\.)+[a-z]{2,3}$",$email,$matched);

while (list($a,$b)=each($matched))

if ($b) print("$a, $b
");

결과 => 0, xs9_tx-abc.yyy_c@cne.kyungsung.ac.kr

1, ac.



string ereg_replace(string givenPattern, string replacementPattern, string givenString);

- givenString에서 givenPattern에 부합하는 텍스트(matched text)를 찾아서,

replacementPattern으로 대체

- givenPattern이 "(패턴)"으로 묶인 문자열들을 포함하고 있으면, replacementPattern에는 이에 대응하는 "\\digit(문자열)" 형태의 문자열들을 포함하고 있어야 한다(digit는 0, 1, ... ,9 중 하나). 그리고 givenString은 "(패턴)"을 이용해 찾은 결과들을 "\\digit(문자열)"에 있는 "문자열"들로 대체하게 된다. "\\0" 는 givenString 전체에 대해 "(패턴)"의 결과를 적용할 때 이용된다.

- 변경된 문자열을 리턴

- case sensitive


예 :

코드 => $string = "This is a test";

print(ereg_replace(" is", " was",$string)); print("
");

print(ereg_replace("( )is","\\1was",$string)); print("
");

print(ereg_replace("(( )is)","\\2was",$string)); print("
");

print(ereg_replace("(( )is)(( )a)(( )test)", "\\1was\\2an\\3exam",$string));

결과 => "This was a test";

"This was a test";

"This was a test";

"This was an exam";


예 2 : redundant whitespace 없애기

코드 => $str ="~ s/\s+/ /g";

$str = eregi_replace("[[:space:]]+", " ", $str);

print("$str
");

결과 => ~ s/\s+/ /g


string eregi_replace(string givenPattern, string replacementPattern, string givenString);

- ereg_replace의 'case insensitive' 버젼

==============================================================

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/01/21 13:58 2009/01/21 13:58
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3909

iteration - 반복

it·er·a·tion〔〕 n. [U.C] 되풀이, 반복(repetition);【컴퓨터】 반복

짧은 반복을 사용하여, 점진적으로 배포하라.

짧은 반복은 아주 집중적이고 생산적으로 느껴져야 한다.
확실하고 잘 정의된 목표가 보이고, 그 목표에 도달해야 한다.
마감이 확실하면 결정이 확고해지므로 어떤 쟁점이든지 해결하지 못하거나 결정하지 못한 상태로 오래 놔두지 않게 된다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/01/21 09:41 2009/01/21 09:41
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3906

글로 써서 하는 의사소통에 대해 우리가 말했던 것 모두가 이메일에도 똑같이 적용된다.

이메일은 사내, 회사 간 의사소통의 근간으로 진화해 왔다.
이메일은 계약을 상의하고, 논쟁을 해결하는 데 사용되고, 법정에 증거물로도 사용된다.
하지만 초라한 종이 문서라면 결코 보내지 않을 사람도 어떤 이유에서인지 지저분해 보이는 이메일을 전 세계로 날리기 좋아한다.

우리의 이메일 팁은 간단하다.

▶ [보내기] 버튼을 누르기 전에 교정을 보라.

▶ 맞춤법을 확인하라.

▶ 포맷을 간단하게 하라. 어떤 사람은 이메일을 읽을 때 비례문자(proportional font) 를 사용하기 때문에, 여러분이 만드느라 고생한 ASCII 아트 그림이 그들에게는 마치 의미 없는 낙서처럼 보일 것이다.

▶ 리치 넥스트(rich-text) 혹은 HTML 메일은 받는 사람이 그걸 읽을 수 있는 경우에만 사용하라. 단순한 텍스트(plain text)는 어디에서든 통용된다!

▶ 답장할 때 원본 메시지의 인용은 최소한으로 하라. 자기가 쓴 100줄짜리 이메일 끝에 달랑 '동의' 라고 붙어있는 이메일을 되돌려 받기 좋아하는 사람은 아무도 없다.

▶ 다른 사람의 이메일을 인용한다면 누구의 것인지 밝히고 글 속에서 인용을 하라(첨부로 하지 말고).

▶ 화내고 욕하는 글을 보내지 마라. 그 욕이 자신에게 돌아와서 끊임없이 따라다닐 것이다.

▶ 보내기 전에 받는 사람 목록을 확인하라. 부서 내 이메일에 자기 상사를 비판하는 이메일을 뿌릴 때 받는 사람 목록에 자신의 상사가 포함되어 있다는 사실을 깨닫지 못했던 사람의 기사가 최근 『월 스트리트 저널』에 실렸다.

▶ 이메일을 보관하고 조직화하라. 받고 보내는 중요한 것 모두.

199년도 미 법무부 조사를 통해 마이크로소프트와 네스케이프 사의 여러 직원들이 알게 되었듯이, 이메일은 영원하다. 여타 메모나 보고서에 기울이는 주의와 관심을 똑같이 이메일에도 기울이도록 노력하라.


//---

제발 이메일 쓸 때, 일반 보고 문서 쓸 때 만큼만 이라도 신경 써서 작성하길 바란다.

이메일 쓰기를 여타 사이트의 자유게시판의 글 작성보다 더 못한, 의미 없는 댓글 작성하듯이 쓰는 사람이 적지 않다.

아마도 그건 받는 사람의 소양을 고려하지 않는 생각에서 나오는 게 아닐까?
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/01/19 11:11 2009/01/19 11:11
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/3894

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : Next »

블로그 이미지

- 홍반장

Archives

Recent Trackbacks

Calendar

«   2024/11   »
          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 27 28 29 30
Statistics Graph

Site Stats

Total hits:
235915
Today:
384
Yesterday:
195