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

「始める」があるなら「後で始める」を用意すべきでは。
「始める」以外に選択肢がないのに、クリックさせる意味はあるんだろうか。
Kitami Akiya @ 涼天環
WindowsユーザーはChromiumEdgeを「始めない」という選択は許されない。
「始める」があるなら「後で始める」を用意すべきでは。
「始める」以外に選択肢がないのに、クリックさせる意味はあるんだろうか。
リモートリポジトリを BitBucket にしていると、SourceTreeが頻繁に認証画面を出してきて非常に鬱陶しい。
何も入れずに閉じてもPull / Pushはできている。
どうやら、バックグラウンドでFetchした時に認証を求めてくるようだ。SourceTreeは一定時間ごとに裏でFetchをしてリモートの情報を取ってきている。
環境は以下の通り、
特にGitHubとBitBucketの両方のリモートリポジトリをSourceTreeで扱っていると起きやすい気がする。
ほぼ、2.のSourceTree / Gitが保持しているログイン情報を設定、修正すればいいと思う。
ただ、Windowsの認証管理で問題が出ていても、Windowsの方からは何らエラーが出ないので厄介である。なので、これも対処に含めた。
結論だけ言うと、自分の場合はSourceTreeのアカウント設定で「デフォルトに設定」をするだけでよかった模様。
間違った認証情報がWindowsに登録されてしまうと、
という、無限ループにはまってしまう場合があるようだ。
認証に成功したらその時の情報が入りそうなものだが、更新に失敗する場合があるのだろうか?
Windowsの設定にある「資格情報マネージャー」から、BitBucket関係の認証情報を一旦削除してしまう。
「設定」画面から「資格情報」で検索すると早い。
あるいはコントロールパネルから入る。
「Windows 資格情報」の方に、
git:https://akiya64@bitbucket.org
とあるので、今回はこれである。他にあればBitBucketに関係する資格情報は一旦、全て削除する。
認証に失敗した場合でも、認証情報は追記されているため問題の切り分けが面倒になっている。
修正もできるので、正しく設定し直してやればいいのかもしれない。
SourceTreeにはコードホスティングサービスのアカウント情報が登録できる。
メニューバーの ツール → オプション → 認証を開く。
アカウントにBitBucketがないので追加する。
「Git保存されたパスワード」とは別の扱いである。
認証方法は BasicかOAuthが選べる。Basicの場合は、ここでユーザー名を入力してパスワードで認証する。
OAuthなら「OAuthトークンを再読み込み」で下記のようにBitBucketのWebサイトが開くので、連携アプリケーションのアクセスを許可してやればよい。
ついで、ユーザー名のデフォルト設定をしておく。
これをしていないと、所有者が自分でないBitBucketのリモートにアクセスするとログインエラーになるようだ。
実は私の場合、ここのユーザー名の設定一発で認証画面が頻繁に表示される問題は解消した。
何となくPull/Pushできるものだから、そのまま使ってきていたが、SourceTreeにアカウント情報を登録できるのだからやっておくべきだった。
OAuthで認証できるなら、こっちの方が断然、楽で確実である。
CSSプリプロセッサ=Sass(SCSS)とかLESSとかでCSSを生成してやると、複雑なCSSもシンプルで見通しのいいソースコード=CSSメタ言語から生成できます。
今回はそのCSSプリプロセッサを、例によってWindows10で使ってみましょう。
今、プリプロセッサって言いました?! Sassだぁ!
いいえ、Stylusです。
メジャーどころのSassはWindowsではRuby実行環境もインストールする必要があります(MacだとRubyは最初から入ってるそうです)。またStylusはNode.js謹製のプリプロセッサでもある。GulpとかGrantとか、タスクランナーと組み合わせると便利らしいです。
ですが、いきなり全部やると大変ですし、ややこしいです。今回はコマンドラインからStylusでCSSをコンパイルしてみましょう。
Stylusを入れるにあたって、下準備が二つほど要ります。
その後、Node.jsの機能を使ってStylusをインストール、CSSのコンパイルを試します。
Node.jsは基本的にコマンドラインから使います。
だが、いにしえのコマンドプロンプトとは訣別しよう。Windows 7以降ならば、Windows PowerShellというコマンドラインが使えます。
Windows PowerShell、略称WPS。以下でもWPSと書けばWindows PowerShellのことを指します。
一旦、管理者として起動してWPSの実行モードを変更する。
Stylusコマンドを実行するだけなら、この設定変更は不要かも知れない。
私はWindows10 64bitを使用しているので、互換性のためかx86(32bit)のWPSもある。多分どちらでもいい。
起動したら、何か警告が出ている。
「セキュリティ上の問題があるので、WPSから実行できるスクリプトに制限をかけていますよ」とのこと。
WPSの実行制限モードを変更する。
> Set-ExecutionPolicy RemoteSigned
上記コマンドを入力。Yで続行。制限モードをRemoteSignedとして、ローカルで作成したスクリプトとリモートからは信頼できるスクリプトのみの実行とする。
再度、WPSを起動してみる。警告メッセージなし。
lsコマンドが使えるので、それだけでも乗り換える価値があります。
WPSはどの実行制限が妥当か、実は私では見当が付いてません。
下記サイトでは、Remote Signedが最適とのことです。企業だと社内ネットワークやPCのセキュリティポリシーなども関係してきます。詳しい人がいたら確認してみて欲しい。そして私にも教えて頂けると幸いです。
Remote Signed
- 実行ポリシーがRemote Singedに設定されている場合、ローカルで作成されたあらゆるPowerShellスクリプトを実行することが許される。リモートで作成されたスクリプトは、信頼できる発行元が署名したものしか実行できない。
Google先生に聞くまでもありません、最短距離でNode.jsの公式サイトへ行きましょう。
Node.js公式サイト https://nodejs.org/en/
Windows用のインストーラである.msiファイルを用意してくれてます、多謝。
スクリーンショットでは、node-v4.4.5-x64.msi ファイルをダウンロードしています。
(バージョンは2016年6月現在)
ダウンロードしたファイルからインストール、以上。
WPSから
> node –v
でバージョンが確認できれば、Node.jsのインストールは一先ず完了です。
私のNode.js は4.0.0ですね。
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で作業するとします。
> cd ~/
> cd \new-project
cd ~/ で ユーザーのホームへ移動、私のPCならC:\Users\akiyaに移動する。ある程度ファイル名を入力したらTabキーで候補が出る。
new-projectフォルダでnpm install を実行、この時は -g を付けない。
> npm install stylus
ログにWARN何とかが出ているかもしれませんが警告なので、一応問題はない。
Errorの場合はインストールが止まるはずです。
インストールが終わったらnew-projectフォルダにnode_moduleフォルダが増えます。
この中にJavaScriptライブラリやモジュールが沢山入っていて、コンパイル処理で呼び出されます。
もちろん、どこにnew-projectフォルダを置いてもいいし、作業フォルダの名前も好きに決められます。フォルダを作ったら作業フォルダへのインストールを忘れずに。
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と表示されます。あっさり。
コンパイル済みCSSはstyle.cssとして、同じフォルダに保存されます。この辺は実行時オプションで指定フォルダへ出力など可能です。
あえて、Stylusファイルをタイポ(ミスタイプ)してコンパイル・エラーを発生させてみます。
「パースエラー 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進数に展開されています。
実は、このコードはサイトのトップページのCSSの一部です。
グローバルメニューのリンクは、ホバーの時に文字色と同じ色の3pxの左ボーダーを表示する、という指定です。
このように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を立ち上げる方法です。
3つのソフトをインストールして下さい。全て公式にインストーラがあります。
Wockerはダウンロードして展開するだけです。
Wockerの展開フォルダはどこでも構いませんが、漢字や空白のあるフォルダ内は避けた方がよいそうです。
私はDドライブ直下の D:\wocker に入れています。
コマンドラインからWockerを起動します、コマンドは5つほどです。
Git Bashを管理者権限で起動します。
Git Bashを「管理者として実行」していれば、公式解説の通りで問題なく起動できます。
ここからGit Bashでコマンドを入れて操作します。
初回のみ、Vagrantプラグインを入れます
$ vagrant plugin install vagrant-hostsupdater
インストール済みのプラグインの一覧の確認は次のコマンドで。
$ vagrant plugin list
次に、Wockerのフォルダへ移動。
$ cd /d/wocker
現在のフォルダが/wockerになっていればOK。(下図の黄色い文字)
続けてVagrantコマンドで仮想化環境を起動。
$ vagrant up
ずらずらっとログが出ます。
起動に成功したら、再び$マークでコマンドが入力可能になります。
$ vagrant ssh
上記コマンドで仮想化環境へコマンドラインから接続します。
Wockerへコマンドを送るために、この接続操作が必要です。
接続に成功したら、$の前が wocker ~ となっているはずです。
Wockerデフォルトを起動してみます。
$ wocker start wocker
Wockerの起動に成功したらコンテナ名が表示されて、コマンド入力が可能になります。
$ wocker ps
また、上記コマンドで実行中の「コンテナ」が確認できます。
これでWordPress本体がローカルPC内で走っていますので、ブラウザで表示を確認します。
ブラウザから下記アドレスにアクセスします。
http://wocker.dev/
4.5のデフォルトテーマ TwentySixteenで”Hello Wolrd”記事が表示されます。(WordPressのバージョンは16年5月現在のWockerデフォルト)
インストールと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
停止しました。ブラウザから http://wocker.dev/ へアクセスしても、WordPressは表示されません。
この先は、「コンテナ」を作って個別の開発環境を用意していきます。
先に書いたこの記事が参考になればと思います。
WindowsでWockerを使う
Windowsでも快適なテーマ開発ライフを送りましょう。
それではごきげんよう。
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:\>
完璧!