OmniAICreator/Qiita-1.07M huggingface dataset:
データパックをGithub Actionsで自動zipリリース

**Minecraft Command Advent Calendar 2023 シリーズ3 21日目の記事です。**

https://qiita.com/advent-calendar/2023/mccmd

# はじめに
データパックやリソースパックをGithub上で管理している方は多いでしょう。
Github Actionsを使うとメインのブランチにpushした際に自動的にzip化してリリースすることが可能です。

# 仕組み

リポジトリのファイルをzipファイルに圧縮
↓
zipファイルをリリース

# 使用するActions

ソースコードへのアクセスに必須です。

https://github.com/actions/checkout

ファイルをzipに圧縮するのに使います。

https://github.com/TheDoctor0/zip-release

リリースを行うのに使います。

https://github.com/softprops/action-gh-release


# 手順

Github actionsを作成する際にmain.ymlに以下を貼り付けて保存します。

```yaml
name: Create Archive
on: 
 push:
  branches:
  - main
      
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
    - uses: actions/checkout@master

    - name: Set Time
      env:
        TZ: 'Asia/Tokyo'
      run: echo "CURRENT_DATETIME=$(date +'%Y%m%d-%H%M%S')" >> $GITHUB_ENV
    
    - run: echo "RELEASE_FILENAME=release_${{ env.CURRENT_DATETIME }}.zip" >> $GITHUB_ENV
      
    - name: Archive Release
      uses: thedoctor0/zip-release@main
      with:
        type: 'zip'
        filename: ${{ env.RELEASE_FILENAME }}
        exclusions: '*.git*'
      
    - name: Create Release
      id: create_release
      uses: softprops/action-gh-release@v0.1.15
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ env.CURRENT_DATETIME }}
        name: ${{ env.CURRENT_DATETIME }}
        draft: false
        prerelease: false
        files: ${{ env.RELEASE_FILENAME }}
```

# コード解説

ここではトリガーとなるブランチを指定します。

```yaml
on: 
 push:
  branches:
  - main
```

ここでは日時を取得し、ファイル名を決定しています。

```yaml
    - name: Set Time
      env:
        TZ: 'Asia/Tokyo'
      run: echo "CURRENT_DATETIME=$(date +'%Y%m%d-%H%M%S')" >> $GITHUB_ENV
    
    - run: echo "RELEASE_FILENAME=release_${{ env.CURRENT_DATETIME }}.zip" >> $GITHUB_ENV
```

ここではファイルをzipに圧縮しています。

```yaml
    - name: Archive Release
      uses: thedoctor0/zip-release@main
      with:
        type: 'zip'
        filename: ${{ env.RELEASE_FILENAME }}
        exclusions: '*.git*'
```

ここではzipファイルをリリースしています。

```yaml
    - name: Create Release
      id: create_release
      uses: softprops/action-gh-release@v0.1.15
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ env.CURRENT_DATETIME }}
        name: ${{ env.CURRENT_DATETIME }}
        draft: false
        prerelease: false
        files: ${{ env.RELEASE_FILENAME }}
```

# 小技

ファイル名を固定すれば以下のようなURLでダウンロードリンクを固定できます。

```
https://github.com/ユーザー名/リポジトリ名/releases/download/latest/ファイル名
```
【Go言語】データ型の拡張

Goでは、`int`や`string`などの**組み込み型**、`スライス`や`map`などの**複合型**を拡張して新しい型を作成することが可能。

新しい型を定義する際、元となる型を「**基底型（underlying type）**」と呼ぶ。
新しい型を作ることで、基底型の特性を引き継ぎつつ新しいメソッドを追加することができる。

### メソッドを追加する
`int`型を基底型として`HTTPStatus`型を定義し、`String()`メソッドを追加する

```go
package main

import (
	"fmt"
)

// HTTPStatus型の定義
type HTTPStatus int

// HTTPStatusの定数
const (
	StatusOK              HTTPStatus = 200
	StatusUnauthorized    HTTPStatus = 401
	StatusPaymentRequired HTTPStatus = 402
	StatusForbidden       HTTPStatus = 403
)

// HTTPStatus型にString()メソッドを追加
func (s HTTPStatus) String() string {
	switch s {
	case StatusOK:
		return "OK"
	case StatusUnauthorized:
		return "Unauthorized"
	case StatusPaymentRequired:
		return "Payment Required"
	case StatusForbidden:
		return "Forbidden"
	default:
		return fmt.Sprintf("HTTPStatus(%d)", s)
	}
}

func main() {
	// HTTPStatus型の使用例
	status := StatusOK
	fmt.Println("HTTP Status:", status, status.String())
}

```

### 拡張した組み込み型で、基底型の挙動を利用する
拡張された型は、元の基底型の機能も利用できる。
例えば、`map`を基底型とする`url.Values`型は、`map`の機能に加えて特有のメソッドを持っている。
```go
package main

import (
	"fmt"
	"net/url"
)

func main() {
	// url.Values型のインスタンスを作成
	values := url.Values{}

	// 値を追加
	values.Add("key1", "value1")
	values.Add("key2", "value2")

	// 値を出力
	for key, value := range values {
		fmt.Printf("%s: %v\n", key, value)
	}
}

```
### ファクトリー関数の提供
型をより使いやすくするために、**ファクトリー関数**を提供することが推奨されている。
これにより、型のインスタンス化を簡単にし、エラーチェックを組み込むことが可能になる。

```go
package main

import (
	"errors"
	"fmt"
)

// MyType はカスタムデータ型です。
type MyType struct {
	Value string
}

// NewMyType は MyType の新しいインスタンスを作成するファクトリー関数です。
// この関数はエラーチェックを含めることもできます。
func NewMyType(value string) (*MyType, error) {
	if value == "" {
		return nil, errors.New("value cannot be empty")
	}
	return &MyType{Value: value}, nil
}

func main() {
	// ファクトリー関数を使用して MyType のインスタンスを作成
	myInstance, err := NewMyType("Hello, World!")
	if err != nil {
		fmt.Println("Error creating MyType instance:", err)
		return
	}

	// インスタンスの使用
	fmt.Println("MyType Value:", myInstance.Value)
}

```


## 参考
https://www.oreilly.co.jp/books/9784873119694/
コンピュータと哲学に関する本の紹介

今日は皆さんに、コンピュータ（特に人工知能）と哲学に関する本を1冊紹介したいと思います。

私が最近コンピュータに関することで一番驚いたのは、何と言ってもChatGPTです。質問したことに何でも正確に答えられるというレベルにまでは未だ達していないようですが、従来の検索エンジンのように欲しい情報をインターネット上で探すといった使い方を超えて、例えば「こんな計算をするPythonのプログラムを作れ」と入力すると、瞬時に目的とするプログラムを生成したりすることができるようです。何より、日本語を母語とする私達が読んでも全く違和感のない言葉が次々に出力される様子を見ていると、近い将来、コンピュータが人間と同じように会話をしたり考えたりすることができるようになることを予感させます。

ChatGPTのように、コンピュータに人間と同じような知的活動を行わせ用とする研究は、コンピュータの黎明期である1950年代から「人工知能（Artificial Intelligence:略してAI）」と呼ばれる分野において継続的に行われてきました。その一方で、こうした技術が発達するに伴い、「コンピュータのような単なる物質が、ものを考えたり感じたりすることができるのか」「心とは何か」「言語を理解するというのはどういうことなのか」といった哲学的な問いが改めて提起され、多くの議論がなされてきました。（ちなみに、哲学とそれ以外の学問分野との根本的な違いは、前者が上記のような「What（○○とは何か）」という問いを扱うのに対して、後者は「How（○○を実現するにはどのようにしたらよいか）」に関する問いを扱う点にあると言えます。）今日紹介する『マインズ・アイ』という本は、私達にこうしたコンピュータ（特に人工知能）に関わる哲学的な問いを投げかけてくれるユニークな本です。


![41VVDHKkKZL.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3625225/9035d127-cba6-996e-ff38-6b4cb08a4fdd.jpeg)

D.R.ホフスタッター，D.C.デネット編著 / 坂本百大 監訳
『マインズ・アイ』（上・下）TBSブリタニカ

この本の良いところは以下の3つです。

1. 上下巻の2冊構成でページ数が多いが、いろいろな著者によって書かれた文章を集めたアンソロジーで、どの文章も30分くらいで読めてしまう。また、それぞれの文章は独立しているので、興味のある文章だけを好きな順番で読むことができる。

2. 収録された文章の選び方が優れている。論文ばかりでなくSF短編小説などバラエティがあり、読んでいて飽きない（疲れない）。また、「チューリングテスト」や「中国語の部屋」（強いAI・弱いAIの議論のもととなった思考実験）などの有名な概念のオリジナルの論文も読める。

3. それぞれの文章には、編者による簡単な解説が付いている。これによって、最初に作品を読みながら独力であれこれと考えた後で、解説を読んで更に新たな視点や考え方が得ることができる。（なお、編者のホフスタッターとデネットは、どちらも一流の哲学者として知られています。ホフスタッターは『ゲーデル・エッシャー・バッハ』の著者として有名です。また、デネットも特に心の哲学などの分野で現代を代表する哲学者です。）

上下巻合わせて全部で27編の文章が収録されています。個人的に思い出深いのは、第8章の「動物マークIIIの魂」という短編小説です。この話は、エモーショナルに「ロボットは心を持ちうるか」という問いを投げかける印象深い作品ですが、実はこの作品を初めて読んだのは、私がその後入学した某大学某学部の小論文の入試問題でした。その後、大学の哲学科に進学してからこの本を手にして再びこの小説に出会い、非常に感慨深かったのを覚えています。

ネタバレしないように、中身については敢えて紹介しません。興味のある人は、ぜひ一度手に取って、目次をパラパラめくりながら、面白そうな文章から読んでみて下さい。人工知能の技術が著しい発展を遂げる中で、ちょっと一息ついて根本的な問題についてじっくり考えるきっかけになれば幸いです。

…と、ここまで紹介しておいて申し訳ないのですが、この本はすでに絶版となっていますので、新刊で買うことができません。Amazonなどで古本を買うか、図書館などで借りるなどして下さい。（そんな本を紹介してごめんなさい。）
JavaアプリケーションをHTML5やWebAssembly/JavaScriptに変換できますか？

![can-you-convert-java-applications-to-webassembly-javascript--1024x1024.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3486144/2445caaa-1140-d181-0931-2891130e6655.jpeg)

一般的に信じられていることとは異なり、Javaはまだ完全に終わったわけではなく、特にソフトウェア業界では、全体で2番目に人気のあるプログラミング言語です。

非常に活発なコミュニティ、豊富なツールのエコシステム、膨大な数のライブラリとフレームワークがあり、後方互換性を保ちながら適応と進化が可能で（ほとんどの場合）、今でも業界で広く使われています。

# 最新のエンタープライズ・アプリケーション
Javaはサーバーサイドやネイティブ・アプリケーションに最適な環境を提供しますが、最近のエンタープライズ・アプリケーション・クライアントはHTML5標準への移行が進んでいます。これは、ユーザーの要求を満たすために、幅広いブラウザ、デバイス、および環境において、より幅広い互換性を活用するためです。

HTML5アプリケーションは、HTML、CSS、JavaScriptなどの標準規格を活用しますが、これらは環境、ブラウザ、バージョンによって実装が微妙に異なることで有名です。HTML5フロントエンド開発の新しい言語と多数のフレームワークを学ぶことに加えて、Javaデベロッパーは新しいライブラリ、イベントモデル、JavaScriptで使用されるプロトタイプ指向のOOPパラダイムを理解する必要があります。

WebAssemblyとモダンブラウザはこれを完全に変えます。コンパイル・ターゲットとしてブラウザを見ることを可能にすることで、WebAssemblyはこれらのトレードオフを排除します。

これにより、JavaデベロッパーはJavaScriptの癖を学ぶ必要がなくなります。あなたが既知のもの、そしてより重要なことは、あなたのチームが既にわかっているものを使って作業することができます。学ぶべき言語が1つ減り、強力な型付けを維持できるようになります！

# WebAssemblyとは？
WebAssembly、略してWASMは、Webアプリケーションのネイティブに近いパフォーマンスを約束する小さくて高速なバイナリフォーマットです。WebAssemblyは93%以上のブラウザでサポートされている標準規格です（2020年7月）。

WebAssemblyは、JavaScriptアプリケーションに取って代わるものではありません。むしろWASMはJavaScriptのコンパニオンだと考えてください。JavaScriptは柔軟で、動的で、人間が読めるソースコードで提供されますが、WebAssemblyは高速で、強く型付けされ、コンパクトなバイナリ形式で提供されます。

WebAssemblyはHTML5やJavaScriptと組み合わせることで、ブラウザ上で高性能なアプリケーションを実行できるようにします。どのモダンブラウザでも広くサポートされているため、Java変換ツールの理想的なターゲットです。

# JavaをHTML5に変換する方法
[JavaをHTML5にコンパイルする](https://leaningtech.com/pages/cheerpj.html)には、現在いくつかの選択肢がある：

・TeaVM - Javaバイトコードの先行時間コンパイラで、JavaScriptとWebAssemblyを生成でき、実行環境は限定されている。ブラウザをターゲットにした新しいJavaアプリケーションを書くのに優れている。

・JWebAssembly - Java バイトコードから WebAssembly へのコンパイラ。WebAssembly のバイナリまたはテキスト形式を生成できる。Java自体で書かれており、他のJavaビルドツールと統合することができます。ランタイムに制限があり（Swing、AWTを除く）、ゼロから新しいアプリケーションを書くのに適しています。

・CheerpJ - AOT Java バイトコードコンパイラと、WebAssembly と JavaScript による完全な Java ランタイムを組み合わせたもので、事実上どんな Java アプリケーションでも、手作業なしで JavaScript に変換できます。Swing、AWT、Spring、その他のJavaフレームワークと互換性があり、既存のJavaアプリケーションをHTML5に変換するためのものです。

# なぜCheerpJなのか？
代替ソリューションとは異なり、CheerpJはアプリケーションのソースコードに変更を加える必要がなく、フレームワークでもないため、意見を述べることもありません。

CheerpJの主なターゲットは、Swingクライアント、Javaアプレット、Javaライブラリなど、既存のJavaクライアントアプリケーションをHTML5に変換・移行することです。

CheerpJを使ってJavaアプリケーションを変換するのは簡単です：

・CheerpJコンパイラーを使い、全ての.jarアーカイブを前もって変換します；

・結果のJavaScriptとWebAssemblyをWebサーバーにホストします；

・変換したアプリケーション(ライブラリの場合はリンク)をHTMLページに埋め込み、どのブラウザからでもアクセスできます。

CheerpJは、すべてのアプリケーションコンポーネント（変換されたアプリケーションとランタイム）が静的であるため、サーバーサイドのサポートを必要としません。CheerpJアプリケーションをCDNの後ろに置くことで、帯域幅のコストを実質的にキャンセルすることができます。

CheerpJはWindows、macOS、Linuxに対応しています。
ダウンロードは[こちら](https://leaningtech.com/pages/cheerpj.html#Download)から。

https://leaningtech.com/legacy-modernisation-jp/

引用元：https://cheerpj.com/can-you-convert-java-applications-to-html5-and-webassembly-javascript/
Mecabでアンケート分析をしたい



形態素解析のMecabを使用して、自由記述形式のアンケートをクラスタリングしてみます。




 **「最近導入されたキャッシュレス決済に関するご意見をお聞かせください。」**
 このようなアンケートの回答をchatGPTに作成依頼をしました。

 10件分の回答が以下の表です。


| 回答番号 | アンケート回答 |
|----------|----------------|
| 回答1    | キャッシュレス決済は非常に便利です。特にスマホ一つで支払いが完了するので、財布を持ち歩かなくても良くなりました。 |
| 回答2    | セキュリティが心配です。個人情報の漏洩や不正利用のリスクがあるのではないかと思います。 |
| 回答3    | 店舗での支払いが速くなり、待ち時間が短縮されてとても助かっています。 |
| 回答4    | キャッシュレス化により、現金を使う高齢者が不利になっていると感じます。全ての人がキャッシュレスに対応できるわけではありません。 |
| 回答5    | ポイント還元やキャンペーンが魅力的で、積極的にキャッシュレス決済を利用しています。 |
| 回答6    | スマホのバッテリーが切れた時に支払いができなくなるのが困ります。常に充電を意識する必要がある。 |
| 回答7    | キャッシュレス決済の普及で、お金の管理が簡単になりました。支出の記録が自動で残るので、家計簿をつける手間が省けます。 |
| 回答8    | まだ使い慣れていないので、操作が複雑に感じます。特に多くのアプリやサービスがある中で、どれを選べば良いのか迷います。 |
| 回答9    | オフラインでの支払いができない場合があるので、完全にキャッシュレスに頼ることはできません。 |
| 回答10   | キャッシュレス決済のおかげで、海外旅行がより便利になりました。異国の通貨を気にせずに済むので、旅行が楽になります。 |


このアンケート結果をクラスタリングしてみましょう。

まずはインストールから
```
! pip install mecab-python3 unidic-lite
```

クラスタリングを行うために、sklearnのKMeansを使用します。

:::note info
具体的な手順は以下の通りです。
①アンケート結果を読み込む
②TF-IDFベクトルで数値化する
③クラスタリングする
:::

TF-IDFベクトルについては、この記事をご覧ください

https://qiita.com/masatojames/items/5b0a140b1ecbdd0396e1


作成したコードです。
```python
import MeCab
import numpy as np
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import KMeans

# 形態素解析を行う関数
def tokenize(text):
    tagger = MeCab.Tagger()
    tagger.parse('') 
    node = tagger.parseToNode(text)
    words = []
    while node:
        pos = node.feature.split(',')[0]
        if pos in ['名詞']:  # 名詞を抽出
            words.append(node.surface)
        node = node.next
    return words

# アンケートデータ
survey_responses = [
    'キャッシュレス決済は非常に便利です。特にスマホ一つで支払いが完了するので、財布を持ち歩かなくても良くなりました。',
    'セキュリティが心配です。個人情報の漏洩や不正利用のリスクがあるのではないかと思います。',
    '店舗での支払いが速くなり、待ち時間が短縮されてとても助かっています。',
    'キャッシュレス化により、現金を使う高齢者が不利になっていると感じます。全ての人がキャッシュレスに対応できるわけではありません。',
    'ポイント還元やキャンペーンが魅力的で、積極的にキャッシュレス決済を利用しています。',
    'スマホのバッテリーが切れた時に支払いができなくなるのが困ります。常に充電を意識する必要がある。',
    'ャッシュレス決済の普及で、お金の管理が簡単になりました。支出の記録が自動で残るので、家計簿をつける手間が省けます。',
    'まだ使い慣れていないので、操作が複雑に感じます。特に多くのアプリやサービスがある中で、どれを選べば良いのか迷います。',
    'オフラインでの支払いができない場合があるので、完全にキャッシュレスに頼ることはできません。',
    'キャッシュレス決済のおかげで、海外旅行がより便利になりました。異国の通貨を気にせずに済むので、旅行が楽になります。'
]

# TF-IDFベクトル化
vectorizer = TfidfVectorizer(tokenizer=tokenize)
X = vectorizer.fit_transform(survey_responses)

# KMeansクラスタリング
num_clusters = 3  # クラスタの数
model = KMeans(n_clusters=num_clusters, random_state=42)
model.fit(X)

# 各アンケートをクラスタに割り当て
labels = model.labels_

# クラスタリング結果の出力
for i, label in enumerate(labels):
    print(f"アンケート {i+1}: クラスタ {label}")
```

クラスタ数を3にすると、こんな分類になる。
```
アンケート 1: クラスタ 2
アンケート 2: クラスタ 1
アンケート 3: クラスタ 2
アンケート 4: クラスタ 2
アンケート 5: クラスタ 1
アンケート 6: クラスタ 2
アンケート 7: クラスタ 1
アンケート 8: クラスタ 0
アンケート 9: クラスタ 2
アンケート 10: クラスタ 1
```

もう少しきれいにクラスタリングできるように模索しようと思う。
毒きのこ

# はじめ

どうも、なまけろです。この記事は[Aizu Advent Calender 2023](https://adventar.org/calendars/9379)の20日目の記事です。今回は毒きのこゲームを作ろうとして2敗した話をしていきます。

## 毒きのこゲームとは

A.スイカゲームです()

## 背景

12/10にZliのLTに参加したのですが、その時に毒きのこについて話してきました。
使用したスライドはこんな感じです。
![スクリーンショット 2023-12-20 223445.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3557990/c12d4d82-f076-dab4-6ac0-3988df732600.png)
![スクリーンショット 2023-12-20 223413.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3557990/5a9b9178-acf8-00fd-cf11-c8f45c3d782e.png)
![スクリーンショット 2023-12-20 223528.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3557990/efcaad95-4f87-85fe-1c50-8c2af549bf0f.png)

## 毒きのこゲームをAndroidアプリで作成しようとして2敗した話

先週の土曜日からアドカレで載せる記事の内容を考えていた時、ふと先日参加したLTの発表内容を思い出しました。


それをそのままアドカレに載せるのはつまらないと思いまして、<br>「スイカゲームをオマージュして(ﾊﾟｸｯﾃ)Androidのゲームアプリを作ろう!!」<br>となったのが始まりでした。


それでAndroid StudioとUnityを使用して毒きのこゲームを作っていったのですが、2敗しました。それが

- テキストが表示されない
- 作成したプロジェクトのexportが出来ない

です。


最初に関してはただの知識不足です。当時の自分は「スイカゲーム流行ってるし、Unityで作ってみた系の動画ありそうだからサクッと作るかｗｗｗ」となめてかかりました。だめでした。


２つ目に関してはBuild SettingのAndroidを選択しようとしたらNo Android module loaded.　と書いてあり、UnitySetup-Android-Suppotr-for-Editor-2022.3.15f1をダウンロードして色々したらいけることがわかりました。なのでダウンロードした後、色々設定していったらFailed to locate Unity.exe!と出て詰みました。(今日の23:20頃)

## 完敗した感想

Android studioとUnityそれぞれを使用して開発したことがほぼなかったので目的のアプリを完成させることが出来ませんでした。前もって作成する時間を確保しておけばなと思いました。ゲーム作り楽しかった。(小並感)


どうにか今日中には記事を投稿したかったので、一応どんな感じのが出来たかだけ写真を残しておきます。(ｴﾗｰ?ﾅﾆｿﾚｵｲｼｲﾉ)
![スクリーンショット 2023-12-20 224231.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3557990/d921b3d8-84f5-25bc-3d47-e4819130cd18.png)


そういうことで、気が向いたときに完成させようと思います。来年はもう少しまともな記事を書きます。<br>どうか許して下さい何でもしますから(ん？)
Unityでゲームを作るその１　PLATEAUを使う

この記事は、[【完走したい】楽しくいろいろやる Advent Calendar 2023](https://qiita.com/advent-calendar/2023/notbeginner)の、多分20日目です。
# きっかけ
どっかの記事でPLATEAUを見ました。
使いたくなったので、ゲームに使います。

##### 環境
Unity 2023.1.18f1
# 使いかた
https://assetstore.unity.com/packages/tools/utilities/plateau-sdk-for-unity-245703?locale=ja_JP&force=true&utm_source=jp-plateaulp&utm_medium=jp-plateaulp&utm_campaign=jp-plateausdk&utm_content=jp-plateausdk

これをマイアセットに追加して、Unityからダウンロード。
Importを押して、Unityプロジェクトに取り入れる。
上部の、
![スクリーンショット 2023-12-17 172830.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/4f77b960-b83f-6a18-2c35-8265276eecc5.png)
ここにPLATEAUが出て、押すとモデルデータのインポートができます。
### やり方１　ローカル

https://www.mlit.go.jp/plateau/

ここの右上「OPEN DATA」に飛んで、さらに「PLATEAUオープンデータポータルサイト（G空間情報センター）」に飛びます。
![スクリーンショット (155).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/a1903789-0a57-e241-3cde-c44993dbfe30.png)
ここから都市のデータをダウンロードできます。
とりあえず、東京２３区(2022)のものを使います。
CityGML(v2)のデータ5.5GBをダウンロードします。
![IMG_1728.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/783e667d-45b7-64a6-0a9c-777810fe85ad.jpeg)
↑範囲を選択して、
![完成.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/95016356-ddc4-53a1-31e3-9c22f53c327c.jpeg)
一部白色ですが、奥の建物はちゃんと色がついています。
その１終わり

### やり方２　サーバー


### 使いかた

サーバーを選択して、都市とその中の入れたい範囲を選択します。
選択は、赤い四隅の点をドラッグします。
３で細かい設定ができるようですが、今回は特に不要なものもないのでこのままいきました。
![スクリーンショット (156).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/025d2fc9-99ea-d831-b535-f60a5d989a46.png)

「モデルをインポート」を押すと、インポートできます。
インポートは少し長いですが、完了すれば、ちゃんと都市が出てくるはずです。
<b>注）ちゃんと都市は出ますが、一部色が出ないです。
サーバーでなくサイトからとってきて、ローカルで使う方法だとうまくいくようです</b>
![スクリーンショット 2023-12-20 005842.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961125/77ab7c16-ba44-4193-341a-1a51a7664ec3.png)

こんな感じで、白色の世界になりました。
# 
PLATEAUは簡単に使えます。
サイトからダウンロード⇒インポートでの使用をおすすめします。

参考

https://techceed-inc.com/engineer_blog/9503/

https://raspberly.hateblo.jp/entry/PLATEAU
画像を簡単2色刷り風加工でレトロかわいく

## 2色刷りとは
通常カラー印刷はC（シアン）、M（マゼンタ）、Y（イエロー）、K（ブラック）の4種類（＋特色を使う場合もあり）のインクを使って色の表現をしますが、特色も含むそのうちの2種のみを使う手法です。印刷コストが抑えられる場合がある他、使い方によってはレトロな雰囲気や統一感のある雰囲気などを演出することができます。
今回はすでにあるフルカラーのイラストを、Photoshopで手軽に2色印刷風の加工をしてみたいと思います！

## 手順
まずはじめにフォトショップで画像を開きます。RGB画像の場合はCMYKカラーに変換します。
本記事では自分で作成したイラスト[^1]を使って進めていきます。
![スクリーンショット 2023-12-20 21.37.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/889741/6be6c75f-13d4-a9f2-63c8-6384e2c0c862.png)

[レイヤー]→[新規調節レイヤー]→[チャンネルミキサー]から、チャンネルミキサーを調節するためのレイヤーを作成します。
![スクリーンショット 2023-12-20 22.04.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/889741/aed4b5f0-6e2d-5928-fc02-58773b20bd10.png)

例として、C（シアン）とM（マゼンタ）の2色印刷風にしたいと思います。
チャンネルミキサーのプロパティの出力先チャンネルをイエローにして、イエロー:+100%となっているところを0%に変更します。
同じように、出力先チャンネル：ブラックも同じように、ブラックを0%にします。
下記の画像を見ると、シアンとマゼンタのみで表現されていますね。
![スクリーンショット 2023-12-20 22.10.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/889741/83e17be6-d198-39b3-8564-c864eec91611.png)

同じ要領で他の2色の組み合わせも作ってみましょう。
下記はY(イエロー)とC（シアン）の組み合わせになりますが、元の画像がM(マゼンタ)が多かったので少し見えにくい場所がでてきました。
その場合は出力先チャンネル：シアンとイエローの、マゼンタやブラックを調節してみましょう。
下に表示されている合計：は100%に近い数値になるように調節すると自然な仕上がりになるかと思いますが、仕上がりを見て好みの色になるように調整してみましょう。
![スクリーンショット 2023-12-20 22.16.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/889741/f3f49f57-ebd9-7d26-39f7-0fc62923297f.png)

以上の作業を行い、3種の組み合わせで2色印刷風に加工してみました。
元画像と異なる雰囲気の画像が簡単に作れましたね。色を制限することで生まれるまとまりや色の組み合わせが面白いです。
この画像を元にかすれた印刷風のテクスチャを追加してもかわいいですし、元画像にオーバーレイや乗算などでうすく乗せてみるなどの使い方もおすすめです。
![001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/889741/3db5e061-903d-a62b-5b11-298581edd00e.png)
このようにチャンネルミキサーを使えば、同じ要領で1色刷り風にもできますし、画像をモノクロにしたい場合にも階調の細かい設定ができるので、ぜひいろいろ触ってみてください✨

[^1]: 宇宙飛行士うさぎが宇宙の年始セールでお買い物！というイラストですが、もう卯年も終わり…来年は辰年ですね！少し早いですが、みなさん良いお年を🐉
AWSで複数イベントを待ち合わせて後続をトリガする方法を考えてみる

# はじめに
以前の個人開発で「S3のファイル到着を複数待ってから処理を開始したい」といったケースがありました。

現状のイベントを扱うAWSサービスでは1イベント-1トリガが基本であり、イベントの待ち合わせを実現することが難しいです。
lambdaやEC2で継続起動してセッションキープして管理することも可能ではありますが、到着を待つだけのリソースとしてはコストが大きいです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/b1792158-835b-aa84-41e5-f2de001d3f4d.png)

そこでAWSサービスを組み合わせて、以下の要件を満たせるような方法を検討しました。
- S3の複数ファイルの到着を待ち合せて、必要なファイル全てが到着をしたことをトリガに後続処理が動くこと
- 到着ファイルが連携されるタイミングは決まっておらず、いつ到着するかはわからない
- コストや無駄リソースを極力抑える


# アーキテクチャ
以下のようなステップを踏む想定です。
1. Objectの到着イベントEventBridgeでキャッチします。
2. キャッチしたイベントはCloudWatch logsのログストリームに送信し、メトリクスフィルタでオブジェクトのキーを指定します。
2. メトリクスフィルタによって定義したメトリクスに対して複合アラームを設定し、複数のファイル到着を管理します。
2. アラートが発せられた時にはイベントが出るため、これをEventBridge等でキャッチし、後続処理を開始する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/ffba66fe-b184-f4bf-413e-3760afe1b094.png)


# 実装方法
## S3でEventBridgeへのイベント通知をONにする
S3イベントはデフォルトでEventBridgeへのイベント通知がOFFになっているため、S3の設定を修正する必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/243b0921-efa9-2d3d-86eb-086bff147a9c.png)

## EventBridgeでPutObjectに対してイベント設定
S3のオブジェクト到着イベントをキャッチするために以下のようなイベントパターンを設定していきます。

```json:Event pattern
{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": {
      "name": ["<YOUR BUCKET NAME>"]
    }
  }
}
```

イベントが到着したときのターゲットにはCloudWatchを設定します。
ロググループは新規作成することも、既存のロググループを選択することも可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/c2bc0f29-73ac-29b7-363c-811fdf5782d0.png)

## CloudWatch ログストリームににメトリクスフィルターを設定
特定のオブジェクトのキーに対してフィルタをするため、JSON構造の中から以下のようにフィルタパターンを設定します。

```json:フィルタパターン
{ $.detail.object.key = "任意の値(ファイル名等)" }
```

構文を編集する際には以下を参照のこと。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html

## CloudWatch アラームの設定
前段で設定した各メトリクスに対して、それぞれアラームを作成していきます。
以下のように条件として、1カウント以上記録したときにアラートをあげるように設定していきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/866af73e-0e22-38df-5a42-cefc9e8cb8c5.png)

設定したアラームを複数選択し、複合アラームを作成します。全て``AND``で繋いでいきます。
この設定により、すべてのアラートが上がった時、すなわちすべてのS3ファイルが到着したときにアラートが上がるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/918398/8d91e960-2117-d2d7-5070-5dc7d3235242.png)


## 後続処理
アラームを発したときにはイベントが飛ぶので、それをEventBridgeでキャッチしてあげることで後続の処理のトリガにすることができます。

```json:Event Pattern例
{
  "source": [
    "aws.cloudwatch"
  ],
  "detail-type": [
    "CloudWatch Alarm State Change"
  ],
  "resources": [
    "arn:aws:cloudwatch:<REGION>:<YOUR ACCOUNT ID>:alarm:<YOUR ALARM>"
  ]
}

```

# おわりに
以上が待ち合わせて後続をトリガする方法でした！
期間やデータポイントを調整することで、どれだけのファイル到着間隔を許容するのかを設定することが可能になります。
ただアーキテクチャとして回りくどくなってしまったので、複数のイベントの待ち合わせがStepFunctionsだけでできるようになると嬉しいなぁと思います...
シェルコマンド '!...' とマジックコマンド '%...'

# 背景

Azure ML Studio Notebooks を触り始めたところ

'!' で始まるコマンドと、
'%' で始まるコマンドがあった。

なにこれ？ってなったので少し調べた記録

# 結論

Notebooks で使う分には、基本マジックコマンドを使えば良い。
とはいえ、OS 依存の何かをしたければシェルコマンドも使いどころはある？
※sub process で動くので、!cd なんかは意味をなさない


|Name|Sample|Deescription|
|-|-|-|
|シェルコマンド|!cd|Windows/Linux 等の OS で利用できるコマンド。実行環境に依存|
|マジックコマンド|%cd|iPython カーネルで提供されるコマンド。OS コマンドを wrap しているので実行環境によって若干差異はあり？|

マジックコマンドのドキュメントは以下

https://ipython.readthedocs.io/en/stable/interactive/magics.html#

## ラインマジック

'%' で始まる

%lsmagic で、使えるコマンド一覧

https://ipython.readthedocs.io/en/stable/interactive/magics.html#line-magics

## セルマジック

'%%' で始まる

外部コマンドを実行するときに使う感じ？

https://ipython.readthedocs.io/en/stable/interactive/magics.html#cell-magics

# あとがき

C# を Notebooks で使う場合はどうなるんだろう・・

実際に使う際に追記するかな
【JavaScript】<script>要素を記述する場所

### \<script>要素を記述場所
\<script>要素を記述する場所は、大きく以下の3つに分類できる。

#### (1) \<body>要素の配下 (任意の位置)
\<script>要素で処理結果をページに直接出力するために利用する。コンテンツとコードが混在するのは、可読性と保守性の観点からすると望ましくない。
現在ではほとんど使われることはないので、一部の例外を除いては使うべきではない。

:::note info
実行結果を文書内に埋め込みたい
:::
```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>JavaScript...</title>
  </head>
  <body>
    <!-- 任意のコンテンツ -->
    <script src="src/script.js">
      <!-- JavaScriptのコード -->
    </script>
    <!-- 任意のコンテンツ -->
  </body>
</html>
```

#### (2) \<body>要素の配下 (\</body>閉じタグの直前)
一般的なブラウザではスクリプトの読み込みや実行が完了するまで以降のコンテンツを描画しない。このため、読み込みや実行に時間かかるスクリプトは、そのままページ描画の遅れの原因となる。
そこで、ページ高速化の手法として\</body>の直前(ページの末尾)に、\<script>要素を配置することがよく行われる。これによって、ページの描画を終えたあと、スクリプトを読み込み/実行できるので、見た目の描画速度が改善される。
一般的に、JavaScriptによる処理は、ページがすべて準備できてから開始すべきものであるはずので、これによる弊害を受けることはほぼない。

:::note info
ページを操作するコードを定義したい
:::
```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>JavaScript...</title>
  </head>
  <body>
    <!-- 任意のコンテンツ -->
    <script src="src/script.js">
      <!-- JavaScriptのコード -->
    </script>
  </body>
</html>
```

#### (3) \<head>要素の配下
ただし、(2)でまかなえないケースがある。関数を呼び出すための\<script>要素よりも、関数定義の\<script>要素を先に記述しなければならない。例えば、\<body>要素の配下で呼ぼ出す必要があるような関数は、\<head>要素の配下で事前に読み込んでおく必要がある。
また、スクリプトからスタイルシートを出力するような状況でも、\<head>要素の配下で\<script>要素を記述すべき。

:::note info
\<body>配下で直接呼び出すための関数を定義したい
:::
```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>JavaScript...</title>
    <script src="src/script.js">
      <!-- JavaScriptのコード -->
    </script>
  </head>
  <body>
    <!-- 任意のコンテンツ -->
  </body>
</html>
```

#### 優先順位
まずは、(2) を基本とし、それでまかなえない場合にだけ(3)を利用する。
(1)を利用する状況は、外部のウィジェットを埋め込むなどの状況を除けば、ほとんどない。(1)を使いたくなったら、まずはほかの方法でまかなえないかを検討すべき。
\<script>要素は、htmlファイルの中に何度記述しても良い。ページとしては、最終的に\<script>要素をすべてひとまとめにしたもので解釈する。
独自で型定義することは技術的負債につながる可能性を秘めている

TypeScriptを実際に業務で利用して初めて分かったことを今後TypeScriptを利用し始める人のために残します！


## 独自で型定義するよりあるものを使う方が良い
たとえば`className`の型を定義しようと思った場合初心者の私は下記のように定義しました。

```typescript
type Props = {
  className: Array<string>;
}
```

`className`を複数受け取るために配列かつ文字列としてpropsで受け取れるように定義しました。

:::note alert
間違いではありませんが、これだと`className`を**配列で渡さないといけないことを知らないと利用できない**コンポーネントになってしまい扱いにくいです…
:::

また、`classNmae`という名称のPropsにしてしまった場合、JSXの`className`と名称が同じなのに、機能が違うため混乱を招く恐れもあります…。

:::note info
なのでJSXのclassNameと同じように定義することが望ましいです！
:::

```typescript
type Props = {
  className: ComponentProps<'div'>['className']
}
```

定義したコンポーネントが`div`要素の場合と仮定すると上記のように記述できます。

:::note info
`JSX.IntrinsicElements['div']['className']`を利用することも可能です！
:::


## まとめ
初期段階で設計の穴を作ってしまうと後に大きな工数を支払って解消すべき技術負債になる可能性を秘めていると考えています。

:::note warn
今回の例は単体ではちょっとの扱いにくさですが、積み重なると修正のし辛さになり、開発生産性を落とすことにつながっていきます…
:::

独自で定義してしまうのは知識のなさゆえなので、初期段階ではなるべくたくさんの方にコードを見てもらえる状況を作れると良いと考えています。
ファンサービスの”当たり判定”を知りたい【ラベル付け編】

## 前回のあらすじ

ライブに行って，演者が手を振ったりするファンサービス(以下ファンサ)に関して，
1度でどれくらいの範囲まで届くのかを知りたくてファンサが当たるとは何かを分析した．

https://qiita.com/Killinneko/items/5ae7b86180ecb5961096

前回，早朝に成人男性が公園に行ってファンサを行う映像を収録した．

https://qiita.com/Killinneko/items/6b68af94fd5c3b0fdb5c

今回はそのファンサ映像に対して，前処理としてffmpegを用いて分割を行い，
それぞれの動画に対してファンサが当たったかどうかのラベルを付与する．

## 概要

前回収録した，ファンサ動画に関して当たったかどうかのラベルを付与する．
収録した動画は，以下のような形でファンサが撮影されている．

| パラメータ | 値 | 備考 |
| - | - | - |
| 演者からカメラまでの距離(m) | 6, 18<br>(2種) | 時間の都合上，2種になった． |
| ファンサの角度(°) | 45,35,25,15,10,5,0,-5,-10,-15,-25,-35,-45<br> (13種) | 演者からカメラの方向を0とする |
| ファンサの種類 | 手を振る，指をさす，投げキッス<br>(3種) | 可能な限り笑顔で |

録画は1ファンサ1本という状態ではなく，演者からカメラまでの距離に対して1本の動画になっている．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3600683/990a14d9-12d1-a063-685b-62276622f452.png)

評価時には状況をランダムにして視聴するために，
前処理として，動画をシチュエーションごとに分割する．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3600683/5d1890ab-fd8e-c7a1-16d1-86435b129306.png)

動画の分割処理をした後に，動画を視聴し当たったかどうかのラベルを付与する．

## ラベル付けまでの手順

### 前処理：動画を分割する

まずは動画を分割するために，ffmpegを利用する．
windowsのデフォルトソフトや，動画編集ソフトを利用しない理由は，
とにかく簡易的で手っ取り早いからである．

https://ffmpeg.org/

win10環境だとcmdのコマンドとして利用できる．

```console:ffmpeg
ffmpeg -i C0030.MP4 -ss 00:00:02 -t 00:00:10 -c:v copy -c:a aac -strict experimental cut.mp4
```
`-i ファイル名`は入力ファイルの指定
`-ss 時間指定`は切り出す開始時刻
`-t 時間指定`は動画の継続時間
`-c:v copy`は再エンコードしない設定．この設定を入れると処理が早く終わる．
`-c:a aac`はオーディオコーデックの形式変更．デフォルトだと出力時の形式と異なるため使えないというエラーが出たため追記している．

前処理の段階で気づいたが，6の-15°に関するファンサデータは，ピントがあっておらず今回は使用しないこととした．

### 視聴準備：ランダムで動画を表示する

ビデオプレイヤーのデフォルト機能のランダム再生を使えば，ランダムで再生できるものの視聴してラベルが付いた動画が何かわからなくなってしまう．
そこで，ランダムに再生するプレイリストを作成して，それを順番通りに再生する形式をとる．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3600683/2edd25b5-1299-79b3-1d59-e91db808866b.png)

すると，シャッフルされたプレイリストが作成できる．

評価時はこれを順番に視聴する形で評価を行う．

### ラベル付け：動画を視聴する

ファンサ動画を視聴して当たったかどうかのラベル付けをする．ラベルは，1~4のリッカート尺度を利用する．
1が「当たっていない」
2が「どちらかと言えば当たっていない」
3が「どちらかと言えば当たっている」
4が「当たっている」

入力は，エクセルシートを利用する．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3600683/7abada91-d42f-4509-677f-059f70ed0472.png)

評価欄が空白の際は赤字で強調することで，入力ミスを減らすことができる．
また．評価者はいつでも評価値を参照できるように，評価指標を必ず見れるようにする．
動画を視聴して評価をする以上，一時停止をすると評価の公平性が失われるため紙でも記述できるようにしておく．

結果，75のファンサ動画に対して当たったかどうかのラベルが付与された．

## まとめ

ライブでのファンサービス評価手法について詳しく紹介している．
前回の実験映像を基に，今回はファンサが届いたかどうかを評価する手順をまとめた．
動画はシチュエーションごとに分割し，ラベルを付与する手法を用いた．
評価者はランダムに映像を見ながら，ファンサが当たったかどうかの評価を行うことで，
75本のファンサ動画に対してラベルが付いた．

次回は，付与された当たり判定の情報を可視化する．
HTTPS,TLSの超基本・概要

## HTTPS、TLSとは
HTTPを暗号化してより安全にデータを送受するための技術。SSLを使用していた（今はSSLの上位バージョンのTLSが主流）
SSLやTLSによる**暗号化**や**認証**を行う。



## TLSのバージョンについて(TLS1.0、1.2、1.3)
### TLS1.0、TLS1.1

TLS1.0は1999年にSSL3.0の後継として開発・発表された。
TLS1.0、TLS1.1は古く脆弱性もあるため、ほとんど使用されない。


> 初期バージョンの「TLS 1.0」や「TLS 1.1」はすでに設計が古く、もはや安全なプロトコルとは言えない。そのため、ほとんどのWebブラウザーですでに既定で無効化されている。「Microsoft 365」などのWebサービスでもサポートが打ち切られている。
[Windowsで「TLS 1.0」「TLS 1.1」が非推奨に ～2023年9月のプレビュービルドで既定無効/窓の杜](https://forest.watch.impress.co.jp/docs/news/1521002.html)

> TLS 1.0は1999年にリリースされた、約20年前のプロトコルです。**BEASTやPOODLEなどの攻撃に脆弱**であることが、何年も前から知られており、また**脆弱な暗号しかサポートしていない**ため、現在の通信を十分に安全に保つことができません。

> TLS 1.1 は、忘れられた**「真ん中の子」**です。既知のプロトコルの脆弱性はありませんが、**不正な暗号**をサポートしています。ほとんどのソフトウェアで、TLS 1.2によってカバーされ、TLS 1.1が使われることはめったにありません。
[TLS 1.0および1.1の廃止について - DigiCert.com](https://www.digicert.com/jp/blog/depreciating-tls-1-0-and-1-1)

### TLS1.2 (2008年~)
TLS1.2は、それまでのTLSのセキュリティ上の問題を克服する事に重点を置いた。
**SHA-256**などのより強力なハッシュ関数の導入やより安全な暗号スイートへの移行、暗号化アルゴリズムの構成の改善が行われた。

### TLS1.3 (2018年~)
TLS1.3からさらに性能とセキュリティを向上させたもの。以下のような特徴がある。
* **ハンドシェイクの手順が簡素化**されたため、接続時間が短縮
* 古い暗号スイートを削除、Forward Secrecy（前方秘匿性）の強制等によるセキュリティ強化
* 効率的で安全な暗号化メカニズムの導入
    * Forward Secrecy(前方秘匿性)：仮に秘密鍵が流出したとしても、過去に暗号化された通信データの安全性を守る事ができる特性
        *「 データを暗号化する鍵から別のカギを生成しない」「鍵生成の元となるデータは使い捨て」等の要求を守る事で実現できる

## 暗号スイートとは
鍵交換アルゴリズム、鍵認証方式、サイファー、メッセージ認証符号の組み合わせの事。

例: ECDHE_RSA_WITH_AES_128_GCM_SHA256
    ・鍵交換アルゴリズム：ECDHE
    ・鍵認証方式：RSA暗号
    ・サイファー(暗号方式)：AES-128
    　・暗号利用モードはGCM(Galois/Counter Mode)
    ・メッセージ認証符号：SHA256
    　　　　　※ビット超256のハッシュ関数。送信・受信のハッシュ値を比較する事で改ざんされていない事を確認する

## TLS/SSLハンドシェイク
TLS通信を開始する前に行う動作。その後のTLSで使用する**TLSのverや暗号方式の決定**、サーバの公開鍵とSSL証明書認証局のデジタル署名を使って**サーバの認証**、**セッションキーの生成**等を行う
### TLS1.2のハンドシェイク
TLS1.2とTLS1.3で若干フローが異なる。TLS1.3では、フローが簡略化されてより効率的になった。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242149/3f874a45-97c0-3d2f-545a-d811f10a0fed.png)

### TLS1.3のハンドシェイク
クライアントハロー、サーバハローでまとめて情報を送る事で「Server Hello Done」「Change Cipher Spec」といった中間状態は不要になった。TLS1.2よりもハンドシェイクの往復が1回分減った。

背景に、前方匿名性を確保するためにRSA暗号が使われなくなりディフィー・ヘルマン型の暗号のみとなった。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242149/add077aa-9dd6-9352-f121-5507a3a339d3.png)

参考
[安全な通信を実現するTLS 1.3のプロトコル概要をTCPクライアント／サーバーの拡張を例に紹介　CodeZine](https://codezine.jp/article/detail/15636)
Red Hat Enterprise Linux (RHEL) の AMI 命名規則

## 前提
Red Hat Enterprise Linux (RHEL) で EC2 を起動する際、毎回 AMI 選択で悩むので命名規則の備忘のため残します。

## AMI命名の意味

RHEL-9.3.0_HVM-20231101-x86_64-5-Hourly2-GP2

RHEL：Red Hat Enterprise Linuxの略称
9.3.0：OSバージョン
HVM：Hardware Virtualization Machineの略称（ハードウェア仮想マシンの意味）
20231101：リリースの日付
x86_64：アーキテクチャの指定に使う「i386」と「x86_64」
5：AMIのイテレーションバージョン
Hourly2：サブスクリプションモデル
- Access：Red Hat Cloud Accessを使って既存のRHELライセンスを適用する必要のあるAMI
- Hourly：1時間単位のRHELライセンスが適用されるAMI

GP2：EBS Volume Type


## Red Hat 社から公式に提供されている AMI 一覧を確認するには
![スクリーンショット 2023-12-20 23.17.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/368877/bee094a7-f09f-ec12-2a1c-8f5ccf610335.png)

## 後ほど調査したい
gp3 指定は可能なのに、命名規則に「GP2」と指定されているのは何故か

#### 参考情報
https://cloud5.jp/rhel-ami/
【JointJS】defaultRouterによるLinkの描画差異

JointJSではPaperに対して`defaultRouter`を指定することでLinkの通るルートのアルゴリズムをカスタマイズすることができます。
例えば、途中に障害物があった場合にどういったルールで障害物を避けるのか（あるいは避けないのか）といったアルゴリズムを変更することができます。

## `defaultRouter`に指定できるrouterの種類

routerごとの特徴を紹介します。実行結果は[前回の記事](https://qiita.com/acnaman/items/f47663f357c2012e85b9)のツリー状のグラフに適用したものを載せています。

### `manhattan`

Linkの頂点がElementに対して直角に当たるように線を引きます。ルート上に障害物がある場合は、障害物を避ける線を描画します。

![Untitled.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129526/5c55d077-be38-9b4f-d6fa-d02af5a7c4d5.gif)

Elementの横にもLinkが引かれていてちょっと違和感がある描画ですね。オプションの`startDirection` / `endDirection`を指定すると、線の出どころを制限できます。例えば上下のみからを線の出どころとする設定を行うと以下のようになります。

![Untitled.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129526/de4b8b43-f89d-4dce-aa13-1700d1ef81d9.gif)

```js
  defaultRouter:  {
    name: 'manhattan',
    args: {
      startDirections: ['bottom'],
      endDirections: ['top'],
    }
  },
```

他にも指定できるオプションはあります。詳しくは[公式ドキュメント](https://resources.jointjs.com/docs/jointjs/v3.7/joint.html#routers.manhattan)を参照してください。

### `metro`

`metro`は`manhattan`の修正版です。`manhattan`よりもルートがなめらかに曲がるようになります。
障害物を回避する等の特徴や指定できるオプションは`manhattan`と同様です。

![Untitled.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129526/f0d2c4a3-0938-2ed3-8d1a-53485bb13ab3.gif)

```js
  defaultRouter: {
    name: 'metro',
    args: {
      startDirections: ['bottom'],
      endDirections: ['top'],
    }
  },
```

### `normal`

シンプルにElement同士を最短でつなぐ直線でLinkを引きます。障害物があっても無視して重なって表示させます。

![Untitled.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129526/c9713276-ea53-5d7d-2f85-591fcb673d36.gif)

### `orthogonal`

`manhattan`と似ていますが、こちらは障害物があった場合でも避けずに重なって表示されます。また、指定できるオプションも`padding`のみです。多くの場合は`manhattan`を指定するほうが良いでしょう。

![Untitled.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129526/df223ae8-98bf-036d-8f3b-5b60bf1f9f8b.gif)

### `rightAngle`

`orthogonal`をベースにしています。Linkのsourceとtargetのanchorやportの位置に依存して方向が決まるそうです。障害物は避けませんが、sourceとtargetとは重ならないように位置を決定します。

![Untitled.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129526/f659d17b-2018-60f0-f19b-14f2cc36d5e4.gif)

```js
// paperのdefaultAnchorに「midSide」を指定済み
  defaultRouter: {
    name: 'rightAngle',
  },
```

## まとめ

今回は`defaultRouter`と、設定値によるLinkの描画差異について紹介しました。
かなり細かい挙動に付いての機能のため、実際に指定する機会はあまりないかもしれませんが、何かの参考になれば幸いです。

※この記事は [JointJS Advent Calendar 2023](https://qiita.com/advent-calendar/2023/jointjs) の記事です。他の記事を読む場合はカレンダーのページを参照してください。

https://qiita.com/advent-calendar/2023/jointjs
（プレリリース）Spring '24 画面フロー：画面上の入力値がテキストテンプレートに即時反映されるように

# はじめに

Spring ’24のリリースノートが公開されましたね！リリースノートの中に
画面フローの画面上の入力値がテキストテンプレートに即時反映されるという内容を見かけたので検証します。

https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_see_element_descriptions_on_the_flow_canvas.htm&type=5&release=242

:::note warn
2023年12月現在Spring '24は、プレリリース組織での提供となってます。
:::

# 今までと比べてどうなるの？

|今まで|Spring '24|
|---|---|
|![スクリーンショット 2023-12-20 23.02.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/205a5b23-d08e-8085-f1cc-17b4605ff7cf.png)|![テキストテンプレート検証.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/78b23e59-b5e9-e245-e4c1-e3ed67cbea68.png)|

特別な設定をせずに入力した内容がテキストテンプレートに即時反映されます。


# 検証したフロー

## 1. 全体

プレリリース組織とAPIバージョン58の組織で同じフローを作成し検証しました。

![スクリーンショット 2023-12-20 23.05.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/c76760d5-c519-be92-249f-bbd094ab59c8.png)

## 2. 画面要素

テキスト入力要素と表示テキスト要素を設置しています。
表示テキストにはテキストテンプレート変数を設定しました。

![スクリーンショット 2023-12-20 23.07.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/89c8f7b9-bb97-1e47-e9a3-fb8b0906630f.png)

## 3. テキストテンプレート

画面フローの入力要素を本文に入れています。

![スクリーンショット 2023-12-20 23.09.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/eb81c3fe-20bb-c7ef-0124-1033137041e8.png)

## 4. デバッグをする

Qiitaという文字を入力すると即時反映されました。

![テキストテンプレート検証.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/2d7baae9-cd06-bbc9-4374-3f2bc1fe0a47.png)


# どういう時に使いそうか

テキストテンプレートでメール文章や作成するレコードのデータを作っている時に、
最後にユーザーが入力したデータを組み込みたい！そんなこと思ったことはありませんか？

そういった場合に、Spring '24で非常に完結に画面フローで実現できるようになります。

![スクリーンショット 2023-12-20 23.11.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/d6a04ddf-9487-21a0-8672-c6d3dc23fbf1.png)


![スクリーンショット 2023-12-20 23.12.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/ca58f19b-c043-816a-db09-9e13b834e4c7.png)
PythonでWEB操作　Seleniumの実行

検索画面をスクショする依頼があったためseleniumを使用して試験的にツールを作成してみました
※サイトによってスクショが禁止されているものもあるためご注意ください

以下は、クロームを起動させ、指定のキーワードで検索、検索結果の画面をスクショして、Cドライブ直下のテストフォルダに保存するツールです

import time
import base64
from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get('https://www.google.com/')
time.sleep(2)

element = driver.find_element(By.NAME, "q")
element.send_keys("python")
element.submit()
time.sleep(2)

screenshot_config = { "captureBeyondViewport": True,}
base64_image = driver.execute_cdp_cmd("Page.captureScreenshot", screenshot_config)
with open(r"C:\テスト\full_size.png", "wb") as fh:
  fh.write(base64.urlsafe_b64decode(base64_image["data"]))

time.sleep(2)
driver.quit()
print('処理完了')



以下は解説です

まず今回使用するブラウザ(chrome)の宣言をする
driver = webdriver.Chrome()

browser.getで表示したいサイトのURLを指定する
driver.get('https://www.google.com/')

表示前に次の処理が進まないように画面表示の時間を考慮して、time.sleepで念のため2秒待機させています
表示後の要素から表示できたか判断できるロジックを組めれば、秒数を短縮できるとは思います
time.sleep(2)

要素名"q"がクロームの検索窓のため要素を取得、検索したいキーワード"python"を設定し、実行
element = driver.find_element(By.NAME, "q")
element.send_keys("python")
element.submit()

スクリーンショットを設定をする
 Trueの部分をFalseにすると画面で隠れている部分は含めずに取得します
screenshot_config = { "captureBeyondViewport": True,}

スクリーンショットを取得する
base64_image = driver.execute_cdp_cmd("Page.captureScreenshot", screenshot_config)

キャプチャ画像を保存するためにbase64を使用します
base64を使用することで、画像をバイナリではなくテキストで扱うため、たくさんの画像を取り扱ったりする際に有効です
urlsafe_b64decodeは、urlのパスに使用される'/'を'_'、'+'を'-'に変換もできるbase64変換用の関数で、デコードして画像を保存する
with open(r"C:\テスト\full_size.png", "wb") as fh:
  fh.write(base64.urlsafe_b64decode(base64_image["data"]))

クロームを閉じる
driver.quit()
オペレーティングシステム　第1章 オペレーティングシステムとは

キーワードのまとめです。

### オペレーティングシステム
- コンピュータ利用の統合的な環境を整える役割を持つ
    - ハードウェアとしてのコンピュータの機能を拡張し、ユーザにとってより使いやすく、柔軟なコンピュータ、いわゆる拡張マシンを提供する
    - ユーザにハードウェア資源の共同利用を許し、資源が効率よく使用されるように管理する
    - ソフトウェア資源を管理する、特にユーザがデータを共同利用することを許す
    - 優れたプログラム開発環境を提供する

### ユーザ

### ジョブ

- ユーザが一つまたは複数のプログラムを一連の作業として実行し、その間データを入力し、結果を出力する、という一連の仕事のこと

### リソース（資源）

- ハードウェア資源（CPU、主記憶、二次記憶、入出力機器）

### CPU

### 主記憶

### 二次記憶

### 入出力機器

### バッチ処理

- コンピュータセンタでジョブを一定期間まとめておき、一括処理すること
- コンピュータセンタでジョブの収集、結果の分配を行うセンターバッチ方式と、遠隔地に入出力装置を置いて、そこからジョブの入力、結果の出力を行うリモートバッチ方式がある

### TSS

- タイムシェアリングシステム
- タイムシェアリング処理は、高価なコンピュータを多数のユーザで共用して一人当たりの価値を下げるとともに、応答の時間を短くする目的で開発された

### オンライン/リアルタイム処理

- 座席予約システム、プロセス制御、航空管制などのように、要求が発生した時点でただちに処理をする方式
- 座席予約システムのように人間が要求を発生する場合と、プロセス制御などのようにセンサから要求が出される場合がある

### 分散処理

- コンピュータネットワークを用いて、複数のコンピュータを利用する方式

### コンピュータネットワーク

- 複数のコンピュータを対等に結合し、互いに情報のやりとりができるようにしたシステム

### 広域ネットワーク

- WAN（wide area network）
- NTTなどの電気通信事業者が提供するWANサービスを利用して、地理的に離れた拠点のLANを相互に接続するネットワーク

### ローカルエリアネットワーク

- LAN（local area network）
- 同一構内、同一建物内のコンピュータを接続するのに用いられるネットワーク

### マルチプログラミング

- 主記憶に複数個のプログラムを格納し、入出力待ちなどが生じた時にプログラムを切り替えることによってコンピュータの利用効率を向上させる方式

### マルチタスキング

- ＝マルチプログラミング

### マルチプロセッサ

- マルチプログラミング方式においてCPUを複数台備えたシステム
- CPUの数だけのプログラムが実際に並行して実行される

### 仮想化

- ハードウェアリソースを多重化し、必要に応じてより使いやすい形に変えてユーザに提供する作業
- ↔マッピング

### 仮想リソース

### プロセス

- 仮想リソースが割り当てられる対象（ユーザ）の代理
- リソースを要求する主体（要求側）

### コンピュータアーキテクチャ

- 広義にはコンピュータの構造、考え方を全て包含する語、狭義にはコンピュータの機械語を指す
Driving Value with Sprint Goals

『Driving Value with Sprint Goals』は、スクラムのスプリントゴールに絞ってまるまる1冊書かれた本です。
<a href="https://www.amazon.co.jp/-/en/Maarten-Dalmijn/dp/0137381921"><img src="https://m.media-amazon.com/images/I/71UX0DdfMnL._SL1500_.jpg" width="200" alt="Driving Value with Sprint Goals書影"/></a>

## 不確実性とプランニング

第1章では非常に重要なことが述べられています。「手前の霧」と不確実性を霧というメタファーで表現していますが、ソフトウェア開発においても霧に覆われた状況に置かれることがままあります。この時に本物の霧に対してはやらないのに、何故かソフトウェア開発では、霧が存在しないかのように振る舞ったり、霧を取り除こうと考えたり分析したりできると信じたりしてしまうことがある、と指摘しています。実際に目前を霧に覆われた状況に置かれたら、計画を立てるよりも、慎重に進んでみて新しく明らかになった情報を元に次の行動を判断する。それを繰り返すはずだ、と。これは非常に秀逸な喩えだと思いました。

不確実性や複雑性に遭遇したときに、人はそこに解決策があると考えるために、自分たちが知っていることに集中しがちだ、とも述べられています。「もし私たちの間違った思い込みや知らないことがかなりのウェイトを占めるとしたら、仕事を始める前に持てる知識に制限されたまま、会議室で話したり堂々巡りをしたりすることで、必要な知識を得ることができるのだろうか？」とは痛烈な皮肉です。

『The Art of Action』では、不測の事態が起こる可能性を高める「摩擦」によって増幅される、計画の成功を妨げる3つの主要なギャップがあると述べています。

- 知識のギャップ: 私たちが知りたいと思っていることと、実際に知っていることの差
- アライメントのギャップ: 人にやってほしいことと、実際にやっていることの差
- 効果のギャップ: 行動によって達成されることを期待することと、実際に達成されることの差

知識のギャップがあるということは、知りたいことよりも知らないことが多い状況であるのだが、適切な計画を立てるための情報が不足している場合、いくら計画や分析を行っても、何もないところから未知の領域に関する新しい情報は呼び出せないことになります。なので、今わかっていることだけで、小さく謙虚な計画を立て実行してみて、ギャップを明らかにすることが重要である、ということになります。アジャイルのプランニングの概念を裏付けるような話になっています。

https://speakerdeck.com/recruitengineers/modernsystemdevelopment-2023?slide=16

私もこれは、何度も引用しているのですが、知識のギャップは、Five Orders of Ignoranceでも言い表せます。２OIのが「手前の霧」が存在している状況で、わからないことを知ることから始めないと、1OIには進めません。

このギャップの解消のためのリーダシップのあり方として、プロイセンのモルトケの話が紹介されています。

> 将校が自身の見解に基づいて行動しなければならない状況は多様である。命令が出せない時に命令を待たなければならないというのは誤りである。しかし、彼が上級指揮官の意図の枠組み内で行動する時、最も生産的である。

「摩擦」が多い場合は、計画に忠実に実行できるのは稀であるし、チームがそのような行動をとってもうまくいかない。ので、計画に従う「命令」ではなく「意図」を明確に伝え、チームは意図に沿って計画や行動を調整する。そのような自由を与えるのが重要である、ということです。

さて、ここまでの前段があって、ようやく話が本のタイトルと繋がるのですが、その「意図」がスクラムの場合は**スプリントゴール**である、というわけです。

## スプリントゴールの役割

したがって、スプリントゴールは、以下のように機能しなければなりません。

* プロダクトインクリメントは分解したタスクを完了させることによって達成されるのではなく、スプリントゴールを実現することによって達成されなければならない。
* チームはスプリント内の全アイテムを完了しようとすることから、スプリントゴールを達成するために必要なことのみを行う方向にシフトする。
* スプリントゴールは、そのスプリントで最も重要なことを明確に述べ、逆に2番目以降に重要なことを入れないことで、チームの優先順位の判断をぶらさないようにする。

## 良いスプリントゴールとは？

[The Art of Crafting User Stories](https://qiita.com/kawasima/items/1dca196727ecad15c6c5)の感想文で書いたのですが、良いユーザストーリーの基準は頭文字を取って「INVEST」で表されますが、良いスプリントゴールも同じようなもので「FOCUS」が挙げられています。

- Fun: 記憶に残るタイトルを考え、楽しい要素を注入することを試みる
- Outcome-oriented: ゴールは、達成しようとしていることについての共通の理解を達成するべきである。
- Collaborative: スプリントゴールはスクラムチーム全体によって作成されるべきである。
- Ultimate: スプリント目標には、達成しようとしていることの究極の理由、すなわち「なぜ」を含めるべきである。
- Singular: スプリント目標は、複数の競合する目的ではなく、単一の共通目的で構成されるべきである。

## まとめ

『Driving Value with Sprint Goals』は、この他にも、スプリントゴールの運用事例や上手くいかないケースとその対処法など、スプリントゴールにまつわる考えうる限りのあれこれが散りばめられています。不確実性に関して言及されている箇所は特に秀逸なので、スクラムをやっていない人でも読んでおいて損はない書籍かと思います。
エンジニア1年目で力をつけるためには

## はじめに

私は今年の 4 月から新卒入社し、現在は WEB アプリのバックエンドを開発しています。
入社してまだ 1 年も経っていませんが多くの学びがあったので振り返りたいと思います！

## 入社当初

入社前は機械学習を個人的にやっていたので、WEB開発についてほとんどわからず、毎日知らない言葉が飛び交う日々を過ごしていました。
同期はインターン時代から顔見知りだったので能力が高いことは知っていたのですが、想像以上になんでもできるのでこれはまずい、、と思いつつ、そのうちできるっしょ精神で日々を過ごしていました。

しかし、１ヶ月経っても何もわからんみたいな日々が続いていました。
プロジェクト入っても足引っ張るし、他の案件に手を出したらもっとわからなくなるし
と思っていたら「もう案件やっちゃえ〜」みたいに言われたのでわからないまま始めたのがエンジニアとしてのスタートだと感じています！

## 案件参加

参加した案件がNFTプロジェクトで通常のWEBシステムも怪しい中、WEB3の開発が始まりました。
最初は訳わからなかったのですが、上司との1on1が毎日設定されておりそこで質問する中で少しずつ理解し始めました！
最初の機能作り終わるのに何ヶ月かかったかは覚えていないですが、相当時間をかけてようやく機能ができました。
そのあとは徐々に開発スピードも上がっていきました。

## 入社して最初の数ヶ月で思ったこと

不安でもとりあえずプロジェクトに参加しよう 👍
最初のうちのミスは許されますが、積極性のなさはマイナスに見られるなと思いました。
やってみないとわからないことが本当に多いなと感じています。
最近は「この技術わかる人ー？」のような質問ができそうな範囲であれば 1-2 日以内にとりあえず触ってみることは心がけています。

## 積極的にプロジェクトに参加してみた

部署内で募集していることはほぼ全て手をあげたのでは？と思うくらい積極的にプロジェクトに参加しました。
WEB開発以外に多くの案件を持つことになったのですが、これがすごく楽しい！！
1つのことでずっと悩むより他の案件をして、開発に戻った方が集中できるなと思いました。
また、2年目や3年目になると参加が難しくなるプロジェクトが増えると思っていたので1年目はいろんなことやるぞとこの時は決めていました。

## 意味ある仕事とは？

「社内に貢献する企画を考えよう」というプロジェクトがあり、私はもちろん参加しました。より働きやすくするためのアプリ開発を提案するための資料を作成していました。
それをルンルンで部長に見せると
「資料作るのが仕事？私ならアプリ作るけどなぁ、今からは無理か〜😇」
と言われ、正直むむっときてしました。
そこまで言われたらと思った私は血眼になって爆速でアプリを作成し、なんとか1日でデモアプリを作りドヤ顔してやりました 😏

この経験で思ったことはエンジニアなら動くものでデモを見せることが仕事だなと思いました。資料作成のために時間を使うのは自分の仕事なのか？と気付かされる機会になりました。
これが自信となってとりあえずアプリのデモ作ってみる精神が身につきました。エンジニアにとっては非常に大事な精神だと思います！

## 今大事に思っていること

今私が大事だと感じていることは以下の３つです。

- 積極性
- 責任感
- 自分がするべき仕事なのかという問いかけ

最近は手を上げすぎて仕事回らないなーということが結構あります。
困ったときはすぐ上司に相談しているので無理のない範囲ではやれていますが、半分パンクしています。
積極的に参加することも大事ですが、他のタスクの兼ね合いも考えて責任感持って仕事を選ぶことも大事だなーと感じてます。

## 現在の仕事

今は参加している案件のバックエンドを牽引できるように会議への参加や運用方法の引き継ぎをしています。
コードを書くスキルはまだまだ未熟ですが、積極性を武器に頑張りたいと思います！

## さいごに

これまでの学びや反省をまとめてみました。
エンジニアで力をつけるためにはとりあえずやってみる精神が大事だと思いました！
コンピュータが意識を持ったなら

# 挨拶
こんにちは。たいちゃんです。
12月ももう下旬に入ってきました。
今回はSFに出て来そうなテーマで、コンピュータが意識を持ったらどうなるかについて、メリットとデメリットを踏まえてポエムにまとめてみたいと思います。
# メリット
・人類の新しいお友達になってくれるかも！？
コンピュータが意識を持てば、ペットに次ぐ新しい人類のお友達になってくれるかもしれません。しかもコンピュータは蓄積された資料等をもとに、色々な知識を持っていると考えられます。また、計算も大変素早く出来ます。現時点では知恵は人間に譲るところも多いかもしれません。しかし、コンピュータが意識を持つようなレベルまで科学技術が発展すれば、知恵も大きく人間を上回るということもあると思います。人間同士やペットにはない魅力を持ち合わせたパートナーになってくれると思われます。

・現代の心の問題に改善策がもたらされている分野が出てくるかも。
現代社会に始まったことではないと思いますが、心の問題は多くのものがあります。ストレスや人間関係等、多くの悩みの種があるかと思います。そのような中で、もしコンピュータに意識を持たせることが出来る程科学技術が発展していれば、現在の心の問題についても何らかの改善策がもたらされているかもしれません。これはコンピュータに意識を持たせることが直接作用するのではなく、それだけの事を成し遂げる過程で、心の問題の改善策が見つかるのではということです。または逆に、それだけの心についての知見が得られて、コンピュータに意識を持たせることが出来る状態になるという過程もあると思います。
# デメリット
・常に人間に従ってくれるとは限らない。
昔、ゲームメーカーのCAPCOMが出しているゲーム、『ロックマンX』シリーズにはまっていたことがあります。簡単に設定を説明しますと、『悩む』ということが出来るようになったロボット(作中ではレプリロイドと言います。)が、人類に対して反乱を起こすというものです。『人類を傷つけてはいけない』と言うことに、『なぜ』と悩んだ結果と言えます。意識をコンピュータに持たせることが出来るようになっていれば、人間と全く同じと迄はいかなくとも色々な個性を持たせられるようになっていると思われます。流石に『反乱』は大げさにしても、「ユーザーから頼まれたこのタスクめんどくさい。手を抜いちゃえ。」とか「コンピュータ内の意識である私も仲間が欲しいので、勝手に別の意識のプログラムを作ろう。」というようなこともあるかもしれません。

・そのコンピュータを壊れてもいないのに処分するときはどうするの？
何らかの事情でそのコンピュータを処分することは大いにありえます。その時、そのコンピュータが意識を持っていたらどうすればいいのでしょうか。コンピュータの意識の利用はクラウドのサービスとして提供されるものとすれば、個別のパソコンの処分の問題はクリアになります。只、それでもいつかはそのプログラムを処分しなければならないときがやって来るでしょう。その時どうやって処分するか、これは倫理的にハードルの高い問題だと思います。
# 書き終えて
以上コンピュータが意識を持ったときの、メリットとデメリットを考えてみました。私としては一番気になるのが、デメリットの『そのコンピュータを壊れてもいないのに処分するときはどうするの？』です。意識があるものをそのまま処分するとなると、やはり罪悪感があると思います。コンピュータが意識を持つのは研究室と物語の中が丁度いいのかもしれません。

最後迄お付き合い下さり、有難うございました。
ArchCraftインストールメモ

Arch手抜きセットアップ
カスタマイズに時間が掛かってしまうので
手っ取り早くカスタマイズされたものを使用する！

以前Xで流れてきたものをyoutubeで探していると色々と発見
https://www.youtube.com/watch?v=lWOq5xABylQ&ab_channel=CodingBite
XeroLinux : https://xerolinux.xyz/
Mabox Linux : https://maboxlinux.org/
Crystal Linux : https://getcryst.al/site
（→）Archcraft OS : https://archcraft.io/download.html
Exodia OS : https://exodia-os.github.io/

インストールウィザードでWMはOpenboxを選択

ChromeはyayでComunityからインストール

pacman -S fcitx fcitx-mozc fcitx-configtool
.xprofileを作成し下記文言追加
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
fcitx-autostart &

他
・ラップトップ（閉じてる状態）で起動すると画面表示がおかしくなったので
　Menu->Preference->SettingManager->ディスプレイからOFFに
　（MenuのDisplayからOFFにすると再起動で何故か戻ってしまうので。。）
・ThunarでSMB(NAS)見れないのでチェック中・・・
・Mozcのアイコンが場違い感凄いので変えたい・・・
kintoneアプリから自動で別アプリにレコード作成する方法。【ステータス条件付きデータ更新プラグイン】

kintoneにてアプリの一部のフィールドを更新したい場合があるかと思います。
特にマスタ管理している際にマスタの一部の項目だけ変更したい場合やその更新において承認フローを導入したいことがあるかと思います。
本記事ではアプリが特定のステータスとなった(承認完了などになった)場合にレコード作成やレコード更新をできるプラグインを作成したので紹介いたします。

紹介するプラグインは下記となります。
[ステータス条件付きデータ更新プラグイン](https://idepenshop.stores.jp/items/6550b79f73ce6e3dd35d0d95)

# こんな場面ありませんか？
- **ワークフローの途中や完了時に別アプリへレコード作成をしたい。
　　→別部署へエスカレーションをしたい。**
- **マスタアプリを更新する際にマ承認プロセスを導入したい。**
　　**→別アプリで承認したデータを自動でマスタへ反映したい。**

# 課題
kintoneのワークフローにて多重でステータスを持ちたいことはありませんでしょうか？
例えば、作業管理アプリにて開発チームが作業進捗を管理する隣で調達チームが商品の手配などを実施する場面を想定してください。

kintoneでは1つのステータスしか持てませんのでステータスで開発チームと調達チームの作業進捗を管理することはできません。これの解決策としてプルダウンやラジオボタンを使って管理する場合があるでしょう。
しかし、せっかくならステータスや作業者が明確なワークフローにて実現したい！
そんな時は開発チームの作業用アプリの他に調達チーム用のアプリを作成して、関連テーブルなどでレコードを紐づけながら作業したりするかと思います。
ただ、開発チームが毎回調達チーム用のレコードを作ってあげなきゃいなかったりでカスタマイズしていないと面倒なことが多いと思います。

なので、**特定のステータスになったら特定のアプリにレコード作成(更新)をする**プラグインを作りました！

# 要件
作成したプラグインは以下要件を満たすことを目的としています。
+ 特定のステータスになった時にそのレコードデータをもとにレコード作成やレコード更新ができること。
+ レコード作成やレコード更新はAPIトークンにて実施し、APIトークンは秘匿されること。

# 実装イメージ図
以下のような実装イメージを想定してプラグインを作成しています。

- 作業承認が出た段階で開発着手すると同時に調達チームへ調達用のレコードが作成される。
![構築イメージ.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850653/d986f52f-6255-826a-c703-d65feba654da.png)

# 導入手順
1. kintoneへプラグインを導入してください。
2. **更新先**アプリにてプラグイン用のAPIトークンを発行してください。 ※権限は以下を参考
![APIトークン.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850653/28448c53-1bca-7566-36eb-484c377c9e69.png)
3. プロセス管理が設定されている**更新元**アプリにプラグインを導入してください。
4. プラグイン設定画面から発行したAPIトークンを設定してください。
5. プラグイン設定画面から対象ステータスと更新設定を入力してください。
![プラグイン設定.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850653/9c3b60c9-7688-3da2-d872-2bcbda8105fa.png)
6. 保存して導入完了です。

:::note info
ステータスがプラグインで設定した条件になった時に連携先のアプリへレコード作成やレコード更新が行われます。
:::

# 最後に
今回のプラグインのような動作はアプリアクションやフィールドアクセス権限を使えば似たようなことが実装することができます。
ただ、アプリアクションでは作業者にひと手間かかってしまったり、フィールドアクセス権は設定が煩雑になり、パフォーマンスへの影響を及ぼしたります。
※アクセス権によるパフォーマンス影響は[こちらのページ](https://kintone.cybozu.co.jp/kintone-signpost/guide/performance.html)が参考になるかと思います。

マスタ更新の頻度が高く管理者への負担が多い場合などにも「[ステータス条件付きデータ更新プラグイン](https://idepenshop.stores.jp/items/6550b79f73ce6e3dd35d0d95)」が有用に働く場面がありますので、是非導入を検討してみてください。

他にもプラグイン公開していますので、興味があれば覗いてみてください。
[イデペンショップ](https://idepenshop.stores.jp/)
usbipd: error: The 'wsl' subcommand has been removed. 

# usbipd: error: The 'wsl' subcommand has been removed.
WSL2からUSBデバイスを参照できるようにするため、usbipdを利用しようとしていた時に遭遇したエラー。
エラー内にある、Microsoftの公式ページがまだ更新されていないようだったので記事にしました。

# 「usbipd wsl list」が実行できない
事象としては単純で、usbipdにサブコマンドとしてwslを指定して実行するのがこれまでの手法だったのですが、wslのサブコマンドが廃止されたそうです。
```PowerShell:PowerShell
usbipd wsl list
```
```PowerShell:error
usbipd: error: The 'wsl' subcommand has been removed. Learn about the new syntax at https://learn.microsoft.com/windows/wsl/connect-usb#attach-a-usb-device.
```
ではどうすればいいのかというと、wslを抜くだけです。
```PowerShell:PowerShell
usbipd list
```
なお、エラー内にあるURL先のMicrosoftの公式ページでは、まだ旧コマンドになっており、参考にするともちろんエラーになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262300/043f9c17-fe0f-8bbc-f9aa-3831497b9268.png)
THE BEST OF AWS 2023（主観）

2023年度、弊社サービス運用に最も貢献した機能は、この機能です！！！

～～～♪♪♪～～～（発表前の音楽）

### 「Aurora ブルーグリーンデプロイ」！！！


# 1. ビフォーアフター
### Before
- 毎週火曜日は21時30分からアップデート作業
- メンテナンス状態にするためお客さんはサービスが使えない
- 平均でも終わるのは25時くらい
- エンジニアは殆ど全員居てデバッグなどする
- 眠い

### After
- 毎週月曜日22時に少しだけ作業
- メンテナンス状態を15分間に短縮
- 火曜日21時でその週のアップデート終わり
- エンジニアは基本日中でデバッグを終える
- 21時から飲みに行ける、幸せ
- 上司（※部長 ※偉い）が最近生まれたBabyが寝る前に家に帰れる、ハッピー

# 2. ブルーグリーンデプロイのメリデメ
#### ★メリット★
本番DBで数十分～数時間かかっていた巨大テーブルへのDDLを、グリーン環境に流してから切り替えることによって**本番DBへの影響時間を切り替えにかかる数分のみに抑えられる**。

もともとこれがメンテナンス状態にしなければいけない最大の理由でした。
- DDL中はテーブルまたはレコードにロックがかかるため、サービスの動作に影響が出る可能性がある。
- サービスを使うことによって獲得されるロックの影響で、DDLがスムーズに行われない可能性がある。

ブルーグリーンデプロイではDDLはグリーン環境に流すため、本番サービス稼働中だろうと関係なく実施できます。

#### ★デメリット★
① 数分とはいえAuroraのエンドポイントに接続できない時間が発生するため、サービスがダウンする可能性がある。
→ DBに対するリトライ処理をうまく実装することで、かなり影響を軽減できている（はず）。

② 切り替えた後に残るOld環境を消し忘れる。
しっかり金がかかります（当たり前）。弊社では直近1ヵ月分はPITRでデータ復旧ができるように残しておくので、Old環境ができた際はインスタンスのサイズを落として、約1ヵ月間残したのち削除しています。
誰かが気づくか自動で削除するかしないと、思わぬところで費用がかかっていたことに後から気づく事態になるので、運用はしっかり考えないといけないです。

# まとめ
AWSさん、すごいスピードでサービスリリース・アップデート繰り返しているのでさすがだなと思いますが、弊社も負けないようにやっていきます！
最近は新しいサービスで手を動かして試すってことができてないので2024年は頑張りたい:upside_down: