프로그래밍 요람에서 무덤까지

[ Provisioning ] 프로비저닝 의 의미

권윤학 — Sat, 14 Jul 2018 15:25:19 +0900

프로비저닝 은 인프라 에서 자주 나오는 용어로 사전적인 의미로는 공급, 준비, 대비, 식량 이란 의미로 IT 에서 의미는 특정 서비스를 제공받기 위하여 서비스 실행부터 시작해 서비스를 제공받기 전 단계까지 처리되는 일련의 절차를 말한다.(위키백과)

즉 사용자 혹은 비지니스 요구사항에 맞게 할당, 배치, 배포하여 시스템을 사용가능하도록 준비하는 절차를 뜻합니다.

프로비저닝은 아래의 내용으로 구분됩니다.

서버 자원 프로비저닝

서버의 CPU, Memory 등의 자원을 할당 또는 적절하게 배치하여 운영이 가능하도록 준비하는걸 서버 자원 프로비저닝이라고 합니다.

OS 프로비저닝

OS 를 서버에 설치하고, 구성 작업을 해서 OS가 동작 가능하도록 준비해두는걸 OS 프로비저닝이라고 합니다.

소프트웨어 프로비저닝

소프트웨어(WAS, DBMS, 어플리케이션 등) 를 시스템에 설치 배포하고 필요한 구성 셋팅 작업을 해서 실행 가능하도록 준비하는걸 소프트웨어 프로비저닝이라고 합니다.

스토리지 프로비저닝

낭비되거나 사용되지 않는 스토리지를 식별하고 공통 풀에서 옴긴 후 스토리지에 대한 요구가 접수 되면 관리자는 공통 풀에서 스토리지를 꺼내 사용 효율성을 높일 수 있는 인프라 구축 가능하도록 하는걸 스토리지 프로비저닝이라고 합니다.

계정 프로비저닝

신입사원이 입사하거나 조직내에서 인사 이동을 하거나 직무변경이 발생해 사용자가 접근하는 자원(Resource)의 범주가 변경되었을 때 HR담당자와 IT관리자는 승인절차 밟은 후 e-mail ,그룹웨어 ,ERP등 다양한 어플리케이션에 필요한계정을 생성하거나 접근권한을 변경해주데, 이러한 일련의 과정을 계정 프로바이저닝이라고 합니다.

[ Docker ] dangling image ( 이름 없는 이미지 / none 이미지 / <none>:<none> 이미지) 제거

권윤학 — Wed, 20 Jun 2018 22:18:24 +0900

Docker 를 사용하다 보면 위와 같이 <none>:<none> 이미지들이 쌓이는데 ( 이미지 생성과정에서 에러가 발생되면 쓸모없는 none 이미지가 남게됩니다. ) 이러한 이미지들을 한번에 정리할려고 하면 아래와 같이 명령어를 입력하면 됩니다.

docker rmi $(docker images -f "dangling=true" -q)

혹은 단 prune 를 사용할 경우 -a 옵션을 붙이면 사용하지 않는 이미지를 전부 삭제하기 때문에 -a 옵션 주의하시기 바랍니다.

또한 prune 명령어는 Docker API 1.25 이상부터 지원됩니다.

docker image prune

[ AWS Lambda ] AWS Lambda 에서 Timezone 설정

권윤학 — Mon, 11 Jun 2018 21:02:00 +0900

AWS Lambda 에서 현재 시간 혹은 현재 날짜를 이용할려면 Timezone 을 변경해야하는데, Lambda 는 기본적으로 Timezone 이 UTC 시간 입니다.

만약 Asia/Seoul 로 변경하고 싶다면 아래와 같이 처리하면 됩니다.

nodejs

process.env.TZ = 'Asia/Seoul';

golang

 os.Setenv("TZ", "Asia/Seoul")

python

os.environ['TZ'] = 'Asia/Seoul'

[ Electron ] Tray Menu 가 사라지는 현상

권윤학 — Mon, 11 Jun 2018 00:13:48 +0900

Electron 으로 Desktop 앱을 만드는 과정에서 자꾸 Tray 아이콘이 사라지는 현상이 발생하는 경우가 있는데, 이런 경우는 아래와 같이 수정하면 대부분 해결됩니다.

해당 코드를...

const {app, Tray} = require('electron');
app.on('ready', () => {
  const tray = new Tray('/path/to/icon.png');
  tray.setTitle('hello world');
});

아래와 같이 수정

const {app, Tray} = require('electron');
let tray = null;
app.on('ready', () => {
  tray = new Tray('/path/to/icon.png');
  tray.setTitle('hello world');
});

tray 변수가 가비지 컬렉터로 인하여 메모리 정리되어 발생하는 과정이라는데, 애초에 예시 코드를 두번째 처럼 줬으면 저 현상으로 많은 사람들이 삽질을 안했을 것 같은데 왜 예시를 수정 안하는지는 모르겠다.

해당 내용은 electron FAQ 에 있는 내용입니다.

[ Elasticsearch ] keyword 와 text (string 타입)

권윤학 — Sat, 2 Jun 2018 18:35:14 +0900

Elasticsearch 에는 여러 데이터 타입이 있지만, 그 중 String 타입은 5.0 부터 text 와 keyword 로 분리되었습니다.

- text: 설명 혹은 길이가 긴 텍스트가 있는 필드에서 전문 검색(full-text) 가 필요한 경우이며, 색인 전에 분석(analyze)을 거쳐 전문 검색(full-text) 에 활용됩니다.

- keyword: 문자열 필드 분석(analyze)이 가능한 타입이며, 해당 타입은 정렬 / 필터링 / 집계 기능을 지원합니다.

각각 데이터 타입은 5.0 이전 버전에서는 analyzed 와 not_analyzed 로 지원되던 기능입니다.

version < 5.0 (이전) text 타입

{
  "foo": {
    "type" "string",
    "index": "analyzed"
  }
}

version >= 5.0 (이후) text 타입

{
  "foo": {
    "type" "text",
    "index": true
  }
}

version < 5.0 (이전) keyword 타입

 {
  "foo": {
    "type" "string",
    "index": "not_analyzed"
  }
}

version >= 5.0 (이후) keyword 타입

{
  "foo": {
    "type" "keyword",
    "index": true
  }
}

전문 검색(full-text) 이 필요 없는 필드는 되도록 keyword 타입으로 사용하는게 좋습니다. (되도록 필드는 직접 매핑)

[ Laravel ] Laravel 5.6 에서 변경되는 사항

권윤학 — Thu, 8 Feb 2018 10:30:09 +0900

Laravel 의 새로운 major 버전인 5.6 버전이 한국시간 2018-02-08 새벽 0시 36분에 Release 되었습니다. 이번 버전에는 어떠한 변경사항들이 있는지 살펴보도록 하겠습니다. 모든 변경사항은 changelog(Github) 를 참고하시기 바랍니다.

또한 5.6 버전으로 업데이트를 하실 경우 Laravel 공식 홈페이지에 있는 마이그레이션 가이드를 참고하시기 바랍니다.

PHP 지원 버전 변경

Laravel 5.6 버전부터는 PHP 7.1.3 버전 이상만 지원하도록 변경되었습니다. 지난 Laravel 5.5 버전부터 PHP 7 버전 이상부터 지원하도록 변경되었으며, 버전 변경 이유는 뒤에 소개하겠지만 의존하는 sympony 프레임워크의 버전업데이트로 발생한듯 합니다.

의존성 패키지 변화

Laravel 프레임워크는 여러 패키지 의존하여 만들어졌습니다.

- Symfony ~4.0

대표적인 의존성 패키지로 Symfony 프레임워크가 있습니다. Laravel 에서 사용하는 Symfony 버전이 ~4.0 으로 변경되었습니다. 이러한 이유로 Laravel 5.6 으로 마이그레이션을 하실 때 프로젝트에서 Symfony 프레임워크를 직접 포함시켜 사용하고 있다면 버전을 변경해야합니다. Symfony 프레임워크 4.* 의 자세한 변경사항은 링크에서 확인가능합니다.

- PHPUnit ~7.0

PHPUnit 은 프레임워크에 상관없이 많은 프로젝트에서 테스트를 위해 사용하고 있습니다. Laravel 5.6 부터는 phpunit ~7.0 버전을 사용합니다.

- cron-expression ~2.0

cron-expression 은 PHP 에서 Crontab 설정을 읽어 이전에 실행한 시간과 다음에 실행될 시간을 계산하여 Cron의 실행여부 등을 판단 할 수 있도록 도와주는 패키지입니다. Laravel 에서 사용되던 cron-expression 이 1.* -> 2.* 으로 변경되었습니다.

그외에 Laravel 에서 관리하는 패키지들의 버전 변경사항이 아래와 같이 발생되었습니다.

- Dusk (~3.0 로 업그레이드)

- Passport (~5.0 로 업그레이드)

- Scout (~4.0 로 업그레이드)

Artisan Command

Laravel 에서 제공되는 Artisan 명령어에도 일부 변경사항이 있습니다.

- optimize 커맨드 삭제

아래의 그림처럼 Laravel 5.4 까지 존재하던 optimize 커맨드가 5.5 에서 deprecated 되었으며, 5.6 에서 완전히 삭제되었습니다.

만약 위와 같이 composer.json 에 php artisan optimize 명령어가 포함되어 있으면 삭제를 하셔야합니다.

- make:controller 커맨드에 --api 옵션 추가

controller 생성 커맨드에 --api 옵션이 추가되었습니다. 이전에 사용되던 --resource 옵션 대신 생겼으며, 해당 옵션으로 생성시 아래와 같이 controller가 생성됩니다.

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class ApiController extends Controller
{
    /**
     * Display a listing of the resource.
     *
     * @return \Illuminate\Http\Response
     */
    public function index()
    {
        //
    }

    /**
     * Store a newly created resource in storage.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function store(Request $request)
    {
        //
    }

    /**
     * Display the specified resource.
     *
     * @param  int  $id
     * @return \Illuminate\Http\Response
     */
    public function show($id)
    {
        //
    }

    /**
     * Update the specified resource in storage.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  int  $id
     * @return \Illuminate\Http\Response
     */
    public function update(Request $request, $id)
    {
        //
    }

    /**
     * Remove the specified resource from storage.
     *
     * @param  int  $id
     * @return \Illuminate\Http\Response
     */
    public function destroy($id)
    {
        //
    }
}

Blade

Blade 는 라라벨에서 제공되는 View 용 template 입니다. Blade 는 총 3가지의 변경사항 있습니다.

- @csrf / @method directive 추가

Laravel 5.5 까지는 제공되는 csrf 토큰과 form 전송시 hidden 값으로 method 명을 보내기 위해 아래와 같이 사용했었습니다.

<form>
  {{ csrf_field() }}
  {{ method_field('PUT') }}
  <!-- ... -->
</form>

하지만 Laravel 5.6 부터는 아래와 같이 사용이 가능합니다.

<form>
  @method('put')
  @csrf
  <!-- ... -->
</form>

- component aliases 추가

컴퍼넌트를 쉽게 불러올 수 있도록 별칭기능이 추가되었습니다. resources/views/components/alert.blade.php 에 Blade 파일이 존재할때 AppServiceProvider 의 boot 메서드 안에 아래와 같이 작성할 경우 components.alert 를 alert 지정하여 불러올 수 있습니다.

Blade::component('components.alert', 'alert');

지정된 별칭을 이용하여 렌더링이 가능합니다.

@component('alert')
    You are not allowed to access this resource!
@endcomponent
// 혹은 component 안에 slot 이 없는 경우는 아래와 같이 directive로 사용이 가능합니다.
@alert
    You are not allowed to access this resource!
@endalert

- double_encode 기본값 true 로 변경

`e` helper method 와 Blade 표현식에서 htmlspecialchars 함수 double_encode 설정의 기본값을 false에서 true 로 변경하였습니다. 이 내용은 이중 인코딩이 된다는 의미이며, 아래의 코드를 보시면 htmlspecialchars 함수의 double_encode 값에 따라 어떻게 인코딩되는지 확인 가능합니다.

만약 이전버전 처럼 double encode 를 안하길 원하면 서비스프로바이더에 아래와 같이 Blade::withoutDoubleEncoding()를 실행시켜주시면 됩니다.

<?php

namespace App\Providers;

use Illuminate\Support\Facades\Blade;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Blade::withoutDoubleEncoding();
    }
}

Logging

이번 Laravel 5.6 변경사항 중 가장 큰 변경사항이라고 생각듭니다. laravel/framework 에서 Log 디렉토리를 살펴보면 아래와 같이 버전간의 차이점이 존재합니다.

5.5

5.6

- config/logging.php 추가

Laravel 5.5 까지 log에 대한 설정은 config/app.php 위치에 있는 log 와 log_level 설정뿐이였습니다. Laravel 5.6 부터는 config/logging.php 파일로 별도로 설정하도록 변경되었습니다. logging.php 파일은 기본적으로 다음과 같습니다.

- Illuminate\Log\Writer 클래스 변경

Illuminate\Log\Writer 클래스가 Illuminate\Log\Logger 클래스로 변경되었습니다. 만약 기존에 Writer 클래스를 Type Hint로 사용하고 있었다면 Psr\Log\LoggerInterface 클래스로 변경하셔야합니다.

- Illuminate\Contracts\Logging\Log Interface 제거

Illuminate\Contracts\Logging\Log Interface 가 제거되었습니다. 만약 기존에 Log Interface 를 Type Hint 로 사용하고 있었다면, Psr\Log\LoggerInterface 클래스로 변경하셔야합니다.

Argon2i 암호 Hash 기능 추가

Argon2 은 2015 년 PHC(Password Hashing Competition) 우승 알고리즘입니다. Argon2 은 아래의 3가지 버전이 존재한다고 합니다.

- Argon2d : GPU 크래킹 공격에 초첨을 맞춘 버전입니다.

- Argon2i : 측면 채널 공격에 저항 할 수 있도록 최적화되어 있습니다.

- Argon2id : Argon2d 와 Argon2i 의 하이브리드 버전입니다.

2017 년 11월 Release 된 PHP 7.2 에 Argon2d 와 Argon2i 가 추가되었으나, Laravel 5.6 에서는 Argon2d 가 Password Hash 기능으로는 적합하지 않아 Argon2i 만 Password Hash 기능으로 추가되었다고 합니다.

Argon2 Hash 를 사용할려면 새로 추가된 config/hashing.php 에서 설정을 변경하시면 됩니다.

그외의 변경사항들

그 외에 여러가지 변경사항이 존재합니다. 자세한 사항은 Laravel CHANGELOG 와 Laravel 5.6 Upgrade Guide 그리고 Laravel News 에서 확인 가능합니다.

[ 개발도서 ] 개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴

권윤학 — Sat, 3 Feb 2018 16:30:57 +0900

도서정보

저자 : 최범균

출판일: 2013-07-05

페이지: 264 쪽

ISBN: 9788969090010 (8969090010)

도서소개 [링크](인투북스)

리뷰

이 책은 객체지향을 공부해야한다면 추천되는 책 중 하나입니다. 저는 객체지향과 거리가 먼 개발자 중 한명입니다. 실무와 개인 프로젝트 그리고 공부를 하는 과정에서 객체지향 개념을 다시(대학교 이후 관심없었음) 공부해야겠다는 생각이 들어 최근에 구매하였습니다.

신입 자바 개발자분들은 반드시 읽길 추천드리며, 또한 객체지향에 대해 입문을 하고 싶은 분들에게도 추천드립니다. 이 책에는 Gof Design Pattern 에 나오는 디자인 패턴 중 11개의 디자인 패턴만 소개하고 있어 만약 객체지향이 목적이 아니라 디자인 패턴을 자세히 공부하고자 구매하시는 분들은 이 책과 다른 책 한권 더 구매를 하셔야 할듯 합니다.

책에서 소개되는 소스코드는 자바 코드이지만 자바를 잘 몰라도(저 같은 분들) 어느정도 이해가 되는 코드라고 생각합니다.

이 책을 읽는다고 객체지향적인 코드를 작성을 하긴 어렵겠지만, 적어도 객체지향적인 사고를 시도할 수 있도록 많은 도움을 주는 책이라고 생각합니다.

[ 번역으로 배우는 영어 ] non-exhaustive list

권윤학 — Fri, 22 Dec 2017 23:43:31 +0900

non-exhaustive list

exhaustive 는 사전적인 의미로 철저한 이라는 의미다.

철저하지 않은 목록? 불완전한 목록? 어색해서 조금 찾아보니 대략적인 목록 이라는 해석이 제일 무난해 보인다.

[ 번역으로 배우는 영어 ] out of the box

권윤학 — Fri, 22 Dec 2017 23:36:08 +0900

out of the box

번역을 하다보면 간혹 보이는 문장인데, 아래와 같이 크게 두가지 의미가 존재합니다.

1. 기존 틀을 깨는 사고(생각) / 아이디어

2. 설정(설치) 없이 즉시 사용이 가능한

Out-of-the-box features include:

(기본 제공 기능은 다음과 같습니다.)

[ Docker ] Laradock 프로젝트를 이용하여 Laravel 로컬 개발 환경 구축

권윤학 — Thu, 21 Dec 2017 01:29:07 +0900

이 글은 Docker와 docker-compose를 알고 있다는 전제하에 설명을 하고 있습니다.

Docker 가 생소하다면 여기 김충섭 님의 글을 먼저 읽어 보시길 추천합니다.

Docker 는 리눅스 컨테이너 기반의 오픈소스 가상화 플랫폼입니다.

Docker 를 이용하면 로컬 개발 환경을 다른 사람과 동일하게 구성할 수 있으며, 이걸 그대로 서비스에 올릴 수 있다는게 가장 큰 장점 뽑을 수 있습니다. Laravel은 이러한 로컬 개발 환경을 위해 H omestead / Valet 같은 환경을 같이 제공해 줍니다. 즉 Docker 를 사용하지 않아도 훌륭한 로컬 개발 환경을 구축 할 수 있습니다. 하지만 실제 서비스 환경까지 생각한다면 Docker 는 좋은 선택이 될 수 있습니다.

Laravel 로 프로젝트를 진행하게 되면 기술 스택은 다양하게 구성이 가능합니다.

DB같은 경우도 MYSQL 를 쓸수도 있고 mariaDB 를 사용할 수 있으며, 아니면 NOSQL인 mongodb 를 사용 할 수도 있습니다. 서버 또한 NGINX or Apache 같은 선택 사항이 있으며, 세션을 위해 redis 같은 메모리 기반 NOSQL 사용해야 할 수 도 있습니다.

이러한 사유로 Docker를 이용할려고 환경 작업하던 중 잘만들어진 오픈 소스 프로젝트가 있지 않을까 라는 생각으로 레퍼런스용으로 찾아보니 Laradock 이라는 프로젝트가 눈에 띄었습니다.

Laradock 프로젝트 특징

우리는 바퀴를 모두 만들 필요가 없습니다. 잘 만들어진 프로덕트가 있다면 그걸 잘 활용하는 것도 중요하기에 Laradock 프로젝트를 살펴보았습니다. 다양한 설정이 가능하도록 구성이 되어있으며, 관련하여 문서도 잘 준비되어 있습니다.

Laradock은 아래 사항들을 지원하고 있습니다.

Database Engines: MySQL - MariaDB - Percona - MongoDB - Neo4j - RethinkDB - MSSQL - PostgreSQL - Postgres-PostGIS.

Database Management: PhpMyAdmin - Adminer - PgAdmin

Cache Engines: Redis - Memcached - Aerospike

PHP Servers: NGINX - Apache2 - Caddy

PHP Compilers: PHP FPM - HHVM

Message Queueing: Beanstalkd - RabbitMQ - PHP Worker

Queueing Management: Beanstalkd Console - RabbitMQ Console

Random Tools: HAProxy - Certbot - Blackfire - Selenium - Jenkins - ElasticSearch - Kibana - Grafana - Mailhog - MailDev - Minio - Varnish - Swoole - Laravel Echo…

이렇게 다양한 환경을 작동시키기 위해 여러가지 설정들이 존재합니다.

php Xdebug 모듈을 설치할지 여부라던가 workspace에 Composer를 설치여부 / Node.js를 설치여부 / Yarn 패키지 매니저를 설치여부 등을 작업자에 맡게 설정이 가능하게끔 .env 파일과 docker-compose.yml 그리고 각 컨테이너의 Dockerfile에 반영이 되어 있습니다.

예를들어 Xdebug의 경우 아래와 같이 반영되어 있습니다.

## .env file
### XDEBUG 사용여부 ##########################
USE_XDEBUG=true

## docker-compose.yml
workspace:
  build:
    context: ./php-fpm
    args:
      - INSTALL_XDEBUG=${USE_XDEBUG}
php-fpm:
  build:
    context: ./php-fpm
    args:
      - INSTALL_XDEBUG=${USE_XDEBUG}

# Dockerfile (php-fpm / workspace)
# xDebug:

ARG INSTALL_XDEBUG=false
RUN if [ ${INSTALL_XDEBUG} = true ]; then \
    # Install the xdebug extension
    pecl install xdebug && \
    docker-php-ext-enable xdebug \
;fi

COPY ./xdebug.ini /usr/local/etc/php/conf.d/xdebug.ini

workspace 컨테이너 같은 utility 컨테이너 제공: workspace 라는 컨테이너를 통해 composer 명령이나 npm 명령들을 node.js 와 php / composer 설치 없이 가능하도록 제공하고 있습니다. 그리고 workspace 에서 자주 사용될 command를 alias 로 적용하기 위해 shell script를 추가되어 있습니다.

# aliases.sh
alias artisan="php artisan"
alias migrate="php artisan migrate"

# Dockerfile (workspace)
COPY ./aliases.sh /home/user/aliases.sh
USER root
RUN echo "" >> ~/.bashrc && \
echo "# Load Custom Aliases" >> ~/.bashrc && \
echo "source /home/user/aliases.sh" >> ~/.bashrc && \
echo "" >> ~/.bashrc && \
sed -i 's/\r//' /home/user/aliases.sh && \
sed -i 's/^#! \/bin\/sh/#! \/bin\/bash/' /home/user/aliases.sh

xdebug / phpcs 원격 설정 사용 : phpstorm에서 ssh 접속을 이용하여 xdebug 원격 설정을 위해 ssh key를 미리 생성해두고 해당 ssh key를 workspace 컨테이너에 등록이 가능하도록 되어 있습니다.

# Dockerfile (workspace)
# ssh:

ARG INSTALL_WORKSPACE_SSH=false
ENV INSTALL_WORKSPACE_SSH ${INSTALL_WORKSPACE_SSH}

ADD insecure_id_rsa /tmp/id_rsa
ADD insecure_id_rsa.pub /tmp/id_rsa.pub

RUN if [ ${INSTALL_WORKSPACE_SSH} = true ]; then \
    rm -f /etc/service/sshd/down && \
    cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys \
        && cat /tmp/id_rsa.pub >> /root/.ssh/id_rsa.pub \
        && cat /tmp/id_rsa >> /root/.ssh/id_rsa \
        && rm -f /tmp/id_rsa* \
        && chmod 644 /root/.ssh/authorized_keys /root/.ssh/id_rsa.pub \
    && chmod 400 /root/.ssh/id_rsa \
;fi

이 부분은 로컬 PC에 PHP를 설치 안하고도 Xdebug와 php_cs를 phpstorm 같은 ide랑 연결이 가능하기 위해 추가되어있습니다.

source volume 사용: 여러개의 컨테이너에서 source code가 필요합니다. (Worker 에서도 소스가 필요하고 NGINX 에서도 소스가 필요)

이러한 경우 docker voulme 을 만들어서 컨테이너에 마운트하여 공유하는 방법도 있지만,

voulmes_from 옵션을 이용하여 컨테이너의 마운트된 볼륨을 공유하는 방법이 있습니다.

laradock은 이러한 방식을 사용하고 있습니다. (voulmes_from 컨테이너로 많이 쓰이는 tianon/true 이미지 사용)

대략 아래와 같은 개념으로 마운트를 한다고 생각하시면 됩니다.

PHP 버전를 동적으로 변경가능: 사용할 PHP의 버전을 언제든지 변경이 가능하도록 아래와 같이 설정되어 있습니다.

# docker-compose.yml
php-fpm:
    build:
      context: ./php-fpm
      dockerfile: "Dockerfile-fpm-${PHP_VERSION}"

## 폴더구조 
+php-fpm
  Dockerfile-fpm-71
  Dockerfile-fpm-70
  Dockerfile-fpm-56

## .env
### PHP version ################
# 사용가능한 값: 71 - 70 - 56
PHP_VERSION=71

그외에 다양한 환경을 제공하고 있습니다. 자세한 사항은 laradock 문서에서 확인 가능합니다.

Laradock 적용하기

Laradock 으로 프로젝트를 띄우는 방법으로 크게 2가지 경우가 있습니다.

- 단일 프로젝트에 적용하기

- 여러개의 프로젝트에 적용하기

Application Container(Source volume)의 볼륨 마운트 경로를 설정이 가능하도록 되어있어 단일 프로젝트이든 여러개의 프로젝트이든 보통 프로젝트 구조는 아래처럼 설정을 하게됩니다.

+ project
+ laradock
## or
+ projectA
+ projectB
+ laradock

Application Container의 경로 설정은 .env 파일에 보면 아래와 같이 변경이 가능합니다.

만약 .env 파일이 없으시면 env-example 파일을 복사하여 .env파일로 생성해주세요.(.env파일은 docker-compose에서 기본적으로 환경설정 파일로 사용됩니다.)

APPLICATION=../

그 이후 nginx/sites 경로에 nginx 가상호스팅 설정 파일을 추가하여 프로젝트에 해당하는 가상 도메인들을 설정하시면 됩니다.

이때 설정하는 가상호스트에 .dev 도메인을 사용하지 않는 편이 좋습니다.(chrome 63 버전 이후부터 .dev 도메인은 강제로 https로 전환됩니다. 관련링크)

docker 실행

Laradock은 docker-compose 파일을 제공해주고 있어서 docker-compose 명령을 이용하여 여러개의 컨테이너를 쉽게 실행 시킬 수 있습니다.

만약 nginx와 mariadb를 실행시킬거면 아래와 같이만 명령하시면 됩니다.

docker-compose up -d nginx mariadb

반대로 실행시켰던 컨테이너들을 종료시키기 위해선 아래의 명령으로 종료가 가능합니다.

docker-compose down

마무리

Laradock은 정말 편리합니다. 하지만 마치 네가 무엇을 좋아하는지 몰라서 전부 준비해봤어 라는 느낌이 강해서 프로젝트와 상관없는 내용이 많다보니 불필요한 내용 그리고 불편했던 사항들이 제법 많았습니다.

다음 글에는 현재 프로젝트에 적용하기 위해 변경하고 수정했던 내용을 적어볼까 합니다.

(사실 다 적고보니 굉장히 두서없는 글이 나와버려서 당분간 포스트 수정부터 하지 않을까 싶습니다.)

[ Angular ] Angular 에 Parcel bundler 를 적용해 보았다.

권윤학 — Sat, 16 Dec 2017 00:48:26 +0900

최근 프론트엔드 커뮤니티에서 엄청나게 뜨거운 녀석이 등장했습니다. 1주 동안( 12. 10 ~ 12. 16) github star 4000개 이상을 받은 번들러가 등장한 것인데요.

바로 parcel 입니다. (글 작성한 2017-12-15 일 기준으로 parceljs 사이트가 한글 번역 되었습니다.)

[github trend에서 1주 기준 모습] 무려 4163스타를 한주동안 받았다고 합니다.

Grunt 에서 Gulp로 그리고 최근에는 Webpack 을 쓰고 있는데 또?? 라는 생각이 제일 먼저 들기 시작했습니다.

어떤놈인지 찾아보니 설정없이 Webpack보다 빠른 번들러라고 소개하고 있습니다.

설정이 필요없다고?? 알아서 bundle이 되는건가??

궁금한 생각에 한번 angular-cli 로 생성되는 app을 parcel로 작업해보았습니다.

문서를 읽어봤을때는 Typescript에 대한 내용이 전혀 없었으며, 따로 플러그인이 있다는 내용도 없어서 찾아보니 typescript plugin이 있었습니다.

그럼 Angular를 작동시키는데는 문제가 없다 판단하여 작업을 시작하였습니다.

1. 프로젝트 생성

먼저 angular-cli를 이용해서 angular 프로젝트를 생성하였습니다.

ng new angular-parcel-example --style=scss --routing

angular-cli로 프로젝트를 생성하는 이유는 설정 없이도 angular-cli 에서 제공되는 기능과 얼마나 비슷하게 사용할 수 있을지 궁금했습니다.

2. parcel bundler 설치

그 다음은 parcel를 설치해야 합니다. 전역 설치를 해도 되지만 저는 local 설치로 진행하였습니다.

yarn add parcel-bundler parcel-plugin-typescript@0.2.0-angular.0 --dev
or
npm i parcel-bundler parcel-plugin-typescript@0.2.0-angular.0 --save-dev

3. package.json의 script 명령어 수정

angular-cli로 serve 및 build를 하던 명령어들을 parcel로 변경해야합니다. 아래와 같이 변경하시면 됩니다.

"scripts": {
  "ng": "ng",
  "parcel": "parcel",
  "start": "parcel ./src/index.html",
  "build": "parcel build ./src/index.html"
}

4. index.html 수정

parcel은 웹앱의 진입점(여기선 index.html)에서 상대경로로 불러오는 파일들을 자동으로 bundle하는 방식입니다. 그렇기 때문에 .angular-cli.json 파일에서 설정되었던 main.ts와 polyfills.ts를 index.html에서 불러오는 처리를 추가해야 합니다.

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "project": {
    "name": "angular-parcel"
  },
  "apps": [
    {
      "root": "src",
      "outDir": "dist",
      "assets": [
        "assets",
        "favicon.ico"
      ],
      "index": "index.html",
      "main": "main.ts",
      "polyfills": "polyfills.ts",
      ...
    }
  ],
  ...
}

아래와 같이 index.html를 수정해주세요.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>AngularParcel</title>
  <base href="/">

  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/x-icon" href="favicon.ico">
</head>
<body>
  <app-root></app-root>
  <!--해당 부분이 추가-->
  <script src="polyfills.ts"></script>
  <script src="main.ts"></script>
</body>
</html>

여기까지 작업이 되었다면 실행이 가능합니다.

yarn start
or
npm start

문제 없이 성공하였다면 localhost:1234로 접속하여 확인하시면 됩니다.

parcel도 webpack과 마찬가지로 hmr이 지원되고 있습니다. hmr의 경우 아무런 설정없이 적용이 되고 있습니다.

여기까지 봤을때는 확실히 parcel 이 주장하는 빠른 빌드와 zero config(설정없는) 번들러가 충분히 매력적입니다.

하지만 angular-cli 에서는 다양한 기능을 제공해주고 있습니다. ( serviceWorker / e2e test / generate / enviroment 등) 이러한 기능들을 그대로 설정없이는 무리가 있어보입니다.

그럼 angular-cli에서 webpack 대신 parcel로 변경하면 좋지 않나!? 싶은 생각에 찾아봤습니다.

네 지금 당장은 없다고 합니다.

저는 사실 webpack의 빌드 속도가 느릴만큼 큰 프로젝트를 진행하고 있지 않으니 괜찮습니다.

parcel의 비교대상은 webpack 이지 angular-cli 는 아니긴 합니다.

webpack 과 비교하면 처음 webpack이 어렵게 느껴졌던 설정 부분 없이도 쉽게 bundle이 가능하고 속도 또한 눈에 띄게 빠르다는 점은 매우 좋은 것 같습니다.

하지만 아직 나온지 얼마안되서 문서가 비약한점은 아쉽네요. 특히 플러그인쪽 문서는 너무 빈약합니다.

