RubyでYoutube Data APIの認証、動画検索、取得、更新

APIを使う準備

まずはデベロッパーキーを取得しておきます。名前と使用するサイトのアドレスを指定すると、キーが発行されます。

認証

Youtube Data APIでの認証は主に3種類あります。

  1. AuthSub
  2. OAuth
  3. ClientLogin

今回は3.のClientLoginを使います。クライアントマシンから実行するバッチスクリプトとしてコードを書いていたので、Youtubeコンテンツの所有アカウントに紐付けるClientLoginが最適です。

APIにPOSTを送信して、認証トークンを取得します。

require 'net/http'
require 'uri'
uri = URI.parse('https://www.google.com/youtube/accounts/ClientLogin')
https = Net::HTTP.new(uri.host, uri.port)
https.use_ssl = true
header = {'Content-Type'=>'application/x-www-form-urlencoded'}
body = "Email=#{email}&Passwd=#{password}&service=youtube&source=#{client_name}"
res = https.post(uri.path, body, header)
token = res.body.split('YouTubeUser=').first.gsub(/^Auth=/, '')

ClientLoginの場合、レスポンスのボディにAuth=xxxYouTubeUser=user_nameというフォーマットでトークンとユーザ名が入ってきます。上記のコードはuglyですがトークンを最後の所で抽出しています。putsで表示した内容をコピーして使用しても良いですが、認証トークンには期限があるので、最新のトークンを取得して以降に使用する方が良いと思います。

sourceの所はアクセス元の名前なので、適当で大丈夫なようです。

動画検索

APIにGETを送信し、特定のユーザがアップロードした動画から、検索キーワードを指定して検索します。

require 'net/http'
require 'uri'
require 'rss'

search_uri = URI.parse('http://gdata.youtube.com/feeds/api/videos')
header = {
    'Authorization'=>"GoogleLogin auth=#{token}", 
    'X-GData-Key'=>"key=#{developer_key}"
}
search_http = Net::HTTP.new(search_uri.host, search_uri.port)
res = search_http.get(search_uri.path + "?v=2&author=#{user_name}&start-index=1&max-results=20&lr=ja&q=#{query}")
rss = RSS::Parser.parse(res.body)

rss.entries.each do |entry|
    puts entry.title.content
end

まずリクエストのヘッダに認証キーとデベロッパーキーを指定します。スペースなどが入る点に注意が必要です。次にリクエストのボディにパラメータを指定します。

  • author => 動画の投稿ユーザを指定できます
  • start-index => 検索結果の開始位置
  • max-result => 検索結果1ページあたりの件数
  • lr => 言語
  • q => 検索キーワード

検索が正常に実行されると、レスポンスのボディにAtom形式でXMLが入ってきます。今回は、これをパースして使うようにしています。XMLの内容については、こちらを参考に。

動画単体の取得

APIにGETを送信し、動画IDを指定して取得します。

require 'net/http'
require 'uri'
require 'rss'

single_uri = URI.parse("http://gdata.youtube.com/feeds/api/users/#{user_name}/uploads/#{movie_id}")
header = {
    'Authorization'=>"GoogleLogin auth=#{token}", 
    'X-GData-Key'=>"key=#{developer_key}"
}
single_http = Net::HTTP.new(single_uri.host, single_uri.port)
res = single_http.get(single_uri.path + "?v=2&author=#{user_name}&start-index=1&max-results=1&lr=ja&q=#{query}")
single = RSS::Parser.parse(res.body)

puts single.title.content

URIにユーザ名と動画IDを指定します。注意はXMLをパースしたときに、ルートノードがentryになる点です。

エントリーの更新

APIにPUTを送信し、動画に関する説明やカテゴリ、タグなどを更新します。

require 'net/http'
require 'uri'

upload_uri = URI.parse("http://gdata.youtube.com/feeds/api/users/#{user_name}/uploads/#{movie_id}")
upload_http = Net::HTTP.new(upload_uri.host, upload_uri.port)
upload_header = {
    'Authorization'=>"GoogleLogin auth=#{token}", 
    'X-GData-Key'=>"key=#{developer_key}",
    'Content-Type'=>'application/atom+xml; charset=UTF-8'
}

xml <<-EOS


  
    #{title}
    #{description}
    #{category}
    #{keywords}
  

EOS

res = upload_http.put(upload_uri.path, xml, upload_header)

XML内で値を指定する場合に注意することがあります。

GithubでもRubyベースのGoogle Data API向けのモジュールは多数あるので、そちらを利用しても手軽に利用できると思います。

by 古川 勝也 （コガワ・マサヤ）

HTTPでXMLを送信したら、The Processing Instruction Target Matching "[xX][mM][lL]" is Not Allowed

The Processing Instruction Target Matching "[xX][mM][lL]" is Not Allowed

Youtube Data APIで動画の更新をしようとXMLをPUTで送信しようとしたら上記のエラー。ステータスは400でBad request扱い。色々探したら、原因が分かりました。
どうやら、XMLの前に余計な文字列が送信されているためのエラーらしい。

Rubyの便利ヒアドキュメントが裏目に

Rubyでのヒアドキュメントで便利なのは、以下のようにインデントできるタイプ。

def xxx
  s = <<-EOS
    
    ...
  EOS
end

ただ、ここでヒアドキュメントで生成した文字列を確認してみると、XMLの前にきっちりインデント文字が生成されてました。

\t\t

これのせいですね。というわけで以下のように変更して事なきを得ました。イージーなミスを・・・

def xxx
  s = <<-EOS

...
  EOS
end

コードが「うーん」という状態になりますが、いたしかたありません。

by 古川 勝也 （コガワ・マサヤ）

CSS Nite LP, Disk 25：Webデザイン行く年来る年（Shift6）参加レポート

