류종택의 프로그래밍 강의실

New Rally X - BGM

류종택 — Mon, 30 Apr 2012 16:55:28 +0900

작업하면서 마음을 안정시키기 위해 듣는 용도로 사용 중인, 일명 방구차의 BGM ㅋㅋ

디아블로와 스타크래프트 BGM도 사용한 적이 있었는데, 문제는 이게 반복할 때 끊어지는 느낌이 문제네 ㅡ.ㅜ

'etc' 카테고리의 다른 글

New Rally X - BGM (0)	16:55:28
TED - 8가지 성공의 비결 (0)	2012/04/24
Use the Magic Trackpad with your Windows PC (0)	2012/03/06
Tron 게임 (0)	2012/02/17
퍼포먼스를 위한 발악 (2)	2012/02/11
LED Display (0)	2012/01/18

Slump Slimp Slurpy

류종택 — Wed, 25 Apr 2012 16:45:43 +0900

오랫만에 놀러 간 사이트에 퀴즈가 올라와 있길래 한 번 풀어봤습니다. 컴파일러와도 연관이 있어서 분류를 컴파일러로 해뒀습니다.

문제 : http://codejob.co.kr/code/view/109/

우선 문제를 BNF로 표시해 보면 다음과 같습니다.

<Slimp> --> AH | AB<Slimp>C | A<Slump>C

이제 YACC를 이용해서 문제를 가볍게 해결할 수도 있겠지만, 퀴즈를 풀어 보는 것이 목적이므로 직접 코딩을 해보도록 하겠습니다.

