쁘도리의 블로그

<div style="margin-top:10px;">\r\n.*\r\n.*\r\n.*\r\n.*</div>$

상세페이지의 닫기 function을 일괄 주석처리 

$('#btnClose').on('click', function() {
	$("#tblList tbody tr").removeClass("selected");
	$("#divInfo").hide();
});

파일검색시 Regular expression 체크박스 선택후 

\$\(\'\#btnClose\'\)\.on\(\'click\'\, function\(\) \{ \r\n.*\r\n.*\r\n\}\)\;$

> 특수문자기호 앞에는 \(역슬러리) 처리 

/* $0 */ 

> $0 검색 결과의 검출된 대상을 지칭 

일괄 주석처리 

모듈(Module)이란?

분리된 하나의 파일을 모듈(module)이라고 부르는데, 모듈은 대게 클래스 하나 혹은 특정한 목적을 가진 여러개의 함수를 포함하는 라이브러리로 구성되어 있음.

장점

• 유지보수 용이 : 기능들이 모듈화가 잘 되어 있는 경우, 의존성을 줄일 수 있기 때문에 기능개선이나 수정에 용이
• 네임스페이스화 :  코드양이 많을수로 전역스코프에 중복되는 변수병이 존재할수 있음, 이때 모듈로 분리하면 네임스페이스를 갖기 때문에 문제를 해결할수 있음
• 재사용성 : 같은 코드를 반복하지않고 중복되는 코드를 모듈로 분리시켜 필요할때 마다 재사용할 수 있다.

모듈 시스템 종류 

• AMD - 가장 오래된 모듈 시스템중 하나로 require.js라는 라이브러리를 통해 개발됨.
• CommonJS -  NodeJS 환경을 위해 만들어진 모듈 시스템
• UMD -  AMD와 CommonJS와 같은 다양한 모듈 시스템을 함께 사용하기 위해 만들어짐
• ES Module - ES6(ES2015)에 도입된 자바스크립트 모듈 시스템

ES Module방식

> ES6에 도입된 자바스크립트 모듈로 <script> 태그에 type="module" 속성을 추가해주면, 해당 파일은 모듈로서 동작.

모듈을 외부에서 사용할수 있도록 내보낼때는 export, export default 와 같은 키워드를 사용하며, 외부에서 모듈을 불러 올때는 import 를 사용하여 모듈을 불러온다.

• named export 를 사용하여 함수 또는 변수를 내보낼수 있음.
• export default 를 사용하여 하나 기본함수를 내볼수 있음. (단, 모듈 당 하나만 내보낼수있음)

CommonJS방식

> NodeJS 환경에서 자바스크립트 모듈을 사용하기 위해 만들어진 모듈 시스템.  모듈을 외부에서 사용할 수 있도록 내볼때는 export, module.export 와 같은 키워드를 사용하며, 외부에서 불러올때는 require 를 사용하여 모듈을 불러옴,

• module.export 를 사용하여 하나의 객체로 묶어서 외부로 내보낼 수 있음.
•  

ES Module for NodeJS

CommonJs 모듈 시스템을 채택했던 NodeJS환경에서 ES Module을 사용하려면 babel과 같은 트랜스파일러(transpiler)를 사용했어야 하는데, NodeJS 13.2 버전부터 ES모듈 시스템에 대한 정식 지원이 시작됨으로서 별다른 도구 필요 없이 NodeJS에서 ES Module을 사용할수 있게 되었다고 함.

출처 : https://www.youtube.com/watch?v=5NXEXkIrkAk 

CI/CD

application 개발부터 배포 때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적이고 사용자에게 빈번이 배포할 수 있도록 만드는 것을 의미.

CI(Continuous Integration) 지속적인 통합의 약자

CD(Continuous Delivery) 지속적인 제공의 약자 또는 (Continuous Deployment) 지속적인 배포로 사용하는 경우도 존재

CI - 버그수정 또는 새로만드는 기능들이 메인 레파지토리에 주기적으로 빌드되고 테스트되어 merge 되는것을 의미.

• 코드 변경사항을 주기적으로 빈번하게 머지해야한다. (최대한 작은단위로 나뉘어 개발하고 통합해 나가는것을 권고)
• 통합을 위한 단계(source build, test, merge)의 자동화

CD - 마지막 배포단계에서 어떻게하면 자동화로 배포될지를 고민하는 단계이며 최종단계가 자동화가 되어있는지 아닌지에 따라서 Delivery(일부 수동적) 일지 Deployment(자동화)일지 나뉜다.

Spring 개발을 하다보면 mapper.xml 에 간혹 ' WHERE 1=1 ' 을 보게 된다. 

where 1=1 은 어떤이유 때문에 소스에 사용 되는지와 사용하지않는다면 어떤 대안이 있는지 알아볼까 한다..

( 필자는 where 1=1 을 사용시 DB실행에 불필요한 수식연산이 들어가여 자원을 잡아먹어 선호하지 않는 의견을 몇번 들어보긴 하였다.. )

WHERE 1=1 참(ture)을 의미

쿼리의 조건을 동적으로 사용하기위해 사용한다고 한다.

하지만, DLETE(삭제), UPDATE(수정) 기능을 수행하는 쿼리에서는 null판별이 옳바르게 전처리 작업이 수행되지 않는 상황에서 삭제나 수정 기능에 사용한다면 원치않는 결과를 초래할수 있다고한다. 왜냐하면 1=1 은 참이기때문에 모든 데이터를 삭제하거나, 모든데이터를 수정하는 일이 발생할수 있기때문이다.

정리하자면, 대부분에 동적인 상황을 고려하여 WHERE 1=1을 사용하는 경우가 대부분의 사용하는 이유가 될것이라고 필자는 생각한다, 하지만 의도치않는 예외적인 상황이 발생한다는 점을 고려한다면 좋은 방법은 아닌것이라고 생각이된다.

WHERE 1=1 에대해서 사용하는 이유와 반대로 WHERE 1=1 을 사용하지 말아야 한다는 이유를 찾다가 잘 정리된 2개의 블로그 게시글이 있어 공유한다. (판단은 본인이...)

WHERE 1=1 의 대안으로는 <where> 태그와 <c:if>  태그를 사용하여 대체하는 방법을 권고한다.

예시 

WHERE 1=1 
 and user_id = #{userId}

<where>
    <if test="userId != null and userId != ' ' ''> 
        and user_id = #{userId}
    </if>
</where>

마지막으로 해당 mybtais 동적SQL에 대한 자세한 내용은 mybatis 공식사이트에서 확인할 수 있다.

DOM Document Object Model 

: 문서 객체 모델

https://developer.mozilla.org/ko/docs/Web/API/Document_Object_Model/Introduction

BOM Browser Object Model 브라우저 객체 모델

: 브라우저를 제어하기 위한 인터페이스

• window : 모든 객체가 소속된 객체(최상위 객체)
  https://developer.mozilla.org/ko/docs/Web/API/Window
• document : 현재 문서에 대한 정보를 가지고 있는 객체
• history : 현재의 브라우저가 접근했던 URL history를 제어할수있음
• location : 문서의 주소와 관련된 객체로 window 객체의 프로퍼티인 동시에 document의 프로퍼티, 문서URL 변경하며 다양한 정보를 얻을수 있음.
• screen : 사용자의 디스플레이 화면에 대한 다양한 정보를 가지고 있는 객체
• navigator : 실행중인 애플리케이션(브라우저)에 대한 정보를 알 수 있다. 

script 로드 해결 방법 (2가지)

• body 태그 최 하단에서 script 로드 (html 파싱 후 script 로드)
• load 이벤트 리스너 등록 : window.onload (html 파싱 DOM생성 그리고 외부콘텐츠가 로드된 후 발생하는 이벤트)

HTML5 script 로드 해결방법 (feat. defer, async)

• defer 속성 : HTML 파싱과 함께, 비동기로 javaScript 파일을 불러온다. (일반적인 경우)

• async 속성 : HMTL 파싱과 함께, 비동기로 javaScript 파일을 불러온다. 단, script가 실행될경우 html 파싱을 중지한다.

* 동기,비동기 설명 https://www.youtube.com/watch?v=sN4E9_u7xQk

' this ' 란 무엇인가?

대부분의 경우 this의 값은 함수를 호출한 방법에 의해 결정된다고 한다.. (this는 호출한 놈?이라고 이해하며, 호출한 행위가 없을경우 기본값으로는 window객체 라고한다.) 단, 위의 경우와 달리 아래와 같이 예외적인 상황도 존재한다. 

1. 전역스코프에서 this는 window 객체
2. 화살표 함수*( Arrow Function)에서는 조금 달라짐..
3. strict Mode 에서도 this 는 조금 달라짐.

* window객체 : 브라우저에서 제공하는 전역 객체

default this = window 객체, 함수를 호출한적이 없을 경우 기본적으로 this는 window 객체

220906 추가내용 : 

bind()

bind() 메서드 : this를 설정할수있는 메서드 단, bind는 단 1번만 this를 설정할 수 있다.

화살표 함수(arrow function)

화살표 함수(arrow function)는 자신을 포함하고 있는 외부 Scope에서 this를 계승받는다.  (화살표 함수에서 this는 자신을 감싼 정적 범위)

Strict Mode

엄격모드?(Strict Mode)에서는 함수를 호출한적이 없을 경우 기본값을 window로 하지않고 undefined로 정의 한다.

출처 : https://www.youtube.com/c/gymcoding

전체쿼리 결과 집합을 쉼 없이 연속적으로 전송하지 않고 사용자로 부터 Fetch Call이 있을때 마다 일정량씩 나누어 전송하는 것을 '부분범위 처리'라고 한다.

정렬조건이 있을때 부분범위 처리

인덱스는 항상 정렬된 상태를 유지하므로 전체 데이터를 정렬하지 않고도 정렬된 상태의 결과집합을 바로 전송할 수 있다.

Array Size 조정을 통한 Fetch Call 최소화

대량 데이터를 파일로 내려받는다면 데이터를 모두 전송해야하므로 가급적 Array Size를 크게 설정해야한다. Array Size를 조정한다고 해서 전송해야 할 총량이 변하진 않지만, Fetch Call 횟수를 그만큼 줄일수 있으며, 반대로 앞쪽 일부 데이터만 Fetch하다가 멈추는 프로그램이라고 할 경우 Array Size를 작게 설정하는 것이 유리하다.(불필요하게 많은 데이터를 전송하고 버리는 비효율을 줄일수 있음.)

쿼리 툴에서 부분범위 처리

모든 DBMS는 데이터를 조금씩 나눠서 전송한다. 즉, 부분범위 처리 방식으로 결과집합을 전송한다. 이 특징을 이용해 중간에 멈췄다가 사용자의 추가 요청이 있을 때마다 데이터를 가져오도록 구현하고 안하고의 차이는 책의 저자가 말하길 DBMS 클라이언트 프로그램을 개발하는 개발자의 몫이라고 말한다.

부분범위 처리 구현

개발 프레임워크에 미리 부분범위 처리 된 구현 기능을 활용하면 된다고 한다. 

OLTP(Online Transaction Processing) 

온라인 트랜잭션을 처리하는 프로그램을 말하며, 일반적으로 소량 데이터를 읽고 갱신한다. (하지만 항상 소량 데이터만 조회하는것은 아님)

수천수만 건을 조회하는 경우에는 많은 테이블 랜덤 액세스가 발생하기  때문에 제 성능을 내기 어려울수 있다. 버퍼캐시히트율이 좋다면 빠른 성능을 보일수 있지만, 아닌 경우도 존재하기 때문이다. 

 그러나 OLTP성 업무에서 쿼리 집합이 아주 많을 때 사용자가 모든 데이터를 일일이 다 확인하지 않는다. 특정한 정렬 순서로 상위 일부 데이터만 확인한다. (ex. 은행계좌 입출금 조회, 뉴스 또는 게시판 등등..) 주로 목록을 조회하는 경우. 이런 경우 항상 정렬 상태를 유지하는 인덱스를 이용하면, 정렬 작업을 생략하고 앞쪽 일부 데이터를 아주 바르게 보여줄수 있다. (인덱스와 부분범위 처리를 잘 활용한다면 OLTP환경에서 극적인 성능 개선 효과를 얻을수 있다고 함.)

멈출 수 있어야 의미있는 부분범위 처리(문제는 앞쪽 일부만 출력하고 멈출 수 있는가..? _부분범위 처리 핵심*)

해당 내용은 추후 5장 3절에서  다룬다고 함..

배치I/O  :  읽는 블록마다 건건이 I/O Call을 발생시키는 비효율을 줄이기 위해 고안한 기능.

  인덱스를 이용해 테이블을 액세스하다가 버퍼 캐시에서 블록을 찾지 못하면 일반적으로 디스크 블록을 바로 읽는데(오라클11g 까지), 배치I/O기능이 작동하면 테이블 블록에 대한 디스크 I/O Call을 미뤘다가 읽을 블록이 일정량 쌓이면 한꺼번에 처리한다. (오라클12c 이후 해당)

(* 12c에 도입된 일반 배치 I/O와 NL조인에 작동하는 기존 배치I/O는 파라미터, 힌트, 실행계획 표현방식이 모두 다르다.)

 배치I/O를 통해 얻을수 있는 성능 이점이 많은에도 불구하고 시스템레벨에서 이를 비활성화 하는 경우가 종종있다. 이 기능을 비활성화하는 이유는 '필요한' order by를 생략한 SQL패턴 때문라고 한다. SQL에 order by가 없으면 결과 집합의 정렬 순서를 보장할 필요가 없으므로

옵티마이저가 배치I/O를 선택할 수 있고, 출력된 결과집합의 정렬 순서가 매번 다를수 있다.

데이터 정렬 이슈 :

배치I/O 기능이 작동하면 인덱스를 이용해서 출력하는 데이터 정렬 순서가 매번 다를수 있다는 사실에 주목해야 함..

@RequestBody,  @RequestParam, @ModelAttribute

@RequestBody : 클라이언트가 전송하는 JSON(application/json) 형태의 HTTP Body를 JAVA객체로 변환시켜주는 역할,

 Body가 존재하지 않는 HTTP Get 메소드에 @RequestBody를 활용하려고 한다면 에러가 발생한다. @RequestBody로 받는 데이터는 Spring에서 관리하는 MessageConverter 중 MappingJackson2HttpMessageConverter를 통해 JAVA객체로 변환하는데, 이는 ObjectMapper 라는 클래스를 이용한다.

@RequestParam : 1개의 HTTP요청 파라미터를 받기 위해서 사용한다. @RequestParam은 필수 여부가 true이므로 반드시 해당 파라미터가 전송되어야 하며, 파라미터가 전송되지 않으면 400에러를 발생한다. (필수값이 아닌경우 required를 false로 설정하는 방법이 있으며, defaultValue옵션을 사용하면 기본값 역시 지정 가능하다.)

@ModelAttribute : 클라이언트가 전송하는 multipart/form-data 형태의 HTTP Body와 HTTP 파라미터의 값들을 생성자나 Setter를 통해 주입하기 위해 사용된다. @ModelAttribute에는 매핑시키는 파라미터의 타입이 객체의 타입과 일치하는지를 포함한 다양한 검증(Validiation) 작업이 추가적으로 진행되는데, 예를 들어 게시물의 번호를 저장하는 int형 index 변수에 "1번" 이라는 String형을 넣으려고 한다면, BindException이 발생하게 된다.
@ModelAttribute을 사용해서 특정 Parameter 값 만을 가져올 수도 있다.

* ObjectMapper의 동작과정 : ObjectMapper는 Json 메세지를 자바 객체로 변환하는 과정에서 객체의 기본 생성자를 통해 객체를 생성하고, 내부적으로 Reflection을 사용한다. 그래서 반드시 @Setter가 필요한 것은 아닌데, @Getter나 @Setter 혹은 @JsonInclude 등 필드에 있는 변수들의 이름을 찾기 위한 메소드들을 필요로 한다.

 그러므로 기본생성자 + @Getter로 클래스를 구현해주면 @Setter가 없어도 값이 바인딩된다.

출처: https://mangkyu.tistory.com/72 [MangKyu's Diary:티스토리]MangKyu's Diary:티스토리]

오라클에서 랜덤 엑세스가 아예 발생하지 않도록 테이블을 인덱스 구조로 생성하는 방법을 IOT(Index-Organized Table)이라 함.

(MS-SQL Server 에서는 '클러스터형 Clustered 인덱스'라고 함. 

 테이블을 찾아가기 위한 ROWID를 갖는 일반 인덱스와 달리 IOT는 그자리에 테이블 데이터를 갖는다.(즉, 테이블 블록에 있어야 할 데이터를 인덱스 리프 블록에 모두 저장하고 있다. IOT에서는 '인덱스 리프 블록이 곧 데이터 블록' 이다. )

일반 테이블은 '힙 구조 테이블'이라고 부른다.  일반 힙 구조 테이블에 데이터를 입력할 때는 랜덤 방식을 사용한다. 반면, IOT는 인덱스 구조 테이블이므로 정렬 상태를 유지하며 데이터를 입력한다.

IOT는 인위적으로 클러스터링 팩터를 좋게 만드는 방법 중 하나이며, Between이나 부등호 조건으로 넓은 범위를 읽을때 유리하다. 또한, 데이터 입력과 조회 패턴이 서로 다른 테이블에도 유용하다.

클러스터 테이블 : 클러스터 테이블에는 인덱스 클러스터와 해시 클러스터 두 가지가 있다.

인덱스 클러스터 테이블 :

 클러스터 키값이 같은 레코드를 한 블록에 모아서 저장하는 구조. 한 블록에 모두 담을 수 없을 때는 새로운 블록을 할당해서 클러스터 체인으로 연결한다. 추가적으로 여러 테이블 레코드를 같은 블록에 저장할 수도 있는데, 이를 '다중 테이블 클러스터' 라고 함. (일반 테이블은 하나의 데이터 블록을 여러 테이블이 공유할 수 없음)

 클러스터에 테이블을 담기 전에 아래와 같이 클러스터 인덱스를 반드시 정의해야 한다. 클러스터 인덱스는 데이터 검색 용도로 사용할 뿐만 아니라 데이터가 저장될 위치를 찾을 때도 사용하기 때문..

 클러스터 인덱스도 일반 B*Tree 인덱스 구조를 사용하지만,  테이블 레코드를 일일이 가리키지 않고 해당 키 값을 저장하는 첫 번째 데이터 블록을 가르킨다는 점이 다르다. 따라서 클러스터 인덱스의 키값은 항상 유니크하다(=중복값이 없다)

해시 클러스터 테이블 :

 해시 클러스터는 인덱스를 사용하지 않고 해시 알고리즘을 사용해 클러스터를 찾아간다는 점만 다르다.