• 0.1 초 : 사용자 자신이 UI에서 보여주는 개체들을 직접 조작한다고 느낄 수 있는 최대 시간. 예를 ㄷ르면 사용자가 한 테이블에서 한 열(column)을 선택한 그 순간 부터 해당 열이 선택되ㅣ었다는 반응이 화면에 보여질 때까지 시간을 들 수 있다. 한 열을 기준으로 정렬을 한 경우에도 이 정도의 시간만 걸리면 이상적이라고 할 수 있을 것 같다. 이때 사용자는 자신이 직접 테이블의 내용을 정렬하고 있다는 느낌을 갖는다.
  • 1초 : 사용자가 컴퓨터가 작업을 끝낼 때까지 과도하게 기다릴 필요 없이 자연스럽게 명령을 내린다는 느낌을 가질 수 있는 최대 시간. 0.2에서 1.0초 정도 지연되는 경우 사용자는 무언가 오래 걸린다는 것을 인지하게 되며 명령에 대한 결과가 사용자의 동작에 대한 직접적인 결과라기 보다는 컴퓨터가 현재 명령을 처리하기위해 '일'을 하고 있다고 느낀다. 예를 들어 보자. 테이블의 내용을 선택한 열을 기준으로 정렬하는 작업이 0.1초 이내에 완료되지 않는 경우에도 왠만하면 1초 이내에는 완료가 되어야 한다. 그렇지 않으면 사용자는 UI가 굼뜨게 반응을 한다고 느끼게 되고 현재 하고자 하는 작업의 '흐름'이 깨지게 된다. 1초 이상 지연되는 경우에는 현재 작업을 수행하기 위해 컴퓨터가 작업을 하고 있다는 것을 커서의 모양을 바꾸는 등의 방법을 통해 사용자에게 알려주는 것이 좋다.
  • 10초 : 사용자가 현재의 작업에 열중할 수 있는 최대 시간. 10초 이상 소요되는 작업의 경우에는 현재까지 완료된 작업의 비율을 퍼센트로 표시를 해주어야 하며 눈에 잘 띄는 곳에 진행 중인 작업을 중지시킬 수 있는 방법 또한 제공해야 한다. 10초 이상 걸리는 작업이 완료된 후에는 작업하던 UI로 돌아왔을 때 어디에 무엇이 있었는지 다시 훑어봐야 할 것이라는 가정을 하는 것이 좋다. 10초 이상의 지연 시간은 사람이 일하는 도중에 현재 작업하던 일을 잠시 그만 두고 다른 일을 하는 등의 자연스럽게 쉬게 되는 경우에나 인정할 수 있다.

참조 : 초고속 웹사이트 구축(위키북스) 에서
영문 URL : http://www.useit.com/papers/responsetime.html
저작자 표시 비영리 변경 금지
  1. HTTP 요청을 줄여라
  2. 콘텐츠 전송 네트워크를 이용하라
  3. 헤더에 만료 기간을 추가하라
  4. Gzip 컴포넌트
  5. 스타일시트는 위에 넣어라
  6. 스크립트는 아래에 넣어라
  7. CSS Expression을 피하라
  8. 자바스크립트와 CSS를 외부 파일에 넣어라
  9. DNS 조회를 줄여라
  10. 자바스크립트를 최소화하라
  11. 리다이렉트를 피하라
  12. 중복되는 스크립트를 제거하라
  13. ETag를 설정하라
  14. 캐시를 지원하는 Ajax 만들기