CSS Niteにおいて1年の総決算であるShift。一度、参加してみたかったイベントのひとつです。全部で9セッション、6時間以上にもおよぶ長丁場ですが、WEB制作のフロントエンド動向をおさらいするにはうってつけの内容でした。

私の場合は、実装的な話は手を動かせばいいでしょ、と思っているタイプ(エンジニア脳)なので、どちらかというと考え方や捉え方といった、問題解決の糸口になる抽象化されたトピックが刺さります。自分にとっては基調講演が一番考えさせられたので、ポイントをピックアップして復習しようと思います。

未来をプロトタイプしよう

長谷川恭久さんによる基調講演は毎年の恒例だそうです。プロトタイピングはソフトウェア開発の世界では昔からある手法ですが、WEBはスピードがとにかく速いこともあり、モノを世に出すスピードも加速する一方です。プロトタイプの段階で早期に問題を発見したり仕様を詰めるという従来の使い方だけでなく、自動化ツールと組み合わせて、製品化へのプロセスを一気に短縮できる環境も整いつつあります。

これはやはりWEBサービスの一般化だけでなく、ソフトウェアは成長するものであるという認識も浸透しつつあるからだと思います。スマートフォンの浸透は特にそれをコンシューマに根付かせています。iPhoneアプリのレビューは荒れ放題ですが、早くアップデートしてくれという言葉が日常的になっていることからも時代の変化が伺えます。

Reimagination = 再想像、再定義

自分の言葉では前提を疑うと解釈しています。既存、標準といったものはよく習うべきお手本であると同時に、創造を妨げるステレオタイプとしてのリスクを持っています。0から1を生み出すプロセスにおいて、このReimaginationという考え方は共感します。
Appleのイノベーションとは、未来にある普通のものと言われています。未来を想像する、ひとつの視点、指針となる考え方であると言えます。

プロトタイピングは試行錯誤のオープン化

プロトタイピングはコミュニケーションを円滑にする手段の1つです。コミュニケーションの対象は、製作者だけでなく発注者や事業者も含まれます。
デザイントレンドを担当した坂本邦夫さんの別セミナーで、ドキュメント作成のポイントに不採用にした理由を書くというのがありました。試行錯誤の過程を見せることで、コミュニケーションの踏み台を作るのです。SNSが普段の小さな対話を保管することで、久しぶりの対面でも本題から話せるという例が近いでしょう。

なぜ、つくるのか？なぜ、使うのか？

5W1Hといいますが、その中でも重要なのはWhyとよく言われます。なぜ？と問い続けることで、問題解決の糸口が見えるという手法は定石です。What、何をつくるのか？にフォーカスされがちですが、まずはなぜ？だと私も思います。根拠や背景が明確になると、実現できるかの判断がつき、ゴールが見えてきます。そこで初めて思考を次のフェーズに持っていけます。

そして、プロトタイピングをしている最中も必ず、なぜ？と何度も振り返ることが重要です。なぜなら、実物で見えるというのは思考を広げる反面、ぶれる、欲が出る温床ともなります。なぜ？という問いかけは行動指針であり、デザイン原則ともなります。

別のセミナーで長谷川さんにプロトタイピングは、どこで線引をすれば良いのか？という質問をしたことがあります。その時はデザイン原則をプロジェクトで設けたりといった、いくつかの回答をいただきました。

「アジャイル　プロトタイピング」と検索すれば、山のように先人の体験談が見つかります。

なぜ、プロトタイピングなのか？

デザインという行為をReimaginationするきっかけになるからだと思います。プロトタイピングをどうやって、どこまでやるか、という話も本当はあります。インクリメンタルという作っては確認する方式もあれば、紙の上でシミュレーションしきってからモノを作るという方式もあります。

私は両者の経験がありますし、他の手法もあるでしょう。必ず一長一短があります。案件の性質やプロジェクトメンバーによって正着が異なる、というのが現在の見解です。私の場合、受託案件についてはウォーターフローとスパイラルフローの組み合わせで対応しています。加えて、プロジェクトのバランスという視点も必要だと、私は考えています。

プロトタイピングはコミュニケーションの一種であり、本質を捉えるための手法です。作業ではなく、デザインやクリエイションに集中できて、はじめてプロトタイピングの価値を感じることができると思います。

by 古川 勝也 （コガワ・マサヤ）

Sublime Text 2 + MAMP + Xdebug でPHPデバッグをする方法

MAMPのphp.iniに設定を追加する

MAMPを使用している場合、私はPROなのでファイルメニュー -> テンプレートを編集 から編集できますが、PROでない場合はphp.iniを直接開いての編集となります。各phpバージョンごとに設定が必要なので、利用環境に合わせて設定を追加していきます。例えば以下。zend_extensionの部分はコメントアウトされているだけなので、行頭のセミコロンを削除でOKです。

[xdebug]
zend_extension=“/Applications/MAMP/bin/php/php5.3.14/lib/php/extensions/no-debug-non-zts–20090626/xdebug.so”
xdebug.remote_enable=On
xdebug.remote_host=“localhost”
xdebug.remote_port=9000
xdebug.remote_handler=“dbgp”
xdebug.remote_autostart=Off
xdebug.profiler_enable = On
xdebug.profiler_dir = “/Applications/MAMP/tmp/php5.3.14/xdebug/”
xdebug.collect_vars=on
xdebug.collect_params=4
xdebug.dump_globals=on
xdebug.dump.GET=*
xdebug.dump.POST=*
xdebug.show_local_vars=on

SublimeXdebugを追加する

SublimeXdebugというXdebugクライアントのプラグインがあります。実行すると、ST2上にXdebugによるPHPデバッグメニューとデバッグ状況を表示する分割ウィンドウを表示します。

