脱職エントリー

いつか退職エントリーを書いて一人前のエンジニアを名乗りたい

PyCon JP 2017のブース出展の反省点

09/08〜09/09に早稲田大学西早稲田キャンパスで行われた「PyCon JP 2017」にスポンサーブースとして参加したので反省点を書いていこうと思います。

 

hololensを展示したことについての反省点

弊社が清水の舞台から飛び降りるつもりで買ってしまったhololens、こいつを使わない手はないとhololensありきでイベント準備を進めましたが・・・結果的にはpyconのような手狭で時間も短いイベントでは使うべきではないという話になります。

(※hololens自体は神がかりガジェットですが何事も用途があります)

 

1.ユーザーに操作をさせるのは大変 

正直言って始めてhololens掛ける人に操作説明するのはとても大変でした。
2日目からは3秒経ったらアクションを開始するように修正しました。

2.一回の体験に時間が掛かる

pyconの忙しいスケジュールを縫ってブースに訪れた人たちにhololens掛けてもらうのは貴重な時間を奪うことになります。

3.何をやってる会社か伝わらない

弊社はDjangoを中心としたwebの請負みたいな仕事をやっている会社なのですが、hololens+unityなんて展示物を出してしまったがために、何しにpyconに来てるのかよく分からない謎の会社になってしまったように思われてしまったのかも知れません。

一応、unityからDjango RestFrameworkで作ったレストフルなwebapiを呼んでるところがだったのですが、伝わりにくくなってしまいました。
ちなみに弊社は事業としてunityなどを扱ったことはありません。 

 

自社サービスもなく、基本なんでも作るのでお仕事くださいってスタンスなので見せられる製品がないコンプレックスの裏返しでみんなが驚くモノを作ろうと熱意が暴走した結果でもあります。

偶然弊社ブースにお越し頂いて偶然上手くいったMR体験出来た方はおめでとうございます。

うまく見えなかった方には申し訳ございません。きちんとした体験会に行けば素晴らしい体験ができます!弊社の力不足です。

 

 ブース出展よりもやるべき事があるのかも 

弊社はこんなことできますよ〜ってアピールするならやっぱり講演するLTするなどでプログラミングやインフラの知識をきちんとアピールすることが大事なのかも知れません。
本来はそれを見せるためにDjango製のアプリを出していましたが、 hololensという飛び道具に飛びついた結果失敗してしまったように感じます。

 

ブースにいると講演を聞き逃す

ブースにいて話込んでいるとつい時間を忘れて自分が聴こうと思っていた講演を聞き逃してしまいます(自分はそれで二つ聞き逃しました)

 

エンジニア兼ブース担当兼営業的な動きというフルスタックな動きには限界を感じました。

良いことも言っておかないと辛い

とりあえず、hololensだしてた変な会社ということで認知が頂ければ弊社としてはいいのかなぁと思ったり思わなかったり

後は反省点は多くとも結構な熱量をpyconに注ぐことができたので来年リトライする機会に恵まれたらもっとシンプルで驚きのある物を作りたいなぁと

 

0から1へ、というラブライブ!サンシャイン!!のテーマを旨に来年のpyconではもう少し色々自己顕示欲を形にできればなぁと思います。

pycon一週間前なので去年の反省点を残しておきたい

pycon一週間前ですね!
今年は弊社日本システム技研もスポンサーとして参加しております。
なんか色々やる予定ですので、是非無銭がっつきでお越しください!

 

自分は去年がpyconが初参加だったのですが、その時の反省点が多々あるので今年参加される方の参考になればと思い恥を忍んで色々書き出しておこうと思います。

1.ノートPCのバッテリーに注意

 普通に使っていると電源は一瞬で終わってしまいますので色々気をつけたほうが良いと思います。

 ・画面はぎりぎりまで暗くする←超大事
 ・chromeは使わない
 ・しかし、ツイートはやめない!!
 ・広い部屋の後ろの方は席は公演聞きながら充電できるよ!(一日目の後半などはみんな電源が少なくなってくるので取り合い必死か?)

