my_help 0.4.3 → 0.4.4

data/my_help_nasu/latex_dir/method_bdd.aux

@@ -0,0 +1,26 @@
+\relax 
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}RSpecとBDDについて}{7}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces RSpecとCucumberのRed-Green-Refactoringサイクル間の関係．}}{8}}
+\newlabel{default}{{1}{8}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces RSpecとCucumberの手順．}}{8}}
+\newlabel{default}{{2}{8}}
+\@setckpt{method_bdd}{
+\setcounter{page}{10}
+\setcounter{equation}{0}
+\setcounter{enumi}{0}
+\setcounter{enumii}{0}
+\setcounter{enumiii}{0}
+\setcounter{enumiv}{0}
+\setcounter{footnote}{0}
+\setcounter{mpfootnote}{0}
+\setcounter{part}{0}
+\setcounter{section}{2}
+\setcounter{subsection}{1}
+\setcounter{subsubsection}{0}
+\setcounter{paragraph}{0}
+\setcounter{subparagraph}{0}
+\setcounter{figure}{2}
+\setcounter{table}{0}
+\setcounter{lstnumber}{1}
+\setcounter{lstlisting}{0}
+}

data/my_help_nasu/latex_dir/method_bdd.tex

@@ -0,0 +1,28 @@
+
+\subsection{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が必要で，そこでサイクルが回ることを意図しています．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=10cm,bb= 0 0 737 453]{../figs/./my_help_nasu.001.jpg}
+\caption{RSpecとCucumberのRed-Green-Refactoringサイクル間の関係．}
+\label{default}\end{center}\end{figure}
+BDDの基本的な考え方は次の通りまとめられています．
+
+\begin{quotation}
+BDDの目的は，ソフトウェアが使われる状況を説明するための言語を単純化することで，ソフトウェア開発チームのコミュニケーションを後押しすることです．つまり，あるコンテキストで(Given)，あるイベントが発生すると(When)，ある結果が期待されます(Then)．BDDにおけるGiven, When, Thenの３つの単語は，アプリケーションやオブジェクトを，それらの振る舞いに関係なく表現するために使われる単純な単語です．ビジネスアナリスト，テスト担当者，開発者は皆，それらをすぐに理解します．これらの単語はCucumberの言語に直接埋め込まれています[1, pp.3-6]．
+
+\end{quotation}
+手順を書き直すと次の通りです．
+
+\begin{figure}[htbp]\begin{center}
+\includegraphics[width=10cm,bb= 0 0 737 453]{../figs/./my_help_nasu1.001.jpg}
+\caption{RSpecとCucumberの手順．}
+\label{default}\end{center}\end{figure}
+まずCucumberで一つのシナリオに焦点を当てて，その振る舞いを記述するfeatureを書きます．一つずつつぶしていくのがこつです．一つのfeatureが書けたら、次に，それぞれfeatureを実現するステップに分けて仕様を決めて行きます．これはTDDのred green refactoringの前に行う作業，「仕様をきめる」に対応しています．このプロセスが終了したら，RSpecに行きます．
+RSpecでは実際にテストコードを書き，ここでもred, green, refactoringを行います．
+RSpecが成功したら，Cucumberのrefactoringを行います．
+

data/my_help_nasu/latex_dir/method_cucumber.aux

@@ -0,0 +1,28 @@
+\relax 
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Cucumberについて}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.1}概要}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.2}features}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.3}Cucumber,RSpecインストール}{11}}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces }}{12}}
+\newlabel{default}{{1}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.4}ディレクトリー構造と使用手順}{12}}
+\@setckpt{method_cucumber}{
+\setcounter{page}{15}
+\setcounter{equation}{0}
+\setcounter{enumi}{2}
+\setcounter{enumii}{0}
+\setcounter{enumiii}{0}
+\setcounter{enumiv}{0}
+\setcounter{footnote}{0}
+\setcounter{mpfootnote}{0}
+\setcounter{part}{0}
+\setcounter{section}{2}
+\setcounter{subsection}{2}
+\setcounter{subsubsection}{4}
+\setcounter{paragraph}{0}
+\setcounter{subparagraph}{0}
+\setcounter{figure}{2}
+\setcounter{table}{1}
+\setcounter{lstnumber}{17}
+\setcounter{lstlisting}{0}
+}