.sublime-projectファイルに設定を追加する

ST2のプロジェクトとして保存している場合は、以下の様な設定を追加します。例えばWordPressを利用時にwpフォルダを作っている場合は、http://your.web.server/wpと記述します。


{
    "folders":
    [
        {
            "path": "..."
        },
    ],

    "settings": {
        "xdebug": { "url": "http://your.web.server" }
    }
}

ブレークポイントを指定する

ST2上で止めたい処理の行で Shift + F8 を押し、Add/Remove Breakpoint を実行します。すると行番号の左に●が表示されます。デバッグ実行時に該当する行まで処理がくるとストップして、そこの部分で現在の変数はどうなっているか？といった情報を確認できます。

デバッグを開始する

Shift + F8 でクイックメニューが表示されます。Run Debugging
選択するとデバッグを開始できます。
メニューからデバッグを開始すると、http://your.web.server?XDEBUG_SESSION_START=sublime.xdebugというURLで規定ブラウザ上にページが表示されます。URLは先ほどの.sublime-projectで指定した値です。

注意しなければいけないのは、セッションキーとしてURLに XDEBUG_SESSION_START=sublime.xdebug という値が追加されていることです。デバッガにXdebug使ってるよーと通知するための値です。デバッガのメニューから Rub debugging を実行した場合に自動で追加されますが、表示されたページ上でPOSTや別ページへのリンクにジャンプしようとした時は、その値がクリアされるので注意が必要です。
Chromeエクステンション Xdebug helper の設定でもセッションキーを指定するので、使用する場合には忘れずに。

ショートカットで効率良くデバッグ

ごく基本的なステップ実行によるデバッグをショートカットで実行できます。プラグインのページにもありますが、よく使うものとしては以下でしょうか。

  • Ctrl + Shift + F5: 次のブレークポイントまで実行
  • Ctrl + Shift + F6: ステップオーバー(次の行へ)

Xdebugでリモートデバッグとなると、Eclipse PDTやNetbeansを使っている例が多数ですし、見やすさや使いやすさは一歩譲りますが、軽量なSublime Text 2でもできるようになるのは嬉しいですね。

by 古川 勝也 （コガワ・マサヤ）

今年1番ヒットだったツールは GRID-IT for MacBook Air 13inch

今年1番ヒットだったツールは GRID-IT for MacBook Air 13inch

Aomori Web Advent Calendar 2012 初日を担当します。今回のテーマですが、プログラマーなら開発ツールあたりを選ぶのでしょうが、あえて別にしようと思います。ちなみに昨年の1番ヒットだったツールはPogoplugでした。Pogoplug と Mac mini でホームサーバを構築した時の記事も、よろしければご覧ください。

私の今年1番のヒットツールはMacBook Air 13inch用のケース GRID-ITです。元々はケースとしての機能を持たない収納ツールとして登場したものですが、それまで使っていたPCケースのファスナーが壊れて次の候補を探していところ発見。ケースとしての機能を備えた新シリーズとして登場していましたので、ポチり。

無残なるMacBook Air

002

先代のケースはコンパクトで軽かったものの、保護する機能はなく裸もちに近い状態でした。一歩先行く！　ツール活用で制作効率アップ in TOKYOで会場について、さあプレゼンの準備！とMacBook Airを取り出してみると、角がとても残念なことに…どこでぶつけたのかすら分からない始末。

とりあえず守らないとダメだ！

001
GRID-ITでは、収納部分のボードがMacBook Airよりの一回り大きく、硬い素材で折り曲がらないようになっています。そのおかげで、角から落としたとしても衝撃から守ってくれます。使い始めて「あっ！」と思うぶつけ方を何度かしていますが、今の所しっかり仕事してくれています。

コレ1つ持てば大丈夫。

モバイルPCで何気に大変なのがアダプターや変換コネクタといった関連用品の持ち歩きです。

  • 収納豊富なカバンに依存すると入れ替えが大変
  • 小分けのポーチはかさばる
  • なるべく平らに収納できないと膨らんで持ちづらい、ダサい
  • どこに収納したかすぐに分かる

意外と細かい点が気になってしまうものです。カバンは定位置をつくりやすいのですが、ポケットで見えなくなるのが難点です。それと、ちょっとした移動でカバンごと持ち歩きたくもないので、手軽な携帯性というのも重要になってきます。

シンプルな見た目・形、適度な大きさ・重さ

003

GRID-ITは、ぱっと見だと地味ですが、よく言えばTPOを選ばないので、打ち合わせにそのまま持っていても違和感がありません。ちょうどA4ブリースケースぐらいの大きさと適度な厚みですので、本体の重さはそれなりなのですが、小脇に抱えるとフィットして持ちやすい所が良いです。

ゴムの「長さ」と「張り」で使い分け

004

中を開くと縦横無尽にゴムバンドが張り巡らされていて、まさにGRID。向きだけでなく、長さと張りも異なります。ブラックに比べて、グレーは張りがやや弱めですが長さがあります。軽くて面積をとるものの収納に向いています。逆にブラックの中でも、隅にある短いものは張りがきつく、小さい物や重い物もしっかりとホールドしてくれます。

持ち物によって収納の仕方を変えられますし、どこに収納するか考えるのも楽しかったりします。気をつけたいのは、重い物の収納場所。位置が偏っていると、小脇に抱えたときのバランスが悪くなるので、均等な重さになるよう工夫するとベターです。

見わたせる収納

005

GRID-ITはマジックテープになっており、開けると収納アイテム全体を見渡すことができます。これ、大事です。いちいちファスナーを開け閉めしたり、カバンに向かってのぞき込むことなく、テーブルに並べたように俯瞰することができます。定位置を決めておくのも大事なことですが、追加アイテムでいつもと違うレイアウトになったとしても、見わたせるとストレスなく取り出しと収納が可能です。

