エンジニアのひよこ_level10

【毎日更新!】新卒3年目エンジニアブログです!

このブログは? 毎日更新エンジニアブログです【更新:2018/09/12】

このブログは?

毎日新卒3年目が学んだことを記事にしているブログです。
ターゲットを広めに、簡単な記事を書いていることが多いです。

あなたは?

  • 新卒3年目のエンジニア
  • 新卒2年目でLaravelにコントリビュート。
  • 新卒2年目でLaravelJPConference2018に30分トークで登壇
  • 趣味はVROculus Rift等。

使用技術

Docker,HTML,CSS,JavaScript,PHP等々...

こいつ面白いな?

そう思ったら、渋谷で良ければランチでもいかがですか!
twitterかメールで連絡していただければ、いつでも歓迎です!(メアドはgithub参照)

klack710 (Masaki Obata) · GitHub

https://twitter.com/nyamucoro

おすすめ記事

willow710kut.hatenablog.com

willow710kut.hatenablog.com

【思考メモ】他者の肯定は、その人の『今』『過去』どちらを肯定してるか意識する【644日目】

悩み相談をした

私の性格上、他の人に悩み相談をされた時、相手の行動を間違っていると言うことはすっごく少ないです。

でも、相手に否定されたと思わせることはたくさんあります。それはなにか

過去の行動を悔やむ人に対して

例えばあなたが、『一年前の私は酷かった。こんなことしちゃってさ』って語ってくれたとします。
そこに私が、『そんなことないよ!過去の君はこうだったから、仕方なかったんだよ!』って言ったとします。

これ、『相手を否定した』とも取れます。

過去を悔やんだ人が、内心でもしょうがないと思ってたり、しょうがないと言われたかった場合には、良いです。本心の方を肯定していますから。
しかし、『本気で最低だと思っていた』『今の私からみて、酷かったと思う』って思っていた場合は?
『過去の相手』を否定して、加えて『今の相手の考え』を否定したことになります。

『そんなことないよ!』という言葉を使ったように、すでに相手の考えを『否定』しているのです。

どうすればいいの?

一旦確実なことが言えるのは、『相手の言ったことすべてを肯定すること』は単純な話ではないです。

言った言葉すべてを肯定する、でも相手の心を否定する場合もあります。

だから、シンプルに銀の弾丸があるわけではないです。

とはいえ、何も対策打てないのか

『そんなことないよ!』って言葉、すでにどこかに対して『否定』を投げています。

否定を投げる言葉を使った時、一回自分は何を肯定したいんだっけ?なんでこの言葉を投げようとしたんだっけ?
って考えるのは一つの手です。

・・・まあ、それも単純な話ではありませんが。

今回の記事を通して考えるべきことは、『私あなたを肯定しまくったじゃん!』なんて考えたときには、一旦自分の思考にブレーキをかけてみましょうってお話でした。

【正規表現】任意の同じ文字を指定して、該当文字を抽出する【643日目】

正規表現で、『同じ文字』を表現したい

aaaaa@nyamucoro.com

この、@より前がすべて同じ文字なのを検証したい

加えて、同じ文字だった文字の部分だけ取りたい。

この場合、 aaaaaの部分

\1でかっこの値を判定でも用いる

www.nyamucoro.com

preg_match('/^(.)\1+@/', $value, $matches);

これだと、 aaaaa@って文字が入る

かっこを付け足す

preg_match('/^((.)\2+)@/', $value, $matches);

((.)\2+)のかっこの部分で aaaaaの部分を取得出来る

外側のかっこが最初に出現したので、内側のかっこの値がずれたので、 \1は\2に変わっています。

【正規表現】任意の同じ文字を指定する。【642日目】

正規表現で、『同じ文字』を表現したい

aaaaa@nyamucoro.com

この、@より前がすべて同じ文字なのを検証したい

\1でかっこの値を判定でも用いる

preg_match('/^(.)\1+@/', $value, $matches);

'(.)\1+'解説

