OmniAICreator/Qiita-1.07M huggingface dataset:
Visual Studio Codeの拡張機能「Powerful Animation」でSVG操作がラクラク【Power Apps】

# Powerful Animation
`Visual Studio Code`の拡張機能 [Powerful Animation](https://marketplace.visualstudio.com/items?itemName=WarnerDigital.powerful-animations)が使えそうなので紹介。

`SVG`を`Power Apps`で使うことがありますが、`"` `ダブルクオーテーション`を`'` `シングルクオーテーション`に置き換えなければならなかったりと、少し手間があります。

https://marketplace.visualstudio.com/items?itemName=WarnerDigital.powerful-animations

実際に`SVG`を`Power Apps`で描画する場合

```yaml:
"data:image/svg+xml," & EncodeUrl("<svg xmlns='http://www.w3.org/2000/svg'{画像}</svg>")
```

と式を書かなければならないことが若干手間だったりします。
この部分をクイックにできる拡張機能が [Powerful Animation](https://marketplace.visualstudio.com/items?itemName=WarnerDigital.powerful-animations)です。

下記のSVGを例にして試してみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/869dbfdb-3f4a-ea3d-77c7-699e30286e12.png)

:::note info
自分で書いたゴリラの絵🦍です
ワンパンマン リスペクト✨
:::


# インストール
1. `Visual Studio Code`を開き、`拡張機能を選択`
1. [Powerful Animation](https://marketplace.visualstudio.com/items?itemName=WarnerDigital.powerful-animations)を選択
1. インストール

このステップでクイックに準備が完了します。

![q1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/4ef78768-f2b1-3a1a-d6d5-54ec7477d6c4.png)

# 使い方 Powerful Animations: Convert to Single Quotes
さっそくSVGファイルを開いてみましょう。
`Visual Studio Code`で`SVG`を開きます。

文字列を選択し、コマンドパレットから`Powerful Animations: Convert to Single Quotes`を実行します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/4263d9a8-bca8-3e98-4c91-35e057ce7cf0.png)

即座に`"` `ダブルクオーテーション`を`'` `シングルクオーテーション`に置き換わります。
Power Appsの`"data:image/svg+xml," & EncodeUrl("ここに値貼り付け")`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/f50be557-f514-c7b4-3d83-26db7e1a3ab9.png)

スグに`Power Apps`で表示しやすくなりました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/1bb867a0-1c7b-2eaa-eb9a-a6cb4bb71650.png)

気の利いた置き換え機能になります。

# 使い方 Powerful Animations: Prepare SVG for Power Apps
上記の機能では物足りない。理想はワンクリックです。
それをかなえるコマンドが`Prepare SVG for Power Apps`!!

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/0c7742eb-1fb9-6b12-e404-8d70f4ae61d0.png)

コマンドパレットに入力して実行。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/5fbef1af-f231-d710-3250-82616df694c8.png)

即座にクリップボードへ、`Power Apps`で使用する文字列が格納されます。

これをそのまま`Power Apps`の`Image` コントロールの`Image`プロパティに貼り付けると・・・

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/0562d8a0-2d3d-bf75-282c-1063e7efbce0.png)

`"data:image/svg+xml;utf8, " & EncodeUrl("<~~`全ての必要な値が設定されます！
手間があった`Power Fx`の入力、`"` `ダブルクオーテーション`を`'` `シングルクオーテーション`に置き換える手間もなく、**Cool✨**

何かと使えそうですね！

# おわりに
今回は便利で要チェックな拡張機能を紹介しました！
`Preview`段階でインストール数もまだ少ないですね！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2734332/8eb7a04e-4b47-5b7d-f52c-2bc1e20a96f4.png)

アーリーアダプタ感味わえます！

**今後の追加機能にも期待大！**
**Powerな人へ届け！**
PHP8から追加された新機能「nullsafe演算子」を活用しよう

## nullsafe演算とは
`nullsafe演算子`(`?->`)は、オブジェクトのプロパティやメソッドにアクセスする際に、
nullチェックを簡潔に行うための新しいPHP構文です
従来の方法では、nullチェックを行うために複数の条件文を書く必要がありましたが、
`nullsafe`演算子を使用すると、コードがシンプルで読みやすくなります

基本構文
```php
$property = $object?->property;
$result = $object?->method();
```

上記では、`$object`がnull出ない場合にのみ`property`や`method`にアクセスし、nullの場合はnullを返すようになっています

## 実際のコード例と解説
### 従来の方法との比較
従来の方法では、以下のようにnullチェックを行う必要がありました
```php
if ($object !== null) { // またはisset()、!empty()など
    $property = $object->property;
} else {
    $property = null;
}
```

`nullsafe演算子`を使うと、同じ処理を1行で記述できます
```php
$property = $object?->property;
```

メソッドの場合は以下の通り
```php
$result = $object?->method();
```

`$object`がnullでない場合に、`method()`を呼び出し、その結果を`$result`に代入します
nullの場合は、`$result`にnullが代入されます

## nullsafe演算子の具体的なユースケース
### データベースアクセス
オブジェクトがデータベースからのレスポンスを表している場合、nullsafe演算子を使って安全にアクセスできるようになります
```php
$user = $db->getUser($userId);
$username = $user?->getUsername(); // $userがnullなら呼び出さないようになり、nullが代入されるようになります
```

### APIレスポンス処理
APIレスポンスがnullを含む可能性がある場合、`nullsafe演算子`を使ってエラーを避けることができます
```php
$response = $api->getResponse();
$data = $response?->data?->item; // $responseまたはdataがnullであればitemへはアクセスされず、nullが代入されるようになります
```

### 深いネストのオブジェクト
深くネストされたオブジェクトにアクセスする場合、`nullsafe演算子`を使用するとコードが簡潔になります

```php
$value = $object?->level1?->level2?->level3;
```

## まとめ
`nullsafe演算子`は、PHP8で追加された便利な機能であり、コードの可読性と保守性を向上させることができます
従来のnull処理に比べてシンプルで使い勝手が良いのですが`nullsafe`演算子だけでは解決できない実装もあるかと思いますので適材適所に使い分けましょう！

## 参考リンク

https://www.php.net/releases/8.0/ja.php#nullsafe-operator

https://www.php.net/manual/ja/language.oop5.basic.php#language.oop5.basic.nullsafe

https://qiita.com/rana_kualu/items/c967d58582ef75e73d7d
持続的なnpmキャンペーン：トロイの木馬化されたjQueryが流通