もともとはバッグインバッグも使ったりしていましたが、俯瞰できる便利さになれると、小分けは便利でも見えないことがストレスになっていくことに気づきました。ひらくPCバッグというバッグがあって、こちらも素晴らしい設計なのですが、バッグの中身を俯瞰できるという点については、GRID-ITのメリットも同様です。

ストレスのちりを積もらせない工夫

収納グッズでそこまでこだわらなくても・・・と言われても仕方ないのですが、最もヘビーに使って持ち歩くPCグッズが最適化されていると、着手コストが下がります。すぐに取りかかれる、片付けられる状態は、先延ばしを防ぐ方法として非常に効果的です。

掃除や後回しにしたい雑務も着手コストを下げる工夫をすると、最大の敵「おっくう」を吹き飛ばして、さっさと片付けられるようになります。そういう観点でツール選びをしてみると、また違った発見があるかもしれません。

Aomori Web Advent Calendar 2012 2日目の担当者は企画の言いだしっぺ、佐々木康幸さんです。

by 古川 勝也 （コガワ・マサヤ）

プログラマ視点で見る、Apple新製品5つ見切り発車レビュー！

この記事は、見切り発車のタイトル通り、実機確認をせずにスペック表のみでのレビューです。発売後、実機確認で意見が変わる可能性もありますが、現時点での検討の参考になれば幸いです。

iPad mini は iPadの代わりとして買ってはいけない

新サイズは何をもたらすか？

結論から言うと、私はiPad miniは買いではないと判断しました。タイトルにあるとおり、iPadの代わりではなく新機軸の使いどころを見いだして買うべきです。
競合製品としてAndroid Nexus 7があります。どちらもタブレットというくくりではありますが、ハードのサイズはそのままユーザ行動の変化に直結するということは、携帯ゲーム機、スマートフォン、タブレットといったモバイルデバイスの利用者は体感しているでしょう。

あのサイズ、ちょっと大きめのポケットなら入ってしまいますし、iPadのディスプレイの内側に収まるコンパクトさは手の小さい日本人にとっては、これがベストサイズだった！と感じる方も出てくると思います。

特にiPad mini横置きでキーボードを操作するときの感覚は、iPad縦置きでのキーボードに近い感覚でしょう。更に横置きのインターフェースを利用できるのは便利だと期待しています。

電子書籍リーダーとしての側面は、やはりPDFを見たときの文字サイズの小ささはiPadで軽減されたストレスがぶりかえす可能性があります。iPad miniの責任ではありませんが、早く実機で確認したいところです。

なぜiPad2と同じCPUを搭載？

スペックでひっかかるのは、搭載CPUがiPad2相当のA5(2世代前)であることです。iPad3ではA5xでRetinaという負荷の大きい機能を実現し、今回のA6x搭載で更に快適な速度を期待できます。
おそらく、iPad miniはRetinaでないとはいえ、筐体が小さく薄くなって発熱問題を想定したものと推察します。

ただ問題は「iPadを凝縮した」というジョナサン・アイブのすばらしい表現のとおり、iPad mini上で動くアプリはiPadアプリそのままという点です。
ハードとソフトはいたちごっこの関係で、iPadの性能が上がるにつれ、アプリもそれを当てにして高負荷になっていきます。コンピュータの処理で最も高負荷なのはグラフィック処理です。

アプリケーションが進化してもハードが劣化、特に処理の要であるCPUとGPUがグレードダウンするのは快適な速度を提供できるかどうか怪しいと考えてしまいます。ここら辺は実機で触るだけでなく、継続的な利用での体感、様々アプリケーションでの動作確認が必要な部分なので、使用レビューを待つことになります。

順当な進化で今買いのiPad4

iPhone5と同じ体験をA6xで

個人的にApple製品は4代目以降が「買い」と思っています。iPad3でRetinaというインパクトが提供されました。今回のスペックアップで、こなれてきたという所でしょうか。iPad3を買ったのに・・・という声が方々から聞こえてきそうです。iPad3をスルーした人は買い時でしょう。

今回搭載されるCPUはA6xということで、iPhone5と世代としては一緒になります。つまり体感レベルで同程度の快適さを得られると可能性が高く、LTE対応とau契約のスタート、この後の展開がとても楽しみです。

MacBook Air Mid 2012のように順当なスペックアップで、まさに買いです。

MacBook Pro は、重いMacBook Air？

やはりのRetina対応・・・いや、そこじゃなくて。

今回の発表で最も残念な結果だった製品です。初代は茨の道、今から次期モデルに期待するしかありません。MacBook ProのRetinaが出たとき、13inchを待つことにした人も多かったと思います。ふたを開けてみれば、スペックはMacBook Air 13inchとほぼ一緒。CPU性能が高く、SSDの容量は768GBまで選べますが、メモリは8GB固定でグラフィックは統合チップセットのみ。

MacBook Proを採用する人は高解像度の写真や動画といった高負荷の作業を必要とされる層です。その場合、メモリの容量とGPUの性能が生命線となります。
USB3、Thunderboltのポート数が多いとはいえ、基本のスペックがこれでは重いMacBook Airと言ってしまいたくもなります。

迷走中のProシリーズ

これまでのProシリーズは、ハイスペックかつ自分でカスタマイズできる余地があるという点と考えていました。Mac Proに対するiMac、MacBook Proに対するMacBook Airといった関係です。ですが、MacBook ProのRetinaモデルからパーツ換装という要素は完全に排除されました。

