2020-02-10

PHPerKaigi 2020 に参加する

今年も参加します PHPerKaigi。

去年のはこちら。

今年もPHPerチャレンジがあるらしいですね

PHPer Kaigi めちゃ楽しかったです！
登壇する同僚たちや強強エンジニアな方々を見るだけの予定でしたが、とても楽しめました。
そして、まさかのPHPerチャレンジもタナボタ3位(実質4位)の入賞で嬉しかったです。が、トークンや # はもうお腹いっぱいです。
とりあえず来年も参加したい！#phperkaigi
— おおしげ🎲 (@_ohshige) 2019年3月31日

今年も楽しみたいと思います！

ちなみに、今年は弊社スポンサーです。

2020-02-03

Rustを初めて触ってその流れでDBからデータ取得までを試してみた

Rust

とある理由で、ほぼ遊び感覚で、Rustを使う機会がありました。
多少勉強しましたが、新しく難しい概念に悩まされ、イマイチ理解は進みません。
とりあえず手を動かしたかったので、DB取得までをやってみました。
メモとして残しますが、もっとRustらしく書けるんだろうなと感じています。
rusqliteを使って、sqlite3からデータを取得し表示するまでです。

環境構築は本家を参考にしました。
www.rust-lang.org

以降は、 rustc 1.42.0-nightly で動作確認済みです。
また、 my.db という名前でsqlite3のDBを用意していて、スキーマ等は以下の通りです。

$ sqlite3 my.db
sqlite> .schema users
CREATE TABLE users (user_id int primary key, name text not null);
sqlite> select * from users;
1|田中太郎
2|鈴木次郎

実際に書いたコードは以下です。

Cargo.toml

[package]
name = "demo"
version = "0.1.0"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
rusqlite = "*"

main.rs

extern crate rusqlite;

use rusqlite::{Connection, NO_PARAMS};

#[derive(Debug)]
struct User {
    user_id: usize,
    name: String,
}

fn get_users() -> Vec<User> {
    let conn = Connection::open("my.db").unwrap();
    let mut stmt = conn.prepare("
        SELECT
            user_id, name
        FROM
            users
        ORDER BY
            user_id ASC
    ",
    ).unwrap();

    let users = stmt.query_map(NO_PARAMS, |row| {
        Ok(User {
            user_id: row.get::<_, i64>(0).unwrap() as usize,
            name: row.get::<_, String>(1).unwrap(),
        })
    }).unwrap();

    let mut result: Vec<User> = vec![];
    for user in users {
        result.push(user.unwrap());
    }

    result
}

fn get_user(user_id: usize) -> Option<User> {
    let conn = Connection::open("my.db").unwrap();
    let mut stmt = conn.prepare("
        SELECT
            user_id, name
        FROM
            users
        WHERE
            user_id = ?
    ",
    ).unwrap();

    let id = user_id as i64;
    let mut users = stmt.query_map(&[&id], |row| {
        Ok(User {
            user_id: row.get::<_, i64>(0).unwrap() as usize,
            name: row.get::<_, String>(1).unwrap(),
        })
    }).unwrap();

    let user = users.next();
    match user {
        Some(user) => Some(user.unwrap()),
        None => None,
    }
}

fn main() {
    // 一覧取得
    println!("{:?}", get_users());
    // 存在するidを取得
    println!("{:?}", get_user(1));
    // 存在しないidを取得
    println!("{:?}", get_user(999));
}

