깍돌이

안녕하세요 오늘은 간단하게 짚고 넘어가야 할 리액트 에서 이벤트 핸들링에 특징 이 있어 작성하려고 왔습니다.

SyntheticEvent ( 합성 이벤트 )

onChange={
            (e)=>{
              console.log(e.type);
              console.log(e.target.value);

              setTimeout(()=>{
                console.warn(e.type);
              })
            }
          }

위와같이 코드를 작성 했을 시에 

setTimeout(()=>{

   console.warn(e.type); // null 값이 들어옵니다.

});

해당 이유는 리액트에서의 onChange , onClick 등에 들어오는 event 파라미터는 브라우저에서 사용되고있는 Event 인

https://developer.mozilla.org/ko/docs/Web/API/EventTarget

와는 다른 객체라고 보시면 됩니다.  해당 event 객체는 React 에서 작성한 SyntheticEvent 로 웹 브라우저에 있는 Event 를 이용한 새로운 객체입니다. 그렇기 때문에 위의 비동기 처리시에는 null 값이 되며 해당 경고가 나타납니다.

리액트 공식 홈페이지에서도 해당 부분을 해결하기 위해서는 e.persist 라는 함수를 사용하라고 되어있는데요 사용은 간단합니다.

위의 에러 코드에서 e.persist()를 호출해주면 됩니다.

          onChange={
            (e)=>{
              e.persist();
              console.log(e.type);
              console.log(e.target.value);

              setTimeout(()=>{
                console.warn(e.type);
              })
            }
          }>

 호출시에는 이제 setTimeout에서도 e.type이 노출됩니다.

e.persist를 사용하고 안하고의 차이를 결과로는 알았습니다.

하지만?   동작이 왜이렇게 바뀌는지에 대한 이유는 기본적으로 리액트에서 사용되고있는 SyntheticEvent 는 객체 풀링 방식을 사용합니다. (Object Pooling) 매 이벤트마다 해당 객체 사용되는것에 대해서 성능상의 이유로 리액트에서는 Object Pooling을 사용함으로써 객체 생성 시간을 줄이고 GC에 대한 노출도 줄이며 메모리관리에 소비되는 시간을 줄이는 방식을 사용하고 있기 때문입니다.  그렇기 때문에 객체가 호출되고 난 후에 이벤트 속성이 초기화 됩니다. 

그렇기 때문에 비동기로 호출하였을 경우에는 해당 객체가 비어있는 현상이 발생합니다.

그렇기 때문에 e.persist를 호출하게되면 기존에 사용하고 있던 이벤트 풀 ( Event Pool ) 에서 제거되고 사용자 코드로 사용이 됩니다.

여기까지 간단한 e.persist에 대해서 적어보았습니다. 

그냥 단순히 비동기에서 왜안되지? -> 아 호출시작부에서 e.persist를 쓰면되겠다 보다는

왜 e.persist라는 거를 써서 했을까 왜 Object Pooling을 사용했을까 등을 생각해보고자 작성하였습니다.

감사합니다~

안녕하세요 깍돌이입니다. 오늘은 되게 오랜만에 작성을 하게되네요

기술 포스팅은 아니고 QA를 일하면서 항상 재밌지만 매번 힘든 경우가 있게 되는데요 마음을 다시 잡기 위해서

도 있고 해당 고찰 시리즈(?) 를 작성 하고 몇달뒤에 나는 얼마나 후회했던 점을 많이 수정하고 보완하였는지

판단하고 싶어졌습니다.      

다시 한번 인사드립니다. 안녕하세요 이제 5년차 Software QA 로 일을하고 있는 깍돌이 입니다. 

벌써 올해 5년차가 되었지만 아직도 제 자신이 보기에 부끄러울정도로 부족함이 보입니다.  

6년차 부터는 고연차라고 생각 하고 자기 자신을 다져서 튼튼하게 만들어야 될 것 같습니다.

버그 & 이슈 

QA로 일하면서 즐거운(?) 점도 버그 이지만 완전 정 반대로 힘들어지는 경우도 버그 입니다.(저는 그렇습니다.)

