Kenny's Playground |

올림푸스 Olympus E-P1

2009/06/16 20:24 in Photo | Tags: E-P1, olympus, pen

기업도 일반 개인과 같이 바꿀 수 없는 유전자를 가지고 있는 것일까. 예를 들어 개발툴 업계라면 MS는 새로운 제품에 꼭 베이직을 끼워 넣고 볼랜드는 항상 파스칼이었다. DSLR에서라면 펜탁스(Pentax)는 항상 단순한 인터페이스를 추구했고 미놀타는 그 반대였다. 반면, 올림푸스는 항상 파격을 추구했던 업체이다. 예를 들어 올림푸스의 Pen-F 시리즈는 필름 한 컷에 2 장의 사진을 찍을 수 있는 포러 미러 메커니즘을 사용한 요상한 녀석이었고 SLR이면서도 매우 소형이었다. 가끔 볼 수 있는 유진 스미스가 담배 피는 모습이 담긴 광고는 인상적이었고 말이다. 어쨌든 필름 카메라 역사에서 Pen-F는 매우 성공적이고도 독창적인 모델이었고 올림푸스라는 이름을 사용자에게 각인 시켰다. 이베이 등을 뒤져보면 아직도 블랙모델 Pen-F는 매우 고가에 거래되고 있는 것을 발견할 수 있을 것이다.

이번에 발표된 올림푸스의 E-P1은 Pen-F 시리즈의 50주년 발매 기념이라나 머라나 해서 나온 새로운 개념의 바디이다. 마이크로 포서드 규격의 센스와 렌즈를 사용하여 DSL(미러가 없는 놈이라)치고는 획기적으로 작은 사이즈의 카메라를 내놓을 수 있게 된 것이다.

아무튼 이 이미지를 본 순간 한 눈에 뿅 가버렸다고나 할까. 오랜만에 참 아름답다라는 느낌을 가지게 하는 바디를 만난 것 같은 느낌이다. 혁신과 실용이 빚어낸 아주 멋진 녀석이라고 생각된다. 가격은 10만엔 ~ 13만엔 사이라고 하니 가격이 하락하기를 기다려 구매해볼 생각이다.

다음은 dpreview.com에서 퍼온 스펙.

-------------------------------------

Small & stylish design

Extremely small and light-weight Micro Four Thirds System
Stylish design with metal finish
Two colours

SLR image quality

12.3 Megapixel Live MOS Sensor
TruePic V image processor
Built-in IS with max. 4 EV steps efficiency
Adapter for all ZUIKO DIGITAL & OM lenses

Easy operation

New developed GUI for easiest operation via Live Control
Automatic recognition of common scenes possible with i-Auto
Clear skin with e-Portrait
Two dials for easy handling
Face Detection and Shadow Adjustment Technology
20 shooting modes (5 exposure modes, i-Auto mode, 14 scene modes)

Creativity and HD Movie

HD Movie with stereo sound featuring depth of field and Art Filters
Art Filters, Multi-Aspect ratios
Multi Exposure function
Art Filters can be applied to previously taken RAW images in the camera and with Olympus software
Enhanced creativity with special lenses e.g. fisheye is available via Four Thirds lens adapter

Additional features of the Olympus Pen:

HDMI TV interface
Linear PCM sound recording
Level gauge
Hi-Speed USB 2.0 interface
Three frames per second with sequential shooting (max 14 in RAW mode)
ISO 100-6400 for wide-ranging sensitivity
Versatile bracketing functions for white balance and exposure
Reliable Supersonic Wave Filter dust reduction system
Based on the Micro Four Thirds Standard
Wide dynamic range in highly lit areas
Simultaneous writing of RAW and JPEG
SD memory card (SDHC compatible)
High-speed data writing and lossless RAW compression for quick processing
Large 7.6cm/3.0” HyperCrystal LCD
AE/AF lock functionality for individual customisation
Auto gradation adjustment to prevent blown highlights and blocked-in shadows
Remote release possible via the optional remote cable RM-UC1

The Olympus Pen E-P1 is available in the following configurations:

E-P1 Kit Silver/Black
(E-P1 body silver & M. ZUIKO DIGITAL ED 14-42mm 1:3.5-5.6 lens black)
E-P1 Kit Silver/Silver
(E-P1 body silver & M. ZUIKO DIGITAL ED 14-42mm 1:3.5-5.6 lens silver)
E-P1 Kit White/Silver
(E-P1 body white & M. ZUIKO DIGITAL ED 14-42mm 1:3.5-5.6 lens silver)
E-P1 Pancake Kit Silver
(E-P1 body silver & M. ZUIKO DIGITAL 17mm 1:2.8 Pancake lens silver & VF-1)
E-P1 Pancake Kit White
(E-P1 body white & M. ZUIKO DIGITAL 17mm 1:2.8 Pancake lens silver & VF-1)
E-P1 Double Lens Kit
(E-P1 body silver & M. ZUIKO DIGITAL ED 14-42mm 1:3.5-5.6 lens black & M. ZUIKO DIGITAL 17mm 1:2.8 Pancake lens silver & VF-1)

New accessories:

M. ZUIKO DIGITAL ED 14-42mm 1:3.5-5.6 lens
M. ZUIKO DIGITAL 17mm 1:2.8 Pancake lens
MMF-1 adapter for all Four Thirds lenses
MF-2 adapter for all OM lenses
FL-14 flash
VF-1 external optical view finder
Leather strap in white and brown
Leather body jacket in white and brown

Trackback 1 | View Comment 0

RIA 아키텍처 - 단순 유연함이 필요하다.

2009/05/09 22:50 in Developement | Tags:

생각해보니 GS 프로젝트 이후로 근래 한 5년은 RIA 애플리케이션만 개발하고 있다. BackOffice 또는 정보계 쪽의 프로젝트가 많으니까 말이다. 하지만 돌이켜 보건데 만족스러운 적이 별로 없었던 것 같다. 처음에는 그것이 프레임워크나 툴의 문제로만 생각되었지만 RIA의 원격 호출이 가지는 태생적인 문제점이라는 것도 조금은 이해할 수 있다. 하지만 이토록 문제가 많다는 것은 무엇인가 잘못되었다는 것을 의미한다. 근본적으로 무엇이 잘못된 것일까...

1. RIA와 서버 연동을 위한 툴이나 라이브러리의 부족
어느 정도 사실이다. J2EE, SOA, AMF 어느 것도 인터페이스를 위한 많은 작업들을 제거해주지는 못했다. 좋은 언어, 고수준의 프레임워크를 기반으로 하는 프로페셔널한 개발 툴이 필요하다. 아직은 엔터프라이즈 레벨에서 편하게 사용할 만한 개발 툴은 그다지 많지 않다.

2. iBatis 또는 원시적인 OR Mapper
추상화 수준이 낮은 이런 OR Mapper류는 전혀 개발자들의 노가다를 줄여주지 못했다. 작성하기 쉬운 것도 아니요 타입 검사가 되는 것도 아니고 디버깅이 쉬운 것도 아니다. 이것은 RDB를 사용하는 이상 완벽하게 없어지지는 않을 것이다.

3. 변화에 대한 둔감함
SI는 체질상 변화에 둔감하고 혁신을 받아들이기 어렵다. Agile 및 XP 방법론을 따르는 개발 환경의 설정, 개발 프로세스의 변경 등 작은 변화만 있었다고 하더라도 많은 프로젝트가 좀 더 좋은 결과를 얻을 수 있었을 것이다. 덧붙여 Spring, Hibernate와 같은 검증된 Open Source Framework의 도입도 그다지 많지 않다. RoR, GRails를 사용하는 프로젝트는 구경도 못해봤다.

4. 원칙 위주의 딱딱한 아키텍처
원칙만 가지고 하자면 RIA 아키텍처는 엄청나게 복잡해질 수 밖에 없는 것 같다. 분산에 원격 호출에 아주 돌아버린다. 예를 들어 RIA에서 DB의 결과를 바로 얻을 수 있는 간단한 프레임워크만 사용했더라도 노가다는 많이 줄었을 것이다.

이런 저런 생각을 하다 보니 Dynamic Typing의 개념이 우리 나라에서는 아주 잘 들어맞는 것 같은 생각을 한다. 예를 들어 Laf/J와 같이 실제적으로 Static Typing을 하지 않는(Hashmap과 같은 것을 Persistence에서 부터 사용한다, 필요하면 언제나 값을 추가한다) 프레임워크는 쉽고 간편하다. 대형 프로젝트에서는 그런 프레임워크는 디버깅하기 힘들고 에러가 많다는 것이 통설이지만 국내 여건에서는 그렇지가 않은 것이다. 예를 들어 DB에 변경이 있다고 하더라도 DAO 로직과 Presentation, 즉 끝 단만 수정하면 모든 것이 어느 정도 동작한다. 모호하지만 유연하기 때문이다. 반면에 정통적인 Framework는 DB를 바꾸면 DAO의 DTO부터 중간 과정에 있는 많은 것을 수정해야 한다. 과정 과정마다의 형 검사가 엄격하게 되기 때문이다. 프로젝트의 변경 사항이 잦은 환경에서는 엄청나게 치명적이다. 복잡한 + 잦은 변경 = 프로그래머의 지옥 이라는 공식이 여기 저기서 발견된다.

어쨌든... 좀 더 생각해보자. 유연한 언어, 유연한 프레임워크, 유연한 프로토콜... 이것이 정답일 수도 있다.

Trackback 1 | View Comment 1

Flex RIA 아키텍처 (Flex + Spring + iBatis)

2009/05/09 17:43 in Web Prog./Flex | Tags: architecture, Flex, iBATIS, RIA, Spring

Flex + Spring + iBatis Micro Architecture

Flex 개발자는 아니지만 최근 프로젝트는 계속 Flex를 사용한다. 이것을 조금 정리해본 것. 마음에 안 드는 점은 꽤 있다. Flex 애플리케이션은 화면 만들기는 쉽지만 이후 서비스 구현은 매우 복잡하다. 원격 호출이 들어가기 때문이다. 거기다가 Flex 단의 MVC 프레임워크까지 적용하면 개발자들은 매우 곤란해 한다.
덧붙여서 iBatis는 쓰면 쓸 수록 생산성 향상에 도움이 안되는 것을 느낄 수 있고. 완벽하게 제 역할을 해주는 것은 Spring 정도구나 하는 생각이 든다.

Flex RIA Architecture 개요#

다음은 일반적인 상황에서의 Flex RIA 아키텍처를 설명해둔 것이다. Flex는 RIA 플랫폼이기 때문에 기존 Web Application Architecture와는 조금 구조가 달라진다. 기본적으로 Presentation이 Flex로 완전히 옮겨가므로 Server단에서는 Presentation Framework가 필요하지 않고 Flex에서 그 역할을 대신해야 한다. Adobe에서 기본으로 제공하는 것은 Cairngorm Framework인데 아주 FM(?)과 같은 표준형의 프레임워크이지만 구조가 매우 복잡하다.

사용 Framework, Tools#

Presentation#

Flex 3.0.x
Cairngorm Framework(옵션)

Business#

Spring 2.5.x
BlazeDS
Flex Messaging

Persistence#

iBatis 2.3.x

etc#

Maven(옵션)
Ant(옵션)

기본 Architecture#

장점#

기존의 Web Application 아키텍처를 최소한으로만 수정한 구조이다. Gateway나 메시지 브로커 개념을 활용하면 비즈니스 로직을 건드리지 않고 Flex 뿐 아니라 WebService, REST와 같은 다양한 프로토콜을 지원할 수 있다.

Spring에서 Flex BlazeDS 연동을 지원하는 라이브러리가 있으므로 설정하기 쉬움
기존 Spring 프레임워크의 강점을 그대로 가져갈 수 있음
Business Logic을 변경하지 않고 Gateway 개념을 통해서 다양하게 서비스할 수 있음. 예를 들어 SOA, REST, RPC 등등.
Query, 비즈니스 로직이 그대로 서버에 있으므로 보안 문제에 있어서도 안전한 편

단점#

매우 복잡한 구조로 숙력된 개발자가 아니라면 생산성이 떨어질 수 있다. 특히, Flex Cairngorm 프레임워크는 너무 복잡하여 단순화한 방식으로 사용할 필요가 있다.

복잡한 구조
DB나 Business가 변경될 경우 수정해야 할 파일이 엄청나게 많다(10여개)
VO/DTO, SqlMap, DAO, Service Object, Service, Command 등등
작은 규모의 프로젝트를 하기에는 너무 무거움

기타#

