2019년 4월 1일 월요일

JIRA Plugin - ScriptRunner 소개 #2

관련 글

ScriptRunner 소개 #2

지난 글에서는 Behaviours를 보았고 다음 내용인 콘솔, 리스너 등을 보겠습니다.
  • Administration > Add-ons > ScriptRunner
    • Script Console
    • Built-in Scripts
    • Script Listeners
    • Script Fields
    • REST Endpoints
    • Script Fragments
    • Escalation Services
    • Script JQL Functions

Script Console

Script Console은 실시간으로 스크립트를 작성하고 결과를 볼 수 있는 곳 입니다.

실제로 스크립트를 작성해보고 실행해본 모습입니다.


  1. 스크립트를 작성하는 곳 입니다.
    • 자동 완성 기능은 없지만 없는 변수나 없는 함수 등은 오류를 보여줍니다.
  2. 스크립트를 작성한 뒤에 Run 버튼으로 실행할 수 있습니다.
  3. Result / Logs / Timing 값을 각각 볼 수 있습니다.
    • Result: 스크립트에서 나온 결과물을 볼 수 있습니다.
    • Logs: 스크립트에서 출력한 log들을 볼 수 있습니다.
    • Timing: Elapsed: 208 ms / CPU time: 78 ms 와 같은 내용을 볼 수 있습니다.
아래는 의도적으로 함수명을 다르게 입력하면 볼 수 있는 에러 화면 입니다.


정적 타입 체크 밖에 해주지 못하지만 최소한의 체크는 할 수 있기에
스크립트 작성은 할 수 있습니다.

Built-in Scripts

ScriptRunner 에 이미 설정(구현)되어 있는 스크립트들을 사용할 수 있는 메뉴입니다.
아래 참고 문서에서 사용할 수 있는 스크립트 리스트를 볼 수 있습니다.
참고 문서: https://scriptrunner.adaptavist.com/latest/jira/builtin-scripts.html

<아래에 더 많은 스크립트가 있습니다>

위 화면의 스크립트 중 "Bulk Fix Resolutions" 스크립트를 확인해보겠습니다.
이 스크립트는 Filter에 있는 티켓들의 Resolution을 변경할 수 있습니다.
참고 링크: Bulk Fix Resolutions


JQL을 바로 작성하는 것은 아니며 기존에 만들어둔 Filter를 사용하여 동작하는 스크립트 입니다.
그 외에 다른 스크립트의 목록은 아래와 같습니다.

Listeners

Listeners는 JIRA에서 일어나는 이벤트에 따라 스크립트를 동작하게 합니다.
프로젝트, 특정 이슈, 특정 이벤트에 따라 동작할 수 있도록 설정할 수 있습니다.

<여러가지 리스너를 추가할 수 있습니다>

이미 있는 리스너 타입을 사용해도 되고
아예 이벤트를 받는 처음부터 스크립트 마무리까지 관리하는 Custom listener를 사용할 수도 있습니다.

이미 있는 리스너 타입 하나를 한번 보겠습니다.
Create a sub-task: Create a sub-task, Will Optionally reopen a matching sub-task

