ハトネコエ Web がくしゅうちょう

プログラミングやサーバー・Web制作、チームマネジメントなど得た技術のまとめ

atom-text-editor::shadow は廃止されました（ATOM v1.13.0）

プログラミング系 ATOM 設定

f:id:nekonenene:20170120192346p:plain

テキストエディタ Atom を使っていて「おや？」と思うことが出た。
初めて見たぞこの表示……。

Atom Deprecation Cop というもので、つまり Atom の設定で変な箇所あったら怒ってくれる人です。
昔から搭載されてるらしいですが私は初めて怒られました。

f:id:nekonenene:20170120192816p:plain

こんなエラーでした。
「なるほどわからん」と思いつつもよく見たら、 style.less で deprecated selector が使われてるよー、と言われていることがわかります。

それで
atom-text-editor .highlight.ideographic-space .region:after, atom-text-editor::shadow .highlight.ideographic-space .region:after
から
atom-text-editor .highlight.ideographic-space .region:after, atom-text-editor.editor .highlight.ideographic-space .region:after
にそのうち自動で直しちゃうよー。みたいな。

問題のある箇所だけ教えてくれればいいのにこれじゃ間違い探しです。
正解は atom-text-editor::shadow => atom-text-editor.editor のとこだけです。わかりづらい！


せっかくなので、これが出た原因である全角スペース表示プラグインの作者さんに報告しようとしたら、
すでに報告済みでしたし、READMEもよく見たら修正されていました。
https://github.com/raccy/show-ideographic-space/issues/9

めでたし

起動すぐに『Windows Media Playerは動作を停止しました』となる問題の解決

Windows 音楽 設定 バグ DTM系 プログラミング系 便利ツール

Windows Media Player が再生を初めて数秒で
『Windows Media Playerは動作を停止しました』と出て終了する問題に、この数週間悩まされてきました。

別の再生プレイヤー使おうか……
いや、でもWindows Media Playerは動作が軽いし広告出ないからいいんだよなぁ……。

iTunes は再生すると必ずライブラリに登録されるから自作曲を再生させたくないし、
Groove Player（Windows10からのプレイヤー）はファイルをダブルクリックしてもたまに再生始めないことがあるし……。

「プログラムと機能」の「Windowsの機能の有効化または無効化」で一度無効にして再起動して有効にすれば直るよー、ってのを試しても解決しなかったので、
「もうダメじゃー」とあきらめていたのですが、今日調べなおしたら、Yahoo知恵袋で１つの答えを見つけて、それを試したら直りました。

Windows10 だからこの解決法は無関係かなーと思っていたので、予想外に直って感動しました。

それは、 https://support.microsoft.com/ja-jp/kb/2970908 にある「Microsoft 簡易修正ツールソリューション」の中の、

の三項目を実行させるというものです。

なお、私はライブラリを開くとすぐに『Windows Media Playerは動作を停止しました』が出ていましたので、
２番目の『Windows Media Player のライブラリの問題を検索・修正する』の実行が効果を発揮したんだと思います。

このページ全然知りませんでしたが、他のことでもお世話になることがあるかもですね。
快適なWindows音楽ライフに戻れました！ よかったよかったー

GitHub Pages にビルドしたフォルダだけを上げたいときの Circle.yml

CircleCI Linux Mac Ubuntu Web制作 git shell パッケージ管理 プログラミング系 設定

GitHub に git push するだけでウェブサイトを作成・更新できる GitHub Pages 。便利です。
ちょっとめんどくさいのが、 gh-pages ブランチか master ブランチのトップディレクトリに index.html がないといけないところ。
（ master ブランチの場合は docs と名付けたフォルダをトップディレクトリにすることも可能）

gulp とか webpack とかで最終的な出力を build フォルダに向けてしている……なんて場合は、この仕様がけっこう厄介です。
デプロイ先のフォルダ名を docs とするのは一つの解決方法ですが、最終出力先のフォルダ名としてどうなの？ って気持ちになります。

