IT 프로세스 표준화란 무엇입니까?
IT 프로세스 표준화란 무엇입니까?
CMMI, Cobit, ITSM 등이 표준 프로세스입니다.
제안사는 IT 프로세스를 어떻게 표준화 할 것입니까?
전문적인 컨설턴트를 투입하여 표준화 할 것입니다.
투입되는 컨설턴트가 전문지식과 스킬을 가진 인력이라는 것은 당연한데, 그 컨설턴트는 어떻게 일을 할 것입니까?
잘 할 것입니다.
일을 하겠겠다는 의지가 있는것입니까?
왜? 화를내고 그러십니까?
이러면 않되겠죠? :)
ExtJS + AIR로 만든 MP3 Player
![]() |
|---|
| ExtJS MP3 Player |
http://extjs.com/blog/2008/11/24/extplayer-air-and-ext/
이런 발상을 할 수 있다는 것이 상당히 흥미롭습니다. (생산성 측면 + 활용성 입니다.)
기술은 어디까지 변화하는 것일까요?
거창한 물음보다. 다음번 프로젝트에 어떤 기술을 사용해야 할 까요?
요즘 팀원들이 EXT-JS를 사용하여 프로젝트 하면서 많이들 어려워 하고 있습니다. 하지만, (지금)어려울지는 몰라도, 트랜드의 흐름중에 있는 솔루션인것은 분명 할 것 같습니다.
모두들 파이팅.
버전관리 - 작업영역에 대한 오해
이글은 이파피루스 대표이신 모던보이님의 글에 트랙백하기 위해서 씁니다.
이파피루스 대표께서 운영하는 블로그에 “버전관리시스템과 포스트모더니즘"이라는 글이 올라왔습니다. 물론 글의 내용은 본인도 상당히 공감하는 통제와 자유화의 관점에서 느끼는 소견이라 사족을 달고 싶지는 않습니다. (동감한다고 해야 할까요?)
하지만, CVS와 SourceSafe의 비교에서 일반 사용자(버전관리 시스템을 개발하는 사람은 아닌)분들이 조금 헷갈려 하시는 부분이 있어 언급하고자 합니다.
CVS와 SourceSafe로 대표되는 개인용 버전관리시스템의 가장 큰 차이점은 “무결성"을 유지하는 방법입니다. 여기에서 무결성이란, 현재 수정중인 소스를 여러 사람이 한꺼번에 수정 했을때, 혹은 이전 버전을 등록하려고 하는 등의 사용자의 실수를 방지하고, “버전관리 시스템"차원에서 결함이 없을을 보장하는 것 입니다.
Do You Know? Habbo Hotel
Blog 유입키워드를 보다 Pixel Art가 있어서 포스팅 해 봅니다.
예전에 Pixel Art에 관심을 가지고 방문했던 여런 사이트중에서 인상 깊었던 곳 중에 하나인 Hotel Haboo를 소개 합니다.
지금이야 상대적으로 아무것도 아닌기술(수준)이 되었지만, 한때 비교해 보았던 싸이월드와는 느낌이 다른 서비스라고 할 수 있습니다.
간단하게 소개 하자면 레고형태의 케릭터를 만들고, Babbo호텔 내를 돌아다니면서(룸을 방문하거나 나이트클럽등 공공장소) 소셜네트워크를 가지는 게임입니다만. Pixel Art에 관심이 있는 입장에서는 다분히 많은 아이템을 볼 수 있어 눈이 즐겁습니다.
![]() |
|---|
| Habbo Hotel |
주로 Room(하우징 개념)을 치장하고, 지인을 불러 수다떨고 노는 분위기 입니다만, 나이트 등에서 One Night Stand를 희망하는 알수없는 님들을 가끔 볼 수 도 있습니다. 본인의 Tag를 도발적인 것으로 해두면 거의 걸린다고 보시면 됩니다. (물론 지리적인 한계 때문에 욕을 먹겠지만 말입니다.)
Borland Management Suite 릴리즈
Delphi를 버리고 ALM 전문기업으로 거듭난 Boland에서 최신 트랜드를 따라가는 솔루션을 발표하였습니다.
이름은 Management Studio. URL: http://www.borland.com/us/products/team/index.html
TeamDemand, TeamFocus, TeamAnalytics 3개의 솔루션을 구성되어 있으며, Boland에서 밀고있는 Open ALM Framework을 위해서 만들었습니다 만. (왠지 IBM Jazz Framework에 밀리는 듯한 느낌이 좀 있습니다.)
아직 평가판을 사용해 보지 않은 상태에서 평가를 하는 것이 부적절합니다만, 왜 지금 시점에 이런 제품이 출시되었는지 잘 이해가 않됩니다. 좀 늦지 않았나요? (하여간.)
기본적으로 요구사항관리, 프로젝트 포트폴리오관리, BI 혹은 대쉬보드를 지원하기 때문에 필요한 많은 부분을 가추었다고 생각됩니다만, 역시 지원되는 레파지토리가 문제인거 같습니다.
구글 크롬 - HanRSS리더로 인정.
모두들 아시다 시피. 구글에서 크룸이라는 웹브라우저를 발표했습니다. (놀라운 일도 아니지만)
Tistory에서 글을 쓰는것은 조금 불편합니다. (기능상이 아니라 시각적으로)
하지만 HanRSS에서 포스팅들을 로딩하는 속도와 스크롤하는 속도는 IE가 도저히 못따라오는듯 너무 편안 합니다.
IE에서는 수집된 글이 많은경우에 스크롤을 하면 너무 버벅거려서 제목만 보이게 하고 스크롤하는 것이 버릇이 되었었는데 크롬의 경우에는 편안하군요.
앞으로 기어스를 내제해서 어떤 서비스들이 난무할지 알수는 없습니다만, [죽어버릴지도 :)] HanRSS리더로는 아주 좋은거 같습니다.
개발자들의 잦은 Commit은 오히려 축복이 아닐까요?
이 글은 오리대마왕님께 트랙벡하기 위해서 씁니다.
먼저 우리개발팀은 SVN을 사용하지 않습니다. 버전관리는 실루엣을 사용하니 SVN에 특화된 이야기는 아니지만 개발자들의 Commit은 장려해야 하는 것이 아닐까해서 몇자 적어 봅니다.
이제까지 형상관리 혹은 버전관리 제품을 사이트나 프로젝트에 도입하면서 개발자들이 못쓰겠다고 버티는 것이 문제였지 너무 잦은 commit은 축복이 아닐까 합니다.
물론 오리대마왕님이 지적하신 것 처럼 프로젝트 리비전을 지원하는 SVN에서 파일 하나 단위로 commit하면 관리하는 입장에서 상태파악(Insight)하기는 좀 곤란하지요. :)
(Eclipse SVN)에 버그가 있어서 소스가 날라가는지는 모르겠지만, 버전관리 시스템은 개발자들이 아무리 험하게 다루더라도 그 변경내용을 고스란히 기록해 줄 것입니다. 그것이 그 프로젝트의 생명줄과 같을 테니 말입니다.
MS의 ITSM솔루션은 어디로 갔을까?
![]() |
|---|
| MS ITSM |
2007년 겨울에서 2008년 봄까지 한국 MS에서 무척이나 홍보에 신경을 쓰던 MS ITSM솔루션이 여름을 지나는 지금은 너무나 조용한듯 합니다.
어제(8월 21일) Compuware의 ITSM Roadshow에 참석하고 관련자료를 정리하다보니, 예전에 MS ITSM 세미나에 참석했다 실루엣팀원들에게 전파하기 위해서 작성해 두었던 자료가 있어서 생각이 났습니다.
약 8개월이라는 시간 밖에는 지나지 않았지만, 초기에 의욕적으로 펼치던 세미나 혹은 홍보가 오히려 수그러든 느낌이 들어서 그렇습니다.
개인적으로 MS의 ITSM(MOF+SMF)에 대해서 강한 인상을 받았고, 저또한 질문을 했었지만, UNIX가 전산실을 점령하고 있는 상황에서 시장을 만들어 낼 수 있을 것인가 궁금하기도 했습니다.
Package 제품과 SLA에 대한 의견 - Coolite를 보면서
요즘 실루엣 Web Framework을 재정비하면서 Javascript Framework인 EXTJS를 사용하고 있기 때문에 관련 자료를 많이 수집하고 있는 편입니다.
자료중에 눈에 띄는 것이 Coolite라고 하는 ASP.Net에서 EXTJS를 사용 할 수 있도록 해주는 제품입니다. 물론 실루엣팀은 Delphi2007을 사용하여 Server Side Layer를 처리하기 때문에 관련은 없지만, 제품의 가격 및 지원정보를 부분에서 잘 정돈되어 있는 제품이라는 인상을 받았습니다.
![]() |
|---|
| ExtJS Price |
Package제품을 만들고 고객지원을 하는 입장에서는 어느 수준까지 서비스를 해야하는가에 대한 계약(SLA, Service Level Agreement)를 정하는 것이 쉽지는 않습니다.
Bug Tracking과 Issue Tracking의 차이에 대해서 의견을 밝혀봅니다.
이 글은 Common Sense님의 글에 트랙백하기 위해서 작성합니다.
질문: Bug Tracking과 Issue Tracking의 차이는? 결론: Bug와 Issue가 가지는 단어의 의미차이 입니다.
여러 책이나 문서에서 “결함(Bug)이라는 단어보다는 논쟁/논의(Issue)라는 단어를 선호하기도 합니다.“라고 완곡하게 표현합니다.
Bug Tracking이나 Issue Tracking이나 모두 “일을 잘 하자고"하는 시스템입니다만, 그 잘 하자는 일에 접근하는 본질적인 시각의 차이는 있습니다.
단순하게 말해서, 요청자(주로 고객이거나 사용자)가 요청하는 모든사항(요청사항 = Ticket으로 발행되는것)이 결함(Bug)는 아닐 것입니다. 물론 결함이 주로겠지만, 기능개선도 있을것이고, 기능개악(^^;)도 있을것이고, 무엇인지 정의하기 어려운 부분도 있을 것입니다.



