Eloquent ORMについてなにも知らなかった(1) - 基本的な使い方編 -

先週に書いた記事で、Eloquent ORM(以下Eloquent)をライブラリとして導入する方法を書きました。

blog.zuckey17.org

この記事の中ではじめ、次のようなコードを書いてbooksテーブルについてBookクラスを作り全件を取得して表示しました。

<?php
// ダメなコードです

class Book extends Model {
    protected $table = 'books';

    protected $fillable = [
        'id',
        'isbn',
        'name',
        'author',
        'created',
        'updated',
    ];
}

===

$books = Book::all()->toArray();
foreach($books as $book) {
    echo $book['name'];
}

このコードは動いてはいましたが、2点の指摘をいただきました。

  1. toArrayするのはやめましょう
  2. table、fillableフィールドの指定はいりません。

非常にはずかしいことに、普段Laravelを書いて、Eloquentを使っているというのに知らないことがありすぎたので、本エントリではこれらの指摘とその他に調べた基本的だと思われることをまとめておきます。

以下で記載しているコードの省略なしは、

php-sandbox/basic-eloquent-usage at master · zuckeyM-17/php-sandbox · GitHub

にありますので、確認に使ってみてください。

指摘について

1. toArrayするのはやめましょう

eloquentのcollectionを利用するように変更 · zuckeyM-17/php-sandbox@029ad50 · GitHub

全件取得 ->表示するのは、以下のようにして書けます。

<?php

$books = Book::all();
foreach($books as $book) {
    echo $book->name;
}

Eloquentは、allgetのメソッドを利用するとCollectionクラスという便利なリストのインスタンスを戻してくれます。
例のようにforeachで回すと、単一のModelが取得できますし、Modelであれば、->でフィールドにアクセスできます。
toArray()を使うとそれらの恩恵に預かることができないので、ORMを使う旨味が激減します。

また、取得には、他にfindfirstlastなどのメソッドがあります。
それぞれプライマリキーで検索やlimitを書けているのですが、これらは単一のModelを取得することに利用します。

※ findの引数が配列になっている場合は、Collectionが戻ります。

2. table、fillableフィールドの指定はいりません。

不要なfillableとtableの記述を削除 · zuckeyM-17/php-sandbox@1e42688 · GitHub

tableフィールド

EloquentはActiveRecordパターンの実装*1 なので、1つのModelインスタンスは1テーブルの1レコードと完全に一致します。
そのため、テーブルの名前が複数形のスネークケースという慣例に則っていれば、EloquentはbooksBookモデルに紐付けるといったように、テーブルの指定を推測してくれます。

この他にも、connectionというフィールドも良く明示的に書いていましたが、DBが複数あるなどの特殊な場合を覗いてはDefaultの設定を見るため、指定する必要はありません。

fillableフィールド

fillableフィールドは悪意のあるユーザーがアプリが意図しない変更をDBに与えないように変更可能かどうかをカラム名ホワイトリストで縛るものです。

以下のようにfillableフィールドに指定した名前のカラムには、fill値を指定してレコードを作成することが可能です。
もし、指定されていたとしても、その値は無視されます。

<?php

class Book extends Model {
    protected $fillable = [
        'isbn',
        'name',
        'author',
    ];
}

===

$newBook = new Book();
$newBook->fill([
    'id' => 111, // 無視される
    'isbn' => '978-4-04-429201-0',
    'name' => '涼宮ハルヒの憂鬱',
    'author' => '谷川 流',
]);
$newBook->save();

同様の役割にguardedというフィールドが存在します。
こちらは、fillableとは逆でブラックリストです。変更されたくない値を明示的に指定することができます。

<?php

protected $guarded = [
    'created',  // createdをfillすることができない
];

その他の基本事項

ここから先は、指摘を受けてからその他に調べて、使ってはいたもののしっかりと理解していなかったり、知らなかったものなどについて紹介します。

ChunkとCursor

公式ドキュメントの以下の項目に記載のあったchunkメソッドとcursorメソッドですが、どちらも大量のデータを取得する際にメモリ使用量を抑える際に使うメソッドのようです。
https://laravel.com/docs/5.5/eloquent#chunking-results

ざっくりとした理解だと、

  • chunk => 複数回に分けてqueryを発行することにより、メモリ使用量を少なくする
  • cursor => カーソルによって1クエリで1行ずつデータを舐めることによりメモリ使用量を少なくする

こちらについては、僕自信の理解が曖昧なため、もう少し調べる必要があると思います。
詳しく理解されている方がいらしたら、コメントで参考サイトなど教えていただきたいです。

Chunk

<?php

Book::chunk(2, function ($books) { // 2冊ずつSQLを回す
    foreach ($books as $book) {
        echo $book->name , "\n";
    }
});

Cursor

<?php

foreach (Book::cursor() as $book) { // カーソルで1行ずつ処理をする
    echo $book->name , "\n";
}

上記どちらも、結果として全件の本のタイトルが表示されます。

Query Scope

クエリスコープはallgetメソッドを発行する際に、結果を絞り込むのに便利な機能です。

Global Scope

Global Scopeはその定義をそれぞれのModelのbootメソッド内にてaddGlobalScopeにて宣言すれば、すべてのクエリにて絞込みが利用できます。

<?php

use Illuminate\Database\Eloquent\Scope;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Builder;

class BookScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        $builder->where('id', '>', 2);
    }
}

===

class Book extends Model {
    ~~~
    protected static function boot()
    {
        parent::boot();

        static::addGlobalScope(new BookScope);
    }
    ~~~
}

===
$books = Book::all(); // idが2より大きい`Book`のCollectionを取得

また、addGlobalScopeで設定していても、

<?php

$books = Book::withoutGlobalScope(BookScope::class)->get();

とすると、絞込みを回避することもできます。

Anonymous Global Scope

こちらは、Scopeクラスを作らなくても、以下のようにbootメソッド内で絞込み条件を付け足すこともできます。

<?php

class Book extends Model {
    ~~~
    protected static function boot()
    {
        parent::boot();

        static::addGlobalScope('id', function (Builder $builder) {
            $builder->where('id', '>', 2);
        });
    }
    ~~~
}

Local Scope

Local Scopeは各Modelに定義します。 scopeというプレフィックスをつけてpublicなメソッドとして宣言し、クエリを引数に取って、決まった絞込みを利用できます。

<?php

class Book extends Model {
    ~~~
    public function scopeRecent($query) // scopeはプレフィックス、recent()というメソッドがqueryBuilderで使えるようになる
    {
        return $query->where('id', '>', 3);
    }
    ~~~
}

===
$books = Book::recent()->get(); // idが3より大きい`Book`のCollectionを取得

Dynamic Scope

Dynamic ScopeについてもLocal Scope同様各Modelに定義します。 Local Scopeの定義に引数を増やして、絞り込む値を利用時に入れることができます。

まとめ

  • 前回のブログについて指摘していただいた実装を見直し、調査しました
    • ブログを書くことで改善できてよかったです!
  • その他にもEloquentの知らなかった基本的な機能がたくさんあったので、まとめて、自分で書いてみました
    • まだ基本の「き」なのでこれからも少しずつ調べていこうと思います

次回はCollectionの様々な使い方、Eventあたりをやりたいです。

ピュアなPHPアプリケーションにLaravel標準ORMのEloquentを導入した

本エントリでは、ピュアなPHPで書かれたWebアプリケーションにLaravel標準のORMであるEloquentを導入した際にやったことを簡単にまとめています。

実施した際はPHP5.6でしたが、学習のためも含めて本エントリ内のソースコードはPHP7.2で動作させています。
経緯でも書かせていただいていますが、データベースはSQLite3を使っていますが、macOSで動かす場合にはすでにインストールされていると思うのでsqlite3 -versionで確認してから動かしてみてください。

