Flip-Table-Net 은 자바 코드로 작성된 flip-table 을.NET 코드로 포팅한 프로젝트로, 콘솔에 데이터를 표로 표현해 줍니다.

설치

Command Line 에서 다음처럼 입력하거나,

nuget install flip-tables-net

Visual Studio Package Manager Console 에서 다음처럼 입력합니다..

Install-Package Flip-Tables-Net

또는 Nuget 패키지 관리자에서 flip-table-net 으로 검색합니다.

기존 자바에서 지원하던 기능

FlipTable은 헤더 정보와 데이터 정보가 필요합니다.

string[] headers = { "Test", "Header" };
string[][] data =
{
    new[] {"Foo", "Bar"},
    new[] {"Kit", "Kat"}
};
Console.WriteLine(FlipTable.Of(headers, data));
+======+========+
| Test | Header |
+======+========+
| Foo  | Bar    |
+------+--------+
| Kit  | Kat    |
+======+========+

데이터에 개행 문자열도 지원합니다.

string[] headers = { "One Two\nThree", "Four" };
string[][] data = { new[] { "Five", "Six\nSeven Eight" } };
Console.WriteLine(FlipTable.Of(headers, data));
+=========+=============+
| One Two | Four        |
| Three   |             |
+=========+=============+
| Five    | Six         |
|         | Seven Eight |
+=========+=============+

그리고 테이블 안의 테이블도 지원합니다.

string[] innerHeaders = { "One", "Two" };
string[][] innerData = { new[] { "1", "2" } };
string inner = FlipTable.Of(innerHeaders, innerData);
string[] headers = { "Left", "Right" };
string[][] data = { new[] { inner, inner } };
Console.WriteLine(FlipTable.Of(headers, data));
+===============+===============+
| Left          | Right         |
+===============+===============+
| +=====+=====+ | +=====+=====+ |
| | One | Two | | | One | Two | |
| +=====+=====+ | +=====+=====+ |
| | 1   | 2   | | | 1   |   2 | |
| +=====+=====+ | +=====+=====+ |
|               |               |
+===============+===============+

.NET 으로 포팅하면서 추가된 기능

flip-tables-net 버전은 .NET 이 지원하는 객체를 사용할 수 있습니다.

DataTableDataSet 을 사용하는 방법입니다.

var dt = new DataTable();
dt.Columns.Add("FirstName");
dt.Columns.Add("LastName");
dt.Columns.Add("Age");
var row1 = dt.NewRow();
row1["FirstName"] = "Junil";
row1["LastName"] = "Um";
row1["Age"] = 37;
dt.Rows.Add(row1);

Console.WriteLine(dt.FlipTablesFrom());
+===========+==========+=====+
| FirstName | LastName | Age |
+===========+==========+=====+
| Junil     | Um       | 37  |
+===========+==========+=====+

.NET nested entity object 객체는 다음과 같이 정의되어 있다면,

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
    public List<Person> Children { get; set; }
    public List<Name> Names { get; set; }

    public Person() { }
    public Person(string firstName, string lastName, int age)
    {
        FirstName = firstName;
        LastName = lastName;
        Age = age;
        Children = new List<Person>();
        Names = new List<Name>() { new Name("A", "B") };
    }
}

public class Person2
{
    public Name Name { get; set; }
    public int Age { get; set; }
}

public class Name
{
    public string First { get; set; }
    public string Last { get; set; }

    public Name() { }

    public Name(string first, string last)
    {
        First = first;
        Last = last;
    }
}
var person2 = new Person2()
{
    Name = new Name("Junil", "Um"),
    Age = 37
};
Console.WriteLine(person2.FlipTablesFrom());
+==================+=====+
| Name             | Age |
+==================+=====+
| +=======+======+ | 37  |
| | First | Last | |     |
| +=======+======+ |     |
| | Junil |   Um | |     |
| +=======+======+ |     |
|                  |     |
+==================+=====+

복합적인 데이터가 담긴 entity model 와 List<> 객체입니다.

var personList = new List<Person>
{
    new Person("Junil", "Um", 37),
};
personList[0].Children.Add(new Person("A", "B", 12));
Console.WriteLine(personList.FlipTablesFrom());
+===========+==========+=====+==============================================================+==================+
| FirstName | LastName | Age | Children                                                     | Names            |
+===========+==========+=====+==============================================================+==================+
|     Junil |       Um |  37 | +===========+==========+=====+==========+==================+ | +=======+======+ |
|           |          |     | | FirstName | LastName | Age | Children |            Names | | | First | Last | |
|           |          |     | +===========+==========+=====+==========+==================+ | +=======+======+ |
|           |          |     | |         A |        B |  12 |          | +=======+======+ | | |     A |    B | |
|           |          |     | |           |          |     |          | | First | Last | | | +=======+======+ |
|           |          |     | |           |          |     |          | +=======+======+ | |                  |
|           |          |     | |           |          |     |          | |     A |    B | | |                  |
|           |          |     | |           |          |     |          | +=======+======+ | |                  |
|           |          |     | |           |          |     |          |                  | |                  |
|           |          |     | +===========+==========+=====+==========+==================+ |                  |
|           |          |     |                                                              |                  |
+===========+==========+=====+==============================================================+==================+

FlipTablePad 옵션

var person2 = new Person2()
{
    Name = new Name("Junil", null),
    Age = 37
};
Console.WriteLine(person2.FlipTablesFrom(FlipTablesPad.Right));
+====================+=====+
|               Name | Age |
+====================+=====+
| +=======+========+ |  37 |
| | First |   Last | |     |
| +=======+========+ |     |
| | Junil | (null) | |     |
| +=======+========+ |     |
|                    |     |
+====================+=====+


Posted by 땡초 POWERUMC

댓글을 달아 주세요

Javascript-OOP-AOP-IoC / 자바스크립트 객체지향 프로그래밍

