株式会社10Xに在籍して4年になります

この記事は10Xアドベントカレンダー2024の10日目の記事になります。昨日は品質管理チームのブロッコリーさんが「10Xに入って1年半でやったこと・感じたこと」という記事を公開しています。

ソフトウェアエンジニアになってから

ブログをそろそろ更新しないとなと思いつつ、気がつけば長い時間が経過してしまった。どれくらい長い時間かというと、約14年だ。

kazu0620.hatenablog.com

今みるとすごく恥ずかしいのだが、14年前に上記の記事を書いて就職先を募った。そのときは「駆け出しエンジニア」という言葉はなかったけれど、その走りのようなものかもしれない。

上の記事を書いた結果、実際にいくつかのWebサービスを開発している会社にお声かけいただき、本当に運良くソフトウェアエンジニアとして働くことができた。この記事では、ソフトウェアエンジニアになってからのその後と、今働いている10Xという会社の話を書くことにする。

ソフトウェアエンジニアになってから10Xに入社するまで

KLabでの3年間

前回の記事を書いたあと、ご縁があり入社したのはKLab株式会社というソーシャルゲームを開発している会社だった。とある版権モノのゲームの開発運用を担当していたのだが、大量のアクセスが来て絶望しながらパフォーマンスチューニングをし続けたのも今では良い思い出。

地道なスロークエリ対策から始まりデータベースの垂直分割、フレームワークのORMを魔改造、と増え続ける負荷に合わせて様々なレイヤでパフォーマンスの改善に向き合う機会があった。

開発の手法だけではなく、今振り返って思っても優秀な周囲の先輩たちからソフトウェア開発の哲学のようなものを学ぶことができたのも価値のある経験だったなと思う。KLabでは3年間働き、2年目からはチームの開発リーダー、3年目には複数チームのマネジメントなども担当させていただき、短いけれど濃密な経験を積むことができた。

個人開発生活で貯金が底をつく

その後、仲間と2人で個人のiPhoneアプリをひたすら開発運用する、という生活を2年ほどした。受託開発は行わず、自分たちが作ったプロダクトの収益だけでやれるところまでやる、というチャレンジだった。

結局最後は貯金が尽きて終わったけれど、企画やデザイン、マーケティングから開発まですべてを自分たちだけでやるという経験は最高に充実していたし得るものもあったと思う。失った貯金に釣り合うかはわからないが。

技術的な学びとしては、2Dの箱庭ゲームを作るフレームワークを内製したりして、この時期にオブジェクト指向の考え方をようやく腹で理解できたというか、腑に落ちた気がする。

Sansanでの5年間

貯金が尽きたあとはSansan株式会社という名刺のプロダクトを作っている会社で働き、iOSエンジニアとして個人向け名刺アプリの開発を担当した。

