Centos Server 리눅스 운영체제에서 likewise-open 패키지 설치 문제

당연히 Ubuntu에서 사용하던 Likewise-open 을 설치하여 제 집에서 운영하는 Active Directory에 Join하려고 했다. 원래 Ubuntu Server를 사용하다가 Redhat 계열의 Centos로 변경해보고자 Centos Server를 선택했다. 


필자의 아래의 블로그 링크를 통해 Ubuntu에서 Likewise-open을 통해 Active Directory에 Join 하는 글을 소개한 바 있다.

 

Centos에서는 RPM기반의 설치 패키지 도구인 yum을 사용하는데, yum을 통해서는 likewise-open 도구를 설치할 수 없는 문제가 발생하였다.

yum install likewise-open
MPOWERUMC:~ powerumc$ ssh POWERUMC\\umc@192.168.0.30
Password:
Last login: Fri Apr  5 01:35:17 2013 from 192.168.0.23
-sh-4.1$ sudo yum install likewise-open
Password:
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: mirror.yongbok.net
 * extras: mirror.yongbok.net
 * updates: mirror.yongbok.net
base                                                               | 3.7 kB     00:00
extras                                                             | 3.5 kB     00:00
updates                                                            | 3.5 kB     00:00
updates/primary_db                                                 | 1.4 MB     00:00
Setting up Install Process
No package likewise-open available.
Error: Nothing to do
-sh-4.1$

 

위와 같이 likewise-open 패키지는 사용할 수 없는 패키지라는 메시지가 출력이 된다. 이 문제로 구글링을 통해 해결 방법을 찾아보았는데, 대부분 과거 문서이고 likewise-open 다운로드 링크도 404 not found 로 생각보다 빨리 해결하지 못하게 되었다.

 

pbis-open 패키지로 설치해야...

현재 likewise-open 은 PowerBroker 서비스를 통해 다운로드 받을 수 있다. 패키지의 이름은 likewise-open에서 phis-open로 변경되었다.


다음과 같이 wget 명령을 통해 pbis-open 패키지를 다운로드 받는다.

wget 명령으로 패키지를 다운로드 받는다.
[powerumc@POWERUMC-CENTOS ~]$ wget http://download.beyondtrust.com/PBISO/7.1.0/1203/pbis-open-7.1.0.1203.linux.x86_64.rpm.sh
--2013-04-01 23:41:19--  http://download.beyondtrust.com/PBISO/7.1.0/1203/pbis-open-7.1.0.1203.linux.x86_64.rpm.sh
Resolving download.beyondtrust.com... 192.30.180.65
Connecting to download.beyondtrust.com|192.30.180.65|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17789736 (17M) [application/x-sh]
Saving to: `pbis-open-7.1.0.1203.linux.x86_64.rpm.sh'
 
 
100%[================================================>] 17,789,736  1.24M/s   in 16s
 
 
2013-04-01 23:41:36 (1.03 MB/s) - `pbis-open-7.1.0.1203.linux.x86_64.rpm.sh' saved [17789736/17789736]

 

 

다운로드 받은 패키지를 ls 명령을 통해 확인할 수 있다. (필자는 alias l="ls -al" 로 사용한다)
[powerumc@POWERUMC-CENTOS ~]$ l
합계 17400
drwx------. 2 powerumc powerumc     4096 2013-04-01 23:42 .
drwxr-xr-x. 4 root     root         4096 2013-04-01 23:08 ..
-rw-r--r--. 1 powerumc powerumc       18 2013-02-22 06:09 .bash_logout
-rw-r--r--. 1 powerumc powerumc      200 2013-04-01 23:42 .bash_profile
-rw-r--r--. 1 powerumc powerumc      124 2013-02-22 06:09 .bashrc
-rw-------. 1 powerumc powerumc      803 2013-04-01 23:42 .viminfo
-rwxrwxr-x. 1 powerumc powerumc 17789736 2013-03-09 05:53 pbis-open-7.1.0.1203.linux.x86_64.rpm.sh
[powerumc@POWERUMC-CENTOS ~]$ sudo ./pbis-open-7.1.0.1203.linux.x86_64.rpm.sh
Creating directory pbis-open-7.1.0.1203.linux.x86_64.rpm
Verifying archive integrity... All good.
Uncompressing pbis-open-7.1.0.1203.linux.x86_64.rpm............
Would you like to install package for legacy links? (i.e.  /opt/likewise/bin/lw-find-user-by-name -> /opt/pbis/bin/find-user-by-name) (yes/no) yes
Would you like to install now? (yes/no) y
Installing packages and old packages will be removed
준비 중...                   ########################################### [100%]
   1:pbis-open-upgrade      ########################################### [100%]
준비 중...                   ########################################### [100%]
   1:pbis-open              ########################################### [100%]
Setting up SELinux Policy Module
 
 
 
 
Importing registry...
 
 
 
 
준비 중...                   ########################################### [100%]
   1:pbis-open-gui          ########################################### [100%]
준비 중...                   ########################################### [100%]
   1:pbis-open-legacy       ########################################### [100%]
Installing Packages was successful
 
 
New libraries and configurations have been installed for PAM and NSS.
Please reboot so that all processes pick up the new versions.
 
 
As root, run domainjoin-gui or domainjoin-cli to join a domain so you can log on
with Active Directory credentials. Example:
domainjoin-cli join MYDOMAIN.COM MyJoinAccount

 

 



 

다음과 같이 opis-open 서비스를 시작하면 된다.
[powerumc@POWERUMC-CENTOS init.d]$ sudo ./lwsmd start
 
 
자동으로 시작되어 있음

TV 프로에서 어떤 조사를 통해 재미있는 사실이 밝혀졌습니다.

페이스북 오래 하는 직원, 업무성과 더 높아

회사에서 페이스북... 대놓고 하기에도 그렇고, 숨어서 하기에도 그렇고...



맥에서 즐겨 사용하는 페이스북 알리미 프로그램이 Shareware로 자꾸 돈내라고 팝업이 뜬다.
$2.99 짜리 맥OS 앱인데, 결제를 하려다가 주말을 이용해 그냥 만들어 보기로 했습니다.

 

아직 초라한 0.1 버전이므로 감안하고 사용하길 바랄뿐입니다. ^^;
차후 업그레이드를 해야 하는 사명감이 좀 더 생기면 버전업을 할 예정입니다.

(Mac OS, Linux 배포 패키지가 완성되면 다운로드 링크에 추가하겠슴돠)


 

 

  Facebook Tray v0.1 

 

다운로드 링크 (SkyDrive)

https://skydrive.live.com/redir?resid=8B8DDD0D9FFC25E1!5800&authkey=!APgYk8Dtt5YV3r4

 

스크린 샷

 

 

지원 운영체제

  • Windows
  • Mac OS
  • Linux

 

특징

  • 트레이 아이콘에서 페이스북의 새로운 알람 개수 표시
  • 네트워크를 통한 페이스북 API 없이 실시간 알람
  • 모바일 화면의 페이스북 윈도우 제공
  • 외부 링크는 데스크탑 브라우저와 연결
  • 내부 링크는 FacebookTray 내부 브라우저와 연결
  • 여러 운영체제 지원


실행 방법

  • 윈도우
    기본 설치 경로인 윈도우 데스크탑에 FacebookTray 폴더의 FacebookTray.exe 를 실행
  • 맥 OS
    기본 설치 경로인 /Applications (응용프로그램)에서 FacebookTray.app 을 실행
  • 리눅스


설치되는 컴포넌트

  • 실행 파일
  • Qt Runtime (Qt Core/OpenGL/WebKit)
  • C++ 10.0 재배포(Redistributable) 패키지 (설치 안됨)
  • OpenSSL (설치 안됨)


발생 배경

Qt를 가장 잘 개발할 수 있는 개발 도구 Qt 개발 플랫폼인 Qt 5.0(Qt 5.0 / Qt Creator 2.6.2) 에서 QWebView 위젯을 제대로 link 및 include 할 수 없는 현상이 발생한다. 이전 환경에서는 물론 발생하지 않는, 이전 release에 보고된 버그이다. 

오류 유형은 일치하지 않으나 발생하는 환경은 유사하다고 볼 수 있다. widgets 모듈에 포함되었던 QWebView가 다른 모듈로 분리가 되었기 때문이다. 

:-1: error: symbol(s) not found for architecture x86_64

 

 

해결 방법

해결 방법은 의외로 간단하다. .pro 파일(qmake) 의 속성을 다음과 같이 추가한다.

QT      +=core gui webkitwidgets 


QT 속성은 qmake가 빌드할 때 사용하는 모듈을 지정하는 속성인데, link 또는 dll 개념과 유사하다고 보면 된다. 

그렇다면 정상적으로 다시 컴파일이 가능하고, Code Completion도 정상적으로 동작할 것이다. 아래는 간단한 샘플 소스 코드를 첨부한다.

.pro
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#-------------------------------------------------
#
# Project created by QtCreator 2013-03-11T20:44:09
#
#-------------------------------------------------
QT       += core gui webkitwidgets
 
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
 
TARGET = FacebookNotify
 
TEMPLATE = app
 
SOURCES += main.cpp\
        mainwindow.cpp
 
HEADERS  += mainwindow.h
FORMS    += mainwindow.ui
MainWindow.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QWebView>
  
MainWindow::MainWindow(QWidget*parent): QMainWindow(parent), ui(newUi::MainWindow)
{
    ui->setupUi(this);
  
    this->onLoad();
}
  
MainWindow::~MainWindow()
{
    delete ui;
}
  
voidMainWindow::onLoad()
{
    ui->webView->load(QUrl("http://blog.powerumc.kr"));
}

  1. 익명 2013.03.24 21:56

    비밀댓글입니다

  2. knocki 2013.06.14 17:03

    Qr Creator 2.7.0(32 bit) / Qt 5.0.2 / Windows 7 환경에서는 pro파일에 위의 옵션을 넣어주지 않아도 되네요.

    그런데 프로젝트를 생성할 때 "Qt Gui Application"으로 하면 안 되고 "HTML5 Application"으로 해야만 QWebView를 정상적으로 include하여서 실행이 되네요.

    혹시 두 프로젝트간의 차이점에 대해 아시나요?
    그리고 Qt Gui Application에서는 QWebView를 사용할 수 없을까요?



다크 엘프 추방자








악마 사냥꾼









방랑하는 암살자





원소의 군주









파멸의 전령
















불편한 매킨토시(Macintosh), 맥북에어를 사용하면서 좌충우돌

애플의 맥킨토시(Macintosh) 제품을 이용하면서 많은 사람들이 기존의 익숙함과 다른 인터페이스 환경 때문에 불편하다는 이야기를 한다. 필자도 카페베네 커피숍을 자주 가는데 대부분 그곳에 iMac 제품이 있는데, 한번씩 써보면 도대체 왜 이런 기계를 쓸까라는 생각을 할 만큼 불편했었다. 네이버 중고나라에서 맥북을 파는 사람들을 보면 이따금 '저랑 안맞는 것 같아서 팔아요' 라는 분들도 계실 정도다.


무엇이 맥킨토시 제품을 사용하는데 불편하게 만들까?

간단하게 필자의 생각을 요약해 보았다. 온전히 필자의 주관적인 기준이다. 불편한 점이 좀 유치하긴 하지만 처음 접해보는 맥킨토시 제품인지라 감각적인 디자인에 만족하면서도 막상 사소한 것에 불편함을 느꼈다.


  • 트랙패드
    필자의 맥북에어에 붙어있는 트랙패드가 상당히 불편했다. 마우스 좌/우 버튼 조작이 어색해서 브라우저에서 스크롤을 하는 것이 여건 귀찮은게 아니었다.
  • 화면 인터페이스
    왜 윈도우 창의 버튼이 좌측이 몰려있나. 우측으로 옮길 수 없을까? 윈도우에 익숙해진 탓에 창 버튼이 좌측에 몰린 것이 거슬린다.

  • 뭘 해야 할지 모르는 산만함
    OSX(오에스 텐)의 상단에 상태바에 메뉴가 있다. 그리고 하단에 커다란 아이콘이 있다. 보이지 않는 설치된 응용 프로그램들을 어디서 찾아야 하지?

맥킨토시(Macintosh) 초보 탈출