저작자 표시 비영리 변경 금지
1. 초고속 웹 사이트 구축
초고속 웹사이트 구축
카테고리 컴퓨터/IT
지은이 스티브 사우더스 (위키북스, 2010년)
상세보기
이번엔 HOONS(http://www.hoons.kr) 에 들어갔다가... HOONS 님이 번역한 도서입니다.

웹사이트 제작을 매번 하는데 FireFox의 YSlow라는 추가기능으로 등급을 찍어보면 평균 E 등급(최하 F등급)이 나와버려서 대략 놀라기도 하고..

급 우울해져서... C등급 이상으로는 올려보고 싶은 욕심에 사서 읽어 보려고 샀다.

한순간에 능력이 상승되기를 바라지는 않지만, 읽어보면은 분명히 도움이 될거 같아서 샀다.


SQL SERVER 2008
카테고리 컴퓨터/IT
지은이 마이크 호텍 (정보문화사, 2010년)
상세보기

이번에 SQL Server 2005를 위한 데이터베이스 모델링이라는 책을 사고, SQL 2008을 공부할 필요성이 있어서 처음으로 구입한 SQL 2008책

Step By Step 시리즈는 이번이 처음이다. 뇌를 자극하는 시리즈는 2권이 있는데, 생각보다는 별로이고 내 스타일에 맞지 않은 책이어서..

처음으로 이 시리즈 책을 샀다

저작자 표시 비영리 변경 금지
C#에서 간단히 랜덤값을 얻는 함수는 System.Random 클래스 이다.

이 클래스를 이용해서, Random한 값을 출력하는 문자열을 리턴하는 함수를 만들때 유의 할 점이 있다.

해당 함수에서 매번 Random 클래스를 인스턴스화 시켜서 사용하면, 같은 값을 리턴하게 된다.

// 랜덤 문자열 만드는 함수
public static string GetRandomCharacter(int length)
{
    Random random = new Random();
    
    StringBuilder sb = new StringBuilder();
    int value = 0;
    for (int i = 0; i < length; i++)
    {
do 
{
   value = random.Next(48, 90);
} while(value > 57 && value < 65);

sb.Append(Convert.ToChar(value));
    }

    return sb.ToString();
}
// 함수 호출
for (int i = 0; i < 20; i++)
{
    Response.Write(GetRandomCharacter(32)+"<br/>");
}

이러한 결과가 나온다.

// 랜덤 문자열 만드는 함수
public static string GetRandomCharacter(Random random, int length)
{          
    StringBuilder sb = new StringBuilder();
    int value = 0;
    for (int i = 0; i < length; i++)
    {
do 
{
    value = random.Next(48, 90);
} while(value > 57 && value < 65);

sb.Append(Convert.ToChar(value));
    }

    return sb.ToString();
}
// 함수 호출
Random random = new Random();
for (int i = 0; i < 20; i++)
{
    Response.Write(GetRandomCharacter(random, 32)+"<br/>");
}
이전의 코드와 달리 함수를 호출 하는 부분에서 Random 함수를 인스턴스화 시켜서 랜덤한 문자열을 출력하는 함수(GetRandomCharacter)함수를 호출한다.
이런식으로 어느정도는 랜덤한 값이 나온다.
저작자 표시 비영리 변경 금지
웹 페이지가 UTF-8로 셋팅이 되어 있으면 한글을 Ajax로 전송해도 깨지지 않지만,

웹 페이지가 EUC-KR 과 같은 형식으로 셋팅이 되어 있으면,

한글을 Ajax로 값을 넘길때, 한글이 깨져서 전송이 된다.

그럴 경우 간단히 해결하는 방법은

한글 데이터를 escape 함수로 인코딩하여 값을 넘긴다음

받은 곳에서.

인코딩 된 값을 디코딩 하여 저장하면 간단히 해결이 된다.
저작자 표시 비영리 변경 금지
1. 부모 페이지에서 iframe 내부 DOM 셀렉터를 이용하여 엑세스 하기
- 부모페이지(parent.html)
<html>
 <head>
<script type="text/javascript" src="jquery-1.4.2.min.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#btn_ChangeBackground").bind("click", function () {
$("#iframe").contents().find("#div_child").css("background-color","#ffff00");
});
});
</script>
 </head>
 <body>
<input id="btn_ChangeBackground" type="button" value="  Iframe 내부  배경 색상 변경" />
<iframe id="iframe" src="child.html" width="500" height="500"></iframe>
 </body>
</html>
- 자식 페이지(child.html)
<html>
 <head>
 </head>
 <body>
<div id="div_child" style="width:50px; height:30px">
iframe 내부 
</div>
 </body>
</html>

2. 자식 페이지에서 부포 페이지에 엑세스 하기
- 부모페이지(parent.html)
<html>
 <head>
<script type="text/javascript" src="jquery-1.4.2.min.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#btn_ChangeBackground").bind("click", function () {
$("#iframe").contents().find("#div_child").css("background-color","#ffff00");
});
});
</script>
 </head>
 <body>
<input id="btn_ChangeBackground" type="button" value="  Iframe 내부  배경 색상 변경" />
<iframe id="iframe" src="child.html" width="500" height="500"></iframe>
 </body>
</html>
- 자식 페이지(child.html)
<html>
 <head>
  <script type="text/javascript" src="jquery-1.4.2.min.js"></script>
  <script type="text/javascript">
$(document).ready( function() {
$("#btn_ParentAccess").bind("click", function() { 
$(top.document).find("body").append("<div id=\"div_unable\" style=\"position:absolute;display:block;top:0px;left:0px;background-color:#ffffff;opacity:0.4;filter:alpha(opacity=40);width:100%;height:100%\"></div>");
});
});
  </script>
 </head>
 <body>
<input id="btn_ParentAccess" type="button" value="  부모 페이지  " />
 </body>
</html>


