OmniAICreator/Qiita-1.07M huggingface dataset:
Rubyのネイティブ拡張をRustで作成してgemとして公開した

先日まで[RustでRubyのネイティブ拡張をビルドする方法](https://qiita.com/irxground/items/f9119282585535629c47)を調べていたのだけど、やっと ruby gems として公開するところまでもっていけた。
調子にのってかなり大胆な名前を付けてしまった。

# hello_rust_gem

RubyGems: https://rubygems.org/gems/hello_rust
GitHub: https://github.com/irxground/hello_rust_gem
（コードレビューしていただけると大変助かります！！）

このgem自体は意味がなく、RustでRubyのgemを書きたいときの参考にできることを目的として作成した。
hello_rust_gemは他のライブラリに一切依存していない。（ただし、`rspec`のような開発時に利用するライブラリは除く）

## 使い方

```ruby
require "hello_rust"

p HelloRust::VERSION
```

## 各ファイルの説明

### `src/lib.rs`

このファイルはRubyのネイティブ拡張の本体部分になる。
中身は `HelloRust` モジュールおよび `HelloRust::VERSION` 定数の定義のみなので、大したことはしていない。
本物のネイティブ拡張を書くときはここを拡張していけばよい。

### `Cargo.toml`

Rustプロジェクトの定義。重要なのは `crate-type = ["cdylib"]` の部分のみ

### `build.rs`

RustのコードからRuby APIをリンクするための設定を生成している。 `build.rs` は `cargo build` するときに自動的に呼ばれる。

### `lib/hello_rust.rb`

これは外から `require "hello_rust"` したときに読み込まれるファイルになる。
いきなりネイティブライブラリを読み込むようにすると、いざRubyコードが書きたくなった時に困るかもしれないので最初の入り口はRubyファイルにしておくとよい。というより、 `bundle gem --ext` がそうなのでそれに則った。

中で `require "hello_rust/hello_rust"` しているが、この部分でネイティブライブラリを読み込んでいる。

### `hello_rust.gemspec`

RubyGems の設定を書くファイル。今回は例として、`Cargo.toml` に書かれたデータを再利用してみたが、そうする必要はない。（が、バージョン番号の更新はミスしやすいのでこの例のように一か所にまとめた方が良いかもしれない）

重要なのは `spec.extensions = ["ext/Rakefile"]` の部分で、
`gem install` するとソースコードを配置した後、ネイティブ拡張をビルドするために `ext/Rakefile` が実行される。

### `Rakefile`

開発者が使う `rake` コマンドのための Rakefile
`rake` で成果物を消して、ビルドして、テストを実行する。
`rake fmt` でRustとRubyのフォーマッターが走る。
その他については `rake -T` を参照。

### `ext/Rakefile`

gemspecに書いた通り、 `gem install` の際に呼ばれる。
`RUBYLIBDIR` という環境変数が渡されるのでそこにネイティブライブラリを配置する。
今回は `require "hello_rust/hello_rust"` で読み込めるように、ファイルパスは `$RUBYLIBDIR/hello_rust/hello_rust.so` に（Linuxの場合）なる。

### `ext/build_task.rb`

ローカル開発するときとgemをインストールするときは、どちらもコンパイルして適切なパスにライブラリを配置することになるので、共通する部分をここにまとめた。

Windowsでビルドするときには、`RUSTUP_TOOLCHAIN` 環境変数を設定している。
[RubyInstaller](https://rubyinstaller.org/) で入るRubyはmingwだが、WindowsでのRustはmingwとmsvcの二種類から選べるので、mingwを強制するため。

### それ以外

あとはテストやライセンスファイル等。
`spec/hello_rust_spec.rb` は `HelloRust::VERSION` をテストしており、最小限だがネイティブライブラリのコンパイルに失敗すると気づけるテストにはなっている。

## 今後

だいたいのプラットフォームで動くことは確認できたので、CIを充実させていきたい。
[Linux] VirtualBoxにCentOSをインストールするとき画面が見切れてしまう場合

#VirtualBoxにCentOSをインストールするとき画面が見切れてしまう場合

###VirtualBoxにCentOSをインストールしてみた

昨日(2020/12/16)、VirtualBoxにCentOSをインストールしてみたのですが、きちんとインストールできたのか、自分でもよくわからなかったんです。

###なぜよくわからなかったのか？

CentOSをインストールするときに、画面が見切れてしまって設定したい箇所をクリックすることができなかったからなのです。

###googleで検索しました

検索してみた結果、そもそも的に何がなんだかまったくよくわかっていなかったのですが、画面が見切れてしまうのは、解像度の問題であるということがわかりました！

###CentOSをインストールするとき、解像度を指定するには？

![001a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/897250/40f0cb88-48f2-1bb4-0b7c-d7f2d2079249.png)

CentOSインストール時に解像度を指定することができるらしく、上の図のように resolution=1440x900 のように記述すれば良いとのことなのです。

![002a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/897250/ea6dae8f-a09c-c7ca-971d-1ac9f5bd4d8d.png)

インストール途中の画面を貼り付けても、いまいちわかりづらいとは思いますが、画面は見切れることなく、設定したい箇所を設定することができました！

![003a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/897250/1dfcdff9-0cf9-6c77-bbc9-f404a899e9c9.png)

ところが、インストールが進んでいくうちに、また表示が小さくなってしまいました！（どういうことなの……）

これだと、インストールが終わった後、システムの再起動というボタンをクリックできないわけですね。

このボタンについては、キーボードで(Alt + R だったかな)を押下することで対応することができまして、無事CentOSを起動することができました！

![005a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/897250/3675de4f-50a9-81f4-97df-f10f10f5b53f.png)

ちょっと画面小さいですけど……
【初心者でもわかる】親子関係をもつチェックボックスで、チェックを連動させる方法

# どうも7noteです。チェックボックスの連動処理を実装します。

今回作っていくのは以下のような仕様のチェックボックスです。

- 親子関係のあるチェックボックス。（例：大阪府➡大阪市、吹田市、堺市・・・）
- 親がチェックされたら、すべての子にチェックをつける。
- 子がすべてチェックされたら、親にチェックをつける。
- 子がすべてチェックが外れたら、親のチェックを外す。

![sample.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/661092/c2a38b1a-74a7-0e29-24c0-688809eec82f.gif)


それでは、実際にチェックボックスの連動処理のソースをどうぞ。

## 連動するチェックボックスの書き方

```index.html
<dl class="preflist">
  <dt><label><input type="checkbox" name="prefA" value="東京">東京</label></dt>
  <dd><label><input type="checkbox" name="prefB" value="○○区">○○区</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○区">○○区</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○区">○○区</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○区">○○区</label></dd>
</dl>

<dl class="preflist">
  <dt><label><input type="checkbox" name="prefA" value="大阪">大阪</label></dt>
  <dd><label><input type="checkbox" name="prefA" value="大阪市">大阪市</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○市">○○市</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○市">○○市</label></dd>
</dl>

<dl class="preflist">
  <dt><label><input type="checkbox" name="prefA" value="福岡">福岡</label></dt>
  <dd><label><input type="checkbox" name="prefA" value="福岡市">福岡市</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○市">○○市</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○市">○○市</label></dd>
  <dd><label><input type="checkbox" name="prefB" value="○○市">○○市</label></dd>
</dl>
```



```style.css
dl + dl {
  margin: 20px 0 0;
}
```


```script.js
$(".preflist dt input[type='checkbox']").change(function () {                   // dtのinput（都道府県）が変更された時
  var area = $(this).parents(".preflist").find("dd input[type='checkbox']");    // 選択された都道府県の市区町村を変数に格納
  if ($(this).is(":checked")) {          // チェックがついた時は、、、
    area.prop("checked",true);           // 選択した都道府県の市区町村全てをチェックする
  } else {
    area.prop("checked",false);          // 選択した都道府県の市区町村のチェックを全て外す
  }
});

$(".preflist dd input[type='checkbox']").change(function () {  // ddのinput（市区町村）が変更された時
  var length = $(this).parents(".preflist").find("dd").length; // 兄弟要素（ほかの市区町村）を含めて何個あるか数えて変数に入れる
  var checked_length = $(this).parents(".preflist").find("dd input:checked").length;  // 既にチェックがついている市区町村が何個か数えて変数に入れる
  var pref = $(this).parents(".preflist").find("dt input");  //選択された市区町村の親の都道府県を変数に格納
if(checked_length == 0){                   // もしチェックが0件だったら
    pref.prop("checked",false);            // 都道府県のチェックを外す
  } else if(length == checked_length) {    // もしチェックが全てついていたら
    pref.prop("checked",true);             // 都道府県のチェックを付ける
  }
});
```

## 解説

まずhtml側で、親にあたるチェックボックスを`<dt>`、子にあたるチェックボックスを`<dd>`とします。
主にjsの処理の解説になりますが、親チェックボックスをクリックした時と、子チェックボックスをクリックした時の2種類の処理に分けます。

親チェックボックスをクリックした際は2つのパターンがあり、親がチェックが付けば子もチェックをつける。もしくは親がチェックはずれたときに子もチェックを外す。

子がチェックされた時は、子の数と、既にチェックがついている子の数を取得してif文で分岐を行います。もし一個もチェックが入っていない時は親のチェックも外し、全ての子がチェックがついた時は親にもチェックをつける処理をしています。

#### おそまつ！
~ Qiitaで毎日投稿中!! ~
[【初心者向け】WEB制作のちょいテク詰め合わせ](https://qiita.com/7note)
【初心者】PHPで配列の重複を数える

# PHPで配列の値が重複しているのかの確認
配列の中に同じ値が重複していないか（いくつ重複しているか）を確認するためには…

```php
$n = ["HND", "NRT", "KIX", "NGO", "NGO"];
$value_count = array_count_values($n);
```
こちらの、array_count_values関数を使用すると…

```php
$n = ["HND", "NRT", "KIX", "NGO", "NGO"];
$value_count = array_count_values($n);
print_r($value_count)
// 出力の結果がこちら
Array
(
    [HND] => 1
    [NRT] => 1
    [KIX] => 1
    [NGO] => 2
)
```
このような感じで、どの値が配列内にいくつあるかがわかるようになる。

配列内の重複の確認は、覚えておいて損なことはないんだろうなと思った。
ValueError: X must be an iterable in weisfeiler_lehman.py


```python
G=[#networkx graphs]
G_grakel=grakel.graph_from_networkx(G, node_labels_tag='label')
gk=grakel.WeisfeilerLehman(n_iter=3,normalize=True)
K,base_kernel=gk.fit_transform(G_grakel)
```

```python
ValueError                                Traceback (most recent call last)
<ipython-input-2-2589f83f6ffe> in <module>
     57 G_grakel=grakel.graph_from_networkx(G, node_labels_tag='label')
     58 gk=grakel.WeisfeilerLehman(n_iter=3,normalize=True)
---> 59 K,base_kernel=gk.fit_transform(G_grakel)
     60 print(K)
     61 

~/anaconda3/lib/python3.7/site-packages/grakel/kernels/weisfeiler_lehman.py in fit_transform(self, X, y)
    295             raise ValueError('transform input cannot be None')
    296         else:
--> 297             km, self.X = self.parse_input(X)
    298 
    299         self._X_diag = np.diagonal(km)

~/anaconda3/lib/python3.7/site-packages/grakel/kernels/weisfeiler_lehman.py in parse_input(self, X)
    142             nx = 0
    143             Gs_ed, L, distinct_values, extras = dict(), dict(), set(), dict()
--> 144             for (idx, x) in enumerate(iter(X)):
    145                 is_iter = isinstance(x, collections.Iterable)
    146                 if is_iter:

~/anaconda3/lib/python3.7/site-packages/grakel/utils.py in graph_from_networkx(X, node_labels_tag, edge_labels_tag, edge_weight_tag, as_Graph)
    313 
    314     if not isinstance(X, Iterable):
--> 315         raise ValueError('X must be an iterable')
    316 
    317     if v2:

ValueError: X must be an iterable

```
原因:
代入したグラフ配列GがNoneTypeだった
【Android】drawableとmipmapの違い

#プログラミング勉強日記
2020年12月17日
mipmapとdrawableの違いがいまいちわからなかったので簡単にまとめる。

#drawableとmipmapとは
　mipmapは3Dで使われていて、遠くの物体には荒いテクスチャ－で、近くの物体には細かいテクスチャーを使う技術である。
　Androidは3Dではないが、drawableで似たようなことが行われている。端末のピクセルサイズに応じてサイズの異なる画像を用意することで画面密度が荒い端末ではメモリー消費量を節約して、画面密度が細かい端末では高精細な画像を適用する qualifierという仕組みである。

#drawableとmipmapの違い
　drableに指定されている画像は端末のピクセルサイズを元にxxhdpiの画像を使用し、mipmapに指定されている画像は描画するときの画面密度を元に適切な画像を切り替えてxxhdpiの画像を使用する。画像では拡大より縮小のほうが画質劣化が少ないことからも、drawableなxxhdpiを拡大するより<b>mipmapなxxxhdpiを縮小したほうが画質の劣化を抑える</b>ことができる。

#結論
- 基本的にアプリアイコンはmipmapだけでいい
- 画像リソースの場合はdrawable
- アプリ内で画像の拡大縮小をするときはmipmap

<font color=blue>Android4.1以前の場合、アプリアイコンはdrawableとmipmapの両方を使う</font>。



#参考文献
[drawableとmipmapの違い](https://firespeed.org/diary.php?diary=kenz-1845)
[【Andorid】アプリアイコンは「mipmap-」というリソースディレクトリに入れるのがいいらしい](https://hack-it-iron.hatenablog.com/entry/2015/01/12/185039)
IAM権限のないユーザに、限定的なIAM権限を付与する


# 背景

AWSを使用するプロジェクトでは多くの場合、システム管理者等がAdministrator権限を持ち、
開発者や運用者はIAMなどの強い権限は持っていないと思います。

例えば開発フェーズやテストで何度も調整を行う際に、毎回管理者が対応するのも大変かと思います。
また、開発環境であれば限定的に権限を付与しても良い場合もあります。

# 例
「え？IAMの権限なんて使う…？」と思うかもしれませんが
例としては、ECSのAutoScaling設定調整が挙げられます。

ECSのFullAccess権限があったら変更くらいできるだろう、と思いますが
一般的にECSのAutoScalingでは、AutoScaling使用許可する専用のIAMロールを使用しています。

![スクリーンショット 2020-12-17 19.24.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406764/9aa9f32d-0c06-8bd5-0ba5-2c5d025a5962.png)

サービス更新画面でいうとこのあたり。

Scalingするためのポリシーとは具体的になんぞや？というと
・トリガーにしているCloudWatchアラームの読取/書込
・サービスの必要タスク数変更
などの権限が挙げられます。


つまり本題に戻ると、**ECSの必要タスク数を1から2に変更したい**、という場合
「ECSサービスの変更」権限=ECS権限 に加えて
「AutoScaling用Roleを変更する」権限=IAM権限 が必要になります。

開発者がIAM権限を持っていない場合、AccessDeniedとなり変更ができません。

以上のように、AWSユーザのみでなくAWSサービスに対してもIAM権限を与えているケースは多いです。
となると、ユーザが追加でIAM権限が必要になったりします。
だからといってAdministrator権限をむやみに増やせないですよね。

# 対処法
このような場合は、該当の**Roleを変更する権限**を、リソースを限定して**ユーザに与えれば**解決します。

今回の例だと、ECSのAutoScalingRoleというリソースのみ、Role変更権限を与えます。

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/aws-service-role/ecs.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ECSService"
        }
    ]
}
```

こちらがサンプルですが、"iam:PassRole"をリソース指定した上で与えます。
因みに今回指定しているRoleは、AWSのマネージドロールのARNです。

# まとめ

AWS IAMは、ユーザのみでなくAWSサービスにも権限を与えるものなので、
設計する際は頭の中で整理しないと混乱しますね。。
*権限を変更する権限？誰が使うんだっけ？サービス・・・？*

ただここを間違うと、必要のない権限まで与えてしまいリスクが大きくなるので、定期的に見直しましょう。

# おまけ

そういえば、2021/1/29でECSの管理マネージドポリシーの推奨が変更になります。
従来のポリシーにiam:passroleが入っていますが、リソースもコンディションも限定されていないですね。
https://docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/managed-policy-transition.html


◆これまでのポリシー（抜粋）　
**AmazonEC2ContainerServiceFullAccess**

```
                "iam:PassRole"
            ],
            "Resource": "*"
```

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_managed_policies.html#AmazonEC2ContainerServiceFullAccess

◆新しい推奨ポリシー　
**AmazonECS_FullAccess**
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_managed_policies.html#AmazonECS_FullAccess

今使っているポリシーが使えなくなるわけではないですが、これを機に権限周りを見直そうと思います。
push後にコードの変更を前のコミットに追加する方法

プログラミングを勉強していると、GitやGitHubを使う機会は非常に多いと思います。
GitやGitHubを使う上で**コミットの粒度を綺麗に保つこと**が大切。

しかし、それが結構難しく、pushした後に「この変更、さっきのコミットに追加したいな」なんて思うことが私は多々ありました。
今回はその時に私が使っている方法を記事にしました。

間違っている部分があれば申し訳ないです。m(_ _)m


# コマンド

今回使うコマンドは以下の通りです。

```bash
git diff
git commit  --amend
git push origin ブランチ名 --force
git diff HEAD^
```
一つひとつのコマンドについて詳しく説明します。

```bash
git diff
```

最新のコミット(HEAD)からの差分を見ることができます。

```bash
git commit  --amend
```

`git commit --amend`を行うと、直前の修正したいコミットと新しいコミットをひとつにまとめてリポジトリにコミットします。直前のコミットはなかったことになります。
ちなみに、amend は「改正する」「修正する」という意味です。

```bash
// git push を強制するオプション (２つは同義)
git push origin ブランチ名　--force
git push origin ブランチ名　-f
```
無理やりリモートリポジトリの履歴を上書きします。
このコマンドを使う場合は注意が必要です。（以下「git push --force を使う場合の注意点」参照）

```bash
git diff HEAD^
```
コミットの変更が追加できているか確認します。

本来、明示的に `git diff HEAD^..HEAD` と書くことで、「最新のコミット」と「最新のコミットのひとつ前」の差分を表示します。ただし`..HEAD`を省略しても、暗示的に現在のブランチの最新のコミット(HEAD)を示すことになるので、この書き方でも大丈夫です。

# git push --force を使う場合の注意点
強制 push は、自分ひとりで作業しているブランチではそれほど問題にはなりません。
一方、**チームで開発を行っており、共有されたブランチを強制的に更新するとき**は注意が必要です。

もし、強制 pushで削除されたコミットを起点にして、チームメンバーがローカル環境で開発を進めていた場合、チームメンバーの次の push でコンフリクトが発生してしまいます。
また、すでに存在しない状態をベースに開発を進めてしまうため、全ての前提が崩れてしまう可能性さえあります。

チームメンバーが多いほどこの問題は発生しやすいため、共有されたブランチでの強制 push は避けるべきです。

---
今回久しぶりに記事を書きました。記事を書いていると、普段何気なく使っていたコマンドの意味や新しい知識を得ることができ、アウトプットの重要性を改めて感じることができました。
これからはアウトプットの量も増やしていきたい。

参考記事

[git 差分を見る - Qiita](https://qiita.com/ikenji/items/42248085c4f4b55660d6)
[Git でコミットを取り消す・修正する方法 (git reset と git commit --amend)](https://www.yunabe.jp/docs/git_undo_commit.html#:~:text=%E7%9B%B4%E5%89%8D%E3%81%AE%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%82%92%E4%BF%AE%E6%AD%A3%E3%81%97%E3%81%A6%E3%82%84%E3%82%8A%E7%9B%B4%E3%81%99&text=amend%20%E3%81%AF%E6%94%B9%E6%AD%A3%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8B,%E3%81%9F%E3%81%93%E3%81%A8%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82)
[git push を強制する -f (–force)と –force-with-lease](https://www-creators.com/archives/5168)
[忘れやすい人のための git diff チートシート - Qiita](https://qiita.com/shibukk/items/8c9362a5bd399b9c56be)
Azure ポータルの Tips 3 選

Azure に触れる上で必ず使うことになる Azure ポータルですが 3 つほど Tips をご紹介します。

## Tips 1. たくさんあるディレクトリの切り替えを簡単にしたい

複数の Azure AD に所属している場合、各Azure AD ディレクトリに紐づく Azure サブスクリプションの状況を確認するには、ディレクトリの切り替えが必要です。

職業柄だとは思いますがこんな感じでディレクトリがスクロールバーが出てくるほどになってくると度々切り替えるのも面倒くさくなってきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/47d29b35-5801-428e-1445-5b69de865e98.png)

そこで、ディレクトリの切り替えを省いてダイレクトに対象のディレクトリの Azure ポータルにアクセスできる方法をご紹介します。
方法は簡単で、Azure ポータルの URL に onmicrosoft.com で終わるディレクトリ名を付けるだけです。

```
https://portal.azure.com/hogehoge.onmicrosoft.com
```

あとはこんな感じでお気に入りにいれておけば一発です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/8e653e4b-35d4-4047-5492-c651965a10af.png)

## Tips 2. サブスクリプションのリソース数や種類を大まかに確認したい

リソースの数が100、200くらいであれば何とかリソースの種類でグルーピングをしたりリソース グループ名から用途を推測したりできますが、その数が 1000 を超えてくると辛くなってきます。
ざっくりとそのサブスクリプションにどういうリソースが何個くらい、どのリージョンに展開されているか、ということを簡単に確認できる方法がありますので紹介します。

まず、**"すべてのリソース"** に移動します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/60b6f4a5-4bfc-35c5-0ff5-522128c7a84a.png)

次に、右端のプルダウンメニューから概要ビューを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/f4a56eaf-8bb6-ca06-e456-e782eee93265.png)

そうするとこんな画面になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/d8013396-adb1-7cfb-7e9e-7cd600916bcf.png)

あとは、リソース グループ単位や
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/444e7462-f559-5d45-98ca-dc27a9e38c30.png)

リソースの種類単位、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/0e0bea5b-5d99-f8d1-3a49-26dfbf225681.png)

サブスクリプション単位、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/a2079645-3617-83fc-c773-0dcec3688a01.png)

で確認ができます。
※サブスクリプションは Lighthouse で委任されているディレクトリのサブスクリプションも出てきます。

上部のフィルタリングと組み合わせるとさらに便利ですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/345ff5f9-272f-1122-a1d5-163c368f0f36.png)

## Tips 3. リソース グラフのクエリを簡単に作りたい

リソース グラフは Azure にあるリソースを Kusto クエリを使ってフィルタリングやソートし、効率よく検索できるとても便利なツールです。

ただ思った通りの結果を得るために Kusto をゼロから自分で書くのもちょっとハードル高いなぁという方に便利な機能があります。

既にリソース一覧の上部にメニューがあるのでお気づきかもしれませんが、**"クエリを開く"** メニューをクリックすると、リソース グラフ エクスプローラーが開き、リソース一覧の出力を得るための Kusto がそのまま書かれています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/ad73afe4-8661-1aea-8c0b-b1ae6cf8f122.png)
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/6d253624-9aab-6334-168a-db980c28d0c3.png)

あとはこのクエリを参考にカスタムすればゼロから組み立てていくよりも簡単にできます。
リソースのビューで予め列を追加してからクエリを開けば追加された列も反映されたクエリが構成されます。


ここからは余談です。
実はある時から、Azure ポータルのリソース一覧はリソース グラフで実現されています。
開発者ツールを開いてリクエストを見てみましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132347/de4bcfb8-8115-a214-1f61-fbe9e327e0ec.png)

`https://management.azure.com/batch?api-version=2015-11-01` のエンドポイントに対して、リソース グラフの API エンドポイントとセットでクエリが投げられていることが分かります。

この `query` をそのままリソース グラフエクスプローラーに貼り付けるとポータルの表示と同じ結果になります。
生成されるクエリを見ることで、こんな風にクエリを書けばこういう表示になるのかという気付きもあるのでポータルの裏側が楽しめると思います。


それでは楽しい Azure ポータルライフを！
２０２０年　Unityのおすすめアセットを紹介するよん

只今、Unityのアセットストアで　

セールが開催されていますね。　

では、これだけは買っておきたいというアセットを

紹介していきます。　

#１　Dynamic Bone
https://assetstore.unity.com/packages/tools/animation/dynamic-bone-16743


アニメーションや映像作品を作るならボーンは必須です。　

サンプルは３Ｄになっていますが、２Ｄでもちゃんと使えます。　

プログラミングなども必要ないので初心者に優しいアセットですね。　





#２　Final IK
https://assetstore.unity.com/packages/tools/animation/final-ik-14290



ダイナミックボーンの進化版ともいえるアセットです。　

ヒューマノイドモデルを自由自在に動かすことができます。　

Ｖチューバーをやる人にもおすすめです。　



#３　Modern UI Pack
https://assetstore.unity.com/packages/tools/gui/modern-ui-pack-150824

スタンダートなＵＩパックです。　

ＵｎｉｔｙのデフォルトＵＩだと少しダサいですから　

持っていて損はないでしょう。　



#４　Corgi Engine - 2D + 2.5D Platformer
https://assetstore.unity.com/packages/templates/systems/corgi-engine-2d-2-5d-platformer-26617

２Ｄゲームを作るなら、コーギーエンジンは必須でしょう。　

沢山の素材やプログラムなどが入っているので　

これ１つで、いろんなゲームが作れます。　



#５　City Builder: Urban

https://assetstore.unity.com/packages/3d/environments/urban/city-builder-urban-180722

これは最近出てきたアセットですね。　

本格的な都会アセットです。　

これがあれば、今流行のサイバーパンク風のゲームが　

出来ますね。　

#　６　Low Poly Animated Animals
https://assetstore.unity.com/packages/3d/characters/animals/low-poly-animated-animals-93089

こちらも最近出てきたばかりのアセットです。　

ローポリなのがいいですね。　



#　７　Universal Device Preview
https://assetstore.unity.com/packages/tools/utilities/universal-device-preview-82015

ゲームをリリースするなら、これは必須でしょう。　

いちいちビルドする手間が省けますからね。　



#８　Basic Motions PRO Pack

https://assetstore.unity.com/packages/3d/animations/basic-motions-pro-pack-157744

ヒューマノイドモデルで使えるアニメーションになります。　

Unityちゃんなどでも使えますし、持っておいて損はないでしょう。　

安いしね。



#９　UTAGE3 Unity Text Adventure Game Engine Version3
https://assetstore.unity.com/packages/tools/game-toolkits/utage3-unity-text-adventure-game-engine-version3-80727

ラノベゲームが作れるテンプレですね。



#　１０　Ariana Character P1
https://assetstore.unity.com/packages/3d/characters/humanoids/ariana-character-p1-118803


こちらも最近出てきたキャラクターアセットです。　

自由度の高いキャラクターを作ることができます。　



#１１　Ultimate Spaceships Creator
https://assetstore.unity.com/packages/3d/vehicles/space/ultimate-spaceships-creator-81341

シューティングやＳＦゲームなどで使えるアセットですね。　



#１２　Portal Effect

https://assetstore.unity.com/packages/tools/particles-effects/portal-effect-167041

ポータルはキャラのテレポートなどにも使えるし　

色々使えると思います。　そして安い。





#１３　UGUI MiniMap
https://assetstore.unity.com/packages/tools/gui/ugui-minimap-32874


簡単にミニマップを実装できるアセットです。　

ダンジョンゲームなどで使えますね。　



#１４　Sophie V2
https://assetstore.unity.com/packages/3d/characters/humanoids/sophie-v2-anime-style-character-for-games-and-vrchat-177182


可愛い女子キャラです。　ＶＲチャットでも使えます。　

私も購入しましたわ。　



#１５　Hyper-Casual - Characters 2
https://assetstore.unity.com/packages/3d/characters/hyper-casual-characters-2-170063


ヒューマンフォールフラットみたいな

キャラパックです。　



#１６　Customizable Pixel Character
https://assetstore.unity.com/packages/2d/characters/customizable-pixel-character-177945

２Ｄゲームで使える、ピクセルキャラです。

安いのに、沢山入っていていいですね。　






ＰＳ　

Unity３Ｄゲームstandard講座と　
２Ｄゲームstandard講座も　好評発売中です。　
ココナラやNOTEなどで購入できます。　

只今、技術書典10に向けて新しいUnity本も書いてまーす。　
お楽しみに。
ArchUnit 実践：自クラスからのみ呼び出されるメソッドの可視性をプライベートに強制する

```
// 実行環境
* AdoptOpenJDK 11.0.9.1+1
* JUnit 5.7.0
* ArchUnit 0.14.1
```

## アーキテクチャテストのモチベーション

16 日目の [ArchUnit 実践：同一パッケージからのみ呼び出されるメソッドの可視性をパッケージプライベートまたはプライベートに強制する](https://qiita.com/drafts/8a1d3772acdd5aae1612) の応用。

## アーキテクチャテストの実装

```java
package com.example;
　
import com.tngtech.archunit.base.DescribedPredicate;
import com.tngtech.archunit.core.domain.JavaAccess;
import com.tngtech.archunit.core.domain.JavaClasses;
import com.tngtech.archunit.core.domain.JavaMethod;
import com.tngtech.archunit.core.domain.JavaModifier;
import com.tngtech.archunit.core.importer.ClassFileImporter;
import com.tngtech.archunit.core.importer.ImportOption;
import org.junit.jupiter.api.Test;

import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.methods;

class ArchitectureTest {

    // 検査対象のクラス
    private static final JavaClasses CLASSES =
            new ClassFileImporter()
                    .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)
                    .importPackages("com.example");

    @Test
    void 自クラスからのみ呼び出されるメソッドはプライベートにする() {
        methods()
            .that(new DescribedPredicate<>("are public or are package private") {
                @Override
                public boolean apply(final JavaMethod method) {
                    return ! method.getModifiers().contains(JavaModifier.PRIVATE)
                        && ! method.getModifiers().contains(JavaModifier.PROTECTED);
                }
            })
            .and(new DescribedPredicate<>("that are only called in declared class") {
                @Override
                public boolean apply(final JavaMethod method) {
                    return method.getAccessesToSelf()
                        .stream()
                        .map(JavaAccess::getOriginOwner)
                        .allMatch(callerClass
                            -> callerClass.getFullName().equals(method.getOwner().getFullName()));
                }
            })
            .should()
            .bePrivate()
            .check(CLASSES);
    }
}
```
rails s でサーバーが起動出来ない不具合について

#解決したい問題
ローカルサーバーを起動したいが下記の表記が出てしまう。

```
A server is already running. Check /Users/ユーザー名/projects/chat-app/tmp/pids/server.pid.
```

##環境
Ruby 2.6.5
Rails 6.0
macOS Catalina

##問題点の洗い出し
コントローラーの記述が間違っておりSyntax errorが起きた
↓
記述を変更後リロードを行ったが読み込みが非常に遅かったため中断後、再度リロード
↓
ブラウザ画面に大量の文字が出現しターミナルの操作が効かなくなったためターミナルを強制終了
↓
再度ターミナル起動後、rails sを使用するも起動せず上記の様な出力がなされサーバーが起動しない

#解決策
サーバーを起動すると

```
A server is already running. Check /Users/ユーザー名/projects/chat-app/tmp/pids/server.pid.
```
ターミナルに出力された場所にサーバーのファイルが一時的に作成される様で
ここにファイルが残ったままだったため新しいサーバーを起動出来なかった。

ターミナルでファイルに記述されている数字を指定して削除するコマンド実行する事でファイルを削除

```
% kill -9 残っていたファイルに記述されていた番号
```
rails sで無事サーバーが起動

#反省点
いきなり予期しない動作が出ても強制終了はできるだけしない様にする
今回はエラー以外の謎の文字羅列にビビり強制終了に至った。
TeXShop の pdfLaTex で日本語のフォントが通らない問題 (Mac)

Mac の TeXShop (pdfLaTex) で、下記のような感じのフォントのエラーが出た場合の対処方法です。

```! Latex error: Font family `JT1+gt' unknown```

下記ページで奥村先生が解答されていて、それが全てではあるのですが、ここまでたどりつくのに結構時間がかかったので、忘備録的に書いておきます。

- [情報処理学会のjsample.texがpdflatexでコンパイルできません](https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=1557)

# 結論

TeXShop の環境設定の「内容変更」のタブを押す。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266247/0b58df7d-57eb-c931-e722-e468d145ca86.png)

デフォルトではこうなっているはず。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266247/72c26fc7-1b7a-715a-4793-5b3db60d66ff.png)

