Haskellで人間性を下げる

Haskellを試してみる

以前よりTLで狂気の沙汰との印象を受けるHaskellを試してみるの巻

まずはコンパイラをダウンロード&インストール

GHC
http://www.haskell.org/ghc/download_ghc_7_4_2#windows

現状の最新はGHC 7.4.2ですな.
ちなみにGHC(Glasgow Haskell Compiler)というのは読んで字の如くHaskellのコンパイラの名前ですかな.
私の環境はWindows 7なので,『Windows 2000 or later (x86) (standalone)』と書かれているところからダウンロード.

インストールが完了するとWindowsメニューに『GHCi』というのが追加されます.

起動すると以下のコマンドプロンプトのような黒画面が現れます.
(実際はインタプリタらしい(勉強しながらブログ更新しているのでまだ良く分からないというのが実情))

少し関数型言語を堪能してきます(―人―)

Responsive Web Designについて

前提用語の説明

プログレッシブ・エンハンスメント

よりよい環境を持っている人にはリッチな演出を.
あまり良くない環境の人には最低限の演出.
ただし,どちらの場合にも提供する情報は減らさない

→要するにIEユーザーには最低限の演出.テキストなどの情報は見られるように配慮するということ
(IEユーザーは地獄の業火で焼きつくされるべきである)

コンディショナル・コメント

htmlタグにIEブラウザによってクラスを振り分けるアレ.

これですな.

メディアクエリとプログレッシブ・エンハンスメント

もう詳しくは下記サイト様にまとめられているのでそちらを参考にしつつ自分用に加筆

Respond.jsとレスポンシブWebデザインをめぐるベストプラクティス議論
http://tokkono.cute.coocan.jp/blog/slow/index.php/web-technology/best-practice-of-responsive-design/

『・最初にメディアクエリなしで狭いビューポート用スタイルを定義
・次にメディアクエリで他のデバイス用スタイルを定義
・最後に IE6-8 用スタイルをコンディショナル・コメントで定義』

スタイル定義としてはこの順番で行なうのがベターなんですかな.
また,IE6-8に関しては

『古いブラウザがサポートできない機能を何らかの手段で補う、いわゆる ポリーフィル として一旦は H5BP に採用されました が、プログレッシブ・エンハンスメント の考え方から言っても、古いブラウザにそこまでのハンディキャップを負わせる価値はない、がコミュニティーの決定となったのです。』

ということで,無理してレスポンシブ対応しなくても良いのではないかという考え方が提案されているようですね.
上記をまとめると,
『通常のメディアクエリ(Respond.jsは使わない) + プログレッシブ・エンハンスメント』が現状での解
ということになるのでしょうか.

個人的懸念点

メディアクエリを使って,モバイルファーストに実装した場合にも,ワイドスクリーン用のスタイルがリクエストされてしまう

メディアクエリを使った場合,internalに記述した場合でも,importを使って記述した場合にも,各CSSがダウンロードされてしまう.
特にモバイル端末のように回線速度が期待できない場合,何回もリクエストを生じさせる設計はあまりヨロシクないのでは.
(まあ画像とは違って高々数kbのテキストなのですがね…(というかメディアクエリを使う以上,今回のデザインに関わらずこの問題は生じるわけですが))

その他懸念点

この内容は今回の記事の内容とは直接関係ないのですが,レスポンシブサイトを作る上で気になるところを…

1. メディアクエリのブレークポイントどうすんねん

モバイルファーストとは言っていますが,ウィンドウサイズ何ピクセルまでをモバイルと判断するかですね.
特にportraitモードとlandscapeモードがあるので,もはやカオス.
横幅1280pxのタブレットとかどうやって判断すんねんという話でして…

(userAgantなんか使っても本末転倒ですしね…)

2. 画像の問題

モバイルファーストにした場合,画像も小さいものを用意(または縮小表示するか)するとは思うのですが,それをどう切り替えますねんという話ですな.

・imgタグの切り替え
imgタグでhtml内に配置しておいて,cssのdisplayで切り替えるなどがあるとは思いますが,その場合,両方の画像がリクエストされるのでモバイルには優しくない.

・cssのbackgroundの切り替え
cssのbackgroundで指定して,メディアクエリで画像そのものを切替えるという方法もあるとは思います.cssのbackgroundに指定される画像は,css自体はリクエストされますが,背景画像はリクエストされないので,リクエストの問題はクリアされるかと.
ただし,width:100%のような指定ができないので,ウィンドウサイズに対して可変な画像配置というのが難しいのではないかと

・Javascriptを使って動的に切り替え
ウィンドウサイズを逐次把握して,動的に切り替える・・・リクエストも最低限で済みますし,imgタグそのものをJSで切り替えれば,width:100%も対応できるが,これも本末転倒感が否めない…

(レスポンシブにまつわるマニアックなお話でしたm(_ _)m)

JavaScriptのカプセル化

JavaScriptのカプセル化について

日頃はWebサイトの制作というバイトなんぞをしているわけではありますが、いい加減スパゲティコードから卒業しなければなあと思い立ち、カプセル化について勉強するわけでありました。

カプセル化のメリットとしては、外部からアクセスできなくなる(隠蔽)というのが一番あると思うんですよね。うんうん。
ここでいう『外部』というのは悪意を持ったアクセスというわけではなくて、例えば他の関数で変数の値の上書きができないようにするというニュアンスですな。

大体発見し辛いバグというと、知らずのうちに変数の値が書き変わっていて、というものでして。
それを未然に防ぐ、という意味合いでも、不用意に外からアクセスできないように隠蔽化しておくのが吉というわけですな。

全部Public

JavaScriptの特長として、変数や関数は基本的に全部Publicです。つまりどこからでもアクセスができてしまいます。
JavaScriptを始めた当初は「なんて便利だ」と思った機能ですが…

で試行錯誤の結果以下のような書き方が「とりあえず」は良さそう。

所感

privateもどきの機能を達成することはできましたが、いくつかの難点もあるようで
・いちいち「private」と打つのがめんd(ry
・メモリ消費が激しい?(prototype使わないから?よう分からん)(そんなに大量にオブジェクトを生成するわけでもないので無視してます汗)
まあこの辺が「とりあえず」という謂れですかなあ
参考サイト[2]には『privateは諦めましょう』なんて言われていますしなあ

参考サイト

[1] JavaScriptとprivateの見果てぬ夢 (JavaScript Advent Calendar 2011 オレ標準コース 6日目) – 泥のように
http://blog.tojiru.net/article/238901975.html

[2] newを封印して、JavaScriptでオブジェクト指向する(1) – 泥のように
http://blog.tojiru.net/article/199670885.html

[3] Javascriptでカプセル化を実現する! – 日本野望の会
http://yabooo.org/archives/53