経緯

事前に、Eloquentを導入するに至った経緯を簡単に説明しておきたいと思います。

SQLite3をデータソースにしたレガシーなプロジェクト

あるプロジェクトが素のPHPで書かれています。すべてのAPIがその1つのモノリシックなPHPアプリケーションとなっています。
ここで問題となっているのが、データベースとしてSQLite3を利用していることでした。
SQLite3はデータベースをファイルとして扱うため、

  • ファイルI/Oが遅くなる
  • サーバの分散ができない

という問題を抱えています。
また、行ロックではなくテーブルロックであるため書き込みが多いようなアプリケーションには向かない、という問題もありました。
嬉しいことに、サービスの成長によってサーバをスケールアウトできるようにしてリソースに余裕がほしいという要望が出てくることになりました。

Laravelへの移行は一朝一夕ではできない

ほかのプロジェクトではLaravelを利用しており、データベースは一部SQLite3を引き継いでいるものの、多くはMySQL(AWS Aurora)です。
ただ、前述のアプリケーションの大きさゆえに、Laravel + MySQLへの移行はすぐには難しく、まずは、MySQLへの移行をする準備として、Laravel標準のORMであるEloquentを既存のコードに入れていくという運びとなりました。

クライアントごとにSQLite3のファイルが異なる

また、管理していたSQLite3のファイルは複数存在しました。
グローバルな情報を扱うアプリケーションに唯一のデータベースと、クライアントにつき幾つか存在するデータベースがあり、リクエストの方法によって、クライアントごとに書き込みや参照をするデータベースを変えるということをしていました。
今回は、こちらの話には触れず、Eloquentの導入部分のみを書きます。
こちらの話も今後別記事として書きたいと思います。

やったこと

あとは淡々とやっていったこと、その際に調べたことを書きます。

※ 簡単な例を用意しました。
https://github.com/zuckeyM-17/php-sandbox/tree/master/use-eloquent-at-pure-php-app

4ステップでできます。

  1. PHPのバージョン管理ツールであるcomposerをインストール
  2. illuminate/databaseというパッケージをインストール
  3. illuminate/databaseの設定
  4. 必要なEloquentモデルを作成

1. PHPのバージョン管理ツールであるcomposerをインストール

$ cd ./src
$ curl -sS https://getcomposer.org/installer | php

用意した例では、環境を汚さないようcomposer.pharというファイルをsrcディレクトリ直下にダウンロードするという方法を取っています。

2. illuminate/databaseというパッケージをインストール

$ ./composer.phar require illuminate/database

ステップ1で用意したcomposer.pharを利用して illuminate/databaseというパッケージをインストールします。
Larvelを構成するライブラリはすべてgithubilluminateというところに所属します。
そこでdatabase部分を担当する、illuminate/databaseをインストールするわけです。

illuminate/databaseのREADME.mdの日本語訳が見当たらなかったので、和訳しました。

3. illuminate/databaseの設定

ほぼ、illuminate/databaseのREADMEを読めば簡単に作ることができます。
READMEではデータソースがMySQLだったため、例ではSQLiteで指定しました。
SQLiteで必要な項目は、ファイルへのパスのみなので簡単です。

<?php

use Illuminate\Database\Capsule\Manager as Capsule;

$capsule = new Capsule;

$capsule->addConnection([
    'driver'    => 'sqlite',
    'database'  => SRC_DIR . '/app.db',     // ここにSQLiteファイルへのパスを入れる
]);

$capsule->setAsGlobal();
$capsule->bootEloquent();

4. 必要なEloquentモデルを作成

illuminate\Database\Eloquent\Modelというクラスを継承したモデルクラスを作成します。
EloquentはActiveRecordの実装となっているため、Modelクラスはテーブルについて1つ作成し、Modelクラスに生えた便利なメソッドでテーブルにアクセスすることができます。
最低限な実装をすると以下のようになります。

<?php
require_once dirname(__FILE__).'/database.php';
use Illuminate\Database\Eloquent\Model;
class Book extends Model {}

これで、Bookモデルがアプリケーションで使えるようになりました。
以下ではBookの中身を取り出して表示しています。

<?php
define('SRC_DIR', dirname(__FILE__));

require_once(SRC_DIR . '/vendor/autoload.php');
require_once(SRC_DIR . '/database.php');
require_once(SRC_DIR. '/Book.php');

$books = Book::all();

foreach($books as $book) {
    echo $book->isbn, "\t" , $book->name, "\t", $book->author, "\t", $book->created, "\t", $book->updated, PHP_EOL;
}

まとめ

Eloquentをライブラリとして導入しました。
illuminate/databaseというパッケージを入れることで可能でした。
ただ、 illuminate/database単体では、マイグレーション周りをサポートしていないらしく、今回のユースケースでは既存のテーブルに対して行うということだったので、ただ純粋にEloquentをライブラリとして使うということを目的とすると、調査が甘かったようです。
EloquentのModelは便利なメソッドがたくさん生えているので、そちらについても今後紹介して行こうと思います。

また、illuminateなどOSSとしてのLaravelのプロジェクトについて少し知識がついたので、これからもう少しソースコードをしっかり追っていきたいなとも思いました。

間違っている部分、この施策についてのフィードバックなどありましたら、いただけると嬉しいです!

2017年を読んだ本とともに振り返る

僕が2017年の1年間で読んだ本をベースに一年を振り返ります。
書評メインではなく、あくまで個人的な振り返りになります。
が、基本的に駆け込みでざっと書いているため、まとまりの無い文章になっております。ご了承ください。
また以前、本ブログのTech系Podcast『しがないラジオ』をはじめて変わった5つのことというエントリにて、

パーソナリティの間でも議論し、積極的に本を読んでその報告をすることにしました。 結果、技術書を1ヶ月に2~3冊くらいのペースで読むようになりました。

と書いてしまったので、おそらく6月くらいだったとは思いますが、それ以降で実際に読めているのかを確認するためにもこれを書こうと思います。*1

振り返り、という名目なので、途中でやめてしまったものについても、言及します。

最後に、リンクはアフィリエイトリンクになっています。2018年の書籍購入の助けになれば本当に嬉しいので、もし興味をお持ちの本があればこちらから購入していただければ嬉しいです。

1月

はじめてのAndroidアプリ開発 第2版 Android Studio 2対応

Urban Data Challengeという地方自治体を中心とする団体が公開している公共データを活用してアイデアやサービス、プロダクトを作り、競い合うコンテストがあり、僕は友人たちと出場しました。
1月末のプロダクトの提出期限に向けてAndroidアプリを作成しました。Androidアプリは書いたことはなかったですが*2Javaは新卒の研修で3週間ほど学習したため、この本さえ読めば大丈夫なのでは、という話になり年末年始を使って読みました。

できたアプリはこちらです。 histleap -タイムリープ型観光アプリ- 1次審査であえなく敗退したため、このアプリについての詳細は省きますが、Androidアプリを初めて作ってリリースできたのは良い経験だったと思います。 また、

をしっかりめに追うことができたのでそれも良かったです。

この本については、ページ数もある程度ありますが、コード例が豊富にあってAndroidアプリについて順を追って解説してくれているので分かりやすかったのではないかなと思います。
完全に初心者向けのため、少し冗長で簡単なのでは?という部分もあるので、少しでも触ったことがある方はつまらないと感じられるかもしれません。

2月

JavaScriptで学ぶ関数型プログラミング

2月時点で業務ではReactを利用したフロントエンド開発を全体の半分ほどの割合で担当していました。
もう少しJavaScriptについて詳しくなりたいと漠然と思っていた僕は会社の本棚にあったこの本を手に取りました。