angular가 아닌 다른 프레임워크나 환경을 구성하는 프로젝트가 있으면 parcel로 다시 작업을 해봐야겠습니다.

이 포스팅의 예시는 github 저장소에 공개된 상태입니다. 관련하여 피드백은 언제나 환영입니다.

[ TypeScript ] TS6133 컴파일 에러 ( noUnusedLocals / noUnusedParameters )

권윤학 — Tue, 5 Dec 2017 17:52:24 +0900

TypeScript로 프로젝트를 진행하다보면 처음엔 tsconfig의 컴파일 옵션때문에 당황할때가 많이 있습니다. ( 저만 그런가요^^?;;)

발생되는 에러코드로 검색해보면 원인을 찾아 볼 수 있지만, 워낙 컴파일 옵션이 많아 에러 코드와 함께 하나씩 정리할려고 합니다.

오늘 확인할 에러는 TS6133:'x' is declared but never used. 에러입니다.

해당 에러와 연관된 TypeScript Compiler Option은 아래와 같습니다.

let noUnusedLocals: boolean = '사용되지 않은 지역 변수가 있으면 알려줍니다.';
let noUnusedParameters: boolean = '사용되지 않은 메서드 파라미터가 있으면 알려줍니다.';

기본값은 false입니다.

많이 사용할만한 옵션은 아닌 것 같지만 필요없는 변수를 할당하여 메모리 낭비를 막을 수 있는 좋은 옵션인 것 같습니다.

만약 해당 옵션이 필요없으신 경우 tsconfig.json의 compilerOptions.noUnusedLocals 와 compilerOptions.noUnusedParameters 항목을 지워주시거나 false로 변경하시면 됩니다.

[ Docker ] Docker for Windows 를 이용하여 Docker 사용시 이슈정리

권윤학 — Tue, 31 Oct 2017 23:58:49 +0900

최근 사내에 서버 개발환경을 Docker를 이용하여 로컬 개발방식으로 변경하는 작업을 했었는데, Docker for Windows 를 사용했을때 많은 이슈가 발생되었습니다. Window에서 Docker를 이용할 경우 어떠한 이슈사항들이 있는지 정리해 보았습니다.

필수사항

Docker for Windows를 사용시 발생했던 이슈들은 아래와 같습니다.

- Hyper-V 사용가능 (Windows 10 Professional or Enterprise 64-bit 만 사용 가능)

- CPU 가상화 사용가능(BIOS에서 활성화 해야함)

- Docker Client에서 사용하는 포트 방화벽 해제

- Windows 사용자명에 한글이 있는 경우

1. Hyper-V 사용가능한 윈도우 버전

기본적으로 Docker는 리눅스에서만 동작하다보니 OSX나 Windows에서는 가상머신으로 Docker Host를 띄워서 사용하도록 되어있습니다.

이러한점을 Docker for windows에서는 Hyper-V를 이용하여 해결하고 있습니다.

이 Hyper-V는 Windows Server 2008에 추가되었던 하이퍼바이저 기반 가상화 시스템으로 Windows 8 프로 버전부터 일반 개인용 윈도우에 포함되기 시작했습니다. Docker for Windows 다운로드시 아래와 같은 문구가 있습니다.

* Requires Microsoft Windows 10 Professional or Enterprise 64-bit For previous versions get Docker Toolbox

Windows 10 프로버전 혹은 엔터프라이즈 64비트가 필요합니다. 이전버전의 윈도우 사용자분들은 Docker Toolbox를 이용하여 Docker를 사용해야합니다.

이 글에서는 Docker Toolbox를 이용한 Docker 사용(VirtualBox)에 대해 다루지 않고있습니다.

Windows 10에서 Hyper-V를 활성화 시킬려면 제어판 -> 프로그램 추가/제거 -> Windows 기능 켜기/끄기 에서 Hyper-V를 포함 하위 항목을 모두 체크해 주세요.

2. CPU 가상화 사용가능한지 여부

윈도우 버전이 Hyper-V를 지원하더라도 사용하고 있는 CPU와 메인보드가 가상화를 지원하는지 확인해야 합니다.

Windows 부팅시 BIOS 셋팅에 가시면 아래와 같이 가상화 활성화 여부가 있습니다.

해당 설정을 활성화(Enabled)로 변경하신 후 저장해주시기 바랍니다.

3. Docker Client에서 사용하는 포트 방화벽 해제

Docker는 기본적으로 linux에서만 작동이 가능하다보니 docker for windows / docker for mac 등은 리눅스 가상머신을 설치한 후 리눅스에 Docker daemon을 설치하는 방식으로 구동됩니다. (아래 그림 참고)

이러한 방식을 이용하다보니 Docker client에서 docker host과 통신이 필요한데 여기에서 사용되는 포트가 방화벽으로 막아둘 경우 아래와 같은 에러가 발생될 수 있습니다.(docker file sharing이 안되는 경우)

기본적으로는 445 port를 사용하고 있기때문에 windows 방화벽에서 455 port를 차단했는지 확인하셔야 합니다.

4. Windows 사용자명에 한글이 있는 경우

이건 docker for windows 문제이기 보다 dockerToolbox의 문제입니다.

(사실 사용자명이 한글이면 문제되는 프로그램이 한둘이 아니기 때문에 왠만해선 사용자명은 영어로 사용하세요.)

dockerToolbox는 python으로 만들어졌는데 사용자 계정 폴더가 한글이 포함될 경우 문제가 발생된다. 이 경우는 마소에서도 관리자 계정을 영어로 새로 생성하라고 할 정도로 골치 아픕니다. 구글에서 찾아보면 여러가지 방식이 나오는데 마소에서 정식으로 권고하는 내용이 아니다보니 이 내용은 기재하지 않겠습니다.

* 앞으로 계속 사용하면서 발생되는 이슈들은 포스팅에 업데이트 될 내용이며, 만약이외 다른 이슈가 있다면 댓글로 피드백 주시면 감사하겠습니다.

[ Jetbrains ] WebStorm / PHPStorm / Intellij 버벅거릴때 성능(속도) 향상 시키기

권윤학 — Tue, 31 Oct 2017 19:51:28 +0900

최근 사무PC를 변경하여 PhpStorm을 새로 설치하였는데, Docker 컨테이너를 띄우니 버벅거리는 현상이 발생하였습니다.

?? PC 사양이 안좋나? 하고 생각하던 찰나 Jetbrains IDE가 JVM에서 작동하다보니 JVM 관련 설정을 빼먹은게 생각나 블로그 포스팅으로 남길려고합니다.

상단 메뉴에 Help -> Edit Custom VM Options에 들어가면 아래와 같이 설정을 수정 할 수 있는데

여기에 아래의 값을 입력하면 됩니다.

-Dawt.java2d.opengl=true

- Dsun.java2d.opengl=true

OpenGL을 지원하는 hardware-accelerator 에서 Java 2D 가 OpenGL가속을 사용하도록 합니다.

적용하고나니 버벅거림 현상이 해결되었습니다. 이런 IDE 셋팅은 한번 해두면 건드리지 않는편이다보니 자주 깜빡하는것 같습니다.

[ PHP ] Modern PHP 란?

권윤학 — Sat, 7 Oct 2017 21:22:40 +0900

프로그래밍 언어를 공부하다보면 Modern이라는 키워드가 자주 등장합니다. 사전적인 의미로 현대적인 라는 의미로 최신이라는 의미가 내포되어 있습니다. 현대적인 라는 말은 과거 / 현재의 비교가 필요합니다. 즉 before & after가 필요하다는 얘기입니다. 그럼 현재 얘기되고 있는 Modern PHP란 무엇일까요?

이 글은 아래의 내용들을 참고하여 작성하였습니다.(피드백은 언제나 환영입니다.)

- PHP THE RIGHT WAY

- 2016 GDG Incheon 8월 전창완님 발표자료

- Modern PHP(도서)

- ModernPUG wiki - 모던의 의미

PHP의 과거와 현재

앞서 Modern이라는 용어를 얘기하기 위해서는 과거와 현재가 비교되어야 한다고 했었습니다.

그래서 아주 간단하게 PHP의 변화에 대하여 간단하게 알아보겠습니다.

PHP 업데이트 날짜 및 주요 변경사항과 프레임워크들에 대한 TimeLine입니다. (틀린사항이 있으면 피드백 언제든지 환영합니다.)

PHP는 20년 가까이 많은변화를 겪었으며, 각각 큰변화들이였지만 TimeLine에서 보면 PHP 5.4가 출시되는 2012년부터 본격적으로 활발한 변화가 생겼습니다. HHVM 의 등장 / composer의 추가 / 표준권고 추가(PSR) 등이 PHP를 더욱 빠르게 변화시켰습니다.

PHP의 문제로 얘기되던 성능은 HHVM / HACK 같은 경쟁상대의 등장으로 개선되었으며, composer의 등장으로 컴포넌트 기반으로 작업이 가능해졌습니다. 표준이 없어 각자의 스타일대로 작성되던 코드들이 호환성있고 읽기 쉬워진 코드들로 변화하였습니다.

또한 기존의 PHP가 코드 결과를 예측하기 어려웠던 점을 타입힌팅(Type Hinting)의 강화로 엄격한 코드를 작성하여 예측하기 쉽고 리팩토링이 편한 코드를 작성 할 수 있게 되었습니다.

Modern PHP의 조건

이러한 내용들을 봤을때 저는 Modern PHP를 지향하기 위해서는 아래의 조건들이 성립해야한다고 생각합니다.

- 최신버전의 PHP

- PSR(표준권고) 준수

- 패키지 매니저

PSR(PHP Standards Recommendations) PHP 표준 권고사항 준수

PSR은 PHP-FIG(PHP Framework Interop Group)에서 재정하는 표준권고 사항으로 PSR-1, PSR-2 같은 코딩 스타일 가이드 부터 PSR-3, PSR-6, PSR-7 같은 기능별 인터페이스 그리고 PSR-4 같은 오토로딩 같은 내용까지 포함하고 있습니다. PSR-1, PSR-2의 경우 IDE에서 코드를 검사하여 코딩 스타일을 통일감있게 만들어주며 PSR-4는 composer를 이용할때 이용됩니다.

PSR에 대한 자세한 내용은 제 블로그에 있는 글과 PHP-FIG 사이트 그리고 PHP THE RIGHT WAY에서 확인이 가능합니다.

패키지매니저(composer)

패키지 매니저는 소프트웨어의 버전 및 의존성을 관리해 주고 설치 / 업데이트 / 삭제 등을 쉽게 해주는 시스템을 말합니다. PHP에는 Composer라는 패키지 매니저가 있으며, 다른언어 들도 다음과 같은 패키지 매니저들이 존재합니다.

- node(NPM, YARN)

- ruby(Gem)

- C#(NuGet)

- java(Jpm)

- python(pip)

패키지 매니저를 이용하면 다른사람이 작성한 코드를 쉽게 갔다 쓸 수 있으며, 이 패키지들의 버전 및 의존성 관리도 쉬워지고 작성한 코드들을 컴퍼넌트 단위로 배포도 가능해집니다.

Http 통신 처리를 해야한다면 guzzle를 사용하면되고 Log처리를 해야한다면 Monolog 를 사용하면 됩니다.

이걸 어디서 찾냐고요? https://packagist.org/에서 검색하여 쇼핑하듯 composer로 불러오기만 하면됩니다.

위에서 말했던 패키지들은 각각 PSR-7(HTTP message interfaces), PSR-3(Logger Interfaces)를 준수한 패키지들입니다.

PSR를 준수한 수많은 패키지들이 있으며, 저희는 가장 적합한 컴퍼넌트 혹은 프레임워크를 사용하면 됩니다.

마무리

사실 Modern PHP에 대한 해답은 PHP THE RIGHT WAY에 잘 정리 되어있다고 생각합니다. 그러나 내용도 많으며, 조금 야매적인(?) 요약이 필요하다고 생각해서 이 포스트를 작성하기 시작하였습니다. PHP가 비록 우리나라에서 안좋은 시선이 많지만, Modern PHP는 나쁘지 않다고 생각합니다. 언어라는건 결국 도구이기때문에 적합한 곳에 자기에게 맞는 도구를 사용하는게 중요하다고 생각합니다.

[ AWS ] Amazon Web Service(AWS)의 용어 정리

권윤학 — Fri, 6 Oct 2017 01:24:24 +0900

AWS에는 많은 용어(키워드 / 약어)들은 Network에 지식이 있지 않거나 혹은 관련 지식이 있어도 약어들이 너무 많아 AWS를 처음 접하시는 사람에겐 어렵게 느껴집니다. 저 또한 아직 모르는 내용이 많기에 정리하고자 합니다.

[AWS 공식홈 글로벌인프라](17년.7월 19일 기준)

가장 많이 나오는 용어로는 리전(Region)과 가용영역(Availability Zone 줄여서 AZ) 그리고 엣지로케이션(Edge Location)이 있습니다. 이 용어들은 AWS의 각 서비스 전반적으로 나오는 용어입니다.

리전(Region)

리전은 AWS의 서비스들이 제공되는 서버의 물리적인 위치(지역)을 의미합니다. 위의 그림에 보면 AWS의 리전 분포를 알 수 있는데요.

이렇게 여러개의 리전을 두는 이유는 네트워크 속도가 가장 큰 이유입니다. 우리나라 서버에 있는 서비스를 미국에서 접속하면 아무래도 속도가 느려질 수 밖에 없는데 만약 미국에 서비스해야한다면 미국쪽 리전에 서버를 생성하여 서비스하면 속도면에서 빠르겠죠?

두번째 이유로는 큰 재해를 대비하기 위함이라고 합니다. AWS에서는 기본적으로 장애라는건 발생가능하다고 판단하여 그 장애에 대응하기 위한 여러 서비스들을 제공하고 있습니다. 장애란건 여러가지가 있겠지만 재해(전쟁, 지진, 화재)도 포함이 됩니다. 리전을 여러곳에 둔것도 이러한 재해시 다른 리전으로 서비스가 가능하게끔이라고 하네요.

우리나라에도 서울리전이 2016년 1월에 추가되었으며, 서울리전에는 2개의 가용영역(AZ)이 포함되어 있습니다.

가용영역(Availability Zone - AZ)

위에서 잠깐 언급했던 가용영역은 리전안에 있는 IDC(데이터센터)를 의미합니다. 기본적으로 AWS의 각 리전안에는 2개 이상의 가용영역을 가지고 있으며, 서울리전에는 2개의 가용영역을 가지고 있다는 말은 2개의 독립적인 IDC를 운영하고 있다는 얘기입니다. 이 IDC의 위치는 AWS 내부직원들도 모르며, 각각 위치는 멀리 떨어져서 각종 재해 발생시 다른 가용영역에 서비스를 계속 할 수 있습니다.

AWS에서는 여러개의 가용영역에 서버를 올려 사용하여 로드밸런싱을 통하여 트래픽을 분산시켜 한쪽 가용영역이 작동을 안하더라도 무중단 서비스를 제공하도록 권장하고 있습니다.

엣지 로케이션(Edge Location)

엣지 로케이션은 리전과 가용영역과 별게로 AWS의 CDN 서비스인 CloudFront과 AWS의 DNS 서비스인 Route 53의 캐시 서버를 의미합니다.

CDN과 DNS같은 서비스들의 서버들은 리전과 별게로 여러개의 엣지 로케이션에 적용되어 서비스되고 있으며, 아래는 현재(2017. 10. 04) 기준 엣지로케이션 분포도입니다.(우리나라에는 3개의 엣지 로케이션이 있습니다.)

북미

버지니아주 애슈번(3), 조지아주 애틀랜타(3), 일리노이주 시카고(3), 텍사스주 댈러스/포트워스(3), 캘리포니아주 헤이워드, 플로리다주 잭슨빌, 캘리포니아주 로스앤젤레스(2), 플로리다주 마이애미, 미네소타주 미니애폴리스, 퀘벡주 몬트리올, 뉴욕주 뉴욕(3), 뉴저지주 뉴어크, 캘리포니아주 팔로알토, 펜실베이니아주 필라델피아, 캘리포니아주 산호세, 워싱턴주 시애틀(2), 인디애나주 사우스벤드, 미주리주 세인트루이스, 온타리오주 토론토

리전별 엣지 캐시: 버지니아, 오하이오, 오레곤

유럽

네덜란드 암스테르담(2), 독일 베를린, 아일랜드 더블린, 독일 프랑크푸르트(6), 영국 런던(4), 스페인 마드리드, 프랑스 마르세유, 이탈리아 밀라노, 독일 뮌헨, 프랑스 파리(3), 체코 공화국 프라하, 스웨덴 스톡홀름(2), 오스트리아 비엔나, 폴란드 바르샤바, 스위스 취리히

리전별 엣지 캐시: 독일 프랑크푸르트, 영국 런던

아시아

인도 첸나이, 중국 홍콩(3), 말레이시아 쿠알라룸푸르, 인도 뭄바이(2), 필리핀 마닐라, 인도 뉴델리, 일본 오사카, 대한민국 서울(3), 싱가포르(2), 대만 타이베이, 일본 도쿄(4)

리전별 엣지 캐시: 인도 뭄바이, 싱가포르, 대한민국 서울, 일본 도쿄

호주

호주 멜버른, 호주 시드니

리전별 엣지 캐시: 호주 시드니

남아메리카

브라질 상파울루(2), 브라질 리우데자네이루

리전별 엣지 캐시: 브라질 상파울루

AWS의 주요 서비스 용어 및 약어

AWS에는 많은 서비스가 있으며, 이 서비스들중 주요 서비스(개인적인 의견)들 위주로 정리해보았습니다.

Computing

- EC2(Elastic Compute Cloud): 클라우드 서버 인스턴스, AWS의 가장 대표적인 서비스중 하나입니다.

- ECS(EC2 Container Service): 클라우드 서버인 EC2를 Docker 컨테이너로 관리 가능하도록 나온 서비스(17년 10월 5일 서울리전 출시하였습니다. 갓마존 감사합니다.)

- EB(Elastic Beanstalk): 웹 어플리케이션용 클라우드 플랫폼 서비스(배포, 모니터링, 확장, 관리) 주로 간단한 서비스 배포용으로 사용합니다.

- AWS Lambda: AWS의 클라우드 Function 서비스 서버 없이 작성한 프로그래밍 코드를 실행하는 환경을 제공하는 서비스입니다.(serverless 아키텍쳐 구현에 사용)

- ELB(Elastic Load Balancing):L4 서비스(load balancing) 트래픽을 분산해주는 역활을 하여 고가용성 서비스를 구축할 수 있도록 합니다.

- Auto Scaling: 트래픽에 따라 EC2 인스턴스들을 확장해주는 서비스 위의 ELB와 함께 사용되는 기능으로 특정 트래픽을 초과시 자동으로 EC2 인스턴스를 생성하고 다시 트래픽이 줄어들면 추가 생성하였던 EC2 인스턴스들을 삭제하는 유연한 서비스를 구축할 수 있도록 도와주는 서비스입니다.

- AMI(Amazon Machine Images): AWS에서 제공되는 가상머신 이미지(AWS에서 기본으로 제공하는 이미지일수도 있으며, 다른 유저 혹은 벤더들이 만들어놓은 머신 이미지도 많습니다.)

Storage

- S3(Simple Storage Service): HTTP 프로토콜과 연동되는 스토리지 정적 사이트를 호스팅하는데 사용할 수도 있습니다. 이미지 파일이나 웹 사이트 정적 요소 관리등을 할 수 있으며, 파일 마다 버전관리가 가능합니다.(AWS의 최초 서비스)

- Glacier: 데이터 보관 및 백업용도를 위한 저렴한 스토리지, S3와 다르게 저장에만 특화되어있는 저렴한 스토리지 서비스로 저장하고 꺼내는데 3시간-5시간 걸린다는 특징을 가지고 있다. S3에서 -> Glacier로 백업을 자동 생성하도록 설정이 가능합니다..

- EBS(Elastic Block Store): EC2 인스턴스에 가상하드를 달아주는 서비스로 EC2 인스턴스는 종료되고 재생성될때 기존의 데이터가 유지가 안되지만 EBS를 연결하여 EBS에 파일을 저장한다면 EC2 인스턴스와 관계 없이 영구적으로 보관이 가능합니다.

Networking

- CloudFront: AWS의 CDN 서비스, 리전에 상관없이 엣지 로케이션 기준으로 가장 가까운 곳에서 파일 캐시를 가져오기 때문에 속도도 빠르며 비용도 EC2 혹은 S3로 서비스를 제공하는것 보다 더 저렴하다고 합니다.

- Route 53: AWS의 DNS 서비스, EC2 / ELB 같은 서비스와 결합하여 사용이 가능하며 Route 53으로 L4 혹은 GSLB(Global Server Load Balancing)를 구축 할 수 있다고 합니다.

- VPC(Virtual Private Cloud): 클라우드 가상 네트워크 구축 서비스로서 내부망(VPN)을 구축하거나 서브넷을 나눠 네트워크를 용도별로 관리가 가능하도록 제공합니다.

Database

- DynamoDB: AWS의 NoSQL 데이터베이스 서비스

- RDS(Relational Database Service): RDBMS 클라우드 서비스 Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL Server등을 지원하고 있습니다.

- ElastiCache: Database Caching 서비스.Memcached, Redis 호환을 지원하고 있습니다.

Management Tools

- CloudWatch: AWS 서비스들을 모니터링하거나 알람을 받는 설정들을 할 수 있는 서비스입니다. 특정 금액 초과할 경우 알람을 받거나 EC2의 CPU 사용률등의 알람도 가능합니다.

- CloudFormation: AWS 서비스 생성 및 배포 자동화 템플릿 서비스, AWS의 다양한 서비스들을 이용하여 아키텍쳐 구현시 미리 만들어놓은 템플릿(JSON)을 이용하여 생성하거나 직접 템플릿을 작성하여 관리가 가능하도록 하는 서비스입니다.

AWS 가격 정책 관련용어

AWS에서 인스턴스 과금 방식을 설명할때 나오는 용어가 영어이다보니 이게 무슨말이야? 할때가 많은 것 같습니다. 이러한 과금 정책들도 한번 정리하였습니다.

- On-Demand(온디맨드) Instance: 기본적으로 사용하는 과금 방식으로, 사용한 시간 만큼 비용을 지불하는 형태입니다.

- Reserved(예약) Instance: 일정 기간 인스턴스 사용을 약속하고, 그에 대한 할인을 적용받는 방식입니다.

- Spot(스팟) Instance: 입찰 방식의 사용방법으로 사용자가 입찰 가격을 제시해놓으면, 아마존에서 남는 인스턴스들에 대해서 Spot 가격을 책정하는데, 이 가격이 입찰가격 내로 들어오면 인스턴스가 기동되는 방식 입찰 가격이 넘어가면 자동으로 Spot Instance는 다시 종료 됩니다. 항상 실행시키는 업무가 아닌 특정 작업 배치 돌릴 서버용도로 사용이 적합하다고 합니다.

Cloude 관련용어 정리

AWS에 관련된 자료를 보다보면 클라우드에 관련된 용어들이 많이 나옵니다. 고가용성, 장애허용, 온프레미스(On-premise) 같은 용어들이 특히 저는 자주 접했던것 같습니다.

- 고가용성(high availabilit): 짧은 다운타음 동안 자동으로 오류를 복구하는 시스템을 의미합니다. (장애가 발생하더라도 아주 짧은 시간이며, 자동으로 복구)

- 장애허용: 고가용성과 다르게 장애가 발생하더라도 서비스의 중단없이 계속 서비스되는 시스템을 의미합니다.

- 온프레미스(On-premise): 클라우드 같은 환경이 아닌 자체 전산실에 직접 설치하여 운영하는 환경을 의미합니다. 반대로 클라우드 같은 환경을 오프프레미스(Off-premises)라고 합니다.

[ 도서리뷰 ] 그럼에도 불구하고 너무나 인간적인 - 대한민국 개발자로 산다는 것

권윤학 — Sun, 17 Sep 2017 12:40:00 +0900

도서정보

출간일: 2017년 09월 05일

쪽수,무게,크기: 336쪽 | 140*203*30mm

ISBN13: 9791186710173

ISBN10: 1186710179

엄태형 작가님 브런치 페이지: https://brunch.co.kr/@taebari

도서리뷰

이 책은 새로운 기술을 알려주거나 개발을 잘하는 방법 혹은 개발방법론등을 제시하는 개발 기술서적이 아닙니다.

그러한 기술도 중요하지만 무엇보다 중요한건 우리의 삶이라고 생각합니다. 이 책은 개발자(직장인)로서 더 나은 삶을 위한 기술서적입니다.

우리는 무엇을 위해 일을 하고 새로운 기술에 열광하고 습득할려고 했는지 잊고 살았던것 같습니다. 이 책은 그러한 해답을 작가님의 경험과 생각을 바탕으로 제시하는 책이라고 생각합니다.

저는 이 책을 읽는 내내 좋은 기분을 감출 수 없었습니다.

그 이유는 평생 개발자로 살아가기 위해 노력하면서도 왜 평생 개발자로 살아가고 싶은지, 왜 새로운 기술을 습득에 노력했는지에 대한 스스로의 질문에 대답을 명확히 못하고 있었는데, 이 책을 통해 해답을 찾았기 때문입니다.

요즘처럼 하루가 멀다하고 새로운 기술이 쏟아져 나오는 시기 한번쯤 읽으면 좋은 도서입니다. 개발자뿐만 아니라 개발자분들과 연계해서 업무하시는 분들도 읽으면 좋을 것 같습니다.

누군가가 작성한 소스코드를 보면 그 사람이 보인다.

개발자는 코드를 공유하고 리뷰하며 소통한다.

내가 던진 농담에 웃어줄 수 있는 사람이 향기롭다.

나와 가치관이 통하고 같은 공간을 공유하는 것이 즐거움으로 다가오는 사람과의 만남은 언제나 가슴 벅찬일이다.

자신에게 한번 물어보자. 나는 누군가와 쉽게 코드가 맞는 사람인가?

그럼에도 불구하고 너무나 인간적인 p.185

[ Angular / Rxjs ] Angular에서 unsubscribe(구독취소)은 언제 어떻게 해야하는가?

권윤학 — Thu, 14 Sep 2017 22:56:39 +0900

RxJs에서는 Observable를 구독(subscribe) 함으로서 스트림을 통해 데이터를 주고 받고 하고 있습니다. 하지만 Observable를 더 이상 관찰할 필요가 없을 경우 구독취소(unsubscribe)를 해야합니다.

그럼 RxJs를 도입한 Angular(Angular 4)에서는 구독취소(unsubscribe)를 언제 어떻게 해야할까요?

오늘 얘기할 내용은 바로 이 구독취소를 언제, 어떻게, 왜 해야하는지에 대해 얘기하고자 합니다.

2017. 09. 15 Update

- takeUntil 내용 추가

ps) 글에 피드백을 주신분들께 감사드립니다.

왜 구독취소를 해야할까요?

이 얘기를 하기위해서는 Observable이 언제 실행되는지 알아야합니다. 기본적으로 Observable은 subscribe(구독)을 했을때 실행을 합니다. 그 이후 들어오는 스트림(데이터)은 subscribe 메서드 안에서 처리가 됩니다. 그리고 구독을 취소하거나 구독이 완료(complated)되기전까지 계속 동작하게되어 있습니다.

그러다보니 구독취소(unsubscribe)를 안하는경우 계속해서 관찰하게 되어 메모리 낭비가 되거나 혹은 로직이 잘못될 수 있습니다.

그럼 언제 구독을 취소해야하나요?

일반적으로 Angular에서 unsubscribe(구독취소)하는 위치는 ngOnDestroy이 실행될 때 입니다. 이건 Component나 Directive 둘다 동일합니다.

여기서 예외는 Async Pipe(파이프)입니다. Async Pipe는 내부적으로 subscribe(구독)과 unsubscribe(구독취소) 처리를 알아서 하고 있습니다.

그래서 어떻게 구독 취소를 해야할까요?

오늘 얘기할 내용중 가장 핵심인 내용입니다. 가장 기본적인 방법은 아래와 같이 unsubscribe 메서드를 호출 하는것 입니다.

ngOnDestroy() {
  this.productsSubscription.unsubscribe();
  this.categorysSubscription.unsubscribe();
  this.userInfoSubscription.unsubscribe();
}

사실 unsubscribe 메서드는 subscribe 메서드의 리턴값인 Subscription 객체에 존재합니다. 그러다보니 여러개의 Observable이 있는경우 ngOnDestroy 코드가 위와 같이 반복되기 쉽습니다. 또한 저 Subscription 객체를 내부에 선언해야한다는 불편함도 있습니다.

take Method

그래서 RxJs에서는 take 같은 구독 취소를 편하게 할 수 있는 operator(연산자)들이 존재합니다.

this.productions$
  .take(1)
  .subscribe(products => {
    //.. code
  });

위의 소스에서 take(1) 는 한번 실행 후 자동으로 구독이 취소됩니다. ajax 호출같은 스트림을 처리할 때 유용한 unsubscribe(구독취소) 패턴입니다.

takeWhile

그럼 이벤트를 다루는 스트림에서는 어떻게 해야할까요? 이벤트는 이벤트 관찰이 필요한 경우 계속 구독해야하는 경우가 대다수일텐데요.

이럴 경우는 takeWhile 라는 연산자(operator)를 이용하면 편리합니다. 이 패턴은 제가 주로 사용합니다.

alive = true;

ngOnInit() {
  this.filterChange$
    .takeWhile(() => this.alive)
    .subscribe(filter => {
      // 필터가 변경되었을때의 처리
    });

  this.keywordChange$
    .takeWhile(() => this.alive)
    .subscribe(keyword => {
      // 키워드가 변경되었을때의 처리
    });
}

ngOnDestroy() {
  this.alive = false;
}

subscribe 전에 takeWhile 연산자를 이용해 this.alive가 true일때만 구독하도록 처리하고 ngOnDestory에서 this.alive 값을 false로 변경함으로 구독취소 처리를 하는 방식입니다. 이 패턴을 사용하면 구독시 매번 Subscription 객체를 선언할 필요가 없습니다.

2017. 09. 15 Update

takeUntil

또 다른 방법으로는 takeUntil 연산자를 이용하는 방법이 있습니다. takeUntil은 연산자에 Observable를 넘겨 미러링을 한뒤 넘겨준 Observable이 데이터를 받거나 완료처리가 되면 미러링을 중단하고 처음 Observable은 구독취소가 됩니다.

예시를 보면 거의 takeWhile과 방식이 비슷합니다.

unsubscribe: Subject = new Subject(void);

public ngOnInit() {
  this.tagService.getTags({category: 'keyword'})
    .takeUntil(this.unsubscribe)
    .subscribe(tags => {
      this.tags = tags;
    });
}

public ngOnDestroy() {
  this.unsubscribe.next();
  this.unsubscribe.complete();
}

정리

그럼 어떤 방식이 제일 좋을까요?? async 파이프(pipe)를 사용하면 일단 Angular 자체에서 구독과 취소처리를 하기 때문에 가장 좋은 방법이라고 할 수 있겠습니다만 그게 불가능한 상황일 경우 위에서 얘기한 어떠한 방법을 사용해도 사실 크게 상관은 없습니다. 편한 방식을 선택하시면 될 것 같습니다.

하지만 명시적으로 unsubscribe를 이용하여 구독취소를 하는것 보다 operator(연산자)를 이용하여 구독취소 처리를 해주는게 스트림의 흐름을 파악하기 편리하기때문에 되도록이면 operator를 활용하시는 편이 좋을것 같습니다.

참고한 사이트: http://reactivex.io/documentation/operators

[ TypeScript / Angular ] export interface was not found in

권윤학 — Wed, 30 Aug 2017 13:20:23 +0900

Angular2(이하 Angular) 개발시 Service에 선언한 Interface를 export를 하고 다른 컴퍼넌트에서 import를 할려고하니 아래와 같은 에러 메세지가 발생하였습니다.

