Laravel + Vue.jsでいいね機能・フォロー機能などを作るチュートリアルを公開しました

初心者向け Laravel PHP Vue.js

はじめに

LaravelとVue.jsで、いいね機能やフォロー機能を持つSNS風のWebサービスを作るチュートリアルをTechpitで公開しました。

紹介動画

このチュートリアルで学べる内容の一部を紹介しています(無音・30秒)。


目次

執筆の経緯

Techpitでは昨年9月にLaravel x LINE Botのチュートリアルを公開しましたが、ブラウザで利用できるタイプのスタンダードなWebアプリケーションの作り方も解説したいと思っていました。

昨年末にアプリ部分をいったん仕上げ、年が明けて1月からチュートリアル記事部分の執筆を開始し、3月に完成しました。

字数は50万字以上、画像も多く使用していますので、もし本にすると400ページぐらいのボリュームになるかと思います。

執筆にあたって心掛けたこと

チュートリアルの執筆にあたって以下を心掛けました。

  1. Webアプリの完成だけを目的とせず様々な知識を学べるようにする

  2. プログラミング初心者が知りたそうなWebサービスの「よくある機能」の作り方を盛り込む

  3. 基本的な機能から応用的な機能まで段階を踏んで学ぶ構成にする

  4. 認証機能を敢えてコマンド一発で作らない

  5. メール送信に関しては商用のWebサービスでも利用されるメールサービスを使う

  6. Laravelを使っていると普段目にしないSQLを確認・改善するプロセスを盛り込む

順に解説します。

1. Webアプリの完成そのものを目的とせず様々な知識を学べるようにする

チュートリアルでは、ただWebアプリの完成を目指すのではなく、途中途中に登場するコードとその解説を通じて、様々な知識を得られるようにしました。

本チュートリアルでは、Webアプリ作りを通じて、以下の知識に触れられるようになっています。

  • プログラミング一般
    • DIの初歩 / N+1問題
  • PHP
    • 三項演算子 / null合体演算子 / 型キャスト / 型宣言 / コールバック / クロージャ / トレイト
  • Laravel
    • リソースルート / authミドルウェア / CSRF保護 / フォームリクエスト / バリデーション / Blade / LaravelMix / 認証・認可 / ポリシー / コレクション / 各種ヘルパ関数 / メール / Eloquent ORM / データベースマイグレーション / リレーション / アクセサ / Eagerロード / Laravel Socailite / Laravel Debugbar
  • Vue.js
    • 単方向のデータフロー / Vue Tags Input
  • メール関連
    • Mailhog / Sendgrid

DI(Dependency Injection/依存性の注入)、型宣言、トレイトなどPHP初心者にはやや敷居が高いと思われる内容にも、知識の入り口として少し触れるようにしています。

2. プログラミング初心者が知りたそうなWebアプリの「よくある機能」の作り方を盛り込む

このチュートリアルで作成するWebアプリそのものはシンプルな記事投稿型サービスとなっています。

その代わりに、

  • いいね機能
  • フォロー機能
  • 記事へのタグ付け機能
  • ソーシャルログイン(Googleログイン)

といった、Webサービスでよく見られる機能を盛り込んでいます。

汎用的な機能ですので、プログラミング初心者の方が今後自作するWebアプリ、ポートフォリオに追加機能として組み込むこともできるのではないかと思います。

また、機能自体も、複数テーブルの多対多のリレーションや非同期通信、外部ライブラリの利用などの要素があり、知識やスキルのアップに繋がるのではと思います。

3. 基本的な機能から応用的な機能まで段階を踏んで学ぶ構成にする

一度に多くの情報を解説されても理解が追いつかない、という自身の学習経験から、

  • ひとつの要素を解説し、これを実装してから次の要素に進む

という構成を心掛けました。

例えば、第1章の「記事一覧を作ろう」では記事一覧画面を作成しますが、1章の前半では、コントローラーからビューに渡す記事一覧の情報をデータベースから取得せず、ダミーの固定データとしています。

具体的には、

  • コントローラーが初登場するパートでは、ビューにデータを渡すというコントローラーの役割のひとつを理解してもらう
  • その次のパートでは、ビューを作成し、ダミーの固定データを表示する
  • さらにその次のパートで、初めてデータベースに記事テーブルを作成する

といった具合です。

Laravel、というかMVCフレームワークそのものを初めて触る初心者でも、つまづくことなく、ひとつひとつの要素を学んでいけるようになっています。

なお、チュートリアルの後半では、基礎を理解している前提でもう少しテンポアップして解説を進めますので、説明がゆっくり過ぎてまどろっこしい、といったことも無いかと思います。

いま説明したのは1つの章の構成の話ですが、チュートリアル全体としても、

  • 前半の6章まではLaravelの知識だけで開発できる
  • 中盤を過ぎた7章の「いいね機能」からは応用編としてフロントエンドにVue.jsを導入

といった構成になっています。

チュートリアルの章立て

  • 0章：はじめに
  • 1章：記事一覧を作ろう
  • 2章：ユーザー登録機能を作ろう
  • 3章：ログイン機能を作ろう
  • 4章：記事投稿機能を作ろう
  • 5章：記事更新・削除・詳細表示を作ろう
  • 6章：メールを使ったパスワード再設定機能を作ろう
  • === ここまでLaravelのみ ===
  • === ここからVue.jsも登場 ===
  • 7章：いいね機能を作ろう
  • 8章：タグ機能を作ろう
  • 9章：フォロー機能とユーザーページ機能を作ろう
  • 10章：Googleアカウントを使ったユーザー登録・ログイン機能を作ろう
  • 11章：デバッグバーを使ってSQLを改善しよう
  • 12章：作ったWebサービスをインターネットに公開しよう

4. 認証機能を敢えてコマンド一発で作らない