data/my_help_nasu/latex_dir/method_cucumber.log

@@ -0,0 +1,28 @@
+This is e-pTeX, Version 3.14159265-p3.7-160201-2.6 (utf8.euc) (TeX Live 2016) (preloaded format=platex 2017.1.26)  8 FEB 2017 06:33
+entering extended mode
+ restricted \write18 enabled.
+ file:line:error style messages enabled.
+ %&-line parsing enabled.
+**method_cucumber.tex
+(./method_cucumber.tex
+pLaTeX2e <2016/11/29> (based on LaTeX2e <2017/01/01>)
+Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.
+./method_cucumber.tex:2: Undefined control sequence.
+l.2 \subsection
+               {Cucumberについて}
+? 
+./method_cucumber.tex:2: Emergency stop.
+l.2 \subsection
+               {Cucumberについて}
+End of file on the terminal!
+
+ 
+Here is how much of TeX's memory you used:
+ 4 strings out of 493683
+ 74 string characters out of 6149653
+ 53892 words of memory out of 5000000
+ 3671 multiletter control sequences out of 15000+600000
+ 7511 words of font info for 31 fonts, out of 8000000 for 9000
+ 929 hyphenation exceptions out of 8191
+ 5i,0n,3p,51b,8s stack positions out of 5000i,500n,10000p,200000b,80000s
+No pages of output.

data/my_help_nasu/latex_dir/method_cucumber.tex

@@ -0,0 +1,205 @@
+
+\subsection{Cucumberについて}
+\subsubsection{概要}
+Cucumberが提供するBDDの内容をまとめると
+
+\begin{quotation}
+BDDはフルスタックのアジャイル開発技法です．BDDはATDP(Acceptance Test-Driven Planning)と呼ばれるAcceptance TDDの一種を含め，エクストリームプログラミングからヒントを得ています．ATDPでは，顧客受け入れテストを導入し，それを主体にコードの開発を進めて行きます．それらは顧客と開発チームによる共同作業の結果であることが理想的です．開発チームによってテストが書かれた後，顧客がレビューと承認を行うこともあります．いずれにしても，それらのテストは顧客と向き合うものなので，顧客が理解できる言語とフォーマットで表現されていなければなりません．Cucumberを利用すれば，そのための言語とフォーマットを手に入れることができます．Cucumberは，アプリケーションの機能とサンプルシナリオを説明するテキストを読み取り，そのシナリオの手順に従って開発中のコードとのやり取りを自動化します[1, 7pp.]．
+
+\end{quotation}
+と記されている．
+
+\subsubsection{features}
+Cucumberでは先の引用にある通り、振る舞いをシナリオとしてまず記述します．
+次に，英語のfeaturesのひな形を示します．
+\begin{lstlisting}[style=customRuby,basicstyle={\scriptsize\ttfamily}]
+% cat ./featrues/sample_e.feature
+Feature: Description of feature
+
+Scenario: Description of scenario
+  Given I want to explain scenario
+  Then I investigate
+  When I know the meaning
+\end{lstlisting}
+ファイルの先頭で，
+\begin{quote}\begin{verbatim}
+# language: ja
+\end{verbatim}\end{quote}
+と記すと日本語でのkeywordが認識されます．下記にmy\_todoに対するfeaturesファイルの具体例を示します．
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+# language: ja
+
+機能: todoの更新を行う
+todoは更新していくものであり，新しく書いたり終わったものを消したいので
+バックアップをとって，過去のtodoを残しておく
+
+シナリオ: コマンドを入力してtodoを更新していく
+ 前提 todoを編集したい
+ もし "my_todo --edit"と入力する
+ ならば editが開かれる
+ かつ 自分のtodoを書き込む
+
+シナリオ: コマンドを入力してバックアップをとる
+ 前提 todoの編集が終わった
+ もし "my_todo --store [item]"と入力する
+ ならば itemのバックアップを取る
+\end{lstlisting}
+このようにFeature, Scenario, Given, Then, Whenなどのcucumberが解釈する大文字で始まる
+keywordsに対して，それぞれ機能，シナリオ，前提，もし，ならばなどの単語があてられています．
+この機能により，より自然な日本語でfeaturesを書くことができ，
+顧客にもわかりやすく，開発者も書きやすくなっています。
+
+featureファイルで用意されているkeywordは
+\begin{quote}\begin{verbatim}
+cucumber --i18n LANG
+\end{verbatim}\end{quote}
+によって表示される．LANG=ja, enに対しては下記の通りになっています．
+
+\begin{table}[htbp]\begin{center}
+\caption{}
+\begin{tabular}{llll}
+\hline
+keyword   &ja(japanese)   &en(english)  \\ \hline
+ feature  & "フィーチャ", "機能"      &"Feature", "Business Need",   \\
+ & &"Ability"     \\
+background  &"背景"  &"Background"   \\
+scenario  &"シナリオ"        &"Scenario"     \\
+ &"シナリオアウトライン",  &"Scenario Outline",  \\
+ scenario\_outline   &"シナリオテンプレート","テンプレ",  & "Scenario Template"   \\
+ &"シナリオテンプレ"   & \\
+examples  &"例", "サンプル"   &"Examples", "Scenarios"          \\
+given   &"* ", "前提"        &"* ", "Given "          \\
+when   &"* ", "もし"        &"* ", "When "  \\
+then   &"* ", "ならば"       &"* ", "Then "  \\
+and    &"* ", "かつ"        &"* ", "And "   \\
+but    &"* ", "しかし", "但し", "ただし"  &"* ", "But "   \\
+given (code)   &"前提"   &"Given"        \\
+when (code)   &"もし"     &"When"         \\
+then (code)   &"ならば"   &"Then"         \\
+and (code)    &"かつ"     &"And"          \\
+but (code)    &"しかし", "但し","ただし"   &"But"          \\
+\hline
+\end{tabular}
+\label{default}
+\end{center}\end{table}
+%for inserting separate lines, use \hline, \cline{2-3} etc.
+
+\subsubsection{Cucumber,RSpecインストール}
+まずrspecをgemでinstallする．
+
+\begin{enumerate}
+\item gem install rspec --version 2.0.0
+\item rspec --help
+\end{enumerate}
+と入力して
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+/Users/nasubi/nasu% rspec --help
+Usage: rspec [options] [files or directories]
+\end{lstlisting}
+のような表示がされていればinstallができている．次に，cucumberをinstallする
+
+\begin{enumerate}
+\item gem install cucumber --version 0.9.2
+\item cucumber --help
+\end{enumerate}
+と入力して
+\begin{lstlisting}[style=customCsh,basicstyle={\scriptsize\ttfamily}]
+cucumber --help
+Usage: cucumber [options] [ [FILE|DIR|URL][:LINE[:LINE]*] ]+
+\end{lstlisting}
+のような表示がされていればinstallできている．
+
+\subsubsection{ディレクトリー構造と使用手順}
+cucumberはRubygemsの提供する基本directory構造での作業を前提としています．
+その構造を表示すると次のようになります．
+\begin{quote}\begin{verbatim}
+bob% tree .
+.
+├── Gemfile
+├── Rakefile
+├── features
+│   ├── hogehoge.feature
+│   ├── step_definitions
+│   │   └── hogehoge_step.rb
+│   ├── support
+│       ├── env.rb
+├── lib
+│   ├── daddygongon
+│   │   ├── emacs_help.yml
+│   │   ├── my_todo.yml
+├── pkg
+├── spec
+│   ├── my_help_spec.rb
+│   ├── my_todo
+│   │   ├── todo_spec.rb
+│   ├── spec_helper.rb
+│   └── support
+│       └── aruba.rb
+\end{verbatim}\end{quote}
+カレントディレクトリ(.)の中にfeaturesというサブディレクトリを作成します．
+そのfeaturesの中に書きたいシナリオを書いた，hogehoge.featureを作成します．
+featureの具体例は上記に示してします．
+
+次にシェルを開いて，カレントディレクトリで，
+\begin{quote}\begin{verbatim}
+cucumber features hogehoge.feature
+\end{verbatim}\end{quote}
+と入力します．そうすると以下のような出力が得られます．
+\begin{lstlisting}[style=customRuby,basicstyle={\scriptsize\ttfamily}]
+Feature: Description of feature
+
+  Scenario: Description of scenario  # features/hogehoge.feature:3
+    Given I want to explain scenario # features/hogehoge.feature:4
+    Then I investigate      # features/hogehoge.feature:5
+    When I know the meaning # features/hogehoge.feature:6
+
+1 scenario (1 undefined)
+3 steps (3 undefined)
+0m0.066s
+
+You can implement step definitions for undefined steps with these snippets:
+
+Given(/^I want to explain scenario$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+Then(/^I investigate$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+When(/^I know the meaning$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+\end{lstlisting}
+ここではステップ定義に使用することができるコードブロックが表示されています．
+ステップ定義はステップを作成するための方法です．このサンプルでは，Giver(), When(), Then()の
+3つのメソッドを使ってステップを記述します．
+これらのメソッドはそれぞれ\/\/で囲まれたRegexp(正規表現)とブロックを受け取ります．
+Cucumberはシナリオの最初のステップを読み取り,そのステップにマッチする正規表現を持つステップ定義を探します．
+その中の対応するステップ定義のブロックを実行します．
+
+これはfeaturesディレクトリの下にstep\_definitionsディレクトリーにあることになっています．
+このシナリオを成功させるには，Cucumberが読み込めるファイルにステップ定義を保存する必要があります[1, pp15.]．
+その内容は次の通りcucumberから自動生成されます．
+\begin{lstlisting}[style=customRuby,basicstyle={\scriptsize\ttfamily}]
+
+Given(/^I want to explain scenario$/) do
+  pending # Write code here that turns the phrase above into concrete actio\
+ns  
+end
+
+Then(/^I investigate$/) do
+  pending # Write code here that turns the phrase above into concrete actio\
+ns  
+end
+
+When(/^I know the meaning$/) do
+  pending # Write code here that turns the phrase above into concrete actio\
+ns  
+end
+
+\end{lstlisting}
+pendingを削除して，そこにあれば良いなと思うコードを記述していきます．
+ここまでがCucumberの使用方法のテンプレートです．
+

data/my_help_nasu/latex_dir/method_usage.aux

@@ -0,0 +1,28 @@
+\relax 
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}my\_helpについて}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.1}使用法}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.2}my\_helpのインストール}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.3}githubに行ってdaddygongonのmy\_helpをforkする}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.4}my\_helpの更新}{16}}
+\@writefile{toc}{\contentsline {paragraph}{gitを用いてmy\_helpを新しくする．}{16}}
+\@writefile{toc}{\contentsline {paragraph}{次にとってきた.ymlを\nobreakspace  {}/.my\_helpにcpする．}{16}}
+\@setckpt{method_usage}{
+\setcounter{page}{17}
+\setcounter{equation}{0}
+\setcounter{enumi}{2}
+\setcounter{enumii}{0}
+\setcounter{enumiii}{0}
+\setcounter{enumiv}{0}
+\setcounter{footnote}{0}
+\setcounter{mpfootnote}{0}
+\setcounter{part}{0}
+\setcounter{section}{2}
+\setcounter{subsection}{3}
+\setcounter{subsubsection}{4}
+\setcounter{paragraph}{0}
+\setcounter{subparagraph}{0}
+\setcounter{figure}{2}
+\setcounter{table}{1}
+\setcounter{lstnumber}{17}
+\setcounter{lstlisting}{0}
+}

