MLBのデータはXMLまたはJSONで取得できるらしい

イチローの打率が気になるので、どこかからデータを引っ張ってきてグラフ化したいなぁ、できれば毎日更新でとか思ってたんだけど、ニュースサイトをパースするのも何か面倒だしましてや手入力とか。どこかでCSV配布してるサイトとかないのかなぁとか思ったらば、なんとMLBが全選手の全データをXMLで提供していることが解って驚愕。マジか。 正確に言うと、「Gameday」っていう今日の注目試合みたいな企画のためのデータベースなのだけど。 MLB.com Gameday | MLB.com: Gameday これがオープンになってて自由に使えるみたい。 データベースはRESTチックにアクセスできそうな階層になっててルートはここ。 http://gd2.mlb.com/components/game/mlb/ 探せば色んなデータが手にはいる。すげえ。

続きを読む

水曜どうでしょうでおなじみ「HTBオンラインショップ」で予約が可能に!

先ほど、うれしーによって水曜どうでしょう「本日の日記」が更新されました。 それによると、

2011年6月13日(月) 嬉野です。 えぇ、奥さん。 HTBにはですね、 HTBオンラインショップというのがありますがぁ、 奥さん辺りは御存知でしたでしょうか? (中略) ただ奥さん! ここからが注目! えぇこれまでね。 唯一、予約販売ものだけがね、 注文出来なかったのね。 受付できなったのですね。 この「HTBオンラインショップ」からはね。 (中略) 「HTBオンライン城・炎上」みたいなね。 どころなく勇ましい感じがしますね。 しますします。 (中略) 「HTBオンライン城・落城寸前!」 あぁ、これ好いわ。 (中略) (※もう誰の許可も取らずに勝手に「HTBオンライン城」と書いちゃってますけど。しったこっちゃないですよ、ねぇ) それがね奥さん! その出来なかった予約受付がさぁ! 「HTBオンライン城」でも出来るようになりましたのよ! (中略) だってだって、これからはね、 忙しくってなかなかね、 「ローソン屋敷」のロッピまで討ち入りにいけないわ! って焦ってた奥さんなんかもね、 もう自宅のパソコンからね、 「HTBオンライン城」をゴンゴン攻めていただくとさぁ、 どうでしょうDVDの予約が出来てですよ、 (もちろん予約特典付きでよ!) しかもよ! 受け渡しの日にはよ! 奥さんの自宅に届けられるんですのよ! ね。 まったくお出かけしないで済んじゃうのよ! (中略) さぁ、それで、それはいつからでしょう! ということでね、 話を続けるとですよ、 その期日は! 来る6月15日午前10時よりとなりますの! これは、どうでしょうDVD第16弾!「72時間!原付東日本縦断ラリー/シェフ大泉夏野菜スペシャル」が、例のごとく予約受付開始されます日時と期を一にしたのでございます! これによりまして、 伝統ある「ローソン屋敷討ち入り!」に加えて! 風雲急を告げる「HTBオンライン城攻め!」も行われることになるわけでありますよ!お立会い!
 

続きを読む

ユーザビリティと統計とmixi

# あんまり真面目に書くつもりはないのだけど Webサービスのユーザビリティを見てみたとき、それが全て直感的で便利とは限りません。 例えば、Amazonで商品をカートに入れた後に出てくる画面。 買い物する人にとってこの画面て本当に重要なんでしょうか。 これ無しで、続いて検索なり買い物なりできた方が便利じゃない? せめてカート画面に移動してくれるとか。 僕はユーザーとしてそう思うんだけど、でも多分統計上はそうじゃない。 これを気にして買い物をしなくなる人よりも、 この画面が表示されることで「オススメ商品」へと進む人の方が多いんですよね。 だから、ユーザービリティの設計というのはただ単なる「デザイン能力」とは違います。 見た目美しいとか、わかりやすいとか、使いやすいとかそういう一般的な「デザイン」だけではなく、 良いユーザビリティの設計とはサービス側の目的をきちんと反映することができる設計なんだろうなと。 そうした、僕らからは「結果論的」に見えることを事前に見通せる人が素晴らしい設計者なのだろうけど、 そんなに素晴らしい設計者ばかりがいるわけでもないので(一応僕もプロですけど、そんなの全然自信ない)、 凡人しかいない場合にはデザイン毎にきっちり統計を取って納得性を持たせるということをやります。 そんなの所詮、理屈の後付けに過ぎないのですけど、凡人にとってはそれが重要だったりします。 でも、そういうことを繰り返していると、たまに、「何のために統計を取っているのか?」を忘れてしまうのですよね。 補助線だったはずの「統計」がデザインの主導権を握ってしまったりします。 明らかに見た目汚いし使いづらいけど、統計上こういうのが良いはずだからこれで、みたいな。 Apple製品の後追いデザインみたいな感じね。 そうなってくるともうなんか、明らかに間違ってるのに誰も文句付けられなくなったりして、 最終的に稼働率下がって「なんでなんだ」的な話になったりとか。 明らかに使いづらく、使いづらくなってんのにねぇ。 ここ5年くらいずっと続く、mixiのデザインの迷走ってそういうことなんじゃないかとちょっと思いました。 最近スマートフォン向けインターフェイスがリニューアルしたけど、これまた酷いよ。 そりゃ統計上、そういうデータを欲しい人が一番いるのかも知れないけど、正直うざいだけで。 iPhoneではmixi、開かなくなりましたよ。 現場のデザイナが悪いわけではなくて、 デザイン部門のマネージャーが無能なのに有能なフリしてるんじゃないかと思うなぁ。

