2021年初頭に SKK を Windows/Mac で Google 日本語入力からの候補取得といっしょに絵文字まで変換して使うための方法

前提・したいこと

いろいろしたいこと盛り沢山。

動作させる環境としては

  • Windows10 の WSL2 で動作させたい
  • WSL2 と VcXsrv で動かしている Emacs の ddskk からも (できるだけ) 利用したい
  • でも Mac でもできるだけ同じように環境を用意したい

そして動作自体には

  • 辞書に無い未知語は候補を Google 日本語入力 (Google Japanese Input) の API から取得したい
  • 辞書に有る語の場合は辞書から候補を取得して可能な限り高速に変換したい
  • 絵文字も入力したい

とぜいたくな感じ。2021 年、令和三年ですからね。

作業内容・手順

SKK のインストール

Windows10 では動作も軽快で安定感抜群な CorvusSKK を利用させていただいてます。

github.com

リリースから最新のインストーラーをダウンロードしてきてインストールすればふつうに完了。

Mac では AquaSKK (aquaskk?) を利用させていただいてます。

github.com

こちらもリリースから最新のインストーラーをダウンロードしてきてインストールすればふつうに完了。

yaskkserv2 のインストール

ここでは yaskkserv ではなく yaskkserv2 を使います。Rust で作られている yaskkserv2 なら比較的簡単に環境差異を気にせずに SKK 辞書サーバ (skkserv) が用意できるためです。(あと個人的に Rust に興味があったからというのも大きい)

github.com

README.md のとおり (2021/01/06時点) に作業をします。

ソースの取得

今後の更新で再ビルドしたいので git で clone します。WSL2 の環境に git が無いときは ZIP でダウンロードしても良いでしょう。(git はインストールしておくことをオススメしますが……)

cd ~/git/
git clone https://github.com/wachikun/yaskkserv2.git

私はホームディレクトリに git ディレクトリを用意してそこにソース類を置いているので、cd してから clone しています。

Rust 用意

(すでに Rust が使える環境の方は飛ばしてください)

まったく Rust の環境用意が無い場合は、 Homebrew on Linux を使ってインストールするのが手っ取り早いかもしれません。

docs.brew.sh

brew のインストールは上記のリンク先のとおりです。
脱線な上に長くなるので省略してしまいますが、私は fish を使っているので PATH を通すための環境変数設定あたりに違いがありました。対処方法は「homebrew fish」等ですぐ出てきます。

ビルド

ここは yaskkserv2 の README.md のとおりです。

cd (yaskkserv2 を clone したディレクトリ)
 cargo build --release

成功するとtarget/release の下に yaskkserv2 本体と辞書変換用の yaskkserv2_make_dictionary が作られます。

実行できるところに配置する

ビルドしてできた yaskkserv2 本体と辞書変換用の yaskkserv2_make_dictionary を実行しやすいように PATH のとおったところに配置します。

私は自分でソースからビルドしたものを ~/bin に置くことにしているので以下のコマンドでコピーして配置しました。

cp -av target/release/yaskkserv2 ~/bin/
$ cp -av target/release/yaskkserv2_make_dictionary ~/bin/

/usr/local/bin とかでも良いんじゃないかなと思います。

辞書用意・変換と yaskkserv2 の起動

yaskkserv2 は SKK 辞書の変換を必要とするので、変換元辞書の用意と変換をしてから yaskkserv2 を起動してみます。

SKK 辞書の用意

公開されている SKK 辞書をダウンロードしてきて集めても良いでしょうし、WSL2 で Ubuntu を使っているなら apt で yaskkserv (yaskkserv2 ではなく yaskkserv) をインストールすると /usr/share/skk の下にだいたいの種類の辞書ファイルが置かれるので、それを利用すると手っ取り早く進められます。以下を clone するのも便利です。

github.com

cd ~/git/
git clone https://github.com/skk-dev/dict.git

また、速く変換したいので Google 日本語入力の API に頼らず辞書ファイルから候補の語が取得できるように以下も利用させてもらいます。

github.com

cd ~/git/
git clone https://github.com/tokuhirom/skk-jisyo-neologd.git

辞書の用意ができたら yaskkserv2_make_dictionary を使って辞書を変換します。以下は上記の skk-dev の dict と SKK-JISYO.neologd を利用する想定です。
なお、絵文字の対応は skkserv ではなくCorvusSKK または AquaSKK でおこなうため、自分は utf8 ではなく eucjp のまま変換しています。

