ブックマーク / satoshi.blogs.com (34)

  • 丸投げ「エンジニアもどき」はGitHubの夢を見るか?

    Facebook のタイムラインに、Wireless Wire News に「海外べて行けるエンジニアべられないエンジニア」という記事が流れて来た。 簡単に言うと、外でもべて行ける人は「自分で手を動かして何かできる人」です。 コーディングできる、設計できる、管理の仕組みを考えられる、コストカットした機材の調達の仕組みを考えられる、人員管理がうまい、プロジェクト管理できる、監査の仕組みやドキュメントを作れる、戦略を作って実行できる、という様な「自分で何かができる」人です。 反対に、「これはべて行けない」という典型例。それは、日国内の大手ベンダやユーザー企業勤務で、下請けや孫請けへの「丸投げ」しかできない「エンジニアもどき」や「SEというなんだか良くわからない仕事をやっている人」「仕事が部長や課長」という人々です。 基的には、私が以前、「ソフトウェアの仕様書は料理レシピに似て

  • node.js モジュール ajmax の公開

    東京Node学園祭2012 アドベントカレンダー 14日目の記事です。イベントの告知の意味も含めて、毎日だれかが1つづつ node.js についてブログで書く、という企画だそうです。 そこで題ですが、github に ajmax という node.js モジュールを公開しました。npm にも登録してあるので、"npm install ajmax" でインストールが可能です。 詳しくは readme ファイルに書いてありますが、英語なので簡単に解説すると、AJAX(eye candy 的な AJAX ではなくて、実際に非同期にデータをサーバーから取得してページの一部をアップデートするタイプの AJAX) を活用した one-page web application を作るための micro MVC framework です。 これまでいくつか AJAX を駆使したアプリを作って来ましたが、

  • node.js と thread hog の話(2)

    [前回までの話へのリンク] ・node.js と thread hog の話(1) 最近になって「c10k 問題」が広く知られるようになったが、実際には、前回書いたように、thread を使いすぎるプログラム(thread hog なプログラム)はスケーラビリティが悪いということは、当時(90年代の終わりごろ)でもすでに「知る人は知る」問題になっていた。 複数のクライアントマシンとの間のソケットを開きっぱなしにしておく、Proxy Server、Chat Server、MMORPG に関わっている人達の間で、ソケット一つに thread を一つ割り当てるスタイルのプログラミングがスケーラビリティに欠けることが知られるようになったのもこのころである。 当時、Microsoft で MSN Messenger を作っている知り合いが「ついに1万人が同時接続しても大丈夫なアーキテクチャに到達した

  • スティーブ・ジョブズに学ぶプレゼンの秘訣

    ベスト・セラー「スティーブ・ジョブズ 驚異のプレゼン」の著者で、Business Week のコラムニストでもある Carmine Gallo が書いた "10 ways to sell your ideas the Steve Jobs Way!" という資料を手に入れたので、簡単に内容を紹介する。 1. 最初は手書きで考えをまとめろ いきなりパワポの資料を作らず、まずは紙やホワイトボードなどで(訳注:neu.Notes+ でももちろんかまわない^^)、プレゼンの大まかな「流れ=ストーリー」を作るべき。つまらないプレゼンでは、観客はすぐに飽きてしまう。語るべき「ストーリー」がないうちにパワポの資料を作っても意味がない。 2. Twitter 向きの短いフレーズを使え Twitter の「口コミ効果」に関しては、いまさら強調するまでもないが、それを最大限に活用するには、140字以内に収まる

  • 組み込みデバイスの開発にこそ必要な「おもてなし設計」

    最近、UIEvolutionのビジネスが、単なる「テクノロジーのライセンス・ビジネス」から、「プロトタイプの構築」や「おもてなし設計」ビジネスにシフトしている。一昔前は、「UIEngineのJavaに対する優位性を説明して欲しい」などの技術的な問い合わせばかりが多かったが、最近は「○○向けのデバイスを作っているんだけど、おもてなしの設計の段階から手伝ってくれないか」という話が増えているのだ。「おもてなし設計」の重要性が業界でようやく理解されて来た兆候だと解釈している。 そこで今日は、そんな傾向をさらに押し進めるために、スマートフォン・タブレット・家電などの組み込みデバイスの開発における「おもてなし設計」の重要性の話。 ここのところ「Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ」「なぜ横並びで展示されるAndroidタブレットを作

  • JavaScript HTMLテンプレートエンジン SNBinder 公開

    先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData(JSON)を結合して HTML を生成するテンプレートエンジン」である。 90年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は(MVC

  • なぜ横並びで展示されるAndroidタブレットを作ってもだめなのか

    先日のエントリー「Androidタブレットはヨドバシカメラの『Androidタブレットコーナー』に横並びにされた時点で負けだ」には、例によって賛否両論のさまざまなフィードバックがよせられたが、否定的な意見の大部分は以下のようなもの。 何故負けなのかがあまりイメージ出来ないなあ。描かれている様子はAndroidが盛況を博しているものにしか見えない。 PCメーカーが「何のためにWintel」と考えてるとは思えないし、スマホやタブレットで「何のためのAndroid」って問いに意味があるとも思わない。 すでにそんな現状の Windows PC でも一定の利益は出ているのだから、Android タブレットも負けではあるまい。 歴史に学ぶとするなら、iPhone/iPadMachintosh だとすれば、Android機はPC/AT互換機なんだと思う。ただ、「Windowsなのでどれも使い勝手は

    なぜ横並びで展示されるAndroidタブレットを作ってもだめなのか
  • Life is beautiful: Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ

    今年のCESについてだが、すでに「感心した商品」と「自分も関係していてうれしかった発表」に関しては書いたので、今回は「これはだめかな」と思ったもの。 まずその筆頭は「3Dテレビ」。これ以上大きくすることも薄くすることも解像度を高くすることもできなくなってしまった「成熟しきった」デバイスであるテレビに何とか付加価値を付けようという気持ちも分からないでもないが、正直言ってこれはいらない。CESに出品されている最新の3Dテレビを見てもあまり感動しないし、そもそも目が疲れる。今年の末あたりになって、「結局3Dテレビって何だったの?」という話になると私は見ている。 二番目は「Android」。前にも書いたが、これから家電やスマートフォンの市場に新規参入しようというアジアのメーカーにとっては、Androidを活用して短い開発期間と低コストで「安かろう悪かろう」のデバイスを薄利多売で売りまくるという戦略

  • Facebookの使い方:実践編

    ではまだまだ普及率は低いが、今年中にも10億人ユーザーに達すると予想されるFacebook。今年の夏前には、「Facebookの使い方」のたぐいのが日屋さんに平積みになっている様子が目に浮かぶ。 単純な「Facebookウェブサイト使い方」は、その手のガイドブックに任せるとして、私がどんな風に使っているかを実例を使って説明しよう。 先日書いた、「ピュアAJAXアーキテクチャのススメ」というエントリーに対して、「BigPipeに似ている」というコメントをTwitter経由でいただいた。そこで調べてみると、「BigPipe: Pipelining web pages for high performance」という論文が見つかった(Facebook内のNoteという仕組みを使って書かれており、誰でもアクセスできる設定になっている)。 読んでみると、私のアプローチとは少し異なるが、そ

  • CESレポート:「おもてなし」アワード2011

    来る予定などなかったのだが、ひょんなことから来る事になったCES。初日の感想に代えて、数多く見た展示物の中で、「これは良い」と感じたもの二つをピックアップする。 1. ベスト・ユーザー・インターフェイス:Samsung i-Function 私自信、Canonのデジカメ一眼レフを使いはじめて2年ほどたつが、操作が面倒で結局使いこなせていないというのが正直なところだ。特に夕焼けのように「今しか撮れない」ショットを撮影しようとした時に、明るさやホワイトバランスを微調整している間にその「魔法の瞬間」が終わってしまう。しかしフルオートではやはり満足のできる写真は撮れない。そんなジレンマをついに解決する「おもてなし」を提供してくれるのが、SamsungのNX11に搭載された i-Function。 i-Functionは、レンズ側にある1つのボタンとリングだけで構成されているのだが、その二つだけで、

    CESレポート:「おもてなし」アワード2011
  • ピュアAJAXアーキテクチャのススメ

    先日、ここで発表したFacebookユーザーむけグループウェア「Fruence.com」。今年のトレンドになるであろう「ソシアル・アプリ」の実例という意味もあったが、私自身の中で少し前から形になりつつあった「AJAXを最大限に活用した新しい形にウェブ・アプリケーション」のアーキテクチャの実践という意味合いも大きい。 このアーキテクチャの特徴は以下の3つである。 サーバー側は、JSON over HTTPのAPIHTML/CSS(およびそのテンプレート)をスタティックな形でのみ提供する(サーバー側では、ダイナミックなHTMLの生成はしない) クライアント側では、JavaScriptを使ってサーバーから取得したJSONとHTMLのテンプレートを組み合わせて(データ・バインドして)表示する。 ウェブサイトはあたかも独立したアプリのように動き、操作中はURLは一切変化しない もともとは、HTML

  • 「ガラパゴス問題」に対する少し前向きな一考察

    昨日の「日のケータイが『ガラパゴス化』した当の理由」には沢山のコメントをいただいたが、その中には、「じゃあ、日はこれからどうすれば良いのか」という質問があったので、私の考えを少し書いてみる。 まず、ケータイやテレビのように消費者向けのデバイスを作るのであれば、世界規模でビジネスをすること以外は考えない方が良い。先のエントリーで書いた通り、日の携帯メーカーは、単に「ソフトウェアの開発能力・デザイン・おもてなし」で負けているだけでなく、ビジネスの規模の違いから、部品の調達コスト・製造コストでAppleに大きく引きはなされているのだ。「悪かろう高かろう」では勝てるわけがない。 もし、日のメーカーがAppleやSamsungと気で戦おうとするのであれば、(1)コスト面での徹底的な合理化をはかり(役員のお抱え運転手を廃止する、年功序列で給料だけが高くなってしまった人たちに辞めてもらう、系

  • プラットフォームとして台頭して来た Facebook

    週末はクリスマス休暇でロスに住む長男が遊びに来ていたのだが、金曜日の朝になって面白そうなFacebookユーザー向けのサービス案を提案して来たので、さっそく作ってみた。24日にはクリスマスパーティもあったし、テニスも毎朝していたので、正味プログラミングをしていた時間は30時間ぐらいしかなかったのだが、発案からわずか3日でサービスがローンチできてしまうとは(Google App EngineとFacebook APIのおかげ)、ずいぶんと便利な時代になったものだ。 日ではまだまだだが、米国では人口の7割以上がアカウントを持つと言われるFacebook。Twitterでの不特定多数向けの「つぶやき」よりも、友達・知り合い間での「プライベートなコミュニケーション」向けのFacebookは、どちらかと言えばmixiに似ている。mixiとの根的な違いは「大人も使っている」点。 特に最近は、「プラ

    taka-oh
    taka-oh 2011/01/03
    APIを使った仕組み作り
  • iPadアプリ開発日誌: ダウンロード数とランキングの関係

    先日iPad向けにリリースした「加速する創作系マガジン『暫』」、とても好評で発売3日目には書籍部門で1位、4日目には総合で2位(瞬間風速では一時的に1位)という快挙。 「どのくらいダウンロードがあるとランキングの上位にい込めるのか」という質問を良く受けるので、発売後8日間のダウンロード数と、(日での)総合順位をグラフにしてみたのがこれ。 グラフの一番右下が初日の結果で(248ダウンロード/総合65位)、ダウンロード数が急速に伸びるとともに順位も上がり、4日目のピークで、2781ダウンロード/総合2位に達している。 アップルがどのくらいの期間のダウンロード数を目安にランキングを決めているかが不明なので、このグラフが100%正しいとは言えないが、大体の感覚はつかんでいただけると思う。重要なことは、このグラフが直線ではなく、大きくカーブしていること。 これは無料アプリのカーブだが、当然有料ア

    iPadアプリ開発日誌: ダウンロード数とランキングの関係
  • Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し,締め切りが近づいたら流す」という働き方

    かれこれ30年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は100人に1人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分

  • 無名関数を使った非同期通信のススメ(JavaScript)

    ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基的に3つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の

    taka-oh
    taka-oh 2010/02/01
    通信プログラムについて。マルチスレッドよりは非同期を駆使するがよい?
  • GoogleはなぜAndroidやChrome OSを無料で配布するのか?

    先週「Androidと家電」というタイトルで講演をさせていただいた私だが、そのプレゼンのキーポイントは、「なぜGoogleAndroidを無料で配布するのか?」。それを私なりに説明するための資料として作ったスライドが以下の二枚。 まずこれは、MicrosoftとIntelがパソコン・ビジネスを育てるためにした「コモディティ戦略」を図式化したもの。IntelとMicrosoftで協力してCPUとOSを部品化・規格化することにより、誰でもパソコンを作れる様にしたのがそれ。これにより、パソコン・ビジネスへの参入障壁が減り、パソコン・メーカーが乱立。差別化がしにくい部分(つまりIntelとMicrosoftがほぼ独占的に提供するCPUとOS以外の部分)で激しいコスト競争が起こり、パソコンのコモディティ化が一気に進んだのは皆さんの記憶にも新しいはず。 特筆すべきなのは、MicrosoftもInte

    GoogleはなぜAndroidやChrome OSを無料で配布するのか?
    taka-oh
    taka-oh 2009/12/06
    階層図が興味深い
  • 組み込み機器向けandroidに関してのつぶやき

    もともとは携帯電話向けに提供されていたGoogleandroidが、それ以外の組み込み機器向けのOSとして注目されている。私なりの見解もそれなりにあるのだが、勘違いしている部分もあるかも知れないので、確認のためにも私の見方をぽろぽろとTwitterでつぶやいてみたので、ぜひともフィードバックをいただきたい(Twitter、このブログのコメント欄やトラックバック、はてぶ、のいずれでも結構)。以下がつぶやきの内容。 androidが携帯だけでなく組み込み機器一般で注目されている背景には、「要求される機能が肥大化し開発費が膨大になり、機種ごとにOSから組み上げるのがコスト的に見合わなって来た」というのがある(リンク)。 それに加えて、GUIやマルチタスクなどの要求に対し、従来の組み込みOS(μiTron・VxWorksなど)が答えられなかったという状況もある(リンク)。 その答えの一つとして浮

  • O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」

    昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、来のMVC(そしてオブジェクト指向そのもの)のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている(ここが根的な問題) ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的(これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない) ↓ ・O/Rマッピ

  • GoogleのAndroid向けのアプリビジネスはなぜ魅力的ではないか?

    PhotoShareをiPhone向けに提供して早くも一年になるが、もっとも良く投げかけられる質問は「PhotoShareはAndroidとかの他のプラットフォームに移植しないの?」というものだ。 少し前までは、「まだiPhone以外のビジネスが十分に大きくないから今はまだ早い」、「iPhone上でやるべきことはまだ沢山あるから」、などと答えて来たのだが、最近は少し見方が変わってきた。 今の勢いでHTML5が進化・浸透してくれるのであれば、わざわざ移植コストをかけてAndroidWindows Mobile向けにネーティブ・アプリを開発するよりは、少なくともUIの部分をすべてHTML+Javascriptにまかせたアーキテクチャでのインタラクティブなアプリの開発というのも十分に可能性があるように思えてきたのだ。 この「HTML+Javascriptですべて出来るじゃん」という発想は、そも