WARNING in ./src/app/core/sidenav/sidenav-item/sidenav-item.component.ts

21:83-92 "export 'ISideItem' was not found in '../sidenav.service'

at HarmonyImportSpecifierDependency._getErrors (/Users/david/work/resume/client/node_modules/webpack/lib/dependencies/HarmonyImportSpecifierDependency.js:65:15)

at HarmonyImportSpecifierDependency.getWarnings (/Users/david/work/resume/client/node_modules/webpack/lib/dependencies/HarmonyImportSpecifierDependency.js:39:15)

at Compilation.reportDependencyErrorsAndWarnings (/Users/david/work/resume/client/node_modules/webpack/lib/Compilation.js:677:24)

at Compilation.finish (/Users/david/work/resume/client/node_modules/webpack/lib/Compilation.js:535:9)

at applyPluginsParallel.err (/Users/david/work/resume/client/node_modules/webpack/lib/Compiler.js:512:17)

at /Users/david/work/resume/client/node_modules/tapable/lib/Tapable.js:289:11

at _addModuleChain (/Users/david/work/resume/client/node_modules/webpack/lib/Compilation.js:481:11)

at processModuleDependencies.err (/Users/david/work/resume/client/node_modules/webpack/lib/Compilation.js:452:13)

at _combinedTickCallback (internal/process/next_tick.js:67:7)

at process._tickCallback (internal/process/next_tick.js:98:9)

ISideItem 을 sidenav.service에서 찾을 수 없다는데 export 잘 선언되어있고 작동도 잘하고 있었습니다.

waring이지만 뭔가 찜찜합니다. 일단 문제되던 코드를 살펴보겠습니다.

//sidenav-item.component.ts
import {Component, Input, OnInit} from '@angular/core';
import {ISideItem, SideItemTypes} from '../sidenav.service';

@Component({
  selector: 'app-sidenav-item',
  templateUrl: './sidenav-item.component.html',
  styleUrls: ['./sidenav-item.component.scss']
})
export class SidenavItemComponent implements OnInit {
  @Input('item') item: ISideItem;
  @Input('index') index: number;

  menuTypes = SideItemTypes;

  constructor() {}

  ngOnInit() {}
}

아래는 sidenav.service.ts 입니다.


import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs/BehaviorSubject';

/**
 * sidenav 메뉴 type
 * (link/dropDown/icon/separator/extLink)
 */
export enum SideItemTypes {
  link,
  dropDown,
  icon,
  separator,
  extLink
}
/**
 * sidenav 메뉴 인터페이스
 */
export interface ISideItem {
  type: SideItemTypes;              // menu의 type:
  name?: string;                    // menu 노출될 이름
  path?: string;                    // 라우터 경로
  icon?: string;                    // 메뉴 아이콘
  tooltip?: string;                 // 메뉴 툴팁
  disabled?: boolean;               // 메뉴 숨김여부
  sub?: ISideSub[];                 // 하위 메뉴(Array)
}

/**
 * sidenav 하위 메뉴
 */
export interface ISideSub {
  name: string;                     // 하위메뉴 이름
  path: string;                     // 라우터 경로
}

@Injectable()
export class SidenavService {
  constructor() { }
  menu: ISideItem[] = [
    //....
  ];
  // 메뉴 subject
  menuItems = new BehaviorSubject(this.menu);
  // 메뉴 스트림
  menuItems$ = this.menuItems.asObservable();
}

분명히 Interface들이 선언이 잘되어있습니다. 구글링을 조금 해보니 해당 이슈가 발견되었습니다.

그리고 기존의 다른 개발자분들은 interface를 어떻게 export하고 import하고 있는지 확인해봤습니다.

angular.io/src/app/navigation/navigation.service.ts

// Import and re-export the Navigation model types
import { CurrentNodes, NavigationNode, NavigationResponse, NavigationViews, VersionInfo } from './navigation.model';
export { CurrentNodes, CurrentNode, NavigationNode, NavigationResponse, NavigationViews, VersionInfo } from './navigation.model';

Interface용 파일을 별도로 빼서 service에서 export로 from 구문으로 내보내고 있습니다.

그래서 아래와 같이 수정하였습니다.

//sidenav.service.ts
import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs/BehaviorSubject';
// import 하고 export하는 이유는 https://github.com/angular/angular-cli/issues/2034#issuecomment-302666897 참고
import { ISideItem, SideItemTypes} from './sidenav.model';
export { ISideItem, ISideSub, SideItemTypes } from './sidenav.model';

@Injectable()
export class SidenavService {
  constructor() { }
  menu: ISideItem[] = [
    //...
  ];
  // 메뉴 subject
  menuItems = new BehaviorSubject(this.menu);
  // 메뉴 스트림
  menuItems$ = this.menuItems.asObservable();
}

// sidenav.model.ts
/**
 * sidenav 메뉴 type
 * (link/dropDown/icon/separator/extLink)
 */
export enum SideItemTypes {
  link,
  dropDown,
  icon,
  separator,
  extLink
}
/**
 * sidenav 메뉴 인터페이스
 */
export interface ISideItem {
  type: SideItemTypes;              // menu의 type:
  name?: string;                    // menu 노출될 이름
  path?: string;                    // 라우터 경로
  icon?: string;                    // 메뉴 아이콘
  tooltip?: string;                 // 메뉴 툴팁
  disabled?: boolean;               // 메뉴 숨김여부
  sub?: ISideSub[];                 // 하위 메뉴(Array)
}

/**
 * sidenav 하위 메뉴
 */
export interface ISideSub {
  name: string;                     // 하위메뉴 이름
  path: string;                     // 라우터 경로
}

Interface 선언용 파일 sidenav.model.ts를 별도로 분리하여 serivce에서 불러와 포함시키도록 하니 waring이 사라졌습니다.

Typescript에서 @(Decorator)를 사용한 경우 발생되는 문제라고 하니 참고하시면 좋을듯 합니다.

[ Angular ] angular2를 이용하여 HNPWA 만들기 ( 1. Angular 프로젝트 작업 )

권윤학 — Tue, 15 Aug 2017 17:51:47 +0900

HNPWA(Hacker News readers as Progressive Web Apps)은 Google I/O 2017 에서 소개된적이 있으며 TodoMVC와 같은 다양한 자바스크립트 프레임워크를 이용하여 한가지 앱을 구현한 프로젝트입니다.

이름에도 나와있든 이 프로젝트는 Progressive Web App (PWA) 기술을 이용하여 Hacker News 앱을 구현한 프로젝트이며, 이중에서 angular2(이하 angular)를 이용하여 구현한 angular2-hn에는 rxjs, firebase, workboxjs 등의 기술들이 포함되어있어, angular로 pwa를 구현하기전에 참고하기 좋은 프로젝트입니다.

이 글의 원문은 rangle.io 개발자인 Houssein Djirdeh의 블로그(https://houssein.me)에 있는 building hacker news with angular 2 cli, rxjs and webpack 입니다. 저자에게 허락을 받고 번역합니다.

(This article's origin is here[https://houssein.me/angular2-hacker-news] Thank you Houssein Djirdeh for allowing me to translate)

추가 내용이 필요하거나 일부(http -> httpclient) 내용은 수정하였습니다.

번역 글 작성시 사용된 angular-cli 버전은 1.2.7이며, angular-core 버전은 4.3.3 입니다.

Angular를 이용하여 프로젝트를 설정하고 구축해본적이 있으신분들은 이러한 작업들이 상당한 시간이 소요됨을 알고 계십니다. 해당 문제를 개선하고자 Angular 팀에서는 Angular CLI를 출시하였습니다. Angular CLI는 명령 줄 인터페이스로, Angular 프로젝트를 쉽게 구축할 수 있도록 도와줍니다.

이 글에서는 Angular CLI, RxJS Observables 및 Webpack을 모듈 로더로 사용하여 해커 뉴스 클라이언트를 구축 할 것이며, 다음 글에서는 추가적으로 PWA를 만들어 볼 예정입니다.

소스보기 / 결과물 보기

이 글에서는 해커 뉴스 페이지를 만들기 위한 단계별로 설명할 예정이며, 작업 단계에서 발생한 문제와 해결방법에 대해 설명이 포함되어있습니다.

아래의 단계로 작업을 진행할 예정입니다.

먼저 Hacker News의 첫 페이지를 작업합니다.
그 후 해당 페이지에 Observable Data Service를 래핑하여 데이터를 비동기적으로 불러옵니다.
사용자가 서로 다른 페이지와 스토리 유형을 탐색 할 수 있도록 Angular Component Router를 사용하여 라우팅을 추가합니다.
마지막으로 사용자 항목 설명 및 사용자 프로필로 이동할 수있는 경로를 추가합니다.

이 튜토리얼을 통해 angular의 작은 모듈부터 처음부터 끝까지 작업을 해보며, 아래의 중요한 내용들을 간단히 살펴보며 실제 프로젝트에 적용되는지 이해가 가능합니다.

The NgModule decorator
View Encapsulation
RxJS

Getting Started

먼저 node.js를 이용하여 angular-cli를 전역 설치합니다.

npm install -g @angular/cli

angular-cli 설치가 끝난 이후에는 angular 프로젝트를 아래의 명령어로 생성 및 실행이 가능합니다.

ng new angular2-hn --style=scss
cd angular2-hn
ng serve

ng new 명령어는 angular-cli를 이용하여 프로젝트를 생성하는 명령이며 --style 옵션은 프로젝트의 style 코드를 선택하는 옵션으로 이 튜토리얼에서는 scss를 사용합니다.

ng serve를 이용하여 프로젝트를 실행하면 https://localhost:4200/에 접속하여 확인이 가능합니다.

멋지지 않습니까? Angular-cli는 원래 SystemJs를 이용하여 모듈을 번들 및 로드하고 있었으나 SystemJs는 번들 시간이 오래걸리고 3rd party library를 추가할때 불편하는등의 단점이 있어 Angular Cli팀은 SystemJs에서 Webpack으로 변경하였습니다.

NgModule

Cli를 이용하여 Angular 프로젝트 생성 및 실행 시 Angular의 최신 릴리스 버전을 사용합니다. 우리는 먼저 @NgModule 데코레이터 살펴 보겠습니다. NgModule 데코레이터는 app.module.ts 파일에서 사용되는 것을 볼 수 있습니다.

// app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

데코레이터(Decorator) 는 ES7에 제안된 내용이지만 최근 발표된 ES7에는 포함되지 않았으며 현재 stage-2에 포함된 내용으로 @로 시작하며 클래스나 프로퍼티에 역활을 표기해주는 언어적 장치입니다.

@NgModule 데코레이터는 그 밑에 AppModule 클래스가 NgModule용 클래스라는걸 꾸며주는 역활을 합니다. Angular에는 여러가지 데코레이터가 존재하는데 (Component, Directive, Input 등) 각각 Angular의 구성요소를 표기해주는 역활을 합니다.

실제로 작동하는 방식은 아래의 예시를 보시면 이해하기 쉬울듯 합니다.

TypeScript로 작성한 모듈 소스

@NgModule({
  imports: [BrowserModule],
  declarations: [HelloWorldComponent],
  bootstrap: [HelloWorldComponent]
})
export class AppModule {}

Es5로 작성된 모듈 소스

(function(app) {
  app.AppModule =
    ng.core.NgModule({
      imports: [ng.platformBrowser.BrowserModule],
      declarations: [app.HelloWorldComponent],
      bootstrap: [app.HelloWorldComponent]
    }).Class({
      constructor: function() {}
    });
})(window.app || (window.app = {}));

다시 app.module.ts로 돌아와서 보면 cli로 생성된 module 소스에는 기본적으로 AppComponent 및 BrowserModule등이 포함되어있습니다. 해당 소스를 FormsModule과 angular 4.3.0에 추가된 HttpClientModule를 아래처럼 추가하도록 하겠습니다.

// app.module.ts

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpClientModule } from '@angular/common/http';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    FormsModule,
    HttpClientModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Let’s get ready to rumble

이 글에서는 위에 언급한거와 같이 scss를 사용할 예정입니다. 만약 angular-cli로 프로젝트 생성시 --style 옵션으로 scss 설정을 안하셨다면 아래의 명령어를 이용하여 변경해주시기 바랍니다. (scss는 sass 3 부터 sass 주문법이 되었습니다.)

ng set defaults.styleExt scss

해당 명령어를 입력 후에는 .angular-cli.json의 defaults 속성이 아래처럼 변경되어있습니다. ( angular-cli.json의 schma에 대해 궁금하시면 해당 링크에서 확인)

"defaults": {
    "styleExt": "scss",
    "component": {}
}

여기까지 설정이 완료되었다면 첫번째 컴퍼넌트인 HeaderComponent를 추가하겠습니다. 아래의 명령어를 터미널에 입력해주세요.

ng generate component Header

app/header 폴더안에 아래의 파일들이 생성된것을 확인하실 수 있습니다.

header.component.scss
header.component.html
header.component.ts
header.component.spec.ts

위의 이미지는 농담입니다. 실제 서비스되는 어플리케이션에서는 UNIT TEST는 매우 중요합니다. 이 튜토리얼에서는 단위테스트는 다루지 않으므로 spec 파일은 주석하거나 삭제하셔도 됩니다.

app.module.ts를 보면 추가한 HeaderComponent가 포함되어있는걸 확인하실 수 있습니다.

// app.module.ts

// ...
import { AppComponent } from './app.component';
import { HeaderComponent } from './header/header.component';

@NgModule({
  declarations: [
    AppComponent,
    HeaderComponent
  ],
//...

header.component.ts를 살펴보면 component의 선택자가 아래와 같이 app-header임을 알 수 있습니다.

@Component({
  selector: 'app-header',
  templateUrl: './header.component.html',
  styleUrls: ['./header.component.scss']
})

추가한 HeaderComponent를 root component인 app.component.ts에 추가해 보겠습니다.

<!-- app.component.html -->

<app-header></app-header>

이제 ng serve 명령어를 이용하여 어플리케이션 실행 시 header component가 정상적으로 추가되었음을 확인 가능합니다.

좋습니다. 이제 html 마크업과 스타일 코드를 추가해 보도록 하겠습니다.

<!-- app.component.html -->

<div id="wrapper">
  <app-header></app-header>
</div>

app.component.scss도 수정합니다. 원문에서는 github 링크로 제공되고 있는 스타일 코드입니다.

@import url(https://fonts.googleapis.com/css?family=Open%20Sans);

$mobile-only: "only screen and (max-width : 768px)";

body {
  margin-bottom: 0;

  @media #{$mobile-only} {
    margin: 0;
  }
}

#wrapper {
  background-color: #F6F6EF;
  position: relative;
  width: 85%;
  min-height: 80px;
  margin: 0 auto;
  font-family: 'Open Sans', sans-serif;
  font-size: 15px;
  height: 100%;

   @media #{$mobile-only} {
    width: 100%;
    background-color: #fff;
  }
}

그 다음 header를 수정하도록 하겠습니다.

<!-- header.component.html -->

<header id="header">
  <a class="home-link" href="/">
    <img class="logo" src="https://i.imgur.com/J303pQ4.png">
  </a>
  <div class="header-text">
    <div class="left">
      <h1 class="name">
        <a href="/">Angular 2 HN</a>
      </h1>
      <span class="header-nav">
        <a href="">new</a>
        <span class="divider">
          |
        </span>
        <a href="">show</a>
        <span class="divider">
          |
        </span>
        <a href="">ask</a>
        <span class="divider">
          |
        </span>
        <a href="">jobs</a>
      </span>
    </div>
    <div class="info">
      Built with <a href="https://cli.angular.io/" target="_blank">Angular CLI</a>
    </div>
  </div>
</header>

header.component.scss도 아래와 같이 수정해줍니다.

$mobile-only: "only screen and (max-width : 768px)";

#header {
  background-color: #b92b27;
  color: #fff;
  padding: 6px 0;
  line-height: 18px;
  vertical-align: middle;
  position: relative;
  z-index: 1;
  width: 100%;

  @media #{$mobile-only} {
    height: 50px;
    position: fixed;
    top: 0;
  }

  a {
    display: inline;
  }
}

.home-link {
  width: 50px;
  height: 66px;
}

.logo {
  width: 50px;
  padding: 3px 8px 0;

  @media #{$mobile-only} {
    width: 45px;
    padding: 0 0 0 10px;
  }
}

h1 {
  font-weight: bold;
  display: inline-block;
  vertical-align:middle;
  margin: 0;
  font-size: 16px;

  a {
    color: #fff;
    text-decoration: none;
  }
}

.name {
  margin-right: 30px;
  margin-bottom: 2px;

  @media #{$mobile-only} {
    display: none;
  }
}

.header-text {
  position: absolute;
  width: inherit;
  height: 20px;
  left: 10px;
  top: 27px;

  @media #{$mobile-only} {
    top: 22px;
  }
}

.left {
  position: absolute;
  left: 60px;
  font-size: 16px;

  @media #{$mobile-only} {
    width: 100%;
    left: 0;
  }
}

.header-nav {
  display: inline-block;

  @media #{$mobile-only} {
    float: right;
    margin-right: 20px;
  }

  a {
    color: #fff;
    text-decoration: none;

    &:hover {
      font-weight: bold;
    };
  }
}

.info {
  position: absolute;
  right: 20px;
  font-size: 16px;

  @media #{$mobile-only} {
    display: none;
  }

  a {
    color: #fff;
    font-weight: bold;
    text-decoration: none;
  }
}

여기까지 작업하신 후 어플리케이션 화면을 보면 아래와 같습니다.

View Encapsulation

이 어플리케이션은 반응형 페이지로 만들고 있기 때문에 가능하다면 다른 크기의 디바이스에서 보여지는 모습을 체크하는 것도 중요합니다. 뷰포트를 조정하여 모바일 장치에서 어떻게 보이는지 확인해겠습니다.

대부분의 최신 브라우저는 body 태그에 margin 값을 가지고 있기때문에 가장 자리들이 여백이 발생되고 있습니다.

하지만 app.component.scss를 보면 화면 크기가 768px보다 작은 경우 margin : 0로 설정하고 있습니다.

$mobile-only: "only screen and (max-width : 768px)";

body {
  margin-bottom: 0;

  @media #{$mobile-only} {
    margin: 0;
  }
}

왜 이렇게 rendering이 되는지 이유를 살펴보면 Angular Conponent의 스타일 캡슐화 방식 때문입니다. 이 튜토리얼에서 Component의 캡슐화에 대해 자세히 다루지 않겠지만, 간략하게 각 방식에 대해 설명을 하자면 아래와 같습니다.

None: 캡슐화를 하지 않습니다. Shadow DOM이 없으며, 스타일을 추가하거나 변경하면 전체 HTML 문서에 적용됩니다.
Emulated: Angular에서 지원하는 Shadow DOM을 사용합니다. (기본값)
Native:브라우저의 Shadow DOM을 사용합니다 .(이 기능을 지원하는 브라우저 확인)

app.component.scss는 app.component.ts의 selector에 적용되도록 캡슐화가 되어있습니다. 그러다보니 해당 scss에서 body를 수정할려고해도 적용이 안되는 문제가 발생된것이며 이에 대한 해결책은 두가지정도 방법이 있습니다.

캡슐화 방식을 변경
app.component.scss가 아닌 styles.scss에 코드 적용

이 튜토리얼은 먼저 캡슐화 방식을 변경해보도록 하겠습니다.

// app.component.ts

import { Component, ViewEncapsulation } from '@angular/core';

@Component({
  selector: 'app-root',
  encapsulation: ViewEncapsulation.None,
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})

export class AppComponent {
}

app.component.ts에 encapsulation: ViewEncapsulation.None 항목을 추가하고 다시 어플리케이션을 실행하면 스타일코드가 적용된걸 확인 하실 수 있습니다. 위에 설명드린거와 같이 ViewEncapsulation.None으로 설정시 캡슐화를 하지않고 문서 전체 대상으로 적용되기 때문입니다.

사실 이러한 경우는 첫번째 방법보다 두번째 방법이 더 단순하고 올바른 방법입니다. src 디렉토리 안에보면 styles.scss 파일이 있습니다. 이 파일에는 전역 스타일 코드를 작성하는 파일이며 우리가 작성했던 body 코드는 이 부분에 넣어주기만 하면 끝납니다. 아래 코드 처럼 말이죠

@import url(https://fonts.googleapis.com/css?family=Open%20Sans);

$mobile-only: "only screen and (max-width : 768px)";

body {
  margin-bottom: 0;

  @media #{$mobile-only} {
    margin: 0;
  }
}

이러한 삽질 덕분에 우리는 캡슐화에 대해 알 수 있었습니다 :)

Multiple Components

그 다음으로 Stories와 Footer라는 두개의 Component를 추가로 만들어 보겠습니다. Stories는 Hacker News의 게시물을 지정된 순서대로 노출을 위한 뼈대에 해당합니다.

ng g component Stories

// stories.component.ts

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-stories',
  templateUrl: './stories.component.html',
  styleUrls: ['./stories.component.scss']
})

export class StoriesComponent implements OnInit {
  items: number[];

  constructor() {
    this.items = Array(30);
  }

  ngOnInit() {
  }
}

<!-- stories.component.html -->

<div class="main-content">
  <ol>
    <li *ngFor="let item of items; let i = index" class="post">
      Story #{{i}}
    </li>
  </ol>
  <div class="nav">
    <a href="" class="prev">
      ‹ Prev
    </a>
    <a href="" class="more">
      More ›
    </a>
  </div>
</div>

/* stories.component.scss */
$mobile-only: "only screen and (max-width : 768px)";

a {
  color: #b92b27;
  text-decoration: none;
  font-weight: bold;

  &:hover {
    text-decoration: underline;
  };
}

ol {
  padding: 0 40px;
  margin: 0;

  @media #{$mobile-only} {
    box-sizing: border-box;
    list-style: none;
    padding: 0 10px;
  }

  li {
    position: relative;
    -webkit-transition: background-color .2s ease;
    transition: background-color .2s ease;
  }
}

.list-margin {
  @media #{$mobile-only} {
    margin-top: 55px;
  }
}

.main-content {
  position: relative;
  width: 100%;
  min-height: 100vh;
  -webkit-transition: opacity .2s ease;
  transition: opacity .2s ease;
  box-sizing: border-box;
  padding: 8px 0;
  z-index: 0;
}

.post {
  padding: 10px 0 10px 5px;
  transition: background-color 0.2s ease;
  border-bottom: 1px solid #CECECB;

  .itemNum {
    color: #696969;
    position: absolute;
    width: 30px;
    text-align: right;
    left: 0;
    top: 4px;
  }
}

.item-block {
  display: block;
}


.nav {
  padding: 10px 40px;
  margin-top: 10px;
  font-size: 17px;

  a {
    @media #{$mobile-only} {
      color: #B92B27;
      text-decoration: none;
    }
  }

  @media #{$mobile-only} {
    margin: 20px 0;
    text-align: center;
    padding: 10px 80px;
    height: 20px;
  }

  .prev {
    padding-right: 20px;

    @media #{$mobile-only} {
      float: left;
      padding-right: 0;
    }
  }

  .more {
    @media #{$mobile-only} {
      float: right;
    }
  }
}

.job-header {
  font-size: 15px;
  padding: 0 40px 10px;

  @media #{$mobile-only} {
    padding: 60px 15px 25px 15px;
    border-bottom: 2px dotted #b92b27;
  }
}

.loader {
  background: #B92B27;
  -webkit-animation: load1 1s infinite ease-in-out;
  animation: load1 1s infinite ease-in-out;
  width: 1em;
  height: 4em;
  &:before, &:after {
    background: #B92B27;
    -webkit-animation: load1 1s infinite ease-in-out;
    animation: load1 1s infinite ease-in-out;
    width: 1em;
    height: 4em;
  }
  &:before, &:after {
    position: absolute;
    top: 0;
    content: '';
  }
  &:before {
    left: -1.5em;
    -webkit-animation-delay: -0.32s;
    animation-delay: -0.32s;
  }
}

.loading-section {
    height: 70px;
    margin: 40px 0 40px 40px;

  @media #{$mobile-only} {
    display: block;
    position: relative;
    margin: 45vh 0;
  }
}

.loader {
  color: #B92B27;
  text-indent: -9999em;
  margin: 20px 20px;
  position: relative;
  font-size: 11px;
  -webkit-transform: translateZ(0);
  -ms-transform: translateZ(0);
  transform: translateZ(0);
  -webkit-animation-delay: -0.16s;
  animation-delay: -0.16s;
  &:after {
    left: 1.5em;
  }

  @media #{$mobile-only} {
    margin: 20px auto;
  }
}

@-webkit-keyframes load1 {
  0%,
    80%,
    100% {
    box-shadow: 0 0;
    height: 2em;
  }
  40% {
    box-shadow: 0 -2em;
    height: 3em;
  }
}

@keyframes load1 {
  0%,
    80%,
    100% {
    box-shadow: 0 0;
    height: 2em;
  }
  40% {
    box-shadow: 0 -2em;
    height: 3em;
  }
}

@media #{$mobile-only} {
  @-webkit-keyframes load1 {
    0%,
      80%,
      100% {
      box-shadow: 0 0;
      height: 4em;
    }
    40% {
      box-shadow: 0 -2em;
      height: 5em;
    }
  }

  @keyframes load1 {
    0%,
      80%,
      100% {
      box-shadow: 0 0;
      height: 3em;
    }
    40% {
      box-shadow: 0 -2em;
      height: 4em;
    }
  }
}

그 다음 Footer Component를 추가하도록 하겠습니다.

ng g component Footer

<!-- footer.component.html -->

<div id="footer">
    <p>Show this project some ❤ on
      <a href="https://github.com/housseindjirdeh/angular2-hn" target="_blank">
        GitHub
      </a>
    </p>
</div>

/* footer.component.scss */

$mobile-only: "only screen and (max-width : 768px)";

#footer {
  position: relative;
  padding: 10px;
  height: 60px;
  border-top: 2px solid #b92b27;
  letter-spacing: 0.7px;
  text-align: center;

  a {
    color: #b92b27;
    font-weight: bold;
    text-decoration: none;

    &:hover {
      text-decoration: underline;
    }
  }

  @media #{$mobile-only} {
    display: none;
  }
}

추가한 Component들을 app.component에 추가하도록 하겠습니다.

<!-- app.component.html -->

<div id="wrapper">
  <app-header></app-header>
  <app-stories></app-stories>
  <app-footer></app-footer>
</div>

여기까지 작업한 내용으로 어플리케이션을 실행하면 아래와 같이 됩니다.

글이나 항목에는 각각의 속성들이 있으므로, 이 부분도 Component로 작성하면 좋습니다. 이 튜토리얼에서는 글에 대한 컴퍼넌트를 Item Component로 지정하겠습니다.

ng g component Item

실제 데이터가 들어오면 story component 자식 component로 item 이 사용되며 해당 식별 index는 itemID로 지정됩니다.

먼저 작업했던 stories.component에 item component를 추가하도록 하겠습니다.

<!-- stories.component.html -->

<div class="main-content">
  <ol>
    <li *ngFor="let item of items; let i = index" class="post">
      <item class="item-block" itemID="{{ i + 1 }}"></item>
    </li>
  </ol>
  <div class="nav">
    <a href="" class="prev">
      ‹ Prev
    </a>
    <a href="" class="more">
      More ›
    </a>
  </div>
</div>

추가했던 Item Component들을 수정하겠습니다. 아래의 component에서 selector와 @Input 데코레이터를 눈여겨 봐주시기 바랍니다.

// item.component.ts

import { Component, Input, OnInit } from '@angular/core';

@Component({
  selector: 'item',
  templateUrl: './item.component.html',
  styleUrls: ['./item.component.scss']
})
export class ItemComponent implements OnInit {
  @Input() itemID: number;

  constructor() { }

  ngOnInit() {
  }

}

<!-- item.component.html -->

<p>Story #{{itemID}}<p>

어플리케이션 재실행 시 위에서 추가한 @Input 데코레이터를 통해 ItemComponent에 itemID가 전달되며, 전달받은 itemID를 표기하고 있습니다.

지금까지 어플리케이션 기본 구조를 작업했으며, 작업한 소스에 대한 내용은 해당 링크에 있습니다.

RxJS and Observables

실제 데이터를 가져오기전에 RxJs 및 observables 에 대해 알아보도록 하겠습니다.

Angular의 Http client를 이용하면 원하는 위치에서 서버와 통신이 가능하며, 서버에서 데이터를 가져 오려면 가장 먼저 할 일은 http.get 에 리소스 URL을 넘겨 호출해야합니다. 이때의 리턴값이 무엇일까요?

Angular에서는 RxJs 라이브러리를 사용하여 Observable 또는 비동기 데이터 스트림을 반환합니다. 여러분들은 이미 Promise의 개념과 이를 이용하여 비동기를 처리하는 방식에 대해서는 잘 알고 있을 것입니다. Observables는 Promise처럼 데이터를 얻지 만, 데이터 스트림을 subscribe하고 특정 데이터 변경 내용에 응답 할 수 있습니다.

위의 diagram은 사용자가 버튼을 클릭 할때 발생하는 이벤트에 대해 보여지고 있습니다. 스트림이 값을 전달하는 방법을 보면(클릭 이벤트를 뜻함) 완료된 이벤트뿐만 아니라 오류도 전달하고 있습니다.

이러한 방식의 어플리케이션에서 Observables를 사용하는 개념을 Reactive Programming라고 합니다.

Observable Data Service

이제 실제 데이터를 처리하기 위해 Observable Data Service를 만들어서 의존성 주입을 해보도록 하겠습니다.

ng g service hackernews-api

생성된 서비스파일을 설정하기 전에 Hacker News API가 어떻게 작동하는지 확인해보도록 하겠습니다. 공식 문서를 살펴보면 모든 항목 (투표, 댓글, 기사, 작업)은 id 값을 통해 구별 하고있습니다.

// https://hacker-news.firebaseio.com/v0/item/2.json?print=pretty

{
  "by" : "phyllis",
  "descendants" : 0,
  "id" : 2,
  "kids" : [ 454411 ],
  "score" : 16,
  "time" : 1160418628,
  "title" : "A Student's Guide to Startups",
  "type" : "story",
  "url" : "https://www.paulgraham.com/mit.html"
}

스토리 유형에 따라 다른 url(엔드포인트)에 접근해야합니다. 예를들어 상위 랭킹 뉴스는 아래와 같이 접근해서 조회할 수 있습니다.

// https://hacker-news.firebaseio.com/v0/topstories.json?print=pretty

[ 12426766, 12426315, 12424656, 12425725, 12426064, 12427341, 12425692, 12425776, 12425324, 12425750, 12425135, 12427073, 12425632, 12423733, 12425720, 12427135, 12425683, 12423794, 12424987, 12423809, 12424738, 12425119, 12426759, 12425711, 12422891, 12424731, 12423742, 12424131, 12424184, 12422833, 12424421, 12426729, 12423373, 12421687, 12427437 ...]

따라서 첫 페이지에 상위랭킹 뉴스를 노출할려면 이 url를 페이지별로 순차적으로 접근해야합니다. 어플리케이션 전체적으로 이 서비스가 필요하기 때문에 app.module NgModule 메타데이터 속의 provider에 포함시키도록 하겠습니다.

// app.module.ts

//...
import { HackerNewsAPIService } from './hackernews-api.service';

@NgModule({
  declarations: [
    ...
   ],
  imports: [
    ...
  ],
  providers: [HackerNewsAPIService],
  bootstrap: [AppComponent]
})
export class AppModule { }

이제 HackerNewsAPIService에 요청 메서드를 구현하겠습니다.

// hackernews-api.service.ts

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs/Observable';
import 'rxjs/add/operator/map';

@Injectable()
export class HackerNewsAPIService {
  baseUrl: string;

