日本の大学生はなぜ勉強しないのか
今週号のメルマガ「週刊 Life is Beautiful」に向けて、「日本の大学生はなぜ勉強しないのか」という文章を書いたのだが、特に冒頭の部分はぜひとも多くの人に読んで欲しいので、引用する。 NHKニュースで「日本の大学生が予習復習のために費やす勉強時間は一日平均３９分」というデータが発表されていました。まさに「ぬるま湯大学」です。私が大学（早稲田大学）に通っていた時も似たような状況でしたがが、これが日本の国際競争力をなくしている原因の一つであることをより多くの人が強く認識すべきだとつくづく思います。 私は米国の大学（University Washington）でも勉強した経験がありますが、日本の大学とは全く異なっていました。まず第一に、予習をしていかなければ全く授業について行けません。授業にもよりますが、９０分の授業の準備に１〜３時間の予習が必要です。 例えばビジネス戦略の授業の場合
Life is beautiful: 図解、イノベーションのジレンマ
私がマイクロソフトをやめるキッカケを作ったのが、「イノベーションのジレンマ」という本だということは、以前にも書いた。IT業界でビジネスをしている限り、大きな会社にいようと、小さなベンチャー企業にいようと、この本に書いてあることを日々意識しながら仕事をするかどうかは大きな違いを生むはずだ。 このブログでも何度も引用しながら、一度もちゃんと解説を書いたことがなかったことに気が付いたので、今日のエントリーは、この本に書かれているコンセプトの解説。 そう思っていつもの様に書き始めたのだが、文字だけではとても伝えにくいコンセプトだ。しかし、図解と言えばパワポ、というのもありきたりすぎるので、会社の廊下にあるホワイトボードに手書きで描いた図を、携帯電話で撮影したものを使うことにした。通りがかった社員にも見てもらえるので、一石二鳥である。 上の図は、この本に書かれたコンセプトを一般化したもの。ブルーのラ
なぜJava開発者は眼鏡をかけているのか？
Home Archives Profile Subscribe 今週の週刊 Life is Beautiful : ４月２４日号 活断層マップと原発マップを重ねてみる なぜJava開発者は眼鏡をかけているのか？ 2012.04.25 Satoshi | Permalink | Comments (1) | | Comments 日本にもJava開発者は多くまた日本には眼鏡の人は多いです。ドントシーシャープ。 Posted by: jar | 2012.04.26 at 04:07 The comments to this entry are closed. Life is beautiful • Powered by Typepad Top
今、日本の家電メーカーに一番必要なもの
今週はラスベガスでCESが開かれているが、CESの時期になるとトラフィックが増えるエントリーが二つある。 とある家電メーカーでの会話：クラウドテレビ編 もし日本のメーカーが iPhone を発売していたら.. どちらも２０１０年のCESに参加した後に感じたことを率直に書いただけだが、その状況は２０１２年になってもあまり変わりがないようである。 日本の家電メーカーや携帯電話メーカーの本質的な問題がどこにあるかを理解したければ、Simon Sinek の "How great leaders inspire action" というビデオを見るのが一番良い。アップルにあって、日本のメーカーに欠けているのは、作り手と消費者の間の「目的意識の共有」である。 戦後の高度成長経済には、「家電三種の神器」と呼ばれたテレビ・冷蔵庫・洗濯機に代表される「もの」を持つことにより生活を向上させることが人々の夢だっ
Google+Motorola: Microsoftは「当て馬」だった
先週、「MotorolaがWindows Phone陣営に乗り換える可能性を示唆」というエントリーに書いた通り、あの手のアナウンスメントにはだいたい何か裏の事情がある。 そして今日、GoogleがMotorolaの携帯電話部門を買収することがアナウンスされ（参照）、その裏事情が何であったかが明らかになった。あれは、MicrosoftとGoogleを競争させて価格をつり上げるための牽制球だったのだ。 Microsoftが実際どの程度Motorolaとの話をしていたかは不明だが、１ドルでも高く売りたいMotorola側としてはGoogleから買収の話が来た時点でわざわざMicrosoftを「当て馬」として引きづり出して競争させようとするのは当然。あのアナウンスメントは、Microsoftに向けたラブコールでもあり、Googleに対する「早く良い条件で結婚を申し込んでくれなきゃ、他の人と浮気しち
iPadアプリ開発日誌： neu.Notes 1.3 リリース
８月３日付けで「AppBankの2010上半期ベストiPadアプリのまとめ。超厳選した２０個！」が発表されたが、CloudReaders と neu.Notes の両方が入っており、開発者としては正直うれしい。アプリを使っていただいているユーザーの方々にもAppBankの人にも感謝の気持ちでいっぱいである。 アプリの平均起動回数がわずか１.5回という短命なiPhone/iPad向けアプリの中で、「長期間にわたって使ってもらえるアプリ」を作るには、やはり「本・マンガを読む」「手書きメモを取る」などのごく基本的なシナリオを押さえたアプリを、必要最低限の機能は提供しながらも、初心者でも使える様にシンプルに、かつサクサク動く様に作るしかない、という発想で作ったのがこの二つのアプリである。 他にも作りたいアプリはたくさんあるし、既にリリースしたアプリのアップデートもしなければならないし、CloudR
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
勝てば官軍、負ければガラパゴス
私が数年前からこのブログで使っている「ガラパゴス化」という言葉、今やテレビや雑誌でまで見る様になり、何だかうれしいような悲しいような、複雑な気持ちである。 私が最初に公の場でこの言葉を使ったのは、２００１年のCTIA（米国最大の携帯通信業界のカンファレンス）でのこと。UIEvolutionというベンチャー企業を立ち上げたばかりでもあり、この業界でなんとか注目を集めようと、「NTTドコモのiモードのことなら詳しいので、日本の若い人たちのライフスタイルがiモードでどう変わったからなら解説できるよ」と会議の主催者に連絡すると、いきなり２０００人も収容できる会場を割り当てられたのだ。 私がNTTドコモから来た人間だと勘違いした人もいたようで、会場は超満員。冒頭でドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えたところそれが大受けで、日本のギャルの生態系の解説も交えながら、日本の「ケータイ文化
iPadアプリ作成日誌: CloudReaders 1.03
今回のCloudReadersのアップデートは、何と申請から４８時間以内に承認されるというスピード承認。前回のアップデートの承認が１週間近くかかったのと比べると格段のスピードアップだ。 今回のアップデートの目玉は三つ。（１）米国ユーザーからの要望が多かったCBRファイル（JPEGファイルの集まりをZIPではなくRAR圧縮したもの）のサポート、（２）巨大な画像ばかりを持つPDFファイルを読み込ませるとアプリが落ちるという問題点の回避、（３）UIの微調整だ。 今回のアップデートで一番苦労したのは、「巨大な画像ばかりのPDF」ファイルの扱いだ。PDFは本来文字データとベクターデータを扱うのが得意なフォーマットだが、雑誌や本をスキャンしたものをPDF化した場合、各ページにスキャンしたままの解像度の画像が貼付けられたページが作られることになる。 そんなPDFファイルをiPhone OSのAPIを使っ
Life is beautiful: とある家電メーカーでの会話：クラウドテレビ編
ある日本の家電メーカーでの会話。まずは副社長室での会話から。 技術部長：副社長、来年度の予算の件はどうなりましたか 副社長：大丈夫だと言っただろう。台湾・中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長：もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか？ 副社長：そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも３割・４割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長：え？「ク、クラ
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
HTML5入門：アニメーションの実装方法３種
HTML5・CSS3のような新しい技術の問題点は、HTML4やらFlashなどの枯れた技術と違ってノウハウ・ライブラリ・ツールとかがまだ十分にそろっていない事。普及のタイミングもまだはっきりとしていないこの段階で手を出せない・出しにくいと感じている人が多いのも良く理解できる。 私から見れば、逆に「こんな楽しい状況は滅多にない」わけで、商売になるかならないかは二の次にしていろいろと試したくなる。 今日作ったのは、HTML5+CSS3上で可能になる（ただし現在ではWebkit独自の拡張を含む）３つのアニメーション・テクニックの比較（左に貼付けたものがそれ、Safari/Chromiumだとすべて動く。Firefox/OperaだとDOMとCanvasのみ（ただし別ウィンドウで開かないとCanvasが動かないークロス・ドメインセキュリティのバグか？））。 詳しくはソース（参照）を見ていただければ
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない
ちまたで問題になっているIPAフォーラム2007に参加した学生がエントリーを書いているのだが、それが半端じゃないぐらいのエンターテイメント。 ...IT産業というよりSIerの人気がないことについて語りたいだけなんじゃないかという顔ぶれだったし... ...はてなブックマークのコメントを見ている限りでは、パネリストの方々は相当現実の見えていない発言をしているようだ。... ...ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。... ...その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
