윈도우 컴포저 패키지 설치시 오류 처리 방법

Your requirements could not be resolved to an installable set of packages.

1
2
3
4
5
6
7
Your requirements could not be resolved to an installable set of packages.

Problem 1
- laravel/horizon v4.2.1 requires ext-pcntl * -> the requested PHP extension pcntl is missing from your system.
- laravel/horizon v4.2.0 requires ext-pcntl * -> the requested PHP extension pcntl is missing from your system.
- laravel/horizon 4.x-dev requires ext-pcntl * -> the requested PHP extension pcntl is missing from your system.
- Installation request for laravel/horizon ^4.2 -> satisfiable by laravel/horizon[4.x-dev, v4.2.0, v4.2.1].

Laravel Horizon을 windows에서 설치하려 할 때 위와 같은 오류가 발생하였습니다.

해결방안

pcntl은 윈도우에서 지원이 되지 않으므로 Docker 또는 Vargrant와 같은 가상환경을 사용해야 합니다.
Link

또는 아래와 같이 실행하여 설치를 완료 할 수 있습니다.

1
composer require laravel/horizon --ignore-platform-reqs

--ignore-platform-reqs 옵션의 설명은
해당 링크에서 확인할 수 있습니다. Link

1
ignore php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.

패키지를 설치하는데 필요한 조건을 충족하지 못하더라도 무시하고 설치를 실행하는 옵션입니다.

필요 조건을 모두 충족하지 않은 경우이므로 정상동작에 실패 할 수 있습니다.

[Git] 원격 브랜치명으로 새로운 브랜치 생성하기

주로 PHPStorm 같은 IDE 나 VSCode 같은 Extension이 잘 되어 있는 에디터를 사용하고,

그 이전에는 Source Tree / Git Kraken / Fork 등 Git Client 를 사용하여 Git을 사용하기 때문에,

아직 CLI로 Git을 유연하게 다루지 못해 git-scm 문서의 내용을 정리 합니다.

명령어 정리

원격 브랜치명과 같은 이름으로 생성할 때

1
$ git checkout --track origin/master

해당 브랜치명이 리모트에만 있고, 로컬에는 없을 때 이를 축약하여 아래와 같이 실행할 수 있다.

1
$ git checkout master

원격 브랜치명과 다른 이름으로 생성할 때

가장 많이 쓰이는 경우인데, 원격 Git 서버의 master 브랜치를 기준으로 새로운 브랜치를 만들고, 체크아웃 할 때 사용합니다.

1
$ git checkout -b my-new-branch-name origin/master

위와 같이 실행하면 origin/master를 트래킹 하게 되는데,

다른 브랜치를 추적하기 위해 아래와 같이 실행할 수 있습니다.

1
$ git branch -u origin/feature-test

참고자료

Git 브랜치 - 리모트 브랜치

[Git] Git Merge 또는 Git checkout 오류 해결하기

문제 상황

git pull origin master 또는 git checkout master 와 같이 브랜치를 변경하거나, 원격저장소에서 pull을 받을때
아래와 같은 오류가 나온적 경험이 한번쯤은 있을것 입니다.


1
2
3
4
error: Your local changes to the following files would be overwritten by checkout:
themes/icarus/layout/widget/recent_posts.ejs
Please commit your changes or stash them before you switch branches.
Aborting

error: Your local changes to the following files would be overwritten by merge:

error: Your local changes to the following files would be overwritten by checkout:

위와 같은 오류와 함께 pull이나 checkout이 동작하지 않습니다.

처음 Git을 사용하였을때는 집과 회사를 오가면서 깃허브를 이용해서 push도 하고 pull도 하고 잘 사용하다가

이런 오류가 나오면 어떻게 해야할지 모르겠고, 커밋을 해야하는것 같은데

무의미한 커밋을 하고 싶지는 않아서 다른 폴더로 clone을 하고 다시 작업을 했었는데요.

해결 방법


에러 메세지를 자세히 보면 해결 방법이 나와있습니다.

Please commit your changes or stash them before you merge. 그리고

Please commit your changes or stash them before you switch branches. 라는 문구가 있습니다.

메세지 그대로 merge 또는 switch branch 이전에 변경사항을 commit 하거나 stash 하라고 합니다.

위에서도 말했지만 저는 쓸데 없는 커밋을 하고싶지 않아 방법을 모르고 새 프로젝트를 실행했지만

이때는 git stash 명령어를 사용하면 됩니다.

