OmniAICreator/Qiita-1.07M huggingface dataset:
python timecode to frame

```python
framerate = 60

def _seconds(value):
    if isinstance(value, str):  # value seems to be a timestamp
        _zip_ft = zip((3600, 60, 1, 1/framerate), value.split(':'))
        return sum(f * float(t) for f,t in _zip_ft)
    elif isinstance(value, (int, float)):  # frames
        return value / framerate
    else:
        return 0

def _timecode(seconds):
    return '{h:02f}:{m:02f}:{s:02f}:{f:02f}'.format(h=int(seconds/3600),m=int(seconds/60%60),s=int(seconds%60),f=round((seconds-int(seconds))*framerate))

def _frames(seconds):
    return seconds * framerate

def timecode_to_frames(timecode, start=None):
    return _frames(_seconds(timecode) - _seconds(start))

def frames_to_timecode(frames, start=None):
    return _timecode(_seconds(frames) + _seconds(start))
```
Ajax通信が全て完了したことをトリガーにして処理を呼び出したい

## 背景
Laravelのフラッシュデータを使うと、そのリクエスト間だけセッションにデータを保持できますが
これをAjax通信などで利用すると、他のXHRが干渉してフラッシュデータが破棄されてしまう可能性があります。

回避策としてLaravelは`reflash()`や`keep()`という機能を提供していますが、制約的に実現が難しかったので
「Ajax通信が全て終わってからリクエストできるようにすればいいんじゃないか？」と思い調べた結果を共有します。

## どうやるか
```JavaScript
((open) => {
    const openedXhr = [];
    XMLHttpRequest.prototype.open = function (method, url, async, user, pass) {
        this.addEventListener('readystatechange', () => {
            switch (this.readyState) {
                case 1: // OPENED
                    openedXhr.push(this);
                    break;
                case 4: // DONE
                    const i = openedXhr.indexOf(this);
                    if (i > -1)
                        openedXhr.splice(i, 1);
                    if (!openedXhr.length)
                        // フラッシュデータを使うAPIを叩く
                        break;
            }
        });
        open.call(this, method, url, async, user, pass);
    };
})(XMLHttpRequest.prototype.open);
```

Ajaxで使われる`XMLHttpRequest.prototype.open`をインターセプトして`readystatechange`を監視します。
ステータスが全て`DONE`になったら全てのXHRが完了していることを保証できるため、フラッシュデータを使う処理を実行します。
今回のようなユースケースに限らず、Ajax通信が全て完了したことをトリガーにした処理を実装したい時に使えると思います。

なおこの即時関数が呼び出される前に実行されたXHRは当然制御できませんが、ユーザーが内部APIをコールするようなアクションを制御したいユースケースであればある程度は制御可能かと思います。

他の懸念点としては
 - 例えば１件目のXHRが２件目を監視する前にDONEになるとAPIが呼ばれてしまう
 - XHRの件数が多いとユーザーを待たせる可能性もある
 - 一定間隔でAjax通信しているようなケースだと更に制御が必要になったりする

などいろいろあります（参考程度にお読みいただければ幸いです）。

## 備考
この記事は以前Stack Overflowで見かけた内容を元にしているのですが、記事を見失ったためメモ代わりに投稿しました...
Oreillyの資料が行方不明

なぜdockerでpython/Rを使って機械学習するか 書籍・ソース一覧作成中 (目標100) docker(18)

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

の続きで、本を紹介しようと思った。　

過去の記事の資料がリンク切れになっているだけでなく、　
書籍のプログラムがどこで公開しているかの関係がつかめなくなっていた。　

ちょっと資料を捜索して、みつかったものから順に追記します。　

ごめんなさい。

20221225追記　

日本語の本は、　

https://www.oreilly.co.jp/catalog/

にあることがわかりました。ありがとうございます。　

英語の本がまださがせていません。　

ごめんなさい。　

arXivの論文もいくつか読んでいます。　

そちらの資料は順次掲載予定です。

<この項は書きかけです。順次追記します。>



# 参考資料　

英語(18) 英語文献を入手したら

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

arxivの論文はwgetで入手できないか

https://qiita.com/kaizen_nagoya/items/1f2b27f606058cc84ad2


citeseerxで検索する時に気をつけている18項目

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

深層学習五十論文 by 綿岡晃輝 単語帳(shell, awk), 英語(25) docker(101)

https://qiita.com/kaizen_nagoya/items/670d4d332e07fd2e5fc2

ポアンカレ予想のペレルマン論文を読む

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



# Countdown Calendar 2022

今年企画した6つのCountdown Calendarと、それぞれの記事一つをご紹介します。

AUTOSAR Countdown Calendar 2022

https://qiita.com/advent-calendar/2022/autosar

AUTOSAR References to ISO, IEC, ITU, IEEE, RFC and SEA etc.

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

Automotive Handbook Countdown Calendar 2022

https://qiita.com/advent-calendar/2022/automotivehandbook

Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>

https://qiita.com/kaizen_nagoya/items/24a1ba5da3d09b2a95d1


2022 いいねをいただいた記事ランキング(O.K.版) Countdown Calendar 2022

https://qiita.com/advent-calendar/2022/goods

2022年１月下旬　いいねをいただいた記事　16

https://qiita.com/kaizen_nagoya/items/0ee589a8edaeab24fd2a

AdCale(O.K.) Countdown Calendar 2022

https://qiita.com/advent-calendar/2022/adventcalendar2022

「会議は15分未満」に。小耳にはさんだ話。

https://qiita.com/kaizen_nagoya/items/510c47c5d1e8d03145db

