Satoryu's Diary

Rubyが好きな貧乏プログラマーの日記。日々の生活、開発に関するメモとか考えとか。


2018年08月03日 [長年日記]

_ デスクの上の新旧交代

誕生日プレゼントとして、KensingtonのワイヤレストラックボールとHHKB Proのキートップ墨とカラーキートップをいただいたので、早速入れ替えてみた。USBケーブルの煩わしたがなくなった。特に、キートップも、思った以上に打鍵感が変わったので驚きだった。長く使っていると表面がツルツルしてきていたことに気づいた。新品のキートップだと滑りがなく、打ち込みやすい*1

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

【新品/取寄品】Kensington マウス Expert Mouse Wireless Trackball K72359JP
価格:12455円(税込、送料別) (2018/8/3時点)




Tags: 雑記

*1 という気がする


2018年07月29日 [長年日記]

_ 37歳になってた。

日付も変わり37歳になってました。

最初に、今年も懲りずに例のアレを共有しておきますね。

皆様の意思決定の助けになれば幸いです。
その意思決定の助けのために、この1年を振り返ってみる。

お仕事

この1年もまた、ほとんどをエンジニアとしてお仕事ができました。
規模は小さいサービスをAzureのみで作ったり、アーキテクチャを変えたり、データ移行をやったり、なんちゃってデータ分析っぽく長めのSQLを書いたり、その一方で関係者との間であれこれ進め方を考えたり、進捗確認おじさん業もした。
まぁまぁぼちぼち楽しくやれているのですが、4月あたりから雑多なことが増えてきて、コードを書かない日があったりと辛い日もありますが、自分にとってのチャレンジもあったので私は元気です。でも、もっとコード書いて、お客さんに喜ばれたいなぁとは思う次第です。
継続的に新しいキャリアに関するお話は積極的にお受けしておりますので、声をかけていただけるとありがたいで sushi 。SMTPはNGなんで話を聞く気はありませんけど。

OSS活動

プライベートで書くコードは、Laravelの壁打ちのために簡単なサービスを作ったり、レガシーなOSSをどのように復活させるか試してみたり、ときにはNode.jsでAzure Functionsのコードを勢いでざざっと書いたりした。書く言語は増えたけれど、相変わらずサーバーサイドなのでフロントとかモバイルとか他のことにも手を出したい。
ちょうど1年前から84本のpull requestを書いていたみたい。その殆どは手前味噌な自作OSSのRubyバージョンアップ対応や小さいバグフィックスで、コミュニティへのフィードバックは少なかった。

読書

今年は本を読んでいきたいと思って、年初は快調に読み進めていたのだけれど、最近は読む時間が取れてなくて残念な気持ち。4月から時差出勤ができなくなったので、通勤電車で本を読めるほどの余裕がなくなってしまったのが痛い。朝の自由時間を復活させたいなぁ。あと、最近は色々急に仕事が重なってきて、単に頭が落ち着かない状態でもある sob
ちなみに、今年読んだ本はこんな感じ。

途中までしか読んでなかったり、パラパラっとかいつまんで読んだだけの本もあるけど、昨年に比べたら数は読めている。

筋トレ

一昨年から少しずつ始めた筋トレは、年初にブランクを空けてしまったのを4月から再開させた。週2、3回というペースは変わらないが、フォームを気にしたり、回数よりもセット数を増やしていくようにしてみた。あと、食事もちょっとだけ気を使って、炭水化物を減らしてみたり、タンパク質多めのものを食べたりしている。少しずつだけれど結果に出ている感じがするので、なんとか続いている。
ただ、お腹周りが全然減らない…

推し事

推し事については、昨年度は良席確保を何度か発生させてしまったので運気を使い果たした感があるので、今年度は在宅気味になるのではないかと危惧しております。ですが、攻めの姿勢は可能な限り維持しようかと。

おわりに

40歳が近くなってきましたが、年齢とは関係なく、わりと楽しく過ごせたかな、と思っています。これからも楽しくやっていければと。


2018年03月30日 [長年日記]

_ tDiary 5.0.8 にアップデートした。

恒例の29日になったので、確認したらリリースされてた。

今回のリリースで、大きな変更は無いが、最新を追っていくためにササッと上げておいた。

Tags: tdiary

2018年03月02日 [長年日記]

_ カイゼン・ジャーニーを読んだ。

