OmniAICreator/Qiita-1.07M huggingface dataset:
俺もクソアプリを作りたくなったので令和に(笑).comを蘇らせてみた

その昔、パソコン通信全盛の頃にテキストの句読点を「(笑)」に置換するというクソアプリがありました。当時にはクソアプリという呼び名はなかったですが。

そのアプリは PC-9801 用だったのですが、当時 PC-8801 しか持ってなかった私は、PC-8801 用に同様のクソアプリを作りました。それが「(笑).com」です。そのまんまですな。

[クソアプリ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/kuso-app)というのがあるのを知り、自分でもなんか作ってみたいなと思った時に思い出したのがこの「(笑).com」。ということで Chrome 拡張で作ってみました。

## ソースコード

```manifest.json
{
  "name": "(syou)",
  "version": "1.0.0",
  "manifest_version": 3,
  "content_scripts": [{
    "matches": ["<all_urls>"],
    "js": [
      "content.js"
    ]
  }]
}
```

```content.js
window.addEventListener('load', () => {
  const elm = document.querySelector('body');
  elm.innerHTML = elm.innerHTML.replaceAll(/。/g, match => {
    const syous = [
      '(笑)',
      '(笑)',
      '(笑)',
      '(笑)',
      '(苦笑)',
      '(爆笑)'
    ];
    return(syous[Math.floor(Math.random() * syous.length)]);
  });
});
```

「。(句点)」をテキスト置換してるだけです。ランダムに「(笑)」「苦笑」「爆笑」に置換されます。比率を変えたかったり、別の笑いを追加したければ `syous` を適当にいじればOK。

## 実行例

[クソアプリ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/kuso-app) の冒頭部分を表示してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/86075/3ed38fe2-3e65-3f71-c701-188674bc1c06.png)

上司からのお説教メールなども、これで全然怖くないですね！(より叱られても責任は持てません)

## 余談

ところで「(笑)」ってなんて読みますか？「(笑)」から転じて「ｗｗｗ」が生れたわけですから「わらい(warai)」が一般的なのでしょうが、個人的には「しょう(syou)」なんですよねぇ。自分の辞書にも「(笑)(しょう)」で登録してますしー。「(爆笑)」は「ばくしょう(bakusyou)」ですし、「(苦笑)」は「くしょう(kusyou)」なんだから、「しょう」やんーって思ってます。

以上、どうでもいいクソネタでした！
UI Stackを参考にToDoリストを作成する

# はじめに
UI設計を行う時に心がけるルールの一つとして、UI Stackという考え方があります。この考え方は[この記事](https://qiita.com/KokiSakano/items/edc1e4384478273661d4)で紹介しました。この記事ではこの考えを活かして実際に開発を行ってみます。
実装のためリにReact、Material UIを採用しています。この記事ではUI設計についてのみを話題にするためこれらの実装については一切触れませんので安心してください。実装された内容に興味のある方はCodeSandboxで実装を確認してください。

# 作成するアプリ
タイトルで既に触れていますが、ToDoリストを作成します。
最低限の機能として以下の6つを実装します。
- タスクの追加
- タスクの完了
- タスクのお気に入り
- タスク一覧の表示
- 完了したタスクも含めた一覧の表示
削除機能があっても良いですが、デフォルトではタスクの完了と同時にタスクを非表示にするのでこの記事では考えないものとします。

# Ideal State
まずはこのアプリの理想的な状態を考えましょう。このアプリにおいて理想的な状態とはいくつかのタスクが存在していてその中にお気に入りのタスクがあったり完了済みのタスクがある状態です。
![スクリーンショット 2022-12-12 21.12.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/591069/cfd9f2ac-ac59-3e50-844d-3792b1a5eac9.png)

# Error State
このアプリでエラーを発生するケースは1つしかありません。追加するタスクのテキストに対するバリデーションです。タスクの追加を行うときに文字数が空もしくは31文字以上であればエラーメッセージを表示するようにします。エラーが発生したときの挙動は以下のようにします。
![スクリーンショット 2022-12-12 21.23.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/591069/90b53f65-878e-8350-5ad0-16678706662b.png)
エラーが起きている場所をわかりやすくするためにラベルとテキストフィールドの色を変更し、テキストフィールドの下にはエラーを解決する助けとなるようなメッセージを表示するようにしています。一度エラーが発生したらそれが解決するまでボタンは無効になるようにしました。
また、エラーが発生することを示すのはボタンを押してからだけではなく、30文字を超えて入力があった場合は動的にエラーを表示するようにしました。今回入力する部分は一つなので恩恵は薄いですが、送信してから修正することに比べて手戻りが少なくユーザーの助けになりやすいです。
さらに、ボタンを押してバリデーションに失敗した場合でも値は残すようにしました。

# Partial State
私はこのアプリにおけるPartial Stateは存在しないと考えているので設計しません。このようにアプリを作成する中で必要のない状態も出てきますが、最初にその状態が必要かどうかを考えることは重要なので忘れずに行いましょう。

# Loading State
タスクを読み込んで表示する必要があると仮定すると、読み込み中の状態が必要となります。画面全体にSpinnerを配置するのもこの規模で話ではないですがここではタスクの読み込み、書き込みを行う部分のみを読み込むような設計にします。
![スクリーンショット 2022-12-12 21.48.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/591069/63239dc9-38cb-9dba-29a4-0f9f66f6af6d.png)
このようにすることでLoading中にタイトルを見てこの画面はどのような画面かユーザーが理解することが可能になったり、完了したタスクを表示にするか、非表示にするかの決定を行うことができます。
他にも今はサーバーとの通信を行っていませんが、サーバーとの通信を行う必要があっても画面上ではタスクのお気に入り、追加、完了の即時反映を行って裏側でサーバーの通信を行うようにすることでユーザーにストレスなくアプリを利用させることができます。

# Blank State
最初からダミーデータとしてタスクをいくつか表示させて置くことで、初期利用時にデータが空になることを防ぐようにしました。ユーザーがこれらのデータの扱いに困るケースが考えられるので得策ではないですが、どのように利用すれば良いか理解できるという点では有利に働きます。実際に出荷するアプリで採用するときはダミーデータとわかるようなデータを作るのが良さそうです。
完了したタスクを表示しないとき、全てのタスクが完了して表示するデータが空になったときにはユーザーに対して賛辞を送るようにしました。完了したことで次の行動のイメージがわかないユーザーのために簡単な説明も表示しています。
![スクリーンショット 2022-12-12 22.11.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/591069/998de107-fd61-e988-1ce9-ede52aa0a19f.png)


# 成果物
こうして作成されたのが以下のアプリケーションです。

https://codesandbox.io/embed/ideal-state-mx4tg2?fontsize=14&hidenavigation=1&theme=dark&view=preview

データの読み込みを5秒間行うように大袈裟に実装してLoading状態を表示できるようにしました。他は説明の通りです。
【React】 Context の使い方

## はじめに

本記事はシリーズものです。

通常、React では props を通じて親コンポーネントから子コンポーネントへ値や関数の受け渡しを行います。
しかし、特定のケースにおいてはこれが面倒に感じてしまうパターンがあります。

いわゆるprops のバケツリレーが発生してしまうんですね。

これの回避のために、React では Context というものが用意されています。
今回はこの Context についてのお話を 3 回に分けてお話しします。

第 1 回では「**Context いつ使用するべき**で**いつ使用するべきではないか**」
第 2 回では「**Context の使い方**」 ← イマココ
第 3 回では「**Context を使う際にどんなことに気をつければいいか**」

についてお話しします。

## Context の使い方

Context では付属する Provider コンポーネントにより、囲まれた範囲に値を配布します。
以下の AuthenticationProvider では、認証情報を子である`Component`に対し配布しています。

```tsx:pages/_app.tsx
import { AuthenticationProvider } from "@/AuthenticationProvider";
import type { AppProps } from "next/app";

export default function MyApp({ Component, pageProps }: AppProps) {
  return (
    <AuthenticationProvider>
      <Component {...pageProps} />
    </AuthenticationProvider>
  );
}
```

### Context の作り方

`createContext`を用い`Context`を作成します。

```tsx:AuthenticationProvider.tsx
import { createContext } from "react";

type User = {
  uid: string;
  email: string;
  name: string;
}

const Context = createContext<User | null>(null);
```

### Context Provider の作り方

先ほどの Context には Provider コンポーネントが付属しています。
`value`には配布したいものを渡します。
今回の場合、user 情報が渡したいので、`useAuth`という hooks から入手したユーザーステートを渡します。

```tsx:AuthenticationProvider.tsx
import { createContext } from "react";

type User = {
  uid: string;
  email: string;
  name: string;
}

export const AuthenticationContext = createContext<User | null>(null);

export const AuthenticationProvider: FC<{ children: ReactNode }> = ({
  children,
}) => {
  const { user } = useAuth();
  if (!user) return <p>Loading...</p>;

  return <AuthenticationContext.Provider value={user}>{children}</AuthenticationContext.Provider>;
};
```

このようにしておけば、user 情報を子コンポーネントたちに配布できるわけですね。

### Context Provider で配布された値を使う

`useContext`という hooks が提供されているので、先ほど作った Context を引数に渡します。

```tsx:Children.tsx
import { useContext } from "react";
import { AuthenticationContext } from "./AuthenticationProvider";

export const Children = () => {
  const user = useContext(AuthenticationContext);
  return <div>{user?.uid}</div>;
};
```

これだけで何重にネストしていても user ステートにアクセスできるようになりました。

## まとめ

いかがでしたでしょうか？
今回は、Context の使い方について話しました。

便利な反面、使い方を誤ると保守性が崩れていってしまったりするので、次回は「**Context を使う際にどんなことに気をつければいいか**」について書いていければと思います。
jquery・Laravelでの簡易的なバリデーション実装

# 背景
モーダルに検索フォームが設置されている。
モーダル内部にLaravelのformクラスを利用しようとすると、
検索ボタンを押す→モーダルを開く→バリデーション　と時間がかる。
そのため、LaravelのFormクラスは利用せずjqueryで実装しようと考えた。

# 結論
Laravelのフォームクラスは優秀。
いろんなことを考慮して作られているため、
自分で同じようなことをしようとするとテストも含めて工数がかなりかかる。

# 実装の概略
入力時にフリーワード→セレクトボックスへ変更。
最小値・最大値が逆に入力されていないか判断するバリデーションのみを実装した。
セレクトボックスは変更後の値が不正な値である場合に、アラートを出すようにした。

# 実装
入力時の値を保持→変更時の値を保持
```Laravel:.js
$('#form').on('focus',function(){
    focusval=this.value;
}).change(function(){
    selectedval = this.value;
    //focusvalとselectedval を較べる処理を記載
)};
```
以上。
Oracle Analytics Cloud：ワークブックのパフォーマンスが気になったら

# はじめに
ワークブックを開くとキャンバスが表示されます。
時として、開くのに時間がかかることがあります。
時間がかかる理由は様々です。
- 複雑なビジュアライゼーションを使用している
- DBの処理時間が長い
- DBからの検索結果の受信に時間がかかっている

などです。
上記のいずれも当てはまらないにも関わらず、パフォーマンスが良くない場合には、一度ブラッシングをオフにしてみてください。

# ブラッシングとは
キャンバスに複数のビジュアライゼーションがあるときに、あるビジュアライゼーションの一部をクリックしたときに、そのデータが含まれる他のビジュアライゼーションが強調表示される機能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/57969650-8d98-93d9-fe20-c0371b676702.png)
この例では、左下の表の一部（製品番号14の列）をクリックしたところ、左上のドーナツチャートと右の折れ線で、この製品が属する製品カテゴリが強調表示されました。
これがブラッシングです。
ブラッシングはデフォルトでオンになっています。

