博士号取得者の就職状況

博士号取得者の就職状況
http://www.slideshare.net/subhjap/ss-3247345

によると（以下太字は上記スライドより引用）

博士課程修了者の６２．９％（１万人）が就職者している


逆に言うと、３７．１％が無職・・・ヒッキー？

あ、ただこの数字・・・

産業別では「教育，学習支援業」が３３．７％，「医療，福祉業」２３．７％，「製造業」１６．３％等の順

（中略）

※専門的・技術的職業従事者とは「教員」２４．９％，「医師，歯科医師，獣医師，薬剤師」２２．０％，「科学研究者」２３．９％，「技術者」１７．５％等

ってことで、医学博士も入っているので（彼等は就職するだろうから）
高めに出ているかもしれない・・・

ちなみに

修士課程修了者の就職者は７４．８％（５万５千人）。就職率は７５．１％

アジャイルが必要な理由

シリーズ化してしまいつつある

情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。


今日は、アカデミックで信じられているモデルと、
最近のソフト開発のモデルから、アジャイルの必要性までを書いてみる

昨日書いたとおり、

~ トヨタ カンバン方式に学ぶ ~
ITシステム開発・管理への適用と実践技法
2. リーン・ソフトウェア開発　
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf

を参考にします
（以下、このＰＤＦを、「参考資料」として
「参考資料のＸシート目」という書き方をします。シートの下の番号をさします）

---

■大学では、下流工程でバグが発見されるほど、
　修正工数が大きいというモデルを使っている。

　これは、スパイラルモデルのバリー・ベーム（Barry Boehm）が提唱したモデル。

　参考資料の４４シート目に、

「ソフトウェアが出荷されてしまってから問題を
　見つけて直すと, 初期設計で行うのに較べて
　100倍のコストがかかる (B. Boehm, 1987)」

　と書かれていますけど、まさに、このモデルを基にしています。

　ということは、初期工程で要求を出し切らなければなりません。
　また、スパイラルモデルを採用して、できるだけ合意をとって、
　安全に開発を進めていくという考え方になります。

　つまり、できるだけ、手戻りをさけるわけです。
　ウォーターフォールがこの典型例です。

---

■大学のモデルの前提

このモデルには、実は前提があります。

　・下流工程の問題は、上流で（適切なコストを支払えば）見つけられる
　・開発中に環境が変わらない
　　　もし、環境が大幅に変わってしまったら、要求段階で決めたことが
　　　実現できなくなるかもしれないので
　・開発時に結果が見通せる
　　　要求時点で、どうなるか判らないものを、要求固めろといわれても・・

　ＣＯＢＯＬのような開発では、できることが決まっていたし、閉じた世界なので、
　開発環境が大幅に変わることはありませんでした。

　なので、このモデルを採用しても、問題なかったのでした。
　このような状態であれば、開発目標を決めて、そこへ向かっていくという
　参考資料　４０シート目の「点ベース開発」も可能です。

---

■今、現実は・・・

・下流工程の問題は、上流で（適切なコストを支払えば）見つけられる
　　→いや、インターネットの混み具合とか、はっきりしないし・・
　　　ハード的なものは、よくわからない
　　なので、インターネットがらみのモノは、作ってみないとわからない
　　ところが正直ある。

・開発中に環境が変わらない
　　いや、ＷｅｂＡＰＩとかは、先方の都合でよく変わる
　　オープンソースを使うと、バージョンによって、結構変わるよね

・開発時に結果が見通せる
　　ってことで、上２つの理由により、結果が見通せない。

このような場合、作ってみないとわからないのだから、要求仕様ですべてを
考えるのは無理で、リリース直前に決めたほうがいいことになる。
そして、リリース後も、環境の変化に追随しないといけない。

ってことで、目標を決めることができず、目標は変化させないといけない。
変化に対応できるように、生物界の多様性のように、多様なものをとりあえず
作っておき、そのときにあったものを使うということになる。

これが、参考資料の４１シート目セットベース開発

---

■実は、Boehmは、このあと、意見が変わっている

　バリー・ベームとリチャード・ターナは、このあと、「リスク分析手法」を提案し、
アジャイルでいくか、ウォーターフォールでいくかの判断について書いている
（たしか、Balancing Agility and Disciplineだったかな
日本語訳はたしか、「アジャイルと規律」だとおもう）

