モバゲータウン基盤モジュール、オープンソース化へ

ここの記事
モバゲータウン基盤モジュール、オープンソース化へ
http://codezine.jp/a/article/aid/2349.aspx
によると（以下斜体は上記サイトより引用）

DeNAでは、YAPC::Asia 2008開催までにモバゲータウンで利用している基盤モジュールをオープンソース化するようだ。YAPC::Asia 2008のセッション紹介のなかで明らかにしている。

　オープンソース化が予定されているのは「MVCのコントローラ」「XSによる高速テンプレートエンジン」「ケータイ絵文字変換」「ケータイ端末認識/認証」「ケータイキャリア向け高速メール送信サーバ」などの基盤モジュール。




だそうな。

ちなみに

YAPC::Asia 2008はPerl開発者のためのカンファレンスで、5月15、16日に東京工業大学大岡山キャンパスで開催される。


で、YAPC::Asia 2008は、
ここ　http://conferences.yapcasia.org/ya2008/

コンピュータなんかの技術トレンドを説明するのは、やっぱ、ハイプサイクルなの？

　Googleのデベロッパー交流会でも、たしか、ハイプサイクルを使った（SNSの）説明があったし、日経コンピューターの２００８年３月２８日号（７００号記念）にも、１６８ページからハイプサイクルを使って説明してるけど、いま、技術トレンドの説明は、ハイプサイクルなんすかねえ・・

あ、ちなみに、ハイプサイクルってのは、
ハイプサイクル
http://www.atmarkit.co.jp/aig/04biz/hypecycle.html
にあるように（以下斜体は上記サイトより引用）


話題や評判が先行する新技術が実際に普及するまでの間、その期待が時間経過とともに、どのように変化するかを示した図、またはサイクルのこと。


で、


　典型的なハイプサイクルには、「黎明期」「流行期」「反動期」「回復期」「安定期」の5つの段階がある。


って書いても、よくわかんないよね。
リンク先の図をみてくれると、わかるかも。。。

ミクストメディアというサーバ屋に突撃→誰もいない、郵便受けは満杯！というブログ

ここのブログ

mixedmediaの終焉？
http://d.hatena.ne.jp/aniota/20080317/1205763568
によると、ミクストメディアというサーバ屋さん、

３月１１日の時点

弊社内部の事情で誠に申し訳ないのですが、弊社技術担当の緊急入院により現在24時間の有人サーバ監視体制が実現できていないため障害対象サーバ特定サーバ復旧作業に非常に時間がかかる状態になっております。また、新任の技術担当者へのサーバ情報引継ぎも正常に行なわれていないため、再発防止の策(アクセス過多の領域を隔離するなど)をとることができません。このような社内の体制の急変に伴い、各々担当者への連絡がつきにくい状況が発生しており、サポート担当者からお客様へすぐに返答を差し上げる事もむずかしい状況となっております。(電話の不通に関しましても、原因不明で、責任者への連絡もとれないため対応ができない状況です)


いや、これだけでも、すごいんだけど・・・

３月１５日の段階で・・


887 ：名無しさん＠お腹いっぱい。：2008/03/15(土) 00:04:20 0

＞864さん

福岡から早速、突撃してきましたｗ　事務所はマンションの最上階。予想通りに誰もいない。

863さんのおっしゃる通り、郵便受けは満杯で、JPRS、KDDI、NTT東・西、クレジット会社、簡易裁判所、警察、債権回収会社などのマイナスオーラ溢れる封筒がたくさんあり、気持ち溢れる先客が封を開けてるのもあり、機器のリース代金一括返済請求660万円とかいろいろありました。


・・・・

で、スラッシュドットによると・・
レンタルサーバー屋がさじを投げたら
http://slashdot.jp/it/08/03/21/0230254.shtml

ちなみに、ウィリアムのいたずら、インターネットWINっていうところ使ってたんだけど・・
ある日とつぜん、つながらなくなったのよねー（＾＾；）

第二のインターネットWIN？

「東京タワー2.0」がないけど、2.0ブームは終わったのかな？

ここの痛いニュース
新東京タワーの名称、「ライジングタワー」「ゆめみやぐら」など6案が出揃う
http://blog.livedoor.jp/dqnplus/archives/1105603.html
(以下斜体は上記サイトより引用）


「東京EDOタワー」「東京スカイツリー」「みらいタワー」「ゆめみやぐら」
「ライジングイーストタワー」「ライジングタワー」の6案


は、論外として、ウィリアムのいたずら的には、
「新東京タワー」のままでいい
というのも、ま、ここではおいておいて、

その下に、いろいろ名称案が書かれているけど、

「東京タワー2.0」

っていうのが、ない点をみると、
もう、何かに、２．０ってつけるブームは、終わったのかな？

オブジェクト指向で開発の最初から最後までの手順例－その５０：のこりをひたすら作る。。。

シリーズオブジェクト指向で開発の最初から最後までの手順例です

　前回までで、ここの「（５－４）ビュー」の 「（５－４－３）画面定義決定」まできました。
　今回は、「（５－４－４）ひたすら、つくる（＾＾；）」って、「（６）全部出来たら、つないで見て確認」です。

---

■とにかく、のこりを作る・・・

　とはいっても、ただ作るだけです。

●クライアント側
（１）画面は出来ていますが、それを、こりたければ、もちょっといじる
（２）各画面において、ボタンが押されたとき、
　　　　入力項目をチェック
　　　　引数を設定して、サーバーを呼び出す
　　　　受け取った結果を表示(innerHTMLをやると簡単）
　　　を必要に応じてやります（共通ユーティリティは作ってありますので、それを利用）

●サーバー側
（１）仕様書から、コントローラーと、DBアクセスは自動生成するので
（２）モデルの部分を作成します。

こんなかんじで、クライアントのサーバー呼び出し部分と、サーバーのモデル部分を作成します。

---

■確認する

　で、出来上がったら、Tomcat上にできあがったものを配置して、
　動かしてみて確認します。

---

　はじめは、ちゃんと例をあげて、まじめにやるように意気込んだのですが、後のほうになって、めんどっちくなってしまったため、途中から流すだけになってしまいました。すみません。　m(__)m

　今度は、４月以降に、装いも新たに、Accessを開発ツールとして使って、上流から、やってみたいと思います。
　Accessのプログラムを作るのではありません。Accessを開発ツールとして使って、Webベース、サーブレットのシステムを開発してみたいと思います。

　ということで、このシリーズは、ここまで。　　おしまい。

「Apple」のロゴを見るだけで創造性が上昇

するそうです！！

ここのニュース
「Apple」のロゴを見るだけで創造性が上昇――デューク大学調査
http://www.itmedia.co.jp/news/articles/0803/20/news002.html
によると！！

まじっすかあ！！（＠＿＠！）

iTunesが載ってるとか、着うたが流せるオーディオ機器だったら、アリかもしんないけど？

ここのニュース
オンキヨー、ソーテックを吸収合併
http://www.itmedia.co.jp/news/articles/0803/19/news116.html
によると（以下斜体は上記サイトより引用）


オンキヨーがソーテックを9月に吸収合併。ソーテックは解散する。


ってことらしい。

たしかに、
・iTunes搭載（iTunes Storeから買える）のオーディオコンポ
　→リモコンで操作、インターネットをつなぐ

とか

・着うたを再生できるオーディオコンポ

とかだったら、アリかもしれないけど（とくにオンキョーはiPodのオーディオコンポはあるみたいだから）、パソコンとオーディオをつないでも・・・（＾＾；）

　どーなんでしょーねー。。

　そーいう目的での合併ではないのかな？
　（生産施設とかの目的なのかしら・・・）

グーグルの検索ページ、変わったんですね！

　いつも、YAHOOで検索してるんで、

　ここのニュース

グーグル、検索ページを刷新
http://www.itmedia.co.jp/enterprise/articles/0803/19/news098.html

をみて、始めて知った。

まだ見てない人は、

こちら　http://www.google.co.jp/

ニュースとか、乗換案内とか、すぐ行けるようになってるし・・・

翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる－その６

シリーズ化してしまった「翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる」のつづき

ローカライズするには、次の３つの手順が必要

（１）国際化対応プログラムになっているか確認
（２）翻訳
（３）翻訳したものを戻し、稼動するか確認

ということでした。そして、前回までで（２）の翻訳部分が終わりました。
今回は「（３）翻訳したものを戻し、稼動するか確認」です。

---

■翻訳したものを確認する理由

　翻訳が終わったら（まあ、終わる前でもいいんですけど）、その訳したものをつかって、ちゃんと動くかどうか確認します。確認する理由は・・・テストしなきゃいけないでしょ！っていう話もあるんですけど、そのほかに

・日本語の長さによって、おかしくなる可能性がある
　日本語が長すぎて、びよーん！となってしまったり、文字列でメモリをとっているとき、１文字２バイトになることによって問題が生じる（バッファオーバーフロー）っていう可能性もあります。
　これらを確認します。
　また、短すぎても、おかしい場合もあるし。。


・訳していないところ、訳しちゃいけないところがある可能性がある
　たとえば、XMLのタグを書き出すところで、STOPってあった場合、これを「中止」とかにしてしまうと、各国別々のXMLになってしまうので、タグの部分は全部英語でいこう・・なのに訳してあるとか、
　文字コードの１６進埋め込みで、ある値がはいってて、本来、そこも訳さないといけないとか、そーいう部分があるかもしれない。。。


　などなど、あるので、もう一回訳したものを入れて、確認します。
　で、確認NGなら、そこの言葉を登録なり、修正なり、削除なりして、
　OKならリリースって言うことになります。

---

　このシリーズ、やっとこれで、おわりです（＾＾）

要求仕様の発注者ビューガイドラインのデータモデル、振る舞い編が公開されてる。

　NTTデータ、富士通、NEC、日立、構造計画、東芝ソリューションなどなどによる、「実践的アプローチに基づく要求仕様の発注者ビュー検討会」というところで、「発注者ビューガイドライン」という、要求仕様のガイドラインを作っていて、昔は、画面編しかなかったけど、最近、データモデル、振る舞い編もできたみたい。

どこにあるかというと、
発注者ビューガイドライン（ダウンロード可能）
http://www.nttdata.co.jp/cview/guideline.html
の一番下、同意して、ボタンクリックしたら、そこに書かれているIDとパスワードをいれると、まず、

「概説編と用語集ダウンロード」のページにいく。

そしたら、右側の「発注者ビュー検討会」と書いてある下のコンテンツリストみたいなところを見てください。
「画面編ダウンロード」
「システム振る舞い編ダウンロード」
「データモデル編ダウンロード」
とあるので、それぞれをクリックすると、げっとー！！できます。

オブジェクト指向で開発の最初から最後までの手順例－その４９：ビュー作成手順

　シリーズオブジェクト指向で開発の最初から最後までの手順例です。

　前回から、ここに示した手順のうち「（５－４）ビュー」をやっています。画面の割り方を、
　　・オブジェクトによるもの
　　・プロセスによるもの
　に分けました。今回は、どちらにしろ、それらをつくっていく手順です。

---

■最近の手順

最近は、

（１）とりあえず、各画面について、HTMLファイルでつくってしまう
（２）とりあえず、そいつらを画面遷移させる
（３）（１）のハードコピーをがんがんとって
（４）仕様書にまとめる

というように、HTMLで作っちゃうっていうのが、いいみたいです。
理由は
・HTMLなら、ホームページビルダーやMicrosoft　FrontPageのような
　すぐに作れるツールがある。

・HTMLなら、後工程にももっていける
　→JSPにするには、とりあえず拡張子を.html(.htm)から.jspに変えれば、
　　いちおう動く。あとは、１つ１つ直していけばいい

・HTMLファイルであれば、お客さんも見れる。
　場合によっては、お客さんが直してくれる
　→これが、いいのかわるいのかは・・・
　　（簡単に直せるとおもわれたり、こったものにされる危険アリ）

では、そんなかんじで、詳細説明

---

■（１）とりあえず、各画面について、HTMLファイルでつくってしまう
　各画面をつくります。

　プロセスごとの場合は、１プロセスをとりだして、そのプロセスの
入力項目をフォームで、出力項目をテキトーに書き出せるようにして
（AJAXで書き出すか、フォームの項目に書くか、結果は次画面に出すか
の違いアリ）、「実行」「キャンセル」ボタンをつけます。

　オブジェクトごとの場合は、１対多の場合

（１）検索・一覧画面
（２）詳細（編集）画面

が必要です（１対１の場合は、（１）がいりません。場合によっては、（１）または（２）どちらかいらないこともあります）。

（１）の検索項目は、検索条件が入れられるようにして
（入力の仕方はいろいろ、コンボボックスで、項目を選んで、値を入れたり、
　フォームにすでに項目が書いてあったり）
実行すると、一覧表示されるようにします。
この一覧は、レコードが分かる程度の内容を表示します。
検索画面と一覧画面は、分けても分けなくてもOKです（個人差があります）

そしてクリックされたら、（２）の詳細画面にいきます。
ここで編集できるようにする場合もあります。
（詳細画面と編集画面を分ける場合もあります）。

詳細画面・編集画面の項目は
　・オブジェクトの属性すべて
　・実行するメソッドで必要な引数
です。
　で、メソッドの分、ボタンを作ります。
　なお、一覧には、次・前とか、編集は一覧に戻るボタンとかも必要になります。

---

■（２）とりあえず、そいつらを画面遷移させる
　で、画面遷移させます。

　プロセスの場合、操作一覧画面をつくり、そこにプロセスのボタンをならべて、
そのボタンがクリックされたら実行というふうにします。

　オブジェクトの場合、親子関係で、親の画面から、子の画面にいけるようにしますが、
　その際、

　　親の親　＞　親　＞　子

　のように、画面上に表示しておき、その表示をクリックすると、すぐに親や、親の親にいけるようにします。
　そして、一番上位のもの（とはかぎらないけど）は、タブでいけるようにします。

　てなことを方針にして、画面遷移させます。
　なお、ボタンのところで、次画面に遷移するようにFormやボタンクリック時のfunctionを書いておくと、ユーザーにも画面遷移が分かってよかったりします。

---

■（３）（１）のハードコピーをがんがんとって

　仕様書書くために・・・
　画面全体が取れるフリーソフトとか持ってると、便利だよ！

---

■（４）仕様書にまとめる
　画面に関しては、業界で、統一した仕様、発注者ビューガイドライン画面編があるけど、まだまだ広まっていないとおもう。

　たいてい、画面の仕様書は

・画面遷移図
・各画面

で構成され、各画面の内容は、

・画面のイメージ
・画面項目
・アクション

が記述される。

画面遷移は、（２）で決めたから、それを図示する。
画面のイメージは、がんばって、（３）で書いた。
画面項目は、（１）でHTMLで作成するときに、項目をだしているので、
その項目に関してです。有効値などもかいておかないと、テストのときに
こまります。

アクションは、ボタンのところで、呼び出す関数やサーブレットなどについて
書きます。

---

ってなかんじです

翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる－その５

シリーズ化してしまった「翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる」のつづき

ローカライズするには、次の３つの手順が必要

（１）国際化対応プログラムになっているか確認
（２）翻訳
（３）翻訳したものを戻し、稼動するか確認

ということで、今（２）の翻訳部分です。

ここは、
（２－１）自動で行う部分
　　（２－１－１）翻訳機で翻訳する
　　（２－１－２）前バージョン上書き
　　（２－１－３）翻訳ワークベンチ用DBにいれる
　　（２－１－４）ID＋ステータス用を作成
（２－２）手動で行う部分
　　（２－２－１）仮訳
　　（２－２－２）訳語統一
　　（２－２－３）本訳
と細かく分けられ、前回までで、 「（２－２－２）訳語統一」を行いました。

今回は、そこで（２－２－３）本訳についてです・・
が、その前に訳語統一で書き忘れたところに関して

---

■訳語統一で書き忘れたところ

統一の例外と、文体について、ふれてなかった気もするので・・

・統一の例外
　訳語統一したものの、場合によっては、例外的に訳す場合は、そこの基準を書き出し、訳をする人に周知させます。

・文体
　エラーメッセージ等、「なになにしてください」にするか、「なになにせよ」にするかなど、文体をどのようにするかに関して決めます。また、動詞について、訳語統一すべきものがあれば、ここで挙げておき、統一辞書に追加します。

---

■本訳の手順

　で、前の段階で、訳語統一辞書ができたので、この段階で、新しく出来た訳語統一辞書を使って、「（２－１）自動で行う部分」を行います。

　ただし、前に仮訳した部分で、統一された用語と同じものは、それを使うようにしてもいいのですが、たぶん、その作業のほうが、めんどっちいです。全部訳しちゃったほうが早いです。

　で、これで、統一辞書で仮訳されているので、あとは、それを修正するというかたちになります。

---

で、翻訳まで終わって、あとは、「（３）翻訳したものを戻し、稼動するか確認」ってことになります。

ApacheのShindigって、OpenSocial（SNSの標準）のサーバーってことは・・

　これつかうと、自分でSNSが開設できるっていうことかなあ・・

　このまえ、Googleデベロッパー交流会で、

ApacheのShindig
http://incubator.apache.org/projects/shindig.html
っていうのを聞いてきた。

　Googleが行ったSNSの標準化APIであるOpenSocialのコンテナってことらしいんだけど・・

　っていうことは、こいつ使うと、SNSが自分で開設できるのかなあ・・？

　だとしたら、企業なんかで、自分と取引先とか、自分と仲間で情報共有して
　SNSやりたい人とかには、よさげな気が。。

　ウィリアムのいたずら、何か勘違いしてる？？
　

Microsoft、ニュースを政治傾向によって分類するツールを開発

ここのスラッシュドットニュース
Microsoft、ニュースを政治傾向によって分類するツールを開発
http://slashdot.jp/it/08/03/16/2315209.shtml
によると(以下斜体は上記サイトより引用）


Microsoftが、ニュース記事を政治傾向に応じて自動的に分類するプログラムを開発中だと言う(Washington Postの記事)。記事で取り上げられているのはMSRの研究者が開発しているBlews。ニュース記事がリベラル、あるいは保守的なブロガーのどちらから多くリンクされているかを判定の基準とし、加えてそうしたブロガーのブログ記事に出現するキーワードによって「感情強度」を計測することで、リベラルが喜ぶ記事、保守派が罵倒する記事などといった個々の特徴が自動的に分かるそうだ。


おお、中国とかで、欲しそうですよね（＾＾）

チベットという言葉が入ってるとき、
　　中国よりならOK、
　　チベットよりならX

でもでも、この程度なら、マイクロソフトでなくても、kizasiとか、どっかの人たちがやりそうな気が・・・

リベラルが喜ぶ記事、保守派が罵倒する記事は

日本だと、産経派の人が喜ぶ記事、アサヒ派が罵倒する記事とかいう感じになるのかなあ

アジャイルで不幸にした業界、法令工学を応用することで、幸せになれれば。。。

いいけどね！

せっかくコメント無視、匿名で書いているんだから、

もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。

最近、IT業界って、暗いとおもいませんか？

村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。

　こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。

　ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。

　さらに、テストに関しても、修正によって、影響が大きい場合、一時的に待つ等ということが行われました。つまり、テスト修正に対しても、管理されていました。これによって、仕様の矛盾がないように机上チェックが十分行われていました。

---

　しかし、アジャイル、とくにテストファーストにより、とりあえず仕様を作って、プログラム作っちゃおうっていう感じで開発がおこなわれました。仕様の矛盾チェックを十分にやることなく、プログラミングされます（そーいえば、仕様チェックを行うSEの地位も、がっくーん！と低下したよね。プログラマの地位が急激に向上して、立場が入れ替わった）。

　その結果として、安易な仕様変更がおこなわれ、五月雨式に仕様変更がおこり、その結果として仕様の矛盾が起こる。そのうえ、その矛盾は、つくってから気付く。結合テストで（さすがに、単体レベルの矛盾は作る前に気付く・・・と思いたい　＾＾；）。

　結合で、すぐに修正してしまうから、安易な対処的修正にながれ、さらに構成管理も崩壊し、結果として、デスマーチに突入、７K,１０Kの世界になる。

　でも、ユーザーはこれ幸いと、結合テストの期間が延びると、仕様変更をガンガンしてくるから、開発終了直前まで仕様変更される。。でも、アジャイルはこれを防ぐ論理がない。仕様が決まれば、プログラミングに移ってしまう。。

　この結果、さらに矛盾は拡大し、システムは崩壊し、品質は低下し、人身御供は増え、業界は不幸になった・・・

---

　この業界を少しでも幸せにしたいなら、

　昔のように、要求仕様管理が必要になる。

　要求仕様の変更を管理し、仕様変更の無矛盾性を確認し、その影響度合いを評価し、そこから、修正箇所とテスト項目を過不足なく抽出する技術が必要になる。

　で、こーいう要求仕様管理は、法令における「溶かし込み」という作業と同じことで、法令工学での研究対象のようだ。

　この分野の研究成果を応用し、要求仕様の変更を管理し、その仕様がほかに矛盾を起こさないかチェックし、その影響度合いを適格に評価したうえで、必要な仕様変更だけを、適切なタイミングで行えるような開発方法論を生み出してくれれば、この業界、少しは幸せになれそうな気がする。

　法律は、実体法と手続法に分けて考える考え方があるが、手続法は、業務フローの機能要件のようなものであるといえる。したがって、手続法における法令工学の成果は、要求仕様の機能要件の策定に多いに貢献できる可能性を持っている。

---

　しかし、法令工学の人たちが、こういうことに応用できると言い出さないのは、たぶん、そんなことをいって、アジャイルな人たちに邪魔されたくないんだろう。法律にアジャイルを持ち込めば、法が朝令暮改され、法の矛盾から社会は混乱し、人々は一挙に暗い社会に陥ってしまう。

　IT業界のように・・・


　ってことで、法令工学を応用することにより、IT業界が明るくなることに、期待はするけど、アジャイルな人たちが入ってこないように、そーっと見守っていく分野なのかもしれない。
　しかし、「これでいける！」となったとき、法令工学を応用して、一気に要求管理方法を取り入れた開発方法論におけるパラダイムシフトが起こる可能性も大だ。
　だから、JAISTのCOEの検証進化可能電子社会の今後には、そーっと要チェキなのだ！