\1と書くと、かっこの値を指定することが出来る。右の数値は、かっこが出現した時の順番の値。

  1. (.)で、任意の一文字
  2. \1で、その直前の(.)自身。( (.)がaなら\1もa)
  3. \1+で、2.の任意の個数指定

aaaaa@nyamucoro.comなら、

  1. aaaaaの最初のaが (.)でマッチする。
  2. aaaaaの二番目のaが、 \1でマッチする。
  3. aaaaaの二番目以降は、 \1+でマッチする。

【イベント紹介】Laravel.shibuya #3は来週火曜!(そしてスタッフします!)【642日目】

Laravel.shibuya?

laravel-shibuya.connpass.com

このイベントです。

IRT(Interactive Round Table)をメインとした勉強会です!

IRT?

机を囲ってみんなでトピックについてお話するよ。

集まってLaravelやPHPについておしゃべりが出来る会ですね!

スタッフ?

Laravel Beginner IRTの枠で、司会進行をいたします。

ビギナー枠なので、気軽にどうぞ!

これからLaravel使いたいけど、何から始めたらいい?
雰囲気でLaravel書いてるけど、脱Beginnerするにはどうしたらいい?
Laravelより普通のPHP書けってよく言われるけどなんで?
Laravelの開発環境構築は何がおすすめなのか?

とかとか、こんな初歩的だったり、具体的な質問じゃないけど迷ってる!みたいなのを、
みんなで『気軽に』『楽しく』話せる場にしたいなって思ってます!!!

あれ?枠埋まってない?

おや?

参加枠が埋まっている?

いや、『初心者枠』が空いてますね?私の司会は初心者用のテーブルですね?

いやいや、『ブログ枠』が空いてますね?参加費が無料になる?アウトプットしてしかもタダ飯が食える?

これは、申し込むしかないですね(‘ω‘ )!

懇親会もありますし、初心者枠でもブログ枠でも困ったら、私に声かければいいので!
お気軽に参加ボタンをポチってしましょ!

ハジメマシテ!』でも大歓迎ですし、さあ、Laravelで悩みがあったりおしゃべりしたい方、ららしぶで僕と握手!

読みやすいプログラムを書くために。データの再利用vs再取得【641日目】

学んだこと

データをしぼりこむのではなく、永続化されたデータを絞り込んだ状態で再取得するのも手

データの再利用vs再取得

// 全てのusersを使う処理
$users = User::get();
$this->xxx_func($users);

// 条件に合ったユーザーを、さっきのデータから絞り込み
$type_beginner_users = $user->whereIn('user_type_id', UserType::BEGINNER);
if (!$type_beginner_users->empty()) {
    $this->yyy_func($type_beginner_users);
}
// 全てのusersを使う処理
$users = User::get();
$this->xxx_func($users);

// 条件に合ったユーザーをクエリで再取得
$type_beginner_users = User::whereIn('user_type_id', UserType::BEGINNER)->get();
if (!$type_beginner_users->empty()) {
    $this->yyy_func($type_beginner_users);
}

このように、データを再利用するものと、クエリで再取得するもの。2つの書き方も考えられる。

本質はどこか?

xxx_funcとyyy_funcは、本質は同じデータを取り扱いたい場合は、データの再利用のほうがいい。

xxx_funcを行っている間にデータが書き換わったら、バグが起こる可能性がある。
加えて、クエリを再発行するので、通信が発生して処理がより重くなる可能性もある。

xxx_funcでデータが変わっているが、その変わったあとの状態がほしい。
yyy_funcを起こした瞬間のDBの状態が重要であれば、クエリを再発行する方を選ぶ必要がある。

逆にデータが変わっているはずなのに変わってない・・・となる。

読みやすいプログラムって?

