HTML5ではaタグ内にdivといったブロック要素と呼ばれていたものをネストできるようになった

 

タイトル通りです!

ネストのルールって難しいです。

 

 

ulにネストしていいのはliだけなのに、liの中はなんでもネストしていいとか・・・。

HTML5以前では、ブロック要素やインライン要素を使ってのルールがありました。

が、

HTML5からブロック要素インライン要素といった分類がなくなりました。

 

そのかわり(?)としてコンテンツモデル

という概念ができました。

 

コンテンツモデル:各要素が内包できるコンテンツ

 

HTML要素は、0個以上の以下カテゴリーに属しています。

  • フローコンテンツ
  • メタデータコンテンツ
  • セクショニングコンテンツ
  • ヘッディングコンテンツ
  • フレージングコンテンツ
  • エンベッディッドコンテンツ
  • インタラクティブコンテンツ

 

これにより

今まで「インライン要素」と呼んでいた要素が

フレージングコンテンツとなったようです。

 

 

本題に戻ると・・・

a(アンカー)要素の仕様を見ると、

コンテンツモデル…..transparent(透過)

↑親要素のコンテンツモデルがそのまま継承されるという意味

 

 

 

例えば、

<p>

  <a href=”#”>リンク</a>

</p>

・a要素の親はp要素である。

・p要素のコンテンツモデルはフレージングコンテンツである。

→a要素にネストできる要素は

<span>,<a>,<img>といった、フレージングコンテンツとなる。

 

 

また、

<div>

  <a href=”#”>リンク</a>

</div>

・a要素の親はdiv要素である。

・div要素のコンテンツモデルはフローコンテンツである。

→a要素にネストできる要素は

メタデータコンテンツの一部を除いたほぼすべての要素となる。

 

 

git stashってadd(インデックス)してないと意味ないんだ!

 

タイトルの通りです。

 

Gitが苦手なもので、とりあえず、stashしちゃうんです。

んで、必要な時にstash popしてます。便利ですよね〜\(^^)/

 

超便利と感じつつ、stashをどんどん貯めていくのですが、

結局、使わず、溜まってくばかりなのですが。

 

そんな GIT stash に関して
私は大きな勘違いをしていることに昨日気がつかされました!

 

git stashってインデックスにあるもの(git addしたやつ)をstashします。

作業ツリーのものはstashしてないのです!

 

 

「だからたまに、"stashしたはずなのに、あのファイルがない!"とかなってたんだ・・・。」

 

 

作業ツリーからインデックス(git add)にあがることにより、

追跡(tracking)が開始されるのです。

よって、git addしなければ、バージョン管理外なのです!

 

##まとめ##

作業ツリーがダーティ(クリーンではない状態)の時は、

stashしたいものをaddして追跡を開始させたのちに、

git stashを実行すること!

 

 

 

 

 

 

 

HTTPステータスコード

 

参考:ここここ

Webに携わってもう直ぐ1年。

Webサイトをいじる中、スペルミスや設定ミスでエラーをよく見てきたのですが、

ヘッダーのstatus codeを見て、404の場合はパスが間違ってんのかな〜、

500番台に場合はPHPのコードスペルミスでのしたのかな〜とか確認してます。

しかし、このくらいしか分かりません。

 

 

この前、406エラーがでて、なにこれ!?ってなったので覚書します。

406 Not Acceptable 受理不可

Webサーバからクライアントへのレスポンスに、クライアントが受理できないデータが含まれている場合に発生する。

だそうです。

例)サーバはapplication/jsonを送信したかったが、リクエストのAccept:ヘッダにapplication/jsonが含まれていなかった。

 

 

まとめ

 

  • 100番台 ・・・ Information

リクエストは受け入れられ、処理は継続

  • 200番台 ・・・ Success

リクエストは正常に受け取られ、受理された。

  • 300番台 ・・・ Redirection

リクエストを完了するためには、他のURL等を参照する必要がある。

  • 400番台 ・・・ Client Error

クライアント側のエラー

  • 500番台 ・・・ Server Error

サーバー側のエラー

DRYの原則

参考:ここ

DRY

=Don’t Repeat Yourself

直訳すると「繰り返すな。」という意味です。

 

同じような内容のコードが重複していると、

変更際、重複の数だけ変更しなければなりません。

また、いざそのコードを使う時に、どれを使えば良いのかわからなくなります。

 

同じようなコードは一箇所にまとめとけ!同じようなコードは何度も書くな!

→再利用性の高いコードを書く必要がある。

 

この原則を守ると、シンプルで保守しやすいコードが書きやすくなるとのことです。

「シンプルなコードを書きたい!!」

 

関連している原則:

・Once and Only Once(OAOO)一度、ただ一度

OCP 開放閉鎖の原則

SRP 単一責務の原則

 

 

 

ISP(The Interface Segregation Principle) – SOLID

