OmniAICreator/Qiita-1.07M huggingface dataset:
Pythonのturtleグラフィックスでペンギンを描いてみよう（ChatGPTのコードを修正してみた編）

# はじめに

　前回の記事で、ChatGPTにペンギンを描くコードを聞いてみたところ、やりたいことは分かるけど成立していない絵が出てきました。
 
 ただ、要素自体は使えそうなものが多かったので、読み解いた結果を使って、コードを修正してペンギンを描こうと思います。

 https://qiita.com/awonohata/items/8abcd7732c8572f86f6d

# Pythonのturtleグラフィックスでペンギンを描いてみよう（ChatGPTのコードを修正してみた編）

## 出力イメージ

　ちょっと顔とポーズがぎこちない感じはしますが、パッと見てペンギンっぽくなっているのではないでしょうか？
 ※おでこのところが少し苦し紛れではありますが。

![penguin_GPT.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/974182/9112b484-4630-1025-8543-fd575d20f415.gif)

## コード

　基本的な流れは以下の通りです。
 
1. 顔の土台（黒）を描く
2. 顔の土台（白）を描く
3. 額の部分の模様を丸（黒）で表現する。
4. 目を描く
5. クチバシを描く
6. 手を描く
7. お腹の土台（黒）を描く
8. お腹の模様（白）を描く
9. 足を描く 

### ChatGPTのコードからの修正部分

　描画画面を見ていると分かりますが、ほとんど丸で構成されています。
 
* 円の大きさの調整
* 円の位置の調整
* 要素の追加

~~~Python
import turtle
def draw_penguin():
    screen = turtle.Screen()
    screen.title("Turtle Penguin")
    # Creating a turtle object(pen)
    pen = turtle.Turtle()

    # Defining method to draw a colored circle with a dynamic radius
    def ring(col, rad):
        # Set the fill
        pen.fillcolor(col)

        # Start filling the color
        pen.begin_fill()

        # Draw a circle
        pen.circle(rad)

        # Ending the filling of the color
        pen.end_fill()

# Draw face

    # Draw face(black)
    pen.up()
    pen.setpos(0, 35)
    pen.down()
    ring('black', 45)

    # Draw face(white)
    pen.up()
    pen.setpos(0, 38)
    pen.down()
    ring('white', 35)

    # Draw face(black)
    pen.up()
    pen.setpos(0, 90)
    pen.down()
    ring('black', 15)
    
# Draw eye

    # Draw first eye
    pen.up()
    pen.setpos(-18, 75)
    pen.down
    ring('black', 8)

    # Draw second eye
    pen.up()
    pen.setpos(18, 75)
    pen.down()
    ring('black', 8)

    # Draw first eye(white)
    pen.up()
    pen.setpos(-18, 82)
    pen.down()
    ring('white', 2)

    # Draw second eye(white)
    pen.up()
    pen.setpos(18, 82)
    pen.down()
    ring('white', 2)

# Draw beak

    # Draw beak
    pen.up()
    pen.setpos(0, 55)
    pen.down()
    ring('orange', 8)

# Draw arms

    # Draw arms(black)
    pen.up()
    pen.setpos(-30, 10)
    pen.down()
    ring('black', 20)

    # Draw arms(black)
    pen.up()
    pen.setpos(30, 10)
    pen.down()
    ring('black', 20)

# Draw belly

    # Draw belly(black)
    pen.up()
    pen.setpos(0, -40)
    pen.down()
    ring('black', 40)

    # Draw belly(white)
    pen.up()
    pen.setpos(0, -40)
    pen.down()
    ring('white', 30)

# Draw feet

    # Draw feet
    pen.up()
    pen.setpos(-25, -40)
    pen.down()
    ring('orange', 10)

    pen.up()
    pen.setpos(25, -40)
    pen.down()
    ring('orange', 10)

    turtle.done()

draw_penguin()
~~~


# まとめ

 位置座標や大きさを調整しながら実行…また描画画面を見て修正・実行…を繰り返してかなり時間がかかりましたが、なんとか作成できました。ただ、ChatGPTがなければスタートラインすらも立てなかったような気がしています。

　そこで、
* 一から自分で描くよりもChatGPTに聞いた方がいい時もある
* ChatGPTの内容が間違っていても、それを下敷きにコードを修正することは可能
* そのために、コードで何を表現しているのか読み解く知識・力が必要
* 可読性を高めるために、コメントを有効活用することも重要
と感じました。
作品：データファイル作成（CSV_Generator）

#概要

データファイル作成スクリプト。

Github: https://github.com/RistoLibera/CSV_Generator

#使用技術

・VBS

#機能一覧

![1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/da20cc14-8647-94be-b318-512172860489.png)

スクリプトとExcelファイルを同じフォルダに入れ

![2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/8c76cdac-8b62-786d-b424-541a725d9169.png)

WindowsのCLIを開いて、範囲、シートの名前、データファイルの名前を指定して実行。

![3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/b117ccbe-aa4a-afde-4ca7-3fbe5d96cd75.png)

データファイルが生成します。

#まとめ

かなり簡単な自動化ツールだが、手作業よりましだ。
NextAuth.js&PlanetScaleでSlackログインを実装する

Next.jsを使っている場合に、NextAuthを使うことで
簡単にログイン認証を作成することが出来ます。

https://next-auth.js.org/

利用できる認証は、かなり多いです。
ドキュメントのProvidersを見てみてください。

https://next-auth.js.org/providers/

Firebase AuthにはないようなLINEなども完備されています。
ただ、Firebase Authもカスタム認証を実装すれば、もちろん対応可能です。

今回、NextAuth.js&PlanetScaleでSlackの構成でログイン認証を組んだのでメモを残します。

NextAuthでSlackを使うドキュメントはここで
DANGERにかかれている内容が厄介です

https://next-auth.js.org/providers/slack

まあhttpsを使いましょうということなんですが
localhostでhttpsを使おうとすると色々手間が必要だったのですが
Nxet.jsの機能で気軽にhttpsが使えるようになっていました

https://zenn.dev/kazu31/articles/nextjs-local-ssh

公式ドキュメントが AppRouter ではなくて PageRouter っぽかったので
次の記事を参考にさせていただいました

https://zenn.dev/tfutada/articles/5557b780050574

https://qiita.com/kage1020/items/8224efd0f3557256c541

NextAuth自体はDBが必須ではないので
DBと連携するための設定を行う必要がありました。

最終的に `[...nextauth]/route.ts` はこんな感じになりました。

```typescript
import SlackProvider from "next-auth/providers/slack";
import NextAuth from "next-auth";
import { PrismaAdapter } from "@auth/prisma-adapter";
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

const adapter = PrismaAdapter(prisma)

adapter.linkAccount = async ({ provider, type, providerAccountId, access_token, token_type, id_token, userId }) => {
  await prisma.account.create({ data: {
    provider, type, providerAccountId, access_token, token_type, id_token, userId
  } });
  return;
}

export const authOptions = {
  secret: process.env.NEXTAUTH_SECRET,
  adapter: adapter,
  providers: [
    SlackProvider({
      clientId: process.env.SLACK_CLIENT_ID,
      clientSecret: process.env.SLACK_CLIENT_SECRET
    })
  ],
  callbacks: {
    async session({session, user}) {
      if (session?.user) {
        session.user.id = user.id;
      }
      return session;
    }
  },
};

const handler = NextAuth(authOptions);

export { handler as GET, handler as POST }
```

何だか、普通にやるとエラーが出てしまうので次の記事を参考に
adapter.linkAccountを書き換えています。

https://github.com/nextauthjs/next-auth/issues/3818
365日毎日草をはやし続けると得られるものは何？

## はじめに
毎日毎日とにかく草をはやし続けていました。そして、ついに１年間続けることに成功しました。
実際に達成してみてどうだったか、つらつらと書いていこうと思います。
あまり何かが学べるような記事ではないと思いますが興味があれば読んでみてください。

↓去年からはやし続けた草たち。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2644705/cbb8d589-ab5a-c205-d93d-588846e226f9.png)


## なぜ毎日草を生やそうと思ったのか
同じ会社で働いているエンジニアが１年間草をはやし続けたことを社内のLTで話していて、「すげっ、オレもやろ！」って思ったからです。そんだけです。

彼の365日草をはやし続けるチャレンジについての記事もあるのでぜひ読んでみてください。
https://qiita.com/sauna1137/items/a8c2a078a31d367b789d

## 続けるために意識したこと
### 極限までハードルを下げること
草を生やすことへのハードルをめちゃくちゃ下げました。実際にコードを書いていなくてissueを発行するだけでもOK。個人開発のコードを数行書いただけでもOK！なんでもOKです！

とにかく草が生えればなんでもいいんです。
続けることが大事なんです。

## この1年でできたことと得られた成果
### 個人開発
#### やったこと
- 新規アプリを1つリリース
- 既存アプリのアップデートを15回くらい
- アプリにリワード広告、アプリ内課金(サブスク、買い切り)を導入などをできました。
- SwiftUIを使っての新規アプリの開発

#### 得られた成果
- 1年間で2.5万のアプリダウンロード
- アプリからの収益(約1.5万円/月)

### 技術面
#### やったこと
- RxSwift+MVVM
- Combine
- TDD
- SwiftData
- StoreKit2
- KotlinでAndroid開発
- Flutter開発
- Goのプログラムをローカルで動かしてアプリと通信
パッと思いつくところでこんなところ。

## 実際に１年間草をはやし続けて感じたこと
1年間何かを続けられたというところにわずかな達成感を感じました。思っていたほどの達成感はありません。

これはおそらく１年続けている頃にはすでに「草を生やす」行為自体が当たり前になり過ぎていて、あまり特別なものには感じなかったのかも。

続けられたということよりも、サブスクで収益を得られた時とか、自分のアプリを実際に使っている人がいるということを知った時の方が達成感とか嬉しさは大きかったと思います。

