OmniAICreator/Qiita-1.07M huggingface dataset:
【Flutter】Firebase Analytics を導入する

# 概要

この記事では、Firebase Analytics 10系を利用したFlutterアプリケーションへの導入方法を解説します。

Firebaseの基本設定に関しては触れませんので、予め設定を完了していることを前提とします。

# 準備
Firebase Analytics のパッケージを追加
``` bash
flutter pub add firebase_analytics
```

パッケージの詳細は以下で確認できます。
10系の書き方は少し違う部分があるので古い記事を参考にされる方は気をつけてください。
https://pub.dev/packages/firebase_analytics

# 実装

## Firebase Analytics クラスの作成

Firebase Analyticsのインスタンスをシングルトンパターンで生成するためのクラスを定義します。
このようなシングルトンパターンの利点は、アプリ全体で一つのインスタンスのみが生成され、リソースを節約できることに加え、どこから呼び出しても一貫した状態管理を実現できることです。
自分はこのようなファイルは `lib/service/` 以下に配置しています。

``` analytics.dart
import 'package:flutter/foundation.dart';
import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  AnalyticsService._();

  static final AnalyticsService instance = AnalyticsService._();

  final FirebaseAnalytics _analytics = FirebaseAnalytics.instance;

  AnalyticsService() {
  // デバッグモードでは有効化しない
    if (kDebugMode) {
      _analytics.setAnalyticsCollectionEnabled(false);
    }
  }

  // Getter for Firebase Analytics instance
  FirebaseAnalytics get analytics => _analytics;
}
```

## イベントの送信

### イベント名のみで送信
次の例では、イベント名のみをFirebase Analyticsに送信します。
``` dart
          AnalyticsService.instance.analytics.logEvent(
            name: 'sort_option_selected',
        )
```

## パラメータ付きイベントの送信
parameters 引数にマップ形式でデータを指定することで、イベントに詳細なパラメータを追加できます。
``` dart
          AnalyticsService.instance.analytics.logEvent(
            name: 'sort_option_selected',
            parameters: <String, dynamic>{
              'sort_option': thisSortBy.title,
            },
          );
```

このように `parmaeters` 引数にmap形式でデータをいれることでイベントの詳細なパラメータを設定することができます。


特定の主要なイベント（例：AddToCart、AppOpen）には、Firebase Analyticsが提供する専用の関数があります。詳細はFirebaseAnalyticsクラスのドキュメントを参照してください。

https://pub.dev/documentation/firebase_analytics/latest/firebase_analytics/FirebaseAnalytics-class.html


測定結果はタイムラグがありますが、通常は翌日にFirebaseダッシュボードで確認可能です。
AWSを用いた3つのデプロイ方法

# AWSを用いた3つのデプロイ方法

Amazon Web Services（AWS）は、ビジネスニーズに合わせた多様なデプロイメントオプションを提供しています。今回は、AWSを利用した3つの主要なデプロイメント方法、すなわちクラウドベースのデプロイ、プライベートクラウドデプロイ、ハイブリッドデプロイについて解説します。それぞれのデプロイ方法は、特定のビジネス要件やセキュリティ要件に基づいて選択され、異なる利点を提供します。

## クラウドベースのデプロイ

### AWS上での完全クラウド運用

クラウドベースのデプロイメントは、アプリケーションやサービスを完全にクラウド環境、特にAWSのクラウドインフラ上に配置する方法です。

#### 特徴

- **スケーラビリティ**: AWSのリソースを利用して、需要に応じて簡単にスケールアップまたはダウンできます。
- **コスト効率**: 利用したリソースに対してのみ支払うため、コスト効率が良いです。

#### 利点

- **迅速なデプロイ**: 物理的なインフラの準備が不要なため、スピーディーなデプロイが可能です。
- **運用の簡素化**: ハードウェアの管理やメンテナンスが不要になり、運用が容易になります。

## プライベートクラウドデプロイ

### 独自のクラウド環境の構築

プライベートクラウドデプロイメントでは、企業がAWSのテクノロジを使用して自社内、または専用のデータセンターにプライベートクラウド環境を構築します。

#### 特徴

- **専用環境**: 他の顧客とリソースを共有せず、セキュリティとコントロールを強化します。
- **カスタマイズ可能**: 特定のビジネス要件に合わせて環境をカスタマイズできます。

#### 利点

- **セキュリティとプライバシー**: データとアプリケーションがより厳格に管理され、セキュリティが強化されます。
- **コンプライアンス対応**: 法規制や業界基準に準拠しやすくなります。

## ハイブリッドデプロイ

### オンプレミスとクラウドの組み合わせ

ハイブリッドデプロイメントは、オンプレミスのインフラとAWSクラウドを組み合わせた方法です。これにより、クラウドの柔軟性とオンプレミスのコントロールを同時に享受できます。

#### 特徴

- **柔軟性**: クラウドとオンプレミスの両方の利点を活用できます。
- **拡張性**: 需要の変動に応じてリソースを柔軟に調整できます。

#### 利点

- **最適なリソース利用**: ビジネスの要件に最も適したリソースを選択できます。
- **リスク

分散**: クラウドとオンプレミスのバランスにより、リスクを分散できます。

## まとめ

AWSを利用したデプロイメントには、クラウドベース、プライベートクラウド、ハイブリッドの3つの主要な方法があります。それぞれのデプロイ方法は特定のビジネスニーズに対応しており、適切な選択によってビジネスの効率化と成長を促進できます。クラウドベースデプロイは迅速性とスケーラビリティを、プライベートクラウドデプロイはセキュリティとカスタマイズ性を、ハイブリッドデプロイは柔軟性と拡張性を提供します。組織のニーズに合った適切なデプロイメント戦略を選ぶことが、成功への鍵となります。
プライベートクラウドとオンプレミスの違い

# プライベートクラウドとオンプレミスの違い

クラウドコンピューティングが進化し続ける中で、多くの企業がプライベートクラウドやオンプレミスデプロイメントを検討しています。これらのアプローチは似ているように思えますが、実際には異なる特性を持っています。本記事では、プライベートクラウドデプロイメントとオンプレミスデプロイメントの基本的な違いと、それぞれの特徴や利点を初心者にも分かりやすく解説します。

## プライベートクラウドデプロイメントとは

### 独自のクラウド環境

プライベートクラウドは、特定の組織のために専用に構築されたクラウドインフラストラクチャです。これは一般的に、その組織のデータセンター内か、またはサードパーティプロバイダによって運営されます。

#### 特徴

- **専用の環境**: プライベートクラウドは、他の組織とリソースを共有せず、一つの組織専用に利用されます。
- **セキュリティとコントロール**: より高いレベルのセキュリティとカスタマイズが可能です。

## オンプレミスデプロイメントとは

### 自社内部のインフラ利用

オンプレミスデプロイメントでは、企業が自社の物理的施設内にハードウェアとソフトウェアを設置し、完全に自己管理します。すべてのサーバー、ストレージ、ネットワーク機器は企業の責任下にあります。

#### 特徴

- **完全なコントロール**: 企業はインフラストラクチャのすべてを自己管理します。
- **データの保持**: すべてのデータは企業の場所に物理的に保管されます。

## プライベートクラウドとオンプレミスの違い

### 管理と配置のアプローチ

- **プライベートクラウド**:
  - インフラストラクチャはクラウドベースで、仮想化技術を利用して柔軟性とスケーラビリティを提供します。
  - サードパーティのプロバイダが管理することも可能です。

- **オンプレミス**:
  - 物理的なインフラストラクチャが自社の施設内に存在し、すべての管理は社内で行われます。
  - クラウドのようなスケーラビリティや柔軟性は限定的です。

### ユースケースと適用性

- **プライベートクラウド**:
  - クラウドの利点を享受しながら、セキュリティとコントロールを確保したい企業に適しています。
  - リモートアクセスや仮想化による効率化を求める組織に理想的です。

- **オンプレミス**:
  - 物理的なアクセスやデータのローカル保持を必要とする企業に適

しています。
  - 規制が厳しい業界や高度なカスタマイズを必要とする環境に適しています。

## まとめ

プライベートクラウドとオンプレミスデプロイメントは、それぞれ異なるニーズと要件に対応する独自の特徴を持っています。プライベートクラウドはクラウドの柔軟性とスケーラビリティを提供し、オンプレミスは完全なコントロールと物理的なデータ保持を可能にします。どちらのアプローチも、組織の特定のビジネス要件やセキュリティ要件に基づいて選択されるべきです。適切なデプロイメント戦略を選択することで、効率的な運用と最適なパフォーマンスを実現できます。
【CSS】imgの代替テキストを装飾する方法

以下のように`img`にテキストに対するCSSを記述することで代替テキストを装飾できます。

色を変更するには以下のように`color`を設定します。

```html
<img class="sample" src="sample.jpg" alt="サンプル" height="100" width="100">
```

```css
.sample{
  display:block;
  border : 1px solid black;
  background-color:black;
  color:red;
}
```
paizaのスキルチェック(JavaScript)でよく使う技


paizaのスキルチェック(JavaScript)でよく使う技

最近、Paizaのスキルチェックをよく解いているのでD-C-Bランクでよく使った技をメモしていたので投稿。

# History

ストックしてもらえるようになったので最新に反映いたしました。

|date|contents|
|:---:|:---|
|2023/11/20 午後|`Array.from("abc")`を復活　出力結果を追加|
|2023/11/20 午前|コメントいただいた改善を取り込む|


# 分割

```shell
const str = "abc\ndef"
const [a, b] = str.split("\n")
```

# 先頭だけ取り出す

```shell
const [head, ...tail] = lines
```

# 連番生成

```shell
> [...Array(5)].map((_, i) => i)
[0, 1, 2, 3, 4]
```

# 文字列を配列に

case1 直接文字列を文字リストに変換(固定文字を配列で取り扱い時はこれ)

```shell
> [..."abc"] 
['a', 'b', 'c']
```

case2 変数の文字列を文字列リストに変換(`...x`は`x`が変数の時シンタックスエラーになってしまうのでこちらを使う)

```javascript
> let text = 'abc'
> ...text // エラーになる
VM895:1 Uncaught SyntaxError: Unexpected token '...'
> Array.from(text) // これならいける
['a', 'b', 'c']
```

# 配列の末尾を取得

```shell
array.at(-1)
```

# 配列の先頭を取得

```shell
array[0]

// 先頭からN番目まで取りたい場合
array.slice(0,N)
```

