neu.Node リリースのお知らせ
去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ
「空気に支配される大人」にはならないで欲しい
「孫正義ソフトバンク社長が、経団連の理事会に出席し、経団連が一致して決議しようとした原発再稼働への賛成・推進に対して、反対し、執行部の姿勢を強く批判した」と報道されている（参照）。いかにも孫さんらしい行動だが、問題視すべきなのは、３００社以上の出席者からは、孫社長の意見に対する反論も同調する意見もなかったという点。 経団連を牛耳る原発推進派の企業により「満場一致で原発再稼働に賛成する」という空気が作られるなか、その「空気作り」が許せなかった孫社長が真っ向から反対したが、残りの「空気が読める、空気に支配される大人たち」は黙ってしまったのである。 この状況は、学校で「いじめ」が起こった時に、一部のいじめっ子たちにより「あの子はいじめて良い」という空気が作られた時に他の生徒が黙認してしまう（そして、結果としていじめる側に回ってしまう）状況に似ている。そんな空気の中で「こんないじめは良くないよ」と
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
Life is beautiful: Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ
今年のCESについてだが、すでに「感心した商品」と「自分も関係していてうれしかった発表」に関しては書いたので、今回は「これはだめかな」と思ったもの。 まずその筆頭は「３Dテレビ」。これ以上大きくすることも薄くすることも解像度を高くすることもできなくなってしまった「成熟しきった」デバイスであるテレビに何とか付加価値を付けようという気持ちも分からないでもないが、正直言ってこれはいらない。CESに出品されている最新の３Dテレビを見てもあまり感動しないし、そもそも目が疲れる。今年の末あたりになって、「結局３Dテレビって何だったの？」という話になると私は見ている。 二番目は「Android」。前にも書いたが、これから家電やスマートフォンの市場に新規参入しようというアジアのメーカーにとっては、Androidを活用して短い開発期間と低コストで「安かろう悪かろう」のデバイスを薄利多売で売りまくるという戦略
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
SVGで少し遊んでみた
HTML5/CSS3の重要性に関しては、ここでも何度か取り上げているが、ちょっと見逃しなのがSVGの重要性。IE9がサポートすることになって、ようやくSVGを活用したサイトの構築が現実的になって来た。HTML5のCANVASがJavaScriptで動的に「描く」ことを前提にしているAPIであるのに対し、SVGはHTMLとの親和性のよいマークアップ言語である点はちゃんと認識した上で使い分ける必要がある。特に、モバイルデバイスでは、CANVASでのアニメーションはやたらと電池を消費するので、ある程度までのアニメーションならば、CSS3アニメーション＋SVGの組み合わせの方が適している。 とうことで、今回は勉強も兼ねて、SVGを生成するプログラムを書いてみた。開発中のiPad向けのベクター・エディタ、neu.Drawから直接SVGを書き出すというモジュールだ。 グラデーションの扱いと、グループ化
Life is beautiful: WEB+DBコラム「なぜ日本のソフトウェアが世界で通用しないのか」
私がコラムを書いている「WEB+DB PRESS」の最新号が発売されたので、ここで宣伝させていただく。今回のコラムのタイトルは、「「なぜ日本のソフトウェアが世界で通用しないのか」。 ...(前略)...そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること、そして、日本のソフトウェア・エンジニアの境遇が悪すぎるということ。そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 詳しくはコラムを読んでいただくとして（宣伝だと言ったでしょう）、この問題はいまやソフトウェア業界だけにとどまる話ではないから始末が悪い。世界で一番進んでいるはずだった日本の携帯電話メーカーが、今や袋小路に追い込まれているのもこれが原因。 通信業界にはもちろん、携帯電話メーカーにもソフトウェアを自分で書ける人がいない今の日本の状況を考えれば、世界の
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
iPadに最適化したPDFファイルの作り方
iPad向けにPDF/マンガリーダーCloudReadersを発表してから、いままで直に付き合いがなかった出版業界の人たちからちょくちょくコンタクトをいただくようになった。その中で良くある質問の一つが、「iPad向けに最適化したPDFファイルの作り方」。そこで今日は、そのあたりのノウハウをまとめて書いてみる。 まもなく日本でも発売されようとしているiPadは色々な意味で画期的なデバイスだが、あくまで位置づけはモバイル・コンピューターであり、パソコンではない。画面も大きく、CPUも高速になったとは言え、搭載するメモリ（RAM）の量はiPhone 3GSと同じだ。 そのため、メモリがふんだんにあるパソコン用に作ったPDFファイルを読もうとすると、メモリ不足でアプリが落ちたり、極端に遅くなったりしてしまう。アプリを作る側もいろいろと対応はしてはいるが（参照）、やはり快適にiPad上でPDFファル
iPadアプリ作成日記: 「iPadアプリ作ってて良かったなあ」と思える瞬間
「iPadアプリ作ってて良かったなあ」と思える瞬間は下に貼付けたコメントみたいなものをもらった時。こんなコメントをしょっちゅうもらえるなら、有料アプリを作って中途半端な小遣い稼ぎをするよりもずっと楽しい。 This is the best app in the world. Honestly. - ★★★★★ by jaybay216 - Version 1.05 - 07 May 2010 This application literally makes my iPad worth every penny I paid for it. This is the best app I have ever seen in my life. It works astonishingly, and its free. I would suggest that the creator starts
iPadアプリ作成日誌: CloudReaders リリース
一日遅れのアナウンスメントになってしまったが、iPad向けPDF/マンガリーダーであるCloudReadersがiTunesストアに並んだので報告させていただく。 米国でのiPadの発売（４月３日）に合わせてリリースしようと準備を進めて来たのだが、ちょっとした行き違いのために、６日遅れとなってしまった。 β版SDKでの審査には一発で合格したので安心していたのだが、最終版をテストしたアップルの担当者が「クラウド本棚」に１冊しか本が置いていないのをバグと勘違いして差し戻して来たのだ。私としては、あまり本がたくさん置いてあってはテストが大変だろうと気を使ったのだが、それが裏目に出たわけだ。 結局、「クラウド本棚はクラウドにあるんだから、私が本を置いた数だけ見えるのが仕様」と説明して承認してもらっただが、そのやりとりに６日かかったというわけである。 今のところiTunesストアには５つレビューが書
iPadのインパクト、私の予想８
iPadの米国でのローンチまで１０日となったわけだが、色々と思うことがあるので書いてみる。 予測１：４月３日のローンチは成功する これは99.9%確実である。この手のデバイスのローンチには、（１）開発者に魅力的なプラットフォームを提供してアプリを作らせ、（２）ブロガーの興味をそそって発売前からせっせとブログエントリーを書かせ、（３）アーリーアダプターの心をくすぐって注文予約させれば良いのだが、まさにその戦略に１００％ハマっている私がここにいる（笑）。 先日のエントリーで書いた様に、開発者としては、iPad用のクラウド本棚付きeBookリーダー「Cloud Readers」をすでにAppleに審査のために提出済みである。ブロガーとしてはこのエントリーも含めてiPadに関しては何度も書いて来ているし、当然アーリーアダプターとしてiPadはオンラインで注文してある。Appleから表彰状をもらいた
共著「Google Chrome OS」出版のお知らせ
先日のセミナーでも少し触れた、「Googleのコモディティ戦略」。インプレスからこのたび出版される「Google Chrome OSー最新技術と戦略を完全ガイド」の「戦略」の部分に共著者の一人として寄稿したのでここで紹介させていただく。 Chrome OSにせよAndroidにせよ、OSをGoogleが無料で提供するには深い意味があるのだから、それをちゃんと理解した上で、自社のデバイスに採用するかしないかを「経営判断」として決めるべき。「他のメーカーも載せはじめたから」とか「自分だけ乗り遅れたくないから」ぐらいな安易な気持ちで始めると、「実際やってみたら得をしたのはGoogleだけ」という結末になりかねないので慎重にすすめるべき。 ２年ほどiPhone向けのアプリを作って来た結果、最近強く思うのは、テレビなどの据え置きがたの家電にアプリをダウンロードして走らせる、という発想自体が根本的に間
Google TVを作ってソニーに何の得があるのだろう？
今週は先日ベータリリースしたばかりのGoogle App Engineアプリのアップデートで忙しいのに、こんなネタを振られては書かざるを得ない。もちろん、「グーグルとインテルとソニー、「Google TV」デバイスを共同開発か--米報道」のこと。 Googleにとってこれが良い話であることは誰にでも分かる。先日のセミナーでも指摘したように、先進国では既に飽和状態にあるGoogleのマーケットシェア。これ以上の利益を上げるためには、パソコンやスマートフォン以外のデバイスもネットに繋いで、全人類を「どこにいてもネットに繋いでいる状態」にしたいわけで（別名「全人類ネット中毒計画」）、Sonyのテレビを皮切りに、Samsung、Panasonic、Sharp、と主要なメーカーのテレビをGoogleのサービスに繋いでもらうためなら金を出しても良いと思っているぐらいだろう。 Intelにとってもこれは
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
無名関数を使った非同期通信のススメ（JavaScript）
ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基本的に３つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
