Windows

Edgeの初回起動ダイアログ

WindowsユーザーはChromiumEdgeを「始めない」という選択は許されない。

「始める」があるなら「後で始める」を用意すべきでは。
「始める」以外に選択肢がないのに、クリックさせる意味はあるんだろうか。

何度もBitBucketの認証が出る問題

リモートリポジトリを BitBucket にしていると、SourceTreeが頻繁に認証画面を出してきて非常に鬱陶しい。

何も入れずに閉じてもPull / Pushはできている。
どうやら、バックグラウンドでFetchした時に認証を求めてくるようだ。SourceTreeは一定時間ごとに裏でFetchをしてリモートの情報を取ってきている。

環境は以下の通り、

  • Windows10
  • SourceTree  2.6.10.0
  • Git 2.18.0

特にGitHubとBitBucketの両方のリモートリポジトリをSourceTreeで扱っていると起きやすい気がする。

問題ありそうな箇所

  1. Windowsの認証管理情報
  2. SourceTreeでのアカウント設定

ほぼ、2.のSourceTree / Gitが保持しているログイン情報を設定、修正すればいいと思う。
ただ、Windowsの認証管理で問題が出ていても、Windowsの方からは何らエラーが出ないので厄介である。なので、これも対処に含めた。

結論だけ言うと、自分の場合はSourceTreeのアカウント設定で「デフォルトに設定」をするだけでよかった模様。

Windowsの認証情報を一旦削除

間違った認証情報がWindowsに登録されてしまうと、

  • Windowsがアプリケーションに代わってログインしようとする
  • サーバ側は認証失敗を返す
  • アプリケーション側で認証画面が出る
  • ログインし直す
  • Windows側のログイン情報は更新されない
  • 最初に戻る

という、無限ループにはまってしまう場合があるようだ。
認証に成功したらその時の情報が入りそうなものだが、更新に失敗する場合があるのだろうか?

Windowsの設定にある「資格情報マネージャー」から、BitBucket関係の認証情報を一旦削除してしまう。

設定画面から「資格情報」で検索する

「設定」画面から「資格情報」で検索すると早い。
あるいはコントロールパネルから入る。

「Windows 資格情報」の方に、

git:https://akiya64@bitbucket.org

とあるので、今回はこれである。他にあればBitBucketに関係する資格情報は一旦、全て削除する。
認証に失敗した場合でも、認証情報は追記されているため問題の切り分けが面倒になっている。

修正もできるので、正しく設定し直してやればいいのかもしれない。

SourceTreeでのアカウント設定

SourceTreeにはコードホスティングサービスのアカウント情報が登録できる。
メニューバーの ツール → オプション → 認証を開く。

ツール → オプション → 認証で認証情報の登録画面を表示

アカウントにBitBucketがないので追加する。
「Git保存されたパスワード」とは別の扱いである。

認証方法は BasicかOAuthが選べる。Basicの場合は、ここでユーザー名を入力してパスワードで認証する。

OAuthなら「OAuthトークンを再読み込み」で下記のようにBitBucketのWebサイトが開くので、連携アプリケーションのアクセスを許可してやればよい。

BitBucketアカウントの認証成功
BitBucketの管理画面で連携アプリケーションにSourceTree for Windows が追加された

ついで、ユーザー名のデフォルト設定をしておく。
これをしていないと、所有者が自分でないBitBucketのリモートにアクセスするとログインエラーになるようだ。

何やら日本語が怪しいが、ユーザー名の設定らしい

実は私の場合、ここのユーザー名の設定一発で認証画面が頻繁に表示される問題は解消した。

アカウント設定をやっておこう

何となくPull/Pushできるものだから、そのまま使ってきていたが、SourceTreeにアカウント情報を登録できるのだからやっておくべきだった。

OAuthで認証できるなら、こっちの方が断然、楽で確実である。

Node.jsを入れてStylusを使う

CSSプリプロセッサ=Sass(SCSS)とかLESSとかでCSSを生成してやると、複雑なCSSもシンプルで見通しのいいソースコード=CSSメタ言語から生成できます。

今回はそのCSSプリプロセッサを、例によってWindows10で使ってみましょう。
今、プリプロセッサって言いました?! Sassだぁ!
いいえ、Stylusです。