이슈를 찾아서 개발자에게 전달 할 때 가 즐거운 게 아니라 다른 분들이 생각하지 못한 이슈를 찾아 낼 때가 그렇습니다.

이러다 보니 모든 케이스를 열린마인드로 바라보는 것도 좋은 거 같습니다.  그래서 TC를 안쓰고 테스트하는 Ad hoc testing(애드훅) 테스트의 경우에 TC에서는 나오지않던 이슈들이 도출되기도 합니다.

QA가 하는 여러 활동 중 에는 많은 사람들이 대표적으로 알고 있는 테스트 활동이 있습니다.  간단하지만 간단하지 않은 활동이죠 해당 활동들을 간단하게 하지 않기 위함과 그로 인하여 제품의 품질을 높이기 위한 추가 활동들이 수 없이 있습니다.   

Test Case

개인적으로 QA의 자산이라고 생각하며 Test Case가 탄탄해야 제품의 품질 을 끌어올릴수 있다고 생각합니다.

철없을 시절에는 1건이라도 자동화가 우선이지! 라는 착각을 했지만  탄탄한 Test Case가 없다면 자동화도 무의미 합니다. 제대로된 자동화를 하기 위해선 많은 공수가 들기도 하는데 Test Case가 물렁 거린다면 그 이후에 작업들도 다 무용지물이 되는건 한순간입니다.

TestCase는 매우 꼼꼼하게 작성합니다. 말 그대로 자산이고 또 다른 QA (담당하지않은) 가 왔을 때 확인하는 시간은 좀 걸리겠지만 제품에 대한 이해가 조금 부족해도 수행 할수 있도록 작성되어야 합니다.  개발자들 을 예로 들면 주석이 꼼꼼하게 달려 있는거랑 비슷하겠네요

TC가 빈틈없이 작성되어있다면? 물론 빈틈없이 모든 케이스를 작성해서 배포시간내에 테스트가 가능하다면 이보다 더 좋을순 없습니다.  하지만 모든 케이스를 다 넣게 되면 TC의 거대화가 진행되면서 필요없는 TC활동이 생기게 되며 이는 비효율적입니다.  또한 배포의 형태에 따라 TC를 매번 Regression Test (회귀 테스트) 를 진행할수는 없는 노릇입니다. 

QA도 Release Plan (배포계획) 에 따라서 Test Plan ( 테스트 계획 ) 을 작성하는데 이 또한 근거가 되는 것은 Test Case 입니다.  그래서 특정 여러 배포에 따라서 Check List라는 형태로 간소화하여 Major 기능들 위주로 확인할 수 있습니다.

Check List 

매번 Regression Test (회귀 테스트 ) 를 돌릴수 없기 때문에 기본적으로는 Release Plan 에 따른 Test Plan 을 짜야 하지만 때로는 Check List 로 작성하여서 최소한의 리스크로 확인 하는 경우도 있습니다. 해당 제품에 대한 메이저 기능들 (절대로 안되선 안되는 ) 이죠 물론 케이스가 조금 응용됐을 때도 안되는 케이스도 어느정도 고려를 해야합니다. 

개인적으로는 Test Case를 작성하고 -> Check List 형태로 간소화하여 사용하기도 합니다.

반대로 Check List로 만든 후에 Test Case 로 정밀화 하기도 합니다.

고찰

버그에 대한 고찰을 이야기하다가 여기까지 왔었네요. 정기 릴리즈 시기가 와서 배포 대기를 하고 있었습니다.

왠지 모르게 이번 배포는 자꾸 2%가 찜찜 하더군요 

배포 중에 하드한 이슈들도 찾고 잘 처리하여 마무리 를 하였습니다. 하지만 배포후에 이슈가 생겼고 

해당 이슈는 QA를 거친 제품에 대한 이슈였습니다.

아주 특이한 케이스였으면 "와 이런 케이스도 있을 수 있구나"  싶었지만 "특별" 하지만 "특이" 한 이슈는 아니였습니다.

다른 분들은 어떨지 모르겠지만 저는 해당과 같은 상황이 닥쳤을 때가 가장 QA하면서 힘든 상황이였습니다.

