ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

「今出しょう子」が、「エイっ子」に載っているそうです。

2013-04-16 20:27:49 | Weblog
あ・・・・

ここのブログ

Windows XPのサポートが終わったら、Microsoftも終わるんじゃないだろうか【連載:村上福之】
http://engineer.typemag.jp/article/fukuyuki-microsoft

(以下太字は、上記サイトより引用)
は、いろいろと意見があると思うけど、
(私も反対意見はあるが)
一番共感しそうなのは。。。

外部と組んだキャンペーンでは萌えキャラも作ったのですが、やっつけ過ぎなので、一部で、いまいち萌えなくて話題になっているようです。

Windowsストアアプリ選手権のキャラ「今出しょう子」がやっつけすぎると話題


だと思います。
そのページ

Windowsストアアプリ選手権のキャラ「今出しょう子」がやっつけすぎると話題
http://matome.naver.jp/odai/2136548553359418201

を見ると・・・

もう、ネーミング「今でしょう!子」っていうところから、やっつけすぎですが、
ポスターが

ですよ(上記サイトより引用)
(Windows 8=)エイっとつくろう・・・
だそうです・・・


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「大学入試にTOEFLを」に、大学情報系の高度ICT人材育成の失敗を感じる・・・

2013-04-16 17:15:13 | Weblog
最近、「大学入試にTOEFLを」という話が話題のようだ。
その中でも、話題沸騰?の・・・

教育再生実行本部の「提言」全文入手
http://blogs.yahoo.co.jp/gibson_erich_man/32702333.html

(以下太字は上記サイトより引用)
を見ていて思ったことをちょっと書いてみたい。




今回の提言は

「結果の平等主義から脱却し、トップを伸ばす戦略的人材育成」

だそうな。あ~、トップを伸ばす・・・懐かしい響きですね。


コンピューター業界にも、ありました。
経団連の

「産学官連携による高度な情報通信人材の育成強化に向けて」
http://www.keidanren.or.jp/japanese/policy/2005/039/honbun.pdf

実はこれ、上記のPDFの11ページはじめを見てもらうと判るけど
(以下斜体は上記サイトより引用)

将来的には、このようなトップレベル層の高度ICT人材は新卒者として毎年3,000人程度必要になる。
このような人材を早期に育成するためには、従来の大学・大学院にはない、高度なITの専門教育や、ソフトウェアの開発手法等の研究開発を行なう、実践性を備えた世界レベルの先進的IT拠点(先進的実践教育拠点)を、意欲を持った大学・大学院から選抜、もしくは新設し、産学官連携による重点的な資源投入の下、トップレベルの高度ICT人材を育成する必要がある


というので始まった、高度ICT人材、つまり、ICTの「トップを伸ばす戦略的人材育成」だった
わけだが、結果はどうなったか・・・




大学でPBLを行ったりすることは多くなった。
基本情報とかを取る人は増えたかもしれない。

でも、この活動で、オープンソースで活躍した人が増えた?
ここ数年、新入社員のプログラム能力やシステム開発力が上がっているだろうか?
将来的に、トップを担う人材が、どんどん採用できるようになったであろうか?


結局2011年の経団連の提言

今後の日本を支える高度ICT人材の育成に向けて
〜改めて産学官連携の強化を求める〜
http://www.keidanren.or.jp/policy/2011/096honbun.html

では、(赤字は上記サイトより引用)


卒業時点で、システム開発の経験を求める声は多くない。


そして、

経団連のアンケートによると、今後、企業の中核を担う高度ICT人材に求める資質として、リーダーシップを発揮し最後までやり遂げる能力、自社や業界を俯瞰できる能力、課題・リスク等を分析し対策を立案・実施できる能力といった、高い能力が求められている。製品開発や自社のビジネスに係る情報のデジタル化やプロセスの管理に留まらず、様々な情報、機器、ヒトの融合による新しい社会の創造に向け、ICTを利活用した変革を牽引していくリーダー人材が望まれている。


それって、プログラム開発したり、システム設計したりでは、養えない力でないかい?

英語も、こんな風になる可能性が大きいと思う。




トップに必要なのは、語学力やシステム開発力も、さることながら、


リーダーシップを発揮し最後までやり遂げる能力、自社や業界を俯瞰できる能力、課題・リスク等を分析し対策を立案・実施できる能力といった、高い能力


なのですよ。それに資する能力というと、