上記を実行すると以下のようになります。

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/demo`
[User { user_id: 1, name: "田中太郎" }, User { user_id: 2, name: "鈴木次郎" }]
Some(User { user_id: 1, name: "田中太郎" })
None

ユーザ一覧の取得とユーザ単体の取得（いる場合といない場合）についてうまくできました。
もうちょっとRustらしく書けそうなところもあり、 unwrap() しすぎな感じもありますが、今後の自分に期待します。

2020-01-27

外部勉強会で刺激を得て社内でリファクタリングのライブコーディング会を開催してみた

プログラミング勉強会

はじめに

業務としてがっつりリファクタリングをやるタイミングがあって、その内容が割と良くて、部署内で共有できたら面白いなと思っていました。

そのときに思い出したのが、前に参加した大改修！PHPレガシーコードビフォーアフターという勉強会で、独立したコアレイヤーパターンをよく扱っていて「PHPの現場」でもおなじみの shin1x1 さんによる講演(？)です。
それは、PHPer Kaigiなどで使われている fortee というシステムをライブコーディングで独立したコアレイヤーパターンにリファクタリングしていくという内容でした。
色々な設計に関するアーキテクチャを勉強してもよくわからないという気持ちもあるなかで、実際にリアルタイムでリファクタリングしていく様を見るのはやり方等が良くわかり、とても勉強になりました。
同時に、アーキテクチャに関することだけでなく、PhpStormの使い方やひいてはMacの使い方など、得られるものは多岐に渡りました。

それを思い出し、同じようなことを部署でやって共有すれば面白いのではないかと思い、リファクタリングのライブコーディング会を開催してみました。

過去のツイートの有言実行でもあります。

身内でビフォーアフターのイベントやりたいわ #phperkaigi
— おおしげ🎲 (@_ohshige) 2019年11月30日

目的

表立った目的として、

リファクタリングのやり方を知る。
設計を知る。
PhpStormの操作を知る。(会社では主にPHPを使っています)
良い例を知る。
反面教師を知る。

などを掲げました。

それ以外にも裏目的として、どんどん野次を飛ばしてもらうことで自分自身が書き方やツールの使い方等で知らない部分を知ることができたらと目論んでいました。

内容

どんなコードをどのようにリファクタリングしたかは言えませんが、過去に業務で行ったリファクタリングを再現したライブコーディングを行いました。

まず、会の趣旨とリファクタリングの方針や進め方を会の冒頭で説明しました。
趣旨はもちろんとして、リファクタリングの方針をしっかり理解してもらえないとライブコーディングを理解できないだろうなということで、ここでは丁寧に説明しました。

全員が理解できたら、その後で実際にリファクタリングをライブコーディング形式で行いました。「まず、ここの処理を丸っと移します」「そして、ここをこう書き換えます」「このとき、こうすると簡単に実現できます」などと喋りながらコーディングしていきました。
こうやっていると、「ここでコミットしたいですね」「そこはこうやったら早いですよ」などと野次（褒め言葉）も飛んでくるので、「わかるわかる」「なるほど」と言いながら思いながら進めます。
一方的な説明にはしたくなかったので、ときどきそういうことがあるのは良かったです。

再現リファクタリングとは言え、圧倒的に時間は足りません。
そこで、2/3ほどの時間が経つとライブコーディングは終え、3分クッキングの「そして完成したのがこちらになります」方式で、実際に再現元となったコードをGitHub上で説明しました。

そうして、ライブコーディングと完成版の説明を全て終えると、質疑応答と参加者によるこういうやり方もあるよといった紹介タイムになり、会は終了となりました。

やってみて

ペアプロやモブプロの経験はあるものの、ライブコーディングは初めてで、ペアプロとモブプロとはまた違った難しさがありました。
多少有意義な野次を入れていただき、モブプロのような感じもありましたが、基本的には1人で喋りながらコーディングするので、とても緊張しました。
特に、通るはずのテストが通らなかったときの公開デバッグは内心ドキドキでした。
また、これほどまでに喋りながらコーディングした経験もなく、無言にならないように注意しながら進めるのも大変でした。
ゲーム実況者ってすごいなとしみじみ感じた瞬間でした。

全体的に、主催としてはとても有意義なものになったと思います。
自分のおすすめのやり方を説明しているときに、「なるほど」や「すごい」といった言葉が出ているのを聞けて、とても満足しました。
逆に、野次などで知らなかった色々な技や手法を聞けて、自分自身も何かを得るという裏目的も達成し、満足でした。

反省点

わかりきってはいましたが、自分が今どこを見ていて何をしようと考えているのかをしっかりと参加者に伝えていかないと、PhpStorm上の激しいスクロールやファイル移動だけだと本当に何もわからないだろうなと思います。
なにかをやったあとに、事後説明で済ませたことも多く反省です。

また、せっかく少人数（そのときは6人ほど）でやっていたので、ただのライブコーディングではなく、途中途中でもう少し議論など見るだけではない何かがあっても良かったと思います。
野次もあったとは言え、それ自体は稀で、基本的にこちらが喋っているだけでした。
次回はもう少しやり方を工夫したいところです。

細かいことで言うと、会議室でプロジェクターで写して開催していて、最初はChromecastで投影していて見づらかったのですが、途中でHDMIに変えて見やすくなりました。
面倒だったのでやらなかったのですが、最初からそうするべきでした。
また、どうしても多少部屋を暗くせざるを得ず、暗いPhpStormと明るいGitHubの行き来が見てる側としては苦痛だった気がします。
そのため、心構えができるように、行き来しようとするたびに「移ります」「戻ります」と言うようにしていました。

とは言え、参加者も喜んでくれた（と信じている）ので、開催して良かったです。

おわりに

外部勉強会での経験を経て自分でもやりたいと思い、しかもちょうど良い題材があったために、開催を決意し上長に相談して開催しました。
初めての経験で多少緊張もしましたが、とても楽しかったです。
また良い題材があればより良い方法で再度開催しようと思います。

2020-01-20

数年ぶりに「リーダブルコード」を読むとやっぱりイイ

読書技術書プログラミング

はじめに

数年ぶりにエンジニアなら読むべきと言われている「リーダブルコード」を読みました。
前に読んだのは少なくとも学生のときなので、がっつり仕事をやり始めてからは初めて読みました。

バイブルと呼ばれている通り、「エンジニア　読むべき」でググると上位10件中7件で、★5だったりオススメ1位だったりでリーダブルコードが紹介されていました。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

作者:Dustin Boswell,Trevor Foucher
出版社/メーカー: オライリージャパン
発売日: 2012/06/23
メディア: 単行本（ソフトカバー）

リーダブルコード

概要

副題にもあるように、より良いコードを書くために必要なことが載っています。
命名、コメント、変数や関数、テストなどについて、章立てされていて、それぞれが独立しているので掻い摘んで読んでも構わないような構成になっています。*1

感想

学生当時は「ふーん」という感じで読んでいたイメージがあります。
が、改めて読んでみるとやはりイイなと感じました。

良いコードは何かと言われれば難しいですが、読みやすいコードは何かと言われればリーダブルコードに沿ったコードと答えても問題なさそうです。
実際、副題には「より良いコードを書くための」となっていますが、はじめにの章では「本書の目的は、読みやすいコードを書くことである。」という一節があります。
そして、その次で述べられている以下のような内容が、本書の全てを体現している気がします。

読みやすいコードを書く → コードは理解しやすいものであるべき → コードを読んで理解する時間を最短にする

良いコードの定義は難しいですが、今後は読んで理解する時間が最短であるようなコードの書き方を目指したいと思います。

特筆すべき感想はあまり無いのですが、命名やコメントに関しては、基本的にそのとおりだと思うことばかりでした。
やはりコーディングする人全員に読んでもらって共通言語として意思統一が図れれば最高だなという思いです。

疑問

そんな中、今になっていくつか疑問も出てきました。

1つ目は、「4章美しさ」で紹介されている視覚的な手すりのためのコードの整列です。
例えば、以下のようなものです。

details  = request.POST.get('details')
location = request.POST.get('location')
phone    = request.POST.get('phone')
email    = request.POST.get('email')
url      = request.POST.get('url')

個人的には、これは嫌いで、本文にもあるように「差分」が増えるからです。
上記ならまだしも、以下はもっと嫌いです。

checkFullName("Doug Adams"  , "Mr. Douglas Adams" , "");
checkFullName(" Jake Brown ", "Mr. Jake Brown III", "");
checkFullName("No Such Guy" , ""                  , "no match found");
checkFullName("John"        , ""                  , "more than one result");

ここまでやる必要があるのか？と思ってしまいます。
嫌いな理由として、ずっとPythonをやっていて、PythonではPEP8で悪い例としてあげられていて悪いものだという認識が強いからかもしれません。
もちろん、見やすくなる場合もあるので、コードを書く人にはせめてコミットをわけてほしいと思う次第です。

2つ目は、「14章テストと読みやすさ」で紹介されている独自のミニ言語を実装するという点です。
確かにある程度はメソッド分割して、場合によっては独自のミニ言語のようなものを作り読みやすくすることも必要だと思います。
ですが、ミニ言語レベルのロジックがテストコードに入ってしまうと、テストコードのためのテストが欲しくなってしまいます。
極論、独自のassertを定義し、その中で常にtrueになるようなassertの呼び出し方をしてしまうと、テストコードの意味がなくなります。
命名やコメントに関してもそうですが、「良い塩梅」というのが大切なのでしょうか。

おわりに

疑問もあげましたが、バイブルと呼ばれるだけあって今でも勉強になる部分は多々ありました。
共通言語として使っていきたいので、みんなに読んでほしいです。

2週連続で本の話になってしまいました...

*1:「本書の読み方」参照

2020-01-13

「現場で役立つシステム設計の原則」を読んで

読書技術書プログラミング

はじめに

先日、増田亨さんの「現場で役立つシステム設計の原則」を読んだので感想を。
しばらく前に買っていたのですが、年末で余裕があったのでやっと読了しました。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

作者:増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: 単行本（ソフトカバー）

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者:増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: Kindle版

現場で役立つシステム設計の原則

概要

全10章で構成されていて、総じてDDDやオブジェクト指向メインの話になっています。
なぜそうするのかという理由とサンプルコードと一緒に説明がなされていて、イメージがわきやすくなっています。

感想

1番の感想は、「新卒1年目で読みたかった」ということです。
納得できるできないは別として、オブジェクト指向を単なる知識ではなくシステム設計として適用するにはどういうことなのか、何をどうすればわかりやすいのか、ということがよくわかりました。
特に、今となっては当たり前にやっていますが、第3章「業務ロジックをわかりやすく整理する」で紹介されている、三層アーキテクチャ＋ドメインモデルの例はとてもわかりやすく、もっと早く新卒1年目あたりで知りたかったです。

第1章は値オブジェクトに関することで、第10章はオブジェクト指向設計の学び方に関することで、徐々にミクロからマクロにスケールが大きくなっていくような構成になっていて、目の前のことからより俯瞰したことまでを順番に紹介していきたい意図がある気がします。
それもあって、自分の中で視野？が広がる感覚があり、とても読みやすかったです。

ただ、いくつか疑問もありました。
例えば、第8章で細かい粒度でAPIを作成して必要なデータだけを取得するという話がありました。
これに関しては、確かにそういうやり方もありますが、本当にそうしたいならGraphQLを採用して必要なデータだけを要求するという方法もあるかなと思いました。

全体を通してDDDやドメインエキスパートといった言葉は出てきませんが、DDDを平易な言葉で言い換えているということがよくわかります。
いかにも英語を日本語に直しましたという文章ではなく日本語で日本語らしく説明されているのでとてもわかりやすくなっている気がします。

上述のAPIや、DBやビューに関して言及している箇所など、いくつか簡単には納得できないこともありますが、総じてとても良い本だと思います。

どう読むか

やはりこういう本は視点が変われば意見も変わると思うので、普段の会社のメンバーで読み合い、議論までできると業務に生きてくるのかなと思います。
最近は読んで終わりということも多いので、良し悪しだけでなく皆の考えを知るためにもそういう機会を用意してみようかなと思う今日このごろです。

2020-01-06

令和2年はどんな年になるのだろうか

雑記

遅くなりましたが、あけましておめでとうございます。

実は1月5日は誕生日でして、ちょうど而立の年となりました。
三十路ではなく而立と言っていこうと思います。

もう過ぎていますがまだ間に合います（しつこい）

まだ間に合いますよ！

いろいろhttps://t.co/ybUKgvHwSm
ボドゲ https://t.co/bQzgY3hABx
本https://t.co/jkzWki1zwo
— おおしげ🎲 (@_ohshige) 2020年1月5日

さて、令和2年になりましたが、今年はどんな年になるのだろうかと思いを馳せています。
周りがやっている100のリストを作ろうと思いましたが、簡単に作れるものでもないので、年始め早々諦めました。

とりあえず簡単な目標としては、下記を掲げようと思います。

定量で、AWSの資格を1つは取る、勉強会やカンファレンスのスタッフを1回はやる。
定性で、Dockerから逃げない、後輩指導を中心に技術レベル向上に寄与する。

今年もよろしくおねがいします！

2019-12-30

2019年を振り返ってみるとブログと日常がリンクしていることがわかった

エンジニアライフ雑記

はじめに

正確にはまだ届きませんが、ブログを始めてから約1年が経ちました。
しょぼい内容でもいいから毎週月曜日に公開するようにしようと決めてから無事に続けることができて、完遂間近です。

そんなブログを始めた2019年でしたが、自分のために振り返ってみます。

振り返ってみて

1月〜4月

2019年が始まったばかりだからか、色々な新しいことをスタートしました。
継続という観点で言うとやりきったと言えるのはこのブログだけかもしれません...

ブログ

このブログを開始したのは1月でした。
ohshige.hatenablog.com 記念すべき1回を改めて見てみると、やっぱりなんか恥ずかしい。
過去の記事の焼増しではありますが、どんだけ気合い入れてるんだと。

言語処理100本ノック

新しいこと2つ目。
やりたいと思いつつやっていなかった言語処理100本ノックに挑戦を開始しました。
ohshige.hatenablog.com 頑張って進めてみようと思っていましたが、現在止まっています。
いずれ再開したいです。

競技プログラミング

新しいこと3つ目。
これまたしっかりとやってこなかったので今年はやってみようかなと始めた競技プログラミング。
ohshige.hatenablog.com 毎日解くということとコンテストに参加するということの2つを意識していました。
頑張ってやっていましたが、毎日解くということについてはパタッとやらなくなってしまいました。
コンテストへの参加も土日に予定が入ることが多くなってしまい、なかなか参加できずにいるので勿体ない気持ちでいっぱいです。

技術カンファレンス初参加

実はカンファレンスなるものに参加したことがなく、あまり興味がありませんでした。
しかし、カンファレンスへの参加に関する風潮が社内で出てきて、会社の同期も登壇するということで、初めて参加してみました。 ohshige.hatenablog.com 初めて参加した技術カンファレンスはPHPer Kaigiでしたが、大変面白く、今後も色々なものに参加しようと思うようになりました。

5月〜8月

最初はGASに触り始めた頃だったのでそのネタが連続しています。
が、途中から仕事としてPHPでBEAR.SundayとLaravelをがっつり触ることになったタイミングだったので、PHP関連の話が多いような気がします。

GASで色々

知り合いに依頼されて初めてGASを触り始めました。
ohshige.hatenablog.com 特別にサーバを用意しなくても色々とできるので夢が広がったときです。
今でもちょいちょいGASで何かを作ることがあるので、いい依頼だったかもしれません。

PHP

仕事の影響でPHPでのAndroidのレシート検証やLaravelを使った実装など、PHPを全面に押し出していたときでした。
ohshige.hatenablog.com ohshige.hatenablog.com このときだけでなく普段からずっとPHPは触っていますが、仕事が忙しくて仕事以外に新しいことに挑戦できなかったため、仕事で得たことをそのままブログにしている典型的な例です。

9月〜12月

やっぱり仕事でやってることが如実に表れてしまっていますが、AWSやTerraformをずっと触っているときでした。
また、LTではありますが、初めて技術カンファレンスで登壇することもできました。

AWS

PHPを触りつつ、AWSもがっつり触るタイミングでした。
ohshige.hatenablog.com これまではほとんどAWSの経験はなかったため、新しい気付きの連続でした。
下手するとずっとAWSの記事を書いてしまっていたかもしれません。

Terraform

AWSをやったあとはTerraformを触る機会もありました。
ohshige.hatenablog.com もちろん初めてだったので試行錯誤することも多く、ブログネタにも困りませんでした。
ですが、AWSにしろTerraformにしろ初心者なので、記事の内容が伴っていないことも多く、不甲斐ないです。

技術カンファレンス初登壇

2月に初めて技術カンファレンスに参加してから10ヶ月後、LTではありますが、PHP Conferenceで登壇することができました。
ohshige.hatenablog.com 1年前までは「技術カンファレンスなんて」と思っていた自分が発表する側になるとはという気持ちでいっぱいです。
せっかくなら一般のセッションに登壇することも目指したいです。

その他

いくつか読んだ本についてもまとめました。

ohshige.hatenablog.com ohshige.hatenablog.com ohshige.hatenablog.com

おわりに

露骨に過去記事へのリンク集になってしまいましたが、1年続けられた嬉しさが表れてしまっているということで許してください。

まとめて思ったのは、結構同じ時期には同じようなブログになってしまっていて、普段の仕事や生活がそのまま表れているなということです。
日記は絶対に続かないのでやらないのですが、定期的なブログを書くだけで当時のことを思い出せるので良いものですね。

来年もできる限り続けようと思います。
良いお年を。