　で、アメリカでは、教科書が変わっている。
　Roger S. PressmanのSoftware Engineering: A Practitioner's Approachでは、
（昔からの）ソフトウェアは死んだとして、アジャイル話がかなり書いてあるんだけど、
日本の大学が参考書として使っているのは、この本の古いバージョンの翻訳版で、
西先生とかが訳している

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識

だとおもった。こっちには、そんなことが出ていない。

---

つまり、ソフトウェアを取り巻く環境が古くて、それって、アメリカでは
修正がかかってるんだけど、大学の先生は、今も使い続けちゃってるんですねえ・・・

そうすると、「要求はしっかり決めましょう」とか「ＭＤＡ」みたいなことが
できると思ってしまうわけです。

・・・かなり、差があるでしょ？

ただ、参考資料の４４シートの話は、こういう風な流れにはなっていない。
つまり、もう一つのお話がのこっているんだけど、それについては、またこんど。

大学でアジャイルを教えているか？というと・・・

なんかシリーズ化してきてしまった

情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。


今日は、大学でのアジャイルの話。

---

■一般には、アジャイルは・・・

　アジャイルなら、どんなものでもＯＫってすると、
　結構アジャイルという手法は、浸透してきているのではないだろうか？

　・・まあ、SCRUMとXP、リーンにおいての話なんだけど・・

　経験している人もかなりいる。
　アジャイルサムライは、かなり読まれている本だったりする。

　一方、どうだろう、最近は、構造化設計って、あんまり聞かないんじゃないかなあ・・
　あんまり、ＤＦＤを使って開発とは、自治体ＥＡでもやっている人でないと、言わないかも
　ＤＦＤは情報処理試験のときに覚えるってかんじかしら・・・

　構造化設計よりも、むしろ、アジャイルを聞く？
　もちろん、オブジェクト指向は健在で、Astah*つかって、がんばるわけだ・・

---

■大学で、今、何を教わるのか

　大学では、「開発」について、何を学ぶのか？
　ちょっとシラバスで「ソフトウェア工学」とか「ソフトウェア設計論」の授業を見てみると、

　どうも、オブジェクト指向、ＵＭＬまでは、教わるらしい。
　シラバスに、よく出てくる。

　Astahを使っていると、シラバスに明示してある大学としては、
　　　琉球大学（モデリングと設計）
　　　芝浦工業大学（ソフトウェア設計論）
　　　早稲田大学理工（ソフトウェア工学：S評価者用の深澤先生＆本位田先生＆鷲崎先生の）
　　　金沢工業大学情報工学科（ソフトウェア工学１）
　なんかがある。ただ、シラバスに明示してないだけで、ほかでも使っている学校は、
　もっとありそうな気はするよね・・

　で、構造化手法、ＤＦＤなんかも、結構、シラバスに出てくる

---

■アジャイルは？

　これに比べると、「アジャイル」という言葉は、シラバスにあまり出てこない。
　いや、出てこないわけじゃないけど、世間で言われるほどではないのだ。
　たとえば、京都産業大学のコンピュータ理工学部のソフトウェア工学１では、授業の１講義分
　がアジャイルにあてられていて、SCRUM,XP,TDDが説明される。

　でも、京産大ですら、この程度なのよ！
（＊注：京産大は、最近、他学部でも、相当、産業界を意識したカリキュラムを組んでいる）
　その他、産業界を意識している、千葉工大（ソフトウェア工学）や、ＳＦＣなどでも出てくる。
　あ、千葉商大（ソフトウェア工学）がすごいかな。。。XPとか、かなり力入れてるみたい。

　でも、構造化手法に比べると、アジャイルは、出てくる数も時間数も少なかったりするわけですよ・・

---

■ちなみに・・・

　ユーザー中心も最近話題ですよね。
　でも、大学では、ユーザー中心はシラバスに出てこない。

　むしろ、形式手法のほうが、よく出てくるかな
（っても、オブジェクト指向や構造化手法ほどじゃない）

---

■どうして・・・

　じゃ、どうして、そういうことが起こるのかっていうと、
　これが、たぶん、大学と産業界の根本的な違いになってくると思う。

　もう、今日は長く書いたので、今度、別なときに書くけど、
　ちょっと前ふりすると、メタボリックスの山田氏の

~ トヨタ カンバン方式に学ぶ ~
ITシステム開発・管理への適用と実践技法
2. リーン・ソフトウェア開発　
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf

プレゼンシートのシート４０「点ベース開発」を教えるのが大学
産業界は今、４１ページの「セットベース開発」になりつつあり、
なぜ、大学が点ベースを教えるかというと、４４ページの理由から。

そんな話を、今度書きます。

