 |
|
|
| |
|
弊社ブログは２０１０年４月２６日からURLを変更いたしました。
ブックマークやRSSで登録されている方は、下記URLへ変更願います。 http://www.conit.co.jp/blog/ 今後とも宜しくお願い申し上げます。 ２０１０年４月２６日 株式会社コニット |
|
|
2010,02,26, Friday
こんにちは、中島です。
このページ「CONIT Labs」は名前こそ「ラボ」ですが、毎日何か研究しているわけでもないので、いわゆる企業ブログというものです。(え、そうだよね？＞社内) 基本的に、スタッフ全員で毎日持ち回りで書くようにしており、「ブログの日」と書かれた汚い段ボール製のバトンみたいなのがスケジュール通りに机の上に置かれたら、その人の番です。だいたい10人くらいで回しているので、書くのは月に２回くらいです。 書きたいときに書きたいタイミングで書くのではなく、当番制で回ってくるものなので、それまでにネタを仕込んでおかないと、毎日の業務に追われて面倒くさいことになります。企業ブログを書いている会社なら、ありがちなパターンかな、と思います。ここで、原点に戻ってみましょう。 何を書くか。何だかんだ言ってもこれが一番重要なのです。ブログを書く意味をみんなである程度共有しておく必要があります。 一応会社のブログなので、個人的すぎることを書かれても読む人が困ります。「うちの猫ちゃんが可愛くて  」とか。知らんがな、という感じですね。とはいえ、「今日は○○の案件を５時間かけ、打ち合わせに２時間でした」みたいな業務報告を書くのも違いますね。知らんがな、です。ブログは社内ツールではなく、ある意味会社の顔であり、最新情報・会社としての思いや考え方・役に立ったり面白かったりする知識やヒントなど、どこかで会社業務と繋がっていて、かつ外部の人が読んで面白い・勉強になる、などと思える物を心がけるのが良いと思っています。 わざわざコニットのページまで来て頂いて、このブログをRSSリーダーに登録して頂いている方々もいらっしゃいます。Googleがインデックスし、何かの拍子でたまたまこのブログに来たという方々もいらっしゃいます。 我々としては、まず世の中の役に立ちたい、思いを伝えたい、というのがあり、それが後々出会いを生み、何かに発展していくということはよくあります。 ので！ ブログをみんながサボりがちだった時期もありますが、忙しいのは当たり前なので、ここらで心機一転、このブログを回していきたいと思います。 コメントなども頂けると大変励みになります！ |
 |
