Factoryパターン〜FactoryMethod〜

そこに、Factoryパターン一族

– Simple Factory[正確にはFactoryパターンではない]
– Factory Method
– Abstract Factory
の章があったので、
ぜひアウトプットしたく書きます!

今回はFactory Methodについてです!

Factory Method

オブジェクトを作成をカプセル化し、依存度を下げるために使います。
(Simple Factory、Abstract Factoryと同じ)

オブジェクト作成のためのインターフェースを
抽象クラス(スーパークラス)に定義しますが、
どのクラスをインスタンス化するかについてはサブクラスに決定させます

→抽象クラス(親クラス)は、
サブクラスの作成したオブジェクトを利用するだけで
具体的なオブジェクトが何なのかを知らない。

AbstractFactoryと違う部分
– 継承を使うので、サブクラス(子クラス)が
作成するオブジェクトの具体的な型を実装する。

 

クラス図でみるとこんな感じ

 

factoryMethodはサブクラスに任せるために、
Factoryクラス(スーパークラス)は抽象クラスになる。

クラス図からもわかるように、
Factoryクラス(スーパークラス)は
Prodoctオブジェクトを作成する具体的な方法は全く知りませんが、
factoryMethodを使えばProdoctオブジェクトを作成できることを知っています。
なので、anOperationメソッド内でfactoryMethodを使用することが多いです。

 

 

HeadFirstでは、
地域スタイルでピザの作り方が異なる
フランチャイズでの例がありました。

FactoryMethodのサンプルコード

 

クラス図はこんな感じ。

 

▶︎ PizzaStore(スーパークラス)
Pizzaオブジェクトを作成する具体的な方法は全く知りませんが、
createPizzaメソッドを使えばPizzaオブジェクトを作成できることを知っています。
→orderPizzaメソッド内でcreatePizzaを使用して実装している。

▶︎ NYPizzaStore(PizzaStoreのサブクラス)
具象Pizza(NYスタイル)オブジェクトを作成する

▶︎ChicagoPizzaStore(PizzaStoreのサブクラス)
具象Pizza(Chicagoスタイル)オブジェクトを作成する

▶︎ Pizza
抽象Pizzaクラス。
PizzaStoreのサブクラスにより、具象Pizzaオブジェクトが作成される。

└ NYCheesePizza 具象Pizzaクラス
└ NYClamPizza 具象Pizzaクラス
└ ChicagoCheesePizza 具象Pizzaクラス
└ ChicagoClamPizza 具象Pizzaクラス

 

メリット1:
地域ごとにピザメニューの作り方が異なっても大丈夫

地域ごとの具象PizzaStoreクラス、具象Pizzaクラスがある。
そのため、同じチーズピザでも、
NY店はゴーダチーズ、Chicago店はモッツアレラチーズにしたり
切り方はサブクラスでオーバライドするなど
多種多様に対応することができる。

 

メリット2:
ChicagoにあるけどNY出身者が多い地区のピザ屋にも対応可能

こんなクラスを作ればいい。
– ChicagoPizzaStore_ManyNewYorker.php

class ChicagoPizzaStore_ManyNewYorker extends PizzaStore
{
    public function createPizza(string $type): object
    {
        $pizza = null;
        if ($type == "チーズ(NY風)") {
            $pizza = new NYCheesePizza();
        } else if ($type == "チーズ(Chicago風)") {
            $pizza = new ChicagoCheesePizza();
        } else if ($type == "野菜(NY風)") {
            $pizza = new NYVeggiePizza();
        } else if ($type == "野菜(Chicago風)") {
            $pizza = new ChicagoVeggiePizza();
        }

        return $pizza;
    }
}

 
ピザ食べたくなりました。
やっぱりマルゲリータですよね。

Factoryパターン〜Simple Factory〜

この前、domicoのライブが宮崎であるというレアな事象ありました。
行かないわけにはいかないので、行ってきました。
めっちゃ、カッコ良いかったです。

 

早速ですが、私「増補改訂版Java言語で学ぶデザインパターン入門
を読んでますが、並行して楽しく読めると噂のこれも読んでいます。

そこに、Factoryパターン一族

– Simple Factory
– Factory Method
– Abstract Factory

の章があったので、
ぜひアウトプットしたく書きます!

今回はSimpleFactoryについてです!

Simple Factory

正確にはFactoryパターンではない!ですが便利なやつです。

サブクラスが複数存在する場合、
if文などで、各サブクラスをインスタンス化する
→ アプリケーション部分の各部分にif文が分散してしまったり、
保守と更新が困難になったり、実装の間違いが多くなるという問題があります。

 

したがって、
アプリケーション内で、
インスタンス化する部分(変化する部分)と変化しない部分
を分けてカプセル化する
というのがSimpleFactoryです。

 

SimpleFactoryのサンプルコード

こんなな感じかと思います。

 

上記でいうと、SimplePizzaFactory = SimpleFactoryになります。

 

▶︎PizzaStore

SimplePizzaFactoryのクライアント。
ピザをインスタンス取得しますが、
「ギリシャピザやクラムピザなどの具象ピザ」については知る必要がありません。
「pizzaインターフェースを実装したピザ(具象ピザ)を取得し、
prepareメソッド,bakeメソッド,…を呼び出せる」ことを知ってるだけで良い。
ピザを取得する事に関しては、SimplePizzaFactoryに任せるだけでOK!

 

▶︎SimplePizzaFactory

SimpleFactoryの主役。
ピザをの作成方法だけを扱うクラス。
具象Pizzaクラスを参照する唯一の部分。

 

▶︎Pizza

SimplePizzaFactoryの製品であるPizzaの抽象クラス。
具象ピザはこれを実装する。

└ VeggiePizza   具象ピザ(具象製品)
└ PepperoniPizza 具象ピザ(具象製品)
└ ClamPizza    具象ピザ(具象製品)
└ CheesePizza   具象ピザ(具象製品)

新作ピザの追加、ピザメニューの削除があっても。。。

大丈夫!

SimplePizzaFactory.php

- use HFD\SimpleFactory\Pizza\PepperoniPizza;
  use HFD\SimpleFactory\Pizza\ClamPizza;
  use HFD\SimpleFactory\Pizza\VeggiePizza;
+ use HFD\SimpleFactory\Pizza\GreekPizza;