어떠한 면에서는 현실이 아니길 기도하기도 했습니다. 하지만 이슈가 발생했던건 현실이였죠.. 

어떤 분들은 "자동화를 해라" 라는 부분에서 스트레스를 받지만 저는 공부하면서 자동화하고 자신의 기술 습득의 향상이 되는 부분이라 하는 만큼 결과도 보여지고 매우 좋아하는 요구사항입니다.

하지만 위와 같이 배포 후 이슈가 1건이라도 발생했을 경우 ( 자잘한 이슈가 아닌 사용성 문제가 있는 ) 에는 QA로써의 책임감에 따라서 정신적으로 많이 힘들었던 기억이 있습니다. 물론 최근에도 비슷한 경험을 하고 멘탈이 조금 씩 나가지만 소 잃고 외양간 고치라는 말처럼 그러다보니 최소한 2번은 절대 발생하지 않겠다 는 생각으로 발생했던 이슈들은 전부 체크리스트에 넣고 시간이 오래걸려도 해당 부분은 추후에 볼수 진행하면서 구멍을 메꾸려고합니다. 

QA는 자기 제품 혹은 자기가 맡은 모듈에 따라서 책임감을 어느정도 가지고 있어야 한다고 생각하고 있습니다.

개발은 개발팀에서 하겠지만 결국 제대로된 상품이 되기위한 Flow 중 QA라는 Flow도 있고 밀접한 관계로 일을하기 때문에 일을하면서 내가 이 제품의 담당자이며 관련자다 라는 책임을 가지고 이슈없는 배포 깔끔한 배포가 이루어질수 있도록 더욱 노력해야 할 것입니다.

예돈돈까스

★★★★★

메뉴 : 생등심 특 돈까스(12,000원) * 1 , 생등심 돈까스(9,000원)

total : 21,000원

후기

          깍돌이 : 가격도 착하고 맛도 맛있고 정자동 경양식은 탑 이라고 생각 

          깍돌이 동생 : 특 시킬까 고민했는데 일반시켜서 다행이다 

특징 

         사진은 특 돈까스이고 청양 고추를 달라고해서 돈까스 위에 뿌려 먹으면 정말 맛있음 

매일식당(Every Day Bistro)

★★★★☆

메뉴 :  수제돈가스 (9,000원) * 4

total : 36,000원

후기

           깍돌이  : 판교 경양식 돈까스 중에는 탑인거 같다 .

           깍돌이 팀원들 : 양이 생각보다 많다~

특징 

         점심시간에 가면 웨이팅이 있을수 있음 12시 전에 가면 없음 12시 10~20분 사이에 가면 2팀~3팀 대기

세이카츠 (せいかつ)

★★★★☆

메뉴 : 로스까스(11,000원) * 4

total : 44,000원

후기

           깍돌이     : 돈살녹~

           깍돌이 권 : 등심으로 만들다 보니 기름이 있는 부분이 호불호가 있을수 있다~

           깍돌이 안 : 두꺼운 고기 살살 녹는다~ 

특징 

         사장님이 혼자 서빙 요리 다하시기 때문에 대기줄이 엄청남  4명이상이면 집에 가라고 하심

네 ! 안녕하세요 최근에 개인적으로 자동화를 Server 쪽에서 진행하다보니 Node.js Express로 많이 짜게 되었는데요

자동화를 하면서 놓쳣던 부분들 ( pm2의 로깅관리, 서버의 주소 노출 등등 ) 의 경험을 다시 덧붙여서 TypeScript & Express 보일러 플레이트를 하루정도 들여서 만들었던 과정을 포스팅하려고합니다.

TS를 설명하는 부분들은 아니니 TS는 건너가고 webpack 에 대한 설명도 어느정도는 건너 서 말씀드리겠습니다.

Node.js

일단 위의 모든 것들을 행하기 위해서는 Node.js를 설치 하여야 합니다.

https://nodejs.org/en/

유명한 사이트죠 현재 포스팅 기준은 Windows에서 하였기 때문에 Windows로 진행 하도록 하겠습니다.

