OmniAICreator/Qiita-1.07M huggingface dataset:
Git操作で使用しているコマンド

本記事では、私が主にVSCodeを用いて作業を行う際、実際に使用するGitのコマンドを紹介します。
また紹介するのはコマンドのみとなるので、それに伴う専門知識(プル、コミットなど)に関する説明は割愛しております。

# 基本的なGitコマンド
始めに、使う頻度が多いGitコマンドを紹介します。

```ts
//ローカルにあるブランチの名前を全て確認する。
git branch
//ローカルとリモートにあるブランチの名前を全て確認する。
git branch -a

//ブランチ作成
git branch -c 新しく作るブランチの名前
//作業ブランチを、指定したブランチに変更する。
git checkout チェックアウトしたいブランチ名
//リモートからブランチをコピーしつつ、そこにチェックアウトする。
git checkout -b 新しく作るブランチの名前 origin/リモートからコピーしたいブランチの名前

//指定したローカルブランチを削除する。
git branch --delete ブランチ名
```

ブランチに関するコマンドです。
--deleteでブランチを削除するとき、削除するブランチにマージしていない変更があるとエラーになるので、削除する前に確認をしておきましょう。

```ts
//フェッチを行う。
git fetch
//指定したブランチから、作業ブランチにマージを行う。
git merge origin マージを行うブランチ名
//指定したブランチから、作業ブランチにプルを行う。
git pull origin プルを行うブランチ名
```

次にフェッチ・マージ・プルです。
フェッチを行うとリモートにあるブランチを取り込みます。git branch -a でリモートブランチを確認をする前にはフェッチを行います。プルはフェッチとマージを同時に行うので、リモートの変更を取り入れたい場面ではプルのみを行うことが多いです。
また origin ブランチ名 を省略してもマージ・プルは行われます。

```ts
//全ての変更をステージする。
git add .
//ステージした変更をコミットする。
git commit -m "コメント"
//コミットした変更をリモートブランチにプッシュする。
git push origin ブランチの名前
```

次にステージ・コミット・プッシュです。
リモートブランチに変更をプッシュする際、このコマンドを上から順番に打ち込みます。
add . は  add と . の間に半角スペースがあるので注意してください。

```ts
git reset --soft HEAD^ //直前のコミットを、コミットを行う前まで戻す。
```

プッシュを行う前の段階で、コミットを取り止めたい場合、私はこのコマンドをよく使っています。他にも方法はありますが、プッシュする前であればこのコマンドを使用します。softをhardに変えると、ファイル内の変更も消え、ワークツリーからも消されます。


# stashで変更を保存・取り出す

次にスタッシュをご紹介します。こちらは作業ブランチで行った変更を一時的に保存できるコマンドです。

```ts
//スタッシュにステージ前の変更をコメントを残しながら全て保存する。
git stash save -u "コメント"
//スタッシュ内に保存したファイルをコメントと共に全て見る。
git stash list
```

git stash save -u を行うと、その作業ブランチは全て変更前に戻るので、ブランチを変更する前やプル・マージを行う前にも利用できます。
また git stash list を打ち込むと以下のような結果が返ってきます。

```ts
stash@{0}: On 保存した時のブランチの名前: コメント
stash@{1}: On 保存した時のブランチの名前: コメント
stash@{2}: On 保存した時のブランチの名前: コメント
```

｛｝の中にある番号はスタッシュの中に保存した順番となっていますが、古い順に並んでいるのではなく、新しく入れたものが{0}となり、古いものは1つずつ数字が大きくなっていきます。この番号は次のコマンドで使用します。

```ts
//指定した番号に該当する変更を全てコピーする。
git stash apply 番号
//指定した番号に該当する変更をすべて削除する。
git stash drop 番号
```
この時 git stash apply で取り出した変更はコピーなので、再び同じ番号を打ち込めば同じ変更を取り出すことができます。また、 git stash drop で削除した変更は再度取り出すことが不可能なので、削除する際はコメントなどを参照しながら実行しましょう。

# 最後
今回紹介したコマンド以外にも作業が効率化されるコマンドはいくつも存在しています。しかし簡単に扱える半面、きちんと覚えるまでは間違いも起こりやすいです。特にコミットやスタッシュを削除する行為は、取り返しのつかない場合がほとんどです。
便利なコマンドですが、慣れるまでは調べながら慎重に作業を進めていくことをお勧めします。
OACでワークブックのレイアウトを作ってみる

# はじめに
OAC（**Oracle Analytics Cloud**）では、ワークブックへのビジュアライゼーションの配置を「レイアウト」として保存し、他のユーザーと共有することができます。
レイアウトの使用方法と、新規作成方法を紹介します。
※ OAC November 2024 Updateを使用しました。

# ワークブックにレイアウトを適用する
新規にワークブックを作成します。
「Sample Order Lines」というデータセットを使用しましたが、なんでも構いません。
「レイアウトの選択」というボタンをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/7b712c9c-7125-222d-d8cd-713d30f7dd0e.png)

2つのビルトインのレイアウトが表示されます。
試しに「Filter Left」を選択して「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/526e746d-5921-e04d-8616-6d1a2ffa008c.png)

ワークブックのキャンバスに選択したテーマが適用されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/91e65ce7-8d8c-0b09-8491-367e5bd935cd.png)

列をキャンバスのビジュアライゼーションにドラッグ＆ドロップしていきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/77688412-9bc3-3ea1-3703-507ba40a6e60.png)

キャンバスのレイアウトをどうするか考えるまでもなく、ワークブックができあがりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/4869d366-19a7-9b48-7272-2ecd7dcd0522.png)

一定のクオリティや見栄えを備えたワークブックを誰でも作成できます。

# テーマを作成する
まずは、通常通りワークブックを作成します。
仮に、こんなワークブックを作成したとします。
このキャンバスのビジュアライゼーションの配置を新たなレイアウトとして保存します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/20e98a72-d7ec-340f-c5e3-bf2b674c51f4.png)

キャンバスメニューを表示して、「共有レイアウトとして保存」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/1bf4e297-7a92-3156-bd44-5b0c0feea543.png)

任意の名前をつけて、「保存」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/bf45371d-ede4-06b1-5948-fe69b4a3923b.png)

# 作成したレイアウトを利用する
先ほどとは別のデータセットを使用して、新規のワークブックを作成しました。
「レイアウトの選択」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/47a4ecf4-c3d1-23d4-f27e-3f9e834e65da.png)

作成したレイアウトを選択して、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/2abb922e-5038-8451-48ff-ff8210fa7083.png)

ビジュアライゼーションの配置がテンプレートとして保存されており、再利用できることがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/58c0f656-9ca4-fc54-e671-df8a0e2b5408.png)

項目をドラッグ＆ドロップしてワークブックを完成させました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/b1212790-1e4d-ed52-49bf-800a81549501.png)

# 作成したテンプレートはどこに？
コンソールの「テーマ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/cf7d64f8-944b-b8ab-9244-bc99bbe7b58f.png)

作成した共有レイアウトが表示されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/faf14bc9-622a-a647-aaff-4c72b78e4452.png)
「読取り/書込み」が許可されているものに関しては、削除することができます。

共有レイアウトを作成するためには、権限を付与する必要があります。
デフォルトでは管理者にのみ許可されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/e8be67e2-bbe6-d4a6-3ff2-c503fa5944b2.png)

# おわりに
共通のレイアウトを策定し利用するようにすれば、レイアウトに頭を悩ますことなく迅速にデータの可視化が可能となります。
大量のXMLファイルを読み込んで、Excelに出力する

# はじめに
業務の中で、XMLファイルで作成されているメタデータ一覧の出力が必要になりました。
手でちまちまやるのはあまりにも面倒くさいので、pythonでやってみます。

pythonなんてろくに使ったこともないですが、調べながらなんやかんやで作れました。

良い時代だ。

# 前提
今回対応したのはSalesforceのメタデータのため、それを取得するコードです。
他パターンでも応用して使えるとは思います。

# コード
## 事前準備
一つだけライブラリを利用するので、インストールする必要があります。  
`pip install openpyxl`

それと当然、pythonのインストールが必要です。

## コード
```python:main.py
import os
import xml.etree.ElementTree as ET
import openpyxl

BASE_FOLDER_PATH = 'C:/Users/XXXXX/Documents/Salesforce/SalesforcePackage/force-app/main/default/objects'
TARGET_FOLDER_NAME = 'webLinks'
XMLNS = '{http://soap.sforce.com/2006/04/metadata}'

# 表記の項目を取得する
TARGET_COLUMNS = [
    'fullName'
    ,'masterLabel'
    ,'displayType'
    ,'linkType'
    ,'content'
]

# このリストに含まれている場合、セット処理は作成する必要がある
CUSTOM_COLUMNS = [
    'content'
]

# 対象となるフォルダ一覧を取得
directories = [
    f for f in os.listdir(BASE_FOLDER_PATH) if os.path.isdir(os.path.join(BASE_FOLDER_PATH, f))
]

objects = {}

# 各オブジェクトフォルダをループ
for objectName in directories:
    # 対象となるフォルダパスを組み立てる
    targetFolderPath = os.path.join(os.path.join(BASE_FOLDER_PATH, objectName), TARGET_FOLDER_NAME)

    # 対象となるフォルダが存在しない場合は飛ばす
    if not os.path.isdir(targetFolderPath):
        continue

    webLinks = {}

    # 対象となるフォルダ内のファイル名一覧を取得
    files = [
        f for f in os.listdir(targetFolderPath) if os.path.isfile(os.path.join(targetFolderPath, f))
    ]

    for fileName in files:
        # weblinkファイルを読み込み
        tree = ET.parse(os.path.join(targetFolderPath, fileName))
        root = tree.getroot()

        webLink = {}
        for targetColumn in TARGET_COLUMNS:
            # 標準のセッター
            if targetColumn not in CUSTOM_COLUMNS:
                webLink[targetColumn] = root.find(XMLNS + targetColumn).text

        # カスタムセッター
        if webLink['linkType'] == 'page':
            webLink['content'] = root.find(XMLNS + 'page').text
        elif webLink['linkType'] == 'url':
            webLink['content'] = root.find(XMLNS + 'url').text
        else:
            webLink['content'] = ''

        webLinks[webLink['fullName']] = webLink

    objects[objectName] = webLinks

# Excelファイルを開く
wb = openpyxl.Workbook()
ws = wb['Sheet']

# 書き込み処理
row = 1
for objectName, webLinks in objects.items():

    for webLink in webLinks.values():

        ws.cell(row, 1).value = objectName
        col = 2
        for columnName in TARGET_COLUMNS:
            ws.cell(row, col).value = webLink[columnName]
            col = col + 1

        row = row + 1

wb.save('C:/Users/XXXXX/Downloads/test.xlsx')
```