そこで、GitHub ユーザーにとっての CIツールとしておなじみ、 CircleCI の出番です！
CircleCI に gh-pages ブランチへの git push をお願いしちゃいましょう！

【追記（2019/5/24）】
この記事の内容は古いです。現在は CircleCI 2.0 ですので、以下の記事をご覧ください。

nekonenene.hatenablog.com

0. 前置きの雑談

さっきから出力とかビルドとかデプロイとか言葉が安定しませんが、全部同じ意味で使ってると思ってください。
Sass が CSS ファイルになったり webpack で JS が出力されるのとかをコンパイルって呼んで、minify 系は圧縮と呼んで、それら一連のことがおこなわれるのをビルドとかデプロイとか呼んでる感じです。

正確にはそういう一連のコンパイルの流れを「ビルド」と呼んで、
人がさわれる状態になる（今回CircleCIが担当する、GitHub Pages への公開・更新）のを「デプロイ」と呼び、
サービス開始を「リリース」と言うらしいです。

私はビルドのことデプロイって言ったり、デプロイのことリリースって言ったりするので、
「あ〜この人あたまがわるいんだ〜」と笑いながら読んでください。

ディレクトリとフォルダも同じ意味くらいの気持ちで使ってますけど気にしないでね！

1. circle.yml の設定

答えから見せたほうがわかりやすいと思うので、まず出来上がりを見せます。
細かい注意点はそのあとに書いていきます。

src ディレクトリの中にある .scss ファイルや .pug ファイルを、タスクランナー gulp によってビルドし、
build ディレクトリに出力している形です。

1-1. CircleCI を働かさない branch の指定

general:
  branches:
    ignore:
      - gh-pages

まずはこの部分で、 gh-pages ブランチへの push があっても CircleCI が走らないよう設定されています。
今回は gh-pages ブランチに直接 push する予定はないので、この設定（もしくは以下に述べる [ci skip] の設定のいずれか）は本当はいりません。

f:id:nekonenene:20161102022958p:plain

上の写真のように、CI の実行がスキップされたログは残ります。
すこし邪魔ですが、ログがないと CircleCI の挙動がおかしいのか SKIPPED されたかわかりませんから必要ですね。

1-2. npm パッケージのインストール

dependencies:
  pre:
    - rm -rf node_modules
  override:
    - npm install

まず node_modules フォルダを削除しています。
CircleCI はキャッシュを持つのですが、 node_modules ディレクトリ内のキャッシュが悪さして変なところで CI が止まるということはよくあって、
しばらく原因解明に悩む時間がたびたび発生するので潔く削除しています。
（CircleCI には「Rebuild without cache」というボタンもあるのですが、そもそもキャッシュが原因の可能性を見落としがち）

1-3. ビルド

deployment:
  deploy:
    branch: master
    commands:
      - npm run build

branch: master と指定することで、 master ブランチへの push による CircleCI タスクのときのみ、この deploy 部分は働きます。
他のブランチへの push でも gh-pages に反映させたいという場合は、この記述は無くすといいでしょう。

その後に、 npm run build でビルドします。
以下のように package.json に書かれているために、npm run build とコマンドすると gulp build がおこなわれます。

# package.json より一部抜粋
  "scripts": {
    "build": "gulp build"
  }

gulp build の中身は gulpfile.js に記述しています。
大ざっぱに言うと、src ディレクトリにあるファイルをビルドして build ディレクトリに出力する処理が書かれています。

1-4. build ディレクトリの中身をトップディレクトリに

    commands:
      - npm run build
      - rm -rf src
      - cp -Rf build/. ./

ビルドし終わったら src フォルダは用済みなので消しています。
特に深い意味はありません。なんとなく消しています。

大事なのは cp -Rf build/. ./ の方です。
build フォルダの中身をトップディレクトリにコピーしてきます。