이 외에도 사소한 것들이 더 많았던 것 같았다. 그래서 약 이틀 정도 사용법에 익숙해지기 위해 검색하고 찾아보면서 '완전한 초보자를 위한 몇 가지 가이드'를 제시하고자 한다.


지금까지 약 2주정도 맥북에어를 사용해 보니, 오히려 원도우가 더 답답하게 느껴질 정도로 맥킨토시의 운영체제는 직관성있고 매우 편리하다. 맥킨토시의 매력은 아마 각자가 찾아야 하지 않을까 생각한다. 적어도 맥이 더이상 불편하다는 생각은 말끔히 사라질 것이다.



OSX 환경 설정

OSX 운영체제의 환경을 설정하는 것만으로 효과를 톡톡히 볼 수 있다. 마치 윈도우를 처음 설치하면 자기 입맛에 맞게 바탕화면이나 키보드 눌림 스피드나 마우스 포인터 속도를 자신에게 맞추는 작업이라고 생각하면 된다.

여기에 나열되는 설정은 좌측 상단의 '사과 아이콘->시스템 환경 설정'으로 들어가면 된다.
 


  1. 하단 Dock 아이콘 숨기기
    Dock 을 자동으로 숨기도록 하여 일반 윈도우를 더 크게 사용할 수 있다.

  2. 키보드 반응 속도 향상
    키보드 반응 속도는 아래의 슬라이드 바를 빠르게/짧게 상태인 우측으로 옮겨주면 된다.
    그리고 F1~F12키보드를 Fn(펑션키)와 함께 눌러서 특수 기능을 사용하도록 하는 것이 좋다. 이를 설정하려면 아래의 '모든 F1, F2 등의 키를 표준 기능 키로 사용' 항목을 체크한다.

  3. 트랙패드 제스처 활성화
    만약 휠 마우스를 사용한다면 아래의 '스크롤 및 확대/축소' 탭에서 '스크롤 방향: 자연스럽게' 항목은 체크 해제한다. 이를 해제하지 않으면 아래로 스크롤 하기 위해 비행 시뮬레이션 게임을 하듯 마우스 휠을 위로 올려야 한다.

필수 소프트웨어

  1. KeyRemap4MacBook
    맥킨토시에서 제공하지 않는 키보드 제어 기능을 사용할 수 있다. 한영 전환 키라든가, 키보드 기능을 바꾼다거나 할 경우 이 앱을 설치하면 된다.
     

    KeyRemap4MacBook 다운로드
    http://pqrs.org/macosx/keyremap4macbook/


  2. 우측 Command 키로 한영 전환
    아래에 보이는 항목을 찾아 체크해 준다.


  3. 키보드 누를 때 반복/속도 향상
    아래의 항목의 수치를 적당하게 조정하면 키보드 반응 속도를 더욱 높일 수 있다.



OSX 자주 사용하는 핫키

몇 가지의 자주 사용하는 핫키만 알면 맥킨토시를 사용하는 것이 한결 자연스러워진다. 

핫키를 사용하기 위해 아이콘이 어떻게 생겼는지 반드시 기억하기 바란다.
 





  1. Mission Control(미션 컨트롤)
    화면의 윈도우와 열려있는 스페이스를 한 화면에서 볼 수 있는 편리한 기능이지요.
    Control + ⇧

  2. 스페이스 이동
    Control + 오른쪽 방향키 or 왼쪽 방향키
     
  3. SpotLight (스포트라이트)
    Control + Space

    OSX에서 사용중인 리소스(응용 프로그램, 이메일, 문자 등)을 모두 검색해 준다.

트랙패드

트랙패드는 시스템 환경설정의 트랙패드 항목에서 매우 자세하게 볼 수 있다. 간단하게 자주 사용하는 제스처만 몇 개 꼭 알고 있으면 된다.

  • 두 손가락을 살짝 댓다가 때기 = 마우스 우클릭
  • 두 손가락 + 위 또는 아래 = 화면을 스크롤
  • 두 손가락 + 좌 또는 우 = 브라우저의 이전 페이지/앞 페이지 이동
  • 세 손가락으로 움직이기 = 아이콘이나 창을 이동
  • 네 손가락 + 좌 또는 우 = 스페이스 영역을 이동한다
  • 네 손가락 + 위 = Mission Control(미션 컨트롤) 실행



  1. 양수영 2013.03.04 09:22

    이미지들이 안보이는데요..?
    저만 그런가요? ㅎㅎㅎ

    • powerumc 2013.03.04 10:46

      지금 모바일로 보고 있는데
      이미지 잘 보이네여.

      이거 저만 보이는건가요? ㅡㅡㅎ

  2. 정환나라 2013.03.07 10:03

    저는 pc에서 크롬으로 보고 있는데 만 아래 이미지 빼고는다 안나오는데요

  3. jamie 2013.03.15 14:20

    크롬브라우저에서는 안보이나봅니다. 저도 크롬유저인데...ㅠㅜ

부하테스트 이야기, 테스트 데이터 분석 문제 풀어보세요.

부하테스트 이야기

부하 테스트는 테스트 분류 상 '비기능 테스트'에 속하는 매우 정교한 테스트 중의 하나다. 부하 테스트는 수치화된 데이터를 통해 성능 지표를 도출한다. 대부분 부하 테스트는 클라이언트 응용 프로그램보다 서버 응용 프로그램에 주로 사용한다. 웹 서버나 통신과 관련된 서버, 그리고 데이터베이스가 대표적이다.

일반적으로 테스트라고 하면 '성공/실패'가 매우 명확하다. 그리고 '성공/실패'라는 결과에 대해 객관적으로 판단할 수 있고, 특별한 경우가 아니고서 '성공/실패'를 재연할 수 있는 시나리오를 가지고 있다.

반면 부하 테스트는 '성공/실패'는 경험적으로 판단해야 하며, 성공인지 실패인지에 대해 다른 사람과 의견이 일치하지 않는 경우가 대부분이다. 그래서 경험적으로 성공과 실패의 기준점을 정하곤 한다. 하지만 매번 성공/실패가 같은 결과를 내지 않으며, 환경적인 요건에 따라 얼마든지 결과가 뒤바뀔 수 있다. 실패한 테스트를 다시 수행 했을 때, 재연할 수도, 못할 수도 있는 있다. 결과적으로 테스트 대상의 환경적인 요건과 더불어 누가, 어떻게 테스트를 수행하였는지도 테스트 결과에 반영이 될 수 있다.

필자는 4년이 넘도록 현장에서 수많은 부하 테스트를 수행해왔다. 매우 재미있는 것은 어떤 서버 응용 프로그램도 성능 요건을 통과한 적이 단 한번도 없었다. 수 년 동안 문제 없이 잘 써왔다는 서버 응용 프로그램도 부하테스트를 통해 문제를 발견하고 더 나은 성능을 낼 수 있도록 개선된 사례들도 매우 많다.

숨겨진 많은 버그나 이슈들이 부하 테스트를 통해 여실히 드러난 것이다. 그로 인해 이전에 다니던 N모 게임사의 인프라는 부하테 스트로 성능 요건을 반드시 통과해야 라이브로 서비스할 수 있는 엄격한 규칙도 생겼다. 물론, 이 때에는 필자가 전담하여 테스트를 수행했었을 때였다.

부하 테스트라는 주제 하나 만으로도 책 한 권 정도의 분량이 넘을 것 같다. 그 만큼 현장에서 부하 테스트에 대한 오해도 많았으며, 개발자와 실무진 간의 성공/실패에 대한 이해관계, 테스트 데이터 분석, 또 이를 보고서화 및 시각화 하는 과정의 자동화 등 많은 재미있는 경험이다.

왜 부하 테스트가 중요할까? 그 이유는 아무것도 눈에 보이지 않기 때문이다. 문제가 있어도 금전적/물질적으로 어떠한 손해를 입었는지 조차 알 수 없다. 테스트를 통해 문제를 발견하지 않는 이상 아무런 문제가 되지 않는다. 그러므로 '비기능 테스트'인 부하 테스트 자체의 필요성 조차 느끼지 못할 것이라 생각한다. 하지만 전문적인 '비기능 테스트' 활동을 시작함과 동시에 많은 문제들을 발견할 수 있을 것이다.

재미로 풀어보는 부하테스트 분석 문제

부하 테스트는 테스트 활동 자체에 큰 의미를 부여할 수 있지만, 부하 테스트 데이터를 분석하는 것도 테스트를 수행하는 것 만큼이나 중요하다. 아니, 이 분석 과정이 더 중요한 경우도 많았다.

이 데이터들은 테스트 툴이 보여주는 성능 지표 뿐만 아니라, 디스크 IO와 네트워크 대역폭과 같은 하드웨어적인 측면과 쓰레드(Thread), 프로세스(Process) 등과 같은 운영체제와 소프트웨어적인 측면 모든 것을 분석해야 한다. 놓칠 수 있는 많은 데이터들이 문제나 이슈의 원인과 직결되는 경우도 있기 때문이다.

가령, 데이터베이스 서버의 병목의 원인을 규명하고자 할 때 대부분 많은 트랜잭션과 락(Lock)이 걸리는 이유일 것이다. 하지만 간혹 디스크 IO가 권장하는 임계치를 벗어난다면 병목의 원인을 구진 디스크로 밝혀질 수도 있기 때문이다.

필자가 재미있는 문제 하나 준비했다!

아래의 그림은 .NET WCF(Windows Communication Foundation)의 부하 테스트 결과이다. 딱 보고 '무엇이 문제인지' 원인을 안다면 당신은 충분히 멋진 개발자이다. 하지만 뚫어져라 쳐다봐도 문제점이 보이지 않는다면 기본기가 부족한 개발자인 스스로를 자책하기 바란다.

이 테스트 결과의 분석 결과는 무엇이 문제인지는 다음 아티클을 기대하기 바란다.

  • Smoke 테스트 결과

  • Stress 테스트 결과

  1. shunman 2013.04.03 13:29

    결과가 어떻게 나오는지 궁금하네요. 어서 다음 아티클 부탁드립니다 ㅋ

최신 우분투(Ubuntu) 12.10 64비트 버전을 제 노트북에 설치하였다. 노트북의 해상도는 1600*900로 세로 길어가 짧은 전형적인 와이드형 LCD 모니터이다. 이전 우분투 12.04 LTS에서는 없었던 문제였는데, 이번에는 설치 중 설치 창이 화면을 넘어서서 창이 잘리는 현상이 발생하였다.

   

화면 잘림 현상은 파티션 나누는 단계에서 고급 설정을 선택했을 때 발생한다.

아래의 이미지는 창이 길어져서 항목을 선택하거나 '계속' 버튼을 누를 수 없게 된다. 설치 중 창의 크기를 줄일 수 없기 때문에 이 문제로 조금 난감했다.

이런 현상이 발생하는 경우 창의 타이틀 부분(위쪽)을 ''Alt+마우스 좌 클릭+마우스 이동 ' 하면 두 번째 이미지 처럼 잘린 창 밑 부분을 스크롤 할 수 있다.

[이미지1] 창이 잘린 이미지

   

[이미지2] 창이 잘려 창을 ' Alt+마우스 좌 클릭+마우스 이동 ' 한 이미지

오늘 플레이 동영상은 방어형 영웅이다. 방어형 케릭 나머지 2개는 촬영을 못했다.

오늘 플레이 중에 '얼어붙은 땅의 수호자' 편이 가장 흥미진진한 경기였다.



얼어붙은 땅의 수호자


방어와 공격이 적절하게 조합된 영웅.

공격템 장착하면 스킬빨로 델딜이 좀 쌔다.

상대방의 레벨과 어느 정도 비슷하다면 1:1에서도 전혀 뒤지지 않는 방어형 영웅.










골렘 수호병


오리지널 방어 영웅.

공격은 일찌감치 포기하자. 공격템을 차도 공격력은 안나오니, 주로 방어템으로...

스킬도 대부분 궁극의 방어 스킬.

적진에 방어 스킬빨로 생각 없이 뛰어도 좋다.









기억을 잃은 전사


방어형 영웅이긴 하지만, 지원형으로 분류해도 좋을 만큼 유용하다.

공격적인 성향이 강한 방어형인데 뎀딜엔 좋지 않다,

4번째 궁극의 스킬에 걸리면 대부분 빼도박도 못하고 죽어줘야 함. ^^;










