Cloud Penguins

Flying penguins in the cloud.

VMwareを退職します

このたびVMwareを退職することになりました。数週間前から有休消化期間に入っており、今週末をもって退職となります

有休消化期間は、Cloud Operator Days Tokyo 2021のシステム周りをお手伝いしていたり、CI/CD Conference 2021を開催したりしてました。

VMwareに入社したのは2020年の春。それから考えると僅か1年半なのですが、元々はPivotalという会社に所属しており、買収を経てVMwareとなったので、Pivotal時代から通算するとおおよそ4年半在籍していたことになります。

そもそも何をしてたんだっけ

PivotalおよびVMwareでは、Senior Solutions Architectというポジションに居ました。一般的にSolutions Architectというとプリセールスエンジニアを指すことが多いのですが、Pivotalの場合は製品を購入していただいたお客様に対して導入の支援やコンサルティングを行う、いわゆるプロフェッショナルサービスと呼ばれる類いの仕事をしていました。

元々NTT CommunicationsでCloud FoundryをベースとしたPaaSを開発していたこともあり、Cloud Foundryの本家本元であるPivotalに転職したという経緯があります。Pivotalでは商用版であるPivotal Cloud Foundryや、KubernetesディストリビューションのPivotal Container Service、VMwareになってからはVMware Tanzu(Pivotalから継承した製品含む) 周りのプロダクトの導入支援に携わっていました。

自分がCloud Foundryに触れたのは2011年のことだったので、NTT Com->Pivotal->VMwareと延べ10年に渡り、このPaaSに関わってきたことになりますね。時が経つのは早いなぁ。

Pivotalってすごかったんだよ

Pivotalは2013年に設立された非常に若い会社でしたが、 Transform How The World Builds Software - 世界のソフトウェアの作り方を変える- のミッションのもと、主に大企業に向けたプロダクトとサービスの提供を行っていました。単にプロダクトを提供するのではなく、ソフトウェアの変革に必要なのはチームとその文化であるという強い信念を全社員が持って取り組んでおり、その信念に反する(Pivotalっぽくない) ことはやらないという、言うなれば我の強い会社だったなあと思います。

f:id:jaco-m:20200929200747j:plain ▲ Pivotalのコアバリュー。今見ても良いなって思う

ビジネスの対象としては、いわゆるエンタープライズと呼ばれる超大企業がメインでしたが、そういったビジネスの会社にありがちな堅さは全くなく、めちゃくやオープンでフレンドリーなカルチャーでした。春になるとオフィスに桜が咲き、秋にはカボチャが生え、それが終わるとクリスマスツリーが生える。いつも卓球台からは楽しそうな声が聞こえる。そんな環境でした。

f:id:jaco-m:20180404111136j:plainf:id:jaco-m:20190315170947j:plainf:id:jaco-m:20181025112616j:plainf:id:jaco-m:20171114203434j:plainf:id:jaco-m:20171031173808j:plain

こういうのをみると、「あ、シリコンバレーの会社っぽいな」って思うかもしれませんが、まさにそれ。Pivotalの場合は、Pivotalという存在自体がある意味商材そのもので、自らが持つソフトウェア開発に向いたシリコンバレーの文化を、エンタープライズにも広げていくという考えでやっていました。 "Silicon valley is not just a place, it's a state of mind" (シリコンバレーとは地名ではなく、マインドセットである) ともよく言っていましたね。

Platform as a Product

前述したように、自分はソフトウェア開発ではなく、Pivotal Cloud Foundryを中心としたクラウドのプロダクトを中心に担当していましたが、それでもこのPivotal文化による影響はバンバン受けていました。

その中でも、Platform as a Product(プロダクトとしてのプラットフォーム) という考え方に触れられたことは、自分が十数年この業界で生きてきた中でも最も衝撃的でした。一言でいうと、「役に立つプラットフォームを作るのであれば、それをプロダクトとして育てよう」という考え方なのですが、この一文で衝撃度合いを伝えるのが難しいので、CloudNative Days Tokyo 2020で発表した以下のセッションを見て欲しい。