左下にある「設定プロファイル」から pTeX(ptex2pdf) を選ぶ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266247/980761cc-264e-e173-39cc-dafc5677bc77.png)

こうなったら、右下の「OK」を押す。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266247/5f9daa75-00fb-8884-b5c2-47415a719d13.png)

上のメニューの「タイプセット」の下の欄が pdfTeX になっているのを TeX + DVI にする。

これでエラーが出ないようになりました。

この方法で直らない場合、class ファイルの指定時にオプションに uplatex を入れると直ることもあるそうです(下記参照)。ただし、私の環境では、この方法では解決しませんでした。

- [! LaTeX Error: Font family `JT1+gt’ unknown. への対処](https://www.albow.net/entry/tex-iasty-err)
Git clean branch

#### Local branch の整理

##### ローカル branch 一覧表示
```bash
$ git branch
```

##### master branch にマージ済みのブランチ表示
```bash
$ git checkout master
$ git branch --merged
```

##### master branch にマージ済みのローカルブランチの削除
```bash
$ git branch -d {masterにマージ済みのブランチ}
```

##### master branch にマージ済みでないブランチ表示
```bash
$ git checkout master
$ git branch --no-merged
```

##### リモート branch 一覧表示
```bash
$ git branch -r
```

##### リモート branch 状態確認
```bash
stale と表示されたブランチは誰かがリモートで削除済みだが、自分のローカルと同期されていない
$ git remote show origin
```

##### リモートで削除されているリモートブランチを削除
```bash
--dry-run で削除対象のブランチを予めチェックできる
$ git remote prune origin --dry-run
```
```bash
$ git remote prune origin
```

##### リモートブランチの最新状態を取得
```bash
-p でリモートブランチの削除を同期
$ git fetch -p
```

#### Remote branch の整理
率先してリモートブランチを整理する担当者がいない限り、リモートリポジトリには古いブランチが溜まってしまいがちです。
前述した git remote prune origin の後、リモートブランチのリストを同期する必要があります。

##### リモート master に既に merge されたブランチを表示
```bash
$ git checkout master
$ git branch -r --merged
```

##### リモート master に merge 済みの各ブランチの最終コミット日や作成者を表示
ブランチを削除すると元に戻せないため、慎重に行う必要があります。
上のコマンドでは、あまり詳細な情報が表示されないため、最終コミット日や作成者を確認した上で削除するために、以下のようなコマンドを試すことが出来ます。

```bash
$ git checkout master
$ for branch in `git branch -r --merged | grep -v HEAD`; do echo -e `git show --format="%ci %cr %an" $branch | head -n 1` \\t$branch; done | sort -r
```

##### リモート ブランチの削除
```bash
$ git push origin --delete branch-name
or
$ git push origin :branch-name
```

##### リモート master に merge されていない各ブランチの最終コミット日や作成者を表示
master に merge する必要の無いブランチも残っているかもしれません。
それについても、最終コミット日や作成者を確認するため、以下のようなコマンドを試すことが出来ます。

```bash
$ git checkout master
$ for branch in `git branch -r --no-merged | grep -v HEAD`; do echo -e `git show --format="%ci %cr %an" $branch | head -n 1` \\t$branch; done | sort -r
```
【Ruby】ifとelseの問題〜演算子を添えて〜

<h3>問題：あなたは警官です。<br>aとb二人の容疑者の取り調べをしています。<br>
どちらも証言がTrue、またはFalseであればその証言はTrueです。<br>
しかしどちらかがFalseでTrueであればその証言はFalse、と出力するメソッドを論理演算子を用いて作りましょう。</h3>
<br>


**呼び出し方：**
police_trouble(a, b)
<br>
**出力例：**

```
police_trouble(true, false) → False
police_trouble(false, false) → True
police_trouble(true, true) → True
```
<br>
**論理演算子**
2つ以上の条件式を組み合わせた複雑な条件式を記述するために論理演算子&&、||、!を使います。
以下のように使用します。


```
# aもbもtrueの場合にtrue 
a && b

# aかbのどちらかがtrueの場合にtrue
a || b 

# aがtrueの場合にfalse、aがfalseの場合にtrue
!a
```
<br>
<br>
<br>
<br>
<br>
**解答**

```
def police_trouble(a, b)
  if (a && b) || (!a && !b)
    puts "True"
  else
    puts "False"
  end
end

police_trouble(true, false) 
police_trouble(false, false) 
police_trouble(true, true) 

```


if文で論理演算子&&と||と!a用いて条件式を記述。
「**(a && b) || (!a && !b)**」は、
①aとbがどちらもtrue
② 　　　〃  　false
このどちらの場合でも「**True**」と出力される。
これ以外であれば(噛み合っていなければ)Falseと出力。
Thymeleafでチェックボックスを使うときの注意点

Thymeleafでチェックボックスを使ったときに少しハマったポイントをまとめてみました！

一般的には`th:field`にプロパティを指定して出力させることが多いと思います。
`th:object`でBeanを指定していれば自動でバインドされるので、単純に出力するだけであれば一番手っ取り早くて簡単にチェック状態を保持することもできます。

# th:fieldを使う場合

`th:object`で指定しているBeanの中で定義されているプロパティを指定し、チェックボックスとして出力することができます。

一番大きなポイントとしてはチェックボックスを出力するのと同時に、パラメータ名の先頭にアンダースコアが付いた形でhiddenを出力することです。
hiddenで出力されているパラメータがチェックボックスを選択していない状態でも送信されることで、Spring側がfalseとしてハンドリングするようになっています。
(ちなみにJSPでSpringのタグライブラリを使用した際も同様なので、Spring Frameworkの仕様が影響しているような気がします)

実際に型別で2パターンほど出力してみるとこんな感じになります。

■booleanのプロパティを使って出力する場合

```html
<input type="checkbox" th:field="*{checkBoo}">
```

※実際に出力されるHTML

```html
<input type="checkbox" id="checkBoo1" name="checkBoo" value="true">
<input type="hidden" name="_checkBoo" value="on">
```

■Stringのプロパティを使って出力する場合

```html
<input type="checkbox" th:field="*{checkStr}" th:value="on" >
```

※実際に出力されるHTML

```html
<input type="checkbox" value="on" id="checkStr1" name="checkStr">
<input type="hidden" name="_checkStr" value="on">
```

新規で開発を行う場合はこのような一般のお作法通りに記述することで問題なく動作できるかと思います。
しかし、別のフレームワークからマイグレーションする際などは元の仕様が異なることもあり、hiddenが出力されてfalseとして扱われると困ることがありそうです。

# 自動でhiddenが出力されないようにするには？

結論としては`th:field`の使用を避けるのが一番です。
単純にname属性を使うようにしてもチェックボックスとしての役割は果たすことができます。

ただ、hiddenが出力されなくなったかわりに`th:field`が自動で行っていたチェック状態を判定ができなくなってしまいます。
(`th:object`に指定したBeanのプロパティをバインドしなくなるため)
多少冗長にはなりますが、別の方法で判定してチェック状態を保持することは可能です。

■booleanのプロパティを使って出力する場合

```html
<form th:action="@{/check}" th:object="${form}" method="POST">
	<input type="checkbox" name="checkBoo" th:checked="${form.checkBoo}">
</form>
```

※実際に出力されるHTML

```html
<form action="/context-path/check" method="POST">
	<input type="checkbox" name="checkBoo" checked="checked">
</form>
```

■Stringのプロパティを使って出力する場合

```html
<form th:action="@{/check}" th:object="${form}" method="POST">
	<input type="checkbox" name="checkStr" th:value="on" th:checked="${form.checkStr eq 'on'}">
</form>
```

※実際に出力されるHTML

```html
<form action="/context-path/check" method="POST">
	<input type="checkbox" name="checkStr" value="on" checked="checked">
</form>
```

上記の例だと、型がbooleanの場合はtrueではないとき・Stringの場合はvalue属性に指定した値ではないときは、当然checked属性が出力されないように判定してくれます。
必要に応じてこういった書き方も使っていくのが良いと思います。

# まとめ

書き方によってはチェックボックスを選択してない状態でも値がPOSTされることになるので、内部の実装によっては影響があります。
自分自身が遭遇したパターンとしては、hiddenで送られたパラメータがStringの型変換(Converter)カスタマイズ実装に影響を及ぼしていたことがありました。

Webアプリケーションを作っていく上では一部の話ですが、知っておくと得する内容だと思います。
Thymeleafの豆知識として参考になれば幸いです。

# 参考

http://se-bikou.blogspot.com/2018/05/spring-mvcthymeleafcheckbox.html

https://docs.spring.io/spring-framework/docs/2.0.x/reference/mvc.html#mvc-formtaglib-checkboxtag
numbaでpythonコードを正しく高速化するためのTips

この記事は[MicroAd (マイクロアド) Advent Calendar 2020](https://qiita.com/advent-calendar/2020/microad)の18日目の記事です。

# はじめに

numbaとはpythonコードを高速化するためのライブラリです。

高速化したい関数に以下のようにアノテーションをつけるだけでネイティブのマシンコードのような速度で実行できるようになります。

```python
import numba

@numba.jit
def f(x, y):
    return x + y
```

numbaを使うとお手軽にコードを高速化できる反面、通常のpythonコードとは違いコンパイルが発生するので
仕組みを理解せずに使っていると返って処理全体の実行速度が遅くなってしまうこともあります。

この記事では意外なnumbaの落とし穴とそれを回避するための方法をご紹介しようと思います。




# no pythonモードを利用する
numbaには最適化が行われる__no python__と通常と同じコンパイル方式の__object__の２種類のモードが存在します。

この二つのモードはデフォルト設定では自動で切り替わるようになっており、
no pythonモードが優先されますが、これが失敗した場合は自動でobjectモードに切り替わります。

オブジェクトモードでは最適化が行われない上、
コンパイルのオーバーヘッドでかえって実行時間がかかる場合があります。

なのでnumbaを活用するには最適化に対応していない処理を把握しておき、
そういった処理を含まないよう関数を切り出すなどの工夫が重要です。

```
no pythonモード非対応の処理
・dict
・set
・pandas
・yield from
・set・dict・ジェネレーターの内包表記
```

また、numbaではno pythonモードでのコンパイルができない場合にエラーをですように設定できるので、
基本的には以下の書き方で利用するのをお勧めします。

```python
@jit(nopython=True)
def f(x, y):
```

or

```python
@njit
def f(x, y):
```





# コンパイルのオーバーヘッドを回避する

numbaでは実装に応じて関数をコンパイルするタイミングが自動で切り替わるようになっています。

それを把握せずに利用すると処理速度が求められる場面でコンパイルが走ってしまい、
高速化のために利用したnumbaが返ってボトルネックになってしまうかもしれません。

意識的にコンパイルタイミングを操作するため、そのバリエーションと書き方を把握しておきましょう。

### 関数が初めて呼ばれたタイミングでコンパイル
こちらがデフォルトの動作です。

```python
@njit
def f(x, y):
  return x + y 
```

### 関数が読み込まれたタイミングでコンパイル
型指定をすることで、関数が定義されたタイミングでコンパイルされるようになります。
型指定には高速化の効果もあるので、この書き方が一番のおすすめです。

```python
@njit(int32(int32, int32))
def f(x, y):
    return x + y
```

### cacheを利用する
またcacheを利用するよう設定することで、初回起動以外はコンパイルを必要なくできます。
この方法は他の型指定とも併用できるので、とりあえずでオプションをつけておいても損はないです。

```python
@njit(cache=True)
def f(x, y):
  return x + y
```

### 事前コンパイル
コンパイル済みモジュールの自動作成することでコンパイルを実行時に起きなくすることもできます。
正直この方法はちょっと面倒くさいですしコードも冗長になります。
どんなタイミングでもコンパイルによるオーバーヘッドを起こしたくない時の最終手段ですね。

```python
from numba.pycc import CC

cc = CC('my_module')

@cc.export('multi', 'i4(i4, i4)')
def f(a, b):
    return a + b

if __name__ == "__main__":
    cc.compile()
>>> from my_module import f
>>> f(3, 4)
```

# まとめ
いかがだったでしょうか。
今回は簡単に高速化を実現できますが、ちょっと動作に癖があるnumbaの注意点をまとめてみました。
この記事が読んでいただいた皆さんの参考になれば幸いです。
先輩からGitのお作法を学んだ

##自分がプライベートリポジトリを作成し、先輩を招待
メアドで招待

##先輩が参加し、必要な物を用意してくださった
・最低限のコード
・githubの運用ルール(readme.mdに記載)

##自分がコードをクローン
ローカルでディレクトリを作成し、そこにクローンする

```
git clone http://xxxxxx.com/xxxxxx.git
```

pushする時と同じ感じになれば成功してるはず。

##クローンした所から進めていく。
今回todoAppを作っていく上でいろいろと不必要なものが入ってるが、消していいのだろうか？
、、、
とりあえずブランチについて学ぶ
>https://qiita.com/gakisan8273/items/0e0ad1fee2a7c623f8d6

それを読んだうえでreadmeを読むと、恐らくmasterとdevelopを主に使いdevelopの中に昨日それぞれのブランチを作っていくのだと思う。

それぞれのブランチで機能を作ったらdevelopでマージしてmasterにコミットするのだと思う、、、

本当はここで先輩に確認しときたいのだが、訳あって今は出来ないので進めていく。

今回のToDoの機能は
・完了機能--done
・追加機能--add
・削除機能--del
の基本的な3つである。

これらのブランチを作った

##とりあえず開発サーバを立ち上げてみる
しかし立ち上がらない。

```yarn start```を実行すると

```
'react-scripts' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。
```
と返ってきた。

```npx create-react-app```を実行してみてもだめだった。

返ってきたのが

```
yarn run v1.19.1
$ react-scripts start
internal/modules/cjs/loader.js:883
  throw err;
  ^

Error: Cannot find module 'react'
Require stack:
- C:\
-～～～～～～～～～～～～～～～～～～
-～～～～～～～～～～～～～～～～～～
-～～～～～～～～～～～～～～～～～～
-～～～～～～～～～～～～～～～～～～
-～～～～～～～～～～～～～～～～～～
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'C:\\Users\\～～～～～～\\react-scripts\\scripts\\start.js'
  ]
}
error Command failed with exit code 1.
```

完全にお手上げなのでもう一度最初からクローンし直す。

クローンしてからすぐに```yarn start```で起動させると

```
'react-scripts' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。
```
と返ってきた。

こyarnの公式ドキュメントに行って```yarn run```をやってみたが、こちらも出来なかった。

それについても調べると

```yarn install```
を実行してからもう一度```yarn start```を実行したら無事に起動させることが出来た。

根本的なミス、、、

今後気をつけたい。

もう一度ブランチを作り直す。

##一度srcをすべて削除
すべて削除してdevelopにコミット

その後は、それぞれの機能をそれぞれのブランチにコミットしていく。

後、masterにマージするの防ぐために保護しながら進めてほしいと言われたので、そっちにも手を付けていく。
調べてみたところプライベートリポジトリではブランチの保護では出来ないらしい。

##マージ

そしてマージする前にマージリクエストもするように言われた。
調べていたら全体の流れをわかりやすいサイトをみつけた
[プルリクエストを使った開発プロセス](https://backlog.com/ja/git-tutorial/pull-request/03/)

developにマージしたいのでdevelopにチェックアウトして```feat/~~~```をマージしていく

##プルリク

しかし今回はmasterではなくdevelopにマージしたいのでdevelopにプルリクする必要がある。

まず普通にプルリクをする。この時はmasterになっている可能性があるので注意。
それから先輩にリクエストを出したら、プルリクの設定で右側のeditでdevelopに変更することが出来た。

##コンフリクト発生

しかしconfirictが発生した。

```
This branch has conflicts that must be resolved