# はじめに
最近技術を追うことが中々出来ない状態の [@\_\_\_nix___](https://twitter.com/___nix___)  です。

近年、オープンソースパッケージの利用が一般的になる中、セキュリティリスクも増大しています。NPMパッケージレジストリとGitHubで発見された、jQueryを偽装した悪意あるキャンペーンについて詳しく見ていきましょう。

https://blog.phylum.io/persistent-npm-campaign-shipping-trojanized-jquery/

# 脆弱性の概要
攻撃者は、人気のjQueryライブラリを模倣した偽のパッケージをNPMとGitHubにアップロードしています。これらのパッケージは正規のjQueryコードと悪意のあるコードを組み合わせており、開発者を騙して使用させることを目的としています。

# 脆弱性の詳細
この攻撃は2022年12月から継続しており、NPMとGitHubの両プラットフォームで確認されています。攻撃者は定期的に新しいバージョンをアップロードし、パッケージ名を少し変更したり（例：jquary, jquery-npm）、追加機能を謳ったりして開発者を引き付けています。一部の偽パッケージは数千回もダウンロードされており、その影響は広範囲に及んでいます。

# 脆弱性の技術的説明
偽パッケージに含まれる悪意のあるコードは、被害者のシステムから機密情報を盗み出そうとします。具体的には、環境変数、ファイルシステム情報、ネットワーク設定などの重要なデータを収集し、攻撃者のサーバーに送信します。また、バックドアを作成して、攻撃者がシステムに継続的にアクセスできるようにする場合もあります。

# 脆弱性の確認方法
## 1. コードの直接確認
   jQueryファイル（例：jquery.min.js）を開き、以下のメソッドの実装を確認します。
   - `end` メソッド: 
     ```javascript
     end: function() {
       return this.prevObject || this.constructor();
     }
     ```
   このコードが異なる場合、トロイの木馬の可能性があります。

## 2. ハッシュ値の比較
   ターミナルで以下のコマンドを実行し、jQueryファイルのSHA-256ハッシュを計算します。  

    ```
    # Linux/macOS (Homebrew)
    sha256sum path/to/jquery.min.js
    
    # macOS (デフォルト)
    shasum -a 256 path/to/jquery.min.js
    
    # Windows
    certutil -hashfile path\to\jquery.min.js SHA256
    ```
   得られたハッシュ値を、jQueryの公式サイトやCDNで提供されているハッシュ値と比較します。

## 3. パッケージの出所確認
   package.jsonファイルを開き、jQueryの依存関係を確認します。
   ```json
   "dependencies": {
     "jquery": "^3.6.0"
   }
   ```
   バージョン番号が正しいこと、そして公式のnpmレジストリからインストールされていることを確認します。

これらの方法を組み合わせることで、トロイの木馬のような脅威をより効果的に検出できます。ただし、完全な保証はないため、常に警戒を怠らず、公式ソースからパッケージをインストールするなど、基本的なセキュリティプラクティスを遵守することが重要です。

# 必要なアクション
1. 偽のjQueryパッケージを使用していることが判明した場合、直ちに削除する。
2. 正規のjQueryパッケージを公式ソースからインストールする。
3. プロジェクト全体のセキュリティ監査を実施し、他の潜在的な脅威がないか確認する。
4. パスワードやAPIキーなど、重要な認証情報を変更する。

# 予防措置
1. 常に公式ソースからパッケージをダウンロードする。
2. パッケージの評判、ダウンロード数、最終更新日を確認する。
3. package-lock.jsonファイルを使用して、依存関係のバージョンを固定する。
4. 定期的にnpm auditを実行し、脆弱性をチェックする。ただし、npm auditだけでは新しい脅威や巧妙に偽装されたパッケージを検出できない場合があることに注意する。
5. サードパーティのセキュリティツールを使用して、依存関係をスキャンする。
6. GitHubリポジトリを使用する場合、スター数や貢献者の信頼性を確認する。

# 終わりに
オープンソースパッケージの利用は開発効率を向上させますが、セキュリティリスクも伴います。今回のjQuery偽装パッケージの事例は、NPMとGitHubの両方で確認され、開発者がパッケージの選択と使用に細心の注意を払う必要性を再認識させます。適切な予防措置と定期的なセキュリティチェックにより、このような脅威からプロジェクトを守ることができます。セキュリティは開発プロセスの不可欠な部分であり、常に警戒を怠らないことが重要です。

# 一言
この記事は [@\_\_\_nix___](https://twitter.com/___nix___), Gemini 1.5 Pro, GPT-4o, Claude 3.5 Sonnet による共同執筆でした。
それぞれ好き勝手言う生成AIをまとめながら少しでも興味深い内容に仕上げてみました。

アディオス！
ちょっとざんねんなコードたち。皆さんの糧にしてもらえると僕も浮かばれる…。

私の書いた「ざんねんなコードたち」を公開します…。
誰かの糧にしてもらえれば嬉しいです。

:::note
設計の良し悪しは棚に上げておきます。
ただ、「こんな書き方できるよ」の一覧であることをご了承ください。
:::

## オブジェクトをくっつけたかったねん…
例えばPropsで受け取ったCSSオブジェクトとコンポーネント側で定義されたCSSオブジェクトをくっつけようとしました。

```diff_jsx
import { FC, PropsWithChildren } from 'react'

type Props = {
  title: string
}

export const Component: FC<
  PropsWithChildren<Props>
> = ({ title, children }) => {
  // カスタムフックからinitialStylesというCSSオブジェクトが返ってくる
  const {
    initialStyles,
  } = useCustom()

  const iconSize = {
    width: 20,
    height: 20,
  }
  
- const iconStyle = Object.assign({}, initialStyles, iconSize)
+ const iconStyle = { ...initialStyles, ...iconSize }
```

## childrenはもっとシュッとできる
childrenを受け取るコンポーネントを作るときは`&`で繋げちゃってました…。
```typescript:before
type Props = {
  value: string
} & PropsWithChildren

export const Component: FC<Props> = ({value, children}) => {}
```
`PropsWithChildren`で`Porps`をラップしてスッキリ。

```typescript:after
type Props = {
  value: string
}

export const Component: FC<PropsWithChildren<Props>> = ({value, children}) => {}
```

## そのコード見づらない？
tailwindのclassが長く連なった上に、条件分岐を含むと非常に読みにくい…。

```jsx:before
- <div className={`flex flex-row items-start gap-4 p-4 ${resolvedBubblePosition === 'left' ? 'justify-end' : 'justify-start'}`}>
```

`tailwind-merge`を使って通常の定義と条件分岐によるclassの定義を分けてみました。
```jsx:after
<div 
  className={twMerge(
    'flex flex-row items-start gap-4 p-4',
    isLeft ? 'justify-end' : 'justify-start',
  )}
>
```

`tailwind-merge`を使うと重複するclassは削除してくれちゃうのでPropsで`className`を渡すなど動的にスタイルを変更する場合などは`twMerge`、ただの文字列を繋げるだけなら`tvJoin`を利用するのが良いかと思います！

なので上記の例だと`tvJoin`でも問題ないと思います。

## コンポーネントのテキストカラー変えたかってん…

`textColoe`には`red`みたいにカラー名が入る想定、任意で設定できるOptionalとして定義しました。
`tailwind-variants`を利用してスタイルを宣言的に定義している前提で話を進めます。

```diff_typescript
import { tv } from 'tailwind-variants'

const style = tv({
  base: '',
  variants: {
    color: {
      red: 'text-red-500'
    }
  }
})

type Props = {
  index: number
-  textColor?: string
+  textColor?: (keyof typeof style.variants.color)
}
```

一見良さそうなコードですが、`textColor`には`red`か`undefined`以外の文字列が渡ってきてしまう恐れがあります…。

 `tailwind-variants`で定義したcolorのkeyを利用することで`red`のリテラル型か`undefined`しか許容できない型となります。

 ## その数値の羅列はやめとけ
tailwindで実装していた私は下記のように定義してしまいました…。

:::note alert
パッと見た時に規則性がある数値ではないので、使う時に覚えないといけない制約を利用者に与えてしまいます…
:::

```diff_typescript
type Props = {
-  padding?: 1 | 2 | 4 | 6 | 8;
+  padding?: 1 | 2 | 3 | 4 | 5;
+  padding?: 'xs' | 'sm' | 'md' | 'lg' | 'xl';
}
```
- 連番にして中身で呼び出しているclassを変える
- セマンティックな`xs(xsmall）`や`lg（large）`のようなキーワードで呼び出す

のような方がわかりやすいかと思います。

## まとめ
ここに書いたコードは漏れなく残念なコードだと思っていますが、中には残念に見えるけど致し方ない実装もあると思います…。

:::note
「**そうなってしまった**」のと「**あえてそうしている**」とは全く別の話なので、チーム内でコミュニケーションをとって対応していけると良いのではないかと思います。
:::
適切な成果アピールはリーダーの責務

# はじめに
成果をあまりアピールしない人がエンジニアにはまあまあいるように思えます。
これが個人の成果のみにとどまる話であれば、個人の責任で終わります。
ですが、これがリーダーだと話は変わってきます。

先に結論を書きますが、
<font color="Red">リーダーが成果を主張しないことで、一緒に働いている人の存在感も低く見られる可能性があるからちゃんとアピールしようね</font>
ということです。

つまり、チームの成果をアピールすることは、**リーダーの責務の一つ**とも言えると思っています。

# 成果について
例えば、決められたルールに従って進め、大きな問題を発生させず、期日内に余裕を持って顧客に開発したサービスを提供することが出来たとします。

これは充分優秀な結果と言えるでしょう。
勿論、バグ検出数、改修量、売り上げなど定量的に数値化して上に報告する必要はあると思いますが、良い結果には違いないかと。

問題が出ずに開発できた、っていうのは当たり前のことでは無いですし、どのチームでも出来ることでは無いと思います。

つまり、以下のことが出来ているということになるかと。
・問題が出ないように進めることが出来た
　→問題に備え、予防することも出来た)
・且つ問題が出たとしても最小限にすることが出来た
　→事前にリスクを想定し最小限に対応出来た
・スケジュールも適切にリスク込みで引き、期日までに無事問題のないものを納品できた（納品後も問題がほぼ無かった）

# 成果をアピールしないとどうなるのよ？
謙遜は美徳かもしれませんが、ことリーダーポジションにいる人間はアピールしまくるくらいでちょうど良いのでは？

謙遜し過ぎて、成果をアピールせず上司も普通に何事も無く終わった、良かったね、で終わっちゃう。
上司目線で言えば、普通に終わって良かったね、じゃあ評価も普通だね、で終わるかもしれない。

そうなると
<font color="Red">チームが縮小する　→ メンバーが減る　→ 皺寄せが残りのメンバーに　→ファイヤー🔥🔥🔥</font>
なんてことにも。

少々極端な例ですが、リーダーはリーダーの成果アピール一つでチームの評価が決まる可能性があることを良く認識しておかなければいけません。

# 最後に
私の好きな安西先生の名言がこちら。
**「お前のためにチームがあるんじゃねぇ。チームの為にお前がいるんだ！！」**

リーダーが手を動かすことも勿論ありますが、チームなのでメンバに適切に動いてもらわないと目標を達成することはできません。
売上一つ取っても、リーダー１人だけ頑張っても目標達成は難しいですよね？

メンバーが適切に動いてもらうよう、リーダーが先頭切って調整やら開発方針やらを決めて頑張ります。
つまり、リーダーはチームの為に頑張ります。
で、せっかくチームが成果を出すことができたのに、成果をアピールしなかったことによって不利益を被ることは非常に勿体無いことだと思います。

そのため、**チームで成果を出すことが出来たら大袈裟なくらいアピールしようぜ**、というお話でした。

以上
【AWS】Cloud9でNode.js用のAWS SDKを使ってHello Amazon Cognito

# はじめに

以下の Hello Amazon Cognito を Cloud9 で行う。

https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/javascript_cognito-identity-provider_code_examples.html

# 手順

## 1. Cloud9 を起動
  - インスタンスタイプは t3.micro (1 GiB RAM + 2 vCPU)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/a014b97d-f7cc-f675-a467-25dc10239dd7.png)

## 2. hello-cognito.js を作成

以下のサンプルコードを編集する。

- 編集前（Hello Amazon Cognito をコピペ）

```hello-cognito.js
import {
  paginateListUserPools,
  CognitoIdentityProviderClient,
} from "@aws-sdk/client-cognito-identity-provider";

const client = new CognitoIdentityProviderClient({});

export const helloCognito = async () => {
  const paginator = paginateListUserPools({ client }, {});

  const userPoolNames = [];

  for await (const page of paginator) {
    const names = page.UserPools.map((pool) => pool.Name);
    userPoolNames.push(...names);
  }

  console.log("User pool names: ");
  console.log(userPoolNames.join("\n"));
  return userPoolNames;
};
```

- 編集後

```diff:hello-cognito.hs
- import {
+ const {
  paginateListUserPools,
  CognitoIdentityProviderClient,
- } from "@aws-sdk/client-cognito-identity-provider";
+ } = require("@aws-sdk/client-cognito-identity-provider");

const client = new CognitoIdentityProviderClient({});

const helloCognito = async () => {
  const paginator = paginateListUserPools({ client }, {});

  const userPoolNames = [];

  for await (const page of paginator) {
    const names = page.UserPools.map((pool) => pool.Name);
    userPoolNames.push(...names);
  }

  console.log("User pool names: ");
  console.log(userPoolNames.join("\n"));
  return userPoolNames;
};

helloCognito();
```

## 実行

```shell
$ node hello-cognito.js
test-userpool-20240710
```

# メモ

- Cloud9 には最初から SDK パッケージが入っていた

```shell
$ npm info @aws-sdk/client-cognito-identity-provider version
3.613.0
```

- import ではなく require を使用する
  - ドキュメントのコードだと以下エラーが発生

```
/home/ec2-user/environment/work/hello-cognito.js:1
import {
^^^^^^

SyntaxError: Cannot use import statement outside a module
```

# 参考

https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/javascript_cognito-identity-provider_code_examples.html
スクラム開発でロギングを統一する方法：クラウドサービスを活用したベストプラクティス


## はじめに