スライド speakerdeck.com

動画 event.cloudnativedays.jp

記事 thinkit.co.jp

また改めて整理してブログに書いてもいいなと考えてたりします。

じゃあなんで辞めるの

Pivotalのすごさを語るといくらでも書けてしまうので一旦この辺にしておきますが、じゃあ何故今回退職することになったか。

まあ、VMwareはPivotalじゃなかったから という点は間違いなく理由としてあるのですが、これだけだとネガティブに伝わってしまうのでもう少し補足。

VMwareになってからは1年半経つのですが、実は大きな不満というものはないんですよね。良くも悪くも小さい会社(といっても数千人いたけど)だったPivotalに比べると、こちらは数万人規模の巨大なソフトウェアベンダー。体制の充実度は圧倒的に高く、待遇としてもPivotal時代よりも圧倒的に良くなりました。仕事の内容も同僚もポジションも変わらないのに待遇がめっちゃ良くなるの、不思議な体験でした。

また、PaaSやCaaSといったチャレンジングなプロダクトを中心としたPivotal時代と比べれば、VMwareには圧倒的なパワーを誇るプロダクトがずらっと並んでいる。こういった足腰のしっかりしたプロダクトの上に、VMware Tanzuという新しいプロダクトを載せるという形になったので、安定度(プロダクト、マーケティング双方)を増しつつも新しいことをやれるといういいとこ取りな状況になったのです。強い。

ただ、プロダクト力で推していくビジネスは強力な一方、社員に求められるものも必然と変わってくることになりました。買収と会社の成長を通じて、良い意味で フェーズが変わった んだなと個人的には考えていて、じゃあどうするかと考えた末、自分としても新しいことやろうと思い、今回の決断に至った次第です。

次は何するの

来週から新しい職場になるので、それは改めて書こうかなと思っています。 が、業界としてはほぼ同一(直接のコンペではない) なところに居るので、今居るコミュニティには引き続き参加していくつもりですし、VMwareプロダクトにも継続して触れていきたいなと思っています。

あ、VMwareの社員向けのライセンス使えなくなるから、VMUG Advantage入らないとな。

あと、11月4-5に開催するCloudNative Days Tokyo 2021、現在CFPオープンしていて締め切りは明日 9/8です!クラウドネイティブ技術に関するものであれば何でも審査の対象となりますので、ネタのある方は急いでご応募ください!

event.cloudnativedays.jp

あと定番のほしいものリスト

Amazon.co.jp

Synology上のDockerでPort80,443が使えない件をなんとかする

TL;DR

SynologyでPort 80や443を使うコンテナ動かしたければ、 システムのnginxをリバースプロキシとして使おう。

/etc/nginx/sites-enabled に nginxのVirtual Hostの設定をぶっ込んでリロードすれば行ける

自宅サーバーとしてSynology便利だけど・・・

みんな大好きSynologyのNAS。

一般家庭でも手の届きやすい金額で入手できる上に、豊富なパッケージにより単なるネットワークストレージだけでなく、サーバーとしての機能も持たせられる。メディアサーバーにもできるしウェブサーバーにも出来る。何ならLDAPサーバーやActiveDirectoryも出来ちゃう。パッケージにないものであれば、ハイパーバイザも提供しているのでVMで建てることもできるし、Dockerパッケージもあるのでコンテナとして立ち上げてしまえば実質何もできちゃう。マジ便利。

自宅で勉強がてらKubernetesクラスタを立ち上げているような人であれば、有志によりSynology CSIが提供されているのでPVをここに持ってくることも出来てしまう。便利。

github.com

Dockerでウェブサーバーが立ち上げられないぞ・・・!

じゃあDockerで何でも立ち上げられるんだね、やったー! ということで、Synology上のDockerでnginxを立ち上げようとすると、こういうエラーになってしまい立ち上げられない。

jacopen@synology:~$ sudo docker run -p 80:80 nginx

