OmniAICreator/Qiita-1.07M huggingface dataset:
FRP VNROM Bypass APK を使用して Google ロック (FRP) を削除する方法

序章

出荷時設定へのリセット保護 (FRP) が原因で Android デバイスからロックアウトされてイライラした経験はありますか? Google FRP ロックは、盗難や不正アクセスの場合にデータを保護するために設計されたセキュリティ機能です。 その目的は果たせますが、ログイン資格情報を忘れた正規ユーザーにとっては不便になる可能性があります。 幸いなことに、利用可能な解決策があります。この記事では、FRP VNROM Bypass APK を使用して Google FRP ロックを削除するプロセスを説明します。

FRP VNROM バイパス APK とは何ですか?

FRP VNROM Bypass APK は、Android デバイス上の Google FRP ロックをバイパスするために特別に設計された強力なツールです。 これは、工場出荷時の設定にリセットした後のセットアップ中に Google アカウントの検証プロセスを回避することで、デバイスへのアクセスを取り戻すための簡単で効果的な方法を提供します。 この方法は個人的な使用のみを目的としており、悪意のある目的での使用は固く禁じられていることに注意してください。

Google FRP ロックを削除するためのステップバイステップ ガイド

FRP VNROM Bypass APK をダウンロードする: まず、オンラインで FRP VNROM Bypass APK を検索します。 サードパーティのソースからファイルをダウンロードする場合は、有害なソフトウェアが含まれている可能性があるので注意してください。 他のユーザーが APK の正当性を確認している信頼できる Web サイトまたはフォーラムを使用してください。

不明なソースを有効にする: APK をインストールする前に、Android デバイスが不明なソースからのインストールを許可していることを確認してください。 これを行うには、[設定] > [セキュリティ] に移動し、[不明なソース] を有効にします。 Google Play ストア以外のソースからアプリをインストールできるようになるため、この手順は非常に重要です。

APK をインストールする: デバイス上でダウンロードした FRP VNROM Bypass APK を見つけてタップし、インストール プロセスを開始します。 画面上の指示に従うと、アプリは数秒でインストールされます。

FRP ロックをバイパスする: インストールが完了したら、FRP VNROM バイパス アプリを開きます。 バイパス プロセスを案内しますが、デバイスのメーカーやモデルによって異なる場合があります。 一歩間違えると複雑な事態につながる可能性があるため、アプリの指示には注意深く従ってください。

デバイスを工場出荷時設定にリセットする (オプション): 場合によっては、FRP VNROM バイパスで FRP ロックを正常に削除するには工場出荷時設定へのリセットが必要になる場合があります。 リセットを続行する前に、重要なデータをすべてバックアップしていることを確認してください。

デバイスのセットアップ: Google FRP ロックを正常にバイパスした後、通常どおり Android デバイスをセットアップできます。 このプロセス中、以前の Google アカウント情報の入力を求められることはなく、デバイスに完全にアクセスできます。

結論

FRP VNROM Bypass APK を使用して Google FRP ロックを削除すると、Android デバイスからロックアウトされていることに気付いた人にとっては救世主となる可能性があります。 これは、手間をかけずにアクセスを回復してデバイスを使用するための正当な方法を提供します。 ただし、セキュリティ対策をバイパスするのは個人的な使用の場合にのみ行うべきであり、悪意のある目的で行うべきではないことを常に覚えておいてください。

サードパーティのツールを使用する場合は注意し、ダウンロードする APK ファイルのソースと正当性を常に確認してください。 さらに、プロセス中に問題が発生した場合は、デバイスの製造元または認定サービス センターに連絡することを検討してください。 ロック解除おめでとうございます!
ソース： https://www.frpbypass.net/download-vnrom-frp-bypass-apk/
wslでelixir その29

# 概要
wsl(wsl2じゃない)で、elixirやってみた。
練習問題、やってみた。

# 練習問題
websocket serverでfizzbuzzを返せ。
portは、50002
clientは、neosvr

# 写真

![2023-08-03 21.46.37.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/00d7ef72-f279-8ca8-2c2f-e959a5e50b52.jpeg)

# サンプルコード

```
defmodule FizzBuzz.Server do
	alias ElixirSocketTesting.ClientAgent
	def start(port \\ 50002) do
		ClientAgent.start_link
		server = Socket.Web.listen! port
		loop(server)
	end
	def loop(server) do
		client = server
			|> Socket.Web.accept!
		client
		|> Socket.Web.accept!
		ClientAgent.add(client)
		Task.async(fn ->
			recv(client)
		end)
		loop(server)
	end
	def recv(client) do
		case client |> Socket.Web.recv! do
		{:text, message} ->
			res = FizzBuzz1.say
			broadcast({:text, res})
			recv(client)
		{:close, _, _} ->
			ClientAgent.remove(client)
		other ->
			IO.inspect other
		end
	end
	def broadcast(packet) do
		ClientAgent.all
		|> Enum.each(fn client ->
			Socket.Web.send(client, packet)
		end)
	end
end


```


以上。
【Vite+TypeScript+React】環境変数の活用方法とそのトラブルシューティング



## 目次

1. はじめに
2. Viteにおける環境変数の設定方法
3. ローカルと本番環境で異なる環境変数を設定する方法
4. 「プロパティ 'env' は型 'ImportMeta' に存在しません」の解決方法
5. まとめ

## 1. はじめに

皆さん、こんにちは！今回は、Vite + TypeScript + Reactの環境で、環境変数を活用する方法とその際に遭遇する可能性のある問題の解決方法について解説します。

## 2. Viteにおける環境変数の設定方法

まずは、Viteで環境変数を設定する基本的な手順を見ていきましょう。

1. プロジェクトのルートディレクトリに`.env`ファイルを作成します。
2. `.env`ファイルに環境変数を設定します。例えば、次のように設定します：

```bash
VITE_APP_TITLE=My App
```

3. TypeScriptとReactのコード内で`import.meta.env.VITE_APP_TITLE`を使用して環境変数にアクセスします：

```typescript
console.log(import.meta.env.VITE_APP_TITLE); // "My App"
```

## 3. ローカルと本番環境で異なる環境変数を設定する方法

次に、ローカル環境と本番環境で異なる環境変数を設定する方法を見ていきましょう。

1. プロジェクトのルートディレクトリに`.env.development`と`.env.production`という2つのファイルを作成します。
2. `.env.development`ファイルにはローカル開発環境で使用する環境変数を設定します。例えば：

```bash
VITE_APP_TITLE=My App (Development)
```

3. `.env.production`ファイルには本番環境で使用する環境変数を設定します。例えば：

```bash
VITE_APP_TITLE=My App (Production)
```

4. TypeScriptとReactのコード内で`import.meta.env.VITE_APP_TITLE`を使用して環境変数にアクセスします：

```typescript
console.log(import.meta.env.VITE_APP_TITLE); // "My App (Development)" or "My App (Production)"
```

## 4. 「プロパティ 'env' は型 'ImportMeta' に存在しません」の解決方法

Viteで環境変数を使っていると、「プロパティ 'env' は型 'ImportMeta' に存在しません」というエラーに遭遇することがあります。この問題を解決するためには、以下の手順を実行します。

1. あなたのプロジェクトのルートディレクトリに`vite-env.d.ts`という名前のファイルを作成します。
2. そのファイルに以下の内容を追加します。

```typescript
/// <reference types="vite/client" />
```

これで、TypeScriptは`import.meta.env`の型を理解し、上記のエラーが解消されます。

## 5. まとめ

今回は、Vite + TypeScript + Reactの環境で、環境変数の設定方法とその際に遭遇する可能性のある問題の解決方法について解説しました。Viteはフロントエンド開発を効率化する素晴らしいツールですが、その設定やエラーメッセージは初見では理解しづらいことがあります。しかし、一度理解してしまえば、その柔軟性とパワーを存分に活用できるでしょう。

それでは、Happy Coding！
プログラミング勉強会256times「フロントエンド案件修行 256times Media編」に参加しました

## フロントエンド案件修行 256times Media編に参加しました。

フロントページから詳細ページへ移動することができる、Webサイトを初めて作り、とても楽しかったです。
こちらが４日目に作成した、<a href="https://colcmia.github.io/256timesMedia/index.html">256times Mediaのサイト</a>です。

### 工夫したところ

- SP版では、ハンバーガーメニューを設置しました。
- PC版では、ヘッダーに検索窓を設置しました。
- 日付が何日前と表記されるようにしました。
- PC版では、2カラムにし、人気記事と広告を配置しました。
- ヒーローエリアトップにも、広告を配置しました。
- WordPressのように、人気記事のアイキャッチをクリックすると、記事詳細ページに飛ぶように作りました。
- 記事詳細ページのJavaScriptは、そのページ内の```<script>``` タグに記載しないと、動きませんでした。
- 記事詳細ページのヘッダーのアイコンをクリックすると、トップページに戻る仕様にしました。
- 画像を綺麗に配置するために、```css: object-fit:cover;```を使いましたが、自分のイメージのようにはなりませんでした。

WordPressのようなサイトを作る事が出来て、楽しかったです。
Fundamentals of Data Visualization 輪読会資料 第1回 (2023.8.7)