思ったより読むのに時間がかかってしまった。目新しい技術が載っているわけでも、複雑な理論が載っているわけでもないので、読むだけならきっともっと早く読み終えられたと思う。単なる物語であればきっともっと早く読み終えられたはずだが、この本はそういう類のものじゃなかった。

この本に書かれているのは、凝縮した著者の情熱と経験にもとづいて書かれている。主人公の江島が直面する問題には、何かしらの基づく事実がある。その場面場面で、「次に江島は(もしくは袖ヶ浦はなどなど)はいったいどう出るのだろうか」と先を想像しながら読んでしまった。この想像が楽しかったので、読むのに時間がかかってしまった。自分は同じ本を何回か読みたいと思うことは稀なのだけれど、この本は様々な立場の登場人物が描かれているので、想像する対象の人物を置き換えながら何度か読み直したいと思った。物語として書かれているからそう思ったのだと思う。よくできてるなー。
読んでて辛いところもあった。自分を主人公江島に置き換えてしまうと、かつて自分が諦めてしまったことなど辛いことを思い出してしまった。

この本は、これからエンジニアとして仕事をする人、というよりも少し自分で何かカイゼン活動を始めた人が良さそう。1人で始めても2人目が現れるまでに時間がかかることもあるだろうし、その間に1人で解決できない問題に色々直面するかもしれない。江島は運が良いとさえ見えてしまうことがあるかもしれない。
でも、一度でもカイゼン活動に挑戦したことがある人ならある程度の辛さを知っている。その辛さがわかっていれば、この本に書かれていない辛さの部分も汲み取りながら、江島という会うことはできない遠くにいる同志の活動を支えに頑張れそうだと思った。

デブサミ終わってから色々な人が絶賛してたので、若干冷ややかな目で読んでたのだけれど、やはりこの著者2人が書いただけあって、物語の一つ一つが問題に直面している人達の背中を後押しするものだと思いました。
この本を書くまでのジャーニーが新たなジャーニーを生むんだろうな。

さて、僕は何をする人だろう。
この4月から社会人として10年目ディケイド。
これまでの世界を破壊して、ファイナル仮面ライドフォームはどうなるのか*1

Tags: 読書

*1 特に意味は無い。書きたかっただけ。


2018年02月16日 [長年日記]

_ 実況パワフルモブプログラミング 感想戦 #devsumi

実況パワフルモブプログラミング

先日お伝えしていた通り、Developers Summit 2018にて仕事をしてきました。
目黒雅叙園の一室を1時間弱お借りして、仕事をしてきました。事前予約通り満席となり、さらには立ち見まで出て、講演者の我々は大変驚きました。朝一のセッションにもかかわらず、来て下さった皆様、ありがとうございました。
デブサミのテーマが「変わるもの、変わらないもの」でしたが、ただの変わり者の私たちはいかがだったでしょうか。

参加者の皆様の感想については、実行委員の方がToggetterにまとめてくださいました。そちらをご覧いただくと雰囲気が伝わると思いますので、ぜひご覧ください。

一夜明け、昨日のことを振り返ってみて、モブの中の人として伝えたかったことを書いてみます。

変わり者達

セッションでプロダクティブなデベロップメントを魅せたクレイジーな開発チームを紹介します。

  • Gota Miyazaki: 普段からモブしてるモブの人。PHPの使い手。
  • Tatsuya Sato(私): 普段からモブしてるモブの人。昨年からPHPに真面目に向き合ってる。ボッチじゃない。
  • Hiroaki Ono: 今回のキーパーソン。普段は別の部署で別のプロダクトを開発してる人。PHPは使ってない、

この最後の小野さんが今回一番重要なポジションでした。「プログラミング、チーム開発は普通に出来る人、けれど今回触るプロダクトについての知識はゼロ」という状況です。ですので、参加者の皆さんは、
「これまで違うプログラミング言語で開発してきた、中途入社の社員」
として見ていただけたのではないでしょうか。

「どこまでやるか」と「どうやるか」

モブプロ開始した時に、朝礼をまずやりました。
これは、スクラムのスタンドアップミーティングとかそういうものや、全く堅苦しいことではなく、

  • 今日どこまでやるか
  • どうやるか