もともとLaravelは、(laravel/uiというライブラリを別途インストールすれば)ユーザー登録やログインといった認証関連の機能をコマンド一発で作成できます。

これはこれでとても便利なのですが、この方法だけでしか認証機能を作った経験が無い場合、初心者がいざ自分の作ろうとするWebアプリに合わせて認証機能をカスタマイズしようと思った時に、どのコードから手を付ければ良いのか分からないのではないでしょうか？

そこで、本チュートリアルでは認証機能を敢えてコマンド一発で作らずに、フレームワークのコードを読みながら順に作成していくようにしました。

本チュートリアルを通じて、フレームワークのコードを読む、という実務で求められる行為にも少し慣れることができるのではないかと思います。

5. メール送信に関しては商用のWebサービスでも利用されるメールサービスを使う

Laravel初心者で、Laravelからメール送信を行ったことがある人は、普段から馴染みのあるGmailのセキュリティ設定を下げて利用したことが多いのではないでしょうか。

本チュートリアルでは、商用のWebサービスでも利用されている、Sendgridというメールサービスの無料枠を使ってメール送信を行う方法を解説しています。

今後、Laravelで個人開発のWebサービスなどを作る際に、メール送信機能を組む込む上で、この知識が役に立つかと思います。

6. Laravelを使っていると普段目にしないSQLを確認・改善するプロセスを盛り込む

LaravelではデータベースのアクセスにORM(Object-relational mapping)が使用されており、SQLを書くことなく、データベースのテーブルにアクセスできます。

ただし、実務ではどのようにSQLが発行されているか意識して開発する必要があります。

本チュートリアルでは、Laravelのデバッグ機能を使用して実際に発行されているSQLを確認するとともに、非効率な部分(N+1問題)を改善してLaravelのレスポンスを向上させるプロセスを学びます。

チュートリアルへの感想

チュートリアルを公開してまだ1週間ですが、さっそく感想をブログやTwitterで報告してくれている方がいますので、一部掲載させていただきます。

ありがとうございます！

ちなみにRails、Laravel、Python、Vue.jsなど含め、Techpit教材はかなり漁ってきました。その中でもかなりおすすめの教材です。

初学者がポートフォリオ作成で躓く(私含め)であろうミドルウェア、リクエスト、認可、ポリシー、さらにはフロンドエンドフレームワーク(Vue.js)との連携まで、実際にアプリを作りながら体験できます。

【感想】Laravel(+Vue.js)でSNS風Webサービスを作ろう！を終えて

終わりに

以上、Laravel x Vue.jsのチュートリアルの解説でした。

ぜひ、このチュートリアルを手に取ってLaravelを学び、個人開発や就職のためのポートフォリオ作りなどに活かしていただければと思います！

【初心者向け】Laravelテストチュートリアル

Laravel PHP テスト 初心者向け

Laravel6

はじめに

「ようこそ・・・『テストの世界』へ・・・」

本記事では、テストコードをまだ書いたことのないプログラミング初学者向けに

「今日からテストを書いてみようかな」

と思ってもらえるよう、チュートリアル形式で簡単なテストの流れを説明します。

題材はLaravelですが、他のフレームワークでも同じようなことはできると思います。

注:本記事は、以前に私がQiitaに投稿したLaravel5.8のテストチュートリアルをLaravel6で動作するよう改訂したものです。

目次

前提

本記事の対象者

  • Laravel初心者で、
    • テストをまだ書いたことの無い人
    • テストで何ができるのか知らない人
    • テストに興味はあるが忙しくてどう書けば良いのかまだ調べられていない人

本記事で取り扱うこと

  • ごく簡単なHTTPテストの書き方

本記事で取り扱わないこと

  • テストの全般的な話(利点、注意点など)
  • テストケースの作り方
  • CIツールによるテスト自動化

環境

  • Laravel 6.4.x

簡単な画面(HTTPレスポンス)のテスト

まずは、Laravelを触ったことのある人なら一度は見たことのある？Welcome画面をテストしてみます。

これが正常に表示されることを、目視ではなくテストコードで確認してみましょう。

Welcome画面

Laravelをインストールすると、既にtests/Feature/ExampleTest.phpという、テストコードのサンプルが存在します。

