OmniAICreator/Qiita-1.07M huggingface dataset:
ElasticBeanstalkでRubyのバージョンアップ候補が現れないときにやったこと

ElasticBeanstalkで運用しているRailsアプリケーションがあり、開発環境のRubyのバージョンを2.2から2.4に上げました。
ElasticBeanstalk上の本番環境もアップグレードしようと思ったのですが、GUIのプラットフォームのプルダウンに2.4の候補が現れず、しばらくハマリました。

調べたところ、CLIから解決する方法しか見当たりませんでした。メモ程度ですが、解決までの道のりです。

もっとよい方法があったら教えてください！

# 選択できるソリューションを調べる

ベースとなるAmazon Linuxと言語のバージョンの組み合わせをソリューションと呼ぶようです。
`list-available-solution-stacks`で選択できるソリューションをリストアップできます。

```bash
aws elasticbeanstalk list-available-solution-stacks | jq -r '.SolutionStacks[]'
```

今回は`64bit Amazon Linux 2018.03 v2.8.6 running Ruby 2.4 (Passenger Standalone)`を使うことにしました。

## ハマったポイント

以下のページにプラットフォーム一覧があります。

Elastic Beanstalk でサポートされているプラットフォーム
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/concepts.platforms.html#concepts.platforms.ruby

最初にここから選んだのですが、実際にソリューションを適用するステップで見つからないと何度も怒られてしまいました。

選択できるソリューションのバージョンには縛りがあるようです。`aws elasticbeanstalk list-available-solution-stacks`で取得できるリストから選びましょう。

# 環境のクローン

次に少し乱暴なやり方をするので、環境をクローンしてから作業した方が安全です^^

GUIや`eb`コマンドからクローンしてください。後でDNSの付け替えをします。

# アプリケーションの新しいバージョンをアップロード

Ruby 2.4に対応したアプリケーションコードをアップロードして新しいバージョンを作成するために、クローンした環境にひとまずデプロイしちゃいます。

zipに固めてアップロードだけするのがお行儀のよいやり方ですが、`eb deploy`と同じパッケージングをしたいのでこうしました。ビルドだけ行うコマンドが見当たらず。

エラーが発生してヘルスチェックが終わらない場合は、オペレーションを中断しちゃいます。それでも新しいバージョンラベルは発行されます。

```bash
eb deploy クローンした環境
```

# ソリューションの変更によるRubyのアップグレード

`list-available-solution-stacks`で取得した中から、`64bit Amazon Linux 2018.03 v2.8.6 running Ruby 2.4 (Passenger Standalone)`にアップグレードします。

`aws elasticbeanstalk update-environment`コマンドを使います。

```bash
aws elasticbeanstalk update-environment \
  --environment-name '環境' \
  --solution-stack-name '64bit Amazon Linux 2018.03 v2.8.6 running Ruby 2.4 (Passenger Standalone)' \
  --version-label '新しいアプリケーションのバージョンラベル'
```

これで無事に新しい環境にデプロイができたので、DNSを付け替えて作業完了です。

誤ってプラットフォームをアップグレードしない措置なのかなーと推測しましたが、なかなか大変でした。
AOJ day 10: Datatype-Generic programming for generating TypeScript types

Many people really like data types in PureScript, for very good reasons. Data types are actually really amazingly good, especially sum types. The best part about data types is that we have various ways to pattern match on them, matching on where we have constructors of data types and their arguments.

What happens when we want to actually get information about our data types? If we think about how our data types are defined, we can extract some more general information about our types:

```hs
data Fruit = Apple | Banana String

-- We have a data type Fruit
-- for which we have a Sum of two arguments:
-- * Constructor "Apple", of no arguments
-- * Constructor "Banana", of one argument:
--   * String
```

We could go and define a generic set of data types that describe this shape, but we don't need to, as this is a well-known concept known as Datatype Generics, where the compiler can derive the generic form for us to use:

```hs
import Data.Generic.Rep as GR
import Data.Generic.Rep.Show (genericShow)

data Fruit = Apple | Banana String

-- note the underscore at the end for the `rep` parameter of class Generic
derive instance genericFruit :: GR.Generic Fruit _

instance showFruit :: Show Fruit where
  show = genericShow
```

So in this example, we were able to get an implementation of `show` for free, by using the datatype generics implementation of `show` with a compiler-derived instance of `Generic` for `Fruit`.

## Datatype-Generic programming for generating TypeScript code from Purescript

In this post, I go over how we can use datatype generics for codegen of TypeScript types from some PureScript type definitions.

<https://qiita.com/kimagure/items/cc0ea2982abdf1625e87>

While the newest version of the library talked about in the article now uses RowToList as TypeScript code generation largely targets Records and Variants, the ideas in it are more broadly applicable to any data types. Indeed, in PureScript 0.12, we no longer generate the generic representation for records (and that's a good thing, leave unto RowToList what is RowToList's), but we still use datatype generics for data types. 

A more readily applicable tutorial on how to use generics-rep can be found here:

<https://purescript-simple-json.readthedocs.io/en/latest/generics-rep.html>
AOJ day 9: Psc-Package2Nix

So while Psc-Package is a nice tool to figure out our dependencies from a package set and a list of direct dependencies, it leaves a lot to be desired when we think about how packages are downloaded. Do we need it to have git fetch our dependencies whenever we don't have them already installed?

And while many will say that Psc-Package indeed shouldn't use git to fetch every dependency, I think many will point out that even if you tried to store these, you'd need to verify the contents somehow, never mind the endless hell that is trying to figure out where you can actually write files on a user's system globally without trouble (well, ignoring all of the unprincipled approaches of shitting files into a user's HOME directory somewhere).

So what if instead of trying to make yet another shitty solution, we can use a solution that does try to do the right thing? If we use Nix for this, we can write derivations for how the dependencies are to be fetched, and those will be hashed. When these derivations are run, Nix will create store entries for these derivations. How do we generate this from a psc-packages.json file though?

## "Nix-ify your Psc-Package dependencies"

In this post, I talked about how the psc-package2nix tool works, by using the package set and the direct dependencies to generate derivations for each package with the correct sha256 hash needed to verify the contents of the dependency sources.

<https://qiita.com/kimagure/items/85a64437f9af78398638>

This also goes into how dependencies are solved for in Psc-Package by traversing the transitive dependencies.

With the Psc-Package2Nix tool, we can now leverage Nix to download and cache dependencies for our projects, where only in the final step, we can use a small derivation to copy the dependencies from the store into the appropriate directories in `.psc-package/{set}/{package}/{version}`. This means that between projects, changes in package sets, and re-installs, we don't have to download any dependencies redundantly, and can instead have Nix handle the details of when new dependencies need to be downloaded.
Unityで10回だけ処理をするプログラムを最適化してみた


`バージョンUnity 2017.3.1f1 (64-bit)`
**1回だけ実行させる方法**みたいな記事はよくあるのに、
**10回だけ実行させる方法**の記事が無かったのと
任意の回数実行のプログラムがダサかったので
#よくあるパターン
```cs
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Hoge : MonoBehaviour {
    int value = 0;
    int number = 10;
    void Start()
    {
    }
    void Update()
    {
        if (value < number)
        {
            Debug.Log("Play!!");
            ++value;
        }
    }
}
```
ただこの状態だと変数が2つになってしまい8バイト消費してしまう。
メモリにも優しくなく、変数宣言も増えてしまってスマートではない。

#マジックナンバー使用
```cs
        if (value < number)
        {
            Debug.Log("Play!!");
            ++value;
        }
```
かと言っても条件式にマジックナンバーは使いたくない
急に5回の処理に変えたい場合ソースコードの中から探していちいち変えなくては、行けなくてミスのもとになってしまう。

#解決
[マジックナンバーを駆逐せよ！](https://shin-go.hatenablog.com/entry/magicnumber)
こちらの方法ならメモリも半分の4バイトで済み、変数も1つなのでスマートである。

`※numberにconstを付ければいい話ですが、こんなコードもあるよ。という紹介です。`
php-master-changes 2018-12-02

今日はドキュメントの修正、imagecropauto() の第三引数の扱い修正、ビルドシステムの修正があった！

# 2018-12-02
## weltling: Update NEWS [ci skip]
- https://github.com/php/php-src/commit/ea454583ebcd0f2414e35e6446f1ed803476ea78
- [7.3~]
- ext/pcre の[昨日のバグ修正](https://qiita.com/sj-i/items/348100041b37b8f236e3#weltling-fixed-bug-77193-infinite-loop-in-preg_replace_callback)の件を NEWS へ追記

## cmb69: Fix [#73291](https://bugs.php.net/bug.php?id=73291): imagecropauto() $threshold differs from external libgd
- https://github.com/php/php-src/commit/dcad13e8c936646ae9cfd4a4ef97a7443a23e774
- imagecropauto() の第三引数の扱いがバンドル版とシステム版で異なっていた問題の修正
- システム版の方に挙動をあわせた形

## petk: Replace AC_CHECK_FILE with test -f
- https://github.com/php/php-src/commit/72087c8921cc21d4debc5dcf8e4189007c51969e
- ビルドシステムで、zend_language_scanner.c への AC_CHECK_FILE を test -f に置き換え
- AC_CHECK_FILE はクロスコンパイル時にターゲットシステム用のファイルが存在するかをチェックするもので、ビルド時に生成するこのファイルに対してなら単に test -f でよいという話みたい

## cmb69: [ci skip] Fix names of the constants
- https://github.com/php/php-src/commit/f0f4ab4b02d4e6783d7bc51c4045bf879bedb4fb
- ドキュメント内の GD_CROP_DEFAULT と GD_CROP_SIDES をそれぞれ IMG_CROP_DEFAULT と IMG_CROP_SIDES へ書き換え

## petk: Remove support for Rhapsody code name
- https://github.com/php/php-src/commit/bde96f293a9d3bf9a61039a93c9b7c2d098cb119
- ビルドシステムで、古い Mac をサポートするための名前だった rhapsody のサポートを除去
ラズパイ向けのOpenCVを、x86_64機のDockerでビルド


ラズパイ向けのOpenCV 4を、x86_64機のDockerでビルド

# 概要
- ラズパイ向けのOpenCVを、x86_64機のDockerでビルドします。
- docker で、 qemuを使うので、結構時間がかかる。

# 環境
- ビルド環境
    - x86_64機
    - Lubuntu 18.04.1 
    - https://github.com/mt08xx/opencv-rpi-buildenv-docker.git
- 実行
    - Raspberry Pi 3B
    - Raspbian: 2018-11-13-raspbian-stretch

# ビルド手順
1. 準備

	```bash
	# 1. スクリプトを取得
	git clone https://github.com/mt08xx/opencv-rpi-buildenv-docker

	# 2. gitのフォルダに移動
	cd opencv-rpi-buildenv-docker

	# 3. docker のインストール(必要あれば)
	sudo ./inst_docker.sh

	# 4. dockerグループに参加
	sudo usermod -aG docker $USER

	# 5. ARMのバイナリ実行のための、qemuとbinfmt関係をインストール
	sudo ./inst_prereq.sh
	```


2. 一度再起動

    ```bash
# 6. 再起動
sudo reboot
```

3. コンテナを作成

	```bash
	# 7. ビルド環境のコンテナを作成
	cd ~/opencv-rpi-buildenv-docker
	docker build . -t mt08/opencv-rpi-buildenv
	```

	```shell-session:このぐらい
	$ time docker build . -t mt08/opencv-rpi-buildenv
	real    16m50.195s
	user    0m0.597s
	sys     0m0.317s
	```

4. ソースの取得・解凍

	```bash:OpenCV4.0.0のソース取得・解凍
	cd ~/opencv-rpi-buildenv-docker
	./dl_opencv.sh 4.0.0
	```

5. ビルド

	```bash
	OPENCV_VERSION=4.0.0
	WORKDIR=build
	NUM_JOBS=8
	#
	cd ~/opencv-rpi-buildenv-docker
	# 
	mkdir -p opencv-${OPENCV_VERSION}/${WORKDIR}
	# 
	# cmake コンフィグレーション
	time docker run -it --rm -v `pwd`:/build -w /build/opencv-${OPENCV_VERSION}/${WORKDIR} --name opencv-rpi mt08/opencv-rpi-buildenv ../../conf_opencv.sh ${OPENCV_VERSION} 2>&1 | tee build_conf.log
	#
	# make
	time docker run -it --rm -v `pwd`:/build -w /build/opencv-${OPENCV_VERSION}/${WORKDIR} --name opencv-rpi mt08/opencv-rpi-buildenv make -j ${NUM_JOBS} 2>&1 | tee build_make.log
	```





    ```shell-session:24-logical-coreで、NUM_JOBS=60にて
real    81m54.272s
user    0m0.569s
sys     0m0.274s
```

6. インストールファイル


	```bash
	# インストール ./usr_local フォルダに必要なものが入る
	OPENCV_VERSION=4.0.0
	WORKDIR=build
	time docker run -it --rm -v `pwd`:/build -w /build/opencv-${OPENCV_VERSION}/${WORKDIR} -v `pwd`/usr_local:/usr/local --name opencv-rpi mt08/opencv-rpi-buildenv make install 2>&1 | tee build_install.log  
	#
	# アーカイブ作成
	cd usr_local
	tar jcvf ../opencv-${OPENCV_VERSION}-rpi.tbz .
	ls -l ../*.tbz 
```

    ```shell-session
## make install
real    3m50.976s
user    0m0.078s
sys     0m0.148s
```

# ラズパイでの実行
1. 必要なパッケージのインストール

	```こぴぺ
	sudo apt-get update && \
	sudo apt-get install \
		libjpeg62-turbo libtiff5 libjasper1 libpng16-16 \
		libavcodec57 libavformat57 \
		libatlas3-base liblapack3 \
		libswscale4 libv4l-0 libxvidcore4 libx264-148 \
		libgtk2.0-0 libgtk-3-0 libcanberra-gtk0 libcanberra-gtk3-0 \
		libavresample3 libtesseract3 liblept5 libhdf5-100 \
		libgstreamer1.0-0 libgstreamer-plugins-base1.0-0 
	```
2. ↑でできた、`opencv-4.0.0-rpi.tbz`をラズパイに持ってくる

3. `/usr/local`に解凍

```
sudo tar jxvf ./opencv-4.0.0-rpi.tbz -C /usr/local
sudo ldconfig
``` 


# その他

1. (TODO) 普通のノートパソコンでのビルド時間 ?
2. (TODO) debパッケージ作成 ?
Android古いプロジェクトエラーNo toolchains found in the NDK toolchains folder for ABI with prefix

No toolchains found in the NDK toolchains folder for ABI with prefix: mipsel-linux-android

### build.gradle
    dependencies {
        classpath 'com.android.tools.build:gradle:3.2.0'
    }
    repositories {
        google()
        jcenter()
    }

### gradle-wrapper.properties

    distributionUrl=https\://services.gradle.org/distributions/gradle-4.6-all.zip
EC-CUBE4の本番環境でデバッグモードを利用する方法

EC-CUBE4では環境変数でデバッグモードに切り替えることができます。

```env:本番環境
APP_ENV=prod
APP_DEBUG=0
```

```env:開発環境
APP_ENV=dev
APP_DEBUG=1
```

しかし本番環境の環境変数を変更してデバッグモードを利用するとエンドユーザからのアクセスでもデバッグモードとなってしまいます。

# デバッグモード用の `index.php` を用意する

EC-CUBE4でもEC-CUBE3の `index_dev.php` のような役割のファイルを作れます。

`index.php` をコピーして適当な推測されにくいファイル名のファイルを作成します。

```shell
cp index.php tekitou_na_suisoku_sare_nikui_file_name.php
```

作成したファイルの37行目付近に環境変数から `$env` と `$debug` を設定している処理があるので、それぞれ `dev` , `1` を代入する処理に書き換えます。

```shell
vi tekitou_na_suisoku_sare_nikui_file_name.php
```

```diff
--- index.php	2018-09-17 00:02:26.000000000 +0900
+++ tekitou_na_suisoku_sare_nikui_file_name.php	2018-12-03 04:34:29.000000000 +0900
@@ -34,8 +34,8 @@
     }
 }

-$env = isset($_SERVER['APP_ENV']) ? $_SERVER['APP_ENV'] : 'dev';
-$debug = isset($_SERVER['APP_DEBUG']) ? $_SERVER['APP_DEBUG'] : ('prod' !== $env);
+$env = 'dev';
+$debug = 1;

 if ($debug) {
     umask(0000);
```

このファイルからアクセスすると強制的にデバッグモードとなります。

http://127.0.0.1:8000/tekitou_na_suisoku_sare_nikui_file_name.php/

必要がなくなればファイルは消しておきましょう。

```shell
rm tekitou_na_suisoku_sare_nikui_file_name.php
```
マイクロサービスの技術異質性について検証してみた話。

この記事はMicroservices Advent Calendarの1日目です。

## Microservicesとの関わり

最近[Qiita:Zineでも取り上げられました](https://zine.qiita.com/jobs/rakus-microservice/)が2017年春から社内でMicroservicesについてパイロットプロジェクトを立ち上げて検証をしていました。実サービスへの適用はまだありません。

## 技術異質性とは

マイクロサービスアーキテクチャは独立性の高い（疎結合な）複数のサービスを組み合わせるアーキテクチャなので、サービスごとに異なる技術スタックを採用することができるというメリットのことです。

各サービスは完全に別のWEBアプリケーションとして作成されるので、アプリケーションフレームワークはもちろんのこと利用言語もバラバラで構成できます。

## やってみた

### 条件

- BFFあり
- サービスは3つ
- BFFと3つのサービスに主担当はそれぞれ1人ずつ
- コードレビューはクロスで実施
- 利用言語
    - BFF: JavaScript
    - サービスA: Go
    - サービスB: Ruby
    - サービスC: Haskel

検証の一環だったので言語からあえてバラバラにしていました。

### どうだったか

正直しんどい。

特にコードレビューで経験の浅い言語を読むことになる状況だったので、コードレビューがあまり意味をなしていなかった。

ただし当然ながらシステム全体としては不整合なく動作する状態にはなった。これが実現できる事自体がモノリシックな構成に対して大きなメリットではあると感じた。

## 考えてみる

技術異質性を実現するためにはいくつか条件があると感じた。

### 1. サービスごとにチームがあること

一番わかりやすかったのはコードレビューの難易度だった。別のサービス担当（＝別の技術スタック利用者）がレビューを担当するのは現実的ではないと感じた。レビュアーは同じ言語、同じフレームワーク（、できれば同じコードスタイル）を利用している人が担当すべきだと感じた。

ただこれについては検証プロジェクトゆえに担当者が1人ずつだったというのもあるので、実際の開発では自然と解決される気もする。でもサービス掛け持ちでの開発の話もよく聞くからやっぱりしんどいかも。

### 2. 不必要に異なる技術スタックにしない

あくまで「異なる技術スタックを利用できる」のであって、「積極的に異なる技術スタックにすべき」ではないと感じた。特に記述的な要求がない場合には各サービスでの技術スタックを共通化（せめて数パターンのどれかに）しておくに越したことはない。

特定のサービスに対して技術的な要求がある場合に異なる技術スタックを選択可能である、と考えたほうが良さそうだった。例えばノンブロッキングな非同期処理をしたいからNode.jsやKotlinを選択するといった場合や、高度な検索処理を行いたいからElasticsearchを中心に据えたシステムにするといった場合が該当すると思う。

そういった要求がない通常パターンのサービスについてはシステム内で共通スタックを定義しておいたほうが開発効率は担保できるはず。

### 3. 通信プロトコルもできる限り揃える

今回意図的にGo言語で作成したサービスはgRPC、それ以外はRESTで通信する仕組みを試してみましたが、BFFからの呼び出しがしんどかったです。gRPCの扱いに慣れていなかったのもあるかもしれませんが、このあたりも必要に迫られなければ揃えておいた方がよいと感じました。あとやっぱりRESTの方がテストツールなどのエコシステムが**手軽に使えるもの**として充実しているというのは強いです。

今回は試していませんがGraphQLなども混ざってくると更に大変になるのかなと思います。呼び先によって呼び方を変えないといけないのは（主に）BFF実装時の負担が増えます。

このあたりはPub/Subを使ったイベント駆動アーキテクチャにすることで吸収できそうな気もしますが、今回の検証では対象に含めていないので今後試してみたいと思っています。

## まとめ

マイクロサービスアーキテクチャでは異なる技術スタックは混在できるが、特別な理由がない限りは技術スタックを揃えておいて、必要に迫られたときに選択肢を狭めないための特性だと認識しておくくらいが良さそう。

---

遅刻での投稿となってしまいましたが以上です。

次は12/6に投稿される @takegamm さんです。
社内向けにJavascript初心者を中級くらいまで引き上げるslideを作りました

社内向け勉強会で発表したプレゼンスライドを載せます。

[フロントエンドの複雑性と戦うベストプラクティス
](https://docs.google.com/presentation/d/e/2PACX-1vQRv7sZw25Xu0kVnS-AiJggp2F-IZzWEVn7mR3PIBTbfmGSsL6CM3ZhbKfUlvjZr_w57qv09AwLiVY8/pub?start=false&loop=false&delayms=3000)

主に、ESを学び始めたJavascript開発者向けにスライドを作っています。webpackを触ったことがないくらいの人のための設定例も載せています。
tree shakingなどを考えると、モジュール化に際して、wild cardは控えめにしたほうが良いなど、様々な議論がありますが、あえて、最初の第一歩としてトピックを絞っています。なのでツッコミどころも結構あると思いますが、遠慮なくまさかりお願いします。

google slide埋込できる方法がないか調べたのですが、調べきれなかったのでリンクを張っています。どなたか、こうすればできるよっていうのがあれば教えてください。
コミュ障プログラミング言語で遊んでみた

#コミュ障プログラミング言語とは？

プログラミング言語を調べてたら「**コミュ障プログラミング言語**」なるものを発見しました．

webサイトはこちら↓
http://www.moonroom.mydns.jp/ls/software/commdis.htm

ｱｱ…　ｴｯﾄ…　みたいなコミュ障の人が言いそうな単語だけでプログラムが書けるらしいです．

Hello, world!!と出力するプログラムはこうなるらしいです．．．

**入力**

```
ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｻｾﾝ…ｱｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…
ｱｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱｱ､ｱｱ､
ｱｱ､ｱ､ｯｽ…ｱｱ…ｴｯﾄ…ｱｱ…ｱ…ｱ…ｴｯﾄ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｴｯﾄ…ｴｯﾄ…
ｱ…ｱ…ｱ…ｴｯﾄ…ｱｱ…ｱ､ｴｯﾄ…ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｴｯﾄ…ｱｱ､ｱ…ｱ…
ｱ…ｱ…ｱ…ｱ…ｱ…ｱ…ｴｯﾄ…ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｴｯﾄ…ｱ…ｱ…ｱ…ｴｯﾄ…ｱ､ｱ､
ｱ､ｱ､ｱ､ｱ､ｴｯﾄ…ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｱ､ｴｯﾄ…ｱｱ…ｱ…ｴｯﾄ…
```

**出力**

```
Hello, world!!
```

#Windowsで実行してみよう

###commdis.exeのダウンロード
先程のwebサイトから
http://www.moonroom.mydns.jp/ls/software/commdis.htm

**commdis.exe**をダウンロードします．

![commdis.PNG](https://qiita-image-store.s3.amazonaws.com/0/317052/93eb78b1-aa70-9be6-e0a6-2c44b851ea51.png)



###ファイルを解凍，コピペする．

ファイルを解凍すると，次の状態になりました．
![pic.PNG](https://qiita-image-store.s3.amazonaws.com/0/317052/a4a20ae3-070a-0264-fe7b-41443c40289e.png)


sampleフォルダの中には，"HelloWorld.txt", "FizzBuzz.txt", "FizzBuzz2.txt"の３つのテキストファイルが保存されています．

それらをcommdis.exeと同じディレクトリにコピペしましょう．
![pic2.PNG](https://qiita-image-store.s3.amazonaws.com/0/317052/dc256ab7-7bb8-235f-7269-c2a1af712abe.png)

###ファイルの実行
HelloWorld.txtを実行するときには，HelloWorld.txtをドラッグし，commids.exeにドロップします．
![スクリーンショット (3).png](https://qiita-image-store.s3.amazonaws.com/0/317052/cbac2071-5d02-37c0-1645-f51c241d6f57.png)


その結果，Hello, world!!と正常に表示されました．
![pic4.PNG](https://qiita-image-store.s3.amazonaws.com/0/317052/3089f836-0828-f763-a67b-66fb315a9a53.png)
メジャーな宝石の名前、だいたいプログラム言語になってる説

そろそろおいらもプログラム言語でも作ろうかなと思って先にネーミングを検討してたら、
Perl、Ruby 以外にも宝石名のプログラム言語が多数あるっぽいことが判明。
宝石の名前のプログラム言語がどのぐらいあるか調べてみた。



| 宝石名       |       言語名 |    タイプ    | 概要 |
|:-----------------|------------------|-----------------|------------------|
| 真珠（パール）|              Perl|        スクリプト言語| 説明不要の大メジャープログラミング言語。 <br> 真珠（パール）の正確なつづりは pearl。<br>６月の誕生石。 | 
| ルビー |            Ruby|       オブジェクト指向<br>スクリプト言語|説明不要の大メジャープログラミング言語<br>７月の誕生石|
| 水晶（クリスタル）|              Crystal|        Rubyライクの<br>コンパイル言語|https://crystal-lang.org/ <br> 大規模での利用事例も多数ある注目言語|
|サンゴ|Coral|学習用のシンプルな<br>プログラミング言語|[official site](https://corallanguage.org/)<br>３月の誕生石|
| トパーズ|                topaz|         RPythonで書かれた<br>Ruby実装|[github](https://github.com/topazproject/topaz) <br>[official site](http://docs.topazruby.com/en/latest/) <br>１１月誕生石|
| エメラルド|             Emerald|       1980年代に作られた<br>OOPな言語|[wikipedia](https://en.wikipedia.org/wiki/Emerald_(programming_language)) <br>５月の誕生石|
| ダイヤモンド|           Diamond|      C#で書かれた<br>OOPな言語|https://archive.codeplex.com/?p=diamond <br>４月の誕生石|
|ガーネット|Garnet|Rubyライクの<br>スクリプト言語|[official site](https://www.cise.ufl.edu/~jnw/COP5555-200308/Assignments/Programs/garnet.html) <br>１月の誕生石 |
|サファイア|sapphire|関数型言語？|[official site](https://github.com/chamini2/sapphire) <br>９月の誕生石|
|琥珀（こはく）|Amber|関数型言語|[github](http://nineties.github.io/amber/ja/)|
|オパール|Opal|関数型言語|[wikipedia](https://en.wikipedia.org/wiki/Opal_(programming_language)) <br>１０月誕生石|



上記で今一番ホットなのがなんといっても Crystal だろう。
- [Rubyっぽいコードが爆速で動く！？CrystalとRubyを比較してみた](https://proxy-paiza-hatenablog-com.paiza.cloud/entry/2018/06/01paizacloud_crystal_lang)
- [Ruby のように書きやすく C のように速いプログラミング言語「Crystal」](https://inside.dmm.com/entry/2018/05/30/crystal-lang)
- crystalのタグをチェック→ https://qiita.com/tags/crystal

# 結果

上記の通り、一目瞭然でメジャーな宝石名のプログラミング言語はすでにほぼ存在していることが分かった。プログラミング言語の名前をつける場合は宝石以外のジャンルから検討した方がよさそう。

**そう思えば C って元素記号だと炭素、炭素の単結晶といえばダイヤモンド！
ということでC言語が宝石の王様だったー。**
VSCode on WLinux on Windows

# 前置き

Windows で快適にすばやく簡単に VSCode を使うための WLinux の紹介です。

当然、VSCode は Windows 上でも動くのですが、言語パッケージのバージョン管理などが結構悩みの種です。
でも Windows 機しか持ってない…という場合、WSL (Windows Subsystem for Linux) が利用できるわけですが、
正直初心者にはコマンド操作でのインストールもなかなか難しいところです。
そんなとき、とりあえず初期セットアップくらいはサクッと簡単に終わらせてしまえるのが WLinux です。

これやるくらいなら Windows で開発するのやめろって感じもありますが、
どうしてもWin機でやりたいときもきっとあると思うので書きました。


# 概要

Windows での開発環境として WLinux を導入し、その上で VSCode を動かします。

### 環境

- Windows 10 Pro (build 17134.407)
- WLinux 1.25.0
- X410 (XServer 必須。VCXsrv などでもいい)

### 利点

- 初心者でも導入が簡単でわかりやすい
- Windows 側の環境へ影響がほぼない
- 要するに Debian なので、言語・ビルドツールなどのバージョン管理も柔軟で自由にできる

### 欠点

- WLinuxが有料 (知識があれば自前でビルドしてタダで済む)

# 導入手順

1. Windows store にて購入。 (https://www.microsoft.com/ja-jp/p/wlinux/9nv1gv1pxz6p)
2. インストールして起動
3. Username, Passwd を入力
![WLinux002.PNG](https://qiita-image-store.s3.amazonaws.com/0/191470/bede04e9-0269-fd59-8204-50c76b4619e4.png)

4. wlinux-setup コマンドを実行(以下のようなメニューが表示される)
![WLinux003.PNG](https://qiita-image-store.s3.amazonaws.com/0/191470/821bea42-37cc-5fc9-ece3-5f977bb3858a.png)
![WLinux004.PNG](https://qiita-image-store.s3.amazonaws.com/0/191470/ffd59e45-f6cd-87fd-f20e-4c83cdb514e2.png)

5. 画面に従い、Nodejs と Editor にチェックを入れる(Space で選択、Enter で決定)
6. Editor で VSCode を選択してインストール
![WLinux005.PNG](https://qiita-image-store.s3.amazonaws.com/0/191470/685b56cb-ba52-55f7-5bdb-af0c2604162f.png)

7. 適当に Enter 押してると終わる


# 使い方

先に X410 などの XServer を起動しておきます。

普通に起動するのと変わらず、

```bash
$ code .
```

と打つだけで起動します。
![WLinux006.PNG](https://qiita-image-store.s3.amazonaws.com/0/191470/8bd625ae-173c-b291-a8d6-499acc5e146c.png)

あとは普通に Ubuntu を使う感覚でお好みの環境を作りましょう。
環境づくりに関しては触れませんので、いろんな記事をご参考ください。

# あとがき

Win 機しかない人がとりあえずサックリ VSCode を使うための紹介でした。
VSCode というより WLinux の紹介になっちゃいました…。
Windows アプリとか作るなら別ですが、そうじゃないなら WLinux も選択肢としては悪くないんじゃないかと思います。
ただ、Live Share などの機能を試していないため、そういった機能が正しく動くかはわかりません…。
時間があれば検証してみたいと思います。

# 関連リンク

- [WLinux - Github](https://github.com/WhitewaterFoundry/WLinux)
- [X410 - Microsoft Store](https://www.microsoft.com/ja-jp/p/x410/9nlp712zmn9q)
- [Wlinux - Twitter](https://twitter.com/wlinuxapp)
    - Twitter で Wlinux 関連のツイートをすると結構反応をくれる公式アカウントです。
GitLab CIのjobの実行時間改善Tips

[GitLab Advent Calendar 2018](https://qiita.com/advent-calendar/2018/gitlab) 3日目の記事です。

# はじめに
GitLab CIを運用するにあたり、ジョブの実行時間を早くする為に実施した設定の見直し等をまとめます。


# 環境
**GitLab (CE)** : 11.2.3
**GitLab Runner** : 11.2.0

# Tips

## 並列実行数を増やす
Runnerが同時に処理することのできるジョブの数を増加させます。

GitLab Runnerサーバの`/etc/gitlab-runner/config.toml`ファイル内の先頭にある`concurrent`を変更することで設定できます。
デフォルトでは1になっていますが、サーバのスペックと相談して適宜増やしましょう。

下記はジョブの並列処理数を3に変更した例です。

```toml:/etc/gitlab-runner/config.toml
concurrent = 3
```

## cacheを使う
.gitlab-ci.ymlの`cache`で指定ディレクトリ/ファイルをパイプラインやjob間で共有することができます。

例として、下記の定義ではnode_modulesをjob1からjob2に渡しています。

```yml:.gitlab-ci.yml
image: node

job1:
  script:
    - npm install
  cache:
    paths:
      - node_modules/

job2:
  script:
    - npm run hoge-script
  cache:
    paths:
      - node_modules/
    policy: pull
```

<br>

cacheの共有範囲は、`cache:key`で指定が可能です。

### branch毎のcache
```yml
cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - node_modules/
```

### job毎のcache
```yml
cache:
  key: "$CI_JOB_NAME"
  paths:
    - node_modules/
```

cache:key に使える変数は[Predefined variables](https://docs.gitlab.com/ee/ci/variables/README.html#predefined-variables-environment-variables)のみです。

なお、キャッシュを削除したい場合はjobの中に削除する処理を仕込むか、Pipelinesページで**Clear Runner caches**ボタンを押下する。（実際にはcacheの実体が削除されるのではなく、cache:keyの接尾辞をインクリメントする。）


## runnerのif-not-present policyを使う
Runnerのexecutorが`Docker`の場合にjobはDockerコンテナ上で実行されますが、その際に利用するDockerイメージは都度プルされます。
イメージのサイズが大きい場合、プルの時間がjobの実行時間を占める割合が大きくなり得ます。

job実行時のDockerイメージのプルの挙動を定義するのが`pull_policy`です。

<dl>
  <dt>always</dt>
  <dd>常にイメージをプルします。デフォルト。</dd>
  <dt>if-not-present</dt>
  <dd>Runnerサーバ上にイメージが存在するか確認し、存在しない場合のみプルします。</dd>
  <dt>never</dt>
  <dd>常にイメージをプルしません。</dd>
</dl>

pull_policyはRunnerの登録時のオプション`--docker-pull-policy`で指定できます。

```sh
gitlab-runnner register --docker-pull-policy "if-not-present" [other options...]
```

<br>

登録済みのRunnerのpull_policyを変更する場合は`/etc/gitlab-runner/config.toml`の該当Runnerに下記のように設定を追加します。

```toml:/etc/gitlab-runner/config.toml
[[runners]]
  name = "123abc456"
  url = "http://localhost:9000/ci"
  token = "your token"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = true
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    pull_policy = "if-not-present" # 追加
  [runners.cache]
```



## Docker in Dockerを使わない
Docker in Dockerでdocker-composeを利用したジョブの実行などやりがちですが、dindの場合はDockerイメージは上述のif-not-present policyの恩恵を授かれません。
docker-composeではなく、実行するメインのイメージ以外はservicesに列挙することで、if-not-present policyにより各イメージのプルも省略できます。

もちろん、Dockerイメージのビルドなどジョブの中でdockerコマンドが必要なものは適宜dindを使うべきです。


# 最後に
まだまだ速度改善できる手法はたくさんあるかと思いますが、まずはお手頃に設定できるところからの紹介でした。
マシンパワーで全て解決する前に、一度CIの設定・構成を見直してみるのもよいかと思います。

# 参考
 - [GitLab Runner Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section)
 - [Configuration with .gitlab-ci.yml cache](https://docs.gitlab.com/ee/ci/yaml/#cache)
 - [How pull policies work](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work)
 - [GitLab CI Services](https://docs.gitlab.com/ee/ci/services/README.html)
ZenjectのPerformance 

こんにちは、DI好きですか？
僕は大好きです
でも手動で依存関係を注入するのはつらいです…
そこでZenjectに自動的に注入してもらいましょう
[Zenject入門はこちら](https://qiita.com/toRisouP/items/b3d3c43db40857ca4ad4)

でもゲームプログラマーならパフォーマンスが気になりますよね
win standaloneでprofiler測定してみました！（↓はいずれもprofilerの値

[ソースコードはこちら](https://github.com/masak2/zenjectPerformanceTest)

##処理時間 [ms]

| 配列数 | normal | inject*1 | inject*10 |
|:-:|:-:|:-:|:-:|
| 1000  | 1.44  | 15.68  | 52.31  |
| 10000  |  8.27 | 58.15  | 160.36  |

##GC Alloc [KB]

| 配列数 | normal | inject*1 | inject*10 |
|:-:|:-:|:-:|:-:|
| 1000  | 23.5  | 242.5  | 378.8  |
| 10000  | 234.4  | 2252.8  | 3072  |

##まとめ
zenjectを使ってpureC#クラスを作成すると大雑把に10倍以上の時間がかかりますね
inject数が増えれば時間も増える傾向にありますね

GC allocも10倍くらい消費します

ターゲットデバイスに依りますが
要素数が1000を超えると処理落ちするし、GC allocも大幅に増えるのでzenjectを使うより手動DIした方がよさそうです
Raspberry PiでマザーボードのBIOS修復

マザーボードのBIOSをアップデートしたら起動しなくなったのでその時の修復方法。
自分の環境ではおおよそ3000円前後で必要な機材が揃いました。

####起動しなくなったマザーボード
Asrock Z370 Pro4

####購入したもの
・Raspberry Pi Zero WH ケースセット(マルツで2650円　ケースなしなら2000円)
・ジャンパーワイヤー メスメス(千石電商で400円)

####Raspberry Pi Zero WHを選んだ理由
GPIOピンが付いている(Zeroの無印やWだと別途はんだ付けが必要)
WiFiが付いている(リモートで操作が楽)
互換機だとGPIO操作が面倒（情報があまりない）

####既に持っていたが無ければ購入するもの
・8G以上のmicrosd(400円程度)
・電源用USBケーブル(microB 150円程度)

####必要環境
・Raspberry Pi Zero WHをセットアップと操作をするPC
・WiFiルーター

##BIOSチップの確認
目では見えない小ささの刻印。デジカメで撮影して拡大したところMX25L12873Fと判明。
![IMG_0158.JPG](https://qiita-image-store.s3.amazonaws.com/0/318222/4d2ddf6c-629f-b0a7-8282-125cbc825a2e.jpeg)


##BIOSチップとRaspberry Pi Zero WHの接続
最初はテストクリップを用いて接続を考えていたが、マザーボードを見たらBIOSのすぐ左に接続用らしきピンがあったのでそれに接続しました。
(BIOSの左にあるPH1コネクタ)
![IMG_0161.JPG](https://qiita-image-store.s3.amazonaws.com/0/318222/93145e0c-6d73-65a9-a51e-3604a0a50e7d.jpeg)
ピンアサインをネットで調べたが一切情報がない。テスターで調べたところ以下のようなピンアサインとなっているようです。
<img width="312" alt="スクリーンショット 2018-12-03 0.25.14.png" src="https://qiita-image-store.s3.amazonaws.com/0/318222/d3111440-0803-d569-1e55-107bcb267ce3.png">
参考までにMX25L12873Fのデータシート
http://www.macronix.com/Lists/Datasheet/Attachments/7396/MX25L12873F,%203V,%20128Mb,%20v1.2.pdf

###マザーボードとRaspberry Piを接続
GPIOピンアサイン
![Raspberry-Pi-GPIO-Layout-Model-B-Plus-rotated-2700x900-1024x341.png](https://qiita-image-store.s3.amazonaws.com/0/318222/55df3f33-eb7e-9b0b-229b-c9a90dfcecf2.png)
17番にSIO2、VCC、SIO3を接続
19番にSI/SIO0を接続
21番にSI/SIO1を接続
23番にSCLKを接続
24番にCS#を接続
25番にGNDを接続
![IMG_0939.jpeg](https://qiita-image-store.s3.amazonaws.com/0/318222/eb5d8ae5-0763-7fc8-c19f-e7f34d853692.jpeg)


##ROM焼き
操作はrootで。
####SPIを有効にする
```$raspi-config nonint do_spi 0```
要再起動。raspi-configはOSのバージョンで若干の変更があるので通らなかったら調べて下さい(後述のflashromで/dev/spidev0.0のエラーが出たらSPIが有効になっていません)。

####flashromをインストール
```$apt install flashrom```

####BIOS内を消去
Erase。速度を16000に指定。
```$flashrom -c MX25L12835F/MX25L12845E/MX25L12865E -E -V -p linux_spi:dev=/dev/spidev0.0,spispeed=16000```
###書き込み
AsrockのサイトからダウンロードしたBIOSをbios.romにmv後に以下のコマンドを実行。
```$flashrom -c MX25L12835F/MX25L12845E/MX25L12865E -w bios.rom -V -p linux_spi:dev=/dev/spidev0.0,spispeed=16000```

Erase/write done.
Verifying flash...
VERIFIED.
と出力されれば成功。

##注意点
マザーボードのボタン電池は一応外しておきましょう。
内蔵LANのMacAdressが変わります(88-88-88-88-87-88)。
Windowsの再認証が必要となるでしょう。
たぶんシリアル番号やUUIDも飛んでいるのでWindows10でも再認証になる可能性が高いです。
flashromで以前のBIOSのバックアップを取って、新しいBIOSにバイナリエディタで書き換えれば大丈夫らしいですが、自分の時はバックアップが取れなかったので再認証となりました。

##その他
違うマザーボードでもチップ名を調べてテスターがあればなんとかなります。
ピンがない場合やピンアサインを調べるのが面倒だったら、ICテストクリップで直接繋いでしまいましょう。
バイナリ形式のデータを扱うプログラムはテストが必須の環境を作れると感じたお話


[BRIGHT VIE Advent Calendar 2018 - Qiita](https://qiita.com/advent-calendar/2018/brightvie) の3日目の記事です。

もう結論はタイトルの通りなのですが、
そう感じた背景などを簡単に記載できればと思います。


# はじめに

弊社では、医療や介護現場で利用されるデータを様々なシステムと相互に連携するプラットフォーム「[ケアデータコネクト](https://care-data-connect.com)」の開発・運営しております。


クライアントとしては、iOSアプリ/Windowsアプリ/Webブラウザといったプラットフォームにサービスを展開しており、
データ連携の際にBluetoothやNFCを利用してやりとりをすることも多くなっています。

また、サーバサイドではNode.jsを利用しており、
各IoT機器から受信したデータを解析・処理を行っております。

その際に受信するデータとしては下記のような16進数の文字列データが飛び交っており、

```
1480051062039000
02010612FF590080BC3C0100250B3400000000000000
02010612FF0D0082BC280100FFFFFFFF000002000000
```

ロジックの確認やデバッグを行う際も手動で行うには無理があるため、
嬉しいことに必然的にテストコードが必須な状態となっている状況です。


# 扱っているデータ

Bluetooth/NFCでは、体温計や血圧計といったバイタルを主に扱っており、
様々なメーカー様が開発された機器とBluetoothやNFCでデータの連携を行っています。

その他にもナースコールや睡眠センサー、排泄関連やマットセンサー/人感センサー/環境センサーなど様々なシステムとの連携を行っており、
JSON形式のシステムもあれば上記のようなバイナリ形式の文字列を扱ったりと、インタフェースは多種多様です。


## データ連携モジュールの開発

サーバサイドはNode.JS、クライアントはJavaScriptをメインで扱っているので、
基本的には同じ仕組みでテストを実行しています。

また、各IoT機器の仕様書や実際に取得したデータをもとに
機器毎のデータ連携モジュールやテストコードがそれぞれ出来上がっていくため、
サーバ/クライアントをあまり意識せずに共通ライブラリとして構築することで
独立して開発・テストが行えることも連携機器を増やしやすい形になっているのかなと感じています。

# テストの導入とテスト駆動開発の取り組み

テストの導入やテスト駆動開発そのものの方法については検索すればたくさん出てくるのでここでは記載しませんが、
初めてテストを導入される方やテスト駆動開発を行うような方には、
弊社では主にデータを解析するところから着手してもらっています。

バイナリデータなので手動で確認するには確認用のデータを準備するだけでも時間と手間がかかってしまうため、
テストが無いと辛いことを実体験で感じれるところも含めてテスト駆動開発に慣れていくことが出来ると思っています。

また、データ形式のフォーマットが決まっていたり
(2バイト リトルエンディアン形式の西暦データとか何バイト目はこういうデータなど)、
パターンの数も仕様書をベースに把握することが出来るため、
テストを書くにはピッタリの開発内容なのではないかなと感じております。


イメージとしては下記のような入力データを

```
[0x06, 0x69, 0x01, 0x00, 0xFF, 0xE1, 0x07, 0x0C, 0x05, 0x00, 0x20, 0x28, 0x02];
```

バイナリデータを解析・処理することで

```
{ 
   value: 36.1
   unit: "Celsius",
   timestamp: 1512401560000
   getType: "Body"
}
```

というようなJSON形式の値に変換をかけ、JavaScript / Node.JS で処理をするような形でテストケースを準備など行っております。

- 参考
   - [[応用編]JavaScriptでバイナリデータを扱ってみる~Bluetoothから取得した温度データを解析~(3/3)](https://qiita.com/megadreams14/items/dee8fcf50f373a1d755d)


# まとめ

弊社では全てのプロダクトにテストコードが存在しているかと言われるとそうではなく、
最低限重要な部分のみテストコードを導入している程度です。

その中でもこのバイナリデータを解析する部分にはテストが不可欠だったので、
はじめての人でもテストに慣れる、ありがたみを感じれるという意味でも
「バイナリ形式のデータを扱うプログラムはテストが必須の環境を作れるとなぁ」と感じております。


まぁ「そりゃそうだ」という部分もあったり、普段から当たり前のようにテストを導入して開発を行っている場合には全然違う意見になるとも思っていますが、
こんな意見もあっていいのかなと。。。
Visual BasicからC#への変換について

# はじめに
これは、[Visual Basic Advent Calendar 2018](https://qiita.com/advent-calendar/2018/vb)の3日目の記事となります。

Visual Basic と C# の相互変換する方法について書いていきます。

# VB6.0からVB.NETに変換
マイクロソフトは、旧VB製アプリケーションのVB.NETへの移行を容易にするアップグレードウィザードを、Visual Studio 2008までは実装しましたが、Visual Studio 2010 以降からは廃止しました。
よって、Visual Studio 2008 で変換したものを Visual Studio 2010 以降で変換するという二段階のアップグレードが必要になります。

Visual Studio 2008 Express Edition CD(DVD)イメージ版のダウンロードはまだ可能でした。
[Visual Studio 2008 Express Edition with Service Pack 1 Combo DVD](http://go.microsoft.com/?LinkId=9348306)

ここ数年内でVB6からVB.NETへのマイグレーションされた方の記事がありました。

* [VB6からVB.NETへのマイグレーションは成功するか。](http://torutakefusa.hatenablog.com/entry/2016/09/20/143941)
* [VB6 から VB2015.NET へのマイグレーション](http://blog.netandfield.com/shar/2017/04/vb6-vb2015net.html)
* [VB6のソースをVisualStudio2019対応にする方法](https://qiita.com/bass/items/ba81fcb90295ca2f8a94)

# VB.NETとC#の相互変換
## AIによる変換
AIにてプログラミング言語を指定して、VB.NETからCsharpに変換します。

https://www.codeconvert.ai/free-converter

https://zenn.dev/microsoft/articles/convert-vb-to-cs

## オンライン
ちょっとした関数の変換ならオンラインを使うのが手っ取り早いです。
オンラインで結果が返ってこないサイトがあるなかで、下記サイトは結果がすぐに返ってきました。

Telerik Code Converter 
http://converter.telerik.com/

## オフライン
### SharpDevelop
SharpDeveloper Ver 5には変換機能がなくなりましたので、ダウンロードページからSharpDeveloper Ver4.4 をダウンロードしてください。 
https://github.com/icsharpcode/SharpDevelop/releases

Visual Studio 2017で作成したものは、プロジェクトを開いた段階で下記のエラーになり正常に開けませんでした。
 
```
Error loading xxxxxx.vbproj:
The Tools version "15.0" is unrecognized.Available tools versions
are "12.0","14.0","2.0","3.5","4.0".
xxxxxx.vbproj
```

Visual Studio 2015のプロジェクトは開くことができました。
プロジェクトの右クリック→Convert→From VB.NET to　C#
![VB2CSharp.png](https://qiita-image-store.s3.amazonaws.com/0/14053/7fa37b4a-1217-6bbf-1bb3-17b7ecc257f7.png)

【2021/04/15追記】
Visual Studio 2017以降で作成したものは、Solution ファイルを編集すれば開くことができるようになります。

https://qiita.com/wacha/items/64df18569b5b8a5c5bd6

### Language Convertプラグイン
Visual Studio 2015の変換プラグインになります。
https://marketplace.visualstudio.com/items?itemName=LuPaLaPaoloSalamone.LanguageConvert

* [VB→C#変換 VisualStudio2015のプラグイン「LanguageConverter」を使ってみた](https://www.lisz-works.com/entry/vs2015plugin-vb2cs-language-converter)

### dnSpy
オープンソースの.NET のデコンパイルツールです。
https://github.com/0xd4d/dnSpy
MSILのコードをVisual Basic（VB）、C#のどちらのかたちにも戻すことができます。

* [.NET のデコンパイル、デバッグ、ソースの編集も可能なオープンソースのツール dnSpy]
(https://troushoo.blog.fc2.com/blog-entry-312.html)
* [凄すぎて大草原不可避な.NET デコンパイラdnSpyを使ってみる](https://qiita.com/Tokeiya/items/54fbf30cb21c77c05c41)


## 参照
* [VB.NETからC#へのWINDOWSFORMプロジェク移管メモ](http://dai-dai.com/wp/?p=211)
* [VB.NETをC#に変換してみた時の作業メモ](https://do-gugan.com/~furuta/archives/2017/09/vb-net2c.html)

# 最後に
Visual BasicからC#への変換する記事を見つけても情報が古いのが多いので、ここらへんで情報を改めてみました。
Visual Studio 2015までが変換の限度っぽいですね。
[material dynamic branch] X4014 divergent gradient operation error

アドベントカレンダー向けにちょっとマテリアルを調査してたら動的分岐にまつわるコンパイルエラーに遭遇したのでメモっておく

#ブランチブロックと勾配加工
動的分岐を使った最適化をおこなうとX4014のdivergent gradient operationがなんとかなんとかというエラーが出ることがあります。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/223804/4a190ac5-0436-2adb-0e7b-4ab74d54c223.png)


大雑把に言ってサンプラーに渡されるUVの値をブランチブロック内部で加工するとこのエラーが発生します。
加工するということはサンプラーがMIPMAPを選択するときに使う勾配が変化してしまうためです。


##BiasでUVに加工なし > OK

	float4  Local3 = ProcessMaterialColorTextureLookup(
		Texture2DSampleBias(Material_Texture2D_0,Material_Texture2D_0Sampler,Parameters.TexCoords[0].xy,View_MaterialTextureMipBias)
	);


##BiasでUVに加工あり > Compile error

	float4  Local3 = ProcessMaterialColorTextureLookup(
		Texture2DSampleBias(Material_Texture2D_0,Material_Texture2D_0Sampler,Parameters.TexCoords[0].xy+float2(1.0f,0.5f),View_MaterialTextureMipBias)
	);


##レベルを直接指定するもの(SampleLevel) > OK

	float4  Local7 = ProcessMaterialColorTextureLookup(
		Texture2DSampleLevel(Material_Texture2D_0,Material_Texture2D_0Sampler,Parameters.TexCoords[0].xy+float2(1.0f,0.5f), float (Local6))
	);

##まとめ
1.シェーダー内部で動的分岐を使う場合は、サーフェスに使う場合はブロック内部でUVを加工せずに使う
2.ポストプロセスなどのSampleLevelを使って直接指定するものは気にしないでOK

サーフェス用のマテリアルで動的分岐を使う場合はちょっと気を付けないといけない。
/etc/nagios/check_diskの引数省略

#???

以下の項目がわからなかった

```/etc/nagios/nrpe.cfg
command[check_disk]=/usr/lib64/nagios/plugins/check_disk 80 95
```

/etc/nagios/check_diskにおいて、対象フォルダの引数がない時は、
各パーティション各々を対象として、チェックを実行する。

```
[root@t-tona ~]# df -Th
ファイルシス   タイプ   サイズ  使用  残り 使用% マウント位置
/dev/vda2      ext4        20G  7.7G   11G   42% /
devtmpfs       devtmpfs   234M     0  234M    0% /dev
tmpfs          tmpfs      244M     0  244M    0% /dev/shm
tmpfs          tmpfs      244M   17M  228M    7% /run
tmpfs          tmpfs      244M     0  244M    0% /sys/fs/cgroup
tmpfs          tmpfs       49M     0   49M    0% /run/user/1000
```
これの各々。tmpfsについてはわからない

引数が数字のみで指定されている場合は、使用している量の%表示を表すので、
今回の設定だと、80%以上の時にWarning, 95%の時にCritical

#...
ややこしいからちゃんと -w とか -c とかつけて書いてよ！！！
IQ1なのでPhotoshopの代わりにOpenCVを使う

# はじめに #
　この記事は[IQ1 Advent Calendar 2018](https://adventar.org/calendars/3160)の3日目です。
　私の大学はAdobeと包括契約しているので，Adobeの色々なソフトを無料で使うことができます．ですが，私はIQが1しかないのでそれらの高級ソフトを使いこなすことができません．そこで，画像をちょっと編集したいなぁ......と思った時，Photoshopの代わりにOpenCVでやることを思いつきました．
　というわけで，とても簡単な作業だけですが今まで書いたコードを供養します．ちなみに全部Pythonです．簡単な作業なので．
#画像の拡大・縮小#
　そもそもIQの高い皆さんはこんなことにPhotoshopすら使わないと思いますが．今から載せるコードたちは全て以下の関数を省略しています．

```python3
# 最初に画像の読み込み
src = cv2.imread("hode.jpg")

# 最後に画像の出力
cv2.imwrite("fuga.jpg", dst)
```

　画像のサイズを変更するとき，サイズを直接指定する場合と倍率を指定する場合があります．

```python
# サイズを直接指定する場合
width = 640
height = 480
dst = cv2.resize(src, (width, height))

# 倍率で指定する場合
dst = cv2.resize(src, None, fx=2, fy=2)
```

# 画像のトリミング #
　OpenCVでは画像は行列として解釈されるので，長方形のトリミングなら簡単です．

```python
# 行列なのでshapeは(縦，横，色チャンネル数)の順に並んでいるので注意
h, w = src.shape[0:2]

#各端を指定
left = w//3
right = w
top = h//2
bottom = h

dst = src[top:bottom, left:right]
```

　他の形はIQ1だと数式で記述するしか思いつかなかったので，その中でも一番簡単な円だけ載せます．

```python
# 切り取るサイズの背景を用意
r = 200
dst = np.ones((r, r, 3), dtype=np.uint8) * 255

# 元画像からコピーする
h, w = src.shape[0:2]
center = (h//2, w//3)
for y in range(h):
    for x in range(w):
        if np.sqrt((y-center[0])**2 + (x-center[1]**2)) <= r:
            dst[y][x] = src[y][x]
```

追記：srcと同じ黒画像を作成して任意の場所に図形を描く関数で白い図形を描いてcv2.bitwise_and()でマスクすればいいことに気付きました。IQ2になれましたね。

#画像のグレースケール化#
　もはやノーコメント

```python
dst = cv2.cvtColor(src, cv2.COLOR_RGB2GRAY)
```

#画像の結合#

　大きな背景画像にペタペタと貼っていく感覚です。

```python

src_list = #画像を複数用意

# 縦×横
h, w = src.shape[0:2]
layout = (3, 4)

dst = np.ones((h*layout[0], w*layout[1]), dtype=np.uint8)

for y in range(layout[0]):
    for x in range(layout[1]):
        dst[h*y:h*(y+1), w*x:w*(x+1)] = src_list[y*layout[1]+x]
```

　ここでIQ1なお知らせです。私はモバゲー版アイドルマスターシンデレラガールズにて、アイドルプロデュース7thアニバーサリーを走らなくてはいけないため、この記事はここで打ち切りとさせていただきます。12月10日より追記の予定です。それではみなさんさようなら。安部菜々をこれからもどうぞよろしくお願いいたします。
モジュールバンドラで生成したファイル群をGithub PagesにCircle CIでデプロイする手順

# 自動Deployしたい

Webpackなどのモジュールバンドラで生成したものをGithub Pagesに公開するとき、手元のソースでビルドすると、うっかりスタッシュせずに試し処理やデバッグ処理を入れたままにしてしまうことがあります。

また、ソースを修正したけどビルドを忘れてたみたいなことも。

pushしたソースをそのまま自動でビルドしてデプロイしてくれると便利です。

# 手順

Github リポジトリは既にあるとします。

## アプリケーションを用意

VueCLIでもNuxt.jsでも素のWebpackでも何でもいいので `npm run build` を実行すると dist ディレクトリに出力するようにします。

## npm パッケージ `gh-pages` をインストール ＆ 設定

Github Pagesを公開するにはいくつか方法がありますが、今回は ph-pages ブランチにpushする方法を使います。

その場合 npm パッケージの `gh-pages` を使うととても簡単です。

```shell
npm install gh-pages --save-dev
```

`package.json` の scriptsにdeploy用コマンドを追加します。

```json
  "scripts": {
    "build": "(distに出力する処理)",
    "deploy": "npm run build && npm run deploy-only",
    "deploy-only": "gh-pages -d dist -m \"Built from commit $(git log -n 1 --format=%h) [ci skip]\"",
    ...
  },
```

gitコメントに`[ci skip]`を入れているのはgh-pagesへのpushをさらにビルドしようとさせないためです。

「Built from commit〜」の部分についてはこちらを御覧ください。
[npm パッケージの gh-pages 利用時 コメントに gitのcommit idを入れる](https://qiita.com/boushi-bird@github/items/7ad0cae244775b57f98f)

これらをcommitし、pushします。

## Circle CIにプロジェクト作成

既に作成済みの場合は飛ばしてください。

1. https://circleci.com/dashboard へ行く
2. `ADD PROJECTS` から対象リポジトリの `Set Up Project` を押す。
3. [Operating System]はLinux 、 Language は Node を選択
4. `Start Building` を押す。

これでプロジェクトが登録され、ビルドが走ります。まだ設定ファイルがないのでビルドエラーになりますがそれで大丈夫です。

## Circle CIからpushさせるために Github に write access 可能な Deploy key を設定する

こちらの記事を参照してください。

[Circle CI で Github に write access 可能な Deploy key を設定する](https://qiita.com/boushi-bird@github/items/6b6eb1d1ed6f6d3341e4)

## Circle CI用設定ファイルを追加する。

既にある場合はこれ相当の設定を追記してください。

`.circleci/config.yml` ファイルを追加し、下記のようにします。

```
version: 2
jobs:
  build:
    docker:
      - image: circleci/node:10
    environment:
      GIT_AUTHOR_EMAIL: circleci@example.com
      GIT_AUTHOR_NAME: Circle CI
      GIT_COMMITTER_EMAIL: circleci@example.com
      GIT_COMMITTER_NAME: Circle CI
    working_directory: ~/repo
    steps:
      - checkout
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package-lock.json" }}
          - v1-dependencies-
      - run: npm install
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package-lock.json" }}
      - run: npm run deploy
```

最小の構成なので他に色々やりたい場合は[公式ドキュメント](https://circleci.com/docs/)を参考にいろいろ設定しましょう。

これをpushします。

## Circle CI のビルドとデプロイが成功するのを待つ

待ちます。

## Github 側の設定

`gh-pages`ブランチへのデプロイが成功したら Github Pages へ反映されているはずです。

反映されていない場合は Github側の設定を見直します。

`https://github.com/(ユーザ or 組織)/(対象リポジトリ)/settings` へ行き、GitHub Pages の項を見ます。

Sourceが `gh-pages branch` になっていなければそれに変更し`Save`ボタンを押します。

# ソース

https://github.com/boushi-bird/gh-pages-deploy-example
クラウドプロバイダーのKubernetesに対するスタンス

#きっかけ
Amazonはコンテナ管理サービスとして既にECSがあるのに、なぜEKSでKubernetes対応したのかな、と思い。
Amazon、Google、MicrosoftそれぞれのKubernetesに対するスタンスを調べてみました。

#Google
KubernetesはもともとGoogleが開発したものですし、がっつりKubernetes推しという印象です。
Istio,Knative中心のインタビューですが、Googleのスタンスがよくわかる記事です。
[Googleのウルス・ヘルツル氏に聞いた、「IstioやKnativeで目指すのはクラウドのアンロックイン」](http://www.atmarkit.co.jp/ait/articles/1808/28/news036.html)
>（クラウドベンダーは、）実装の優劣を競うことはできる。だが、運用APIは統一されるべきだ。このため、運用APIはオープンソースでなければならない。

>クラウドは未来永劫、それぞれが異なるものであり続ける。GCPのプロダクトでいえば、BigQueryやCloud Spannerはそれぞれがユニークな機能を果たしており、オープンソースではない。こうしたプロダクトで差別化を図っていくのは当然のことだ。私たちが注目しているのは、「クラウドにおけるAPIの80％が、同じような機能を果たすにもかかわらず、異なっている」という事実だ。

運用部分では勝負しないということのよう。運用のところでロックインされてしまうと、移行のハードルが高くなりAWSのシェアを奪えませんからね。ユーザーとしてもベンダーロックインは避けたいところ。
また[オンプレミス版GKE](https://cloud.google.com/gke-on-prem/)も発表されておりハイブリッドクラウドという面でも、Kubernetesは大きな役割を果たしています。企業としてはクラウドへ持ってけないものがある中で、クラウドとオンプレ両方を一元管理できるのは運用負荷を減らせるのでうまみがあります。企業のクラウド利用のハードルを下げられますので、Googleとしても好都合です。

#Amazon

まさにの記事を発見しました。
[AWSはなぜ、ECSがあるのにKubernetesのサービスを始めたのか、コックロフト氏に聞いた](http://www.atmarkit.co.jp/ait/articles/1806/11/news029.html)

>データセンターを自動化するための汎用的な手法として、今注目されているのがKubernetesだ。一方ECSはAWS上でしか使えないため、こうしたニーズに全く対応できない。

>Kubernetesを使ったサービスの提供については、2つのことが言えると思う。
>1つは、クラウドと同じことをデータセンターでやりたいというニーズだ。こうした場合、クラウドとオンプレミスで同一のものを使えるということが要件になる。
...
一方で、（新しいアプリケーションを）構築するスタートアップ企業や開発者のことも考える必要がある。こうした人たちは、ホットな技術に着目し、自身のアプリケーションを開発する傾向が強い。この「ホットな技術」として浮上したのがKubernetesと、おそらくサーバレスだ。
　
つまり、Kubernetesを採用したサービスをAWSが生み出した理由は、「ポータビリティ（可搬性）」と機能性だ。

そのまんまですね。
ハイブリッドクラウドと、スタートアップ企業を意識したため、Kubernetesにも対応したとのことです。こういったニーズに素早く答えるところがAmazonの強いところです。

#MicroSoft
こちらの[記事](https://gihyo.jp/admin/column/newyear/2018/container-and-cloud)にあるように、Googleの後にKubernetes対応したのがMicrosoftです。Kubernetesがデファクトスタンダードとなることを後押ししました。
Kubernetesのツールをつくっている[Deisという企業を買収](https://jp.techcrunch.com/2017/04/11/20170410microsoft-acquires-container-platform-deis/)しており、本気度が伺えます。

[Azure Kubernetes Serviceに関するMicrosoftのGabe Monroy氏とのQ&A - Build 2018にて](https://www.infoq.com/jp/news/2018/08/build-2018-gabe-monroy)
>Kubernetesサービスを選択する時に忘れてならないのは、すべてがKubernetes上で動作する訳ではない、ということです。システムはデータストアやキュー、ファンクション、他のサービスなどにも依存していますが、それらの多くはKubernetes上で実行されるものではないのです。ですから、Kubernetesサービスにおいて最も重要な差別要因は、それが動作するクラウドプラットフォームであると言えます。

#まとめ
Google,Microsoft,AmazonだけでなくAlibabaやIBMなどもKubernetesサービスを提供しており、Kubernetesがデファクトスタンダードであることは間違いありません。Amazonもこの流れには逆らうことはできないでしょう。クラウドプロバイダーとしてはKubernetesに対応しつつ、自社の周辺サービスとの連携を深めることで、差別化を図る流れになりそうです。
npm パッケージの gh-pages 利用時 コメントに gitのcommit idを入れる

npm パッケージ [gh-pages](https://github.com/tschaub/gh-pages) 利用時に
どの commit から作られたかをわかりやすくするために commit id をgitコメントに入れる方法です。

```shell
gh-pages -d dist -m "Built from commit $(git log -n 1 --format=%h)"
```

`Built from commit 51679f9` のようなコメントになります
スクリプトブロックの便利な使い方

本エントリは[PowerShell Advent Calendar 2018 ](https://qiita.com/advent-calendar/2018/powershell)の5日目の記事です。

Advent Calender自体初めての参加です。宜しくお願い致します。
気軽によく使うTipsを簡単に紹介します。

###スクリプトブロックについて
スクリプトブロック{}は**コマンドを事前に格納しておいて実行時に評価させることができる**仕組みです。実際にスクリプトブロックを実行する時は「&」か「.」を頭に記入することで実行できます。

以下のような感じです。

```
PS C:\Users\TASK-PC> {Write-Host "Hello World!!"} #　これだけではダメ
Write-Host "Hello World!!"
PS C:\Users\TASK-PC> & {Write-Host "Hello World!!"} # 「&」に後ろのスクリプトブロックを評価させることがポイント
Hello World!!
PS C:\Users\TASK-PC> . {Write-Host "Hello World!!"} # 「.」でもできる
Hello World!!
PS C:\Users\TASK-PC>
```


###よく利用する方法
この性質を利用すると、
リアルタイムで様々なコマンドを評価できるので汎用性が高いです。

以下は今回の使い方を利用していない例で、コマンドを通常通りに変数格納しただけです。
この場合は変数を呼び出しても、格納時の時刻が表示されるだけです。

```
PS C:\Users\TASK-PC> $Today = (Get-Date).ToString("yyyy/MM/dd HH:mm:ss")
PS C:\Users\TASK-PC> $Today
2018/12/03 00:35:42
PS C:\Users\TASK-PC> $Today
2018/12/03 00:35:42
PS C:\Users\TASK-PC> $Today
2018/12/03 00:35:42
PS C:\Users\TASK-PC>
```

これを最初の変数格納時にスクリプトブロックを利用しておくと、
毎回変数呼び出しのたびに実行してくれるのでリアルタイム日時を出力できるようになります。
「&」と「.」を頭につけておくことだけは忘れないようにしてください。

```
PS C:\Users\TASK-PC> $Today = { (Get-Date).ToString("yyyy/MM/dd HH:mm:ss") }
PS C:\Users\TASK-PC> & $Today
2018/12/03 00:39:02
PS C:\Users\TASK-PC> & $Today
2018/12/03 00:39:06
PS C:\Users\TASK-PC> . $Today
2018/12/03 00:39:12
PS C:\Users\TASK-PC>
```

ループ処理時にループのたびにリアルタイムで値を可変させたい場合などに利用できますから、例に挙げたような時刻系(サーバ起動時間とか)や、インベントリ情報系(SUした後のユーザIDとか)でよく活用しています。以下が処理例です。

```
PS C:\Users\TASK-PC> $Today = { Write-Output (Get-Date).ToString("[yyyy/MM/dd HH:mm:ss(ddd)]") }
PS C:\Users\TASK-PC> 1..5 | ForEach-Object { Write-Host (& $Today) "Loop Count is $_";Start-Sleep -Milliseconds 5000 }
[2018/12/03 00:55:52(月)] Loop Count is 1
[2018/12/03 00:55:57(月)] Loop Count is 2
[2018/12/03 00:56:02(月)] Loop Count is 3
[2018/12/03 00:56:07(月)] Loop Count is 4
[2018/12/03 00:56:12(月)] Loop Count is 5
PS C:\Users\TASK-PC>
```
ループ構文内でわざわざコマンドを毎回書く必要もなく、
変数定義時の一回だけ書いて、あとは「&」か「.」で呼び出せばよいのでスッキリした書き方ができて愛用しています。

関数にするまでもない簡単なコマンドを呼び出したい時にご活用ください。


簡単ですが以上です。
合成数列の和アドベントカレンダー PHP 編

[合成数列の和アドベントカレンダー Advent Calendar 2018](https://qiita.com/advent-calendar/2018/composite-number) の 3 日目です。

# ルール
- 入力として正の整数 N を与えたら 4 から始まる [合成数](https://ja.wikipedia.org/wiki/%E5%90%88%E6%88%90%E6%95%B0) の数列の 1 番目から N 番目からの合計を出力してください
- N は最大で 100 とします

# プログラム(PHP)

```php:composite.php
<?php
// Extension load check
if (!extension_loaded('gmp'))
{
    die('PHP extension gmp is not loaded.');
}

$in = (int)$_SERVER['argv'][1];
$num = 4;
$composites = $sum = 0;
while ($composites < $in)
{
    if (!gmp_prob_prime($num))
    {
        $composites++;
        $sum += $num;
    }
    $num++;
}
print $sum;
```

※素数判定に [GMPモジュール](http://php.net/manual/ja/book.gmp.php) を使用しています。

# 出力例
```
$ php composite.php 2
10
$ php composite.php 4
27
$ php composite.php 10
112
$ php composite.php 100
7059
```

# メモ

この問題は [ずんだ問題](https://qiita.com/tbpgr/items/3a4169b370f1a317ece0) の番外編です
優秀な技術者を追い出してしまった事例3 - 技術を買えばいいは本当か -

副題をつけました。

これも優秀な技術者を追い出してしまった事例だ。

## ある書籍に書かれた事例（固有名詞・技術名は伏せ字にします。）

### エンジニアが「大量脱走」

「先に説明した研究開発の本丸、〇〇研究所では、先進△△や□□を担当する部署の若手技術者が、コスト削減ばかりを追求する本社の経営方針に反旗を翻して、大量に退職する事態が発生した。この『大量脱走』が先端分野でのリソース不足につながり、先に述べた▽▽性能テストで最下位という結果と大きく関係していることは想像に難くない。」

「この事態に焦った□□は、社内公募で◯◯の技術者を公募するも、それども足らずに◯◯県や〇〇県内などで、〇〇関連のエンジニア中途採用セミナーを開催。その回数は１６年中だけで１０回以上になるという。」

『◯◯の技術は、他社から買えばいい、と本社から指示が出ました。技術への夢を語る管理職は周囲を見てもほとんどいませんし、みんなエクセルでコスト計算をしているような感じ。夢がないわけです。□□で仕事をするのが馬鹿らしくなって辞めました。』

「エンジニアの多くは、次世代技術や新(製品)の開発といった前向きで夢のある仕事ではなく、リコールの事後処理に忙殺された。」

---

固有名詞や技術名を伏せ字にした理由は、同じようなことが起きっていないか身近な問題として捉えてもらいたいからだ。

## 技術を買えばいいは本当か

日本の従来型企業の多くは、キーとなる技術を開発している人に対する本来的な市場価値よりも低い賃金で雇用しようとする傾向がある。その状況の中で、将来的な賃金上昇の可能性が見えず、雇用削減の可能性だけが見えてくる状況では、無理して今の企業に居続ける理由をなくしてしまっているのです。

### 買うのでさえ評価できる技術者が必要
「〇〇の技術を他社から買えばいい」とするためにするには、〇〇の技術を適切に評価できる技術者がいなければなりません。また、販売元の言いなりにならないためには、代替候補を持っておく必要があります。自分で開発できるだけの力量があったときにだけ、適正な価格で購入することができます。
　しかし、「〇〇の技術を他社から買えばいい」という多くの人々は、そのことに無自覚なので、その分野の技術者を追い出してしまって、使えない技術を高く買い込んでしまったりするのです。

### 開発を重ねてきた技術者は、他社の技術の良さと弱点とを評価できる。

その分野で開発を重ねて結果を出してきた技術者は、他社の技術の良さと弱点とを評価できます。どのような評価をその技術分野でしなければならないのか、評価方法を身に着けていますから、他社の技術であっても、自分が開発してきた技術と同様に評価できます。
　その評価にかかる時間が、圧倒的に短くなります。

　ときとして、開発を重ねてきた技術者は、その分野の事業化を推進する力になることもあります。

- どのような応用分野があるのか、
- 利用する側の技術者が何を気にするか、
- どのようにしたら利用者の技術者たちを満足させることができるのか


技術者に事業のマネジメントができないなどという決め付けは、百害あって一利なしです。



### 複数の候補の技術から選択できる能力が必要
ある目的を達成するための技術は、複数の候補があるのは普通です。その中で適切な技術を選ぶのは簡単なことではないのです。仕様書と見積りがあれば足りるものではないのです。仕様書で言っているほどの性能が実は出ていないことが得てしてあるものです。

### 嘘でなくても適切ではない評価に騙されるな
　技術を売りこんで契約をとろうとする側は、捏造した評価結果を持ち込むことがありうるのだと自覚しなければなりません。
　嘘ではないけれども正しくはないことが山ほどあるのです。ユーザーが自覚していない「たちの悪い」条件は抜いたデータセットは除外したデータで評価した結果を使えば、とてもいいもののようにユーザーは勝手に思い込んでしまうのです。

### 欲にかられると適切な評価ができなくなる
技術を持つとする会社を買う際にも同じようなことが起こります。買うとうまくいくはずだという欲目で物事を見ていますから、実はそれほどの技術を持ち合わせていないかもしれないという可能性について軽視してしまうのです。しかも、その案件を提案している人は社内の実力者であるはずです。そうすると、それがうまくいかないかもしれないという指摘は、社内の中で無視される運命にあるのです。

そのような組織的な欠点が、大手電機メーカーの海外の発電事業の買収などに現れているのです。

### 他国の企業の技術・製品を購入する際には、政治リスクも考えにいれなければならなくなってしまっている。
2018年下半期の動向としては、こういった状況だ。
- ファーウェイ社に対する一連の規制が生じてきている。
- 画像認識技術についても、[Googleは顔認識技術を外部に売らないと決定…悪用を防ぐため](https://jp.techcrunch.com/2018/12/15/2018-12-14-google-agrees-not-to-sell-facial-recognition-tech-citing-abuse-potential/)


安易に考えないことが必要になってきている。

---
追記

手持ちの選択肢がなければ、相手と交渉する際の手持ちのコマがなくなる。
交渉する際の手持ちのコマを持ちあわせていないことが相手に伝わると、
相手に足元を見られることになってしまう。

だから、社内に力量を持ちわあせた技術者を抱えておく必要がある。
Game A Week４週目（完成しなかった。。。(´；ω；`)）

**Game A Week４週目です**
４週目は時間があまりなく最終日当日に作り始めるとかいうことになってしまったのでゲームとかでよくあるドアの開閉シーンを作ろうと思って何個かサイトを参考に作ってみたのですがエラーが吐きまくりでそれも解決しなくて。。。
はじめてanimetionの機能使ったので初めて学ぶことが多かったです
詳しくは明日書きます。
[AWS]Elastic IPアドレスに課金されるケース（小ネタ）

# はじめに
大した話ではありませんが、AWSマネジメントコンソールでお試しでインスタンスを作ったり消したりしている人にとってのあるあるネタ。

# Elastic IPアドレスについて
Elastic IPは簡単に言うと固定のIPアドレスです。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

EC2ではDHCPによる動的IPアドレスを使用するのがデフォルトですが、インターネットで接続するためには固定アドレスが必要となります。
（余談ですが、Elastic IPアドレスを割り当てるのにもDHCPを使用しているみたいです）

そして、Elastic IPアドレスはやや特殊な課金方式を採っていて、インスタンスに割り当てられていない（停止中含む）場合に課金が発生します。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/elastic-ip-charges/

オンデマンドインスタンスはOS停止していれば課金されない話を現場でもしていたので、書籍を読みながら色々作ってインスタンス停止だけしていたら地味に料金が発生してプチ驚いた、という話でした（ただし、アドレス1つぐらいなら本当に微量）
ちなみにEBSやAMIも持っているだけでお金がかかるタイプのリソースなので、使い終わって放置する際に気をつけましょう（2敗）