기능

javascript와 img태그를 사용하여 사용자로부터 버튼 클릭을 입력 받을 시 a 태그를 생성, blob을 불러와 이미지를 다운로드 하려고 한다. 

 

 

발생문제

1. 단순 blob이 아닌 url을 이용하여 파일을 다운로드 시 새창으로 열리는 현상이 있다.

(해결)아래와 같이 fetch, axios등을 이용하여 blob으로 내려받아 오픈한다.

     const response = await axios.get(IMG_URL + url, {
        responseType: 'blob',
      });

      const blob = new Blob([response.data]);
      const imageUrl = URL.createObjectURL(blob);

      const link = document.createElement('a');
      link.href = imageUrl;
      link.download = url;
      document.body.appendChild(link);
      link.click();
      document.body.removeChild(link);

 

2. 간헐적 cors 에러가 발생

 

(1)의 코드를 이용하여 다운로드를 시도 시 간헐적으로 cors가 발생한다.

크롬 개발자 도구의 disable cache를 체크 시 정상적으로 다운로드 수행됨을 확인하여, 캐시 문제라고 판단하였다. 이 캐시 문제를 해결하기 위하여 아래와 같은 헤더 설정을 해보았지만 브라우저는 여전히 캐싱을 하였다.

      const response = await axios.get(IMG_URL + url, {
        responseType: 'blob',
        withCredentials: false,
        headers: {
          'Cache-Control': 'no-store',
          'Access-Control-Allow-Origin': '*',
          'Access-Control-Allow-Credentials': 'true',
        },
      });

 

이 원인에 대해 자세히 설명해준 " https://blog.hwahae.co.kr/all/tech/5412 " 글을 요약하면

 

html 태그 상 img src태그에서 aaa.co.kr/img1.png를 불러들일때 헤더를 포함하여 브라우저가 캐싱, 추 후 사용자의 버튼 클릭을 입력받아 다운로드 받는 함수 (1)를 수행하지만, 이미 img태그에서 aaa.co.kr/img1.png를 캐싱해버렸고, axios함수에서 또 한번 같은 주소인 aaa.co.kr/img1.png를 호출할때 img태그에서 사용한 헤더 정보를 가지고 요청(특정 정보가 없는 헤더정보)하여 cors에러가 발생하게 된것.

 

그 외 https를 서버에 올렸을 때, 서버상에서는 정상동작하고 로컬(http)에서는 cors가 발생하기도 하였다.

'Javascript > DOM 관련' 카테고리의 다른 글

[DOM API] DOM 그리고 HTMLElement  (0) 2019.12.17
[JAVASCRIPT] 브라우저 로드 순서  (0) 2019.12.01
[JAVASCRIPT] 스크롤 거리 구하기  (2) 2019.12.01
[JAVASCRIPT] event processing  (0) 2019.12.01

 

 

 

문제의 404 화면(수정메뉴 왼쪽 이미지 깨짐)

 

 

 

 

- 현상 

위와 같이, cloud storage에 이미지를 업로드 직후 이미지  not found 현상.

그러나 일정시간 후 혹은 일정 횟수 강제로 refresh하면 이미지가 보이는 현상.

 

- 원인

처음에는 업로드 링크(getDownloadURL())가 반환이 제대로 되지 않았나 추측하여 확인해보니,링크는 문제가 없었다.

 

자세히 살펴보니, 이미지의 크기가 큰 경우 업로드가 완료되었더라도, 심지어 해당 이미지 링크가 정확히 firestore에 의하여 반환(getDownloadURL())이 되었더라도, 해당 링크가 유효하기까지는 시간이 걸린다는 것을 확인하였다.

 

- 추측 

추측 근거1 : 무식한 방법으로 확인을 해보았는데, 큰 크기의 이미지 파일(400MB)를 업로드 후 반환된 이미지 링크를 그대로 복사하여 브라우저에 직접 접근해보니, 이 역시 404가 발생되다가, 일정 시간 후 정상 표출되는 점.

추측 근거2 : 에러가 발생한 시점의 링크 주소와 정상적으로 표출될때의 링크주소는 같으므로, 링크는 문제가 없다는 점.

추측 근거3 : 정상적으로 표출될때까지의 시간이 이미지 크기에 비례하여 소요된다는 점. 

 

 

- 처리

이미지를 업로드 후 내부적으로 해당 이미지링크가 정상처리될때까지 progress bar를 표출하는 방법이 있겠고,

해당 이미지가 정상적으로 보여질때까지 재시도를 하는 방법이 있겠다.

 

여기서 필자는, 재시도하는 방법을 택했으며, 브라우저를 refresh(F5)하는 방법보다는,

해당 이미지에 error를 캐치하여 재시도하는 로직을 넣었다.

 

 