# 配列を分割

```shell
array.slice(n, m)

const x = [1, 2, 3, 4, 5, 6]
x.slice(0, 3)
> [1, 2, 3]
x.slice(4, 10)
> [5, 6]
x.slice(6)
> []
```

# 数値を2進数に変換

```shell
> const x = 256
> x.toString(2)
'100000000'
```

# 配列の途中を削除(n番目から1文字を削除)

```shell
> array.splice(n, 1)
```

# 重複を削除

```shell
[...new Set(array)];
```

随時追記していく

# Contribues

ご指摘、編集リクエストをありがとうございます！大感謝です🙏

- @oswe99489
- @UMA9626
Microsoft Graph APIで特定のAppRoleが取得できない

## はじめに
Microsoft Graph APIでアプリロールを取得していたのですが、特定のアプリロールが取得できず困ったので、解決策を簡単にまとめておきます。
使用言語はJavaScriptです。（ほかの言語でも同様かと思います）

また本記事ではアプリロールの説明や登録方法などは記載しません。

## 問題
ログイン中のユーザーのアプリロールの一覧を取得したかったので以下のように実装。
使用していたAPIは以下で、fetchAPIを使用して取得。

```JavaScript
const response = await fetch("https://graph.microsoft.com/v1.0/me/appRoleAssignments");
```

アプリロールは返ってきているのですが、特定のアプリロールが入っていません。
原因が分からなかったのでSDKをインストールして試してみます。

### Microsoft Graph SDKの導入
[Microsoft Graph SDK](https://learn.microsoft.com/ja-jp/graph/sdks/sdk-installation)を使用して確認してみます。

```JavaScript
const client = Client.init({
  authProvider: (done) => done(null, <access_token>)
});

let appRoleAssignments = await client.api('/me/appRoleAssignments')
	.header('ConsistencyLevel','eventual')
	.get();
```

ですが、結果は変わらず。
問題のあったユーザーはどれもアプリロールの数が多かったので、試しにフィルターをかけてみることに。

### フィルターをかける
リソースIDでフィルターをかけられるようなので、そちらを試してみます。
```JavaScript
const client = Client.init({
  authProvider: (done) => done(null, <access_token>)
});

let appRoleAssignments = await client.api('/me/appRoleAssignments')
	.header('ConsistencyLevel','eventual')
    .filter('resourceId eq <resourcedId>')
	.get();
```

アプリケーションにアプリロールを定義している場合は、アプリのオブジェクトIDがresourcedIdになります。

フィルターをかけて試してみたところ、取得したかったアプリロールが取得できました。なぜ？

## 結論
フィルターをかけることで取得できるようになりました。
詳しい原因はわかりませんが、問題が発生していたユーザーはアプリロールの数が多かった（フィルター前のレスポンスを数えてみたら96個もありました）ので、数が多かったのが問題だったのかなと思います。
get_poacar_file_folder_abs_path_list.pyの実行ログ

## スクリプトの入出力について

* get_poacar_file_folder_abs_path_list.py<sup>[1]</sup>

    * 入力：COD[1]からダウンロードしたcifファイルを変換したPOSCARファイル約30万件が入ったディレクトリ(：308325件)

    * 出力：poscar_abs_path_list.npy, poscar_folder_abs_path_list.npy

[1] https://github.com/k-morii-toridai/scripts_get_poscar_abs_path_list.git


## 実行の詳細ログ
```terminal
pwd
```
/mnt/ssd_elecom_black_c2c/scripts_get_poscar_abs_path_list


```terminal
ls -CF
```
get_poacar_file_folder_abs_path_list.ipynb*  get_poacar_file_folder_abs_path_list.py*  old/



```terminal
time python3 get_poacar_file_folder_abs_path_list.py
```
len(poscar_folder_path_list): 507142
100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████| 507142/507142 [13:58<00:00, 604.50it/s]
len(poscar_file_path_list): 308325
len(poscar_folder_path_list): 308325

real    15m19.689s
user    9m15.050s
sys     34m50.252s


```terminal
ls -CF
```
get_poacar_file_folder_abs_path_list.ipynb*  get_poacar_file_folder_abs_path_list.py*  old/  poscar_abs_path_list.npy*  poscar_folder_abs_path_list.npy*
Amazon RDS Proxy で結構請求された話し

# 背景
先日健康診断の再検査を受けたら再検査となってしまった  [@\_\_\_nix___](https://twitter.com/___nix___)  です。

AWSとコスト爆発にまつわる話は少なくありません。
コスト順だと次のような順番になるでしょうか。

5位 ... AWS Private CA（$400/月）
4位 ... Amazon Kendra （$810/月）
3位 ... NatGateway（$1,000/月）
2位 ... Amazon RDS Proxy（$1,190/月）
1位 ... [AWS CloudTrail](https://qiita.com/___nix___/items/c41796997dbcc553c799) （$62,000/4日）

過去にも先にも CloudTrail（厳密には CloudTrail-Lake）を超えるような話は見たこともありませんし聞いたこともありません。もしこれを超える話をお持ちの方は是非教えてください。

# 本題
今回ご紹介するのは 2位 に付けた Amazone RDS Proxy 、もう少し詳しく言うと、「RDS Proxy + Aurora Serverless v2」のお話です。

「なーんだ、ピン留めの話？」そう思われる方も少ない無いでしょう。

https://qiita.com/2kai/items/c58153294999bccbb6ec

これはいわゆる「ピン留め」という現象によりコネクションが増えていく状況です。この状況によってACUの使用率が下がらずに費用が高騰するという事故案件です。

では Amazon RDS Proxy の料金体系を見てみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22939/0177263f-4e58-24c3-f560-2543e69bab67.png)

確かに1時間当たりの ACU の利用量がそのまま料金に直結することが確認できました。

# 請求書
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22939/64887214-9839-0b31-cf51-febdd9101361.png)

$1,190.40 ！？
円安の今の状態だと 179,750円 ...

え、え、もしかして「ピン留め」が発生したのか？

# 調査
「ピン留め」かどうかは `DatabaseConnections` や `DatabaseConnectionsCurrentlySessionPinned` の数を見れば分かりますので確認したところ、それらの値は全く増えておらず負荷もほとんど掛かっていないことが分かりました。

「ピン留め」では無い...。

では何が原因なのでしょうか。
もう一度 RDS Proxy に関連するリソースを調査してみました。

環境は4つ、それぞれに RDS Proxy が存在しており、エンドポイントが 2つずつ。

|環境|RDS Proxy|Endpoint|
|:---:|:---:|:---:|
|環境A | 1 | 2 |
|環境B | 1 | 2 |
|環境C | 1 | 2 |
|環境D | 1 | 2 |

結構使ってることが分かりましたが、ザックリ計算してみましょう。
1ACU1時間当たりの単価は確か $0.025 でしたね。

```
24(h) x 31(Day) x 4(Proxy) x 2(Endpoint) x 0.025 = $148.8（時価22,469円程）
```

全然そこまでいかないです。

# 原因特定
分かる人には既に分かったかもしれません。
料金体系に罠がありました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22939/70d35289-867c-dfc6-3114-1a758d7b7a77.png)

はい、**最低料金 8 ACU** と書いてあります。
つまり 1 ACU しか使ってなくても 8 ACU 使っているものとして計算しなさいという意味なので算出し直してみます。

```
24(h) x 31(Day) x 4(Proxy) x 2(Endpoint) x 0.025 x 8(ACU) = $1,190（時価179,750円程）
```

Σ(･ω･ﾉ)ﾉ！
た、高い...

# 編集後記
ほとんど利用しておらず、単に置いてあるだけでこれだけ課金されるというのにはビックリでした。こんな事例もあるということを事前に知っておいて頂けるだけでも良いかと思いますので皆さんもお気を付けください。


ただ、AWS公式サイトの説明でどうしても気になることがあります。

https://aws.amazon.com/jp/rds/proxy/pricing/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22939/68e3f12f-1d12-e268-915f-a7f785736e30.png)

**例えば、1時間に平均10ACUを消費する** これは例としては間違っていないのですが、最低料金が8ACUに設定されるとすればそこに触れるべきで、例として示すのであれば **例えば、1時間に平均4ACUを消費する** のようなものが必要だと思います。

4ACU しか使っていないけど、課金は 8ACU だということに気が付けるハズですので...


