なぜパッケージソフトは海外進出できず、ソーシャルゲームはできそうなのか？

　玉井先生の筑波での講演で、「パッケージソフトは海外進出できない」理由について、いろいろ議論していたけど、
ちょっと論点がずれている気がしたので、パッケージ会社に長くいて、今はいないウィリアムのいたずら様が、その
理由を書いてみよう。

　理由は、いくつかある。

■（１）コンピューター化するビジネスモデルが、アメリカ発の場合、どうしても、アメリカ産ソフトになる。

　たとえば、ＤＴＰソフトの場合、国内でどんなにＤＴＰソフトを作っても、
　最近は、「世界で同時に出版」とかいう場合もある。
　このような場合、世界的にビジネスを仕掛けるアメリカが、自国のソフトを
つかって、ビジネスモデルを組み上げ、それを世界にばら撒く。

　つまり、世界的にパッケージソフトを売るためには、そのパッケージソフトがサポートする
業務が、世界的になっていなければならない。
　日本は、ビジネスにおいて（製造業ではない、金融、流通などのビジネス）、世界をリード
するほどには、なっていない・・・（超大国なのに　　；＿；　）


■（２）そもそも、世界的にソフトを売るために必要な、金が用意できない。

　世界中に売るには、１００万本くらい売る必要はあると思う。
　１本１万円だと、１００億円の売り上げ。
　荒利益２０％だとして、２０億、とりあえずお金がかかる・・
　（１本も売れる前に・・・）

　まったくの新分野にたいして、「２０億投資して（＾＾）ｖ」と銀行さんにいっても、
お金を貸さないし、大企業にいっても、投資として通りにくい。
　もし、通したい場合・・・「アメリカでは、こんな事例があります」といって話を
もって行かないと。。。

　つまり、カネを出す人間（銀行、大企業など）は、日本発の世界的なソフトを出す
リスクをとりたがらない。

■（３）さらに、そこまでしてまで、儲けようという人がいない。

　世界的なビジネスをするには、リスクがあって、めんどっちい。
　そこまでするなら、日本でそこそこ儲けたほうがいい。
　たいてい、「パッケージソフトは海外進出するべきだ」という人は、大学の先生やお役人さんといった、自分では「するべきだ」といっても、やらない人たち。
　実際にやるとなったら、めんどっちいい。

---

　Ｒｕｂｙが成功したのは、

（１）Ｒｕｂｙの言語に、ビジネスモデルはない・・・
（２）Ｒｕｂｙを広めるのに、お金がかからなかった
（３）Ｒｕｂｙを広めたい人たちがいた（まつもとさんに限らず）

　なので、おなじように、上記３つの条件が揃えば、世界的に広まる可能性がある。

　ということで、ソーシャルゲームを考えると・・

（１）がちゃ、出会い系などは、日本発のビジネスモデルになりうる
（２）ＤｅＮＡ，グリー、カネはいくらでもありそうだ・・・
（３）ソーシャルゲームの会社は、海外進出をねらっているのでは・・・

というように、ソーシャルゲームは３拍子揃っているので、日本発、世界へ、ということになるかもしれない。

民放連次期会長「ＮＨＫの同時配信控えて」

最近、ＮＨＫは、ネット（らじるらじる）で聞いています。
音がクリアだし便利。録音もＭＰ３形式でできるし・・

ということで、ＮＨＫのラジオのネット配信は便利なのだが・・・


民放連次期会長「ＮＨＫの同時配信控えて」
http://headlines.yahoo.co.jp/hl?a=20120329-00000117-san-soci


へ、自分たちは、radikoとかやっているのに、なぜ？
ＮＨＫは、公共放送だから、みんなに聞いてもらうために、
ネット配信する必要があるのでは？

利用者の利便性を考えず、一方的に民放の都合を押し付けられても・・・

サウンドサイネージに初音ミクを使うのって、アリだと思う

　　　　ザ・テレビジョン

　この文字を見て、頭の中に、高音の「ざ・てれびじょーん！！！」っていう
音が再現された人、多いと思います。
　むかし、「ザ・テレビジョン」っていう本のＣＭで、かならず、その音が流れました。

　こういう、音でその商品などを宣伝するものを、「サウンドロゴ」といいます。
　そして、このサウンドロゴなどを（スピーカー等を置いて）街中に流して宣伝するのが、
　サウンドサイネージ（デジタルサイネージに対抗して？）