tests/Feature/ExampleTest.php

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class ExampleTest extends TestCase
{
    /**
     * A basic test example.
     *
     * @return void
     */
    public function testBasicTest()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

このExampleTestは、Tests\TestCaseを継承しており、テストに関する様々なメソッドが使えます。

$response = $this->get('/')で、'/'にアクセスした(GETリクエストした)結果のレスポンス(注1)が$responseに代入されます。

注1: 正確には\Illuminate\Foundation\Testing\TestResponseが代入されます。

そして、$response->assertStatus(200)で、そのレスポンスが正常であること(ステータスコードが200 OKであること)をチェックしています。

ステータスコードについては以下を参考にしてください。

このExampleTestを実行するには、Laravelのルートフォルダで以下コマンドを実行してください。

$ ./vendor/bin/phpunit ./tests/Feature/ExampleTest.php

すると、以下の結果が表示されました。

PHPUnit 8.4.3 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 405 ms, Memory: 16.00 MB

OK (1 test, 1 assertion)

OK、と表示されています。

つまり、'/'へアクセスした(GETリクエストした)結果、正常にレスポンスが返ってきた(HTTPレスポンスステータスコードが200 OKだった)ということです。

これをテストコードで確認することができました。

ビューのテスト

ただ、このテストでわかったのは、正常にレスポンスが返ってきた、ということまでです。

Welcome画面が表示されたのかどうかまでテストできていません。

現状のルーティングを見ると、'/'へアクセスすると、'welcome'というビューが表示されることがわかります。

routes/web.php

<?php

// 略

Route::get('/', function () {
    return view('welcome');
});

welcomeというビューは、具体的にはresources/views/welcome.blade.phpというビューのテンプレートです。

このresources/views/welcome.blade.phpこそがあのWelcome画面なので、このテンプレートが使われているかどうかをテストで確認してみます。

tests/Feature/ExampleTest.phpに以下のコードを追加します。

tests/Feature/ExampleTest.php

<?php

// 略

public function testBasicTest()
{
    $response = $this->get('/');

    $response->assertStatus(200)
        ->assertViewIs('welcome'); // 追加
}

このようにassertViewIsメソッドで、どんなビューが使われたのかをテストすることができます。

修正後のExampleTestを実行してみます。

$ ./vendor/bin/phpunit ./tests/Feature/ExampleTest.php
// 略
OK (1 test, 2 assertions)

こちらも結果はOKとなりました。

あのWelcome画面が表示されていることを、テストコードで確認することができました。

さらにassertSeeメソッドを使うと、表示(注2)されている文字列もテストできます。

注2: 正確にはhtml内にその文字列が含まれているかをテストします。htmlのタグなども確認の対象になります。

Welcome画面にLaravelの文字が表示されていることを、テストコードで確認してみましょう。

tests/Feature/ExampleTest.phpに以下のコードを追加します。

tests/Feature/ExampleTest.php

<?php

// 略

public function testBasicTest()
{
    $response = $this->get('/');

    $response->assertStatus(200)
        ->assertViewIs('welcome')
        ->assertSee('Laravel'); // 追加
}

修正後のExampleTestを実行してみます。

$ ./vendor/bin/phpunit ./tests/Feature/ExampleTest.php
// 略
OK (1 test, 3 assertions)

こちらも結果はOKとなりました！

ログイン中かどうかを絡めたテスト

ここから先は、ユーザーがログイン中かそうでないかによって結果が異なる画面をテストしていきます。

laravel/uiライブラリからユーザー登録画面やログイン画面等を作成できるので、これを実行します。

$ php artisan migrate
$ composer require laravel/ui
$ php artisan ui vue --auth
$ npm install
$ npm run dev

上記コマンドの詳細については、以下の記事を参考にしてください。

Welcome画面にユーザー登録画面とログイン画面へのリンクが追加されました。

LoginとRegisterが追加されたWelcome画面

以下、テストではなく人力でユーザー登録画面にアクセスし、ユーザー登録を行なっています。

Register画面

ユーザー登録が完了すると、以下のホーム画面へ遷移します。なお、ログイン画面からログインした場合も、このホーム画面へ遷移します。

ホーム画面

ホーム画面は、ログイン中の時のみ表示されます。

ログインしていない状態で直接/homeへアクセスすると、ホーム画面は表示されず、ログイン画面へリダイレクトされます。

この「ホーム画面は、ログイン中の時のみ表示される」ということをテストコードで確認してみましょう。

ホーム画面の表示は、php artisan make:authコマンドによって作成された、app\Http\Controlles\HomeControllerで行われています。

このHomeControllerをテストするためのHomeControllerTestを作成します。

以下コマンドを実行すると、テストの雛形を作成できます。

$ php artisan make:test HomeControllerTest

作成されたテストの雛形の内容は、以下になります。

tests/Feature/HomeControllerTest.php

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

class HomeControllerTest extends TestCase
{
    /**
     * A basic feature test example.
     *
     * @return void
     */
    public function testExample()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

このtests/Feature/HomeControllerTest.phpを以下の通り編集します。

tests/Feature/HomeControllerTest.php

<?php

// 略

public function testExample()
{
    $response = $this->get('/home'); // 変更(ホーム画面のパスに変更)

    $response->assertStatus(200)
        ->assertViewIs('home') // 追加(ここでの'home'は、ホーム画面で使われているビュー名)
        ->assertSee('You are logged in!'); // 追加(ホーム画面で表示されているメッセージ)
}

このHomeControllerTestを、以下コマンドで実行します。

$ ./vendor/bin/phpunit ./tests/Feature/HomeControllerTest.php

すると、以下の通り、OKではなくFAILURES!となりました。

PHPUnit 8.4.3 by Sebastian Bergmann and contributors.

F                                                                   1 / 1 (100%)

Time: 1.15 seconds, Memory: 16.00 MB

There was 1 failure:

1) Tests\Feature\HomeControllerTest::testExample
Expected status code 200 but received 302.
Failed asserting that false is true.

/var/www/vendor/laravel/framework/src/Illuminate/Foundation/Testing/TestResponse.php:183
/var/www/tests/Feature/HomeControllerTest.php:20

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

Expected status code 200 but received 302.と出力されています。

ログイン中でない状態でアクセスしたので、リダイレクトを示す302のステータスコードが返ってきた、ということです。

そこで、ログインした状態を作り出してテストしてみます。

DBには、先ほど人力でユーザー登録画面にアクセスして登録したユーザーデータが存在するので、テストではこのユーザーを使うことにします。

# select id, name from users;
 id |        name        
----+--------------------
  1 | shonansurvivors
(1 rows)

tests/Feature/HomeControllerTest.phpを以下の通り編集します。

tests/Feature/HomeControllerTest.php

<?php

namespace Tests\Feature;

use App\User; // 追加
use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;


class HomeControllerTest extends TestCase
{
    public function testExample() 
    {
        $response = $this
            ->actingAs(User::find(1)) // 追加
            ->get(route('home'));

        $response->assertStatus(200)
            ->assertViewIs('home')
            ->assertSee('You are logged in!');
    }
}

actingAsメソッドで、そのユーザーとしてログイン済の状態になります。

また、User::find(1)で、DBのusersテーブルからidが1であるユーザーを取ってきています。

改めてHomeControllerTestを、以下コマンドで実行します。

$ ./vendor/bin/phpunit ./tests/Feature/ExampleTest.php

すると、OKとなりました。

OK (1 test, 3 assertions)

ログイン中の状態で/homeへアクセスすると、

  • ステータスコードが200となること
  • homeというビューが使われていること
  • You are logged in!が、html中に存在すること

が確認できました。

このようにログイン中かどうかが絡む機能も、テストコードで確認できます。

テストに必要なDBのデータを自動で準備する

今回はたまたま開発環境のDBにユーザーのデータが存在し、テストではこれを利用してログインを行いましたが、 テストに必要なDBのデータ準備もコードで自動化してみます。

Laravelではテスト用のDBのデータを作るのに、ファクトリというものを使う方法があります。

database/factories/UserFactory.phpが、ユーザーデータを作るためのファクトリです。

database/factories/UserFactory.php

<?php

use App\User;
use Faker\Generator as Faker;
use Illuminate\Support\Str;

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', // password

        'remember_token' => Str::random(10),
    ];
});