[英語でデータ可視化を学ぼう：第1回](https://gaisaba.connpass.com/event/291969/) での報告資料です。この勉強会では、[Claus O. Wilke, Fundamentals of Data Visualization](https://clauswilke.com/dataviz/) を輪読しています。今回の担当箇所は Preface と Introduction で、この文書では内容の要約を行います。

## Preface

**この本の全体像**

図表は文書の出来・不出来を左右するほど大事であるのに、**説得的な作図の方法**を教える資料は少ない
- 大学で作図を専門に教える講義は稀
- 文献も少ない

可視化ツールのチュートリアルはあるものの、それらは
- 特定の可視効果を**実現する方法**は教えてくれるが・・・
- **なぜ**ある可視化が他の選択肢と比べて**望ましい**のかが説明してくれない

にも関わらず、**分析者は良い図表を作れるはずだと期待**されてしまう・・・

編集者が文章の質を感じる「耳」が必要なように、
可視化のためには図表の質を感じ取る「目」が必要：
- バランスは取れているか
- わかりやすいか
- 説得的か

そして、目は鍛えられる: 多くの単純なルールと原則を意識して細部に注意することが必要

一方、一昼夜で身につくものでもなく、経験によって身につくものでもある
著者の今の考えも絶対のものではないから、鵜呑みにせず自分の感覚に合うかどうかを考えるべき

**この本の読み方**

基本的には論理的な順序で書かれているが、順不同で読んでも良いようになっている
直近の関心のある箇所をつまんで実践してみるのもおすすめ

この本の図表のほとんど全ては [R言語](https://cran.r-project.org)の[ggplot2](https://ggplot2.tidyverse.org)ライブラリにより作られているが、
Rのハウツー本ではない
→　**可視化の原理原則**を示すのが主題
＊コードを知りたいときはGitHubレポジトリ[clauswilke/dataviz](https://github.com/clauswilke/dataviz) に公開している

### Thoughts on graphing software and figure-preparation pipelines

作者の意見では、可視化のパイプラインにおいては **自動化が肝**
図表はデータ分析のパイプラインの中で自動で生成されるべきで、手作業での編集（Illustratorなど）を挟むべきではない
> ＊ところで、[Nathan Yau, Visualize This](https://www.amazon.com/Visualize-This-FlowingData-Visualization-Statistics/dp/0470944889) という別の本では、Rで作図したあとIllustatorなどで洗練させていく方法が取られていました。時期が大分古いというのと、こちらの著者は新聞紙に載せる図を作っていたという違いもあるかもしれません

自動化すべき理由
- 手作業を挟むと再現性が失われる
- 手作業が多いと、図表を改善するのが面倒になる
- 自分のやった手作業を忘れてしまう

結果、対話的な可視化ツールは避けるべき。Excelも対話的
> BIツールはどうだろう？


## Introduction

データ可視化は、芸術であり科学でもある（その両立が難しい）

- いちばん大切なのは**正しさ**（ミスリーディングであったり歪曲しては駄目）
- 同時に、見た目に**美しい**である必要がある
- メッセージを強調するものであるべき

科学者の傾向としては、審美性で苦労することが多い
デザイナーは逆に美しい可視化をするがデータに疎いことが多い

この本が扱うのは、出版物やプレゼン向けの可視化における「原則」「手法」「概念」
ただし、静的なものにフォーカス（アニメーションや対話的なグラフを含まない）

**各パートについて**

**Part I. From data to visualization**

- 様々なグラフタイプを解説（棒グラフ、散布図、円グラフなど）.
- 可視化の種別を「対象となるデータ型」ではなく「伝えたいメッセージ」で分類（統計学者以外にはこちらのほうが良いとのこと）
> 以前、仕事で可視化の手法について技術紹介したときに、データ型で分類して紹介したことを思い出しました

**Part II. Principles of figure design**

- データ可視化で生じるデザイン問題を説明（可視化における審美性 (aesthetic) の側面）
- 色、シンボル、大きさなどの選択問題を取り上げる


**Part III. Miscellaneous topics**

- その他のトピック
    - ファイル形式
    - ソフトウェア
    - etc.

### Ugly, bad, and wrong figures

この本では、同じ図表の複数バージョンを作り、良い例と悪い例を両方示す
悪い例には次の3つの分類が付されている：

- **Ugly**: 美的な問題はあるが、それ以外は明瞭で有益な図。
- **Bad**: 知覚に関する問題のある図。不明確, わかりにくい、複雑過ぎ、欺瞞的。
- **Wrong**: 数学的な問題のある図。客観的に間違っている。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80588/bb010c7c-3e50-08ec-2bf0-f15390638236.png" width="600px" />
ReactNativeでstyled-componentsを使ったbox-shadowの正しい設定方法: 3つの例で完全解説


# ReactNativeでstyled-componentsを使ったbox-shadowの正しい設定方法: 3つの例で完全解説

ReactNativeでスタイリングを行う際、`styled-components`を使用すると、簡潔に美しいデザインが作れることが多いです。しかし、`box-shadow`の設定は少しトリッキーな部分があります。

この記事では、ReactNativeプロジェクトで`styled-components`を使用して`box-shadow`を設定する方法を、3つの例（2つの失敗例と1つの成功例）を通して解説します。

## 目次
[1.失敗例1: 一般的なbox-shadowの指定](失敗例1)
2. [失敗例2: shadow-offsetの誤った書き方](#失敗例2)
3. [成功例: 正しいshadow-offsetの書き方](#成功例)
4. [まとめ](#まとめ)

### 失敗例1: 一般的なbox-shadowの指定
ReactNativeでは一般的なCSSのように`box-shadow`を直接指定することができません。

```jsx
import styled from 'styled-components/native';

export const Container = styled.View`
  width: 150px;
  height: 52px;
  border-radius: 26px;
  backgroundColor: "#FFFFFF";

  //shadow
  box-shadow: 2px 8px 12px rgba(0, 0, 0, 0.16);
`;
```

このように書いても、シャドウは反映されません。

### 失敗例2: shadow-offsetの誤った書き方
ReactNativeでは、`shadow-color`, `shadow-opacity`, `shadow-radius`, `shadow-offset`などのプロパティを使用してシャドウを設定します。しかし、次のように`shadow-offset`をオブジェクトで指定すると、反映されません。

```jsx
import styled from 'styled-components/native';
import { Platform } from 'react-native';

export const Container = styled.View`
  width: 150px;
  height: 52px;
  border-radius: 26px;
  backgroundColor: "#FFFFFF";

  //shadow
  shadow-color: "#000000";
  shadow-opacity: 0.16;
  shadow-radius: 12px;
  shadow-offset: {
    width: 2px;
    height: 8px;
  };
  ${Platform.OS === 'android' && `elevation: 6;`}
`;
```

### 成功例: 正しいshadow-offsetの書き方
正しい`shadow-offset`の書き方は次のようになります。

```jsx
import styled from 'styled-components/native';
import { Platform } from 'react-native';

export const Container = styled.View`
  width: 150px;
  height: 52px;
  border-radius: 26px;
  backgroundColor: "#FFFFFF";

  //shadow
  shadow-color: "#000000";
  shadow-opacity: 0.16;
  shadow-radius: 12px;
  shadow-offset: 2px 8px;
  ${Platform.OS === 'android' && `elevation: 6;`}
`;
```

このように指定すると、シャドウが正しく反映されます。

### まとめ
ReactNativeで`styled-components`を使用して`box-shadow`を指定する際は、`shadow-offset`の書き方に注意が必要です。正しい書き方をマスターすることで、美しいシャドウ効果をアプリに追加できます。この記事が、あなたの開発をスムーズに進める助けになれば幸いです。
合コンで使える！ITエンジニア必須テクニック３選

はじめまして。
ITエンジニアのがとぺいたです。
ではしょっぱなから一言、ここで断言します。
**ITエンジニアはモテる！！**
本題に入るITエンジニア合コン必須テクニックを伝授する前に、論理的に
・ITエンジニアがモテる理由
・ITエンジニアを名乗ってはいけない理由
について説明します。
# なぜITエンジニアがモテるのか
モテるからです。
雨が降るように、いつだって弱者が強者に搾取されるように、月が奇麗なように
世の中の普遍の原理、ルールなのです。
# 合コンでITエンジニアを名乗ってはいけない理由
私仕事できます！っていうやつ大体仕事できないですよね、、、
「一億円稼いだ僕が教える簡単投資テクニック」
こんな本誰も買わないですよね。胡散臭いですもん。
ITエンジニアも一緒です。
ITエンジニアですって名乗るのはNGです。
じゃあどうするの？
そう、匂わせることが大事なんです。
# ITエンジニア匂わせ必須テクニック３選
### 1. JAVA TEA
ITエンジニアを匂わすためには、まず身なりからです。
時計といえばROLEX、ITエンジニアといえば**JAVA TEA**です。
持ち歩く飲み物は絶対に**JAVA TEA**にしましょう。
Javaを連想させるのです。
今までモテるITエンジニアを何人も見てきましたが、**JAVA TEA**以外の飲み物を飲んでいる人にはあったことがありません。
箱ごとケースで買っておくことをお勧めします。
### 2. Cookie
好きな食べ物は？と聞かれたとき
「・・・本当はラーメンって言いたいけど、にんにくマシマシ系男子っておもわれたくない」
「・・・好きな食べ物なんて、特にない」
「・・・おしゃれな食べ物言わなきゃ、、、」
ノンノンノン
僕たちにはとっておきのアイテムがあるじゃないですか。
そう！！**Cokkie**です！！
先代のエンジニアに感謝ですね。ITエンジニアの合コンのために、この名前にしてくれたそうです。
好きな食べ物を聞かれたら、間髪入れずに横から
**「Cokkie!!!!!!!!!!!!」**
と割り込みましょう。

### 3. While（true）{}
まずは、While（true）{}を噛まずに言えるようになりましょう。
「ワイル カッコ トゥルー カッコトジル ナミカッコ ナミカッコトジル」

練習できましたか？

・それでは実践編です。
意地悪なA君が女の子の前で嫌～～なことを言ってきたとします。
**A君「てかさー、こいつチェックシャツ以外着てるのみたことなくね？(笑)ダサい(笑)」**
さて、ここで練習の成果を発揮しましょう。
**ワイ「ワイル カッコ トゥルー カッコトジル ナミカッコ ナミカッコトジル の中に突っ込むぞ！」**
さすがにIT系じゃない女の子でも無限ループはしってるはず。
てか、ちょっと考えればこの式の意味がわかるはず。
**女の子「なにその言い回し...かっこいい...！！（この人、ITエンジニアだ！！）」**
全女の子キュン死です。

# まとめ
最後の決め台詞はもちろん
**「俺という、ワイル カッコ トゥルー カッコトジル ナミカッコ ナミカッコトジルの中に入ってみる？」**
**「抜け出せねえよ？」**
以上、健闘を祈る。

追記
**女の子「break;」**
と言われたら脈なしなので帰りましょう。
【小ネタ】S3のライフサイクルルールで、非現行バージョンの保持するバージョン数の設定ができない...？？

# はじめに
先日バージョニングを有効化しているS3で以下のライフサイクルルールを設定したところ...
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3491064/0807183f-b2da-6cf0-535d-dc80338faa26.png)


ルールの作成時にエラーが出ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3491064/d2570365-0e4a-9735-4836-284292936396.png)



直訳すると以下の通りですが、
NewerNoncurrentVersionsとは一体なんだろう...。
```:翻訳
'NewerNoncurrentVersions' for
NoncurrentVersionExpiration action must be a positive integer
↓
NoncurrentVersionExpiration アクションの
「NewerNoncurrentVersions」は正の整数である必要があります
```

# 結論
「NewerNoncurrentVersions」＝「保持する新しいバージョンの数」です。
なので非現行バージョンのオブジェクトは1バージョンも保持しない、という場合は保持する新しいバージョンの数を空欄で作成しましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3491064/be0b8079-8d46-070b-e026-e3f2086ab3f5.png)

ちなみに公式ドキュメントでは以下の記載があり、
AWSとしては保持する新しいバージョン数はオプション設定なので、
そもそも値を入力する必要がないということなのでしょう...。
> オプションで、[Number of newer versions to retain] (保持する新しいバージョンの数) に値を入力して、保持する新しいバージョンの数を指定できます。
- [バケットのライフサイクル設定](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)
学習意欲の変遷：外発的動機づけから内発的動機づけへの軌跡

# 1.はじめに
どうも、ARIの名古屋支社に勤務している愛知県民こと、
新藏（にいくら）と申します♪
(/・ω・)/

Qiitaで面白そうなイベントがやっていたので、参加ボタンをポチりました。
https://qiita.com/official-events/e9f582bec72278130942

「失敗を乗り越えた経験」ということで、
**6年前の自己学習に対する考え方がしくじっていたので、
そこから6年を経て、どのように考え方が変わったのかを記事にしたいと思います！**

やる気はあるがなかなか勉強できない方、若手の方の参考になれば幸いです。
(*^^)v

# 2.学習意欲の変遷

## 2.1.新卒時代(2018年~2019年)
6年前に私はARIに新卒として入社しました

・業務が忙しい（残業20~30時間くらい）
・家から現場が遠い（片道90分くらい）
・何のために勉強するのかよく分からない

というような状態で、特に「何のために勉強するのかよく分からない」については
ARIからは新卒時の課題として資格2つ（ITパスポートやSAA等）の取得をお願いされていました。

「取らないとな」という気持ちはあるのですが、**「何のために取るのか」が整理できていなかった**ので、
勉強自体があまり進んでいませんでした。

**現場に出てからはほとんど自己学習できていなかった**・・・気がします。

:::note info
新卒の研修の時には、どうにか気合でITパスポートを取得しました。
:::

## 2.2.若手時代(2019年~2021年)

2年目辺りにこのままだとちょっと良くないな・・・と感じたので、
毎年提出している人事考課表にて、「CLFの資格を取得します」や「半年で50時間勉強します」等の目標を記載して、
勉強せざるを得ない状況に自分を追い込みました。

達成できないと給与や賞与に影響するので、
**自分に負荷をかけながらも勉強を進めていました。**

精神的に病むまではいかなかったのですが、そこそこ大変だった記憶があります。
3,4年目は上記の人事考課を利用した勉強を続けていました。

:::note info
この時期にはCLFの資格を取得しました。
:::

## 2.3.中堅時代(2021年~2023年)
忘れもしない**2021年8月13日、私のベビーが産まれました！**
10~12月は育児休業だったのですがそんな中で
ベビーが目で物を追うようになったり、寝返りができるようになったりして、
圧倒的な成長を見せつけられました。

そんな中で
「自分はこのままで良いのか？」「ベビーに恥じない人生なのか？」
と考えるようになり、1週間に最低3時間は勉強するようにしました。

この時期は**あまり勉強自体は苦にならず、自分のペースで粛々と勉強できていたと思います。**

:::note info
この時期にはSAA,AZ900,DP900の資格を取得しました。
:::

# 3.動機づけ
さて、2章の体験を振り返ると、私は学習意欲が変化していると感じました。

なぜ変化したのかを考えると、学習の際の動機が変化していることに気づきました。

そこで動機づけについて調べたところ、
**動機づけには外発的動機づけと内発的動機づけの2種類がある**ことが分かりました。

本章では、それぞれの動機づけの違いと学習意欲に与える影響について説明します。

## 3.1.外発的動機づけとは
> 外発的動機付けとは、報酬や評価、罰則や懲罰といった、外部からの働きかけによる動機付けを意味する言葉です。

具体的には「お金がもらえるからやる」「上司に怒られるから（怒られないように）やる」
の様な動機づけとなります。

**内容がシンプルなので、短期的な学習意欲を発生させることはできる様です。**
しかし、長期的には難しいようです。

## 3.2.内発的動機づけとは
> 内発的動機付けとは、物事に対する強い興味や探求心など、人の内面的な要因によって生まれる動機付けを意味する言葉です。

具体的には「技術を極めたいからやる」「楽しいからやる」という様な動機づけとなります。

**外発的動機づけによる学習よりも、本人の成長やアウトプットのクオリティが高まる**
らしいのですが、人により何を内発的動機づけとするのかが違うので、
その点はなかなか難しいと感じました。

:::note info
次の記事では内発的動機づけを生む方法について書く・・・予定です！
(｀･ω･´)ゞ
:::

参考
https://mitsucari.com/blog/intrinsic_extrinsic/
https://stretch-cloud.lmi.ne.jp/column/0040

# 4.外発的動機づけから内発的動機づけへの軌跡

最後にまとめとなりますが、私の場合は学習する動機が以下の様に変化しました。

|時期|動機|動機づけの種類|
|---|---|---|
|新卒時代(2018年~2019年) | できない理由をあれこれ言って、<br>勉強できていない |-|
|若手時代(2019年~2021年) | 毎年の評価が下がるから |外発的動機づけ|
|中堅時代(2021年~2023年) | ベビーに誇れる人間になるために |内発的動機づけ|

# 5.おわりに
ここまで読んで下さり、ありがとうございます！！！
(^^)

今回はポエム的な内容でしたが、悩んでいる人の助けになれば幸いです。
次は何かしら記事にします♪

後、「軌跡」で思い出したのですが・・・
**閃の軌跡はとても面白いゲームなので、みなさんプレイしてみてください！**
(:3_ヽ)_
【Mac】スクリプトを定期的に実行する方法


## 設定方法

用途ごとに設定ファイルを以下の場所に保存します。
| 場所                                   | 用途                                           |
| :------------------------------------- | :--------------------------------------------- |
| `~/Library/LaunchAgents/<Label>.plist` | ユーザー単位のエージェント                     |
| `/Library/LaunchAgents/<Label>.plist`  | 管理者が提供するユーザーごとのエージェント     |
| `/Library/LaunchDaemons/<Label>.plist` | 管理者によって提供されるシステム全体のデーモン |

以下のコマンドを実行すると定期実行されるようになります。

```zsh:ターミナル
launchctl load /path/to/your.plist
```

以下のコマンドを実行すると定期実行されなくなります。

```zsh:ターミナル
launchctl unload /path/to/your.plist
```

## サンプル

### 30秒ごとにsample.shを実行

```xml:~/Library/LaunchAgents/sample.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>sample</string>
  <key>Program</key>
  <string>/Users/mofu/script/sample.sh</string>
  <key>StartInterval</key>
  <integer>10</integer>
  <key>StandardOutPath</key>
  <string>/Users/user_name/script/sample.out</string>
  <key>StandardErrorPath</key>
  <string>/Users/user_name/script/sample.err</string>
</dict>
</plist>
```

### 毎日3時にsample.shを実行

```xml:~/Library/LaunchAgents/sample.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>sample</string>
  <key>Program</key>
  <string>/Users/user_name/script/sample.sh</string>
  <key>StartCalendarInterval</key>
  <dict>
      <key>Minute</key>
      <integer>0</integer>
      <key>Hour</key>
      <integer>3</integer>
  </dict>
  <key>StandardOutPath</key>
  <string>/Users/user_name/script/sample.out</string>
  <key>StandardErrorPath</key>
  <string>/Users/user_name/script/sample.err</string>
</dict>
</plist>
```
【Unity】EditorWindowのCreateGUI()とOnGUI()は何が違うか

# 経緯
Create -> UI Toolkit -> Editor Windowで生成されたコードでCreateGUI()が使われていた
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/a577dd8b-3b6e-7af9-1853-2c1d2a36efc5.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/f5cce096-3988-5901-c800-dbb80aa2c0f3.png)

いろいろな記事を見ているとCreateGUI()とOnGUI()の使い方が似ていたので調べてみた

ドキュメントを読んでも、使い方が全く一緒だった
 - CreateGUI
https://docs.unity3d.com/ja/2021.3/ScriptReference/EditorWindow.CreateGUI.html
 - OnGUI
https://docs.unity3d.com/ja/2021.3/ScriptReference/EditorWindow.OnGUI.html

# 結論
それぞれ呼ばれるタイミングが違う
```
0. ウィンドウを開く
1. Reset()
2. Awake()
3. OnEnable()
4. CreateGUI()
5. OnGUI(), Update() ※繰り返し
```
OnGUI()とUpdate()の呼ばれる順番を完全に特定することが出来なかったが、Unityのライフサイクルやログを出してみた結果、Update() -> OnGUI()の順番で呼ばれているようだった

# 注意
#### CreateGUI()の呼ばれるタイミング
https://forum.unity.com/threads/custom-editorwindow-creategui-called-before-awake-onenable-when-opening-project.1085909/
上記フォーラムで、Unity起動時に最初からウィンドウを開いていた時と、手動でウィンドウを開いた時でAwake, OnEnable, CreateGUIの呼ばれる順番が違うという報告がある
CreateGUIよりもAwake, OnEnableの方が早く呼ばれるという前提でコードを書かないほうがいい

#### OnGUI()の呼ばれるタイミング
OnGUI()は毎フレーム呼ばれるわけじゃない
マウスをホバーしたときや、キーボードを操作したときなど、何かイベントがあった時のみ呼び出されていた
これはおそらくほとんどのOnGUI()呼び出しはGUIView.Repaint()内から行われているからだと推測している
(GUIView.RepaintはMethodImplになっており、先が読めなかった)
一般的にOnGUI()を毎フレーム呼び出したい需要は少ないはずなので、もし毎フレーム呼び出したかったらUpdate()のなかでRepaint()を呼ぶこと

ちなみに、OnGUI()の回数を減らしたかったらEditorWindow.wantsLessLayoutEventsをtrueにするといい

#### Time.framecountは使わないほうがいい
再生モードの時、Time.framecountは期待通りの挙動をする
毎フレームインクリメントされ、一時停止するとインクリメントがストップする
しかし、再生モードでないとき、Update()は毎フレーム呼ばれているのに、Time.framecountはインクリメントのタイミングが変わる
正確なタイミングは分からないが、入力(マウスやキーボードのイベント)があった時にインクリメントされているようだった
Mulesoft DataWeave Playground: データ変換のマスターシェフへの道

# はじめに
DataWeave Playgroundは、ブラウザでDataWeaveを実行するツールということで、中にいくつか便利な機能を紹介していきたいと思います。

DataWeave Playgroundすべての機能(HP)：
https://developer.mulesoft.com/tutorials-and-howtos/dataweave/learn-dataweave-with-the-dataweave-playground-getting-started/

# import&export
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3343120/d739ddd8-ccf8-3bae-36be-1898507dda50.png)

**Export：** Playgroundで生成したコードを.zipファイルにエクスポートし、Visual Studio Codeに移動したり、コードを試すために他の人に共有できます。

**Import：** .zipファイルを取り出してPlaygroundでコードの編集に役立ちます。

# Script Explorer
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3343120/9bc40901-026d-ad58-76f9-9a33b0bc5e7c.png)

ここでは、スクリプトで使用できる.dwl（DataWeave Language）ファイルを見ることができます。これは、モジュールで関数を作成し、importディレクティブを使ってメインスクリプトで使用するのに便利です。

# LOG VIEWER
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3343120/cd24621e-179b-a1a1-e7c3-ea46d29e0875.png)

