【docker】docker-compose.ymlのvolumesって何してるの？【304日目】

どういう意味？

手元のOSのディレクトリをコンテナの中のディレクトリにマウントする

マウント？

イメージとしては、コンテナの該当ディレクトリは、
手元のOSのディレクトリを使うよ。

具体的な例だと、手元のOSのディレクトリでファイルを新しく作ると、
コンテナの中でもファイルが出来上がるよ。

例

手元のOSで./webにtest.htmlを作ると、コンテナ内の/var/www/webにも、test.htmlが作られる。

    volumes:
      - ./web:/var/www/web

何が嬉しいの(php)

例えば、phpのコンテナでこれをすると、
手元で./webにプログラムを書いた時に、コンテナに自動反映される。

普通なら、 docker buildで何度もコンテナ作り直す必要があるので便利。

何が嬉しいの(mysql)

データの永続化。

普段、コンテナを落とすと、コンテナの中のデータは一から作り直しになってしまう。
でも、手元のデータをマウントしているなら、コンテナを立ち上げる度にデータが消えません。

ただ、手元のOSの該当ディレクトリを消したら、当然なくなります！

docker-composeの例

github.com

【一週間振り返り】焦りと後悔の一週間でした【303日目】

1.今週一週間の感想(ざっくり)

失敗したと焦り、一人でなにかしなきゃと焦ってた一週間でした。

2.良かったこと

Laravelの開発環境作り直し
　　→知識の整理ができてよかった

焦り・後悔したけど、復帰した
　　→一度チームに自分は何をするのか考える機会できてよかった

3.もっとこうしたかったこと

プログラミングの時間作りたかった。

焦ったあと、ちゃんと焦ってるのを相談するべきだった。
成果を求めてくる敵じゃなくて、ちゃんと一緒に考えれるチームの味方と思って、正直に相談するべきだった。

眠気・朝起きれないっていうのは大問題。

4.新しく気づいたこと

今、私が頑張るべきことが何かが『わかっていないことがわかった』

正直、今も混乱しているので、考え直す。

・・・あと、プログラムただ書いてるだけが楽なのもわかった。
でも、今苦手なのを経験しておきたいという気持ちは確か。

5.来週したいこと

Laravelでチュートリアル2つ進める。

気持ちと行動の整理。
あと、相手の考えを思い込みで進めない。

6.その他

正直、過去の先輩がうまく行ってるのを、私が半分仕事を引き継いだ途端に崩壊したって思って焦っています。
崩壊するのは当然だと考えるのもできるけど、引き継ぎをお願いした人からしたりそうじゃない可能性もあるので、
ちゃんと振り返る。

イミュータブルパターンの使い所【302日目】

イミュータブルであるとは

イミュータブルであるとは、変更が不能であるということ。

変更してはいけない値とは何か。

それは事実。

事実とは？

お店でものを買った。
Webサイトでものを買った。

銀行でお金を引き出した。
Webサイトで入金した。

こういった事実です。

これをイミュータブルにしなければ？

これらの値を変数やオブジェクトに入れる。

この時に、もしイミュータブルじゃなかったら？

銀行の入金システムで、うっかり値を変更しちゃった。
となると、事実が変わってしまう。

思わぬバグが生まれるかもしれないですし、
そもそも、値がそうあるべきではない。
なので、イミュータブルであるべき。

どうしても変えたいときは？

でも、銀行の入金を取りやめとかする時には？

入金した事実はそのままに、『入金を取り消した』という事実を
追加で入れるべき。

イミュータブルかどうかは重要

データをイミュータブルにするかは、データのあり方として重要ですし、 銀行とかのシステムなら、データの保証が揺るぐことも起きるので、
設計の段階でも、値がイミュータブルであるべきかをちゃんと考えましょう。

イミュータブルパターン自作した時の記事

willow710kut.hatenablog.com

willow710kut.hatenablog.com

【bash】過去に打ち込んだコマンド一覧を見て、実行コマンドを選ぶ【301日目】

こんなとき

ターミナル使って、コマンドをいろいろ打った。

でも、結構前に打ったコマンドなんだったか思い出せない。

historyコマンド

これで、過去に打ち込んだコマンド一覧が見れる。

さて、これでコマンドをコピペして、コマンドを打つ・・・のは面倒ですね

!xxx

!123のように、historyで出てきたコマンドの左の数値に、!をつけて実行すると、
コマンドが簡単に実行できます。

いっつも上下キーでコマンドの履歴を見て探してたので、こっちのほうが便利。楽ちんですね。

小さな工夫を繰り返して、時間の節約をしていきましょう。

【Laravel】Laravelのプロジェクトをcloneしたけど動かない時【300日目】

こんなことありませんか

新しくLaravelのプロジェクトをgit cloneしてきたよ！

えっと、localhost:8000に行けばいいんですね！

・・・あれ？動かないんですが。

エラー例

whoops looks like something went wrong.

Warning: require(xxxx/vendor/autoload.php): failed to open stream: No such file or directory

No application encryption key has been specified.

Woops~

そのそも、エラーが表示されていないです。
本番環境でエラーが表示されたら、ユーザー困惑なので当然ですよね。

開発環境だけでですが、

config/app.php

'debug' => env('APP_DEBUG', false),

に変えてもう一度アクセスしてみれば、エラーがわかります。
エラーがわかったら、下のエラーがないか確かめましょう。

Warning~

composer install

