タグ

mixiに関するyoheiのブックマーク (23)

  • mixi Engineers’ Blog mixi有料サービス ~ payment.mixi.jpの知られざる裏側 ~

    はじめまして。開発部アプリケーション開発グループの向田(むかいだ)です。今回は、mixiの中では珍しいmixi有料サービスについて紹介したいと思います。堅い内容かもしれませんが、最後までお付き合いいただければと思います。また、今回の内容はPC版の有料サービスに限定させていただきますのでご了承ください。 ■はじめに mixi有料サービスと言っても、以前よりmixiプレミアムは存在していました。しかし、当時はお支払い用に登録していただいた決済情報が、mixiプレミアムのサービスだけでしか利用できず、今後有料サービスを追加したい、様々なサービスを提供したいという思いのさまたげになっていました。そこで、下記コンセプトを元に課金処理部分を再構築し、2008年4月1日より新たにスタートしました。 ◇コンセプト クライアントサービスとの疎結合 セキュリティリスクの軽減 利便性の向上 1. クライアントサ

    mixi Engineers’ Blog mixi有料サービス ~ payment.mixi.jpの知られざる裏側 ~
    yohei
    yohei 2008/09/19
  • mixi for iPhoneから発掘されたmixi日記投稿用API « ku

    追記 2008.7.31 はてなブックマークでPUTにすべきというコメントがいくつかあったので、やべーatomPubとかぜんぜんわかってないから自分がちゃんと見ないで勝手にPOSTって書いたかもと思って再度確認したらやっぱりPOSTになってました。googleで検索するとCocoaのNSURLRequestのPUTを使うとなんか不安定っていうのがいくつが出てくるので、そのへんのからみなのかもしれません。あ、あとNokiaのsymbianでPUTがお手軽にできないとかあったりするのかも。 iPhoneからぜんぜん日記を書く手段がなかったらmixiから、mixi for iPhoneという日記を書いたりするiPhoneアプリが公開されました! 新しいアプリに新しいAPI、日記が投稿できるアプリなら日記投稿用のAPIというわけでmixiのあしあとAPI発掘と同じように掘り起こして見つけました。

    yohei
    yohei 2008/07/31
    知らないタグは無視しよう
  • mixi(ミクシィ)

    mixi(ミクシィ)は、友人・知人とのコミュニケーションをさらに便利に楽しくするSNSというサービスです。

    mixi(ミクシィ)
    yohei
    yohei 2007/10/28
    議論がかみ合わず、難しい言葉だけで終始。質問者が一番筋がよさそう
  • mixi Engineers’ Blog » OAuthは熱いかも?な件に関して

    お久しぶりです、最近はすっかり寒くなってきましたねー。原宿のオフィス環境に最近慣れてきたトールマエサカです。さておき、今日は認証API系のお話をしたいと思います。 OAuthとは? OAuthとは、最近注目されているウェブ上での認証プロトコルの事です。1.0プロトコルの最終ドラフトが、今月リリースされ、良い機会なのでエンジニアブログに書いてみました。 このエントリーを書いている課程で資料を検索してみたらまちゅさんが大変素晴らしい記事: WebAPI のアクセス制御に使える OAuth という仕様 OAuth の Auth は認証?認可? (私もそう思う) を既に書かれている事に気がついたので私は軽くなめる程度にします。 で、実際にOAuthがどういう風に役に立つかというと、例えばウェブサービスAがウェブサービスBから、サービスBでのユーザの認証情報 (idとかpassword) を問わずに

    mixi Engineers’ Blog » OAuthは熱いかも?な件に関して
  • mixi Engineers’ Blog » Inside Tokyo Cabinet その五

    先日、MySQL Conferenceという催しに行ってきました。そこでMySQLの開発者のBrian Aker氏およびMichael Widenius氏と話をする機会があったのですが、やっぱしトップランナー達と議論するのは刺激になるなぁと思ったmikioです(その時の資料)。さて、一連の連載も今回が感動の最終回で、TCの性能上の蘊蓄をお届けいたします。 なぜdynamic hashingを使わないか Brianさん達とTCの実装についても少し議論したのですが、その際にdynamic hashingをなぜ使わないのかと問われました。その背景として、TCやQDBMではハッシュのバケット数(=格納するレコード数を予測してその数倍に設定すべき値)をデータベース作成時に指定しなければならないという問題があります。バケット数が大きすぎると空間効率が劣化し、小さすぎると時間効率が劣化するというトレード

    mixi Engineers’ Blog » Inside Tokyo Cabinet その五
    yohei
    yohei 2007/09/25
    この連載面白いよね
  • mixi Engineers’ Blog » Inside Tokyo Cabinet その四

    涼しさに夏の終わりを感じてなんだか寂しくなるも、新しいオフィスから見えるパノラマの空の高さに癒されているmikioです。秋は気が変わりやすいこともあり、今回は唐突にDBMの並列性についての考察を記してみます。 並列性って何? 最近はマルチコアのプロセッサが当り前になってきて、そのパワーを100%引き出すために、並列性をできるだけ高めることが求められるようになってきました。それについて考える前に、まずは用語の整理をしておきましょうか。 並行性 : 二つ以上のタスクを一緒に進めること。必ずしも同時に処理を行うとは限らず、Aを少しやってからBを少しやって、それからまたAを少しやって、またBをやって...といった、いわゆるタイムシェアリングで実現してもよい雰囲気。 並列性 : 二つ以上のタスクを同時に進めること。タスクを複数のマシンに割り当てたり、複数のCPUに割り当てたり、CPU内の複数のコアに

    mixi Engineers’ Blog » Inside Tokyo Cabinet その四
  • Inside Tokyo Cabinet その参 - mixi engineer blog

    この連載のように小難しい記事が続くと、読者の皆さんだけでなく執筆陣まで引いてしまうのではないかと心配しているmikioです。いやいや、いいんです。ハッキングから夜のオカズまでバラエティに富んだブログを目指すべく、私は私なりの記事を、たとえマイノリティ向けだとしても臆さず書いてゆくのです。今回はTCの実装の詳細についてお届けします。 QDBMとどう違うの? QDBMもTCと同様にDBMの一実装で、小さくて速くて使いやすいをモットーに作りはじめて、それなりに目標を達成できたと自負しているプロダクトです。しかし、今思えばいろいろと気に入らない点がいくつかありました。TCはそれを克服すべく一から書き直したものです。具体的には以下の点が違います。 空間効率の向上 : データベースファイルのサイズがもっと小さい 時間効率の向上 : 読み書きにかかる時間がもっと短い 耐障害性の向上 : データベースファ

    Inside Tokyo Cabinet その参 - mixi engineer blog
  • mixi Engineers’ Blog » Inside Tokyo Cabinet その弐

    予定を立てた途端にやりたくなくなる症候群に堪えて連載を続けるmikioです(こんな私でもエアーマンくらいは倒せます)。前回はDBMの基について説明しましたが、それを忠実に実装しても実際には使いものにはならないことにも触れました。今回は、実用的なDBMに進化すべく、Tokyo Cabinet(およびその前身のQDBM)で考えた工夫についてお話します。 ハッシュ関数についてもう少し 前回の記事に関して、「ハッシュ関数はビットシフト使って実装した方が早いよ」という旨のお便りをいただきました(ありがとうございます)。まさにその通りで、乗算命令(ここではimull)より左シフト命令(ここではsall)の方が速いみたいです(Intelの資料によると、mulが15から18で、salが4とのこと)。しかし、DBMの場合はファイルI/Oにかかる時間が支配的になるというのが重要な点です。したがって、ハッシュ

    mixi Engineers’ Blog » Inside Tokyo Cabinet その弐
  • Inside Tokyo Cabinet その壱 - mixi engineer blog

    約半年間の沈黙を破ってOSSの世界に戻ってきつつあるmikioです。先日、Tokyo Cabinet(以下「TC」と呼びます)というデータベースライブラリをリリースしました。今回から数回に分けて、TCの設計と苦労話について連載してみます。 DBMとは TCは、いわゆるDBMの系譜のデータベースライブラリで、単純なハッシュテーブルをファイル上で永続化するだけの機能を提供します。DBMはAT&Tの古代UNIXの時代から受け継がれる伝統芸能なのですが、私はそういう枯れた技術が大好きなのです。 プログラマの皆さんは、PerlRubyではハッシュ(連想配列)と呼ばれ、JavaC++ではmapと呼ばれるような、何らかのキーに関連づけてなんらかの値を記録するデータ構造って実によく使いますよね。例えばmixiでは、ユーザアカウントに関連する情報(名前とかニックネームとか)は、ユーザIDをキーにしたハッ

    Inside Tokyo Cabinet その壱 - mixi engineer blog
  • http://mixi.jp/issue_ticket.pl は OpenID server だったよ - 知らないけどきっとそう。

    mixiのURLにOpenIDっぽいパラメータがくっついてる件 http://blog.fkoji.com/2007/08051128.html OpenID大好きなので、少し調べてみました 結論から言うと、news.mixi.jp とか video.mixi.jp とかの、mixi.jp と別ドメインにセッションを引き渡すために使ってるぽい このあたりの話のあと、cookiedomain指定をやめたのかもしれない http://kaede.to/~canada/doc/mixi-and-cookie リクエストのやりとりはこんな感じ ログインしてcookieもらう(domain指定なしなので mixi.jp にしか渡されない) POST /login.pl HTTP/1.1 Host: mixi.jp HTTP/1.x 200 OK Set-Cookie: BF_SESSION=***

    http://mixi.jp/issue_ticket.pl は OpenID server だったよ - 知らないけどきっとそう。
  • mixiに潜むOpenID認証のパラメータ - F.Ko-Jiの「一秒後は未来」

    mixiニュースのコンテンツはJSONPで取得されている。URLは以下のようなものだ。 http://news.mixi.jp/get_member_news.pl?id=******&post_key=**************** 「これをログアウトした状態でリクエストするとどうなるだろうか?」という好奇心が生じたので、試してみた。すると、次のようなURLにリダイレクトされた。(パラメータは伏せてある) http://news.mixi.jp/get_member_news.pl?id=******&post_key=****************** &openid.mode=id_res &openid.user_setup_url=http%3A%2F%2Fmixi.jp%2Flogin.pl%3Fnext_url%3D %26openid.trust_root%3Dhttp

    mixiに潜むOpenID認証のパラメータ - F.Ko-Jiの「一秒後は未来」
  • たけまる / mixi station API

    ID + Password フォトについては Feed URI がないようです.エントリを追加することは できますが,取得することはできません (普通どおり,ブラウザで mixi.jp にログインしてみてくださいということでしょう). URI に含まれる "r=<数値>" という部分は意味がないようです.数値がな んであっても,あるいはこの部分がなくても,動作します. ■ mixi station API を利用したクライアントの実装例 足あとの一覧を表示するクライアントのサンプルコードを紹介します. クライアントオブジェクトには XML::Atom::Client を使います. XML::Atom::Client は,WSSE をサポートしています.また,取得した XML を適切なオブジェクト (XML::Atom::Service, XML::Atom::Feed) に 自動的に変換し

  • たけまる / XML::Atom::Service 0.12.0

    _ XML::Atom::Service 0.12.0 [atompub][perl] 昨日 [2007-07-01-1],mixi station API の解析結果をまとめましたが, 調べているとこんな記事を見つけました. yohei-y:weblog: [これはすばらしい] mixi ステーション API。ただ一つ注文が… どうしても直してほしいのは APP の service document の名前空間 URI。 これは http://www.w3.org/2007/app が番仕様である。mixi の Web API は古い名前空間を使ってる。 mixi は Perl で開発をしていたはずです.Perl の APP モジュールの一 部 (XML::Atom::Service) のメンテナは自分です.ということは,ひょっ としたら,これは自分のせいではないのか? ということに気

    yohei
    yohei 2007/07/02
    GJ。米欄で miyagawa さん追加情報
  • mixiのあしあとAPI発掘 « ku

    mixiが新しく出したmixiステーションがすばらしいです。その裏側が。 mixiにログインした状態で http://mixi.jp/atom/tracks/r=2/member_id=myMixiID にアクセスするとatomで自分のページのあしあとがフィードされます。ちなみにmixiステーションが送っているリクエストは以下の通り。 GET /atom/tracks/r=2 HTTP/1.1 X-WSSE: UsernameToken Username="ku@example.com", PasswordDigest="passwordDigest8jrjEdO61Bx8c=", Nonce="Y0NonceLYj0=", Created="2007-06-29T03:04:30Z" User-Agent: mixi station/v1.4 (by glucose) Host: mix

    yohei
    yohei 2007/06/29
    おおー
  • http://mixxi.jp/url

  • asahi.com: 「76世代」の時代が来た ミクシィ東証マザーズ上場 - 就職・転職

  • BKCon 2006 - にぽたん研究所

    昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち

    BKCon 2006 - にぽたん研究所
  • 見出しの効能 - 牛のつれづれなるままに3.0

    Webページのアクセシビリティを高める一つの手段として、見出し要素によるマークアップを挙げることができる。HTMLのh1,h2…というやつである。 来の目的からすると章、節、項目といった階層構造の長いドキュメントにしか使えないのだけど、現在のようなUIかドキュメントかわからないWebページでも、機能や意味を考えるとマークアップできる。たとえばdel.icio.usのブックマークでは、 h1: 「del.icio.us/kinoue」 h2: 「All your items (17)」 h3: 「tags」「options」 h4: 各ブックマークのタイトル といった感じになっている。 このようになっていると、たとえば視覚障害者用閲覧環境では、見出し移動コマンドを使って素早く構造をたどって移動することができる。 しかしながら、mixiでもはてなブックマークでも、あまり見出しによるマークアッ

    見出しの効能 - 牛のつれづれなるままに3.0
  • はてなブログ | 無料ブログを作成しよう

    木場公園の隣に咲く河津桜|春の訪れを感じる 春の陽気を感じながら、カメラを片手にゆったり散歩。 木場公園の隣に咲く“河津桜”は、見頃を過ぎても美しかった。 木場公園の隣に咲く河津桜 多くの観光客が訪れているのは、海外でも桜の開花情報がシェアされているからだろう。 後ろのマンションが日らしさを引き…

    はてなブログ | 無料ブログを作成しよう
    yohei
    yohei 2005/03/29
    同感。mixi で重要なのはリアルワールドで友達な人とのつながりだけ
  • mixi(ミクシィ)

    mixi(ミクシィ)は、友人・知人とのコミュニケーションをさらに便利に楽しくするSNSというサービスです。

    mixi(ミクシィ)