GitとGitHubの概要②
お疲れ様です！
IHです！
さて、今日は、前回のGitHubの続きをやっていきたいと思います！
前回は
・Gitの管理下にあるファイルやディレクトリの変更修正の記録を保管するところをリポジトリという
この辺りをアウトプットしましたね！
今回は実際に、
についてアウトプットを行っていきたいと思います！
よろしくお願い致します！
ーーーーーーーーーーーーーーーーーーーーーーーー
まずは、ターミナルでrails newコマンドを使って、新規アプリケーションを作りましょう！
記述例：rails _6.0.0_ new アプリケーション名 -d mysql
今回は、練習用として「git-app-1」という名前のアプリケーションを作ってみました。
記述は省きますが、以下のような、簡単な機能を持ったアプリケーションとしますね。
「テキストを新規投稿する（例：こんにちは！）」
↓
「投稿完了ページに移動する」
↓
「【投稿一覧に戻る】というボタンをクリックすると、投稿一覧画面に移動する」
↓
「投稿一覧画面に、自分が投稿したテキストが追加されている（例：投稿した「こんにちは！」というメッセージがが表示されている）」
続いて、GitHubデスクトップを立ち上げてください。
まだGitHubデスクトップをインストールできていない方はこちらからどうぞ！
すると、以下のような画面が出てくると思います。
次に、左上の「Current Repository」をクリックしてください。「first_app」や「git-app」と書いているものは、僕が練習で使っていたものです。
無視して進めてください。
◉ローカルリポジトリの作成
ここから、ローカルリポジトリを作成していきます！
まずは、「ADD ▼」をクリックしてください。
すると選択肢が出てくるので、「add an Exiting Repository」を選択です。
ここで、「Choose」をクリックしましょう。すると、Finderが開かれるので、先ほど作ったアプリケーションを選んだ後、「Add Repository」をクリックします。
僕の場合はgit-app-1ですね。
すると、次のような画面になります。
これで、ローカルリポジトリが完成しました！
ここで「commit」というGitHubの用語を紹介します。
commitとは、
「ファイルやディレクトリの変更修正を、リポジトリに記録すること」
です。
これから、そのcommitを行います。
すぐ下の画像をご覧ください。右下の入力欄に「最初のコミット」と書いてあると思います。この入力欄には、ファイルの変更修正の内容をわかりやすく書きます。
この、
「ファイルの変更修正の内容をわかりやすくするための記述」
のことを、
「コミットメッセージ」
と言います。
(今回はわかりやすくするため「最初のコミット」と日本語で記述しましたが、開発体制によっては、英語での記述を求められることもあるそうです。GitHubが世界中で使われているサービスだからですね)
コミットメッセージを入力できたら、「commit to master」をクリックしましょう。
そうすると、次のように表示されます。
これで、ローカルリポジトリに
「アプリケーションの全ての情報を保存する」
という内容の変更修正を記録できました。
最初の変更修正が完了したわけですね。
しかし、ローカルリポジトリ（自分のPC上に置かれたリポジトリ）を作っただけなので、他の人にデータを見てもらうには、わざわざ自分のPCを見せないといけません。
「リモートリポジトリ（外部サーバー上に置かれたリポジトリ）があれば、離れた人にも見せられるのに……」
と思っちゃいますよね。不便……。
というわけで、リモートリポジトリの作成に移りたいと思います！
◉リモートリポジトリの作成
次の画像をご覧ください。青い「Publish repository」と書かれたボタンをクリックしましょう。
すると、次のようなポップアップが出てきます。
「☑️Keep this code private」のチェックを外し、
「Publish Repository」をクリックしましょう。
（Keep this code privateにチェックが入っていると、非公開になってしまいます）
これで、リモートリポジトリの作成は完了しました！
実際にリモートリポジトリが作成できているか、GitHubのサイトで確認してみましょう！
画面左側の「Repositories」の下に
「ユーザー名/アプリ名」
と表示されていればリモートリポジトリの作成が成功しています！
ーーーーーーーーーーーーーーーーーーーーーーーー
いかがでしたか?
夜も遅くなってしまったので、一旦ここまでにしたいと思います。
ここまで読んでくださりありがとうございました！
それではまた！
GitとGitHubの概要①
皆様お疲れ様です！
IHです！
最近、GitとGitHubについて学んだので、アウトプットしていきます！
それではいきましょう！
ーーーーーーーーーーーーーーーーーーーーーーーー
まず、Git(ギット)とは
「ファイルやディレクトリの変更履歴を記録・追跡するためのバージョン管理システム」
のことをいいます。このGitという管理システムを利用すれば、今までは
「うわっアプリを作ってたらエラーが出た！ くそ！ どこが原因で出たんだ！？ 探さないと！」
と困っていたのが、
「あ、ここが原因だったのか〜！ じゃあここを○○に修正して……」
と、対策がしやすくなるわけですね。
続いて、GitHubとは
「Gitを利用した、複数人での開発を簡単にできるようになるWebサービス」
です！
Googleドライブのようなクラウドサービスに近いイメージです。
これを利用すれば、自分のPC上だけでなく、外部サーバーにも保存できます。
このGitとGitHubmを利用するために必要な準備は、以下の2点です。
・GitHubのサイトでアカウント登録
・GitHub Desktopのインストール
この辺りの準備については、解説しているサイトや本等があるので、割愛させていただきます。
それでは、次は、GitHubを利用する上で大切な用語について、ちょっと見ていきたいと思います！
まず、リポジトリです！
リポジトリとは、
「Gitの管理下にあるファイルやディレクトリの変更記録を保存する箱のような物」
をいいます。
このリポジトリには、ローカルリポジトリと、リモートリポジトリの2種類があります。
ローカルリポジトリとは
「自分のPC上、つまりローカル環境上に置くリポジトリ」
のことです。
対して、リモートリポジトリとは、
「外部サーバー上に置くリポジトリ」
のことです。
ローカルリポジトリには、ファイルやディレクトリの変更修正を好きなタイミングでリポジトリに記録できます（自分のPC上にあるため）。
しかし、リモートリポジトリに、ファイルやディレクトリの変更修正を直接記録することはありません。
ローカルリポジトリに変更修正を記録
↓
ローカルリポジトリの変更修正を、リモートリポジトリに同期、反映させる
という方法をとります。
ーーーーーーーーーーーーーーーーーーーーーーーー
いかがでしたか？
今回触れたGit、GitHubの内容は、ほんの入り口の部分になりますので、他の用語や、使用方法などについては、また後日解説させていただきたいと思います。
また、ブログの更新ペースですが、勉強とのバランスも考えて、
「2日に1回」
のペースでやっていきたいと思いますので、よろしくお願い致します！
それでは、ここまで読んでくださってありがとうございました😁
ビューファイルでインスタンス変数を使う時
どうも、お疲れ様です！
IHです！
さて、明日に備えて(もう今日ですが。😅)、
寝ようとしていたところでしたが。
でしたが、
ちょっとどうしてもアウトプットしておきたい事があったので、書いております。
それはRailsについてのことなんですが
「コントローラーファイルで、アクション内に定義したインスタンス変数は、対応するビューファイルでも使用できる」
という内容です。
この私IH、ちょっとこのあたりの理解が曖昧だったのですが、さっきテックキャンプのカリキュラムで復習していたら
、
「あっそういうことか！」
と、点と点が繋がる感覚があったので！
忘れずアウトプットしていきたいと思います！
それではいってみよう！
ーーーーーーーーーーーーーーーーーーーーーーー
さて、早速ですが、アウトプットしたい内容は以下の通りです。
コントローラーファイル内で
といったように定義したインスタンス変数は、そのアクションに対応するビューファイルにも、その定義したインスタンス変数を利用する事ができる。
たとえば、postsコントローラーファイルで、indexアクションに
class PostsController < ApplicationController
def index
@post = Post.find(1)
end
end
と記述したら、
app/views/postsディレクトリ内の
index.html.erbというビューファイルに、コントローラーのinndexアクションで定義したインスタンス変数を使用できる分です！
それで、ここからがポイントなのですが。
ビューファイルで使いたいからといって、
<%= @post %>
と書いてしまっては、エラーが出てしまいます。
（ビューファイルで表示させたい処理があるときは、<%= %>の間に記述します）
これは、コントローラーで定義した@postには、
postsテーブルの一番目のレコードが丸ごと入っているためです。
例えば、postsテーブルの1番目のレコードに以下のようなデータが入っていたとします。（自分のノートです😁）
どうやら一番目のレコードのデータには「idカラム」「contentカラム」「created_atカラム」という3つのカラム（項目）があるようです。それらのカラムの値を見てみると
・id：1
・content：はじめまして
・created_at：2020-01-01-00:00:00（レコードが作られた時間は2020年1月1日0時0分0秒ということ）
となっています。
したがって、ビューファイルで
<%= @post %>
と書いてしまうと、コンピューターが
「えっ？ いやテーブルの一番目のレコードのデータが欲しいのまではわかるけど、一体どのカラムの値が欲しいのよ！？
id？ content? created_at?
アーンあたしわかんない誰か教えて〜！」
何でオネエ口調なんだこのコンピューター、というツッコミは置いといて。
要するに、表示させたい値を1つまで絞ってあげないと、コンピューターがどれを表示させればいいかわからず、混乱してしまうわけですね。その結果、エラーが起きると。
では、どうすればいいの？
簡単です。カラムを指定してあげればいいんです。
具体的な方法としては、
＊カラム名の前には、(.)ドットを記述することも忘れずに！
つまり、ビューファイルのindex.html.erbで、
postsテーブルの一番目のレコードカラムの
「contentカラム」
を表示させたければ、
<%= @post.content %>
と記述することになります！
ーーーーーーーーーーーーーーーーーーーーーーー
いかがでしょうか？
最近、応用カリキュラムの内容が、基礎の時よりちょっと複雑になり、
「うーん、一度今までのRuby、Railsの内容を復習しておくほうがいいかもなぁ」
と感じていました。
それで、今日は復習を中心に勉強していこうと思っていたわけですが……。
いやーいい復習になりました！ 今日はちょっとだけ前に進めた気がします！
この調子で、楽しくどんどんプログラミングを学んでいきたいと思います！
それではこの辺で！
ここまで読んでくださり、ありがとうございました！
アプリケーション開発の手順について
どうも、IHです！
今日はプログラムを書く系の話ではなく、
「アプリケーションの開発手順」
について学んだので、アウトプットしていきたいと思います。
(実際には、制作会社によってこの手順は異なるそうですが、今回は一般的な制作手順を学びました)
これまでは
カリキュラム通りにプログラムを記述する
↓
その通りに動くか検証する
といった流れでしたが、
エンジニア っぽくなってきましたね！
楽しみです😁
それでは早速いってみよう！
ーーーーーーーーーーーーーーーーーーーーーーーー
まず、アプリケーションの開発前にやることについて触れます。
「開発」というのは、実際にコードを書く段階ですね！ その前にやるべき事があるというわけです。
開発前の流れをざっくり説明すると、以下のようになります。
「企画」
↓
「要件定義」
↓
「設計」
それぞれの段階について、順番に見ていきましょう！
・企画とは？
……「誰の（ターゲット）」「どんな問題を解決したいか」を決めます。
この答えによって、新しくアプリを作るのか、それとも既にリリースしているアプリに機能を追加するのかが決まります。
・要件定義とは？
…… 企画で「誰の」「どんな問題を解決するか」が決まったら行う、詳細な情報整理のことを、要件定義と言います。
具体的には、
「ユーザーがどのように機能を使用するのか、を考え言語化する」
「障害が起こったとき、どうするのかを決める」
と言ったことを整理します。
・設計とは？
……「エンジニアが実際にどのようなアプリや新しい機能を作っていくか」の手順書や、必要な設計図を作ります。
上記3つが、開発前に行うことです。
これらをしっかりと行ってから、開発の段階に入れるわけですね。
続いて、その開発が終わったあとに何をするのかを見ていきましょう！
開発後にやることの流れは、大きく2つです。
「デプロイ」
↓
「保守/運用」
こちらもそれぞれ見ていきますね。
・デプロイとは？
……実際に作ったアプリを、外部のサーバーに移して、全世界からアクセスできるようにすることです。
・保守/運用とは？
……デプロイした後、アプリに不具合が起こったら、正常に機能するよう修正しなければなりません。また、アプリに異常がないか、定期的にチェックする必要もあります。これが保守/運用です。
「どれくらいの人数に使われるアプリなのか」
「どれくらい重要なアプリなのか」
によって、保守/運用のやり方は変わります。例えば、医療現場で使われるアプリに不具合が生じたとすれば、早急に対応しないといけませんよね。人の命に関わる事ですから。こういった、人の命に関わるものには、何が起きても良いよう何重もの策が講じられるそうです。
以上が開発後にやることの流れになります。
アプリケーション開発全体の流れを振り返ると、以下のようになります。
企画
↓
要件定義
↓
設計
↓
開発
↓
デプロイ
↓
保守/運用
ーーーーーーーーーーーーーーーーーーーーーーーー
いかがでしたか？
ざっくりと開発の全体の流れを振り返ってみました。
個人的な感想としては、事前準備として企画までは予想していましたが、要件定義や設計などもあるんですね！
どんなことでも、事前の準備はやっぱり大事ですね。
ちなみに、エンジニアが主に担当するのは、要件定義以降になるそうですよ。
企画は企画部さんの仕事になるみたいです。
でも、企画からやってみるのも面白そうですね！
僕は最近、筋トレにハマっているので、筋トレアプリの企画とか妄想してました😁
腕立て伏せとかするとき、自分で回数数えるのちょっとしんどかったりするじゃないですか？
だから
「腕立て伏せをカウントしてくれるスマホアプリ」
があったらいいなって思ってたんです。
以下、アプリの大まかなイメージです。
・画面には、「1回押す事に1回カウントしてくれるカウントボタン」と「何回したかを数字で表示するカウンター」を表示させる。
・顎や鼻で押せるよう、カウントのボタンは大きくする（顎や鼻で押さないといけないので、腕立て伏せも深いものになってサボれない）。
・「制限時間内に何回できるか！？」
または
「腕立て伏せ100回を何秒でできるか！？」
といったチャレンジモードと、ユーザーのランキング機能
こんな感じですね！
いや多分、もう同じようなアプリあると思いますが😅
それに、たとえば
「30秒以内に何回できるか！？」ってチャレンジモードでランキング機能を付けても、
「俺30秒で200回出来たわ笑（指でボタン連打しただけ）」
ってユーザーが出てきて、ランキング機能自体が形骸化しそう……
そもそも今勉強してるRubyやRailsで作れるんだろうか……
とか考え出したら、アプリを出すのって難しいですね！🤣
以上、アプリを自分で作るという私の妄想でした😌
こんな感じで、どんな時も。
エラーが起きた時だろうと。笑
楽しみつつ勉強していきます！
今日もみてくださってありがとうございました！
アイソレーション
お疲れ様です_(._.)_
今日もRuby on Railsの勉強をしていたIHです。
今日は
「Ruby on Railsで、『pictweet』という、Twitter風のアプリを制作してみよ～」
というカリキュラムをやっておりました。
・ユーザー登録機能の追加
・マイページの実装
という内容だったのですが、これが中々のボリュームでした。
モデルやテーブルが複数出てきたことにより、コードがより複雑になる。そして、その複雑なコードをシンプルな記述にすべくと、色々な概念やメソッドも登場してきました。
正直、
「情報量多過ぎて頭ついていかねー！」
状態でしたね。笑
まあでも、この「わかんねー！」は、
Railsを使う人たちが全員通る道だと思うので。
それに、僕も先週まで
「ターミナルってなんなん！？
Linuxコマンドって何の役に立つん！？」
という状態から、普通に
「◯◯ディレクトリに移動したいから、cd ◯◯
を実行して……と。オッケー、移動できたから
ruby sample.rbで実行や！」
ってやれてますからね。何とか。
だから、何度も使っていく中で、理解できてくる部分もあるんじゃないかなと思ってます。
気持ちはリラックス。
されど行動は怠らず。
ということで今日もアウトプットしていきましょー！！
日付をまたいで、もう今日じゃなくなってますが。笑
ーーーーーーーーーーーーーーーーーーーーーーー
さて、今日は先ほど紹介しました、
「ユーザー登録機能」
を実装する上で重要な概念についての
アウトプットをしたいと思います。
その概念の名は
「アイソレーション」
です！
説明しよう！ アイソレーションとは！？
・アイソレーション
→モデルを利用して、テーブル同士に関連付けを行うこと。
もうちょっと詳しく説明しますね。
ユーザー登録機能を実装するには、
複数のモデルが必要になってきます。
昨日まで僕が作っていた「pictweet」には、
・ツイートの文章(例：今日は海に行ってきました！)
・画像(例：海の写真)
・名前(例：IH)
という3つの情報をもつ「tweetsテーブル」と、
tweetsテーブルに対応する「Tweetモデル」だけがありました。
つまり、この時点では
１つのテーブルと１つのモデル
しか「pictweet」は持っていなかったのです。
だから、投稿はできても
「誰がどのツイートを投稿したのか」
といった情報がありません。
または、以下のようなこともできてしまいます。
「あいつ海に行っただと！ リア充しやがって！ 俺が削除してやる！ 」
「『彼女とデートに行きました！』だって！？
くそっ！ 羨ましい！ 悔しいから自撮り写真をゴキ◯リの画像に差し替えてやる！」
といったように、他人のツイートを勝手に削除したり、編集したりできるわけですね。
もうめちゃくちゃだよ。
しかし、
・ユーザーの名前(ニックネーム)
・Email
・パスワード
といった情報をもつ「usersテーブル」とそれに対応した「Userモデル」を作り、usersテーブルとtweetsテーブルを関連付ければ、
・各ユーザーが、自分の投稿したツイートを編集したり、削除することができる！
・誰がどのツイートを投稿したのかがわかる！
となります！
(これをするには、deviceという、ユーザー管理機能を簡単に実装してくれるGemが必要なのですが、説明が長くなるため、ここでは省きます。
めっちゃ大事なんですがね。僕もまだ理解しきれていないので、勉強しておきます✍️)
ここで、2つのメソッドが出てきます。
それは、
・has_manyメソッド
・belongs_toメソッド
です。
has_manyメソッドとは、
「１人のユーザーが複数の投稿を所持している状態」を示すメソッドです。
我々がするツイートは、ユーザーにとって「所持しているもの」なんですね。
belongs_toメソッドとは、
「１つの投稿は、１人のユーザーに所属する」
ということを示すメソッドです。
確かに、１つの投稿を複数人で所有する、なんてこと、ありませんものね。
has_manyメソッドは
app/models/user.rbに
「has_many :tweets」
と、
belongs_toメソッドは
app/models/tweet.rbに
「belongs_to :user」
と記述します。
１人のユーザーは、複数の「tweets」を持つ。
１つのツイート(投稿)は、１人の「user」に所属する。
ということですね。
ーーーーーーーーーーーーーーーーーーーーーーー
いかがでしたか？
正直、ここの分野は、理解するのに時間がかかりそうです。
そのため、至らない説明になっているかと思います。
もし
「ここはこういう意味だよー！」
というご意見等があれば、是非お願いいたします！
それでは、今日も最後まで読んでくださってありがとうございました！
RubyGemsについて
お疲れ様です。
IHです。
今日は、新たに学んだ「RubyGems」について
アウトプットをしていきたいと思います。
--------------------------------------------------------------
まず、プログラミングには「ライブラリ」と呼ばれる拡張機能があります。
ライブラリとは、他のプログラムと組み合わせて使うために、複雑なプログラムを一つにしたものです。このライブラリをアプリケーションに読み込まれば、複雑な機能でも簡単に実装できるのです。
Rubyにおけるライブラリは「Gem」と呼ばれます。
Gem。日本語に訳すと「宝石」という意味ですね。
さらに、その「Gem」というライブラリをたくさん管理しているのが、
「RubyGems」です。
こんな画面が出てきます ↓
僕がみた時にはダウンロード数が550億もありました。
550億回もダウンロードされたって事ですよね？
ヒエーッ！ すごすぎ！
実は、現在、僕が大変お世話になっているフレームワークの
「Ruby on Rails」もGemなんですよね。今日まで知らなかったです。
（フレームワークとは、少ない労働力でアプリケーションの実装をする事ができる仕組みのことです。Ruby on Railsは、Ruby専用のフレームワークで、めちゃくちゃ人気があります）
また、このGemは、1つだけインストールしても効果がない場合もあるそうです。
Gemの中には、他のGemの機能により成り立っている物もあるのだとか。複雑ですね。
ちょっと例を出します。
（以下は僕のイメージですので、間違っていたらご指摘ください）
*******************************************************************
仮に「Gem①」と言う名前のGemをインストールしたとします。しかし、せっかくインストールしたのに全く動かない……。
確認してみると、どうやら「Gem②」という名前のGemもインストールしないと、Gem①は動かないようです。
「じゃあ、そのGem②とやらをインストールしてみよう」
Gem②をインストールしました。しかし、それでも動きません。すると今度は「Gem③」という名前のGemをインストールしないと、Gem②は動かないようです。
「……じゃあGem③をインストールすればいいのね？」
Gem③をインストールしました。しかし、それでも動きません。すると今度は「Gem④」という名前のGemをインストールしないと、Gem③は動かないようです。
「わかったよ！ Gem④インストールしたらいいんでしょ！」
Gem④をインストールしました。しかし、それでも動きません。すると今度は「Gem⑤」という名前のGemをインストールしないとーー。
「もう勘弁してくれよっ！！！」
*******************************************************************
こうなったら、嫌ですよね😅
はっきり言って、めんどくさいです。誰も使う気になりません。
そこで登場するのが「bundler」というGemです！
(bundlerは、日本語で「梱包機、結束機」だそうです)
このbundlerは、必要なGemやバージョンを合わせてインストールしてくれる優れもの！
これでやっと動きます。笑
ちなみに、アプリケーションで使用するGemの「名前」や「バージョン」といった情報を記載し、管理しているファイルのことを、「Gemfile」といいます。
また。、bundlerでインストールしたGemの情報を記録するファイルは「Gemfile.lock」といいます。
--------------------------------------------------------------
いかがでしたか？
自分なりに、ユーモラスに書いてみました。
ブログ書くのって、結構大変ですね😅
ここまで書くのに90分はかかりました。
改めて思いましたが、ブロガーさんは本当にすごいですね。
基本毎日更新としていますが、更新頻度については、勉強との兼ね合いも考えつつやっていけたらなと思います。
ここまで読んでくださってありがとうございました。
それではまた。
このブログの紹介
テックキャンプ短期転職コース81期生、IHと申します。
このブログの使用目的は以下の通りです。
・テックキャンプで学んだことを「ギブの精神を持って」アウトプットする。
「ん？ ギブの精神って、何なん？」
そう思われた方もいるかもしれません。
これから順番に説明していきます。
まず、テックキャンプを受講し始めた9日前に、
「勉強したことは、 人にわかりやすく説明する ことを意識しながらで勉強していくことで、自分の中に落とし込んでいける」
と学びました。
そのため、このブログでは
「第三者に説明するつもりで、プログラミング（HTML , CSS , Ruby , Ruby on Rails）の技術、知識を説明・紹介していく」
という使用目的を持って、日々記事を書いていきたいと思います。
しかし、「ただ自分がわかればいい」というものではなく、ワンポイント付け加えます。
そのワンポイントとは、
「第三者からすると、どう感じるだろうか」
という考え方です。こうするのには理由があります。
実は今日、有名Youtuberの「まこなり社長」のある動画を拝見しました。
（2020年7月15日時点で、テックキャンプを運営されている株式会社div様の代表取締役をされている方です）
それがこちら↓
この動画を一言で要約するなら
「一流はギブの精神を持っている」
だなと私は考えています。
動画内でもまこなり社長が語られていますが、GACKTさんやサッカーの本田圭佑選手は非常に話の上手い方たちです。名言も数多くあります。このお二人は、常に
「どう話せば、聞いてくれる人たちが楽しいと思ってくれるか」
を考え、そのための準備も日頃からしているそうです。
つまり、一流とは「相手に喜んでもらえるもの（話）を提供する」という、
「人に何かを与える心（まさにギブの精神）」
を常に持っているのです。
私はこの動画を見ながら
「これは、今後の自分にも言える重要な話だな」
と思いました。
私は、今後エンジニアとして、Webサイトやアプリケーションを開発していく立場になります。
その時には
「どうすればお客様にご満足いただけるか」
とお客様が快適に使えるサービスを常に考え、開発を行なっていかなければなりません。しかし、そのギブの精神は、一朝一夕で身につくものではないでしょう。
「それなら、今から練習すればいいじゃん！」
そう考えたため、私は、ただのアウトプットではなく
・テックキャンプで学んだことを「ギブの精神を持って」アウトプットする
というルールを自分に課したいと思います。
「どうすれば見てくださる方に喜んでもらえるか」
を、時には画像を使い、時にはユーモラスに説明していけたらなと思います。
というわけで。
長々となりましたが、よろしくお願い致します。
