viewportについて

 

viewport

ってスマホ対応の時使うレスポンシブル対応のやつだな、

っということしかわからなかっための勉強します!

 

 

参考:http://ichimaruni-design.com/2015/01/viewport/

 

 

結論

・スマホサイトがある場合

<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0">

 

width=device-width : 幅をデバイスごとにサイズを切り替えてくれる!

 

initial-scale:初期のズーム倍率

 

※device-width  ⇄ 初期のズーム倍率が 1 になる。(initial-scale=1.0)

 

minimum-scale=1.0とすることで最小倍率を指定しているが、初期ズーム倍率と等しいため、縮小できない状態。

なぜ、縮小できなくするのか謎・・・。

Yahoo!の天気サイトもしてた・・。これ↓

<meta name=”viewport” content=”width=device-width,initial-scale=1.0,maximum-scale=1.0,minimum-scale=1.0,user-scalable=no”>

user-scalable=noってしてるのに、拡大できるやん?なんで?

 

と、思ったらいろんなサイト比較してるとこ発見!

 

 

しかし、よくわからない。

maximum-scale=1.0,minimum-scale=1.0,user-scalable=no

ってどうなれば正しい挙動なの?

 

・PCサイトしかなく、SPで最適化したい場合

<meta name="viewport" content="width=960(コンテンツの大きさ)">

これすれば、横の余白がなくなる。

 

シーケンスの初期化

 

シーケンスって便利ですよね。

SQLでもできるし、phppgadminを使えばGUIでも操作できる!

 

しかし、シーケンス設定っていまいちよくわからないのでまとめます。

 

  • phppgadminでのシーケンスの作成

phppgadminでシーケンスを作成しようとするとこんな画面がでます。

名前:シーケンスの名前をつけます。

よく見るのは「 テーブル名_カラム名_seq」ですね。

増加数:直前の数値からいくつ増加するか。

最小値:デフォルトは1。

最大値:MAX値

開始値:デフォルトは最小値と同じ。

キャッシュ値:メモリに格納しておくシーケンス番号の量を指定します。

これによりアクセスを高速にすることができます。

最小値は1(デフォルト)

Can cycle?:番号が最大値を超えた場合に最小値に戻るかどうか。

「いいえ」(デフォルト)が指定された場合、シーケンスの限界値に達した後の

       nextval呼び出しは全てエラーになる。

ログカウント:わからん!誰か教えてください。

Will increment last value before returning next value (is_called)?:

訳)次の値を返す前に最終値を増加しますか?

 

 

例えば、

増加数:1

最小値:1

開始値:1

Will increment last value before returning next value (is_called)?:いいえ

このシーケンスは1から始まり、2,3,4,….と1ずつ増加します。

 

 

 

  • phppgadminでのシーケンスの初期化

1.「リセット」をクリック。//最終値が1となる

2.「Restart」をクリック。//Will increment last value before returning next value (is_called)?が「いいえ」となる

 

 

  • SQLでのシーケンスの初期化

SELECT setval (‘シーケンス名’,  1,  false);

第2引数:最終値

第3引数:値を返す前に増加させるか<</Will increment last value before returning next value (is_called)?>>  true(増加する)/false(増加させない)

よく使うGitコマンド

 

Git DIFF

ブランチ間の差分を表示

$ git diff master[取り込むほう] develop[取り込まれるほう]

 

ブランチ間の差分があるファイル一覧を表示

$ git diff master[取り込むほう] develop[取り込まれるほう] --name-status

 

ブランチ間の差分があるファイル数を表示

$ git diff master[取り込むほう] develop[取り込まれるほう] --name-status | wc -l

 

 

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)依存性反転の原則

– 抽象に依存すべき。具象クラスに依存してはいけない。

 

HeadFirstデザインパターンの説明が分かりやすかったです。

↑では様々な種類のPizza(NYCheesePizza,NYClamPizza…)を作るPizzaStoreを例に出しています🍕🍕🍕

 

[Before]なにも考えず実装する🙄

PizzaStoreは具象クラスであるNYCheesePizzaやNYClamPizzaに依存しています。

高水準なクラス PizzaStoreから低水準なクラスNYCheesePizzaに依存する形となり、依存の方向は上から下(矢印)になっています。

 

デメリット🙅‍♂️

PizzaStoreは4つの具象クラス依存しており、Pizzaの種類が増えるとさらに依存する具象クラスが増え、コードの修正も必要となってしまいます。

 

 

[After]DIPに沿った実装をする🤔

抽象クラスPizzaを追加しました。

PizzaStoreは抽象クラスPizzaを作成し、抽象クラスPizzaに依存するようになります。

また、具象クラスだったNYCheesePizzaやNYClamPizzaは抽象クラスPizzaを実装するようになり、抽象クラスPizzaに依存するようになりました。

これにより、原則通りにPizzaStoreもNYCheesePizzaやNYClamPizzaもすべて抽象に依存するようになりました!!!

さらに、依存の方向を示す矢印も上から下だったものが「反転」して、下から上への依存となりました💡

 

メリット🙆‍♂️

PizzaStoreは具体的なPizzaの種類を知らなくていい(抽象Pizzaクラスしか知らない)ので、新しい具象Pizzaクラスが作成されても修正は少なくなります。

 

 

まとめ

この原則に従った設計を考える時には、高水準コンポーネントではなく低水準コンポーネントから抽象化できないかを考えていくといい気がしました。

 

また、この原則に従うための指針として

  • 具象クラスへの参照を保持する変数を持たない
  • 具象クラスからクラスを継承しない
  • ベースクラスの実装済みメソッドをオーバーライドしない

というのも大事だなと改めて感じました。

 

\ 改めて、この本おすすめです🍺/