コメントを読むと何となく分かるとは思いますが、コードの流れとしてはこんな感じ。

1. 対象フォルダ内にあるフォルダ名一覧を取得  
それぞれのオブジェクトフォルダ内にある、`webLinks`フォルダ内のファイルが実際に読み取りたいXMLファイルです。
1. `webLinks`が存在しないオブジェクトもあるので、存在チェック
1. 存在していた場合、フォルダ内部の全XMLファイルを読み込んで、必要な情報をdict（連想配列）に保存
1. Excelファイルを作成
1. Excelファイルに3. で保存した情報を書き出す
1. Excelファイルを保存

# おわりに
なんかコードが汚い！！！  
もうちょっとなんとかしたいけども、今は取りあえず動くし良いでしょう・・。

pythonを使ってみて、気楽にコードを書いて動かすだけなのでお手軽なのですが、記法がなかなかに馴染まないですね。
型も定数宣言もできなかったり、セミコロン不要なのがなんだかソワソワします。
フィールドにインスタンス化されていないデータ型があります(SPSS Modeler データ加工逆引き12-8)

# フィールドにインスタンス化されていないデータ型があります（Excel/データベースエクスポート）

![スクリーンショット 2024-12-04 8.44.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/b0eeb65a-e93e-0f1f-6a93-aeaeec6cc339.png)

## 1.想定されるトラブル

・エクセルエクスポート時にエラーが起きる
・データベースエクスポート時にエラーが起きる
   
## 2.ストリームのダウンロード

https://github.com/yoichiro0903n/blue/raw/refs/heads/main/excel_output.str

## 3.サンプルストリームの説明

![スクリーンショット 2024-12-04 8.44.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/7c542788-3723-2adc-a85a-be1db0e61ddf.png)

a.入力は以下の通りです。

![スクリーンショット 2024-12-04 8.45.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/6a67f7ea-5d3e-a511-0b9a-d80a38c8c8b0.png)

b.[Excel]ノードを編集します。[Excel（tm）の起動]をチェックします。

![スクリーンショット 2024-12-04 8.45.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/84c7f868-986a-18e4-bdc5-5a0ca054da16.png)

[Excel]ノードを実行します。この時点ではエラーは起きず実行できます。

![スクリーンショット 2024-12-04 8.46.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/475d212c-ff93-ec84-3b10-c2d1b49ff9ba.png)

#### エラーの確認

b.[フィールド作成]ノードを編集します。無作為にカテゴリーを生成します。

![スクリーンショット 2024-12-04 8.46.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/af0c78cd-e9fc-f833-4b8a-c2f4bbded83c.png)

[プレビュー]します。新しいフィールドが作成されました。

![スクリーンショット 2024-12-04 8.47.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/4b0b2c80-7130-bbb1-f553-cdf84e0a11bd.png)

[Excel]ノードを実行します。[Excel]ノードが赤く点灯してエラーになります。

![スクリーンショット 2024-12-04 8.49.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/b6413057-b57e-5f14-77e0-e629bb342b52.png)

エラーメッセージは以下の通りです。

![スクリーンショット 2024-12-04 8.47.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/ab8629ae-cb35-d415-7e4a-a35a56ef6187.png)

#### 問題を解決する

c.[データ型]ノードを編集します。[値の読み込み]ボタンを押して[Cate]のデータ型を確定します。

![スクリーンショット 2024-12-04 8.48.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/254e7733-ac1c-0738-04ac-1ffe516b94bb.png)

[Excel]ノードを実行します。

![スクリーンショット 2024-12-04 8.49.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/8a5806ed-1980-e2e1-a8d2-e6c98a2e47f9.png)

#### 注意事項

CSVなどのファイル出力ではこの現象は起きませんが、Excelエクスポートやデータベースエクスポートで発生するので直前にデータの型を配置して、実行前には型のリフレッシュを実施します。

## 4.参考情報

#### Excelエクスポート

https://qiita.com/416nishimaki/items/3ec81ebf749a3d86d196

#### データベースエクスポート

https://qiita.com/416nishimaki/items/0af81c33ac4f07ae2dbe

#### SPSS Modeler ノードリファレンス目次

https://qiita.com/416nishimaki/private/503037195081d3323eee

#### SPSS Modeler 逆引きストリーム集（データ加工）

https://qiita.com/416nishimaki/items/4bf813e6cba84b2a1008
『いきなりプログラミングJavaScript』という本を書きました

『いきなりプログラミングJavaScript』という本を書きました！
1月24日に発売予定です。もう予約できます。ぜひ！

[![L.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33890/420c7d69-4818-8fc8-e169-b3dedd22524c.png)](https://www.shoeisha.co.jp/book/detail/9784798184395)

# どんな本か

### コンセプト

いわゆるJavaScriptの入門書です。

...なのですが、この本の特徴的なところはプログラミングの文法やお作法の説明にはあまり重きを置かず、『まずは手を動かして作ってみよう！』と実践を通じて**プログラミングの楽しさ**を知り、その過程でついでにプログラミングの知識を身につける...「プログラミングの楽しさを知ろう」という点に比重を置いたコンセプトとなっております。

書籍を通じて作成するアプリケーションも「学びましょう」より「作ってみたい」を重視した内容になっています。

* **AIが必ず負けてくれる！「接待○×ゲーム」**
  わざと負けてくれる優しいコンピュータと〇×ゲームを対戦できるアプリケーションを作ります
* **面白いダジャレを3段階で判定！「ダジャレ審議会」**
  文章を入力すると３匹の審査員(猫)が、その文章がダジャレとして成立しているかどうか、ひねりがあるかどうかを判定してくれるアプリケーションです
* **誰でも教科書に載れる！「偉人なりきりメーカー」**
  一見すると偉人を紹介する歴史の教科書のようなページですが、プロフィールを改ざんしたり偉人の顔に落書きできるアプリケーションです
* **声だけでキャラクターを簡単操作！「スイカ割り応援上映」**
  音声認識でキャラクターを誘導してスイカ割りをするアプリケーションです

いわゆるQiitaでも恒例のクソアプリカレンダーにありそうなちょっとひねったアプリケーションを作ることができます。

まだ校正作業中なので暫定版ですがこんな雰囲気の書面となっています。

![無題.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33890/e333b395-3682-9190-e8a5-7d12c4f56dd3.png)

この本はJavaScriptをこれから学ぶ人をメインターゲットにしていますが、サブターゲットとして「if文やfor文など基礎文法は習得したものの、これをどう組み合わせたら世にあるようなアプリケーションになるのか分からん！」という人も想定読者としています。

### 著者について

GMOペパボにて[Alive Studio](https://alive-project.com/studio)というVtuber向けの配信環境支援ツールを開発しているWebアプリケーションエンジニアです。

趣味でもプログラムを書いていて、こんな感じのいわゆる[『クソアプリ』](https://qiita.com/advent-calendar/2024/kuso-app)を作ってきました。

https://qiita.com/kurehajime/items/e9a90c1d3705fbc8197a

https://qiita.com/kurehajime/items/a922d42dff5e0f03d32c

https://qiita.com/kurehajime/items/f9d225fab5eaa736913b

実用性のない面白プログラムを作り続けていたら、書籍執筆の話が飛び込んできました。こういうこともあるんですね。

### 工夫したこと・気を付けたこと

執筆するうえで以下の点を工夫しました。

**純粋なプログラミング体験にフォーカスする**

一般的に、現代のJavaScriptでの開発はコードを書き始めるまでにいくつもの準備を踏みます。
ライブラリを使うためにはnpmが必要で、npmを使うにはnodeが必要で、そのnodeをお行儀よく使うにはnvmやnodebrewが必要で～...と、慣れてる人には当たり前ですが、画面にHello Worldを表示するまでに長い長い工程を踏みたらい回しにされます。

この書籍では、読者がプログラミングの下準備だけで疲弊してしまわないようにフレームワーク無しのプレーンなJavaScriptだけでアプリケーションを開発する内容に意図的に割り切っています。ファイルを保存してリロードすれば即反映される、バンドルやトランスパイルなしの環境です。

**最短でビジュアル的に見えるものを作る**

JavaScriptが他の言語と比べて優れているのは、GUIアプリケーションを構築するハードルが圧倒的に低いところです。

この書籍ではどの章でも最初の数ページで画面に何かを表示するところから書き始め、具体的なロジックは後から付け足していく構成を取っています。
『書いた！なんか動いてる！うれしい！』というプログラミングのプリミティブな成功体験を最短経路で味わえるよう心掛けました。

**書いて、実行して、説明はあと**

タイトルの『いきなりプログラミング』の書名の通り、この本ではまず書いて実行して動きを見て、その後で知識をつけようという構成にしています。
章の最初に「これからこういうものを作りましょう」という全体像は示しますが、あくまで『学ぶ内容主導』ではなく『やりたいこと主導』で進めます。

**どこで諦めても『完成』と言い張れる構成にする**
この書籍では、最初に素朴なアプリケーションを作ってそこに少しずつ機能を足していく形で完成形のアプリケーションを作る流れにしています。

例えば『AIが必ず負けてくれる！「接待○×ゲーム」』の場合、最初に自分で〇と×の両方を置いて自分で勝敗判定するセルフサービスの〇×ゲームを作ります。次に勝敗判定のロジック、さらにその次に普通に価値を狙うCOMの実装、最後に意図的に負けてくれる接待モードを実装します。

こうすることで、どこで諦めても「いや、このアプリはこれで完成だから」と言い張れる、挫折者に優しい構成にしています。自分自身意識の低い人間なので、この考え方は日ごろから重視しています。けっこう大事です。



# おわりに

まだまだ校正作業中ですが、順調にいけば1月24日に発売予定です！
プログラミングをこれから始める人、言語の基礎文法を習得したもののアプリケーションとして完成させた経験がない人、何か面白いものを作ってみたい人、ぜひお手に取ってもらえればと思います

[![L.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/33890/420c7d69-4818-8fc8-e169-b3dedd22524c.png)](https://www.shoeisha.co.jp/book/detail/9784798184395)
Clojure: RingでTodoアプリを作る - DB接続

![advent_calendar_2024.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/f4cd8ce0-6352-a1d8-4cae-f39dd44f4def.png)

[*Advent Calendar 2024 Day 13*](https://qiita.com/advent-calendar/2024/clojure)

昨日からTodoアプリを`Clojure`で作り始めています
今日はpostgresqlのDBと接続し、データを取得したいと思います

`next-jdbc`というライブラリを使って実現していこうと思います

https://github.com/seancorfield/next-jdbc

## `next-jdbc`

まずはライブラリをプロジェクトに追加します


```clojure:project.clj
  :dependencies [[org.clojure/clojure "1.11.1"]
                 ; ...
                 [com.github.seancorfield/next.jdbc "1.3.967"]
                 [org.postgresql/postgresql "42.7.4"]]
```

次に、DBの接続情報を作っていきます

:::note warn
一応この記事の最後にpostgresql dbの構築方法も載せておきます
:::

```clojure:database.clj
(ns todo.database
  (require '[next.jdbc :as jdbc]))

(def db-spec
  {:dbtype "postgresql"
   :dbname "todo"
   :host "localhost"
   :port 5432
   :user "todo-user"
   :password "todo-password"})
```

DBの接続を返す関数と、それを使って`Todo`の一覧を取得する関数を書いてみます

```clojure:database.clj
(def db (jdbc/get-datasource db-spec))

(defn select-todos
  []
  (jdbc/execute! db ["SELECT * FROM todos"]))
```

実行してみます

```clojure
(select-todos)
; => [#:todos{:id 1, :title "朝食を食べる", :completed false}]
```

うまくデータを取得できていそうです。

これで準備ができました。

明日は実際に作っていこうと思います

## 番外編 - `postgresql` dbの構築方法

今回は`Clojure`に焦点を当てているため、`docker`を用いて簡単に構築しました

```Dockerfile:Dockerfile
FROM postgreql:latest

ENV POSTGRES_DB=todo
ENV POSTGRES_USER=todo-user
ENV POSTGRES_PASSWORD=todo-password

ADD ./init.sql /docker-entrypoint-initdb.d/
```

```sql:init.sql
-- テーブル作成
create table todos (
  id serial primary key,
  title text not null,
  completed boolean not null
);

-- テストデータ挿入
insert into todos (title, completed) values ('朝食を食べる', false);
```
新規参画者がするっとチームに馴染むためのオンボーディング

9/11にD-Plusさんで開催された[【増枠！】D-Plus Tokyo #6~受けてよかった！自分が受けたい！オンボーディングのLT会~](https://d-plus.connpass.com/event/328644/)で登壇した内容です。
せっかくなのでアドベントカレンダーに参加させていただきました！
5分のLTで話せなかった具体的なところを補足する形の記事となります。

# スライド

<script defer class="speakerdeck-embed" data-id="6ce585ff018f40a085b8603d800a44be" data-ratio="1.7772511848341233" src="//speakerdeck.com/assets/embed.js"></script>


# 概要：何も考えずに日々やっていることこそ教えてあげよう
会社勤めをしていると、プロジェクトの目的だ理念だとかコーディングルールだアーキテクチャだとかを話す前に、やることっていっぱいありますよね。
出退勤の打刻をしたり、カレンダーを見て会議の予定を確認したり、slackの通知に反応したり、月末月初に申請しないといけなかったり。
このルーティンになったらなんでもない毎日の小さな小さな名もなき作業が、新規参画者にとっては大波のような情報量となって襲ってきます。既存メンバーにとってはなんでもない作業なので、それらの対応が漏れていると **「なんでこんなこともできないの？」** とマイナスなギャップを生んでしまいます。
長年チーム・会社にいる人ほど、この「毎日やるなんでもない作業」のことを棚卸しして、気を配ってあげましょうという内容です。

# 具体的なチームでの取り組み
Google Docsで「毎日使うツール」「毎日やること」を箇条書きにしてまとめたものをガイダンスで配布しています。
配布内容は毎回同じものとなりますが、1つのドキュメントをルールブックとして共有するのではなく、新規メンバーその人用に作成し配布することで、各々が自分用のメモを気楽に書けるようにしています。

↓中身はこんなかんじ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947757/6f1999f2-c4b7-5b5e-18d3-22156797a333.png)

また、ガイダンス後のTODOとして毎日使うツールを毎日使うための準備運動をしてもらいます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947757/bbe087b2-eee1-02d6-302e-8829f208f2bb.png)

この取り組みで、「毎日やること」を「なるべく早めに」「なにも考えずできるようにする」状態を目指しています。


# 効果

会議に遅れないように参加したり、定期的にやることをきちんとやっていると、「 **既存メンバーが新規メンバーを信頼するようになるのが早い** 」と感じています。
新規メンバー本人もルーティン作業に脳のリソースを割かなくなり、開発作業に集中できてチームに貢献することができるため、参画初期から実績を出しやすい環境をつくれています。

オンボーディング資料の最初の一歩として、まずは本記事のように毎日の作業を棚卸しして、ガイダンス資料を作成してみてはいかがでしょうか。
実務の面で新規参画がしやすくなるものになるとおもいます。

# 今後
新規参画メンバーのFBをもらい、さらなるオンボーディングの改良を目指します！
プロジェクト目的の理解や、マインドセットの醸成のための仕組み等はまだまだオンボーディングへ組み込めていないため、それらも組み込んでいくのが目標です。
Migration Guide v0.25.0

[Previous << Flow Go SDK](https://qiita.com/flowcadence/items/3616deed7fbb2d69f91e)
[Next >> Flow Dev Wallet](https://qiita.com/flowcadence/items/506522b43325705d9b8b)

https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a#reference-2020832ebee1810a325a

Go SDK バージョン 0.25.0 では、API とパッケージの命名に重大な変更が加えられました。新しい HTTP アクセスノード API の実装を利用可能にするために変更が必要でした。

すべての変更点を列挙し、マイグレーションの例を提示します。
* **パッケージの名称変更：client -> access**: `client`パッケージは`access`に名称変更されました。これにより、以前はgRPC実装のみを含んでいた`grpc`パッケージと、新しいHTTP API実装を含んでいた`http`パッケージの両方が含まれます。
* **パッケージの削除：convert**: `convert`パッケージは削除され、そのすべての関数はそれぞれ対応する`grpc`と`http`パッケージに移動しました。また、そのメソッドはエクスポートされないように変更されたため、今後はパッケージ外で使用できなくなりました。
* **新クライアント**：新しいクライアントが追加され、それぞれがクライアントインターフェースの関数を実装し、それらを作成するためのファクトリーについても公開しました。
* **新クライアントインターフェース**: 新しいクライアントインターフェースが作成され、ネットワークに依存しないようになりました。つまり、gRPC固有のオプションを渡すために使用されていたAPIの追加オプションは公開されなくなりました。これらのオプションを渡すことは依然として可能ですが、以下の例で示されているように、ネットワーク固有のクライアントを使用する必要があります。このインターフェースでは、いくつかの関数も変更しました。
   * `GetCollectionByID` renamed to `GetCollection`
   * `Close() error` was added

<h1>Migration</h1>

**Creating a Client**

アクセスノードとの通信に使用するクライアントの作成方法は、HTTPとgRPCの通信プロトコルを自由に選択できるようになったため、変更されました。

*Previous versions:*
```ruby
/* initialize a gRPC emulator client */
flowClient, err := client.New("127.0.0.1:3569", grpc.WithInsecure())
```
*Version 0.25.0:*
```ruby
/* common client interface */
var flowClient access.Client

/* initialize an http emulator client */
flowClient, err := http.NewClient(http.EmulatorHost)

/* initialize a gPRC emulator client */
flowClient, err = grpc.NewClient(grpc.EmulatorHost)
```
**Using the gRPC Client with Options**

クライアントの使用方法はほとんどのケースで同じですが、gRPCクライアントに追加オプションを渡すという高度なケースでは、ベーシックのクライアントではもはや不可能です。高度な例で示されているように、ネットワーク固有のクライアントを使用する必要があります。

*Previous versions:*
```ruby
/* initialize a gRPC emulator client */
flowClient, err := client.New("127.0.0.1:3569", grpc.WithInsecure())
latestBlock, err := flowClient.GetLatestBlock(ctx, true, MaxCallSendMsgSize(100))
```
*Version 0.25.0:*
```ruby
/* initialize a grpc network specific client */
flowClient, err := NewBaseClient(
	grpc.EmulatorHost, 
	grpc.WithTransportCredentials(insecure.NewCredentials()),
)
latestBlock, err := flowClient.GetLatestBlock(ctx, true, MaxCallSendMsgSize(100))
```


*Last updated on **Nov 26, 2024** by **Giovanni Sanchez***

翻訳元

https://developers.flow.com/tools/clients/flow-go-sdk/migration-v0.25.0

***
<b>[Previous << Flow Go SDK](https://qiita.com/flowcadence/items/3616deed7fbb2d69f91e)
</b>

[Flow blockchain / Cadence version1.0ドキュメント](https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a) (Migration Guide v0.25.0)

<b>[Next >> Flow Dev Wallet](https://qiita.com/flowcadence/items/506522b43325705d9b8b)</b>
システム開発に関する用語【要件定義】【設計】

## システム開発とは？
**コードを書くだけでなく、** スケジュール作成や要件定義などをまとめて、「システム開発」と呼ぶ。

## 要件定義
**システムの目的や最低限満たすべき条件を明確化**する工程。
この段階で、発注者と開発者が話しあい、何を作るか方向性を決める。

要件定義をきちんと行わないと、不完全なシステムになってしまったり、障害が起きる可能性がある。

### ◎機能要件
**システムが何をするか？** 発注者がシステムに求める機能。

例：
「今回作るシステムはログイン機能を付けます！」　
「登録したものを一時保存できる機能を付けます！」
    
### ◎非機能要件
**システムの品質・条件。**
例：
「一定時間ログインがないと、自動的にログアウトする」
「保存期間は○○日までとする」
「1秒以内に検索結果を表示する」
「平日日中はサーバー稼働率99.9%以上を保証する」

## 設計
建物を建てる時、同様事前に設計を考えておく。
抽象的なものから詳細なものへ…という順で書くので、
画面 ⇒ データ ⇒ アプリケーション　と設計する。

### ◎画面設計
いきなりHTMLを書かず、画面の設計を事前に決めておく。
- 画面の流れ(どこからどこに転移するか)
- 入力する項目、表示項目、配置など
以下の図を書いて設計することが多い。

`画面遷移図(UI Flows図)`：
画面間のリンクや操作の流れを視覚化する。
```
[ログイン画面] → [ユーザ画面]
                 ↘︎ [エラー画面]
```
`ワイヤーフレーム`：
画面内の要素配置を簡易的に表現する。
```
┌──────────────────┐
│ ログイン          │
│ ┌────────────┐ │
│ │ ユーザー名    │ │
│ └────────────┘ │
│ ┌────────────┐ │
│ │ パスワード    │ │
│ └────────────┘ │
│ [ログインボタン]  │
└──────────────────┘
```
---

### ◎データベース設計
`概念設計`：
これから作成するシステムで、どんな情報を管理するのか、**ビジネス的な視点**で整理する。
``ER図（エンティティ・リレーションシップ図）`` で表現される。

例：
「ログインシステムにはメアドがいるな」
「一時保存機能には作成日時が必要だな」

- 管理すべき「もの（エンティティ）」は何か？
- それにはどんな関係性（リレーション）があるか？
- それぞれの特徴（属性）は何か？

`論理設計`：
概念設計をもとに、データベースとして実装可能な形に落とし込む。
どのようなカラム・テーブルにするか、テーブル設計を行う。
`ER図`や`テーブル定義書`を作成する。

`物理設計`：
物理的領域や格納方法を決める
ラスタータイルの作り方（2024年版）

![mug-jp_logo_01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/73197/8d017f83-8e52-aee7-f6b2-8c75ccd7df34.png)

## はじめに

### MapLibreとは

MapLibre Official WebSite
https://maplibre.org

- Web地図に関するプロダクトをOSSとして開発・メンテナンスしているOrganizationです
- ブラウザ・モバイル向けの地図ライブラリおよび地図配信に関するツール群があります


### MapLibre User Group Japan (MUG-JP) とは

MUG-JP Official Web Site
https://mug-jp.org/

- MapLibreプロダクトの開発者によるユーザーコミュニティです
- ナレッジの共有やイベントの開催による普及活動を行なっています

## はじめに

筆者は過去に以下の記事を投稿しています

https://qiita.com/Kanahiro/items/4b5f8db5743c69741220

この数年で地図タイルの静的配信の世界観は大きく変わりました。主にPMTilesの台頭によって、ディレクトリ形式で配信するメリットがなくなっています。上記記事ではディレクトリ形式でのタイル生成を念頭に置いており内容が古くなってしまっています。なので本記事では、<b>令和最新版</b>のラスタータイル生成フローを紹介します。

## ラスタータイルの生成フロー

入力はGeoTIFF、出力をPMTilesとします。

```mermaid
graph LR

GeoTIFF --gdal_translate--> MBTiles1[(MBTiles<br />最大ズームのみ)] -- gdaladdo --> MBTiles2[(MBTiles<br />全ズームレベル)] -- go-pmtiles --> PMTiles[(PMTiles)]
```

:::note info
最もポピュラーは形式としてGeoTIFFで説明していますが、GDALがサポートする形式ならほかの形式でも問題ないでしょう。なお、GeoTIFFがRGB値を持っていることを前提としています。
:::

### 1. GeoTIFF -> MBTiles

[gdal_translate](https://gdal.org/en/latest/programs/gdal_translate.html)によるフォーマット変換でGeoTIFFをMBTilesへ変換出来ます。

```sh
gdal_translate -of MBTILES input.tif output.mbtiles-r bilinear -co BLOCKSIZE=512 -co TILE_FORMAT=WEBP
```

昨今、ラスタータイルは512^2の解像度がポピュラーですから、`-co BLOCKSIZE=512`でそう設定しています。またナウいフォーマットとしてWebPを利用する設定も可能です（`-co TILE_FORMAT`）。

このほかにも多様なオプションが利用可能です、以下のドキュメントを参照しましょう。

https://gdal.org/en/latest/drivers/raster/mbtiles.html#raster-mbtiles

### 2. MBTiles内に各ズームレベルのタイルを生成する

`gdal_translate`の変換だけでは、最大のズームレベルのタイルしか生成されません。最大のズームレベルのタイルを用いて、低いズームレベルの画像を生成する必要があります。ここでは[gdaladdo](https://gdal.org/en/latest/programs/gdaladdo.html)を利用します。`gdaladdo`はいわゆるピラミッド画像を生成するためのプログラムです。「最大ズームのタイルを用いて低いズームのタイルを生成する」というのはまさにピラミッド画像でやっていることと同じですから、なんとなく腑に落ちそうです。

```sh
gdaladdo -r bilinear output.mbtiles
```

ここで重要なこととして、`gdaladdo`は既存ファイルに対する破壊的変更を行うという点に留意してください。頑張ってGeoTIFFからMBTilesにしたのちに、たとえば誤ったパラメータで`gdaladdo`を実行してしまうと、またGeoTIFFからやり直し…ということがありえます。実行前にMBTilesを複製しておくことをお勧めします。

### 3. MBTiles -> PMtiles

https://github.com/protomaps/go-pmtiles

`go-pmtiles`を利用すれば容易にPMTilesへ変換できます。[release](https://github.com/protomaps/go-pmtiles/releases)から最新バージョン・適切なアーキテクチャの実行ファイルをダウンロードしておきます。

:::note info
Apple Siliconのmacなら`Darwin_arm64`
Intel macなら`Darwin_x86_64`
Windowsなら`Windows_x86_64` 
このあたりを選べばおそらく問題ありません。arm版WindowsやLinuxユーザーはご自身でわかると思うので割愛します。
:::

```sh
./pmtiles convert output.mbtiles output.pmtiles
```

これでラスタータイルのPMTilesが得られるので、思い思いのラスタータイルサーバーを構築・配信しましょう。

## 宣伝

https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81%AE%E3%83%97%E3%83%AD%E3%81%8C%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E6%95%99%E3%81%88%E3%82%8B%E4%BD%8D%E7%BD%AE%E6%83%85%E5%A0%B1%E3%83%87%E3%83%99%E3%83%AD%E3%83%83%E3%83%91%E3%83%BC%E9%A4%8A%E6%88%90%E8%AC%9B%E5%BA%A7-%E4%BA%95%E5%8F%A3%E5%A5%8F%E5%A4%A7/dp/4798072249

本記事で紹介したような手順で生成したタイルを配信するサーバーを実装する手法など、サーバーサイド技術を学びたい方向けに書いた書籍です。100冊書いましょう！
タイムボックスについて

この記事は、[適応型ソフトウェア開発 アドベントカレンダー 2024](https://qiita.com/advent-calendar/2024/adaptive-software-development) の 10日目です。

## タイムボックスについて

スクラムフレームワークにおけるスプリント期間の話である。
適応型ソフトウェア開発ではどのように期間を設定するのだろうか。
という話だ。

### イテレーション

イテレーションについては、こちらの記事で記載しているが、大きく異なっているのは開発の進捗指針が「状態」という概念であることだ。

https://qiita.com/h-kinocoboy/items/ea3290261f491faf6615

## 「状態」に向き合う

「状態」を最新化し続けることが、適応型ソフトウェア開発で重要なポイントである。

しかし、「状態変化」に追従し、観測を続けることはなかなか難しい。

その難しさがどこにあったのかというと、時間軸の違いである。


## 時間軸の違い

「状態」が変化するタイミングは、文脈の大小や環境変化、関わるものの多さによって変化する。

そのため、スクラムのように定点的なタイムボックスを置いた観測だけでは開発指標である「状態」の追従・最新化が追いつかない。または顕在化しない状態が続いてしまうことだ。


### チームで取り組んだ際に有効だった時間設定

今まで登場した「目標」・「カオス」・「タスク」はそれぞれ状態を持っている。
しかし上述した通り、状態変化を観測できる時間軸は異なっている。


#### タスク
これが最も状態変化を観測するまでのスパンは短かった。
早ければ、半日。遅くても3日で状態変化を観測できるものだ。


#### カオス
これはなかなか手強い。
そもそもわからないものの状態を変えようというのだから、それはそうなのだ。

しかし、カオスの淵をなぞっていくうちに状態が変化することも多かった。
これは１週間か２週間で状態が変わってくることが多かった。

### 目標
これが最も動かない。
おおよそプロジェクトのフェーズと言い換えても良いものだから、マンスリー単位で変化が観測できるものかもしれない。


## 有効な時間軸

上述した通り、有効な時間軸はday, week, month の3つの観点での状態観測を行うことで、
最新状態を維持し、適応型ソフトウェア開発を継続できることを知った。


### チームでの取り組み
私たちは、このday, week, month の観点でそれぞれイテレーションを回す三重ループを行うことにした。
その結果、毎日状態がわかり、週単位でどれだけの状態が進んだかを整理し、月が変わった時にどれだけの進捗があったのかを知ることができるようになった。
ゼロから作るDeepLearning #4 -損失関数-

※以下の企画です

https://qiita.com/tatataichi/private/56936a028e625e62af8e

前回に続いてゼロつくやっていきます。
今回も4章 -ニューラルネットワークの学習-に入ります。
いよいよ機械学習らしくなってくる章です。たのしみ〜


それでは頑張っていきます〜

# 4章 ニューラルネットワークの学習
## 損失関数
そもそもニューラルネットワークにおける「**学習**」とは、パラメータ（重み$w$や、バイアス$b$など）を教師データを基に自分で算出することを言う。
その際に、**正解データと出力結果を比較してどれだけ間違っているかを表す指標として「損失関数」というもの**を用いる。

今回は損失関数の種類について学んでいく〜

## 二乗和誤差
二乗和誤差は、ニューラルネットワークの出力結果と正解データとの誤差を二乗して、それらをすべて足し合わせたもの。
以下の式で表される。

$$
E = \frac{1}{2} \sum_{k=1}^{K} (y_k - t_k)^2
$$

- $( y_{k} )$: ニューラルネットワークの出力（予測値）
- $( t_k )$: 正解データ
- $( K )$: データの次元数

先述の通り、損失関数はそのニューラルネットワークの**精度の悪さ**を表すので、**予測値と正解データの差分が大きいほど二乗和誤差の答えも大きく**なる。

一応コードにも起こしておく。
```python:二乗和誤差
def sum_square_error(y, t):
  return 0.5 * np.sum((y-t)**2)
```

予測が合っているときと外しているときで、ちゃんと誤差が大きくなるかをテストしてみる。
データとしては、`t`が正解データでなり、`y`がニューラルネットワークからの出力だと仮定する。
やりたいことは、`t`の配列のうち、どれが"1"になっているかを当てる。`y`の出力結果は、前回学んだ"ソフトマックス関数"によって得られた確率値である。

```python:合っているとき
y = [0.1, 0.05, 0.6, 0.05, 0.1, 0.1]
t = [0, 0, 1, 0, 0, 0]

sum_square_error(np.array(y), np.array(t))
```
```terminal:合っているときの出力結果
0.09750000000000003
```

```python:間違っているとき
y = [0.1, 0.05, 0.1, 0.05, 0.1, 0.6]
t = [0, 0, 1, 0, 0, 0]

sum_square_error(np.array(y), np.array(t))
```
```terminal:間違っているときの出力結果
0.5974999999999999
```

ちゃんと外れているときの出力値の方が大きくなっていることがわかる。


## 交差エントロピー誤差
交差エントロピー誤差は、主に**分類問題**で使われる損失関数。出力結果が確率として解釈される場合に有効っぽい。
以下の式で表される。

$$
E = - \sum_{k=1}^{K} t_k \log y_k
$$

- $( t_k )$: 正解ラベル（通常「1（正解）」または「0（不正解）」）
- $( y_k )$: ニューラルネットワークの出力（ソフトマックス関数を適用した確率値）

実質的には「**出力値の自然対数を計算するだけ**」の関数。
出力が1になれば$log1 = 0$になって、損失関数が0になるという仕組み。

```python:交差エントロピー
def cross_entropy_error(y, t):
  delta = 1e-7
  return -np.sum(t * np.log(y + delta))
```
コードもほぼそのまんまだが、一点だけ注意点があった。
それは`delta = 1e-7`の部分で、めちゃくちゃ小さい数字を`y`に加えている。
理由としては、`y=0`になったとき`no.log(0) = -inf`という爆発を起こしてしまうため、その防止策として加える必要があるみたい。なるほど。

せっかくなので二乗和誤差と同様のテストを行ってみる。

```python:合っているとき
y = [0.1, 0.05, 0.6, 0.05, 0.1, 0.1]
t = [0, 0, 1, 0, 0, 0]

cross_entropy_error(np.array(y), np.array(t))
```
```terminal:合っているときの出力結果
0.09750000000000003
```

```python:間違っているとき
y = [0.1, 0.05, 0.1, 0.05, 0.1, 0.6]
t = [0, 0, 1, 0, 0, 0]

cross_entropy_error(np.array(y), np.array(t))
```
```terminal:間違っているときの出力結果
2.302584092994546
```
こちらもちゃんと想定通りの結果になった。


## ミニバッチ学習
### ミニバッチ学習とは？
機械学習では通常、大量のデータを使ってモデルを学習させる。しかし、すべてのデータを一度に計算するのは**計算コスト**が高くなる。そのため、データをいくつかの「小さなグループ（ミニバッチ）」に分けて順番に学習する方法を「ミニバッチ学習」と呼ぶとのこと。

### ミニバッチ学習の流れ
1. 学習データをランダムにシャッフルする
2. 一定サイズのバッチに分割する（例: バッチサイズ = 32とか）
3. 各バッチで損失関数を計算し、パラメータを更新する

これは実践的に学んだほうがガッテン行きそうなので一旦頭にいれておく・・・

# まとめ
今回は損失関数の代表的な２つを学んだ。
活性化関数とか損失関数とか、なぜ存在していて、どんな種類があるのか　とかはちゃんと説明できるように復習していきたい。
イテレーションについて

この記事は、適応型ソフトウェア開発 アドベントカレンダー 2024 の 9日目です。

## 適応型ソフトウェア開発のポイント

前回までの記事で適応型ソフトウェア開発の大枠を解説してきた。
ここで改めておさらいする。

### 取り組む時のルール
簡単なルール × 豊かな人間関係 = 圧倒的な適応力 の方程式を常に意識すること

### 適応度地形
どこを目指し、どのような環境にいるのかを把握すること
周辺状況の環境変化を常に意識する

### 開発指標
学習・思案・協調という状態を前に進める
そして、常に最新化しておく

### 俯瞰と集中を切り替えること
原則、目標に向かう進行としてはマルチタスクで進めていく。
そしてマルチタスクの対象となるのは、「カオスの縁」にある今着手することができるタスクだ。


## 適応型ソフトウェア開発のイテレーション

上述したポイントを押さえながら、イテレーションを回していく。
ただ具体的にどう進めたのかこのままではイメージが湧かないと思うが、とてもシンプルなものだ。

なぜなら、簡単なルールで取り組むことが適応型ソフトウェア開発における鉄の掟であるためだ。

ここからは私たちが行ったイテレーションの流れをまとめたいと思う。


### チームが行ったイテレーションの流れ
チームは一回のイテレーションでこれらの取り組みを行うことにした。
* 環境を把握する
* カオスの縁を把握する
* タスクに変換する
* それぞれの「状態」を明らかにする
* 状態を前に進める担当をアサインする
* 振り返りをする


#### 環境を把握する
まず始めたのは環境を把握することだ。
主に自分たちを取り巻く周辺状況の状態把握である。

* このプロジェクトも目標はなにか？
* どのように世界を変えたいのか？
* それに関わっている人は誰か？
* 関わっている組織はなにか？
* プロジェクト自体はどのような状態か？
* 成果物はどのような状態か？

この辺りを全て言語化するところから着手した。
そうすると、現時点では全く想像もつかない「カオス」が見えてくる。
そのカオスを見つけることが大切である。


#### カオスの縁を把握する
カオスを見つけることができたら、そのカオスの縁に何があるのかを確認する。

わからないなりに、１歩踏み出せそうな領域があるか？

という問いをチームに繰り返すことが多かった。

そうすると、「カオスの縁」が１つのタスクに変換されていく。


#### タスクに変換する

タスクとは、何かアウトプットが生まれるものとチームで定義した。
このタスクを進めることで、カオスへの理解が深まると考えた。

カオスの縁は１つではないはずであり、多角的に存在すると思う。
それらをまず書き留め、一覧かすることに勤めた。

#### それぞれの「状態」を明らかにする
一覧に洗い出されたタスクそれぞれの「状態」を確認した。

このタスクは、「学習」が必要な状態なのか、すぐに方針を「思案」できるのか？
また誰かとすぐに「協調」できるのか？
次のカオスに当たるまでこれを繰り返した。

そうすると、次のカオスの淵が見えてくることがある。

#### 状態を前に進める担当をアサインする
それぞれのタスクをマルチタスクに進めていくため、主担当をアサインした。
これは立候補で行っていくことが多かった。
豊かな人間関係を形成されることで、指示を仰ぐことが減り、能動的に動き出せる状況が必要だった。

そしてそれぞれがチームの目標達成のため、多角的に別々の方向から歩き出すのだ。

#### 振り返りをする

ここまでの流れを振り返ることで、より上手に進める方法を模索する。


### まとめ
おおよその流れは通常のアジャイル開発と同じものである。
むしろ原初のフレームワークなので、原点だ。


## 参考資料

https://qiita.com/h-kinocoboy/items/307b026c8102334d2a17

https://qiita.com/h-kinocoboy/items/5b69d06e9801d56989be

https://qiita.com/h-kinocoboy/items/606781082146d8c29474
OutSystemsで大量データを扱う日次バッチ処理を作成する

# 目的
システム開発において、結構な頻度で定期的に処理する必要が出てくると思います。
例えば、メール配信、他のシステムとのデータの同期、日時集計処理、データアーカイブなど用途も様々です。
OutSystemsにおいてこのようなバッチ処理を定期的に実行する実装例挙げます。

# 環境
OutSystems O11
Service Studio Version 11.54.37

# OutSystemsでのバッチ処理
主にTimerという機能を用いて実装します。

## Timer
タイマーは、スケジュールされた時間に定期的にロジックを実行できるようにするOutSystemsツールです。
ServiceStudioの右側のProcessタブで作成管理することができます。
TimerからはServerActionを呼び出し実行することができます。
Timerは日次、月次の定期的に実行をスケジュールすることができます。そのほかにもService手動での実行や、UIやAPIを経由しての実行ができます。

## Timer実装の留意点

### Timerの制限事項
- タイムアウト時間:20分
- エラー時の再実行数:3回
- 1サーバ当たりの並列実行数:3

### Timerのタイムアウト対策
バッチ処理は一般的に長時間リソースを占有する負荷のかかる処理をシステムのオフピークに実施します。ここで気になるのはタイムアウト時間です。すべての処理をタイムアウト時間内で完了させることは保証できません。
公式のTimerのベストプラクティスとして、一度の処理はタイムアウト時間内で正常させ、Timer内でTimerを再実行させる方法があります。
1度のTimer実行で処理が終わらないことを考慮して、Timerを安全に終了し再実行するために処理終了時間を設定します。処理のループ内で処理終了時間を経過しているかを判定し、経過している場合は処理を中断しTimerの再実行をスケジュールします。

#### 再実行のための進捗管理
上記の通りTimerを再実行することにより対象のすべてのデータの処理完了を担保します。そのため、処理が完了しているか明確な条件を定義する必要があります。

#### 処理のループ
一度の処理のループは進捗の管理をしやすい単位を考慮して決定します。さらに1度のループでTimerのタイムアウト時間を超過しないように、十分処理時間の小さな単位をループさせる必要があります。

### 例外処理
例外が発生した場合、データをロールバックする必要があるのか、今までの処理分はコミットするのかを判断し処理を実装します。また、例外によるTimerの再実行をするのか、そのまま処理を終了するのかを判断し処理を決定します。例外が発生した旨と調査のための情報をログに残したり、システム管理者や運用担当者にメールを送るなどの処理を入れる必要があるかもしれません。

### ログ
バッチ処理の失敗時の調査のために、最低限失敗した箇所、失敗した理由をログに残しておく必要があります。ただし、バッチ処理は大量のデータを処理する必要があるため、レコード単位で成功したことをログに残してしまうとログに大量のデータがたまってしまい、問題になることがあります。どのようなログがあれば対応が可能かをよく検討する必要があります。

## 実装例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3796185/1ac28c13-014e-6ff9-c605-3a89c925a215.png)
点群データ.plyをBlenderで読み込める.objファイルフォーマットに変換する

# PLYファイルをOBJフォーマットにPythonプログラムで変換する

**測距センサーLiDAR（iPadProに搭載）で取得した点群をBlenderなどの3D-CAD，CGソフトにインポートするためにOBJフォーマットに変換する．**

```convert_ply2obj.py
import trimesh
import tkinter as tk
from tkinter import filedialog

# ダイアログボックスでPLYファイルを選択
root = tk.Tk()
root.withdraw()
ply_file_path = filedialog.askopenfilename(filetypes=[("PLY files", "*.ply")])

# PLYファイルの読み込み
mesh = trimesh.load(ply_file_path)

# 変換されたOBJファイルの保存パスを指定
obj_file_path = ply_file_path.replace('.ply', '.obj')

# OBJファイルとして保存
mesh.export(obj_file_path)

print(f"PLYファイルをOBJファイルに変換しました: {obj_file_path}")
```

**注意事項**
もし，pygletライブラリにおいてエラーがでたら，ほとんどはそのバージョンに関するエラーだと思います．その場合には，以下のコマンドをターミナルにて実行し，現在のpygletをアンインストールして，バージョン２よりも前のバージョンを再インストールしてみてください．
```:bash
pip uninstall pyglet
pip install "pyglet<2"
```
[忘備録] 動画系の拡張子多すぎんか？一覧表作った

| 拡張子 | 概要 | メリット | デメリット | 用途 | Windows | Mac |
|--------|------|----------|------------|------|---------|-----|
| **.mp4** | MPEG-4 Part 14。広く使用されている動画フォーマット。 | 高い互換性、効率的な圧縮、品質とファイルサイズのバランスが良い。 | 一部の古いデバイスで非対応の場合がある。 | ストリーミング、動画共有、デバイス間の移動。 | 〇 | 〇 |
| **.avi** | Audio Video Interleave。Microsoftが開発したコンテナフォーマット。 | シンプルな構造、幅広いコーデックに対応。 | ファイルサイズが大きくなりやすい。 | 動画編集、保存。 | 〇 | 〇 |
| **.mkv** | Matroska Video。オープンソースのコンテナフォーマット。 | 高度な機能（字幕、複数音声トラックなど）、無制限のストリーム数。 | 一部のプレーヤーでの互換性が低い。 | 高品質動画の保存、ブルーレイのダンプ。 | 〇 | 〇 |
| **.mov** | QuickTime File Format。Appleが開発した動画フォーマット。 | 高品質な動画保存、編集に適している。 | ファイルサイズが大きくなる傾向。 | プロフェッショナルな動画編集、Apple製品での使用。 | 〇 | 〇 |
| **.wmv** | Windows Media Video。Microsoftが開発した動画フォーマット。 | Windowsとの高い互換性、効率的な圧縮。 | 他プラットフォームでの互換性が低い。 | Windows環境での動画配信、ストリーミング。 | 〇 | △（対応アプリで可能） |
| **.flv** | Flash Video。Adobe Flashで使用される動画フォーマット。 | ストリーミングに適している。 | Flashの廃止によりサポートが減少。 | ウェブ上の動画配信（現代では減少傾向）。 | 〇 | △（対応アプリで可能） |
| **.webm** | オープンソースの動画フォーマット。 | ライセンスフリー、ウェブでの使用に最適。 | 高度な編集には不向き。 | ウェブ動画、ストリーミング。 | 〇 | 〇 |
| **.mpeg** | Moving Picture Experts Group。標準的な動画フォーマット。 | 広範な互換性、様々な品質設定が可能。 | 新しいフォーマットに比べて圧縮効率が劣る。 | DVD、デジタルテレビ放送。 | 〇 | 〇 |
| **.3gp** | 3GPP。携帯電話向けの動画フォーマット。 | 小さいファイルサイズ、モバイルデバイスに最適。 | 画質が低い。 | モバイルデバイスでの動画撮影、共有。 | 〇 | 〇 |
| **.ts** | Transport Stream。デジタル放送で使用されるフォーマット。 | ストリーミングに適している、エラーチェック機能。 | 一般的な再生ソフトでの互換性が低い。 | デジタルテレビ放送、ストリーミング。 | 〇 | 〇 |
| **.m4v** | MPEG-4 Video。Appleが開発した動画フォーマット。 | iTunesとの高い互換性、DRM保護が可能。 | 他プラットフォームでの互換性に制限。 | iTunesでの動画配信、Apple製品での使用。 | 〇 | 〇 |
| **.rmvb** | RealMedia Variable Bitrate。RealNetworksが開発したフォーマット。 | 高い圧縮率。 | サポートプレーヤーが限定的。 | インターネット上の動画共有（主に中国で使用）。 | △（専用プレーヤーが必要） | △（専用プレーヤーが必要） |
| **.vob** | DVD Video Object。DVDで使用される動画フォーマット。 | 高品質な映像と音声。 | ファイルサイズが非常に大きい、編集が難しい。 | DVDの映像保存。 | 〇 | 〇 |
| **.dat** | MPEGプログラムストリーム。VCDやSVCDで使用。 | 特定の用途に適している。 | 一般的な再生ソフトでの互換性が低い。 | VCD、SVCDの映像保存。 | 〇 | 〇 |
[忘備録]音声ファイル拡張子一覧

## 音声ファイルの拡張子一覧
多すぎんか？一覧表ほしかったのでメモ

| 拡張子 | 概要 | メリット | デメリット | 用途 | Windows | Mac |
|--------|------|----------|------------|------|---------|-----|
| **.mp3** | MPEG-1 Audio Layer III。広く普及している音声圧縮フォーマット。 | 高い互換性、ファイルサイズが小さい。 | 圧縮による音質の劣化。 | 音楽配信、ストリーミング。 | 〇 | 〇 |
| **.wav** | 無圧縮の音声ファイルフォーマット。高音質。 | 高音質、編集が容易。 | ファイルサイズが大きい。 | プロフェッショナルな音声編集、録音。 | 〇 | 〇 |
| **.aac** | Advanced Audio Coding。MP3より高音質で同等または小さいファイルサイズ。 | 高音質、効率的な圧縮。 | 一部の古いデバイスで非対応。 | ストリーミング、Apple製品での使用。 | 〇 | 〇 |
| **.flac** | Free Lossless Audio Codec。無損失圧縮フォーマット。 | 音質を損なわない圧縮、圧縮率が高い。 | ファイルサイズが大きめ、対応プレーヤーが限定的。 | 高音質音楽保存、アーカイブ。 | 〇 | 〇 |
| **.ogg** | Ogg Vorbis。オープンソースの音声圧縮フォーマット。 | ライセンスフリー、高音質。 | 対応デバイスが少ない。 | ゲーム音声、ストリーミング。 | 〇 | 〇 |
| **.m4a** | MPEG-4 Audio。AACをベースにしたフォーマット。 | 高音質、iTunesなどでの広いサポート。 | 非Apple製品での互換性に制限。 | 音楽配信、Appleエコシステム。 | 〇 | 〇 |
| **.aiff** | Audio Interchange File Format。Appleが開発した無圧縮音声フォーマット。 | 高音質、編集に適している。 | ファイルサイズが大きい。 | プロの音声編集、Apple製品での使用。 | 〇 | 〇 |
| **.wma** | Windows Media Audio。Microsoftが開発した音声フォーマット。 | Windowsとの高い互換性。 | 一部デバイスやソフトでの対応が限定的。 | Windows環境での音楽配信。 | 〇 | △（対応アプリで可能） |
| **.opus** | 高効率音声圧縮フォーマット。VoIPやストリーミングに適している。 | 低遅延、高音質。 | 一部プレーヤーでの対応が限定的。 | インターネット通話、ストリーミング。 | 〇 | 〇 |
| **.alac** | Apple Lossless Audio Codec。Appleの無損失圧縮フォーマット。 | 音質を損なわない圧縮、Apple製品との高い互換性。 | 他のプラットフォームでのサポートが限定的。 | Appleエコシステムでの音楽保存。 | 〇 | 〇 |
[Ruby] 改行ルールについて

# 概要

Rubyの改行ルールについて、参考書を読んだ際に気づきがあったのでまとめました。

# 改行ルール

Rubyでは「**文末が改行であることが明らかな場合のみ**」改行可能です。
文末が以下文字列で終わるケースを指します。
- `,` 
- `(`, `{`, `[` 
- 演算子（`+`, `-`, `&&`, `||`）
- メソッドチェーン（`.`）
- `\`

上記以外にもルールはありますが、一般的なものをピックアップしています。

# サンプルコード

### `,`
```ruby
array = [
  1,
  2
]
```

### `(`, `{`, `[` 
```ruby
def my_method(
  arg1
)
end

hash = {
  a: 1,
  b: 2
}

array = [
  1,
  2
]
```

### 演算子（`+`, `-`, `&&`, `||`）
```ruby
flag = condition1 &&
        condition2 ||
        condition3
```

### メソッドチェーン（`.`）

```ruby
User.where(active: true)
    .order(created_at: :desc)
    .limit(10)
```

### `\`
```ruby
a = 100
puts \
  a

# ただし、メソッド名や識別子を改行で分割することは不可（以下はエラー）
a = 100
pu \
  ts a
```

# 参考文献

https://gihyo.jp/book/2022/978-4-297-13062-6

https://qiita.com/Nabetani/items/66da23a83b65aba4dc20
まーたpyenv globalしたpythonのバージョンと実際に使用されてるバージョンが違う

# どういうこと？
こういうこと
```
pyenv install 3.13
Downloading Python-3.13.1.tar.xz...
-> https://www.python.org/ftp/python/3.13.1/Python-3.13.1.tar.xz
Installing Python-3.13.1...
Installed Python-3.13.1 to /root/.pyenv/versions/3.13.1
root@b5f1f59af63d:/home/volume/langgraph_demo# pyenv global 3.13.1
root@b5f1f59af63d:/home/volume/langgraph_demo#  python -V
Python 3.11.0
root@b5f1f59af63d:/home/volume/langgraph_demo# pyenv versions
  system
  3.11.0
* 3.13.1 (set by /root/.pyenv/version)
```
python -vの結果が3.13.1になっていてほしい

# いろいろやってみる

まずはパスを調べる
```
(3.11.0) root@b5f1f59af63d:/home/volume/langgraph_demo# which python
/root/.pyenv/versions/3.11.0/bin/python
(3.11.0) root@b5f1f59af63d:/home/volume/langgraph_demo# which pyenv
/root/.pyenv/bin/pyenv
```
.pyenv/shims/pythonみたいにshimsの中じゃないんだなとは思ったが、pyenvを向いていそうではある

Pyenvの設定を再度有効化
```
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"

```

rehashして再度確認
```
root@b5f1f59af63d:/home/volume/langgraph_demo# pyenv rehash
root@b5f1f59af63d:/home/volume/langgraph_demo# python -V
Python 3.13.1
root@b5f1f59af63d:/home/volume/langgraph_demo# pyenv versions
  system
  3.11.0
* 3.13.1 (set by /root/.pyenv/version)
```

無事一致した
新規に環境を作っているとときどきこの事象に遭遇するため、根本的に解決したいところ。
空白だけ。見えない言語「Whitespace」

# コードって...
まあ、皆さんこういうのを想像しますよね。
```python
print("この例はPythonです")
```
まあこの言語って、もちろん**見える**じゃないですか。
じゃあこれはどうですか？
```text
   	      	 
   			 		   		  	 
    
		    	  	   
	
     		  	 	
	
     		 		  
 
 	
  	
     		 				
	
     	     
	
     	 	 			
	
     		 				
	
     			  	 
	
     		 		  
	
     		  	  
	
     	    	
	
     	 	 
	
   
```
これは**見えない言語**である
「Whitespace」です！ちなみにこれは、HelloWorldを出力するプログラムです！

# 当たり前を覆すWhitespace
コードの**見える**という当たり前を壊したWhitespaceは
読めない言語になりましたとさ。
おわり。
最後までお読みいただきありがとうございます。
コメント、いいねしてくれると嬉しいです。
Qiitaで記事を書き始めて分かったこと

# いつから始めたの？
最初の記事の投稿日である2024年11月08日です。

https://qiita.com/Cheesecake2960/items/1eb6338ead2dbf4d9d19

そこから何故か放置し始めました(?)
投稿が再開したのは拡張機能を作ったことを書いた時です。

https://qiita.com/Cheesecake2960/items/df629fdda0a4e59a56da

これです。
その記事を投稿するとき、
「アドベントカレンダー？なにそれおいしいの？」
という感じになり、今はアドカレのおかげで投稿が止まってません

# Qiitaのいいところ

### Markdown記法が結構いい
HTMLより単純なMarkdownは、記事を書くのに
最適だと思います！

### 結構記事が見られる！
https://qiita.com/Cheesecake2960/items/1dba050bee8410517f1f

この記事とかは、180件ぐらい見られてますからね。
すごくうれしい。モチベが上がる。

# おわりだよ
最後まで読んでいただきありがとうございます。
次は「見えない言語 Whitespace」
について記事を書きます！
君には10分でGitの触りだけ知ってもらう

## この記事で触れること
- Gitの概要（本当に触りの部分だけ）
- Gitでよく聞く最低限の用語の解説
- Git、GitHubを使った開発の流れ「例」

## この記事で触れないこと
- ステージング、リポジトリなどの名前を最悪知らなくてもなんとかなりそうな用語の解説
- リバート、チェリーピックなどのたまに行うコマンドの解説
- インストール、Gitコマンド実行などのハンズオン手順

## Gitってなに？
ギットと読みます。
**「ファイルのタイムマシン」** みたいなもんです！
Gitを使えばこんなことができます.
- ファイルを過去の状態に戻す
- ファイルの変更履歴を確認する
- チームで同じファイルを同時に編集する

これがあると、「あの時のバージョンに戻したい！」という夢が簡単に叶います
間違えてファイルの中身全消ししちゃっても大丈夫大丈夫！！

## GitHubってなに？
「Gitが本なら、GitHubは図書館」です！
GitHubはアプリやドキュメントなどをオンラインで管理・共有するためのサービスになります

Git = ローカル（自分のPC）で管理するツール。
GitHub = リモート（クラウド）で管理＆公開するツール。

## Git基本概念
Gitを使う上でよく出てくる用語がありますので最低限押さえておきましょう！
### クローン
偉大なる先輩方が作ってくださったアプリを自身のPCに持ってきて開発可能な状態にすること
まずは感謝の気持ちを込めてクローンするところから始めましょう

### プル
クローンがアプリを丸々持ってくることに対して、アプリの変わった部分（他の人が開発した部分）だけ持ってきて自分のPC上にあるアプリに反映させること
こちらも感謝の気持ちを込めましょう。

### ブランチ
ブランチを例えるなら「別のストーリーを書くノート」
ストーリーの大筋はできているが、追加ストーリーを書きたい場合、元のストーリーのノートとは別のノートを用意して新しい章を書き始めるイメージです。
追加ストーリーがぐちゃぐちゃになってもメインのノートはそのままなのでいつでもやり直せます
ブランチを作る＝ブランチを切るという言い方をすることが多いです

### コミット
コミットを例えるなら「セーブ」
ファイルの状態を「今ここでセーブして、そのセーブデータは残しておく！」というイメージです
このセーブデータを遡ったり、比べたりすることで変更履歴が分かります。
昔のセーブデータを呼び起こして過去の状態の戻すこともできちゃいます。

### プッシュ
自分のPC側で開発した変更部分（コミット）をGitHubに送ること
ブランチごと送ることができるので、GitHub上のメインストーリーにいきなり変更が反映されることはないのでご安心を！

### マージ
マージはブランチを本体に統合します。
追加ストーリーをメインストーリーにマージして、それを新たなメインストーリーとする、といった感じです

## Git、GitHubを使った開発の流れ例

![画像用.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/620431/973419cf-3e0a-84ad-dc9e-59b68abc78a2.jpeg)

まずはじめにGitHubには既に先人が作ってくださったアプリが存在する状態で考えます
1. 初心者ワイはGitHubからアプリを自分のPCに「クローン」します。もう既にアプリがクローン済であれば「プル」で他の人の開発部分を自分のPCのアプリに反映させます
1. 初心者ワイは自分のPC上で「ブランチ」を切ります。これで元のアプリの状態はそのままに開発を進められます
1. 開発の途中途中で「コミット」をします。これで現時点の開発成果物がセーブされます
1. 開発が一通り完了したらGitHubに「プッシュ」します。これでGitHubにワイの成果物が送られます
1. ワイの成果物を先輩にレビューしてもらってOKなら「マージ」する。これでメインのアプリに開発が統合されます
1. 以降☝️の繰り返し

## 終わりに
今回はGitで最初に覚えるべき用語とよくある開発の流れ例を紹介しました。
簡単に概要をつかんだところで次はこちらの記事を読むのをオススメします

https://qiita.com/jesus_isao/items/63557eba36819faa4ad9

こちらの記事は私が新卒で入社した会社の先輩が書いたもので、当時の私は「あれ、はてブで見たことある記事が…あれこれなんかバズってない！？すご先輩すご！！」ってなってたのが記憶に新しいです。
この頃の自分は将来開発エンジニアになるとは1mmも思っていなかったので、この記事見てもｱﾝﾏﾘﾖｸﾜｶﾝﾅｲﾔって感じでした。

今回は改めて先輩の偉大さを胸に刻み、その前段階の本当に触りの部分だけを自分なりにまとめてみました。
タイトルパクってしまってすみませんでした。。。
【Ruby】今日書いたコードの振り返り#3

## はじめに

こんにちは！アメリカの大学で語学を学びながら、独学でソフトウェアエンジニアを目指している者です。

Rubyで繰り返し処理を書く中で、「`each`の返り値」と「なぜ明示的に`return`を書く必要があるのか」に疑問を持ちました。

この記事では、具体的なコード例を用いて、`each`の返り値と`return`の役割について解説します。

---

### 問題のコード

次のコードを例に考えてみましょう。

```ruby
def prefix(ary, obj)
  result = []
  ary.each do |item|
    result << item
    if item == obj
      return result
    end
  end
  return result
end

p prefix([1, 2, 3, 4, 5], 3)
```

このコードは、配列`ary`の要素を順番に`result`へ追加し、`obj`が見つかった時点で`result`を返します。

`p prefix([1, 2, 3, 4, 5], 3)` を実行すると、`[1, 2, 3]`が出力されます。

しかし、最初は `return result` がなぜ必要なのか分かりませんでした。

なぜなら、`ary.each`の返り値が最後に評価された `result << item`だと考えていたためです。

---

### 最後の`return result`が必要な理由

#### `return result`を省略するとどうなるか

`obj`が見つかった場合は`if item == obj`内で`return result`が呼ばれるので問題ありません。しかし、`obj`が見つからない場合、最後に評価される値は`each`メソッドの返り値になります。

`each`は最後に評価された式ではなく、\*\*元のコレクション（`ary`）\*\*を返すメソッドです。そのため、`return result`を省略すると、`obj`が見つからない場合は元の`ary`を返してしまいます。

結果的に同じ要素が返ってくることもありますが、このメソッドが本来返したいのは`result`であり、`ary`ではありません。したがって、最後に明示的に`return result`を書いて、「このメソッドは常に`result`を返す」という意図をコードで明確にする必要があります。

---

### なぜ`each`の返り値は最後に評価された式ではなく元のコレクションなのか

ここで新たな疑問が生まれます。「`each`はなぜ`result << item`ではなく`ary`を返すのか？」

#### `each`が元のコレクションを返す理由

##### 1. **繰り返し処理が目的**

`each`は要素に対して処理を行うためのメソッドで、結果を集めることが目的ではありません。

処理を実行することがメインであるため、戻り値はシンプルに元のコレクションを返す設計になっています。

##### 2. **メソッドチェーンを可能にするため**

`each`が元のコレクションを返すことで、後続に`map`や`select`などのメソッドを続けて呼ぶことができます。

もし`each`が最後に評価された式（例えば`nil`や`result << item`）を返していたら、メソッドチェーンがしづらくなるでしょう。

##### 3. **副作用を伴う処理に便利**

`each`は標準出力やファイル出力など、副作用が目的の処理と相性がよく、返り値が元のコレクションであることで、処理結果を気にせず繰り返しを実行できます。

---

### 他の返り値について

Rubyでは`each`以外にも、さまざまな構造で返り値が決まっています。

- **メソッド**: 最後に評価された式、または`return`で指定した値が返り値
- **クラス定義**: クラス名を返す
- **モジュール定義**: モジュール名を返す
- **ブロック**: ブロック内で最後に評価された式が返り値となり、`map`や`select`などがこれを利用して結果を集計

---

### まとめ

#### 問題のコードについて

`return result`が必要な理由は、`obj`が見つからなかった場合にも`result`を返すためです。`each`の返り値が元の`ary`であるため、明示的に`result`を返すことで意図が明確になります。

#### `each`の返り値について

- `each`は最後に評価された式ではなく元のコレクションを返します。
- これは繰り返し処理に特化しており、メソッドチェーンや副作用を伴う処理に適した設計思想によるものです。

#### その他の返り値について

- メソッド、クラス、モジュール、ブロックなど、それぞれ固有の返り値のルールがあります。
Qiita Advent Calendarをめちゃくちゃ頑張っている話

# こんにちは
Cheesecakeです。12月です！クリスマス！アドベントカレンダーです！
というわけで、この記事では、アドカレの話をしようと思います！

# アドカレってなに？
#### Qiita Advent Calendarとは？
> 毎年12月1日から25日までの期間限定でQiitaで開催される、年に1度の記事投稿イベントです。毎年、Qiitaとクリスマスを最高に盛り上げる一大イベントとなっております。

https://help.qiita.com/ja/articles/qiita-adcal-1

という感じです。

# プレゼントももらえる！
アドカレ最大の目玉といっても過言ではない、**プレゼントがある**というところです！Qiitaの記事を書くだけで、プレゼントがもらえるんですよ！最近はこれのおかげで投稿頻度が上がってます:cheese::cake:

### どんなプレゼント？
- Qiita Tシャツ、ぬいぐるみ
- Mac mini, iPad, iPhoneなど
- Amazon ギフトカード
などなど、プログラマーにうれしいものがたくさんあります！

# おわり
Qiitaをまだやってない人も、これをきっかけに
投稿を始めてみてはどうでしょうか？
コメント、いいね、お願いします:smile:
ONCE / Campfireのコードを読んでみた

本記事は[READYFOR Advent Calendar 2024](https://qiita.com/advent-calendar/2024/readyfor)の10日目の記事です。

Railsを開発している会社が、実際にどのようなRailsアプリケーションのコードを書いているのかを知ることができる、という[噂を耳にしました](https://techplay.jp/event/957689)。日頃のRailsへの感謝の気持ちも込めて、思い切って身銭を切り、**$299**で[Campfire](https://once.com/campfire)を購入し、読み解いてみました。（※オープンソースではないため、コードそのものはこの記事に掲載していません）

# 興味はビジネスロジックをどこに書いているか？

出た...この話題...何周目よと言われそうだが、わたしの興味はこの1点のみです。

- ビジネスロジックをどこに書いているか？
  - `app/models`のみで見通しの良いコードになるのか？

## 経験上、この3パターン

実務でよく見る3つのパターン、それぞれ一長一短があると考えています。

### モデル (app/models) 派

- メリット: 
  - 伝統的なRailsの「Fat Model, Skinny Controller」のアプローチを踏襲し、ActiveRecordモデルにビジネスロジックを持たせることで、Railsの標準的な構成を維持できます。初学者や小規模なプロジェクトには理解しやすく、Rails Wayに忠実。
- デメリット: 
  - モデルが肥大化しやすく、特に複雑なビジネスロジックを持つ場合は、テストが難しくなることがある。また、ActiveRecordに依存する形でロジックを記述するため、インフラ層（データベース）との結合が強くなりがち。

### サービスクラス (app/services) 派

- メリット: 
  - ビジネスロジックをサービスクラスに分離することで、モデルやコントローラがシンプルになり、コードの責任範囲が明確になります。また、サービスクラスはテストがしやすく、再利用性が高い
- デメリット: 
  - サービスクラスが増えすぎると管理が複雑になり、結局どこに何があるのかが分かりにくくなることも。特に大規模プロジェクトでは、明確な命名規約や依存関係の管理が重要。

### DDD (app/contexts, app/contexts/domain, app/contexts/infra...) 派

- メリット: 
  - ドメイン駆動設計（DDD）の考え方に基づいて構成を設計するため、ドメインごとに分割されたコードがビジネスロジックを自然に反映するようになる。複雑なビジネスロジックを整理しやすく、特に大規模なシステムでの拡張性に優れる。
- デメリット: 
  - 学習コストが高く、全てのチームメンバーがその設計方針を理解し、遵守する必要がある。また、Railsの標準的な構成から離れるため、既存のRails開発者にとっては馴染みにくい。


# 本題のコードリーディング

正直なところ、もっとボリュームのあるコードを期待していましたが、実際のコード量はそれほど多くなく、感想をまとめるのが難しい部分もありますが...

- **`app/models/concerns`に切り出して、見通しのよいコードを保っている**
  - concernsディレクトリを活用し、共通の処理をモジュールとして切り出すことで、コードの見通しをよくしていました。このアプローチは、たとえばマストドンのコード構造にも見られます。
    - [Mastodonの例](https://github.com/mastodon/mastodon/tree/main/app/models/concerns/user)
- **複数のモデルにまたがる処理についての実装**
  - こちらの[参考記事](https://zenn.dev/igaiga/books/rails-practice-note/viewer/ar_processing_across_multiple_models#%5Bactiverecord%5D-%E8%A4%87%E6%95%B0%E3%81%AE%E3%83%A2%E3%83%87%E3%83%AB%E3%81%AB%E3%81%BE%E3%81%9F%E3%81%8C%E3%82%8B%E5%87%A6%E7%90%86%E3%82%92%E6%9B%B8%E3%81%8D%E3%81%9F%E3%81%84%E3%81%A8%E3%81%8D%E3%81%AE%E8%A8%AD%E8%A8%88%E6%96%B9%E6%B3%95)の通りの実装でした
    - **主となるモデルに処理を実装**
    - **`app/models`配下に何も継承していないただのクラスで実装**

が、感想になります。

# で、あなたの意見は？

最終的には、プロジェクトとしての一貫性が重要だとは思います。ただ、現実にはやり切れずに複数の手法が混ざり合い、結果的にコードが混沌としてしまうこともよくあります。そのため、どのアプローチを採用するにせよ、徹底的にやり切ることが鍵だと感じます。

個人的には、あまり大きな声では言えませんが、下記の参考例から`app/services`は肯定派です。

- **マストドンのコードベース**
  - マジカルなコードもなく、読みやすく整理されていると感じます。
- **[「Sustainable Web Development with Ruby on Rails」](https://sustainable-rails.com/)**
  - この書籍には、次のような興味深い指摘があります。
> これが美しいコードだとは言いません。これがオブジェクト指向の設計原則に準拠しているとは言いません。 。 。それらが何であれ。また、これがDHHのやり方であるとは主張しません。

> 私が主張するのは、このアプローチにより、Railsから大量の価値を引き出すと同時に、ビジネスロジックを好きなように統合および整理できるということです。そしてこれにより、そのロジックがHTTPリクエスト、メール、データベース、およびRailsによって提供されるその他のものと絡み合うのを防ぐことができます。そして、これは持続可能性に大いに役立ちます。

- **Service Layerに関する考察**
  - https://davetron5000.github.io/service-layer-railsconf-2022/

<hr>

明日は、 yuji_developer さんによる記事です。
何もしてないのに物を壊した時の心構え

今年を振り返る「なんかかく」アドベントカレンダー 10 日目です。たまに BYOD します。Bring ではなく、Break です。今年も Break しました。何もしていないはずなのに...

仕事柄、仕事道具が突然不調をきたすと突然色々調整を掛けないといけないところがツライのですが、そこで色々焦って騒いだり設定を変えまくったりすると余計に時間とリソースを浪費しますね。

## 何もしてないのに壊れる

昔からそんなことがありました。
[Intel Wireless AC 9560が突然エラーになりWi-Fiが何も見つからなくなることがある #Windows10 - Qiita](https://qiita.com/e99h2121/items/cfcd0b7d221c90150009)

最近でも個人的に突然 C ドライブのサイズが突然無くなった！とか、騒いだことがあります。優しく以下を教えてもらいました。単に Docker が巨大なログをはいて落ちてた。そういうこともあるよね。

[「TreeSize Free」がついに64bit化 ～ファイルのディスク占有率を高速に可視化する無償アプリ - 窓の杜](https://forest.watch.impress.co.jp/docs/news/1434172.html)

他にもキーボードが壊れたり、カメラ、マイクが壊れるとか。macOS を再インストールしたりしました。
[macOSを再インストールする方法 - Apple サポート (日本)](https://support.apple.com/ja-jp/102655)
パスワードも良く忘れますね。Mac、キーボードがログイン時は英字、ログイン後は日本語になるとかするんだぜ。

## 壊れたときにまとめないといけないフォーマットを決めておくと楽

ということでこんな記事を書きました。

[あわてない技術 #SRE - Qiita](https://qiita.com/e99h2121/items/21ae78f196f4cc66abd9)
> 日ごろから慣れる。

慣れるためには脳みそを楽にすること。型を決めておくのが楽です。

```:壊れたとき
## ID
- 社員番号とかメールアドレスとか
- チームとか

## いつ頃から
- 発生時刻、発生に気づいた時刻

## 試したこと
- キャッシュクリア
- サインアウトからのサインイン
- OS 再起動

## 影響範囲
- 〇時に〇〇できないと困る
- or 最悪来週でもどうにかなる

```

まあなんにせよ、世に言われるテクニカルサポートを頼るときのフォーマットというのは自分が質問するときのフォーマットでもあります。

## おちつけ

[ほぼ日の「おちつけ」 - ほぼ日刊イトイ新聞](https://www.1101.com/store/ochitsuke/goods/index.html?srsltid=AfmBOootS9ac_Qz5GIAa5a4WvVQflUYbTUAzGC5sOc_Z0ghKQ7tIY_dw)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/578527b7-ad26-f5ce-47e1-c7d72809bdbd.png)


- 冷静に Wiki をあさる
- 冷静に過去のチャットをあさる
- 冷静に FAQ を読む
- 冷静に Known issues を調べる

最悪それでも解決しない場合には、人類未知の課題として記録に残すと将来に貢献できるとは思うくらいの心構えでいると、案外翌朝ふと解決策を思いついたりします。

## まとめ

今年は [Mac のマウスのスクロール方向が逆](https://www.bossraku.com/blog/365/) であることをはじめて知りました。
Shift + Command + 4 がスクリーンショットであることもはじめて知りました。
世の中いつもと違うことが起こってもあわててはいけないですね。
今日は表 (?) の方の記事も書いてますのでこんなところで！ : [Logic Apps と Logic App とロジック アプリ #Azure - Qiita](https://qiita.com/e99h2121/items/f6313c2eabaa2d2b70f6)

以上です～