を決めるだけです。
このセッションの時は、事前に「どこまでやるか」は決めていたので、それの再確認から始まりました。普段においても、せいぜい数分程度で済ませます。メンバーそれぞれが別々のタスクをアサインされる場合、朝礼ではそれぞれが何をやったのかを共有し、それぞれが抱えている問題を相談したりします。ですが、モブだとチームでできることは1つであり、一緒に活動しているので、それは既に共有されています。ですので、朝礼ではやることの再確認程度です。
なので、このセッションでは「どうやるか」にすぐ自然と移りました。
「どこまでやるか」と「どうやるか」を決めるフェーズは明確には別れていません。それは、「今日」*1の中で終えられるかどうかを考えなければならないので、「どこまで」いけるかは「どうやる」によって変わる可能性があります。

今回のやることは、管理画面に出ているデータが数字だけではわかりづらいので、「棒グラフでデータを表示する」というものでした。これに対して、次のようなタスクに分けて、進めることにしました。

  1. とりあえず何でもいいからグラフを出す。
  2. PHPからダミーのデータを渡す。
  3. データベースからデータを抜き出し、ダミーデータを置き換える。

ここでは、会場に来ている参加者の人達が少しでも進捗が見えるようになればと思い、まずは画面のアウトプットを出し、それが徐々に精緻化されていくことで、「本当にゴールに向かって開発が進んでる」という感覚を持ってもらおうという意図があります。
ですが、これは普段でもわりとやります。目に見えてない段階では想像でしか出来栄えについて議論できないので、その議論は無駄になりがちです。ですので、ダミーデータでもいいので何かしらアウトプットを出すところから始めるようにしています。もちろん、すぐにアウトプットまで作れそうな場合は、SQLを組むところから始めることもあります。

見積もり

今回は意識してそれぞれにかける時間を見積もりました。この日は30分しかないということで、分単位の見積もりをしましたが、これは初めての試みでした。
いつもは1日単位で、その日のやることを決めてます。
ランチタイムや休憩時間といったタイミングが入ったりするので、その時点であとどれくらいいけそうなのかどうか確認をします。

設計

朝礼の時にやっていたように、その場でプロダクトの画面を見ながら完成のイメージについて絵を書いています。ホワイトボードだったり、そこら辺に置いてあるコピー用紙とかで絵を書いたりしてます。書いたものは残したりはしてません。セッション後に「ドキュメントはどうしてるんですか?」と聞かれたけれど、必要な時にその時の相手向けに書いています、としか回答できなかった。伝えたい相手に伝えるための手段なので、その時々に書くしかないのだと思う。プロダクトについて網羅的に書くのは、今のプロダクトはシンプルだから出来るかもしれない。けれど、作ったところで誰が見るのかがわからないものは無駄になりそうなので、多分やらないと思います。

ちなみに、この時に使っていたホワイトボードはnu boardです。

ドライバー選択

やることが決まり、それをどう進めるかも決まったら、最初のドライバーの選択です。普段なら誰が誰がどの順でやっても良いのですが、今回は、プロダクトについて知らないメンバーが1人います。彼にはプロダクトの知識が必要なものを敢えてやってもらう必要があるので、最後の3つめのタスクをやってもらうことにしました。その他2つはPHPやJavaScriptといった技術に関する知識で解決できてしまうため、ナビゲーターが持つプロダクトに関する知識を引き出す機会はほぼ無いでしょう。新しく入ったドライバーが進めなくなった時、その時がナビゲーターの持つ知識がドライバーの背中を押すタイミングだと思います。

YATTA!

はい、大げさにやりましたw
普段のオフィスではここまでやりません。「よし!」とか言ったりします。
このYATTA!の本質は、「成果の喜びを共有」し、「そこに行き着くまでの過程を称える」ことだと思っています。単に出来て良かったということだけでなく、それのどこが良いのかを話したりします。例えば、「あそこのエラー、わかりづらかったけど、無闇にはまらずに別の方法に変えてよかったね」とか、「事前にあの辺りのことを調べておいてもらって助かりました。」とか。こういう良いことを言われると、自然とそれを再現させたくなります*2
もちろん、嬉しいことをいつものメンバーと嬉しいと言えるのはとても楽しいので、喩えモブプロをしていないとしても、是非みなさんもやってみましょう。周りの騒音にならない程度に。

一日の終り

事前の打ち合わせでは、時間内にゴールまでたどり着かなくても、それはそれで問題にモブで立ち向かうことで見てもらえるものはあると思っていたのだけれど、予想外なことに最後に時間が余ってしまった。
なので、途中で後回しにした見た目の修正などをまとめる作業に入りました。これも普段の一日の終りにやることです。開発中は、機能として中核となる部分から作り、少しずつ精緻化していくやり方でした。このやり方だと、本質的でない部分は飛ばしてしまいます。このセッションでは、グラフの縦幅が大きすぎるので小さくしないといけなかったり、棒グラフの色を統一させないといけなかったりや、クエリにorder byを付けないと順番が保証されない、など細かい修正タスクを事後のやることとして出しました。

