新しい日記

新しい日記

viewport units へさらなる理解

この記事は主に以下の記事を参考にしています。

bitsofco.de

viewportとは?

viewportを基本にした相対的な単位です。
vw, vh, vmin, vmax の4つがあります。

名前 単位 意味
viewport width vw ブラウザのviewportの横幅の1/100
viewport height vh ブラウザのviewportの縦長の1/100
minimum viewport vmin ブラウザのviewportの横幅と縦長のうち、小さい方の1/100
max viewport vmax ブラウザのviewportの横幅と縦長のうち、大きい方の1/100

ブラウザサポートはこんなかんじ

ブラウザ 対応状況 詳細、対処方法
IE8 × 使えないよ!
IE9 vminはvmと記述すること
IE10〜Edge vmaxのサポートなし
Opera mini × 使えないよ!
iOS 7.1 Safari 使えるけどバグがでやすい、これを使え

詳細はこれを参考に
Can I use... Support tables for HTML5, CSS3, etc

vwについて

そもそも、widthの%指定と何が違うのかというところですが、
%はhtml,bodyの幅を基軸に指し、
viewportはスクロールバーまでを含めた画面全体の幅を指します。

なので、もしも

.foo {
  width: 100vh;
}

と指定した場合には、画面をはみ出し横スクロールが出てしまうということです。
※最近のブラウザはスクロールバーが隠れていることが多いけど、その場合でもです。
このような微妙な差異が出てしまうため、画面いっぱいの横幅を指定する際は%の方が思う通りのスタイルになってくれます。
ただ、%は親要素の幅から計算されるため、HTMLのどの部分にある要素なのかという点を強く意識しなければいけないのもまたひとつの弱点です。
幅計算に微妙な差異はあるのものの、HTMLのどの部分にある要素であるかを意識せずとも画面幅からある程度の大きさを指定したいという際にはvwは非常にわかりやすい単位でもあります。

vhについて

vhとheightの%を比較すると、圧倒的にvhのほうが使い勝手が良いです。
というのも、heightの%指定は親要素にheightが指定されていない限り有効とならないからです。
このために、htmlといった文書のルート要素にあたるものにheight: 100%;としたり、親要素のheightをいちいち指定したりする必要があり、heightの%は非常に扱いにくい単位でした。
その点、vhはどこにあるどんな要素でもviewportから計算された高さを適用してくれます。
画面の高さいっぱいの要素を作りたいとしたら、

.foo {
  height: 100vh;
}

これだけでオッケー。
これで、どんな高さのブラウザでも必ず画面いっぱいの高さにフィットし、しかも画面のリサイズにも対応してくれます。最高!

応用編

基本的なことはわかったと思うので、これをどのような例に使えるのかを紹介します。

画面いっぱいの要素を並べたページ
.foo {
  width: 100%;
  height: 100vh;
}

たったのこれだけで要素が完璧に幅・高さ共にフィットしたスライドっぽいデザインにできるよ。

画像の最大幅・最大長をコントロールする
img{
  max-width: 100%;
  max-height: 90vh;
}

max-width や max-height に適用することで、必ず画面内に画像を収めたいときなどに便利。

横縦比固定のブロックを作る
.foo {
  width: 10vw;
  height: 10vw;
}

width, height ともに同じ viewport units による指定をすることで、横縦比を固定させたブロックを作ることができます。

シングルページ、かっこいいデザイン

条件

  • シングルページ
  • ビジュアル重視
  • スクロールアクション

Goodmoods | Where inspiration meets e-shopping
Phases Magazine


条件

  • シングルページ
  • width: 100%;

Lunar Gravity | We craft unique digital experiences throughout the universe.


例外

  • table!?!?

Epic Newsletter February 2015

最近はどこもかしこもヒーローイメージババーンみたいなのが多いな〜〜〜
枠つきのデザインかわいいからやりたい

git コマンドをつかっちゃお

git コマンド詳しくなくて恐縮ですが最近利用し始めたので自分用メモに残しておく

ブランチ間の差分をファイル名だけで出力する
git diff --name-only ブランチ1 ブランチ2
ブランチ間の差分をファイル名+ステータスで出力する
git diff --name-status ブランチ1 ブランチ2
ブランチ間の差分をzipでまとめる
git archive --format=zip head `git diff ブランチ名 master --name-only` -o archive.zip

ただし、これだと削除ファイルがあるとそれをまとめようとして
pathspec: did not match any files
と怒られる(何か解決方法がありそうですがわからない…)
ので、git archiveじゃなくてzipでやるとまとまってくれる

