 |
|
|
| |
|
弊社ブログは２０１０年４月２６日からURLを変更いたしました。
ブックマークやRSSで登録されている方は、下記URLへ変更願います。 http://www.conit.co.jp/blog/ 今後とも宜しくお願い申し上げます。 ２０１０年４月２６日 株式会社コニット |
|
|
2010,03,31, Wednesday
 こんにちは。橋本です。 プロ野球オタクの私ですが、『プロ野球の情報配信をしたい』という長年の夢が叶いました！ こんなモバイルアプリが欲しいという長年の思いを全てぶつけたアプリです。 1. 試合の速報を一度に確認することが出来ます。  2. 各試合の詳細ももちろん確認できます。  3. ニッカンさんの冠が付いているように、ニッカンさんの記事を選んで読むことができます。  4. 順位表はいつでも確認できますし、各チーム毎の盗塁数や本塁打数、防御率なども分かるようになっています。  5. 個人成績だって、全て確認できます。各項目ごとにソートすることも可能なので、現在の盗塁王、ハーラーダービーなど、ファンなら知りたい情報はいつでも確認できます。  6. チームごとの日程表が確認できます。通常、日程表は全チームの情報が載っていますが、このアプリでは、自分が日程を知りたいチームを選べば、そのチームだけの日程が確認できます。そのチームの月間勝敗数も一目で分かります。  7. チームごとのメンバー一覧が確認できます。試合を観戦にいった際、知らない選手が登場することが良くありますね。そんな時は、このアプリで背番号から誰なのか分かります。  これからもどんどんアップデートしますので、ご愛顧、何卒よろしくお願いします。 |
 |
