index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>sawa.md</title>
    <link>https://SawaTszm.github.io/</link>
    <description>Recent content on sawa.md</description>
    <image>
      <title>sawa.md</title>
      <url>https://SawaTszm.github.io/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://SawaTszm.github.io/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo -- gohugo.io</generator>
    <language>ja</language>
    <lastBuildDate>Sun, 02 Jun 2024 22:21:53 +0900</lastBuildDate><atom:link href="https://SawaTszm.github.io/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>【日記】最近読んだ本の感想【2024/05/31】</title>
      <link>https://SawaTszm.github.io/post/book-202405/</link>
      <pubDate>Sun, 02 Jun 2024 22:21:53 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/book-202405/</guid>
      <description>幸福な王子/柘榴の家 童話集第一遍が「幸福な王子」、第二遍が「柘榴の家」で、今回は両方が一冊に纏まっているものを読んだ。幻想文学、というジャンルを（おそらくちゃんと意識しては）初めて読んで、あらゆるものに自我がある独特な世界観に圧倒されつつも楽しく読めたけど、よくよく考えたら「サルカニ合戦」とかも臼が喋ってるのに子供の頃は深く考えないで読んでたよなと思った。童話で花が喋ろうが打ち上げ花火が喋ろうが、読み聞かせてもらう子供にとっては問題ないのかもしれない。
ジャイロスコープ 短編集。あとがき的なインタビューで先生本人も仰ってるけど、読者の考える「伊坂さんらしさ」は若干薄い短編が多め（特に「ギア」とか）。「浜田少年ホントスカ」と「1人には無理がある」が特に好き。
特に「浜田少年ホントスカ」の、
「殺し屋なんていう便利な職業は、フィクションの中にしかいないですからね」
これを読んだ最初は、こういうメタ的に刺してくる台詞を登場人物に言わせるの好きだなー、とだけ思ってたけど、読み返してみるとこれってこっちの台詞に意識を持っていかせることで、少し前の浜田少年の「プロの殺し屋に頼んだ方がいい」という若干違和感のある台詞をかすませてるのがすごい。他にも好きな言い回しは山のようにあったけど、あげるとキリがないので割愛する。
夜の国のクーパー 伊坂さん祭り。
なんとなく、「私」にとってこの国はミニチュアの世界みたいな物なんじゃないかなぁと確たる証拠もなく漠然と考えていたので、まさか本当にそうだとは思わず読み進めていてびっくりした。
冠人に対する印象が文字通り180度ひっくり返ったけれど、「この親にしてこの子あり」という観点で凄まじく納得出来たのがよかった。物語上、一番明確な目的を持って動いていた複眼隊長の目的が、実は冒頭で既に達成されてました、という読み終わった後にわかるあっけなさも好き。殺し屋シリーズのような転がっていく楽しさ、というよりは、じわじわと謎が深まっていく面白さ、という感じだった。
二重人格 めちゃくちゃ難しくて自分の読解力を疑いそうになった。勢いで読み切った後に見た巻末解説に「ドエトスフキーの作品の中でも評価がわかれる」「冗長な書き方が～」的な事が書いてあってちょっと安心した。個人的には、タイトルとあらすじを見て、自分の理想の姿の他人格が内面に生まれて支配されてしまう話かなと思ってたんだけど全然違くて、自分が上手くいかない理由を突然現れた理想の自分が邪魔してくるからだと思い込んで破滅（自滅）するという話でちょっと意外だった。そもそも「二重人格」っていうタイトル自体が、本来はロシア語でのドッペルゲンガー的な単語の意訳らしいと知って納得した。他のドエトフスキー作品を何冊か読んでからまた読み返したい。
「後回し」にしない技術 kindle unlimitedで読んで良かったので再読。ドエトフスキーの小説読んでみようと思ったのもこの本から。「一冊読もう、ではなく一行読もう」とか、「ウォーミングアップに時間をかけるな」とか、後回し癖のある人（私）にとっては切れ味の鋭い言葉が多い。この本とか、「勉強が面白くなる瞬間」はモチベーションダダ下がっている時に読みたい。</description>
    </item>
    
    <item>
      <title>【git】カウントしたコミットファイルの総文字数を自動でコミットメッセージに追加する</title>
      <link>https://SawaTszm.github.io/post/auto-counting-word/</link>
      <pubDate>Mon, 06 May 2024 14:51:45 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/auto-counting-word/</guid>
      <description>趣味で書いている小説をgitで管理していて、進捗把握のためにコミットメッセージにその日1日書いた総文字数を入れ込んでいます。
こんな感じで。
以前までは、SF作家である藤井太洋先生自身が公開してくださっている拡張機能: novel-writerのステータスバー表示で文字数を把握し、手動でコミットメッセージを書いていました。
ただ、この方法にはいくつかの（個人的には解決したい）問題があり、
日付が回ると文字数がリセットされるので、うっかりしてると差分の文字数がわからなくなる 特定のファイルや変更は含みたくない場合がある（翌日への自分のメモなど） コミットメッセージへの手打ちを辞めたい 上記二つに関しては、私が拡張機能で出来ることを把握しきれていないだけ or 今後改善される可能性はありますが、どうせならコミット時に自動でコミットメッセージ入力できたら楽だよなぁという動機があったので、ちょっと調べてスクリプトを組んでみました。
やったこと 下記のスクリプトを.git/hooks/commit-msgとして設定します。
#!/bin/bash # ステージングエリアに追加されたファイルの差分を取得し、文字数をカウントする関数 # .git/hooksに移動させて、`chmod +x .git/hooks/commit-msg`を実行することでコミット時にhookされる get_character_count() { # ステージングエリアに追加されたファイルの差分を取得 diff_output=$(git diff --cached) # 追加された行の文字数を合計する added_characters=$(echo &amp;#34;$diff_output&amp;#34; | grep &amp;#39;^+&amp;#39; | sed &amp;#39;s/^+//g&amp;#39; | wc -m) # 削除された行の文字数を合計する deleted_characters=$(echo &amp;#34;$diff_output&amp;#34; | grep &amp;#39;^-&amp;#39; | sed &amp;#39;s/^-//g&amp;#39; | wc -m) # 追加された文字数と削除された文字数の合計を計算する total_characters=$((added_characters - deleted_characters)) # 結果を出力 echo &amp;#34;$total_characters&amp;#34; } # コミットメッセージに追加 character_count=$(get_character_count) echo &amp;#34;📝 $character_count 文字&amp;#34; &amp;gt;&amp;gt; &amp;#34;$1&amp;#34; スクリプト内でやっている事はかなりシンプルで、git diffの結果である追加行(+で始まるもの)と削除行(-で始まるもの)の文字数をそれぞれカウントして差し引いて、総文字数を計算しているだけです。</description>
    </item>
    
    <item>
      <title>【github】mainではないブランチから派生したブランチでPRを出すとき</title>
      <link>https://SawaTszm.github.io/post/pr-on-a-branch-not-main/</link>
      <pubDate>Fri, 08 Mar 2024 18:16:03 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/pr-on-a-branch-not-main/</guid>
      <description>ベースブランチってどこ向け？