英語だと
・リーダーシップを発揮し最後までやり遂げるために必要な、コミュニケーション能力

だし、

ICTだと
・リーダーシップを発揮し最後までやり遂げるために必要な、システム開発能力

となる。ところが、この力は、いままでも養っていないし、今も養っていない。




まず、ICTの世界から話そう。
2006年当時、そして今でも・・・以下の3つの問題があった

・そもそも、システム開発手法が固まっていなかった
・そのような状態では、先生が適切な教育をしているかどうかわからない
・ということで、明確なテストの合否に大学が走っていった。

以下、順繰りに見ていく。




<<そもそも、システム開発手法が固まっていなかった>>

 システムは、この手順でできる!というのは、1995年ころには固まっていて、情報処理試験の96年版の教科書?テキスト?には、この手法が載っている。これは構造化設計で書いてある。

 しかし、オブジェクト指向で一貫性を持ったものが出てき始めたのが2004年ごろから。
 そのころかな?に出てきたICONIXで、一端の完成をみた・・・
 ・・・が、この方法では、現在の開発実務が、できないのだ・・・

 ICONIXでは、画面分割の話とかは出てこないし、コントローラーの創り方は一通り(現場では、採用するフレームワークによって変わる)だったりする。このほか、いくつか実務的に問題がある。

 いまだに、全工程を、全部矛盾なく見せるというのは、各企業のフレームワークではあっても、オープンソースやAstahを使っては見たことがない。

 だから「Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法」というシリーズをやっているわけだ。





<<そのような状態では、先生が適切な教育をしているかどうかわからない>>

 そこで、現場の先生は、現在の全工程を開発したのではない人、

 つまり、
  ・賢い大学を出て
  ・かなり昔に現場の経験を持ち
  ・今はマネージャー、研究員、もっと偉い人が
  ・昔の開発手法に基づいて
 教えているという状況になった。

 その結果、構造化手法に基づいた教育
  DFD書きましょうね
  ER図書いてね!
 という方法を教えた後で・・・

 じゃ、
  Javaで開発してみましょう!
  PHPで開発してみましょう!!

・・・どうやって??
・・お前(=先生)がDFDから開発して見ろよ!(-_-;)
という結果になった。

 その結果、授業とPBLが切り離されるか、
 PBLでは要求までとか、もしくは、画面設計書を作って実装
・・・という話になってきた。




<<ということで、明確なテストの合否に大学が走っていった>>

 はっきり言って、ばんばんモノが作れるなら、情報処理試験受けなくたって、アピールできる

「即戦力になる男-オレのGitHubをみてくれ(^^)v」
 でURLだけ書いておけば、そのものを動かしてみれば、能力はわかる。

でも、そこまで即戦力になる男(女)は、大学ではつくれない。
あんまり、DFDやIDEF0書いて、オープンソースの開発は、
していないと思うぞ(ER図は、わからんが・・・)

 そこで、大学は、情報処理試験に走った。

   ITパスポート受からせよう、
   基本情報を受からせよう

 ・・と・・・
 でも、それで、
「リーダーシップを発揮し最後までやり遂げるために必要な、システム開発能力」
が身に付くかは、かなり疑問なのだが・・・




英語も同じ道をたどっているようだ。

幸いにも英語は、
<<そもそも、システム開発手法が固まっていなかった>>
のレベルである

・「英語の会話のための文法」は固まっている

 まず、大西泰斗先生の、一億人の英文法とかに書かれている内容でいいだろう。




しかし、その次の段階

<<そのような状態では、先生が適切な教育をしているかどうかわからない>>

は、はなはだ疑問だ。
英語の先生が、本当に英語を話せるのなら、

・日本の伝統や文化など、日本人として必要な教養を身につけ、国際的に発信できる力を育成

なんて簡単だ。大学生に、観光地に生かせて、英語でガイドさせればいい。
ワキで先生が見ていて、もし、学生がおかしなこといったら、即座に訂正すれば
いいだけの話だ。果たして、できるか・・・


・小・中・高等学校における英語教育を抜本的に改革・強化、その一環として学校教育において英語に触れる時間を格段に増加(土曜日の活用、イングリシュ・キャンプ、タブレットPC等の活用)

なんてのも簡単。
そもそも、タブレットPCを持っていても、英語に触れる時間は、増えない。
タブレットPCで勉強するやつは、今、カセットテープでも勉強する。

強制的に英語を聞かせるなら、給食の時間、校内放送を英語でしゃべればいい。
毎日30分は、必ず英語を聞く羽目になる。