第一級関数や高階関数という言葉の存在すら知らなかった僕には、この本はかなり難しいものだったように思います。
実際今何がかいてあったかを詳細に思い出そうにも思い出せない程度には理解できなかったので、もう一度読んでみるのもありかもしれません。

3月

Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門

前述の通り、Reactを業務で書いており、2月初旬にできた未経験エンジニアの後輩がReactをやる、ということだったのでこの本を会社に買ってもらって先に読んでおきました。
簡単な表アプリを作ったりするので、Reactの概要をつかむには良い本でしたが、JSXを使わずにcreateClassを使ったりとすでに古い記述がありました。
この辺の本をやってようやく、"React周りのみについては"少しはできるようになったんだなという自覚を得ることができました。

ちょうどこの本は僕が2017年最もお世話になった勉強会であるWe Are JavaScripters!さんのもくもく会に参加した日に発売され、Reactの話をその場でしたことも相まって3月末の人生初LT登壇につながりました。

Reactつながりでいうと、その他にも、React Nativeを、同じくしがないラジオのパーソナリティであるid:jumpei_ikegamiと学習し、錯視を利用した簡単なアプリを作成しました。
React Nativeについては、5月くらいに勉強会にも参加しましたが、書いたのはこれきりでした。 ReactのLearn Once Write Anywhereを実感できたという点で良かったなと思います。

そして3月はPodcastしがないラジオを始めた月でもありました。

4月

なぜ、この人と話をすると楽になるのか

この時期、外部連携などの仕様を詰めたりと他のビジネスサイドの方々と話をする機会が増えてきていました。
前職では、部門や会社をまたいだコミュニケーションが多かったにも関わらず、エンジニアとしてコードを書く、ものを作るようになった自分は、ビジネスサイドの方々とうまく話せない、という問題に当たりました。
そこでとりあえず尊敬するラジオパーソナリティの1人である日本放送アナウンサー吉田尚記さんのこの本を手に取りました。
実際、この本の中では、雑談をある種のゲームと考えて、自分を捨てて話すということが書かれており、確かに普段あまり関わりのない他部署の方と、業務外で話す際に相手が気分が良くなるような話し方をすることは、仕事上重要なコミュニケーションを円滑に回す上で必要なことで、そのコミュニケーションをルールのあるゲームという風に考えてしまうと、ゲームを攻略するために動いてコミュニケーションを成功させる、ということはできるのではないかな、と思いました。
これは現在もまだまだ完全に実行できてはいませんが、これからも意識することになるだろうと思います。
しがないラジオでも、ep.7 楽しい雑談で紹介しているので、ぜひ聞いていただければと思います。

これと同時期に仕事ができる人はなぜモチベーションにこだわらないのかを購入しました。
こちらは半分程度しか読めていないのですが、この購入履歴を見た母*3から「大丈夫か?元気にしているか?」と電話がかかってきたのを覚えています。

Electronではじめるアプリ開発 ~JavaScript/HTML/CSSでデスクトップアプリを作ろう

Reactをやっているということもあって、業務の幅が何か広がるのではないかと思い、購入して読みました。
この本はElectronの本と書かれていますが、Reactの小さな良いサンプルが詰まっている本と考えたほうが良いでしょう。
Electronについても書かれていますが、あくまで入門書で、多くは書かれておらず、何かプロダクトで作ろうという際には公式ドキュメントなどを読む必要があります。
この本を読んで簡単な社内ツールを作ってみました。
Electronは、普段フロントエンドをやっているならば、簡単にGUIを作れるので、ビジネスサイドに感謝されるツールを短期間で作るのにはちょうど良いかなと思います。

5月

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く

ゴールデンウィークに読みました。
普段はPHPのEloquentというORMを利用して簡単なクエリを発行していたり、Sequel Proを用いてMySQLに対してクエリを実行したりしています。
サーバーサイドを書いているならSQLくらいまともに書けない*4といけないだろうということで、評価の高かったこの本を読みました。
巷では「10年本」と言われているようです。
本の概要としては、対象読者はリテラシー高めなビジネスサイドから初級アプリケーションエンジニアなどで、分析の話に絡めて参照系のクエリの基礎から応用までを紹介しているという感じです。
「この商品買った人はこれ買いがち、みたいな分析とかやりたいよね?こんな感じで書くんだよ。さっき紹介したこれとこれを組み合わせて」みたいな感じでかかれていてどういうタイミングで使うのか、を意識して学習することができるので、かなり良かったと思っています。
PosgreSQLを対象に書かれていますが、途中のウインドウ関数以外は、MySQLでもほとんど問題なく使える内容だと思います。
この本を読んで、SQLチョットカケルくらいには成長したと思います。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

5月10日にあったReact反省会にてサイボウズの方がReactを導入するのを会社に広めるという話で紹介されていたのがきっかけで知りました。
僕もエンジニア歴の浅い人間がエンジニア組織、ひいては会社に対してどうやって影響力を持っていくかについて考えないことはなかったので、読みました。
ダラダラと読んでしまったので、結局1ヶ月時半くらいかかってしまいました。
何かを組織に導入するときに必要な48のパターンがエピソードと共に紹介されています。
1つ1つが当たり前のようで実践しきれないことが書かれていていい本だと思いました。*5
常に意識することはなかなか難しいなと感じましたが、時々、今のあの本のアレじゃね?というと気があると嬉しいです。
部内でのKPTのときに一度実践したのですが*6、「何か食べながら」というパターンはすぐに使えておすすめです。
僕がよく聞くPodcastである #omoiyarifmでもコーナーとして、各パターンを紹介されています。

6月

成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

プロジェクトの失敗はだれのせい? ~紛争解決特別法務室“トッポ―”中林麻衣の事件簿

対個社の仕事はこの時期も続いており、かなり大きなクライアントの仕事が入る気がしたので、契約について学びました。
「あまり受託開発的な仕事をしたくないな〜」と思って事業会社に入ったのでこういうことに手をだすとは思っていませんでしたが、契約とか法律についてよりも、結局は顧客とよく話して良いものを作る、何か不具合があったときは迅速に誠意を持って対応することが重要、ということがどちらの書籍にも書いてあり、そうだよなあと思うと同時に事業会社にいるエンジニアはそのあたりを少し忘れてしまうこともあるかもなという反省があったことが一番良かったと思います。
しがないラジオでも、ep.15 楽しいエンジニアのIT契約入門で紹介しているので、ぜひ聞いていただければと思います。

エラスティックリーダーシップ ―自己組織化チームの育て方

この本は途中で読むのをやめてしまいました。 このブログでもまとめを書いたまつもとゆきひろさんの"若手エンジニアの生存戦略"という勉強会で紹介されていたので購入しました。
雑な感想とメモ【まつもとゆきひろ氏特別公演】若手エンジニアの生存戦略 @DRECOM #colab_matz 20170520

まえがきにもある通り、序盤でざっくりとしたこの本の考えが書かれており、それを読んで少し進んだところで脱落してしまいました。
その後は第6部にて、日本人の有名エンジニアによるエッセイが紹介されているので、時々つまみ食いする、という感じで楽しんでいます。

サバイバルフェーズ、学習フェーズ、自己組織化フェーズ、などチームの状態を言語化して述べてくれていて、そういう考え方はいいなと思いました。
リーダーだけでなく、チームのメンバーもそのチームの状態によって振る舞いを変える必要があるんだなと思うと同時に、それができるのはかなりモチベーション高く、実力がある水準以上で周りで起こっていることが俯瞰できている状態だけなんだろうな、とも思いました。

ZERO BUGS シリコンバレープログラマの教え

