철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

Archive for 4월 2007

openid 프로바이더라면 최소한…

with 2 comments

노력은 이해하지만 그것을 떠나서 사용자 약관에 최소한 99.9%정도 uptime(1년에 약 8시간)을 보장하는 SLA 계약은 언급 되어있어야 하지 않을까? 다른 것도 아닌 openid 같이 identity(만)을 처리하는 서비스를 제공하는 경우라면 말이지. 애초에 “다운되었을때 다른 프로바이더를 사용할 수 있는 인프라가설라무네”라는 가정을 먼저 꺼내지 말아야 하는 것이 아닐까. 내가 선택한 프로바이더인데 안정성을 위해서 다른 openid들을 만들어두라는 것도 웃기고(일반 사용자들한테 “우리 죽을 수도 있으니까 다른데도 계정을 만들어 놓으세요.”). 내 계정에 대한 안정성인데 회사들끼리 쿵짝하는 것도 이상하고(안되면 일차적으로는 사용자와의 계약에 관한것이지).

myid 간담회 후기 보다가 문득 든 생각.

Written by charlz

2007년 4월 27일 at pm 11:56

Uncategorized에 게시됨

Adobe Flex 오픈소스화 계획과 Adobe의 행보

leave a comment »

아직 소식을 듣지 못하신 분들은 보도자료를 여기서 보실 수 있습니다. 스코블이 Flex 팀원들과 독점 인터뷰를 한 동영상도 있습니다. 발표에서는 실제 오픈소스화가 6월에 조금씩 시작하여 2007년 말에 완료될 것이라고 이야기하고 있습니다. (Adobe의 Flex SDK 오픈소스화에 관하여 더 자세히 알고 싶은 점이 있다면 이에 관한 토론을 위해서 만든 구글 그룹을 통하여 질문할 수 있습니다. 현재 몇가지 궁금한 내용들을 Adobe에서 답변을 달아준 내용들이 있군요.)

(나머지 글 보기…)

Written by charlz

2007년 4월 27일 at am 3:34

Uncategorized에 게시됨

구글의 오피스(Apps), 2007년 4월 현재 상황

with 4 comments

대충 생각나는대로 주저리…

위드프로세싱을 위해 Writely를, 스프레드시트를 위해 XL2Web를 인수했었다. 이번에는 프레젠테이션을 위해서 Tonic Systems를 인수했다. 뻔하지만 공식대로라면 Office 제품군의 제품목록을 보면 향후 방향을 좀 더 예상해 볼 수 있다. 많은 블로거분들이 표를 만들었지만, 한번 더 해보면:

  • Word – Writely인수후 Docs로.
  • Excel – XL2Web인수후 Spreadsheet로, 근래에 표기능 추가.
  • PowerPoint – Tonic Systems. 오픈 예정.
  • Outlook – GmailCalendar
  • OneNote – Notebook
  • Access, InfoPath, Forms Server – Base(?), DabbleDB 같은걸 인수해서 무료로 제공해줬으면 좋겠다. 혹은 CogHead?
  • Publisher – Pages(?)
  • SharePoint Server – Groups(?), Personalized Homepage(?)
  • Groove – Groups, Code
  • Project(Client/Server) – 아직 Microsoft Project에 준하는 서비스가 나오지 않은 것이 신기하다. 37Signals를 인수하려는 것은 아닐텐데 말이지.
  • Visio – Microsoft Visio도 분명 타겟일텐데.
  • SharePoint Designer – Designer가 필요한 SharePoint Server에 준하는 제품이 없으니 예외.

온라인 서비스들이니 1:1로 대응 안되는 것은 당연하기는 하지만, 그래도 이정도 모양이 나온 것이 우연은 아닐터.

이걸 보면 바로 드는 생각이, 구글이 Microsoft Office에 비해 가질 수 있는 장점 중 하나가 이런 구현이 다른 것과 믹스되거나 분리되어 가질 수 있는 다른 새로운 가치를 제공할 수 있는 서비스를 구현하기가 데스크탑 소프트웨어보다 상대적으로 쉽다는 것이다. 예를 들어, Spreadsheet의 표기능을 독립적으로 분리해서 Chart라는 서비스를 오픈하고 이 Chart가 다른 서비스에서 사용될 수 있도록 함과 동시에 독립적인 서비스로 제공할 수 있도록 한다면.

