OmniAICreator/Qiita-1.07M huggingface dataset:
Azure AI Searchへのデータ取り込み時に画像をOCRしてベクトル化もしちゃう

Azure Cognitive SearchがAzure AI Searchにリブランドされ、AI機能に多くのアップデートがありました。
その中の一つに ***「データのインポートとベクター化」*** があります。
これは簡単に言うとデータをBlob Storageにおいておけば、生成AIアプリケーションには欠かせない「チャンク分割」と「ベクトル化」を自動で実行し、インデックスを作成してくれる機能です。

詳細な実施手順ついては既に解説されている記事があります。

https://qiita.com/tmiyata25/items/ef231ea340e681a44970

https://qiita.com/tmiyata25/items/3e9644b4e8346c13f619

本記事の内容も上記手順を実施したことを前提としています。

## 本題
上記の手順を自身の環境でも試している中で気になるチェックボックスを発見・・・
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206219/c80508ae-b4ad-f0dd-17e6-ed8610dff727.png)

> ドキュメントが画像ファイルであるか、埋め込み画像が含まれる場合は、それらの画像から抽出したテキストをドキュメントのテキスト コンテンツとマージできます。

PDFなどのドキュメントでところどころ画像が挿入されているケースは比較的多いと思います。
特に社内の手順書系のドキュメントは実際の内容はスクリーンショットがほとんどを占めるなんてこともありますよね。
この機能を使えばドキュメント内の画像をOCRし、前後のテキストデータと合わせて取り込み、チャンク分割、ベクトル化まで実施してくれるということです。

## 必要な手順
### Azure AI Serviceを作成しておく
本機能の実際の動きとしてはAzure AI Searchの「スキルセット」を使ってインデクサー実行時にAzure AI VisionのOCR機能を呼び出す形となります。
なので呼び出されるAzure AI Visionが利用できるようにリソースを作成しておく必要があります。

既存のAzure AI Visionの単体リソースではなく、最近追加されたマルチサービスリソース（単一のキー、エンドポイントで複数のAIサービスにアクセスできる）として作成する必要があります。

https://learn.microsoft.com/ja-jp/azure/ai-services/multi-service-resource?tabs=windows&pivots=azportal

## 日本語化対応
参考記事の（2/2）にもある通り、スキルセットの日本語化対応を実施します。
追加の対応として「Microsoft.Skills.Vision.OcrSkill」のdefaultLanguageCodeもenからjaに変更します。
```json
{
      "@odata.type": "#Microsoft.Skills.Vision.OcrSkill",
      "name": "#4",
      "description": null,
      "context": "/document/normalized_images/*",
      "textExtractionAlgorithm": null,
      "lineEnding": "Space",
      "defaultLanguageCode": "ja",
      "detectOrientation": true,
      "inputs": [
        {
          "name": "image",
          "source": "/document/normalized_images/*"
        }
      ],
      "outputs": [
        {
          "name": "text",
          "targetName": "text"
        }
      ]
    }
```
変更後はインデクサーのリセットと再実行を忘れずに

## 動作確認
まずは適当なテキストと画像が混じったPDFファイルを用意します。
ChatGPTにアメリカ、中国、日本の紹介を500字でしてもらいました。
そして日本の紹介文だけ画像化し、PDF化しました。

Githubにアップしておいたので検証の際はご利用ください。

https://github.com/Yosuke-Sakaue/country.pdf/blob/main/country.pdf

このファイルをデータソースとして登録したBlob Storageにアップロードし、インデクサーを実行します。
作成されたインデックスに対して検索をかけてみます。

まずはアメリカを検索しますが元々テキスト形式だったので問題なく検索できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206219/cc71425c-3567-ece6-6119-43786077ec0e.png)

次に日本について検索してみます。
画像だった内容がしっかりOCRされて検索できることが確認できました！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206219/5c5fb335-9713-52c3-ebbf-b36d6de95a91.png)

※余談
インデックスのクエリオプションで「検索結果でベクター値を非表示にする」にチェックを入れると検索結果がスッキリします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206219/ce3ace02-1bb4-18b5-0097-a79f219bac54.png)

## おわりに
データインポート時のOCR機能については元々Cognitive Search時代からスキルセットで設定することが可能でしたが、スキルセットの追加画面からJSON追加して設定するといったとっつきにくいものでした（そもそもインデクサーやスキルセットの概念を理解するのが大変だった、、）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206219/042ecb5b-6970-085d-8851-3a88e6ae17f4.png)

この辺りを単純に意識する必要が減ったというだけでも便利なったと感じますし、生成AIとの組み合わせ、RAGアプリケーションの構築を検討されている方には活用できる可能性がある機能だと思いました。
ただし、すべての画像がOCRしてテキスト抽出できるものではないと思いますので、引き続き社内のスクショだらけの手順書をどう生成AIと連携するかは課題になってくるでしょう。

以上、少しでも参考になれば幸いです。
17日目：What do different evaluation metrics tell us about saliency models?(2017)

### What do different evaluation metrics tell us about saliency models?(Zoya, 2017)

https://arxiv.org/pdf/1604.03605.pdf

#### 概要

この論文では、視覚的注目モデルの評価における異なる指標の分析が行われ、8つの評価メトリックに関する実験と視覚化を通じて、メトリックの挙動と特性が明らかにされています。異なるメトリックがモデルのランキングに影響を与え、それには偽陽性や偽陰性の取り扱い、視覚バイアスの考慮、空間的な逸脱の取り扱い、および注目マップの前処理が関与しています。著者らはこれらの差異に基づいて特定の前提やアプリケーションにおいてメトリックを選択するための勧告も提供しています。


#### この論文で議論されているさまざまな評価基準とは何ですか？また、顕著性モデルのランク付けにおいて、それらはどのように違うのですか？

この論文では、ROC曲線下面積（AUC）、シャッフルAUC（sAUC）、正規化スキャンパスサリエンシー（NSS）、ピアソンの相関係数（CC）、地球移動距離（EMD）、類似度またはヒストグラム交差（SIM）、カルバック・ライブラー発散（KL）、情報利得（IG）など、顕著性モデルの評価指標について説明しています。これらのメトリクスは、偽陽性と偽陰性をどのように扱うか、視聴バイアスを考慮するか、空間的偏差を考慮するか、顕著性マップをどのように前処理するかなどの様々な要因により、顕著性モデルをどのようにランク付けするかで異なります。

例えば、知覚に基づくランキングは、NSS、CC、SIMと密接に一致し、KLやEMDからは最も遠い。人間の知覚を駆動する特性は、顕著性の他のアプリケーションに望まれる特性とは異なる可能性がある。異なるモデルやメトリクスの基礎にある仮定をより注意深く考慮する必要があり、異なるメトリクスの動作や特性は、評価にどのメトリクスを使用するかの決定に入るべきである。

評価メトリックの選択は、顕著性がどのように定義され、どのようにグランドトゥルースが表現されるかに依存する。評価指標は、どのように顕著性モデルをランク付けするかで異なり、これは、偽陽性と偽陰性をどのように扱うか、視聴バイアスを考慮するかどうか、空間的偏差を考慮するかどうか、および顕著性マップをどのように前処理するかによって生じる。

要約すると、論文で議論されているさまざまな評価メトリクスは、さまざまな要因や仮定の扱いが異なるため、顕著性モデルをランク付けする方法に違いが生じます。これらの違いは、顕著性モデルを評価するために最も適切なメトリクスを選択する際に、メトリクスの特性と動作を注意深く考慮することの重要性を浮き彫りにしています。


#### 偽陽性と偽陰性は、顕著性モデルのランキングにどのような影響を与え、評価指標でどのように扱われるのか？

偽陽性と偽陰性は、評価基準でどのように扱われるかによって、異なる方法で顕著性モデルのランキングに影響を与える可能性がある。偽陽性は、顕著であると予測されたが、実際には顕著でない領域を指し、偽陰性は、実際には顕著であるが、そのように予測されなかった領域を指す。

評価指標によって、偽陽性と偽陰性の扱いは異なる。例えば、AUCやsAUCのような測定基準は偽陽性により敏感で、KLやIGのような測定基準は偽陰性により敏感です。NSSとCCは偽陽性と偽陰性の影響を受けにくいので、顕著性モデルを評価するためのよりロバストなメトリクスになります。

メトリクスが偽陰性をどの程度罰するかを直接比較するために、系統的なテストを行うことができる。例えば、25％、50％、75％の偽陰性によるスコアの低下を測定し、このスコアの変化を無限オブザーバー限界と偶然の間のスコア差で正規化することができる。この正規化されたスコアは、異なる測定基準が偽陰性をどのように罰するかを比較するために使用することができる。

要約すると、偽陽性と偽陰性は顕著性モデルのランキングに影響を与える可能性があり、評価メトリッ クによってその扱いが異なります。評価メトリクスで偽陽性と偽陰性がどのように扱われるかを理解することは、顕著性モデルの評価に最も適したメトリクスを選択するために重要です。


#### 特定の前提の下で、特定の用途のために、どのような指標の選択を推奨し、どのように実際のシナリオに適用できるのか。

この論文は、特定の前提の下で、特定のアプリケーションのためのメトリック選択の推奨を提供する。例えば、物体や動きの検出、監視、ローカライゼーションやマッピング、セグメンテーションなど、顕著性の検出アプリケーションには、AUC、KL、IGのようなメトリックが適切であろう。適応的な画像・動画圧縮やプログレッシブ伝送、コンテンツを意識した画像の再ターゲッティングやトリミング、レンダリングや可視化、コラージュ、芸術的なレンダリングなどのアプリケーションでは、NSSやSIMのようなメトリクスがより有用な評価を提供するでしょう。

これらの推奨は、特定のアプリケーションの仮定と要件を注意深く考慮し、顕著性モデルを評価するための最も適切なメトリックを選択することにより、実用的なシナリオに適用することができる。例えば、物体検出のための顕著性モデルを評価することが目的であれば、AUC、KL、IGを用いて、可能性のある物体位置の確率密度を生成し、見逃したターゲットにペナルティを与えるモデルの能力を評価することができる。一方、コンテンツを考慮した画像の再ターゲティングのために顕著性モデルを評価することが目的であれば、NSSやSIMを使用して、重要度や顕著性によって異なる画像領域をランク付けするモデルの能力を評価することができます。

