VSCodeでRWD対応

最近、あるWebサイト^※１（以下、「サイト」と言う。）を全面リニューアルした。サイトを制作するためのツールとしてテキストエディッターが必要であるが、昨今は高機能テキストエディッターが無料で入手できることを知っていたので、この機会に使ってみることにした。
以下、リニューアルした経緯を交えながら、使用した無料テキストエディッターの体験を投稿する。
なお、この記事は自分でサイトを制作している（又は制作したい）が、どのテキストエディッターを使えば良いか悩んでいる人に参考になればとの思いで投稿している。従って、既に高機能テキストエディッターでサイトを制作している人、あるいはサイト制作に必要な言語をマスターせずに制作したい人には向かない内容である。

サイトリニューアルの経緯

私はサイトを自身で制作するが、よっぽどのことが起きない限り、制作済みサイトを全面リニューアルすることはない。その理由は単純で、ちょっとした更新なら良いが、新たにサイトを作り直すとなると、面倒臭いは時間は取られるはで、なかなか制作する気持ちになれないからである。
初めてサイトを制作したのはこのドメインのサイトで１９９７年頃であり、その後２０１２年に別ドメインのサイト（今回リニューアルしたサイト）を制作した。制作した当初はどちらも、一生このサイトを使い回し、将来リニューアルする気持ちは更々なかった。
しかし、その後モバイルが台頭しだし、時代の変化^※２からレスポンシブWebデザイン^※３（以下、「RWD」と言う。）の必要性を感じるようになった。
そこで、２０１４年の時に、本ブログの親サイトである「小松市不動産Navi」をＲＷＤ対応するために全面リニューアルをした。その一方で別サイトのＲＷＤ対応が残っていたが、面倒臭いので、いずれ暇になったら対応しようと思いつつズルズル先延ばししていた。なお、ブログに関しては、ＲＷＤ対応のテンプレートに変えるだけなので、既にＲＷＤのブログにしてある。

その一方で、Googleは２０１８年３月２７日に「モバイルファーストインデックス^※４」（以下、「MFI」と言う。）を開始することを発表し、準備が整ったサイトからＭＦＩへの移行が進められていたが、２０２１年３月末を持って強制移行が実施されることになった。
これにより、お尻に火が付き３月末までの完成を目標にＲＷＤ未対応サイトも全面リニューアルすることにした。

VSCode使用の経緯

従来から、サイト制作に当たり有償のソフトを使う気持ちは毛頭ないので、高機能のテキストエディッターを使ったことがなかった。
私が初めてサイトを制作した時は、Windows標準搭載のメモ帳で制作した。しかし、ファイルサイズが大きくなるとメモ帳で読み込めなくなり、Windows標準搭載のワードパットを使用しだした。その後、無償の「Crescent Eve」の存在を知り使い始めた。
「Crescent Eve」はWindows標準搭載のテキストエディッターに比べると、HTML入力に便利な機能が付いていた。例えば、HTMLタグの入力補完、終了タグの入力忘れなどの文法チェック、使用頻度の高いソースコードを定型句として登録できる機能などがある。
以後世の中にどんな無償のテキストエディッターが存在するのか知らないまま「Crescent Eve」を使い続けていた。めったにサイトを新規制作しない私に取って、サイトを一旦制作してしまえば、ちょっとした更新では軽い「Crescent Eve」は使い勝手も良く、エディター情報に疎い私でも無料の高機能テキストエディッターの存在を知るようになるものの調べてまで使ってみる気もならなかった。

しかし、今回RWD対応のため全面リニューアルをしなければならなくなったことを契機に高機能の無償テキストエディッターを使ってみる気に変わった。探してみると、「Visual Studio Code」（以下、「VSCode」と言う。）だけでなく、その他「Atom」や「Brackets」など色々あるようである。どれも無償と言っても全て試しに使ってみるとなると時間が取られ遣りたくない。そこで、良いソフトは多くの人が使用するだろうから、それを判断基準にして選ぶことにした。フロントエンドエンジニアが使用している（プログラミングに特化した）テキストエディッターのシェアは、VSCodeが断トツで高いことが分かり、私は迷うことなくVSCodeを選んだ。