  constructor(private http: HttpClient) {
    this.baseUrl = 'https://hacker-news.firebaseio.com/v0';
  }

  fetchStories(): Observable {
    return this.http.get(`${this.baseUrl}/topstories.json`);
  }
}

이전에서 언급한거와 같이 http.get은 Observable이 리턴됩니다. fetchStories 메서드를 보시면 Observable를 넘겨주고있습니다. component에서 이 Observable를 어떻게 처리하는지 보시겠습니다.

// stories.component.ts

import { Component, OnInit } from '@angular/core';
import { Observable } from 'rxjs/Observable';

import { HackerNewsAPIService } from '../hackernews-api.service';

@Component({
  selector: 'app-stories',
  templateUrl: './stories.component.html',
  styleUrls: ['./stories.component.scss']
})

export class StoriesComponent implements OnInit {
  items;

  constructor(private _hackerNewsAPIService: HackerNewsAPIService) {}

  ngOnInit() {
    this._hackerNewsAPIService.fetchStories()
                    .subscribe(
                      items => this.items = items,
                      error => console.log('Error fetching stories'));
  }
}

Component가 초기화때 발생되는 이벤트인 ngOnInit에 데이터 스트림을 subscribe하고 해당 리턴값을 item 속성에 설정합니다. 뷰에서 설정해야하는 것은 SlicePipe에 보여질 값이 500개가 아닌 30개씩만 노출되도록 수정하는 것 뿐입니다.

<!-- stories.component.html -->

<div class="main-content">
  <ol>
    <li *ngFor="let item of items | slice:0:30" class="post">
      <item class="item-block" itemID="{{ item }}"></item>
    </li>
  </ol>
  <!-- ... -->
</div>

이제 어플리케이션을 다시 실행하면 리스트 항목에 인기순으로 노출되는 ID목록이 보입니다.

Item의 ID 항목을 Component에 전달하였으니 이번에는 Item의 상세 내용을 가져오는 Observable subscription를 서비스에 작성하도록 하겠습니다.

// hackernews-api.service.ts

//...
  
fetchItem(id: number): Observable {
  return this.http.get(`${this.baseUrl}/item/${id}.json`);
}

그 다음 Item Component view에 사용할 pipe들을 먼저 처리하고 수정하도록 하겠습니다.

우리가 사용할 pipe는 크게 2가지입니다.

먼저 해커 뉴스의 시간 데이터는 Unix format으로 넘어오기 때문에 사람이 이해 할 수 있는 형식으로 변환이 필요합니다. 이 튜토리얼에서는 moment.js의 구현체인 angular2-moment 라이브러리를 사용합니다.

npm install --save angular2-moment

angular2-moment를 npm으로 설치한 이후 app.module에 포함시켜줍니다.

import { MomentModule } from 'angular2-moment';

@NgModule({
  imports: [
    MomentModule
  ]
})

모듈을 불러오고 나면 우리는 amFromUnix와 amTimeAgo pipe를 사용 할 수 있습니다.

두번째로 처리할 pipe는 링크가 있는 항목을 도메인만 표시해주기 위해 domain이라는 pipe를 사용할 예정입니다.

ng generate pipe domain

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({
  name: 'domain'
})
export class DomainPipe implements PipeTransform {

  transform(url: any, args?: any): any {
    if (url) {
      const domain = '(' + url.split('/')[2] + ')';
      return domain ? domain.replace('www.', '') : '';
    }
  }
}

pipe 처리가 추가가 완료되면 item component를 약간 수정하도록 하겠습니다.

// item.component.ts

import { Component, Input, OnInit } from '@angular/core';

import { HackerNewsAPIService } from '../hackernews-api.service';

@Component({
  selector: 'item',
  templateUrl: './item.component.html',
  styleUrls: ['./item.component.scss']
})
export class ItemComponent implements OnInit {
  @Input() itemID: number;
  item;

  constructor(private _hackerNewsAPIService: HackerNewsAPIService) {}

  ngOnInit() {
    this._hackerNewsAPIService.fetchItem(this.itemID).subscribe(data => {
      this.item = data;
    }, error => console.log('Could not load item' + this.itemID));
  }
}

<!-- item.component.html -->

<div *ngIf="!item" class="loading-section">
  <!-- You can add a loading indicator here if you want to :) </i> -->
</div>
<div *ngIf="item">
  <div class="item-laptop">
    <p>
      <a class="title" href="{{item.url}}">
        {{item.title}}
      </a>
      <span class="domain">{{item.url | domain}}</span>
    </p>
    <div class="subtext-laptop">
      {{item.score}} points by
      <a href="">{{item.by}}</a>
      {{ (item.time | amFromUnix) | amTimeAgo }}
      <a href="">
        <span *ngIf="item.descendants !== 0">
          {{item.descendants}}
          <span *ngIf="item.descendants === 1">comment</span>
          <span *ngIf="item.descendants > 1">comments</span>
        </span>
        <span *ngIf="item.descendants === 0">discuss</span>
      </a>
    </div>
  </div>
  <div class="item-mobile">
    <!-- Markup that shows only on mobile (to give the app a
    responsive mobile feel). Same attributes as above
    nothing really new here (but refer to the source
    file if you're interested) -->
  </div>
</div>

/* item.component.scss */

$mobile-only: "only screen and (max-width : 768px)";
$laptop-only: "only screen and (min-width : 769px)";

p {
  margin: 2px 0;

  @media #{$mobile-only} {
    margin-bottom: 5px;
    margin-top: 0;
  }
}

a {
  color: #000;
  cursor: pointer;
  text-decoration: none;
}

.title {
  font-size: 16px;
}

.subtext-laptop {
  font-size: 12px;
  color: #696969;
  font-weight: bold;
  letter-spacing: 0.5px;

  a {
    color: #b92b27;

    &:hover {
      text-decoration: underline;
    };
  }
}

.subtext-palm {
  font-size: 13px;
  color: #696969;
  font-weight: bold;
  letter-spacing: 0.5px;

  a {
    color: #b92b27;

    &:hover {
      text-decoration: underline;
    };
  }

  .details {
    margin-top: 5px;

    .right {
      float: right;
    }
  }
}

.domain {
  color: #696969;
  font-weight: bold;
  letter-spacing: 0.5px;
}

.item-laptop {
  @media #{$mobile-only} {
    display: none;
  }
}

.item-mobile {
  @media #{$laptop-only} {
    display: none;
  }
}

.item-details {
  padding: 10px;
}

이제 어플리케이션을 실행하면 해커 뉴스 첫 페이지가 나타납니다. 지금까지 작업된 내용을 보실려면 해당 링크에서 확인해 주시기 바랍니다.

Things are kinda slow though

어플리케이션 로드시 요청 데이터들을 한번 살펴보겠습니다.

31 개 요청 및 20.8KB 전송 546ms 요청 횟수가 너무 많으며, 첫 페이지 불러오는 시간의 5배가 소요됩니다. 단일 게시물을 확인할때 댓글이 많다면 심각한 문제가 될수 있습니다.

2000개의 코멘트가 있는 글을 불러올때 어떤일이 발생하는지 해당 링크를 누르면 gif파일로 확인이 가능합니다.(약 1.5MB의 741건 요청이 90초 정도 걸립니다.) 저러면 실제 사용 서비스는 불가능해보입니다.

참고용으로 github에 이 버전의 어플리케이션을 가지고 있습니다. 해당 링크에서 코멘트가 불러와지는 시간을 직접 확인 가능합니다.

Let’s switch things up

우리는 이제 여러번의 요청을 통해 데이터를 가져오는게 좋지 않다는걸 경험하였습니다. 조금 찾아본 결과 단일 요청으로 세부정보까지 제공해주는 비공식 API가 있다는걸 알아냈습니다.

예를들어 상위랭킹 뉴스 목록의 응답은 아래와 같습니다.

// https://node-hnapi.herokuapp.com/news?page=1

[
  {
    "id": 12469856,
    "title": "Owl Lisp – A purely functional Scheme that compiles to C",
    "points": 57,
    "user": "rcarmo",
    "time": 1473524669,
    "time_ago": "2 hours ago",
    "comments_count": 9,
    "type": "link",
    "url": "https://github.com/aoh/owl-lisp",
    "domain": "github.com"
  },
  {
    "id": 12469823,
    "title": "How to Write Articles and Essays Quickly and Expertly",
    "points": 52,
    "user": "bemmu",
    "time": 1473524142,
    "time_ago": "2 hours ago",
    "comments_count": 6,
    "type": "link",
    "url": "https://www.downes.ca/post/38526",
    "domain": "downes.ca"
  },
  ...
]

응답데이터를 보면 domain 항목이 따로 있을뿐만 아니라 time_ago 같은 속성도 있습니다. 멋지네요 앞에서 만든 domain.pipe.ts와 angular2-moment 라이브러리를 제거해도 문제 없을 것 같습니다. HackerNewService에서 변경해야할 사항을 살펴보겠습니다.

// hackernews-api.service.ts

@Injectable()
export class HackerNewsAPIService {
  baseUrl: string;

  constructor(private http: HttpClient) {
    this.baseUrl = 'https://node-hnapi.herokuapp.com';
  }

  fetchStories(storyType: string, page: number): Observable {
    return this.http.get(`${this.baseUrl}/${storyType}?page=${page}`);
  }
}

데이터 응답시 500개의 최상위 뉴스들이 조회가 되지 않기때문에 페이지 번호가 추가적으로 필요합니다. storyType를 end-point(url)에 넘기고 있어 사용자가 이동하는 주제에 맞춰 해당 주제의 뉴스를 노출 할 수 있습니다.

이번에는 stories component에 변경사항을 살펴보겠습니다. 최상위 뉴스를 얻기 위해 'news' 값과 페이지 값에 1를 넘겨 조회하도록 하겠습니다.

// stories.component.ts

export class StoriesComponent implements OnInit {
  items;

  constructor(private _hackerNewsAPIService: HackerNewsAPIService) {}

  ngOnInit() {
    this._hackerNewsAPIService.fetchStories('news', 1)
                              .subscribe(
                                items => this.items = items,
                                error => console.log('Error fetching stories'));
  }
}

template 파일은 아래처럼 변경합니다.

<!-- stories.component.html -->

<div class="loading-section" *ngIf="!items">
  <!-- You can add a loading indicator here if you want to :) -->
</div>
<div *ngIf="items">
  <ol>
    <li *ngFor="let item of items" class="post">
      <item class="item-block" [item]="item"></item>
    </li>
  </ol>
  <div class="nav">
    <a class="prev">
      ‹ Prev
    </a>
    <a class="more">
      More ›
    </a>
  </div>
</div>

더 이상 item component에서 비동기로 개별적으로 데이터를 불러오지 않고 stories component에 로딩 표시용 section을 추가합니다. 그리고 item의 데이터를 자식 component에 전달만 하면 됩니다.

즉 item.component.ts에 더 이상 HackerNewsService가 필요 없어지고 부모로부터 Item 객체를 가져오기 때문에 ItemComponent는 깨끗해집니다.

// item.component.ts

export class ItemComponent implements OnInit {
  @Input() item;

  constructor() {}

  ngOnInit() {

  }
}

item.component.html은 크게 변경사항이 없지만 item 객체가 있는지 확인하는 *ngif구문을 없애도 되며(부모에서 해당 처리를 수행함), 또한 각 매개변수들은 새로운 API 데이터의 속성을 참고합니다.

<!-- item.component.html -->

<div class="item-laptop">
  <p>
    <a class="title" href="">
      {{item.title}}
    </a>
    <span *ngIf="item.domain" class="domain">({{item.domain}})</span>
  </p>
  <div class="subtext-laptop">
    <span>
      {{item.points}} points by
      <a href="">{{item.user}}</a>
    </span>
    <span>
      {{item.time_ago}}
      <span> |
        <a href="">
          <span *ngIf="item.comments_count !== 0">
            {{item.comments_count}}
            <span *ngIf="item.comments_count === 1">comment</span>
            <span *ngIf="item.comments_count > 1">comments</span>
          </span>
          <span *ngIf="item.comments_count === 0">discuss</span>
        </a>
      </span>
    </span>
  </div>
</div>
<div class="item-mobile">
  <!-- Markup that shows only on mobile (to give the app a
    responsive mobile feel). Same attributes as above
    nothing really new here (but refer to the source
    file if you're interested) -->
</div>

이제 변경된 소스를 어플리케이션 실행하여 확인해 보자

이제 훨씬 빠르게 로드되는걸 확인 할 수 있습니다. 지금까지의 단계의 소스는 해당 링크에서 확인 가능합니다.

Routing

우리는 꽤 먼 길을 걸어왔지만, 계속하기전에 어플리케이션의 전체 component 구조를 그려보도록 하겠습니다. 제 부족한 파워포인트 실력은 양해부탁드립니다.

또한 comment가 표시되는 페이지 component의 구조도 살펴보겠습니다.

사용자가 이러한 페이지를 접근 할 수 있도록 하려면 애플리케이션에 routing을 포함시켜야 합니다. routi ng 생성하기 이전에 ItemComments component를 생성하겠습니다.

ng g component ItemComments

그 다음 app.routes.ts 파일을 src/app 폴더안에 생성합니다.

// app.routes.ts

import { Routes, RouterModule } from '@angular/router';

import { StoriesComponent } from './stories/stories.component';
import { ItemCommentsComponent } from './item-comments/item-comments.component';

const routes: Routes = [
  {path: '', redirectTo: 'news/1', pathMatch : 'full'},
  {path: 'news/:page', component: StoriesComponent, data: {storiesType: 'news'}},
  {path: 'newest/:page', component: StoriesComponent, data: {storiesType: 'newest'}},
  {path: 'show/:page', component: StoriesComponent, data: {storiesType: 'show'}},
  {path: 'ask/:page', component: StoriesComponent, data: {storiesType: 'ask'}},
  {path: 'jobs/:page', component: StoriesComponent, data: {storiesType: 'jobs'}},
  {path: 'item/:id', component: ItemCommentsComponent}
];

export const routing = RouterModule.forRoot(routes);

앞으로 우리가 진행할 작업에 대한 개요입니다.

우리는 상대경로를 가진 특정 Component에 맵핑된 route의 배열을 생성했습니다.
news, newest, show, ask 그리고 jobs등의 다양한 메뉴들을 상단 링크에 라우팅 할 예정이며 이러한 경로들은 StoriesComponent에 맵핑됩니다.
기본 root 경로를 최상위 news 목록으로 리다이렉트되도록 처리하였습니다.
StorietComponent에 연결할때 data 속성을 통해 storiesType를 매개 변수로 전달합니다. 이를 통해 각 경로에 관련된 뉴스 유형을 가질 수 있습니다(데이터 서비스를 사용하여 뉴스 목록을 가져올 때 필요함).
: page가 토큰으로 사용되어 StoriesComponent가 특정 페이지의 뉴스 목록을 가져올 수 있습니다.
: id는 ItemCommentsComponent가 특정 item에 대한 모든 comment를 얻을 수 있도록 사용됩니다.

라우팅으로 할 수 있는 일은 훨씬 많지만, 우리에게 필요한건 이러한 기본설정뿐입니다. 이제 app.module.ts를 열어 라우팅을 등록해보겠습니다.

// app.module.ts

// ...
import { routing } from './app.routes';

@NgModule({
  declarations: [
    //...
  ],
  imports: [
    //...
    routing
  ],
  providers: [HackerNewsAPIService],
  bootstrap: [AppComponent]
})
export class AppModule { }

Angular에서 route에서 Component를 불러오게 알려주기 위해선 RouterOutlet를 사용해야 합니다.

<!-- app.component.html -->

<div id="wrapper">
  <app-header></app-header>
  <router-outlet></router-outlet>
  <app-footer></app-footer>
</div>

Story Navigation

HeaderComponent에 링크에 해당하는 경로로 바인딩 하도록 하겠습니다.

<!-- header.component.html -->

<header>
  <div id="header">
    <a class="home-link" routerLink="/news/1">
      <img class="logo" src="https://i.imgur.com/J303pQ4.png">
    </a>
    <div class="header-text">
      <div class="left">
        <h1 class="name">
          <a routerLink="/news/1" class="app-title">Angular 2 HN</a>
        </h1>
        <span class="header-nav">
          <a routerLink="/newest/1">new</a>
          <span class="divider">
            |
          </span>
          <a routerLink="/show/1">show</a>
          <span class="divider">
            |
          </span>
          <a routerLink="/ask/1">ask</a>
          <span class="divider">
            |
          </span>
          <a routerLink="/jobs/1">jobs</a>
        </span>
      </div>
      <div class="info">
        Built with <a href="https://cli.angular.io/" target="_blank">Angular CLI</a>
      </div>
    </div>
  </div>
</header>

RouterLink directive는 특정 element에 경로를 바인딩합니다. 이제 StoriesComponent를 업데이트합시다.

// stories.component.ts

import { Component, OnInit } from '@angular/core';
import { Observable } from 'rxjs/Observable';
import { ActivatedRoute } from '@angular/router';

import { HackerNewsAPIService } from '../hackernews-api.service';

@Component({
  selector: 'app-stories',
  templateUrl: './stories.component.html',
  styleUrls: ['./stories.component.scss']
})

export class StoriesComponent implements OnInit {
  typeSub: any;
  pageSub: any;
  items;
  storiesType;
  pageNum: number;
  listStart: number;

  constructor(
    private _hackerNewsAPIService: HackerNewsAPIService,
    private route: ActivatedRoute
  ) {}

  ngOnInit() {
    this.typeSub = this.route
      .data
      .subscribe(data => this.storiesType = (data as any).storiesType);

    this.pageSub = this.route.params.subscribe(params => {
      this.pageNum = +params['page'] ? +params['page'] : 1;
      this._hackerNewsAPIService.fetchStories(this.storiesType, this.pageNum)
                              .subscribe(
                                items => this.items = items,
                                error => console.log('Error fetching' + this.storiesType + 'stories'),
                                () => this.listStart = ((this.pageNum - 1) * 30) + 1);
    });
  }
}

우리가 추가한 내용을 살펴보겠습니다. 먼저 현재 route 정보를 접근할 수 있는 ActivatedRoute 서비스를 의존성에 추가하였습니다.

import { ActivatedRoute } from '@angular/router';

@Component({
  //...
})

export class StoriesComponent implements OnInit {
//..

constructor(
  private route: ActivatedRoute
) {}
//...
}

ngOnInit에서 route의 data 속성에서 storiesType을 component 속성에 저장합니다. Component의 storiesType 속성으로 설정시 any type으로 방법을 주목하시기 바랍니다. 이렇게하면 타입검사에 벗어나는 간단한 방법이며, 그렇지 않으면 data에 storiesType 속성이 없다고 에러가 발생될 수도 있습니다.

ngOnInit() {
  this.typeSub = this.route
    .data
    .subscribe(data => this.storiesType = (data as any).storiesType);

// ...
}

마지막으로 route 매개변수를 subscribe하여 페이지 번호를 가져옵니다. 그런 다음 데이터 서비스를 사용하여 뉴스 목록을 가져옵니다.

ngOnInit() {
  // ...

  this.pageSub = this.route.params.subscribe(params => {
    this.pageNum = +params['page'] ? +params['page'] : 1;
      this._hackerNewsAPIService.fetchStories(this.storiesType, this.pageNum)
        .subscribe(
          items => this.items = items,
          error => console.log('Error fetching' + this.storiesType + 'stories'),
          () => {
            this.listStart = ((this.pageNum - 1) * 30) + 1;
            window.scrollTo(0, 0);
          });
    });
}

완료 처리를 위해 우리는 onCompleted(subscribe 3번째 파라미터)를 사용하여 목록의 첫번째 값을 나타내는 listStart 변수를 업데이트하고(아래의 stories.component.html 에서 확인 가능) 사용자가 페이지를 전환하려고 할 때 페이지 맨 아래에 멈추지 않도록 창 위쪽으로 스크롤합니다.

<!-- stories.component.html -->

<div class="main-content">
  <div class="loading-section" *ngIf="!items">
    <!-- You can add a loading indicator here if you want to :) -->
  </div>
  <div *ngIf="items">
    <ol start="{{ listStart }}">
      <li *ngFor="let item of items" class="post">
        <item class="item-block" [item]="item"></item>
      </li>
    </ol>
    <div class="nav">
      <a *ngIf="listStart !== 1" [routerLink]="['/' + storiesType, pageNum - 1]" class="prev">
        ‹ Prev
      </a>
      <a *ngIf="items.length === 30" [routerLink]="['/' + storiesType, pageNum + 1]" class="more">
        More ›
      </a>
    </div>
  </div>
</div>

여기까지 목록의 상단 네비게이션 및 페이징 처리까지 완료하였습니다. 어플리케이션을 실행하여 변경된 페이지를 확인해보시기 바랍니다.

Item Comments

거의 다 끝났습니다. comment 페이지의 Component들을 추가하기 전에 ItemComponent의 링크를 업데이트하여 라우팅에 포함시켜 보겠습니다.

<!-- item.component.html -->

<div class="item-laptop">
  <p>
    <a class="title" href="{{item.url}}">
      {{item.title}}
    </a>
    <span *ngIf="item.domain" class="domain">({{item.domain}})</span>
  </p>
  <div class="subtext-laptop">
    <span>
      {{item.points}} points by
      <a href="">{{item.user}}</a>
    </span>
    <span>
      {{item.time_ago}}
      <span> |
         <a [routerLink]="['/item', item.id]">
          <span *ngIf="item.comments_count !== 0">
            {{item.comments_count}}
            <span *ngIf="item.comments_count === 1">comment</span>
            <span *ngIf="item.comments_count > 1">comments</span>
          </span>
          <span *ngIf="item.comments_count === 0">discuss</span>
        </a>
      </span>
    </span>
  </div>
</div>
<div class="item-mobile">
  <!-- Markup that shows only on mobile (to give the app a
    responsive mobile feel). Same attributes as above,  
    nothing really new here (but refer to the source
    file if you're interested) -->
</div>

어플리케이션을 실행하고 뉴스 항목의 comment 부분을 클릭하여 주시기 바랍니다.

멋집니다. 우리는 ItemCommentsComponent로 라우팅이 되었음을 확인 할 수 있습니다. 이제 나머지 component들도 추가해 보겠습니다.

ng g component CommentTree

ng g component Comment

우리는 hackernews.api 서비스에 새로운 GET 요청을 추가하여 comment를 가져와야 합니다. component를 수정하기전에 먼저 살펴보겠습니다.

// hackernews.api.service.ts

//...

fetchComments(id: number): Observable {
  return this.http.get(`${this.baseUrl}/item/${id}`);
}

item-comments.component도 수정하도록 하겠습니다.

// item-comments.component.ts

import { Component, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

import { HackerNewsAPIService } from '../hackernews-api.service';

@Component({
  selector: 'app-item-comments',
  templateUrl: './item-comments.component.html',
  styleUrls: ['./item-comments.component.scss']
})
export class ItemCommentsComponent implements OnInit {
  sub: any;
  item;

  constructor(
    private _hackerNewsAPIService: HackerNewsAPIService,
    private route: ActivatedRoute
  ) {}

  ngOnInit() {    
    this.sub = this.route.params.subscribe(params => {
      const itemID = +params['id'];
      this._hackerNewsAPIService.fetchComments(itemID).subscribe(data => {
        this.item = data;
      }, error => console.log('Could not load item' + itemID));
    });
  }
}

StoriesComponent에서 처리했던거와 비슷하게 라우트 매개변수를 subscribe하여 itemID를 확인 후 해당 뉴스의 comment들을 조회합니다.

<!-- item-comments.component.html -->

<div class="main-content">
  <div class="loading-section" *ngIf="!item">
    <!-- You can add a loading indicator here if you want to :) -->
  </div>
  <div *ngIf="item" class="item">
    <div class="mobile item-header">
     <!-- Markup that shows only on mobile (to give the app a
    responsive mobile feel). Same attributes as below,
    nothing really new here (but refer to the source
    file if you're interested) -->
    </div>
    <div class="laptop" [class.item-header]="item.comments_count > 0 || item.type === 'job'" [class.head-margin]="item.text">
      <p>
        <a class="title" href="{{item.url}}">
        {{item.title}}
        </a>
        <span *ngIf="item.domain" class="domain">({{item.domain}})</span>
      </p>
      <div class="subtext">
        <span>
        {{item.points}} points by
          <a href="">{{item.user}}</a>
        </span>
        <span>
          {{item.time_ago}}
          <span> |
            <a [routerLink]="['/item', item.id]">
              <span *ngIf="item.comments_count !== 0">
                {{item.comments_count}}
                <span *ngIf="item.comments_count === 1">comment</span>
                <span *ngIf="item.comments_count > 1">comments</span>
              </span>
              <span *ngIf="item.comments_count === 0">discuss</span>
            </a>
          </span>
        </span>
      </div>
    </div>
    <p class="subject" [innerHTML]="item.content"></p>
    <app-comment-tree [commentTree]="item.comments"></app-comment-tree>
  </div>
</div>

component 맨위에는 뉴스 정보가 노출되고 그뒤에는 뉴스 내용(item.content)이 표시됩니다. 그런 다음 CommentTreeComponent의 선택자인 app-comment-tree에 해당 뉴스 comment(item.comments)들을 입력합니다.

/* item-comments.component.scss */

$mobile-only: "only screen and (max-width : 768px)";
$laptop-only: "only screen and (min-width : 769px)";
$tablet-only: "only screen and (max-width: 1024px)";

.main-content {
  position: relative;
  width: 100%;
  min-height: 100vh;
  -webkit-transition: opacity .2s ease;
  transition: opacity .2s ease;
  box-sizing: border-box;
  padding: 8px 0;
  z-index: 0;
}

.item {
  box-sizing: border-box;
  padding: 10px 40px 0 40px;
  z-index: 0;
}

@media #{$tablet-only} {
  .item {
    padding: 10px 20px 0 40px;
  }
}

@media #{$mobile-only} {
  .item {
    box-sizing: border-box;
    padding: 110px 15px 0 15px;
  }
}

.head-margin {
  margin-bottom: 15px;
}

p {
  margin: 2px 0;
}

.subject {
  word-wrap: break-word;
  margin-top: 20px;
}

a {
  color: #000;
  cursor: pointer;
  text-decoration: none;
}

@media #{$mobile-only} {
  .laptop {
    display: none;
  }
}

@media #{$laptop-only} {
  .mobile {
    display: none;
  }
}

.title {
  font-size: 16px;
}

.title-block {
  text-align: center;
  text-overflow: ellipsis;
  white-space: nowrap;
  overflow: hidden;
  margin: 0 75px;
}

@media #{$mobile-only} {
  .title {
    font-size: 15px;
  }
  .back-button {
    position: absolute;
    top: 52%;
    width: 0.6rem;
    height: 0.6rem;
    background: transparent;
    border-top: .3rem solid #B92B27;
    border-right: .3rem solid #B92B27;
    box-shadow: 0 0 0 lightgray;
    transition: all 200ms ease;
    left: 4%;
    transform: translate3d(0, -50%, 0) rotate(-135deg);
  }
}

.subtext {
  font-size: 12px;
}

.domain, .subtext {
  color: #696969;
  font-weight: bold;
  letter-spacing: 0.5px;
}

.domain a {
  color: #b92b27;
}

.subtext a {
  color: #b92b27;
  &:hover {
    text-decoration: underline;
  }
}

.item-details {
  padding: 10px;
}

.item-header {
  border-bottom: 2px solid #b92b27;
  padding-bottom: 10px;
}

@media #{$mobile-only} {
  .item-header {
    background-color: #fff;
    padding: 10px 0 10px 0;
    position: fixed;
    width: 100%;
    left: 0;
    top: 62px;
  }
}


.loader {
  background: #B92B27;
  -webkit-animation: load1 1s infinite ease-in-out;
  animation: load1 1s infinite ease-in-out;
  width: 1em;
  height: 4em;
  &:before, &:after {
    background: #B92B27;
    -webkit-animation: load1 1s infinite ease-in-out;
    animation: load1 1s infinite ease-in-out;
    width: 1em;
    height: 4em;
  }
  &:before, &:after {
    position: absolute;
    top: 0;
    content: '';
  }
  &:before {
    left: -1.5em;
    -webkit-animation-delay: -0.32s;
    animation-delay: -0.32s;
  }
}

.loading-section {
  height: 70px;
  margin: 40px 0 40px 40px;

  @media #{$mobile-only} {
    display: block;
    position: relative;
    margin: 45vh 0;
  }
}

.loader {
  color: #B92B27;
  text-indent: -9999em;
  margin: 20px 20px;
  position: relative;
  font-size: 11px;
  -webkit-transform: translateZ(0);
  -ms-transform: translateZ(0);
  transform: translateZ(0);
  -webkit-animation-delay: -0.16s;
  animation-delay: -0.16s;
  &:after {
    left: 1.5em;
  }

  @media #{$mobile-only} {
    margin: 20px auto;
  }
}

@-webkit-keyframes load1 {
  0%,
  80%,
  100% {
    box-shadow: 0 0;
    height: 2em;
  }
  40% {
    box-shadow: 0 -2em;
    height: 3em;
  }
}

@keyframes load1 {
  0%,
  80%,
  100% {
    box-shadow: 0 0;
    height: 2em;
  }
  40% {
    box-shadow: 0 -2em;
    height: 3em;
  }
}

@media #{$mobile-only} {
  @-webkit-keyframes load1 {
    0%,
    80%,
    100% {
      box-shadow: 0 0;
      height: 4em;
    }
    40% {
      box-shadow: 0 -2em;
      height: 5em;
    }
  }

  @keyframes load1 {
    0%,
    80%,
    100% {
      box-shadow: 0 0;
      height: 3em;
    }
    40% {
      box-shadow: 0 -2em;
      height: 4em;
    }
  }
}

그 다음으로 CommentTreeComponent를 설정하겠습니다.

// comment-tree.component.ts

import { Component, Input, OnInit } from '@angular/core';

@Component({
  selector: 'app-comment-tree',
  templateUrl: './comment-tree.component.html',
  styleUrls: ['./comment-tree.component.scss']
})
export class CommentTreeComponent implements OnInit {
  @Input() commentTree;

  constructor() {}

  ngOnInit() {

  }
}

<!-- comment-tree.component.html -->

<ul class="comment-list">
  <li *ngFor="let comment of commentTree" >
    <app-comment [comment]="comment"></app-comment>
  </li>
</ul>

/* comment-tree.component.scss */

ul {
  list-style-type: none;
  padding: 10px 0;
}

li {
  display: list-item;
}

ngFor directive를 이용하여 모든 comment들을 노출하도록 하였습니다.

이제 CommentComponent를 작성하도록 하겠습니다. 이 component는 하나의 comment에 해당하는 요소입니다.

// comment.component.ts

import { Component, Input, OnInit } from '@angular/core';

@Component({
  selector: 'app-comment',
  templateUrl: './comment.component.html',
  styleUrls: ['./comment.component.scss']
})
export class CommentComponent implements OnInit {
  @Input() comment;
  collapse: boolean;

  constructor() {}

  ngOnInit() {
    this.collapse = false;
  }
}

<!-- comment.component.html -->

<div *ngIf="!comment.deleted">
  <div class="meta" [class.meta-collapse]="collapse">
    <span class="collapse" (click)="collapse = !collapse">[{{collapse ? '+' : '-'}}]</span>
    <a [routerLink]="['/user', comment.user]" routerLinkActive="active">{{comment.user}}</a>
    <span class="time">{{comment.time_ago}}</span>
  </div>
  <div class="comment-tree">
    <div [hidden]="collapse">
      <p class="comment-text" [innerHTML]="comment.content"></p>
      <ul class="subtree">
        <li *ngFor="let subComment of comment.comments">
          <app-comment [comment]="subComment"></app-comment>
        </li>
      </ul>
    </div>
  </div>