その分、高い基礎スペック、高解像度と高性能グラフィック処理、豊富なポート数という差別化で、まさにProと言えるもののはずなのですが、13inchに関してだけは残念な結果です。高性能CPUと少し大きめ(Retina非使用時に最大 1680x1050)の解像度は新しいProの定義には一部入りますが、差別化が中途半端なので今後を見守るしかありません。まさか、Retina搭載がProなんてことになりませんよね？

野心的な進化をしたiMac

すさまじい技術に裏打ちされたディスプレイ

デザインのページを見るとわかりますが、製造方法をプッシュする内容はユニボディ以来ではないでしょうか？それだけ、この薄いディスプレイを作り上げたことへの達成感が伺えます。しかも光の反射を削減して、より見やすく・・・というのはThunderboltディスプレイを買ったばかりの自分ですら、羨ましくなってしまいます。ディスプレイ一体型デスクトップとしては、間違いなく最高峰ではないでしょうか。

管理が難しいSSD+HDDへの解答、Fusion Drive

iMacもしくは旧MacBook Proを利用している方は、SSD+HDD(MacBook Proの場合は光学ドライブを自分で換装)で使っている人も割といるかと思います。SSDの高速なI/Oは、利用者にとって世界が変わります。デュアルドライブは自作好きだとすぐに思いつく方法ですが、ディスク2つを管理するというのは意外と手間です。SSDの速さとHDDの懐の広さ、この特長の違いをOSレベルで解決しようというのがFusion Driveです。使用者の操作感覚をまったく損なわないこのアプローチは非常にすばらしいものです。

アプリケーションのような読み取り専用で起動の速さが重要なものはSSDへ、保存を目的としたファイルはHDDへというのが一般的な運用でしょう。しかし、制作中のファイルは大きくてSSDで運用した方が絶対に良いのだけど、管理するフォルダが本来はHDD側だからどうしよう？というケースが起きます。Fusion Driveでは、SSD+HDDというデュアルドライブを1つの空間に見せかけて、どちらに保存するかは裏でOSが使用状況を見て判断するようです。

個人的にFusion DriveはiMacだけでなく、MacBook Proにも搭載されて欲しい手法です。MacBook Airとの絶対的な差別化にもなりますし。

安定性が心配なFusion Drive

新しい試みはトラブルがつきものです。Fusion Driveも良いことばかりではありません。おそらく不具合や頻繁なアップデートが発売当初は予測できます。1台目となる人は仕方ありませんが、乗り換えを検討している方は必ずバックアップを用意して扱わないと危険です。

何しろ重要なデータを管理する部分に新技術を導入するのですから、リスクは高いです。なぜか消えてしまったでは済まされません。

割り切り仕様のMac mini

ホームサーバーとしての地位を確立するか？

通常モデルとサーバモデルというのがMac miniの特徴です。両者はMacBook ProのようにCPUコア数とグラフィック性能の差で分かれていましたが、今回からはどちらも統合チップセットのみとなりました。Intel HD Graphics 4000のスペックの高さを伺えますし、用途からはグラフィック性能はそこまでいらないという判断でしょう。
今回は、CPUのコア数とFusion Driveの搭載が各モデルの違いとなります。通常モデルだとコア数の他、Fusion Driveを搭載するかどうかで変わってくるようです。

対してサーバモデルだとFusion Driveは搭載できませんが、ドライブを2つ搭載できるのでミラーリングにしても良し、サブの容量として割り当てても良しと自由度が高いです。

ホームサーバとして運用する場合の参考記事(環境構築、運用例)もよろしければごらんください。

大容量か？安全性か？

通常モデルですと最大1TBの大容量Fusion Driveが手に入ります。ディスプレイが別の場合にはMac miniはiMacに代わる選択肢となりますし、この大きさは持ち運べるデスクトップという運用も可能です。

サーバモデルでは、ドライブを2つにして片方をTime Machine対象にすれ自動バックアップ機能を搭載したサーバに早変わりです。すぐに使わないけど重要なデータなどは、バックアップ目的ならTime CapsuleよりもMac miniの方が安全に管理できます。

まとめ

Apple製品に限らずですが、やはり新製品や最初のモデルチェンジは鬼門です。新しいもの好きはそこも見込んで楽しみますが、実用性を考えた場合はそうもいきません。特に話題のiPad mini、待望のMacBook Pro 13inchに関して、自分なら次期モデル待ちです。

ですが新しいもの好きとしては、iPad miniは実機で触って何と思うかが今から楽しみです。

by 古川 勝也 （コガワ・マサヤ）

[レポート]一歩先行く！ツール活用で制作効率アップ

抱える課題は立ち位置によって違う

セミナーでは効率化を行う目的、効率化の後のことについては講師の立場によって伝え方が異なっていたと思います。私が扱ったテーマ「バージョン管理」では、「機械化できることはして、人間にしかできない事に集中しよう」という主旨でした。

バージョン管理のデモで反応が良かった部分は、コミット済みの画像と編集後の画像の比較ができるところでした。
フロントエンドの人間にとっての課題は、大量の画像書き出しといったテキストではない成果物の管理。画像もバージョン管理できるというアプローチは当初、キャッチーに理解できる例示として考えましたが、結果的にフロントエンドをメインとする方々が日々抱える問題を解決する例示となっていたようです。役立つ内容を提供できたようで嬉しかったですが、プレゼンテーション制作は要求分析そのものなので、さらに精進しようと思いました。

何のために効率化するのか？効率化の先にあるものは？

私の主旨は「機械化できることはして、人間にしかできない事に集中しよう」でしたが、効率化できて人間本来の仕事に集中できたその先には何があるのでしょうか？