ember.js 프로젝트의 경우

 

firebase로부터 반환된 이미지 주소를 get

 

template

 

 

 

react 프로젝트의 경우

 

 

 

와 같이 error핸들을 catch하여 retry로직을 타도록 처리하였다.

 

 

 

 

해당 이미지는 허블딥필드 (400mb짜리 이미지), 재시도 로직에 의하여 3회 후 정상 표출됨을 확인

(재시도 3번 후 정상 표출됨을 확인)

 

 

그외 방안

1. 애초에 이미지 등록 시 크기 제한하는 방안.

2. 위의 재시도 방법

3. progress bar 처리

 

그러나 수정/등록 시 불필요하게 progress bar를 통하여 사용성을 저해하기 보다는

정상처리 될때까지 재시도 처리함(2번).

 

 

 

 

 

---------------------------------------------------------------------------------------------------------------

 

번외,

 

2022.01.14 이와 관련하여 chatGPT에 문의해보니 답변이 바로 나왔다. 어떻게... 가능한거지...

 

 

When you upload an image to Firebase Storage, it is first stored in a temporary cache before it is fully uploaded to the server. This is done to ensure that the upload process is as fast and efficient as possible, even if the user's internet connection is not very stable.

Once the image is fully uploaded to the server, it is then made available for retrieval. However, depending on the network conditions, there may be a delay between the time the image is uploaded and the time it is fully available for retrieval.

This delay can be caused by several factors such as network congestion, high traffic to the server, or slow upload speeds. Additionally, Firebase Storage is built on top of Google Cloud Storage, which is a highly-scalable object storage service that enables users to store and access data in near real-time.

If you want to ensure that the image is immediately available for retrieval after upload, you can use the put method provided by the Firebase Storage SDK, along with the .on method that allows you to register a listener that triggers once the image is uploaded.

You can use the put method to upload the image and the .on method to register a listener that will listen for the state_changed event, which is triggered when the upload state changes. Once the state_changed event is triggered, you can check if the upload is complete and if so, you can retrieve the URL of the uploaded image and use it to display the image on the page.

In summary, the delay in the image appearing on the page is likely due to the image being temporarily stored in a cache before it is fully uploaded to the server, and it can be caused by network conditions, high traffic, or slow upload speeds. However, you can use the put method with the .on method to ensure that the image is immediately available for retrieval after upload.

 

 

개인적인 생각으로는 지구 상 어디에서든지 위 현상은 겪었을테지만, 문제는 그 현상에 대한 글을 어떻게 효율적으로 검색하냐.. 가 문제다.

위 답변에 대한 글, 지식, 질/답 글을 검색할 수가 없어서 삽질(?)아닌 삽질을 하게 되었는데. chatGPT는 도대체 어떻게 ...

 

사실 개발이라는 것은 원하는 정보를 찾아서 응용하는것이 대부분이라고 생각된다. 그리고 트러블슈팅. 트러블슈팅의 연속,

하나의 작은 문제를 해결하고 다음 문제를 해결하다보면 기능이 완성되어지고 그 기능들이 모여져서 프로그램이 완성된다.

그러나 모든 것을 다 해본적도 없고 사람의 암기력은 한계가 있으므로 아는 것이라도 다시 문서를 뒤적거려야 하고 본문글처럼 자기가 가진 수준의 지식으로 여러가지 실험과 시도를 통해 해결하면서 프로그램을 만드는데, "정확한 질문"만으로 확실하진 않지만 저런 수준의 답변은 개발자들에게 꽤나 생산성을 높여줄것같다.

GPT4는 더 높은 성능을 보여줄것이라고 하고, 유료라더라도 충분히 지불할 의향이 있다!!

 

 

 "opencv를 이용하여 간단한 자동차 번호 인식 코드를 달라"라고 하니 쌩뚱 맞은 코드를 내놓는것을 보면 완벽하진 않아보인다. 그러나 함수단위로 input과 output을 명시한다면 원하는 코드를 짜주는 것 같다. 조금 더 적극적으로 사용해봐야겠음.

마이그레이션 순서

 

  1. Add TypeScript
  2. Add tsconfig.json
  3. Start simple
  4. Convert all files
  5. Increase strictness
  6. Clean it up
  7. Celebrate

 

1. typescript 설치

 

npm install --save typescript @types/node @types/react @types/react-dom @types/jest

yarn add typescript @types/node @types/react @types/react-dom @types/jest

를 통하여 typescript 및 기타 모듈을 설치한다.

 

기존 js 기반 react의 react-router-dom의 경우

npm install react-router-dom로 설치한다.

 

하지만 ts에서는 npm install @types/react-router-dom 로 설치를 새로 해야한다.

