낭중일기

electron의 윈도우용 인스톨러 NSIS 설정

Wed, 06 Jun 2018 00:00:00 GMT

얼마 전부터 일렉트론으로 무언가를 하고 있는데 슬슬 인스톨러를 붙여볼 시점이 되어 electron-builder의 설정을 뒤적이며 삽질한 결과 몇가지 알게된 것이 기뻐 몇자 끄적여본다.

NSIS

electron-builder에서 윈도우용 인스톨러로는 nsis, appx, msi, squirrel 등을 선택할 수 있는데 나는 그 중에 nsis를 선택했다. 특별한 이유가 있지는 않고 electron-builder의 기본값이기도 하고 문서에서도 상대적으로 자세하게 설명되어 있기 때문에 선택했다. NSIS는 널소프트 스크립터블 인스톨 시스템의 약자로 추억의 프로그램 윈앰프의 인스톨러를 위해 만들어졌다고 한다.

`package.json`을 이용한 설정

electron-builder를 사용할 때는 package.json 파일에 build 설정을 추가할 수 있다. 여기에 입력할 수 있는 옵션들은 홈페이지에 자세히 나와있다. 주소마저 기억하기 쉽다. 그것은 바로 https://electron.build/이다. 가령 내 경우 현재 이 정도 설정을 추가했다.

{
  ...
  "productName": "소중한 앱이름",
  "scripts": {
    "build": "electron-builder build"
  },
  "dependencies": {
    ...소중한 의존모듈님들
  },
  "devDependencies": {
    ...소중한 개발의존모듈님들
  },
  "build": {
    "appId": "com.myappid",
    "files": [
      "나의소중한파일들의경로"
    ],
    "win": {
      "target": [{
        "target": "nsis",
        "arch": [
          "x64",
          "ia32"
        ]
      }],
      "icon": "나의소중한아이콘경로.ico"
    },
    "nsis": {
      "oneClick": false,
      "perMachine": true,
      "allowToChangeInstallationDirectory": true,
      "language": 1042,
      "include": "build/installer.nsh",
      "shortcutName": "단축아이콘 이름"
    },
    "directories": {
      "output": "빌드를마친파일이가야할경로"
    }
  }
}

하나씩 살펴보면 다음과 같다.

`productName`

인스톨러에 표시되는 프로그램 이름을 설정할 때 이 값을 사용한다.

`scripts`

electron-builder의 cli 명령은 문서에 잘 나와있다. npm script에 electron-builder build를 등록하여 사용하고 있다.

`build`

electron-builder의 본격적인 설정이다. 이름만 봐도 어느 정도 알 수 있다. 이름만으로 알 수 없는 설정은 다음과 같다.

`nsis.oneClick`

별도의 경로 설치없이 한방에 설치되게 할 것인가를 설정한다. 기본값은 true라서 이 설정없이 만든 인스톨러를 실행하면 %APPDATA%로 설치된다.

`nsis.perMachine`

사용자별 설치인지 기기 단위 설치인지 설정하는 옵션이다. oneClick 값에 따라서 기본값이 바뀐다고 문서에 설명되어 있다. oncClick을 false로 두고 인스톨러를 빌드해서 실행했더니 사용자가 선택하도록 하는 화면이 나왔다. perMachine을 true로 해서 선택화면이 나오지 않게 했다.

`nsis.allowToChangeInstallationDirectory`

사용자가 설치하면서 설치 디렉토리를 변경할 수 있는지 여부이다.

`nsis.language`

인스톨러의 언어를 지정한다. 설명에는 기본값이 시스템 언어라고 되어 있던데 내가 해보니 영문을 모르겠지만 영어로 나왔다. 여기에는 마이크로소프트의 LCID 값을 넣어줘야 한다고 되어 있다. 그런데 문서에 있는 링크로 가보면 필요한 값이 없어서 좀 더 찾아보니 이런 문서를 발견했다. 한국어는 1042이다.

`nsis.shortcutName`

바탕화면에 생성되는 단축아이콘의 이름이다.

`nsis.include`

NSIS가 사용하는 스크립트를 추가할 수 있다. build/installer.nsh 경로에 파일을 생성한다. 위에서 언급한 것처럼 설치 디렉토리의 기본값이 %APPDATA%라서 변경하기 위해서 여기에 스크립트를 사용했다. 문서의 경우에는 C:\MyApp에 설치하도록 설명하고 있는데, C외의 드라이브를 루트로 사용하는 사람들도 간혹 있기 때문에 불안한 방법이라고 생각되어 조금 더 찾아본 결과 아래와 같이 사용하기로 했다.

Var SystemDrive

!macro preInit
    ReadEnvStr $SystemDrive SYSTEMDRIVE
    SetRegView 64
    WriteRegExpandStr HKLM "${INSTALL_REGISTRY_KEY}" InstallLocation "$SystemDrive\앱이설치될폴더명"
    WriteRegExpandStr HKCU "${INSTALL_REGISTRY_KEY}" InstallLocation "$SystemDrive\앱이설치될폴더명"
    SetRegView 32
    WriteRegExpandStr HKLM "${INSTALL_REGISTRY_KEY}" InstallLocation "$SystemDrive\앱이설치될폴더명"
    WriteRegExpandStr HKCU "${INSTALL_REGISTRY_KEY}" InstallLocation "$SystemDrive\앱이설치될폴더명"
!macroend

변수는 !macro안에 선언할 수 없고 전역에 두어야 하는 모양이다. ReadEnvStr $SystemDrive SYSTEMDRIVE 구문은 변수 $SystemDrive에 환경변수인 SYSTEMDRIVE를 담도록 하고 있다. 그 아래는 64bit와 32bit 운영체제에 따라 별도의 경로를 설정할 수 있다.

가령 위의 경우처럼 $SystemDrive 대신에 $ProgramFiles64 또는 $ProgramFiles도 사용할 수 있는 것 같다. ProgramFiles의 경우에는 별도로 변수를 할당해 주지 않아도 경로 지정이 가능했다.

