OmniAICreator/Qiita-1.07M huggingface dataset:
標準 Pascal 範囲内での Delphi 入門

# はじめに
標準 Pascal (Standard Pascal) で解説されている範囲での Delphi はどうなっているのかを、ふと知りたくなりました。この記事は **「Delphi のコンソールアプリケーションで uses 句を記述しない場合、標準 Pascal と何が違うのか？」** を調べたものです。

端的に言えばオブジェクト指向拡張部分を除いた Object Pascal (Delphi) の解説です。

# 目次
ここがメインページです。

 - [0. はじめに](https://qiita.com/ht_deko/items/afb3c008a83a20792169)
 - [1. 記法: トークンと区切り文字](https://qiita.com/ht_deko/items/ce1f56017fb4fcf0302a)
 - [2. データの概念: 単純型](https://qiita.com/ht_deko/items/5c04bb2b42947e29d94b)
 - [3. プログラムヘッダと宣言部](https://qiita.com/ht_deko/items/2d5996cbfc82d734b247)
 - [4. 動作の概念](https://qiita.com/ht_deko/items/05af01a81f7c3bb5eeb4)
 - [5. 列挙型と部分範囲型](https://qiita.com/ht_deko/items/335e59857cc78aea951a)
 - [6. 構造化型の概要と配列型](https://qiita.com/ht_deko/items/eedda6d38b6d0887d4ac)
 - [7. レコード型](https://qiita.com/ht_deko/items/1d2c85768febc95009bf)
 - [8. 集合型](https://qiita.com/ht_deko/items/50bac0de384d66208944)
 - [9. ファイル型](https://qiita.com/ht_deko/items/986fa01c9e6cfc3fd673)
 - [10. ポインタ型](https://qiita.com/ht_deko/items/745ad4a792d277d33831)
 - [11. 手続きと関数](https://qiita.com/ht_deko/items/b93ac03bfee002f17137)
 - [12. テキストファイルの入出力](https://qiita.com/ht_deko/items/391d6c1a53c7aaa3416f)
 - [付録](https://qiita.com/ht_deko/items/15b27e00fac9d723d9f0)
 - [用語集](https://qiita.com/ht_deko/items/56e4910d7e00d9bcc5b2)

※ 章の構成は [『J&W 第 4 版』](https://qiita.com/ht_deko/items/65e84a12e0203da77337#pascal-%E5%8E%9F%E6%9B%B8%E7%AC%AC-4-%E7%89%88) に準拠しています。
※ 用語は『J&W』邦訳版に準拠しています。
※ 標準 Pascal に存在しない用語は Delphi / Turbo Pascal のマニュアルに準じています。

# おわりに
Delphi って便利ですね。[:sushi:](https://qiita.com/ht_deko/items/46fcdbb11cdc58872160)

**See also:**

 - [標準 Pascal の規格票と解説書を読んでみる (Qiita)](https://qiita.com/ht_deko/items/091661d6fa3d72700a56)
 - [Delphi における Pascal の処理系定義](https://qiita.com/ht_deko/items/2b7cab95ffc60de10c25)
 - [Delphi と標準 Pascal の比較 (標準 Pascal コードを Delphi に移植する際の注意点) (Qiita)](https://qiita.com/ht_deko/items/a13d6459227e787422ae)
 - [Pascal へのオブジェクト指向拡張の歴史と Delphi (Qiita)](https://qiita.com/ht_deko/items/ff2d90c9174290583377)
PHPのCarbonで特定の日付の曜日を日本語で表示する

# PHPのCarbonで特定の日付の曜日を日本語で表示する

```php
// ローカルを日本語設定にする
setlocale(LC_ALL, 'ja_JP.UTF-8');
$dayOfWeek = Carbon::parse('2019-03-07')->formatLocalized('%a');

echo $dayOfWeek // 木
```

### 参考:
[Carbon](https://carbon.nesbot.com/docs/)
[omoonさんブログ](http://blog.omoon.org/20160309/1075)

### お願い

これよりいい方法があれば教えていただけると助かります！
普段使っているMacアプリまとめ 2019

5年前のもの
https://qiita.com/yuch_i/items/470685b945578afabbb9

# 概要

* あまりいろいろ使わなくなった
* JetBrains TOOLBOX最強!
* Docker便利!

# 開発系

## JetBrains TOOLBOX

諸々。WebStorm/PyCharm/GoLand/IntelliJ/DataGridがメイン。
RubyMine/PhpStormも時々使う。

JS/TSは一時Visual Studio Codeに浮気してたがWebStormに戻ってきた。

一括アップデート、設定の同期化、便利。

## Iterm2

開発中はIDEと行ったり来たり。
IDE付属のターミナルは基本使っていない。

https://www.iterm2.com

## Xcode

Swift開発用。
最近あまり出番がない。

## Karabiner Elements

US配列なので必須。
Ctrl+7で日本語、Ctrl+8で英語にするように設定している。

https://pqrs.org/osx/karabiner/

## Tower

gitクライアント。
commitは差分が見やすいGUIでやりたい。
ずっと使ってる。

https://www.git-tower.com/mac

## Notes (メモ)

タスク・メモのフロー情報管理はMac標準のメモに落ち着いた感じ。
ストック情報としたい場合はGoogle Docsに階層化して保存している。

TODO管理はThings -> Omni Focus -> Notes
テキストエディタもmi -> Cot Editor -> Notes

## Safari, Chrome

通常利用はSafari。
開発用はChrome。

## Docker Desktop

開発環境はなるべくコンテナ化しようとしている途中。
circleciコマンド経由で使っている場合もある。

https://www.docker.com/products/docker-desktop

## VirtualBox + vagrant

Windows上での動作確認など、VMが必要な場合に使う。

# CLI

## zsh

Macではシェルはzshを使っている。

## ansible

個人環境の設定ファイルやhomebrewパッケージはansibleで管理している。

# Other

他はコミュニケーション系でSlack, Skype入れてるくらい。
Rust: Futureのざっくりとした説明(0.3)

自分の理解の確認だから間違ってるかも。

## タスクと`Futute`
タスクは一つのオートマトンで、`Future`はその部分。

`Future`は計算の状態、つまり「どこまで計算を進めたか」という概念を取り扱うことを示すトレイトだ。
乱暴にいえば`await`する単位が計算の状態になる。
例えば、以下の例でいえば「(0)初期状態」「(1)`foo`待ち」「(2)`bar`待ち」「(3)計算終わり」など。

```rust
async {
// (0)
    let x = ... ;
    let y = ... ;
// (1)
    let f = await!(foo(x, y)); 
// (2)
    let b = await!(bar(f));
    
    Ok(b)
// (3)
}
```

図にするとこう。
![maton.png](https://qiita-image-store.s3.amazonaws.com/0/231765/53cd2a2a-9420-f4d5-9166-c9a08db02d7a.png)

`Future`は再帰的な構造になっている。図中(1)や(2)の中身もまた`Future`で、分岐とかを考えなければ、全て展開すると一本の長いチェーンになる。このチェーンがタスク。`async`/`await`がオートマトンを繋げていく。

いわゆるExecutorは、タスクに対してポーリングを行い、オートマトンを進められるところまで進める。
進められないところというのは、再帰を辿って行き着いた先にあるIOの部分などだ。IOは本質的に低速なため、そこで計算を止めざるをえない。
このとき、IOを待ってExecutorがブロックしないよう、`Future`ではブロックを別スレッドに押し付けるように書いておく。そして、計算の準備ができるまで、Executorには計算結果の代わりに`Pending`を返しておく。
Executorは`Pending`を受け取ると、一旦そのタスクの処理を中断し、別のタスクのポーリングを行う。次にこのタスクをポーリングするときは前回の続きから始めて、同様に計算を進められるところまで進め、また中断する。これをタスクの完了まで繰り返す。

そもそも計算機自体がオートマトンで、プログラムカウンタやメモリ上の変数などの形で計算状態が表されている。
`Future`はそれをもっと粗い単位で表現するものだという理解。

## ライフタイム
`Spawn`に(スレッドをブロックせず)ぶん投げることができるのは`'static`な`Future`だけだ。このタスクはいつ実行されるか分からないから、当然`'static`でないと困る。
ただし、そのタスクの中で、タスク自身が所有権を持つものの参照を作り、その参照をタスク内で取り回す分には全くの合法になる。
これがいわゆるnon-`'static`な`Future`。

Webフレームワークでは、リクエストにつき一つのタスクを生成し、それを`Spawn`に投げてまた次のリクエストを待つ処理が必ずどこかに出来るはず。
このとき、アプリケーション全体の状態(コネクションプールとか)は`Arc`で包んでリクエスト毎にクローンされ、タスク全体としては`'static`にする。
そして、リクエストの処理中にはクローンされたものや処理中に生成したオブジェクトの参照だけを取り回したいはずだ。このときnon-`'static`な`Future`が役立つ。

## Waker
無駄なポーリングを防ぐために、ポーリングしていいことをExecutorに通知するための仕組み。

jsの`Promise`に当てはめて考えるとわかりやすい。
`Promise`はコンストラクタで`resolve`と`reject`を貰う。
計算が完了したらこのいずれかを呼ぶ。これらはコールバックの中で呼ばれるだろう。

```javascript
new Promise((resolve, reject) => {
    setTimeout(() => resolve("OK!"), 1)
})
```

Rustの`Waker`は、いくつか(重大な)違いがあるものの、雰囲気としてはこれに近い。
`Future`トレイトを実装する時必須になるメソッドの`poll`は、引数に`&Waker`を貰う。
`waker.wake()`を呼ぶことで、Executorにこのタスクをポーリングしていいことを通知する。

```rust
fn poll(mut self: Pin<&mut Self>, waker: &Waker) -> Poll<Self::Output> {
    if (*self).is_progress {
        if self.flag.load(Ordering::Relaxed) {
            return Poll::Ready(String::from("OK!"));
        } else {
            return Poll::Pending;
        }
    }

    (*self).is_progress = true;
    let flag = Arc::clone(&self.flag);
    let waker = waker.clone();

    thread::spawn(move || {
        thread::sleep(std::time::Duration::from_millis(1));
        flag.store(true, Ordering::Relaxed);
        waker.wake();
    });

    Poll::Pending
}
```

ゴツいのは許して。
ネイティブなマルチスレッドを触り、スレッド間で何らかの通信を行う以上、`Future`の奥の方はどうしてもゴツくなる。どのタイミングでポーリングされてもいいように実装しておく必要があるため、その分の分岐も要る。

そのかわり、これを使うときには`async`/`await`で簡単。

```rust
async {
    let ok = await!(Fuga::new());
    println!("{}", ok); // => OK!
}
```

また、内部に`Future`を持つ別の`Future`を実装するのもそんなに難しくない。下のは上の`async`ブロックと大体同じ。

```rust
impl Future for Hoge {
    type Output = ();

    fn poll(mut self: Pin<&mut Self>, waker: &Waker) -> Poll<Self::Output> {
        Future::poll(Pin::new(&mut self.fuga), waker).map(|ok| println!("{}", ok));
    }
}
```

力尽きたからここまで！
[入門] GoでAPIを書いて，k8sにデプロイするまで [随時更新]

# 概要
新しい技術を使ってみたいけど， **何がいいの？どう使うの？時間ないよ** と躊躇してしまうこともあると思います．
本記事では，自分が躓いたポイントも踏まえつつ題材を元にガシガシ書いていこうかなと思います．
自分自身も最近学び始めた技術ですので，入門として書かせていただきます！

# 構成
## Go編
- [**Go**とは](https://qiita.com/tozastation/items/029440f6471d3ab97b8c) 
- [Goで，**レイヤードアーキテクチャ**を書いてみる](https://qiita.com/tozastation/items/a69a102fdc3f62d566b4)
- Goで**gRPC**を使ってみる(お待ち下さい😓)
- Goの**テスト**を書こう(お待ち下さい😓)
 
## Docker編
- **Docker**とは(お待ち下さい😓)
- [Dockerfileの書き方](https://qiita.com/tozastation/items/ca19034433f30ea5baee)
- Dockerの使い方(お待ち下さい😓)

## Kubernetes(k8s)編
- **Kubernetes(k8s)**とは (お待ち下さい😓)
- [k8sにAPIサーバをデプロイ](https://qiita.com/tozastation/items/e4f77a96707b4e1fdf2d)
- [kubectlコマンド](https://qiita.com/tozastation/items/1ea437db7cfa2eea0965)
- ログの収集 (お待ち下さい😓)

## Istio on Kubernetes
- [Istioが作るサービスメッシュ~環境構築~](https://qiita.com/tozastation/items/e2f3029a8d7636da1fba)
- [Istioが作るサービスメッシュ~サンプルアプリのデプロイ~](https://qiita.com/tozastation/items/1f3c3f213b42e1689406)
最小構成の Airflow で DB を切り替える

## はじめに
- [最小構成の Airflow を GKE に deploy する](https://qiita.com/kysnm/items/b48375bb39c90bd2e7c2) を LocalExecutor を利用するため DB を MySQL に変更します

- kubernetes のドキュメントにおいて v1.10 を参照しているのは Google Kubernetes Engine で利用しているバージョンと合わせています

## Deploy MySQL
- [公式ドキュメント](https://v1-10.docs.kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/#deploy-mysql) を参考に構築する

### ハマりどころ
- API Reference で目的のものが見つけづらく [komposer](https://v1-10.docs.kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/) を利用して docker-compose の YAML を変換し参考にした
    - ただし komposer は v2.1 が対応していなかったり、一部の記述が対応していなかったので 2 に書き換えたり、コメントアウトして変換を行った

- GKE では PersistentVolume は基本的に不要だった
    - 上記公式ドキュメントの通り deploy する
    - Web 上で YAML タブを確認すると `error while creating mount source path '/mnt/data': mkdir /mnt/data: read-only file system` 
    - https://discuss.kubernetes.io/t/running-tutorial-mysql-example-gives-me-read-only-file-system-error/3197

        > It turns out that when running on GKE there is no need to explicitly create a volume. 

    - https://cloud.google.com/kubernetes-engine/docs/concepts/persistent-volumes#dynamic_provisioning

        > ほとんどの場合、PersistentVolume オブジェクトを直接構成したり Compute Engine 永続ディスクを作成したりする必要はありません。

- Lost+Found directory 問題
    - log に `--initialize specified but the data directory has files in it. Aborting.` が出力される
    - `/var/lib/mysql` directory に loast+found が含まれてしまうため
    - mysqld 起動時に `--ignore-db-dir=lost+found` を指定する
    - https://github.com/docker-library/mysql/issues/186 

## docker image の更新について
- kubernetes において docker image の pull policy は IfNotPresent です
- tag を変えずに image の更新をしたい場合 `imagePullPolicy： Always` を指定するといいようです
    - https://kubernetes.io/docs/concepts/containers/images/#updating-images
    - latest タグを使うのはどのバージョンを利用しているのかわからなくなる、ロールバックできないという点から非推奨

        - https://v1-10.docs.kubernetes.io/docs/concepts/configuration/overview/#container-images

            > You should avoid using the :latest tag when deploying containers in production, because this makes it hard to track which version of the image is running and hard to roll back.

## 実装
- https://github.com/kysnm/airflow-gke/pull/1
- https://github.com/kysnm/airflow-gke/pull/2
- https://github.com/kysnm/airflow-gke/pull/3
[基本情報技術者(FE)]磁気ディスクの構造(トラック,セクタ,シリンダ)

#はじめに
このページは、初心者エンジニアの僕が、基礎知識を養うために勉強したことを、共有する場です。
とりあえず、基本情報基礎の過去問を解きながら、勉強したことを解説していきます。
間違いや、ニュアンスが微妙なところもあるかもしれませんが、お気軽にご指摘を頂けると幸いです。

#今日の問題
```text:14年秋FE問22
1つのファイルは磁気ディスク上の連続した領域に記録されているのがよいといわれる。その理由のうち、適切なものはどれか。

1.　磁気ディスク上にデータの記録されていない部分がなくなり、全領域が利用できる。
2.　磁気ヘッドの無駄な動きが減るので、ディスク表面の摩耗が少なくなる。
3.　ファイルの管理情報を格納する領域が少なくなり、その分ユーザーが多く利用できる。
4.　連続してデータを読み取る場合、磁気ヘッドのシーク回数が少なくなるので、読み取り時間は短くなる。
```
```text:正解
4
「連続してデータを読み取る場合、磁気ヘッドのシーク回数が少なくなるので、読み取り時間は短くなる。」が正しい

【解説】
磁気ディスク上の連続した領域（1つのトラックや1つのシリンダなど）に記録されているデータを連続して読み取る場合は、
目的のデータがあるトラック上に磁気ヘッドを移動させる動作（シーク動作）の回数が少なくなるので、
シーク時間の分だけ読み取り時間が短くなるといえる。
```
[引用サイト](http://jibun.atmarkit.co.jp/scenter/ittrain/105_today_a4.html)
#解説
##磁気ディスクとは
ようするに、フロッピーディスクのような記録方法だそうです。懐かしい。
表面と裏面に、磁性物質を塗布したもの円盤状のものを1~数十枚配置したもの。それが、1枚のものをフロッピーディスク。
最近は、USBメモリやHDDの台頭で、利用度は減少しているらしい。

##トラック( = 輪切りしたバームクーヘンの生地)
磁気ディスクは、1~数十個に輪切りにされたバームクーヘンのようになっている。
また、それぞれのバームクーヘンは、生地が巻かれた構造になっているが、巻かれた生地の1枚1枚が「トラック」と呼ばれる。
（ちなみに、そのトラックをさらに分割したものをセクタと呼ばれ、磁気ディスク上で読み書きできる最小の単位。）
CDなどの音源でも、いまだにトラックと呼ばれているのは、これのことだったのかも。（予想）
[参考サイト](http://mt-net.vis.ne.jp/ADFE_mail/0562.htm)

##シリンダ( = 輪切りしたバームクーヘンの生地を縦にまとめたもの)
引き続きバームクーヘンに例えると、1回のデータアクセスでは、輪切りした1つのバームウーヘンの１つの生地に対してのみ行っているのではない。
つまり、上下の輪切りされた他のバームクーヘンの生地にも同時にアクセスしてるそうな。その同時にアクセスできる生地を縦にまとめたものを、シリンダと呼ぶ。
[参考サイト](http://mt-net.vis.ne.jp/ADFE_mail/0562.htm)

##大小関係はシリンダ＞トラック＞セクタ
過去問に出てたので、ついでに。
[参考サイト](http://mt-net.vis.ne.jp/ADFE_mail/0562.htm)

##磁気ヘッド
色々書いてましたが、磁気テープや磁気ディスクに接触させる磁性体の部分をいうみたい。
[参考サイト](https://kotobank.jp/word/%E7%A3%81%E6%B0%97%E3%83%98%E3%83%83%E3%83%89-4113)

##シーク回数
多分、シークする回数のこと。
>シークとは、捜索する、探し求める、得ようとする、～を求めて行く、向かう、～しようと努めるなどの意味を持つ英単語。ITの分野では、目的のものを探し出す、目的の場所を見つけて移動する（させる）、といった意味で用いられることが多い。

[引用サイト](http://e-words.jp/w/%E3%82%B7%E3%83%BC%E3%82%AF.html)

##その他　この問題から学べること
 - ディスク表面は摩耗しない

#最後に
引き続き、IT知識の基礎固めで学んだことを共有しています！
よろしくお願いします。
[入門] Goとは [随時更新予定]

![image.png](https://qiita-image-store.s3.amazonaws.com/0/192927/653240df-abf5-3d28-79bd-7b118beb7ab8.png)

# Goについて
プログラミング言語Goの情報サイトである[golang.jp](http://golang.jp/about_go)さんに書いています．Googleさんが発表したオープンソースのプログラミング言語になります．
自分が特に抜粋するならば，以下の二点になります．

## シンプルさ
大規模なシステムにおいて，属人性（個の技術スキル）による複雑な実装は，運用やメンテナンスを難しくさせます．
Goには，継承・Generics・例外が実装されていません([参考記事](https://sklab.net/2017/05/24/go%E8%A8%80%E8%AA%9E%E3%82%92%E5%8B%89%E5%BC%B7%E3%81%97%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%8B%E3%82%89%E4%BB%95%E4%BA%8B%E3%81%AE%E5%90%88%E9%96%93%E3%81%AB%E8%AA%BF%E3%81%B9/))．また，ループ処理を例にあげると，他の言語だとfor・ while・do/whileなど選択肢がありますが，Goでは，forしか実装されていません．このように，**プログラマーによる表現の違い**を抑制することができます．
このことから，**初学者でも取っつきやすい**と思っています．自分を例に出すと，**APIサーバを作ろう**となった時に，Java, Scala->Pythonなどを学んできましたが， Goの学習コストの方が低いですし，モチベーションが上がりました．システムを開発している方達でも，**多人数で精度やばらつきを維持するプログラムを生産していくのは難しい**と思います（ペアプロやモブプロもありますが）．

## 高速さ
開発において，速度は重要です．
ここでいう開発速度は，プログラミング言語のパフォーマンスではなく，チームとしての開発速度になります．
特にプログラムのビルド時間は特に重要であると考えています．実装したシステムを開発環境やステージング環境で動かしたいことを考えてみて下さい．経験した方もいると思いますが，規模の大きなシステムになる程ビルド時間はものすごい量になります．
下記は，C#とGoで同様の処理のプログラムを書き，ビルドを行なった結果です．
> C#ももちろん好きです

### 結果
C#の2分の1ほどの速度で実現できています．
- C#: 約447秒
- Go: 約200秒

## まとめ
プログラミングを初めて3年ほど経ち，チーム開発を何度か経験してみてGoはいいなと思ったので本記事を書かせていただきました．興味のある方はぜひ試してみて下さい！
機械学習の構成について

機械学習の構成についての覚書です
各環境のメリット・デメリットなど

#環境はローカルか、クラウドか

##ローカル
初期投資が大きく、ランニングコストが安い
必須なのはグラボと環境構築を諦めない根性
その分制約がほぼ無いので、可能ならローカルで環境構築仕切ってしまいたい
anacondaを使う方法がかなりオススメ

###必須
必須なのはグラボ。
とりあえず動かしたいならGTX750辺りが安くて良い
性能はクラウドと大して変わらない
できればGTX1060ぐらいは欲しいけど、ジャンクに手を出すのはやめた方が良い（一敗）
中古で店舗から買うのが無難

###あれば良いもの
SSD。無いということは無いと思う。1TBぐらいのを買ってしまえば容量を気にしなくて済む

###割となんでもいい
CPU　core第二世代以降
メモリ　8GBぐらい
OS　出来れば最新
python　3.x。2.7はもうおしまい

###やること
nVidiaに登録してCUDA、cudnnを入手
sckitlearn全盛期は依存地獄だったが、最近はtensolflowとkerasを入れると大体動くのでそこまで大変でも無い

##クラウド
googleのColaboratoryなら無料
https://colab.research.google.com/
最初からほぼ全部揃っている。CUDAも入っていて何の知識も依存地獄もない

amazonのAWSでも良いが有料。時間課金制

###TPU
TPUが使えてアホみたいに早い
しかしGPUのソースコードにはかなり手を加える必要がある
tensorflowのバージョンが上がればその辺り自動的に対応してくれるんじゃないかな、もう少し待とう

TPUは現状、CPU扱いになる

```py
from tensorflow.python.client import device_lib
print(device_lib.list_local_devices())
```

```text:実行結果
[name: "/device:CPU:0"
device_type: "CPU"
memory_limit: 268435456
locality {
}
incarnation: 14364440645520663771
, name: "/device:XLA_CPU:0"
device_type: "XLA_CPU"
memory_limit: 17179869184
locality {
}
incarnation: 5324631014525462955
physical_device_desc: "device: XLA_CPU device"
]
```

###Colaboratoryについて
12時間ごとにリセットがかかるのが最大のネック
回避するためには、学習結果を12時間以内の範囲でgoogleドライブに逃がすなどの対処が必要

GPUはTESLAのK80
K80は2012年リリースのハイエンドGPU
しかし、7年も経つので、そろそろ厳しい
また、K80は内部で2つのチップを持っているがその内の一つしか使えない
性能的にはざっくりとGTX960～GTX970辺り

#まとめ
どれも一長一短
なんとなく試したいだけならColaboratoryが良い
ガッツリやりたい場合は自前での環境構築をオススメ
【C#】【自分用メモ】List内の重複チェック

【目標】
Listで重複チェックをし、被っているものを表示させてくれる仕組みを作りたい。

【その1】
順当にFor文で回す。

```Hoge.cs
using System;

class Hoge
{
  static void Main()
  {
    // リスト
    string[] berries = new string[]{"blackberry", "blueberry", "strawberry", "cranberry", "raspberry", "blueberry"};

    for (int i = 0; i < berries.Count - 1; i++)
    {
      for (int j = i + 1; j < berries.Count; j++)
      {
        if (berries[i].Equals(berries[j]))
        {
           Console.WriteLine("{0}は重複しています。", berries[j]);
           break;
        }
      }
    }

  }
}
```
まぁなんとネストが深いことやら…。

【その2】
そこでHashSetの出番です。
[こちら](https://pknight.hatenablog.com/entry/20130326/1364310124)を参照にさせてもらいました。

```Hoge.cs
using System;
using System.Collections.Generic;

class Hoge
{
  static void Main()
  {
    // リスト
    string[] berries = new string[]{"blackberry", "blueberry", "strawberry", "cranberry", "raspberry", "blueberry"};

    var hashset = new HashSet<string>();
    foreach(var berry in berries)
    {
      if (hashset.Add(berry) == false)
      {
        Console.WriteLine("{0}は重複しています。", berry);
        break;
      }
    }

  }
}
```

以上、備忘録でした。
Access/SQL CDate関数/指定した値を日付に変換する

##CDate関数/指定した値を日付に変換する

シリアル値などの数値を日付に変換する
CDate(カラム)

```SQL:qiita.rb
SELECT IIf(([日付カラム1])='',Null,CDate(([日付カラム1]))) As Expr1, 

```
Access/SQL ＩＮＴ/日付データの小数点を切り捨てる

##ＩＮＴ/日付データの小数点を切り捨てる

日付データの小数点（時間の部分）を切り捨て日付のみにする
INT(カラム)

```SQL:qiita.rb
SELECT カラム１, IIf(([日付カラム1])='',Null,CDate(([日付カラム1]))) As Expr1, IIf(([日付カラム2])='',Null,CDate(INT([日付カラム2]))) As Expr2

```
expo32にbare-minimumテンプレートが追加された

![alt](https://user-images.githubusercontent.com/26253721/39765058-e8d0eae4-531b-11e8-9305-4c852f269517.png)

expo32になってから、プロジェクト作成時にbare-minimumテンプレートが選択出来るようになった。

bare-minimumテンプレートとは最初からejectされているテンプレートだ。
expoコマンドが一切使えなくなる代わりに、ios, androidフォルダが作成され、nativeコードを扱えるようになる。

もう素のreact-native-cliを使わず、expo-cliのみで完結できる時代も近いのだろうか

試してみたい方は

```
npm i -g expo-cli
expo init project
```
を実行すると、以下のように、テンプレート選択肢にbara-mimimumが現れる。

Blank
Tab
Bara-minimum ！！！

Bare-minimumを選択すると、iosフォルダと、androidフォルダを含んだreact nativeプロジェクトが生成される。

Expoがどんどん便利になっていく。
嬉しい〜〜
Access/SQL SELECT結果でINSERTする

##Access/SQL SELECT結果でINSERTする


```vb:qiita.rb
Dim db As DAO.Database
Dim rs As DAO.Recordset
Set db = CurrentDb

Dim strSQL As String
    
strSQL = "INSERT INTO テーブル1  (カラム1, カラム2, カラム3) "
strSQL = strSQL & "SELECT カラムA,カラムB,カラムC "
strSQL = strSQL & "FROM テーブル2 WHERE Not カラムA Is Null"

Debug.Print strSQL
db.Execute strSQL

```
Laravel でもCRUD を bake したい CakePHPユーザーのための infyom

CakePHPからLaravelに移行すると ```cake.php bake``` に類するものが欲しくなると思います。そういうときは infyom がおすすめです。

[InfyOm Laravel Generator : Laravel Scaffold, CRUD, API Generator](http://labs.infyom.com/laravelgenerator/)

この infyom、Webでの編集画面の生成は、CakePHP の bake にちょっと劣るかもしれませんが、APIの生成、テストコードの生成などもでき、十分に使えます。

# 使い方

## Laravelの環境構築

まずは Laravel の環境を構築しておきます。

[インストール 5.8 Laravel](https://readouble.com/laravel/5.8/ja/installation.html)

設定は、データベースに接続できるだけで大丈夫。```.env``` の DB_* の項目をみればだいたいわかります。

## infyomのインストール、設定

その後パッケージをインストール。

composer.json に追記。5.8.x-dev, 5.8.0 のか所は利用している Laravel のバージョンに合わせます。

```json
"require": {
    "infyomlabs/laravel-generator": "5.8.x-dev",
    "laravelcollective/html": "^5.8.0",
    "infyomlabs/adminlte-templates": "5.8.x-dev",
```

```bash
# インストール
composer update
```

config/app.php の２か所に追記

```php
    'providers' => [
        // ...略
        Collective\Html\HtmlServiceProvider::class,
        Laracasts\Flash\FlashServiceProvider::class,
        Prettus\Repository\Providers\RepositoryServiceProvider::class,
        \InfyOm\Generator\InfyOmGeneratorServiceProvider::class,
        \InfyOm\AdminLTETemplates\AdminLTETemplatesServiceProvider::class,
    ],
```

```php
    'aliases' => [
        // ...略
        'Form'      => Collective\Html\FormFacade::class,
        'Html'      => Collective\Html\HtmlFacade::class,
        'Flash'     => Laracasts\Flash\Flash::class,
    ],
```

その後、設定ファイルや infyom 関連ファイルを展開。

```ｂａｓｈ
php artisan vendor:publish --all
php artisan infyom:publish
php artisan infyom.publish:layout
```

## テーブルの準備と画面の作成

とりあえず準備されているマイグレーションファイルから users テーブルを作成します。

```bash
php artisan migrate
```

## CRUDの作り方

``php cake.php bake all [Model]``的な使い方、uses テーブルのCRUDを作る場合。

```bash
php artisan infyom:scaffold User --fromTable --tableName=users --paginate=25
```

書き方は

```bash
php artisan infyom:scaffold 生成するモデル名 --fromTable --tableName=元となるテーブル名
```

という形。 もし /admin 以下に配置したい場合は ```--prefix=admin``` をつけます。

### 自動生成されたモデルをちょっと修正

生成されたコードは softDelete が有効になっていますが、テーブルにはカラムがないので、コメントアウトします。

app/Models/User.php 

```php
    //use SoftDeletes;
```

また、IDが必須になっているのでそれをコメントアウトし無効にします。

```php
    public static $rules = [
        // 'id' => 'required',
```


### コマンド実行時にこのようなエラーが出たら

```
   Symfony\Component\Debug\Exception\FatalThrowableError  : Class 'Doctrine\DBAL\Driver\PDOMySql\Driver' not found
```

以下のコマンドを実行後、もう一度  ```php artisan infyom:scaffold ...``` を実行してください。

```bash
composer require doctrine/dbal
```

## 動作確認

サーバーを起動して

```bash
php artisan serve
```

<http://127.0.0.1:8000/users>

を開きます。

生成される画面はこんな感じ。

<div style="display:flex">
<img width="250" alt="1.png" src="https://qiita-image-store.s3.amazonaws.com/0/8961/19470ce2-0bdd-f394-12ef-98d14f0a3cac.png">
<img width="250" alt="2.png" src="https://qiita-image-store.s3.amazonaws.com/0/8961/7fb5bd2d-82f9-6ff4-be60-39f1d3afcaa6.png">
<img width="250" alt="3.png" src="https://qiita-image-store.s3.amazonaws.com/0/8961/49d4c813-853a-ef56-1481-a6fa2380aec3.png">
</div>
AWS Powershell TagSpecificationパラメータの書き方

#はじめに
公式ドキュメントにはTagSpecificationの書き方が載っていなくて困った。
ググっても出てこないし。

せっかく同時にタグ付与できるのだから作成後にNew-EC2Tagで付けるのはちょっとイケてないですよね

#以下サンプル

書き方はどのコマンドレットでも同じで、
Tagを付けるコマンドレットによってResourceTypeを適宜変更する必要があります。

複数行版を併記しているのは「こういう構造になっているのですよ」ということをわかってもらい、
ワンライナーを書き換えたけどエラー出た。という悲しい事件を減らすためです。

##New-EC2VolumeでTagSpecification
###複数行版
```Powershell
$TagSpecification = @{
  ResourceType = "Volume";
  Tags         = @(
    @{Key = "hogehoge"; value = "foo"},
    @{Key = "piyopiyo"; Value = "bar"}
  );
}
New-EC2Volume -SnapshotId "snap-xxxxxxxxxxxxxxxxx" -AvailabilityZone "us-east-1f" -TagSpecification $TagSpecification
```

###ワンライナー
```Powershell
New-EC2Volume -SnapshotId "snap-xxxxxxxxxxxxxxxxx" -AvailabilityZone "us-east-1f" -TagSpecification @{ResourceType = "Volume"; Tags = @(@{Key = "hogehoge"; value = "foo"}, @{Key = "piyopiyo"; Value = "bar"}); }
```

##New-EC2SnapshotでTagSpecification

###複数行版
```Powershell
$TagSpecification = @{
  ResourceType = "Snapshot";
  Tags         = @(
    @{Key = "hogehoge"; value = "foo"},
    @{Key = "piyopiyo"; Value = "bar"}
  );
}
New-EC2Snapshot -VolumeId "vol-xxxxxxxxxxxxxxxxxx" -TagSpecification $TagSpecification
```

###ワンライナー
```Powershell
New-EC2Snapshot -VolumeId "vol-xxxxxxxxxxxxxxxxxx" -TagSpecification @{ResourceType = "Snapshot"; Tags = @(@{Key = "hogehoge"; value = "foo"}, @{Key = "piyopiyo"; Value = "bar"}); }
```

#使用可能なResourceTypeの一覧
このFields - Nameです。
https://docs.aws.amazon.com/sdkfornet/v3/apidocs/index.html?page=EC2/TEC2TagSpecification.html&tocid=Amazon_EC2_Model_TagSpecification
(メモ) Xdomain に laravel 5.7 をデプロイするとき.htaccessの修正が必要

* [Xdomain (無料プラン)](https://www.xfree.ne.jp/) の php 7.1 で動かしてみた。

## 修正点

* /blog/public/ 以外にアクセスされた時、 /blog/public/ にアクセスさせる方法。
    * 例) /blog/.env にアクセスされた時に /blog/public/ にアクセスさせる

```apache:./.htaccess
RewriteEngine On
# 相対ディレクトリ。今回は/blogという名前。
RewriteBase /blog

# /public/が含まれていない場合、RewriteRuleに従う
RewriteCond %{REQUEST_URI} !/public/.*
# RewriteCondでマッチした場合、RewriteBase/public にアクセスさせる。
RewriteRule ^ public 
</IfModule>
```

* 以下の修正をしないとLaravelの表示が出来ない。

```diff:./public/.htaccess
-    <IfModule mod_negotiation.c>
-        Options -MultiViews -Indexes
-    </IfModule>
+    #<IfModule mod_negotiation.c>
+    #    Options -MultiViews -Indexes
+    #</IfModule>
```

* http://サブドメイン.php.xdomain.jp/プロジェクト名/public/

にアクセスして表示されることを確認。
おかしい場合は以下のパーミッションを777にしてみる。

* storage
* bootstrap/cache

![スクリーンショット_2019-03-07_11-26-54.png](https://qiita-image-store.s3.amazonaws.com/0/25728/e541d129-554d-e045-97f1-7583380b9f50.png)

## 注意点

* http://xxxxxx.php.xdomain.jp/blog/.env

にアクセスすると表示されてしまう。
.htaccessでアクセスできないように制御が必要。


## 広告について

> (※)3ヶ月間、ファイルマネージャのご利用、もしくはFTPでの接続が行われない場合は、広告が表示されます。

この点は注意。


----

以下作業メモ

## FileManager

1ファイルで動く。編集にも対応。
これを使うとファイルやフォルダの削除が簡単に出来る。
※ 自分以外は使えないように適宜修正すること。

* https://github.com/diego95root/File-manager-php


### tar.gz解凍

* デプロイの時、ファイルが9000ファイル程とUPLOADに時間がかかるため、tar.gz圧縮し、xdomain上でtar.gz解凍すると早い。

```php
<?php
try {
    $phar = new PharData('src.tar.gz');
    $phar->extractTo('.', null, true); // すべてのファイルを展開し、上書きします
} catch (Exception $e) {
    // エラー処理
}
```

### (参考までに)zipファイル解凍

```php
<?php
$zipfile = 'src.zip';
$zip = new ZipArchive;
if ($zip->open($zipfile) === TRUE) {
    $zip->extractTo('.');
    $zip->close();
    echo 'success';
} else {
    echo 'some error';
}
```


----

* [インストール 5.7 Laravel](https://readouble.com/laravel/5.7/ja/installation.html)

### 事前準備

```sh
sudo apt install -y \
 php-zip php-mbstring php-xml php-sqlite3 php-mysql sqlite3
```

### laravelのインストール

```sh
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
composer global require "laravel/installer"
```

```sh:~/.bashrc
export PATH=$PATH:$HOME/.config/composer/vendor/bin
```

```
laravel new blog

cd blog
vi .env
```

```diff:.env
- DB_CONNECTION=mysql
+ DB_CONNECTION=sqlite
```

```
touch homestead
php artisan migrate
```

```php:config/app.php
'timezone' => 'Asia/Tokyo'
'locale' => 'ja'
```
Figma Missing Fontsの対処法


macのwebでfigmaを使っていて
Missing Fontsのエラーが出て日本語入力できなかった

<img width="341" alt="スクリーンショット 2019-03-07 11.04.48.png" src="https://qiita-image-store.s3.amazonaws.com/0/145645/1511318a-9a37-9b0e-2c52-b184b26cdbf3.png">

・Noto Sans CJK JPをダウンロードする

https://www.google.com/get/noto/#sans-jpan


・Font Book.appを立ち上げる
ダウンロードしたzipの中からoftファイルを全部選んでドラッグ&ドロップ
![スクリーンショット 2019-03-07 11.11.11.png](https://qiita-image-store.s3.amazonaws.com/0/145645/a54d8d6a-fe3f-a06c-d5f1-3e75ecdeedc5.png)

完了
AccessVBAでSQL文を実行する方法

```vb:qiita.rb
Dim db As DAO.Database
Dim rs As DAO.Recordset
Set db = CurrentDb

Dim strSQL As String

'//SQL文記載
strSQL = "SELECT*****"
strSQL = strSQL & "FROM****"

Debug.Print strSQL

'//SQL文実行
db.Execute strSQL

```
TypeScriptとTypeORMの組み合わせでSyntaxError: Unexpected token {

ちょいハマりした。

# コイツ。
```shell-session
(node:93711) UnhandledPromiseRejectionWarning: /Users/username/project/src/entity/SomeEntity.ts:1
(function (exports, require, module, __filename, __dirname) { import {
                                                                     ^

SyntaxError: Unexpected token {
    at new Script (vm.js:79:7)
    at createScript (vm.js:251:10)
    at Object.runInThisContext (vm.js:303:10)
    at Module._compile (internal/modules/cjs/loader.js:657:28)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
(node:93711) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:93711) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
```

こういうエラーがいちばん嫌い。

# 環境
typescript ^3.3.3333
typeorm ^0.2.14

# 経緯
typeormセットアップして、
それ用のEntityを作って、
tscして、
`node dist/index.js`

したら上記エラーが出た。

エラー内容的にはNodeに対応してない文法が存在しているって感じだけど、そもそもtsからjsにコンパイル済みだし、意味不明。

typescriptのコンフィグにもちゃんと下記は入れてる。

```json:tsconfig.json
"module": "commonjs",
"target": "es6",
```

意味わかんねーよバーカ！

# 結論
typeormのドキュメントが分かりづらい。

typeormを利用する際、下記のようなconfigがプロジェクトルートに必要になる。
(厳密に言うと必須ではない。コード内に書くこともできるので)

```json:ormconfig.json
{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "username": "root",
  "password": "hogerahogera",
  "database": "mogeramogera",
  "synchronize": true,
  "logging": false,
  "entities": [
     "src/entity/**/*.ts"
  ],
  "migrations": [
     "src/migration/**/*.ts"
  ],
  "subscribers": [
     "src/subscriber/**/*.ts"
  ]
}
```

で、entitiesプロパティがプロジェクト内のEntity(他で言うmodel。要はテーブルを表す)の場所を指す。

のだが、僕のようにコンパイルしてからコンパイル後のファイルをnodeで動かしてる人の場合、上記の設定のままだとコンパイル後のjsファイルから、コンパイル前のtsファイルであるentityを読みに行ってしまう。

https://stackoverflow.com/questions/50361948/syntaxerror-unexpected-token-import-typeorm-entity

そんなん知るかよって感じ。

まあ徹頭徹尾ドキュメントを読んでない僕が悪いっちゃ悪いのだが、もうちょっと書きようはあると思う。

一応それっぽいことは、ドキュメント内の[ここ](https://github.com/typeorm/typeorm#loading-all-entities-from-the-directory)に書いてあった。

修正後はこんな感じになります。

```json:ormconfig.json
{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "username": "root",
  "password": "hogerahogera",
  "database": "mogeramogera",
  "synchronize": true,
  "logging": false,
  "entities": [
     "dist/entity/**/*.js" <- ここが変わってる
  ],
  "migrations": [
     "src/migration/**/*.ts"
  ],
  "subscribers": [
     "src/subscriber/**/*.ts"
  ]
}
```

うまく動いた！

typescriptになれてる人ならハマらないのかな？

こういうconfig系で何度も躓くので、実践的なtsプロジェクトの作り方とか落ち着いたらまとめます。
日付のチェック（フォーマットと閏年）

## 忘れないように

```checkDate.ts
const checkDAte = (dateStr: string): string => {
  // リテラルの方が早いらしい
  // 2019-10-15のフォーマットの場合
  const reg_date = /^\d{4}-\d{1,2}-\d{1,2}$/.test(dateStr)
  if (!reg_date) {
    return 'invalid'
  }
  const parts = dateStr.split('-');
  const year = parseInt(parts[0], 10);
  const month = parseInt(parts[1], 10);
  const day = parseInt(parts[2], 10);
  const monthLength = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
  // 閏年を考慮
  if (year % 400 === 0 || (year % 100 !== 0 && year % 4 ===0)) {
    monthLength[1] = 29;
  }
  if (!(day > 0 && day <= monthLength[month - 1])) {
    return 'invalid'
  }
  return 'valid'
}
jestのexpect.anything()が効かなかった

jestでオブジェクトが同値でであることをテストする際、テスト対象のオブジェクトにnew Date()とかの値が含まれている場合、new Date()の値がいくつになるのかは当然わからないのでexpect.anything()を使うといいよ、という記事を見つけた。[参考](https://qiita.com/pirosikick/items/cb9419a1233e8f316b88)

でもこんな感じになってテストが通らない。
![スクリーンショット 2019-03-07 10.15.59.png](https://qiita-image-store.s3.amazonaws.com/0/131625/cc208cb2-eee4-8baf-f26d-145c507b71e2.png)


こうなってたのを

```
      expect(user).toEqual({
```

こうしたらテストが通った

```
      const userJSON = JSON.parse(JSON.stringify(user));

      expect(userJSON).toEqual({
```
AWS Lambda（Node.js）でGoogle Cloud Natural Language APIを使用してエラー"Failed to load gRPC"が発生したときの対応方法

# 環境／ライブラリ
- AWS Lambda（Node.js 8.10）
- [@google-cloud/language](https://www.npmjs.com/package/@google-cloud/language)

# 事象
AWS Lambda（Node.js）上の関数で、Google Cloud Natural Language APIを呼び出すとエラー"Failed to load gRPC"が発生する。

# エラーログ例
```
Error: Failed to load gRPC binary module because it was not installed for the current system
Expected directory: node-v57-linux-x64-glibc
Found: [node-v57-darwin-x64-unknown]
This problem can often be fixed by running "npm rebuild" on the current system
Original error: Cannot find module '/opt/nodejs/node_modules/grpc/src/node/extension_binary/node-v57-linux-x64-glibc/grpc_node.node'
at Object.<anonymous> (/opt/nodejs/node_modules/grpc/src/grpc_extension.js:53:17)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/opt/nodejs/node_modules/grpc/src/client_interceptors.js:144:12)
at Module._compile (module.js:652:30) code: 'MODULE_NOT_FOUND
```

# 対応方法
以下のコマンドでリビルドする。targetはNode.jsのバージョンに合わせる

```
npm rebuild grpc —target=8.1.0 --target_arch=x64 --target_platform=linux --target_libc=glibc
```

# 感想
こういうエラーが起きると、Pythonにすれば良かったと思う（逆もまた然り）

# 参照
- [aws lambdaで開発中に発生するエラーおよびつまづきポイントまとめ](https://qiita.com/t0w4/items/700edce7a14eec9efd76)
Durable Functionsで同一ストレージアカウントを複数アプリで共有するときの注意

## Durable Functions の注意点
Durable Functions を試している際にちょっとハマったので、共有します。
※経緯などは[自分のブログ](https://himanago.hatenablog.com/entry/2019/03/07/034607)に書きましたが、Qiitaにもシンプルに注意点だけ投稿しておきます。

Azure Functionsの目玉ともいえる拡張機能、Durable Functionsについては以下を参照ください。
[Azure Functions の 超イケてる Durable Functions を使ってみる](https://qiita.com/TsuyoshiUshio@github/items/3e8acb1b0388b6045fdb)


## 概要
Durable Functions では**同一のストレージアカウント内に同じ関数名の関数を作ると衝突することがある**ということです。
Durable Functionsではオーケストレーター関数やアクティビティ関数を呼び出し、関数間で情報をやり取りすることで複雑なフローを可能にしますが、複数の関数アプリで同一のストレージアカウントを使いまわすと、別アプリに同じ関数名の関数があると、別アプリの関数であるにもかかわらず衝突し、呼びたいほうの関数が呼べない、ということが起きてしまいます。

## なぜ衝突するのか
Durable Functionsを使ったFunction Appを作成すると、ストレージアカウント内に**「タスクハブ」**が作成されます。
これは論理的なコンテナーで、同一のタスクハブに属した関数同士が情報のやりとりを行うことができるようになります。
<img src="https://docs.microsoft.com/ja-jp/azure/azure-functions/durable/media/durable-functions-task-hubs/task-hubs-storage.png">
参考：[Durable Functions におけるタスク ハブ - Azure](https://docs.microsoft.com/ja-jp/azure/azure-functions/durable/durable-functions-task-hubs)

そして、Durable Functionsでは、オーケストレーター関数やアクティビティ関数のコールを、このように**関数名の文字列**で行います。

```cs
var instanceId = await starter.StartNewAsync("SampleFunc", input);
```


そして、Durable Functionsを使ったアプリを何も考えずそのまま作ると、すべてデフォルトのタスクハブ名`DurableFunctionsTaskHub`として作成されてしまいます。


ということで、必然的に**同一タスクハブ内に同名の関数が存在すれば衝突してしまう**というわけです。
手元で確認したところ、どうも競合する関数名のうち**古いほうが呼ばれてしまう**ようでした。

## 対処法
### ①：別のストレージアカウントを使う
別のストレージアカウントを使えば、タスクハブは別のものになるので、衝突しなくなります。

### ②：タスクハブ名を明示的に指定する
同一のストレージアカウントを使いたい場合は、タスクハブ名を明示的に指定すれば、その名前になってくれます。`host.json` に以下のように書けばOKです(Functions 2.xの場合)。

```JSON
{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub"
    }
  }
}
```

なお、「デフォルトのタスクハブ名がアプリ名から決まるようにしてほしい」というissueも出ているようです。
[Task hub name should default to the function app name · Issue #383 · Azure/azure-functions-durable-extension](https://github.com/Azure/azure-functions-durable-extension/issues/383)

## まとめ
Durable Functions の良さは、本来複雑な実装・管理が必要な処理も、通常のプログラミングを行うかのように記述できる点です。

しかし、通常のプログラミングではあたりまえの「アプリや名前空間、クラスが異なれば同一のメソッド名を用いてもよい」という常識は、Durable Functionsでは通用しません。
内部の動作を知っていれば当然の動きですが、特に複雑な処理を作る場合などは、裏側の管理の仕組みなども意識しながら使わないといけませんね（これはDurableに限らずどんな開発でも当てはまる話）。

~~逆に、別アプリでもタスクハブが同じなら関数間で情報をやりとりできる、ということです。
関数名の競合にさえ気を付ければ、ここはむしろメリットにもなりえますね。~~
↓とのコメントをいただいたので、ここはやらないほうがよさそうです。
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">多分ですけど複数のFunction AppでTaskHubを共有すること自体だめだと思うので記事の最後の部分はいらないかなぁって思います<br><br>Queueのメッセージを使って関数の動きとか色々してるはずなので、Queueが共有されると変な動きしそう</p>&mdash; かずき@スマブラはリンク (@okazuki) <a href="https://twitter.com/okazuki/status/1103817224802820096?ref_src=twsrc%5Etfw">2019年3月8日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
画像の拡張子やContent-Typeが違ってもブラウザには表示されるのか

結論: 実際のフォーマットと拡張子やContent-Typeが違っていても表示はされます。

# フォーマットと拡張子とContent-Type

例えばPNG画像は、ファイルの拡張子`.png`で保存して、`Content-Type`を`image/png`で配信するものとされています。

これらが「ちぐはぐ」だったらブラウザはどう解釈するのか実験してみました。

経験的には実際のフォーマットに従ってちゃんと表示されますが、裏付けになる資料があるといいなと思って結果を共有します。

この辺の挙動は[HTMLの勧告](https://www.w3.org/TR/html52/)に記述がありそうな気もしますがサクッと見つけられず(詳しい方教えてください！)。

# 実験用のページ

こんなページを用意しました。

https://www.ideamans.com/_experimental/image-format-ext-content-type/
<img width="858" alt="Image_Format___Extension___Content-Type_Test.png" src="https://qiita-image-store.s3.amazonaws.com/0/35178/0e3139b5-a457-706a-8373-f9a4890a7903.png">

JpegとPNGについて、実際の内部フォーマット、拡張子、`Content-Type`ヘッダのすべての組み合わせで画像を表示します。

正しい組み合わせの画像は背景色を緑、拡張子か`Content-Type`あるいはその両方が内部フォーマットと異なる画像は背景色を赤としています。

これらの画像がすべて表示されれば、そのブラウザは実際の内部フォーマットに従って表示しているということになります。

# 検証

横着して[Browser Screenshots](https://developer.microsoft.com/en-us/microsoft-edge/tools/screenshots/)を利用しました。

https://developer.microsoft.com/en-us/microsoft-edge/tools/screenshots/?url=https%3A%2F%2Fwww.ideamans.com%2F_experimental%2Fimage-format-ext-content-type%2F

すべて問題なく表示されていますね。

![screencapture-developer-microsoft-en-us-microsoft-edge-tools-screenshots-2019-03-07-08_34_33.png](https://qiita-image-store.s3.amazonaws.com/0/35178/b6c472f6-2cbe-3d9f-f3cf-1f34b531e539.png)

ついでに[Browsershots](http://browsershots.org/https://www.ideamans.com/_experimental/image-format-ext-content-type/)でも。

http://browsershots.org/https://www.ideamans.com/_experimental/image-format-ext-content-type/

いくつか非対応なのか不具合なのかわからないブラウザもありますが、かなりドマイナーなのでよしとしましょう。

# 最後に

なぜこの実験をしたのかというと、WebPの配信はしばらくJpegやPNGのレスポンスを差し替える方法が主流になりそうだからです。

`image.png`へのリクエストを内部的にWebPにルーティングして、`Content-Type: image/webp`として返す、という方法ですね。

拡張子が`.jpg`や`.png`でもWebP画像を配信しちゃっても表示される裏付けが欲しかったのです。

もちろんバラバラでもいいという意図ではないので、拡張子や`Content-Type`はお行儀良く指定しましょう！
systemctl メモ

サービスの一覧を確認、起動、停止する手順のメモ


### 定義されているサービスを全て確認

```
systemctl list-unit-files --type=service
```

### 起動中のサービスを全て確認

```
systemctl list-units --type=service
```

### 特定のサービスのステータスを確認

```
systemctl status [サービス名]
```

### サービスを起動する

```
systemctl start [サービス名]
```

### サービスを停止する

```
systemctl stop [サービス名]
```

### サービスの自動起動を有効にする

```
systemctl enable [サービス名]
```

### サービスの自動起動を無効にする

```
systemctl disable [サービス名]
```
【PHP】Gmail APIでメールを取得する

# はじめに
Gmail APIのリファレンスが全部英語なので読むのに時間がかかり、苦労したので日本語メモ用に残しておきます:open_hands:

# 公式ドキュメント
[Gmail API](https://developers.google.com/gmail/api/?hl=ja)
[Class Google_Service_Gmail_Message](https://developers.google.com/resources/api-libraries/documentation/gmail/v1/php/latest/class-Google_Service_Gmail_Message.html)　
↑いろんなクラスがあるので、欲しいメソッドが既に存在しているかもしれません。まずは欲しい機能が実装済みでないか調べましょう。

# 前準備
- PHP5.4 以上
- Composer が利用可能である
- Gmailが使えるGoogleアカウントがある

# クイックスタート
### 1. [ENABLE THE GMAIL API] ボタンをクリック
<img width="889" alt="スクリーンショット 2019-02-20 16.24.29.png" src="https://qiita-image-store.s3.amazonaws.com/0/246277/29fed223-0667-eb11-7e84-8227f3b6c1bb.png">

クリックすると以下のようなウィンドウがでてくるので、 **[DOWNLOAD CLIENT CONFIGURATION]**
というボタンをクリック
<img width="603" alt="スクリーンショット 2019-02-20 16.42.57.png" src="https://qiita-image-store.s3.amazonaws.com/0/246277/78b3ec61-323f-9083-b21a-2079eb3c91fe.png">

`credentials.json`というファイルがダウンロードされるので、作業ディレクトリにファイルを移動する。
### 2. Google Clientライブラリをインストール
```
$ composer require google/apiclient:^2.0
```
### 3. サンプル作成
- 作業ディレクトリに```quickstart.php```というファイルを作成
- そのファイルにgithubのサンプルコードをコピペ　→　https://github.com/gsuitedevs/php-samples/blob/master/gmail/quickstart/quickstart.php

### 4. サンプル実行 && アカウント認証
```
$ php quickstart.php　
```
4-a. ターミナルにリンク先が表示されるので、コピペしてブラウザで表示
4-b. 画面に従いアカウント認証をする
4-c. 認証コードが表示されるので、コピーする
<img width="518" alt="スクリーンショット 2019-02-20 16.55.27.png" src="https://qiita-image-store.s3.amazonaws.com/0/246277/5fae25fd-7064-684d-1f12-9da005629876.png">
4-d. ターミナルに貼り付け、Enter

### 5. 認証成功！　ラベル一覧が表示されます
以降は、作業ディレクトリに追加されている`token.json`を読み込んで認証するので、いちいちGoogleアカウントの認証をする必要はありません。
試しに`php quickstart.php`と再度実行するとすぐにメールのラベル一覧が表示されます。

### 6. メール一覧を取得する
```php:quickstart.php
// さっき認証に使用した quickstart.php に追記します。

// 検索条件を追加することができます。
$optParams = array(
    'maxResults' => '最大取得件数',
    'labelIds'   => 'ラベルのID', // ラベルのidはlistUsersLabels()で取得可能。
    'pageToken'  => 'ページトークン',
    // Gmailのメール検索時の形式で条件を指定できます。
    'q'          => 'from:someuser@example.com after:2018-02-20',
);
// 条件に当てはまるメールの一覧を取得します。
$messages = $service->users_messages->listUsersMessages($user, $optParams);

// メッセージIDからメールの内容を取得します。
foreach($messages->getMessages as $message) {
    $message_id = $message->getID();
    $message_contents = $service->users_messages->get($user, $message_id);
    print_r($message_contents);
}
```

### 7.メモ
メールの本文は上記のコードだと `$message_contents['payload']['body']['data']`にありますが、URLセーフ処理がかけられているためデコードする必要があります。

```php:
$body = $message_contents['payload']['body']['data'];
$body = str_replace(array('-', '_'), array('+', '/'), $body);
$body = base64_decode($body);
```
でデコードできます。
vue-routerで指定したパスで404エラーが発生したときの対応方法（Vue.js, AWS S3 + CloudFront）

# フレームワーク/環境
- Vue.js + vue-router
- AWS S3 + CloudFront

# 事象
以下のようにvue-routerで指定したパスにアクセスすると404エラー（not found）が発生する。
ただし、localhost上やS3のみ（CloudFront無し）で公開する場合は、404エラーは発生せず正常にアクセスできる。

```router.ts
import Vue from 'vue';
import Router from 'vue-router';
import Tools from './views/Tools.vue';
import Info from './views/Info.vue';

Vue.use(Router);

export default new Router({
  mode: 'history',
  base: process.env.BASE_URL,
  routes: [
    {
      path: '/',
      name: 'tools',
      component: Tools,
    },
    {
      path: '/info',
      name: 'info',
      component: Info,
    },
  ],
});

```

# 対応方法
###概要###
「CloudFront」で「Custom Error Response」を作成して、HTTP Error Codeが404（not found）の場合は、レスポンスコードを200にしてindex.htmlを返すようにする
###詳細###
1. AWSのコンソールから「CloudFront」を開く
2. メニューの「Distributions」＞対象のIDをクリック
3. 「Error Pages」タブ＞「Create Custom Error Response
」ボタンをクリック
4. 「Custom Error Response Settings」画面で以下のように設定して、「Yes, Edit」ボタンをクリック

| 項目名                   |       値          |
|:------------------------|:------------------|
| HTTP Error Code         |   404: Not Found  |
| Customize Error Response|            Yes    |
| Response Page Path      |       /index.html |
| HTTP Response Code      |           200: OK |

# 感想
エラーが解消されるとテンションが上り、別のエラーに直面してまたテンションが下がる

# 参照
- [Vue.js Router: history mode and AWS S3 (RoutingRules)
](https://stackoverflow.com/questions/43095823/vue-js-router-history-mode-and-aws-s3-routingrules)
【Linuxコマンド】grepで特定ディレクトリ配下のファイル内検索

秀丸エディタなどでよく使うgrep検索。Linux上では下記のコマンドで実現できる。

**grep -rl {検索対象の文字列} {検索対象のパス}**

例) カレントディレクトリ配下の"hello"が含まれるファイルを検索

```コマンド
$ grep -rl hello .
./a.txt
./bk/text.txt.bk
./test.txt
./tmp/20190307/sample.txt.20192307
```
GitLabをAWS上で動かす(2/3)

前回の続きです。

[GitLabをAWS上で動かす(1/3)](https://qiita.com/C910/items/772329aa2d59a7f9236d)
☞ GitLabをAWS上で動かす(2/3)
[GitLabをAWS上で動かす(3/3)](https://qiita.com/C910/items/217e7df50a37e10b781b)

# IPv4パブリックIPを設定

### ElasticIPを設定
<img width="724" alt="スクリーンショット 2019-03-07 8.44.53.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/dfe815dc-80b6-2ee1-d0aa-ec8f33aa200d.png">
作ったインスタンスを選択して右クリック（もしくはアクションから）IPアドレス管理を選択。

<img width="1028" alt="スクリーンショット 2019-03-07 8.47.12.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/754923cf-b995-0894-fb8d-305bb23d62d6.png">

「ElasticIPを割り当てます」をクリック

<img width="1278" alt="スクリーンショット 2019-03-07 8.49.37.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/aa25328d-70e6-e25e-2d41-7b5373b54e05.png">

新しいアドレス割当の画面に遷移するので右下「割り当て」ボタンをクリック

<img width="994" alt="スクリーンショット 2019-03-07 8.50.48.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/5b56021c-6715-0ab7-fdb2-1465d94d8501.png">

成功した場合は問題なく、そのまま「閉じる」ボタンをクリックしてもらって大丈夫ですが、失敗したときは下のようなエラー画面がでます。

<img width="972" alt="68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3231383837392f64336235636232302d363862312d656335622d303961302d3233313633616531376237362e706e67.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/0b0c604d-972c-36e0-679c-39adcadef9c2.png">

私が遭遇したエラーはリージョンあたりのElasticIPの割り当て数が上限に達したとのエラーでした。
その場合は、Amazon EC2 Elastic IP アドレスリクエストフォームから問い合わせて上限を上げてもらいましょう。

上記のエラーを対策したときの記事: [AWSでEC2インスタンス作成してElasticIPを割り当てようとしたら怒られた話](https://qiita.com/C910/items/3c9706b051cb8607c203)

### ElasticIPの確認
<img width="2020" alt="スクリーンショット 2019-03-07 8.57.25.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/bd79e550-7665-c537-5dbd-6e0ab2ffaf39.png">

ElasticIP一覧に追加されています。
何に使用しているかわかりやすいように適宜名前をつけてあげましょう。

### アドレスの関連付け
<img width="473" alt="スクリーンショット 2019-03-07 9.01.04.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/83fe4208-18ed-dbec-0d42-b8c81351a7be.png">

雑に名前をつけたら今度は関連付けをします。
選択して右クリック（またはアクション）から「アドレスの関連付け」を選択

アドレスの関連付けの画面に遷移しますので、画像のように前回作ったインスタンスを選択
<img width="1311" alt="スクリーンショット 2019-03-07 9.04.49.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/66e090d4-7926-c975-fa97-3627da55b7a8.png">
プライベートIPも選択しましょう。

そして右下の「関連付け」をクリック

<img width="979" alt="スクリーンショット 2019-03-07 9.07.00.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/85c71f9e-612b-5fcd-4828-3384701d7570.png">

これで作成したインスタンスとの関連付けができました。

# ssh接続確認

### IPv4パブリックIPでssh接続
<img width="2007" alt="スクリーンショット 2019-03-07 9.08.38.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/ca169b13-ca2e-1f17-5bbe-9987132f9b60.png">

インスタンスに戻って確認すると先程割り当てたElasticIPがIPv4パブリックIPに表示されています。（確認終了

ターミナルでssh接続して接続されることを確認！
<img width="570" alt="スクリーンショット 2019-03-07 9.12.53.png" src="https://qiita-image-store.s3.amazonaws.com/0/218879/930d4602-6b5a-e40c-8199-90a1693dafdd.png">

---

今回は以上です。
次回はGitLabをインストールするところから
"npm run build"でエラー"Cannot find module '../package.json'"が発生したときの対応方法

# 事象
ビルド（`npm run build`）すると、エラー"Cannot find module '../package.json'"が発生

# 対応方法
node_modulesを削除して、再インストール（`npm install`）する

# 感想
GithubのIssuesは、とりあえずいいねが集中しているコメントを見ればよい

# 参照
- [Error: Cannot find module '../package.json'](https://github.com/webpack/webpack/issues/5427)
🏃‍♀️無限ループ∞最短選手権🏃‍♂️

# さぁみんな無限ループしよう。
最近、無限ループが流行りらしいので
各プログラミング言語(その辺にあった10個の言語)の
無限ループを比べてみます。
**果たしてどの言語が1位に輝くのか!?**

※改行は1文字としてカウント。
(一応、全て実行してチェックしています)

# C (24文字)

```c
int main(void){for(;;);}
```

# C⋕ (37文字)
```csharp
class a{static void Main(){for(;;);}}
```

# C++　(20文字)

```cpp
int main(){for(;;);}
```

# D (22文字)
```d
void main(){for(;;){}}
```

# Go (31文字)
```go
package main
func main(){for{}}
```

# Java (53文字)

```java
class a{public static void main(String[]a){for(;;);}}
```

# JavaScript (8文字)

```javascript
for(;;);
```

# PHP (14文字)

```php
<?php
for(;;);
```

# Python (9文字)

```python
while 1:0
```

# Ruby (11文字)

```ruby
while 1
end
```

# 【優勝】JavaScript

チャンピオンは**"JavaScript"**でした。さすが**"JS"**。
**"JavaScript"**は無限ループ界において最有力候補であると考えられますね。

### ???「JSが優勝だと思っていたのか。」

# 【真の優勝】Ruby ※追記

```ruby:Ruby(6文字)
loop{}
```

Ruby、6文字で無限ループが出来るとは……。
~~恐るびー~~

### ???「6文字ごときが優勝だと思っていたのか。」

# 【本当の真の優勝】L00P ※追記(番外編)

```:L00P(0文字)
```

0文字……圧巻です。
言語名からして、無限ループ界の頂点に君臨していると思われる風貌をしてますね……。

このように上記で比べていた10個の言語以外の言語では、もっと文字数が少ないものがありました。
無限ループは奥が深い。

# 最後に

もっと文字数減らせるよ！とか
もっと文字数が少ない言語あるぜ！最強だぜ！

などなどありましたらコメントまたは編集リクエストでお願い致します。
"npm run build"でエラー"Cannot find name 'Buffer'/'http'/‘https'"が発生したときの対応方法

# 事象
ビルド（npm run build）すると、エラー"Cannot find name 'Buffer'/'http'/‘https'"が発生

# エラーログ例
```
0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/bin/node', '/usr/local/bin/npm', 'run', 'build' ]
2 info using npm@6.4.1
3 info using node@v8.12.0
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle ztrans@0.1.0~prebuild: ztrans@0.1.0
6 info lifecycle ztrans@0.1.0~build: ztrans@0.1.0
7 verbose lifecycle ztrans@0.1.0~build: unsafe-perm in lifecycle true
8 verbose lifecycle ztrans@0.1.0~build: PATH: 
9 verbose lifecycle ztrans@0.1.0~build: CWD: /Users/user/Desktop/ztrans
10 silly lifecycle ztrans@0.1.0~build: Args: [ '-c', 'vue-cli-service build' ]
11 silly lifecycle ztrans@0.1.0~build: Returned: code: 1 signal: null
12 info lifecycle ztrans@0.1.0~build: Failed to exec build script
13 verbose stack Error: ztrans@0.1.0 build: `vue-cli-service build`
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
13 verbose stack at emitTwo (events.js:126:13)
13 verbose stack at EventEmitter.emit (events.js:214:7)
13 verbose stack at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack at emitTwo (events.js:126:13)
13 verbose stack at ChildProcess.emit (events.js:214:7)
13 verbose stack at maybeClose (internal/child_process.js:915:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
14 verbose pkgid ztrans@0.1.0
15 verbose cwd /Users/user/Desktop/ztrans
16 verbose Darwin 17.6.0
17 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "build"
18 verbose node v8.12.0
19 verbose npm v6.4.1
20 error code ELIFECYCLE
21 error errno 1
22 error ztrans@0.1.0 build: `vue-cli-service build`
22 error Exit status 1
23 error Failed at the ztrans@0.1.0 build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]
```

# 対応方法
tsconfig.jsonで、以下の設定を追加すると解決する

```tsconfig.json
"compilerOptions": {
  "types": [
  "node"
],
}
```

# 感想
GithubのIssuesは、Stack Overflowと違い、答えが埋もれている。

# 参照
- [Typescript error: Cannot find name 'Buffer'/'http'/'https'](https://github.com/aws/aws-sdk-js/issues/1271)
[OR-Tools] Solver別Wall time

計算にぜんぜん時間を要していないのに，なぜ，Walltimeが4秒と出るの?

Solverを以下のように宣言したとき：
```solver = cp_model.CpSolver()```
WallTimeは，以下のように得られる：
```wallTime = solver.WallTime()```
cp_model.CpSolver()のとき，WallTimeの単位は，秒．
https://developers.google.com/optimization/scheduling/employee_scheduling

Solverを以下のように宣言したとき：
```solver = pywraplp.Solver('SolveStigler',pywraplp.Solver.GLOP_LINEAR_PROGRAMMING)```
WallTimeは，cp_modelの利用時と同様に，以下のように得られる：
```wallTime = solver.WallTime()```
ただしこのとき，WallTimeの単位は，ミリ秒．
https://developers.google.com/optimization/reference/linear_solver/linear_solver/MPSolver/

単位が違う．．．