　さらに、これら音を使った販売促進を「サウンド・マーチャンダイジング」といいます。
　（日経情報ストラテジー２０１２年５月号　２１ページにありますね）

　このまえのリテールテックJAPANでも、ヤマハが、サウンドサイネージを出していましたね。
　（ＴＬＦスピーカーっていうのが、それ）

　で、こういうサウンドサイネージを行うには、まず、宣伝するコンテンツを作らないといけません。
　一般の人が、音楽やってる人とかに頼むのは・・・大変そう・・・

　そこで、サウンドサイネージに初音ミクを使う（初音ミクに、ザテレビジョーンって言わせて、
　それを流すような・・）のっていうのは、アリだと思います。

スケールアウト型ＳＱＬデータベース

日経Ｓｙｓｔｅｍ　２０１２年４月号の１０ページのトレンドに、

スケールアウト型ＳＱＬデータベースって言うのが出ている。

MySQL Cluster 7.2のような、ＳＱＬをしゃべってくれるんだけど、
ＫＶＳにも対応して、スケールアウトするというもの。

ただ、その記事で、明確に書かれていなくて、大事な点があると思う。
それは、ＲＤＢの特徴は「トランザクション処理ができる」という点に
あった。

ＭｙＳＱＬ Clusterは、トランザクション、レプリケーションを実現して、
単一障害点がなくmemchachedが使える・・という話らしいけど、
ＳＱＬをしゃべるかどうかより、業務的に導入するかのポイントは、

　　・トランザクションを使えるか
　　・単一障害点が存在するか／しないか

どうかのほうが、業務への導入のポイントじゃないかな？
・・・なことない？

Hadoopクラスタの推奨構成、推奨設定、運用のつぼ

ＯＳＣ２０１２で聞いて来た内容をメモメモ！

■Hadoop認定技術者が語る！Hadoopクラスタの推奨構成、推奨設定、運用のつぼ

Hadoop
　　キーは、分散ファイルシステム
　　もともとのコンセプトを知ること大事
　　　　　ＧｏｏｇｌｅにのＧＦＳ
　　　　　構成されているサーバーが安価：信頼性が低いもの
　　　　　　　→壊れることが前提の条件

ＨＤＦＳの基礎
・既存ＯＳのファイルシステム上で稼動できる
・ブロックごとに分かれる：デフォルト６４Ｍ（実際には１２８も多い）
・レプリケーション３がおおい
　　　１Ｔだと、３倍・・３Ｔでいいわけではない、もう少しいる

・大きいファイルを少ないノードで管理するのがとくい
　　　１Ｍを２０００台より２Ｇ１個のほうがいい
・シーケンシャルのほうがとくい
　　　ＭａｐＲｅｄｕｃｅに置き換えられる：レイテンシがある
　　　ＲＤＢのようなものは向かない
　　　Ｈｂａｓｅ（ＫＶＳ）はレイテンシを低減している
　　　大きいファイルはＨＤＦＳ
・ＨＤＦＳは数十Ｐでも問題ない
・ファイル追記は正式にはサポートされていない
・大きなファイルをブロックに分けるのがいい

・単一障害点が存在する
　　　ネームノード
　　　　　とくにfsimageとedits
　　　　　バックアップいる

・ＲＡＩＤだと性能落ちる→ＪＢＯＤ

・実は中間ファイルもできる：ディスク容量注意
　　　ログも激しく書かれるので注意

・サーバー１台にＨＤＤ４～１２台

・サーバー構成
　　ジョブトラッカー→タスクトラッカー
　　　小規模構成（～２０台）
　　　　　ネームノードとジョブトラッカー同じサーバー
　　　それ以上
　　　　　ネームノードとジョブトラッカーサーバー分ける

・Ｈａｄｏｏｐのシステム拡張
　　　５～８ノードくらいからはじめ
　　　追加（３種類）
　　　　　　計算能力必要＝ＣＰＵ不足
　　　　　　大量データ＝ハードディスク
　　　　　　配列処理（mapReduce)＝メモリー追加
　　　データノードとレプリカから、購入頻度がわかる
　　　メモリ：１アイテムあたり２００バイト消費
　　　　　　→ファイルの個数が重要
　　　　　　　ファイルの個数が増えると、アイテム数が増え、
　　　　　　　最悪、スワップが走る

・セカンダリネームノード
　　　ネームノードのふぇ－ルオーバー先では「ない！」
　　　ネームノードの負荷を軽減するために、ある処理が動く