続きを読む

【メモ】 「バックエンド」はどこからどこまで「バックエンド」なの?

Webサービスにてユーザーがアクセスする部分と管理者だけがアクセスする部分(管理ツールなど)とがあって、 個人的には前者を「フロントエンド」後者を「バックエンド」と呼称したいのだけど、 それで違和感がないか自信が持てなかったので少し調べてみた。 検索で一番最初に出てくるのはJavaベースの開発。 アプリケーションの構造によってかなり違いはあるけれども、ざっくり言えば、

  • フロントエンド … HTTP処理を行う部分(Webサーバ/アプリケーションサーバ)
  • バックエンド … データベースサーバ
というのが普通っぽいようだ。 業務用途としての裏表ではなくて、アーキテクチャ的に見てどうかというような。 HTTP処理すればそこはアプリケーション的にはフロントエンドであり、 それを介して更新されるデータ部分がバックエンドだよねと言う。 まぁそりゃそうか。それはそれで筋が通ってる。 ただその後の様々な文章を読んでいくと解釈は結構適当なようで、 ざっくりと「後ろにあるもの」的な用法をしているところもちらほら。 並べてみるとこんな感じ。

Webサービス

  • フロントエンド … Webサービスそのもの、ユーザーのPCやブラウザ
  • バックエンド … APIや会員情報を管理する部分(「バックエンドシステム」と呼称)
バックエンドにインフラやサーバ等ハードウェアを含める場合もあり。

ブログサービスなど

  • フロントエンド … CMSが出力するHTMLファイル
  • バックエンド … CMSソフトウェアおよびデータベース

広告配信サービス

  • フロントエンド … 広告を表示させる部分
  • バックエンド … どの広告を表示させるか決める部分

一般的なビジネス

  • バックエンド … 「POSシステム」「需要予測システム」「会計システム」など。イントラネット内の内部向けサイトも
まぁ確かにこれはこれで「裏側」ですね。間違ってはない。 んー厳密じゃないのか?

結論的なもの:

ニュアンスで良いんじゃないかな。うん。 別にアーキテクチャの概念を反映した設計を書くわけではなく、 単純に呼称をどうするかという話だし。 あんまり気にしないことにします。

続きを読む

【メモ】 Gmailに転送するよりPOP3で取得する方が便利かも

SPAMフィルターの利用とバックアップの目的でメールをGmailに集約しています。 今までは各メールサービスでメール転送を設定し、Gmailとして受信していました。

  1. hoge@fuga.comにメール受信
  2. hogefuga@gmail.comにメール転送
  3. hogefuga@gmail.comにアクセスしてメール取得
大体はこれで問題なく動くんですが、サービスの状況によってちょっと不安定になる部分があり気になっていました。 あくまで体感でしかないのですが、メールの受信よりメール転送の方が信頼度が落ちる気がするのです。 サーバの状況で遅延しやすいというか。 また、仮に遅延が起きた場合に元メールを受信していないのか、転送に失敗しているのか、 Gmailが受信できていないのか判断が面倒くさいという欠点もあります。 そもそも転送を設定できないサービスもありますし。 というわけで、先日設定を以下のように変更することにしました。
  1. hoge@fuga.comにメール受信
  2. hogefuga@gmail.comがhoge@fuga.comからメール取得
  3. hogefuga@gmail.comにアクセスしてメール取得
具体的にはGmailの設定「アカウントとインポート」「POP3 を使用したメッセージの確認」内の、 「POP3 のメール アカウントを追加」から追加を行えます。メールソフトの設定と同じなので特に困ることはないかな。 設定するとだいたい30分に1回取得することが出来ます。

この方法のデメリット

GmailのPOP3の取得タイミングは30分に1回程度なので、最大30分から1時間程度メールを取得しない、 ということが起こりえます。PCメールですからそんなの普通にあることなんですが(プッシュ型の携帯メールとは違う)、 通常のメールチェックはもう少し間隔が短いし、不便を感じるかも知れない。 任意のタイミングで取得しようと思ったらわざわざ設定画面を開く必要がありますし。 その辺りは用途によって考えるべきかなと思います。 ただ、こんな説明もあるので活発に使ってるメールアドレスだったらこの問題は顕在化しないかも。 検証はしていませんが。
Gmail がメールを取得するアカウントのメール受信間隔が長い場合は、Gmail が新着メールをチェックする間隔も長くなります。
 

続きを読む

1日1ニコ移転します(作業中)

