jQueryRotate.2.2.js 

 jQueryRotateCompressed.2.2.js

 

http://code.google.com/p/jqueryrotate/wiki/Examples

-키 생성 

keytool -genkey -alias 키이름 -keyalg RSA -keystore

 

-키 삭제

keytool -delete -alias 키이름 -storetype JCEKS -keystore(또는 생성된 위치 .keystore파일삭제)

 

-키 리스트 확인

keytool -list -v -keystore -storepass 입력비밀번호 -storetype JCEKS

 

 

톰캣 설정 방법(6.0)

 

<Connector connectionTimeout="20000" port="80" protocol="HTTP/1.1" redirectPort="8443"/>

하단에

 

<Connector SSLEnabled="true" clientAuth="false"
   keystoreFile="키스토어생성위치(예:C:\Users\admin\.keystore)" keystorePass="비밀번호"
   maxThreads="200" port="8443" scheme="https"
   secure="true" sslProtocol="TLS"/>

추가

안드로이드, 또는 자바 프로그래밍을 할 때 아주 높은 빈도로 등장하는 키워드 중 하나가 'synchronized' 입니다.
쓰레드(Thread)를 이용해서 프로그래밍을 할 때 동기화를 맞추기 위해서 사용하는 명령어죠.


무작정 synchronized를 남발하거나 사용하다보면 프로그램 성능이 저하되거나 오동작, 또는 오히려 락(Lock)이
발생되는 경우가 있는데, 놓치기 쉬운 synchronized의 개념에 대해 확실히 알고 넘어가야 될 것 같습니다. 

public class SynchronizedTest

{

public synchronized void A()

{

System.out.println("Method A");

}

public synchronized void B()

{

System.out.println("Method B");

}

public void C()

{

System.out.println("Method C");

}

}

위와 같은 클래스가 있다고 가정할 때, 메소드 A와 메소드 B는 synchronized가 사용되어져 있습니다.
다수의 쓰레드를 사용하는 프로그램에서 class SynchronizedTest 의 인스턴스 내부의 메소드 A, B, C에 접근할 때,
메소드 A와 메소드 B는 동시에 진입이 불가능합니다.


쓰레드 1과 쓰레드 2가 있다고 가정하면 쓰레드 1이 메소드 A를 수행하는 동안, 쓰레드 2는 메소드 A와 메소드 B에 
접근이 제한
이 됩니다.
많이 착각하는 오류 중 하나가 쓰레드 1이 메소드 A를 수행할 때, 쓰레드 2는 메소드 A로의 접근만 제한이 되는 걸로 
생각하는 경우가 있는데 그게 아니라 메소드 A와 메소드 B 모두 접근이 제한됩니다. 


그 이유는 다음과 같습니다.

public synchronized void A()

{

System.out.println("Method A");

}

이렇게 메소드 전체에 synchronized가 걸린 경우는 


public void A()

{

synchronized (this)

{

System.out.println("Method A");

}

}

이것과 같습니다. this, 즉 현재 클래스의 인스턴스를 이용해서 락(Lock)을 걸기 때문입니다.
그렇게 때문에 한 인스턴스 내에서 synchronized된 메소드들은 여러 개의 쓰레드에서 동시에 진입이 불가능합니다.

즉, 함부로 synchronized를 남발하다가는 상당히 심각한 성능 저하가 발생할 수 있습니다.


그리고 여기서 알 수 있는 또 다른 점은 락은 인스턴스마다 존재한다는 점입니다. 
즉, class SynchronizedTest의 인스턴스를 여러 개 만들었다면, 각각의 인스턴스마다 락이 따로 존재하게 됩니다.


하지만, 만약 static을 이용해서

public static synchronized void A()

{

System.out.println("Method A");

}

가 된다면 이야기는 조금 달라집니다. 이 메소드는 각 인스턴스마다 생기는 고유의 메소드가 아니라 
static으로 설정되어진 메소드이기 때문에


public void A()

{

synchronized (SynchronizedTest.class)

{

System.out.println("Method A");

}

}

이것과 같은 코드가 됩니다.


synchronized는 쓰레드 기반의 프로그래밍을 할 때 상당히 중요한 키워드이기 때문에
그 개념은 확실히 알고 넘어가야 할 것 같습니다.

String path = DictionaryFactory.class.getResource("").getPath();

 스트럿츠와 스프링 프레임워크의 가장 큰 차이점은 스트럿츠는 웹에 특화된 프레임워크라는 것입니다.

스트럿츠 프레임워크의 전반적 흐름은  웹 브라우저 사용자가 요청을 하면 서블릿에서 해당 요청을 받으면  structs.xml 설정에 따라 알맞은 액션으로 연결시킵니다 이과정에서 인터셉터(보안, 파일업로드..., 등)  에서 요청을 처리한 후 액션에 넘겨지게 됩니다. 액션에서 비즈니스 로직을 수행한 후 수행한 결과를 request객체에 담고 리턴된 포워드로 jsp를 연결하게 됩니다.

이런 일련의 과정들은 HTTP 요청방식에 대한 전반적인 처리를 다룬 다는 것입니다. 즉 웹 환경에만 특화된 것입니다.

 

반면,  스프링 프레임워크는 웹어플리케이션 뿐만 아니라 자바 어플리케이션에도 특화된 프레임워크입니다. 기본적으로 컨테이너라는 것을 제공하는데 이 컨테이너는 빈의 생성과 소멸등 일련의 라이프 사이크을 관리하게 됩니다. 환경설정도 스트럿츠 방식처럼  xml로 설정하는 방식뿐만이 아닌 자바 기반의 어노테이션을 활용하여 자바 빈들을 등록하실 수 있습니다.

이렇게 등록된 자바 빈은 웹 시스템 뿐만 아닌 어플리케이션에서도 활용 할 수 있습니다.

 

스프링은 MVC환경에 특화된 서블릿이나 컨트롤러 , 뷰리졸버 등을 제공하는 데, 사실상 이러한 것은 웹 환경을 지원하기 위해 제공하는 것입니다. 실질적으로 비즈니스 로직을 실행하는 Service나 Repository같이 자바빈으로 등록된 것 들은 웹 환경이 아닌 어디에서도 사용 가능합니다. 즉, 외부인터페이스에 확장까지 고려한 프레임워크라고 보시면 될 것 같습니다.

$(#id).animate({top:20}, 1000, null, baloonDown);

 

 

$(엘리먼트).animate({property},duration,easing,callback);


property : 에니메이션의 마지막에 도달해야 하는 값을 명시
               css에서 지원하는 값을 허용한다.

duration: 1/1000초 단위로 기술 또는 slow,fast등으로 기술

easing : 선택사항을 미묘하게 바꾸는 함수이름
            플러그인 형태로 제공된다.
            기본으로는 linear / swing 두 함수를 제공

callback : 에니메이션이 완료된 뒤 호출되는 함수이름

[출처] jQuery 에니메이션|작성자 냥꼬


[spring-application.xml]

...
<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basenames" value="cms/messages" /> <!-- messages.properties source 경로 --> <!-- 여러개일경우 property태그 안에<list><value>cms/messages</value></list>로 변경 -->
</bean>
<bean id="messageSourceAccessor" class="org.springframework.context.support.MessageSourceAccessor">
<constructor-arg ref="messageSource"/>
</bean>
<bean id="message" class="cms.util.CmsMessage">
<property name="messageSourceAccessor" ref="messageSourceAccessor"/>
</bean>
...




[CmsMessage.java]


package cms.util;

import java.util.Locale;

import org.springframework.context.support.MessageSourceAccessor;

/**
* Message
* @author J.H.Kim
*/

public class CmsMessage {

/**
* MessageSourceAccessor
*/

private static MessageSourceAccessor msAcc = null;

public void setMessageSourceAccessor(MessageSourceAccessor msAcc) {
CmsMessage.msAcc = msAcc;
}

/**
* KEY에 해당하는 메세지 반환
* @param key
* @return
*/
public static String getMessage(String key) {
return msAcc.getMessage(key, Locale.getDefault());
}

/**
* KEY에 해당하는 메세지 반환
* @param key
* @param objs
* @return
*/
public static String getMessage(String key, Object[] objs) {
return msAcc.getMessage(key, objs, Locale.getDefault());
}
}



[message.properties]

test={0}입니다.
test1=테스트~



사용

CmsMessage.getMessage("test", new String[]{"메시지 테스트"});
CmsMessage.getMessage("test1");

결과
메시지 테스트입니다.
테스트~


TAG사용

<%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %>
...
<spring:message code='test' arguments='메시지테스트' var="testMessage"/>
<spring:message code='test1' var="testMessage1"/>
...
${testMessage}
${testMessage1}
...

결과
메시지 테스트입니다.
테스트~

 

 

[출처] Spring Properties Message 사용하기|작성자 듀스포에

INPUT[type=text]{
  font-size: 8pt;
  font-family:"돋움";
  border:0px; 
  text-align:center;

}  //ie

 

 

INPUT{
  border: expression( (this.type=='text')?'0px':'' );
  text-align:center;
  font-size: 8pt;
  font-family:"돋움";
}  //기타

select count(decode(to_char(hiredate,'mm'), '01', 1)) "1월",
       count(decode(to_char(hiredate,'mm'), '02', 1)) "2월",
       count(decode(to_char(hiredate,'mm'), '03', 1)) "3월",
       count(decode(to_char(hiredate,'mm'), '04', 1)) "4월",
       count(decode(to_char(hiredate,'mm'), '05', 1)) "5월",
       count(decode(to_char(hiredate,'mm'), '06', 1)) "6월",
       count(decode(to_char(hiredate,'mm'), '07', 1)) "7월",
       count(decode(to_char(hiredate,'mm'), '08', 1)) "8월",
       count(decode(to_char(hiredate,'mm'), '09', 1)) "9월",
       count(decode(to_char(hiredate,'mm'), '10', 1)) "10월",
       count(decode(to_char(hiredate,'mm'), '11', 1)) "11월",
       count(decode(to_char(hiredate,'mm'), '12', 1)) "12월",
       count(*) "전체"
from emp
where to_char(hiredate,'mm') >= '01' and
      to_char(hiredate,'mm') <= '12';


DECODE 함수 사용 방법

decode(검색컬럼, 조건1, 결과값1,..., 기본값)

[출처] 오라클 Decode 예제|작성자 흑향

HTML이란 용어를 많이 접해 보셨을 겁니다. HTML을 접하면서부터 같이 듣게 되는 용어에는 웹 표준이라고 있습니다.


1. 웹 표준이란 무엇일까요?

우선적으로 웹 표준의 웹은 월드와이드웹(World Wide Web)을 줄여서 웹이라고 부르는데, 이 웹에서 우리는 인터넷의 다양한 정보를 공유할 수 있습니다. 이 공간에서 서로 공통된 규칙으로 정보를 공유하기 위해서 통일화된 방식이 필요로 하게 됩니다.



2. 웹 표준을 지켜야 하는 이유는 무엇일까요?

최근에는 인터넷을 접하는 다양한 계층, OS, 브라우저, 휴대기기가 있습니다.

계층 : 노인, 장애인, 어린이 등
OS : 윈도우즈, 리눅스, 유닉스, 맥 등
브라우저 : 익스플로러, 크롬, 사파리, 오페라, 파이어폭스 등
휴대기기 : 스마트폰, TV 브라우저, PDA 등

이렇게 다양한 방법으로 웹을 사용하게 되는데, 여기서 특정 플랫폼의 사용자를 타겟으로 웹을 만든다면 어떻게 될까요?
특정 플랫폼의 계층이 아닌경우 장애인, 노인, 외국인, 리눅스 사용자, 맥 사용자 등은 정보를 접할 기회가 줄어들어 정보화의 폐해가 드러나게 됩니다.



3. 웹 표준을 지키는 방법.

첫째, 호환성을 유지하라.
일반적으로 프로그램을 개발할 때, 버전이 올라가면 갈수록 새로운 기능을 추가하고 이전 기능은 폐기하게 됩니다. 그러나 사용자의 측면에서는 예전 기능을 계속 유지해 주어 개발 호환성을 유지해 줄 필요성이 생기게 되는데, 버전 호환성 유지는 예전에 사용된 비표준 문법들이 계속 확대 재생산되어 결국 접근성에 심각한 위해를 주게 된다.

주로 나모 웹 에디터, 드림 위버와 같은 저작 도구에 의존하여 표준을 무시하고, 그냥 남의 코드를 딷가 적당히 익스플로러에서만 돌려보고 개발을 끝내는 풍토와 그런 정보 가공자들을 계속 양산하는 교육 시스템에도 문제가 있다.

이와 반대로, XHTML 1.x 이나 HTML 4.x 표준에 맞추어진 문서는 99% 접근성이 높은 사이트들이다. 기존에 흔이 사용되는 table 구조를 div로 바꾸고 font, b 같은 태그들을 스타일시트(CSS)로 사용하게 되면, HTML 코드 양은 반 이하로 줄어들게 된다.

구조와 표현이 엄격히 분리되면, 사이트의 로딩 속도도 빨라지며, 코딩과 유지보수의 효율성은 두 배로 늘어난다.


둘째, 구조와 표현, 동작을 분리하라.

구조(Structure) : HTML, XHTML
표현(Presentation) : CSS
양식(Behavior) : DOM, ECMAScript(공용 javascript)

스타일시트(CSS)는 단순히 링크의 색상, 글자 모양을 바꾸는 정도가 아니고, 문서의 배치, 여백 조정, 색깔, 요소 자체의 성격 변화, 클래스를 통한 디자인의 일관성 확보, 서로 다른 미디어에 따른 최적화된 디자인 템플릿 적용 등 많은 역활을 할 수 있다.

HTML 에서는 철저하게 구조화된 마크업만을 사용하고, 모양이나 디자인에 관한 것은 CSS로 완전히 분리함으로써, 구조는 변하지 않은 채 여러 가지 디자인을 적용한다거나, 상황에 따라 쉽게 디자인을 변경하는 것이 가능해진다.
또한, 똑 같은 디자인 템플릿에 따른 내용을 담는 여러 가지 문서를 만드는 것도 가능해진다.
디자인에 전혀 영향을 주지 않고 문서의 내용을 바꾸는 것도 쉬워지기 때문에 장애인의 접근성에 엄청난 도움을 준다.
(한 개의 HTML 문서에 시각 디자인용 CSS와 텍스트용 CSS와 기존 CSS를 만들어 변경해 줌에 따라 문서의 구조가 내용에 섞이지 않고 제공될 수 있다.)


셋째, 최소한의 디버깅을 거쳐라.

HTML과 XHTML, CSS, DOM, JAVASCRIPT가 표준 문법을 사용 했는지 확인을 할 수 있다.

- http://validator.w3.org – 브라우저 유효성 검사
- http://jigsaw.w3.org/css-validator – CSS 유효성 확인
- http://www.stg.brown.edu/service/xmlvalid – XML 유효성 확인

 

 

출처 : http://cafe.naver.com/htmlkor/621   작성자 : 봄(semidex37) 


+ Recent posts