【AWS Amplify】AWS Amplify を推したい。(2021年以降の気になるアップデートのまとめ)
先日のはじめてのIT勉強会のLTで発表した内容をブログにしたものです。
この記事で書きたいこと
- AWS Amplify は小規模・プロトタイプ開発向けではなくなってきている。
- かなり強力なアップデートがされており、今後も要チェックのサービス。
- AWS Amplify の様なサービスが普及した時、一人のエンジニアが持てる役割はより大きくなりそう。
以前の AWS Amplify
僕が最初に触れた 2018年頃はプロトタイプ・小規模開発向けという位置づけだったと記憶しています。
(トップページも更新されてしまい、当時のソースは見つけられませんでした。。)
ただ、実際に当時は Amplify の管理するリソースをカスタマイズ出来ない、データベースは DynamoDB しか選べない、などの制限が多くプロダクトとして利用するの際の拡張性・柔軟性に欠けるという印象でした。
最近のアップデートが激アツ
そんな Amplify ですが、2021年あたりのアップデートから非常に機能が強化されていました。
細かいことも含めつつ、いくつかのアップデートをピックアップしてご紹介していきます。
CI/CD のサポート
GitHub と連携したCI/CDをサポートがされました。
元々CLI ベースのデプロイ機能はありましたが、GitHub Acitons などを自身で設定せずに CI / CD 環境を構築出来る様になっています。
AWS Amplify がフルスタック CI/CD 機能を新たにローンチ
AWS CDK によるカスタマイズに対応
Amplify のネックだった Amplify CLI 未対応のリソースを管理することが出来ます。これは激アツ。
Extend Amplify backend with custom AWS resources using AWS CDK or CloudFormation | Front-End Web & Mobile
AWS CDK によるオーバーライドに一部対応
Amplify CLI で作成したCognitoなどをカスタマイズすることが出来るようになりました。
AWS Amplify が CDK を使用して Amplify で生成されたリソースをオーバーライドする機能を発表
Amplify Studio + Figma によるコンポーネント生成
個人的に可能性を感じるアップデートだと思っています。後述します。
AWS Amplify Studio – 最小限のプログラミングでFigmaからフルスタックのReactアプリを実現 | Amazon Web Services ブログ
拡張性を得た AWS Amplify
以前の Amplify は DB が DynamoDB 以外選べないことや他のサービスと併用する時に結局 CloudFormation を二重管理する必要があるなど拡張性の面で限界が存在していました。
AWS CDK 対応のアップデートでこれを打ち破ることができる様になり、ある程度の小・中規模のプロダクトなら十分使えるレベルになったと思います。
また、FIgma から React Component を生成する機能も超強力になる可能性があると思います。
自動生成したコードは融通が効かない・使えない・読めないという事は往々にしてよくあることですが、「ロジックとビューの分離」は昨今のフロントエンドのトレンドです。
Container / Presentational にコンポーネントを設計し、自動生成したコードをUIコンポーネントとして Presentational 側で使用する事は決して難しくはありません。
まだ public preview 版ですし、props の型が無いなどのツラミもあると思いますが、今後の動向をチェックして損のない機能だと思います。
まとめ
最近のアップデートにより AWS Amplify は実践的にかなり使えるサービスになってきています。
少なくとも以前のプロトタイプ開発や学生向けといった様な範疇には収まらない水準まで来ており、新規開発の際の選択肢の一つに入れても良いのではないでしょうか。
興味持って頂けた方は上記で列挙した以上のアップデートもあるので是非チェックしてみてください。
僕自身も今後もチェックして触っていきたいと思います。
余談: AWS Amplify を通して個人的に思ったこと
一連のアップデートは単純に便利サービスに進化しただけではなく
「フロントエンド・バックエンド・デザイナーの垣根を薄くしている」
「一人のエンジニアがカバーできる領域が広がりつつある」
ということでもあると解釈しています。
(もしくは元々は一つだったはずなので、昔に戻っているのかもしれませんね。)
Amplify に限らずとも XD で Android の UI を自動生成するなどもありますし、デザインツールで実際の UI をそのまま作る将来は近いのかなぁと。
この先もプログラマー・デベロッパーを続けていくには、
デザインやネットワークなどより上もしくは下のレイヤーの知識を身に着けていかないといけないのかもしれませんね。
この先はそのつもりで色々とキャッチアップしていこうと思います。
【レビュー】食洗機買ったらQOL爆上がりした
よくあるタイトルつけちゃいました。
食洗機買いました
最高です。
「食洗機気になる！！」と言ってもらう事も多かったので、
使った感想・レビューを書いていきたいと思います。
購入した商品はこちら
評判の良いこちらを買いました。
分岐水栓を取り付けるタイプです。
パナソニック 食器洗い乾燥機 プチ食洗 ホワイト NP-TCR4-W
QOL爆上がりポイント3点
時短
シンプル is ベストです。最高。自炊のモチベがあがる。
「ちょっとコチュジャンを取る為にスプーン使いたいけど洗い物増えるの面倒...」「野菜切ったから少しボウルに置いておきたいけど洗い物が増えるのは面倒...」
そんな時に気兼ねなくスプーンやが使える様になります。
そういうちょっとした手間やワンクッションが無くなるお陰で億劫な気持ちが減り、自炊しようという気持ちが湧きやすくなりました。家庭円満
同居人との洗い物溜めがち論争が解決します。
家電で解決出来るトラブルは家電で解決してしまった方が良いと思います。
我が家の争いの火種はいつだって僕にあるのですが、平和を望んでいない訳ではないのです。
その他にも「手荒れ防止」もあると思います。
僕はあまり肌が荒れないタイプなのですが、同居人の肌があまり強くないので、
その辺りのケアにもなっていれば良いなぁと思います。
感想
最高です。
ちなみに名前はディーゼルと名付けました。
購入・導入までのよもやま話
【購入から導入まで】食洗機買ってみた。
感想は別記事に書いています。 こちらの記事は気になった人の為に購入から取り付けまでのことを淡々と書いていきます。
購入した食洗機・分岐水栓
分岐水栓を取り付けるタイプのこちらです。
パナソニック 食器洗い乾燥機 プチ食洗 ホワイト NP-TCR4-W
お金周りの話
購入費用
このくらいかかりました。
◇ 合計 約6~7万程 ◇ 内訳 本体代 ... 約4万 分岐水栓 ... 約1万 分岐水栓取付工事費 ... 約1万
ランニングコスト
月々かかるお金として、主に以下の2つがあります。
水道光熱費
ざっと調べた限りは月1000円くらいになる様子です。
まだ購入したばかりなので実際にいくらになるのか不明です。食器用洗剤代
「お金 < 時短、家庭円満 」という方針なので強力だと話題のこちらを使うことにしました。
一ヶ月は持つと思うので、月1000円くらいになるかなと思います。 Amazon | ジョイ ジェルタブ 食洗機用洗剤 大容量 54個 Lサイズ | ジョイ | 食器洗い機用洗剤
予想としては大体月辺り2000 ~ 2500円になる見込みで考えています。
購入から導入までの流れ
大まかに以下の流れとなります。
食洗機・分岐水栓を購入する。
置き配をお願いしたのですが、ドアの前にそこそこデカイ家電があると圧巻ですね。分岐水栓の取り付け工事
ちょっと大変でした。後述します。食洗機のセッティング（コンセント・ホース類の取り付け)
食洗機付きの説明書がわかりやすく、とても簡単でした。
購入するまでに二の足を踏んでいる時間が長かったのですが、ほぼ一週間の間に全て済みました。
振り返るともっと早く決断していればと思いました。
トラブル
購入から導入に至るまでいくつかトラブルがありました。
分岐水栓の型番がわからない
住んでいる部屋の分岐水栓が古すぎて型番が消えていた為、問い合わせをする必要がありました。
パナソニック公式に掲載のあるこちらのサイトにメールで写真を送ると回答して頂けます。 www.naniwa-ss.co.jp分岐水栓が取り付けられない
一度知り合いに頼んでチャレンジ頂いたのですが、惜しくも断念する事に。
我が家の築年数が古くかなり固着が激しく簡単には取れない状態だった事が原因です。
こちらのサイトから取付工事をお願いして業者の方に取り付けをお願いすることになりました。
www.mizu-support.com 検索するとお値段については諸説あるようですが、
丁寧に対応頂けたので僕は満足しています。コンセントを見つけられない。
食洗機は延長コードNG且つアース付きのコンセントが必要です。最初にコンセントの位置を調べましょう。
僕はロクも調べもせずに買った為、「コンセントが無い！！」と15~20分程本当に右往左往しました。
本当、たまたま置きたい場所の近くついていてよかったです。
まとめ
悩んでいる方の参考になれば良いなぁと思います。
Next.js チュートリアル冒頭の Falling Into The Pit of Success. を読んでみた。
next.js のチュートリアルの一番最初にある記事を読んだ感想などをばっと書いてみた。 こういう記事は読み飛ばしがちなので、たまにしっかりと読んでみる。
Enter Next.js, the React Framework. Next.js provides a solution to all of the above problems. But more importantly, it puts you and your team in the pit of success when building React applications. 引用元：Create a Next.js App | Learn Next.js
記事の内容
筆者はスタックオーバーフローの設立者で、著名なプログラマーの発言を引用しつつ「あなたの仕事は、言語、API、アプリケーションを常に再設計し、成功の穴をより深く、より広くすることだ。」ということを述べている記事でした。
短くてサクサク読めるので、詳しくは是非実際に読んでみてください。
登場した人達とキーワード
普段、こういう記事に人名が出てくると「誰だ！！」となるので調べてみました。
ジェフ・アトウッドさん。
筆者。StackOverflow の設立者。
Indoor enthusiast. (インドア派)とのことエリックリパートさん。
Facebock のプログラマー。
C# のコンパイラの設計チームや VBScript などの設計実装などに取り組んでいた人とのこと。
メモリの不具合を例にあげ、C++ を自身にとっての「Pit of Despair」と表現している。
About Eric Lippert | Fabulous adventures in codingリコ・マリアーニさん。 Facebock のプログラマー。
言語設計を説明する際にフレームワークやプラットフォームを使用して自然と良い体験を得られることを「The Pit of Success」という言葉を生み出した。ブラッドアダムスさん。 Google のプロダクトマネージャー。
https://www.linkedin.com/in/brabrams 上記の「The Pit of Success」という概念は言語設計に留まらないものだと言っている。
感想
- たまにしっかり読むと色々な示唆や学びがあって良いですね。
- DX/UXって言葉に「楽が出来る・簡単」という印象を持っていたけど「自然と正しい振る舞いを強制すること」「ミスを抑制すること」が重要だと気付かされました。(記事中の「The Pit of Success」に相当する認識。)
- 「適切に設計されたシステムを使用すると正しいことを簡単に実行でき、間違ったことを実行するのが面倒になる（不可能ではない）」という一文が凄く良い。
- この記事では作り手としての意識について述べているけど、反対に利用者としても自然と良い習慣・成功を得られるツールやシステムに触れていくことも大事だと思う。
- 朝起きてカーテンを開けるのは自然で正しい振る舞いなので、SwithBot を買う口実としてこの記事を引用したい。
【Google Chrome】Chrome 97 の全画面表示のショートカットキー変更を元に戻す。
TL;DR
- Chrome 97 から 全画面のショートカットが変わってしまって地味に辛い。
Mac Chrome 97から「フルスクリーンにする」がfn + Fに変更 | iwb.jp - Mac の キーボードショートカット でショートカットを上書きする事が出来た。
- 他のアプリケーションでも応用が効きそう。
対応方法
「システム環境設定 > キーボード > ショートカット > アプリケーション」を開く。
(システム環境設定からキーボードショートカットで検索すれば一発で出来る。)
「+」を押下し、ショートカットの追加を行う。
各項目を以下の通りに設定する。
アプリケーションに「Google Chrome」
メニュータイトルに「フルスクリーンにする」
ショートカットに「⌘⇧F」
設定後に Chrome のメニューを確認するとショートカットが変更されている。 この状態で Chrome を使用すると今まで「⌘⇧F」 でフルスクリーン表示にできる。 (ただし、今まで通り使用する為にはフルスクリーン解除もショートカットの上書きを行う必要がある。)
まとめ
Mac の キーボードショートカット機能を使用することで Google Chrome のキーボードショートカットの変更に対応する事ができる。 またメニュータイトルを基にショートカットの上書きが出来る様子の為、他のアプリケーションでもショートカットの変更が起きた時に対応できるので便利そう。
追記 2022/01/19
正しい元のフルスクリーンのショートカット 「⌘⇧F」 ではなく「⌘F」だったので読み替える様にお願いします。
【Docker】M1 Macで arm64 に対応していない Docker コンテナを動かす。
TL;DR
- M1 Mac上で arm64 に対応していないDockerイメージ(MySQLなど)やライブラリ(numpyなど)を使用したい。
Dockerfileを build するだけではなくdocker-composeを利用したい。- 環境変数
DOCKER_DEFAULT_PLATFORMでlinux/amd64を指定すると、コンテナを amd64 アーキテクチャで起動する事が出来た。
Docker の M1 Macの対応状況 （2022/01/12時点）
Docker Desktop の arm64 に対応していないコンテナ( MySQL など)は amd64 版のコンテナを動かす事で対応できるとのこと。
ただし、一部の API（Linux の inotify など）が完全に動作しない事もあり「 Arm ベースのマシンで Intel ベースのコンテナを実行することは「ベストエフォート」としてのみ見なされるべき」という記載もあります。
Docker Desktop for Apple silicon | Docker Documentation
ファイルやネットワーク周りの OS の機能を触る時は不具合を引くこともありそうですが、特定のランタイムやソフトウェアを使用するだけなら問題なさそうですね。
linux/amd64 を指定して Docker コンテナを動かす方法
環境変数
DOCKER_DEFAULT_PLATFORMにlinux/amd64を指定する。
DOCKER_DEFAULT_PLATFORMは Docker CLI の--platformオプションがサポートされているコマンドに対して、使用するデフォルトのプラットフォームを変更できます。
Docker コマンドラインの利用 | Docker ドキュメントdocker compose upを実行する。
これで docker-compose.yml を書き換えたりせずに、コンテナを amd64 アーキテクチャで起動する事が出来ます。
何故、 DOCKER_DEFAULT_PLATFORM で動くのか
ドキュメントによると DOCKER_DEFAULT_PLATFORM は --platform オプションがサポートされているコマンドに対して機能すると書いてあります。
しかし、docker compose には --platform オプションは明記されていません。
この部分に関しては直接的なソースやリファレンスを見つける事が出来ませんでしたが、docker-compose build の場合、docker cli を用いているという記述を確認しました。
docker-compose build | Docker Documentation
恐らくこれと同様に内部的に Docker CLI を使用している為、 --platform オプションが有効に働いていると予想しています。
余談: docker-compose.yml で platform を指定する方法
Docker Compose で調べると platform オプションでservice毎に platform を指定する方法が出てきます。
例えば、以下の様な docker-compose.yml でも動作することを確認しました。
version: "3.6"
services:
db:
image: mysql:8.0
platform: linux/x86_64
ただし、少しこの辺り不可解な事がありまして、公式の Compose v3 リファレンスにはplatformオプションの記載がありません。
Compose file version 3 reference | Docker Documentation
しかし、Compose v2 リファレンスや Github の最新の Compose Spec（Composeの仕様）には platform の記載があります。
Compose ファイル バージョン 2 リファレンス | Docker ドキュメント
compose-spec/spec.md at master · compose-spec/compose-spec · GitHub
以下のissueとリリースノートによるとv2スキーマとv3スキーマを統合し、COMPOSE_SPECと合わせるとある為、platformオプションがある事が正しい様子です。
もしかしたらドキュメントの更新が追いついていないのかもしれませんね。
https://github.com/docker/compose/pull/5985#issuecomment-683395676
Release 1.27.0-rc1 · docker/compose · GitHub
参考
【はじめてのIT勉強会】自分の為に小さくコミットをする【Git】
はじめに
はじめてのIT勉強会アドベントカレンダー '21 Advent Calendar 2021 - Adventarの１７日目ですね。
投稿が遅れてしまい、申しありません
「はじめてのIT勉強会」ということで、
プログラマーとして「１年目に知っておければ良かった」という事を記事にしてみました。
この記事で伝えたいこと
最近、小さいコミットを心がける様にしてから、少しずつミスが減ったり作業の質が上がったりと良いことが多いと感じました。
そこで、今回の記事を通して、
- 小さくコミットをすると見直ししやすくて良いぞ
- 具体的にはコミットにプレフィックスをつけると良いぞ
という事を伝えられればと思います。
コミットを小さくすると起こる良いこと
さくっとまとめると以下の2つのことが得られました。
ミスの減少
これは「大きい差分を丁寧に見直すよりも小さい差分を細かく見直す方が簡単」だからです。
当たり前の事だと思うのですが、これは実際にコミットと見直しを行ってみて気づきました。思考の整理 これは後述のプレフィックスを意識しているお陰です。
なのでコミットを小さくしたお陰という訳ではないのですが、コミットと作業の意味がより明確に紐づく事によって自分の作業の整理がしやすくなりました。
どちらも早くから取り組む程、効果が大きいと思います。
本当、もっと早く実践出来ていればと思うばかりですね。。。笑
コミットを自然と小さくする方法
たとえ知識として「〇〇した方が良い」と知っても、実際に実践に移すことは難しいと思います。
そこで最初の一歩として取り入れてみて欲しいことは
「Gitのコミットにプレフィックスをつける」
ということです。
プレフィックスをコミットする時につけるだけで、自然とコミットが小さくなっていきます。 僕の場合は好きなフレームワークのangularのコミット規約を採用していて、このプレフィックス達をコミットする時につけています。
| プレフィックス | 意味 |
|---|---|
| build | ビルドシステムや外部依存関係に影響を与える変更 |
| ci | CIの設定ファイルやスクリプトへの変更 |
| docs | ドキュメントのみの変更 |
| feat | 新機能 |
| fix | バグフィックス |
| perf | パフォーマンス向上のためのコード変更 |
| refactor | バグ修正も機能追加もしないコード変更 |
| test | 不足しているテストの追加や既存のテストの修正 |
引用元 angular/CONTRIBUTING.md at master · angular/angular · GitHub
極端な例えですが、1つのコミットにまとめていた差分にプレフィックスをつけるとfeatとdocsのコミットに分割する必要が出てきたりします。
これは自然とコミットを分割する基準が出来るということです。
この「自然と」コミットの分割が強制される点が凄くオススメしたい理由です。
プレフィックスをつける内にコードの修正とREADMEの更新で分割したり、バグフィックスと機能追加が別コミットに分けなければいなくなり、そうしている内に自然と小さくコミットする様になっていくと思います。
コミット分割の最初の一歩・基準として凄く良いと思うので是非取り入れてみてください。
まとめ、あとがき
まとめると以下の通りとなります。
- コメントにプレフィックスをつける
- 自然とコミットが分かれる様になる
- コミットが小さいと見直しがしやすくなりミスが減る
こんな感じですね。
ケアレスミスを改善しようと取り組む中で上で述べたような小コミットと見直しの取り組みに行き着きました。
正直、現在進行形で取組中・改善中なのですが、もう少し早めに気づけていればと思うばかりです。
だからこそ、少しでも誰かの為になればと思ってこの機会に記事にしてみました。何か参考になれば幸いだと思います。
読んでいただいた方々、ありがとうございました。