docker: Error response from daemon: driver failed programming external connectivity on endpoint epic_turing (3f98a359a914e07caa28b26ec4900650668df4eeecdefd28fca18be4a799e974): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use.
ERRO[0001] error waiting for container: context canceled

tcp 0.0.0.0:80: bind: address already in use. はい。80番や443番は既にシステムによって使われてしまっているため、Dockerから叩けないのである。実際SynologyのIPをブラウザで叩くと、5000番にリダイレクトされてDSM(DiskStation Manager)の画面が表示されることが分かるだろう。

単に静的なコンテンツをホストするだけであれば、パッケージでいくつかのウェブサーバーが提供されているのでそれを使えば良い。 f:id:jaco-m:20210818201241p:plain

しかし、Dockerで立ち上げてたウェブアプリに対してSynologyのIP経由で80や443経由でアクセスさせたいというケースも多いだろう。実際自分も、S3互換のオブジェクトストレージであるMinioや、コンテナレジストリであるHarborをSynology上に立ち上げようとしてこの問題に当たってしまった。

Synology上の80や443は誰が使っているのか

じゃあこのSynology上の80や443は誰が使っているのか。SynologyにSSHでログインしてnetstatしてみるとこう出る。

$ sudo netstat -anp | grep -e "0.0.0.0:80" -e "0.0.0.0:443"
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      13584/nginx: master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      13584/nginx: master

どうやらnginxが立ち上がっているようだ。これはWebサーバーのパッケージを入れなくても、必ず立ち上がっている。

またDSMのデフォルトポートである5000や5001も、nginxを経由していることが分かる

$ sudo netstat -anp | grep -e "0.0.0.0:5000"
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN      13584/nginx: master

nginxに任意の設定を食わせる

これらの設定ファイルは、/etc/nginx に存在する。 /etc/nginx/nginx.conf を親として、 /etc/nginx/app.d/etc/nginx/conf.d に個別の設定が格納されている。DSM自体や、パッケージでインストールした各アプリケーションへのルーティングも、app.dやconf.dに格納されるようになっている。