이 글의 마지막에 이 프로젝트에서 사용되어지는 @types/*의 package.json을 넣어두겠다.

 

위 문제의 에러 메시지는 보통 "  Could not find a declaration file for module 'react-redux'.  "와 같이

모듈을 찾을 수 없다고 나온다.

 

 

2. tsconfig.json 추가

 

tsconfig.json는 프로젝트를 컴파일하는 데 필요한 루트 파일과 컴파일러 옵션을 지정하는 파일입니다.

 

[참고사이트]

www.typescriptlang.org/docs/handbook/tsconfig-json.html

typescript-kr.github.io/pages/tsconfig.json.html

 

 

npx tsc --init

를 수행하여 생성하거나 직접 tsconfig.json 생성

 

아래는 npx tsc --init를 이용하여 기본적으로 생성되는 tsconfig.json 포맷.

더보기

{

  "compilerOptions": {

    /* Visit https://aka.ms/tsconfig.json to read more about this file */

 

    /* Basic Options */

    // "incremental": true,                   /* Enable incremental compilation */

    "target""es5",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */

    "module""commonjs",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */

    // "lib": [],                             /* Specify library files to be included in the compilation. */

    // "allowJs": true,                       /* Allow javascript files to be compiled. */

    // "checkJs": true,                       /* Report errors in .js files. */

    // "jsx": "preserve",                     /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */

    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */

    // "declarationMap": true,                /* Generates a sourcemap for each corresponding '.d.ts' file. */

    // "sourceMap": true,                     /* Generates corresponding '.map' file. */

    // "outFile": "./",                       /* Concatenate and emit output to single file. */

    // "outDir": "./",                        /* Redirect output structure to the directory. */

    // "rootDir": "./",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */

    // "composite": true,                     /* Enable project compilation */

    // "tsBuildInfoFile": "./",               /* Specify file to store incremental compilation information */

    // "removeComments": true,                /* Do not emit comments to output. */

    // "noEmit": true,                        /* Do not emit outputs. */

    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */

    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */

    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

 

    /* Strict Type-Checking Options */

    "strict"true,                           /* Enable all strict type-checking options. */

    // "noImplicitAny": true,                 /* Raise error on expressions and declarations with an implied 'any' type. */

    // "strictNullChecks": true,              /* Enable strict null checks. */

    // "strictFunctionTypes": true,           /* Enable strict checking of function types. */

    // "strictBindCallApply": true,           /* Enable strict 'bind', 'call', and 'apply' methods on functions. */

    // "strictPropertyInitialization": true,  /* Enable strict checking of property initialization in classes. */

    // "noImplicitThis": true,                /* Raise error on 'this' expressions with an implied 'any' type. */

    // "alwaysStrict": true,                  /* Parse in strict mode and emit "use strict" for each source file. */

 

    /* Additional Checks */

    // "noUnusedLocals": true,                /* Report errors on unused locals. */

    // "noUnusedParameters": true,            /* Report errors on unused parameters. */

    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */

    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

 

    /* Module Resolution Options */

    // "moduleResolution": "node",            /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */

    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */

    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */

    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */

    // "typeRoots": [],                       /* List of folders to include type definitions from. */

    // "types": [],                           /* Type declaration files to be included in compilation. */

    // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */

    "esModuleInterop"true,                  /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */

    // "preserveSymlinks": true,              /* Do not resolve the real path of symlinks. */

    // "allowUmdGlobalAccess": true,          /* Allow accessing UMD globals from modules. */

 

    /* Source Map Options */

    // "sourceRoot": "",                      /* Specify the location where debugger should locate TypeScript files instead of source locations. */

    // "mapRoot": "",                         /* Specify the location where debugger should locate map files instead of generated locations. */

    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */

    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

 

    /* Experimental Options */

    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */

    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */

 

    /* Advanced Options */

    "skipLibCheck"true,                     /* Skip type checking of declaration files. */

    "forceConsistentCasingInFileNames"true  /* Disallow inconsistently-cased references to the same file. */

  }

}

 

 

 

 

3. convert all files

 

사실 TS를 모르는 상태에서 TS 변환 후 배워나가겠다..라는 방법은 맞지 않다.

ts로 전환하는 과정에서는 기존 js에 ts의 type annotation을 일일히 수작업으로 맞추어주어야 하기 때문에

ts에 대한 문법적 지식이 전무한 상태에서는 진행하기가 힘들다고 생각이 된다.

 

tsconfig.json rule을 매우 느슨하게 설정(strict:false)하여 진행해볼수도 있다.

(본 작성자는 TS를 모르는 상태에서 작업을 진행하였다)

 

 

모든 js react프로젝트에 해당하는것은 아니지만, 적어도 내가 진행하는 프로젝트에서 나오는 문제점들을 하나하나 나열해가면서 진행한다.

 