## 現状と次にやりたいこと
その後、草はどうなっているかというと最近はすでに何日も草が生えてない日が出ています。

![スクリーンショット 2023-12-24 16.47.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2644705/c607ea2a-8611-858a-bbf8-3eac699d2535.png)

１年間を通して「続ける」ということに関してほとんど意識することなく行える下地ができました。
次は続けるというところに意識するのではなく、「どんな技術を身につけられたか」「個人開発でどんな成果をだせたか」のような草の質にフォーカスしていきたいと思っています。今まではほぼ枯れかけの草をはやしていただけなので...

## 最後に
１年間続けると、歯を磨くかのようにほぼ無意識にコードを書いたり、個人開発のことを考えたりすることができるようになります。続けられるという状態さえ作ってしまえば、結構いろんな道が見えてきそうじゃないですか？

みなさんもぜひ１年間草をはやしてみてはいかがでしょうか？

それでは！
javascriptにもgroupbyが出たらしい

# はじめに
それなりに時間はたったもののJSでgroupByが使えるようになったらしい（前からあったらごめんなさい）
あまり深くは触らないがちょっとだけ触ってみる

# 構文
```javascript
Object.groupBy(items, callbackFn)
```

グループ化したいアイテムと処理を渡したら配列を含むオブジェクトを返してくれるっぽい？

# ためしてみる
```javascript
    const reports = [
        { name: "report_A", status: "1", user_id: 1 },
        { name: "report_B", status: "1", user_id: 2 },
        { name: "report_A", status: "2", user_id: 1 },
        { name: "report_A", status: "1", user_id: 2 },
        { name: "report_B", status: "2", user_id: 1 },
    ];
    const result = Object.groupBy(reports, ({ name }) => name);
    console.log(result)
```

これでname単位でのグループ化をしてくれるらしい

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519878/6fa43b5b-d676-db81-823c-d2b41e7e3807.png)

# もうちょい触ってみる
```javascript
    const reports = [
        { name: "report_A", status: "1", user_id: 1 },
        { name: "report_B", status: "1", user_id: 2 },
        { name: "report_A", status: "2", user_id: 1 },
        { name: "report_A", status: "1", user_id: 2 },
        { name: "report_B", status: "2", user_id: 1 },
    ];
    const result = Object.groupBy(reports, ({ name }) => name);
    // console.log(result)

    const counts = Object.fromEntries(
    Object.entries(result).map(([key, values]) => [key, values.length])
    );

    console.log(counts)
```

グループ化したやつからいい感じにグループ化したキーと件数を取得してみる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519878/d816873c-e84e-a7cb-cd7f-829f62b0a3d5.png)

# 何に使える？
一覧でデータ取得してる系のところとかだと取得データをフロント側でちょちょいといじって割合のグラフ作ったり、ラジオボタンとかでキーを指定して集計からの再描画とかできそう

データ取得が全件バーンだけでよくなるので何かしらかには使えそうな気がする

# 参考
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Object/groupBy
SEO初心者でもできる自社サービスのリード増加に向けたSEO対策のはじめ方

## はじめに
SEO対策の重要性は誰もが認識していますが、実際に成果を出すまでの道のりは決して簡単ではありません。この記事では、SEO初心者が自社サービスのリードが伸び悩んでいた課題に対して、どのように取り組み、どのような成果を得たかを共有します。



本記事は、[株式会社ACCESS Advent Calendar 2023](https://qiita.com/advent-calendar/2023/access) の24日目の記事です。
メリークリスマスイブ🤘🎅


## 課題の概要
* 自社サービスのリードが増えない
* ターゲットにリーチできる記事が不足している
* 効果的なSEO対策ができていない


## 実施した取り組み
### ユースケース分析
弊社が提供しているプロダクトを、ユーザーがどのように使っているかを可視化するために、ユーザーごとのユースケースや機能を洗い出しました。
ニーズはあるが製品サイトで紹介されていないユースケースや機能を調査し、どのキーワードを狙っていくかの方針を決めました。
例えば、 弊社サービスの [Linkit Maps](https://linkit.access-company.com/map_advance/) だと位置情報を記録して過去の移動経路を表示する「移動履歴」という機能を使いたいという声が多いことが数字で可視化されました。


### キーワード分析
キーワード分析では、まず、ユースケースや高利用率の機能を基に、ターゲット層に響くキーワードを洗い出す作業から始めました。このプロセスでは、ターゲット層がどのようなキーワードを使用して製品を検索するかを想定し、それに基づいて複数のキーワード候補をリストアップしました。

### 検索ランキング上位を狙えるキーワードを選定
次に、SEO対策ツールを活用して、これらのキーワード候補に関連するキーワードを調査しました。また、検索ボリュームの確認や、検索結果のランキングで上位に位置するための難易度を分析しました。


### コンテンツ制作
狙いたいキーワードにもとづいた新規記事作成や既存記事のリライトを実施しました。
記事は作成できるようになりましたが、特に期日に制約がなかったため他の作業を優先してしまうこともありました。その結果、計画的なコンテンツ配信が課題となりました。


### 記事を定期リリースするためのリリーストレインの作成
計画的に記事を作成するために、スクラム開発でよくあるリリーストレインを作成しました。
下記のように週1記事を目標にするリリーストレインを作成し実行しました。

![記事作成リリーストレイン.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538286/78519e09-5209-bb54-f8e1-c6bdef019a0d.png)


## 得られた成果
* キーワードパフォーマンスの向上
狙ったキーワードのパフォーマンスが徐々に向上しました。
例として、「移動履歴」というキーワードは圏外だったのが、11月に記事を作成し現在の平均順位は 46位 まであがりました。
ランキングについては日々変化するため一喜一憂せず見守りたいと思います。
* リリースプロセスの最適化
リリーストレインを用いることで、関係各所とのコミュニケーションを最小限に抑え、リリースのリズムを保てるようになりました。



## まとめ
この記事では、SEO対策の一環として実施した取り組みとその成果についてご紹介しました。リード増加という目標に向けて、何から始めたら良いかわからない方や、少人数でもコンテンツ制作をまわしていかなければならない方々にとって少しでも役立つ情報を提供できれば幸いです。


明日は @B-SKY-Lab さんの記事です。お楽しみに〜！
トランスポートネットワークとは

こんにちは！Assieです。
今日はあまりまとまった資料とか記事をみたことないなぁと思ったのでトランスポートネットワークについて書こうと思います。

トランスポートワークとは、その名の通りノードとノードをつないで通信トラフィックを伝搬するネットワークだと思っています。
RANなどでは3GPP、ETSI等で全体像が決められていますが、
トランスポートは様々な技術が使われていたり、つなぐノード側も進化するので、
とてつもなくバラバラしていて全体像はつかみづらいかなと思います。

そもそも通信ネットワークは例えば以下のようにいくつか種類があって、
それぞれつなぐトランスポートネットワークの感じは少し変わってきます。
・モバイルネットワーク
・ブロードバンドネットワーク
・衛星ネットワーク
・ケーブルテレビネットワーク

ちなみに日本はモバイルと固定は完全に分離していますが（NTTドコモとNTT東西のような形)、ほとんどの国は同じ事業者が提供しているケースが多いので、
モバイルと固定のトランスポートネットワークをまとめて考える形も多いかなと思います。
アクセス部分だけがNodeBか、OLT&ONUか、はたまたEnterprise CPEかでバックボーンは共有でVLANIDでわけるみたいな。
ここが一つモバイルのオーケストレーションを考える時にネックで、
モバイルはモバイル内のことを考えるけど、固定まで含めた通信ネットワーク全体の最適化を考えないとトランスポートネットワーク全体としては最適にならないなぁと思ったり。

で、トランスポートネットワークにはどういった技術があるかですが、下のレイヤーから言って、以下3つあたりでしょうか。
1. Optical Transport NW (L2) 
2. Microwave Transport NW (L2)
3. IP Transport NW (L3)

1.Optical Transport NW 
光ネットワークは、光通信使ってたら何でも入るきらいがあるのですが、
PON、OTN＆WDMあたりです。(昔はSDHとかもありましたが)
宇宙での光通信も話題ですね。

2.Microwave Transport NW 
無線長距離ネットワークであるマイクロ波通信は、設置が簡単なので地理条件が難しいところに使いますが、やはり光通信よりも速度が落ちてしまうので、徐々に光通信へと置き換わっています。
一方で完全になくなるかというとそういう見込みでもないらしく、
ジャングルのNWだったり、山間部のネットワーク等々一定量は残り見込みだそう。

3.IP Transport NW
IPルータですね。BNGやCGN等のサービス機能も含めてです。
ここは馴染みがある方も多そうなので説明不要？

では、Transportに関する標準はどのあたりなのでしょうか。
自分がチラチラみているのはこのあたりです。

・IETF：Transport NW主戦場。Optical, Micrwave, IP全部に関してプロトコルからオーケストレーション等々まで広い。
・ITU-T: こちらも主戦場。一番見ているのは時刻同期系とかちょっとニッチどころかもだけれど、ここにきてIOWNが楽しみ。
・ETSI：特にNFV周りの動き。F5Gがちょっと前に仕様が出てきたのもぼちぼち見ている。
・3GPP：直接Transportの要件が出てくることは少なめだけど、つなぐMobile NW全体の動向は抑えたいので見てます。 
・BBF: BNG周りやDevice Managementまわりが多いか？
・MEF：Enterprise CPE・NaaSまわり。
・TM Forum: 基本OSS&BSS中心なので、E2E OrchastratorからのControlまわり。
・OIF：Optical Networkの流れを見てますが、特に400ZR、800ZRまわり等Pluggableが最近元気
・Linux Foundation: ONFでSDNまわり(特にPON)、P4とか見てたのだけど、LFに移動。正直プロジェクトが多すぎて見切れないのだけど、ONAPとかが王道？
・ORAN Alliance: Fronthaul周りの要件。
・TIP: OOPT, Open TransportでDisaggregation周りのIP・Opticalの動き。

あとトランスポートかは？？だけど、IEEEの802.xx系もWiFIの動きで見てます。

中身ある話かわからないですが、こんな感じがTransport NWかなと思います。
次Slicingの話に行きます。
モゲマイクロ対策をマグネット接続方式のMicroUSBケーブルで

毎度、ググっても出てこない小ネタを取り扱っております。
本記事は個人的な見解であり、筆者の所属するいかなる団体にも関係ございません。

# 0. はじめに

今年の初めにErgoArrowsという分離型キーボードを導入しました。
(導入記については以下の記事を参照)

[分離型キーボードを導入した件について \#Keyboard \- Qiita](https://qiita.com/ynott/items/0abb7ff575c6ec01e5f7)

[ErgoArrows](https://shop.yushakobo.jp/products/ergoarrows)は、自作キーボードです(組み立ては遊舎工房さんに依頼したのであまり自作はしていませんが)。こういった自作キーボードには[Pro Micro](https://shop.yushakobo.jp/products/21?_pos=2&_sid=1ea2ac062&_ss=r)という、Arduino互換の小型マイクロコントローラボードが使われています。以下のようなものです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/990e5155-b0a1-c469-7bb0-03cb408340d2.png)

分離型キーボードには、右手側と左手側で2つのPro Microが使われています。しかし、こいつはMicroUSBのコネクタが基盤から表に外れやすく以下の写真の右のようにMicroUSBのコネクタだけ千切れてしまう事がよくあります。
こういうのをモゲマイクロといいます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/5679cd06-f68e-5b14-3f10-fba713384906.png)

右側がもげたので、ずっと左側のPro Microに接続して使っていましたが、こちらもとうとうやられてしまい、キー入力がチャタリングを始めたので、Pro Microを交換することにしました。交換するだけではまた同様にモゲマイクロになると嫌なので、マグネット接続のMicro USBケーブルに交換してみました。

という話になります。

# 1. 新しいPro Microを用意

遊舎工房さんでコンスルーピン付きの新しいPro Microを2つ購入しました。

[Pro Micro （コンスルー付き）](https://shop.yushakobo.jp/products/21?_pos=2&_sid=1ea2ac062&_ss=r)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/9f32903f-2ab5-4e78-b6d7-7ccb46ce6dd0.png)

通常はコンスルーピンをPro Microに半田付けしますが面倒なのでコンスルーピンを刺して、さらにスルーピンの長い方をニッパーで切り落としてコンスルーピンの脇に差し込みました。

# 2. マグネット接続MicroUSBケーブル

モゲマイクロになる理由は簡単で、Pro Microのコネクタに力がかかるのでコネクタの半田付け部分が剥がれてしまいます。逆に言えばコネクタに力がかからなければ問題ありません。そこで、MicroUSBコネクタとケーブル部分が分離するケーブルを購入することにしました。

5端子版を購入しました。
[Amazon\.co\.jp: マグネット\-充電ケーブル 7ピン 3A急速充電\+データ通信 2M\+2M Type\-C\-充電ケーブル 充電コード 2本セット 540度回転 磁石 Type\-C \+ USB\-B ケーブル 片手操作 ブルーシルバー HYDOOD : パソコン・周辺機器](https://www.amazon.co.jp/dp/B0B14YDK8Z/)

マグネット接続 MicroUSBを分離した状態
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/bbf16385-8fb3-32e8-d689-0c5ba85ca3e3.png)

マグネット接続 MicroUSBを接続した状態
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/86021775-a6ea-e51e-dc7f-a989c455fbfc.png)

マグネット接続 MicroUSBをPro Microに繋げた状態
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/8f829a3b-0996-76fe-50c7-c72199d82167.png)

上から見た
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/9243fc77-9eab-67d8-1553-cc25adbdeb8c.png)
根元まで刺さっていませんが、これぐらいの方が基盤にかぶらなくて良いので問題ありません。

