Webブラウザ上でネイティブなプログラムを実行する「Native Client」という技術が、Googleから発表されました。
Webにたいして、こういうアプローチができるGoogleという会社は素直にすごいなあと思います。
いままでも、Flashについては渋々使っていることを公言していましたが、こういう回答を用意していたわけですね。
ローカルリソースへのアクセスはかなり厳しくなるんでしょうが、そのぶんGoogleのクラウドを存分に使えるんでしょうね。きっと。。。
カテゴリー: システム開発
巷ではGoogle Chart APIが話題になっていますが、
Yahoo!のJavaScriptライブラリ「YUI」にも、グラフを描くCharts機能が追加されていました。
今現在は、experimentalとなっていますので、まだ試験的な扱いのようです。
WebAPI形式で静止画を返すGoogle Chart APIと違って、YUIのChartsはJavaScriptからFlashを操作してグラフ描画しています。
このFlashの部分は、元々Flash Developer Centerでオープンソースとして公開されているもののようです。
YUIからChart機能を使う場合は、Flashのインタフェースを意識せずにJavaScriptの操作のみで使えるようになっています。Flashなので、アニメーション効果をつけたりもできそうです。
このグラフ作成機能の中に、円グラフを作成する機能が含まれているのですが、そいつの色を変える設定で少々てこづったので、設定方法を書いておきます。
何回もやって、技術も進歩して、経験も積んで、環境が変わっても、システム作りってなかなか変わらないもんですね。
徹夜してないぶんは、進歩かもしれませんが・・・
鈴木さんの記事を読んで、そんなことを思いました。
－品質についての気づき
設計通りに作れないのが当たり前
～明確なのは「仕様や設計に矛盾がないことはありえない」ということです。実装してみて分かる矛盾は必ずあります。そのフィードバックをなるべく早い段階で行うことが重要です。そもそも設計通りに作れないのが当たり前なのです。
～皆さん、仕様変更も設計書の変更も普通にやってますよね？「それじゃ実装できない」って。それは、すごく正しいことなのです。
【IPCM】iPhone，ディズニーランド，スタバの共通点は？──人気ブログ「Life is beautiful」の中島氏が講演
ユーザー・エクスペリエンスとはおもてなしのこと。
トータルでのユーザー・エクスペリエンスの設計が大事。
このあたりが、UI大事ってとこにもつながってくるんだとおもう。
もう2年以上JavaScriptのコードを書いてます。
今ではだいぶ使いどころもわかってきて、Webサイトをつくるんだったら、サイトの中に味付程度で使うのが一番現実的かなと思ってます。
WebサイトとWebアプリは違うんだということもわかってきました。
Webアプリだったら、クライアント側は全部JavaScript、サーバサイドは全部WebAPIという構成が、非常にシンプルで美しいです。Livedoor ReaderやONGMAPみたいのが、自分の思うWebアプリです。
一方のWebサイトを作ろうと思うと、このJavaScript+WebAPIの構成は恐ろしく効率が悪いです。レガシーなWebページを量産するために、JavaScriptをメインで使おうと考えてはいけません。でも味付け程度だったら使いどころが結構あるんです。その落としどころをどこにするかが、最近の課題だったりします。
ところで、JavaScriptってプログラム言語的にもおもしろかったりします。
プロトタイプベースのオブジェクト指向というらしいです。
C++とかJavaのような、普通のオブジェクト志向をやってきたひとからすると、恐ろしく気持ち悪い言語です。でも嵌ると、本当に嵌ります。いろんな意味で嵌ります。
そのあたりは、IT戦記とか、最速とかをみた方が良くわかります。
例のMatzさんの日記に、プログラミング言語分類論。って話がありました。
_ [言語] Chris’s Wiki :: blog/programming/LanguageNiches
プログラミング言語は大きく分けると3つに分割されるように思われる。
1. 強い制御と静的な型。C, C++
2. 緩い制御と静的な型。Java, C#
3. 緩い制御と動的な型。Python, Ruby
最近流行(？)の関数型言語であるが、結局(2)の分野に分類されるので(筆者の意見では)成功しないかもしれない。
JavaScriptってどこに入るんだろう、JavaScriptは関数型言語に近いって話を聞いたことがあります。でも３．に入るような気がします。このあたり、元々プログラムが専門じゃないだけに、自分は本当に弱いです。
また、こういう観点から見るとGoogleがその使用する言語を C++, Java, Pythonに限定していることは、各領域から一つずつということで、実は非常に合理的であることがわかる、という話。
JavaScriptが入ってない、、、
JavaScriptが、プログラミング言語として興味深いというおもしろさもあるのですが、
最大のおもしろさはWebブラウザ上で動作するということなんだと思います。
その気になれば、サーバサイドの言語を使わずに、JavaScriptだけで結構いろいろやれます。
マッシュアップもある程度できちゃいます。Flashみたいに開発ツールを買う必要もありません。
–JavaScript: 世界で最も誤解されたプログラミング言語
自分もここに書いてあるような誤解をしていただけに、世の意見が180度変わってしまったのには本当に驚きました。この世界は本当に何があるかわかりません。
情報システム開発の世界では、情報システムの開発を請け負う企業をSI(とかSIer)と言い、それを使う企業をユーザー企業と言います。
通常、両者は協力してシステムの構築に当たるのですが、お互いの領域の線引きをどこにするかというのが非常に難しかったりします。
ユーザーはITプロフェッショナルであるべきか
ユーザー企業ができる限り，自分で取り組むことである。情報システム開発を例にとれば，要件定義，設計，プログラム開発，テスト，機種選定，システム環境の整備，データ移行，システム運用・保守，利用者教育まで，すべて自分で責任を持って実施する。ビジネスに合致した情報システムを開発し，動かしていくには，自分でやるのが一番早く，柔軟な対応が可能で，しかも安上がりなはずだ。
すべてユーザー企業側がやったほうが望ましいという意見もある一方で、ITの部分はすべてSIerが責任を負うべきとの意見もあります。
経営者がITを理解できない本当の理由
我々ユーザー企業は、ビジネスにおけるIT投資の費用対効果を考え、どんなビジネスをして、ITをどう使ったらいいかを考え抜く。できあがったシステムを使いこなしてビジネスを遂行し、所定の効果を出すところに力を注ぐ。
一方、ITや情報システムの開発については、ITベンダーに責任をもって担当していただく。
結局のところ、企業が行うビジネスと情報システム(IT)がどの程度密接なのかで決まってきます。
すべての経営行為はシステム開発そのものだという意見さえもあります。
「IT投資」という考え方そのものが間違っている
ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。
どのようなソフトウェア機能なら、システム的ボトルネックが生じずに、かつ、ソフトウェアシステムの保守性が悪くならずに開発可能かどうかの検討がつかない経営者では、ろくな事業企画ができるわけがないのです。
なぜなら、それは、自社の経営行為そのものであり、それを外注にやってもらうのは、経営行為そのものを外注にやってもらうというような、意味不明の行為だからです。
上の記事の通り、自社のビジネスとITが密接な企業ほど、社内の人員でシステムを構築すべきです。
いわゆるIT企業はたいていそうしていると思います。はてなやライブドアなどは、ほとんどのシステムを社内で構築しているようですし、Googleにいたっては、ハードの設計まで自前でやっていると言われています。
それでは、SIerはどうすれば良いのか？その答えが、アジャイル開発だったりするのかと思っています。
アジャイルアライアンス
要件の変更は例え開発の後期であっても受け入れます。
アジャイル･プロセスは変化を味方につけることによって
お客様の競争力を引き上げます。
ビジネスをする人と開発者はプロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
ですから彼らが必要とする環境と支援を与え
仕事が無事終わるまで彼らを信頼してください。
この問題はSIerが受け取る報酬も関係してきます。
単に技術者の頭数が欲しいだけならば人月見積もりでもいいのでしょうが、
ビジネス自体を一緒に作ろうとしているパートナーに対して、
人月見積もりしてたら駄目でしょう。
人月見積もりでは生産性は上がらない、IPAが警告
「ソフトウェアのアウトプットを計るのは難しく、現状多いのはコスト積み上げ型の何人日という形での見積もり。ソフトウェア工学は進歩しているが、生産性を上げても金額が低くなってしまう。このジレンマが生産性の上がらない要因。それがまさしく浮き彫りになった調査」
よいSEにはよい報酬を，
“人月いくら”はもうやめよう
システムの価格を“原価”によって決めるのではなく，そのシステムがユーザーにもたらす“価値”によって決めよう，という機運が高まってきたことだ。
>デッドライン―ソフト開発を成功に導く101の法則
>「仕様書があいまいなのは、システムの利害関係者間の間で対立が解決されていないしるしである」
あいまな仕様書ができてしまう理由の一つに、ステークホルダーにとって読みにくい仕様書(読めない仕様書)を作ってしまっているという点があります。
wikiで仕様書を書くと、どういうことが起こるのか？
・いつでも最新の内容を確認することができる
・RSS、差分機能によって、変更個所を確認することができる
結局のところ、仕様書のような類のドキュメントを作成していく過程では、一発勝負ということはほとんどありえず、少しずつ作成、修正されながら完成されていくものです。
wikiを使用すれば、ドキュメントを作成・修正していく過程を共有することができます。
しかしながら、wikiならではの問題点も当然ありますが…
最近のコメント