보안에 민감하지 않은 애플리케이션인 경우 Business Logic이나 DAO 로직을 Flex로 옮기는 것이 도움이 될 수 있다.

Trackback 0 | View Comment 0

프로그래머는 작가와 같다.

2009/04/30 15:53 in Essay | Tags: programmer

개요#

긍지있는 프로그래머는 프로그래머를 소모품 취급하려는 시도에 대해서 어떻게 생각하고 있을까. 완전히 동의할 수는 없다고 하다러도 다음 글은 그에 대한 대답을 상당히 명확하게 들려주며 꽤나 새로운 시각을 제공한다.

잘은 모르지만 한 가지는 확실하다. 소트트웨어는 공장에서 만들어지지 않는다는 것.

Writing Software is Like Writing 프로그래밍은 글 쓰기와 같다 by Bruce Eckel April 21, 2009 - Artima Developer Blog

번역#

Writing Software is Like ... Writing

가끔 비유가 필요한 경우가 있다. 우리는 우리가 무엇을 하는지를 잘 알고 있다. 우리는 컴퓨터에게 일을 시킨다(Program). 그것이 할 수 있는 모든 것을. 그리고 우리는 그 일을 하기 때문에 그 일이 무엇을 의미하는지 잘 알고 있다.

그러나, 의사 결정권자 – 관리자, CEO, 고객, 이익 당사자, 등등 – 에게 소프트웨어 개발은 미스테리이다. 그들은 개발의 모든 것에 대해서 알고 싶어하지는 않지만 소프트웨어 개발을 대충이라도 예측할 수 있을 정도는 알고 싶어한다.

따라서 이해 당사자들에게 추상화(Abstraction)이 필요하다. 즉, 비유 말이다. 그러나 이러한 비유가 유용하기 위해서는 중요하지 않은 것을 숨기고 있는 그대로 보여주는 것이 필요하다. 우리는 오랫동안 이런 문제를 해결하지 못했고 언제나 우리의 언어로만 표현하였다. 그것은 우리들에게는 말이 되지만 우리는 유용한 비유나 그렇지 못한 것을 구별하지 못한다.

수학자나 엔지니어들이 초기의 프로그래머였기 때문에 우리는 자연스럽게 프로그래밍을 과학이나 엔지니어링으로 생각한다. 하지만 우리가 프로그래밍을 아무리 수학 공식이나 교량 건설과 같은 것으로 만들려고 해도 그렇게 되지 않는다.

이해 당사자들은 우리의 비유를 추종하며 그들이 관심 있는 것에 대해서 묻는다. “만약, 프로그램이 수학과 같은 것이라면 왜 항상 고장나는가? 수학은 옳거나 그러지만 소프트웨어는 단지 동작하지 않는다.” 그리고 나중에는 우리는 과학과의 비유를 포기한다. “만약 프로그램이 공학이라면 한 사람의 프로그래머를 다른 사람과 바꿔도 비슷한 결과를 얻어야 하는 것 아닌가?”

후자에 대해서는 이해 당사자들을 매우 놀라게 하는 원인이었다. 어쨌든 엔지니어들의생산성 수준은 비슷하다. 그리고, 최종적인 산출물도 검증이 가능하다. 엔지니어링에는 모순이 별로 없으며 따라서 “소프트웨어 엔지니어링”이라고 부를 수 있다면 비슷하게 모순이 없어야 한다.

이러한 문제에 대한 해결책으로는 두 가지 대표적인 접근 방법이 있다. 큰 부정(모든 차이를 부정하고 모든 소프트웨어 개발이 같은 척하기) 또는 작은 부정(이러한 차이는 우연한 것이고 모순은 제거할 수 있다)이다.

큰 부정은 전혀 들어맞지 않는다. 그러나 작은 부정은 계속적으로 “소프트웨어 엔지니어들의 표준화” 시도를 양산해 내었다. 대표적인 것이 자격증(certificaiton)이다. 만약 자격 검증 과정만 있다면 논란은 해소되고 소프트웨어 엔지니어 들은 진정한 엔지니어가 될 것이다. 그리고 그들 또한 모순이 없을 것이다.