要約すると、特定のアプリケーションの要件と目標を慎重に検討し、顕著性モデルを評価するための最も適切なメトリックを選択することにより、特定の前提条件の下で、特定のアプリケーションのためのメトリックの選択のための勧告は、実用的なシナリオに適用することができます。
【Rails】外部DB上の複合主キーを持つテーブルのデータ取得をしてみた

## はじめに
Rails6.1系を利用しているとある案件開発において、複合主キーを持つ外部DB上の中間テーブルを利用しつつデータ取得をしたいという場面に遭遇しました。

## 問題点
Rails7.1系であれば[複合主キーへの対応が進められている](https://railsguides.jp/active_record_composite_primary_keys.html)ようなのですが、
現在は利用しているのが6.1系という状況でありました。~~そんなぁ～(;´༎ຶД༎ຶ`)~~
[外部DBへの接続](https://qiita.com/TKY_study/items/b13ddd6bf62f8fcf5311)自体は成功しており、同様の設定によってデータ取得自体は出来たのですが、中間テーブルが絡むアクセスパターンにおいて以下のような警告が大量に出て煩わしいといった状況になっていました。

~~~
WARNING: Active Record does not support composite primary key.

USER_ROLE_MAPPER has composite primary key. Composite primary key is ignored.
~~~


## 解決方法
以下のように外部DB上のテーブルと対応付けたmodelを設定することでデータ取得時に利用する事が出来、また警告に関しては`self.primary_key = nil`を設定する事で表示させないようにすることが出来ました。


```ruby:app/models/external_test.rb
class ExternalUserRoleMapper < ApplicationExternalRecord
  self.primary_key = nil
  self.table_name = 'USER_ROLE_MAPPER'
  belongs_to :external_user, foreign_key: 'USER_ID'
  belongs_to :external_role, foreign_key: 'ROLE_ID'
end
```

## おわりに
今回はデータ取得のみ、アクセスパターンも極めて限定的で今後増える想定もない。といった状況でしたのでこのような対応に留めたのですが、主キーが絡む操作などが軒並み行えない状態となっています(例えば`find`や`last`メソッド等で例外となる)。そのため、一般的な利用パターンにおいては以下のような対応を検討した方が良いと考えられます。

- [composite_primary_keys gem](https://rubygems.org/gems/composite_primary_keys/versions/8.1.3)の導入
- Rails7.1系へのアップグレード


## 参考にさせて頂いた記事など
https://qiita.com/MasamotoMiyata/items/1523cdeb1a48ff7a21a2  

https://rubygems.org/gems/composite_primary_keys/versions/8.1.3  

https://railsguides.jp/active_record_composite_primary_keys.html
16日目：Reverse Attention for Salient Object Detection(2019)

### Reverse Attention for Salient Object Detection(Shuhan, 2019)

https://arxiv.org/pdf/1807.09940v2.pdf

コンパクト性を意識したモデルを取り上げる。注視マップを生成するというよりも注目するべきオブジェクトを抽出するモデル。

#### 概要

この論文では、深層学習技術の急速な発展により、顕著物体検出が進展している。しかし、埋め込みデバイスでの利用を妨げる低解像度と重いモデルの課題が残る。著者は、高精度かつコンパクトな深層ネットワークを提案し、逆注視を使用して顕著性物体検出を効率的に行う方法を示している。提案手法は、簡潔さ、効率性（45 FPS）、モデルサイズ（81 MB）の面で他の手法に優れていることが実験で示されている。

#### 提案手法

提案されたネットワークは、深い層で高レベルの意味情報を、浅い層で詳細な情報を取り込むために逆注意を使用し、残差学習を組み合わせて、効果的な物体検出を実現しています。VGG-16をバックボーンに持ち、提案されたネットワークのアーキテクチャはHEDに基づいています。逆アテンションは、上位からの消去を利用して物体領域を段階的に拡張し、提案された手法の効果的な性能を示しています。

逆アテンションを使用して物体の境界近くの空間的な詳細を捉え、視覚的な改良を達成します。深い監視が各サイド出力ステージに適用され、逆アテンションは深い層の確信度予測を消去し、ネットワークに不足しているオブジェクト領域と詳細を効果的に探索させます。他のネットワークとの違いには、逆アテンションネットワークやサイド出力残差ネットワークなどがあり、提案手法はこれらと異なる方法で逆アテンションを使用します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/df580b34-002e-12ec-9b3a-f80881815ab1.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/5d22a2cb-6431-347e-c8a2-483a63b9ae9d.png)


#### 結果

逆アテンションを用いた新しいアプローチを提案し、これにより顕著物体検出の性能が大幅に向上した。他の既存手法との比較では、提案手法が優れたF-measureとMAEスコアを示し、視覚的品質と効率の両面で優れていることが確認された。将来の研究では、手作業の顕著性事前情報とスクラッチからの学習を組み合わせ、ネットワークの冗長性を解消する方針が検討される。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/f8f7cc8e-4953-e781-5749-1126b5f3792c.png)


#### 結論
この論文では、逆アテンションを用いた新しいアプローチを提案し、これにより顕著物体検出の性能が大幅に向上した。他の既存手法との比較では、提案手法が優れたF-measureとMAEスコアを示し、視覚的品質と効率の両面で優れていることが確認された。将来の研究では、手作業の顕著性事前情報とスクラッチからの学習を組み合わせ、ネットワークの冗長性を解消する方針が検討される。
デザイン思考で考えるプロダクト提案

# はじめに
12/5　の ハッカソン・おかわりLT会!!で話していたデザイン思考のプロダクト提案について記事にします。
LT会では技育CAMPキャラバン名古屋で最優秀賞をいただいたプロダクト「簡単行列整理くん」を例にデザイン思考について話しました。

# デザイン思考の基礎となる考え方
## 5W1H で考える

| 5W1H  | 意味       |
| ----- | ---------- |
| when  | いつ       |
| where | どこで     |
| who   | 誰が       |
| what  | 何を       |
| why   | なぜ       |
| how   | どのように |

世の中に発生する全ての事象はこの 6 つの要素を考えられます
（抽象的に見ると一部が欠損している事象もある）
この考え方で出来事を言語化すると、より具体的で多角的な見方で物事を捉えられます

# デザイン思考について
### ユーザー中心のサービス

ユーザー中心にサービスを考える

-   体験中心の設計  
    → ユーザーがアプリを使う中で何を感じたのか、を最も重視する
-   ユーザーの使いやすさが第一  
    → 開発のしやすさよりもユーザーが使いやすいかを考える

### デザイン思考

**見えている課題** から **その根本にある課題** を見つけ出す  
より具体的な答えを得るためにはさまざまな課題を知るのが大事

簡単な方法

-   身近な課題を挙げる  
    → その課題を感じている人が近ければ近いほど、問題の本質が見える
-   多くの人が感じている課題を挙げる  
    → その課題が普遍的なものであれば、実際のケースを集めやすく、問題の本質が見える

### 課題を中心に考える

課題のある場所(where)、時間(when)、環境(why or what or how)にフォーカスして背景を見つける  
課題がユーザーの心情をどう変えるのかを考える

課題が起こる背景と解決しない原因を知って、解決方法を考える  
ユーザーの心情を知って、アプローチを考える  
（その課題は課題自体を解決しないといけないのか、それとも課題がユーザーに与える悪影響を排除すればいいのか）

## 抽象と具象で考える

課題の本質は抽象化して捉える  
その課題を言語化して共有する

この段階で課題を抽象化できなければアプローチを生み出すのが難しい
言語化できなければ、課題をなぜ解決しなければいけないのか、発表のときにアピールするのが難しい

## 解決策のプロトタイプで考える

実際に動く前に頭の中でふんわりとイメージするのではなく、言語化して、課題とそのアプローチをとりあえずで提案する

課題が提案されれば、他のメンバーが別の背景を考えて、新しいアプローチを思いつきますし、アプローチが提案されれば、その問題点が見えてきます

## 試行錯誤で考える

アイデアを一度出しただけではまとまりません  
何度も考えると別の視点が見えてくる、別の心情が見えてきます  

その思いついたアプローチの中で最も具体的で、効果的なものを最終的にアイデアとして決定します  

# 終わりに
今回はデザイン思考を使った物事の考え方について紹介しました。この考え方でアイデア出しをすれば、ユーザー目線でのプロダクト設計、ユーザー体験を意識した画面設計ができるようになると思います。

## 参考資料
METI DX：基礎から学ぶデジタルサービス研修「経済産業省が実施するデジタル・トランスフォーメーション（DX）研修」
https://www.youtube.com/watch?v=rNIteo1pNFU&list=PLcRmz7bR5W3lGaRiTTEGNs3BmliHgYdAB&index=1
https://www.youtube.com/watch?v=lTxTLRREXcw&list=PLcRmz7bR5W3lGaRiTTEGNs3BmliHgYdAB&index=2
15日目：Predicting Human Attention using Computational Attention(2023)

### Predicting Human Attention using Computational Attention(2023)

https://arxiv.org/pdf/2303.09383.pdf

2023年の最新の研究事例。Transformerをベースにしている。

#### 概要

HAT（Human Attention Transformer）は視覚的な注目を予測する新しいトランスフォーマーベースのモデルで、上向きと下向きの注意制御の両方を予測し、従来の手法を上回る性能を発揮します。HATの革新的なデザインと単純化された焦点網膜により、人間の動的な視覚作業メモリに似た空間的時間的な認識が可能です。HATは異なる注意制御タスクでSOTAの予測を達成し、注目の空間的および時間的割り当てを示す。データセットCOOC-Search18およびCOCO-FreeViewにおいて、HATはcNSSで83%、58%、72%の向上を達成した。これは、さまざまな注目を必要とするシナリオで人間の行動をより良く予測できる新しい注目モデルの開発を促す可能性があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/b2ebe1b3-0a17-ee58-4d2a-490e25d82778.png)

#### 主な貢献

1．人間の注意の空間的・時間的配分（固視スキャンパス）を予測するために、2つの異なる偏心位置の視覚情報を統合する新しい変換器アーキテクチャであるHATを提案する。

2. TP、TA、FV設定におけるSOTAスキャンパス予測によって実証されたように、我々のHATアーキテクチャが様々な注意制御タスクに幅広く適用できることを示す。また、HATによる人間の注意 人間の注意の予測は非常に解釈可能であることを示す。

3. 固定離散化の必要性を排除し スキャンパス予測を逐次的な高密度予測タスクとして定式化する。HATを高解像度入力に適用できるようにする。


#### モデルアーキテクチャ
HAT（Hierarchical Attentive Transformer）モデルによるスキャンパス予測の手法が紹介されています。エンコーダー,デコーダー,CNNを使用し、視覚的なタスクにおいて作業メモリを構築し、タスクごとに学習することで、精密なフィクセーションヒートマップ(注視点マップ)を生成します。HATは、従来の低い解像度のグリッド空間での離散的なフィクセーションを排除し、ピクセル座標の連続的な予測としてスキャンパス予測を行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/b6a62067-7a45-181e-7fe1-ca320094ca0e.png)


#### 実験結果
COCOのデータセットにしてHATとその他のモデルを適応し比較．SOTA

HATは視線予測において他の手法を上回り、特に視覚探索と自由閲覧のタスクで高い性能を示しました。視線の定量的な予測結果や定性的な比較を通じて、HATは人間の注視に対して優れた予測能力を持ち、未知のデータセットにおいても安定した性能を示すことが確認されました。注視予測のための新しいアプローチとして、HATは広範なタスクでの有望なフレームワークとなりうることが示唆されています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/f47ff3da-a26b-a803-bf15-ec8d3ee91fcb.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/a348e2fa-2b34-fe5a-050d-1d3c06305784.png)


#### 議論
提案されたHATモデルの実装詳細（セクションB）、削減研究の追加結果（セクションC）、OSIEおよびMIT1003での実験（セクションD）、追加の質的分析（セクションE）、および提案されたHATモデルの応用に関する議論（セクションF）が提供されています。画像のトレーニングの詳細については、固定解像度（320×512）に画像をリサイズし、トレーニング中にデータ拡張を使用せずに、30エポックでHATをトレーニングします。また、畳み込み層とMLPを含むいくつかのパラメータは、損失を使用してエンドツーエンドでトレーニングされます。HATはOSIEおよびMIT1003で優れた性能を発揮し、推論速度は1秒で、メモリ使用量は18GBです。実験では、異なるピクセルエンコーダーとデコーダー構成でHATが優れた性能を発揮し、モデルの柔軟性が示されています。
HAT（Human Attention Transformer）モデルによる視線予測の性能評価とその応用について述べられています。実験結果によれば、HATは異なるエンコーダやデコーダ、Transformerデコーダレイヤーの選択においても高い性能を示し、特に自由視点データセットでの予測が優れています。また、HATは視線の予測において人間の行動に近い結果を示し、将来的にはVR/ARゲームや自動運転システムなど様々な分野での応用が期待されます。

#### 所感

最新の研究ではSVMやCNNではなくtransformerを用いるようになっている．
やはりtransformerは偉大．
また人が注視する箇所の予測だけでなく、視線がどのように推移するかまで予測出来ているようだ（注視マップの数値が大きい順に線を結んでいるだけ？）
twitter APIの初期設定 python投稿

# はじめに 
twitterAPIを使用するために参考にした記事をまとめる。

# twitter dev設定
1. twitterアカウント作成
1. twitter devに登録　今回はfreeプランで登録
1. プロジェクト、APPを設定　※APPは必ずプロジェクトに属させる、プロジェクトに登録しないと使えない
1. 各種キーを取得、控えておく
    1. Breken Token
    1. API Key
    1. API Secret Key
    1. Client ID
    1. Client Secure
    1. Token
    1. Token Secret
    
BrekenTokenは特に重要


https://help.booster.me/%E3%82%AD%E3%83%A3%E3%83%B3%E3%83%9A%E3%83%BC%E3%83%B3%E4%BD%9C%E6%88%90%E3%82%AC%E3%82%A4%E3%83%89/p6NUoyahyxvJzDJSzV4Qjn/twitter-api%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B-twitter-developer-portal%EF%BC%88%E9%96%8B%E7%99%BA%E8%80%85%E3%83%9D%E3%83%BC%E3%82%BF%E3%83%AB%EF%BC%89/75HipDVmXSKuat4uRZx74r


https://youtu.be/0EekpQBEP_8?si=6NvCAFCJGvCaOsQG

動画を見ながら設定した方が簡単だった

# Pythonのtweepyを用いてtwitterに自動投稿する
 ```

import tweepy

#Twitter APIキーとトークン
bearer_token = "XXXXXXXXXXX"
consumer_key = 'XXXXXXXXXXX'
consumer_secret = 'XXXXXXXXXXX'
access_token = 'XXXXXXXXXXX'
access_token_secret = 'XXXXXXXXXXX'

client = tweepy.Client(
     bearer_token=bearer_token,
    consumer_key=consumer_key, consumer_secret=consumer_secret,
    access_token=access_token, access_token_secret=access_token_secret
)

# Search Recent Tweets (This requires Basic Level Access)
query = 'QUERY'
tweets = client.search_recent_tweets(query=query, max_results=10)
for tweet in tweets.data:
    print(tweet.text)

message = sys.argv[1] if len(sys.argv) > 1 else "DefaultArg1"
client.create_tweet(text=message)

# Post Tweet
message = "test tweet"
client.create_tweet(text=message)

 ```


 https://scr.marketing-wizard.biz/dev/tweepy-twitter-apiv2
予約機能のダブルブッキング問題をDBレベルで解決した日記

## 環境
Mysql8.0
Laravel10.3.2

## プロジェクトの状況
飲食店の予約システムの予約機能。

座席に対して予約をする仕組み。
座席の使える時間がある（seat.start_time, seat.end_time）
予約のリクエストは座席が使える時間のどこでもできるような仕様。

## やってみた１　楽観的ロック（Optimistic Lock）
楽観的ロックはDBにロックをかけない方法なので、楽観的ロックと呼ばれたらしい。

楽観的ロックはversionを管理することでダブルブッキングを解決する。
僕のプロジェクトの場合、座席テーブルにversionカラムを持たせて
transactionが開始したところのversionとupdateが行われる時のversionを比較、
versionが変わっていたら、処理を行わない。

プロジェクトの仕様上、座席テーブルのupdateは予約時間が被らなくても変わるので、楽観的ロックは却下。

## やってみた２　悲観的ロック（Passimistic Lock）
DBにロックをかけるから悲観的ロックと呼ばれたらしい。

悲観的ロックは
予約可能な座席をSelectしたところで、そのレコードにロックをかける。（update for）

例えば、transactionAとtransactionBがほぼ同時に行われたとしよう。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3256444/062348bd-eeb1-d471-6406-c398a78f5a0e.png)

transactionAが終了するまで待って、transactionBのSelectが行われたはずなのに、
なんで、Aの結果が反映されてないのか？？？？？？？
ここで僕は詰まってしまった。

## トランザクション分離レベルについて調べた
Mysqlのデフォルト設定はREPEATABLE READだ。
REPEATABLE READは一つのドランザクション内で同じ結果を保証するが、新しいレコードが追加される場合不整合が生じる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3256444/fa1fff6f-7d27-67e6-21f8-37929bc1b209.png)


### transaction分離レベルをREAD COMMITTEDに変更してみた。

READ COMMITTEDはコミットされたデータに対してSelectできる。
つまり、BのSelectにAの結果が反映される。

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f333235363434342f37393539333536352d653465332d653763612d343433392d3136303634323035626534662e706e67 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3256444/9b6841a8-c220-fef0-63b6-58a5f315f795.png)



これでダブルブッキングは起こらなくなった。

## 問題点
座席をSelectしているので、選択した予約時間と被らない時間を Selectしても
座席のSelectができない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3256444/ea82180e-a3bf-20df-5ee2-e6cae00193e6.png)

このように違う時間帯のSelectをしていても
先にSelectをしたAの方の予約処理が終わるまで
Bの処理は待機することになる。

予約できる時間を自由に設定できるようにするためには
このような仕組みになるしかなかった。

座席に対して予約できる時間を１時間毎に固定するしようだったら
この問題もなかっただろう、、
【Git】blameでバグの犯人探しをする

# はじめに
小ネタです。犯人探しをしたいときにお使いください。

# 犯人探し

`git blame -n ファイル名`で該当ファイルに絞って検索する事ができます。
`-n`は行数を表示させるコマンドです。

```terminal
git blame -n index.html
^f541b32  1 (username 2023-12-20 19:15:14 +0900  1) <!DOCTYPE html>
^f541b32  2 (username 2023-12-20 19:15:14 +0900  2) <html lang="en">
^f541b32  3 (username 2023-12-20 19:15:14 +0900  3) <head>
^f541b32  4 (username 2023-12-20 19:15:14 +0900  4)     <meta charset="UTF-8">
^f541b32  5 (username 2023-12-20 19:15:14 +0900  5)     <meta name="viewport" content="width=device-width, initial-scale=1.0">
^f541b32  6 (username 2023-12-20 19:15:14 +0900  6)     <title>Document</title>
^f541b32  7 (username 2023-12-20 19:15:14 +0900  7) </head>
^f541b32  8 (username 2023-12-20 19:15:14 +0900  8) <body>
^f541b32  9 (username 2023-12-20 19:15:14 +0900  9)     <div>追加</div>
abc8c358 10 (username 2023-12-20 19:15:26 +0900 10)     <div>追加2</div>
db27514b 11 (username 2023-12-20 19:15:43 +0900 11)     <div>バグ</div>
17413c9f 12 (username 2023-12-20 19:16:01 +0900 12)     <div>追加3</div>
^f541b32 10 (username 2023-12-20 19:15:14 +0900 13) </body>
^f541b32 11 (username 2023-12-20 19:15:14 +0900 14) </html>
```
下記の情報が得られます。完璧ですね

- コミットのハッシュ値
- 変更者名
- コミット日時


該当のコードがわかっていれば、`git log -S 文字列 ファイル名`でもいけるっぽいです。

```terminal
git log -S "バグ" index.html

commit db27514bd2c251ed4a64326df69c54cc9f7f521f
Author: username <hogehohe@gmail.com>
Date:   Wed Dec 20 19:15:43 2023 +0900

    bugs
```

ハッシュ値がわかれば、後は`git show ハッシュ値`で詳細な情報を確認できます。
完璧ですね。

```terminal
git show db27514

commit db27514bd2c251ed4a64326df69c54cc9f7f521f
Author: username <xxxx@gmail.com>
Date:   Wed Dec 20 19:15:43 2023 +0900

    bugs

diff --git a/index.html b/index.html
index 6fc0def..6b3a39d 100644
--- a/index.html
+++ b/index.html
@@ -8,5 +8,6 @@
 <body>
     <div>追加</div>
     <div>追加2</div>
+    <div>バグ</div>
 </body>
 </html>
\ No newline at end of file
```
パラメータを使って自分の情報は取得しない

## はじめに
パラメータにログインユーザのidを渡し、自分の情報をコントローラで取得しようとしていました。

これはURLの打ち込みなどで簡単に他人のページが覗けてしまう状態なので、かなりマズい状況です。。

自戒の意味も込めて整理しておきます。

## 環境
Laravel 9.52.16

## 問題
```php: web.php（失敗例）
Route::group(['middleware' => ['auth']]), function () {
    // 一覧を表示するためのルーティング（一部略）
    Route:get('my/purchase/index/{id}', [PurchaseController::class, 'index'])->name('my-purchase');
});
```

```php: PurchaseController.php（失敗例）
public function index($id)
{
    $user = User::findOrFail($id);

    $purchase = $user->purchases()->get();

    // 以下略
}
```

購入一覧を表示するindexアクションのURLで、{id}としてしまっているのが問題です。

一見、middlewareがあるので本人以外はindexにアクセスできないように見えるかもしれません。

しかし'auth'なので、ログインユーザが検索ボックス内でidを直打ちすれば、保護すべき他人の一覧を見放題です。

コントローラにある通り、ログインユーザ自身のpurchaseを取得しようとしていましたが、セキュリティの脆弱性を孕みます。


## 解決策
```php: web.php（解決例）
Route::group(['middleware' => ['auth']]), function () {
    // {id}を消す
    Route:get('my/purchase/index', [PurchaseController::class, 'index'])->name('my-purchase');
});
```

```php: PurchaseController.php（解決例）
public function index()
{
    $user = Auth::user();

    $purchase = $user->purchases()->get();

    // 以下略
}
```

単にログインユーザ自身のデータのみを取得したいなら、「Auth::user();」で事足ります。
全ての人に送るMac入門書

# はじめに

この記事は長らくWindowsとLinuxに親しんできた筆者が、初めてMacに触れて感じたポイントをつらつらとまとめたものです。
なので入門書ではありません。ごめんなさい。

Macに触れたことがない方はそうなんだーと思いながら。熟練の方は懐かしき日を思い出しながら気軽に読んでいただけると幸いです。

なお本記事はMacBook Airでの体験をもとに書いており、トラックパッドあり前提での内容となっております。

# 起動音が大きい

初めての起動時「ドゥーン」とかなり大きい音が鳴り、めちゃめちゃびっくりしました。
最初からどうでもいい内容ですいません。

共感いただける方が多いと嬉しいです。

# シャットダウンしないでスリープさせるだけでOK

使い終わったら電源を落とすのが当たり前だと思っていたため、スリープで運用するのが基本というのは驚きでした。
最初は少しだけ違和感がありましたが、便利すぎてあっという間に慣れてしまいました。
すぐに前回の続きを始められるので、もういちいちシャットダウンする生活には戻れません。

# 最大化したはいいけど、、他のウィンドウはどこ？

WindowsやLinuxと異なり、Macは仮想デスクトップの機能が非常に洗練されています。

仮想デスクトップ間の行き来は指3本のフリックでスイスイ行えますし、Mission Controlという画面を開けば、デスクトップの入れ替えやウィンドウの移動も簡単に行うことができます。

タイトルにあるウィンドウの最大化についても、最大化した時点でそのウィンドウは別の仮想デスクトップとして新たに作成されます。

慣れれば非常に便利なのですが、初めて触る人からすると「あれ、さっきまでのウィンドウどこいった。てかどうやって戻るんや」となること必至です。

# Finder？あーエクスプローラーね。えーっとホームディレクトリーは、、

まずパスバーがありません。不便すぎます。

そしてサイドバーには「よく使う項目」が並び、その下にはiCloudやらタグやらが。ホームディレクトリーはどこ？

Macの基本的なディレクトリ構成も知らない状態で「よく使う項目」を見せられても、何が何やらさっぱり分からず。

パスを指定しようにもパスバーがありません。ダメ元でcommand+Lなんかを押してみますが反応はありません。（ちなみに正解はcommand+shift+Gです）

色々とカスタムすれば使いやすくなりますが、デフォルトのものについては、自分が唯一明らかにWindowsの方が優れていると感じるポイントかもしれません。

# えーっとメニューは、、

上の例のようにパス指定で移動したい等、アプリごとのメニューを開きたい場面は多いと思います。

Windowsではウィンドウの上部にあるリボンにメニューがあることが多いです。（ウィンドウにくっついている）

一方でMacは、画面の1番上部にあるステータスバーにメニューが表示されます。（ウィンドウから離れている）
そして最大化などをしているときにはこのステータスバーも隠れてしまうため、マウスを上に持っていかないと表示されません。

自分は今でも結構迷子になってしまいます。

# commandがCtrlっぽいな。それでconrolがAlt？optionは、、

Macは独自の修飾キーを持っており、地味にWindowsと似たような機能を有しています。ただ似ているだけなので、所々異なる点があります（コマンドの強制終了はcommand+Cじゃなくてcontrol+Cとか）。

また名前も地味に似ていて、混乱の一因になっています。

ややこしいですね。

# DeleteがBackSpaceなんだ。じゃあDeleteはどこ？

なぞなぞのようになってしまいましたが、これもキーボード関連の混乱ポイントです。

WindowsではBackSpaceキーでカーソルの前の文字を消すことができますが、Macではその機能をDeleteキーが担います。
そしてWindowsにおけるDeleteキー（カーソルの後ろの文字を消去）に相当するキーはMacには存在せず、ショートカットとして実装されています。（control+D等）

ややこしいですね。

# バツを押したのにアプリが終了しない

Macの赤いバツはアプリを終了するためのものではなく、ウィンドウを閉じるという意味合いの方が大きいです。

じゃあ黄色いボタンの役割は何かとなりますが、こちらは「Dockにしまう」ためのボタンです。難しいですね。このあたりは実際に使ってみないとなかなか理解が難しいです。

赤いバツでは現在の作業内容が終了するので、そこがわかりやすい違いかも知れません。

余談ですが、自分は使わないアプリが起動しているのが嫌で、いつもバツを押したあとにDockのアイコンを右クリックして終了を選択するという二度手間を続けていました。最近command+Qというショートカットを知りました。もっと早く知りたかったです。


# さいごに

自分の所感ですが、Macは最初こそ戸惑う点も多いものの、一度慣れてしまえば非常に便利な機能が多く、現在はありがたく使わせていただいています。

また何か思い出したら追記するかも知れません。

最後までお読みいただきありがとうございます。
タスクの見通しを良くする工夫

この記事は[ファンタアドベントカレンダー2023](https://qiita.com/advent-calendar/2023/funteractive-inc)の21日目の記事です

---

多様なプロジェクトに取り組む中で、1日に3つや4つの仕事が進行している時、それぞれのタスクをどのようにこなしているのかを考えてみました。

前提として細かい数あるタスクを効率的に処理する方法に焦点を当てており、重たいタスクをこなす方法ではないことを先に断っておきます。

## タスク管理について

重くはないが量が多いタスクを効率的に処理するために、私はタスクの種類を３つに分けています。

- 集中が必要系
- 10分で終わる系
- 考えなくていい系

朝やお昼などの体力があるときにいきなり集中が必要系のタスクに取り掛かりたい…という気持ちはグッと堪えて、10分で終わる系のタスクから着手しています。

特に複数案件を切り替えるときはすぐ終わる系のものを最初に着手し、徐々に重たいタスクに取り掛かります。始めちょろちょろ中ぱっぱを強く心がけています。慣らし運転をすることでプロジェクトごとの切り替えコストを抑えるのが目的です。

考えなくていい系は仕事上がりの前、頭が疲れている時に着手するものとして残しておくことが多いです。

## 使用するツール

使用するツールは使い慣れたものならなんでも良いと考えています。個人的に[Things3](https://culturedcode.com/things/)を愛用しています。

チームで使うタスク管理ツールがある場合でもThingsにも同じタスクを入力し、それだけ見ていれば今日何をすればいいかわかるようにしています。

自分が何をすればいいかわかれば良いので、ここで使うツールにはコラボレーション機能などは求めません。

![Untitled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140260/bbe54fe6-0450-82ab-174e-112ba8fed9db.png)

## 工数について

実際の所要時間を悲観的に見積もり、1.2〜1.5倍の時間を予定します。そのまま入力すると時間かかりすぎでは？となってしまうため、あらかじめ悲観的に見ていることは伝えています。

見積もりより短く終わった場合はラッキー、次のスプリントのタスクでもやっておこうの精神でやっています。

## やってみてダメだったもの

### カンバン系のツール

Todo, in Progressみたいな状態管理をやり始めるとメンテナンスがめんどくさくなり何もやらなくなりました。

あくまでやってないタスクだけ見えればよく、細かい状態管理は不要です。やったら消し、差し戻しがあったら復活させることで、やることリストのメンテナンスの手間を省いています。

### ポモドーロテクニック

大きいタスクをやっつけるのには有効だと思いますが、今回想定している複数案件をこなすような場合、差し込みタスクへの対応でリズムが崩れるので向かないと考えています。

### Fantasicalやgoogle calendarのようなカレンダー+Todoリストなツール

予定もやることも一覧できて最強だと最初は思っていたのですが、分単位でやることを詰め込むようになってしまいました。その結果差し込み対応が入った時の柔軟性が確保できず予定が総崩れということが頻発しました。

## その日のスケジュールをプロジェクト単位で切り分けるか、タスク単位で切り分けるか

当たり前ですが切り分けた時の粒度はプロジェクト単位の方が大きく、タスク単位の方が小さいです。

この切り方にはそれぞれメリットデメリットがあると考えています。

プロジェクト単位で切り分けると頭の切り替えコストも少ないため集中が続き、時間が確保できるので誰かとの協業がしやすく、重たいタスクもこなしやすいですが、一方で差し込み対応に弱く、他のプロジェクトが動いたときの対応が遅れがちです。

タスク単位で切り分けると各プロジェクトの状況により取り組む順番を柔軟に切り替えられるので、イレギュラーに強く、今回想定するケースではこちらの方があっていると考えています。

どちらかに寄せ切るとそれはそれで問題が起きるので、関わっているプロジェクトの数やそれぞれの状況に合わせて比重を変えていけると良いですね。

## まとめがわりの心構え

1日のスケジュールを組む際、ガチガチに固めすぎないよう心がけています。たとえば、10時から14時までお仕事A、14時から17時までお仕事B、それ以降にお仕事Cという具体的な時間割を設定していると、予期せぬ差し込みタスクが発生した際にスケジュールが一気に崩れます。

大きい粒度でタスクを管理するとリカバリーが難しくなるため、**関わっている仕事が3つ以上ある場合は特に、プロジェクト単位ではなくタスク単位で考える**ようにしています。

また、忙しさは重なるものだと割り切ることが大切です。お仕事Aに取り組んでいる最中に、突然明日対応予定のお仕事Bが動き出し、さらに眠っていたはずのお仕事Cまでもが動き出すことがよくあります。関わっているプロジェクトが多ければ多いほど、イレギュラーな出来事が増える傾向にあります。このような状況に陥った際にはパニックにならず、忙しい時期は重なるものだと心得て、落ち着いて対応するよう努めています。

最後に、大体のものは思っていた通りにいきません。イレギュラーに対応できるよう、やることパズルをすぐにできる環境を作っておくことが重要だと考えています。

---

明日はPMの山本さんが1on1について書かれます。引き続きお楽しみください。
グループでデータ分析コンペに参加する楽しさについて

## はじめに
こんにちは。マナビDXクエスト参加者のじんどうです。
(https://dxq.manabi-dx.ipa.go.jp/)

2022年度マナビDXクエストの演習でデータ分析コンペの楽しさを知り、今年の3月くらいからデータ分析コンペに参加するようになりました。
まだまだ初心者ですが、賞品と複数メダルもいただけました。
データ分析コンペに個人で参加したこともありますが、マナビDXクエストで出会った方々とグループで参加することがほとんどです。グループで参加するからこそ得られること、そして何より楽しいと言うことを知っていただきたく、本記事を書きました。

すでにデータ分析コンペに参加されている方、これから参加してみようと考えている方、是非ともグループでの参加をお試しください。

## きっかけ
データ分析コンペに参加することになったきっかけは、マナビDXのSlackでmatsuさんがKaggleコンペへの参加を呼び掛けてくれたことです。他にもたくさんの方が手を上げられ、バックグラウンドやライフステージが似ている人同士でグループを組みました。

## 初戦　【Kaggle】WiDS Datathon 2023
WiDS Datathonは毎年行われるコンペで、女性たちがデータサイエンスのスキルを磨くことを目的としたコンペです。2023年は気象予測がテーマでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3655975/eabc351b-1bfc-4d63-2c55-5e6356aaaafe.png)

女性4人のグループで挑みました。グループを組むまで全く面識がない方々で、お互いの実力も性格も何もわからないまま、探り探りでのスタートでした。全員コンペ参加経験がほとんどなく、でも勉強熱心なメンバーがそろいました。

結果、比較的初心者向けのコンペとのことでしたが・・・。　**73位/697**
順位はそこそこですが、他の参加者が提供して下さっているソースコードを少し変更することしかできず、悔しさの残る結果となりました。


## 2戦目　【Kaggle】AMP®-Parkinson's Disease Progression Prediction
リベンジを果たすべく同じメンバーで挑んだのも、またまたKaggleのコンペです。パーキンソン病の症状を予測するコンペでしたが、ルールが難しく、理解するのに一苦労したコンペでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3655975/e7e69c4c-19b7-f6e2-f69b-8957e2912d8c.png)

自分で一からコードも書いてみましたが、提供コード以上の精度にはできず、今回も提供コード＋α　と言ったことろでした。
それでも結果は**115位/1805　初のBRONZEメダル**もいただけました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3655975/9203e85e-3ff5-1429-a4e3-46d39ef4142f.png)

ただし、メンバー全員これはまぐれの結果だと実感。もう少し初心者向けのコンペで腕を磨くことになりました。

## 3戦目　【Nishika】生鮮野菜の価格予測 2023春
英語に苦労したこともあり、次は国内の親しみやすい内容のコンペにしました。
これは、気候や過去の価格データなどから、12品目の野菜の価格を予測するコンペです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3655975/e300d950-901a-fd08-088c-19cd03933620.png)

ここからは、参加できなくなったメンバーに代わり、元々のきっかけを作ってくれたmatsuさんにも一緒に入っていただき参加しています。
野菜が12品目もあったので、それぞれで野菜を分担し、野菜毎に何が予測に効きそうかと言ったことを調べました。
野菜によって気候の影響を受けるタイミングや期間も異なります。みんなで情報を共有しながら、「確かに去年の冬はこの野菜が高騰していたけど、こんな理由だったんだねー」なんて話をしながら楽しくコンペを進めました。

ただし、これだけいろいろ調べても気候データは精度向上には全く活かせず。そのもどかしい気持ちを共有できるのもグループ参加の楽しさです。
このころには、それぞれが自走できるようになっていて、SARIMA、LightGBM、CatBoostなどそれぞれが得意なモデルを使って予測値を算出しました。それをアンサンブルすると驚くほど精度が上がりました。
野菜によって時系列モデルが効くもの、決定木系が効くもの、バリデートの時期も1年前の同じ月が良いものもあれば、先月が良いものもあります。いろんな組み合わせを試しました。
結果　**3位/100　賞品もゲット** しました。Tシャツ、マグカップ、ステッカーなどをいただけ、チームで山分けしました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3655975/ef99f70f-111a-6f6a-c35d-bcf121f1c21d.png)

その後もメンバーを加え、いくつかのコンペに参加しています。

【PROBSPACE】 野菜取引価格の予測  6位/113　GOLD
【Nishika】中古マンション価格予測 2023夏の部　　15位/127
【PROBSPACE】 タクシー需要予測  20位/109　SILVER

## さいごに
グループでデータ分析コンペに参加すると、
* これをやったら精度が上がったよーとメンバーに自慢ができる
* ソースコードの書き方や進め方に困った時にアドバイスがもらえる
* 分担ができる（いろんなことが試せる）
* そして何よりも、喜びや悔しさを共有できる

尊敬できる人たちと同じ目的に向かって協力することは、仕事でも企業協働でもデータ分析コンペでも、本当に楽しくわくわくすることだと日々感じています。

データ分析コンペ、まだまだ初級者ですが、いつかは賞金が取れるような力をつけていきたいです。
ぜひ、グループでデータ分析コンペ参加してみて下さい！
Pythonで「文字列、タプル、rangeなどからリストを作成する」の動作を確認してみた

# 概要

Pythonで「文字列、タプル、rangeなどからリストを作成する」の動作を確認してみました。以下のページを参考にしました。

https://www.javadrive.jp/python/list/index12.html

# 実装

以下のファイルを作成しました。
```sample.py
mylist = ["A", "B", "C"]
newlist = list(mylist)
print(newlist)