2.懇親会で人間違い

 僕「○○の話をした人ですよね」
 その人「えっ違います」

 公演した人の顔と名前ぐらいちゃんと覚えておきましょう。
 自分で言うのもなんですが大変失礼な行為だと思っています。

 とはいうものの、人に話しかけないよりは良いのかなと思ってます。
 懇親会ぼっちで終わってしまうのはもったいないですよね。僕はぼっちで終わる人です。

3.有名人ぐらい覚えていこう

 僕「○○社の△△って方と名刺交換しました~」
 自社の先輩「おいその人って有名な△△さんやで!!」
 僕「まじっすか。しらんかったです」

 pythonコミュニティの人を全然知らなかったので、普通に接してしまいました。
 知っていれば会話ももっときっかけがあったのになぁと思ってしまいます。
 まぁでも有名人相手だと萎縮してしまうので無知はある意味強いのかもしれませんが有名人と話すときにあの本読みました~とかあのサービス使ってますとかあのプレゼン聞きました~とかきっかけが増えるので知ってた方がいいんだろうなと思いました。

4.あんまり他人に積極的になれなかった

f:id:darakunomiti:20170902141731p:plain

日本人って基本的にシャイだと言われていますがIT産業に従事する人はその傾向がより強いんじゃないかと思っています(僕はその中でもとりわけ強いです)

会話が始まるといいのですがきっかけが難しいですね。。だって誰だかわからないところに突然乱入していって、「僕長野の零細企業でDjangoでwebapi作ってます!アニメ見たり地下アイドル現場にかよってます!好きなアニメは大正野球娘。ラブライブ!サンシャイン!!です!」
なんて言っても「は?」って感じじゃないですか、どうやって会話に入るのか誰か教えください。多分、会話のきっかけになる要素が事前に分かってるといいんですよね。
はいえあれだけ人がいる中でFBのお友達やツイッターのお友達が全然増えないのはちょっともったいなかったなぁと、、絶対に接点さえあれば仲良く慣れる人はいるんじゃないかと思います。

まぁ僕自身友達づくりが苦手なフレンズってことは重々承知ですが・・

 

余談ですが声優さんのお渡し会のときはイベント関連作品のアニメに関するグッズなどを装着していればきっかけには困らないし相手の笑顔も見れるので成功体験になります。作品主体のお渡し会のときはおすすめ。

pyconの懇親会で話すのは声優さんでも地下アイドルちゃんでもありませんが)

5.去年聞いた話が全然活かされてない!

色々な話を聞いた気がしますが、実務に繋がったって話はなかったなぁと
まぁ、去年~今年はお仕事ではDjangoでwebapiを作っていただけだったので、活かすような話もなかったのですが、今年は講演を聞いてその中から一つだけでも手を動かして接してみようと思います。

6.PR

弊社日本システム技研のスポンサーブースが出ます!
※下記はイメージ画像です

f:id:darakunomiti:20170902140015j:plain

 

簡単なゲームや景品も用意していますので是非お立ち寄りください!

自分がいる時間には地下アイドルやアイドル声優事情や現代サブカルチャーの話題なんかを振っていただければ喜びます!

 

※こちらを恨めしそうに見つめているペッパーはこれません

DjangoRestFrameWork ネストしたフィールドにユニークキーが含まれる時、updateで一意制約違反

元ネタ stackoverflow.com

先に解決法だけ見たい人は

class MemberSerializer(serializers.ModelSerializer):
    """各メンバ-エリア"""

    class Meta:
        model = Member
        fields = ('id', 'name', 'birthday', 'coler')
     # ユニークキーの入力チェックを外す
        extra_kwargs = {
            'name': {'validators': []},
        }

やりたかったこと

例えば、アイドルの名前は、エゴサ、パブサで検知しやすいように、全作品でユニークになっていなければならないとします。
で、グループ名や結成時期とメンバーの情報をapi一本で更新したいとするじゃないですか。
そうするとシリアライザーは多分こんな感じ。

selializer.py