1. 위에 말했던 react-router-dom이 ts버전인 package를 설치해야하는 문제.

 

2. 

상대경로 관련 문제

 

 

import App from "app"; 부분을 보자.

정확히는 tsconfig.json의 "moduleResolution""node", << 이 옵션에 관한 문제.

 

chiabi.github.io/2018/08/30/typescript/

www.typescriptlang.org/docs/handbook/module-resolution.html .

 

세부적인 moduleResolution은 위의 링크에서 확인하길 바랍니다.

필자는 import App from "./App"; << 로 상대경로를 지정했습니다.

해당 옵션을 보고, node로 설정 후 require로 끌어오는 것을 추천드립니다.

 

 

 

 

 

 

 

SVN(형상관리)와 연결하여 젠킨스가 최신의 소스를 가져와서 빌드하기 위한 설정.

 

 

 

 

새로운 ITEM 클릭

 

 

Freestyle project 선택

 

 

 

소스 관리 부분에 SVN설정

Repository URL : svn url

Credentials : Add 버튼을 클릭하여 실제 svn에 접속이 가능한 svn 계정과 비밀번호 입력

 

위와 같이 기본적인 설정을 마친 후 저장.

 

 

 

Build Now를 클릭

 

 

바로 아래에 build history에 빌드 완료(파란색) 여부가 표시되고

 

 

 

 

작업공간을 클릭시 정상적으로 svn의 소스를 가져 온 것을 확인하여 SVN과의 연결 완료

'WEB > CI CD' 카테고리의 다른 글

2. Jenkins 설치  (0) 2020.03.03
1. CI / CD 개념  (0) 2020.03.03

 

이 글에서는 Linux, tomcat환경에서의 설치를 설명합니다.

 

 

 

https://jenkins.io/

 

Jenkins

Jenkins – an open source automation server which enables developers around the world to reliably build, test, and deploy their software

jenkins.io

 

 

Jenkins에서 제공하는 파일은 대표적으로 *.war , rpm 형식을 제공합니다.

 

 

여기서는 war형식의 젠킨스를 다운받아 다음과 같은 명령어로 바로 구동됩니다. (설치과정없음)

java -jar jenkins.war.  혹은 java -jar jenkins.war --httpPort=9090

https://jenkins.io/doc/book/installing/#war-file

 

그외 apt-get, yum, rpm으로 설치하는 방식이 있으며, 

 

war방식은 신경쓸것없이 바로 구동이 되는 반면 rpm은 아주 조금 까다로우나 jenkins workspace(war가 생성되는 위치)경로등 기타 설정을 할 수 있다는 장점이 있습니다.

 

여기에서는 war파일을 통하여 진행하겠습니다.

 

 

 

젠킨스를 실행할 때 아래와 같이 

nohup java -jar jenkins.war --httpPort=8888 & 

로 수행하여 백그라운드 및 터미널이 닫혀도 젠킨스가 유지되도록 합니다.

 

 

 

위의 명령어로 수행시 터미널에 아래와 같은 화면이 나오지 않습니다. (nohup.out 파일에 있는 내용입니다)

 

위에서 패스워드가 나오고 이것을 그대로 복사 한 후 unlock시 사용합니다.

 

 

https://jenkins.io/doc/book/installing/#unlocking-jenkins

 

 

 

 

 

jenkins.war 수행 시 기입한 포트명으로 localhost:8888 로 접속 시 설치 확인

 

 

 

 

- 설치 후 위의 로그인 창 전에 플러그인 설치를 묻는데 어느것을 선택해도 무방합니다. 추후 플러그인은 얼마든지 제거/수정이 가능하기 때문입니다.

'WEB > CI CD' 카테고리의 다른 글

3. SVN과 연결  (0) 2020.03.03
1. CI / CD 개념  (0) 2020.03.03

 

 

정의 : CI(지속적인 통합) / CD (지속적인 배포)를 통하여 애자일 방법론을 실현시킨다. 애자일을 실현시키기 위하여 ci/cd한다

 

 

애자일에 대해 간략 설명하자면, 기존의 폭포수 모델의 개발 방법론은 최초 고객의 요구사항을 얻어 개발이 진행된다. 그러나 고객의 요구사항은 수시로 바뀌고 처음 설계한 컨셉과 달라지기 때문에 유연하게 대처하기가 곤란해지며 이는 일정 지연, 품질의 저하로 이어진다. 이러한 요구사항에 대응하기 위하여 폭포수 모델과 달리 개발 과정 중에 수시로 고객에게 프로토타입으로써 결과물을 보여주고 피드백을 받고 수정하여 대응한다.

 

 

 

 

우측 상단, Continuous Visibility를 실현

 

