markdown 문서에 custom css 적용하기

  • 참조 링크 : HTML Support in Typora
  • 아래 섹션이 custom css 적용해본 결과이다.
  • 적용 절차
    • 아래 Sytle을 문서 첫부분에 넣는다
      1
      2
      3
      4
      
      <style>
      .note { color:#01579b; background:#e1f5fe;}
      .warning { color:#d50000; background:#fce8e6;}
      </style>
      
    • markdown 본문은 다음과 같이 처리한다

      1
      2
      
      * <span class="note"> 이곳엔 **note 클래스** 적용</span>
      * <span class="warning"> 이곳엔 **warning 클래스** 적용</span>
      
    • 결과는 다음과 같다
      • 이곳엔 note 클래스 적용
      • 이곳엔 warning 클래스 적용

markdown 문서에 emoji 서포트 적용하기

  • 위 섹션 작업을 하다보니 githbu commit 메시지 작성시 요즘 사용중인 emoji를 적용하고 싶어졌다
  • 참조 링크 : Jemoji, Github-flavored Emoji plugin for Jekyll
  • 적용 방법
    • Gemfile에 다음 추가
      gem 'jemoji'
      
    • _config.yml에 다음 추가

      1
      2
      
      plugins:
        - jemoji
      
    • jekyll serve를 그냥 껐다 켜보면 다음과 같은 에러가 보인다
      1
      2
      3
      
      ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x64-mingw32]
      Could not find gem 'jemoji x64-mingw32' in any of the gem sources listed in your Gemfile.
      Run `bundle install` to install missing gems.
      
    • 위 지시사항대로 shell에서 bundel install을 실행하여 jemoji를 설치한다
    • 이후 bundle exec jekyll serve를 다시 실행
  • 테스트
    • markdown

      1
      
        * I give this plugin two :+1:!
      
    • 실행결과
      • I give this plugin two !
    • 윗 줄에 엄지 척 emoji가 적용되어 보인다면 성공 !!
  • 결국 jemoji 안쓰고 jekyll-spaceship으로 변경
    • 관련 문서
    • jemoji는 사이즈 고정이라 문맥에 따라 emoji 사이즈가 변경되지 않는 문제가 있었음
    • jekyll-spaceship 부작용
      • 위에서 code block에서 emoji 처리가 안되어야 하는데..emoji processor가 code block까지 침범하는 듯.
      • jemoji는 이런 문제가 없었음.
      • 관련하여 jekyll-spaceship이슈등록
        • 개발자가 버그임을 인정. 고치는중임 (2021-01-04, 22:57)

Google Apps Script 다른 사람과 협업하기 [문서번역]

  • 원본 : Collaborating with Other Developers, GAS
  • 앱 스크립트는 당신과 다른 개발자가 add-on, 스크립트, webapp을 함께 빌드하고 유지하는데 도움을 주는 기능들 제공합니다.
  • ★ 이 가이드는 여러 개발자에 의한 active collaboration을 커버합니다. 만약 당신이 단순히 누군가와 코드를 공유해서 그들이 자신의 프로젝트에 포함하는 정도만을 원한다면 Libraries 가이드를 보세요.

Collaboration basics

  • 협업하기위해, 당신과 협력자는 모두 해당 Apps Script 프로젝트에 editor Access를 가져야 합니다.
    • 그 프로젝트가 bound script라면 container 또한 마찬가지입니다.
    • 이것은 팀원 모두가 App Script Code를 보고 편집할 수 있도록 해줍니다
    • 편집자들은 새로운 버전을 생성하고, add-on을 발행하고, Apps Script APi용 executables로 web apps을 게시할 수 있습니다.
  • 당신은 당신의 프로젝트, add-on, web ap을 어떻게 편집, 리뷰, versioning하고 (가능하다면) 발행하고 게시할 지 미리 계획하여 당신의 팀을 도울 수 있습니다.
    • Standalone projects는 가장 협업하기 쉽습니다.
      • 이유는 Google Drive에서 바로 보이며,
      • add-on이나 web app 개발에서 추천되는 프로젝트 타입이기 때문입니다
  • 협업에서 흔한 문제는 스크립트 프로젝트 소유자 프로젝트의 소유권을 이전하지 않고 팀을 떠나버릴 때 발생합니다.
    • 이 때문에 당신이 프로젝트를 유지보수하거나 업데이트하지 못할 수 있습니다.
    • 이 문제를 방지하려면 스크립트 프로젝트를 공유 드라이브에 위치시키세요.
      • 공유 드라이브는 특정 소유자가 존재하지 않습니다.
  • 항상 script 프로젝트의 소유권을 공유하세요 어떤 팀원이 조직을 떠나고 계정이 제거되면, 다른 소유자가 없는 스크립트의 접근권한은 사라집니다. 드라이브에서 script의 소유권을 공유하거나 공유 드라이브로 문서를 옮기세요
  • (역자주) 공유 드라이브는 Workspace 구독자만 가능한 듯..

Collaboration with the clasp command line tool

  • claspscript.google.com과 당신의 local 파일 시스템간에 프로젝트를 동기화 시켜줍니다.
  • 당신과 당신의 협력자가 git과 같은 소스코드 관리툴을 사용한다면 이것은 또한 개발과정을 간소화하고 자동화할 수 있습니다.
  • clasp을 이용한 명령행 인터페이스 가이드를 참조하세요.

Collaborating with shared drives

  • ★ 공유 드라이브는 Google Workspace Business 나 Google Workspace Enterprise 고객만 이용가능합니다.
  • 지금은 쓸 일이 없으므로 Pass

Collaborating with project sharing

  • 당신은 프로젝트를 당신의 협력자와 직접 공유하여 협업을 진행할 수도 있습니다.
    • 당신은 정규(regular) 구글 드라이브나 공유 드라이브에 있는 script project를 직접 공유할 수 있습니다.
    • 이 방법을 사용한다면, 누가 계속해서 script를 소유하고 유지보수할 것인지 주의깊게 계획을 짜는게 좋습니다.
  • ★ 모든 container-bound srcipts는 해당 container에 정의된, 동일한 owner, viewer, editor 접근권한 목록을 사용합니다. container owner는 누가 만들었든지 상관없이 새로운 스크립트에 대한 소유권을 갖습니다.