懇親会で話していた時に振り返ることができたのですが、近年のサービスやアプリケーションは「無料」「簡単」といった敷居を下げるキーワードに終始するケースが多いです。これは消費の仕方を示唆するだけで、「それを使ってどうなるの？」「どう組み合わせればいいの？」「自分のケースには当てはまるの？」というような「先」が提示されません。我々、制作者・開発者は生産者です。

点を提供するよりも、何を生産できるようになるのか、どんな利益を得られるようになるのか？すでに駆使して利益を得ている人間はどんな世界を見ているのか？といったモデルケースを提示すること、つまり線を提供することで、試してみよう、挑戦しようというポジティブな行動の引き金になると思います。行動する人が増えれば、続こうとする人も増えます。その連鎖が、デファクトスタンダード化やパラダイムシフトといった動きになるのでしょう。

自分にとっての効率化の先を考える

自分の事例をあげると、適切なフレームワーク採用によって、作業期間は見積もり1ヶ月の内容が2日で実装できるようなケースが出てきました。余剰工期は、インターフェース設計をはじめとした使い勝手のブラッシュアップに適用。

結果、第1版から品質の高いものを提供できたのでクライアントから即OK。差し戻しもなく、互いに気持ちよく次の工程に入ることでポジティブな連鎖が生まれ、以降の内容が進めやすくなったり、信頼の獲得につなげられました。
もっと言えば、作業だけでなく考える時間についてもらえる対価の比率があがっています。自分で納得のいく対価は、メンタル上でも非常に健全で価値の高いものです。

良い例ばかりではありませんし、そこに至るまで、たくさんの失敗や試行錯誤がありました。しかし、効率化によってどんな利益を得られるようになるかの「先」として1つの例でしょう。

目前よりも少し先を意識してみる

車やバイクの教習を受けたことがある人は知っているかもしれませんが、目前より少し先の目標物を見たほうが運転しやすくなります。目前を見ると視野が狭くなり、危険予測などに影響が出るためです。
効率化によって得られた利益をどうするのか？新たに投資するのか、別な用途に転換するのか、それは人によって違うと思います。

大事なのは効率化した先を考えて、制作環境の見直し・ツール導入を検討することだと思います。効率化の前には、必ず試行錯誤のコストが発生するからです。自分にとって、何を効率化することがベストなのか？今回のセミナーが見直し、振り返りの機会になれば幸いです。

by 古川 勝也 （コガワ・マサヤ）

IE9でprototype.js + Shadowbox.jsを使う場合のメモ

事の発端はIE9利用時のフィードバック

サムネイル表示にShadowbox.jsというライブラリを使用していました。これはいわゆるLightbox系なのですが、導入した当時はjQuery移行が活発で、prototype.jsをベースにしたものがあまり無かった中では貴重な存在でした。

今回、リリースから4年ほど経過しているシステムの追加機能をリリースしたのですが、IE9の場合にサムネイル表示されない現象が発生しました。再現してみると、クリックすると画像への直リンクとなってしまいます。

問題はprototype.jsの古さとdoctype

prototype.jsは1.7 RC3でIE9のフルサポートが完了したようです。また、Shadowbox.jsのフォーラムではdoctypeをhtml5にしたら正常に動いたということで、prototype.js 1.7 stableにアップデートしつつdoctypeをxhtml 1.0からhtml5としたところ、標準モードで問題なく動作するようになりました。IE7とIE8についても問題ありません。(IE6はもういいでしょう・・・)

イベントモデルの変更が原因？

IE9ではDOM L3のサポートで独自のattachEvent実装などがなくなっているようです。prototype.jsのソースを少し読んでみると、新しいものではブラウザ判定の処理が異なっており、イベントハンドラにまつわる記述に変更があります。この辺が影響しているようです。

ブラウザサポートはライブラリやソースのメンテナンス、リファクタリングを伴う契約に

問題は、こういった検証や修正は請求対象となるか否かでしょう。今回は無償対応としたのですが、こういったケースを想定した保守費用や継続的製作費を説明もしくは計上しておくのも、製作者サイドには大事かと思います。Androidの世界はもっと大変かもしれません。

ソフトウェアの最大のメリットは、「後から直せる」ことです。しかし、こういった特定のベンダに依存した環境で製作を行なっていくことは、「後出しジャンケンされる」ということでもあります。

SIerの世界では、そういったケースにそなえた予算取りなどが確立している所も多いですが、正直、がんじがらめにされたユーザが訳もわからず搾取されているケースもあります。AppleがFlashを全面廃止した時と同じように一寸先は闇ですが、3年以上の稼働を想定したシステムなどは、こういったケースでクライアントに理解を得られるよう平時からの情報共有が大事だと改めて思いました。

by 古川 勝也 （コガワ・マサヤ）

今後のWebサイト制作との向き合い方を改めて考える

NPO法人 あおもりIT活用サポートセンター最初の活動として、第1回目のセミナーとなる「今後のWebサイト制作との向き合い方」が終了しました。私はレポートとして会場の様子というより、講師の発表内容から感じ取ったこと、考えたことをピックアップしたいと思います。

利用者にも製作者にも有益なWebサイトとは？

今回のセミナーのテーマです。前回記事「フリーランスの製作者が考えるべきプロジェクトのバランス」では、利用者(以下、ユーザ)と製作者の他に発注者(以下、クライアント)という立場を加えていました。製作側にいると、ユーザとクライアントを履き違えてしまうケースがあります。

クライアントにとっての顧客であるユーザに利益がもたらされるバランスでないと、クライアントの事業継続に支障が出ます。やはりプロジェクトの関係者として、どういう立場があるのか？それぞれにとって有益とは何をさすのか？この視点がまず無くては始まらない、と思います。

詳しくは後述しますが、Webという言葉が入ったセミナーでビジネスにおいてWebを前提に考えるべきなのか？という疑問はポイントだと思います。