코딩을 하기 이전에 위의 BNF가 어떻게 처리되야 하는 지를 [그림 1]과 같이 약간 변칙적인 상태도로 표현해봤습니다. 이전 포스트(http://ryulib.tistory.com/73)에서도 상태도를 이용해서 BNF를 표현하는 방법에 대해서 설명했듯이, 저는 상태도를 이용하여 BNF를 저만의 방식으로 처리하고 있습니다. 이번에는 좌측 결합은 없고 우측 결합만이 있기 때문에 비교적 간단하게 처리할 수가 있습니다. 읽는 방법은 제가 프로젝트에 쫓기고 있어서 생략합니다. 첨부하는 코드를 참고하시기 바랍니다.

[그림 1] BNF를 상태도로 표현

[소스1]

procedure TfmMain.FormCreate(Sender: TObject);
var
  Slurpy : TSlurpy;
begin
  Slurpy := TSlurpy.Create;
  try
    Slurpy.Source := 'AH';
    moMsg.Lines.Add(Format('%s IsSlimp is %s', [Slurpy.Source, BoolToStr(Slurpy.IsSlimp, true)]));

    Slurpy.Source := 'ABAHC';
    moMsg.Lines.Add(Format('%s IsSlimp is %s', [Slurpy.Source, BoolToStr(Slurpy.IsSlimp, true)]));

    Slurpy.Source := 'ADFGC';
    moMsg.Lines.Add(Format('%s IsSlimp is %s', [Slurpy.Source, BoolToStr(Slurpy.IsSlimp, true)]));

    Slurpy.Source := 'ABAHD';
    moMsg.Lines.Add(Format('%s IsSlimp is %s', [Slurpy.Source, BoolToStr(Slurpy.IsSlimp, true)]));

    Slurpy.Source := 'AHDFG';
    moMsg.Lines.Add(Format('%s IsSlurpy is %s', [Slurpy.Source, BoolToStr(Slurpy.IsSlurpy, true)]));

    Slurpy.Source := 'DFGAH';
    moMsg.Lines.Add(Format('%s IsSlurpy is %s', [Slurpy.Source, BoolToStr(Slurpy.IsSlurpy, true)]));
  finally
    Slurpy.Free;
  end;
end;

[소스 1]은 IsSlump, IsSlimp, IsSlurpy를 판별할 수 있는 TSlurpy 클래스의 사용방법입니다. 7: 라인에서처럼 Source 멤버에 검사할 문자열을 입력하시고, IsSlump / IsSlimp / IsSlurpy 등의 메소드를 통해서 해당 문자열이 Slump인지, Slimp인지 또는 Slurpy인지를 판별할 수가 있습니다.

[소스 2]

function TSlurpy.IsSlurpy: boolean;
begin
  try
    Result := IsSlimp and IsSlump;
  except
    Result := false;
  end;
end;

function TSlurpy.IsSlimp: boolean;
begin
  try
    FState := FStateSlimpBase;
    FIsFinished := false;
    repeat
      FState.Execute;
    until FIsFinished;

    Result := true;
  except
    Result := false;
  end;
end;

function TSlurpy.IsSlump: boolean;
begin
  try
    FState := FStateSlumpBase;
    FIsFinished := false;
    repeat
      FState.Execute;
    until FIsFinished;

    Result := true;
  except
    Result := false;
  end;
end;

[소스 2]는 TSlurpy 클래스의 일부분 입니다. IsSlurpy는 간단하여 설명을 생략합니다. IsSlimp와 IsSlump의 경우에는 동일한 구조이기 때문에 IsSlimp만을 설명하도록 하겠습니다.

13: [그림 1]에서는 모든 시작을 Base라고 표시했으나, IsSlimp를 점검하는 조건만을 보면 처리가 달라지기 때문에 FStateSlimpBase를 기초 상태로 두고 있습니다.

14-17: FIsFinished가 true가 될 때까지 반복을 하고 있습니다. FIsFinished가 true라는 것은 현재의 검사가 성공적으로 완료되었다는 의미입니다. 반복하는 동안 계속 현재의 State의 Execute 메소드만을 실행합니다. 내부적으로 무엇을 할지는 캡슐화되어 있어서 정확히는 모르겠지만, 조건이 만족되거나 에러가 날 때까지 계속 문자열을 검색한다는 것을 직감적으로 알 수가 있습니다.

21: 만약 파싱 중간에 에러가 있다면 Exception을 발생시킬 에정입니다. Exception이 발생된다면, 현재의 점검은 false로 리턴합니다.

[소스 3]

procedure TStateSlimpBase.Execute;
begin
  case Next of
    'A': begin
      SetState(FSlurpy.FStateSlimpA);
    end;

    else raise Exception.Create('Error in ' + ClassName);
  end;
end;

3: 다음 문자를 읽어 들입니다.

4-6: 'A'라는 문자열이면 상태를 FStateSlimpA로 옮겨서 검사를 계속 진행합니다.

8: 다른 문자열이 온다면 에러 입니다.

[소스 4]

procedure TStateSlimpA.Execute;
begin
  case Peek(1) of
    'H': begin
      Next;
      FSlurpy.FIsFinished := true;
    end;

    'B': begin
      Next;
      SetState(FSlurpy.FStateSlimpAB);
    end;

    else begin
      if FSlurpy.IsSlump then FSlurpy.FState := FSlurpy.FStateSlimpASlump
      else raise Exception.Create('Error in ' + ClassName);
    end;
  end;
end;

3: 이번에는 다음 문자열을 읽지 않고, 살짜 훔쳐(Peek) 봅니다.

4-7: 'H' 일 경우에는 검사가 완료되고 IsSlimp는 true를 리턴하게 됩니다. 훔쳐보기만 했기 때문에, 문자열 하나를 읽어서 다음 문자를 읽을 준비가 되도록 합니다.

9-12: 'B' 일 경우에는 상태만 계속 옮겨가면서 검사를 하게 됩니다.

14-17: 'B', 'H' 가 아닌 경우에는 다음에 <Slump>가 오게 되는 지 검사하게 됩니다. 이러한 과정들은 당연히 [그림 1]에 표시된 그대로 입니다. 3:에서 Next를 해서 문자를 읽어 버리면, IsSlump가 한 자를 생략한 채로 검사하게 되기 때문에 Peek(1)로 훔쳐보기만 한 것 입니다. 다음에 <Slump>가 오지 않는 다면 에러입니다.

다른 모든 상태에 대해서도 원리는 같습니다.

이처럼 상태도를 이용해서 State Pattern을 사용하다보면 전체의 줄거리와 각각의 구현이 완전히 분리가 되어 개발이 한층 쉬워지는 것을 알 수가 있습니다. 사실 이 문제 정도의 복잡도라면 State Pattern을 사용하지 않고 재귀 호출만으로도 쉽게 구현되기는 하지만, 코드의 가독성은 State Pattern이 훨씬 앞선다고 생각합니다.

언제가 될 지, 프로젝트가 한가해지면 그 동안 공부했었던 컴파일러 제작에 대한 강좌를 하고 싶지만, 잘 안되네요 ^^;

아래 첨부는 소스 전체와 사용된 비지오 파일입니다. 샘플이 작아서 제대로 동작하고 있는 지는 잘 모르겠습니다 ^^;

Slump Slimp Slurpy.7z

'프로젝트 > 컴파일러' 카테고리의 다른 글

Slump Slimp Slurpy (0)	2012/04/25
파싱 과정을 표기해 보자 (1)	2010/11/10
프로젝트 개요 - 컴파일러 제작 (0)	2010/11/10
계산기용 스캐너 만들기 - State Pattern (1)	2010/11/04
계산기용 스캐너 만들기 - Lex 편 (0)	2010/11/01
계산기 (0)	2010/10/27

TED - 8가지 성공의 비결

류종택 — Tue, 24 Apr 2012 14:43:32 +0900

Passion, Work, Good, Focus, Push, Serve, Ideas, Persist

열정, 노력, 잘하는 것을 만들어라, 집중, 의지, 다른이가 필요한 것을 줘라, 아이디어, 인내

http://www.ted.com/talks/lang/ko/richard_st_john_s_8_secrets_of_success.html

아래 대사가 귀에 들어오네요 ㅋㅋ

"It's not always easy to push yourself, and that's why they invented mothers."

'etc' 카테고리의 다른 글

New Rally X - BGM (0)	16:55:28
TED - 8가지 성공의 비결 (0)	2012/04/24
Use the Magic Trackpad with your Windows PC (0)	2012/03/06
Tron 게임 (0)	2012/02/17
퍼포먼스를 위한 발악 (2)	2012/02/11
LED Display (0)	2012/01/18

MemoryPool

류종택 — Mon, 09 Apr 2012 15:59:05 +0900

GetMem와 FreeMem 대신 사용할 수 있는 메모리 풀 유닛입니다. [그림 1]과 같이 15배 이상의 속도 차이를 보이고 있습니다. 상황에 따라서 더 차이가 날 수도 있고 줄어 들 수도 있습니다. 멀티미디어 및 대용량 소켓 작성 때, 조금이라도 성능을 짜내기 위해서 사용하던 것인데, 조금 다듬어서 RyuLib에 포함 했습니다.

16KB 이상의 메모리 생성 및 해제는 풀을 사용하지 않고 바로 생성 및 삭제하도록 되어 있습니다. 또한, 메모리 풀의 한계를 지정하지 않아서, 메모리를 모두 잠식할 수도 있습니다.

"RyuLib for Delphi" 소스는 아래의 "http://ryulib.tistory.com/notice/11"에서 받으시기 바랍니다.

[그림 1] 실행 결과

사용법은 위의 소스 저장소에서 "/XE2/Samples/MemoryPool"를 참고하시기 바랍니다. [소스 1]은 해당 샘플의 메인 유닛입니다.

TMemoryPool.GetMem()의 리턴 값인 TMemoryPage가 실제 할당받은 메모리 객체입니다. TMemoryPage.Data 포인터가 할당 받은 메모리의 주소, TMemoryPage.Size가 할당 받은 크기 입니다.

[소스 1] 사용법

unit _fmMain;

interface

uses
  MemoryPool,
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TfmMain = class(TForm)
    moMsg: TMemo;
    procedure FormCreate(Sender: TObject);
  private
    FList : TList;
    FMemoryPool : TMemoryPool;
    procedure do_SystemTest;
    procedure do_MemoryPoolTest;
  public
  end;

var
  fmMain: TfmMain;

implementation

{$R *.dfm}

procedure TfmMain.do_SystemTest;
var
  Loop1, Loop2 : Integer;
  Tick : cardinal;
  Data : pointer;
begin
  RandSeed := 0;

  Tick := GetTickCount;

  for Loop2 := 1 to 10000 do begin
    for Loop1 := 1 to 1000 do begin
      GetMem(Data, Random(16 * 1024));
      FList.Add(Data);
    end;

    for Loop1 := 0 to FList.Count-1 do FreeMem(FList[Loop1]);
    FList.Clear;
  end;

  moMsg.Lines.Add(Format('System.GetMem: %d ms', [GetTickCount-Tick]));
end;

procedure TfmMain.do_MemoryPoolTest;
var
  Loop1, Loop2 : Integer;
  Tick : cardinal;
  Page : TMemoryPage;
begin
  RandSeed := 0;

  Tick := GetTickCount;
  for Loop2 := 1 to 10000 do begin
    for Loop1 := 1 to 1000 do begin
      Page := FMemoryPool.GetMem(Random(16 * 1024));
      FList.Add(Page);
    end;

    for Loop1 := 0 to FList.Count-1 do FMemoryPool.FreeMem(TMemoryPage(FList[Loop1]));
    FList.Clear;
  end;

  moMsg.Lines.Add(Format('MemoryPool.GetMem: %d ms', [GetTickCount-Tick]));
end;

procedure TfmMain.FormCreate(Sender: TObject);
begin
//  IsMultiThread := true;
  FList := TList.Create;
  FMemoryPool := TMemoryPool.Create;

  do_SystemTest;
  do_MemoryPoolTest;
end;

end.

'RyuLib > RyuLib for Delphi' 카테고리의 다른 글

MemoryPool (0)	2012/04/09
ThreadPool (0)	2012/01/18
ObserverList (0)	2010/12/13

MEncoder MinGW 빌드

류종택 — Tue, 03 Apr 2012 22:14:23 +0900

2012년 4월 03일 현재 MPlayer(MEncoder) 소스를 SVN에서 받고 필요한 라이브러리들을 모두 설치한 결과 대부분은 문제 없이 바로 빌드가 됩니다. 하지만 몇 가지 주의할 점이 있습니다.

FreeType의 라이브러리의 버전이 너무 높으면 libass에서 문제가 된다. libass 빌드에서는 문제 없으나, MEncoder 빌드 할 때 libass 소스에서 문제가 된다. 2.2.1 버전부터 빌드가 진행된다.
pkg-config-0.26 대신 pkg-config-0.25을 사용하였다. pkg-config-0.26 설치가 잘 안된다.
맥북 프로에서 부트캠프로 Win7을 띄워서 빌드에 성공하고 사용하는데 지장이 없었으나, 다른 PC에서 실행할 수 없는 문제가 발생한다. CPU 특성 때문인 것으로 보인다. 빌드할 때, 옵션으로 처리할 수도 있으나, 그냥 일반 PC에서 빌드하면, 맥북에서도 잘 돌아간다. (configure 실행 할 때, 자동으로 인식하기 때문)
x264와 faac 등을 포함 시킬 때 make 중간에 에러가 발생한다. "gcc -o mencoder.exe...." 를 하다가 중단되는데, 본인은 해당 부분을 수동으로 작성했다. 문제는 "-lx264 -lfaac" 가 포함되지 않았기 때문이다.

현재 설치된 라이브러리들의 버전은 아래와 같습니다. 버전이 표기 안된 것은 현재 날짜로 구할 수 있는 최신 버전입니다. MEncoder에서 사용하지 않고 있는 것도 있습니다.

faac
faad2
fontconfig-2.9.0
freetype-2.4.6
fribidi-0.19.2
glib-2.28.1
lame-3.98.4
liba52
libass-0.10.0
libogg-1.3.0
libtheora-1.1.1
libvorbis-1.3.2
libvpx
libxml2-2.7.8
pkg-config-0.25
x264-122
xvidcore
zlib-1.2.5

무엇인가 빠트린 것이 있는 것 같지만, 나중에 또 여유가 나면 정리하도록 하겠습니다.

'프로그래밍 > MinGW' 카테고리의 다른 글

MEncoder MinGW 빌드 (0)	2012/04/03
MinGW 64 비트 윈도우 실행 파일 빌드 (0)	2012/01/20
MinGW에서 liba52 build (0)	2012/01/14
MinGW에서 libfaac 설치 (0)	2012/01/13
Install libogg, libvorbis and libtheora with MinGW (0)	2011/11/04
MinGW 설치하기 (0)	2011/08/05

비트 모아 기가 바이트

류종택 — Mon, 26 Mar 2012 12:11:30 +0900

통신 등에서는 조그만 데이터의 차이가 계속 쌓이면서 큰 차이를 만드는 경우가 종종 있습니다. 이런 경우 사용 할 수 있는 간단한 트릭을 소개하도록 하겠습니다.

우선 아래와 같이 불린을 구조체로 묶어서 보내는 경우를 생각해보겠습니다.

[소스1]

type
  TPacket = packed record
    Data1 : boolean;
    Data2 : boolean;
    Data3 : boolean;
  end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Caption := IntToStr(SizeOf(TPacket));
end;

버턴을 클릭해보면 당연히 3바이트 크기임을 알 수가 있습니다. 하지만, true/false의 상태를 가지고 있기 때문에 1 바이트에 8개의 불린을 처리할 수가 있기 때문에 아래와 같이 표현 할 수 있습니다.

[소스 2]

type
  TPacket = packed record
    Data : byte;
  end;

function GetData(APacket:TPacket; AIndex:integer):boolean;
var
  BitMask : byte;
begin
  BitMask := 1;
  BitMask := BitMask shl AIndex;
  Result := (APacket.Data and BitMask) = BitMask;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Caption := IntToStr(SizeOf(TPacket));
end;

이제 구조체의 크기는 1바이트로 줄었고, 최대 8개까지 불린 변수를 사용할 수 있게되었습니다. SetData 함수는 일단 미뤄두기로 하겠습니다.

이제 이 넘을 좀 더 세련되게 바꿔 보도록 하겠습니다. 구조체에 메소드를 추가하는 것이 델파이 어느 버전에서부터인지 기억지 잘 안나는 군요. 오래된 버전을 사용하시는 분들은 "packed record"를 "object"로 바꿔서 사용하시기 바랍니다. 제가 도스 시절에 주로 사용하던 방법입니다. 구조체에 메소드를 추가한 타입이라고 생각하시면 됩니다. 다만, [소스 3]의 예제대로 사용하기에는 몇 가지 제약 사항이 있습니다.

[소스 3]

type
  TPacket = packed record
  private
    FData : byte;
    function GetBooleans(AIndex: integer): boolean;
    procedure SetBooleans(AIndex: integer; const Value: boolean);
  public
    property Booleans[AIndex:integer] : boolean read GetBooleans write SetBooleans;
  end;

{ TPacket }

function TPacket.GetBooleans(AIndex: integer): boolean;
var
  BitMask : byte;
begin
  BitMask := 1;
  BitMask := BitMask shl AIndex;
  Result := (FData and BitMask) = BitMask;
end;

procedure TPacket.SetBooleans(AIndex: integer; const Value: boolean);
var
  BitMask : byte;
begin
  BitMask := 1;
  BitMask := BitMask shl AIndex;

  if Value then FData := FData or BitMask
  else FData := FData and (not BitMask);
end;

이제 데이터를 보관하는 변수를 캡슐화해서 안전하게 보관하였고, property를 통해서 필요한 인터페이스만 제공하도록 하였습니다. 그리고, 여전히 구조체의 크기는 1 바이트이기 때문에 해당 구조체를 소켓 등으로 주고 받는데에도 문제가 없습니다.

저는 표현 범위가 byte, word, integer 등의 제한 범위 내에서만 사용 되면서 데이터의 크기를 줄여야 할 경우에 가끔 사용하는 방식입니다. 예를 들어 32 개수 미만의 열거형과 512 미만의 정수를 사용한다면, word 안에 집어 넣고도 몇 비트가 남게 될 것 입니다.

[소스 4]는 제가 실무에서 사용했던 예 입니다. word의 맨 앞의 비트는 불린 변수로 사용하고, 나머지는 정수 형태의 변수로 사용하고 있습니다.

[소스 4]

type
  THeader = packed record
  private
    FIndex : word;
    function GetHasKey: boolean;
    procedure SetHasKey(const Value: boolean);
    procedure SetFrameIndex(const Value: word);
    function GetFrameIndex: word;
  public
    property HasKey : boolean read GetHasKey write SetHasKey;
    property FrameIndex : word read GetFrameIndex write SetFrameIndex;
  end;

function THeader.GetFrameIndex: word;
begin
  Result := FIndex and $7FFF;
end;

function THeader.GetHasKey: boolean;
begin
  Result := (FIndex and $8000) = $8000;
end;

procedure THeader.SetFrameIndex(const Value: word);
begin
  FIndex := (FIndex and $8000) or Value;
end;

procedure THeader.SetHasKey(const Value: boolean);
begin
  if value then
    FIndex := FIndex or $8000
  else
    FIndex := FIndex and $7FFF;
end;

'프로그래밍 > Delphi' 카테고리의 다른 글

Record vs Object (0)	2012/04/27
비트 모아 기가 바이트 (3)	2012/03/26
변칙으로 사용하는 TDD (0)	2011/07/01
2008.03.29 - Flex & Delphi : 채팅 프로그램 만들기 (2)	2011/06/02
Twitter API를 이용하여 메시지 전송하기 (4)	2011/01/07
메소드 또는 함수의 interface 부분이 자주 변할 때 (2)	2010/12/16

기초 분석 결과 보고서

류종택 — Thu, 22 Mar 2012 11:51:13 +0900

이번에 소개할 것은 제가 프리랜서로 프로젝트를 맡을 때 제일 처음 고객에게 보고하는 문서입니다. 학생 때부터 학교는 안가고 사업의 길에 뛰어 든 탓에 경력이 20년이 훌쩍 넘어 버렸고, 그 기간 동안 수 없이 수정 보안을 거쳤는데도 형편 없습니다. 초기의 복잡했던 형식에서 지속적으로 탈피해서 정말 필요하다는 것 이외에는 모두 간소화 하였습니다. 아무런 준비가 없는 분들에게 조금이라도 도움이 되길 바라며, 좋은 의견이 있으면 공유해 주셨으면 합니다.

저의 초기 문서 작업 형태는 제 동영상 강좌에 있습니다. 이 시기에는 도표를 남발하고, 규격화된 모양새를 갖추기 위해서 애를 썼었습니다. 지금은 문서를 꾸미기 보다, 쉽게 작성하고 눈에 들어오도록 간결화 하고 있습니다.

기초 분석 결과 보고서를 작성하는 이유는 고객의 의뢰를 수행하는데 "기간"이 얼마나 걸리며, 어느 정도의 "비용"이 필요한 지를 알리는 것 입니다. 그리고, 고객에게 이러한 예측이 얼마나 엉터리며, 프로젝트를 성공적으로 이끌기 위해서 서로 어떠한 협력과 원칙을 가지고 프로젝트에 임해야하는 지를 알리는 것이 가장 중요한 목표입니다.

FF-Server.pdf

EncodingServer.pdf

사실 정확하게 정해진 형식을 따르지 않기 때문에 프로젝트 또는 의뢰자의 상황에 따라 내용이 크게 달라집니다. 하지만, 꼭 지키는 몇 가지 원칙이 있습니다.

결론부터 작성한다.
기능위주의 요구사항을 정리한다.
비기능 요구사항 및 기타 중요한 이슈는 "주요 이슈"로 묶어서 정리한다.
일정 예측은 왜 엉터리가 될 수 밖에 없는 지 설명하고, 어떻게 대체해야 하는 지를 고객에게 설득한다.

결론부터 작성한다
모든 보고서는 결론이 우선되어야 합니다. 기승전결은 흥미로운 소설을 읽을 때나 효과적이지, 보고서는 보고서의 목적이 무엇인지 핵심을 먼저 파악하고 상세한 내용을 읽어 갈 수 있도록 배려 해야 합니다.

제일 골치 아픈 일정 예측
개발 의뢰를 맡을 때 가장 힘든 경우는 바로 고객이 밑도 끝도 없이 "얼마나 걸려요? 얼마면 되요?""라고 물어보는 경우입니다. 소프트웨어는 무형의 제품이기 때문에 아무리 노력해도 정확한 요구 수준을 파악하기는 어렵습니다.

기간과 비용은 정확하게 예측 할 수 없습니다. 언제 단 한 번이라도 프로젝트가 예상대로 끝난 적이 있었습니까? 따라서, 개발을 진행하는 동안 예측이 얼마나 지켜졌는 지 또는 벗어났는 지를 보고하고, 심각한 경우 원인과 함께 대안을 제시합니다
"우리의 요구사항은 이게 전부에요!", "우리의 요구사항은 정말 간단해요!", "바뀌더라도 상식적인 범위를 벗어나지 않을 겁니다" 이렇게 도발하는 고객을, 근거와 함께 논리적으로 설득할 수 있어야 합니다.
개발해야 할 시스템이 제공해야 할 기능 목록이 준비되어야 합니다.
필수 비기능 요구사항들이 빠짐없이 분석되어야 합니다.
요구사항이 변하면 비용과 기간이 증가하거나 덜 중요한 요구사항을 포기해야 합니다.

우리의 요구사항은 이게 전부에요

고객이 생각하지 못한 배경조건을 찾아내거나, 필요할 거 같지만 요구되지 않은 기능을 찾아낸다.
유사한 또는 보다 좋은 조건 그리고 좀 더 큰 기업의 의뢰에서 조차 초기 요구사항은 항상 변한다는 것을 증거로 제시한다.
고객에게는 당연하지만 전혀 경험이 없는 외부인에게는 생소한 것들이 걸림돌이 된다는 점을 인지시킨다. 예를 들어 외국인들이 문화적 차이 때문에 황당한 상황에 빠지는 것에 비유한다. 개발자는 고객에게 외국인이 아니라 외계인임을 잊지 않도록 한다.

요구사항이 바뀌더라도 상식적인 범위를 벗어나지 않을 겁니다
고려된 적 없는 상식을 소프트웨어가 받아주지 않습니다. 상식이라고 할 수 있는 요구사항도 분석되지 않은 것들은 프로젝트를 위험에 빠트리게 됩니다.

집을 지을 때, 전등 정도를 다른 것으로 바꿔 다는 것은 그렇게 어렵지 않을 수 있지만, 크게 문제될 거 같지 않은 던 파이프 하나를 빼트려 먹으면 콘크리트를 허물고 다시 뭍어야 합니다. 이미 굳어 버린 콘크리트 속에 파이프를 집어 넣을 수는 없습니다.

마찬가지로 요구사항 자체의 중요도와 상관없이, 변화된 요구사항이 프로그램의 내부에 배치되어 있다면, 프로젝트 전체를 위협하게 됩니다. 간단한 문제지만 간단하게 처리할 수 없는 것들은 항상 발생합니다.

일단 러프하게 좀 알려주세요
절대 안됩니다. 그것은 눈 감고 그림이 대충 얼마나 아름다운지 알려달라는 것과 같습니다. 저는 "기초 분석 결과 보고서"를 작성할 수 있을 정도의 활동 이전에는 대충이라도 비용이나 기간을 알려드리지 않습니다. 가방 하나 사려고 해도 수 천원에서 수 백만원이 넘는 것들이 있듯이, 프로젝트 개발의 비용과 기간은 전적으로 고객님의 요구사항에 달려 있습니다.

그리고, 일단 얼굴 도장을 찍고, 고객에게 호객 행위를 할 수 있는 기회를 놓쳐서는 안됩니다 ㅡ.ㅡ;;

끝으로
하고 싶은 말은 정말 많았지만, 바쁜 일정 속에 살다보니 두서 없는 글이 되어 버려 아쉽습니다. "시작은 반이다"라는 말처럼 처음 활동이 상당히 중요하긴 합니다. 그러나, 맡은 프로젝트를 끝까지 책임지고 완수하는 것만큼 중요한 것은 없습니다. 그러다 보면, 단골 고객이 생기고, 고객이 고객을 소개시켜주기 시작합니다. 시간이 흘러도 단골이 생기지 않고, 고객이 고객을 소개 시켜주지 않으면 자신에게 정말 심각한 문제가 있다는 것을 알아야 합니다.

'소프트웨어 공학 > Method-R' 카테고리의 다른 글

기초 분석 결과 보고서 (1)	2012/03/22
기초 분석 결과 보고 (4)	2011/11/25
분할 정복에 대한 예제 #1 (5)	2011/07/05
동영상 플래이어 만들기 #1 (0)	2010/09/12
Quick Snap Framework 소개 (3)	2010/09/01
Database Application 구축 프로세스 (0)	2010/08/19

미디어 서버 구축 프로젝트

류종택 — Wed, 29 Feb 2012 06:17:25 +0900

서버: 델파이
클라이언트: "안드로이드 + ffmpeg" or "MS-Windows + ffmpeg"

어제 1차 개발일정을 마치고 프로젝트를 간략하게 정리해 봅니다. 모든 프로젝트를 정리해야지 하면서도 잘 안되는 군요 ^^;

이미 상용 미디어 서버가 시장을 장악한 상황에서 미디어 서버를 직접 개발하게 된 이유는 다음과 같습니다.

실시간 방송 중 광고 송출
VOD 방송 중 배속 재생 등을 지원하는 미디어 서버 및 클라이언트 개발
VOD 방송 중 광고 송출
통신사에서 RTSP를 막아버리고 있는 가 봅니다. 이것도 하나의 개발 이유

제 다른 포스트에서도 썼던 기억이 있지만, 현재 미디어 서버에서 제공하는 배속은 제약사항 때문에 고객의 니즈를 만족시키지 못하여, 직접 제작을 의뢰 받아서 제작 중 입니다.

아래는 실시간 방송 모듈 테스트 화면, 의뢰 받은 XX일보의 실시간 골프 방송입니다. 원본 영상의 해상도는 640*480 입니다.

서버의 Class Diagram

[그림 1]

FFServer: 미디어 서버 클래스
FFConnection: 사용자의 컨넥션을 관리
MediaSourceList: 미디어서버를 통해 배포할 동영상의 소스
PackageBuffer: 동영상의 프레임 정보를 묶어서 관리
Package: 프레임의 묶음
기타 클래스는 도면에서 생략하였음

클라이언트의 Class Diagram

[그림 2]

FFClient: 미디어 서버에 접속하여 동영상을 재상하는 클래스
State관련 클래스들: 클라이언트의 State Diagram 참고
StreamPlayer: 서버로부터 전송 받은 동영상 정보를 재생하는 클래스
기타 클래스는 도면에서 생략하였음

클라이언트의 State Diagram

[그림 3]

스마트폰의 특성상 네트워크가 불안정해질 수 있기 때문에 의도하지 않게 접속이 끊어졌을 경우에는 재접속하여 재생을 계속 이어가도록 했습니다.

'프로젝트 > 기타 프로젝트' 카테고리의 다른 글

미디어 서버 구축 프로젝트 (0)	2012/02/29

Tron 게임

류종택 — Fri, 17 Feb 2012 07:26:24 +0900

초등학교 때였던가? 이게 영화가 있는 것도 모르고, 게임에 빠져들었던 적이 있었는데, PC에서 실행할 수 있는 프로그램이 있어서 올려봅니다.

Tron.zip

기억이 참 새롭네요 ^^*

'etc' 카테고리의 다른 글

TED - 8가지 성공의 비결 (0)	2012/04/24
Use the Magic Trackpad with your Windows PC (0)	2012/03/06
Tron 게임 (0)	2012/02/17
퍼포먼스를 위한 발악 (2)	2012/02/11
LED Display (0)	2012/01/18
SoundTouch 버그 수정 (0)	2012/01/18

퍼포먼스를 위한 발악

류종택 — Sat, 11 Feb 2012 23:52:25 +0900

오래 전부터 습관이 된 탓에 and 조건을 분별할 때에는 항상 확률이 낮은 것부터 나열하도록 신경을 쓰고 있었습니다. 그러다가, 요즘 PC에서 그런 것이 과연 얼마나 퍼포먼스 향상에 도움이 될 까 궁굼해 졌습니다. 바로 테스트에 들어 갔습니다.

[소스 1]

procedure TForm1.Button1Click(Sender: TObject);
var
  Tick : Cardinal;
  Loop, a, b : integer;
begin
  Tick := GetTickCount;

  for Loop := 1 to 100000000 do begin
      a := Random(2);
      b := Random(100);
//      if (a = 1) and (b = 1) then Tag := Tag + 1;
      if (b = 1) and (a = 1) then Tag := Tag + 1;
  end;

  Caption := IntToStr(GetTickCount - Tick);
end;

11: 라인과 12: 라인이 오늘의 주인공입니다. 결과적으로 똑같은 두 문장의 속도 차이는 아래와 같습니다.

11: 라인 평균 1200 ms 정도
12: 라인 평균 730 ms 정도

and 문장에서는 앞에서 false가 판별되었을 경우 다음 조건을 검사하지 않기 때문에 확률이 낮은 것을 먼저 분별하면 성능에 도움이 됩니다. or 에서는 반대로 확률이 높은 것부터 나열하는 것이 조금이나마 이득이 됩니다.

근래에는 PC의 성능이 워낙에 좋아졌기 때문에 일반적인 경우 퍼포먼스에 대한 고민을 많이 할 필요가 없었졌습니다. 하지만, 스마트폰, 게임 및 증권 시스템 트레이딩과 같이 반복 계산이 많은 프로젝트 등에서는 이런 작은 차이들이 엄청난 결과를 만들어 내기도 합니다.

그렇긴 해도 반복 횟수를 감안하면 상당한 뻘짓이네요 ^^;

'etc' 카테고리의 다른 글

Use the Magic Trackpad with your Windows PC (0)	2012/03/06
Tron 게임 (0)	2012/02/17
퍼포먼스를 위한 발악 (2)	2012/02/11
LED Display (0)	2012/01/18
SoundTouch 버그 수정 (0)	2012/01/18
아들 넘의 첫 번 째 게임 - 홀짝 맞추기 (0)	2012/01/17