stylus-old-logo.png

古いStylusロゴの方が好き

メジャーどころのSassはWindowsではRuby実行環境もインストールする必要があります(MacだとRubyは最初から入ってるそうです)。またStylusはNode.js謹製のプリプロセッサでもある。GulpとかGrantとか、タスクランナーと組み合わせると便利らしいです。

ですが、いきなり全部やると大変ですし、ややこしいです。今回はコマンドラインからStylusでCSSをコンパイルしてみましょう。
Stylusを入れるにあたって、下準備が二つほど要ります。

  1. Windows PowerShellの実行モード変更
  2. Node.jsのインストール

その後、Node.jsの機能を使ってStylusをインストール、CSSのコンパイルを試します。

Windows PowerShellの設定

Node.jsは基本的にコマンドラインから使います。
だが、いにしえのコマンドプロンプトとは訣別しよう。Windows 7以降ならば、Windows PowerShellというコマンドラインが使えます。
Windows PowerShell、略称WPS。以下でもWPSと書けばWindows PowerShellのことを指します。
一旦、管理者として起動してWPSの実行モードを変更する。
Stylusコマンドを実行するだけなら、この設定変更は不要かも知れない。
wps-from-start.png
私はWindows10 64bitを使用しているので、互換性のためかx86(32bit)のWPSもある。多分どちらでもいい。
wps01.png
起動したら、何か警告が出ている。
「セキュリティ上の問題があるので、WPSから実行できるスクリプトに制限をかけていますよ」とのこと。
WPSの実行制限モードを変更する。

> Set-ExecutionPolicy RemoteSigned

上記コマンドを入力。Yで続行。制限モードをRemoteSignedとして、ローカルで作成したスクリプトとリモートからは信頼できるスクリプトのみの実行とする。
wps02.png
再度、WPSを起動してみる。警告メッセージなし。
lsコマンドが使えるので、それだけでも乗り換える価値があります。
WPSはどの実行制限が妥当か、実は私では見当が付いてません。
下記サイトでは、Remote Signedが最適とのことです。企業だと社内ネットワークやPCのセキュリティポリシーなども関係してきます。詳しい人がいたら確認してみて欲しい。そして私にも教えて頂けると幸いです。

Remote Signed

  • 実行ポリシーがRemote Singedに設定されている場合、ローカルで作成されたあらゆるPowerShellスクリプトを実行することが許される。リモートで作成されたスクリプトは、信頼できる発行元が署名したものしか実行できない。

PowerShellの使用方法|Windows管理者のためのPowerShell

Node.jsのインストール

Google先生に聞くまでもありません、最短距離でNode.jsの公式サイトへ行きましょう。

Node.js公式サイト https://nodejs.org/en/
Windows用のインストーラである.msiファイルを用意してくれてます、多謝。
nodejs-msi.jpg

スクリーンショットでは、node-v4.4.5-x64.msi ファイルをダウンロードしています。
(バージョンは2016年6月現在)
ダウンロードしたファイルからインストール、以上。
WPSから

> node –v

でバージョンが確認できれば、Node.jsのインストールは一先ず完了です。
私のNode.js は4.0.0ですね。
node-v.png

Stylusのインストール

JavaScriptといえば、普段はWebサイトの表示をブラウザ側=フロントエンドであれこれしてくれてますね。そんなJavaScriptをサーバーサイド≒PC側で動かして便利に使うぜ!というJavaScriptアプリケーションがNode.jsです。
で、そのアプリケーションパッケージの一つにStylusがあります(かいつまんだ説明)。
Stylusのインストールは、計2回行います。
グローバル・インストールと作業フォルダへのインストール。
1つ目のインストール
npm=node package managerというNode.jsのパッケージ管理機能を使って、stylusをグローバル・インストールします。
グローバル・インストールすることで、WPSでどのフォルダにいてもstylusコマンドを呼び出せます。
WPSで使いたいプログラム名=コマンド・オプション・対象を確認しつつ命令文を書きます。コピペでなく打ち込み推奨。

> npm intall –g stylus

-g オプションでグローバル・インストールになります。
インストール確認&バージョン確認は