このファクトリの詳細については本記事では触れませんが、これを使うといい感じにダミーのデータを作ってくれます。

ファクトリについてもっと知りたい方は、以下記事を参考にしてください。

このファクトリを使うよう、tests/Feature/HomeControllerTest.phpを以下の通り変更します。

tests/Feature/HomeControllerTest.php

<?php

namespace Tests\Feature;

use App\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;


class HomeControllerTest extends TestCase
{
    public function testExample()
    {
        $user = factory(User::class)->create(); // 変更(ファクトリでユーザーデータを作成)

        $response = $this
            ->actingAs($user) // 変更(ファクトリで作ったユーザーデータでログイン中状態を作る)
            ->get(route('home'));

        $response->assertStatus(200)
            ->assertViewIs('home')
            ->assertSee('You are logged in!');
    }
}

ファクトリで作成されたユーザーにて、ログイン中の状態を作っています。

以下コマンドでHomeControllerTestを実行すると、結果はOKとなりました。

$ ./vendor/bin/phpunit ./tests/Feature/HomeControllerTest.php
// 略
OK (1 test, 3 assertions)

ただ、これだとHomeControllerTest実行のたびにDBにダミーのユーザーデータが1件また1件...と作られてしまいます。

sample=# select id, name from users;
 id |        name        
----+--------------------
  1 | shonansurvivors
  2 | Dr. Jayce Wiegand
(2 rows)

2件目がファクトリで作られたダミーのユーザーデータです。

これに対しては、ひとつのやり方として、テスト用のDatabaseTransactionsを使うという方法があります。

これを使うと、テストの実行後にDBをロールバックし、テスト実行中にDBに作ったデータが残らなくなります。

tests/Feature/HomeControllerTest.phpで、DatabaseTransactionsを使うようにします。

tests/Feature/HomeControllerTest.php

<?php

namespace Tests\Feature;

use App\User;
use Illuminate\Foundation\Testing\DatabaseTransactions; // 追加
use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;


class HomeControllerTest extends TestCase
{
    use DatabaseTransactions; // 追加