그런 면에서 자기네 서비스만이 아닌 단순 Mashup을 넘어선 포괄적인 User Created/Generated Applications(UC/GA?)를 위한 Ning이나 Dapper, Yahoo! Pipes같은 서비스나 인수(?)도 한번 기대해본다.

이 서비스들이 수익모델을 가지게 되는 방향도 Microsoft Office와의 관계에서 지켜봐야할 부분이다. 역시 광고/검색/호스팅 뿐이라면, 수입과 상관없이 아무리 많이 쓰더라도 그 자체로서는 틈새가 크지 않을테니.

Written by charlz

2007년 4월 24일 at pm 3:21

Uncategorized에 게시됨

윈도우 Notepad(메모장)의 Ctrl+Z(Undo)가 작동될 날이 올지도

with 6 comments

가슴아프게도 디테일을 떠나서 Notepad(메모장)의 버그로 인해서 한글에서의 Ctrl+Z의 기능이 작동을 하지 않습니다. 영어를 사용하면 비록 한단계이기는 하지만 Undo가 가능합니다. 그동안 버그로 생각하지 않았던 것인지 아니면 Notepad의 경중을 따진 것인지는 정확히 모르겠지만 버그로 올라가 있지 않았었습니다. 회사에 입사하게 된 이후에 여러가지를 배우면서 그 중에서도 IME관련 내용들을 많이 배우게 되었는데, 그 와중에 요건 고칠 가치가 있겠다고 생각했습니다. 그래서 버그를 중요도를 높여 올리고 Push하기 시작했습니다.

겨우 꽤나 오래된 Notepad에서 그것도 잘못 동작한다고 생각하기 보다는 기능이 없다고 생각할 수 있는 현재의 현상 그리고 버그 자체의 중요도를 살펴보면 사실 버그가 고쳐지지 않을 가능성도 각오하고 올린 버그였습니다. 게다가 비록 올릴 수는 있도록 되어있다고 해도 제 팀과는 상관이 없는 제품의 버그이기도 하고, 이전 호환을 위해서 behavior가 바뀌는 것에 대한 평가도 생각하면 더더욱 그랬죠. 버그가 올라가자 우리나라를 포함한 IME 팀의 멋진(?) 분들이 문제를 휙휙 쉽게 찾아냈습니다. 이제 문제는 이것을 고치느냐는 것이었습니다.

좋은 소식, 긴 email끝에 고쳐지는 것으로 결정나고 현재 윈도우의 코드트리에는 픽스가 올라와 있는 상태입니다. Notepad는 그 기능이 간단할지는 몰라도 윈도우를 설치하면 텍스트를 수정/생성할 수 있는 가장 빠른 방법으로 실제로 엄청나게 많이 사용되고 있고 그것을 해당 팀이 모를리 없으니, 제 걱정은 괜한 것이었죠. 언제일지 모르는 다음 윈도우 업그레이드에 포함될 것을 기다리고 있고, 그때되면 한글의 Undo가 동작하는 것을 확인하고 버그를 기분좋게 닫으면 이것 하나 종지부를 찍게 됩니다.

springnote의 포스트 “스프링노트 이야기 1 – 생각이 자라나는 노트“를 통해 본 이야기:

[공감??] 메모짱…짓궂군효

를 보고는 이 포스트를 올리지 않을 수가 없었네요.^^ 부디 한글 Undo가 안전하게 Notepad에 안착하길.

Written by charlz

2007년 4월 22일 at am 12:02

Uncategorized에 게시됨

Visual Studio "Orcas"와 .NET FX 3.5 베타 1

with 2 comments

Somasegar’s WebLog : Visual Studio “Orcas” and .NET FX 3.5 Beta1 shipped!

Visual Studio Code Name Orcas Downloads

Visual Studio 2005의 차기버젼인 코드명 Orcas의 베타 1 버젼과 이를 위한 .NET Framework의 3.5 의 베타 1 버젼이 드디어 공개되었습니다. 지속적으로 CTP(Community Technology Preview, 커뮤니티 기술 프리뷰)를 내놓았었지만, 베타 1은 CTP들과는 다르게 모든 기능 전체를 정비하여 내놓는 하나의 큰 초석입니다. 첫 베타인 만큼 아직 완성도가 높지 않을 수 있지만 수백가지의 새로운 기능들이 포함되었고 다양한 픽스들이 들어가있습니다. 이번 공개에는 무료로 배포되는 Express버젼도 처음으로 포함되었습니다.

