return falseの罠

こんばんは、有村です。
2017年ももう終わりますね。早いものです。

さてさて、今日のテーマはreturn falseの罠です!
さっそくコードサンプルを。。。

hogeとfuga両方とも、クリックでalertが出るというコード。
fugaをクリックした時は、バブリングによって「fuga → hoge」とアラートが出るようになっています。

ん?なって…います……?

実際にはこのコードだと、fugaクリック時には「fugaしかalertが出ない」となってしまいます!

ここで私はひっかかりました。。
このfuga、a要素本来の動き(リンク)を殺したくてreturn false;をつけているのですが、
return false;によってバブリングまで死んでしまって、
本来「fuga → hoge」とクリックイベントが伝搬するはずが、fugaで止まってしまったんですね…。

おさらい。
return false;って何をしているのか。
preventDefault(要素のイベント、つまりaだったらリンクのイベントをキャンセル)
stopPropagation(バブリングをキャンセル)
この2つが行われる。

なので、もしa要素本来の動きを殺したいだけであれば、

と書くべきだったのですね;;

return false;は便利なんですけど、たまにこのようなひっかけがあるので、
「何をキャンセルしたいのか」を常に意識することが大事だな〜と思いました!

それでは、きょうはこのへんで。

ハードの用語について調べてみた

こんにちは!有村です!
最近よく色んな人に、「ほんっとにハードのこと何も知らないんだな…」という顔をされます!

メモリは多い方がよさそう、SSDって速そう、Core iなんちゃらって数字が大きければ優秀?
そんな前知識でIT従事者と話してたら、そりゃ呆れ顔されますよね!

というわけで、今回のテーマはハードの用語について調べてみたです!
プログラムは書けてもハードは良く知らない…そんな同志がいたら、お役に立つと嬉しいです!!

CPUってなに?
central processing unitの略。中央演算処理装置。
こいつが優秀であればあるほど、ユーザからの命令処理の能力が上がるらしい。

何をもって優秀と呼ぶかは、
・クロック数(GHz)、数字が大きいほうが優秀
・コア数、多ければ多いほど同時に処理速度が上がる
これらの数字も関わってくるみたい。

また、クロック数においては、
Turbo Boost
というブースト数値も見ておいたほうが良さそう。

Turbo Boostは、超簡潔に言えば「もしまだCPU全体の発熱に余裕があるなら、負荷が高いコアの性能を上げる(ブーストする)わ」
ということらしい。
Turbo Boostに書かれている数値は、ブースト時に最大ここまでクロック数が上がるよ、というもの。

いつもブーストしとけばいいじゃんと一瞬思ったけれど、「発熱」というワードが大事。
全員が常にブーストしてしまうと、熱で即死亡ですもんね…。

GPUってなに?
Graphics Processing Unitの略。画像演算処理装置。
CPUと名前似とるやんとずっと思ってたのですが、こちらは画像処理に特化した演算装置のようです。

PCでゲームする人にはかなり重要かも知れません!
グラフィックの描画性能が低ければ、もちろんゲームの動きももっさり、カクカクしますよね…(実体験)
GPUはCPUと同じくらい大事な装置だと理解!

SSDってなに?
solid state driveの略。半導体素子メモリのことらしいけど…正直それだけ聞いても分からん。
データの読み書きをするやつ。HDDの仲間のようなもの。

色々読んでいて分かりやすかった説明は、USBメモリと同じ仕組みだということ。
HDDは円盤がくるくる回って、物理的に情報を読み書きしているけれど、SSDはメモリチップでそれを行うため、
HDDと比べて読み書きが非常に速い!

なら全部SSDでいいじゃんと思ったのですが、PC売り場を見ていても分かるように、SSDってそれ自体が高いんですよね…。
なので、システムやエディタなど高速なやりとりが必要になるものはSSDに、音楽や画像など頻繁にアクセスしないものは外付けHDDに、という
住み分けも大事そうです。

これで、PC売り場のスペック表を見ても、なんとな〜く理解できそうですね!
まだまだハード用語あると思いますが、ひとまずきょうはこのへんで。

条件文をシンプルに!

こんばんはー、有村です。
今日も通常運転で学んだことを好きなように書きます。

今日のテーマは条件文をシンプルに
頭では分かっていても、なかなか難しいんですよね〜。
そこでまずはいつも私が書くソースの例。

いつものように用途不明ですけど、要は引数の値に応じて計算式を変えて、その結果を引数として別の関数を実行しようってやつです。
これを整理していきます。

1・共通項を見つける
たとえば上の例だと、「calcに計算した値を代入する」「calcを引数にしてfugaを実行する」という流れが同じですね。