スクラム開発において、ロギングの統一は非常に重要なテーマです。特に、クラウドベンダーの多様なサービスを活用する現代の開発環境では、ロギングの一貫性を保つことがプロジェクトの成功に直結します。この記事では、ロギングを統一するためのベストプラクティスと、クラウドサービスを活用した具体的な方法について解説します。

## なぜロギングの統一が重要なのか

ロギングの統一は、以下のような理由で重要です：

1. **トラブルシューティングの効率化**：一貫したログフォーマットは、問題の特定と解決を迅速に行うために不可欠です。
2. **監査とコンプライアンス**：統一されたログは、セキュリティ監査やコンプライアンス要件を満たすために役立ちます。
3. **パフォーマンスの最適化**：ログデータを分析することで、システムのパフォーマンスを最適化するためのインサイトが得られます。

## クラウドサービスを活用したロギングの統一

### 1. ログ収集の一元化

クラウドベンダーが提供するログ収集サービスを活用することで、ログの一元化が可能です。例えば、AWSのCloudWatch LogsやAzureのMonitor Logsを使用することで、複数のサービスからのログを一箇所に集約できます。

### 2. ログフォーマットの標準化

ログフォーマットを統一するためには、JSONやCSVなどの標準フォーマットを採用することが推奨されます。これにより、ログ解析ツールとの互換性が高まり、データの可視化が容易になります。

### 3. ログのタグ付け

ログにタグを付けることで、特定のイベントやリソースに関連するログを簡単にフィルタリングできます。例えば、リクエストIDやユーザーIDをタグとして追加することで、特定のトランザクションに関連するログを迅速に特定できます。

### 4. ログの保存とアーカイブ

クラウドストレージを活用して、ログデータを長期間保存することが可能です。例えば、AWSのS3やAzureのBlob Storageを使用することで、コスト効率よくログデータを保存できます。

### 5. ログのモニタリングとアラート

リアルタイムでログをモニタリングし、異常を検知した際にアラートを発する仕組みを構築することが重要です。AWSのCloudWatch AlarmsやAzureのMonitor Alertsを活用することで、異常検知とアラートの自動化が可能です。

## 実際の導入事例

### 事例1: Eコマースサイトのロギング統一

あるEコマースサイトでは、AWSのCloudWatch Logsを使用して、全てのマイクロサービスからのログを一元化しました。ログフォーマットはJSONを採用し、リクエストIDとユーザーIDをタグとして追加することで、トラブルシューティングの効率が大幅に向上しました。

### 事例2: 金融機関の監査対応

金融機関では、AzureのMonitor Logsを使用して、全てのトランザクションログを一元管理しています。ログデータはAzure Blob Storageに保存され、監査要件を満たすために長期間アーカイブされています。

## まとめ

ロギングの統一は、スクラム開発において非常に重要なテーマです。クラウドサービスを活用することで、ログの一元化、フォーマットの標準化、タグ付け、保存とアーカイブ、モニタリングとアラートの自動化が実現できます。これにより、トラブルシューティングの効率化、監査対応、パフォーマンスの最適化が可能となります。

皆さんもぜひ、クラウドサービスを活用してロギングの統一を実現し、プロジェクトの成功に繋げてください。
Laravel Eloquentで親テーブル小テーブル共に検索対象にする方法

# 概要
Laravel Eloquentにおいて、親子テーブル両方を検索対象にする方法について、この記事では記載する。

# 解決方法
**orWhereHas を使って検索対象に**含めれば、解決することが出来る。

```App\Models\Player.php

public function team(): BelongsTo
{
    return $this->belongsTo(Team::class);
}

static public function findBySearch(string $input)
{
    $players = Player::makeBuilder($input)->get()->load('team');
    return $players;
}

static private function makeBuilder(string $input)
{
    return Player::where('name', 'LIKE', '%' . $input . '%')
        ->orWhere('age', 'LIKE', '%' . $input . '%')
        ->orWhere('position', 'LIKE', '%' . $input . '%')
        ->orWhereHas('team', function ($query) use ($input) {
            $query->where('name', 'like', '%' . $input . '%')
                ->orWhere('area', 'like', '%' . $input . '%');
        });
}

```

# 補足
## withとloadの使い分け
以下の記事が分かりやすいと思います。

https://qiita.com/bitarx/items/4d6f2eee2e1fb9d17586
スクラム開発でSLAを遵守するためのベストプラクティス


## はじめに

こんにちは、皆さん。今回はスクラム開発において、サービスレベルアグリーメント（SLA）を遵守するためのベストプラクティスについてお話しします。クラウドベンダーの多様なサービスを活用しながら、どのようにして高い品質と信頼性を保つかについて、具体的な方法を共有します。

## SLAとは？

まず、SLA（サービスレベルアグリーメント）について簡単におさらいしましょう。SLAは、サービス提供者と顧客の間で合意されたサービスの品質や可用性、応答時間などの基準を定めたものです。これを遵守することは、顧客満足度を高め、信頼性の高いサービスを提供するために非常に重要です。

## スクラム開発とSLA

スクラム開発はアジャイル開発手法の一つで、短期間のスプリントを繰り返しながらプロダクトを進化させていく方法です。この中でSLAを遵守するためには、いくつかのポイントに注意する必要があります。

### 1. 明確な定義と目標設定

まず、SLAの内容をチーム全体で明確に理解し、具体的な目標を設定することが重要です。これにより、全員が同じ方向を向いて作業を進めることができます。

### 2. 継続的なモニタリング

SLAを遵守するためには、サービスのパフォーマンスを継続的にモニタリングすることが不可欠です。クラウドベンダーが提供するモニタリングツールを活用し、リアルタイムで状況を把握しましょう。

### 3. 自動化の活用

自動化は、SLAを遵守するための強力な武器です。CI/CDパイプラインを構築し、テストやデプロイを自動化することで、人的ミスを減らし、迅速なリリースを実現します。

### 4. インシデント管理

インシデントが発生した場合の対応も重要です。インシデント管理ツールを導入し、迅速に問題を特定・解決する体制を整えましょう。また、インシデント後の振り返りを行い、再発防止策を講じることも大切です。

### 5. チームのコミュニケーション

最後に、チーム内のコミュニケーションを円滑に保つことがSLA遵守の鍵となります。定期的なミーティングやレビューを通じて、情報共有とフィードバックを行いましょう。

## クラウドサービスの活用

クラウドベンダーが提供する多様なサービスを活用することで、SLA遵守のための環境を整えることができます。例えば、AWSのCloudWatchやAzureのMonitorを使ってパフォーマンスを監視したり、Google CloudのPub/Subを使ってリアルタイムのデータ処理を行うことができます。

## まとめ

スクラム開発においてSLAを遵守するためには、明確な目標設定、継続的なモニタリング、自動化の活用、インシデント管理、そしてチームのコミュニケーションが重要です。クラウドベンダーのサービスを上手に活用しながら、信頼性の高いプロダクトを提供していきましょう。

皆さんのプロジェクトが成功することを願っています。この記事が少しでもお役に立てれば幸いです。

## おわりに

この記事が気に入ったら、ぜひ「いいね」や「フォロー」をお願いします。また、質問やコメントがあればお気軽にどうぞ！
研究が上手くいかない時，自分と向き合うのって大事だよねって話

## 目次
1. [はじめに](#はじめに)
2. [どうして研究を進められなかったのか](#どうして研究を進められなかったのか)
3. [まず、自分と向き合った](#まず自分と向き合った)
   - [机に向かう時間が思いのほか少なかった](#机に向かう時間が思いのほか少なかった)
   - [やることが抽象的だった](#やることが抽象的だった)
   - [計画が立てられていなかった](#計画が立てられていなかった)
4. [さいごに](#さいごに)

## はじめに
研究はなかなかうまくいかないものです．そこで戦意を喪失したり，逃げ出したくなったりすると思います．実際自分ももう少しで学校に行かなくなっていたかもしれないというところまで追い込まれていました．そこで，そんな自分がどうやって立て直したのかを綴ります．これを読んだ方々が、同じような状況に陥ったときに参考にしてくださればと思います．

## どうして研究を進められなかったのか
自分は高校まで野球に打ち込んでいてデスクに向かって長時間作業をするのが苦手でした．また，長時間1つのことを考え続けることも苦手でした．また，目的や目標が「卒業したい」という研究と直接関係ない事にあったため曖昧となっていました．なので研究に集中することもできなければ，テーマすら決めることができませんでした．以上のような状況となってしまったため研究を進められずにいました．実際，レポート提出の1か月前までテーマが決まっておらず成果物なんてありませんでした．このままでは卒業できないと思い，自分と向き合うことにしました．そうすることでどうして研究がうまくいかなかったのか少しわかった気がします．状況の当てはまる人がいたら，参考にしてみてください．

## まず，自分と向き合った
そんなことになったので自分と向き合いました．そこで気づいた点がいくつかあったので取り上げます．

### 机に向かう時間が思いのほか少なかった
まず，最初に自分がどれくらい研究に時間を費やしているのかを計測しました．結果は思いのほか少なかったです．正直，驚きました．これでは研究が進まないのも納得．そこで，週の初めに今週は何時間やるという目標を立てて，そのために1日ごとどれくらいの時間を研究に費やすべきなのかを明確にしました．そうすることで必然的に研究に費やす時間が増えました．これで量を確保することができました．次に質を求めていきましょうということで次の話に進みます．

### やることが抽象的だった
研究室の先輩からのアドバイスでesaというものにやったことの整理をしているのですが，それが抽象的でした．例えば「テーマを決める」のような感じです．それでは何をすればいいのかを考え直さないといけないのでやる気が削がれます．なのでとにかく細かくします．

- テクニカルレポートの執筆
    - 概要を書く
    - 背景を書く
    - 課題を書く

上記のように整理した場合，テクニカルレポートのどこを書くのかに関しては細かくすることができています．ですが，それでは書くのに何すればいいんだっけとなりやる気が削がれます．そこで下記のように修正を加えます．

- テクニカルレポートの執筆
    - 概要を書く
        - 追加できた内容を整理して書く
        - 変更点があったら，その部分も対応するように変更する
    - 背景を書く
        - 前回のスライドから修正した部分を追加する
        - 文章全体を読んで一番必要なところに図1つを追加する
    - 課題を書く
        - 詳細を箇条書きにして整理してから文章にする
        - ファイルの種類に関することが記載されている参考文献をみつける
        - 文章全体を読んで必要なところに図or表を2つを追加する

これくらい細かくすることでやる気が削がれることは少なくなりました．また，1つずつクリアしていく感じがちょっと楽しいなと感じるようになり，作業がはかどるようになりました．注意点としては一番最初にこのように細かくしてください．朝一番はやる気があると思うのでタスクの細分化は頑張ってください．ここまで細かくすることで必要な時間がわかるのでいいと思います．

### 計画が立てられていなかった
その日その日を乗り越えることで精いっぱいだったので計画が立てられていませんでした．そこで，現在から期限までを逆算するように目標を立てました．もちろん，これも先輩からのアドバイスです．実際に，レポートの提出まで1ヶ月しかなかったので提出日に終わらせることをゴールとして，それまでにやるべきことを羅列，それらを期限に間に合わせるために終わらせるべき日を決めることで計画を立てました．そうすることでゴールまでの道筋が見えてきました．また，1週間ごとで達成したいことを整理すれば週ごとになにかをクリアできていることになるので積み重ねた感じが出てきて研究のモチベーションを保つことができます．要するに計画は下記の期間で立てるべきだということです．
- 現在から期限までを逆算したときの計画
- 1週間での計画(その週の頭に考える)
- 1日の計画(その日タスクを始めた最初に考える)

## さいごに
事が上手く進まないときは，工夫することが大切です．私は研究が進まなかったのはその人の技量や知識量，生まれ持った集中力などが関係しているかと思いました．ですが，このように自分と向き合った結果そんなことはありませんでした．周りの頑張っている人も時間の確保や計画の練り直しを必死に頑張っているのかと思うと自分なんてまだまだだなと思いました．最後まで読んでいただいた方，ありがとうございます．もし参考になりましたらいいね(♡)をお願いします．
AzurePipelines: New Pipeline した際にやりがちな失敗

# 背景

Azure Pipeline を使い始めて、
New Pipeline の際にやりがちなことをメモっておく

# 失敗例

## Pipeline Branch Default を変えずに放置

すると、以下のようなエラーがでて困ることになる。

![](https://camo.qiitausercontent.com/6b825e661410433651efdf64d403c1f8fd26d7c4/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3132303037322f34303238626236622d636230362d373837632d363661382d3130303030366331396566642e706e67)

対策法は以下で

https://qiita.com/baku2san/items/934f480da44d6da0cb6e

## pipeline.yml の保存先を変え忘れて、Default のままに

作成する際に、以下を気を付ける
- 保存先
- ファイル名

ex.) .azdo/pipelines/pytest.yml

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/3cb4e1d7-bd27-51e6-4b1c-1116e04326a2.png)

## branch 切らずに、commit で origin へ

どちらにしたいかを考えて選択する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/d3e6092d-cace-4954-32df-59f24595dbde.png)

やっちゃったときは、git reset で対処

https://qiita.com/baku2san/items/8ac9ffd4c2e93570ee07

## branch の名称変え忘れて、Default のままに

保存する前に、feature/pytest とか、目的の branch 名にしておく

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/c76dca6e-82f5-40ba-fdba-ddfe35d1f58f.png)

## GUI trigger で overwride して、yaml 殺しちゃう

以下の設定を思わず、設定しちゃったら元に戻そう

![](https://camo.qiitausercontent.com/89e8abf5075aed57f2350d1f8d8e49f0f6c91123/68747470733a2f2f6c6561726e2e6d6963726f736f66742e636f6d2f6a612d6a702f617a7572652f6465766f70732f706970656c696e65732f7265706f732f6d656469612f706970656c696e65732d6f7074696f6e732d666f722d6769742f79616d6c2d706970656c696e652d6f766572726964652d747269676765722e706e673f766965773d617a7572652d6465766f7073)

https://qiita.com/baku2san/items/196525118e32cadc38ab

## base branch 変えられないよーって嘆く

Azure Repos -> Branches から変えておく

https://qiita.com/baku2san/items/9c7959c82a4aee9ad65c

## trigger が効かねー

作ろうとしてる yml ファイルは、どの branch にあるか？を考える

https://qiita.com/baku2san/items/8ccfe8ae8c81d9c5fd36

# あとがき

yaml 書く以外に、意外と躓くことが多かった

勿論、yaml 書く際にも躓いてますけどね・・ :sweat_smile: 

https://learn.microsoft.com/ja-jp/azure/devops/pipelines/yaml-schema/?view=azure-pipelines
スクラム開発でネットワークの冗長性を確保する方法


## はじめに

スクラム開発において、ネットワークの冗長性を確保することは非常に重要です。特にクラウド環境では、サービスの可用性を高めるために冗長性を持たせることが求められます。この記事では、クラウドベンダーの様々なサービスを活用しながら、ネットワークの冗長性を確保する方法について解説します。

## ネットワークの冗長性とは？

ネットワークの冗長性とは、システムが一部の障害に対しても継続的に動作できるようにするための設計手法です。具体的には、複数のネットワークパスやデバイスを用意し、一つが故障しても他のパスやデバイスが代替することで、サービスの停止を防ぎます。

## クラウドベンダーのサービスを活用する

### 1. マルチリージョン展開

クラウドベンダーは複数のリージョンを提供しており、これを活用することで地理的な冗長性を確保できます。例えば、AWSではリージョン間でのデータレプリケーションやフェイルオーバーを簡単に設定できます。

### 2. ロードバランサーの活用

ロードバランサーを使用することで、トラフィックを複数のサーバーに分散させることができます。これにより、一部のサーバーがダウンしても他のサーバーがトラフィックを処理し続けることができます。AWSのElastic Load Balancing (ELB)やGCPのCloud Load Balancingなどが代表的なサービスです。

### 3. 自動スケーリング

自動スケーリングを設定することで、トラフィックの増減に応じてサーバーの数を自動的に調整できます。これにより、急なトラフィック増加にも対応でき、サーバーの負荷を分散させることができます。AWSのAuto ScalingやGCPのAutoscalerが利用可能です。

## スクラム開発における実践方法

### 1. スプリントプランニングでの考慮

スプリントプランニングの段階で、ネットワークの冗長性を確保するためのタスクを明確にします。例えば、ロードバランサーの設定やマルチリージョン展開のテストなどです。

### 2. デイリースクラムでの進捗確認

デイリースクラムでは、ネットワーク冗長性に関するタスクの進捗を確認します。問題が発生した場合は、チーム全体で迅速に対応策を検討します。

### 3. レトロスペクティブでの振り返り

スプリントの最後に行うレトロスペクティブでは、ネットワーク冗長性に関する取り組みの成果と課題を振り返ります。これにより、次のスプリントでの改善点を明確にします。

## まとめ

ネットワークの冗長性を確保することは、クラウド環境でのサービスの可用性を高めるために不可欠です。スクラム開発のプロセスに組み込むことで、効率的に冗長性を確保することができます。クラウドベンダーの提供するサービスを最大限に活用し、強固なネットワークインフラを構築しましょう。

## 参考リンク

- [AWS Elastic Load Balancing](https://aws.amazon.com/jp/elasticloadbalancing/)
- [GCP Cloud Load Balancing](https://cloud.google.com/load-balancing)
- [AWS Auto Scaling](https://aws.amazon.com/jp/autoscaling/)
- [GCP Autoscaler](https://cloud.google.com/compute/docs/autoscaler)
【しくじり】周囲を巻き込むことを考慮する

# はじめに
周囲を巻き込まず、自分一人でなんとかしようとしたしくじりの経験を記載していこうと思います。
結論としては、自分一人で抱え込まず、周囲を巻き込んで正しい体制を組もうね、というお話です。

# ダメなリーダーの例
私が実際に経験した前職のとある案件の例を挙げておきます。
とある新しい案件に開発者一人アサインされた時の話です。

・体制
　リーダー1名、その他の対応要員私1名、、、以上！

・リーダーからの伝言
　引き継ぎ資料（かなり雑）がここにあるから確認しといてー。
　俺は場所しか知らないからー、他の技術的なことは何も知らないからー

・スケジュールは？
　もう決まっているから、xx月末までに開発完了させといて

・修正する仕様は固まっている？
　まだ決まってない。というか今日仕様検討会だから、行ってきて:poop:
 　(Д)゜゜ﾒﾀﾞﾏﾄﾞｺｰ

・ 設計やコードのレビューして欲しいんだけど？検証は？
　全部一人でやって！

その他リーダーに聞いても、分からない、お前がなんとかしろの一点張り。
何個か提案したけど、じゃあそれでwってな感じで。

仕様全然固まっていないのに、スケジュールだけはきっちり決まっている開発案件あるあるなの本当におかしいと思ってます。
仕様固まってからスケジュール厳しそうなことを伝えても、スケジュールは動かないとかね（事前にスケジュール変更の要請は出しているのにね）

結局私はこの案件で以下を対応しました。
・他の営業担当者に混じって仕様検討会に出席
・議事録の展開
・仕様調整
・設計、コーティング
・結合テスト
・検証項目の作成、検証
・納品物のまとめ

※俺すげ〜、な話ではないです。

# しくじりポイント
このチーム体制はもちろん問題ですし、
特に初めて関わる案件で初見のアプリのコードなので当然私は知見が無い状態で手探りで修正する羽目になりました。
そのため品質に問題がある可能性が全然ありますよ、とリーダーに言ったのですが、、
お前が全部なんとかしろと。。

これ、<font color="Red">リーダーに言ってダメであればもっと上を巻き込んだほうが良かった</font>と思っています。
例えば部長、もしくは本部長とかにも何なら掛け合っても良かったと思っています。
他のエンジニアやマネジャー層に相談するのもありだったな、と今なら言えますが当時は一人で全部抱えてしまいました。
※本当によくバグ0で乗り切ったもんだ


### 後日談
ちなみにリーダーの作業は、最後の納品物の連絡だけ(笑
しかも一ヶ月後に退職してるし(笑笑😆

自分がリーダーになったらこういうことは絶対にやらないようにしようとココロに誓いました。

### もう一つ追加で後日談

例で挙げた案件が終わってから数ヶ月後に、
当時の部長から過去にお前が関わってたこの案件じゃなんでこんなに利益率高いのか？と聞かれました。
どうも利益率想定の200%越えだったらしいです。

なんで部長がなんにも把握してないんだorz(あのリーダー本当に何にも上に挙げてなかったんだな。。)

見積もったの自分では無いこと、
客との打ち合わせから実装、テスト、納品物の作成まで一人で対応したこと(顧客からのクレーム0だったし)で、
最小工数で奇跡的に対応できたからだと思いますよとイライラと報告したら納得してくれました。
　※前職のベンチャーは、技術力のあるエンジニアが多かったけど、人間的にテキトーな人も多かった

# 最後に
自分一人でなんでも抱え込むのはやめましょう。

以上
【初心者向け】Docker でReact プロジェクトを作成してみる

# はじめに

Docker を使って React プロジェクトを作成する方法を忘れないように備忘録として残しておきます。
この順番でやれば最低限のプロジェクトは作成できます。

## 1. Docker のインストール

まずは Docker のインストールがまだの人は先にDockerインストールします。公式サイトからインストーラーをダウンロードし、指示に従ってインストールを完了してください。

- [Docker Desktop (Windows/macOS)](https://www.docker.com/products/docker-desktop)
- [Docker Engine (Linux)](https://docs.docker.com/engine/install/)

## 2. React プロジェクトの作成

プロジェクト用のディレクトリを作成し、ディレクトリ配下でCreate React App を使って新しい React プロジェクトを作成します。

```bash
npx create-react-app my-react-app
cd my-react-app
```

## 3. Dockerfile の作成
プロジェクトのルートディレクトリに Dockerfile を作成し、以下の内容を追加します。

VScodeでプロジェクトを開いてDockerfileを作成するのが一番やりやすいと思います。

```
# ベースイメージを指定
FROM node:14

# 作業ディレクトリを設定
WORKDIR /usr/src/app

# 依存関係をコピー
COPY package*.json ./

# 依存関係をインストール
RUN npm install

# アプリケーションのソースコードをコピー
COPY . .

# 開発サーバーを起動
CMD ["npm", "start"]

# コンテナが使用するポートを指定
EXPOSE 3000
```

## 4. Docker イメージのビルド
Dockerfile を使って Docker イメージをビルドします。

```
docker build -t my-react-app .
```

## 5. Docker コンテナの実行
ビルドしたイメージを使って Docker コンテナを実行します。

```bash
Copy code
docker run -p 3000:3000 my-react-app
```
ブラウザで http://localhost:3000 にアクセスすると、React のデフォルトのウェルカムページが表示されるはずです。
![スクリーンショット 2024-07-09 16.06.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2120218/e1a04856-fe8e-af8a-f11f-64c15cec6251.png)


## 6. Docker コンテナの停止
Docker コンテナを実行した後、必要に応じてサーバーを停止する方法について説明します。

まず、現在実行中の Docker コンテナの一覧を表示します。

```bash
Copy code
docker ps
```
このコマンドを実行すると、実行中のコンテナの一覧が表示されます。コンテナ ID と名前を確認できます。

```plaintext
Copy code
CONTAINER ID   IMAGE          COMMAND        CREATED          STATUS          PORTS                    NAMES
abc123def456   my-react-app   "npm start"    5 minutes ago    Up 5 minutes    0.0.0.0:3000->3000/tcp   vibrant_tesla
```
ここで、CONTAINER ID 列の ID（例えば abc123def456）を使用して、コンテナを停止します。

```bash
Copy code
docker stop abc123def456
```
コンテナが正常に停止されると、docker ps を再度実行してもそのコンテナは一覧に表示されなくなります。

docker psで表示されたコンテナを一気に停止したい場合は以下のコマンドを実行してください。

```bash
docker stop $(docker ps -q)
```

# まとめ
この記事では、初心者向けに Docker を使って React プロジェクトを作成し、コンテナを実行および停止する方法を説明しました。以下が基本的な流れです。
実際に作ってみると思ったよりも簡単に作成できるので是非一度プロジェクトを作成してみてください。
インフラの状態を定期的に評価する方法：スクラム開発でのベストプラクティス


## はじめに

スクラム開発において、インフラの状態を定期的に評価することは非常に重要です。クラウドベンダーの多様なサービスを活用しながら、プロダクトの品質を高めるための方法について解説します。

## インフラ評価の重要性

インフラの状態を定期的に評価することで、以下のようなメリットがあります：

- **パフォーマンスの最適化**：リソースの使用状況を把握し、必要に応じてスケールアップやスケールダウンを行うことができます。
- **コスト管理**：無駄なリソースを削減し、コスト効率を高めることができます。
- **セキュリティの強化**：脆弱性を早期に発見し、対策を講じることができます。

## 評価のタイミング

スクラム開発では、スプリントの終了時やリリース前にインフラの評価を行うことが一般的です。しかし、以下のようなタイミングでも評価を行うことが推奨されます：

- **新しい機能のリリース前**：新しい機能がインフラに与える影響を事前に評価します。
- **トラフィックの増加時**：予期せぬトラフィックの増加に対応するため、リソースの状態を確認します。
- **定期的なメンテナンス**：定期的にインフラの状態をチェックし、問題がないか確認します。

## 評価の方法

### 1. モニタリングツールの活用

クラウドベンダーが提供するモニタリングツールを活用することで、インフラの状態をリアルタイムで把握できます。例えば、AWSのCloudWatchやAzureのMonitorなどがあります。

### 2. 自動化スクリプトの作成

定期的な評価を自動化するために、スクリプトを作成することが有効です。例えば、PythonやShellスクリプトを使用して、リソースの状態をチェックし、レポートを生成することができます。

### 3. アラート設定

異常が発生した際に即座に対応できるよう、アラートを設定しておくことが重要です。モニタリングツールと連携して、特定の条件を満たした場合に通知を受け取るように設定します。

## ベストプラクティス

### 1. 定期的なレビュー

スプリントの終了時やリリース前に、チーム全体でインフラの状態をレビューする時間を設けましょう。これにより、全員がインフラの現状を把握し、必要な対策を講じることができます。

### 2. ドキュメントの整備

インフラの評価結果をドキュメントとして残しておくことで、後から参照しやすくなります。評価の方法や結果、対策などを詳細に記録しておきましょう。

### 3. 継続的な改善

インフラの評価は一度行えば終わりではありません。定期的に評価を行い、継続的に改善を図ることが重要です。新しいツールや技術を取り入れることで、評価の精度を高めることができます。

## まとめ

インフラの状態を定期的に評価することは、スクラム開発において非常に重要です。モニタリングツールの活用や自動化スクリプトの作成、アラート設定などを駆使して、インフラの健全性を保ちましょう。定期的なレビューやドキュメントの整備、継続的な改善を行うことで、プロダクトの品質を高めることができます。

皆さんもぜひ、これらのベストプラクティスを取り入れて、インフラの評価を行ってみてください。
ITパスポート 入出力インタフェース

・入出力インタフェース
コンピュータ本体と周辺装置の接点

・USB
PCと、HDDやプリンタなどの多種多様な周辺装置を接続するための標準的なインタフェース
Type-A, Type-B, Type-B mini, Type-B micro, Type-C
・ホットプラグ
PCの電源を入れたままケーブルの脱着ができる方式
・プラグアンドプレイ
PCにケーブルを差し込むとOSが自動認識し、必要な設定が行われる方式
・バスパワー方式
USBのケーブルを介して、必要な電力をPC本体から供給する方式

・HDMI
映像や音声、制御信号を、１本のケーブルで入出力できるAV機器向けのインタフェース

・ポートリプリケータ
USBやHDMI、LANなどの複数のポート（差し込み口）を装備した機器

・無線インタフェース
・Bluetooth
電波を利用した無線通信のインタフェース
2.4GHz帯の電波を利用し、半径数mから数十mの範囲で通信できる
・BLE（Bluetooth Low Energy）
超省電力でIoT機器にも利用される

・IrDA
赤外線を利用した無線通信のインタフェース

・RFID
ICチップと小型アンテナを埋め込んだ荷札
汚れに強い、格納ができるデータ量が大きい、内容の書き換えができるなどの特徴がある
・NFC
RFIDの国際規格

・デバイスドライバ
PCに接続されている周辺機器を制御・操作するためのソフトフェア
C_TS452_2021 - SAP Certified Application Associate - SAP S/4HANA Sourcing and Procurement対策（5/100）

【5日目】
トピック1：企業構造とマスタデータ（5/11）

≪問題5≫
品目マスタの購買グループを更新するレベルはどれですか。
□クライアント
□プラント
□購買組織
□会社コード

≪解答≫
□クライアント
■プラント
□購買組織
□会社コード

≪解説≫
◆購買グループは、特定の購買活動に関する責任を負う購買担当者または購買担当グループを表すキーです。内部的には、購買グループによって品目または品目グループの調達が管理されます。外部的には、購買グループは仕入先に対する担当者の役割を果たします。ただし、購買組織やプラントなどの企業構造の他の単位に割り当てることはできません。
◆購買グループは、プラントレベルで個々の品目に割り当てられます。また、購買グループは、権限管理によって制限がなければ、すべての購買組織およびプラントに対して有効にすることが可能です。
スクラム開発におけるリリース管理を徹底する方法


## はじめに

スクラム開発において、リリース管理はプロジェクトの成功に欠かせない要素です。リリース管理がしっかりしていないと、プロダクトの品質が低下し、チームの生産性も下がってしまいます。この記事では、クラウドベンダーのサービスを活用しながら、リリース管理を徹底する方法について詳しく解説します。

## リリース管理の重要性

リリース管理は、プロダクトのリリースプロセスを計画し、実行し、監視するための一連の活動です。これにより、以下のようなメリットがあります：

- **品質の向上**：リリース前に十分なテストを行うことで、バグや不具合を減少させることができます。
- **透明性の確保**：リリーススケジュールや進捗状況をチーム全体で共有することで、透明性が高まります。
- **リスクの軽減**：リリース前にリスクを特定し、対策を講じることで、リリース後のトラブルを減少させることができます。

## クラウドベンダーのサービスを活用する

クラウドベンダーのサービスを活用することで、リリース管理を効率化することができます。以下に、いくつかの具体的なサービスとその活用方法を紹介します。

### CI/CDツールの活用

継続的インテグレーション（CI）と継続的デリバリー（CD）は、リリース管理において非常に重要です。クラウドベンダーが提供するCI/CDツールを活用することで、リリースプロセスを自動化し、効率化することができます。

- **AWS CodePipeline**：AWSのCI/CDサービスで、コードのビルド、テスト、デプロイを自動化できます。
- **Azure DevOps**：MicrosoftのCI/CDツールで、パイプラインの設定が簡単に行えます。
- **Google Cloud Build**：Google CloudのCI/CDサービスで、スケーラブルなビルド環境を提供します。

### モニタリングとアラート

リリース後のプロダクトの状態を監視し、問題が発生した際には迅速に対応することが重要です。クラウドベンダーのモニタリングサービスを活用することで、リアルタイムでプロダクトの状態を把握することができます。

- **AWS CloudWatch**：AWSのモニタリングサービスで、リソースの使用状況やアプリケーションのパフォーマンスを監視できます。
- **Azure Monitor**：Azureのモニタリングサービスで、ログの収集やアラートの設定が行えます。
- **Google Cloud Monitoring**：Google Cloudのモニタリングサービスで、リソースの監視やアラートの設定が可能です。

### インフラストラクチャの自動化

インフラストラクチャの設定や管理を自動化することで、リリースプロセスをさらに効率化できます。クラウドベンダーが提供するインフラストラクチャ自動化ツールを活用しましょう。

- **AWS CloudFormation**：AWSのインフラストラクチャ自動化ツールで、リソースの設定をコードで管理できます。
- **Azure Resource Manager**：Azureのインフラストラクチャ自動化ツールで、リソースのデプロイを簡単に行えます。
- **Google Cloud Deployment Manager**：Google Cloudのインフラストラクチャ自動化ツールで、リソースの設定をコードで管理できます。

## リリース管理のベストプラクティス

最後に、リリース管理を徹底するためのベストプラクティスをいくつか紹介します。

### 1. リリース計画を立てる

リリース計画を立てることで、リリースのスケジュールや必要なタスクを明確にすることができます。計画には、リリースの目的、スケジュール、リソース、リスクなどを含めると良いでしょう。

### 2. テストを徹底する

リリース前に十分なテストを行うことで、バグや不具合を減少させることができます。ユニットテスト、統合テスト、エンドツーエンドテストなど、さまざまなテストを実施しましょう。

### 3. フィードバックを重視する

リリース後のフィードバックを重視し、次回のリリースに活かすことが重要です。ユーザーやチームメンバーからのフィードバックを収集し、改善点を特定しましょう。

### 4. 継続的な改善を行う

リリース管理は一度設定すれば終わりではありません。継続的にプロセスを見直し、改善を行うことで、より効率的なリリース管理が可能になります。

## まとめ

リリース管理を徹底することで、プロダクトの品質を向上させ、チームの生産性を高めることができます。クラウドベンダーのサービスを活用し、リリースプロセスを自動化・効率化することで、よりスムーズなリリースが実現できます。この記事で紹介した方法やベストプラクティスを参考に、リリース管理を徹底してみてください。
Java初学者へサポートする事を考える

# 概要
会社の人材育成を目的にJavaを知らない人がJava初学者へサポートできることを考える

# 確認事項
## 受験資格はOracle Certified Java Programmer, Silver SE 11
https://www.oracle.com/jp/education/certification/1z0-816-jpn-31705-ja.html
> 関連資格：Oracle Certified Java Programmer, Silver SE 11
> 受験料（税込）：37,730 円 価格ポリシーについて
> 出題形式：選択問題
> 試験時間：180 分
> 出題数：80 問
> 合格ライン：63 %

180分の試験なので、きつそうな印象であるが、合格ラインは低い。

## 学習教材
あとで正式名を確認するが、すでに購入済
これでも出題範囲は確認可能。↑のリンクにも掲載されている

# 出来る事リスト（案）
1. 希望があれば、なんでもどうぞ。
1. 学習スケジュールを作る。これがないと始まりません。作成に協力することは可能です。スケジュールが厳しければbronzeや他の学習に切り替えることも検討する。**もう難しいのではないか？**
https://jagi.hatenablog.com/entry/2024/05/15/195546
1. 問題でわからないところの解説
1. 業務の即戦力になりたいなら、資格取得を辞めてアプリケーションを作る学習にシフトしましょう
https://qiita.com/tmoritoki0227/items/d886b8ff290c8731cef1
1. まだ学習を始めてないなら、まずは全体像の把握から始めましょう。模擬試験で問題の傾向を確認するか、動画から入りましょう。
https://m.youtube.com/results?search_query=java+silver
1. Ruby試験の経験談を伝える。java合格体験記を紹介。試験は効率良く合格する方法を知ってから対策に取り組みましょう。満点目指すのはやめましょう。教本にはあるが問題集にない知識は一旦捨てましょう。
https://search.yahoo.co.jp/search?p=Java%20silver%20%E5%90%88%E6%A0%BC%E4%BD%93%E9%A8%93%E8%A8%98&iau=0&ei=UTF-8
（参考）過去にRuby勉強で作ったノート：https://qiita.com/tmoritoki0227/items/17c818c6a220ad2500d7
1. 家でjavaを実行できる環境はありますか?オンラインの実行環境もあります。座学だけでも合格は可能です。
https://paiza.io/ja/languages/online-php-editor

1. 試験の申込の準備をする。準備とは「あとはこのURLから日程調整するだけ」としておくのがお勧めです。申し込みにはアカウント作ったりと結構大変です。スケジュールと一緒に作成を済ませるのがおすすめです。
**（参考）早めに登録しましょう。非常に難しかった。**
https://www.oracle.com/jp/education/certification/examinfo-172594-ja.html#take
https://manabiya-sakura.com/information_technology/id=1554/
https://www.oracle.com/jp/education/guide/newuser-172640-ja.html
1. 試験センターがどういうものか知らなければ説明する
1. AIを使っているか。使ってないなら使えるようにする。疑問点はAIにまず聞いてみよう。
1. 学習を阻害しているものはありますか？勉強が続かない、やる気が出ないという課題があれば、対策を考える。定期なミーティング（一回１５分でも）を希望があれば実施します。ミーティングの内容は進捗の確認や、学習の進め方の相談、問題の解説になると思います。

# 試験問題サンプル
https://se-media.jp/java/3113/
# 「最も使っている」プログラミング言語で異変、前年首位のJavaが王座陥落
https://xtech.nikkei.com/atcl/nxt/column/18/02670/112900001/

# IT資格ランキングを初級・上級別にご紹介！【メリットや注意点も】
https://last-data.co.jp/media/it-license-ranking/

# 同じエンジニアでも年収に差が出る。日本のエンジニアの「稼げるIT資格」とは？
https://www.korekara-freelance.com/paying-certifications/1816/

# 収入が上がるスキル
何か資格を取るだけで、収入が上がるというケースは稀だと思います。
一概に言えませんが、上流工程の経験、例えば設計の経験を積んでいる人ほど収入アップに有利です。プログラミング、運用だけでは厳しいです。そのため、設計、開発の経験を積みましょう。

単純に英語が出来る人は重宝されます。外国人とのやり取りを任させれたり、最新の技術ドキュメントは英語なので、技術習得に有利です。


# 資格を取って業務範囲が広がったことがあるか？
ありません。実際の業務で業務貢献しないと業務範囲拡大は難しいと思います。
努力家、成長志向のある人だという印象は持たれます。
会話のきっかけになることはあります。
アピール出来る資格は上級の資格で、国家試験だとなお良いです。


# Javaエンジニアの求人

https://doda.jp/keyword/%E6%9D%B1%E4%BA%AC%E9%83%BD%E3%80%80%EF%BD%8A%EF%BD%81%EF%BD%96%EF%BD%81/

## 求人スキル紹介
求人では以下のようなものが求められています。今後の勉強で意識してみては？


・Javaを用いた開発実務経験3年以上
・Struts、Spring、Play等主要なフレームワークでの開発経験
・Gitを用いたプルリクベースのチーム開発経験
・WebAPIの設計・開発経験
・Dockerを利用した開発経験

---

・Javaの開発経験（3年以上）
・業務システム開発経験（SI/PKGなど）
・基本設計以降一通りの経験

---

・Java,C言語,C++などの言語を用いた開発経験

---


・システム開発経験
※JavaもしくはC#での開発経験をお持ちの方
上流工程から下流工程まで幅広くご経験された方

---

・JAVA開発経験
・リーダー経験　または　設計/方式検討などのアーキテクト関連の経験

---

・IT業界における、アプリケーションエンジニアとしての5年以上の経験
・実業務でのJava言語（JavaSE～JavaEE）によるシステム開発経験者

---

・C#およびJavaを使用したシステム開発経験
・チームとして活動できるコミュニケーション能力

---

・Webオープン系開発（JavaやPythonを優遇）の経験が３年以上ある方
・IT分野の資格を一つ以上所有している方
・明朗快活であり、協調性、積極性を兼ね備えている方

---
SourceTree で、push した commit を完全に消す方法

# 背景

Git で hard reset のメモです。

正直、こんなことすることが来るとも思ってなかった・・

Azure Pipelines で New Pipeline をすると、Default で Commit してしまうので、どうしても戻したくなった為。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/ce56c9a6-8a8f-d105-0cc5-afde0686d5c1.png)

# 方法

1. SourceTree で戻したい hash を取得
   ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/aa66a641-1814-f89e-2386-b68532a0eebc.png)

1. ターミナルを起動
   ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/c8324101-1a9d-059d-c9e0-91a49db0708d.png)

1. local を hard reset
   ```git: 対象まで戻す
   git reset --hard {hash}
   ```
   
1. origin に反映
   :warning: 
   ```git: リモートへの反映
   git push origin -f
   ```

# あとがき

ここの設定、Default で変える方法欲しいなぁとか思いつつ、
二回目以降は、branch 作られても面倒だし、やっぱりこの Default が正解かな。 :sweat_smile: 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/2ceb86c6-5aa6-d4ff-aa5b-999213d54033.png)
C_TS452_2021 - SAP Certified Application Associate - SAP S/4HANA Sourcing and Procurement対策（4/100）

【4日目】
トピック1：企業構造とマスタデータ（4/11）

≪問題4≫
会社間共通購買組織の設定時に更新すべきではない組織割当はどれですか。
□プラント-購買組織
□参照購買組織-購買組織
□プラント-購買グループ
□会社コード-購買組織

≪解答≫
□プラント-購買組織
□参照購買組織-購買組織
□プラント-購買グループ
■会社コード-購買組織

≪解説≫
◆購買組織は、ロジスティクス内の組織ユニットであり、購買の要件に応じて会社を細分化するためのものです。
◆購買組織の機能を指定するには、購買組織を会社コード（オプション）およびプラント（必須）に割り当てる必要があります。
◆以下のような調達形態が考えられます。
（1）企業グループ共通：1つの購買組織が、すべての会社コードを担当します。
（2）会社固有：1つの購買組織は、1つの会社コードのみを担当します。
（3）プラント固有：1つの購買組織は、1つのプラントのみを担当します。
◆購買組織が会社コードに割り当てられている場合は、その会社コードに属するプラントのみを購買組織に割り当てることができます。また、購買組織が会社コードに割り当てられていない場合は、すべての会社コードのプラントを購買組織に割り当てることが可能です。
◆参照購買組織を使用すると、購買組織共通の調達トランザクションを実行することができます。これにより、購買数量を増やすことができ、より有利な条件で合意できる集中契約を利用できるほか、条件の更新も簡略化されます。
スタートアップ企業のエンジニア3ヶ月の総括。

# はじめに
とてつもなく早く過ぎたような気がしましたが、気づけばエンジニアをして3ヶ月。どんな業務をしてきたのかと共に、3ヶ月ならではの悩みや課題を共有いたしますので、ぜひこれからエンジニアを目指す方々の参考になればと思います。

# 業務内容
　- Shopifyフロント改修
　- 新規Shopifyページ作成
　- テックブログ執筆←NEW
　- Python使ったSalesforceとShopifyの連携←NEW

## NEWタスク１：テックブログ執筆
実は前職でもなかったテックブログの記事執筆をいたしました。
ちょうどこの前出たShopify Editions 2024 Summerが出たのでその機能を触ってみたというやつです（多分まだ出てないですが）
何より難しかったのは、「誰にみてもらうのか」によって体裁が変わる点です。新規向けのブログならあまり用語を使えないし、使っても解説が必要なので記事の分量が増えるという難点があるので、うまく混ぜ合わせる努力が必要です。
逆にすでに知識のある人へのブログには、舐められないような深い調査が必要です。抜け漏れの内容ダブルチェックなどで整合性を担保しながら記事を作ってました。

## NEWタスク2：Python使ったSalesforceとShopifyの連携
Liquidもプログラミングとはいえ、個人的には初めてのガチプログラミングタスクでした。
何よりまずスタートはPythonとLambdaの学習、SalesforceのAPIについて学習、ShopifyのGraghQLについて学習→フローチャート書いてみる→テスト環境で叩く→本番反映というかなりの道のりでした。
ただ自分としてはすごいエンジニアっぽいタスクを振られてすごく嬉しかったです。またこれは言語化できたら記事化したいです。

ちょっと忙し過ぎてこれ以上書けないです。。
もう4ヶ月目に入ってしまってますが、今月はデザインにも足を踏み入れているので、またそれは4ヶ月目の総括で話したいと思います。
社内SEとして求められた役割を勘違いして1年で辞めた話

2023年6月から、1年間、社内SEとして働きました。

そこで感じたことをシェアします。

# なぜ前職を・なぜ社内SEを選んだのか

- 東京で働けるだけの給料が欲しかった
- 過去の経歴を活かせる可能性が高かった
- CTOから仕事を回してもらえる可能性があった

Web制作系の職場でした。

# 会社からは何を期待されていたのか

## 【1】プログラミングで分からない事やバグが出た時にいて欲しい

企業には、何かしらITに関連するビジネスモデルがあるはずです。
その潤滑油としての役割が社内SE何だと思います。
そういった状況の企業だと、プログラムが少しでも分かる人がいないとバグが発生した時に詰む可能性があります。

そういった状況を回避することが、社内SEに期待される役割な訳です。

## 【2】他人が使えるような既存の技術の中でやりくりして欲しい

- 便利だから
- 効率が良いから

そういったものは社内SEには求められていません。
基本的には今発生している小さな課題をいかに早くクリアするかだけが重要です。
また新しい技術や変化によって生じる負の影響（学習や移行のコスト）は嫌われます。

## 【3】立場は間違いなく弱い

潤滑油ですもん、そりゃそうです。
会社の利益を直接生み出していはいないわけですから。

なので基本的には希望は通りません。
しかしいなくなると困るので、とても大切にはされます。
（このバランスもあまり居心地が良いものではなかった）

# これから社内SEになるならせめてCTOなどの技術職から仕事を振ってもらえるように立ち回るべき

これだけは前職で良かった点です。
1年だけとはいえ、社内SEとしてだけ働いていたら、LaravelもDjangoもRailsも関わらせてもらえなかったと思います。
職歴に書けるかどうかっていうのは大きいです。

# まとめ

結果的には、自分がやりたかったこと・会社からの期待にミスマッチがあり、長く働き続けることができませんでした。

「良く考えて選べ！」
と言われるかもしれませんが、むしろ考えすぎた結果がこれなんですよね...

向き不向きがある職種だと思いますし、今後のキャリア選択の参考になれば幸いです。
ABC243Dを解いた


筆者はレート600前後の茶色コーダ

7/9のADTで出題された以下のABCの過去問題を解いていく

https://atcoder.jp/contests/abc243/tasks/abc243_d

ADT(ALL)のページ

https://atcoder.jp/contests/adt_all_20240709_1/tasks/abc243_d

# 実装コード

完全二分木なので、親ノードに行くには半分にして
子ノードに行くには左の子なら2倍して、右の子は2倍して更に+1すればOK、
と思ったがTLE、数が大きいので掛け算に時間がかかるようだ。bit演算にしてもTLEは解消せず[^bit_op]

[^bit_op]: たしかPythonのbit演算って多倍長整数を使っている関係上、結局裏で四則演算していた記憶(要出典)。だからこの修正は意味なかった。

```python:TLEコード
import sys
def rI(): return int(sys.stdin.readline().rstrip())
def rLI(): return list(map(int,sys.stdin.readline().rstrip().split()))
def rS(): return sys.stdin.readline().rstrip()
def rLS(): return list(sys.stdin.readline().rstrip().split())
def err(*args): print(*args, file=sys.stderr)

def main():
    N, X = rLI()
    S = rS()
    ans = X
    for s in S:
        if s == 'U':
            ans //= 2
            #ans >>= 1 bit演算にしても同じくTLE
        else:
            ans *= 2
            #ans <<= 1
            if s == 'R': ans += 1
            #if s == 'R': ans |= 1
    print(ans)
if __name__ == '__main__':
    main()

```

ここで解説を見たが、bit演算の要領で文字列を管理して、最後に計算すればいいみたい。解説通りに実装するのは面白くないのでリストと整数値を使った計算をして最後に進数変換した値を出力する感じにしてみた。

```python:ACコード
import sys
def rI(): return int(sys.stdin.readline().rstrip())
def rLI(): return list(map(int,sys.stdin.readline().rstrip().split()))
def rS(): return sys.stdin.readline().rstrip()
def rLS(): return list(sys.stdin.readline().rstrip().split())
def err(*args): print(*args, file=sys.stderr)

def main():
    _, X = rLI()
    S = rS()
    bx = bin(X)[2:]
    bits = [int(x) for x in bx]
    for s in S:
        if s == 'U':
            bits.pop()
        elif s == 'L':
            bits += [0] 
        elif s == 'R':
            bits += [1]
    ans = [b*(1<<i) for i,b in enumerate(reversed(bits))]
    print(sum(ans))
if __name__ == '__main__':
    main()

```

# まとめ

ABC243Dを解いた、普通に計算するとTLEが出たので値を一回リストで管理して最後に値を求めるようにすることで解くことがた。

# 感想

完全二分木なので簡単に解けるだろうと思ったが普通にTLEが出て解説を見たが、
大きめの値を掛け算すると時間がかかるという認識がなかった。
次からは大きめの値を掛け算する必要があるときは工夫して値を出すようにしたい。
Docker初心者に送る言葉

ポエムです。スクショも検証もなくていい。怠惰なエンジニアはポエムを書くべきである。ポエムすら生成ＡＩに任せたい。
Dcoker初心者向けの話。
巷にいろいろ初心者向けがあふれかえっているわけなんですが、あんま見かけないのが「じゃあDockerがなかった時代はどうやってたの[おじいちゃん|おばあちゃん]」である。
結局のところ、あらゆるテクノロジについて、初心者にまず説明するべきは「これがなかったらどうなってたことやら」を理解してもらわないとだめなんだって。

じゃあ、Dockerに限った話をする。
こいつがなかったらどうなるか。お前は、お前が面倒を見ているシステムなり、開発している動かないコードだったりを動かすために使っているあらゆる他人が作ったプログラム関連がバージョンアップされるたびに、再インストールしなければならない。
再インストールしたら、他人（昨日までのお前を含む）が作ったクソコードはバージョン依存で動かなくなるかもしれない。その場合戻しようもない。お前はもうどうしようもないだろう。
コンテナ化するとバージョンを変えたいモジュールだけ入れ替えられる。しかも環境影響まったくなしだ。コンテナならバージョンを指定してインストールできるからだ。お前のバージョン依存のクソコードだって難なく動かせるだろう。顔も知らないもう辞めたナイス・ガイのコードだって動くだろう。

単にこれのためだけにDockerは存在する。
その動作原理はLinux標準（俺から言わせればSolarisだ。最初に見たプロセス分離を親と思う生き物だからだ）機能だ。
初学者はそこをまず理解するべきである。Docker ComposeだろうがKubernetesだろうがArgo CDだろうが、これがわかればわかるんだ。
【覚書き】clearコマンドで表示を消す

# clearコマンドとは
clearコマンドとは、**実行結果を削除するためのコマンド**です。

# 実行例
以下のようなコマンドラインがあるとします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/430841/a54b9746-995b-29fd-adc5-8af26bd54c62.png)

これに対して、`clear`コマンドを実行すると、表示がリセットされ、画面が綺麗になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/430841/3d0949b2-da8d-846c-92eb-fcf717187110.png)

画面を綺麗にしたい時に使う感じですね。

# 主なオプション
## `-x`：削除せずにスクロールする
通常の`clear`コマンドは画面の表示を全て削除するのに対し、-xコマンドは完全には消しません。その代わり、画面外までスクロールを行うことで見た目のみすっきりさせます。

例えば、以下のような画面で`clear-x`を実行するとしましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/430841/a4560cce-3ade-6441-dfd5-32e1dde4fae7.png)


すると、画面から表示が消え、綺麗になったかのように思えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/430841/13a65aad-9a15-2bfe-6356-a337e6c29bad.png)

が、上にスクロールすると内容が残っていることが分かります。

![Animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/430841/d276ad34-8872-f8b5-bc19-2b970ddc3678.gif)

内容は残しておきたいけど表示だけすっきりさせたい場合はこちらを使うのがよさそうですね。

# 最後に
今回はclearコマンドについて覚書きしました。
linuxコマンドを覚えていきたいので、知り次第こまめにアウトプットしていきます。
ベンダーロックインを回避する戦略：クラウド時代の賢い選択


## はじめに

クラウドサービスの普及に伴い、多くの企業がクラウドベースのソリューションを採用しています。しかし、クラウドベンダーに依存しすぎると、いわゆる「ベンダーロックイン」のリスクが高まります。この記事では、ベンダーロックインを回避するための戦略について詳しく解説します。

## ベンダーロックインとは？

ベンダーロックインとは、一度特定のクラウドベンダーのサービスを利用し始めると、そのベンダーから離れることが難しくなる状況を指します。これにより、コストの増加や技術的な制約が生じる可能性があります。

## ベンダーロックインのリスク

1. **コストの増加**: ベンダーの価格変更に対して柔軟に対応できない。
2. **技術的制約**: 特定のベンダーの技術に依存することで、他の技術を採用するのが難しくなる。
3. **移行の困難さ**: 他のベンダーに移行する際のコストや時間が大きくなる。

## ベンダーロックインを回避する戦略

### 1. マルチクラウド戦略の採用

複数のクラウドベンダーを利用することで、特定のベンダーに依存しない環境を構築します。例えば、AWSとAzureを併用することで、どちらか一方に問題が発生しても、もう一方でサービスを継続できます。

### 2. オープンソース技術の活用

オープンソースの技術を積極的に採用することで、特定のベンダーに依存しないシステムを構築できます。例えば、Kubernetesを利用することで、どのクラウドベンダーでも同じコンテナオーケストレーションを実現できます。

### 3. 標準化されたAPIの利用

標準化されたAPIを利用することで、異なるクラウドベンダー間での移行が容易になります。例えば、RESTful APIを利用することで、異なるバックエンドサービス間でのデータのやり取りがスムーズに行えます。

### 4. インフラストラクチャー・アズ・コード（IaC）の導入

IaCを利用することで、インフラの設定をコードとして管理できます。これにより、異なるクラウドベンダー間でのインフラの再現が容易になります。TerraformやAnsibleなどのツールを活用するのが一般的です。

### 5. サービスの抽象化

サービスを抽象化することで、特定のクラウドベンダーに依存しない設計を実現します。例えば、データベースアクセス層を抽象化することで、異なるデータベースサービス間での移行が容易になります。

## まとめ

ベンダーロックインを回避するためには、複数のクラウドベンダーを利用するマルチクラウド戦略や、オープンソース技術の活用、標準化されたAPIの利用などが有効です。これらの戦略を組み合わせることで、柔軟でスケーラブルなクラウド環境を構築できます。

クラウドサービスの選択は慎重に行い、将来的なリスクを最小限に抑えるための対策を講じることが重要です。この記事が、皆さんのクラウド戦略の参考になれば幸いです。
Loguruでログを取る③

# これまで
1. [Loguruでログを取る①](https://qiita.com/i-am-misaki/items/9b4dc4d570f61408795e)
2. [Loguruでログを取る②](https://qiita.com/i-am-misaki/items/1487e56934aa6e776883)



# 実用向け

```python
logger.add("file_app.log", backtrace=True, diagnose=True)

def func(a, b):
    return a / b

def nested(c):
    try:
        func(5, c)
    except ZeroDivisionError:
        logger.exception("What?!")

nested(0)
```
__結果__
![スクリーンショット 2024-07-10 212740.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3634951/a09567f9-f499-6fbc-f0ef-6a1a10d0d533.png)

- __backtrace__
エラーを生成した完全なスタックトレースを表示するかどうか
<!-- (ただ上記の場合、logger.exception()になっているので必要ない) -->

- __diagnose__

デバッグを容易にするために、例外トレースに変数の値を表示するかどうか

:::note alert
デフォルトは __True__ になっているので、
機密データの漏洩を防ぐため、本番環境ではこれを __False__ に必ず設定する
:::
- __logger.exception()__
例外のトレースバックとともにERRORレベルのメッセージをログに記録する

<br></br>
###### backtrace, diagnose以外にもパラメータはあるので、下記参照

https://loguru.readthedocs.io/en/stable/api/logger.html


# logger.exception()とlogger.error()の違い
#### logger.exception()
- キャッチされた例外のメッセージとトレースバックの両方をログに記録
- トレースバック情報は自動的に含まれる

#### logger.error()
- logger.{level}()・・・levelのメッセージを記録するため
- トレースバック情報は自動的に含まれない
RailsでOmniAuth-GitHubを利用してログインをしようとした時に、turboが邪魔をしてgithubのログイン画面にいけなかった現象について。Not found. Authentication passthru.

## 読んで欲しい人
- 下記の記事を参考に開発を進めていて`Not found. Authentication passthru.`の表示になった人
    - https://fuga-ch85.hatenablog.com/entry/2021/04/10/075536
    - https://github.com/heartcombo/devise/wiki/OmniAuth:-Overview
- 過去の俺

## 動作環境

- ruby 3.3.0
- Rails 7.1.3.3

## ハマった現象

- 上記で紹介した「omniauthを使ってgithub認証を実装する」の設定が一通り終わり、いざ`user_github_omniauth_authorize_path`リンクを設置して、ボタンを押した時に`Not found. Authentication passthru.`という文言が出てきて、githubの認証画面に遷移できない状態


ボタンの画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3819522/82fe5861-16ef-9ea5-9975-66b5dc3a4ca8.png)

遷移後の画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3819522/52a88ba3-18ee-4d4e-1e5f-7a1abe01d20f.png)

リンクを設置したファイル
```haml
%div
  %p　下記のボタンを押してログインしてください
  = link_to 'GitHubでログインする', user_github_omniauth_authorize_path, class: 'btn'

```

## 解決

- `link_to`ではなく`button_to`にした
- turboをオフにした


```diff_haml
- = link_to 'GitHubでログインする', user_github_omniauth_authorize_path, class: 'btn'
+ = button_to 'GitHubでログインする', user_github_omniauth_authorize_path, class: 'btn', data: { turbo: false }
```

### 解説

- `link_to`ではなく`button_to`にした

ドキュメントにpostメソッドを使用してくれと書いてあった

> OmniAuth 2.0+ requires using HTTP POST as the request method to initiate the authentication, so your link should be configured with method: :post: (this requires rails-ujs or similar to create POST requests)

OmniAuth 2.0+ では認証を開始するためのリクエストメソッドとして HTTP POST を使用する必要があります


- turboをオフにした

ドキュメントに書いてあった

> If you're using Turbo you'll likely get a CORS error, and must disable it:
> `<%= button_to "Sign in with Facebook", user_facebook_omniauth_authorize_path, data: { turbo: false } %>`

Turboを使用している場合、CORSエラーが発生する可能性が高いので、無効にする必要があります

### なぜCORSエラーが発生するのか？

- Turboが非同期的に通信をめっちゃするので、異なるオリジンからのリクエストが増えて、サーバー側で適切なCORSポリシーの設定が求められるから

[そもそもCORSとは？](https://qiita.com/att55/items/2154a8aad8bf1409db2b)
[そもそもturboとは？](https://zenn.dev/shita1112/books/cat-hotwire-turbo/viewer/abstract)

turboは色々なオリジンへリクエストを投げて早くサイトの変更をしてくれる。一方、CORSのオリジンポリシーというルールに違反するのでエラーが発生しちゃう

↑

間違っていればご指摘ください

## 感想・学んだこと
- 全く未知の状態から学んだので、大変だった。
- ドキュメント大事だなぁ
- CORSやturboなど意識しなければわからない部分を理解することで視野が広がった。
ZIO HTTPに入門する

# 概要

このブログでは、ZIO HTTPを使ったシンプルな"Hello, World!"アプリケーションの作成方法を紹介します。

## サンプルコード

以下のコードは、`zio-http`を使用してHTTPサーバーを構築し、`/hello`エンドポイントに対して"Hello, World!"というレスポンスを返すアプリケーションの例です。

```scala
import zio._
import zio.http._

object Main extends ZIOAppDefault {
  val routes: Routes[Any, Response] =
    Routes(
      Method.GET / "hello" ->
        handler(Response.text("Hello, World!"))
    )

  def run: ZIO[Any, Throwable, Nothing] = {
    Server.serve(routes).provide(Server.default)
  }
}
```

### コードの詳細

#### ルーティングの定義

```scala
val routes: Routes[Any, Response] =
  Routes(
    Method.GET / "hello" ->
      handler(Response.text("Hello, World!"))
  )
```

この部分では、HTTP GETリクエストが`/hello`に対して行われたときに、"Hello, World!"というテキストレスポンスを返すようにルーティングを定義しています。

#### サーバーの起動

```scala
def run: ZIO[Any, Throwable, Nothing] = {
  Server.serve(routes).provide(Server.default)
}
```

`run`メソッドでは、サーバーを起動するための処理を定義しています。ここで重要なのは、`Server.serve(routes)`の部分です。このメソッドは、指定されたルーティングに基づいてサーバーを起動します。

### `Server.serve`の戻り値

`Server.serve`メソッドの戻り値は`URIO[Server, Nothing]`です。`URIO`は型エイリアスで`ZIO[Server, Nothing, Nothing]`とも表現できます。この型は、`Server`を要求し、失敗しないことを示しています。

### `provide`による依存関係の注入

```scala
Server.serve(routes).provide(Server.default)
```

`provide`メソッドを使用することで、`Server`を注入しています。ここでは、`Server.default`が注入されます。

### `Server.default`とは

`Server.default`は、デフォルトのサーバー設定を提供するためのものです。この設定には、標準的なポート（通常は8080）やホスト名（通常はlocalhost）が含まれます。開発中はこのデフォルト設定で十分ですが、本番環境ではカスタマイズが必要な場合があります。

## まとめ

このブログでは、`zio-http`を使用してシンプルなHello, Worldアプリケーションを作成する方法を紹介しました！