참고로 잘못된 경로를 넣으면 빌드에 실패한다. 나 같은 경우에는 시스템 드라이브 루트에 설치되게 하기 위해서 삽질을 하다보니 잘못 넣으면 빌드에 실패한다는 사실을 체감하고 말았다.

`directories.output`

빌드된 인스톨러가 저장되는 경로이다. 별도로 지정하지 않으면 dist 디렉토리에 저장된다.

그리고, `node-gyp` 또는 `node-pre-gyp` 빌드오류

일렉트론을 빌드할 때 네이티브 모듈을 재빌드하곤 하는데, 이유는 알 수 없지만 windows-build-tools로 설정해놓은 작업환경에서도 빌드가 실패했다. 빌드실패로 생기는 오류가 엉뚱한 점 중의 하나는 빌드에 실패한 후 바이너리 다운로드를 시도하다가 다운로드에 실패한 것으로 나오는 경우이다.

혹시 node-pre-gyp ERR! Tried to download(403): 같은 오류와 함께 URL이 생기는 오류라면 다운로드가 아니라 로컬환경에서 빌드가 되지 않아 생기는 오류를 의심하는 편이 문제를 빨리 해결하는데 도움이 될 것이다. 내 경우에는 sqlite3로 인해 다음과 같은 오류를 경험했다.

node-pre-gyp ERR! Tried to download(403): https://mapbox-node-binary.s3.amazonaws.com/sqlite3/v4.0.0/electron-v1.8-win32-x64.tar.gz

결론적으로는 node-gyp 빌드가 가능한 환경을 달성하면 된다. 마이크로소프트의 Node.js 가이드라인에 수동 환경설정 과정이 소개되어 있다. 빌드에 성공한 방법은 다음과 같다.

Visual C++ BuildTools 설치: http://go.microsoft.com/fwlink/?LinkId=691126
Python 2.7 설치: https://www.python.org/downloads/ (윈도우 환경변수에 파이썬 경로를 추가해주어야 한다.)
모두 설치를 마치면 명령창에서 npm config set msvs_version 2015를 실행한다.

이렇게 해도 실패한다면 node_modules 디렉토리를 삭제하고 의존 모듈을 다시 설치해보기를 추천한다. 혹시 그래도 안된다면… 멀리서나마 행운을 빌겠다.

나의 Amazon Go 방문기

Wed, 23 May 2018 00:00:00 GMT

Gas Works Park의 평화로운 조류들. 나랑은 관련이 없다.

시애틀은 졸립습니다.

시차와 피로의 영향으로 밤낮을 가리지 않고 잠이 오는 시애틀에는 유명한 우주바늘을 비롯해서 별다방 1호점, 파이크플레이스 마켓 같은 유명 관광지도 많다. 잠못 이룰만한 일은 벌어지질 않는다. 여기에는 블로그 분위기에 어울리게 아마존의 편의점인 Amazon Go에 방문한 이야기를 잠시 적어본다.

아마존 고

아마존 고는 계산하는 점원이 없는 대형 편의점 정도의 느낌이었다. 예상과 달리 무인점포 같은 느낌은 아니고 점원도 매우 여러명이 있고, 일도 하는 것 같지만 자기들끼리 모여서 이야기를 나누고 있는 것 같기도 하다. 한국 편의점 알바의 업무 강도에 비하면 뭔가 행복해보이는 사람들이 주황색 옷을 입고 서성이고 있다.

> 아마존 고의 모든 것을 보여주는 동영상. 그렇다 저게 전부다.

입장을 위해서는 아마존 고 전용 앱을 설치하고 카드를 등록해야 한다. 한국에서 발급받은 신용카드도 쓸 수 있다. 나는 해외결제가 되는 신한은행 체크카드를 사용했는데 이걸로도 문제없이 결제가 되었다. 입장할 때 앱을 실행해서 출입구에서 태그를 찍고 입장한다. 일행이 있는 경우에는 일행을 먼저 입장시키고 입장해야 한다. 바구니에 상품을 넣었다 빼는 경우에는 물건을 넣은 사람이 꺼내야 제대로 인식한다는 설명이 있었다.

봄 신상품으로 소바 샐러드가 출시되었다.

콤부차를 집을까봐 일거수일투족을 감시하는 카메라.

들고 나가기만 하면 된다.

나도 모르게 돈이 빠져나가는 신비의 문.

위장에 약간의 따스함을 전달하고 싶을 때는 전자렌지를 쓸 수 있다.

물건을 모두 고른 후에 훔쳐가듯이 재빠르게 출구로 나와도 결제가 되고 만다. 출구 근처에는 음식을 먹을 수 있는 공간이 있다. 일회용 식기도 있고 전자렌지도 준비되어 있다.

과자는 역시 감자칩이랑게. 감자에 싹이 나서 잎이 나서 칩, 감자감자칩…

그리고 감자칩을 맛있게 먹었다. ~~러플스를 수입해달라.~~ 바닥에 깔려있는 아마존 고 봉투는 기간 한정 사은품으로 매장에 비치되어 있었다.

Hammerspoon을 이용한 macOS 한영전환키 설정

Wed, 27 Dec 2017 00:00:00 GMT

Caps Lock이 싫어서

시에라 이후로는 CapsLock 키로 한영전환을 할 수 있게 되서 버릇을 고친 사람도 많겠지만, 미개한 나의 버릇을 고치기 보다는 컴퓨터에게 일 시키는 것이 더 편하다. 사실 Karabiner-elments를 설치하면 간단하게 해결할 수 있지만, 마음에 들지 않는 구석이 있어 다른 방법을 찾아보다가 Hammerspoon을 쓰게 되었다. 참고로 이 글은 macOS는 시에라 10.12.6, Hammerspoon은 0.9.55 버전을 기준으로 작성했다.

Hammerspoon