2・三項演算子を使ってみる
ワンライナーで済む内容であれば、三項演算子がシンプル。

慣れるまでちょっと読みにくいけど。

で、きれいにするとこうなる。

みじかくなった。

短いからいいと言うよりは、共通項がまとまって余計な処理が減ったことが大きいですね。
処理の記述が多いと、どうしても煩雑に見えてしまうので。

共通項はなんだろう?って考えることは、物事を抽象化して捉えることと近しいのですかね?
色々繋がってますね〜。

それでは、今日はこのへんで。

ガード節と正常系と異常系

こんばんは。有村です。
寒いですね〜、うちの猫も布団にばかり居るようになりました。私も1日中、布団の中だけに居たい。

さてさて今日はガード節周りについて学んだので、忘れないように記録を残しておきます!

まずは、今まで分かったようで分かっていなかった「正常系と異常系」について。
超ライトに言うなら、
正常系 … 期待された処理や内容、いわばノーマルケース
異常系 … レアケース、めったに来ない珍客
的な感じ。

これは、引数で渡された食物をもぐもぐする用途不明関数なのですが。(こういうのしか思いつかなかった)
普通、食べ物って植物とか肉とかで、金属って食べないですよね。金属持って来られて食え!って言われるなんて考えもしないし、「食べる」という目的からすると、食べられないものを持って来られることは「異常」と見なすことができますよね。
なので、上の関数だと、
異常系 … 金属
正常系 … 金属以外
になります。

で、本題のガード節は、「起きにくい事象(異常系)だけど、もしそれが起きてしまったら、そのまま出て行ってもらう」という考え方だそうです。
正常系の動作に続いてしまう前にはじくってことですね。
それで、明確に「お前は異常系なんやで」ということを示す書き方(ガード節)がこれ。

if で囲まれた部分がガード節です。異常系、正常系を if の範囲で示すことで、先程より明瞭性が増した気がしますね!
else が無くなった分、記述がすっきりしたのも好印象。

ただし、正常系と異常系が分かれない場合もある、という点には注意しなければいけないようです。
具体的に言うと…

この関数は引数によって性別を判定するものですが、この分岐では「男」と「女」に正常と異常の区別はありません。(これをウェイトが同じ、とか言うらしい)
もし、

とかの条件式であれば、それが異常系になるのだと思いますが。

今日はこのへんでおしまい!
おつかれさまでした、おやすみなさい!

CSSにルールをつくる

こんばんは、有村です。
さすがにもう年始ムードはなくなりましたね〜、次の連休いつかなあ…

さて今日のテーマは「CSSにルールをつくる」です。
コーディング規約というよりは自分の中での設計に近いのかもしれませんが、そのレベルに達していないので、ここはルールという言葉を使います。

今日の有村ルールはこれ。
繋げる要素が3つ超えたら切り離す。

有村はこんなルールでclass命名を考えていました。

つまり、ネストするにつれて、その親のclass名を子が継承していくルールです。
こうしていた理由は、親と子の関係性をclass名で示したいなと思ったのと、.meun .list .inner とかすることで無意味に詳細度を上げたくなかったからです。

でもお気づきですね、そう、これネストが深くなるととんでもなくclass名なげぇってなるんです。困った。

今日そんな悩みをCSS設計のプロ(イケメン)に相談したら、こんな助言をもらいました。
3つ以上繋がったら切り離せ、と。

なぜかと有村聞きました。有村的にまとめた理由はこう。

・設計の基本は、その機能(たとえばトグルリスト、とかボタン、とか)をそれぞれモジュールとして考える。
・見た目ではなく機能として捉える。
・そうなったとき、上のルールでclass名が長くなりすぎる = 複数のモジュールがひとつになってしまっているのでは?と考える。
・ひとつのモジュールの目安はだいたい3ネスト。上のルールのclassで表すと、.hoge_fuga_arimura。それ以上超えたら、一度立ち止まって考える。

確かに先程のソースでは、
「メニューのリスト」と「矢印アイコンの箱」の2つにモジュールが分割できるように見えます。
それが全て「メニューのリスト」として扱われてしまっているから、こんなに長くなるのですね。

で、改良案。

自分の中でも納得がいきました!

まずはこのルールを自分の中でのベースとして、もっといい案があればどんどん取り入れたいですね!

それでは、今日はこのへんで。

原則を知る ーDRYー

こんばんは、原田です。

さっき地元の知り合いから電話がきて、地元に帰りたくなりました。はい。

 

 

最近、上司に「どれが良い実装で、どれが悪い実装なのかが分からない」と相談しました。

すると、「原則を知るといい。」という助言を頂きました。

原則  …特別な場合は別として、一般に適用される根本的な法則。

確かに、原則を知ることは、いいコードが分かる導きになるかもしれないと思い、これからちょいちょい原則を書いていこうと思います!!!

 

ではでは、

今日の原則は〜・・・・

DRY

です。

乾燥という意味ではありません。(知らなかったのは私だけですかね?)

DRY(Don’t  Repeat Yourself)

重複を防ぐ考え方。

Single Source of truthとも言うそうです。

 

なぜ重複を防いだ方が良いのか?

重複が多い→変更時に変更箇所が増える→時間がかかる

情報量が多い→明確でない→不一致が生じる可能性がある

という点があるからだそうです。

 

ということで、今後はまとめることができたり、同じような実装が複数ある場合は、関数化したりしてDRYに努めようと思います。

jQueryで追加した要素にイベントを付与する!

こんばんは、有村です。年の瀬ですね。
おそらく今年最後の投稿です。

今日は、「jQueryで追加した要素にイベントを付与する」をテーマに記事を書きます。

まずは簡単な仕様。

・ページ読み込み後、複数の .parent に対して .child を子要素として保持しているか精査。
・.child を保持していた場合、.parent の子要素として .btn を追加する。
・.btn をクリックすると、.child が開いたり閉じたりする。

まあ要はアコーディオンってやつですね。
ここのポイントは、「ページ読み込みの状態では .btn は存在していない」という点です。

で、私は最初こう書きました。

動きそうに見えるじゃないですか?
でも、実際には…

・子要素に .child がいれば、ボタンは追加される
・でも .btn を押しても何も起こらない

という挙動になりました。なぜ。

原因はお分かりですね、 .btn に click イベントを付与するタイミングでは、まだ .btn が存在していないんです。
なので、後から「追加されたでーーーwww」ってやってきた .btn ちゃんは、イベントを何も持っていない…となるのです。

で、早速解決法。

先ほどと違うのは、セレクタが .parent になって、on の第2引数に .btn が追加された点です。

じゃあなぜこれで動くのか?どうやらこれはバブリングを利用しているようです。
バブリングは 対象 → 先祖 にイベントが伝わっていくことを指します。つまり、.btn をクリックしたら、その親要素である .parent にもクリックイベントが伝わっているということです。
それを利用して、このonメソッドでは、

・.btn をクリックする
・.parent にバブリングでクリックイベントが伝わる
・元々のイベントの発生源が第2引数の要素とマッチしているか精査
・マッチしていたならばfunction実行

という流れが行われているようです。便利!!!!
thisの値も、発生源である .btn 自身が返ってきます。

年の終わりにいい発見があってよかったです!
来年もこまめに更新できたら…いいな…

それでは、良いお年を。

関数もオブジェクトである。

こんばんは。有村です。
橘さんに「全然ブログ更新しねーな」と言ったんですけど、それを言ってしまった以上、私が更新しないと「お前もなwww」と返ってきそうなので、書きます。

さて早速ですけど、javascript における関数はオブジェクトなんですって。まあその辺はググれば山ほど出てきますし割愛するとして…

関数の書き方なんですけど、

って記述もできるし、

ってのもできますよね。

私、後者の書き方って何がいいんだろうとずっと謎だったんですけど、ようやく見えてきた気がします。

たとえば、メッセージボックスを開いたり、閉じたりする処理を実装するとします。(toggleで一発やんとかは置いておいて…)
そういうときは今までだと、

って書いていたんですけど。
これだけで終わればいいんですけど、もっと複雑な仕様になると、

とか関数がどんどん増えそうですよね。
どれだけ messageBox にまつわる関数を量産すれば気が済むねんってなりそうです。

そこで、冒頭の話題に戻りますが、関数はオブジェクトなんです。
オブジェクト…オブジェクト……。まずは、もしこの messageBox にまつわる仕様を、オブジェクトっぽく書いたらどうなるでしょうか?

おお、先程の messageBoxなんちゃらの羅列より、なんだかすっきりした気がします!
ただこれだともちろん動かないので、javascriptっぽく書くと…

メッセージボックスを開きたければ、

おおおおー、なんだか分かりやすくなりました!

ひとつひとつ関数を書くやり方だと、頑張って関数名に規則性を持たせても「どこからどこまでが messageBox の仕様…?」と見にくいですし、見にくいが故に「他の案件でもこのソース使おう♪」ってなったときに使い回ししにくいなと思います。
オブジェクトとして書くと、「機能のまとまり」として捉えられるので、使う人にとっても優しいコードになるのではないでしょうか?