대지의 거수


방어형 영웅에 힐링 스킬이 겸비되어 있다.

방어형이지만 몸빵이 그리 좋지는 않지만,

힐링 스킬로 자기 목숨은 자기 목숨은 어느정도 챙길 수 있다.

대체적으로 전부 느려서 골드 모으기가 힘들고 느리다.









뼈 파괴자


방어와 공격이 어느 정도 비율을 갖춘 영웅.

도끼 돌리는 스킬은 당하는 입장에서는 매우 짜증을 불러 일으킨다 ㅋ;

방어력 보다는 피빵 스킬이 많아서 HP를 잘 관리하자.









성기사 단장


공격 성향이 무척 강한 방어형 영웅.

공격템 차면 정말 방어형 영웅인지 의심이 갈 정도로 뎀딜이 끝장남.

더불어 방어형 스킬 2개가 있는데, 이 덕분에 방어와 공격 모두 강하다.

그래서 방어형 영욱 중엔 사기에 가깝다.










  1. zerald 2013.02.07 01:23

    골렘이 생각보단 딜링이 되던거같던데요.....

  2. zerald 2013.02.07 01:23

    골렘이 생각보단 딜링이 되던거같던데요.....

iOS계의 리그 오브 레전드(League of Legends)라고 불리우는 Game Loft 히어오즈 오브 오더앤 카오스(Heroes of Order & Chaos-히오카-HOC)라고 불리는 악마의 게임!

 

최대 레벨이 40인데, 벌써 만랩을 찍었다. @.@

 

이를 기념하여 게임 플레이 영상을 만들어봤다.

 

게임 하시는 , 같이 하셈!!







동영상이 안보이면 다음 tv팟 링크: http://tvpot.daum.net/mypot/View.do?ownerid=nYPHkTYSu8c0&clipid=47463284#clipid=47463282&t=all

유투브 : https://www.youtube.com/watch?v=MCP3UU5aGyI











동영상이 안보이면 다음 tv팟 링크 : http://tvpot.daum.net/mypot/View.do?ownerid=nYPHkTYSu8c0&clipid=47463284#clipid=47463284&t=all

유튜브 : https://www.youtube.com/watch?v=Cf2Pz_164qo


개요

SpringSource Tool Suite for Eclipse Juno(이하 STS) 를 Eclipse Marketplace 를 통해 설치를 하고자 할 때, Dependencies 체크 후에 아래와 같은 메시지와 함께 설치가 되지 않는다.

Cannot complete the install because one or more required items could not be found. Software being installed: Spring IDE Security Extension (optional) 3.1.0.201210040510-RELEASE
...
...
이하 생략    

이 문제는 인터넷을 통해 필자와 같은 문제의 Thread를 찾을 수 있었다.

  • Thread: cannot install Spring Tool Suite (STS) for Eclipse Juno (3.8 + 4.2) 3.1.0.RELEASE     필자와 같은 문제가 발생하는 경우 위 링크의 답변처럼 GEF(Graphical Editing Framework) 를 설치/업데이트 하면 된다고 한다. 아래의 원문의 링크를 이클립스에서 Help -> Install New Software를 이용하여 설치/업데이트를 할 수 있다. 뭐가 뭔지 잘 모르겠다면 Releases 의 링크를 통해 업데이트하면 된다.

GEF Update-Sites
Using the Eclipse Update Manager (see Eclipse Help for detailed instructions) GEF can be installed from the following update sites:

GEF(Graphical Editing Framework)의 정보는 IBM 사이트에서 찾을 수 있다. 모델링이나 이미지/그래픽 기반으로 Editing 할 수 있는 오픈 소스 프레임워크이다. STS에서 GEF를 이용한 기능적인 향상이나 종속적인 바이너리 등이 변경이 된 듯 싶다.


[이미지 1] GEF Extension 예시 / 이미지 출처 - http://www.eclipse.org/gef/


[이미지 2] Visual Studio DGML / 이미지 출처 - http://msdn.microsoft.com/en-us/library/vstudio/jj739835.aspx  

마치 Visual Studio 의 DGML(Directed Graph Markup Language)과 비슷하게 보인다. 하지만, Eclipse에서의 GEF와 Visual Studio에서의 DGML의 가장 큰 차이점이라고 하면 DGML은 정의된 스키마(Defined Schema)이고, GEF는 확장 가능한 프레임워크라는 점이다. 그 점에서 Eclipse의 GEF에 더 좋은 점수를 주고 싶다..    

GEF와 DGML의 자세한 내용은 아래의 링크를 참고하기 바란다.

Eclipse에서 GEF를 설치/업데이트가 성공하였다면 다시 Eclipse Marketplace에서 STS을 설치한다. 그럼 아래와 같이 못 보던 추가 구성 요소들이 더 많아진다. 그리고 계속 진행하면 설치가 성공할 것이다.    

개요

Java 8 버전에서 Lambda 표현을 지원한다. 아직 Java 8은 Beta 버전이다. 여러 언어 중에서 Lambda 표현을 지원하지 않는 언어로 손꼽힌다. Wikipedia에서 Anonymous Function을 참고해보면 Java 언어가 언어의 표현력에 있어서 추세를 따라가지 못하는 것이 아닐까 생각한다.

반면,

  • C#은 2007년도에 C# 3.0 버전에 LINQ 라는 대주제를 중심으로 Lambda, Anonymous Class, Extension Methods를 내놓았고,
  • C# 4.0은 2010년도에 Dynamic이라는 대주제를 중심으로 동적 프로그래밍이 가능해졌다.
  • C# 5.0은 2012년도에 비동기 라는 대주제를 중심으로 비동기 프로그래밍을 언어적으로 지원한다.

Wikipedia에서 C# 역사에 대해 더 자세히 알고 싶은 분은 'C# (programming language)' 를 참고하면 좋겠다.

Java를 이용하여 프로그래밍을 하려고 하면 정말 C#이 많이 생각난다. C#에서 한 줄짜리 문장을 Java에서는 십여 줄 넘는 경우가 많기 때문이다. 굳이 예를 들자면, 우리나라에서 유행하는 줄임말 '엄친아'를 풀어서 '엄마 친구의 아들' 로만 말해야 하는 것과 같은 느낌이랄까… 어쨌든 Java는 Java만의 매력이 있는 법. 그 매력을 찾아보는 것도 재미있겠다.

각설하고, 먼저 Java 8을 사용하여 개발할 수 있는 환경부터 간단히 살펴보자.

현재 Java 8 버전은 베타 버전이다. 현재 Java 8은 Sun사의 JDK를 칭한다. 그러므로 Oracle 사이트에서 Java 8 버전을 다운로드 받을 수 없다.

그리고 Project Lambda를 지원하는 개발 툴을 사용해야 한다. 다음의 링크의 NetBeans와 IntelliJ IDEA 12 버전에서 Project Lambda를 사용해볼 수 있다. 아래의 링크에서 다운로드 받을 수 있다.

설치와 JDK 1.8 버전의 환경 구성이 완료되었으면 Lambda 표현을 Java 에서 사용할 수 있다.

Java 8 의 Lambda 샘플 예제 간단한 예제만 소개하겠다.

(Java에서 권장하는 네이밍이나 코드 구현 방식에 맞지 않는 부분이 있더라도 양해 바란다.) 간단한 더하기 계산을 Lambda 표현으로 작성하면 다음과 같다. 



위의 코드로 말미암아 Lambda 표현은 (arguments) -> { … } 로 표현할 수 있겠다.

간단하게 Thread를 돌리는 코드를 Lambda 표현식으로 작성해보자. 




다음은 ExecutorService를 Lambda 표현으로 작성하였다. 





Java의 Lambda 이야기가 나온 김에 어떻게 Lambda 표현으로 발전하였는지도 짤막하게 보자.

원래 이런 코드가 있었다. Runnable Interface를 구현하는 코드이다. 




또는 Java의 Local Class를 이용할 수 있다. Local Class는 메서드 구현부에서 Class를 선언하여 이를 인스턴스화 할 수 있다.

위의 Runnable Interface를 구현한 코드를 Anonymous Class(익명 클래스)로 표현할 수 있게 되었다. 그래서 아래의 예제와 같이 Interface를 구현하는 Class를 만들지 않아도 된다. 



위 Anonymous Class를 Lambda 표현으로 작성하면 더 간결하게 표현할 수 있다. 


단, Java 8의 Lambda 표현에 제약이 있다.

그리고 Project Lambda를 소개하는 페이지의 Functional Interfaces 에서 제약에 대한 설명이 있다. 하지만 이는 근본적으로 Java에서는 C/C++의 Pointer를 표현할 방법이 없는 이유이다. 그러므로 함수를 가리키는 Pointer도 있을 수 없다. 반면, C#에서는 함수포인터를 표현하기 위해 Delegate(대리자)를 지원한다. C#에서는 함수포인터를 안전하게 다룰 수 있다.

그래서 Java에서는 함수포인터를 표현하기 위해서 Listener 형태의 패턴을 주로 사용한다. 다른 말로 Observer 패턴이라고 부른다. Java의 Thread가 대표적이다. Java의 Thread는 Runnable을 인자로 받는 생성자가 있다. 위의 코드에서도 볼 수 있듯이 Runnable은 void run() 메서드만 달랑 가지고 있는 Interface이다. Java의 Thread는 이 Runnable Interface만 알고 있으면 되고, Runnable Interface를 구현하는 인스턴스를 Thread에게 넘겨주면 된다.

반면, C#의 Thread는 Delegate(대리자-안전한 함수 포인터)를 이용하여 Thread를 실행한다. C# 컴파일러는 Delegate를 결국 Class 로 취급한다. 이로 말미암아 Java와 C#에서 포인터라는 것은 언어적으로는 전혀 메커니즘으로 작동하지만 런타임 입장에서는 유사한 메커니즘으로 동작한다는 것을 알 수 있다. 하지만 Java에서 함수포인터를 흉내를 낼 수 있는 방법은 있다. 키/쌍의 컬렉션을 이용하여 참조를 전달하는 방법이다. 아래는 간단한 예제 코드이다. 



어찌되었든 결국, Java의 Lambda는 Interface를 이용하여 Lambda 함수를 만듦으로써 Interface의 함수가 단 1개만 있어야 Lambda 표현을 할 수 있는 제약이 생겼다. Interface를 이용하여 Lambda를 표현한다고 함은 내부적으로 Proxy 객체를 생성하여 그 안에 Lambda 표현을 메서드로 만든다.

아래의 익명 클래스를 보자. 아래의 runnable 로컬 변수를 리플랙션을 이용하여 getMethods() 의 목록이다. 



아래의 Lambda 표현을 보자. 마찬가지로 runnable 로컬 변수를 리플랙션을 이용하여 getMethods() 의 목록이다. 


이를 통해 Java의 Lambda 표현식은 내부적으로 Proxy 클래스가 생성됨이 확인되었다. 그런데 이 Proxy 클래스가 언제 생성이 될까? 컴파일 타임에 생성이 될까, 아니면 런타임에 생성이 될까?

이를 JD-GUI 도구를 이용하여 Decompile 결과를 확인하려고 하였으나, Java 1.8.0 버전에 대해서 JD-GUI 가 올바르게 인식을 하지 못해 전혀 class 파일을 전혀 읽을 수 없다. 대신 .class 파일을 Text Editor 로 열어서 대략적인 내용을 확인할 수 있는데, Text Editor 에서는 Lambda 표현으로 구현된 Proxy Class 를 찾을 수 없었다. 따라서 Lambda 표현은 런타임에 구현 객체 Proxy 가 생성된다는 것을 알 수 있다. (다만, 확신은 못하겠다.)

한가지, Java 8의 Lambda 표현의 다른 점이라면 Lambda 표현의 Proxy 객체는 java.lang.invoke.MagicLambdaImpl 클래스를 상속한다는 점이다. 앞서 얘기했듯이 JD-GUI 도구가 Java JRE 1.8.0 의 rt.jar 파일을 상위 호환성이 아직 지원되지 않아 구현 내용을 알 수는 없었다. 이는 좀 더 Java 8의 Release 시기가 다가오기를 기다려야 할 것 같다. 