CI를 실시함으로써의 이점은 다음과 같다.

  • 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
  • 자동화 테스트 수행 ( 테스트를 거치지 않는 CI는 불완전하다. 반드시 수행해야함)
  • 정적 코드 분석에 의한 코딩 규약 준수여부 체크
  • 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시
  • 결합 테스트 환경에 대한 배포작업

단점은 다음과 같다.

  • 다른 개발자의 코드들을 합쳐보니 실행이 안된다. ( 머지 이슈 )
  • 내 PC에서는 됐는데 통합하니 실행이 안된다. ( 환경적인 이슈 )
  • 통합되기 전에는 자신이 갖고 있는 소스가 최근 통합된 코드가 아닐 수 있다.
  • 통합되기 전에는 개발 중간 과정을 눈으로 확인하기 힘들다.

 

체계가 확립되지 않은 곳에서는 개발자가 war파일을 ftp로 직접 업로드 후 WEB/WAS를 재시작하거나 수정된 일부분의 파일을 직접적으로 올리면서 수정하고 있다.

개발환경을 맞추었다고는 하나 여러명의 개발자가 자신의 pc에서 각자 개발한 소스를 최종적으로 병합하는 과정에서의 문제가 발생할 수 있고, 서버에 반영하는 과정에서의 Human error등의 위험성이 있다.

또한 Local에서 개발하여 테스트 후 다시 운영 서버에 반영 후 테스트등의 작업에 적잖은 시간을 소모한다. 

 

 

이를 위해 CI 툴인 jenkins등을 통하여 아래와 같은 방법으로 CI를 실현한다.

 

1. 각자 개발자는 형상관리 서버에 커밋한다.

2. CI툴(젠킨스)는 소스 변경을 탐지(혹은 스케줄링등 특정 조건에서 발동하게 셋팅가능)

3. 젠킨스에 설정한 JDK등의 컴파일러 여러 기타 도구(maven, gradle)을 통하여 빌드

4. 빌드에 성공하면 junit등의 테스트 수행

5. 테스트까지 성공하면 WEB/WAS서버에 자동으로 배포( 쉘 스크립트등을 통한 web 서버 재시작)

 

 

 

"고객이 확인할 수 있게 항상 빌드가 깨지지 않게 유지하는 것이 중요합니다."

 

 

간단히 요약하자면 "커밋하면 자동으로 테스트(테스트코드가 있다면)와 빌드를 수행하고, 에러가 발생하지 않는다면 타겟(개발/운영)서버에 배포해준다."

 

 

 

 

'WEB > CI CD' 카테고리의 다른 글

3. SVN과 연결  (0) 2020.03.03
2. Jenkins 설치  (0) 2020.03.03

 

 

흔히들 CMOS와 BIOS를 혼동하곤 한다. 컴퓨터 부팅하면서 부팅순서나 연결 장치들의 정보를 보기위한 파란 화면을 CMOS 세팅 또는 BIOS 세팅을 하기 위한 창이라고 이야기 하곤 한다. 둘의 단어적인 의미만 보아도 전혀 다른 두 개의 용어가 왜 혼동되어 비슷하게 사용되고 인식되고 있는지 한번 알아보자.

 

CMOS

CMOS(Complementary metal-oxide semiconductor)는 한글로 표기하면 상보성 금속산화막 반도체라고 한다. '씨모스'라고 불리는 말에 비해 참으로 어렵다. 쉽게 말해 광다이오드를 사용하여 집적회로를 만들기 위한 기술의 하나이다. 이러한 CMOS 기술은 CPU, microcontroller, static RAM 과 같은 디지털 논리 회로에 쓰인다. 더이상 CMOS에 대한 기술을 언급하는 것은 전자공학을 전공하지 않은 사람에게는 오히려 혼란만 가중될 것 같다.

그렇다면 이러한 반도체와 컴퓨터 시스템에서 흔히 말하는 CMOS와 무슨 차이가 있을까? 컴퓨터 메인보드를 살펴보면 RTC/NVRAM이라고 불리우는 CMOS chip이 존재한다. 메인보드 수은 건전지 옆에 존재하는 이 chip이 CMOS 방식으로 만들어져 있기 때문에 그냥 그렇게 불리어온 것이다. 수은 건전지는 CMOS battery라고 하는데 시스템이 꺼진 경우에도 RTC/NVRAM의 내용을 지속적으로 유지시키기 위해 존재한다.

그럼 CMOS 의 핵심인 RTC/NVRAM은 대체 어떤 정보를 저장하고 있을까?

RTC(Real-Time Clock)은 시스템의 날짜와 시간을 저장하고 있고 NVRAM(Non-Volatile RAM)은 비휘발성 램으로 메모리 크기, 드라이브(플로피 및 하드 등) 타입, 부팅 순서 및 구성 정보 등의 CMOS data를 저장하고 있다.

 

BIOS