• メガＩＴ企業であるマイクロソフトが開発しているので、長期的なサポートが期待できる。
• オープンソースなので、マイクロソフトだけでなく多くのエンジニアが開発に参加し新機能がリリースされ易い。

久しぶりにサイトを制作してみて

ＲＷＤ対応するに当たって、なるべく時間を取られたくなかったので、既にＲＷＤ対応してある本ブログの親サイトをなるべく流用して作ることにした。また、ＲＷＤ対応するがコンテンツ自体は既に存在するので、多少文章を見直す必要があるものの大部分は既に出来上がっている。よって、制作時間を多く取られることはないと考えていたが、すんなり進まなく想定していた以上に時間が取られてしまった。３月末までに完成させるつもりで始めたが、作業途中から間に合いそうもないと分かり頑張ったものの完成したのは４月１１日となり大幅に遅れた。

• 時間短縮のために既存サイトを流用したことによりデザインも流用元サイトに似ているものの、ＣＳＳをそのまま流用できなく、大幅な見直しとなった。その理由は、流用元のサイトをＲＷＤ対応した時、ＣＳＳのメディアクエリの設定は、当時の私は制作し易さを重視しモバイルラストの作りにしてあったが、今回のＲＷＤ対応では全く逆のモバイルファースト^※５にしたため、大幅な見直しが入ってしまった。
• 頻繁にサイトを制作している訳でなく７年ぶりだったので、全体的に思いの外スムーズに進まなかったと言うか、サイト制作を甘く見過ぎていたのかもしれない。

VSCodeの便利な機能

VSCodeの全機能を把握している訳でないが、その中でも便利と感じたものを以下に紹介する。

プラグイン

豊富なプラグイン（拡張機能）が用意されているので、自分の開発目的に合わせたパワーアップが実現できる。例を挙げると次のとおり。
なお、私の場合はサイトの制作を始める前に、便利そうな拡張機能を適当にインストールしただけなので、調べれば便利な拡張機能が色々ある筈である。また、ネット上にはお勧め拡張機能を紹介しているサイトが色々ある。

全角スペースの可視化（zenkaku）

全角スペースを灰色ボックスで可視化してくれる。以前、低機能のテキストエディターを使っている時、ＣＳＳファイルだったと思うが、ソースコードの行の最後に誤って全角スペースが入ったために表示が可笑しくなった。画面上ではスペースが見えないだけに、原因を調べるのに苦労した経験があったので、迷わずインストールした。

ＨＴＭＬ文法チェック（W3C validation）

HTMLの文法チェックを行う。単にインストールしただけでは動作しなく、ＪＤＫのインストール、システム環境変数の新規追加、Settings.jsonへの追加等が必要になる。ただ、私の環境下では、一旦動作したが翌日動作しなくなり、再度インストールし直すなどを試み動作しだす。その後再び動作しなくなる期間が続いた後、突然動作しだすも２日程度しかもたなかった。不安定で殆ど動作してくれないので、VSCode上で「W3C validation」を動作させることを諦める。

ＣＳＳ文法チェック（CSSTree validator）

ＣＳＳの記述が間違っている箇所に波線を引いてくれる。

ＨＴＭＬのリアルタイムビュー（Live Server）

修正等をしたＨＴＭＬファイルを保存したタイミングで自動的にブラウザが更新され、表示内容を確認できる。通常ならブラウザのウィンドウをアクティブにして更新ボタンをクリックする必要があるが、これらの操作が不要になる。ちょっとしたことと思うかもしれないが、使ってみると以外と便利。

ＣＳＳクラス名の補完（Intellisense for CSS class names in HTML）

ＨＴＭＬソースコードを打ち込んでいる時に、ＣＳＳファイル上に存在しているクラス名を補完する。インストールするも、なぜか私の環境下では動作せず。