결론은 Java 8의 Lambda 표현을 하기 위해서는 Interface 의 구현 함수는 반드시 1개여야 한다는 점이다.

  1. 짜두 2013.01.17 08:59

    이제 베타버전이니 좀더 발전해야 겠네요. 굉장히 빠른 속도로 발전해나가지 않을까하는 생각이 드네요.ㅎ

개요

간단하게 작성한 C++ 코드가 컴파일이 되지 않는다. auto 키워드와 lambda 식을 제대로 해석을 하지 못하는 모양이다.

인터넷을 통해 쉽게 문제를 해결할 수 있었다. 아래의 원문의 링크를 참고하면 된다. 필자는 아래의 링크를 참고하여 스샷좀 뜨고, 예제 샘플 정도만 만들었으니 설정에 어려움이 없다면 아래의 참고 링크만으로 충분할 것이다.

필자가 받은 GCC 4.7.2 버전의 Release 변경 사항을 보면 도움이 될 것이다.

그리고 몇 가지 std 함수 중 to_string 함수에 버그가 있는데, 아직도 Pending 상태라 되도록 사용하지 말고(사용자체가 안된다 ^^;), stringstream 등을 사용하도록 권장한다. SourceForge에서 GCC 버그 항목을 찾아보면 2011년도에 버그가 등록되었지만, 우선순위가 낮아 당분간 고칠 생각이 없는것 같다. (SourceForge GCC to_string 버그 링크)

MinGW-GCC 에서 C++11 컴파일 환경 구성

Project Explorer -> Project Properties -> C/C++ Build 탭 -> Settings 탭 -> Tool Settings 탭 -> Miscellaneous 항목 -> Other Flags 에 -std=c++0x 를 추가한다.

그리고 C/C++ General 탭으로 이동한 후 Paths and Symbols 탭 -> Symbols 탭 -> __GXX_EXPERIMENTAL_CXX0X__ 항목의 Value 값을 0 으로 설정한다.

모두 완료되었다면 Clean Project를 해서 다시 컴파일하자. 아래와 같이 auto 키워드와 lambda 구문에 더 이상 경고와 오류 문구가 뜨지 않고 컴파일도 성공한다.

Qt 개발 환경을 만들려는 참에 Eclipse에서 Visual C++로 만든 프로젝트를 MinGW GCC로 변환해야 할 필요가 생겼다. '인터넷 검색 링크를 잊어버려서… 다시 참고 원문 링크는 찾으려니 찾아지지 않아서... 패스....'

우선 프로젝트를 변환하는 방법은 크게 두 가지가 있는데, 예를 들어, 첫 번째는 전혀 다른 프로젝트를 Dynamic Web Application으로 바꾼다거나… 이런 경우에는 Project Explorer에서 -> Propject Properties -> Project Facet에서 변경하면 된다고 한다.

   

두 번째, 필자가 필요한 것은 이 방법이다. Eclipse에서 Visual C++로 만든 프로젝트를 MinGW로 변경하고자 한다.

Project Explorer -> Project Properties -> C/C++ 탭 -> Tool Chain Editor에서 변경할 수 있다.

   

이제 MinGW GCC 컴파일러를 이용하여 컴파일이 되도록 환경을 수정해야 한다. 이 방법은 아래의 링크를 참고하면 된다.


참고로 필자의 MinGW GCC 환경 변수의 경로이다.

  • INCLUDE - D:\Program Files\MinGW\include
  • LIB/LIBPATH - D:\Program Files\MinGW\lib
  • PATH - D:\Program Files\MinGW\bin

   

여기에서 주의해야 할 것은 Environment 옵션에서 'Append variables to native environment' 항목을 선택한다.

   

Eclipse 개발 도구의 장점이라면 많은 벤더가 Eclipse 개발 환경을 지원하고, 오픈 커뮤니티 포럼도 굉장히 활성화가 되어있다는 장점이 있다. 그리고 오픈 소스이며 순수 Java로만 구현이 되어있어 Eclipse를 확장하거나 개발 환경을 구성하기 매우 쉽다. Eclipse에서 여러 언어를 지원하고 다양한 무료 플러그 인을 제공한다. (일부 언어는 컴파일러를 별도로 설치해야 한다.)

그 중 인터넷 자료를 찾아보면 Eclipse에서 C++ 개발 환경을 구성할 수 있는데, GCC(GNU C Compiler)에 포함된 컴파일러를 대상으로 소개하고 있어, 이를 Visual C++ 환경을 구성하는데 몇 가지 시행착오를 겪은 부분이 있어 이를 공유하고자 한다.

물론, Microsoft에서는 Visual Studio Express 2012 for Windows Desktop Application라는 무료 개발 버전을 제공한다. 하지만, 무료 개발 버전인 Express는 여러 가지 무료 플러그 인을 설치하는데 제약이 있어, 거의 순정 그대로 사용 해야 하는 불편한 점이 있다. 무료 개발 툴이 Eclipse를 이용하여 Visual C++ 개발 환경을 구성하고, Eclipse의 다양한 플러그 인을 그대로 사용할 수 있도록 하기 위해, 개발을 위해 추가 비용 없이 무료 도구인 Eclipse 에서 Visual C++ 개발 환경을 구성하는 것이 도움이 될 것이다.

     

1. 먼저 Visual C++ 컴파일러가 포함된 SDK 를 다운로그 하면 된다.

가장 최신 버전인 Windows SDK for Windows 8 버전은 아쉽게도 모든 컴파일러가 포함되지 않는다. Microsoft가 무슨 수작을 부리려는 것인지는 몰라도, 지금껏 꾸준히 제공된 SDK 를 충실히 제공하지 않는다.

 

더 자세한 내용은 필자가 작성한 다음의 링크를 참고하기 바란다.

     

비교적 가장 최신 버전인 Windows 7 SDK 또는 Windows 8 SDK를 설치하면 된다.

     

     

2. 그 다음, Eclipse C++ 개발 버전을 다운로드 받아서 설치한다.

이미 Eclipse IDE for Java EE Developers 버전 등을 이미 설치했다면, 다운로드 받은 Eclipse IDE for C/C++ Developers을 압축을 풀어서 features 폴더와 plugins 폴더를 기존의 Java EE 버전에 복사를 하고, 중복된 파일은 Skip 하면 된다.

올바르게 설치가 되었으면 필자와 같이 C++ 프로젝트를 생성할 수 있다.

     

아래와 같이 Microsoft Visual C++ 프로젝트를 생성할 수 있는 항목이 있다. 그렇다고 프로젝트를 생성한 후 컴파일은 되지 않을 것이다. 그런 이유로 필자는 지금 이 아티클을 쓰고 있지 않은가? ^^

     

Visual C++ 프로젝트가 생성이 되면, 아래와 같이 붉은 색의 x 표시가 너덜 너덜 널려있다.

     

Ctrl+F11 을 눌러 실행시키면 다음과 같은 오류 메시지가 나온다. 정상이니 놀라지 말자.

     

     

3. 컴파일 환경을 구성하기 위해 환경 변수 정보를 수집하자.

Eclipse에서 Visual C++을 컴파일 하기 위해서 다음의 환경 변수 정보가 필요하다. 이 경로는 Visual C++ 컴파일러와 Visual Studio에서 C++ 빌드를 하기 위해 필요한 경로이다.

  • PATH
  • INCLUDE
  • LIB
  • LIBPATH

     

Visual C++ 컴파일러인 cl.exe 파일은 %ProgramFiles(x86)%\C:\Microsoft Visual Studio 11.0\VC\bin\cl.exe 에 위치한다. 그러나, 이 cl.exe는 현재 폴더의 하위에 존재하는 CPU 아키텍처 버전별 폴더에 있는 .dll 파일을 필요로 한다. 이 폴더에도 cl.exe 파일이 존재하므로 현재 자신의 컴퓨터의 CPU 아키텍처 버전의 폴더만 알면 된다.

     

자신의 컴퓨터의 CPU 프로세스 아키텍처를 모르면 Command Line에서  SET PROCESS 를 입력해 본다. 그럼 아래와 같이 확인할 수 있다.

     

이로써, 컴파일에 필요한 cl.exe 가 포함된 폴더는 %ProgramFiles(x86)\Microsoft Visual Studio 11.0\VC\bin\amd64 임을 알 수 있다. 이 폴더를 메모해 놓자.

그리고 더 필요한 폴더가 있다.

%ProgramFiles(x86)%\C:\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat 파일은 'Visual Studio 개발자용 명령 프롬프트'이다. 이 파일의 내용을 보면 컴파일이나 명령 도구를 수행하기 위해 필요한 경로를 설정하는 부분이 있는데, 이 폴더들도 필요하다.

     

위와 같이 PATH, INCLUDE, LIB, LIBPATH 가 Visual C++을 컴파일 하기 위해 필요하다. 이 Batch 파일을 보면 위의 환경 변수에 조건에 따라 계속 경로를 추가한다. 그러므로 우리는 편의상 설정된 전체 경로를 그대로 복사해서 사용할 것이다.

먼저 Visual Studio 개발자 명령 프롬프트(Command Line)을 실행 시킨 후, 아래와 같이  SET INCLUDE 와  SET LIB 명령을 실행하면 완전한 환경 변수의 경로를 구할 수 있다.   

     

이 경로를 클립보드에 복사하기 편하도록 하려면, 다음과 같이 파일에 결과를 쓰도록 하면 된다. 그럼 log.txt 파일이 없으면 파일을 생성하고, 파일이 존재하면 콘솔의 출력 내용이 log.txt 파일 끝에 추가 된다.

C:…\>SET INCLUDE >>log.txt
C:…\>SET LIB >>log.txt
C:…\>SET PATH >>log.txt

     

     

4. 이제 Visual C++ 컴파일러인 cl.exe 파일을 Eclipse에서 컴파일이 되도록 설정해보자.

일부 환경 변수의 경로는 %PATH% 환경 변수의 경로에 추가해 주면 되는데, 그렇게 되면 너무 번거로워질 것 같아서, Eclipse에서 제공하는 기능을 통해 환경 변수 정보를 추가하겠다.   

Eclipse 메뉴에서 Windows -> Preferences -> C/C++ 탭 -> Build 탭 -> Environment 로 이동하자.

     

이 곳에서 아래의 그림과 같이 PATH, INCUDE, LIB, LIBPATH 환경 변수를 입력하면 된다.

     

이제 Ctrl+F11 을 눌러 컴파일하여 실행하면 정상적으로 실행이 될 것이다.

하지만 C++ 편집기에는 붉은 색의 경고 문구들이 사라지지 않았다.

     

그렇다. 지금까지 Eclipse에서 C++ 소스 코드를 빌드하는 환경을 구성한 것이다.

     

     

5. Eclipse 에서 C++ 소스 코드 편집 환경 구성을 해야 한다.

여기까지 잘 구성을 하신 분이라면 이번 구성도 어렵지 않게 할 수 있을 것이다. 환경 변수의 경로만 몇 개 추가해 주면 된다.

Eclipse의 좌측 Project Explorer에서 C++ 프로젝트에 마우스를 갖다 놓고 오른쪽 버튼을 클릭해보자. 프로젝트 속성을 변경할 수 있는 Properties 메뉴 항목이 보일 것이다. 클릭하면 속성 창이 뜬다.

     

C/C++ General 탭 -> Paths and Symbols 탭으로 이동하여 GNU C++ 항목에서 Includes 탭을 보자. 이곳에서 Add 버튼을 클릭하여 INCLUDE 환경 변수의 값을 하나 하나씩 넣자. 반드시 경로를 ';' 로 붙여져 있는 것은 분리해서 하나 하나씩 입력해야 한다.

마찬가지로 Libraries 탭으로 이동한 후 LIB 환경 변수의 경로 값을 하나씩 입력하자.

     

6. 이제 Eclipse에서 Visual C++ 개발 환경을 구성하는 것이 모두 완료되었다.

#include 파일 목록이 보이지 않았고 Intellisense가 동작하지 않았었는데, 이제 모두 동작한다.

     

     

부록으로 아래와 같은 오류 메시지를 만날 경우 대처 방법이다.

오류 1 : 컴파일 시에 발생한 오류인데, iostream 헤더 파일을 찾을 수 없어서 발생하는 오류이다. 위의 3번과 4번의 방법으로 빌드 환경을 구성하자.

     

