2012年4月10日火曜日

コードの複雑さを測ろう(継続的に、見やすく)

以前、このブログでRubyのメトリクス測定ツールであるReekを紹介しました。 

最近、このReekの出力結果をHTMLに整形するツールを作りました。
こんな感じでreekの解析結果を整形してくれます。



ツールの概要については、【第3回】Edge Rails勉強会で発表させて頂いくスライドがあるのでそちらをご覧下さい。
コードの複雑さを測ろう
View more presentations from Shinya_131.


githubにコードが置いてあるので是非使って見て下さい。 
バグ報告、フィードバックなどお待ちしています!


以上です!

2012年2月7日火曜日

正しいHTMLを書こう

○はじめに
HTMLは多少構文がおかしくてもブラウザが柔軟に解釈してくれて、なんとなく動いてしまう事が多いですが、構文間違いが多いとブラウザに依存したコードとなり、想定外の環境だとレイアウトが崩れたり、動作しなくなったりする可能性があります。

今後も新しいプラトッフォームやブラウザが次々と登場する事でしょうから、出来る限り正しいHTMLを書けるように心がけたいと思います。

また、構文が間違っているHTMLは読みにくく保守しにくいので、その面からも正しいHTMLを書きたいと思います。

そこで、今回は、HTMLの構文が正しいかチェックする"HTML構文チェッカー"を使って、構文が正しいかチェックしてみました。

○実際にやってみる
私が作成している「ATND RSS」と言うサイトを例に、HTML構文チェッカーを使って見ます。

Web上にはいくつかの構文チェッカーがありますが、今回は、HTML5にも対応している(X)HTML5 Validatorを使ってみます。
他にも「HTML 構文チェッカー」などと検索するとたくさん出てきます。

①HTML5 ValidatorにチェックしたいWebサイトのURLを貼付けて「Validate」をクリックします。URLを貼付ける以外にも、HTMLファイルをサイトにアップロードするなどして構文をチェックすることも出来ます。

②すると、以下のように構文にエラーがある場所が表示されます。

2カ所のエラーがありました
  • 76行目:"/"の位置がおかしい。
  • 92行目:要素の右寄せを"align"属性で行っている。
    ※この属性はすでに廃止されている^^;)
発見されたエラーを修正してもう一回チェックしてみました。

今度は大丈夫そうです。
○まとめ
  • HTMLの構文チェックを行って正しいHTMLを書こう。


○関連記事


2012年2月6日月曜日

rubyコードの複雑さを数値化する

○はじめに
今日は、Rubyで書いたコードのメトリクスを測定するreekと言うツールを紹介します。

メトリクスの測定とはコードの複雑さ(汚さ)を計る事です。
複雑なコードは理解しにくいため、変更しにくく、バグが発生しやすいです。
メトリクスを測定して、複雑なコードを発見しリファクタリングすることで製品の品質が向上します。

○具体的に何をしてくれる?
メトリクス測定ツールは具体的に何をしてくれるのでしょうか?
例えばreekの場合は、コードの中に以下のような"汚い"部分が無いか探してくれます。
  • 大きすぎるクラス、メソッド
  • "a", "b"みたいな、何が入っているのか分かりにくい変数名
  • rdoc用のコメントが無いクラス・・・
    などなど
そして「汚い部分が何カ所あったか」と「どこがどんな風に汚いのか」を表示してくれます。
例えばこんな感じです。
./foo.rb -- 6warings    :
  #=>foo.rbに6カ所汚い部分があった
  Foo has no descriptive comment (IrresponsibleModule)
  #=>Fooクラスがどんなクラスなのか説明するコメントが無い
  Foo has the variable name 'a' (UncommunicativeName)
  #=>Fooクラスに'a'と言う説明的でない名前の変数がある
  Foo#bar has apporox 11 statements(LongMethod) 
  #=>Fooクラスのbarメソッドが長過ぎる
  ・・・
#以降は私が書いた補足です。

プログラムが機械的に解析した結果なので、完璧では無い事も多いのですが、コードの汚さの目安として使ったり、どこをリファクタリングしたら良いのかの基準にする事ができます。