|
2010,02,25, Thursday
こんにちは、開発チーム佐々木です。
MIXI家の萌香たん弊社にも欲しいです。 http://alpha.mixi.co.jp/blog/?p=386 ツンデレも良いですが、個人的にデレツンってのがあっても良いかなと思ったりしてます。 よくある話ですが、サービスレベルアグリーメント（SLA）で99.9はどういう事かという話です。 昨晩GoogleAppEngine様が停電で停止していました。 丁度、運用中のサービスを監視中だったのでビックリしてしまいましたが、 ２〜３時間停止ってことはどうなのか？ サーバというものは人間の代わりに２４時間３６５日働いてくれる素晴らしいリソースです。 ２４時間＊３６５日＝８７６０時間 マイクロソフトのクラウドと、アマゾンのクラウドでは、SLAで99.9%の稼働をうたっています。 ８７６０時間＊０．００１＝８．７６時間 この場合は年間で８．７６時間はサーバーが処理不能になる事を覚悟しなければなりません。 非常に少ない時間ですけどね。 （ただし、それ以上の時間ダウンしても払い戻しがあるだけです。業務へのインパクトは取り返せません） 安定したサービスを提供するには、相応のコストが掛かります。 クラウドサービスであそこが高い、ここが安いとかありますが、 値段だけを見るのではなく、稼働時間SLAとの兼ね合いで見るべきで、 高い安いは理由があります。 そこで弊社で使わせてもらっている、AmazonとGAEはどうかというと、 Amazonは半年以上使わせて貰っていますが、未だにトラブルは発生していません。 GAEは使い始めて１ヶ月もしないうちに、数時間のダウンが発生しています。 特にSLAは無いようなので、いくらサーバがダウンしても文句は言えないのです。 お金は貰うけど落ちたら頑張るから〜といった、日本的にいうと、なぁなぁな関係とでもいいますか。 安いには安い理由があるって事ですよ。 それで困るようなシステムを構築してはいけません。 |
| |
|
2010,02,24, Wednesday
----------------------------------------------
高橋大輔選手、銅メダルおめでとう！  安藤美姫選手、鈴木明子選手、浅田真央選手頑張れ！  ----------------------------------------------  こんにちは。フィギュアスケートオタクの橋本です。 先日のブログエントリーで、フィギュアスケートオタクであることを公開して以降、 フィギュアスケートで検索してこのサイトに辿り着く人がものすごい勢いで増えています。（笑） 高橋大輔選手の銅メダルの表彰式は、本人以上に涙が溢れ、止まりませんでしたよ。 4回転トゥーループの失敗は残念でしたが、表現力ではピカイチでした。豊かな顔の表情は、是非他の選手にも見習って欲しい点です。 プルシェンコ選手が、4回転を跳ばずして金メダルを取ったライサチェック選手と、採点者を避難していましたが、 軸がぶれるなど、細かいミスを連発したプルシェンコ選手が負けていたと思います。ジャンプの競技ではないので、当然です。 女子も、今日まさにSPが終了し、キム・ヨナ選手が一位に立っていますね。演技を観ましたが、表現力が非常に豊かでした。 明らかに、歴史上最強の女子フィギュアスケート選手だと思います。 それに対し浅田真央選手は、トリプルアクセルは成功させ、ノンミスだったものの、表現力ではキム選手に劣っていました。 表現力というのはあまり失敗する要素が無いのに、ジャンプの場合失敗すると大減点につながるので、 浅田真央が不利だと思っています。2回のトリプルアクセルを成功させ、ノンミスであればいい勝負はできますが。 もちろん、私自身は浅田選手を応援していますから、明後日のフリーは、ノンミスかつ、最高の演技を見せて欲しいです。 そんなフィギュアスケートオタクの私が、今回「フィギュアスケートの星」というmixiアプリモバイルを企画しました！ あなたがコーチとなって、フィギュアスケートの選手を育て、ビギナーからオリンピック選手になるまで育成するゲームです。 操作は簡単です。画面から、練習メニューや、大会を選択して、あとはクリックしていくだけ。  練習・大会では、タイミングよく決定ボタンをクリックすれば、素晴らしいジャンプやスピンができ、どんどんポイントを増やすことができます。 是非一度、試してみてください！ |
| |
|
2010,02,24, Wednesday
こんにちは、岩田です。
今日は、今後のスマートフォンのアプリはすべてWebアプリになるのでは、と結構前からいわれていますが、 実際に今どこまでいっているのか、簡単にしらべてみました。 もちろん最終の段階では各キャリアや端末の種類に問わず、１つのアプリを作成したら全ての端末で動作することだと 思いますが、現状ではどうなっているのか、またはどういったWebアプリ作成のためのプラットフォームがあるのか 調べてみました。 iPhoneのWebアプリ iPhone用のJavaScriptインターフェイス http://www.davidcann.com/iphone/ このページにあるiPhoneの画面はjavaScriptとPHPで出来ています。 まー普通ですね。 Big5 こちらも似たようなものですね。 前座はこれまでにして、本命はこちらの２つでしょうか  appcelerator Titaniumという名前で、どんなことができるかはこちらを見てください。 こちら http://vimeo.com/8473513 オープンソースの凄いやつ PhoneGap webだけでなくNativeアプリもjavascriptから叩けるので、Camera, 加速度センサなども使用できます。 そして、iPhoneだけでなく、Androidなども対応しているらしいです。 appceleratorは有償でPhoneGapはオープンソースです。 まだまだ、発展途中な感じでどんどんアップデートされていくと思いますが、注目したいと思いました。 やはり、日本ではパットしたものはありませんでした。 本当は後追いではなく、今後に向けてサービスを生み出していきたいのですが。 技術的な押さえどころは、特にHTML5とwebkitで、javaScriptとCSSもという感じでしょうか。 まーいろいろと勉強しておきたいところです。
| http://www.conit.co.jp/labs/index.php?e=303 |
| iPhone | 05:14 PM | comments (1) | trackback (0) | |
| |
|
2010,02,21, Sunday
海外の記事の翻訳記事へのリンクです。
http://www.aoky.net/articles/jeff_atwood/top_6_list_of_programming_top_10_lists.htm いくつか転載。オリジナルは↑のリンクです。 ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣ 1. 自分が誤りを犯すということを理解し、受け入れること 。 2. 自分と自分のコードは別物である。 3. どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 4. 相談せずにコードの書き直 しをしない。 5. 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 6. 世界で唯一変わらないのは変わるということだけ。 7. 唯一本当の権威は、地位ではなく知識より生ずる。 8. 自分で正しいと思うことのために戦うこと。しかし負けは潔く認めること。 9. ｢部屋に籠りきりのやつ｣にはなるな 。 10. 人ではなくコードを批判すること——コーダーには優しく、コードには厳しく。 デア・オバサンジョの｢ソフトウェアプロジェクト失敗の10の兆候｣ 1. 最初のバージョンであまりに多くのことをやろうとする。 2. 確立されていないテクノロジーに大きく依存している。 3. 稼ぎ頭だったり強力な後ろ盾を持っていたりする別な社内プロジェクトと競合している。 4. チームが人員不足。 5. ｢複雑な問題には複雑な解法が必要｣ [ 複雑さ自体がプロジェクトのゴールになる。] 6. スケジュールチキン [ 悪いニュースを伝えることを恐れる。] 7. スコープクリープ [ スケジュールは変わらずに要件が膨らんでいく。] 8. 第2のシステムシンドローム [ 比較的小さい成功したシステムの後継システムが、機能満載の肥大化したシステムになる傾向があること。] 9. 参入戦略がない。 10. 解き方を知らない問題に取り組んでいる。 |
| |
|
2010,02,18, Thursday
Hi everyone, David here.
As development continues on my Mixi game, I've been liking Google App Engine more and more. Before starting, one complaint I heard was that it is hard to adjust to the Google App Engine "datastore". Unlike SQL, the datastore is a "schemaless" framework, which stores instances of classes instead of rows in a table. You can run queries, but the queries are a bit limited. For example, you can't have more than one "greater than/less than" sign in your query. You also can't sort on fields that aren't specified in the WHERE clause of your query. It was a bit strange adjusting for me to, but I'm really starting to like it now. GAE has a very robust logging system that lets you track CPU time. Since you are mostly charged for CPU time, and pages with high CPU can actually become blocked, it is vital to tweak your queries to maximize efficiency. In typical SQL environments, performance always took a back seat to just getting the code to work. Now, I really have to be diligent about how I structure my data, how information is queried, and how it is managed. I like being in control of the cost of my app, and the adventure in finding inefficiencies in my code. Another concern with the datastore is that the data are hard to export, backup, and restore. I couldn't disagree more. With the remote api, you can do all kinds of things with your data, including exporting it to Excel, migrating it to a development server, and updating/restoring entire datastores. Here's all the info you need. http://code.google.com/appengine/articles/remote_api.html As I continue to hack away, I'll keep posting to this blog on any other learnings. Until then, happy coding. -David
| http://www.conit.co.jp/labs/index.php?e=301 |
| Python | 12:30 AM | comments (0) | trackback (0) | |
| |
|
2010,02,16, Tuesday
こんにちは。橋本です。
とうとう、マイマシンを高速なWindows7 64bit版にし、業務効率を上がりそうな今日この頃です。 弊社コニットでは、自社アプリの企画～開発や、クライアント向けの開発を行っています。 スタートの際、
のどちらかになることがほとんどです。 前者は、アプリの企画自体を、『企画・マーケティング担当者』が作った場合にありがちで、 後者は、システム開発者が作った場合にありがちです。 特にどちらが良いとか悪いとかはないのですが、今までの経験上、一般的に以下のような 結果になることが多いと感じています。
必ずしも、上記のとおりになるわけではないですが、なりがちなので、企画する際は気をつけて行うようしています。 みなさんもぜひこの辺りを念頭に置きつつ企画されてみてはいかがでしょうか？ |
| |
|
2010,02,12, Friday
こんにちは、中島です。
今日は、弊社新サービス「EatNow」について、企画者という立場から企画の意図などについて、書きたいと思います。 まずEatNowというサービスですが、一言で言うと「食を通じたリアルタイムなコミュニケーション」です。毎日、食事を写真や位置情報と共に記録し、友達と共有するというものです。ブログほど情報が重くなく、かなり気軽にホイホイとアップロードするコンセプトです。友達がアップロードしたものは、即座に確認することができます。 EatNowはFacebookのアプリが中心にあり、Facebookのソーシャルグラフを利用します。クライアントとしてFacebook connectができるiPhoneとAndroidのアプリケーションを用意し、接続します。  Facebookアプリケーション  iPhone版タイムライン  iPhone版詳細画面 アップロードした食事情報は「Eat」と呼んでいて、EatNowのDBに格納され、Facebookのアプリを中心に、FacebookのWall、Twitterへの投稿なども同時に行え、ちょっとしたバズが発生する仕組みとなっています。 このサービスを使い続けることで、個人としては毎日の食事がログとなり、集合としては地図上にてどんな食事がどの場所で摂られたかを俯瞰して見ることが出来ます。Facebookなので全世界的に食事マップを俯瞰することができます。そして、ただアップロードして友達のを見るだけではなく、アップロード数や「美味しい！」ボタンを押された数などによってポイントが貯まり、表彰され、ランキングに食い込んだりすることが出来ます。 以上がEatNowの簡単なサービス概要となるのですが、自分がこのサービスを思いついたのは何年か前となります。 2005年くらいから、毎日の食事を携帯のカメラでアップしていくだけというブログを始めました。 大食漢ですわ 携帯のカメラが本格的な品質になってきたこと、3Gが普及してパケ放題が当たり前になってきたことで数十キロバイトもある写真を外から気軽にネットにアップロードできるようになったこと、ブログが普及し、携帯からの投稿機能も整ってきたことなどが良いタイミングとなりました。 ただ、この頃は食事をいちいち写真で記録している事は結構奇特な目で見られました。誰に見せるのだ、そんなことやってどうする、という感じで、完全に「暇人」扱いです(笑) mixiはありましたが、こんな情報ばかりアップロードしているととたんにマイミクに嫌われる…という、「濃いつながり」の空間だったので、食事写真は一人でこそこそやっていたわけです。 これを何ヶ月、何年か続けているうちに、ライフログとしての面白さに気づきました。食べ物のカテゴリ別に分けていたので、自分がどんなカテゴリの食べ物を食べているかが一気に分かるのです。中華や揚げ物、カレー、が異様に多かったので、ブログを見た友人からは「そのうち死ぬよ？」と忠告されたりもしました(笑) でもログ取ったらみんなロクな食事してないと思うのですけどね。 そして2005年といえば、食事記録シーンに大きなマイルストーンが訪れました。あの発明家のドクター中松先生が、「食事を35年間記録し続ける」という偉業で、イグノーベル賞を受賞したのです。これを偉業と呼ばず何と言いましょう。栄養学的な見地からの食事記録ですが、目的が何であれ、食事を記録するという行為において世界一というわけです。  ドクター中松先生 自分の場合は栄養学でも何でもなく、「盛りつけられた食事は美しいが、箸を付けられる前の一瞬しか無くはかないから記録しよう」という目的でした。情報的には箸にも棒にもかからないジャンクなものですが、「何か楽しい」のです。繰り返される日常の中で唯一変化し続け、人畜無害であり、毎日必ず訪れる、という普遍性が、食事の写真を撮ることに繋がっていました。 一方その頃、「アスクユー」というグルメ系CGMサービスの企画運営という仕事に従事しており、自分よりも全然本格的でグルメな方々が、何を思い、何を探し、何が楽しいのか？を日々研究する毎日でした。本当にグルメな方々というのは食事、そして食事をする環境まで全てを一種の芸術として捉えておられることが多く、長文で熱のこもったグルメ評をいくつも目に触れました。新規機能を考えるときにもユーザー目線で考えることによって、食事を摂るとはどういう事か？まで立ち返ることが基本でした。 「アスクユー」、そして現在大人気の「食べログ」も、基本はグルメ好きによるグルメ好きのためのサイトであり、レビュアーがキチンとレビューを書くこと、そしてそれが大勢の読者に向けて有効なガイドとして機能すること、がCGMを回していく２大エンジンです。 しかし実際は、その熱のこもった長文レビューにレビューを書くことへの壁を感じてしまう人も多かったり、基本的には１店舗一人１レビューであるため、本当は気に入ったお店は何回も行くのにレビューは１個だけの掲載であったり、と、ガイドなりの性質も持ち合わせています。 ちょうど2007年はTwitterがデビューした年で、「つぶやき」をリアルタイムに友達と共有するというその新しい概念はまだほとんどの人に面白さが理解されずにいましたが、ひょっとしてこれ流行るかも？と一部で注目を集めていました。前述の「アスクユー」でも、Twitterのように何かを食べたらその瞬間にリアルタイムに繋がれる機能があったら面白いね、といったネタを思いつきましたが、さすがにサービスの性格上合わず、アイデアはそのままお蔵入りしました。「それ、あんたのブログやん！」とのツッコミと共に。 それから時がたち、コニットを立ち上げ、iPhoneのアプリを作る時期と同時に、Twitter、そしてFacebookというサービスは猛烈な速度で会員を増やし、成長して行きます。Twitterは静的なブログがメインだったネットに、今何をしているか？というリアルタイム性をもたらしました。Facebookは世界中のユーザーを一気に集め、数々のゲームを友達と一緒に遊ぶというソーシャルゲームで世の中を変えました。 ここで新しいサービスとして、再び「食事を記録する」というアイデアが眠りから覚め、TwitterやFacebookの数々の特性を盛り込むことで、CGMではない「ソーシャルメディア」として具体的に構築を開始しました。 Twitterでは日々何のネタが投稿されているのか？を日々研究していますが、実に「食事」が多いのです。これはTwitpicのPublic Timelineを見れば一目瞭然です。１ページに25個ある写真のうち、多いときは10個、少なくても１個は食事、もとい食べ物の写真がアップされています。つまり前述した通り、繰り返される日常の中で唯一変化し続け、人畜無害であり、毎日必ず訪れる、という普遍性が、食事の写真を撮る行為に繋がり、意味はないけど「何か楽しい」のです。これは世界的に証明されました。結局人類は皆暇人であり、日々そんなに面白い出来事が起こり続ける事なんて無いんです。 そして今、新しい位置ゲー(ゲームなのか？)として、主にiPhoneて「foursquare」が世界的に大ブームを起こしています。  foursquare これまでもモバイル端末から「位置情報＋写真＋友達」といったサービスは多々ありましたが、foursquareはそこに得点、メイヤー、バッヂといったソーシャルゲーム的要素を組み込んだことと、ソーシャルグラフをFacebook、Twitterの両方をシームレスに持てること、優れたUIなどが功を奏したのか、最近一気に広まった感があります。 foursquareで扱っている情報は「誰がどこでチェックインしたか」という情報であり、その情報が集まったところで全く役には立たないわけですが、これで遊ぶ人は何らかのガイドを求めているのでもなく、自分のライフログでもなく、ソーシャルゲームの一環として遊んでいます。意味のない情報でも、友達の情報だったら意味を持つという感じですが、これこそがソーシャルゲームの醍醐味だと思います。昨今のfoursquareのサービスとしての纏まりとその流行には大いに勇気づけられました。 EatNowは「位置情報＋写真＋友達」を基本に、新たに「食」を切り口とし、ソーシャルゲームの醍醐味をプラスしたサービスを目指していきたいと思っており、Twitterのリアルタイム性、Facebookの世界的で巨大なソーシャルグラフとソーシャルゲームの醍醐味、iPhoneやAndroidといったリッチなモバイルデバイスの良さを全て活かしてMIXした物にしたいと考えています。  友達が今からビール飲むようだ！地球の裏側では今こんな物が食われている！という情報に全く意味は無いですが、何か楽しくないですか？ ということで、皆さん是非とも「EatNow」を使ってみてください。きっと楽しいです。 EatNowサイト Facebookアプリ EatNow iPhone版EatNow ダウンロード Android版EatNow ダウンロード |
| |
|
2010,02,10, Wednesday
 iSlateと言うアプリを作ったら審査に通るのでしょうか？ あ、って言うかもうでてるのね。 こんばんは。高浦です。 iPadが発表されて２週間が立ちました。 ここらでiPadに採用された電子書籍のフォーマットであるepubについて触れておこうと思います。 epubは簡単に言えばHTMLや画像などをzipに圧縮して拡張子を.epubに変えただけのものです。なので解凍すればUIWebViewで表示できてしまいます。 ちょっと実験してみましょう。 まずepubファイルの用意ですが、ネットに転がっているサンプルを落としてきてもいいのですが、pdfをepub形式に変換してくれるサービスがあったのでこれを利用したいと思います。 http://epub2go.com どこか適当なwebページにSafariでアクセスしてtest.pdfと言う名前で保存し、epub2go.comにアップロードします。 そうするとepubファイルがダウンロード出来るようになります。 これを適当なフォルダに保存して解凍してみましょう。 ターミナルでunzipコマンドを使うと解凍できます。 $ unzip test.epub すると、 mimetypeファイル .opfファイル .ncxファイル html系のファイル などが出てくると思います。 htmlファイルはそのままブラウザに表示できてしまいます。 その他のファイルには書籍の詳細情報が書かれており、専用のアプリを開発するときにはその中も参照する形になるでしょう。 あとはアップルが新しく展開するiBookStoreという電子書籍のマーケットからダウンロードしたepubファイルにサードパーティ−のアプリからアクセスできるか？と言う話ですが、その辺は現段階では不明です。 残念ながらブロックされてしまうと言う可能性もあるかも、、、 iTunesで購入した音楽ファイルにも最初からアクセスできたわけではありませんでしたね。 |
| |
|
2010,02,09, Tuesday
こんにちは、開発チーム佐々木です。
先程は実のないブログ記事で失礼しました。 ”いちかわ”のブログでもHTML5について記事がありましたが、 わたくしもHTML5関連でひとつ。 ファイルが保存できるテキストエディター（ＨＴＭＬ＋ＪａｖａＳｃｒｉｐｔ） テキスト欄があり、Saveボタン、Loadボタン、Clearボタンがあるだけですが、 大いなる可能性を感じるHTMLです。 記事やソースコードなど、編集中の状態をlocalStorageに保存しておいて、 確認後にサーバーにコミットするなんて使い方も出来ますね。 日をまたいで編集するとかの一時保存の為にサーバーサイドでロジックをくまなくて 良いわけですね。なにかと便利です。 インデント等されませんが、ソースです。（Safariで確認済み）
|
| |