ファイルが足りてないです。
vender配下のファイルは、外部の方が提供しているライブラリなので、composer installでダウンロードしましょう。

No application~

cloneしてすぐなら、.envファイルが足りてない可能性が高いです。

.envは環境の設定ファイルで、基本はgitで管理しないので、このプロジェクト作った人に、
『.envちょーだい！』
って言いましょう。それをlaravelのプロジェクト配下に入れればOKです。

【git】データベースの中身は、gitで管理しないべき【299日目】

良くない例

laravelのスタートページ表示 by klack710 · Pull Request #1 · klack710/study-laravel · GitHub

自作のLaravelの基本の開発環境です。
これの良くないところはどこでしょうか。

mysqlのコンテナの中身全部入ってる

mysql配下の中身、これはmysqlのデータとかが全部入っちゃってます。

これは良くないですね。

え、なぜ悪いか？

重い

gitでプッシュする、プルする時に、ユーザーの入力全部送ったりしてしまいます。

もし、手元で仮の入力とかしたら、それもコミットの中身に入っちゃいますね。

そもそもソースコードの本質ではない

また、このプロジェクト、このコードの本質には、データベースの中身は関係ないはずです。

ユーザーAの会員登録情報が、このプロジェクトの中身の本質か？そんなの関係ないはずです。

でも、新しくテーブル作った時とか、初期データ空っぽ？

開発で、テーブルを新しく作った時とかあると思います。

その時に、初期データどうするか。

これに関しては、何が本質かを見てみましょう。

ユーザーの区分など→マイグレーションファイル

Usersテーブルに、Rolesテーブル。

Usersテーブルは会員情報、Rolesテーブルは、会員における区分を司るとします。
ここに、role_idカラムを追加する。

このRolesテーブルに、adminやclient、userなどの区分を保存する時。
これは変化しない値で、ユーザーの性質を扱うものなので、マイグレーションファイルで初期値として入れればいい。

ユーザーの情報→シード

そもそもユーザー情報がなかったら、
開発するたびに会員登録して、そしてユーザー作って開発するのか。

そうはならないと思います。

そういう時は、データのバックアップをとって、seed値として取っておきましょう。
実際のデータ、あるいは実際に開発できる最低限のデータをseed値として用意して、
開発環境を構築するときに、そのデータでデータベースを作りましょう。

gitで管理するものは、プロジェクトの本質だけを残すべき

ソースコードには、そのプロジェクトにおける本質となるものだけ入れましょう。

エディターによって生成されるファイル、Macだから生成されるファイルとかは、含めないように。
そして、今回のデータベースの情報も、含めないべき情報です。

そういうファイルやフォルダは、 .gitignoreに記述してコミットに含めないように気をつけましょう。

【MySQL】GROUPBYでまとめた後、countの重複を取り除く【298日目】

こんなときにつかう

select 'count(id)' FROM 'users' GROUP BY 'group_id';

GROUP BYではgroup_idでまとめているが、idの方で重複がある場合。
この時、 idが[1,2,3,4,4,5]だった場合、 count(id)の値は6になる。

idの4が重複しているので、合計を5にしたい時

こうする

select 'count(DISTINCT id)' FROM 'users' GROUP BY 'group_id';

countする前のidの重複を防いだ後に、countをすることができる。

(応用)片方を重複削除して、もう片方を重複削除したくない時

select 'count(id), count(DISTINCT name)' FROM 'users' GROUP BY 'group_id';

これで、nameは重複削除してcountするが、idは重複削除せずにcountすることができる。

【思考メモ】メモには種類が2つある。使い分けよう。【297日目】

メモ書きには二種類ある

長期用メモと短期メモもとい揮発性メモを使い分ける。

ブログや研究ノートは長期用。
裏紙やホワイトボードメモは揮発性メモ。

どう使い分けるの？長期メモは？

長期用メモは、私のようなブログであったり、
研究ノートなど、あとで読み返せる形のもの。

良い点は、忘れにくくなる。あとで読み返せる。
悪い点は、あとで読み返せてしまう。

後で読みかえせると思うと、半端なことは書いてはいけないと、
心がセーブをかけてしまう。
なので、とにかく思考を吐き出したい時には、次の揮発性メモを使うといい。

揮発性メモ

揮発性メモは、裏紙であったり、ホワイトボードなど、
簡単に消せて、簡単に捨てれるもの。

良い点は、記録が残るという不安を消すことができる。
悪い点は、捨てる。短期的なもの。

思考整理に揮発性メモを使うと良い。
書く時は、とにかく思いついたことを書く。

どうせ記録に残らないなら、
なぜ脳内で完結させずにアウトプットするのか。
誰にも見られないのに。

それは脳内→メモ→自分への再インプットのサイクルを行えるから。 これにより、客観視のフェーズを組み込むことができる。

また、人は脳内で同時に考えるのはそんな得意じゃないので、
一度メモに書いて、それを一旦忘れて、次の内容に集中しやすくする。

思考元

ゼロ秒思考という本を呼んで、私のメモの書き方は二種類あるなと思って書きました。
ゼロ秒思考、なかなかいい本なのでおすすめ。

おまけ

ちなみに、ノートに書いているからと言って、長期用メモになっているとは限らないです。

大学の講義でノートに書くけど、覚えてないものがあると思います。
それは、とにかく書くことに意識をしているので、実質揮発性メモと同じとり方をしているからです。

長期用メモは、あとで必ず読み返すか、読み返すことを想定して書きましょう。