プロトタイピングの落とし穴

長谷川 恭久さん(@yhassy)のセッション、諸事情で途中参加のため内容を把握できていなかったのですが、プロトタイピングというテーマは実際の案件で使っていることもあり、常々考えていたことについて質問させてもらいました。

私の場合、プロトタイピングとスパイラルフローの組み合わせで案件に取り組むケースが大半です。要件定義から基本設計、機能設計あたりまでは、予算と納期の線引きをするためにウォーターフォールというハイブリッドな進め方です。

実装フェーズに入り、優先度の高い機能からプロトタイピングが始まります。仕様が変わるケースもありますが、それは洗練されていく過程として必要です。先にわかる、というのが大事です。

プロトタイプを見て出た追加要望への線引きはどうするか？

難しいのは追加要望のケースです。予算と納期があるので、とピシャっと冷水を浴びせるのは簡単です。しかし、そこで芽を摘むことが今後に影響が出るかどうか見極めなくては行けません。実際に追加する場合の影響範囲も重要です。

長谷川さんからいただいた回答としては以下でした。

  • 案件のファシリテーターとしてバランス感覚を保つこと
  • 製作者内部ではデザイン原則を持っておく
  • 対クライアントには最終ゴール、目的の共有を文書で行うのも効果的

プロトタイピングは最初に考えたとおりに作るという意味ではありません。最終的に出来上がったものが仕様と言えると思います。つまり途中での紆余曲折も受け入れるということですが、本来の目的がぶれないように進むことが肝要であり、難しい点です。特にプロジェクトの利害関係など、様々な要因が絡んでくると尚のこと難しくなります。

アジャイル開発の要素がこの辺には含まれるのですが、Web制作も同じソフトウェア業界なのですから制作プロセスに取り入れていく時期なのでは。(あまり単語としてすら出てこないので)

加えて、ちょうど記事としてファシリテーターのバランス感覚について書いていた途中もあって、やはり、と思う部分が多かったです。今回の回答を受けて、後日の記事でもう少し掘り下げたものをまとめてみたいと思います。デザイン原則について調べるにはAppleやMicrosoftのガイドラインも有名ですが、他にもたくさんあります。長谷川さんが配信している Automagic Podcast #39 もオススメです。デザイン原則などについて考え方の糸口を共有してくださっています。

うどん県のプロモーションは是か非か？

高畑 哲平さん(@teppeitakahata)のセミナーは初めてだったのですが、頭の中を筋道立てて整理してもらうような感覚を覚えました。セッション内容は書籍タイトルにもなっているWebマーケティング思考トレーニングということで、マーケティングという視点での考え方についてエッセンスがたくさん出ていました。

その中で、うどん県のプロモーション方法について高畑さんの持論が展開されたのですが、考察するにあたってポイントになると思った点は以下のとおりです。

  • 国交省の都道府県別宿泊者数で香川県は下位で成長率もマイナス
  • 関西圏で香川県はうどんのために日帰りできる場所
  • うどんは単価が低いので収益率が低い
  • B to C としては、うどんという目的に対して旅費¥40,000は高くないか？

高畑さんは常に商品力が最優先とおっしゃっていましたが、魅力的な商品を開発といっても回収率と商品を提供する環境も含めて総合的な判断が必要なのだとも解釈しました。

翻って青森県はどうなのか？

青森県の場合、商品と言えるコンテンツはもう十分すぎる程ある、と個人的に感じています。ただ、内需でまかなえたり販売力が弱いため埋もれているケースが多く見られます。

商品力として単品ではなく統合された状態、つまりパッケージングが最適化されていないために競争力に乏しいのではないかと私は思っています。北に行こうとしたら、青森県を飛ばして北海道まで行くと思います。北海道というパッケージングに期待していくのであって、実際に旅行してみると分かりますが、個別の商品力に関しては青森県は引けをとらないものが多々あります。しかし、そう認知されていません。

商品力というと個別に製品として考えそうですが、パッケージとして考えなければ販売チャンネルとプロモーション方法が乏しくなり、リーチしたいターゲット層をカバーできないだろうと思います。

Webの立ち位置はどこか？

マーケティングの4P(Product, Price, Place, Promotion)は更に2グループに分けられるそうです。

  • 商品力(Product, Price)
  • 販売力(Place, Promotion)

往々にして商品力にまず注力すべきということですが、Webの立ち位置は Place つまり販売チャンネルという位置づけでした。私も同感で、商品開発や企画をしている時に Web という単語は出てこないというのを高畑さんの言う通り実感しています。

Webを使おう、となるのは商品の特性や流通方法に物理的な制限があるからこそであり、拡散力や窓口の一本化などを期待しています。また懇親会で伺った内容ですが、JimdoのWebサイト設計の思想として商品力のみに注力できるようにしてあるのがポイントとのこと。

これもかなり重要な考え方なので実践しようと思いました。商品力に集中できる体制づくりは、販売力を担う部分でも考えておくべきなのでしょう。

思考力を磨いていくために

最後にこのセミナーでキーとなる言葉についてまとめたいと思います。

事業を一気通貫して売れる戦略を書く

マーケティング活動において、商品があり流通や消費があり、ユーザの手元に届いてからも体験として受け入れてもらえるか？リピーターとなってもらえるか？など、全体の流れを具体的にイメージできているのかが大事だと思います。私はこの戦略に UX も含まれていると考えています。

日常生活を経験とする

長谷川さん、高畑さんが、なぜこれほどまでに思考内容を言語化、視覚化できるのか。その答えだと思います。ファシリテーターとしてのバランスも、マーケティング戦略の解決策も日常生活に散らばるヒントを考察し、振り返り、実践して蓄積しているということなのだと思います。

