satoryuの日記

忘れっぽいから覚えてるうちに書いておかないと。

1日階段200段を登り続けて1ヶ月経った。

2年前くらいから自宅で筋トレを週2か3くらいで続けている。 腕立てやダンベルは好きなのだが、足腰周りがどうも苦手で、スクワットなどやってみてもあんまり楽しくない。 ということで、楽しくないのなら、生活の一部に組み込んで必須事項にしてみた。

具体的には、出社時に自分のデスクがある19Fまで、9Fから階段で行くようにした。 1階登るまでにだいたい20段なので、200段登っていることになる。

iPhoneのヘルスケアアプリで上った階数を見てみると、上った階数が上がっている。

これを始めたのが1月22日からなので、一ヶ月が経過した。 平日の出社時のみなので毎日ではないが、この期間を続けられたので、やはり生活の中に組み込むことは良いと思う。 特に朝であればまだ元気なので、やる気がおきやすい。 帰宅時や帰宅後とか仕事での疲れがある状態だと、やらない理由にしやすいので続けづらかったのではないかと思う。

変化

残念なことに体重や体脂肪率への影響は出ていない。

しかし、体感として、

  • 体が軽く感じる
  • 脚を上げるのが楽
  • ふくらはぎ、ひざまわりが少し太くなった
  • 下腹部の腹筋も少しついた

といったところ。 なんとも形容しがたいのだけど、特に体が軽く感じるというのは本当に気持ちがいい。

参考

この運動を始めるにあたって参考にしたものを紹介する。

勉強会: プログラマの健康を考えるイベント「ヘルシープログラマ!」

何か良い方法はないかと考えている時に、4年前にあったヘルシープログラマーの出版イベントを思い出した。

connpass.com

ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack

ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack

このイベントで訳者の玉川さんが、出社時に自席のフロアまで階段で行くという話をしていたので、それを参考にした。

階段の上り下りの運動強度は筋トレと同じ?:Goodayクイズ:日経Gooday(グッデイ)

階段の上り方で鍛えられる部位がことなってくる。 自分の場合、つま先で上る方法とかかとをつけて上る方法とを、日毎に変えるようにしている。

スクラムフェス大阪2019で発表してきた。 #scrumosaka

www.scrumosaka.org

無茶苦茶、緊張したけど、なんとか終えられることができて、一安心しております。 聴きにきてくださった方々には、お礼しかありません。 時間オーバーしてしまったのが残念でありますが、ツイッターを見ていると楽しんでいただけていたようで、脇汗をかきまくった甲斐がありました。

このセッションでは、コミュ障な自分がお客さんと直接対話する仕事に携わった時にとても参考になったCustomer Interaction Patternsを、自分の話を交えつつ紹介しました。

コミュニケーションを始めることが苦手なコミュ障の人にとって、コミュニケーションを始めるハードルが下がってくれたら嬉しいです。 エンジニアがお客さんに会いに行く、ってそんなことやる必要あるのかな?と思われる方も、エンジニアにとっても良いことがあるということをお伝えしたいことでした。 懇親会で数名の方々に声をかけていただいて、楽しんでいただけたようでホッとしました。

まだ明日もあるので、楽しんでいきましょう!

参考書籍

今回の発表準備や資料作成で参考にした本を紹介します。

パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)

パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)

この2冊はともに、パターン・ランゲージについての説明があり、今回はそこだけ参考にしました。 今回の自分の発表ではざっくばらんに紹介していましたが、「いきいきとした」や「美しい」ものを生み出す仕組みを作ろうという試みは大変興味深いです。

Keynoteで魅せる「伝わる」プレゼンテーションテクニック

Keynoteで魅せる「伝わる」プレゼンテーションテクニック

プレゼンの魔法使いである長沢さんが書かれた本で、Keynote使いの人にとてもオススメです。 単にKeynoteの使い方の本ではなく、プレゼンテーションの作り方まで書いてあって、一冊でとても美味しい内容でした。 今回はここにあるのを色々試みようと思ったのですが、いい形にできず… 本番で使えるように、もうちょい練習をこなしていきたいところ。

