2012. 4. 12. 14:07 카테고리 없음

json 파일을 추가할 경우가 생겨서..


1. http.m 파일 수정

$webtob/config/http.m


json            MimeType = "application/octet-stream", SvrType=HTML


2. compile
wscfl -i http.m

3. webtob 재기동
wsdown
wsboot

posted by smplnote
2012. 4. 12. 09:14 IT

[WHY] 

eclipse에서 grails plugin을 설치하지 않고도  ant  view에서 편리하게 각각의 gradle 명령을 사용하고 싶었음.


참고한 reference를 보면 gradle이 설치되어 있고 GRADLE_HOME 환경변수가 설정된 상태를 전제로 한다.


앞글에서 설명했던 gradlew 를 이용하면 미리 gradle binary들 설치하고 환경변수를 설정하지 않고도 빌드실행이 가능해진다. 




[Prerequisite]

== gradle wrapper생성을 통해 만들어진 파일들 (3)

gradlew.bat or gradlew

gradle/wrapper/gradle-wrapper.jar

gradle/wrapper/gradle-wrapper.properties


== 실제 build를 수행할 build 파일

build.gradle

// this is sample...

apply plugin: 'java'

repositories {

mavenCentral()

}

[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'

jar {

destinationDir = file("dist")

}


== gradle을 수행할 ant build wrapper 

build.xml

<project name="build-gradle"  default="help"  basedir=".">

<property environment="env" />

<property name="gradle.executable" location="./gradlew.bat" /><!-- for window -->

<target name="help">

<exec executable="${gradle.executable}" dir=".">

<arg value="tasks" />

</exec>

</target>

<target name="build"> <!-- 모든 포함된 project의 build task를 실행 -->

<exec executable="${gradle.executable}" dir=".">

<arg value="build" />

</exec>

</target>

<!--

<target name="subproject-build" description=" 특정 subproject의 build task만 실행시키고 싶을때 사용">

<exec executable="${gradle.executable}" dir=".">

<arg value=":common:build" />

</exec>

</target>

-->

</project>

이제, 필요할 때마다 ant target을 추가하면된다. 



reference : https://gist.github.com/735788 

posted by smplnote
2012. 4. 12. 08:47 IT

maven이든 ant든 다른 어떤 툴이든, 우선 많은 용량의 binary를 다운 받아서 작업을 해야한다.

plugin으로 제공되는 경우도 용량 자체는 크게 다르지 않거니와 행여나 버전이 낮아 쓰기 불편한 경우도 있어

새로 시작할 때마다 부담이 되는 경우가 있다. 

gradle은 eclipse 지원을 일찍 포기한 것으로 보이는데, 상위버전에서 제공되는 명령이 제대로 먹히지 않는다.

(물론 별도의 GRADLE_HOME 을 설정할 수 있도록 preference 에서 설정화면을 제공하고 있다.)


gradle wrapper의 핵심 idea는  gradle을 설치하지 않은 상태에서도 gradle을 사용할 수 있도록 제공하는 기능이다.


물론 아무것도 없이 실행되는 것은 아니다. 

단지 최소한의 쉘스크립트와 바이너리를 통해 이 작업을 수행할 수 있다. 



먼저, gradle wrapper 스크립트를 만들기 위해서는 당연하게도 gradle이 설치되어 있는 곳에서 시작하여야 한다.

build.gradle을 다음과 같이 작성한다.

// 현재 gradle 버전은'1.0-milestone-9' 이다. 

task wrapper(type: Wrapper) {

gradleVersion = '1.0-milestone-9'

}

defaultTasks 'wrapper'


실행이 되면

쉘파일과 (윈도우용인 gradlew.bat , *nix용인  gradlew)

실행을 위한 jar (gradle/wrapper/gradle-wrapper.jar )

설정정보를 포함한 property ((gradle/wrapper/gradle-wrapper.properties)

가 만들어진다. 

(cf. 새 버전이 나올 경우 wrapper task를 실행하여 새로 생성하거나 단순히 gradle-wrapper.properties 에서 binary를 다운 받을 경로를 변경해주면 된다.)


이제 준비완료.


gradlew가 해주는 역할은 단순하다.

gradle 배포본이 있는지 체크해서 없으면 gradle-wrapper.properties에 정의되어 있는 경로에서 다운로드를 받고,

있을 경우에는 모든 argument를 gradle 에게 전달한다. 


현재 gradle-1.0-milestone-9-bin.zip의 크기는 29M다. ( gradle-wrapper.jar 는 39K )


기본으로 설치되는 위치는 

$USER_HOME/.gradle/wrapper/dists


이제 신규 프로젝트에

저 파일을 같이 포함하면 준비완료.

gradlew 를 실행하면 된다. 



reference : http://www.gradle.org/docs/current/userguide/gradle_wrapper.html


posted by smplnote
2012. 4. 5. 07:48 IT

jqgrid의 이렇게 다양한 기능이 있다는걸 새롭게 알게됨.


formatter:'date',formatoptions: {newformat:'Y-m-d'} 을 추가


{name:'started',   index:'started',   sortable:false, align:'left', width:90, formatter:'date',formatoptions: {newformat:'Y-m-d'}},


referece) http://www.trirand.com/jqgridwiki/doku.php?id=wiki:colmodel_options

posted by smplnote
2012. 4. 5. 07:40 IT

Rest Client example

- reference

http://blog.springsource.org/2009/03/27/rest-in-spring-3-resttemplate/
http://dlinsin.blogspot.com/2009/11/playing-with-spring-resttemplate.html http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/client/RestTemplate.html


import org.springframework.web.client.*;

...

@RequestMapping(value="/rest", method=RequestMethod.GET)

public String rest( Model model) throws Exception{

String url = "http://localhost/sample?email={mail}"; 

RestOperations restTemplate = new RestTemplate();

String result = restTemplate.getForObject(url, String.class, "tistory@tistory.com"); // url, responseType, urlVariable

//DELETE delete(String, String...)

//GET getForObject(String, Class, String...)

//POST postForLocation(String, Object, String...)

//PUT put(String, Object, String...)  

model.addAttribute("result",result);

// json방식으로 처리할 경우 바로 result를 return 하면 될듯..  

return "sample/RestResult";

}


posted by smplnote
2012. 3. 22. 10:27 IT
가상머신에 대한 명명규칙을 지정하기위한 규칙.

추천글에서 제시하는 기본 가이드라인은 다음과 같다. (관심있는 부분만 거론함)
1. device의 위치, 목적, 기능, 서비스를 식별할수 있도록 해라.
2. 단순해야하지만, 시스템관리자,지원,운영자들에게는 의미가 있도록 해라.
3. 특정 벤더,제품명을 쓰는 것은 피해라. (물론 예외는 있다...)

개인적인 생각으로는 

(물리위치)-{데이터센터명} - 일련번호 - {관리유형} 

* 지리적 위치 : 미국? 한국? 

* 용도 : 관리용,  일반사용자용 ,  백업용 ,  테스트용 등등..
 

한가지 첨언할 것은 사용자가 원하는 hostname과 관리용 hostname을 두는것도 추천... 


추천글
http://virtualizationreview.com/blogs/virtual-insider/2011/10/how-to-design-an-effective-naming-convention.aspx  

 
posted by smplnote
2012. 2. 21. 18:12 IT

"Apache Deltacloud is a REST-based (HATEOAS) cloud abstraction API, that enables management of resources in different IaaS clouds using a single API. "

즉 여러 IaaS 클라우드 벤더가 제공하는 resource에 대한 추상화된 REST기반 API를 제공합니다. 
슬로건이  “Many clouds. One API. No problem.” 이군요. 


SD Times에 "Apache adopts new top-level cloud project" 라는 관련기사가 있는데요..
http://www.sdtimes.com/content/article.aspx?ArticleID=36373&page=1

요약하면

Amazon, Eucalyptus, GoGrid, IBM, Microsoft, OpenStack , Rackspace 등
다양한 클라우드 구현체들 간에 불일치를 API 레벨에서 해결하고자 하는 목적이 있으며,
Deltacloud의 장점은 특정 벤더에 통제되지 않는점. 
(또한 DMTF에서 표준화 작업을 진행하고 있는데, 최초 구현체가 될 것으로 생각됨)

현재 버전은 0.5.0
 
 


Resource Type : Compute, Storage
top level entity : Realms, Images, Instance States, Instances, Keys, Storage Volume, Storage Snapshots, Blob Storage. 
인증 :  HTTP basic authentication.

API 문서 :   http://deltacloud.apache.org/api.html 

site : http://deltacloud.apache.org

posted by smplnote
2012. 2. 14. 13:38 IT

IBM의 가상화 관리/자동화 솔루션 V7.1.1

용도 : 가상화 데이터 센터의 프로비저닝

http://www-01.ibm.com/software/tivoli/products/prov-mgr/

provisioning workflow 개발시에는 APDE (Automation Package Developer Environment)라는 Eclipse plugin을 이용한다.

* 개발절차
APDE 설치 -> automation package project 생성 -> workflow 작성 -> compile -> run (test)
-> manifest 파일작성(tcdriver.xml) -> 패키지 문서 생성(옵션) -> 패키징 (ant build.xml 사용)
*  배포
tcdriver를 대상위치에 복사 ( xxx.tcdriver 를  TIO_HOME\drivers 에 copy )
-> install ( TIO_HOME\tools 에서 install 실행 )
ex) tc-driver-manager.[cmd|sh] installDriver MyFirstPackage