ＣＳＳコード表示（CSS Peek）

ＨＴＭＬソースコード上で、設定されているＣＳＳの記述内容を表示してくれる。これまでだとＣＳＳの記述内容を確認したい時は、ＣＳＳファイルを表示させた上で検索し確認する必要があったが、このような操作が不要になる。ただ、なぜか私の環境下では、上手く動作してくれないこと有り。

ソースコードの整形機能（Prettier）

ソースコート保存時にコードを整形してくれるので、コードを打ち込んでいる時に見易くなるようにタブを挿入するようなことが不要になる。整形対象ファイル種別を把握していないが、少なくとも私が使用した全種別（html、css、js[jQuery]、JSON）が対象であった。

その他

なお、日本語版（Japanese Language Pack）にするのも、ソースコードを印刷（PrintCode）できるようにするのも拡張機能のインストールが必要になる。

ユーザースニペット

ユーザー自身が、頻発に使用する文字列（ソースコード）とそれと関連付けられた短縮名称（VSCodeでは「prefix」と言っている。）を登録することにより、短縮名称を入力するだけで関連付けられたソースコードを展開してくれる機能である。
「Crescent Eve」でも同様な機能として「定型句」があるが、次の大きな違いがあった。

• 「Crescent Eve」の場合は、短縮名称に相当するものがなく、登録番号を指定することにより展開される。従って、私のように頻繁にサイトの更新しないものは、間違った登録番号を指定してしまうことが良くあった。一方、VSCodeの場合は、短縮名称を工夫することによりソースコードの内容を推測し易くなるので、間違って展開させてしまうことはない。
• 登録可能件数は、「Crescent Eve」の場合は１０件と非常に少ないが、VSCodeの場合は十分な件数を登録できそうだ。
• 登録方法に関しては、「Crescent Eve」の場合は登録したい文字列を入力フォームにコピべするだけなので面倒なことはない。一方VSCodeの場合は、入力フォームが用意されていないのでユーザーが直接JSON^※６ファイルに入力しなければならない、JSONのデータフォーマットは難しくはないもののフォーマットに従って入力しなければならないので面倒臭い。無償なので文句を言える立場でないが、この仕様を知った時は驚いた。
• その他として、「Crescent Eve」は登録した文字列の特定の位置に特定の文字列を置換させる機能があり、VSCodeでも似たような目的の機能があるものの、「Crescent Eve」の方が使い勝手が良く、操作性も良い。

マルチカーソル

カーソル位置や単語を複数選択して同時に編集ができる機能である。ファイル内の全ての単語を書き換えるなら置換機能を使うと思うが、ファイルの一部のエリアに於いて複数の単語を纏めて置き換えることができ便利である。

エメット

HTMLやCSSのコードの入力を補完してくれる機能であり、規定のルールに従って省略形で入力するだけで、ＨＴＭＬやＣＳＳのコードが展開される。文章で上手く説明できないので例で示す。なお、ＨＴＭＬの記述に於いて使用できる記号には、ＣＳＳと同様な意味合いのものもあり、基本的な記述はマスターし易いと思う。
なお、豊富な記述例はEmmetの「cheat cheet」を参照されたし。

例１

ＨＴＭＬの場合で、入れ子（「>」）、クラス（「.」）かつ繰り返し（「*」）を使用した例である。

入力内容

ul.cls-name>li*3

入力の意味

「cls-name」クラス付きul要素、ul要素の子（入れ子）のli要素を３回繰り返して展開。

展開されるコード

<ul class=”cls-name”>
<li></li>
<li></li>
<li></li>
</ul>

例２

ＨＴＭＬの場合で、上記で使用した記号以外にＩＤ（「#」）、グループ化（「()」）、同階層（「+」）を使用した例である。

入力内容

table#id-name>(tr>th+td)*2

入力の意味