</div>
<div *ngIf="comment.deleted">
  <div class="deleted-meta">
    <span class="collapse">[deleted]</span> | Comment Deleted
  </div>
</div>

/* comment.component.scss */

$mobile-only: "only screen and (max-width : 768px)";
$laptop-only: "only screen and (min-width : 769px)";
$tablet-only: "only screen and (max-width: 1024px)";

:host >>> {
  a {
    color: #b92b27;
    font-weight: bold;
    text-decoration: none;
    &:hover {
      text-decoration: underline;
    }
  }
}

.meta {
  font-size: 13px;
  color: #696969;
  font-weight: bold;
  letter-spacing: 0.5px;
  margin-bottom: 8px;
  a {
    color: #b92b27;
    text-decoration: none;

    &:hover {
      text-decoration: underline;
    }
  }
  .time {
    padding-left: 5px;
  }
}

@media #{$mobile-only} {
  .meta {
    font-size: 14px;
    margin-bottom: 10px;
    .time {
      padding: 0;
      float: right;
    }
  }
}

.meta-collapse {
  margin-bottom: 20px;
}

.deleted-meta {
  font-size: 12px;
  color: #696969;
  font-weight: bold;
  letter-spacing: 0.5px;
  margin: 30px 0;
  a {
    color: #b92b27;
    text-decoration: none;
  }
}

.collapse {
  font-size: 13px;
  letter-spacing: 2px;
  cursor: pointer;
}

.comment-tree {
  margin-left: 24px;
}

@media #{$tablet-only} {
  .comment-tree {
    margin-left: 8px;
  }
}

.comment-text {
  font-size: 14px;
  margin-top: 0;
  margin-bottom: 20px;
  word-wrap: break-word;
  line-height: 1.5em;
}

.subtree {
  margin-left: 0;
  padding: 0;
  list-style-type: none;
}

여기서 우리는 app-comment를 재귀로 호출했다는 것에 주목해야합니다. comments 안에 대댓글 개념으로 comments 배열 가지고 있어 대댓글까지 표기하기 위해 재귀를 사용했습니다.

이제 어플리케이션을 실행하면 각 뉴스의 모든 comment들을 보실수 있습니다.

지금까지의 작업 단계의 소스를 보실려면 여기에서 확인하실 수 있습니다.

User Profiles

우리에게 남은 것은 사용자 프로필뿐입니다. 개념은 거의 동일하므로 이 부분은 자세히 설명하지 않겠습니다. 프로필을 처리하기 위해서 해야할일은 아래와 같습니다.

데이터 서비스에 유저 정보를 조회하는 메서드를 설정합니다.
user component를 생성합니다.
app.route 에 /user 경로에 대해 추가합니다.
다른 component(item / item-comments)에 route 링크를 처리합니다.

사용자 프로필 처리까지 완료한 소스는 여기에서 확인 가능합니다.

Wrapping things up

모든 작업이 완료되었습니다. production으로 빌드 혹은 실행 하기 위해 ng build --prod 또는 ng serve --prod를 명령어를 입력 하시면 uglifying 및 tree-shaking을 사용할 수 있습니다.

이 튜토리얼이 유용했다면 트윗 또는 repo에 star (번역 repo)를 보내주세요.

이 글 이후 오프라인에서도 작동하고 모바일 홈 화면에 설치 할 수 있는 프로그레시브 웹 앱(PWA)을 만드는 방법에 대한 포스팅을 확인해 주시기 바랍니다.

번역후기

번역이 아직까지 익숙치 않아 오번역이 제법있을 수 있으나 최대한 튜토리얼을 직접 진행해보고 맥락에 맞게 번역하였습니다.

사실 PWA에 관련된 포스팅을 번역할려고 했으나 앞에 해당 포스팅이 선행으로 있어서 해당 글 부터 번역했습니다.

해당 글에 대한 피드백은 언제나 환영입니다.

고맙습니다.

[ 개발 도서 ] 아마존 웹 서비스 인 액션 (aws in action) - AWS 활용에서 인프라 자동화와 데브옵스까지

권윤학 — Tue, 8 Aug 2017 23:42:35 +0900

도서 정보

저자 : 안드레아스 비티히, 미하엘 비티히

번역 : 모파상(백영상)

출간 : 2017-05-01

페이지 : 504 쪽

ISBN : 9788968483585

물류코드 :2358

도서소개: [링크](한빛미디어)

리뷰

최근 프로젝트가 끝나고 개발 서적 구매를 위해 교보문고에 갔다가 오늘 구매했습니다. 사실 이 책이 아니라 L earning J avascript 혹은 함수형 반응형 프로그래밍 를 읽어보고 구매하러 갔다가 이 책을 구매하고 오게 되었습니다. (저 두개의 책도 다음주에 구매예정)

AWS와 관련된 국내 서적이 많은데 이 책의 장점이라면 입문자를 대상으로한 예제가 따라가기 쉬웠습니다. AWS는 좋은 기술이나 문서가 어려웠는데 이 책을 보면서 쉽게 따라할 수 있었습니다. 또한 비용에 대한 설명등도 자세히 나와있습니다.

단점으로는 입문자 대상이여서 그런지 AWS Lambda, API Gateway 같은 서비스의 내용이 없어서 아쉬웠습니다. 이러한 내용은 관심이 있으시면 이 책을 읽은 후 다른 강의나 AWS 문서를 읽어보셔도 무방할 것 같습니다.

이 책은 왜 AWS를 써야하는지 입문자에게 알려주는 그러한 책인것 같습니다. 사실 AWS가 좋다고 하지만 접해보지 않은 사람에게 크게 와 닿지 않았을텐데 그러한 분들중 AWS에 관심이 있으신 분들이라면 이 책을 추천드립니다.

[ Angular ] angular-cli.json의 Schema로 알아보는 angular-cli 기능들

권윤학 — Tue, 25 Jul 2017 18:01:04 +0900

최근 Angular-cli와 NativeScript 그리고 electron를 이용하여 간단한 프로젝트 및 seed 프로젝트를 구성하고 있는데 angular-cli에 모르고 있던 기능들이 많아서angular-cli.json의 설정들을 정리하고자 합니다.

해당 포스트는 angular-cli wiki의 내용들을 위주로 작성되었습니다.

작성당시 angular-cli버전은 1.2.2 입니다.

Angular-cli.json의 구성

Angular-cli.json의 속성들은 크게 아래와 같이 구성되어있습니다.

- project

- apps

- e2e

- lint

- test

- defaults

- packageManager

- warnings

project(프로젝트 관련 속성)

//프로젝트 전역에 해당하는 설정
"project": {
  //프로젝트 이름[string]
  "name": "프로젝트의 이름",
  //eject 여부[boolean](ng eject를 실행하면 webpack 설정을 직접 하도록 변경가능하다.) 기본값: false
  "ejected": false
}

- name(string) : 프로젝트의 이름

angular-cli의 ng new로 프로젝트 생성시 입력되는 이름이 기본값으로 들어갑니다.

- ejected(boolean) : eject 여부 기본값은 false

angular-cli에는 ng eject라는 명령어가 있습니다. 해당 명령은 어플리케이션의 webpack 설정을 cli에서가 아닌 직접 설정 가능하도록 변경하는 기능이며 해당메뉴로 변경시 ejected: true로 angular-cli.json이 변경됩니다.

다시 복구가 불가능하다고 하지만 변경했던 angular-cli.json과 package.json의 script 부분 그리고 의존성 추가된 webpack 관련 loader들만 변경하면 다시 ejected:false 상태로 변경가능합니다.

eject 시 주요 변경 사항

1. package.json - scripts

초기 ng new 시 scripts 속성 구분

"scripts": {
  "ng": "ng",
  "start": "ng serve",
  "build": "ng build",
  "test": "ng test",
  "lint": "ng lint",
  "e2e": "ng e2e"
}

ng eject 후 변경된 scripts 속성

"scripts": {
  "ng": "ng",
  "start": "webpack-dev-server --port=4200",
  "build": "webpack",
  "test": "karma start ./karma.conf.js",
  "lint": "ng lint",
  "e2e": "protractor ./protractor.conf.js",
  "pree2e": "webdriver-manager update --standalone false --gecko false --quiet"
}

2. package.json - devDependencies

개발의존성에 아래의 패키지들이 추가됩니다.(webpack에서 사용되는 모듈로더들이네요)

"devDependencies": {
  "webpack-dev-server": "~2.5.1",
  "webpack": "~3.3.0",
  "autoprefixer": "^6.5.3",
  "css-loader": "^0.28.1",
  "cssnano": "^3.10.0",
  "exports-loader": "^0.6.3",
  "file-loader": "^0.10.0",
  "json-loader": "^0.5.4",
  "less-loader": "^4.0.2",
  "postcss-loader": "^1.3.3",
  "postcss-url": "^5.1.2",
  "raw-loader": "^0.5.1",
  "sass-loader": "^6.0.3",
  "script-loader": "^0.7.0",
  "source-map-loader": "^0.2.0",
  "istanbul-instrumenter-loader": "^2.0.0",
  "style-loader": "^0.13.1",
  "stylus-loader": "^3.0.1",
  "url-loader": "^0.5.7"
}

3. webpack.confing.js 파일 추가

프로젝트 루트에 webpack.config.js이 추가됩니다. cli에서 사용되던 webpack.config.js이며 해당 파일을 수정하여 webpack 설정을 커스텀 할 수 있습니다.

4. angular-cli.json 설정 수정

angular-cli.json에 project.ejected 값이 true로 변경됩니다.

apps(어플리케이션 관련 설정)

//어플리케이션에 해당하는 설정[array]
"apps": [
  {
    //어플리케이션 이름[string](cli로 생성시에는 입력안되어있다.) 기본값: 프로젝트 이름을 사용함
    "name": "어플리케이션 이름",
    //어플리케이션 실제 소스 경로[string](cli로 생성시 src로 되어있다.)
    "root": "src",
    //빌드된 결과물 소스가 생성될 경로[string] 기본값: "dist"
    "outDir": "dist",
    //프로젝트에서 사용되는 assets 경로[array<string>](cli로 생성시 ["assets", "favicon.ico"]으로 되어있다.
    "assets": [
      "assets",
      "favicon.ico"
    ],
    "deployUrl": "",
    //어플리케이션 시작 html 파일[string] 기본값: "index.html"
    "index": "index.html",
    //어플리케이션 진입 시작 파일[string](cli로 생성시 "main.ts")
    "main": "main.ts",
    //어플리케이션 진입전 polyfill 처리하는 파일[string](cli로 생성시 "polyfills.ts")
    "polyfills": "polyfills.ts",
    //테스트 진입 시작 파일[string](cli로 생성시 "test.ts")
    "test": "test.ts",
    //typescript 설정파일[string] 기본값: "tsconfig.app.json"
    "tsconfig": "tsconfig.app.json",
    //typescript 설정파일 unit Test 파일[string](cli로 생성시 "tsconfig.spec.json")
    "testTsconfig": "tsconfig.spec.json",
    //생성된 selector에 적용될 접두사
    "prefix": "app",
    //실험적인 기능인 @angular/service-worker 사용여부[boolean] 기본값: false
    "serviceWorker": false,
    //빌드시 순환의존성 경고를 표시합니다.[boolean] 기본값: true
    "showCircularDependencies": true,
    //빌드시 포함될 전역 스타일 파일들[string|array<string>]
    "styles": [
      "styles.sass"
    ],
    //css 전처리기 옵션 (less, sass, scss)
    "stylePreprocessorOptions": {
      //포함시킬 경로들 경로는 root경로로 포함됩니다.[array<string>](styles와 다른점은 파일이냐 경로이냐 차이)
      "includePaths": []
    },
    //빌드시 포함될 전역 자바스크립트 파일들[array<string>]
    "scripts": [],
    //환경설정 파일 경로[string](cli로 생성시 environments/ 경로에 위치해있음)
    "environmentSource": "environments/environment.ts",
    "environments": {
      "dev": "environments/environment.ts",
      "prod": "environments/environment.prod.ts"
    }
  }
]

apps에 주요한 설정이 들어가 있으며 거의 프로젝트 초반단계에선 주로 해당 영역만 보게되는 경우가 많습니다. 그만큼 angular-cli.json의 핵심이라고 봐도되겠습니다.

- name(string): 어플리케이션의 이름

cli로 생성 시 project.name에만 입력되어있습니다. 별도로 설정할 필요 없습니다.

- root(string): 어플리케이션 소스 root 경로

cli로 생성시 src로 입력되어있으며 해당 경로를 변경해야할 경우 root 속성 값을 변경해야합니다. ng new 명령시 --source-dir=src or -sd=src 옵션을 이용하여 생성할때 부터 변경이 가능합니다.

- outDir(string): build된 결과물이 생성되는 경로 기본값은 dist

angular 프로젝트를 build한 결과물이 생성되는 경로입니다. 해당값이 설정이 안되어있는경우 distribute를 의미하는 dist로 설정됩니다.

해당 경로는 .gitignore에 포함되어있어 버전관리 대상이 아니도록 설정되어있습니다.

- assets(array<string>): assets에 파일들을 추가하도록 설정합니다.

프로젝트에서 사용되는 asset 파일들을 추가하는 속성입니다. 폴더 경로를 설정할 수 있으며 파일을 추가할 수도 있습니다. favicon.icon 혹은 manifest.json파일들을 이 속성에 추가하시면 됩니다.

- deployUrl(string): build 된 결과물을 배포할 url를 설정합니다.

만약 aws 클라우드 프론트 같은 서비스를 이용하여 angular 서비스의 js 와 css를 배포하고 있다면 클라우드 프론트의 엔드포인트를 설정하여 운영할 수 있도록 추가된 값입니다. build 결과물에 publicPath를 설정해주며, 미설정시에는 상대경로로 설정되어 결과물이 생성된다.

- index(string): 어플리케이션이 시작되는 html 파일을 설정합니다. 기본값은 index.html

어플리케이션이 시작되는 html의 파일을 설정하는 속성이며, 미설정시 기본값은 index.html입니다.

- main(string); 어플리케이션 진입시작 파일을 설정합니다.

angular 어플리케이션이 시작되는 파일을 설정합니다. cli로 생성시 기본적으로는 main.ts가 설정되어있습니다.

- polyfills(string): 어플리케이션 진입전 polyfill 처리를 하는 파일을 설정합니다.

polyfill이란 poly + fill의 단어로 여러가지를 채우다라는 뜻을 의미하고 있습니다.(자세한 내용은 해당 링크 참고) 구형브라우저들이 지원하지 않는 최신 기능들을(html5) 가능하도록 해주는 js / css를 의미합니다. angular에서는 이러한 polyfill를 쉽게 이용가능하도록 지원해주고 있습니다. angular-cli로 생성된 프로젝트에는 polyfills.ts에 포함되어 있습니다.

- test(string): 어플리케이션 테스트 진입 파일을 설정합니다.

angular-cli에서는 unit test를 위해 karma를 사용하도록 되어있습니다. 테스트 코드 진입 파일을 설정하는 속성으로 기본적으로 cli로 프로젝트 생성했을때는 test.ts로 설정되어 있습니다.

- tsconfig(string): typescript config 파일을 설정합니다. 기본값은 tsconfig.app.json

angular는 기본적으로 javascript / typescript / dart 등의 언어로 개발이 가능하지만 angular-cli는 typescript로 작성되도록 셋팅이 됩니다. typescript로 작업시 typescript의 빌드 옵션을 설정 할 수 있는 tsconfig가 필요하며 angular-cli에서는 build시 사용할 tsconfing를 설정 가능하도록 되어있습니다. 또한 어플리케이션 코드말고 테스트 코드 또한 typescript로 되어있어 어플리케이션 코드와 테스트 코드의 설정 파일을 별도로 나뉘어놨습니다. 해당 속성은 어플리케이션에 해당하는 설정 파일이므로 tsconfig.app.json 파일로 기본값이 되어있습니다.

- testTsconfig(string): 테스트코드의 typescript config 파일을 설정합니다.

위에서 설명한거와 같이 어플리케이션 코드와 테스트 코드 모두 typescript 코드로 작성되어있으며 위에서는 어플리케이션 코드의 typescript 설정파일이였다면 해당 속성은 테스트 코드의 설정 파일입니다. cli로 프로젝트 생성시 설정되어있는 값은 "tsconfig.spec.json" 입니다.

- prefix(string): 생성되는 컴퍼넌트들의 selector의 추가되는 접두사를 설정합니다.

ng generator 같은 명령어로 생성되는 selector에 기본적으로 추가되는 접두사를 설정합니다. cli로 프로젝트 생성시 app이 기본적으로 들어가있으며 이럴 경우 ng generator toolbar 명령시 app-toolbar로 selector가 생성됩니다.

- serviceWorker(boolean): @angular/service-worker 사용여부입니다. 기본값은 false

angular 팀에서 아직 시험단계로 서비스중인 serviceworker 모듈에 관련된 속성입니다. 해당 내용은 google i/o 2017에서 소개된적이 있으며, 그 내용을 cli로 구현하였습니다. 관련 내용은 해당 링크에서 확인 가능합니다.

- showCircularDependencies(boolean): build시 circular-dependency waring 확인 여부입니다. 기본값은 true

webpack build 시 circular-dependency waring이 있는지 없는지 확인 여부입니다.

- styles(string|array<string>): build시 전역으로 포함될 style 파일들입니다.

보통 이 영역에 직접 작성하는 스타일 파일들과 3rd library들을 추가하여 추가하고 있습니다.

- stylePreprocessorOptions(object): css 전처리기에 전달할 옵션속성입니다(현재는 includePaths만 가능)

- includePaths(array<string>): build에 추가할 path를 설정합니다.

해당 속성과 styles와의 차이는 파일이냐 경로냐 정도로 생각하시면 됩니다.

- scripts(array<string>): build시 전역으로 포함될 script 파일들입니다.

styles과 마찬가지로 전역으로 추가할 script 파일들을 설정하는 곳입니다. 주로 hammer.js 같은 3rd library 들을 추가합니다.

- environmentSource(string): 환경파일 설정합니다.

build시 환경에 따른 환경변수들을 설정 할 수 있는 영역입니다. cli로 생성시 기본적으로 "environments/environment.ts" 입력되어 있으며 해당 부분은 환경변수 기본값으로 사용됩니다.

- environments(object): 환경들을 정의 및 사용할 환경변수 파일을 설정합니다.

build시 사용될 환경들에 대한 정의를 할 수 있으며 해당 환경이 사용될 환경변수파일도 설정 가능합니다.

e2e(end-to-end 테스트 관련 설정)

"e2e": {
   //angular team에서 만든 angular 용 e2e 프레임워크인 protractor 설정
   "protractor": {
      "config": "./protractor.conf.js"
   }
}

e2e 속성은 angular e2e test 프레임워크인 protractor 관련 설정이 있습니다. protractor 사용법의 경우 윤영식님 블로그의 글을 보시면 자세하게 확인 가능합니다.

lint(TSlint 관련 설정)

//TSlint 관련 설정[array]
"lint": [
    {
      "project": "src/tsconfig.app.json"
    },
    {
      "project": "src/tsconfig.spec.json"
    },
    {
      "project": "e2e/tsconfig.e2e.json"
    }
]

lint 속성은 Tslint 관련된 속성으로 각 프로젝트(어플리케이션 / unit test / e2e test 등)별로 tslint를 설정을 처리할 수 있습니다. 위의 json은 cli로 생성시 기본적으로 설정될 json으로 project 속성 말고 files / tslintConfig / exclude 같은 속성들이 존재합니다만 딱히 설정할 일이 크지는 않을 것 같습니다. 각 항목들은 아래와 같습니다.

- files(string|array<string>): lint 대상 파일들을 추가합니다.

각 프로젝트별로 config파일들에 보면 아래와 같이 설정되어있습니다. 아래는 cli 설치 후 tsconfig.spec.json 입니다.

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "outDir": "../out-tsc/spec",
    "baseUrl": "./",
    "module": "commonjs",
    "target": "es5",
    "types": [
      "jasmine",
      "node"
    ]
  },
  "files": [
    "test.ts"
  ],
  "include": [
    "**/*.spec.ts",
    "**/*.d.ts"
  ]
}

보시면 files가 있는데 이 부분을 cli.json에 직접 설정도 가능합니다. files는 glob를 지원합니다.

- project(string): tsconfig 파일의 위치를 설정합니다.

프로젝트의 tsconfig 파일위치를 설정하며, 대부분 lint의 속성들은 저 파일안에 포함시켜서 작성하고 있습니다. 위에서 project 속성외에는 딱히 설정할 일 없다는

이유가 이 때문입니다.

- tslintConfig(string): tslint.json의 위치를 설정하는 항목입니다. 기본값 "tslint.json"

프로젝트별로 tsconfig를 따로 써야할 경우 설정 할 수 있겠지만 project 속성에 포함하는 파일로 변경이 가능하니 tsconfig.app.json 같은 파일에 수정하시는걸 추천드립니다.

- exclude(string|array<string>): lint에 제외할 경로나 파일을 설정합니다.

lint 대상이 아닌경우를 추가합니다. 보통 아래와 같이 많이 사용합니다.(아래는 cli로 생성시 기본 tsconfig.app.json)

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "outDir": "../out-tsc/app",
    "baseUrl": "./",
    "module": "es2015",
    "types": []
  },
  "exclude": [
    "test.ts",
    "**/*.spec.ts"
  ]
}

test(unit test 관련 설정)

//unit test와 관련된 설정
"test": {
  "karma": {
    "config": "./karma.conf.js"
  }
}

angular-cli에서는 기본적으로 karma를 이용해서 unit test를 할 수 있도록 지원하고 있습니다. 해당 속성에는 karma / codeCoverage 에 대한 속성을 지원하고 있습니다.

- karma

- config(string): karma config 파일 경로를 설정합니다.

karma의 설정 파일 경로를 설정하는 속성으로 cli로 프로젝트 생성시 프로젝트 root에 karma.conf.js 파일이 생성되어 있습니다.

- codeCoverage

- exclude(array<string>): karma coverage 체크시 제외할 파일이나 경로를 설정합니다.

해당 속성은 glob pattern을 적용합니다.

defaults(generate 명령시 기본값 설정)

"defaults": {
    //style 파일형태[string](cli로 생성할때 --style 옵션에서 선택 가능합니다.)
    "styleExt": "sass",
    //component 생성시 설정
    "component": {
      //어플리케이션 루트에 생성할지 여부[boolean](true시 apps.root 경로에 소스가 생성됩니다.) 기본값: false
      "flat": false,
      //test 코드 생성 여부[boolean] 기본값: true
      "spec": true,
      //inline style로 생성할건지 여부[boolean](true시 스타일 파일이 생성안되고 component 메타데이터 안에 스타일을 입력합니다.) 기본값 : false
      "inlineStyle": false,
      //inline html로 생성할건지 여부[boolean](true시 html 파일이 생성안되고 component 메타데이터 안에 html를 입력합니다.) 기본값 : false
      "inlineTemplate": false,
      //view 캡슐화 모드[string] Emulated / Native / None 기본값: "Emulated"
      //https://angular.io/guide/component-styles#view-encapsulation
      "viewEncapsulation": "Emulated",
      //change detection 전략 모드[string] Default / OnPush 기본값: Default
      "changeDetection": "Default"
    },
    //watch.poll 옵션값[number] 기본값: undifined
    "poll": 1000,
    //class 생성 시 설정
    "class": {
      "spec": false
    },
    //derective 생성 시 설정
    "directive": {
      "flat": true,
      "spec": true
    },
    //guard 생성 시 설정
    "guard": {
      "flat": true,
      "spec": true
    },
    //interface 생성 시 설정
    "interface": {
      //인터페이스 이름에 접두사 설정합니다.[string]
      "prefix": ""
    },
    //module 생성 시 설정
    "module": {
      "flat": false,
      "spec": false
    },
    //pipe 생성 시 설정
    "pipe": {
      "flat": true,
      "spec": true
    },
    //service 생성 시 설정
    "service": {
      "flat": true,
      "spec": true
    },
    //ng serve 명령 시 설정
    "serve": {
      //실행될 서버 port[number] 기본값: 4200
      "port": 4200,
      //실행될 서버 host[string] 기본값: "localhost"
      "host": "localhost",
      //ssl 여부[boolean] 기본값: false
      "ssl": false,
      //sslKey 경로[string](ssl 사용시 sslKey 위치) 기본값: "ssl/server.key"
      "sslKey": "ssl/server.key",
      //sslCert 경로[string](ssl 사용시 sslCert 위치) 기본값: "ssl/server.crt"
      "sslCert": "ssl/server.crt"
    }
  }

defaults 속성은 주로 ng generate 명령어와 관련된 설정들입니다. angularjs의 경우 yoman의 generator들을 이용하여 컴퍼넌트나 서비스 파일들을 추가했었는데 프로젝트 진행시 generator들이 지원되지않거나 수정이 필요한 경우 포크를 받아 별도 generator를 만들어 사용해야하는 불편함이 있었는데 angular-cli는 이러한 점을 어느정도 설정이 가능하도록 제공하고 있습니다. 대부분은 flat / spec 속성만 있으며 component나 interface 생성시는 다른 옵션이 보입니다.

대부분 속성들의 세부항목이 반복되어서 반복되지 않는 속성들만 알아보겠습니다.

- styleExt(string): style 코드 확장자를 결정합니다.(css / scss / less / sass / stylus)

해당 속성은 component 생성시 angular-cli.json의 defaults.component.inlintstyle = false 인 경우 스타일 코드 생성될 확장자를 결정합니다. 또한 ng new 명령으로 프로젝트 생성시 --style=sass 와 같이 옵션을 넣어 생성 가능합니다.

- component(object): ng generate component 명령시 관련된 설정입니다.

- flat(boolean): 생성되는 소스가 angular-cli.json의 apps.root 디렉토리에 생성할지 여부를 설정합니다.

ng generate 명령과 관련된 설정들은 거의 대부분 이 하위속성이 들어가 있습니다. 모두 같은 내용이며 단지 기본값만 속성마다 다릅니다. component의 경우 기본값이 false입니다.

- spec(boolean): 생성하는 코드의 테스트 코드를 생성할 것인지 설정합니다.

이 속성도 flat과 마찬가지로 대부분 하위속성으로 포함되어있으며 마찬가지로 기본값만 다릅니다. component의 경우 기본값이 true입니다.

- inlineStyle(boolean): 생성하는 컴퍼넌트 소스의 inlineStyle 여부를 설정합니다. 기본값: false

해당 속성은 컴퍼넌트에 관련된 설정으로 Component 메타 데이터에 style를 inline 방식으로 할지 아니면 style url 방식으로 할지 결정합니다. false인 경우 컴퍼넌트 생성시 styleExt 설정한 확장자로 스타일코드도 같이 생성됩니다.

- inlineTemplate(boolean): 생성하는 컴퍼넌트 소스의 inlineTemplate 여부를 설정합니다. 기본값: false

마찬가지로 Component 메타 데이터의 템플릿이 inline 방식으로 할지 결정합니다. false인 경우 컴퍼넌트 생성시 html 파일도 같이 생성됩니다.

- viewEncapsulation(string): view 캡슐화 모드를 설정합니다.

해당 설정은 Component의 캡슐화 모드를 설정합니다. 미설정시 메타데이터에 encapsulation항목이 미입력되며 이럴경우 Emulated 로 설정됩니다. encapsulation항목에 대해서는 공식 문서에 나와있습니다. 설정 가능한 항목값 (Emulated / Native / None)

- changeDetection(string): 컴퍼넌트 변화감지 전략을 설정합니다.

해당 설정은 Default / OnPush 값들이 설정 가능하며 미설정시 메타데이터에 changeDetection 항목이 미입력되며 이럴경우는 Default 로 설정됩니다. 성능상의 이슈로 OnPush로 설정하는 컴퍼넌트들이 있겠지만 모든 컴퍼넌트 생성시 OnPush로 해야 할지는 잘 모르겠네요. changeDetection관련 내용은 해당 링크에서 확인 가능합니다.

- poll(number): watch.poll에 전달되는 속성값으로 미설정(undefined)이 기본값입니다.

webpack watch에 관련된 설정으로 파일 변경체크를 몇초(밀리세컨드)마다 하는지 설정하는 값입니다.

- class(object): ng generate class 명령 시 설정입니다.

class 생성시에는 spec 설정만 가능합니다. flat 여부는 설정 불가능하며 apps.root 경로에 무조건 생성됩니다.

- directive / guard / module / pipe / service(object): ng generate [property] 명령시 설정입니다.

해당 속성들은 모두 하위 속성으로 flat / spec 속성을 가지고 있으며 기본값이 모두 다릅니다.(기본값은 위의 angular-cli.json 예시 참고)

- interface(object): ng generate interface 명령 시 설정입니다.

위의 명령들과 다르게 prefix 속성만 설정 할 수 있습니다.

- prefix(string): ng generate interface 명령 시 생성되는 인터페이스 네임에 접두사를 설정합니다.

ng generate interface 명령시 코드는 apps.root 경로에 생성되며 생성되는 인터페이스 코드 네임에 접두사를 설정합니다. 미설정시 접두사 없이 생성명령에 붙인 이름으로만 생성됩니다.

- serve(object): ng serve 관련 설정입니다.

해당 속성들은 모두 ng serve에 관련된 속성들로 이게 언제부터 지원했는지는 잘 모르겠는데 정말 편하네요. 딱히 추가 설명드릴게 없어 하위속성만 나열했습니다.

- port(number): ng serve로 생성되는 서버의 포트를 설정합니다. 기본값: 4200

- host(string): ng serve로 생성되는 서버의 호스트를 설정합니다. 기본값: "localhost"

- ssl(boolean): https 프로토콜 여부입니다. 기본값 false

- sslKey(string): ssl 사용시 sslKey 파일 위치입니다. 기본값: "ssl/server.key"

- sslCert(string): ssl 사용시 sslCert 파일 위치입니다. 기본값: "ssl/server.crt"

packageManager(패키지 매니저 설정)

//패키지 매니저 어떤걸 사용할지 여부[string](npm / cnpm / yarn)
"packageManager": "npm"

cli에서 작업시 패키지 매니저 관련 작업을 어떤 툴을 이용할지 선택할 수 있습니다. 미설정시 npm으로 설정됩니다. ng set --global packageManager=yarn 명령으로 설정 변경이 가능합니다.

warnings(경고 표시 설정)

//console 경고 사용여부 설정
"warnings": {
  //노드 버전이 호환 가능하지 않을 때 경고 표시여부[boolean] 기본값: true
  "nodeDeprecation": true,
  //사용자가 cli를 설치하였을때 경고 표시여부[boolean] 기본값: true
  "packageDeprecation": true,
  //글로벌 버전이 로컬 버전보다 새로운 경우 경고 표시여부[boolean] 기본값: true
  "versionMismatch": true
}

해당 속성들은 기본적으로 안건드리는걸 추천드립니다. 정말 필요에 의해서 무시해야하는 경우만 설정하시면 될 듯 하네요.

마무리

이 글을 처음 작성할려고 생각했을때는 금방 작성이 끝날거라 생각했었는데, 생각보다 cli에 많은 옵션들이 있었습니다.

블로그로 글 작성시 잘못된 정보를 남길순 없어서 최대한 자료조사를 하다보니 제가 모르던 옵션들이 너무 많아 자료조사만 2일이 걸렸습니다. 그 만큼 이 글을 통해 다른분들에게 조금이나마 도움이 되었으면 좋겠습니다.

해당 포스트에 잘못된점이 있거나 궁금하신 점 피드백 모두 환영입니다.

프레임워크와 라이브러리의 차이

권윤학 — Tue, 11 Jul 2017 18:53:46 +0900

최근 자바스크립트는 수많은 라이브러리와 수많은 프레임워크들이 자고일어날때마다 출시되고있습니다.

그러면 어떠한것은 라이브러리이고 어떠한것은 왜 프레임워크일까요? 오늘은 라이브러리와 프레임워크의 차이를 정리하고자 합니다.