class MemberSerializer(serializers.ModelSerializer):
    """各メンバーエリア"""

    class Meta:
        model = Member
        fields = ('id', 'name', 'birthday', 'coler')


class UnderGroundIdleSerializer(serializers.ModelSerializer):
    """アイドルのグループ名"""

    members = MemberSerializer(many=True, source='members', required=False)

    class Meta:
        model = UnderGroudIdle
        fields = ('id', 'name', 'members')

View.py

class IdleViewSet(viewsets.ModelViewSet):

    pagination_class = PostPagination
    queryset = UnderGroundIdle.objects.all().prefetch_related('members')
    serializer_class = UnderGroundIdleSerializer
    parser_classes = (MultipartFormencodeParser, JSONParser,)

    @transaction.atomic
    def update(self, request, *args, **kwargs):
        """特に意味はないけど分かりやすく可視化"""
        responce = super().update(request, *args, **kwargs) ★ここが重要になってきます
        return responce

postする時のjsonはこんな感じ(他のメンバーごめんなさい)

{
    "name": "Aqours",
    "members": [
        {
            "birthday": "3-4", 
            "coler": "Yellow", 
            "name": "国木田花丸"
        }, 
        {
            "birthday": "4-17", 
            "coler": "Blue", 
            "name": "渡辺曜"
        }
    ]
}

なんですが、これをこのままputすると、一意制約違反エラーとなってしまいます。(国木田花丸渡辺曜がすでに存在するというエラー)

原因

Djangoの入力値のチェックで何故かinsert時と同じチェックをしている。。

responce = super().update(request, *args, **kwargs) ★ここから呼ばれるのが以下のクラス

class UpdateModelMixin(object):
    """
    Update a model instance.
    """
    def update(self, request, *args, **kwargs):
        partial = kwargs.pop('partial', False)
        instance = self.get_object()
        serializer = self.get_serializer(instance, data=request.data, partial=partial)
        serializer.is_valid(raise_exception=True) ★ここでエラーが起きる
        self.perform_update(serializer)

        if getattr(instance, '_prefetched_objects_cache', None):
            # If 'prefetch_related' has been applied to a queryset, we need to
            # forcibly invalidate the prefetch cache on the instance.
            instance._prefetched_objects_cache = {}

        return Response(serializer.data)

対策

リアライザーでチェック処理を外す指定ができる。

class MemberSerializer(serializers.ModelSerializer):
    """各メンバ-エリア"""

    class Meta:
        model = Member
        fields = ('id', 'name', 'birthday', 'coler')
   # この2行を追加
        extra_kwargs = {
            'name': {'validators': []},
        }

こうするとチェック処理が動かなくなるので自前でvalidateを書くなどの処理でupdateが出来るようにしました。
もちろんDjangoでチェックしなくてもデータベースから一意制約違反のエラーは出てくるので結果的には一意制約を保つことができます。(なんか嫌ですが)

ネストしたモデルシリアライザーって結局自前でupdateしなきゃ行けないのにチェック処理は全部クリエイト基準で行われるってなんか微妙な感じ。。

S3の静的webサイトで404時に別のドメインに飛ばす時

f:id:darakunomiti:20170809202339j:plain

問題は解決してませんが、ごまかし方だけメモ

やりたいこと

subdomain.domain.com で404エラーがでたら
domain.com/404 に遷移する
サブドメインドットコムはS3単独の静的webサイトで、クラウドフロント通したりはせずに、Route53でサブドメインを振っています。

やってみたことの一部

S3のリダイレクトルールをこんな感じで書いてみました。

<RoutingRules>
  <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>domain.com</HostName>
      <ReplaceKeyPrefixWith>404</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

が・・・

sudomain.domain.com/uwaaaaa/
こういうありえないアドレスにアクセスすると

domain.com/404/uwaaaaa/
うーーん。。。何故か遷移元のURLを引き継いでしまいます。。。

とりえずのごまかし方

引き継がないようにあれこれやってみましたが、結果的にはごまかす方向で逃げました。

<ReplaceKeyPrefixWith>404</ReplaceKeyPrefixWith>