zip -r archive.zip `git diff ブランチ名 master --name-only`

ヒー、これで差分ファイルだけをzipでまとめてその各差分ファイルについて新規追加なのか更新なのか削除ファイルなのかをまとめて!っていう要望に応えることができてたすかりました

sourcetree で Git Flow を使ってみる

お恥ずかしながら、役職名の中にエンジニアって単語が入ってるのに git は sourcetree で使ってる。
git コマンドもあんまり詳しくないし…

sourcetree で git flow というブランチ管理をするにあたってのメモです。

まずmasterがあります。
f:id:tttttahiti:20150522122312p:plain

新しい案件Aが入ってきたので開発したいです。
なので、ブランチを切ろうと思います。
ここで、右上のほうにあるGit Flowを選択します!!
f:id:tttttahiti:20150522122626p:plain

そうするとこんなオプションが出てきます。
私はこのまま使っています。このままOKを押す。
f:id:tttttahiti:20150522122740p:plain

そしてもう一回Git Flowを押すとこんなのが出てくる
f:id:tttttahiti:20150522122931j:plain
今回は新しい開発案件なので、新規フィーチャーを選択しましょう。
他のものについては後ほど書きます。

そして、何かしら編集をしたら普通にコミットしたりプッシュしたりします。

f:id:tttttahiti:20150522123342p:plain

sourcetreeならorigin/feature/featureAというようにブランチが進んでいることがパッと見てすぐにわかります(そりゃそうですね)

ひと通り開発が終わったらこのフィーチャーを終わりにしましょう。また、Git Flow をクリック。
f:id:tttttahiti:20150522123604p:plain
ここでは推奨されるアクションであるところの「現在のブランチを終了」をクリックします。
そうするとfeatureAというブランチはdevelopブランチにマージされ、ローカルブランチは削除されます。

じゃあ次に違う案件Bが入ってきたのでまた同じように新規フィーチャーを開始しましょう。
同じように作業してコミットしてプッシュして〜
f:id:tttttahiti:20150522124259p:plain

案件Bを作業中のところ、同時に案件Cも進めて欲しいと言われました。
そんなときはまたGit Flowをクリックし、「現在のブランチを終了」の下にある「その他のアクション」というプルダウンメニュがあります。
このプルダウンメニュから新規フィーチャーを開始を選択すると、featureBブランチはそのままに、developブランチから新しくfeatureCブランチが切れます。

そして、作業してコミット&プッシュした様子
f:id:tttttahiti:20150522124658p:plain
ブランチっぽくなってきた

そこで、案件Cが作業終わりました。Git Flowから「現在のフィーチャーを終了」でdevelopにマージ&featureCブランチ削除。

次に、案件Bも作業終わりました。同じく「現在のフィーチャーを終了」。何かコンフリクトしてたら解決しましょう。
f:id:tttttahiti:20150522125124p:plain

ここまでで案件A、案件B、案件Cが終わったので、リリースすることになりました。
現在ブランチの様子をみるとdevelopブランチは進んでるけど、masterは最初のコミットのままですね。
リリースする情報はmasterにいれたいので、リリース準備作業をしましょう。
ここでまたGit Flowをクリックし、「新規リリースを開始」を選択すると、releaseブランチを切れます。

ここで何かしら準備して、ファイルの変更などがあったら普通にコミット&プッシュ。
f:id:tttttahiti:20150522125630p:plain

全部終わってリリース出来る状態になったら、Git Flow から 現在のブランチを終了を選択。
そうするとこんな画面がでてきます。
f:id:tttttahiti:20150522125815p:plain
メッセージのタグは適宜わかりやすく書いておきましょう

そして、OKをクリックするとreleaseブランチの内容がmasterとdevelopにマージされこんな状態になります。
f:id:tttttahiti:20150522130001p:plain
枝分かれしているな〜

あとはdevelopとmasterの両方にチェックついてるか確認してプッシュすればおしまい。
f:id:tttttahiti:20150522130307p:plain


さて、ひと通り終わってリリースしたけど、細かいところの修正依頼が来ました。
そんなときは Git Flow の 新規ホットフィックスを開始を選択しましょう。
masterブランチからhotfixAブランチが切れます。
何かしら修正してコミット&プッシュが終わったら、Git Flow→現在のブランチを終了を選択。
そうするとreleaseブランチを終了したときと同じような画面が出てきますので、同じようにメッセージ書いて、OKをクリック。
f:id:tttttahiti:20150522130816p:plain