カーネギー話し方入門 文庫版

カーネギー話し方入門 文庫版

全部は読めていないのですが、序盤のプレゼンテーションに関する心構えが読んでてとても興味深いものでした。 リンカーンなどの著名人がどのように演説に取り組んでいたのかといったエピソードがあり、それを今回は真似て、スライドの全体の推敲を繰り返して、スライドを作っていくようにしてみました。これは、先の長沢さんの本 自分の場合、ちゃんと言語化したりとか、話の構造を作り込んだりとかがまだまだだな、という気がしています。

Developers Summit 2019 2日目に行ってきた。

一日目はこちら

f:id:satoryu:20190214111830p:plain

昨晩のアンオフィシャル懇親会で飲みすぎたのか、今朝が冷え込んでいたせいなのか、はたまた虫歯のせいなのか、今朝は具合が悪くて、午前はまともに話を聞けなかった。

という気持ちにめげずに、参加したセッションについて忘れないうちに書き残しておきます。

ゲームQAを支える技術~前処理・後処理は大変だが役に立つ~(太田 健一郎[スクウェア・エニックス])

スクエアエニックスの某タイトルで実践した、AI for QAでの泥臭いデータの前・後処理についての話だった。 そもそもゲーム開発について自分は知らなかったし、テストについてもそんなに知識が無いので、色々と新しいことばかりで面白いセッションだった。

ゲームにおけるAIの位置づけは2つある:

  • ゲーム内AI: ゲーム中に現れるキャラクターやナビゲーションで使用されるAI
  • ゲーム外AI: ゲーム開発のために使用されるAI。開発支援ツールやQAなど。

このセッションで扱っているのはゲーム外の方だ。 ゲーム開発におけるQAもまた特殊で、品質についての観点が、期待どおり動いているかどうか、だけでなく面白いかどうかというもの。 後者は定義が難しいので自動化に向かないため、前者の期待通りに動いているかどうかを検証するためにゲーム外AIを使っていた。 ここで、狩野モデルを使っての説明で、前者は当たり前品質で、後者が魅力的品質。つまり、AIを使って、当たり前品質のQAを実装したとうことのようだ。

このセッションで扱っていたのは、とあるタイトルのガチャのQAについて。 ガチャにも決まりがあって、確率をユーザーに表示しなければならず、なおかつその確率どおりにアイテムが排出されることを保証しないといけないらしい。 ここまでの話なら、ひたすらガチャを回して、分布を検証すれば良さそうに思うのだが、ここでもゲーム開発特有の難しさが出てくる。 実機での検証なので画面のキャプチャを撮り、そこに写っている確率の表示を抜き出して、マスターデータの確率の値との比較をする手順となっているのだけど、

  • ゲームの世界観を作り込むため、フォントが独自に作り込まれている
  • Google Computer Vision APIを使っていたが、フォントを学習させるといったことができない
  • アイテムなどの組み合わせによって色味とか変わってくる

と、かなり難しい要素が。自動での認識が怪しいところがあるが、偽陰性より偽陽性の方がゲームとしてインパクトが高いので、そちらを手動で修正できる仕組みで対処。 ここで、とても参考になったのは、「自動処理に一貫させようとせず、手動処理と組み合わせる」ということ。 本来の目的(大田さんの場合、全体の作業時間の短縮)を見失うことなく、全部できなくても部分だけで実現していくスタイルは真似ていきたい。

途中紹介していた前処理大全が泥臭いデータの扱いについて書いてあるそうなので、読んでみよう!

ことばだけでは足りません、描いてシェアして伝えていこう!(高野 明子[Sider])

SiderはSideCIのころからちょくちょく使っていて、いつもお世話になっております。 このセッションのスピーカーの高野もいつからかわからないけど、Twitterでフォローしていて、

  • 絵でわかりやすく技術のことを解説する人
  • お母さんエンジニア

というイメージを持っていた。なんだかわからない一方的な親近感があったので、このセッションには何故か「行かねばなるまい!」という気持ちで参加しました。