- Framework(프레임워크)

프레임워크는 Application 개발시 코드의 품질, 필수적인 코드, 알고리즘, 암호화, 데이터베이스 연동 같은 기능들을 어느정도 구성이 되어있는 뼈대(구조)를 제공하도록 만들어진걸 프레임워크라고합니다.

조금 어렵게 설명드렸는데, 개발 구조나 설계 시 제공되는 인터페이스의 집합입니다. 완성된 어플리케이션은 아니지만 어느정도 프로그래머가 제공된 프레임워크의 구조에서 어플리케이션을 개발해야합니다.

- Library(라이브러리)

라이브러리는 특정 기능에 대한 API(도구 / 함수)를 모은 집합을 라이브러리라고 합니다.

그 기능을 사용하기위해 불러와서 호출하는 방식을 생각하시면 쉬울듯 합니다.

- Framework와 Library의 차이

위의 내용으로만 봤을때는 단순히 라이브러리가 모이면 프레임워크처럼 보일 수 있습니다.

저도 그렇게 생각하고 있었고요 그리고 크게 틀린 생각도 아닌거 같습니다만

자료를 찾아보니 토비의 스프링에 아래와 같은 내용이 있습니다.

프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다.

프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다.

라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.

단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.

반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.

프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 합니다.

애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 합니다.

어플리케이션의 flow를 누가 제어하는냐가 프레임워크인지 라이브러리인지 구분할 수 있었습니다.

맨 위의 이미지에 보면 위에는 framework에 해당하는 것들이며(~~polymer는 라이브러리입니다. 이미지 만들고나니 잘못만들었네요~~) 아래는 library에 해당하는 것들입니다. 저는 사실 react는 프레임워크로 알고 있었는데 react 공식 홈페이지에 보면 이렇게 소개하고있습니다.

A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES

React는 어플리케이션의 흐름을 강제화 하고있지 않습니다. 단순히 ui를 렌더링하기 위한 라이브러리입니다. 프레임워크 처럼 느꼈던건 react 사용 시 flux 같은 라이브러리로 어느정도 프레임워크 같은 모습을 갖추고 있기 때문인것 같습니다.

Backbone.js 또한 지금까지 프레임워크로 기억하고 있었는데 이 포스트를 작성하면서 공식 매뉴얼을 다시 읽었는데 아래와 같은 문구가 있었습니다.

Backbone is a library, not a framework, and plays well with others.
You can embed Backbone widgets in Dojo apps without trouble, or use Backbone models as the data backing for D3 visualizations
(to pick two entirely random examples).

backbone.js 또한 javascript의 mvc 패턴을 구현하기 위한 라이브러리였으며, backbone.js를 이용하여 어플리케이션 개발시 backbone.js가 흐름을 제어하는게 아닌 어플리케이션에 흐름에 맞게 backbone.js를 이용하여 개발했던게 생각나네요.

- 마무리

간혹 이러한 질문을 받은 경우가 많았습니다. OOO 프레임워크는 XX 목적에서는 사용하기 어려운데 어떻게 하면 좋을까요?

저의 대답은 원하는 목적에 맞는 프레임워크를 찾아보세요 입니다.

프로젝트 진행 단계에서 혹은 개인 공부단계에서 한번쯤은 하셨을 고민이라 생각합니다. 저 또한 그랬구요.

마치 저 질문은 자동차는 하늘을 날 수 없는데 하늘을 날게끔 방법이 없나요? 라는 질문같은거라 생각합니다.(나중에는 나오겠지요 그만큼 기술이 발달하면)

물론 너무 극단적인 예시일수 있습니다만 프레임워크란 그 프레임워크에 맞는 목적에 최적화된 뼈대입니다. 대부분 목적에 맞는 프레임워크는 이미 만들어져있습니다. 만약 찾아봐도 없다면 목적과 비슷한 프레임워크에 다른 라이브러리를 결합하여 사용하는 방법도 있습니다.

라이브러리들을 이용해서 프레임워크화 할 수 없나요? 라는 질문도 받았습니다.

가능합니다. 그럴 능력과 시간이 있다면 그렇게하는게 가장 좋습니다.

하지만 왜 node.js의 npm / php의 composer 같은 패키지 매니져들을 다들 사용하며 프레임워크를 사용하는지 생각해보면 빠릅니다.

우리가 직접 프레임워크를 만든다면 어플리케이션 코드도 관리해야하지만 프레임워크에서 발견되는 버그들도 다 수정해야야하며 시간에 쫓겨 어플리케이션에 맞춰 프레임워크를 개발하다보면 결국은 프레임워크로서의 의미가 사라진 코드들이 남을 가능성이 높습니다.

하지만 이미 잘만들어진 프레임워크를 사용한다면 버그 업데이트도 빠르며 훨씬 쉽게 개발이 가능하기때문이 아닐까요?

저런 질문들은 결국 프레임워크와 라이브러리 차이를 알게 된다면 어느정도 방향은 알 수 있다고 생각이 듭니다.(물론 정답이란건 없지만요.)

[ 티스토리 초대장 ] 2017년 6월 초대장 배포(배포완료)

권윤학 — Tue, 6 Jun 2017 17:19:51 +0900

i n v i t a t i o n

티스토리 초대장

안녕하세요!

티스토리 초대장 두번째 나눔을 진행할려고합니다.

지난번에 나름 의미있는 분들에게 드린다고 생각했는데 생각보다 초대받으시고 블로그를 운영 안하시는 분들이 많았습니다.

정말 티스토리 블로그를 운영하실 의향이 있으신분들만 신청해주셨으면 좋겠습니다.

신청방식은 비밀댓글로(공개댓글 안받습니다.) 이메일과 운영하실 블로그의 주제 혹은 블로그를 운영하실려는 이유를 남겨주시면 확인해서 의미있는 분들에게 초대장 배포해드리도록 하겠습니다.

초대장 배포 후 일장 기간동안 블로그 개설을 안하실 경우 다른분들을 위해 회수 할 수 있는점 양해부탁드립니다.

- 이런분들이 좋아요

블로그를 운영할 목적이 분명하신분

이메일 주소를 바르게 남겨주신분들

- 이런분들은 싫어요

아무 이유없이 달라고 하시는분들

이메일 주소를 남겨주시지 않은분들

단순 티스토리가 좋다고 하시는분들

티스토리 이래서 좋아요!

1. 이미지, 동영상, 오디오, 파일까지! 무한 용량과 강력한 멀티미디어를 올릴 수 있어요!

2. 스킨위자드로 스킨을 내맘대로~ 거기에 기능 확장 플러그인까지!

3. 내가 원하는대로 myID.com으로 블로그 주소를 만들 수 있어요!

[ laravel ] laravel 5.5에서 변경되는 사항 정리

권윤학 — Tue, 6 Jun 2017 11:11:20 +0900

Laravel 5.5 Release가 2017년 7월인 다음달로 예정되어있습니다. 정식 배포전 5.5버전에서 변경되는 사항들을 정리하였습니다.

(해당 포스트의 정보는 laravel news에 있는 내용들을 정리하였습니다.)

저작권에 문제가 될 경우 삭제하도록 하겠습니다.

1. LTS 버전 변경

현재 laravel의 LTS(Long Term Supported)버전은 5.1입니다. 이전 5.1버전과 마찬가지로 2년간 버그 픽스와 3년간 보안 업데이트가 이루어질 예정이라고 합니다.

현재 서비스에서 5.1 버전으로 유지하고 계신분들은 5.5로 버전 업데이트 생각도 해보시는게 좋을듯 합니다. 그전에 다음 변경사항을 꼭 참고하시는게 좋을것 같네요.

2. PHP7.0 이상부터 지원

Laravel 개발자인 Taylor가 laravel 5.5부터 php 7.0+가 필요하다고 트위터를 통해 발표했었습니다. 개인적으로도 꼭 Laravel때문이 아니여도 php버전은 7.0+으로 버전 업을 하시는걸 추천드립니다. 마이그레이션 가이드는 php 공식 매뉴얼에 포함되어있으니 마이그레이션시 참고하시면 좋겠네요.

3. vendor:publish의 편의성 추가

이전 버전에서는 php artisan vendor:publish를 이용한 추가한 패키지들의 vendor 파일을 추가하는 방식이 조금 불편했었는데, 이 부분을 CLI상에서 선택해서 추가하도록 변경되었습니다. 말로 조금 어렵게 표현했는데 아래의 이미지를 참고하시면 좋을듯 합니다.(이미지를 누르면 조금더 잘보입니다.)

4. 커스텀 유효성 검사패턴 추가

laravel에는 request의 유효성체크를 위해 다양한 유효성 체크 패턴을 제공하고있지만 한국에 안맞는 패턴이 제법있어서 이러한 부분은 커스텀을 해야했는데 불편했던 커스텀 방식이 직관적으로 수정이 되었습니다. 이부분은 Taylor의 블로그 글을 통해 확인하시는게 좋을듯 합니다.

5. 유효성 검사의 only 메서드 결합

개인적으로 이 부분은 의아하긴 합니다만, request를 validate 메서드를 통해 유효성 검사한 이후 유효성 검사 패턴에 있는 항목들만 only 메서드를 호출하여 리턴 하도록 수정되었습니다. 아래의 코드를 보시면 이해가 편하실듯 하네요.

public function store()
{
    $data = $this->validate(request(), [
        'name' => 'required',
        'price' => 'required|numeric',
        'category_id' => 'numeric|exists:categories',
    ]);

    // $data = request()->only('name', 'price', 'category_id');

    return Product::create($data);
}

저같은 경우 저런 처리가 필요한 경우는 별도 함수를 만들어서 처리하고있었는데 5.5 버전 올릴때 확인해봐야겠네요.

6. 패키지 자동 발견기능

laravel에서 추가하는 패키지들은 개발 환경에서만 필요한 패키지들이 많이 있습니다. 예를 들면 laravel-debugbar 같은 패키지가 있겠네요. 이러한 패키지를 laravel에 추가하기 위해서는 config/app.php 에서 추가하거나 AppServiceProvider에서 환경에 따라 등록하는 코드를 작성해주어야 하는데 사실 이 부분이 매우 코드를 지저분하게 만들고 있긴 했습니다. 이러한 부분을 개선하고자 composer의 dev-require인 패키지들은 자동으로 등록해준다고 합니다.

원리가 궁금해서 찾아보니 composer.json에서 extra부분에 아래와 같은 방식으로 추가한다고 하는군요.

결국은 개발용 패키지들쪽에서 처리를 해야하는거네요. 업데이트가 되고나면 사용하던 개발용 패키지에 PR해야 할 듯 합니다.

"laravel": {
      "providers": [
        "Barryvdh\\Debugbar\\ServiceProvider"
      ],
      "aliases": {
        "Debugbar": "Barryvdh\\Debugbar\\Facade"
      }
    }

이외에 다양한 변경사항을 laravel news에서 확인 가능하며, 아마 LTS 버전으로 출시되다보니 5.4에서 변경되었던 elixir -> mix 같은 변경사항은 없을것 같습니다.

[ PHP ] Fatal error: Maximum function nesting level of 'xxx' reached (xdebug.max_nesting_level)

권윤학 — Fri, 2 Jun 2017 12:19:36 +0900

프로젝트 진행중 갑작스럽게 특정페이지에서 500error가 발생되어 당황했었는데,

php error로그에 아래와 같은 에러가 발생하고있었다.

Fatal error: Maximum function nesting level of 'xxx' reached

조금 찾아보니 xdebug를 활성화시 아래의 설정값과 연관되어 발생한 에러로 재귀함수로 인한 무한루프를 보호하는 값이다.

php.ini에서 해당 값을 조금 변경해서 해결하였는데 템플릿 구문에서 루프문이 재귀 100번을 넘겼다고하니.. 개선이 필요할듯 하다..

아래는 xdebug에서 찾은 설명이다.

xdebug.max_nesting_level

Type: integer, Default value: 256

Controls the protection mechanism for infinite recursion protection. The value of this setting is the maximum level of nested functions that are allowed before the script will be aborted.

Before Xdebug 2.3, the default value was 100.

[ Angular ] Angular 4.0 정식 release (4.0에서 달라진점)

권윤학 — Mon, 27 Mar 2017 09:40:20 +0900

Angular가 Semantic Versioning(유의적 버전관리)에 따라 v4.0.0이 3월 23일 github에 정식 release 되었습니다.

이전에 작성하였던 4.0 베타 릴리즈 정보 및 릴리즈 주기 관련된 글(이전글 보러가기)처럼 3월에 정식 버전이 release되었네요.

4.0으로 변경되면서 어떠한점이 달라졌는지 간단하게 정리해 보았습니다.

정리하기전에 해당 글에서는 용어를 아래와 같이 사용하고 있습니다 .(관련하여 피드백 주시면 감사하겠습니다.)

- angular 2.0 -> angular v2

- angular 4.0 -> angular v4

- 공식 문서 분리

angular v2와 angular v4 의 문서가 분리되었습니다.

angular v2는 레거시 문서로 해당 링크로 별도 분리되었습니다. https://v2.angular.io/docs/ts/latest/

그리고 신규 릴리즈된 angular v4는 angular.io로 변경되었습니다. https://angular.io/docs/ts/latest/guide/

기존에 angular v2를 사용하시던 분들은 변경된 문서 url에서 매뉴얼을 보시거나 마이그레이션 가이드를 확인하여 v4로 변경하셔야합니다.

- angular-cli 1.0

angular v4 출시로 angular v4 프로젝트를 관리할 수 있도록 angular-cli 1.0이 출시되었습니다.

기존에 사용하던 angular-cli를 변경하는 방법은 해당 링크에서 확인 가능합니다.

- 더 작고 빨라졌다.

AOT를 통한 컴퍼넌트의 코드들이 60% 정도 줄었으며, production 코드의 크기가 백키로단위로 줄어들었다고 합니다.

- 애니메이션 별도 패키지화

기존 angular v2는 animation을 @angular/core에서 불러오고 있어서 애니메이션을 사용 안하여도 production 코드에 애니메이션 코드들이 포함되는 문제가 있었습니다.

그러나 angular v4부터는 @angular/platform-browser/animations로 분리되어 애니메이션을 사용하는 경우만 해당 모듈을 불러와서 자동 완성 및 코드 분리에 유리해졌습니다.

- 더 향상된 ngIf, ngFor

angular v4의 템플릿 바인딩 구문에서는 ngIf와 ngFor가 사용이 가능하며, 로컬 변수 할당이 가능해졌다고합니다.

<div *ngIf="userList | async as users; else loading">
  <user-profile *ngFor="let user of users; count as count" [user]="user">
  </user-profile>
 <div>{{count}} total users</div>
</div>
<ng-template #loading>Loading...</ng-template>

- Angular Universal

Angular를 서버에서 실행 할 수 있도록 해주는(서버렌더링) angular universal의 @angular/platform-server 프로젝트가 업데이트 되었습니다.

Angular Universal에 관한 데모는 링크에서 확인하시면 됩니다. 추가적인 문서와 코드 샘플은 추후 업데이트 된다고 합니다.

- TypeScript 2.1과 2.2의 지원

TypeScript 최신버전으로 업데이트 하였다고합니다. 이 업데이트로 ngc 컴파일의 속도가 향상되었다고 합니다.

- 템플릿용 소스맵 제공

템플릿 중 오류가 발생하면 컨텍스트를 제공하는 소스맵을 생성한다고 합니다.

그외에 Packaging관련 변경사항이 있으며(사실 이부분은 읽어봐도 이해가 안가서 기재를 안하였습니다.) 해당 내용들은 공식블로그에서 확인 가능합니다.

기존 학습용 프로젝트를 아직 마이그레이션을 진행 안하였는데, 마이그레이션 가이드를 따라 마이그레이션 진행할 예정입니다.

가이드가 워낙 상세해서 크게 무리는 없을것으로 예상되네요. 다만.. 최근 회사 업무가 바빠서 조금 미루고 있는건 함정이네요...

블로그 포스트 중 angular-cli 관련 포스트가 있는데 angular-cli 1.0이 release되어서 해당 포스트 업데이트도 할 예정입니다.

[ AWS ] 2017년 AWSOME Day 후기

권윤학 — Sun, 19 Mar 2017 22:40:34 +0900

2017년 3월 17일 ~ 18일 Amazon Web Service에서 AWSome Day가 있어서 저는 17일 다녀왔습니다.

오전 9시~ 10시 등록 후 9시 45분 부터 입장이 가능하였으며, 1층에서 사전 등록하신 분들은 안내하시는분들에게 사전등록여부를 보여주시면 입장 빼찌를 주십니다.

요 빼찌를 달고 다녀야 입장이나 중간에 왔다갔다 가능했었습니다.

지하로 내려가니 AWS 파트너사들의 부스들이 몇개 있었는데 사람이 너무 많은것도 있고 정신이 없어 그런지 부스 내용이 잘 눈에 들어오진 않았습니다.

AWSome Day는 AWS 기술 에센셜 과정의 내용을 기반으로 AWS 기술 강사님들의 교육을 무료로 체험하는 행사라고 합니다. 참고로 이 AWS 기술 에센셜 가격이 슈퍼트랙(AWS 국내 교육 공식 파트너사)에서 44만원이라고 하네요. 이러한 교육을 무료로 체험 할 수 있는 AWSome Day 정말 awesome입니다.

17일날 참석하신분이 듣기로는 천명이 넘는다고 하는걸 들었는데 평일이여도 그정도라면 AWS에 대한 관심이 어느정도 인지 조금이나마 느낄수 있었습니다.

참석하시는 분들에게는 점심을 무료로 제공해주었는데 점심 퀄리티가 좋았습니다.

행사는 공식 일정으로는 오후 4시 30분까지 이루어졌으며 AWS의 주요 서비스 몇가지 EC2, S3, ELB, RDS등의 설명이 있었으며, 사람이 많아 실습은 없었으나 데모를 통한 설명이 같이 있어 처음 접하시는 분들에게 좋은 행사였던것 같습니다.

행사때 가져온 선물들입니다. 텀블러는 행사 끝나고 설문조사만 참여해도 다 나눠주었으며, 그외에는 부스에서 받아왔던걸로 기억하네요.

AWSome Day말고도 AWS에서는 많은 행사가 예정되어있다고합니다. 자세한 일정은 아래 링크에서 확인하시길 바랍니다.

https://aws.amazon.com/ko/about-aws/events

[ egjs ] egjs meetup 참관 후기

권윤학 — Thu, 23 Feb 2017 23:33:19 +0900

2017년 2월 23일 네이버에서 운영하고있는 프론트엔드 라이브러리 egjs의 첫번째 meet up이 있어 참석하게 되었습니다.

강남 메리츠 타워 16층에서 진행되었으며 egjs의 소개와 간단한 실습과 참석하신 분들과 대화를 나눌 수 있는 시간등을 보냈는데요.

도착하면 egjs의 스티커와 메모지등을 받을 수 있었습니다.

발표장 모습입니다. 저녁으로 서브웨이 샌드위치와 음료수를 제공 해주셨습니다. (맛있게 잘먹었습니다.)

1부에는 egjs의 소개를 하는 시간이였으며 2부에는 egjs의 component를 간단하게 실습하며 사용 방법을 소개하는 시간이였습니다.

3부에는 치맥을 제공해 주셔서 참석하신 개발자 분들과 대화를 나눌 수 있었습니다.

당일 발표했던 ppt 자료는 아래에 링크를 포함했으며, 제가 설명하는 것보단 자료나 api문서나 예시등을 보시는게 좋을 것 같습니다.

사실 국산 오픈소스가 크게 성공한적이 없어 항상 무언가 아쉬웠는데 egjs 개발자분들의 많은 노력들을 조금이 나마 느낄 수 있었던 시간이였습니다.

egjs는 현재 네이버 서비스에 많이 사용되고있는 라이브러리라고 하니 많은 관심 부탁드립니다.(저도 최근 많이 사용해보고 있습니다.)

egjs 홈페이지: http://naver.github.io/egjs/

egjs github: https://github.com/naver/egjs/

egjs 소개 ppt: https://www.slideshare.net/netil/egjs

egjs demo ppt: https://github.com/egjs/edu/raw/master/slides/egjs-codelab.pptx

[ 맥북 ] 맥북프로 터치바 13인치 구매 후기 (스페이스 그레이)

권윤학 — Thu, 16 Feb 2017 18:52:52 +0900

많은 고민 끝에 맥북프로를 구매하였습니다. 회사 바로 건너편 willys(윌리스) 신사점이 있어서 매장에서 구매하였습니다. 지금 2월 프로모션으로 맥북 프로를 구매하면 파우치와 USB C / USB 둘다 가능한 64GB 메모리까지 주고 있습니다.

구매한 모델은 13인치 터치바 기본형이며 색상은 스페이스 그레이입니다.

역시 애플 다운 심플한 구성.... 가격이 비싼데 어댑터 하나쯤은 끼워주면 얼마나 좋을까요

달랑 전원 어댑터 하나 주다니....

사용 후기는 키보드는 생각보다 느낌 쫀득한 느낌이 마음에 들었으며, 터치바는 정말 누르는 느낌이 전혀없어서 상단 기능키 많이 쓰셨던 분들은 많이 어색 하실듯 하네요. IDE로 PhpStorm 사용 하고있는데 전혀 느려지진 않았습니다.

터치바 모델이 배터리가 빨리 사라진다는 얘기가 있어 고민이 많았는데. 일단 오늘 하루 배터리 테스트해보고 심각한 정도면 서비스센터 방문 할 예정입니다. 테스트 끝나면 다시 업데이트 하도록 하겠습니다.

배터리는 테스트해보니 밝은 조명으로 3시간 정도 사용해보니 35% 정도 사용되었네요 이정도면 무난하게 배터리도 오래가는 편이네요 물론 공개했던 시간 만큼은 아니여도 배터리 걱정으로 구매 망설이시는 분들은 참고하시길 바랍니다.

[ 티스토리 초대장 ] 2017년 2월 초대장 배포(신청마감)

권윤학 — Wed, 8 Feb 2017 23:15:11 +0900

i n v i t a t i o n

티스토리 초대장

안녕하세요!

티스토리에 보금자리를 마련하시려는 여러분께 초대장을 배포해 드리려고 합니다.

나만의, 내 생각을, 내 기억을 담는 소중한 블로그를 만들고 싶다면 티스토리로 시작해보세요!

티스토리 블로그는 초대에 의해서만 가입이 가능합니다. 원하시는 분은 댓글에 E-mail 주소를 남겨주시면 초대장을 보내드립니다. 남겨주실 때에는 꼭 비밀댓글로 남겨주세요!

초대장을 보내드리고 바로 개설하시지 않으신 분들은 초대장을 회수할 수도 있으니 바로 개설해주세요!

Yes

이런 분들께 드립니다!

1. 다른 블로그를 사용해보셨던 분

2. 이메일 주소가 정상적인 분

3. 블로그를 시작하려는 이유를 남겨주신 분!

이런 분들께 드리지 않아요!

1. 이메일 주소가 의심되는 분!

2. 이메일 주소를 남기지 않으신 분

3. 이유도 없이 달라고 하시는 분!

티스토리 이래서 좋아요!

1. 이미지, 동영상, 오디오, 파일까지! 무한 용량과 강력한 멀티미디어를 올릴 수 있어요!

2. 스킨위자드로 스킨을 내맘대로~ 거기에 기능 확장 플러그인까지!

3. 내가 원하는대로 myID.com으로 블로그 주소를 만들 수 있어요!

[ PHP ] Laravel 5.4 Release (Laravel 5.4에서 변경점)

권윤학 — Wed, 25 Jan 2017 08:23:39 +0900

Laravel 5.4이 한국 시간 2017-01-24일 오후 4시에 Composer에 Release 되었습니다.

이 포스트는 Laravel new의 Laravel 5.4 Is Now Released 글을 번역한 내용입니다.

문제 될 경우 바로 삭제하도록 하겠습니다.

Laravel Dusk

Laravel Dusk는 JavaScript Application을 위한 브라우저 테스트 도구입니다. Laravel Dusk는 상호 작용에 의한 올바른 페이지 테스트에 초점이 잡혀 있으며, Dusk를 이용하여 클릭 버튼 / 링크, 양식, 드래그 앤 드롭과 같은 용도로 사용할 수 있습니다.

Dusk는 ChromeDriver와 Facebook Php-webdriver를 테스트에 사용합니다. 모든 Selenium 브라우저에서 작동하지만 기본적으로 ChromeDriver가 제공되므로 JDK 또는 Selenium을 설치하지 않아도됩니다.

Dusk는 Selenium을 설정하고 매번 서버를 시작하지 않아도 사용하기가 매우 쉽습니다.

Laravel Mix

Laravel Mix는 차세대 Elixir입니다. Gulp 대신 webpack으로 제작되었다고 하며, 확인해보니 최근 Release된 Webpack 2.x를 사용하고 있습니다. Major 변경이다 보니 이름까지 변경하게 되었다고 합니다.

기존 Elixir를 커스텀하지 않은 한 Mix로 마이그레이션하는건 크게 문제되지 않는다고 하며 Laracast에서 Mix를 다루는 영상이 업로드 되어있다고 합니다.

Blade Components and Slots

Components 와 Slots은 Blade templates이 더욱 더 유연하게 사용이 가능하도록 디자인 되었습니다. 아래와 같이 alert을 보여주는 예시가 있다고 가정하였을때

// alert.blade.php
<div class="alert">
    {{ $slot }}
</div>

아래와 같이 위의 Componet를 template에 추가가 가능합니다.

@component('inc.alert')
    This is the alert message here.
@endcomponent

Markdown Emails

Laravel 5.3에서는 이메일과 SMS 그리고 기타 다른 채널을 통하여 같은 메세지를 보낼 수 있는 Mailable과 Notifications의 두가지 메일과 관련된 기능이 소개되었습니다.

이러한 개선 사항을 바탕으로 Laravel 5.4에는 메일 템플릿에 MarkDown 시스템이 추가되었습니다.

Automatic Facades

아래의 예시처럼 모든 클래스를 Facade로 사용이 가능합니다.

namespace App;

class Zonda 
{
    public function zurf()
    {
        return ‘Zurfing’;
    }
}

위의 클래스를 router나 controller에 아래와 같이 사용 할 수 있습니다.

use Facades\ {
    App\Zonda
};

Route::get('/', function () {
    return Zonda::zurf();
});

Route Improvements

또 다른 변경점은 router 구문을 middleware나 정의된 name으로 시작이 가능하다는 것입니다.

Route::name('profile')->get('user/{id}/profile', function ($id) {
    // some closure action...
});

Route::name('users.index')->middleware('auth')->get('users', function () {
    // some closure action...
});

Route::middleware('auth')->prefix('api')->group(function () {
    // register some routes...
});

Route::middleware('auth')->resource('photo', 'PhotoController');

또한 route caching layer는 큰 규모의 프로젝트에서 route 매칭에 크게 개선하였습니다.

Higher Order Messaging for Collections

이 새로운 기능을 설명하기 위해서는 예제 코드를 보여주는게 가장 좋은 방법입니다. collection을 each를 이용하여 작업을 수행할 시 기존에는 아래와 같이 코드를 작성하였습니다.

$invoices->each(function($invoice) {
    $invoice->pay();
});

laravel 5.4 부터는 아래처럼 작성이 가능합니다.

$invoices->each->pay();

More New Features

다른 변경 사항 및 개선 사항은 다음과 같습니다.

retry helper 함수 추가
array_wrap helper 함수 추가
503 error 기본 페이지 추가
::class 표기법으로 전환되었습니다.
password reset router에 name이 추가되었습니다.
phpRedis가 지원됩니다.
유효성 검사에 IPv4 와 IPv6이 추가되었습니다.
date_format 유효성 검사가 조금 더 정확해 졌습니다.

Upgrading to Laravel 5.4

공식 문서에는 전체 업그레이드 가이드가 포함되어 있으며, 주의해야 할 몇 가지 변경 사항이 있습니다.

Laravel Tinker는 이제 독립된 패키지이며, composer를 이용하여 설치가 가능합니다.

composer require laravel/tinker

컴포저 설치가 끝난 후에 config / app.php에 provider를 추가합니다.

Laravel\Tinker\TinkerServiceProvider

laravel Test로 browser kit를 사용 하셨을 경우 Laravel Dusk로 마이그레이션을 하시거나 이전 패키지를 컴포저로 사용해야 합니다.

composer require laravel/browser-kit-testing --dev

마지막으로 composer.json에 laravel/framework의 버전을 5.4.*로 변경합니다.

Learning More About Laravel 5.4

조금 더 자세한 내용은 Laracasts에 새로운 기능들과 관련된 시리즈가 모두 준비되어있으며, 공식 문서에는 버전 업 가이드와 버전 릴리즈 노트에서 확인이 가능합니다.

Laravel 5.3

Laravel 5.4

vanilla Css / vanilla Javascript 란?

권윤학 — Tue, 24 Jan 2017 22:45:48 +0900

해외 사이트에서 CSS와 JavaScript 관련된 내용을 보다보면 Vanilla Css 혹은 Vanilla Js(JavaScript) 같은 용어를 많이 볼 수 있습니다.

영어를 잘 못하는 저로서 어떻게 해석할지 난감했었는데, 지금은 순수 CSS 혹은 기본 CSS 정도로 해석하고 있습니다.

보다 더 정확한 의미로는 라이브러리나 프레임워크 없이 순수하게 JavaScript나 CSS만 사용하는 것을 의미하고 있습니다.

저처럼 해당 단어로 구글링이나 네이버에서 검색하시는 분들이 혹여나 계실까 포스트로 남깁니다.

[ Angular ] Angular 4.x 베타 릴리즈, Angular 3.x는 잊어라

권윤학 — Fri, 13 Jan 2017 21:15:23 +0900

작년 구글은 Angular 2.x를 발표한지 6개월만에 Angular 3.x 에 대한 계획을 발표하여 모두를 놀라게 하였습니다. 이제 막 나온 프레임워크를 또 다시 신규 프레임워크로 개발하는 줄 알고 있었습니다. 하지만 Angular 3.x를 출시 하지 않고 2017년 3월 Angular 4.0 릴리즈를 목표로 한다고 합니다.

?? angular 2가 나온지 얼마나 됐다고 3.x 버전이니 4.x 버전이니 하는건가 싶었습니다. 하지만 Angular팀의 버저닝과 릴리즈 정책을 보고 이해가 되었습니다. 아마 기존에 Angular1과 2이 다른 프레임워크로 나뉘어져 있어서 버전 관리를 고민을 많이 한걸로 보입니다.

Angular의 버전 정책

기존의 Angular1의 버전은 아래와 같이 되어있습니다.

Angular 1.0

Angular 1.1

Angular 1.2

Angular 1.3

Angular 1.4

Angular 1.5

여기서 버전을 보면 1.1와 1.2 버전 전후로도 나뉘어지며, 1.2 와 1.3 사이에 IE8 지원 중단등의 이슈가 있지만 버전 넘버링으로만으로는 그 이슈를 알기 힘듭니다. 이러한 이유로 시멘틱 버저닝(Semver)를 따를려고 하는 것이며

Angular2는 아래와 같이 버전 관리가 되어진다고 합니다.

Angular 2

Angular 3

Angular 4

Angular 5

Angular 6

Angular 7

Angular 8

즉 2017년 3월에 릴리즈 예정인 Angular 4는 Angular 2의 2번째 major 버전인셈 입니다.

이러한 이슈로 기존 한국 커뮤니티에서는 Angular 2 명칭을 Angular로 변경하고 있는 중입니다.(Angular 1은 AngularJS)

Angular 3.x 는 왜 릴리즈가 취소되었는가?

Angular 3.x은 @angular/router의 major 버전이 3.x로 시작되면서 베타버전으로 준비되고 있었습니다. 정확하지는 않지만 이 부분때문에 아마 4.x 부터 다음 major 버전으로 채용한 듯 싶습니다.