「id-name」ＩＤ付きtable要素、table要素の子孫要素としてグループ化された要素を２回繰り返して展開。なお、グループ化された要素は、table要素の子のtr要素、tr要素の子のth要素、th要素の兄弟（同階層）のtd要素。

展開されるコード

<table id=”id-name”>
<tr>
<th></th>
<td></td>
</tr>
<tr>
<th></th>
<td></td>
</tr>
</table>

例３

ＣＳＳの例である。ＣＳＳ上では、「プロパティ名：プロパティ値」（あるいは、「プロパティ名」のみ）を記述する時の補完機能のようである。従って、「要素名{ }」の波括弧内の入力時に働く機能のようだ。
私は使いこなしていないので正確性に欠けるかもしれないが、プロパティ名だけの場合は正式なプロパティ名の文字列を左から順に適当にピックアップして入力していけば、対象候補のプロパティ名が表示されるので容易に入力できる。一方、「プロパティ名：プロパティ値」の場合はどのように省略して入力すれば良いかは慣れて覚えるしかないように思う。

入力内容

mb:1r+p:5-10+bgc:#fff

入力の意味

３個のプロパティを「+」で結合して記述。なお「cheat cheet」を見ると、プロパティ名とプロパティ値の区切りを示す「:」（コロン）が付いているので本記事でもそれに合わせ「:」を付けているが、省略しても問題なく展開できるようだ。

展開されるコード

margin-bottom: 1rem;
padding: 5px 10px;
background-color: #fff;

画面の分割表示

ファイルの内容（ソースコード）を表示する領域は、分割することができる。分割した領域には、異なるファイルのソースコード表示させたり、１つのファイルの異なるエリアのソースコードを同時に表示させることにも使える。
ＨＴＭＬファイル、ＣＳＳファイル及びＪＳファイルは互いに関りを持つので、私の場合、２個（時には３個）に分割し、ＨＴＭＬ、ＣＳＳファイルあるいはＪＳファイルを同時に表示させる使い方をした。
これまでだったら、それぞれのファイルを「Crescent Eve」等を使ってウィンドウ上に表示させていた。常にある時点の見たいファイルは２個程度しかないが、作業をしていると、どんどんウィンドウの数が増えて行きＰＣ画面内はウィンドウで煩雑になり、見たいウィンドウ探してアクティブすることに煩わしさを感じることがよくあった。
しかし、VSCodeを使うようになってからは、常にその時点の見たいファイルを分割して表示させ、その他色んなウィンドウが表示されてる状態になったとしても、VSCodeのウィンドウをアクティブにするだけなので、煩わしさを感じなくなった。

便利さが伝わらないかもしれないが、実際使っていて結構気に入った。

ショートカット

VSCodeには豊富なショートカットが用意されている。ショートカットを利用すれば通常マウスで操作するようなことでも一発でキーボードから操作できるので、指をキーボードから離す必要がなくマウスの使用頻度が減り作業効率が上がる。
このように書くと、私がショートカットを使いこなしているように誤解されるが、現状は数ある中の極僅かなショートカットしか使用できていない。それでも便利と感じたショートカットが幾つもあるが、それらを挙げて行ったとしても私の使っていない便利なショートカットが数多くあることを考えると余り意味がない。そこで、便利さの雰囲気だけ味わえるように２例だけ紹介する。

コメントの設定／解除

ソースコード作成中はコメントアウトしたり、アンコメントすることが多く、またコードの注釈としてコメントを付けることが頻繁にある。

コメントにするには、コメントの開始や終了を示す文字列を入力する必要があり、ソースコードの種類（HTML、CSS、JS）によりその文字列が異なるため、コメントの設定／解除が煩わしい。

ショートカットを利用すれば、対象の行にカーソルを移動（複数行を対象にしたいのなら、複数行にまたがるようにドラッグ）した上で、「Ctrl」＋「/」を押下するだけで良い。対象行が有効なコードであればコメントアウトし、無効であればアンコメントしてくれ、しかもソースコードの種類に関係なく同じキー操作、つまりユーザーはソースコードの種類を意識する必要がなくなり非常に便利だと感じた。