:::note info
親愛なるAWSさん、料金ページのサンプルには8ACU未満の事例も入れた方が良いかと存じます(; ･`д･´)
:::
[WordPress] Cocoon でトップバーのカラーを変更する方法 🌈

最近スマホ版ブラウザでよく見かける、トップバー（アドレスバー）の色がカスタムカラーになってるやつ、自分もやってみたかったから試してみた。（というかデフォルトで青色になっててダサかったから変えたんだけどね）

イメージ画像👇

https://glazestyle.com/blog/meta-theme-color/

# 1. Cocoon設定画面へアクセス 👨‍💻

WorpPress ダッシュボード > Cocoon 設定 > Cocoon 設定　に行く。

![Screenshot 2023-11-17 at 22.15.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1900756/99bb4efd-070e-7d85-c532-1e924252d65f.png)

# 2. ヘッド用コードに追加 👨‍💻

アクセス解析・認証 > ヘッド用コードに行く。

![Screenshot 2023-11-17 at 22.18.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1900756/c38e5868-47b0-1c8d-9048-e25a14fc6807.png)

下記コードを打つ！

```
<!-- theme-color -->
<meta name="theme-color" media="(prefers-color-scheme: light)" content="#FFFFFF">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#FFFFFF">
```

いろんな色試してみたけど、どれもうざったいデザインになっちゃう。結局、白にすることにした。

参考👇

https://jito-site.com/meta-theme-color/
【Google Cloud Next Tokyo ’23レポート】 Google Cloud と歩むスタートアップの軌跡 - Bitkey と Luup の成長物語 -

# 概要
現在、Google for Startups などのスタートアップ支援プログラムが様々な企業で活用されています。本セッションでは、創業初期から Google Cloud をご活用している Bitkey と Luup が、プログラム活用方法やインフラの変遷など、スタートアップの各成長ステージでの Google Cloud 活用術について説明します。

株式会社ビットキー Developers Experience Div. VP of Engineering
佐藤 正大 氏

株式会社Luup Software Development部 Co-founder, CTO
岡田 直道 氏

Google Cloud カスタマー エンジニア、スタートアップ リード
岩成 祐樹

# 所感
bitkeyとLUUP、２社のスタートアップがGCPを使ってどのように今日に至ったか、というお話し。

両社ともに、創業期の思いのお話からあり、とても興味深かった。
全ての鍵を一つで、という考え方も面白く、確かにいい、と納得してしまったし、
気軽に乗っていける電動モビリティで街じゅうを駅前化する、というのもワクワクした。

そんなスタートアップ２社が、GCPを選んだ理由と、どのようなアーキテクチャをもってここに至ったか。
非常に参考になるお話しでした。

# 内容メモ
## bitkey
- 従業員数：230名
- 開発者：80名
- 「鍵」はなんで別々に存在するのか？
    - 顔認証なら全て一つ
- 人々の生活全てを対象に
- 暮らしと仕事、そしてそれ以外（イベントなど）

## LUUP
- 従業員数：80名
- 開発者：10名
- 街じゅうを駅前化するインフラを作る
- ハードウェア
    - 車両
- 自治体など土地ごとの連携
- モバイルアプリ
- Data
- 4700以上のポート（車両置き場）

## 技術から見たGCP活用
### bitkey
- AWS IoTも活用
![PXL_20231116_081531955.MP.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1458753/8725113c-780b-579f-82de-9b997f64d5d4.jpeg)
### LUUP
- 立ち上げから今に至るまで同じ構成
- AWS IoTも活用
![PXL_20231116_081737639.MP.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1458753/741e0edc-ab2a-1e75-2f55-8bd4c588d4f4.jpeg)

### GCPの決め手
- 試乗会では鍵さえ開けば良かった(LUUP)
    - FireBaseの選択が頭にあった
    - そこから自然にインフラもGCPになっていった
- 同じく、デモンストレーションの段階で、FireBaseの選択があった（Bitkey）
    - クイックにモバイルアプリが開発できる
- GCPのサービスの新規性と、使いやすさ（Bitkey）

### インフラをアップデートするタイミングと判断基準
- 予算策定のタイミングにコスト予測から（LUUP）
- リソース使用率の増加も見ている（LUUP）
- FireBaseからAlloyDBへ移行中（Bitkey）
    - 事業が進むにつれてドメイン理解が進み、変化していく
    - CloudFunctionsが肥大化
    - データをRDBに収めたくなるケースが出てきた
![PXL_20231116_082658866.MP.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1458753/b0f9d1fa-96db-5e14-0e5f-4c5c9a8a45a8.jpeg)

### 意思決定のプロセス
- スタートアップにおいては、新しい事をやっているゆえに課題が山ほどある。（Bitkey）
    - 課題の粒度を認識し、カテゴライズする事
- 課題の粒度から、テックリードや経営層がすることが多い（LUUP）
-
##　組織から見たGCPの活用
 ### スケールに向けた観点
- LUUP
    - 車両とアプリの可溶性
    - 信頼性（SLO）
- bitkey
    - オブザーバビリティ
        - リスクの事前察知
        - 早期解決
    - 分散トレーシング
        - 物理からクラウドインフラ
    - 学習継続力の高いチームビルディング
### 技術以外のGCP活用
- スタートアップ支援
    - 技術支援
    - 資格支援
    - カルチャーセッション
    - コミニュティ、ミートアップ
- googleイズムをしれる、感じれるのがいい
# 関連記事
- [【Google Cloud Next Tokyo ’23レポート】 by yukiMiyoshi_fcafe](https://qiita.com/yukiMiyoshi_fcafe/items/18ad65426e1a71311419)
- [【Google Cloud Next Tokyo ’23レポート】 by sho_fcafe](https://qiita.com/sho_fcafe/items/a97ee90d6a05f68e1c01)
【Google Cloud Next Tokyo ’23レポート】運用管理者目線でみたGoogle Workspaceのリアル

# 概要
 本セッションは、Google Workspace ユーザー企業 3 社が登壇し、Google Workspace ならではの活用方法、今後の展望などをお話しします。

エイチ・ツー・オー リテイリング株式会社 IT・デジタル推進室 プロジェクトマネージャー
吉田 寛基 氏

敷島製パン株式会社 SPS推進部 課長
吉安 壮真 氏

株式会社ロッテ ICT戦略部 スペシャリスト
西川 季宏 氏

Google Cloud Google Workspace 事業本部 セールス スペシャリスト
隅野 友加里

# 所感
お話しいただいた内容がリアリティに溢れていて、悩みどころや進め方など、身近に感じれるお話しでした。

オフィス回帰の流れはありつつも、
オフィスに縛られない働き方と、そこから生まれる変化を積極的におこしている印象がありました。

若い世代は何も言わずともどんどん使っていく、というのも、
デジタルネイティブな時代に適応していく必要性を感じました。

googleからのアドバイス、とあるように、利用促進に付き添ってくれるのも面白いですね。

# 内容メモ
## 導入したメリット
- 元々オンプレでの運用で、特に容量上の問題から解放された
- オフィスに行けない状況が発生した中、オフィスでしか出来ない業務の改善
    - オフィスのPCにしかないデータ

## ユーザー部門における利活用促進への取り組み
- コミニュケーション系のツールは割と何もしなくても使ってくれた
- スプレッドシートなどドキュメント系のツールは、業務フローに関わるため、進めづらい
- 若い世代はなにもせずともどんどん使っていく傾向がある
- スマホも1人一台配布をし、どこでも働ける環境を作る目的(エイチツーオー)
- googleからのアドバイスで、社内周知、人事部門への理解促進を進める。

## セキュリティに関しての事例、メリット
- googleグループを使っての、グループ単位での権限管理
    - グループが増えすぎて、グループの管理が課題
- googleアカウントでのサービス利用を進めている
    - 誰がどのサービスを使っているかがわかる
- 人事マスタとGoogleαアカウントを結びつけて管理している
    - 異動の際にも楽

## 現在の課題感
- AppSheetの取り組み
    - ガバナンス面が標準ライセンスでは賄えない
- ファイルサーバーの移行
-　Driveの権限管理の考え方に合う合わないがある
-　雇用形態によっての、アカウントの提供方法
    -　パート、アルバイトさんへの提供が難しい
-　社外への共有の際に、Googleアカウントが必要になってしまう点
    -　メールへのファイル添付が残ってしまっている
    -　この部分を少し柔軟に出来たら
-　社内で使っているちchromebookのchromeOSのアップデートに課題感がある

## 今後に期待する事
- DuetAI早くほしい
    - meetの要約
    - 文書の生成
    - スライド生成
- Meetの文字起こし日本語対応に期待
    - DuetAIも絡めて、議事録の自動生成に期待
- 外部共有
    - 柔軟に外部を取り込める事で、使用するツールをgoogleに統一できる

# 関連記事
- [【Google Cloud Next Tokyo ’23レポート】 by yukiMiyoshi_fcafe](https://qiita.com/yukiMiyoshi_fcafe/items/18ad65426e1a71311419)
- [【Google Cloud Next Tokyo ’23レポート】 by sho_fcafe](https://qiita.com/sho_fcafe/items/a97ee90d6a05f68e1c01)
【Google Cloud Next Tokyo ’23レポート】日本の空を支えるGoogle Workspace

# 概要
Google Workspace を 10 年利用されている ANAホールディングス様、昨年 Google Workspace の利用を開始した日本航空様が登壇し、航空会社ならではの活用方法やユーザー部門からの声、今後の展開などをお話します。


全日本空輸株式会社 デジタル変革室 サービスプラットフォーム部 経営サポートチーム リーダー
橋本 至 氏

日本航空株式会社 IT企画本部 IT運営企画部 海外IT・コミュニケーション基盤グループ アシスタントマネジャー
遠山 和也 氏

Google Cloud Google Workspace 事業本部 ソリューション営業部 部長
武市 憲司

# 所感
ANA、JAN、これぐらいの規模感になると、
Google Workspaceの導入を進めるのも年単位になるし、かなりの労力が必要。
特にコミニュケーションツールの入れ替えは現場の混乱を招きやすく、慎重にしないといけない。

Gmail、Driveなどから徐々に進めていき、
Awareness活動、という利用促進を促すための活動を部署やグループ企業横断で組織し、進めていったという取り組みは、非常に参考になった。


# 内容メモ
- ANA
    - 2013年に導入
- JAL
    - 2022年に導入
## どのように使用しているか？
- ANA
    - 約15業種、５０社
    - 売上約1.97兆円、従業員数約４万人
    - まずはGmail、Driveから。
    - カレンダー、ハングアウトと、数年をかけて徐々に進めていった
    - 導入以前は、社内イントラのみ
    - 2012/4からiPadの配布開始
    - 2014以降、スタッフにiPhoneの貸与
        - 内戦の置き換え
    - 2018
        - iphone8になった事で、電話会議の参加が可能に
    - 20年4月から23年10月
        - meet:2000回から1万回に/d
        - chat:57スペースから3.5マン/d
        - Drive:２４１％増
- JAL
    - 199路線、１０００便/d、3466万人/y、64カ国、３７６空港
    - 従業員：36,039人
    - 目的
        - クラウドをフルに活用した働き方改革
            - 社員がいつでもどこでも同じように働ける
        - コラボレーション機能を最大限に活かした生産性
            - チーム
    - Driveとchatの利用を開始、Gmail、カレンダーへと進めた
    - Awareness活動
        - 活用促進
        - チーム、グループ企業から少数でチームを作る、横断的アイディアっワークによる課題を見えるか
        - Googleの協力
    - アカウント配布から開始まで１年かけてハードルを少しずつ超えていく
        - ユーザーに段階的にわかってもらう
    - レベル分けした教育資料や動画
    -chat利用の推進

## 座談会
### workspaceに切り替えて一番良かった事は？　ANA→JAL
- 検索性
    - メール、ファイルなど検索して探せるようになった
- 新入社員など、馴染みのあるサービス
    - 今や小中高生も使っている
### ユーザーのコラボレーションや働き方について JAL→ANA
- コラボレーション機能の活用
    - リアルタイム共同編集の活用
        - 会議メモの同時編集
    - トラブル発生時の共有

### 現場のDX推進について
- ANA
    - 整備現場における利用
        - 機材管理、部品管理、発注管理
        - 元々は紙での管理

### チームワークはいつでも伝え合える場から生まれる
-  長谷部誠との対談記事
-  初対面の機長と副基調
    -  事前の情報共有


## 今後の展開
- JAL
    - いかにユーザーに活用していくか
    - chromebookの活用
- ANA
    - chrombook羨ましい・・・・
    - 最新機能への追随
        - 機能を使い尽くしたい
    - DUetAIに期待

## GCPへの要望
- グローバルなサービスではあるものの、日本に向けた機能、ローカライズに期待（ANA）
- ANAさんに同意（JAL）
- workspaceを利用する企業を増やしてほしい（JAL）
    - 他者とのコラボがしやすくなるので

# 関連記事
- [【Google Cloud Next Tokyo ’23レポート】 by yukiMiyoshi_fcafe](https://qiita.com/yukiMiyoshi_fcafe/items/18ad65426e1a71311419)
- [【Google Cloud Next Tokyo ’23レポート】 by sho_fcafe](https://qiita.com/sho_fcafe/items/a97ee90d6a05f68e1c01)
私の1回目AI漫画！

### 私の1回目のAI漫画
ChatGPTで4コマ漫画を作ってみました。

最初は英語でリクエストを出しました。

私:

I want to create a 4 pieces manga.

ChatGPT:

Creating a four-piece manga is an exciting project! Since I can generate one image at a time, we can start with the first panel. Please describe the scene, characters, and any specific details you want in this first panel. Once it's done, we can proceed with the subsequent panels one by one.

私:

In the first scene,  a programmer is debugging a program. The office is very small and jumbled up. The light is not very bright. The hair is straggly.

ChatGPT:
![sQrgXGuDkuTuynEeTLblS19Zi0y2/mQidsAEoIykaOwvi.jpg](https://firebasestorage.googleapis.com:443/v0/b/type-c1c71.appspot.com/o/sQrgXGuDkuTuynEeTLblS19Zi0y2%2FmQidsAEoIykaOwvi.jpg?alt=media&token=1959a1fe-9b1d-4259-9647-21d802ce44f2)

Here is the first panel of your manga, showing a programmer in a small, cluttered office, intently debugging a program. How does this look for your story? If you're ready, we can proceed with the second panel. Just describe the scene you have in mind.


英語は得意ではないため、この後、中国語で要求を出しました。

私:

他一直在努力调试程序。突然有了恍然大悟的感觉。(ずっとプログラムをデバッグして、ひらめきがあったようです)

ChatGPT:
![sQrgXGuDkuTuynEeTLblS19Zi0y2/aENLUtoWC01stm35.jpg](https://firebasestorage.googleapis.com:443/v0/b/type-c1c71.appspot.com/o/sQrgXGuDkuTuynEeTLblS19Zi0y2%2FaENLUtoWC01stm35.jpg?alt=media&token=0bb9aa43-1ba8-4ff1-aca2-8c9caa2f5a38)

Here's the second panel, capturing the moment of realization for the programmer. It conveys his sudden insight in a dramatic manga style. If this fits your vision, let's move on to the third panel. Please describe the next scene for me.

ちょっとイメージが違うので、修正してもらいます。

私:

不要这个夸张。要有一种意会而且狡黠的感觉。(ちょっと誇張すぎます。小賢いの感じにしたいです)

ChatGPT:

![sQrgXGuDkuTuynEeTLblS19Zi0y2/K6LUi9jHC8eebc08.jpg](https://firebasestorage.googleapis.com:443/v0/b/type-c1c71.appspot.com/o/sQrgXGuDkuTuynEeTLblS19Zi0y2%2FK6LUi9jHC8eebc08.jpg?alt=media&token=3a9bb679-ab74-45b4-946f-0030f442d686)

Here's the revised second panel, with a more subtle expression of realization for the programmer. He now has a knowing, sly smile, reflecting a clever insight. If this aligns better with your vision, we can proceed to the third panel. Please describe the next scene for me.

以下は早送りです。

![sQrgXGuDkuTuynEeTLblS19Zi0y2/J2ZFisui2Z38P1Ol.jpg](https://firebasestorage.googleapis.com:443/v0/b/type-c1c71.appspot.com/o/sQrgXGuDkuTuynEeTLblS19Zi0y2%2FJ2ZFisui2Z38P1Ol.jpg?alt=media&token=f4706302-4150-4423-8061-a0260ed43e64)

![sQrgXGuDkuTuynEeTLblS19Zi0y2/ufJeXdqLIlvYX4D5.jpg](https://firebasestorage.googleapis.com:443/v0/b/type-c1c71.appspot.com/o/sQrgXGuDkuTuynEeTLblS19Zi0y2%2FufJeXdqLIlvYX4D5.jpg?alt=media&token=dcd2615c-ea55-45e0-81fb-107feaa8a2a9)

4コマ目もプログラマーの姿勢をもっと誇張するようにしてもらいました。

4コマ並べてとお願いしました、残念であるため、自分で1コマずつアルバムに保存して、Wechatのもーメンツに公開しました。

私は描きが下手ですが、 お陰様で、1回目のAI漫画を公開します！

![sQrgXGuDkuTuynEeTLblS19Zi0y2/OfKnxFQUbsh8NDdj.jpg](https://firebasestorage.googleapis.com:443/v0/b/type-c1c71.appspot.com/o/sQrgXGuDkuTuynEeTLblS19Zi0y2%2FOfKnxFQUbsh8NDdj.jpg?alt=media&token=26060526-3b8b-4cc8-b571-27403145fe23)

夢の漫画を作成しました！
🎉
謎のICカードリーダーがM1Mac+Sonoma(14.0)で使えた話

謎のICカードリーダーをmacosで動作するか検証しました。似たようなものがAmazonや楽天で色々あるのでブランド不明です。説明には、「Mac OS 10.11.1」以上に対応とか書いてあります。El Capitan(2015年)以降ですか。本当かいな？

## 環境
- MacBook Air M1
- macos Sonoma(14.0) 
- [一台で多機能なSDカードも読める謎のICカードリーダー](https://amzn.to/3SG91QQ)
↓ こんなやつ ¥1,500
![スクリーンショット 2023-11-17 21.36.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14768/9216d6ab-1d10-bc39-00dd-ad7a721d18cb.png)

## 結論

M1Mac+Sonoma(14.0)でドライバーレスで使えた。MicroSD（TF）も挿したらマウントされた。大成功。

![IMG_0564.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14768/f7525d92-4546-2322-d50a-516c0b0c08c6.png)

## インストールなど

USB-CtoAアダプタを利用して接続しただけで特にインストール必要なし。[JPKIの「利用者クライアントソフト」](https://www.jpki.go.jp/download/mac.html)をインストールして動作確認。マイナカードの署名読み込み/検証も成功

![スクリーンショット 2023-11-17 20.52.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14768/356bf3ec-a48b-b3b5-d343-c3d9dbddb8f4.png)

差し込むとLEDの色が赤→緑に変わってオシャレ。ICカード認証の時も、メモリーカードのR/Wの時もピカピカ光る。

## デバイス情報

- **Generic USB2.0-CRW**
    - カードリーダーは Multi-Cardとしてして出てくる。メモリーカードを入れないと何も出ない。

![スクリーンショット 2023-11-17 21.00.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14768/e41a911f-c08a-3596-5b7e-a200e9b7a2f6.png)

どうやら[Realtek RTS5169](https://www.realtek.com/en/products/computer-peripheral-ics/item/rts5169)のようですね。

![スクリーンショット 2023-11-17 22.38.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14768/9b80e6e6-8bb2-44bc-e2df-9688b271eefa.png)

1チップに機能全部入り。端子にコネクターほぼ直結してるような感じですね。同じような製品でカードリーダー機能の無いバージョンもありますが、多分基盤にコネクターついてないダケな気がします。メモリースティックも足出てるんですね。へー。

https://pdf1.alldatasheet.com/datasheet-pdf/view/1132031/REALTEK/RTS5169.html

## マニュアルには

ちなみに同梱してあった日本語のマニュアルには「MacOS10.15以降（Apple製のCPUを搭載したmacでは使用できません）」と書いてありました→動いたけど。

![IMG_0574.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14768/9d51c3c5-e770-17da-49ad-91cfc7e4c757.png)

## ぶつぶつ

最近はマイナンバーカードもスマホ経由で使えるようになっていたので、全く気にしていなかったのですが、ICカードを使う要件があったのでジャンク箱の奥から出してきたらmacosではPasoriはことごとく非対応になっていました。まぁ、現行のS300を買えば解決なのですが、どうも不信感が...。

ということで、なんとなくIO-DATAのにしようかと思ったのですが、結局は[AB CIRCLE CIR115A](https://www.abcircle.co.jp/jp/product/13/CIR115A/%E6%8E%A5%E8%A7%A6%E5%BC%8Fic%E3%82%AB%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%80%E3%83%A9%E3%82%A4%E3%82%BF/)がベースっぽいのでちゃんとサポートされてるっぽい...ということで、チャレンジしてみたのでした。

ある程度標準化されていると思うのですが、ドライバーも入れずに認識されたのでよかったです（チップそのままだから？）

他のでもちゃんと動く保証はありませんが、動作情報のあまりないmacosで普通に動くのがわかったので残しておきます。
鉛筆と不確定性原理

:warning:記事の内容は私個人の見解であり，所属する学科組織またはサークルを代表するものではありません．

# はじめに
AdventCalendar ２日目です！
アドカレ[^1]参加者の都合上，僕はあと３回書くことになっていて，第１回は物理の内容になります．

さて，皆さんは12月をいかがお過ごしでしょうか．だんだんと寒くなり，体調を崩してはいませんか？
ちなみに僕は理学部化学科の生徒として**毎日一限週４実験**の８文字に忙殺されています．
ですから，もしこれからのアドカレの投稿が遅れても許してください．


# 鉛筆を立てる
さて，皆さんは鉛筆やボールペンを机に立たせて遊んだことはありますか？
ここでの「立たせる」とは尖っている方を下にして置き，手を放すことを指すものとします（下図参照）．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288338/e4a83d3f-8d4e-9a0f-47f0-3cf4303e45e9.png)

もし手元に鉛筆がある人は，何秒くらい立たせることができるか測ってみてください．
ちなみに僕がやってみたときは0.3 秒くらいでした．やってみたら分かるんですが，「立っている状態」の定義次第で測定時間が大きく変わりそうです．

# 不確定性原理って２種類あるねん[^2]
ここで大きく話は変わりますが，皆さんは「不確定性原理」というものは聞いたことがありますか？
おそらくこの記事を読んでいる人は（ぼんやりとでもよいので）頭に浮かんでいるはずです．あの量子力学で出てくる不確定性原理です．
下の式が有名だと思います．
```math
\Delta x \ \Delta p \ \geq \ \frac{\hbar }{2}
```
見出しにもある通り，実は不確定性原理には２種類あります．
以下，少し難しい話になるため，量子力学にあまり馴染みがない方は飛ばして頂いて構いません．

１つ目のタイプは２つの観測量の標準偏差に関するものです．
一般の観測量に対しては以下のKennard-Robertsonの不等式というものが成り立つことが知られています．
```math
\sigma (A) \sigma (B) \geq \frac{1}{2} |\braket{[A, B]} |
```
ここでAとBは観測量で，σは標準偏差です．
この式は２つの（非可換な）観測量の，測定による「ばらつき」に対して制約を与えています．

これに対し，２つ目のタイプは位置と運動量の測定にトレードオフが存在することを主張します．
ここでガンマ線顕微鏡の思考実験というものを紹介します．
詳細は他の文献に譲ります[^3]が，光を粒子に当て，それにより粒子の位置を特定するという実験です．この実験では粒子の位置と運動量の２つを測定します．

この実験において，粒子の位置を精度よく当てるにはどうすればよいか考えてみます．
最も単純な方法は光の波長を短くしていく方法があります．しかし，波長を短くすると光の運動量は大きくなってしまいます[^4]．
光は粒子に当たりますので，その分だけ粒子の運動量も大きくなります．すると，粒子の運動量の観測結果への誤差も大きくなってしまいます．
これを数式によって表すと，下のようになります．
```math
\varepsilon (A) \eta (B) \ \geq \ \frac{\hbar }{2}
```
ここでεはAの測定誤差，ηはBの擾乱です．

サラーっと説明しましたが，このように不確定性原理には２つのタイプがあります．
なんだか同じように見えるかもしれません．~~僕も書きながら同じように見えてきました．あれ．~~

# 鉛筆と不確定性原理
少し話題がそれましたが，鉛筆の話に戻ります．
先ほど鉛筆がどのくらいの時間立つのか，みたいな話をしました．
今回はこの**立ち続ける時間**を不確定性原理によって見積もることを試みます．

しかし，真面目に考えると大変ですので，いくつかの仮定を設けます．
1. 立ち続ける（＝つり合いが保てる）か否かには不確定性原理のみが制限となる
2. 机は十分かたいとする
3. 鉛筆の重心に全質量が集中しているものとする
4. 真上から１°ずれたところを倒れた（＝つり合いが保てなくなった）とする

これらの仮定の下，計算を実行すると，真上から鉛筆がずれた角度θには以下の「ばらつき」があることが分かります（計算過程は省略）．
```math
\sqrt{\braket{(\Delta \theta )^2}_t } = \sqrt{\frac{\hbar }{2M\sqrt{gl^3}} } \exp (\sqrt{\frac{g}{l}}t )
```
ここで $\hbar $はディラック定数，$M$は全質量，$g$は重力加速度，$l$は鉛筆の先から重心までの距離です．
この角度が１°になったとき，鉛筆は倒れたことになります．そのときの時間は以下により与えられるはずです．
```math
\exp (\sqrt{\frac{g}{l}}t ) = \frac{\pi }{180} \sqrt{\frac{2M\sqrt{gl^3}}{\hbar }}
```
この式に，僕が持っている鉛筆の物理量を代入しましょう．
今回は以下の値になります．

$$l = 20 \ cm$$ $$M = 50 \ g$$ $$g = 1000 \ cm/s^2$$ $$\hbar = 10^{-27} \ erg \cdot s$$
これらを代入して計算すると，$t = 5s$となります．つまり鉛筆が立ち続ける時間は５秒だと見積もることができました．

# おしまいに
大部分の計算は省略してしまいましたが，そんなに難しいことはしていないので，まあいいでしょう（！？）．
もし時間があれば，今回の計算をQiita記事またはX（旧Twitter）に投稿するかもしれません．~~ぜひフォローしましょう！！！[^5]~~
残り23日のアドカレもお楽しみに！

[^1]: AdventCalendarの略
[^2]: [参考文献](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%9F%E3%82%AB)
[^3]: [ネットにあるものであれば，これなど](http://www.phys.u-ryukyu.ac.jp/~maeno/qm2006/qm8.html)
[^4]: p = h/λ
[^5]: [僕のTwitter](https://twitter.com/kagakuc6h6)
仮想デスクトップでRPAを実行した場合の挙動を検証


一つのパソコンでRPAを実行しながら、別の作業もできないかと依頼があったため
仮想デスクトップでRPAを実行した場合どのような挙動をするか検証する

今回検証する環境は、
OSはWindows10
RPAは PowerAutomateforDesktopです

WindowsのOSによって仮想デスクトップの作成方法は異なるためこの記事では省略する

まず、作成した仮想デスクトップ上では、元のデスクトップと同じ配置がされている
同じフォルダを開くことができる

仮想デスクトップでExcelを開こうとした場合
すでに元のデスクドップでExcelを開いていると、元のデスクトップに遷移してExcelが開く
これはExcelの仕様だそうで、Excel以外にもこのような挙動をするアプリがあるそうです

別々のExcelを開く方法もありますが、この記事では省略する

逆に仮想デスクトップでExcelを開いている場合に、元のデスクトップでExcelを開こうとしても仮想デスクトップに遷移する


本題である仮想デスクトップでのRPAの実行について検証する
まずRPAの実行は可能である

試してみたところ、以下の挙動が発生した。

Webページのリンクをクリックの「物理クリックを送信」の処理時には、仮想デスクトップ(RPAを実行しているデスクトップ)に遷移した
「物理クリックを送信」を解除したら画面遷移はなくなりました

Excelの「セルをコピー」の処理は、元デスクトップ(RPAを実行していないデスクトップ)のExcelで作業しているとそのExcelの値がコピーされた
「セルをコピー」ではなく「Excelワークシートから読み取る」の場合、値がコピーされることはなかった
（これは仮想デスクトップでなくても発生する挙動でした）

RPAで「Excelを起動」する際に、元のデスクトップ(RPAを実行していない画面)を開いていた場合、その画面(RPAを実行していない画面)上にExcelが立ち上がる
ただしExcelの起動でExcelインスタンスを開いたとしても
元のデスクトップでExcelを開いていても画面遷移せず、逆にRPA実行中に元のデスクトップでExcelを開いても画面遷移しなかった

他にも実行していない画面に影響を与える処理があるかもしれない

今回の検証の結果、RPAの処理によっては別のデスクトップに影響を与える挙動があるとわかった
SVGからPathマークアップ構文への変換

# Streamlitアプリ: SVG to Path

Check out this awesome Streamlit app I built that converts SVG to Path markup syntax! You can try it out [here](https://svg-to-path.streamlit.app/). #streamlit #python 

https://svg-to-path.streamlit.app/

## はじめに

このStreamlitアプリケーションでは、SVG形式のデータをPathマークアップ構文に変換する機能が提供されています。[こちら](https://svg-to-path.streamlit.app/)から試してみてください。

## アプリケーションの機能

- SVGデータを入力し、Pathマークアップ構文へ変換できます。
- インタラクティブなUIを使用して、変換結果をリアルタイムで確認できます。

## スクリプトの概要

アプリケーションの実装には、Streamlitを使用して構築されたPythonスクリプトがあります。


## 使用例

アプリケーションの使用例として、以下の手順に従ってください。

1. **アプリにアクセス**: [アプリのリンク](https://svg-to-path.streamlit.app/)からアプリにアクセスします。

2. **SVGデータの入力**:
    アプリのUIには、SVGデータを入力するためのテキストエリアが用意されています。任意のSVGデータを入力します。またはsvg fileのラジオボタンを選択することでファイルの変換も行えます。
    
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1244335/26ad745e-4108-3217-ccc5-feadbd791e2a.png)



3. **変換結果の確認**:
入力したSVGデータに対して、アプリは即座にPathマークアップ構文に変換します。生成されたコードは画面に表示され、コピーして利用することができます。<br/>
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1244335/a17671ae-06d5-c434-021e-256c34b1153b.png)

## まとめ
Streamlitを使用したこのアプリケーションは、SVG形式のデータを簡単かつ効果的にPathマークアップ構文に変換するのに役立ちます。是非、試してみてください！
    
## 追記
streamlitの設定で公開範囲をパブリックにしていなかったです。すみません_(._.)__
修正しました！
Kotlin Parcelableの使用ケースについて

Androidのアプリケーション開発をしているとParcelableというものが出てきます。

## Parcelableとは？
Androidにおけるシリアライズ、デシリアライズするためのインターフェースです。
Parcelableを実装することで、オブジェクトの状態を保持できます。つまり、値を受け渡しを可能にします。

## どんなシナリオで使われるか？
**アクティビティやフラグメントが一時停止したり再開する場合**
onSaveInstanceStateおよびonRestoreInstanceStateメソッドでParcelableを使用してオブジェクトの状態を保存および復元します。
以下のような感じです。

```kotlin
private val SAVE_KEY = "save_key"

//保存する
override fun onSaveInstanceState(outState: Bundle) {
    outState.putParcelable(SAVE_KEY, myDataObject)
    super.onSaveInstanceState(outState)
}

//取得する
override fun onRestoreInstanceState(savedInstanceState: Bundle) {
    super.onRestoreInstanceState(savedInstanceState)
    val restoredData = savedInstanceState.getParcelable<MyData>(SAVE_KEY)
}
```

**あるアクティビティから別のアクティビティにデータを渡す場合**
IntentにParcelableオブジェクトを添付することができます。

**Fragment間でデータを受け渡す場合**
Fragmentに対しても、同様にParcelableを使用して引数を渡すことができます。

**画面の向きを回転させた場合**

画面の向きを変えるとアクティビティが再生成される可能性があります。
このとき、アクティビティの状態を保存し、再生成後にそれを復元する必要があります。Parcelableは、アクティビティの再生成前にonSaveInstanceStateで状態を保存し、onCreateが呼び出されたタイミングで取得するような処理になると思います。

```kotlin
class MainActivity : AppCompatActivity() {

    private var userData: UserData? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 画面が初めて作成された場合または再生成された場合
        if (savedInstanceState == null) {
            userData = UserData("John", 25)
        } else {
            // 画面の向きが変更されたときなど、再生成時に保存した状態を復元
            userData = savedInstanceState.getParcelable("user_data")
        }

        // userDataを使用してUIを更新するなどの処理...
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)

        // 画面の向きが変更されたときなど、再生成時に復元するために状態を保存
        outState.putParcelable("user_data", userData)
    }
}
```
【AWS】マネージドサービスとサーバーレスの違い

# 【AWS】マネージドサービスとサーバーレスの違い

クラウドコンピューティングが進化する中で、Amazon Web Services（AWS）はさまざまなサービスを提供しています。その中でも特に注目されているのが、マネージドサービスとサーバーレスです。これら二つのアプローチは、多くの面で共通点を持ちながらも、根本的な違いを有しています。本記事では、マネージドサービスとサーバーレスの違いを明確にし、それぞれの特徴と利用シナリオについて解説します。

## マネージドサービスとは

### インフラ管理の負担軽減

マネージドサービスは、インフラストラクチャの設定、運用、メンテナンスなどをクラウドプロバイダが代行するサービスです。これにより、ユーザーはサーバーの管理やパッチ適用などの複雑なタスクから解放され、アプリケーション開発やビジネスロジックに集中できます。

#### 特徴

- **インフラの自動化**: サーバーのプロビジョニングやスケーリングが自動化されます。
- **継続的なメンテナンス**: セキュリティパッチの適用やバックアップの取得などが自動的に行われます。

## サーバーレスとは

### インフラ管理の完全な抽象化

サーバーレスは、サーバーやインフラストラクチャに関する管理を完全に抽象化し、コードの実行にのみ焦点を当てるアプローチです。ユーザーはコードをデプロイするだけで、実行環境の管理やスケーリングはプロバイダによって自動的に行われます。

#### 特徴

- **完全な抽象化**: サーバーやクラスタの存在を意識する必要がありません。
- **イベント駆動**: アプリケーションはイベントに応じて自動的にスケールします。

## マネージドサービスとサーバーレスの違い

### 管理の範囲と責任

- **マネージドサービス**: インフラの管理は楽になりますが、アプリケーションレベルでの設定や管理が必要です。
- **サーバーレス**: アプリケーションのデプロイメントと実行に集中でき、インフラに関する考慮が不要です。

### 適用シナリオ

- **マネージドサービス**: カスタマイズ性が高く、特定のニーズに合わせたインフラを構築したい場合に適しています。
- **サーバーレス**: 高いスケーラビリティと迅速なデプロイメントが必要な場合や、インフラストラクチャの管理を完全に避けたい場合に最適です。

## まとめ

マネージドサービスとサーバーレスは、AWSを含むクラウドプラットフォームにおいて重要な役割を果たしています。これらのサービスを理解し、適切に選択することで、アプリケ

ーション開発の効率化、リソースの最適化、ビジネスの成長加速に寄与できます。プロジェクトのニーズに応じてマネージドサービスとサーバーレスの間で適切なバランスを見つけることが、クラウドベースのアプリケーション開発における鍵となります。
キャッシュサービスとは

# キャッシュサービスとは

キャッシュサービスは、データの一時的な保存や迅速なアクセスを可能にする技術で、ウェブアプリケーションやデータベースシステムにおいて重要な役割を果たしています。この記事では、キャッシュの基本概念、その種類、そしてキャッシュサービスがなぜ重要なのかについて、初心者にも理解しやすいように解説します。

## キャッシュの基本

### データアクセスの高速化

キャッシュは、頻繁にアクセスされるデータや計算結果を一時的に保存しておくためのメモリ領域です。これにより、同じデータへの再アクセス時に、元のデータソース（例えば、データベースやファイルシステム）からデータを読み込む代わりに、高速なキャッシュメモリからデータを取得できます。

### キャッシュのメリット

- **パフォーマンス向上**: データアクセス時間が短縮され、全体的なシステムパフォーマンスが向上します。
- **負荷の軽減**: バックエンドシステムへの負荷が軽減され、より効率的なリソース利用が可能になります。

## キャッシュの種類

### 様々なキャッシュメカニズム

- **ブラウザキャッシュ**: ウェブブラウザが静的コンテンツ（画像、CSSファイル、JavaScriptファイルなど）を一時保存します。
- **アプリケーションキャッシュ**: アプリケーションサーバー内でデータや計算結果をキャッシュします。
- **データベースキャッシュ**: データベースクエリの結果をキャッシュし、同じクエリの実行速度を向上させます。
- **分散キャッシュ**: ネットワーク上の複数のサーバーにわたってキャッシュを管理します（例：Redis、Memcached）。

## キャッシュの重要性

### システム全体の効率化

- **応答時間の短縮**: キャッシュを利用することで、エンドユーザーに対する応答時間が短縮され、ユーザーエクスペリエンスが向上します。
- **スケーラビリティの向上**: システムのスケーラビリティが向上し、大量のリクエストに対応できるようになります。

## まとめ

キャッシュサービスは、データの迅速な取得を実現し、システムのパフォーマンスを大幅に向上させる重要な役割を果たします。ブラウザキャッシュ、アプリケーションキャッシュ、データベースキャッシュ、分散キャッシュなど、さまざまな形態が存在し、それぞれ特定のニーズに対応します。適切なキャッシュ戦略を採用することで、ウェブアプリケーションやデ

ータベースシステムの効率性とスケーラビリティが向上し、エンドユーザーに優れた体験を提供することができます。
3つのELB特徴解説

# 様々なELBの特徴解説

Amazon Web Services（AWS）は、負荷分散を実現するためのElastic Load Balancing（ELB）サービスを提供しています。ELBは、入ってくるトラフィックを複数のターゲット（例えば、EC2インスタンス、コンテナ、IPアドレス）に分散することで、アプリケーションの可用性と耐障害性を高めます。ELBには、主にApplication Load Balancer（ALB）、Network Load Balancer（NLB）、そしてClassic Load Balancer（CLB）の三種類があり、それぞれ異なる特徴と用途を持っています。この記事では、これらのELBタイプの特徴と使い分けについて解説します。

## ELBの基本

### 負荷分散サービス

ELBは、AWSのスケーラブルな負荷分散サービスで、アプリケーションのトラフィックを効率的に処理します。このサービスを利用することで、高トラフィックの状況でもアプリケーションのパフォーマンスを維持し、システムのダウンタイムを減らすことができます。

## Application Load Balancer（ALB）

### アプリケーションレベルでの負荷分散

ALBは、特にHTTP/HTTPSトラフィックの負荷分散に適しており、リクエストの内容に基づいてトラフィックをルーティングできます。

#### 特徴

- **コンテンツベースのルーティング**: URLパスやヘッダー情報に基づいてトラフィックを異なるターゲットに転送します。
- **WebSocketsとHTTP/2サポート**: モダンなアプリケーションプロトコルに対応しています。
- **高度なリクエスト処理**: セッションスティッキネスやSSL終端などの機能を提供します。

## Network Load Balancer（NLB）

### ネットワークレベルでの高性能負荷分散

NLBは、TCPトラフィックやUDPトラフィックの負荷分散に特化しており、低レイテンシで高いスループットを実現します。

#### 特徴

- **高いスループットと低遅延**: インスタンスへの直接的な接続により、高速なトラフィック処理が可能です。
- **静的IPアドレスの割り当て**: 固定のIPアドレスを使用して負荷分散を行います。
- **長期接続に適している**: TCP接続やWebSocketの長時間接続に最適です。

## Classic Load Balancer（CLB）

### 従来型の負荷分散

CLBは、ALBやNLBが登場する以前から利用されているELBの初期形態で、基本的な負荷分散機能を提供します。

#### 特徴

- **シンプルな設定**: 一般的な負荷分散のニーズに対して簡単に設定できます。
- **HTTP/HTTPSとTCPトラフィックのサポート**: 基本的なプロトコルに対応しています。
- **徐々に非推奨に**: AWSではALBやNLBの利用を推奨

しており、CLBは徐々に古い技術と見なされています。

## まとめ

AWSのELBは、アプリケーションのトラフィックを効率的に処理し、可用性とパフォーマンスを向上させるための重要なツールです。ALBはアプリケーションレベルでの高度なルーティング機能を提供し、NLBはネットワークレベルでの高性能なトラフィック処理に適しています。CLBは基本的な負荷分散機能を提供しますが、より高度な機能が必要な場合はALBやNLBの利用が推奨されます。これらのサービスを理解し、適切に選択することで、AWS環境下でのアプリケーションの信頼性と効率性を大幅に向上させることが可能です。
rex0220 計算式プラグインの使い方をGPTsに学習させてみる（その９）誤った計算式の訂正学習２

[rex0220 計算式プラグインの使い方をGPTsに学習させてみる（その８）使用例の学習](https://qiita.com/rex0220/items/194b48e1a5172e5dd8a1)の続きです。

[rex0220 計算式プラグインの使い方をGPTsに学習させてみる（その７）誤った計算式の訂正学習](https://qiita.com/rex0220/items/b68659ae87d6c49b1898)で前月の１０日計算で誤った応答の訂正学習をしました。
しかし、前月の月末計算を行うと、また誤った応答をしていました。
使う関数が異なるものについては、使用例の学習追加して応答を改善する必要があります。

# 概要

「前月の月末を算出する」で、計算式プラグインでは使えない EMONTH 関数を使った応答となった。
「関数一覧に無い関数は利用できません。」としても、ダメなようです。
月末を計算する DATE_ENDOF 関数の使用例を学習させます。

# 学習前の「前月の月末を算出する」応答
惜しいけど、EMONTH 関数は使えません。

![2023-11-17_19h58_44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/b225dca9-9e51-d4f5-411a-7490990b30e4.png)

# 「前月の月末を算出する」の使用例を学習

```
・前月の月末を算出する
  DATE_ENDOF(DATE_ADD(日付, -1, "month"),"month")
  DATE_ENDOF(DATE_ADD("TODAY", -1, "month"),"month")