R オプションでフォルダの下を潜ってファイルを探します。
f オプションで、コピー先に同名のファイルがたとえあっても容赦なく上書きします。

個人的にハマったのは、build でも build/ でもなく、build/. が正解なことです。そっかー。

.gitignore によって build ディレクトリを含めてないから考えていませんでしたが、
ここ cp コマンドでなく mv コマンドでもよさそうですね。

1-5. git push で gh-pages へデプロイ

  - git config --global user.name  "CircleCI"
  - git config --global user.email "circleci@gh-pages.com"
  - git add .
  - git commit -m "Publish [ci skip]"
  - git checkout -B gh-pages
  - git push -u origin gh-pages --force

さて、ビルドが終わりました。
あとはデプロイ！ git push までの流れを見ましょう。

1-5-1. git config

まずは git config で username と email の設定を入れます。
値はなんでもいいですが、この設定をしておかないとコミット git commit ができません。

1-5-2. git commit

コミットメッセージが「Publish [ci skip]」となっていますね。
この [ci skip] の部分が特別で、コミットメッセージにこの文字が含まれているコミットに対して、CircleCI は処理をおこないません。

通常は 1-1. で書いた特定のブランチを無視する方法だけでいいと思いますが、
おもしろい仕組みだなと思いましたので書いておきました。

1-5-3. add branch & checkout

続いて git checkout -B gh-pages です。

新しいブランチを作りつつチェックアウトする b オプションは知っていたのですが、
すでに同名のブランチがある場合はエラーを発生させてしまうオプションなので「どうしよう」と悩んでいたのですが、
この B オプションならば、基本は b オプションと同様ながら「すでに同名のブランチがある場合はブランチの作成をせずチェックアウトする」ようです。助かりました。

1-5-4. git push

そして最後に gh-pages ブランチをリモートリポジトリに git push します。
pull を要求されてはエラーになりますので、force オプションを付けます。

2. git push だ！ の前に……

CircleCI が git push できるようにするためには下準備が必要です。

CircleCI のプロジェクトページ（対象リポジトリ）に飛び、PROJECT SETTINGS を開き、
PERMISSIONS の「Checkout SSH keys」をクリックします。

f:id:nekonenene:20161102031951p:plain

すでに deploy key はあるかと思いますが、これには git pull の方の権限しかありませんので、user key を作成します。

Add user key のところにある「Authorize with GitHub」ボタンをクリックして user key を発行してください。
それが終わりますと下準備は完了です。

あとは push し無事にビルドが終了すれば、

https://YOUR_USENAME.github.io/REPOSITORY_NAME

にページが作成されます。

3. Failed にならないために

test:
  override:
    - npm run test

CircleCI には test の部分があります。
ここを省略することは可能ですが、書かないと、必ず結果が Failed になってしまいます。

精神的に Failed ラベルが並ぶのは嫌ですし、
すべてが Failed となってしまうのでは、ビルドに失敗しての Failed などと見分けがつきません。

とはいえ、作りたてのプロジェクトなど、
テストコードがない場合もあるかと思います。

その場合は、test の部分は cd ./ や echo 'にんじんたべたい' などと、
当たり障りのないコマンドを書いておくといいかと思います。

4. 余談 : yarn

公開した circle.yml では npm install としていますが、実際は

dependencies:
  pre:
    - rm -rf node_modules
    - npm install -g yarn
  override:
    - yarn install

test:
  override:
    - yarn test

deployment:
  deploy:
    branch: master
    commands:
      - yarn build

のように、npm から yarn に乗り換えつつあります。
（rm -rf node_modules のあとに yarn cache clear を書いたほうが安全かも）

今のところは特に問題が起きていません。
……が、yarn をインストールさせることなく npm だけで終わらせたほうが CircleCI のタスクにかける時間が 1分近く少なくて、複雑な気持ちになっています。
yarn.lock による安定さが優れてるのではって勝手に期待してるんだけど、どうでしょう？