ぽんぽこ開発日記

主にHTML, CSS, JavaScriptなどフロントエンドの話を。目指せ脱初心者。

Twitterアカウント運用のあれやこれや仮説

Twitterアカウントを使ってサービスの拡大を図る施策を担当することになったので、仮説を立てて整理していくことにする。

# 運用における重要な数値

  • フォロワーの数
  • ツイート数

# フォロワーを増やすには??

  • フォロー返しを狙う
  • 面白いツイートをしていく

# 世を利用する

  • バズっている流れを利用する
  • 関連雑誌やメディア特集に関して把握しておく(時期がきたらそれに乗ってツイート)
  • ツイートする時間帯をコントロールする


# ターゲットの行動に沿ってアカウントを運用していく

いまさら聞けないHTTP通信の基礎

春休みなので、基本的なものをもう一度おさらいしておこうと思いまして、HTTP通信について勉強しております。ただ、未だ分かっていないことが多い上にTCP/IPの詳しい知識なんて皆無状態で恐縮です。

というわけで、HTTP通信の基本となる部分のみさらっと復習してみることから始めました。

HTTP通信の仕組み

HTTP通信とはブラウザとWebサーバー間で行なう通信のことを指します。ブラウザからWebサーバーに向けてTCPというプロトコルを使って接続を行い、接続が成功したらブラウザは「こういう情報くださいな☆」というリクエストを発行します。Webサーバー側は発行されたリクエストを受け取り、サーバー側で検索を行い、要求された情報をかき集めてレスポンスとしてブラウザ側に情報を渡してあげる、ということをします。

プロトコルってなんぞや

自分もまだよくわかっていない部分が多いのですが、読んでいるJavaScriptの解説を読むと

プロトコル(Protocol)とは、ネットワーク上で通信を行なう上での手順や規約をまとめたものになります。

とあります。個人的には勝手に「通信する上での儀式・マナーっぽいやつね」と解釈して理解しております。


なのでステップにしてみると

  1. ブラウザからWebサーバーへTCP(マナーに従った)接続を行なう
  2. 接続が成功したら、ブラウザは●●●な情報がほしい、とリクエストを発行する
  3. サーバー側はリクエスト通りに情報をかき集めてブラウザに送る


HTTPリクエストの中身

HTTP通信でブラウザからWebサーバーに送るリクエストの中身はこうなっているようです。

  1. HTTPリクエスト行
  2. HTTPヘッダ
  3. 空行
  4. メッセージボディ
HTTPリクエスト行

最初にリクエスト行というものがきます。ここにはメソッド・URL・プロトコルが記載されております。メソッドとはGET / POSTといった情報を取得するのか送信するのかといった手段を意味します。URLはアクセスしたいURLを明示し、サーバー側はこのURLに従って情報を集めることとなります。プロトコルとはHTTP 1.1のように現在の通信バージョンを記載しております。

HTTPヘッダ

文字コードであったり、UA(ユーザーエージェント)で合ったり、その他もろもろの細かい情報が記載されております。JavaScriptを使ってこれら情報を操作し、分岐条件に使ったり、加工して最適化を図ったりすることがままあります。

メッセージボディ

POSTした時に使用される部分。送りたい情報をのっけるとこ。



HTTPレスポンス

レスポンスの中身はこうなっているようです。

  1. HTTPステータス行
  2. HTTPヘッダ
  3. 空行
  4. メッセージボディ
HTTPステータス行

プロトコルステータスコードが表示されている。(200とか403とか)

HTTPヘッダ

ブラウザに送った(HTMLであったりpngなどの)データの形式や、Webサーバーの種類など載っている。

メッセージボディ

HTMLファイルなど、データの本体が載っている。これをブラウザは読み取り表示しているわけっぽい。

要するに...

ブラウザとWebサーバー間で行なうHTTP通信ってのはTCPというマナーに従って情報のやりとりをする作業のことですよと。接続が成功したらブラウザさんはリクエストを送るし、サーバー側はそのリクエストに従って情報を提供しますよと。リクエストとレスポンスの中身はざっくりとこんな感じ(上記参照)ですよと。


今後とも

についても理解を深めていきたい

かんたんJavaScript (プログラミングの教科書)

かんたんJavaScript (プログラミングの教科書)

IE対応をどのバージョンまでするべきか

フロントエンド開発をする以上、最小の労力で価値のある部分から着実に実装を進めていきたいところです。今回はブラウザ対応について。

作るウェブサイトによってどこまでIEのバージョンを気にするか、いろいろと判断基準はあるかと思いますが、ひとまずのところ、ぼくはこうやっている、という点でまとめてみようと思います。

2014年の各ブラウザの利用率

マイナビの調査データによるとIE8さん現役だそうです...
f:id:noriven:20140830032353j:plain
⬆️使われているブラウザのシェア率(棒グラフ)