다행히도 자격 검증은 한번도 제대로 된 적이 없다. 소프트웨어 개발자들이 그러한 것에 심각하게 신경 쓰지 않기 때문이다. 그리고 고용주들은 자격증이나 학위에 상관없이 가장 좋은 프로그래머들을 고용하기를 바라기 때문이다. 그리고 자격 검증 프로그램(기사 자격증, SCJP, OCP 등등)들은 언제나 돈을 벌기 위한 것이기 때문에 결국에는 시들해진다. 예를 들어서 나는 SCJP를 심각하게 고려하는 사람을 본 적이 없다. 좀 더 고수준의 자격증은 좀 더 재미있다. 하지만 그것들은 워크샵과 같아서 나에게는 시험처럼 느껴지지 않는다.

한 때 나는 모든 프로그래머들의 역할을 단순한 타이핑으로 제한함으로써 기계의 부속품과 같이 취급하려는 시도들을 조롱했다.

우리는 과학자가 아니며, 우리는 엔지니어가 아니다. 그렇다면 우리를 프로그래머가 아닌 사람에게 어떻게 설명해야 타당할 까? 어떻게 하면 프로그래머들과 프로젝트의 개개의 차이점과 프로젝트의 성패의 차이를 잘 설명할 수 있을까?

나는 이렇게 제안한다. 나는 이것이 모든 것을 설명할 수 있다고 생각한다. 비록 이것이 예측 가능한 행동을 바라며 한 프로그래머를 다른 프로그래머와 교체해도 동일한 결과를 얻기를 바라는 의사 결정권자들을 실망시킬 수 있지만 말이다. (이러한 작업들은 아직도 진행중이다. 예측 불가능 성을 보정하는 유일한 방법은 Agile 방법론 뿐이다. 이는 이해 당사자들과의 커뮤니케이션 대역폭(bandwidth)를 늘려준다.)

프로그래머는 작가와 같다.

... 이하 생략

Trackback 0 | View Comment 1

Scala Iterable 인터페이스 구현하기

2009/04/26 17:21 in Developement/Scala | Tags: Iterable, Iterator, scala

ArrayStack 개요#

Stack 구조체를 구현하고 테스트해본다.

* Princeton.edu ArrayStackOfString example

* See it in my wiki

소스#

ArrayStack

  case class ArrayStack[T](size: Int) extends Iterable[T] {
    // stack
    val stack : Array[T] = new Array[T](size);
    // number of items in stack
    var idx : Int = 0;
    
    //---------------------------------------- Stack Methods
    def push(item: T) = { stack(idx) = item ; idx += 1; }
    def pop() : T = { idx -= 1; stack(idx); }

    //---------------------------------------- Iterable Interface
    //* check if stack is empty
    override def isEmpty : Boolean = {idx <= 0; }

    //* return Iterator
    def elements : Iterator[T] = new Iterator[T]  {
      var i = idx - 1;
      override def hasNext:Boolean = { i >= 0; }
      override def next : T = { i -= 1; return stack(i+1); }
    }
    
    //* Apply a function f to all elements of this iterable object.
    override def foreach(f : T => Unit){
      var currentIndex = idx - 1;
      while(currentIndex >= 0){
        f(stack(currentIndex).asInstanceOf[T]);
        currentIndex -= 1;
      }
    }
  }

ArrayStackTester

object ArrayStackOfString extends Application {
  //--------------------------------------------- Main Method
  
  // create array stack
  val astack = new ArrayStack[String](100);
  Console.printf("> ArrayStack of Size %d created.\n\n", astack.size);
  
  // test stack
  def doStack {
    Console.readLine() match {
      case null => 
      case "" => Console.println("> Bye !!");
      case "-" if astack.isEmpty => Console.println("@@ Stack is Empty "); doStack;
      case "-" => Console.printf("> Poped : %s\n", astack.pop()); doStack;
        
      case item:String => {
        astack.push(item);
        Console.printf("> Pushed : %s \n", item);
        doStack;
      }                  
    }
  }
    
  doStack;  
  
  // printout stack
  Console.printf("> Stack dump\n");
  for(item <- astack) {
    Console.println(item);
  }
}

결과#

 ArrayStack of Size 100 created.

Array
> Pushed : Array 
Stack
> Pushed : Stack 
Of
> Pushed : Of 
String
> Pushed : String 
-
> Poped : String
-
> Poped : Of

> Bye !!
> Stack dump
Stack
Array

Trackback 0 | View Comment 0