技術的な面では、多くのユーザーに利用されて一定の歴史があるプロダクトのリアーキテクチャを推進する、という経験ができたのは多くの学び(と反省）があった。また、本気でプロダクトで世界を変えようと真摯に働く創業メンバーを目の当たりにしながら仕事ができたのも、今の仕事を選ぶ価値観に影響を与えていると思う。

最終的にはAndroidの開発にも一部携わったり、エンジニアリングマネージャー / プロダクトマネージャーというロールも担ったりと、幅広いチャレンジの機会をいただくことができた。また、Sansanでは技術イベントへの登壇や技術書執筆などの機会も得られたが、これも会社の後押しがあったからこそだなと思っており、今でも感謝している。

10Xとの出会い

プロダクトマネージャーとして尊敬しているyamottyさんと、ソフトウェアエンジニアとして尊敬しているishkawaさん、この2人が起業をした、というのは自分の中でもニュースだった。

最初は外巻きに様子をみていたのだけど、当時10Xがタベリーというプロダクトを少人数で作っていて、これが非常に完成度の高い出来だった。10人未満でこれを作ってるというのにびっくりしたのと、自分もこれに携わりたいと感じ、ちょうど元同僚が10Xで働いていたので、声をかけてみた。

まだ社員が10人未満だったときで、CTOのishkawaさんとまず渋谷のスタバで面談をしたのを覚えてる。その後、CEOのyamottyさんととも表参道の飯屋で面談をして話を聞いた。事業を短期間で成功させたり流行りに乗る、というより、何十年という長い時間をかけてでも大きな成功を目指してるのが印象的で、いいなと思った。

そこからは気がつけば、1dayインターンという名の選考を経て入社していた。

10Xでの4年間

10Xに入社後は、最初の2年間ほどはソフトウェアエンジニアとして久々にゴリゴリに開発に携わることができた。サーバー / クライアントなど領域を閉じずに、モバイルアプリのUI実装から決済システムのバックエンドまで、色んな機能の開発に関わることができた。

特にサーバーサイドは5年ほど書いてなかったこともあり、k8sを用いたインフラ運用やPub/Subを使った非同期処理など、触れてなかった技術に関わる機会もあり新鮮だった。

2022年くらいからは、どちらかというとマネジメントに軸足を移して、組織作りに関わっている。コードをひたすら書けるほうが好きと言えば好きではあるが、事業が成功する可能性が少しでも上がるなら必要なロールを担う、という心持ちで挑戦してみている。

なぜ、まだ10Xで働き続けるのか

10Xに入社して、4年半。業界的には平均2〜3年ほどで転職するイメージがあるので、すでに結構長いほうだ。でも、まだ今の所転職する予定はなく、当分腰を据えて10Xで働こうと思っている。なんでそう考えてるんだろうな、というのを改めて言語化してみた。

長い時間をかけて産業と生活を変えようとしている

今僕たちは「ネットスーパーがあたりまえ」のようにある世界を作ろうとしている。この状況と現実にはまだまだ多くのギャップがある。まだ日本中のあらゆる地方でネットスーパーが使えるわけではないし、都心でもみんながあたりまえのようにネットスーパーを使ってるか、というとそうではない。

これを実現するの課題は多くあるし、どの課題も軽いものではない。それでも長い時間をかけてでもやりきろという意思を経営陣が持ってることはとてもポジティブだなと思う。

2〜3年ほど集中的に取り組んで、ビジネスの成功体験を得るのも悪くない。でも、30代後半の今は、10年単位のスパンで時間がかかっても日々の生活や社会を大きく変えるような仕事もいいな、と思ってる。今のところ、4年半仕事をしたけれど何かを変えるにはまだ時間がかかりそうな状態だ。

時間をかけてでも、身近な生活に関わる産業を大きく変えるチャレンジをしてみたい。それが、自分がまだ10Xにいる理由の1つだと思う。

事業の成功のためにソフトウェアの構造が重要

もう1つの10Xでまだ働く理由は、上記を実現するためにソフトウェアが果たす役割が大きい、という点だ。小売企業にとってのネットスーパー事業の成長、エンドユーザーの良質な体験、10Xとしての事業成長。これらをすべて満たすのは、とても難しい。

これをうまく解くためには、バックヤードのオペレーション、外部システムとの連携、お買い物の体験。そうしうたものをソフトウェアでどう表現するか、どんな構造を作るかが非常に重要だ。

答えのない難しいパズルをしてるなという気持ちに思うけれど、ソフトウェアの領域からそうした難問に取り組めること自体が面白さの1つだと考えている。最近、インタビュー形式で近いトピックについてお話したので、興味があれば以下の記事も見ていただけるとありがたい。

10x.co.jp

10Xでは、一緒に開発するメンバーを募集しています。

そんなわけで、僕はまだ当分10Xという会社で働く予定です。そして、10Xではいま一緒にソフトウェアエンジニア、とくにバックエンドに強いエンジニアを絶賛募集中です。

ここまで読んで、少しでも興味があるなと感じたら、XのDMからでもいいし、下記のフォームからでもよいので気軽にお声かけいただけるとありがたいです。ここには書ききれなかったことも含めてお話しできると思います。

• [共通]カジュアル面談 / 株式会社10X
• ソフトウェアエンジニア(SWE) / 株式会社10X

 

文系ド素人がmixiアプリを開発〜リリースするまでのまとめ

というわけで

プログラミング未経験の状態から、mixiアプリのリリースまでなんとか漕ぎ着けることができました！最近、OpenSocial界隈は盛り上がってるみたいだし、プログラミング経験はないけれど、興味ある！って人も多いと思います。そこで、所謂「ド素人」の状態からプログラミングを勉強してmixiアプリをリリースするに至るまでの僕の軌跡と、何をどう勉強すればいいのか？ってのをまとめてみました。webで調べたり、プログラマの知人に相談したりしてこれは良かった！って部分を抜き出してまとめたので、これから勉強するぞって方は参考にして頂ければ幸いです。これであなたもＳＡＰ（ソーシャル・アプリ・プロバイダー）に！

完成したアプリ

「一行リレー小説」

http://mixi.jp/view_appli.pl?id=15525
開発期間：実質3ヶ月程度
リリース日：3月24日
現在の投稿総数:7622行
現時点でのユーザー数：1112人
一日のPV数：3000超程度
サーバー運営にかかるコスト：月7000円ほど（amazonEC2/S3を利用）

という感じです。大赤字で涙目ですが、正直これくらいのユーザー数なら別にさくらの月1500円のレンタルサーバーでも捌けるはずなので、ちょこっとアプリ作りたい！って人はわざわざクラウドとか利用したりしなくても大丈夫そうな感じです！

スタート地点

・htmlとかcssはなんとなく書ける。
・レンタルサーバーを借りて、簡単なホームページは作ったことある
・でも、プログラミングは全く未経験。配列？ループ文？なにそれ、こわい。
という状態からガチでソーシャルアプリを作ることを決意。

1.サーバーサイドのお勉強をする

とにかく、素人でもPHP使えばいろいろできるんだぜ！みたいな記事をよくはてブで見ていたので、何はともあれまずPHPを勉強してみることに。（というか、この時点ではPHPとMysqlだけでmixiアプリも作れると思ってた）amazonとかブログの書評とかを見てPHPの勉強のために読んだ本が下の2冊。両方読めばとりあえず、データベース使って簡単なwebアプリなら作れるようになります！多分。

改訂新版 基礎PHP

最初に手をつけたのがこの本です。最初はすごく優しく教えてくれるんだけど、なんか途中から急にスパルタになったイメージ。でも、？？？って思ったところもgoogle先生に聞けば大抵教えてくれるんで、何とか読み進めてきました。

プログラミングPHP 第2版

プログラミングの教科書は、動物の絵の本がおすすめという噂を聞いて購入。こちらは、開発と同時並行で読んで行きました。文法構造の細かいところやセキュリティ関係の部分が上述した一冊だけではカバーしきれて無かったので役立ちました。というわけで、まぁPHPのコード書けるようになったしアプリ作るか！と、なるのですが・・・。

2.クライアントサイドのお勉強をする

勢いに乗って、実際にmixiアプリの開発についてググって調べたりコードを見たりしてみると・・・。あれ・・・？あれ・・・？プログラミング勉強したハズなのに、なんだか見慣れない文法や記法ばかり・・・。なんと！mixiアプリ、というかOpenSocialはPHPではなくjavascriptで動いたいたのです！いや、サーバーサイド（PHPなど）の知識も必要なのですが、メインの部分はjavascriptで書かれているのです！というわけで再びamazonのレビューやブログの書評を見たりして勉強の仕方を調べる。結論として、javascriptは以下の二冊だけやっとけばＯＫだという結論に至りました。javascriptの場合、下手な入門書だと本当に上っ面のことしか書いてなかったりするんで、以下の2冊を気合で勉強するのがいいと思います。

JavaScript 第5版

一見、とてもブ厚く見えるし実際こんなの読み進めれるのか？と不安になると思います。だけど、実際開いて読んでみると、やっぱ想像の通りで、わからない部分が何度もあってああ自分はアホだなーとか思って泣きそうになると思いますが、まぁとにかく読み進めてみましょう。

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

これも、開発と同時並行で読み進めて行きました。薄っぺらい本ですが、初心者が実際コーディングしてくと絶対ハマってしまうだろうなーってところの原因と対処方を書いてくれてるので、とても役に立ちました。わいはいも虫から蝶になれるのや！と妄想しながら気合で読み進めてください。

この2冊を読み終えたあと、PHPの知識と合わせてajaxで簡単なアプリを何か作ってみるといい感じです！mixiアプリは、基本全てajax（非同期処理）で書くことになるからです。あと、フレームワークの使い方も抑えておくとさらにグッドです。ちなみに、今回のアプリでは「prototype.js」というフレームワークを使用しました。

3.やっと・・・mixiアプリの開発へ！

というわけで、ようやく開発へ。で、mixiアプリについてはどうやって勉強するんだ？と思ってるかもしれませんが、mixiアプリの中身自体はjavascriptで通信部分に関してはajax的なものとPHPで書くことになるので、新しいことを学ぶ、というより今まで学んだことを生かして実際にコーディングして行くという側面が強い感じです。では、実際にmixiアプリを開発するにあたって、大枠の手順を箇条書きにしてとめてみます。

○下記アドレスの手順に従い、ディベロッパー登録をする

http://developer.mixi.co.jp/appli/pc/pc_prepare/developer_account_regist_pc

○xmlファイルを用意する

このxmlファイルがmixiアプリの本体となります。XML！？と聞いてもビビるかもしれませんが、安心して下さい。以下のアドレスにあるxmlの中身をコピーして、以下の部分にjavascriptやhtmlを記述すればいいだけです。
http://developer.mixi.co.jp/appli/pc/lets_enjoy_making_mixiapp/helloword_of_mixi_app
拡張子にビビらなくてもＯＫ！コピペしたものの中身だけちょっと変えればほら！これでもう、あなたのアプリです！

 <?xml version="1.0" encoding="UTF-8"?>
<Module>

　〜省略〜

  <Content type="html"><![CDATA[
 <!--- 以下の部分にhtmlとjavascriptでコードを記述します。 -->
<h1>Hello mixi App World!</h1>
<p>これはわいのアプリや！</p>
<script type="text/javascript">
alert("わいのアプリなんや!");
</script>
 <!--- コード、ここまで -->
  ]]></Content>
</Module>

○xmlファイルをサーバーにアップロードする

サーバーの準備に関しては次項で詳しく説明しています。サーバーのレンタル方法やFTPの使用法なんかに関しては、事細かに説明してるサイトがたくさんあるので検索すればすぐに親切な解説サイトが見つかるはずです。サーバーを確保できたらば、xmlファイルをweb上にアップしましょう。

○mixiアプリを登録する

以下のアドレスで、必要項目を入力すればとうとうあなたのアプリがmixi上で動作するようになります！ガジェットURLという項目には、先程web上にアップしたxmlファイルのアドレスを入力すればＯＫです！
http://mixi.jp/add_appli.pl

○さぁ、アプリ作成開始！

いよいよ、実際のコーディングです。マイミク情報を取得したり、idからニックネームを取得する、などのmixiアプリやOpenSocial固有の機能の使い方に関しては、以下のサイトを見ると参考になります。大体の疑問はmixi Developer Centerで解決するかと思います。最低限の機能はソースコードも掲載してくれているので、最悪コピペでも動作可能です。それでも分かりづらい部分や疑問があったときは、下の２サイトを見てみると同じことをより詳しくor分り易く書いてたりするので、オススメです。

・mixi Developer Center
http://developer.mixi.co.jp/appli
・goo Developer's Kitchen
http://developer.home.goo.ne.jp/
・OpenSocial API デベロッパー ガイド
http://code.google.com/intl/ja/apis/opensocial/docs/0.8/devguide.html

○補足

アプリの開発を実際に始めると、コードを変更したのになぜか反映されない！ってここが起こります。これは、mixiアプリが強力なキャッシュ機能を備えているためです。詳細と対策は、以下のサイトなんかを参考にしてみるといいでしょう。

・mixiアプリ開発日誌−mixiアプリ キャッシュを無効にする方法
http://blog.soratobu.jp/2009/04/465/

また、実際のコーディングを行う時にはFirebugなどのデバッグツールを使用すると飛躍的に効率がアップするのでオススメ（というか必須）です！それに加えて、プログラミング用のエディタを仕様するとさらに開発効率は上がると思います。僕は、次項で説明するlinux環境を用意できてからは、vimというエディタを使用して開発していました。

4.サーバー環境を整える

大体の個人アプリはサクラのレンタルサーバーで全然大丈夫だとは思うのですが、万が一大ヒット・・・なんてことがあるとmixiアプリの場合ケタ違いのアクセスが生まれるので、並のサーバーではとても持ちません。もちろん、ここまで読んでくれた方は、すでに頭の中で万が一の大ヒットのことを想像してヨダレをたらしていることかと思います。僕も、万が一のことを考え今回のアプリはamazonEC2でサーバーを構成していました。所謂、流行りのクラウドというやつです。実際の運用方法や概念については、下記の書籍が参考になりました。

下の入門書を読みながらVMwareを使って、仮想環境でroot権限の勉強をしました。まぁ、なんだかんだ言って普通にプログラミングしててもどっかでサーバー周りの話は絡んでくるので、linuxのお勉強をしておいて損することはないと思います。なお、VMwareのインストールに関しては下記のサイトを参考にしまいた。
http://bach.istc.kobe-u.ac.jp/lect/tamlab/ubuntu.html

Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)