では、さっそくreekを使ってみましょう。

○インストール
コマンドラインで以下を実行すればインストールできます。
$ gem install reek

○実行
reekは、1ファイルを対象にメトリクスを測定することも出来ますし、複数のファイルを一度に測定する事も出来ます。

なお、もちろんRubyで書かれたRuby on Railsのコードに対して測定する事も出来ます。

①一つのファイルのメトリクスを測定
$ reek ./foo.rb
→foo.rbファイルのメトリクスを測定

②複数のファイルのメトリクスを同時に測定
$ reek rails_app_example/app/controller/
→controllerディレクトリの中にある全てのファイルのメトリクスを測定します。

以上の通り簡単な手順ですので、ぜひお試しください。

○まとめ
  • reekはRubyで書いたコードのメトリクスを測定するツール
  • メトリクス測定とはコードの汚さを測定する事
  • メトリクスは完璧ではないけど、リファクタリングすべき場所の目安になる
  • reekでrubyコードのメトリクスを計ろう!

2012年1月31日火曜日

巻き込むデザイン

○はじめに
昨日、KDDIデザイニングスタジオで開かれた『KDDI ∞ Labo open MEETing Vol.5 - デザイン』と言うイベントに参加してきました。各方面でデザインに携わっている方々からデザインについての考え方や思いを聞くイベントです。

会場

※イベントに付いての詳しい情報はこちらにあります。
ATND:KDDI ∞ Labo open MEETing Vol.5 「デザイン」

イベントの中で、面白法人カヤックの玉田さんのセッションに登場した「人と人との繋がりをデザインする」と言うコンセプトが特に興味深かったのでレポートしたいと思います。

○プロフィール交換アプリ「flap.to」
今回のセッションではカヤックがリリースしているプロフィール交換アプリ「flap.to」が題材に取り上げられました。

このアプリは、近くに居る人と電話番号、メールアドレス、twitterアカウントなどの情報を交換するアプリです。
flap.to
このスクリーンショットに居る鳥が、自分のプロフィールを近くに居る人に運んでくれます。相手に鳥が届くとピヨピヨピ〜と音がします。

○このアプリの狙い
玉田さんは、このアプリをデザインする時に「人と人の繋がりをデザインする」事を狙ったそうです。

flap.toで連絡先を交換すると結構目立つが鳴ります。その音を聞いたまわりの人が「それ何?」と、聞いて来くる事を狙ったそうです。

プロフィール交換を鳥が行う必然は無いけど、この効果のために鳥を使ったアプリにしたとの事でした。

会場では、参加者同士のプロフィール交換が行われて、会場のあちこちからflap.toの音が聞こえて来たのですが、何とも言えない興味を引かれる音でした。

また、別の例として「iPhoneを持って拳と拳をぶつけると連絡先が交換できる」BUMPと言うアプリも話に登場しました。このアプリも使っている人だけで無く、周りの人の興味を引きつけます。

『誰かが何かを使っている所を見て「面白そう」と思わせる』ことが大切である。との事でした。

○巻き込むデザイン
ここからは私の感想です。

話が変わりますが、SNSが広まったのは「SNSは皆で使わないと面白く無いので誰かがSNSに参加し出すと自然と友達を誘う」仕組みがあるからでは無いかと思います。

SNSが浸透してくると、この仕組みは「SNSに参加していないと仲間内の話題に付いて行けなくなる」という仕組みに変わります。

この、人が人を誘って利用者が増えて行く(周りを巻き込む)仕組みが、玉田さんが言う「人と人の繋がりをデザインする」と言う事ではないかと思いました。

人と人の繋がりをデザインする事は、デザインであると同時に広告でもある。と、言えるのでは無いかなと思いました。


○関連記事

※この話、どこかで聞いた気がするのですが出典が思い出せない。

2012年1月27日金曜日

5分でWordPressとかを準備できるfluxflexがすごい

○はじめに
最近fluxflexと言うクラウドサービスを使ってみているのですが、そのサービスがとても面白かったので、ちょっと紹介したいと思います。

URL: http://www.fluxflex.com/