cd ~/git/dict
yaskkserv2_make_dictionary --dictionary-filename=/tmp/dictionary.yaskkserv2 SKK-JISYO.* ../skk-jisyo-neologd/SKK-JISYO.neologd

辞書表記の影響で SKK-JISYO.neologd のいくつかの語で警告が出ますが、わずかであったので無視して進めました。(気になる方は変更して変換成功するようにしてみてください。そしてその内容を書いていただけますと……)

yaskkserv2 の起動

辞書の変換までできたので、yaskkserv2 を起動します。
変換した辞書は、変換時のコマンドに渡した --dictionary-filename オプションのパスにある /tmp/dictionary.yaskkserv2 にできています。よって起動時にもこれを使います。

yaskkserv2 --no-daemonize --google-japanese-input=notfound --google-suggest --google-cache-filename=/tmp/yaskkserv2.cache /tmp/dictionary.yaskkserv2

オプションについての詳細は yaskkserv2 の README.md を見ていただくのがいちばんですが、使ったものは以下のとおりです。

  • 使いはじめは Google 日本語入力から候補をもらう処理をいろいろ試してみたかったので、--no-daemonize をつけてバックグラウンドで動作しないようにしています。
  • --google-japanese-input=notfound とすることで、Google 日本語入力からは辞書に候補が無かった場合にだけ候補を取得します。
  • --google-suggest をつけて有効化しています。
  • Google 日本語入力から取得した候補はキャッシュして何度も問い合わせしないように --google-cache-filename=/tmp/yaskkserv2.cache をつけています
  • さいごに変換した辞書の場所 /tmp/dictionary.yaskkserv2 を指定しています。

特に README.md にもあるとおりで、Google 日本語入力からの候補取得はどうしても変換ラグが発生してしまいます。 notfound オプションでできるだけ軽減させています。
また、起動ポートは指定していないので 1178 で起動していますが、AquaSKK の内蔵 skkserv を使っていたり他に skkserv が動いているのであれば

yaskkserv2 --no-daemonize  --port 1179 --google-japanese-input=notfound --google-suggest --google-cache-filename=/tmp/yaskkserv2.cache /tmp/dictionary.yaskkserv2

--port 1179 のようにポート番号を指定するオプションでポート番号を変更すれば OK です。
あとは CorvusSKK または AquaSKK で yaskkserv2 を skkserv として追加してやると利用できます。最近の WSL2 であれば、Windows 側から WSL2 への通信に localhost が利用できるので、skkserv は localhost:1178 で接続可能になっています。便利になったものです。。

また、ここまでで ddskk から yaskkserv2 に接続して変換することができるようになっています。

絵文字変換の用意と設定

絵文字も変換できるように辞書を用意します。絵文字辞書を用意してくださっている方がいらっしゃるので、以下を clone するか必要な辞書ファイルをダウンロードします。

github.com

github.com

uasi/skk-emoji-jisyo の README にもあるように、CorvusSKK または AquaSKK に直接辞書として登録します。

絵文字辞書は utf8 であり eucjp な SKK と異なるのですが、このあたりあまりいろいろすると後から混乱しそうなため

  • yaskkserv2 は ecujp の辞書と eucjp で動作させる
  • 絵文字用の utf8 の辞書は CorvusSKK または AquaSKK に直接辞書として登録する

と分けてみています。
skk-dev/dict にも絵文字辞書があるのですが、以前からこの手順と分け方で設定していたのでそのままにしています。Emacs の ddskk でも絵文字変換を使わないので、yaskkserv2 に絵文字辞書を入れたくないという背景もあります。
もしこの手順無しでもうまく絵文字変換できたよ!という方いらっしゃいましたら教えていただけますと……

お試し

以上で CorvusSKK または AquaSKK では以下の挙動が確認できるはずです。

  • 「▽へんかん」(変換)など辞書にありそうな語を変換する → 高速に変換される = yaskkserv2 経由で辞書ファイルから変換されている
  • 「▽へんかんてすと」(変換test) など辞書にない語を変換する → 数ms〜1s 程度の時間をかけて変換される = yaskkserv2 経由で Google 日本語入力から候補取得して変換されている
  • 「▽だんぼーる」(📦) など絵文字を変換する → 絵文字が変換候補に存在する = utf8 の絵文字辞書が読み込まれて変換に使えている