```

# 学習後の「前月の月末を算出する」応答

![2023-11-17_20h09_10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/5e784bba-05fa-18b4-e50d-6e958b84a0a6.png)

# 「１年前の月末」応答

月末に関してはマスターしたようです。

![2023-11-17_20h10_50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/729a97f5-cd76-ea83-f51e-46b1812aee26.png)

# 利用できない演算子と関数

応答内容に、利用できない演算子と関数があった場合の対策として、利用できないことと代替手段を学習させた。
利用できない演算子と関数を記述するだけでは、応答内容が改善されない。
機能として同等の演算子や関数を学習させることで、応答内容が改善されやすくなる。
モグラたたきのように、利用できない演算子と関数が応答されたら、代替手段を学習させるしかなさそうだ。

GPTs に対応方法を聞いたら、利用できない説明と代替案・記述例まで、詳細に記載することで対応できるらしい。

```.txt
・利用できない関数：CONTAINS
説明: この関数は配列内の特定の要素があるかを判定するために使用されます。計算式プラグインでは、利用できません。
代替案: CONTAINS 関数の代わりに IN 関数を利用できます。
記述例: IN(チェックボックス,"A")

・利用できない関数：ARRAY_REPLACE
説明: この関数は配列内の特定の要素を新しい値で置き換えるために使用されます。計算式プラグインでは、利用できません。
代替案: 配列の要素を置き換えるにはARRAY_MAP 関数で配列を再構築する必要があります。
記述例: 配列の要素"TEST"を”ABC" に変更する例
ARRAY_MAP(ARRAY(チェックボックス),x, REPLACE(x,"TEST","ABC"))

・利用できない関数：ARRAY_FILTER
説明: この関数は配列から特定の条件を満たす要素のみを抽出するために使われます。
代替案: ARRAY_FILTER の代わりに、ARRAY_FIL 関数を指定します。
記述例: ARRAY_FIL(ARRAY(チェックボックス),x, x = "A")

・利用できない関数：ARRAY_UNION
説明: 通常、複数の配列を結合し、重複する要素を排除するために使用されます。
代替案: ARRAY_UNION の代わりに、DISTINCT 関数を指定します。
記述例: DISTINCT(配列1,配列2)

・利用できない関数：ARRAY_REVERSE
説明：配列の要素の順序を逆にする関数ですが、計算式プラグインでは使用できません。
代替案：配列の順序を逆にする必要がある場合は、REVERSE 関数を指定します。
記述例: REVERSE(ARRAY("A","B","C"))
```

# まとめ

関数の使用例として、計算式を並べておいても、応答内容にはなかなか反映してくれません。
計算式の目的と計算式をまとめて学習させると、応答内容に反映されやすいようです。
AWSの主要なサーバーレスサービス

# AWSの主要なサーバーレスサービス

サーバーレスアーキテクチャは、アプリケーション開発と運用の世界で革新をもたらしています。このアプローチにより、開発者はサーバーの管理やスケーリングについて心配することなく、コードの実行に集中できます。Amazon Web Services（AWS）は、サーバーレスアーキテクチャを実現するための複数のサービスを提供しています。この記事では、AWSの主要なサーバーレスサービスとその特徴について、初心者にも分かりやすく解説します。

## AWS Lambda

### イベント駆動型コンピューティング

AWS Lambdaは、イベントに応じてコードを自動的に実行するサービスです。サーバーのプロビジョニングや管理はAWSが行い、開発者はコードのアップロードとイベントの定義に集中できます。

#### 特徴

- **自動スケーリング**: コードはイベント発生時に自動的に実行され、トラフィックの増減に応じてスケールします。
- **多言語対応**: Java、Go、PowerShell、Node.js、C#, Python、Rubyなど多くの言語をサポートします。

## Amazon API Gateway

### RESTful APIとWebSocket APIの作成

Amazon API Gatewayは、RESTful APIやWebSocket APIを簡単に作成、公開、保守、監視、およびセキュリティ保護するためのサービスです。Lambdaと連携することで、フルマネージドなサーバーレスAPIを構築できます。

#### 特徴

- **トラフィック管理**: ピーク時のトラフィックにも対応できるスケーラビリティを提供します。
- **セキュリティ**: AWS Identity and Access Management (IAM) と連携し、APIアクセスをセキュアに保ちます。

## Amazon S3

### スケーラブルなクラウドストレージ

Amazon Simple Storage Service (S3) は、スケーラブルなオブジェクトストレージサービスです。ウェブサイトの静的コンテンツのホスティングや、ビッグデータの保存など、様々な用途に使用できます。

#### 特徴

- **データ耐久性**: 高い耐久性を持ち、データの損失リスクが非常に低いです。
- **柔軟なストレージクラス**: さまざまなストレージクラスを提供し、コスト効率の良いデータ保存が可能です。

## Amazon DynamoDB

### フルマネージドNoSQLデータベース

Amazon DynamoDBは、高速で柔軟なNoSQLデータベースサービスで、サーバーレス環境に適しています。大規模な分散データベースの管理を簡素化します。

#### 特徴

- **高性能**: 単一ミリ秒未満のレイテンシで一貫したパフォーマンスを提供します。
- **オートスケーリング**: テーブルの使用量に基づいて自動的にスケーリングします。

## まとめ

AWSのサーバーレスサービスは、アプリケーション開発の効率化と運

用の簡素化に大きく貢献します。Lambda、API Gateway、S3、DynamoDBなどのサービスは、サーバーレスアーキテクチャの構築において中心的な役割を果たし、開発者がインフラストラクチャの管理から解放され、ビジネスロジックの実装に集中できる環境を提供します。これらのサービスを理解し、適切に組み合わせることで、高度にスケーラブルでセキュアなサーバーレスアプリケーションを構築できます。
AWSの主要ゲートウェイ

# AWSの主要ゲートウェイ

Amazon Web Services（AWS）は、クラウドコンピューティングプラットフォームとして広く利用されています。AWSのネットワークアーキテクチャの重要な部分を担うのが、さまざまな種類のゲートウェイです。これらのゲートウェイは、インターネットや他のネットワークとの接続を管理し、セキュリティとデータの流れを効率的にコントロールします。この記事では、AWS内で使用される主要なゲートウェイの種類とその機能について初心者にも分かりやすく解説します。

## インターネットゲートウェイ (IGW)

### VPCへのインターネットアクセスを提供

インターネットゲートウェイは、AWSのVirtual Private Cloud（VPC）をインターネットに接続するために使用されます。これにより、VPC内のリソース（例えば、EC2インスタンス）がインターネットと通信できるようになります。

### 特徴

- **双方向通信**: IGWは、インターネットからのインバウンドトラフィックと、VPCからのアウトバウンドトラフィックの両方をサポートします。
- **パブリックサブネットの接続**: IGWは通常、VPC内のパブリックサブネットに接続されます。

## NATゲートウェイ (NAT GW)

### プライベートサブネットのアウトバウンドアクセス

NATゲートウェイは、プライベートサブネット内のインスタンスがインターネットと通信するのを可能にしますが、インターネットからの直接のアクセスは許可しません。

### 特徴

- **セキュリティ**: プライベートサブネットのインスタンスはインターネットから隠された状態で、インバウンド接続を受け付けません。
- **アップデートやパッチのダウンロード**: 外部のリソースにアクセスすることで、ソフトウェアの更新などを安全に行うことができます。

## バーチャルプライベートゲートウェイ (VGW)

### VPN接続を提供

バーチャルプライベートゲートウェイは、VPCを企業のオンプレミスネットワークや別のVPCと安全に接続するために用いられます。

### 特徴

- **VPN接続**: VGWを通じて、Secure Socket Layer（SSL）またはIPsec VPN接続を確立できます。
- **データの暗号化**: 通信データは暗号化され、セキュリティが保たれます。

## AWS Direct Connect (DX)

### 専用ネットワーク接続

AWS Direct Connectは、AWSとオンプレミス環境との間に専用のネットワーク接続を確立します。これにより、インターネット経由ではなく、より高速で安定した接続を実現できます。

### 特徴

- **高速アクセス**: インターネットトラフィックの遅延や混雑を避け、一貫した高速接続を提供します。
- **データ転送コストの削減**: 大量のデ

ータ転送時に、コスト削減が期待できます。

## まとめ

AWSのゲートウェイは、VPCの構成要素として非常に重要であり、ネットワークのセキュリティ、接続性、効率を大きく向上させます。インターネットゲートウェイ、NATゲートウェイ、バーチャルプライベートゲートウェイ、AWS Direct Connectは、それぞれ異なるニーズに応じた接続オプションを提供し、AWSクラウド環境の柔軟性と機能性を高めます。これらのゲートウェイを理解し、適切に構成することで、AWS上のリソースをより効果的に利用できるようになります。
DNSサービス/ゲートウェイ/ルートテーブル/ロードバランサーの違い

# DNSサービス/ゲートウェイ/ルートテーブル/ロードバランサーの違い

ネットワークの世界では、DNSサービス、ゲートウェイ、ロードバランサーという三つの異なるコンポーネントが重要な役割を果たしています。これらはそれぞれ異なる機能と目的を持ち、ネットワークの効率性、セキュリティ、可用性を高めるために用いられます。ここでは、これらの技術の基本的な違いと、それぞれがネットワーク環境にどのように貢献するのかを初心者にも分かりやすく解説します。

## DNSサービスとは

### ドメイン名をIPアドレスに変換

DNS（Domain Name System）サービスは、インターネット上のドメイン名（例えば、`www.example.com`）をIPアドレスに変換するシステムです。これにより、ユーザーは覚えやすいドメイン名を使用してウェブサイトにアクセスでき、背後で実際のIPアドレスへのルーティングが行われます。

### DNSの重要性

- **ユーザーフレンドリー**: IPアドレスを直接記憶する必要がなく、ウェブサイトへのアクセスが容易になります。
- **動的なIP管理**: ウェブサーバーのIPアドレスが変更されても、ドメイン名は同じままで、アクセス可能です。

## ゲートウェイとは

### ネットワーク間の接続ポイント

ゲートウェイは、異なるネットワーク間でのデータ転送を可能にするデバイスまたはソフトウェアです。これにより、例えば、ローカルネットワークとインターネット間の通信が可能になります。

### ゲートウェイの役割

- **プロトコル変換**: 異なるネットワークプロトコル間で通信するために、データ形式の変換を行います。
- **セキュリティ**: 外部からの不正なアクセスを防ぎ、ネットワークのセキュリティを強化します。

## ルートテーブルとは

ルートテーブルは、AWSのVirtual Private Cloud（VPC）内のネットワークトラフィックのルーティングを制御するために重要な役割を果たします。ルートテーブルは、トラフィックがどのように転送されるかを定義するルールの集合体です。AWSのVPC内で複数のルートテーブルを作成し、異なるサブネットに適用することで、ネットワークの柔軟性とセキュリティを向上させることが可能です。

### ルートテーブルの基本概念

- **ルーティングルール**：各ルールは特定のIPアドレス範囲（宛先）と、そのトラフィックを転送する先（ターゲット）を指定します。
- **複数のルートテーブル**：VPC内で複数のルートテーブルを作成し、異なるサブネットに異なるルーティングポリシーを適用できます。

### AWS内でのルートテーブルの役割

- **トラフィックの制御**：サブネット間やインターネット、他のVPCなどへのトラフィックの流れを効果的に管理します。
- **セキュリティの強化**：不要なトラフィックが特定のリソースに届かないようにルーティングを設定することで、セキュリティを強化できます。

### ルートテーブルの設定例

- **インターネットゲートウェイへのルート**：パブリックサブネット内のインスタンスがインターネットと通信できるように、ルートテーブルにインターネットゲートウェイへのルートを設定します。
- **VPCピアリング**：別のVPCと通信するために、そのVPCへのルートをルートテーブルに追加します。

## ロードバランサーとは

### トラフィックの均等分散

ロードバランサーは、ネットワークトラフィックを複数のサーバー間で分散させる装置やソフトウェアです。これにより、単一のサーバーに過負荷がかかることを防ぎ、全体のパフォーマンスと可用性を向上させます。

### ロードバランサーの機能

- **負荷分散**: 複数のサーバーにトラフィックを均等に分配し、サービスの停止を防ぎます。
- **スケーラビリティ**: トラフィックの増加に対応し、システムの拡張が容易になります。

## まとめ

DNSサービス、ゲートウェイ、ロードバランサーは、それぞれネットワークの異なる側面を担っています。DNSサービスはドメイン名とIPアドレスの変換を担い、ユーザーにとってのアクセスのしやすさを提供します

。ゲートウェイは異なるネットワーク間の通信の橋渡しを行い、セキュリティを確保します。ロードバランサーはサーバー間でトラフィックを分散させ、システムのパフォーマンスと可用性を高めます。これらの技術を理解し適切に適用することで、効率的で安全なネットワーク環境の構築が可能になります。
【SwiftUI】TextにURLを表示させようとすると勝手に青くなるのやめてくれ

# はじめに
TextにURLを表示させようとすると勝手に青くなってしまいます。
`foregroundStyle`などを指定してもずっと青いので💢

# 問題
`Text`にURLを表示させようとするとURL部分が青くなります。
```swift
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("https://qiita.com/")
    }
}
```
![スクリーンショット 2023-11-17 20.00.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/71ecc92a-1638-9b99-bd72-e8503d488981.png)

文字+URLだとURL部分だけ青くなります。
```swift
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("QiitaのURLはhttps://qiita.com/")
    }
}
```
![スクリーンショット 2023-11-17 20.01.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/aca11cd3-9b4d-62d0-7ecc-f8adb908d9cb.png)

文字+URL+文字だと後ろの文字がURL判定されて青くなります。マジで困ります。
```swift
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("QiitaのURLはhttps://qiita.com/です")
    }
}
```
![スクリーンショット 2023-11-17 20.02.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/d4f14db3-0d48-820f-e50f-78476ec30f04.png)

`foregroundStyle`を指定してもURL部分は青いままです。
```swift
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("QiitaのURLはhttps://qiita.com/です")
            .foregroundStyle(.red)
    }
}
```
![スクリーンショット 2023-11-17 20.03.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/12b6ff92-df92-106e-29c8-90cf6263a5a5.png)

# 解決方法1
`Text`のマークダウンを無効にする
```swift
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text(verbatim: "QiitaのURLはhttps://qiita.com/です")
    }
}
```
![スクリーンショット 2023-11-17 20.06.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/1e43f2e9-e98c-899f-0424-bb97cd7c4a7d.png)

:::note alert
**欠点**
他の箇所でマークダウンが使いたくても使えなくなります。
Qiitaの部分を強調しようと太文字にしようとした場合
![スクリーンショット 2023-11-17 20.13.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/ed66e720-7d68-8ec1-7cae-2c4f6202af1a.png)
```swift
Text("**Qiita**のURLはhttps://qiita.com/です")
```
:::

# 解決方法２
`tint`でリンクの色を変更する
```swift
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("QiitaのURLはhttps://qiita.com/です")
            .tint(.primary)
    }
}
```
![スクリーンショット 2023-11-17 20.06.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/1e43f2e9-e98c-899f-0424-bb97cd7c4a7d.png)

:::note alert
**欠点**
本当にリンクを表示させたい時も黒くなってしまう
![スクリーンショット 2023-11-17 20.18.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1745371/515c1b41-363d-881a-1907-2a9afeb2aa14.png)
```swift
Text("QiitaのURLはhttps://qiita.com/です。\n私のプロフィールは[ここ](https://qiita.com/SNQ-2001)")
    .tint(.primary)
```
:::

# おわり
原因はマークダウンですね
標準でマークダウンが効くようになってるのはいいことなのか？
【Google Cloud Next Tokyo ’23レポート】強みを活かす組織づくりへの変革を考える

# 概要
全ての組織が不確実な時代を乗り越え、成長を続け存続をするためには、多様性の力を味方につけ「強みを活かす」組織作りが急務です。そうはいっても組織作りは言うは易く行うは難し。どうような一手を打つべきか悩みを抱えている組織は多いのではないでしょうか。本セッションでは、組織変革のプロフェッショナルや組織改革の実践企業が一同に会し、「強みを活かす」組織づくりの目的と実践方法について考えます。

株式会社 UPSIDER HR HRPR
宮本 佳歩 氏

吉積情報株式会社 代表取締役
秋田 晴通 氏

Tably株式会社 代表取締役
及川 卓也 氏

Google Cloud パートナー事業本部 ソリューション パートナー 事業開発マネージャー
清水 岳之
# 所感
[【Google Cloud Next Tokyo ’23レポート】グローバル No 1 サービスを目指す meviy に、なぜカルチャー推進が重要なのか？〜社員の自己肯定感を高める #IAmRemarkable](https://qiita.com/yukiMiyoshi_fcafe/items/9e507b2303e14402901e)でも触れられていた、イノーべションを起こせる組織に必要要素が、ここでも登場。
それらをベースに、パネリストのみなさんに自社やご自身のお考えをお話し頂きました。

正直いって、ここのお話は熱くていいお話しでした。
*カルチャーはプロダクトである*
をはじめ、名言がたくさん飛び出たのではないかと。

飛行機に例えて、飛び続ける（前へ加速し続ける）必要があってその上で安全性の確保も怠らずやって、という例えば話はすごく腹落ちしました。
それだけ組織運営は難しく繊細でありつつ、前へ前へ進まなければならない。

あとコミニュケーションの大事さ。
これは、同じようなテーマだと必ず出てくると思いますが、やはり外せないキーワードだと思います。

IT業界はずっとVUCAだったよね、っていうのも納得感ありましたね笑

当事者意識をいかにして持ってもらうか、
採用がどれだけ大事であるか。

それらを本当に熱のこと持った言葉で伝えていただいたように思います。

最後に、この話を聞いて「アクション」してください、という及川さんの言葉は刺さりました。
翌日にはいい話だったな、で終わる事は本当に多い。
アクションしないと、それで終わり、

僕も何かアクションしないと、と思いました。
（このアウトプットはその一歩・・・）

# 内容メモ
## イノベーションを生み出す組織に共通する６つの要素
- 多様性の尊重
- ビジョン共有
- 自主祭
- 内発的動機づけ
- リスクテイク
- つながりとコラボレーション

## VUCA時代おいて最も大切にしていることは？
※VUCA：目まぐるしく変転する予測困難な状況

- 機能だけを突き詰めると、ユニーク性を出すのが難しい
    - 加えて企業のカルチャーも重要になってくる
    - カルチャーはプロダクトである
        - UPSIDERではお客様の近くに座る、を意識している
- カルチャーに優劣も正解もない
- カルチャーそのものを大事にしてほしい
    - UPSIDERでは大事にしている
- 同じビジョンにむかっているか、それに関するコミュニケーションをとっているか？が大事
- 変化に如何に対応していくか
    - 1人だと行き詰まることが多い
    - 人に話すと不思議とアイディアが生まれる
- IT業界はそもそもずっとVUCAだった
- 今の状態に安泰はない
    - 今業界はパラノイアしか生き残れない
- 飛び続ける必要がある
    - 飛行機のイメージ。加速し続けないと落ちる。
    - 乗客を怪我させない、飛行機を落とさないためのチェック
- 「ブレーキ」をかけるアドバイスが多い
    - チェックリストの肥大化
### コミニュケーションの工夫
- オンラインでもシャッフルランチを実施

## 成長に対する最も大きな課題と打ち手
- 採用が難しいながらも最も重要
- 今いるメンバーにどうすれば当事者意識を持ってもらえるか？
    - Googleのカルチャーに、全ては一人一人が責任を持つ
        - 心理的安全性はマネージャーが作るではなく、一人一人が考える
- 相互理解をいかに深めていくか
    - なぜこの人は今こんなことをいうのか？
    - 人それぞれのライフラインを共有する
        - 日常的に深く自己開示を促す
    - ユニフォームのような、共通のアイテムを身につけると自然と共同感を感じられる
## 組織づくりの失敗例
- 採用
    - 相談を受けた際に話を聞いていくと、採用ミス、に落ち着くことが多い
    - 採用はとにかくこだわる
- 組織の成功の話から、それを自分事として成功させたいと本気で思っているか？
    - スタートアップの方が死に物狂い
    - 大企業が本気で人・もの・金をかければ負けるはずがない
        - それでも負けるところに、一人一人の成功に対する自分事の観点がないのでは
    - 時間は有限である
    - 個人がどれだけ本気になれるか

## 組織づくりのヒント
- 多様性に取り組む目的は何か？
    - 組織のためであり、自分のためであり、お客様のためであり、社会のため
    - みせかけなら不要
- 上層部をいかに巻き込めるか
- アクションを起こす
    - 聞いた話、感情が動いた事を忘れずにアクションに結びつける 

# 関連記事
- [【Google Cloud Next Tokyo ’23レポート】 by yukiMiyoshi_fcafe](https://qiita.com/yukiMiyoshi_fcafe/items/18ad65426e1a71311419)
- [【Google Cloud Next Tokyo ’23レポート】 by sho_fcafe](https://qiita.com/sho_fcafe/items/a97ee90d6a05f68e1c01)