Angular 4.x 일정

Angular팀은 아래의 3개의 규칙으로 앞으로 버전 업데이트가 이루어질 것이라고 합니다.

- 매주 패치 릴리즈

- 각 주요 릴리즈 매월 3 회 마이너 릴리즈

- 마이너 릴리즈가 6 개월마다 변경됩니다.(마이그레이션이 쉽게 가능하도록 제공하거나, 큰 규모의 마이그레이션이 없다는 걸로 보입니다.)

이 3개의 규칙대로라면 2017년 3월 4.x가 릴리즈됐을때 5.x는 9월 ~10월 사이로 예상됩니다.

2017. 03 Angular 4.0 릴리즈

2017. 09 ~ 10 Angular 5.0 릴리즈

현재 4.0.0-beta.3까지 진행되었으며, 각각 날짜는

4.0.0-beta.3(2017-01-11)

4.0.0-beta.2(2017-01-06)

4.0.0-beta.1(2017-12-22)

4.0.0-beta.0(2017-12-15)

실제로 거의 1주일 ~ 1주일 반 정도 걸리고 있습니다.

Angular 4.x의 목표

Angular4.x의 목표는 Angular2.x와 하위호환이 가능하며, 컴파일러 오류 메세지를 개선하는 것이라고 합니다. 또한 Angular 2.x가 TypeScript 1.8 기준으로 작성되어있어 TypeScript 2.1로 이동하는것도 포함되어있다고 하네요. 이러한 목표를 보아 Angular 4.x가 새로운 프레임워크가 아니라는걸 다시한번 확인 할 수 있습니다.

Angular를 공부하시면서 Angular 3가 나온다 Angular 4가 나온다더라 걱정하실 필요 없으실 것 같습니다.

이외 자세한 내용은 아래의 영상에서 확인 가능합니다.

[ Nginx ] Request Header의 특정 헤더값이 확인이 안될 경우 (underscores_in_headers)

권윤학 — Sun, 8 Jan 2017 17:21:18 +0900

Nginx를 이용하여 서비스를 하다보면 요청 헤더에 넘기는걸 확인했지만 값이 서버사이드에서 확인이 안되는 경우가 있습니다.

그 Header 이름에 _(unserscore) 가 있다면 이 설정을 의심하셔야 합니다.

underscores_in_headers

Nginx의 경우 Request Header 명칭에 _(underscore)가 들어가 있을 경우 해당 Header를 기본적으로 제거합니다.

이러한 설정을 변경하기 위해서는 nginx.conf에서 아래의 설정값을 on으로 설정하셔야 합니다.

underscores_in_headers on;

되도록이면 _가 포함안된 Header 명으로 하시는게 좋겠습니다만 그게 힘들다면 설정값을 변경 후 Nginx 서버를 재시작하시면 서버사이드에서 확인이 가능합니다.

[ php ] Composer (PHP 의존성 관리도구) 소개

권윤학 — Wed, 4 Jan 2017 22:13:04 +0900

Composer(이하 컴포저)는 PHP에서 사용하는 의존성 관리도구입니다. 컴포저를 이용하면 프로젝트에서 사용하는 라이브러리들을 선언하고 의존성을 해결해주며 설치까지 해줍니다. Node.JS의 NPM, ruby의 bundler, gem 같은 패키지 관리 도구와 비슷하며 실제로 컴포저는 NPM과 bundler에서 영감을 얻었다고 합니다.컴포저는 패키지 관리도구라고 하지 않으며 의존성 관리도구라고 합니다.

컴포저로 해결되는 문제는 아래와 같습니다.

- 여러 라이브러리에 의존하는 프로젝트일 경우.

- 이러한 라이브러리들은 또다른 라이브러리를 필요 합니다.

- 이때 필요한 의존 관계의 라이브러리들을 지정할 수 있습니다.

- 컴포저는 패키지가 설치되어야 하는 버전을 찾아, 알맞은 버전의 패키지들과 의존 패키지들을 설치합니다(프로젝트 디렉토리로 다운로드 한다는 의미입니다).

의존성 선언

프로젝트를 생성할 때 필요한 라이브러리를 선언해줘야 합니다. 컴포저 사이트 매뉴얼에 있는 monolog/monolog 라이브러리를 예시로 들겠습니다.

이 라이브러리를 프로젝트에 추가하기 위해선 composer.json 파일에 아래와 같이 입력해주시면 됩니다.

{
    "require": {
        "monolog/monolog": "1.2.*"
    }
}

이렇게 입력하시면 해당 프로젝트에는 monolog 1.2버전의 라이브러리가 필요하다는 걸 표시해주는 것입니다.

(여기서 언급한 monolog는 php 5.3이상에서 작동하는 로깅 프레임워크입니다. Laravel에서도 사용하는 프레임워크이며, php 표준 권고인 psr-3인 Logger Interface 규약을 지키고 있는 프레임워크입니다.)

시스템 요구사항

컴포저는 PHP 5.3.2 이상부터 사용이 가능합니다. 몇가지 PHP 설정이 필요한데 인스톨러를 이용하여 설치 할 경우 비호환성을 체크하여 표시해준다고 합니다.

소스로부터 패키지 설치 시 zip 파일 대신 git. svn 또는 hg가 필요할 수도 있다고 합니다. 컴포저는 멀티 플랫폼을 지원하여 윈도우, 맥, 리눅스 모두 동일하게 동작합니다.

설치방법

Linux / Unix / OSX 에서의 설치 방법

로컬 설치방법과 글로벌 설치방법이 있는데 저는 글로벌 설치방법에 대해서만 설명 드리겠습니다.(로컬로 설치해서 쓸 일이 없을듯 합니다.)

터미널에서 아래의 명령어를 입력해 주시기 바랍니다.

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

그 이후 터미널에서 composer 라는 명령어를 이용하여 사용이 가능합니다.

window에서의 설치 방법

윈도우에서는 수동으로 설치하는 방법이 있으나 인스톨러를 이용한 설치 방법만 설명드리겠습니다. 차이가 없으며 오히려 인스톨러쪽이 간편합니다.

해당 링크에서 인스톨러를 다운로드 받으신 후 설치를 진행하시면 됩니다. 설치가 완료되면 path 설정이 자동으로 되기 때문에 composer 명령어를 바로 사용이 가능합니다.

Composer 사용하기

아까 작성하였던 composer.json 파일 있는 경로에서 아래의 명령어를 입력하면 선언해둔 의존성 라이브러리들을 설치합니다.

composer install

아까 composer.json에 선언해둔 monolog/monolog 라이브러리를 vendor/monolog/monolog 경로에 자동으로 설치가 됩니다.

Autoloading

라이브러리를 받는 일 말고 컴포저는 설치된 라이브러리들의 클래스를 자동으로 불러올 수 있도록 autoloading을 준비합니다. autoloading을 하기 위해서는 아래의 소스를 입력하시면 됩니다.

require 'vendor/autoload.php';

그 다음부터는 컴포저로 설치한 monolog 라이브러리를 사용이 가능해집니다. 더 자세한 사용 법은 다음 포스트에서 다루도록 하겠습니다.

이 포스트는 컴포저 매뉴얼 사이트인 getcomposer - getting started의 내용을 토대로 작성하였습니다.

[번역] 당신이 2017년에 배워야 하는 언어, 프레임워크, 도구 (2017년 웹 개발 트렌드)

권윤학 — Wed, 28 Dec 2016 23:54:47 +0900

해당 포스트는 Martin Angelov의 [The Languages, Frameworks and Tools You Should Learn in 2017] 글을 번역한 내용입니다.

저는 영어를 요즘 초등학생보다 못합니다. 발 번역이여도 이해 부탁 드립니다.

소프트웨어 개발 분야는 계속 발전하고 있으며, 2016년에도 우리가 개발하는데 조금 더 편하도록 변화시킨 인기있는 언어, 프레임워크 도구들이 많이 릴리즈 되었습니다. 이 모든 최신들을 따라가는것은 어렵기 때문에 매년 말 내년에 주목해야 하고 중요 할 것들이 무엇이 있는지 살펴보는 시간을 가지고자 한다.

The Trends

Progressive Web Apps(pwa 프로그레시브 웹 앱)

2016년에 Progressive Web App 개념이 등장하였습니다. Progressive Web App은 오프라인에서도 작동하며 네이티브 앱 같은 경험을 제공합니다. 스마트 폰 홈 화면에 추가 할 수 있으며, 푸시 알림도 받을 수 있어 네이티브 앱과의 격차를 줄일 수 있습니다. 2017년에는 Progressive Web App이 더욱 중요해지고 연구할 가치가 있다고 생각합니다. 조금 더 자세한 사항은 링크에서 확인해 주시기 바랍니다.

The Bot Hype (봇의 유행)

현재 많은 사람들이 봇에 대해 이야기 하고 있습니다. 플랫폼 운영 및 프레임워크 구축까지 커뮤니티에선 활발하게 이야기되고 있습니다.

(여길 참고) 봇은 새로운 모바일 앱이며, 만약 당신이 지금부터 관심을 가진다면 많은 사람들이 함께 열광하는 흐름에 참여 할 수 있습니다.

시간이 지날수록 봇은 사용자가 하던 일을 자동화하는 것으로 전략하게 됩니다. 하지만 그것이 우리가 원하는 것입니다.

Consolidation of Frontend Frameworks (프론트엔드 프레임워크의 통합)

자바스크립트 커뮤니티에는 프레임워크가 도구가 많으며, 거의 매주 새로운 프레임워크와 도구가 생겨나고 있습니다. 최근까지는 이전도구가 새로운 도구로 대체 될 것 이라는 기대가 있었습니다. 그러나 2016년에 경향을 봤을때는 그렇지 않을 듯 합니다. 대신 인기있는 프레임 워크가 아이디어를 교환하고 신규 프레임워크가 제시 한 혁신을 통합하는 것을 보았습니다. 따라서 2017 년 주요 JS 프레임 워크 중 어떤 것을 선택하든 중요하지 않으며 기능은 거의 비슷할 것 입니다.

The Cloud

어느 회사나 개발자들은 클라우드를 도입하고 있습니다. 클라우드는 어느때나 필요하면 확장하고 컨트롤 페이지를 이용하여 설정이 변경 가능한 가상 컴퓨터 인프라입니다. AWS, Google Cloud, Azure 같은 대표적인 클라우드 제공업체들은 지속적인 경쟁으로 가격을 인하하고 있기 때문에 작은 회사나 개인 개발자들도 예산 부담 없이 서비스를 이용할 수 있습니다. 클라우드와 조금 더 친해지는 것도 2017년을 위한 좋은 투자가 될 듯합니다.

Machine Learning

Machine Learning은 지난 1년동안 많은 주목을 받았습니다. 3월에는 이세돌 대 알파고의 역사적인 대결이 있었으며, 그 후 더욱 주목을 받고 있습니다. 숫자나 문자 같은 데이터만 학습하던 Machine Learning은 사용자들의 모바일 디바이스를 사용하는 패턴을 학습하는 걸 통하여 더욱 진화하고 있습니다. 이러한 점을 봤을때 2017년 더욱 Machine Learning이 중요한 영역으로 자리잡을 것이다.

Languages

JavaScript

Javascript의 혁신은 계속 이어질 것 입니다. 더욱 빨라진 웹 브라우저 개발에 맞춰 표준이 제정되고 있습니다. ES2017에서는 2017년 중반쯤 제정이 될 것으로 보이며 비동기 처리 방식인 аsync/аwait이 추가됩니다. 이 기능은 Babel를 이용하면 지금도 ES2017을 사용이 가능합니다.

TypeScript

Typescript 2.1은 2016년 후반에 릴리즈 되었으며, ES2017에서 추가된 async/await와 더 나아진 Type inference를 제공합니다. Typescript는 정적인 타입을 지정하고 JavaScript로 컴파일 되는 언어입니다. 전통적인 OOP모델과 정적인 타입 지정외의 훌륭한 기능이 추가되어 대규모의 코드를 관리하고 유지보수 하는데 도움이 된다. Angular2의 기본 언어이기 때문에 한번 도전해보는걸 권합니다. 저희가 작성한 퀵스타트는 해당 링크에서 확인 가능합니다.

C#

C# 7.0은 2017년에 발표 될 예정입니다. 기존보다 더 좋은 언어가 될 것입니다. Microsoft는 오픈 소스 에디터인 Visual Studio Code와 .NET Core를 발표하면서 모두를 놀라게 하였습니다. 이 에디터들은 Windows, Mac os, Linux에서 모두 실행이 가능하며, 조금 더 빠르게 C# 코드를 작성하는데 도움을 줄 것입니다.(자세한 내용 여기) 두 에디터는 현재 커뮤니티가 활발한 상태이며, 2017년 또한 활발하게 활동할 예정입니다.

Python

Python 3.6은 12월에 릴리즈 되었습니다. Python은 자동화, machine learning, 과학 컴퓨팅에 적합하여 개발자, IT 전문가 및 과학자가 선택할만한 스크립팅 언어로 자리 매김하고 있습니다. Python 2와 3가 작년에 분할되어 커뮤니티에 반발이 많았으나, 현재는 3버전을 통하여 많은 지원을 받을 수 있습니다. 더 나은 성능을 위해 PyPy를 사용 하는걸 고려해 보시길 바랍니다.

Ruby

Ruby 2.3은 올해(2016) 초에 여러 가지 성능 향상과 함께 릴리즈 되었습니다. Ruby는 스크립트 언어로서 좋은 선택이지만 Rails와 함께 사용 하면 더욱 빛을 발휘합니다. 현재는 앞으로 출시 될 Ruby 3 릴리즈를 현재 버전보다 3배 더 빠른 Ruby 3x3 계획이 발표되었습니다.

PHP

PHP 7.1은 12월에 릴리즈 되었습니다. 7.1에서는 7.0에 비해 성능이 크게 향상 되어 이제는 PHP도 웹 어플리케이션을 빠르게 구축가능한 플랫폼으로 변화시켰습니다. PHP를 이용하여 최신 웹 트렌드의 웹 앱을 만들고 싶다면 PHP: The Right Way(한글판은 여기)를 참고하시기 바랍니다.

JAVA

JAVA 9는 2017년에 릴리즈될 예정입니다. HTTP 2.0과 REPL 같은 새로운 API들이 제공 될 예정입니다. 해당 기능은 많은 JAVA 개발자들의 요구에 의해 추가되었으며, JAVA 프로젝트에 큰 바람을 불어넣어줄 것이다. 만약 JAVA를 사용하지 않는 개발자라면, 수많은 JVM 기반의 언어 중에서도 Kotlin과 Scala를 살펴보는 것도 좋을듯 합니다.

Swift

Swift 3은 MacOs와 IOS의 현대적인 프로그래밍이 가능한 Apple에서 새로 밀고있는 언어이며 올해 초에 공개하였습니다. 또한 Swift는 오픈소스이고 커뮤니티 활동이 활발한 상태이다. Swift 4가 2017년에 출시 될 예정으로 보이며, API 서버가 도입되어 웹 앱 이외에도 서버측 코드를 작성할 수 있는 좋은 선택이 될 듯 합니다.

만약 조금 더 흥미로운것을 찾고 있다면 루비와 유사한 구문과 우수한 성능의 Crystal과 Elixir를 확인해 보시기 바랍니다. 또한 Haskell 또는 Clojure와 같은 함수형 언어를 살펴보시길 바랍니다. 그외에 추천하는 언어는 Rust와 Go입니다.

한가지 이상 배우기 : JS (ES2017), TypeScript, C #, Python, Ruby, PHP7, Java / Kotlin / Scala

Frontend

웹 플랫폼에서는 Web Assembly와 Service Workers라는 두가지 주요 발전이 있었습니다. 이 두가지 기술로 인하여 네이티브 어플리케이션과의 차이를 좁히고 웹 어플리케이션이 조금 더 빠르게 동작가능하게 해주었습니다. 특히 Service Workers의 경우 Progressive Web Apps이 가능하게 하고 미래에 더 많은 API를 사용할 수있는 웹 플랫폼에 대한 알림을 지원합니다.

ANGULAR 2

Angular 2는 올해에 정식 릴리즈 되었습니다. 구글이 이 프레임워크를 지원하고 있으며, 큰 규모의 프로젝트에서 주목을 받고 있습니다. 웹을 이용하여 데스크탑 모바일 앱까지 작성이 가능하도록 방대한 기능을 포함하고 있습니다. Angular2는 TypeScript로 작성되었으며, Angular 2 개발 시에도 TypeScript를 권고하고 있습니다. 관련 자료가 많이 있으며 2017년 Angular 2를 배우는 것은 좋은 투자가 될 것 입니다.

VUE.JS

Vue.js 도 올해 2.0이 릴리즈 되었습니다. Angular, React 및 Ember에서 좋은점들을 도입하여 사용하기 쉬운 프레임워크로 만들어졌습니다. 또한 Angular.js 나 React에 비해 가볍고 좋은 성능을 가졌습니다. 우리가 만든 Vue.js 튜토리얼들 중 하나를 시작하여 올해에 사용해 보시기 바랍니다.

Ember

Ember.js는 Javascript 프레임워크에서 좋은 선택 중 하나 입니다. 데이터 바인딩, 템플릿 자동 업데이트, 컴퍼넌트 및 서버 측 렌더링을 지원합니다. 다른 프레임워크와 비교했을 때 좋은점은 조금 더 성숙하고 안정되어 있는 프레임워크라는 것 입니다. 큰 변화(Breaking Changes)가 적은편이며 커뮤니티에서는 이전 버전의 호환을 중요시 여기고 있습니다. 오래유지해야하는 애플리케이션에 좋은 선택이 될 것 입니다.

그 외에 살펴볼만한 프레임워크로는 Aurelia와 React가 있습니다. React 생태계가 작년에 상당히 복잡해져서 초보자들에게 권하기 어려운 프레임워크가 되었습니다. 하지만 이미 React가 익숙한 개발자들은 GraphQL, Relay, Flux 및 Immutable.js등을 이용하여 풀스텍 솔루션을 만드는것을 추천합니다.

어떠한 프레임워크라도 Bootstrap 제외하고 구성이 다 되었다고 언급하기 어렵습니다. 현재 4버전은 알파 단계이며, 2017년 정식 릴리즈 될 예정입니다. 새로 추가되는 기능으로는 다용도 카드 컴퍼넌트와 플렉스박스 그리드가 있으며(일반 그리드와의 비교) Bootstrap은 점점 현대적인 프레임워크가 될 것이며 사용하는 즐거움도 더해질 것입니다.

SASS와 LESS는 오늘날 가장 인기있는 CSS 전처리기입니다. 일반 CSS가 여러 지원이 추가되었지만, SASS와 LESS의 mixins, 함수 및 코드 구성에 대한 지원이 여전히 훌륭합니다. 아직 접해보지 못했으면 해당 SASS와 LESS 가이드를 참고해주시기 바랍니다.

한가지 이상 배우기 : Angular 2, Vue.js, Ember, Bootstrap, LESS/SASS.

Backend

Backend에도 수많은 선택이 있으며, 성능요구사항에 맞는 선택을 할 수 있습니다. 최근 웹 개발 트렌드는 비지니스 로직은 백엔드로 옮겨지고 있고 프론트엔드나 모바일 앱에서는 이를 API를 통해 연결하는 방식을 선호합니다. 그러나 풀스택 프레임워크는 여전히 개발하기 더 간편하고 빨라 웹 앱 개발에 좋은 선택지중 하나입니다.

NODE.JS

Node.js 는 JavaScript를 서버사이드에서 실행하는 대표적인 방법입니다. 올해 Node.js는 많은 릴리즈가 있었으며, 릴리즈 내용으로는 성능 향상과 ES6 표준에 대한 지원이 추가되었습니다. Node.js에는 API와 서버 데스크탑 어플리케이션 심지어 로봇까지 만들 수 있는 프레임워크와 대규모의 모듈 관리가 가능한 커뮤니티가 있습니다. 이러한 것들에 관심이 있는 당신이 살펴볼 프레임워크로는 Express, Koa, Next, Nodal등이 있다.

php

PHP 는 가장 맨처음 나온 웹 언어이자 가장 많이 알려져 있고 가장 많은 프레임워크를 사용하는 언어입니다. Laravel은 훌륭한 기능과 정리된 문서 덕분에 훌륭한 커뮤니티가 형성했습니다. Zend Framework는 비지니스용 프레임워크로 3버전을 릴리즈 하였습니다. Symfony는 올해에도 많은 릴리즈가 되여, 풀스택 프레임워크로 좋은 선택이 됩니다.

Ruby

Ruby 의 경우 Rails 프레임 워크를 사용하는 것이 가장 좋습니다. 웹 소켓, API 모드 등이 지원되는 5.0 버전이 2016년에 릴리즈 되었습니다.

Sinatra는 작은 어플리케이션에서는 좋은 선택이며, 2017년에 2.0 릴리즈 될 예정입니다.

Python

Python 자체에는 이미 Django와 Flask의 형태의 full/minimal 프레임워크가 있습니다. Django 1.10는 8월에 릴리즈 되었는데, Postgres를 위한 Full-text-search를 지원하고 시스템 점검을 위한 중간단계의 레이어를 도입하였습니다.

JAVA

Java 생태계에도 인기있는 프레임워크가 있습니다. P lay와 Spark 두가지 모두 Scala에서 사용이 가능하며 인기있는 프레임워크 입니다.

다른 것으로는 Phoenix라는 것이 있습니다. Elixir로 작성되었고 Rails보다 뛰어난 성능을 보이고 있어 Rails의 자리를 노리고 있는 프레임워크입니다.. 2017년에 Elixir를 배워보려고 한다면, Phoenix도 같이 사용해보시길 바랍니다.

한가지 해보기: 풀스택 프레임워크나 마이크로 프레임워크

Databases

PostgreSQL

PostgreSQL 는 올해 2개의 버전이 릴리즈 되었습니다.(9.5와 9.6) 이 릴리즈를 통하여 mysql에서의 UPSERT 같은 기능과(일명 ON DUPLICATE KEY UPDATE) 더나은 full text search, 병렬 쿼리와 효율적인 복제, 집합 구성, 인덱싱, 정렬을 통해 성능을 끌어올렸습니다. Postgres는 대규모, 테라바이트급 데이터셋, 연산이 많은 웹 앱에 최적화 되어 사용하고 있습니다.

MySQL

MYSQL 는 2017년에 8.0 메이저 버전 릴리즈를 할 예정입니다. 시스템에 많은 개선이 이루어질 것으로 예상됩니다. MYSQL은 여전히 가장 보편적인 데이터베이스이며, 앞으로 릴리즈될 버전으로 인하여 개발 업계 전체가 이점이 있을 것입니다.

CouchDB

NOSQL 유저에게는 CouchDB를 추천합니다. CouchDB는 REST-ful HTTP API를 제공하는 빠르고 확장 가능한 JSON 저장소입니다. 이 데이터베이스는 사용하기 쉽고 뛰어난 성능을 제공합니다. PouchDB는 브라우저에서 완전히 작동하며 CouchDB와 동기화 할 수 있습니다. 이렇게하면 오프라인 상태일땐 Pouch를 사용하고 인터넷 연결이 가능 해지면 자동 동기화가 가능합니다.

REDIS

REDIS 는 키-값 형식의 데이터베이스 중 인기있는 데이터베이스입니다. REDIS는 작고 빠르며 다양한 기능을 제공합니다. memcache 대신 REDIS를 사용 할 수 있으며, NoSQL 대신 쓰거나 메시지 전송과 동기화를 위한 채널로 사용할 수 있습니다. Redis에서 제공하는 수 많은 데이터 구조를 골라서 사용할 수 있으며, 4.0 버전이 나오면 모듈 시스템이 도입되어 복제셋 구성이 더욱 개선될 것입니다.

한가지 해보기: Postgres, MySQL, CouchDB, Redis.

Tools

Yarn

Yarn 은 Facebook에서 개발한 NODE.JS 패키지 관리자 입니다. Yarn은 NPM을 개선한 도구이며, 더 빠른 설치, 향상된 보안 및 안정적인 빌드를 제공합니다. Yarn은 기존의 package.json 포맷 및 npm 설정이 그대로 호환되기 때문에 설치가 간단합니다.

Visual Studio Code / Atom

오픈 소스 에디터 중 인기가 많은 에디터는 Visual Studio Code와 Atom이 있으며, 두 에디터는 1년간 놀라운 발전이 있었습니다. 두 에디터의 공통점으로는 웹 기술로 제작되었으며, 커뮤니티에 많은 개발자들의 관심을 받고 있습니다. 게다가 플러그인을 설치하여 각 프로그래밍 언어에 대한 문법 체크, 코드 최적화, 리팩토링을 비롯한 기능을 추가가 가능합니다.

git

git 은 가장 인기 있는 코드 버전 관리 시스템입니다. 서버가 없이도 컴퓨터의 모든 폴더를 저장소로 변환 할 수 있습니다. 코드를 공유하려면 GitLab, Bitbucket 및 Github와 같은 여러 선택지가 있습니다. 2017 년에는 git 커맨드 라인과 친해져보기를 읽어보길 권장합니다.

Electron / NW.js

데스크톱 응용 프로그램은 아직 죽지 않았습니다. 웹 앱이 점점 더 많은 기능을 제공하지만, 때로는 웹 플랫폼에서 사용할 수없는 강력한 기능과 API가 필요합니다. Electron 및 NW.js와 같은 도구를 사용하면 웹 기술을 사용하여 데스크톱 응용 프로그램을 만들 수 있습니다. OS 권한에 접근도 가능하고 npm의 모듈을 사용할 수 있습니다. 이 툴들에 대해 좀 더 알아보고 싶다면 Electron 가이드와 NW.js 가이드를 참고하여 주시기 바랍니다.

DevOps

최근 소프트웨어 개발 팀 구성의 트렌드는 배포를 담당하는 개발자를 구성원으로 포함하는 것 입니다. DevOps라고도 불리는데, 이럴 경우 버그를 더 빠르게 수정하고 더 빨리 릴리즈 할 수 있습니다. 운영 경험이 있는 개발자는 업계에서도 상당히 귀중한 인재이며, 최신 기술에 관심이 많다면 더욱 큰 도움이 됩니다. 또한 이러한 업무를 위한 우리가 추천하는 도구는 Ansible와 Docker 입니다. 리눅스 커맨드 라인과 기본 시스템 관리자 권한에 대한 경험이 있으면 더욱 좋습니다.

하나 이상 해보기: Yarn, Git, Visual Studio Code, Electron, Ansible, Docker

Tech

cloud

Cloud 는 소프트웨어 업계 전반적으로 장악하여 데이터센터를 운영하는 회사들은 데이터센터를 축소하거나 Cloud로 옮기고 있습니다. 대표적인 Cloud 서비스는 AWS, Google Cloud, Azure이며, 세 가지 서비스 모두 가상 머신, 호스트 데이터베이스, machine learning 서비스 등을 포함 한 강력한 기능 확장 세트를 보유하고 있습니다. 사용 요금이 급격히 인하되고 있어서 소규모 업체나 개인 개발자들도 클라우드를 이용할 수 있게 되었습니다. 2017년에는 이들 서비스중 하나를 이용해서 작은 프로젝트를 하나 해보는 것도 좋은 경험이 될 것 입니다.

Artificial Intelligence(AI 인공지능)

AI 는 2016년의 이슈였습니다. 음성 인식과 이미지 분류는 사용자가 접할 수 있는 극히 일부의 기술이며, 기계는 사람과 비슷한 인지 능력을 갖는 정도까지 진화하였습니다. 인공지능과 machine learning을 이용한 신생 기업(스타트업)도 많이 등장하였습니다. 여기에 Google의 Tensor Flow나 Microsoft의 Cognitive Toolkit과 같은 오픈 소스 프로젝트들도 릴리즈 되었습니다. machine learning은 수학과 밀접하게 연관된 분야이며, machine learning을 시작하기에 도움이 되는 온라인 코스도 있습니다.

VR / AR

가상 현실 (VR)과 증강 현실 (AR)은 이미 존재 하는 기술이였지만, 최근 매력적인 경험을 제공 할 만큼 충분히 성숙하였다. Facebook (Oculus Rift), Google (Daydream) 및 Microsoft (Windows Holographic)는 모두 가상 현실 플랫폼을 보유하고 있고 third party 개발자를 환영하고 있습니다. 아직은 VR 헤드셋은 멀미를 줄이거나, 게임 이외의 분야에서도 즐거운 경험을 제공하기 위한 도전 단계에 있습니다.

한가지 해보기: Cloud deployment, Machine Learning library, VR Development

2017년에도 처음 듣거나 아직 해보지 못한 기술이 엄청 많네요. 2017년은 더욱 더 열심히 공부해야 겠습니다.

해당 번역에 대해 문제가 있거나 수정 사항이 있으실 경우 피드백 감사드립니다.

발번역이라 조금 앞뒤가 안맞거나 잘못 번역한 문장이 있을 수 있습니다.

2017년도 화이팅!!

[ 최현우 마술공연 ] 2016 The 최현우 Ask？＆ answer！. 후기

권윤학 — Wed, 28 Dec 2016 22:47:33 +0900

해당 포스트는 제가 100% 지불하고 작성한 후기입니다.

이번 크리스마스에는 최현우 마술사의 공연을 보고왔습니다.

인터파크 같은 곳에서 구매하면 제법 가격이 있는편인데 소셜에서 크리스마스 시즌에도 구매가 가능해져서 싸게 구매했습니다.

[인터파크 티켓 정가]

[위메프 티켓 가격]

저 같은 경우 S석이 잘 안보일까바 R석으로 구매했었는데 다녀와보니 공연장이 작아서 S석도 잘 보일 것 같네요.

공연장 외관 모습입니다. 공연 시작 2시간 전에 도착해서 사람이 별로 없을때 입니다.

들어가면 바로 매표소가 보이고 옆에 포토존도 있네요.

케이블 TV VOD 와 함께 이벤트 진행중이여서 페이스북 조아요 눌러주고 직원분께 보여드리면 카드 / 퍼즐 등 중 하나를 준다고해서

저도 카드를 받았습니다. (일반 카드인줄 알고 받았는데 트릭용 카드여서 쓸데가 없는건 함정....)

어떤 트릭용 카드인지는 Youtube에서 확인 가능하니 해당 링크에서 확인해주세요. 링크

저와 제 여자친구는 카드를 받았는데 동영상 보고 후회를 했다는....

티켓발매 가능한 시간이 되서 티켓을 받고 공연장안으로 입장하였습니다. 공연장 안은 사진촬영이 불가능해서 일부러 사진을 촬영하지 않았습니다.

공연 후기는 최현우씨의 재치와 입담 그리고 마술까지 어울러져 재미있게 봤습니다.

주말 데이트 혹은 가족 나들이로 마술 공연 다들 어떠하신가요??

서울 올림픽공원에서는 1월 1일까지만 공연하고 2월 11월부터 부산 공연이 예정되어 있다고 하네요.

[PHP] PHP 표준 권고(PSR) - PHP Standard Recommendation

권윤학 — Mon, 26 Dec 2016 22:06:51 +0900

PHP Standard Recommendation

국내에서는 아직도 많은 기업과 개발자들이 PHP를 이용하여 웹 개발을 하고있습니다. PHP는 JAVA나 Python 같은 언어에 비해 구식의 스타일을 쓰는 경향이 많다보니 이것을 개선할려는 움직임으로 Modern PHP이 강조되고 있는데, 이 Modern php 권고 사항으로 psr이 포함되어 있습니다.

(modern php에 관련하여 궁금하실 경우 해당 링크에서 확인하시면 자세한 내용을 확인하실 수 있습니다. 링크)

그럼 psr이 도대체 무엇일까요?

