OmniAICreator/Qiita-1.07M huggingface dataset:
【リファクタリング】メソッドの抽出手順

## メソッドの抽出の目的

1. メソッドの抽出し、メソッド名を正しく命名することで、そのメソッドの目的を明確にする

2. メソッドの粒度を短くすることでメソッドの再利用性を高める

3. メソッドの粒度を短くすることでオーバーライドのしやすさを高める

特に1番が重要です。長すぎるルーチンは理解するのにとても時間を要します。

一方、メソッドの抽出を行い、適切なメソッド名を命名することで、 **内部の実装を見なくとも読み進めていくことが可能** となります。

## メソッドの抽出を行うべきコードとは？

同一メソッド内に下記のような箇所が複数存在する場合はメソッドの抽出を検討するべきです。

- コメントが無いと何をしているのか理解できない処理
- 条件分岐やループによってネストが深くなっている処理

抽出するべき処理を探す場合には、メソッドの物理的な長さに着目するのではなく、メソッド名とメソッド本体の意味的な距離の長さに着目するべきです。

## メソッドの抽出の手順

実際にメソッドを抽出すべき処理を見つけた場合、どのような手順で行えばよいでしょうか。

下記に手順を記します。

1. 新たなメソッドを作成し、メソッドの目的に合わせて適切なメソッド名を命名する。
   (※適切なメソッド名のつけ方については『[リーダブルコード](リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)   Dustin Boswell https://www.amazon.co.jp/dp/4873115655/ref=cm_sw_r_tw_dp_U_x_OaYSCbX5PDZZJ)』を読むことをお勧めします！)

2. 抽出対象の処理を手順1で作成した抽出先のメソッドにコピーする。

3. 抽出対象のコード内で一時変数が存在する場合、抽出対象のコード内だけで使用されているかを確認する。そうでなければ抽出先の一時変数として定義する。

4. 抽出対象のコードが抽出元メソッドのローカルスコープ変数を変更するかを調べる。変更する変数が１つだけ存在する場合はそれを抽出先の戻り値とする。変更する変数が複数ある場合は、このままの状態でメソッドを抽出することはできない。(一時変数の分離を適用する)

5. 抽出対象のコードがが抽出元のローカルスコープ変数を使用してるかを調べる。使用している場合それらを抽出先メソッドの引数とする。

6. 上記手順でメソッドの抽出が完了。一度コンパイルしてエラーが発生しないことを確認する。

7. 抽出対象のコードを抽出したメソッドで置き換える。

※これらの手順はIDEを使用している場合は簡単に行うことができます。
eclipseの場合は抽出対象のコードをドラッグで選択して「Ctrl + Shift + M」
ただし期待通りに抽出が行えたかを目視で確認してください。

## 参考

- [新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)   Martin Fowler]( https://www.amazon.co.jp/dp/427405019X/ref=cm_sw_r_tw_dp_U_x_ODXSCb3SE9GJC)
Rubyで例外を捕捉する

### 例外を捕捉して処理を続行する場合
もっとも単純な構文

```ruby.rb
begin
 # 例外が起きうる処理
rescue
 # 例外が発生した場合の処理
end
```

### 例外オブジェクトから情報を取得する
Rubyでは発生した例外もオブジェクトであるため、例外オブジェクトのメソッドを呼び出すことで、発生した例外に関する情報を取得することができる。代表的なものとして例外発生時のエラーメッセージを返すmessageメソッドとメソッド呼び出し履歴を配列で返すbacktraceメソッドがある。
こんな感じの構文

```ruby.rb
begin
 # 例外が起きうる処理
rescue => 例外オブジェクトを格納する変数(e,exがよく使われる)、捕捉したい例外クラス
 # 例外が発生した場合の処理
end
```
具体例

```ruby.rb
begin
 1 / 0
rescue => e
 puts "エラークラス: #{e.class}"
 puts "エラーメッセージ: #{e.message}"
 puts "バックトレース ----"
 puts e.backtrace
 puts "----"
end

#こんなエラーが帰ってくる
エラークラス: ZeroDivisionError
エラーメッセージ: divided by 0
バックトレース ----
(irb):2:in '/'
(irb):2:in 'irb_binding'
省略/irb:11:in '<main>' 
```


### 例外クラスの継承関係

Rubyではすべての例外クラスはExceptionクラスを継承している。その下にたくさんのサブクラスがぶら下がっている。ここで重要になるのがExceptionクラスの下にあるStandardErrorとそれ以外の例外クラスの違いを理解すること。
StandardErrorは通常のプログラムで発生する可能性の高い例外を表すクラスです。これのサブクラスとしてNoMethodErrorやZeroDivisionError、StandardErrorクラスが含まれている。
StandardErrorクラスを継承していないものは、通常のプログラムでは発生しない特殊なエラーが起きていることを表す。
rescue節に何もクラスを指定しなかった場合に捕捉されるのはStandardErrorとそのサブクラスです。StandardErrorを継承していない例外クラスは捕捉されない。

```ruby.rb
begin
 # 例外が起きそうな処理
rescue
 # StandardErrorとそのサブクラスのみ捕捉される
end
```
Node.js,Expressメモ③

今更Node.jsとExpressかよ!と突っ込まれるかもしれません。こんにちは。
rete.jsを使いたいためにExpressのチュートリアルを進めていますがどう活きるかまだわかりません。


今回はこちらのPart3をやります。
https://developer.mozilla.org/ja/docs/Learn/Server-side/Express_Nodejs/mongoose

Part3にしてデータベース。楽しみです。

# データベースの選定
Expressも他のwebフレームワークと同様にいろいろ選択できるみたいですね。
そのまま使うかODM/ORMを選択も必要そうです。
推奨としては速度優先じゃないならODM/ORMを使った方が開発・保守コストを削減できるから
ODM/ORMの方がいいんじゃないとのこと。
個人的にも速度を犠牲にしても拡張性が欲しいのでそちらを選択したいところです。

NPMパッケージでは多数のODM/ORMを利用できるようです。

チュートリアルの選択はMongooseというもので、書いている時点で最も人気のある
ODMのようです。
データベースはMongoDBを使うとのこと。
NoSQL系のデータベースは触ったことがないのでそういう意味でも楽しみです。


# MongooseとMongoDB
Nodeコミュニティでは特に人気のある組み合わせみたいです。
それは使用感がJsonに似ていて親しみやすいから、ということみたいですね。
インストール
mongoose
`npm install mongoose`

mongoDB
https://www.mongodb.com/download-center/community
ローカルインストールとクラウド(Azure, GCP, AWS)があります。
クラウド版使いたいなぁと思いつつとりあえずwindows版を。


# モデル設計
チュートリアルでは書籍のライブラリアプリを作成するようです。
そのために必要なデータの洗い出しから始まっています。

細かく書くのは大変なのでモデルだけ。
・Book
　本のタイトル、著者※1、ISBM、ジャンル※2 など
・BookInstance
　本のオブジェクトにステータスをつけたもの
・Author(著者※1)
　性、名、誕生日、死亡日など
・Genre(ジャンル※2)
　名前など

本は同じものが複数存在するからそれぞれにステータスを変えれるようにBookInstanceがあるんですね。


# mongoDBデビュー
上で書いた通りmongoDBは初めてさわります。言葉の概念もよくわかりません。
データベースを作成と同時にコレクションを作ってくれといわれてもよくわからないのですが
検索してみたら要するにsqlでいうところのテーブルなんですね。
ではBookというコレクションを最初に作成してみました。

そしてなんとここからチュートリアルが翻訳されていませんw


# mongooseを読み込む。mongoDBに接続する。
ここからは斜め読みで進めてみます。

app.jsにdb周りの記述を追加します。
`var app = express();`の下に追加します。
`
var mongoose = require("mongoose");
var mongoDB = "mongodb://localhost/<database_name>"; //portはいらないんだー。と思いました。 
mongoose.connect(mongoDB);
mongoose.Promise = global.Promise;
var db = mongoose.connection;
db.on("error", console.error.bind(console, "MongoDB connection error:"))
`
# モデルの作成
モデルはどこに作るんだろうとみたら別のjsとしてつくるみたいですね。
ふむ。
わかりやすいです。
が、jsの文字列の扱いがなれません。。括らなくてもOKなの？

`XXXSchema.virtual(名前).get(function(){return XXXXX})`

これはレコードが追加された瞬間に処理されるのでしょうか。問い合わせがあった時に処理されるのでしょうか。


#仮データを入れる
チュートリアルの方でコードを用意してくれているみたいです。
populatedb.jsをルートに置いてnodeコマンドで実行するみたいです。
そのjsの中でasyncというモジュールを使っているのでインストールしときます。
`npm install async`

`node populaterdb <database_name>`
実行したらだだだっとデータが入りました。

| name| count| size|
|:----|-----:|----:|
| authors| 5| 99.4B|
| bookinstance|11|133.5b|
|books|7|405.6B|
|genres|3|53.7B|

順調順調。
つづく。
CircleCIでgithub pagesに自動デプロイする

# 動機

[作っているアプリケーション](https://github.com/sterashima78/vue-webpage-builder) のデモページをgithub pages で公開しているが、デプロイ作業を自動化したかった。

# 概要

- gh-pages ブランチで公開する方式
- ビルドタスクで dist ディレクトリにアプリケーションを生成する
- [push-dir](https://www.npmjs.com/package/push-dir) でデプロイする
- master ブランチ以外は無視するようにする

# 設定

## package.json

```json

{
     :
   <snip>
     :
  "scripts": {
       :
     <snip>
       :      
    "deploy:github": "cross-env DEPLOY='github' run-s build send:github",
    "send:github": "push-dir --dir=dist --branch=gh-pages --message='[ci skip] Deploy'"
  },
    :
  <snip>
    :
}
```

## config.yml

```yaml

version: 2
jobs:
  build_deploy:
    docker:
      - image: node:10
    steps:
      - checkout
      - add_ssh_keys:
          fingerprints:
            - "xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx"
      - run:
          name: Install Node dependencies
          command: npm install
      - run:
          name: Deploy
          command: |
            git config --global user.name "Circle CI"
            git config --global user.email "<>"
            npm run deploy:github
workflows:
  version: 2
  deploy:
    jobs:
      - build_deploy:
          filters:
            branches:
              only: 
                - master
```

## 説明

- deploy:github タスクは buildタスクと send:github タスクを順次実行する
    - buildタスクはビルドされたアプリケーションが dist ディレクトリに配置される
    - send:github タスクで github pagesへのデプロイをする
- push-dirコマンド
    - --dir：デプロイ対象ディレクトリ
    - --branch：デプロイ対象ブランチ
    - --message：コミットメッセージ
        - デプロイした dist ディレクトリには circleciの設定が含まれていないため、コミットメッセージに　"[ci skip]" が含まれていないとビルドに失敗する
- Circle CIが自動で作るsshキーはリードオンリーなので、自分で登録して書き込み可能にする必要がある
    - 参考: https://esnetk6.com/2018/04/circle-ci-deployment/
- workflows の filters でmasterのみに限定するとほかのブランチではビルドが走らない
    - 参考: https://circleci.com/docs/2.0/workflows/#using-contexts-and-filtering-in-your-workflows
Web開発向け実用的SublimeTextパッケージ3選

#はじめに
##SublimeTextとは
- "恋に落ちる"ほど軽量快適で、拡張性の高いテキストエディタ
- まだインストールしてない人々は、まず [こちら](https://sublimetext.com) からSublimeTextをインストール!!

##パッケージについて
ユーザーが自由に作成した、「プラグイン」のようなものが自由に無制限でSublimeTextのコマンドパレット(Tools->Command Pallete[Ctrl+Shift+P])で`Package Control: Install Package`からインストールできる。
##早速紹介
### AutoFileName
![autofilename.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/210747/32ef07af-3e34-c372-f6f1-a3ace74d15de.gif)

その名の通り、`<script src="` ←この時点で現在編集しているディレクトリからファイルを予測候補で出してくれる。便利。
### FileIcons
![fileicons.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/210747/261b2960-a649-da0d-edb7-a965ec71fc5a.png)

現在のプロジェクトのファイルたちにアイコンをつけてくれる。ファイルの見分けがつきやすくなる。
### HTML-CSS-JS Prettify
![HTML-CSS-JavaScript-Prettify.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/210747/c50f99bf-3f55-b2f3-56dd-7977167f7bb5.gif)

SublimeTextにはデフォルトでコード整形がついてないので、自分好みの整形ツールを入れる必要がある。
`Ctrl+Shift+H`で自動整形してくれる。
HTML,CSS,Javascript,JSON,React/JSX/Vue.js等に対応。
#まとめ
- 今回はWeb開発向けの実用的なパッケージを3つに絞って紹介した。
- これを機に記事を読んだ人が、SublimeTextに初めての人はどっぷりと、すでに使ってる人にはもっとどっぷりと浸かって恋に落ちてほしい。
- 快適開発環境でWeb開発にハマろう!!
Google Spread Sheet + Google Apps Script で自動翻訳

大量な日本語コンテンツ(600行ぐらい)を中国語に翻訳するニーズと出くわし、数行で自力で訳したら、気が滅入ってしまったことが起因でした。

早速本題に入りたいと思います。


例えば、このような会話がGoogle Spread Sheet 上に600行あるとしましょう。

-**最近見たい映画とかありますか。**

これをGoogle APIで自動翻訳できたら楽だなと思って、GoogleAppsScriptsで何かできないか調べてみました。

```
function onEdit(){
    var sheet = SpreadsheetApp.getActiveSheet(); 
    var val = sheet.getRange("A1:A3").getValues();

    for (var i = 0; i < val.length; i++) {
        var set = LanguageApp.translate(val[i], "ja", "zh-cn");
        var num = 1 + i;
        var cell = sheet.getRange("B"+num);
        cell.setValue(set);
    }
}
```

実行すると下記のイメージになります：

![スクリーンショット 2019-04-15 10.30.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/170085/9901f9a7-7292-7b38-4869-4f983f6b55d0.png)


上記の処理はA1:A3のセルにある日本語のコンテンツを翻訳し、B1:B3に翻訳した内容をセットするという流れです。

少し補足しますと：

1)
`getValues()`は複数の値を配列形式で返すことに対し、`getValue()`は一つの値を返しくれます。
今回の場合は大量処理なので、`getValues()`にしました。
値をセットする方法は他にもありますが、配列の組み立てとか考えるのがめんどくさいので、ループにしました。

2)
        var set = LanguageApp.translate(val[i], "ja", "zh-cn");
上記の関数の引数は、「翻訳テキスト」、「翻訳元の言語」、「翻訳する言語」
日本語→英語の場合は "ja", "en"でOK

3) 
SpreadsheetからGASの開き方は下記のイメージです：
![スクリーンショット 2019-04-14 21.34.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/170085/7357f508-ac26-a59a-1c30-2a22c9df6535.png)

最後に、翻訳の精度について

googletranslateという機能も使えるが、[こちらの記事](https://qiita.com/kazinoue/items/82779a11af8a2dea0d21)を読んでたら、精度がそこまでらしいので、LanguageAppを使用しました。
数は打てくれましたが、精度が体感80%で、修正は必ず必要になります。
まあ、作業量は減ったので、気持ちは大分楽になりました。
社名には住所地を、人名は姓名を

資料に固有名詞を書くときの習慣について。

# 社名に住所地
社名には、本社の住所地を書くとよい。

同じ社名で本社の違う会社が存在するから。

社長名を付記する場合がある。

 暴力団員による不当な行為の防止等に関する法律 
http://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=403AC0000000077_20171201_429AC0000000046
に関連する書類には、社長の生年月日を記載する場合がある。

この種の書類の有効性については未調査。

# 人名は姓名
人名は、姓名を書くのが基本。
姓だけ、名だけは、公式資料とは言えない。

人名だけだと、同性同名が多い人だと識別できない。

生年月日は個人情報としてあまり公開したくない人が多い。
社名と同じく、住所地を書くのは一つの手。

同性同名同住所地（市町村）という人も多い。

最終学歴を書くのも一つの手。
同性同名の同じ最終学歴の人もそれなりにいる。

勤務先を書くのも一つの手。
勤務先であれば、その勤務先に同性同名の人間が何人いるか把握していて、振り分けてくれるかもしれない。

ここまでのまとめとしては

1. 勤務先
2. 最終学歴
3. 住所地

例：小川清＠名古屋市工業研究所：静岡大学理工学研究科博士課程後期設計工学専攻：愛知県春日井市

長すぎる。

愛知県春日井市では、電話帳に同性同名を確認している。

住所地だけでは、、、。

4. 最終学歴ではなく、博士、修士、学士等ではどうだろう。

10人いた。
https://ndlonline.ndl.go.jp/#!/search?lang=ja_JP&materialtype=Hakuron&creator=小川清&page=1&maintain=true&searchCode=PAGE

### 最後までおよみいただきありがとうございました。
いいね　💚、フォローをお願いします。
####  Thank you very much for reading to the last sentence.
Please press the like icon 💚　and follow me for your happy life.
mrubyでgame開発日記１日目

#一日目

今日は、とりあえず数学をもう一度勉強し始めた。というのも、3Dの分野自体が数学の固まりみたいなものだったので、勉強した。

自分の場合、数学は１年前から高校１年生レベルの問題をやったりしていました。高校は数学１でカリキュラムが終わるようになっていたので、レベルとしては中学生数学のレベルに毛が生えた程度です。

そこでやったのが、数学全体を勉強してみようと思い、「数学大百科事典」という高校数学と大学数学（２年レベルまで）のものが網羅した物を理解しながら読みました。ここで、注意したのが覚えようと思って読んでいません。

#どうして覚えようとしなかったのか？

この間、もくもく会でそこの主催している会社の社長から言われたことなのですが、「あまり肩肘張らずにやる」ということをいわれたからです。覚えようとするとどうしても方に力が入ってしいます。特に僕の場合はそうです。そうしないと覚えなくなるのではないのかという錯覚に陥ってしまうからです。

ですので、そうならないためにあえて覚えることを諦めました。
覚えなくても、結構頭のどこかで覚えていると思い、覚えることは諦めます。

#明日やること

数学は継続してやります。あとは、家にかえって時間を１時間くらい作りopenglで四角形のobjファイルを出力できるようにしまう。今日はこれで。

###Ciao!
【メモ】CentOS7 で munin のホスト名を変える

#ホスト名の変更と過去のデータの引き継ぎ

既にlocalhost名で稼働していたため、過去データを引き継ぎつつ
ホスト名を newserver.domain.com に変更した。

参考にした元記事はこちら：
[[CentOS]munin監視対象のホスト名が変わっても監視データを引き継ぎたい](https://nullpopopo.blogcube.info/2015/07/munin-nodenamechange.html)

まず、サービスを一旦停止する。

```
sudo service munin-cgi-graph.socket stop
sudo service munin-cgi-html.socket stop
sudo systemctl stop munin-node
```
vim で下記のホスト名を編集 [localhost] -> [newserver.domain.com]

```
/etc/munin/munin-node.conf
/etc/munin/minin.conf
/etc/munin/conf.d/local.conf
```

データベース関連の名前を変更する（コピー）

```
cd  /var/lib/munin/
sudo cp state-localhost.localhost.storable state-domain.com-newserver.domain.com.storable
sudo cp -R localhost domain.com
```

特に以下のファイル群は数が多いので、手動での変更は厳しい。参考サイトのワンライナーを使わせてもらう。

```
cd /var/lib/munin/domain.com/
for A in $(ls | grep localhost); do sudo mv ${A} $(echo ${A} | sed -e "s/localhost/newserver.domain.com/"); done
```

ファイル群の所有者が munin ではなく root になっているとサービスが動かないので、修正する。

```
cd /var/lib/munin/
sudo chown -R munin:munin domain.com
```

過去のファイルはバックアップに保管しておいても良い。不要になったら消す。

```
cd /var/lib/munin/
sudo mkdir backup.old
sudo mv state-localhost.localhost.storable backup.old/
sudo mv localhost backup.old/
```

サービスを再度起動

```
sudo service munin-cgi-graph.socket start
sudo service munin-cgi-html.socket start
sudo systemctl start munin-node
```

以上。
JenkinsとBacklogでできること

#JenkinsとBacklogでできること

GCPのDeployment ManagerでJenkinsサーバを立ててみたけど
Github以外の連携をやるのが初めてでそもそもなにができるのか
よくわからなかったのでメモ。

Backlog用プラグインが公式から用意されていてこれがとても捗る。

- JenkinsのログインがBacklogのアカウントで可能に
- Backlogのgitの設定が簡単に 
- ナビゲーションメニューからBacklogへリンク
- Issueの作成・リンク
- ビルド結果で生成されたファイルをBacklogに転送

他にも色々あるようだけどまだ試していない。

Backlog & Jenkins & Slack環境はやはり便利。
各項目の設定方法は随時追加します。
Chrome 75 lazy loading 遅延ロードのネイティブサポート

6月4日リリース予定の**Chrome75**にて、`img`と`iframe`タグの、lazy loading(遅延ロード)がネイティブ実装されます。詳しくは、Chromeの開発者である、[Addy Osmaniさんのページ](https://addyosmani.com/blog/lazy-loading/)に説明があります。

Addyさんはこちらの男性です。
https://www.youtube.com/user/addyosmani

以下、そのざっくり要約になります。


現状では画像の遅延ロードをする場合、[lazysizes](https://github.com/aFarkas/lazysizes)などのJSライブラリを使用する必要がありましたが、Chrome75からは不要になる予定です。

遅延ロードというのは、オフスクリーン(スクロールしないと見えない領域)のimgやiframeのダウンロードをしないことでネットワーク使用量を減らし、webページをすぐにレンダリングすることでユーザ体験を向上するテクです。

```html
<img src="celebration.jpg" loading="lazy" alt="..." />
<iframe src="video-player.html" loading="lazy"></iframe>
```

`img`と`iframe`の**loading**属性の指定で、遅延ロードの有効、無効を指定できます。デフォルトでは**auto**になります。

- lazy 有効。オフスクリーンの場合はダウンロードしません。
- eager 無効。これまで通りにオフスクリーンでもダウンロードします。
- auto 遅延ロードするかどうかはブラウザが判断します。

`srcset`で指定した画像や、`picture`タグ内の`img`タグに対しても機能します。

遅延ロードでダウンロードされなかったimgやiframeはユーザがスクロールを開始してスクリーンの見える部分(above-the-hold)に近づくとダウンロードを開始します。
どれくらい近づいたらかはブラウザの実装によります。あまり短すぎるとユーザは真っ白な画面に遭遇するリスクがありますし、逆に長すぎるとユーザが途中でスクロールをやめてしまい、無駄に終わる可能性もあります。

遅延ロードはChrome75だけの実装ですので(Firefoxも実装予定です)、他のブラウザではlazysizesなどのJSで対応する必要があります。ブラウザで遅延ロードがサポートされているかの判定は以下のようにします。

```javascript
if ('loading' in HTMLImageElement.prototype) { 
    // 遅延ロードをサポートしてます
} else {
   // 遅延ロードをサポートしてません
   // lazysizesなどで対応します
}
```

こちらに遅延ロードのデモのビデオがあります。
https://www.youtube.com/watch?v=bhnfL6ODM68

もしくは[Chrome Canary](https://www.google.com/chrome/canary/)でこちらのサンプルページを開いて遅延ロードを体験することができます。
https://mathiasbynens.be/demo/img-loading-lazy

遅延ロードを実行するためには、`chrome://flags`のフラグ設定から、

- Enable lazy frame loading
- Enable lazy image loading

を有効にして、Canaryを再起動します。

遅延ロード実行の判定は、スクロールの距離とネットワークスピードに基づいて決定します。それの閾値は[ハードコード](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/settings.json5?l=937-1003&rcl=e8f3cf0bbe085fee0d1b468e84395aad3ebb2cad)されています。

遅延ロードの実装によって、これまで動いていたiframeや広告のiframeに影響する可能性もあります。

[**Body.OnLoad()**イベントがオフスクリーンのimgやiframeを待たずに発火することに注意してください。](https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit#)

Chromeの実装では、もしサーバが[rangeリクエスト](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests)に対応している場合、最初の2KBだけを取得します。最初の2KBに画像サイズの情報が含まれていれば、その情報を元にプレースホルダーの表示ができるからです。

ブラウザが遅延ロードをサポートしているかのヒントをサーバ側に送信する仕様も[議論](https://bugs.chromium.org/p/chromium/issues/detail?id=949365)されています。これにより、無駄なJSのダウンロードを防ぐことができます。
Windows10でAnacondaの仮想python環境使っていてvscodeのfromに赤線エラーが出る

#私の環境
- Windows10 pro
- AnacondaのPython利用
- Python 3.7.2
- conda使ったPython仮想環境で開発（[こちら](https://qiita.com/taketakekaho/items/319295454a13b523f310)参考）

#事象
コード自体に問題ないはずなのにfromの所に赤線のエラーが出るのが気になる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/f2e07b2a-8e61-a306-cc05-bec2fc7eb88a.png)

マウスを合わせてエラー内容見るとこんな感じ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/7eec4f03-573f-6bed-3ecf-82e7d519910a.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/021f2ff8-7ef9-ba34-4aef-a461ec0a6d73.png)

#原因
色々調べると、仮想環境使ってるからかpythonのインストールフォルダがvscodeが認識している場所と異なるのでエラーになってるっぽい。

## pythonのインストールフォルダを確認
仮想環境起動したプロンプトで以下を調べるとインストールフォルダを教えてくれます。

```:cmd
(py37)$ where python
C:\Users\taketakekaho\AppData\Local\Continuum\anaconda3\envs\py37\python.exe
C:\Users\taketakekaho\AppData\Local\Continuum\anaconda3\python.exe
```
私は今仮想環境で開発してるので`C:\Users\taketakekaho\AppData\Local\Continuum\anaconda3\envs\py37\python.exe`を使ってるということになります。

## vscodeが認識しているpythonのインストールフォルダ
ファイル＞基本機能＞設定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/b6c6b68c-e3a7-56fd-c922-ed66bcb8220a.png)
で`python.pythonPath`を入力するとPathが見れます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/f396e964-042d-3bd9-bcdc-26a328d9a9f7.png)


確かに相違してます。

#対処
今使ってる仮想環境のPythonインストールフォルダを指定した所
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/0317dbb1-378c-0c33-75ea-d1af71f2d44a.png)

赤線のエラーは消えました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178016/fda43c4c-c45a-0257-2b88-d77c3173adad.png)


これいちいち仮想環境変わる度に設定しないといけないのかな…

#参考にしたリンク
[vscodeでimportの下に赤線がでるバグ？](https://teratail.com/questions/137869)
Atom＋Tex 〜Windows編　手順をメモ

# Windowsにtex環境を作りたい　手順をメモ
###必要なもの
- Atomのインストール
- TexLiveのインストール

## Atomのインストール
1. 以下からAtomをダウンロード  
https://atom.io/

2. AtomSetup.exeファイルを実行
3. 環境設定を編集
次のパッケージをインストールする
 - Latex 　（Engineをplatexに変更）
 - japanese-menu
 - language-latex
 - latextools
 - pdf-view
 - color-picker
 - latexer

## TexLiveのインストール
1. 以下からtexLiveをインストール！
https://www.tug.org/texlive/acquire-netinstall.html 
ここから、 `install-tl-windows.exe`をインストール

2. Simple installにチェックを入れてNEXTからのInstallをクリック
3. 次へを何度かクリックし、導入をクリック
4. インストールのため30分くらい待機
5. 終了とCloseを押してインストール完了！

# あとがき
>
Cloud Latex　ていうサービスが使いやすいらしい。
わざわざ環境作る必要なかったかも......
やっぱりLP作るのはStrikinglyで十分だと、作って思った

※早くプロダクトを市場に出したいスタートアップ・個人開発者は、という条件付き

▼私が作ったStrikingly製LP（頑張って作ったので宣伝させてください）▼
<a href="http://bit.ly/2Igre3W" target="blank">
![jpWatariOgp.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/217058/afc423ed-4cbb-d9ad-e1c3-46bb69b57ce7.jpeg)</a>
https://jp.watari.dev/

拙い英語ですが英語版もあります
http://www.watari.dev/

Strikingly自体のページ
https://strikingly.com

## プロダクト開発に専念したくて、LPはとにかく早く出したかった
今回、Watariというデスクトップ向けアプリを個人で作るに当たって、最初はダウンロードリンクを直で置いておいたのですが
「さすがにs3のリンクが直で置いてあるのはマズいでしょｗ」ということでダウンロードページの作成をすることにしました。

要件が、
- 【最重要】最小限の構築で作れること
- ダウンロードボタンを押した数が分かること（GoogleAnalytics仕込めば余裕）
- ページを容易に複製できて、英語版サイトもサクッと作れること
- 独自ドメインの設定ができること
で

候補として、
a. Webflow（<http://webflow.com/>）で多少リッチなLPを作る
b. html・Scssで書いてfirebaseやgithub pagesでホスティング
c. StrikinglyでFVとOGPだけこだわる

こんな感じになり、選ばれたのがStrikinglyでした。

## 価格

気になる価格は**$20/月（Pro版）**
これで（Strikinglyのロゴなど入らない）サイトが3つ公開でき、
独自ドメインの設定ができます。

年間で払えば$16/月まで安くなるのですが、
アプリの方向性が変わって
「LPで会員登録まで出来たら楽じゃね？」とかなった時に
自作でLPを作ることを考えて月払いにしてます。

## でも多分すぐ卒業すると思う

プロダクトローンチした勢いで書いてますが、たぶん上で書いたような
「LP内にサービスの機能を組み込みたい」という場合や
よりリッチな見た目にしたい、という場合はStrikinglyでは足りないです。

リッチさならWebflow、サービス組み込みなら自社サービス内で作りましょう。

勢いだけで書いてすみませんでした、サービスの開発に戻ります。
2体問題（力学）

###2体問題　一般論
質点1と質点2にお互いにはたらく力がある場合，

```math
m_1 a_1 = F_1 + F_{12}
\\
m_2 a_2 = F_2 + F_{21}
```

ここで$F_{12}$と$F_{21}$は，お互いにはたらく力で
$$ F_{12} = -F_{21}$$
がを満たす（作用反作用の法則）。この$F_{12}$と$F_{21}$を内力，あるいは相互作用とよぶ。一方で内力以外の力，$F_1$，$F_2$を外力とよぶ。


重心
作用反作用の法則を考慮すると
$$m_1 a_1 + m_2 a_2 = F_1 + F_2$$
が成立する。この方程式は内力がない。

ここで$M:= m_1 + m_2$を定義し，さらに次の座標を定義する。
$$ x_G = \frac{m_1 x_1  + m_2 x_2}{m_1 + m_2} $$
これを重心または，質量中心とよぶが，理由は次のためである。

重心の座標$x_G$を微分することで，加速度を得ることができる。
$$
a_G := \ddot x_G = \frac{1}{M} (m_1 \ddot x_1 + m_2 \ddot x_2)=  \frac{1}{M} (m_1 a_1 + m_2 a_2)
$$
すると外力だけの方程式は
$$M a_G = F_1 + F_2$$
となる。

これは，質量中心に質量$M$の物体が1つあり，力$F_1 + F_2$を受けているときの運動方程式に他ならない。さらに言えば，2物体がどのような内力をおよぼし合っていても，2物体が相対的にどのような位置にあっても，重心の運動は$F_1+F_2$のみで決定されることがわかる。


相対位置
重心の運動を求めることができても，1つ1つの質点の運動は決定できない。そこで，重心と質点の座標の差を求めると，
$$ x_1 - x_G = x_1 - \frac{m_1 x_1 + m_2 x_2}{m_1 + m_2} = \frac{m_2 (x_1 - x_2)}{m_1 + m_2} $$
同様に，
$$ x_2 - x_G = x_2 - \frac{m_1 x_1 + m_2 x_2}{m_1 + m_2} = \frac{m_1 (x_2 - x_1)}{m_1 + m_2} $$
という関係を得る。双方に対して，相対座標$x:=x_1 - x_2$の運動を得ることができれば，2質点の運動は完全に求められたことになる。

もとの運動方程式について，差をとると

$$ a : = a_1 - a_2 = \frac{F_1}{m_1} - \frac{F_2}{m_2} + \left( \frac{1}{m_1} + \frac{1}{m_2} \right)F_{12} $$
ここで，$1/\mu := 1/m_1 + 1/m_2$を定義すると，
$$ \mu a = \frac{\mu}{m_1}F_1 - \frac{\mu}{m_2}F_2 + F_{12} $$

という運動方程式を得る。

結局，重心・相対座標ともに，1体問題として取り扱うことができる。2つの1体問題を解くことで2体問題が解決できる。もとの2質点の座標との関係は
$$ x_1 = x_G + \frac{\mu}{m_1}x$$
$$ x_2 = x_G - \frac{\mu}{m_2}x$$
である。


2体問題において，外力がはたかない場合の運動方程式は
$$M a_G = 0$$
$$\mu a = F_{12}$$
となる。重心については，等速直線運動となり，初めに重心が静止している座標系では，重心は静止し続ける。一方相対座標$x$は，内力についての運動だけを解くことになる。

他
$F_1 = -F_2$を満たす場合も，重心は等速直線運動になる。


$\frac{F_1}{m_1} = \frac{F_2}{m_2}$を満たす場合，重心は複雑な運動をする可能性があるが，相対座標は内力のみで決定される。$\frac{F_i}{m_i}$は，外力による加速度を表している。一様重力場がこれに相当する。球対称な重力場の場合は，加速度が位置に依存してしまう。$\frac{F_1}{m_1} = \frac{F_2}{m_2}$となる2質点の位置が非常に特殊な場合を考えることはできるかもしれない。

###重力の2体問題
運動方程式は，慣性系のものということに注意しておく。

議論を簡単にするために，2物体の重心を原点にとる座標系を考える。つまり，

$$ x_1 = \frac{\mu}{m_1}x$$
$$ x_2 = - \frac{\mu}{m_2}x$$

となる。中心力がはたらく1体問題の場合，円や楕円軌道になることがある。相対運動が円軌道の場合を考えることにする。例えば，地球から観測した月の運動が円軌道ならば，逆に月から観察した地球の運動も同じ半径の円軌道になる。この式をみると，各質点の運動は相対運動の定数倍になっているから，重心を中心とした，半径が小さな円軌道になる。このとき，2質点とも同じ周期で運動する。

重心が原点にあるので，

```math 
m_1 x_1 + m_2 x_2 = 0
```

という関係式を得る。当然の帰結になるが，原点が2質点の位置を$m_2:m_1$に内分している。さらに

```math 
m_1 \dot x_1 =  -m_2 \dot x_2
```

となり，速度ベクトルが互いに反対方向を向く。速度ベクトルの大きさの比は，$1/m_1 : 1/m_2$となる。


初期位置と初速度をこのようにセッティングすると，原点まわりの楕円運動が実現できる。
Apple Developerメンバーシップの更新…


Apple Developerメンバーシップそろそろ更新時期だな…と思いいろいろ調べていたところ…
普通にAppleだし自動更新とかあるだろって思ったのですが、、笑

日本は何故自動更新対象外なのか…

公式ドキュメント↓ 
https://developer.apple.com/jp/support/renewal/

![スクリーンショット 2019-03-18 14.27.30.png](https://qiita-image-store.s3.amazonaws.com/0/355868/6296e40a-b810-4926-4e73-c052b51697f9.png)


Apple musicとか普通にサブスクリプションなのにね。
というかこれだけ国あって入っていない日本…

そろそろ国外逃亡するか…
という気持ちになりました。笑

大人しく今年は手動で更新しましたよ。
パラメータに指定したパス以下から、頭文字'_'のディレクトリのみを削除

再帰的に呼び出して、頭文字'_'のディレクトリのみを削除する。という要件があったのでメモ。

```dirdel.c

#include <stdio.h>
#include <string.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>

int dirdel(char *path){

	DIR *dir;
	struct dirent *dp;
	struct stat statBuf;
	char childpath[512];
	int nret = 0;

		if (stat(path, &statBuf) == 0){
			if((dir=opendir(path))==NULL){
				perror("opendir");
				return -1;
			}

			for(dp=readdir(dir);dp!=NULL;dp=readdir(dir)){
				if(dp->d_name[0] != '.'){
					sprintf(childpath, "%s/%s", path, dp->d_name);
					nret = dirdel(childpath);
				}
				if(dp->d_name[0] == '_'){
					if(rmdir(childpath) == 0){
					}else{
						nret = -1;
					}
				}
			}
		}

	closedir(dir);

	return nret;
}

int main(argc,argv)
int   argc;
char  *argv[];
{
	char path[512];

	int nret = 0;
	
	if(argc<=1){
		strcpy(path,".");
	}
	else{
		strcpy(path,argv[1]);
    }
	
	nret = dirdel(path);
	return nret;
}

```
UbuntuのVSCodeでRustの開発環境を作る

UbuntuのVSCodeでRustの開発環境を構築したのでメモとして残しておきます:smile:

# 環境

- ubuntu 18.04
- vscode 1.33.1
- rust 1.34.0

# VSCodeの拡張機能

VSCodeにはRustのソースコードの補完や定義ジャンプ、整形、ビルドタスクなどの機能を持ったプラグインがあるのでそれをインストールします。マーケットプレイスでrustで検索するとRust(rlt)と出てくるのでそれをインストールします。

![rust-rls.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/b57c6dca-f1ad-4ef4-3399-6db505986e5d.jpeg)

## コマンドライン上でコンポーネントをインストールする方法

`rustup component list`コマンドで現在インストールされているコンポーネントを調べるとdefaultでインストールされているモノのみです。

```
~$ rustup component list | grep -e installed -e default
cargo-x86_64-unknown-linux-gnu (default)
rust-docs-x86_64-unknown-linux-gnu (default)
rust-std-x86_64-unknown-linux-gnu (default)
rustc-x86_64-unknown-linux-gnu (default)
```

VSCode上でインストールするものと同じコンポーネントを`rustup component add`コマンドでインストールします。

```
~$ rustup component add rust-analysis --toolchain stable-x86_64-unknown-linux-gnu
~$ rustup component add rust-src --toolchain stable-x86_64-unknown-linux-gnu
~$ rustup component add rls --toolchain stable-x86_64-unknown-linux-gnu
```

先ほどインストールしたコンポーネントが追加されています。

```
~$ rustup component list | grep -e installed -e default
cargo-x86_64-unknown-linux-gnu (default)
rls-x86_64-unknown-linux-gnu (installed)
rust-analysis-x86_64-unknown-linux-gnu (installed)
rust-docs-x86_64-unknown-linux-gnu (default)
rust-src (installed)
rust-std-x86_64-unknown-linux-gnu (default)
rustc-x86_64-unknown-linux-gnu (default)
```

## VSCode上でコンポーネントをインストールする方法

Rust(rls)をインストールした後、ターミナルで`cargo new hello`とすると、`RLS not installed. install?`と聞かれるのでYesと答えてインストールします。

![rust-rls-notinstalled.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/a2903d38-5565-e459-ebf7-dbbff29bd53c.jpeg)

TERMINALに表示されるインストールログを見ると`rustup component add`コマンドでインストールする方法と同じコマンドを使っています。

![rust-rls_install.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/1bd300be-3715-eee4-986a-8c0f30b48b0c.jpeg)

## 動作確認

Vscodeを再起動して先ほど作成したhelloプロジェクト開きます。そしてターミナルで`cargo r`をするとコンパイル、実行と進み`Hello, world!`と表示されています。

![rust-run.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/9617ae59-611b-b8ae-5d0e-fea8aa0f03cc.jpeg)

ビルド時に"error: linker \`cc\` not found"というエラーがでたらbuild-essentialパッケージをインストールします。

```
~$ apt install build-essential
```

# デバッグ環境

デバッガ`lldb`をインストールします。

```
~$ sudo apt install lldb
~$ lldb --version
lldb version 6.0.0
```

vscode用のlldbフロントエンドCodeLLDBをインストールします。拡張機能マーケットプレイスで`CodeLLDB`で検索すると出てくるのでインストールします。

![rust-debug.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/38cd9875-8963-5bc7-db6b-d90999942e96.jpeg)

プロジェクトを開いている状態で、Debug-->Start Debuggingと押すかF5でデバッグ画面に映ります。

![rust-debug2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/4648f51c-1d10-2772-2f57-cd4fa69c7b1a.jpeg)

初めてデバッガを起動するときに下のようなメッセージが出ると思いますがYesを押します。.vscodeディレクトリの下にlaunch.jsonが作成されます。launch.jsonはデバッガ構成の設定を行っています。

![rust-debug-error.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/271649/c79db9f2-3808-02f8-12db-91e7636ee4c0.jpeg)
k8sのEvictedされたpodを一括削除

nodeのリソースが足りなかったようで、podが大量に再起動されてEvictedだらけ…
そんな時、大量のEvcitedされたpodを一括削除するワンライナー！

```
kubectl get pods --all-namespaces | grep Evicted | $(awk '{print "kubectl delete pod "$2" -n "$1}’)
```

これでいけると思ったのですが、なぜかこれを数回実行しないと全部は削除されませんでした…
何故？？k8sのversionかな…
もう最近k8sのversionに悩まされすぎて疑いがそこにばっかり向きます…笑
まあ手動で一つずつ削除するよりはかなり楽でした笑
何かいい方法あれば教えて頂きたいです。
ReactのJSXについて理解を深めよう！

#概要
Reactを勉強していく中でふと__『JSXって何だ？』__という疑問が湧いたので、この記事を書くことでJSXの理解を深めたいと思います。

前回の記事
__[ReactでHello Worldをする前に...](https://qiita.com/micropig3402/items/27031fb50580ad8497fc)__

続きはこちら
__[Reactにおけるトランスパイラー【Babel】の役割](https://qiita.com/micropig3402/items/064394428791144f5488)__

#結論
####JSXでコードを書くことにより、JavaScriptでコードを書くより簡単にHTMLを画面に出力できる！

#実際にコードを見てみよう
```react:src/App.js
import React, {Component} from 'react';

class App extends Component {
  render() {
    return <div>Hello Micropig！</div>;
  }
}

export default App;
```
上記のコードの`<div>Hello Micropig！</div>`がまさに__JSX__と言われるものです。

表示画面はこのように！
<img width="805" alt="スクリーンショット 2019-04-14 20.04.50.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/343290/92afbf37-eba4-b2ba-890f-ae9e2bc9e17f.png">

---

#JSX = JavaScript XML ? ?
JSXはJavaScriptを拡張した言語です。Reactを用いてHTMLを出力するための言語で、これもReactと同様にFacebook社が開発しました。JSXは見た目がXMLやHTML風なので可読性が高いです。

- JSX = JavaScript XML
- JSX = JavaScript eXtension

私が見つけた限り、２つの正式名称が見つかりました....
あまり正式名称にこだわらなくても良いかもしれませんね！

#なぜJSXなのか
先ほどお見せしたこのコードは、アプリケーションの中で[トランスパイル](https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9)されJavaScriptのコードに変換されます。

```react:src/App.js
import React, {Component} from 'react';

class App extends Component {
  render() {
    return <div>Hello Micropig！</div>;
  }
}
```
直接JavaScriptで同じような出力を画面に表示しようとすると以下のようなコードになります。

```react:src/App.js(JavaScriptを使う)
import React, {Component} from 'react';

class App extends Component {
  render() {
    return React.createElement(
      'div', 
       null, 
      'Hello Micropig！');
  }
}

export default App;
```
画面表示は特に変わりません。
<img width="805" alt="スクリーンショット 2019-04-14 20.04.50.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/343290/f1b44238-236c-56f6-3964-73aeb15f637c.png">
---

以上に示すように、画面に`<div>`タグを用いて`Hello Micropig！`と表示したい時に、JSXを用いてコードを書くのとJavaScriptを用いてコードを書くのではJSXを用いてコードを書いた方が__容易に実装できる__ことがお分かりいただけると思います。

####このように比較的直感的にHTMLを表現できるということがJSXの強みであります。

#リファレンス
[React の JSX とは？](https://react.keicode.com/basics/jsx.php)
[「JSX キモい」に反論してみる](https://qiita.com/oukayuka/items/195315df70b1f8de3a18)
[ReactやVueのJSXについて曖昧に理解する](https://qiita.com/nabepon/items/87bb3b4f1e7bfa342489)
[シンタックス  【 syntax 】とは ](http://e-words.jp/w/%E3%82%B7%E3%83%B3%E3%82%BF%E3%83%83%E3%82%AF%E3%82%B9.html)
[トランスパイルとは](https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9)
【Git】計画なしに他のブランチをマージし、削除/移動したら起こりえる問題

他の人のブランチで作成されたものを自分のブランチにマージしてから、マージされたものを削除や移動し`master`にマージした後、他の人のブランチを`master`にマージする場合、どうなるのか検証してみました。

[検証用GitHubリポジトリ](https://github.com/lostfind/git-playground)

## 予測
他の人のブランチにはまだ削除/移動前の姿があるから、そのまま`master`にマージされ、
結果的には移動されたものはコピーした扱いになる。**(結論から言いますと、これは不正解です。)**

## 検証
### 検証用のブランチですること
+ `dev/newfile`
新しいディレクトリとその配下にファイルを作成する。

+ `dev/movefile`
dev/newfileをマージし、マージされたものを一部は削除、残りはディレクトリごと移動する。

### 検証詳細
#### 準備
1. `master`から`dev/newfile`ブランチを切る
    2. ディレクトリ`new`作成
    3. `new`の配下にいくつかのファイルを作成
    4. コミット
5. `master`から`dev/movefile`ブランチを切る
    6. `dev/newfile`ブランチをマージする
    7. マージされた`new`ディレクトリ配下のファイル一部を削除
    8. `new`ディレクトリ名を`moveto`に変更
    9. コミット
10. `master`に`dev/movefile`をマージ

*ここまでのGit履歴グラフ*
<img width="800" alt="git_graph.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306025/61ca229d-aa1b-0af2-6867-d4c6a41b54b8.png">

#### 結果
##### `dev/newfile`ブランチを`master`へのマージリクエストを作成する。
あれ、差分がない！？
じゃあ、なにか修正してマージしたら差分がでるのでは？と考え、確認してみました。

##### `dev/newfile`の一部を修正した後、`master`へマージする。
コンフリクトが起きました。

```
CONFLICT (modify/delete): new/new_c.txt deleted in master and modified in HEAD. Version HEAD of new/new_c.txt left in tree.
CONFLICT (modify/delete): new/new_b.txt deleted in master and modified in HEAD. Version HEAD of new/new_b.txt left in tree.
Automatic merge failed; fix conflicts and then commit the result.
```


```sh
$ git status

On branch dev/newfile
Your branch is up to date with 'origin/dev/newfile'.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Changes to be committed:

	new file:   moveto/move_to.txt
	renamed:    new/new_a.txt -> moveto/new/new_a.txt

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)

	deleted by them: new/new_b.txt
	deleted by them: new/new_c.txt
```

ローカルで手動マージすると`dev/newfile`で最後の修正分は
`dev/movefile`で削除されたファイル : 新しいファイルとして作成されます。
`dev/movefile`で移動されたファイル : 移動されたまま修正分が適応されます。

```
Changes to be committed:

	modified:   moveto/new/new_a.txt
	new file:   new/new_b.txt
	new file:   new/new_c.txt
```

## まとめ
`dev/newfile`にはファイルが残っていても`dev/moveto`ブランチでのコミットが最新なので、マージしようとしても`master`にマージ済みより過去分になるので、差分がでず削除/移動済み扱いになりました。
移動されたものに対しては`dev/newfile`で移動前のファイルを修正しても、移動後のファイルにマージはされます。

**予測での「結果的には移動されたものはコピーした扱いになる」は完全に間違えたものでした。**

他のブランチのファイルやディレクトリを別名でコピーして自分のブランチで使いたい場合、こういう問題にならないために下記のようにするといいかなと思います。

```shell
# ファイルが1つの場合
git show {コピー元ブランチ名}:{パス/ファイル名} > {コピー先パス/ファイル名}

# ディレクトリごとコピー
git checkout {コピー元ブランチ名}
cp {コピー元Dir} {コピー先Dir}
git checkout {自分のブランチ}
```
もっと簡単でスマートな方法がありましたら教えてください！🙇‍♂️
データベースにおける分離レベルとは

■３つの問題点

複数のトランザクションで同一データをやり取りする際
下記３つの問題が起こりうる。

ダーティリード
　・AさんがデータXを更新
　・BさんがデータXを取得
　・Aさんがコミット
　  ⇒この時Bさんはコミット前の更新データXを参照してしまう。
　  ⇒「コミットをしていない更新データを参照できてしまうこと。」

ノンリピータブルリード
　1.AさんがデータXを参照
　2.BさんがデータXを更新
　3.Bさんがコミット
　4.AさんがデータXを参照
　  ⇒1と4で違う値を参照してしまう。(再現性がない。 = リピータブルでない。)

ファントムリード
　1.AさんがテーブルXを参照
　2.BさんがテーブルXにデータを挿入
　3.Bさんがをコミット
　4.AさんがテーブルXを参照
　  ⇒1と4でデータの数が異なる。(1ではいなかったデータ出現。 = ファントム)

---
■分離レベル
分離レベルとは上記３つの事象のうちどのレベルまで禁止するかまたは許容するかというもの。

| 分離レベル | ダーティ | リピータブル | ファントム |
|:-:|:-:|:-:|:-:|
| READ_UNCOMITTED  | 〇 | 〇 | 〇 |
| READ_COMITTED    | 〇  | 〇  | ×  |
| REPEATABLE_READ  | 〇  | ×  | ×  |
| SERIALIZABLE  | ×  | ×  |  × |

〇 : 許容する。 × : 許容しない。

---
■実装DBと分離レベル
分離レベルはどれでも選べるわけでなく、実装DBがそれに対応しているかに依存する。

Oracle
　・READ_COMITTED
　・SERIALIZABLE  
h2
　・READ_COMITTED

---
■参考
[Oracle]
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19215-02/consist.htm
(表13-1)のところに記載あり

[H2]
http://h2database.com/html/features.html
Locking, Lock-Timeout, Deadlocksのところに記載あり。
ホットリロードで快適Web開発環境を整える

#はじめに
##ホットリロードとは
ホットリロードとは、[Vue.js](https://vuejs.org)等で実装されている、
「ファイルの変更をトリガにリアルタイムで変更を反映してくれる」
機能のこと。
##何が嬉しいか
- デザインを確認したい
- 文章だけを変更して見栄えを確認したい
- こういった時に使える

#導入方法
`npm install -g live-server`
`cd /開発してるやつのパス`
`live-server .`
これだけ。
 
#まとめ

- 今回はWeb開発が数段快適になる`live-server`の紹介をした
- Web開発してる人はぜひ使ってみてほしい
- 使うとやめられない。Web開発が止まらない!!
プログラミング学習記録57〜iPadをサブディスプレイに〜

##今日やったこと
- 「Duet」でiPad(10.5インチ)をサブディスプレイにする

「Duet」というアプリを使って、iPadをサブディスプレイにして作業してみました。

1200円の有料アプリなのですが、それ相応以上の価値があると思います。

iPadの配置を上、右、左の3パターンで試してみたのですが、右に置くのが見やすいかなと思います。
PCが左ですね。

そして、テキストエディタをPCで開いて、ドットインストールなどの動画をiPadの方で開いて見るのが見やすいです。

テキストエディタをiPadの方で開くと、文字が小さくて見づらいので、テキストエディタはPCで開く方が良さそうです。

iPad Proの大きいやつ(12.9インチ)だったら、iPadでテキストエディタを開いてもいいかもしれません。

今日はドットインストールを少し見ただけなのですが、それでもサブディスプレイのありがたさを実感しました。

10.5インチのiPadだと若干サブディスプレイとしては小さいですが、それでもPCの１画面だけでやるのと比べたら快適さが全然違います。

ドットインストールなどの動画教材を見ながらメモをとったり、エディタに打ち込んだりする作業をするときは、２画面で作業した方が圧倒的に効率がいいですね。

ウィンドウを複数開いて、切り替えながらやったり、１画面を半分にしてちょこちょこやるとなると、同じ作業量でも疲れ方が倍増してしまいます。

余計なストレスを減らすためにもデュアルディスプレイは非常に有効だということがわかりました。

おわり
ありがとうcybozu Live

# cybozu Live終了
cybozu Liveのサービスが20190415で終了する。

これまで、自分が主催したグループ30
他の方が主催されたグループに参加していた数7

プログラマ関連の活動は
http://gitlab.com
に移行した。

ソースコードの管理、コンパイルなどは
git系が大事。

コンパイルしにくいところで議論していても、
コンパイルせずに意見を言う人がいても止めにくい。
コンパイルすればわかることを、コンパイルせずに議論する人にはうんざり。

ソースコードでも、１行ソースコードを書き足せば、わかることを、
数行日本語で書かれても、この人、何やってるんだろうと思う。

プログラマが前提の議論で、
プログラムを書かずに意見を述べる姿勢に疑問を感じていた。

cybozu Liveがサービスを終了していただけるのを機会に、gitlabを多用。

# yahoo groups
cybozu Liveを利用する前には、
yahoo groupsを利用していた。

多くの資料をyahoogroupsからダウンロードしてあるし、
一部はcybozu Liveに再掲した。

９割は有効利用できてこなかった。反省。

一部の資料は、soundcloude,

# researchmap
学術的な内容は、yahoo groupsからresearchmapに移行しようとした。
http://researchmap.jp

スケジュール管理、ファイル共有（ファイルの種別に制約がある）、メール配信などの設定がうまくできずに、yahoogroupsからの移行では、有効に利用できていない。

# facebook
公開に近い議論はyahoogroupsからfacebookに移行した。
cybozu Liveを利用しているグループも、facebookにもグループを作成して、公開情報はfacebookに置くようにしてきた。

cybozu Liveが終了しても、facebookのグループは続く。

# Qiita
公開できる資料で、プログラミングに関連する事項は、１昨年の暮れから、Qiitaに書くようにしている。
今後、過去の資料を整理しながら、公開できる資料をQiitaに掲載する速度を増す予定。

# twitter
Qiita, facebookに掲載した公開情報は、twitter, はてなブックマークにも記録するようにしている。

# はてなブックマーク
同上

# Lineグループ
緊急連絡などは、cybozu Liveのグループに対応したLineグループを作ってきた。
Lineグループは今後も緊急連絡用に続く。

# gitlab
gitlabに移行して課題は、

1. メール配信
通知する、しないの設定はできる。

メールの通知をするかしないかの設定を細かく指定できる仕組みがわかっていない。

2. 日程調整
milestone, issu, wikiのどれでも日程調整は可能。
メール配信の設定がきめ細かくできれば、現状でも利用は可能。

3. ファイル共有
ソースコーヂ系のファイル以外では、10MB以上のファイルはおけない。

### 最後までおよみいただきありがとうございました。
いいね　💚、フォローをお願いします。
####  Thank you very much for reading to the last sentence.
Please press the like icon 💚　and follow me for your happy life.
Solidity v0.5.0 以上での transfer メソッド

# 概要
- Solidity 0.5.0 からは、Ether を受け取ることのアドレスの型を `address payable` とする必要があります。
- Solidity 0.4.0 までと同様に普通の `address` 型を使用するとコンパイル時にエラーとなります。

# サンプルコード（0.4系で動くコード）
- tipEther メソッドは、関数を実行する際に送った Ether を beneficiary に送ります。

```js
pragma solidity ^0.4.25;

contract AddressPayableTest {
    address beneficiary = 0x0089d53F703f7E0843953D48133f74cE247184c2;
    
    function tipEther() public payable {
        beneficiary.transfer(msg.value);
    }
}
```

- 上記のコードは、Solidity 0.4 系までは動きますが、Solidity 0.5 系だと次のメッセージと共にコンパイルエラーとなります。

`Member function “transfer” not found or not visible after argument-dependent lookup in contract?`

# サンプルコード（0.5系で動くコード）
- tipEther メソッドは、関数を実行する際に送った Ether を beneficiary に送ります。
- beneficiary は Ether を transfer メソッドによって受け取るため、`address` ではなく `address payable` とします。

```js
pragma solidity ^0.5.0;

contract AddressPayableTest {
    address payable beneficiary = 0x0089d53F703f7E0843953D48133f74cE247184c2;
    
    function tipEther() public payable {
        beneficiary.transfer(msg.value);
    }
}
```

# 注意
- 基本的には `address payable` はなるべく使用せず、特定のアドレスに対して Ether を送金する場合は、withdrawal パターン を使用すべきだと思います。
- `msg.sender` は `address payable` なので、普通に withdrawal に従えば、　`address payable` については意識する必要がないと思います。

# 参考
- https://solidity.readthedocs.io/en/v0.5.7/050-breaking-changes.html?highlight=breaking%20changes
- https://solidity.readthedocs.io/en/v0.5.7/common-patterns.html#withdrawal-pattern
Display histogram using R

### Data
```text
Name Life Period
태조 73 6
정종 62 2 
태종 45 18
세종 53 32
문종 38 2  
단종 16 3 
세조 51 13
예종 28 1
성종 37 25 
연산군 30 12
중종 56 12
인종 30 38
명종 33 1
선조 56 22
광해군 66 41
인조 54 15
효종 40 26
현종 33 10
숙종 59 46
경종 36 4
영조 82 52
정조 48 24 
순조 44 34   
헌종 22 15
철종 32 14
고종 67 44 
순종 52 3
```

### Souce Code
```r
kings <- read.table("chosun kings.txt", header=T)
str(kings);
attach(kings)
windows(width=5.5, height=4.5)
hist(Period)
```

### Histogram of Period
![Histogram of Period.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/356443/aeabe05f-766f-b989-c4d1-a017aa3ca7e0.png)
UbuntuでAngular Gridが使えるようになるまで

#最初にUbuntuのバージョンを確認
まずは自分が使っているUbuntuのバージョンを確認。

```bash
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
```
#Node.jsをインストール

```bash
$sudo apt update
$sudo apt install nodejs
$sudo apt install npm
```
#Angular GridのGetting Startに従う
[Angular Gridの公式サイト](https://www.ag-grid.com/angular-getting-started/)を参考に進める。公式の例だとsudoが付いてなかったりするので、必要に応じてsudo追加。

###Anglar CLIのインストール
```
$sudo npm install -g @angular/cli
$ng new my-app --style scss --routing false
$cd my-app
$ng serve
```
これで[localhost:4200](http://localhost:4200)にアクセスすると、こんな画面が表示される
![Screenshot from 2019-04-14 15-44-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/334790/9dd6fd8a-e7a4-3bb5-6ca1-cb82496f21c9.png)

###ag-gridのインストール
直前のng serveコマンドが実行状態になるので、新たなコンソールを起動しmy-appディレクトリにて下記を実行。

```
$npm install --save ag-grid-community ag-grid-angular
$npm install
```
とりあえずここまでで環境はOKなハズ。
できるリーダー(テックリード)になるためのトレーニング法③

## はじめに
うめりんです。前回は[意思決定のためのトレーニング](https://qiita.com/umerin/items/e9938717748621db0d47)でした。
まだご覧になっていない方は、記事に順序性は無いので後からでもご参考にして頂ければと思います。

## ③すぐにトレードオフの説明ができるように、普段から思考を整理し情報が集まるようにしておく
考え方はエンジニアに限ったものでは無く、誰でも応用可能なものです。

##なぜ必要なのか？
リーダーになると「(1)プロダクトやサービスにおける目に見える機能」だけでなく「(2)関連のあるシステムや仕組みの全般」にも、常に気を配らなくてはならなくなります。
ここでは便宜上、(1)をビジネスサイド要件、(2)をエンジニアサイド要件、と仮に呼ぶことにします。

ビジネスサイド要件は、エンジニアを含めた関わる全ての人達から依頼がくる可能性があり、絶えることはほとんど無いと思います。
しかし、エンジニアサイド要件は、エンジニアから発信しないと他の誰も気にしていないことが多く、往々にして事前予測が難しいため後から出てくることが多いです。
そのため、ビジネスサイド要件で予定の100%が埋まっていると、エンジニアサイド要件が出てきた際、どう詰め込むのかという議論が起こりがちです。
また、エンジニアサイド要件の検知・相談・対処が遅れると思わぬ被害が出ることも少なくありません。

##具体的に何をすれば良いのか
まずは、トレードオフそのものについて詳しく知ってください。
[wikipedia](https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AC%E3%83%BC%E3%83%89%E3%82%AA%E3%83%95)も参考になりますが、ソフトウェア開発においては、QCD（Quality：品質、Cost：コスト・価格・費用、Delivery：納期）のそれぞれが"トレードオフの関係にある"と表現されることが良くあります。
ただし、これらはゼロかイチかでは無く、バランスを取ること（妥当な基準の合意形成）が重要になります。
そして、今回のビジネスサイド要件とエンジニアサイド要件におけるトレードオフの対象となるのは、最初は「時間」です。
例えば、ビジネスサイド要件に割り当てる時間を90%に減らし、エンジニアサイド要件に割り当てる時間を10%とした際に、ビジネスサイド要件に割り当てる時間が100%だった時に得られるはずだった売上・利益・価値（顧客体験など）が何かしら失われるはずなので、ビジネスサイド要件で失われるものと、エンジニアサイド要件を実施することで得られるもの（またはエンジニアサイド要件を実施しないことで失われるもの）とを天秤にかけて、どちらを選ぶか（最適な、両要件の割合・QCDの割合）を判断するという流れになります。
トレードオフを語る際にQCDだけを引き合いに出すと「品質が高ければバグが起きないはずで、バグが起きないなら費用も納期も守れるはずだ」と一見正しそうなことをおっしゃる方がいるので、そういう時のためにも「誰に対しても有限である時間の観点をセットで会話すること」が望ましく、過剰品質や過剰性能という言葉も覚えておいた方が良いです。

次に、エンジニアサイド要件を列挙し、何らかの変更が起きる可能性と影響範囲を洗い出す方法を考えておきましょう。
エンジニアサイド要件の観点例（変更や発覚の可能性）は、以下の通りです。
・扱うコンピュータ環境全般における、OS/コンパイラ/インタプリタ/ミドルウェア/ライブラリ/エンジン/ツール/SDK/IDEなど、のバージョン
・ソフト受け入れ側（顧客やプラットフォームなど）の、審査基準・検収条件・システムプロトコルやレギュレーション
・システム動作環境における、リソース（CPUコア、メモリ、ストレージ、ロケーション、通信帯域など）の数/管理方法（省電力、アクセス権限など）
・意図しない挙動、技術的負債（処理速度、データ構造、データ量など）、セキュリティ脆弱性
可能性と影響範囲を洗い出す方法は、変更頻度が分かっているものは時期を明確にしておく、資料で受領する類のものは内容をしっかり確認し有識者にも教えを乞う、発覚する類のものはコミュニケーションフロー（起きた時に誰から誰に連絡するか）を明確にしておくなどが挙げられます。

そして最後に、「何らかの変更」を検知できる仕組みを作っておきましょう。
検知と表現すると真っ先に**通知を自動化する**が思い浮かぶと思いますが、それ以外にも**リリースノートやロードマップを定期的に確認する担当メンバを割り当て**たり**情報感度の高いメンバをアサイン**したり、**変更を見つけたら教えてくださいと全体に言っておく**だけでも一定の効果はあるので、デジタルなエンジニアリング以外の方法も併用して無理のないやり方を模索してみて下さい。

## おわりに
エンジニアからエンジニア以外の人達に対してもそうですが、1人のメンバーからリーダーに対しても使える考え方ですので、お試し下さい。
Nuxtの開発支援CLIツール「naru」の紹介

# naru
Nuxtの開発支援CLIツール「naru」を開発しました。
npmまたはyarnでインストールできます。

```bash
npm install -g naru
# or
yarn global add naru
```

# どういうツール？
コンポーネントやページ、プラグインなどの雛形をコマンドで作成できるツールです。

下記はLoginFormというコンポーネントを作成する例です。

```
naru create-component LoginForm
# or
naru cc LoginForm # 省略した書き方
```

`components/`フォルダ直下に`LoginForm.vue`が作成されます。
![スクリーンショット 2019-04-14 19.56.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154299/c0690baa-678e-5687-8384-3e7fc56788e6.png)

中は初期設定だと下のようになります。

![スクリーンショット 2019-04-14 19.57.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154299/34616e8b-8758-5615-21d2-40dae080bf30.png)

このようにコマンドでnuxtで使うファイルなどを作成することができます。

# なぜ作ろうかと思ったか
最近Nuxt.jsとLaravelでCMSを開発しています。
Laravelでは`artisan`というコマンドでコントローラーやモデルを作成できます。
この`artisan`のようにnuxtで必要なコンポーネントやページを作成できたらいいなと思い開発しました。

[Nuxt.js+Laravelで開発しているCMSの紹介
](https://qiita.com/hota1024/items/0648cde692ad4671d445)

# インストール
npmまたはyarnでインストールできます。

```bash
npm install -g naru
# or
yarn global add naru
```

# 機能
**機能一覧**

- `create-component <名前>` コンポーネントを作成します
- `create-page <名前>` ページを作成します
- `create-layout <名前>` レイアウトを作成します
- `create-middleware <名前>` ミドルウェアを作成します
- `create-plugin <名前>` プラグインを作成します
- `create-store <名前>` モジュールモードでVuexストアを作成します
- `config` naruのコンフィグファイル(.naru)を作成します

それぞれの<名前>はパスにもできます。
例：`naru create-component articles/_id/edit`

create~だと長いので省略ができます。
例：`naru cl blog`

**省略形一覧**

- `create-component` → `cc`
- `create-page` → `cp`
- `create-layout` → `cl`
- `create-middleware` → `cm`
- `create-plugin` → `cpl`
- `create-store` → `cs`

# 設定
`naru config`を実行すると`.naru`というディレクトリが作成され、その中に`naru.config.js`というファイルが作成されます。

![スクリーンショット 2019-04-14 20.18.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154299/1f3ccd09-3912-48c0-c2c7-645e9c41249d.png)


このファイルを書き換えることでnaruの設定を上書きすることができます。

初期の`naru.config.js`は下のようになっています。

```naru.config.js
module.exports = {
  componentsPath: './components',
  pagesPath: './pages',
  layoutsPath: './layouts',
  middlewarePath: './middleware',
  pluginsPath: './plugins',
  storePath: './store'
}

```

例として`naru`でコンポーネントを作成するディレクトリを`parts`にしたい場合は`componentsPath`を`./parts`にするとできます。

またコンポーネントなどの雛形を自分で作成したい場合は`./naru`直下に対応する雛形の名前のファイルを作成してください。

例：コンポーネントの雛形を作成する際は`.naru`直下に`component.vue`というファイルを作成します。

**作成した際のスクショ**
![スクリーンショット 2019-04-14 20.19.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154299/49d3a67b-1eca-b248-92b4-a3f617c13db5.png)

**雛形ファイルの例**

```component.vue
<template>
  <div class="component">
    Component Template
  </div>
</template>

<script>
export default {}
</script>

<style></style>

```

対応する雛形の名前

- コンポーネント → `component.vue`
- ページ → `page.vue`
- レイアウト → `layout.vue`
- ミドルウェア → `middleware.js`
- プラグイン → `plugin.js`
- Vuexストア → `store.js`

# まとめ
こういうCLIツールを開発したのは初めてでした。いい経験になりました。
ちなみにライブラリは[oclif](https://oclif.io/)というものを使っています。結構便利でした。
基本情報技術者過去問題 平成29年秋期 午前問2 について

参考サイト:
http://e-words.jp/w/CRC.html
https://www.fe-siken.com/kakomon/16_haru/q63.html

#問題
送信側では，ビット列をある生成多項式で割った余りをそのビット列に付加して送信し，受信側では，受信したビット列が同じ生成多項式で割り切れるか否かで誤りの発生を判断する誤り検査方式はどれか。

>
ア：CRC方式
イ：垂直パリティチェック方式
ウ：水平パリティチェック方式
エ：ハミング符号方式

#解答
ア：CRC方式

#CRC方式とは？
Cyclic Redundancy Check。
巡回冗長検査。
誤り検出方式の一つで、データを値とみなしてある定数で割った余り（余剰）を用いて誤りの検知を行なうもの。

<font color="red">生成多項式</font>というキーワードが出たら、CRC方式と覚えましょう。
GitLabのExternal issue trackerを有効にし、GitLabからRedmineの関連チケットにリンクが張られるようにする

# 前置き

GitLabの"External issue tracker"という機能を有効にします。
これはコミットメッセージにチケット管理ツールのチケット番号を含めると、自動的にチケットへのリンクを張ってくれるというものです。

今回はGitLabからRedmineにリンクを張ってみます。

例えばコミットメッセージに`Update README.md CENTRAL_SERVER-136`と記述した場合、
GitLabの画面上からコミットメッセージを見ると、以下の画像ようにRedmineへのリンクが張られるようになります。

![p1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/231426/4a0ee2ea-a675-f53e-a4cf-6109149f2b1f.png)

# 環境

- GitLab CE Omunibus 11.9.4

Redmineのバージョンはなんでも大丈夫です。
GitLabから一方的にRedmineへリンクを張る機能なので、操作は全てGitLabで完結します。

# GitLabの公式ドキュメント

- External issue trackerについて(英語)
  - https://docs.gitlab.com/ee/integration/external-issue-tracker.html
- Redmineの設定について(英語)
  - https://docs.gitlab.com/ee/user/project/integrations/redmine.html

# 手順

全て公式ドキュメントの通りに進めます。

## Redmine issue trackerの設定画面にアクセス

有効にしたいプロジェクトで画像の順にクリックし、Redmine issue trackerの設定画面を開きます。

![p2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/231426/2aeb202d-f79e-b94e-f37e-0c4c53d120d7.png)

## Redmine issue trackerの設定

Redmine issue trackerの設定を行います。

![p3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/231426/75128e11-d5f2-1c51-f5a7-fb77a35af762.png)

| 項目名 | 入力例 |
|:------:|:------:|
| Description | Redmine issue tracker |
| Project url | https://example.com/projects/sandbox |
| Issues url | https://example.com/issues/:id |
| New issue url | (なんでもよい) |


`New issue url`は現在使われておらず、将来のバージョンで削除されるとのことです。
未入力だとエラーになるので、適当に何か入力します。

Redmineが自己署名証明書(オレオレ証明書)の場合、保存しようとした時にエラーになります。
そのため自分の場合、テスト環境で事前確認ができず、最初から本番環境で試すことになってしまいました。

## GitLabのIssuesの無効化

GitLabのIssuesを無効化しておきます。
私のプロジェクトの場合、Redmineで全てのチケットを管理し、GitLabはコード管理のみとしています。

![p4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/231426/c034de2a-bdcd-6cb9-8753-b0c2ce1a0519.png)

## 動作確認

最後にRedmineのプロジェクト番号やチケット番号をコミットメッセージに入れてみます。

1番目のようにチケット番号のみでリンクを張りたい場合、GitLabのIssuesは必ず無効化してください。
GitLabのIssuesを使用したい場合は2番目のようにプロジェクト名も必ず含めるようにしてください。

プロジェクト名は「大文字、"-"(ハイフン)でなく"_"(アンダースコア)で繋ぐ」というルールがあるので、3番目は失敗しています。

```
git commit -m "Update README.md #136
git commit -m "Update README.md REDMINE_PROJECT-#136
git commit -m "Update README.md redmine-project-#136
```

![p5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/231426/e594f911-c42d-5af8-0d0a-4b1451d08f71.png)

# 最後に

以上でGitLabのコミットメッセージからRedmineの関連チケットに簡単にアクセスできるようになりました。
クリック一つでGitLabからRedmineにアクセスできるのは少し嬉しいですね。

# その他

試していませんが、Redmine以外の"チケット管理ツール"と呼ばれる以下のツールもほとんど同じ手順で設定できるようです。

- YouTrack
- Jira
- Bugzilla
- Custom Issue Tracker