|
|
|
여러 프로젝트를 위한 개발 환경 구성 (초안)
Development/Environment |
2012/01/29 11:41
|
|
|
소프트웨어 개발이 이루어질 때 한 가지 개발 작업만 진행하게 된다면 모르겠지만,
기존 소프트웨어 유지 보수 작업이 생길 수도 있고,
누가 물어보았을 때 해당 프로그램 개발 소스를 봐야 할 수도 있고..
무엇보다 여러 프로젝트에 할당되어 개발해야 하는 경우도 있다.
이와 같은 상황에서, 나에게 직면한 가장 큰 문제는
일명 context switching이 잘 되지 않는다는 것이다.
A를 개발하다가 잠시 B를 개발하려고 하면, 개발 프로그램을 하나 더 띄운다던지,
관련 문서들을 찾기 위해 이것저것 노력해야 한다던지..
따라서 본 문서는 여러 프로젝트와 관련되어 개발 작업을 할 때, 조금 더 편한 개발 환경을 구성하는 방법은 어떤 것들이 있을까 하는 고민에서부터 출발하고자 한다.
특히 다음과 같이 의사소통 시스템이 아예 다른 경우는 context switching이 조금 더 어렵게 된다.
- ex1. 프로젝트 A는 aaa1@aaa.com 이메일을 통해 의사소통을 하지만, 프로젝트 B는 aaa2@bbb.com 이메일을 통해 의사소통을 하는 경우
- ex2. 프로젝트 A는 trac을 통해 프로젝트 B는 mantis를 통해 이슈 관리를 하는 경우
- ex3. 프로젝트 A는 trac 1을 통해, 프로젝트 B는 trac 2를 통해 이슈 관리하는 경우
ex1의 경우, 가장 편리한 방법은 여러 이메일 계정을 관리해 주는 메일 클라이언트 (ex. Outlook, Thunderbird)를 쓰는 방법이 될 것이다.
ex2의 경우에는 이슈 관리 provider가 다르므로 2개의 web page를 띄우면 문제가 없지만
ex3의 경우에는 trac 1에 대해서는 Chrome을, trac 2에 대해서는 FireFox를 이용하여 해결하는 방법이 한 솔루션에 대한 예시로 작용할 수 있을 것이다.
이러한 context switching 문제(?)와 관련하여 구글에서도 사용자들의 이러한 고민을 어느 정도는 생각하고 있는 것 같다.
한글 웹페이지에서 대략 검색해 보니 최대 3개의 계정까지 멀티 로그인을 지원한다고 한다.
멀티 로그인에 대한 상세한 정보는 다음 URL 참고
- http://support.google.com/accounts/bin/answer.py?hl=ko&answer=181599
사실 이와 같이 여러 가지를 개발하는 것과 관련된 문제는 개발 라이브러리의 충돌과 같은
개발 이슈에서도 발생 가능하다.
이클립스의 경우 workspace를 다르게 두어 사용 가능하겠지만, 아무래도 2개의 별도 이클립스를 실행하는 게 JVM을 사용해서 그런지 많이 부담스러운 게 사실이기는 하다.
아니면 각각 프로젝트에 대해 가상 머신을 만들어 세팅하고 각 가상 머신에 원격으로 접속하여 개발하는 방법도 있을텐데.. resource 낭비가 생기는 것은 어쩔 수가 없는 듯.
|
|
|
이 글의 관련글(트랙백) 주소 :: http://livelock.tistory.com/trackback/27
|
|
|
|
|
|
DB 호환성 문제
Development/SQL |
2011/08/21 15:41
|
|
|
SQL Server 2000->2005 마이그레이션 등을 수행한 후,
2005부터 지원되는 SQL문을 사용하려고 하는 경우, 다음과 같은 메시지가 나타날 때가 있다.
Msg 325, Level 15, State 1, Line 6 'PIVOT' 근처의 구문이 잘못되었습니다. 이 기능을 사용하려면 현재 데이터베이스의 호환성 수준 값을 더 높게 설정해야 합니다. 저장 프로시저 sp_dbcmptlevel에 대해서는 도움말을 참조하십시오.
에러 메시지에서 볼 수 있듯이, 호환성과 관련된 문제이다.
따라서 다음과 같은 구문을 실행하여 호환성 문제를 해결한다.
EXEC sp_dbcmptlevel '[Database 명]', [호환성 번호]
호환성 번호는 80: SQL Server 2000, 90: SQL Server 2005 등이다.
|
|
|
이 글의 관련글(트랙백) 주소 :: http://livelock.tistory.com/trackback/25
|
|
|
|
|
|
SELECT시 클러스터형 인덱스를 사용해도, ORDER BY를 반드시 사용할 것!
Development/SQL |
2009/05/05 23:02
|
|
|
MS SQL Server Books Online (온라인 설명서)에서, Clustered indexes(클러스터형 인덱스)를 검색해 보면 아래와 같은 설명을 볼 수 있다.
영문: "An index on the columns specified in the ORDER BY or GROUP BY clause may remove the need for the Database Engine to sort the data, because the rows are already sorted. This improves query performance." 한글: "ORDER BY 또는 GROUP BY 절에 지정된 열에서 인덱스를 만들면 행이 이미 정렬되어 있기 때문에 데이터베이스 엔진이 데이터를 정렬할 필요가 없습니다. 따라서 쿼리 성능도 향상됩니다."
BOL의 설명이 조금 애매한데, 이에 대해 'Clustered index를 만들면 행이 이미 정렬되어 ORDER BY를 사용하지 않아도 된다'라고 잘못 해석할 수도 있을 것 같다.
실제로, 다음과 같은 예제를 실행해 보면 SELECT시 클러스터형 인덱스를 사용하면, 굳이 ORDER BY를 생략해도 될 것 같다는 착각을 준다. -----------------------------------------------------------------
CREATE TABLE dbo.AA ( id INT NOT NULL, VARCHAR(10) NOT NULL ) GO DECLARE @I INT SET @I = 1 WHILE @I < 1000 BEGIN INSERT INTO dbo.AA VALUES( @I, CONVERT( VARCHAR(10), @I ) ) SET @I = @I + 1 END GO CREATE CLUSTERED INDEX CX_AA_id ON dbo.AA(id) --DROP INDEX CX_AA_id ON dbo.AA --TRUNCATE TABLE dbo.AA GO
SELECT * FROM dbo.AA SELECT * FROM dbo.AA ORDER BY id GO
----------------------------------------------------------------- 실행 계획 비교: 위 실행 계획과 같이, ORDER BY를 안 써도 똑같이 수행되기 때문에 ORDER BY가 필요없다고 생각할 수 있다. 그러나, 아래의 예제로 실행해 보면 실행 계획이 다르며, 따라서 ORDER BY를 사용하지 않으면 정렬되지 않은 데이터를 얻는다. (출처의 예제 소스를 위와 비교하기 위해 변형하였다.) ----------------------------------------------------------------- CREATE TABLE dbo.order_by ( id int identity(1,1) PRIMARY KEY CLUSTERED , some_field VARCHAR(10) )
DECLARE @I INT SET @I = 1 WHILE @I < 1000 BEGIN INSERT INTO dbo.order_by (some_field) VALUES ( CONVERT( VARCHAR(10), @I ) ) SET @I = @I + 1 END GO
CREATE NONCLUSTERED INDEX ni_order_by_some_field ON dbo.order_by (some_field ASC)
SELECT * FROM dbo.order_by SELECT * FROM dbo.order_by ORDER BY id
----------------------------------------------------------------- 실행 결과(위 SELECT에 대해 TOP 5로 Query를 수행하였다.): ORDER BY를 안 쓰니, 정렬되지 않았다! 실행 계획: 2개가 서로 다르다. 이와 같은 경우가 있을 수 있기 때문에, 절대로 'Clustered index를 만들면 데이터가 물리적으로 정렬되므로 order by를 사용하지 않아도 정렬된 데이터를 얻을 수 있다' 라는 착각을 하면 안된다! 이 점에 대해 다소 의아하게 생각할 수 있는데, SQL Server는 RDBMS이고 ORDER BY를 명시하지 않은 SELECT 결과에 대해서는 정렬되지 않은 결과를 SQL Server에서 준다고 하여도, SQL Server는 정상적으로 작동한 것이라고 할 수 있기에.. Clustered index를 만들었기에 ORDER BY를 쓰지 않는 실수를 해서는 안된다. 조금 더 자세하게 살펴보고자 한다면, 관련 출처 및 출처에 기재된 URL을 참고.. - http://social.technet.microsoft.com/Forums/ko-KR/transactsql/thread/97fdcd34-dfb7-45fb-b495-89b24a8dc16d |
|
|
이 글의 관련글(트랙백) 주소 :: http://livelock.tistory.com/trackback/4
|
|
|
|
|
| 부족하지만 남고 싶기도 한 어느 Developer였던 사람의 블로그입니다. (다시 돌아올지도..) |
«
2012/05
»
| 일 |
월 |
화 |
수 |
목 |
금 |
토 |
| |
|
1 |
2 |
3 |
4 |
5 |
| 6 |
7 |
8 |
9 |
10 |
11 |
12 |
| 13 |
14 |
15 |
16 |
17 |
18 |
19 |
| 20 |
21 |
22 |
23 |
24 |
25 |
26 |
| 27 |
28 |
29 |
30 |
31 |
|
|
|
|
Total : 3,852
Today : 1
Yesterday : 4 |
|
|