こちらの本も2割くらいで読むのが止まってしまいました。
エンジニアとしての様々な心構えが書かれた本、ということで読まなくてはと思い購入したのですが、例えがよくわからなかったのか、語り口が合わなかったのか、あまり面白くなくやめてしまいました。
すべて読んでいないので、なんとも言えませんが、リーダブルコードなどを読むので十分では?と思いました。

5、6月のブログ活動について

5、6月では、自分が参加した勉強会について、まとめと感想をなるべく早く書いてブログにするということを数回しました。
やっていると、公開するのが早ければ早いほどリツイートしていただくことも多く、それだけで承認欲求が満たされるような気持ちになりましたが、メモを取ることに必死になって重要なことを聴き逃しているような気がすることと、あとで公開してくださるスライドのコピーを取ることにあまり意味を見いだせずブログの内容も薄くなってしまうと思ったのでやめることにしました。

7月

食べる!SSL! ―HTTPS環境構築から始めるSSL入門

SSL?なにそれ美味しいの?という状態だったので、読みました。美味しかったと思います。
会社の先輩と話をしていたとき僕がちんぷんかんぷんなことを言い出したときにこれを勧めてくださいました。
amazonのレビューにもある通り、初学者には非常に読みやすく簡単にSSLのことを解説してくれています。
安いですし、分量も多くないので良かったと思います。

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

こちらのcommpassで公開されていた書籍プレゼント企画にて見事当選したので、読んで、しがないラジオでフィードバックしました。(ep.19 楽しいSPAとサーバーレス)
サーバレス、SPAというトレンドをおさえていて、2017年多く売れた技術書の1冊だと思います。
ピュアなjQueryで画面を作りつつ、Jasmineでテストを書きつつ、AWSのサーバレスなサービスを理解しつつと、1冊で多くのことを学べる本でした。
業務でフロントエンドの開発をしているとはいえ、ES6で書いたReact.jsしか経験がなかったため、jQueryで1からSPAを構築していく、さらにJasmineでUIのテストも書く、というのは面白く読み進めることができました。
また、AWSのいろいろな機能を簡単に使うというところで、ざっくりとした概要をつかめたことも良かったです。

またポッドキャストの中での発言を監修されている方に取り上げていただきました。

特にポッドキャストでは「雑にアウトプットする」というのを意識的にやっていますが、それによって良い学びが得られた素晴らしい体験だったと思います。

8月

Guide to ScalaーScalaプログラミング入門

社内で、PHPで書かれているサーバーサイドを徐々にScalaに移行したいという話が、2017年の年始より出ていました。
年始から主要なメンバーの転職もあって難しかったのですが、そろそろ本格的に考えるか、となったのでこちらの本を読みました。
Scalaといえば、コップ本がバイブルとして有名ですが、まず初心者が簡単に触る分にはこちらの本は分量的にも値段的にもちょうど良かったように思います。
ざっと書きつつ読みましたが、結局2018年1月現在で社内のScalaのプロダクトコードは1行もなく、PHP5.6 => PHP7.2移行を進めよう、という段階なので違うパラダイムの言語の学習ができてよかった、くらいの気持ちでいます。

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

4月に「なぜ、この人と話をすると楽になるのか」を読んでから、コミュニケーションに対してある種ドライなスタンスの取れる、"清濁併せ呑める"ような人間になりたいとぼんやり思っていて、この本がamazonで目に入ったので購入しました。
ただ、この本はある程度大企業の中間管理職、30代後半から40代をターゲットに書かれた本のようで、組織をまたいだ人脈の作り方、チーム運営時の判断の方法論などが書かれており自分が求めているものと少し違うな、というふうに感じて6割くらい読んだところで脱落してしまいました。

9月

ザ・コーチ

こちらの本は、しがないラジオのep.20 楽しい!?目標設定のエピソードに対して、リスナーのid:tbpgr さんがフィードバックとして紹介してくださった本でした。
はじめは、会社の目標設定が難しいということを話していましたが、自分のエンジニアとしての目標にも話が広がりました。
この本は目標、目的、夢、ビジョン、ゴールといった、違いが曖昧な言葉たちについての詳細な説明から始まり、それらを決めていく過程、決めてから実行する過程を小説ベースで読者に伝える自己啓発本です。
読んだ感想などをep.25 楽しいエンジニアがマネージャーをやる理由で話しています。

2017年は、インプットもアウトプットもそのときどきの流れで無計画に行ってきましたが、より大まかな進みたい方向をしっかり決めていきたいと思っています。
本当にそんなことできるのだろうか、と思ったりしますが、確かに周りにできている人はかなりいます。
2018年はよりそれをより明確に描けるようにして、第1歩が踏み出せれば良いかなと思います。

わかばちゃんと学ぶ Webサイト制作の基本

LT loversというイベントで知り合い、そこからしがないラジオでもゲスト出演していただいている湊川あい(Twitter @llminatoll)さんの本です。
普段からエンジニアとして仕事をしているので対象読者ではありませんでしたが、出演してくださるということで予習として読みました。
Webサイトを制作、運用するための必要な知識がマンガでわかりやすくまとめられていて、初心者の方が概要をつかむにはすごくいい本だと思いました。
特に、文字でわかりづらいポイントを絵で理解できること。ただ単に作るというだけでなく何のために作るのかを考えることが必要だ、と説明してくれていること。が非常に良いなと思いました。

どのような思いを持って書かれたか、著者の湊川あいさんがどのような人柄なのかについては、

で語られています。

10月

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

こちらも湊川あいさんの本で、Gitの初心者のための本でした。僕は普段からGitである程度のことは自分で調べつつできていたため、対象の読者かというとそうでもないかなという感じでした。
しかし、この頃、社内のデザイナーの方がHTML、CSS、JSなどのコーディングもチャレンジするということで、フロントエンドを担当していた僕がGitについての質問を受けるが多くなっており、この書籍を購入し、その方に読んでもらうことにしました。
すると、瞬く間にある程度のことは1人で問題なくこなせるようになっていました。
僕も経験がありますが、Gitは少ししか触っていないとオーバースペックに感じることがあったり、概念的に字面だけではわかりづらい部分があったりするためマンガというアプローチはすごくいいなと思いました。
すすめるにあたり僕も読みましたが、rebaseなど、必要なときに調べ、理解もそこそこに忘れてしまうことなどがあったので、これ一冊で業務で使えるレベルになる良い入門書だなと思いました。

テスト駆動開発

普段聞いているPodcastである#ajitofmのAjitofm 6: Worse Is Betterajitofm 13: Test Driven Developmentにて訳者のid:t_wadaさんを交えて紹介されており、それを聞いて読みました。
それまで、ユニットテストはなんとなく書いていましたが、実際それが意味のあるものなのかわかりませんでしたし、それによって救われたなということも特になく、よくわかっていませんでした。そういうことへの理解が深まるのだろうなと思って読みました。
しかし、この書籍を読んでから理解ができたのは、ユニットテストが意味のあるものなのか、とか、テストによって変更を加えた際のミスに気づいて救われた、などはテスト駆動開発の目的とは違うのだということでした。
僕の理解ではテスト駆動開発で重要なのは、機能追加の前にテストを書いて、追加する機能について考察し理解し設計する、ということなのだと思いました。
そういう意味で、僕の当初の期待はうまく満たされませんでしたが、 id:t_wada さんの推奨する写経の方法をいい感じに実践できたりすることができ、楽しく読み切ることができました。

この辺の話は、ep.28 楽しい『新訳版・テスト駆動開発』の読み方でも話しています。

11月

Java言語で学ぶデザインパターン入門