provisioning workflow 기본 가이드라인은 다음과 같다.

1. automation package naming : 대문자로 시작하는 CamelCase. _로 연결 [세부규칙 정의가 필요]

2. workflow naming : 동사+행위, 대문자로 시작하는 CamelCase. 설명을 위한 부가정보의 구분자로 _ 사용 [세부규칙 정의가 필요]

3. parameter naming : 대문자로 시작하는 CamelCase.
ex) workflow WorkflowName (in CamelParam, out CamelParam )

4. variable, array naming : 소문자로 시작하는 CamelCase

5. constant naming : 대문자, _ 로 연결 ex) MY_CONSTANTS

6. comment , annotation
- comment :  # 으로 시작
- 문서 생성을 위한 정보는 annotation을 사용하여 작성 : @doc, @param, @requirepermission

7. Locale & encoding : 파일은 ISO-8859-1 , UTF-8 등 가능하나 호환성을 위해 ISO-8859-1 권장.
로케일에 영향받지 않도록 선언하기  -> LocaleInsensitive

8. security : 암호와 같이 보안이 필요한 정보는 로그등에서 보이지 않도록 암호화 처리해야한다.
ex) Java[SensitiveData#mark(UserPassword)]

9. 동시작업 최대값 설정 : 기본값은 5
spawn command를 사용하여 동시작업 실행

10. exception handling
try / catch, catchall / finally / endtry
throw / rethrow

11. logging
log msg_type message [debug|info|warning|error]
cf) parameter를 로깅할 필요는 없음(run history에 남음)
cf) 에러의 경우에는 처리할 수 있도록 logging후 throw 할것