・Ｈａｄｏｏｐの設定
　　　１個１個ＢＩＯＳ画面を見て設定するのは、現実的でない
　　　　→ＢＩＯＳの設定を吸出し、配布する必要
　　　　　ＨＰはフリーでそういうツールがある
　　　　　HP SmartStart Scripting Toolkit

　　　マウスで設定でいいわけではない。

・Ｕｂｕｎｔｕ（Fedoraは推奨でない）
　tar-ballからだと、少し操作方法が変わることも

・タスクトラッカー、MapReduceは障害があっても手順がある。
　JobTrackerに障害が起こると、ＪＶＭタスクの動作は不安定
　　　→ジョブのやり直しになってしまう
　　　　　　→ＦＴクラスターでできる？

・スワップさせたら負け
・ＮＴＰを必ず設定、時刻大事
・Ｈａｄｏｏｐのパラメータを行うＸＭＬファイル
　　　→クラウディアさんのところにデフォルトあり

・ＤＬ１８０を使っているお客さん多い
・既存のＤＢからＳＱＯＯＰを使って、Ｈａｄｏｏｐに入れることができる
・非定型は、FlumeでHadoopへ

MySQL User Forum Tokyo

あ、昨日のに書き忘れていた。
昨日のＯＳＣ２０１２で聴いてきた話で、

４月３日に、
OTN MySQL User Forum Tokyo
を、日本オラクル株式会社本社13Fセミナールーム
でやるらしいよ
　参加費無料だけど、事前登録が要るみたい

くわしくは

OTN MySQL User Forum Tokyo
～MySQLの最新技術動向から技術概要、トラブルシューティングまで一気にお聞きいただける絶好の機会～
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=150351&src=7560060&src=7560060&Act=4

ＭｙＳＱＬでＮｏＳＱＬ(memcached)サポート

今日、ＯＳＣカンファレンス２０１２で聞いてきたことをメモメモ

---

■MySQLとＮｏＳＱＬ
（ＭｙＳＱＬ最新動向＆ＭｙＳＱＬ　Ｃｌｕｓｔｅｒ７．２）

・世界で最も普及しているオープンソースデータベース
・なぜOracleがMySQLをもつのか？
　　より多くのお客様、幅広いニーズを満たすため
　　　　→Ｗｅｂサイト
　　　　→組み込み案件
　　各種のoracle製品が、ＭｙＳＱＬ対応
　　Ｔｗｉｔｔｅｒ：ＣａｓｓａｎｄｒａからＭｙＳＱＬに戻る
・Facebook memcachedを前に使ってる
・ＯＥＭ、組み込み→adobe,F5Networkのロードバランサ
　　　　　　　　　　　Ｐｏｓｇｒｅからのマイグレーション
　　　　　　　　　　　　（バキュームの問題）
・ＡｍａｚｏｎＲＤＳ：ＭｙＳＱＬ
・aadhaar:インド版国民総背番号制
　　　　ＭｙＳＱＬ：トランザクション処理
　　　　Ｈａｄｏｏｐも使っている　
　　　　レプリケーション：ディザスタリカバリへ

・ＭｙＳＱＬ　Ｃｌｕｓｔｅｒ
　　・アクティブアクティブがた、シェアードナッシング
　　・障害が起きても、処理を継続　ストライピング＆ミラーリングの考え方
　　・トランザクション対応のキーバリューストアへ
　　・トランザクショナル＆リレーショナルＤＢ
　　　　　トランザクションでキーバリューストア可能
　　・９９．９９９（年間で障害ダウンしてるのが５分）
　　・携帯電話ネットワーク（エリクソンで）
　　　　　単一障害点がない

・ＭｙＳＱＬ　Ｃｌｕｓｔｅｒ　７．２
・１分間で１０億件クエリーをさばける
　　　８台、メモリ４８Ｇ
　　　インフィニバンド
　　　ＮｏＳＱＬのインターフェースで
・アダプティブクエリー・ローカライゼーション
　　１１個のＪＯＩＮ（８７秒）→１，２６秒
　　物理環境では、２３０倍
・ＭｙＳＱＬでＮｏＳＱＬサポート
　　memcachedに対するプラグイン
　　　キャッシュに話しかける
　　　→memcached API
　　ＫＶＳなのに、トランザクション対応
　　レプリケーションもできる
　スキーマフリーもＯＫ，
　既存のテーブルもＯＫ→設定済み
・ＡＰＩの柔軟性　Ｃ＋＋、Ｊａｖａも
・仮想環境
・遠隔地レプリケーション
　　→マルチサイトクラスタリング
　　　ネットワークはよくないとだめだけど・・