Conflicting files
.eslintcache
src/App.js
```
また登場```.eslintcache```
調べていたらこのツイートを見つけた
https://twitter.com/oukayuka/status/1338818640473309184?s=20

英語なのでよくわからなかったが、git ignoreを使ってgitに上がらないようにする。

```git rm --cached .eslintcache```を実行
[参考サイト](https://fantastech.net/gitignore)を参考にすべてのブランチで実行し、ローカル・リモートリポジト両方で反映させる。

なぜかcheckoutが出来なかったがブランチ名の前に```-f```をつけたら出来た。


後はApp.jsである。

こいつはvscodeで新しい方を維持させたらすぐに解決した。

##完了

で、初めてマージさせることが出来た。
Public API Perfomanceデータについて知る

New Relicでソリューションを提供している佐々木です。
New Relic Advent Calendar 2019の11日目記事をお届けします(ちょっと時間差です！)。

## Public API Performanceダッシュボードについて

最近New Relicにサインアップされた方は、何やらデフォルトでこのようなダッシュボードがあることにお気づきかと思います。
<img width="400" alt="Public API Performanceダッシュボード1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538642/7a284a20-7010-001a-200e-6f91eee34739.png">

これは、複数のクラウド事業者からNew Relicが定期的に収集したデータを使って表示しているダッシュボードになります。ダッシュボードを開くと、各APIの応答速度を俯瞰できるチャートが表示されます。また、左側のバーチャートから気になるAPIを選ぶと、そのAPIの情報だけフィルタすることができます(添付画像ではGoogle APIだけ選んでみました)。

![publicapi2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538642/ded1427d-85f3-fe87-5c1e-80c2ebf92738.png)

けっこう前からNew Relicをお使いの方は、デフォルトでこのダッシュボードは作られていません。作ってみたいという方は、簡単な操作であとから追加することができます。
右上のドロップダウンメニューから```Add more data```を選び、一番上の```Public API Performance```を押していただくだけです。

![publicapi3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538642/9514bfec-8df8-a9f3-3bdd-db8f828d7dfe.png)


## なぜこのようなダッシュボードがあるのか

このダッシュボードには2つの目的があります。

1. 外部APIの稼働状況の参考値を知る
収集対象となっているものは広く利用されているメジャーなAPIです。実際これらのAPIを使っていたり、それらの応答時間ってどれくらいなんだろう・・・と知りたいシーンもあるかもしれません。その参考値として使っていただくことができます。

2. New Relicのデータ分析機能について学べる
New Relicにサインアップした直後のタイミングは、まだエージェントなどの設定をしていないため、自分のシステムから送られたデータを見ることはできません。その時点で、New Relicがどのようなデータ分析をできるか手軽に知りたいな、という場合に、参考データとして利用することができます。

ここでは、2について、もう少し深堀りをしていきたいと思います。

## ダッシュボードの元となっているデータ: "Public_APICall" Event

右上にある```Query your data```メニューをクリックしてみてください。これはNew Relicに収集されているデータを分析できるツールです。このデータをEventデータと言い、現在収集されているEventデータは左側に表示されている```Event type```で種類分けされています。その中に```Public_APICall```という名前のEventデータがありますので、これを選択してみましょう。すると右側にラインチャートが表示されますが、その右上にある```Raw Data```というボタンをクリックすると、収集されているデータを表形式で見ることができます。
すると、```API```というカラムに外部APIの名前が格納されているなど、なんとなくこれがダッシュボードの元になっているデータなんだなーということがわかると思います。

![publicapi4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538642/ddd4aea4-bfbf-dcfb-1707-456054f3903b.png)

New Relicが収集しているEventデータの特徴は、属性名と値のペアを複数持つJSON形式であることです。このデータを加工してダッシュボード上でさまざまな表現をすることができます。

Public API Performanceダッシュボードに戻ってみましょう。右上の```・・・```を押して、```View query```を選びます。

<img width=500" alt="Public API Performanceダッシュボード2" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538642/c29d55b5-a786-baf5-bc92-31ddacb01108.png">

すると、このようなクエリが表示されます。

```
FROM Public_APICall SELECT percentile(duration, 99) as 'response time' FACET api LIMIT 100
```

このクエリはNRQL(New Relic Query Language、発音はえぬあーるきゅーえる、なーこー、ぬるくる、など人それぞれ)と呼ばれる、New RelicのEventデータを分析するための専用の言語です。```FROM Public_APICall```とあるように、先ほど見たPublic_APICallのデータを分析していることがわかります。ご自身で独自のNRQLを書いて分析をし、その結果をダッシュボードに表示することもできますのでチャレンジしてみてください。


## 最後に

Public API Perfomanceデータについて理解が深まったでしょうか。このデータはNew Relicがすべてのお客様に自由に使っていただけるよう提供しているものなので、ぜひ活用してみてください！
100円ショップでお手軽に椅子を改善する

###はじめに

100円ショップで購入可能な商品（ダイソーのバックレスト）で職場の椅子を改善します。
こんなやつ
![71KHD9C8+dL._AC_SY450_.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/57089/95ea3309-24fb-77ba-14bb-fae66965087c.jpeg)



###なぜ？

職業柄、長時間座ったまま仕事をすることが多いですが、
キーボードやマウスはともかく個人の椅子を仕事場に持ち込むのは難しいです。
椅子が体に合わないとどうしても腰に負担がかかり、
肩こり、目の疲れと体全体へ連鎖していってしまいます。
そこであまりお金をかけずに椅子を改善したいと思います。

###詳しく

100円のバックレストを今の椅子につけるだけで、
・腰が正しいカーブになる
・椅子の背面が蒸れない
・100円なのでちょっと昼休みに買ってくる等ができる
と良い事ずくめです。

###おしまい
他にも、どうにも疲れて頭がまわらない時に100円ショップをぶらつくと、
想像もしなかった商品がたくさん見つかるので息抜きに良いです。
商品名がわからずに検索したらかなり評判がよくて、わざわざ書かなくても他に沢山紹介記事がありました・・・・・・
はじめてのAWSその3 Wordpressを構築する

AWSでサーバ構築するための覚書です。その2で作ったEC2サーバにWordpressをインストールします。


#Wordpressのインストール
こちらを参考にさせていただきながら
https://qiita.com/moomindani/items/9968df0d4396564bf74c

##Teratermで接続
まずはTeratermでEC2に接続して作業します。

##Apacheのインストール
ApacheはWebサーバでhttpのdaemon(サービス)なので「httpd」はApacheのことです。
####インストールと設定
httpdをインストール
```sudo yum install httpd -y
```
インストールの経過が画面上にどんどん出てきますが、最後に```Complete!```が表示されればインストール成功

httpdを自動起動に設定
```sudo systemctl enable httpd.service
```

ec2-userをapacheグループに追加
```sudo usermod -a -G apache ec2-user
```
httpdを起動
```sudo systemctl start httpd
```

####ここで忘れていたセキュリティグループの設定
EC2の管理画面でセキュリティグループlaunch-wizard-1を開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/940466/1bc500c6-5e4c-7449-6f92-670c9545e79b.png)

下部にあるインバウンドルールの編集をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/940466/2db947ee-ab35-2bf7-7d3e-c5a51bc87bf9.png)

インバウンドルール2を追加する

* タイプ:HTTP
* ソース:0.0.0.0/0
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/940466/6d2b06f7-3735-73c4-0cca-34a7485df4bc.png)

####接続テスト
ブラウザから接続してみてApacheのテストページが表示できたら成功。このときのURLはAWSコンソールでEC2の情報を表示したときに「パブリック IPv4 DNS」と書かれているものです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/940466/e6d8e678-1697-2083-aaf2-bdd6d25ac1de.png)

##MariaDB,PHP,WordPressのインストール
この先はこちらの記事を見ながら作っていきました
https://qiita.com/moomindani/items/9968df0d4396564bf74c

##WordPressによるモダンなWebサイトの完成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/940466/79d74308-f060-399f-2330-c96cbc045050.png)
PM(プロジェクトマネジメント)一年生の苦悩

## はじめに

この記事はZeals Advent Calendar 2020の17日目の記事です。

現在ZealsでPMをやっている中村です。
一昨年の11月にZEALSにJoinし、エンジニア歴が二年となりました！
実務では主にRails・React書いていました！
そんな私ですが、現在はPMとして働いております！
本日はそんなPM一年生の僕が直面した**苦悩**について紹介できればと思います！
その前にPMをやることになった背景や実際の業務内容について軽く触れようと思います！

## 背景
エンジニアとしての業務に慣れてきた今年の9月くらいに『PMとして働いてみない?』と誘われたのがきっかけです！
PMとして働くなら暫くコーディングから離れる事になりそうと思い迷ったのですが、

- 『僕ならできる』といってくれた人たちの期待に応えたい
- 以前からPMの業務に興味があった

といった理由から引き受ける事にしました！

## PMの業務内容と概要(私の場合)
次にPMの業務について紹介します。
会社によってPMとしての働き方って多様だと思っていますが、私の場合は以下のような業務内容です！

```
1. 要件定義
   開発したい機能の要件を関係者を集めて纏める
   要件定義書の作成
2. リリーススケジュールの計画の作成
   いつまでにリリースしなくてはならないかデッドラインを明確にした上でのロードマップ作成
3. アサインするメンバーの決定
   アサインするエンジニアの決定
4. 開発進捗管理
   開発が順調か否かの確認
5. QAエンジニアと機能の確認
   QAの方がテストしやすいようにサポート
   バグが起きている場合適宜エンジニアのアサイン
6. リリース
   機能が本番環境でも動作するかチェック
```

大まかに書きましたが、ざっくりこんな感じですね！
ZEALSでのPM業務って分解してみると結構量がありますね。。。
普段このような業務を進める上で、本題となるPM一年生である僕の苦悩について記載していきます！

# PM一年生苦悩

### 圧倒的PMスキル不足
僕が思うPMをやるにおいて大事なスキルは

- コミュニケーション力(聞く力・伝える力)
- ファシリテーション力
- ドキュメント作成力
- メンバーの意見をまとめる力
- 決断力
- 巻き込み力

などなど大きくこの辺りが挙げられると思っています！

エンジニアの仕事ではドキュメントの作成を業務としてやってましたが、

その他のスキルについては、これまであまり意識してこなかったです！

いざプロジェクトが始まり、プロジェクトに関するミーティングを行っても、

- うまく会議が進まない

- メンバーの意見をうまく纏めることができない

といった状態になっていました！

結果として、**ファシリテーションスキル**や**メンバーの意見をまとめる力**など実務で自分に足りていない能力があらわになりました。

皆の貴重な時間を頂いているにも関わらず上手く会議を進める事ができなくて、申し訳なさと自分の不甲斐なさで気持ちが一杯になったのを覚えています。


### PMって何？状態
PMの業務内容に記載しましたが、日々色んな業務をしております！

そういった中で、**結局PMって何すれば良いの？**という状態に陥りました。。。

エンジニアとして働いていた時は、要件やデザインがあり、その要件を満たす機能を作るといった明確なゴールが設定されていました。

なので、実装の仕方について考える事はありましたが、何をすれば良いのか？と道に迷う事はあまりなかったです！

PMとして、実際にプロジェクトを立ちげた時に

- まず最初に何をすれば良いんだ？
- 僕に求められてる仕事って何なのだろう？

といった、立ち振る舞い方や、仕事の仕方についてもかなり苦戦していました！

他にも**PMとしてどこまで実装に関わるべきか**等々

たくさん苦悩はあるのですが、挙げるとキリがないので２つくらいにしておきます！

## 現状と今後

苦悩を踏まえて現状はどうなっているのかも少し話します！

現状は周りの皆さんの支えもあり、毎日ヒーヒーいながらPM業を楽しめています！

ただ、**スキル**に関しては、まだまだ全然足りていない物もあると思っています(銀の弾丸はどの職種にもない事を痛感。。。)が

**PMって何？**状態からは抜け出せた気はしています。

PMとして3ヵ月ほど仕事をしてきて自分の役割や立ち位置を徐々に認識できるようにはなってきました！

しかし、自分の役割を認識しているだけでは、勿論全然足りないと思っています！

今後は、「あの時あいつにPM任せて良かったね」 と言ってもらえるように**己の成長**とプ**ロジェクトの結果**で会社に恩返しできればと思っています！


##　終わりに
ここまで読んで頂きありがとうございました！

新しい職種に挑戦する時って、わからない事ばかりで大変だなと改めて実感しました！

そういえばエンジニアになりたての時も、必死に食らいついていたな。。。と二年前を懐かしく感じながら終わろうと思います！
Azure portalのダッシュボードをカスタマイズしてみた

# 1. はじめに
本記事は、Microsoft社が提供しているAzureラーニングパスを使って学習した内容をまとめたものです。
今回は、主に「コア クラウド サービス - Azure portal を使用してサービスを管理する」について触れています。

# 2. Azure portalとダッシュボードについて
Azureを使用する場合、まず初めにAzure portalにアクセスし、
操作していくことが一般的な使い方だと思います。
ダッシュボードはAzure portalに表示される
タイル状のUIをした利用者ごとにカスタマイズが可能な画面を指します。
<img width="500" alt="2020121701.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534316/597499c2-4361-9782-e07c-4b460e38fbd5.png">

# 3. 「ダッシュボードのカスタマイズ」の実践
演習項目の「ダッシュボードをカスタマイズする」について実践してみました。
演習項目は上から順に
・タイルの追加と構成
・タイルのサイズを変更する
・ダッシュボードを複製する
・ダッシュボードを共有する
・ダッシュボード.json ファイルを編集する
・ダッシュボードを削除する
・ダッシュボードをリセットする
の７つあり、「ダッシュボード.json ファイルを編集する」まで実践すると
下図のようになりました。
<img width="500" alt="jsonファイルを編集した後のダッシュボード.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534316/966c0642-9b2c-6287-ef8f-3ff52a29dff7.png">

# 4. 実践内容にないこともしてみた
ダッシュボードのレイアウトはjsonファイルで管理できるということなので、
実践内容にはない、編集方法もテキストエディタ上で試してみました。

まずは、それぞれのタイルがどのようなjsonオブジェクトになっているか確認してみるために、
時計タイルを２つ横にならべてみました。
<img width="500" alt="2020121702.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534316/17b9747b-38f5-8088-4f40-b4e668c15c42.png">

それぞれの時計タイルのjson構造は↓

```
"parts": {
          "0": {
            "position": {
              "x": 0,
              "y": 0,
              "colSpan": 2,
              "rowSpan": 2
            },
            "metadata": {
              "inputs": [],
              "type": "Extension/HubsExtension/PartType/ClockPart",
              "settings": {}
            }
          },
          "1": {
            "position": {
              "x": 2,
              "y": 0,
              "colSpan": 2,
              "rowSpan": 2
            },
            "metadata": {
              "inputs": [],
              "type": "Extension/HubsExtension/PartType/ClockPart",
              "settings": {}
            }
          }
}
```

どうやらpartsオブジェクト配下にそれぞれのタイルのjsonオブジェクトが格納されているようです。
それぞれのオブジェクトの違いは先頭の数字とpositionの内部だけなので、そこを変えれば容易に複製できそうです。

実際にjsonファイルの編集だけで時計タイルを３つに増やしてみました。
<img width="500" alt="2020121703.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534316/40049837-0434-9d04-f686-cf271c03da45.png">

jsonについて少し知っていれば、UIに頼らずにテキストエディタ上の編集のみで
ダッシュボードにタイルを増やすことができました。

一気に1000個のタイルを配置したい場合などはjson編集のほうが楽ですね。
（1000個も配置する場面が訪れるかどうかという疑問からは目をそらしつつ）

# 5. まとめ
Azureを触るのは今回のラーニングパスでの実践が初めてだったため、
実践を通してどのようなものか少しは分かったような気がしました。

今回はAzure portalのダッシュボードという割と初歩的なところを取り上げましたが、
機会があればAzureを利用したクラウドサービスの運用などについても学習し、取り上げていきたいです。
【Salesforce】LastModifiedDateをWHERE句に指定したSOQLが低パフォーマンスとなる原因について

#はじめに
特定の期間にユーザが更新したレコードの抽出を目的として、次のようなSOQLを作成し実行したところ
想定しているよりもクエリのレスポンスが悪い、時にはタイムアウトとなった経験はありませんか。

```sql
SELECT Id, Name FROM targetObject 
WHERE fromDate < LastModifiedDate AND LastModifiedDate < toDate;
```

私も上記のようなLastModifiedDateを指定したSOQLのパフォーマンスで躓きました。
本記事ではLastModifiedDateをWHERE句に指定した場合に低パフォーマンスとなる原因について調査し、
その調査結果について備忘録的にまとめております。

#低パフォーマンスの原因
原因はWHERE句でのLastModifiedDate指定において
インデックスが無効となるパターンが存在するためでした。

下記条件パターンのうち①と②はインデックスが有効となりますが、③はインデックスが無効となります。

①LastModifiedDate > DateField
②LastModifiedDate = DateField
③LastModifiedDate < DateField

#LastModifiedDate < DateField でインデックスが無効となる理由
これはLastModifiedDateはインデックスを保持しておらず、
SOQLのクエリオプティマイザが内部的にLastModifiedDateをSystemModStampへと置き換えて
SystemModStampのインデックスを使用しているためです。

LastModifiedDateとSystemModStampはいずれも更新時間を保持する項目となりますが、
リファレンスを参照しますと更新契機が次のように異なることがわかります。
>LastModifiedDate：ユーザがこのレコードを最後に変更した日時。
>SystemModStamp：ユーザまたは自動化されたプロセス (トリガなど) によって最後に更新された日時。

端的に言えばSystemModStampの方が更新タイミングが多いため
項目間での更新時間については次の関係が成立します。
` LastModifiedDate <= SystemModStamp` 

上記よりWHERE句指定パターン③ LastModifiedDate < DateField においては
` LastModifiedDate < DateField < SystemModStamp`  の関係が成立する可能性があり
SystemModStampで条件を判定した場合にレコードの抽出漏れが発生します。
このため③のWHERE句指定ではLastModifiedDateをSystemModStampへと置き換えることができずインデックスが有効となりません。

冒頭に提示したSOQLもパターン③が当てはまるため、インデックスが無効になっていたようです。

#対応策について
SystemModStampが常にLastModifiedDateと同一の値を保持しており、
` LastModifiedDate < DateField < SystemModStamp` とならないことが自明であれば、
SystemModStampをWHERE句の条件に指定するのが最も簡単な対応策となります。

ですが、大抵の場合はトリガ等でSystemModStampが更新されているでしょうし、
SystemModStampで代用できるか調査するぐらいであれば、この対応策は止めておいたほうがよいでしょう。


現実的な対応策としては、カスタムインデックスを付与した日付型カスタム項目を用意するものがあります。
ワークフロールール等でカスタム項目にLastModifiedDateの値コピーを行って同期をとっておけば、
WHERE句指定にカスタム項目を使用できますので、どのWHERE句指定パターンでもインデックスが有効となります。

#参考ページ
[Salesforce および Lightning プラットフォームのオブジェクトリファレンス システム項目](https://developer.salesforce.com/docs/atlas.ja-jp.object_reference.meta/object_reference/system_fields.htm)
[SOQL 実行時の LastModifiedDate と SystemModStamp のインデックス利用について](https://help.salesforce.com/articleView?id=000318519&type=1&mode=1)
[Force.com SOQL Performance Tips: LastModifiedDate vs SystemModStamp](https://developer.salesforce.com/blogs/engineering/2014/11/force-com-soql-performance-tips-systemmodstamp-vs-lastmodifieddate-2.html)
昼食にかかる時間よりも短い時間で、Webサイトを作成する（Azureラーニングパス）

# はじめに
弊社の啓発活動で[Azureラーニングパス][link-1]を使用して簡単なWebサイトの作成方法を学びましたので、基礎的な部分を忘れないように演習内容を備忘録として残します。
※昼食にかかる時間には個人差があります。

# Webサイトを作成する
WordPressを利用したWebサイトを作ります。

## リソースを作成する
サンドボックスが有効になった状態で、[Azure Portal](https://portal.azure.com/#home)にアクセスします。

画面左上のポータルメニューから「リソースの作成」を選択すると、Azure Marketplaceの画面が表示されます。
WordPressを使用するには、検索ボックスに「WordPress」と入力し、検索結果から無印のWordPressを選択します。
WordPressの概要ページが表示されるため、画面上部の「作成」を選択します。

![WordPress50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/414958/fb01a4c2-4f63-0049-0e01-8317a800a82a.png)

##デプロイを構成するオプション 
WordPressの作成画面が表示されるので、それぞれ入力・選択していきます。
<dl>
<dt>アプリ名</dt>
<dd>任意の名前</dd>
<dt>サブスクリプション</dt>
<dd>[Concierge Subscription]を選択</dd>
<dt>リソース グループ</dt>
<dd>既に1つ選択できると思うので、下記の例のような項目を選択
例：[learn-296d3d1a-972b-467c-9695-23220435932b]
※ラーニングパスのサンドボックス環境以外の場合は、リソースグループを事前に作成する必要があります。
</dd>
<dt>データベース プロバイダー</dt>
<dd>[MySQL In App]を選択</dd>
<dt>App Service プラン/場所</dt>
<dd>本記事のApp Serviceプランの項で後述します。</dd>
<dt>Application Insights</dt>
<dd>変更なし</dd>
</dl>

![WordPress250.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/414958/9307a6a2-1ae7-46f3-fd8f-333070a1d33c.png)
##App Serviceプラン
App Service プラン/場所 をクリックします。
App Service プランが表示されるので、新規作成をクリックします。
すると、新しい App Service プラン という画面が表示されるので、それぞれ入力・選択していきます。
<dl>
<dt>App Serviceプラン</dt>
<dd>任意の名前</dd>
<dt>場所</dt>
<dd>利用したいリージョン(場所)
今回は[Central US]を選びます。</dd>
<dt>価格レベル</dt>
<dd>利用したい機能・パフォーマンスに応じたレベル
今回は無料の[F1]を選択します。</dd>
</dl>

![WordPress350.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/414958/f211c3a5-77a6-e056-2d90-a69af0b732d7.png)


無料の[F1]を選択するには、スペックの選択画面で[開発・テスト]タブを選択した後に表示される一番左の[F1]を選んでから適用ボタンをクリックします。
新しい App Service プラン画面に戻ると価格レベルが[F1]になっていることが確認できますので、OKボタンをクリックします。
WordPress アプリ作成画面に戻るので、作成ボタンをクリックします。
これにより、新規サイトのデプロイが開始されます。

# アクセスしてみる
デプロイの完了を待ってから、サイトにアクセスしてみます。デプロイにかかる時間は体感5分くらいでしょうか。
演習用の環境とはいえ、一時的ではありますがインターネットに公開される形でデプロイされています。試しに、演習をしたPCとは別のPCからアクセスして見ると、問題なくアクセスできることが確認できると思います。
アクセスにはデプロイしたリソースに移動してから画像の場所でリンクを踏みます。
![4-website-url-expanded.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/414958/e7908794-362a-8fc2-7dff-43676620ad3a.png)
WordPressの画面が表示されれば成功です。
![4-configure-wordpress.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/414958/b8e201a7-4b88-cbe5-3403-aabc2db8cab2.png)

# まとめ
啓発活動では、この演習の他にも多くの演習や読み物を読んできました。その中で、いつもMicrosoftが**早さ**を謳っていましたが、それが実感できる内容の演習であったと思います。本来ならば、リソースグループを作成してからのリソースの作成なのですが、演習用のサンドボックスだと事前に用意されているものを利用します。なので、実際の手順と違うところなどもありますが、大きな流れは一緒です。

個人的な感想を言わせてもらうと、Dockerのイメージを落としてくるような感覚でした。使うだけみたいな。Azure Marketplaceで選択するオプションをJenkinsとかにすれば、なかなか実用的なのではないでしょうか。


[link-1]:https://docs.microsoft.com/ja-jp/learn/