BIOS(Basic Input Output System)은 운영체제와 하드웨어 사이의 입출력을 담당하기 위해 저수준의 소프트웨어와 드라이버로 이루어진 펌웨어을 의미한다. 쉽게 말해 운영체제는 메인보드나 그래픽카드와 같은 하드웨어와 통신하기 위해 중간 매개체를 사용해야 한다. 그렇게 되면 운영체제는 세부적인 하드웨어의 구성이나 신호체계를 알 필요없이 중간 매개체와만 통신하면 된다. 이러한 중간 매개체 역할을 하는 것이 BIOS이며 이것은 하드웨어가 제조될 때 제조회사에서 하드웨어에 포함시켜 둔다.

하드웨어에 포함시켰기 때문에 전원이 없는 상태에서도 유지되야 하므로 ROM을 사용한다. 흔히 메인보드의 BIOS를 ROM BIOS라고 부른다. 이것은 메인보드 뿐만아니라 SCSI, VGA에도 포함되어 제조된다.

 

CMOS vs BIOS

그렇다면 이제 왜 CMOS와 BIOS가 혼동되고 있는지 살펴보자. 부팅하면서 부팅 설정을 하기 위한 파란 화면에 뜨는 내용들은 실제 CMOS(RTC/NVRAM)에 저장되어 있다. 하지만 이러한 데이터를 설정할 수 있도록 파란화면을 뜨게 하는 프로그램(유틸리티)는 ROM BIOS에 존재한다. 따라서 컴퓨터 시스템을 부팅하면서 F1, F2, ESC, Delete(제조 회사마다 차이)들의 키를 누르게 되면 ROM BIOS에 포함된 BIOS 설정 유틸리티가 CMOS의 내용을 읽어와 설정할 수 있도록 보여주는 것이다.

어떻게 보면 CMOS 설정이나 BIOS 설정이나 그 말이 나름대로 의미가 맞는 말일 수도 있다. 하지만 이러한 차이쯤은 인식하고 쓰는 것이 좋을 듯 하다. 

 

 

 

 

http://forensic-proof.com/archives/181

Document

 

- DOM을 설명하기 앞서, Document는 브라우저가 불러온 웹 페이지를 나타내며, 모든 종류의 문서에 대한 공통의 속성과 메서드를 묘사합니다. 

- Document는 node tree로 표현될 수 있으며, tree안의 일부 node들은 children을 가질 수 있고 단순히 node만 존재할 수 있습니다. Document또한 Node를 상속받습니다. 

 

DOM

 

- "DOM"이란 간단히, Document( HTML or XML)을 접근/조작하는 API라고 할 수 있습니다. 문서의 유형(HTML, XML, SVG 등)에 따라서 더 다양한 API가 존재합니다. 그러므로 DOM은 HTML, XML, SVG등을 다루는 API 인터페이스 중 하나이지 DOM이 HTML은 아닙니다.

예컨대 "text/html" 콘텐츠 유형으로 제공되는 HTML 문서는 HTMLDocument 인터페이스도 구현하는 반면, XML과 SVG 문서는 XMLDocument 인터페이스를 구현합니다.

 

 

<!DOCTYPE html>
<html class=e>
 <head><title>Aliens?</title></head>
 <body>Why yes.</body>
</html>

위의 HTML 코드에서 Document는 아래와 같이 node tree로 표현됩니다.

 

 

 

Node

 

 

 

  • 노드는 다양한 DOM API(Document, Element ... )가 상속되는 인터페이스입니다.(모든 DOM 객체는 Node를 상속)

  • 다음 메소드와 속성들이 Node 인터페이스를 상속합니다. ( Document, Element, Attr, Text, Comment, CDATASection, ProcessingInstruction, DocumentFragment, DocumentType, Notation, Entity, EntityReference 등)

  • 엘리먼트는 Node를 상속받으므로 Node.baseURI, Node.childNodes, Node.nodeType 등 (어떤 카테고리에 속해 있는 노드인지 알려주는 식별자)과 같은 속성을 사용할 수 있습니다.

  • 즉, 문서에는 나와있지 않지만, HTML Document를 구성하는 node tree에서 최상단에 속한 것이 node이고 모든 엘리먼트들은 이 node 인터페이스를 상속받는다고 볼 수 있습니다.

 

 

 

Element

 

 

Element가 Node를 상속함.

Element의 대표적 속성 : attributes, classList, className, clientHeight, id, innerHTML등

 

 

  • 부모의 Node와 그 부모인 EventTarget의 속성을 상속하고 어떤 것들은 직접 구현(implement)합니다.

 

 

HTMLElement

 

HTMLElement은 Element를 상속함.

 