<ReplaceKeyPrefixWith>404?referer=</ReplaceKeyPrefixWith> 

どうしても引きはがせないURLの部分を何の意味もないクエリストリングにすることで404の画面をそれっぽく見せることにしました。

ごまかしに過ぎませんが、これは一体。。うーーん。。。

AWS 認定ソリューションアーキテクト – アソシエイトに合格したのでやったことを書いていく

先日、名古屋で開催された「ラブライブ!サンシャイン!! Aqours 2nd LoveLive! HAPPY PARTY TRAIN TOUR」 に参加するついでに表題の試験を受けてなんとか合格出来たのでやったこと書いていきます。

合格証はこんな感じかな?

www.certmetrics.com

〇受けようと思ったきっかけ
単純におちんぎんが欲しかったのと、自分レベルでも受かりそうだなと思ったのが1番の理由です。
仕事でもAWSは使ってますし、AWS知識はあって損することはないかなと思いました。 筆者はオンプレ経験もないし、webの仕事をちゃんとし始めて1年ちょいで404以外のエラーコードもググらないと知らないし、wellknownポートもsshが22番で httpが80番ということを知ったのも最近というレベルです。

〇試験について

試験会場がとても少なく、NAGANOのような蒙い土地では試験が受けられないので、今回イベント遠征で受けるしかありませんでした。 そのため順延することも、落ちることも許されないし受験料がバカ高いというちょっと厳しい中での受験だったので落ちるわけにはいかないと自分を追い込めたことが功を奏したのかなと思います。

やったこと

1.ラブライブ!サンシャイン!!を視聴する

 とても良い内容で前向きな気持ちにもなるし、ライブにも行きたくなりました。 なにか資格を取りたいけどモチベが続かない人は思ってる人はまずはラブライブ!サンシャイン!!を見てください。 ラブライブ!も見てないという人は一期と二期と劇場版をプロットを抑える程度でいいので見てください。(僕もよく憶えてません)

視聴時は序盤の千歌ちゃんの気持ちと目的、あと最終回での母親との会話シーンをしっかり抑えた上で見ると作品理解に繋がると思います。

2.合格対策本を読んだ

電車の中や寝る前はずっとこれを読んでました。4週ぐらいはしたんじゃないでしょうか。 業務ではEC2、S3、CloudFront、SNS、CloudWatch辺りは使ってるのでなんとなく概念が分かりますがGlacierとかDynamoとかSQSとかSWFとか名前すら知らなかったので、こういう本で概念を得るのはとても大事だと思います。

http://www.yodobashi.com/product/100000009002617642/

3.模試を受けた

本を2周した段階で模試を受けました。 2000円ちょいぐらいで受けれます。 問題数は少ないですがこういう感じの問題がでるよって分かるので良いと思います。 苦手分野も分かりますし。
問題は全部スクショに残して見直ししてください

これをやるやらないで大きく違います。 ちなみに自分は45点しか取れませんでした。

もうダメだ諦めようと思いましたが、君の心は輝いているかい?の歌詞の

君は何度も立ち上がれるかい?

の歌詞を思い出して問題を見直すことにしました。

本の内容は分かったつもりでも違う表現で説明されると分からなかったりして、もっと頭を回せば分かるような問題も結構あることに気付きました。 さっぱり分からんと言うのも4問ぐらいありましたが、それ以外が取れれば合格なのでいけると根拠なく確信してました。

4.問題を解きまくったりブラックベルトを読んだ

AWS WEB問題集で学習しよう – 赤本ではなく黒本の問題集から学習する方向け
ここに課金して電車で暇を見つけてはずっとやってました。
やりっぱなしにしないで、時々過去にやった問題に戻ってやったことはできているかどうかを確認しながら進めました。 問題数が多いのでがむしゃらに進むのもいいですが、時々しっかり止まって、理解しているか確認しながら進むことが大事だと思います。   

よくホワイトペーパーを読めって意見もありますが、僕は英語読めないのでブラックベルトを読んでました。 slideshareの方ならスマホでも読めるし、pdfをスマホで読むのは厳しいです。