ここではlog()関数の出力を見ることができます。

# API REFERENCE
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3343120/bc8ab668-b044-0a94-8f8a-0953a5bd2abd.png)

ここでDataWeave APIリファレンスを参照し、任意の関数を参照することができます。

さらに、ブラウザの検索機能（**CTRL+F**または**CMD+F**）を使って、APIリファレンス内の関数を検索することができます。

# 終わりに

最後までお読みいただき、本当にありがとうございました。
DataWeave Playgroundに関する、すこし役に立ったら嬉しいです。フィードバックが頂きましたら幸いです。
The Teams 5つの法則を読んで

# チームとは
目的をもつことで、グループからチームになる。
目的には3種類ある。
1.行動目標
2.成果目標
3.意義目標
どれがいい、悪いではなく、それぞれメリットデメリットがある。
意義目標は、あまり変わらない。
成果目標、行動目標は、状況にあわせて変化させるべき。

多様性は、あればあるほどいいわけじゃない。
メンバーの連携が少ないチームであれば、同じような能力を持った人を集める必要がある。
メンバーの連携が多いチームであれば、多様なメンバーがいたほうがいい。

コミュニケーションは多ければ多いほどいいわけではない。
適切なルール設定をして、コミュニケーションコストを下げることが有効。

# 人を理解する
人を動かすのは感情。
相手を知らなければ伝わらない。
水平質問　経験に関する質問
垂直質問　感覚に関する質問　　

モチベーションタイプとポータブルスキルを把握して、人にあったコミュニケーションをとる。

モチベーションタイプ
アタックタイプ達成支配型欲求
レシーブタイプ貢献調整型欲求
シンキングタイプ論理探求欲求
フィーリングタイプ審美創造型欲求

ポータブルスキル
外交的なスキル
内向的なスキル


# 心理的安全性の作り方
無知の不安
　そんな事も知らないのか、と批判しない
無能の不安
　そんなこともできないのか、と批判しない
邪魔の不安
　今の言う意味あった？と批判しない
批判的だと思われる不安
　反対意見を出すことを批判しない

# まとめ
コミュニケーションは大事
SQLを組むとき気をつけること

# 基本
SQLは2種類に分けられる。
検索か、検索でないかだ。

パフォーマンスについて気にするのは、ほぼ検索のときだけ。
数百件のデータから検索するときには問題にならないSQLも、数万、数十万とデータ量が増えると重すぎて動かなくなる。

データ量が増えても、検索の負荷はそれほど増えないSQLにすることが必要。

そのためには、インデックスを使うことがポイントとなる。

インデックスというのは、図書館の[分類法](https://ja.m.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E5%8D%81%E9%80%B2%E5%88%86%E9%A1%9E%E6%B3%95)のような仕組みで、データを木構造に順番どおりに並べて、データの位置と検索速度が比例しないようにできる。

50番目だろうが、5千兆番目だろうが、同じくらいの速度で検索できるようになる。
(もちろん、全体のデータ量が増えれば検索時間も増える。対数的に。でも、B＋木の構造であれば枝の深さが等しい、平衡木なので、何番目かには比例しない)

# 気をつけること
### group by, sort by
これらをインデックスの貼られてないカラムに対して行うと、重くなる原因になる。 

### JOIN
JOINの結合条件にインデックスが貼られていないカラムを使用すると、重くなる原因になる。
また、一般的に、対象のレコード数が小さいテーブルを先に結合するほうが、検索対象となるレコード数を節約できる。

### 後方一致検索
後方一致ならインデックスが使えるが、前方一致だと使えないので注意。

### 関数を使用する
検索値のほうに関数を使用するならいいが、カラムのほうに使用してしまうとインデックスが効かない。

### UNION 
unionはソートして重複行を削除してくれる。
その分パフォーマンスが悪いことがある。
重複行を取得してもよければ、union allを使用しよう。

### N＋1問題
関連テーブルからデータを取得するようなときに、SQLがN＋1回発行される有名な問題。
1回分は主テーブルからN個のリストを取得するとき。
N回分は、関連テーブルのデータを、主テーブルのレコード数分繰り返して取得するとき。
Joinで一度に取得することが望ましい。
（とはいえ場合によっては適宜もってきたほうがいいこともあるし、ORMではLazy Loadといってあえて一度に持って来ない設定もできることが多い。）

### サブクエリー
サブクエリーを使う場合は、JOINで使用することが多いと思う。
その場合、できるだけサブクエリー内で取得される件数を減らしたほうがいい。
例)
```
SELECT * FROM A INNER JOIN (SELECT id,created_at FROM B) as sub ON A.b_id=sub.id WHERE b.created_at > '2022-10-10'
```
よりも
```
SELECT * FROM A INNER JOIN (SELECT id FROM B WHERE b.created_at > '2022-10-10') as sub ON A.b_id=sub.id WHERE b.created_at > '2022-10-10'
```
のほうがいい。
 
# まとめ
インデックスには、メモリーを使うとか、登録処理のたびに作り直すオーバヘッドが生じるなど、デメリットもあるので、要らないなら作らなくていい。
また、DBがどのインデックスを使用するかは、統計的に決まったりもするので、パフォーマンスは理論上だけでは決まらない。
実際に測ってみたり、実行計画をみたりするのが大事。
データベースパフォーマンスアップの教科書を読んで

# データの保存構造
- heap organized table
- index organized table　
Heap organized tableは、順序のないテーブル。登録は早いが、検索は遅い。そのため、ログデータの保存など、検索の必要がない場合にしか使われない。
Index organizbd tableは、順序があるテーブル。インデックスも使えるので、一般的なアプリケーションではこちらを使用する。


# インデックスの仕組み

インデックスの仕組みは、本の目次と似ている。
本から情報を探すとき、目次がないと、全てのページを見つかるまで探すことになるが、目次があれば探す範囲を少なくできる。

データベースも、インデックスを使うと、データが見つかるまでに探すデータの数を減らせる。

## インデックスのアルゴリズム

### btreeインデックス　
b＋treeの木構造となってる。
ルートノード、ブランチノード、リーフブロックで構成されていてる。
ルートノードは一つだけで、そこからブランチノードが生え、ブランチノードからまた別のブランチノードが生える。
最後にリーフブロックがくっつく。

実際のレコードはリーフブロックにだけあり、ルートノード、ブランチノードは他のノードへの参照と検索用のキー値をもってる。

ルートノードはだいたい真ん中くらいの値をもってて、それより小さい値は左のブランチノードへ、それより大きいものは右のブランチノードへ格納されてるので、大小比較をしていくと目的のデータが格納されてるリーフブロックに辿り着ける。

一個のデータをとるだけなら、全体のデータ数が増えても検索時間はほとんど増えない。
いわゆる、O(logN)の計算量となる。

_ bitmapインデックス
btreインデックスはカーディナリティの低いデータに向いてないが、こちらは逆にカーディナリティの低いデータに向いてる。
データをbit単位の値の配列形式で保存する。
例えば、男を1,女を0とすると、
1.男
2.男
3.女
は、110となる

# オプティマイザ
ルールベースオプティマイザとコストベースオプティマイザがある。
今はほとんどコストベースオプティマイザ。
全体結果最適化を目指す。

## オプティマイザの動作
1.クエリの解析
2.暫定的な実行計画の作成
3.実行計画のコストの算定
4.もっともコストの低い実行計画を選択

# インデックスの戦略
複合インデックス
　インデックスを複数カラムのセットで設定しておくやり方。
　予めソートされてるのでパフォーマンスはいいが、柔軟性はない。
　順番も意味があり、最初のカラムの検索でインデックスが使用されない範囲検索などをする場合はパフォーマンスがでない。
最初のカラムだけが検索される場合はインデックスが使えるが、2番目以降のカラムだけが検索される場合は、インデックスが使用されないこともある。
マージインデックス
　個別のインデックスが設定された2つのカラムで検索するときに使われる。
　複合インデックスにしておくよりはパフォーマンスに劣ることがあるが、柔軟性があり、インデックスのサイズも小さくてすむ。
どのような複合インデックスを設定し、どこに単体のインデックスを設定するかは、カラムのカーディナリティ、アクセスの量、データの量、よく使われる検索条件を考慮して決める必要がある。


# まとめ
データベースは奥が深い。
【読書感想文】相手に説明できない人はギャルである。【3時間で頭が論理的になる本】

ご無沙汰しております。

今回は出口汪さんのご著書、「[3時間で頭が論理的になる本](https://www.amazon.co.jp/3%E6%99%82%E9%96%93%E3%81%A7%E9%A0%AD%E3%81%8C%E8%AB%96%E7%90%86%E7%9A%84%E3%81%AB%E3%81%AA%E3%82%8B%E6%9C%AC-PHP%E6%96%87%E5%BA%AB-%E5%87%BA%E5%8F%A3-%E6%B1%AA/dp/456976584X)」で特にお客様とコミュニケーションをとるうえで大切な教えが詰まっていると感じたため、これを読んでいるあなたにも共有したいと思い、筆を執っています。


出口さんは教育や書籍出版のお仕事をされている方で、以前は東進ハイスクールの現代文講師としても働かれていたみたいです。

そんな方の本ですから、とても分かりやすく、まさしく論理的に書かれています。
出口さんの公式サイトもあるみたいなので、気になる方はぜひ覗かれてください！
→https://suiohsha.co.jp/

相手に説明できない人がギャルだと思う理由は最後にお話しいたします。


それでは本編へ！

# 論理とは
そもそも皆さん論理とは何でしょうか？
もしよければコメント頂けますと幸いです。

私は人(自身を含む)を説得するための考え方だと思っています。



人が納得するには直感と論理が揃っていないと成立しませんが、
理解(説得)するには論理でつじつまがなんとなく合っているだけで成立します。

「なんとなく」というのは、説得する対象の知識・経験によって
反論や質問の深さが変わるため、相手の論理の破綻に気づけないことも
往々にして起きることを加味して記述しています。


では出口さんはなんとおっしゃっているのか。

出口さんは、
「自分の感覚とは違う他者を感じて初めて現れるもの」
だとおっしゃっています。


これを聞いて、私の深堀りが浅すぎたことを実感しました(;^ω^)
人を説得するための考え方も結局、「自分の感覚とは違う他者を感じて初めて現れるもの」
のため、私は出口さんが掘って柔らかくなった穴をサクサクっと掘り返していただけでした。


こういったことをお手ごろな値段で知ることができる本というのは、
やはりとても魅力的なものだと改めて感じます。

さて、話が脱線してしまいました。
話を戻して、出口さんの主張をもう少しつぶさに見ていきたいと思います。


# 自分の感覚とは違う他者を感じて初めて現れるものとは？
最初読んだときは意味がよくわかりませんでした。

ただ、そのあとに出口さんが挙げている例を聞くと
スッと腑に落ちました。

それが「ギャル」です。

ギャルとあまり仲良くはなかったので、想像で話すことをご了承ください。

ギャルって「ぴえん」や「好きピ」といった、
方言よりも難しい言語で話しています。

また、すごいもおいしいもひどいもやってしまった…という感情もすべて
「ヤバい」という言葉に集約されているイメージです。

このような言葉って、友達や同年代の人にはいうかもしれませんが、
親戚のおじさんには言いませんよね。


なぜ言わないのかというと、自分のギャルの感覚とは違う他者だからです。

親戚のおじさんにも言ってしまう場合はギャルの語彙力が皆無なのか、
自分の使っている言葉が相手に伝わらないことを自覚できていないです。

なぜかギャルに辛口コメントしてしまいました…笑


しかしこういったことってビジネスの場面だと、
マジメな顔をしてギャルみたいなことをしていることがよくあります。


相手の知識量に合わせて話さないと相手に伝わらないどころか、
相手からの質問の応酬になるか頼んだ仕事を完遂できないなんてことがザラに起こりえます。


自分の感覚とは違う他者であるからこそ論理が生まれ、
論理があるからこそ相手に説明することができます。


他者の感覚に寄り添わずに論理的に説明しても、
相手に伝えるという目的を達成するにはかなりの遠回りになってしまいますよね。

これって、ギャルが自分の知っている言葉だけで話して
相手によく伝わっていない状況と本質的には何も変わらないと思っています。


こういった背景から、私は
「相手に説明できない人はギャルである。」
と考えています。


# 最後に
この本の感想は以上にするのですが、この「[3時間で頭が論理的になる本](https://www.amazon.co.jp/3%E6%99%82%E9%96%93%E3%81%A7%E9%A0%AD%E3%81%8C%E8%AB%96%E7%90%86%E7%9A%84%E3%81%AB%E3%81%AA%E3%82%8B%E6%9C%AC-PHP%E6%96%87%E5%BA%AB-%E5%87%BA%E5%8F%A3-%E6%B1%AA/dp/456976584X)」は
他にも論理的思考になるための方法や考え方まで、論理的思考の論理を詰め込んだ本です。

出口さんもおっしゃっていて、私もとても共感できる言葉があるので、
それを最後に紹介します。

:::note info
"おそらく論理を意識する人は、まだ論理的ではないのではないでしょうか。私は講演などでは話したいことを話したいようにしゃべります。別段論理を意識してしゃべることはないのですが、私の話が分かりやすいと感じるならば、その話に筋道が立っているからであり、そのような私は論理に習熟しているといえます。"
:::


この文章を書くことで、私がギャルであるとバレてしまわないことを祈るばかりです。
継承関係をどのようにDBの物理設計に変換するか問題

データベーススペシャリストの勉強中、ふと疑問に思ったので簡単に調べてみました。

# やりたいこと
- 概念データモデル中で継承関係にあるエンティティを、物理設計に変換して`CREATE TABLE`する
    - スーパタイプ「動物」、サブタイプ「犬」、サブタイプ「猫」をどのようにテーブルにするか

# 1. 考えたい継承関係
今回は、以下のような継承関係を考えてみる。

```mermaid
classDiagram
    class animal {
        - int id
        - String name
        - int age
    }
    
    class dog {
        - int height
        - String color
    }

    class cat {
        - int tailLength
        - float weight
    }
    
    animal <|-- dog: is-a
    animal <|-- cat: is-a

```
"`dog` is an `animal`"、 "`cat` is an `animal`"なので、上のクラス図のような継承関係（汎化と特化の関係）が成り立ちます。ここで、`animal`のサブタイプは`animal`のフィールド（属性）を継承していて、`dog`や`cat`のインスタンスには、`id`、`name`、`age`といったフィールドがあることに注意します。

# 2. 関係スキーマ記述
以下のような感じとなります。下線が引いてある属性は主キー。

 動物 (<INS>動物コード</INS>, 名前, 年齢)
    いぬ (<INS>犬コード</INS>, 体長, 色)
    ねこ (<INS>猫コード</INS>, しっぽの長さ, 体重)

# 3. たどり着いた物理設計

```mermaid
erDiagram
    animal {
      int animal_id PK
      varchar animal_name 
      int age
    }

    dog {
      int dog_id PK "FK"
      int height
      varchar color
    }

    cat {
      int cat_id PK "FK"
      int tail_length
      decimal weight
    }

    animal ||--o| dog: "is-a"
    animal ||--o| cat: "is-a"

```
**クラステーブル継承**(**Class Table Inheritance**)という考え方を用いて、物理設計を上記のように記述します。親クラスに「子クラスで共通となるようなカラム」を持たせ、子クラスに「親クラスの主キーを参照するような主キー兼外部キー」、「子クラスに固有なカラム」を持たせるのが特徴です。

親テーブル`animal`にすべての動物のレコードを格納し、それぞれの子クラスにわんちゃんとねこちゃんを格納していくと以下のような例になります。

**animalテーブル**
|animal_id|animal_name|age|
|---|---|---|
|1|ハナ|3|
|2|ミケ|5|
|3|ポチ|2|

**dogテーブル**
|dog_id|height|color|
|---|---|---|
|1|60|茶色|
|3|55|白色|

**catテーブル**
|cat_id|tail_length|weight|
|---|---|---|
|2|30|4.5|
PF作成：３日目

３日目。予定通り進んではいるので順調だと思う。
昨日提出したテーマ課題、実装機能リストが合格できた。よかった。

## 進捗
- テーマ課題、実装機能リスト合格
- WBS清書し提出。合格
- ER図作成し、終了。メンターさんに質問して大丈夫そうだと評価貰った。（https://app.diagrams.net/#G1LpCHG1F5TT9oZYnV6Jzk4WfeJzKSLA8Y）
- テーブル定義書作成し、終了。メンターさんに確認してもらって平気そうだった。（https://docs.google.com/spreadsheets/d/1-BZKaTNKeX3Ml3q61Mv8g7hDEjQ9Mvlcb6R2ypmWR6w/edit#gid=692918718）


## 学んだ事
### 【WBS】
- WBSは実装機能リストを元に作成順に列べ、そこから肉付けしていくような形で作成すると楽にできる。ここでの作成順は最初は機能ごとに作成したが、メンターさんが必要順にするといいとアドバイスをくれた。<br>例えば、管理者機能、会員機能、投稿機能、会員退会機能などの順。最初は管理者機能、会員機能、退会機能、投稿機能などの順で作成しようとしていた。
- 機能作成からページを作成するなどの順がよい。
- アプケーションを実装するときはコントローラーやモデルは一気に作らない方がいい。必要項目事に一つずつ作成した方がエラー解決が楽。
- モデルを一つ作成したらバリデーション、フラッシュメッセージの設定も同時にする。そうすると何のエラーなのかわかりやすくなる。わからなければせめて空のバリデーションが文字数制限くらいはつけた方がいい。
- 管理者側とユーザー側が同じ投稿をすることがある場合はビューはそれぞれ別で使用して、中身の機能を部分テンプレートで作成するやり方がいい。
### 【ER図】
- ER図はいいねモデル、フォローモデル、コメントモデルは中間テーブルなので多対多の関係。ここでの多対多は中間テー部を介さないでの関係の話。中間テーブルとのリレーションは１対N。
- いいねの対象が複数の場合は２個くらいならテーブルを複数作ってしまった方がいい。それ以上ならば別の方法があるが、今回は使用しないためまだよくわかっていない。
- カラム名は単数系、複数形がはっきりしているもので名詞であれば何でもいい。逆に動詞や単数系、複数形がはっきりしていないものは間違った返り値になる場合があるので注意。
### 【テーブル定義書】
- 電話番号や住所など２つ以上情報が入るような場合同じテーブル管理は出来ないので新しくテーブルを作成する必要がある。
- DEFAULTはenumを使用する場合絶対にないとダメだと思っていたが、なくても平気。状況によって使い分けよう。
- NOT NULLもデータがからでもいい場合はNOT NULLはいらない。
- NOT NULLをつけては行けない場合がある。今回のように神社・お寺の情報を管理者もユーザーも投稿できる場合、神社・仏閣にユーザーIDをつけないと行けないが、管理者から投稿するとユーザーIDはないためNOT NULLをつけてはいけない。


## 明日の予定
そろそろ下準備は終わりにしたい。<br>明日はワイヤーフレーム「draw.io」 を使用して完成させる。UI Frowも同様に終わらせたい。メンターさんに質問できないので大変かもしれない。とういかここがおそらく一番苦手な部分だろうから時間がかかりそう。明日はバイトもあるから頑張っていこう！
二重軸グラフのレイヤー操作（前面・背面）

## 前提
Tableauで二重軸グラフを作成した際、左のメジャーが前面・右が背面となる。

以下のような二重軸を作成した際、**面積の小さい線グラフを前面に配置した方が効果的**なのに対して、線グラフが背面・棒グラフが前面となっている。
![スクリーンショット 2023-08-03 22.40.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1537142/fb241255-000d-67f7-f6e9-1a531a2ac320.png)

背面・前面を入れ替えたい際、メジャーの位置を入れ替えればグラフの順序自体は簡易に解消される。
これが直感的にまず操作する人が多いのではないだろうか
しかし、この場合には軸の配置も入れ替わる。
![スクリーンショット 2023-08-03 22.44.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1537142/12ce8c95-28e6-6b96-7845-b23c8b9ce4db.png)

今回は**軸の位置は入れ替えず、グラフのみ背面・前面を別途設定する方法**を記載する

## 方法
軸を選択し右クリック
「マークを背面に移動」を選択
![スクリーンショット 2023-08-03 22.11.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1537142/d49d9695-ce9d-3916-f8db-d26a7116c4f3.png)

この方法によって軸の位置は動かさず、グラフのレイヤー位置（前面・背面）のみ変更できる。
![スクリーンショット 2023-08-03 22.47.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1537142/d7d0bb91-ab69-a956-7a2a-6af3aee566e6.png)
PLATEAU SDK Toolkitsでビルの窓に明かりを灯す

PLATEAU SDK Toolitの使って、PLATEAUのモデルのビル群の窓に明かりを灯すやりかたです。
![anim.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/3c43a15d-dff3-cbb8-a25c-773bbda159fa.gif)

# 前提
* Windows11
* Unity2022.2.17
* PLATEAU-SDK v1.1.6
* PLATEAU-SDK-Toolkits-for-Unity v0.1.0

# 手順
## インストール手順
1. Unity Version 2021.3.27f1(LTS)により新らしいバージョンでUnityプロジェクトを作成します。このときURPかHDRPを選択している必要があります。
1. PackageManagerからAdd package from git URL...を選択し、`https://github.com/Project-PLATEAU/PLATEAU-SDK-for-Unity.git`を設定して、Addボタンを押します。
1. https://github.com/Project-PLATEAU/PLATEAU-SDK-Toolkits-for-Unity/releases/tag/release から最新のtgzをダウンロードします。
1. PackageManagerからAdd package from tar ball...を選択し、3でダウンロードしたファイルを選択します。
1. インストール後ポップアップが上がってきたらYesを押してUnityEditorを再起動させます。

## PLATEAUのモデルインポート方法
1. PLATEAU -> PLATEAU SDKを選択します。
1. インポート元をサーバに変更します。
1. 都道府県、データセットを選択します。
1. 範囲選択ボタンを押します。
1. Sceneウィンドウ上に表示されているオレンジ色の四角を利用してインポートしたいエリアを選択し、決定ボタンを押すします。
![2023-08-03_18h58_28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/48763b20-71ff-499e-ab49-4f41b59fb343.png)
    1. 複数個所インポートするとUnity自体がかなり重くなり、保存に5分とか待たされるようになります。最初は1つの区画でやりましょう。 
1. モデルをインポートボタンを押します。
1. Hierarchyに `インポート中です...` が表示されるので、待ちます。
1. 終わるとHierarchyにロードされたモデルがロードされます。

## Rendering Toolkitを使って窓に明かりを灯す
1. PLATEAU -> Rendering Toolkitを選択します。
1. 自動テクスチャ生成ボタン（①）を押して、Scene画面で窓を作りたいオブジェクトを選択し、テクスチャ生成ボタン（②）を押します。
![2023-08-03_18h51_53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/4abe76aa-f935-603c-2a47-dd0eeae6e4dc.png)
1. 環境システムの設定ボタン（①）を押して、Time of Dayに0.9を設定して夜にします。
![2023-08-03_18h53_20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/55891eb2-eb27-7af0-7507-ed1a4fb3f28f.png)

# 蛇足
ARCore Geospatial Creator for Unityのほうがぱっと見は良く見えるかもしれません。。。
[こちら](https://github.com/machidyo/geospatial-creator-in-unity-sample)にAPIKeyを設定すれば利用できるリポジトリがあるので、良かったら試してみてください。
![2023-08-03_19h29_27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/fe7d56e6-217f-fbbd-00ff-b116dc922637.png)
Pythonのお勉強も兼ねて、競馬予想AIを作ってみる 【Part1】

Qiita自体が初めてだけども、Qiita自体の勉強も兼ねて、競馬予想AIを作る過程を書いていけたらと思う。

# 開発環境について
まず開発環境について、今回はWindows端末がまだ準備できておらず、
家にMacでプロトタイプを作って、動作の検証をしているうちに、
Windows端末を準備し、そちらを本環境とする予定である。

プロトタイプを作るMacの開発環境は以下。
||内容|
|:-----:| :-----:|
|機種|MacBookPro(2019年 13インチ)|
|CPU|Intel Core i5-8257U|
|RAM|LPDDR3 16GB|
|グラフィック|Iris Plus Graphics 645|
|Python|3.1.1|

windows端末が準備できたらまたここに追記しときます。

# やりたいこと
今回やりたいこととしては、大きく以下の2つ。
<dl>
<dt>1. TensorFlowを使って、競馬の予想AIを作ってみる</dt>
<dd>大学時代に使っていたけど、もう忘れてしまったPythonを思い出しがてら、<br>
    Tensorflowの勉強がてら、webスクレイピングの勉強がてら、<br>
    趣味の延長で競馬の予想AIを作ってみようかと思っています。
</dd>
<dt>2. GitHubの使い方を学ぶとともに、ソース管理をしてみる</dt>
<dd>今までSEとして、ぼちぼちと既存の機能の改修とか開発もやってきたものの、<br>
    ソース管理らしいソース管理をやったことがないということもあり、<br>
    それの勉強もしてみたいと思っています。
</dd>
</dl>

# 終わりに
更新頻度高くないかも知らんけども、ぼちぼちと書いてゆくますです。
次の更新では、どういう仕様にするかとかを決めていけたらなーとか考えとります。

以上。
【Java】Springで見かけるDI方法の違い（コンストラクタインジェクション vs @Autowired）

日頃の業務でなんだかんだJavaを書きますが、良くわかっていない部分があったのでその解消。

Springフレームワークを使っていますが、他のクラスを利用する際にDIしますよね。
書き方としては、@Autowiredを利用する場合とコンストラクタを利用する場合があると思います。

皆さんはどちらでしょうか。
私が担当しているアプリでは後者のコンストラクタを利用する方が主流です。
せっかくなのでこの違いを整理してみました。

# コンストラクタを利用する書き方
HogeValidatorクラスをDIする際こんな感じで書きます。
```Main.Java
@Service
public class HogeServiceImpl implements HogeService {
    
    // ① インターフェースのfinal宣言
    private final HogeValidator hogeValidator;

    // ② コンストラクタでのDI
    public HogeService(HogeValidator hogeValidator) {
        this.hogeValidator = hogeValidator;
    }

    @Override
    void doHoge() {
        hogeValidator.validate();
        ...
    }

}
```
①ではinterfaceをfinalを使ってクラス変数として宣言します。
②のコンストラクタ部分では、HogeValidatorをDIします。

## Autowiredを利用する際の書き方
```Main.Java
@Service
public class HogeServiceImpl implements HogeService {
    
    // Autowiredを用いたDI
    @Autowired
    private HogeValidator hogeValidator;

    @Override
    void doHoge() {
        hogeValidator.validate();
        ...
    }

}
```

## メリット
### コンストラクタ 
1. 他クラスとの依存関係が明白に
・一箇所に纏まる、見やすい
2. メンバ変数をfinalで宣言可能
・変数がイミュータブルになり、オブジェクトの安全性が向上する。
(final宣言ができる、ということ)
・スレッドセーフになる
・必ずメンバ変数がインスタンス化されてからコンストラクタが走る
　
3. 依存関係が見つからない場合、コンパイルエラー
・早期にバグ修正できる
・逆に依存関係を環境変数によって切り替えができる
（本番では本番用の実装クラス、テストではテスト用のクラスを用いる、というような切り替え）

### Autowired
1. 1行でDIできるのでコードが完結
・楽で良いね

## デメリット
### コンストラクタ
1. コードが冗長になる
・いちいち書くのは、、まあだるい

### Autowired
1. 他クラスとの依存関係が分かりにくくなる（可能性がある）
・バラバラに宣言できるので、誰かが変なところで依存関係を作るかもね、ということ
2. finalで変数宣言できない
・上の逆
3. 依存関係が見つからない場合、実行時エラー
・実行しないとバグに気づけないのは怖いね

## おわり
どちらがお好みでしょうか。
私はコンストラクタの方を好んでます。
コード書くのだるいですが、安全が確保されている方が好みです。
いずれにせよ、プロジェクト内で書き方が統一されているべきでしょう。

よかったら参考にしてみてください。
システムの形態

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457284/950d247f-ce12-71fc-35a7-1b423ee22694.png)
　システムの形態を分類すると、バッチ処理、オンライントランザクション処理、リアルタイム処理といった処理形態に基づく分類や、集中システム、分散システム、クライアントサーバシステムといった分担形態に基づく分類ができます。

１：処理形態での分類
①バッチ処理：データをある程度蓄積しており、指定した時点で一括処理を行う。

②オンライントランザクション処理：データが発生する都度処理を行う。処理すべきデータは、通信回線で送る。

③リアルタイム処理：遷座の信号に瞬時に反応して指示を出す。

２：分担形態での分類
①集中システム：コンピュータセンタに汎用機を設置して、汎用機に全ての処理を行わせる。拠点には汎用機にアクセスするための端末を設置する。

②分散システム：処理を行うコンピュータを拠点ごとに分散して配置する。拠点間を通信回線で接続する。

③クライアントサーバシステム：分散システムの一形態である。処理を行うサーバと処理の依頼を出すクライアントで構成する。

３：集中システムと分散システム
「集中システム」
・障害発生時：センタに障害が起こる年してむ全体が停止する。

・運用管理；センタだけに管理者を配置すれば良い。容易である。

・データ管理：センタのみで管理すれば良い。

・セキュリティ：センタで集中した管理が可能である。比較的容易である。

「分散システム」
・障害発生時：１拠点のコンピュータに障害が起きても、その拠点に障害の影響が局在化される。

・運用管理：各拠点ごとに管理者を配置する必要がある。複雑になる。

・データ管理：各拠点間での整合性をとる必要がある。

・セキュリティ：各拠点間での管理を必要とする。困難になる。

４：クライアントサーバシステム
　処理を行うコンピュータやプログラムをサーバ、処理の依頼を出すコンピュータをクライアントと言います。
「代表的なサーバ」
①ファイルサーバ：ファイルを管理して、共有する。

②データベースサーバ：データベース管理、データベースへのアクセスを行う。

③プリントサーバ：プリンタの共有、出力ジョブの管理を行う。

④Webサーバ：要求に応じてHTMLファイルを返す。

⑤メールサーバ：電子メールの配送を行う。

⑥DNSサーバ：問い合わせのあったホスト名に対応するIPアドレスを返す。

　シンクライアントとは、外部記憶装置を持たないクライアント機器をシンククライアントと言います。起動のたびにサーバからOSをダウンロードして読み込みます。
ギフトの古典的な『正』字カウントをGlideを使用し変えてみた！

## ●できたこと
https://twitter.com/6iE1h8QWNV0YQ5B/status/1688381357662334976

## これを作りたいっ！（利己主義）だけでは実際に利用してもらうことはできない！
こんにちは。小売業で販売課長をしている石ゴリです。
今回はGlideを学んで1週間で職場課題解決っ！に取り組んだところ
利用者のフィードバックを受け利他主義の重要性を学ばせてもらいました。

モノ作りはエゴイズム（利己主義）でこんなものを作りたいっ！だけでは
ユーザーに寄り添い、実際に使用してもらえるアウトプットは作れない！
そんな大事なことを気付かせてくれたストーリーです！ぜひご覧ください！

![タイトルなし.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3471031/71065c6d-cb20-608c-4528-7469be42640c.jpeg)
CHATGPT先生に利他主義で一句を作ってもらったら
職場の課題解決どころか世界を変えることになってしまった！頑張れ！俺！

## ●チャレンジした職場課題
**父の日・母の日などの社会催事で手書きの『正』文字手法でカウントしていたギフト件数報告**
・今までの本社への報告内容は
『持ち帰りギフト・発送ギフトの発送件数内訳』
『商品部門と買上げ金額』
・上記の課題をアプリ作成により解決すること・更にプラスアルファの機能として･･･
①ギフト用商品として売れているものを把握
②詳細な数値情報を一目で把握できる集計フォーム
この2つの機能を追加したアプリをGlideで作成しました。


## ●使用ツール
・Glide
・Googleスプレッドシート

## ●作成のポイント
**①Googleスプレッドの設定**
選択してもらう項目はあらかじめ全てタグで分けて準備しておくことです。
今回の私の場合は一枚だけ書き込み専用のタグ『ギフト詳細』にして
あとは選択できるタグを準備します。『部門ctg』『数量』『発送件数』『持ち帰り件数』etc.
を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3471031/aba4cbe0-bb6f-08de-0f1c-886c2a931aaa.png)

**②Componentを使いこなしましょう。やってみればすぐにできる！**
『DateTime』･･･クリックすると自動で日付・時間をスプレッドシートに記録してくれます。
『Choice』･･･クリックすると事前にタグ付けして整理しておいたものから選択ができます。
『Text Entry』･･･クリックすると言語入力が可能です。
今回使用したのはこの３つだけです！しかし、その他も使えそうテンプレートがたくさんあります！
**不安な方はGoogle翻訳機能を使いながら進めると理解度が早まります！おすすめです！（下の図の感じ）**
![スクリーンショット 2023-07-31 155116.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3471031/ab369145-57ea-700d-d813-14206a009bdd.png)

**③Glideの更新場所を覚えましょう！**
この機能覚えておかないと･･･
「スプレッドシートの入力値が反映されてない！」
「Glideの入力数値がスプレッドシートに反映されてない！」
ってテンぱること結構あります・・・。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3471031/ae5070e1-f769-e181-736b-45d96d02f5c1.png)

## ●チームメイトにフィードバックをもらう
・職場のチームメイト（部下）に集まってもらい、
私が取り組んだ職場課題とその背景の説明を行い、
良い点・悪い点の素直な意見を言ってもらうようにお願いしました。

★良い点
・「おお～！すげ～！データ飛ばしたら勝手に記憶されてんの？！やばっ」
・「スマホで数値入力できるのはありがたい」
・「数値をゼロから入力するよりも選択から選べるのが良いね！」
・「データ飛ばして終わりでなくて実際に集計も確認できるのが良い！」

★悪い点（改良点）
・「金額計は自動計算で出てもらうとありがたいっすね～！」
・「割引するときに割引ボタンがあると便利かも」
・「全商品を事前登録してそこから商品を選択するのは現実的ではないので、
　部門とctgが分かれば十分だと思います」
・「別に数字を選択するなら先に見えててもいいかもしれないですね～」
どれも貴重な意見ばかり。無駄にすることなく残された時間で改善しよう！

## ●フィードバックを受けた後の改善点
・「全商品を事前登録してそこから商品を選択するのは現実的ではないので、
　部門とctgが分かれば十分だと思います」
**⇒単品登録から部門・ctg登録に修正し簡素化に成功◎**
・「別に数字を選択するなら先に見えててもいいかもしれないですね～」
**⇒事前に数を表示させて選択しやすく変更しました◎**
・「金額計は自動計算で出てもらうとありがたいっすね～！」
**⇒自動計算は入れましたが列全体への事前計算式は入れられず…！△**
・「割引するときに割引ボタンがあると便利かも」
**⇒今回はできませんでした。今後修正チャレンジ予定。××**

ユーザーの意見をもらう!修正する!!これを繰り返す!!!
このサイクルを回すことで使いやすいアプリへ！
今回の経験で業務改善に直接かかわる、
**ユーザーから貴重な意見をもらって実現する（利他主義）の
重要性を学びました！**

## ●参考記事（大変お世話になりました！）
●【爆速アプリ開発】Glideの使い方を初心者向けにわかりやすく解説
https://engineer-life.dev/howtouse-glide/
●子供でも作れる！glideでインスタグラム風アプリを作ろう
https://puzzlly.jp/courses/5Mj0egUSqieuqPrmqzXSYK/videos/7j32GhfAWKwAPdDxfE3jKg
●Glide 初心者向け解説 画像付き日報をデジタル化しよう!!

https://qiita.com/okinakamasayoshi/items/7153d3fdc34e8aaf074a
React Developer ToolsのProfilerの使い方【初心者向け】



React Developer Toolsは、Reactアプリケーションのパフォーマンスを最適化するための強力なツールです。その中でも、「Profiler」タブは特に有用で、Reactのコンポーネントがどのようにレンダリングされ、どの程度の時間を要しているかを詳細に分析することができます。ここでは、その使い方を初心者向けに解説します。

![スクリーンショット 2023-05-10 12.11.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/987057/18f9802c-d993-dd54-01fe-54ba6fbed034.png)


## 1. React Developer Toolsのインストール

まずはじめに、React Developer Toolsをインストールする必要があります。Google ChromeまたはFirefoxのブラウザに対する拡張機能として提供されています。

## 2. Profilerタブを開く

React Developer Toolsを開き、「Profiler」タブをクリックします。

## 3. レコーディングを開始する

「Record」ボタンを押すと、Reactのレンダリングのプロファイリングが開始されます。その間にアプリケーションを操作すれば、その操作に伴うレンダリングのパフォーマンスが計測されます。

## 4. レコーディングを停止する

レコーディングを停止するには、「Stop」ボタンを押します。すると、計測した結果が表示されます。

## 5. プロファイリング結果を解析する

計測結果は、フレームワークごとに色分けされた「flamegraph」形式で表示されます。各バーは個々のReactコンポーネントを表し、その幅はそのコンポーネントのレンダリングに要した時間を示します。バーをクリックすると、そのコンポーネントの詳細な情報（例えば、レンダリング回数、各レンダリングに要した時間など）を見ることができます。

## 6. パフォーマンスの最適化

Profilerの結果を元に、特にレンダリング時間が長いコンポーネントを特定し、そのパフォーマンスを改善するための対策を考えます。例えば、不要な再レンダリングを避けるために`shouldComponentUpdate`や`React.memo`を使う、ステートやプロップスの変更を最小限に抑える、などが考えられます。

## まとめ

React Developer ToolsのProfilerは、Reactアプリケーションのパフォーマンス分析に非常に有用なツールです。ただし、パフォーマンスの改善は一見すると難しく見えるかもしれません。しかし、Profilerを使ってレンダリングのボトルネックを特定し、それに基づいて最適化を行うことで、アプリケーションのパフォーマンスを大幅に改善することが可能です。

また、Profilerはリアルタイムでのパフォーマンス測定を提供するため、新たな機能を追加したときや、既存のコードをリファクタリングしたときにも、すぐにその影響を確認できます。
BFF とは

##  はじめに
業務でBFFを使用しているが、フロントエンドとバックエンドの間にいる奴ぐらいの知識しかないので調査してまとめる。

## BFFとは
BFF(Backends For Frontends)とは、フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計バターン。

名前の通り、フロントエンドのためのバックエンド、バックエンドAPIから取得したデータをフロントエンドに向けて生成するサーバのこと

![bff.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3525075/a4891660-d5ba-5f1e-dd8b-d62e962a48e6.png)

## 登場経緯
クライアント端末の増加したことに伴うロジックの増加です。
例えばweb、スマホ版web、スマホアプリ、デスクトップアプリなど複数のクライアント登場により、それぞれにコンテンツのだし分けを実装する必要があり、冗長なコードを書かざるを得ない。

そこで、複数のバックエンドから情報を取得し、適切な形に整形するロジックを持つサーバが導入された。それがBFFの登場経緯

## メリット

`APIの集約`
クライアントはBFFに対してAPIを投げれば、複数のバックエンドに対しての対応や加工をBFFがやってくれる
バックエンドからのレスポンスをクライアントが求める形に加工してクライアントに返してくれるので処理が少ない

`バックエンドの差異吸収`
バックエンド毎に異なるAPI(rest,grpc...)を使用していても全て吸収し、いい感じに対応してくれる

`フロントとバックの分離`
フロントとバックが直接通信を行う場合、通信プロトコルを一致させないといけなかったが、BFFを挟めば、異なる通信プロトコルを使用できる

`認証、権限、キャッシュの分離`
BFFに認証、権限、キャッシュなどの処理を実装すれば、フロントとバックはそれらを気にしなくてよい

## デメリット
`BFFサーバの構築と運用保守が必要`
BFFはソースコードを持ち動作するサーバなので構築から運用保守が必要

`デプロイ`
BFFはバックエンドと多くやり取りするため、バックエンドのAPIが変更になれば当然BFFも修正し同時にデプロイする必要がある

`通信の増加`
モノリシックよりも遥かに通信量が増えるので、データ取得までの時間がかかる。帯域の増強などが必要

## まとめ
構築難しそうだなと感じたが、メリットが大きすぎるのでマイクロサービスでは必須に感じた。
調査していて、APIについての知識が不足していると感じたので次はAPIについて調査しようと思う。
Javaで「Pathオブジェクトを使ってファイルやディレクトリを表す」の動作を確認してみた

# 概要
Javaで「Pathオブジェクトを使ってファイルやディレクトリを表す」の動作を確認してみました。以下のページを参考にしました。

https://www.javadrive.jp/start/file/index1.html