> stylus -V

グローバル・インストールは以上です。
次に、2つ目のインストール
作業フォルダへもインストール作業が必要です。
今回はユーザーフォルダのnew-projectで作業するとします。
project-folder.png

> cd ~/
> cd \new-project

cd ~/ で ユーザーのホームへ移動、私のPCならC:\Users\akiyaに移動する。ある程度ファイル名を入力したらTabキーで候補が出る。
new-projectフォルダでnpm install を実行、この時は -g を付けない。

> npm install stylus

npm-install-2.png
ログにWARN何とかが出ているかもしれませんが警告なので、一応問題はない。
Errorの場合はインストールが止まるはずです。
インストールが終わったらnew-projectフォルダにnode_moduleフォルダが増えます。
この中にJavaScriptライブラリやモジュールが沢山入っていて、コンパイル処理で呼び出されます。
node-modules-explore.png
もちろん、どこにnew-projectフォルダを置いてもいいし、作業フォルダの名前も好きに決められます。フォルダを作ったら作業フォルダへのインストールを忘れずに。

.stylファイルを書いてコンパイル

style.styl を次のように書いていたとして、CSSファイルをコンパイル(ソースコードから生成)してみます。

bright-h = #257bcc
.menu-item
    color bright-h
    display block
    padding 0.2rem 1rem
    border-left solid 3px #fff
    &:hover
        border-left solid 3px bright-h
    & a:hover
        text-decoration none

WPSからコンパイルを実行します。使いたいプログラム名と対象ファイルを指定して実行。

> stylus style.styl