・ＭｙＳＱＬ Cluster Manager

・ＭｙＳＱＬサーバー
　　現在５．５
　　現在５．６
　　　　オプティマイザ
　　　　パフォーマンススキーマ
　　　　ＮｏＳＱＬオプション

・あと商用版のお話など

スマホアプリで「マネタイズできている」は3割--計画通りは4％

スマホで儲けるのは、むずかしいものがあるんでしょうな。
ちなみに、

現在リリースしているスマートフォンアプリのマネタイズ方法では「無料アプリ＋広告」と回答した運営者が39.4％と最も多く、次いで「有料アプリ」が31.0％、「無料アプリ＋アプリ内課金」が29.6％という結果となった。

なんだそうな。やっぱ、広告としてのアプリが有力？


スマホアプリで「マネタイズできている」は3割--計画通りは4％
http://headlines.yahoo.co.jp/hl?a=20120315-35015184-cnetj-sci

（このエントリー内の太字は、上記ニュースより引用）

Ｍ２Ｍクラウドは、いいかもしれない・・でも・・

日経コンピューター２０１２年３月１５日のＭ２Ｍクラウドの話（７８ページ～）。
Ｍ２Ｍ（センサー情報を適当（いや適切）に処理して、アクチュエーターなどを操作する）
は昔からあった話だけど、クラウドになることにより、遠隔操作できたり、スケールアウト
できたり、という点は、たしかにいいかも！
とくに、スケールアウトメリットは大きいと思う。最近、システムリソースの大きさをはじめから
予見できない部分があるからねえ・・

ただ、レスポンスタイムは見切れない部分がある。
やっぱり、リアルタイム処理となると、現場にも、マシンが必要か？
例えば、小売業だと、ＰＯＳレジデータを、一回ストアコントローラーに纏めていると思う
（って、習った）
それと同じように、センサー情報を一回現地レベルで集計、処理できるサーバーを用意しておいて
（このサーバーから、アクチュエーターも操作でき、ある程度の俊敏な処理は出来るようにしておいて）
そのサーバーからクラウドに送るという「からくり」も必要かもしれない


・・・けど、そーなると、そのサーバーの保守とかがあるから、クラウドメリットが半減するかな？
でも、それでも必要だし、集計だけでも、メリットある気がする。クラウドの・・

超高速開発のＢＲＭＳっていうけど・・・

　日経コンピューター２０１２年３月１５日の特集は”「超高速開発」が日本を救う”ということで、ビジネスプロセスを入力することで、画面の自動生成をするとかいうツールを使った開発が、紹介されている。

　しかし、この手の開発は、Ｅｘｃｅｌを使った仕様書によって、大手開発会社（富士通とか）は、導入済みじゃないだろうか（INTARFRMとか、そうじゃなかったっけ？）。

　そして、この手の話がうまくいかない理由も、もう判っているのではないだろうか？
　つまり、「うちの会社は特殊で・・・」
　という形で、業務フローがまとまらない。

　今話題なのは、その先の話で、業務フローを単純に纏めようとすると、まとまんないから、基本的なビジネスプロセスと、各社で変更されるようなビジネスルールを分けるという話で、こうすると、業務フローがまとまりやすいという流れが、欧米で出てきている（次のＢＡＢＯＫとか）という話が、

第６回　要求シンポジウム　その１
http://blog.goo.ne.jp/xmldtp/e/55b28377d6199b9b66063216f6fa1b3b

で書いたこと。
ファクトモデルとか、ＳＢＶＲとかの話につながっていくんだけど・・

そこまで書いてないと、「いまさら感」になってしまう。

ＲＤＢに適しているもの、ＮｏＳＱＬに適しているものを結合の観点から

まとめてみた。

【テーブルを結合しない】
　　・どちらでもよい


【自己結合してしまう】
　　　・ＮｏＳＱＬが向いている
　　　・レコードレベルで、ツリー構造になっているはず。
　　　　　　複雑になると、ＲＤＢには向かない
（自己結合：
　　看護婦と婦長のように、同じテーブルのレコード内で親子関係があるため、
　　自分のテーブルを別名をつけて結合する）