で、英語の先生が、30分間、ぶっ続けで英語をしゃべれるか、DJできるか・・・

でも、逆に、通訳・ガイドの人や、Radio Japanの人が、
大学や高校に行って、英語の授業をする機会は、すくないわけだ・・・





だから、結局

<<ということで、明確なテストの合否に大学が走っていった>>

となり、TOEIC,TOEFLに走っていこうとしているわけだ。

本当に英語ができるなら、簡単だ。

エントリーシートに

「私は英語が流暢にしゃべれます。嘘だと思ったら、面接時に英語で質問してください」

と書けばいいだけのことだ。採用する企業は、英語でしゃべってくるだろう。
それに、答えればよい。

その自信がないから、テストの点でごまかしているんだろう・・・




というわけで、現状の「高度ICT人材育成」状況をみると、英語で、どういうことになるかは・・・
・・・想像がついたりしますね・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(2)

2013-04-16 14:11:13 | 開発ネタ
昨日、

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(1)
http://blog.goo.ne.jp/xmldtp/e/ca9cc98062afa09603680042d6dc8f86

で書いた話の続きなんだけど、今日は大事なところなので、
進捗をゆっくり、その代わり、丁寧に話す。




昨日、


(1)ユースケースに対して、そのアクティビティを書いて、
   要求を明示するよねえ
    →ユースケース図、アクティビティ図

(2)そのアクティビティに対し、入出力を明示し
   (ここが入出力設計、UI)


をやった。実は、(3)、(4)を飛ばして


(5)アクティビティ図の入出力に対する部分がViewとなり、
   クラス図(ER図に相当する)ところが、モデル(DAO)になり
   アクティビティは、Viewを受ける部分にあたるので、コントローラーとなる。
    →コントローラーが
       クラスとなるか(Struts,Actionクラス)
       メソッドとなるか(CakePHP,Zendなど)
     は、フレームワークやアーキテクチャによる
   これで、アーキテクチャに基づいたクラス、メソッド割がきまる。

の途中までをやると、やりやすい(理由は(4)を説明するときに言う)

ので、今日は(5)の途中まで




■Viewのクラスを作る

昨日、アクティビティ図を作った。
そのとき、オブジェクトノードを入れた。
そのオブジェクトノードをクラス図に描く。

画面はステレオタイプをViewとし、
データ部分(DBのテーブルとか)は、ステレオタイプをModelとしよう。

そうすると、まず、こんな形に書ける。




■Viewのデータを入れる

次に、入出力するデータを、とりあえず、全部入れる。

アンケート画面は、問1~問5まであった
 なので、こんなカタチ


集計結果表示画面は、
 問1~問4まで:円グラフ
 問5:棒グラフ
 問2、問3については、思う、思わないをクロス集計
 (きのうの、間違えていました。問2と問3のクロス集計です)

ここで、サーバー側でグラフをビットマップで作り、表示する手もあるけど、
今回は、そうではなく、クライアント側に数値を送り、それをGUIで組み立てるとする。
そうすると、必要な数字は

問1を円グラフにするには、
  問1Aの人数、問1Bの人数がわかればできる

問2を円グラフにするには
  問2Aの人数、問2Bの人数がわかればできる
  (総数は、問1Aの数と一致するはず、しなければ無回答)

問3を円グラフにするには
  問3Aの人数、問3Bの人数がわかればできる
  (総数は、問1Aの数と一致するはず、しなければ無回答)

問4を円グラフにするには
  問4Aの人数、問4Bの人数、問4Cの人数がわかればできる
  (総数は、問1A+Bの数と一致するはず、しなければ無回答)

問5を棒グラフにするには
  問5A、B,C,D,E,F.G.Hの各人数がわかればできる
  (総数は、問1A+Bの数と一致するはず、しなければ無回答)

問2、問3のクロス集計を作るには、
  (1)問2Aかつ問3A
  (2)問2Aかつ問3B
  (3)問2Bかつ問3A
  (4)問2Bかつ問3B
の人が判ればできる。
 そして、(1)~(4)がわかれば、
 問2の円グラフ、問3で円グラフの人も計算でもとまるのでいらない。

まとめると、これだけの値がいる

  ・問1Aの人数、問1Bの人数
  ・問2Aかつ問3A、問2Aかつ問3B、問2Bかつ問3A、問2Bかつ問3B
  ・問4Aの人数、問4Bの人数、問4Cの人数
  ・問5A、B,C,D,E,F.G.Hの人数

