映画館のイス

映画館のイスが好きです

シンプルで振り返りに集中できるKPTツールを作った

何を作ったか

Simple KPTというKPTツールを作りました。

simple-kpt.com

KPTというのは振り返りを行う際に用いられるフレームワークで、Keep, Problem, Tryをそれぞれ挙げることで振り返りを整理する手法です。

Simple KPTのボード画面
Simple KPTのボード画面

GitHubリポジトリは以下です。

github.com

デモ

ログイン不要で触ってもらえるデモボードがあるので、ぜひ触ってみてもらえると嬉しいです。

https://simple-kpt.com/demo

作った動機

振り返りに使うツールについて、あまりしっくりこないなーという感触がありました。

Miroのようなホワイトボード形式だと自由度が高すぎてカードの配置やテキストサイズの調整に手間取り、変なところでつまづいて振り返りに集中できないことがありました。GitHub ProjectやTrello, Notionなどのようなカンバンだと汎用的であるがゆえに多機能すぎて振り返りをするのにはノイズになったり、逆に痒いところに手が届かなかったり…といまいちKPTにフィットしません。

こういった課題を解消して、必要以上の自由さや機能を排除したシンプルなKPTツールが欲しいと考え、Simple KPTを作りました。

機能

「シンプル」が言い訳にならないように、振り返りに必要な機能はしっかり盛り込むことを意識しています。

  • 🔗 振り返りボードの共有
    • 振り返りボードのURLを共有することで振り返りに参加者を招待できます
  • ⚡️リアルタイム同期
    • アイテムの追加や変更が参加者全員にリアルタイム同期されます
  • ⏱️ タイマー
    • 振り返りのアイテムを書き出す時間をタイマーで設定できます。タイマーもリアルタイムに同期されます
  • 🙈 他の参加者のカードを隠すモード
    • タイマー起動時に他の参加者のカードを非表示にできます。他の人の意見に引っ張られずに自分の考えを出しやすくする狙いです
  • 👍🏻 Vote機能
    • 参加者の関心事や課題意識を可視化し、議論すべきアイテムの優先順位づけに活用できます
  • 📥 エクスポート
    • 振り返りボードをMarkdownやCSV形式でエクスポートできます
  • 🤖 AIサマリー
    • 振り返りの内容をAIによって要約でき、次回の振り返りに向けてのアドバイスももらえます
  • ✅ Tryの進捗管理
    • ボード横断でTryのステータスを管理でき、Tryを継続的に追える仕組みを備えています
  • 📈 アイテム数推移のグラフ表示
    • Keep, Problem, Tryのアイテム数の推移をグラフで追うことができ、振り返りを継続するモチベーションを高めてくれます
  • 🌓 ダークモード
    • 好みに合わせてテーマを変えられます
  • 🌐 多言語対応
    • 日本語と英語に対応しています

こだわりポイント

振り返りの継続を支える仕組み

振り返りを継続させるための仕組みをいくつか実装しています。

振り返りで出たTryが忘れられてしまうのはありがちな問題かと思います。Simple KPTではTryリストという機能で、ボードを横断してTryのステータスを一覧で確認できます。以前の振り返りで出たTryが放置されることを防ぎ、実際に改善へ繋げていくための仕組みです。個々のボード内で管理する方法だとボードが増えるにつれて過去のTryが埋もれてしまうため、ボード横断で一覧できる形としています。

Tryリスト
Tryリスト

また、Keep・Problem・Tryのアイテム数推移のグラフ表示を実装しています。振り返りを重ねるごとにグラフが蓄積されていくことで、これまでの実績を視覚的に確認でき、継続のモチベーションにつなげることを狙いとしています。

アイテム数推移グラフ
アイテム数推移グラフ

意見を出しやすくする仕組み

振り返りの際、他の人が書き出している内容がつい気になってしまい、自分の意見に対して自信が揺らいだり、書き出しにくくなってしまうことはないですか？（自分はあります）

そういったことを防ぎ、率直に意見を出し合える仕組みとして「他の参加者のカードを隠すモード」を実装しました。タイマーを設定する際のオプションとして提供しています。