ISP(The Interface Segregation Principle)
– クライアントに対して利用しないインタフェースへの依存を強制してはならない。

参考:ここここ

 

・インターフェイスはクライアント(使う側)の都合により変更される

→インターフェイスはそれを使うクライアントごとに分離されるべき

 

 

・インターフェイスが分離されていないと、

クライアントにサーバが依存すべきところが、

サーバにクライアントが依存してしまい、

変更のたびに全体へ影響を与えてしまう。

→依存関係の逆転が成り立たず、脆弱となる。

 

 

・太った(いろんな役割を持つ=便利な)インターフェイスにしない。

→SRP(単一責務の原則)にする

 

・依存をできる限り減らす。

→クラス間の結合度(Coupling)を減らす

 

オブジェクト指向って難しい・・・。

 

 

 

LSP(The Liskov Substitution Principle)- SOLID

LSP(The Liskov Substitution Principle)リスコフの置換原則
– 派生クラスは、その基底クラスと置換可能でなくてはならない。

 

参考:ここ

 

リスコフさんが提唱した、置換原則です。

置換するもの:親クラスと子クラス

この2つが置き換えることができなければならない。

 

よく、子クラスに親クラスをオーバーライドするのですが、

その時、親クラスの意図する動きをしなければならないということ。

 

LSP ありきの ODP

子クラスと親クラスが置き換え可能でないと、

そのクラスに依存するクラスの変更時、

子クラスor親クラスからの来たのかの条件文が必要となり、

変更が大変、浪費がかかる。

=拡張にしにくく、修正が多い

ODP(オープン・クローズドの原則)に反している。

 

 

 

DIP(The Dependency Inversion Principle)- SOLID

DIP(The Dependency Inversion Principle)依存性逆転の原則
– 具象化されたものではなく、抽象化されたものに依存するべきである。

参考:こちら

 

具体的なものに依存するより、抽象的なものに依存した方が

影響少ないよ!安パイ!

と言った感じでしょうか。

 

 

インターフェイス、クライアント・・・。

いまいちわからない(´ι_` )

 

インターフェイス  → 使うもの

クライアント   → 使う人

とこんな感じ?

 

参考記事の

「所有権」も逆転している。

この意味がわかりません。

わかったら追記します!

OCP(The Open-Closed Principle)- SOLID

OCP(The Open-Closed Principle)オープン・クローズドの原則
– オブジェクトは拡張に対して開いており、修正に対して閉じていなければならない。

参考:こちら

 

この法則ですが、よく聞くし、言いたいこともなんとなくわかるのですが、

どうすれば、この法則に沿ったソースが書けるか、なってるのかがまだわかんないですね。わかったらまた書こう。

 

ー オブジェクト指向の核心をついている

というますが、オブジェクト指向がまだまだなので、「確かにそうだ!」とかまだ言えるレベルではないです、はい。

 

オブジェクト指向の話って、よく「抽象」て言葉が出てくるんですけど、

日本語が苦手なので、ここで覚えます。

「抽象」《名・ス他》

多くの物や事柄や具体的な概念から、それらの範囲の全部に共通な属性を抜き出し、これを一般的な概念としてとらえること。
(ほうほう、なるほど、共通部分を簡潔に捉える的な感じですかね?)

まとめ
・追加/継承する時が楽にできる(開放)
・その時、既存のコードを変更しなくていい、
そのコードが使われる時、使う主体に影響を与えない(閉鎖)

 

⇒使う側にも、使われる側にも影響が少ないもの

SRP(The Single Responsibility Principle)- SOLID

SOLIDとは…
オブジェクト指向設計の五つの原則の頭文字をとったものだそうです。

SRP(The Single Responsibility Principle)
– クラスの責務は単一でなければならない。

OCP(The Open-Closed Principle)
– オブジェクトは拡張に対して開いており、修正に対して閉じていなければならない。

LSP(The Liskov Substitution Principle)
– 派生クラスは、その基底クラスと置換可能でなくてはならない。

ISP(The Interface Segregation Principle)
– クライアントに対して利用しないインタフェースへの依存を強制してはならない。

DIP(The Dependency Inversion Principle)
– 具象化されたものではなく、抽象化されたものに依存するべきである。

 

今回は、
SRP(The Single Responsibility Principle)単一責務の原則
-クラスの責務は単一でなければならない。

について、書きます。

1つのクラスには、1つの責任・役割を持たせる。

その理由としては、
クラスの責任・役割を小さくすることで、読みやすくて、保守性も上がるからだそうです。

コードの変更の必要が発生した時、1つのクラスに複数の役割の関数をもたせていた場合、
依存が大量に発生し、変更箇所が増える。
こんな感じかなっと掴んでいます。この読みが当たっているかはわかりませんが・・・。

設計って大事だなっと、しみじみと思いました。 おわり

参考:
オブジェクト指向の法則集
プログラマが知るべき97のこと