t_wの輪郭

リリース作業ですげー疲れた。実労1時間だが、これだけでヘボヘボのヘボン式となった。ヘボン式がへぼいと言いたいわけではない。疲れていると余計なものが出てくる。

「Amplifyと繋がってるGitホスティングサービスの変更（Amplifyのバグのせいですげーテクいし本番環境を一回吹っ飛ばして立て直す）」と「DBのテーブルの多対多への変更に伴うデータ変換」が重なってめちゃ気を使う作業群となってしまった。今思うとそんなもん重ねるなとなる。

でも、これ以降は他のメンバーが開発に参加できるので、開発が加速するはずだ。社内標準のGitホスティングサービスに移行できたし、データ構造が固まったのでフロントエンドの開発を並列化して進められる。

https://rinkaku.towasys.com/
まだhttpsには対応していないため、httpとなっている。早いうちにhttpsに対応させたい。
→ 2022年4月29日：httpsに対応させた。

ともあれ、これでAmazonアソシエイトの承認を受けられるはずだ。
Google AdSenseを張ることだってできる。

2022年8月7日

朝からElevated accessの申請をした。

うおおおおTwitter APIでTwitterに自動投稿できるようになった！！！
やっと更新通知（と呼んでたけど記事が一定数閲覧されたらTwitter APIでTwitterに投稿）する機能を実装できるぞ！！！

記事が一定数閲覧されたらTwitter APIでTwitterに投稿する機能を実装した。

リリースした。

トークンとかの格納に.envを使っているのだけれど、これがrsyncすれば開発環境から本番環境に反映されると思っていて、本番環境でエラーを起こしていた。

2022年8月6日

Twitterへの自動投稿はめんどくさかった
ブログ更新したらTwitter APIで自動投稿したいとか考えてたけど、思ってた100倍ぐらいめんどいことが分かった

めんどくさい理由：

• 投稿に使うtokenが有効なのは2時間だけ
• refresh_tokenを使えばtokenの再取得ができるが、その際にrefresh_tokenも新しいものが払い出され、古いrefresh_tokenは利用できなくなる
• 故に、DBにrefresh_tokenを入れておく必要があり、さらに常に有効であるかに気を配る必要がある
• refresh_tokenが無効化した場合には、DBを触ってrefresh_tokenの入れ直しが必要

OAuth2.0だとめんどくさいらしく、OAuth1.0aを使った方が良いとSNSで情報をいただいた。ただ、OAuth1.0aの投稿APIはElevated accessが必要とのこと。

twitterAPIはoauth1.0aで使うのがオヌヌメ

oauth2.0はリフレッシュトークンの管理がめんどい

OAuth1.0が一生うまくいかん。
ブログ更新ツイートぐらいだったら手動でやればいいやという気持ちになってきたけど、それはそれとしてOAuth1.0に負けるわけにはいかない。

あきらめてライブラリ使ってもいいですか。

力尽きた。

丸一日OAuthに捧げたけど成果物は何もないし、いまだにAOuthって書きそうになる

さて、来週の月曜日もリリースが待ってる。火水木と開発、金に品証、月にリリースだ。

今週中に今月の必達目標をこなしたい。

再来週は祝日なので今進捗を稼ぎたい。