シャープ、「住宅用 定置型リチウムイオン蓄電池システム」を発売

もっと前だったら、計画停電の話とかで、検討する人も多かったのでしょうね。

夜間電力を蓄電できるとかは、学校の需要とか、見込めるんじゃないだろうか？
夏の冷房とか・・

どっちかっていうと、家庭用より、学校・企業のほうが、こういう需要は、多いんじゃないかなあ・・

なことない？？


シャープ、「住宅用 定置型リチウムイオン蓄電池システム」を発売、満充放電8,000回でも容量70％以上を維持
http://news.goo.ne.jp/article/internetcom/trend/internetcom-20130116012.html

サムスンがＤｏｃｏｍｏと組んでやるTizenについて－ （４）編集

シリーズ（なのか？）

サムスンがＤｏｃｏｍｏと組んでやるTizenについて
http://blog.goo.ne.jp/xmldtp/e/6c8030e63cc789e43d19683e034c3536


前回はプロジェクトを作って、ここ

まできたので、今回は、編集を行います。

---

■ドラッグ＆ドロップで編集

といっても、ただ、ドラッグ＆ドロップするだけです。

たとえば、ＨＴＭＬ４にある部品、ボタンを画面に貼り付けるとすると、

1.まず、真ん中あたりに「ＨＴＭＬ4.0」と書いてあるところをクリック
2.ボタンをクリックして、
3.適当なところにドロップすると、

なかんじになる。右側のHTMLのソースが書いてあるところで
submitがハイライトになっているけど、このようにＧＵＩで
追加すると、自動的にソースがかかれる。

---

■ソースを編集すると、反映される

で、ソース側をなおしてみると、それが反映される。
例えば今作ったボタン、ハイライト部分を削除すると、こんなかんじ

ってことで、ＧＵＩでやっても、ソースを直してもよい。

---

■テキストを直して、ブラウザで見る

左側の画面レイアウト、文字のところは

のように直接修正できる。

なので、

なかんじに直して、ブラウザで見ると・・・


なかんじになる。

---

シナリオから、ＴＤＤができるはず

昨日の

情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。


の第二段。今日は、ＴＤＤ

---

ＴＤＤができる根拠は、シナリオにある。
外部設計終了段階、つまりＧＵＩが決まった時点で、
「この画面に、こういう値を入れたら、こうなるよね」
　　というのは、ユーザーで合意を取る。

また、外部インターフェース、とくにＷｅｂＡＰＩにおいて、
確認の意味をこめて、

こういうのを入れたら、
こういう結果が帰ってくるはず。

というサンプルを出す
（例：ＹＡＨＯＯ　ＡＰＩ 一番シンプルな地図の表示）


実装側は、このサンプルが動くように実装する。
つまり、サンプルを出した時点で、入出力の例が決まるので、
この例が実現できるように、プログラムを組んでいく。
まさにＴＤＤができるというわけだ。
実務的には、こんなかんじで、サンプルの実現というような形で
プログラムしていくんじゃないかなあ・・ちがう？？
（私はそうだけど・・）

---

だが、この話を受け入れるには、
「外部設計が完了するまで、シナリオないしはユースケース記述を行っている」
ということになってしまい、いや、実際そうなんだけど、
アカデミックな世界では、そう見ていない気がする・・・

つまり、機能要件、非機能要件は要求仕様で確定し、

外部設計の段階では要求を出すのではなく、
　　ユーザーインターフェースの決まりに従って、
　　機能要件・非機能要件に添った形で設計していく

というふうに見ているような感じがする。

前回出した「機能要件の合意形成ガイド」では、機能要件は外部設計において、
最終合意されるという立場だけど（だから外部設計のガイドになっている）
大学では、機能要件は、要求仕様で確定し、ＭＤＡによって、実装可能
にすらなると考えているようだ。

---

当然、この結果、大学の側からすると、シナリオ作成は、要求仕様の分野の
技術となる。でも、この要求分析のレベルのシナリオでは、ＴＤＤには使えない。
画面にどう入力するかまでわからないと、具体的なテストの値としては使えないのだ。

シナリオ自体には、画面の値を記述するまでの記述力がある
（自然言語で書くからね）
なので、実務的には、シナリオに近いものを書いて、ＴＤＤの元とし、
要求→外部設計→ＴＤＤの話は繋がる。

でも、大学の教える内容では、
要求　｜　外部設計　｜　ＴＤＤ
と、この間の話が繋がらなくなる。むしろ、外部設計はＭＤＡが完成すれば
いらないんじゃないかと思っている節もある。
このへんが、ちょっと、大きな差なんですよね！

gooメールにログインできない事象について→ログインできた（１：３０追加）

こ・ま・っ・て・る・ん・で・す・け・ど・～

あ～返信できない・・・
申し込みできない・・・（＞＿＜！）
(申し込み先のＵＲＬが、受信メールの中にある）

クラウドは、これだから・・・（－＿－；）


gooメールにログインできない事象について
http://blog.goo.ne.jp/goomailstaff/e/64380570e8eda44d6c8c2babd7db2619

---

１：３０ごろ追加

ログインできた！
えらい！！Ｇｏｏ

Office 2013の国内発売日が2月7日に決定

パーソナル版は3万1290円


ただ～し！！


対応OSはWindows 7以上で、XPとVistaには未対応


そうですか、そうですか・・・

ちなみに、パーソナル以外の価格はこんなかんじ

Office Personal 2013（3万1290円）
Office Home and Business 2013（3万6540円）
Office Professional 2013（6万2790円）
Office Professional Academic 2013（2万9800円）


Office 2013の国内発売日が2月7日に決定--パーソナル版は3万1290円
http://headlines.yahoo.co.jp/hl?a=20130115-35026884-cnetj-sci

（このエントリ内の太字は、上記記事の内容及び見出しからの引用）

Fusion-IOとかNetezzaとか

雑感

最近、ビッグデータのせいか、大量データの高速処理が話題だ。

メモリとかキャッシュとかによる、高速化を手掛けるFusion-IOとか
DWHアプライアンスのNetezzaとか

この２つに共通するのは、適正なお金を払わないと得られないということだ。
オープンソースを使ったり、安いパソコンでごにょごにょって話じゃない。


ある程度の技術力を持たないと、オープンソースは高くつく。
リリースまでの期間における逸失利益まで含めると、
いっぺんに製品を入れてしまった場合のほうが、お得なこともおおい。
そうしないのは、資本力のため。
お金をかけたほうがよいとしても、先立つものがない企業にとっては、
とりあえず、ごにょごにゅするしかない。

---

しかし、ビッグデータをやろうという会社は基本的に大会社だ。

約6割の企業がビッグデータの活用を組織的な検討課題と認識、NRI
http://marketing.itmedia.co.jp/mm/articles/1212/25/news056.html


の記事の下の棒グラフ、右側が売上規模だが、１兆円以上の企業は８４％も、ビッグデータを検討しているが、５００億円（っていっても、かなりでかいが）の企業は半分近くの４７％しか、検討していない
つまり、ビッグデータに興味があるのは、売上規模がでかい、億単位の投資のできる企業だ。
となってくると、高速化も、ハード的にしっかりしたものを選ぶことになるだろう。

---

ビッグデータが話題だが、主に解析のほうに興味が行き過ぎているかも知れない。
購入する層が、カネを持っているのであれば、
むしろ、ハードに力をいれたほうが、ビジネス的においしいかもしれない

アスペクト指向の横断的関心事→共通ルール→cakePHPのbeforeFilterとかで実現？

情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。

そんな分野の１つ「アスペクト指向」を、今日はご紹介。

---

■学界的に、アスペクト指向は・・・

学界的には「アスペクト指向」というのがある。
オブジェクト指向では、いろいろなオブジェクトに共通して起きる
「横断的関心事」というのがある。
これに対処するため手法で、具体的には、
横断的に、プログラムを切って、
そこに「横断的関心事」のプログラムを差し込む。

たとえば、みんなでログを出したいとしたら、
各メソッドの呼び出し時に＝プログラムを切って
そこにログの＝「横断的関心事」の
プログラムを差し込む。

このとき、プログラムをきるところを「ジョインポイント」
といい、このジョインポイントをまとめたものを「ポイントカット 」
「横断的関心事」のプログラムを「アドバイス」という。

実行時には、もともとのプログラムに対して、ポイントカット部分に
来たら、アドバイスを実行することになるが、このように、
アドバイスのプログラムを差し込んでいくことを「ウィーブする」という

・・・めんどっちいなあ、ことばが・・・

ここが詳しい。

http://www.atmarkit.co.jp/farc/rensai/aspect02/aspect02b.html

---

■「横断的関心事」＝「共通ルール」（機能要件の合意形成ガイド等）

で、この「横断的関心事」だけど、アスペクト指向の説明では
ログが好まれる。このほか、セキュリティ要件なども
「横断的関心事」とされている。

でもこれ、もっと簡単に言って、どんな機能でも守る「共通ルール」
のことだ。

たとえば、

どんな画面でも、全画面でエラーがあったら、エラーをここに表示！
日本語と英語の切り替えはいつでもできるようにするのよ！

とかの共通ルール。これは、アスペクト指向における
「横断的関心事」として処理できる。
Viewの表示直前を、ポイントカットして、
エラーがあったら表示、ロゴを表示、日本語英語チェックなどを
アドバイスすればよい。

共通ルールって言った途端に、実務よりの話になってくる。
画面の「レイアウト共通ルール」などは、
「機能要件の合意形成ガイド」とかにも出てくる
ただし、レイアウトの場合、共通ルールのすべてを横断的関心事に
するかというと・・・

でもまあ、共通ルールになっていることの多くは、「横断的関心事」だ

---

■ポイントカットと、CakePHPにおけるbeforeFilterなど

では、実装についてみてみよう。
アスペクト指向の場合、ウィーブするには、ＡＯＰ対応の開発環境で
実現できる。Javaにおいては、eclipseは対応している。

では、実務上、共通ルールを、どうやって実装するか。
CakePHPの場合、画面自体は、
　　共通なレイアウトは、　
　　　　　default.thtml、cake.generic.cssというテンプレートやＣＳＳ
　　　　　エレメント
　　コントローラーに来るときの共通処理として
　　　　　beforeFileter
　などによる実現が考えられると思う。

beforeFilter,afterFilterは、すべてのコントローラーをとおる。
したがって、この中で、対象となるものを選択して、実行すれば、
アスペクト指向と同じようなことができる。

　ただし、Filterの種類は限定されている
（アスペクト指向のポイントカットタイプ程はない）

---

■JQueryの場合

JQueryのイベントは、

　　$(セレクター).イベント(function

となる

http://ascii.jp/elem/000/000/450/450276/


$(セレクター).イベント　をジョインポイント、
（function　をアドバイスと考えれば、

対応は付く。また、ジョインポイントは、
ポイントカットタイプとその引数（対象を表す）にわかれるが、

セレクターを引数部分、
ポイントカットタイプをイベントと考えれば、
用意されているポイントカットタイプとイベントは違うけど、
似たように考えられる。

---

この関連付けに文句のある人はたくさんいるだろう。
それはそれでよい。

ただし、
実務上では、共通ルールとして、ユニバーサルデザインが議論されたりする。
今回の説明で考えると、そのようなユニバーサルデザインがアスペクト指向
で取り組めることになる。

そのように、実務での話題を、学会で取り込めるようにするためには、
こういう関連付けは有意義かと思うし、それを辞めさせる必要性もないと思う。

Facebookに張り巡らされ始めた罠

ここの記事

気軽な「いいね」で恥をかく。Facebookに張り巡らされ始めた罠について
http://www.landerblue.co.jp/blog/?p=5141


どうも、「いいね」をクリックしてしまうと、
自分には見えないけど、いろいろと問題になることが
起こることがあるらしい・・・ってことなのかしら？？

・・・実は良くわかっていないけど、
なんか、大事そうなので、ＵＲＬをメモしておいた・・・

アジャイルにとって、情報システムを内省化できる環境が整ったってことも大きいと思う

結局、米企業では、「情報システムは内製する方が良い」　という判断が多いようですね…　モジュール化した製造業とは異なり、垂直統合的な傾向が表れている（？）　と仮にみなせるのならば　さらに興味深い　◆　アジャイルの取り組みが大きく遅れている itpro.nikkeibp.co.jp/article/COLUMN


というツイートについて

アメリカは、
「情報システムは内製する方が良い」
　　　↓
　内省化率が高い
　　　↓
契約とか考えないでいいし、
情報システムは、プロジェクトごとというよりは改善なので、
アジャイルのほうが向いている
　　　↓
アメリカはアジャイルが広まった

という議論に関しては、激しく同意するし
たぶん送なんだと思う。

ただし、１点、付け加えさせてほしい。
ユーザー企業が、内製可能なほど、技術的な環境が整ったことも大きいと思う。

つまり、今の開発は

・画面作製はＨＴＭＬ（ＨＴＭＬ５）
・ＤＢは、ＭｙＳＱＬなど→phpmyadmin等で、管理が簡単
・あとはCakePHPのBakeなどで、ある程度自動化してくれる

その結果、ＰＨＰと、JQuery,JQueryMobileを組み合わせれば、
プログラムは、そこそこできるようになった。
これは、情報システム部の人に勉強してもらえば対応可能

というように、ツール・技術がそろってきたので、アジャイルが
可能になって来たといえる。
オブジェクト指向へのこだわりがなければ、
（継承して抽象化させるこだわりがなければ）
これらのツールで、　ボトムアップで開発したほうが、
現場の要望がタイムリーに取り込みやすいので、
アジャイルが広まる要因になったといえる

無料の文字認識ＡＰＩをDocomoが出しているらしい－なんと風景写真にも対応

文字認識というとＯＣＲだけど、
ああやって、はっきり書いていない、風景写真の中にある
文字を認識するようなＡＰＩをDocomoさんが、無料で出しているらしい


文字認識ＡＰＩ
http://recognize.jp/


これに関する論文は、ここ

ＮＴＴ技術ジャーナル
高精度な認識を実現する文字認識技術の開発
http://www.ntt.co.jp/journal/1301/files/jn201301036.pdf

プライベートDropBox？文書を構成管理したい！ その１ 概要

プログラムではなく、ドキュメントを、文書管理したいことはないだろうか？
とくに、Dropboxみたいに、アクセスできれば、みんなそこにアップしたい！
ってなことはないだろうか？

ただ、Dropboxの場合は、パブリッククラウドなわけで・・・
いや～それを、プライベートクラウドでやりたいんだよ！
ってことは、ないですかねえ・・・企業の場合

私はある（企業じゃないけど）。
論文を管理したい。

こんなとき、プログラム同様、Subversion(SVN)が使えそうで、
最近だと、全部ＧＵＩベースでできそうなので、
使ってみて、その使用感をレポートしてみたいと思う。
（ただ、クラウドではなく、一台のマシン上で行うが、
　原理はクラウドでもできると思う）

まず、今日は概要。
こんな風にするとできるという話。

---

■概要

●こんなシステムを作る

サーバー：Visual SVNを使用
　　→本来はクラウド上に展開するが、ここでは、ローカルＰＣで行う

クライアント：TortoiseSVNを使用
　　→各自のマシン上に展開することになる。
　　→成果物をサーバー上にコミットしたり、チェックアウトする


●やること

　はじめの１回目と、普段することに分かれる

---

■はじめの１回目にやること

Visual SVNとTortoiseSVNをインストールし、初期化する

以下の手順になる

１．Visual SVNをインストール

２．ユーザーを作成

３．リポジトリを作成

４．TortoiseSVNをインストール

５．はじめてのチェックアウト

---

■普段すること

・コミットなど

---

次回は「はじめの１回目にやること」

今後参考にするサイト
http://gside.org/Gentoo/subversion/subversion_client2.html

サムスンがＤｏｃｏｍｏと組んでやるTizenについて－ （３）プロジェクト作成

シリーズ（なのか？）

サムスンがＤｏｃｏｍｏと組んでやるTizenについて
http://blog.goo.ne.jp/xmldtp/e/b7793baacdfa6fed8d2e70866565308e

前回は、インストールして、立ち上げるところまできたので、
今回は、プロジェクトをつくります。

---

■そのまえにちょっと・・・

Apacheがインストールされている場合、
前回書いたように、Tizenを立ち上げると、

のように、eclipseのワークスペースを聞いてきます。
このときに、apacheのhtdocsを指定しておくと、
ブラウザですぐに見れたりと、なにかと便利かもしれない・・・

それと、前回書かなかったけど、立ち上がったとき、
こんな画面

が出たら
「workbench」をクリックしてください。

---

■プロジェクトの作成

Tizenの（実質eclipse）のFileメニューのNewをクリック

のように、Tizen Web Projectが見える場合は、それを選択。

のように、Tizen Web Projectがなかったら、Other...を選択

でTizen→Tizen Web Projectを選択。
いずれにせよ、こんな画面になる。

真ん中の大きい段の一番左、「Tizen Basic」を指定（クリック）すると、
右側にいろいろ出てくる。
ProjectNameを入れて（今回はTizen2)、「Finish」ボタンをクリック

なのが、もし出て来たら、Yes　（こないこともある）

プロジェクトができる。左側のProjectExplorerで、プロジェクト名
（ここではTizen2)の＋ボタンをクリックすると、
構成物が出てくる。その中で、index.htmlをクリックすると、
こんなかんじ

---

■ブラウザで見る

さっき書いたように、
eclipseのワークスペースをapacheのhtdocsに指定しておくと
ブラウザからも、こんなかんじ

でみえる。

---

つぎは、編集？