Hammerspoon은 macOS용 매크로라고 볼 수 있다. macOS에 JXA라고 해서 Javascript로 매크로를 짜는 방법도 있기는 한데, Hammerspoon의 경우에는 Lua(http://www.lua.org/)로 작성한 스크립트를 실행해준다. 오픈 소스 앱이고 무료이다. 우선 앱을 설치하면 다음과 같이 상단 메뉴 막대 우측에 망치모양의 아이콘이 추가된다.

ㅁ..망치숟가락!

여기서 Open Config을 선택하면 Hammerspoon이 실행하는 스크립트 파일이 열린다. 이 스크립트 파일은 ~/.hammerspoon/init.lua에 위치하고 있다. 그런데 내가 Lua 문법을 좀 아느냐 하면 잘 모른다. 그렇지만 한영키 전환 정도야 간단하리라는 희망을 품고 방법을 찾아보았다.

키 맵핑 적용하기

나의 긍정적인 예상대로(?) Hammerspoon의 GitHub wiki에서 내가 원하는 모듈을 찾을 수 있었다. 키를 리맵핑 할 때 쓸 수 있는 foundation_remapping 모듈을 쓰기로 하고 foundation_remapping.lua 파일을 내려 받았다.

내려 받은 foundation_remapping.lua 파일은 ~/.hammerspoon/ 디렉토리에 넣어준다. 개별 파일을 모듈로 쓸 수 있는 모양이다. init.lua 파일에 아래의 내용을 추가했다.

local FRemap = require('foundation_remapping')
local remapper = FRemap.new()

remapper:remap('ralt', 'f18')
remapper:register()

내려받은 모듈을 불러온 후에 우측 알트키를 f18에 맵핑 한 것 같다. 이렇게 해서 저장을 하고 다시 메뉴 막대의 망치를 눌러서 Reload Config을 실행한다. 이제 한영키가 잘 적용되었는지 해보면 아무 일도 일어나지 않았습니다.

시스템 단축키 설정을 바꿔주어야 한다. 시스템 환경설정 - 키보드 - 단축키 - 입력소스 - 입력메뉴에서 다음 소스 선택을 고르고, 앞에서 열심히 맵핑한 오른쪽 Alt키에 넌 F18이고 난 주인이야를 외치면서 살며시 눌러본다. 그럼 아마 잘될 것이다. (부디…)

Hammerspoon Preference 창 자동으로 닫기

보통 맥 사용자라면 재부팅을 잘 하지 않지만 나에게는 컴퓨터는 껐다 켜야 제 맛 같은 습관이 있어서 사용을 마치면 전원을 꺼버리는 편이다. 그런데 부팅 때 마다 Hammerspoon을 실행시키도록 Launch Hammerspoon at login을 체크해 놓으면 매번 설정창이 등장해서 귀찮았다.

그래서 이 창을 닫는 스크립트를 추가해버렸다. Hammerspoon이 제공하는 타이머 기능이 문서에 정리되어 있는데, 그 중 하나를 사용했다.

악의 근원, Launch Hammerspoon at login

hs.timer.waitUntil(
    function()
        if (hs.window.find('Hammerspoon Preferences') == nil) then
            return false
        else
            return true
        end
    end,
    function()
        hs.window.find('Hammerspoon Preferences'):close()
    end,
500)

재부팅 해보면 아마 잘 될 것이다. (부디…)

결론

완료된 나의 init.lua 파일은 다음과 같다.

local FRemap = require('foundation_remapping')
local remapper = FRemap.new()

remapper:remap('ralt', 'f18')
remapper:register()

hs.timer.waitUntil(
    function()
        if (hs.window.find('Hammerspoon Preferences') == nil) then
            return false
        else
            return true
        end
    end,
    function()
        hs.window.find('Hammerspoon Preferences'):close()
    end,
500)

사실 이렇게 까지 할 필요가 있나, 습관을 고치면 편할 것을! 같은 생각이 들기도 하지만 1도 모르는 Lua를 (몇 줄 안되지만) 끄적거려본 나름 즐거운 시간이었다. ~~end를 제대로 안써서 오류나고 그런 건 비밀이다.~~ 모듈 불러올 때 require라서 왠지 익숙한 느낌적인 느낌이 들기도 했고.

그러나 애석하게도 이 후로는 아무 것도 자동화 하지 않았다는 슬픈 사연이…

react-navigation과 redux 통합하기

Sun, 17 Dec 2017 00:00:00 GMT

tl;dr

어떤 내비게이션이 좋은지는 아몰랑
Expo: http://docs.expo.io/
react-navigation + redux: https://reactnavigation.org/docs/guides/redux
React Native Debugger
이 글에 사용한 코드의 저장소: https://github.com/hyunchulkwak/rn-practices
Expo 링크: https://expo.io/@hyunchulkwak/rn-practices

단도직입적으로…

대부분의 경우에 새로운 기술을 접하거나 소개할 때는 React Native 시작하기 같은 제목의 글을 쓰는 것이 보통일 것이다~~(선빵)~~. 그러나 React Native는 시작하는 것이 사실 좀 번거롭기도 하다. 게다가 시작하기 류의 글은 왠지 이어서 쓰기가 부담스러울 것 같다. 그래서 대신에 요즘 백수생활의 시간낭비 삼아 사소한 앱을 만들면서 겪은 내가 삽질한 결과를 조금 옮겨보기로 했다.

Expo

Expo는 무엇인가? Expo는 꿈돌이가 춤추던 대전 엑스포가 아니다. 그게 93년이니까 어쩌면 이 글을 보는 분 중에 그 해에 태어난 분들도 있겠다~~(흠좀무)~~. 처음 React-Native를 react-native init으로 시작하는 것은 다소 자해행위 같은 느낌이 있다. 특히 안드로이드 환경설정하는 것은 매우 귀찮은데, 무언가 해야할 것이 많아서 내가 이러려고 React Native 시작했나 하는 자괴감이 들게 된다. Expo는 이런 귀찮은 작업을 무마해주는 도구로, 애플리케이션 코드만 짜면 Expo 클라이언트 앱을 통해서 바로 코딩 결과를 확인할 수 있다.

Expo XDE(https://github.com/expo/xde/releases)를 설치하면 GUI로 프로젝트 생성과 빌드를 클릭 몇번으로 해결할 수 있다. 코딩 결과는 아이폰과 안드로이드용 Expo 클라이언트를 통해 확인할 수 있다. CLI 선호자를 위해 npm 패키지로 CLI도 제공한다. SDK가 제공하는 다양한 기능을 활용하면 네이티브 모듈과 연결하는 수고도 줄여준다. 이 정도면 종합선물셋트 수준이다. ~~꿈돌이 종합선물셋트!~~

사실 지금 작업 중인 나의 삽질 가득한 개인 프로젝트는 react-native init으로 시작했다가, Expo로 해봤다가, 다시 react-native init으로 돌아가긴 했다. 둘을 비교해보면 Expo로 만들면 빌드한 앱 용량이 좀 커지는 편이고, 네이티브 모듈을 연결하려면 결국 eject를 해야 하는 등의 아쉬움이 있다.

그렇지만 처음 시작할 때 복잡한 설정을 거치지 않아도 되서 이 글을 쓰는 목적에는 잘 부합하기 때문에 여기서는 Expo를 사용한다.

XDE 최신버전을 내려받고 실행한다. 가입은 GitHub 계정으로 할 수 있다. XDE에서 Project - New Project를 누르고 디렉토리를 지정하면, 프로젝트 스캐폴딩을 부어주고, 의존 모듈도 설치하고, ~~북치고 장구치고 서장이랑 받도 먹고~~ Expo 클라이언트에서 접속할 수 있는 URL도 알려준다. XDE를 설치하는게 내키지 않는다면 create-react-native-app을 써보는 것도 좋다. 그렇지만 이 경우에도 결과물을 확인할 때는 Expo 클라이언트를 사용하게 된다. 이제 문제의 디렉토리를 에디터에서 열고 본론으로 넘어간다.

초기 설정을 마치고 커밋한 결과는 여기에서 확인할 수 있다.

내비게이션의 세계

react-navigation은 React Native 프로젝트에 흔히 사용하는 내비게이션 모듈 중 한가지이다. 이것 외에도 인기있는 패키지가 몇가지 더 있는데 그것이 알고싶다면 여러가지 패키지를 비교한 아래의 글들을 참고하면 좋을 것 같다.

여기에 한가지 더 추가하자면 판단기준으로 쓰기는 적절하지 않지만, Facebook에 개설된 React Native Community 그룹의 최근 인기도를 보면 react-navigation 보다 react-native-navigation의 인기가 좀 더 올라간 것 같기는 하다.

react-navigation 적용하기

서론이 엄청 길었다. 일단 react-navigation을 설치한다.

yarn add react-navigation

일단 아무 것도 없는 황무지에 내비게이션을 붙여보자. react-navigation은 내비게이션 구조에 따라 StackNavigator, TabNavigator, DrawerNavigator를 제공한다. 예를 들어 첫화면, 소개, 도움말 같이 3개의 화면을 구현해야 한다면, 내비게이터와 각각의 화면을 정의해야 한다. 디렉토리 구조는 대략 이렇게 잡았다.

/navigator
  AppNavigator.js
  index.js
/screens
  Home.js
  About.js
  Help.js
  index.js
App.js

우선 내비게이터를 정의해본다. 내가 작업하는 앱에서는 DrawerNavigator를 쓰고 있었는데, 이 글에서는 TabNavigator를 써봐야겠다. 예제 코드를 참고해서 작성해보았다. TabNavigator API는 이렇다.

TabNavigator(RouteConfigs, TabNavigatorConfig)

RouteConfigs에 각 라우팅별로 navigationOptions를 줄 수 있는데, 여기에 레이블과 아이콘을 설정한다.

// navigation/AppNavigator.js
Home: {
  screen: Home,
  navigationOptions: {
    tabBarLabel: 'Home',
    tabBarIcon: ({ tintColor, focused }) => (
      <Ionicons
        name={focused ? 'ios-home' : 'ios-home-outline'}
        size={26}
        color={tintColor}
      />
    ),
  },
},

위에서 Ionicicons의 경우에는 Expo에서 제공해주는 @expo/vector-icons를 사용한다. 전체 아이콘 목록(https://expo.github.io/vector-icons/)도 참고하면 좋겠다.

TabNavigatorConfig에는 다음과 같이 설정을 추가했다. 각 옵션에 대해서는 문서에서 살펴볼 수 있다.

{
  tabBarPosition: 'bottom', // 탭을 하단으로 위치시킨다. ios는 하단, 안드로이드는 상단이 기본값이다.
  animationEnabled: true,
  tabBarOptions: {
    inactiveTintColor: '#333',
    activeTintColor: '#400011',
    style: {
      backgroundColor: '#fff',
    },
    labelStyle: {
      fontSize: 10,
    },
    indicatorStyle: {
      backgroundColor: '#400011',
    },
    showIcon: true, // 안드로이드는 기본값이 false이므로, 통일을 위해 true로 설정한다.
    showLabel: true,
  },
}

어서오세요, 안녕히 가세요(?)

이 부분까지 마치고 커밋한 결과는 여기에서 확인할 수 있다.

redux에 상태 떠넘기기

redux와 연결하는 방법은 문서에 잘 소개되어 있기는 하다. 저장소에서 예제 코드도 찾아볼 수 있다. 보고 잘 흉내내 본다.

redux 스토어와 루트 리듀서를 만든다.
내비게이션 리듀서를 만든다.
App.js에서 렌더링했던 AppNavigator에 navigator 속성으로 addNavigationHelpers({ dispatch, state })을 넘겨준다.
3을 위해서는 AppNavigator를 렌더링하는 부모 컴포넌트를 redux에 연결해주어야 한다.
4에서 만든 redux에 연결한 컨테이너 컴포넌트를 Provider에게 순순히 넘겨준다.

1번은 스킵하고 2번을 잠시보자. 이렇게 생겼다.

import { AppNavigator } from './AppNavigator'; // 아까 걔임..

const initialState = AppNavigator.router.getStateForAction(
  AppNavigator.router.getActionForPathAndParams('Home') // 액션을 반환한다: {type: 'Navigation/NAVIGATE', 'routeName': 'Home'}
);

const navigatorReducer = (state = initialState, action) => {
  const nextState = AppNavigator.router.getStateForAction(action, state);

  return nextState || state;
};

export { navigatorReducer };

Custom Router API가 사용되어 혼란스러워 보이지만, 초기 상태를 설정하고 라우팅 액션이 들어올 때 마다 새로운 상태를 반환하는 리듀서일 뿐이다. 조금 있다가 이 광경을 Redux 개발자도구로 보면 마음에 평화가 찾아오니 일단 지나가자.

공식문서의 예제에서는 App 컴포넌트를 redux에 연결하고, AppNavigator의 navigator 속성을 추가해준다. 이후에 Root 컴포넌트를 새로 만들어서 App 컴포넌트를 렌더링한다. 나 같은 경우에는 App 위에 Root를 두는 대신 NavigatorRoot를 만들었다. 별 차이는 없다. 그리고 Expo는 최상위 컴포넌트를 기본적으로 App.js에 선언하는데, 이걸 변경하려면 app.json에서 entryPoint를 설정하고, 최상위 컴포넌트를 설정하는 파일도 생성해주어야 하니 Root를 쓰려면 번거롭다.

const AppNavigatorWithNavigationState = ({ dispatch, navigator }) => (
  <AppNavigator
    navigation={addNavigationHelpers({
      dispatch,
      state: navigator,
    })}
  />
);

const mapStateToProps = ({ navigator }) => ({ navigator });

const NavigatorRoot = connect(mapStateToProps)(AppNavigatorWithNavigationState);

export { NavigatorRoot };

늘 한결같은 모습에 반해버림

지금 막 뭔가 대단한 일을 벌인 것 같은데 애석하게도 화면 상의 변화는 없다. 이거 그럼 뭐하러 함!? 이제 준공식을 마쳤으니 삼천포 톨게이트로 차를 보내야겠다. 여기까지 작성하고 커밋한 결과는 여기에 있다.

React Native Debugger 연결하기

redux 개발자도구에서 제대로 redux와 연결되었는지 작동해보고 싶다. React Native Debugger라는 신통방통한 도구가 있어서 써보려고 한다. Electron으로 만들어진 프로그램이라 먼저 릴리스 페이지에 가서 내려받는다.

react-native-debugger-open를 devDependencies에 추가하고 package.json의 scripts에 아래와 같이 명령을 추가한다. XDE에서 실행하면 React Native Debugger가 잘 작동하지 않아서 cli로 돌아갔다. ~~(이제 와서!?)~~ React Native Debugger의 가이드를 보면 postinstall을 사용하게 되어있는데, 제대로 안 찾아봤지만 아마도 메트로 번들러에서 이 명령을 실행하기 때문인 모양인데, Expo는 이 명령을 실행하지 않으니 그냥 start 명령을 추가하기로 했다.

yarn add --dev react-native-debugger-open exp

// package.json
"scripts": {
  "start": "yarn run rndebugger && exp start",
  "rndebugger": "rndebugger-open --revert && rndebugger-open --open --expo"
},

--expo 옵션을 주는 이유는 Expo의 경우 원격 디버깅에 19001 포트를 사용하기 때문이다.

redux 개발자도구에 연결할 수 있도록 store도 약간 수정해야 한다.

import { createStore } from 'redux';
import { reducer } from './reducer';

const store = createStore(
  reducer,
  window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__(),
);

export { store };

위와 같이 설정하고 이렇게 실행해본다. 뒤에 --lan 옵션은 Expo cli 옵션인데, 로컬 ip로 QR코드를 생성해준다. Expo가 제공하는 터널을 통해서 원격 디버깅을 너무나 느리기 때문에 이렇게 하는 편이 낫다. 다만 PC와 테스트 기기가 같은 무선망에 연결되어 있어야 한다. --lan을 따로 붙이는 이유는 시뮬레이터로 실행한다거나 하는 다른 cli 명령들도 편의대로 추가할 수 있기 때문이다.

$ yarn start --lan

위의 명령을 실행하면 맥에서는 React Native Debugger를 잘 설치했으면 자동으로 실행도 된다. 윈도우는 실행까지는 되지 않으니, 미리 실행해놓아야 한다. 결과를 보자 헤헤.

참고로 위 화면에서 안드로이드는 실제 기기를 연결했다. 삼성 스마트폰의 경우 SideSync라는 프로그램을 쓸 수 있다.

여기까지 마치고 커밋한 결과는 여기에서 확인할 수 있다.

내비게이션 액션 처리

NavigationActions.navigate()를 디스패치해주면, redux를 통해서 내비게이션을 변경할 수 있다.

import { NavigationActions } from 'react-navigation';

dispatch(NavigationActions.navigate({ routeName: 'Home', params: {} }));

params의 관리는 물음표인데, 적절한 가이드를 찾지는 못했다. redux를 사용하지 않을 때는 각 스크린에서 this.props.navigation.state.params까지 산넘고 물건너 찾아가야 하는 불편함이 있다. 디스패치한 params 값을 내비게이션 리듀서의 action에서 받을 수도 있기 때문에, 타입이 'Navigation/NAVIGATE'인 액션을 기준으로 적절히 관리해보고 있다. 이 글을 보시는 분 중에 좋은 방법을 알고 계시는 분이 있다면 댓글 좀 부탁드립니다. (굽신굽신…)

그나저나 가벼운 마음으로 글을 쓰려고 시작했는데 생각보다 많은 것(?)을 쓰고 말았다. 오늘은 이쯤에서 얼렁뚱땅 마무리를 짓겠다. 다음 이 시간까지 안녕~

Windows에서 프론트엔드 개발환경 설정하기

Wed, 06 Dec 2017 00:00:00 GMT

왜 윈도우인가?

단도직입적으로, 개발을 위해 어떤 운영체제가 더 나은가는 이 글의 관심사가 아니다. 단지 일하다보면 윈도우에서도 개발환경을 설정해야 하고 그 과정의 고통을 경감시키는 정도를 목표로 하고 있다. 내 입장에서는 맥이나 윈도우나 안되는 시점이 다를 뿐 안될 때는 둘 다 나에게 엿을 준다. 단 거 먹고 힘내라고.

울릉도 특산물, 호박엿

엿도 많이 먹으면 지겹기 때문에 충치예방을 위해 적당히 먹어야 한다. 엿 대신 먹을 수 있는 먹거리를 살펴보자. ~~뭐야, 생생정보통이야?~~

cmder: 윈도우용 콘솔 에뮬레이터

처음 윈도우용 git-bash의 답답함에 Conemu를 접하고 투박함에 별짓을 다해보았지만 내 능력으로는 별 소용이 없었다. cmder는 Conemu를 잘 지지고 볶아 먹음직스러운 요리로 만들어놓았다.

홈페이지(http://cmder.net/)에서 다운로드 받을 수 있으며, 풀버전은 Git이 포함되어 있는데, 그 아래에 작은 글씨로 된 7z 압축 파일(52mb)을 내려받는 것을 추천한다. 압축을 해제하고 Cmder.exe를 실행하면 초록빛깔 람다가 명령을 기다린다. Git 설치 마저도 귀찮은 나에게 딱 좋아.

~~먹으면 잘 싸야 탈이 없다.~~

심화코스: LF 강제하기

혼자 일하는 환경이 아니면 맥 사용자와 윈도우 사용자가 만나 CRLF와 LF의 화개장터가 자주 벌어진다. 이걸 막기 위해 나는 이런 방법들을 쓰고 있다.

git 설정

git config --global core.eol lf
git config --global core.autocrlf input

프로젝트의 .gitattributes
```
* text=auto
```
프로젝트의 .editorconfig
```
[*]
end_of_line = lf
```

1, 2번의 경우 스택오버플로우 답변을 참고했고, 3번의 경우 IDE에서 EditorConfig을 사용하는 경우에만 적용된다.

심화코스: cmder를 위한 Snazzy

기본적으로 지원하는 색상도 충분하긴 한데, 나 같은 경우에는 맥에서 iterm, zsh, pure-prompt, snazzy를 적용해서 쓰다보니 묘하게 아쉬운 느낌이 들어서 찾아보니 Conemu용 snazzy 설정도 있었다. 앞에서 압축을 해제한 cmder 폴더에서 vendor/conemu-maximus5/ConEmu.xml 파일을 열고, gist의 xml 내용에서 name="Palette1"을 name="Palette2"로 바꿔서 아래처럼 추가했다. 참고로 폰트는 Fira Mono를 쓰고 있다.

<key name="Colors" modified="2017-11-06 20:26:04" build="161206">
  <key name="Palette1" modified="2017-11-06 20:26:04" build="161206">
    <value name="Name" type="string" data="Monokai"/>
    ...
  </key>
  <key name="Palette2" modified="2017-11-06 20:26:04" build="161206">
    <value name="Name" type="string" data="Snazzy"/>
    ...
  </key>
  <value name="Count" type="long" data="2"/>
</key>

위 내용을 추가한 후 설정(단축키 Win+Alt+P)에서 Features - Colors를 선택해서 Snazzy로 변경한다. 폰트는 Main에서 변경할 수 있다.

Chocolatey

그러나 아직 윈도우는 배가 고프다. 설치할 게 많다. node, npm을 필두로 yarn이라던가 즐겨쓰는 에디터도 설치해야 한다. 일하는 백엔드 환경에 따라 추가해야 할 설정도 많다. ~~그렇게 하나씩 설치하다가 집에는 언제 갈 것인가?~~ 출출한 윈도우에게 초콜렛을 먹이자. 윈도우는 출출할 때 윈도우가 아니야.

Chocolatey는 윈도우용 패키지 매니저이다. 맥으로 치면 Homebrew 같은 역할을 한다. 설치 안내 페이지에 가면 윈도우 명령창 또는 파워쉘에서 설치하는 법이 안내되어 있다. 명령창을 관리자 권한으로 실행한 후에 설치 명령을 실행한다.

이후에 필요한 프로그램 설치는 간단하다. choco install 먹거리이다. 가령 nodejs를 설치한다면 choco install nodejs를 실행한다. npm이랑 비슷하게 여러 개를 적어서 설치할 수도 있다. 환경변수 설정 등도 알아서 해주기 때문에 설치를 기다리며 딴짓을 하면 좋다.

IDE도 설치할 수 있다. 인텔리제이 계열의 IDE도 설치할 수 있는데, 시리얼 번호는 셀프다. 설치할 수 있는 패키지도 검색해볼 수 있다. JDK도 있고 Python, Ruby 등 생각할 수 있는 건 왠만큼 다 있다고 보면 되겠다. ~~비밀을 하나 밝히자면 cmder도 있다.~~

다양한 명령어는 choco -h로 도움말을 살펴보자. 설치(install), 삭제(uninstall), 업그레이드(upgrade), 목록(list)은 예측 가능한 단어로 되어있다.

λ choco -h
This is a listing of all of the different things you can pass to choco.

Commands

 * list - lists remote or local packages
 * search - searches remote or local packages (alias for list)
 * info - retrieves package information. Shorthand for choco search pkgname --exact --verbose
 * install - installs packages from various sources
 * pin - suppress upgrades for a package
 * outdated - retrieves packages that are outdated. Similar to upgrade all --noop
 * upgrade - upgrades packages from various sources
 * uninstall - uninstalls a package
 * pack - packages up a nuspec to a compiled nupkg
 * push - pushes a compiled nupkg
 * new - generates files necessary for a chocolatey package from a template
 * source - view and configure default sources
 * sources - view and configure default sources (alias for source)
 * config - Retrieve and configure config file settings
 * feature - view and configure choco features
 * features - view and configure choco features (alias for feature)
 * apikey - retrieves or saves an apikey for a particular source
 * setapikey - retrieves or saves an apikey for a particular source (alias for apikey)
 * unpackself - have chocolatey set itself up
 * version - [DEPRECATED] will be removed in v1 - use `choco outdated` or `cup  -whatif` instead
 * update - [DEPRECATED] RESERVED for future use (you are looking for upgrade, these are not the droids you are looking for)

NPM 패키지를 위한 `windows-build-tools`

node-gyp을 사용하는 패키지들은 간혹 윈도우에서 빌드를 시도하다가 피보다 붉은 오류를 뿜어내며 퇴근을 방해하곤 한다. 그런 사고를 미연에 방지할 수 있는 것이 바로 windows-build-tools이다. 수동으로 이러저러하게 설치하는 법도 있지만, 게으른 나에게 그럴 시간이 있을리가 없다.

행복을 찾아서…

λ yarn global add windows-build-tools

이 패키지가 설치하는 내용물은 다음과 같다.

Visual C++ Compilers (targeting x86, X64 and ARM)
Visual C++ headers & libraries (CRT & STL)
Visual C++ build scripts (targeting Windows desktop)
Microsoft Build Tools 2015 (MSBuild)
Windows SDK 8.1 (optional, on by default)
Windows SDK 10 (optional, off by default)
ATL and MFC (optional, off by default)
C++ Build tools specific command prompts

그리고 여기에 Python 2.7도 추가로 설치하지만 환경변수로 붙지는 않는다. 이 패키지가 설치한 Python은 탐색기를 열고 %USERPROFILE%\.windows-build-tools로 이동하면 확인할 수 있다.

로컬 서버

프로젝트 환경에 webpack-dev-server나 browsersync 같은 개발 서버를 잘 설정해 늫으면 그럴 일이 잘 없지만, 가끔은 HTML 정도를 열어보기 위한 로컬 서버가 필요할 때가 있다. lite-server 같은 모듈을 쓰는 방법도 있긴한데, 쓰다보면 늘 쓰는 디렉토리만 쓰기 때문에 콘솔로 이동하기가 왠지 귀찮다. 그래서 Fenix web server를 쓰곤 한다. 일렉트론으로 만든 노드 서버라고 보면 되겠다. 외부로 공유도 가능해서, 접속 URL도 제공해준다.

먼저 Web Server - New를 선택해서 이름, 디렉토리, 포트를 지정한다. 목록에 커서를 올리면 우측에 나오는 버튼으로 조작한다. 가장 우측에 녹색이 나오면 실행, 붉은 색이면 종료이다.

집사가 필요하다면…

맥에서 쓰는 알프레드 같은 걸 원하는 분들이 혹시 있을지 모르겠다. 윈도우 10 같은 경우에는 Win+S를 누르면 바로 검색창을 띄울 수 있기 때문에 이 기능을 자주 쓴다. 만족이 안되는 분이 있다면 또 다른 일렉트론 앱인 hain을 추천해본다.

새로운 시작

열심히 설치했는데 무언가 잘 안된다면 재부팅 해보자. 그래, 새로운 시작이다. 그래도 안되면 여기 손 끝에 닿는 미래가 있다.

Gatsby로 블로그 시작하기

Sun, 03 Dec 2017 00:00:00 GMT

시작하기

나는 너무나 게으르고 풍요로운 0과 1의 세계를 내가 오염시킬 필요가 없다고 생각해왔기 때문에 블로그 운영에는 관심을 끊고 살았지만, 사실 언제나 마음은 있었다. 오랜만에 또 마음이 동해서 여러 가지 블로그 생성 도구를 둘러보다가 Gatsby를 써보려고 하니 gatsby-starter-lumen 테마가 그럴싸해보여서 엉겁결에 이러저러한 인스톨과 약간의 테마 수정을 거쳐 이렇게 마크다운 몇자를 적는 일에 이르렀다.

Gatsby

Gatsby는 React로 만든 정적 사이트 생성기이다. ~~위대한 개츠비가 아니다.~~ ~~갸스비 왁스도 아니야.~~ 공식 웹사이트에서는 앞에 겁나 빠른을 붙여서 Blazing-fast static site generator for React라고 소개하고 있다. 문서와 튜토리얼을 잘 제공하고 있으나, 자세한 기능은 부대끼며 알아보기로 했다. 참고로 이 글을 쓰는 시점의 React의 최신 버전은 16.2.0이지만 Gatsby는 버전 15의 마지막 업데이트인 15.6.2를 의존하고 있다. 버전 16.x를 적용하려면 gatsby-plugin-react-next를 쓸 수 있는 모양인데 해보지는 않았다.

사실 유명한 정적 사이트 생성기로는 지킬을 비롯해서 많이 있기 때문에 Gatsby가 뭐가 좋은지 아직 잘 모르겠다. React로 되어 있고 위에도 말했지만 테마가 마음에 들었을 뿐이다. 사실 앞으로 Gatsby의 장점을 영영 모를 수도 있다. 블로그를 열심히 운영한 적이 없기 때문이다. 쉰소리는 그만하고 설치로 넘어가자.

설치

gatsby-cli를 설치하고 테마를 지정해서 초기화 명령을 하면 알아서 스캐폴딩을 하고 의존 모듈도 내려 받는다. 요즘은 다 이러니까 놀랍지가 않다.

$ yarn global add gatsby-cli
$ gatsby new blog https://github.com/alxshelepenok/gatsby-starter-lumen
$ gatsby develop

이렇게 실행하고 나면 localhost:8000으로 블로그 페이지에 접속할 수 있다. 게시물은 src/pages/articles에 디렉토리별로 분리되어 있다. src/pages/pages는 블로그 소개 같은 별도 페이지를 위한 디렉토리이다. 자세한 디렉토리 구조는 gatsby-starter-lumen에서 확인할 수 있다.

설정

블로그 설정은 gatsby-config.js를 잘 만져보면 된다. siteMetadata를 수정해주는 것이 거의 대부분이다. 여기서 author 항목에 있는 키를 삭제하면 GraphQL이 pageQuery에 오류가 났다고 난리다. 설정에서 삭제한 항목을 GraphQL 쿼리 보내는 부분을 확인해서 삭제해야 한다. 나같은 경우는 telegram, vk를 지웠다. rss 같은 경우에는 gatsby-plugin-feed 플러그인이 생성해주기 때문에 /rss.xml로 작성했다. 트위터와 GitHub 같은 경우에는 아이디만 작성하면 된다.

이 테마는 댓글로 Disqus도 사용할 수 있는데, disqusShortname에 Disqus를 등록할 때 쓴 이름을 넣어주면 된다. 자세한 가이드는 여기에서 확인할 수 있다.

화면 구성은 React 컴포넌트로 되어 있으므로, React 개발자 도구를 켜고 잘 찾아보면 된다. 스타일시트는 scss로 작성되어 src/assets/scss에 전역 스타일이 있고 컴포넌트 별로 디렉토리에 자체 스타일이 분리되어 있다. 테마에서는 Roboto를 사용하는데 난 Lato로 바꾸고, 코드 블럭에 쓰려고 Fira Mono를 추가했다. layouts/index.jsx를 열어보면 typeface-roboto를 불러오는 부분이 있는데, typefaces 저장소를 이용하고 있어서 같은 방식으로 폰트를 설치하고 추가했다.

내가 선택한 테마에는 gatsby-plugin-offline이 적용되어 있어서 별도의 작업을 하지 않아도 ServiceWorker가 적용된다. 이 외에도 Gatsby에 적용할 수 있는 여러가지 플러그인들이 있다. 가령 내 경우에는 gatsby-plugin-google-analytics를 추가해서 별 고생없이 구글 애널리틱스를 적용할 수 있었다. 장점을 한가지 발견한 것 같다.

새 글 작성하기

곧 새 글을 쓰려니 단점이 나왔다. 새 글을 작성할 때 마크다운 문서를 자동으로 생성해주는 기능 따위가 없다. 왜 없냐는 이슈에 일단 그런 건 계획 없다는 답변이 있다. 일단 고대의 마법인 복사-붙여넣기를 시전하고 잘 수정해준다. 이슈를 잘 읽어보면 gatsby-utils와 create-gatsby-blog-post가 소개되어 있는데 디렉토리 하나 만드는 것은 대수롭지 않으므로 일단 수동으로 했다. ~~이랬다, 저랬다.~~

빌드와 배포

빌드와 배포는 튜토리얼에 잘 설명되어 있다. 튜토리얼에서는 Surge를 사용해서 배포한다. 요즘 GitHub Pages 말고도 이렇게 무료로 정적 웹사이트 호스팅 하는 서비스들이 있는데 써본 적이 없으니 한번 써보기로 했다. 처음에는 React 공식문서도 쓰고 있다는 Netlify에 관심이 있었는데, Gatsby가 안내하는 Surge가 매우 단순해보여서 이쪽으로 실행해보기로 했다. 먼저 Gatsby에서 빌드를 실행한다.

$ gatsby build

빌드를 마치면 public 디렉토리에서 빌드를 마친 정적 리소스를 확인할 수 있다. Surge를 사용하는 과정은 웹사이트에서 소개하고 있다. NPM 모듈을 설치하고 실행하면 터미널에서 가입과 로그인을 할 수 있다. 아래에서 public은 업로드 할 정적 리소스가 있는 디렉토리이다.

$ yarn global add surge
$ surge public

가입을 마치자 마자 바로 배포가 진행된다. Surge에서 제공하는 도메인 이름도 수정할 수 있다. 그 외에 별도로 구입한 도메인에 CNAME을 이용해서 쓰는 방법도 있다. 도메인을 GoDaddy에서 구매했는데, @으로 CNAME 지정이 되지 않아 가이드에 있는 A 레코드를 설정하기는 했다. 테스트하면서 Surge에 올린 다른 페이지는 surge list 명령으로 조회하고 surge teardown {domain}.surge.sh를 실행하면 삭제할 수 있다.

그런데 ServiceWorker를 사용하려면 SSL을 적용해야 하는데, Surge는 별도 도메인에 대한 SSL 적용은 유료로 지원한다. 이런 이유로 다시 Netlify를 확인해보니 무료 계정에 도메인을 따로 사용해도 SSL을 무료로 제공하고 있다. 심지어 복잡한 설정도 없이 클릭 몇 번이면 해결되었다. 가입도 GitHub 계정으로 가능하기 때문에 일사천리로 진행할 수 있었다. 방법은 큰 차이가 없다.

$ yarn global add netlify-cli
$ cd public
$ netlify deploy

netlify-cli를 설치하고 배포 명령을 실행한 후 터미널의 질문에 잘 답변해주면 된다. 도메인과 HTTPS 적용은 문서에 설명되어 있다. HTTPS의 경우에는 배포 후에 브라우저로 접속해서 해당 사이트의 Settings - Domain Management에서 적용할 수 있다.

그나저나 점심을 먹고 나서 처음 gatsby new blog ...를 실행했는데 저녁시간이 되어 버렸다. 과연 내가 계속해서 이 블로그를 잘 쓸 수 있을까? 허허허허허.