5.模試をもう一回受けた

ライブで遠征する2日前に試験を受けるべきかどうかの最終判断のためにもう一回模試を受けました。 結果は70点の合格、本試験は模試よりも難しいので受けるかどうか悩みましたが、この日に種田梨沙さんのお仕事復帰宣言がでていて、とても前向きな気持ちになれていたし、このビックウェーブに乗って朗報コンボを続けたいという思いで受験を決意しました。

6.最後までベストを尽くした
当日はバスでの移動でしたがバスの中でもずっと黒本サイトの問題を解き続けてました。 また試験中も問題が異様に難しくなんどもあ、これ無理かもって思いましたが、最後まで、見直しとあと問題をよく読み込んで、消去法や文脈理解でぎりぎりまで頭をぶんまわし続けたおかげで

なんと60%台半ばでしたが(恐らく)ギリギリ合格を果たすことができました!

〇まとめ
 大事なことはAqours(ラブライブ!サンシャイン!!に出てくる主人公達が結成したスクールアイドル)からもらった諦めない力です。 人間追い込まれれば力を発揮します。 安からぬ受験料捨てたくないじゃないですか? 資格手当でおちんぎん欲しいじゃないですか? 資格欄になんか書きたいじゃないですか?

そういった(灰色の感じすらある)欲求に素直になることだと思います。

ラブライブ!サンシャイン!!を見ましょう。9月から二期が始まります。

焦燥感に駆られてるエンジニアは高海千歌を目指せ

最近仕事が忙しかったので癒やしを求めてラブライブ!サンシャイン!!を見直してました。

改めて見てみると自分のようになにか焦燥感に追われてるエンジニアを前向きにさせる良い内容だったので色々思うところを書いておこうと思います。

 

ラブライブ!って何?

ラブライブ!サンシャイン!!はタイトルにもあるようにラブライブ!というスクールアイドル達が競い合う大会の名前から取られています。

1作目のラブライブではμ'sというユニットの9人の女の子達の物語が描かれ、ラブライブ!サンシャイン!!では沼津に住むAqoursというユニットで同じく9人の物語が描かれている。

が、別にラブライブ!での大会の優勝を目指して努力する話でもないし、ラブライブ!自体についてはあまり描写されず、むしろ、メンバーそれぞれの悩みの克服や欲求を叶える場としてスクールアイドルを始め、そして地区予選を突破して東海予選に出場するところで第一期は終了しました。

念のために添えておくとスクールアイドルとして頂上を目指すサクセスストーリーではありません。

高海千歌は何故スクールアイドルを始めたのか?

本作で重要なことは彼女たちがスクールアイドルを始めた動機にあると思ってます。
主人公の高海千歌は「このまま何もしないままだと普通になっちゃう」という焦燥感と
街頭モニターで見たμ'sの映像に衝撃を受けてスクールアイドルを始めることとなりました。

元々「輝きたい」というシンプルな欲求で、それを満たすためスクールアイドルという場が提供されただけで、実は水泳でも、サッカーでもなんでも良かったんじゃないかと思います。

もちろん、アイドルが歌って踊る映像はとても輝いて見えますのでスクールアイドルであることは作品の動機付けを補強することに意味が合ったと思います。

 

焦燥感にかられたエンジニアは何故スクールアイドルを始められないのか?

スクールアイドルというのは比喩でここではプログラミングスキル向上のための活動と置き換えてください。
掲題の回答としては単純にいうと現実との折り合いが付かないからです。
1日最低8時間働いて通勤で+1時間以上かけて、アニメも見たいし姪っ子とも遊びたい自分としてはプログラムの勉強にかけるコストなんて残っていないというのが本音です。

また、面白そうな分野というのもたくさんあって、AWSMicrosoftも次々と新サービスを提供してきますし、機械学習、IoT、VR、フロントエンド、バックエンド、インフラ、スマホアプリ・・等々やってみたら面白そうなこと、楽しそうなことで世の中は溢れかえっています。