しがないラジオでは10~12月とゲスト回が続き、多くの方がこの書籍を紹介されていました。
業務などでも「デザインパターンでいうアレだよ」、みたいな会話があり、読むとより実のある議論ができるのではないかと、購入し読みました。
はじめの3章は、前述の通りの写経をしたのですが、他の本も読みたいなということで、それ以降はざっと読むことをしました。
すでに読んだことのあった同僚と話すときに意識して「ファクトリーで」などと会話してみることでパターン・ランゲージの強さを認識することができました。

nginx実践入門 (WEB+DB PRESS plus)

業務でnginxを触る必要ができたので急ぎ購入しざっと読みました。前半特にリファレンス的な要素が強買ったため、あっさりと読み、触りつつわからなければ参照するという読み方をしました。
nginxについてまとまりがって読みやすい日本語の本はこちらくらいなんじゃないかなと思います。
今まではすでにあったnginxの設定を見てもわけがわからず、そのあたりで何か不具合があっても手も足も出ないという感じだったのですが、読めるようになり、怖さがなくなったのが良かったです。
業務では、アプリケーションの状態によってリクエスト先のサーバを変えるという処理を今回の実装でnginxの役割として実装しました。
その部分がnginxでやるべきことなのか、アプリケーション側でやるべきことなのか、ということが未だによくわかっておらず、そのへんも今後学習していきたいです。*7

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

こちらも、上記のnginxと同様に必要に迫られたので会社の本棚から借りて読みました。
しかしながら、元あったChefのコードをベースに書いたため、公式サイトで事足り、導入部分のみ読みました。

まとめ

12月はふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道を読み始めましたが、いろいろあって、全く進めることができませんでした。
1月上旬でとりあえず読みたいです。

これまでざっくり2017年に読んだ本を振り返りました。
インプット量は思っていたよりも少なく、少しがっかりしました。
また、学んだことについて思いのほか忘れていることが多く、Podcastだけでなく、文字でも一冊一冊でまとめておこうと思いました。 振り返りは、途中でも書きましたが、以下に尽きるのかなと思います。

2017年は、インプットもアウトプットもそのときどきの流れで無計画に行ってきましたが、より大まかな進みたい方向をしっかり決めていきたいと思っています。 本当にそんなことできるのだろうか、と思ったりしますが、確かに周りにできている人はかなりいます。 2018年はよりそれをより明確に描けるようにして、第1歩が踏み出せれば良いかなと思います。

とりあえずまとめたので、もしかすると読み返して追記するかもしれないです。

*1:この言及はかなり微妙で、技術書以外を含めても振り返るとそこまで読んでませんでした。すごい、とおっしゃっていただいた方が何人かおられたのに本当に申し訳ないです。

*2:というかその当時Android端末を持ってすらいませんでしたが

*3:母は僕が昔使っていたkindle保有しているので僕が買った本は全て知っている

*4:いや~な苦手意識、ありますよね?

*5:いい本はそういうのが散らばりがちじゃないですか?

*6:続いていないです

*7:今回はもろもろの事情によりアプリケーションに手を入れないでなんとかするという制限がありました。

実データで学べるRedashハンズオンをやってみたら完全に求めていたものだった

Redash?

RedashとはさまざまなデータソースからSQLなどのクエリを駆使してデータを取り出し、グラフやレポートをGUIで作ることのできるオープンソースのツールです。
Webエンジニアをされていれば、いい感じにデータを抽出してほしいという依頼が飛んできたりすることもあるのではないでしょうか?
Redashでは実行したクエリを保存して別の人が違うタイミングで実行したり、ダッシュボードにまとめてレポートを作ったりすることができるので、その辺の要求に簡単に応えられるようになるのではないかと思います。

Redashハンズオン?

この記事のタイトルにもありますRedashハンズオンid:kakku22 さんが作られているもので、ハンズオン中で使うデータを含め環境構築まですべてが書かれています。
MacでもWindowsでも問題なくできるそうなのでこれも嬉しいなと思いました。

動機

どのくらいの知識量なのか?

僕自身、SQLはふつうに書ける(チョット調べたら複雑なものも書ける)くらいです。
また、今回紹介するハンズオンではDockerで環境構築を行っており、僕のDockerの基礎知識は限りなく0でしたが、全く問題なく最後まで終えることができました。

なぜこれなのか?

Redashについては以前から知っており、会社でも溜まってきたデータをそろそろ可視化して次の施策につなげたいなどの要求が高まってきたこともあって「自分で使ってみよう!」と思ったこともありました。
使ってみよう、と思ったはいいものの、公式の解説ページであるSetting up a Redash Instanceからいろいろやってみたのですが、何故か*1うまくいかず、Redash怖いという印象で終わってしまっていました。

id:ariarijp さんとid:kakku22 さんが主催でRedash Meetup #0 - Redash 初心者向けハンズオンを開催されるとのことをconnpassのサイトから知り、ハンズオンならやれそう!と思って申し込んだものの業務都合で参加できなくなりました。
一度やる気が出たのでこれを逃す手はないということで、公開されている資料を見て実行に移しました。*2

スクリーンショット 2017-12-29 12.25.20.png (69.5 kB)

内容

実際の内容について、詳しくは元の資料を参照してください。

Dockerのインストール、環境構築から、基本的な操作

環境構築から基本操作が出来るようになるまでの流れが一通り体験できます。 基本的な操作とは、

  • クエリ作成
  • グラフ作成
  • ダッシュボード作成

のことを指しています。 Redashは基本的に使う分にはすごくシンプルなので、簡単なSELECT文が書けたらこのあたりは2回目何も見ずとも実行することができると思います。 僕は普段、MySQLのクエリを探索的に使う際にはSequel Proを利用していますが、それよりもSQLの補完がいい感じに効いていて楽に書けるなと思いました。 これはチームで触る際に、特にBizDevの方々に触り始めてもらうに当たってすごく良いことだと思います。 一部補完が強すぎて、Enter Keyを押すときに違ったクエリになってしまうことがあり、行末に空白を打つという工夫によって回避していたりしました。

クエリ操作をサポートする機能を使ってみる

SQL文を書く際に、上記の機能だけで言うと、Sequel Proなどでもできますが、こちらで紹介されている - パラメータ付きクエリ - フィルタ - クエリスニペット - クエリに色を付ける

などの機能を利用すると、より快適なSQL生活ができると感じました。 普段は、Google 日本語入力を使って、よく使うSQLを出力したりしていますが、クエリスニペットを使うとそこも覚えなくてすむのでコストが削減できますし、チームの知見を共有できるという意味ではすごく良いと思いました。

フォーク、リンク集作成、結果のダウンロード、アラート通知などの機能の紹介

簡単ではありますが、これらの発展した機能にも触れられていました。
特にアラート通知機能は革命的に便利で、Slack通知をいとも簡単に実現できました。
コードをわざわざ書いて、cron回してということをしていましたが、GUIで作成からメンテナンスまでできるので、楽に評価高くできそうですね!

その他、自由課題

また、ミートアップの発表資料を見ると早く終わった方のための自由課題がありました。
そちらもやってみると、先程も書いたとおり基本操作はすんなりできたので、自分ひとりでも簡単に最後まで終えることができました。
振り返り記事では、追加演習も紹介されており、admin周りのページも一通り目を通してみました。
同じく紹介されているGoogle Spreadsheets連携についても、社内便利ツールとして使い所がかなりありそうなので、次に学びたいなと思っています。

まとめ

Dockerをやってみたら意外と楽にできた

おまけチックですが、Dockerについて少しだけ耐性ができました。
「Dockerよくわからん」という状態で、以前にRedashを試そうとしたときもAWSを選択してしまっていました。
今回Dockerを入れて触ってみて、*3特に問題なく環境構築できたので、Dockerいけるんじゃね感が高まってきました。そういう意味でも0からとりあえず1まで動く前提で工程が記されているハンズオンって偉大だなと思いました。

実際の業務でチームに導入していこうと思う

実際にやってみて、これならお試しでチームに導入できそうだなと思いました。
そういえば、つい最近BizDevの方が、「クエリ触れる用になりたいんですよね」的なことを話されたので、年始に導入やれるんじゃないかと思いました。

ただ、実際運用する際にDockerでいいのか?
など、あくまでハンズオンでわかりやすくしてくださっていた部分で嵌りそうなので、その辺を公式ドキュメント読みつつやってみようと思います。

初心者向けハンズオン再演があるようです

一回目のハンズオン回の再演があるそうです。
こちらから申し込むことができるので興味がある方は是非行ってみてはいかがでしょうか?*4 redash-meetup.connpass.com

*1:春頃なので詳細には覚えていないですが

*2:その週ではできませんでしたが...汗

*3:あまりわからないながらも

*4:すでに定員オーバーしていますが、1月末なのでキャンセルも見込めると思います

ajitofm忘年会に参加してきました

僕が普段聞いているajitofmというPodcastの忘年会が開催されていたので、参加しました。

connpass.com

このエントリでは、ajitofmの紹介と今回開催された忘年会の感想を書こうと思います。

ajitofm

ajitofmはsuzuken id:suzu_v さんがホストとして、VOYAGE GROUPさんの社内バーであるAJITOでの*1エンジニア同士の語らいを収録し、公開されているPodcastです。 *2

Tech系のPodcastといえば昨今幅が広いですが、比較的技術的な話が多く、基本的にはVOYAGE GROUPの方々がお話しされています。

またVOYAGE GROUPの外からゲストがいらっしゃっているときにはそのゲストの色が色濃く出ているように感じるので、 id:suzu_v さんの回し力が垣間見れます。

言語としては、普段書かれている(らしい)PHPやGOの話が多く、インフラ環境や機械学習的な話?もあったりします。

僕とajitofmとの出会い

普段からTech系のPodcastをよく聞きますが、ajitofmと出会ったのは7月の上旬でちょうど2エピソード目がリリースされた直後くらいだったと思います。新しいPodcastを探していて偶然発見してから毎回欠かさず拝聴しています。

僕は現在でプログラミングを始めて1年半足らずと日が比較的浅いほうですが、おそらく普通に話されていたらわかりづらいだろうなという点もしっかり言葉を割いて話してくださっているように感じ、優しいPodcastだなという印象を受けました。

ajitofm忘年会

さて、忘年会はもちろんAJITOで行われたわけですが、僕は19時が定時だたっため遅刻して参加しました。*3

するといきなりid:suzu_v さんによる開会の挨拶らしきプレゼンが入ります。

本当に間に合ってよかった。

個人的には、PodcastsConnectによるリスナー数の分析や離脱率のグラフが面白かったのと、ajitofmのページhttps://ajito.fm/ で少々レスポンシブがうまくいっておらず、id:suzu_v さんがCSSが苦手とおっしゃっていたのが新鮮で良かったです。(スライドはたぶん公開されていないのでURLはありません)

suzukenさんと話した

到着からいろいろな人と話すことができましたが、特に印象に残ったことでいうと、やはりsuzukenさんとお話ができたことがあります。

普段からPHPを書いていたり、記憶に新しかったりと、特に最新2回の話をして、それについてや、それについて思ったことを交えて感想を 話した伝えたように思います。

注意 以下技術的な内容も含まれますが、あくまで話を聞いた僕の解釈となっています

あまり楽しいとは言えないプログラミングも業務ではあるんだよという話

エピソード16で機械学習の進歩によって人間がプログラミングをすることがなくなるのではないだろうか、というような文脈の話をされていました。

一度考えたらあとは作業になってしまうような、機械にやらせたいプログラミングはある、ということの例として、PHPのバージョン5.6から7.2への移行作業を挙げられていました。

僕は最近業務で、*4既存のPHPのPDOを使ったSQL文をEloquent*5のモデルを導入することで移行するといった作業をしています。 この作業自体は本当に考えることは少なく、ただ変更していくというもので、楽しくないな、辛いなと思っていました。

そして、このエピソードを聞いて、suzukenさんでもそういう作業をしているんだ! という風に励まされ、嬉しかったという話をしました。*6 jQueryで書かれた古いコードのメンテをすることもある、であったり、関連する話が盛り上がってすごく良かったし、勇気をもらうことができました。

設計の悩みから、アドバイスを受けてうれしかった

↑の流れでもう1つ自分が最近抱えていたDB設計についての悩みについて相談しました。 状態を管理をビットフラグで行っているものが複数箇所あり、パッと見でわかりづらく、コード変更が怖いといった相談をしました。 すると、その「状態」が、順番のあるものなのか、そうでないものなのかによって、enumなどで1カラムで管理するものと、すべてのビットをカラムに分ける方法とが考えられる、といったアドバイスをいただきました。

そういうふうに分けて考えるのか、と勉強になったことだけでなく、こういった日々の悩みをしっかり聞いてもらえて、的確なアドバイスまでいただけたことが嬉しいなというふうに感じました。

その他にもいろいろな話を聞いていただき、ajitofm忘年会の主催を独り占めしてしまった感のある時間帯を作ってしまって少し反省しましたが、それでもすごく良い経験ができて本当に楽しかったです。

そして、こういった設計についての悩みはいろいろな部分で存在し、僕自身日々不安に思っていたため、このような話を、レベルはもっともっと高いと思いますが、たくさんのエンジニアが就業後日常的にされているらしいAJITOという環境は本当に素晴らしいんだろうなと思いました。

その他感想

たくさんの方とお話できましたし、プレゼント企画もあって、ajitofm忘年会本当に楽しかったです。 何より、普段聞いているPodcastの中の方々と直接会って話せて嬉しかったです。

またの機会があれば是非参加したいですし、AJITOの方にも来ていいとのことなので話したくなったら行ってみても取って食われたりしなさそうだな?笑とか思いました。

中の人まで届くかはわかりませんが、最後はメッセージでしめたいと思います。

お忙しいとは思いますが、お体にお気をつけてください。来年からのエピソードも楽しみに待っています!!

*1:実際は会議室を借りているらしいですが

*2:とはいえ、VOYAGE GROUPさんと公式な関係性はなく、あくまで個人の見解として公開されているようです。

*3:最新回で適当に来ていいとおっしゃっていたので甘えさせていただきました。

*4:経緯と詳細は省きますが

*5:ORM

*6:ちなみにsuzukenさんはORMではなく生SQL派だとおっしゃっていました。

Tech系Podcast しがないラジオ忘年会を開催しました

はじめに

しがないラジオアドベントカレンダーの19日目の記事となります。

僕は、1日目にもTech系Podcast『しがないラジオ』をはじめて変わった5つのことというタイトルで記事を書いていますので、そちらも読んでいただけると嬉しいです。

さて、僕はしがないラジオでパーソナリティーをやっていて、

昨日(12月18日)しがないラジオ忘年会を主催したので、本日の記事ではそちらのレポートを書きます。

shiganai.connpass.com

当日の様子

過去回ゲストのかた5人と、公募のリスナー枠で3人のかたが参加してくださいました。

f:id:zuckey_17:20171219200556j:plain

ゲストの中でもsp11でゲストに出ていただいた石丸さんはなんとドイツからSkypeで悪の組織のボス的に参加してくださいました。

f:id:zuckey_17:20171219200642j:plain

リスナーの3人とはパーソナリティー両方が初めましてだったので、日常的に、一方的に声を聞いていただいている人にお会いして、「あ、本物がしゃべっている」と言われるというなかなかできない体験ができました。笑