HTMLElement의 대표적 속성 : dataset, innerText, style, Element를 상속한 id 등

 

  • 대표적인 Document 인터페이스 메소드인 getElementById()에 의하여 HTMLElement를 얻을 수 있습니다.
  • 모든 종류의 HTML요소를 나타냅니다. 일부 요소는 이 인터페이스를 직접 구현하지만 나머지 요소는 HTMLElement를 상속한 자식 인터페이스를 구현합니다.

  • 이 요소가 하나 일 경우 HTMLElement이고 복수일경우 HTMLCollection을 반환한다.

 

HTMLCollection

 

  • 일반적으로 document.getElemetsByTag와 같이 복수의 노드를 접근할때 리턴된다. 

  • 유사 배열이다.
  • 가장 큰 특징으로 라이브 컬렉션이다.

  • NodeType을 오로지 ElementNode만 포함한다.

 

 

NodeList

 

  • HTMLCollection과는 다르게 모든 NodeType을 포함한다. 

  • Array는 아니지만 forEach를 사용이 가능하며 Array.from()을 사용하여 Array로도 변환 할 수 있다.
  • document.querySelectorAll은 정적 NodeList를 반환한다.

  • element.childNode는 동적 NodeList(라이브 컬렉션)을 반환한다.
  • 리스트의 항목을 열거할때는 for...in/for each..in을 사용하지말고 for of를 사용하면 NodeList객체를 올바르게 반복합니다.

 

 

 

 

 

 

'Javascript > DOM 관련' 카테고리의 다른 글

img, a 태그의 CORS 문제  (0) 2024.04.23
[JAVASCRIPT] 브라우저 로드 순서  (0) 2019.12.01
[JAVASCRIPT] 스크롤 거리 구하기  (2) 2019.12.01
[JAVASCRIPT] event processing  (0) 2019.12.01

이 문서는 https://webpack.js.org/concepts/loaders/ 를 번역하였습니다.

Loaders

Loader는 import하거나 load한 소스 코드에 적용되는 프론트 엔드 전처리 변환를 제공하는 도구입니다. Loader는 TypeScript와 같은 다른 언어나 data URL로 표현되는 인라인 이미지들을 변환시켜줍니다. 또한 import를 통하여 CSS 파일도 포함시켜 줄 수 있습니다.

Example

Loader를 사용하여 웹팩에게 CSS파일을 불러오거나 TypeScript를 JavsScript로 변환시켜 줄 수 있습니다.
Loader의 설치는 다음과 같습니다.

npm install --save-dev css-loader ts-loader  
( css, typescript 로더 )

웹팩에게 css-loaderts-loader를 이용하여 모든 .css, .ts파일을 변환하라고 설정할 수 있습니다.

webpack.config.js

module.exports = {
  module: {
    rules: [
      { test: /\.css$/, use: 'css-loader' },
      { test: /\.ts$/, use: 'ts-loader' }
    ]
  }
};

Using Loaders

로더를 사용하는 방법에는 세가지가 존재합니다.

  • Configuration (권장): webpack.config.js 파일에 대한 설정.

  • Inline: 각 소스코드에 import 문을 통한 방법.

  • CLI: 스크립트 명령어를 통한 방법.

Configuration 방식

아래의 module.rules 에서 웹팩 설정에서 여러개의 Loader를 지정할 수 있습니다. 이 설정을 통하여 웹팩에 어떠한 모듈이 적용되어 있고 사용되는지 한눈에 파악할 수 있습니다.

Loader는 오른쪽에서 왼쪽(또는 아래에서 위로)으로 평가/실행됩니다. 아래 설정의 경우 sass-loader, css-loader, style-loader의 순서로 실행됩니다.

 

 

 

ERROR in ./src/styles.css
Module build failed (from ./node_modules/css-loader/dist/cjs.js):
CssSyntaxError

(1:1) Unknown word

> 1 | var content = require("!!./styles.css");
    | ^
  2 | 
  3 | if (typeof content === 'string') {

※ style-loader는 css를 DOM에 Inject하는 기능, css-loader는 importurl()등으로 js에서 css를 불러드리는 구문을 해석해주는 기능입니다. 만약 webpack.config.js의 rules의 use순서가 'css-loader','style-loader'일 경우 오른쪽->왼쪽 평가/실행의 webpack특성에 따라 style-loader가 먼저 수행, 즉 css를 import하는 기능이 없는데 style-loader가 먼저 수행되어 build 실패(위의 예)가 됩니다. 그러므로 특성에 맞게 설정(순서)하여야 합니다.

 

 

 

"Loader Features"에서 더 자세한 로더의 특징을 살펴볼 수 있습니다.

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          // style-loader
          { loader: 'style-loader' },
          // css-loader
          {
            loader: 'css-loader',
            options: {
              modules: true
            }
          },
          // sass-loader
          { loader: 'sass-loader' }
        ]
      }
    ]
  }
};