おわりに

やってる方も、見てる方もとても楽しんでいただけたようなので、とても満足しています。参加してくださった皆さんの普段のお仕事が少しでも楽しいものになれば、幸いです。

*1 このセッションの場合、だいたい30分程度。

*2 少なくとも自分は。


2018年02月09日 [長年日記]

_ Azure Web Apps にLaravelをデプロイするカスタムデプロイの作成方法

今のプロジェクトで、Laravelでアプリケーションを開発していて、それをAzure Web Apps 上で動かしている。公式のドキュメントでは、Composer Extensionを使って、デプロイした後にcomposer install が自動的に実行するようにしている。けれども、これは下記の観点からオススメしない。

  1. デプロイ時に実行される処理を変更できない。
  2. インストールされるcomposerのバージョンが、Composer Extensionをインストールした時点での最新。

1については、Composer Extensionがデプロイ時に実行されるスクリプトを上書きしてしまうため、カスタムデプロイを実装できないことを言っている。2は、composerやphpのバージョンの組み合わせで発生する問題がある場合、デプロイ時に混乱する恐れがある。

また、Laravelのアプリをプロダクションとしてデプロイする場合、パフォーマンスを最適化するためのコマンドが用意されているので、それをデプロイ時に実行したい。

ということで、Azure Web Appへのデプロイ時にそういったお好みのコマンドを実行できるようにカスタムデプロイを準備する方法を書きます。

Composer をアプリのリポジトリにインストール

Composer はpharファイル(圧縮されたphp)で配布されているので、それをリポジトリ内にインストールする。上で書いたように、Composer Extensionを利用するとそもそもカスタムデプロイが実行できないため、自前で持つ必要がある。

cd /path/to/your/laravelapp/
mkdir bin
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php --install-dir=bin --filename=composer
git add -A
git commit -m 'Install composer'

Azure Portalからデプロイ先のWeb AppにKuduで入り、コンソールでインストールしても構わない。Slotを利用したデプロイをする場合、Slot作成時に毎度インストール作業が発生するので注意が必要だ。

カスタムデプロイのスクリプトを作成

ゼロから書く必要は無く、npmでKuduScriptコマンドをインストールし、それを使ってPHP用のデプロイスクリプトの雛形を用意する。

cd /path/to/your/laravelapp/
npm install kuduscript -g
kuduscript -y --php
git add -A
git commit -m 'Generate deployment script'

これを実行することで、.depoymentdeploy.sh が生成される。
.deploymentはどのファイルをデプロイ時に実行するかを指定し、実際に実行される一連の手続きをdeploy.shに書く。

#!/bin/bash

# ----------------------
# KUDU Deployment Script
# Version: 1.0.15
# ----------------------

# Helpers
# -------

exitWithMessageOnError () {
  if [ ! $? -eq 0 ]; then
    echo "An error has occurred during web site deployment."
    echo $1
    exit 1
  fi
}

# Prerequisites
# -------------

# Verify node.js installed
hash node 2>/dev/null
exitWithMessageOnError "Missing node.js executable, please install node.js, if already installed make sure it can be reached from current environment."

# Setup
# -----

SCRIPT_DIR="${BASH_SOURCE[0]%\\*}"
SCRIPT_DIR="${SCRIPT_DIR%/*}"
ARTIFACTS=$SCRIPT_DIR/../artifacts
KUDU_SYNC_CMD=${KUDU_SYNC_CMD//\"}

if [[ ! -n "$DEPLOYMENT_SOURCE" ]]; then
  DEPLOYMENT_SOURCE=$SCRIPT_DIR
fi

if [[ ! -n "$NEXT_MANIFEST_PATH" ]]; then
  NEXT_MANIFEST_PATH=$ARTIFACTS/manifest

  if [[ ! -n "$PREVIOUS_MANIFEST_PATH" ]]; then
    PREVIOUS_MANIFEST_PATH=$NEXT_MANIFEST_PATH
  fi
fi

if [[ ! -n "$DEPLOYMENT_TARGET" ]]; then
  DEPLOYMENT_TARGET=$ARTIFACTS/wwwroot
else
  KUDU_SERVICE=true
fi

if [[ ! -n "$KUDU_SYNC_CMD" ]]; then
  # Install kudu sync
  echo Installing Kudu Sync
  npm install kudusync -g --silent
  exitWithMessageOnError "npm failed"

  if [[ ! -n "$KUDU_SERVICE" ]]; then
    # In case we are running locally this is the correct location of kuduSync
    KUDU_SYNC_CMD=kuduSync
  else
    # In case we are running on kudu service this is the correct location of kuduSync
    KUDU_SYNC_CMD=$APPDATA/npm/node_modules/kuduSync/bin/kuduSync
  fi
fi

# PHP Helpers
# -----------

initializeDeploymentConfig() {
    if [ ! -e "$COMPOSER_ARGS" ]; then
    COMPOSER_ARGS="--no-interaction --prefer-dist --optimize-autoloader --no-progress --no-dev --verbose"
    echo "No COMPOSER_ARGS variable declared in App Settings, using the default settings"
  else
    echo "Using COMPOSER_ARGS variable declared in App Setting"
  fi
  echo "Composer settings: $COMPOSER_ARGS"
}

##################################################################################################################################
# Deployment
# ----------

echo PHP deployment


# 1. Initialize Composer Config
initializeDeploymentConfig

# 2. Use composer
echo "$DEPLOYMENT_SOURCE"
if [ -e "$DEPLOYMENT_SOURCE/composer.json" ]; then
  echo "Found composer.json"
  pushd "$DEPLOYMENT_SOURCE"
  ./bin/composer install $COMPOSER_ARGS
  exitWithMessageOnError "Composer install failed"

  php artisan package:discover
  exitWithMessageOnError "Package discover failed"

  php artisan config:cache
  exitWithMessageOnError "Caching config failed"

  php artisan migrate --force -v --database=sqlsrv
  exitWithMessageOnError "Migration failed"
  popd
fi

# 3. KuduSync
if [[ "$IN_PLACE_DEPLOYMENT" -ne "1" ]]; then
  "$KUDU_SYNC_CMD" -v 50 -f "$DEPLOYMENT_SOURCE" -t "$DEPLOYMENT_TARGET" -n "$NEXT_MANIFEST_PATH" -p "$PREVIOUS_MANIFEST_PATH" -i ".git;.hg;.deployment;deploy.sh"
  exitWithMessageOnError "Kudu Sync failed"
fi

##################################################################################################################################

echo "Finished successfully."

デプロイ!

デプロイすると、deploy.shが実行されるようになります。
ドキュメントは見つけられていないけれど、どうやらローカルgitやGitHubなどgitリポジトリを介したデプロイのみにサポートしているようだ。Zipデプロイを試してみたところ、deploy.shは実行されなかった。

参考

_ Developer Summit 2018 で普通に仕事してきます。

Developer Summit 2018

Developer Summit 2018で普通に仕事してきます。

モブプログラミングで仕事してるって言ってるけど、いったいどんなスタイルなんだろう?

という方々をお迎えして、現場見学会というのは兼ねてより実施していましたが、毎度入館申請とか社内の場所取りとか面倒くさいので、ここいらで一気に片付けてしまいたいと思います。

ごめんなさい、お暇なら是非見に来てね!


2018年02月05日 [長年日記]

_ エンジニアのためのデザイン思考入門を読んだ。

デザイン思考というものは、成果物を中心に進めていくものづくりの方法だと思っていたのだけれど、それだけではなく、ユーザーの体験をデザインするものだと知った。この本では、実際に東工大で実施されたエンジニアリングデザインプロジェクト(EDP)を元に、問題を発見していくためのユーザーインタビューからアイデアの発見、そしてプロダクトにまでの方法と、それを行うチームのあり方について書かれていた。
チームについて書かれている3章や、EDPに参加した学生のコラムを読むと、チームで意見をぶつけあいながら試行錯誤していく、そしてそれが楽しそうなのが描かれていた。とにかく3章だけでも読む価値あると思う。丁度昨年、EDPに参加する社会人を募集しているという話を聞いたのだけれど、なんでもっと話を聞かずにスルーしてしまったのだろうと後悔してる。
今新規事業の開発をしているので、読みながら時々、今のプロダクトを良くするにはどうしたらいいのか、というのをあーだこーだと考えてた。

おまけ: きっかけ


最近の投稿

翻訳しました(ちょっとだけ)

follow us in feedly