とっても丁寧に書いてくれてるのですが、いかんせん「cd」と「ls」だけ覚えた状態から読み始めたのでなかなかハードでした。また涙目に。でも、セキュリティからバックアップまで詳しく解説してくれてて、とても良書でした。rootって何？ってのから、実際の運用してみるところまでこの一冊で行けちゃうのでは、と思います。

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

amazonEC2の実際の運用の実例と共に説明してくれます・・・が、具体的な内容に関してはこの本よりも著者のブログの方がはるかに充実しています。実際、運用を初めてからググって、この著者のブログを読んで解決ってパターンが多かったです。ちなみに実際に運用するまでには、詰まってgoogleで検索して・・・っていうのをかなり繰り返しました。クラウドの概念的なものをこの本でつかんで、運用に関しては下記のブログを熟読すると良いのでは、と思います。
・RX-7乗りの適当な日々　
Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次)
http://d.hatena.ne.jp/rx7/20080528/p1

5.そして、公開へ！

mixiアプリの公式カテゴリ掲載の申請をすると、mixi側の審査を受けた後それが通ってれば正式公開となります。注意点としては、
・推奨環境を書いておかないと審査に落ちる
・バーチャルグラフを使ったアプリは審査は通るが18歳未満の利用が制限される
・バーチャルグラフを用いたアプリは、オススメ欄掲載は絶望的
などでしょうか。審査には大体１〜2週間くらいかかるとmixiのディベロッパーセンターには書いてあったのですが今回開発したアプリの場合、申請から3営業日での公開となりました。実際には大体２〜３日で公開されるアプリが多いみたいです。また、確信はないのですがバーチャルグラフを利用したアプリはmixiアプリのオススメの項目には掲載されないようです。さらに、どんなジャンルのアプリであろうがまず間違いなくカテゴリ「その他」に分類され導線は限りなく細くなるので、ヒットを狙うならソーシャル・グラフに絞って利用できるものを開発するのが良さそうですね。あ、それからアプリをインストールしていなくて、かつマイミクではないユーザーの個人データは取得できない仕様となっています。ここまでは良いのですが、アプリを一度入れたけれど削除してしまった人のデータも当然取得出来なくなるというのが意外と盲点なので気をつけて下さい。バーチャルグラフを利用したアプリだと、下手するとコレで致命的なバグを引き起こす可能性もありそうなので。