# ブラッシングをオンにするとどうなる
「開発者」機能で確認すると、キャンバス上の各ビジュアライゼーションを表示するためのクエリー以外に、「ブラッシング問い合わせ」という多数のクエリーが実行されているのがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/b9238b89-9c16-0477-067b-8fb70fc51121.png)
ブラッシングをオフにすると、これらの問い合わせが実行されなくなるため、その分パフォーマンスが向上します。

:::note info
パフォーマンスの確認方法は、こちらの記事を参考にしてください。
- [Oracle Analytics Cloud：実行時のパフォーマンスが気になったらココを見る](https://qiita.com/tyo38/items/0d87e32b2c7bd4d7a776)
:::

# ブラッシングをオフにする
ブラッシングは様々なレベルでオフにすることができます。

## キャンバスレベルでオフにする
ブラウザの右下に並んでいるアイコンの中から、ブラッシングアイコンをクリックすると、そのキャンバスでブラッシングがオフになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/c9c52f4e-8c9c-6e49-ba33-dde551fae0f8.png)
オフになった状態
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/aa4009c7-6a35-25a9-a3cb-f4955d6c8931.png)
もう一度、アイコンをクリックするとオンの状態に戻せます。
キャンバスのプロパティ画面からオフにすることもできます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/f6ccbfa5-1b66-f2b3-baeb-87647fc7eec1.png)

## ワークブックレベルでオフにする
ワークブックのレベルでオフにする場合は、ワークブックのプロパティを使用します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/e28a191b-e7fc-7ee6-9453-52362b3acff0.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/edf0275b-6e01-c8a1-2c8a-58bbeb02de16.png)
こうしておけば、それ以降ワークブックにキャンバスを追加すると、そのキャンバスでのブラッシングはオフになります。
ただし、元々キャンバスレベルでブラッシングがオンになっていた場合、それが自動的にオフになるわけではありません。

## システムレベルでオフにする
コンソールの「システム設定」で、「Performance and Compatibility」セクションでブラッシング設定のデフォルトを設定できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342206/6615fadc-6977-ff52-7ad2-db268e9ceea1.png)
サブジェクト領域に対するブラッシングと、データセットに対するブラッシングをオフにします。

:::note info
設定が反映されるまで、数分かかることがあります。
:::

これにより、新規のワークブックを作成すると、そのワークブックではブラッシングがオフになります。
既存のワークブックでは、ブラッシングの設定が「自動」になっていれば、システム設定に従ってオフになります。自動ではなく「オン」になっていれば、システム設定に関わらずオンになります。
キャンバスレベルでオンになっている場合、そのキャンバスはオンのままです。

# おわりに
ブラッシング設定は、システムのデフォルトをオフにしておき、必要なワークブックやキャンバスのみでオンにするのがパフォーマンスを重視する場合はベターかも知れません。
GraphQLリゾルバのディレクトリ構造

[Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く Advent Calendar 2022](https://qiita.com/advent-calendar/2022/shwld)
の**13日目**。[株式会社mofmof](https://www.mof-mof.co.jp/)に生息している[shwld](https://twitter.com/shwld)です。

前日は[GraphQLサーバーを構成する要素](https://qiita.com/shwld/items/0d2cb0802918030d6350)について書きました
# GraphQLサーバーを構成する要素

```:/use-cases/graphql-resolvers/src/modules
┣━┳━ modules
┃ ┗━┳━ account // Entityなどに対応するオブジェクト単位でディレクトリをきっている
┃   ┣━┳━ mutation-resolvers
┃   ┃ ┗━┳━ account.create // アクションイベントごとにディレクトリを切る
┃   ┃   ┣━━━ create-account-validation.ts // バリデーションに関するロジック
┃   ┃   ┣━━━ create-account.sdl.graphql // このアクションのスキーマ定義
┃   ┃   ┣━━━ create-account.test.ts // テストロジック
┃   ┃   ┣━━━ create-account.ts // mutation本体
┃   ┃   ┗━━━ index.ts
┃   ┣━┳━ object-resolvers
┃   ┃ ┗━┳━ account // オブジェクトごとにディレクトリを切る
┃   ┃   ┣━━━ account.sdl.graphql // オブジェクトのスキーマ定義
┃   ┃   ┣━━━ account.ts // Entityをオブジェクトに変換するロジック
┃   ┃   ┗━━━ index.ts
┃   ┣━┳━ query-resolvers
┃   ┃ ┗━━━ .gitkeep // root queryはめったに生やさないので空なことが多いです
┃   ┗━ index.ts
┣━ middlewares // GraphQL Shieldなどを格納する場所
```
[/use-cases/graphql-resolvers/src/modules](https://github.com/shwld/uzumaki/tree/advent-calendar/use-cases/graphql-resolvers/src/modules)

[GraphQL Modules](https://the-guild.dev/graphql/modules/docs#example)と同じようにmoduleを分けて管理しています。

## 考慮ポイント

### テストを処理の隣に置く
テストだけを切ってテストだけを配置するか、フロントでよくある形である実処理の隣に置くかで悩むところですが、後者を選択しました。
処理を治す場合テストも一緒に直すし、逆も然りなので、個人的にはこっちのほうが開発体験がいいです。

ここ一番悩んだところで、レイヤー的観点で見るとテストだけを別プロジェクトにしたかった気持ちもあったのですが、開発体験を優先しました。
なのでその苦渋の選択の結果として、GraphQLリゾルバの層にはテストに使う依存が含まれてしまっている(devDependenciesなので許してという気持ちで入れた)というモヤりポイントがあります。

### スキーマ定義を一箇所にまとめるか散らすか

```graphql
type AccountEdge implements Edge {
  node: Account
  cursor: String
}

type AccountConnection implements Connection {
  pageInfo: PageInfo
  edges: [AccountEdge]
}

type Account implements Node {
  id: ID!
  createdAt: DateTime!
  updatedAt: DateTime!
  isDeleted: Boolean

  name: String!

  projects: ProjectConnection!
}
```

スキーマ定義はこういうやつです。
現状は、各モジュールの各要素の中に散らばって存在しています。
GraphQLリゾルバの作り方としてはスキーマファーストを選択しているのですが、これは割りとコードファーストに近いアプローチだなーと感じてます。
（モジュールを切って、要素を定義して初めてスキーマを決められる）

ただここは、後述（このカレンダー内の別記事で書く予定）のplopjsによるコード生成により、`yarn g:module` コマンド一発でこのディレクトリ構造とファイルを一発で作成できるため、局所的なスキーマ定義によるコードファースト的なメリットを維持しつつスキーマファーストの恩恵を得られる構成になってると思います（何書いてるかよくわからなくなってきたけど伝わるでしょうか...）
# 次回予告
明日は[Relay Styleページネーション](https://qiita.com/shwld/items/6f8d186adb8064d27a65)について書きます
【React】 Context をいつ使うべきか

## はじめに

通常、React では props を通じて親コンポーネントから子コンポーネントへ値や関数の受け渡しを行います。
しかし、特定のケースにおいてはこれが面倒に感じてしまうパターンがあります。

いわゆる**props のバケツリレー**が発生してしまうんですね。

これの回避のために、React では Context というものが用意されています。
今回はこの Context についてのお話を 3 回に分けてお話しします。

第 1 回では「**Context いつ使用するべき**で**いつ使用するべきではないか**」 ← イマココ
第 2 回では「**Context の使い方**」
第 3 回では「**Context を使う際にどんなことに気をつければいいか**」

についてお話しします。

## いつ使用するべきか

先に記載した通り、props のバケツリレーを無くしたいと思ったシーンです。
以下のようなシーンでは使うと便利です。

### 1. 認証情報やページ全体で使うテーマの場合

以下のように、認証情報を持った`AuthenticationProvider`でベースとなる\_app.tsx を囲むことでアプリケーション全体に配布することができ、各コンポーネントで props を経由することなく、直接認証情報を入手することができます。

```tsx:pages/_app.tsx
import { AuthenticationProvider } from "@/AuthenticationProvider";
import type { AppProps } from "next/app";

export default function MyApp({ Component, pageProps }: AppProps) {
  return (
    <AuthenticationProvider>
      <Component {...pageProps} />
    </AuthenticationProvider>
  );
}
```

### 2. 親から子、子から孫と何重にも同じ値を受け渡ししないといけない場合

1 と似たようなケースではありますが、何重にも props を受け渡さないといけないケースにも有用です。
一概に何段目からというのは特に決まってないですが、次の**どういうシーンで使うべきではないのか**？を見てチームで話し合うのが良いかと思います。

## いつ使用するべきではないか

ネストが深くない値の受け渡しに関してはメリットよりデメリットが大きくなります。
なぜなら**再利用性が下がる**からです。

子コンポーネント側では、`useContext`という hooks を用い、配布された値や関数を参照しますが、
これは親が Provider に囲まれているという前提のコードになってしまいます。

つまり子が親に依存し、再利用性が失われる訳です。
まさに子が親の`Context`を知ってしまうわけですね。

なので、使わなくていいシーンでは使わない。使う場合も用法を守る必要がある。
ということを覚えておいてください。

## まとめ

いかがでしたでしょうか？
今回は、Context というものについての概要として

- いつ使用するべきか
- いつ使用するべきではないか

について話しました。
次回、**Context の使い方**について書いていければと思います。
Unable to resolve AWS account to use. It must be either configured when you define your CDK Stack, or through the environmentの対処法

# エラー内容

`cdk init` コマンド後の `cdk bootstrap` コマンドが上手く実行できない
- コマンド
```
cdk bootstrap
```
- 実行例
```
>cdk bootstrap

Unable to resolve AWS account to use. It must be either configured when you define your CDK Stack, or through the environment
```

# 原因
1. 環境変数がおかしい
2. `aws configure` が設定されていない

# 対処法

## 1. 環境変数がおかしい場合の対処法

問題がないかチェック
- コマンド
```
cdk doctor
```
- 実行例
```
$ cdk doctor
ℹ️ CDK Version: 2.53.0 (build 7690f43)
ℹ️ AWS environment variables:
  - AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
  - AWS_STS_REGIONAL_ENDPOINTS = regional
ℹ️ No CDK environment variables
```

環境変数で変な設定している箇所を探す
- コマンド
```
export -p
```
- 実行例
```
$ export -p
...省略
declare -x AWS_ACCESS_KEY_ID="hogehoge"
declare -x AWS_SECRET_ACCESS_KEY="fugafuga"
declare -x AWS_REGION="us-east-1"
...省略
```

環境変数を消す
- コマンド
```
unset 【環境変数】
```
- 実行例
```
$ unset AWS_ACCESS_KEY_ID
$ unset AWS_SECRET_ACCESS_KEY
$ unset AWS_REGION
```

## 2. aws configure が設定されていない場合の対処法

`aws configure` コマンドを実行して設定する
- コマンド
```
aws configure
```
- 実行例
```
>aws configure
AWS Access Key ID [None]: hogehoge
AWS Secret Access Key [None]: fugafuga
Default region name [None]: ap-northeast-1
Default output format [None]: json
```

## 成功例
以下のようになれば成功
- コマンド
```
cdk bootstrap
```
- 実行例
```
>cdk bootstrap
 ⏳  Bootstrapping environment aws://【AWSアカウントID】/【リージョン】...
Trusted accounts for deployment: (none)
Trusted accounts for lookup: (none)
...省略
```
なぜあなたは論文が書けないのか?


本の紹介記事です。プロダクト開発のための開発手法や技術書についてではなく、論文執筆についてのHowTo本の紹介です。

# なぜあなたは論文が書けないのか?/佐藤雅昭

[<img width="500" alt="Image.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599506/ced1b47f-5471-49a8-9cf0-c67c5a16c9df.jpeg">](https://publish.m-review.co.jp/book/detail/978-4-7792-1724-1)

https://www.amazon.co.jp/%E3%81%AA%E3%81%9C%E3%81%82%E3%81%AA%E3%81%9F%E3%81%AF%E8%AB%96%E6%96%87%E3%81%8C%E6%9B%B8%E3%81%91%E3%81%AA%E3%81%84%E3%81%AE%E3%81%8B-%E4%BD%90%E8%97%A4-%E9%9B%85%E6%98%AD/dp/4779217245

# なぜ読んだのか

note記事「[働きながら情報系の大学院を修了したby父](https://note.com/fushiroyama/n/n602687744edb)」で紹介されていたことがきっかけです。（尊敬しました。）

先行開発組織にいるのに、現部署に移ってから論文はおろか学会発表すらしていません。前部署でも論文はほとんど経験がありません。かと言って、開発した技術が事業化しているわけでもない。

開発技術の価値をお客様に早く提案する(PoC)、アカデミックに技術開発を深堀して発信する、どっちも中途半端でもやもやしてました。前者についてはコツコツ開発しています。ビジネスの判断は自分だけでコントロールできません。
後者については、割と自分でコントロールできる領域ですが、現組織では論文を出している人など一人もおらず、またコロナで学会発表もオンラインになったためモチベーションも下がっていました。そんな中、上述の記事で紹介されていた本著を手に取ってみました。

# 本の紹介
全4章構成で、特に「なぜ論文を書くのか？」というモチベーションにフォーカスされています。

- プロローグ：なぜあなたは論文を書くのか？
1. 論文を書き始められない要因
1. 論文を書く前のこと
1. 論文を書くときのこと
1. 論文を書いた後のこと

論文を書き始めることに抵抗がある人は、2章までが特に重要。
3章は論文で”イイタイコト”を定めてブレずにそれに向かって書いていくのか、
4章は書き終わってからAcceptされるまでにモチベーションを保って活動続けるための方法が記載されている。

論文に対して抵抗ある人が気軽に読めるように、本著はさらっと読みやすく作られています。

プロダクト開発のノウハウが学べるわけではないので、その観点ではお勧めしません。各章、問いかけるような見出しになっているので、[目次](https://publish.m-review.co.jp/book/detail/978-4-7792-1724-1)を読んで部分的にでも自分に当てはまると思った方には、良いきっかけを与える1冊かもしれません。

# 気になった点

## 論文を書く目的は？
キャリアのため？成果のため？博士号のため？やらされて書く論文は苦行です。なんとなく書きたい、書いた方がよさそうと思っているが、まず「どうなりたいか」を考えす必要があります。


## 核となるデータが集まれば論文を書き始める
プロダクト開発のように明確な目的のために開発するだけでなく、研究開発をしながらアウトプットのイメージをしていくことも多いと思います。研究開発では、核となるデータや事象が出てきた時点で論文を書き始める必要があります。ここで重要だと思った点は2点あります。

- ストーリーを描くことが重要
   ”ストーリー”というのは一つのキーワードです。3段論法で作っていくなど、具体的な組み立て方は本著にも記載されていますが、データ(材料)からストーリーを展開する考え方の癖をつけたいと思いました。ストーリーを組み上げる作業は単純作業ではなく「知的作業」なので、まとまった時間を確保するようにしてしっかり考えます。

- 完璧を求めすぎない
   完璧なデータを集める必要はなく、核となるデータでストーリーが描ければ、まずは最初の半歩を踏み出していき、その中で必要な材料があればまた集めるだけです。データを綺麗見見せたり、論文を読んだりするのは「単純作業」なので、small stepを踏んでいけば進みます。

## 論文のテーマに即した文献に目を通したか？モデル論文を3本程度見つけているのか？
   論文を読むのが苦手な私にとっては耳の痛い内容でした。英語に抵抗があるのであれば翻訳機能に頼ればいいですし、全部完璧に理解して読む必要はないです。「できたらやる」ではなかなか行動できないので、時間を確保する仕組みを作って、文献を読んでいく必要があります。

## その他
2章までの中から取り上げましたが、3章以降も参考になりました。論文を書いていくうちに何が言いたかったのかぐちゃぐちゃになっていった経験がある（めっちゃよくある）ので、一つのイイタイコト（=この本では北極星とも表現されてました）に向かって組み立てていくためのコツを、一つ一つ分解して記載されていました。

4章では、論文を書き終わった後の長い闘いで心が折れないように、という内容が記載されており、昔、研究室の先輩、Reviewerにキレたり心折れたりしてたな～と思い出しながら読みました。

## まとめ
とにかく、モチベーションをしっかりと確認すること。
如何に最初の半歩を軽く踏み出すかも重要ですが、その後も論文がAcceptされるまでは根気のいる作業です。コントロールできない他人（上司、指導教官、Reviewer）ともやり取りする必要がありますし、書き終わった後も根気強く進めなければAcceptまでたどり着かないです。その時に、モチベーションを保てるように普段から「どうなりたいか」考え続けたいと思いました。

# さいごに（ポエム）

「なぜやるか」が最重要だと思いました。

現業では、PC稼働時間をモニタして業務時間が管理されており、増えたタスクを残業で処理することができません。今のタスクに追加で論文を書くとなると、プライベートの時間を割いてコソコソ論文を書いていくことになります。

「今の会社で働く中で、本当にそこまでして論文を書く必要があるのだろうか？」の問いに対しては「いや、ない」という結論に至りそうですが、自分のキャリアを見通して論文が必要かどうかを考えて、もし必要なら業務の中で論文を書けるように環境を整える努力も必要だと思いました。
コラボフロー LINE WORKS連携オプションの設定について

[コラボフロー Advent Calendar 2022](https://qiita.com/advent-calendar/2022/collaboflow) 13日目の記事です！
コラボフローってなんぞや？って方は[こちら](https://www.collabo-style.co.jp/about/)のページをご参照ください！
##

非常に寒くなり、子供達が風邪引かないかヒヤヒヤしているケニーです。
13日目の本日は、今まで出てきていない内容を記事にしようと思います。

コラボフローと他のサービスを連携して利用する事で、
更に仕事の効率が上がったり、簡単に処理できたりできるのですが、
その一つがLINE WORKSとの連携です。

そう、あのLINEです！
スマートフォンをお使いのほとんどの方は利用しているのではないでしょうか。
普段使い慣れているLINEにワークフローの通知がきて、そこから処理できたらすごく楽じゃないですか！？

:::note info
以下のようなことができます！
・LINE WORKSのコラボフローBotから、申請したいコラボフローの文書を呼び出す
・コラボフローの申請書に関する通知を、LINE WORKSのコラボフローBotで受け取る
![aboutLINEWORKS.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2627323/ce1199f4-740a-df89-0049-d45a4a5f5fb1.png)
:::

設定方法について、よくお問い合わせをいただいたりしておりますので、
今日は、コラボフローとLINE WORKSを連携させる設定方法を改めてザっとまとめてみようと思います。
最近公式サポート記事も大きく更新されましたので、そちらもお時間ある際にご参照ください。

[参考記事：コラボフロー LINE WORKS連携オプション](https://collaboflow.zendesk.com/hc/ja/sections/360000306716)

## 事前準備

#### コラボフロー側
##### １）コラボフローにユーザー登録
　　コラボフローとLINE WORKSのユーザーIDは、一致させる必要があります！

　　例：
　　コラボフローのユーザーID ：kenny_test@kennystyle
　　LINE WORKSのユーザーID  ：kenny_test@kennystyle
　　（LINE WORKSドメイン名またはワークスグループ名が「kennystyle」の場合）


##### ２）フォームと経路を設定
　　コラボフローに、LINE WORKSと連携したいフォームと経路を作成します。

##### ３）認証コードを用意
　　ご契約開始時にコラボスタイルからお送りしますメールに記載された、「認証コード」をご用意ください。
　　お試し中の場合、「認証コード」は不要です。

#### LINE WORKS側
　LINE WORKSのサイト（初期設定ガイド）をご確認の上、設定を行ってください。
　https://line.worksmobile.com/jp/ebook/video-for-beginner/


## 設定方法

結論から。
文字ではなくイメージ図で共有します！（文字だけだと分かりにくいですしね。。）
LINE WORKS側とコラボフロー側でそれぞれ認証情報を発行し、
外部サービス連携設定で、以下画面のように設定を行います。

#### 認証情報の設定
設定のイメージ（認証情報を発行する箇所と、貼り付け先）
![参考例 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2627323/527f0bf1-158f-b611-cf3d-dd9f3faaabba.png)

どの値（キー）をどこに保存するのかが最大の混乱（複雑）ポイントなんだと予測しています。
その為、上記イメージ図を参照に何をどこに貼り付けすれば良いか、パッと見で理解していただけますと嬉しいです。

#### トークBOTS設定
設定のイメージ
![スクリーンショット_20221212_174834.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2627323/cd30bbc0-8068-994f-a606-a48c5a1fc575.png)

こちらもどこに何を設定すればよいかをキャプチャ＋補足で示しました。

なお、詳細の認証情報の発行については、
以下公式サポート記事をご参照ください。
参考URL：[LINE WORKSとの連携設定](https://collaboflow.zendesk.com/hc/ja/articles/360001598075)

## まとめ

一度設定できると、使い慣れているLINEを使って、業務効率化を図れるので、
非常に使い勝手良いですよね～。

少しでもお役に立てれば嬉しいです！

以上でっす！
React Hook Form,バリデーションzodを使用した場合、zodスキーマに記述した項目同士のチェック

## はじめに
React Hook Form を使用し、バリデーションライブラリはzod という案件にて、zodスキーマに記述した項目同士のチェックが必要だったのでそのメモです。

私が探した時点（2022.12）では、日本語で解説してくれている記事を見つけることができなかったので、参考になれば嬉しいです。


## やりたいこと
zodを使用して、zodスキーマに登録した項目同士のバリデーションチェックをしたい

### 例えば、パスワードチェック

**最初の入力と確認用が同じかどうかチェックしたい**

というシーンは良くあるのではないでしょうか？


## 結論

zodのrefineを使用します。

```js

const passwordForm = z
  .object({
    password: z.string(),
    confirm: z.string(),
  })
  .refine((data) => data.password === data.confirm, {
    message: "パスワードとパスワード（確認）が異なっています。",
    path: ["confirm"],
  });

```



エラー文言出力はconfirmにエラーが入ってくるので、パスワードの方にもエラーメッセージを出す場合には、confirmとします。



``` jsx

 <div>
     <p>パスワード</p>
     <input type="password">
     <ErrorMessage message={errors.confirm?.message} />
 </div>
 <div>
     <p>パスワード確認</p>
     <input type="password">
     <ErrorMessage message={errors.confirm?.message} />
 </div>

```


## 参考

https://github.com/colinhacks/zod#refine


## 最後に

他にもzodで重複チェックをする方法も書いてますので、もし良ければ参考にしてみて下さい。
参考になれば嬉しいです。

https://qiita.com/niyu1103/items/30329309bdfa1268a28b
GBFSの公開リストSystems Catalog へ申請・更新する手順

# きっかけ
GBFSのデータを公開する際に、「System Catalog に追加するのってどうするんだっけ？」という会話になったので備忘録として記事にしておきます。

# System Catalog とは

GBFSでデータを公開している各サービスの System ID　を管理している csvファイルです。
System ID が重複しないように、申告制になっています。

日本で公開している２社のSystem ID
- docomo-cycle-tokyo
- hellocycling


![770B6C7E-FE5E-4739-ABDC-06D837B0EB1F.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274029/11751c76-d4df-b19e-286f-7c4faf33f278.png)

こちらのリストは以下で公開されています。

https://github.com/MobilityData/gbfs/blob/master/systems.csv

# System ID Catalog に追加してもらう方法

FAQには以下のように記載されている。

>Who maintains systems.csv?
>
>The systems.csv catalog is currently maintained by MobilityData and the GBFS community. If you have or are aware of a system that does not appear on the list please add it by opening a pull request or notify MoblityData at: sharedmobility@mobilitydata.org.

https://gbfs.mobilitydata.org/learn/faq/

- Github で Pull Request を送る
- GBFSを管理している Mobility Data へメールで連絡


なにか相談事項などがあるときはメールで、
基本的にはPRを送ったのでよいと思う。

他の人のPR、自分のケースでは、1~2週間で反映された。

参考までに、LocationとNameを修正したPR↓
（現在は反映されてClose）

https://github.com/MobilityData/gbfs/pull/453

# 補足

リストは、国名、System IDをアルファベット順でソートしている。
データを公開した順になっているわけではない。
[2022年版]Lambda+API GateWayでAPIを爆速構築

## 概要
今までなにかAPIを作るときはレンタルサーバーを借りていたりしたのですが、もう時代はとっくにサーバレスに進んでいるなと思いまして、今更ながらこのような基礎的なことをしてみようと思いました。

## 作るもの
最終的にはタイトルにあるようにLambdaとAPI GateWayを用いてAPIを構築していこうと思います。

## 実践
### Lambda
まず、Lambdaの方で関数を用意します。
下記のLambdaのページから「関数の作成」を選択しまして
![スクリーンショット 2022-12-14 5.15.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/89bb8a94-d16a-f858-f149-fa530caafba6.png)
関数名と言語を決めて「関数の作成」を選択します。
自分はRubyが好きなので言語をRubyにしてますがNodeが初期選択されてるので一般的な気がしてます
![スクリーンショット 2022-12-14 5.16.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/573c72b6-1267-7143-45c2-2efb3d838b27.png)

今回はLambdaの方のコードは特にいじりませんのでLambdaでの作業はここまでです！

### API GateWay

#### APIの作成 
次にAPI GateWayのページに飛びまして下記の「REST API」を選択します。
![スクリーンショット 2022-12-14 5.07.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/a4135918-66d4-89c9-e925-e39a43b8b685.png)

次にAPIの名前を決めて「APIの作成」を選択します。
![スクリーンショット 2022-12-14 5.10.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/c47d9884-7e9e-8a2d-57fa-812648d92d6a.png)

#### リソースの作成
次にリソースを作成していきます。
ページの上の方のアクションの中に「リソースを作成」があるのでそちらを選択し
![スクリーンショット 2022-12-14 5.12.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/554bba19-dd58-4414-73be-2cd17f81dcbf.png)
リソース名をきめて「リソースの作成」を選択します。
このリソース名がパスのベースにもなります。
![スクリーンショット 2022-12-14 5.13.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/d9ddb657-fde1-6280-70af-e9172c6e9f3f.png)

#### アクションの作成
次にアクションの方を作成していきます。
先ほどと同じアクションのボタンから「メソッドの作成」を選んで
![スクリーンショット 2022-12-14 5.13.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/c1474258-f04a-5253-c085-0907481e1558.png)
GETを選択し
![スクリーンショット 2022-12-14 5.13.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/65585576-58e9-5066-5671-fae03b58a4b3.png)
先程作成下Lambda関数を選んで「保存」
![スクリーンショット 2022-12-14 5.18.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/bae186af-c572-e35f-ecba-a6d54f432084.png)
権限云々が出てくるのでOKを押下
![スクリーンショット 2022-12-14 5.19.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/420149b6-3e7e-1818-bc59-1bf1b5004004.png)
これでアクションの準備は終わり！

#### デプロイ
最後にデプロイです。
今までと同様にアクションからAPIのデプロイを選択し
![スクリーンショット 2022-12-14 5.19.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/9eb01e19-1c08-452f-7f55-ea9f07100fbb.png)
ステージ名を決めて「デプロイ」を選択
![スクリーンショット 2022-12-14 5.20.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/8b8365f6-6945-c044-0796-9ca7ab9565b3.png)

表示されたURLに先程の/リソース名の形式でアクセスすると...

![スクリーンショット 2022-12-14 5.21.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83409/7f4360aa-b01e-fa06-5d21-b9148d37ad5e.png)
Labmdaの方で定義したJSONが返ってきました！！！
簡単..そしてはやい...
システムエンジニアこそ健康を意識すべし

月に一度は整体に行って、身体を整えている小野です。
デスクワークでずっと座っているので、一ヶ月に一度は整体に行くのオススメです。あなたの身体は、意外と悲鳴を上げています。

エンジニアの働き方を見ると、健康についても考えるようになりました。
”コロナの時期だったから”というのもありますね。
仕事を休むと、そのまま収入にも影響しますし。

すべてのシステムエンジニアが健康について考えるべきだと思っています。
**そう思ったのは、健康がベースにあり、初めて仕事やプライベートが上手くいくと感じることが増えたからです。**

体調が悪い時は、仕事のパフォーマンスを発揮できません。
体調が良い時は、仕事のパフォーマンスを発揮できます。

忙しいシステムエンジニアも最低でもこれだけはやっておくと、体調が良くなることを書いています。

## システムエンジニアこそ健康を意識すべし！ 健康管理も仕事のひとつ

ビジネスマンなら、健康管理も仕事です。
システムエンジニアという職業上、どうしても運動不足、時期によっては睡眠不足になってしまいます。

だからこそ、普段から健康管理をして、体調を良くしていたいですね。

### 早寝早起きをする

20代の頃はそこまで気にしませんでしたが、30代になってから夜遅くに寝ると翌日のパフォーマンスは最悪です。
むしろ、翌日だけでなく、一週間パフォーマンスが回復しないこともありました。

どうしても寝る前の10分は、色々と何かをやりたくなってしまうものです。スマホをいじったりや、テレビを見たりなどなど。
しかし、翌日の朝「あと10分寝たい」と思うのも自分です。。（笑）

朝スッキリと目覚めることは、その日1日の気持ちにも大きく影響しますし、仕事のパフォーマンスを上げたいなら夜は寝て早起きする習慣に移したほうがいいですよ。

ちなみに、**早起きのコツは、早く寝ることです！**
早起きのコツは、早く寝ることです！！

大事なことなので、2回書きました。

2時に寝て6時に起きるのは、辛いです。
しかし、22時に寝て6時に起きるのは、カンタンです。（しかも、目覚めはスッキリしています）

### 整体で身体を整える

長時間のデスクワークは、身体に良くないです。
最近だと、「スタンディングデスク」なるものも増えていますよね。長時間座っているということは、人間の身体には良くないことなのでしょう。

https://www.amazon.co.jp/dp/B08PF2Z9QD?ref_=cm_sw_r_cp_ud_dp_CDZ66HC9XS6TBDZAE1PB

**デスクワークに付きものなのが、ストレートネック、腰痛です。**
座ってパソコンを見続けていると、どうしても首と背骨はストレートになっていきます。
背骨は、緩やかなカーブ状だから、身体や重いものを支えられます。

1ヶ月ほど仕事をしていると、身体は想像以上にストレートになっているので、整体で整えると良いですよ。
数ヶ月、数年溜めて、ぎっくり腰になる時には「時すでに遅し」です。

### 良いものを食べる

身体を作るのは、日々の生活で食べているものです。
なので、「身体に良いものを食べること」
これ大事です。

そして、**さらに大事なのは、身体に悪いものは食べないこと**です。
夜中のカップラーメンはアウトです（笑）
あなたが毎日食べている・飲んでいるものは、身体に良いものですか？

https://www.amazon.co.jp/dp/4479307605?ref_=cm_sw_r_cp_ud_dp_2MVQVMJM4BJ7EYDYZQWB

### さいごに

こちらの本は、科学的に健康と幸せについて書いていて分かりやすかったので、オススメです。

https://www.amazon.co.jp/dp/B08Z328ND5?ref_=cm_sw_r_cp_ud_dp_E8QPY8VWY0CGA9AMMB2B
PG16:Error for row-level triggers with transition tables on partitioned tables

# はじめに
にゃーん。趣味でポスグレをやっている者だ。

この記事は[PostgreSQL 16 全部ぬこ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/pg16-all-nuko) 19日目の記事です。
今回はパーティションテーブル＆トリガに関するエラーメッセージの改善という小ネタについて書きます。

# 概要

|項目|内容|
|:--|:--|
|タイトル|[Error for row-level triggers with transition tables on partitioned tables](https://commitfest.postgresql.org/40/3981/)|
|Topic|Bug Fixes|
|ステータス|commited|
|Last Modified|2022-11-04|
|概要|パーティションテーブルに対して行レベルトリガを使おうとしたときのエラーメッセージの改善|

# 変更内容
この変更は、パーティションテーブル（``type=partitioned table``）のテーブルに対して、行トリガを設定しようとしたときのエラーメッセージの改善です。

## PostgreSQL 15.0/15.1

```sql
=# create table parted_trig (a int) partition by list (a);
CREATE TABLE
=# create function trigger_nothing() returns trigger language plpgsql as
=# $$ begin end; $$;
CREATE FUNCTION
=# create trigger failed after update on parted_trig referencing old
=# table as old_table for each row execute procedure trigger_nothing();
ERROR:  "parted_trig" is a partitioned table
DETAIL:  Triggers on partitioned tables cannot have transition tables.
=#
```
エラーメッセージ詳細の文言は「パーティション化されたテーブルのトリガーは、トランジションテーブルを持つことができない」という意味になっています。

しかし実際には、行レベルトリガではなくステートメントレベルトリガであればパーティションテーブルであっても設定は可能です。

```sql
=# create trigger failed after update on parted_trig referencing old
table as old_table for statement execute procedure trigger_nothing();
CREATE TRIGGER
=#
```
なので、行レベルトリガ作成時のエラーメッセージ詳細は不正確では？というのが問題のようです。


## PostgreSQL 16

```sql
=# create table parted_trig (a int) partition by list (a);
CREATE TABLE
=# create function trigger_nothing() returns trigger language plpgsql as
$$ begin end; $$;
CREATE FUNCTION
=# create trigger failed after update on parted_trig referencing old
table as old_table for each row execute procedure trigger_nothing();
ERROR:  "parted_trig" is a partitioned table
DETAIL:  ROW triggers with transition tables are not supported on partitioned tables.
=#
```

PostgreSQL 16ではパーティションテーブルに対して行トリガを作成しようとしたときのメッセージ詳細が「トランジションテーブルを使用する ROW トリガーは、パーティションされたテーブルではサポートされていない」といった意味に変更されました。

# おわりに
今回の記事で取り上げたのは、ささやかな修正ですが、こういう誤解を招かないメッセージの修正というのも使い勝手の向上という意味では大事ですよね。
【Playdate】外部クラスを扱う

これまでmain.luaに色々と記述してきましたが、利用するオブジェクトを外部クラスに切り分けてみます。
[前回のコライダーを埋め込むプロジェクト](https://qiita.com/sada_lp1/items/dd85039b606dd683c78a)のwallオブジェクトを切り出します。
まず、`wall.lua`を`source`ディレクトリに新規作成します。

```wall.lua
local gfx <const> = playdate.graphics

class('Wall').extends(gfx.sprite)

function Wall:init(x, y, w, h)
	Wall.super.init(self)
	local wallImage = gfx.image.new(w, h)
	gfx.pushContext(wallImage)
		gfx.setColor(gfx.kColorWhite)
		gfx.fillRect(0, 0, w, h)
	gfx.popContext()
	self:setImage(wallImage)
	self:moveTo(x, y)
	self:setCollideRect(0, 0, self:getSize())
end
```

`class('Wall').extends(gfx.sprite)`で`sprite`を継承した`Wall`クラスを作成しています。
更にコンストラクタ関数`:init`で`Wall`クラスの初期化を行います。
`Wall.super.init(self)`で基底クラスのコンストラクタをオーバーライドし、前回記述のコードを移植しています。
前回コードでは`wallSprite`に画像セットしたりなどしていましたが、`self`に書き直します。

上記設定後、`wall.lua`を`main.lua`に読み込みます。

```main.lua
import "CoreLibs/object"
import "CoreLibs/graphics"
import "CoreLibs/sprites"
import "CoreLibs/timer"

import "wall" -- wall.luaを読み込み

local gfx <const> = playdate.graphics

local playerSprite = nil
local wallSprite = nil

function myGameSetUp()

	local playerImage = gfx.image.new("Images/playerImage")
	assert( playerImage )

	playerSprite = gfx.sprite.new( playerImage )
	playerSprite:moveTo( 200, 120 )
	playerSprite:setCollideRect(0, 0, playerSprite:getSize()) -- playerSpriteにコライダーセット
	playerSprite.collisionResponse = playdate.graphics.sprite.kCollisionTypeBounce -- コライダーとぶつかったときのふるまい
	playerSprite:add()
	
	wallSprite = Wall(300, 120, 20, 80) -- Wallオブジェクト新規作成
	wallSprite:add() -- ゲーム内に追加

	local backgroundImage = gfx.image.new( "Images/background" )
	assert( backgroundImage )

	gfx.sprite.setBackgroundDrawingCallback(
		function( x, y, width, height )
			backgroundImage:draw( 0, 0 )
		end
	)

end

-- 略　--
```

`import "wall"`でsource直下に配置した`wall.lua`を読み込みます。
更に`myGameSetUp()`で壁を生成していたコードを削除、`wallSprite = Wall(300, 120, 20, 80)`で壁オブジェクトを新規作成しています。
あとは`wallSprite:add()`でゲーム内に追加します。
空間と時間

数理最適化設計で空間と時間について考える。　

時間と空間　エルンスト・マッハ＜エンジニア夏休み企画＞ 【読書感想文】

https://qiita.com/kaizen_nagoya/items/f178c9ac8199996694f3

何を測定するとよいか

https://qiita.com/kaizen_nagoya/items/98a942e4755896a1d3a4

プログラマが知っているとよい設計指針（4）STARC RTL 設計スタイルガイド　

https://qiita.com/kaizen_nagoya/items/7a3298801259409bd1b9

俯瞰的考え気づく客観が存在しない空集合と

https://qiita.com/kaizen_nagoya/items/d541d448c017fc63c817

連続と離散、時間と空間、物理量と生物量。統計と確率(2)

https://qiita.com/kaizen_nagoya/items/d0980c6bf9d3079aa98d

最初に試験(test)プログラムを書く理由5つ。仮説（135）

https://qiita.com/kaizen_nagoya/items/c41e016df1a46cca7192

安全分析（HAZOP）の際の声かけ。安全（２０）

https://qiita.com/kaizen_nagoya/items/381649a6ea025ecba173

自然言語処理で陥る罠。仮説（149）

https://qiita.com/kaizen_nagoya/items/71093310ffc5324f15ff

すべての技術者に伝えたいこと。仮説（117）

https://qiita.com/kaizen_nagoya/items/411073412b0d3676821c

安全性の考え方　武谷三男　

https://qiita.com/kaizen_nagoya/items/d7f004099dabf5d475b7

服飾デザイナ、ネットワークデザイナ、Webデザイナ

https://qiita.com/kaizen_nagoya/items/4a54ef0ca16dba466d6f

Wireshark インフラエンジニアの玉手箱

https://qiita.com/kaizen_nagoya/items/edc19705677f46ad461d

# 参考文献　

【無限時空】時間・空間・速度・加速の概念が根底から異なる世界の話

https://qiita.com/ikiuo/items/19fd32723deff1a0e916

### 最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

#### Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.
Quest2,Proのパススルー設定

今更ですが自分用にメモを残したくなったので。

## 環境
* Windows10
* Unity 2021.3.15f1
* Oculus Integration v46.0
* Meta Quest2,Pro

## XR Plug-in Management
Android、PCともにOculusを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30693/99cf6fdb-bb58-f9ff-27c4-2e9e25dd6f88.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30693/32746b01-36d5-60b7-fd13-35f0820feff4.png)

## Oculusメニュー
"Set OVRPlugin to OpenXR" を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30693/45147d88-0198-58c1-b62a-8c7c801c9130.png)

## OVR Passthrough Layer
OVRCameraRigに "OVR Passthrough Layer" をAdd Component
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30693/32f2d7a2-eda3-c773-f11d-e17f1acebdc5.png)

## OVR Manager
"Passthrough Capability Enabled" と "Enable Passthrough" を有効に
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30693/efd8a58b-728a-4c39-367c-8c574ec03adb.png)

なお "enableMixedReality" を有効にすると
```Screen position out of view frustum (screen pos 0.000000, 0.000000, 1000.000000) (Camera rect 0 0 912 1840)```
とエラーがでてカメラが正しく動作しなくなるようなので注意
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30693/881894d7-7177-af25-1016-b51969352b94.png)

以上
CTO興味ある人へ：CTOの業務についてその４　チームビルディング/キャリア戦略

CTOを長年やってるとよく聞かれる質問です。
```
CTOの仕事ってどんな仕事があるんですか？
```
から始まった**CTOの業務について**のその４です。

# チームビルディング
最も大きいタスクのうちの一つです。チームメンバーが居ないと仕事は始まりません。チームビルディングが上手く出来ればCTOのタスクの半分くらい終わった感じではないでしょうか。ただこのタスクのボリュームが大きいです。
採用、評価制度の次は、**キャリア戦略**

**キャリア戦略**は、とても大事な仕事です。これがしっかりと出来ると１年後２年後の組織の状態は全く違ってくるでしょう。ただ、メンバー全員一人ひとりの戦略を考えるため、めちゃくちゃ時間も必要となります。ここは無理をしてでもCTO自らが旗振りをしてマネージャーを巻き込んで設定していく必要があります。
メンバーが育ってない、体制が足りてないと悩んでるCTO、VPoEの皆さん、ここを２年前にやってなかったあなた達の責任です！！未来のために今日からでも取り組んで下さい！！

## キャリア戦略
先ず最初に会社内のエンジニア組織としてあるべき姿をイメージします。そうすると足りない部分、弱い部分が見えてくると思います。そこを強化していくためにエンジニア一人ひとりのキャリア戦略をトップダウンで考えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/23130/2978cab4-847e-09ce-9302-56afc4f607a9.png)
その後、エンジニア毎のキャリア戦略をボトムアップで考えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/23130/b843bf46-bacb-387d-f741-5f7e3059c829.png)
トップダウンとボトムアップの２つをマージして個別のキャリア戦略に落とし込むんで行きます。

## PPM分析
PPM分析とはマーケティングで使われる分析手法で、「市場成長率」と「市場占有率（マーケットシェア）」の2軸からなる座標に事業や製品・サービスを分類し、経営資源の投資配分を判断するための方法で、戦略として自社および競合他社の事業の立ち位置を確認することに役立ちます。
これを人財育成・キャリア戦略に適用させます。縦軸に評価・給与、横軸に成長率・市場価値として分類します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/23130/4b676b4b-d990-7db4-3529-2ed220531660.png)
- 問題児
若手に多いのでスキルや人間力成長のためのPJアサインや適切なリーダとマッチングさせる
- 花形
組織にとって大事な優秀なメンバー、どんどん成長のチャンスを与えて報酬も与える
- 金のなる木
中堅、シニアのメインエンジニア。適切なPJにアサインしパフォーマンスの最大化を図る。　
- 負け犬
シニアに多い。スキルのセグメントが狭いのでジェネラリストにすべく働きかける。負け犬から花形へ持っていく。
　
これをベースにしっかりと個別のキャリア戦略を実行する事で、問題児を金のなる木にへ、負け犬から花形へ変化してもらいます。

# まとめ
エンジニアの一人ひとりのキャリア戦略を描いてない会社もあるのでは無いでしょうか？
個々人のキャリアをしっかり描き、面談でもそこをしっかりと話合う事により成長の速度も変わってきます。時間は掛かりますが、最も楽しみなタスクの一つだと思います。子供の成長と同じく、エンジニアメンバーが成長していくのは、とても喜ばしい事です。人にとって、すぐに成長する人もいれば、最初は不器用だけど要領を得れば一気に成長するメンバーもいます。是非、じっくりと時間を掛けてあげて下さい。
ひき続き記事を書いていきますので、フォロー、イイねお願いします！

# シリーズ記事まとめ
CTO興味ある人へ：CTOの業務についてその１　会社組織内での話
https://qiita.com/k1morikawa@github/items/5e9022a99a51d9a57576
CTO興味ある人へ：CTOの業務についてその２　チームビルディング/採用
https://qiita.com/k1morikawa@github/items/b2b3fb2246bd0984bab1
CTO興味ある人へ：CTOの業務についてその３　チームビルディング/評価制度
https://qiita.com/k1morikawa@github/items/edb2e3c20ce02a201eec
Railsのカスタムバリデーションとたたかう

# たたかう
　データの形式や数値について、制約を設けることをバリデーションという。Railsにはあるていど整ったバリデーションがあり、上手に使うことで簡単にいろいろできる。

https://railsguides.jp/active_record_validations.html

　以下は私のアプリの`Report`モデルの記述だが、このようにcontentの文字数の最大値を設定したり、空白の場合はエラーとなるようにしている。

```ruby:app/models/report.rb
#　略
  validates :content, length: { maximum: 200 }, presence: true
```

　ただ、細かいところを詰めようとすると、どうしても既存の表現ではうまくいかないところが出てくる。そうなったらつくるしかない。

　カスタムメソッドの登場だ。

# カスタムメソッド
### 1. 過去の日付はNG

　例えば、「目標の締め切りは現在より過去の日付はNG」としたいなら、以下のように入力する。

```ruby:app/models/plan.rb
class Plan < ApplicationRecord
# 略
  validates :deadline, presence: true
  validate :deadline_cannot_set_in_past

# 略

  def deadline_cannot_set_in_past
    if status == "進行中" && (deadline.present? && deadline < Date.today)
        errors.add(:deadline, ":ステータスが「進行中」の場合、過去の日付は使えません") 
    end
  end
end
```

 validateにメソッド名を書いておき、紐づけるイメージだろうか。わりあいわかりやすい。

　Railsガイドにも同様の記述がある。


https://railsguides.jp/active_record_validations.html#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89

### 2. 条件を満たすデータの総数の制約

　次に、「進行中の目標の個数は3個まで」を設定した。これはアプリを使っていく上で、振り返りながら目標の状態を変更する流れがある。ただ、同時に進行中にできる目標は制限がないといけないので、制約を設けることにした。
　（振り返りの記述の際に、すこし面倒なのだ）

　それは以下のようになる。

```ruby:app/models/plan.rb
class Plan < ApplicationRecord
 
# 略
  validate :progress_total_count_cannot_set_exceeded_limit
# 略
  PROGRESS_MAX_COUNT = 3
  def progress_total_count_cannot_set_exceeded_limit
    count_in_progress = user.plans.where(status: "進行中").count
    if count_in_progress > PROGRESS_MAX_COUNT
      errors.add(:status, ":「進行中」の目標の数は、3個までです") 
    end
  end
end
```

　ログイン中のユーザについて、進行中となっている目標の個数を出してくる。それだけ。オーバーならエラーが出るようにした。


### 3. 条件を満たすデータの変更禁止

　最後に、「完了となった目標はもういじっちゃだめ」という制約をつくった。これはすでに完了した目標は締め切りが過ぎているため、
「名前だけでも変更しよう...」
とすると、
「締め切りが現在より以前ですだめ！」
と怒られるためである。

　やっていく。

```ruby:app/models/plan.rb
class Plan < ApplicationRecord
#略
  validate :cannot_edit_on_complete, on: :update
#略
  def cannot_edit_on_complete
    if status == "完了" && (deadline_changed? || name_changed?)
      errors.add(:deadline, ":完了状態で締め切りは変更できません") 
    end
  end
end
```

　`on: :update`をつけることで、更新の時のみバリデーションが効くようにしている。また、`_changed?`をつけることで、属性が変更したかどうかを確認している。

https://api.rubyonrails.org/classes/ActiveModel/Dirty.html


# テストもがんばっていくけど。。。

　バリデーションをつくったらテストも書かないといけないのだが、テストってぜんぜんわからん。これは来年やっていこう。
OSM Djibouti vector tile build in 3 minutes

# About this document
This is a log of building OSM Djibouti vector tiles based on a great entry by yuiseki at [3分のブラウザ操作で、いますぐ無料でベクトルタイル地図をBuild, Deploy, Hostingしよう](https://qiita.com/yuiseki/items/05ef7f4a8f7fc6e5a9bf). 

# Identify the source data
By googling "geofabrik djibouti", I identified https://download.geofabrik.de/africa/djibouti.html as the source data location.

# Create a Github repository
I created https://github.com/optgeo/vector-tile-djibouti using https://github.com/yuiseki/vector-tile-builder as the template.

# Edit the `.env` file
I edited https://github.com/optgeo/vector-tile-djibouti/blob/main/.env updating europe/andorra to africa/djibouti.

# Enable GitHub Pages from `gh-pages` branch.
Enabled at https://github.com/optgeo/vector-tile-djibouti/settings/pages.

# The site is ready after waiting a few minutes.
The site is at https://optgeo.github.io/vector-tile-djibouti/.
Angular Felx-Layoutが開発終了してしまうので、書き換えなどをまとめておく

angular14系のアップデートを行った際、warningでAngular Flex-Layoutが開発終了することを知ったので簡単にまとめてみます。
# 概要
- 長らくBeta版だったAngular Flex-Layoutが開発終了するらしいです。
  - [開発終了の報告](https://blog.angular.io/modern-css-in-angular-layouts-4a259dca9127)
  - 開発者の方（CaerusKaruさん）が15系のバージョンはリリースすると[こちらのissues](https://github.com/angular/flex-layout/issues/1430#issuecomment-1321320073)でも言及されています。
- [公式のissuesに移行ガイド](https://github.com/angular/flex-layout/issues/1426)があります。
- 以前から開発に関わっていた[有志の方](https://github.com/angular/flex-layout/issues/1426#issuecomment-1335928126)が、場合によっては開発を引き継ぐと表明してくださっています！今後どうなるかはわからないですが…

乗り換え先としてtailwindなどの選択肢もありますが、今回は簡単にSassで置き換えることにします。適宜読み替えていただけると幸いです。
>tailwindに乗り換えたい場合は、[この日本語の記事](https://tech.every.tv/entry/2021/11/16/172603)が参考になるかと思います。

:::note warn
追記
[移行ガイド内](https://github.com/angular/flex-layout/issues/1426#issuecomment-1342706122)で有志の方がcssに置き換える例をかなり追加してくれていました。こちらを参考にすると大方はcssに置き換えられると思います！
:::

# 実装
Sassの記述をAngular.jsonでグローバル設定したsrc/styles.sass、あるいは各ディレクトリ内のSassに追記していきます。
後はAngular Flex-Layoutで記述していたhtmlなどのclassを置き換えるだけです。

例
```Sass
.test
  display: flex
  flex-direction: column
  align-content: center
  align-items: end
  column-gap: 2vh
```
```html
<!-- angular Flex-Layout -->
<div class="common" fxLayout="column" fxLayoutAlign="center end" fxLayoutGap="2vh">

<!-- testクラスを利用した書き換え -->
<div class="test">

```

以下はflex-layoutで主に利用する例です。組み合わせたらいい感じになると思います。
```SASS
.flex-row
   display: flex
   flex-direction: row

.flex-col
   display: flex
   flex-direction: column

.flex-row-wrap
   display: flex
   flex-direction: row
   flex-wrap: wrap

.flex-col-wrap
   display: flex
   flex-direction: column
   flex-wrap: wrap
 
.fxFlex
  flex: 1

.flex-grow
  flex-grow: 1

.flex-initial
  flex: initial

.flex-layout
  justify-content: flex-start

.flex-layout-space-between
  justify-content: space-between
  
.flex-layout-justify-center
  justify-content: center

.flex-layout-center
  align-items: center

.flex-layout-space-around
  justify-content: space-around

.flex-layout-start-center
  justify-content: flex-start
  align-items: center

.flex-layout-space-between-center
  justify-content: space-between
  align-items: center
  
.flex-layout-stretch
  align-content: stretch
  align-items: stretch

.flex-layout-row-gap
  row-gap: 1.5em

.flex-layout-column-gap
  column-gap: 1.5em

```

参考
[[Angular8]サイトを簡単スタイリング！Angular Flex-Layoutの使い方をまとめてみた \| DevelopersIO](https://dev.classmethod.jp/articles/angular-flex-layout/#toc-10)

[フレックスコンテナー内のアイテムの配置 - CSS: カスケーディングスタイルシート \| MDN](https://developer.mozilla.org/ja/docs/Web/CSS/CSS_Flexible_Box_Layout/Aligning_Items_in_a_Flex_Container)
【エラー解決】Ruby on Rails いいね機能 〜まさかそこ！？ってなる落とし穴を解決する方法〜

# はじめに
Ruby on Railsを使っていいね機能を実装しているが、教材や記事通り実装しても謎のエラーに苦しめられる・・・という経験をしたことがある人を何度も目にしてきました。

今回がそういった人に向けて、よく見落とされがちなエラー解決の方法を伝授します！

# エラー
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1081227/da3c7de6-fa50-af17-1759-2981f97097c7.png)

# 解決方法
ルートもコントローラーの記述も全部あっているはずなのに上記のようにNo route matches と怒られる方は一度viewページを確認してみてください！
いいねボタンがlink_toになっていませんか？？？
```rb:index.html.erb(変更前)
<% if @post.favorite?(current_user) %>
    <%= link_to post_favorite_path(@post.id), method: :delete do %>
        <span style="color:red;">❤︎</span>
    <% end %>
<% else %>
    <%= link_to post_favorites_path(@post.id), method: :post do %>
        <span>❤︎</span>
    <% end %>
<% end %>
```

link_toメソッドのHTTPメソッドには、GETがデフォルトで指定されています。

そこで、いいね機能をpostアクションといいね削除をdeleteアクションにするために、link_toメソッド内で、method: :postとmethod: :deleteとしてHTTP通信の種類を指定する必要があります。

##### しかし！！！
このメソッドを指定してもなお、HTTPメソッドがGETのままになることがしばしばあります。。。

そこで、link_toで記述したいいね機能を、デフォルトがpostメソッドであるbutton_toに書き換えてみてください！

```rb:index.html.erb(変更後)
<% if @post.favorite?(current_user) %>
    <%= button_to post_favorite_path(@post.id), method: :delete do %>
        <span style="color:red;">❤︎</span>
    <% end %>
<% else %>
    <%= button_to post_favorites_path(@post.id), method: :post do %>
        <span>❤︎</span>
    <% end %>
<% end %>
```

これで多くは解決するはずです！

# 最後に
いかがでしたでしょうか？
まさかこんなところ！？と思う方も多かったのではないでしょうか。
少しでも多くの人の開発の助けとなっていれば幸いです！
ご精読ありがとうございました！
2022/12/13主にITとかセキュリティの記事

Cisco製IP電話に脆弱性、PoCが公開済み - パッチは来年公開予定
https://www.security-next.com/142090

サイバー防衛で法整備、平時から攻撃元監視　防衛3文書(12/11)
https://www.nikkei.com/article/DGXZQOUA1029P0Q2A211C2000000/

徳丸本2版の実習環境をDockerに移植した話(12/9)
https://qiita.com/ockeghem/items/d38478c242f9d2f639d7

フィッシングサイトはレベルの高い偽物が増加、だまされないよう注意を(12/11)
https://news.mynavi.jp/techplus/article/20221211-2532194/

4年ぶりの「Windows」説明会からおさらいするPC買い替えタイミング - 阿久津良和のWindows Weekly Report(12/11)
https://news.mynavi.jp/article/20221211-windows_report/

Windowsのサポートいつまで？　11への更新は早めに(12/11)
https://www.nikkei.com/article/DGXZQOUC298U90Z21C22A1000000/

楽天グループが「オンプレ回帰」を決断、パブリッククラウドからIT基盤を戻す狙い(12/12)
https://xtech.nikkei.com/atcl/nxt/column/18/00001/07478/

尼崎市「泥酔USB紛失事件」のてんまつ、こんなひどい報告書を読んだのは初めてだ(12/12)
https://xtech.nikkei.com/atcl/nxt/column/18/00148/120800261/

公式ストア以外でスマホアプリを配布、「サイドローディング」とは(12/12)
https://xtech.nikkei.com/atcl/nxt/column/18/01679/110200084/
LaTeXで最適化問題を記述するためのパッケージ"Optidef"

## はじめに

LaTeXで最適化問題を記述する時に，[Optidef](https://github.com/jeslago/optidef)というパッケージが便利です．

できることは
- 簡単に最適化問題を書ける
- 問題番号（数字）と式番号（アルファベット）を付けれる
- min max問題も簡単に書ける（styファイルのダウンロードが必要）

などです．

## 例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178972/e9e418f3-ed1c-c882-9408-91febb87b234.png)

```LaTeX
\begin{mini!}
    {w,x}          % 決定変数
    {f(w)+ R(w+6x) \label{eq:prb-obj}} % 目的関数
    {\label{prb}}  % 問題のラベル
    {J(w^*, x^*)=} % minの左側
    \addConstraint{g(w)}{=0  \label{eq:constr1}} % 1つ目の制約
    \addConstraint{n(w)}{= 6 \label{eq:constr2}} % 2つ目の制約
    \addConstraint{L(w)}{=Kw \label{eq:constr3}} % 3つ目の制約
    \addConstraint{h(x)}{=0. \label{eq:constr4}} % 4つ目の制約
\end{mini!}
```

## 使うには

プリアンブルに
```LaTeX
\usepackage{optidef}
```
と記述すると，使うことができます．Overleafでも使用できることは確認済みです．

## 他の記述方法

- 最適化問題一つに対して，一つの参照（式番号）にするには

    -> ```mini!```を```mini```に書き換える

- 参照（式番号）を無くすには

    -> ```mini!```を```mini*```に書き換える．

- minimize を min，subject to を s.t. にするには

    -> ```\begin{mini!}```の後に```|s|```を付け足す．

- minimize を argmin にするには

    -> ```mini!```を```argmini!```に書き換える．

- ページをまたいで記述するには

    -> ```\begin{mini!}```の後に```<b>```を付け足す
        （mini環境での問題へのラベル付けは\labelOP{}を使用）

- 最適化問題中のカンマを全て無くすには

    -> ```\usepackage[nocomma]{optidef}```

他にも，制約の揃え方についてのオプションなどを指定できます．

## より新しい機能

[Github](https://github.com/jeslago/optidef)からoptidef.styをダウンロードして，プロジェクト内に置くと最新の機能を使うことができます．

例えば，customopti環境を使えば，min や argmin の部分を，"inf" や "min max" に置き換えることができます．

### inf

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178972/6f0722cb-b86a-4701-0f08-433432d26da5.png)

```LaTeX
\begin{customopti!}|s|
    {inf}          % minimize の代わり
    {w,x}          % 決定変数
    {f(w)+ R(w+6x) \label{eq:prb-obj}} % 目的関数
    {\label{prb}}  % 問題のラベル
    {J(w^*, x^*)=} % minの左側
    \addConstraint{g(w)}{=0  \label{eq:constr1}} % 1つ目の制約
    \addConstraint{n(w)}{= 6 \label{eq:constr2}} % 2つ目の制約
    \addConstraint{L(w)}{=Kw \label{eq:constr3}} % 3つ目の制約
    \addConstraint{h(x)}{=0. \label{eq:constr4}} % 4つ目の制約
\end{customopti!}
```

### min max 

min max の場合は，決定変数の部分は空欄にして，「minimize の代わり」の部分に自分で記入します．

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178972/466349e1-c281-61f3-16c1-206772567441.png)

```LaTeX
\begin{customopti!}
    {\underset{\displaystyle \mathit{w}}{max}\quad\underset{\displaystyle \mathit{x}}{min}} % minimize の代わり
    {}             % 決定変数
    {f(w)+ R(w+6x) \label{eq:prb-obj}} % 目的関数
    {\label{prb}}  % 問題のラベル
    {J(w^*, x^*)=} % minの左側
    \addConstraint{g(w)}{=0  \label{eq:constr1}} % 1つ目の制約
    \addConstraint{n(w)}{= 6 \label{eq:constr2}} % 2つ目の制約
    \addConstraint{L(w)}{=Kw \label{eq:constr3}} % 3つ目の制約
    \addConstraint{h(x)}{=0. \label{eq:constr4}} % 4つ目の制約
\end{customopti!}
```


## 参考

[optidef – Environments for writing optimization problems](https://www.ctan.org/pkg/optidef)
[Package documentation](https://ftp.yz.yamagata-u.ac.jp/pub/CTAN/macros/latex/contrib/optidef/optidef.pdf)
[Issues: Personalized environments](https://github.com/jeslago/optidef/issues/39)
【コピペ用】スプレッドシート Query関数のよく使う書き方メモ

# はじめに
よく業務でスプレッドシートを使ってQuery関数を書くことがあるが、書き方をなかなか覚えられない・・・というか覚えることを諦めたためコピペでつかえるようによく使う記述をメモしました！
# Query関数

### select文とwhere文
```
=query('シート名'!$A:$Z,"select A,B,C where A='あいうえお'")
```

### 複数条件
```
かつ
=query('シート名'!$A:$Z,"select A,B,C where A='あいうえお' and B='かきくけこ'")
または
=query('シート名'!$A:$Z,"select A,B,C where A='あいうえお' or B='かきくけこ'")
```

### 条件不一致
```
=query('シート名'!$A:$Z,"select A,B,C where A<>'あいうえお'")
=query('シート名'!$A:$Z,"select A,B,C where not A='あいうえお'")
```
### 日付関連
```
いつから
=query('シート名'!$A:$Z,"select A,B,C where A>=date'2022-12-12'")
いつからいつまで
=query('シート名'!$A:$Z,"select A,B,C where A>=date'2022-01-01' and A<=date'2023-12-31'")
```

### 縦結合
```
=query({$A$1:$A$10;$A$15:$A$24},"select*")
```
### 横結合
```
=query({$A$1:$C$10,$C$15:$H$24},"select*")
```

### Importrange

```
=query(importrange("スプシid","シート名!$A:$Z"),"select Col1, Col2, Col3 where Col1='あいうえお'")
```

 <details> <summary>アルファベットの列番号</summary>

| 列番号 | アルファベット |
|:-:|:-:|
|   1|   A|
|   2|   B|
|   3|   C|
|   4|   D|
|   5|   E|
|   6|   F|
|   7|   G|
|   8|   H|
|   9|   I|
|   10|   J|
|   11|   K|
|   12|   L|
|   13|   M|
|   14|   N|
|   15|   O|
|   16|   P|
|   17|   Q|
|   18|   R|
|   19|   S|
|   20|   T|
|   21|   U|
|   22|   V|
|   23|   W|
|   24|   X|
|   25|   Y|
|   26|   Z|
|   AA以降|  +26 |
</details>

# 最後に
こちらの記事は完全コピーしていただいて構いません！
ご自身のよく使う関数のメモを作成するのに使ってみたりしてみてください^^
ご精読ありがとうございました！