nogamincho technical memo

Mainly AWS and Java

リモートワークの環境を紹介する

退職エントリからしばらく何も書いていなかったのですが、まとまった時間を取れたのでリモートワーク環境について書きます。 2月下旬から部分的にリモートワークを導入しはじめ、3月にはほぼ完全にリモートワークに移行しました。

リモートワークし始めは、ダイニングテーブルにダイニングチェアで仕事をしていたものの、今後もリモートワークが続くことが想定されるため、奮発して環境を整備しました。

きっかけとしては、ダイニングチェアに座っていると腰の調子がすこぶる悪く、腰の違和感が無視できなくなったのが一番です。 相談なしに買える家庭ではないので、妻とも相談しましたが、「どうせ今後もリモートワーク続くし、速いほうが良くね?」との共通認識があったため、3月下旬〜4月中旬にかけて少しずつ整備しました。

いろいろ整備した結果、自宅だから生産性が下がってるなぁと感じることは特になくなりました。中でもいちばん重要なのはイスでした。何から揃えようか?と思っている方は、イスを最初に買うと良いかと思います。

いまは、引き戸で仕切れるリビング横の部屋に鎮座しています。しばらくはここを仕事場として使わせてもらっています。

f:id:nogamincho:20200426121834j:plain
現在のリモートワークの風景

以下が今の私のリモートワーク環境です。(リモートワーク開始前に購入したものものも含まれています)

4Kモニタ

  • ASUS 28インチ 4Kモニタ
  • 購入時価格:34800円

コメント

  • 長期戦になることが見えてきて、さすがに辛くなってきたため購入。
  • 基本的に4分割で使っており、上部2画面が1軍、左下が2軍、右下が3軍みたいな使い方してます。SlackやメーラーMacbookの画面側においてる。

良かった点

  • フルHDで4面とれるのは正義。細かい文字でも気にならないので、WQHDより4Kを選択してよかったなぁと。
  • 物理的に大きすぎず、小さすぎずでちょうどよかった。

改善点

  • 視線を上下に動かす必要がある。それが嫌な人はウルトラワイドモニタの方がよさそう。
  • 端っこは見づらいので28インチより大きくなったら、曲面ディスプレイの方がよさそう。
  • 高さの調整はできたほうがよかった。(そのうちアーム買いたい…)

モバイルモニタ

  • EVICIV 13.3インチ フルHD モバイルモニタ
  • 購入時価:19980円

コメント

  • 移動中のコワーキングスペースや客先で作業することを想定し、リモートワークが始まった直後に購入。
  • 4Kモニタ購入後は第3のモニタとして利用。(片付けているときの方が多い)

良かった点

  • Web会議でパワポを使って説明するときに、共有画面、発表者ツール、調べ物やメモ用の画面、とモニタごとに役割分担ができるのが最大のメリット
    • このモバイルモニタの画面を共有するようにしているので、機密情報が映っちゃったりとかが起きにくいです。
  • 思ったより軽い。表示もあんまり違和感ないです。
  • Type-C 1本で給電・表示ができるのが嬉しい。ACアダプタ→モニタ→Macと繋いで給電できるのでMacのUSBポートの節約ができる。
  • モバイルモニタとしてならコスパ高くておすすめ。

改善点

  • あんまない。満足度高い。
  • サブディスプレイとして主力にするには13.3インチはちょっと小さいかも。

デスク

  • FLEXISPOT 電動昇降デスクE1E(EC1)セット
  • 購入時価格:37000円

コメント

  • 必ずしも昇降式である必要はなかったですが、最適な高さがわからなかったこと、周りで評判が良かったことから購入。
  • Amazonのリンクをつけていますが、公式サイトから天板とセットになっているものを購入しました。

良かった点

  • 体勢ごとに最適な高さに昇降させることができて、やはり楽。
  • 他の電動昇降式デスクと比べたら安価ですが、天板が結構ちゃんとしていてチープさは全く感じません。

改善点

  • 一番下げても71cmと、少しだけ高く感じます。耐荷重的にも60cmまで下げられることからも、2つ上のモデルのE3の方がおすすめしたいです。(お子さんと並んで使ってる人もいて、ほっこりしました)

チェア

コメント

よかったこと

  • メッシュなので蒸れない。座り心地もよく、腰の違和感が解消。
  • 座面も広く、椅子の上であぐらいても全然余裕。
  • 座面の高さが変えられることはもちろん、リクライニング、肘掛けや背面やヘッドレストの高さ調整、座面スライドなど、その時の気分に合わせて変えられるのがめっちゃいい。

改善点

  • 会社で使っているイスはリクライニング時に座面も合わせて傾いてくれるのがよかったものの、そこまでの機能はなし。
  • でかい。

床の保護シート

  • 防水キズ保護シート 90cm×180cm
  • 2157円

コメント

  • 買った時点で一番安いものを買いました。

良かった点

  • 90cm x 180cmと大きめのサイズを買ったので、イスを収納していても、机から離れて座っていても、はみ出ることが無いのはメリット。
    • 90 x 150あれば多くのケースでははみ出ないので、90 x 120よりもおすすめ。
  • 床に貼り付けられるので動かない。
  • 透明かつうすいので見た目の違和感がない。

改善点

  • 貼るのが難しい。綺麗に気泡を抜きながら張ると、15分ぐらいかかった。
  • 耐久性に難あり。そのうち破れそうなので、破れたら1mmぐらいの厚さがあるものに買い替え予定。

Trackpad

  • Apple Magic Trackpad 2(シルバー)
  • 購入時価格:14070円

Apple Magic Trackpad 2 - シルバー

Apple Magic Trackpad 2 - シルバー

  • 発売日: 2015/10/14
  • メディア: Personal Computers

コメント

  • いわずもがな。普段マウス使わないのでTrackpadを採用。

良かった点

  • 電池持ちがいい。充電もLightningを使っているので特に問題なし。

改善点

  • 特になし。

ヘッドホン

コメント

  • 新幹線通勤中に騒音がすごいので、ノイズキャンセリングヘッドホンを購入。
  • 耳がカバーされることで集中できるので、一日中つけています。

良かった点

  • 新幹線、飛行機での移動でも(無音とまではいかないが)遮れるため、愛用中。
  • バッテリー持ちがよく、長時間のWeb会議がある場合でもフル稼働でも一日は持つ感覚。

改善点

  • 文句なし。SONYのヘッドホンとの比較はもっとちゃんとやればよかったかも。どっちがいいか比較せずに買ってしまったのは反省。

キーボード

  • FILCO Majestouch MINILA Air US67キー 赤軸
  • 購入時価格:(ヨドバシで買ったので覚えてない)

コメント

  • スペースキーが小さいキーボードが好きで、英語キーボードのなかで一番手に馴染みそうだったので購入。

良かった点

  • スペースキーが小さく、手に馴染む。
  • Bluetoothで接続でき、値段も比較的手頃。

改善点

  • MacのFnキーを割り当てていないため、Fnキーが必要な場合はMacのキーボードを使っている。
  • 右シフトがもうちょっと大きいと嬉しいかも。
  • 静音リングをつけているものの、結構な打鍵音なので、Web会議の時には自重している。

他の方のリモートワーク環境も気になるので晒してもらえると嬉しいです。

AWS CLIに設定された呼び出し元アカウントを確かめる方法

小ネタです。

AWSのアカウントを複数管理していると、どのアカウントを使っているかわからなくなることありますよね?

その際にAWSアカウントで使う2つのコマンドを紹介します。

aws sts get-caller-identity

呼び出し元の情報を表示するコマンドです。

APIを呼び出すリージョンについて、そのアカウントでSTSのエンドポイントが無効化されていなければ利用できます。

アカウント番号なんだっけ?SwitchRoleしたっけ?ってときにもよく使います。

~ ❯❯❯ aws sts get-caller-identity
{
    "UserId": "AIDAABCDEFGHIJKLMNOPQ",
    "Account": "012345678910",
    "Arn": "arn:aws:iam::012345678910:user/nogamincho"
}

aws s3 ls

S3バケットの一覧を表示するコマンドです。

get-caller-identityよりも短いのでバケット名からどのアカウントかすぐにわかるときに利用しています。 (以前の現場はアカウント番号よりも命名規則でS3バケットを作成していたので重宝しました。)

~ ❯❯❯ aws s3 ls
2019-04-17 16:15:15 nogamincho-test-bucket

他にもこんなコマンド使ってるよ!!とかがあれば教えて下さい。

JJUG CCC 2019 Springに参加してきました!

今更感がありますが、5/18に行われたJJUG CCC 2019 Springの参加してきたのでその参加記録です。

初めてのボランティアスタッフ

今回は初めてボランティアスタッフを担当しました。 どんな感じか知っていただき、他の方にもどんどん参加していただけると幹事の負担を減らせるかなと思っています。

申し込み

DoorKeeperでボランティアスタッフの募集がかけられます。一度JJUGのイベントに参加していればメールで募集の通知が来ると思います。 申込み後はJJUGのSlackのボランティアスタッフ用のチャネルに招待され、コミュニケーションはそのチャネル上で行われます。

今回は以前と比べてボランティアスタッフが倍増し、50名ほどの募集だったようです。

事前のアンケート

開催1ヶ月ほど前に、どの時間帯ならばスタッフとして活動できるか?どのセッションを聴講したいか?など事前アンケートが取られます。

初回の担当割時点でセッションのタイムテーブルが確定していなかったため、どのセッションを聴講したいか?という点は考慮できなかったようです。

事前打ち合わせ

開催の約2週間前に新宿で事前打ち合わせがありました。

軽い自己紹介と事前の段取りの説明、担当割の調整が行われました。(段取りや会場でのアナウンスの内容はGoogleスプレッドシートで共有されます) どうしても聞きたいセッションがあればこのタイミングで申し出れば皆さん気軽に変わってくださるかと思います。

私は別件があり途中抜けしましたが、その後みなさんは懇親会に行っていたようです。

開催当日

集合

ボランティアスタッフは8:30に集合します。 9時までは掲示物の整理や段取りの再確認を行い、9時から30分間で案内の掲示や立て看板の配置を行います。

部屋付きのスタッフ業務

ボランティアスタッフ初参加でも困らないように、各部屋の担当にスタッフ経験がある人と初めての人でペアを組んで配置されました。

私の担当は英語セッション2つでしたが、ペアの方がスピーカーとコミュニケーションを取っており、質問は私が通訳します、と言いきるツワモノだったので安心してその他の業務をこなしていました。

実際にやったのは、ドアの開け締め、参加者の誘導、インカムで他の部屋とのコミュニケーションなど割と軽めな業務でした。

スタッフをしてよかったこと

ボランティアスタッフをすることで実利としては「スタッフTシャツがもらえる」「懇親会の参加費が無料」の2点があります(笑) 普段は会えないような社外のJavaエンジニアと話すきっかけになるのがよいと思いました。

懇親会LTやった

LTは何度か登壇しており、今回は3回目の登壇でした。

私は仕事ではインフラ整備をしているため普段はJavaを書いていません(笑) なので、アプリよりもインフラよりの内容で登壇しています。

Jibに関しては日本語に関する情報が少ないと思っていたので、その内容をまとめました。

最後に

私は仕事でJavaは書いていませんが、何かしらコミュニティに貢献できないかと考えています。 その一歩がボランティアスタッフやLTでの発表です。

JJUG CCCは参加者が1000人を超えるイベントですが、そのイベントが参加費なしで開催できているのはスポンサー様と幹事の方々のおかげです。 特にボランティアスタッフは幹事の負担を下げられるので簡単にできる貢献だと思います。

次回以降も同じように大量のスタッフが募集されると思いますので、みなさまもぜひ一緒にカンファレンスを作り上げましょう!

Homebrewでterraform0.12を導入する

背景

  • Terraformを使おうとしたところver. 0.11からver. 0.12でConfiguration Languageの仕様が変わるとのこと。
  • Homebrewでver. 0.12をインストールしようとしましたが、まだ正式リリースされていないためインストール不可…
  • productionで使うわけじゃないので、仕様が変わっても問題ない。
  • 手でバイナリを配置すると管理できなくなるので集約したい。

解決方法

brew installにはHEADオプションといって、最新版のコードからビルドしてインストールするオプションがあるようです。 今回はこれを使ってみました。

# terraform ver. 0.11の削除
~ ❯❯❯ brew uninstall terraform
Uninstalling /usr/local/Cellar/terraform/0.11.13... (6 files, 120.6MB)

# 最新版のterraformのインストール
~ ❯❯❯ brew install terraform --HEAD
Updating Homebrew...
==> Installing dependencies for terraform: go and gox
==> Installing terraform dependency: go
==> Downloading https://homebrew.bintray.com/bottles/go-1.12.1.mojave.bottle.tar.gz
######################################################################## 100.0%
==> Pouring go-1.12.1.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/go/1.12.1: 9,794 files, 452.6MB
==> Installing terraform dependency: gox
==> Downloading https://homebrew.bintray.com/bottles/gox-0.4.0.mojave.bottle.tar.gz
######################################################################## 100.0%
==> Pouring gox-0.4.0.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/gox/0.4.0: 5 files, 3.3MB
==> Installing terraform --HEAD
==> Cloning https://github.com/hashicorp/terraform.git
Cloning into '/Users/<username>/Library/Caches/Homebrew/terraform--git'...
Checking out files: 100% (6012/6012), done.
==> Checking out branch master
Already on 'master'
Your branch is up-to-date with 'origin/master'.
==> make tools test bin
🍺  /usr/local/Cellar/terraform/HEAD-4d52999: 6 files, 50.2MB, built in 6 minutes 34 seconds
Removing: /Users/<username>/Library/Caches/Homebrew/terraform--0.11.13.mojave.bottle.tar.gz... (25.4MB)

# バージョンの確認
~ ❯❯❯ terraform --version
Terraform v0.12.0-dev

環境

  • OS: mac OS Mojave 10.14.4
  • Homebrew: 2.0.6

Office for Macでフォントのスキーマを追加する

課題

Windowsとファイルを共有することが多いため、メイリオ等のフォントを標準にしたいケースあります。

しかしながら、Office for Macではフォントのスキーマを追加する際にアプリケーションから行うことが出来ません。

そのため、設定ファイルを手作業で追加する必要があります。

f:id:nogamincho:20190227140406p:plain
ここにフォントを追加したい

解決方法

/Users/<ユーザー名>/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Themes.localized/Theme Fonts配下にXMLファイルを配置することで追加できます。

このXMLを配置することで、Word, Excel, PowerPointのすべてで利用可能になります。

私が利用しているファイルの内容を配置しておきます。

メイリオ

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<a:fontScheme xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" name="メイリオ">
    <a:majorFont>
        <a:latin typeface="メイリオ"/>
        <a:ea typeface="メイリオ"/>
        <a:cs typeface=""/>
    </a:majorFont>
    <a:minorFont>
        <a:latin typeface="メイリオ"/>
        <a:ea typeface="メイリオ"/>
        <a:cs typeface=""/>
    </a:minorFont>
</a:fontScheme>

ヒラギノ明朝用

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<a:fontScheme xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" name="ヒラギノ明朝">
    <a:majorFont>
        <a:latin typeface="ヒラギノ明朝 Pro"/>
        <a:ea typeface="ヒラギノ明朝 Pro"/>
        <a:cs typeface=""/>
    </a:majorFont>
    <a:minorFont>
        <a:latin typeface="Times New Roman"/>
        <a:ea typeface="Times New Roman"/>
        <a:cs typeface=""/>
    </a:minorFont>
</a:fontScheme>

VPC endpoint policy for CloudWatch Logs, CloudWatch Events

First of all

I found that we could describe VPC endpoint policies for VPC endpoints of CloudWatch Logs and CloudWatch Events. I tried to verify the behavior.

I described about VPC endpoint and VPC endpoint policies, so skip if not necessary.

I am sorry for my poor English because I am not good at English.

What's VPC endpoint?

VPC endpoint is a endpoint to route a request to AWS API from VPC resources within AWS network.

Usually, if you want to send an AWS API request from an EC2 instance in a private subnet, you need to place a NAT Gateway (or NAT instance) in a public subnet, which means the request may be routed through the Internet. But VPC endpoints enable us to keep the request within AWS network.

What's VPC endpoint policy?

Speaking briefly, VPC endpoint policy is like a IAM policy. All requests through a VPC endpoint are constraint by the policy.

Even if you allow by IAM policy, a request is denied by a VPC endpoint policy with no allowance.

VPC endpoint has two types, "Gateway" and "Interface". Until now, we can describe VPC endpoint policy only for Gateway type(S3 and DynamoDB).

Thanks to this update, VPC endpoint policies of CloudWatch Logs and CloudWatch Events can now be described as Interface type VPC endpoints for the first time.

Use case of VPC endpoint policy

What are the benefits of using a VPC endpoint policy?

Firstly, I understand that you can restrict access to resources of other accounts.

Let's take S3 as an example.

When you use a VPC endpoint and a VPC endpoint policy with no restriction, it is possible to take data from EC2 to the S3 bucket of another account by using the access key of another account.

If confidential information etc. are stored on EC2, data leakage can occur in the following cases.

  • System operation personnel operate with malicious intent
  • OS command injection is performed for EC2
  • EC2 infects with malware

f:id:nogamincho:20190216170254p:plain
a use case of VPC endpoint policy

Therefore, when I use the VPC endpoint policy, I restrict a VPC endpoint policy only the resources of my account as correspondence to those risks.

Try

Preparation

  1. Create a VPC endpoint of com.amazonaws.ap-northeast-1.logs f:id:nogamincho:20190216170730p:plain Only if you chose com.amazonaws.ap-northeast-1.logs or com.amazonaws.ap-northeast-1.events, you can see a text box for a policy at the bottom.
  2. Describe policy. I allowed only a request to a log group "log-group-allowed". f:id:nogamincho:20190216162340p:plain
{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Resource": [
        "arn:aws:logs:ap-northeast-1:XXXXXXXXXXXX:log-group:logs-test-allowed:*"
      ],
      "Principal": "*"
    }
  ]
}
  1. Create an EC2 instance in a subnet you created the VPC endpoint.(I attatch to an IAM policy to an IAM role of the EC2 instance.)
  2. Create log groups and log streams.
$ aws logs create-log-group --log-group-name logs-test-allowed
$ aws logs create-log-stream --log-group-name logs-test-allowed --log-stream-name logs-stream
$ aws logs create-log-group --log-group-name logs-test-denied
$ aws logs create-log-stream --log-group-name logs-test-denied --log-stream-name logs-stream

Verify a behaivor

Log in to the EC2 instance, then send a request.

Verify a route of requests

Using a dig command, I confirmed a request to logs.ap-northeast-1.amazonaws.com was routed to the VPC endpoint.

Private IPs were gotten, then I confirmed.

[ec2-user@ip-172-31-29-146 ~]$ dig logs.ap-northeast-1.amazonaws.com

; <<>> DiG 9.9.4-RedHat-9.9.4-61.amzn2.1.1 <<>> logs.ap-northeast-1.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30198
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;logs.ap-northeast-1.amazonaws.com. IN  A

;; ANSWER SECTION:
logs.ap-northeast-1.amazonaws.com. 60 IN A  172.31.10.218
logs.ap-northeast-1.amazonaws.com. 60 IN A  172.31.20.109
logs.ap-northeast-1.amazonaws.com. 60 IN A  172.31.44.227

;; Query time: 2 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: 土  2月 16 05:50:36 UTC 2019
;; MSG SIZE  rcvd: 110

Verify a behavior of policy

I sent a test data to the log groups, logs-test-allowed, logs-test-denied.

The put-log-events request to logs-test-allowed was suceeded.

[ec2-user@ip-172-31-29-146 ~]$ aws logs put-log-events --log-group-name logs-test-allowed --log-stream-name log-stream --log-events timestamp=1550295898001,message=ExampleEvent1 timestamp=1550295898002,message=ExampleEvent2
{
    "nextSequenceToken": "49592304407703484745949521076996311451170380XXXXXXXXXXXX"
}

The put-log-events request to logs-test-denied was failed.

[ec2-user@ip-172-31-29-146 ~]$ aws logs put-log-events --log-group-name logs-test-denied --log-stream-name log-stream --log-events timestamp=1550295898001,message=ExampleEvent1 timestamp=1550295898002,message=ExampleEvent2

An error occurred (AccessDeniedException) when calling the PutLogEvents operation: User: arn:aws:sts::XXXXXXXXXXXX:assumed-role/ec2-logs-fullaccess-role/i-XXXXXXXXXXXX is not authorized to perform: logs:PutLogEvents on resource: arn:aws:logs:ap-northeast-1:XXXXXXXXXXXX:log-group:logs-test-denied:log-stream:log-stream

These have confirmed that the VPC endpoint policy is applied to the VPC endpoint of CloudWatch Logs.

Finally

  • The VPC endpoint policy is an important function for restricting resource access from the VPC, the risk of data leak can be reduced.
  • If other Interface type endpoints is updated, we will be able to build a more secure VPC environment and expect further development.

Please share in Twitter or other SNS!!

AWSの認定資格のデジタルバッジがアップデートされました

AWSの認定試験に合格するとデジタルバッジが付与されます。

↓こんなの

f:id:nogamincho:20190219145645p:plain
旧版のバッジ

2/3に受験して付与されたバッジを見るとこんな感じに変わっていました。

ちょっぴりスマートな感じになりましたね。

f:id:nogamincho:20190219150028p:plain
新版のバッジ