6.まとめ

・開発にはサーバーサイドとクライアントサイド、両方のプログラミング知識が必要
・ヒットする可能性があると思うなら、サーバー環境を大規模アクセスに耐えれるよう整えてから公開しよう
・ヒットを狙うならバーチャル・グラフは極力利用しないようにしよう

以下、技術的なお話に関するまとめでした。戦略的なお話のまとめも用意しましたので、これを読んでアプリを開発するぞ！と思った方はぜひこちらもお読み頂ければ、と思います。

http://d.hatena.ne.jp/kazu0620/20100413/1271181653

余談
というわけで、文系でプログラミングは未経験だと言う人でも数カ月かければmixiアプリは作れます。ちなみにこれは完璧余談なのですが、このアプリの公開は大学の卒業式の前夜に始まりました。おかげで、思いも知らなかったバグの修正やまだ時間的余裕があると思ってたために追加してなかった必須機能の追加などのため式の直前まで徹夜でプログラミングをするハメに・・・。とはいえ、なんとか無事式には出席できて僕も晴れてニートの仲間入りを果たすことができました。世間の噂を真に受ければ既卒なのですでに人生終了！という噂ですが・・・。これより、就職活動を開始したいと思っております。アルバイトでも構わないので何とか、仕事を見つけられれば・・・と思っています。