このモードにより、タイマー終了後に全員のカードが一斉に表示されるようになるため、それぞれの率直な意見をもとに振り返りを進められます。

タイマー設定ダイアログ
タイマー設定ダイアログ

アクセシビリティ

さまざまな人が、さまざまな環境で使えることが重要と考えるため、アクセシビリティには注意を向けて開発を行いました。

カラーコントラストはWCAG AAの基準をクリアし、キーボードによる操作もほぼすべてに対応できています。また、タッチデバイスの操作にも対応しています。スクリーンリーダーを使う環境においても、適切なaria属性を付与し、操作者に必要な案内やフィードバックを行えるように対応しています。

全ページでLighthouseのAccessibilityのスコアは100点、WAVE（アクセシビリティ検証ツール）によるチェックでもエラー・アラートともに0件となっており、一定の水準は達成できているんじゃないかと考えています。

Lighthouseスコア
Lighthouseスコア

WAVEのチェック結果
WAVEのチェック結果

ただ、キーボード操作でカードをドラッグアンドドロップできない点や、スマートフォンでの使用が実質的に困難な点は課題があります…これは今後の改修ポイントとしたいですね。

URL共有による招待は安全？

機能紹介で触れたとおり、Simple KPTではURLの共有でボードに参加者を招待する方式を採っています。ボード参加にパスワード等の入力を必要としていません。この方式って安全なんでしょうか？ちょっと考えてみます。

ボードを識別するIDにはUUIDv4を使っており、存在するボードのUUIDを探し当てることは現実的に不可能で安全と考えます。

UUIDv4は122ビットのランダムな値を持ちます。仮に100万ボード存在するとして、毎秒1億回の総当りをしても1つのボードを見つけ出すのに平均約1700兆年もかかる計算となり現実的ではありません。

それよりも、誤ってパブリックな場所にURLを公開してしまうリスクが懸念されます。URLの取り扱いには注意が必要ですが、URL共有により招待を行う方式は多くのアプリケーションで採用されており、広く受け入れられている共有方式です。

Simple KPTでは、UUIDの特定が実質不可能なことを踏まえ、振り返り参加メンバーの招待をURLひとつで完了できる手軽さを重視してこの方式を採用することにしました。

おわりに

Simple KPTはKPTに特化したツールですが、振り返りの手法はKPT以外にもいろいろあります。 将来的には他の手法にも対応したいなーという思いもあるのですが、そうなるとSimple KPTという名前をどうするか問題が出てきますね 😂

でもまずは、このKPTツールを一度触ってみてもらえると嬉しいです。

そしてできればフィードバックをください（Issueでもお問い合わせフォームでも歓迎です）

simple-kpt.com

よろしくお願いします！

オンラインでAWSの認定試験を受ける際に注意したほうがいいこと（SAA-C03に合格しました）

tl;dr

  • 試験の予約はお早めに
  • 試験開始前の手続きに時間がかかるので30分前にチェックインしたほうが良い
  • 写真付き身分証明書にマイナンバーを使う際は裏面を撮ってはいけない
  • 有線LANでの接続を勧められるが、ノートPCを持ち上げてデスク周りを映すことを要求されるので十分に長いLANケーブルを用意するか安定して接続できるWi-Fiを使用したほうが良い

AWS Certified Solutions Architect - Associate (SAA-C03) に合格しました

先日、SAA-C03を受験し977点という思いもよらぬ高得点で合格することができました。運が良かったのもありそうですが、3ヶ月の勉強が報われてよかったです。

合格できたのは良かったのですが、試験前のステップでちょっとしたつまずきがありました。 スムーズに試験を開始できなかった経験を踏まえ、試験前にどんなことをやるのか、どんなことに注意しといたほうが良いのかといった点を共有したいと思います。

試験前の注意事項

試験の予約

試験の予約は早めに済ませたほうが良いです。自分の場合、1週間くらい先の日程で予約したいと考えていたのですが、1ヶ月くらい先まで土日の枠が埋まっており希望の日程で予約できませんでした。平日であっても半月先くらいを見ないと空いていなかったので、土日に受験したい人はかなり早めに動かないと希望の日時で受験できないと思われます。

