エンジニアのひよこ_level10

毎日更新してた人。たまに記事書きます。

【デザパタ勉強】テンプレートメソッドパターンの嬉しいところ【353日目】

コード

template-method by klack710 · Pull Request #6 · klack710/study-design_pattern · GitHub

使う側

public class Main {
    public static void main(String args[])
    {
        ConcreteDotPrint cdp = new ConcreteDotPrint();
        ConcreteLinePrint clp = new ConcreteLinePrint();
        cdp.templatePrint("dot");
        clp.templatePrint("line");
    }
}

結果

...
dot
...
---
line
---

どゆこと?

public abstract class AbstractPrint {
    public abstract void firstLine();
    public abstract void print(String str);
    public abstract void lastLine();

     // 基本の動作をここで記述
    public void templatePrint(String str) {
        this.firstLine();
        this.print(str);
        this.lastLine();
    }
} 

templatePrintの中に、基本動作がある。

この基本動作に含まれている、firstLineとかをオーバーライドして実装する。

何が嬉しいの?

firstLineみたいなパーツをオーバーライドで実装できる。

これは、似た動作をするものをどんどんたくさん作れる。AbstractPrintを継承したら、ドットやライン以外にも、
いろんな枠が作れる。テンプレートが作れる。

おかしな部分を見つけたら、簡単に治せる。各パーツ毎におかしな動きを見つけたら、
すぐにそこを直せばいいって気がつける。

簡単、汎用性が高いので、身近でも結構使われているかも?

【一週間振り返り】新しい挑戦の種まきが出来た一週間【352日目】

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

新しい挑戦の種まきが出来た一週間でした。

2.良かったこと

  1. PHPカンファレンスに登壇の申請しました

  2. 自分の考え方が変わってきたのを結構気がつけてきました

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

プログラミング系、あまり頑張れてなかった・・・

ただ、自分の今の思考に気がつけたのは良かったこと?

4.新しく気づいたこと

1.プログラミングより、マネジメント方面に興味が向いてきた?
 →新しい技術を学ぶ機会より、今のチームうまく回すことの方が興味が強いみたい

2.難しいことをやることと、凄いと言われることをやることは必ずしも一致しない
 →小さな努力で、多数の人を助けたら、それは凄いことだよね

5.来週したいこと

  1. 登壇しますー
  2. 他社の人とランチもしますー
  3. 他社の人とダーツもしますー

6.その他

挑戦のための種まきはいい感じに出来たので、来週がんばりますー!おー!

PHP Conference 2018のスピーカー応募してみました【351日目】

PHP Conference 2018?

phpcon.php.gr.jp

PHPというプログラミング言語のイベントですね。

大きな会場で、いろんな人が登壇したりしてるやーつ。で、そこで登壇したいなーという感じですー

何を話すの?

『新卒2年目がLaravelにコントリビュートするまで』ってタイトルで登壇したいなーと考えています。

申し込んだので、10月中旬の発表楽しみですね。登壇出来なかったときは、どこかのイベントで登壇するようにがんばりますー

登壇といえば。

こちらの方でも登壇しますー!

10/3、19:30から渋谷でやりますのでぜひぜひ。

supporterzcolab.com

最初20人定員だったのに、今27人になってて、増枠してるビビってる。

最初は人来ない方に怯えてたんだけどナー

今は逆に人増えてて震えてます。がんばりますー!当日はよろしくおねがいいたします!

We try to talk in English on lunch time.【350日目】

I try to write in English but...

Hi, I'm Obata. I'm Japanese.

I try to write in English now but I'm not good at writing and speaking in English. Sometimes, I will write wrong sentences, OK?

Can you speak in English?

When I was college student, I have some international friends. Our lab had many international student because our teacher is Chinese. So, I like talking in English. But I'm not good at speaking and hearing in English. When I talked in English with my friend, I sometimes said "please wait, please talk to me slowly.", "I'm sorry, I don't know that word. Can you explain me that word?", haha.

What did you do?

Yesterday, I and co-worker try to talk in English on lunch time. That time, we have one role "talk only in English". First, I can't talk because I'm shy boy. So I said "Now, I'm difficult to talk because I'm shy. If I can talk in Japanese, I can't talk too". Thay said "No problem!" and "OK!" so I love our co-worker.

We talked many topics, 'what they did in this weekend', 'Vue.js', 'VR', bla bla bla. I enjoyed it. I think I want to do it sometimes.

Don't be afraid.

My English is very poor. I try to speak in English so I can talk in English. If you want to talk in English, please try to speak in English. You can use one word. You can use some body-language. If your English is not perfect, it's OK. If you say something, you can explain your thinking. Because, you can understand what I want to say now.

DI(依存性注入)の仕組みが嬉しい理由【349日目】

DIってなんぞや

class A {
  private $db_handler;

  public __construct(Handler $db_handler) {
    $this->db_handler = $db_handler
  }
}

このクラスは、Handlerクラスがないと動かない。依存している。
その依存しているインスタンスを外部から渡してやっている。

このクラスを使うなら、new A(new MySQLHandler())こんな感じ。
これで嬉しいのは、new A(new PostgreSQLHandler())とかで使うこともできる。

良くない例

class A {
  private $db_handler = new MySQLHandler();
}

class Aは、依存しているものの中身を意識しないでいい

このとき、使うべきHandlerが、MySQLなのか、PostgreSQLなのか、
そこを意識しないでも、プログラムを書けるのがいいところ。

このおかげで、プログラムを書いてる人はどのデータベースに対しても書けるし、
テストコードも書きやすい。

【思考メモ】末端エンジニアで『見込み残業』が嬉しい理由【348日目】

新卒2年目エンジニアのメモ