【１対Ｎの多段階構造】
　　　・ＮｏＳＱＬが向いているがＲＤＢでもよい
　　　・テーブルレベルでツリー構造になっているはず。
例：テスト→問題→選択肢のような関係で、問題を使いまわさない。


【１対Ｎが、２箇所から来ている、Ｎ対Ｎ】
　　　・ＮｏＳＱＬだと、更新時に問題が出る
　　　　　　→が、それをクリアすれば良い
　　　・ＲＤＢでＪＯＩＮする
　　　　　　→遅くなる場合がある※

例：受注明細（受注１→受注明細Ｎ　と　商品１→受注明細Ｎ　の２箇所）
　　テスト→問題→選択肢のような関係で、問題を使いまわす。


※ＲＤＢで結合が遅くなる場合：対策
・マテリアライズド・ビューを使う（Oracleのみ）
　　→自分でマテリアライズド・ビューもどきをつくる

・クエリーキャッシュを使う
　　→自分でキャッシュしてがんばる

電機、メガソーラー推進－クラウド会社にも、必要ですよね、メガソーラー

電機各社が、メガソーラーに力を入れているらしい。


電機、メガソーラー推進　各社、買い取り制度追い風
http://news.goo.ne.jp/article/sankei/business/snk20120312102.html

たしかに、テレビ事業では赤字なので、儲かるところ・・・というと、メガソーラーなんですかね。

実際、メガソーラーをの太陽光電力発電をはじめとする新電力は、

＜特定規模電気事業者＞新電力　人気に思わぬ落とし穴も
http://headlines.yahoo.co.jp/hl?a=20120312-00000027-mai-soci

にもあるくらい、超人気だし・・・

やっぱり、この一因は、今年の夏、東電がちゃんと電気を提供してくれるのかどうか不安というのもありますよね。
クラウド会社も、２４時間運営のためには、必要かも？メガソーラーとかの新電力！

原子力におけるセーフティケース（安全性を保障するための論拠）

　セーフティケースという概念がある。
　安全性（セーフティ）を証拠を元に立証することで、イギリスで、主に考えられているもののようだ。
　まず、ハザード分析やリスク評価（Ｈ＆Ｒ）を行って、それに対して、安全だよ！という証拠をだして、立証していく。

　分野ごとに、いろいろなセーフティケースがあって、

　　　自動車だと、ISO26262やMISRA（みすら）-SAなど、
　　　軍事ではDef Stan 00-56 issue4 2007、
　　　鉄道だとBS EN 50129:2003
　　　原子力だとSAP(Safety Assesment Principle)2006

　なんかがあるみたい。

　と、ここまで、このまえ、SEA-SPINで聞いてきた。

---

　ってことを思い出して、いま「原子力　セーフティケース」で検索すると、おもに、「高レベル放射性廃棄物処分」の話のようだ。
　ストレステストとかは、こういう形で立証しないと、まずいんでないかい？と思い、ぐぐって見たら

原子力発電所に対する欧州「ストレステスト」
http://www.greens-efa.eu/fileadmin/dam/Documents/Studies/Nuclear_Stress_Test/Stresstests%20(JP).pdf

なるＰＤＦが出てきた。そこにセーフティーケースという言葉は出てくるのだが。。。

そうだね。そこに書いてあるように、
セーフティケースは、一度決めたらいいってもんじゃないよね。
技術的に最新のものにした上で、チェックしないと・・・

日本のストレステストは、どうなってるんでしょうね？
福島の状況を反映しているのかな？

ツンデレで、ビッグデータの問題点を考えてみる

ビッグデータ＝統計の専門家まかせという考え方で、大丈夫か？
http://blog.goo.ne.jp/xmldtp/e/c38a65222b83fa67b55539d71b6e769c

で書いたことがわかりにくい気がするので、ツンデレを使って、具体的に説明してみる。

---

■ケース

　こういうケースを考えましょう。

　トモダチ関係を分析するため、
　　　スカイプの音声を全部録音して、
　　　それをテキストに自動変換し、
　　　そのテキストを使って、
　　　　テキストマイニングで
　トモダチ関係を判断するとします。

　Ａさんは、Ｂ君に、ひどいことを１００回いいました。
　　でも、やさしいことを３回いいました。

　Ａさんは、Ｃ君にやさしいことを５回いいました。

　Ａさんは、Ｂ君とＣ君、どちらがすきでしょう。

　答え　Ｃ君

　とは、いいきれないよね。

---

■ビッグデータと統計の関係

