-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* 進捗 * 校正 * 長くなったので分割してシリーズ化 * なんか丸数字①②がtitleに入れられなかったので修正 * 進捗 * HTMLの学習法にちょっと触れる * 長くなったので分割 * 進捗 * 進捗 * 投稿日時を修正 * 投稿に向けてファイル名の変更 * 日付の修正 * 投稿時刻の変更 * 校正・推敲
- Loading branch information
1 parent
cfcf195
commit 41fdffa
Showing
3 changed files
with
244 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
+++ | ||
title = '私的Webサイト制作史part.1' | ||
date = 2024-08-19T00:00:00+09:00 | ||
categories = ["ポエム","技術","経験談"] | ||
draft = false | ||
+++ | ||
# 私的Webサイト制作史part.1 | ||
|
||
意外と周りにWebサイト制作してみた、もしくは作ってみたい、みたいな人がたくさんいたりして、極稀にどうやって学んだの?とは……聞かれませんが、僕的にはこっちから自分の経験を語りたいので、ちょっと書いてみます。 | ||
|
||
こうした方が良いとかっていう意味で書いているのではないです。こんなふうに学んだ人がいたよ~っていう一例というか、こういうことに困っているけど調べ方がわからない、みたいな人の一助になったらいいかなぁ、とか思って書いています。全くの技術的文書のつもりで書いていないので、気軽にふ~んと思って読んでいただけると幸いです。 | ||
|
||
書いていたら、いつの間にか原稿がずいぶん長くなってしまったのでシリーズ化しています。 | ||
|
||
## 最初は本から | ||
|
||
正直言ってあんまり覚えていないです。 | ||
|
||
HTML/CSS/JSを知ったのは適当なGoogle検索の結果だったと思います。本格的に興味を持って行動して最初に辿り着いたのは本だったと思います。その本ではHTMLにとても感動した記憶があります。 | ||
|
||
その本を読んでいて、やけに印象的だったのが、HTMLは文書をほぼ半永久的に保存できるということを強調していたことです。そもそもHTML自体は現在WAHTWGで策定/仕様公開している列記とした国際規格で、ブラウザさえあれば読むことが可能です。その上中身はただのテキストファイルなので、テキストエディターさえあればとりあえず読めます。僕は、HTMLのその保存性に強く感動しました。 | ||
|
||
その本を読んだときが、確か中2くらいだったと思いますが、その当時はそこまで本格的にWebサイトを作ろうとかいう意欲はなく、ちょっとお遊びでHTMLをちょこっとメモ帳で書いた感じです。HTMLに感動してHTMLばかりに興味があったのでCSSは全く書いていません。しかも、書いたパソコンがWindowsXPだったので、その本が推奨していたHTML5に対応していなくて、本に僅かながら書いてあったレガシーコードを参考に書いたという思い出があります。 | ||
|
||
その本を読んだ後も、興味の赴くままに、非連続的にその手の本を見つけては読んでいたと思います。 | ||
|
||
## 色々な教材で学んだ初期 | ||
|
||
### やっぱり個性派文庫 | ||
|
||
本格的にHTML/CSSをコーディングし始めたのは、やっぱり個性派文庫なんですよね。当時はミカフラ文庫と称して、ミカエル・フラグメント(鬼詠雪介)を掲載していたと思います。もともとWordでやっていたのをHTMLにも乗り出した動機は縦書きができるを知ったからです(これも記事にしたら面白そう……)。確かこの辺からVS Codeを使い出したと思います。 | ||
|
||
#### 地獄のHTML化 | ||
|
||
ミカフラの当時の最新話までの原稿を、見様見真似でいろんなサイトを参考にしながら手作業でHTMLにしてました。SSGとか知らなかった時代ですから、新規ファイル作ったらドキュメントタイプ宣言から書いていました。ルビ振ったり段落切ったり。 | ||
|
||
特に自分がこだわっていたのがルビ振りで、各話に初めて出てくる難しめの単語に限ってルビを振るというルールをWord時代からやっていて(これも我ながらどえらいめんどくさいことをしていたと思います)、これをHTML版でも踏襲していました。すべての単語に対してルビを振るなら単純な置換で一発なのになぁとか思っていました。今思えばPythonとかで一発で実現できそうな話ですね(辞書ファイル作るのが少々面倒だけど)。まぁその地獄のHTML化をミカフラはほぼ全て手作業でやってたような気がします。 | ||
|
||
その後は何時だかから、ネットの似たような事例をほぼマルパクリしながらWordのルビをHTMLのタグに変換するマクロを自作して、テキストファイルに移行するつい最近まで対応していた気がします。 | ||
|
||
ついでにテキスト検索/置換を知って使い始めたのはミカフラの編集を始めてから、正規表現はHTMLを弄り始めてからです。これもまた記事にしてもいいかも…… | ||
|
||
### WebサイトっぽくしたくてCSSを触る | ||
|
||
最初は小説原稿をHTMLに手作業で変換していっただけでしたが、やっぱりちゃんとしたサイトが欲しかったので、作り始めました。ここらへんから本格的にCSSを学び始めたんじゃないかと思います。 | ||
|
||
最初は軽く本とかをこんなことができるんだ~みたいな感じで読んで、実際に作り始めたらやりたいことを検索欄にぶち込んで参考になりそうな記事を読みながらCSSを書いたって感じです。 | ||
|
||
#### クラスセレクターを使いたくない | ||
|
||
当時の自分にとっては、HTMLはあくまで文書であって、文章の中身(コード)がそれなりに読みやすくあるべきだと思っていました。そちゃ可読性は重要ですが、ちょっとベクトルが違って、今回の話はもっと初歩的な話です。HTMLってタグが増えるとごちゃごちゃしてきて、慣れないと少々読みにくいじゃないですか。だから、あまり余計は属性を付けてごちゃごちゃさせたくなかったんですよ。それから単に記述量が増えるのがめんどくさかったというのも覚えています。あとクラスの命名法というか、命名するための語彙がなかったっというのも影響していると思います。 | ||
|
||
コードを読むとわかりますが、必要最小限のタグにしかクラスを付けてないです。要素セレクターを最優先で使って、クラスセレクターは要素セレクターで選択できないときに使っていた感じです。 | ||
|
||
#### HTMLタグにクラスを一つしか付けられないと思い込む | ||
|
||
単純に思い込みました。CSS設計を知るまでは、ずっとすべてのスタイルをシングルクラスで実装していました。べつにシングルクラスで実装すること自体は悪いことではないんですが… | ||
|
||
#### 記述量を極力抑えたい | ||
|
||
CSSって、頑張れば記述量を抑えることが出来ます。なので様々なセレクターを駆使して、1行2行レベルの重複コードの被りを撲滅するような方針でCSSを書いていました。 | ||
|
||
#### クソコード爆誕 | ||
|
||
クラスセレクターを使いたくない、HTMLタグにクラスを1つしか付けられないと思い込んだ、様々なセレクターを駆使して記述量を減らす、の3つが主な原因となってクソコードが爆誕しました。 | ||
|
||
クラスセレクターよりも要素セレクターの使用を優先して、クラスの子に対してスタイルを当てる、みたいなことをしたせいで、HTMLの構造に強く依存したコードになりました。当時はエディターのEmmetを用いればHTMLの構造の依存なんか怖くないとか思っていました。HTMLの構造が変わった瞬間にスタイルが崩れるので本当に苦労しました。 | ||
|
||
タグにクラス1つしか付けられないと思い込んだせいで、重複コードを増やす構造になっていて、様々なセレクターを駆使して記述量を抑える方針と競合して、中途半端で無駄に労力のかかった覚えがあります。その上タグ1つに1クラスの都合で、たまに子要素を追加したりしてHTMLの構造が変わったりして、構造依存なCSSの変更をしないといけなくなったりして余計に大変でした。 | ||
|
||
## 終わりに | ||
|
||
ここまでで僕のWebサイト制作史の初期が終わりました。いかがだったでしょうか?同様の悩みを持っている人がいれば、シリーズ第二弾が解決してくれるかもしれません。次回「CSS設計到来」! |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
+++ | ||
title = '私的Webサイト制作史part.2' | ||
date = 2024-08-20T00:00:00+09:00 | ||
categories = ["ポエム","技術","経験談"] | ||
draft = false | ||
+++ | ||
# 私的Webサイト制作史part.2 | ||
|
||
書いていたらいつの間にか3000文字を超えていたので、分割してシリーズ化しました。今回は僕が脱初心者した話です。 | ||
|
||
## CSS設計に出会う | ||
|
||
前回の説明で、CSSのコードがカオスになったんだなぁと言うのは想像に難くないと思います。実際、CSSというのはカオスになりやすい構造を持っています。僕の場合は単にアホなことをしていただけですが……。まぁCSSはカオスになります。 | ||
|
||
### CSS設計って何? | ||
|
||
そこで、出てくるのがCSS設計というものです。CSS設計とは、読んで字の如く、CSSがカオスにならないように秩序立ててコーディングする手法の総称です。BEMとかOOCSとかSMACSとかが知られてますね。ものによりますが、大体、セレクターの使い方とかクラスの命名法とか、こういうところではこのプロパティを使ってはならないとかが規定されています。 | ||
|
||
### CSS設計を知るのってムズくね? | ||
|
||
僕の経験になりますが、Webサイトを作っている過程でCSS設計に出会うのは、その必要性に対して、なかなか難しいと思います(サンプル数1)。 | ||
|
||
というのも、初心者の間っていうのは、初心者のためのサイトを見るものです。そういうところっていうのは大概言語仕様を解説しているに過ぎず、そういう設計とか工夫みたいな書き方とでも言いましょうか、一歩進んだ中級者になるためのやり方は教えていないんことが多いんですよ。精々クラスセレクターをうまく工夫して…程度のことです。更に、世の中熟練度別の人口はピラミッド型をしているはずで、儲けようと思っているサイトは、人口が多く需要が高い初心者向けの教材を作ったほうが儲かります。その上、そういう儲けようと思っているサイトは、PV数を稼ぐためにSEOがつよつよなので、検索にも引っかかりやすくなっています。僕はそういうサイトを否定したいわけではないですが、CSS設計にたどり着けるように、リンクを貼るなりCSS設計解説記事みたいな脱初心者/至中級者みたいな導入をする記事があってもいいと思うんですよね。 | ||
|
||
また、今まで僕はCSSがカオスになるという表現をしていますが、そもそもWebサイトを作り始めたばかりの僕にはその語彙/表現がありませんでした。その表現を知ったのはCSS設計を知ってからです。当時の僕のHTML/CSS学習は、Google先生にキーワードを尋ねるスタイルだったので、言葉がわからないと検索しようがないんですね。今ならばAIを使えばCSS設計という単語を引き出せるかもしれません。 | ||
|
||
以上の理由で、CSS設計にたどり着くのは難しかったのだと考えています。 | ||
|
||
### 出会いはGoogle検索アプリのニュース | ||
|
||
Google検索アプリのニュースって、可処分時間をゴリゴリ奪ってくる忌々しきショート動画に匹敵しそうなぐらい、僕にとっては見ていられるものです。しかし、Google検索アプリのニュースは、あくまで娯楽でしかないショート動画と違って、トレンドのQiita記事とかZennの記事が流れてきます。なので、学習のインプットするのに比較的良いと感じています。 | ||
|
||
ある日のこと、いつものようにGoogle検索アプリのニュースを眺めていたらCSS設計とかいう初めての言葉をテーマにした記事が流れてきました。覗いてみれば、これこそが自分がモヤモヤしていた原因で、CSS設計を使えば解決できるということがわかりました。これがCSS設計との出会いです。本当に偶然です。 | ||
|
||
### CSS設計は何で学んだのか | ||
|
||
最初は適当なQiita記事や、個人ブログみたいなのを参考に学んだと思います。僕はBEMを採用したのでほとんどBEMしか学んでいません。 | ||
|
||
ただ、CSS設計くらいまで来ると、体系的な教材がネット上に見つからないんですね。HTML/CSSの言語仕様ならたくさん体系的な教材があったのに……。CSS設計はそういう意味でも学びにくいような感じがします。手法としてはちゃんとドキュメントとして存在しているので、そういうのを読んでも良いのですけど、やっぱり最初は第三者が書いた記事を読みたいと思うものです。公式ドキュメントってとっつきにくいので。 | ||
|
||
ネットに情報が少ないので、僕は本を探しました。というか中級者になるならどんなことでも書籍に当たるのが良いのではないかと思っています。実際本は結構出ています。ただ、それが当時の僕の手の届きやすい価格帯、もしくは場所にあるかといえばないのですけど。当時僕は高校の図書館の先生と仲が良かったので、お願いしてCSS設計の本を1冊入れてもらいました。非常にありがたかったです。 | ||
|
||
### CSS設計が変えたもの | ||
|
||
CSS設計に出会ったことで、自分のCSSのコードがスッキリするようになりました。管理性、拡張性が向上して、楽になりました。 | ||
|
||
## SSGに出会う | ||
|
||
SSGに出会ったのもCSS設計に出会ったのとほぼ同時期だったように思います。出会い方もほぼ一緒だと思います。実践したのが同時期だったのは確実に言えますが……。個性派文庫のサイトリニューアルのときに両方とも導入したので。 | ||
|
||
#### SSGって何 | ||
|
||
SSGは日本語で静的サイトジェネレーター(Static Site Generator)というツールのことで、SSGのルールに則って書いたコードを、サーバーにアップロードできるHTML/CSS/JSのファイル群に変換してくれます。最近はSSRとかの登場で静的/動的の境目がぼやけているので説明が難しいです。 | ||
|
||
このサイトでもHugoというSSGを使っています。[このサイトのリポジトリ](https://github.com/ToYama170402/ToYama170402.github.io)を見てくれるとわかりますけど、この一見Webサーバーにアップロードしてもなんの意味もないファイル群は、Hugoを通して変換することで、Webサイトとして機能するファイル群になります。 | ||
|
||
#### 何が良いのよ | ||
|
||
Webサイトの部品を一元管理のもとで使い回すことができることが最初に僕が感じたメリットです。 | ||
|
||
それまでの個性派文庫では、ヘッダーやフッター、ボタンなどのサイトの各ページで使い回すような部品はコピペして使いまわしていました。そこで、ヘッダーの見た目を変えるために編集したとしましょう。そうしたら、他のページ全てにコピペし直す必要があります。それが2,3ページ程度ならなんとかなるかもしれませんが、いつか必ずコピペを忘れて悲惨なことになります。 | ||
|
||
SSGを使うとコピペをプログラムにやらせるので、絶対そのような悲惨な状況になることはありません。部品をファイル単位で管理して、部品を変更すればその部品を使っているすべてのページにその変更が反映されるからです。 | ||
|
||
また、SSGにはマークダウンなどのテキストベースのドキュメントファイルをHTMLに変換してくれる機能もついていたりします。このブログもその機能を活用して書いています。毎回毎回HTMLを書いていると流石に死んじゃいます。今やHTMLは人間が書くものではなく機械が書く時代になっているのです(それでも基礎を知ることは大事なのでちゃんとHTMLも勉強しましょう)。 | ||
|
||
#### 何で学んだのか | ||
|
||
流石にSSGともなってくると、HTMLとかCSS設計みたいないわゆる界隈の常識みたいなものではなくなってきます。そのため、体系的な解説書が存在するわけではなく、ネット上に散乱している導入事例を参考にしたり、もっと細かく弄るのであればツールを作っている公式のドキュメントみたいなものを読むようになってきます。 | ||
|
||
個性派文庫で採用したのはJekyllで、これにはありがたいことに公式で日本語のドキュメントサポートがありました。というかJekyllの開発言語のRubyが国産なんですよね。とまぁ、その日本語ドキュメントとか巷に散乱している事例を拾いながら作ったって感じです。 | ||
|
||
対してこのブログではHugoを採用したというのは前に書いたとおりです。Hugoはたくさんの導入事例があったので、あまり公式のドキュメントは参考にしませんでした。また、既存のテーマを導入して少しいじっただけなのでそこまで深いことはやっていないっていうのも公式ドキュメントにお世話にならなかった理由です。 | ||
|
||
## 終わりに | ||
|
||
書いていたらまたもや3000文字を超えてしまったのでこのへんで切って、次回に回しましょう。次回は次の個性派文庫のリニューアルで使いたい技術/ツールに触れてみた話が主題です。 |
Oops, something went wrong.