よく、『みなし残業は悪だ!』という話を見かけますが、
新卒2年目の時点での私個人としては、個人的にはメンタルに優しい制度だなと感じます。

嬉しく感じるところをメモしてみます。

理由:バッファ

自分の作業、見積もり通りに『ピッタリ』やれますか。

早く終わるときもあれば、予想外の時間がかかるときもあります。
さらに、会社全体のイベントで、予想外に時間が削られる場合もあります。

その予想外の時間に対して、会社に費用を余分にかけさせないで済む、バッファとして機能します。

ゆったり仕事をするわけではないですが、
不意に残業しなければいけなくなったときに、
会社側に予算があるのかな?負担かけないかな?と考えなくていいのは、
非常にやりやすいです。

この思考になる理由

給料に対して、自分はどれだけコミット出来ているのか?

それを考えたときに、バッファがあると考えるのは楽になります。

もし、これがなかったら、不意に残業が必要になったときに、
会社に影響与えてしまう・・・って心が・・・

自分の給与、開発にかけた時間とお金は費用と考えると、
かけた時間がそのまま売上のマイナスになると考えると、
ちょっと残業代もらうって不安になりますよ、たぶん、きっと。

ということで、こんなふうに考えて働いている人もいますってことで、
参考にどうぞー

【思考メモ】給与のために仕事と役職を変える社会の不具合【347日目】

悲しい例

『ベテランエンジニアがいました』
『会社側は給与を上げるために、役職を上げました』
『出来るベテランエンジニアは、役職の都合、苦手なマネジメントの仕事を始めました』
『結果、周りも本人も不幸になりました』

あるえー?なんでこうなったー? って思うけど、わりと今の社会だとよくあることなのかなって。

どうするべきだった?

個人的に思うのが、給与テーブルが、役職とセットなのが良くないのかも。

じゃあどうするかというと、その人の仕事自体に給与テーブルを用意すること。
プロフェッショナルの人には、プロフェッショナルの人用の給与テーブルを用意すること

それ以外の解決方法が今まだ私は知らないとも言います(´・ω・`)

さて、今回の内容はここまで。以下は雑なメモです。

雑思考メモ

ピラミッド形式の組織において、
上から下に役割が違うのは、各層において、下層の仕事の責任を抽象化するという点で良いとは思う。

プログラムにおける抽象化みたいなイメージで組織を見てる。

ただ、給与に関しては上層が高い給与を持つとは限らないよなーとも思ってる。
だから、なんでそれが常識になってるんだろー?って今考えてる。
発生源が知りたいなとか。

責任の大きさとか、直接的な責任とか、仕事が与える影響範囲がキーになっている気がするけど、まだ自分の中で結論が出てない。

でも、最初に上げた具体例の問題って、どうしようもなかったのかなー?と思いながら、新しく本を手に取るのであった。

【Docker】Laravel+mailhogでメールのローカル開発環境構築【346日目】

ローカルで、メールのテストをしたい

Laravelでメールを送りたい。

ただ、実際に送ると、間違えて送ったら困る。

なので、mailhogを使ってメールが送信できているか確認しよう。

mailhogを使うと、ページを見に行くと下の画像のように送信したメールが見れます。

f:id:willow710kut:20180924231235p:plain

では、環境構築の方法を見てみましょう。

自作の参考コード

Mail by klack710 · Pull Request #12 · klack710/study-laravel · GitHub

Docker側

docker-compose.yml

  mailhog:
    container_name: study-laravel_mailhog
    image: mailhog/mailhog
    ports:
      - "8025:8025"
    environment:
      MH_STORAGE: maildir
      MH_MAILDIR_PATH: /tmp
    volumes:
      - .maildir:/tmp 

内容解説

  1. imageに mailhog/mailhogでmailhogの環境構築。
  2. portの設定。 localhost:8025でメールの受信状態を確認
  3. environment内の設定で、/tmpディレクトリに、メールの内容をファイルで保存する
  4. volumesで、手元の maildirディレクトリにメールの内容を保存する

Laravel側

  1. メール文面の設定
  2. メールを送信するコントローラー
  3. (テスト用に)コントローラーにアクセスするルーティング

1.メール文面の設定

<?php
 namespace App\Mail;
 use Illuminate\Mail\Mailable;

 class SimpleMail extends Mailable
{
     /**
     * メッセージの生成
     * from関数とか使うと、差出人とか変えられる
     * @return $this
     */
    public function build()
    {
        return $this->view('emails.simple_mail');
    }
}

simple_mail.blade.php

<body>
    <div>
    testmail
    </div>
</body> 

2.メールを送信するコントローラー

<?php
 namespace App\Http\Controllers\Mail;
 use App\Mail\SimpleMail;
use App\Http\Controllers\Controller;
use Illuminate\Support\Facades\Mail;

 class SimpleMailController extends Controller
{
    /**
     * メール送信
     *
     */
    public function send_mail()
    {
        Mail::to('crimsondrop710@gmail.com')
            ->send(new SimpleMail());
        return "メール送ったよ!";
    }
 } 

3.(テスト用に)コントローラーにアクセスするルーティング

Route::group(['namespace' => 'Mail' , 'as' => 'mail.'], function () {
    Route::get('/simple_mail', 'SimpleMailController@send_mail')->name('simple_mail');
});

内容解説

  1. SimpleMail extends Mailableで、build内でbladeを呼ぶ。
  2. bladeでhtmlメールのデザイン設定
  3. Mailファサードでsendを呼び、メール送信する

参考

MailHogを利用してメール送信テスト環境をdockerコンテナ上に作る - Qiita

Docker + Rails + Mailhogでメールを送信せずにブラウザで確認できる開発環境を作る - ココナラよもやまブログ