기타. 메세지 ID 정보
Table 1. Subsystem codes
Code Subsystem
APM Activity plan applet
COM Common
DEX Deployment engine
DSE Discovery
GRP Group management
INF Infrastructure
JDS Job distribution service
JEE J2EE. TheTivoli Provisioning Manager code that runs on the WebSphere® Application Server.
NET Network management
PCH Patch management
QLX Data model query language exception
SRV Server management
SWD Software deployment
TCA Tivoli Common Agent
TDM Automation package manager
TSK Provisioning task management
UTL Utilities
message ID 포맷정보
http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/topic/com.ibm.support.tpm.doc/messages/rtrbmsg_messageidformat.html

메시지 : http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/topic/com.ibm.support.tpm.doc/messages/rtrbmsg_tpm.html


URL : http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/topic/com.ibm.tivoli.tpm.wkf.doc/workflows/cwkf_intro.html
pdf 버전 : http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/topic/com.ibm.tivoli.tpm.wkf.doc/tpm_workflow_guide.pdf

posted by smplnote
2012. 2. 7. 13:59 1300K
부제 Bring Behavior-Driven Development to Infrastructure As Code

O'Reilly , Stephen Nelson-Smith, 2011

Chef 와 Cucumber를 조합하여 Infrastructure를 행위기반으로 테스트 해보기.

Chef 설치절차, Cucumber- Chef 설치절차 소개,  예제.

cf) 시스템,네트웍,어플리케이션 모니터링 용으로 개발된 Cucumber-Nagios 가 있음..
Infrastructure Development Life Cycle http://www.slideshare.net/botchagalupe/infrastrucutre-as-sdlc 

고려사항.
1. ruby와 Chef 를 배워야 한다. 
2. unix 계열에서 작업 (윈도우에서 연습은 할 수 없을까?)
3. Amazon EC2 를 써야한다. 
 
인프라 자동화에 대한 고민중.. 
 
posted by smplnote
2012. 1. 28. 16:56 IT
Cédric Champeau 가 만든 groovy 2.0에서 선보일 static type checking 에 대한 슬라이드 bit.ly/Ays6Dl 를 요약
 
아직 2.0은 진행중이지만 슬라이드를 통해 현재상태를 보여준다

STC의 목적은 빠른 오류 검출이다. : 동적 언어의 약점으로 지적되는  실행시점 오류를 컴파일 시점에 미리 체크하여 오류를 최소화하고자함. 그외 타이핑 오류, 할당오류등을 사전 검출

현재 제안중인 방식은
Class나 method에 TypeChecked annotation으로 지정하고 하는 것이다
(사실 완전히 정적타입체킹을 기본으로 정한다면 동적언어의 장점 전부를 포기하게 된다.)

물론 TypeChecking은 정적 컴파일을 의미하진 않는다. 또한 모든 groovy언어의 기능에 대해 검사해주지는 않는다
Metaclass변경이나 use, binding 사용성의 검사는 지원하지 못한다. 

Static compile의 목적은 성능, 타입안전성이다 
STC의 장점에 byte code size를 줄일수 있고 성능도 개선할수 있다 또한 메타클래스 변경으로 인한 사이드이펙트도 없다. 대신 groovy가 지닌  dynamic한 장점을 잃게된다 (dynamic method dispatch,meta class etc)

그래서 여전히 선택사항으로 남을것으로 보인다
CompileStatic annotation을 사용할 예정이다

앞으로 좀더 효과적으로 처리하기 위한 방법이나 개발중인 코드의 버그수정,개선이 진행되겠지만 groovy라는 매력적인 도구를 좀더 선택적으로 사용할수 있도록 하는 노력이 활발히 진행되고 있어 내심 반갑다.

이왕이면 어노테이션 수준외에도 보다 상위의 컴파일 옵션 상에서 정적타입체킹이나 정적컴파일을 선택할 수 있도록 해주는건 어떨까 싶다.










 
posted by smplnote