過去に「あなたはフリーランスとして生き残れますか？」という記事でも触れていますが、今どうするか解答を出せないとしても、自身をアップデートし続けるマインドさえあれば、あらゆるヒントをあらゆる場所に見いだせるはずだと考えています。

普段からアンテナを張っていない対象は、不思議と流れていくだけで残りません。生活や環境の変化によってアンテナも変わってきます。そういった自身の変化との向き合い方こそが、Web制作と向きあった時の成果として現れるのではないでしょうか。

ご来場の皆様を始め、講師のお二人、運営メンバに感謝を込めて。
すばらしい機会をありがとうございました。

by 古川 勝也 （コガワ・マサヤ）

フリーランスの製作者が考えるべきプロジェクトのバランス

プロジェクトはある目的を達成するために集まったチームといえます。よくある立場としては、利用者・発注者・依頼者が考えられるでしょう。よくこういった製作話で持ち上がるのは、関係者の利益バランスの設定を間違った結果、誰にも使われない、納期に間に合わないといった成果物ができあがるパターンです。

よく聞こえてくるのは、特に発注者と製作者の溝です。果たしてこれは誰のためのプロジェクトだったのだろうか？と反省する弁もよく聞かれます。受託案件となると、イニシアティブは支払いを行う発注者にあるケースが多く、製作者がそのしわ寄せ先になると思われがちですが蓋を開ければ全員が損をしています。

  • 利用者 試す気にもならないサービス、メリットも感じられず時間の浪費
  • 発注者 投資に対してリターンを得られず資産と労働力の浪費
  • 製作者 労力に対してリターンを得られず、加えて継続的な取引機会の損失

今回の記事では犯人探しや責任のなすり合いではなく、プロジェクトにとって大事な利益のバランスについて自分なりの考えを書きたいと思います。

誰がためのプロジェクトか？

Balance of project1

製作者がよく陥る失敗はクライアントとユーザの優先順位を誤るケースです。売上をあげる、という点ではクライアントである発注者の意向に添うことで満たされることは多いでしょう。しかし、その利益とはどういう定義なのでしょう？
一見、発注者が得をして製作者も懐が温まったように見えますがビジネスとしては失敗です。なぜなら発注者の収入源となるユーザの利益が低いために、今後の回収を望めないからです。

当たり前の話をしたところで、上のグラフに違和感を感じないでしょうか？ユーザは最初の時点で、自分にメリットがあるかどうかも分かりません。発注者は投資をしたのであって、回収するまではマイナスです。お金の流れだけで言えば、製作者が一番最初に得をしているはずです。つまり、このグラフは製作者の思い込みの可能性があります。

精根尽き果てでも完遂すべきか？

Balance of project2
次にあるケースはユーザ至上主義ともいえる姿勢です。一見、クライアントの顧客であるユーザの利益を最大にしようという姿勢は正しく見えます。しかし、そのために発注者と製作者にとっての負担を非常に大きくすることで成り立つ状態であった場合、果たして継続できるビジネスとなるのでしょうか？

あくまで発注者も製作者も事業体なのですから、継続できるだけの還元が見込めなければ手を引いた方がマシかもしれません。何とかやり遂げた、しかし2度とやりたくない。特に製作者にとってはユーザーのためと言われれば弱いかもしれませんが、リターンに対して労力があまりに大きすぎる状況を冷静に見られていなければ危険です。いわゆるデスマーチは事業の継続性という点では最悪のトラウマとなります。

Win-Winとは本当に成り立つのか？

Balance of project3
関係者すべてに平等の利益があるWin-Winが理想的というのは、よくある話です。ですが、平等の利益とはどういう状態なのでしょう？これはあくまで自分の感覚になってしまいますが、平等という定義がよほど明確になっていない限り、体面上は平等であっても不公平感が募っていくようです。これは対人関係において「自分はこれだけやっているのだから」というのは、実は互いに感じていることであり、それを忘れることは1つ目のグラフへの序章となりえます。

自分が一番に投資をしているつもりで、実は自分の利益を最大限にしようと操作してしまう可能性があります。本当に利益をそのように操作していなくとも、プロジェクトの関係が良好でないと、不公平を感じてしまうというのが怖い所です。

1%だけ譲る、という感覚

Balance of project4

先ほどのグラフで余剰だった1%はユーザーに譲ります。発注者の顧客であり、継続的な還元を得るためには必要です。さらに製作者が1%をユーザーに譲ることで、発注者が得している状態を作れるかを考えます。内部的な関係としては、製作者が発注者に対して1%譲るという感覚が大事ではないかと考えています。恩を売れ、ということではなく少しだけサービスする、という感覚です。発注者に直接ではなく、顧客であるユーザに利益があることで発注者に利益が増えます、という体裁は大事です。

なぜなら最終的に大事なのは事業の継続性であり、そのためには良好な対人関係も必要だからです。加えて、最初に物理的な利益を得ることになるのは大抵の場合は製作者だという前提があるからです。
発注者から「あ、この人に頼んでよかったな」と少しだけでも思ってもらえることが、継続への一歩だと思います。

仕事と生活のバランスを忘れない

ここまで、プロジェクトという観点で書いてきましたが、あえて利益とは何か？還元とは何か？というのは具体的に定義していません。その利益は仕事としてなのか？人としてなのか？でも変わってくるからです。私の中では人として、というのを大前提にしています。
フリーランスという立場上というのはありますが、あらゆるリソースをつぎ込み、最大限の努力を自他共に認められる内容であっても、普段の生活がおろそかでは今後の継続性という点ではマイナスです。

様々な人間の助けや共生によって成り立っているという視点を見失わない余裕、バランスを維持することが実は一番に意識を払うところなのだと感じています。

by 古川 勝也 （コガワ・マサヤ）