stash는 간단하게 버전관리 되는 대상들을 잠시동안 임시저장 해두는 방법이라고 말할 수 있습니다.

그래서 어떻게 하라는건가요?


위와 같은 상황에서는 아래와 같이 사용하면 됩니다.

1
2
3
4
5
6
# 현재 Staging 영역에 있는 파일의 변경사항을 스택에 넣어둡니다. 
$ git stash
# 아래 명령어와 같이 원격 저장소의 master에서 pull을 하거나, git checkout master와 같이 브랜치를 바꿀 수 있습니다.
$ git pull origin master
# stash 명령어로 스택에 넣어둔 변경 사항을 적용하고, 스택에서 제거하여줍니다.
$ git stash pop

간단하게 한줄로 표현하면 git stash && git pull origin master && git stash pop 와 같이 사용할 수 있습니다.

참고자료

git stash에 대한 자세한 사용법은 해당 링크에서 확인할 수 있습니다.

[AWS] S3 호스팅에 도메인 연결하기

S3에서 정적 웹호스팅을 할 수 있다는 이야기는 들어 보았지만, 아직까지 해 볼 경험이 없었는데
지인 덕분에 간만에 재밌는걸 해봐서 잊지 않으려고 기록합니다.

이미 많은 포스팅들도 있고, 공식 가이드 문서도 충분히 잘 정리 되어 있으니 참고 하시기 바랍니다.

도메인은 이미 구매하였다는 가정하에 진행합니다.
이 포스팅에서 사용할 도메인은 [travelerapp.kr](http://travelerapp.kr) 입니다.(곧 만료 예정)

S3 설정하기


  1. 우선 별 다른 설정없이 s3 버킷을 생성하여줍니다.
    이때 주의할점은 버킷명을 호스팅 하고자 하는 도메인과 일치시켜 주어야 합니다.

    버킷 생성하기

    또한 권한 설정시 퍼블릭 액세스를 꼭 체크 해제 해주어야 합니다.

    버킷 생성하기(권한 설정) - 퍼블릭 액세스 체크해제

  2. 버킷이 생성되면 호스팅 하고자 하는 파일을 업로드하여줍니다.
    호스팅시 누구나 접근 가능하게 하기때문에 퍼블릭 액세스를 허용 해야합니다.

    파일 업로드시 퍼블릭 액세스로 변경

  3. 그 후 속성 → 정적 웹 사이트 호스팅 메뉴에 들어가서
    인덱스 문서(메인 페이지), 오류 문서(404 등 오류가 발생했을때 노출 할 페이지) 2가지를 설정하여줍니다.

    정적 웹호스팅 설정

    저는 아래와 같이 main.html과 error.html으로 설정했습니다.
    저장 후 빨간색 박스 안에 있는 엔드포인트에 본인이 설정한 페이지가 정상적으로 노출되는지 확인합니다.

    정적 웹호스팅 설정 - 엔드포인트 확인

    또한 /detail.html 과 같이 존재하지 않는 페이지를 조회하였을때에 오류 문서로 설정한 페이지가 정상적으로 노출되는지도 확인합니다.

  4. 마지막으로 버킷의 정책을 설정하여 줍니다.

    해당 리소스 하위 경로에 대한 조회 권한을 설정하는것으로, 아래의 빨간 박스 내용이 자신이 설정하려는 도메인과 동일해야합니다.

    버킷 정책 편집 - 편집기 안의 빨간 박스의 내용을 본인의 도메인으로 설정

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    {
    "Version": "2012-10-17",
    "Id": "Policy1579004958999",
    "Statement": [
    {
    "Sid": "Stmt1579004957334",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::static.travelerapp.kr/*"
    }
    ]
    }

이것으로 S3에 대한 설정은 끝입니다.

Route53 설정하기


2019년 하반기 회고

상반기 회고 당시에는 하반기에는 분기별 회고를 해서 더 잘 정리해야겠다 생각했는데,
하반기 회고 조차 늦어지게 되었습니다.

💼 회사


새 회사로 이직을 하게 되면서, 인수인계 기간이 지난 후 약 3주정도 휴가를 즐겼습니다.

여행도 다녀오고, 쉬는 기간동안 카페 투어도 하고 이곳 저곳 돌아다녔지만 생각보다 생산성 있는 휴가는 아니여서
아직 아쉬움이 남아있습니다.

새 회사로 오게되어 회사에 적응하는 시간을 보내고 실무에 투입되었습니다.
이정도 규모의 회사에서는 어떻게 서비스를 하고 있고, 현재 서비스에서 어떤 문제를 가지고 있어서 그것을 해결하기 위해 어떤 고민을 하고 있는지, 앞으로 어떤 계획이 있는지 등을 어깨넘어 보면서 새로운것들을 알아가고 있습니다.
생각보다 많은 일들이 동시에 빠르게 진행 되고 있으면서도 아쉬움이 느껴졌습니다.

무엇보다 업무적 문서화가 아닌 공유 목적의 개인적인 문서화와 일정 관리 체계가 이렇게 잘 되어 있는 기업에서 일해본 경험이 처음이라 이러한 부분은 너무 만족스럽습니다.

최근에 스타트업에서 성장한다는 주니어의 착각 이라는 포스팅을 접하게 되었습니다.
해당 글을 보며 과연 이전 회사에서 내가 느끼고 있었던 나는 이곳과 함께 빠르게 성장하고 있다 라는 생각이 어찌보면 혼자만의 착각이 아니였을까 다시 한번 돌아보는 기회를 준 고마운 글이었습니다.

지금은 스타트업에서 근무할때 처럼 기존의 것이 문제가 된다면 새로운걸 빠르게 도입하고 결과물을 확인하고 기존의 것은 대체 할 수 있는것은 아니지만,

오히려 많은 사람들이 쓰고 있는 솔루션에서 호환성 유지를 위해 문제 없이 기능을 개선하면서도

과연 최적의 방법일까 다시 한 번 더 고민해보면서 얻고 있는 이점들이 있습니다.

📒 블로그


블로그 배포 방식 변경

상반기에는 Travis CI로 블로그를 배포하도록 변경하였는데, Github Actions 신청이 가능해지면서 배포 방식을 Github Actions로 옮겼습니다.

Travis CI에서 Private Repo Free 제한이 Codeship 서비스와 동일하게 월 100회인줄 알았으나, 토탈 100회인것을 알고 시간여유가 있을때 빠르게 옮겨야겠다 싶었습니다.

코드는 이전과 동일하게 Dropbox에서 동기화 하면서도 Github Private Repo로 형상관리 하고있습니다.

해당 내용은 Github Actions를 이용하여 Hexo 블로그 배포하기 에 포스팅 되어있습니다만,
허원철님의 Github Actions 를 사용하는게 더 빠르게 설정하기 좋은것 같습니다.

TIL Repo 생성

새로 알게 된 것들, 오류를 해결한 경험 등을 블로그에 포스팅해서 한글로 공유하고 싶었으나,
오히려 포스팅이다보니 어느정도 갖춰 작성하려는것에 대한 부담감으로 작성을 미루게 되는 문제점이 발생했습니다.

이를 해결하고자 기존에 Notion에 간단하게 정리하거나 가볍게 정리할 내용을
TIL 레포지토리 에 작성하고 있습니다.

🏃 일상


💪 운동

상반기에 잠시나마 운동을 시작 했는데, 퇴사 시기와 맞물리게 헬스장도 끝나서 아직까지 운동을 안하고 있습니다.

운동을 할 때는 운동을 해도 왜 이렇게 체력은 늘지 않고 피곤할까 하며 몰랐는데,
안 하면서 저질 체력을 더 크게 느끼고 있습니다….

이동욱님의 하반기 회고록 포스팅을 보며 자극되는점이 너무 많았고,
더 오래 오래 지금 하고 있는 일을 하기 위해서는 건강이 제일 우선이기때문에 상반기에는 다시 운동을 시작해야겠습니다.

신년 계획


1일 1커밋

12월즈음부터 1일 1커밋을 진행하고 있는데, 이걸로 얻을 수 있는 장점은 잠시나마 커밋을 하기 위해 시간을 내고 있다는것었습니다.

하지만 한달쯤 진행 해 보았는데 이것을 깨뜨리지 않기 위해 오히려 의미없는 커밋을 하고 있는건 아닌가라는 것을 고민하게 되었습니다.

그래도 이것을 이어가기 위해서 무언가 정리하고 공부하게 된다 라는점은 이점으로 자리잡고 있어,
상반기에는 지속하는게 목표이긴하나, 이것때문에 무언가를 포기한다거나 하는식으로 너무 얽매이지는 않도록 해야겠습니다.

프로젝트

매번 흐지부지 되는 프로젝트가 너무 많아서 그저 강의를 따라해서 만들어낸 결과물이 아닌,
혼자서 무언가 만들어낸 결과물이 나올 수 있는 프로젝트를 진행하는게 목표입니다.

진행할 아이템은 많으나 가볍게 시작해서 빠르게 결과물을 내어볼 수 있는게 이중에 무엇일지 생각해보고,
만들어보고싶습니다.

운동

자극제

남들과 나 자신을 비교하는 제 성격이 장점은 아니나, 이 부분을 자극제로 사용할 수 있는 방향으로 긍정적으로 활용 해왔습니다.
그리고 감사하게도 항상 제 가까이에 제가 자극이 될 수 있는 좋은분들이 계셔주셔서 지금의 제가 있을 수 있지 않았을까 생각합니다.

이동욱 개발자님유튜브에서 진행하여 주신 인터뷰회고록 등을 보며 더 열심히, 그리고 꾸준히 해야겠다는 자극을 얻을 수 있었습니다.
특히나 더 오래 하고 싶어서 본인에게 투자하신다는 부분에서는 뭔가 대단하시다고 느껴졌습니다.

하지만 다른사람이 편한 신발이 내게도 편할 수 없는것처럼 곧이 곧대로 따라하는게 아니라
저에게 맞는 방식을 찾아서 제게 좋은 자극이 되어주시는 분들과 같이 꾸준히, 그리고 열심히 해야겠습니다.

일정관리

내가 해오던 것, 해야할 것, 하고싶은것과 개인적인 캘린더 일정 들을 이곳 저곳에 따로 정리하다보니
매번 내가 지금 무엇을 해야할지 무엇을 하기로 했는지를 잊는 경우가 많습니다.

회사 다이어리(미팅 내용정리 및 공유 내용 정리와 일정 기입), Notion(개인적인 일정 또는 내용 정리), 캘린더 앱, 카카오톡 캘린더 등을 모두 따로 관리 하는게 필요한 것만 볼 수 있다는 장점이 있지만,
오늘 무엇을 하기로 했지? 라는 생각이 들 때는 모든것을 들여다 보아야한다는 단점을 요즘들어 느끼고 있습니다.

또한 개인적으로 무언가를 진행해야하고 진행할것이다 라는것이 주어지면 큰 틀만 잡고 잘게 나누지 않아,
기한이 없어 계속 진행이 늘어지는 문제가 있어서 개인적인 일정도 기한을 정하는게 좋을 것 같습니다.

독서

원래부터 책을 가까이 하지 않았었고 책을 읽을 시간이 있다면 관심 있는 기술 서적을 더 많이 읽는 편인데,
정리되지 않은 상태로 말을 하고 글을 적는것을 고치는데 도움이 되지 않을까 싶어
두달에 한권정도는 업무 외의 책을 읽을 수 있지 않을까 생각하고 있습니다.

[PHP] InvalidArgumentException : Unable to locate factory with name [default]

발단

Laravel Framework로 TDD를 진행중에 Unit Test를 하기 위해 artisan 콘솔을 이용하여 TaskTest 라는 이름의 테스트 클래스를 생성하였습니다.

1
$ php artisan make:test TaskTest --unit

코드는 간단했습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21


namespace Tests\Unit;

use App\Project;
use Illuminate\Foundation\Testing\RefreshDatabase;
use PHPUnit\Framework\TestCase;

class TaskTest extends TestCase
{
use RefreshDatabase;

/**
* @test
*/
public function it_belongs_to_a_project()
{
$task = factory('App\Task')->create();
$this->assertInstanceOf(Project::class, $task->project);
}
}

해당 테스트를 생성 후 아래와 같이 PHPUnit으로 해당 테스트를 실행하였더니

1
$ ./vendor/bin/phpunit --filter it_belongs_to_a_project

아래 이미지와 같은 에러가 나왔습니다.

InvalidArgumentException : Unable to locate factory with name [default] [App\Task]

과연 무엇이 문제일까 싶어 해당 모델의 migration이 제대로 안된걸까요?

[JS]Document.ready 의 대안

jQuery를 사용할 때, DOM이 로드된 후 처리를 위해 아래와 같은 구문을 많이 사용해왔습니다.

1
2
3
4
5
6
7
8
9
$(function(){

});

// or

$(document).ready(function(){

});

이와 같은 동작을 jQuery 없이 사용 할 수 없을까 찾아 보았는데,

1
2
3
document.addEventListener('DOMContentLoaded', () => {

})

위와 같이 작성하면 됩니다.

DOMContentLoaded는 최초로 HTML 문서가 완전히 로드 및 파싱 되었을때 발생되므로,

모든 리소스(이미지, 스크립트, 스타일 시트 등)가 로드 된 후 발생하는 load 이벤트 보다는 먼저 호출됩니다.

그렇다면 왜 DOMContentLoaded 이벤트 리스너 대신 $(document).ready()를 사용했을까 알아 보았는데,

CAN-I-USE-DOMContentLoaded를 확인하였더니, IE8까지는 지원을 하지 않았습니다.

물론 jQuery가 아닌 대안들도 있었겠지만, 브라우저 호환성을 위해 jQuery를 써오던 입장에서는 간단하게 사용할 수 있던 방안이었으리라고 봅니다.

참고자료

[JS]jQuery 두번째 파라미터가 뭐지?

jQuery로 작성된 코드를 보는데, $("selectorA", "selectorB") 와 같은 코드가 있었습니다.

당연히 기존에 자주 접하던 $("selectorA, selectorB") 와 같은 코드인줄 알았으나, 예상과 다르게 동작하여 문서를 확인해 보았습니다.

jQuery 문서에 따르면, A DOM Element, Document, or jQuery to use as context 가 기재되어있다.

해당 영역에는 DOM element가 올 수 있는데 Selector Context를 확인해보면

selector context is implemented with the .find() method, so $( “span”, this ) is equivalent to $( this ).find( “span” ).

이와 같이 말하고 있습니다.

jQuery .find() vs. context selector 해당 링크에서 퍼포먼스 확인을 해보면
아래 이미지와 같이 context selector를 사용 하는 것 보다, 아주 조금이나마 더 빠릅니다.

[Java]Spring REST Docs HTML이 생성되지 않을때

백기선님의 스프링부트 강좌를 수강하는중에 Spring REST Docs를 이용하여 HTML을 생성하려하는데,

아무리 빌드를 해도 ascii\html\index.html이 생성되지 않았습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
오후 11:58:18: Executing task 'build'...

> Task :compileJava
> Task :processResources
> Task :classes
> Task :compileTestJava
> Task :processTestResources NO-SOURCE
> Task :testClasses

> Task :test
2019-12-02 23:58:35.629 INFO 24376 --- [ Thread-5] o.s.s.concurrent.ThreadPoolTaskExecutor : Shutting down ExecutorService 'applicationTaskExecutor'
2019-12-02 23:58:35.629 INFO 24376 --- [ Thread-7] o.s.s.concurrent.ThreadPoolTaskExecutor : Shutting down ExecutorService 'applicationTaskExecutor'
2019-12-02 23:58:35.630 INFO 24376 --- [ Thread-7] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2019-12-02 23:58:35.630 INFO 24376 --- [ Thread-5] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2019-12-02 23:58:35.630 INFO 24376 --- [ Thread-7] .SchemaDropperImpl$DelayedDropActionImpl : HHH000477: Starting delayed evictData of schema as part of SessionFactory shut-down'
2019-12-02 23:58:35.630 INFO 24376 --- [ Thread-5] .SchemaDropperImpl$DelayedDropActionImpl : HHH000477: Starting delayed evictData of schema as part of SessionFactory shut-down'
2019-12-02 23:58:35.637 INFO 24376 --- [ Thread-5] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown initiated...
2019-12-02 23:58:35.642 INFO 24376 --- [ Thread-5] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown completed.
2019-12-02 23:58:35.733 ERROR 24376 --- [ Thread-7] .SchemaDropperImpl$DelayedDropActionImpl : HHH000478: Unsuccessful: drop table event if exists
2019-12-02 23:58:35.734 INFO 24376 --- [ Thread-7] com.zaxxer.hikari.HikariDataSource : HikariPool-2 - Shutdown initiated...
2019-12-02 23:58:35.739 INFO 24376 --- [ Thread-7] com.zaxxer.hikari.HikariDataSource : HikariPool-2 - Shutdown completed.

> Task :asciidoctor NO-SOURCE
> Task :bootJar
> Task :jar SKIPPED
> Task :assemble
> Task :check
> Task :build

BUILD SUCCESSFUL in 18s
5 actionable tasks: 5 executed
오후 11:58:36: Task execution finished 'build'.

cli를 들여다보니, 위와 같이 노출이 되는데 자세히 들여다보면 > Task :asciidoctor NO-SOURCE 가 있습니다.

의존성문제인줄알고 버전도 변경 하여 보고 build.gradle 파일의 코드가 잘못되었거나,

버전이 올라가면서 변경점이 있는지 체크해보았으나 다른점이 없어 검색을 하였더니
asciidoctor sourceDirectory가 Maven 플러그인에서는 src/main/asciidoc이지만, Gradle 플러그인은 sourceDirectory가 /src/docs/asciidoc 였습니다.
또한 Spring-REST-Docs에 의해 생성되는 경로도 아래 이미지와 같이 달랐습니다

JUnitRestDocumentation rule

Maven을 사용해 본 적이 없어서 gradle과 플러그인도 동일할줄 알았는데,

빌드 결과물도 다른 디렉토리에 생성되고 실행가능한 명령어들도 다른것을 알 수 있었습니다.

참고자료


[JS]Object literal 보다 JSON.parse()가 더 빠르다

서론


웹에서 몇 kb 크기의 객체를 초기에 렌더링 하는것은 생각보다 많습니다.

이 javascript 객체가 로드될때까지 클라이언트는 빈 화면을 보게 될 수 있습니다.

이러한 문제를 해결하기 위해, 서버사이드 렌더링을 활용 하는 방법도 있겠지만
다른 방법은 없을까요?

Chrome Dev Summit에서는 객체를 JSON으로 직렬화 하고, 문자열 리터럴로 변환해 Javscript 객체에 전달하는 것이 성능 향상에 도움이 된다고 이야기합니다.

무슨 소리일까?


아래의 두 코드는 동일한 객체를 생성하지만,
Javascript 엔진의 경우, JSON 예제를 스캔하고, 파싱만 하기 때문에 빠르다고합니다.

Javascript 파서에게 해당 코드는 여러개의 객체 리터럴을 받는 코드이냐, 많은 양의 데이터가 담긴 문자열 단일 리터럴이냐로 구분됩니다.

해당 예제에서의 객체의 값은 숫자이지만, 자기 자신의 속성과 값을 가진 Object 또는 배열이거나, 더 많은 값을 가진 무엇이든 될 수 있기 때문입니다.

이렇기 때문에 자바스크립트 파서는 단지 올바르게 토큰화 하기위해 JSON.parse에 비해 더 많이 동작 해야 합니다.

또 다른 이유로는 자바스크립트 객체 리터럴은 그 값이 객체문자열이라는것을 미리 알지 못하기때문입니다.

JSON.parse로 파싱할때에는 간단하게 중괄호 이후에 Object로 시작할지, 아니면 잘못된 JSON 형식인지라는 두가지 옵션에만 중점을 둡니다.

반면 객체 리터럴은 위의 이미지와 같이 Javscript Object는 중괄호 뒤의 값이 무엇인지를 아직까지는 알 수 없고

이렇게 되었을때는 첫번째 라인에 선언된 x의 값을 바인딩 한 객체 리터럴을 생성하는것을 알 수 있다.

하지만 이와 같이 선언 되었을 경우 두번째 라인의 코드에서 첫번째 라인의 x는 전혀 참조되지않습니다.

이와 같이, 이러한 문맥 의존 문법으로 인해, Javascript 엔진에서의 파싱이 까다롭습니다.

문자열을 JSON 파싱하는것은 이러한 문제가 없어, 구문 분석이 훨씬 간단해져서 빠를 수 있는것 입니다.

실제로 얼마나 빠른건데?


캐시가 없는 콜드로드 상태에서 8MB에 가까운 페이로드를 기준으로 파싱하였을때,
v8과 크롬에서 JSON.parse()가 1.7배정도 빠르다고 한다.

이는 다른 자바스크립트 엔진이나 브라우저에서도 적용된다고한다.

리덕스앱에 이와 같은 적용을 한 사례에서는 Time To Interactive(TTI)가 18% 개선되었고, Lighthouse 성능 점수가 8포인트 증가하였습니다.

이러한 작업을 직접 수동으로 하는것 대신 툴을 이용하는것을 추천합니다.
코드 베이스에 JSON 모듈을 사용할 경우, webpack에서는 JSON.parse()기능을 이미 적용 시켰습니다.

다른 코드들은 babel 플러그인를 이용해 변환 할 수 있습니다.

맺음말


페이스북 페이지에서

Faster apps with JSON.parse

해당 문구를 보자마자

“엥?? JSON.parse()는 느리지 않나??” 라는 생각만을 가지고 관심을 가지며 영상을 보면서 정리한 내용이라 제가 잘못 이해한 부분이 있을 수 있습니다.

잘못된 부분이 있으면 코멘트 부탁 드리겠습니다.

출처


Faster apps with JSON.parse (Chrome Dev Summit 2019)

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×