Inline 방식

import구문을 이용하거나 equivalent "importing" method를 통하여 Loader를 지정할 수 있고 !문자로 로더를 분리할 수 있습니다. (각 Loader 부분은 현재 디렉토리를 기준으로 상대 경로입니다.)

import Styles from 'style-loader!css-loader?modules!./styles.css';

또한 모든 preLoader, postLoader등을 !을 이용하여 재정의 할 수 있습니다.

  • ! 를 이용하면 모든 일반 Loader가 제외됩니다.

    import Styles from '!style-loader!css-loader?modules!./styles.css';
  • !!를 이용하면 모든 Loader가 제외됩니다.(preLoaders, loaders, postLoaders)

    import Styles from '!!style-loader!css-loader?modules!./styles.css';
  • -!를 이용하면 postLoader를 제외한 로더들이 제외됩니다.

import Styles from '-!style-loader!css-loader?modules!./styles.css';

이곳에 ?key=value&foo=bar 와 같은 쿼리 파라미터, ?{"key":"value","foo":"bar"} JSON object도 넘겨줄 수 있습니다.

앞서 밝혔듯이 module.rules(Configuration)을 이용하는 것이 보일러 플레이트 감소, 더 빠른 로딩, 편하게 디버깅 할 수 있습니다.

CLI

아래와 같이 CLI을 통하여 Loader를 사용할 수 있습니다.

webpack --module-bind jade-loader --module-bind 'css=style-loader!css-loader'

Loader Features

  • Loader는 체인으로 묶이며, 이 체인은 역순으로 실행됩니다. 첫 번째 로더에 의한 변환된 자원은 그 다음 로더에 전달되는 식입니다. 그리고 마지막 로더에 의하여 JavaScript로 리턴됩니다.

  • Loader는 동기/비동기식으로 실행됩니다.

  • Loader는 Node.js에서 동작하며 Node.js에서 가능한 모든 것을 할 수 있습니다.

  • Loader는 options으로 설정할 수도 있습니다.(deprecated 됐지만 아직 지원하는 query파라미터도 사용가능)

  • Normal module은 package.json을 통해 일반 main외에 loader필드로 loader를 내보낼 수 있습니다.

  • 플러그인은 Loader에게 기능을 추가합니다.

  • Loader는 추가 임의 파일을 내보낼 수 있습니다. can emit additional arbitrary files.

Loader는 전처리 기능을 통하여 output을 사용자 지정하는 방법을 제공합니다. 이로써 사용자는 압축, 패키징, 언어 변환, 잘 다듬어진 로직들을 include하는데 더 유연해집니다.

Resolving Loaders

Loader는 표준 module resolution를 따르고 대부분의 케이스에서는 module path 에서 로드됩니다.

로더 모듈은 Node.js와 호환되는 JavaScript로 작성된 function을 내보내어져야 합니다. 주로 npm을 통하여 관리하지만 사용자 정의 loader를 통하여도 이를 설정할 수 있습니다.

https://github.com/judaihyun/webpack-korean-docs/blob/master/content-ko/concepts/loader.md

 

순수 자바스크립트이며, 지속적으로 추가/확장됩니다.

 

 

기본 기능 설명 ( ES5 )

 

- 테스트 케이스로 설명(아래)

        const testCase = {
            'mysite@ourearth.com': true,
            'my.ownsite@ourearth.org': true,
            'mysite@you.me.net': true,
            'mysite.ourearth.com': false,  // [@ is not present]
            'mysite@.com.my': false,  // [ tld (Top Level domain) can not start with dot "." ]
            '@you.me.net': false,  // [ No character before @ ]
            'mysite123@gmail.b': false,  // [ ".b" is not a valid tld ]
            'mysite@.org.org': false,  // [ tld can not start with dot "." ]
            '.mysite@mysite.org': false,  // [ an email should not be start with "." ]
            'mysite()*@gmail.com': false,  // [ here the regular expression only allows character, digit, underscore, and dash ]
            'mysite..1234@yahoo.com': false,  // [double dots are not allowed]
        }

 

 

실제 코드

function emailValidator(args) {
    var msg = '유효하지 않는 이메일입니다.';
    if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(args)) {
        return true;
    }
    // alert(msg);
    return false;
}

이상 없을 시(성공) : true

이상 있을 시(실패) : false

 


*테스트 *

 

위 콘솔 로그의 각 라인 의미 : 실제 입력된 문자열 : 예상하는 리턴값 => 실제 리턴값

 

 

'Javascript > 코드 모음' 카테고리의 다른 글

[JAVASCRIPT] 전화번호 유효성 검사  (1) 2019.12.09
[JAVASCRIPT] 비밀번호 유효성 검사  (0) 2019.12.09

+ Recent posts