OmniAICreator/Qiita-1.07M huggingface dataset:
Workato：新たに追加されたRecipe functions by Workatoコネクターについて

# はじめに
Workatoで、新たに「Recipe functions by Workato」コネクター（以下、「Recipe functionsコネクター」）が追加されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/fe81e5a2-1268-614f-1eb9-fbfce5c28687.png)


もしかしたら、レシピ作成時に「Build recipe function」がStarting pointに追加されていたこと（Callable recipeから変わっていたこと）に気付いた方もいるかもしれません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/71ed0cf6-d0b3-22c0-71e0-0f7152e18936.png)

Recipe functionsコネクターは、これまであった（今もある）Callable Recipeコネクターと似ていますが、レシピから呼び出されるモジュールとしての利用に特化したコネクターとなっています。

Recipe functionsについて、簡単に以下で説明します。

# Callable RecipeとRecipe functionsの違い
Callable Recipeは、レシピから呼び出されるモジュールとしての役割と、API Platformにおけるエンドポイントの役割の両方に対応します。このため、例えばRequest typeやReply typeといった、API Platform固有の（モジュール用途において不要な）設定項目が存在します。また、Callable Recipeでは必ずNameを定義する必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/b409d919-8d93-5053-1581-75698e383790.png)

これに対して、Recipe functionsはモジュール用途としての利用に必要な設定項目（Parameters schema, Result schema）のみが用意されています。つまり、設定項目を必要最低限とし、モジュール用途に特化したコネクターとなっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/e0ed7a80-6da4-fe8e-c4f7-615bd7f6207b.png)

また、Recipe functionsはNameの指定は不要なため、呼び出し元のレシピではレシピ名を指定して利用します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/775d5f1d-d42d-5f11-effb-455df0b7da13.png)

# 簡単な利用方法（レシピ作成方法）
## 呼び出し先（モジュール）レシピの作成
呼び出し先となるレシピの作成方法は、Callable Recipeと殆ど変わりません。大きな違いはNameの指定の有無で、Recipe functionsはNameの指定が不要です（設定項目がありません）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/11ca4067-7414-97d4-345e-1dbcb745bb7b.png)

## 呼び出し先レシピの作成
呼び出し先となるレシピの作成方法も、Callable Recipeとほとんど変わりません。大きな違いは、Recipe functionでRecipe functionsをトリガーとするレシピ名を指定する（Callable Recipeではレシピ内で定義したNameの値を指定する）点になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/64876/072f2ca8-fd8a-cf16-dc98-b2f5d01851ef.png)

# Callable RecipeとRecipe functionsの使い分け
今後作成するレシピにおいては、特別な理由が無ければ、Recipe functionsを使用するのが適当でしょう。

もちろん、Callable Recipeでこれまで同様にレシピのモジュールを作成することは可能です。例えば、呼び出し先の名称とレシピの名称は別々に管理したい場合は、Callable Recipeが有効です。また、API Platformとレシピのモジュール両方で活用したい場合も、Callable Recipeが有効です。用途に応じてCallable RecipeとRecipe functionsを使い分けていただければ宜しいかと思います。

# Callable RecipeからRecipe functionsへの移行は必要か
これまでCallable Recipeで作成したレシピや呼び出し元のレシピは、Callable Recipeのまま利用可能です。
（Recipe functionsへ移行する必要もなく、Callable Recipeのままでこれまで通り利用可能です）

# Callable RecipeとRecipe functionsを相互に変換する方法はあるか
Callable RecipeからRecipe functions、あるいはRecipe functionsからCallable Recipeへ変換する方法はありません。
Realmモデルの単体テストで RLMObject subclasses with the same name cannot be included twice in the same target. Please make sure 'Employee' is only linked once to your current target.

Realmのモデルの単体テストを追加したところ、テストを実行するとAppDelegateで以下のエラーが表示されテストがクラッシュするようになりました。

```
Thread 1: "RLMObject subclasses with the same name cannot be included twice in the same target. Please make sure 'Employee' is only linked once to your current target."
```

原因としてはRealm ObjectのサブクラスとしてEmployeeを定義していますが、そのEmployeeをアプリとテストの両方のTargetに追加していたのが、良くなかったようです。


今回RealmのObjectのサブクラスとしてEmployeeクラスをテスト対象としています。

## ダメだった状態
* Employeeクラスをアプリとテストの両方のターゲットに含めていた

## テスト可能な状態
* Employeeクラスはアプリのターゲットのみに含める
* テストコードの先頭に以下のインポートを追加する
  ```
  @testable import アプリのターゲット名
  ```

このようにすることで、テストコードからEmployeeを参照することができ、Employeeはアプリ側のターゲットのみに含めることができます。

## 参考
https://stackoverflow.com/questions/31002886/class-are-being-linked-more-than-once-in-target


本件とは直接関係ないんだけど、テストケースにアプリ側で必要なPodの依存がすべてふくまれちゃうんだよなぁ。
今回のケースだとRealmSwiftには依存していいけど、Firebaseとかの依存ははずしたいんだけど。。。
ConoHa VPSを立ててみる

こんちわ！初めましての方は初めまして、[みどり](https://twitter.com/Midorichaan2525) です><
この記事は[ConoHa AdventCalender 2021](https://qiita.com/advent-calendar/2021/conoha)の12日目の記事です。

Qiitaのアカウントを作成して初めてのAdvent Calenderなので何を書けばいいのか知りませんが、とりあえずConoHa VPSを立ててみようかなと思いますっ
記事書くの慣れてないから下手なのは許してください...()

> **1. アカウント作成/ログイン**

まぁ、アカウントがないと始まらないよね〜
https://www.conoha.jp/conoha/login/ からログイン 
or
https://www.conoha.jp/conoha/signup からアカウントを作成しましょう！！

サイト右上のこのはモードは有効にすべしっ ↓↓↓
![loginpage.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1184898/daddf231-d928-cb6a-a6d1-738141b3fadb.png)

> **2. ダッシュボード**
![dashboard.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1184898/4e624b9f-4fc4-4fb1-9faf-1e2c866281b5.png)

ログインできたらこの画面になるよ！このはモード可愛い...
ConoHa WINGやVPS、ディスク、イメージ、ネットワーク、セキュリティ、オブジェクトストレージ、DNS、ライセンス、ドメイン、APIなどなど....

> **3. サーバー**

左の サーバー から、画面が変わったら右上の ＋サーバー をクリック
or
画面中央の +追加 をクリック！！

今回は構築してみるだけなので、
- リージョンは 東京
- サービスは VPS
- VPS割引きっぷは 利用しない
- メモリは 1GB
- OSはもちろん Ubuntu
ルートパスワードとネームタグを適当に設定してと...
1GB月額968円は安い...!!!
![スクリーンショット 2021-12-09 15.29.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1184898/6d7036b0-1bbf-523b-84f8-fac0478fc986.png)

> **3. なんか色々してみる**

サーバーリストからVPSを選択して、IPアドレスを確認
ターミナルかTeraTermとかで接続っ
(ssh root@ipaddress)
![スクリーンショット 2021-12-09 15.32.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1184898/1e7386ba-3e9d-84ef-a82a-1ea60be000f7.png)

やったね！サーバーができたよ！


... 




**rmには気をつけろ**
by 某猫もどき

> **4. おわり**

はい、立ててみるだけなのでこれだけだよ...()
初心者でも簡単にサーバー立てれるし、お財布には優しいし、キャラが可愛いしおすすめのVPSですっ！
欲を言うとDDoS対策とか欲しかった...()

DBサーバーとして使うもよし、ゲームサーバー立てるのもよし！
DiscordBotに使うもよし！

ではでは、みどりでした〜

p.s 書くの下手ですまねぇ...
【初心者】EC2をコストに怯えながら使わなくてすむポイント3選

はじめまして。リンクアンドモチベーションの綿引です。

本記事では、 私が ***"EC2 を安く使うため"*** に注意しているポイントをご紹介します。
尚、今回は初心者向けのため "オンデマンドインスタンスを対象" にしたいと思います。

## EC2 作成時に注意するポイント一覧
先に項目の一覧を記載すると以下になります。

- インスタンスタイプは新しいものか？
- EBS ボリュームタイプ/サイズは適切か？
- 停止が可能か？

詳細は以下紹介していこうと思います。
まずは EC2 のコストが何に対して発生するか見てみましょう。

## EC2 のコストについて
EC2 は**「各インスタンス毎に使用された時間分のコストが発生する」**従量課金制です。

https://aws.amazon.com/jp/ec2/pricing/

選択できるインスタンスのタイプは多くの種類があり、それぞれのタイプで性能と時間あたりの使用料金が異なります。

まとめると安く使うコツとしては以下となります。

- 安いインスタンスタイプを選択する
  - 出来るだけ性能が良いものをチョイスしたい
- 許される時間停止しておく

では早速、上記の一覧の項目の詳細を記載していきたいと思います。

## インスタンスタイプは新しいものか？
まず簡単にインスタンスタイプの説明をします。
t3.medium を例に取ると、以下のように「インスタンスファミリー・世代・サイズ」に分かれます。

|項目|説明|
|:-:|:-:|
|t|インスタンスファミリー|
|3|世代|
|medium|サイズ|

インスタンスファミリーが同じなら基本的にこの世代が新しい方が**高性能かつ安価**です。
なのでそこで個人的にインスタンスタイプをざっくり決めたら、"世代が最新のもの" を選ぶようにしています。

サイズは「micro」や「medium」、「large」などがあり、大きいものの方が高性能で高価になります。
インスタンスファミリーは「汎用」や「コンピューティング最適化」と言ったモデルに分かれており、それぞれで「t」や「c」といった文字列がつく形になっています。

https://aws.amazon.com/jp/ec2/instance-types/

また **t3a.medium** など世代の後に「a」や「g」などの文字列が入ってるインスタンスタイプもあり、例えば「a」が入ってると CPU が通常の Intel ではなく AMD のものを使っており、t3.medium より安価だったりします。

このようにインスタンスタイプは様々な種類があり、選択に迷ってしまうこともあるかと思いますが、それぞれの性能・コストを確認した上で「このインスタンスタイプにしよう！」と決めたら、**世代が最新か？**や、**新しく「a」などの文字列がついたものが出てないか？**なども見てみるとより安く高性能なモデルが使えるかもしれません。

## EBS ボリュームタイプ/サイズは適切か？
EBS ボリュームタイプとサイズに関しても性能・コストに関わってきます。

https://aws.amazon.com/jp/ebs/pricing/

ボリュームタイプに関しては速度的な要件が厳しくなければ基本的にデフォルトの「EBS 汎用 SSD(gp2)」でいいかなと思っていますが、今だと2020年に発表された**「EBS 汎用 SSD(gp3)」**の方が安くいためこちらがファーストチョイスかなと思っています。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html

ただ申し訳ないですが私がそこまで「EBS 汎用 SSD(gp3)」を使ったことないので、あくまで上記の公式を見た見解です。
今後は gp3 は積極的に使っていこうと思います。

サイズに関しては容量によってコストがかかってくるので、余程の要件がなければほどほどのサイズにしましょう。

## 停止が可能か？
最後に停止が可能かという点ですが、先述した通り EC2 は稼働時間でコストが発生します。
要件で常時起動させておかなければならない場合は仕方ありませんが、そうでない場合は**「可能な限り停止する」**ことが大事になってきますため、個人的の勉強や検証のためで使いたいなど、停止が問題ない場合は基本的に停止しておきましょう。

ただ「日中だけは起動しておきたい！」など時間指定もあるかと思います。
その場合は、日次で停止や起動を行うのも面倒なので**自動停止/起動の設定**を入れてしまいましょう。

EC2 の自動停止/起動を行う方法としては、以下のようなやり方があるので是非参考にしてみてください。

1. 自動起動/停止用の Lambda 関数を作成し CloudWatch Events にて定期実行する
1. **AWS Instance Scheduler** を使用する

1つ目に関しては Lambda 関数は自身を作成し、その Lambda 関数を CloudWatch Events の機能で定期実行する手法です。
CloudWatch Events でのスケジュール設定も cron 式で出来たりするので、比較的わかりやすいかなと思います。

2つ目は 「AWS Instance Scheduler」 という AWS ソリューションを使う方法です。
CloudFormation テンプレートを適用することで自動停止/起動に必要な AWS サービスが作成されるため、使用者は Lambda 関数などコードを書かなくて良い点が魅力です。

https://aws.amazon.com/jp/solutions/instance-scheduler

他にも手法はあるかもしれませんが、参考にして頂けると良いかなと思います。

## おわりに
今回は私が EC2 を安く使うために注意しているポイントをご紹介させて頂きました。

本記事はオンデマンドインスタンスを対象としたため、リザーブドインスタンスや Savings Plans については語りませんでしたが、こちらも**「常に稼働させておくような EC2 を長期間使用する場合」**はコスト削減の有効な手段なので興味があれば見て頂けると良いかと思います。

最後にこの記事が見て頂いた方の何かの参考になれば幸いです。
neosでlogix その18

#概要

niosでlogixやってみる。
Demultiplexノード
Multiplexノードを使ってみた。

#写真

![2021-12-09 06.15.05.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/c84f851b-e9e1-5b6c-200d-f2fbd05c3472.jpeg)


#Demultiplex

```
Inputs
 	Object	Value
 	Object	DefaultValue
 	Int	Index
Outputs
 	Object	ValueOutputs.[0]
 	Object	ValueOutputs.[1]
 	Object	ValueOutputs.[2]
 	Int	OutputCount
```

#Multiplex

```
Inputs
 	Float	[0]
 	Float	[1]
 	Int	Index
Outputs
 	Float	*
 	Int	InputCount
```

以上。
データチェック自動化のススメ

#はじめに
今年もこの時期がやってきました。
毎年何について書こうか悩むのですが、今回は昨年から取り組んでいるデータチェック自動化について書くことにしました。
今期は特に工数削減に注力しており、データチェック自動化の導入が大きく貢献してくれたのでその成果を記載していきたいと思います。

検証工数の削減を検討されている方の参考になれば幸いです。


#データチェック自動化とはなにか
**仕様書とマスターデータを機械的に比較してデータの整合性を担保する検証**です。
データ検証、データチェックなど、他にも呼び方があるかもしれませんが、弊社ではこの検証をデータチェック自動化と呼んでいます。

#マスターチェッカー導入のメリット
スマホゲームの場合、ガチャやイベントクエストなどアプリ内の動作の多くはマスターで制御されていると思います。
開催期間、消費スタミナ、獲得経験値etc......、必要な各種データをマスターデータに登録することである程度自由にイベントなどを開催することが可能です。
反面、登録したマスターデータに誤りがあると正常に開催されなかったり意図しない動作をしてしまうため、マスターデータが更新された箇所は必ず検証を行う必要があります。


検証を行う場合は実際にマスターデータを反映してアプリ上で確認するのが一般的です。
アプリ上での検証はテスト環境の準備や、再現確認のために同じ手順を何度も繰り返して確認を行う必要があったりと中々に時間がかかる作業です。
また人が確認を行うため、手順違いによる見逃しや見間違いによるミスなどが発生してしまう可能性もあります。

同じイベントを開催する場合、特に仕様変更が入らない限りは基本的に同じ箇所のマスターデータを次のイベント用に更新するだけです。
つまり更新予定のマスターデータと更新箇所がわかっていれば、それぞれを比較して一致していることを確認することで、意図通りの状態になっていることの担保がとれているため、アプリ上での確認を不要にすることができ、確認工数を抑えることができます。
また、ツール上で機械的に比較する形になるため、設定値のミスや誤字、脱字などの人の目では見逃しやすいミスも検知しやすくなります。

### つまり、確認工数の削減と検証精度の向上の両方が見込めるのです！


#注意点
データチェック自動化での確認には、いくつか注意点があります。

**①データチェック自動化で検証を行うデータの影響範囲を確認する**
検証対象のマスターデータを使用する機能や影響範囲についてプロダクト側のエンジニアに、データチェック自動化での検証内容についてレビュー(検証内容のすり合わせ)を行っておいた方がよいです。影響がないと思っていたけど実は…なんてことも起こりえますので、事前に問題がないことを確認しておきましょう。

**②マスターデータが正しく反映されていることを確認する**
いくらマスターデータが正しいことを確認できていたとしても、アプリに反映されていなければ意味がありません。
変更箇所全てを確認する必要はないと思いますが、更新したマスターデータで動作する機能を実際にアプリ上で確認したりサポートツール※などで確認を行ったほうがよいです。
※サポートツールとはサーバー上に反映されているマスターデータをブラウザなどで確認できるツールのことです。

**③画像の内容はデータチェック自動化では確認不可**
データチェック自動化でも画像のファイル名や設定の有無はチェック可能ですが、画像の内容については確認ができません。
こちらもアプリ上やサポートツールで確認する必要があります。


#導入例
データチェック自動化は大量のデータ確認が必要な箇所や、データを更新する箇所、内容が固定化されている施策、機能に導入すると効果が大きいです。

実際に私が担当しているタイトルで導入した施策と導入効果を紹介します。


**◆事例1**
1つ目はキャラクターの強化機能です。
確認するデータ量が多く、スキルの内容や強化素材の値が固定されているため導入しやすい機能でした。
以下2点が確認箇所です。

- スキル効果確認
- 強化素材の設定確認



導入前は1キャラクターあたり300項目のテストケース数が導入後は20項目まで削減でき、確認工数は**約93％削減**できました。


**◆事例2**
2つ目はガチャです。
設定する箇所や設定内容は変更点がないため、データチェック自動化の導入がしやすく、また検証対象のガチャ本数が多いため導入時の削減効果も見込める機能でした。
以下4点が確認箇所です。

- 開催期間
- 排出カード
- 価格
- おまけ（おまけが付くガチャの場合）

導入前はガチャ1本あたり70項目のテストケース数が、導入後はガチャ1本あたり10項目まで削減でき、確認工数は**約90％削減**できました。


#さいごに
導入にあたり、データを比較するための仕組みを用意したり、プロダクト側と認識のすり合わせを行うなど事前準備にも工数がかかります。
ですが導入できれば効率よく、精度高く検証が行えるようになると思いますので、導入してみてはいかがでしょうか。
【Harmoware-VIS】Mapboxなどの外部マップを非表示又は変更

#Harmoware-VIS とは

https://qiita.com/ucl_Harmoware_VIS/items/e861e0f651ffde647b6a

#Mapboxなどの外部マップを非表示又は変更

###**非表示**
[`HarmoVisLayers`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#harmovislayers) コンポーネントのプロパティの `visible` に false を設定します。

```javascript
<HarmoVisLayers visible={false} ..... />
```
`visible` のデフォルト値は true です。

###**変更**
[`HarmoVisLayers`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#harmovislayers) コンポーネントのプロパティの `mapStyle` に [Mapbox Style Specification](https://docs.mapbox.com/mapbox-gl-js/style-spec/) で説明されているスキーマに準拠した JSON オブジェクト、またはそのような JSON への URL を設定します。

```javascript
<HarmoVisLayers mapStyle={'mapbox://styles/mapbox/light-v10'} ..... />
```

`mapStyle`のデフォルト値は以下です。

```javascript
mapStyle: 'mapbox://styles/mapbox/dark-v8',
```

その他の情報は [Mapbox のリファレンス](https://docs.mapbox.com/mapbox-gl-js/api/map/)を参照してください。

[`HarmoVisLayers`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#harmovislayers) コンポーネントのプロパティの `mapStyle` に Mapbox のマップを利用する設定をする場合は、[`HarmoVisLayers`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#harmovislayers) コンポーネントのプロパティの `mapboxApiAccessToken` にアクセストークンの設定が必要です。
[React] keyboardイベントを追加する

## 概要

（[zenn.devにも投稿している記事](https://zenn.dev/gashi/articles/20211209-article013)です。）
YouTubeなどで音量を調節したり、動画を検索したりするときに、keyboardを用いて情報を入力することが多くある。
なので、keyboardイベントを理解して、そのような実装に対応できるようにメモを残しておく。

例として、「オブジェクトの移動」をキーボードで行ってみる。

- 「矢印」を入力したときに、対象のオブジェクトが現在の位置から5px動くように設計。
- 「スペースキー」を入力したときに、対象のオブジェクトの色をランダムに変更するように設計。

![sc.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1480416/665e3300-b765-6afc-ad8a-373e89417a35.gif)

## keyboardイベントの種類

1. `onKeyDown`: キーが押されたときに発動。
2. `onKeyUp`: キーを話したときに発動。
3. `onKeyPress`: 文字や数字を入力するキーボードを押したときに発動。これはデバイス依存があり、廃止されたものなので、現在は使用を推奨されていない。

## source code

```javascript
// App.tsx
import React, { useState } from 'react';
import './App.css';

function App() {
  const [top, setTop] = useState(0);
  const [left, setLeft] = useState(0);
  const [backgroundColor, setBackgroundColor] = useState('#ffffff')

  const keyDownHandler = (e: React.KeyboardEvent<HTMLDivElement>) => {
    const key = e.code;

    if (key === 'ArrowUp') {
      setTop((top) => top - 10);
    }

    if (key === 'ArrowDown') {
      setTop((top) => top + 10);
    }

    if (key === 'ArrowLeft') {
      setLeft((left) => left - 10);
    }

    if (key === 'ArrowRight') {
      setLeft((left) => left + 10);
    }

    if (key === 'Space') {
      let color = Math.floor(Math.random() * 0xFFFFFF).toString(16);
      for(let count = color.length; count < 6; count++) {
        color = '0' + color;                     
      }
      setBackgroundColor('#' + color);
    }
  }

  return (
    <div
      className="container"
      tabIndex={0}
      onKeyDown={keyDownHandler}
    >
      <div
        className="box"
        style={{ 
          top: top,
          left: left,
          backgroundColor: backgroundColor,
        }}></div>
    </div>
  );
}

export default App;
```

```css
.container {
  height: 100vh;
  width: 100vw;
}

.box {
  border: 1px solid black;
  height: 100px;
  position: fixed;
  width: 100px;
}
```

### 実装ポイント

- オブジェクトの移動には、`top`, `left`の座標位置で調整する。
- 色の変更には、`backgroundColor`の変更で調整する。
- 矢印キーを押すことで、その方向に移動するための値がセットされる。
- spaceキーを押すことで、colorのhex6桁をランダムに生成し、colorを作成する。この際、単純にランダム生成すると、0が考慮されずに6桁にならない場合がある（例：#004455の場合、上2桁の00が省略されてしまう）。そうならないようにfor分を追加。
- state管理は`useState`を使用。座標位置とcolorとを管理。

```javascript
let color = Math.floor(Math.random() * 0xFFFFFF).toString(16);
for(let count = color.length; count < 6; count++) {
  color = '0' + color;                     
}
setBackgroundColor('#' + color);
```

## reference

- [SyntheticEvent](https://reactjs.org/docs/events.html#keyboard-events)
- [6ケタのカラーコードをランダムで生成する色々な方法](https://q-az.net/random-color-code/)
- [MDN - KeyboardEvent](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent)
- [React + TypeScript: Handling Keyboard Events](https://www.kindacode.com/article/react-typescript-handling-keyboard-events/)
Github Actionsメモ

# はじめに
普段開発でGithubを利用しているので、気になっていたGithub Actionsについて調べてみました。
ちなみに、CIにはTeamCityやJenkinsを使っているので、その辺りと比較してどうか？といった視点でまとめています。

## 人気＠検索ワード

Github Actionsが徐々に広まってきているのが見て取れます。人気の技術は抑えたいところなので覚える価値は高そう？

![2021-11-25_14h46_07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2322565/51cf97fa-7654-0726-4f39-5afb932c4865.png)

と、思いきやJenkinsおじさん圧倒的……

![2021-11-25_14h46_23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2322565/17b4598f-96e9-0a1d-af11-1de49a096c6a.png)

## 機能の違い

意外と(?)できることに大きな違いはないように見えます。
実際に導入してみると違いが見えてくるかも知れませんが、、

## Github Actionsの良いところ

### CI用の設定がソースコードとセットで管理される

TeamCity/JenkinsではCI用の設定を別のサーバ上の設定として管理することになりますが、Github Actionsではリポジトリ内ののyaml形式の1ファイルとして管理できます。
Github Actionsに限った話ではないですが、TeamCity/Jenkinsで生きている身からするとこれは魅力的です。

### OSSのアクションを利用できる

OSSとして様々なアクションが公開されています。
よくある設定であれば、OSSのアクションを組み合わせるだけでCIの設定が完了してしまいます。

### 導入が簡単

ビルド～テストを通すだけなら30分程度で実現できました。簡単。

## Github Actionsの良くないところ

CI用の設定がソースコードとセットで管理されるので、最初の導入時は無駄なコミットを重ねることになります。
[act](https://github.com/nektos/act)などを活用することでこの負担は軽減できると思いますが、自分の開発環境はWindowsなので対応していませんでした。残念。

→ workflow_dispatchを使うことで任意のタイミングでトリガーできるので、導入しやすくなると教えていただきました。Thx!
鬼車(oniguruma)に困ってる人たちへ：Redhat8系 PHP install 

最近PHPをインストールすると鬼車にハマります。

rpmからonigurumaをインストールする方法がありますが、
remiリポジトリを入れれば簡単に解決出来ます。

```
$ sudo yum install https://rpms.remirepo.net/enterprise/remi-release-8.rpm

remi-release-8.rpm                                                                            26 kB/s |  26 kB     00:01
Dependencies resolved.
=============================================================================================================================
 Package                       Architecture            Version                           Repository                     Size
=============================================================================================================================
Installing:
 remi-release                  noarch                  8.5-2.el8.remi                    @commandline                   26 k

Transaction Summary
=============================================================================================================================
Install  1 Package

・・・ (割愛) ・・・

Installed:
  remi-release-8.5-2.el8.remi.noarch

Complete!
```

remiリポジトリを有効にして、oniguruma-devel をインストールします。

```
$ sudo yum install --enablerepos=remi oniguruma-devel

=============================================================================================================================
 Package                             Architecture           Version                               Repository            Size
=============================================================================================================================
Installing:
 oniguruma5php-devel                 x86_64                 6.9.7.1-1.el8.remi                    remi                  67 k
Installing dependencies:
 oniguruma5php                       x86_64                 6.9.7.1-1.el8.remi                    remi                 210 k

Transaction Summary
=============================================================================================================================
Install  2 Packages

・・・ (割愛) ・・・

Installed:
  oniguruma5php-6.9.7.1-1.el8.remi.x86_64                    oniguruma5php-devel-6.9.7.1-1.el8.remi.x86_64

Complete!
```

redhat8、 RockyLinux、 AlmaLinuxでも同様に対応出来ると思います。
【Harmoware-VIS】移動体アイコンの詳細な表示コントロール

#Harmoware-VIS とは

https://qiita.com/ucl_Harmoware_VIS/items/e861e0f651ffde647b6a

#移動体アイコンの詳細な表示コントロール

Harmoware-VIS は移動体アイコンの「表示位置」は移動データに定義した２点の位置と時間から計算しますが、その他の項目は移動データへの定義そのままなので、例えば２点間を移動中にサイズや色や方向、グラフの値などは変化しません。

また、既定ではアーチ（[`MovesLayer`](https://qiita.com/ucl_Harmoware_VIS/items/cc65d90488d2f0d66ae1#moveslayer) の`optionArcVisible`）や直線（[`MovesLayer`](https://qiita.com/ucl_Harmoware_VIS/items/cc65d90488d2f0d66ae1#moveslayer) の`optionLineVisible`）の表示は直近の２点間のみとなります。

この部分をカスタマイズしたい場合、Harmoware-VIS に登録した移動データ（ [`movesbase`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#movesbase-object-array) ）から、表示用の移動体のデータ（ [`movedData`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#moveddata-object-array) ）を生成する処理をカスタマイズするオーバーライド関数を使用することで実現できます。

オーバーライド関数を登録する書式

```javascript
this.props.actions.setMovesOptionFunc(getMovesOptionFunc);
```

引数となる getMovesOptionFunc の関数書式

```javascript
const getMovesOptionFunc(props,index1,index2) => object
```

オーバーライド関数は１移動体（`index1`）毎にコールします。

| 引数 | 説明 | 
| -------- | -------- |
| props | アプリのルートの[プロパティ](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#api%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9) |
| index1 | 移動データ[`movesbase`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#movesbase-object-array)内の処理中の移動体の index |
| index2 | 移動データ[`movesbase`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#movesbase-object-array)内の operation 配列の該当時刻（[`settime`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#settime-number)）データの index |

リターン値は既定の移動体のデータ（ [`movedData`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#moveddata-object-array) ）に上書きされますので注意してください。
既定では settime 、 position 、 sourcePosition 、 targetPosition 、 color 、 direction 、 sourceColor 、 targetColor 、 movesbaseidx 及び、その他の [`movesbase`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#movesbase-object-array) に含まれる要素が[`movedData`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#moveddata-object-array)にコピーされます。

オーバーライド関数のコード例
（`getGraphValue(n)` はグラフのデータを取得する関数を想定）

```javascript
const getMovesOptionFunc(props,index1,index2) => {
    const {settime, movesbase} = props;
    const {operation} = movesbase[index1];
    const currentData = operation[index2];
    const optElevation = [];
    optElevation[0] = getGraphValue0(settime,currentData);
    optElevation[1] = getGraphValue1(settime,currentData);
    optElevation[2] = getGraphValue2(settime,currentData);
    optElevation[3] = getGraphValue3(settime,currentData);
    const optColor = [[255,0,0],[0,255,0],[0,0,255],[255,255,255]];
    return {optElevation,optColor};
}
```

※注意※
オーバーライド関数の引数の Harmoware-VIS の プロパティの [`movedData`](https://qiita.com/ucl_Harmoware_VIS/items/ea97c5e0e112a3d0ecca#moveddata-object-array) は、前回の表示済データですのでご注意ください。
RHEL設計構築時に適用するpatchを検索する方法(備忘録)

### RHEL設計構築時に適用するpatchを検索する方法

redhatのカスタマーポータルに登録しログインする。

以下のサイトで、条件等を指定し検索する。
・製品名 (ex Red Hat Enterprise Linux)
・バージョン (ex 8.2)
・重要度 (ex Important,Critical)

設計項目に関連するもの、OS全体に関連するものを選択し、
条件にあるものであれば、「解決法」のサイトへ飛び
設計項目の追加、修正手順を作成する。


https://access.redhat.com/security/security-updates/#/security-advisories
pyenv-win をインストールしても'pyenv'が認識できないときの解決方法

#前書き
いろいろな記事を参考に、Windowsにおいてpyenvを使用できるようにpyenv-winをインストールしてみるものの、pyenvが認識されていないと出てしまい困ってしまいました。
やってみたら解決方法は意外と簡単でした。
同じように躓いてしまう人がいると思うので記事にしておきます。

##現象
インストール後にバージョン確認をしてみると、環境変数の設定もしたのに
以下のように出てきてしまいます。

```
>pyenv --version
'pyenv' is not recognized as an internal or external command, operable program or batch file
```

## 解決方法
pyenv-winをインストールした以下のフォルダを開きます。

:::note info
C:\Users\<ユーザー名>\.pyenv\pyenv-win\bin
:::

このフォルダ内にある

:::note info
pyenv.ps1あるいはpyenv.batを実行します。
:::


# 追加情報

## PythonのバージョンをSystemに戻す。
pyenv-winには、systemへのパスがなく、元に戻せなくて焦ってしまいます。

Pythonのバージョンを戻すために参考にしてください。: [pyenv-winのversionsにSystemを追加する](https://qiita.com/1219mai0410/items/e73a729b6f22eaababe7)