fluxflexを使うと、自分が必要としている様々なプラットフォームを素早く、手軽に準備する事ができます。

○fluxflexって何なの?
fluxflexは分類で言うとPlatform as a service(PaaS)にあたるサービスです。
このサービスを使うと、WordPressのようなCMSや、Ruby on RailsのようなFrameworkをサーバ等も含めて貸し出してもらい、自由に使う事ができます。

自分でサーバーを買ってきて環境を構築するのと違って、とにかく早く、安く準備できます。

○fluxflexで何ができるの?
fluxflexではGithubにあるコードをインポートしてサーバを構築する事ができます。説明するよりやってみた方が分かりやすいと思うので、例としてfluxflexでWordPressを準備する手順を説明します。

無料で試せるのでぜひ実際にやってみてください。


Step1 サーバを立ち上げる
  1. まず、アカウントを作成してログインします。
  2. 左上にある「Create A New Project」を押します。
  3. 好きなURLを指定します。
以上でサーバーが立ってしまいましたw 簡単すぎてヤバいです。この時点ではサーバーが立っただけでまだ何もできないので引き続きWordPressをインストールします。

※上記手順のスクリーンショット
2.Create A New Project
3.URLを指定

Step2 WordPressをインストールする
  1. 左上にあるプロジェクト一覧からさっき作成したサーバを選びます。
  2. Set Upタブを選びWord Pressのinstallボタンを押します。
  3. しばらくして画面右上のステータスが「Available」になったら完了です。
さっき入力したURLにアクセスしてみると、WordPressの初期画面が表示されるはずです。
2.Set Up→WordPress install
URLにアクセスするとWordPressの初期画面が!
 以上で手順は終了です。この一連の手順でfluxflexのPaaSにWordPressの環境が構築できてしまいました。とにかく早く、手軽です。

fluxflexを使うと、WordPress以外にもRedmainとかRuby on Railsとか様々なソフトやプラットフォームが簡単に準備できます。公開用のURLも貰えるので個人で何かちょっとしたサービスを作りたい時には最適ですね。

無料版ではプロジェクトを一つしか作れませんが、課金すればもっとたくさんサーバを立てる事が可能です。

○感想
もし、上記の作業を全部自前でやるとしたら何日かかるか想像しただけでため息が出ます。にかく手軽で早いのがいいですね。気軽に何か試したり公開したい時には最高です。

まだ分からない点/不安な点としては、

  • どのくらいの負荷に対応できるスペックなのか良くわからない。
  • 他のサービスに移行したくなった時どういう手段があるのか気になる。(ソースはGithubにあるからいいとしてDBは移せるのかな・・・?)
と言った点が挙げられますが、気軽な用途に使うのなら、あまり気にしなくていい事なので追々いろいろ試してみたいと思います。ぜひ皆さんも試してみてください!

2012年1月22日日曜日

jQueryのセレクタを手軽に試せるツール

○はじめに
前回紹介したATND RSSを作成するにあたって、今まで知らなかったツールやサービスを知る事が出来たので、今後何回かに分けて紹介したいと思います。
Webサービスやサイトを作ろうとしている人の参考に少しでもなればと思います。

さて、今回はjQueryのセレクタの挙動を確認できる"jQuery Selectors Inspecter"と言うツールを紹介したいと思います。

○何ができるツールなの?
このツールは「jQuery日本語リファレンス」で配布されているツールです。このツールを使うと下の例のように、ダイアログに入力したセレクタでどこが選択されるのか確認することが出来ます。

例)$("div#title")でどこが選択されるのか調べる場合。

1.調べたいページでjQuery Selectors Inspecterを実行する。
※セットアップ方法は後述します。


2.ダイアログに"div#title"と入力する。
※"$()"は不要。

3.選択される場所が赤くなる。
以上です。簡単ですね。

○セットアップ方法
セットアップ方法についてですが、このツールはブックマークレットとして提供されているので、以下のWebサイトに行って「jQuery Selectors Inspecter」と書いてあるリンクをブックマークに登録すればセットアップ完了です。



後は、調べたいWebページでブックマークをクリックすればこのツールを使えます。ちなみにjQuery Mobileで作成したサイトでも使えました。