오류 2 : 이는 컴파일 중 발생한 오류처럼 보이지만, cl.exe 파일을 찾을 수 없거나 cl.exe 에 종속된 DLL을 찾지 못하는 경우 발생하는 오류이다. 1번의 SDK 가 올바르게 설치되었는지 확인하자. 설치가 올바르게 되었다면 3번과 4번을 다시 따라해보자.

    

  1. 익명 2014.02.17 11:33

    비밀댓글입니다

    • POWERUMC 2014.02.20 23:01 신고

      이클립트는 workspace마다 설정을 복제할 수 있는 것으로 알고 있거든요.
      숨김 폴더의 .eclipse 인가(가물가물), 이 폴더를 복사하시면 됩니다.

  2. 경준씨 2014.03.06 21:50

    http://msdn.microsoft.com/ko-KR/windows/hardware/gg454513
    Windows 8.1 SDK가 업데이트 되었습니다.
    수정 바랍니다.

    • POWERUMC 2014.03.06 23:03 신고

      아래의 링크를 보시면 이렇게 써있네요. 잘못 알고 계신 것 같은데요?

      명령줄 빌드 환경
      Windows SDK는 더 이상 전체 명령줄 빌드 환경을 제공하지 않습니다. 대신 Windows SDK를 사용하려면 컴파일러와 빌드 환경을 별도로 설치해야 합니다.

      http://msdn.microsoft.com/ko-kr/windows/desktop/bg162891.aspx

  3. 경준씨 2014.03.06 23:39

    맨 아래쪽에 SDK가 있습니다.

    • POWERUMC 2014.03.07 18:22 신고

      SDK가 있는 건 알고 있어요.
      명령줄 빌드를 제공하지 않는다는 얘기가 써 있어요.

      제가 찾는 건 SDK가 아니랍니다.

  4. dkkim 2014.09.30 17:51

    안녕하세요. 올리신 글 많은 도움이 됐습니다.
    한가지 질문이 있는데... 기존에 visual studio에서 개발한 c++ 소스를 말씀하신 Eclipse 환경에서 빌드하고 실행까지 되는게 확인 되는데요. 디버깅이 잘 안되는데 따로 설정할 것이 있을까요?

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]
[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]


지난 1편의 글에 이어, 어떤 분이 원문을 쓰신 분에게 이런 말을 남겼다.

이 코멘트에 대해 원문을 쓰시는 분은 아래의 링크로 반박의 글을 작성하셨다.

원문 : http://imjuni.tistory.com/488

   


필자의 입장에서는 상용 솔루션이 커스터마이징을 해야 쓸만한 제품이란 것은 제품을 구매한 사용자 입장에서는 그리 달갑지는 않을 것이다. 대신 3rd party 벤더나 오픈 소스를 이용하여 기능을 더 보탤 수 있고, SDK API를 이용하여 직접 도메인 제약에 맞게 만들 수도 있을 것이다.

원문을 읽어보면 저 분은 TFS에게 어떻게 데였는지 모르겠지만, 병적으로 거부하는 것 같다. 그렇다고 싫어하는 이유에 대해 근거가 있거나 정확하게 잘못된 정보를 바탕으로 작성이 되었다는 것에 매우 안타까움을 느낀다.



첫 번째로, 위의 원문에서 아래와 같이 잘못된 정보를 가지고 있다.

   

일단 TFS에서는 VCS 기능을 어느 정도 확장을 할 수 있다. 이때 TFS Server는 물론이고, 클라이언트인 Visual Studio Extensibility를 이용하여 클라이언트도 확장할 필요가 있다. 이는 비단 TFS 뿐만이 아니라 SVN도 마찬가지다. 고로 어느 범위까지 확장할 것인가 결정에 따라 개발을 해야 할 범위가 틀려질 수 있다.

   

두 번째로, TFS를 Git와 비교한다는 것은 좀 무리가 있다고 본다.

Git는 유명한 리눅스를 개발한 리누스 토발즈에 의해 분산 버전 관리할 수 있는 소스 제어 솔루션이다. 분산 버전 제어가 자칫 매우 유연해 보일 수 도 있을 것이다. 이에 반해, TFS는 중앙 집중 방식의 소스 제어 솔루션이다.

기업에서 통제가 되지 않는 소스 제어는 보안적인 이슈나 소스 코드 유출 등의 사고가 생기가 마련이다. 이런 점에서 분산 버전보다 중앙 집중 방식이 기업에서 개발 환경 조건에 더 부합한다고 본다.

이런 장단점 등으로 오픈 소스를 지향하는 사람들은 분산 버전 관리 방식인 Git를 선호한다.

반면에, TFS는 TFS란 제품이 나오기 전부터 Microsoft 내부적으로 이슈 관리와 소스 제어를 할 수 있는 솔루션을 만들어 사용하고 있었다. Microsoft는 소프트웨어 기업이다. 소프트웨어를 잘 개발할 수 있도록 Team Foundation이라는 제품으로 발전하면서 상당히 많은 노하우가 녹아있는 제품이다.

SVN는 CVS가 Atomic Transaction(원자성)이 보장되지 않는 이유의 심각한 문제로, SVN으로 다시 태어났다.

   

원문을 쓰신 분은 필자가 이해하기 힘든 이유로 CodePlex와 Git를 비교하는 것은 '중국이 한국보다 인구가 많으니 강대국이다.'라는 논리와 같다.

잘못된 정보만을 가지고 TFS를 혐오하는 것은 바람직하지 않다고 본다. 안된다고 하는 많은 기능들이 이미 예전부터 지원했던 것인데 원문을 쓰신 분은 이런 기능을 이용하는 방법을 몰랐던 것이지, TFS 자체의 문제는 아니다.




이런 말을 해주고 싶다.

도구는 단지 도구일 뿐이다.
쓰는 사람이 잘 써야 좋은 도구이다.
잘 쓸 수 없는 도구는 그 사람의 잘못이지 도구의 문제가 아니다.
 

  1. 나그네 2013.01.13 17:36

    git 든 svn 툴이든 오픈소스 제품군만으로도 충분 해서. .굳이 tfs 도입할 이유가 생각나지 않는군요.

    vs 플러그인으로 연동하면 그만이라서..

  2. JIN 2016.08.29 11:56

    정성스레 작성하신 글 잘 보고 갑니다..
    TFS를 프로젝트에 처음 적용해 나가면서 어떤것인가 하고 경험해 가는 중에 포스팅 하신 몇몇 글들을 읽었습니다. ALM툴/서비스는 처음인지라 TFS가 정말 적당한지 어떤지에 대한 개념도 없이 아래의 몇가지 장점만으로 선택을 했습니다.
    처음엔 제목만 보고 아뿔싸 'TFS' 문제가 많은가보다 하고 심장이 쫀득해졌다가,
    객관적으로 분석해주신 내용을 보고 오히려 최고는 아니었어도 현재로써는 적절한 선택이었다는 생각이 들더군요..

    1. 현재 팀원이 1.2(12명 아닙니다 ㅎㅎ)명.. TFS 정책상 부담없이 쓸수 있고, 중장기적으로 팀이 5명까지 커질일이 없다는점
    2. 현재 Visual Studio를 사용중이며
    3. 1의 이유로 새로운 툴/서비스에 대한 시장조사/검증 자체가 부담
    4. 중앙 집중식 버전 컨트롤
    5. 그나마 접하고, 본게 이것
    6. 처음엔 단지 소프트웨어 버전컨트롤 이상도 이하도 아닌 이유로 사용함
    7. FDA 승인을 필요로 하는 제품 개발과 깊은 관련이 생기면서 Validation 문제에 봉착
    (FDA regulation 의 Validation 입니다 이는 Software의 Validation과는 다른 훨씬더 확장된 내용을 다루고 있습니다. 첨언하면, Software의 Validation하면 Software의 Specification과 Use case를 따르는 기능의 검증이 촛점이라면, FDA의 것은 SDLC를 어우르는 광범위한 Traceablity, 시스템 검증, 변경 관리 등등.. 전사적으로 등골빠지는 것중의 하나가 FDA 승인이죠..)
    8. 다만 7의 결과물이 Documented Evidence 가 되어야 하는게 FDA의 요구사항입니다. TFS내의 WORK ITEM과 Design Specification, Code, Test, Debug(issue) 등의 결과물이 문서상에 존재해야 한다는것이었죠.. 이 작업은 사람을 미치게도 할수 있는 부분입니다.. ㅎㅎ 이부분은 TFS에서도 직접적으로 문서화를 위한 솔류션을 통합한것은 아닌거 같더라구요 때문에 Modern Requirements라는 솔루션을 채택했습니다.. 이는 TFS상의 WORK ITEM의 부모자식관계 변경 이력, User Requirements, Design Specification, Code, Test, Debug(Issue) 의 Traceability등을 자동으로 생성해주는 역할을 합니다..
    9. 그 외에도 TFS가 'Microsoft' 라는 알려진 기업의 솔루션이기에 직접 구축한 Opensource based 시스템이나 시장에 인지도가 없는 회사의 솔류션일 경우 FDA의 Audit시에 수없이 많은 질문을 야기할 가능성을 줄여줄수 있다는 점도 큰 몫이었습니다.

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]





 
예전에 인터넷에서 자료를 찾는 중에 Team Foundation Server를 무척 혐오한다는 사람의 글을 읽게 되었다. 매우 잘못된 정보로 Team Foundation Server와 Visual Studio를 바라보는 것을 매우 안타깝게 생각한다. 이 글을 작성된 지 1년 정도 되었는데, 필자는 오늘에야 비로서 이 내용을 바로 잡고자 한다.

필자는 Microsoft 제품과 직접적으로 관련되지도 않았고, 더 이상 Microsoft MVP도 아니다. 그러므로 필자의 답변은 최대한 중립적인 입장에서 작성하였다. 물론, 필자는 Team Foundation Server를 사용한다. 하지만, 반드시 Team Foundation Server만 사용하지는 않는다.

그리고 글의 작성자는 Team Foundation Server의 기능과 Visual Studio IDE 기능을 모두 Team Foundation Server의 문제로 지적하고 있다. 이런 툴의 기능에 대한 혼돈이 있어 필자의 답변 또한 편의상 글 작성자의 의도에 맞게 Team Foundation Server로 통일하였다.

아래의 원문의 글을 작성하신 분의 글은 검은색이고,
필자가 답변한 글은 어두운 붉은 색으로 표시하였다.




원문 : 
http://imjuni.tistory.com/464 


 

단순한 거부 반응이 아니라 왜 TFS를 쓰기 싫을까? 개인적으로 TFS를 정말 오랫동안 써보고 또 TFS를 이용하여 공동 작업을 해보기도 한 결과 TFS는 정말 사용해서는 안될 도구라는 사실을 지속적으로 느꼈고, TFS를 제발 쓰지 않았으면 하는 생각을 계속 하게 되었다. 하지만 TFS는 생각보다 사용되는 곳이 많다. 그 이유는 가장 적은 비용으로 ALM 도구를 도입할 수 있다는 것 때문에 TFS를 도입하게 된다. 그런데, 가장 큰 문제는 ALM을 위해서 TFS를 도입하면 반대 급부로 TFS 때문에 개발자의 생산성이 저하되어 TFS를 도입한 비용만큼 개발자의 생산성이 저하된다. 그리고 제발 TFS가 가지는 ALM 기능이 VCS에 포함된다는 착각은 하지말자. Work item을 생성하거나 체인지 셋을 묶거나 추적하는 등의 기능은 ALM이면서 Issue Tracker이기 때문에 가능한 기능들이다. 이러한 기능은 Jira 또는 Code Beamer, Trac, Launchpad 와 같은 도구에서 제공하는 기능이지 SVN이나 Mercurial에서 제공하는 기능이 아니다. 정말 이런 대착각은 하지말자. 또한 Martin Fowler가 조사한 Vcs Survey에 따르면 TFS의 인지도는 0%다. 정말로 0%다. 링크를 따라가면 확인할 수 있다. 설마 Martin Fowler가 이름 없는 사람이고 그래서 그 조사를 믿을 수 없다는 이야기는 하지말자. Martin Fowler는 그 유명한 Refactoring의 저자이자, 애자일과 관련하여 아주 유명하신 분이다.


왜 TFS를 쓰면 안될까? 번역과 경험을 토대로 이 글을 써보자.