Pro Microを刺した状態
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/654fc4ac-3702-71e1-5c97-0dd7024d98a2.png)

# 2. 結論

快適です。
力がかかると自動的にマグネットで外れますし、付けたり外したりも楽々です。
問題としては、MicroUSBコネクタ側を外すのにちょっと力がいりますが、基本的に刺しっぱなしですし、問題ありません。
時々、マグネット接続部分の接続不良でキーボードが効かなかったりしますが、少し回してあげるとすぐに直ります。接点復活剤などを振りかけておいたり、カーワックスで磨いておくと良いでしょう。
【ロバストPythonを読んた感想】ロバストなコードをささえる機能は言語を超えた共通点がある

# はじめに

今年発売されたPythonの本で、よかったと思った本です。

https://www.oreilly.co.jp/books/9784814400171/

この本は、ロバストなコードを書くにはどうしたらいいか。Pythonに最近導入された機能も含めて説明されています。[Clean Code アジャイルソフトウェア達人](https://asciidwango.jp/post/171118672245/clean-code)も本文で引用されている部分があり、クリーンコードについても学べます。

Python2のころからPythonは使用していますが、Python3.3くらいの知識で止まっていたので、Python固有の知識を得る事ができました。
特に、データクラスやABC（抽象基底クラス）は、必見だとおもいました。

この二点をおさらいしてみます。

# データークラス

[データークラス](https://docs.python.org/ja/3/library/dataclasses.html?highlight=class#module-dataclasses)は、3.7で導入されました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/532235/f65e77f9-7b44-ad3f-e752-82282fcc08a7.png)

Pythonでは基本的にClassを作っていろいろなデータ構造を表します。このDataClassが登場するまでは、ユーザ定義の型が必要な場合は、Classを作って__init__()に値をself.xxxにコピーするコードを書く必要がありました。これが簡略化され書きやすくなりました。

データークラスはデコレータとして実装されていていています。
classを使って記述しますが、データークラスとクラスの目的には違いがあります。

- データクラスは単にデータを保存する事が目的
- クラスは、データの一貫性を担保必要があるデータを保持する事が目的

ロバストPythonでの説明も9章のデータクラスの説明があり、そのあと10章クラスの説明になっています。

# インターフェース

Python 3.6で、abc(抽象基底クラス)が導入されました。これを使ってInterfaceの定義ができるようになりました。
継承を使わなくても（継承の関係がないクラス同士でも）Interfaceの定義ができます。

## 継承は不要

オブジェクト指向の言語では、基底クラスを作って継承したクラスを作る方法で同じメソットをもつクラスをつくり、共通の使い方をするような使い方が基本的な使い方の一つだったとおもいます。
しかし、[達人プログラマー　31 インヘリタンス(相続)税](https://www.ohmsha.co.jp/book/9784274226298/)で使ってはいけないと書かれています。
abc(抽象基底クラス)が3.7で追加されたのも継承の問題点を補う為だと思いました。

継承を使う必要はなくなります。

# Elixirとの比較

Elixirは2014年にリリースされた比較的新しい言語です。
関数型言語で、オブジェクト指向ではないので、Pythonの機能と単純には比較できませんが、データクラスやInterfaceに当たるもがあります。

## struct

defstructを使って、ユーザ独自のデータ構造を定義できます。これは、Pythonのdataclassと同じようなものだと思います。
module毎に定義できます。
moduleには、関数も定義することができ、selfのないclassみたいな感じです。

```Elixir:defstructの例
defmodule User do
  defstruct name: nil, age: nil

  def print(user) do
    IO.puts("name=#{user.name} age=#{user.age}")
  end
end
```

使い方

```Elixir
iex(1)> mydata = %User{name: "taro", age: 30}
%User{name: "taro", age: 30}
iex(2)> User.print(mydata)
name=taro age=30
:ok
iex(3)>
```

## protocol

Elixirでは、モジュールに共通のインターフェースを持たせたい場合、protocolを使います。
Pythonのabc(抽象基底クラス)のような役割です。
詳しい説明は、[elixirschool.com](https://elixirschool.com/ja/lessons/advanced/protocols)などを参照してください。
親子関係のないmodule同士で、使う事ができます。

## classにあたるものは？

Pythonの場合、Classを定義してデータと操作する関数を書きます。
Elixirの場合は、オブジェクト指向ではないので、classはありません。
しかし、データと関数の管理を手助けをする仕組みがあります。

- moduleには構造体と関数を書けるので、moduleにまとめる事ができる。
- パターンマッチによりデータの型と実行する関数を紐づけることができる。

このような仕組みがあるので、ElixirでのプログラミングでClassが無くて困ったということはありません。

# ロバストなコードの追求

3.6,3.7でプログラミングコミュニティが進めてきたPythonの追加機能は、Elixirとも共通点をもったものでした。ロバストなコードに必要な機能は、共通があるのだと感じました。

使用するプログラミング言語は、いろいろな要件に依存するので選べない場合も多いですが、このように、言語を超えた、ロバストなコードに対する考えを身に着け、それぞれの言語で活用する事が大切かと思いました。

Pythonを使っている方も、他の言語の言語を学んでみると共通点がわかり勉強になると思います。
Elixirは学びやすく、応用範囲も広いのでお勧めです。
Rails7.1から使えるErrorReporterに見るRailsの思想

# はじめに
本記事は錆びかけたRailsの知識を頑張ってアップデートするアドベントカレンダー23日目です。

今回は、Rails7.1から使えるようになった例外(エラー通知)について紹介します。

この機能もすごくRailsらしい機能だな、と思ったのでそこから考えたことを軽く書きました。

# ErrorReporterについて

Rubyでのこれまでの例外処理といえば、以下のように書くのでした。

```ruby:過去の例外処理
begin
  // エラーが発生するかもしれないなんらかの処理
rescue SomethingIsBroken => error
  MyErrorReportingService.notify(error)
end
```

これが、Rails7.1からは、以下のように書けるということです。

```ruby:Rails7.1以降
Rails.error.handle(SomethingIsBroken) do
  // エラーが発生するかもしれないなんらかの処理
end
```

`MyErrorReportingService.notify(error)`はどこに行ったのかというと、以下のようにinitializerの処理として書いておけます。

```ruby:config/initializers/error_subscriber.rb
class ErrorSubscriber
  def report(error, handled:, severity:, context:, source: nil)
    MyErrorReportingService.report_error(error, context: context, handled: handled, level: severity)
  end
end
```

ErrorReporterの詳細については、Railsガイドの該当ページをご覧ください。

https://railsguides.jp/error_reporting.html

# Rails(など)における省略記法のトレードオフ

今回のErrorReporterの導入は、直感的に「例外処理がスッキリわかりやすくなったな」と感じました。これまでコードの各所に書いてあった`MyErrorReportingService.notify(error)`みたいな通知の記述を共通化できるためです。

一方で、パッとコードを見た人は何をやっているのかわからないでしょう。

Railsの良いところでもあり悪いところでもある(というかトレードオフ)、省略記法に似たにおいを感じたのです。

```erb:index.html.erb
<%= render @cats %>
```

```erb:_cat.html.erb
<div>
  <p><%= cat.name %></p>
  <!-- 他の猫の詳細情報を表示する -->
</div>
```

初見の人は、「一体何が起きているんだ・・・？！」となるでしょう。

このindex.html.erbを省略せずに書くと以下のようになります。

```erb:index.html.erb
<%= render partial: 'cat', collection: @cats, as: :cat %>
```

まだわかりづらいところもありますが、`partial`で部分テンプレートを指定し、`collection`で配列を渡して、`as`で部分テンプレート内の変数を決めている、と言われれば納得できる人も出てくるでしょう。

さらにわかりやすくするなら、`@cats`コレクションを繰り返し、逐一catをレンダリングするようにもできます。

```erb:index.html.erb
<% @cats.each do |cat| %>
  <%= render 'cat', cat: cat %>
<% end %>
```

このような説明を経て、ようやく最初の`<%= render @cats %>`というシンプルな表記にたどり着けます。

このように、省略記法は短く書けて生産性が上がる代わりに初見の人にとってわかりづらい(学習コストが高い)というトレードオフがあります。

# どのように対応するか
チームに招けるメンバーのレベルや教育の質を鑑み、先を見越してコーディングの方針を決めておく必要があります。

Rails7系から活発に使われるようになってきているhotWireでも同じような省略記法が使えますね。

わかりづらいからという理由で省略記法を敬遠するとなるとコード量が増えます。基本的には、さまざまな場面で生まれるこのような記法の揺れが起こらないよう、ガイドラインを作るべきです。
Terraformメモ


## はじめに
インフラのコード化とかよく聞くが、実際に使っているわけではないのでよくわからない、インフラのコード記載でどこまでできるのかいまいちわからない、自動化という点でdockerとの違いは何なのか、曖昧だったのが大体わかるようになったのでそのメモ。

## できることを具体的に
例えばAWSでEC2インスタンスを作って何か表示させるのを自動化することは可能。
※AWSでWebページを表示したいならばその箇所の知識は必要。

### Terraform設定例

#### 1. プロバイダの設定
```hcl
provider "aws" {
  region = "us-west-2"  // ここに適切なリージョンを指定
}
```

#### 2. セキュリティグループの設定

HTTP (ポート80) とSSH (ポート22) が開く。

```hcl
resource "aws_security_group" "laravel_sg" {
  name        = "laravel_sg"
  description = "Security group for Laravel application"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
```

#### 3. EC2インスタンスの設定

Amazon Linux 2 AMIを使用して、Apache HTTPサーバーをインストールし、簡単なHTMLページを表示するためのuser_dataスクリプトの例。

```hcl
resource "aws_instance" "web_instance" {
  ami           = "ami-xxxxxxxxxxxxxxxxx"  // 適切なAMI IDを指定
  instance_type = "t2.micro"  // インスタンスタイプを指定

  security_groups = [aws_security_group.web_sg.name]

  user_data = <<-EOF
                #!/bin/bash
                sudo yum update -y
                sudo yum install -y httpd
                sudo systemctl start httpd
                sudo systemctl enable httpd
                echo '<html><h1>Hello, World!</h1><p>This is a test page.</p></html>' | sudo tee /var/www/html/index.html
                EOF

  tags = {
    Name = "WebServerInstance"
  }
}

```

#### 4. Terraformの実行

- Terraformを初期化します：

  ```bash
  terraform init
  ```

- プランを作成し、どのようなリソースが作成されるかを確認します：

  ```bash
  terraform plan
  ```

- リソースをデプロイします：

  ```bash
  terraform apply
  ```

### 上記設定記載確認方法
例えばAWSのプロバイダを使用して記載したい場合、terraform AWS providerで、以下を検索し、設定等行う。

https://registry.terraform.io/providers/hashicorp/aws/latest/docs

### まとめ
TerraformでAWSを使用するとEC2作成までをコード化できる。
よって何度も手動でもう一度作る必要はなくなる。

### dockerとの違い
以下で棲み分けは大体ピンとくるようになった。
・Terraform:インフラストラクチャのプロビジョニングを担う
・Docker:アプリケーションのコンテナー化を担う

### おわりに
きっかけは掴んだ、あとは実際に構築していく。
情報や最初のとっつきにくさに惑わされたりはもうしない。

## 参考記事

https://www.ntt-tx.co.jp/column/iac/230815/

https://www.lac.co.jp/lacwatch/service/20200903_002270.html

terafform aws providerとかで
https://registry.terraform.io/providers/hashicorp/aws/latest/docs
numpyで重複有配列のrankを計算する方法

配列に対して，各要素のrankingを求めたいとします．
ただし，引き分けがあった場合は，同順位として，次の順位は前の順位+1から再開するものとします．
例えば，`[1,1,2,2,3]`という配列の順位は`[0,0,1,1,2]`というように得たいものとします．
そのような計算は実は`np.unique`で得ることができます．

```python
import numpy as np

A = [1, 1, 2, 2, 3]
_, ranks = np.unique(A, return_inverse=True)
print(ranks)
>>> [0, 0, 1, 1, 2]
```
XCodeでAppleWatchアプリを実機テストする方法

この記事は、XcodeでWatchOSアプリを開発するときの実機デバッグついて少し手間取ったので、まとめています。
（本当はAppleWatchアプリ作ったよ！という記事を書きたかったけど、それは今度に...)

本記事の検証条件は以下の通り(条件が違うために手間取ったので...)

| 対象 | バージョン |
|:-----|:----|
| macOS | Sonoma 14.0 |
| Xcode | 15.1 |
| iOS | 17.2.1 |
| WatchOS | 10.2 |

ちなみに、アプリは事前に作成しているものとします。

## 【前提】デベロッパモードについて
- iOS16、watchOS9から、AppStore公開前のアプリを実機で動かすための**デベロッパモード**という機能が実装された
- 「設定」アプリの「プライバシーとセキュリティ」から「デベロッパモード」を選択し、有効にすることでXCode上でシミュレータとして選択できるようになり、実機でのデバッグができる

## 【問題】「プライバシーとセキュリティ」に「デベロッパモード」が存在しない
デベロッパモードを有効にしないと、XCode上でシミュレータとして選択できない。これは困った。

## 【結論】Apple Watchと接続されたiPhoneをケーブルでMacに接続する
iOS17やwatchOS10から、セキュリティ面を考慮して「開発者でないとデベロッパモードを有効にできない」仕様になったため、開発者であることを認知させる手順が必要ということ。

以下の手順を踏めば、無事Apple Watchを実機デバッグできることがわかった。
結構手間だけど、1回シミュレータとして登録できれば次回からはデベロッパモードの有効だけでOK。

1. Mac、iPhone、Apple WatchのOSを最新化する
1. iPhoneをMacにケーブルで接続した上で「信頼する」を選択
1. iPhoneの「設定」アプリにて「プライバシーとセキュリティ」から「デベロッパモード」を選択し、有効にする(ペアリング後はWi-Fi接続が可能)
1. iPhoneを再起動する
1. Xcode上でiPhoneをシミュレータとして登録する
1. Mac、Apple Watchを同じWi-Fiに接続する
1. Apple Watchで「信頼する」を選択
1. Apple Watchの「設定」アプリで「プライバシーとセキュリティ」から「デベロッパモード」を選択し、有効にする
1. Xcode上でApple Watchをシミュレータとして登録する

## 【アプローチ】どのように取り組んだか
こっからは調べたことを記録として残しておきます。

### とりあえず公式ドキュメント(英語)をググる

https://developer.apple.com/documentation/xcode/running-your-app-in-simulator-or-on-a-device

ふむふむ、iPhoneをシミュレータとして登録(ペアリング)する際は、ケーブルを通してペアリングをしないといけない模様。
2回目以降は同一Wi-Fiでデベロッパモードになっていればケーブルがなくても実機検証できるとのこと。

またwatchOSの場合は、iOSが17以降であれば、XcodeとiPhoneがペアリングされていれば同一Wi-FiでApple Watchのペアリングもできるとのこと。

ということまでわかったので、試してみる。

ケーブルをMacに挿してiPhoneを再起動したら無事iPhoneにデベロッパモードが表示された。

![IMG_B22725A991F2-1.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3572911/3b6f07b7-c767-adfb-272b-39a4d7806afd.jpeg)

しかし、Apple Watchに一向にデベロッパモードが表示されない。

![incoming-DE5CC7F8-A174-4A76-A263-99C88CD693FB.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3572911/7ec504cd-9088-23e3-0e41-8e66a399edef.png)

- Apple Watch上で「Macを信頼する」は選択済
- iPhoneはXcodeにペアリング済
- Mac、iPhone、Apple Watchはすべて同一Wi-Fiに接続済

一応Apple Watchを再起動したものの，結果は変わらず。。

> 現在対応方針検討中...(なんとか24日中に解決したい...)

# 参考

https://umikazeken.hatenablog.com/entry/2023/05/02/000051
創業者CTOがシリーズAに至るまでやるべきこと＆やらなくて良いこと

ついに、Hubble Advent Calender 最終日を迎えました！
毎日一緒に仕事をしている仲間でも、こうやって記事として改めてみてみると、その力強さに尊敬の念が再燃します。最後に、創業期からこのような素晴らしいエンジニアの皆様と出会う過程の中で感じた、僕の経験談を共有したいと思います！

スタートアップの一人目のエンジニアとして、とりあえずガリガリコードを書いてプロダクトを作っていくことが最優先事項である一方、やはり創業メンバーとして要求されることは多岐にわたります。少ないリソースの中で選択と集中は必須であり、何に重点を置いておくと良いか、僕個人の経験で振り返ってみました。やらなくて良い、と少し過激な発言をしましたが、やるに越したことはないが後で仲間が増えていったときに挽回できる、という意味と捉えてください。あくまでも僕個人の感想なので、事業内容や社内カルチャーによっては全く違う意見もあるとは思います。

# やるべきこと
>## テストを書く & ドキュメントを残す
まず後続で参画してくださるエンジニアに”開発の安心感”を与えられるかが重要かと思います。テストがない、ドキュメントがない会社はそれだけで不安要素を与えてしまいます。テストやWikiの重要性はおそらくほとんどのエンジニアが理解している一方、スタートアップとして変わりゆく仕様に対して随時更新していくのは簡単なことではありません。優先度を意識して社内カルチャーとして啓蒙しておくことは大事かと思います。

>## リファクタの重要性をチーム内に植え付ける

これは開発というより組織的なお話です。エンジニアはリファクタリングの重要性は理解している一方、ビジネスサイドはどうしてもリファクタリングの重要性に気づきません。理解のあるビジネスサイドの方でも、エンジニアが言うから必要なんだろう。。。という程度かと思います。この辺りFindyさんの記事がわかりやすく説明されていたので、リファクタリングの重要性の啓蒙活動を行っておくことは、CTOの役目かと思います。

https://speakerdeck.com/mtx2s/internal-quality-issues-caused-by-organizational-design

> ## 交通整備

仕様以外に後続エンジニアが気になる点は開発におけるルールです。リリースフローはどうなっている？修正はどこからブランチを生やして作業すれば良い？レビュー、動作確認は誰に頼めば良い？等はまとめておくと、毎回説明する手間が省けます。HubbleではNotionに誰でも何でも書いて良い文化と、修正依頼等はForm経由での依頼にしており、依頼から反映までルールを明確にして運用しています。

# やらなくて良いこと(後回しでも助けてもらえる！！)

>## コードは汚くても良い

少し語弊を与える可能性もありますが、未来が予想しづらい初期フェーズでは、再利用可能かつメンテ性に優れたコードを書いておくのは難しいこともあると思います。もちろん綺麗なコードを書くのに越したことはないですが、逆に捉えると後続で参加してくださるエンジニアもメンテ性の高いコードを書きたいと思ってくれる人がほとんどです。（リファクタ好きは結構多い）テストをしっかりと書いておけば、リファクタも安心して取り組めるので、リファクタの重要性をチームに啓蒙し、その時間を確保しておけば、後続エンジニアが手助けしてくれます。

>## 凝ったインフラ

CTOとして、最新技術をできるだけ取り入れて魅力のある開発組織にしたい、とは誰しもが思うでしょう。DDDをベースに、マイクロサービス、GraphQLを採用し、Rustで高速な処理を実現、、、もちろんこれが悪いと言っているわけではないですが、できるだけシンプルにすることが大切かと思います。各フレームワークのベストプラクティスに沿って、SQLを正しく記述（Paginationを入れておく、N+1を防ぐ、、）等をしておけば、昨今のPCリソースでは全然捌けます。システム構成はビジネスドメインや事業戦略とも密接に関わってくるので、小さなうちは出来るだけシンプルな状態に保っておく方が良かったりします。
レガシーすぎるスキーム（オンプレで開発、AWS EC2にmiddlewareをマニュアルでinstall して。。。）は避けたいですが、AWSやGCP等を使用されている場合はよくあるスキームをまるっとそのまま真似して。。。程度にやっておけば良いかと思います。

>## 尖った機能

我々HubbleはSaaS事業です。過去に何度も絶対に受注したい、、この機能があれば受注できそう。みたいな案件がありました。結論から言うと、SaaS事業としては個別のカスタマイズは初期の段階では避けた方が良いです。個別にカスタマイズされた機能は、横展開ができず結果としてその後のメンテ優先度が下がり、、と上手くいかないことがほとんどだと思います。自分たちで作り出したい世界観を実現することに注力し、目先の利益にとらわれずに開発することが大事です。理解あるお客様は必ず存在します。

>## 人事

CTOの役割は人材採用と言っても過言ではありません。ただほとんどのエンジニアが人材採用は無経験かと思います。ここで言いたいのは人事は不必要というわけではなく、人事専門の方には敵いません。スタートアップでは人事を早めに採用しろ、とはまさにこのことで、人事担当を採用すると、採用周り、労務、評価制度、組織構成、等一気に会社らしくなります。CTOとしてはまずプロダクトの力で会社を成長させ、早めに人事担当を採用することを勧めます。


# まとめ

会社、組織は一人で立ち上げることはできません。仲間集めが最も重要な仕事であり、「その仲間に安心感と期待感を与え、如何に早くオンボーディングできるか」を意識しながら、誇れる組織を作っていくと良いと思います！
画像の補間方法

## アップスケーリング時の画像補間方法
深層学習を使ったメーカー研究員 ももてぃ（仮）です:cherry_blossom:
深層学習を使って前処理をする際に画像の情報量を増やす機会があったので、基本的なことですがアップスケーリングの補間方法についてまとめました。

そもそもは、CNNで学習する画像をアップスケーリングして情報量を擬似的に増やして性能向上に繋がるかどうか？を知りたかったのですが。
擬似的に解像度を上げてもあくまで補間しているだけなので、結果は変わらないのか？
画像の解像度が擬似的に向上し、性能が良くなるのか？
結果がわかったらまた共有します。
ご意見あれば是非欲しいです:relaxed:


### 1. この記事を読んで得られること
・OpenCVで実装できるアップスケーリングの補間方法の原理がわかる。

### 2. アップスケーリング方法

以下のテストコードを実行しました。
```
image = cv2.imread(input_image_path)
# アップスケールの倍率とメソッド
scale_factor = 4
methods = [cv2.INTER_NEAREST, cv2.INTER_LINEAR, cv2.INTER_CUBIC, cv2.INTER_AREA, cv2.INTER_LANCZOS4]

# 出力ディレクトリの作成
os.makedirs(output_dir, exist_ok=True)

# 各メソッドで画像をアップスケールして保存
for method in methods:
    print(method)
    upscaled_image = cv2.resize(image, None, fx=scale_factor, fy=scale_factor, interpolation=method)
    output_path = os.path.join(output_dir, f"upscaled_method_{method}.jpg")
    cv2.imwrite(output_path, upscaled_image)

print("アップスケールが完了しました。")
```
ちなみに、methodの中の数字は以下のようになっています。
cv2.INTER_NEAREST：0
cv2.INTER_LINEAR：1
cv2.INTER_CUBIC：2
cv2.INTER_AREA：3
cv2.INTER_LANCZOS4：4

###### 最近傍補間
![upscaled_method_0.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3650630/7371ffc0-bac8-5dfb-2c95-5d53f5b16062.jpeg)
最も単純な補間方法で、近くのピクセルの値をそのまま使用しています。そのため拡大するとカクカクした画像になっていますね。
これだと情報量は増えていなさそう。。

###### バイリニア補間
![upscaled_method_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3650630/495109e7-5099-0b70-8606-bd405f011714.jpeg)
近くの2×2のピクセルの値を使用して線形補間を行う。
標準的な補間方法としてよく使用される方法。

###### バイキュービック補間
![upscaled_method_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3650630/4aa02f6d-363b-4ad4-f43d-8bdca9a9399b.jpeg)
双線形補間よりも滑らかな結果が得られるが、計算に時間がかかる。
バイリニアと比べて、パッと見の違いはわかりません。

###### エリア補間
![upscaled_method_3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3650630/1ffa4ead-b510-69ce-690f-8b6934d17335.jpeg)
近く4×4個のピクセルの値を使用して補間する。
ピクセルの集合を平均して補間を行います。
縮小時に用いると、ノイズの影響を抑えることができますが、拡大時には適していません。

###### ランチョス補間
![upscaled_method_4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3650630/6a8b2a68-bab3-5a85-ec42-636b972ccbf4.jpeg)
サンプリングウィンドウを使用して補間を行います。
高い品質を提供しますが、計算が他の方法よりもコストがかかります。
[sentry] monitoring 404


# はじめに

Next.js に Sentry を入れた際、captureException などで /monitoring?xxx へのリクエストが飛びます。
このリクエストが 404 エラーになってしまったので、その原因と対応をまとめます。

# 要約

next.config.js の tunnelRoute の path を見直すことで解決しました。

# 前提

Next.js: @13 App Router
sentry/next.js: @7.77
Next.js の basePath や rewrite などでアクセスする path をいじっている

# 詳細

## 1. sentry の初期設定を wizard で行った場合はデフォルトで tunnel が設定される

```bash
npx @sentry/wizard@latest -i nextjs
```

https://docs.sentry.io/platforms/javascript/guides/nextjs/

next.config.js に sentry の設定が生成される.
ちなみに tunnelRoute を設定すると 直接 Sentry に飛ばすのではなく、自前のサーバーを経由して Sentry にログを飛ばすことができる。これをすることによって AdBlocker などでサードパーティへのリクエストがブロックされることを回避できる。

fyi: https://docs.sentry.io/platforms/javascript/guides/nextjs/troubleshooting/?original_referrer=https%3A%2F%2Fwww.google.com%2F#dealing-with-ad-blockers

```next.config.js
// ...
module.exports = withSentryConfig(
  module.exports,
  {
    // For all available options, see:
    // https://github.com/getsentry/sentry-webpack-plugin#options

    // Suppresses source map uploading logs during build
    silent: false,
    authToken: process.env.SENTRY_AUTH_TOKEN,
    org: '<org>',
    project: '<project>',
  },
  {
    // For all available options, see:
    // https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/

    // Upload a larger set of source maps for prettier stack traces (increases build time)
    widenClientFileUpload: true,

    // Transpiles SDK to be compatible with IE11 (increases bundle size)
    transpileClientSDK: true,

    // Routes browser requests to Sentry through a Next.js rewrite to circumvent ad-blockers (increases server load)
    tunnelRoute: '/monitoring',

    // Hides source maps from generated client bundles
    hideSourceMaps: true,

    // Automatically tree-shake Sentry logger statements to reduce bundle size
    disableLogger: true,
  }
)
```

## 2. /monitoring へのリクエストが 404 になる

今回は tunnelRoute が自動で設定されたので、sentry の captureException などでエラーを捕捉しようとすると、monitoring へのリクエストが飛ぶ。

この時、/monitoring へのリクエストが 404 になってしまう。

## 3. 原因

Next.js へのアクセスを reverse proxy 経由でアクセスしており、実際の path は /reverse/XXX のように `/reverse`がつくようになっていた。

そのため、tunnelRoute の設定を`/monitoring`から`/reverse/monitoring`へ変更することで無事に sentry へロギングできるようになった。

# まとめ

1. sentry の初期設定を wizard で行った場合はデフォルトで tunnel が設定される
2. tunnelRoute は /monitoring に設定され、sentry の captureException などでエラーを捕捉しようとすると、monitoring へのリクエストが飛ぶ。
3. 404 になる場合は、tunnelRoute の path を見直すことで解決する。

# 参考文献

- [公式 tunnel について](https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/)
- [base path の issue](https://github.com/getsentry/sentry-javascript/issues/8293)
使用してるConsole

デバッグで使用するのに便利なconsole〜です。私がよく使用しているものををまとめる。

```js
console.log('おはよう！');
console.info('こんにちは！');
console.warn('警告！');
console.error('エラーです！');
console.clear(); // ログを消去します！
```
上のコンソール関数はどれも似たような動作をします。warnや、errorはエラーを知らせたい時、clearは、これまでのコンソールをクリアします。

```js
const table = { Num: 123 }
console.table(table);

for (let i = 0; i <= 2; i++) {
  console.count();
}
console.countReset();
```

tableは配列やオブジェクトを表形式で出力し、まとめて表示することができます。
countは受け取った文字列をログに記録し、この文字列を使って呼び出された回数を出力します。何も指定しない場合、defaultが表示されます。countResetを呼べば、countのカウンタをリセットします。


#### 参考
https://www.amazon.co.jp/JavaScript-%E7%AC%AC7%E7%89%88-David-Flanagan/dp/4873119707/ref=pd_sbs_d_sccl_3_1/358-8138093-3473600?pd_rd_w=pN7gB&content-id=amzn1.sym.e146c92a-7981-4c58-8351-e2a023395915&pf_rd_p=e146c92a-7981-4c58-8351-e2a023395915&pf_rd_r=WBE913K7Y0QTM70WYJ1Y&pd_rd_wg=1dr2h&pd_rd_r=9c0d52a1-ffe2-457d-ac49-c1b33b9d6789&pd_rd_i=4873119707&psc=1
OpenCV Advent Calendar 2023まとめ

2023年も、OpenCV Advent Calendarを寄稿者・読者としてお楽しみいただき、ありがとうございました！
=======================================================================================
今年も無事に、OpenCV Advent Calendarは25日間、完走することができました！ありがとうございました！

さて、昨年などであればここでOpenCV 4.9.0 Releaseというニュースがありまして、さてその紹介記事をさくっと書こうかとも思いましたが（えっと私が書いているパッチでリリース止まっている？）


■ 今年の投稿は、こんな感じの傾向でした
==================================

今年の投稿は、ざっくりこんな傾向となっていました。

DNNやfloat16など、流行している話題がしっかり含まれていて読み応えのある一か月間でした！

また、いくつかの機能紹介で、あまり慣れ親しんでいない機能も知る機会になったと思います。

投稿いただきました、ありがとうございました！

| ジャンル | 件数 | 投稿日 |
|:-:|:-:|:-:|
| 開発環境  | 4 | 4,14,17,23 |
| 動作環境  | 1 | 5 |
| 性能検証  | 2 | 6,18 |
| 計算精度  | 2 | 7,20 |
| 計算理論 | 3 | 1,2,22,24 |
| Tips | 1 | 19 |
| 機能紹介(DNN,float16) | 6 | 9,12,13,15,16,21 |
| 機能紹介(その他) | 6 | 8,10,11,21, (2nd)22, 24 |
| その他  | 3 | 3,25,(2nd)25 |

■ 話題：OpenCV 3が終焉を迎えました！
==========================
今年トピックの１つは、OpenCV 3が停止となったことだと思います。

https://github.com/opencv/opencv/wiki/ChangeLog#version3420

> version:3.4.20
> June, 2023
> 
> OpenCV 3.4.20 has been released. Bug fixes, optimizations and other enhancements are propagated into OpenCV 4.8.0. OpenCV 3.4.20 is last official release in 3.4 branch.]
> (邦訳) OpenCV 3.4.20がリリースされました。バグ修正、最適化、その他の機能強化は、OpenCV 4.8.0に伝達されました。OpenCV 3.4.20が、3.4 branchからの、最後のオフィシャルリリースになります。

OpenCV3は、2015/7リリース。その当時のChange Logを見ると、現在にも着実に引き継がれていますね（WinRT...）。

- Support Android
- Support WinRT
- intristic
- OpenCL
- NEON
- Java Binding
- IPP
- opencv_contrib repository

■そして次の音楽（OpenCV5）が始まるのです
=====================================
OpenCV5が、とうとう来年にリリースしそうですね！（クラウドファウンディングはなかなか苦戦しているようですが）

- Matでの色深度サポートの拡張
- imgprocでの文字描画のtruetypeサポート　など等

今度はどんな進化をしていくのか、今からワクワクしています！

■ おわりに
=========
OpenCV3に大きな感謝の意を示し、OpenCV4とOpenCV5に幸多からんことを願いつつ、こちらの記事にてOpenCV Advent Calendar 2023は閉幕とさせていただきたいと思います。

皆様、ありがとうございました！

（
作品：社員検索（Personnel_Search）

#概要

軽量検索アプリ。

Github: https://github.com/RistoLibera/Personnel_Search

![Capture.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/0a4c1907-52fb-7cc0-95be-b41f4f2687c1.png)


#使用技術

・Java
・Oracle Database

#機能一覧
##認証機能

![1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/11445415-ad3b-2e52-6d10-973277a697a5.png)


正しいアカウントしかログインできません。

![2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/21234f20-3a07-91a2-74b8-e2ab1ede0cfe.png)

ログイン成功し、検索へ遷移。

##検索機能

![3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/5232c927-cf43-4b5d-20b4-7317c64184e8.png)

ENTERを押す必要なしで入力するテキストによって自動的にDBで検索します。

![4.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/74d64156-47fe-6245-d250-7244027aa91c.png)

でも大文字と小文字を区別する必要があります。

![5.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/613718/611e26b5-2740-ead2-20bd-6434cf97a80e.png)

入力なしで全ての社員情報を検索することになります。

#まとめ

UI/UXはとっても苦手ですが、なんとなく出来上がりました！
くも膜下出血になったElixirプログラマー奮闘記

# いつもと違う頭痛にあう
頭が「ジュワー」とするいつもと違う感覚の頭痛になる
まだこの時点ではまだ話せたが…
# 病院に行く
その日の地元の病院に行く
この時点では「くも膜下出血」であるこを気づいてない
その次の日に大きい病院で「くも膜下出血」と診断される
本来なら救急車で運ばれもいいレベルがだ
この時点事の重大に気づいていない、親に運ばれた

# 脳の手術をする
この時の記憶がない
破裂した脳の血管にコイルのつめたことを主治医から聞いた

# 生存確率と後遺症になる確率
50％は初回の出血で死亡する
20%は手術しても後遺症が残る
30%は社会復帰できる

# 記憶が一部飛ぶ
まず、まともに話せなくなる
「失語症」である
言葉がでなくなる
はじめ、看護師さんにそってない態度をとってたことも覚えてない
手術して数日後、別人と看護師さんに言われた
体の右半分が麻痺した事も覚えてない
これは、リハビリの先生から聞いた

# リハビリを開始する
体のリハビリもしているが、こちらは結構回復してるのでリハビリ内容は省略する
### 言語（日本語）
もし、仕事に復帰するなら、話せないと困る
プログラムだけ打てれは良いとはいかない
病気発病前はZoomで半日〜１日話すこともある
これはPOと要件定義や、チームメンバーと仕様や技術相談を受けるとき必須
これはリハビリの先生も業界対する勘違いがあったので仕事を説明した

リハビリ内容は声に出して文書を読む
POからもらった本を題材や
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/ae0070c7-8356-2de7-a195-59e931c5de60.png)

チームメンバーからもらった本を題材にした
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/cbb6b5d7-1a4f-9654-edf8-b90d9c458783.png)

リハビリようの本は病院にありますが言語の先生が興味がある本を読んだほが効果てきと教えてもらい実践してます

### タイピング自習（パソコンのキーボード）
- a-zをひたすら打った
- あ-ん（ローマ入力）をひたすら打った
- iex で遊ぶ
- 比較ツールを使ってプログラム例を比較しながら練習
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/ceb9432c-92cc-ea69-a291-66d6252396a1.png)