jQueryのセレクタを手軽に確認できますね!

○関連記事


○参考資料



2012年1月19日木曜日

「ATND RSS」というWebサイトを作りました

○はじめに
皆さん、ATNDと言うイベントサイトをご存知でしょうか?
ATNDはリクルートが運営しているイベント情報サイトでイベント情報の告知や参加申し込みが出来るサイトです。
主にIT系の勉強会やカンファレンスの情報が登録されています。

今回、私は、このATNDをより便利に使えるようにする(ちょっとした)Webサイトを作成したので、今日はこのサイトの紹介をしたいと思います。

○サイトの名前、概要

「ATND RSS」
ATNDに登録されるイベントの内、自分が興味あるキーワードに関連するイベントをRSSで配信するサイトです。

URL http://atndrss.fluxflex.com/






○このサイトを作った動機
ATNDには素晴らしいイベントがたくさん登録されていてとても便利なのですが、以下のようなことで悲しい気分になった事はありませんか?
  • 大人気のイベントに申し込もうとしたらすでに人数いっぱいで予約出来なかった。
  • 大変面白そうなイベントがあったがすでに終了していた。
私も何回か上記のような出来事があって「自分が興味を持っているイベントが登録されたら速攻で知りたいなあ・・・」と日頃から思っていたので、このサイトを作成しました。

○ATND RSSを使うと・・・?
ATND RSSを使うと、自分が興味あるキーワード(例えば「Android 勉強会」)に一致するイベントがATNDに登録されたとき、すぐにイベントの情報がRSSに配信されます。
これで自分が興味のあるイベント情報を逃しません。

ATNDとRSSをお使いの方はぜひ、ATND RSSを使って、素晴らしいイベントライフを送ってください。

○今後の予定など
以上でATND RSSの説明は終わりです。ATND RSSはまだ、何日か前に開発に着手したばかりで不完全な部分が沢山あります。このWebサイトに関連した今後の予定についてつらつらと書きたいと思います。
【今後の予定】
  • ATND RSSは現在IE8に対応していない(!)ので、まずはIE8でも使えるように改修を行いたい。
  • RSSを使っていない人も多いと思うので、他の媒体(メールとかtwitter bot?)でもイベント情報をお知らせできるようにしたい。
以上

2012年1月15日日曜日

ユーザビリティテストのワークショップに参加してきました

○はじめに
今日はall webさん主催のユーザビリティテストのワークショップに参加して来たので内容を簡単にレポートしたいと思います。

ユーザビリティテストとは、製品やサービスの品質を高めるための手法で、テストしたい製品をユーザーにつかってもらい、その様子を観察することで、製品の改善点を見つけることを言います。

○レポート
さて、レポートです。
会場は品川区にある五反田図書館の会議室です。新しくて綺麗な建物でした。
会場

会場の様子
今回は、「あるケーキショップのスマートフォン向けWebサイトをデザインする」というテーマでペーパープロトタイプの作成と、ユーザビリティテストを行う内容でした。


こんな風に、実物大のペーパープロトタイプを書いて、ユーザー役の方に指でタッチしてもらいながら、操作に突っかかる部分が無いか確認したり、「この画面にこんな機能があると嬉しい・・・」と、言った要望を聞いたりしながら、ペーパープロトタイプを徐々に改善していきます。
とても勉強になった3時間でした。

○感想
1)ユーザービリティテストの必要性をあらためて感じた
普段、業務でユーザビリティテストを行うときにも感じるのですが、やはり、ユーザーの視点で考えないと絶対に気づかない部分があるので、ユーザービリティテストはコストを割いて行うべきだと思いました。

しかも、テストで発見した課題の内容によっては、製品に大幅な修正が必要なこともあるので、設計が確定する前、早い段階でやる必要があると思います。

2)テストだけでは十分では無い
テストによって製品の問題点を発見することができますが、それを改善する手法は別途必要だと感じました。テストは必要ですが、テストだけでは十分ではありません。

今回のワークショップを行ったときには、「iOS HIG」や「iPhoneアプリ設計の極意」に書いてある手法や、「誰のためのデザイン?」に書いてあったデザインについての原則の知識が役に立ったと思います。