現在、はてなダイアリーを中心に更新中のニコニコ動画紹介コーナー、「1日1ニコ」ですが、 ブログ内に記事を載せた場合の色合いとか、はてなダイアリーでの企画的自由度のなさなどを考えた結果、 ブログとして独立させることにしました。 あ、エイプリルフールだけど、マジで。 Google Analyticsに登録したらば猛烈な勢いでクロールされたので、 なにがしかで検索すると引っかかるかも知れませんが、基本的にはまだ移行作業中。 一応、毎日更新されてはいますが、あくまでテスト運用です。 「ニコニコ動画的サービス」にまでするつもりはありませんが、個人的に、

  • 今流行ってるらしい動画を把握することが出来る
  • ニコニコ動画関連のエントリを容赦なく投稿することが出来る
  • 同居人がアカウントがないので外部プレイヤーで動画を見やすくできる
あたりを目的としつつ、徐々に整備して行ければいいかなと。 URLについては正式稼働し次第公開の予定。 そんな感じで。

オマケ:技術的なチャレンジポイント

  • jQuery
  • 3カラム
  • ランキングデータの解析

続きを読む

RSSリーダーの変更を検討中

「RSSリーダーなんて今日日はやらねえんだよ」 というお言葉はもっともでありまして、「最近のWeb通のトレンドはこれ、paper.li それにreddit組み合わせ、これ最強」 ということかも知れませんけれども、まぁでもぶっちゃけ自分が継続してチェックしたいサイトがあった場合にそれを漏らさずチェックするのは、TwitterやTumblrではまぁ無理なわけでして(どんどん流れて行っちゃうからね)、結局んところRSSリーダーは必要だなぁと個人的にはまだ思っているわけです。代替手段はまだ出てないなぁと。 んで、現在使っているのは自前のサーバにインストールするタイプのRSSリーダー、「フレッシュリーダー」なのですが、 グループで使える高速 RSSリーダー – フレッシュリーダー Ver.2 昨年の9月末を持って販売が終了、今年の9月末を持ってサポートも終了と言うことで、今ある製品のセキュリティ・ホールとか放置で捨てられちゃうのねーと思うとやっぱり不安なのでじゃあ変更するかと。使ってるのが自分ひとりじゃないので、そうそう安易に移行できませんが、出来ればメンテナンスできるサーバ・インストールタイプが良いなぁと思いつつ、いやいや、余計なエネルギー使う必要なんか無いしGoogleリーダーかlivedoor Readerでいいだろとも思いつつ、この辺を視野に検討中です。 Google リーダー livedoor Reader – RSSリーダー Fastladder : RSS / Atom feed reader ちょろっと見た感じでは、もうGoogle リーダーで十分だろと思ったんですけどね。一応、自分でも触ってみたいなぁというのはあってですね。いやでも面倒くさいからGoogle リーダーでいいかなぁやっぱり。ですよねぇ…

続きを読む

Google AdSenseのアカウントが停止されましたよ、と。

広告が表示されないのでおっかしいなーと思ってログインしてみたらばこんな表示が。 えー。 メールチェック。 確かにこんなメールが届いてました。

サイト運営者様 記録を確認しましたところ、お客様の AdSense アカウントにおいて不正行為の危険性があることがわかりました。不正行為により AdWords 広告主の費用が増大するのを防ぐため、お客様の AdSense アカウントを無効にさせていただく必要があります。未払いの収益と Google に分配された収益はすべて影響を受けた広告主に払い戻されます。 これは Google の広告システム、特に広告主とサイト運営者の関係を公正に維持するための措置ですのでご了承ください。ご理解のほどよろしくお願いいたします。 今回の措置、異議申し立てを行う方法、不正行為全般についてご不明な点がある場合は、次の URL で詳細をご覧ください。 http://www.google.com/adsense/support/bin/answer.py?answer=57153 よろしくお願いいたします。 Google AdSense チーム
さっぱり内容が解りません。 不正行為の「危険性」があった?どういうことなんでしょうか… ググってみるとこのメッセージはプログラムが自動的に検出して無効措置→メール送信しているもののようです。 ああ、だから具体性のないメッセージなのね。要するに不正なクリックを検出したんで止めたよという意味らしい。 不正クリック?身に覚えなさすぎ。。 こうしたことは良くあることみたいなのですが、初めてのことだったので少々戸惑いました。なんぞ。 とりあえず、FAQにある専用のお問い合わせフォーム(無効なアカウントについての申し立て)から異議申し立て。 返答には1週間程度掛かるらしい。うむー。 さてどうなりますかねぇ。

続きを読む

[umbls] postのタイトルが誤って付けられてしまう不具合を修正しました。

いつもご利用ありがとうございます。 umbls | Tumblrを便利に使うサービス binderで作成したRSSにて、postのタイトルが誤って付けられてしまうことがある不具合を修正しました。

不具合内容

「post TypeがPhoto、Quote、Videoの場合」で、「タイトルが設定されていない場合」に本来であればそれぞれ「Photo」「Quote」「Video」というタイトルにならなければいけないところ、1つ前のタイトルが設定されてしまう
プログラムを修正し、現在取得中のアイテムについては正しいタイトルが付けられております。 ご迷惑おかけいたしました。 @Charz_red さん、ご報告ありがとうございました!

続きを読む