mylist = list("Hello Python")
print(mylist)

mylist = list(("A", "B", "C"))
print(mylist)

mylist = list(range(10))
print(mylist)
```

以下のコマンドを実行しました。
```
$ python3 sample.py 
['A', 'B', 'C']
['H', 'e', 'l', 'l', 'o', ' ', 'P', 'y', 't', 'h', 'o', 'n']
['A', 'B', 'C']
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
```

# まとめ

何かの役に立てばと。
僕がRustを推したい理由

どうも。暇すぎてミイラになった人です。

最近、というよりここ数年はGoではなくRust推しな僕ですが、僕がなぜRustを推したいのか解説します。

:::note warn
この記事では他の言語のディスりが含まれています。PythonもしくはGoを使っていてRustが嫌いな人はアレしてください。
:::

# Pythonで例外を書いてみる。

```python
def exc(text: str) -> str:
  if len(text) == 0:
    raise ValueError(text)
  return text
```

これは`text`の長さが0なら例外をスローし、それ以外なら`text`を返すという、ごくごく一般的なPythonのコードです。そして僕も昔はPythonを推していました。しかし、今になってわかる。この書き方はダメだという事が分かります。**例外をスローするという事は、str型以外の型が返されたうえで異常終了する可能性がある。** という解釈ができます。つまり、`exc`の挙動を何も知らない人がこれを使うと、**ValueErrorがスローされてサービスが落ちる、という惨状になりかねません。**

# Go言語で例外を書いてみる。

それじゃあ、今度は別の言語、例えばGo言語を使えばいいじゃないか、という考えに行き着きます。それでは以下のコードを見てみましょう。

```go
import "errors"

func exc(text *string) (*string, error) {
	if len(*text) == 0 {
		return nil, errors.New(*text)
	}
	return text, nil
}
```

上のコードはPythonとほぼ同じ挙動をするコードです。ただし、パラメータは文字列のポインタ、返却値は文字列のポインタとエラーのタプルです。

一見すると、Pythonが抱えていた問題を解決しているように見えます。確かに、宣言された返却値の型以外の型が返ってくるという事は起きなさそうです。

**ところが**、今度は別の問題が浮上します。例えば、execに渡される型が`nil`ならどうなるでしょうか？

というわけで検証してみたコードがこちら:

```go:main.go
package main

import (
	"errors"
	"fmt"
)

func exc(text *string) (*string, error) {
	if len(*text) == 0 {
		return nil, errors.New(*text)
	}
	return text, nil
}

func main() {
	value, err := exc(nil)
	fmt.Println(*value, err)
}

```

そして出力されたものがこちらです。

```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x47adb4]

goroutine 1 [running]:
main.exc(...)
        /home/hyamamoto/test.go:9
main.main()
        /home/hyamamoto/test.go:16 +0x14
```

つまり、ぬるぽが起きます。言い換えれば、サービスが落ちます。対処法はいろいろありますが、その何れもランタイムでnilチェックを行うものです。このため、**プログラマがコード上で変数の値がnilになる可能性があるかどうかを注意深く観察しなければなりません。** ヒステリックまっしぐらです。

ちなみに、僕が体験した事例では、フォームバリデーションを実装した時に、サードパーティがエラーを出さずに正常な値として`nil`を出力する事例があって、それ故にサービスがよく落ちる事がありました。

# Rustで例外を書いてみる。

それではRustではどうなるのかというと、以下のコードになります。

```rust
fn exc(text: Arc<String>) -> Result<String, String> {
  return if text.is_empty() {
    Err(text.to_string())
  } else {
    Ok(text.to_string())
  }
}
```

`Arc`は「共有リファレンス向けのスマートポインタ」です。さて、ここで注意すべき点は、**Rustでは全ての値は必須である** という点です。つまり、`nil`や`NULL`をArcにぶち込むなんてことはできないのです。そしてそもそも、Rustでは`unsafe`を使わない限り、`nil`や`NULL`の値が存在することもできません。

この上で、上記のコードを見ると、`Result`型以外の型の値を返すことはなく、かつtextにぬるぽが混入することもありません。また、エラーが発生した時にどういう処理を行うのかを明確に記述しなければ、正常時の値を獲得することもできないため、この`Result`一つとっても、Rustのメモリ保護の機構が秀逸である事が分かるかと思います。

## Rustでnilに相当するものはあるのか

ここで読者諸君は疑問に思われるかもしれません。`nil`が必要な場面があるが、その場合はどうすべきか、と。

**ご安心ください！** [ちゃんとあります](https://doc.rust-lang.org/std/option/)。ただし、この場合も`Option`の値は必須になるので、指定された型以外の型が混入するという謎現象はありません。

## まとめ
どの言語が素晴らしいかなどと優劣はつけられません。たとえば、コーディングテストなどではかき捨てで使えるスクリプト言語が向いています。特に、僕はPythonをかき捨てのためのスクリプト言語として今も利用しています。現代のWebプラットフォームのバックエンド部分ではGo言語が良く使用されるでしょう。Rustはメモリ保護がずば抜けている一方で、そのメモリ保護が原因でコードが煩雑になる事があります。

なので、使いたいプログラミング言語はケースバイケースで選ぶべきでしょう。

おわり
AWS SOA-C02 学習方法

# 初めに
2023年12月にAWS SOA-C02を受験して無事合格したので勉強方法を共有出来ればと思い記事を久々に投稿します。
AWS SAAはQiitaでかなりの数の勉強方法などが見つかりますが、それに比べてSOAはそこまで最新の投稿数が少ないので投稿してみようと思いました。

## スタート時点のスペック
勉強開始時点でどの程度のスペックだったかも参考になるかと思いますので記載します。
・**取得済みのAWS資格**：AWS CLF-C01、SAA-C03
・**SAA取得後すぐに勉強開始**
・**業務でのAWS使用**：たまに触る程度
・**エンジニア歴(インフラ)**：4~5年

## 勉強方法
### 使用した教材
[1.AWS SOA試験概要説明資料](https://aws.amazon.com/jp/certification/certified-sysops-admin-associate/)

[2.AWS Skill builder](https://aws.amazon.com/jp/training/digital/)

[3.Cloud Tech](https://kws-cloud-tech.com/)

[4.CloudLicense](https://cloud-license.com/)

**5.AWS公式ドキュメント、個人/企業技術ブログ**

**6.AWS マネジメントコンソール**

### 勉強方法
#### 1.AWS SOA試験範囲を知る
まずは"AWS SOA試験概要説明資料"を確認し、SOAの試験範囲を確認しました。
確認後、資料の最後に記載されているサービス一覧が記載されているので、分からない・知らないサービスはメモをして概要をノートにまとめました。

#### 2.問題を解いて解いて解きまくる
試験範囲を把握したら教材2~4に載っている試験問題を解きまくります。
教材2→3→4の順番で解いていき、各教材の試験問題全て解き終わったら次の教材に移る。

2→3→4の順番にした理由としては以下です。

***2.AWS Skill builder***
・無料
・公式と同様の試験問題の言い回しに慣れるため

***3.Cloud Tech***
※有償
・試験同等の問題に加えて、それぞれの問題に対してイラスト付きの解説があるため
・SOAの問題に慣れるため
・理解を深めるため
・各セクション全て解く→100問ずつ一気に解くといった利用をしました。

***4.CloudLicense***
※有償
・C01の問題含めてだが、問題数が一番多い
・間違えた問題だけ解くことが出来る
・問題数が多いので似ている問題が多数出題→試験前に解いておいた方が良い
・10セクションずつ解く→間違えた問題を解く
　→#51以降全て終わったら2回目一気に解く→#1～同様に繰り返す
  →試験モードで解く

#### 3.間違えた・知らない問題の理解を深める
試験問題で間違えたり、合っているけど知らない問題があった場合は、以下を実施しました。

1.試験問題の解説を読む
2."1"で分からない場合AWS公式ドキュメントを読んだり、個人/企業のテックブログを読んで"なるほどね~!"と納得するまで読む
3.イメージが付くようにAWSマネジメントコンソールへログインし、操作してみる。

そして、分からなかった問題をノートに***イラスト+コメント付き***で***自分が理解できるように***まとめました。


### 勉強期間・時間・タイミング
勉強期間や時間を数字として残しておきたいと思い、AWS SAAの受験勉強を開始した時から**StudyPlus**を使用して記録を残しています。

合否に関わらず振り返りをする際に役立つので記録を残すようにしています。

**1.勉強期間**
SOA受験勉強を始めてから試験受験日の前日までで***16日***でした。
※平日はもちろん仕事有です。

基本的には毎日勉強を行うようにしましたが、仕事や私用などで殆ど勉強できない日も1日あったりなかったりでした。

**2.勉強時間**
計算してみたところ、約50時間でした。
***1日あたり約3時間程度***です。
振り返ってみると人生で一番勉強をしていた中学時代と同じぐらい力入れていました。

**3.勉強タイミング**
勉強をいつしていたのか、ですが以下となります。

[**平日**]
・起床後～業務開始の間
・電車などでの移動時間
・昼休み
・業務後～就寝の間

[**休日**]
・図書館やブックラウンジなどで開館～19時程度まで。
　※もちろん休憩しつつです。
・帰宅後～就寝の間

## 実際の試験
私は試験はいつも試験会場で受けています。
（オンライン受験のセッティングが面倒なので。）

***試験中の進め方***
※あくまで個人的な進め方です。

ホワイトボードへ以下を記載しつつ、問題を解いています。
***〇：絶対出来ている問題番号を記載***
***△：多分合っているだろうけど、どうだろうな～という問題番号を記載***
***×：うん！知らないオプションですコレ！という問題番号を記載***

確かにPCに後で見返す機能あるのでやらなくても良いのですが、
〇へ記載する問題数が増えていくのを見て心を落ち着かせるためにいつも記載しています。

5問に1問ぐらい分からない問題あっても平気平気～といった感じでメンタルを安定させています。
***〇が多くならなかった場合、それはそれで落ち着かないのですけどね...。***

後は基本的に全問見返しています。
余裕だと思っている問題を絶対落とさないためにも「問いと回答の組み合わせあっているよね？」と確認するためです。

## これから受験する方へのアドバイス
[***試験の解き方***]
・良く分からん！という問題が出てきたら、**明らかに間違っている回答を選択肢から排除していって答えを割り出す**という解き方をしてみてください。
SAAと比べてそういう問題が何問かあったな～と感じています。

[その他]
・AWSマネジメントコンソールで各サービスを触っておく。
　作成しなくても良いので、作成途中の画面まで見ておいたりすると覚えやすいかなと。
・特定のワードと特定のサービスの組み合わせを覚える
・連携できるサービスは全て連携させて考えてみる
・サービスのデフォルト設定を覚えておく
　（セキュリティグループ、ACL等）
・問題を解いて解いて解きまくる

# 最後に
これからAWS SOAを受験する方の参考になれば幸いです。
ranger-cdをfish用に書き換える


## 【背景】
最近、fish-shellを利用するようになりました。
その際に困ったのは、`.bashrc`で作っていた設定が使えなくなったことです。
（当たり前ですけどね笑）

その中の一つが`ranger-cd`です。
私は普段からrangerを使用しており、rangerを閉じた際にそのディレクトリにcdしていてほしいため、`ranger-cd`を使用していました。

ですが、fish-shellでは`.bashrc`ではなく`fish.sh`を使用するため、そっちに移行すべく調べたのでここに残します。

## 【ranger-cdとは？】
ranger-cdとは、ファイルマネージャーであるrangerを使った後に、シェル（ターミナル）で作業していたディレクトリを自動的に変更するためのシェル関数です。
この関数は、rangerを終了した後に最後に訪れたディレクトリに自動的に移動します。
この関数を.zshrc、.bashrcなどのシェル設定ファイルに追加するか、あるいはシェル設定からこのファイルを読み込むことができます。


## 【ranger-cd 元スクリプト】

```bash
# .bashrc
 function ranger-cd {
 	   temp_file="$(mktemp -t tmp.XXXXXX)"
 	   /usr/bin/ranger --choosedir="$temp_file" "${@:-$(pwd)}"
 	   test -f "$temp_file" &&
 	       if [ "$(cat -- "$temp_file")" != "$(echo -n $(pwd))" ]; then
 		   	     cd -- "$(cat "$temp_file")"
 		     fi
 	   rm -f -- "$temp_file"
 }