特にiOS HIGは無料で公開されているし、内容が具体的ですので、まだ読んでいない方にはオススメしたいです。


※参考資料




誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

2012年1月6日金曜日

枠を超えるデザイン

●テーマ
今日はWebサイトやiPhone向けアプリのデザインについて書きたいと思います。

●安全領域とは何か?
Webサイトの画面デザインを行うとき、「安全領域」という考え方を考慮してデザインを行う場合があるそうです。

安全領域とは以下に書いたような、Webサイトの左上の領域です。
この部分は、ブラウザのウインドウが小さくされた場合でも表示されています。
また、WebサイトはPC、スマートフォンなどの様々な大きさのディスプレイで表示されることになりますが、安全領域は小さめのディスプレイでも表示されます。
そこで、この安全領域にロゴやナビゲーションと言った重要な要素を配置するのが良いとされています。

Google Labsに面白いサービスがありました。
このサービスを使うと、ブラウザのウィンドウサイズの分布を可視化してくれます。

この例では、99%のユーザーは最低でも紫の範囲が見えており、90%のユーザーには最低でも水色の範囲が見えていることがわかります。
左上の領域ほどたくさんの人に見れることが一目瞭然ですね。

「安全領域」という考え方は、Webサイトを「画面単体」でデザインするのでは無く、「ウィンドウの大きさ」や、「どんなデバイスで見られれるのか」と言った事に、幅広く気を配った考え方だと思います。

●ホットゾーンとは何か?
Webサイトの「安全領域」と似た考え方に「ホットゾーン」という考え方もあります。
これは、iPhone向けアプリの画面をデザインするときに使われる考え方です。
iPhoneは指で操作するデバイスです。
ですから、右手の親指が自然に届く範囲である、ホットゾーンに重要な要素を配置する事が望ましいとされます。これがホットゾーンの考え方です。(※1)
この「ホットゾーン」という考え方は、デバイスと言う枠を超えて、ユーザーの手にまで気を配った、更に進んだ考え方だと思います。

Appleが配布しているiPhoneアプリのデザインガイドラインには、「(iPhoneは)外出中、気が散るような状況で使われる」点に気をつけてデザインせよ。と、言った内容が書いてあるなど、ユーザーが置かれた状況に気を配ってデザインを行うべきである事が強調されています。

●まとめ
「画面だけをデザイン」するのでは無く、製品が使われる状況や、使う人の状況に気を配った「枠を超えるデザイン」を行う事が、UXの向上のために重要では無いかと思います。


●注釈
*1:さらに興味深いのが、指が届きにくい右上や右下の領域です。ここには編集(削除)などのボタンが配置され、何かの拍子にボタンに指が触れてしまい誤操作をしてしまわないようになっています。(推測)。ユーザーに簡単に押して欲しくないボタンを"コールドゾーン"に配置し、あえて押しにくくしているのです。

●参考書籍

iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン


すべての人に知っておいてほしい WEBデザインの基本原則


2012年1月4日水曜日

「名前をつける」ことの意味

●テーマ
プログラムを書く時、変数に名前を付けたり、クラスやメソッドに名前をつけたりと、何かに名前をつける事が良くあると思います。 
良い名前を付けることは、良いプログラムを作ることにつながります。 
そこで、今日は、この「名前を付ける」という行為の意味についてがんばって書いてみたいと思います。
●名前を付けるとはどういう事なのか?
さて、突然ですが、以下の図をご覧下さい。
この一見、関係なさそうな2つの現象には共通点があります。
2つに共通する事、それは、物と物とがお互いに引き合う法則が関係している点です。 
リンゴが地面に落ちるのは、リンゴが地球に引っ張られるからです。
また、地球が太陽の周りを回っていられるのは、地球が太陽に引っ張られているからです。(もし太陽に引っ張られていなければ、地球は遠心力でどっかに飛んで行ってしまいます。) 
かの有名なニュートンは、この物と物とが互いに引き合う法則「引力」という名前をつけ、その性質を数式で定義しました。