f:id:noriven:20140830032359j:plain
⬆️使われているブラウザのシェア率(円グラフ)


f:id:noriven:20140830032407j:plain
⬆️ブラウザのバージョンでさらに小分けした円グラフ


出典:IE8が4年間連続トップ - 2月ブラウザシェア | マイナビニュース

まずはIE8対応を基準にして実装

どのジャンルのウェブサイトを作るにせよ、IE8対応までは行なうことを前提としてまずはウェブ制作の話を勧めることが多いです。というのも理由がありまして、マイナビによる調査でわかったことなのですが、已然としてIE8をお使いになられているユーザーがギャン抜きで多いからです。YoutubeGoogleもIE8を切り捨てる動きになってはいますが、もう少しばかりIE8対応は続けたいと思っております。

サービス・ウェブサイトの運営をしつつ、アクセスユーザーのブラウザ情報を参考にIE7対応をするか判断

IE7対応についていろいろと物議をかもしているのを時々目にしますが、ぼくはアナリティクスなどの統計情報からさらにIE7まで対応するべきか判断をしています。もちろん発注側とも共有済みで理解の上で進めております。なぜこのように2段階でブラウザ対応を考えているかといいますと、「できるだけ早く価値検証を行ないたいため、95%(IE6,7以外のブラウザを使っているユーザー層)のユーザーが出来るだけ早くウェブサービス・ウェブサイトに触れる機会を作ること」を大事にしているからです。リリース後、その上でIE7ユーザーが多く、見逃すことができないのであれば着手する、という構えで作業をしております。ちなみに余談ではありますが、ぼくの制作の数が少ないってのもあるかと思いますが、未だにIE7対応を迫られたケースはありません!笑


Similar Webとかで競合サイトのブラウザ統計情報とかまでみれるのであれば事前にどこまで対応するべきか判断する材料になりとても助かるのですが、いかんせんそこまで開示されていないのでやはり、今のところは2段構えでフロントエンド開発せざるをえない、そんな感じで2014年も残すところ4ヶ月です。

がんばります。

文系にも分かりやすいJavaScriptの高階関数の基本と使い方

高階関数とは何か?今までよくわからなったので改めて勉強してみた。

高階関数とは

・引数や返り値に他の関数をセットした関数
というものらしいです。とかいっても全然わからなかったので自分なりに解釈して飲み込んでみた。

高階関数は上司と部下の関係に似てると思った。

ある新規事業開拓の調査を行なう部署が存在していたとする。
部長は佐藤さん。佐藤さんには山田と後藤という2人の部下がいる。

ある日、社長からその部署へ「ホテルを立てようと思っているので採算性があるのかどうか調べてくれ。」と頼まれた。

部長である佐藤さんは「かしこまりました。調べてみます。」と返事をした。
さて、これから佐藤さんは何をするべきか考えてみた。
まず

プロセスはこうだ。

  1. 佐藤さんは社長からデータをもらう
  2. 山田と後藤に初期投資費用と収益を調査してもらう
  3. 佐藤さんは山田と後藤が調査して出してくれた結果をみていけるかどうか判断する
  4. 結果を社長に報告する

ここまでをソースコードに落としてみる

var satou = function(location, buildingCost, manageCost, yamada, gotou){
     // location = 立地
     // cost = 建物、設備を用意するための費用
     // manageCost = 運用するための人件費
     var a= yamada(location, buildingCost, manageCost);
     var b= gotou(location);
     
     var conclution = b - a;
     if(conclution > 0){
          var answer = console.log(‘この事業をするべきだ’);
     } else{
          var answer = console.log(‘この事業をするべきでない’);
     };
     return answer;
}; 

var preInvest = function(){
     // 初期投資にかかる費用を計算するロジックが書かれる
};


var income= function(){
     // 見込める収益を計算するロジックが書かれる
}; 

//実行
satou(‘熱海’, 10000, 500, preInvest, income);
 



いろいろと事業内容の精度にはツッコミがあるかもしれないが、この部署ではざっくりとこんなことをする。
このとき、佐藤さん、山田、後藤それぞれが目的を持った関数になっていることに注目していただきたい。

佐藤さんはまず社長から立てる場所(location)と施設建設の費用(buildingCost)、運用コスト(manageCost)のデータを受け取る。それを山田と後藤にそれぞれ渡し、集計を取ってもらう。つまり山田と後藤の目的はコストと収益の集計をとることだ。
そして山田と後藤から返ってきた集計データを合わせ、佐藤はこの事業をするべきか否かを判断し、社長に報告する。これが佐藤のやること・目的にあたる。