セッションタイトルから、「グラレコとか絵のテクニックとかそういう話かな」と勝手に思っていたのですが、予想を裏切る良い話を聞けました。 「インターネットは優しい世界」というのは、同感しかありませんでした。自分もOSS活動の中で、Pull-requestやIssueを貰ったりする時に優しさを感じます。 何のお返しもできない無償なのに、なぜこうも動いてくれたのか、と。 また、自分も今がキャリアの分岐点と思っていたころだったので、先を行く人がどのように考えているのかを知ることができ、大変参考になりました。 「若い人の方が成長が早く、すぐに追い越していく」という時代の中で、自分は競うことしか考えてなかったのですが、自分の持ち味や好きなことを生かしていく道というのがあるのだと思いました。

おそらく、ここには書かれてないような辛いことや苦労したことがあるのだと思います(勝手な妄想)。 それでもなお開発が好きでいられるエンジニアとして歩んでいる人がいる、ということが知れて、とても励みになりました。

あ、でも絵の書き方とか練習のコツとかも教えてほしいなぁ🎨

デブサミ、ありがとう

漆原さんと高野さんの話には、これから先もエンジニアとして開発をやっていきたい自分にとってとても励みになった。楽しいと思えるからこそ、やっぱり続けていきたい。 高野さんの話にも含まれていたし、1日目の角さんと永瀬さんの話でもそうだけど、自分より年下の人たちの方がより新しいことに真っ先に触れているし、そこからの伸び率も高い。 そういった人たちと今後どう付き合っていったらいいのか、そういうことを考えるための参考にしたいと思いました。

毎年そうなんですけど、今年もお腹いっぱいのデブサミでした。 実行委員の皆さん、スピーカーの皆さん、ありがとうございました!

Developers Summit 2019 1日目に行ってきた。

f:id:satoryu:20190214111830p:plain
devsumi2019

毎年恒例のエンジニアの祭典Developers Summit 2019に行ってきた。 今年はスピーカーでも当日スタッフでも無く、ただの参加者です。 やっぱり個人スポンサーになっておくべきという後悔を初っ端からしてしまった。最前席がやはり最善。

全部のコマをセッションで埋めるつもりは無いので、聞きたいところに行き、なるべくAsk the speakerでスピーカーにお話を伺うのがやはり良いなと思いました。 こういうスタイルのイベントを長く続けているのは本当に尊敬する。 その中でも、少しずつスタイルを変え続けていて、今年はスタッフの方々がスタッフTシャツを来てて、お祭りっぽさがあってとても楽しい雰囲気を感じる。 例年だと、スーツのホテルマンみたいな見た目だったから、ちょっと話かけづらかった(個人的見解)。

以下、参加したセッション

❤一生エンジニアを楽しもう❤夢中が最高!! 漆原 茂 [ウルシステムズ]

タイトルにあるようにずっと「一生エンジニア」でいるための方法について、それがなぜ良いのか、そしてそれを裏付ける様々な分野の研究の成果を紹介してくれた。 昨年、ほぼ同じタイトルの話をしていたので、また聞きたいなー、と思って来ました。 けれど、昨年に比べて、追加で新しい話が加わっていたので、非常に面白かった。

プログラマー35歳定年説を否定するものとして、そもそも何かを学ぶことについて年齢での衰えが無いという話、もしそれが劣化するとしたらそれは環境要因の方が大きいという話はだいぶ希望をもらえた。 特に、環境要因として4つ挙げていた。

  1. 毎日プラスになるサプライズがある
  2. 未来を楽しみにしている
  3. 同じ気持ちの仲間がいる
  4. 幸せにあふれている。

幸いなことに今はこの4つを満たせていると思っている。 1は毎日何か新しいことを学ぶ時間をきっちり取るようにチームで決めて、実施している。2は、自分たちの気質上なのかそういう話が多い。3は、1と2がチームでできているので大丈夫だと思う。4は、1から3の状況が自分としては幸せな環境だと思っている。 色々なことがあって、偶発的にできているような感じもするので、どうやったらこれを再現できたり、まわりに拡大できるかは考えないといけないんだろうな。というところで、示唆を与えてくれるセッションだった。