ただし、それぞれ持っていると、大変なので、配列にしてもっている

  問1[0]は、問1Aの人数、問1[1]は、Bの人数
  問23[0]は問2Aかつ問3A、問23[1]は問2Aかつ問3B・・・

で、こんなかんじになる

今回、送信完了と、集計画面では何も送らないので
属性は入れない
(一般には、集計画面で、表示したいアンケートを選んだりするが、
 今回は1種類しかアンケートがないので)

ということで、こんなかんじ。




■Viewにメソッドを追加する

 Viewにメソッドを追加する。
 メソッドは、アクションを起こすところ
   =結果として、イベントを起こすところ
   =多くは、ボタンをおしたり(場合によってはタイマーもありだけど)

となる。

 ということは、アクティビティ図で、画面から、システムに行くところは、必ず
メソッドになる。そして、これは、ボタンをおしたときなどのアクションに結び付く
(実装上、メソッドとしてJavascriptの関数で書くか、FormタグのSubmitボタンに
 なるかは、この時点では決めなくて良い)

 今回は、あとあとの若干の理由から、「初期表示」も入れる

 また、結果表示画面は、初期表示より、結果表示のほうがいいので、そうした
 (ここで、メソッド名は、正直、どうでもよい。かっちょ良いのにしてくれ)

 こんなかんじになる。





■画面分割

ここで、1画面で表示しきれない、表示しないほうがいい場合は、画面分割する。

集計結果表示画面は、いいとして、アンケート画面は、このままだと困る。

  問1で、「いいえ」と答えた人は、問4に飛ばないといけない。
  問2と問3を同時にだしてしまうと、問2に答える前に
    日本の「卵かけ御飯」が「絶対に危険な食べ物」に選ばれる…中国
    http://blog.livedoor.jp/dqnplus/archives/1758248.html
   を見られてしまう可能性がある→その場合、問2の意味なし
   問2と問3は分離しないといけない。そして、後に戻れないようにする。

結果として、こういう画面割りにしないといけない

  問1
  問2
  問3
  問4・5(4と5は一緒の画面でいい)

そこで、Viewの画面を分割する。
分割は(かっこ内は、問1画面の例)、

  ・分割した画面のクラスを作る(問1画面クラス)
  ・分割した画面で表示(入力)する項目をつける(属性問1を追加)
  ・もとの画面(アンケート画面)から、
    分割した画面の属性を削除(アンケート画面の属性問1を削除)
    分割した画面を集約か、コンポジションかにして、線を結ぶ
  ・分割した画面(問1画面クラス)にメソッドを追加する
    →その画面で起こすアクション

この結果、
  ・もとの画面の属性が全てなくなれば(今回はそのケース)
    その画面は抽象的にまとめたもので、実装の必要はない
    このとき、元の画面(アンケート画面)のメソッドは、
    集約した=分割した画面のメソッドのどこかに対応する
    はず(アンケート画面の回答実行=問4・5の回答実行)

  1個でも属性が残れば、
    その画面は必要になる

これらの処理をして、必要となった画面を、
appview(でもdispでもなんでもいい、viewと区別する)という
ステレオタイプに変えておく。あとで判りやすくするため

結果、こうなる





今回は「受注明細」のような画面のかたまりや、
「年月日」といった、型の話は出てこなかった。
その操作は、次回、はなそう。

それと、「集約」でも「コンポジション」でもどっちでもいい
と書いたけど、実は、分けられる(その上で、今回は集約を使っている)
その理由も書くかも?

さらに、その後で、コントローラーなんだけど、コントローラーに行く前に、

(4)その後、MVCアーキテクチャを採用したとすると、
   なんかのフレームワークを決めて、

を説明する。ここで、「初期画面」を入れた謎などが、解ける
んだけど・・・ここまではいかないかな?

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

グーグルに差し止め命令 検索予測表示(サジェスト機能)めぐり

2013-04-16 09:56:52 | Weblog
このニュースなんだけど、サジェスト機能全てに対してなのか、
この名誉が傷つけられたという人に関する表示だけなのか?
サジェスト機能全てだとしたら、大問題の気が・・・
さすがに、そうじゃないよね・・



グーグルに差し止め命令 検索予測表示めぐり 東京地裁初判断
http://headlines.yahoo.co.jp/hl?a=20130415-00000585-san-soci


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする