2020-11-07

半年間のリモートワークで買ったものとか

3月末からリモートワークを続けていて、自宅の環境も多少変わりました。以前から自宅でも机でプログラミングをしたり読書をしていましたが、カフェなどに移動することをも多く、物自体を少なめに保っていました。

f:id:suzusin:20201107164934j:plain — 3月頃のデスク

元々MBPのDefaultのペチペチキーボードが好きだったのもあり、この程度の環境でも特に不満はなかったのですが、本格的なリモートワークに突入して、環境改善意欲が高まってきました。

そして、今はこんな感じになっています。

f:id:suzusin:20201107165124j:plain — 11月頃のデスク

ディスプレイ

HP 27f 4K ディスプレイ

社会人になった頃に安く買ったASUSの21インチ FullHD を使っていましたが、ちょうどAmazonのセールで4kがあったため買い替え。以前の方は同じタイミングでリモートになった妻のデスクへ。

jp.ext.hp.com

キーボード

Happy Hacking Keyboard Professional HYBRID Type-S 英語配列／墨

キーボードに関しては指が引っかかりやすいという理由でメカニカルが苦手だったのですが、あまりに社内Slackで人気だったため気になりはじめました。今の会社には開発環境向上制度というものがあり、一定の予算内であれば買ってもらうことができるため、それを使ってチャレンジ。

最初のうちは打ちづらいと感じていたものの、数ヶ月でさすがに慣れてきて、軽快に押せるのは気に入ってきました。会社の資産なので退職したら返却するのですが、その時は個人的に買うかもしれないです。

www.pfu.fujitsu.com

デスク

FLEXISPOTスタンディングデスクEN1B

flexispot.jp

こちらも同僚が購入していたのを見て購入。以前は適用に買った幅90cmの机だったのですが、手狭だったのと座りっぱなしが良くないらしいので。以前の机はジモティで譲渡。

長いミーティングの際などはスタンディングにしてストレッチしたり。。高さを記憶できるメモリー機能がとても便利で、椅子とデスクの最適な高さを測って記憶させました。

www.itmedia.co.jp

f:id:suzusin:20201107172310j:plain — スタンディングデスク

実は、5月2日に注文したのだが2週間しても音沙汰が無いので問い合わせたところ、欠品しているとのこと。キャンセルするか、次回入荷を待つかを聞かれ、入荷を待ったところ、5月24日に無事到着しました。さすがに今は落ち着いたと思うけど、当時はリモートワーク関連のものが多く売り切れていましたね。

Web カメラ

Logicool StreamCam

カメラはMBPにあるのでずっと不要だと思っていたのですが、 1画面で集中したいなという思いでクラムシェルモードを試しており、それが結構良い。そこで必要となり、こちらを購入しました。

これは2万円弱と正直高いです。ただ見たところType-C対応はこれくらいしか見当たらず。せっかくスッキリさせようとしているのにドングルをかませるのは好きではなかったので、長く使うものだろうしと決断。

iPadでも良いのですが、画面共有する機会も多く、やはり便利です。

www.logicool.co.jp

2020-11-01

不確実な未来と向き合って経験したこと

今年は多事にかまけて更新していなかった… 先ごろ、比較的大きなリリースを終えたので感想を残しておく。

自社で開発しているプロダクトにおいて、ユーザ体験を向上させる機能開発を行った。プロダクトオーナーの纏めた要件を元に設計に落とし込んだのは夏頃。マイクロサービスアーキテクチャによるサービス分割を推進していることもあり、既存のコードベースとは別にサービスを立ち上げて開発を進めていった。

良い設計は、様々な判断を後ろにずらすことができると考えている。またソフトウェアに柔軟さを持たせることができるし、要求の追加や変更にも耐えやすい。また、Agileで開発を行っているのだが、こちらも同じような考え方がある。知られた話だが、まずはミニマムの価値あるプロダクトを作り、触って、良くしていくことができる。