|
2010,03,31, Wednesday
こんにちは 阿久津です。
第１回 Google App Engineを使ってみよう！！ 第２回 GAE Datastoreのデータ取得パフォーマンスを検証！！ 今回は、GAEでのデータアップロードについてです。 ■データアップロードを使うシーンについて 色々と考えられると思いますが、以下の辺りではないかと・・・ ・マスタ的に扱うデータモデルのデータを初期登録する ・他の環境で使用していたデータ（mysql,postgre,oracle,sqlserver,db2等）をGAEに移行する ・バックアップしてあったデータをアップする ・パフォーマンステスト用に大量データを投入する 上記に記載した限りではないですが、色々なシーンで活用できるこの機能は、覚えておいた方が便利だと思います。 GAEでのアップロード機能は、至って簡単なものなので実際試してみることをおすすめします！！ ではでは、以下より実際にデータアップロードするための手順をご紹介します。 ■事前準備 ・まずは、app.yamlに「remote_api」の設定を行います。 - url: /remote_api で、アプリケーションの更新処理を行います。 $ appcfg.py update ■データ準備 今回は、前回から使用しているUserモデルにデータをアップロードすることを考えていますので awkなどを使って以下の形式のデータを10万行用意してみました。 サンプル：$awk 'BEGIN{OFS =","; for (i =1; i <= 100000; i++) print("xxx" i,"id" i,"name" i);}' > user.csv ■ローダクラスの作成 以下のようなソースを作成します。（モデルクラスは、インポートするとうまくいかなかったのでこのソースに定義してます。） from google.appengine.ext import db ■実行 ＄appcfg.py upload_data --config_file=UserLoader.py --filename=user.csv --kind=User . (最後のドットは、app.yamlが置いてあるディレクトリを指定してます） ■結果 ちょいと処理はかかるものの無事データアップロードが完了しました。 appcfg.py upload_dataには色々とオプションがあるので、google aap engine documentを参考に設定を変えて試してみるのも よいと思います。 ■次回 アップロードが出来たので次回は、ダウンロードについてお話したいと思います
| http://www.conit.co.jp/labs/index.php?e=323 |
| Google App Engine | 04:05 PM | comments (0) | trackback (0) | |
| |
|
2010,03,31, Wednesday
Hi everyone, David here.
I'll be the first to admit that I'm no Flash expert. This is a trick which was taught to me just the other day, a trick so simple I felt stupid for not knowing it! Anyway, if you want to import AI images into Flash, here's the best way to do it. I did it on a Mac, but it should work for a PC as well. Step 1: Drag and drop the AI file onto the stage. This will work even if you don't have AI installed. Step 2: A window will appear, asking which AI layers you'd like to import. Pick the layers you'd like to import and click "OK". Step 3: The image will be imported in it's native AI state. Left as-is, this will eat up the performance of your Flash. To avoid this, select everything imported from Flash, right-click, and choose "break apart". Repeat this process a few times until everything is "broken apart".  That's it! You now have an image originally created in AI in native Flash. |
| |
|
2010,03,25, Thursday
こんにちは、中島です。
「放送とネットの融合」という言葉は、いつ頃から言われているのでしょうか。おそらく、2005年頃ホリエモンがニッポン放送の株を買って何かしようとしていた時、「ネットの勢いが放送を飲み込もうとしている」という脅威？がニュースなどで報道され、その頃からかな？という気がします。放送＝旧メディア・年寄り・権力・資金、ネット＝新メディア・若手・自由・安価、といったイメージも、その頃から徐々に現実味を帯びてきていたのではないかと思います。 放送は知っての通り、大きく分けてテレビとラジオがあります。電波を利用してコンテンツを流すのが放送です。放送をするには電波法に則り、放送局の免許を取得することが必要ですので、一般人には手が出せません。対してネットは誰でもすぐにコンテンツを配信できるため、すぐにでも「ネット放送局」を作ることができます。 ここ数年で急速にブロードバンド環境が普及したということもあり、電波を使った放送をそのままネットでストリームすることは、技術的には何ら難しいことではなくなりました。 ではなぜ、元来無料で放送されている民放が、ネットで同タイミングでストリームされないのでしょうか？ これには様々な理由が考えられるのですが、一番の障壁となっているのは、地方局のコンテンツが完全にスルーされてしまうことだと言われています。 電波というのは、届く範囲が限られていますので、地上波においては東京の日本テレビを大阪で受信することはできません。逆に大阪の毎日放送を横浜で受信することもできません。この性質を利用し、大阪の毎日放送には大阪にある色んなローカル企業やローカル商店のCMが流されます。横浜もまたしかりです。大阪の人が大阪で消費活動をするための告知は、大阪という小範囲で十分なのですね。これが完全にネットのストリーミングでグローバルになってしまうと、在京のキー局から配信される番組を全国のみんなが見るようになり、そこにはローカルな情報は無くなってしまいます。そして今までキー局の番組を買って流していたローカルなテレビ局は意味が無くなってしまい、商売にならなくなるということです。 その他、ネットというよく分からない世界にコンテンツを流すことで権利問題が発生しないのか？や、視聴率調査はどうするんだ？ということ、そもそものネットというものへの不信感？が、強くあると言われています。 そういった様々な問題はテレビ・ラジオと共通なのですが、ことラジオに関して、先日大きな進歩がありました。電波放送とネットストリームを完全に同一の内容として放送する「サイマル放送」が、ついに合法的な形で試験開始したのです。それがこの「radiko.jp」(ラジコドットジェーピー)です。  誰でもブラウザから簡単にラジオを聞くことができますが、アクセスしたIPのある地方からエリアを割り出し、そのエリア内でしか聞けないという制限があります。 試聴可能地区：東京都、神奈川県、千葉県、埼玉県 TBSラジオ 文化放送 ニッポン放送 Inter FM TOKYO FM J-WAVE ラジオNIKKEI 試聴可能地区：大阪府、京都府、兵庫県、奈良県 ABCラジオ MBSラジオ ラジオ大阪 FM COCOLO FM802 FM OSAKA IPに地域の情報を割り振ることにより、広告収入で成り立っているローカル局を守ることが出来ている、という仕組みなのですね。 放送の音質はMP3にして64kbpsか96kbpsくらいですので、何ら問題ないです。FMはほぼそのままの音質ですが、AMについては元がノイズだらけなので、驚異的に音質が良くなったように聞こえます(笑) これまでその音質の差がコンテンツの差、雰囲気の差となり、「この番組はAM向き」とか「FMはオシャレ」とかみたいな区別が何となくあり、汚いノイズの中で結構エグくて強烈な笑いを追求するような番組がAMには多いわけですが、それが無菌室のような音質になったとき、コンテンツにどのような変化が訪れるのか、気になるところです。 ただ個人的にはやはり、地方に住んでいてもJ-WAVEの「GROOVE LINE」や、TBSの「ウイークエンドシャッフル」が聞きたいですよね。広告の問題があると思いますが、わざわざ聞く人を減らすことにテクノロジーを投入しなくても良いように思います。ネットの中でくらい自由に聞けるようになればいいのになぁ、と思う次第ですね。 |
| |
|
2010,03,24, Wednesday
こんにちは。高浦です。
最近UIWebViewを使う機会が多くなってきているんですが、UITextViewなら簡単にできるけどUIWebViewじゃ出来ないことに突き当たることがあります。 たとえば、選択した部分の文字列を取りたい場合があります。 UITextViewなら - (void)textViewDidChangeSelection:(UITextView *)textView; というメソッドと、 selectedRange プロパティを組み合わせて - (void)textViewDidChangeSelection:(UITextView *)textView{ NSLog(@"%@",[textView.text substringWithRange:textView.selectedRange]); } とやれば選択したテキストをログに出力してくれます。 ところがUIWebView.hを見てみてもにはそんな便利なメソッドもプロパティも見当たりません。 それじゃあどうしようか？？？ UIWebViewにはJavaScriptの命令を実行する - (NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script; というメソッドがありますのでこれを使いましょう。 NSLog(@"%@",[webView stringByEvaluatingJavaScriptFromString:@"(window.getSelection()).toString()"]); はい、たったこれだけでUIWebView上で選択した文字列がログに出力されます。 webページを見つつ、文字を選択して辞書検索をしようなんて思ったときには便利です。 JavaScriptを使えば他にも任意の場所に自動的にスクロールしたりするようなことも出来ます。 UIWebView+JavaScript、いろいろ面白いことが出来そうです。
| http://www.conit.co.jp/labs/index.php?e=320 |
| iPhone | 09:25 PM | comments (0) | trackback (0) | |
| |
|
2010,03,24, Wednesday
最近iPhoneの為に「eneloop mobile booster」と「Pocket WiFi」を買ってしまいました。
開発チーム佐々木です。 今回は最近の考えている事ですが、営利目的の団体に属する以上 「商品が売れるには？」 という一言だけど、究極の目的がありますね。 自分なりの考察結果ですが、これまた一言で 売れる物は、「心を揺さぶられるもの」 今のところそういう結論に至っています。 揺さぶるというのは、いろいろあります。 ・美しい！ ・便利！ ・美味しい！ ・キレイ！ ・かっこいい！ ・面白い！ ・楽しい！ 商品やサービスと接触した時に、このような感情の言葉となり得る物。 そういう時に、お金を払ってもいいかなと思いますね。 上段で「心を揺さぶられるもの」と書いていますが、その他に揺さぶられる事はありませんか？ まだまだありますよね。 ・怖い ・恐ろしい ・痛い ・悲しい ・つらい ・みじめ こういう負の方向へ揺さぶられる際にも、たいていお金を払ってもいいかなと思いますね。 保険だったり、教材だったり、ストレス解消だったりします。 何にしても、”売る”為には、感情を揺さぶらないとダメよ！！ ってことですね。 |
| |
|
2010,03,18, Thursday
こんにちは 阿久津です。
前回に続きGAEネタです。 今回は、前回GAEに登録したデータストアのUserエンティティを使用して 検索について調査した結果をご報告します。 (11万件くらい登録されています） 今回もpythonです。 ■pythonでの検索方法については、以下３つがあります（まだあるかもしれませんが・・・) ・Queryインタフェースを使用した検索 ・GQLQueryインタフェースを使用した検索 ・エンティティのID or Name 識別子を使用した検索 詳細は、google app engineのドキュメントを参照ください。 ■各検索時のパフォーマンス on GAE Userモデルより、ある特定のエンティティを３回実行しその平均値を 算出してみました。 ・Query ■ queryのfilter()を使用して検索してみた結果 ・1回目：0.1s ・2回目：0.1s ・3回目：0.01s Avg : 0.07 ・GQLQuery ■ gqlはこんな感じselect * from Iuser where userid = :1で検索してみた結果 ・1回目：0.2s ・2回目：0.2s ・3回目：0.01s Avg : 0.13 ・識別子 ■ User.get_by_key_name()を使用して検索してみた結果 ・1回目：0.08s ・2回目：0.01s ・3回目：0.01s Avg : 0.03 ■総括 query,gql,識別子での検索結果は、ほぼパフォーマンスの差はないと感じました。 ただ平均的にレスが早い、idやkey_nameを使用して検索する方が良いでしょうね。 そのほか、インデックスもありますがこちらも今後実験していきたいと思います。 ■次回 GAEのデータアップロードについてお話したいと思います。
| http://www.conit.co.jp/labs/index.php?e=318 |
| Google App Engine | 12:02 PM | comments (0) | trackback (0) | |
| |
|
2010,03,17, Wednesday
こんにちは、いちかわです。
3/11に開催されたgoogle主催のDevFest 2010 Japan に参加してきました。 このイベントは、googleが開催するイベントの中では、 ・Google I/O ・Google Developer Day ・Google DevFest と、3番目に規模の大きいイベントとのこと。 イベント名にJapanと書かれるぐらいだから世界中で行われているのかとググってみたら、インド、メキシコ （探せばもっとあるのかもしれない）でも開催されたみたいですね。 日本で行われたのは初めてらしく、募集から実際の運営まで色々と大変だったみたいです。 （苦労話は書かれていませんが、開催者のブログ） 今まで参加してきた他のイベントと違って募集の所からいろいろな工夫がありました。 参加できる資格を得るには、先着？名でも、紹介された人だけでもなく、クイズに答えて点数が良かった人が選ばれるとか、技術者心をくすぐる方法でした。 クイズ自体も、簡単な物から実際にプログラムを書かなければならないものなど、いろいろな種類が用意されていました。 そんなわけでコニットでは、応募した二人が（私を含め）参加しました。 場所は汐留という事で、先日迷子になったばかりの場所で多少の不安がありましたが、まんまと迷子に。。。 本日予定されているプログラムは手書きだったり、手作り感が漂うイベントです。  会場に入ってみるとすでにすごい人数。最終的には400人ぐらいの参加者があったそうです。 真ん中ら辺に座り、イベントが始まるのを待ちます。  仕事で最後まで参加できなかったため、自分が参加したセッションは3つ。 ・たのしい Android： カスタム UI でAndroid アプリにワクワク感を加えよう ・Google App Engine - 分散クラウドコンピューティングの新しいパラダイム / リアルタイムソーシャルアプリケーション開発 ・モバイルマッピング: Google Maps を利用した様々なモバイルマッピングの手法 どれも興味深く聞かせて頂きました。 しかし、このイベントのさらに良いところは、オフィスアワーというのが設けられており、各セッションのスピーカーや、googleエキスパートの人に直接話ができるという事です。 mixi向けのアプリでgoogle app engineを使っているわけですが、分からない事もありましたので直接GAE中の人に相談をしました。 GAE中の人は非常に親切で、イベント後も引き続き相談させて頂いています。 話を聞くだけではなく、このように相談できる機会を与えてくれるイベントは本当に助かります。 短い時間でしたが、色々と楽しませて頂きました。 ちなみに、汐留駅から離れた場所だったので、近くに食事を取るところがありません。 そんなわけで、会場内の弁当屋は大盛況。  googleが用意する弁当はどんなもの？？と勝手に妄想しましたが、何種類か用意してあったうちのエビフライハンバーグ弁当を食べました。 セッションを聞きながら弁当を食べれるという、フランクな感じが良かったです。 |
| |
|
2010,03,16, Tuesday
こんにちは。橋本です。
下記の通り、ソーシャルアプリの開発者向け勉強会を開催します！ 奮って応募頂けると幸いです。 ------------------------- （タイトル） 第1回 オープンソーシャル開発者勉強会 （日時/場所） ・3月26日19:00～ 東京都渋谷区桜丘町26番1号 セルリアンタワー11F GMOインターネット株式会社 会議室 （参加資格） ・オープンソーシャルアプリを開発したことがある。 または、しようとしている。 ・オープンソーシャルの基本的な概念を理解している。 （募集人数） ・20名程度 ・参加者多数の場合、抽選とさせていただくことがあります。 （応募方法） 下記URLより、登録を行って下さい。 http://spreadsheets.google.com/viewform?formkey=dDRabHBleTRKanJvaHN4Y0JtTHpLVHc6MA （第1回勉強会テーマ） ・オープンソーシャルのサーバの選び方（クラウド？、非クラウド？）と、設計方法 （内容） ・カンバセーション 1h 参加者全員で、お互いの意見を交換しあう ・FAQ 1h よういちろうさん、ZIGOROuさん、その他エキスパートに 直接質問する。 ・交流会 2h 近くの居酒屋で。3000円/人程度。 （ゲスト） mixi よういちろう氏 DeNA ZIGOROu氏 （参加費） 無料 |
| |
|
2010,03,16, Tuesday
Mixi Mobile and Google App Engine: Some Lessons Learned
Hi everyone, David here again. I've been living and breathing Mixi Mobile and Google App Engine for over a month now. I have 1 Mixi Mobile game under my belt (well, 2 if you count 動物落下中), and I thought I'd share some key learnings. I tend to be the kind of guy that jumps into things head first, without really appreciating the consequences, and often without thinking beyond the next 2-3 steps. (Maybe that's why I can't get any better at "go", the Chinese strategy game). This has caused me and the team here some undue pain. If you are developing a game for Mixi Mobile on Google App Engine, hopefully you will have the foresight and wisdom to avoid the problems I encountered. If not, perhaps these notes will help. Lesson #1: Expect lots of users This ain't Facebook, and this ain't the App Store. Due to the (as of yet) small pool of Mixi Mobile developers, individual apps generate a lot more traffic than, say, your run-of-the-mill Facebook app. By virtue of just appearing in the "New Apps" section of the mobile site, you will get a tremendous amount of traffic. That makes Mixi Mobile an exciting place to be, but you need to take traffic issues seriously. Take a look at the number of users of apps that have appeared in the new app listing for 1, 2, and 3 days to get a feel for the traffic you can expect. Lesson #2: Prepare for the worst Being a naive, newbie Google App Engine user, I didn't anticipate some of the strange issues that come with GAE. Even if you pay to increase limits on CPU usage and datastore space, you app still has limits. In particular, be careful to know the number of simultaneous requests that your app can handle before Google disables it. That's right: Google disables your app if it's performance is too poor. Google says a typical app can have up to 500 simultaneous requests per second, but that assumes an average page request takes just 75 API. Unless you're some superstar engineer, your app will probably have poorer performance than that. If you're like me, your app will have MUCH poorer performance than that. So here is a checklist of things to do before release. -Prepare a "maintenance" version of your app, in case things go bad. The maintenance version shouldn't have any datastore or memcache reads, just a static page (or a fun little flash game like ours :) As you should know, Mixi Mobile will put your app in "JOIN停止" mode if it discovers your app is returning bad pages to its users. That means your app won't be listed in the "New Apps" section: a death sentence for up-and-coming apps. -Given your app's average CPU performance, figure out the max simultaneous requests per second. Should your app start to go over that limit, be prepared to switch it to the "maintenance" version. (thus avoiding the JOIN停止) -Take the time to tune your app's performance! This isn't just something that good engineers do. With other platforms, apps may start to get slow with poor CPU usage, but with GAE your app will be disabled! Read up on Google's site for how to optimize your datastore. Minimize the puts to your datastore and use memcache wherever possible. -Throw exceptions wherever possible. Again, having an "error found" page is way better than returning a server error directly to the user (and avoids the risk of the mixi mafia closing down your app). Trust me, thousands of users will find all kinds of problems with your app that no amount of testing will prepare you for. Lesson #3: Knowledge is power Google App Engine is a great tool for communicating the state of your app. When your app throws exceptions, show a detailed log. Make use of appstats to monitor page performance. And keep a running counter of new/active users, and anything else that may provide details about how your users are engaging your app. Lesson #4: First impressions are everything You may be debating when to release your app. It's the speed vs. functionality quandary that haunts all of us engineers. I take the position that speed is life, and I prefer to take risks over waiting yet another week for a release. That being said, because new Mixi Mobile apps appear on the "New Apps" list for a limited time, it is critical that your app succeed in that short time. Be ready. Prepare a community site for users to post questions and suggest ways to improve. Be sure you are making use of the Mixi social API to pump up the virality. Understand what makes successful social games, and make sure your app is following the same equations. Implement the game plan for how you will generate revenue as soon as possible. And at the very least, make sure your app doesn't crash in it's opening days. Lesson #5: One step at a time When I read blogs like this, and hear advice from others, and listen to feedback from my users, and listen to what "needs to be done" from the powers-that-be, I often end up feeling overwhelmed and hopeless. If I can pitch in my 2 cents: one step at a time. As you are ultimately the one developing the app, you have the final say as to what gets implemented. There is going to be way too much work for you to handle, so just stick to the priorities. And when you consider priorities, remember that the boring, backend stuff is often times more important than adding some new feature or improving the UI. Because what good is an app if it can't even open?
| http://www.conit.co.jp/labs/index.php?e=315 |
| Google App Engine | 03:41 PM | comments (0) | trackback (0) | |
| |