千歌ちゃんがスクールアイドルを選択出来るぐらい簡単に何かを選ぶことが難しい時代になってきていると思います。

本作で、曜ちゃんが飛び込みかスクールアイドルかを悩むシーンはありませんし、(梨子ちゃんに関してはピアノの大会かラブライブ!地区予選かで悩むシーンがありましたが)3年生組が受験勉強に追われる描写もありません。

作中からそういった現実との折り合いやスクールアイドル以外のタスクに追われる描写の存在を想像することはできません。

しかし、少なくとも彼女たちは夏休み返上で特訓をしています。
持てる時間はすべて練習に当てているのです。
そうです、エンジニアとAqoursの違いはモチベの有無なんじゃないかと思います。

自分のモチベを捧げられる何かを発見出来ていないのが一番なんじゃないでしょうか?

 

高海千歌も挫折している

本作の最後に少しだけ触れられていますが、千歌ちゃんもスクールアイドルを始める前に何か色々やってみては辞めてるようなことを母親が示唆していたように、千歌ちゃんもまた、スクールアイドルにたどり着く前に多くのことを始めては挫折していたことがうかがえます。

焦燥感に駆られたエンジニアも本を買ってみたり勉強会に出るなどしつつも結局少し手を付けて辞めてしまうことは往々にしてあるのだと思います。

挫折してもそれでいいと、ラブライブ!サンシャイン!!は教えてくれています

そうです、「君のこころは輝いているかい」の歌詞は以下のように挫折しても立ち上がることの重要性を説いています。

君はなんども立ち上がれるかい?
胸に手をあて"Yes!!"と笑うんだよ
まだ出会いにどんな意味があるか
知らないけれどまぶしいね 僕らの夢 

 

この先がどうなるか分からないけど立ち上がることを述べるのは、先が見えず将来が分からない世界や社会の情勢の中で、立ち上がり続けることで状況に対応しようという現代人へのメッセージが込められているようにすら感じます。


色々手を付けては辞めてしまい、結局中途半端だった高海千歌にとって、スクールアイドルを始めて東海大会に進み、九人(地区予選では8人だったため)であの舞台で彼女の輝きたいという物語は達成してしまっているのです。

だから僕は二期は不要だと思います。
二期になってファンアート的にみんながわいわいする話は、ちょっとした後日談的なOVAなどとしては面白いかも知れませんが、すでに完結した物語をそこまでと同じかそれ以上の分量で描くことは物語としていけないと思っています。
もし、二期や劇場版が必要だとするなら、それはAqoursの後継者を作るために彼女達を伝説に仕立て上げるという作業だけでしょう。

 

最後にもう一つ、Aqoursの歌の中から歌詞を引用して終わりたいと思います。

特に最後の1行が大好きです。

届かない 星だって
手を伸ばす勢い持って
届かないって決めないで
手を伸ばせ それから悩め!

 

30を超えて普通にすらなれない底辺エンジニアの僕にとって手を動かすこと、挫折しても次を見つけて立ち上がり続けること、Aqoursの九人は本当に大切なことを教えてくれると思います。

 

しかし、30超えたおっさんが女子高生の生き方に感動するってキモチワルイデスネ

AWSのcentos+nginxでオレオレ証明書〜クライアント証明書+Let'sEncryptに証明してもらうまで

2日ぐらい作業をしたのですが、結構無駄に時間を食ってしまったので詰まりポイント等をメモしていきます

1.各証明書系を作る

qiita.com

4番以降はApacheの設定の話なのでスルーします。

2.作った証明書をnginxに設定する。

/etc/nginx/nginx.confを直します。

server {
listen 443 ssl; # ssl on; ではなく、listen に書くのが推奨
server_name domein名を書く!;

# server certificate
sl_certificate /etc/pki/CA/certs/ドメイン名.crt; # サーバのSSL証明書。

# server privatae key
# ssl_certificate_key /etc/pki/CA/private/ドメイン名.key; # サーバの秘密鍵。

ssl_verify_client on; # クライアント認証
# ssl_verify_depth 10; # 中間CA を使う場合のみ

# CA certificate
ssl_client_certificate /etc/pki/CA/cacert.pem; # プライベートCAの証明書
}