Orcas는 .NET Framework 3.0을 업그레이드한 .NET Framework 3.5를 사용하여 만들어졌지만, PC에는 각 버젼별로 SxS(Side by Side, 사이드바이사이드)로 사이좋게 설치가 가능하고 이전 버젼의 프로그램들을 최대한 해치지 않는 범위를 지키기 위해서 노력합니다. 또한 Orcas로 만드는 프로젝트들은 “Multi-Targeting”(멀티 타게팅)이 가능하여 원하는 .NET Framework의 버젼을 기준으로 개발을 할 수 있기 때문에 업그레이드시의 기술 변경의 부담이 없어졌습니다!

수많은 새로운 기능들은 다음의 백서에서 보실 수 있습니다:

Download details Visual Studio code name Orcas Overview White Paper

백서의 부록에 장장 10페이지가 넘는 기능 요약이 있으니 참고하시면 좋을 것 같습니다.

(Cross posted to my msdn blog)

수많은 팀들로 이루어진 커다란 개발툴 부서에서 CTP를 지속적으로 이렇게 빨리 내놓기까지 근 1년도 걸리지 않았지만, 엄청나게 많은 고통스런(?) 변화들이 내부적으로 있었습니다. 그 결과로 크기와 상관없이 베타의 주기도 빨라질 수 있었고, 다양한 엔지니어링 향상을 가져올 수 있었죠. 이제 베타1으로 윤곽을 잡았으니 사용자와 교감(?)을 나눠서 최종적으로 출시하는데까지 달려가는 일만 남았군요.^^ 개발 툴과 개발 플랫폼을 만드는 일만큼 욕과 칭찬을 많이 받는 곳도 없을것 같습니다.

Written by charlz

2007년 4월 20일 at pm 12:02

Uncategorized에 게시됨

내 사이트 오시는 분들 중에서

leave a comment »

그 오래전 +ORC 찾기라든가 fravia+등등 기억하시는 분들도 계실까…

그분들 지금 직업이 아마도…?

Written by charlz

2007년 4월 17일 at pm 8:25

Uncategorized에 게시됨

Microsoft Silverlight 발표!

with 5 comments

Microsoft Silverlight
(이미지는 네뷸라라는 로고)

Microsoft Silverlight

그동안 언급을 하지 않던 마이크로소프트의 차세대 웹 전략의 일부인 Microsoft Silverlight 브랜드가 NAB(National Association of Broadcasters) 2007이라는 큰 규모의 방송미디어 컨퍼런스를 시작으로 전격적으로 공개되었습니다. 이전에는 WPF/e라는 코드명으로 공개되어 마치 Flash의 경쟁 제품 중 하나쯤으로 회자되던 그것이 사실 그 정도가 아니었습니다. 배경 소개를 위해서 작은 연재를 해봅니다: Silverlight-마이크로소프트의-차세대-웹-전략의-교두보(I)

오늘 공개한 내용으로는:

  • IE와 FireFox, Safari 지원. Windows군 지원과 Mac의 지원.
  • 서버에는 Microsoft 제품군이 전혀 필요 없음.
  • 미디어 지원
    • 풀스크린 720p의 VC-1 WMV까지의 동영상을 지원!
    • QuickTime등의 다른 미디어로부터의 변환을 위한 Expression Media Encoder 공개 예정.
    • 다양한 업체들로부터의 스트리밍/미디어 기술 지원.
    • Windows Longhorn의 IIS7을 사용할 경우 Media Pack을 통해 미디어 다운로드/스트리밍 지원(Windows 2003의 2배).
  • 작은 설치 용량!
  • WPF에서 사용하는 Visual Brush의 사용! – 비디오 자체를 브러쉬로 사용하여 어떤 곳이든 그릴 수 있는 기능.
  • 소스코드는 모두 텍스트. 바이너리로 되어 볼 수 없는 부분은 없다.

현재 Silverlight를 지원하거나 이를 사용하여 서비스를 준비하고 있는 회사들은: Akamai Technologies Inc., Brightcove Inc., Eyeblaster Inc., Limelight Networks, Major League Baseball and Netflix Inc. Brightcove, Eyeblaster, Limelight Networks, Major League Baseball, NaviSite Inc., Netflix, Pinnacle Systems Inc., Rhozet Corp., Skinkers, Sonic Solutions, Tarari Inc., Telestream Inc. and Winnov등 다양한 기술 회사들과 미디어 회사들을 포함합니다.

오늘 NAB에서 공개한 것은 브랜드와 데모화면이었지만, 조만간 실제로 사용해볼 수 있는 바이너리를 제공할 예정이고 이전의 맛보기 버젼인 2월 CTP를 사용해보실 수 있습니다. 다음의 링크들에서 더 많은 정보를 보실 수 있습니다.

Microsoft Silverlight Virtual Pressroom – Microsoft Silverlight VPR Press Material

Somasegar’s WebLog

Tim Sneath  Introducing Microsoft Silverlight

out-with-wpfe-in-with-microsoft-silverlight-this-has-just-been-announced (on10 동영상)

Addicted to Digital Media – Introducing Microsoft Silverlight

(Cross-posted to my msdn weblog)

웹에서 할 수 있는 것들이 늘어나고 좋아진다는 사실은 꽤나 신나는 일 아닐까요. 컨텐츠 일관성을 위해 Silverlight의 소식에 관해서는 여기와 msdn블로그에 같이 올리고, 관련된 글을 desktop 블로그에 올렸습니다.^^

Written by charlz

2007년 4월 16일 at pm 9:44

Uncategorized에 게시됨

구글, Maxthon 지분 일부 인수

with 3 comments

Google Takes Partial Ownership Of Maxthon Browser

한때 개인적으로 많이 사용했던 브라우저. 그 전 이름 MyIE2, 그 전이름 MyIE(중국), 그리고 영향을 주고 받았던 Donut씨리즈(일본), 등등으로 이어지는 Maxthon. 현재 Maxthon의 중국 점유율은 엄청 높다고 한다. 아무튼 공개된 소스를 개선하여 만든 MyIE2지만 결국 그걸로 한건 해낸 듯하다.

추억의 브라우저들이 주제라면 할이야기가 많은 분들…무지 많겠지. 난 여기까지.

Written by charlz

2007년 4월 10일 at pm 11:30

Uncategorized에 게시됨

"개발자와 기획자, 상생의 길"을 읽다가…

with 7 comments

Linus Home 개발자와 기획자, 상생의 길 – 해당 프로젝트에서 좋은 해결방안을 찾은 경우인 것 같고 프로젝트가 잘 되었다고 하니 툴을 만들기 위한 시간이 스케줄에 영향을 많이 미친 것도 아닌 것 같구요. 이런 해결책을 적용할 수 있는 프로젝트(혹은 그 종류)가 많지는 않을테지만, 이 경우를 한가지 예로 생각하고 조금 더 광의에서 생각해봅니다.

다음과 같은 기본적이고도 당연한 가정을 일단 생각해봅시다:

  1. 기획자가 기획을 한다.
    개발자나 다른 사람들로부터 피드백을 받거나 할 수 있지만, 결국 기획은 기획자가 하는 것이다. 그러니 기획에 대한 책임은 기획자가 지는 것이다.
  2. 개발자는 기획자가 만들어 놓은 틀에서 개발 결과를 만들어낸다.
    기획자가 문서로 주었든 말로 전달을 했든 결과는 개발자가 만들어내는 것이다. 개발자는 전달된 내용으로 구현을 하는 것이 책임이다.
  3. 기획이 완벽할 수 없으며 틀이 갖춰지지 않은 부분의 구현은 서로의 책임이다.
    기획자는 구멍을 만든 책임, 개발자는 구멍을 때운 구현의 책임.

