Programming is Fun

Framework는 분명한 제어의 역전기능이 적용되어 있어야지 된다.

Application code는 Framework가 짜놓은 틀에서 수동적으로 동작할 수 있어야지 된다.

라이브러리를 사용하는 Application 코드는 Application의 흐름을 직접 제어한다.

단지 동작하는 도중에 필요한 기능이 있을 때, 능동적으로 Library를 사용한다. 

반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해서 사용된다. 

보통 프레임워크 위에 개발된 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다. 

1. 속도가 빨라졌다. 

전에 VS2010이 뭐같은 녀석이였는지, VS2010에서 시작되는 화면을 보다보면 속이 터져버릴것만 같았다. 

VS2012의 경우에는 속도 자체가 빨라진것보다 Solution을 Lazy Loading을 시켜서 좀 더 빨라보이는 트릭을 사용한다. 

물론 트릭뿐 아니라, 실질적인 속도 자체도 더 빨라졌다. UI의 반응 속도라던지, compile 시의 속도가 향상된 것이 눈에 보인다. 

(물론 측정한것은 아니다. 체감으로.. )

2. 코드의 가독성이 높아졌다.

VS2010의 화려한 인터페이스에서 VS2012의 조금은 투박한 인터페이스를 보면 이건 퇴보가 아닌가. 하는 생각이 들지만, 이 상태로 3~4 시간 코딩을 해보면 확실히 느낌이 다르다. 전에 보이던 인터페이스의 화려한 색이 은근히 가독성을 떨어트리고 있었던 것이 아닌가 하는 생각이 들 정도로 UI 자체에서의 코드에 대한 집중도를 높여준다. 

3. Solution Explorer가 향상되었다.

기존에는 Pending Explorer, Solution Explorer 등의 여러 파일 탐색기에서 각각의 다른 기능을 수행하고 있다. 그런데 거의 모든 기능이 Solution Explorer에 통합이 되었다. 간단한 Toggle 동작만으로 SVN에 올려야지 되는 파일리스트 및 변경사항을 알아내는데 도움을 준다. 

또한, Solution Explorer에서 Class의 method tree를 열수 있는 기능이 추가 되어서, 파일을 하나하나 열지 않고 객체의 method를 직접 찾아가는데 도움을 준다. 

4. Console Application과 Class Library의 default platform이 "Any CPU"로 변경되었다.

개인적으로는 이 점 하나만으로도 VS2010을 버리고, VS2012로 갈아타야지 된다고 생각한다. VS2010은 default platform이 "x86"이기 때문에 개발후 배포작업에 있어서 Reference Linking 작업을 실수를 하거나, x64 system에서 개발하는 개발자와 x86 system에서 개발하는 개발자간의 suo 파일이 달라져서 전체적인 시스템이 달라진것과 다름없는 형태를 보이고 있었다. 특히 svn이나 git에 올리지 않는 suo 파일에 설정된 platform 정보가 딸려다니기 때문에 타개발자와의 소스 호환에도 어려움이 있고, 이 부분이 꼬이면 한 30여개가 넘는 project들 중에서 어떤 msil이 32bit로 따로 설정된것인지 찾는 귀찮고 초보 개발자들은 매우 당황하는 일들을 원천적으로 막을 수 있다. (무조건 "Any CPU"로 개발하는거다!)

5. solution 파일과 proj 파일이 VS2010과 공유된다.

이건 MS가 VS2010 SP1에서부터 준비한 결과인것 같은데, solution과 proj 파일이 VS2010과 VS2012간에는 차이가 없게 열리거나, VS2012에서 migration된 proj 파일이 VS2010에서 아무런 문제 없이 사용이 가능하다. 단 NuGet 1.X 를 이용한 package가 있는 경우에는 VS2012에서 에러가 발생한다. NuGet을 이용하지 않은 project라면 당장 VS2012로 사용해도 무방하다. 

간만에 MS가 Tool을 잘만들어서 내보낸것 같다. 오늘 하루종일 VS2012와 Windows 8으로 삽질을 하고 있었는데... Windows 8에 대해서는 좀 더 사용해보고 글을 하나 적어볼만 한 내용들이 좀 있는것 같고. 

PS. MSSQL이 분리가 되었다. 이건 굉장히 바람직한것이 아닐까 싶다. 몇몇 개발자들은 자신의 컴에 MSSQL Express가 설치가 자동으로 되어있는지도 모르는 사람들이 꽤 있기도 했고. 

PS2. MSSQL2012도 매우 향상된 느낌이 든다. 속도 뿐 아니라, 시스템에서의 안정성 자체도 좀 나아진것 같아서 좀더 가지고 놀면서 테스트를 해봐야지 될 것 같다.

NoSQL Solution 검토중, Cassandra 설치 부분에 대해서 번역 및 참고 사항 추가

• 설정환경 : JAVA 1.6 이상

설치 Progress

• Download Cassandra application

• conf/cassandra.yaml 파일 수정

  항목	설명	Example
  data_file_directories	DB 파일이 저장될 위치 지정	C:\cassandra\data
  commitlog_directory	DB Commit이 발생될 때, 메세지가 저장되는 위치 지정	C:\cassandra\commitLogs
  saved_caches_directory	Cache의 저장위치	C:\cassandra\cache
  storage_port	Cluster 구성시에 저장 메체들간의 통신 Port	default:7000
  rpc_port	Remote Client Port. Client의 접속 정보를 저장하는 Port	default:9160
  initial_token	Cluster를 구성시, 첫번째노드로 사용되는 경우에만 0를 설정한다. 다른 경우에는 모두 빈값으로 표시	default:(공백)

• conf/log4j.properties 파일 수정

  항목	설명	Example
  log4j.appender.R.File	log4j의 파일 저장 위치	/var/log/cassandra/system.log

• cassandra-env.sh 수정

  항목	설명	Example
  MAX_HEAP_SIZE	cassandra에서 사용할 heap의 사이즈 설정	default : 4G, 절대로 작은 값으로 production에 보내지 말것!
  HEAP_NEWSIZE	cassandra에서 새로운 heap 요청이 발생하였을 때에, 생성될 size	default : 800M, 절대로 작은 값으로 production에 보내지 말것!

위 값들이 너무 작은 경우, OutOfMemory exception이 발생할 가능성이 매우 높음

시작 progress

bin/cassandra.bat -f -- foreground로 실행, CTRL+C로 중지 가능
bin/cassandra.bat    -- background로 실행, Process kill로만 중지 가능