function createPizza(string $type): object
{
        $pizza = null;
        if ($type == "チーズ") {
            $pizza = new CheesePizza();
-       } else if ($type == "ペパロニ") {
-           $pizza = new PepperoniPizza();
        } else if ($type == "クラム") {
            $pizza = new ClamPizza();
        } else if ($type == "野菜") {
            $pizza = new VeggiePizza();
+       } else if($type == "ギリシャ"){
+           $pizza = new GreekPizza();
        }

GeekPizza.php(新作ピザ)

+namespace HFD\SimpleFactory\Pizza;
+
+
+class GreekPizza extends Pizza {
+
+    public function __construct() {
+        $this->name = "ギリシャピザ";
+    }
+
+}

 

ピザの作成を
SimplePizzaFactoryに任せてるので、
SimplePizzaFactoryの修正と
新作ピザクラス(具象ピザ)の追加のみで対応できる。
さらに、PizzaStoreと分けているので
PizzaStoreには影響が少ない!

 

なによりシンプルでわかりやすいですね。

次は、FactoryMethodについて書きたいと思います!

claspでGAS(GoogleAppsScript)ファイルをGit管理する。

突然ですが、
私、ガチャガチャが好きなんです。
25才の今でも、ガンガンやっちゃってます。
最近の一押しはワニワニパニックとこれです。

 

はい、本題に入ります。

最近、社内ツールをGASで作ることが多かったり、
私自身slackのbotはGASで作ることが多いため、
Git管理をしたかったので方法を探しておりました。
そこで、この記事を参考にGit管理ができたので、書きます!
https://qiita.com/rf_p/items/7492375ddd684ba734f8

 
下記リポジトリはgasで作ったLINEbotです。
kin29/linebot_calendar
このソースも GAS + clasp + Gitをつかって管理しています。

 

使うもの

– GASファイル(プロジェクト)
– clasp
– Gitリポジトリ(GithubでもBitbucketでもなんでもok!)

 

claspとは?

Googleドライブ上にあるGoogleAppScriptなどのファイルを
コマンド操作でファイルの変更や保存などがブラウザでなく、
ローカル側で行うことができるものです。
GASって普通はGoogleドライブからブラウザ上でしかソースを書けないと思っていました。
claspを使うとエディターを使って、
コード整形とかも簡単にできるので超便利です。
参考:https://qiita.com/HeRo/items/4e65dcc82783b2766c03

 

0.claspコマンドの導入

npm i @google/clasp -g

 

1.clasp login

https://script.google.com/home/usersettings
にアクセスし、Google Apps Script APIをオンに。
これで該当アカウントのGASプロジェクトをclaspから操作が可能になります。
そして、ターミナルでclasp loginと打ちます。
すると、ブラウザが開いて許可しますかてきな質問が出てくるのでokすると成功したよメッセージがでてくればログイン完了です

$ clasp login
No credentials given, continuing with default...
🔑  Authorize clasp by visiting this url:
https://accounts.google.com/o/oauth2/v2/auth?access_type=XXXXXXXXXXXX...

Authorization successful.
Default credentials saved to: ~/.clasprc.json

 

2.既にあるGASファイルをローカルでpullする

$ mkdir [ファルダ名]  //このフォルダ以下をGit管理します。
$ cd [フォルダ名]
$ clasp clone [スクリプトID]
Cloned 2 files.
└─ コード.js
└─ appsscript.json

スクリプトIDは、 Git管理したいGASファイルを開いて、
ファイル>プロジェクトのプロパティ>情報の「スクリプト ID」に書いてます。

$ vi .clasp.json
{"scriptId":"[スクリプトID]"}

↑をしないと、複数GASプロジェクトが存在していると、
clasp pullした時にどのプロジェクトをpullしてくるかわからないので、
予期しないプロジェクトをpullしてきたりするのでした方がいいです!

 

3.Gitにファーストコミットする

リモートリポジトリは、GithubでもBitbucketでもなんでもokです。

$ git init
$ vi .gitignore //.clasp.jsonはGit管理外にする。
$ git status
$ git add -A
$ git commit -m 'first commit'
$ git remote add origin [リポジトリURL]
$ git push -u origin master

 

4-1.GoogleドライブよりGASファイルを更新後、ローカルにpullする

Googleドライブでコード変更した時は、ローカルにpullして同期します。

$ clasp pull

.clasp.jsonのスクリプトIDに基づくGASプロジェクトをpullしてきます。

 

4-2.ローカルよりGASファイルを更新後、ブラウザ側にpushする

ローカルでコード変更した時は、Googleドライブにpushして同期します。

$ clasp push

.clasp.jsonのスクリプトIDに基づくGASプロジェクトにpushします。

 

Gitで変更分をコミットする。

$ git add -A
$ git commit -m 'バグ修正'
$ git push origin [ブランチ名]

こんな感じです。
ちょっと面倒ですが、Git管理できるのは良きです。

stripe決済をフレームワーク使わずに組み込んでみる!(PHP)

こんにちは!
過去に簡単決済「stripe」を導入してみる。を紹介しました。
今更気づいたんですが、べつにLaravel使う必要なかったなって(笑)
ただ、使いたかったんだと思います!ww

そこで!
PHPのフレームワークを使わないパターンで
もっとシンプルに組み込みたいと思います。

完成は、こちらです。
[ kin29/stripe_practice_php ]
↑だと、.envの設定だけで
ビルドインサーバ立てたら、もうできちゃいます。

 

さあ、つくろう。

リファレンス

stripe API
Card Payments Quickstart
ほぼ、↑のクイックスタートをやってます。

環境

– Mac
– PHP7.2.7

準備

stripeアカウント発行、テスト環境申請(申請後すぐできました)
↑これだけ!

手順

1.プロジェクト(作業ディレクトリ)の作成

~$ mkdir stripe_practice_php/

 

2.stripe/stripe-phpの導入 ←composer経由

$ cd stripe_practice_php/
$ composer require stripe/stripe-php
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
Using version ^6.20 for stripe/stripe-php
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing stripe/stripe-php (v6.20.0)
    Downloading: 100%
Writing lock file
Generating autoload files

$ ls
composer.json composer.lock vendor

 

3.カード情報入力フォームをつくる。

$ cd stripe_practice_php/
$ vi index.php
...
<div class="content">  
  <div class="title">stripe DE おかいもの</div>
  <div>¥100</div>
    <form action="./payment.php" method="POST">
    <script
       src="https://checkout.stripe.com/checkout.js"
       class="stripe-button"
       data-key="{pk_test_XXXXXXXXXXXXXXXXXXX}"
       data-amount="{商品の値段}"
       data-name="{カード入力モーダルのタイトル}"
       data-description="{カード入力モーダルのタイトル下の説明文}"
       data-image="https://stripe.com/img/documentation/checkout/marketplace.png"
       data-locale="auto"
       data-currency="jpy">
    </script>
  </form>
</div>
...

 

 

4.バックエンドをつくる。

$ cd stripe_practice_php/
$ vi payment.php
<?php
require __DIR__.'/vendor/autoload.php';

\Stripe\Stripe::setApiKey("{sk_test_XXXXXX}"); 

$token = $_POST['stripeToken']; //ここでAPIにリクエストしてる
   
$charge = \Stripe\Charge::create([
    'amount' => 100,
    'currency' => 'jpy',  //usd(ドル)→jpy(円)に変更しました。
    'description' => 'Example charge',
    'source' => $token,
]);
    
//thanks.phpにリダイレクトさせる。
header("Location: ./thanks.php");

 

5.サンクスページをつくる。

$ cd stripe_practice_php/
$ vi thanks.php
...

<div class="content">
   <div class="title">「stripe DE おかいもの」<br>ご利用TEGEありがとうございました。</div>
   <div>利用金額:¥100</div>
  </form>
</div>

...

 

6.完成! →実際に動かしてみる「http://localhost:8080/index.php

$ cd stripe_practice_php/
$ php -S localhost:8080   //ビルドインサーバを立てる

※テスト用のカード番号の参考はこちら
https://stripe.com/docs/testing#cards

 

7.管理画面をみてみる。 →実際にみせちゃう
https://dashboard.stripe.com/test/dashboard

 

‘currency’ => jpy

に変更することにより、
円請求ができますが、管理画面ではドルに換算されていました。

 

まとめ

・簡単!早い!わかりやすい!

・ドキュメントは英語ですが、読みやすく充実してます。

・リンク型なので、面倒なトークン化(カード情報非保持)対応の必要なし!

・次は、PHP以外の言語でもしてみたいです!

Ubuntu環境構築してみる。

どうも!わたしはlinuxばかり触ってきた身なもので、
今回はubuntuを触ってみます!
わたしの妄想では、この2つにあんまり違いはないんでないかなって思ってました。
構築しただけだと、その認識のままです。
触りこんでくと違うんですかね。

<使うもの>
・Mac
・Vagrant
・VirtualBox

<構築環境>
・ubuntu
・Apache
・ホストOSとの共有ディレクトリ → ubuntu_share/
・(おまけ)pythonをデフォルトで3の方にする。

ubuntu環境構築

ubuntu環境との共有フォルダーをホスト側に作成

$ mkdir ubuntu_share

 

ubuntu環境用のディレクトリ作成、そのディレクトリ内に移動

$ mkdir ubuntu_dev
$ cd ubuntu_dev

 

ubuntu-18.04をいれて、立ち上げて、SSHで入ってみる。

$ vagrant init bento/ubuntu-18.04
$ ll  //Vagrantfileができてることを確認。
$ vagrant up
$ vagrant ssh
vagrant@vagrant:~$ exit //一旦出る。

 

設定ファイルVagrantfileよりIP・共有ディレクトリを設定し、

再起動後、SSHで入ってみる。

$ vi Vagrantfile

Vagrantfile

...
  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
config.vm.network "private_network", ip: "192.168.33.10"   //コメントアウト(#)を外す
....
  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
# config.vm.synced_folder "../data", "/vagrant_data"
config.vm.synced_folder "../ubuntu_share", "/home/vagrant/ubuntu_share"
...
$ vagrant reload
$ vagrant ssh
vagrant@vagrant:~$ ll  

ubuntu_share/があることを確認し、

テストファイルを作って、ホスト側にもあったら\(^^)/よし

 

Apache導入(サーバ)

/var/www/html/がルートになるはず。
Vagrantfileにて ip: “192.168.33.10”としてるので、
http://192.168.33.10でアクセスできるようになります。

$ sudo apt-get update
$ sudo apt-get install apache2
$ sudo /etc/init.d/apache2 start

 

pythonをデフォでPython3の方にする

元から Python 3.6.5/Python 2.7 は入ってます。 デフォルトをPython 3の方にする。

$ python -V
Python 2.7.15rc1
$ python3 -V
Python 3.6.5

 

デフォルトでは pip がインストールされてないので、インストールする。
pip とは…
The Python Package Index に公開されているPythonパッケージ・ライブラリのインストールなどが行える
らしい。

$ pip install {入れたいパッケージ名}
$ sudo apt install python3-pip python3-dev
$ sudo apt install python-pip python-dev

 

pyenvインストール

$ git clone https://github.com/yyuu/pyenv.git ~/.pyenv
## 環境変数の設定とか(上手く行くことを確認したら、~/.bash_profileなどに書いておく。)
$ export PYENV_ROOT=$HOME/.pyenv
$ export PATH=$PYENV_ROOT/bin:$PATH
$ eval "$(pyenv init -)"
$ source ~/.bashrc
$ pyenv --version
# 使えるもの一覧を表示する
$ pyenv install --list
# インストールしてみる
$ pyenv install -v 3.6.6
# デフォルトに設定する。
$ pyenv global 3.6.6
 
python -V
-> 3.6.6

 

ついでに、よく使うやついれておく

$ sudo apt-get install git gcc make openssl libssl-dev libbz2-dev libreadline-dev libsqlite3-dev
$ sudo apt-get install python3-tk tk-dev python-tk libfreetype6-dev

 

こんな感じでできました。
pythonも使ったことないので、
自分的疑問で、なんでpythonとpython3があるんだよ、統一させちゃいかんの?
ややこしんだよっって思ってます。。
なにか理由はあるんでしょうね、きっと。

Laravel環境構築してみる!

話題のこの本、
「PHPフレームワーク Laravel Webアプリケーション開発」読んでます!
まだ読み途中ですが・・・。
今回は最初の「環境構築」部分を自分なりにまとめたこと描きます。

環境構築のパターン

  1. VagrantでLaravel環境構築
  2. DockerでLaravel環境構築

二つとも、Macでやります!

1. VagrantでLaravel環境構築

■事前準備
・VirtualBoxのインスートル
・Vagrantのインスートル

■構築する環境
・ドキュメントルート … /home/vagrant/code/testapp/public
・laravelプロジェクトdir … /home/vagrant/code/testapp
・共有dir … /home/vagrant/code = /home/(ユーザdir)/code

■手順

$ cd  /*(user_dir)に移動する*/

$ vagrant box add laravel/homestead

$ git clone git@github.com:laravel/homestead.git Homestead

$ cd Homestead/

# 初期化
$ sh ./init.sh

# ゲストOSの設定ファイル調整
$ vi Homestead.yaml  /* ip、sites、authorize、keyの設定 */

# hosts設定 「192.168.10.10 homestead.test」
$ vi /etc/host  /* Homestead.yamlに合わせてip設定する */

$ cd /*(user_dir)に移動する*/

# ゲストOSとホストOSの共有dir先を作成 
# /home/vagrant/code = /home/(ユーザdir)/code
$ mkdir code/

$ cd Homestead/

# 調整し直したHomestead.yamlの設定でvagrantで環境を立てる 
$ vagrant up

# sshでゲストOSに入る
$ vagrant ssh

# ここからゲストOSにいる
$ cd code/

$ composer create-project laravel/laravel testapp --prefer-dist "5.5.*"

http://homestead.test/
にアクセスするとlaravelのページにアクセスできることを確認!完成\(^^)/

■つまったところ
・何回も作りなお直してたら、もうあるってめちゃ言われました。(以下参照)

The box you're attempting to add already exists. Remove it before
adding it again or add it with the `--force` flag.

Name: laravel/homestead
Provider: virtualbox
Version: 6.3.0

そんなときの対処方法
・その壱

$ vagrant global-status /* 動いてるやつの確認 */
$ vagrant global-status --prune /* 何も出てこない時はこっち */
$ vagrant destroy homestead-7 /* 「homestead-7」を指定してdestroy */

・その弐

$ cd ~/.vagrant.d/boxes/
$ ll
$ rm -rf {target}

2. DockerでLaravel環境構築

■事前準備
・Dockerのインスートール

■構築する環境
・ドキュメントルート … /var/www/public
・laravelプロジェクトdir … /var/www/
・共有dir … /var/www = /home/(ユーザdir)/laravel_docker/testapp

■手順

$ cd

$ mkdir laravel_docker

$ cd laravel_docker

$ git clone https://github.com/laradock/laradock.git

$ cd laradock

$ cp env-example .env

# コンテナ起動(初期化)
$ docker-compose up -d nginx mysql workspace phpmyadmin

# 起動中のコンテナ一覧の確認。各コンテナが起動(up)していることを確認
$ docker-compose ps

# ゲストOSに入る
$ docker-compose exec --user=laradock workspace bash

# testappという名前でlaravelをいれる。
$ composer create-project laravel/laravel testapp --prefer-dist "5.5.*" 

# ゲストOSからでる。
$ exit

# laradock/.envの調整。「APP_CODE_PATH_HOST=../testapp」に書き換える
# /var/www = (user_dir)/laravel_docker/testapp にさせるために!
$ vi .env

# コンテナ一旦シャットダウン
$ docker-compose stop
 
# コンテナ起動。再起動により.envが反映されます。
$ docker-compose up -d nginx mysql

http://localhostでアクセスすると、
laravelのデフォ画面がでるはずです!完成^^

この本ですが
内容はとても親切丁寧なので読みやすいです!
ADRの話なども書いてあって、私には難しいですが頑張れそうです!
もっと読んだらまた記事書きまうす。

コンフリクとが起きた時によく使うコマンド

 

久しぶりです。暑くなってきましたね。

Gitでコンフリクと起きた時って、「うわーめんどー><」ってなりますよね。

けど絶対王政みたいな感じで、こっちのブランチが「絶対正しいんだ!」ってときありますよね。そんな時に便利なgitオプションが下記コマンドがあります。

# 2つのブランチ間でコンフリクトしているファイル aaa.txt があるとする

# aaa.txt を現在チェックアウトしているブランチ側の対応に合わせる場合
$ git checkout --ours aaa.txt

# aaa.txt をマージさせたブランチ側に合わせる場合
$ git checkout --theirs aaa.txt

 

いつも忘れるので、エイリアスを作ろうとおもいます。

 

alias git-i-am-king='git checkout --ours $1'
alias git-you-are-king='git checkout --theirs $1'

 

しかし、
よくみたら、そんなでもないので覚え方を考えようと思います。

私たちが正しいのでわたしたちになりましょう、ね、aaa.txtさん。

$git checkout --ours aaa.txt

彼らが正しいので彼らになりましょう、ね、aaa.txtさん。

$git checkout --theirs aaa.txt

 

以上、くだらない投稿でした。

標準入出力、リダイレクト、パイプ

実家からお歳暮でもらったであろうビールをかっさらってきて、

帰宅と同時に飲むのが至福のひとときな今日この頃。

 

 

全体はこんな感じです。

 

▶︎標準入出力とは。

lsやcatなどの実行結果は、
指定しない限り、普通は画面に表示される。←これです!
デフォルトではそれぞれ以下のようになっている。
標準入力 → キーボード
標準出力 → 画面

こんな感じ

# キーボードで入力(標準入力)したものがそのままに出力(標準出力)される
echo hello!

 

▶︎リダイレクトとは。

「リダイレクト」を使うと、標準入出力を指定のファイルに変更することができる。

出力リダイレクト

画面(標準出力)でなく、ファイルに結果を出力する

# 「hello!」という出力結果を新規ファイルoutput.txtに出力
echo hello! > output.txt

#「>」は上書き
# dateコマンドの出力結果を既存ファイルoutput.txtに上書き
date > output.txt

#「>>」は追記
# 「add!」という出力結果を既存ファイルoutput.txtに追記
echo add! >> output.txt

入力リダイレクト

キーボード(標準入力)でなく、ファイルからの入力をコマンドに渡す

# cat output.txtと同じ結果
# cat 0< output.txtと同じ結果
cat < output.txt

echo 6+1 > input.txt
# bc 0< input.txtと同じ結果
bc < input.txt

 

▶︎パイプ「|」とは。

標準出力をコマンドに渡す

# 中間ファイルが不要となる 
# echo 6+1 > input.txt && bc < input.txt と同じ結果
echo 6+1 | bc

 

#余談

過去のコミット全部自分のものにしたい時

$ git filter-branch -f --env-filter "GIT_AUTHOR_NAME='名前';\
 GIT_AUTHOR_EMAIL='メールアドレス';\
 GIT_COMMITTER_NAME='名前';\
 GIT_COMMITTER_EMAIL='メールアドレス';" \
HEAD

過去のコミットを編集することは歴史をガラリとかえて未来に影響が大きいのであまりしないほうがいいです、はい。
けど今回グローバルネームでコミットしてしまっていたため変更しました。もちろん

$ git config --local user.name 名前
$ git config --local user.email "メールアドレス"

もしましたよ。

よく使うGitコマンド

 

Git DIFF

ブランチ間の差分を表示

$ git diff master[取り込むほう] develop[取り込まれるほう]

 

ブランチ間の差分があるファイル一覧を表示

$ git diff master[取り込むほう] develop[取り込まれるほう] --name-status

 

ブランチ間の差分があるファイル数を表示

$ git diff master[取り込むほう] develop[取り込まれるほう] --name-status | wc -l

 

 

git stashってadd(インデックス)してないと意味ないんだ!

 

タイトルの通りです。

 

Gitが苦手なもので、とりあえず、stashしちゃうんです。

んで、必要な時にstash popしてます。便利ですよね〜\(^^)/

 

超便利と感じつつ、stashをどんどん貯めていくのですが、

結局、使わず、溜まってくばかりなのですが。

 

そんな GIT stash に関して
私は大きな勘違いをしていることに昨日気がつかされました!

 

git stashってインデックスにあるもの(git addしたやつ)をstashします。

作業ツリーのものはstashしてないのです!

 

 

「だからたまに、"stashしたはずなのに、あのファイルがない!"とかなってたんだ・・・。」

 

 

作業ツリーからインデックス(git add)にあがることにより、

追跡(tracking)が開始されるのです。

よって、git addしなければ、バージョン管理外なのです!

 

##まとめ##

作業ツリーがダーティ(クリーンではない状態)の時は、

stashしたいものをaddして追跡を開始させたのちに、

git stashを実行すること!