Emacs の ddskk では絵文字辞書を使っていないので、最後の絵文字変換以外が動作するはずです。

おわりに

Google 日本語入力を使った候補取得をおこなう場合、SKK の設定によっては辞書ファイルに存在する語に変換する場合でも Google 日本語入力に問合せしてしまい若干のラグが発生してしまうことがあるのですが、以上の設定では可能な限りローカルの辞書から候補を取得して高速に変換ができるようになっているはずです。また、WIn10 でも Mac でも、また Emacs の ddskk でも同じように変換ができるようになっているはずです。

過去にも SKK をさまざまな環境で同じように利用する方法を試行錯誤してきましたが、多くの方の作成物を繋いで利用させていただくことで 2021 年には素晴しい SKK 環境が OS やアプリケーションにとらわれることなく実現できるようになっていることに感謝です!

……と、せっかく SKK の良い感じな環境を手に入れたので長文を書いてみたくて書いた記事です!

2020 年と 2021 年

びっくりするほど 2019 年の終わりについて覚えていない……。でも記事はあるから不思議。

nishikawasasaki.hatenablog.com

酔っぱらい過ぎていた?

2020 年

世の中としてはコロナなんだろうけど、個人的にはますますの山登りとカメラ (フルサイズ) につきる年。

ずっとマイクロフォーサーズを使っていたのに、2 月に突如 SIGMA の fp を買ってフルサイズデビューした。写真データの連番を見ると、10 ヶ月 7500 枚くらい撮影したらしい。山の写真が 9 割かな?写真が撮りたいから山へ行くし、山へ行くから写真が撮りたい。そんな 1 年だった気もする。オールドレンズ、特に六甲にちなんだ ROKKOR を 2 つ入手してよく使った。

また、春くらいの緊急事態宣言で 2 ヶ月くらい山に行かなかったことを考えると、2019 年よりよほど山に行ったなーという感じがする。

f:id:nishikawasasaki:20201231202851p:plain

去年の記事をあらためて読んでみると 1000 メートル超えの金剛山に言及しているけど、今年は 2000 メートル近い西日本最高峰の石鎚山に登頂することができた。同じく去年は雪山を「歩きたい」と書いているけど、石鎚山は雪山を登って登頂できてる。百名山にも 4 座、剣山、大台ケ原、大山、石鎚山に登ることができた。テント泊もしたし、ステップアップしてるな〜。来年も楽しみ!

2 月のコロナ前最後というタイミングで研修に行って試験を受けて認定スクラムマスター (CSM) になったのもいつもと違うことかな。数年来、自分で考えたり見聞きしたことから判断してやってきたことの答え合わせになった。これだけで食べていけるような甘い世の中じゃないと思っているのでだからなにってことも無いのだけれど、「次は今よりうまくやる」をモットーにしている自分にとって大きなきっかけだったなとは思えるものだったと思う。あと 2019 年にしなかった登壇を誘ってもらってしたのも良かった。

nishikawasasaki.hatenablog.com

なんか追い込まれるかぎりぎりにならないと動かない性質なので、こういう機会はありがたや。

2020 年は世界的に世の中とんでもない年だったのだろう。個人としても、こんなにもそれまでしたことがないことをやった年もなかったし、もっとたくさんしたいことがあるなとさらに思えた年もなかった気がする。ひとつ大きな変わり目なんだなと振り返る年になったかな。

2021 年

2021 年って書くたびに超未来感すごい。去年の記事にも仕事では新しいことしたいと書いていたけど、これはなにも進められなかった。ただまあ、もうそろそろ良いかなーという感じが隠さないほど出ているし変化の年になりそうな気がしてる。
山は今年行けなかった北アルプスのような 3000 メートル峰にも行ってみたいなー。雪中テント泊はまだ遠いかもしれないけど、冬の山でももっと遊びたい。やりたいことはたくさんあるなー。

J Lang Fest Kansai Online #1 で登壇してきた

久しぶりに外の勉強会ではなしてきた。

kansai-jvm-langs-fest.connpass.com

毎年 1 回は機会を作ろうと思っていたのに、2019 年は社外で登壇しなかったので久しぶりになってしまった。。

