my_help 0.4.5 → 0.5.0

data/docs/nasu/latex_dir/new_code.tex

@@ -0,0 +1,237 @@
+
+\section{ビヘイビア駆動開発の実践}
+CucumberとRSpecを用いてBDDでmy\_helpのテスト開発を進めていきました．
+ビヘイビア駆動開発のコツとして「焦点を合わせる」ことが強調されています．
+ここでは，焦点を合わせたmy\_helpの中での一つの振る舞いである
+「todoの更新」を例として詳しく見ていきます．
+
+\subsection{todoの更新マニュアル}
+最初に，todoを更新するときの手順を示します．
+
+\begin{enumerate}
+\item my\_todo --editを入力して~/.my\_help/my\_todo.ymlを開く
+\item editorでtodoを書き込む（今週やることならweeklyというitemを作ってそこに書き込む）
+\item 保存して~/.my\_help/my\_todo.ymlを閉じる
+\end{enumerate}
+この振る舞いがきちんとできているのかをBDDでテストを書いていきます．
+
+\subsection{Cucumber}
+以下はtodoの更新を行うときのfeatureです．
+まず，適当なディレクトリにfeaturesというディレクトリを作成します．
+次に先ほど作成した，featuresディレクトリにmy\_todo.featureを作成します．
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+# language: ja 
+
+機能: todoの更新を行う
+自分のするべきことを書き込むためにtodoを更新する
+
+ シナリオ: コマンドを入力してtodoを更新していく
+          前提 todoを編集したい
+          もし "my_todo --edit"と入力する
+          ならば editが開かれる
+          かつ 自分のtodoを書き込む
+\end{lstlisting}
+機能とは，このシステムの機能のことを記述します．ここでは，todoを更新するシステムですので，「todoの更新を行う」です．
+機能の下には，機能の補足説明を記述します．機能の補足説明では，ルールがないので自分がわかりやすいように，記述するのが常識です．
+シナリオは，その名の通りtodoを更新する時のユーザの行動やシステム振る舞いを前提，もし，ならば，かつ，しかしに分類して記述します．
+
+ここまでfeatureが記述できたら，次はcucumberコマンドを実行してみます．
+コマンドは以下の通りです．
+\begin{quote}\begin{verbatim}
+nasu% cucumber features/my_todo.feature
+\end{verbatim}\end{quote}
+featuresディレクトリにあるmy\_todo.featureファイルをcucumberで実行するという意味です．
+
+実行すると図\ref{fig:003}のようになります．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=12cm,bb= 0 0 937 753]{../figs/./my_help_nasu.003.jpeg}
+\caption{step定義をする前のcucumberの実行結果．}
+\label{fig:003}
+\label{default}\end{center}\end{figure}
+ここでは，1つのscenarioと4つのstepが失敗しています．
+まだstep定義を記述していないので当たり前です．
+
+一度cucumberを実行したのには理由があります．
+featureを書いた時点でcucumberを実行すると，ステップ定義の元となるコマンドを，cucumberが自動的に作成してくれるからです．
+
+以下がcucumberから出力されたステップ定義の元となる部分です．
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+前提(/^todoを編集したい$/) do
+
+end
+
+もし(/^"([^"]*)"と入力する$/) do |command|
+
+end
+
+ならば(/^editが開かれる$/) do
+  
+end
+
+ならば(/^自分のtodoを書き込む$/) do
+
+end
+\end{lstlisting}
+これをコピーして，featuresディレクトリの中でstep\_definitionsディレクトリを作成し，その中にmy\_todo\_spec.rbを作成し，そこに貼付けます．
+
+ここでもう一度cucumberを実行してみると図\ref{fig:004}のように変化が出てきます．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=12cm,bb= 0 0 937 753]{../figs/./my_help_nasu.004.jpeg}
+\caption{defaultのstep定義を貼り付けた後のcucumberの実行結果．}
+\label{fig:004}
+\label{default}\end{center}\end{figure}
+これは1つのシナリオがあり，1つがpendingであり，4つのstepの内1つがpendingで3つがskipしたことを表しています．
+step\_definitionsのmy\_todo\_spec.rbのpending部分を書き換えて，step\_definitionsの記述を進めていきます.
+
+まず，「前提」を見てみるとmy\_helpが何か振る舞いをすることはありません．
+よって，このままにしておきます．
+「もし」もユーザが入力するコマンドであり，my\_helpが何か振る舞いをすることはないのでこのままにしておきます．
+次に，「ならば」を見てみるとmy\_helpがeditを開くという振る舞いをしています．
+ステップ定義では，あれば良いと思うコードを記述するので私は下記のように記述しました．
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+ならば(/^editが開かれる$/) do
+  Mytodo::Edit.new.open
+end
+\end{lstlisting}
+pendingの部分が書けたので，もう一度cucumber features/my\_todo.featureを実行します．
+すると，図\ref{fig:005}のような結果が返ってきました．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=12cm,bb= 0 0 937 753]{../figs/./my_help_nasu.005.jpeg}
+\caption{pendingのstep定義を書き込んだ後のcucumberの実行結果．}
+\label{fig:005}
+\label{default}\end{center}\end{figure}
+Cucumberは，エラーが出たステップのすぐ後ろにエラーを表示してくれます．
+ここでCucumberでエラーが出たので，この「ならば　editが開かれる」のシナリオに注目してRSpecに進むことにします．
+
+\subsection{RSpec}
+次にRSpecを使って実際にtodoを更新する振る舞いをするコード書いていきます．
+
+そのための準備として，まずspecというディレクトリを作成し，my\_todoというサブディレクトリを追加します．
+次に，このサブディレクトリにtodo\_spec.rbというファイルを追加します．
+この機能はmy\_help --editと入力されれば，~/.my\_help/my\_todo.ymlが開かれるので，その振る舞いをするコードを書きます．
+まずtodo\_spec.rbは下記の通りです．
+\begin{lstlisting}[style=customRuby,basicstyle={\scriptsize\ttfamily}]
+require 'spec_helper'
+
+
+module Mytodo
+  describe Todo do
+    describe "#open" do
+      it "open file my_todo.yml" 
+    end
+  end
+end
+
+\end{lstlisting}
+describe()メソッドは，RSpecのAPIにアクセスしてRSpec::Core::ExampleGroupのサブクラスを返します．
+ExampleGroupクラスはオブジェクトに期待される振る舞いのサンプルを示すグループです．
+it()メソッドはサンプルを作成します．
+
+完成したコードを下記の通りです．
+\begin{lstlisting}[style=customRuby,basicstyle={\scriptsize\ttfamily}]
+require 'spec_helper'
+
+
+module Mytodo
+  describe Todo do
+    describe "#open" do
+      it "open file my_todo.yml" do
+          system("emacs ~/.my_help/my_todo.yml")
+      end
+    end
+  end
+end
+
+\end{lstlisting}
+specディレクトリのmy\_todoディレクトリをrspecで実行すると図\ref{fig:006}結果がでました．
+\verb|--color|を付け加えるとわかりやすく色づけをしてくれて，見やすくなります．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=12cm,bb= 0 0 937 753]{../figs/./my_help_nasu.006.jpeg}
+\caption{pendingのstep定義を書き込んだ後のcucumberの実行結果．}
+\label{fig:006}
+\label{default}\end{center}\end{figure}
+図\ref{fig:006}を見るとエラーが出てしまっているのがわかります．
+\begin{quote}\begin{verbatim}
+`<module:Mytodo>': uninitialized constant Mytodo::Edit (NameError)
+\end{verbatim}\end{quote}
+上記のエラーを解決するために，specディレクトリの一つ上の構造のディレクトリにlibディレクトリを作成します．
+その中にmy\_todoというディレクトリを作成し，my\_todo.rbを作成します．
+
+構造を表示すると以下のようになります．
+\begin{quote}\begin{verbatim}
+/Users/nasubi/my_help/lib/my_todo% ls
+my_todo.rb
+\end{verbatim}\end{quote}
+my\_todo.rbに先ほどのエラーでMytodoというmoduleがないといわれているので，
+ここで作成します．
+
+/Users/nasubi/my\_help/lib/my\_todo/my\_todo.rbの中に以下のコードを記述します．
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+module Mytodo
+  class Edit
+    def open
+
+    end
+  end
+end
+\end{lstlisting}
+また，これをrequireしないといけないので，lib/todo.rbとして，以下を追加します．
+\begin{quote}\begin{verbatim}
+require 'my_todo/my_todo'
+\end{verbatim}\end{quote}
+これだけでは，rspecがlib/my\_todo/my\_todo.rbを読み込んでいないため，このスペックを実行するために，specディレクトリにspec\_helper.rbに以下を追加します．
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+$LOAD_PATH.unshift File.expand_path('../../lib', __FILE__)
+require 'todo'
+\end{lstlisting}
+これでもう一度rspecを実行してみると図\ref{fig:007}の結果が返ってきました．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=12cm,bb= 0 0 937 753]{../figs/./my_help_nasu.007.jpeg}
+\caption{redを修正してgreenになったrspecの実行結果}
+\label{fig:007}
+\label{default}\end{center}\end{figure}
+図\ref{fig:007}を見ると，エラーが消えて成功しているのがわかります．
+これで「ならば　editが開かれる」のシナリオのRSpec部分が成功しました．
+Red, Greenと進めたので次はRefactoringをするのですが，ここではあまり必要のないので省略します．
+RSpecが終わったので，Cucumberに戻ります．
+
+先ほどlibディレクトリでlib/my\_todo/my\_todo.rbを作成したので，cucumberでも読み込むために，以下を作成します．
+\begin{quote}\begin{verbatim}
+/Users/nasubi/my_help/features/support/env.rb
+\end{verbatim}\end{quote}
+env.rbの中は以下の通りです．
+\begin{lstlisting}[style=customRuby,basicstyle={\scriptsize\ttfamily}]
+$LOAD_PATH.unshift File.expand_path('../../../lib', __FILE__)
+require 'todo'
+\end{lstlisting}
+これでcucumberもlib/の中身を読み取ってくれます．
+
+もう一度cucumberを実行してみると,図\ref{fig:008}の結果が返ってきました．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=12cm,bb= 0 0 937 753]{../figs/./my_help_nasu.008.jpeg}
+\caption{libの中身を読み込むようにしたcucumberの実行結果．}
+\label{fig:008}
+\label{default}\end{center}\end{figure}
+エラーが消えています．
+
+これでBDDが成功しました．
+残りの「自分のtodoを書き込む」もmy\_helpが何か振る舞いをするわけではないので，「コマンドを入力してtodoを更新する」シナリオ全てのテスト開発が終わりました．
+このようにBDDでmy\_helpのテスト開発を行っていきました．
+
+\subsection{.rspec options}
+図\ref{fig:006}の時に述べたように,[rspec spec --color]で実行すると成功すればGreenで表示され，失敗すればRedで表示されます．
+結果に色がついていると見やすく，どのような結果が出ているかが一目瞭然です．
+しかし，毎回[--color]のコマンドを打ち込むのが面倒になってきます．
+そこで，カレントディレクトリに.rspecを用意し，
+\begin{quote}\begin{verbatim}
+--format documentation
+--color
+\end{verbatim}\end{quote}
+のようにすることで，rspecで実行するときにこのファイルを読み込み，[--color]を入力しなくても実行されます．
+

data/{my_help_nasu → docs/nasu}/latex_dir/overview.aux

@@ -1,6 +1,6 @@
 \relax 
 \@setckpt{overview}{
-\setcounter{page}{5}
+\setcounter{page}{4}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -16,6 +16,6 @@
 \setcounter{subparagraph}{0}
 \setcounter{figure}{0}
 \setcounter{table}{0}
-\setcounter{lstnumber}{1}
 \setcounter{lstlisting}{0}
+\setcounter{lstnumber}{1}
 }

data/docs/nasu/method.hiki

@@ -0,0 +1,5 @@
+ここでは、本研究で使用するcucumberの特徴について詳述する．
+cucumberはビヘイビア駆動開発(bdd)を実現するフレームワークである．
+まずはbddの現れた背景や現状を示した後、Cucumberの記述の具体例を示して，
+その特徴を詳述する．
+さらに，本研究の対象となるmy_helpの振る舞いを使用法とともに示す．

data/{my_help_nasu → docs/nasu}/method_bdd.hiki

@@ -1,24 +1,30 @@
 {{toc}}
+!先行研究，方法
+ここでは、本研究で使用するCucumberの特徴について詳述します．
+Cucumberはビヘイビア駆動開発(BDD)を実現するフレームワークです．
+まずはbddの現れた背景や現状を示した後、Cucumberの記述の具体例を示して，
+その特徴を詳述します．
+さらに，本研究の対象となるmy_helpの振る舞いを使用法とともに示します．
 
-!RSpecとBDDについて
+!!RSpecとBDDについて
 
 ビヘイビア駆動開発(Behaviour-Driven Development : BDD)は，テスト駆動開発(Test-Driven Development : TDD)の工程への理解を深め，それをうまく説明しようとして始まりました．TDDの持つ単語のイメージが構造のテストを中心とするべしというのに対して，BDDはソフトの振る舞いに中心をおきなさいという意図があります．この違いが，初めに考えるべきテストの性質を変化させ，構造ではなく振る舞いを中心にテストを構築するという意識をもたせてくれます．
 
 さらに，ソフトの中で，オブジェクト同士がコミュニケーションをとるように，実世界において開発チームやテストチーム，あるいはドキュメントチーム間のコミュニケーションの取り方をシステムで提供しようというのがBDDのフレームワークです．CucumberとRSpecはこれを実現する一つのシステムとして提供されています．
 
-RSpecとCucumberの関係を図に示しました．これは，RSpec本から書き写した図です[1, pp.9]．RSpecでテストを書くと一つ一つのfunctionあるいはmethodレベルでRed, Green, Refactoringを行うべしという意図があります．一方で，もっと大きな枠組み，つまりシステムレベルでもこれらのステップは必要です．ところが，それをRSpecで書くのには無理があります．このレベルのテスト記述をしやすくするのが，Cucumberです．そこでもRed, Green, Refactoringが必要で，そこでサイクルが回ることを意図しています．
+RSpecとCucumberの関係を図{{ref(fig:001)}}に示しました．これは，The RSpec Book[1]から書き写した図です[1, pp.9]．RSpecでテストを書くと一つ一つのfunctionあるいはmethodレベルでRed, Green, Refactoringを行うべしという意図があります．一方で，もっと大きな枠組み，つまりシステムレベルでもこれらのステップは必要です．ところが，それをRSpecで書くのには無理があります．このレベルのテスト記述をしやすくするのが，Cucumberです．そこでもRed, Green, Refactoringが必要で，そこでサイクルが回ることを意図しています．
 
-!!!caption:RSpecとCucumberのRed-Green-Refactoringサイクル間の関係．
-{{attach_view(my_help_nasu.001.jpg,my_help_nasu)}}
+!!!caption:(fig:001)RSpecとCucumberのRed-Green-Refactoringサイクル間の関係．
+{{attach_view(my_help_nasu.001.jpeg,my_help_nasu)}}
 
 BDDの基本的な考え方は次の通りまとめられています．
 ""BDDの目的は，ソフトウェアが使われる状況を説明するための言語を単純化することで，ソフトウェア開発チームのコミュニケーションを後押しすることです．つまり，あるコンテキストで(Given)，あるイベントが発生すると(When)，ある結果が期待されます(Then)．BDDにおけるGiven, When, Thenの３つの単語は，アプリケーションやオブジェクトを，それらの振る舞いに関係なく表現するために使われる単純な単語です．ビジネスアナリスト，テスト担当者，開発者は皆，それらをすぐに理解します．これらの単語はCucumberの言語に直接埋め込まれています[1, pp.3-6]．
 
-手順を書き直すと次の通りです．
+手順を書き直すと図{{ref(fig:002)}}の通りです．
 
-!!!caption:RSpecとCucumberの手順．
-{{attach_view(my_help_nasu1.001.jpg,my_help_nasu)}}
+!!!caption:(fig:002)RSpecとCucumberの手順．
+{{attach_view(my_help_nasu.002.jpeg,my_help_nasu)}}
 
-まずCucumberで一つのシナリオに焦点を当てて，その振る舞いを記述するfeatureを書きます．一つずつつぶしていくのがこつです．一つのfeatureが書けたら、次に，それぞれfeatureを実現するステップに分けて仕様を決めて行きます．これはTDDのred green refactoringの前に行う作業，「仕様をきめる」に対応しています．このプロセスが終了したら，RSpecに行きます．
+まずCucumberで一つのシナリオに焦点を当てて，その振る舞いを記述するfeatureを書きます．一つずつつぶしていくのがこつです．一つのfeatureが書けたら、次に，それぞれfeatureを実現するステップに分けて仕様を決めて行きます．これはTDDのred green refactoringの前に行う作業，「仕様を決める」に対応しています．このプロセスが終了したら，RSpecに行きます．
 RSpecでは実際にテストコードを書き，ここでもred, green, refactoringを行います．
 RSpecが成功したら，Cucumberのrefactoringを行います．

data/{my_help_nasu → docs/nasu}/method_cucumber.hiki

@@ -7,6 +7,7 @@ Cucumberが提供するBDDの内容をまとめると
 
 !!features
 Cucumberでは先の引用にある通り、振る舞いをシナリオとしてまず記述します．
+シナリオとは，一つひとつの振る舞いを，主にGiven(前提), Then(もし), When(ならば)に分けてfeaturesを記述します．
 次に，英語のfeaturesのひな形を示します．
 <<< ruby
 % cat ./featrues/sample_e.feature
@@ -25,19 +26,13 @@ Scenario: Description of scenario
 # language: ja
 
 機能: todoの更新を行う
-todoは更新していくものであり，新しく書いたり終わったものを消したいので
-バックアップをとって，過去のtodoを残しておく
+自分のするべきことを書き込むためにtodoを更新する
 
 シナリオ: コマンドを入力してtodoを更新していく
- 前提 todoを編集したい
- もし "my_todo --edit"と入力する
+ 前提   todoを編集したい
+ もし   "my_todo --edit"と入力する
  ならば editが開かれる
- かつ 自分のtodoを書き込む
-
-シナリオ: コマンドを入力してバックアップをとる
- 前提 todoの編集が終わった
- もし "my_todo --store [item]"と入力する
- ならば itemのバックアップを取る
+ かつ   自分のtodoを書き込む
 >>>
 このようにFeature, Scenario, Given, Then, Whenなどのcucumberが解釈する大文字で始まる
 keywordsに対して，それぞれ機能，シナリオ，前提，もし，ならばなどの単語があてられています．
@@ -46,8 +41,9 @@ keywordsに対して，それぞれ機能，シナリオ，前提，もし，な
 
 featureファイルで用意されているkeywordは
  cucumber --i18n LANG
-によって表示される．LANG=ja, enに対しては下記の通りになっています．
+によって表示される．LANG=ja, enに対しては表{{ref(table:one)}}の通りになっています．
 
+!!!caption: (table:one)featureファイルで用意されているkeywordの日本語(ja)，英語(en)の対応表．
 || keyword || ja(japanese) || en(english)
 ||^ feature||^ "フィーチャ", "機能"    ||"Feature", "Business Need", 
 ||"Ability"   ||
@@ -69,7 +65,7 @@ featureファイルで用意されているkeywordは
 || but (code)  || "しかし", "但し","ただし" ||  "But"        ||
 
 !!Cucumber,RSpecインストール
-まずrspecをgemでinstallする．
+まずrspecをgemでinstallします．
 #gem install rspec --version 2.0.0
 #rspec --help
 と入力して
@@ -77,7 +73,8 @@ featureファイルで用意されているkeywordは
 /Users/nasubi/nasu% rspec --help
 Usage: rspec [options] [files or directories]
 >>>
-のような表示がされていればinstallができている．次に，cucumberをinstallする
+のような表示がされていればinstallができています．
+次に，cucumberをinstallします．
 #gem install cucumber --version 0.9.2
 #cucumber --help
 と入力して
@@ -85,10 +82,10 @@ Usage: rspec [options] [files or directories]
 cucumber --help
 Usage: cucumber [options] [ [FILE|DIR|URL][:LINE[:LINE]*] ]+
 >>>
-のような表示がされていればinstallできている．
+のような表示がされていればinstallできています．
 
 !!ディレクトリー構造と使用手順
-cucumberはRubygemsの提供する基本directory構造での作業を前提としています．
+CucumberはRubygemsの提供する基本directory構造での作業を前提としています．
 その構造を表示すると次のようになります．
 <<<
 bob% tree .
@@ -117,7 +114,7 @@ bob% tree .
 
 カレントディレクトリ(.)の中にfeaturesというサブディレクトリを作成します．
 そのfeaturesの中に書きたいシナリオを書いた，hogehoge.featureを作成します．
-featureの具体例は上記に示してします．
+featureの具体例は上記に示しています．
 
 次にシェルを開いて，カレントディレクトリで，
  cucumber features hogehoge.feature
@@ -159,7 +156,7 @@ Cucumberはシナリオの最初のステップを読み取り,そのステッ
 
 これはfeaturesディレクトリの下にstep_definitionsディレクトリーにあることになっています．
 このシナリオを成功させるには，Cucumberが読み込めるファイルにステップ定義を保存する必要があります[1, pp15.]．
-その内容は次の通りcucumberから自動生成されます．
+その内容は次の通りCucumberから自動生成されます．
 
 <<< ruby
 

data/{my_help_nasu → docs/nasu}/method_usage.hiki

@@ -1,39 +1,44 @@
 {{toc}}
 !my_helpについて
-!!使用法
 my_helpは本研究室の西谷が開発したものです．
+my_helpとはユーザメモソフトであり，CUIスキルの習得を助けてくれます．
+tarminal上で簡単に提示させることができるため，プログラミングに集中することができるといった特徴があります．
+また，自分の見やすいように初心者でも簡単に編集することができ，すぐに参照できるメモとしても使うことができます．
 
-以下はmy_helpのREADMEです[2]．
+!!my_helpの開発動機と特徴
+以下はmy_helpのREADMEからの抜粋です[2]．
 
-CUI(CLI)ヘルプのUsage出力を真似て，user独自のhelpを作成・提供するgem.
+!!! 概要
+my_help - CUI(CLI)ヘルプのUsage出力を真似て，user独自のhelpを作成・提供するgem.
 
-# 問題点
+!!! 開発動機
 CUIやshell, 何かのプログラミング言語などを習得しようとする初心者は，
 commandや文法を覚えるのに苦労します．少しのkey(とっかかり)があると
 思い出すんですが，うろ覚えでは間違えて路頭に迷います．問題点は，
-- manは基本的に英語
-- manualでは重たい
-- いつもおなじことをwebで検索して
-- 同じとこ見ている
-- memoしても，どこへ置いたか忘れる
+* manは基本的に英語
+* manualでは重たい
+* いつもおなじことをwebで検索して
+* 同じとこ見ている
+* memoしても，どこへ置いたか忘れる
 
 などです．
 
-# 特徴
+!!! 特徴
 これらをgem環境として提供しようというのが，このgemの目的です．
 仕様としては，
-- userが自分にあったmanを作成
-- 雛形を提供
-  - おなじformat, looks, 操作, 階層構造
-- すぐに手が届く
-- それらを追加・修正・削除できる
+* userが自分にあったmanを作成
+* 雛形を提供
+** おなじformat, looks, 操作, 階層構造
+* すぐに手が届く
+* それらを追加・修正・削除できる
 
 hikiでやろうとしていることの半分くらいはこのあたりのことなの
 かもしれません．memoソフトでは，検索が必要となりますが，my_helpは
 key(記憶のとっかかり)を提供することが目的です．
 
+
 !!my_helpのインストール
-!!githubに行ってdaddygongonのmy_helpをforkする
+githubに行ってdaddygongonのmy_helpをforkします．
 #git clone git@github.com:daddygongon/my_help.git
 #cd my_help
 #rake to_yml
@@ -44,8 +49,8 @@ key(記憶のとっかかり)を提供することが目的です．
 #rake add_yml
 
 !!my_helpの更新
+git hubを用いてmy_helpを新しくします．
 
-!!!gitを用いてmy_helpを新しくする．
 #git remote -vをする(remoteの確認).
 #(upstreamがなければ)git remote add upstream git@github.com:gitname/my_help.git
 #git add -A
@@ -53,17 +58,13 @@ key(記憶のとっかかり)を提供することが目的です．
 #git push upstream master(ここで自分のmy_helpをupstreamに送っとく)
 #git pull origin master(新しいmy_helpを取ってくる)
 
-!!!次にとってきた.ymlを~/.my_helpにcpする．
+次にとってきた.ymlを~/.my_helpにcpする．
 #cd my_helpでmy_helpに移動．
 #cp hogehoge.yml ~/.my_help
 
 それを動かすために
 (sudo)bundle exec ruby exe/my_help -mをする.
-
-ここで過去にsudoをした人はpermissionがrootになっているので，sudoをつけないとerrorが出る．
-
+ここで過去にsudoをした人はpermissionがrootになっているので，sudoをつけないとerrorが出ます．
 (sudoで実行していたら権限がrootに移行される)
-
-新しいターミナルを開いて動くかチェックする．
-
+#新しいターミナルを開いて動くかチェックする．
 

data/docs/nasu/my_help_nasu/my_help_nasu.001.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.001.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.002.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.002.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.003.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.003.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.004.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.004.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.005.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.005.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.006.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.006.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.007.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.007.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu/my_help_nasu.008.bb

@@ -0,0 +1,5 @@
+%%Title: ./my_help_nasu.008.jpeg
+%%Creator: extractbb 20110311
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Mon Feb 13 11:26:11 2017
+

data/docs/nasu/my_help_nasu.hiki

@@ -0,0 +1,28 @@
+{{toc}}
+
+!title:ユーザメモソフトmy_helpのビヘイビアテスト開発
+!author:2535 那須比呂貴
+
+
+![[概要|my_help_nasu_overview]]
+
+![[序論|my_help_nasu_introduction]]
+
+![[先行研究，方法|my_help_nasu_method_bdd]]
+!![[my_help_nasu_method_cucumber]]
+!![[my_help_nasu_method_usage]]
+
+![[本論|my_help_nasu_new_code]]
+!![[my_help_nasu_features]]
+![[結論,考察|my_help_nasu_discussion]]
+
+
+!謝辞
+本研究を進めるにあたり，様々なご指導を頂きました西谷滋人教授先生に深く感謝いたします．
+また，本研究の進行に伴い，様々な助力，知識の供給を頂きました西谷研究室の同輩，先輩方に心から感謝の意を示します．
+本当にありがとうございました．
+
+!reference:
+:RSpecBook: "The RSpec Book", David Chelimsky, Dave Astels, Zach Dennis, 訳, 株式会社クイーブ, 監修, 角谷信太郎, 豊田裕司 (翔泳社, 2012).
+:README: my_help README, Shigeto R. Nishitani, [[http://www.rubydoc.info/gems/my_help/0.4.3]] 2017/2/11アクセス.
+:Qiita: rake specにrspecのオプションを渡す, Qiita, [[http://qiita.com/snaka/items/e0808f9cfbad87c49b4e]] 2017/2/13アクセス.

data/docs/nasu/nasu_abst/abst_fig.bb

@@ -0,0 +1,5 @@
+%%Title: abst_fig.png
+%%Creator: extractbb 20160307
+%%BoundingBox: 0 0 394 443
+%%CreationDate: Thu Feb 16 11:10:26 2017
+

data/docs/nasu/nasu_abst/my_help_nasu.001.bb

@@ -0,0 +1,5 @@
+%%Title: my_help_nasu.001.jpg
+%%Creator: extractbb 20160307
+%%BoundingBox: 0 0 737 553
+%%CreationDate: Thu Feb 16 11:08:20 2017
+

data/docs/nasu/nasu_abst/nasu_abst.aux

@@ -0,0 +1,10 @@
+\relax 
+\citation{RSpecBook}
+\bibcite{RSpecBook}{1}
+\@writefile{toc}{\contentsline {section}{\numberline {1}目的}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}方法}{1}}
+\@writefile{toc}{\contentsline {paragraph}{BDD}{1}}
+\@writefile{toc}{\contentsline {paragraph}{CucumberとRSpec}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}ビヘイビアテスト駆動開発の実践}{1}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces RSpecとCucumberのRed-Green-Refactoringサイクル間の関係．}}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}まとめ}{1}}