　スカイプの音声のテキストマイニングなんて、まさに非構造データなわけで、
これの解析というと、ビッグデータになりそうだ・・・
　さて、このとき、統計的に単純に平均とかを出せば、
　　Ｃ君のほうに、優しい言葉をかけている回数が多いから、
　　すきなのはＣ君となる。


　しかし、これは不自然だ。
　ひどいことを１００回も言ってＢ君と付き合っているとしたら、
　Ｂ君がいじめられっこか、Ａさんがツンデレと考えたほうが自然だ。

　しかし、そんなことは、統計からは出てこない。
　統計から出てくるのは、あくまで、

　Ａさんは、Ｂ君に、ひどいことを１００回いいました。
　でも、やさしいことを３回いいました。
　Ａさんは、Ｃ君にやさしいことを５回いいました。

しか出てこない。
これをみて、ツンデレと判断するのは、あくまでも人間の判断になる
人間の判断だから、正しいかどうかは判らない。

---

■潜在変数、因子の発見

　つまり、統計では、表面的なことは出てくるが、もう一歩、奥に入った
ところ、つまり潜在意識、統計用語だと因子（因子分析）や潜在変数（共分散構造分析）
が知りたいとなると、人間の判断が入ってくる。

　たとえば、因子分析だと、Ａさんが、Ｂ君Ｃ君Ｄ君、Ｅ君に対して、もっといろんなデータを
あつめてきて、それを表（行列）にして、それに対して、因子分析をかけるわけだけど、
その前に因子の数を大体決める。そして、分析すると、因子負荷量は出してくれる。
　出してくれるけど、その値が、どういう意味かは、自分で考えないといけない。
　コンピューターは、考えてくれない。

　そうすると、自分で考える・・・といっても、今の場合だと、Ａさんのような女子高生
（あれ、設定、女子高生だったっけ？女子高生とする）に詳しいおじさんじゃないと、
よくわかんないわけだ。


　で、共分散構造分析（ＳＥＭ）をする場合、その構造がわかんなければならない。

　ツンデレの場合、２つの構造が、すぐに思いつく。
　１つは、ツンの要素とデレの要素、それぞれが、行動に関係しているというもの


　もうひとつは、やっぱり、デレ（愛）の要素が根本にあり、それがツンフィルターによって、
ゆがませられた上に、気まぐれ要素eの誤差項の影響を受けたのが、行動という考え方。


　これのどっちがいいかは、共分散構造分析をすれば出てくるかもしれない。
　だけど、この２つの構造でいいのか？っていう問題がある。
　ツンデレは、もっと複雑かもしれない。
　こういうことは、やはり、「ツンデレ評論家」の女子高生好きオジサンでないと、わからないのだ。

---

■ビッグデータはむしろ、業界専門家が必要

　ということで、ビッグデータは、女子高生好きオジサンがやるのがいい・・・というわけではなく、
　データからモノを判断する場合、潜在意識までさかのぼってしまうと、それらしいことを言える、
業界の専門家が必要になる。

　逆に、統計の専門家が、本当に必要かというと。。。システムが出来てしまえば、あとは使うだけ
なので、使い方がわかればいいってことになる。

　上記の共分散構造分析の場合は、ＳＰＳＳ　Ａｍｏｓが判ればいいって言うことになるし・・

　というわけで、統計の専門家だけで大丈夫か？
　ツンデレ解析できるか？
　統計専門の数学科の人がツンデレ解析すると、おかしな方向に行かないか？

　ってことになる。

イマドキの新人教育の課題といったら・・・

むかし、スラッシュドットで話題になったけど・・


新人教育向けの秀逸な課題プログラムって？
http://developers.slashdot.jp/story/09/06/02/0520208


やっぱ、掲示板だよねえ・・・

機能要求だけじゃなくって、非機能要件の説明も出来るし、
セキュリティや高速化の話も出来るし、
DDos攻撃して、新人をいじめることもできる・・・

---

でも、大学って、酒屋倉庫問題や、図書館問題が多いよね・・・

うん、図書館・・・
やっぱ、イマドキの図書館問題は、
外部公開用のＡＰＩを作って、外部からアクセスさせて、
バグの問題、法律の問題、世渡りの問題まで、研究させるんでしょうか

・・・奥が深い・・・

でも、法律のお勉強は、新人教育にいらないかな・・・
（自分のバグを棚において、他人を攻撃する世渡りの教育は必須　！！）