Togetterのまとめは、こちら。

togetter.com

大学におけるイマドキのエンジニア教育 角 征典[ワイクル] 永瀬 美穂[アトラクタ]

産業技術大学院大学や筑波大で行われている文科省プロジェクトenPiT、東工大で実施されている産学連携のPBLであるEDP(エンジニアリングデザインプロジェクト)で教えている実践的な開発の教育についての話だった。

永瀬さんの話では、「学び方を学ぶ」というのがとてもおもしろかった。 大学の教育だと課題(おそらく情報理論とか線形代数のような科目)を教えていくのは、今後も変わらない理論ならいい しかし、ソフトウェア開発やそこで使う技術は数年単位で変化しつづけるので、それを学びつづける必要が出てくる。 なので、「学び方」自体を学ぶ必要があるということだ。午前に聞いた漆原さんの話と少し繋がるところがあって、面白い。 正直、自分が学生だったら、こういう授業がある大学を選びたいなって思った。

角さんの東工大のEDPの話は、詳しくは書籍に書いてあるのでプロジェクト自体についてはそちらを読むとグッとくるんだろうなと思う。 個人的には特に角さんが書いた章の文体というかノリがとても面白いし、そういうふうに面白く書けるだけのプロジェクトだったんだなという風にとらえている。 あと、裏設定として採用につなげているところなんてのも、とても良いと思った。 自分が就職活動中に難しく感じたのは、企業で働くイメージが想像しづらいというところだった。 PBLで擬似的にでも何らかのやりとりをスポンサー企業とやっていれば、かなり働くイメージがつきやすいと思う。 これは学生側だけでなく、企業にとっても同じだろう。

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

途中で参考書籍として挙げていた、金出先生の本も読んでみたいなぁ。

EDPの情報はかなり公開されてるので、あとで眺めてみよう。

titech-edp.github.io

そして、こちらもまたセッションの最中のツイートがToggetterにまとまってる。

togetter.com

アンオフィシャル懇親会

connpass.com

例年懇親会はなく、勝手に集まって飲みに行ったりとかはあったのですが、今年はアンオフィシャルという名の実質公式懇親会が開催されました。 参加者とスピーカーの人たち、そして本当はデブサミ行きたかった人とかデブサミに想いがある人達が集まっていた感じがしました。 ノラLTしたり、コミュニティの告知したりしながら、寿司をつまんでわいわいできたので、とても楽しかった。 途中で、やっとむさんの心理的安全性ゲームで遊んだのだけど、とてもおもしろかった。

運営してくれた滝川さん、会場提供のAkatsukiさん、ありがとうございました!

とりあえず初日はこんなところで。

二日目も書きました。 satoryu.hatenablog.com

Emmet でHTMLをサクッと気持ちよく書く。

Emmet という、HTMLやCSSをサクッと書くためのプラグインがある。 今日はチーム内で、どこまで一度にHTMLコードを生成できるか小一時間くらい盛り上がってしまった。 それくらい気持ちよく書ける。

emmet.io

vimemacsを始め、多くのテキストエディタプラグインが提供されている。 Visual Studio Codeには同梱されているので、すぐに試せる。

CSSセレクターに似た記述でHTMLを生成してくれる。

例えば、

div.container>div.row>(div.col-md-3{Sidebar}+div.col-md-9{Content})

と入力して展開すると、

<div class="container">
    <div class="row">
        <div class="col-md-3">Sidebar</div>
        <div class="col-md-9">Content</div>
    </div>
</div>

他にも、属性を付けたりもできる。

form.form>(label#name[for="name"]{Name}+input[type="name"]+label#email[for="email"]{Email}+input[type="email"]

こんな一行から、

<form action="" class="form">
    <label for="name" id="name">Name</label>
    <input type="name">
    <label for="email" id="email">Email</label>
    <input type="email">
</form>

フォームがサクッとガッツリできる。 なんか気持ち良い。

良いところ

慣れるまで時間がかかるかもしれないし、テンプレートエンジンやVue.jsなどクライアント側でレンダリングするような場合、そこまで複雑なHTMLを書くことは無いかもしれない。 けれど、

  • 記述量が減るし、
  • 閉じタグを忘れることもなくなるし、
  • 単純作業を減らせる

といった利点がある。

頑張って一行で書ききったつもりが、思ったものと違うHTMLを生成してしまうこともあって、その時の残念感もなかなか大きい。 慣れるために、写経で、チートシートを脇に正解がわかった上でそれをEmmetで生成するにはどうするかと考えていくと良さそう。

chartjs-plugin-colorschemesを試してみた。

f:id:satoryu:20190202193530p:plain

ウェブの画面に棒グラフや折れ線グラフを表示するためのJavaScriptライブラリにChart.js というのがあって、とても便利。 しかし、ちょっと悩ましいことがある。 複数のデータをプロットする際に、それぞれの色をどうするか自分で考えなければいけないということだ。

そういった時に使えそうなプラグインを見つけたので、ここで紹介。

nagix.github.io

これはChart.jsで書くチャートのカラーパレットを提供してくれる。 個別に色を指定することは必要ないのはとても嬉しい。

自分は最近はwebpackを使うようにしているので、以下のような感じにセットしてみた。

npm install chartjs
npm install chartjs-plugin-colorschemes

とした後に、使いたいところで、

import 'chartjs-plugin-colorschemes';
import Chart from 'chart.js';

new Chart(ctx, {
   // ... some definitions of chart
        options: {
            plugins: {
                colorschemes: {
                    scheme: 'brewer.Paired12'
                }
            }
        }
   });

のようにする。 このオプションで選ぶschemeは、かなり豊富で以下のページで確認できる。

nagix.github.io

簡単なサンプルを作ってみたので、参考になれば。

github.com

Laravel Valet がPHP 7.3で動かないので、7.2に戻した。

Homebrew でPHPをインストールして、そのまま使い続けているので、気づいたらPHP 7.3に上がっていた。 たまたまLaravel Valetを使ってみようとインストールしてみたところ、試しに作ったLaravel アプリをブラウザで開こうとしても、502 Bad Gateway とNginxのエラーで開けなかった。

GitHub上にIssueが既にあがっていて、ちょうど同じタイミングで同様の現象に直面していた人がいた。

github.com

ここで挙げている手順を試してみたのだけれど、PHP 7.3 では動かせなかった。 ということで、別の方法として提案されている7.2に戻すことで、一応valetを起動できるようになった。

brew uninstall php --force
brew install php@7.2
brew links php@7.2 -f

valet install

php-fpmのプロセスが起動されていれば、正常に動いていることになる。

[2019-01-31 23:13:59]> ps aux | grep php
tatsuya.b.sato   91504   0.0  0.0  4267752    652 s002  R+   11:14PM   0:00.00 grep php
tatsuya.b.sato   89386   0.0  0.0  4484248   1160   ??  S    10:55PM   0:00.00 /usr/local/opt/php@7.2/sbin/php-fpm --nodaemonize
tatsuya.b.sato   89384   0.0  0.1  4486568  17988   ??  S    10:55PM   0:00.22 /usr/local/opt/php@7.2/sbin/php-fpm --nodaemonize
root             89342   0.0  0.1  4484248  14464   ??  Ss   10:55PM   0:00.09 /usr/local/opt/php@7.2/sbin/php-fpm --nodaemonize

PHP 7.3で実行していた時、エラーログ(~/.config/valet/Log/nginx-error.log)に以下のエラーが出ていたのだけど、これを調べていけば解決方法がわかるのかな。なんでfastcgiって文字が出ているのだろうか。

2019/01/31 12:44:05 [error] 58693#0: *1 connect() to unix:/Users/tatsuya.b.sato/.config/valet/valet.sock failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/Users/tatsuya.b.sato/.config/valet/valet.sock:", host: "blog.test"
2019/01/31 12:44:05 [error] 58693#0: *1 connect() to unix:/Users/tatsuya.b.sato/.config/valet/valet.sock failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/Users/tatsuya.b.sato/.config/valet/valet.sock:", host: "blog.test", referrer: "http://blog.test/"