ABC language (O.K.版） Advent Calendar 2022

https://qiita.com/advent-calendar/2022/abc_ok

LLVMソースコードのコンパイルをしようと思ってハマった罠とそこから脱出するための努力

https://qiita.com/kaizen_nagoya/items/16f270e42b947756ced3

ABC maker(O.K版） Advent Calendar 2022

https://qiita.com/advent-calendar/2022/abcmaker

JAXA/IPA クリティカルソフトウェアワークショップ WOCS言語関連発表(改定版)

https://qiita.com/kaizen_nagoya/items/4789832baf494cb74626

CountdownCalendar2022 報告

https://qiita.com/kaizen_nagoya/items/5b4b99cb9ad571f4094b

誤差の評価が苦手（専門分野以外）

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

 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞


# 文書履歴(document history)
ver. 0.01 初稿 20221229
ver. 0.02 URL追記　20221231
ver. 0.03 ありがとう追記 20230620
### 最後までおよみいただきありがとうございました。

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

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

Please press the like icon 💚　and follow me for your happy life.
OCIのオブジェクトストレージの速度

先の記事は Cloudflare R2 のダウンロード速度を比較してみたのですが、
この記事では、OCIのオブジェクトストレージを測定してみます。

# OCI とは何ぞや

OCI は Oracle Cloud Infrastructure です。
その中には、AWS や GCP と同様にオブジェクトストレージがあります。
10GB は無料で、転送量も10TBまで無料らしいです。

実行環境：Windows10 WSL2 Ubuntu 20.04
テストファイル：その辺にあった go1.14.4.linux-amd64.tar.gz(117.98MB)を使いました。

## では、計測

```
# wget https://objectstorage.ap-tokyo-1.oraclecloud.com/p/6dHJLJH0kbjURF-a6wsbAiAZia_g947KDWpAPdx9wbeo6I5dl0vdmn83Bd6mli_U/n/nrtvpczsxdiz/b/download-test/o/go1.14.4.linux-amd64.tar.gz
--2022-12-1 19:43:37--  https://objectstorage.ap-tokyo-1.oraclecloud.com/p/6dHJLJH0kbjURF-a6wsbAiAZia_g947KDWpAPdx9wbeo6I5dl0vdmn83Bd6mli_U/n/nrtvpczsxdiz/b/download-test/o/go1.14.4.linux-amd64.tar.gz
Resolving objectstorage.ap-tokyo-1.oraclecloud.com (objectstorage.ap-tokyo-1.oraclecloud.com)... 134.70.80.3
Connecting to objectstorage.ap-tokyo-1.oraclecloud.com (objectstorage.ap-tokyo-1.oraclecloud.com)|134.70.80.3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 123711003 (118M) [application/x-gzip]
Saving to: ‘go1.14.4.linux-amd64.tar.gz.5’

go1.14.4.linux-amd64.tar.gz.5 100%[=================================================>] 117.98M  11.9MB/s    in 9.7s
```

んー先のS3よりは速いけど、それほど速くはない感じですね。

# まとめ

価格的にはGB単価（東京リージョン）では、下記のような感じです。

```
R2：$0.015/GB
Wasabi：$0.00699/GB（$6.99/TB）
S3：$0.025/GB
GCS：$0.023/GB
OCI：$0.0255/GB
```

OCIは大手の中では、一応安い範疇ではありますけど、スピードは微妙な感じですね。
そして、相変わらず管理画面は少しわかりづらい・・・

## 参照リンク

- [Cloudflare R2](https://www.cloudflare.com/ja-jp/products/r2/)
- [Wasabi](https://wasabi.com/)
- [AWS S3](https://aws.amazon.com/jp/s3/)
- [Google Cloud Storage](https://cloud.google.com/storage?hl=ja)
- [OCI Obejct Storage](https://www.oracle.com/jp/cloud/storage/object-storage/)
RSpecでのテクニックをpytestで実行するための逆引きメモ

# 背景

副業のプロダクト開発で、pytestを使ってユニットテストを書いています。
それまでRubyのRSpecでしか書いたことがなく、他の言語・フレームワークでのテストの書き方について戸惑った箇所があったので、今回は僕と同じようにRSpecを書いていた人がpytestを書くときに役立つような話を書きたいと思います。

https://rspec.info/

https://pytest.org/


# 知っておいてよかったこと
普段はRSpecでの書き方に慣れているため、pytestでのテストの書き方に最初は戸惑っていましたが、いくつかpytestでもRSpecでよく使う機能と同じことができることがわかりましたので、よくつかうものを紹介します。

## pytestでは`-k`オプションをつけることで、実行するテストを指定できる

まずはテストの実行時です。
RSpecでは、実行ファイルを指定した後に`:`を続けて実行する行数も指定することできます。

```
$ rspec spec/sample_spec.rb:12
```

pytestでは`-k`オプションをつけることで、実行するテストを指定することができます。
ただし、渡した文字列と完全一致ではなくて部分一致するテストが実行されるので、注意です。

```
$ pytest -k sample_test
```
とした場合には`sample_test`を含む`sample_test_1`や　`sample_test_2`という名前のテストが実行されます。


# fixtureでテスト前にモックやダミーデータの準備ができる

RSpecではbefore句を使うことでテスト前に実行したい処理を記述できます。

```ruby
before do
   # テスト前に実行したい処理
end
```

https://relishapp.com/rspec/rspec-core/v/2-0/docs/hooks/before-and-after-hooks

こちらはpytestではfixtureを使ってデータを用意したりします。

https://docs.pytest.org/en/6.2.x/fixture.html

下記で使い方を書いたので、もしご興味があればこちらも読んでいただければと思います。

https://qiita.com/isaka1022/items/f0f37f6e76c1ae9cec1a


# ダミーデータを用意するにはfactory_boyが使える

ダミーデータの用のために、僕はRSpecではfactorybotを用いて実現してきました。

```ruby
FactoryBot.define do
  factory :user do
    name { 'name' }
  end
end
```

https://github.com/thoughtbot/factory_bot_rails

これと同様のものを、pytestではfactoryboyを使って実現できます。

```python
import factory
from app.models import User

class UserFactory():
    class Meta:
        model = User
    name = 'name'
```

https://factoryboy.readthedocs.io/en/stable/


# `pdb.set_trace()`でデバッガを呼び出せる

テストの途中でコンソールを使ってデバッグを行いたいときなどにはRailsだと`binding.pry`などを使います。

```ruby
requre 'pry';binding.pry
```

pytestではどうする`pdb.set_trace()`を使うことができます。

```python
import pdb
pdb.set_trace()
```

また、実行時に`--pdb`オプションをつけてテスト実行すると、テストが失敗した際に自動的にデバッガを起動してくれるので便利です。

```
$ pytest --pdb sample_test
```



# 参考

https://qiita.com/sugarpot/items/53fbf92002781731efce

https://nwpct1.hatenablog.com/entry/python-pytest-tox-pdb
参考になる！タメになる！パワポデザイン術 おすすめアカウント3選

### 参考になる！タメになる！パワポデザイン術 おすすめアカウント集

この記事は ウェブクルー Advent Calendar 2022 20日目の記事です。
昨日は @kalzit  さんの「 Scalaユーザーが使うfp-ts 」でした。

### はじめに

今回、私が発信するテーマは「パワポデザイン術」についてです。
お取引先企業や社内に対する提案で、必ずと言ってよいほど必要になる資料ですが、
「パワポデザイン術」をおさえておけば、見られる・伝わる・感動する内容になるはずなんです。

提案の一押しになる、伝える内容の魅力がさらに輝く、
そんなタメになるパワポデザイン術の情報を発信しているおすすめアカウントを3つご紹介いたします。

# 参考になる！タメになる！パワポデザイン術 おすすめアカウント3選

### トヨマネ｜パワポ芸人 （@toyomane）様

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/913783/f5617447-c08f-9fc4-a245-cec9e690f2ed.png)

トヨマネさんは2021年9月にパワポ作りに関する本を出されるほど、
タメになる情報発信が豊富です。

トヨマネさん伝わるパワポ術は、新卒社員や大学生など、初心者でもわかりやすくトライしやすい内容で、どんな場面でも活躍すること間違いなし。
文章は砕けた感じが印象的で、読みやすいのもトヨマネさんの魅力です。


### パワポ研｜ビジネス×デザイン（@powerpoint_jp）様
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/913783/f8aabbc2-f8d5-4beb-1e35-3c71dd040fd1.png)

パワポ研さんは、IR資料や決算資料などビジネスに役立つ情報が満載です。
複雑かつ細かい内容はパワポ研さんの研究内容は役立つこと間違いなし。


### あらた | Presentation Designer（@powerpoint_plus）様
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/913783/509ac7b7-55e6-130b-b3da-0f9b758b1949.png)

プレゼンスクエア編集長のあらたさんが発信するTwitterアカウント。
『パワポdeデザイン』| iStock Ambassadorの著者でもあります。

あらたさんはパワポの基本的なデザイン術だけでなく、
パワポを活用したアニメーションの発送も豊富で、その術は見ごたえ満載です。

# さいごに

いかがでしょうか？
私は普段営業業務に携わっていますが、資料作成はある意味「デザイン視点」を踏まえて試行錯誤しております。

WEB会議が急速に進んでいる今、みなさんが楽しくパワポ術を学び、活かせるように。
またストックがたまったらご紹介いたします！

明日は、@tatsuyanamiki さんの記事です。
よろしくお願いします！
M1 Macbookでdocker-compose updateが上手くいかなかった時の解決方法

## 経緯
docker-compose updateを実行時、
エラーが発生。

```
ERROR [18/19] RUN pip3 install torch==1.5.1+cpu torchvision==0.6.1+cpu -f
```

M1 Macbookで実施。
M1以外のMacユーザーは問題なく実行できた

## 解決案
docker-compose.ymlの追加が必要

pip3を使っているサービスの下に
```
platform: linux/x86_64
```
を追加する。

上手くいかない場合は、上記修正をした上で、
```
docker-compose build --no-cache
```
を実行したら治った。

M1 macでコンテナを作ると、
platformが異なる形で生成されるのが原因らしい

## 参考URL
[[M1 mac, Docker] pythonコンテナでpip installしたときにNo matching distribution found for ~ が出る](https://qiita.com/arakkk/items/65d4e94b25aeff1c0154)
Flutterアプリをリリースするために僕が考えたブランチ戦略とデプロイ方法と仕組みについてまとめてみた！

# はじめに
この記事は[MIXI DEVELOPERS Advent Calendar 2022](https://qiita.com/advent-calendar/2022/mixi) の22日の記事です。

# この記事はなに？
昨年からFlutterでアプリ(iOS/Android)開発をはじめ、今年の頭に初めてアプリをリリースしました！
リリースする際に考えたブランチ戦略、デプロイ方法と仕組みについてまとめてました！


## この記事で紹介すること
- ブランチ戦略について
- デプロイ方法と仕組みについて

上記について紹介します！


# 環境
今回の記事は以下の環境、ツールを使用しています。
- MacOS: monterey 12.6 2
- Flutter: 3.0.2
- Fastlane: 2.190.0
- GitHub
- DeployGate
- Bitrise



# ブランチ戦略について
まずはアプリをリリースするまでのブランチ戦略についてご紹介していきます！

## 具体的なリリース手順
以下の図でリリース作業を進めています。それぞれ解説していきます！
![デプロイフロー&ブランチ戦略-アプリ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49347/077b435f-431a-4554-e287-4520f26473ce.jpeg)



### 各ブランチの役割

```
- main: 新しい機能を作成するための起点となるブランチ
- feature: 機能ごとに作成するブランチ。機能が完成したらmainブランチに対してPRを作成する。このタイミングでDeployGateにビルドが作成されるで、QAさんに確認してもらう
- work: 作業ごとに各人が作成するブランチ。作業が完了したらfeatureブランチに対してPRを作成する
- bumpup: mainブランチの内容をリリースする際にバージョンのアップグレードをおこなう
- staging: 各機能が正常に動作しているか最終確認をおこなう
- production: このブランチ入った機能をもとにリリース作業をおこなう 
```
こちらの手順で作業を進めています！


# デプロイ方法と仕組みについて
ここからは上記のブランチ戦略を進めるために使っているデプロイ方法と仕組みについて解説していきます！

## デプロイ方法について
デプロイ方法としては2つ用意しており
- 特定のブランチにPR作成、PushをトリガーにBitrise経由でデプロイ
- 手元から手動で特定のlaneを実行してデプロイ

を用意しています。

どちらもデプロイツールとして[Fastlane](https://docs.fastlane.tools/)を使用しており、Bitrise内でFastlaneを実行するか、手元の環境でFastlaneを実行するかだけの違いになります。

## なぜ手元からもデプロイ出来るようにしたのか？
基本的にはBitrise経由でデプロイを行うのですが、以下の理由から手元からデプロイする手段を残しておきました。

- Bitriseが万が一ダウンしてもリリースする手段を残しておきたかった
- Bitriseにベンダーロックインな状態にしたくなかった

上記2点が大きな理由となります。Fastlaneにデプロイ作業に全て任せる状態にしておけば、Bitriseから低コストで他のサービスに乗り換えることが出来る状態にしました。

## デプロイの仕組み
上記を踏まえた上でデプロイの仕組みは以下の図のようにしました。

![アプリデプロイフロー.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49347/b037a4ae-c949-a842-acd8-163afeb332de.jpeg)


Bitrise経由でのテスト実施からの各環境へのアップロードを基本としつつ、手元の環境でもFastlaneを動かせる状態としました。
複数のlaneを作成して、ブランチの作成、プッシュをトリガーにDeployGate、各プラットフォームの内部テストに自動的にデプロイされるようになっています。


## 終わりに
今回ブランチ戦略からデプロイの仕組みまでまるっと作成しました。
初めて触るツールや、アプリならではの証明書周りで苦戦しつつ、なんとかここまで出来たのでとても良い経験となりました！
まだまだ改善の余地もあると思うので、今後も引き続き改善していければと考えています！！
u-vision (arm mdkが無料になった。）

秋ロボアドベントカレンダー2022 18日目です。
こんにちは、やましょうです。

1.前書き
ネタ用に作ったコードが某コンパイラで正常に動かないってネタを投稿予定でしたが、最新版だと治っている。。ってことで、
投稿できなくなり、ごまかしネタです。

2.緊急連絡
mbed.orgのソースは今月中に消えます。
なのでmbed.org使用していた人はコピーするなりダウンロードするなりして自衛しましょう。

3.チャンス
さてダウンロードしたソースをofflineでコンパイルするチャンスです。
今年の２月か３月にarmさんがmdk (u-vision）のコミュニュティーエディションを出してくれました。
簡単なところ$”無料”$ってところですね。

細かいラインスはここにあるらしい。
https://www2.keil.com/mdk5/editions/community

ダウンロードはここ
https://www2.keil.com/mdk5

そしてなぜか日本語の説明文もある。
https://www2.keil.com/mdk5/install

mbedのソースをoffラインでコンパイルしたい人はリンク先を参照してみてください。
https://qiita.com/toyowata/items/6361aea538740c0eb860

最新版だとコンパイラ５が入っていない等あるかもしれないですが、
努力していれてください。

まぁ一番、簡単なのは、自分でstm32 cube mxで作るのが一番楽だと思います。


以上
やましょうでした。
VSCodeでMarkdownテーブルを「はぁ、書きづらい…」と思いながら書いている皆へ

VSCodeの [Markdown Table](https://marketplace.visualstudio.com/items?itemName=TakumiI.markdowntable) プラグインが最高でした。

## What's "Markdown Table" ?

VSCodeのプラグインです。
`*.md` ファイルを編集時、テーブル内で `Tab` キーを押すだけで、次のセルに移動 & 整形をしてくれます。

この手のテーブル整形プラグインって全角文字を認識してくれず、結局ガタガタな見た目に…ということが多いですが、作者が日本人の方なのでそのあたりを考慮するというポリシーのようです。

![20221221_182749.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/164949/be8551ad-5059-af4a-2ddb-132a29626708.gif)

上記をよく見てみると分かりますが、 **左右・中央寄せも意識した整形をしてくれています** 。クールですね。

## 何気に便利な付随機能も

ラクラク `Tab` キー整形機能だけでなく、たまに使いたい便利コマンドも搭載されています。
TSVからMarkdownに変換する (Excelからコピペしたときなんかに便利)、列の追加などなど…

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/164949/cda17fce-3ab5-1374-d441-a7d8efde6213.png)

## 参考リンク

[Markdown Table - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=TakumiI.markdowntable)
iPhoneのSMSを取り出す

# バックアップを取る
iTunesなどでiPhoneのバックアップを取る

全バックアップが面倒なら自己責任でサードパーティ製のものを使うと個別バックアップできるかもしれません。

# バックアップしたフォルダからSMSのデータを探す

Windowsであれば`%userprofile%\Apple\MobileSync\Backup`内にバックアップした日時毎のデータがあるので適当にバイナリgrepする。

自分の場合は`chat_id`で検索するとすぐでした。
他にも送信者などでも良いと思います。
（迷惑メールなら送信者が特殊なアドレスなので引っかかりやすいです。）

バイナリgrepは[msys](https://www.msys2.org/)や[cygwin](https://www.cygwin.com/install.html)などでやるのが楽と思います。
例）
```shell
$ grep chat_id . -nr
Binary file ./3d/3d0d7e5fb2ce288813306e4d4636395e047a3d28 matches
```

# DB Browser等でSQL実行する
見つかったファイルをどこかにコピーして、適当にxxxx.sqliteなどにリネームします。

[DB Browser](https://sqlitebrowser.org/)でsqliteファイルを開いたら以下SQLで取り出せます。

```sql
select c.guid,datetime((m.date/1000000000)+978307200,'unixepoch','localtime') AS date,h.id,m.subject,m.text from chat as c, chat_handle_join as cj, chat_message_join as mj, handle as h, message as m
	where c.ROWID = cj.chat_id and cj.handle_id = h.ROWID and c.ROWID = mj.chat_id and mj.message_id = m.ROWID
```

ファイルに保存するときは
SQL実行タブの`結果のビューを保存`アイコンでCSVにします。

この時BOMがついていないのでエクセルで開くと文字化けします。

[サクラエディタ](https://sakura-editor.github.io/)等で開いてBOM有りで保存しなおすと
エクセルでも文字化け無しで見れます。

参考URL
https://www.dekyo.or.jp/soudan/contents/ihan/howto.html
https://www.keishicho.metro.tokyo.lg.jp/anket/cyber_phishing.html
axiosでpostした結果をshift-jisで返してるつもりなのに、utf-8で受け取る不思議

## 経緯
getでCSVを取得していたのだが、リクエスト値に追加する文字列が長くなりすぎてエラーが発生。（429 Too Many Requestsエラ）

postに変更することで、既存処理にほぼ手を入れずにCSVを取得できないか試していた。

元々、shift-jisで返却していたのでshift-jisで返却されるだろうと思っていたら、utf-8で返却されCSVが文字化けしてしまった。

## 対応
ヘッダーのcontent-typeなどを追加したけど上手くいかなかった。
最終的に、axiosをcreateする際に、responseEncodingを指定することで解決。

もちろん、API側のレスポンスもshift_jisで返却している状態

```
let request = axios.create({
        responseType: 'blob',
        responseEncoding: 'shift_jis',
    })
request.post(url, {
                customer: JSON.stringify(params)
            }).then(response => {
               // 処理
})
```

## その他
Utf-8 BOM付きで返却も考えたが、以下問題もあったため、shift-jisのままとして
・今まで、shift-jisで返却していたためユーザーに変更の通知を行わないと行けなくなってしまう。
・Utf-8 BOMをslackで共有すると、なぜかBOMが外れる

#### 参考URL
[Slackのファイル共有を利用するとBOMが消える](https://qiita.com/mitsuaki1229/items/4624ba1858a7a0e7aee4)
Next.jsの特徴であるSSG/SSRの強みとメリット【React/Next.js/バックエンド比較】

Nextについて調べると、大きな違いとして、SSG/SSRについて書かれています。
これが自分の中で腑に落とせたので、メモしておきます。

## SSG：静的サイトの生成（Static Site Generation）
SSGは、JavaScriptを完全に読み込む前に、静的サイトを表示できる仕組みのことです。

静的サイトとは、最初から決められたコンテンツしか表示しないサイトです。
ざっくりとした理解であれば、HTML/CSSのみで組まれたサイトという認識で良いと思います。
この反対を動的サイトといいます。

### SSGのメリット
Next.jsはReactと違い、最初の読み込み時に静的サイトを表示することができます。
よって画面のチラツキを最小限に抑えることができるわけです。

### 動的サイトとは？
静的サイトとは反対に、ユーザーの入力によってコンテンツを変化させることができるサイトのことです。

例）
- タイピングの結果を表示する（フロントエンド）→ブラウザ上で動くJavaScriptを使う
- 入力した条件に応じた結果を表示する（バックエンド）→サーバー上で動くPHP/Ruby/Javaなどを使う

## SSR：サーバー（Server-side Rendering）
SSGに対して、こちらはサーバーへのリクエストを処理して表示する仕組みのことです。
バックエンドで行われていることと近いです。
しかしバックエンドの処理と違うのは、Next.jsは差分のみ更新して表示するので、ページ全体のリロードが不要で早いことです。
（書いていると、Reactってそういうのできないん？って疑問になりますが）

## まとめ

読み込み・表示速度を比較すると、

SSG > SSR > 全読み込み（バックエンド）

という感じです。
しかしSSGは静的サイトしか表示しないので、SSRのような汎用性はありません。
これだけみるとバックエンド要らなくね？ってなりますが、重たい処理や精度が必要な処理は、普通にバックエンドに任せるべきだと思います。
例えば大量のデータ処理なら、ブラウザでやるよりサーバーの強力なコンピューターで処理した方が適切です。
ブラウザでやると、メモリが一瞬でパンパンになって、動かなくなりますので泣
今さら読むリーンスタートアップ本。エンジニア目線で考察してみる。


#はじめに

この記事は[ZOZOアドベントカレンダー#3 25日目](https://qiita.com/advent-calendar/2022/zozo)の記事になります。


# リーンスタートアップ本とは

今更ながら、読んでいます。[リーン・スタートアップ　ムダのない起業プロセスでイノベーションを生みだす](https://www.amazon.co.jp/dp/B00F3UTIQY)。

スタートアップ企業にいるわけではないのですが、どこにいようと次々に顧客の望みを叶える（ちなみに顧客の望みは顧客自身はしらないから難しい）必要があるのだから必要な知識になります。
もちろん、企業内起業にも対応した内容でもあります。

今回はリーンスタートアップを実践しようとしたら開発組織はどのようにあるべきかをちょっと考えてみました。

# ベースになるもの

ちなみにリーンスタートアップとはリーン生産方式、デザイン思考、顧客開発、アジャイル開発といった知識がベースとなっているそうです。なので、これらの基礎を知っておく必要がありそうです。

これらはどれも、サイクルタイムが極端に短い、顧客の望みを中心とする意思決定を科学的に行うための考え方と言ったところでしょうか？

簡単にリーンスタートアップとはを言葉にすると、リリースすることは完全な商品を顧客に提供する手段ではなく、まずは顧客に使ってもらいそこから学習することが目的になります。顧客から学習するための最低限の機能（MVP)を最短でリリースし、その学習結果から更に新たに仮説を立て、さらにMVPを出していくその繰り返しがリーンスタートアップになります。

# VUCAの時代の商品開発

現代はVUCAの時代と言われています。
VUCAとは、VOLATILITY（変動性）/UNCERTAINTY（不確実性）/COMPLEXITY（複雑性）/AMBIGUITY（曖昧性）の頭文字をとってVUCAといいますが、常に変動し、不確実で、複雑で曖昧な世の中ということです。

考えてみれば現代という時代は、流行り廃りのサイクルが日に日に早くなっており（今年のはじめに流行したものとか覚えてますか？）、消費者の興味も複雑になっています。若者はテレビを見ないと言いますし、新聞やテレビ、雑誌ぐらいしかなかった情報媒体も今や多く存在します。

例えば、ちょうど先程テレビでこんな話題が上がっていました・・・
懐かしいかもしれませんが、2013年の流行語大賞の候補を思い出してみてください。
ＰＭ2.5/ＮＩＳＡ(ニーサ)/母さん助けて詐欺/弾丸登山/美文字/ＤＪポリス/ななつ星/パズドラ/ビッグデータ/SNEP（スネップ）/ヘイトスピーチ/さとり世代/ダークツーリズム/ご当地電力/ご当地キャラ/こじらせ女子/富士山/日傘男子/バカッター/激おこぷんぷん丸/困り顔メイク/涙袋メイク/倍返し/今でしょ/ダイオウイカ/じぇじぇじぇ/あまロス/ビッグダディ/ハダカの美奈子/ふなっしー/フライングゲット/マイナンバー/ＮＳＣ/アベノミクス/３本の矢/集団的自衛権/特定秘密/汚染水/ブラック企業/限定正社員/追い出し部屋/ナチスの手口に学んだら/ネット選挙/アホノミクス/引いたら負け/二刀流/スポーツの底力/シライ/お・も・て・な・し/コントロールされている

結構知っている言葉が並んでいませんか？自分はSNEP以外は全部わかりました。

2022年は？
村神様/キーウ/きつねダンス/国葬儀/宗教2世/知らんけど/スマホショルダー/てまえどり/Yakult（ヤクルト）1000/悪い円安/令和の怪物/ルッキズム/リスキリング/ヤー！パワー！/メタバース/BIGBOSS/ヌン活/丁寧な説明/#ちむどんどん反省会/青春って、すごく密なので/SPY×FAMILY/こども家庭庁/ガチ中華/顔パンツ/オミクロン株/OBN/オーディオブック/大谷ルール/インボイス制度/インティマシー・コーディネーター

どうでしょう？ほんと今年に流行った言葉らしいです。
自分はスマホホルダー？てまえどり？ルッキズム？リスキング？ヤー！パワー！（流行ったの？という意味で）？ヌン活？青春って、すごく密なので？ガチ中華？顔パンツ？OBN?インティマシー・コーディネーター?これだけの言葉を知らなかったです。今年ですよ？今年ですよ？

人々の情報媒体が多岐に渡っているという証拠ではないでしょうか？

たった9年でこんなに状況が変わっているんです。どうやって１発で商品を当てるのでしょうか？
どこでなにが流行るかわからない。もうマスでは無理なんです。新聞やテレビに広告打っても見ない人が多いので当たらないんですよ。

そう考えると、サイクルタイムを極端に短くし、不完全な商品でも次々リリースし、顧客に使ってもらい、そこから学習し、さらに手を打つ手法は理にかなっていると思いませんか？

# 開発組織はどうあるべきか？

そういう中で開発組織はどうあるべきか？

ヒントのひとつは[FourKeys](https://qiita.com/YasuhiroKimesawa/items/627801a25ed3a2d7d6b0)かなと思っています。

[この記事](https://qiita.com/YasuhiroKimesawa/items/627801a25ed3a2d7d6b0)でもご紹介しましたが、計測するのは、デプロイの頻度とリードタイム、そして品質です。

サイクルタイムを短くしMVPを多く検証するために打ってつけの計測方法だと思います。

当然ながらそれができる開発体制になっていかないといけない。
FourKeysの目指すところはLean・DevOps・アジャイルです。そこを突き詰める必要があります。

仮説を立て、それを検証できるMVPを短いサイクルでリリースする。そこから学習し次に活かす。(Lean)
言い換えれば仮説を立て(スプリントゴール)、検証に向けた最優先のタスクを整理し(スプリント計画)、チーム全員が協力し、すぐにリリースし、その反応、結果をレビュー(スプリントレビュー)し、振り返りと共に学習し、次のゴールに向けて動く。(アジャイル)
すぐにリリースするための動き方も学習が必要。リリースを即座にシンプルに行う技術、実装するスピードに品質、おそらくリソース効率を求めるよりフロー効率を求める方が良いでしょう。ユニットテストや、E2Eテストも自動化できるほうがいいでしょう。インフラのあり方や運用の仕組みも工夫が必要。これらをこうしたらこうできそうという仮説から、適応、振り返りによる検証のサイクルを回していく(DevOps)

もちろん開発チームだけでこれらを回すのでは足りない。関わる隣のチーム、ミドル層、トップ層をも巻き込んでいく。

これらに成功した組織こそ、良い未来が待っているということでしょう。
集中すること・マインドフルネス・アジャイル

#はじめに

この記事は[ZOZOアドベントカレンダー#2 23日目](https://qiita.com/advent-calendar/2022/zozo)の記事になります。



# VUCAの時代

VUCAとはVOLATILITY（変動性）/UNCERTAINTY（不確実性）/COMPLEXITY（複雑性）/AMBIGUITY（曖昧性）の頭文字をとってVUCAといいます。
現代はVUCAの時代と言われています。

この常に変動し、不確実で、複雑で曖昧な世の中をどのように生きるか？
VUCAの時代は、個人の生き方だけでなく、働き方や組織構造、企業のあり方まで問われるような時代でもあります。

そんな激動の時代に流されず生きるため有効なプラクティスをいくつか紹介しましょう。


# マインドフルネスとは

VUCAの時代。必要なのは時代に沿いつつ、流されず自分を生きること。自己認識力を高めること。
そのプラクティスとしてマインドフルネスがあります。

いくつか有効なプラクティスがありますが、基本はマインドフルネス瞑想でしょう。
ただの瞑想ではありません。なにも考えないのではなく、呼吸に集中するプラクティスです。

瞑想すると、意思に反して、色々なことを思い浮かべると思います。
それは過去のこと（やったこと、やってしまったことなど）、または、未来のこと（やろうと思っていたこと、これからやる必要のあるものなど）であることがほとんどです。
それらを一旦手放し、呼吸、つまり今目の前にあるものに集中するというプラクティスです。
呼吸は誰にでもできる（当然している）行為という面もあります。

流されず、今目の前にあることに集中する力が身につきます。

世の中が常に変動し、不確実で複雑で曖昧な世の中では、一つのことに集中することも困難だと思います。
スマホが手元にある時代、PCが目の前にある時代、一つのことをやりながら他のことにも手を付ける。そして両方身につかないなんてことはよくあることだと思います。

マインドフルネスを身につけると、一つのことに集中する力もつきます。


# 不確実性に対応したアジャイルプラクティス

Scrumのプラクティスであるバックログ、カンバンにおけるWIP、どちらも目の前にあるものに集中するというプラクティスになります。
バックログには優先順位を設定する必要があります。優先度の高い順から手を付けていきます。
カンバンにおけるWIPもDOINGに持っていける数を制限することで今あるものに集中する効果があります。

一人のリーダーが全てタスクを把握して、メンバーに振っていくにはやることが多すぎて無理ゲーになってきています。
今の世の中それぐらい複雑です。
チームメンバー全員で理解し、優先度を把握してチームで取り組む必要があります。


# タスク管理　並列で仕事をしない

独りで仕事をする方も同様、並列で仕事をすることはリスクが高すぎる行為です。

直列でタスクを管理できるツールを利用しましょう。

自分はSpreadSheetを使った自作のツールを活用しています。

# Youtubeで集中

グループで仕事をしているときは集中せざるを得ません。独りの場合はなかなか集中するのは難しいですよね。
そんなときはYoutubeで集中できる効果音がたくさんあるので、聞きながら仕事をするといいでしょう。

# 集中することが困難な時代に

VUCAと呼ばれる時代、集中すること自体が困難な時代。
そんな時代だからこそ、解決策も一昔前とは比較にならないほど多く提案されています。

それらを活用するかしないか。それで働き方・生き方も変わるはずです。

ぜひ参考になさってみてください。
RubyonRailsチュートリアル：実践メモ【目次】

#### 【第一章】
- [ターミナルを開く方法](https://qiita.com/suzuki_q/items/59fea2e882197f562ead)
- [ルートの設定方法](https://qiita.com/suzuki_q/items/755ed1a2602c20b12b50)
#### 【第二章】
- [Gitのバージョン管理下に置く](https://qiita.com/suzuki_q/items/3d9fdc8b79a6741b2b41)

#### 【第三章】
- [コントローラの新規作成](https://qiita.com/suzuki_q/items/2b3d5e31787a08d00759)
- [ローカルサーバーの使用方法](https://qiita.com/suzuki_q/items/c35c495de24d30abb32b)
[Android][Kotlin] Splash画面の実装　コピペ可能

### コピペでいけます！

アプリ起動時にいきなりアプリ画面を表示させるのではなく、LINEみたいに一旦起動中の画面を表示させたいですよね。
そんな時に使えるSplash画面。
コピペでいけるので、ぜひ試してください。
方法は超簡単です！

### まずは
```build.gradle
dependencies {
    // コルーチン設定
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4'
}
```
```AndroidManifest.xml
// メインのActivityをSplashに
<activity
    android:name=".SplashActivity"/>
・
・
・
// メイン画面に遷移できるように追記
<activity
    android:name=".MainActivity"/>
```

### ソースコード
```SplashActivity.kt
class SplashActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_splash) // レイアウトは各自で

        CoroutineScope(Dispatchers.Main).launch {
            // 一秒間表示　（二秒間なら2000）
            delay(1000)
            // MainActivityへ画面遷移
            val intent = Intent(this@SplashActivity, MainActivity::class.java)
            startActivity(intent)
            finish()
        }
    }
}
```

レイアウトに

    <ProgressBar
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerHorizontal="true" />

をつけると、通信時によくある「ぐるぐる」を表示できます！！
これで、っぽくなるのでおすすめです！
セキュリティ対策の最初の一歩の一歩(オフィス編)。

# １．この記事の背景
セキュリティの3本目の記事です。
物理的な対策、監視強化に加え、やはり足元のセキュリティが大切です。
意外となさそうでありそうな事例(初歩の初歩)を取り上げたいと思います。

# ２．意外とあるあるではないかと思われる事例

## 事例１：フリーアドレスで後ろから画面丸見え！
※図にしてみました。
![配置.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003921/c1625cf8-589e-0841-f31c-3f00ad1e4836.png)

・テレワークが進むとオフィスの一部を返却して違う部や課が同じ部屋に集まるようになる。
・フリーアドレスだと基本的にものを置かない。
　→見通しがいいので、その気はないのにショルダーハックできてしまう！

[対応]
・パーティーションで区切る
・資料をPCに表示させるとき、共有範囲を超える人が見えてしまう場合は個室(会議室など)で作業する

## 事例２：ファイルサーバの権限管理ができてない！
特に異動時に削除申請忘れでそのままに・・・。

[対応]
・退職には事務処理が発生するのでそのなかのフローに入れてしまう。

# ３．どう従業員に伝えるか
研修では、ある程度知識は獲得できても「そんなやつおれへんやろ」のテンションになりがちです。
そういう気分にさせないことが大切で、**実際の事例(社内事例が一番効く)と損害(発生してない場合も最悪のケースの試算)を数字で示すことで恐怖感をあおること**もアリかなと思います。

コンプラ対応が厳しくなるなか、「研修はやってました」では通用しない時代です。
真剣さを喚起させる方法があるといいですね。。
UNIXのコマンドまとめ③

引き続きUnixについてなんとなく書いていこうと思います。

第3回は、絶対パスと相対パスのコマンドについて書いていきます。

****

**コマンド**

* <code>pwd</code>：現在のディレクトリを表示
*  <code>cd (目的ディレクトリのフルパス)</code>：目的のディレクトリへ移動。フルパスは絶対パスのこと。
    *  例：<code>cd /Users/(ユーザ名)/Desktop/フォルダ名</code>
*  <code>cd ~</code>または<code>cd</code>：ホームディレクトリに戻る
*  <code>cd /(ディレクトリ名)</code>または<code>cd (ディレクトリ名)</code>：現在のディレクトリからすぐ下のディレクトリに移動
<br>

**ポイント**
* tabキーでコマンドの補完ができる
* 補完候補が複数ある場合は1回tabキーを押しただけでは補完されないが、２回tabキーを押すと補完候補が一覧で確認できる。


以上

参考 : 
https://dotinstall.com/lessons/basic_unix_v3/55304
https://dotinstall.com/lessons/basic_unix_v3/55305
rubymine データベースのテーブルを表示させる

# あくまで備忘録です。
# マイグレーションを実験的に行なった
しかしrubymineのデータベースの欄にテーブルが表示されていなかった。
多分mysqlと接続されていないようなことが起きていた。

### mysqlでテーブルを確認
```
mysql> show columns from Products;
+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | bigint       | NO   | PRI | NULL    | auto_increment |
| name       | varchar(255) | YES  |     | NULL    |                |
| created_at | datetime(6)  | NO   |     | NULL    |                |
| updated_at | datetime(6)  | NO   |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+
4 rows in set (0.01 sec)
```
確かにテーブルは保存されている。

### データソースおよびドライバー
右のデータベースをクリックして左上にある＋をクリックしてデータソースをクリックした。
そこで自分の使っているのがmysqlだったのでクリックした。
ユーザーをrootにしてスキーマをクリックするとパスワードか何かを要求されるか無視してクリック
そうすると全てのスキーマが表示されるので使いたいスキーマにチェックすると
スキーマのテーブルが表示された。

# 感想
これは本格的にはダメだろうけど
表示するだけが目的だったのでこれで満足だ。
まだまだ知らないことばかりだ。
モデル化のススメ

システム開発を行う場合，ざっくり企画，要件定義，設計，実装，テスト，ローンチというプロセスを経ると思いますが，要件定義と設計の間に大きなギャップがあることに気づくことがあります．
* 要件一覧は出てるけどあまり構造化されてないなぁ
* 将来的に変化が大きい部分とほとんど変化しない部分の境界が明確じゃないなぁ
* ビジネスルール，システムルール，原理原則を見出したいなぁ

などなど．
それぞれに対する対策を要件定義に含める場合もあれば設計で実施する場合もあり，開発組織によってまちまちだとは思いますが，何れにせよ上記のようなイシューに対してどういったアクションを取ればよいのか，明確でないことが多いです．

筆者の経験では，ドメインモデル，プロセスモデル，ルールの３つを思考してみるとしっくり来ることが多かったです．
全部が揃っていれば良いというわけでもありませんし，全てが必要というわけでもありません．どの順番で考えればよいということでもなく，システム化対象となるものによって必要となるモデルはまちまちです．しかしながら，将来のニーズを取り込める土台を作り，システムの賞味期限を永らえるにあたって有効だったという経験則ではあります．

# ドメインモデル
筆者は昔からドメインモデルと同等のアプローチを取ることが多かったので，最近の動向にはワクワクしながら，いろいろなケースを拝見しては共感したり学びに変えたりしています．
ドメインモデルは各オブジェクトの存在や意味，オブジェクト間の関係性を明確化し，構造化することに優れており，事象の原理原則をあぶり出すのに有効な手法でありつつ，一方でIT，非IT限らず広く共有できる点でも強力なツールだと考えています．
最近は他の場で多く語られている分野ですので，ここでは割愛します．

# プロセスモデル
プロセスモデルの描き方として有名なのはBPMLであり，多くの製品が世の中で使われていると思いますが，これはアクターのアクションに着目したものであるため，要件の確認においてはかなりの効力を発揮します．
一方で，下記の問題により要件漏れが発生するリスクが高いと考えています
* あらゆるケースを同時に表現しきることが難しいため，ケースを網羅するためには複数枚のモデル図が必要となる
* アクターとアクションの組み合わせが厳密ではなく，多様な組み合わせが想定できるケースが多いため，モデルとしての堅牢性が低い
* プロセスが存在している目的がわかりにくい（複数の目的を持っていることもある）ため，設計の際にはさらなる分解が必要

短い業務プロセスであればBPMSを活用した自動化も図れると思いますが，長い業務プロセスに対しては可視化に留めるのが懸命かもしれません．

プロセスが長い場合には，主要なオブジェクトの状態遷移を描いてみるのが意外とおすすめです．
かなり抽象的なので一定の慣れは必要となりますが，オブジェクトの状態がデータの状態に対応することが多いため，実装やテストにおいて想定すべきケースの洗い出しに便利です．
また，状態遷移はアクターからは独立しているため，
* 将来的にビジネスニーズが変化した際にも，アクターが変わるだけで状態遷移は変わらない
* アクターが変わるとビジネスがどう変化するかなど，水平思考的にビジネス展開の幅が想像できる
* 状態遷移に手が入る場合にはビジネスの構造自体に変化がある

といった副次的な効果も期待できるため，要件定義の効率化にも寄与すると考えています．

一方で，複数オブジェクトの状態変化が同期する場合（ほとんどそうですが）は状態管理が複雑化するため，注意が必要です．あくまでも主要なオブジェクトへの適用にとどめておきたいところです．

# ルール
一時期，ルールエンジンの登場によって注目され，最近ではRPA技術の発展の文脈でも注目されています．
主に業務の自動化に資するものとして期待されている考え方ですが，自動化はともかくとして，パラメータとアルゴリズムのあぶり出しと分離に一役を担う存在と言えます．
ビジネスルールは現実に発生する事象をベースに説明されるために曖昧なことが多く，汎用的に構造化すること自体の難易度が非常に高いため，またビジネスの現場との共通理解を優先し，一般的には要件をやや直接的に実装することが多いと思いますが，抽象化して構造的に捉えることで汎用性が高まり，多少のニーズの変更に対して堅牢なシステムを構築することが可能となります．

課題はあります．
抽象度，実装難易度，エンハンスコストがそれぞれ相関することになり，技術組織のレベルによってルールの抽象度をコントロールする必要があると筆者は考えます．
抽象度が上がると，数多ある高度なアルゴリズムおよびそれらの組み合わせの適用が可能になってくることが多くなりますが，実装難易度も相応に上がり，エンハンスの機会自体は減少しますがエンハンスに当たる人財は高度なスキルが要求されることもあります．
技術組織の現状のレベルや今後の育成計画，採用の難易度，事業全体の組織のバランス等を加味して方針を決める必要があると思っています．

# 最後に
とはいえ，モデル化の方法は多様であり，またシステム化の対象によって進め方も様々です．ここではあくまで考え方の一例を紹介させていただきました．
ITにおける実装業務を経験されている読者であれば思考の中で実施していることではあると思うので，まずは簡単なプロジェクトから可視化を始めてみて，その効果や課題を体感した上で各々の技術組織にあったやり方を模索していってください．
[備忘録] カレントディレクトリのパスを改行無しでクリップボードにコピー

# 備忘録 (メモ)
## カレントディレクトリのパスを改行無しでクリップボードにコピー
~~~bash
$ echo -n $PWD | xsel -bi 
~~~
- `-n` : echoコマンドの改行無しのオプション

# alias (お好みで)
~~~bash
alias pbcopypwd='echo -n $PWD | xsel -bi'
~~~
サーバーサイドエンジニアが嫌になってきたのでSREに転身した話

:::note info
この記事は[PHC BXC Advent Calendar 2022](https://qiita.com/advent-calendar/2022/phc_bxc)21日目の記事です
:::

転身したのは2年くらい前の話ですが

# はじめに

今までサーバーサイドメインのエンジニアやってたのですが、しんどくなってきたのでSREになりました。サーバーサイドエンジニアで感じていた不満点とかSREのやりやすさとか自分の考えを書いてみました。

# 何してる人？

いわゆるWeb系の企業でアプリケーションエンジニアをやってきました。何度か転職はしましたが、いずれの会社でもサーバーサイドの開発(Ruby、Go、Python等)が中心で、インフラやフロントも必要に応じて扱ってきた感じです。まあ、ごく普通のサーバーサイドエンジニアですね・・・

# サーバーサイドエンジニアが嫌になってきた理由

色々ありますが・・・

## 1. フルスタックに働くのが嫌になってきた

自分の仕事はサーバーサイドのコーディングが中心ではありますが、必要に応じてインフラやフロントエンドのコーディングも行ってきました。アプリもちょっとだけやったことがありますし、専門の人には及びませんがMLも業務で扱ったことがあります。

ですが正直、**自分の得意な領域以外の仕事をするのがかなりしんどく**なってきました・・・特にフロントエンド、Javascriptとかですね。私の専門はアドテクでして、アドテク固有のJS技術に関してはモチベもありますし、ある程度自信もあります。ですが、UIに関わる部分と言いますか、ReactとかVueとかのフレームワークを使って画面を動かすようなJSの使い方には全く興味が湧かないんですよね・・・

Web系のサーバーサイドエンジニアであってもフロントエンドのコーディングを求められることは珍しくないので、どうしてもやりたくないタスクが発生してしまうことがあり、これがストレスでした。まあ最近はやりたくなさすぎて拒否ってたけど・・・

## 2. 開発やコーディングに対する細かい議論が嫌になってきた

これが一番大きいかもしれません。簡単に言うと、**コードにこだわりも持つのが面倒**になってきました。
キャリア初期の頃は、より綺麗なコード・処理効率の高いコードを書こうと常に意識してましたし、その辺りをコードレビューで議論するのも楽しめていました。ですが最近では、このコードに対する議論がシンプルに面倒くさくなってきました。

端的に言うと、「その議論って事業的に価値あるの？」って思うようになりました。面白くもないし金にもならないことを議論するのが時間の無駄って感じると言うか。もちろん重要なアーキテクチャ等に関する議論は必要です。**自分が嫌になってきたのは、コード規約とか計算量に関する細かい議論**ですね。あとデザインパターンとか。

チーム内で自分が技術面で圧倒的にリードしておりメンバー全員を納得させられるだけの説得力を持つ選択肢を提案出来るなら議論の余地もないのですが、そのようなことは稀でしょう。サーバーサイドの開発や設計には人によって経験や得意とする手法に差があることが多いため、余分な議論が発生しやすいです。あとサーバーサイドエンジニアって同じ会社でもスキル感がバラバラだったりするんだよね・・・

まあチームの成長とか考えると、細かいレビューをお互いにし合えるような環境の方が適しているとは思います。コードに対してこだわりを持つことや議論を深めることが悪いことだと思っている訳ではないです。

ちなみに、コードを書くこと自体が嫌な訳ではないです。プライベートとかで自由にコーディングするのは楽しいです。あくまでも「仕事で」の話ですね。

# SREの働きやすさ

サーバーサイドエンジニアではなくSREならどのように不満が解消されるのか。ちなみにSREとは言ってるけど、どっちかというとクラウドインフラエンジニアって感じです・・・

## 1. サーバーサイドエンジニアよりも守備範囲が限定される(気がする)

SREの肩書きになってからも相変わらずサーバーサイドの設計・開発には関わってますが、フロントやアプリ側のタスクを求められるようなことは全くなくなりました(当然といえば当然だけど)。まあ、インフラ側でもやりたくない仕事は少なからずありますが・・・

## 2. 技術的・事業的な正しさを示しやすい
インフラの設計はサーバーサイドの設計に比べると選択肢が少ないですし、そもそも設計に関わる関係者自体少ないので、**自分の提案する構成を関係者に納得してもらうのが比較的簡単**です。

余分な議論で時間を浪費することが少なく、自分の得意な手法で進められることが多いのでストレスが少ないです(すごく嫌なこと言ってるかも)。

もちろん他の人が出してくれた案の方が優れてることもありますが、SREって割とベテランの人が多いのでこちらとしても納得しやすい案を出してくれることが多いです。

# SREの微妙なところ
私は現職でも前職でもSREという役職ではありますが、正直に言って自分が**本来の意味でのSREの仕事**だけをしているとは思っていませんし、それに注力したいとも思ってません。

自分が求めている役割としては、SRE的業務を含めたクラウドインフラのアーキテクトって感じなのかな・・・

# 宣伝

私は**株式会社PHC メディコム事業部 ビジネストランスフォーメーションセンター(BXセンター)** でSREとして働いてますが、自分の役割が何なのか分からなくなるくらいには自由にやらせてもらってます。

一見お堅い会社に見えますがBXセンターに限って言えばほぼWeb系の組織なので、興味のある方いましたらぜひお話ししましょう！

https://careers.digicare.jp/entry/engineer/
テストにおけるアンチパターン～期待結果を期待通り得るには？～


<h1>はじめに</h1>
<p>Web系SaaSシステムエンジニアのKyukiです。<br />
みなさんは、テスト仕様書を書いたことはありますか？<br />
</p>
<p>
今回は、日々の業務の中で実際に経験したテストに関わるアンチパターンを紹介し、皆様のデバックライフに気づきを与えられればと思います。<br />

<h1>あなたにとっての「正常」は何？</h1>
<p>「正常に処理が終了する」<br />
だとか<br />
「正常な文言が表示される」<br />
だとか。<br>
そういったワードが期待結果として記載されているテスト仕様書を見た事がありませんか？<br>
では、「正常」って何なのでしょうか？<br>
辞書を引くと「普通、正しいとされる状態にあること。」といった説明があります。<br>
<strong>なるほど！</strong>「普通」の状態。「正しい」状態という事なんだな！
<br>
とは、納得できないですよね。<br>
具体的・明示的に、『何』が、『どうなれば』期待した結果となるのか、記載するようにしましょう。<br>
例えば、「エラーが発生せず処理が終わる」とか「エラーが起こってもエラー画面に遷移する」とかそういった書き方になっていれば、誰が実施しても同じ結果が得られますよね。
「エラー」と言ってもエラー毎に処理が変わるのであれば、それぞれのエラー毎に記載すべきですが...。
</p>

<h1>A～zは本当に26個ですか？</h1>
<p>
項目を列挙する時、一つ一つ記載するのは面倒だと感じる方もいるでしょう。<br>
「ABCDEFGHIJKLMNOPQRSTUVWXYZ」と書かなければならないところ「A～Z」と省略してしまう事も多いのではないでしょうか？<br>
ですが、テスト仕様書において省略は危険です。<br>
「A~Z」と書いていてあっても、書き出してみると「AXYZ」かもしれません。<br>
私達はアルファベットが26字だと思っていますが、27文字だと思っている人もいるかもしれないですよね？<br>
例はアルファベットなので、ググれば分かりますが、<br>
実際は「ユーザーID、パスワード、登録日、登録者」の順番に表記されることを確認しなければならないケースだったりする事でしょう。
そんな時、『「ユーザーID～登録者」が表示される。』などといった期待結果が記載されていたら、果たしてそのテストで品質は保証できますか？</p>

<h1>最後に</h1>
普通、当然、<br>
<br>
そんな思い込みが、バグを埋め込む原因となります。<br>
テストではそれを検知する為に当たり前を再点検し、明文化する事が重要です。<br>
是非、今回挙げた例以外にも、思い当たる節があれば改善していってくださいね。
JavaScriptで小数第二位までの足し算をする

### 繰り返し足し算の中でハマる沼
JavaScriptでの小数の計算をググると計算後に100倍してMath.floorを利用し、最後に100で割る方法の紹介が多かった。
しかしこの場合、例えば```1.8```となるべき計算結果が```179.99999...```と計算された場合に```1.79```が答えになってしまう場合があり、足し算を繰り返していく処理の中で少しハマった。

#### シンプルな足し算
Math.roundを使う方がいいみたい。理由は上記のような場合でも四捨五入してくれるから。

```javascript
let total = 0;
let numbers = [小数点以下がある数字の配列];
for (const num of numbers) {
    total = Math.round((total + num) * 100) / 100;
};
```

#### 小数の係数が絡んでくるパターン
係数が小数の場合は係数に対してもMath.roundを使う。
```javascript
let total = 0;
let numbers = [小数点以下がある数字の配列];
let coefficient = 0.61; //係数
for (const num of numbers) {
    total = Math.round((total + number * Math.round(coefficient)) * 100) / 100;
};
```
【PHP】配列同士を検索して要素を取得する方法(array_filter)

# 配列値×配列値で検索
サンプル
```php
// 検索対象配列
$baseArr = [1,2,3,4,5];
// 検索情報配列
$searchArr = [2,3,9];

// 一致した検索対象配列の要素が格納される
$result = array_filter($baseArr, function($value) use ($searchArr) {
        return in_array($value, $searchArr);
    }
);

var_dump($result);

/*　　　結果
array(2) {
  [1]=> int(2)
  [2]=> int(3)
}
*/
```
サンプルでは検索対象配列に１から５までのデータ、検索情報配列には２，３，９が格納されています。
このうち１から５までの値で一致した、２，３の要素が返却されました。

array_filter関数の第一引数に検索対象配列を指定し、第二引数にはフィルターの条件（無名関数）を設定し、useには検索情報配列を引き継いでいます。
フィルター条件にはin_array関数を使うことで、検索対象配列の各値が検索情報配列の値に含まれている場合にはリターン値がtrueとなり、フィルタリング後の結果セットに検索対象配列の該当要素が格納されていくようになっています。

# 連想配列キー×配列値で検索
サンプル
```php
// 検索対象連想配列
$baseArr = [
        100 => 'りんご',
        200 => 'みかん',
        300 => 'メロン',
        400 => 'レモン',
        500 => 'バナナ'
    ];
// 検索情報配列
$searchArr = [100,300,999];

// 一致した検索対象連想配列の要素が格納される
$result = array_filter($baseArr, function($key) use ($searchArr) {
        return in_array($key, $searchArr);
    }, ARRAY_FILTER_USE_KEY
);

var_dump($result);

/*　　　結果
array(2) {
  [100]=> string(9) "りんご"
  [300]=> string(9) "メロン"
}
*/
```

先の例では、配列同士の値を検索するものでしたが、こちらでは連想配列のキー基準で検索をしています。

array_filter関数の第三引数のflagに「ARRAY_FILTER_USE_KEY」を指定することで、第二引数に指定したフィルターの条件（無名関数）には検索対象連想配列のキーが渡されます。
フィルターの条件で検索対象連想配列の各キーが検索情報配列の値に含まれている場合には、検索対象連想配列の該当要素が格納されます。

# きっかけ
上記の連想配列キー×配列値で一致した要素を取得する必要が生じ、in_array関数単体だと一つの値が配列に含まれるかどうかはできても、この場合に良い方法がないものかと考えました。

当初はforeach文を使っての以下のような手段を検討しましたが、

```php
$result = [];
foreach ($baseArr as $key => $value) {
    if (in_array($key, $searchArr)) {
        $result[$key] = $value;
    }
}
```

もう少しスマートなやり方はないだろうか…ということで備忘録としてまとめてみました。

# 参考

https://www.php.net/manual/ja/functions.anonymous.php

https://www.php.net/manual/ja/function.array-filter.php

https://hensa40.cutegirl.jp/archives/1515

https://maasaablog.com/development/backend/php/2760/#toc13
肥大化した参照系マイクロサービスをスリムにするための取り組み

# 現状・課題
- ZOZOでは5年以上前からリプレイスプロジェクトが進行中で2017年から作成された参照系をあつめたマイクロサービスが存在する
- このマイクロサービスは[過去の弊社社員のプレゼン資料](https://speakerdeck.com/sonots/zozotownripureisu2020)にも書かれている通り、肥大化しておりモノリス化してしまっている
- 現状でも参照系のエンドポイントを増やすときはこのマイクロサービスに追加するかたちになっておリ、肥大化していた。
- 参照系マイクロサービスを作成したあとに作られた他のマイクロサービスへ移行が済んでいるのも関わらずエンドポイントが残ってしまっている。
- リクエストされていないエンドポイントが存在する

# そもそものハナシ
## マイクロサービスとは
> 協調して動作する小規模で自律的なサービス。

[マイクロサービスアーキテクチャ](https://www.oreilly.co.jp/books/9784873117607/) より

- 小さくかつ1つの役割に専念したもの
サービスの境界をビジネスの境界と合わせて特定の機能のコードがある場所を明確にする。
サービスの境界を明示化しておくことによって大規模になるのを防ぐようにする
- 自律性
それぞれが独立して変更でき、コンシューマを変更する必要なく単独でデプロイできなくてはならない。
「他のなにも変更せずに単独でサービスの変更やデプロイを行えるか」

## マイクロサービス化する主な利点
- 技術変異性
サービスごとに異なる技術やジョブごとに最適なツールを選択することができる
- 回復性
サービス境界は明確な障壁となって障害の連鎖を防ぐ
- スケーリング
必要なサービスに絞ってスケーリングすることができる
- デプロイの容易性
独立したサービスのみを迅速にデプロイできるため顧客に新機能を提供することも迅速に可能
問題が起こった場合でも原因の特定もモノリシックシステムに比べて容易で、ロールバックも迅速に行うことができる
- 交換可能にするための最適化
必要に応じてサービスを完全に書き直したりサービス自体の削除も容易になる
コードベースを数百行程度にすると開発者はサービスに対して愛着を持ちにくくなるので置き換えコストも低くなる。

## モノリシックシステムとは
> システムやソフトウェアが1つのモジュールでできており、分割されていない設計のこと

## モノリシックシステムのメリット
- デプロイが簡単
- 1つのコードベースで構築すると開発が容易
- 外部モジュールを必要としない構造のためプロセス間での通信が発生しない。

## モノリシックシステムのデメリット
- 大規模なモノリシックシステムは開発が複雑になり速度が低下する
- スケーリングが困難
- いずれかのモジュールにエラーが発生するとすべての可用性に影響する可能性がある
- テクノロジー導入の障壁が高い
- 微小な変更でもモノリシックシステム全体のデプロイが必要になる

# 洗い出し・調査
- 肥大化した参照系マイクロサービスのopenAPIからエンドポイントをスプレッドシートなどに洗い出し。
- 洗い出したエンドポイントの中で既存で同等の機能を持つマイクロサービスがあるか/すでに移行済みか洗い出し。
移行できると判断した場合はそのエンドポイントがサービスのどのページで呼ばれているのか・どんな用途でリクエストされているかなども合わせて記載しておく。
- エンドポイントを1つ1つ過去に呼び出された形跡があるかDatadogのデータを確認
- 過去に呼び出されていないエンドポイントをリクエストするASPなどのクライアント側のロジックが存在するか確認
存在する場合、なんの機能に使われているものかを記載しておく
- リクエストされていない削除候補のエンドポイントを別シートなどにまとめてクライアント側のソースを管理するチームに確認してもらい、削除可能か判断してもらう。（全体の3割ほどが削除候補になった）
- 一部、まだ使われていないが今後使われる想定のものに関しては、使われるまでは[OpenAPIでdeprecatedを指定](https://swagger.io/docs/specification/paths-and-operations/#deprecated)して非推奨としておきます。
- 今後使用する可能性もないものに関しては参照系マイクロサービス及びクライアント側からのソースコードの削除をすすめる。

# 削除
- 洗い出し・調査の結果、削除可と判断されたエンドポイントについては随時ソースコード自体の削除をすすめる
- 削除の際にも開発環境やステージング環境などでエラーが発生しないか監視を行う
- 削除をした際には関連チームに報告を行い、エラー監視をしばらく行う
- 削除を随時行うことでスリム化が進みビルド時間なども短縮されていき、よりマイクロサービスの恩恵を受けられるようになる

# 今後の進め方
- まずは削除できるソースコードについてすべて削除を完了する。（数万行のソースコードを削除できる見込み）
- 削除しないエンドポイントに関してはマイクロサービスを細分化した際にどのマイクロサービスに該当するかを分類分けする
- 各マイクロサービスが作成される時に同時で参照系マイクロサービスからの移行もすすめる
- クライアント側についても移行後のエンドポイントをリクエストするように修正を行っていく

# 振り返り
- 参照系マイクロサービスの中でもさらに細分化してマイクロサービスを定義するべきだったかもしれないが、マイクロサービス化の第一歩を踏み出しただけでも大きな価値があったと思う。
- マイクロサービス化したあとからも肥大化させてしまっていたことも問題で、ストアドを参照しているロジックを前もってエンドポイント化して実装を進めたものの数年間使われていないものも多かったので進め方についても途中で見直す必要があったと思う。
- 数カ月間かけて洗い出し調査を行ったが最終的には数万行は削除できそうなのでこの作業はやる価値が大きいと思う。
- もうちょっとスリム化すれば新しい技術を導入したりすることも容易になると思うのでよりよいマイクロサービスになると思う。
【AWS】Dockerで作った環境をECRに再プッシュする

[前回](https://qiita.com/huntas0624/items/108cf534f541ed7810c1)、DockerimageをECRにプッシュし、Fargateでコンテナを動かした。

コードを変更したときに再プッシュする必要があるので試してみる

今回は分かりやすいようにDockerbuildをするときにタグを`Changetest`としておいた
コードの中身は以下の様に`変更後のコードです`を付け加えておいた
ローカルで動かした↓
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884542/141c7b42-7557-19a9-e96d-622d06ce27ca.png)

基本的には前回やったことをなぞるだけでした
1\. ECRのプッシュコマンドを表示からコマンドを打ち込んでいきます
ただ、タグを`changetest`と変更しました。
そうするとリポジトリのイメージが1つ追加されました

2\. タスク定義から新しいリビジョンを作成する
新しいリビジョンを作成して、コンテナを追加から先ほどECRにプッシュしたイメージを追加していきます。名前とURIを入力してください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884542/6f9a964a-4f20-938a-a45e-9fa9810df562.png)

3\. サービスを更新する
サービスにチェックマークを入れ、更新をクリックします
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884542/32e2762a-f69c-6fce-35a3-cf5d51810b17.png)

タスク定義を新しいものに更新します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884542/9d90c502-9c9d-16b0-05b7-3b76ffd45924.png)

4\. ブラウザから確認する
クラスター→タスクへと飛び、パブリックIPを検索すると
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884542/141c7b42-7557-19a9-e96d-622d06ce27ca.png)
ローカルで動かしたときと同じ画面が出力された！！
Go(gin)のテストで配列をFormDataとしてPostしたい

# はじめに
タイトルの件で調べても解決に時間がかかってしまったので簡単にまとめてみます

# 解決方法
- url.Valuesに"配列をpostする際は{"1", "2"}と書く
- 構造体のタグにformを指定する
- Bindする

```hoge_controller_test.go
	t.Run("hogeが作成されること", func(t *testing.T) {
		r := controllers.StartMainServer()
		formData := url.Values{
			"form1": {"1", "2"},
	}
		
		req, _ := http.NewRequest("POST", "/hoge_new", strings.NewReader(formData.Encode()))
		req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
		test := httptest.NewRecorder()
		r.ServeHTTP(test, req)
		assert.Equal(t, 200, test.Code)
	})

```

```hoge_controller.go
type Form struct {
	Form1 []string  `form:"form1"`
}

func hoge_new (c *gin.Context) {
	var f Form
	c.Bind(&f)

	fmt.Println(f.Form1)

	c.JSON(200, "OK")
}
```

以下のように配列で受け取ることが確認できました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2889192/5e8836d5-530a-d524-557a-7a1ba0c25a56.png)

# おわりに
url.Valuesに配列を指定する書き方が分からずに詰まってしまいました

# 参考

https://gin-gonic.com/ja/docs/examples/binding-and-validation/

https://stackoverflow.com/questions/63471580/how-to-send-post-form-data-through-a-http-client
モアレグラフィ

# 注意
- アドベントカレンダーで初めて記事を書きます．
- 日本が変 or 解説が間違っている場合があります．
- ご意見いただけますと幸いです．

# 本稿を記述する目的
1. 読者にモアレグラフィについて理解していただく．
2. 記事を通してアウトプットすることで，自身の理解を深める．
3. アドベントカレンダーに参加する

# 執筆経緯
モアレグラフィ生成プログラムを作成し，コンテストに応募しました．
その時得られた考え等を共有したいと思います．

# モアレグラフィとは
まず，モアレについて説明します．
モアレとは，縞模様と縞模様が重なったときに現れる縞(モアレ縞)のことを指します．
モアレ縞の例を示します．横縞と横縞の画像を重ねた時に，中心部に6本ほど縦縞があると思います．これがモアレ縞です．
![moire.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/d8990a43-a575-98ba-d19b-552ce8cff4cc.png)
図 モアレの例

このモアレに画像を埋め込み，アートとして楽しもうというものがモアレグラフィというものです．
モアレグラフィには，基準となる格子，変形した格子の2種類が必要になります．
基準格子は，白黒を繰り返した格子です．
変形格子は，埋め込む画像の輝度から，基準格子を変形させたものです．
変形した格子に基準となる格子を重ねると埋め込まれた画像が現れます．

### モアレのコントロール方法
モアレは，格子と格子の位相差で任意でコントロールすることができます．
格子そのものにも位相を持っているため，例えば，基準格子の1点の画像の位相に位相差を加えることで，任意形状のモアレを生成することができます．

# モノクロモアレグラフィ生成手法
まず1ピッチ(1周期)の画素数を決定します．
次に，元の画像の輝度の平均を1ピッチごとで求めます．
取得できた平均の輝度から位相差に変換します．
```math
p = \frac{b_{ave}}{255} × \pi\\
p:位相差, b_{ave}:平均輝度
```
位相差を用いて，基準となる格子を1ピッチ毎にそれぞれの位相差を加えます．
求まった全画素の位相から輝度を再計算し，変形後の縞を求めることができます．
cosを利用した変形格子の生成例を示します．
```math
I(x,y) = a\cos(\theta(x,y))+b\\
a:輝度振幅,b:背景輝度
```
基準格子と，変形格子，そして，変形格子に基準格子を重ねた時の画像を示します．
![base.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/fd85d5bb-b874-1367-d71e-179e1b1fa446.png)
図 基準格子
![testgrad.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/56e3f73c-a56a-c8d3-82d7-04a078d189bb.png)
図 変形格子
![kasa.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/2c5bd03f-fbbd-dfba-fce5-39ca44e21157.png)
図 変形格子に基準格子を重ねたもの

- 元画像はSIDBAのgirlを利用しました．ありがとうございます．

# カラーモアレグラフィ生成手法
R,G,Bで分離し，各色でモノクロモアレグラフィ生成手法と同じように格子の変形を行います．
最後に，RGBを結合し，1ファイルにします．

![testgrad.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/29a7a917-2c21-6921-d88f-2fd7a11a2376.png)
図 変形格子
![kasa2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/bea5765a-b196-f8e9-e7ad-6bed7eaa7cc8.png)
図 変形格子に基準格子を重ねたもの

- 基準格子は，最初のものと同じです

変形格子だけを見ると何かゆがんだ格子にしか見えませんが，基準格子を重ねることで，物凄く綺麗になりますね．
とても面白いと思います．

以上で，説明を終わります．
モアレグラフィの概要，基本的な生成方法を示しました．

クリスマスなので，モアレグラフィを作成して恋人を驚かしてみてはいかがでしょうか？
モアレに興味があるかた，面白い変形方法を知っている or 思いついた方は，教えていただけると嬉しいです．

それでは皆さん，メリークリスマス🎄!!!

### おまけ
私は，好きなアイドルである岩本蓮加(レンタン)のモアレグラフィを生成して終わります．
![testgrad.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/75dbbd2a-2181-8975-cc9b-61bf4b354232.png)
図 レンタンの変形格子
![rentan2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/a8fbada6-dd9d-1754-054d-8f12c57ebf67.png)
図 基準格子と変形格子を重ねたもの

- 斜め格子を用いた場合
![testgrad.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/2b6e1a54-3e97-8b0b-a7cb-61f910f4fdc5.png)
図 レンタンの変形格子
![rentan3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1640637/dd28eec5-b02c-ea56-8693-d2708c84814f.png)
図 基準格子と変形格子を重ねたもの

斜め格子にする工夫は，また別記事で書こうかなと思います．

レンタンは，モアレグラフィになってもかわいいですね！

- 元画像
https://twitter.com/nogizaka46/status/1510905425981734915
完走を終えての感想(次にチャレンジする方へ向けて)

ついに25日目を迎えました！


１．取り組み方

ステップ１：まずアカウントを作る

ステップ２：カレンダーのテーマを決める

ステップ３：1日ごとのテーマを書き出す
    　　　　　　とりあえず&&とにかく25個、書き出します。　　　　　　

ステップ４：記事のドラフトを書く

ステップ５：イラストを入れたり、見栄えを整えて投稿する

２．チャレンジしたいなと思われた方へ

Qiitaとは、で調べると、「プログラマのための・・・」という文言も見つかるので、つよつよエンジニア
のコミュニティサイトのような印象を受ける方もいらっしゃると思います。

ただ、<a herf="https://qiita.com/about">「Qiitaの思想」</a>には次のように書かれています。

>エンジニアにとって再利用性・汎用性の高い情報が集まる場をつくろう

私の勉強メモが再利用性・汎用性の高いか・・・といわれるとちょっとしりごみしちゃいますが、
誰かの何かにひっかかる可能性が0ではないと思い、チャレンジすることにしました。

記事にすると、構成を考えたり、再度調べたりして勉強になります！
またチャレンジしたいなと思いました。
WordやPowerPointなどをPDFで保存する方法

# WordでPDFを保存する方法
## 1. Wordを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/fbd59887-aa39-5aa4-7192-212605edc81f.png)


## 2. 「ファイル」→「名前を付けて保存...」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/3d45a964-c0bd-acf7-6ab6-4b0094069e47.png)

## 3.​ ファイルの名前と保存する場所を設定
![20221220-214631a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/8f09a3fa-dbab-39ba-d86e-0ee8a6e25dc0.png)

## 4.​ 書き出すファイル形式をpdfにする

### 4-1.​ 「ファイル形式：」を選択
![20221220-214631b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/6ea630a0-994d-28ef-87f5-b7701bacaee0.png)

### 4-2.​ 「PDF」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/1b443252-2979-a305-2597-c346e9830dc8.png)

## 5.​ 「エクスポート」を押して保存する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/9dc859a0-278a-1e50-4922-99e9de898256.png)

# PowerPointでPDFを保存する方法

## 1. PowerPointを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/3f9a9c9a-8b3b-58ca-401d-7ec238123426.png)

## 2. 「ファイル」→「エクスポート...」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/d155e4be-398b-ede3-43d8-eae74dc14b87.png)

## 3.​ ファイルの名前と保存する場所を設定
![名称未設定 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/3df5add8-2b21-7e4b-bacc-680d87a4efce.png)

## 4.​ 「エクスポート」を押して保存する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540178/19e57ab5-0052-40e2-7c15-5e3f8672189a.png)



参考

https://support.microsoft.com/ja-jp/office/save-or-convert-to-pdf-on-your-mac-aa183751-1f09-4b8b-88a4-099a0c7528da

https://support.microsoft.com/ja-jp/office/office-desktop-%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7-pdf-%E3%81%BE%E3%81%9F%E3%81%AF-xps-%E3%81%AB%E4%BF%9D%E5%AD%98%E3%81%BE%E3%81%9F%E3%81%AF%E5%A4%89%E6%8F%9B%E3%81%99%E3%82%8B-d85416c5-7d77-4fd6-a216-6f4bf7c7c110#ID0EBBH=macOS

https://support.microsoft.com/ja-jp/office/powerpoint-%E3%83%97%E3%83%AC%E3%82%BC%E3%83%B3%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92-pdf-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%A7%E4%BF%9D%E5%AD%98%E3%81%99%E3%82%8B-9b5c786b-9c6e-4fe6-81f6-9372f77c47c8
町工場の独力DX事例についてまとめておきました(HILLTOP株式会社)

# １．背景
　HILLTOP株式会社の講演を聞く機会があり、さらに出版されている本を読みました。
　DX事例というとITコンサルが入っているイメージなのですが、ほぼ自力で実現されたようで
　興味深く、まとめたいと思います。
![machine_yubisashi_kosyou.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003921/547a459f-8138-f693-8695-d9c0d5e782bf.png)

書籍
ディズニー、NASAが認めた 遊ぶ鉄工所(山本 昌作 (著))
![HILLTOPさん本.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003921/4ec01a2a-c36c-bc0b-3bf9-ff99e43ab66e.png)


# ２．HILLTOP株式会社について
　会社概要は<a herf="https://hilltop21.co.jp/company/#profile">こちら</a>です。
   ![hilltop.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003921/bdb285c8-6bbd-48f8-c455-0243201010a7.png)
   (HILLTOP本社。筆者撮影。)

# ３．忙しい方へ
　DXを進める上でポイントだなと思った結論(成功のカギ)を先にまとめておきます。
　・「こんな環境で働きたくない、働かせたくない」と思うトップ(社長など)の存在
　　　→トップの熱意、社員への働きかけが成否を左右する！
　・「こんな環境で働きたくない」と思う社員の存在
　　　→ネガティブが原動力！(「現状でいい」派を変革することが全体の変革な気がする)
　・ 常にアンテナを張っているキーマンの存在
　　　→新しい風。
　・ キーマンがこれやろう、と言ったときに実現させるエースの存在
　　　→実働部隊がいないとうまくいかない。

では、順を追って記載していきます！

# ４．「こんな環境で働きたくない」と思うトップ(社長)の存在
## こんな環境とは？
　HILLTOPは現経営陣のお父さんが建てた製作所が原点です。
　本でも触れられていますが、息子さん(長男)が3歳のときに病気になり薬の副作用で聴力を失われました。この会社はそんな息子さんの働き口を思ってのことでした。
　ただ実態は技術があって設立したわけでなく、孫請けの工場。イメージ通りの汚い環境、安い賃金・・・

>「あばらや」のような町工場を到底継ぐ気にはなれなかったのです。

　(『ディズニー、NASAが認めた 遊ぶ鉄工所』p.14)

　しかし、お母さんから「工場を3人で支えてほしい」(兄弟は3人)と懇願され、継ぐことにしました。
　(せっかく取った内定も辞退されたそうです)

# ５．常にアンテナを張っているキーマンの存在

　「4」のような気持ちなので、山本XX氏は現状打破を考えます。
　　**・少品種大量生産で利益の出ないビジネス構造**
　　　→ 多品種少量生産　へ完全移行。ロングテール
　　　　これからの時代ニーズとビジネスのあり方にアンテナを張っていた結果だと思います。

　　**・職人頼りの仕事の仕方**
　　　→ よくある手順書がなく、人の勘と経験による作業。
　　　　これをIT自動化しました。
　　　　→ 人によって品質が違う
　　　　　→ 手順書ないから(※)
　　　　　　→ あらゆるデータをセンターで取得し、自動化に成功。

　　:point_up:手順書、パターン化がうまくいくと思った背景
　　　  ① 炊飯器「ライスレディ」の開発講演を聞いた
　　　　→ ボタンひとつで誰でも同じ品質のご飯が炊ける
　　　　これは「はじめチョロチョロ、なかパッパ」のプロセスやごはんを数値化し分析し可能になったもの。
  ② マクドナルドのバイトマニュアル
　　　　→ 誰でも同じ品質のサービスが可能になる

# ６．キーマンがこれやろう、と言ったときに実現させるエースの存在

　改革は1人ではできないことがほとんどです。
　山本昌作氏が「こうやろう」と方針を示し、三男である山本昌治氏が現場と会話しながら進めていったそうです。これは心強い味方です。

# ７．「こんな環境で働きたくない」と思う社員の存在
　HILLTOPの外観は工場ではないようなポップなデザインですが、内装もおしゃれです。
　どういうオフィスがいいか？社員で話しあったそうです。
　世の中的にはこういう系はどこか他人事になりがちですが、なぜ話し合いができたのか？
  (「これ、私の仕事じゃない」「本業以外をやる時間ない」・・・)
  実はHILLTOPの前身は汚い工場でした。これがモチベーションになったとのこと。
　確かにこれからキレイなオフィスになる、しかも意見が聞いてもらえる、となったら当事者意識が
　芽生えたのだとか。

　:point_up:業務を変革するには、人の行動も変革しないとだな、、と思いました。
　ただ、これは「にわとりが先かたまごが先か」なので、両方を視野に企画していくのが
　よさそうです。

 というわけで、ポイントと内容をざっとまとめてみました。
自分の仕事が変わるというのはストレスを伴うものです(勤怠システムが変わった瞬間、2,3日ストレスを感じること、ありませんか・・・？)
さらに最初は不具合もあるあるです。
トップや企画、実行チームはこれらを見越しつつ、まっすぐ前の道を指し示すこと、ただし意固地にならず柔軟にチャレンジすること、こうしたことも大事なのかなと思いました。
あとはどれだけ味方を増やしていくか、ですね。