ぜひとも起こしたい「教科書革命」
アップルが１月の１９日に何やら「教育関係」のアナウンスメントをするという話が報道されていたが（参照）、これを見て思い出したのが、私が少し前から漠然と考えている「教科書革命」。 教育はどの国にとってもとても重要だが、今の教科書の在り方は色々な意味で時代遅れである。 まず第一に、教科書はすべてデジタルで配布されるべきである。特に成長期の小中学生に重いカバンを持たせることは、背骨の発育上とても良くない。すべてデジタル化し、子供たちはタブレット一枚を持って、もしくは手ぶらで（タブレットは家と学校に一枚づつ持っておき、ネット経由で同期すれば可能）学校に通うという時代を実現すべき。 ここまでならば多くの人が既に考えているだろうが、同時に私が実現したいのは、義務教育機関中の教科書すべてのパブリック・ドメイン化である。パブリック・ドメインであれば、子供たちが無料で手に入れることができるだけでなく、教育者自
プラットフォームは乗るものではなく、担ぐもの
先日、出版記念イベントを開かせていただいた「エンジニアとしての生き方」、アマゾンでの在庫がなくなっていたようでご迷惑をおかげしたが、再び入荷したようである（３０日現在）。 ちなみに、この本はブログの人気エントリーとWEB+DB PRESSのコラムと書き下ろしから構成されるが、WEB+DB PRESSのコラムの連載はまだ続いているのでこちらもよろしくお願いする。 最新号のVol.62には、「プラットフォームは乗るものではなく、担ぐもの」というタイトルで、AndroidだiOSだHTML5だと乱立するプラットフォームにどんな気持ちで向き合うべきかという話を書いてみた。要約すれば「常に時代の先端を走り続けたいのであれば、『勝ち馬を見つけ出してそこにお金を張る』のではなく、『自らが騎手になって自分がこれと思ったプラットフォームを勝たせる』意気込みが必要」という話。 SDKの公開当初からアプリケーシ
SNBinder入門：一行おきに背景色を変えるテクニック
「ピュアAjaxアーキテクチャ」なウェブサイトを実現するために作ったSNBinder、多くの方々からフィードバックをいただけ、私もとても良い勉強になっている。そんなフィードバックの中に、「テンプレート内で条件分岐ができるようにして欲しい」「テンプレート内にスクリプトが書ける様にして欲しい」などのリクエストをたびたび見かけるので、今日はそれに関してひと言。 たしかに、従来型のテンプレートのほとんどに「繰り返し」や「条件分岐」の機能がある。ものによっては、そのテンプレート中にスクリプトが書けてしまうものもある。SNBinderにそんな機能を追加するのもけっして難しくないのだが、私がSNBinderで実現しようとしている方向性とは少し違う、と感じている。 そもそもテンプレートとは、JavaとかPythonなどで記述された「ロジック（もしくはコントローラ）」と、ユーザーに何を見せるかというHTML
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
私からの提案：おかえりなさいテレビ
若干誤解してしまった人も少しいたようだが、私が「もし日本のメーカーがiPhoneを発売したら...」で指摘したかったのは、「広告一つでこんなにインパクトが違うのか」という単純な話ではなく、「どこに重きを置いてもの作りをするか」というもっともっと根本的な問題。 カタログスペック重視のもの作りは、確かに社内の稟議を通しやすいし、作る過程でも目標設定が簡単だ。量販店で横並びにされた時にも他社の製品に負けない。しかし、これがそろそろ通じなくなっていることは、日本のどのメーカーもひしひしと感じているはずだ。 確かに「ユーザー・エクスペリエンス（おもてなし）」とか「ライフスタイルへのインパクト」重視のもの作りは、定量化ができなし、大失敗の可能性もあるので、「出る杭は打たれる」型の日本の会社では難しいのかも知れないが、そろそろ意識を切り替えないと手遅れになる。「ユーザーにどんな体験をしてほしいか」をまず
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
アップルの３０年ロードマップ
昨日、日経BP主催のAndroidに関するセミナーで講演＋パネルディスカッションをしたのだが、パネルディスカッションを一緒にさせていただいた、日本通信の福田尚久氏との話（特に、楽屋に戻ってからの非公開の話）が興味深かった。 福田氏は、スティーブ・ジョブズがAppleに戻り、Microsoftからの資金調達、iPodのリリース、アップル直営店の展開、という今のAppleの成功の基盤となる「奇跡の復活」を遂げた時期にジョブズの側近として活躍した人。 彼に言わせると、今のAppleのビジネス戦略は、倒産寸前だった９７年当時に作った「３０年ロードマップ」に書かれた通りのシナリオを描いているという。 もちろん、具体的な内容は企業秘密でもあるので直接聞き出すことはできなかったが、ここ１２年の間にアップルが出して来たもの（iPod, iTunes, iPhone, Apple TV, Safari, O
Google App Engine入門：フレームワークの選択
Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、
WSSEのセキュリティリスクとその対処法に関する一考察
引き続きiPhone SDKで遊んでいる私だが、Typepadやはてなが採用しているAtomを使ったiPhoneアプリを作ってみようとしたところで、WSSE認証の仕組みを（Objective-Cで）ゼロから作らなければならないことに気づき挫折しかける。SHA1のライブラリまで自前で用意しなければならないのはちょっと荷が重かったのだが、増井さん（masuidrive）からRFC中のコード（参照）が使えることを教えていただき、それを元に実装（持つべきものは友だ^^）。 細かな間違いをいくつもしていた上に、WSSEの仕様を少し勘違いして始めたためになかなか動かず、はてなからステータスコード200がもらえたのは夜の１０時過ぎ。半日ぐらいで軽く作れると思っていたのに、結局丸一日かかってしまったが、「WSSEとは何ぞや」を何も知らないところから始めたのだから良しとしよう。 しかし、WSSEの仕様に関し
プロトタイプを重視するカルチャー
最近、UIEJのメンバーの間で「うみがめ」というGoogleの「20%ルール」に相当するルール作りの話が盛り上がっている。ルール作りはおおいに結構なのだが、「なぜうみがめが必要か」というプリンシプル（相当する良い日本語がないが、あえて選ぶなら「筋」－詳しくは「プリンシプルのない日本」参照）を見失って「ルールのためのルール作り」に陥らないで欲しい、というのが私からのお願いである。 そこで、今まで私がプロトタイプ作り、ベータ版サービスの重要性に関して言って来たことをまとめてみた。 １．UIEのような会社にとって何よりも大切なものは、賢くてクリエイティブな人。そんな人たちが働きたいと思うような、そして彼らがクリエイティビティを最大に発揮できるような環境を提供することが大切。 ２．本当のイノベーションはごく少人数でおこすもの。一人とか二人とかのクリエイティブな人が、「こんなもの作りたい」という情熱
優秀な主婦はイベント・ドリブン（event-driven）方式でパンを焼く
昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 １．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる ２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる ３．こね板の上で生地をこねる ４．ボールにラップをして室温で１時間発酵させる（一次発酵） ５．適当な大きさに生地を分割し、丸めて形を作る ６．オーブンに入れ、３０分発酵させる（二次発酵） ７．オーブンの温度を２００度にして１８分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。 興味深いのは、このレシピにおける、「１５分予備
心暖まるラッコの映像
バンクーバーの水族館で「手を繋いで水に浮かぶラッコ」が評判になっている。Youtubeに映像が上がっているので、下に張っておく。King5によると、実際に海でもこの行動に出ることがあるらしい。波に流されてはぐれてしまわないように、という行動と解釈されているそうだ。
ネットの時代には「知識量・記憶力」よりは「適応力・応用力」の方がずっと大切
先日の「習作UI: 縁日の金魚を再現してみた」というエントリー。特に深い意味もなく作ったのだが、ソフトウェア・エンジニアを目指す学生さんのためにひとこと付け加えておきたいのは、この業界で本気で成功しようと思ったら、この程度のプログラムは、シミュレーションの専門家でなくともサクッと作れるように自分を鍛えておかなければいけない、ということ。 この業界で働きはじめると、担当した仕事によって、データ解析・Java・３D・シミュレーションなどのある特定の分野のプログラミングの経験を積むことになる。そういった経験を通して特定の分野を深堀りしてエキスパートになるのはおおいに結構なのだが、往々にして落ち込んでしまうのが「ボクはJavaのエキスパートだからRubyではプログラムは書かない」、「シミュレーションのことならそれに詳しいエンジニアがいるんだからその人に頼んで」、「今からFlashを勉強している時間
日本は世界経済にとってのガラパゴス諸島
渡辺千賀さんの「日本は世界のブラックホールか桃源郷か」というエントリー。「そう、そう」とうなずきたくなるようなエントリーだが、私が数年前から使っている表現は「日本は世界経済にとってのガラパゴス諸島」。 ２０００年ごろから始まった、日本特有の「ケイタイ文化」の進化は、主に言語と人種と非関税障壁の壁により隔離された日本だからこそ起こったと言え、文化人類学的に見ても、グローバル経済の面から見ても、とても面白い。だから、米国のワイアレス関係の人たちの中でも目利きの人たちは、あいかわらず日本を特殊な実験場のような目で注意深く見ている。 隔離されているからこそ、独自の変化を遂げることが出来ているのも一つの特徴だが、それゆえに「外来種」にあっという間に駆逐されてしまったり、海外でまったく勝負できないなどの例も後を絶たない。最近ではスターバックスが良い例である。昔良く見かけた「マイアミ」とか「カトレア」は
Life is beautiful: リーダーに必要とされる感情知性（Emotional In...
MBAプログラムに参加したおかげで、大量の論文を読まされることになったのだが、頭の中を整理する意味で文章にするのは役に立つし、それがブログのちょうど良いネタになる。今日のエントリーは、Daniel Goleman という人の書いた”What Makes a Leader?” という論文の要約。 筆者は（企業などの）リーダーになるためには、ただ高い知性と専門知識を持っているだけでは不十分で、筆者がEmotional Intelligence(感情知能)と呼ぶ能力を持っていることが不可欠だという。 Emotional Intelligenceには５つの要素がある。 Self-Awareness 自分のムードや感情を常に冷静に把握しており、それが他の人に与える影響を十分に認識していること。Self-Awarenessが低い人は、自分の性格の欠点を指摘されたりするとそれを「個人攻撃」と見なして不必
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
これぞマッド・サイエンティスト
面白い物理の実験を見せてくれるMITの教授のビデオがYoutubeで大人気だが、これを見て思い出したのは、子供のころは科学の実験の時間が大好きだった私（物理より化学だったが）。自分の家にも実験室を持とうと、小遣いをためては、ビーカー＋フラスコ＋石綿金網＋三脚＋アルコールランプと買い集めていたころを思い出す。専門の薬局に水酸化ナトリウムと塩酸を買いに行って「子供には売れない」と断られたのも私だし、木炭を作ろうとしていて部屋の中に一酸化炭素が充満してしまい、「何このにおい！」と母親に助け出されたのも私だ。 ちなみに、このビデオは落下する水と空き缶だけで発電するという実験。確かにすごい。こんな先生ばかりだったら、科学好きの子供たちが増えるだろうなあ、と。
Life is beautiful: 自分で考える前にググっていませんか？
つい先日、興味深い話を聞いた。ある大学の授業で「デジタル・コンテンツ・ビジネス」というテーマで小論文を宿題として書かせたところ、同じような内容の小論文ばかりが集まったという。その原因を調べたところ、「デジタル コンテンツ ビジネス」のキーワードでググると上位に来る私の過去のエントリーの内容がほぼ丸写しにされていたという。 日本の学生の勉強に対する態度なんてそんなものなのかも知れないが（それはそれで憂うべき話だがその話は別の機会に）、少し心配になるのがどんな気持ちでその手の「コピペ」をしているのか、という点である。確信犯的に「徹底的に手を抜きたいからコピペしているだけ」ならまだ許せる。私が問題視するのは「自分で考える前にまずググる」習慣であり、「ググれば答えが見つかるにちがいない」という錯覚である。 暗黒時代とも呼ばれる中世ヨーロッパで科学の進歩があんなにも長い間低迷した原因の一つは、あの時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外国為替相場取引（FX）で確実にもうける方法（必勝法）