githubで間違えてAWSのシークレットキーを公開したらAWSからお叱りのメールが来たので対処法をメモに残しておく
AWSからのメールには対処法の一つとして以下のように書かれていた。
ROTATE THE KEY
If your application uses the access key, you need to replace the exposed key with a new one. To do this, first create a second key (at that point both keys will be active) and modify your application to use the new key.
Then disable (but do not delete) the first key. If there are any problems with your application, you can make the first key active again. When your application is fully functional with the first key inactive, please delete the first key.
GOOGLE 翻訳すると
キーを回転
アプリケーションでアクセスキーを使用する場合は、公開されたキーを新しいキーに置き換える必要があります。これを行うには、最初に2番目のキーを作成し（その時点で両方のキーがアクティブになります）、新しいキーを使用するようにアプリケーションを変更します。
次に、最初のキーを無効にします（ただし、削除はしません）。アプリケーションに問題がある場合は、最初のキーを再度アクティブにすることができます。アプリケーションが最初のキーを非アクティブにして完全に機能している場合は、最初のキーを削除してください。
私の場合はアプリでキーを使っていたのでこれを実行した。
1.AWSのルートアカウントでサインイン
2.右上にある自分のアカウント名（？）が表示されたプルダウンメニューを展開し、一番下の「マイセキュリティ資格情報」を選択
3.左側のメニューで「アクセス管理」>「ユーザー」を選択。
4.自分のユーザー名が表示されるので選択。
5.「認証情報」 タブを選択。発行されてるアクセスキーとステータス（有効or無効）が表示されているのを確認。「アクセスキーの作成」ボタンで新しいアクセスキーを作成する。
なおこの機会にのみ、シークレットキーの表示とCSVファイルダウンロードができるのでダウンロードは必ずしておくこと。
6.新しいアクセスキーの情報をアプリの設定ファイルに書き込む（自分の場合はDjangoだったのでそのプロジェクトのsettings.pyへ。）そして反映させる。
7.旧いアクセスキーを無効化する
めでたしめでたし。
もういちどこんな事態に陥ったときのために（陥っちゃダメなんだけど、）備忘録として書き殴りました。
Django備忘録 : 新規プロジェクトの立ち上げ方法
mkdirで任意のディレクトリ を作成
$ mkdir myDjangodir
できたディレクトリに移動
$ cd myDjangodir
できたディレクトリ用に仮想環境を作成
$ python3 -m venv my_venv
(my_venvの部分は任意の名前)
※lsコマンド打てば、myDjangodir ディレクトリ内にmy_venvディレクトリ ができていることが確認できるはず。
仮想環境内にDjangoをインストール
まずは仮想環境の中に入る
$ python3 -m venv my_venv/bin/activate
$ の前に(my_venv)と表示されるようになるはず。
この状態でDjangoをインストールする。
インストールする前に、pip(パッケージ管理システム)を最新のものにアップグレードする。
(my_venv) $ pip install --upgrade pip
このpipを用いてDjangoをインストールする。
(my_venv) $ pip install Django
バージョン指定してインストールしたい場合「==」で指定してインストールできる。
(my_venv) $ pip install Django==2.2.5
これで開発環境は整った。
仮想環境から抜け出たい場合はdeactiveコマンドを使う。
$ deactive
（my_venv）がプロンプトから消えていればOK
新規プロジェクトの立ち上げ
思えばこれが本題
本記事冒頭手順で作成したディレクトリに入る
$ cd myDjangodir
仮想環境をアクティブに。
$ source my_venv/bin/activate
(my_venv)$
プロジェクトを作成
(my_venv) $ django-admin startproject myproject
↑これで「myproject」というプロジェクトが作成された。この中に一つまたは複数のアプリケーションを作成してゆく。
おしまい
Flutter 入門備忘録：新規プロジェクトの立ち上げ手順（VSCODEとXcodeで）
＊基本的なインストールやセットアップは終わってる前提。
毎回チュートリアルみてたら大変なので備忘録としてまとめとく。
１ VSCODEで、表示＞コマンドパレット＞Flutter:New Projectを選択
２ プロジェクトを置くディレクトリを選択もしくは新規作成。
３ ターミナルで新プロジェクトを配置したディレクトリ へ移動
4 open ios/Runner.xcworkspace とコマンド打つ。xcodeのワークスペースが立ち上がる。
５ ワークスペースの左のパネルから「Runner」をクリック。
６「Signing & Capabilities」>Teamプルダウンメニューから「自分の名前（Personal Team）」を選択
7 VSCODEでプロジェクトのディレクトリ 開いてlib/main.dart選択し、がりがりコードを書く。
８ command+S で保存してからF5を押す。シミュレーター起動して結果を確認できるはず。
Flutter入門者の備忘録 ：Stateful widgetとStateless widgetについて
少し前にDjangoのアプリをどうにかこうにかひとまず完成させて、今は前から興味があったFlutterの勉強をしています。
まずは公式のチュートリアル https://flutter.dev/docs/get-started/codelab
に手をつけているところ。
で、また未来の自分用に雑な備忘録を残しておこうと思います。
Widgetとはなんぞや？
Widgetとは、
Flutterアプリの「見た目に関わる部分」を構成する部品（パーツ）なんだそうです。
Flutterにおいて、このWidgetというものがとにかく基本として押さえなければいけないものなんだとか。
「In Flutter, almost everything is a widget」（By公式）
で、
Widgetには2種類ある
らしい。
1 ,Stateless widget
2,Stateful widget
1....Stateless widgetについて
「Stateless widgets are immutable」 、つまり、statelessなwidgetの値は変えることができない。
2....Stateful widgetについて
対してStateful widgetsについては、値は変わるかもしれない。
そして、
これを実行するにあたっては少なくとも二つのclassが必須、なんだそうです。
1...StatefulWidget クラス
と、そのStatefulWidgetクラスが作り出す、
2...State クラスのインスタンス
この二つ。
結び
まだ全然理解が浅いので、何か分かり次第追記します。
FATAL: too many connections for role ..."に対して、自分がとった対策（Django/Heroku）
Djangoで作ったアプリをHerokuにデプロイして動作確認などしていた。しばらくそれを続けていたところ、あるページでInternal Sever error が表示されてしまい、「なんだ？」と思いリロードしてみるときちんと表示されたり、あるいはエラーのままだったり。
こんなん恥ずかしくて他人様に見せられん！
ということで解決策を探っておりましたのでその辺りを記事に残しておこうと思う。
ターミナルで
$ heroku logs
を打つ。
これでどんなエラーメッセージが出ているか確認。
そうするとでていたのがこれ↓
FATAL: too many connections for role "..."
ぐぐったところ、
$ heroku pg:killall
をすればよいとか書いてあったので実行したが、アプリをいじってまたしばらくすると同じerror画面に。
ムキー
気を取り直して別の解決策を探る。
そして発見したのが以下の記事
stackoverflow.com
この記事の質問に対する返答で、こういった文言があった
「Seems like the connections are not being reused and/or a new thread is being created for each request.」
超訳すると
・コネクションが再利用されていないっぽい。
・新しいスレッド（すれっどってなに？）がリクエストの度に作られている。
とのこと。なるほど〜。
そして意気揚々と、その回答者が示してくれた解決策を実行してみたのだが、残念ながらまた同じ現象は起こってしまった。
そして再びGoogleの旅に出るわたくし。
そして次に出会った↓の記事で、どうやら解決したっぽい。
これによると、herokuの「pgbouncer」なるものを導入することで解決したらしい。
なんじゃそれとおもいググってみると、
devcenter.heroku.com
コネクションをリミット（制限）してくれるものらしい。おおおおおこれの予感！
早速試してみよう！
ターミナルで次のコマンドを実行
$ heroku buildpacks:add https://github.com/heroku/heroku-buildpack-pgbouncer
これで
$ heroku open
してみると。
今度はしょっぱなからServer Error!!
しかし、これは想定内。なぜなら上の記事でこのやり方を書いてくれた方が予め、「このコマンド実行すると最初はこんなエラーメッセージが出るよ！」
と教えてくれていたから。
そのエラーメッセージとはちなみにこんなやつ↓
heroku server does not support SSL, but SSL was required
で、じゃあこれをどのように解決するかといえば、↓のページに書いてある。
該当部分を超訳すると、
「私はデータベースの設定に自動的に加えられる”sslmode: required”を取り除く必要があったのだ。
それは
（settings.pyで）
django_heroku.settings(locals())
と書かれている場所の後に、
del DATABASES['default']['OPTIONS']['sslmode']
を書き加えることによって可能になる
」
とのこと（適当訳だから細かいこと言わない！）
これをやってから、
git add -A .
して、
git commit -m " コメント"
して、
git push heroku master
して、
heroku open
でアプリをブラウザに表示。
GETリクエストを大量に出すべくひたすらページ遷移などしまくってみているが、今のところ５００エラーは起きていない。
このまま順調でいてくれ！！！
ではさよなら。
完全自分用備忘録：Djangoで作ったチャットアプリをheroku上で動作させるために必要な知識の整理
ローカルでちゃんと動くチャット機能をheroku 上で試したところ、
Error during WebSocket handshake: Unexpected response code: 404
が吐き出される。
エラー文をコピペしてググってみても違う言語、JAVAとかRubyとかばかりヒットして、しかもそれぞれ原因がバラバラっぽくて「ここを直せば動くっぽいな」っていうのが全然見えてこない（ぐぐり力が足りないのかもしれない）
そもそもこのチャット機能、プロトコルもHTTPじゃないし、
知らない用語・考え方・技術がたくさん登場して、
訳わからないながらどうにか実装したと言う感じで
しばらく経ってみたらもうすっかり用語とか仕組みとか忘れ去っているので、ググってもちっとも理解が進まない。
と言うわけで、完全自分用に、今回調べたこと・分かったこと・自分の思考の履歴などをこの記事に記録してゆくことにする。細切れに更新を繰り返します。
用語
ASGIとは？
非同期通信が可能なWSGI
そもそもWSGIってなんだっけ？
Web Server Gateway Interface は、プログラミング言語Pythonにおいて、WebサーバとWebアプリケーションを接続するための、標準化されたインタフェース定義である。（wikipedia）
PythonはWebアプリ/Webサービスを作るときのプログラミング言語です。PHPと同様にZope、Twisted、Django、TurboGears等複数のフレームワークが存在します。
ただ、使用するフレームワークによって、利用可能なサーバーが制限されてしまったり、逆にサーバーによって利用可能なWebアプリケーションフレームワークが制限されることがあります。
WSGI（Web Server Gateway Interface）とは、サーバーとWebアプリケーションをつなぐ共通のインターフェースをPythonで定義したものです。
インターフェースというと難しく思えますが、要するにWSGIはクッションです。
例えば、JavaはサーバーとWebアプリケーションをつなぐ際にJava Servelet APIを使います。すると、フレームワークを気にせずに動作させることが可能です。
つまり、WSGIはJavaにおけるJava Servelet APIです。WebサーバーとWebアプリケーション間のインターフェースを定義しています。WSGIを利用することで、WebサーバーとWebアプリケーションフレームワークの組み合わせを柔軟に選択することができます。
WSGIとは？PythonとWebアプリケーション | Hornet|静岡拠点のWeb、ホームページ制作
なるほど。
サーバー内で発生する、webサーバーとフレームワーク（Django）とのやりとりを仲介する、橋渡し的な役割を果たすと言うことはわかった。
ちなみに読み方は「ウィズギー」らしい。
WSGIの動作には2種類のWSGIが必要になります。1つはWebサーバー側、そしてもう一つはWebアプリケーションフレーム側に必要です。双方のWSGIが汎用的なインターフェースでリクエスト情報・レスポンスヘッダ・レスポンス本文等をやりとりすることによって稼働します。
この仕組みのおかげでWSGIに対応したWebサーバーと、WSGIをサポートするアプリケーションフレームワークであれば組み合わせることが可能になります。
Daphneとは？
Daphne is a pure-Python ASGI server for UNIX
channel_layersってなんだっけ？
Channel layers allow you to talk between different instances of an application. They’re a useful part of making a distributed realtime application
チャネルレイヤーを設定すると違う端末同士でリアルタイムに対話ができるようになるよ、程度の意味合いかな。
Redisを使用。
herokuのdynoってなんだっけ？
herokuでは、プロセスの処理はdynoによって行われます。
プロセスの処理とはHTTPのリクエストやレスポンス、バックグラウンド処理などです。
dynoは3種類あり、処理をするプロセスの種類によって使い分けられます。
web dyno
worker dyno
one-off dyno
で、結局404エラーの原因てなんなの？
さぁ？わかったら追記します。