# 実装
以下のファイルを作成してみました。
``` JSample1_1.java
import java.nio.file.Path;
import java.nio.file.Paths;

class JSample1_1{
  public static void main(String[] args){
    Path p1 = Paths.get("C:\\code\\java\\file\\report.txt");
    Path p2 = Paths.get("C:", "code", "java", "file", "report.txt");
    Path p3 = Paths.get("C:/code/java/file/report.txt");
    Path p4 = Paths.get("C:/code/java/file/");
    Path p5 = Paths.get("C:/code/java/file");

    System.out.println(p1);
    System.out.println(p2);
    System.out.println(p3);
    System.out.println(p4);
    System.out.println(p5);
  }
}
```
以下の通り実行できました。
```
$ javac JSample1_1.java
$ java JSample1_1 
C:\code\java\file\report.txt
C:/code/java/file/report.txt
C:/code/java/file/report.txt
C:/code/java/file
C:/code/java/file
```

以下のファイルを作成してみました。
``` JSample1_2.java
import java.nio.file.Path;

class JSample1_2{
  public static void main(String[] args){
    Path p1 = Path.of("C:\\code\\java\\file\\report.txt");
    Path p2 = Path.of("C:", "code", "java", "file", "report.txt");
    Path p3 = Path.of("C:/code/java/file/report.txt");

    System.out.println(p1);
    System.out.println(p2);
    System.out.println(p3);
  }
}
```
以下の通り実行できました。
```
$ javac JSample1_2.java 
$ java JSample1_2 
C:\code\java\file\report.txt
C:/code/java/file/report.txt
C:/code/java/file/report.txt
```

# まとめ
何かの役に立てばと。
BigQueryでINSERT処理直後にUPDATE・DELETE処理を行うとエラーが起こり、処理が行えない

# 概要
BigQueryでINSERT処理直後に頻繁にUPDATE・DELETE処理を行うとエラーが起こり、
30分ほど処理が行えない問題に直面したので、それを回避した方法をまとめます。

# 直面したエラー
pythonを使ってBigQueryのデータを操作していたのですが、以下のようなエラーが発生しました。
```
from Exception: query job failed error: [{'reason': 'invalidQuery', 'location': 'query', 'message': 'UPDATE or DELETE statement over table project.dataset.xxxx_table would affect rows in the streaming buffer, which is not supported'}]
```
INSERTやUPDATEのクエリには問題がなく、何度もクエリを実行していると発生しました。
公式ドキュメントをみると以下のような制限があるようです。

https://cloud.google.com/bigquery/docs/reference/standard-sql/data-manipulation-language#limitations

> Rows that were written to a table recently by using streaming (the tabledata.insertall method or the Storage Write API) cannot be modified with UPDATE, DELETE, or MERGE statements. The recent writes are those that occur within the last 30 minutes. All other rows in the table remain modifiable by using UPDATE, DELETE, or MERGE statements. The streamed data can take up to 90 minutes to become available for copy operations.
(日本語訳)
ストリーミング（tabledata.insertallメソッドまたはStorage Write API）を使用して最近テーブルに書き込まれた行は、UPDATE、DELETE、MERGE文では変更できません。最近の書き込みとは、過去30分以内に発生したものです。テーブル内の他の行はすべて、UPDATE、DELETE、MERGE文を使用して変更可能なままです。ストリーム・データがコピー操作に使用できるようになるまで、最大90分かかることがあります。

メソッドを使ってストリーミング挿入した行に頻繁に更新をかけていたことが問題のようでした。

https://cloud.google.com/bigquery/docs/samples/bigquery-table-insert-rows?hl=ja#bigquery_table_insert_rows-python

# 回避策
回避策の一つとして、ストリーミング挿入ではなくバッチ読み込みで
JSONやCSVのファイルから挿入する方法があります。

https://cloud.google.com/bigquery/docs/batch-loading-data?hl=ja

しかし、ファイルの作成やGCSにアップロードする処理の実装が面倒なので、UPDATEを使わなくて良いように設計し直すことにしました。

元々の設計では、タスクとステータス、更新日時等のカラムを持ったタスクを管理するテーブルが一つあり、
タスクができたらINSERTし、数分おきにタスクのステータスを確認して、UPDATE文でステータスと更新日時を更新するようにしていました。
そのため数分おきにUPDATE文を実行する状況になっていました。

イメージ
**task**
|  id  |  task  |  status | modify_dt |
| :--- | :--- | :--- | :--- |
|  1  | task_a  | success | 2023-07-01 10:00:00 |
|  2  | task_b  | running | 2023-07-01 10:00:00 |


そこで、UPDATE処理を実行しないで済むように以下のようにテーブルを二つに分けるようにしました。

**task**
|  id  |  task  | regist_dt |
| :--- | :--- | :--- |
|  1  | task_a  | 2023-07-01 10:00:00 |
|  2  | task_b  | 2023-07-01 10:00:00 |

**task_log**
|  uuid  |  id  |  status | regist_dt |
| :--- | :--- | :--- | :--- |
|  uuid1　　|  1  　　| running | 2023-07-01 10:00:00 |
|  uuid2 |  2   | running | 2023-07-01 10:00:00 |
|  uuid3　　|  1  　　| running | 2023-07-01 10:05:00 |
|  uuid4 |  2   | running | 2023-07-01 10:05:00 |
|  uuid5　　|  1  　　| success | 2023-07-01 10:10:00 |
|  uuid6 |  2   | running | 2023-07-01 10:10:00 |

更新していた項目を別テーブルで管理し、その都度INSERTしていくようにしました。

# まとめ
* メソッドやAPIでストリーミング挿入をした後に時間が経たない間に頻繁にUPDATEやDELETEを行うと
テーブルに対して処理が行えない状態になる。
* テーブル設計を見直すことで頻繁にUPDATEを行わないようにし、エラーを回避した。
【告白】ライティング案件がAIに毒されて、まともな記事が納品されない

私はブログの記事作成には某ライティングサービスを活用しています。
タイトル指定、見出し指定で記事作成を行なってくれるため、低価格な割にそこそこの記事が出てくるため、 ドラフト記事の作成としてここ数ヶ月、10記事ずつぐらいを発注していました。

でもいよいよダメなようです。 完全にAIで書いたであろう記事が納品されたからです。
その記事をこの後そのまま載せますが、発注したタイトル・見出しは下記です。

* タイトル
    * ハーブ研究家のベニシア・スタンリー・スミスさんのウワサについて
* 見出し１
    * ベニシア・スタンリー・スミスさんはどんな人？知名度があるのはなぜ？
* 見出し２
    * ベニシアさんの家族はどんな人がいる？
* 見出し３
    * ベニシアさんについてウワサされてることとは？
   
出来上がった記事はこちらです。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ベニシア・スタンリー・スミスさんはどんな人？知名度があるのはなぜ？

ベニシア・スタンリー・スミスさんは、現代の音楽業界において非常に才能豊かで成功を収めているアーティストの一人です。彼女はシンガーソングライターとしての優れた才能を持ち、独自の魅力的な音楽スタイルで多くのファンを魅了しています。
彼女の知名度がある理由はいくつかあるのです。まず彼女の音楽は感情豊かで聴く者の心に深く響くものがあります。彼女の歌声は力強く情熱的であり、歌詞は人間の感情や経験に共感を呼び起こす内容となっているのです。
ベニシア・スタンリー・スミスさんは、独創的で斬新なアーティストとしても知られています。彼女の音楽はジャンルにとらわれず幅広い要素を取り入れており、聴く者に音楽体験を提供しています。
さらに彼女のライブパフォーマンスも高く評価されているのです。ステージ上での彼女のパワフルな歌声と独自のパフォーマンスは観客を惹きつけ、多くの人々が彼女のコンサートに足を運ぶ要因となっています。

ベニシアさんの家族はどんな人がいる？

ベニシア・スタンリー・スミスさんの家族についての情報は限られておりますが、彼女の親しい関係者によれば、彼女には支えとなる素晴らしい家族がいます。
まず両親は彼女の音楽の道に対して大きな理解とサポートを示してきたようです。彼女の音楽への情熱を育み、才能を信じ、彼女がアーティストとして成長する過程で常に彼女の傍らにいたのです。
兄弟姉妹も彼女にとって大切な存在であり、彼らとの絆は強いとされています。
さらにベニシア・スタンリー・スミスさんは親しい友人たちとも家族のような関係を築いています。音楽の道に進む中で共に励まし合い、刺激し合う仲間たちが彼女の創造性を高めてきたと言えるでしょう。
彼女の家族は彼女の音楽活動を支え、彼女自身の成長に寄り添ってきた存在です。彼女の音楽における成功の裏には、家族との絆とサポートがあったことが想像されます。

ベニシアさんについてウワサされてることとは？

ベニシア・スタンリー・スミスさんは、音楽業界やメディアでさまざまなウワサが流れています。彼女が注目を集める一方でその人気に伴って噂話も絶えないのです。
まず彼女の音楽活動における才能については、絶賛の声が多いのです。彼女の歌声や楽曲のクオリティは高く評価されており、「次世代のトップアーティスト」「圧倒的な歌唱力」といった称賛が飛び交っています。
プライベートにおいても、ベニシアさんの人柄についてのウワサがあります。彼女は謙虚で真摯な性格であるとされ、スタッフやファンとの交流も大切にしているようです。
しかし人気の裏には時折、嫉妬や妬みからくる噂も見られます。競争の激しい音楽業界で成功を収めると、そうした噂話も避けられないのです。
その他にも彼女のプライベートライフに関する噂も少なからずあります。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

ベニシア・スタンリー・スミスさんがミュージシャン・アーティストとしてライティングされています。
しかし実際は、ベニシア・スタンリー・スミスさんはハーブ研究家です。
ハーブについては、一切触れられていません。これは人間の書いた文章ではないでしょう。

Chat-GPTの特徴はキーワードに続く「ありそうな文章」を生成することです。
ベニシア・スタンリー・スミスさんに関する記事がネット上に少ないため、
「ベニシア・スタンリー・スミス」に関するChat-GPTの学習ができておらず、
このようなありふれた女性の記事を生成しているんです。

で、この記事で何が言いたいかというと、
ライティングサービスの運営会社はちゃんとチェックしろやこら！
ということです。

あなたがライティングサービスを運営しているなら、
ぜひ自社が納品した記事を見直して、顧客に適切な記事を届けているか確認してください。
【Python】出てきた単語Django


# 【python】出てきた単語集Django

## 自分用のメモみたいなものです。※間違えもあるかもしれません

### ①req

request(リクエスト)

------


### ②resp

response(レスポンス)

------


### ③dicr

dictionary(ディクショナリ)

-----

### ④json

JavaScript Object Notation(ジャバスクリプト　オブジェクト　ノーテーション)