### タイピングをリハビリの先生と
- 渡された絵を発音しながらタイピング
- リハビリの先生からの課題（IT用語）を説明し発音しながらタイピング

ポイントは発音しながらである
音がわからないと、間違えたり、打てない場合があり
この病気になる前は、体が覚えていてこのプロセスを省略してたことを認識

# 少しはプログラムは書けるようになる
上記の練習を２ヶ月練習した結果
院内で書いたプログラム

- 言語聴覚リハビリ答えあわせプログラム　〜数字、仮名ソート〜
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/a63413b6-6575-d0e4-994f-e8694dd6eb83.png)

https://qiita.com/t-yamanashi/items/8043271f90de81a316c8

- リハビリゲーム（1-25の数字を押してくゲーム）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/6b51e51f-a23a-799f-99b8-b90d51292073.png)

https://github.com/t-yamanashi/num25

https://qiita.com/t-yamanashi/items/95b5a60036b47e616d87

ここまでは復活しました

# 余談：この病気になると制限されること
運転を２年間禁止されます（発作が起きると危ないため）
趣味のドライブができないので

DJコントローラーで遊ぶ趣味を追加しました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/c4925633-6c3f-fd58-f50b-83d4eee6733d.png)
ちょうぜつ本で学ぶクリーンアーキテクチャの誤解とパッケージ原則の重要性

この記事は[ちょうぜつ本 1 周年 Advent Calendar 2023 ](https://qiita.com/advent-calendar/2023/chouzetsu-book)の24日の記事になります。

# ちょうぜつ本の推薦理由
ちょうぜつ本おすすめする理由は設計スキルを向上させ、初級者から中級者へのステップアップを目指す方々に最適な教材であるという点にあります。

設計の初学者から初級者向けには、例えば「良いコード/悪いコードで学ぶ設計入門」（通称：ミノ駆動本）のような多くの入門書が出版されています。また、アンクルボブによる「クリーン〇〇」シリーズなど、中級者以上を対象とした書籍も長く人気を集めています。

しかし、初級者が中級者へと進むための適切な教材は、これまで比較的少なかったのです。「ちょうぜつ本」は、このようなギャップを埋めるために推奨されています。本書は、現代のチーム開発に不可欠な設計原則を、中級者にも理解しやすく解説しており、初級者が既に学んだ知識を再確認し、次のレベルへの挑戦に適しています。

サンプルコードはPHPで書かれているため、PHPプログラマーには特に有用ですが、理論的な部分はPHPの経験がない方にも実践的な内容として十分に役立ちます。

この本は幅広く扱われていますが、今回は本の最初の章であるクリーンアーキテクチャとパッケージ原則について簡単に説明をします。

# クリーンアーキテクチャはレイヤーの依存性を解説している

![スクリーンショット 2023-12-20 12.39.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/46364/0d6851b9-da82-9393-667d-c494a0d88cc1.png)

クリーンアーキテクチャは、図によって広く知られるようになりましたが、このことが誤解を生んでしまった面もあります。図に示された構造を実現すること自体が重要であると誤解されていることがあります。
実際には、それよりも依存性のルールの重要性を理解することがより大切です。

ロバート・C・マーティンは、クリーンアーキテクチャの本のなかで以下のように記述しています

> 図221では、クリーンアーキテクチャの概要が示されていますが、これはあくまでも一例に過ぎません。この4つの層以外にも、必要なものが存在するかもしれません。しかし、依存性のルールは常に適用されます。ソースコードの依存性は、常に内側に向けるべきです。内側に近づくほど、抽象度と方針のレベルは高まります。外側には具体的な詳細が存在し、内側にはソフトウェアの抽象化された高位レベルの方針がカプセル化されます。最も内側は、最も一般的で高位レベルのものになります。

（引用：ロバート・C・マーティン, 角 征典, 高木 正弘, 「クリーンアーキテクチャ 4つの円だけ？」より）

レイヤーを意識した設計をする場合は図が示す4つの層―ドメインモデル、ユースケース、プレゼンテーター、インフラストラクチャ―が存在する事が多いですが、それが3つや5つとかでも問題ないと言えます。

クリーンアーキテクチャはレイヤーを意識してそのレイヤー間の依存性についてもっとも重要した考え方である。そのレイヤーは内側びドメインに関するクラスだけが存在する、一番外側はドメインとは全く関係ないDBなどが存在するという方が個人的にはあっていると思います。


# パッケージ原則で認知負荷をさげる
パッケージ原則は、特に大規模なプロジェクトで重要な役割を果たしますが、理解するのが難しい点もあります。

たとえばRailsでは、アクティブレコードのクラスは通常 app/models 直下に作成されます。しかし、中規模以上のプロジェクトではこの構造がもたらす課題も存在します。具体的には、どのファイルがどこにあるのかが分かりにくくなることや、たくさんのファイルがあるため関係しないファイルも同じディレクトリにあるため気になってしまうなどの理由によりプログラミング時の認知負荷が増大します。


このような状態を説明するのに中規模のECサイトのモデルのファイルリストを例に出します。
以下のファイルリストがパッケージを無視したディレクトリ構造です。
```
├── cart.rb
├── cart_item.rb
├── category.rb
├── category_tag.rb
├── coupon.rb
├── credit_card.rb
├── customer
├── customer.rb
├── customer_address.rb
├── customer_churn_prediction.rb
├── customer_complaint.rb
├── customer_insight.rb
├── customer_lifetime_value.rb
├── customer_order_history.rb
├── customer_preference.rb
├── customer_profile.rb
├── customer_satisfaction_metric.rb
├── customer_wishlist_analysis.rb
├── discount.rb
├── discount_rule.rb
├── inventory.rb
├── marketing_campaign.rb
├── order.rb
このようなファイルがあと15個ある
```

このように非常にわかりづらい状態になっています。


パッケージ原則に従ってパッケージを作成すると以下のようになり先程あげたプログラミング時の認知負荷を下げることができます。
![customer_only.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/46364/fb5aa4f6-a7ec-e09d-e6ab-2670611312fb.png)


この場合だとCustomerに関連するモデルを編集する際、関連ファイルのみを確認することで済むようになります。


パッケージ原則はいくつかありますが、私がパッケージ原則を理解する中で難しかった「リリース再利用等価原則」「共通再利用原則」「共通クロージャー原則」に関しては
関連する機能を同じパッケージ内にまとめ、その変更がパッケージ内で完結するように設計することで原則に従った設計ができているのではないかと思います。

パッケージ原則を用いることで、特に中規模以上のシステムを開発する際に認知負荷を軽減し、より効率的なプログラミングが可能になります。
今回は説明できませんでしたが、パッケージ原則はパッケージをいかに安定させるかの項目もありそれも中規模以上のシステムを開発する場合は重要です。
今回の説明を通じて、パッケージ原則の重要性と効果について、興味を持っていただければ幸いです。

# まとめ
今回はちょうぜつぼんの中で重要だと思った
**クリーンアーキテクチャはレイヤーの依存性を解説している** と **パッケージ原則で認知負荷**をさげるということについて説明しました。

冒頭に説明したように、今回私が説明したところ以外にもちょうぜつ本は設計等に関することを幅広く学習ができるおすすめの本です。
flutterにてENVied利用時にジェネレーターがエラーを出した時の対処法

## 概要
* FlutterにてENViedパッケージを利用しようとした際、env.g.dartの生成時エラーを吐いたのでその解決法の共有目的で書きます。
* 日本語の記事を見つけられなかったので、誰かのお役に立てれば。（Qiita初投稿なので優しく見守ってください。）

## 環境
MacBook Pro 2018,13-inch
Visual Studio Code
Flutter 3.16.5

## 起こったこと
Flutter(Dart)にてAPIキー等の秘匿化を行おうと思い、以下の記事を参考にしながらENViedパッケージの設定を進めていました。
[FlutterでのAPIキーの安全な管理](https://qiita.com/myzw1mt3/items/1543c3e1307fb89279fa)

しかし、記事の4における⑤の部分で、ジェネレーターの実行時に下記のエラーを吐きました。

```terminal:Terminal
Environment variable not found for field `key`.
package:ルートディレクトリ/env/env.dart:8:17
```

上記の参考記事の通り、env.dartは以下のように記載しています。
```dart:env.dart
import 'package:envied/envied.dart';
part 'env.g.dart';

@Envied(path: '.env')
abstract class Env {
  @EnviedField(varName: 'KEY', obfuscate: true)
  static String key = _Env.key;
}
```

エラーメッセージを見てもよくわからんのと、調べても同様の症状に悩んでる人が見つからずに格闘。

## 解決方法
色々調べた結果、以下のissueに辿り着きました。
[Environment variable not found for field" if build_runner hasn't been run without envied](https://github.com/petercinibulk/envied/issues/59)

英語を頑張って読んで要約すると、次のようなことらしいです。
* enviedコードを利用せずに一度も`buid_runner`を実行していない状態で実行するとこのエラーが出る
* 解決方法としては、一度この`env.dart`をコメントアウトしてから`buid_runner`を実行。その後再び`env.dart`を復元してから`buid_runner`を実行する

自分はENViedを利用するまでに一度も`buid_runner`を実行していなかったので、この原因だと思い試したところ解決しました。

## まとめ
同様の症状で苦しんでいる誰かの助けになれば幸いです。
【プラクティス紹介】1分でさらっと分かる「ゴールデンサークル」

![golden_circle.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3526800/0209f494-4f65-78c0-b6c5-b335c88b60bf.jpeg)


## プラクティス名（別名）
ゴールデンサークル　（Start With Why）

## プラクティスの目的・狙い
* プロダクトのコンセプトを明確化する
* 手段が目的化してしまうことを防止する

## どんな時に使うか
* そもそも「なぜつくるのか」が明確になっていない時
* 背景や意図がDEVに伝わっておらず「何をつくるのか」が迷走しそうな時

## 実施手順
1. 3つの同心円を描き、中心からWhy/How/Whatとし、それぞれが何を指すのかを説明する
1. 関係者で議論し、**Why→How→Whatの順で**明文化していく
1. Whatに基づき作成されたMVP（最初のインクリメント）からフィードバックを得る
1. 得られた知見をもとに必要に応じてWhy/Howを見直す
※スタートアップのモノづくりではWhyレベルの修正をピボットと呼ぶ

| レベル | 検討事項 | どこに書くか？（例） |
|:-:|:-:|:--|
| **Why**  | 目的・理由  | 製品ビジョン、プロダクトゴール、仮説、開発方針など  |
| **How**  | 手段・方法  | インセプションデッキ、アーキテクチャ、リリースプランなど |
| **What**  | 製品・機能  | PBL、ユーザストーリーなど（具体的な要求の記述）  |

※上記はゴールデンサークルのフレームをアジャイル開発にあてはめた場合の一例です

## アレンジ例
* 改善活動や推進活動のコンセプトをゴールデンサークルで明確化する

## アンチパターン
* Why/How/Whatをフェーズ分けしてウォーターフォール的に定義していく
→3領域は互いに影響し合うため分けて考えるより重なりを意識した方がよい

## 参考情報
ゴールデンサークル理論のTED動画（2009年サイモン・シネック氏が提唱）
https://www.youtube.com/watch?v=qp0HIF3SfI4

アジャイル開発におけるゴールデンサークルの活用方法は市谷さんの講演資料が詳しいです
エンタープライズアジャイル勉強会（2017年12月）『アジャイル開発はWhyから始まる』
https://www.slideshare.net/papanda/why-84153441

## こぼれ話（私的コメント）
ゴールデンサークル理論は「何をするか」の前に「なぜするか」を語ることによって、動機に共感してもらい、人の行動を促しやすくなるという理論です。プレゼンテーション、マーケティング、ブランディングメッセージなどの文脈で使われることが多いようですが、単なる小手先のテクニックではなく、その本質は深く、思考/伝達/行動のフレームワークとして汎用的に使うことができる考え方です。アジャイル開発の文脈では「なぜそのプロダクトをつくるのか？」を突き詰めるためのフレームワークとして活用できそうです。
僕もDEV出身なので「何をつくるか？」につい目が行きがちなのですが「なぜつくるのか？」の方がもっと大事だったりします。大抵そのことに気づくのは作ってしまった後だったりするわけですが。（泣）

　[アジャイルプラクティス一覧へ戻る](https://qiita.com/kakashi_h5/items/20584998c5ca4594b9ea)
二人三脚 Python3編

https://paiza.jp/works/mondai/array_utilization_primer/array_utilization_primer__find_pair

全く考えつかず。
小さい順にソートするとか
一番小さい数にするとか考えたけど。
結局だめだった。

5つの要素があるとして、
数学を思い出して、場合分けってどうやると考えたときに、
5つの数から最初に選び出す場合5通りある。
2回目は4通り。
だから20通りあるというのはわかったが。

たしか今までに学んだこととして、すべてのペアの組み合わせを出す方法があった。

https://paiza.jp/works/mondai/array_utilization_primer/array_utilization_primer__reduce

これに対する私の記事

https://qiita.com/Atsulabo/items/347ca18e1ccf234c42bc

これをヒントにして多重ループ文を作成。

答えはペアにさせればよいのでansで配列を作っておく。
で最初のdiffより小さいのがあればdiffとansで登録。
これでいいのかな。

```py

N = int(input())
A = [int(input()) for _ in range(N)]
ans = [None,None]
diff = abs(A[0]-A[1])
for i in range(N):
    for j in range(i + 1,N):
        if abs(A[i] - A[j]) < diff:
            diff = abs(A[i] - A[j])
            ans = [A[i], A[j]]

ans.sort()
print(*ans,sep="\n")

```
OKでした。
難しかった。。。。
30分もかかってしまった。
新しい問題をやるときは今までやった内容を復習しておこう。。。
いやあそれにしても前には考えつかなかった解法が思いつくだけでもレベルアップしてんだな〜
なかなかおもしろい
軽深演習 # 20 下手な鉄砲

### 軽深（かるしん　なんちゃって圏論） Advent Calendar 2023 20日目の記事です。

演習形式をとっているので、ぜひ　回答を試みてください。

### 前提知識　下手な鉄砲も数撃ちゃ当たる

誰も知っていることわざですね。
図式で書くと、こんな感じですね。
```mermaid
flowchart LR
A[下手な鉄砲]-->B[数撃ちゃ]-->C[当たる]
```
これも解像度の高い図式がいいですね。大雑把すぎるので左に矢印を付け加えたり、途中に足したりしましょう。
```mermaid
flowchart LR
A[該当範囲設定]-->B[全件取得]-->C[該当判定]-->D[該当抽出]
```
ちょっとちがいますが、これはsqlのselect文に似てますね。
```mermaid
flowchart LR
A[テーブルと条件指定]-->B[select 実行]-->D[データ取得]
```

違いは全件取得したあとに、該当判定するか、データ走査時に、判定するかです。どっちが高速かは、一概にはいえません。遅いハードディスクにあるデータなら、一括でもってきて、インメモリで処理したほうが早いこともあります。
単純な図式化ですが、見通しがよくなります。

以上は、SQLの事例でしたが、検索一般に戻ると、どの範囲もしく検索エンジンを検索するのがいいでしょうか？



### 演習 現在進行中の研究を検索するのによい検索にはどんなものがあるでしょうか？

Google で適当に検索するのは、非効率的です。生成AIでまず調べるのがよいですが、この程度のプロンプトでは抜けてしまう検索エンジンがあります。なんでしょうか?
ヒントはお金が重要です。
ハッカソン参加時の備忘録 ～ 第０回：なぜこの記事を書くのか ～

はじめまして。
ITエンジニアのきゅうと申します。

# はじめに
　エンジニアをしていると、少し前からちょくちょく耳にする『ハッカソン』。
　ハッカソンという言葉はハック(hack)とマラソン(marathon)を合わせた混成語とのことで、
ハッカソンと言う名前に特に意味があるとは思いませんが、要するに決められた時間内に力を出しきって１つアプリや、サービス等を作り上げようぜ！と言う、IT関連のイベントの事です。

　かくいう私も、自分が所属している会社が年に１度、グループ会社を招いてハッカソンを開催しますのでそれに参加したり、外部のハッカソンに応募したりしております。
何故、自らキツいイベントに身を置くのか、きっとマラソン大会に参加するランナーと同じ気持ちだと思いますので、身近にいらっしゃるランナーの方に質問してみると良いかもしれません。

# 概要
　話が脱線しかしておりませんが、ハッカソンは決められた時間内にアプリやサービス等を作り上げる、、、
　言い換えれば動くモノを提供出来なければスタートラインに立つことすら出来ないわけです。

　そこで、これから何回かに渡って、私が過去に参加したハッカソンの際に行ったスタートラインに立つまでの手順を未来の私への備忘の意味も込めて、遺したいと思います。
※出来るだけ細かく手順を記載しますが、あくまで備忘録となりますので、理論は記載しません。
　何故そうなるの？と言うような質問は受け付けておりませんので、この記事をヒントに調べてみましょう！！


# 詳細
　ハッカソンにはそれぞれテーマがあることがほとんどです。
　そのテーマに沿った内容をアイデアソンの時に考えだし、それぞれのチームで、そのアイデアに沿ったプロダクトを作成していくことになります。
　アイデアソンからハッカソンまでの期間が1カ月以上あいているものもあれば、アイディアソンが終わったらすぐハッカソンが始まる場合もありますので、エンジニアに用意されている時間は少ないと思っておいた方が良いでしょう。。。

　そこで頭を悩ませるのは、どういったテクノロジーで、どういったプロダクトを作るのか？ということです！！
* クライアントアプリなのか、Webアプリなのか？
* オンプレミスなのか、クラウドなのか？
* DBを使うのか、スプレッドシートなどで代替するのか？

　その他にも考えることは沢山ありますし、それに対して一つ一つ丁寧に答えを出している時間がありません。
　そこで、何回かの記事に渡って、少しでもプロダクトを簡単に作っていく方法を、
　いろいろな記事・Webページを参考にしながら記載していきます。



# アジェンダ
## クラウド（AWS）
* ★第１回：クラウド環境を作成してみよう！
 
https://qiita.com/kyuu2197/items/16230161e5be2acea4b9

* ★第２回：１番お手軽なGUIであるLINEとAWS(Lambda)の連携をしてみよう

https://qiita.com/kyuu2197/items/68fcadc6ab6ac57cf8ea

* ★第３回：AWSのLambdaとRDS(MySQL)を連携して、DBに格納したものを表示してみよう！！

https://qiita.com/kyuu2197/items/46ef484db8e54bc74069
 
* ★第４回：AWS LambdaとAWS DBを連携させてみよう 
 
https://qiita.com/kyuu2197/items/71af265808e60239a9c3

* ★第５回：【Python】AWS LambdaとAWS S3を連携させてみよう 
 
https://qiita.com/kyuu2197/items/201d33437ba33665f840

* ★第６回：【Python】AWS LambdaとAWS Rekoginitionを連携させてみよう
 
https://qiita.com/kyuu2197/items/fd566d9966994a712f91

* ★第７回：【Python】AWS Rekoginitionのメソッドの種類を見てみよう
 
https://qiita.com/kyuu2197/items/d55ba9a4a6607cc58622

## 生成AI
* ★第８回：【Python】生成AIについて、学んでみよう
 
https://qiita.com/kyuu2197/items/9787e4bff2ee1bf9344e

* ★第９回：【Python】AWS LambdaとAWS Bedrockを連携させてみよう
 
https://qiita.com/kyuu2197/items/a44f7a9bd66e9fe9b59a

## xR（クロスリアリティ）
* ★第10回：テクニカル賞の常連、xRに触れてみよう
 
https://qiita.com/kyuu2197/items/d163413b74b7c4665422


※これからもどんどん増えます。。。