引力が発見されるまで、リンゴが木から落ちる原因と、地球が遠心力でどっかに飛んで行かない原因が同じだなんて、誰も考えませんでした。
しかし、ニュートンが、異なる現象から共通する性質を取り出し、「引力」と言う名前を付けた事によって、今まで別々だった現象が一つの統一された概念で説明できるようになったのです。バンザイ!
●何に対して名前を付けるべきか?
ところで、ニュートンは引力という目に見えないものに名前を付けました。   
そして、名前がついたことで、引力という概念を他人に伝えたり、引力について議論したりできるようになりました。
目に見えるものに名前を付けるのは普通の事です。重要なのは、目に見えない物に名前をつけて目にみえる(認識できる)ようにすることです。
目にみえるものであれば、他人と共有できます。
●まとめ
  1. 名前を付けるとは、別々の物から共通の性質を取り出すことです。そうする事で、別々の現象を一つの概念で扱えるようになります。
  2. 目に見えない物に名前を付けることで、目にみえる(認識できる)ようになります。そうする事で、それを他人に伝えたり、それについて議論したりできるようになります。
●参考資料
本記事は、以下の資料を参考にしました。参考にしたと言うより、ほとんど以下の記事同士をくっつけただけになってしまいました。しかし、もし、上手くくっついているとすれば、それはそれで意味があることだと思いますので、そのまま掲載します。もし上手くくっついてなかったら・・・ごめんなさい。 

2012年1月1日日曜日

勉強会のススメ

都内では、プログラミングについての勉強会やデザインについての勉強会など、ITについての様々な勉強会や情報交換会が開かれています。

このような勉強会はイベント告知サイトで参加者の募集を行っている事が多く、基本的に誰でも参加できます。参加費は無料か安価な事が多いです。

こういった勉強会は平日の18時以降や土日に行われる事が多いです。そして、プライベートな時間を割いて勉強会に参加するよう人は優秀な人が多いため、こういう勉強会に参加すると大変勉強になります。

以下に、IT系の勉強会が多く登録されているイベント告知サイトをまとめてみました。勉強会を探す際の参考になればと思います。


◆ATND
  • twitterのアカウントで参加予約が出来できて便利です。検索機能が充実していないが登録件数が多いです。
  • ATNDで人気のイベントをtweetしているbotがあるので、それをフォローして面白そうなイベントが開催されていないか探すと良い感じです。→@upmeetup

◆IT勉強会カレンダー
  • 日付別にイベントを探せます。

◆zusaar(ズサー)
  • 決済機能がついているので有料のイベントが探せる。

◆@ITイベントカレンダー
  • @ITのイベント告知サイトです。

他にも良いサイトがありましたらぜひ教えてください。


2011年12月31日土曜日

削るならスコープ

私が所属している会社では、アジャイルでシステム開発をするのですが、その時に良く発生する問題があります。

それは、「要件がコロコロ変わって確定しない」と言うことです。

いや、そもそも変化を抱擁せよと言う言葉が表すように、現実に合わせて柔軟に計画を変更させて行くことこそがアジャイルでは大切なのですが、実際問題として要件がコロコロ変わると問題です。

なぜなら、プロジェクトには以下のような制約があり、要件が変わって作業量が増えた分、別の何かを犠牲にしなければいけないからです。
1)予算
2)時間
3)スコープ
4)品質

さて、私たちは変化を抱擁し計画を柔軟に変更する一方で、4つの制約の内、何を犠牲にすべきなのでしょうか?

先日、アジャイルサムライと言うアジャイルの指南書を読んでいたところ、この問題の解決へのヒントになる事が書いてあったので紹介します。

アジャイルサムライによれば、このような時は、まずスコープを削ることを検討するべきとのことです。

ある統計によると、開発したシステムに実装された機能の内、6割程度はほとんど(あるいは全く)利用されないそうです。

使わない機能を作ることに労力を割くくらいだったら、もっと優先度が高い他のタスクに労力を割いた方が良いですね。


2011年11月13日日曜日

「肩越しの視線」


10月に面白法人カヤック様という会社で「ゲームニクス」についての講座がありました。