Scala の好きなところ」をテーマにもらっていたので、大好き(?)な Akka をメインにしてみた。
コーディングとかたくさんある機能、簡単に実現できる並列・分散処理、リアクティブなどなど、Akka の良いところはたくさんある。その中でも特に推しておきたい処理を部品として分解することによる事業へのメリットを扱ってみてる。実は「それは Akka じゃなくても良いんじゃない?」という声があるだろうなーとは思ってる。ほんとそのとおり。でも同じように実現できる言語やフレームワークの中でも、その自由さであったり容易さがピカイチなのは Akka だと思ってる……。定量的に比較してなくて超定性しかも個人の。
そんなだから、もし「おいおいおいおいーこれも超いいんだけど!?忘れてない!?!?!?」みたいなのがあればぜひ教えてもらって知りたい!というモチベーションでも登壇したのでした……。

資料はこちら

speakerdeck.com

質問でもらっていた背圧制御については Actor ではなく Streams の方で実装されているのは訂正しておきます。
あとあんまりデメリット側のはなしができてなかったのだけれど、アクターやメッセージボックスの数の最適化や、割り当てるスレッドプールの数などアクターモデルにはアクターモデルのチューニングポイントというか難しさがある。これはどんな道具でもそういうところがあるので、道具にあわせて学んでうまく付き合っていきたいところ。

そういえば「良い道具は使い手を良く育てる」みたいなことを途中言いたかったんだけれど、なにかの格言なのかネットの言葉なのかネタ元が見つからなかったので見送った……。良い道具はそれ自体に作り手の思想やプラクティスが染み込んでいるので、ある程度はその道具の導くとおりに振る舞うことで良いおこないとなるみたいな云々カンヌン……。

ぜんぜん内容には関係ないけれど、タイトルや途中のスライドに出てくる山は
剣山(から見た次郎笈)→(次郎笈から見た)剣山 → 大膳原キャンプ場 → 大山から見た日本海 → 大山
の順番。この夏の山々。もっと山登りいきたいなー。

他の方の登壇内容もすごく興味深いのに、登壇が後の方だったので自分のことにいっぱいでちゃんと見聞きできていない。。また見ときます。

運営の方、素敵な機会をありがとうございました〜。良い経験になりましたー。

Windows Terminal 1.3 で変わったタブ切り替えの挙動をもどす

Windows Terminal が 1.3 になったころから Ctrl + Tab と Ctrl + Shift + Tab での次のタブ・前のタブのタブ切り替え挙動が変更となった。

Release Windows Terminal Preview v1.3.2382.0 · microsoft/terminal

We're trying out a new tab switching experience! (#6732), followups: (#7263) (#7280) (#7321) The nextTab and prevTab bindings will now display an ephemeral UI that can be navigated with the mouse or keyboard

↓ こんなかんじ

1.3からのタブ切り替え
1.3からのタブ切り替え

いろいろ変わっていくこと試してみることはとても良いことなんだけれど、自分にはあんまり合わなかった。。
というのもシェルの名前といまいるディレクトリを表示されても、そこでなにしてたか覚えてない。なんなら複数同じディレクトリを別タブで開いておいて Scala の sbt の対話型コンソールで作業しつつ別タブではコマンド実行してたりするので、同じ名前の同じディレクトリがいくつも並んでしまう。こういう使い方してると合わないのかも。

たくさん開いたタブを検索する機能も入ってるので、それとの挙動の共通感を出したかったのかも?

ということで元に戻した。
方法は同じリリースノートに書いてあった。

If you would like to fall back to the original tab-switching UI (or lack thereof), set new useTabSwitcher (global, boolean, default true) to false.

  "useTabSwitcher": false,

これを keybindings とか copyOnSelect とかと同じ階層に追加する。

戻った。しっくりきた。

We'd love feedback on why the new tab switcher didn't work for you!

ということなので、またフィードバックしだいでは変更あるかもしれないけどひとまずはこれで……。

RAW現像に手を出しています

いままでカメラと写真を撮るのは好きできたけれど、どうにも RAW 現像というのはやってこなかった。

f:id:nishikawasasaki:20200615120203j:image

というのも、撮って出し(と呼ばれているらしい)撮影したときのカメラでの見た目そのままの JPEG で残しておくのが楽だったし、あとから見た目を変えてしまうことになんとなく抵抗感があったからかもしれない。別に写っているものに手を加えて変えてしまうわけでもないので、「撮ってそのまま」みたいなことに勝手な鮮度みたいなものを感じているのかも。

f:id:nishikawasasaki:20200615120140j:image

カメラを SIGMA fp にしてからというもの、プロダクトの魅力か魔力かカメラをとにかく触りたくなる。そこでメニューで見つけたのが「現像」機能だった。機能があるからには使いたい。でもいつ使うんだろう?