설치 같은 경우는 많이 포스팅하기도했고 검색해도 많이 나오기 때문에 스킵 하도록 하겠습니다.

Node.js가 설치가 완료 되었다면 이제 환경 설정을 할 차례입니다.

Windows PowerShell, CMD, Visual Studio Code 등의 Terminal 에서 내가 작업할 프로젝트 폴더를 만들고 이동합니다.

ex: mkdir network 

     cd network

그 후에 기본적인 npm 세팅을 하도록 합시다.

npm init -y  // npm 기본 세팅 
npm i -D  // devDependencies 참조 
npm i // dependencies 참조 

npm i -D : 개발디펜던시로 devDependencies 를 기준으로 설치 하시면 됩니다.

npm i : 프로젝트 디펜던시로 dependencies 를 기준으로 설치 하시면 됩니다.

** npm i -D typescript @types./axios

    npm i axios 

webpack 에 대해 설명을 제대로 하자면 더 길어질수있어 기존에 작성하였던 webpack 포스팅을 참조 드립니다.

https://ipex.tistory.com/entry/TypeScript-TS-%ED%99%98%EA%B2%BD-%EC%84%A4%EC%A0%95-with-webpack-v4TypeScript-Environment-Configuration-with-webpack-v4

이번 포스팅에서는 webpack 과 typescript + express 구조에 대해서 말씀을 드리려고합니다.

일단 express부터 간단하게 구조를 짜보자면

이와 같은 구조가 일단 만들어집니다.

log - 서버 로깅 폴더

public - static 파일을 serving 하기 위한 공유 폴더

route - express Route 폴더 

views - index.html 등 뷰 템플릿 엔진을 사용하기 위한 폴더

index.ts - express 서버의 진입점 ( 시작점 ) 

폴더 구성 후 tsconfig.json 을 생성 

{

  "compilerOptions": {

    "module": "commonjs",

    "target": "es6",

    "moduleResolution": "node",

    "strict": true,

    "alwaysStrict": true,

    "noImplicitAny": true,

    "allowSyntheticDefaultImports": true,

    "outDir": "dist",

    "listEmittedFiles": true,

  },

  "include": [

    "src/**/*"

  ]

}

src 하위에 있는 ts가 전부 js로 변환됨을 확인하실수 있습니다. outDir에 의해서 dist 폴더로 말이죠

프로젝트/src 구조이기 때문에 outDir은 단순히 dist로만 해도 /프로젝트/dist에 결과 파일이 생성됩니다.

( 폴더 구조 그대로요 )

그래서 사실 저도 여기까진 전혀 문제가 되지 않았습니다.

Express 구조 

src / 

    log

    public

    route

    utils

    views

    index.ts

라는 간단한구조에서 tsc만 돌리면 폴더 구조 그대로 dist에 빼주기 때문에 package.json 에서

npm start 에 tsc후에 node dist로 실행해버리면 ( 트랜스 파일 후 서버까지 실행 ) 

이 정상적으로 되기 때문입니다.    하지만 문제는 public 폴더입니다. 단순하게 테스트용도로 바로 쓸수있는 형태의 페이지를 써야해서 nunjucks라는 Node.js 템플릿 엔진을 사용하는데요

그렇게 되면 public 폴더도 같이 서빙해야됩니다. ( index.html 과 수 많은 js css 등 ) 

그래서 webpack 을 같이 쓰게 되고 webpack + tsc의 콜라보가 발생합니다. ( FE코드와 BE코드의 각각 분리된 컴파일 ) 

FE 코드 트랜스파일링 (webpack)

public폴더와 views폴더만 따로 배포하기 위해서 webpack 을 사용하였습니다.  하지만 

entry :{

 'index':'./src/public/js/index.js' 

}

와 같이 입력하면 dist/index.js 로 빌드가 됩니다.  우리의 FE 코드들은 dist/public/index.js가 되어야 하기 때문입니다.

그래서 entry 를 수정합니다.

entry : {

  'public/index':'./src/public/js/index.js'

}

dist/public/index.js 에 정확하게 번들링되어 결과가 정상적으로 나타납니다.  하지만 여기서 문제가 생깁니다.

views도 같이 뽑아내기위해서  HtmlWebPackPlugin 을 사용하는데요  해당 플러그인을 쓰게되면 자동으로 css와 js들의 태그를 붙여 주게 됩니다.

<link> href="../public/index.css" rel="stylesheet">





<body>
     ....
    <script type="text/javascript"src="../public/index.js"></script>
</body>

이와 같이 말이죠 Express에서 index.html 의 위치는

src

   views

        index.html 

입니다. 그렇기 때문에 해당 js와 css의 접근을 위해서는 ../public 으로 접근을 해야 합니다.

src

   views

       index.html

   public

       index.js

       index.css

여기까진 전혀 문제가 없어 보이지만 큰 문제가 하나있습니다.

app.use(express.static(path.join(__dirname, "public")));

express에서는 static 파일을 서빙하기 위해서 public폴더를 지정하였는데요 

../public이 되어버리면  해당 파일들이 서빙이 되지 않습니다. ( send.render 시에 404 not found가 발생 ) 

그래서 해당 방법을 위해서 

webpack output 에 publicPath 를 이용합니다.

 output:{
       publicPath:'',
       path:path.join(__dirname,'./dist'),
       filename: '[name].js'
    }, // 결과 파일

이와같이 변경하게 되면 ../public은 사라지지만 /public  이 남습니다.

express.static으로 public이 이미 지정되어있기 때문에 /public/index.css가 아니라 index.css가 되어야합니다.

그리고 webpack 에서 또한 리소스 파일들 ( 폰트 이미지 등)도 같이 dist로 나가야 하는 상황입니다. 

현재 문제점

expres는 public 폴더를 static으로 쓰고있는 상황이여서 파일 경로가

public/index.css 라면

index.css 로 요청을 해야 express내부적으로 public/index.css로 요청을 하게 되지만

webpack 옵션으로 인해 /public/index.css로 요청하게 되어 express에서는

public/public/index.css를 찾게 되는 현상이 발생 

해당 현상을 해결하기전에 아래와같이 필요한 파일들을 이동하였습니다.

[ 파비콘 index.html 등 리소스 파일 이동 ] 

 plugins:[
        
        new HtmlWebPackPlugin({
            template:'./src/views/index.html',
            filename:'./views/index.html',
            showErrors:true
        }),
        new MiniCssExtractPlugin({
            filename:'[name].css',
            chunkFilename:'[id].css'
        }),
        new CopyWebpackPlugin([
            {
                context:'./src/public/resource/',
                from:'**/*',
                to:'./resource'
            },
            {
                from:'./src/views/favicon.ico',
                to:'./'
            },
        ])
    ],

const CopyWebpackPlugin = require('copy-webpack-plugin'); 을 이용 했습니다. context : 루트 위치고 from 에서 to로 이동합니다.  

** 유의 할점은 번들링하기전에 파일들을 이동하는 거 이기 때문에 webpack 번들링과 연관되지않습니다. ( 그래서 플러그인이기도하지요)

그리고 해당 경로를 해결하기 위해서 생각을 해보았습니다. ts는 

/dist

   /express구조

 로 만들어 냅니다.

webpack 을 똑같이 사용하기엔 express에서는 webpack 에서 번들링되는 부분들은 public 에서만 쓰면 됩니다.

위와같이 entry 이름을 'public/index' 로 해버리면 public 경로가 잡혀버려서 경로 문제가 생기기 때문에

entry 는 다시 index 로 변경합니다.

그렇게 되면 

dist/

   index.css 로 생성되는데

  output:{
       publicPath:'',
       path:path.join(__dirname,'./dist/public'),
       filename: '[name].js'
    }, // 결과 파일

path 경로를 dist/public으로 잡으면 됩니다. 

그렇게 되면

dist/public/

            index.css

            index.js 등 으로 나타나게 됩니다.

그리고 나선 express 에서의 코드를 간단하게 수정합니다.

nunjucks.configure('views');  -> nunjucks.configure('dist/public/views')

    nunjucks.configure('dist/public/views',{
      autoescape:true,
      express:this.app
    });
    
    this.app.use(express.static(path.join(__dirname,"public")));
    this.app.use(favicon(path.join(__dirname,"/public/resource/fav","favicon.ico")));

** 혹시 의아 하실수 있습니다. dist에서 app.js가 실행되는데 왜 ./public/views 가 아니라 dist인지

configure에서 path 는 current working directory 이기 때문에  root/dist/public/views 로 되어집니다.

1. express template -> 경로 수정 

2. favicon ( express 에서 faviocn 을 미리 response하기 위해서 serve-favicon 이라는 모듈을 사용) 경로 변경

3. webpack config 수정 

const path = require('path');
const HtmlWebPackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
    target:"node",
    devServer:{
        contentBase:path.resolve(__dirname,'/src'),
        disableHostCheck:true,
        host:'0.0.0.0'
    },
    name:'network',
    mode:'development', // "production" | "development" | "none"
    devtool:'eval',  // source-map   hidden-source-map
    resolve:{
        modules:['node_modules'],
        extensions:['.scss','.css','.js'],
        alias:{
            "@gdlUtils":path.resolve(__dirname,'src/gdlUtils'),
            "@userCSS":path.resolve(__dirname,'src/public/css'),
            "@res":path.resolve(__dirname,'src/public/resource'),
            'public':path.join(__dirname,'public')
        }
    },
    entry:{
        'index':'./src/public/js/index.js'
  
    }, 
    module: {
    rules: [
  
      {
        test:/\.html$/, // html loader
        use:[
            {
                loader:'html-loader',
                options:{minimize:false}
            }
        ]
      },
  
       {
          test:/\.css$/i,
          use:[
              {
                loader:MiniCssExtractPlugin.loader,
              },
             'css-loader'
          ],
          
       },
      {
          test: /\.(png|jpg|jpeg|gif|svg|woff|woff2|ttf|eot)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
          use:{
              loader:'url-loader',
              options:{
                  name:'[path][hash].[ext]',
                  limit:10*1024 // 10kb
              }
          }
      },
      {
        test: /\.ico$/,
        loader: 'file-loader'
     }
        
           
    ]
    }, 
    
    plugins:[
        
        new HtmlWebPackPlugin({
            template:'./src/views/index.html',
            filename:'./views/index.html',
            showErrors:true
        }),
        new MiniCssExtractPlugin({
            filename:'[name].css',
            chunkFilename:'[id].css'
        }),
        new CopyWebpackPlugin([
            {
                context:'./src/public/resource/',
                from:'**/*',
                to:'./resource'
            },
        ])
    ],
    optimization:{},
    output:{
       publicPath:'',
       path:path.join(__dirname,'./dist/public'),
       filename: '[name].js'
    }, 
  }

4. 환경에 맞게 pakcage.json 수정 ( scripts 부분만 )

  "scripts": {
    "build": "webpack -p",
    "nms-dev": "webpack && tsc && node dist",
    "dev": "nodemon --exec npm run nms-dev",
    "restart": "pm2 restart 'NMS'",
    "deploy": "webpack && tsc && pm2 start dist --name 'NMS'",
    "stop": "pm2 stop 'NMS'",
    "delete": "pm2 delete 'NMS'",
    "log": "pm2 log 'NMS'",
    "abcde": "tsc && node dist",
    "be-dev": "nodemon --exec npm run abcde",
    "tsc": "tsc",
    "f": "pm2 stop 'NMS' && pm2 delete 'NMS'",
    "webpack": "webpack"
  },

network 경로 위치에서 npm run nms-dev 라고 입력 해봅시다

[결과 화면]

이로써 기본적인 대쉬보드를 만들기 위한 아주 최소한의 기본작어빙 완료 되었습니다.

앞으로 해야할건 nunjucks를 통한 템플릿 화 + 자동화된 케이스 및 코드 작성 연결

nunjucks를 -> SPA FE로 포팅 정도가 있겠네요

(이번에는 너무많이 작업해놔서 포스팅을 못할정도가 되지 않길 )

긴글 읽어주셔서 감사합니다~

질문은 언제나 환영합니다.

소스코드 : 

https://github.com/lgance/network/commits/master

의 Commit 13499cfa87c1aab7c4506bf54b561ba4090f6937 을 찾으시면 됩니다.

커밋 메시지는 typeScript & express boilerplate 입니다. 

감사합니다. ~

안녕하세요 모두들 새해복 많이 받으세요

지금은 아니지만 예전에 맡았던 제품중에 SPA Web IDE 제품을 맡은적이 있었습니다.

해당 제품을 맡게되면 품질도 검증하지만 실제 페이지 개발을 많이 하게되는데 이부분에서 기본기 및 Native 스킬들에 

대해서 많은 공부를 하게되었고 혼자하다보니 독학으로는 쉽지 않았던 부분들이 있어서 많은 시간을 들여서 공부던 기

억이 누군가를 도와줄수 있으면 좋겠다 정확한 지식을 전달해주고싶다라는 마음이 있어서 커뮤니티들을 돌아다니면서

질문도 하지만 답변도 해주는 식의 활동들을 하면서 내가 이해했던 부분들을 글로 작성하려니 제대로 이해를 해야

작성할수 있구나 라는걸을 느끼게 되면서 티스토리 블로그도 작성하게 되었습니다. 

그러던 와중에 마주치게된 NAVER Boost Course !

네이버 메인에서 발견한 NAVER Boost Course 의 리뷰어가 된다면 리뷰어가 되기까지 2달간의 테스트를 거칩니다.

                  프로젝트 테스트 -> 프로젝트를 리뷰하는 리뷰 품질 테스트 

두 달간의 테스트를 거친 후에 리뷰어로 발탁이 될수있기에 정말 좋은 기회라고 생각이 되어서 지원을 하게 되었고

2019년도 에 수강생들의 코드를 리뷰 하면서 활동했던거 같습니다. (상반기에만 너무 집중적으로 ㅜㅜ... 하반기엔 거의 못했네요)

리뷰어로 활동을 하면 소정의 활동비가 지급되지만 활동비가 목적은 아니였기에 1명의 수강생의 리뷰를 할때는 개인적

으로는 하루 날을 잡고 했던거 같습니다. (유료로 코드 리뷰를 신청한 수강생에게 실망감을 주고 싶지 않았습니다.)

코드를 리뷰하면서 알고있던 지식도 다시한번 조사해보고 평소에도 더 좋은 기본기와 코드를 알려줄수 없을까 이곳저곳 자료 조사도 하고 코드도 짜보고 트렌드 조사도 했던거 같습니다.

2019년 하반기에는 개인적 인 변화가 있었는데요 "이직" 을 하게되었습니다.  코드리뷰의 경우 높은 코드리뷰 품질을 

드리고싶어 하루를 사용했었는데 하반기에는 개인적인 공부를 하게되어  하루를 쓸시간이 없었던거 같습니다. (아마 하루는 있었겠지만)

그대로 1년의 활동이 지나 2020년이 되었고 퇴근 후 집에 도착해보니

커넥트 운영진에서 작은 선물을 보내왔었네요!

랑 텀블러가 왔습니다. 처음으로 노트북에 스티커를 붙여보네요 ㅎㅎㅎ

커넥트 운영진 들 2019년도 동안 감사했습니다. 

ICST(International Conference on Software Testing Verification and Validation) 2010 발표

구글의 개발 단계별 결함 수정에 들어간 비용 에 대해서 작성한 자료를 보면

개발자가 테스트 주도 개발(Test Driven Development, TDD) 과정에서 결함을 발견시 5달러의 비용을 줄일수 있지만 QA단계인 시스템 테스트 과정에서 발생한 결함의 경우 5,000달러의 품질 비용을 줄일수 있다는 것 

이런것을 보면 적용시기가 문제이지 품질에 시스템을 적용하는건 비용의 문제가 아님을 보여주는 계기가 된다.

잔존 결함 밀도, 코딩표준 준수율, 코드 리뷰 수행률, 중복 코드, 코드 복잡도 

feat. NHN 은 이렇게 한다 !  소프트웨어 품질관리 

계속 추가 예정

브라우저 테스트 스택

https://www.browserstack.com/docs/automate/selenium

쉽게 정규식 을 배워 보자 

https://github.com/ziishaned/learn-regex/blob/master/translations/README-ko.md

프론트엔드 마스터를 하기위한 9개 프로젝트

https://blog.naver.com/bkcaller/221712728455

훌륭한 프로그래머가 되기 위한 앱 8 선

https://tagilog.tistory.com/579?fbclid=IwAR3VNuZqDucGJ-EFrIH8XKvstuPIgF_XvfylLo4TPD5xIRLYc-UaN2CP2-c

Git 배우기 

https://learngitbranching.js.org/?locale=ko

CSS flex 

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

http://www.beautifulcss.com/archives/2812 

하위 브라우저에서 flex를 잘 사용하는 방법

https://css-tricks.com/using-flexbox/

무료 파비콘 제공 사이트

https://www.iconfinder.com/icon-sets/featured/free/5

파비콘 컨버트 사이트

https://converticon.com/

Concurrent Connection Test  일명 CC Test 라고 불리우는 TCP 같은 연결에 동시성 테스트를 해야 할 경우

에 JMeter를 간단하게 사용한 후기입니다.

Apache JMeter 

JMeter의 경우 부하테스트 기능과 성능을 측정하기 위해 디자인된 100% 순수 자바 애플리케이션이라고 소개 되었습니다. 

실제로 실행해서 보면 java 를 CLI 형태로 실행 하는 모습을 확인 할수 있습니다.

JMeter에 대해서는 한번 자세히 따로 포스팅 하도록 하겠습니다. (테스트 쪽에)

이번에는 설치 과정은 제외하고 작성 하겠습니다. 간단한 활동이기도 했고

https://jmeter.apache.org/download_jmeter.cgi

여기서 다운받고 설치 하면 끝! 입니다.

Thead Group 

처음에 설치 후 실행하게되면 TestPlan 이존재할텐데요 일단 Test Group 을 우릭으로 생성 해줍니다.

HTTP Request 설정 

해당 TestGroup 에서 Http Request를 생성합니다. 해당 작업에서는 내가 어디 서버로 부하를 줄지 에 대한 

Thead Group 설정

해당 설정에서는 유저의 수를 정할수 있습니다.

Number of Thread(users) : 유저수를 정하며 100으로정하게 되면 100개의 쓰레드로 실행하기 때문에 동시성이 가능합니다.( 저는 3000으로 했습니다. - 컴퓨터가 날아갑니다.)

Ramp-up period ( inseconds) : 준비시간을 의미합니다. 

Loop Count : 위에 HTTP request를 해당 유저들이 몇번씩 할건지에 대한 이야기입니다.

                  A URL로 3000인 상황에서 10이면 ( 3천명이 10번씩 -> 3만번 호출) 이 될수있겠네요

Thead Group Listener 

어떻게 보면 매우 중요한 부분입니다. 해당 위의 테스트 한 내용에 대한 결과를 보는 부분인데요

이중에서 제가 자주 쓰는 2가지만 일단 간단하게 소개하겠습니다.

View Result Tree

Http 가 호출을 했을 때의 결과를 Result Tree로 보여줍니다.

아래와같이 성공한경우는 초록색 실패한 경우는 빨갛게 나오며 클릭시 해당 내용을 확인하실수 있습니다.

Summary Report

많은 호출개수와 에러율 쓰루풋 정도가 확인되는데요 간단하게 요약 형태로 나오는거라 자주 애용합니다.

여기까지 정말 간단하게 JMeter를 알아 보았는데 사실 JMeter는 엑셀을 가지고 연동하여서 쓰는 방법도 많고 

활용방안이 무궁무진합니다. 해당을 이용하여서 업무에 적용시마다 하나하나 소개할 예정입니다. 

감사합니다.

** 제 가 사용하는 PC가 dell XPS 8930 을 사용하는데 3000명이 1000번 호출은 PC가 못버팁니다. 

1000명이 1000번 호출은 간신히 버팁니다. 사용하시는 분들은 참고하세요~