1. 크기: 이 부분은 MS가 참 미쳤다. SVN은 TortoiseSVN을 쓰면 15MB 많아야 20MB면 충분하다. 심지어 자체 웹서버가 내장된 tortoiseHg도 24MB면 충분하다. 웹서버도 없고 아무것도 없는 TFS는 Visual Studio Extension이라는 이유로 VS 필수 구성요소를 모두 설치해야 되기 때문에 200MB가 넘는다. 솔직히 요새 200MB면 껌이기 때문에 그리 부담도 되지 않지만 타 시스템과 비교하였을 때 10배 이상 크기가 큰 것은 확실하다. 넷북이나 가벼운 시스템에서 구동시키는 것은 확실히 부담되는 크기임이 자명하고, 부인해서도 안될 것이다. 뿐만 아니라 덩치가 크다는 것은 그만큼 메모리를 많이 소비한다는 뜻과 동일하다. TFS는 그만큼 가볍지도 않고, 용량도 많이 차지하는 거대 도구라는 것을 인정해야 한다.

SVN의 용량과 TFS의 설치 용량을 비교하는 것은 의미가 없다.

 
Team Foundation Server(이하 TFS)는 설치 시에 소스제어 기능만 선택적으로 설치할 수 없다. 그래서 설치 시에 모든 기능이 포함하여 설치하게 되는데, 이 중에는 소스제어, 작업항목, 빌드, 팀 탐색기(소스제어 클라이언트) 등이 모두 포함된다. 그리고 이 기능이 원활하게 동작하기 위해서 VC++ 재배포 패키지, .NET Framework 재배포 패키지 등이 설치 파일에 모두 포함이 된다.

 
마찬가지로 SVN을 소스제어로 이용하고, 그 외에 빌드, 이슈 트래킹 툴  등을 모두 갖추고 설치한다면 TFS보다 설치 용량이 더 많아질 지도 모른다.


그래서 용량이 크다는 이유로 TFS가 싫다는 이야기는 이야기의 논재에 벗어난 것 같다.





2. 읽기 전용 파일: 왜 이런 구조로 개발 되었는지 이해할 수 없지만 TFS에서 관리하는 모든 파일은 읽기 전용이다. 파일을 고쳤다고 하더라도 실제로 체크 아웃을 한 것이 아니라면 전혀 반영되지 않으며 이를 알 수 있는 방법은 Visual Studio 탭에 표시된 잠금 표시와 저장할 때가 되어서야 나오는 읽기 전용이므로 이를 해제해 달라는 말을 보았을 때다. 이 경우 일단 저장을 하고 다시 체크인을 한 뒤 다시 또 저장을 해야 한다. 만약 이 와중에 충돌이 발생하면 끔찍한 결과를 초래 한다. 읽기 전용 파일이 문제가 되지 않는다고 주장하는 사람은 빈번하게 충돌이 발생하는 환경에서 개발을 해보지 않은 것으로 판단 된다.

TFS의 소스를 파일을 내려받은 클라이언트의 파일은 읽기 전용이라는 점은 필자로 여러모로 불편한 점이 있다고 생각한다. SVN과 비교하자면 불편한 점이 확실히 맞다. 

 
TFS는 윈도우 탐색기나 커맨드 라인을 통해 파일을 수정하려 한다면 읽기 전용 파일이기 때문에 수정하여 저장할 수 없다. 이 경우 읽기 전용 파일 속성을 해제해 주어야 한다. 하지만, 수정하려는 파일을 체크인 하려고 한다면, 먼저 체크아웃을 해 주어야 한다. 체크 아웃을 하지 않으면 체크인 시에 수정된 파일로 간주하지 않기 때문에 변경 집합에서 제외되므로 체크인을 할 수 없다.

반면, SVN또는 기타 소스제어에서는 윈도우 탐색기 등에서 파일을 수정하면 알아서 체크아웃을 시키거나 체크아웃 과정을 자연스럽게 유도한다. 

이 부분에서 불만을 주장하신 분은 '일단 저장을 하고 다시 체크인을 한 뒤에 다시 저장을 해야 한다'는 방법은 잘 이해하기도 어렵거니와 잘못된 방법이다. 이 경우 필자가 이야기 한 것처럼 강제로 수정한 파일은 언제든지 다시 체크아웃을 한 후에 체크인을 하면 된다. 단, 특정 버전 받기를 하게 되면 모든 파일을 덮어씌우기 떄문에(Overwrite) 체크인 전에 특정 버전 받기를 실행하면 안된다. 물론 이런 경우는 극히 드물겟다. (최신 버전 받기는 변경된 파일만 덮어씌우므로 최신 버전 받기는 강제로 수정한 파일이 안전하게 수정된 내용으로 보존된다.)

하지만, 불만을 주장하신 분의 이야기 처럼 빈번하게 충돌이 발생하는 환경이라면 어떤 소스제어 솔루션을 사용하더라도 빈번하게 충돌이 발생하게 되어있다. 이런 충돌 상황을 빈번하게 겪어 충돌을 피할 수 있는 경험적인 감각을 익힐 수 있을 정도의 지능을 가진 사람이라면 대부분의 충돌이 발생하는 상황을 최대한으로 피할 수 있다.





3. 솔루션 파일 수정 무한 반복: 몇 가지 상황이 되면 이 경우를 만나게 된다. 예를 들면 VPN으로 사내 망에 접근할 때 TFS 서버 이름이 변경되는 경우 이다. 이 때 VPN으로 접근한 사람이 솔루션 파일에 TFS 이름을 바꾸면 나머지 사람은 그 솔루션 파일을 받은 뒤 다시 바꿔야 하고, VPN 작업자는 또 바꾸고, 이러한 무한 반복이 실행 된다. 또 다른 경우로는 솔루션 파일이 바인딩 되지 않은 경우 솔루션 파일을 바인딩 하기 위해서 솔루션 파일을 변경하고 다른 사람은 그 바인딩 정보를 솔루션 파일에 기록하기 위해서 변경하고 그러면서 자신에게 바인딩 하는 과정을 또 거치는 등 역시 무한 반복이 실행 된다. 발생하는 일 자체는 그리 짜증나지 않지만 무한한 반복으로 인해서 체인지셋 관리에 어려움을 겪게 된다. Subversion 또는 Mercurial은 근본적으로 이러한 일이 발생하지 않는다. 두 VCS에서 프로젝트 파일이란 단순히 관리가 필요한 텍스트 파일에 불과하기 때문이다.

이 부분은 글을 작성하신 분의 의견에 공감한다.


다만, SVN의 경우는 소스제어 바인딩 정보가 .svn 숨김 폴더에 저장되기 때문에 이런 문제가 발생하지 않지만, 폴더마다 .svn 숨김 폴더에 캐시된 데이터가 쌓이는 문제도 함께 가지고 있다. SVN 최신 버전에서는 폴더마다 .svn 숨길 폴더가 만들어 지는 문제를 최상의 폴더 한 곳에만 생기게 하도록 수정되었다고 한다.




4. .net 안쓰는 사람: Java 또는 PHP, Ruby, Python 등을 이용하여 개발할 경우 TFS로 인해서 얻는 반사 이익이 급격히 줄어든다. 솔루션 파일을 통한 간편한 프로젝트 추가 기능을 사용할 수 없고 디렉토리를 통채로 삽입할 경우 바이너리 파일이나 의미 없는 파일을 일일히 GUI로 제거해 주어야 한다. 반면 TortoiseSVN 또는 TortoiseHg는 Ignore list를 편집하여 간편하게 복수 파일을 관리하지 않을 수 있다. 또한 다른 도구와 다르게 비교 도구를 자체적으로 지정할 수 없고, 체인지셋 간 비교가 원활하지 않다. 이와 같은 단점으로 인해서 생산성이 저하 된다. 또한 Maven, Ant와 같은 오픈 소스 빌드 도구를 사용할 수 없고 MSBuild와 같은 도구만 사용가능하여 TFS 장점을 취하기 힘들다. 만약 Eclipse, Aptina 등과 같은 도구를 사용할 때는 2개의 IDE를 사용하거나 Teamprise를 사용해야 하는데 Teamprise는 MSDN Account가 있을 때 무료이다. Visual Studio Ultimate with MSDN 라이센스가 필요하다. 따라서 .net을 사용하지 않는 사람은 추가 비용이 발생할 수 있다는 것을 확실히 인지해야 한다.

필요 없는 파일의 확장자를 필터링하여 통채로 소스제어에 바인딩 또는 체크인할 수 있는 기능은 예전부터 TFS에 있는 기능이다. 그리고 비교 도구로 파일이나 체인지 셋, 폴더 등 비교하는 기능도 사용자가 별도로 설정할 수 있는 기능이 예전부터 존재한다.

그리고 라이센스 부분에서 TFS가 상용 솔루션인 점을 감안하면 당연히 클라이언트 라이센스 정책이 있다는 점은 당연하지 않을까?

이 부분도 다시 확인해 보시길...





5. Same Directory Archive: 사용자 디렉토리 경로와 TFS 경로를 일치 시키는 일을 한다. 사실 SVN과 Mecurial, Git와 같은 도구는 Point to Point, Central Repository의 특정 지점과 지점을 프로젝트로 연결함으로서, TFS 처럼 경로를 강제하지 않는다. TFS가 경로를 강제한다는 말은, Repository에 만들어진 Directory structure가 실제 사용자 Directory structure와 일치시킨다는 것이다. 일반적인 VCS에서는 프로젝트 단위로 연결하기 때문에 프로젝트 하위 Directory structure는 관리되지만 프로젝트 상위 Directory structure는 따로 관리하지 않는다. 관리하지 않더라도, VCS 자체에서 branch 별로 Directory를 만들거나 구조적인 관리가 가능하지만 사용자는 최종적으로는 프로젝트와 프로젝트가 연결되는데 반해 TFS는 프로젝트 상위, 하위 모든 Directory structure를 일치 시킴으로서 불편을 유발한다. 예를 들면, A, A', A'' 프로젝트가 있다고 가정하면 A'와 A''는 A 프로젝트 branch일 때 TFS는 관리자가 만든 구조로 세 프로젝트를 관리해야 하지만 SVN 또는 Mercurial은 A와 branch내부에 A'와 A''를 둘 수 있다. 개발자가 원하는 방식으로 프로젝트를 관리할 수 있다.

말씀하신 것처럼 소스제어의 폴더 구조를 반드시 따를 필요가 없다. 사용자가 작업영역(Workspace)를 이용하여 폴더 구조를 정의할 수 있다. 그리고 유용한 것 중, 공개 작업영역을 이용하면 누군가가 정의해 놓은 구조를 모든 사람이 공개 작업영역을 이용하여 같은 개발 구조를 가져갈 수도 있다.

이 부분도 다시 확인해 보시길...





6. 충돌 처리 미흡: 충돌이 일어날 때 TFS는 일반적으로 3가지 선택지를 준다. 다른 사람의 소스를 원복 하는 것, 내 소스를 원복하는 것, 자동으로 머지를 하는 것 3가지 선택지가 있다. 일반적으로 어떠한 도구라도 자동 머지는 믿을 수가 없고, 나 살자고 다른 사람이 작업한 결과물을 버리게 할 수 없기 때문에 내 소스를 버리게 된다. 이 경우 지금까지 작업한 것이 모두 사라지게 되는데 이를 방지하기 위해서는 Local Workspace를 제외한 또 다른 사본이 필요하게 된다. 이는 이중으로 머지를 하게 만드는 수고를 하게 함으로서 정말 고통 스러운 작업을 지속적으로 유발한다. 정말 이 과정에서 수없이 많은 충돌과 누락을 발생시키는데 도저히 이 방식을 용납하기 힘든 정도이다.

이렇게 고생하면서 충돌 처리를 하시는 점이 이해가 가지 않는다. 이런 소스의 버저닝 문제로 소스 제어를 사용하는데, 그 자체가 용납하기 힘들 정도이면 소스제어 기능을 충분히 활용하지 못하는 것 같다.