まだ勉強不足かな…と思われるくらいの時期に予約は先に済ませておいたほうが良さそうです。

試験当日の注意事項

身分証明書のアップロード

写真付き身分証明書を写真にとってアップロードする必要があります。このとき、表面と裏面の撮影を手順で促されるのですが、マイナンバーカードを身分証明書に使う場合には注意が必要です。

促されるままに裏面を撮影してアップロードしたところ、チェック段階で「裏面は撮らずに表面のみをアップロードしてください」と指摘が入りました。表面、裏面の両方の欄にマイナンバーカードの表面の写真をアップロードすることで良いとのことでした。

そういった説明は画面上には表示がなかったと思うのでご注意ください。

写真によるデスク周りのチェック

デスク周りの写真も撮影してアップロードを行います。私は、事前にデスク周りにはあまり物を置かないほうが良いと聞いていたので、おおかた不要なものは片付けておきました。しかし、チェックの段階でいくつか指摘を受けて片付けることとなりました。

指摘を受けたのは、ティッシュ箱、ウェットティッシュ、エアコンのリモコンです。これらは手の届かない場所に移動することになりました。

逆にこれは大丈夫かなと不安があったもので指摘を受けなかったのは、バスタオルを被せた外付けモニタでした。私の場合、デスク近くの本や小物といったものは届かない場所にあらかじめ片付けていたのですが、布やバスタオル等で覆っておけば大丈夫だったのかもしれません。

Webカメラによるデスク周りのチェック

写真に加えて、Webカメラによるデスク周りのチェックも求められました（もしかしたら、写真の時点できれいに片付いていればスキップされるのかもしれません）。

このとき、ノートPCにつないでいたLANケーブルの長さが足らず、LANケーブルを抜いてWi-Fi接続にしようと思ったのですが、LANケーブルを抜いた時点でWebカメラの映像がブルースクリーンになってしまったようでPCの再起動が必要となってしまいました…

これはかなりの時間のロスとなるので、有線LANを用いる際には十分にご注意ください。チェアの後方からデスク全体をWebカメラで映す必要があるので、それなりに余裕を持った長さのLANケーブルが必要となります。

スマホの置き場所、腕時計のチェック

身分証明書やデスク周りの写真のアップロードが完了した後には、スマホは手の届かない場所に置く必要があり、どこにスマホを置いているかについてもWebカメラで確認されます。

また、腕時計の着用有無もチェックされるため、あらかじめ外しておくことをおすすめします。

受験中の注意事項

音や声を出さない

音や声を出さないことは注意事項として事前に示されているのですが、長丁場の試験となるため、集中力が低下してきた際に問題文を小声で読み上げてしまった場面がありました。その際にすかさず「声を出さないで」とチャットで注意を受けました。

口から少し漏れる程度の小声ではあったのですが、かなり厳しく見ているようなのでご注意ください。

お疲れ様でした

私の経験したつまずきポイントは以上です。色々書いていますが、監督官(?)の人がボイスやチャットでサポートしてくれるので、それに指示通り従えば大丈夫かと思います。

私の場合、試験開始30分前にチェックインしたのですが試験前のステップに40分くらいかかってしまったので、試験時間が10分短くなってしまった…とかなり焦りました。しかし、ちゃんと試験時間は130分フルで受けることができました。なので、焦らず淡々と指示通りやれば大丈夫です。

私の勉強方法

他の方々がいろいろ書いてくれているので、私があらためて書く必要はないかもですが一応自分がどんな勉強をしていたか書いておきます。

まず以下のテキストを1巡だけ通して読みました。

AWS認定資格試験テキスト　AWS認定ソリューションアーキテクト - アソシエイト　改訂第3版

AWS認定資格試験テキスト　AWS認定ソリューションアーキテクト - アソシエイト　改訂第3版

Amazon

その後、Ping-tのSAAの問題集を隙間時間にやっていました。

【試験レベル】Well-Architected Frameworkに基づいた設計 の項目が実際のSAAの出題に近い形の問題となります。こちらを重点的にやることをオススメします。自分はほぼこの項目だけやっていました。

ある程度Ping-tの問題を解いていると、出題傾向が掴めると思うので、重要なワードを何らかのメモツールに書き起こして後から見返せるようにしておくと重要ポイントを復習しやすいと思います。

おわりに

以上です。これから受験するみなさん頑張ってください！

自分は気が向いたらSAPも受けてみます！

Vimで正規表現を使ってスネークケースとキャメルケースを相互変換する

Vimでスネークケースとキャメルケースを相互に変換する方法を紹介します。

スネークケース -> キャメルケース

以下のような文字列を変換する

hoge_fuga_piyo_foo_bar_baz

コマンドラインモードで以下のように入力

:%s/\v_(.)/\u\1/g

結果

hogeFugaPiyoFooBarBaz

スネークケース -> アッパーキャメルケース(パスカルケース)

以下のような文字列を変換する

hoge_fuga_piyo_foo_bar_baz

コマンドラインモードで以下のように入力

:%s/\v(^|_)(.)/\u\2/g

結果

HogeFugaPiyoFooBarBaz

キャメルケース -> スネークケース

以下のような文字列を変換

hogeFugaPiyoFooBarBaz

コマンドラインモードで以下のように入力

%s/\v([a-z]\@=)([A-Z])/\1_\l\2/g

結果

hoge_fuga_piyo_foo_bar_baz

雨は夜更け過ぎにコミットログへ変わるクソアプリを作った

この記事はクソアプリ2 Advent Calendar 2019 - Qiitaの24日目の記事です。

f:id:hogesuke_1:20191223234603p:plain

作ったクソアプリ

christmas-eve.hogesuke.net

「雨は夜更け過ぎにコミットログに変わる」クソアプリを作りました。

聖夜に空を見上げるとコミットログがふわふわと降ってくる。

あぁ今年はこんなコードを書いたっけなぁと思いを馳せながら眺める光景はきっと美しく、荒んだ心を癒やしてくれるに違いないと思って作りましたがそんなことはありませんでした。

おわり

これは何か

GitHub APIを通してリポジトリのコミットログを取得し、そのコミットログを雪とともに降らせるアプリです。

f:id:hogesuke_1:20191223234722p:plain

右上にリポジトリ名を入力してEnterすると、好きなリポジトリのコミットログを降らせることができます（Privateリポジトリは不可）。

試してみてくれると喜びます。

なにで作ったか

three.jsを使ったWebGLのアプリです。

PCではマウス操作で、AndroidやiOSではジャイロを使って全方位を見渡せるようになっています。 three.jsで提供されているクラスやライブラリを使って、今回のアプリは簡単に実装可能でした。

実際のところ3Dに関する知識やWebGLに関する低レイヤーな部分についてはほとんど分かっていないのですが、それでも何となく動くものが作れるというのはthree.jsのすごさでしょう。

コードは以下にあります。

github.com

苦労した点 その1

とにかくロードに時間がかかる

three.jsはminifyしたものでも約600KBのファイルサイズです。
その他の今回使用したライブラリを含めたbundleしたJavaScriptファイルは、nginxでgzipして配信しても約500KBとなっています。

webpackのTree Shakingで使用しないコードを削ぎ落とせないか考えたのですが、現時点においてはTree Shakingに対応できていないようでした。

参考: https://discourse.threejs.org/t/three-js-file-size-when-importing-via-npm-and-bundling-with-webpack/8904/2

three.jsの本体だけでなく、アセットもファイルサイズが大きくなりがちです。

このアプリでは背景に360°の全天球画像を使用しています。
背景を画面いっぱいに表示するため、それなりの解像度が必要かつ、Retinaでも表示することを考えると解像度を落としづらいという問題があります。
そのため、背景画像だけで485KBにもなってしまいました。

fontもかなりのファイルサイズになります。
three.jsでtextをレンダリングするには、fontデータをJSON形式に変換したものが必要です(これはfacetype.jsで生成できます)。
欧文フォントであれば数十キロバイト程度ですが、和文フォントとなると数MB〜十数MBにもなります。 今回使用した和文フォントのJSONは、gzipで配信してもなお2MBの巨大ファイルとなってしまいました。

