仕事用ディスプレイを 4K で作業してみました

ご挨拶

はじめまして。このブログで初登場となりますエンジニアの池田 (@yukung) です。どうぞよろしくお願いします。

突然ですが最近、 Amazon プライム・ビデオで「有田と週刊プロレスと」を見始めました。これが非常に面白くてハマっておりまして、今は風呂場に iPhone やタブレットを持ち込んで 1 話分見るのが一日の日課になっています。

私は元々プロレスファンというわけではなく、試合会場に観戦に行ったこともありません。ただ、中学生くらいの頃に友達の家や自分の弟と一緒にスーファミ版の「ファイヤープロレスリング」シリーズやプレステ版の「闘魂烈伝」シリーズをプレイして長州力選手や藤波辰爾選手、闘魂三銃士などを知った程度のニワカです。「闘魂烈伝」で印象に残っているのは、私が操る長州力選手のリキ・ラリアット ​💪​ ¹ を弟の操るキャラに喰らわせまくり、結果弟が泣き出して喧嘩になる、という青春の淡い思い出が思い出されます。

そんな私でも、有田の溢れるプロレス愛と、丁寧で想像以上に分かりやすい解説（普通にプロレス関係なく、事前知識無しの相手に対するプレゼンの勉強になると思って見てます）によって、レスラー同士の因縁や団体同士の抗争の経緯を知ることができ「あぁ、あのキャラレスラーにはそんなドラマがあったのか💡 ​」と毎回膝を叩いてカタルシスを得る毎日です。その昔、たけし軍団や、あの眼鏡屋さんのメガネスーパーがプロレス団体やってたって知ってました？²これを知らなかった人は今すぐ「有田と週刊プロレスと」見るといいと思います。それだけ！！³

4K ディスプレイはいいぞ

このままでは初エントリが単なるプロレスブログになってしまい、流石に弊社の並河に怒られてしまいますので、唐突に 4K ディスプレイの話をしようと思います。

弊社では入社時に開発用マシン (Mac/Win 選べます) と同時に、ディスプレイが貸与されますが、現在私が貸与されているディスプレイは LG の 4K ディスプレイ (32UD60-B) です。⁴ これに MacBookPro 13inch を接続しているわけなんですが、この体験が素晴らしく思ったため、ブログに書こうと思った次第です。

ディスプレイ近影

ディスプレイ 32UD60-B のスペック

項目	スペック
画面サイズ	31.5インチ
解像度	3840×2160
パネル	VA（非光沢）
スピーカー	有（5Wx2）
入力	HDMI2.01 / DisplayPort1.21
光度	300cd/㎡
応答速度	4ms(GTG)
付属品	HDMIケーブル / DisplayPortケーブル

初めて 4K ディスプレイ使ってみた感想

とにかくでかい！

私は自宅ではフル HD ディスプレイ 2 枚を並べて使っていますが、私にとって 4K ディスプレイの利用は初めてでした。そのため利用し始めた当初はあまりに画面の領域が広く、立ち上げている各アプリケーションのウィンドウ配置にかなり戸惑いがありました。個人の感じ方次第かもしれませんが、私はアプリケーションウィンドウをどこに置いてもフワフワ浮いているような気がして、落ち着かないというか位置が定まりませんでした。

また、文字が小さくなるため、読めないほど潰れないか心配でしたが、そこは 4K ディスプレイ、文字の潰れやかすれはなく、文字が小さくても思った以上に読めることが分かり、安心しました。個人的には、 31.5 インチくらいが作業領域の広さと文字の大きさのトレードオフのバランスが良く、これ以上大きくなると文字の潰れではなく文字が小さくて読めなくなる気がしています。

正面から見た図。普段利用している距離感もこのくらいの視野で利用している。 IDE やターミナルの文字も視認できている。（フォントサイズは 15pt で利用しています）

一点だけ、 MacBook Pro を HDMI 経由で USB Type C で接続するために USB-C Digital AV Multiportアダプタ を利用していますが、この場合はリフレッシュレートが 30Hz での接続となるため、マウスポインタを動かした際のちらつきが発生しまう問題があります。私は使っているうちに慣れてしまい気にならなくなってしまいましたが、気になるようであれば、別途 DisplayPort で接続すれば 4K/60Hz で表示されるようです。こちらも気が向いたら試してみようと思っています。

アプリケーションウィンドウの配置

利用当初に感じていたアプリケーションウィンドウの位置が定まらない問題ですが、個別のウィンドウ同士が被って表示されないようだと、結局 ⌘ + Tab や ⌘ + F1 でアプリやウィンドウを切り替える必要があり、その度作業が中断されてしまい、せっかくの作業領域を有効に利用することができません。

そこで私はウィンドウマネージャと呼ばれる類のツールを使うことでこれを解決することができました。ウィンドウマネージャとは、ざっくり言うとキーボードショートカットやマウスのジェスチャを呼び出すことによって、アプリケーションウィンドウを画面に対し自動的に 2 分割や 4 分割で整列したり、中央寄せ、最大／最小化などをしてくれるツールです。

macOS には、私の知る限り以下のようなウィンドウマネージャツールが存在するようです。

• BetterSnapTool
  • https://itunes.apple.com/jp/app/bettersnaptool/id417375580?mt=12
• Magnet
  • http://magnet.crowdcafe.com/
• Shiftit
  • https://github.com/fikovnik/ShiftIt
• chunkwm
  • https://koekeishiya.github.io/chunkwm/
• Amethyst
  • http://ianyh.com/amethyst/
• Spectacle
  • https://www.spectacleapp.com/
• VEEER
  • https://veeer.io/

私は、以前 Shiftit を使っていたことがありそのキーボードショートカットを指が覚えていたため、そのまま Shiftit を継続利用しています。その他のツールはまだ試したことがないので、オススメ情報があればぜひ教えてください。

Windows の方は普段使っておらず状況をあまり知らないため、ここでは触れません。詳しい方おられたら教えてください。

4K ディスプレイ利用後の変化

仮想デスクトップを使わなくなった

4K ディスプレイ + ウィンドウマネージャという作業環境でしばらく作業を行っている中で、私が以前と比べて一番変化を感じているのは、 macOS の仮想デスクトップを使わなくなったことです。これは私の中ではかなり大きな変化で、以前の FullHD ディスプレイの環境では、仮想デスクトップをかなりヘビーに使っていました。アプリケーションウィンドウ最大化 + 仮想デスクトップ (4 〜 5 枚) を切り替える使い方です。

これはエディタや IDE、ターミナルの表示領域を最大限確保したい + 複数のアプリケーション間を行き来したい、という欲求から行き着いた私の利用方法で、長らくこのような使い方をしていましたが、 4K ディスプレイに切り替えてから現在、仮想デスクトップは利用していません。

仮想デスクトップを使う代わりに、左半分がブラウザや Dash ⁵ といったリファレンス用途、右半分が IDE/エディタ + ターミナルという基本形で、必要な時にウィンドウマネージャで位置を変えたり、ウィンドウ最大化 + ⌘ + Shift + + というキーボードショートカットで文字を大きくしてクローズアップする、といった使い方に落ち着きました。また、手元の MacBook Pro のディスプレイは Slack やメールなど、コミュニケーションモードに頭を切り替えた時に利用するようにしています。

以前は仮想デスクトップを切り替える際の一瞬の間というか、画面が切り替わるアニメーションと合わせて、コンマ何秒という時間ではありますが頭のコンテキストスイッチが発生していました。頭の中の流れを細かく順を追って表現すると、

1. 「デスクトップ切り替え」
2. 「アニメーション待機」
3. 「ウィンドウの視認」
4. 頭をコンテキストスイッチ
5. 何がしたかったのかを思い出す
6. 作業再開

という手続きを踏んでいたような感覚です。これが一日数百回繰り返されていたわけで、特にコードを書いている時などフロー状態に入っている状態でこれが頻繁に起きていたことを考えると、塵積で相応のコストが費やされていたと思っています。コンピュータのデスクトップの切り替えと違い、人間の頭はコンテキストスイッチが苦手です。切り替えた後に対象を「視認」した上で「思い出す」というステップが（無意識でも）入ってしまいます。

しかしながら現在、上記のような使い方に落ち着いた結果、視線をずらすだけで良くなりました。これによってデスクトップ切り替えのアニメーションが発生しなくなったので、頭のコンテキストスイッチのコストが劇的に少なくなったのが一番大きい点と感じています。デスクトップ切り替え後の「アニメーションの待機」→「ウィンドウの視認」→「やりたかったことを思い出す」という 3 ステップが無くなったような感覚で、物理的に費やされている時間のコスト以上に、頭のコンテキストスイッチのコスト削減効果の感覚が大きいです。

副作用

さらに、画面が大きいため見下ろすような視線の状態を保持しようとすると、必然的に深く腰掛けて骨盤が起きた状態で座高の高さを稼ごうとします。その副作用として以前よりもやや姿勢が良くなったことも感じています。以前から肩甲骨の痛みや脇コリに悩まされていた私としては、嬉しい副作用かもしれません。以前整体に費やしていたコストを考えると、生産性以上のリターンがある気がしています。

そうそう、以前弊社並河が記述した以下の記事にも紹介されていますが、弊社のオフィスの椅子はハーマンミラー社のエンボディチェアですので、長時間のコーディングもなんのそのです。（とはいえ長時間座り続けるのは体に良くありませんので、数時間ごとにコーヒー買いに行ったり散歩したりしましょう）

lab.astamuse.co.jp

その他感動した点

• 横幅があるということは素晴らしい
  • Excel や Google スプレッドシートの世界観が変わる
    • エンジニアだけではなく、マーケティングやデータ分析をされている方にもオススメ
  • ターミナルでエラーログなどを表示した際に折り返されない
    • ログの意味が素直に入ってくる
• 縦にも長い
  • デュアルディスプレイで 1 枚を縦向きにする、という方法もあるが、1 枚のディスプレイに収まっているのはやはり切り替えや仕切り感がなくシームレス

Google スプレッドシートを最大化してみる、の図

Google スプレッドシートは初期表示では Z 列 までしか表示されていないんですよ。知ってました？私は知りませんでした。

docker-compose logs -f の図

ほとんどのログが画面の半分にも到達しておらず 1 行で読めます。JSON ログなど機械が読むログでなく、人間が読むログであれば human readable な状態にしたいですね

まとめ

個人や自宅で 4K ディスプレイを利用されている方もおられると思いますが、 1 日の長い時間を費やす業務や職場でこそ、ぜひ 4K ディスプレイの利用をオススメします。また 4K ディスプレイを利用の際は、合わせてウィンドウマネージャの利用もオススメです。

また、好きな PC + 4K ディスプレイ + 良い椅子で気持ちよく仕事がしたいんだ！という方、弊社ではエンジニア・デザイナー等、絶賛大募集しております。ご興味のある方は下記バナーの採用サイトからご応募いただくか、カジュアルにランチなどでお話させていただくことも可能です。(@yukung) までお気軽に DM 等でご連絡いただければと思います。お待ちしています。

---

1. 余談ですが私はこの絵文字を見るとリキ・ラリアットをいつも思い出します↩

2. これを知らなかったことがニワカプロレスファンを物語っていますね。ガチプロレスファンの方、すみませんでした（汗）↩

3. ちゃんと見た人はわかりますよね？それだけ！！↩

4. 執筆時 Amazon で 39,950 円でした。30 インチ超え 4K ディスプレイがもう 4 万円切る時代なんですね…。↩

5. 様々なドキュメントやリファレンスを一括で参照できるアプリ↩

今どきのシャッフルランチを支える技術

こんにちは、すしざんまいが恋しいfdkです。

今回は、件の社内プロダクトaimeshiの舞台裏を現場レポートします。

lab.astamuse.co.jp

aimeshiとは

社内ワークショップから発足したプロジェクトで、 部門の垣根を超えたコミュニケーションを活性化するためのプロセスの全部または一部をシステムにより自動化するシャッフルランチの仕組みです。

*1

aimeshiのコア・コンセプト

• しがらみなし（恣意的な人選、店選びを排除）
• 負担なし（スケジューリング、イベント進行を自動化。参加者のお財布にも優しい）
• ハズレなし（メンバーは言わずもがな、美味しいお店を自動推薦）

小さくて大きな目標

それは、イベント実施率を100％にすることです。

限られた予算で一定期間の検証を行うのが最初で最後のミッションです。

aimeshiには強制力はありませんが、愛があります。各人の都合に合わせて、自然と参加したくなるような仕組みづくりを目指しました。

最初のオファーからコミュニケーションが始まるのです。

インシデント発生

順風満帆の滑り出しから数週間を経たある火曜日の夜、いつもと趣の異なるお知らせが届きました。

イベントキャンセルとは、決められた時間内に一定の人数が集まらない場合に、当日のイベントの開催を取り止めることです。aimeshiにもプライドがあります。

しかし、これは100%のイベント実施率を目指すわたしたち運営チームにとっては寝耳に水。はじめて味わう敗北です。

状況と原因の分析

事象を分析した結果、定足数5人のうち3人まで確定している状態で、残りの2オファーの回答期限内にイベントの受付の締め切りを迎えてしまったということでした。 最小催行人数が4人というルールに従い、イベントは見送られました。

対応策

当初のフローは次のようなものでした。

最初にイベントの定足数分の回答期限付きオファーを出す。期限内に参加回答をしたメンバーを順次確定する。欠席回答もしく回答期限切れの場合は新たに別のメンバーにオファーを出す。

以下のような対策案が上がり、2と3をすぐさま対応しました。

1. イベントの受付締め切りに向けて、オファーの回答期限を調整し、オファー切り替えを行う

2. 初回のオファーを定足数よりも大きな数で出し、先着順でメンバー確定するようにルールを変更する

3. システムだけに頼らず、オファーの回答を促すコンシェルジュサービスを導入する

振り返りと考察

これまでの1ヶ月半で、11戦10勝1敗の成績、全体の約6割のメンバーがaimeshiに参加しました。

メンバー毎の参加回数を集計してみると、2回以上のリピーターが一定数いることがわかります。

また、1イベントあたりの確定までの平均オファー数は14.91回となっており、かなりのフラれ率であることがわかりました。これは、オファー時に個々のスケジュールを考慮しないこと、企画に対して一定の心理的障壁がありそうなこと、PR不足などが要因として考えられます。

一方で、オファー到達率は100%、1人あたりの平均受信オファー数は3.28回となっており、公平性という観点では妥当な線に達しているものと言えます。

では、参加したメンバーの反応はどうでしょうか。参考までに、社内コミュニケーションツールにおけるaimeshi関連の累積トピック数をグラフ化すると、順調な伸びを示しており、一定の反響があることが見て取れます。

2018年12月12日が初回。β期間として週2回開催。

今後の課題

• イベントあたりの平均オファー数を指標とし、これを下げること
• より賢いお店の選定アルゴリズムの開発
• AIによる、より魅力的なお誘いメッセージ
• 会話に花が咲くトピック推薦エンジンの開発
• おひとり様向けのsolomeshiの開発
• キャッシュレス化

検証期間中に2回目、3回目の参加を果たしたメンバーは開拓者であり、リピーターであり、大のaimeshiファンと言えましょう。このようなファンは大切にしなくてはなりません。エバンジェリストとして彼・彼女らに次期のaimeshi運営をぜひともお願いしたい次第です。

まとめ

企画・開発段階もさることながら、いざ運用を開始してみると、色々な事象が起こります。チームaimeshiは、その度に喧々諤々と議論をし、それぞれが自ら進んで役割を果たす、いいチームです。そんなチームに支えられてaimeshiは歩みを進めています。

現場からは以上です。

*1:チャーリーさんの「ビジネスモデル図解ツールキット」を使わせていただきました。 note.mu

schemaspy+jenkinsで最新のER図をブラウザで閲覧できるようにする

こんにちは、アプリチームのchotaroです。

いくつかの新規サービスの開発を控え、アプリチームにも人の入れ替わりが発生してきています。

そんな中、新規参画者への情報共有が一つの課題になりました。

今回はそのためにやった一つのTIPSを紹介します。

解決する課題

• 逐次DBの構造が変更されるのに対して、プロジェクト内のER図がメンテできておらず最新のER図が存在しないこと
• 新規参入者が全体の構造を理解するのに、時間がかかってしまうこと

解決方法

schemaspyとjenkinsを組み合わせて、チームメンバーが最新のER図をWEBブラウザ上で確認できるようにする。

実践

schemaspy

schemaspyは、オープンソースで提供されている、ER図生成ツールです。(ライセンスはLGPLv3)

接続先やスキーマ名の情報を与えることで対象のDB・スキーマを読み取り静的なhtmlを一式生成します。

スキーマごとにディレクトリを生成し、スキーマ内でのカラムの検索やリレーションを表現した図を出力してくれます。

スキーマごとの画面イメージ

html一式が出力されるため、例えばCIサーバ上に展開するようにすれば、チームメンバー全員が閲覧可能になります。

ER図の出力

基本的にはドキュメントに全部書いてあります。親切。

下準備

• graphvizのインストール(ubuntuであれば apt-get install graphviz してあげてください。dot -V でinstallされているか確認できます。 )
• java8のインストール

必要なライブラリの準備

• ライブラリ本体SchemaSpy releases
• 接続先に合わせたjdbc driver(postgresqlであれば、wget https://jdbc.postgresql.org/download/postgresql-42.2.5.jar )

上記を一つのdirectoryに入れ、同じ階層にschemaspy,propertiesを作成します。

# type of database. Run with -dbhelp for details
schemaspy.t={{接続先のDBの種類 postgresqlなら[pgsql] }}
# optional path to alternative jdbc drivers.
schemaspy.dp={{ 接続用のJDBC driver [/path/to/driver/postgresql-42.2.5.jar]}}
# database properties: host, port number, name user, password
schemaspy.host={{ 接続先host }}
schemaspy.port={{ 接続先port番号 }}
schemaspy.db={{ 接続先DB名 }}
schemaspy.u={{ user name }}
schemaspy.p={{ password }}
# output dir to save generated files
schemaspy.o={{ output先のdirectory }}
# db scheme for which generate diagrams
# schemaspy.s= {{ 対象のスキーマ名 (今回は全スキーマを対象としたいのでコメントアウトしています。) }}

実行

ここまでで準備してきたdirectoryで

java -jar [jar名] -all

とコマンドを実行します。(-allは全スキーマを分析対象とするためのオプションです。)

ciサーバ上で出力が確認できたらnginxなどWEBサーバーの設定を仕込み、まずページを見られるか確認します。

こんなページが閲覧可能になればOKです

schemaspy index.html

okならばjenkinsにjobを作っていきます。

Jenkins jobでER図の最新化を自動化する

シェル実行で以下のようなスクリプトを設定。

rm -rf /path/to/output/*
cd ~/schemaspy
# jarの実行。
java -jar schemaspy-6.0.0.jar -all
ls -al /path/to/output/

このとき、書き込み先のディレクトリのpermissionには注意してください。jenkinsユーザーの書き込み権限が出力先のdirectoryにあることが前提になります。権限がない場合、処理がfailしてしまいます。

また一部のみ出力ではなく全量を出力するため、ゴミが残らないよう毎回クリーンアップするようにしています。

このjob自体をwebアプリのデプロイjobのあとに起動するように設定して完了です。

こうすることで実際に動いているwebアプリが、どんな構造のDBを元にしているのかがすぐ確認できるようになりました。

効果

これから先に備えた変更なので、この先どうなるか、というとこです。今後に期待。

ただし、ローカルで利用してみた所感では、やはり無いのと有るのでは自分自身の実装に対する確信が違います。

ひと目でわかること、は大事。

課題

リレーションを明示的に貼っていないとリレーション図を閲覧できません。(当たり前ですが……

なのでリレーションを明示的に貼ってはいないものの同一なもの(USER.user_idとACCESS_LOG.user_idのような関係)を読み取ることが難しいです。

docker上にDBを立ててそこにddlを流し、別途alter文を流して擬似的に見せることはできますが……そうするとそのalter文までメンテナンスしなくてはならないため諸々コストがかかります。

悩ましいところですが、新規チームメンバーの参画のタイミングで継続的に改善していくしかないかなというところです。

以上、主にschemaspyの紹介でした。

アプリチームでは今後もこのような改善活動を継続しつつ、サービス開発に勤しんでいきます。

もし興味持たれた方おられましたら、下記バナーから開発環境や採用情報など見れますので、是非見てみてください。

それでは失礼します。