위의 것은 잘 지켜지지 않습니다. 서로 이해하지 못하는 이유인데 다음의 것들을 생각해봤습니다:

  1. 기획은 반드시 바뀐다.
    기획자의 책임이니 아니다 싶으면 바꾸게 되는 것은 당연하죠. 바뀐 기획을 반영하는 것이 개발자의 몫이기 때문에 그것도 당연하지 않느냐! 는 이야기를 하죠. 필연적이지만 당연하지는 않다.
  2. 개발 세부도 반드시 바뀐다.
    기획이 바뀌듯이 개발 일정을 왜 못지키느냐, 개발자들은 뭘 하냐는 이야기는 즐.^^
  3. 기획의 범위는 애매하다.
    디자인/개발 세부까지 아우를 수 있는 반면, 둘다 전혀 상관 없을 수도 있다. 기획자의 배경과 재능에 따라 어느쪽으로 어느정도 디테일을 가지느냐는 천지차이로 달라질 것이다. 디테일하다는 것이 좋은 것이라는 이야기는 아니다. 되려 독이 될 수도 있다.
  4. 구현과 기획의 괴리는 반드시 발생한다.
    개발자 배경인 기획자라고 하더라도 기획이 개발 세부에서 나오는 괴리를 모두 커버할 수는 없다. 반면, 기획자가 내가 개발자냐라고 반문한다면 이를 존중하지 않는 것이겠죠. (엄청나게 많은 사람들이 참여해서 만드는 표준을 구현한 구현체들이 각기 동작이 다르듯이 말이죠.) 극단적인 예를 들어, 기획서에 “목록”이라고 되어있다면, 개발자에게 있어서 “목록”이라는 구현은 수십가지인데 그 중에서 기획자가 원하는 것을 찾을 방도는? 기획서에 나온대로 할 수 없는 기술적인 장벽도 존재한다.
  5. 개발자는 디자이너가 아니다.
    개발자가 만들면 투박하기 쉽다는 말은 틀린 것이 아니라 당연할 가능성이 큰 것이니까 할 필요가 없다. 개발자한테 이거 왜 인터페이스 디자인이 후져?라고 하지 말지어다. 개발자가 디자인을 맡지 않은 한 디자인을 잘할 필요가 하등 없다.
  6. production 개발과 prototype 개발은 다른 것이다.
    이리해보고 저리해보고 하는 것은 구현의 결과를 예측하기 힘들기에 당연하지만 올바른 기획자라면 당연시하기보다는 최소화해야한다. 결정을 내리는 입장의 짐은 그만큼 무거운 것이다. 위의 Linus님이 하신 이야기는 이를 프로젝트의 성격에 맞게 해결하기 위해서 잘하신 일일것이다. (단, 스케줄에 지장이 없을지어다)
  7. 개발은 예외없이 버그를 양산한다.
    말할필요도 없다. 왜 버그가 많냐고 말할 시간에(많고 적음은 개발팀의 몫) 버그를 얼마만큼 줄이자는 말이 그리고 그 시간을 존중해주는 것이 훨씬 낫고 맞다. 버그의 수가 중요한 것이지, 버그가 있냐 없냐는 무의미한 말이다. 흔히 스케줄에 버그를 고치는 기간같은 것을 반영 안하는 경우가 많은데, 위의 가정을 생각하면 작은 프로젝트라도 꼭 넣어야하고 없다면, 이런 시간이 있다는 것을 최소한 고려해줘야한다.
  8. 기획도 예외없이 버그를 양산한다.
    이리해보고 저리해보는 것을 버그로 인식하지 않는 것은 틀린 것이다. 기획서에 나와있는 말대로 구현되고나서 해보고 기획한대로 안되면 일단 버그인 것이다. 기획서에 한줄이 바뀌면 구현의 임팩트는 수십수백수천 혹은 수만라인의 코드가 될 수도 있는 것이다. 이에 대한 영향은 7번에서 이야기 했듯이 개발로 인한 버그를 만들어내는 것과 동일하다는 것이다. 이렇게 생각하면, 이리저리 바꾸는 것을 트래킹해야하는 것은 당연하지 않은가. 버그를 무조건 부정적인 것으로 생각하지 말아야한다.

이 중에서 7과 8에 무게를 두고 싶은건 왜일까요.ㅎㅎㅎ

(사실 이는 정해진 스케줄과 리소스 내에서 뻔한 사실 두가지로 귀결됩니다. 각자의 영역에 대한 유연성 부족. 서로의 롤에 대한 이해 부족. 나를 중심으로 원이 형성되어있습니다. 그 원이 일하는 상대의 원과 너무 멀면 기획과 개발의 차이는 커지고 말썽이 많아지는 것이고, 너무 가까우면 서로의 영역에 침범하는 것이 됩니다. 하지만, 이를 이해하고 인정하면 일은 좀 더 쉬워집니다. 원을 늘일 수는 없지만 유연하게 잠시 줄일 수는 있고, 멀면 멀다는 것을 인정하고 – 툴을 만들어주는 등^^ – 임하면 되는 것입니다.)

Written by charlz

2007년 4월 7일 at pm 4:20

Uncategorized에 게시됨

테스트 포스트

leave a comment »

흠냐…슬러그까지???

Written by charlz

2007년 4월 6일 at pm 10:37

Uncategorized에 게시됨

%d 블로거가 이것을 좋아합니다: