OmniAICreator/Qiita-1.07M huggingface dataset:
DatabricksのAI PlaygroundによるLLMの動作確認

こちらのプレビュー機能です。

https://docs.databricks.com/ja/machine-learning/foundation-models/supported-models.html#chat-with-supported-llms-using-ai-playground

:::note info
**プレビュー**
本機能は[パブリックプレビュー](https://docs.databricks.com/release-notes/release-types.html)です。記事の執筆時点では日本リージョンではまだ利用できません。
:::

Databricks Foundation Models APIで利用できるLLMの動作確認をクイックに行いたい場合に活用できるのがAI Playgroundです。

<iframe width="560" height="315" src="https://www.youtube.com/embed/IQtxL7qmi_8?si=n_aq2nFzzUrsNAHQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

有効化されているワークスペースであれば、サイドメニューに**Playground**が表示されます。ロボ。
![Screenshot 2023-12-24 at 10.44.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/f18b519c-1fdc-5a66-fc5a-a1ac2d24797b.png)

画面構成はこのようになっています。
![Screenshot 2023-12-24 at 10.44.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/bd0fe7d7-fc71-1f24-f1d1-9ac5edd52de0.png)

左上のドロップダウンリストからLLMを選択します。
![Screenshot 2023-12-24 at 10.45.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/1f89a5be-c0fc-edb1-687a-5c9cfa4ec170.png)

右上の設定ボタンでパラメータを変更できます。
![Screenshot 2023-12-24 at 10.45.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/836216d2-9312-7b45-2d40-fd5e428be4d6.png)

**+** ボタンを押すとチャットウィンドウが追加できるので、レスポンスの比較を行うことができます。
![Screenshot 2023-12-24 at 10.46.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/1065126b-65f2-e039-608c-d3f30d7f38a8.png)

**Sync chats**にチェックがついていれば、プロンプトが両方のウィンドウに反映されるので、容易にレスポンスを比較できます。便利。
![Screenshot 2023-12-24 at 10.47.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/5fd6e969-f4d8-3a65-b6f5-1e4667c8064c.png)

ウィンドウ右上の **< >** をクリックすると、モデルエンドポイントへのリクエストのcurlコマンドが表示されます。プログラムに組み込むなどのケースで役立ちそうです。
![Screenshot 2023-12-24 at 10.49.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/e4206923-9d53-7a76-c77a-b7a80350dada.png)

そして、**System Prompt**は編集できます。以下のようにレスポンスを日本語にすることも可能です。

> あなたはDatabricksのエキスパートです。日本語でレスポンスをしてください。

![Screenshot 2023-12-24 at 10.51.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168882/6408e890-98d7-745c-7208-d8ffb12ca380.png)

LLMを用いたシステムの構築は自然言語による試行錯誤が多く発生することになるかと思います。期待した挙動をさせるにはどのようなプロンプトが良いのかを検証するには便利なツールかと思います。日本で利用できるようになりましたら是非お試しください！

### Databricksクイックスタートガイド

[Databricksクイックスタートガイド](https://www.amazon.co.jp/dp/B09V1YXFVQ/)


### Databricks無料トライアル

[Databricks無料トライアル](https://databricks.com/jp/try-databricks)
Solr入門(tokenize入門)

# はじめに
Mars Flag Advent Calendar 2023 25日目担当の菅です。機能に引き続きよろしくお願いします。

前回は、弊社マーズフラッグが検索を扱う会社であることから、24日では、検索OSSであるSolrを使って、検索の体験をできる環境を整えました。
今回は、日本語を検索する際に必ずといっていいほど必要になってくるtokenizeについて体験してみましょう！！
※本記事は、「[Solr入門(Solrを動かしてみよう！！)
](https://qiita.com/suga_MARSFLAG/items/3d5f2f4c8c19c25dd8b0)」にて作成した環境で実施しています。

# 1. tokenizeとは
文章を単語に分割することを「tokenize」と言います。
検索を行う際にSolr側で文章をそのまま理解することができないため、tokenize等の前処理を行い、検索精度を高めます。
今回は、日本語検索でよく用いられる
* 意味ベースでtokenizeする形態素解析
* 文字数ベースでtokenizeするNgram

の二つを体験してみましょう。

# 2. 形態素解析
## 2-a. 形態素解析とは
形態素解析とは、事前に用意した辞書を用いて、文章内の単語毎(形態素)に分割することを言います。
```text: 形態素解析例
関西国際空港
↓
関西 | 国際 | 空港
```
 Solrでは、形態素解析を用いることで、検索語内の単語を分析し、検索の意図を汲んだキーワードマッチングに役立ちます。
 ただし、辞書上に載っていない固有名詞などの単語を分析できない欠点もあります。

## 2-a. 形態素解析を使ってみよう
Solrでは日本語に対する形態素解析が標準で搭載されていますので今回はそちらを試してみます。
1\. [http://localhost:8983/solr/#/gettingstarted/analysis](http://localhost:8983/solr/#/gettingstarted/analysis)上にアクセスし、
「Field Value (Index)」に関西国際空港と入力

2\. 「Analyse Fieldname / FieldType」に「text_ja」を選択し「Analyse Values」ボタンをクリック
形態素解析結果が表示されます
![形態素解析.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3528619/9f543b54-c93a-beb0-25b2-10a46c744abd.png)
分割されている様子が確認できます。

# 3. Ngram
## 3-a. Ngramとは
意味を考慮するNgramに対し、意味を考慮せず単語をN文字毎に分割し検索を行う手法です
例えば、「関西国際空港」をN=2で分割すると下記の様になります
```text: Ngram例
関西国際空港
↓
関西 | 西国　 | 国際 | 際空 | 空港
```
 Solrでは、Ngramを用いいることで検索漏れを防ぎます。
ただし、Nを小さくするほど検索数が増える一方、欲しくない情報も検索に引っかかってしまう検索ノイズが発生しやすくなります。

## 3-b. Ngram用Tokenizerの作成
残念ながら標準にNgramのみのtokenizerがないため、tokenizerの作成を行います。
1\. [http://localhost:8983/solr/#/gettingstarted/schema](http://localhost:8983/solr/#/gettingstarted/schema)にアクセスし、
「Manipulate Field Type」ボタンをクリック。

2\. 表示されるeditorに下記を入力
  ```json:tokenizer設定
  {
      "add-field-type": {
        "name": "nGram",
        "class": "solr.TextField",
        "positionIncrementGap": "100",
        "analyzer": {
          "tokenizer": {
            "class": "solr.NGramTokenizerFactory",
            "minGramSize": "2",
            "maxGramSize": "2"
          }
        }
      }
    }

  ```
  参考： https://solr.apache.org/guide/solr/latest/indexing-guide/tokenizers.html#n-gram-tokenizer


3\. 「Add FiledType」をクリック
![tokenizer作成.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3528619/7b74d76c-7f93-3519-a1b0-d8c3795a3338.png)

## 3-c. Ngramを使ってみよう
作成したnGramを試してみます。
1\. [http://localhost:8983/solr/#/gettingstarted/analysis](http://localhost:8983/solr/#/gettingstarted/analysis)上にアクセスし、
「Field Value (Index)」に関西国際空港と入力

2\. 「Analyse Fieldname / FieldType」に「nGram」を選択し「Analyse Values」ボタンをクリック
![nGram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3528619/ece4989b-7952-7efd-d8f6-de20ea204ece.png)
分割されている様子が確認できます。
50歳台で情報処理安全確保支援士試験に1発合格しました

# はじめに
　令和5年春期に情報処理安全確保支援士の試験を受験して、1回の受験で合格できました。ちょうど1年前の今頃に勉強を始めていたので、これから受験する人の参考になればと思い、合格体験記を書きました。

# 筆者の職業、ステータス
　受験時は52歳のオッサンです。40歳台までは主に新システムの研究と開発に携わっており、特にセキュリティに特化した業務は担当していませんでした。50歳になって機密情報管理などの部門セキュリティ管理の仕事に携わることになり、支援士試験を受けてみようと思いました。普段の業務は社内手続きや社規を守った運用支援がメインで、支援士試験に頻出するWebアプリの脆弱性対策やアクセス制御・マルウェア対策などの業務は行っていないので、試験向けにしっかり勉強しました。
　また、一切免除なしで午前1～午後2まで受験するのは体力が持たないと思ったので、まずは令和4年秋期に応用情報技術者試験を受験して一発合格していました。

# 勉強したこと
### 午前対策
　参考書（徹底攻略　情報処理安全確保支援士教科書、インプレス）をひたすら読み込みました。試験の4か月前くらいから毎週末に勉強しました。午前2はとにかく参考書をしっかり覚えれば大丈夫です。最新のセキュリティ技術やマルウェア等を反映した問題も出るかと思ってTwitterで情報収集してましたが不要でした。60点以上で合格なので、参考書に載っている知識で解ける問題を取りこぼさなければ、まず落ちないと思います。

### 午後対策
　過去問をひたすら勉強しました（令和元年～直前分）。たぶんこれだけでも大丈夫とは思いますが、一応参考書として「情報処理安全確保支援士　午後問題徹底解説、技術評論社」も勉強しました。あまり色々な参考書に手を出すよりも、過去問をしっかりやって、判らない部分は調べて知識を補強する、ということを繰り返す方が効率が良いと思います。あとは本番に慣れるため、時間を測って、回答も指定文字数に納まるように練習しておくと試験当日も焦らずに済みます。一応「ポケットスタディ　情報処理安全確保支援士、秀和システム」も買いましたが、こちらはしっかり勉強するというより、気分転換に読むといった感じでした。

# 試験時のコツ
### 前日は良く寝て、体力温存しておく
　50歳台になるととにかく体力・集中力が落ちてます。長時間の試験なので、なるべく前日は良く寝て、少しでも体力を蓄積しておくことをおすすめします。私は試験中に疲れで目が霞んで試験問題がぼやけて見えるようになったので、ひたすら目薬を差して頑張りました。

### 昼食は食べない
　午後1の試験時間は90分、午後2は120分と長時間です。私は試験中にトイレに行きたくなったら困るので昼食は抜きました。

### 選択問題の時間配分を誤らない
　私は午後1の試験の途中で選択問題を変えてしまったので、時間が足りなくなりました。途中で変えると時間が足りなくなって焦るので、なるべくなら変えない方が良いです。（でも解いてる途中に自信がなくなって、他の問題に変えたくなるんですよね…）

### 記述式問題は、正解が判らなくても頑張って何か書く
　部分点があるかは判らないのですが、ずばりの正解が判らなくても、それらしい何かを頑張って書いた方が良いと思います。年齢が高ければ経験値も高いので、何かしらはきっと書けるはずです。

# 結果
　幸いにも1回で合格できました。しかし点数はイマイチで、午前2は70点台。午後1と午後2はどちらも60点台でした。ただ60点以上で合格なので、結果オーライです。

# おわりに
　受験は知力だけでなく、体力もある程度は必要なので、受けるならできれば若いうちの方が良いです。でも50歳台でも勉強すればちゃんと受かりますので、是非頑張って下さい。逆に50歳台で受けて良かった点は、試験当日の朝にちゃんと起きられることです！　またIPAがプレスリリースで合格者の年齢構成や最年長記録も発表しているので、自分がレアキャラである感が味わえます。
　受験される皆さま、合格目指して勉強がんばって下さい！
あなたのDLモデルをブーストするちょっとしたtips

本日はbotterアドベントカレンダー25日目の記事として、僕が普段行っているDeepLearningモデルの開発tipsの中でも、大昔から使っている任意のモデルに対して適応可能な金融データのモデリングでも使えるちょっとしたtipsとその面白い関係性について紹介したいと思います。
botterの皆さんが仮想通貨スペシフィックな非常に面白い記事や超大作を書いている中、非常に特化した小さい記事になってしまいますが、一部の方に刺さるとうれしく思います。

### Monte Carlo Dropout

Dropout as a Bayesian Approximation: Representing Model Uncertainty in Deep Learning: https://arxiv.org/abs/1506.02142

上記論文にて出てくるテクニックです。論文趣旨を要約するのであれば、Dropoutを用いるとDLの出力は近似的にベイズ推論となっているということを証明している論文です。Dropoutを推論時に有効化することで、各レイヤーの重みの分布からサンプリングをしていることになり、何度も繰り返すことで出力の分布を得ることができます。
これによって得られたモデルの出力の平均値を最終的な出力として使うことにより、予測精度の改善を得ることができます。一方で、推論時に多数のサンプリングを行う必要性があるため、推論コストは数十倍必要になってきます。

### Stochastic Weight Averaging(SWA)

Averaging Weights Leads to Wider Optima and Better Generalization: https://arxiv.org/abs/1803.05407

上記論文にて出てくるテクニックです。同じく要約すると、SGDで最適化中にモデルウェイトの移動平均を同時に計算し、推論時にはウェイトの移動平均を用いるアプローチで、これによりフラットな解に到達しより良い汎化性能を得られるようになります。
こちらもマーケット予測でも有効で、モデルの予測精度を改善することが多いです。

以上２つのテクニックが今回の記事で紹介するtipsになります。

個人的に非常に面白いなと思った点と関係性についてアペンディックスとして話していきます。Monte Carlo Dropoutはもともとモデルの不確実性を測るためのアプローチとして研究されてきたうちのドロップアウトの特性証明の論文の一つです。一方もともとSWAのアイディアはロスサーフェスと汎化性能の関係性に対する議論から出てきていて、FastGeometric Ensembling(https://arxiv.org/pdf/1802.10026.pdf) がその前身となるアイデアとなっています。２つの論文は全く別々のコンテキストから生まれてきたものではありますが、推論時の数式は非常に近似しておりとても興味深いなと思ったことを覚えています。

前者は推論時にウェイトにノイズを載せて最終的にモデル全体の出力の平均をとる形で、後者はノイズを加えたウェイトの平均をもとにモデルの出力をとる形です。ノイズが微小な変動を表現していると解釈するならば、２つの手法はかなり近似的な役割を果たしています。それを反映してなのか、SWA後にMC Dropoutを行った際に得られるパフォーマンスのブーストはかなり限定的であり、SWA単体で実装するだけで十分な効果が得られることが多いように思います。SWAは推論時にサンプリングが必要ないため、MC Dropoutよりも非常に高速かつ精度の高い予測を得ることができ、特に短期の予測モデルを作っている方にとってはうれしい手法なのではないかと思います。

以上、短くなってしまいましたがtipsの紹介でした。皆さんのDLモデルが改善しますように！
ABC334回答メモ

# 0.はじめに
　今年最後のABCということで気合を入れて取り組みました。
　とこらがB問題で大ブレーキ。
　Cも一筋縄でいかなそうだったので、まさかのAだけフィニッシュかと
　諦めかけましたが、Dは簡単で気持ちを取り直せました。
　そのあとはB,Cも時間をかけて解き、時間一杯でA~DをACして
　2023年を締めくくりました。
　レートは+35で半年ぶり2回目の緑コーダとなりました。


# 1.A - Christmas Present
　BとGを比較しBが大きければバット、Gが大きければグローブを表示
　BatとGloveのスペルを正しく書けるかが一番の間違えポイントな気が
　しました

　https://atcoder.jp/contests/abc334/submissions/48736001


# 2.B - Christmas Trees
　最初は、RとLの差をMで割り、そこに、Rにツリーが立っていれば
　1を加えてはい終了。と思いましたが、例題３が1差で合いませんでした。

　おそらく、AがLとRの間にある場合とか、ALRが-とか+とかいろいろ
　関係あるのかと、ALRに10**18を足してみたりいろいろしても解けず
　最後は以下の考え方で解きました。

　【考え方】
　　・Aはツリーが立っている場所ならどこでもよい。
  　・AがLの左にあれば、A~R間のツリー数-A~L間のツリー数に
　　　Aにツリーが立っていたら+1を加えれば答えが求まる。

　上記に従い、新Aを算出してからそれにしたがいツリー数を求め
　無事ACでした。

　解説を見たら、Pythonは4行で解けてたので愕然としました。
　

　https://atcoder.jp/contests/abc334/submissions/48788455

# 3.C - Socks 2
　初見時は時間がかかりそうなのでスルー。
　戻ってきた時は残20分でしたが、なんとか行けそうかとトライ。

　一見残った靴下全部をどうにかするような問題かと思いきや
　結局両方残ってるのはそのまま使うのが最善なので、リスト内で
　どう組み合わせる問題なんだと気づきました。

　さらに、偶数余っている場合は全部組み合さざるを得ないので
　単純に先頭から組み合わせて差を集計すればOK

　奇数余ってる時は、どの靴下を使わないかを求める問題となりますが
　組み合わせは、靴下を抜く前後でずれるだけなので
　前からの差の累積和と後ろからの差の累積和を求めておき
　抜いた靴下によるずれが生じる前後で累積和を足した値を求め
　その差が一番小さい時が答えとなります。
　アルゴリズムの問題集とかに割とあるパターンですね。

　ギリギリ残り3分でACが取れたので喜びもひとしおでした。

　https://atcoder.jp/contests/abc334/submissions/48796541


# 4.D - Reindeer and Sleigh
　D問題にしては簡単な気もしましたが、難易度というよりは
　よくある問題なので解きやすかったのかもしれません。

　【考え方】
 　・与えられたトナカイ数で引けるそりの最大数を
 　　素早く求める
 　・事前準備でそりごとのトナカイ必要数リストを昇順ソートし
　　 i台目までのそりを引くのに何頭のトナカイが必要かのリストLを
 　　生成しておく
 　・Q毎にリストLを2分探索し、何台引けるかを求め出力

　苦手だった2分探索もbisectを知ってから、楽になりました。

　https://atcoder.jp/contests/abc334/submissions/48774758


以上
ARKitで現実のオブジェクトとインタラクトする【ARObjectAnchor】

**現実のものとARオブジェクトを関係を持たせて配置したい**。
箱の上にARオブジェクトを置くとか。
そのためには、３次元の物の位置と大きさをつかむ必要がある。
ARKitの平面検出や、FeaturePointでは、詳細に物体の形状を認識できない！
LiDARならポリゴンメッシュが取れるけれど、搭載端末は少ない。
機械学習で２次元の位置形状はとれるが、３次元への変換がむずかしい。

**スキャンして物体を登録しておいて検出してみよう。**
妥協策として、物体をあらかじめスキャンすることで、ARアンカーとして位置検出する方法がある。

![May-15-2021 10-08-22.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/235259/0b42d2e6-c0e3-d3b0-beb1-d831ed584003.gif)

#スキャン済みのオブジェクトを検出する

###スキャン済みオブジェクトの登録

Assets.xcassetsの+ボタンからAR Resorsesのフォルダを作って、.arobjectファイルをドロップします。

スキャンしたオブジェクトをARReferenceObjectとして登録し、detectionObjectsとしてまとめてARWorldTrackingConfigurationに設定してセッションを実行します。

```swift

let configuration = ARWorldTrackingConfiguration()
guard let referenceObjects = ARReferenceObject.referenceObjects(inGroupNamed: "gallery", bundle: nil) else {
    fatalError("Missing expected asset catalog resources.")
}
configuration.detectionObjects = referenceObjects
sceneView.session.run(configuration)
```

ARObjectファイルは、urlからも読み込めます。

```swift
let configuration = ARWorldTrackingConfiguration()
var referenceObjects = [ARReferenceObject]()

do {
    guard let referenceObject = try? ARReferenceObject.referenceObjects(archiveURL url: URL) else {
        fatalError("Missing expected referenceObject.")
    }
    referenceObjects.append(referenceObject)
} catch let error {
    fatalError("Couldn't initialized ARReferenceObject from URL.")
}
configuration.detectionObjects = referenceObjects
sceneView.session.run(configuration)
```

###検出したオブジェクト・アンカーの取得

sceneViewのrenderer内で検出したスキャン済みのオブジェクトを、オブジェクト・アンカーとして取得できる。

```swift
func renderer(_ renderer: SCNSceneRenderer, didAdd node: SCNNode, for anchor: ARAnchor) {
    if let objectAnchor = anchor as? ARObjectAnchor {
        print(objectAnchor)
    }
}
```

**取得できる情報**
オブジェクトアンカーの情報:
ID 
transform(translation:位置、rotation:座標)
スキャンしたオブジェクトの情報：
name
center
extent

位置だけでなく、元のオブジェクトの大きさやスキャン時に設定した中心も取れる。

>ARObjectAnchor: 0x282cc3540
 identifier="6238D5ED-9245-C2A5-F6A6-8B283A4748F6" 
transform= 
translation=(0.110339 -0.191025 -0.283564) 
rotation=(-0.97° -109.75° -5.06°)]

>referenceObject=ARReferenceObject: 0x2828c2d00 
name="Scan_09-11-54" 
center=(-0.001493 -0.019628 -0.001815) 
extent=(0.085925 0.106859 0.084746)



🐣
****
フリーランスエンジニアです。
AIについて色々記事を書いていますのでよかったらプロフィールを見てみてください。

もし以下のようなご要望をお持ちでしたらお気軽にご相談ください。
AIサービスを開発したい、ビジネスにAIを組み込んで効率化したい、AIを使ったスマホアプリを開発したい、
ARを使ったアプリケーションを作りたい、スマホアプリを作りたいけどどこに相談したらいいかわからない…

いずれも中間コストを省いたリーズナブルな価格でお請けできます。

お仕事のご相談はこちらまで
rockyshikoku@gmail.com

機械学習やAR技術を使ったアプリケーションを作っています。
機械学習／AR関連の情報を発信しています。

[Twitter](https://twitter.com/JackdeS11)
[Medium](https://medium.com/@rockyshikoku)
[GitHub](https://github.com/john-rocky)
Visual Studio Codeのインストール

以下ページより目的にあったOSをダウンロードして、インストール
https://code.visualstudio.com/download

マニュアルについては以下を参照
https://code.visualstudio.com/docs

Macの手順などについては、以下を参考にできる
https://code.visualstudio.com/docs/setup/mac
UnsafePointerでメモリのアドレスを見てみよう！

# ポインタとは
ポインタとは、変数のアドレスを記憶する変数のこと。ポインタを使うことで、アドレス先の値を取得したり、変更することができる！
アドレスはバイト単位の一次元配列であることを強調するため、バイトアドレスとも呼ばれる。オブジェクトのアドレスを取得するには、オブジェクト名の前に&演算子（アドレス演算子）を付ける。

**アドレス演算子**
```
&オブジェクト名
```

**オブジェクトaのアドレス**
```
&a
```

# UnsafePointerを使用し、アドレスを見てみよう！
UnsafePointerを使用して構造体のアドレス先の値を取得してみよう！
## UnsafePointerとは
特定のタイプのデータにアクセスするためのポインタ
`UnsafePointer<Int>`に変換し、アドレス先の値を取得することができる。

https://developer.apple.com/documentation/swift/unsafepointer

## UnsafePointerの使用例
Playgroundで使用してみよう！
### UnsafePointerのInt型の使用例
```Swift
var a = 10
var b = a
func action(a: UnsafePointer<Int>, b: UnsafePointer<Int>) {
    print(a)
    print(b)
}
action(a: &a, b: &b)
```
値型であるaオブジェクトとbオブジェクトのアドレスを`&`をつけることで表すことができ、`Int`から`UnsafePointer<Int>`に変換できる！

**出力結果は下記のようになる**
```
0x0000000102a04120
0x0000000102a04128
```
値型の構造体は、bは代入時点のaのコピーであり、aとbは別々の実体を示すので、aとbのメモリのアドレスも異なる。
8バイト数ずらしたアドレスにbは割り当てられている。

### UnsafePointerの構造体型の使用例
```Swift
 struct Info {
    var count = 0
}

class VC1 {
    var info: Info
    init(info: Info) {
        self.info = info
    }
}
func action(a: UnsafePointer<Info>) {
    print(a)
}
var value1 = Info()
var value2 = value1
value1.count = 10
value1.count //10
action(a: &value1)
value2.count //0
action(a: &value2)
```
**出力結果は下記のようになる**
```
0x00000001022e4340
0x00000001022e4348
```
aとbは別々の実体を示すので、aとbのメモリのアドレスも異なるため、value1を変更しても、valuewに値の変更が共有されないということです。

**※構造体とclassの違いがわからない方は下記を参考にしてみてください！**

https://qiita.com/hinakko/items/70c05a1abcc44fea5174
# 参考文献
https://ja.wikibooks.org/wiki/C%E8%A8%80%E8%AA%9E/%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF

https://qiita.com/kaneshin/items/ebabd4f44010568d550f

https://qiita.com/ysn/items/1029d5343c089d04c831

https://zenn.dev/kabeya/scraps/3251e0676aa504

https://youtu.be/pD9sk6QF1Ws?si=Co7F2DgUv5avl7CS
社内のデータ抽出・分析依頼の量の上限を決めてみた話

こんにちは、タイミーでデータアナリストをしているhatsuです！

今回は、データアナリストが日々対応している社内のデータ抽出・分析依頼（以下「依頼」とします）の依頼量の上限設定について、その目的と影響についてご紹介します。

なお、この記事は [Timee Advent Calendar 2023](https://qiita.com/advent-calendar/2023/timee) のシリーズ3、24日目の記事です。

アドベントカレンダーの他の記事もぜひご覧ください！

## なぜ依頼の量の上限を決めるのか

タイミーのデータアナリストが所属するBIグループでは、KPI指標をモニタリングするためのダッシュボードの作成や、業務で必要なデータの抽出など、データに関する幅広い依頼を社内メンバーから受け付け、日々対応しています。

しかし、会社が大きくなるにつれてこの依頼の量がどんどん増えていき、データアナリストが本来やるべきプロジェクトや分析に割く時間が次第に圧迫されるように…。

そこで、データアナリストが重要なタスクに割くリソースを確保できるようにするため、来た依頼すべてに対応するのではなく、「この期間内では最大N件までの依頼しか受け付けない」というように、対応する依頼の件数に上限を設けることにしました。

## 副次的に起こったこと

元々はデータアナリストのリソース確保のために設定した依頼量の上限でしたが、依頼量の上限設定をして良かったことはそれだけではなく、副次的な良い影響もいくつかありました。

その1つが、社内メンバーがBIツールを使ってみるきっかけになっているということです。

タイミーではLookerというBIツールを導入していて、社内のメンバーが必要なデータを簡単に抽出できるような環境を整えているので、このLookerを使えばデータアナリストに依頼せずとも基本的なデータの抽出やダッシュボード作成は自力でできるようになっています。

依頼の量を制限するということは、当然「対応できない依頼」が発生するのですが、これらの依頼で欲しているデータがLookerで出せるものであるケースは多く、その場合は自力でデータを出してもらうことをお願いしています。

タイミーにはまだまだLookerに馴染みのないメンバーや、Lookerの使い方に自信のないメンバーも多いのですが、そういったメンバーには使い方をまとめたドキュメントを共有したり、個別でLookerの使い方のレクチャーなどもしています。

## 今後やっていきたいこと

データアナリストへの依頼の量を制限したことで、社内ではLookerを使ったデータ抽出がより活発に行われるようになってきました。

しかしそれに伴い、Lookerの使い方でつまずいているという声や、Lookerを使っていく中でわからないことがあって困っているという声も多方面から聞かれるようになってきました。

社内で[Lookerの講習会](https://tech.timee.co.jp/entry/2023/11/15/120007)を定期的に開催するなど、一部すでに取り組んでいるものもあるのですが、今後よりLooker活用のサポート体制を整えていき、データアナリストのリソース確保と社内のデータ利活用推進の両立を図っていければと思っています。

## **We’re Hiring！**

タイミーのデータ統括部では、私たちとともに働くメンバーを募集しています。

現在募集中のポジションは[こちら](https://hrmos.co/pages/timee/jobs?category=1814216944314011650)です。

[カジュアル面談](https://devenable.timee.co.jp/casual)も行っていますので、興味を持っていただけた方は、ぜひお話しさせてください！
NestJS でホットリロードを行う

# はじめに
この記事では、NestJS でホットリロードを行う方法について記載していきます。

```npm run start``` でローカルサーバーを起動して開発をしていると、コードを変更して動作確認をする際、ローカルサーバーを再起動しないと変更が反映されません。そのため、ローカルサーバーを再起動しなくても変更を反映できるようにする方法について記載していきます。

# 方法1：```npm run start:dev```
```npm run start:dev``` でローカルサーバーを起動すると、ホットリロードを行うことができます。

:::note

```package.json``` 内で定義されているように ```start:dev``` の中身は ```nest start --watch``` です。

```package.json
"start:dev": "nest start --watch"
```
:::

# 方法2
NestJS のこちらのドキュメントに記載の手順で実施できます。

https://docs.nestjs.com/

# 参考
- [First steps](https://docs.nestjs.com/first-steps)
- [Hot Reload](https://docs.nestjs.com/)
B - Christmas TreesをElixirで解いた〜ユニークビジョンプログラミングコンテスト2023 クリスマス (AtCoder Beginner Contest 334)

ユニークビジョンプログラミングコンテスト2023 クリスマス (AtCoder Beginner Contest 334)の B - Christmas Trees をElixirで解いたので，報告します．

## 問題

https://atcoder.jp/contests/abc334/tasks/abc334_b

## 最終的な解答例

https://atcoder.jp/contests/abc334/submissions/48810731

```elixir
defmodule Main do
  def main() do
    [a, m, l, r] =
      IO.read(:line)
      |> String.trim()
      |> String.split(" ")
      |> Enum.map(&String.to_integer/1)

  IO.puts(Integer.floor_div(r - a, m) - Integer.floor_div(l - 1 - a, m))
  end
end
```

[`Integer.floor_div/2`](https://hexdocs.pm/elixir/1.16.0/Integer.html#floor_div/2)という便利関数があったので，それを使用したら，こんなに簡潔なコードになりました．

`Enum.map(l..r, fn x -> Integer.floor_div(x - a, m) end)`として，プロットしてみると，動きがわかるのではないかと思います．

## １つ前の解答例

https://atcoder.jp/contests/abc334/submissions/48810596

```elixir
defmodule Main do
  def main() do
    [a, m, l, r] =
      IO.read(:line)
      |> String.trim()
      |> String.split(" ")
      |> Enum.map(&String.to_integer/1)

    first_tree_pos = 
      case rem(l - a, m) do
        0 -> l
        rm when rm < 0 -> l - rm
        rm -> l + m - rm
      end  

    last_tree_pos =
      case rem(r - a, m) do
        0 -> r
        rm when rm < 0 -> r - rm - m
        rm -> r - rm
      end

  IO.puts(div(last_tree_pos - first_tree_pos, m) + 1)
  end
end
```

$L$に最も近い木の位置を`first_tree_pos`とします．同様に$R$に最も近い木の位置を`last_tree_pos`とします．`last_tree_pos - first_tree_pos`を`m`で割り，1を加えると，木の本数になります．

`rem/2`関数と`case`文を使ってそれぞれ求めます．`rem`関数は，あまりを求める関数ですが，負の値を割るときに結果も負になるという特性がありますので，注意が必要です．0の場合，正の場合，負の場合で場合わけをします．

## 素朴な解答例

https://atcoder.jp/contests/abc334/submissions/48810216

```elixir
defmodule Main do
  def main() do
    [a, m, l, r] =
      IO.read(:line)
      |> String.trim()
      |> String.split(" ")
      |> Enum.map(&String.to_integer/1)

    l..r
    |> Enum.count(fn x ->
      rem(x - a, m) == 0
    end)
    |> IO.puts()
  end
end
```

愚直に範囲`l..r`の中で，`rem(x - a, m) == 0`となる数を数え上げています．TLE(実行時間制限超過)となりました．

## 素朴な解答の改良例

https://atcoder.jp/contests/abc334/submissions/48810360

```elixir
defmodule Main do
  def main() do
    [a, m, l, r] =
      IO.read(:line)
      |> String.trim()
      |> String.split(" ")
      |> Enum.map(&String.to_integer/1)

    [first_tree_pos] =
      Stream.unfold(l, fn x -> {x, x + 1} end)
      |> Stream.drop_while(fn x -> rem(x - a, m) != 0 end)
      |> Enum.take(1)

   [last_tree_pos] =
     Stream.unfold(r, fn x -> {x, x - 1} end)
     |> Stream.drop_while(fn x -> rem(x - a, m) != 0 end)
     |> Enum.take(1)

  IO.puts(div(last_tree_pos - first_tree_pos, m) + 1)
  end
end
```

$L$に最も近い木の位置を`first_tree_pos`とします．同様に$R$に最も近い木の位置を`last_tree_pos`とします．`last_tree_pos - first_tree_pos`を`m`で割り，1を加えると，木の本数になります．

`first_tree_pos`と`last_tree_pos`は地道に数え上げています．[`Stream.unfold/2`](https://hexdocs.pm/elixir/1.16.0/Stream.html#unfold/2)を使いました．

これでもまだTLE(実行時間制限超過)となりました．
SIの醍醐味

NEXTSCAPE星名です。

少し経歴の話をしますが、私はNTT Communicationsという会社でシステム開発を請け負う仕事をしていました。
また、タワーレコードではIT部門の責任者として自社のシステムの開発をITベンダーに発注するという仕事もやってきました。
その中で体験したエピソードを紹介します。

 **（１）某レコード会社のECサイトリニューアル**
人気のアーティストを多く抱える某レコード会社のECサイトのリニューアル案件を受託して、年末のその頃人気があったグループのCD＆グッズ販売に合わせてリリースするスケジュールで開発を進めていましたが、ギリギリ間に合うかどかの瀬戸際で、リリース前には何日も会社に泊まり込みで対応しました。
お客さん側の責任者の方も我々のオフィスまで何度も足を運んで、仕様や進捗の確認をするだけでなく、その度に差し入れをしていただきました。
その甲斐あって何とか発売に間に合わせてリリースをしたのですが、消費税を計算して請求するところがバグっていて、お客様から消費税を取り忘れるという障害を出してしまいました。
人気のグループですから、当然大量に予約注文が入っており、後から消費税だけお客さんに請求する訳にもいかないので、消費税分をこちらが肩代わりするという決着となりました。
最初こそ失敗しましたが、その後は安定して動くサイトとしてお客さんにも信頼され、別のSI案件なども発注していただける関係を築くことができました。
今もそのサイトは開発は別のベンダーさんがやっていると思いますが、その頃と同じ名前で運営されています。

 **（２）某CDレンタル会社の音楽配信サイトの構築**
NTT CommunicationsはOCNというプロバイダー事業をやっていましたが、OCNでも音楽配信サービスを始めようという事で音楽配信のプラットフォームを構築し、自社のサービスで活用すると共に横展開して様々な企業の音楽配信サービスをSIで受託するという構想を展開しました。
その中で某CDレンタル会社の音楽配信サイトの構築を受託したのですが、CDレンタルを生業としている会社が音楽配信のビジネスを新たに始めるので、お客さん側に知見がある訳ではなく、毎週のようにお客さんの責任者の方々と一緒にシステム以外の部分も含めて議論をしていました。
しかし、最後の最後でお客さん側の経営判断で音楽配信サービスは頓挫し、我々と相対していた責任者の方々は悉く会社を去るという事となってしまいました。
社内政治に利用された形でしたが、それまで構築したコストのウン億円は支払っていただき、その責任者の方々とは別の会社となってからも付き合いは継続して、何かの機会で仕事をご一緒する事もありました。
おまけですが、OCNの音楽配信をやっていた私の若かりし頃の記事が残っていましたので貼っておきます(^^;
ここで一緒にプレゼンしたレコード会社の方とは、それぞれ会社が変わった今でも年に何度か近況報告会をする間柄になっています。
[NTT Com、音楽配信事業の現状と課題に関する説明会](https://internet.watch.impress.co.jp/cda/news/2004/07/23/4005.html)

**（３）タワーレコードのECサイトリニューアル**
これは私がタワーレコードでECサイトをリニューアルするウン億円のプロジェクトの責任者だった時の話ですが、最終的には3社のコンペで発注先のベンダーさんが決まりました。
タワーのメンバーもその頃はシステム開発が専門という訳でも無かったので、毎週毎週何日もベンダーさんの会議室にメンバー全員で集まって一緒に仕様を検討したり、進捗を確認したりという事をやっていました。
ところが、リリース近くになって仕様の変更が入ったり、思ったように実装が進まない状況が続き、結局リリースは延期。
請負契約のSIなので納品・検収が完了しないとお金を支払う事は出来ませんが、プライムで受注したベンダーさんは自社の開発メンバーよりもSESで発注していたメンバーの方が多いような状況だったので、出ていくお金は減らない。
また、そのベンダーさんは、大手SIerのグループ企業という訳ではなく、独立系のオーナー会社だったので、その社長はタワーのプロジェクトの延期で非常に苦しい状況に陥って、何度も彼と色々な相談をした事を覚えています。
でも、何とかリリースまでこぎつけ、その後タワーレコードのECは私が居た頃は年商30億くらいだったのが、今ではその10倍にもなろうとしている状況で、昔は私の部下だったメンバーが今でも何人かは残って頑張ってくれています。

**結局何が言いたいかというと・・・**
割と失敗した案件の事ばかり書いていますが、もちろん上手く行ったプロジェクトも沢山あります。
でも、たとえ失敗したとしても、その時一緒にプロジェクトを推進してくれた方々とはその後何年経っても立場が変わっても、何かあればお互い声をかけてもらえる関係が築けているのはとても幸せな事だと思っています。
また、自分が携わった仕事が世の中に出ていく、お客さんに使われるという瞬間は毎回ゾクゾクするような興奮がありました。
だから私はSIが楽しいし、やめられない。（もちろん大変なコトも沢山ありますが・・・）
私のような体験をNEXTSCAPEの社員のみなさんにも味わってもらいたいので、これからもお客さんと直接相対する『プライムベンダーであるコト』には拘っていきたいと思っています。

それでは、みなさま、*Merry Christmas!!*
広告業界のターゲット区分（F1層、F2層）のまとめ

株式会社ビデオリサーチがテレビ番組の視聴率を集計する際、視聴者を以下のように区分しています

|男性|年齢|女性|
|---|---|---|
|C 層|4～12才|C 層|
|T 層|13～19才|T 層|
|M1 層|20～34才|F1 層|
|M2 層|35～49才|F2 層|
|M3 層|50才以上|F3 層|

これは広告業界において主流の区分となっています。この記事では 18 歳の新入社員向けにそれぞれの概要を紹介します。

# F1層
女性 20～34歳
20～34歳の女性は多くが独身のため自由に使えるお金を持っています。そのため強い購買意欲を持ち、積極的に自己投資し、トレンドに敏感な世代と言われています。

# F2層
女性 35～49歳
家庭を持ち、妻、母といった責任のある立場を任せられることが多い年代です。大型家電や日用品などの家庭の消費はF2層と密接に関係しています。また、美容や健康ジャンルに興味を持ち、自己投資も惜しまない傾向にあります。

# F3層
女性 50歳以上
子供が自立する年齢となるので、金銭的な余裕が生まれやすい世代です。値段よりも品質を気にかける傾向にあり、余暇や時間を楽しむためにお金を使います。

# M1層
男性 20～34歳
若く社会人としてバリバリ働く世代です。自分の将来のために、ビジネスやスキルアップなどキャリアに関心が高く、F1層と同様に自己投資に余念がないです。

# M2層
男性 35～49歳
家庭を持ち、大黒柱となる人が多い世代です。消費の決定権を持つ傾向が少なく消費活動は最も少ない年代です。食事やゴルフ、飲み会等の人付き合いにお金を掛ける傾向にあります。

# M3層
男性 50歳以上
子供が自立することによって経済力が目立ちます。消費活動が活発ですが量よりも質を求める傾向にあります。健康にも気を使い始め、運動や食事に心を配ります。

# T 層
男女 13～20歳
この年代は、SNSを活用してのコミュニケーションが密に行われています。情報が流れる速度は非常に早く、流行り廃りが重要視されます。実際、T層の口コミ力は大きく、流行を作り出すためには外せない世代です

# コア層
商品購買意欲の高い13歳から49歳までの層を指します。

# 区分毎の人数

![112.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/fdbf32f0-44ca-8959-69a2-5b2d68796038.png)

# 参考文献
- 視聴率基本の『キ』
https://www.videor.co.jp/digestplus/tv/2023/04/75947.html
- 総務省統計局 > 男女別人口推計
https://www.stat.go.jp/data/jinsui/2022np/index.html
PytorchモデルのCPUとGPUの使用率を取得する


```python
from torch.profiler import profile, record_function, ProfilerActivity


with profile(activities=[
        ProfilerActivity.CPU, ProfilerActivity.CUDA], record_shapes=True) as prof:
    with record_function("model_inference"):
        model(inputs)

print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))
```

>-------------------------------------------------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ---------
>Name    Self CPU %      Self CPU   CPU total %     CPU total  CPU time avg     Self CUDA   Self CUDA %    CUDA total  CUDA time avg    # of Calls  
>-------------------------------------------------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ---------
>model_inference        10.84%       6.598ms        55.50%      33.792ms      33.792ms       0.000us         0.00%      57.264ms      57.264ms             1  
                                           aten::conv2d         0.63%     381.000us        37.83%      23.032ms     182.794us       0.000us         0.00%      53.513ms     424.706us           126  
                                      aten::convolution         0.49%     301.000us        37.20%      22.651ms     179.770us       0.000us         0.00%      53.513ms     424.706us           126  
                                     aten::_convolution         2.24%       1.366ms        36.71%      22.350ms     177.381us       0.000us         0.00%      53.513ms     424.706us           126  
                                aten::cudnn_convolution        24.91%      15.165ms        29.84%      18.169ms     144.198us      50.862ms        88.82%      50.862ms     403.667us           126  
volta_scudnn_winograd_128x128_ldg1_ldg4_relu_tile148...         0.00%       0.000us         0.00%       0.000us       0.000us      24.387ms        42.59%      24.387ms     554.250us            44  
volta_scudnn_128x32_sliced1x4_ldg4_relu_exp_small_nh...         0.00%       0.000us         0.00%       0.000us       0.000us       4.449ms         7.77%       4.449ms       1.112ms             4  
                  volta_scudnn_128x32_relu_medium_nn_v1         0.00%       0.000us         0.00%       0.000us       0.000us       4.185ms         7.31%       4.185ms     119.571us            35  
volta_scudnn_128x32_sliced1x4_ldg4_relu_exp_interior...         0.00%       0.000us         0.00%       0.000us       0.000us       3.614ms         6.31%       3.614ms     190.211us            19  
                  volta_scudnn_128x128_relu_small_nn_v1         0.00%       0.000us         0.00%       0.000us       0.000us       2.959ms         5.17%       2.959ms       1.480ms             2  
>-------------------------------------------------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  
>Self CPU time total: 60.885ms
Self CUDA time total: 57.264ms
DRBD9で分散ストレージを手短に構築したよって話

# はじめに
以前よりNextcloudを構築・運用しており、「1ミリもデータを無くしたくない！」という思いから、その保存用HDDの冗長化の過程を備忘録としてまとめたものになります。

昨今では、「そろそろ南海トラフがくる！」と騒がれて止まないのと、メインHDDがぶっ壊れたても大丈夫なように、名古屋⇔北海道間でバックアップ体制の構築を行いました。

自分的メモのため、詳しくは書いていませんが、ご参考程度にどうぞ。

# 構成
・DRBDのバージョン：9.0
・各ノードのOS：`Ubuntu 22.04 LTS`
・ノード1(`192.168.100.1`, Proxmox上のVM)
　・ホスト名：`node-1`
・ノード2(`192.168.100.2`, Raspberry Pi 4B)
　・ホスト名：`node-2`
 
以下、全てホスト名で書いていきます。
リージョン間のバックボーンネットワークは、OCI上に構築済みのWireguardを利用しており、各リージョン間で通信できるようになっています。(ちなみに、実家や兄弟の家などを含め、全てWireguardのバックボーンネットワークに接続・通信できるようになっています。)

使用しているHDDは、下記。
https://www.amazon.co.jp/dp/B07BK6696F?psc=1&ref=ppx_yo2ov_dt_b_product_details

# DRBDのインストール
node-1, node-2で実行する
```
# リポジトリの追加
$ sudo add-apt-repository ppa:linbit/linbit-drbd9-stack

# リポジトリのアップデート
$ sudo apt update

# 構築に必要なDRBDをインストール
$ sudo apt install drbd-utils drbd-dkms -y

# カーネルモジュールのロード
$ sudo modprobe drbd

# インストールできたか確認
$ cat /proc/drbd
```
# 冗長化するディスクの準備・初期設定
node-1, node-2で実行
```
# fdiskなどで、対象のHDDのデバイス名を調べておいてください。
# 今回は「/dev/sda」としますが、各自で適当なデバイス名に置き換えてください。
$ sudo pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created.
$ sudo vgcreate  vg0 /dev/sda
  Volume group "vg0" successfully created
$ sudo lvcreate -l100%FREE -n lv0 vg0
  Logical volume "lv0" created.
```
作成できたか確認
```
$ lsblk
```

ホスト名の確認(node-1, node-2)
```
$ uname -n
node-1
```

node-1, node-2で実行
```
$ sudo tee /etc/drbd.d/global_common.conf <<EOF > /dev/null 
global {
    usage-count no;
}
common {
    net {
        protocol C;
    }
}
EOF
```

node-1,node-2で実行
```
$ sudo tee /etc/drbd.d/r0.res <<EOF > /dev/null 
resource r0 {
    device /dev/drbd0;
    disk /dev/vg0/lv0;
    meta-disk internal;
    on <node-1のホスト名> {
        address 192.168.100.101:7789;
    }
    on <node-2のホスト名> {
        address 192.168.100.102:7799;
    }
}
EOF
```
node-1,node-2で実行
```
# メタデータの作成
$ sudo drbdadm create-md r0
# DRBDの起動
$ sudo drbdadm up r0
# statusの確認
$ sudo drbdadm status r0
```
この時点では、起動しただけで同期は始まらないので、下記のコマンドを`node-1`で実行します。
```
$ sudo drbdadm primary --force r0
```
同期まで時間がかかるので、待機

:::message
もし、どちらのHDDにも何もデータがない場合は、初回フル同期はスキップすることができます。
その場合は、`$ sudo drbdadm primary --force r0`ではなく、下記のコマンド(`node-1`で実行)を使ってください。([公式ドキュメント](https://linbit.com/drbd-user-guide/drbd-guide-9_0-ja/#s-skip-initial-resync))
```
$ sudo drbdadm new-current-uuid --clear-bitmap r0
```
:::

# 備考
追記があれば、適宜追記していきます。
未経験エンジニアが実践する集中力と柔軟性を両立する働き方

# はじめに
未経験からエンジニアに転職し業務する中で、エンジニアは黙々と作業することが多くて集中力を維持するのが大変だなと感じました。
前職は建築関係、特にオフィスや働き方を提案する業務をしていたこともあり、その時に培った知識などを活用して自分なりの働き方を実践しているので、もし集中力が続かない、業務の効率が悪いといった悩みがある方の参考の１つになれれば幸いです。

# 目次
- 前職で学んだ働き方の知識
  * 15-45-90の法則
  * ABW（アクティビティ・ベースド・ワーキング）
- 実践していること
- 実践した感想
- 参考記事
- おわりに

# 前職で学んだ働き方の知識
### 15-45-90の法則
人が集中できる時間は90分が限度とされています。レム睡眠とノンレム睡眠のように、日中も集中力が高まる90分と眠気の出る20分が交互に現れるといわれています。
「15-45-90の法則」とは、人が集中できる時間の法則で、この法則によると、人は15分・45分・90分の3つの単位で集中することができます。﻿
15分は特に集中できる時間とされていて、深い集中力が求められる同時通訳者の方などはこの15分を目安に交代するといわれていて、﻿45分は子供でも集中力を保てる長さです。90分は集中できる限界で、それ以上集中しようとしても集中力が低下してしまい、パフォーマンスは下がると言われています。

![15-45-90の法則イメージ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3574782/00f64667-4e01-4853-d94d-05a129387183.jpeg)

### ABW（アクティビティ・ベースド・ワーキング）
ABWとは業務や気分に応じて時間と場所をワーカー自ら選択できるワークスタイルです。
ABWは、仕事を「しなければならない場所」ではなく、「自分の力を発揮できる場所」に焦点をあてた考え方で、従来のオフィスのような固定席を設けず、働く人が働く場所や時間を業務の内容に応じて自由に選択できる働き方を指します。
単に作業する席を選択できるフリーアドレスとは異なり、1人で集中して作業したいときには周囲から隔離されたワークスペース、アイデア出しや企画の検討を行うときはクリエイティブに作業ができるエリアを使うなど、そのときの作業内容に合わせて働く場所を選ぶことがABWの特徴です。

##### ABWのメリット
1. 柔軟性と選択肢の拡大：
   ABWでは、従来の固定されたデスクではなく、作業内容に応じて最適な場所で仕事ができます。これにより、作業に適した環境を選択でき、仕事の柔軟性が向上します。
2. コラボレーションの促進：
   ABWはオープンな作業スペースや共有スペースを提供することが一般的です。これにより、チームメンバーや異なる部署の人々がより簡単にコラボレーションし、情報を共有できます。
3. クリエイティブな発想の促進
   異なる環境での作業は、新しいアイディアを生み出す助けになります。ABWはクリエイティブな発想を刺激し、従来の枠にとらわれないアプローチを可能にします。
4. ワークライフバランスの向上
   ABWは通勤時間の短縮や在宅勤務の促進により、従業員のワークライフバランスの向上に寄与します。柔軟な働き方ができるため、労働環境に合わせた生活スタイルが実現できます。

# 実践していること
上記で説明した"15-45-90の法則"と"ABW"の考え方を自分なりに解釈し、オフィスや自宅での働き方を工夫しています。
まず、"15-45-90の法則"は業務によって15分・45分・90分のどの段階の集中力が必要か見極めて作業をしています。例えば、無理難題で自分の能力を最大限発揮してもできるかどうかわからないような作業（新しい言語の学習等）は、15分作業＋5分休憩。自分の知識プラスなにか調べたりしながらするようなある程度集中力のいる作業（コーディング等）は、45分作業＋10分休憩。あまり集中力を必要としない単純作業（資料作成や雑業務）は、90分作業＋15分休憩。と自分は作業を振り分けて作業するようにしています。
"ABW"は、基本的にオフィスでの働き方を指しますが、自分の場合オフィスは固定席のため、自宅でのリモートワークをABWにあてはめて作業するようにしています。自分の場合は、作業する場所を、「自宅のデスク」「自宅のリビング（ローテーブル）」「自宅のダイニング（チェアなしで立って作業する）」「近くのカフェ」「近くのコワーキングスペース」の５つに分け、"15-45-90の法則"で振り分けた作業ごとに、どの場所で作業するのが最適かを決めて作業しています。15分集中の作業は、「近くのコワーキングスペース」か「自宅のデスク」、45分集中の作業は「近くのカフェ」か「自宅のデスク」や「自宅のダイニング」、90分集中の作業は「自宅のデスク」か「自宅のダイニング」や「自宅のリビング」で行い、2時間程度で作業場所を変えるというルールを作りました。

# 実践した感想
自分なりに"15-45-90の法則"と"ABW"を取り入れた働き方を半年程度実践していますが、以前より明確にコーディング時のミスが減りました。休憩時間が増えたこと、作業場所を変えることで、思考を一旦リセットしてコードを見返すことが多くなり、コードのミスを発見できることが頻繁にあります。作業場所を2時間ごとにかえるのは、気分転換になりかなり気に入っています。休憩時間が増えるため、作業進捗が悪くなると懸念していましたが、実践前とそこまで変わらないと感じています。
問題点としては、45分集中の作業と90分集中の作業が多くの割合を占めていて、15分集中の作業がほとんどないです。作業の割り振りは自己裁量で変えていいのでそこまで問題ではないですが、もう少し15分集中が必要な難しい課題にチャレンジしていかないといけないなと思いました。

# 参考記事
https://wakuwakukikaku.com/syucyuryoku

https://www.kaonavi.jp/dictionary/abw/

# おわりに
本記事では、自分なりに考えた働き方のルールを紹介しました。人それぞれ自分に合った集中できる時間や、ワークスペースがあると思うので、この記事をみて自分の働き方は自分に合っているのか。一度考え直すよい機会になれればうれしいです。
キャズム理論のまとめ【改訂版】

「キャズム理論」とは、ハイテク製品がマーケティングを成功させメインストリーム市場に到達するために何をすべきか、に焦点を当てた理論です。

1999年のジェフリー・ムーアの著書「[キャズム](https://amzn.to/4balT8k)」で提唱されました。ここでは「[キャズム](https://amzn.to/4balT8k)」の主要な内容を紹介します。

## ハイテク製品のユーザ層

「[キャズム](https://amzn.to/4balT8k)」ではハイテク製品のユーザを５つのグループに分類しています。

## 1. イノベーター（ハイテクオタク）

![supuer_nihonjin.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/2aa73cca-77a2-a1bf-41ef-e6dc8ad81041.png)

このグループは自らを先駆者や革新者と見なし、新しいアイデアや技術の先頭に立っていることを誇りに感じています。

新しいアイデアや製品に対して非常に積極的でリスクを冒すことにためらいがありません。ハイテク技術への興味が強く、革新的なソリューションや製品をいち早く採用する傾向があります。

他のグループが自分たちのアイデアや製品を受け入れないことに対して、理解が欠けていると感じることがあります。

## 2. アーリーアダプター（ビジョナリー）

![challenge_mokuhyou_businesswoman.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/57136443-a5c7-ca12-b7a9-ab2487992351.png)

自分たちの役割は新しいアイデアを実践し、他の人々にその価値を伝えることであると考えます。イノベータのアイデアを取り入れ、それを組織やコミュニティに適用することで、変化を促進する役割を果たしていると認識する。

リスクを取ることには抵抗がありますが、革新的なものには積極的に関与します。イノベータを尊敬し、新しいアイデアに感謝しています。後から述べるアーリーマジョリティやレイトマジョリティとは異なり、イノベータとの距離感が少なく、彼らを励ますことがあります。

## 3. アーリーマジョリティ（価格・品質重視派）

![smartphone_blank_sagyouin_man.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/34e955f9-74e7-f890-f677-68fe2339efb9.png)

自分たちは変化に敏感であり、新しいアイデアや製品を素早く受け入れることで、組織や社会の発展に貢献していると考えます。

アーリーアダプタより保守的で、新しいアイデアや製品を採用するまでには時間がかかります。他の人々の評判や製品の信頼性が確立された後に、採用を検討する傾向があります。

## 4. レイトマジョリティ（みんな使ってる派）

![friend_advice_woman.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/70d184ff-6a52-aa9c-6762-cc4ebf79e0a9.png)

自らを慎重な意思決定者と考え、変化を受け入れる際には慎重な姿勢を重視します。安定性や信頼性を重要視し、組織や社会の安定に貢献していると考えています。

新しいアイデアやハイテク製品に対してかなり慎重で、他の人々が既に採用していることを確認するまで待ちます。大多数の人が取り入れていることを見て、ようやく採用を考える傾向があります。

イノベータやアーリーアダプターに対しては少し距離を置いており、保守的な立場から、新しいアイデアや製品を慎重に検討します。

## 5. ラガード（ハイテク嫌い）

![native_american_shaman.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/f20e4d33-4360-2b05-65d7-f177651e2113.png)

最も保守的なグループであり、伝統的な価値観や過去の成功体験を守ることで、組織の安定を維持する役割を果たしていると考えます。伝統的な方法や既存の製品に忠実であり、変化を受け入れることに抵抗します。

イノベータやアーリーアダプターに対しては、軽蔑的な態度を示すことがあります。

## ハイテク製品がユーザを獲得する流れ

早期に新技術を採用し、市場のリーダーとなるグループ。
、市場全体の2.5%
、市場全体の13.5%

一般のビジネスや消費者が新技術の採用を始める段階。
、市場全体の34%

主流市場が新技術を受け入れる段階。
、市場全体の34%

技術の採用が遅れ、最終的には採用するか、あるいは採用しないグループ。
、市場全体の16%

## キャズム（＝溝）について

![112.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3160433/04683a27-cd66-168b-5d34-abb990b8d6cc.png)

キャズムとは初期市場（イノベーターとアーリーアダプター）と主要市場（アーリーマジョリティ以降）の間に生じる隔たりを指します。

新しいモノ好き(アーリーアダプター)と　実利主義者の購買動機には大きな隔たり(キャズム)があり、
  キャズムを越えることは、市場において技術が普及していく上での重要な課題であり、この課題を越えられないと新技術は市場の広がりを制限される可能性があります。

## キャズムを乗り越える方法
### 無料で提供する
レイトマジョリティやラガードが新しい技術やアイデアを受け入れる際のリスクを軽減するために、トライアルやデモンストレーション、無料のトライアル期間などを提供することが有効です。これにより、彼らが新しいものを試すことに対する心理的な障壁を下げることができます。

### 教育と啓蒙
レイトマジョリティやラガードに対して、新しい技術やアイデアの利点や可能性について教育することが重要です。教育キャンペーンやワークショップを通じて、彼らの理解を深めることができます。

### 製品やサービスを改善する
レイトマジョリティやラガードのニーズや価値観に焦点を当て、彼らが製品やサービスをより使いやすく、魅力的に感じるような改善を行うことが重要です。彼らのフィードバックを取り入れ、製品やサービスをカスタマイズすることで、彼らの支持を得ることができます。

## キャズム理論の意義
この理論は、特に新興技術が市場に参入する際に、初期の成功から主要市場への移行がどのように進むべきかを示唆しています。ムーアのアプローチは、市場成熟度と技術の採用に関する洞察を提供し、企業や製品が持続的な成功を収めるための方針を考える上で有用です。

## 参考文献
- [キャズム Ver.2: 新商品をブレイクさせる「超」マーケティング理論](https://amzn.to/3Wwsp4J/)
2023 年 マイクロソフト製品・サービスの脆弱性を振り返る

今年も早いものであっという間に年の瀬ですね。少し早いですが、今年のマイクロソフト製品・サービスで修正した脆弱性を振り返ってみましょう。


## 脆弱性の総数
2023 年、マイクロソフトは、合計で 957 件 (2022年は 956 件) のマイクロソフト製品・サービスの脆弱性を修正しました。脆弱性の修正数は、過去 5 年間の統計と比較しても減少している　というわけではありません。セキュリティに力をいれたら脆弱性の数も減るのでは？と思われるかもしれませんが、そういうわけではありません。これは、①マイクロソフト製品・サービスの数が増加している　②セキュリティの研究が発達することで新たな脆弱性や攻撃手法は日々みつかる　　③マイクロソフトの長年の製品セキュリティへの取り組みにより、脆弱性を見つけやすくなっている　　といったことが影響しています。特に②③ については、近年は、機械学習を用いた脆弱性の ”亜種” の発見に力を入れており、発見されたひとつの脆弱性から、類似の攻撃手法や脆弱性を多数のバイナリから早期に発見することができるようになっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3031633/e82d128c-6ce8-27ca-dfa6-5350cacab40e.png)


## ゼロデイの状況
修正プログラムが公開されるよりも前に悪用を確認していた脆弱性（いわゆる “ゼロデイ” の脆弱性） は、22 件です。 近年は、マイクロソフト製品においては、”認証や権限なしで一撃でネットワーク越しに攻撃できる” といった、インターネット越しに簡単に悪用ができる脆弱性は、実はそもそも大幅に減少しており、このため、悪用されたマイクロソフトの脆弱性もそのようなものはほとんどありません。悪用されるマイクロソフト製品の脆弱性のほとんどは、脆弱性の種別でいうと特権の昇格やセキュリティ機能のバイパス、脆弱性の悪用条件でいうと「ユーザー操作が必要」「認証・権限が必要」という条件がつくものです。すなわち、すでに攻撃者は何かしらの初期攻撃を行ったことを前提に悪用が行われる脆弱性なのです。
実際、2023年のゼロデイの脆弱性は、攻撃を行うために、認証、もしくはユーザーの操作が必要ないもの、すなわち、”認証や権限なしで、一撃でネットワーク越しに攻撃できる” ゼロデイは 1 件のみでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3031633/09315d16-7b33-d4b2-f04f-ef5cbbac70d2.png)



## 悪用脆弱性の CVSS は高くない
マイクロソフト製品の脆弱性は、メディアでの注目度が高いことから、よく目にする機会も多いのですが、タイトルとして目につきやすい「ネットワークで攻撃可能」というものが重要というイメージが残ったままの方もいるかもしれません。
マイクロソフト製品、特に、Windowsにおいては、実は、フィッシングなどによって初期侵入を行った後に悪用される特権昇格・セキュリティ機能のバイパスが、悪用に好まれる傾向にあります。これらの脆弱性は、CVSS の値としては低いため、パッチ適用漏れになっているケースも少なくありません。
実際、2023 に修正したマイクロソフト製品全体の CVSS 平均が 7.34 に対して、ゼロデイで悪用された脆弱性の CVSS の平均は 7.59 で、ほとんど差がありません。このように、CVSS の値としては現れないが、リスクのある脆弱性も、適切にリスク評価し、パッチ適用を進めていくことが重要だということが言えると思います。
マイクロソフトでは長年、すべての脆弱性に対して悪用の可能性を評価して、 ”マイクロソフト悪用可能性指標” を示して、CVSS だけでは評価できないリスクを評価できるよう情報を提供しています。また、microsoft セキュリティ製品でも、microsoft vulnerablity management などでリスクを多角的に把握できるように基盤を提供しています。
また、業界においても、CVSS だけではなく、昨今はEPSSなどの指標をリスク評価に活用する組織も増えてきています。このようなものを活用して、多角的にリスク評価していくことが重要だと思います。

今回ご紹介したデータはあくまでマイクロソフト製品・サービスでの脆弱性の統計で、統計が一概にすべての脅威の情勢を表すものではありませんが、みなさまがマイクロソフト製品の脆弱性対応を行う上でのぜひご参考になれば！

それでは、みなさま Happy Holidays 🎁
mindの研究 その51

# 概要
mindが、謎なので調べてみた。
練習問題やってみた。

# 練習問題
mindで俺cpuのアセンブラから、mindのソースコードを生成せよ。

# サンプルコード

```



コードは　40個の　文字列。
コード数は　変数。
スタック1は　文字列。
スタック2は　文字列。
スタック3は　文字列。

アセンブラとは
　コード（コード数）に　入れ
　コード数に　１を　加えて　コード数に　入れる
。

俺コンパイルとは
　文字列１は　文字列
　単語1は　文字列
　単語2は　文字列
　数１は　変数
　数２は　変数
　合否は　変数
　ｎは　変数
　スタック1に　「」を　入れ
　スタック2に　「」を　入れ
　スタック3に　「」を　入れ
　ｎに　１を　入れ

「メインとは」を　表示し　改行し
「　数aは　変数」を　表示し　改行し
　ここから
　　もし　ｎが　コード数より　大きい
　　ならば
　　　終り
　　つぎに
※　　コード（ｎ）を　一行表示する
　　コード（ｎ）を　文字列１に　入れ
　　文字列１から　単語切り出し　単語1に　入れ
　　文字列１から　単語切り出し　単語2に　入れ

　　もし　単語1が　「」に　等しい文字列
　　ならば
　　　打ち切り
　　つぎに

　　もし　単語1が　「set」に　等しい文字列
　　ならば
　　　「　数」を　表示し
　　　単語2を　表示し
　　　「に　入れ」を　表示し　改行し
　　つぎに

　　もし　単語1が　「loop」に　等しい文字列
　　ならば
　　「　ここから」を　表示し　改行し
　　つぎに

　　もし　単語1が　「get」に　等しい文字列
　　ならば
　　　スタック3に　スタック2を　入れ
　　　スタック2に　スタック1を　入れ
　　　スタック1に　単語2を　入れる
　　つぎに

　　もし　単語1が　「>」に　等しい文字列
　　ならば
　　　スタック3に　スタック2を　入れ
　　　スタック2に　スタック1を　入れ
　　　スタック1に　「>」を　入れる
　　つぎに

　　もし　単語1が　「if」に　等しい文字列
　　ならば
　　「　もし　数」を　表示し
　　スタック3を　表示し
　　「が　」を　表示し
　　スタック2を　表示し
　　「より　大きい」を　表示し　改行し
　　「　ならば」を　表示し　改行し
　　「　　終り」を　表示し　改行し
　　「　さもなければ」を　表示し　改行し
　　スタック1に　「」を　入れ
　　スタック2に　「」を　入れ
　　スタック3に　「」を　入れ
　　つぎに

　　もし　単語1が　「out」に　等しい文字列
　　ならば
　　　「　　数」を　表示し
　　　スタック1を　表示し
　　　"を　数値表示し　「 」を　表示し"を　表示し　改行し
　　　スタック1に　スタック2を　入れ
　　　スタック2に　スタック3を　入れ
　　つぎに

　　もし　単語1が　「+」に　等しい文字列
　　ならば
　　　「　　数」を　表示し
　　　スタック2を　表示し
　　　「に　」を　表示し
　　　スタック1を　表示し
　　　「を　加え」を　表示し　改行し
　　　スタック1に　スタック3を　入れ
　　つぎに

　　単語１を　数値変換し　数１と　合否に　入れ
　　もし　合否が　真？
　　ならば
　　　「　」を　表示し
　　　単語1を　表示し
　　　「をつみ　」を　表示し
　　　スタック2に　スタック1を　入れ
　　　スタック1に　単語1を　入れる
　　つぎに

　　ｎに　１を　加えて　ｎに　入れる
　繰り返す
「　つぎに」を　表示し　改行し
「　繰り返し」を　表示し　改行し
「。」を　表示し　改行し
。

メインとは
　コードを　クリアし
　1を　コード数に　入れ
　「1     」を　アセンブラし
　「set  a」を　アセンブラし
　「loop  」を　アセンブラし
　「get  a」を　アセンブラし
　「100   」を　アセンブラし
　「>     」を　アセンブラし
　「if end」を　アセンブラし
　「get  a」を　アセンブラし
　「out   」を　アセンブラし
　「get  a」を　アセンブラし
　「1     」を　アセンブラし
　「+     」を　アセンブラし
　「set  a」を　アセンブラし
　「jmp loop」を　アセンブラし
　俺コンパイルする
。





```

# 実行結果

```
メインとは
　数aは　変数
　1をつみ　　数aに　入れ
　ここから
　100をつみ　　もし　数aが　100より　大きい
　ならば
　　終り
　さもなければ
　　数aを　数値表示し　「 」を　表示し
　1をつみ　　　数aに　1を　加え
　数aに　入れ
　つぎに
　繰り返し
。
```

以上。
MapLibre GL JSと標高タイルで等高線を描画する

# TL;DR

- [maplibre-contour](https://github.com/onthegomap/maplibre-contour)を使えば、標高タイルから等高線を描画出来る

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73197/a6c4f182-ae85-9f7d-007e-acd05217137e.png)


[MapLibre User Group Japan](https://dayjournal.notion.site/MapLibre-User-Group-Japan-Official-Web-Site-4ecb7ea313f945f39ccc2ca8dfbaad4f)の@Kanahiroです。標高タイルから生成する等高線についての記事です。

# 標高タイル

MapLibre、ないしWeb地図の世界では、標高データ（DEM）を効率よく扱うため、標高値をRGBにエンコードした「標高タイル」が利用されています。技術的背景・利活用には以下の記事が詳しいです。

https://qiita.com/shi-works/items/2d712456ccc91320cd1d

# MapLibre GL JSと標高タイル

GL JSでは、標高タイル（raster-dem）を用いると、陰影図や3D地形を描画することが出来ます。

https://docs.maptiler.com/sdk-js/examples/hillshade/

https://maplibre.org/maplibre-gl-js/docs/examples/3d-terrain/

![Screenshot 2023-12-20 at 8.38.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73197/c0a597b2-706a-0e64-acd6-83d33456932f.png)

# 標高タイルで等高線

https://github.com/onthegomap/maplibre-contour

前述のように標高タイルを用いて、等高線を描画するための実装です。サードパーティプラグインという位置付けです。ユニークな点として、内部的にはベクトルタイルを生成しており、柔軟に地図スタイルを設定出来ることが挙げられます。また、パフォーマンスも良好に思います。

## example

![Screenshot 2023-12-20 at 8.43.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73197/b1061919-6811-673c-d2ab-726cdf75558c.png)
©️OpenStreetMap Contributors.

https://github.com/Kanahiro/maplibre-countour-example

https://kanahiro.github.io/maplibre-countour-example/

## 技術的背景

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73197/3cac7c02-b059-bbed-a615-4ff72e0f88c7.png)
リポジトリより引用

関心領域（＝タイル）に加え、隣接するタイルを用いて等高線を生成しているようです。

サポートしている標高タイルのエンコーディングはMapLibreと同様、Terrain-RGBかTerrariumになります。地理院標高タイルは利用出来ません。
Gitコマンド（メモ）

## 初めに
以下は、いくつかのgitコマンドのリストです。より完全なリストをお望みなら、@Pakku8914 のこちらの素晴らしい投稿をお勧めします: 

https://qiita.com/Pakku8914/items/5dfe07248eabd1c4ef98

## Gitのセットアップ

```bash
1. mkdir git # ディレクトリを作成

2. git init # git パーソナルディレクトリを初期化

3. git --version 

4. git config --global user.name "your name"

5. git config --global user.email "your email"

6. git status

7. git add .

8. git commit -m "your message"

9. git log # コードをコミットしたユーザーの情報を表示

10. git show <commit id> # コミットに関する情報

11. git remote add origin <git repo url>

12. git push -u origin master 
# その後、GitHubのIDとパスワードを入力して特定のリポジトリにコードをプッシュする必要があります

13. git pull -u origin master 
# 最初に上記のコマンドでそのリポジトリのURLを指定する必要があります
```
     
## 他に知っておくべきいくつかのコマンド

```bash
1. vi .gitignore  # これにファイルを入力して、コミットから除外します

2. git add .gitignore

3. git log --grep "<search keyword>"

4. git log --oneline # コミットの数

5. git branch # ブランチのリストを表示

6. git branch <branch name>

7. git checkout <branchname> # ブランチを切り替える

8. git branch -d <branchname> # マージ前に特定のブランチを削除

9. git branch -D <branchname> # マージ後に特定のブランチを削除

10. git merge <branch name>

11. git reset <filename> # ステージングエリアからファイルを削除

12. git reset .

13. git reset --hard # ステージングエリアとワークスペースからファイルを削除

14. git clean -n or -f # ワークスペースから未追跡および不要なファイルを削除

15. git tag -a <tagname> -m <message> <commit id>
```

## git stash

```bash
1. git stash # アイテムを隠す

2. git stash list

3. git stash apply stash@{0} # スタッシュからワークスペースにファイルを戻す

4. git stash clear 
```

## git revertとタグコマンド

```bash
1. git revert <commit id>  # 既存のコミットを元に戻す

2. git tag -a <tagname> -m <message> <commit id> # タグを適用

3. git tag  # タグのリストを表示

4. git show <tagname>

5. git tag -d <tagname> # タグを削除
```

## git clone

```bash
1. git clone <url of github repo>

2. git push --set-upstream origin main
```
【Go言語】ジェネリクス

**ジェネリクス**は、関数や構造体に型パラメーターを追加することで、より柔軟なコードの記述を可能する。
しかし、ジェネリクスの概念はメソッドの記法とは異なる点がいくつかある。

ジェネリクスの基本
* ジェネリクスを使うと、関数や構造体に追加の型パラメーターを設定できる
* 型パラメーターは関数名や構造体名の後ろに配置され、角括弧`[]`で囲む
* さまざまな型に対して同じ関数や構造体を使い回せるようになる。

### 構造体でジェネリクス
```go
package main

import "fmt"

// ジェネリックな構造体
type Pair[T1, T2 any] struct {
    First  T1
    Second T2
}

func main() {
    // ジェネリックな構造体の使用例
    pair1 := Pair{1, "one"}
    pair2 := Pair{"two", 2}

    fmt.Printf("Pair 1: First=%v, Second=%v\n", pair1.First, pair1.Second)
    fmt.Printf("Pair 2: First=%v, Second=%v\n", pair2.First, pair2.Second)
}

```

### メソッドにジェネリクス
```go
package main

import (
    "fmt"
)

// ジェネリックな型Tに対するメソッド
func Print[T any](value T) {
    fmt.Printf("%v\n", value)
}

func main() {
    // ジェネリックなメソッドの使用例
    Print(42)
    Print("Hello, World!")
    Print(3.14)
}

```


## 参考
https://www.oreilly.co.jp/books/9784873119694/
なぜLANケーブルにはクロスとストレートがあったのか

# はじめに
こんにちは。えか太郎です。本記事ではLANケーブルのクロスとストレースの違いについて書きます
# クロスケーブルとストレートケーブルの使い分け
LANポートには以下のように二種類あります。
1つ目が「ルーターやスイッチングハブのLANポート」、
2つ目が「パソコンのLANポート」です。
これらを相互に繋ぐ場合はストレートケーブル。（例えば、パソコンとハブ）
同じ種類同士を繋ぐ場合はクロスケーブルを使ってください。（例えば、パソコン同士、ルーターとハブをつなぐ場合）
|                            | スイッチングハブ、ルーター | パソコン           | 
| -------------------------- | -------------------------- | ------------------ | 
| スイッチングハブ、ルーター | クロスケーブル             | ストレートケーブル | 
| パソコン                   | ストレートケーブル         | クロスケーブル     | 
# なぜクロスとストレートがあったのか。
これの原因は同じ形状のLANポートでも「パソコン」と「ルーターやハブ」では送信と受信のコネクタが逆向きになっているからです。間違ったケーブルを使うと送信端子同士、受信端子同士が接続されてしまい通信できなくなります。
# 現在での需要
現在は主にストレートケーブルが使われています。クロスケーブルは結線にいくつか種類があるため確認しておいたほうがいいかもしれないです。
2000年前後に相手のポートやLANケーブルの種類を判別して自動でクロスかストレートかを変える「オートMDI/MDI-X」という機能が搭載されるようになったので、現在はクロスケーブルもストレートケーブルも特に問題なく混在させて問題はありません。また1GbpsのLANには標準でこの機能は実装されているので「1000Base-TX」が付いている機器を購入すれば確実といえます。
# 今後
おそらくシリアルポートのように旧規格ならではのメリットもないのでおそらく廃れて、30年以上も前のすステムが残っているレガシーな環境でしか使われなくなるのではないでしょうか。


（シリアルポートは単純で安価であり、コンソール機能が高度に規格化され普及しているため、ネットワーク機器の分野で永く使用されている。シリアルポートはホストシステムからのソフトウェアサポートをほとんど必要としない。By wiki）
AWS Trusted Advisorを使って本気でAWSアカウントを守る

# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://zenn.dev/tech4anyone/articles/c05ee9777c6de0)。

この記事ではAWS Trusted Advisorに関連する内容を超詳細にまとめています。

具体的には以下流れで説明します。

- AWS Trusted Advisorとは
- AWS Trusted Advisorの仕組み
- AWS Trusted Advisorの活用
- AWS Trusted Advisorのベストプラクティス

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

# この記事を読んでほしい人
- AWS Trusted Advisorがどういうサービスか説明できるようになりたい人
- AWS Trusted Advisorを採用するときのベストプラクティスを説明できるようになりたい人
- AWS Certified DevOps Engineer Professionalを目指している人


# AWS Trusted Advisorとは
AWS Trusted Advisorは、AWSのサービスを最適化するためのオンラインツールです。
AWS Trusted Advisorは、コストの削減、パフォーマンスの向上、セキュリティの強化、耐障害性の高めるなど、AWSのベストプラクティスに基づいて、AWSアカウントを分析し、改善提案を行います。

# AWS Trusted Advisorの仕組み
AWS Trusted Advisorは、以下の5つのカテゴリーに分類されたチェック項目を用いて、AWSアカウントを評価します。

| カテゴリー | 説明 |
| --- | --- |
| コスト最適化 | 不要なリソースや過剰なプロビジョニングなど、コストを削減できる可能性がある箇所を特定します。 |
| パフォーマンス | サービスの利用率や設定など、パフォーマンスを向上できる可能性がある箇所を特定します。 |
| セキュリティ | アクセス制御や暗号化など、セキュリティを強化できる可能性がある箇所を特定します。 |
| 耐障害性 | 冗長性やバックアップなど、耐障害性を高める可能性がある箇所を特定します。 |
| サービス制限 | 各サービスの制限値に近づいているかどうかを監視し、制限値の増加やサービスの変更を提案します。 |

# AWS Trusted Advisorの活用
AWS Trusted Advisorは、ダッシュボードからチェック項目の結果を確認できます。
チェック項目の結果は、以下の3つの色で表示されます。

- 緑：問題なし
- 黄：注意が必要
- 赤：改善が必要

チェック項目の結果に応じて、AWS Trusted Advisorは具体的な改善提案を行います。
改善提案には、対象となるリソースや設定の詳細や、改善方法の手順が記載されています。
また、一部の改善提案は、AWS Trusted Advisorから直接実行できます。

例えば、コスト最適化カテゴリーでは、以下のようなチェック項目と改善提案があります。
| チェック項目 | 改善提案 |
|--- | ---|
| 低使用率EC2インスタンス | CPU使用率が10%未満であるEC2インスタンスを特定し、停止または削除することでコストを削減できます。 |
| アイドルロードバランサー | トラフィックがないロードバランサーを特定し、削除することでコストを削減できます。 |
| EC2 Reserved Instance最適化 | EC2 Reserved Instanceとオンデマンドインスタンスの利用状況に基づいて、Reserved Instanceの購入や変更を提案します。 |

これらの改善提案は、ダッシュボードから直接実行することができます。
例えば、「低使用率EC2インスタンス」チェック項目では、「停止」ボタンや「削除」ボタンが表示されます。
これらのボタンをクリックすることで、対象となるEC2インスタンスを停止または削除することができます。

# AWS Trusted Advisorのベストプラクティス

AWS Trusted Advisorを効果的に活用するためには、以下のベストプラクティスに従うことが推奨されます。

| ベストプラクティス | 説明 |
| --- | --- |
| 定期的にチェック項目の結果を確認する | AWS Trusted Advisorは週に1回チェック項目の結果を更新します。定期的にチェック項目の結果を確認し、改善提案に従ってAWS環境を最適化することが重要です。 |
| チェック項目の結果を通知する | AWS Trusted Advisorは、チェック項目の結果が変更された場合や、新しいチェック項目が追加された場合に通知する機能を提供しています。通知機能を有効にすることで、チェック項目の結果を逃さずに確認できます。 |
| チェック項目の結果をレポートする | AWS Trusted Advisorは、チェック項目の結果をPDFやCSV形式でダウンロードできる機能を提供しています。レポート機能を利用することで、チェック項目の結果を文書化したり、他のツールと連携したりできます。 |
| チェック項目の結果をAPIで取得する | AWS Trusted Advisorは、チェック項目の結果をAPIで取得できる機能を提供しています。API機能を利用することで、チェック項目の結果を自動化したり、カスタマイズしたりできます。 |

# まとめ
この記事ではAWS Trusted Advisorに関連する内容を超詳細にまとめました。

- AWS Trusted Advisorとは
- AWS Trusted Advisorの仕組み
- AWS Trusted Advisorの活用
- AWS Trusted Advisorのベストプラクティス

次回はAWS Secrets Managerについて超詳細解説します。