COVID-19 の影響により、ビジネスを支援する自社のプロダクトの需要は急激に高まり、また多くの要望も届くようになった。幸いなことに、ビジネスサイド（この言い方はあまり好きではないが）の方々によりスクリーニングされているため開発時に心配することは少ないが、それでも方向転換や優先度の変更は当然あり得る。

いま内省することは、途中参加のメンバーにこういった意図や狙いをうまく伝えることができなかったのかもしれない、ということだ。とりわけ途中から参加したメンバーは、曖昧に感じたことが多々あったのだと思う。背景、考えられる要素、考えなくてよい要素、それらを踏まえてみんなで議論する機会を、途中でも設けるべきだった。走り始めていると、なかなか難しい。

また設計も、今回は良い設計ができたとは言えないのだが、柔軟さや余白を残しつつバランスを取り、開発者が不安になることのない設計をすることがアーキテクトとしての価値なのだろうと感じた。

レトロスペクティブで様々な意見や改善案が出たのも良かった。しっかりとコトに向かって、これからもプロダクトを良くしていきたい

2019-12-08

Default Subnetが無くてAWS CDKでDeployに失敗した

cdk deploy をしたときに、Template errorとやらで落ちた。

$ cdk deploy HogeStack
HogeStack: deploying...
HogeStack: creating CloudFormation changeset...
  0/28 | 01:13:45 | CREATE_IN_PROGRESS   | AWS::EC2::VPC                         | ExampleVpc (ExampleVpc7799291B) 
~中略~ 
  6/28 | 01:14:04 | CREATE_FAILED        | AWS::EC2::Subnet                      | ExampleVpc/PrivateSubnet2/Subnet (ExampleVpcPrivateSubnet2Subnet...) Template error: Fn::Select  cannot select nonexistent value at index 1
        new Subnet (/Users/szk416/hoge_project/node_modules/@aws-cdk/aws-ec2/lib/vpc.ts:1311:20)

最初はTemplate errorなのでコードのミスかと思ったが、エラーメッセージを見て、ふと思ってマネジメントコンソールを見たら ap-northeast-1a 以外のdefault subnetが存在していなかった。昔よくわからず、リソースを掃除しようと消してしまったのかもしれない。

ユーザガイドを見たらCUIでしか作れないようだったが、特に難しいことはなかった。デフォルト VPC とデフォルトサブネット - Amazon Virtual Private Cloud

aws ec2 create-default-subnet --availability-zone ap-northeast-1c aws ec2 create-default-subnet --availability-zone ap-northeast-1d

default subnetが復活して、無事deployできた。

2019-05-02

macosでVimライクなキーバインディングを使う

macosではemacsライクなキーバインディングをデフォルトで使用できます。 Ctrl+F, B, P, Nで上下左右に移動できるので、十字キーに指を持っていく必要がありません。

www.capa.co.jp

しかし、vimで作業するときは当然Ctrl+H, J, K, Lで移動するため、無意識の誤操作が増えてきました。またサーバサイドエンジニアとなると、どうしてもviで作業することもあります。

そこで、通常のバインディングもVimライクに変更することにしました。

Karabinerをインストールします。

pqrs.org

Complex ModificationsからAdd ruleをクリック。

Import more rules from the Internetでブラウザが開きます。

Vi Style Arrows を検索して、 Import します。

Karabinerに戻ったら、有効にしたいRuleをEnableにします（Ctrl以外にもありますね）。

これでViと同じ上下左右の移動ができるようになりました。ただし、当然これをするとデフォルトのCtrl+Kによるカーソルから右を切り取り がオーバーライドされるので、多用していた場合は注意が必要です。

2019-03-26

Visual Studio for Macでデバッグできないとき

LeetCodeやAtCoderが流行っているので久々にC#を書こうとしたら詰まったのでメモ。

Visual Studio for Macをダウンロード
.NET Coreをダウンロード
Visual Studioで適当にConsole Appを作成
Console.WriteLineにBreakPointを置いてデバッグ実行

Debugger operation failed 
launch: program '' does not exist.

f:id:suzusin:20190326194844p:plain

調べたところ、dotnetへのpathが通っていないとのことだった。

$ dotnet
zsh: correct 'dotnet' to 'done' [nyae]? n
zsh: command not found: dotnet
$ ln -s /usr/local/share/dotnet/dotnet /usr/local/bin
$ dotnet
zsh: correct 'dotnet' to 'done' [nyae]? n

Usage: dotnet [options]
Usage: dotnet [path-to-application]

Options:
  -h|--help         Display help.
  --info            Display .NET Core information.
  --list-sdks       Display the installed SDKs.
  --list-runtimes   Display the installed runtimes.

path-to-application:
  The path to an application .dll file to execute.

linkを貼ることで無事デバッグできるようになった。

2019-02-09

docker-composeのProjectという概念について

大本のディレクトリを分けても、同名フォルダ配下にあるymlを元に docker-compose up するとRecreating されてしまう。

例えばmyProjectに開発用のymlがあるとする（volumes等々だいぶ記述を省いている）。フォルダ名をmyProjectとする。

myProject/docker-compose.yml

version: '2'

services:
  nginx:
    image: nginx
    container_name: "nginx-dev"
    ports:
      - "8080:80"

  app:
    build: ./php
    container_name: "app-dev"

普通に起動すると、こうなる。

$ docker-compose up -d
Creating network "compose_default" with the default driver
Creating app-dev   ... done
Creating nginx-dev ... done

$ docker-compose ps
  Name                 Command              State          Ports
------------------------------------------------------------------------
app-dev     docker-php-entrypoint php-fpm   Up      9000/tcp
nginx-dev   nginx -g daemon off;            Up      0.0.0.0:8080->80/tcp

あまり使うことはないが、docker ps でも見てみる。

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
3e845fb43f2e        nginx               "nginx -g 'daemon of…"   53 seconds ago      Up 52 seconds       0.0.0.0:8080->80/tcp   nginx-dev
d60726667f0e        myproject_app         "docker-php-entrypoi…"   53 seconds ago      Up 52 seconds       9000/tcp               app-dev

コンテナ名はそれぞれ、ymlのcontainer_nameで指定したものになっている。ただ気にしていなかったのは、appコンテナはDockerfileから作っているので、myproject_appというIMAGE名になっている点。

この環境を検証環境やステージングで使おうとしたとき、2環境欲しいなと思うことがある。 1つの環境はチームメンバーが通常開発に使用する安定的なもので、もう1つは設定や構成を変更する開発案件で使用するもの。

そこで、ymlを分けて以下のように管理することにした。

/myProject
|--docker-compose.yml
|--php
| |--Dockerfile
|--ymlfiles
| |--docker-compose.staging.develop.yml
| |--docker-compose.staging.stable.yml

ポートフォワーディングでホスト側を分ければ2環境同時に使うことができると考えた。

myProjectはgit cloneしてきた同じものだが、その上の階層で分けている。

/home/webmaster/stable/myProject/ymlfiles
/home/webmaster/develop/myProject/ymlfiles

そしてコンテナ名もそれぞれ変更した。これで問題ないように思えた。

version: '2'

services:
  nginx:
    image: nginx
    container_name: "nginx-staging-stable"
    ports:
      - "8080:80"

  app:
    build: ../php
    container_name: "app-staging-stable"

version: '2'

services:
  nginx:
    image: nginx
    container_name: "nginx-staging-develop"
    ports:
      - "8080:80"

  app:
    build: ../php
    container_name: "app-staging-develop"

stableを立ち上げる。

$ docker-compose -f docker-compose.staging.stable.yml up -d
app-staging-stable is up-to-date
Starting nginx-staging-stable ... done

$ docker-compose -f docker-compose.staging.stable.yml ps
        Name                      Command              State          Ports
-----------------------------------------------------------------------------------
app-staging-stable     docker-php-entrypoint php-fpm   Up      9000/tcp
nginx-staging-stable   nginx -g daemon off;            Up      0.0.0.0:8080->80/tcp

developを立ち上げる。

$ docker-compose -f docker-compose.staging.develop.yml up -d
Recreating app-staging-stable   ... done
Recreating nginx-staging-stable ... done
szk416s-MacBook-Pro:~/study/myProject/ymlfiles szk416 $ docker-compose -f docker-compose.staging.develop.yml ps
        Name                       Command              State          Ports
------------------------------------------------------------------------------------
app-staging-develop     docker-php-entrypoint php-fpm   Up      9000/tcp
nginx-staging-develop   nginx -g daemon off;            Up      0.0.0.0:8080->80/tcp

なんと、 Recreatingされてしまい、先に作ったapp-staging-stableとnginx-staging-stableは消えてしまった。

docker ps で見ても同じ。

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
d569715fafaf        nginx               "nginx -g 'daemon of…"   56 seconds ago      Up 54 seconds       0.0.0.0:8080->80/tcp   nginx-staging-develop
159d41b57e5b        ymlfiles_app        "docker-php-entrypoi…"   56 seconds ago      Up 54 seconds       9000/tcp               app-staging-develop

何が起こったのか？

docker-compose にはProjectという概念がある

公式ドキュメントにはちゃんと書いてあるし、確認するコマンドもある

-p, --project-name NAME 別のプロジェクト名を指定 (デフォルト: directory name)

各設定ファイルはプロジェクト名を持っています。 -p フラグでプロジェクト名を指定できます。フラグを指定しなければ、Compose は現在のディレクトリの名前を使います。詳細は COMPOSE_PROJECT 環境変数をご覧ください。

cf. docker-compose コマンド概要 — Docker-docs-ja 17.06.Beta ドキュメント

ここでいう、 フラグを指定しなければ、Compose は現在のディレクトリの名前を使います というのが重要で、 docker ps の結果の方を見ると、 ymlfiles_app と、ディレクトリ名 + サービス名になっていることがわかる。

つまり、いくら大本のディレクトリから分けていたとしても、親ディレクトリが ymlfiles なので同じプロジェクトとして扱われてしまっていた。基本的にはない話だが、本番環境などであればシャレにならない。

そもそも、環境変数にymlを指定する手段があるところを見ると、複数立てるようなことはしない方が良いのだろう。

suin.io

フォルダごとに.envを置いてPROJECT_NAMEを指定する手段もあるようだが、こういうのは後からチームに加わった人が気付きづらいので良くないと考えている。

結局、ymlfiles-stable, ymlfiles_develop のように分けて管理することにした。愚直だが一番わかり易いと思う。

2019-02-04

安全なcron書き換え方法のメモ

備忘録
いくつか宗派があるらしい

はじめに

[ cron 編集 ] とかで調べると [ crontab -e ] が出てくると思います
- これを使うのはやめましょう
- crontab -r と打ち間違えると既存の設定が消えてしまいます
  - cf. https://ozuma.hatenablog.jp/entry/20120711/1342014448

オススメの手順

sudo crontab -l > crontab.bak
cp -p crontab.bak crontab.new
vi crontab.new
sudo crontab -l | diff crontab.new -
sudo crontab crontab.new
sudo crontab -l | diff crontab.bak -

説明

現在のcron 設定一覧を bakファイルに書き出し
それを newにコピー（存在する場合は上書きとなる）
作成した newを書き換える（ここで本来行いたかった変更）
現在の設定と newを比較
作成した newファイルを食わせて反映
変更箇所を念のため確認

その他

これらの手順でも、結局typoで -r を打ったらしょうもないのでコピペで行きましょう。
すぐに走らせたくても余裕を持って2分先くらいを指定しましょう。