data/my_help_nasu/latex_dir/method_usage.tex

@@ -0,0 +1,76 @@
+
+\subsection{my\_helpについて}
+\subsubsection{使用法}
+my\_helpは本研究室の西谷が開発したものです．
+
+以下はmy\_helpのREADMEです[2]．
+
+CUI(CLI)ヘルプのUsage出力を真似て，user独自のhelpを作成・提供するgem.
+
+\begin{enumerate}
+\item 問題点
+\end{enumerate}
+CUIやshell, 何かのプログラミング言語などを習得しようとする初心者は，
+commandや文法を覚えるのに苦労します．少しのkey(とっかかり)があると
+思い出すんですが，うろ覚えでは間違えて路頭に迷います．問題点は，
+- manは基本的に英語
+- manualでは重たい
+- いつもおなじことをwebで検索して
+- 同じとこ見ている
+- memoしても，どこへ置いたか忘れる
+
+などです．
+
+\begin{enumerate}
+\item 特徴
+\end{enumerate}
+これらをgem環境として提供しようというのが，このgemの目的です．
+仕様としては，
+- userが自分にあったmanを作成
+- 雛形を提供
+\begin{quote}\begin{verbatim}
+ - おなじformat, looks, 操作, 階層構造
+\end{verbatim}\end{quote}
+- すぐに手が届く
+- それらを追加・修正・削除できる
+
+hikiでやろうとしていることの半分くらいはこのあたりのことなの
+かもしれません．memoソフトでは，検索が必要となりますが，my\_helpは
+key(記憶のとっかかり)を提供することが目的です．
+
+\subsubsection{my\_helpのインストール}
+\subsubsection{githubに行ってdaddygongonのmy\_helpをforkする}
+\begin{enumerate}
+\item git clone git@github.com:daddygongon/my\_help.git
+\item cd my\_help
+\item rake to\_yml
+\item rake clean\_exe
+\item [sudo] bundle exec exe/my\_help -m
+\item source ~/.zshrc or source ~/.cshrc
+\item my\_help -l
+\item rake add\_yml
+\end{enumerate}
+\subsubsection{my\_helpの更新}
+\paragraph{gitを用いてmy\_helpを新しくする．}
+\begin{enumerate}
+\item git remote -vをする(remoteの確認).
+\item (upstreamがなければ)git remote add upstream git@github.com:gitname/my\_help.git
+\item git add -A
+\item git commit -m 'hogehoge'
+\item git push upstream master(ここで自分のmy\_helpをupstreamに送っとく)
+\item git pull origin master(新しいmy\_helpを取ってくる)
+\end{enumerate}
+\paragraph{次にとってきた.ymlを~/.my\_helpにcpする．}
+\begin{enumerate}
+\item cd my\_helpでmy\_helpに移動．
+\item cp hogehoge.yml ~/.my\_help
+\end{enumerate}
+それを動かすために
+(sudo)bundle exec ruby exe/my\_help -mをする.
+
+ここで過去にsudoをした人はpermissionがrootになっているので，sudoをつけないとerrorが出る．
+
+(sudoで実行していたら権限がrootに移行される)
+
+新しいターミナルを開いて動くかチェックする．
+

data/my_help_nasu/latex_dir/my_help_nasu.aux

@@ -0,0 +1,12 @@
+\relax 
+\@input{overview.aux}
+\@input{introduction.aux}
+\@writefile{toc}{\contentsline {section}{\numberline {2}先行研究，方法}{6}}
+\@input{method_bdd.aux}
+\@input{method_cucumber.aux}
+\@input{method_usage.aux}
+\@input{code.aux}
+\@input{features.aux}
+\@input{consideration.aux}
+\@writefile{toc}{\contentsline {section}{\numberline {5}謝辞}{28}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}参考文献}{28}}