7. offline 상태에서 완벽한 무력화: 일반적으로 오프라인 상태에서 유효한 SCM은 분산 SCM인 Git, Mecurial을 제외하면 SVN도 유효하다고 보기는 힘들다. 다만, TFS와 SVN이 근본적으로 다른 점이라면, TortosieSVN을 이용한다면 어떤 파일이 수정되었는지 알 수 있다. 또한 작업 이전에 프로젝트를 모두 복사한 뒤 자유롭게 작업하고 그 결과물이 마음에 든다면 그 소스를 바로 커밋할 수 있다. 커밋한다면 실제 Repository에 반영된다. TFS로 동일작업을 해야 한다면 일단 사본을 만들고, 그 사본으로 작업한 뒤 원래 Local Workspace에서 수정한 파일을 "기억을 더듬어서" 일일히 Check out을 한 뒤 하나씩 복사해야 한다. 완벽하게 Check out이 끝난 뒤라면 통채로 복사해도 상관은 없지만 중요한 것은 Check out을 한 뒤 해야 하는 것이다. 만약 당신이 30개의 파일을 수정했다면 30번 Check out을 해야 한다. 만약 Git, Mercurial을 사용한다면 Local Repository에서 revision을 관리하며 작업을 지속하는 것이 가능하다.

TFS와 Visual Studio에서 온라인 상태로 바인딩된 소스제어가 오프라인으로 변경이 되고, 코드 변경 작업이 완료된 후 다시 온라인 상태로 전환이 되면 변경된 파일은 체크 아웃 상태를 유지한다. 그리므로 일일이 기억을 더듬어서 작업할 필요는 없다.

이 부분도 다시 확인해 보시길...





8. 비용: TFS는 단점만 가진 SCM이지만, 자체적으로 ALM 기능을 포함하고 있기 때문에 비용이 수반된다. ALM이 반드시 필요한 경우라면 가장 저렴한 비용으로 구축할 수 있지만 TFS를 사용함으로서 얻는 불이익이 ALM 도입 비용을 상회할 지 모른다. 또한 TFS 사용을 위해서 VS가 전혀 필요하지 않는 사람도 VS를 TFS 라이센스로 모두 구입해야 하므로 사실 비용이 썩 저렴하다고 보기 힘들다. 만약 Issue Tracker 또는 ALM이 필요하다면 Jira와 같은 도구를 도입하고 SCM을 따로 구축하거나 Trac + Mercurial, Launchpad + Mecurial 같은 솔루션을 사용하는 것이 현명한 방법이라 생각한다. 이를 통해서 VS가 필요없는 사람에게 TFS VS를 구입 해줄 필요가 없으므로 비용을 절감할 수 있고, 또한 VS 역시 TFS 버전으로 구매할 필요가 없으므로 비용을 절감할 수 있다. 심지어 SCM 서버도 리눅스 등을 이용하여 구축할 수 있으므로 서버 비용도 절감할 수 있다. (다만 리눅스 엔지니어를 채용하는 비용이 추가적으로 발생할 수 있습니다)

TFS 라이센스 부분에서 TFS를 사용하려는 사용자가 모두 Visual Studio를 구매할 필요가 없다. CAL(Client Access License)만 구입하면 된다.

그리고 오픈 소스를 이용하여 ALM 환경을 구성하는 것은 그 조직이나 그 사람의 자유이다. 그것이 관리하기 편하고, 사용자가 원한다면 오픈 소스를 사용하는 것도 좋은 방법이다. 다만, 오픈 소스를 이용하여 모든 ALM 환경이 구성된 경우, JRE 버전, 새로운 버전으로 업그레이드와 데이터 마이그레이션, 오류 등으로 자유 소프트웨어 진영에서 어떠한 지원도 받을 수 없을 것이다. 이런 점에서 상용 솔루션은 어떤 지원을 받거나, 책임의 소지를 확실히 구분할 수 있다.

이 부분도 다시 확인해 보시길...





 



  1. 안들이 2013.01.11 02:25

    일단 닷넷에서 자바로 넘어 온 입장해서 적자면..

    1. 윈도우 플랫폼이 너무 고가정책이다.
    어떤 걸 도입하든 MS제품으로 도배가 되는데 제품 라이센스 체계가 굉장히 복잡하고 비용또한 유닉스보다 저렴한 정도이지 리눅스의 무료(오픈소스)에 비하면.. 넘사벽입니다.

    흔히 유지비용을 MS에서 더 저렴하다고 하지만 리눅스기반에 오픈소스 제품군에 부분적으로 컨설팅이나 유료제품군을 사용하는게 훨씬 더 저렵합니다.

    2. 사용자 수가 절대적으로 적고 참고할 만한 자료가 없다.(멘토 부족..)
    라이센스 정책이 고가에 인증부분이 강화되면서 불법라이센스가 거의 사라졌지만 비례적으로 관련 정보나 생태계도 같이 사라지고 있습니다.
    (최근 윈도우 서버 2012가 출시 되었지만 네이버에서 검색해보면 아직도 MS에서 출시 이벤트를 한건지 출시 이벤트 정보만이 C&P 하듯이 몇페이지외에 실질적인 정보가 거의 없습니다..)

    3. 리눅스/자바/이클립스 체계가 충분한 개발장비가 되고 있다..
    VS 2012를 잠깐 써본 적이 있는데.. 정말 좋아졌더군요.(사실 경쟁자가 없을정도로 잘 만들었죠.. 무겁다는 것만 빼면..) 하지만 리눅스든 윈도우든 맥이든 자바에 이클립스만 있어도 충분히 개발환경을 만드는데 충분하더군요. 버전업이 되었다고 자바버전이 올라갔다고 이클립스를 갈아 치우지 않아도 되고..
    VS의 경우 이제 매년 갱신해야 하지요..(얼터밋이 1900만원이던가..매년..)


    안드로이나 애플이의 IOS 나 OSX 든 운영체재는 무료나 아주 저렴하게 풀고 개발환경도 무료나 저렴하게 풀고 플랫폼을 확산하는데 주력하고 있는데.. 또 제품들도 충분히 나와주고 있고요.. 그런데 비싼 OS에 개발환경을 갖출 이유는 없겠지요..자바로 만들어도 윈도우 대응도 되고요..-_-

    MS가 부활하려면 OS비용을 아주 낮은 비용으로 책정하고 (연 19800원? 이나 무료) 윈도우 스토어와 모바일 스토어를 통합해서 스토어를 통해서 수익을 적극적으로 만드는게 현실적으로 보입니다..
    하지만 MS는 포기하지 않겠지요.. 점유율이 떨어진 만큼 비용을 올려서 수익을 만들고 있으니까요.. 지금도..

  2. 안들이 2013.01.11 02:33

    윈도우 블루(차기버전)가 무료정책이고 윈도우 서버도 비용이 실 웹서비스나 웹서버로 도입가능할 정도로 저렴해지고 비주얼 스튜디오가 10만원 이하로 책정 되면 다시 윈도우 플랫폼을 써보고 싶네요..

    (도대체 받지도 않을 기술지원은 왜 포함하는건지.. msdn 문서도 문서화 제공부분에서 필수적인 것인데.. 장점이라며 비싸게 책정되고 있는 msdn 구독료는 이해하기 힘드네요..-__- 요즘 게임업체들도 모바일로 전환하거나 외국으로 나가면서 리눅스 플랫폼에 오픈소스 제품군을 적극적으로 준비하는 업체가 많더군요.)

  3. 아름드리 2013.01.11 09:36

    3번 항목의 .svn 숨김 폴더는 근래에 최상위 폴더에만 생성되도록 변경되었습니다.

  4. 공도 2013.01.13 08:42

    7번에 덧붙여서, Git의 로컬 커밋과 개념이 다르지만 Shelve 기능을 활용하면 팀에 영향주지 않고 개인적으로 커밋하는 효과를 얻을 수 있죠. 몇 번이든지 Shelve Set으로 저장했다가 다시 복원했다가 하다가 메인 트리에 올릴 수 있을 때 체크인 하는 방식으로 쓸 수 있고 또는 아직 체크인 하기 전의 코드를 팀원이 리뷰하는 용도로 쓸 수도 있고요.

  5. 지나가다 2019.11.15 13:14

    관리의 입장이 아니고,
    정말 현장에서 개발자들끼리 개발해서 소스 충돌 안나는 데는
    TFS 만한게 없다고 생각합니다.

    비용, 시간 다 따져도 TFS 의 압승이라고 생각이 되네요.
    SVN 이나 Git 쓰면서 해결 방법이 있다고 하는데..
    첨부터 문제가 안나야지, 그걸 왜 개발자들이 해결을 하고 있는지 이해가 안감.

    • POWERUMC 2019.11.19 10:06 신고

      모든 소스제어 제품군은 같은 파일을 수정하고 서로간에 동기화가 되지 않으면 무조건 충돌이 나게 되어 있습니다.
      머지 방법도 몇 가지로 분류할 수 있지만, 상황에 따라서 개발자가 직접 머지하게 됩니다.
      테스트 해보시면 이해가 되실거라 생각합니다.

  6. ㅋㅋ 2021.03.12 08:37

    정말 오래전 글이네요.
    있는 사이트에서 무슨 바람이 불었는지 TFS 를 잘 쓰고 있는데, git 으로 전환을 하려는거 같습니다.
    지금 gif 전환 단체 대화방을 만들어서 며칠 째 뭐가 안된다, 뭐가 안된다 하면서 대화를 나누는거 보면, 웃겨 죽겠네요.
    역시 조직에 미친 사람 하나 정도는 있어야.. 나머지 조직원들이 개고생을 하죠.

    가격은 나가지만, 서로 연관도 없는 수 많은 개발자들이 신경 안쓰고 소스를 관리할 수 있는 TFS 를 버리고, 소스의 delete/insert 가 주 기능인 git 으로 넘어가기 위해서 삽질하는 모습에서..
    세상이 아직은 웃을 일이 많다는걸 새삼 느낍니다.

C++/CX 에서 프로퍼티 사용

C++/CX에서 지원하는 프로퍼티는 C# 2.0까지 사용하는 방식의 get, set 을 구현 방식이다.

public ref class Test sealed
{
public:
    Test( void);

private
:
    String^ _name;

   

public:
    property String ^ Name
    {
        String^ get() { return _name; }
        void set(String ^ name) { _name = name; }
    }

};
}

   

   

C# 3.0 에서 프로퍼티 사용

하지만 C# 3.0에 와서는 더 편리하게 자동 구현 속성을 지원한다. 컴파일 시에 아래의 프로퍼티는 알아서 get_XXX(), set_XXX() 메서드로 변환하여 컴파일을 수행한다.

class Test
{

     public String Name { get; set; }

 
   // And
     public int Age { get; protected set; }

 
   // And
     public String Address { get; private set; }
}

   

   

C++/CX 에서 매크로를 이용하는 방법

C++/CX에서 프로퍼티를 선언하여 사용하는 방식에 불편함을 느껴, 다음과 같이 매크로를 만들어 프로퍼티 선언에 사용하였다. 

public ref class Test sealed
{
public:
       Test( void);

public
:
        PROPERTY(String ^, Name);
        PROPERTY(int32 , Age);
        PROPERTY_GET(String ^, FirstName);
        PROPERTY_GET(String ^, LastName);
};
}

   

아래의 매크로 코드를 사용하여 프로퍼티 선언을 쉽게 하자.

#define __PROPERTY_GET_FUNC (TYPE, NAME) TYPE get() { return m_##NAME; }
#define __PROPERTY_SET_FUNC (TYPE, NAME) void set(TYPE value) { m_##NAME = value; }
#define __DEFINE_PROPERTY (TYPE, TYPENAME) property TYPE TYPENAME
#define __PROPERTY (TYPE, NAME, IMPL) \
private: \
       TYPE m_##NAME; \
public
: \
        __DEFINE_PROPERTY(TYPE, NAME) \
       { \
       IMPL \
       } \

#define
 PROPERTY_GET (TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_GET_FUNC(TYPE, NAME))
#define PROPERTY_SET (TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_SET_FUNC(TYPE, NAME))
#define PROPERTY (TYPE, NAME)     __PROPERTY(TYPE, NAME, __PROPERTY_GET_FUNC(TYPE, NAME) __PROPERTY_SET_FUNC (TYPE, NAME))

   

   

※ 2012년 7월, 필자의 페이스북에서 공유한 정보이다.

