【Vue】Vueの勉強を始めようpart0(環境構築編)【519日目】

さあ勉強を始めよう

さて、勉強を始めるにあたって、環境構築ですね。

ってことで、Dockerで一から環境構築を・・・

ってのは面倒なので。

以前Laravel用に作ったdockerの環境を流用しちゃいましょう。

使ったリポジトリ

github.com

あまり整備していませんが、使いたい方は使って大丈夫ですよ！友人も使ってくれてるので動作問題ないはず。

.oO(使うときにStarとか置いてくれたら嬉しいな。使い方わからなかったらtwitterとかで聞いてください)

やったこと

1. 対象のリポジトリをclone
2. study-laravelって名前でコンテナ名やプロジェクト名を作ってたので、いろんなファイルの名前を変える
3. app/public にindex.htmlでHello Worldを書く
4. docker-compose up
5. localhost:8000にアクセス

おしまい。

勉強中のリポジトリ

ここで公開

github.com

公開動作環境

github pagesで、静的な動作環境を表示。

これで一応今どんな状態かみんなも進捗見れるはず。

https://klack710.github.io/study-vue/public/

言えること

こうやって、自分の環境構築の成果や手順は残しておくのおすすめ。

この環境構築は10分で終わったので・・・！

さて、これでひとまずhtmlとphpの環境はできました！ワクワクですね！

Vue.jsの勉強始めました。【518日目】

Vueの勉強始めました

Laravelの勉強していたんですが、私、フロントエンドは生のJavaScript、jQueryで書いてました・・・

TypeScriptやなにかフロントエンドのJSフレームワーク覚えたいな・・・ってことで、選ばれたのはVue.jsでした。

なんでVue?

JavaScriptのフレームワークはいくつかあります。
AngularやReactとかもあります。

それでもVueを選んだのは、

1. 知見のある人が近くにいる
2. 学習コストが低い(と言われている)
3. 公式のドキュメント・動画とか豊富
4. Starが一番多い
5. JavaScriptにHTMLが混ざってるの初見で吐き気が(ry

1.が一番大きいですね。一つ学べば、他を学ぶハードルを下げる要因になると思って選びました。

使った本

Vue経験者におすすめされた本。これを今読んでいます。

これからの計画

ひとまず本を読み進めつつ、練習。

今の所、今月に本を読み終わるのが目標。
3月末ってことで、そこそこ忙しいので・・・

初心者エンジニアのSlackの集いで、勉強始めたよ報告しながらがんばります(‘ω‘ )！
あ、一応宣伝、招待URLですー

Create Account | Slack

【アフィリエイト】Amazonアソシエイトを使ってみる【517日目】

友人がアフィリエイトしていた

友人がアフィリエイトブログを始めたそうです。

アフィリエイト、それだけ聞くといいイメージないですよね・・・ｗ

ただ、使ってみるまでわからないよなーってことで、勉強がてら使ってみることにしました。

対象記事

【Docker】phpでPDOにmysqlを使うと、could not find driverと出る【186日目】 - エンジニアのひよこ_level10

php7.2でmcryptがインストールできない問題【124日目】 - エンジニアのひよこ_level10

docker exec -itって実際は何をしてるの？【90日目】 - エンジニアのひよこ_level10

見づらくない？

ほら、記事の質落としたいわけじゃないので、なんとなくおまけに付ける感じです。

そういや、久々に記事をリライト。docker execの記事少し見やすくなったかも？

どうやってやったの？

Amazonアソシエイトの登録の仕方は略。

1.登録する
2.売る商品を検索する
3.リンク作成をクリック

4.カスタマイズして、画面下のHTMLを貼り付け

これでOK。

やってみた感想は？

紹介文うさんくせえええええ

こういうの書くの苦手ー誰かリライトしてー

でも、この本はマジでおすすめなの。
この本薄いのに、この本だけでメンバー内でDockerちょっとわかるまんになれたの。

ってことで、気になる方はポチるのおすすめしますー

最後に:使った文章

■対象の人:環境構築わからない・・・インフラ用語わからない・・・

プログラム書けるけど、インフラ用語わからない、環境構築してみたいけどできない。

私がそうでしたが、以下の本で勉強しました。

インフラの用語を一から説明してくれて、その後にDockerの話をしてくれるので初心者向けです。
Laravelの環境くらいなら、一人で書けるようになりました。

アフィリエイトリンク貼ると、胡散臭くなるけど、単純におすすめしたい本(｀･ω･´)ゞ

【Git】`git stash -u`に対しても、メッセージをつけたい【516日目】

git stashって？

www.nyamucoro.com

git stash -u "メッセージ"では動かない

git stash メッセージでコメント残せるんだ。

なら、 git stash -u メッセージ・・・あれ？動かない？

-mをつける

git stash -u -mメッセージ

このとき、-mのあとにスペースを入れてはいけないやつ。

saveを省略しないバージョン

git stash save -u -mメッセージ

こっちも、おっけー。

ちなみに、 git stash saveのsaveの部分を略しながら、オプションをつけられるかは、
Gitのバージョンによるので、コマンドが上手く動かなかったら、
saveを略さない上のコマンドを試してみてください！

【Git】git stash save -uで、作業内容を一時保存する【515日目】

作業中に、別な作業をしたい

プログラミングで、今やってるコーディングを途中で止めて、
他のコーディングをしたいって時ありませんか？

Aの作業中に、今のコーディング止めて、先にBやって！

ってやつです。

そんな時、Aを全部消すのもったいないですよね。
だからといっても、commitするのも・・・

では、それを別な場所に一時保存しましょう。

git stash save

git stash save(gitのバージョンによっては、saveを省略出来ます)

こちらで、今の作業中の変更を、一時保存出来ます。

この時、新規ファイルなどの untracked filesは保存出来ないのですが、
git stash save -uで untracked filesも一時保存出来ます。

もとに戻す時は？

git stash pop

これで、元に戻せます。

作業Bが終わったら、作業Aを途中から再開できる便利な方法です。

別なブランチにも移動できる？

ちなみに、 stash saveで保存した内容は、ブランチを移動しても、移動先で stash pop出来ます。

例えば、 masterや developブランチで作業して、上手く行ったら、 git stash save -u

その後、新しいブランチを作るなり、別なブランチに移動してから、 git stash pop

これで、変更内容の移動が出来ます。
たまに便利。

【SQL】インデント等使いこなして、SQLを見やすくしてみよう！【514日目】

SQLって見にくいこと多いですよね

よく、自分や他の人のSQL文を見直すのですが、まーーーーあ見にくい。

ってことで、見やすいSQL文ってどんなのだろう？

友人2人と一緒に私のSQL文をリファクタリングしてみました！

元コード

 SELECT
 DISTINCT
  rankings.*,
  CASE
   WHEN user_types.id = 3 THEN 5
   WHEN user_types.id = 2
    OR user_types.id = 5
    OR user_types.id = 6 THEN 6
   WHEN user_types.id = 1
    OR user_types.id = 4
    OR user_types.id = 7 THEN 7
   WHEN user_types.id = 8 THEN 8
   ELSE 0
  END AS ranking_type_id
 FROM `db`.rankings
 RIGHT JOIN `db`.user_types ON rankings.user_id = user_types.id
 WHERE rankings_term_id = 8
 ORDER BY rankings.group_id, ranking_type_id, rankings.rank;

うおっ、詰まってる。
ただ、最低限の改行を使ってるだけまだマシ・・・？

~~句と式に改行を入れる

友人Z君の改変

SELECT
    DISTINCT rankings.*,
    CASE
        WHEN 
            user_types.id = 3
        THEN 5
        WHEN
            user_types.id = 2 OR user_types.id = 5 OR user_types.id = 6
        THEN 6
        WHEN
            user_types.id = 1 OR user_types.id = 4 OR user_types.id = 7
        THEN 7
        WHEN 
            user_types.id = 8
        THEN 8
        ELSE 0
    END AS ranking_type_id
FROM
    `db`.rankings
RIGHT JOIN
    `db`.user_types
ON
    rankings.user_id = user_types.id
WHERE
    rankings_term_id = 8
ORDER BY 
    rankings.group_id,
    ranking_type_id,
    rankings.rank
;

おおおお！！！

長くなりましたがいい感じですね。

極力SQLの~~句と式を同列に書かないようにしているようです。

WHERE rankings_term_id = 8

WHERE
    rankings_term_id = 8

見やすさ段違いですね！

さらにZ君ひと手間。

変数を扱う

MySQLの特性ですが

SET @aId = 5, @bId = 6, @cId = 7, @dId = 8, @eId = 0;

SELECT
    DISTINCT rankings.*,
    CASE
        WHEN 
            user_types.id = 3
        THEN @aId
        WHEN
            user_types.id = 2 OR user_types.id = 5 OR user_types.id = 6
        THEN @bId
        WHEN
            user_types.id = 1 OR user_types.id = 4 OR user_types.id = 7
        THEN @cId
        WHEN 
            user_types.id = 8
        THEN @dId
        ELSE @eId
    END AS ranking_type_id

いい感じ。ここには用途は書いてないですが、実務では、変数に意味のある言葉をつければ、
より可読性が増しますね！

すると、友人O君がぼそっと・・・

ORじゃなくてIN句使う

SET @aId = 5, @bId = 6, @cId = 7, @dId = 8, @eId = 0;

SELECT
    DISTINCT rankings.*,
    CASE
        WHEN 
            user_types.id = 3
        THEN @aId
        WHEN
            user_types.id in (2, 5, 6)
        THEN @bId
        WHEN
            user_types.id in (1, 4, 7)
        THEN @cId
        WHEN 
            user_types.id = 8
        THEN @dId
        ELSE @eId
    END AS ranking_type_id
FROM
    `db`.rankings
RIGHT JOIN
    `db`.user_types
  ON
    rankings.user_id = user_types.id
WHERE
    rankings_term_id = 8
ORDER BY 
    rankings.group_id,
    ranking_type_id,
    rankings.rank
;

たしかに！！！
WHENの中にIN使う発想がなかった。

こういう、同一内容のORがあったら、IN疑うのは良いことですね！

最後に、全体を整えるー

最終型

SET @aId = 5, @bId = 6, @cId = 7, @dId = 8, @eId = 0;

SELECT DISTINCT
    rankings.*,
    CASE
        WHEN 
            user_types.id = 3
        THEN @aId
        WHEN
            user_types.id IN (2, 5, 6)
        THEN @bId
        WHEN
            user_types.id IN (1, 4, 7)
        THEN @cId
        WHEN 
            user_types.id = 8
        THEN @dId
        ELSE @eId
    END AS ranking_type_id
FROM
    `db`.rankings
RIGHT JOIN
    `db`.user_types
  ON
    rankings.user_id = user_types.id
WHERE
    rankings_term_id = 8
ORDER BY 
    rankings.group_id,
    ranking_type_id,
    rankings.rank
;

DISTINCTはSELECTのオプション、全体にかかっているので位置を移動。
INを大文字に

最初と比べても、印象はかなり変わったのではないでしょうか？

改行、インデントだけでなく、句の使い方にも工夫がありましたね。

こういう細かなテクニックの積み重ねで、キレイなコードは生まれると思います！
たまに自身のコードを、複数人で見直してみてはいかがでしょうか(‘ω‘ )！

【一週間振り返り】風邪治しつつ仕事＋新しい生活基盤作る一週間【513日目】

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

風邪引きながらも仕事やりきれたよ(治った。移してない)+新生活にあたってリズム変えてみたよ！

2.良かったこと

1.ちょくちょく休みながらもお仕事やりきれた(会社の皆さんありがとうございます)

2.在宅のおかげで感染広がらず？

3.水飲む、寝る場所変える、朝起きたら洗濯とかサイクルを作る

4.エアロバイク再開してみた

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

プログラミングの勉強のサイクルはまだ作れてない。

あと、昨日の記事である、自分に対する自己肯定感低過ぎからちょっと失敗一つ。

4.新しく気づいたこと

やらかしても、こっそり間違い教えてくださる環境に感謝。

本を書きましたとか言えるくらい、そんなアバウトで下心満々な理由でいいから
目標を持つと勉強頑張れそう。

5.来週したいこと

書類用意とかせねばあああ

あと、勉強に対する習慣をどこかで用意したい。

6. エアロバイク(一週間分)

36km

6.その他

エアロバイクを毎日書いてたけど、通常の記事に書くのが嫌だから続かなかった。

なら、一週間振り返りに書けばいいのではってことで書いてみる。続くかな？

あと久しぶりの腹筋ローラーマジ腹筋痛い。

【PHP】returnを返さなかったときはどうなる？voidじゃない？【512日目】

こんなプログラムがあったとき

public function foo($key, $array)
{
    if($key != null) {
        return $array[$key];
    }
}

このプログラム、もし$keyがnullだったとき、returnを通らないです。どうなるでしょう。

return nullされる

http://php.net/manual/ja/functions.returning-values.php

return を省略した場合は NULL を返します。

ということで、return nullされます。
すると、きっと2つ程疑問が出ると思います。

voidじゃないの？

PHP: 新機能 - Manual

返り値の型として void が導入されました。返り値の型を void と宣言した関数は、関数内での return 文を省略するか、あるいは空の return を使う必要があります。 void 関数から NULL を返すことはできません。

void 関数の返り値を使おうとした場合はその値は NULL と評価されます。 警告は発生しません。警告を発生させると、一般的な高階関数の利用にも影響するからです。

ざっくりいうと、

『voidという値は存在しなくて、voidとは意味のない値を指す』
『意味のない値なので、returnがvoidのときは、そのreturn値を使うことはできない』

return nullは明記しなきゃいけないの？

public function foo($key, $array)
{
    if($key != null) {
        return $array[$key];
    }
    return null;
}

こう書かなければいけないというのは、PSRなどで決められていません。
但し、極力明記するべきだと思います。

可読性も上がりますし、そもそもコードで検討忘れだったりするかもしれません。
明記することで、関数に対する意味などと正しく定義しやすくなります。

あるいは、以下のように書き換えることもできます。

public function foo($key, $array)
{
    if($key == null) {
        return null;
    }
    return $array[$key];
}

極力、他の人のためにも、明記するほうが良いでしょう。