タイトルの通り、main(default)ではないブランチから派生したブランチのPRを出すのに謎の抵抗感があったのですが、githubくんがかなりよしなにしてくれることに気がついたのでその挙動を備忘録として書いておきます。
（知っている人にとってはめちゃくちゃ当たり前体操な内容だと思います）
TL;DR main(default)ブランチから切ったブランチAから更に切ったブランチA2のPRを出すときは、難しいこと考えずにブランチA向けにPR出すのが良き。
どういうこと？ たとえば、チームメンバーがmainから派生したbranchAで作業していたとします。
branchAに乗っている機能が前提の作業をするために、branchAからbranchA2を切りました。
branchA2の作業が終わりPRを出したいのですが、branchAはまだ細かい部分のPR中でmainにはマージされていません。
さて、このbranchA2のPRの向き先はmainかbranchAか、という話です。
今こうして自分で書いていても「いやbranchA向けだろ……」と思うのですが（main向けにPRを出すと、branchAのコミットもPRに乗ってしまうためかなり見づらいことになるので）、
「branchA向けに出したとして、branchAがmainにマージされたらbranchA向けのPRはどういう扱いになるんだ……？　mainでrebase or mergeしてmain向けに直さないといけないのか？」と漠然と面倒臭がっていました。今までは。
この「PRのbaseとなっているブランチがマージされていった後にデフォルトのブランチ向けのPRに直す」作業、githubが勝手にやってくれます。
実例 （ほとんどmainにしかpushしていないprivateリポジトリで実験）
test-branch-Aというブランチををmainから切ってPRを出したとします。
その後、test-branch-Aから切ったtest-branch-A2のPRをtest-branch-A向けに出します。
（PR作成時にbaseが選べるし、作成した後もEDITボタンから変更できます）
この状態でtest-branch-AのPRがマージされると、
Base automatically changed from test-branch-A to mainというログが残って、test-branch-A2のPRがmain向けに自動修正されます。
めちゃくちゃ便利だ……。もっと早く気が付きたかった。
PR出した後は、ベースとなるブランチ自体に先んじてマージしちゃうか、そっちの作業を待ってからmainにマージするか、どちらにせよベースとなるブランチで作業している方とのコミュニケーションは必要ですが、とりあえず派生元にPR出しておけばあんまり困ることは（今のところの経験上）ないです。
派生PR、もう怖くない！な備忘録でした。</description>
    </item>
    
    <item>
      <title>日記(~2023/07)</title>
      <link>https://SawaTszm.github.io/post/diary-2023-07/</link>
      <pubDate>Tue, 27 Jun 2023 17:14:07 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2023-07/</guid>
      <description>(2023/06/17)
We updated our RSA SSH host key - Github
私用のPCで久々にpushしようとして警告出て、ちゃんと公式情報見た上で対応できたけど、3/24以降仕事以外のコードをpushしてなかったことが地味にショックでした。
(2023/06/24)
広くなったベランダで育て始めたペパーミント、苗買ってきた時よりなんか葉っぱ過疎ってないか……？と思って見てみたら馬鹿でかい青虫がついててリアルタイムでもりもり葉っぱ食べられてました。
(2023/06/26)
「AI分析でわかった トップ5％社員の習慣」を読んで、上位5%社員のXX%が〜っていうのに関しては、サンプリング数少ないから95%の人たちと違って一概には言えないんじゃないの？（この本作るために良いところだけピックアップするときにだいぶバイアスかかってそう）とは思ったけど、これ実践してみようかなと思うところはいくつかあったので読んでよかったです。
読んですぐに（内容は本とは全然関係ない）スーパーミニマムな社内LTをしたんですが、「資料作りに時間をかけない」と割り切って最初からNotionにまとめることで割と短い時間で形に出来たのが個人的にいい学びでした。
(2023/06/27)
JavaScriptの入れ子の関数とクロージャ、シンプルに知らなかったです。使い過ぎはネストが辛くなりそうなので良くないと思う（というかユースケース自体あんまり思いつかない）けど、外側の関数のスコープを持ってくれる性質を利用して、コード理解の一助のためにロジックの一部を別関数に切り出す時なんかには有効そうだなと思いました。</description>
    </item>
    
    <item>
      <title>【覚え書き】JavaScriptのプライベートクラス機能</title>
      <link>https://SawaTszm.github.io/post/private-class-field/</link>
      <pubDate>Tue, 20 Jun 2023 23:05:31 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/private-class-field/</guid>
      <description>TypeScriptを使っていると、「ちゃんとprivateとかreadonlyとか使って制約かけないとな〜」と認識し直すタイミングが定期的に来るんですが、