正直、どのファイルをどこに置けば良いのか全然分からないので最初にそこで詰みました。
どれがなんのファイルか理解しないと行けませんね

あと、reloadしたらエラーになって動かないこともあるので事前にチェックができます。

# which nginx
/sbin/nginx
# /sbin/nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# 

3.Let'sencryptで証明書を無銭で証明してもらおう

オレオレ証明だとchromeさんがこんな感じにエラーを吐きます。(画像は参考です) f:id:darakunomiti:20170617115533j:plain

ちなみに長野県のサイトは未だに証明書系がおかしいのですが、いつ直るのでしょう・・

とにかくサーバーの証明書をちゃんとしたものにするためにlet'sencryptというものを入れます。
これをやるとレッツエンクリプトさんが認めたサーバーだからOKとchromeさんも怒らないみたいです。

基本的な手順書はこちtkuchiki.hatenablog.com

4.証明書をnginxさんに教えて上げよう

confをこんな感じに設定を直しましょう。

server {
        listen 443 ssl; # ssl on; ではなく、listen に書くのが推奨
        server_name ドメイン名;

        # server certificate
        ssl_certificate /etc/letsencrypt/live/ドメイン名/fullchain.pem; # let's encrypt ★ここを変更
        # server privatae key
        ssl_certificate_key /etc/letsencrypt/live/ドメイン名/privkey.pem; # let's encrypt ★ここを変更        

        ssl_verify_client on; # クライアント認証
  
        # CA certificate
        ssl_client_certificate /etc/pki/CA/cacert.pem; # プライベートCAの証明書   
     }

詰まったポイント

1 t2.microだとメモリーが足りなくて落ちる

./certbot-auto certonly –webroot -w /usr/share/nginx/html -d your.domain –agree-tos -m your@email.address –debug をやった際にmemoryが足りないぞと怒られます。 しかし、それ以外にもgccのインストールで失敗してるとかpip のバージョン上げろとか色々出てるので混乱するんですよね (エラーログはすみません、残ってません)

対策) メモリーを増やそう! swapというのを使えばいいみたいです。 oh-sky.hatenablog.com

2.IP制限をかけていたのでLet'sencryptさんが自分のEC2に繋げられずにエラー

koty.hatenablog.com こちらに書かれてるとおりです

アクセス元の66.133.109.36 は固定されたIPのようなので、次回からはこのIP指定でアクセス制限しても良いかもしれない。

書かれているとおりセキュリティグループに上記を追加したら上手くいきました。

3.well-knownに繋がらない

let'sencryptは/usr/share/nginx/html 配下に .well-known/acme-challenge/ランダム文字列 で何かを作りますがここにアクセス出来なくて困っていたようです。
なのでnginxさんにこちらのlocationを作って上げないと行けませんでした。

    server {
        listen 80; # ssl on; ではなく、listen に書くのが推奨
        server_name ドメイン名;
        location ~ /.well-known {
            root    /usr/share/nginx/html;
        }
    }

これを追加します。 正しいのかどうかはよく分かりません(^_^;)

4.chromeだけエラーを出し続ける(T_T)

上記の設定でsafarifirefoxでは証明書系の警告がなくなりましたがなぜかchromeだけで続けるんですよ!
プライベートブラウズしても!

多分の回答)nginxに中間証明書はないぞ!

# ssl_verify_depth 10; # 中間CA を使う場合のみ

手順書にこういう話があったので上記の1〜3で困ったときに中間証明書の設定をonにしたりoffにしてみたりしてました。
が、よくわかりませんがこの設定がonになってるとchromeさんだけ証明書を更新してくれず?エラーを出し続けます。 これを切ってnginxをreloadすることで無事chromeでも証明書の警告がでなくなりました。

これでひとまずクライアント証明書ができて、クライアント証明書を持った人が警告なしでサイトを開けるようになりました!

問題は期間が短いのでこいつを延ばしてやる必要があります。。(以下次号)