<특정 이벤트에서 Sub-task를 만들 수 있는 리스너 입니다>


 Create a sub-task Listener를 등록하는 화면의 각각 입력 필드에 대해 알아보겠습니다.
  • Note: Listener 등록시 해당 설명으로 Listener 리스트에서 설명을 볼 수 있습니다.
  • Project(s): 해당 이벤트가 발생하는 프로젝트를 설정합니다.
    • 프로젝트는 자동 완성되어 입력할 수 있습니다.
  • Events: 어떤 이벤트를 받아서 처리할 것인지 이벤트를 설정합니다.
    • All Issue Events, Issue Created, Issue Updated 등의 이벤트를 추가할 수 있습니다.
  • Condition: 해당 이벤트가 발생했을 경우, True / False를 판단할 스크립트를 설정합니다.
    • 'Show examples'를 누르면 예시 코드를 볼 수 있습니다.
    • 'Priority changed to Major (Listeners only)' - Listeners 에서만 동작하는 코드로 priority가 Major로 변경되었을 경우 True를 반환하는 스크립트 입니다.
    • 그 외에 많은 예제 스크립트가 있으니 참고하여 작성하면 됩니다.
    • Target Issue Type: Sub-task 카테고리의 이슈 타입을 설정합니다.
    • Subtask Summary: 생성할 Sub-task 제목(Summary)를 설정합니다.
    • Fields to copy: All / None / Custom 으로 상위 태스크의 필드 값을 복사할 것인지 설정합니다.
    • As User: 어떤 유저로 티켓 생성을 할 것인지 설정합니다.
      • 값이 없을 경우 현재 유저로 설정합니다.
    • Additional issue action: Sub-task 생성 이후 타겟 이슈(부모 이슈)에 대해 추가적인 작업을 하도록 설정합니다.
      • Condition과는 달리 추가적인 작업을 할 수 있도록 하는 스크립트 입력 필드입니다.
      • 제목을 바꾸거나 팝업 메세지를 따로 띄우거나 할 수 있습니다.
      • 'Show examples'를 누르면 예시 코드를 볼 수 있습니다.
    • Subtask Action: 이미 생성된 Subtask가 있을 경우 transition을 진행할 것인지 설정합니다.
      • 주의할 점은 적용하고자하는 프로젝트의 서브 태스크가 어떤 워크플로우를 쓰는가를 확인하여 적용해야 합니다.
    Create a sub-task 외에 다른 listener 타입이 있으며 아예 커스텀한 listener도 만들 수 있습니다.
    Custom listener의 경우 다음과 같이 만들 수 있습니다.


    이 listener는 앞서 설명드린 create a sub-task 와 프로젝트, 이벤트 필드 설정하는 것은 같지만
    이벤트를 받고 처리하는 방식이 다릅니다.
    발생한 이벤트에서 각종 데이터를 받아 처리해야하는 listener 타입 입니다.
    listener에 필요한 listener 타입이 없다면 커스텀하게 만들어서 사용하면 됩니다.

    // Listener 중 Remote Custom listener는 JIRA에 등록되어있는 application에도 scriptRunner를 설치해야 사용할 수 있습니다.


    Script Fields

    Script fields는 아래와 같이 설명이 나와있습니다.
    A script field is a custom field that allows you to automatically display a value according to the results of a ScriptRunner script.
    요약하자면, "스크립트러너의 스크립트 결과를 보여주는 Custom field" 입니다.

    2019년 3월 25일 월요일

    JIRA Plugin - ScriptRunner 소개 #1

    업무에서 요즘 많이 사용하는 'ScriptRunner' 라는 플러그인을 소개하려 합니다.
    이 포스트에서 다루는 내용은 JIRA 환경을 기준으로 작성되었습니다.
    (한국 문서로는 많이 볼 수 없어서 공부 및 소개 겸 포스트 작성합니다.)

    ScriptRunner란?

    Adaptavist ScriptRunner
    • 메인 페이지: https://scriptrunner.adaptavist.com/latest/index.html
    • Adaptavist 라는 회사에서 만든 스크립트 플러그인
      • Adaptavist inc: https://www.adaptavist.com/
      • ScriptRunner, Test Management, SmartDraw 등 Atlassian 소프트웨어 플러그인 개발사
    • JIRA, Confluence, Bitbucket에서 커스텀 스크립트를 사용할 수 있는 플러그인
    • 플러그인 설치 시 기본적으로 스크립트 함수, 필드 지원
    • 스크립트 언어는 Groovy를 사용

    ScriptRunner 가이드

    가이드 문서는 모두 영어로 되어있으며, JIRA Server, JIRA Cloud로 나눠져있습니다.
    Server 설치 버전과 Cloud 버전이 달라 기능도 약간씩 다르니 그 부분은 참고하여 사용해야합니다.
    ScriptRunner 플러그인을 처음 시작한다면 다음 자료들을 보면 좋습니다.
    Adaptavist에서는 따로 교육과정도 있으니 참고하세요.

    ScriptRunner 스크립트 작성

    ScriptRunner 플러그인으로 스크립트를 작성할 수 있는 곳은 JIRA 기준으로 다음과 같습니다.
    • Administration > Add-ons > Behaviours
    • Administration > Add-ons > ScriptRunner
      • Script Console
      • Built-in Scripts
      • Script Listeners
      • Script Fields
      • REST Endpoints
      • Script Fragments
      • Escalation Services
      • Script JQL Functions
    각 메뉴에서 할 수 있는 일을 정리해보겠습니다.

    Behaviours

    behaviours 기능을 통해 관리자는 하나 이상의 behaviours를 만들 수 있습니다. behaviours는 주어진 프로젝트 또는 이슈에서 이슈에 대한 필드가 동작하는 방식을 정의합니다. 아래는 예시입니다.

    예시:
    • 이슈 화면에 입력된 다른 데이터(즉, 이슈 생성 또는 이슈 전환 중)에 따라 필드를 필수 항목으로 지정.
    • 사용자 역할 또는 그룹에 따라 필드를 읽기 전용으로 설정
    • 이슈 화면(스크린)이 제출되기 전에 필드 데이터를 서버 측이 검증 수행
    • 다른 이슈 화면(스크린) 데이터에 따라 필드 값 설정
    https://scriptrunner.adaptavist.com/5.5.0/jira/behaviours-overview.html#_examples
    링크에서는 예시로 좋은 설명이 1, 2 있습니다.
    1. 이슈 생성 시 기본 Description(설명) 포맷 값 설정
    2. Resolved 처리 시 Resolution이 Fixed 일 경우, Fix Version 입력을 꼭 할 수 있도록 스크린 설정
    3. Live Editing (실시간 코드 작성)

    작성하다보니 내용이 많아졌네요.
    ScriptRunner 소개 #2 포스트에서 다음 내용들을 다루겠습니다.

    2018년 1월 19일 금요일

    GitLab CI 해보자!





    미디엄: https://medium.freecodecamp.org/how-to-setup-ci-on-gitlab-using-docker-66e1e04dcdc2
    GitLab CI quick start: https://gitlab.com/help/ci/quick_start/README
    GitLab CI Demo: https://gitlab.com/ykyuen/gitlab-ci-demo

    이번에 GitLab에서 CI를 자체적으로 지원해준다고 해서 한번 해보자!
    하는 마음으로 시작하는 CI 설정!

    쉽게 정리해보자면, 설정 순서는 다음과 같습니다.

    0. 빌드하고자하는 환경을 설정
    1. .gitlab-ci.yml 설정
    2. gitlab에 push!
    3. 빌드됨!

    여기서 가장 어렵다고 생각이 드는 것은 빌드하고자 하는 환경을 설정하는 것이라고 생각합니다.
    그런데 freecodecamp 미디엄 글에서는 도커 이미지를 사용해서 설정하는군요.

    일단 저는 Cordova 앱을 빌드하기 위해 필요한 환경설정이 무엇인지 살펴보고자 합니다.
    필요한 세팅은 아래와 같을겁니다.

    Cordova Android 문서를 참고해보았습니다.
    - JDK 8 이상
    - Android SDK, Android SDK Packages
    - Node.js 8.9.4 (NPM)
    - Cordova

    정리하고 나니 위에 4개 정도 필요하네요. (추가적으로는 환경변수 설정도 있겠습니다.)

    미디엄 글에서 나온 것은 docker 이미지를 사용해서 CI를 설정하고 있어서 편하게 되어 있습니다.
    저도 그래서 찾아봤습니다. cordova 관련한 docker 이미지가 있는지!

    있습니다!
    https://hub.docker.com/r/beevelop/cordova/

    요거 써서 설정되어 있는 이미지를 사용하면 편할 것 같습니다.

    그래서 제가 작업한 저장소는 아래에!
    https://gitlab.com/pineoc/cordova-ci-demo

    기본적인 프로젝트 구성은 아래와 같이 만들어졌습니다.

    0. .gitignore는 platforms, plugins를 포함해서 기본적인 세팅을 했습니다.
    1. npm i -g cordova
    2. cordova create ci-test com.pineoc.citest ciTest
    3. cordova platform add android
    4. .gitlab-ci.yml 세팅

    .gitlab-ci.yml 파일은 아래와 같습니다.

    
    image: beevelop/cordova:latest
    
    before_script:
      - cordova platform add android
    
    stages:
      - build
    
    build:
      stage: build
      script:
        - cordova build android
    
    

    이렇게 .gitlab-ci.yml을 작성하고 올려두면 자동적으로 파일을 인식, 빌드를 시작합니다.

    https://gitlab.com/pineoc/cordova-ci-demo/-/jobs/48618903

    이것처럼 쭉 로그가 나오고 빌드 결과는 passed, failed로 나옵니다.
    그렇게 어렵지 않게 기본 프로젝트 빌드는 세팅해보았지만
    추가적인 설정이 들어가면 어려워질 수 있을 것 같네요.
    (플러그인을 추가, iOS 빌드 시스템)

    도움이 되었으면 좋겠습니다.

    2018년 1월 13일 토요일

    Android Weekly #282 번역글



    원본: http://mailchi.mp/androidweekly/android-weekly-282?e=cae561fb9f


    ARTICLES & TUTORIALS

    Dagger에서 Koin으로 (미디엄 링크)

    이 게시물에서 Arnaud Giuliani는 Dagger에서 Kotlin 기반 종속성 주입 프레임 워크 Koin으로 마이그레이션하는 방법을 설명합니다. 프록시 / CGLib 없고, 코드 생성 없고, introspection 없음. Kotlin 기능 및 DSL 매직을 이야기합니다.

    Firebase Predictions 탐험 (링크)

    Joe Birch는 새로운 Firebase Predictions에 대해 설명합니다. Firebase Predictions를 사용하면 응용 프로그램의 사용자 행동을 예측하고 이를 사용하여 응용 프로그램의 유지를 향상시킬 수 있습니다.

    아키텍쳐 컴포넌트 함정 - 1부 (링크)

    Christophe Beyls는 대부분 문서화되지 않았고 거의 논의되지 않는 중요한 함정에 중점을 두고 있으며, 놓친 경우 응용 프로그램에 문제를 일으킬 수 있습니다.

    안드로이드에서 높이 다루기 (링크)

    Sebastiano Poggi는 높이가 올라가면서 UI 요소의 그림자를 조정할 수 있음을 보여줍니다.

    Grox: 상태의 예술 (링크)

    이 블로그 포스트에서 Alin Turcu는 최신 Groupon Open Source Library : Grox를 소개합니다. Grox는 모든 애플리케이션의 상태를 유지하는 데 도움을줍니다. Grox의 개념은 Redux 또는 Flux와 같은 JavaScript 프레임워크와 비교할 수 있습니다. 이는 단방향 데이터 흐름이며 불변의 데이터 구조를 뒷받침합니다.

    Canvas: 진정한 놀이터! (링크)

    이 포스트에서 Saurabh Pant는 뷰 캔버스에 직접 그리는 방법을 설명합니다.

    RadialGradient - Layers (링크)

    이전 글에서는, RadialGradiant 렌더링은 하드웨어 계층이 아닌 소프트웨어 계층을 사용하여 수행되었습니다. 이 짧은 시리즈에서 Mark Allison은 차이점이 무엇인지 살펴 봅니다.

    라이브러리 & 코드

    Rings

    링크가 사라진 라이브러리입니다..

    ads1015

    AndroidThings I2C 프로토콜을 사용하는 ADS1015 주변 장치를 지원하는 아날로그 - 디지털 변환기 드라이버입니다.

    kotlinconf-app

    공식 KotlinConf 응용 프로그램입니다! 응용 프로그램의 모든 부분은 Kotlin으로 구현됩니다. 백엔드, 프론트엔드 및 모바일 응용 프로그램 등등!

    grox

    Grox는 Java / Android 앱의 상태를 유지하는 데 도움을 줍니다.

    뉴스

    Kotlin 공식 가이드

    이 사이트에는 Android 용 Kotlin Style 및 Java Interop(interoperability) Guides가 포함되어 있습니다.

    Kotlin 업데이트

    Android에서 최신 Kotlin 지원 상태에 대한 Google의 업데이트.

    비디오 & 팟캐스트

    droidcon NYC 2017


    Kotlin visibility modifiers, internal modifier, modules


    droidcon London 2017

    2018년 1월 8일 월요일

    2017년 회고

    2017년 회고

    2018년 1월에 쓰는 2017년의 회고! (마치 일기 몰아쓰기를 하는 것 같다.)
    2017년은 다사다난했다. 2016년에는 어땠는지 기억해보면 2017년보다는 덜 혼란했던 것 같다.
    시간별로 한번 쭉 정리해보고 각 이슈 별로 이야기를 해보려한다.

    타임라인

    타임라인으로 적어보려 했지만… 기억이 많이 나지 않는다. 큰 이슈별로 정리해보면.

    1. 01.01 - 새해가 밝았다!
    2. 05.22 - 월천상회 퇴사
    3. 05.29 - 스마트스터디 입사
    4. 06.13 ~ 16 - 사이판 워크샵
    5. 06.22 - 개발본부 개발자로
    6. 09.06부터 - 한국사이버성폭력대응센터 기술 지원
    7. 09.16 - J2S Conference 2017
    8. 12.18 - 스마트스터디 퇴사
    9. 12.27 - 플루토 방송국 첫방송!

    생각보다 중간중간의 기억이 비어있어서 적는동안 당황했다.
    실제로 업무이야기라 그런 것도 있고 진짜 기억나지않는게 대부분이라 캘린더도 뒤져보고 회고록도 뒤적뒤적..

    월천상회 퇴사

    월천상회는 학교 다닐 때 휴학하고 참여를 하면서 2017년 5월까지 일했던 힘들었지만 재미있던 경험을 준 회사다.
    월천상회에서는 키즈 매거진 앱인 킹콩로켓56, 한글놀이 앱인 한글코끼리 등 유아 컨텐츠를 담은 앱들을 개발했었다.
    안드로이드, iOS에 각각 런칭하기위에 크로스플랫폼 프레임워크들을 사용했다.
    놀이 앱에 대해서는 Cocos2d-x를 사용했었고 키즈매거진 앱은 HTML 형식의 컨텐츠를 담기위해 Cordova를 사용해서 개발했었다.
    이직하기 전에 월천상회에서는 책도 출판하는 등 같이 많이 노력했지만 내가 생각했던 소프트웨어를 만들어 성장할 수 있는 곳은 아니라고 생각하게되었고, 이직을 준비하게 되었다.

    스마트스터디 입사

    학교를 졸업하기 전부터 일해왔던 월천상회 에서 퇴사하고 스마트스터디로 이직하게되었다.
    월천상회에서 일할 때 부터 관심있게 봐왔던 회사로 저기서도 꼭 다른 개발자들이랑 일해보고 싶다! 했었다.
    내가 지원했던 포지션은 앱 개발자로 Cocos2d-x 앱을 만드는 쪽으로 지원했었다.
    붙었으니 이야기하는 거지만 처음에 이력서를 너무 성의없게 내서 서류탈락했었지만..
    메일로 피드백 요청을 드렸고 너무나 감사하게도 부족한 부분을 알려주셔서 수정해서 다시 지원했었다.

    서류를 통과하고 기술면접, 임원면접 후에 5월 29일에 입사!
    라이브 팀에서 일을 시작했다. 얼마 있지 않아서 6월 13 ~ 16까지 사이판 워크숍을 다녀왔다.
    (아직 적응도 다 하지 못한 상태에서 다녀온 느낌이었지만 룸메이트였던 가이님이나 다른 개발자분들과 재미있게 보낼 수 있었다.)

    스마트스터디 기술 본부의 개발자로

    사이판을 다녀온 뒤에 조직개편이 있었다. 따로 있던 개발자들이 모여 기술 본부가 생겼고
    기술 본부는 인프라, 내부 서비스, 앱 등에 대한 개발을 담당하게 되었다. 
    (원래 각자 담당하던 일을 본부로 조직을 통합해서 개발자들이 시너지를 낼 수 있게!)

    나는 원래 라이브 팀에 있다가 기술 본부의 개발자로 앱 개발에 대한 일을 했다.
    주로 앱 프로젝트에 없는 문서를 문서화하고 앱을 관리하는데에 필요한 정보들을 정리했다.
    앱 빌드하는데에 오래걸리는 문제도 있었는데 Cocos2d-x의 앱 빌드 경우 cpp 파일들을 다 컴파일 하느라
    오래걸리는 문제가 있었는데 NDK 빌드할 때 CPU 코어만큼 빌드 태스크를 만들면 빨라지는 방식으로 그래들 스크립트를 업데이트 했었다. (일해라 컴퓨터! 일해라 CPU!)

    이후에 앱도 CI(Continuous Integration)를 적용해보고 싶었는데..
    어찌하다보니 해보지 못한게 아직도 아쉽다.

    입사하고 3개월 동안은 수습기간이었는데, 이 때 불안한 생각이 좀 많았었다.
    내가 정말 잘하고 있는게 맞는지, 이 회사에서 내가 일을 잘 맡아서하고 있는건지.
    그래서 6월, 7월, 8월 각 월마다 회고록을 쓰고 무슨 일을 했었는지 정리했다. 쓰고나서 본부 사람들에게 공유도 하고..
    (정규직이 되고싶어! 하는 몸부림이었을 수도 있겠다. 8월까지만 쓴 것은 아니고 10월까지는 쓰긴했지만 11월, 12월은 못쓰고 넘어가버렸다.)

    나중에는 기술 본부에서도 서비스실, 시스템실 이렇게 나눠지고 각각 팀이 만들어졌는데
    서비스실, 서비스 2팀의 개발자였다. (앱 개발팀)
    앱 팀은 그동안 일해온 특성상 한사람당 하나 이상의 프로젝트를 맡아서 개발해와서 협업한다는 느낌이 별로 없었다.
    (정보 공유는 어느정도 있었으나 많지는 않았던 것 같다.)
    서비스실에서는 그래도 실 안에 있는 사람들이 각자 어떤 일을 하는지는 알면 좋겠다 는 의미로 각자 맡은 프로젝트의 리뷰를 하고자 했는데 일정상 몇개만 할 수 있었다.

    여러가지 프로젝트 개발을 해볼 수는 없었지만 불꽃남자님이 Jira를 잘 사용하는 방법, 이슈 만들기, 프로젝트는 어떻게 진행해야하는가 같은 것을 잘 알려주셔서 그동안 배우지못한 협업 프로세스를 배울 수 있었다.
    실제로 프로젝트 진행하면서 프로젝트 구성원들과 함께 배운 것도 하나하나 적지 못하지만 너무나 배운 것이 많았다.

    한국사이버성폭력대응센터 기술 지원

    엄청 큰 기술 지원은 아니었다. 
    사이버성폭력이 일어나는 사이트들에 대한 자문이나 홈페이지 리뉴얼을 위한 지원을 했다.
    사실 처음 한국사이버성폭력대응센터 줄여서 한사성, 홈페이지를 가봤는데 반응형도 아니었고 화면 크기도 맞지않아
    문제가 조금 있었다. 9월에 처음 한사성팀과 미팅을 했었고 그 이후 계속 지원하고 있다.

    J2S 컨퍼런스 참석

    타임라인에 적어두어서 발표한 것 같지만 가서 듣고온 일이다.
    주니어로 시니어분들이 어떻게 생각하는지, 어떻게 성장해왔는지 궁금해서 들으러 가고 싶었는데 금방 신청이 끝나서 우울해하고 있던 차에 불꽃남자님이 발표자셔서 참석권을 얻을 수 있었다!
    가서 듣고 온 이야기에서 느꼈던 것만 정리해보면,

    • 회사는 개인의 이력을 관리해주지 않는다.
    • 자기가 성장해야한다.
    • 애자일은 테스트를 안해서 망했다.(?)
    • 테스트가 없는 리택토링은 리팩토링이 아니다.
    • 의도적 수련! 토이 프로젝트도 해보자!

    불꽃남자님은 리모트, 재택근무에 대한 이야기를 해주셨는데 회사에서 잘 실천하고 있나 확인하며 들었었다.

    스마트스터디 퇴사

    입사한지 정말 얼마안되서 퇴사를 하게 되었다. (약 6개월)
    많은 개발자분들과 함께해서 즐거웠고 다 같이 또 모여서 개발했으면 좋겠다는 생각을 많이했다.

    플루토 방송국 첫 방송!

    퇴사 이후에 더 많이 만나는 (전)스마트스터디 개발자분들과 플루토 방송국을 같이 만들어가고 있다.
    지금까지 2회 방송! 앞으로도 꾸준히 방송할 수 있었으면 좋겠다. 모두 좋은 회사에 취직해서 그 곳에서도 방송해보고!
    (시간이 될 수 있을지는 모르겠지만)


    회고 후기

    2017년 돌아보니 많은 일이 있었던 것 같지만 내 욕심보다 성장을 많이 하지 못해서 아쉬운 한 해였다.
    2018년, 올해에는 좀 더 많은 성장, 즐거운 이야기가 가득한 한 해가 되었으면 좋겠다.
    이 글을 읽어주신 모든 분들도 큰 성장, 많은 즐거운 이야기가 함께하기를 바랍니다.

    2018년 1월 2일 화요일

    Firebase node-gyp error

    최근에 파이어베이스 호스팅과 Functions를 이용해서 사이트를 만들어보고자 했지만
    firebase 커맨드라인에 문제가 생겨서 글을 남겨봅니다.


    Error Name: ERR! Pre-built binaries not found for grpc@1.6.6 and node@9.3.0 (node-v59 ABI) (falling back to source compile with node-gyp)

    위와 같은 에러가 났는데요.
    몇가지 글이 나오지 않는데 GitHub에 이슈가 올라온 것으로 확인했습니다.

    https://github.com/firebase/functions-samples/issues/267

    저는 아래와 같이 해결했습니다.

    $ npm install -g firebase-tools

    또 project-folder/functions 폴더로 가서 node_modules를 지우고 다시 명령어를 해주었습니다.

    $ npm install

    그리고 디플로이! 잘 진행해볼 수 있었습니다.

    $ functions firebase deploy

    === Deploying to 'webpage-test'...

    i  deploying functions, hosting
    i  functions: ensuring necessary APIs are enabled...
    ✔  functions: all necessary APIs are enabled
    i  functions: preparing functions directory for uploading...
    i  functions: packaged functions (29.15 KB) for uploading
    ✔  functions: functions folder uploaded successfully
    i  hosting: preparing public directory for upload...
    ⚠  Warning: Public directory does not contain index.html
    ✔  hosting: 2 files uploaded successfully
    i  functions: updating function app...
    ✔  functions[app]: Successful update operation.
    Function URL (app):

    ✔  Deploy complete!

    Project Console: ---
    Hosting URL: ---

    2017년 12월 28일 목요일

    Cocos2d-x 7주년



    http://discuss.cocos2d-x.org/t/happy-7th-birthday-cocos2d-x/40271

    Cocos2d-x 가 올해 12월로 7주년을 맞이했다고 합니다.

    2018년에는 코코스 크리에이터(Cocos Creator)를 어떻게 만들어갈 것인지,
    지금까지 얼마나 많은 사용자가 사용하고 있는지 등을 보여주고 있습니다.

    make games easier to develop
    위와 같은 목표로 Cocos 엔진을 만들어갈 것이라고 합니다.

    내년도 Cocos 지켜보겠습니다.

    2017년 12월 21일 목요일

    Cocos2d-x 3.17에 대한 테스트 요청 글이 올라왔네요.

    http://discuss.cocos2d-x.org/t/we-need-help-testing-v3-17/40609


    slackmoehrle의 글이 올라왔습니다.
    현재 3.17버전 개발이 마무리 단계로 보이는데 테스트가 필요하다고 하네요.

    3.17버전의 마일스톤은 12.31로 며칠 남지 않은 상태긴합니다.
    https://github.com/cocos2d/cocos2d-x/milestone/37

    dumganhar가 많은 이슈를 처리하고 있는데 31일까지 다 완료가 가능할지 모르겠습니다.

    이번 업데이트에는
    - clang+libc++ 컴파일
    - proj.android-studio가 안드로이드 프로젝트 기본 폴더로
    - Third party 라이브러리들 업데이트
    - NDK r16+ 사용

    이렇게 커뮤니티에 올려져있었습니다.
    업데이트 후에 CHANGELOG를 봐야하긴 하겠지만 큰 변화보다 엔진을 안정화시키는
    업데이트가 될 것 같습니다.

    2017년 10월 13일 금요일

    Cocos2dx 블로그, 3.16 업데이트 포스팅

    공식 블로그에 올라오기 전에 작성했던 글:
    https://pineoc.blogspot.kr/2017/10/cocos2d-x-316.html

    Cocos2dx blog에 올라온 3.16 업데이트에 대한 글:
    http://blog.cocos2d-x.org/2017/10/cocos2d-x-v3-16-released/

    앞서 업데이트가 진행되기 전에 글에서 이야기했던 내용을 보면,

    Cocos Creator에서 만든 것을 C++로 가져올 수 있다는 점과
    prebuilt를 사용해서 bullet 빌드하는 컴파일 속도를 올렸다는 점을 볼 수 있을 것 같습니다.
    (윈도우 10, 윈도우 폰, 타이젠 지원 중지도 크다면 큰 변경사항이네요.)

    업데이트 전, 릴리즈노트와 달라진 점은 없습니다.
    추가적인 정보를 위해서 포스팅하게되었습니다.

    C++ 사용자를 위한 코코스 크리에이터 플러그인https://github.com/cocos2d/creator_to_cocos2dx
    이 플러그인을 사용해서 export하면 에디터에서 만든 결과를 사용할 수 있습니다.
    단지 0.2 버전으로 안정적이지는 않지만 사용할 수 있게 되었다는게 크다고 생각됩니다.
    (https://github.com/cocos2d/creator_to_cocos2dx#limitations, 이 리스트만 지원됨.)

    LayerRadialGradient 라는 Layer를 추가했다는데 이 레이어는 LayerColor 레이어와 비슷하지만,
    둥글게 색칠하는게 다르다고 합니다. (어디에 사용할지는 잘 모르겠군요.)

    Bullet 라이브러리가 prebuilt로 들어갔다고 합니다.
    개발자들이 잘 사용하지 않는 라이브러리인데 빌드할 때 같이 빌드되는 바람에 시간이 많이 들었는데
    좋은 업데이트인 것 같습니다.

    Windows 10 metro, Windows Phones, Tizen 지원 중단.
    윈도우폰은 중단될 줄은 알았지만, 윈도우즈 지원을 전면 중단했습니다.
    (타이젠도 더불어 중단.. 시장 점유율도 0%인걸요..)

    전체 CHANGELOG 링크 추가하고 마칩니다.
    https://github.com/cocos2d/cocos2d-x/blob/v3/CHANGELOG

    2017년 10월 5일 목요일

    Cocos2d-x 엔진에 대한 토론 쓰레드(2)



    https://pineoc.blogspot.kr/2017/10/cocos2d-x.html
    앞선 글에 이은 글 입니다. 이번에는 cocos2d-x founder walzer의 글을 한번 보도록 하겠습니다.

    http://discuss.cocos2d-x.org/t/answering-the-questions-about-cocos-creator-the-engine-and-editor/38665

    이번 글은 Cocos Creator에 대한 내용과 Cocos 엔진의 미래에 대한 내용을 다루고 있습니다.
    글에서는 아래와 같은 내용을 담고 있었는데요.

    Cocos 엔진 미래
    - Chukong Technologies 에서 Xiamen Cocos Software inc로 큰 변화가 있을 것.
    - 게임 엔진에 더 많은 개발자가 참여할 것이고, slackmoehrle가 다시 참여할 것.
    - 자금을 아래와 같이 사용할 것
      - 커뮤니티, 문서, 비디오 튜토리얼, 포럼 등에 지원
      - C++, Lua 개발자들을 위해 Creator 지원
      - 3D 개발을 Creator에서 개발할 수 있게 지원
      - cocos2d-x 4.0!

    Cocos Creator 이야기
    - 퍼포먼스에 대한 이야기
    - R&D Edge, 3D 지원 등에 대한 이야기
    - Cocos Creator 미래.
      - HTML5, 자바스크립트의 상승세 등
      - 이 에디터를 마지막으로 생각하고 개발중이다! 안되면 게임업계 Quit!
    - We need a friendly ENGINE, no dysfunction EDITOR.
      - 이 글에 대한 것은 전에 중국 커뮤니티에서도 이야기나온 것들이 있음. (성능, 언어 지원 등등)
      - '유니티와 너무 비슷하다', '바퀴를 왜 다시 만드나' 에 대한 대답은 '우리 엔진에 맞는 에디터가 필요하다' 도 인 것 같습니다. (있는 것을 왜 개발하냐고 묻는 것과는 다른 의미를 생각하고 개발할 수 있는 것)
    - Cocos2d-x Future: C++ or Javascript
      - cocos2d에서 Objective C vs C++논의가 있었다면 Objective C를 선택했을 것.
      - 큰 의미가 있는 논의가 아니다.
    - Cocos Creator를 사용해야하는 이유에 대한 투표
      - C++를 지원하지 않는다는점, Cocos Creator가 Opensource가 아니라는 점, 영어 문서가 잘 안되어 있는점 때문에 사용하기 힘듬.

    위와 같이 정리를 해보았습니다. 이해할 수 없는 내용이나 어려운 내용은 없었지만
    중간에 왜 있는 도구를 다시 개발해야하나하는 내용은 제대로 이해하기 힘든 점도 있었습니다.

    이 첫글 이후에 이야기된 내용은 약 75개 정도 있는데 중간에 KAMIKAZE가 트롤링이 심해서
    대화가 닫히는 일도 일어나기도 했습니다.
    (게임엔진은 C++이 최고다! C++, C++ ... 이랬다가 지금은 삭제하고 조용한 상태입니다.)

    정보에 대한 공유가 이뤄지고 있는 점에 대해 좋다고 생각합니다. 커뮤니티와 이야기하고
    토론한다는 점에서 아직 Cocos 그룹이 살아있다는 것을 보여주고 있다고도 생각합니다.

    전체적으로 3D를 지원한다, JS를 밀어주려한다 등등에 대한 것은 이해하지만
    Cocos2d-x 버전 4.0 계획은 조금 이해가 가지 않습니다.
    로드맵이 업데이트가 되지 않고 있어서 추후에 3D를 추가한다, VR 등등 다른 부분을 많이 추가할 것이다, 이런 자세한 부분이 공유가 되지 않고 있어서 혼란스럽기도 하구요.

    커뮤니티에서는 이렇게 이야기가 진행되고 있었고 앞으로 Cocos 그룹이 어떻게 프로젝트를 진행할지는
    지켜봐야할 것 같습니다.

    다른 이야기들이 진행된다면 다른 포스트로 공유하겠습니다.
    고맙습니다 :)

    2017년 10월 3일 화요일

    Cocos2d-x 엔진에 대한 토론 쓰레드

    http://discuss.cocos2d-x.org/t/we-need-a-friendly-engine-not-a-dysfunction-editor/33651

    최근 한달 전까지 이루어진 토론인데 쭉 읽어보면서 내용을 정리해보려합니다.
    일단 제목부터...
    We need a friendly engine not a dysfunction editor.
    (우리는 부작용 에디터가 아닌 친숙한 엔진이 필요합니다.)
    구글 번역기로 돌려서 그런지 이상하지만 의역을 해보자면,
    우리는 작동이 잘 되지 않는 에디터보다 친숙한 엔진이 필요하다. 
    이렇게 해석할 수 있을 것 같습니다.

    현재 Cocos2d 팀은 Cocos Creator에 힘을 집중하고 있는데 그에 대한 유저들의 생각,
    이야기들을 볼 수 있는 쓰레드입니다.

    저도 코드로만 짜고 중간에 Cocos Studio를 사용해서 한번 앱을 개발해본 적이 있었지만,
    코드로 짜는게 편하다고 느끼는 편입니다.
    (저도 저 쓰레드를 만든 사람과 같은 생각으로 엔진 본연에 더 집중해줬으면 하는게 바람이었지만,
    에디터를 만들어서 조금 더 확장해보려는 시도는 나쁘지 않다고 생각합니다.)

    저는 Cocos2d-x 를 깊게까지 사용하지 않는 개발자라고 생각하는데도 엔진에 집중하고 있지 않다고 생각합니다.
    마이너 버전 업할 때 마다 버그가 있어서 bugfix 버전이 금방 나오곤해서 그것도 문제라고 생각하구요.
    (물론 오픈소스 엔진이니까 유저들이 관심을 가지고 PR, Issue 잘 수정해서 올리고 그러면 완성도가 올라가긴 하겠습니다만..)

    이 쓰레드는 엔진에 집중하지 않고 왜 에디터를 더 밀고 있냐하는 이야기로 시작되었습니다.
    308개의 쓰레드를 다 번역해서 올리기는 힘들 것 같고 큰 이야기 흐름에 대해 정리해보겠습니다.
    (There are 307 replies with an estimated read time of 85 minutes.) 읽는데에 85분 걸릴거라고 하는데,
    아마 해석하느라 2~3배정도 걸리지 않을까 예상해봅니다..ㅎㅎㅎ

    시작해봅시다! (의역과 모호한 해석이 넘쳐날 수 있습니다;;)

    맨 처음 글은
    "요즘 엔진보다 에디터에 힘을 쓰고 있는 것 같다. 다양한 것을 시도하는 것도 좋지만 cocos2d가 가지고 있는 엔진으로써의 장점을 잘 살려야한다고 생각한다. 에디터보다 엔진에 집중하는게 좋지 않을까?"
    라는 글 이었습니다.

    그 이후로 이야기가 진행되었는데요, 너무 많아서 대략적인 내용을 정리해보면,

    "엔진 개발도 중요하지만 쉽게 개발하기 위해, 엔진 사용자들이 더 쉽게 개발할 수 있게 에디터 개발도 좋은 방향이라고 생각한다." vs "하지만 엔진에도 수정해야하고 발전해야하는 부분이 많은데 에디터에 힘을 쏟는 것은 이상하다."

    중간에 커뮤니티 에반젤리스트인 Slackmoehrle이 와서 이야기를 진행합니다.

    "엔진 만드는 것도 중요합니다, 하지만 에디터로 프로토타입을 만들고 게임, 앱을 만드는데에 본질을 집중할 수 있게 에디터가 필요하다고 생각합니다. 다른 엔진들도 에디터가 있지만 우리 엔진은 에디터가 없는 것도 개발자들에게 장벽이라고 생각합니다."

    글 작성자 외에 다른 개발자들이 하는 말은
    "이미 있는 바퀴를 또 다시 만드는 것은 멍청한 것이다. (있는 도구를 또 만드는 것)"

    Slackmoehrles
    "몇 달마다 에디터를 만드는데에 우려를 표하는 글이 올라오지만 우리는 에디터를 만드는데에 소신을 가지고 만들고 있다. 사람들이 우려하는 내용은 별 의미 없는 우려가 많았다. 에디터 만드는 것은 중요하다고 생각한다."(많이 추리긴 했지만 이런 느낌의 글 흐름이 있었습니다.)

    글 작성자
    "Cocos Studio, Cocos Builder 같은 경우는 Open되서 개발되었는데 Cocos Creator는 Unity처럼 캡슐 상태로 개발이 되고 있는 것에 대해 우려가된다."

    Slackmoehrles
    "우리의 엔진은 오픈소스이며 에디터가 캡슐 상태(private) 인 것은 문제가 되지 않는다."

    다른 글에서는 이후로 튜토리얼이나 엔진에 대한 문서, 튜토리얼 이야기가 나왔습니다.
    아직 문서나 그런 자료들이 많이 부족해서 초보 개발자들이 개발하기 힘들다는 점에 대해 이야기가 있었고, 계속해서 많은 노력이 필요하다는게 전체적인 이야기였습니다.

    그 이후에는 walzer , Cocos founder가 이야기합니다.
    http://discuss.cocos2d-x.org/t/we-need-a-friendly-engine-not-a-dysfunction-editor/33651/140

    긴 이야기를 했지만 요지는
    "JS를 지원하고 에디터를 만드는 것은 많은 개발자가 Cocos2d를 사용하기 좋은 환경으로 만들어가고 싶다!"

    이에 대해 많은 이야기가 오고갔습니다.
    에디터와 엔진의 코드베이스, 현재 사용자앞으로 사용할 사용자의 차이, 에디터는 어떤언어로 개발되어야하냐부터 자잘한 이야기까지 있었습니다.
    모든글을 영어로 읽어보지 못했지만, 전체적인 이야기는 에디터 정말 필요한가?

    이어지는 글을 보고 정리한 결론을 따로 포스팅해야겠습니다.

    이어지는 글 :
    - Answering the questions about Cocos Creator, the engine and editor: Link
    - Vote cocos2d-x future C or Javascript: Link
    http://pineoc.blogspot.com/2017/10/cocos2d-x-2.html

    JIRA Plugin - ScriptRunner 소개 #2

    관련 글 소개 #1:  https://pineoc.blogspot.com/2019/03/scriptrunner-1.html ScriptRunner 소개 #2 지난 글에서는 Behaviours를 보았고 다음 내용인 콘솔, 리스너 등을 ...