保存

保存のショートカット（「Ctrl」＋「S」）は、他のテキストエディッターだけでなく、色んなアプリでも使われ、一般的なショートカットと思われる。ただ、拡張機能のリアルタイムビューと併用して使うと操作が大分異なってくる。

サイトを作成していると、試しに色々設定を変えてみて、どの設定がブラウザで最もしっくり表示されるかみたいことがある。このような時の一般的な操作は次のとおりである。

設定を変更するために、キーボードを使ってテキストエディッター上に表示されているソースコードを変更マウスを使ってテキストエディターのツールバーの「ファイル」をクリック表示されるプルダウンメニューから「保存」をクリックブラウザのウィンドウをアクティブにするためにマウスでそのウィンドウをクリックブラウザの更新ボタンをクリックして変更した表示状態を確認。別の設定を試すために、マウスでテキストエディターのウィンドウをクリックしてアクティブにする。以後、同様の操作を繰り返す。

一方、保存のショートカットとリアルタイムビューを使うと次の操作になる。

まず、VSCodeでソースコードを変更している時は、ブラウザウィンドウとVSCodeウィンドウが重なっているとブラウザウィンドウが下になり隠れてしまう。そこで、ブラウザで確認したい部分がVSCodeウィンドウで隠れないようにするために、ウィンドウの位置をずらしておく。その状態で、VSCode上に表示されているソースコードをキーボードで変更マウスを使わずショートカットで保存リアルタイムビューはブラウザがアクティブになっていなくても更新してくれるので、ユーザーは何の操作をすることなく変更した表示状態を確認できる。この時、VSCodeウィンドウはアクティブのままなので、アクティブウィンドウの切り替えを行わずに、続けてキーボードでソースコードを変更していける。

文章だと便利さが上手く伝わらないかもしれないが、私はショートカットとリアルタイムビューにより一連の操作が簡略化され非常に便利に感じた。ソースコードの変更内容にもよるが、マウスをほぼ使わずキーボードだけで作業を完結することができる。

ＲＷＤ対応の影響

ＲＷＤ対応することにより、検索順位に影響を与えるのか興味があり、参考程度に３，４月前後の検索順位を追ってみた。
Googleの移行期限が３月３１日、ＲＷＤ対応を完了しサーバーにアップロードしたのが４月１１日、（私の見方が正しければ）ＲＷＤ対応のページをGoogleがインデックスしたのも４月１１日である。
少なくとも私のサイトでは、期限前のモバイルフレンドリーでないサイト（～３月３１日）、期限を過ぎたモバイルフレンドリーでないサイト（４月１日～４月１１日）、モバイルフレンドリーサイト（４月１１日～）の違いにより、明らかな順位の変動は微塵も見られなかった。
サイトのコンテンツ量が、ＰＣに比べモバイルが極端に少ないと影響を受けるのではとの情報もあり、デバイスにより表示されるコンテンツ量が変わらない今回の対応では影響がないのかもしれない。ただ、お尻に火が付いた状態で、遅れながらも頑張って対応しただけに、ちょっと拍子抜け感があり「トホホ」である。
しかし、この短い期間では影響が無かったが、サイトを運営している以上、ＲＷＤ対応は避けて通れなく不可欠な対応であったことは疑う余地がない。
ちなみに、ＲＷＤ対応したサイトをアップロードした２日後に、コロナ禍で需要が極端に低迷している中、スマホでサイトを閲覧した人から空港前月極駐車場の申し込みがあったので、今回の頑張りが功を奏したと思いたい。

所見

独り言

サイトを作成していると、こんな変なことが起こるのかと思うことが良くある。私はめったにサイトを制作しないので記録しておかないと忘れてしまう。これまでもそのような時はメモったこともあっただろうが、余りにも年数が経ってしまうとメモがあるか探すのも大変なので探す気も起きない。
そこで、この場を借りて自分のために備忘録を残しておくことにしたので悪しからず。

備忘録