その講座に出てきた「肩越しの視線」という考え方が使いやすいシステムを作る上で大切な考え方だと感じたので、参加レポートをかねて当日の内容の一部を書きます。
  • 講座の概要
場所:面白法人カヤック様 恵比寿オフィス
日時:2011/10/21
演者:立命館大学 サイトウ・アキヒロ教授
概要:
日本の家庭用ゲームには、プレイヤーが説明書を見なくても操作方法に迷わないよう、様々な工夫が詰まっている。これらのテクニックをまとめ、体系化したものをゲームニクスと呼ぶ。 
今回の講座では、ゲームニクスが誕生した背景とそのテクニックの一部をファミコン黎明期よりゲームのディレクションに携わってきたサイトウ教授が説明する。 
※本記事では実際のテクニックではなく、ゲームニクスが誕生した背景に絞って書きたいと思います。 
  • ゲームニクスが誕生した背景
  • 家庭用ゲーム機の歴史は1983年のファミコン発売から始まったと思われがちだが、それ以前にもアタリ社が販売していたゲーム機がアメリカで広く普及していた。  
  •  しかし、アタリ社のゲーム機向けのゲームは、開発しようとすれば誰でも開発でき、アタリによる品質チェック無しに発売できたので低品質なゲーム(クソゲー)が氾濫して、市場の信用を失い、売り上げと株価が暴落した。
  • アタリの 失敗を見た任天堂は、ゲームの品質をチェックする機関「マリオクラブ」を設立した。マリオクラブでは一般公募で集めたプレイヤーに審査対象のゲームを遊んでもらいゲームの品質をチェックした。 
  • 審査内容はプレイヤーにA4一枚分程度の説明書だけを与えて、後は操作方法についての説明が無い状態で遊んでもらい、詰まらずに操作できるかをチェックすると言うものだった。
  • 当時はマリオクラブの審査に通らないとゲームが発売できなかった。
  • 「肩越しの視線」の大切さ
  •  ゲームの面白さは大切だが、操作方法が分からなければそもそもその面白さまでプレイヤーはたどり着けない。
  • 当時のゲームクリエーターたちは、ゲームを作っている最中に他人にゲームで遊んでもらい、その様子を肩越しに見て、プレイヤーの行動を確認しながらゲームの制作を進めた。 
  • ゲームクリエーターは「このアイディアいい!」「おれグレイト!」と言うエゴを持っている。 
  • 作った人は作った人のエゴで物事を見てしまうが、他人の視線、肩越しの視線が大切。
  • 感想
  • ゲームクリエーターに限らず、モノ作りをする人であれば、自分のアイディアに対して自信を持つ事があると思いますが、それを「エゴ」と呼んで、あくまで使う人の使う人の視点(「肩越しの視線」)にこだわる姿勢が強く印象に残りました。

Bloggerにソースコードを載せる時にシンタックスハイライトする方法

プログラミング関係のブログを見ていると、よく↓のような感じで、シンタックスハイライトされたコードが、いい感じで載せられているのを見かけると思います。

 
class my_class
  def my_method
    p "hello world!"
  end
end

どうやら Syntax Highlighterと言うライブラリを使っているようなのですが、Bloggerでこのライブラリを使う方法になかなかたどり着けず苦労しました。

以下のサイトに書いてある方法を試したらうまく行ったので書き残しておきます。


http://net-3.blogspot.com/2011/05/blogger.html


流れとしては、
1)以下のサイトでHTMLに埋め込むコードを取得し、
http://www.way2blogging.org/2011/03/how-to-add-syntax-highlighterv3-to.html
2)BloggerのブログテンプレートのHTMLファイルに書き込んで準備完了。
3)使う時は、以下のような感じでpreタグにclassを指定して、ソースコードを括ってあげる
 
    色づけしたいコードを記述



※2012/2/6追記:このサイトに載っている方法でもうまく行きました。
http://yksmtmks.blogspot.com/2011/05/syntaxhighlighterblogger.html

 以上

2011年11月12日土曜日

ブログ始めました。


「勉強したことをアウトプットすると知識が身につきやすい」と、聞いたのでブログを始めてみました。