てぃーびーさんが楽しくてしかたがない、しがないラジオ忘年会レポートという記事を書いてくださっているので、そちらも参照してみてください。

忘年会のコンテンツ

主に3つの企画をしました。

ゆるくやっていたためパーソナリティー2人がLTで計50分以上もしゃべったため、たった3コンテンツで3時間半まるまる使いました。

公開録音

公開録音には出席していただいたすべての方に参加していただきました。

ゲストの方には、自分のゲスト回の思い出を、

リスナーの方には、印象に残ったエピソードの話をしていただいています。

特にどういう内容でやるかを事前に共有せず、その場でお題を出したにもかかわらず、しっかり答えていただきました。

こちらのエピソードは、「ep.29 楽しいしがないラジオ忘年会」として既に公開しているので、 公式ページや各種Podcastクライアントにて聞いていただければ嬉しいです。

https://shiganai.org/ep/ep29

個人的には、グダグダしてお蔵入りするんじゃないかと思っていたのですが、 皆さんが順応に対応していただき、素晴らしいなと思いました。

リスナーの方々の印象に残ったエピソードがすべてゲスト回だったので、 パーソナリティー2人の回もこれからもっと頑張っていかないとという気持ちになりました。泣

LT大会

順番に紹介していきます。

まずパーソナリティーの2人がそれぞれ25分ずつくらい話しました。LTとは...

しがないラジオの作り方 - @zuckey_17 -

収録/編集環境の変遷や、Webサイトの実装、 そして、その課題点や今後の方向性について話しました。

スライドにも書きかしたが、

  • 音声コンテンツの収録や編集に詳しい方
  • SoundCloud APIに詳しい方

いらっしゃいましたらアドバイスいただきたいです笑

しがないラジオの1年 - @ikegami_jumpei -

  • SoundCloudの視聴数の変遷
  • Twitterのフィードバック
  • 僕らのプライベートSlackのやりとり

などをもとにこの1年を振り返ってくれました。

さまざまな方々が徐々にしがないラジオに関わっていってくださっているのを実感することができました。

たった一つの盛り上げる技術 - @tbpqr -

ハッシュタグでのツイートだけでなく、パーソナリティーへのDMなどでも含め いつもたくさんのフィードバックをしてくださるてぃーびーさんが、 なぜそこまで積極的にフィードバックをするのか、ということについて、

「その行動の結果なにが起こるかを考える」

という観点から解説してくださいました。

※ 残りのお二方は公開記事がありません。

Web系に転職したらその次は? - @hkdnet -

僕らのラジオの名前(SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ)に寄せて、Web系に転職した後のステップアップについての考え方についてを話しくださいました。

パーソナリティー2人よりも早くにWeb系に転職したはくどーさん、 いつもいろいろ教えていただいていたりしていてやはりすごいなという感じがありますが、 それでも切磋琢磨できる存在になりたいという気持ちの高まりとも感じました。

無題 - OSCAさん-

はくどーさんに引き続いてエンジニアのキャリアについての考え方を話してくださいました。 詳しくは、本アドベントカレンダー23日分の記事で詳しく書いていただけるようなのですが、 エンジニアが自らの仕事へのモチベーションを考える上での考えうる選択肢を紹介してくださいました。

また、エンジニアは常に自分の考えている最もモチベーションの上がる仕事ができるわけではなく、

  • その状況の中でどのように仕事をする理由を見つけていくのか
  • もし部下がそこに疑念や不満を持った時にモチベーティングしていくのか

について話してくださいました。

今僕は、Web系に転職して、コードが書けて自分の能力が向上していくことそのものに喜びを感じていますが、 それが年を経ると、他のモチベーションが生まれてきたり、それを見つける必要が出てきたりすることもあるのだろうな、と漠然と考えました。

楽しいドイツの観光地ベスト5 - @shoya140 -

残念ながら時間不足で石丸さんのLTを聞くことができませんでした。 (ドイツからのリモート参加にもかかわらず、時間を取ることができず、すみませんでした。) sp11bでも話されていましたが、ドイツの様々な名所を趣味である写真をベースに紹介してくださっています。

どれも素晴らしい写真で、ドイツへのいきたさが高まります。

スペシャルコンテンツ

こちらは企画していたわけではなかったのですが、LT大会終盤のはくどーさん、OSCAさんの発表を受け、議論が白熱したので少しその内容を書きたいと思います。

仕事の方向性と自身のモチベーションについて

OSCAさんの発表でもありましたが、エンジニアが仕事の中に求めるモチベーションはさまざまで、

企業がそのモチベーションにあった仕事を必ずしも提供できるわけではありません。

その中で、組織の中でてぃーびーさんはMBB(Management by Belief)を紹介してくださいました。(OKR(Objectives and Key)と対比されていました。)

まだしっかり調べきれていないですが、

チームで誰がどんなモチベーションを持っているかを把握し、すり合わせる。

そして全員が高いパフォーマンスを発揮することができる。

いうのは簡単だが、なかなか実践できていることは少ない。そういう話だったと思います。

将来の描きかた

上記の話の中で湊川さん(llminatoll)から、前職での取り組みについての紹介がありました。

10年後の目標をチームで共有して把握し、個々がやるべきことを分担できるようにするという施策でした。

それを受けて、長期的な目標の立て方、その難しさについての話になりました。

結論としては、長期スパンな目標ほどと抽象度を持って手段を明確にしないのが良いのではないか、という話になったと思います。

各個人、目標を立ててそれを進めていきたい、目の前のことだけ片付けていけば良い、などさまざまな性格の中で、

(特にWeb系と呼ばれる世界で)どんどん変化していく世の中に適応しつつ成長していくためには、

もしかしたら当たり前かもしれないですが、そういった考えを持っていかないといけない、という話になりました。

似た人が集まった

いろいろ議論に花咲きましたが、おふたりのLTからこのような議論に発展したのは、勝手ながら、みんなこういった話が好きで僕らのPodcastを聞いてくれていて、実際に集まったらめちゃくちゃいい話あいができたのだ、と思いました。

僕もこういう話は大好きですし、モヤモヤすることも多いです。これからもそれをラジオという形でアウトプットし続けて、いろいろなフィードバックを受けていきたいと思いました。

最後に

この会に参加していただいた過去回ゲストのみなさま、リスナーのみなさま、

すごく楽しい時間を過ごせたと思います。

初対面の方もいたりして微妙に緊張していましたが、終始じんわりとした感動の中にいました。本当にありがとうございました。

そして、僕と同じくパーソナリティのガミさん id:jumpei_ikegami は会場手配、飲食の手配をしてくれました。本当にありがとう!

この日のために、ステッカーを作ったのですが、皆さんにお渡しすることを忘れてしまい、それだけが残念です。

また、昨日参加していただいた方にはお会いすることもあるでしょうし(ゲスト回待ってますよ!)、Twitterフィードバックや、iTunesレビュー企画などで配布しようと思っているので、今後にご期待ください。

まだ、残り日数もありますし、ラジオの更新もあると思いますが、忘年会ということでこちらで締めたいと思います。

今年もありがとうございました!来年もどうぞよろしくお願いします!

Tech系Podcast『しがないラジオ』をはじめて変わった5つのこと

はじめに

f:id:zuckey_17:20171201233552j:plain

しがないラジオアドベントカレンダーの1日目の記事となります。 このアドベントカレンダーを立ててくださったてぃーびーさん、いつもフィードバックなど関わっていただきありがとうございます。

今年の3月にしがないラジオをはじめて、自分がどのように変わったのか、周りの環境がどのように変わったのか、を書こうと思います。

本題

1. インプット量が増えた

ラジオを配信する、しかも1週間に1回のペースで1時間 ~ 1時間半ほど話すとなると、話題が豊富に必要になります。

1週間に平均1回のリリースをしようと決めて始めたこのしがないラジオですが、かなり早い段階でネタがなくなってしまっていました。

序盤*1については、パーソナリティのこれまでの経験について語っており、学生生活、社会人生活でITやプログラミングとどのように接してきたか、パーソナリティ2人の前職でどのようなことをしていたか、感じていたか、などを話していました。

そういった話題も長く続くことはなく、前週にあったTech系のニュースの雑多な話を拾って自分たちの意見を取り上げるといった方式になりました。

しかし、途端に 「以前の方が面白かった」と言われるようになります。

よくよく考えるとエンジニアになってそう長くない2人が雑多なニュースに対して深い考察ができるとは思えません。

パーソナリティの間でも議論し、積極的に本を読んでその報告をすることにしました。

結果、技術書を1ヶ月に2~3冊くらいのペースで読むようになりました。

そのほかにも、

など、興味をもっていろいろ読むことができました。

「ラジオで話せるし、とりあえず読んどくか」

と考えられるようになったのは、かなり良い変化ではないかと思います。

登壇駆動でいろいろなことをインプットできるということはよく言われていますが、 ラジオ駆動でいろいろインプットを加速するというのもあるなあと思いました。

2. アウトプット量が増えた

インプットに引き続きアウトプットも増えるようになりました。

ラジオの公開を始めた3月頃、あまりのリスナーの増えなさに、宣伝したい!という思いから、 LT大会や勉強会で発表することを始めました。

それまでは1度も勉強会で登壇をしたことがなく、 また僕自身あがり症で大人数の前で話すことにすごく苦手意識がありました。

そういうこともあり、3月から月に1度はなんらかの発表活動をするということを目標に掲げ、 発表することにしました。

そして徐々に「話すのが楽しい!」「もっといろいろと伝えたい」と思うようになりました。

発表以外にも、React初心者向けハンズオンでメンターを行ったりと、積極的に人前に出るようになりました。

印象深いエピソードとしては、過去回ゲストでもあるたみーさんが最近まで代表で運営されていた We Are JavaScripters!のLT大会にてこちらも運営の一人である深見さんから 初めての発表の時から比べて格段に上手くなったと褒めていただいたことがあり、 その時はすごく嬉しく、苦手意識が薄れていくのを感じました。

f:id:zuckey_17:20171201233354j:plain

また、ゲストに出てくださる方は、

をはじめとして、いろいろな形でアウトプットをされている方がいらっしゃり、自分もすごく刺激を受けることができています。

ラジオというアウトプットを始めると連鎖的に色々なアウトプットにつながるのだなと思いました。

※ アウトプットといえば5月頃、「ブログをやる」と息巻いていましたがやっていません。がみさんは同時に宣言していた筋トレを最近始めたようなので、もう一度頑張りたいと思っています。

3. SIerについて知見を得た

特に ep.3b 楽しい大手SIer SEのお仕事ではSIerや日本のIT業界の多重構造についての疑問点を話していますが、基本的に省略しない方の名称の通り、

SIerで疲弊しているのではなくもっと楽しいWEB業界に行こうよ」

ということを押していこうと始まったラジオなので、少し強めにSIerディスる、ということをしています。

このようにSIerについて1意見あります、というスタンスを明示的にとっていると 例えばTwitterや他のTech系PodcastなどでSIerについて触れられているものが目についてくるようになります。

やはりSIerがつらい、SIerのここがダメ、などと言及されていることがほとんどですが、 中には

  • 半年やもっと短いスパンでプロジェクトが変わるので様々な技術スタックを身につけることができる
  • SIerにいたからきちんとした工数などの見積もりが上手くなり、結果として周りとの期待値調整がうまくなった

などなど、良いことも目につくようになりました。

もしかしたら筋の良い*2SIerで経験するのは非常に良いことなのではというふうに思うようになり、 現在では一概には言えないのかなというふうには考えを改めています。

とはいえ、ラジオの中でも度々いっていますが、 ブラックでは?と思ったり、もっと楽しいことがほかにあるんじゃないかな、と思ったならば、 実際にするのかどうかは置いておいても、転職活動を始めることをオススメします。

それだけで、

  • 自分が何を大事にして仕事をしているか
  • 世間の自分への評価はどんなものなのか
  • 世の中にはこういう仕事(業界)もあるのか

という様々な発見があると思います。

4. 個人でWebサービスを運用するという経験ができた

6月頃にしがないラジオWebPageを作りました。

このサイトは Firebaseホスティング機能で、静的なファイルを置き 音声ホスティングサービスの SoundCloudや、 TwitterSlackなどのAPIを利用して 動いています。

パーソナリティの2人が業務でReact.jsVue.jsを主に使っていることもあり、 2人とも触ったことのない Angularで作ってみるか、ということになりました。*3

Angular日本ユーザー会*4が開催されていたAngular入門者向けハンズオンに二人で参加し、 そのあとにこのWebサイトを作成しましたが、いろいろなAPIを利用したり、するとハマったことも多く、*5 ただ自分たちでどのようにこのサイトを作っていきたいのかというのを話し合って作り上げました。

それだけでもすごく勉強になったのですが、 一度エピソード一覧が引けなくなる、という不具合があり、それをリスナーの方がTwitter経由で知らせてくださる、ということがありました。

内容はSoundCloudAPIのトークン切れという問題だったのですが、*6 報告をいただいて、とりあえず直さないと、この間に来ていただいた人が2度と聞いてくれなくなる! と頭を抱えながら対応したのはすごくいい経験になりました。

ちょうど先週に過去回ゲストにも出てくれている前職の同期のみっつん*7がヘッダーを作ってくれたので 久々の更新をしましたが、少し仕事が忙しい時期もあり改善から離れてしまっていたのでもっと改善していきたいなと思っています。

5. 仕事以外の名刺ができた

普段はソフトウェアエンジニアという職種で名乗っていますが、今ではTech系Podcasterという肩書きができました。 勉強会でも時々「しがないラジオのずっきーさん」「楽しくて仕方がない人」というので認識されていることもすくないですが、あって、 知ってくださって聞いてくださる人が本当に実在することに毎回感動しています。

とはいえ、僕が普段聞いているbackspace.fmでは100回配信して初めてPodcasterと名乗れ、とおっしゃっていた回が あったと思うので、11月で折り返しを超えていますが、ひとまずはそれを目指して、頑張っていこうかなと思います。

最後に

かなり自分語りになってしまいましたorz これを書いていて改めて、ラジオを始めるといいことしかなかったように思います。

2017年の2月に同じくパーソナリティのガミさんとスノボ旅行に行った際、かのRebuild.fmの話で盛り上がり、 そのあと自分たちの今やっている仕事の話で盛り上がり、「これPodcastとして話せるんじゃね?」と言い合って実際に3月に始まった時は、 まさか12月にアドベントカレンダーを立ち上げて自分が1日目のエントリーを書いているとは思いもしませんでした。*8

こうしていられるのは、いつも聞いてくださっているリスナーさんのおかげです、本当にありがとうございます。 これからもいろいろと改善を重ねてよりよくしていくつもりでいるので、フィードバックなどありましたらどんどん #しがないラジオでいただければと思っています。

*1:ep4くらいまで

*2:どう良いのかはさておき

*3:こちらもラジオによるインプットの促進ですね!

*4:とても暖かい方々でした!

*5:特にSoundCloudAPIがあまりよくなく?辛かったです笑

*6:今でもあまりわかっている自信がないので、もし詳しい方いらっしゃいましたら、話を聞かせていただきたいです

*7:みっつん本当にありがとうありがとう

*8:初めてのアドベントカレンダーで、かなりギリギリですが間に合ってよかったです