```

引用元：[bash_automatic_cd.sh](https://github.com/wdv4758h/ranger/blob/master/examples/bash_automatic_cd.sh)

## 【Fishシェルへ書き換え】


Fishシェルの構文はBashとは異なります。

例えば、変数の代入には`set`コマンドを使用し、`&&`や`;`でのコマンドの連結は異なる方法で行います。
また、条件分岐には`if`文が使われますが、Bashとは書き方が少し異なります。

以下は、提供されたBash関数をFishシェルに移植した例です：

```bash
# fish.sh
function ranger-cd
    # 一時ファイルを作成
    set temp_file (mktemp -t tmp.XXXXXX)
    
		# rangerを実行
    /usr/bin/ranger --choosedir="$temp_file" $argv; or pwd

    # 一時ファイルが存在し、かつ現在のディレクトリが一時ファイルに書かれているディレクトリと異なる場合
    if test -f "$temp_file"
        set selected_dir (cat $temp_file)
        if test "$selected_dir" != (pwd)
            cd $selected_dir
        end
    end
    # 一時ファイルを削除
    rm -f $temp_file
end
```

このスクリプトでは以下の変更を行っております。

- 一時ファイルの作成に`set`を使用して変数を代入しています。
- `test`コマンドを使用してファイルの存在を確認しています。
- Fishでは`&&`の代わりに`; and`を、`||`の代わりに`; or`を使用します。
- `if`文の構文が変わり、Bashの`[ ... ]`の代わりに`test`コマンドを使用し、条件ブロックは`end`で終了させる必要があります。

上記の例がFishシェルにおける`ranger-cd`関数の移植版となります。

:::note info
※`/usr/bin/ranger`の箇所は、使用している環境に合わせて変更してください。

※fish-shellへの変換はChatGPTにやってもらいました。
こう言う置換はChatGPTは強いですね。

※私の環境で動作確認済みです。
:::
eslint-plugin-svelte3 からeslint-plugin-svelte 移行時に詰まったこと

## 概要

[eslint-plugin-svelte3](https://github.com/sveltejs/eslint-plugin-svelte3) が deprecated になっていたため [eslint-plugin-svelte](https://github.com/sveltejs/eslint-plugin-svelte) に移行しようとしたが地味に詰まったので軽くまとめる。

## 参考

ほぼこれ通りにやれば大丈夫なはず

https://zenn.dev/snowcait/articles/62cec4ce8de6a0


公式README

https://github.com/sveltejs/eslint-plugin-svelte

## エラー内容

公式READMEを参考に、

```cjs
module.exports = {
  root: true,
  parser: '@typescript-eslint/parser',
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:svelte/recommended',
    'prettier'
  ],
  plugins: ['@typescript-eslint'],
  overrides: [
    {
      files: ['*.svelte'],
      parser: 'svelte-eslint-parser',
      // Parse the `<script>` in `.svelte` as TypeScript by adding the following configuration.
      parserOptions: {
        parser: '@typescript-eslint/parser'
      }
    }
  ],
  parserOptions: {
    sourceType: 'module',
    ecmaVersion: 2020,
    extraFileExtensions: ['.svelte'],
    project: './tsconfig.json'
  },
};
```

とすると、eslint実行時に

```bash
error  Parsing error: ESLint was configured to run on `<tsconfigRootDir>/playwright.config.ts` using `parserOptions.project`: "path/to/tsconfig.json"
```
といった内容のエラーが出た。

## 解決方法

`parserOptions` から `project` の設定を削除したところエラーメッセージが消えた。

```cjs
module.exports = {
  root: true,
  parser: '@typescript-eslint/parser',
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:svelte/recommended',
    'prettier'
  ],
  plugins: ['@typescript-eslint'],
  overrides: [
    {
      files: ['*.svelte'],
      parser: 'svelte-eslint-parser',
      // Parse the `<script>` in `.svelte` as TypeScript by adding the following configuration.
      parserOptions: {
        parser: '@typescript-eslint/parser'
      }
    }
  ],
  parserOptions: {
    sourceType: 'module',
    ecmaVersion: 2020,
    extraFileExtensions: ['.svelte'],
    // project: './tsconfig.json' <- これが不要だった
  },
};
```
12日目：Predicting human gaze beyond pixels(2014)

### Predicting human gaze beyond pixels(Juan, 2014)

https://www.researchgate.net/publication/259961066_Predicting_human_gaze_beyond_pixels


#### 概要

新しい視覚の予測アーキテクチャを提案している。
従来の"ピクセル属性"だけでなく、"物体"や"意味"の情報も重要である（つまりボトムアップだけでなくトップダウンも？）。
特に、物体やセマンティック属性の共通の属性セットを提案し、その重要性を分析し、大規模なアイ・トラッキングデータセットを使用して人間の注視を正確に予測することを目指している。

ピクセルレベルの属性として、色、強度、方向が導入され、オブジェクトレベルの属性としてサイズ、複雑さ、凸面性、実体性、偏心度が提案されている。
セマンティックレベルの属性では、顔、感情、触れる、注視などの重要な意味情報が議論され、これらの要素が視覚の注目に影響を与えることが説明されている。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/4dc1cf04-acda-ed5b-84bc-23f437d405a8.png)

#### 主な貢献
1．ピクセル、物体、意味（セマンティック）の3層での顕著性モデルの提案
2．視線追跡データの700枚のデータセットを構築、提供


#### データセットと検証方法
視覚的な注目に関連する要因や、新しいOSIEデータセットの概要が説明されている。データセットは、視線追跡データ、セグメンテーション、および意味属性の評価に基づくもので、視線の注視を引き起こす異なるオブジェクトやセマンティック属性の統計的分析が可能である。また、他のデータセットとの比較や実験手順についても述べられている。

被験者に画像を自由に見るよう指示し、視線パターンに関する統計と分析を行いました。実験結果から、被験者の視線は画像の中央に偏っており、他のデータセットと比較してもその傾向が小さいことが示された。また、画像のエントロピーを測定し、このデータセットが異なる種類の対象に注意を引きやすいことが明らかになった。

この研究では、物体の定量的分析が紹介され、特に細かい輪郭を使用したオブジェクトのセグメンテーションが強調されている。また、セマンティックアトリビュートに基づいた物体への注視の分布とその結果が示され、特に顔に対する注視が多いことが強調されている。被験者によるセグメンテーションとラベリングが行われ、その結果が統計的な分析と実験結果として報告されている。注目の「物体中心のバイアス」に焦点を当て、物体と意味の属性と結びついていることが述べられている。提案された意味の属性の統計的分析が行われ、それぞれの妥当性が定量的に示されている。


#### 提案モデル
最後に、計算モデルを構築し、異なる属性の組み合わせと比較して視線の予測を行い、他の最近の注目モデルとも比較する。まずベースとなる分類モデルはSVMである。画像の注目領域を決定するために、MITモデルと同様に、複数の主題によって指定された注目領域を重視し、少ない注視が発生する画像の大部分を背景として残す方法が採用される。1：3のサンプリング比率を選択する目的は、同じ画像内の正と負のサンプルピクセルの分布をバランスさせることであり、学習サンプルは平均がゼロで分散が1になるように正規化される。
線形SVMが各ピクセル、オブジェクト、および意味レベルの属性の重みを学習するために使用され、特に視覚情報の神経過程メカニズムに基づくものです。Faceとtextが他の属性を圧倒し、その後にgazedとtasteが続く。モデルは、他のモデルよりも優れた視覚注視の予測性能を示し、特に物体の意味情報が重要であることが明らかになった。
提案された方法は、異なる属性が視覚注視に異なる寄与をすることを示し、これを考慮すると注視予測が向上する。
定量的な評価では、提案されたモデルは他のモデルよりも優れた性能を示し、視線データから学習された重みがより正確な予測に導くことが示す。
提案された三層構造の視覚顕著性モデルは、物体および意味レベルの情報を明示的かつ主導的にモデリングし、視線配分の機構を理解する。
提案モデルは、視覚データセットとして700枚の画像と15人の視線データを提供し、物体および意味の情報が人間の視線を予測する重要性を実証した。
これにより、制限された数のオブジェクト検出器を追加する現行の問題を克服した。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/216d9da4-bfeb-ab68-6be1-d55ac98f3b08.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981660/e60c0aba-4879-dc1d-11a4-c45c5c342542.png)

### 所感
ピクセルレベル(ボトムアップ)と物体、セマンティックレベル(トップダウン)に分けて考慮している。論文中にも言及されている通り、高精度な注視点を抽出するためにはボトムアップだけでなくトップダウンを同時に考慮する必要があるのだろう。
パイプを分岐する [ワンライナー]

# パイプを分岐する

シェルのパイプ構文(`|`)による入出力ストリームはプロセスを直列で接続します。プロセスAの出力を分岐/複製して、プロセスBとプロセスCに並列接続で同じデータを渡すことは、パイプ構文だけを用いてシンプルに実現することはできません。

古くから、シェルで一つの出力を複数プロセスへ分岐させる手段として、FIFO (名前付きパイプ) と`tee`コマンドを組み合わせる方法が知られています。W. Richard Stevensの「Advanced Programming in the UNIX® Environment」でも、具体的なコード付きで紹介されています。

```sh
mkfifo fifo1
prog3 < fifo1 &
prog1 < infile | tee fifo1 | prog2

# 出典: W. Richard Stevens, Stephen A. Rago. Advanced Programming in the UNIX® Environment, Third Edition
```

ですが、正直に言って面倒ですよね。スクリプトファイルならともかくコマンドラインでこれをやろうとは思えません。FIFOの削除も意識しなければなりません。

## ワンライナーでやる

プロセス置換 (Process Substitution) に対応したシェル限定ですが、プロセス置換を活用することで上記のコードをワンライナーで書くことできます。FIFOの削除も気にする必要がありません (Bash on GNU/Linux環境では`/dev/fd/n` (実体はパイプ) を通じて入出力が行われます)。

```sh
prog1 < infile | tee >(prog3) | prog2
```

`<(list)`と比べて、`>(list)`のプロセス置換は利用頻度が圧倒的に少ないと思いますが、こういうときに利用できます。パイプを分岐したいユースケース自体もあまり多くありませんが、例えばネットワーク経由で大きなデータを取得して異なるパターンの集計や加工を行いたいとき等に、データ取得を1回で済ませて一時ファイルも作らずワンライナーできれいに片付けることができるので、シェル芸人にはきっと役立つでしょう。

プロセス置換の具体的なユースケースは、TLDPの[Advanced Bash-Scripting Guide](https://tldp.org/LDP/abs/html/process-sub.html)等でもたくさん紹介されているので参考にしてみてください。

## 参考文献

* W. Richard Stevens, Stephen A. Rago (2013). [Advanced Programming in the UNIX® Environment, Third Edition](https://learning.oreilly.com/library/view/advanced-programming-in/9780321638014/). Addison-Wesley Professional
* Mendel Cooper (2014). [Advanced Bash-Scripting Guide](https://tldp.org/LDP/abs/html/index.html)
* [Bash Reference Manual](https://www.gnu.org/software/bash/manual/bash.html)
【AWS】個人のAWSアカウントに請求が来て驚いた話

# 発端
>AWS Innovate にご参加いただき誠にありがとうございました。ご参加いただきました皆様の中で、5 つ以上のセッションをご視聴いただいた方へ、AWS クレジット 25 USD をご案内いたします。

先日受講した[AWS innovate](https://aws.amazon.com/jp/events/aws-innovate/apj/modern-apps/?trkCampaign=innovate-mad-apj&trk=19f9b5e7-161e-40bb-9f5c-580532a87768)をそれはもう大変マジメに良く聞いた関係で、
AWSから期限付きのAWSクレジットを25ドル分も頂けてしまったので、
ひゃっほーい！と私個人のAWSアカウントにクレジット突っ込んで、
何かしらの遊びに使おうと思ったという、欲望でいっぱいな話である。

# 何が起きたか
久しぶりに個人のアカウントを開いて、クレジットコードを入力する為に、
請求画面をワクワクしながら開いた瞬間の事。

![b71d02bd-ffbd-9490-c4b8-55a38fa4396b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/d018a2a4-190e-7a54-aaf1-d46bae602d17.png)


アイエエエ!?ボクオカネカカルコトシテナカッタヨ!?
ニンジャ!?ニンジャナンデ!?

# 調査
このままだと私のクレジットカードから、お金が引かれてSAN値が減少する。
お財布の中身＝体力も減少するので、気絶ロールを振る事になる前に早急に調査を進めた。

まずはどこのサービスから料金が発生しているか、が問題である。
![4b0f8218-eda5-6e4b-5567-a765cbbacba4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/24b2984a-ae2d-860c-2186-aabccb757a79.png)
うむ。EC2で確定。

となると、以前コードを書くのに使った、
Cloud9が起動したままになっているのか？確認する。
![f5647776-38a5-0f81-6547-091d4c99729b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/63ad68d2-a4d0-c80c-45c1-fa22efedcda1.png)


止まってんじゃん。
個人用のCloud9は久しく起動していないし、何にせよ無料枠があるはずである。
9月は掛かっていなくて、10月と11月に料金が発生している。
…ん？9月は掛かってないよな？あれ？無料枠？

![5022fbbb-d8ae-72b7-030c-6be103aebc44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/a7caf510-0522-efcd-7c05-ac4c9ec0ebb5.png)

::: note warn
AWSのEC2の無料枠はサインアップしたあと12か月間無料です。
::: 

**アァァーーーー！！**

どうやら2023年9月で12か月間の無料枠が無事終了していた模様。
あれー…？でもEC2(Cloud9)は止めていたような…？

# 原因
EBSはEC2が止まっているかどうかなんて関係ない。無条件課金です。
![c06c01a8-87bf-258b-f173-1753a5c90170.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/71513c2f-a8d9-e9bd-36b7-538490d6da54.png)


EBSとは、EC2が利用するいわゆるHDD。ボリューム。
EC2は起動中のみの課金だが、EBSはサイズに応じた金額×存在していた時間になる。
今回は東京リージョンで、gp2なので、10GiB x 0.12(USD/M) = 1.2USDという流れ。
皆様も是非、お気をつけ下さい。
個人のアカウントを持っている方は、たまに金額だけはチェックした方が良い。
尚、自分のCloud9環境は即刻削除した。しょうがないね。

# 結末
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737208/2ff582a2-1c26-c59c-9b4d-0959909617e3.png)

払いました。**頂いたAWSクレジットで。**
10月分はクレジットカードから引かれた後だった。クッ。気付かなかったわ。
せっかくの$25が目減りしたが、やむない。

しかしながら、この残ったクレジットをいかに **使い切るか** が問題なんだ。

クレジットの期限迫る！
執筆時点、11月分の使用料を支払った以外、$1も使ってない！
ただ、もらった物をドブに捨てる訳には行かねぇ！

次回、AWSクレジットを使い切る編。本当にやるかどうかは不明。
読書感想文　11月

## 11月に読んだ本
『統計でウソをつく法  -数式を使わない統計学入門-』(ダレル・ハフ 著, 高木秀玄 訳)を読みました。この本は、大学の先生の紹介で知りました。
身近に使われている数字の中に統計があります。内閣支持率や街頭インタビューの結果など〇〇%のような数字やグラフでまとめられ公表されます。また、製品のプレゼンでは、「この製品の導入で、業務効率が50%向上!」と統計結果を提示することがあります。このような"数字"を説明の根拠にあげることで、説明の説得力が増します。しかし、数字を鵜呑みすることで騙されたり、誤った統計を提示することで不信感を与えたりすることもあります。あらゆる情報が出回る世の中で"数字"と上手に付き合っていくために改めてこの本を手に取りました。

## 概要
本書は、数字で人を騙す方法を9章にわたって豊富な事例を用いて紹介しています。タイトルにもあるように数式は一切出てきません。グラフの描き方やサンプルの取り方といった直感的に理解できる内容を事例にあげて説明しています。
本書に書かれている内容の一例を紹介します。雑誌の読者調査のため、あらゆる場所で、あらゆる種類の人に「普段どのような雑誌を読みますか？」とインタビューしました。その結果、多くの人が「学術誌A」と答え「娯楽雑誌B」と答えた人数を大きく上回りました。この結果は果たして正しいでしょうか？当時の出版部数を見ると、娯楽雑誌Bは、学術誌Aの部数の10倍以上でした。一般的に考えれば娯楽雑誌Bと答える人が多いはずです。では、なぜ調査結果では学術誌Aと答える人が多かったのでしょうか？回答者が見栄をはってウソをついていることが原因として考えられます。これを見て、しょうもないと思う方がいるかと思いますが、十分考えられる原因です。今回のインタビューは、調査対象に偏りがなかったものの、研究者を対象に調査すれば、今回の調査結果は簡単に捏造できます。サンプルの取り方次第では、調査結果から導き出される結果を捻じ曲げることができます。

## 学び
数字の裏を考えることが大切だと学びました。サンプルは適切か、情報の発信源、隠されたデータ(調査母数など)はないか疑うことで、騙される可能性を減らすことができます。また、自身が情報を発信する時、数字を読み取るための情報を開示することで、情報の信頼性を上げることができます。

## 最後に
本書は、数字に関わらず、情報に騙されない術を学ぶ本としておすすめです。不特定多数が簡単に情報を発信できる時代です。正しい情報もあれば、誤った情報、中には意図的に人を騙す情報もあふれています。騙されないためにも、情報の疑い方を本書で学んでみてはどうでしょうか？
pyenvでinstallのビルドが失敗した時の解消法

### 背景
pyenvでPython3.6をインストールしようとしたらビルドが失敗してしまった。
```zsh
BUILD FAILED (OS X 14.1.2 using python-build 20180424)