これらのファイルをダウンロードするにはかなりの時間を要するため、なんらかのごまかしが必要です。

ローディング時間をごまかす

このアプリで使用するすべてのリソースサイズを合計すると3MBにもなります。
環境にもよりますが、すべてのロード完了までには結構な時間がかかってしまうでしょう。
特にWifiに接続していないモバイル環境では致命的です。

そこで、いくつかのステップでユーザーに離脱されないようにごまかしを施しました。

script要素のdefer属性

まず、メインのJavaScriptファイルとなるbundle.jsのscript要素にdefer属性を付与し、500KBのbundle.jsのロード完了まで「何も表示されない」という最悪の状況を回避します。

よく意味が分からないテキストを表示

つづいて、よく意味が分からないテキストを表示し、時間稼ぎをします。
「こいつは何をいっているんだ？」という疑問でほんの少し時間を稼げたら幸いです。
「雨は夜更け過ぎにコミットログへ変わる」がそれです。

ローディングステータスの表示

それだけでは時間が稼ぎきれないので、ローディングステータスを表示します。
フリーズしている訳ではなく、確実にロードが進行していることをユーザーに伝えます。

単純なスピーナーでは進行状況を伝えられないので、全体のアセット数とロード完了したアセット数をテキストで表示しています。

f:id:hogesuke_1:20191224000659p:plain

three.jsで提供されているLoadingManagerを使用すると、アセットのローディング状況をイベントで取得可能です。

参考: https://threejs.org/docs/#api/en/loaders/managers/LoadingManager

とりあえずサンプルリポジトリのコミットログを降らせる

ひとまずアプリを動かせる最低限のローディングが完了したら、サンプルとなる自前のリポジトリのコミットログを降らせてしまいます。

このサンプルを動かしている裏では、ファイルサイズの大きい和文フォントのJSONをロードしており、ユーザーが任意のリポジトリを指定した際に日本語を表示できるように備えます。

サンプルリポジトリのコミットメッセージには英字のみを使用し、和文フォントを必要としないためサイズの小さい欧文フォントでまかなっています。

以上

このような感じでごまかしている気でいますが、1Mbps以下の通信速度のような環境ではロード完了までかなりの忍耐が必要になります。

昼休みなどの混み合う時間帯は厳しいかもしれません。

苦労した点 その2

テキストのオブジェクト生成処理が重い

テキストのオブジェクト(TextGeometry)の生成処理がとても重く、かなりの時間を要します。

100文字前後のテキストで百数十ミリ秒の処理時間がかかっていました。
これはMacBookPro 2019で実行した結果なので、スマホなどの非力なデバイスだとさらに遅くなります。

このアプリでは最大100コミットログを表示しているため、すべてのTextGeometryを生成するのに数秒〜数十秒かかります。

JavaScriptはシングルスレッドで動作するため、TextGeometryの生成処理が動いている間はrequestAnimationFrameの呼び出しがされずフリーズしてしまいます。

WebWorkerに処理を委譲しようとするも失敗

これを解決するため、TextGeometryの生成処理をWebWorkerに委譲できないか試してみましたが失敗しました。

WebWorkerで生成したオブジェクトをメッセージで送受信する際に、そのオブジェクトが持つ関数が失われてしまったためです。
これはメッセージをJSONにシリアライズする際に、関数を省略してしまう仕様によるものでした。

関数を残したままJSON化させる方法もあります。
参考: https://qiita.com/suetake/items/52ec9d22e978ceb3111c

しかし、詳細は忘れてしまいましたが、この方法では別の問題が発生しうまくいきませんでした。

別の方法として、Object3DクラスのtoJSONで取得したJSONをWebWorkerから送信し、受信側でJSONLoaderを用いてdeserializeする方法を試してみましたが、TextGeometryには対応しておらずこれも失敗に終わりました。

下はうまくいかなかったコードの例です。

const geo = new THREE.TextGeometry('hogehoge'); 
const serialized = geo.toJSON();
const jsonLoader = new THREE.JSONLoader();
const parsed = jsonLoader.parse(serialized); // ここのパースで「TextGeometryは未対応」というエラーとなる
const deserialized = parsed.geometry;

TextGeometryをTextBufferGeometryに変更

その後、調べているとTextBufferGeometryというものの存在を知りました。

そもそも、GeometryはBufferGeometryを扱いやすくしたものらしいのですが、処理コスト的はBufferGeometryに劣るということでした（よく分かっていない）。

TextGeometryをTextBufferGeometryに変えてみるとそれだけで、おおよそ5分の1の処理時間になりました。
根本的な解決にはなっていませんが、ひとまずパフォーマンスの問題は軽減されたので妥協しています。

three.jsを初めて触ってハマった点

いくつか、はちゃめちゃにハマった点があるので、これからthree.js(WebGL)をやろうとする方が同じ轍を踏まないように記してみます。

スマホでジャイロが機能しない

これは、httpsでないページではDeviceOrientationEvent（ジャイロ）の検知が許可されないという問題によるものでした。

Let's encryptを使うなどしてhttps化する必要があります。

Mobile Safariでジャイロが機能しない

Mobile Safariはジャイロがデフォルトで無効になっているため、iOSの設定からジャイロ機能をONにする必要があります。

参考: https://tips.spacely.co.jp/ios12-2_safari_gyro/

サンプルコードが動かない

使っているthree.jsのバージョンが異なることによって動かない場合がありました。

three.jsはセマンティックバージョニングを採用していないため分かりづらいのですが、バージョンによっては破壊的変更が含まれます。

サンプルコードで使用しているバージョンを記載してくれていることが多いので、それを確認するようにしたほうが良さそうです。

特定の端末でのみ動作しない

これはthree.jsは関係ない話ですが…

webpackのdevtoolをevalにしてビルドしたjsをiPhoneで動作確認したところ動作しない事象に遭遇しました。

devtoolを'inline-cheap-source-mapに変更したところ問題が解消されたため、おそらく特定のブラウザの特定のバージョンにおいてevalでの解釈に問題があり動作しなかったと思われます。

特定の端末で不可解な事象に陥った場合にはwebpackを疑ってみるのも良いかもしれません。

おわりに

素敵なクリスマス・イブを！！ 🎄🎁🥂🎅🏻✨

christmas-eve.hogesuke.net

サブ4目指して初マラソンを走ったら惨敗した話

初マラソン

3/10に初のフルマラソン挑戦である「はなももマラソン」に出場しました。

フルマラソンは初でしたが、ハーフマラソンは3回経験があります。
ハーフマラソンの自己ベストは1時間45分（キロ5分）です。

フルマラソンは、サブ4を目標としていました。
ハーフマラソンの記録からして、この目標はそれほど難しくないものと考えていました。

結果

5時間58分

めちゃくそに考えが甘かったです。完全に惨敗しました。

序盤、サブ4ペースであるキロ5分40秒を目安に走っていました。
しかし、参加者の多いレースであるため、スタート直後はなかなか自分のペースで走れません。
5km地点ぐらいでやっと自分のペースの集団に位置取りでき、やっとここからが本番という感じでした。

そう思ったのも束の間、10km地点ぐらいで異変が生じました。キロ5分40秒という自分のハーフマラソンのペースから比べてもだいぶゆるいはずでしたが、息が苦しくペースを保つのがやっとという状況でした。

その後、14km時点で苦しさから逃れるようにトイレに立ち寄り、これはもうサブ4は無理だなとこの時点で諦めざるを得ませんでした。

18km地点くらいで、ついに歩いてしまいました。ハーフでも一度も歩いたことはありませんでしたが、1週間ほど前に発症した風邪が、マラソン当日もまだ完治していなかったのだと思われます。
そこからは少し走っては歩くを繰り返すレースとなりました。

そして、苦しさと同時に空腹と喉の渇きも強く感じていました。
当日の朝、腹痛でろくに朝食をとらずにレースに臨んだため、序盤からエネルギー切れを起こしていたのです。 20km地点で提供されたバナナと、沿道の方にもらったチョコレートに大いに助けられ、エネルギーを回復し耐え忍びました。

25km地点くらいからは足の痛みも大きくなりました。一度に走れる距離もどんどん短くなり、200mほど走っては500m歩くぐらいになっていたと思います。
ここからはひたすら痛みとの戦いでした。

30km地点でのこり12km、時間にして2時間（この時点ではキロ10分〜12分ペースでした）もあることに半ば絶望していました。足が痛いしタイムもボロボロだし、棄権の方法が分かっていれば棄権していたかもしれません。しかし、どうやって棄権するのか分からないため、それも叶わずただ歩き続けました。

35km地点ぐらいで沿道の方から梅干しをもらいました。この梅干しが最高にうまかった。この梅干しは人生通してうまかったものランキング、ベスト10に入るだろうと思われます。

40km地点付近で「残り10分で関門が閉じらますよ」と声をかけてもらいました。幸い、関門まで100mくらいまで来ていたのでクリアできたのですが、危うく関門でリタイアとなる状況にちょっと情けなさを感じました。

40km地点を超え、残り2kmだけとなったことろで、実はまだ走る余力があるのではないか、という謎の活力が湧いてきました。足の痛みを無視して普段のフォームで走ってみると、意外と走れる。
もうこのまま走ってゴールしてしまえと、最後の2キロはキロ5分30分ぐらいのペースで走りました。

結果、5時間58分。
当初のサブ4という目標には遠く及ばないですが、フルマラソンの厳しさを学べたことは収穫でした。

反省点

  • 前日はよく眠る
    • よく眠るための対策を取ること
  • 朝ごはんをよく食べる
    • 沢山食べること
    • 走る前にもゼリー飲料で補給しておく
  • エイドをもつこと
    • ゼリー
    • チョコレート
    • 塩飴
  • ドリンクをもつこと
    • 給水所だけでは足りなかったため
  • 序盤はペースを抑える
  • 真冬のレースにする
    • 自分は暑がりで気温が１桁台でないと汗をかきすぎてしまうため
  • 長距離練習をもっとする
    • 脚の筋力が不足していたと感じるため

次の目標

サブ4

次はサブ４を達成したいです。

仕事中にTwitterを見てサボっていることをSlackに晒しだすChrome拡張を作った

先日、slack-chikuryというChrome拡張を公開しました。

chrome.google.com

これはなにか

仕事中にTwitterなどを開くと、Slackのstatusにサボっていることを晒しだすChrome拡張です。

動作例

アイコン

f:id:hogesuke_1:20190314192309p:plain

数字はその日の合計サボり時間(分)です。

Slack

f:id:hogesuke_1:20190314192923p:plain

表示しているページのタイトルも表示されます。仕事に関係のないページを見ているのもバレバレです。

なぜ作ったか

仕事の手が止まったとき、ついTwitterを開いてしまうことはないでしょうか。自分はあります。

ビルド、テスト、CI、npm install、docker-compose upなど、あらゆる場面で細かな待ち時間が発生し、そのたびにTwitterを開く誘惑に駆られ、誘惑に負けます。

そして、その時間が生産性を落としているように感じました。

自分の意志では改善を期待できないため、外からの監視の目を頼り、脅威を作り出すことで改善を試みる狙いです。

使い方

Chrome拡張のインストール

以下のリンクから拡張をインストールしてください。

https://chrome.google.com/webstore/detail/slack-chikury/bgeefbiianafjfckcacgjkeglnijljoi?hl=ja&gl=JP

SlackのOAuth tokenを発行する

Slackのstatusの変更リクエストを実行するために、OAuth AccessTokenが必要です。

Slackのappsページを開きます。

https://api.slack.com/apps

Create New Appをクリック

f:id:hogesuke_1:20190314184351p:plain

App名を入力、WorkSpaceを選択し、 CreateAppをクリック

f:id:hogesuke_1:20190314184601p:plain

Add features and functionalityのPermissionsをクリック

f:id:hogesuke_1:20190314184916p:plain

ページ中頃のSelect Permission Scopesで Modify user’s profile を選択し、Save Changes

f:id:hogesuke_1:20190314190020p:plain

ページ上部のOAuth Tokens & Redirect URLsで、Install App to Workspaceをクリック

f:id:hogesuke_1:20190314190627p:plain

Authorizeをクリック

f:id:hogesuke_1:20190314190726p:plain

OAuth Access Tokenをコピー

f:id:hogesuke_1:20190314190941p:plain

OAuth tokenを設定する

Chrome拡張のポップアップを表示し、コピーしたOAuth Tokenをペースト f:id:hogesuke_1:20190314192016p:plain

オプション

拡張のポップアップより以下を設定できます。

f:id:hogesuke_1:20190314194808p:plain:w400

  • Time Range
    • この拡張を有効にする時間の範囲です
  • Day of the week
    • この拡張を有効にする曜日です
  • Emoji
    • チクり時にstatusに表示するEmojiです
  • Sabori URLs

効果はあったか？

Twitterを見る時間はゼロになりませんが、衆目に晒されている感覚を得ることで時間はだいぶ削減されました。

1日のサボり時間を数字で見れるので、自分がどれだけ集中していないかの指標とし、サボり傾向にあるときは「Twitterを見る」以外の方法でリフレッシュできないかといった対策を試みています。

おわりに

みなさんもサボりを晒して生産性を上げていきましょう。

chrome.google.com

Issue, PullRequestも歓迎です。

github.com

Swagger UIをすこしだけ見やすくしてみた

OpenAPIを採用するプロジェクトが増え、Swagger UIで生成されたAPIドキュメントを見る機会も多くなりました。

目にする機会が増えると、ドキュメント上の見づらい部分（個人の感想です）が少し目に付きます。

そこで、Swagger UIのドキュメントをStyleをイジって「すこしだけ」見やすくできないか試みてみました。

Style変更箇所

見づらいと感じたのは以下の点です。

  • RequestやResponseのExample
  • Responseのテーブル

これらの箇所のStyleを変更してみました。

RequestやResponseのExample

f:id:hogesuke_1:20190120180803p:plain

Before

フォントサイズが小さく、weightが太めに設定されているため、文字が潰れて見づらい。

After

  • フォントサイズを大きめに変更
    • 12px -> 15px
  • weightをnormalに変更
  • フォントを等幅のものに変更

Responseのテーブル

f:id:hogesuke_1:20190120233931p:plain

Before

Statusコードとその説明までの横幅が広く、目を動かす必要がある。
また、行の区切りを示す表示がなく、どこまでがどのStatusコードの説明か判別しづらい。

After

  • Statusコードを右寄せにし、説明の近くに配置
  • 行の区切りにborderを表示

Styleの全容

.swagger-ui .opblock-body pre,
.swagger-ui .response-col_description__inner div.markdown {
    font-size: 15px;
    font-style: normal;
    font-weight: normal;
}

.swagger-ui .opblock-body pre {
    font-family: "Courier New", Consolas, monospace;
}

.responses-table .response {
    border-top: 1px solid rgba(59,65,81,.2);
}

.swagger-ui .response-col_status {
    text-align: right;
    padding-right: 15px !important;
}

.swagger-ui table tbody tr td {
    padding-bottom: 10px;
}

.swagger-ui .model {
    font-size: 14px;
}

このStyleを適用する方法

このStyleを使ってみたい！、という方がいるかどうかはさておき、このStyleを適用するための方法をご案内します。

ユーザースタイルシートを適用するためのブラウザ拡張がいくつかあります。
それらをブラウザに導入することで、独自のStyleをwebページに適用することが可能です。

個人的には Stylus という拡張をおすすめします（Chrome, Firefoxともにあり）。

以下に、Stylusを使用する場合の具体的な手順を説明します。

Stylusのインストール

以下のリンクより拡張をブラウザに追加します。

Chrome chrome.google.com

Firefox addons.mozilla.org

Styleの追加

以下のリンクよりStyleをインストールします。

https://userstyles.org/styles/168032/swagger-ui-slightly-easy-to-see

f:id:hogesuke_1:20190121005234p:plain

完了！

以上で完了です。

実際にSwagger UIのドキュメントを開いて、Styleが適用されているか確認してみてください。

https://petstore.swagger.io/#/pet/addPet

おわりに

もっとこうしたほうが良いのでは？とか、いやいやあなたのStyleのほうが見づらいよ！、とかご意見あればお待ちしております。

twitter.com