윈도우 8, 요즘 인기가 많다. 일반 사용자들의 후기도 많이 보이고, 더불어 개발자들에게도 기존의 개발 경험을 살려 그래도 개발이 가능해서 인기가 많다. 더불어 C++/CX와 HTML5로 개발이 가능하다.

   

WinRT와 WinMD

그 중에서 C#/XAML을 이용하여 앱을 개발할 경우 Windows 8 Runtime(WinRT)의 라이브러리를 이용하여 개발하게 되는데, 마이크로소프트에서는 이 WinRT를 관리 언어가(Managed 플랫폼 환경) 아닌 C++로 만들어진 네이티브(Native)로 컴파일 되어 있다. 확장된 COM 기반이기 때문에 C#과 HTML5에서 모두 이 라이브러리 APIs 집합을 사용할 수 있다. 이것은 매우 큰 장점이 분명하다.

그런데 말이다. 이 WinRT 자체가 매우 성급하게 만들어진 라이브러리라는 것이 여럿 보인다. 그 중 네이티브로 컴파일된 환경에서 C#과 유사하게 런타임상의 객체나 타입 정보를 알아내기 위해 RTTI(RunTime Type Identification)을 C++/CX 컴파일 시에 자동으로 구현이 된다. 그리고 RTTI를 위해 사용되는 WinRT의 API 정보의 일부는 .WinMD 파일로 저장이 된다. 이를 윈도우 런타임 라이브러리(Windows Runtime Library)라고 하며, 이 라이브러리는 윈도우 8 앱을 개발하는 환경 모두에서 사용할 수 있다.

   

   

   

   

윈도우8 WinRT, XAML의 미완성을 의미하는 IXamlMetadataProvider와 IXamlType 인터페이스

여기에서 문제가 발생한다. 모든 객체들은 C++/CX과 C#에서 XAML(eXtensible Application Markup Language)에서 다룰 수 있다. 그리고 Windows.UI.Xaml 네임스페이스에 XAML과 관련된 APIs 집합이 있다. 그런데 WinRT는 XAML을 핸들링 할 수 있는 라이브러리를 완벽하게 구현해 놓지 못했다.

그래서 WinRT의 IXamlMetadataProviderIXamlType 인터페이스가 생겼다. 이 인터페이스가 WinRT가 XAML을 (꽁수로) 핸들링하기 위해 만들어진 인터페이스로 보인다.

코드에서 새로운 객체를 생성해서 사용하고 싶으면 var obj = new LoginView(); 와 같이 새로운 객체를 생성하는 new 키워드를 사용하면 된다.

객체지향을 완벽하게 표현하는 XAML에서도 마찬가지다. XAML에서 다음처럼 LoginView 객체를 생성할 수 있다.

   

   

여기에서 IXamlMetadataProvider가 미완성 XAML임을 증명해 준다. 윈도우8 모던 앱(Modern App)에서 XAML에서 객체가 생성되는 경우 컴파일 시에 자동으로 생성되는 XamlMetadataProvider.g.cs 파일에서 객체를 생성해 준다. (g는 Generated를 의미한다). 자동으로 생성되는 이 코드는 다음과 같은 코드가 포함이 되어있다.   

   

XAML에서 LoginView 객체 생성을 요청할 경우 IXamlMetadataProvider를 구현한 코드를 통해 객체를 대신 생성한다. 다시 말해, 하드 코딩이 되어있다.   

이는 매우 유감이다. 이는 즉, 런타임상에 동적으로 생성되는 객체나 앱 컴파일 시에 해당 클래스가 포함이 되어 있지 않다면, XAML은 객체를 생성하지 못하게 된다. 동적인 무언가에 의해 생성되는 객체는 XAML에서 명시적으로 객체를 생성할 수 있는 방법이 없어진 것이다. (단, 명시적인 호출)

   

   

사용자가 구현하는 IXamlMetadataProvider

일단 WinRT가 이렇게 구현되어 있으니, 어쩔 수 없다. 동적으로 생성되는 객체에 대해서 XAML에서 명시적으로 객체를 생성하기 위해서는 Custom IXamlMetadataProvider를 구현해 주어야 한다.   

아래는 필자가 개발 중인 Umc.Core.WinRT.dll 에 포함된 Custom IXamlMetadataProvider이다. 윈도우8 모던 앱을 컴파일할 때 MSBuild는 참조되는 어셈블리의 메타데이터를 검색하여 IXamlMetadataProvider 인터페이스를 구현한 객체를 XamlMetadataProvider.g.cs 코드에 자동으로 추가를 해준다. 그리고 컴파일이 된다.

   

   

   

IXamlMetadataProvider가 필요한 경우의 예시

아마 일반적으로 윈도우8 앱을 개발할 때 이 인터페이스를 구현할 필요는 없다. 하지만, 앱을 캡슐화하려고 하고, IoC(Inversion of Control) Container 등을 활용하고자 하고, 동적인 객체가 필요한 경우라면 이 인터페이스를 구현해야 할 필요가 있을 것이다.   


C#이 지원하는 System.Dynamic.ExpandoObject 객체를 생성한다면 이 객체는 XAML에서 명시적으로 호출을 할 수 없다.   

또, System.Dynamic.DynamicObject 를 구현하는 객체도 마찬가지이다. 아래는 Umc.Core.WinRT에 포함된 코드의 일부이다.

   

위와 같은 코드를 이용하여 동적인 객체를 생성하였다면, 명시적으로 구현한 클래스가 없으므로 당연히 XAML에서도 이 객체를 생성할 수 없다.   

이와 같은 경우에 IXamlMetadataProvider를 구현하면 된다.

   


그 밖에 필요한 것들

아마 WinRT는 윈도우폰7 의 API 보다 더 작다. 작은 만큼 없는 것이 많고, 포기해야 하는 것이 많다. 아래에 나열되는 구현체는 http://umcore.codeplex.com 의 필자가 만든 코드를 WinRT용으로 마이그레이션한 것들이다. 조만간 Umc.Core.WinRT도 공개할 것을 약속한다.   

1. WinRT 설계 자체가 IoC Container를 활용하기 매우 너그럽지 못한 구조이다. 그래서 기본적인 WinRT 구조를 많이 벗어난 구조를 직접 구현해야 했다.      


2. MarkupExtension등을 지원하지 않아 Markup 확장이 불가능하여 다른 형태의 XAML답지 못한 요소나 속성들을 따로 만들어야 한다. MarkupExtension등으로 IoC Container 등과 통합을 쉽게 할 수 있으나, 어쩔 수 없이 필자는 Attached Property로 아래와 같이 구현해야 했다.

또는 아래와 같이 LambdaExpression을 이용하여 동적 Compile() 하여 사용하는 형태로 다음과 같이 사용이 가능토록 할 것이다. 이 경우, 위의 방법보다 더 나은 성능을 보여줄 것이다.

 

3. Frame.Navigation은 객체의 Type으로 뷰를 이동한다. 하지만, 하나의 타입에 두 개의 뷰를 만들 수 있는 APIs 를 제공해 주지 않는다 따라서 INavigationService와 NavigationServiceFrame을 직접 구현하여 다음과 같이 하나의 Type 으로 생성되는 뷰는 여러 개의 뷰 객체를 생성할 수 있도록 했다.

다음과 같이 인터페이스를 정의하였고, 기존의 Windows.UI.Xaml.Controls.Frame은 Umc.Core.ModernApp.NavigationServiceFrame으로 대체하도록 하였고, UniquqKey로 구분하여 하나의 Type에 여러 뷰를 생성하여 네비게이션 할 수 있도록 했다.

   

4. IoC Container와 통합된 EventAggregator

뷰에 이벤트를 전달하거나 전역 이벤트를 전달하기 위해서 좀 쉬운 구조로 가기 위해 IoC Container에 EventAggregator를 함께 넣어보았다. Message 방식을 통해 뷰의 이벤트나 전역 이벤트를 구독할 수 있다.

   

그리고 구독을 뷰에서 제어할 수 있도록 하였다.

   

5. IoC Container와 통합된 인젝션. 객체의 인젝션(Injection-주입)은 다음과 같이 이루어진다.

   

6. IoC Container의 Configuration File 구성

이건 이전에 http://umccore.codeplex.com 에 구현해 놓은 것을 WinRT 용으로 마이그레이션 하였다. patterns & practices - Unity의 경우 Configuration을 지원하지 않지만, UmC Core의 IoC는 이를 한번 더 Wrapping 하였기 때문에 구성 파일로 만드는 것이 가능하다.

   

7. IoC Container에서 지원하는 AOP

이는 WinRT 구조상 이를 구현하기가 그리 쉽지는 않다. WinRT에서는 직접 MSIL(MS Intermediate Language)을 이용하여 런타임에 Instructions을 생성할 수 없다. 다만, APIs 가 모자란 만큼 모자란 대로 구현을 할 수 밖에 없다.

예를 들면, C#의 dynamic 을 이용하여 다음과 같이 구현 가능하겠다.

   

   

다음 버전의 윈도우8 앱 SDK 구조는 또 얼마나 바뀔까 걱정!

실버라이트의 일부와 윈도우 폰7에서도 그러하듯 이번 WinRT도 초기 버전이라는 생각이 든다. 생각해보라. 실버라이트 1,2까지 얼마나 개발자의 Needs를 만족해주지 못하였는지. 앞으로 등장할 윈도우 폰8 개발 SDK도 하위 호환성을 일부 포기한다고 알고 있다.   

현재까지 윈도우8 앱 개발 SDK 환경을 본다면, 기존에 가능하던 것들이 WinRT 환경에서 매우 많은 제약이 따른다는 것이 불편하다. 현재 WinRT와 윈도우8 앱 개발 플랫폼의 구조를 본다면, 차기 개발 SDK에서는 WinRT를 얼마나 개선할 수 있을지 알 수는 없다. 아마 WinRT/SDK를 만드신 분들도 참 많이 고민을 했을 것이다.   

다만 WinRT/SDK를 사용하는 개발자에게 그 동안 밟아왔던 원망스러웠던 수순을 밟지 않기를 바랄 뿐이다. 

어쨌든, 윈도우8 WinRT/SDK의 불합리하거나 불편했던 부분을 필자가 구현한 이전에 공개했던 http://umccore.codeplex.com 에 추가로 공개할 예정이다.

'O/S > Windows 8' 카테고리의 다른 글

윈도우 8, 무서운 드라이버와 궁합  (0) 2013.06.05
윈도우 8, 반토막짜리 WinRT와 WinRT SDK  (1) 2012.10.30
  1. 김종남 2016.05.15 21:03

    글 잘 보았습니다.

그 동안 VSTS2010.NET 팀 블로그에 관심을 갖어주신 모든 분들께 감사합니다. 저희 팀 블로그는 이 블로그를 통해 더 이상의 아티클을 발행하지 않으며, 새로운 팀 블로그로 이전을 하기로 하였습니다.

2009년, C++, 게임, 웹, .NET, 소프트웨어 개발을 각기 다른 분야에서 활동하시는 분들이 Visual Studio 2010이라는 개발 툴을 통해 만나게 되었고, 팀 블로그가 창설이 되었습니다.

2012년 9월 25일, 새로운 개발 툴이 한국에 출시되는 시점에서 저희 팀 블로그는 그 동안 소기의 목적을 달성하였다고 판단하며, 그리하여 현재의 팀 블로그는 더 이상 아티클을 발행하지 않으며 폐쇄합니다. 현재 vsts2010.net 도메인은 소멸 날짜까지 유지될 예정이며, 검색으로 유입되어 정보를 찾는 분들을 위해 팀 블로그의 아티클은 유지됩니다.

저희 팀 블로그는 새로운 목적과 목표를 위해 DEVWITH.COM 라는 이름으로 새로운 둥지를 틀었습니다.

Developers With..
HTTP:// DEVWITH.COM



VSTS2010.NET의 아티클 발행을 RSS로 구독하시는 분들은 DEVWITH.COM 도메인의 RSS 발행 주소로 변경이 됩니다. 이점, 불편을 드려 양해를 부탁 드립니다.

다시 한번 VSTS2010.NET 팀 블로그를 관심있게 지켜봐주신 모든 분들과 도움을 주신 많은 분들에게 감사의 마음을 전해 드리며 저희 VSTS2010.NET 팀 블로그는 이만 물러가겠습니다.

감사합니다.

+ Recent posts