私は 90 年代後半から HTML を書いてきました。Web は百種類の異なる方法で進化してきましたが、Web の核心は実際には変わっていません。ファイルを開いてマークアップを構成し、CSS でスタイルを設定し、見た目や動作が希望どおりになるまで調整します。基本は同じです。タグはよりセマンティックになり、レイアウトはより柔軟になり、標準はより厳密になりましたが、本質的な HTML は依然として 1 行ずつ作成されています。
劇的に変わったのはツールです。エディターは、拡張機能、パネル、ターミナル、および私が決して触れることのない機能が満載された完全な開発環境に膨れ上がりました。 Visual Studio Code や WebStorm などのツールは非常に強力ですが、重いものでもあります。クリーンで軽量なワークフローを、一度にすべてを実行しようとする巨大なワークフローと交換する必要性を感じたことはありません。私のプロジェクトでは、書き込み、バージョン管理、検証をカバーするシンプルなスタックを使用します。これらは、私がすべての HTML および CSS プロジェクトで使用する 3 つのツールです。
NoteTab Pro が依然として私の HTML ワークフローを支えている理由
私は初めてプログラミングを始めたときから NoteTab Pro を使用しており、ずっと私のワークフローに残っている数少ないツールの 1 つです。何年にもわたって機能が追加されてきましたが、肥大化したり、気が散るものになったりすることはありませんでした。即座に起動し、リソースをほとんど使用しないため、拡張機能、パネル、バックグラウンド サービスを管理する代わりにマークアップに集中できます。その一貫性が重要です。数年ごとに編集者を学び直す必要はありません。予測可能であってほしい。
私の仕事の種類としては、それがぴったりです。長い形式の記事を構成したり、きれいなレイアウトを構築したり、特定のルールを使用して CMS のコンテンツをフォーマットしたりする場合、組み込みの HTML ライブラリと CSS ライブラリを使用するとプロセスが高速になります。構造化された要素をすばやくドロップし、属性を調整して次に進むことができます。スニペットをカスタマイズする機能は、CMS に癖がある場合や厳密な書式要件がある場合に特に役立ちます。コード テンプレートを一度調整すれば、無期限に再利用できます。
JavaScript フレームワークを管理しようとしたり、完全な開発環境として機能しようとしたりするのではなく、それが重要です。ウェブを構築してくれるエディターは必要ありません。素早くロードして、スムーズにきれいな HTML を記述して、完了して公開できるように邪魔をしないようにする必要があります。
GitHub Desktop が HTML 作業のセーフティ ネットである理由
私のスタックに新しく追加されたのは GitHub Desktop だけですが、それでも、バージョン管理という 1 つの仕事のために存在しています。これは Git のグラフィカル インターフェイスであり、コマンド ラインに触れることなく、変更の追跡、編集内容の行ごとのレビュー、ブランチの作成、間違いのロールバックを行うことができます。レイアウトの調整や構造の変更を試したい場合は、安全に分岐できます。何かが壊れた場合でも、数秒で前のバージョンに復元できます。この種のセーフティネットは、間違いが起こったときに非常に貴重なものになります。
NoteTab Pro と並行して実行されます。いつものようにファイルを書いて保存します。 GitHub Desktop はプロジェクト フォルダーを監視するだけです。論理的な停止点に到達したら、短い説明を付けてコミットし、次に進みます。私は HTML プロジェクトのほとんどを GitHub にプッシュすることさえしません。私の仕事ではローカルリポジトリで十分です。コラボレーションやクラウド ホスティングには使用していません。私はこれをバージョン履歴、ロールバック、および制御された実験に使用しています。実際の HTML と CSS の構築方法を変えることなく、保険と構造を提供します。
オンラインバリデーターが HTML と CSS を正直に保つ理由
私はオンラインバリデーターを使い続けます。なぜなら、オンラインバリデーターはシンプルでスムーズだからです。別のアプリをバックグラウンドで実行したり、エディターに緊密に接続したりする必要はありません。ページをチェックする準備ができたら、URL を貼り付けるかファイルをアップロードし、結果を確認し、修正が必要なものを修正して、次に進みます。私のマルチモニター設定では、ある画面でバリデーターを開き、別の画面で NoteTab Pro を開いたままにして、フォーカスを中断することなく問題にすばやく対処します。検証を一定のバックグラウンドノイズに変えるのではなく、意図的に検証を続けます。
私が信頼する HTML の標準チェック
HTML の場合は、W3C マークアップ検証サービスを使用します。これが開発者の間でよく知られている名前には理由があります。ドキュメント構造、不適切なネスト、属性の欠落、および最新の HTML 仕様に対する標準への準拠をチェックします。ダイレクトなので気に入ってます。何が間違っているのか、どこが間違っているのか、そしてなぜそれが重要なのかを教えてくれます。推測は必要ありません。構造的に何かがおかしい場合は、すぐにわかります。
CSS を検証する簡単な方法
CSS については、W3C CSS Validator を利用しています。それはまさにその言葉通りのことを行います。無効なプロパティ、タイプミス、仕様に準拠していないルールにフラグを立てます。 CSS は場合によっては失敗する可能性があるため、標準ベースのチェックを行うことで、ずさんなスタイルを出荷していないという自信が得られます。これは、自分が書いた内容がクリーンで技術的に正しいことを確認する簡単な方法です。
ローカル検証が意味のある場合
さらに一歩進んだ検証を行いたい場合は、最新の HTML 検証と W3C の現在のマークアップ チェックを強化する Nu Html Checker も利用できます。ローカルで実行できますが、ツールをダウンロードし、コマンド ラインから Java を使用して実行する必要があります。この設定は難しくありませんが、Web インターフェイスを使用するよりも複雑です。私のワークフローでは、オンラインバリデーターで十分です。一括検証や自動化が必要な場合は、次のステップとしてローカル Nu チェッカーを使用することになります。
より良いプログラマーになる: 成長するための 7 つの習慣
より良いプログラムを書くための、歴戦の習慣。
このシンプルなスタックが今でも機能する理由
私は大規模な Web アプリを構築したり、無秩序に広がるフロントエンド フレームワークを管理したりしているわけではありません。私はクリーンで構造化された HTML と CSS を作成して公開していますが、そのような作業にはこのスタックで十分です。 NoteTab Pro はスピードと予測可能性を与えてくれます。 GitHub Desktop は構造とロールバックを提供します。 W3C バリデーターは、すべてを標準に準拠し、技術的に健全な状態に保ちます。意図的に最小限に抑えられていますが、何年も Web 用に構築してきた私は、シンプルで信頼できるものは、複雑で肥大化するものよりも優れていることを学びました。