今まではメリットが分からなくて、実際にこの書き方したことはないんですけど…
ある日仕事してる夢を見て、その夢の中で上記みたいなソース書きながら「あー!分かった!こういうことかー!」って言っていたので、備忘録も兼ねて記事にしました。
にしても、夢の中でアハ体験するって、職業病というよりなんか病んでる気がする。

それでは、今日はこのへんで。

ファサードについて考える(超初級編)

こんばんは。有村です。
年末が近づくにつれ忙しくなる、これITあるある。

さて今日は、デザインパターンのファサードについて有村なりに考えてみました。

Q:ファサードの例をあげてみて!
A:jQueryのメソッドを思い出すよろし

ファサードは玄関…つまり窓口…という表現は色々な記事で見かけましたが、いまいちピンときませんでした。
また、複雑な処理を隠蔽する…という役割もあるそうですが、これも言葉で言われても理解できません…。

そんな中、一番「あー」ってなったのは、「jQueryのメソッドはファサード」という表現です。

たとえばjQueryのメソッドを使うとき、IE8だとこの書き方…IE9からだとこっち…とか考えないですよね。生のjavascriptだと、IE8はaddEventlistenerが使えないなど考慮しなければならないのですが。
では、jQueryではそれらを考えなくてもメソッドひとつでいい感じになるのはなぜか?
答えは、jQueryのメソッドの中で、ブラウザに応じた分岐処理をやってくれているからです。

また、ブラウザの分岐にとどまらず、生のJSで書いたら相当に長くなる処理であっても、私たちはその先にある処理を意識することなく「メソッドを呼び出しさえすれば」実現することができます。
つまりこんな感じで、中で何やってるのかは分からないけど、この窓口を叩けば後はいい感じにやってくれる、というのがファサードの考え方の掴みなのかな?と思っています。

窓口と処理する人、という考え方は実生活にも則しているな〜と思うと、 処理する人 → 専門職 → つまりそいつらは1つの役割しか持たない → 関数の細分化と抽象化 にも発想が発展するような気がしますね!

それでは、今日はこのへんで。

schema.orgと初めての遭遇

こんばんは。有村です。
もう1ヶ月くらい風邪をひいている気がするのですが、これもう風邪じゃないですよね?

さて今日は、「構造化マークアップ」とか「schema.org」とか、「聞いたことはある…だがよく分からねえ用語」と対峙したので、ゆるくまとめてみます。

Q:schema.orgってなんなのさ?
A:検索エンジンに正確なページの情報を伝えるための記法。

このコードだけ見たとき、「h1だから、ほげほげはそれなりに大きな見出しなんだろな…」と分かりますが、具体的にそれが何かは分からない。
その下に「100円」と書かれた要素がいるので、ああーこれは商品名なのかな?と予想がつくかも知れませんが、はっきり明示されてはいませんよね。
おそらく、商品名なのかな?どうかな?という疑問は、検索エンジンにとってもそうなのでしょう。
例の如く色々端折りますが、

とした場合、「商品について述べるでー」「ほげほげが商品名やでー」「100円が商品価格やでー」と明示したことになります。これなら検索エンジンにも分かりやすいですね!

Q:で、なにがメリットなんですか?
A:検索結果が最適化されるよ
検索結果が最適化…?日本語でおk…ですが、ブラウザで何かを検索した結果でレビューの☆が出てきたり、サイト名の下にサイト内検索ができる検索窓が出てきたり…というのは、誰しも一度は見たことがあると思います。それが検索結果の最適化だそうです。
このラーメンおいしいかな?どうかな?と店舗名で検索したときに、ラーメンの画像が出てきたり、評価が★★★★☆だったりすると、「おお〜行ってみようかな!」ってなりますよね。逆も然り。
この場合、ラーメンの店舗名で検索するユーザが求めるのは「ラーメンの評価はどうか」「見た目はおいしそうか」などだと思うので、検索結果が最適化されている、というのはなるほど納得です。

Q:ってことは、ちゃんとやれば検索結果表示順もグイグイ上がるってことですね!
A:検索結果表示順には直接影響ないらしい(悲報)
SEOと同じで、ちゃんと書けば表示順に反映されるものなのかと思ってましたが、どうやらそれは違うらしい。
あくまで検索結果の最適化であって、schema.orgを適切に使ったからといって表示順には直接影響はないとのこと。
ただ、
検索結果が分かりやすい → ページのアクセスが増える → 優良サイトとして検索エンジンが認識、表示順アップ
というのはありそう。というか、絶対あると思います。

schema.orgとの遭遇で、分かってきたのはそんな感じです。
本気でやろうと思ったらかなり奥が深くて、今日はさわりだけでしたが…「良いWEBコンテンツ」を作成する上では避けて通れなそうですね!仲良くするぞ!

それでは、今日はこのへんで。