psr은 PHP-FIG (PHP Framework Interop Group) 이 주도하여 제안한 PHP 표준 권장안입니다. 즉 Code Convention 중 하나입니다.

최근에 나오는 Modern php 프레임워크 대부분은 이 psr를 표준으로 하여 개발되고 있습니다.

2016.12.26일 기준 통과된 규약은 7개입니다.

기본적으로 봐야하는 규약은 PSR-1 / PSR-2 / PSR-4 정도 되겠습니다.

PSR-1과 PSR-2는 코딩 스타일에 관련된 내용이며 PSR-4은 autoload와 관련 된 내용입니다.

PSR-1 Basic Coding Standard

- 파일 인코딩은 BOM(Byte order Mark)이 없는 UTF-8만 사용

- 클래스 이름은 반드시 StudlyCaps 와 같이 첫 글자를 대문자를 이용

- 네임스페이스와 클래스는 오토로딩 표준(PSR-4)를 따를 것

<?php
// PSR-4
namespace Vendor\Model;
 
class Foo
{
}

- 클래스 상수(const)는 반드시 모두 대문자로 작성하고 구분자로 _ 를 이용하여 작성

- 클래스 메서드명은 반드시 camelCase() 처럼 카멜케이스(camelCase)로 작성.

<?php
namespace Vendor\Model;
 
class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';

    public function camelCase() {
        return "";
    }
}

PSR-2 Coding Style Guide

- PSR-1를 기본으로 합니다.

- 들여 쓰기는 tab 대신 4칸의 공백 사용합니다.

- PHP 닫는 태그(?>) 는 사용하지 않습니다.

- namespace 선언 후 다음줄은 공백줄이며 여러개의 use문은 줄 공백 없이 사용 후 마지막 use 문 다음에 공백줄을 사용합니다.

- 클래스와 메서드의 여는 괄호는 다음 줄에 사용하고 닫는 괄호는 내용 다음 줄에 닫아야 합니다.

- 한줄의 길이는 120자 이하로 사용할 것(권고사항입니다. 강제가 아니라)

- 메서드 접근제어자(private, public, protected)는 반드시 명시해야 합니다.

- abstract 과 final은 접근 제어자보다 앞에 있어야 하며 static은 접근 제어자 뒤에 나와야 합니다.

- 제어문 ( if / for 등) 여는 중괄호는 같은 줄에 사용하고 닫는 중괄호는 내용 다음줄에 닫으며 닫은 후 한줄 공백을 사용합니다.

- if 나 elseif 같은 제어 관련 구문은 제어문 뒤에 한 개의 공백을 두고 그 후에 괄호를 사용하고 조건문을 기술할 것. 함수 호출이나 메소드 호출은 메소드명 뒤에 공백이 있으면 안됩니다.

설명이 길어서 무슨 말인지 도저히 모르실 것 같아 예시문장을 준비하였습니다.


<?php
namespace Vendor\Package;
  
use FooInterface;
use BarClass as Bar;
  
class Foo extends Bar
{
    public function sampleFunction($a, $b = null)
    {
        if ($a === $b) {
            bar();
        } elseif ($a > $b) {
            $foo->bar($arg1);
        }
    }
}

요즘은 IDE에 PSR-2를 잡아주는 기능이 있어서 저는 PHPstorm을 이용하여 확인하며 수정하고 있습니다.

PSR-4 Autoloader

PSR-4는 PSR-0을 대체하여 나온 오토로딩 표준입니다. PSR-4의 핵심은 네임스페이스 및 서브네임스페이스를 파일 시스템 디렉토리에 대응시킨다는 것입니다. 이러한 PSR-4를 지키는 autoloader를 직접 구현할 필요없이 컴포저를 사용하여 PSR-4 autoloading이 가능합니다.

이외에 Modern PHP에 대한 내용이 궁금하신다면 Josh LockHart의 Modern PHP 책을 한번 읽어보시기 바랍니다.

저는 최근 프로젝트에 Laravel를 사용하기 시작하여 관심을 가지고 공부하기 시작했습니다.

[PHP] MAMP를 이용한 Windows/MAC 에서 PHP 개발 환경 쉽게 셋팅하기

권윤학 — Tue, 20 Dec 2016 08:21:33 +0900

이전 포스트에서는 수동으로 Apache / Mysql / Php 를 셋팅하는 방법에 대해 포스트를 했었습니다.

만약 수동으로 Php 개발 셋팅을 하셨다면 해당 포스트를 확인하여 Apache와 Mysql 서비스 제거를 하신 후 MAMP를 설치하여 주시기 바랍니다.

Windows에서 Apache / Mysql 서비스제거

이번 포스트에서는 수동이 아닌 프로그램 설치 한번으로 PHP 개발 환경을 구축 하도록 하겠습니다. 예전에는 APMSetup이라는 프로그램을 이용하여 PHP 개발 환경을 한번에 설치가 가능했는데 APMSetup의 경우 더 이상 업데이트가 되지 않아 php7도 지원이 안되며 windows10에서도 설치가 불가능합니다.

이러한 불편함을 없애고자 찾아보니 MAMP라는 프로그램을 이용하면 php / apache or nginx / mysql을 쉽게 설치 및 관리가 가능하다고 하네요.

1. 다운로드

https://www.mamp.info/en/downloads/

해당 링크에서 mamp를 다운로드합니다.

제가 포스트 작성한 시기 버전을 위의 이미지를 참고하시면 되겠습니다.

MAMP는 Mac / Windows 둘다 사용이 가능하니 Mac사용 하시는 분들도 참고하시면 좋겠습니다.

2. 설치하기

다운로드 완료 후 설치파일을 실행합니다.

설치 시 주의사항은 아래의 그림처럼 MAMP pro도 같이 설치 할꺼냐고 묻는 항목이 있는데 이때 체크를 해제하시면됩니다.

MAMP PRO는 유료!!

그외에는 모두 Next로 무난하게 설치합니다. 그리고 설치경로를 물어볼때 경로는 편한 위치로 하시는게 좋습니다.

저는 D:\MAMP로 설치하였습니다.

모든 설치가 완료되면 MAMP를 실행하신 후 아래의 그림처럼 start server를 클릭해주면 Apache와 Mysql이 자동으로 실행됩니다.

현재 Apache서버로 실행되고 있는데 Nginx 서버로 변경을 원하실 경우 Preferences를 누르신 후 Web Server탭을 눌러주시면 아래의 그림처럼 서버 변경이 가능합니다.

PHP버전 변경을 원하실 경우에는 PHP 탭을 눌러 원하시는 버전을 선택이 가능합니다.

수동으로 설치했을때와 다르게 MAMP하나로 컨트롤이 가능하니 정말 편하네요.

mysql의 경우 MAMP를 설치하면 기본적으로 localhost/phpmyadmin으로 접속이 가능합니다.

Apache나 Nginx의 설정 변경이 필요한 경우 MAMP가 설치된 폴더에서 변경 하시면 됩니다.

php설정도 마찬가지이고요.

MAMP의 단점이라면 php를 버전별로 셋팅이 가능하다보니 조금 무거운점을 뽑을 수 있지만 간편함을 생각하면 큰 단점은 아니라고 생각합니다.

[PHP] windows 에서 Apache, Mysql 서비스 제거

권윤학 — Tue, 20 Dec 2016 08:12:16 +0900

Window에서 Apache, Mysql 서비스 제거하기

이번 포스트는 윈도우에서 수동으로 설치했던 Apache와 Mysql을 제거 하기 위해 서비스를 제거하는 방법을 알아볼까 합니다.

제거할려는 이유는 예전에는 APMSetup이라는 프로그램을 이용하여 Apache와 Mysql을 쉽게 컨트롤 할 수 있었는데,

현재 APMSetup은 업데이트가 안되어서 php5버전만 사용이 가능합니다만

MAPM이라는 프로그램을 이용하면 Apache와 Nginx까지 쉽게 컨트롤 가능하며 php버전도 자유롭게 변경이 가능하여

다음 포스트에서는 MAMP를 이용한 php 개발 환경을 셋팅하고자 합니다.

그럼 Apache와 Mysql의 서비스를 제거하는 방법을 알아볼까요?

1.Apache 서비스 제거

Apache가 설치된 폴더로 cmd창을 이용하여 이동합니다. 저는 d:\apm\Apache24 폴더입니다.

그 다음 bin 폴더로 이동합니다. 그러면 아래와 같은 그림이 되겠습니다.

아래의 명령어를 입력하여 아파치 서비스를 제거합니다.

httpd.exe -k uninstall

아래와 같이 성공이라고 뜨면 아파치 서비스가 제거됩니다.

2. Mysql 서비스 제거

그 다음은 Mysql 서비스를 제거하도록 하겠습니다. mysql은 apache와 다르게 서비스를 먼저 중지시킨후 제거가 가능합니다.

제어판 -> 관리도구 -> 서비스 로 이동합니다.

그 다음 mysql을 찾아 중지를 해줍니다.

이후부터는 Apache랑 동일합니다. Mysql이 설치된 폴더로 이동합니다. 저는 d:\apm\mysql 폴더입니다.

bin폴더로 이동하시고 아래의 명령어를 입력합니다.

mysqld --remove

아래와 같이 뜬다면 성공입니다.

여기까지 완료했으면 apm 폴더들을 제거가 가능합니다.

다음 포스트에서는 MAMP를 이용하여 php 개발 환경을 셋팅하도록 하겠습니다.

[mac OS X] MAC에서 npm install sudo 없이 하기 (권한 문제)

권윤학 — Tue, 13 Dec 2016 21:09:17 +0900

mac os 에서 npm install -g 로 글로벌 설치 시 권한 문제가 발생하여 sudo npm install -g를 이용하여 설치를 하였는데

이게 매번 불편하여 방법을 찾아보니 아래의 방법을 통해 해결하였습니다.

sudo chown -R $USER /usr/local

terminal에 위의 명령어를 입력 하신 후 부터는 npm install -g 를 sudo 없이 사용이 가능합니다.

[PHP] Window10에서 APM 환경 구축하기 - 3. MYSQL 설치

권윤학 — Wed, 30 Nov 2016 19:09:10 +0900

Windows 10 (윈도우 10) 에서 APM 환경 구축하기

Windows10에서 APM 환경 구축하기 시리즈 보기

1. Apache 설치

2. PHP 설치

3. MYSQL 설치

- MYSQL 설치하기

php를 windows에서 사용하기 위해 구축하는 과정에서 남긴 포스트입니다.

지난 포스트에 이어 이번에는 MYSQL 을 설치해보도록 하겠습니다.

해당 포스트는 이전 포스트인 Apache 설치 / PHP7 설치 포스트에 이어서 진행 하는 내용이오니 안보신분들은 위에 목차에서 확인해 주시기 바랍니다.

1. MYSQL 다운로드

http://dev.mysql.com/downloads/mysql/

위의 링크에서 MYSQL Community Server를 다운로드 받습니다.

2. 압축 해제

Apache와 php가 설치된 D:\apm\ 폴더에 압축 해제 및 폴더명을 mysql로 변경해 하도록 하겠습니다.

3. MYSQL install

압축 해제한 D\apm\mysql 폴더안에 bin이라는 폴더로 cmd(관리자 권한으로 실행)창을 이동시킵니다.

그 후 아래의 명령어를 입력합니다.

mysqld --install

설치 후에 제어판 -> 관리도구 -> 서비스 에서 mysql 서비스를 시작합니다.

여기까지 mysql 설치과정입니다. 이제 php와 연동을 하도록 하겠습니다.

php폴더로 가시면 php.ini 파일이 있습니다. 해당 파일을 메모장이나 에디터로 실행해주세요.

그리고 mysqli 모듈을 추가해줍니다. 기존에는 앞에 ; 주석으로 되어있으니 주석만 제거하시면됩니다.

;extension=php_mysqli.dll -> extension=php_mysqli.dll

extension_dir 설정도 php가 설치된 경로기준으로 변경합니다.

extension=php_mysqli.dll
extension_dir = "D:\apm\php7\ext"

저장 하신 후 제어판 -> 관리 도구 -> 서비스 에서 apach를 재실행합니다.

여기까지 하시면 mysql 설치 및 php와 연동이 완료됩니다.

[PHP] Window10에서 APM 환경 구축하기 - 2. php7 설치

권윤학 — Mon, 28 Nov 2016 22:13:24 +0900

Windows 10 (윈도우 10) 에서 APM 환경 구축하기

Windows10에서 APM 환경 구축하기 시리즈 보기

1. Apache 설치

2. PHP 설치

3. MYSQL 설치

- PHP 7 설치하기

php를 windows에서 사용하기 위해 구축하는 과정에서 남긴 포스트입니다.

지난 포스트에 이어 이번에는 PHP7 을 설치해보도록 하겠습니다.

해당 포스트는 이전 포스트인 Apache 설치 포스트에 이어서 진행 하는 내용으로 안보신분들은 위에 목차에서 Apache 설치 포스트를 확인해 주시기 바랍니다.

1. PHP 7 다운로드

http://windows.php.net/download/

PHP7은 위의 링크에서 다운로드 가능합니다. 해당 포스트 작성 시점에서 PHP7 가장 최신 버전은 7.0.13입니다.

다운로드시 주의점은 Non Thread Safe와 Thread Safe 차이점입니다.

- Thread Safe

윈도우의 경우 멀티 쓰레드 방식으로 구동이 되고있으나, PHP는 멀티 프로세스 방식으로 구동이 되고있어 Windows용 PHP는 항상 Thread Safe 방식으로 제공이 되고있었습니다. 이 Thread Safe 방식은 리눅스 같은 OS에서 구동되는 PHP보다는 성능이 저하되지만 Window에 호환된 버전이여서 안정성이 높습니다.

- Non Thread Safe

이러한 성능저하의 문제점을 해결한 방식이 Non Thread Safe 방식입니다. Non Thread Safe 방식이다 보니 연동 방식이 다른점이 많습니다. 그래서 저는 Thread Safe 방식으로 설명을 드리겠습니다.

보통의 경우 아래와 같은 경우 사용한다고 하니 참고하시기 바랍니다.

Windows + IIS(ISAPI) : Thread Safe 버전
Windows + IIS(CGI or FastCGI) : Non Thread Safe 버전
Windows + Apache(MPM worker) : Thread Safe 버전
Windows + Apache(MPM prefork) : Non Thread Safe 버전

저는 64비트 PC여서 64비트 Thread Safe Zip 파일을 다운로드 받았습니다.

2. 압축 해제 및 폴더 이동

압축은 기존에 Apache를 설치했던 D:\apm\ 폴더에 압축을 풀었습니다. 폴더명은 php7으로 변경하였습니다.

그 후 php7 폴더안에 보시면 php.ini 파일이 없습니다. php.ini-development 와 php.ini-production 파일 둘중 하나를 파일명을 변경해줘야 하는데요 저는 php.ini-development을 php.ini으로 파일명 변경 하였습니다.

파일명을 변경한 php.ini를 열어서 아래의 내용을 수정 (php를 설치한 경로안에 ext폴더로)후 저장합니다.

extension_dir = "D:\apm\php7\ext"

여기까지 하셨으면 Apache를 재시작합니다.

제어판 -> 관리도구 -> 서비스 -> Apache24 -> 중지 후 시작

3. 연동 테스트

Apache에 php7 연동을 하였습니다.

제대로 연동이 되었는지 확인은

D:\apm\Apache24\htdocs 폴더 안에 phpinfo.php 같은 파일명으로 아래의 내용을 저장 하신 후

<?php  phpinfo(); ?>

http://127.0.0.1/phpInfo.php에 접속 하였을때 아래와 비슷하게 페이지가 보인다면 정상입니다.

이번 포스트에서는 Apache 설치에 이어서 PHP7까지 설치해 보았습니다. 다음 포스트에서는 이어서 MYSQL를 설치하도록 하겠습니다.

[PHP] Window10에서 APM 환경 구축하기 - 1. Apache 설치

권윤학 — Sun, 27 Nov 2016 12:36:39 +0900

Windows 10 (윈도우 10) 에서 APM 환경 구축하기

Windows10에서 APM 환경 구축하기 시리즈 보기
1. Apache 설치
2. PHP 설치
3. MYSQL 설치
- Apache 설치하기

php를 windows에서 사용하기 위해 구축하는 과정에서 남긴 포스트입니다.

PHP는 서버사이드 언어로 보통은 APM(Apache 서버 / PHP / MYSQL db) 으로 많이 사용하고 있습니다만

요즘은 apache 대신 NGINX와 MYSQL 대신 Maria를 사용하는 LEMP Stack도 많이 쓰인다고 합니다.

해당 포스트는 APM 환경을 구축하도록 하겠습니다.

1. Apache 다운로드

http://apachelounge.com/download/

위의 링크에서 다운로드가 가능합니다. 제가 다운받을때의 최신버전은 apache 2.4.23버전입니다.

제 PC는 64비트 pc이기때문에 win64를 다운받았습니다.

2. 압축해제

다운로드 받은 zip파일을 원하는 경로에 압축 해제합니다.

저는 (d:\apm\) 해당 경로에 압축을 해제하였습니다.

압축 해제시 Apache24폴더와 ReadMe 파일이 있는데 ReadMe에는 설치 방법이 자세히 나와있습니다. (물론 영어로요)

ReadME 파일은 삭제하셔도 됩니다. 그러면 현재 폴더는 c:\apm\Apache24 폴더가 생성되는거겠죠?

3. conf 파일 수정

Apache24 폴더안에 conf 폴더(D:\apm\Apache24\conf)에 가시면 httpd.conf 파일이 존재합니다.

해당 파일에서 변경 할 내용이 있습니다.

먼저 ServerRoot 관련 내용인데 아래 처럼 Define 구문이 있는경우면 SEVROOT 값만 변경하시면됩니다.

그게 아니라면 ServerRoot 값과 DocumentRoot 값 두개다 직접 변경하셔야합니다.

또한 저는 php7을 같은 d:\apm\php7 폴더에 설치할 예정입니다.

그래서 php7 모듈 로드를 맨아래에 추가하였습니다.

Define SRVROOT "d:\apm\Apache24"
ServerRoot "${SRVROOT}"
DocumentRoot "${SRVROOT}/htdocs"

#php7 모듈 추가
LoadModule php7_module "D:\apm\php7\php7apache2_4.dll"
AddHandler application/x-httpd-php .php
# configure the path to php.ini
PHPIniDir "D:\apm\php7"

SetHandler application/x-httpd-php

4. httpd 서비스 추가 및 실행

cmd(command line interface) 창을 관리자 모드로 실행합니다.

Apache가 설치된 폴더 안에 bin 폴더로 이동합니다. (저의 경우 d:\apm\Apache24\bin 폴더이겠군요)

아래와 같이 명령어를 입력해주시면 apach 서비스가 설치됩니다.

단 여기서 VCRUNTIME140.dll 관련 에러가 나실 경우는 아래의 링크에서 다운로드 받아서 설치하신 후 진행 해 주시기 바랍니다.

http://www.microsoft.com/en-us/download/details.aspx?id=48145

httpd.exe -k install

그 후 아파치 서비스를 실행합니다.

그 후 제어판 > 관리도구 > 서비스에서 apache 서비스가 아래의 그림처럼 실행되어있는 경우 정상적으로 설치 및 실행된걸로 확인 가능합니다.

혹은 localhost로 접속하였을때 아래와 같은 페이지가 나타난다면 정상입니다.

이번 포스트에서는 apache를 수동 설치 하는 방법에 대해 알아봤는데요 다음 포스트는 php7를 이어서 수동으로 설치해보도록 하겠습니다.

[개발자 노트북 스티커] 프로그래머 스티커 REDBUBBLE 직구 후기

권윤학 — Thu, 3 Nov 2016 23:17:18 +0900

REDBUBBLE 스티커 직구 후기

개발자들이 노트북에 스티커를 붙이고 다니는 모습을 많이들 보셨을텐데

도대체 왜? 스티커를 붙이고 다니는 것이며, 저런 스티커는 어디서 구하는 것이지? 라는 생각을 많이 했습니다.

스티커를 노트북에 붙이는 이유는 자신의 관심사를 표현하는 거라고 합니다.

저는 Node.js에 관심이 있어요. 이러한 표현을 노트북에 Node.js를 붙여서 표현하는 방식인셈이죠

그래서 저도 한번 저의 관심사들을 표현하기 위해 스티커 구매하는 곳을 찾다. REDBUBBLE이라는 해외 사이트를 찾았습니다.

이 사이트는 개발쪽 외에 일러스트, 케릭터, 디자인문구 등의 프린트 된 스티커 / 티셔츠 / 가방을 판매 하는 사이트입니다.

이 사이트외에 다른 사이트도 있는데

굳이 이 사이트에서 구매한 이유는 바로!!

6개 (수량 종류 상관없음) 이상 구매 시 50% 할인!!

스티커만 구매 하면 배송비용도 비교적 저렴하기 때문에 부담없이 구매할 수 있었습니다.

2016-11-04 일 기준 빠른 배송은 11-09일(5일) 일반 배송은 25~29일(21~25일) 정도 소요된다고 합니다.

이렇게 배송이 왔습니다. 가려진 부분은 개인정보여서 가렸습니다.

구매한 스티커들입니다.

닌자는 귀여워서 같이 구매했습니다.

최근 관심이 생겨 공부중인 angular2 / ioinc2 / webpack / typescript 도 있으며

기존에 공부했던 backbone과 react도 같이 구매했습니다.

전부 small 사이즈로 구매했는데 생각보다 제법 컸습니다.

스티커를 붙일 노트북

전 원래 php / C# 개발자로 일을 시작해서 맥북을 아직 구매안했습니다. (2016 맥북 프로를 기다렸는데 터치바때매 고민중...)

ionic을 통한 하이브리드 앱 개발을 공부하면서 맥북의 필요성을 많이 느끼고 있습니다.(그 이전엔 node.js때매 고민을 잠깐했었습니다.)

왜 맥북을 고민하냐면 맥OS가 유닉스 기반이여서 터미널의 명령어가 서버의 리눅스와 동일하다 보니 node.js 프로그래밍시 window보단

편하고 예외도 적습니다. 또한 하이브리드 앱 개발시에는 IOS 앱을 빌드 할 수 있는건 맥OS에서 밖에 안되니

맥북을 구매 할 수 밖에없는 상황입니다.

스티커를 붙인 후 모습

큼직큼직해서 오히려 좋은 것 같습니다.

Backbone.js의 로고가 너무 커서.. git 로고는 키보드 옆쪽에 부착

구매 한 스티커 장바구니 및 가격

만약 스티커 외의 티셔츠, 가방 등이 들어가면 배송비가 뻥튀기되니 참고하시길 바랍니다.

개발자 스티커에 관심이 있으신분들은 REDBUBBLE에서 쇼핑 어떠하신가요?

https://www.redbubble.com

2017.01.08 업데이트 내용입니다.

댓글로 주문 방법에 대해 문의하시는 분이 계셔 추가로 업데이트하였습니다.

비회원이든 회원이든 상관없이 구매하실 상품을 장바구니에 담으신 후 장바구니에 가셔서 맨아래에 내려가면 아래의 그림처럼 배송방법을 선택하게 됩니다.

위에서 나라를 선택하시면 아래의 가격이 변하게 될텐데 보시면 위에는 1월 30일 ~ 2월 1일에 배송이 될꺼라는 얘기이며 아래는 아래는 1월 12일에 배송이 될거라는 얘기입니다. 즉 일반 배송이냐 퀵 배송이냐 차이이며, 가격차이가 약 20달러 정도 차이납니다.

일반 배송은 약 4달러 정도합니다.

배송방법을 선택하시면 결재방법을 선택하게 됩니다. 결재방법마다의 설명을 제가 잘 알지 못해서 이 부분은 딱히 설명드릴게 없네요.

결재 방법을 선택 하시고 나면 배송주소 정보를 입력해야합니다. 아마 이 부분 때매 물어보신 것 같습니다만 이 부분도 제가 잘 알지는 못하지만 일반적인 해외구매시 입력해야하는 부분을 참고하여 예시를 들어 보았습니다.

예시로 경복궁역의 주소로 입력하였으며 위의 그림은 http://www.juso.go.kr/ 사이트에서 검색하셔서 도로명 영문주소를 확인한 내용입니다.

Redbubble 사이트가 한글 입력이 안되는걸로 알고 있어서 이름은 그냥 영문으로 입력하였습니다.

Phone은 국가코드 없이 입력하여도 하단에 이전 단계에서 국가를 선택하였기 때문에 크게 문제가 안됩니다.

Email도 사용하고 계신 이메일 주소를 입력하시면 되며

Street Address 1 / Address 2 의 경우 2개로 나뉘어져있는데 Address 1의 입력 글자가 매우 짧게 설정된걸로 보아 길면 Address 2에 기입하라는 뜻입니다. 여기에는 사직로 지하 130만 입력하였으며, Address2에는 예시로 201ho라고 기입하였습니다.(아파트나 빌라의 호수 같은걸 보통 기입합니다.)

ZIP or Postcode 는 우편번호를 입력하시면 되고

City or Suburb의 경우 시/도 (서울특별시, 경기도, 강원도) 를 입력하였으며,

State, Region or Province 에는 구/군 (종로구, 서대문구, 은평구) 를 입력하시면 됩니다.

여기까지 하셨으면 그 다음엔 결재를 하시면 주문완료입니다.

저도 해외 구매를 많이 하는 편이 아니라 자세히 설명 못드리는 점 양해부탁드립니다.

[boilerplate] boilerplate code (보일러플레이트 코드)

권윤학 — Wed, 26 Oct 2016 23:45:15 +0900

boilerplate code

github에 오픈소스를 검색하다보면 boilerplate라는 용어를 많이 접할 수 있다.

boilerplate란 표준 문안이라는 뜻의 단어로 프로그래밍에서의 boilerplate code는 위키피디아의 설명을 보면

- 최소한의 변경으로 재사용할 수 있는 것

- 적은 수정만으로 여러 곳에 활용 가능한 코드, 문구

- 각종 문서에서 반복적으로 인용되는 문서의 한 부분

라고 설명되어있다.

javaScript나 html에서의 보일러플레이트라고 하면 보통 크로스 브라우징과 호환성을 위한 Modernizr, polyfill, Normalize 등이

적용되어 있는 템플릿 같은 형태로 많이 사용된다.(어떻게보면 seed project와 비슷하다.)

반복되지만 자주쓰이는 형태를 자동화한다는게 보일러플레이트의 핵심이다.

[syntax sugar] 문법적 설탕(Syntactic sugar)

권윤학 — Wed, 26 Oct 2016 23:31:30 +0900

Syntactic sugar

TypeScript를 학습하는 과정에 많이 접하는 용어가 아닌가 싶다.

먼저 위키피디아의 설명을 보면

- 사람이 이해 하고 표현하기 쉽게 디자인된 프로그래밍 언어 문법

- 사람이 프로그래밍 언어를 sweeter하게 사용 할 수 있도록 도와주는 문법

- 더욱 더 간결하고 명확하게 표현이 가능한 문법을 뜻 한다.

대표적인 예로 count++; 이러한 문법도 있으며 TypeScript를 Syntactic sugar의 특징을 가졌다고도 한다.

ES6의 Class 또한 Syntactic sugar인 구문임

[Semantic Versioning] 오픈소스 버전의 숫자들은 무엇을 의미하는거지?

권윤학 — Wed, 26 Oct 2016 18:20:55 +0900

Semantic Versioning(이하 Semver)은 Github 창업자인 톰 프레스턴-베르너(Tom Preston-Werner)가 작성한 버전 관리 방법으로

현재 많은 오픈소스들이 버전관리를 SemVer로 버전관리를 하고있다.

(Bower / NPM 패키지들도 마찬가지)

SemVer로 인한 장점으로는 개발자가 버저닝에 대한 명확한 기준을 통하여 버전만으로도 외부 라이브러리들을 도입이 가능하며

버저닝에 대한 고민을 덜어준다는 장점도 있습니다.

SemVer를 요약하자면 위에 그림으로 표현이 가능하다.

요약

- 기존 버전과 호환되지 않게 API가 바뀌면 “Major 버전”을 올리고,

- 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “Minor 버전”을 올리고,

- 기존 버전과 호환되면서 버그를 수정한 것이라면 “Patch 버전”을 올린다.

Jqeury로 예시를 들겠다.(2016-10-26일 기준)

Jquery는 현재 버전이 1.x.x 버전과 2.x.x 버전과 3.x.x 버전이 존재하는데

1.x 버전에서 2.x로 변경되면서 기존 서비스되던 API의 호환이 안되어 Major 버전을 올려 2.x으로 서비스를 하기 시작했으며

기존 1.12.x 버전은 이후 patch만 진행

최근 3.x버전이 정식 배포가 되었는데 마찬가지고 2.2.x 버전도 앞으로는 patch만 진행한다고함

가장 큰 문제는 역시 브라우져 호환문제이다보니 1.x에서만 현재 IE6~8이 지원이 된다.

그래서 대부분 개발자들은 jquery를 Major 버전을 확인해서 다운로드 받거나 패키지를 받아 사용중인 상황이다.

만약 SemVer가 없이 각 라이브러리마다 버전 표기 기준이 달랐다면 이거 또한 개발자들에게 학습곡선이 되지 않나 싶다.

새로운 체계는 아니지만 이미 있던 체계를 정리하는 것 SemVer가 지향하는게 아닐까 싶다.

[오픈소스 버전] Beta, RC, Nightly 이게 무슨말이야?

권윤학 — Wed, 26 Oct 2016 00:04:30 +0900

2.0.0-nightly

2.0.0-rc.0

2.0.0-beta.10

github에 보면 배포된 버전에 beta, rc, nightly 등의 용어가 붙어있는 경우를 간혹 볼 수 있습니다.

저도 처음 볼때 이건 또 무슨 말이야 하면서 찾아보곤 했었는데..

오늘은 이런 버전 표기에 대한 얘기를 해볼까 합니다.

소프트웨어 배포 생명 주기

소프트웨어는 아래와 같은 단계를 걸쳐 출시 및 배포를 진행한다고 합니다.

개발단계

1. 프리알파(pre-Alpha) : 이 단계는 실제 개발 이전 단계의 모든 활동을 말하며, 보통 프로토 타입까지의 단계를 얘기합니다.

2. 알파(Alpha) : 프로토 타입 이후 실제 테스트를 시작하는 단계부터 어느정도 기능이 구현되는 단계의 유닛별 테스트를 보통 말합니다.

이 단계에서는 일부 기능 별로 테스트하는 경우가 많으며 불완정한 소프트웨어입니다.

3. 베타(Beta) : 알파 이후부터 소프트웨어 기능의 완성 전 단계를 말합니다. 베타 단계에서는 최적화가 안되어 있는 경우가 많아 많은 이슈가 발생되기도 합니다.

4. 클로즈드 베타(Closed Beta) 테스트 / 오픈 베타(Open Beta) 테스트 : 베타 이후 단계의 테스트는 크게 두가지로 나뉘어지며, 이는 소프트웨어에서의 얘기이며, 오픈소스의 경우 베타 버전 릴리즈시 계속 테스트가 가능합니다.

5. 최종 릴리즈 혹은 출시후보 - RC(Release Candidates) : RC가 여기에 해당하며 정식 출시전 마지막 베타를 보통 RC라고 지칭합니다.

rc버전이 나왔다고하면 곧 출시 되는구나 생각하시면 됩니다. rc버전에서 크게 버그가 안 보일 경우 바로 출시 준비를 합니다.

여기서 Nightly가 빠져있는데 Nightly는 매일매일 업데이트 및 수정되어 올라오는 버전입니다.

즉 하루하루 발생되는 이슈나 업데이트 사항이 있어 빌드되어 배포되는 버전입니다.

이러한 버전은 정식 버전보다 안정성은 떨어지겠지만 급한 경우에는 이러한 배포를 하는 경우도 있겠네요.