    public function testExample()
    {
        // 以下変更点なしにつき省略

以下コマンドでHomeControllerTestを実行すると、結果は引き続きOKとなりますが・・・

$ ./vendor/bin/phpunit ./tests/Feature/HomeControllerTest.php
// 略
OK (1 test, 3 assertions)

テスト終了後のDBを見ると、ユーザーデータはテスト開始前時点から増えてはいません(2件のまま)でした。

sample=# select id, name from users;
 id |        name        
----+--------------------
  1 | shonansurvivors
  2 | Dr. Jayce Wiegand
(2 rows)

これでDBにダミーデータが残ることなく、何度でもテストを実行できます。

最後に

以上で、本記事のテスト体験ツアーは終了です。

テストでどのようなことができるか、イメージはつかめたでしょうか。

本記事をきっかけに、テストを書き始めていただければ幸いです。

「納期は守る」「品質も確保する」 「両方」やらなくちゃあならないってのが「エンジニア」のつらいところだな

「LaravelでLINE Botを作るTechpit教材」のレビュー・感想まとめ

Laravel Line 勉強法

はじめに

「Laravelで飲食店検索LINE Botを作ろう！」という教材をTechpitで公開し、約1ヶ月半が経過しました。

多くの方に購入いただき、また教材への感想も多数いただいています。

今回はそれらを紹介させていただきます。

目次

Techpitでのレビュー

Techpitでは受講した方が任意でレビューを投稿することが可能で、教材のトップページにはそれらレビューが表示されます。

f:id:shonansurvivors:20191022145527j:plain

現時点では、投稿された全てのレビューで5段階評価最高の星5をいただけています。

以降は、実際のレビュー内容です。

まず、1人目の方の感想。

買ってよかった。

このコースの通りやれば、LINEbotを作れる。

個人的に嬉しかったのが以下の３点。

  1. Laravelでアプリを作成〜公開までのやり方が分かった。

  2. Laravelでアプリを開発するのに有用なツールやライブラリ、コマンドを知ることができた。

  3. 外部APIを使う際の流れが理解できた。

どれもLaravelの入門書だと調達できなかった知識なので、よかった。

LINEbotが目的でなくても、Laravelの開発をするつもりであれば、知っておきたい内容だと思った。

Laravelの入門書と並行して私の教材に取り組んでいただき、入門書では触れていない知識をうまく私の教材が補完するかたちとなったようです。

嬉しかった3点、として挙げていただいた点が、まさに私の教材で意識して盛り込んだ内容なので、大変嬉しいです。

Laravelでアプリを作成〜公開までのやり方が分かった。

教材ではHerokuへのデプロイ方法を解説しています。

Herokuなどにデプロイができるようになると、自作のアプリをネット上で広く使ってもらえるようになり、プログラミング学習のモチベーションがぐっと上がるかと思います。

そのため、教材にはデプロイ方法の解説を盛り込みました。

Laravelでアプリを開発するのに有用なツールやライブラリ、コマンドを知ることができた。

APIとの通信などに便利なHTTPクライアントライブラリGuzzleの使い方や、対話形式ですぐにLaravelの処理を試せるtinkerなど、LINE Botと直接は関係無い知識も積極的に盛り込んでいます。

外部APIを使う際の流れが理解できた。

教材では、ぐるなびAPIの使用方法を解説しています。

何かひとつAPIの使い方を学べば応用して他のAPIも使いやすくなり、作ることのできるアプリの幅も広がることになるので、API利用を題材としました。

次に2人目の方の感想。

満足のいく講座でした。

最終的にはherokuにアップロードして公開することが目的ですが、途中途中でオウム返しbot, 簡易版などを作成し公開することで段階的に理解することができました！

Laravel入門書（青本）を一読した後にお勧めだと感じます。

教材では一気に完成形のLINE Botを作るのではなく、シンプルな内容から徐々にBotの機能を発展させていく構成としましたが、その点を評価いただけたようです。

こちらの方も通称青本と呼ばれる以下のLaravel入門書と併用して、私の教材に取り組んでいただいたようです。

PHPフレームワーク Laravel入門

PHPフレームワーク Laravel入門

続いて3人目の方の感想。

簡単にLINE Botを作ることができました。laravelの初学者でも、十分理解ができ、API の活用方法を知れる良い教材でした！

Laravel初学者でも十分に理解できるとのことですが、丁寧な解説を心掛けたので大変嬉しいです。

また、LINE Bot作りを通じてAPIの活用方法を学んでいただけたようです。

4人目の方の感想。

制作意欲も湧き、内容もわかりやすい非常に良い教材でした。次回作も期待しています。

教材作成前の内容検討段階では他にもいくつか候補はあったのですが、Techpitさんとの相談の中で「LINE Botは制作意欲が湧きやすい題材のひとつでは？」という話になり、今回選択しました。

それが良い結果に繋がったようで嬉しいです。

最後に5人目の方の感想。

LineBotなどのAPIなどを使ってみたい、Laravelに触れてみたいという方にオススメです。

実用的にアプリが作れるので楽しかったですし、解説や質問への回答も丁寧ですごく良かったです。

この教材の前後でLaravel本を読むとより理解が深まると思います。

こちらの方は教材の途中でエラーが出て一時詰まってしまったのですが、Techpit上の質問機能で私とやり取りし、無事LINE Botを完成させることができました。

その質問対応も含めて評価をしていただけました。

Twitter上での感想

Twitter上でも感想を書いて下さる方がいたので、それらの一部を紹介します。

同じ方なのですが、異なる観点で2つ感想を書いていただけているので、その両方を紹介します。

初級レベルで基本的なことから記述してくれていたから、Laravel勉強始めたばかりの自分は取り組みやすかった！

基礎的なところから解説をしている点を評価いただけました。

PHPの初歩的な知識(変数、配列、連想配列、if文、foreach文、関数・引数の概念の理解)があればLaravel未経験でも教材を進められるよう解説しているつもりなので、Laravel初学者の方であればすんなりと入っていけるのでは、と思います。

Lineでキーワードを入力すると飲食店検索ができるようになって、デプロイ方法まで解説されてるからこのチュートリアル完成させれば普通にアプリケーションとしても便利だ😄

ある程度の実用性を持たせたアプリを作ることのできる点を評価いただきました。

アプリ(LINE Bot)完成後はご自身で使ったり、知り合いにLINE上で友だち登録して使ってもらうなどして、楽しんでもらえたらと思います。

教材を使った勉強会での感想

また、既に開催済みですが、私の教材を使った勉強会をTechpitさんに先日開催いただきました。

10/19(土)の開催に対し、その4日前の10/15(火)からの告知だったので募集期間は短めでしたが、大変嬉しいことにすぐに募集枠はいっぱいとなりました。

参加いただいた方からは以下のような感想をいただきました。

外部apiとlaravelの連携だったりインターフェース,tinker,guzzleだったりと知りたかった技術が実際にアプリとしてどのように機能するのか。最初から調べながらやるよりもはるかに理解がしやすかった。

様々な知識を短期間で効率的に学べる点を評価いただきました。

この教材を足がかりに、更にアプリケーション開発の知識を広げていっていただけたらと思います。

最後に

以上、「Laravelで飲食店検索LINE Botを作ろう！」のレビュー・感想まとめでした。

多くの方から好意的な評価をいただけて、教材執筆者としては嬉しい限りです。

こちらの教材に興味を持った方は以下のTechpitのサイトからご覧ください。

「AWS IAMのマニアックな話」とCloudFormation

AWS 書評

技術書典7で頒布された「AWS IAMのマニアックな話」のダウンロード版をBOOTHにて購入しました。

takuros.booth.pm

本の概要

タイトルに「マニアックな・・・」とありますが、実は表紙を見ると「初心者からマニアまで必読」とあるこの本。

AWSアカウントとIAMユーザーの違いなど、基礎的な内容から始まって段階的にIAMについて理解できる本となっています。

全10章構成の1章・2章で基礎を押さえた後は、3章のチュートリアルで実際にIAMポリシー等を作成。

4章以降はIAMの設計・運用に役立つ実践的なノウハウがまとめられています。

CloudFormation学習者にもおすすめ

この本の内容全体に対する書評としては、Qiitaでもトレンドとなっていた、

が詳しいので、私からは個人的に嬉しかった第8章の「IAMとCloudFormation」について。

この章では、CloudFormationを使ってIAMを管理することの利点のほか、別途コラムというかたちで、IAMに限らずAWSリソース全般に関してCloudFormationを継続的に利用するための考え方について触れられています。

CloudFormationの使い始めは、それ全部で完結するような長大なテンプレートファイルを作成してしまいがちなようで、これに対して

  • どのようなAWSリソースがCloudFormationのテンプレートファイル化に適しているか、その考え方

  • ひとつのテンプレートファイル内で管理するAWSリソースの粒度

について解説されており、これが私には非常に勉強になりました。

もちろん、このIAM本で取り扱われていることからもわかる通り、IAM(IAMユーザーは除く)はCloudFormationで作成・管理するのに適しており、その具体的手法が学べます。

なお、IAMを作成するためのCloudFormationテンプレートファイルは比較的シンプルなものになるようで、CloudFormation入門の題材としてもIAM作成はお勧めだそうです。

続く9章ではサンプルとして、管理者グループ、開発者グループなどを想定した6タイプのIAMグループの構成が掲載されています(CloudFormation用テンプレートファイルも本掲載のURLからダウンロードできます)。

これらも活用して、IAMに加えてCloudFormationの理解も深めていきたいと思います。

ITエンジニアの副業として有料チュートリアルが持つ可能性

キャリア 働き方 副業

はじめに

プログラミング初学者向けの教材(チュートリアル)を執筆し、Techpitというプログラミング学習サービスで公開しました。

Techpitは、作りながらプログラミングが学べる「プログラミング学習教材のマーケットプレイス」です。現役のエンジニアがプログラミング学習者向けに教材を販売し、プログラミング学習者は現役エンジニアが作った教材で、文法ではなくサービスの作り方を学ぶことが出来ます。

これまでQiitaなどに自らの勉強目的でチュートリアルを投稿したことは何度かありますが、有料のチュートリアルを作成したのは今回が初となります。

有料なので、筆者である私にはその売上の一部が入ります。私は企業で社員として働いているので副業収入ということになります。

今回は企業に属する社員エンジニアの副業という観点で何か参考になればと思い、執筆のきっかけや動機、副業としての可能性などの考えを書きます。

目次

執筆のきっかけ

7月上旬にTechpit運営の方からtwitterのDMでコンタクトをいただきました。

私が過去にQiitaに投稿したLaravelのチュートリアル記事が、比較的Googleの検索上位であったことが目にとまり、声をかけてくださったそうです。

後日ビデオチャットでTechpitというサービスがどういったものであるかの説明を受けた後、今後充実させる必要のある教材について話し合い、Laravelの教材を作成することになりました。

なぜ執筆することにしたか

執筆の動機としては2点あります。

  • もともと何か有料のコンテンツを作成してみたかったが、なかなか書くきっかけをつかめずにいた

  • スタートアップのサービスのこれからの成長に関わってみたかった

もともと何か有料のコンテンツを作成してみたかったが、なかなか書くきっかけをつかめずにいた

アウトプットの一環としてnoteや技術書典などに何か有料のコンテンツを出したい、という気持ちは前々からありました。

ただ、有料のコンテンツを出すからにはそれなりの質・ボリュームのものを、という思いもあり、本業やそれに関する勉強のさなか、なかなか手をつけられずにいました。

そんな中で今回声をかけてもらったわけですが、Techpitでは教材を章単位で作成し、ひとつの章の作成が完了したら運営の方がレビューをする、というプロセスを繰り返し、教材全体を完成させていきます。

また、各章の作成について納期にあたるものはありませんが、これから作成に着手する章の完成の目処をSlackで伝え、一定の期日感を持って執筆に取り組むことになります。

「一人で黙々とコンテンツを作成するよりは、運営の方のレビューを受けながらある程度の締め切り意識を持って取り組んだ方が最終的に完成させられそう」と考え、Techpit向けに執筆することにしました。

実際、7月上旬から8月下旬までの2ヶ月間で約100,000字(技術書であればおそらく200〜300ページの規模)のチュートリアルを書き上げましたが、セルフコントロールだけでこの期間にこの量をこなすのは無理だったと思います。

スタートアップのサービスのこれからの成長に関わってみたかった

上から目線の偉そうな物言いになってしまって大変恐縮なのですが、Techpitはプログラミング学習サービスとして、Progateやドットインストール等と比較してまだ若いサービスです(ローンチしたのも昨年10月とのこと)。

サービスの認知度やコンテンツ量もこれから伸びていくのだと思います。

そういったスタートアップのサービスに微力ながらも実際に自分も関わることで、外部からの1コンテンツ提供者という立場ではありますが、このサービスが今後どのように成長していくのか、強い関心を持つことができるのではと考えました。

執筆着手後はSlackにて運営の方々と頻繁にやり取りを行ったほか、ミートアップにも一度参加させていただきましたが、プログラミング学習サービスとしてより良いものにするための今後の展望などを共有してもらえたほか、私からの記事執筆のこと以外の質問にも随時真摯に答えていただけるなど、単に教材を執筆する以上のさまざまな学びや気付きを得ることができました。

執筆にあたって留意したこと

今回の有料チュートリアル記事執筆では、自分のこれまでの無料記事と比較して以下の点で差別化を図るようにしました。

無料(Qiita等) 有料(Techpit)
対象者 テーマにもよるが初学者から現役ITエンジニアまで幅広く おもに実務未経験のプログラミング初学者
テーマ 何らかの技術にフォーカス プログラミング初学者にとって親しみやすい何らかのアプリケーションを完成させる(ただし、完成だけを目的とせず、その過程で触れる各技術については詳しく解説)
ボリューム 1,000字〜多くて10,000字弱程度 100,000字程度(技術書200〜300ページ規模)
開発環境構築方法 記事のテーマでなければ特に解説しない 素のMac OSの状態からの構築方法を全て解説
コードの解説 記事のテーマと直接関係の無いコードについては解説しない 組み込み関数の仕様なども含め、登場したコードについて基本的に全て解説
画像 必要最低限 Webサイト上でのサービス登録、インストールなどGUIを使う場面があれば1ステップごとに画面の画像を掲載

Techpitで上記のような基準やガイドラインがあるというわけではありませんが、自分個人としてこういった線引きをした上で執筆に取り組みました。

教材公開後の売れ行きについて

執筆を終えて先日教材を公開したばかりですが、いまのところ連日購入をいただけている状況です。

副業としての有料チュートリアルの可能性

ITエンジニアの副業の一部としては以下のようなものが挙げられるかと思います。

  1. 個人開発したアプリからの課金や広告収入を得る
  2. 個人として技術書を執筆し、技術書典やBooth、Amazon(Kindle)などで販売する
  3. noteなどに技術に関する有料記事を投稿する
  4. Udemyなどに技術に関する有料動画を登録する

Techpitがターゲットとするプログラミング学習者向けの教材作成は、上記の1, 2を組み合わせたところがあると私は思っていて、

  • サービスとしてグロース、マネタイズすることは厳しいが何らかのアプリのアイディアを持つエンジニアが、

  • プログラミング初学者でも挑戦できるレベルにアプリをシンプル化した上で、

  • そのアプリの作り方を、個人執筆の技術書レベルの詳細度でチュートリアル化する

といったアプローチを取ることで、アプリのアイディア、作成スキルをマネタイズできるのではと思います。

なお、3.のnoteとの違いは、

  • Markdownで教材を執筆できること

4.のUdemyとの違いは、

  • 動画撮影、音声録音などの無いテキスト形式の教材であるため、相対的に作成着手のハードルが低く、メンテナンスも容易

といった点があると思います。

(note, Udemyもそれぞれ優位な点があると思いますので、Techpitの方が良いと結論づける意図はありません)

Techpitでは、教材の販売と同時に教材執筆者募集も行なっているようです。

興味のあるITエンジニアの方向けに募集フォームのリンクを以下に掲載しておきます。

docs.google.com

最後に

以上、副業として取り組んだ有料チュートリアル執筆の振り返りでした。

今回の記事がITエンジニアの方々の参考になれば幸いです。

最後にPRとなりますが、プログラミング初学者の方でもし興味があれば、ぜひ以下の教材をご覧ください。

この教材の対象者

  • PHPの初歩を学んだ次のステップとして、何かWebアプリケーションを作ってみたいと思っている方
  • PHPの人気フレームワークであるLaravelを使ったWebアプリケーション開発を学びたい方
  • Webアプリケーション開発に役立つさまざまな知識を得たいと思っている方
  • LINE Botの開発方法を学びたい方

Webエンジニアになって3ヶ月が経ちました

Webエンジニア キャリア 働き方

はじめに

Webエンジニアにキャリアチェンジして、3ヶ月が経過しました。

今回は直近約2ヶ月間(6〜7月)の振り返りとなります。

目次

おもな仕事内容と得られた知見

入社直後にアサインされたプロジェクトを、7月のリリース完了まで引き続き担当しました。

(アサイン当初の話はこちら👇)

プロジェクト内で担当する領域としては、LaravelによるバックエンドとVue.jsによるフロントエンドの開発となります。

様々な機能の実装を行なったのですが、その中で特に印象に残ったこととして以下の3点があります。

  • フレームワークの機能の把握
  • 適度なドキュメント整備
  • テストコード

フレームワークの機能の把握

今回のプロジェクトで作る各画面では、社内外のユーザーの権限やデータの状態に応じて、各データへの参照可否や更新可否を制御する必要がありました。

それらをどう実現するか・・・と、Laravelの公式ドキュメントを調べているとGateやPolicyといった認可の機能が見つかったので、これらの使い方を公式ドキュメントで調べながら順次実装していきました。

この認可に関しては自らフレームワークの適切な機能を選択して実装することができましたが、他の認可以外の機能に関してはレビュアーから

「Laravelではこれこれという標準的な機能があるのでそれを使った方が良い」

と指摘を受けることもあったので、フレームワークの様々な機能を幅広く把握しておくことは重要だと感じました。

そのフレームワークを選択しているからには、フレームワークの思想や設計に準じて実装していくことが求められる・・・と考えるからです。

このあたり、経験や知識量が多分に関係してくると思うので、

  • 日頃から公式ドキュメント等でインプットしておく
  • 一方で、そのフレームワークでの開発経験が長い周囲のエンジニアに早めに相談して手戻りの発生を抑える

といったことをバランス良く行うことが大切かな、と思います。

適度なドキュメント整備

前述の認可では、ユーザーの権限やデータの状態、操作内容といった可否の組み合わせが多岐に渡りました。

そのため、実装漏れが無いよう、いったん対応が必要な箇所をドキュメントに洗い出した上で、順次実装していくことにしました。

前職でIT関連の利用部署にいた時は膨大なドキュメントと付き合っており、それに対して現職ではドキュメント作成は必要最低限とする文化にあると思っていますが、この認可の仕様に関しては抜け漏れ防止の面であらかじめドキュメントを整備しておいて良かったと思います。

テストコード

今回のプロジェクトで、最も重要な機能のひとつが、バッチ処理や画面での入力に応じて金額の計算を行う、というものでした。

これに関しては、テスト駆動開発、とまでは行きませんでしたが、金額計算の実装がある程度終わってから、それを追いかけるようにテストコードを書きました。

職場の環境では、開発したコードは必ず自動でテストが実行される仕組みになっています。

ですので、いったん完成した金額計算のコードに新たに追加・修正を行う必要が生じた際も、作成済みのテストがあれば非常に安心感がありました。

適切なテストを書いていれば、追加・修正したコードを起因としてこれまでうまくいっていた金額計算に不備が生じる、ということを避けられるからです。

テストコードに対しては、

「こんな便利なものはもっと早くから書き始めれば良かった・・・」

という思いがあり、テストコードを書き始める前の自分を読者として想定して、チュートリアル風の記事をQiitaに投稿しました。

こちらがありがたいことに好評で、一時期デイリートレンド1位まで獲得し、200以上のいいねをもらうことができました。

社内のSlackでも、トレンド入りを採り上げてもらい、とても励みになりました。

今後について

そんなこんなで3ヶ月目も経過したのですが、このたび職場で新チーム体制の発表があり、私はSREチームへの配属が決まりました。

実際には9月からの配属なので、まだSREとしての実務には入っていないのですが、

  • AWS全般
  • Ansible
  • CI/CD
  • Go

などがキーワードになりそうです。

もともとSREには関心があって、いずれはやってみたいとは思ってたのですが、予想外に早くそのタイミングがやってきましたw

キャッチアップは非常に大変だと思いますが、SREという考え方や自社のインフラを細部まで把握できる(しなければならない)良い機会となるので、何とか頑張っていきたいと思います。

最後に

以上、Webエンジニア3ヶ月目の振り返りでした。

今後SREや、その他エンジニアとして学びや気づきがあった際にはまた報告したいと思います。

Webエンジニアになって1ヶ月が経ちました

Webエンジニア キャリア 働き方

はじめに

今年5月からWebエンジニアとして働き始めたことを以前にブログでお伝えしました。

6月に入り、この1ヶ月でWebエンジニアとしてどんな働き方をしてきたかを簡単に振り返りたいと思います。

目次

配属先

私は6名ほどのチームに配属になりました。

配属後2, 3日程度の間はチームに以前から積み残っていた、比較的優先度の低い改修タスクが割り振られ、それらをこなしていました。

その後は、このチームが抱える7月リリース予定のプロジェクトにアサインされ、その開発を行っています。

仕事の進め方

プロジェクトにおいて開発が必要となる各機能は、GitHub上で一定の粒度でIssue化(課題として登録)されています。

(なお、プロジェクトによってはRedmineで管理されています)

配属当初はリーダーから各Issueを順次アサインしてもらっていましたが、現在は自分でIssueを選んだり、あるいは把握した要件をもとに自らissueを立てて自分自身にアサインしたりしています。

この辺り、ただ与えられたタスクを受け身でこなすのではなく、自ら考えて仕事を組み立ていくことになりますので、一定の裁量があって自分としてはとてもやりやすく感じています。

1日の仕事の流れ

現在はプロジェクトで「何を作るか？」がほぼ明確になっていることもあり、日々の大半はコードを書いています。

だいたい1日に3本程度のIssueに並行して取り組んでいる感じでしょうか。

ひとつのIssueに対するコードを書き終え、GitHub上でレビュー依頼をしたら、別のIssueに取り掛かり、依頼したレビューで指摘コメントが入ったら、今度はその対応に着手して・・・といった具合です。

コードに充分に触れたくてWebエンジニアという職種を選んだので、この環境にはとても満足しています。

なお、7月のリリースを終えて次のプロジェクトが始まったら打ち合わせの比重が高まるかもしれませんが、サービス作りの初期から参画できるので、それはそれで楽しみでもあります。

コードレビュー

書いたコードは、必ず別のエンジニアにレビューをしてもらうルールになっています。

正しく動きさえすればどんなコードでも良い、といったことは全く無く、 今後の保守のしやすさ、読みやすさなど様々な観点から適切なコードが書けているかが厳しくチェックされます。

厳しく、とは書きましたが、こうしたコードレビューから私が感じるのは「ダメ出し」のようなネガティブなものではなくて、より品質の高いものを皆で築き上げていこうという前向きなものです。

レビューが指摘無く一発で通れば、それはそれで嬉しいものなのですが、経験豊富なエンジニアからの指摘、コメントからは(その後ググって色々調べて得る知識も含めて)多くの学びがあります。

なので、(色々と指摘をさせてしまっているレビュアーには申し訳ない気持ちを持ちつつも)指摘、コメントがあれば「ラッキー！」と捉えて、指摘対応に取り組むようにしています。

なお、レビューでのコメント内容についても辛辣なものにはこれまで出会ったことは無くて、レビュアー側も充分に配慮してコメントしてくれているんだろうと思います。

今後について

1ヶ月を振り返ると、とにかくLaravel(PHP)のコードを書いていました。

Laravelに対する理解は以前よりぐっと深まり、それはそれでとても良かったのですが、裏を返すとLaravelの開発が必要となるIssueにばかり手を出していた、ということでもありました。

チームにはフロントエンド(Vue.js)のタスクもごろごろ転がっており、LaravelとVue.jsのどちらも書ける人が多数いますので、自分としても苦手意識のあるフロントエンドに手を出していかなければ・・・と思っています。

冒頭に

現在は自分でIssueを選んだり、あるいは把握した要件をもとに自らissueを立てて自分自身にアサインしたりしています。

この辺り、ただ与えられたタスクを受け身でこなすのではなく、自ら考えて仕事を組み立ていくことになりますので、一定の裁量があって自分としてはとてもやりやすく感じています。

と書きましたが、だからと言って、易きに流れてはいけませんね。。。

その他生活面

Webエンジニアの仕事内容そのものではなく環境面の変化で良かったことになりますが、出社時刻が柔軟なおかげで、こどもの保育園への送りを毎朝担当できています。

Webエンジニアは、他の職種と比べて勤務形態が柔軟なケースが多いと思いますが、こうした点も転職して良かったと感じています。

最後に

以上、Webエンジニアとなって最初の1ヶ月の振り返りでした。

Webエンジニアを目指している方の参考になれば幸いです。

そして

Webエンジニアとなって3ヶ月目にも振り返りレポートを書きました。

こちらからご覧ください。