/etc/nginx/nginx.conf を開いてみると、以下のような記述があることが分かる。

    include conf.d/http.*.conf;
    include app.d/server.*.conf;
    include sites-enabled/*;

そう、 nginxがこれらのファイルをincludeしてくれるのである。なので、nginxをリバースプロキシとすれば任意のアプリに対してルーティングを設定出来るというわけだ。

ただ、app.d配下に関してはDSMをアップグレードすると初期化されて消えてしまう。そこで、sites-enabled内に以下のようなファイルを設置した。

server {
  server_name minio.udcp.run;
  listen 80;
  access_log /var/log/nginx/concourse.access.log;
  location / {
          proxy_set_header Host $http_host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          client_max_body_size 100M;
          proxy_pass http://localhost:9000/;
  }
}

DockerでPort 9000でMinioを立ち上げている。minio.udcp.runへのリクエストがあった場合は、そこへのリバースプロキシとして機能するという設定だ。

コンフィグファイルの作成が終わったら、以下のコマンドでnginxをリロードする。

sudo synoservice --reload nginx

無事ブラウザからアクセス出来た。

f:id:jaco-m:20210818210019p:plain

なお、この設定はDSM 6.2系で確認している。最新の7系ではどうなるかはまだ未確認。

Auth0でTKGのクラスタを認証できるようにする

TKGでは、認証に外部Identity Provider(IdP)を利用することができる。TKG1.3以降はPinnipedというコンポーネントが含まれており、これが外部IdPを担った認証を行うようになっている。

Pinnipedについては星野さんのCNDO2021の発表が参考になるので興味のある方は是非。

event.cloudnativedays.jp

OpenID Connectを使った認証はTKGのドキュメントに記載があるのだけど、これはOktaを使った説明になっている。 自分は普段Auth0をIdPとして使っており(CNDT/CNDOもAuth0)、そちらを使ったログインをやりたいなと思い、今回の記事を書くことにした。

なおOkta/Auth0に限らずOpenID ConnectなIdPであれば似たような設定で利用可能だと思うので、適宜読み替えて活用してもらえれば。

Management Clusterの構築手順

これ以降の解説はTKG1.3.1 を前提とする。

Management Clusterを作る

Management Clusterの作り方は、1点を除き通常とほぼ変わりなし。今回はUIを使って構築してみる。

$ tanzu management-cluster create --ui

f:id:jaco-m:20210530141517p:plain いつもの画面。今回はvSphereを使うが、認証周りについてはEC2でもAzureでも同じだと思われる。

f:id:jaco-m:20210530141623p:plain Iaas Providerの設定は通常と変わらず。各自利用している環境に合わせて変更。

f:id:jaco-m:20210530141705p:plain Management Cluster Settings。ここも通常と変わらないが、 CONTROL PLANE ENDPOINT の値だけちゃんとメモしておくこと。後で使います。

この後 6. Kubernetes Networkまでは通常と一緒なので割愛。

次に7. Identity Management。ここが一番のポイント。一旦TKG側の設定はここで止めておいて、Auth0の設定に入る。

Auth0の設定をする

auth0.com Auth0にログインをする。アカウントを持っていない方は新規登録しておきましょう。今回の用途くらいであれば無料の範囲内で利用可能。

f:id:jaco-m:20210530142544p:plain ログインしたら、Applications-> Create Applicationをクリック。

f:id:jaco-m:20210530142651p:plain Nameは任意の名前を。application typeはRegular Web Applicationsを選ぶ。

f:id:jaco-m:20210530143203p:plain 次にアプリケーションの設定にはいるが、すこし下にスクロールしたところにあるApplication URIsのAllowed Callback URIsに https://<Control PlaneのIP>:31234/callback を入れる。IPには先ほど控えたControl Planeの値を。これが出来たら一旦Save。

TKGのOIDCの設定をする

Auth0の画面を開いたままTKGの画面に戻る。 f:id:jaco-m:20210530143847p:plain Identity Managementの項目に、Auth0の値を転記していく。

  • ISSUER URL - http://<Auth0 appのDomain>/
    • https:// および 末尾のスラッシュを忘れないこと。これを忘れるとログインが失敗する
  • CLIENT ID - Auth0のClient ID
  • CLIENT SECRET - Auth0のClient Secret
  • SCOPES - openid,groups,email
  • USERNAME CLAIM - どの値をUsernameとして扱うか。今回は email を指定
  • GROUPS CLAIM - どの値をGroupとして扱うか。今回は groups を指定

入れ終わったらNEXTをクリック。残りの設定は通常のクラスタ作成と変わらない。

f:id:jaco-m:20210530144528p:plain 全ての設定が終わったらインストールを開始。しばらく待ち。

Management Clusterの設定

Management Clusterの設定が終わったら、次は tanzu コマンドを使ってadminのkubeconfigを取得。この段階ではOIDC認証は使っていない。

$ tanzu management-cluster kubeconfig get --admin
Credentials of cluster 'demo' have been saved
You can now access the cluster by running 'kubectl config use-context demo-admin@demo'
$ kubectl config use-context demo-admin@demo
Switched to context "demo-admin@demo".

Pinniped周りのPodが正しく上がっているかを確認。この段階で何らしかのErrorが発生していたら、コンフィグを間違っている可能性があるので kubectl logs などを使って確認する。

$ kubectl get all -n pinniped-supervisor
NAME                                      READY   STATUS      RESTARTS   AGE
pod/pinniped-post-deploy-job-bfzhn        0/1     Completed   0          3m4s
pod/pinniped-supervisor-f5dd7d547-pbxbd   1/1     Running     0          2m20s
pod/pinniped-supervisor-f5dd7d547-xjw8l   1/1     Running     0          2m20s

NAME                          TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
service/pinniped-supervisor   NodePort   100.65.72.169   <none>        443:31234/TCP   3m4s

NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/pinniped-supervisor   2/2     2            2           3m4s

NAME                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/pinniped-supervisor-f5dd7d547   2         2         2       3m4s

NAME                                 COMPLETIONS   DURATION   AGE
job.batch/pinniped-post-deploy-job   1/1           44s        3m4s

次に、OIDC経由のユーザーにClusterRoleを付与する。今回はManagement Clusterの全権を付与したいので、cluster-admin をユーザーにつける。ユーザーに与える権限を絞りたい場合は、ここで別のClusterRoleやRoleをbindingすれば良い

$ kubectl create clusterrolebinding cluster-admin-jacopen --clusterrole cluster-admin --user jacopen@gmail.com
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-jacopen created

終わったら、OIDCで認証するためのkubeconfigを出力する。今回は /tmp/mgmt_oidc_kubeconfig に出力している

$ tanzu management-cluster kubeconfig get --export-file /tmp/mgmt_oidc_kubeconfig
You can now access the cluster by running 'kubectl config use-context tanzu-cli-demo@demo' under path '/tmp/mgmt_oidc_kubeconfig'

出力したkubeconfigを使ってリソースを取得してみる。

kubectl --kubeconfig /tmp/mgmt_oidc_kubeconfig get all

すると、自動的にブラウザが立ち上がってAuth0の認証画面に飛ばされるので、Auth0に設定してある認証手段(user/pass, Google, GitHubなど)を利用してログイン。すると、ブラウザには以下のように表示され、kubectl側では無事にレスポンスが帰ってきているはず。

f:id:jaco-m:20210530155644p:plain

これで無事Management ClusterをOIDCのユーザー経由で利用できるようになった。

OIDC経由のユーザーでtanzuコマンドを利用できるようにする

OIDC経由のユーザーをcluster-adminにしたので、そのユーザーを使ってtanzuコマンドからclusterの作成等が可能になる。

環境を分けるために別ユーザーを作成の後、 tanzu login --endpoint "https://<Management Cluster IP>:6443" --name <Management Cluster名> を実行。

すると自動的にブラウザが立ち上がり、Auth0での認証が行われる。認証が通れば以下ののようになる。

$ tanzu login --endpoint "https://10.9.11.103:6443" --name demo
✔  successfully logged in to management cluster using the kubeconfig demo
$ tanzu management-cluster get
  NAME  NAMESPACE   STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES
  demo  tkg-system  running  1/1           1/1      v1.20.5+vmware.1  management


Details:

NAME                                                     READY  SEVERITY  REASON  SINCE  MESSAGE
/demo                                                    True                     113m
├─ClusterInfrastructure - VSphereCluster/demo            True                     113m
├─ControlPlane - KubeadmControlPlane/demo-control-plane  True                     113m
│ └─Machine/demo-control-plane-kp9pv                     True                     113m
└─Workers
  └─MachineDeployment/demo-md-0
    └─Machine/demo-md-0-86cb4697d7-sm8p8                 True                     113m


Providers:

  NAMESPACE                          NAME                    TYPE                    PROVIDERNAME  VERSION  WATCHNAMESPACE
  capi-kubeadm-bootstrap-system      bootstrap-kubeadm       BootstrapProvider       kubeadm       v0.3.14
  capi-kubeadm-control-plane-system  control-plane-kubeadm   ControlPlaneProvider    kubeadm       v0.3.14
  capi-system                        cluster-api             CoreProvider            cluster-api   v0.3.14
  capv-system                        infrastructure-vsphere  InfrastructureProvider  vsphere       v0.7.7

tanzuコマンドを使ってManagement clusterの情報を得ることができた。

TKGのダウンロードやドキュメントにさっくりたどり着く方法

今日は小ネタ。

今すぐTKGのCLIバイナリやドキュメントにアクセスしたい!ってこと、よくありますよね?(あるのか?)

これらはMy VMware からアクセスできるんですが、検索使ったとしても探すのがちょこっと面倒くさい。

GoogleでTKGで検索しても、たまごかけごはんばっかり引っかかってTanzu Kubernetes Gridにはなかなかたどり着けない。

ということで、TKGには https://www.vmware.com/go/get-tkg というショートカットが用意されていて、直接ダウンロードページに飛べるようになっています。

ぶっちゃけそれすら面倒なので、もっと簡単に飛ぶには、ブラウザの検索窓で "get-tkg"と入れればOK f:id:jaco-m:20210119113108p:plain

これで一番上にダウンロードページが出てきます。

f:id:jaco-m:20210119113203p:plain

右のDocumentationからドキュメントに飛ぶことも可能。

2020年買って良かったもの

n番煎じと言われても気にしない。jacopen的今年買って良かったモノを1年の振り返りがてら書いてみる。

ガジェット

SONY VLOGCAM ZV-1

ソニー Vlog用カメラ VLOGCAM ZV-1

ソニー Vlog用カメラ VLOGCAM ZV-1

  • 発売日: 2020/06/19
  • メディア: Camera

ソニーのVLOG向けカメラ。商品レビュー撮影モードの鬼のようなオートフォーカスの速さがヤバい。手ぶれ補正はないので出先で使うとそれなりにブレるが、これはCatalyst Browseでソフトウェア的に補正が可能。

普段はリモートワーク時のWebカメラとしての出番が多いが、出かける時はついでに持ち運んでいる。

eMeet luna

これまたリモートワークの友である会議用マイクスピーカー。1万円を切る価格なのに音質はとても良く、有線、無線いずれの使い方もできて便利。それまではコンデンサマイクを利用していたが、リモートワークにはオーバースペックなのと場所の問題もあったが、eMeet Luna導入で快適さが断然増した。

ATEM Mini

言わずと知れた超コスパスイッチャー。コロナ禍では品不足で全然買えなかったようだが、最近は在庫が安定してきた様子。自分はコロナ禍より前に買っていたので良かった。

USB接続できないカメラをWebカメラ化するのに利用したり、いくつかお手伝いしている配信のスイッチングなどにも利用している。

ハイセンスの65型テレビ

引っ越しを機に購入。国内メーカーとの比較で迷ったが、価格と品質のバランスでハイセンスを選択。65インチはちょっと大きすぎるかな?とも思ったが、実際に使ってみるとむしろちょうど良い大きさだった。F1ファンとしては、情報量がめっちゃ多いF1 ZONEも見やすく大満足。

ゲーミングPC

www.dospara.co.jp

オンライン配信をする際、それまで使っていたMacbook Proでは全然性能が足りず、かつMac版OBSの質も良くなかったためWindows移行を決意。ちょうどWSL2が出たタイミングで、普段の作業にも困らなくなってきたのも後押しになった。 どうせ買うなら十分なスペックのモノをということで、ドスパラのゲーミングPCを購入。Ryzen 3900Xに64GBメモリ。スペックの余裕は心の余裕。OBSはもちろんPremiereやAfter Effectsも快適に使えるので満足。

DELL XPS15

www.dell.com

自宅環境はゲーミングPCでいけるが、出先で配信の裏方をやる際にMacbook Proでは以下略のため、パワーのあるノートPCが必要になってきた。配信の為にはGPUパワーが重要ということで、GTX 1650 Tiを積んだXPS15を選択。ベゼルが細くてかっこいい。おかげで15インチだけどフットプリントはとても小さい。

出先での利用のほか、リビングでテレビを流しながら作業をする用途にも利用している。

トレーニング

コロナ禍で在宅勤務になったこともあり、こりゃ運動しないと体型ヤバいことになるなと思いオンラインのパーソナルトレーナーをつけてみた。結果、コロナ前よりも健康になってきた感ある。 以下はトレーニングのために購入してよかったもの。

可変式ダンベル

最初は自重トレーニングをやっていたが物足りなくなってきたため、可変式のダンベルを購入。細かく主さを調整できるパワーブロックタイプを購入。それまでは10kgのダンベルですら重たいと思っていたのだが、トレーナーから「20kg x2くらいはすぐに物足りなくなりますよ」と言われ、嘘やろと。でもまぁ、可変式であれば重たい側を使わなければいいだけだし、とりあえず買ってみようとこちらを選択。

それから半年経った今、20kgでは全然足りず最大重量の26kgでスクワットしてる。筋肉ってすごい

パワーグリップ

正直筋トレってあまり好きではなかった。みんな重たいダンベルやバーベルをすいすい挙げているのに、自分はその1/3すら持てない。腕や足の筋肉というよりも、握力が足りず手のひらが痛くなってしまい嫌になるパターンが多かった。 ・・・ということをトレーナーに話してみたところ、ウェイトトレーニングやるならパワーグリップは必須ですよと。え、なんそれ初めて聞くアイテム。 ということで、こちらを購入。

筋トレ上級者にはゴールドジムのパワーグリップが定番らしいのだが、レビューを見る限りその1/3の値段で遜色ない品質ということでこちらに。

効果はてきめんで、あ、筋トレってこんなに楽しくやれるものなんだと衝撃を受けるほどだった。握力を使うこと無く鍛えたいところに負荷をかけられるので、その分成長も早いように感じる。

チンニングバー

ダンベルでも良い感じに鍛えられていたのだけど、もっと別のパターンで腕や背中を鍛えたいなということでこちらの懸垂バーを購入。突っ張り棒のように設置するタイプで、自室の入り口に設置している。値段も安く中国産ということで、もし落ちたら大怪我だよな・・・と不安だったが、設置してみるとガッチリ固定されてビクともしない。今のところ不安になる挙動はなく、目論見通りのトレーニングが出来ているので満足。

その他

ミーレ食洗機

www.miele.co.jp

引っ越し先にはホシザキのビルトイン食洗機がついていた。これは洗いが10分程度で終わるユニークな製品だったが、如何せん洗浄力が弱かった。3倍の時間をかけていいからちゃんと汚れを落として欲しかったのだが・・・。

汚れの落ちない食洗機にフラストレーションが溜まってきたため、奮発してミーレの食洗機を購入。こちらは洗いに時間はかかるものの、洗浄力は十分にも関わらず静かで省エネ。洗剤の量も半分で済むようになった。QoL爆上がり。

眼鏡(乱視矯正入り)

今年初め、嫁の父親の付き添いで偶然訪れた眼鏡屋で視力検査してもらったところ、軽度の乱視があることが判明。1年ほど前から目の疲れに悩まされていたのだけど、これが原因だったようだ。

ということで乱視矯正入りの度無し眼鏡を購入。

体感できるほどの効果が出ており、PCを使うときには必ず眼鏡を使うようになった。頭痛も肩こりも軽減したように感じており、ほんと買って良かったなと思う。

React入門したい

今日は雑記。

CloudNative Days Tokyo 2020では、配信プラットフォームを自作したんだけどこれにはRailsを使っている。Railsを選択した理由は、開発を担当した自分と r_takaishiが過去に経験があり一番素早く作ることができたからだ。

正直Railsでほとんど困っておらず、圧倒的な速さで作ることができたので全然これでいいのだが、せっかくフロントエンドに手を出すのであれば新しいものを経験したい気持ちもあるっちゃある。

ということで、Reactデビューしてみることにする。ちなみにこのあたりの知識はゼロでガチの初心者。

手始めに参考にしているサイト

チュートリアル:React の導入 – React

正真正銘のReactだけの不純物なしでReact入門

初めてのReact「入門編」導入から基本まで〜TODOアプリを作ってを学ぼう! | 株式会社ウェブ企画パートナーズ

まだ全然わかっていないのでこれから調べていくこと

  • JavaScriptで書いていくべきなの、それともTypeScriptを使ったほうがいいの
  • SSRとやらをするの?しなくていいの?NextJSとかExpressとか出てくるけどこいつらをどう使うの?
  • フレームワークを使ったほうがいいの?Gatsby.jsってやつ?
  • reduxってなんぞ
  • routerってなんぞ