成功すれば、たった1行 compiled style.cssと表示されます。あっさり。
compiled
コンパイル済みCSSはstyle.cssとして、同じフォルダに保存されます。この辺は実行時オプションで指定フォルダへ出力など可能です。
あえて、Stylusファイルをタイポ(ミスタイプ)してコンパイル・エラーを発生させてみます。
compile-error
「パースエラー 6行目24文字目 :があったんじゃない?」
とのことですが、5行目に { があるために、パース=構文解析の辻褄が合わなくてコンパイルが中断されました。
その後にエラーを出したモジュールがズラズラっと表示されます。
style.stylファイルを修正しましょう。Node.js、Stylus双方ともに何も変更されませんし、問題もありません。
生成されたCSSファイルの中身は下記の通り。

.menu-item {
    color: #257bcc;
    display: block;
    padding: 0.2rem 1rem;
    border-left: solid 3px #fff;
}
.menu-item:hover {
    border-left: solid 3px #257bcc;
}
.menu-item a:hover {
    text-decoration: none;
}

例えば、stylファイルではbright-h = #257bcc と16進数を色名に格納しておきます。
Styleファイルの4行目11行目ではcolor+色名で指定しておくと、コンパイル後のCSSでは16進数に展開されています。
diff-styl-css.png
実は、このコードはサイトのトップページのCSSの一部です。
グローバルメニューのリンクは、ホバーの時に文字色と同じ色の3pxの左ボーダーを表示する、という指定です。
2016-06-12_15h34_32.png
このようにShirohanadaテーマはStylファイルからstyle.cssを生成しています。
Stylusは単体アプリケーションとしても機能が豊富です。
Styleファイルへの変更を検知して自動でコンパイルしたり、
ベンダープレフィックスを付けるライブラリを使ったり、
ブラウザのインスペクタ(要素を調査)からStylファイルの何行目のスタイルが当たってるか分かったり…
素敵な機能が備わりまくりですが、実は私も使い切れてません。
この記事を書くために、改めてコマンドライン=CLIからStylusを使ってみた感触では、Node.js+Stylusだけでテーマ用のstyle.cssの作成はできそう。
なので、次回「StylusをCLIで使う」へ続く!

参考にしたサイト
Stylusを使ってみる | アカベコマイリ
SASSよりもStylusが優れている6つのポイント | Qiita

bright-h = #257bcc 
.menu-item color bright-h display block padding 0.2rem 1rem border-left solid 3px #fff &:hover border-left solid 3px bright-h & a:hover text-decoration none

WindowsでWockerを使う 光速編

先に書いた、WindowsでWockerを使う 記事の要約版です。
Windowsで最短手順でWockerを立ち上げる方法です。

インストール

3つのソフトをインストールして下さい。全て公式にインストーラがあります。
Wockerはダウンロードして展開するだけです。

  1. VirtualBox
  2. Vagrant 
  3. Git for Windows
  4. Wocker

Wockerの展開フォルダはどこでも構いませんが、漢字や空白のあるフォルダ内は避けた方がよいそうです。
私はDドライブ直下の D:\wocker に入れています。

コマンドラインから仮想化環境を起動

コマンドラインからWockerを起動します、コマンドは5つほどです。
Git Bashを管理者権限で起動します。

Git Bashを「管理者として実行」していれば、公式解説の通りで問題なく起動できます。

git1
git2
ここからGit Bashでコマンドを入れて操作します。
初回のみ、Vagrantプラグインを入れます
$ vagrant plugin install vagrant-hostsupdater
インストール済みのプラグインの一覧の確認は次のコマンドで。

$ vagrant plugin list

次に、Wockerのフォルダへ移動。

$ cd /d/wocker

現在のフォルダが/wockerになっていればOK。(下図の黄色い文字)
続けてVagrantコマンドで仮想化環境を起動。

$ vagrant up

git3
ずらずらっとログが出ます。
git4
起動に成功したら、再び$マークでコマンドが入力可能になります。

Wockerコンテナの起動と停止

$ vagrant ssh

上記コマンドで仮想化環境へコマンドラインから接続します。
Wockerへコマンドを送るために、この接続操作が必要です。
接続に成功したら、$の前が wocker ~ となっているはずです。
git5
Wockerデフォルトを起動してみます。

$ wocker start wocker

Wockerの起動に成功したらコンテナ名が表示されて、コマンド入力が可能になります。

$ wocker ps

また、上記コマンドで実行中の「コンテナ」が確認できます。
これでWordPress本体がローカルPC内で走っていますので、ブラウザで表示を確認します。
ブラウザから下記アドレスにアクセスします。

http://wocker.dev/

4.5のデフォルトテーマ TwentySixteenで”Hello Wolrd”記事が表示されます。(WordPressのバージョンは16年5月現在のWockerデフォルト)
wocker-dev
インストールとWockerの準備が終わってGit Bashでコマンドを打ち始めて、スムーズなら20分ぐらいでここまできます。
初回起動時はVagrant・Wockerが色々とダウンロードするので時間がかかりますが、二回目からはGit Bashを開いて1分程度で起動可能です。WindowsとWockerが同じSSDドライブに入っていればもっと速いかもしれません。
最後にWockerを止めて、仮想化環境も一時停止します。
再びGit BashからWockerへ停止コマンドを送ります。

wocker ~ $ wocker stop wocker

停止したら、Wockerへの接続から抜けます。

wocker ~ $ exit

仮想化環境を止めます。

$ vagrant halt

wocker-command1
停止しました。ブラウザから http://wocker.dev/ へアクセスしても、WordPressは表示されません。
この先は、「コンテナ」を作って個別の開発環境を用意していきます。
先に書いたこの記事が参考になればと思います。
WindowsでWockerを使う
Windowsでも快適なテーマ開発ライフを送りましょう。
それではごきげんよう。

Windows PowerShell

SSHやGit Bashを使っていると、
「ついコマンドプロンプトでlsと打ってからDirを打ってしまう」問題は、
2015年、遂に最終解決を見た。


D:\>ls
D:\>ls
'ls' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。
D:\>dir
 ドライブ D のボリューム ラベルは WD10EZEX です
 ボリューム シリアル番号は 0651-71F0 です
 D:\ のディレクトリ
2015/07/30  08:22    <DIR>          android-sdk
2015/08/02  09:36    <DIR>          android_project
2015/09/13  13:41    <DIR>          document

などということは、もうないのだ。Windows7以降は。
Windows PowerShellを使う。

PS D:\> ls
    ディレクトリ: D:\
Mode                LastWriteTime      Length Name
----                -------------      ------ ----
d-----       2015/07/30      8:22             android-sdk
d-----       2015/08/02      9:36             android_project
d-r---       2015/09/13     13:41             document
PS D:\>

完璧!