結局は、データの扱いの本質がどこにあるかが重要なので、一発でこれが正しいとは言えないφ(・

だけど、本質を正しく伝えるのが大切なので、後者の本質が正しいのに前者で書くのは、
バグも起こるかもしれないし、あとから読んだ人が『このプログラムがやりたいこと』を『勘違い』する可能性があります。

最後に。

『正しい意味』を『素早くわかりやすく理解する』のが本当の意味での『読みやすいプログラム』。

『ぱっと見キレイ』だけど『勘違いさせやすい』のは、読みやすいプログラムではないと思います。

読みやすいプログラムはなにかをもう一度自分で見直してみると、面白い発見があるかもしれません。
ということで、今回数日間連載していた『読みやすいプログラムを書くために』を締めくくりたいと思います。

ここまで読んでくださった方、ありがとうございました。

読みやすいプログラムを書くために。判定用の数値は判定の時に算出する【640日目】

学んだこと

$has_という変数名をつけず、データの取得と、countなどの判定とで処理を二段階に分けるのも手

has_xxxのような変数を作っていた

$has_user_item = !($items->where('item_type', 'user')->empty());

if (!$has_user_item) {

このように、if文内で変数一つで扱えるよう、判定用の変数を用意していた。

判定用の数値は判定の時に算出する

$user_items = $items->where('item_type', 'user');

// 判定用の数値に変える
if (!($user_item->empty())) {

}

このように書くことも出来る。ただ、一長一短ある。

どちらがより再利用されるプログラムか。

注)これに正解はなく、ケースバイケースです。

$has_user_item = !($items->where('item_type', 'user')->empty());

if (!$has_user_item) {
     xxx_func($has_user_item);
}

このように、判定結果を引数等で他の場面で使いたい場合もあるかもしれない。先程のように分割すると

$user_items = $items->where('item_type', 'user');

// 判定用の数値に変える
if (!($user_item->empty())) {
     xxx_func($user_item->empty());
}

こんなコードになったりするので、一気にまた見にくくなり、メンテナンスも面倒。なのでケースバイケース。

おまけ

ちなみに、メモリにどれくらい使うか・・・みたいな話があるが、それは考えるべきプログラムなのか?私達はそこまで切り詰めたサーバーなのか?って考えると、
一旦考えなくても良い現場が多いだろう。

【一週間振り返り】相談乗ったり、次にやること増やしてた一週間【639日目】

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

相談聞いたり、次にやること増やしてた一週間。

2.良かったこと

  1. ぺちこん北海道CfP通った
  2. めっちゃ息抜きした
  3. 誕生日(7/10)です!って言ったらめっちゃいろいろ送ってもらえて感動だった
  4. スマホ変えました(Pixel3)
  5. Laravel.shibuyaのスタッフやります
  6. メンター練習の機会が増えそうな予感?

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

無限LT次の企画進めたい

北海道のホテルと飛行機早く予約しないといけない

運動サボってる(´;ω;`)

4.新しく気づいたこと

めっちゃ友人に癒やされて、結構元気出た。

最近やる気が出ないよなーって思ってたの、精神の充電が切れていたのかもしれない。

5.来週したいこと

無限LTの企画進める。

北海道のホテルと飛行機早く予約。

体調崩す以外では運動必ずする。

6.その他

他にも誕生日の人いたのでお祝いぶん投げてました。

さて、北海道の飛行機予約、今からでもなんとかなるだろうか・・・

7.体重

101.2kg

変わらないΣ(・∀・;)

読みやすいプログラムを書くために。否定の否定を書かない【638日目】

学んだこと

if (! $has_no_ )って否定の否定のコードは、正しく解釈するのが難しくなる

否定の否定

$has_no_items = .....

// ない場合
if ($has_no_items) {
 ....
}

// ある場合
if (!$has_no_items) {
 ....
}

言うまでもなく見づらい

変数名を変える

$has_items = .....

// ない場合
if (!$has_items) {
 ....
}

// ある場合
if (!$has_items) {
 ....
}

これで少し見やすくなる

変数に入れ直す

$has_items = .....
$has_no_items = !$has_items;

// ない場合
if ($has_no_items) {
 ....
}

// ある場合
if ($has_items) {
 ....
}

ただ、こちらは一度処理を先にする。

直感で$has_itemsの変数との関係が見づらくなる可能性もあるので、要検討。
$has_no_itemsの算出方法が変わると、バグの危険もあるので、扱い注意。