というわけで

もしも面接して頂ける、という会社があれば
kazu620@gmail.com　

まで連絡を頂ければ幸いです。

Elastic Load BalancerでMySQLサーバーを冗長化しようとするとエラーが出る

mixiアプリをamazon EC2上の仮想サーバーで公開しようと目論んでいるのですが上記のところでハマりました。日本語で対策法を書いたサイトが見当たらなかったので、原因と対策法をまとめておきました！

DBサーバーの構成

・マスターサーバー１台
・スレーブサーバー２台
でレプリケーション
OS/ubuntu 9.10
MySQL/5.1.37を使用
という状態で、AWSのElastic Load Balancerにスレーブサーバー２台を紐付けしてみたもののデータベースサーバーに接続出来ず。試しにマスター側サーバーから、スレーブ側に接続しようとすると下記のようなエラーメッセージが表示されました。

エラー内容

Host 'hostname' is blocked because of many connection errors. 
Unblock with 'mysqladmin flush-hosts' 

スレーブのサーバーに接続エラーが大量発生されたためにブロックしてるよー、とのこと。このエラーメッセージにある通りに

Slave# mysqladmin -p flush-hosts" 

を実行してみると、接続できるように！！なりましたが、１０分くらいするとやはり同じエラーがでて接続エラーに。