つまり部署のメンバーをまとめ、そのメンバーに役割を振っていくのが佐藤さんという高い階級に位置する人(関数)で、その下に役割ごとの調査をしてくれる部下(関数)がいる。これがいわゆる高階関数なのか、と解釈した。

以上のことから高階関数の特徴をより具体的に書くと目的を達成するための機能を分解し、それぞれ別の関数にわけることでカスタマイズ・メンテナンス性を向上させることができるなーと思った。

レスポンシブサイト制作のベストプラクティスを求めて

ウェブサイトをスマホ対応にする際、いくつかの方法があります。制作サイドとしては、一体どの方法がベストプラクティスなのか検討するべきだと思う訳なのですが、僕の中でそれが曖昧だったので考えてみました。

今回比較するのはよく使われている方法である
CSSのメディアクエリー(Media Queries)を使う方法
②サーバーサイド側でユーザーエージェントを使って分岐する方法
③htaccessを使って分岐する方法

の3つの方法になります。

とりあえず一覧表を作ってみた。

Media Queries ユーザーエージェント(サーバーサイド) htaccess
分岐点の柔軟性
自分の指定したwidthにいくつでもbreak-pointを設定できる

ブラウザ・OS単位で分岐できる。Media Queriesより詳細にはできない

基本はユーザーエージェントを利用するため、ブラウザ・OS単位で分岐できる
範囲 CSS すべてのファイルに適応可能(サーバーサイドで処理した場合) フォルダベース(すべてのファイルに適応)
読み込むファイル CSSの重複が生じがち ファイルの重複を極力さけることができる 同じコンテンツを持ったHTMLをウェブ上に複数認識させてしまうためSEO上よろしくない
感想・結論 静的サイト、小規模サイトならこれでいいかも ファイルの重複をさける、JSの管理も行えるため、ウェブサービスのように中大規模サイトではこのやり方がベターだと思う ユーザーエージェントを使ったやり方と同等のことができるが同様のHTMLファイルを複数管理しないといけないためウェブサービス構築には向いてないかも。そしてSEO上よくないので極力使いたくない方法かも
ひとつひとつみていく。

①Media Queries

Media Queriesは自分の好きなように横幅を設定し分岐することができる。しかもいくつもその分岐点を設定することができるため非常に便利です(もちろんその分管理の手間は増えます)。ただ、分岐の範囲がCSSの中だけの話なので同時にJSのレスポンシブ化などを行ないたいときには向いていません。最後に読み込むファイルが重複してしまう点が一番のデメリットだということ。importを使って読み込むファイルを指定するのですが、スマホ用だろうがタブレット用だろうがPC用だろうが、事前にすべて読み込んだ上で、使うCSSを選ぶ、という処理になりますので、PCで閲覧していてもスマホCSSを読み込む必要が出てきます。大規模なウェブサービスなどを運用していると無駄な処理をしていることになるのであまり無視できることではありません。

②サーバーサイドで行なうユーザーエージェントでの処理

分岐点がブラウザ・OSごとでの指定になり、Media Queriesでの分岐の柔軟性に比べるとやや劣りますが、特徴的なのはサーバーサイドで分岐軸を設定できる点です。サーバーサイドで分基軸を作ればCSSの分岐も可能ですし、JSのレスポンシブ化にも対応できます。やろうと思えばHTMLだってできるので管理がしやすくなります。また分岐ロジックが出力されるソースコード上に出てこないのでセキュリティ上もMedia Queriesと比べたらいいのかも。MediaQueriesと違って、CSSもJSも無駄なファイルを読み込むことがなくなるため、無駄な処理をせずに済む点が良いですね。大規模サイトや複数のJSをスマホ対応したいサイトを作る場合はこの方法がベストかも。

③htaccessを使って分岐する方法

使っているのはユーザーエージェントなので②と同じやんけ!ってなるかもしれません。ただこの方法ではフォルダ単位で読み込むファイルを変更する、という処理になるので同じコンテンツを持ったHTML(スマホ用、PC用のHTMLファイル)、それぞれのデバイスに対応したCSSファイルを作らなければなりません。なので管理コストが高く、かつ同じコンテンツを持ったHTMLを複数ウェブに認識させてしまうのであまりよろしくありません。スマホ用HTMLをnoindexに設定するのも一手間ですし、あまり最適なやり方ではないのかなーと思われ。

結論:

個人的には小規模・静的サイトを作るのであればMediaQueriesを使った分岐のほうが早く済み、弊害が小さく済むのでそのやり方がいいかなと思いました。
一方で大規模サイトを作る際は分岐の処理をサーバーサイドに任せて、CSS・JS・HTMLのバランスのとれた分岐をするべきだなと思いました。

ってことで今、大規模サイトでMedia Queries使っちゃっているのでどっかのタイミングでユーザーエージェントを使った方法に切り替えないとなぁと思った(汗)