先ほどのreleaseブランチを終了させたときと同じです。
hotfixAブランチがmasterとdevelopの両方にマージされます。
f:id:tttttahiti:20150522130845p:plain

あとはdevelopとmaster両方プッシュしておいてね!

各ブランチの使い方としては、
フィーチャー→新しい開発用。案件ごとに分けて作るのが○。このブランチを開始するときはdevelopから切られ、終了するときは、developブランチにマージされる。masterには関与しない!
リリース→フィーチャーが終わり、リリースに向けて作業するブランチ。developから切られ、developとmasterの両方にマージする。
ホットフィックス→小さい修正など用。masterから切られ、developとmasterの両方にマージする。
このようになると思います。

気をつけなきゃいけないと思うのは、各ブランチの終了のタイミング。
特に、リリース作業をすることが確定するまでフィーチャーブランチは終了させないほうがよいということ。
むやみやたらとフィーチャーブランチを終了させると、developブランチになんでも案件が混ざってしまいます。
そうすると、リリースブランチを切って〜終了させるときに、別の関係ない案件もmasterにマージしちゃう可能性があります。
逆に、この案件とこの案件はセットで納品したいというときは、それらのフィーチャーブランチを終了させてからリリースブランチを切ってマージすれば、スムーズにできます。

上手に使って運用に活かしましょう。

PHP short_open_tagの設定

以前にも調べた話題ですが
PHP省略タグについて - 新しい日記

これをOn Offさせる方法について。

php.iniをいじってサーバ全体について設定する方法
/etc/の中にphp.iniがあるので、その中をいじる

short_open_tag = Off //省略タグ使用不可

あるいは

short_open_tag = On //省略タグ使用可

サーバ全体を勝手にいじれなさそうなとき、.htaccessを使う方法

php_flag short_open_tag Off //省略タグ使用不可

あるいは

php_flag short_open_tag On //省略タグ使用可

以前調べた内容の通りデメリットもあるし、あとサーバが移転したときにいちいち設定しなおしたりするのだるいし、省略タグ使わないほうがいいですね

inline-block, line-height, vertical-align

良記事!!!

1html5experts.jp

2
https://html5experts.jp/takazudo/13464/

3
https://html5experts.jp/takazudo/13592/

4
理解しておきたい、CSSによるインラインレイアウトの仕組み(inline-block編)Inline Layout─Frontrend Conference | HTML5Experts.jp

技術関係ない話2

関係ないとまでは言わないけどそこまで関係ない話

Slack人気の理由を機能で説明がつかないと思っている人はたぶん多い、私はチャットツールあんまり比較してないのでわからんけど一応業務でSlackは使ってる

私が思うSlackのいいところ

  1. 絵文字がいっぱいある
  2. アイコンがかわいい
  3. 名前がいいやすい
  4. リンクとかコードとかいいかんじに貼れる
  5. 既読とかいちいちわかりやすいところに書かないでくれる
  6. メッセージをあとから編集できる
  7. チーム内オープンチャンネルとダイレクトメッセージの管理のしやすさ

私が思うSlackのよくないところ

  1. iOS版で通知が来るのか来ないのかよくわからん(バッジはつくから困りはしないしそもそも設定がミスってるのかな?)
  2. 英語ばっかりなので英語わからんっていう人に勧めにくい

結論Slack支持層が増えたのって主ターゲット層がSlack使いたい!Slackみんな使おうよ!っていう気持ちになるような優れたUXを提供できたという当たり前なことに落ち着くと思うんですが

UX、軽い口調で言葉に出すとひどい仕打ちにあうからあまりいいたくない言葉ランキング1位だけど、これについては優れたUXを提供できたということがまさにそれだと思います

使っててかゆいところに手が届くのはUX上すごく大事であって、かゆいところが残ったままだとイライラが募っていく、それをかゆいところにすっと手を届かせるナチュラルなアフォーダンス力といいますか、それは支持されるサービスの第一前提なのかなと思います。

それから、これを使っている私!というセルフブランディングに加担できるブランド力みたいなのがあるとより強い。気分産業なんて単語があったかもしれない。今はみんな機能やスペックよりも使ってどんな気持ちになるかを重視しているというやつ。これをやるのがSlackはうまかったんじゃないかな。
その要素として「いいやすい名前」「かわいいアイコン」「ナイスなUIパターン」とかが効いてくるのだろうと私は考えました。

macbook人気と近い、まさにそれ