原因

同じような症状が出ている人がいないか調べたところAWSのフォーラムで全く同じ症状に悩んでいる人が！
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=131707𠉻
さらにリンク先には、amazonスタッフの返信もありました。一部を丸ごと引用させて頂くと

It seems as if the application being load balanced (MySQL, in this case) may have some behavior which is being triggered by the default ELB health check: The CreateLoadBalancer API will set up a default health check of type "TCP", which simply attempts to open a TCP connection to the registered instance at regular intervals.

If that is the case, you would seem to have two options:
1) Reconfigure the health check (using ConfigureHealthCheck) to something that is not interpreted as an error by your application.
2) Reconfigure your application not to interpret the ELB health check probes as errors.
You can read more about the types of ELB health checks, and the default settings, here:

どうやら、ELB側で行っているHealthCheck（インスタンスが正常に動作してるかどうかのチェック）がMySQLサーバーに接続しようとしてエラーが生じている模様。解決するためには、HealthCheck側の設定を見直すか、サーバー側の設定をいじってHealthCheckをエラーと認識させないように変更するかどっちかだよー！とのことです。

対策

HealthCheckの設定（コンソールから確認可能）をチェックしてみたところ、確かに
Ping Target:TCP:3306
となっている。これがエラーの原因だったみたいです。今回は、HealthCheckの設定の方をいじってエラーを修正することにします。そもそも、HealthCheckがMySQLに接続しない限りエラーは生じないんだからポート80経由でHealthCheckすればいいのでは！？ということで、MySQLのポートではなく80番ポートのhtmlファイルにping打つように変更してみます。CUIで設定を行う場合は以下をコピペ、コンソールで変更する場合は、HealthCheck欄の一番下に表示されているEdit Health Checkをクリックして同様の設定を行えばＯＫです。