f:id:nishikawasasaki:20200615120249j:image

カラーモードは、SIGMA の売りでもある「T&O」か「風景」を好きでよく使うのだけれど、山で緑がきれいな写真を撮ったつもりが「T&O」になっていて元気のない枯れた絵になっていることがあった。うーんなんだか記憶の色でもないし、見せたい色でもない。ああそうか、こういうときに RAW(fp では DNG)で撮っておけば後から自分が見ていた景色を再現できるのかと、ようやく気がついたのでした。

f:id:nishikawasasaki:20200615120402j:image

修正をしているのではなくて、自分の見ていたものを再現する。そう考えると、変な抵抗感は無くなっていました。

f:id:nishikawasasaki:20200615120315j:image

スマートフォンにカメラを繋いで写真を取り込めば、その場でアプリを使って現像できる手軽さも良くて、これはなかなか楽しいことになりそうだなー。

2ヶ月ぶりの山登り

先週の日曜日に約 2 ヶ月ぶりの山登りに行った。
こんなご時世なので山行中もできる限りマスク。
すれ違うときのあいさつもあいさつも控えめか黙礼に。
変に声を張り上げてこれみよがしなのよりも、
「わかってますよ」とスッと会釈してすれ違うのもなかなか粋。

↓ は YAMAP さんがブログへの埋め込みに対応したそうなので

切り取られてしまっているので元の写真もいっしょに

f:id:nishikawasasaki:20200607123233j:plain
睡蓮

写真アップ用のサイト(Tumblr)を用意した

ここでやっても良かったんだけれど、
貼り付けての見やすさとかまとめなことを考えて
いつからぶりかの Tumblr を開始した。

https://nishisasa-photo.tumblr.com/post/617349801143566336
nishisasa-photo.tumblr.com

飽きるまではちょこちょこアップしていこう📷

はてなブログTumblr へアップした写真を表示する、
ブログパーツとかウィジェット探したけど
すぐに見つからなかったのでまたいつか。

デスクトップ(物理)を整えた

4月から基本的にテレワークな状態になったので、自分はあまりつかっていなかった机の上をカッコいい感じにしたいと思い始めていました。
そこでよく見ていたのが ↓

note.com

配置や配線は当たり前に、天板のオーダーから塗装、はては線を塗ったりとただならぬこだわり!こういうこだわり大好きです。

しかしながらさて自分も、とはなかなか行かない領域。
いろいろ考えて少し手を入れてみました。

まずはモニタアーム。
つい先日、長年の夢だったモニタアームを購入したのですが、なんと使っている机の張り出した部分が短すぎてがっちり固定できない問題が判明。どうしたものかと思っていたのですが、妙案を思いつきました。
……妙案というか引き出しを犠牲にする案です。
机を 180 度回転させ、本来正面となる向きを壁側に向けるのです。そして引き出した引き出しの中でモニタアームを固定し、さらにケーブル類やコンセント、電源系を引き出しの中に全部しまってしまう作戦。
こんな感じになりました。

ケーブル類がまとまるとそれだけでスッキリ見えていい感じに(個人の感想です)

あとはブックスタンドに PC を載せて、HHKB など機器類をもとに戻せば完成。

地味にブックスタンドに角度をつけるためにボール紙を挟んでいて、HHKB のケンブルはこの隙間から通しています。

これ以上は Magic Trackpad 2 に買い替えたり、モニタをベゼルレスな 4K に買い替えたり(そして 4K 対応として PC のスペックを上げたくなったり)、机を DIY して超気に入るものに替えたりとどうやってもお金がかかりまくってしまうのでひとまずここまで……。
机の上にマットを敷くのはやりたいかも。

山道具がおいてあったり鳥谷のポスターがあったり(写ってないところにカープグッズも多数)懐かしの CD が並んでいたりと、なかなかの雑然とした空間ができあがりました。満足。

API Gateway の HTTP API と Lambda を開発用・本番用のバージョン違いで接続する

めずらしく AWS ネタ。
けっこうどうやるんだ?ってなったので自分用のメモ。
要は API Gateway のステージとステージ変数を使って Lambda ファンクションのエイリアスを呼び分ける話。
「動的統合」というやつらしく IAM ロールは自分で用意・指定する必要があったところが(自分には)肝でした。

Lambda 側の準備