Inspect or clean up the working tree at /var/folders/_q/p7r22lmn5dn_6zlcvbrmmgqc0000gn/T/python-build.20231220180512.39601
Results logged to /var/folders/_q/p7r22lmn5dn_6zlcvbrmmgqc0000gn/T/python-build.20231220180512.39601.log

Last 10 log lines:
                case upgrade in \
                        upgrade) ensurepip="--upgrade" ;; \
                        install|*) ensurepip="" ;; \
                esac; \
                DYLD_LIBRARY_PATH=/var/folders/_q/p7r22lmn5dn_6zlcvbrmmgqc0000gn/T/python-build.20231220180512.39601/Python-3.6.15 ./python.exe -E -m ensurepip \
                        $ensurepip --root=/ ; \
        fi
dyld[53570]: missing symbol called
/bin/sh: line 1: 53570 Abort trap: 6           DYLD_LIBRARY_PATH=/var/folders/_q/p7r22lmn5dn_6zlcvbrmmgqc0000gn/T/python-build.20231220180512.39601/Python-3.6.15 ./python.exe -E -m ensurepip $ensurepip --root=/
make: *** [install] Error 134
```
エラーを見てみても原因はわからなかった。
### 対処
とりあえずhomebrewを最新にアップデートしてみた。
```zsh
brew update
brew upgrade
```
それでもエラーが出たので brew doctor で警告が出ていないか見てみた。
どうやらHomebrewが/opt/homebrew以外にインストールされているらしい...
```zsh
Warning: Your Homebrew's prefix is not /opt/homebrew.