そんな折にJavaScript側で実現できるプライベートクラス機能なるものがあることを知りました。
プライベートクラス機能 - JavaScript | MDN
クラスのフィールドの先頭にハッシュ(#)をつけることで、プライベートなインスタンスフィールドを生成することができます。
あくまでコンパイル時にエラーの判定を行うTypeScriptと異なり、JavaScript自身の機能なのでランタイム時に判定＆エラーを返してくれます。
継承を使う場合は、privateと同じく子クラスからは参照不可になりますが、
子クラス側で同じ名前のプライベートインスタンスフィールドを定義することはできます。
存在を知ってパッと概要を追って、良さそうと思ったけど世の反応（？）はどんな感じなんでしょうか。
（ちなみに、インスタンス生成時に少し遅くなるらしい、と言う旨の去年の記事はお見かけしました: JavaScriptでプライベートを使うと遅くなる話）</description>
    </item>
    
    <item>
      <title>日記(~2023/06)</title>
      <link>https://SawaTszm.github.io/post/diary-2023-06/</link>
      <pubDate>Sat, 17 Jun 2023 15:11:15 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2023-06/</guid>
      <description>(純然たる日記の寄せ集めです)
(2023/04/01)
ながら聞き用にbocoのPEACE SS-1買いました。
仕事中に音楽とかラジオとか聴きたい派なんですが、ずっとイヤホンをしていると耳が痛いし、中耳炎になって危ないってよく聞くし……と思って数年前にShokz(旧Aftershokz)の骨伝導イヤホンを買ったのが骨伝導との出会いでした。
買った当時は気にならなかったんですが、しばらく経ってちょっといい椅子を導入してヘッドレストにクッションをつけたら首周りの部分が干渉するようになってしまって、ちょっと不便だな〜と思っていたところにPEACE SS-1くんと出会いました。実に快適です。ありがとうboco。
（耳を挟むように押し込むと音量上げたりできるらしいですが、なんか直感的に出来なくてコツが必要＆挟み込み部分の寿命縮めそうなので本体操作は諦めてます）
(2023/06/16)
最近調べ物によくChatGPTを使っていて、便利だなぁと思う反面このままいくと原神のスメール編で学者たちに起きていたこと（聞けばなんでも出してくれるアーカーシャ端末があるから、誰も一次情報に触れようとしなくなる）が自分の中で起こりそうだなぁと漠然と考えたりしてました。
利便性の恩恵を受けつつ、自分で調べ物をする感覚は忘れないように上手く間をとっていきたいです。
(2023/06/17)
応用情報がCBT方式になるのを密かに待っているんですが（基本情報はそれで去年受けた）、長文読解とか記述方式の回答とかの相性の問題で中々導入されないんじゃないか説が結構濃厚な感じがするので、観念して秋季に受けようかなと考え中です。
予定があれば早起きできることを証明したいと思います。</description>
    </item>
    
    <item>
      <title>SSOについて調べたことまとめ</title>
      <link>https://SawaTszm.github.io/post/sumary-sso/</link>
      <pubDate>Sat, 17 Jun 2023 11:06:39 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/sumary-sso/</guid>
      <description>SSO、使う側としてはよく見かけますが実装する側としてはあんまりキャッチアップしてこなかったなと思ったので、軽く調べたのをまとめておきます。
SSOとは シングルサインオン（Single Sign-On、SSO）は、ユーザが1回の認証で複数のアプリケーションにアクセスできるようにする仕組み全般のことを指します。
大きく分けるとSAML（Security Assertion Markup Lnaguage）、OIDC（OpenID Connect）の2つの一般的なプロトコルがあります。（※諸説ある）
SAML SAMLアサーション（ユーザ情報とアクセスできる内容を含む暗号化署名されたXMLドキュメント）を使用してサービス間でID情報を共有します。
ビジネス系（Slack, Office365, Salesforce）などでよく見られる（らしい）です。
OpenID Connect JWT(JSON Web Token)を使用してサービス間でID情報を共有します。
よくお世話になる「GoogleアカウントでYoutubeにログインしている」系はOpenID Connectで実現されています。
代表的な実現方式 （【図解つき】シングルサインオン（SSO）とは？機能や仕組み、導入メリット、デメリットをわかりやすく解説！ | mobiconnect（モビコネクト）を多大に参考にしています、ありがとうございます）
代行認証方式 利用者の代わりにエージェントが認証情報を保持し、ログイン画面を検知したら代行して各システムのID、パスワードを入力する方式です。
（個人的にはこれをSSOと呼んでも良いのか、という気持ちは多少あるけど、パスワード自動生成などで認証情報を意識しないので実質SSO、と言うことなのかもしれない）
システム側でSSOに対応していなくても、ID/パスワードでログインする一般的なシステムであれば使用することができ、活用範囲が広いです。
その代わり、利用者側のPC（もしくはWebブラウザ）に常駐するエージェントを必ず入れる必要があります。
リバースプロキシ方式 Web上で実現するSSOの仕組みとして、アクセスを全てリバースプロキシと呼ばれる中継サーバを介して行うようにネットワークを設計する方式です。
リバースプロキシに対して認証を行うと、認証済みのCookieが発行され、各サイトにアクセスできるようになります。 対象としたいシステムに何か導入する必要がないため、既存システムへの影響がほぼない状態で事前検証ができます。が、リバースプロキシがボトルネックになる可能性があります。
実装する場合はざっくり以下のような構成になります:
Nginx等を使用して、アプリケーションへのリバースプロキシをセットアップ SSOプロバイダの設定（色々あるので最適なものを選ぶ） アプリケーション側の認証ビュー（API）の実装 エージェント方式 リバースプロキシ方式同様、Web上で実現するSSOの仕組みで、Webサーバやアプリケーションサーバにエージェントソフトウェアを組み込む方式です。
組み込んだモジュールがSSOサーバと連携することでSSOを実現します。
リバースプロキシと異なり、ボトルネックが発生しづらい、既存のネットワーク環境に変更を加えなくて良い点がメリットです。
SAML認証方式 SAML認証方式は、IdP（Identity Provider）とSP（Service Provider）の2つの要素で構成され、SP側（Webサーバやアプリケーション側）をSAMLに対応させることで、IdPが提供する認証情報を利用してSSOを実現できます。
（名前がすごくややこしいけど、別に他の方式がSAMLプロトコルを使わないと言うわけではなくて、この方式の説明の意図は「上二つの方式と異なりWeb上で完結せず、アプリケーション側でSAMLに対応するSSO方式」ってことだと思います）
まとめ 認証まわりって難しいですね。
（見ている途中でソーシャル認証やOAuth2あたりの情報も出てきましたがちょっとパンクしてきたのでここで止めておきます）
参考 シングルサインオンとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 【図解つき】シングルサインオン（SSO）とは？機能や仕組み、導入メリット、デメリットをわかりやすく解説！ | mobiconnect（モビコネクト） What Is Single Sign-on (SSO)? How It Works - YouTube 後で見たい Django SSO - YouTube </description>
    </item>
    
    <item>
      <title>Flutter周りで知ったことまとめ</title>
      <link>https://SawaTszm.github.io/post/diary-2023-03-11-about-flutter/</link>
      <pubDate>Sat, 11 Mar 2023 20:43:27 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2023-03-11-about-flutter/</guid>
      <description>最近個人でFlutterを触っていて楽しいので色々調べていて、その時知ったことや勉強会で聞かせてもらった話などのまとめ。
（「こんな便利なものあるんだ〜」と思っても一回ブラウザのタブを開いちゃうと忘れがちなので、自分用のリンク集として）
Material Design3 https://m3.material.io/
Material 3 is the latest version of Google’s open-source design system. Design and build beautiful, usable products with Material 3.
(拙訳) Material 3 は、Google のオープンソース デザイン システムの最新バージョンです。 Material 3 を使用して、美しく使いやすい製品を設計および構築します。
Googleのデザイナーと開発者によって構築・サポートされている、オープンソースなデザインシステム。
Android, Flutter, そしてWeb向けのUXガイダンス・UIコンポーネントの実装が含まれている。 PrimaryColorを選択するだけでいい感じに各色設定してくれたりするので便利。
（絶対それ以外の便利な使い方もある）
// ThemeDataで指定する ThemeData( useMaterial3: true, colorSchemeSeed: Colors.XXX, // 好きな色 ) これだけでデフォルトの「テストです！！！」と言わんばかりの真っ青なヘッダが変わるのでちょっと「おぉ……」ってなる。
DartPad https://dartpad.dev/
Dartの構文を気軽に試せる。便利。
ちなみに、新しいバージョンを試したいときは下のstable channelを押して切り替える。
Serverpod https://serverpod.dev/
reverpodならぬServerPod。
Flutterコミュニティ向けに、Dartで書かれたOSSのアプリサーバ。
isar https://isar.dev/
hiveのv2系としてのプロジェクトらしい？
Flutterで使うデータベース。詳しくはこれから調べる。</description>
    </item>
    
    <item>
      <title>Python: requestsのタイムアウトエラーについて</title>
      <link>https://SawaTszm.github.io/post/python-requests-timeout/</link>
      <pubDate>Wed, 08 Mar 2023 16:47:00 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/python-requests-timeout/</guid>
      <description>pythonでHTTP通信するときに大体使うrequestsで、timeoutエラーの種類で問題の切り分けがしたくて調べたのでちょっとまとめ。
TL;DR 公式ドキュメントのExceptionsを見るとわかりやすい。
中でもタイムアウト関連のエラーは以下の二つ:
connect timeout requests.exceptions.ConnectTimeout例外が投げられる。
相手のサーバと接続を確立する時に時間がかかりすぎたtimeout。
公式ドキュメント
read timeout requests.exceptions.ReadTimeout例外が投げられる。
相手のサーバからレスポンスが返ってくるまでに時間がかかりすぎたtimeout。
公式ドキュメント
両方まとめてcatchしたい時は requests.exceptions.Timeout例外が設定されていて、ConnectTimeout, ReadTimeoutどちらも含まれます。
もうちょっと詳しく そもそもRequestsの例外の中には、RequestException（曖昧な例外）やConnectionErrorが設定されていて、明らかに設定がおかしい場合や早期に接続エラーが起きた場合には、レスポンスを待つ前にこの例外が投げられます。
それらが起きずにtimeoutエラーが起きた場合は、接続の確立で相手からレスポンスが返ってこない(ConnectTimeout)か、接続確率はできてるけど接続先がデータの準備などで時間がかかりすぎて設定したtimeout時間内にレスポンスが返ってこない(Readtimeout)かの二択。
なので、ConnectTimeoutが起きた時には安全に再試行できると公式ドキュメントにも書かれてます（少なくともリクエスト時の設定に問題がある訳じゃないから）。
Timeout例外が出た時にする事は下記の感じになると思います:
ConnectTimeoutが出た場合は、リクエストを投げてる相手のサーバがダウンしてないか、ネットワーク設定に問題がないかを確認する。 ReadTimeoutが出た場合は、接続の確立には成功していて、向こうのレスポンスに時間がかかっているので、リクエストするサーバ側にも責任がある場合はチューニングする。そうでない場合は一度timeout時間を伸ばして成功するか様子を見る。 デフォルトのtimeout時間は設定されていないので注意する 明示的に設定しない限り、timeoutのデフォルトはNoneです。つまりtimeoutしません。
基本的にはtimeoutを設定して、上記のtimeoutエラーで原因がわかるようにした方が良さそうです。
import requests try: # connect timeout, read timeoutどちらも同じ値で良い場合 res = requests.get(&amp;#39;有効なURL&amp;#39;, timeout=30) # connect timeout=30, read timeout=60とかで分けたい場合 res = requests.get(&amp;#39;有効なURL&amp;#39;, timeout=(30, 60)) except requests.exceptions.ConnectTimeout: print(&amp;#34;接続確立のエラー&amp;#34;) except requests.exceptions.ReadTimeout: print(&amp;#34;レスポンスが遅すぎたエラー&amp;#34;) </description>
    </item>
    
    <item>
      <title>Wakatime導入してみた</title>
      <link>https://SawaTszm.github.io/post/install-wakatime/</link>
      <pubDate>Tue, 28 Feb 2023 23:40:16 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/install-wakatime/</guid>
      <description>個人開発でアプリ出したいなぁと思っていて（今はFlutterくんと仲良くなるためにチュートリアルやってるだけですが）、毎日少しずつでもコーディングするモチベーションが欲しい……！と思ってwakatimeを導入しました。
wakatimeは、VSCodeなどのエディタと連携して、実際にコーディングしている時間を計測してくれるサービスです。
ちょうど最近登録したLAPRAS(GithubやTwitterなどからクローリングした情報をまとめてポートフォリオにしてくれるサービス)のbeta版機能として連携できるようになっていて知りました。
個人で使っているPCのVSCodeにだけ導入しておけば、完全に個人でコーディングしている時間を集計できるのが良さげです。
インストール&amp;amp;セットアップ サイトからgithubでサインアップ settingsにあるSecret API Keyをコピーしておく VSCodeの拡張機能でwakatimeをインストール インストールが終わるとAPIKeyの入力を求められるのでペースト これだけです。ダッシュボードは割とリアルタイムに反映されるので、少しコードを触って見に行くと集計されてます。
どのリポジトリを触ったか、どの言語を触ったか、更にはデバッグしていた時間なども記録されてました。
profileに反映されるのは少し時間がかかりますが、少しすると表示され始めます:
（githubのProfileにバッジも置いてみた）
結論: 良さそう 最初は「ブログでもzennの記事書くときでも結構だらだらmdファイル触るし、触った言語比率とかそういうのpublicになるとちょっと恥ずかしいな〜」みたいな謎のプライド(？)で導入を悩んでいたんですが、公表するデータは制御できるし、最初から気軽な気持ちで導入しておけばよかったなと思いました。
サイト内でコーディング時間のゴールも設定できる&amp;amp;profileの草形式で自分の頑張りが見られるので、モチベーションアップに繋がりそうです。
(個人で触るコードのみの環境なのでサクッと導入しましたが、仕事上の守秘義務のあるコードを触る環境なんかに入れる時はセキュリティ的にちゃんと色々調べないといけないと思います。)</description>
    </item>
    
    <item>
      <title>Hugoを使用しているサイトでmermaidを記述できるようにする</title>
      <link>https://SawaTszm.github.io/post/use-mermaid-in-hugo-blog/</link>
      <pubDate>Wed, 14 Dec 2022 19:20:31 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/use-mermaid-in-hugo-blog/</guid>
      <description>最近読んだGoF本を記事としてまとめたくて、このサイト内でmermaidを記述したかったので組み込みました。その時の備忘録です。
※「エラーを出さずに動くようにする」をメインに進めていったので、「こっちの方がいい」「これやらない方がいい」等もあるかもです。適宜読み替えて実施してください。
手順 mermaidのUNPKGから、mermaild.min.jsとmermaild.min.js.mapをダウンロードする static/jsあたりに取得した2つのファイルを置く 適宜リネームしてください。私はVersion情報を入れてmermaild.min.9.2.jsにしました layouts/shortcodes/mermaid.htmlを作成する。 &amp;lt;script src=&amp;#34;{{&amp;#34;js/mermaid.min.9.2.js&amp;#34; | relURL}}&amp;#34; defer&amp;gt;&amp;lt;/script&amp;gt; &amp;lt;div class=&amp;#34;mermaid&amp;#34; align=&amp;#34;{{ if .Get &amp;#34;align&amp;#34; }}{{ .Get &amp;#34;align&amp;#34; }}{{ else }}center{{ end }}&amp;#34;&amp;gt; {{ safeHTML .Inner }} &amp;lt;/div&amp;gt; (ローカルで確認するときは)ビルド＆devサーバ立ち上げ 記事内に{{&amp;lt;mermaid&amp;gt;}} mermaidの記述 {{&amp;lt; /mermaid &amp;gt;}}と記述することで、図として表示されるようになります。 結果 これは試しに入れてみた公式ドキュメントの例:
(ダークモードだとちょっと見づらいかも)
sequenceDiagram participant Alice participant Bob Alice-&gt;&gt;John: Hello John, how are you? loop Healthcheck John-&gt;&gt;John: Fight against hypochondria end Note right of John: Rational thoughts prevail! John--&gt;&gt;Alice: Great! John-&gt;&gt;Bob: How about you?</description>
    </item>
    
    <item>
      <title>VSCodeで開いているファイルをgithubで表示する</title>
      <link>https://SawaTszm.github.io/post/get-code-url-viewing-in-vscode/</link>
      <pubDate>Wed, 02 Nov 2022 11:27:17 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/get-code-url-viewing-in-vscode/</guid>
      <description>前置き 今更何を言っているんだ感が凄まじいんですが、最近「ここ見たらわかりやすいですよ」とファイルのURL（できればgithub上の）を投げたい事があって、VScodeでファイル探す→githubのURLに直して渡すの流れが億劫だった（絶対VSCode上で出来るだろうにその時テンパってて見つけられなかった）のを真面目に探したら数分で発見したので備忘録として書いておきます。
結論 拡張機能：GitLensのコマンドで出来ます。
GitLens: Open File on Remote # ブラウザで開く GitLens: Copy Remote File Url # URLコピーする(便利) コマンドを実行する前に範囲選択しておくと、その行が選択された状態のURLになります。便利だ……。
反省 「不便だな」と思ったことを手数で誤魔化してそのままにしないこと。</description>
    </item>
    
    <item>
      <title>日記 2022-09-15</title>
      <link>https://SawaTszm.github.io/post/diary-2022-09-15/</link>
      <pubDate>Thu, 15 Sep 2022 21:36:09 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2022-09-15/</guid>
      <description></description>
    </item>
    
    <item>
      <title>TOEICを受けてきました</title>
      <link>https://SawaTszm.github.io/post/diary-2022-09-13/</link>
      <pubDate>Tue, 13 Sep 2022 19:07:16 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2022-09-13/</guid>
      <description></description>
    </item>
    
    <item>
      <title>日記(2022/06/25)</title>
      <link>https://SawaTszm.github.io/post/diary-2022-06-25/</link>
      <pubDate>Sat, 25 Jun 2022 13:08:08 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2022-06-25/</guid>
      <description></description>
    </item>
    
    <item>
      <title>気をつけるべきだなと思ったこと</title>
      <link>https://SawaTszm.github.io/post/things-to-watch-out-for/</link>
      <pubDate>Thu, 23 Jun 2022 21:29:26 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/things-to-watch-out-for/</guid>
      <description></description>
    </item>
    
    <item>
      <title>[TIL] display: contents;</title>
      <link>https://SawaTszm.github.io/post/css-display-contents/</link>
      <pubDate>Mon, 20 Jun 2022 19:54:19 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/css-display-contents/</guid>
      <description></description>
    </item>
    
    <item>
      <title>基本情報に受かりました</title>
      <link>https://SawaTszm.github.io/post/diary-2021-05-16/</link>
      <pubDate>Mon, 16 May 2022 21:41:51 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2021-05-16/</guid>
      <description></description>
    </item>
    
    <item>
      <title>docker for Macが更新できない</title>
      <link>https://SawaTszm.github.io/post/docker-for-mac-does-not-work/</link>
      <pubDate>Mon, 10 Jan 2022 12:45:25 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/docker-for-mac-does-not-work/</guid>
      <description></description>
    </item>
    
    <item>
      <title>初めてのOSS Contribute【First Contributions編】</title>
      <link>https://SawaTszm.github.io/post/first-oss-contributions/</link>
      <pubDate>Wed, 05 Jan 2022 20:34:34 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/first-oss-contributions/</guid>
      <description>https://firstcontributions.github.io/
Make your first open source contribution in 5 minutes.
君も5分でOSSコントリビューターだ！(意訳)
「OSS活動への貢献してみたいけど、まずどうすれば良いのかよくわからないな」と思って調べていた時に発見した上記のありがたいプロジェクトで、OSSコントリビュータデビューさせてもらった時の備忘録です。
OSSにPR出してみたいけどぶっつけ本番は緊張する、貢献したいOSSとかまだあんまり決まってない(けどやりたいとは思ってる)人がもしいれば、このプロジェクトの胸を借りることをお勧めします。
流れのまとめ First ContributionsのリポジトリでPRを出す流れを体験させてもらう サイトのプロジェクトリストを参考に作業するリポジトリを探す ↑のREADMEやContribute.mdなどでルールを確認(大事) 1.の要領でPRを作成、修正、マージ PRの手順 基本的にはリポジトリのREADMEに沿って進めるだけです。5分もかかりませんでした。
(様々な言語で翻訳されていて、コミュニティの大きさを感じます)
簡単な手順は以下の通り。
リポジトリをフォーク フォークしたリポジトリをクローンしてくる ブランチを作成 コードを変更してコミット Push PRを送る(githubで自分のリポジトリに行くとCompare &amp;amp; pull requestボタンが表示される) これで完了です！
記念すべき人生初OSSコミットがこちら
練習が終わったら本番 PRを出すまでの流れを実際に体験できたので、いよいよ他のOSSにPR出していくぞ！という流れなのですが、貢献したいコミュニティが最初から決まっている場合を除くとどこのリポジトリにどういう作業をさせてもらおうか悩む、というか目星をつけられなくて困ると思います。少なくとも私は困りました。
ですがその辺りもFirst Contributionsはカバーしてくれていて、ネクストステップとして取り組みやすいプロジェクトのリストを用意してくれています。(一番最初に貼ったURLと同じです)
https://firstcontributions.github.io/
ここで自分で使っている言語や諸々で絞り込んで、気になったリポジトリのissue等を見ていくと、すぐに取り組めるタスクがあったりします。
(もしくは実際に使ってみて、気になる箇所があればissueやそれに対するPRを立てたりもできます)
私の場合は、興味があったリポジトリに誰でも取り組んで良い「ファイルごとのテストカバレッジを100%にする」issueが立っていたのでそれに着手しました。
大体のリポジトリはREADMEやContribute.mdなどに貢献の方法やルールが明記されているのでまずはそれを見て、しっかりそれらを守りつつ作業することを心がけましょう(自戒)。
記念すべき人生二度目OSSコミットがこちら
余談 OSSコントリビューションというと花形のPRに目が行きがちですが、issueでのエラー報告も立派な貢献になるみたいです。言われてみれば確かに、実装中エラーに当たった時OSSのissueにはいつもお世話になってます。 カタカナ表記の場合、リポジトリ派閥とレポジトリ派閥があることに気がつきました。IT用語辞典などでも併記されているので、完全に好みの問題みたいです。 軽い気持ちでやったFirst Contributionsさんのお試しPRでしたが、大きな声では言えないですがこれひとつでfindyさんの偏差値が結構上がりました（！）。OSSへの貢献はエンジニアのハードルの一つなのかも知れないですね。 </description>
    </item>
    
    <item>
      <title>2021 08 05 Diary</title>
      <link>https://SawaTszm.github.io/post/diary-2021-08-05/</link>
      <pubDate>Thu, 05 Aug 2021 21:26:58 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2021-08-05/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【Python】フォーマット済み文字列リテラル</title>
      <link>https://SawaTszm.github.io/post/python-%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88%E6%B8%88%E3%81%BF%E6%96%87%E5%AD%97%E5%88%97%E3%83%AA%E3%83%86%E3%83%A9%E3%83%AB/</link>
      <pubDate>Mon, 02 Aug 2021 18:52:08 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/python-%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88%E6%B8%88%E3%81%BF%E6%96%87%E5%AD%97%E5%88%97%E3%83%AA%E3%83%86%E3%83%A9%E3%83%AB/</guid>
      <description>目的 すごく今更&amp;amp;簡潔にだけど、python3.6以降で利用できる文字列フォーマットについてまとめていきます。
（ずっとstr.format()を使っていたので戒めも兼ねて）。
フォーマット済み文字列リテラルとは フォーマット済み文字列リテラル(f-string)では、文字列の先頭にfを付けることで、pythonの式を文字列内に{式}の形で埋め込むことができます。
従来の書き方よりも簡潔、かつわかりやすく記述することができる書き方です。
公式ドキュメント
使い方 変数に入った数字を3文字のカンマ区切りにする hoge = 99999999 # 従来のstr.format() print(&amp;#34;{:,}&amp;#34;.format(hoge)) # フォーマット済み文字列リテラル print(f&amp;#34;{hoge:,d}&amp;#34;) :の後ろに整数をつけて縦を揃える tokuten = {&amp;#34;kokugo&amp;#34;: 9, &amp;#34;sugaku&amp;#34;: 81, &amp;#34;eigo&amp;#34;: 100} for sub, point in tokuten.items(): print(f&amp;#39;{sub:10} ==&amp;gt; {point:5d}&amp;#39;) # kokugo ==&amp;gt; 9 # sugaku ==&amp;gt; 81 # eigo ==&amp;gt; 100 まとめ 従来のstr.format()と比べると、f-stringは最終結果が人の目で見てもわかりやすいですね。</description>
    </item>
    
    <item>
      <title>Lodashの概要と関数まとめ</title>
      <link>https://SawaTszm.github.io/post/javascript-lodash/</link>
      <pubDate>Sat, 17 Jul 2021 11:11:15 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/javascript-lodash/</guid>
      <description>lodashとは The Lodash library exported as a UMD module.
(中略) &amp;hellip;Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc.
配列、数値、オブジェクト、文字列など、値を扱う際に便利な関数を多く提供しているJavaspriptのライブラリです。
_.getや_.eachなどがそれ。
公式ドキュメントがすごくわかりやすくていい感じです。
lodash - github
公式ドキュメント
使い方 インポート import _ from &amp;#39;lodash&amp;#39;; 関数 _.get() _.get(object, path, [defaultValue]) objectのpathの値を取得する。値を解決できなかった場合、defaultValueを返す。
_.has() _.has(object, path) objectのpathの値が存在するかを調べる。値自体は返さない。
_.set() _.set(object, path, value) objectのpathにvalueの値をセットする。
pathが定義されていない場合は新しく作られる。
インデックスのプロパティがない場合は配列が作成され、それ以外のプロパティがない場合はオブジェクトが作成される。(？)
_.each() -&amp;gt; forEach() _.forEach(collection, [iteratee=_.identity]) collectionの要素を反復し、各要素に対してiterateeを実行。
iterateeは3つの引数(value, index|key, collection)で呼び出される。
※iteratee関数は明示的にfalseを返すことで反復を終わらせることができる
_.flatten() _.flatten(array) arrayを一段分フラットにする。非破壊的メソッド。</description>
    </item>
    
    <item>
      <title>【AWS SAM】テンプレートでCloudWatchイベントを記述する</title>
      <link>https://SawaTszm.github.io/post/aws-sam-template/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/aws-sam-template/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【DDD】前提知識まとめ</title>
      <link>https://SawaTszm.github.io/post/ddd-%E5%89%8D%E6%8F%90%E7%9F%A5%E8%AD%98%E3%81%BE%E3%81%A8%E3%82%81/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/ddd-%E5%89%8D%E6%8F%90%E7%9F%A5%E8%AD%98%E3%81%BE%E3%81%A8%E3%82%81/</guid>
      <description>目的 社内お勉強会で DDD 本を輪読することになったんですが、
改めて「〇〇ってわかりますか？」と言われると戸惑ってしまうことが多いので自分用にまとめました。
抽象クラス(abstract class) 他のクラスで継承してもらうことを前提としたクラス。
複数のクラスの共通処理の中に、一部異なる処理を使用したい場合などに定義する。
抽象クラス自体はインスタンス化できない abstract functionで抽象メソッドを定義できる インターフェース クラスが実装するメソッドを定義することができるもの。
メソッドの実体は持てない(定義のみ) 使用できる修飾子はpublicのみ 定数を持てる。実装先のクラスでのオーバーライドはできない
不特定のクラスで、共通のメソッドを定義したい場合などに定義する。 ポリモーフィズム 「中に入るものによって、同じ関数でも違う処理を行える」というオブジェクト指向プログラミングの特徴のこと。
「モノが「そのモノ」らしく振る舞うこと」 =「呼び出した関数が、呼び出し元のオブジェクトに適した振る舞いをすること」
# 動物は必ず「鳴く」 interface Animal { sound(); } # 犬は「動物らしい振る舞い」をする(鳴く) class dog implements Animal { sound() { /**/ } } # 動物は「鳴く」ので、引数の動物ごとの異なる鳴き声を処理する # 引数で与えられる動物によって、異なる処理(鳴き声)ができる public function animalsound(animal) { animal.sound() } 継承 親クラスの振る舞いを引き継いで、子クラスを実装すること。 子クラス側で親クラスを拡張することができる。
委譲 実際の振る舞いを別のオブジェクトに委ねることで、別のオブジェクトの振る舞いを再利用する手法。(？)
カプセル化 関連のあるデータとその使い方を一まとめにしたもの。 内部のデータを直接いじることはさせずに、使い方だけを見せる。
GoF デザインパターン 23 種類あるヤツ(雑)
勉強します
3 分でわかるデザインパターン入門
SOLID 原則 SOLID 原則とは Robert C.</description>
    </item>
    
    <item>
      <title>【Docker】【nginx】docker-compose上のnginxをhttps対応する(開発環境編)</title>
      <link>https://SawaTszm.github.io/post/docker-nginx-ssl-on-server/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/docker-nginx-ssl-on-server/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【Embulk】インストール＆dynamoDBのインポートを試してみる</title>
      <link>https://SawaTszm.github.io/post/embulk-install-and-dynamodb-import/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/embulk-install-and-dynamodb-import/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【laravel-admin】インストール＆画面作成まで 編</title>
      <link>https://SawaTszm.github.io/post/laravel-admin-install/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/laravel-admin-install/</guid>
      <description>目的 ここ最近、しばらくlaravel-adminという管理画面を作成するためのライブラリを使っていたので、調べたことやつまづいたところも含めて少しずつ書き起こそうと思います。
まずはインストール編です。簡単に管理画面を確認できるところまで見ていきましょう。
laravel-adminとは laravelで簡単にDBの管理画面を作成することができるライブラリです。
ドキュメントやデモサイトなど使用するために必要な資料が充実しており、難しいカスタムを行う必要がなければものすごく簡単に管理画面が構築できます。
Laravel-admin(ドキュメント)
GitHubページ
基本的な使用方法は上記でカバーし、カスタマイズして使用したい際には直接ソースコードを読んで適宜書き換えていく形になります。
主観ですが、コード内のコメントも(おそらく書き換える前提の部分は)丁寧に書かれているので、しっかり読み解けば問題ないかと思います。
プロジェクトの作成 既に開発しているlaravelプロジェクトに追加する場合は、この章は飛ばしてもらって大丈夫です。
何もないところからlaravel-adminを試したい方は、まずlaravelプロジェクトを作成するところから始めましょう。
公式によると、現在のバージョンでは以下の環境が推奨されるようです。
PHP 7+ laravel 5.5+ This package requires PHP 7+ and Laravel 5.5, for old versions please refer to 1.4
laravel-admin install
$composer create-project --prefer-dist &amp;#34;laravel/laravel=5.5.*&amp;#34; &amp;lt;project-name&amp;gt; DBも必要になってくるので、.envにDBの情報も書き足しておきましょう。
よければこちらの記事も参考にしてみてください。
【Laravel+MySQL+nginx】docker-composeで最小構成の環境構築 - SawaLog
インストール laravelの準備ができたら早速laravel-adminをインストールします。
$composer require encore/laravel-admin インストールが終わったら下記コマンドを実行します。
$php artisan vendor:publish --provider=&amp;#34;Encore\Admin\AdminServiceProvider&amp;#34; $php artisan admin:install これらを実行すると、app/Adminディレクトリが作られます。これからの実装はこのディレクトリ配下で行うことになります。
ファイルの初期配置は以下。
app/Admin ├── Controllers │ ├── ExampleController.php │ └── HomeController.php ├── bootstrap.</description>
    </item>
    
    <item>
      <title>【Laravel】Laravelで使用するDBををReadWrite構成にする時の確認でちょっとハマった話</title>
      <link>https://SawaTszm.github.io/post/laravel%E3%81%A7%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8Bdb%E3%82%92%E3%82%92readwrite%E6%A7%8B%E6%88%90%E3%81%AB%E3%81%99%E3%82%8B%E6%99%82%E3%81%AB%E3%81%A1%E3%82%87%E3%81%A3%E3%81%A8%E3%83%8F%E3%83%9E%E3%81%A3%E3%81%9F%E8%A9%B1/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/laravel%E3%81%A7%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8Bdb%E3%82%92%E3%82%92readwrite%E6%A7%8B%E6%88%90%E3%81%AB%E3%81%99%E3%82%8B%E6%99%82%E3%81%AB%E3%81%A1%E3%82%87%E3%81%A3%E3%81%A8%E3%83%8F%E3%83%9E%E3%81%A3%E3%81%9F%E8%A9%B1/</guid>
      <description>起こった問題 タイトルの通り、Laravelで使用するDBのhostをRead/Weiteで切り替えたい、と思って設定をしていました。
設定後下記を確認して、
&amp;gt;&amp;gt;&amp;gt; config(&amp;#39;database.connections.pgsql&amp;#39;) =&amp;gt; [ &amp;#34;read&amp;#34; =&amp;gt; [ &amp;#34;host&amp;#34; =&amp;gt; [ &amp;#34;postgres2&amp;#34;, ], ], &amp;#34;write&amp;#34; =&amp;gt; [ &amp;#34;host&amp;#34; =&amp;gt; &amp;#34;postgres&amp;#34;, ], ... 反映されてるな、と思って念の為connectionも見てみました。
&amp;gt;&amp;gt;&amp;gt; DB::connection(&amp;#39;pgsql::read&amp;#39;)-&amp;gt;getConfig(); =&amp;gt; [ ..., &amp;#34;host&amp;#34; =&amp;gt; &amp;#34;postgres&amp;#34;, ] ……あれ？
Readコネクションなのでpostgres2であって欲しいのに、postgresが出てきてしまいました。
反映されてないのかな？と思い色々調べたので、備忘録として置いて起きます。
調べたこと getConfigで参照されるconfigは、
Illuminate\Database\Connectors\ConnectionFactory::make内で、
/** * Establish a PDO connection based on the configuration. * * @param array $config * @param string|null $name * @return \Illuminate\Database\Connection */ public function make(array $config, $name = null) { $config = $this-&amp;gt;parseConfig($config, $name); if (isset($config[&amp;#39;read&amp;#39;])) { return $this-&amp;gt;createReadWriteConnection($config); } return $this-&amp;gt;createSingleConnection($config); } createReadWriteConnectionが呼び出され、</description>
    </item>
    
    <item>
      <title>【Laravel】フォームリクエストでのバリデーションに条件付きの制約を追加する</title>
      <link>https://SawaTszm.github.io/post/laravel-%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%A7%E3%81%AE%E3%83%90%E3%83%AA%E3%83%87%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E6%9D%A1%E4%BB%B6%E4%BB%98%E3%81%8D%E3%81%AE%E5%88%B6%E7%B4%84%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/laravel-%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%A7%E3%81%AE%E3%83%90%E3%83%AA%E3%83%87%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E6%9D%A1%E4%BB%B6%E4%BB%98%E3%81%8D%E3%81%AE%E5%88%B6%E7%B4%84%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【Laravel】独自ペジネータで自前のCollectionを使う</title>
      <link>https://SawaTszm.github.io/post/laravel-%E7%8B%AC%E8%87%AA%E3%83%9A%E3%82%B8%E3%83%8D%E3%83%BC%E3%82%BF%E3%81%A7%E8%87%AA%E5%89%8D%E3%81%AEcollection%E3%82%92%E4%BD%BF%E3%81%86/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/laravel-%E7%8B%AC%E8%87%AA%E3%83%9A%E3%82%B8%E3%83%8D%E3%83%BC%E3%82%BF%E3%81%A7%E8%87%AA%E5%89%8D%E3%81%AEcollection%E3%82%92%E4%BD%BF%E3%81%86/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【Laravel&#43;MySQL&#43;nginx】docker-composeで最小構成の環境構築</title>
      <link>https://SawaTszm.github.io/post/laravel&#43;mysql&#43;nginx-docker-compose%E3%81%A7%E6%9C%80%E5%B0%8F%E6%A7%8B%E6%88%90%E3%81%AE%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/laravel&#43;mysql&#43;nginx-docker-compose%E3%81%A7%E6%9C%80%E5%B0%8F%E6%A7%8B%E6%88%90%E3%81%AE%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89/</guid>
      <description>目的 laravel-admin使いたいだけの用途にLaradockは重すぎる……
ので、お勉強も兼ねて、docker-composeでLaravel&amp;amp;MySQLのみの環境を立てました。
その上でlaravel-adminの管理画面まで開けるようにしてみます。
構成 project_root_dir ├── docker-compose.yml ├── docker │ ├── nginx │ │ ├── Dockerfile │ │ └── default.conf │ ├── php │ │ └── Dockerfile │ └── db │ │ ├── my.cnf │ └── Dockerfile └── laravel └── ... 手順 docker-compose.ymlを作成 # docker-compose.yml version: &amp;#34;3.5&amp;#34; services: app: build: context: . dockerfile: ./docker/php/Dockerfile args: PROJECT_NAME: app_admin volumes: - ./:/var/www/html depends_on: - database links: - database ports: - &amp;#34;4000:80&amp;#34; - &amp;#34;4001:8080&amp;#34; tty: true database: image: mysql:5.</description>
    </item>
    
    <item>
      <title>【MySQL】外部キー追加時にエラー</title>
      <link>https://SawaTszm.github.io/post/mysql-%E5%A4%96%E9%83%A8%E3%82%AD%E3%83%BC%E8%BF%BD%E5%8A%A0%E6%99%82%E3%81%AB%E3%82%A8%E3%83%A9%E3%83%BC/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/mysql-%E5%A4%96%E9%83%A8%E3%82%AD%E3%83%BC%E8%BF%BD%E5%8A%A0%E6%99%82%E3%81%AB%E3%82%A8%E3%83%A9%E3%83%BC/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【Python】cerberusまとめ</title>
      <link>https://SawaTszm.github.io/post/python-summary-of-cerberus/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/python-summary-of-cerberus/</guid>
      <description>cerberusとは CERBERUS, n. The watch-dog of Hades, whose duty it was to guard the entrance; everybody, sooner or later, had to go there, and nobody wanted to carry off the entrance. - Ambrose Bierce, The Devil’s Dictionary
ケルベロスはシンプルで軽量なデータ検証機能を提供するパッケージです。
公式曰く、拡張も容易なため、カスタム検証も可能です。
(以下、9割公式のドキュメントの翻訳です)
概要 検証用のスキーマを定義し、それを Validator クラスのインスタンスに渡します。
schma = {&amp;#39;name&amp;#39;: {&amp;#39;type&amp;#39;: &amp;#39;string&amp;#39;}} v = Validator(schema) 次に、validate()を呼び出すことで、簡単にスキーマと辞書を検証できます。
検証が成功すると True が返されます。
document = {&amp;#39;name&amp;#39;: &amp;#39;john doe&amp;#39;} v.validate(document) # True インストール 安定バージョンはpipから取得できます。
pip install cerberus
使い方 基本的な使い方 # 概要の通り。スキーマを定義し、Validatorクラスに渡して検証する。 &amp;gt;&amp;gt;&amp;gt; from cerberus import Validator &amp;gt;&amp;gt;&amp;gt; schema = {&amp;#39;name&amp;#39;: {&amp;#39;type&amp;#39;: &amp;#39;string&amp;#39;}} &amp;gt;&amp;gt;&amp;gt; v = Validator(schema) &amp;gt;&amp;gt;&amp;gt; document = {&amp;#39;name&amp;#39;: &amp;#39;john doe&amp;#39;} &amp;gt;&amp;gt;&amp;gt; v.</description>
    </item>
    
    <item>
      <title>【Python】poetryを試してみる</title>
      <link>https://SawaTszm.github.io/post/python-try-poetry/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/python-try-poetry/</guid>
      <description>poetryとは pythonの環境管理ツールです。
機能としてはpipenvに近い感じでした。
本当に触りだけやってみたリポジトリはこちら。
sample-poetry
インストール $pip install poetry プロジェクトを作る $poetry new sample-project 実行すると下記のファイル・フォルダが作成されます。
sample-project ├── README.rst ├── pyproject.toml ├── sample_project │ └── __init__.py └── tests ├── __init__.py └── test_sample_project.py モジュールの追加 $cd sample-project # pyproject.tomlがある階層で $poetry add [--dev] &amp;lt;package name&amp;gt; これでpoetryが管理している仮想環境内にモジュールが追加されます。
それに伴って、ファイルと依存関係を管理する pyproject.tomlとpoetry.lock が作成されます。
Remove Deoendency $poetry remove &amp;lt;package name&amp;gt; This is very simple :)
Use Virtual Environment # not active $poetry run python -m pytest # active $poetry shell Use Exsting Environment $poetry install [--no-dev] Reference Poetry - Python dependency management and packaging made easy.</description>
    </item>
    
    <item>
      <title>【Python】エラーについて</title>
      <link>https://SawaTszm.github.io/post/python-about-error/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/python-about-error/</guid>
      <description>知りたかったこと try-catch の有効範囲はどれくらいなのか(呼び出した関数で起きたエラーも拾えるのか) ネストしたエラーの扱いってどうするのが良いんだろう 結論 呼び出された先の例外もキャッチできますφ(･･
調べて知ったこと エラーには構文エラーと例外がある 複数の例外を指定することができる except (RuntimeError, TypeError, NameError): pass exceptは上から順に見て、引っかかったタイミングでそのexcept節内部のみを実行する 最後の except 節では例外名を省いて、ワイルドカードにすることができる しかし、ワイルドカードの except 節は通常のプログラムエラーをたやすく隠してしまうため、注意は必要 Try…exceptの中にはelse節を設けることができる。else節は全てのexcept節よりも後ろに置く try 節で全く例外が創出されなかった時に実行されるコードを記述することができる for arg in sys.argv[1:]: try: f = open(arg, &amp;#39;r&amp;#39;) except OSError: print(&amp;#39;cannot open&amp;#39;, arg) else: print(arg, &amp;#39;has&amp;#39;, len(f.readlines()), &amp;#39;lines&amp;#39;) f.close() 参考：
Python の例外処理（try, except, else, finally） | note.nkmk.me
8. エラーと例外 — Python 3.8.1 ドキュメント
Except 節では例外名の後に変数を指定できる。この変数は例外インスタンスに結び付けられ、instance.argsに例外インスタンス生成時の引数が入る。
例外インスタンスに実装されている__str__はinstance.argsをわざわざ出力しなくても見られるようになっているので、print(inst)で見られる。便利。 例外ハンドラは、try 節の直下で発生した例外を処理するだけではなく、その try 節から(たとえ間接的にでも)呼び出された関数の内部で発生した例外も処理する。(！)
def this_fails(): ... x = 1/0 .</description>
    </item>
    
    <item>
      <title>【Pytyon】リストの重複要素をカウントする</title>
      <link>https://SawaTszm.github.io/post/pytyon-%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AE%E9%87%8D%E8%A4%87%E8%A6%81%E7%B4%A0%E3%82%92%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%99%E3%82%8B/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/pytyon-%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AE%E9%87%8D%E8%A4%87%E8%A6%81%E7%B4%A0%E3%82%92%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%99%E3%82%8B/</guid>
      <description>目的 投票結果を DB に貯めて、その結果を一位から取得したい。
DB 構成は、
Id Recipe int str というシンプルな感じです。
ここからレコードの recipe の値を、[a, b, c, b, ...]と言ったリストに直した際、
「一番投票数の多かったもの」や「投票数が多かった順の要素のリスト」が欲しい。
TL;DR collectionsを使えば比較的簡単にできます。
要素のカウントは collections が便利 import collections votes_list = [a, b, c, b] c = collections.Counter(votes_list) # Counter({&amp;#39;b&amp;#39;: 2, &amp;#39;a&amp;#39;: 1, &amp;#39;c&amp;#39;: 1}) # `要素`: `出現回数` recipe = c.most_common() # [(&amp;#39;b&amp;#39;, 2), (&amp;#39;a&amp;#39;, 1), (&amp;#39;c&amp;#39;, 1)] # 出現回数が多い順に並べ替えてくれる recipe = c.most_common()[0][0] # b 参考にさせていただいたもの お世話になりました。
collections — コンテナデータ型 — Python 3.8.1 ドキュメント</description>
    </item>
    
    <item>
      <title>【Redis】ってなんぞや</title>
      <link>https://SawaTszm.github.io/post/summary-of-redis/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/summary-of-redis/</guid>
      <description>目的 案件で触らせてもらうことになったぜ
何もわからないぜ
という状態なので、自分が調べたことについてまとめておきます。
Radis とは REmote DIctionary Serverの略 読んで字の如く、ネットワーク接続されたKey-Value型のNoSQLデータベース 永続化可能なインメモリデータベース オープンソースのプロジェクトで、Redis Labsがスポンサー。中身はC言語 AWS上でもRedis-serverが提供されている 様々なデータ構造をサポートしている STRING LIST SET HASH ZSET (ソート済みのset) 補足：インメモリDB すべてのデータをコンピュータのメインメモリ上に展開しながら動作する仕組みのことです。
コンピュータ(サーバ)の電源が落ちれば消えてしまうので、永続化の手段としてデータを別途どこかに保存することがあります。
インメモリデータベースでサーバが落ちたらデータはどうなる？ インメモリとカラム型データベースの可能性を調べる（その3） － Publickey
インストールと動作確認 少し挙動を試してみたいだけなら、公式チュートリアルの画面でコマンドを叩くことができます。
Try Redis
Macであれば下記brewコマンドで一発。
$brew install Redis インストールできたら、サーバを立ち上げてみます。
$ redis-server # 立ち上がったら別のタブで動作確認 $ redis-cli 127.0.0.1:6379&amp;gt; set test &amp;#34;hoge&amp;#34; OK 127.0.0.1:6379&amp;gt; get test &amp;#34;hoge&amp;#34; 動作確認までできました。
このコマンドを叩く先のredis-serverがローカルにあるかAWS上のサービスとしてあるかが変わってくるだけで、cli側の設定や叩き方は基本的に変わりません。
(PythonなんかでRedisクライアントを作成する時に指すHOSTが変わってくるくらい、の認識です)
データのタイプ Redisは前述の通り様々なデータタイプに対応しています。
どのデータタイプを使用するかによって、コマンドやデータの指定方法が違ってきます。
コマンドの詳細などは公式ドキュメントで。
Data types – Redis
Strings 最も基本的な、KeyとValueが1:1な構造。
Key = valueの形。
バイナリセーフ(JPEG画像やシリアル化されたRubyオブジェクトなども格納可能) 最大512MBまで 127.</description>
    </item>
    
    <item>
      <title>Killedと言われないためにDockerのメモリ割り当てを増やす</title>
      <link>https://SawaTszm.github.io/post/increase-memory-allocation-of-docker-to-avoid-killed/</link>
      <pubDate>Fri, 19 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/increase-memory-allocation-of-docker-to-avoid-killed/</guid>
      <description></description>
    </item>
    
    <item>
      <title>2021 02 09-19 Diary</title>
      <link>https://SawaTszm.github.io/post/diary-2021-02-09/</link>
      <pubDate>Tue, 09 Feb 2021 14:11:32 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2021-02-09/</guid>
      <description></description>
    </item>
    
    <item>
      <title>2021 02 02 Diary</title>
      <link>https://SawaTszm.github.io/post/diary-2021-02-02/</link>
      <pubDate>Tue, 02 Feb 2021 12:01:46 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2021-02-02/</guid>
      <description></description>
    </item>
    
    <item>
      <title>2021 02 01 Diary</title>
      <link>https://SawaTszm.github.io/post/diary-2021-02-01/</link>
      <pubDate>Mon, 01 Feb 2021 11:06:43 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2021-02-01/</guid>
      <description></description>
    </item>
    
    <item>
      <title>【ディープリンク】ってなんぞや</title>
      <link>https://SawaTszm.github.io/post/summary-of-deep-link/</link>
      <pubDate>Thu, 28 Jan 2021 19:10:59 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/summary-of-deep-link/</guid>
      <description>目的 「LINEBOT くんのメッセージをタップしたらアプリに飛ぶようにしてほしい！」
という要件を貰ったけど、
そのあたり全く初見だったので調べてまとめてみました。
ディープリンクとは 任意のアプリに遷移できるリンク(URL)のことです。
アプリに遷移できるだけでなく、更にその中の特定の画面を指定して遷移することができます。
スマホでTwitterやYoutubeのリンクをタップした時に、アプリが立ち上がって見たかった投稿や動画を開いてくれることってありますよね？ あの仕組みのことです。
プラットフォームごとのディープリンク対応 プラットフォーム 種類 対応 URL Android App links Android6.0 以降 WebURL Android App Indexing Android WebURL Apple universal links iOS9 以降 WebURL どちらも Custom URL Scheme iOS,Android カスタム URL Android(Google) App Links App Linksはオープンソースのアプリ連携サービスです。Facebookが提供しています。
https:// から始まる URL を利用できます。
メリット WebURL から直接アプリを起動できる Android 特有のアプリ選択画面を飛ばせる デメリット 認証情報ファイルを https 通信可能なサーバに上げておく必要がある android 6.0(2015 年 10 月リリース)以降しか対応していない 設定方法 下記が参考になりました。
App Linksに対応してみた - Qiita
App Indexing App Indexingは、その名の通りアプリのコンテンツをインデックスして、Google検索の結果からアプリに直接遷移することができるサービスです。Googleが提供しています。</description>
    </item>
    
    <item>
      <title>2021-01-28 Diary</title>
      <link>https://SawaTszm.github.io/post/diary-2021-01-28/</link>
      <pubDate>Thu, 28 Jan 2021 14:20:35 +0900</pubDate>
      
      <guid>https://SawaTszm.github.io/post/diary-2021-01-28/</guid>
      <description></description>
    </item>
    
    
    <item>
      <title>About</title>
      <link>https://SawaTszm.github.io/page/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://SawaTszm.github.io/page/about/</guid>
      <description>welcome!</description>
    </item>
    
    <item>
      <title>Contact form</title>
      <link>https://SawaTszm.github.io/page/form/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://SawaTszm.github.io/page/form/</guid>
      <description>問い合わせ先 TwitterのDM、もしくはこちらのGoogleフォームよりお問い合わせください。</description>
    </item>
    
    <item>
      <title>Privacy Policy</title>
      <link>https://SawaTszm.github.io/page/privacy_policy/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://SawaTszm.github.io/page/privacy_policy/</guid>
      <description>当サイトに掲載されている広告について 当サイトでは、第三者配信の広告サービス（Googleアドセンス）を利用しています。
このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 『Cookie』(氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。
当サイトが使用しているアクセス解析ツールについて 当サイトでは、Googleによるアクセス解析ツール「Google Analytics」を利用しています。
このGoogle Analyticsはトラフィックデータの収集のためにCookieを使用しています。
このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくは下記をクリックしてご確認ください。
Terms of Service | Google Analytics - Google（Google アナリティクス利用規約） Google のサービスを使用するサイトやアプリから収集した情報の Google による使用 - ポリシーと規約 - Google 当サイトの免責事項について 当サイトで掲載している画像の著作権・肖像権等は各権利所有者に帰属致します。権利を侵害する目的ではございません。記事の内容や掲載画像等に問題がございましたら、各権利所有者様本人が、お問い合わせフォームよりご連絡下さい。確認後、対応させて頂きます。
当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。
当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。
当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。
プライバシーポリシーの変更について 当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。</description>
    </item>
    
    
  </channel>
</rss>