本番用と開発用とは Lambda の「バージョン」と「エイリアス」で表現する。なにも設定を変更してない状態だとバージョンは $LATEST だけ存在している。これを本番用の prod と開発用の dev に分ける。
現在の $LATEST バージョンをひとまず仮に本番用とするためバージョンを発行(作成)する。
f:id:nishikawasasaki:20200326195247p:plain
まだ一度もバージョンを作成していないと、バージョン 1 が作られる。

次にエイリアスを作成する。
本番用は固定されたバージョンの 1 を利用して、開発用は常に最新の $LATEST を使うとした場合。
f:id:nishikawasasaki:20200326195509p:plain
開発用なので dev としたエイリアスを、バージョンは $LATEST を見るように作成する。
f:id:nishikawasasaki:20200326195610p:plain 同様に本番用として prod エイリアスをバージョン 1 を見るように作成する。

これで Lambda 側の準備は完了。

API Gateway 側の準備

用意した Lambda のエイリアスに対応する形で API Gatewaydev ステージを用意する。

f:id:nishikawasasaki:20200326195915p:plain

ステージの名前は自由に。
ステージ変数の名前として「キー」に好きなものをつける。ここでは LambdaAlias
ステージ変数の値には Lambda で作った開発用のエイリアスを同じ dev をつける。
(この「値」が API Gateway の呼び出す Lambda ファンクションのエイリアスとして使われることとなる。)

同じことをデフォルトのステージ $default でもおこない、「値」は prod にしておく。
(本番用にちゃんと区別したい場合はデフォルトのステージを使わず prod ステージを用意すると良いはず。)

あとは統合する Lambda ファンクションを arn で指定するときに、エイリアス:エイリアス名 までつけて指定すれば OK。
arn + :エイリアス名 とするとそのエイリアスで Lambda ファンクションを指定できるそう。
arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxxxx:function:hogehoge:${stageVariables.LambdaAlias} こんな雰囲気。
f:id:nishikawasasaki:20200326200440p:plain
「一致する Lambda 関数がありません」と出てくるけどちゃんと保存できます。

これで動くかなと思ったらそうではなくて、いまやっている「動的統合」の場合は「アクセス許可を呼び出す」のところを自動ではなく明示的に指定しないといけないそう。
自分はここから IAM 力の低さにつまづいてしまった……。
以下のページにもあるのだけれど、

動的統合を構築する場合、それに応じて権限を更新することも重要です。統合が単一のLambda関数を指す場合、HTTP APIは呼び出し権限を自動的に追加します。ただし、複数の関数を使用する場合は、ロールを手動で作成および管理する必要があります。これを行うには、Lambda関数オプションを呼び出すための[Grant API Gateway permission to invoke your Lambda function]をオフにし、適切な権限を持つカスタムロールを入力します。

高速、低コストで、より良いAPIの構築 – HTTP APIが利用可能(GA)になりました | Amazon Web Services ブログ

とのこと。
具体的にどんなロールを用意したらいいの?ってなったけど チュートリアル: 2 つの AWS のサービス統合と 1 つの Lambda 非プロキシ統合を使用して Calc REST API を作成する - Amazon API Gateway の内容に沿ってロール作成したものを使えばうまくいきました。

最終的にこういう状態に。

f:id:nishikawasasaki:20200326200903p:plain

試す

ここまできたら API Gateway に本番用と開発用の 2 つのステージで URL が得られているはず。

上が本番用で下が開発用。
あとは API Gateway のルートに作成したパスをつなげれば本番用・開発用の使い分けができる。

もし API 実行して Internal Server error が帰ってきており、Lambda の実行ログが Cloud Watch にも無いようなら、API Gateway から Lambda を呼び出せていないので IAM まわりを確認する。 そうでなく Lambda の中でこけているなら通常どおり Cloud Watch でログを見て修正する。

シネスコレイアウト写真の3段重ね

人がしてるのをみてシネマスコープ(風?)に切り抜いたり撮ったりしてる写真たち、Instagramにアップすると16:9くらいに横が切れるなーと思ってた。

そんなところにこれまで使ってなかったInstagramの「レイアウト」で、縦か横に3段重ねにするとちょうど収まることに気がついた!

こんな感じ。  

f:id:nishikawasasaki:20200220095845j:image

f:id:nishikawasasaki:20200220095848j:image

f:id:nishikawasasaki:20200220095852j:image

見やすいかというと……?だけどたまには奇をてらった感じで良いかも📸