OmniAICreator/Qiita-1.07M huggingface dataset:
Sphinx＋Drone＋S3で快適ドキュメントライフ

ドキュメントの維持管理はどんな組織においても永遠の課題と思います。
今回は[サーバープラットフォームチーム](https://jobs.qiita.com/employers/e-seikatsu/development_teams/24)で取り入れている永続化したい社内向けドキュメントの維持管理の仕組みをご紹介します。

## Sphinx とは

[Sphinx](https://www.sphinx-doc.org/ja/master/) は Python ベースのドキュメント生成ツールです。
マークアップ言語である reStructuredText をソースとして、 HTML で構成されたドキュメントをビルドできます。
プラグインを入れれば Markdown や AsciiDoc をソースにすることもできますし、 PlantUML を埋め込んだりすることもできます。

## Sphinx ドキュメントのホスティング

Sphinx で作ったドキュメントを公開したいのであれば [readthedocs.org](https://readthedocs.org/) を使うのが簡単です。
Github や Gitlab を利用しているなら github.io や Gitlab Pages を使うのも良いでしょう。
当社では AWS を活用しており、 Sphinx で生成されたファイルを S3 に置いて適当なドメインにホスティング、公開範囲を適当なポリシーで制限する、というようなことをやっています。

## Drone とは

[Drone](https://drone.io/) は Go ベースの CI ツールです。
Git リポジトリへのイベントを契機に、 Docker コンテナ内でジョブを実行するというシンプルなツールです。
当社では開発用に社内に Drone サーバを構築して運用しています。

## 概要

以下のようなフローで Gitlab への push を契機に、 Drone で Sphinx ドキュメントをビルドし、 S3 へアップロードします。

![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/119312/d35564ad-7e27-95f6-b0f1-4877fea5177e.png)

これによって

* ドキュメントを書く人はマークアップ言語で記述できる
* ドキュメントを読みたい人は HTML で構造化された形式で読める
* ドキュメントが更新されたタイミングは Slack 通知で検知可能
* Git 管理されてるので diff や log も当然見れる

を実現しています。

## やること

### AWS

1. アップロード用の S3 バケットを用意
1. S3 バケットの AWS アクセスキーと AWS アクセスシークレットを取得
1. S3 バケットを適当なドメインにホスティング

### Drone

1. Gitlab との連携を ON にする
1. S3 の AWS アクセスキーと AWS アクセスシークレットを登録する

### Gitlab

1. Drone url と Token を設定する
1. Sphinx ドキュメント用のレポジトリで `.drone.yml` を以下の様に書く（ S3 アップロード用の docker イメージには [atlassian/pipelines-awscli](https://hub.docker.com/r/atlassian/pipelines-awscli) を利用）

    ```yaml
    pipeline:
      build:
        image: python:3
        commands:
          - pip install Sphinx
          - make html
        when:
          event: push
          branch: master

    push-contents:
        image: atlassian/pipelines-awscli
        secrets:
          - AWS_ACCESS_KEY_ID
          - AWS_SECRET_ACCESS_KEY
        commands:
          - aws s3 sync --delete _build/html/ s3://<作成した S3 バケット名>/
        when:
          event: push
          branch: master
    ```

1. 以上で master に push されたタイミングで Sphinx ドキュメントが出来上がるようになります

## さいごに

ドキュメント作成はしばしば気が重くなる作業ですが、避けては通れないものでもあります。
しかし綺麗なドキュメントが楽に書ける仕組みがあると、不思議と筆は進んでいくものです。
皆さんもサーバーサイドアプリケーションエンジニアとして、当社で快適なドキュメントライフを送りませんか？
https://jobs.qiita.com/postings/238
BEAR.SundayのCQRSを時限公開のコンテンツに使う

# はじめに
BEAR.Sundayには破壊的メソッド(onPut/onPost/onDelete)を実行した際にキャッシュを更新または破棄する[機能](http://bearsunday.github.io/manuals/1.0/ja/resource.html#cacheable)があります。キャッシュの参照とキャッシュの生成が分離できます。

注）CQRSは本来ソフトウェアパターンの名前ですが、本記事では便宜的にキャッシュ生成およびキャッシュ破棄に関するBEAR.Sundayの一機能の名前として言及しています。

# 時限公開コンテンツ
`@Cacheable`アノテーションが指定されたResourceは標準で有効期限が存在しないキャッシュが生成されます。
これは未来永劫公開され続けるものには有効ですが、指定時間に公開したい、もしくは指定時間に公開を終了したいようなコンテンツに対しては不利な面があります。
そのResourceに対して更新処理が行われない限りキャッシュが破棄されず、記事が公開されない・記事の公開が終了しないといった問題が発生します。

# CacheableアノテーションのexpiryAt
`@Cacheabe`アノテーションは`$expiryAt`という引数を受け入れます。この引数を指定すると、無期限もしくは決められた時間（TTL）の指定ではなく、キャッシュの有効期限を日時指定で柔軟にカスタマイズできます。

これを利用して、予約公開のコンテンツには公開開始日時を指定するように、公開終了日時が決まっているコンテンツには公開終了日時が指定されるようになれば一応意図する動作になりそうですね。

## var/db/sql/getArticleById.sql
記事を取得するSQLです。
今回キャッシュ操作に扱う公開開始日(`release_date`)は一応専用のキーで取得しておきます。

```sql
SELECT
  *,
  release_date AS __release_date
FROM
  article
WEHERE
  id = :id
```

## src/Resource/App/Article.php
`@Cacheable`アノテーションに`expiryAt`が指定された場合、`$this->body`内に指定されたそのキーで何かしらの有効日時を示す値が必ず存在している必要があります。

ですので、有効期限も公開日時も指定されていない、もしくは記事が存在しないなどといった、本来であれば無期限でキャッシュできそうな場合でも日時を指定する必要があります。今回はそのような場合とりあえず`2999-12-31`にしてしまいます。

```php
<?php
namespace Vendor\Project\Resource\App;

/**
 * @Cacheable(expiryAt="__expiry_at")
 */
class Article extends ResourceObject
{
    use ResourceInject;

    private const EXPIRY_NEVER = '2999-12-31';

    /**
     * @var callable
     */
    private $getArticle;

    /**
     * @var NowInterface
     */
    private $now;

    /**
     * @param RowInterface $getArticle
     * @param NowInterface $now
     * @Named("getArticle=getArticle")
     */
    public function __construct(RowInterface $getArticle, NowInterface $now)
    {
        $this->getArticle = $getArticle;
        $this->now = $now;
    }

    /**
     * @param int $id
     *
     * @return ResourceObject
     */
    public function onGet(int $id) : ResourceObject
    {
        $article = ($this->getArticle)([
            'id' => $id,
            'now' => (string) $this->now
        ]);

        // 記事自体が見つからない
        if (empty($article)) {
            $this->code = Code::NOT_FOUND;
            $this->body = ['__expiry_at' => self::EXPIRY_NEVER];

            return $this;
        }

        $this->body = $article;
        $this->body['__expiry_at'] = empty($article['expiration_date']) ? self::EXPIRY_NEVER : $article['expiration_date'];
        // 公開開始前の記事
        if (strtotime($article['__release_date']) > strtotime($this->now)) {
            $this->body['__expiry_at'] = $article['release_date'];
            $this->code = Code::NOT_FOUND;
        }

        return $this;
    }
}

```

まず有効期限設定の有無に関わらず、キャッシュの有効期限を設定します。次にもしその記事が公開開始前のものであれば、その公開開始日時でキャッシュの有効期限を上書きします。

これで

* 公開開始日前の記事であれば公開開始日にキャッシュが破棄される
* すでに公開されている記事であれば公開終了日にキャッシュが破棄される
* 公開終了日が存在しない記事は2999年にキャッシュが破棄される（自分はもう死んでいるのでそんな先のことは知らない）

という挙動が実現できるはずです。

# 最後に
お気づきになられた方も多いと思いますが、こちらの実装では厳密なCQRSになっていません。（キャッシュの有効期限が切れたあとのユーザアクセスでキャッシュが生成されてしまう）
キャッシュが存在しないものが公開されて困るほど高負荷のサービスでは他に対策が必要になると思います。
php7.4から波括弧を使用した配列や文字列のオフセットへのアクセスは非推奨になる

php7.4から波括弧を使って配列や文字列のオフセットにアクセスする文法は推奨されなくなります。

> ``$var{$idx}`` でなはく ``$var[$idx]`` を使って下さい。

```php
$a = [100, 2, 3, 4, 5, 'a' => 'hoge'];
var_dump($a{'a'});
```

```
// 出力
string(4) "hoge"
```
こういう書き方は注意ですね。

というか波括弧でも配列のオフセット指定が動くって知らなかった。。。


[波括弧を使った、配列や文字列のオフセットへのアクセス](https://www.php.net/manual/ja/migration74.deprecated.php#migration74.deprecated.core.array-string-access-curly-brace)
AWS HTTP API(β版)でオーソライザー(Cognito)を作成する

##はじめに

REST APIで作成できるオーソライザー(Cognito)を、HTTP API(β版)で作成します。
Cognitoでユーザープールを作成済みであることが前提です。


##API GatewayでHTTP API(β版)を作成する

特別な設定はせずにHTTP API(β版)を作成します。この章は読み飛ばしOKです。

1. Amazon API Gateway のトップページに移動します。
2. [APIを作成]ボタンを押します。
![001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/4be654e8-75de-9d45-28d6-e816a39c6b5e.png)
3. HTTP API Beta の[構築]ボタンを押します。
![002.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/fdf90a24-dfdd-b47b-a8ef-d8ab9177aa7f.png)
4. _Step1_ APIの作成  
[API名]に適当な名前を入力して、[次へ]ボタンを押します。
![003.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/287a96e8-f1fb-ad79-1493-08839157f267.png)
5. _Step2_ ルートを設定  
設定は変更せず、[次へ]ボタンを押します。
6. _Step3_ ステージを定義  
設定は変更せず、[次へ]ボタンを押します。  
※初期値の$defaultは、自動でデプロイしてくれる、優秀な設定です。
7. _Step4_ 確認して作成  
[作成]ボタンを押します。
![004.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/6bcfd6d5-5b99-ccfb-d1c2-cf3a287fdc5b.png)


##オーソライザー(Cognito)を作成する

ここからが本題です。

1. 作成したHTTP APIのトップページに移動します。
![005.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/01336947-6962-c4ad-25de-1c05a65a88a5.png)

###認可
![006.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/7be30746-208a-b874-5d2f-ed4255503887.png)

1. 左ペインの[開発>認可]を選択します。
2. [オーソライザーを管理]タブを開きます。
3. [作成]ボタンを押します。

###JWTオーソライザーの作成
![007.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546599/e3d82f83-cc92-3bcc-369f-71ae66819005.png)

1. [名前]に適当な名前を入力します。
2. [IDソース]を設定します。※画像の例は「$request.header.Authorization」
3. __[発行者 URL]を入力します。次のような形式です。  
https://cognito-idp.{リージョン}.amazonaws.com/{プールID}  
{リージョン}: リージョン名です。東京リージョンなら「ap-northeast-1」です。  
{プールID}: Cognitoで作成したユーザープールのプールIDです。ユーザープールの「全般設定」から確認できます。__
4. [対象者]の[Add audience]ボタンを押して、{アプリクライアントID}を入力します。  
{アプリクライアントID}は、ユーザープールの「全般設定>アプリクライアント」から確認できます。  
※アプリクライアントが未作成の場合は作成してください。
5. [作成]ボタンを押します。

これで、オーソライザーが作成できました。


##作成したオーソライザーを確認する


作成したオーソライザーの確認も載せようと思いましたが、長くなりましたのでまたの機会に。

獲得したIDトークンをfetchでリクエストすると良い感じに結果が得られます。

```javascript
const jwt = '{IDトークン}';
const url = 'https://{API-ID}.execute-api.ap-northeast-1.amazonaws.com/';
const params = {
  method: 'get',
  headers: { 'Authorization': jwt },
};
await fetch(url, params);
```
えっ...私のSlack 地味すぎ...？～テーマ変更で自分色のSlackに～

アドベントカレンダー前半にまだ隙間があるのであと1記事書いてみようと思います。
こんにちは、ペットの晴男と毎日楽しく暮らしています。Osanuです。
↓これは寝起きで肉球揉ませてくれる晴男。一揉みで3日分のストレスが消える。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/ef10bdd8-32b9-f25a-cce7-89998d16d9b7.png)

##閑話
まず惚気話を聞いてほしいんですけど、最近叱るときには
「こら～ハル～？:innocent:なーんで机に上っちゃったのかな～？:innocent:
前も登ったらあかんて言ったよね～？:innocent:ねえハル？？？きいてる？？？ハル？？？:innocent:」
と私がされたらばちくそイラつきそうな怒り方をしているんですが理由があるんです！

ハルは怒られているときとそうでないときを私の声のトーンで判別しているようで
叱られてるときはめっちゃ黒目大きくして　きゅるん:worried::sparkles:　ていう顔をするんです
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/70b52dd2-3a48-f7c4-ee16-c26722d82085.png)←こんなかんじの顔。はいかわいい。
https://image.itmedia.co.jp/l/im/nl/articles/1701/18/l_km170118_hikakuneko02.jpg

しかも自分の名前もわかっているので上記の　ねえハル？　の部分で返事するんです
こら～ハル～？（ニャッ:crying_cat_face:）なーんで机に上っちゃったのかな～？（ニャッ:crying_cat_face:）

って感じなんですよ:hugging:　はいかわいいですね:see_no_evil:
何回も問いかけたくなりますよね！！！！
んで私気になったので調べたんですよ、怒られているときに鳴く意味を。

したらこちらのサイトさんに書いてありました。
[猫を叱ると短く鳴くのはどういう意味？猫の気持ちを教えます。](https://mofmo.jp/article/5313)
>猫を叱るときに、猫は短くて低い声で「ニャッ」と鳴くことがあります。

>これは相手に対する不満な気持ちの表れなんです。
>ですから、猫を叱るときに発する短く鳴く声は「なんかうっとうしいな」という気持ちがこもっていると考えられます。

**「なんかうっとうしいな」**


##ほんへ
閑話休題と行きましょう。
みなさんSlackの色味変更出来ること、ご存知でしょうか！
私のslackはこんなかんじです！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/7f093dd7-563d-7334-6f35-e515e9758290.png)

テーマを変えるとお気に入りの色でSlackが使えて気分があがりますね！:v_tone1:

###どこで変えるのか
サイドバー上部、ワークスペース名押下からPreferencesを開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/40575dbd-863a-23ef-0d1c-d3b500ae921a.png)上から3番目！

開いてThemesを押下すると、ライトモードとダークモードだけでなく
サイドバーのテーマも決めることができます！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/166b65ac-3319-e431-820e-4dcb602dd270.png)

Slackが提案するテンプレートもありますが、ここは自由に決めることが出来ます。
もっと下にスクロールするとカスタムテーマがあると思います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/cf1e3bf8-9ee8-e849-367f-7d0c4f1e48d0.png)
ここで当該項目にカラーコードを入力することで好きな色に変えることが出来ます！

###でもセンスがない！
色彩センスってどうやって身につくんでしょうねえ:frowning2:
センスないから！って思ってる人、結構沢山いますよね。
でもそんなあなたでも大丈夫、テンプレ沢山あります(V)o￥o(V)

オススメサイト①[Slack Themes](https://slackthemes.net/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/612016d0-318f-2a32-cce4-d1d2ef8a62d7.png)

テンプレートが沢山あって、かつ実際に適用したときのサイドバーのイメージを
見ながら決めることができます！

オススメサイト②[Pokémon Slack theme generator](http://pokeslack.xyz/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/60252445-3e28-3ba6-81fe-62137c883b42.png)

ポケモンに使用されている色合いでテーマカラーを作成してくれます！
好きなポケモンを検索することが出来ますし、詳しくない人はランダムで選ぶこともできます！
*このサイトは鳴き声が出るので音量注意です:flushed:

###テンプレートを適用するには
上記の両サイトとも、カラーコードの羅列がコピーできるようになっていると思います。
それをコピーしてCustom Themeの
[Copy and paste these values to share your custom theme with others]欄に貼り付けてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215581/7a83df8a-2f51-313f-45c0-1f5eccac2dc7.png)
貼り付けるだけで適用されます！

とても簡単なので自分好みのSlack画面にカスタマイズしてみてください(*'▽')
閑話の方が長かったけど()以上です:relaxed:
読んでくださってありがとうございました！:pray_tone1::sparkles:
【備忘録】wgetでつながらないのにcurlではつながる

# 事象
localにtomcatを立ち上げてwgetでアクセスしたらつながらない。
試しにcurlでアクセスしたらつながる。
同じアクセス先なのになぜだろう。

# 原因
wgetにはプロキシ経由でアクセスする設定があるらしく、それが有効になっていた。

```
[ファイル]
/etc/wgetrc

[該当設定]
http_proxy=http://proxy.xxx.xxx:pp/
https_proxy=http://proxy.xxx.xxx:pp/

```

# 感想
今まで好みでwgetを使用していたが、調べてみるとcurlとwgetで差分がけっこうある。
そこら辺については他にまとめている方がいるので割愛。
Android で annotation が見つからない件 - シンボル annotation を解決できません。

# はじめに
最近、Google Speech-to-Text を使った音声アプリを Android で作る機会がありました。
Google さんの公式ドキュメントから [Android のサンプルリンク](https://github.com/GoogleCloudPlatform/android-docs-samples/tree/master/speech/Speech)があり、
そのまま「えいっ！」ってコピペしてみると、「シンボル annotation を解決できません。」と怒られました。

多分、上記サンプルに関わらず、コピペしてコマッタ…って人もいるかとおもいます。
パッと検索してみても annotation をキーワードに指定するとなかなか出てこなかったので記事にしてみました。

# 問題のコード

``` java
import android.support.annotation.NonNull;
```

# 先に結論
下記のように書き換えると、とりあえず動きました。

``` java
import androidx.annotation.NonNull;
```

細かい所まで見れてないですが、気になる人は [annotation のリリースノート](https://developer.android.com/jetpack/androidx/releases/annotation?hl=ja) 等、参照ください。

とりあえず今作ってるアプリが動いたらいいや…（おいっ！）

# 結論に至った経緯
## Annotation は appcompat に含まれる

annotation って何者？って調べると、appcompat に含まれているみたいです。
下記、参考の URL を見ても appcompat を implementation していれば行ける模様。

【参考】
https://qiita.com/que9/items/34469b1164ec59f0ebbe
https://developer.android.com/studio/write/annotations?hl=ja

でも、appcompat implementation してるよ？

``` app/build.gradle
    implementation 'androidx.appcompat:appcompat:1.1.0'
```

試しに annotation 直接指定してみるか。

``` app/build.gradle
    implementation 'com.android.support:support-annotations:28.0.0'
```

やっぱダメ。
（直接 jar を配置したらビルド通ったのですが、なんか違う！と思ったのでここには書きません。）

## Android は AndridX になっていた

なんか appcompat の仕様でも変わったのかな？と思って調べてみると、やっぱ変わってた。
私は下記２つを参考にしました。

https://qiita.com/toastkidjp/items/4b851046c19af6e55995)
https://developer.android.com/jetpack/androidx/migrate?hl=ja


ということで、あるべき androidx の annotation を import すると直りましたとさ。
めでたしめでたし。
ドメインにもこだわりたい

## ドメインにもこだわりたい
ブラウザからアクセスするときに意識することは少ないですが、
名刺、広告や、メディアに掲載されるときなどはURLを記載されることが多いので、
ロゴと同じくらいこだわりたいものです。

「.com」が取得できるのが理想ですが、
今日では希望の文字列はほとんど取得され尽くしていて、
またプレミアムなドメインと称して高値でプールされていたりして、
よほどオリジナリティのある文字列でない限り取得は不可能に近いでしょう。

次点で「.jp」ですが、これも希望の文字列は取得しにくくなってきている感じがあります。
個人的には字面があまり好きではないので、
よほど気に入った文字列を閃いたときくらいしか取得しません。

## 素敵な事例
「センスあるなぁ」と感心した事例をいくつか。

### YouTube
https://youtu.be/xxxxxx/
YouTubeとしては https://www.youtube.com/ ですが
動画共有用の短縮URLはyoutu.beになります。


### ロケタッチ
http://tou.ch
サービス自体は終了してしまっていますが位置情報アプリ「ロケタッチ」。
touch!

### about me
https://about.me/
自分のプロフィールを公開するサービス。
その名も「About Me」。
名は体を表すというやつです。
素晴らしい。

「.me」は使い勝手良さそうです。
「Follow Me」とか「Call Me」とか（この例は既に取得されているでしょうが）。


### Abema TV
https://abema.tv/
「.tv」を「テレビ」として使っています。
実際はオセアニアにある「ツバル」という国に割り当てられているドメインです。


### カメリオ（kamelio）
https://www.newsexplorer.kamel.io/
サービス名とドメインが完全に一致。



## 使えそうなドメイン
先述のような使い方ができるドメインがいくつもあります。
### .ac
- 「mani.ac（マニアック）」

### .ai
- ダッサいですが、出会い系サイトを作るとして「iide.ai（良い出会い）」
- 「shinozaki.ai（篠崎愛）」とか「あい」という名前の人

### .am
- 「abrah.am（アブラハム）」

### .art
- そのままArtの意味で「modern.art」
- 「loinhe.art（ライオンハート）」とか「marioc.art（マリオカート）」とか

### .be
- 「kasu.be（かすべ）」。エイです。

### .co
- 「フクリコ」という福利厚生サービスを作ったら「fukuri.co」というドメインにしようと思ったことがありましたが、fukurico.comで同じことを既にやっている企業がありました。
- 「mari.co（マリコ）」とか、実際は「mariko」でしょうが、少しひねった活動名で使えそうです。


### .coffee
これからコーヒー屋やカフェをやる場合に使えますね。
ちなみに「.cafe」もあります。
- bluebottle.coffee
- ueshima.coffee

### .de
ドイツのドメインです。


### .in
- 「keror.in（ケロリン）」とか。黄色い風呂桶で有名ですね。


### .inc
2019年に新たに誕生した「法人企業・組織」を表す新gTLD
- 「garage.inc」とか「starfuckers.inc」とか。

### .ink
- 「〜d.rink(〜ドリンク)」
- 「〜l.ink（〜リンク）」

ちなみに.linkというドメインもあります。


### .io
本来は「Input/Output」の意味です。
実例が前述されているので割愛。


### .la

### .me
実例を先述してるので割愛。

### .nu
手ぬぐいの「かまわぬ」さんなんかは「 kamawa.nu 」とかできるんですけど

### .rest
- fo.restとか。

### .us
「.me」と同じような使い方ができそうです。
「join.us」のように「動詞 + us」の形や
「mysterio.us（ミステリアス）」のような形容詞の形。

### .uno
- 「shiobanahar.uno（しおばなはるの）」。汐華初流乃。ジョルノ・ジョバーナの日本名ですね。

### .tv
実例を既述しているので割愛




## 余談
### 世にも珍しい2文字
余談だが、最近は3文字以上の文字列でないとドメインを取得することができない（申請すらできない）。
そんな中、アメリカのアパレルブランド「アメリカンイーグル」のドメインは
https://www.ae.com/
2文字！！しかも「.com」！!
これは羨ましい。


## 一度取得されたら終わり
- すぐに使わなくても、事前に取得しておくべき


## SNSもチェックする
サービス名が決まり、ドメインも取得できたからと喜ぶのはまだ早い。
その文字列がSNSでも取得をできるかはチェックした方が良い。

- twitter.com/xxxxxx/
- instagram.com/xxxxxx/

上記の「xxxxxx」の部分文字列。
苦肉の策で「_official」を足したりするけど、あまりかっこよくない。
文字列としても冗長だし。


## 増え続けるドメイン
最近では「.coffee」「.cafe」などの、業種に特化した文字列なども増えています。
たまにレジストラのページ見に行くと楽しいかも。


## どこでドメインを購入？
#### ムームードメイン
https://muumuu-domain.com/domain/price
おすすめ。
ロリポップやhetemlといったレンタルサーバーとの連携が楽。
Wordpressでサイト立ち上げるくらいのライトなユーザーなら共有サーバーで十分だと思う。

#### ゴンベエドメイン
https://www.gonbei.jp/reg/domain_price.cgi?p1=domain_price
「.de」など、本来、日本では取得できないようなドメインも取得することができる。
若手エンジニアが学んだ工数見積もり方法

[ディップ Advent Calendar 2019](https://qiita.com/advent-calendar/2019/dip-dev)の20日目です。

## はじめに
こんにちは、ディップ株式会社に2018年新卒で入社し、求人系サービスの開発や社内向けツールの開発を行なっている@taku-0728です。
今回は私が先輩から教わった工数見積もり方法について書きたいと思います。
知っている人からすれば当たり前だろと思われるかもしれませんが、同じように工数見積もりについて悩んでいる方の参考になればと思います。
よろしくお願いいたします。

## 背景
まずはじめに言っておきますが私は「**工数見積もりが大の苦手**」です。基本的に考えるより先に行動したいタイプなので、「いつくらいにできそう？」と聞かれても「やってみないとわかんないじゃん」と思うタイプの人間です。（もちろん答えるときは◯日くらいですとちゃんと答えますが。）
そのため、自分でスケジュールを引く際には内容を軽く把握して **ある程度感覚でスケジュールを引いていました。**

## 問題点
「感覚でスケジュールを引く」ことは知識と実務経験が豊富なベテランエンジニアであれば問題ないと思います。しかし、経験も知識も未知数な若手エンジニアにとっては相当難しいと思います。最初に引いたスケジュールから思うようにいかなかったにも関わらずギリギリまでなんとかしようとして報告が遅くなり、結果的に先輩や上司を困らせた経験がある方はいるのではないでしょうか？(私はその一人です。)
「**先輩や上司への報告がギリギリのためスケジュールの遅延を早い段階で検知できず、適切な対応を取れない**」ことが一番の問題点であると思います。

### なぜ思うように進まないのか
最初に自分で「これくらいかかるだろう」と考えたのになぜ思った通りに進まないのでしょうか？
原因はいくつかあると思いますが「そもそも見積もる粒度が大きすぎる」というのが1つ考えられると思います。
たとえばあるタスクについて設計からテストまでの工数を出して欲しいと言われた際、

- 設計：◯人日
- コーディング：◯人日
- テスト：◯人日

のように各工程ごとでしか見積もりを行わないことはあると思います。
このような見積もりだと

- 担当したタスクが想定より難しかった
- 緊急度の高いタスクによって必要な工数が確保できなかった

など、よくある問題がそのままスケジュールの遅延に繋がりがちです。
その遅延をすぐ報告せずギリギリまでなんとかしようとして上司・先輩にアラートをあげるタイミングが遅くなってしまうのではないでしょうか。
例えばコーディングに3人日かかると見積もります。はじめの1日で予想以上に詰まり初日で全体の20%しか進んでなかった場合、すでに10%程度遅れているにも関わらず「あと2日あるからなんとかなるか」と考えてしまいがちです。（夏休みの宿題でありがちなやつですね）ただ、そうなると遅延を取り返そうと残りの2日間でものすごく残業したり、最悪の場合ギリギリになって「やっぱり無理でした」と報告することになってしまいます。

## 解決策
どうすればスケジュールの遅延を早い段階で検知し、適切な対応が取れるのでしょうか？
当たり前ではありますが、「タスクをより細分化して工数を見積もる」ことを教わりました。
### 細分化って？
とはいえ細分化と言われても何を持って分割すればいいのかわからないと思います。
自分が教わった定義は「**1つのタスクが3時間以下になるまで細分化**」することです。
例えばコーディングに3人日かかるさっきの例で考えます。

- コーディング：24時間(8時間×3人日)
  - タスクA：10時間
     - タスクA-1：3時間
     - タスクA-2：2時間
     - タスクA-3：2時間
     - タスクA-4：3時間
  - タスクB：8時間
     - タスクB-1：3時間
     - タスクB-2：3時間
     - タスクB-3：2時間
  - タスクC：6時間
     - タスクC-1：3時間
     - タスクC-2：3時間

コーディングという1つの大タスクが3つの中タスク、9つの小タスクにそれぞれ細分化されました。
これによってもしタスクA-1に詰まって5時間かかってしまった場合、タスクA自体が2時間遅れていること、それによってタスクB、タスクCの開始時間も遅れる可能性があることに気づけます。自分の見積もりより遅れそうだなと思ったタイミングで先輩や上司に報告、相談することで周りも遅延を早い段階で把握でき、適切な対応を取れるのではないかと思います。

## 結果
タスクの見積もり方法を工夫してみて約1ヶ月経ちましたが、当初想定していなかった効果もいくつかありました。

### 自分の見積もりに自信がもてる
今まで感覚値で見積もっていたものを細分化して見積もることによって自信が持てるようになりました。
マネージャーたちに「このスケジュールで大丈夫？」と聞かれた時に「各タスクにこれくらいの時間がかかりそうです。その結果全体としては◯日くらいかかります。」と根拠を持った説明ができるようになりました。

### バッファが考えやすい
実工数に対してバッファをどれくらい持つべきか悩んでいましたが、今は1日4~6時間で見積もるようにしています。実際の業務時間は1日8時間ですが、毎日8時間全てを自分のタスクに使えるわけではないので1日あたり4~6時間を工数として見積もり、残りの時間はバッファとして考えるようにしています。

## これから
工数見積もりについて書かせてもらいましたが、正直言って「見積もり上の工数と実際にかかった工数が全く同じになる」ことは不可能だと思っています。しかしながら見積もりと実績値の差を限りなく減らすことはできると思うので、各タスクが終了した後に見積もりと実際の工数を比べてなぜ差があったのかを振り返り、次の見積もりに活かすというサイクルを意識しています。このサイクルを繰り返すことで見積もりと実績値の差を限りなく減らすことができるようになると考えています。
また、今自分のチームの他の若手メンバーにも同じ方法で工数を出してもらっています。
他のメンバーの意見も取り入れながらやり方は都度変えていくつもりです。

## まとめ
若手エンジニアが先輩から教わった工数見積もり方法について話をさせていただきました。
あくまでも一例であり、もっといい方法はたくさんあると思うので、参考程度にとらえていただければと思います。
意見や不明点等あれば気軽にコメントしていただければと思います。
最後までお付き合いいただきありがとうございました。
いまさらの微少電流計

[RL78＋MCP3901で微少電流計](https://yokaton.com/mcu-202209-microa/)を作ったときに「INA226の方が簡単じゃね？」となり、試しに作ってみました。
結果：ホントに簡単だった。
マークダウン記法が苦手なので[**こちらに書きました**](https://yokaton.com/mcu-nxp/#i-0)。

「なんじゃこりゃ」ってぐらい簡単に完成して、それなりに精度も出てるようです。
理屈上は0.25μAまで見えるはずだけど、調べようもないし怪しいけど、少なくとも2.5μAは読み取れてる雰囲気です（その後、ちょっと高価なテスターを買って比較してみたら1μA以内の誤差範囲なようです）。
自分の用事のある領域は2～5V、10μA～10mAなのでこれで十分。

手持ちの抵抗に電圧をかけて「計算上はXXμAなはず」と言う手段で計測結果と比べてみたんですが、なかなか良い線行ってます。
シャント抵抗を暖めたり冷やしたりしても、それほどは変化もせず、これなら一応実用的かなと思いました。

間欠的な電流の変化を捉えたくて作ったけど、こう言う道具って安く売ってないんですかね？
売ってればその方がもっと簡単で良いんだけど･･･ただし最大でも1万円程度まで。電流プローブとか使ったことは無いけど高いですよね～

次回はもっと高速なI2Cの付いたCPUでやってみたいけど（I2C速度の制限で最高のサンプリング速度140μSを出せてない）、INA226のI2C最高速度の2Mとか出るI2Cを内蔵したCPUって世の中にあるんですか？（Hs-mode － ハイスピードモードとか言うのがあるらしい）。

たかがI2Cと思ってたけど色々と進化してるんですね～

↓RL78のSTOP時の消費電流を計測したグラフ。
![2020-01-12_15h27_36.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43186/ecc67423-b41a-26f9-ce7e-ee125e3e1263.jpeg)
MacOSX Mojave で AFL を使う

## 導入

MacOSX で AFL を試すまでの手順とワナのご紹介です。

AFL（American fuzzing loop）はプログラムにデータのエントリポイントを埋め込むタイプのファザーで、さまざまなファジングフレームワークのエンジンとしても利用されています

参考：
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072/8d88a15d-81a9-0822-1b77-c38fe68e49e6.png" width= 700px>
https://github.com/google/oss-fuzz


## 手順

ソースコードの取得。試した時点では2.52bが降ってきました。展開して、make します。

```
$ wget http://lcamtuf.coredump.cx/afl.tgz
$ tar -vxzf afl.tgz

$ cd afl-2.5.2b
$ make
...

WARNING: Fuzzing on MacOS X is slow because of the unusually high overhead of
fork() on this OS. Consider using Linux or *BSD. You can also use VirtualBox
(virtualbox.org) to put AFL inside a Linux or *BSD VM.
```

MacOS は fork() の負荷が高いので、ファジングが凄まじく遅くなるそうです。BSDか、VirtualBox上のBSD環境での実行を検討してくださいとのこと。*ワナ1

次にテスト用のシードファイルを作成します。

```
$ mkdir test_in
$ echo -n 'hoge' > test_in/hello
```

いよいよ実行、、しようとすると abort します。

```
$ ./afl-fuzz -i test_in -o test_out ./a.out

[-] Whoops, your system is configured to forward crash notifications to an
    external crash reporting utility. This will cause issues due to the
    extended delay between the fuzzed binary malfunctioning and this fact
    being relayed to the fuzzer via the standard waitpid() API.

    To avoid having crashes misinterpreted as timeouts, please run the
    following commands:

    SL=/System/Library; PL=com.apple.ReportCrash
    launchctl unload -w ${SL}/LaunchAgents/${PL}.plist
    sudo launchctl unload -w ${SL}/LaunchDaemons/${PL}.Root.plist
```

MacOSX Mojave 環境ではクラッシュレポートが外部ユーティリティに転送されるため、ファジングエンジンがこれを認識するまでの間にタイムアウトしてしまう、そうです。ので、ファジング実行時にはこれを一時的にオフにする必要があります。書いてある通り following commands を順に打ってOFFにします。*ワナ2

再度実行。

```
$ ./afl-fuzz -i test_in -o test_out ./a.out
```

<img width="1005" alt="afl.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072/9d6271cc-fcc5-88f8-21f8-80f82e64b1f5.png">

無事動作しました、、が、警告のとおり、遅いです。ファジングというかMacの負荷テストみたいになります。

## 参考

基本的な手順はこちらを参照させていただきました。ありがとうございます。

- [ご注文は American Fuzzy Lop ですか？](https://qiita.com/binzume/items/8e985e7bd01a6e4000d3)
非開発者がほとんどを占めるチームでTwilio + NCMB + Monacaでアプリを作った話

## はじめに

遅くなってすみません！
この記事は、[Twilio Advent Calendar 2019](https://qiita.com/advent-calendar/2019/twilio)の19日目の記事です。

はじめまして。
[富士通クラウドテクノロジーズ](https://fjct.fujitsu.com/)という会社で[ニフクラ mobile backend](https://mbaas.nifcloud.com)というサービスの企画を担当している[@sasachi1231](https://qiita.com/sasachi1231)と申します。
今日は、ハッカソンに参加した時にTwilioなどのサービスを使った話です。

## あらまし

ニフクラ mobile backendのチームメンバー有志で構成されたメンバーで[Spajam](https://spajam.jp/)というハッカソンに出場することになりました。
メンバー構成は以下。

- Rさん(企画チームリーダー)
- Nさん(企画チーム)
- Mさん(企画チーム)
- Sさん(開発チーム)
- 僕(企画チーム)

そうです。エンジニアが1名しかいないんです。
多分一般的にはエンジニアが3名くらいいて、企画者とデザイナーが1名ずつとかだと思うんですが、今回は5名中4名が企画、エンジニアとして働いている人は1名のみ。デザイナーに至っては不在という感じです。

## 開発言語／環境を選ぶ

Spajamは、モバイルアプリ並びにプレゼンを成果物として審査が行われます。
したがって、モバイルアプリ(スマホアプリ)を作る必要があるのですが、先程も書いたとおり、僕達のチームはほとんどが非開発者。XCode(Swift or Objective-C)やAndroid Studio(Java or Kotlin)は使えません。

みんなが使える言語は何か、それぞれ挙げていったところ、JavaScriptだけはみんなが共通して使うことができるということがわかりました。
(企画チームでは、ニフクラ mobile backendのWebページを更新することが多々あり、最低限のJavaScriptの知識はみんな持っていた形です)
そこで、HTML5 / JavaScriptをつかってスマホアプリが開発できる[Monaca](https://ja.monaca.io)を使うことにしました。

ちなみに、デザイナーも不在なため、簡単にきれいなUIを作ることができる[Onsen UI](https://ja.onsen.io/)も使って、UIを整えていくことにしました。

## 作ったもの

僕たちは、テーマが「観光」だったので、それに絡めてブレストを行いました。
いろんな案が出る中、「観光地に行った時、そのへんにいる人に写真撮ってくださいって頼むの緊張するよね」という話になり、そこからアイデアを膨らませていった結果、シャイな人でも「写真とってください！」って言えるアプリ、その名も **Shy-to-seeing** (シャイ + サイトシーイング)を作ることになりました。

ユーザーのユースケースは以下です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280892/f21ba658-66d8-3f93-9556-1ba4dd56d462.png)

1. ユーザーAが写真をとって欲しいところでアプリを起動します
2. 近くにいるShy-to-seeingをインストールしているユーザーの一覧を表示します
3. 特定のユーザーを選ぶと、そのユーザーに電話がかります(※自動ガイダンス)。この際、電話を受け取った人は、「写真を撮ってあげるなら1を～」というガイダンスに従い、ボタンを押します
4. 承諾してくれた人が駆けつけてくれます
5. はい、チーズ！

フロントエンドにMonaca + Onsen UI、ユーザーの位置情報を格納するデータベースにニフクラ mobile backend、電話を掛ける処理にTwilioを使っています。

## 結果

残念ながら入選することはできませんでした(選ばれたら箱根の温泉旅館にいける)。
非常にレベルが高く、「えっこれ今すぐ製品化できるじゃん」というクオリティの作品もちらほらありました。
いい刺激になったなーと思います。
普段、開発者向けサービスの企画をしているので、たまには開発者の立場にたってみることも大事だなあと思いました。

## 作ってみて

### よかったこと

- Twilioは「電話をかけられる」「SMSを送れる」程度のことは知っていたけど、音声ガイダンスを流せるのはびっくりした
    - プレゼンウケもなかなか良かった。やっぱり音が流れるのはわかりやすく訴求できる
- Onsen UIはリファレンスがわかりやすく、普段から触っていなくてもすぐに使うことができた
    - [ここ](https://ja.onsen.io/)にわかりやすくリファレンスがのってる
- 全員が触れる言語だったので、全員が分担しつつコードを書くことができた

### 失敗したこと

- Twilioで最初海外の番号を取得してしまい、番号を取り直す必要が生じた
    - 結果無料枠を超えてしまった
- Onsen UIで、最初気づかずaタグで遷移していたので、途中で全画面ons-navigatorに修正するのが大変だった
- JSファイルとHTMLファイルを明確に分けず、結構HTMLファイルにJSも記載していたので、同時に編集してしまいコンフリクト、ということが多かった
    - おそらくちゃんとJSファイルを切り出しておけば防げた

## おわりに

ハッカソンに参加したのは初めてで、正直最初は結構戸惑いましたが、勢い任せてわーーーっと開発するのは楽しいなあと思ったので、たまにはこう言うのにも出てみたいなあと思いました。
あと、周囲のエンジニアがどんな言語や手法を使っているのかも知ることができるので、トレンドを知ることができるいい機会にもなりました。

またぜひ出てみたいです。

ちなみに、弊社が提供している[ニフクラ mobile backend](https://mbaas.nifcloud.com)には、スクリプト機能というFunction as a Service的な機能があるのですが、Twilioさんと連携させていただいていて、簡単にアプリにSMS認証などを組み込むことができます。
いろいろな使い方ができると思うので、是非試してみてください！

次は、[@RyBB](https://qiita.com/RyBB)さんで、[Twilio Verifyを使ってkintoneのアプリに二要素認証をつけてみた](https://qiita.com/RyBB/items/344ea34186afba7a30f5)です。
(僕が遅れたので、書いてる時点で既に公開いただいています……)
OSSコンプライアンスに関する各社のケーススタディ

### 自己紹介
みなさん，はじめまして．
パナソニック株式会社でOSSコンプライアンス推進を担当している加藤と申します．
今回は，OpenChain Japan WGの活動で集まったケーススタディを紹介したいと思います．

## 各社のケーススタディ

OpenChainの成果物は下記のWikiに置かれています．
https://wiki.linuxfoundation.org/openchain/jwg_outcomes_page

ケーススタディはこちら
OSSコンプライアンス推進の組織・体制について各社の事例 (日本語・英語)
https://wiki.linuxfoundation.org/_media/openchain/openchainjwg_organization_lt_20180419_jpen_.pdf

OSSコンプライアンス推進の教育・啓発について各社の事例 (日本語・英語)
https://wiki.linuxfoundation.org/_media/openchain/openchainjwg_education_lt_20180613.pdf

OSSコンプライアンスのステップアップ、各社のケース (日本語・英語)
https://wiki.linuxfoundation.org/_media/openchain/openchainjwg_activity-stepup_lt_20191218_jpen_.pdf


### なぜ事例集めをしようと思ったのか？
OSSコンプライアンスを社内で推進していると，「他の企業はどんな取り組みをしているのだろう？」，「どんなことを課題に取り組んでいるのだろう？」と思うことがあります．それに対して，今ではOSSコンプライアンスに関するセミナーなどで企業の方のセッションを聞くことで，いろいろと参考になる情報を得ることもできます．しかし，セミナーでは聞けても1社もしくは2社くらいの事例で，聞きたかった部分について語ってくれるかもわかりません．

そこで，テーマを決めて，Lightning Talkの形式で事例紹介をしてみれば，いろんな事例を聞けるのではないか？，それをWikiに載せれる形式にすれば，参加できなかった方にも参考になるのではないか？，また，担当者が社内で推進する場合にも「他の企業は，こんなに進んでいる！」とエビデンスと共に説明できて，OSSコンプライアンス推進担当者の力になるのではないか？，などと考え，実施してみたのが始まりです．

### これから
OpenChain Japan WG では，今後も，いろいろなテーマで事例集めLightning Talkを企画したいと思います．


### おわりに
今回は，OSSコンプライアンスに関する各社のケーススタディの紹介を行いました．
みなさんの参考になる情報があれば幸甚です．

また，このケーススタディ紹介Lightning Talkの場では，資料にない口頭だけの情報もいろいろと聞けたりします．興味のある方はOpenChain Japan WGのMLを購読し，全体会合に参加してみてください．はじめは聞く側でも，きっと話す側に回りたくなると思います．

### 明日のテーマは？
明日は日立製作所の野村さんが「OpenChain認証取得、日立製作所の取り組み」を記載下さいます．日本企業でいち早くOpenChainの認証を取得された日立製作所さん．きっと皆さんにも参考になることでしょう！
とあるスクラムチームの小さな改善のお話

# はじめに

これは[株式会社メディアドゥのアドベントカレンダー](https://qiita.com/advent-calendar/2019/mediado)20日目の記事です。
あるスクラムチームの、レトロスペクティブにおける、小さな改善の話です。
それではどうぞ。

# ねんのため、基本知識

アジャイル・スクラムはすでに多くの開発現場に溶け込んでいるため、詳細な説明は不要かと思いますが、念の為さらっと触れておきます。

スクラムは、透明性・検査・適応という三本の柱があり、その柱を基礎に各イベントが設計されているわけですが、今回のテーマであるレトロスペクティブは検査・適応に集中するためのイベントです。

具体的には、開発にまつわる様々な事柄の改善策を議論し、次回スプリントでより多くの価値を出せるようにスクラムチーム全員で模索していく、といったところです。

何も無いところで議論すると意見が出なかったり発散してしまうため、振り返るためのフレームワークとしてKPTを利用するチームが多いと思います。Keep・Problem・Tryを順番に議論していくことで問題点から改善策を導く方法で、巷では下記の様なボードをよく見かけます。
<img src="https://i.gyazo.com/75c39fd3d34c530473b7ebfe9f879e26.png">


# どういう状態だったか

これまでのレトロスペクティブでは、KPTに準ずる形で改善策が議論されていました。

やり方自体特に問題なく、メンバーからは活発に意見が出ていて、むしろレトロスペクティブを有効に活用できているよう感じました。が、チームメンバーからはなんとなく上手く行っていないという声が出る不思議な状態でした。

これは一体どういうことなのか、そういえば過去私が携わってきたチームでもメンバーがレトロスペクティブに対して意味を見失ってしまったことを思い出しながら、問題点を考えていきます。

# 問題点

KPTではProblem(問題点)からTry(改善策)を考えますが、Problemは問題となっている"出来事"を上げることが多いと思います。氷山モデルを用いて考えると、出来事を生み出しているパターンや構造などを発見しなければ、本質的なTryを導き出せないことが分かります。

![氷山モデル](https://i.gyazo.com/39b6255d2a3d8c554c08ac4f0ed79d7d.png)

これまでのレトロスペクティブでは、出来事の全体像を把握していなかったため、Tryが本質的ではなかったのではないでしょうか。これが問題点その１です。

もう一つ考えられるのがKeepの扱いです。Keepはそのスプリントで起こった継続したいことを列挙していくため、ポジティブな意見でありチームの強みと言えます。
しかし、Keepはせっかく上げてもスプリントごとにリセットされてしまう運用をしていたため、チームの強みを醸成できていなかったのではないでしょうか。これが問題点その２です。

これらの問題点により、レトロスペクティブを効果的に使いこなせていないため、なんとなく成果出てない/上手く行っていない、と感じるようになったと考えました。

# KPT改善

問題点を解消するため、KPTのやり方を改善してみます。

Problemの全体像を分析できていないことが問題だったので、Problem・Tryの間にcauseという領域を定義しました。
causeで考えるのは、Problemの出来事に対して「なぜこうなったか」「なにがブロックしているか」など、氷山モデルのパターン・構造・メンタルモデルに該当するものです。

出来事の全体像を機械的に思考させることで、本質的なTryが導き出されます。
(余談ですが、もしかするとcauseよりfactorの方が的確な表現かもと記事を書いていて思いましたが、その辺りは都度改善していこうと思います。)

続いてKeepについて。Keepはチームの強みです。強みは文化として定着させることで、チームがより成果を出せるようになります。
そのために、スプリントごとにリフレッシュされていたKeepをしっかり定着させる目的で、あえてTryに移動させることを推奨しました。

最後に、Tryした内容が暗黙知として、チーム全員が認識・実行できている状態になっていれば「TeamCuluture (チームの文化)」という枠で永続化することにしました。
将来的に新しいメンバーが加入した時には、TeamCulutureの確認をオンボーディングに組み込んでいければ素敵です。

![KPcT](https://i.gyazo.com/e9fbefbea1c9798a6bfa39722d213a8d.png)

# 具体的なやり方

スプリント1のレトロスペクティブにて

1. KeepとProblemをメンバーそれぞれ考え、ボードに書き込みます
2. 1についてメンバー全員でグルーピングと質疑応答により、内容の合意をします
3. Problemについて、causeを考えていきます
   1. Problemとcauseは1:1でも1:nでも構いませんが、必ずcauseはどれかのProblemに紐づいている必要があります
4. causeについてメンバー全員で議論します
5. 次回スプリントで行うTryを、Keepとcauseから掲げます
   1. Keepに上がった項目のうち、チームの文化としたいものをTryに掲げます
   2. causeから具体的な改善策をTryとして掲げます (Tryはプロダクトバックログ化のために、ゴールの認識を合わせておくとスムーズです)
6. Tryをプロダクトバックログ化し、スプリントを開始します

スプリント2以降のレトロスペクティブにて

1. Tryのプロダクトバックログについて、チームメンバー全員で振り返ります
   1. チーム文化として根付いていれば、TeamCultureへ
   2. Try中、または未着手であればTryに残します
2. ここからは1回目と同じサイクルを回していきます

<img src="https://i.gyazo.com/bb6afc2df2e94b7dad8a4e13c7e421a5.png">

# やってみてどうなった？

今回の小さな改善により、今まで隠れていた様々なものが見えるようになり、メンバーの目線が前より合ってきたような気がします。結果としてTryがより本質的になり、レトロスペクティブがより機能するようになってきました。

まだこの方法で数回程度しかレトロスペクティブを実施していない状態ですが、すでにTeamCultureが溜まっていて、着実に強くなっているような感じです。

#  まとめ

レトロスペクティブを効果的なイベントにすべく、KPTを改善してみました。

まだ始めたばかりのものなのでしっくりこない部分が多々ありますが、そこはアジャイルマインドによる検査と適応で改善したいところです。

また、KPTはあくまでもツールであり、これを使いこなすことがゴールではないと思います。
常に成果を出し続けられるチームになることを、チーム一丸で目指していきたいと思います。

明日はそんなチームで獅子奮迅の活躍をしている nukomaru さんです。はりきってどうぞ！
C#のTry Catch Finally Throw

タイトルの通り、C#での例外をCatch句内でthrowした挙動を確認してみました。

環境：Visual Studio2017，.net472

``` C#:Form.cs
private void button1_Click(object sender, EventArgs e)
{
    textBox1.Text += "①実行開始" + Environment.NewLine;
    try
    {
        Method();
    }
    catch
    {
        textBox1.Text += "⑤実行中　呼び出し元のCatch" + Environment.NewLine;
    }
    textBox1.Text += "⑥実行完了" + Environment.NewLine;
}

private void Method()
{
    try
    {
        textBox1.Text += "②実行中　Try" + Environment.NewLine;
        throw new Exception();
    }
    catch
    {
        textBox1.Text += "③実行中　Catch" + Environment.NewLine;
        throw;
    }
    finally
    {
        textBox1.Text += "④実行中　Finally" + Environment.NewLine;
    }
    textBox1.Text += "⑤実行されない　Try外" + Environment.NewLine;
}
```

実行結果

```
①実行開始
②実行中　Try
③実行中　Catch
④実行中　Finally
⑤実行中　呼び出し元のCatch
⑥実行完了
```

知識の浅い自分は'throw'したらFinallyの実行順がどうなるのか…？
と思って確認した結果です。
認証機構のマイクロサービス化

決済基盤、会員基盤をメインにサーバーサイドエンジニアをやっているルンバです。   
今日はNAVITIMEの認証基盤をマイクロサービス化したときのお話をいたします。   
複数プロダクトを開発運用している方の参考になれば幸いです。

## はじめに
NAVITIMEでは様々なアプリを開発運用しています。
NAVITIMEのプロダクトは大まかには下記の形で開発運用されています。
  
・ユーザーデータはアプリローカルではなくDBに保存する
 
・アプリから各プロダクトの専用APIサーバーに接続し、ユーザーデータの参照更新を実施している

## 既存システム
![01_mini.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315364/f74dca20-ad7e-1ac1-6371-483ac36aaa8e.jpeg)


## 既存システムの問題点
### 1. 仕様差分
各プロダクトAPIサーバーで独自実装しているため、プロダクトによって微妙な仕様差分が発生していました。社内独自フォーマットにユーザー情報を格納し社内独自の暗号化形式で作られていたのですが、サービスによっては認証には直接関係ない情報がフォーマットに追加されていく状況でした。もちろんググってもHow To記事は出てこないため、年季の入ったドキュメントを1から読んだり有識者にヒアリングする必要があり、学習コストが高い仕様でした。
### 3. クラウド化の流れ
社内のアーキテクチャがクラウド化していく中で、いわゆる「サーバーレス」という選択肢も出てくるようになりましたが、この独自の認証仕様をどのように踏襲していくかが悩みの種でした。

## 認証機構APIの構築
問題を解決するため、全社が同時に参照するAPIサーバーを構築しました。
![02_mini.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315364/7374812a-5a4e-67f5-0fec-c78660a5ed02.jpeg)

### 1. 認証処理専用のAPIを構築
認証処理を賄うAPIサーバーを構築しました。
### 2. JWT規格に統一
認証規格は①一般化されていて、ググればおおよその仕様の理解ができるもの②クライアント側がどういうアーキテクチャであっても実現できるものという軸で選定し、JWT（RFC 7519）を採用しました。
### 3. トークンを使ったユーザーデータ参照APIも構築
認証機構APIの構築と合わせて、ユーザーデータ参照APIも構築しました。今までは各プロダクトのAPIサーバーでDB接続して参照更新していたユーザーデータを、認証機構APIで発行したトークンを用いて参照更新する形に刷新しました。認証機構と合わせて、主なユーザーデータの参照更新の仕様もAPI化することで統一されました。
![03_mini.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315364/4f4cd22b-12a2-d558-5d73-22e62ca8e8b7.jpeg)


## 改善された点
### 認証仕様の全社的な統一化
基本的には認証機構APIをリクエストしJWTを受け取るだけ、という仕様に統一化されました。今まで各プロダクトのAPIで独自で実装していた処理がごっそりなくなることでコードも単純化され、また新規サービスの開発も遥かに簡単になりました。APIの仕様書通りにリクエストするだけでいいので1時間程度で開発が完了します。
### 仕様の汎用化
JWTという一般化された規格を用いることで、一般的なドキュメントを読むことで認証処理の大枠は理解できるようになりました。JWT内部のクレーム情報にはいくつかNAVITIME独自の仕様が含まれていますが、そこは社内整備されたドキュメントを読めば理解できるようになりました。
### クラウド化に対応
APIベースでのJWTのやり取りで認証処理が完結するため、クライアント環境がAWSでもGCPでも、サーバーレスであっても、統一的な仕様で認証が行えるようになりました（基本的にはAPIにリクエストするだけでいい）

## 気をつけていること
全プロダクトが1つのAPIを参照するため、アクセス数の見積もりには気を使う必要があります。
このAPIサーバーが輻輳するとサービス全断リスクがあるため、認証APIサーバーは他APIサーバーよりも余裕を持った台数で稼働しています。

## まとめ
ドキュメントの整備やアクセス負荷の対応等、まだ課題はありますが
認証機構をAPI化することで開発運用の効率化ができました。
FirebaseのGoogleService-Info.plistを環境ごとに分ける


## みんな大好きFirebase

っていうほど使いこなせているわけではないのですが。()
今回はFirebaseを利用するにあたり、困ったことを備忘録チックに。

## Firebaseの導入方法
Firebaseのドキュメントによると

1. Firebaseプロジェクトを作成する
2. アプリをFirebaseに登録する
3. Firebase構成ファイルを追加する
4. アプリにFirebaseSDKを追加する
5. アプリでFirebaseを初期化する
6. あとはいい感じに(こんなことは書いてません)

で、今回は3の
**Firebase構成ファイル**
に注目します。

## Firebase構成ファイルを追加する
Firebaseでアプリを作成していくと、「GoogleService-Info.plist」という名の我が衣に宿りし闇の・・・
まぁ構成ファイルをダウンロードできますと。
で、これをアプリに追加するわけですよ。
ここで、問題が発生します。

・・・あれ？
開発環境と本番環境、別々のFirebaseプロジェクトだな？

## 解決

- それぞれの環境用のplistをアプリに追加する
- RunScriptによってその環境で必要なplistをFirebaseが求める形にリネームして配置する

こんな感じです。
で、実際に動かすRunScriptは以下の感じになるかと。
({開発環境}、{本番環境}のところは、各々が作成したBuildConfigurationによって書き換えてください)

```shell
if [ "${CONFIGURATION}" = "{開発環境}" ]; then
  cp "${PROJECT_DIR}/${PROJECT_NAME}/Resource/GoogleService-Info_Debug.plist" "${BUILT_PRODUCTS_DIR}/${PROJECT_NAME}.app/GoogleService-Info.plist"
elif [ "${CONFIGURATION}" = "{本番環境}" ]; then
  cp "${PROJECT_DIR}/${PROJECT_NAME}/Resource/GoogleService-Info_Release.plist" "${BUILT_PRODUCTS_DIR}/${PROJECT_NAME}.app/GoogleService-Info.plist"
fi
```

## 余談
Firebaseプロジェクトには複数のアプリを紐づけられるので、開発環境とステージング環境を一緒にしていることが多いです。
上記のRunScriptで、if文をちょこちょこっとすればおけです。

```shell
if [ "${CONFIGURATION}" = "{開発環境}" ] || [ "${CONFIGURATION}" = "{ステージング環境}" ]; then
```

## 最後に
一回やっちゃえばこぴぺなので、どんどんこぴぺしていきましょう！
あえて言おう！Firebaseは便利だと！
mintty + tmux + Vim の環境で、insert mode 終了時に IME を off にする

# 自分の環境
Windows -> mintty -> SSH -> tmux -> Vim

# vimrc
```vim
if &term =~ 'tmux'
  let &t_EI .= "\ePtmux;\e\e[<0t\e\\"
elseif &term =~ 'xterm'
  let &t_EI .= "\e[<0t"
endif
```
mintty は要 ver. 3.0.2 以降。

# 過程
* tmux なしだと ["ここ"](https://qiita.com/mwmsnn/items/0b40662a22162907efae) に書いてある設定で行けたのに、tmux の内からだとうまくいかなかった。
* IME off の制御が tmux から mintty にうまく伝わっていないのだろうと推測。
* この制御が Control Sequence Introducer (CSI) というもので実現されていると知る。
* ["ここ"](https://unix.stackexchange.com/questions/409068/tmux-and-control-sequence-character-issue) にたどり着く。

# その他
* ~~Insert mode を抜けてから IME が off になるまで少し時間差がある。この間のキーストロークが抜け落ちてしまう。どこでこのラグが発生しているのかはよく分からない。~~ コメントに書いた通り、`\ePtmux;\e` + `\e\\` を追加したことによって時間がかかるようになったと思っていたが、そうではなく単に tmux の待ち時間が加わっていただけだった。
* Tera Term でも同じように設定できるはず。
* あと以下のように設定しておくと、IME on のときはカーソルが赤くなって分かりやすいのでとっても便利。

```:.minttyrc
IMECursorColour=255,0,0
```

# 参考 links
[挿入モードを出る時にIMEをオフにする（SSH接続など端末エミュレータからVimを利用する場合）](https://qiita.com/mwmsnn/items/0b40662a22162907efae)
[tmux and control sequence character issue](https://unix.stackexchange.com/questions/409068/tmux-and-control-sequence-character-issue)
cssうんちをストーカーさせてみた

# マウスストーカー
マウスに追従するようなアニメーションのことをマウスストーカーというらしい。
というわけでうんち追従させてやんよ💩
単純にマウスカーソルを💩画像にするのは面白くないので、そこは違う形で実装するぞ！

# Let's Try
↓画面内でマウスを動かしてみよう！
<p class="codepen" data-height="265" data-theme-id="default" data-default-tab="result" data-user="petapetapeta" data-slug-hash="wvBgZxd" style="height: 265px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;" data-pen-title="unchi-stalker">
  <span>See the Pen <a href="https://codepen.io/petapetapeta/pen/wvBgZxd">
  unchi-stalker</a> by petapetapeta (<a href="https://codepen.io/petapetapeta">@petapetapeta</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

# ポイント
## html(pug)
htmlでカーソルのポイント用の要素を2つ用意する
1つはその時のマウスポイントの位置を表示する要素(`.cursor-small`)、もう1つは遅延で追従する要素だ(`.cursor-big`)

```css
#app
  .cursor(v-show="!isOut")
    .cursor-small(ref="cursorSmall")
    .cursor-big.unchi(ref="cursorBig")
```

## css(stylus)
デフォルトのカーソルはいらないので`none`で消してしまいます。
```css
body
  cursor none !important
```
`.cursor-small`は今回は円、`.cursor-big`はうんちのcssを書き、初期に表示されないように画面外にポジションを設定しておきます。

## javascript
一番のポイントは`mousemove`のイベントでマウス位置を取得し、その位置に`.cursor-small`をもってくる＋`.cursor-big`は前回のマウス位置と現在のマウス位置でちょこっと計算をはさみ、遅延させるようにすることです。
あとは`mouseleave`のイベントで要素を非表示にするようにしておくと画面外にマウスカーソルが出た時にうんちが残ってしまうということがなくなるぞ💩
Rustでasyncする、stdのみにできないのか？（できなかった）

# はじめに
- Rustでasyncしようとしたら、stdだけではすぐに使えなかった
- 外部crateを使わずにできないものか調べてみる

## async/await

- async functionからのみawaitできる
- mainはasyncじゃないからasync functionの終了待ちができない

## Javascript/typescriptのasync/awaitと違うこと
- awaitしないとasync functionは動きださない
- asyncはfunctionだけでなく、ブロックとしても使える



## まずは外部crate利用の短いコードで

### futures版

```toml:Cargo.toml
[dependencies]
futures = "0.3"
```


```rust:main.rs
use std::thread;
use std::time::Duration;
use futures::executor::block_on;

async fn hello() {
    println!("hello");
    thread::sleep(Duration::from_secs(3));
    println!("hello waited 3sec");
}

fn main() {

    println!("main@1");
    block_on(hello());
    println!("main@2");

}
```

### async-std版

```toml:Cargo.toml
[dependencies]
async-std = "1.3.0"
```


```rust
use std::thread;
use std::time::Duration;
use async_std::task::block_on;

async fn hello() {
    println!("hello");
    thread::sleep(Duration::from_secs(3));
    println!("hello waited 3sec");
}

fn main() {
    println!("main@1");
    block_on(hello());
    println!("main@2");
}
```

### tokio版

```toml:Cargo.toml
[dependencies]
tokio = "0.2"
```


```rust
use std::thread;
use std::time::Duration;
use tokio;

async fn hello() {
    println!("hello");
    thread::sleep(Duration::from_secs(3));
    println!("hello waited 3sec");
}

fn main() {
    println!("main@1");
    tokio::runtime::Runtime::new().unwrap().block_on(hello());
    println!("main@2");
}
```




## stdのみのコード


```rust:main.rs
use std::thread;
use std::time::Duration;

async fn hello() {
    println!("hello");
    thread::sleep(Duration::from_secs(3));
    println!("hello waited 3sec");
}

fn main() {

    println!("main@1");
    block_on(hello());
    println!("main@2");

}

use std::{
    future::Future,
    ptr,
    task::{Context, Poll, RawWaker, RawWakerVTable, Waker},
};

fn block_on<F>(f: F) -> F::Output
where
    F: Future,
{
    let waker = my_waker();
    let mut context = Context::from_waker(&waker);

    let mut t = Box::pin(f);
    let t = t.as_mut();

    loop {
        match t.poll(&mut context) {
            Poll::Ready(v) => return v,
            Poll::Pending => panic!("This executor does not support futures that are not ready"),
        }
    }
}

type WakerData = *const ();

unsafe fn clone(_: WakerData) -> RawWaker {
    my_raw_waker()
}
unsafe fn wake(_: WakerData) {}
unsafe fn wake_by_ref(_: WakerData) {}
unsafe fn drop(_: WakerData) {}

static MY_VTABLE: RawWakerVTable = RawWakerVTable::new(clone, wake, wake_by_ref, drop);

fn my_raw_waker() -> RawWaker {
    RawWaker::new(ptr::null(), &MY_VTABLE)
}

fn my_waker() -> Waker {
    unsafe { Waker::from_raw(my_raw_waker()) }
}
```

https://stackoverflow.com/questions/56252798/how-do-i-execute-an-async-await-function-without-using-any-external-dependencies/56258784#56258784

を小変更しただけ。

**これはヤバい。各自で書くべきではない。**



# まとめ

- Rustは公式ではExecutorを提供していないため、他のcrateを使おう。

## 雑感

- Executorは時期に公式で提供されるのでは。
- Rustがasync/awaitを提供しだして間もないからか、世の中に動かないexampleコードが多い。
- JS/TypeScript脳から考えると、asyncがawaitするまで走らないのは構造的に仕方ないとは言え、悩む。
- runtimeはサンプルコードをよく見かけたけど、deplicatedでasync-stdかtokioをどうぞ、と。
Elastic CloudにてKibana UIを日本語化する方法


##１．はじめに

Elastic CloudにてElasticsearch Clusterを構築する際に、kibana.ymlでユーザー独自の設定を行うことができる。
この機能を用いて、KibanaのUIを日本語に変更する。

##２．設定方法


以下に記載の通り、kibana.ymlに```i18n.locale: "ja-JP"```を設定すれば、KibanaのUIを日本語に変更することができる。ちなみに、このパラメータは、X-Packの機能でBasic以上のライセンスが無ければ設定することができない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482612/b4fd5859-cf01-07be-5691-4aff47973331.png)


Elasticsearch Clusterを構築する際に、下記の通り「User Setting overrides」からKibanaの設定項目を開き、```i18n.locale: "ja-JP"```を設定します。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482612/96fe5513-6c55-64f9-f360-63e5e7d455e7.png)


##３．確認

下記添付の通り、日本語化されていることの確認が取れました。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482612/9772f767-0c3b-fcfc-b38d-b448fea2c46a.png)


##４．その他カスタマイズ項目

Elastic Cloudで設定できるkibana.ymlは、すべてではなく限られており[ec-manage-kibana-settings](https://www.elastic.co/guide/en/cloud/current/ec-manage-kibana-settings.html)を参照すると詳細な内容が確認できる

以上
Amplifyを使って任意のタイミングでIDトークン、アクセストークンを更新する

## 概要

Amplifyを使って任意のタイミングでIDトークン、アクセストークンを更新する。

## 実装

一度認証されているのが前提。

Amplifyにはそれ用の口がない（っぽい）ので、Amazon Cognito Identity SDK の機能を使って更新する。

```javascript
import { Auth } from "aws-amplify";

const cognitoUser = await Auth.currentAuthenticatedUser();
const currentSession = await Auth.currentSession();

cognitoUser.refreshSession(currentSession.refreshToken, (err, session) => {
    console.log('session', err, session);
    const { idToken, refreshToken, accessToken } = session;
});
```

## 参考

* [元ネタ](https://github.com/aws-amplify/amplify-js/issues/2560#issuecomment-481707972)
* [Amazon Cognito Identity SDK](https://github.com/aws-amplify/amplify-js/tree/master/packages/amazon-cognito-identity-js)
データマイニング手法7選

 
![blue-and-yellow-graph-on-stock-market-monitor-159888.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262932/8c2ab3d3-cbe3-902e-6f86-abbbd99ac952.jpeg)

[データマイニング](![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262932/ab0df843-5f61-1a91-5e16-3ed294d5fe4b.png)
)とは、事前にわからないが潜在的に有用な、不完全でノイズが多く、ファジーでランダムな大量のデータから隠された情報を抽出するプロセスです。

情報ストレージ形式によると、マイニングに使用されるオブジェクトは、リレーショナルデータベース、オブジェクト指向データベース、データウェアハウス、テキストデータソース、マルチメディアデータベース、空間データベース、一時データベース、異種データベース、およびインターネットです。

#一、データマイニングプロセス

ビジネス上の問題を明確に定義し、データマイニングの目的を決定します。

データ準備：データ準備には、大規模データベースおよびデータウェアハウスターゲットでのデータマイニング用のデータ抽出ターゲットデータセットの選択、データの完全性と一貫性のチェック、ノイズ除去、不足しているフィールドを埋める、無効なデータを削除するなど。

データマイニング：データ関数のタイプとデータの特性に応じて、対応するアルゴリズムが選択され、精製および変換されたデータセットに対してデータマイニングが実行されます。

結果分析：データマイニングの結果を解釈および評価し、ユーザーが最終的に理解できる知識に変換します。

#二、データマイニングの分類

直接データマイニング：目的は、利用可能なデータを使用してモデルを構築することです。このモデルは、残りのデータを記述し、特定の変数（データベースのテーブル、つまり列の属性として理解できる）を記述します。

間接的なデータマイニング：特定の変数はターゲットで選択され、モデルによって記述されるのではなく、すべての変数間に特定の関係が確立されます。

#三、データマイニング手法

##1.ニューラルネットワーク法

ニューラルネットワークは、その優れた堅牢性、自己組織化適応性、並列処理、分散ストレージ、高い耐障害性のために、近年ますます注目を集めています。

##2.遺伝的アルゴリズム

遺伝的アルゴリズムは、生物学的自然選択と遺伝的メカニズムに基づくランダム検索アルゴリズムであり、バイオニックグローバル最適化手法です。遺伝的アルゴリズムには、暗黙的な並列処理の特性があり、他のモデルとの組み合わせが容易であるため、データマイニングに適用できます。

##3.決定木法

デシジョンツリーは、予測モデルで一般的に使用されるアルゴリズムであり、大量のデータを分類し、そこから価値のある潜在的な情報を見つけることを目的としています。その主な利点は、簡単な記述と高速分類であり、特に大規模なデータ処理に適しています。

##4.ラフ集合法

ラフ集合理論は、不正確で不確実な知識を研究するための数学的ツールです。ラフセットメソッドにはいくつかの利点があります。追加情報を提供する必要がなく、入力情報の表現スペースが単純化される、アルゴリズムがシンプルで操作が簡単です。ラフセット処理の対象は、2次元のリレーションテーブルに似た情報テーブルです。

##5.正および負のメソッドをオーバーライドする

すべての肯定的な例を網羅し、すべての否定的な例を除外して、ルールを見つけるという考え方を使用しています。最初に、正のサンプルセットで任意のシードを選択し、負のサンプルセットで1つずつ比較します。フィールド値と互換性のあるセレクターは破棄されます。それ以外の場合は保持されます。この考えによれば、すべての肯定的な例は回覧され、肯定的な例の規則（セレクターの組み合わせ）が得られます。

##6.統計分析法

データベースのフィールドアイテム間には、機能的な関係と関連する関係の2種類の関係があり、統計分析を使用してそれらを分析できます、つまり、データベースの情報は統計原則を使用して分析されます。一般的な統計、回帰分析、相関分析、差分分析などを実行できます。

##7.ファジィ集合法

すなわち、ファジー判定、ファジー意思決定、ファジーパターン認識、およびファジークラスタリング分析は、ファジー集合理論を使用した実用的な問題に使用されます。システムの複雑さが高ければ高いほど、あいまいさがより強くなります一般的なファジーセット理論では、あいまいさのあいまいさを記述するためにメンバーシップを使用します。
#zoom でミュート状態を一時的に解除/切り替えするにはスペースキーを押すだけで良いかもね？ (Macアプリ)

Macのアプリだと、初期設定で、スペースを押した間だけミュート解除できるみたいだ。これは良いね。

# Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/2854








<!-- Update From Qiita API -->

# チャットメンバー募集


何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。

https://line.me/ti/g2/eEPltQ6Tzh3pYAZV8JXKZqc7PJ6L0rpm573dcQ





# Twitter


https://twitter.com/YumaInaura


<!-- Update From Qiita API -->
Selection Sort

# Pythonで「選択ソート（Selection Sort）」
## はじめに

ここでは[「プログラミングコンテスト攻略のためのアルゴリズムとデータ構造」][1]の中で取り上げられている[「AOJ (Aizu Online Judge」)][2]の問題を自分で解いた際に学んだことや、こう考えれば分かりやすいと感じたことなどを自分への整理も兼ねてまとめています。
このテキストはC++で書かれているので、私のようにpythonで勉強をされている初学者の方の参考になれば幸いです。また私自身も初学者ゆえ、至らない点が多々あると思いますので、ご指摘・ご助言頂ければ喜びます。よろしくお願いします。

## 問題詳細

[ALDS 1_2_B: Selection Sort][3]
選択ソートで昇順に並べ替える問題です。
問題詳細は上記リンクをご参考ください
## 考え方
・以下の処理をN-1回繰り返す
　　1. 未ソート部分から最小の要素の位置 minj を特定する
　　2. minj の位置にある要素と未ソート部分の先頭要素を交換する

## pythonコード
```python
def SelectionSort(A, N):
    cnt=0
    for i in range(N):
        minj = i       # A[i]が未ソート部分の先頭
        for j in range(i, N):
            if A[minj] > A[j]:
                minj = j  # 未ソート部分の最小要素の位置をminjに入れる
        if minj != i:
            cnt +=1
        A[i], A[minj] = A[minj], A[i] # 未ソート部分の最小要素を未ソート部分の先頭と入れ替える
    return A, cnt

N = int(input())
A = list(map(int, input().split()))

ans, cnt = SelectionSort(A, N)

print(*A)
print(cnt)
```````
※指数表記はどうすればよいのでしょうか、ご教示いただければ幸いです。
## ポイント
・未ソート部分の最小値を未ソート部分の先頭であるA[i]に入れていくことで、未ソート部分が狭まっていきます。

・**計算量はO(N^2)**
（未ソートの部分の最小値を見つけるためにN-1回、N-2回、...、1回の比較演算を行います。従って合計の比較演算の回数は(N^2-N)/2）となるので、計算量はN^2に比例します）

## まとめ
以上となります。間違いや改善点などございましたら、よろしくお願いいたします。


[1]:https://book.mynavi.jp/ec/products/detail/id=35408
[2]:https://onlinejudge.u-aizu.ac.jp/home
[3]:https://onlinejudge.u-aizu.ac.jp/courses/lesson/1/ALDS1/all/ALDS1_2_B
ls -lをすると、ls -lhになる、エイリアス的な関数を.bashrcに記述する

# はじめに

**ls -l**で表示されるファイルの容量が、バイト単位なので、パッと見て非常に分かり難い。自動で、KB、MB、GB表示に変換してくれるように、エイリアスを設定したいのだが、オプション付きでエイリアスを設定する事ができないため、**.bashrc**に関数を作って対応する事にした。

# 環境
Ubuntu 16.04.5 LTS

# 手順

ホームに移動する。

```shell
cd ~/
```

.bashrcを開く。

```shell
vi .bashrc
```

**Shift + g**で、一番下に移動して、下記のls関数を記述する。

```bash
function ls () {
  if [[ "$@" =~ ^--color=auto.*l.*$ ]]; then
    command ls "$@" -h
  else
    command ls "$@"
  fi
}
```

.bashrcを実行して、変更内容を有効にする。

```shell
source .bashrc
```

下記のどのコマンドを実行しても単位の表示がOKになっている事を確認する。
**ls**コマンドはそのまま使えます。

```shell
ls -l
ls -la
ls -al
```
# 解説

**$@**には、lsコマンドの**引数**が入ってきます。.bashrcファイルの上の方を検索すると、**alias ls='ls --color=auto'**の記述があるため、**ls -l**をすると、$@の中身は、**--color=auto -l**で拾われる事になります。オプションが、-l or -la or -alに対応できるよう、正規表現でマッチングさせます。マッチングすれば、最後に、**-h**のオプションを追加しています。

.bashrcの中から、**alias ls**を検索する。

```shell
$grep "alias ls" > .bashrc
alias ls='ls --color=auto'
```

# 参考
https://tutorialmore.com/questions-603168.htm
Raspberry Pi の Python デフォルトバージョンを 2系 から 3系 に切り替える

#環境
投稿時点での最新の [NOOBS](https://www.raspberrypi.org/downloads/noobs/) をインストール済みです。

```bash
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
```

#切替手順
##インストール済 Python バージョン確認

`python` コマンドで確認すると、2系のPython がデフォルトになっています。

```bash
$ python -V
Python 2.7.16
```

ちなみに 3.7系の Python もインストール済みです。

```bash
$ python3 -V
Python 3.7.3
```

## alternatives を確認
皆さんお馴染みの `update-alternatives` コマンドで、Python がバージョン管理されているか確認します。
もちろんこの時点で Python は登録されていません。

```bash
$ sudo update-alternatives --list python
update-alternatives: エラー: python の alternatives がありません
```

## alternatives に登録

`update-alternatives` コマンドで、Python の 2系（2.7）と3系（3.7）を登録します。

```bash
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
update-alternatives: /usr/bin/python (python) を提供するために自動モードで /usr/bin/python2.7 を使います
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.7 2
update-alternatives: /usr/bin/python (python) を提供するために自動モードで /usr/bin/python3.7 を使います
```

## alternatives を確認

以上の手順で alternative による Python のバージョン管理ができるようになります。

また `update-alternatives --config` コマンドにより、デフォルトの Python バージョンを確認することができます。
もしこの時点で3系の Python がデフォルトになっていないようなら、選択肢の番号を入力します。（空エンターならそのまま終了）

```bash
$ sudo update-alternatives --list python
/usr/bin/python2.7
/usr/bin/python3.7
$ sudo update-alternatives --config python
alternative python (/usr/bin/python を提供) には 2 個の選択肢があります。

  選択肢    パス              優先度  状態
------------------------------------------------------------
* 0            /usr/bin/python3.7   2         自動モード
  1            /usr/bin/python2.7   1         手動モード
  2            /usr/bin/python3.7   2         手動モード

現在の選択 [*] を保持するには <Enter>、さもなければ選択肢の番号のキーを押してください:
```

念の為、`python` コマンドで 3系に切り替わっているか確認します。

```bash
$ python -V
Python 3.7.3
```