저작자 표시 비영리 변경 금지
JQuery 에서 Ajax로 페이지를 요청하고 그 페이지를 받아서 보여주는 경우에

가끔씩 캐싱처리가 되어, 새로 업데이트 된 내용이 나오지 않는 경우가 생긴다.

이럴 경우, Ajax를 호출 하기 전에 

$.ajaxSetup({cache:false});

이 코드를 삽입하여 Ajax 호출 시 cache 처리를 하는 것을 막아야 한다.

이것을 이용하게 되면 Ajax 로 요청 하는 페이지 URL 뒷 부분에 랜덤으로 값이 붙여

Cache 처리를 막는다.

가령

CommentArea.aspx 페이지를 Ajax로 요청을 하게 되면

실제적으로는

CommentArea.aspx?_=1270616257167   - 1번째
CommentArea.aspx?_=1270616273776   - 2번째

이렇게 호출을 한다.

저작자 표시 비영리 변경 금지
  1. ViewState
    - 요청 전반에 걸쳐 상태가 유지되는 이 기능의 매커니즘은 사실 클라이언트와 서버 사이를 빈번하게 오고가는 거대한 데이터들로 인해서 얻어지는 결과다. 많은 실무 응용 프로그램에서 이 데이터들은 수백 킬로바이트에 이르는 경우도 빈번하며, 모든 요청 시마다 매번 수신되고 다시 전송되므로, 사이트 방문자가 버튼을 클릭하거나 그리드에서 다음 페이지로 이동하려고 할 때 응답 지연의 원인을 제공하여 방문자를 지치게 만든다. 큰 대역폭을 차지하는 페이지의 개인 문제야 말로 Ajax가 해결책을 제시해 줄 수 있는 대표적인  문제들 중 하나임에도 불구하고 ASP.NET Ajax 역시 이 문제가 존재한다.
    - ASP.NET Ajax도 매번 비동기 요청을 수행할 때마다 페이지의 모든 ViewState를 수신하고 전송한다.
  2. 페이지 생명 주기
    - 클라이언트 측 이벤트와 서버 측 이벤트 처리기 코드를 연결해 주는 매커니즘은 페이지 수명 주기의 한 부분이며, 경우에 따라서 상당히 복잡 미묘해질 수도 있다. 단지 소수의 개발자들만이 이벤트 처리기의 실행이 모호하게 실패하는 일이나 ViewState 오류 없지 런타임 시에 컨트롤 계층 구조를 조작할 수 있다.
  3. 제약이 많은 HTML 기반의 컨트롤
    - 서버 컨트롤은 자신을 HTML로 렌더링하기는 하지만, 그 결과가 내가 생각한 결과와 같다고 장담 할 수는 없다. 서버 컨트롤의 HTML은 대체로 웹 표준을 만족하지 못하거나 CSS를 적용하기 어려운 구조일 뿐만 아니라 서버 컨트롤 시스템이 생성한 ID값은 예츠갛기 어렵고 복잡하여 자바스크립트로 접근하기 힘들다. 
    - 서버 컨트롤에서 GridView나 기타의 데이터를 자동으로 Bind해 주는 서버 컨트롤의 경우, 컨트롤 자체적으로 렌더링 시에 Table 코드르 만든다. 이렇게 만들어진 Table 코드는 웹표준 방식에 맞지가 않는다. 그리고 각 렌더링된 컨트롤의 ID값은 각 컨트롤의 ClientID값으로 확인이 가능하나, 자신의 페이지가 아닌 다른 페이지에서는 접근이 제한이 된다.
  4. 취약한 관계의 분리
    - ASP.NET의 코드-ㅣ하인드 모델은응용 프로그램 코드를 HTML 마크업과 분리하여 별도의 코드-비하인드 클래스에 작성할 수 있는 방법을 제공한다. 이 모델은 로직과 프리젠테이션을 분리하는 방법으로 널리 박수를 받았으나, 실제로 개발자들은 프리젠테이션 코드와 응용프로그램 로직을 하나의 거대한 코드-비하인드 클래스에 뒤 섞어 구현할 수밖에 없었다. 그래서 뛰어난 관계의 분리를 도입하지 않고 얻어진 결과물들은 대체로 취약하고 난해했다.
  5. 테스트의 어려움
    - ASP.NET의 설계잘들은 그 첫 번재 플랫폼을 설계하면서 오늘날과 같이 자동화된 테스트가 소프트웨어 개발의 주류로 성장할 것이라는 예견을 하지 못했다. 따라서 그들이 설계한 아키텍처가 자동화돈 테스트에 적합하지 않은 것은 당연한 일이다.
저작자 표시 비영리 변경 금지