자바스크립트 객체지향 프로그램을 쉽게 하기 위한 소스 코드를 github 에 공개(https://github.com/powerumc/Javascript-OOP-AOP-IoC)했다.

자바스크립트로 객체지향 프로그래밍을 잘 하려면 배워야 하는 것들이 참 많다. 함수형 프로그래밍과 자바스크립트의 prototype 기반의 chain, 함수를 인스턴스로 사용하고, 객체지향적인 몇 가지 자바스크립트 패턴을 익혀야 하는 데, 쉽지만은 않을 것이다. C

가장 간단한 객체지향 코드를 보자. 이 코드는 Program 클래스를 상속 받은 Outlook 클래스가 있고, run() 메서드로 실행하는 코드다.

function INHERITANCE(PARENT, CLASS) {
	for(var p in PARENT) if(PARENT.hasOwnProperty(p)) CLASS[p] = PARENT[p];

	var PROXY 					= function() { };
	PROXY.prototype 			= PARENT.prototype;
	CLASS.prototype				= new PROXY();
	CLASS.prototype.constructor = CLASS;
}

var Program = (function() {
	Program.prototype.version = "1.0.0";

	return Program;
});

var Outlook = (function() {
	INHERITANCE(Program, Outlook);
	function Outlook() {
		Program.apply(this, arguments);
	}

	Outlook.prototype.run = function() { console.log("[" + this.version + "] Running... "); }
	
	return Outlook;

})(Program);

var outlook = new Outlook();
outlook.run();

너무 성급하게 이해하지 않아도 된다.

조금이라도 쉽게 Javascript 객체지향을 하기 위해 만든 라이브러리를 공개했으니...

설치

  • npm
npm install javascript-oop-aop
  • bower
bower install javascript-oop-aop-ioc

1. 기초

이 라이브러리를 이용하면 매우 쉽게 클래스를 선언할 수 있습니다. oop.class(...) 를 사용합니다.

oop.class( [parents,] classInfo )

  • 클래스 선언
var Program = oop.class({
	say: function() { return "Hello"; }
});

var p = new Program();
p.say();

// return "Hello"
프로퍼티 선언
  • 기본적인 프로퍼티 선언
// Define class.
var Program = oop.class({
	say: function() { return "Hello"; },
	name: "엄준일"
});

var p = new Program();
console.log("My name is ", p.name);

// output
My name is 엄준일
  • 사용자 정의 get/set 프로퍼티 선언
var Program = oop.class({
	say: function() { return "Hello"; },
	name: "엄준일",
	age: { get: function()      { return this._age; },
		   set: function(value) { this._age = value; }
});

var p = new Program();
p.age = 35;
console.log("My age is ", p.age);

// output
My age is 35

2. 상속

oop.class( parents, classInfo )

  • 부모 클래스 상속하기
// Define parent class
var Program = oop.class({
	version: "1.0.2",
	show: function() { 
		console.log("openning window."); 
		/* some code.. */
	}
});

// Define class.
var Outlook = oop.class( Program, {
	run: function() { console.log("running outlook program."); }
});

// Run code.
var outlook = new Outlook();
console.log("version " + outlook.version);
outlook.run();
outlook.show();

// Output
version 1.0.2
running outlook program.
openning window.
  • 자기 자신 참고 (this or self)
var Program = oop.class({
	version: "1.0.2",
	show: function() { 
		console.log("openning window.");
		/* some code.. */ }
});

var Outlook = oop.class( Program, {
	run: function(self) { // inject 'self' argument name.
		console.log("running outlook program.");

		// *** HERE ***
		// a method call inhertianced Program.show method.
		self.show();
	}
});

var outlook = new Outlook();
console.log("version " + outlook.version);
outlook.run();
//outlook.show();      remove this line.

// Output
version 1.0.2
running outlook program.
openning window.
부모 인스턴스 참조

var Program = oop.class({
	run: function() { console.log("run Program.") }
});

var Outlook = oop.class( Program, { // HERE inheritance Program class.
	run: function(base) \ 
		console.log("run Outlook.");  

		// *** HERE ***
		// You can call parent method from base keyword.
		base.run();
	}
});

// Output
// run Outlook.
// run Program.

3. 인젝션 (주입)

oop.inject( [argument], ... )

  • 매개변수 주입
var Program = oop.class({
	version: "v1.0"
});

var Outlook = oop.class( Program, {
	version: "v2.0",
	run: function(base, self) { 
		console.log("base version: "   , base.version)
		console.log("current version: ", self.version);
	}
});

var outlook = new Outlook();
outlook.run();

// Output
base version: v1.0
current version: v2.0
  • 컨테이너로부터 주입

4. 가로채기 - AOP

oop.interception( function, behavior )

oop.interceptionBehavior( before, after, exception, finally_ )

  • 클래스 또는 메서드 가로채기

    • 메서드 가로채기
var Program = oop.class({
	run: function(msg) { console.log("run Program. ", msg); }
});

// *** HERE ***
// Setup the interception a method
var p = new Program();
oop.interception( p.run, oop.behaviors.LoggingBehavior );

// Call a 'run' method.
p.run("Now running...");

// Output
------ enter interception ------
[Thu Nov 13 2014 09:29:41 GMT+0900 (KST)]  {}
run Program.  Now running...
------ end interception ------
  • 클래스 인스턴스 가로채기
var Program = oop.class({
	run: function()       { console.log("run Program.", msg); },
	terminate: function() { console.log("Terminated the Program.") }
});

// *** HERE ***
// Pass class instance arguments
var p = new Program();
oop.interception( p, oop.behaviors.LoggingBehavior );

// Call a 'run' method.
p.run("Now running...");
p.terminate();

// Output
------ enter interception ------
[Thu Nov 13 2014 09:29:41 GMT+0900 (KST)]  {}
run Program.  Now running...
Terminated the Program.
------ end interception ------
  • 사용자 정의 가로채기 (Behaviors)

    • 사용자 정의 가로채기 정의

가로채기 행위를 사용자 정의로 만드시려면 oop.interceptionBehavior 메서드를 호출합니다.

var customBehavior = oop.interceptionBehavior(
	function() { console.log("before"); },
	function() { console.log("after"); },
	function() { console.log("throw exception"); },
	function() { console.log("finally"); }
);

var Program = oop.class({
	run: function() { console.log("run Program."); }
});

var p = new Program();
oop.interception(p,  customBehavior);
p.run();

// Output
before
run Program.
after
finally

코드가 실행 중 예외가 발생할 경우 다음 처럼 exception 함수가 실행됩니다.

var Program = oop.class({
	run: function() { 
		console.log("run Program."); 
		throw "crashing... "; 
}});

var p = new Program();
oop.interception(p,  customBehavior);
p.run();

// Output
before
run Program.
throw exception crashing...   // HERE exception behavior.
finally


Posted by 땡초 POWERUMC

댓글을 달아 주세요

맥 앱스토어 다운로드

슈퍼 눈팅 (무료)

슈퍼 눈팅 (무료)

눈치 보지 말고 눈으로 팅하자… 눈팅!!

소셜 네트워킹을 하고 있는데 눈치 보인다면…
인터넷 쇼핑을 하고 있는데 눈치 보인다면…

이제 눈팅 하세요… 눈팅 ^_^

주요 기능

  • 인기 있는 웹사이트 목록
  • 투명도를 조절할 수 있음
  • 아이폰, 아이패드, 랩탑 중 원하는 디바이스 모드로 브라우징

v1.1

  • 페이스북, 트위터 등 공유 기능
  • 브라우저 캐시 및 쿠키 제거 기능
  • 소소한 버그 수정

스크린샷

Posted by 땡초 POWERUMC

댓글을 달아 주세요

MonoDevelop 한글판이 곧 업데이트 됩니다.

다운로드 : http://monodevelop.co.kr

MonoDevelop 통합 개발툴의 한글화를 위해 Github에 Pull Request로 게시하였고, 몇 일 후 특별한 문제 없이 MonoDevelop Master 브랜치에 병합이 완료 되었습니다.

[Ide] Translate to Korean language

차후 공식적인 배포에 의해 Xamarin Studio, MonoDevelop, MonoDevelop for Unity 와 같은 개발툴에서 한글 버전을 만나뵐 수 있을 것 같네요.

GitHub MonoDevelop Korean Repository

오탈자 및 버그 신고

Xamarin의 공식적인 버그 신고는 https://bugzilla.xamarin.com/ 에서 신고할 수 있습니다. 다만, 한글 번역과 관련된 버그를 처리해 줄지 모르겠네요.

  1. http://monodevelop.co.kr/ 에서 신고해 주시거나

    또는

  2. GitHub MonoDevelop Korean Repository 에 신고해 주시거나

    또는

  3. 직접 MonoDevelop Repository 에서 Fork 하셔서 작업하시면 됩니다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 컴포지트 2013.08.05 09:09 Address Modify/Delete Reply

    군말없이 merge 시켜주다니..ㅋㅋ
    노고에 감사드립니다.

  2. hellojin 2014.02.11 17:33 Address Modify/Delete Reply

    맥용 xamarin studio 를 사용하려하는데. 한글을 입력하면. 그냥 죽어버리는 군요.. 그래서. 한글화 된걸 사용해보고 싶은데.. 어떻게 해야되는지 통 감이 안오네요.. 어떻게 해야되는지 좀 알려주세요..~ 부탁드립니다.

    • 땡초 POWERUMC 2014.02.12 09:23 신고 Address Modify/Delete

      오 그래요?
      저는 같은 맥에서 죽지 않고 잘 써지는데요...

      기본 내장 외 한글 입력기를 쓴다거나 다른 이유가 있을 것 같은데,
      덤프를 떠주시면 제가 한번 봐 드리겠습니다.

  3. oiziee 2014.03.07 18:07 Address Modify/Delete Reply

    안녕하세요 위에 링크가 죽어있네요
    한글버전을 꼭 구하고 싶은데
    한글버전을 보내주실수 있으신가요?
    부탁드립니다
    pijunyel@naver.com

    • 땡초 POWERUMC 2014.03.07 18:24 신고 Address Modify/Delete

      한글버전은 Xamarin Studio에 함께 배포 되고 있습니다.
      아래의 링크에서 받으시고,
      환경 설정의 Language에 'Korean' 으로 변경해 주시면 됩니다.

      http://xamarin.com/download

  4. 지나가던이 2014.08.05 10:24 Address Modify/Delete Reply

    한글 버전 주석은 너무나도 감사드립니다.
    하지만, 버그가 있더군요... 조금 아쉽습니다.

    '아'를 입력할경우 '아'를 입력한 후에도 한번 더 무언가를 입력해주어야만 해결되는 현상이 있습니다.

    더 좋은 버전 기대하겠습니다.

  5. TeemoSoft 2015.01.07 01:37 신고 Address Modify/Delete Reply

    안녕하세요 맥에서 유니티 모노디벨롭 을 사용중인데 http://monodevelop.co.kr에서 받아서 사용해보니
    Assembly-UnityScript 로드 실패
    Assembly-UnityScript-firstpass 로드 실패

    이렇게 뜨네요 작업하는데는 큰 문제는 없지만 어딜 고치면 될까요?

JS-Lambda 자바스크립트 라이브러리를 공개합니다.


JavaScript Array Extensions 자바스크립트 오픈 소스를 개발한 데 이어 JS-LambdaLGPL 라이센스로 공개합니다.

JavaScript 에서 람다 표현식(Lambda Expression)을 사용할 수 있도록 만든 라이브러리 입니다. 자세한 내용은 아래의 소스 코드를 참고 하시면 됩니다.

Github: https://github.com/powerumc/js-lambda

JS Lambda

  • It is possible lambda expression that can be used JavaScript.
  • you just got a function F();

Simple Examples

// Before  
function func(a,b) {
    return a + b;
}  
console.info( func(4,6) );


// ** After with JS-Lambda **  
var func = F("a,b => a + b");  
console.info( func(4,6) );  

// Result  
10

Or you can invoke directly

// Before  
function anonymousMethod(a,b) {
    return a + b;
}  
console.info( anonymousMethod(4,6) );  

// ** After with JS-Lambda **  
console.info( F("a,b => a + b")(4,6) );  

// Result  
10

Callback Examples

// Before  
function callback( func ) {
    if( func ) func();
}  

callback( function() { console.info('My name is Junil Um'); } );  

// ** After with JS-Lambda **  
callback(  F("() => console.info('My name is Junil Um');")  );  

// Result  
My name is Junil Um  

With jQuery

// Before  
var li = $("item li");  

li.each( function(i, o) {
    $(o).addClass("some");
} );


// ** After with JS-Lambda **  
var li = $("item li");  

li.each( F("(i, o) => $(o).addClass('some');") );  


Posted by 땡초 POWERUMC

댓글을 달아 주세요

jQuery 1.7.1 버그 패치를 공유합니다.

jQuery 1.7.1 의 정식 버전은 인터넷 익스플로러(IE; Internet Explorer) 10 버전에서 런타임 버그가 존재한다. 이 버그는 jQuery 1.7.1 내부적으로, 그리고 jQuery UI 에 영향을 미친다.

그러므로 현재 jQuery 1.7.1 버전을 사용하는 버전에서는 필자가 공유한 코드를 사용하거나 패치 방법으로 코드를 수정하면 된다.


다운로드 및 추가정보






Posted by 땡초 POWERUMC

댓글을 달아 주세요

팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1

필자는 얼마 전에 다음과 같은 글을 썼다. TFS를 그다지 좋아하지 않는 분의 글을 검색 중에 우연히 찾게 되었고, 이에 대해 필자의 의견을 남긴 적이 있다.

개인적인 의견에 필자가 반박한 것이기도 했지만, 필자는 기능적인 면에서 반박을 한 것이라 상대방의 마음이 상할지 몰랐으나, 다시 돌이켜보면 미안한 맘이 계속 든다.

과거 필자는 MS Visual Studio ALM MVP 로서 이 제품을 써야할 이유를 말할 수 있었으나, 지금은 중간적인 입장에서 TFS를 쓰지 말아야 하는 진짜 이유도 써보고 싶었다. 최근 필자는 TFS 이외의 다양한 제품을 접하면서 TFS를 쓰지 말아야 하는 이유에 대해 더욱 확신이 들었다.

우리나라에는 전문가가 없다

우리나라에 팀 파운데이션 서버(Team Foundation Server) 전문가가 없다. 그러므로 당신에게 도움이 될 만한 전문가의 손길은 없을 것이다. 팀 파운데이션 서버(Team Foundation Server) 는 모든 것을 통합한 ALM(Application Lifecycle Management) 제품이다. ALM(Application Lifecycle Management)을 이해하려면 가장 먼저 소프트웨어 공학부터 시작하고 이해해야 한다. 그리고 사용자 측면과 관리적 측면 모두를 이해하고 솔루션 환경을 제공해야 한다.

ALM 제품을 쓰기전에 소프트웨어 공학을 설명하지 못하면 왜 팀 파운데이션 서버(Team Foundation Server)를 써야 하는지도 설명할 수 없다. 소프트웨어 공학은 50년도 되지 않는 짧은 역사를 가졌지만 공학적인 분야에서 이만큼 빠르게 변화하고 발전한 공학도 없을 것이다. 그래서 소프트웨어 공학이란 것이 정확한 기준을 섣불리 경계를 짓기도 애매한 학문이다.

그리고 소프트웨어 공학과 최근 빠르게 확산되는 애자일(agile)에도 많은 시간을 쏟아서 경험을 축척해야 한다. 소프트웨어 공학은 정량적인 측정이 가능하지만 애자일은 다르다. 팀원간의 관계와 팀이 축척한 또는 개개인의 경험이 큰 작용을 하고 애자일이란 툴적인 측면에서도 적극적이어야 한다. 필자도 소프트웨어 공학과 애자일을 공부하면서 처음 블로그에 쓴 글로부터 불과 4년 밖에 채 되지 않는다. 학문이라는 것은 알면 알수록, 배우면 배울수록 모르는 것이 점점 더 많아지는 것은 왜그럴까 ^^;

TFS 전문가는 골고루 다 알아야 한다. 이것 저것 모두 통합된 제품이므로 당연한 것이다. Team Foundation Server, Visual Studio Ultimate 외에 알아야 할 것들이 더 많다.

전문가적인 서비스를 제공하는 업체도 없다

한 마디로, 팀 파운데이션 서버(Team Foundation Server) 기술을 서비스하는 업체들은 다 망했다. 그러므로 만약 당신의 회사에서 TFS 컨설팅이나 서비스를 받고자 한다면, TFS 전문가가 올 확률은 거의 없다고 봐도 된다.

실제로 운영하다 장애가 생겨도 우리나라에서는 제대로 된 서비스를 받기 힘들다. 국내 팀 파운데이션 서버(Team Foundation Server) 전문가가 있는 업체가 한 군데도 없다. 한 곳의 전문 업체가 있었지만 TFS 사업을 접었다고 전해들었다.

필자의 과거 전 회사에서는 TFS 컨설팅을 했었고, 그런 업체가 몇 군데 더 있었지만 지금은 TFS의 수요도 없을 뿐더러 한 번 도입하면 다른 솔루션으로 갈아탈 수 없는 폐쇠성을 가지고 있어 도입의 실효성에 대해서도 논란이 있다.

image-1
이미지 링크

마이크로소프트 제품으로 발라야 한다

TFS 도입을 결정하는 순간 마이크로소프트(Microsoft)의 제품으로 완전히 발라버려야 한다.

가장 먼저 발라야 하는 것은 윈도우 서버(Windows Server) 이다. 가장 최신의 버전인 Team Foundation Server 2012는 윈도우 서버 2008 R2 부터 설치할 수 있다. 항상 최신 버전에 잘 적응을 하는 것이 이로울 것이다.

두 번째로 발라야 하는 것은 엑티브 디렉토리(Active Directory; AD)이다. 다른 LDAP(Lightweight Directory Access Protocol; 경량 디렉터리 액세스 프로토콜)의 OpenLDAP 은 전혀 지원하지 않는다. 예를 들어, 사내에서 리눅스(Linux) 서버에 OpenLDAP을 쓴다면 당장 OpenLDAP 데이터를 Active Directory로 마이그레이션을 해야할 지도 모른다. 좀 더 똑똑한 방법으로는 Active Directory와 OpenLDAP을 동기화 하는 방법도 있지만, 결국 유지 관리의 피로도는 급격하게 늘어날 것이다. (물론, AD 없이 쓸 수도 있지만, 없이 쓸 생각을 하면 앞이 캄캄하다)

세 번째로 발라야 하는 것은 Microsoft SQL Server 데이터베이스 제품이다. 왜 MySQL을 지원하지 않는지 기술적으로 이해하기가 힘들다. 물론 이 제품에서 분석 서비스(Analysis Services)와 리포팅 서비스(Reporting Services)를 제공하는데, 이거 안쓰고 싶어도 써야 한다. 이거 안쓰면 TFS가 매우 초라해 지기 때문이다.

네 번째로 발라야 하는 것은 IIS(Internet Information Services; 인터넷 정보 서비스)이다. 너무도 당연한 이야기지만…

다섯 번째로, 옵션으로 쉐어포인트(SharePoint)를 바를 수 있다. 이것을 바르려고 하는 순간 전용 서버를 고려해야 할 것이다.

예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다

모든 것이 통합된 TFS 구동하는 환경은 또 매우 복잡하고 오류의 원인을 찾는 것이 매우 힘들 수도 있다. 그러므로 MS 제품 이것 저것을 알아야 하고 계속…….. 배워야 하는 악순환이 계속된다.

필자는 6년이 넘게 거의 논스톱으로 직접 운영하는 TFS 서버가 있다. 서버도 직접 구매했었고, 소음 때문에 코로케이션으로 쓰다가 서버는 팔고, 결국 규모를 데스크탑 두 대로 줄여서 집에서 돌린다. 자동 업데이트가 설정이 되었는지 원인은 모르겠으나 서버 재부팅 후에 TFS 서비스들이 먹통이 되는 경우가 많았다.

실무에서도 많이 겪는 문제 중 하나가 윈도우 업데이트(Windows Update) 서비스이다. 필자가 몸담았던 회사 중에 운영 조직에서 윈도우 서버 전문가들이 직접 관리했지만, 가끔은 윈도우 업데이트 후에 정상적인 서버 작동이 되지 않아 윈도우 업데이트를 롤백(rollback) 하는 경우가 다반사였다.

대충이라도 모르면 어디서 튀어나온 트러블인지도 예측할 수 없다. 권한 구성만 해도 엑티브 디렉토리, IIS, MSSQL, 쉐어포인트 다 따로 해줘야 하는데 이 제품들이 서로 자기 오류가 아니라는 듯한 메시지만 보여준다.

제대로 된 기능이 하나도 없다

얼마 전에 필자가 쓴 글이다. 글의 요지는 ‘모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.’ 이다.

[ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)

크로스 플랫폼(Cross Platform)을 지원하는 Atlassian 의 제품 몇 개와 비교해 보자.

  • TFS 이슈관리 vs JIRA (atlassian)  
    음.. 이건 알만한 사람이면 다 안다. TFS를 JIRA와 비교하는 것이 실례이다. redmine과 같은 오픈된 제품에 비해서도 TFS는 장점보다는 단점이 더 많다. TFS 이슈관리가 MS OFFICE 플러그인을 제공하긴 하지만, MS OFFICE에서 플러그인으로 다루는 것이 더 불편하다. 플러그인을 너무 대충 만들어놓고 OFFICE 통합이라고 하는 것은 좀 무리수다.

  • TFS 코드뷰어 vs STASH (atlassian)
    이것도 TFS는 STASH에 비교하는 것이 실례이다. STASH의 특성이 조금 다르긴 하지만, github 의 인트라넷 버전이라고 봐도 무방할 것이다. 그만큼 TFS 코드뷰어에 비해 잘 만들어 졌다.

  • TFS 팀 빌드 vs BAMBOO (atlassian)
    TFS 팀 빌드는 할 수 있는 것이 거의 없다. BAMBOOJenkins에 비교 자체가 실례이므로 넘어간다. 이미 BAMBOO는 Amazon EC2 같은 클라우드와 통합이 되었다. 이에 비해 TFS는 이제 베타 버전으로 인터넷을 통해 서비스를 테스트 중이다. 특히 BAMBOO는 다양한 소스 제어를 지원하는 것도 장점이다.

Atlassian의 통합성은 TFS의 복잡한 구성보다 더 간단하다. Atlassian 제품은 각 제품간에 긴밀하게 통합이 되어있으며, 다른 3rd party 제품까지 다양하게 통합할 수 있다. Atlassian 은 제품마다 REST 형태의 API 를 제공하는데, 제품간에 응용 프로그램 수준의 인증이나 Oauth 인증 등 다양하게 각 제품을 연결할 수 있다.

필자는 Atlassian 제품은 모든 제품을 라이센스를 직접 구매하여 집에서 호스팅을 하면서 공부하는데, 서로 간에 긴밀하게 잘 통합되어 있으며, 상당히 많은 Addon이 제공되어 매우 쉽게 기능을 확장할 수 있다.

#1의 결론

이번 #1에서 이야기한 ‘팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1’은 주로 TFS의 외적인 부분에서 언급하였다. 앞으로 TFS 제품을 Atlassian과 다른 오픈된 ALM 솔루션과 기능적인 면으로도 비교해 볼 예정이다.

이슈 관리/ 소스제어/ 빌드/ 테스팅/ 릴리즈, 그 외에 다양한 면에서 비교해 보면서 진짜 이유를 조금씩 파헤쳐 볼 것이다.

image-2
이미지 링크, 이런 것도 통합인가?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지나가는사람 2019.08.28 15:25 Address Modify/Delete Reply

    이미 오래전 글이긴 하지만 본 김에 첨언하자면...

    TFS는 Windows VS를 사용하는 환경이라면 엄청나게 강력한 툴이며, 기능또한 강력하다 생각합니다.

    물론 언급한 것 처럼 마소의 제품군을 사용해야 그 위력이 재대로 발휘되는 만큼 어느정도의 마소 제품군의 강제성은 있습니다만 이 이유로 사용하지 말아야 한다는 것은 논리적 비약이라 볼 수 있겠네요.

    차나리 제목이 TFS 구축 시 유념해야 할 사항 혹은 TFS 기능을 100%로 끌어올릴 수 있는 방법 이정도가 제목이였으면 더 좋지 않았을까 싶네요..

  2. 지나가는사람 2019.08.28 15:31 Address Modify/Delete Reply

    덧붙여 MS제품에 잔지식이 많아야한다 즉, 어렵다는 것이 TFS가 좋지 않다라고 말하는 것도 논리적 비약이라 보여지네요.

    SQL Lite가 Oracle 혹은 Sql Server에 비해 가볍고 사용하기 편하다는 이유로 Oralce DB는 SQL Lite보다 좋지 않다. 라고 말하는 것이 억지라고 생각되거든요.

    물론 좋은 제품이라하면 기능의 접근성이 좋고 직관적으로 이해하기 편해야 하는 것은 맞지만 역으로 기능이 많고(복잡하고) 익히기에 어렵다는 이유로 그것이 좋지 않다라고 말하는 것은 아니라는 것이죠.

Javascript Array Extensions

Array Extensions는 Node.js 와 브라우저에서 사용할 수 있는 배열 라이브러리이다.

요즘 자바스크립트(JavaScript) 를 만지는 날이 많아져서 JavaScript 로 뭘 만들 수 있을까 하는 생각에 기억을 더듬어 보니 JavaScript 에서 배열을 다루는 일이 많았다. jQuery의 selector 등으로 DOM을 다루는데 효과적이지만, 배열을 다룰 때는 모라는 점이 많았다.

인터넷에 찾아보면 자바스크립트(JavaScript)로 배열을 다루는 오픈 소스를 발견하였다. 그 중 가장 호감이 가는 자바스크립트(JavaScript) 오픈 소스를 발견하였다. 자바스크립트로 C#과 가장 비슷하게 Enumerable과 LINQ를 구현한 자바스크립트다.

사실, 필자가 만들고 싶었던 디자인이 linq.js와 비슷했지만, 역시나 이미 나와있으므로 좀 더 Lightweight 하게 쓰도록 만들어 보았다. 요 몇일 3~4일 동안 틈틈히 만들었고, 더 큰 디자인으로 갈 생각은 없다.

완성도를 좀 더 높이면 npm, nuget 등에서 패키지로 배포할 예정이다.

설치하기

Nuget

PM> Install-Package JS.Array.Extensions

Node.JS

$ npm install js-array-extensions

required('js-array-extensions');

from Github

Array Extensions는 Github를 통해 배포하고 있다.

https://github.com/powerumc/array-extensions

git 를 이용하여 다음과 같이 소스 코드를 받을 수 있다. 소스 코드를 받을 디렉토리로 이동한 후 다음의 명령을 실행하면 된다.

git init  
git clone https://github.com/powerumc/array-extensions.git  

사용 방법은 매우 간단하다. README.md 에 포함한 예제 하나만 보면 쉽게 이해할 수 있을 거라 생각한다.

var arr = Array.range(1, 10)
               .select(function(i) { return { number:i, name:"POWERUMC " + i } })
               .where(function(o) { return o.number >= 5 })
               .take(3);  

// results var arr  
POWERUMC 5  
POWERUMC 6  
POWERUMC 7  

현재까지 지원하는 Array Methods 는 십여가지가 넘지만 부족한 것 같아서 좀 더 보강할 계획이다. 함께 코드를 개선하실 분은 Fork 하셔서 작업 후에 저에게 알려주시면 됩니다.

  • any
  • first
  • firstOrDefault
  • firstOrNew
  • last
  • lastOrDefault
  • lastOrNew
  • where
  • select
  • foreach
  • orderBy
  • take
  • skip
  • sum
  • average
  • range and Array.range
  • union
  • clone

image-1

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 황정현 2013.06.17 17:51 Address Modify/Delete Reply

    자바스크립트 학습용으로도 좋네요. ^^

VISUAL STUDIO 2012 UPDATE 2 한국어 패치

한국어 패치 개요

비주얼 스튜디오(Visual Studio) 2012 Update 2 버전을 설치한 사용자는 일부 프로젝트 템플릿의 주석 및 실행 결과가 영문으로 변경된다. 이 경우 여러 사람과 함께 소스 저장소로 체크인이 있을 경우 소스 코드의 포함된 한글/영문을 제대로 인식하지 못해 충돌(conflict)가 발생할 수 있다.

이 문제를 해결하기 위해 프로젝트 템플릿을 기존의 Visual Studio 2012 Update 1 ASP.NET MVC 프로젝트 템플릿에 포함된 한글로 모두 변경하였다.

파이썬(Python)으로 설치 파일을 만들었는데, 예외 처리를 하지 않아서 오류가 있을 수 있으니 오류 발생 시 수동으로 진행해 주시면 됩니다.

업데이트 대상

Visual Studio 2012 Update 2를 설치 후 ASP.NET MVC 4 프로젝트 템플릿이 영문으로 바뀌는 현상이 발생




한국어 패치가 필요한 대상

한 명 이상의 팀원과 공동 작업을 할 경우 영문/한글 주석을 충돌로 인식하는 문제가 발생할 수 있다.

  1. ASP.NET MVC 4 로 프로젝트를 만든 경우
  2. 한 명 이상의 팀원과 소스 제어(Source Control)에 체크인 해야 하는 경우

설치 방법

http://powerumc.github.io/VS2012_UPDATE2_KOR_PATCH/
  1. ZIP 파일을 다운로드 받는다. 다운로드 링크

  2. 다운로드 받은 ZIP 파일 압축을 푼다.

  3. CD VS2012_UPDATE2_KOR_PATCH-master 를 입력하여 압축 푼 폴더로 이동한다.

  4. CD dist 폴더로 이동한다.

  5. vs2012u2_patch.exe 를 실행한다.

    Downloading… c:usersumcappdatalocaltemptmprqavidmaster.zip
    99% |####################################################################### |

    Extract unzipping… c:usersumcappdatalocaltemptmprqavidmaster
    unzipdir = c:usersumcappdatalocaltemptmprqavidmasterVS2012_UPDATE2_KOR_PATCH-master
    Install… c:usersumcappdatalocaltemptmprqavidmasterVS2012_UPDATE2_KOR_PATCH-master
    BasicMvcWebApplicationProjectTemplatev4.1.csaspx Install… c:usersumcappdatalocaltemptmprqavidmaster
    VS2012_UPDATE2_KOR_PATCH-master

    …. 생략 ….

    Complated Installation VS2012 Update 2 Korean Patch

    Support by http://blog.powerumc.kr

지원 문의

  • 대표사이트 : http://powerumc.kr
  • 블로그 : http://blog.powerumc.kr
  • 커뮤니티 : http://devwith.com


Posted by 땡초 POWERUMC

댓글을 달아 주세요


최근 Git이나 Mercurial 과 같은 분산제어 방식의 소스 제어 제품을 무조건 맹신하고 찬양하거나 분산제어 방식보다 중앙집중형 소스제어 방식을 무조건 배척하는 현상이 일부 나타나고 있다.

리누스 토발즈(Linus Tovalds)와 같은 공산주의(Communism) 사상의 이상을 강조하는 철학이 담긴 Git은 GitHub.com을 통해 소스 코드를 공유함으로서 오픈 소스 진영에 매우 발전적인 기여를 하고 있음은 확실하다. 리누스 토발즈(Linus Tovalds)가 만든 것이라 그런지 훨씬 더 주목받고 있는 것 같다.

중앙집중 소스제어와 분산제어 소스제어 방식은 그 원칙과 근본적인 가치에 차이가 있는, 방법론으로 접근해야 할 것이다. 따라서 각 소스 제어의 방식마다 특징과 장단점이 있으며 ‘좋은 게 좋은 것 아닌가~’ 라는 간단한 답을 얻길 바란다.

필자는 중앙집중 소스제어와 분산제어 소스제어 방식의 장단점을 5가지의 관점에서 살펴보자. 중앙집중 소스제어(이하 중앙제어 방식)은 분산제어 소스제어 방식을 사용하는 몇 가지 소프트웨어를 제외한 대부분으로 보면 된다.

  • 중앙통제력
  • 정책주입력
  • 분기용이성
  • 사용편의성
  • 성능

그 외에 도움이 될만한 위키피디아(Wikipedia) 링크를 참고하기 바란다.

내용상 비교하는 대상은 중앙제어 방식은 ‘팀 파운데이션 서버(Team Foundation Server)’와 SVN을 많이 참조하였고, 분산제어 방식은 ‘Git’을 많이 참조하였다.

중립적인 관점에서 글을 작성하였으나 어느 한 쪽으로 편향이 되었다면 미리 그 점에 대해 양해를 구하는 바이다.

중앙통제력

이름에서도 알 수 있는 것 처럼 중앙집중적인 통제력은 기존의 중앙집중 방식이 분산제어 방식보다 유리한 점이 많다. 분산제어 방식은 자신이 서버로의 통제를 받는 동시에 제 3자에게 있어 자기 자신이 서버가 된다. 반면, 중앙집중 방식에서는 서버가 오직 물리적인 한 곳에 위치해 있다.

때문에 중앙집중 방식은 조직에 있어 정책적인 부분을 클라이언트에게 강제로 주입할 수 있는 여지가 많다. (물론 분산제어 방식도 가능하다) 중앙 서버 한 곳의 설정만으로 많은 클라이언트를 통제할 수 있다.


이미지 참조

그리고 모든 히스토리는 중앙 서버의 데이터베이스에 저장이 되기 때문에 클라이언트에게는 단지 소스 밖에 없지만, 분산제어 방식은 그렇지가 않다. Git의 스테이징 스토리지가 바로 클라이언트가 가지고 있는 데이터를 저장하는 (임시?)스토리지다.

조직에서 소스코드가 변경되는 주요 변경 이력은 매우 민감한 부분이고, 영업비밀과 직결되는 요소들이 많다. 응용프로그램이 연결되는 데이터베이스의 컬럼이나 테이블의 사소한 변경에도 응용프로그램은 수정되어야 할 수 있고, 이것이 응용프로그램의 소스코드에 반영이 되면서 소스제어에 이력을 남기게 된다.

정책주입력

정책적인 주입력은 중앙통제력과 유사한 부분이 많다. 중앙통제력이 크면 클수록 정책주임력은 향상된다. 중앙 서버의 정책적인 설정만으로 여러 클라이언트는 중앙 서버에 의해 통제받을 수 있다.

특히 ALM(Application Lifecycle Mamangement) 제품과 개발 IDE 제품간에 얼마나 긴밀하게 잘 통합이 되었느냐에 따라 정책주입력에 영향을 미친다. 통합이란 것이 양날의 검과 같아서 좋게 말하면 ‘All in One’이라 표현할 수 있겠고, 나쁘게 말하면 구성요소간에 강한 응집력으로 인해 제한된 확장이라 말할 수 있겠다.

ALM 통합의 장점

  1. 한 번의 구성으로 모든 것을 사용할 수 있다.
  2. 새로운 업그레이드도 한 번의 구성으로 모든 것을 구성할 수 있다.
  3. 개발툴과 통합되어 사용하기 쉽다.

ALM 통합의 단점

  1. 설치/구성 환경은 벤더에 의해 결정된다.
  2. 기능이 하나 하나가 완성도가 높지 않아 기업 및 도메인 환경에서는 추가 개발이 필요한 경우가 많다. (범용성을 위해…)
  3. 오픈 소스 ALM 도구보다 쓸 수 있는 도구들이 적다. (애드인/플러그인)
  4. 다양한 외부 도구와 연동이 제한된다.

분기용이성

분기(Branch)는 나무에서 여러 가지(Branch)로 뻗어 나가는 것을 일컬어, 하나의 소스 코드에서 여러 가지(Branch)로 소스 코드를 키울 수 있다. 특히 분산 제어 방식에서 분기가 얼마나 유용하고 효율적으로 사용할 수 있는지 잘 알 수 있다.

중앙 제어 방식에서의 분기는 곧 변경 이력으로 반영되어 영구적으로 분기 이력이 남게 된다. 때문에, 분기를 개인적인 용도로 사용하는 것이 힘들다. 소스 제어의 파일 시스템 구조를 복잡하게 만들 수 있고 구성원 개개인이 이를 핸들링 하기에는 전체 제품의 소스 코드에 좋지 않은 영향을 미칠 수 있다.


이미지 참조

반면, 분산 제어 방식의 경우 분기는 반드시 알아야 할 매우 효과적인 기능 중 하나로 볼 수 있다. 위에서 언급 했듯이 서버에게는 클라이언트가 되지만, 제 3자에게는 곧 서버가 된다. 즉, 로컬 서버(클라이언트)에서 자체적으로 분기가 가능해진다. 클라이언트에서 분기와 서버로 Push되는 정보는 다르므로 서버의 정책이나 구조에 영향을 최소한으로 적게 미치게 된다.

하지만, 중앙 제어 방식에서도 이런 단점은 충분히 극복할 수 있다. 분기는 병합(Merge)이라는 조건을 전제로 수행되는데, 만약 병합이라는 전제 조건이 없다는 가정하에 이와 유사하게 문제를 해결할 수 있는 방법이 있다.

중앙 집중 방식의 소스 제어 제품마다 기능적으로 다른 점이 있겠지만, 다중 작업 영역(Workspace) 또는 보류(Shelve) 기능을 이용하여 로컬 분기(Local Branch) 기능을 유사하게 흉내낼 수 있다. (물론 진정한 의미에서의 분기 목적과는 다소 차이가 있다)

사용편의성

사용편의성은 소스 제어를 사용하는 사용자가 얼마나 소스 제어를 편하게 사용함을 의미한다. 이를 언급하기 전에 사용편의성은 개개인의 경험적인 부분에서 다를 수 있다.

먼저, 분산제어 방식의 대표적인 Git을 험오하는 이유 10가지에 대해 쓴 블로그 내용을 참고하자.

Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.
이하 생략…
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

대부분의 소스 제어 명령은 GUI(그래픽 인터페이스)와 CMD(명령줄 인터페이스) 방식을 제공한다. 주로 GUI 방식은 개발툴과 연동이 되는 확장 또는 플러그인 방식으로 제공되고, CMD 방식은 소스 제어 제품 자체에서 제공하는 고유의 기능으로 제공이 되는 것이 대부분이다. 그래서 소스 제어를 사용하는 개발자가 어떤 환경에서 개발하느냐에 따라 GUI 또는 CMD 방식으로 갈리는 경우가 많다.

먼저, 이클립스(Eclipse) 또는 비주얼 스튜디오(Visual Studio)와 같이 비주얼을 강조하는 개발툴에서는 GUI 방식의 소스 제어 플러그인을 사용하는 경우가 대부분이다. 이런 환경에서는 키보드와 마우스를 함께 사용하는 경우이고 아이콘(icon)으로 수정된 파일을 바로 확인할 수 있다.

반면, SVN 또는 Git 의 CMD 도구의 사용이 익숙해질 경우 상당히 빠르게 명령을 사용하거나 결과를 확인할 수 있다. 그리고 개인용 컴퓨터의 성능에 거의 영향을 받지 않고 소스 코드를 개발할 수 있고, 손이 마우스와 키보드로 번갈아가며 사용할 필요가 없어 익숙한 사람에게는 더할 나위 없이 편리하다. 더불어, SSH와 같은 단순 Plain Text 환경에서도 제어가 가능하기 때문에 사용에 있어 거의 제한도 없다.

하지만 대체적으로 두 방식 모두 GUI 도구를 제공하거나 GUI 공개 소프트웨어가 많기 때문에 취향에 맞에 사용할 수 있다.

성능

중앙제어 방식은 모든 동작이 서버 측의 허가 없이는 불가능하거나 반드시 서버와 연결이 되어야 한다. 인트라넷이라면 크게 성능의 손실은 없겠지만, 지역이 다른 사람과 오픈 소스 개발을 하거나 클라우드 소스 컨트롤을 사용하는 경우 매우 느리다.

분산제어 방식은 모든 동작이 대부분 로컬에서 이루어 진다. Push, Fetch 같은 동작만이 서버와 연결이 필요하다. 때문에 성능이 매우 좋은 것이 특징이다. 하지만, 중앙제어 방식과 다르게 많은 데이터를 로컬에 저장해야 하므로 중앙제어 방식보다 로컬에 충분한 용량이 확보되어야 한다.

결론

몇 가진 기본적인 관점에서 깊지 않은 내용으로 중앙제어 방식의 소스제어 컨트롤과 분산제어 방식의 소스 컨트롤을 살펴보았다.

필자에게 어떤 것을 사용할지 묻는다면, 작은 개발 조직과 기업 환경에서는 중앙제어 방식을 권장하고 싶다. 많은 소프트웨어 개발 조직에서 여전히 통제하에 소프트웨어 개발을 하기를 원한다. 그리고 암묵적인 소프트웨어 개발 프로세스를 명시적인 프로세스로 개선하고자 하는 곳도 과거보다 많이 생겼다. 이런 환경은 중앙제어 방식이 더 효과적이라 믿는다.

반대로 분산제어 방식은 패키지를 개발하는 기업이나 IT 컨설팅, 국지적 개발 환경이 필요한 경우 효과적일 것이라 생각한다. 물론 기업 환경과 맞지 않는다는 것이 아니며, 통상적인 경우를 말한다.

필자는 우연히 Stack Overflow에서 매우 흥미로운 주제를 발견하였다. 바로 [Git vs Team Foundation Server [closed]]11 인데, 어느 개발팀의 분산제어 방식과 중앙제어 방식의 대결 구도에서 어떤 것을 선택해야 할 것인가에 대한 논의였다. (참고로 필자는 최근 git을 더 좋아한다.)

내용인 즉, 자신의 개발팀에 Git를 도입시켰으나, 개발 팀원들은 팀 파운데이션 서버(Team Foundation Server)로 바꾸길 원했다. 이 질문에 추천 답변의 내용은 ’Git을 버려라. Git을 계속 쓰다가는 계속 비난을 받고 싸우게 될거다’고 한다.

결론은 소스제어 컨트롤(Source Control)은 개인이 아무리 좋고 훌륭한 소스제어라고 생각하더라도 다른 사람들은 그렇게 생각하지 않을 수 있고, 선택에 있어서 다수의 의견에 귀 귀울이는 것이 좋을 것 같다.

I think, the statement

everyone hates it except me

makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.
Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):
automatic backup of the whole repo: everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don’t worry, take one of those present on every workstation.
offline repo access: when I’m working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, anything.
But as I said: I think that you’re fighting a lost battle: when everyone hates Git, don’t use Git. It could help you more to know why they hate Git instead of trying them to convince them.
If they simply don’t want it ’cause it’s new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?

Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what’s the problem. Convince them and you’ll convince the rest of the team.

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이성훈 2018.05.10 14:53 Address Modify/Delete Reply

    분산제어 서버를 이용하면 프라이빗 블록체인과 차이가 없는건가요..?!

[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 자체의 문제는 아니다.




이런 말을 해주고 싶다.

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 나그네 2013.01.13 17:36 Address Modify/Delete Reply

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

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

  2. JIN 2016.08.29 11:56 Address Modify/Delete Reply

    정성스레 작성하신 글 잘 보고 갑니다..
    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시에 수없이 많은 질문을 야기할 가능성을 줄여줄수 있다는 점도 큰 몫이었습니다.