Many of Homebrew's bottles (binary packages) can only be used with the default prefix.
Consider uninstalling Homebrew and reinstalling into the default prefix.
It is expected behaviour that some formulae will fail to build in this unsupported configuration.
It is expected behaviour that Homebrew will be buggy and slow.
Do not create any issues about this on Homebrew's GitHub repositories.
Do not create any issues even if you think this message is unrelated.
Any opened issues will be immediately closed without response.
Do not ask for help from Homebrew or its maintainers on social media.
You may ask for help in Homebrew's discussions but are unlikely to receive a response.
Try to figure out the problem yourself and submit a fix as a pull request.
We will review it but may or may not accept it.
```

公式を見ながらHomebrewを再インストール
https://github.com/Homebrew/install
そしてもう一度pyenvでpython3.6 をインストールしてみる
```zsh
$ pyenv install 3.6
WARNING: The Python lzma extension was not compiled. Missing the lzma lib?
Installed Python-3.6.15 to /Users/<path>/.pyenv/versions/3.6.15
```
なんかエラーは出たけどインストールできたっぽい？
一応versionsで確認してみる
```zsh
$ pyenv versions
  system
  2.7.18
  3.2.6
  3.6.15
  3.8.7
* 3.9.4 
  3.9.10
  3.10.9
```
インストールできていた。
### まとめ
pyenvでインストールが失敗する場合は、"brew doctor" で警告が出ていないか見てみるとよいかも。
今回はHomebrewのインストール先が推奨されていない場所だったため失敗していた可能性が高い。（他のエラーも考えられるかもしれないから警告をチェックする）