elb-configure-healthcheck  ロードバランサーの名前  --headers --target "HTTP:80/index.html" --interval 30 --timeout 3 --unhealthy-threshold 5 --healthy-threshold 3

ただし、そもそも80番ポートを通すよう様にロードバランサーを作っていない場合はエラーになるので注意です。コンソールでロードバランサーのDescription→Port Configurationに80番ポートが表示されていない場合は、以下の様にロードバランサー自体作り直す必要があります。コンソールから作る場合はロードバランサー作成時の一番最初の画面に表示されるListener Configurationの項目に80番ポートと3306番ポートの両方を追加すればＯＫです。（作成後にコレを修正する方法、探したけど見つかりませんでした＞＜）

elb-create-lb ロードバランサーの名前 --availability-zones us-east-1a --listener "protocol=TCP, lb-port=3306, instance-port=3306" --listener "protocol=http,lb-port=80,instance-port=80"

設定が終わったら、サーバー側でapacheを起動しておくのとpingの対象となるhtmlを設置しておくのをお忘れ無く。上記の通り設定変更した後に動作確認したところ、エラーなく無事動作していました！

mixiアプリのスクロールバーを消す

mixiアプリでは、記述する情報が増えて高さが一定以上になると、iフレームの右側にスクロールバーが表示される仕様がデフォルトとなっています。これ、意外とウザいんですよね。調べてみた所、openSocialが提供してくれているgadgets.window.adjustHeightというメソッドを使えば、簡単にウィンドウの高さを指定することができるようです。

1.xml内でadjustHeightの利用を宣言する

ここでちょっとハマったんですが、adjustHeightメソッドを使う場合は、xmlで利用宣言を行わなければいけません。メインとなるxmlファイルのModulePrefs部分にという記述を追加します。

     
           ...
        
           ...
    

上記の様になるとＯＫだと思います。opensocialでは、xml部分で宣言しておかないと利用できないメソッドがいくつかあるようで、ビュー画面を移動させるメソッドだとを追加する場合もここで宣言しておく必要がある様です。

2.adjustHeightメソッドを呼び出す

後は、javascript記述部分にてadjustHeightを呼び出してやれば、高さを固定することができます。

gadgets.window.adjustHeight(ここに高さを指定);

これでもう、クソ邪魔なスクロールバーは消えて、安心ですね！なお、高さの単位はピクセルで指定してＯＫです。adjustHeight(1000)とすると、iフレーム内の高さは1000pxになり、1000px以内ならばスクロールバーは表示されなくなります！！adjustHeight()とした場合は自動的に現在のiフレームのサイズに合わせたウィンドウサイズに調整してくれます。データの読み込み処理などを行ってる場合は、処理終了時にadjustHeight()を行うと良いでしょう。