OmniAICreator/Qiita-1.07M huggingface dataset:
Raspberry Pi | I2C > I2Cセンサーの接続確認まで > 使用品 | 配線 | i2cdetect | link:Rasberry PIのI2Cコマンド詳解

```
Raspberry Pi 2 Model B (以下RPi)
Raspbian Jessie
Python 2.7.9
I2C接続のとあるセンサー
```

### 概要

I2C接続のとあるセンサーを使うことになった。
最終形は組込みCであるが、RPiで使い始めることで、トラブルの回避、問題の切り分けがしやすくなる。

### 使用

使用するものは以下の通り。

- RPi + 40ピンソケット加工品
    - [RPi > Link > GPIOオスメス変換 > 40ピンソケット2つ使用](https://qiita.com/7of9/items/ef7007748b112050555c)
    - ジャンパーピンを挿すことができる
    - i2cdetectやi2cdumpなどのコマンドを使えるようにしたもの
- ジャンパーピン
- ブレッドボード
- プルアップ抵抗 x 2 (図面の抵抗値)
- コンデンサ 104 (VCCとGND間)
- I2Cセンサー

RPiのケース上にブレッドボードを載せ、配線をしておく

### 配線

以下を使う。

- Pin# 01: VCC(3.3V)
- Pin# 03: SDA1
- Pin# 05: SCL1
- Pin# 09: GND

I2CとしてはCHANNEL1を使うことになる。

### RPiからの実行

```bash
$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
```

ただのしかばねのようだ。

[こちら](https://qiita.com/7of9/items/0a3398ccf226733679b7)に記載のmodprobeを実行する。

```bash
$ sudo modprobe -r i2c-bcm2708
$ sudo modprobe i2c-bcm2708 baudrate=50000
```

```bash
$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --      
```

I2Cセンサー(特技: xxx、yyy測定)が仲間になりたそうにこちらを見ている。
仲間にしますか?

- [x] はい
- [ ] いいえ

### 参考

- [Rasberry PIのI2Cコマンド詳解](http://www.hogetan.net/note/memo/pi_i2ccmd.html) @ かないノート
    - 分かりやすいです

### 組込みCでの実装

- TODO
    - [Raspberry Pi / I2C > I2Cセンサからデータを読み取る (成功編) / link: Raspberry Pi で I2C の Repeated Start Condition を有効化](https://qiita.com/7of9/items/0a3398ccf226733679b7)
        - リンク先の実装を試す
        - Pythonで組みたい気もするが。。。
    - low levelの実装に変更する
        - https://qiita.com/7of9/items/a1a42359cff9ed06778f
    - 対象マイコンでそのコードを使う

### Python実装

対象のセンサーのPython実装のコードが見つかった。
それで動作確認したところ、期待した値を取得できた。
これで、ハードチェックは完了した。
LibreOfficeのDocumentにPythonマクロを組み込む

http://christopher5106.github.io/office/2015/12/06/openoffice-libreoffice-automate-your-office-tasks-with-python-macros.html
####Interface-oriented programming in OpenOffice / LibreOffice : automate your office tasks with Python Macros

LibreOffice BasicではIDE（マクロのエディター）で作成したBasicマクロを「マイマクロ」、「LibreOfficeのマクロ」、「○○○.odt等」のどれかに記録するか指定できるが、Pythonマクロはマクロの保存場所が決められているので、ドキュメント内部に保存することが出来ない。

上記の記事では、ドキュメント内部に保存する方法が記載されている。

まず、上記の中にある「myscript.py」マクロを作成する。
Writer用とCalc用があるので注意。
（わかりにくいですが、検索で探すとすぐに見つかります。）

次に、「include_macro.py」マクロを作成する。

WriterかCalcのドキュメントを新規作成する。

端末から
$ python3 include_macro.py ○○○.odt
を実行する。

with_macroフォルダが作成され、その中に「○○○.odt」がコピーされて、マクロを組み込んでいます。

マクロを実行　ー＞　○○○.odt　に「myscript」が追加されています。

それを実行すると、PythonのVerが表示されます。

![fuyou.png](https://qiita-image-store.s3.amazonaws.com/0/238800/db100056-ca91-66f9-bab4-541be5a095ea.png)
今気がついたのですが、Verの方はあっていますがパスは「UbuntuのPython3」のパスですね。「myscript.py」のコードを参考にする場合は注意が必要です。
UbuntuのPython3はVer3.6.3です。
LibreOfficeのPythonは/opt/libreoffice6.0/program/pythonです。
（パスはVerによって違います。）
json-serverでエンドポイント毎にjsonファイルを分割する

# json-serverとは
WebAPIを利用したアプリケーションを開発している時に、APIをモックで置き換えたい事があると思います。json-serverはJSON形式のレスポンスを返すモックサーバを、簡単に構築できるライブラリです。

**json-server**
https://github.com/typicode/json-server


## インストール・起動方法
### インストール方法

インストールにはnodejsが必要です。npmを使ったインストール方法は以下の通りです。
```
npm install —-save-dev json-server
```

### 起動方法

あらかじめ、以下のようなjsonファイルを準備しておきます。
作成したjsonファイルを指定してjson-serverを実行すると、キー名をエンドポイントとしてjsonを返却するサーバがlocalhostに起動します。

```json
// end-point-name.json
{
  "end-point-name": {
    "items": [
      {
        "name": "hoge"
      }
    ]
  }
}
```

上記jsonファイルを指定してjson-serverを実行します。

```
json-server end-point-name.json
```

`http://localhost:3000/end-point-name`にアクセスすると、以下のようなjsonが返ってきます。

```json
{
  "items": [
    {
      "name": "hoge"
    }
  ]
}
```

# エンドポイント毎にjsonファイルを分割する方法
開発を進めるうちにモック用のjsonファイルは肥大化するため、エンドポイント毎にjsonファイルを分割したくなるのですが、json-serverには1つのファイルしか渡すことができません。

そこで、複数のjsonファイルを結合するスクリプトを自前で組む必要があります。
jsonファイルを監視して`mock.json`という名前の巨大なjsonを生成し、それをjson-serverに渡します。

以下のディレクトリ構成でファイルを配置します。

```
/
  /api - エンドポイント毎のjsonファイルを格納
    - end-point-name-1.json
    - end-point-name-2.json
    - end-point-name-3.json
    - ...
  /scripts
    - merge_mock_json.js - mock.jsonファイルを生成する
mock.json
```

```javascript
// merge_mock_json.js

const fs = require('fs');
const path = require('path');

// ルートパスを設定
const root = path.resolve('./', 'api');

fs.watch(root, function(event, filename) {
  if (api === undefined) { api= {} };

  // jsonファイルのみ処理する
  if (path.extname(file) == '.json') {

    // /api/mock配下にあるjsonファイルの名前をエンドポイントとして読み込む
    const api = fs.readdirSync(root).reduce((api, file) => {
      const endpoint = path.basename(file, path.extname(file));
      api[endpoint] = JSON.parse(fs.readFileSync(root + '/' + file, 'utf-8'));

      return api;
  }
  }, {});
  fs.writeFile(root + '/../mock.json', JSON.stringify(api), function(err) {
    if (err) throw err;
    console.log('mock file updated.');
  });
});
```

上記スクリプトとjson-serverを並列実行するため、npm-run-allというライブラリをインストールします。

```
npm install --save-dev npm-run-all
```

`package.json`にnpm scriptsを記載します。

```json
{
  ...
  "scripts": {
    "serve": "npm-run-all -p create-mock boot-mock",
    "create-mock": "node ./scripts/merge_mock_json.js",
    "boot-mock": "json-server --watch ./mock.json",
    ...
  },
  ...
}
```

`npm run serve`でモックが起動します。

json-serverはその他にも検索やルーティング、POSTでデータを保存するなど、WebAPIのモックとしては充分な機能が揃っており、とても便利です。
ぜひ使ってみてください。
Railsでwebpackerを入れるとherokuへのデプロイでこける時の対処法

# 環境
* Rails 5.1.5
* webpack 3.11.0

# エラーメッセージ
```
remote:        Webpacker is installed 🎉 🍰
remote:        Using /tmp/build_a60546bb726d2fa7f4b8b4ac052f461e/config/webpacker.yml file for setting up webpack paths
remote:        Compiling…
remote:        Compilation failed:
remote:        bundler: failed to load command: webpack (/tmp/build_a60546bb726d2fa7f4b8b4ac052f461e/vendor/bundle/ruby/2.3.0/bin/webpack)
remote:        Errno::ENOENT: No such file or directory - /tmp/build_a60546bb726d2fa7f4b8b4ac052f461e/node_modules/.bin/webpack
```

# 対策
```
heroku buildpacks:clear
heroku buildpacks:set heroku/nodejs
heroku buildpacks:add heroku/ruby
```
https://github.com/rails/webpacker/issues/739#issuecomment-327546884

# 原因
heroku buildpacksのデフォルトのnode関連のエンジンのバージョンが古いためのようです。

# 参考
https://github.com/rails/webpacker/issues/739
https://github.com/rails/webpacker/issues/1282
https://github.com/heroku/heroku-buildpack-ruby/issues/712
https://qiita.com/tatsuyankmura/items/728e190b92e0370eefbb
WP TinyMCE Advanced で投稿エディターにオリジナルスタイルを追加する

2018.02.27
自分用メモなので、ちゃんとまとまってないです！

# TinyMCE Advancedにオリジナルスタイルを追加したい
1. divとかにクラスつけてくくりたい
2. h4とかもクラスつけたい
3. エディターにもCSS反映させたい

# editor-style.cssを使う
1. wp-content/theme/ [自分の使ってるテーマ] の下に配置する。
2. header.php で読み込む。

editor-style.cssで追加したクラスなどが、TinyMCE Advancedのスタイルボックスで選択できるようになります。

editor-style.cssは、**エディターと投稿表示画面両方に適用されます**！

## エディター画面にのみCSSを反映させる
エディター画面にのみ反映させたいCSSは、`#tinymce`をつけて記述します。

```css
#tinymce p{
    color: red;
}
```
BeanCreationException が止まらないからeclipse 追ってみた。

### 諸注意
<ul>
<li>コンプライアンスの問題によりスクショ等は載せておりません。</li>
<li>新人エンジニア向けの記事です。eclipse を細部までご存知の方にとっては読む価値の無い物です。</li>
<li>"mvn clean install" すると問題が解決するけど、なぜ解決しているのか理由が分からない" という新人さんにお勧めです。</li>
</ul>

## 問題: BeanCreationException が解決しない
eclipse 上で、Bean を定義している.java, .xml を修正しても解決しなかった事が、今回記事を書く事になった理由です。

## 解決策: target 配下を見てみよう
eclipse 上で編集したデータはtarget ディレクトリ配下に反映され、それらが実行されます(main/java, main/resources 配下のファイルが直接実行されるワケではない)。
eclipse へJAVA プロジェクトをimport する際に、<font color="DeepPink">.classpath</font> というファイルも含まれているのですが、コイツの中でtarget 配下が定義されている様です。

### i) Java ファイルでBean 定義している場合
基本的にはmain/java 配下を編集してセーブした場合、target 配下のclass ファイルに反映されるはずです。
class ファイルは(基本的には)直接弄れないはずなので、どうしてもエラーが解決しない場合は`mvn clean install`し直してみましょう。
※これによりtarget ディレクトリが一度削除されて.java ファイルを元に.class ファイルが作り直されます。
<a href="https://maven.apache.org/plugins/index.html" target="_blank">Maven 公式</a>


### ii) xml ファイルでBean 定義している場合
こっちのケースが曲者で、コレこそが今回記事を殴り書いた一番の理由です。
.java ファイルの場合、eclipse で編集して"Refresh" をするとtarget 配下に反映されるのですが、<font color="DeepPink">.xml ファイルは"Refresh" しても反映されません！</font>
.xml ファイルの修正を反映するには、target 配下に存在する同名の.xml ファイルを修正するか、`mvn clean install` し直す必要がある様です。※因みに`mvn compile` では反映されませんでした。
著者はmain/resources 配下の<font color="DeepPink">実行パスにすら含まれていないファイル</font>を修正して「直らねぇ！」と嘆いていたワケです。皆さんが同じ轍を踏まないように願っています。

## まとめ
現場からは以上です。
`mvn clean install` で何となく問題が解決してしまうのは、何らかの事情で.java ファイルが"Refresh" されていなかったり、target 配下の.xml ファイルが修正されていない場合でも、target 配下が0 から作り直されるからなんです。
この辺りは公式ドキュメント追ってみると理解が深まると思うので、最後にリンクを貼って終わりにします。
<a href="https://maven.apache.org/plugins/index.html" target="_blank">Maven 公式ドキュメント</a>
<a href="https://www.eclipse.org" target="_blank">eclipse 公式ドキュメント</a>
Inside Wine; 関数名など

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; 関数名など

### Win32 API で最初に呼び出される関数

Xxxx という名前の Win32 API について、WINE で最初に実行が開始される関数は、

~/wine/dlls/yyyy.c

の中に、

```c:~/wine/dlls/yyyy.c
ZZZZ WINAPI Xxxx(・・・)
{
  ・・・
  
  return zzzz;
}
```

のような形式で関数定義されている。この関数の中から、以下に述べるような「server 関数」が呼び出されることがある。「server 関数」の名称や、リクエストの名前は、Xxxx と似ていることが多い。




## server 関数

server 関数の本当の関数名は、req_xxxx() である。しかし、これで grep 検索しても見つからない。それはマクロが用いられているためで、実際は、/wine/server/ フォルダの中の *.c 内に、DECL_HANDLER(xxxx) を最初の行として、実際の関数定義がある。

【server 関数の呼び出し】

```c:
SERVER_START_REQ(xxxx)
・・・
SERVER_END_REQ;
```

・・・の中には、以下のいずれかが来る :
1. wine_server_call( req )
2. wine_server_call_err( req )

【server 関数の実装】

/wine/server/yyyy.c

の中の :

```c:~/wine/server/yyyy.c
DECL_HANDLER(xxxx)
```


【server 関数の呼び出し例】

```c:~/wine/dlls//user32/win.c
static WND *create_window_handle( HWND parent, HWND owner, LPCWSTR name,
```

関数の中からの例 :

```c:~/wine/dlls//user32/win.c
 SERVER_START_REQ( create_window )
    {
        req->parent   = wine_server_user_handle( parent );
        req->owner    = wine_server_user_handle( owner );
        req->instance = wine_server_client_ptr( instance );
        if (!(req->atom = get_int_atom_value( name )) && name)
            wine_server_add_data( req, name, strlenW(name)*sizeof(WCHAR) );
        if (!wine_server_call_err( req ))
        {
            handle      = wine_server_ptr_handle( reply->handle );
            full_parent = wine_server_ptr_handle( reply->parent );
            full_owner  = wine_server_ptr_handle( reply->owner );
            extra_bytes = reply->extra;
            class       = wine_server_get_ptr( reply->class_ptr );
        }
    }
    SERVER_END_REQ;
```



## 効率的な grep 検索

以下のようにすると効率よく検索できる。

### Win32 API で最初に呼び出される関数を検索したい時

Xxxx という名前の Win32 API について、WINE で最初に実行が開始される関数の関数定義を検索したい場合、

```
探す場所:     /wine/dlls/
探すファイル: *.c
検索文字列:   WINAPI Xxxx
```

とすると良い。

### SERVER_START_REQ(xxx_yyy) のリクエストを処理する関数を検索したい時

関数名は、req_xxx_yyy で、関数定義は、/wine/server フォルダの *.c ファイルに、DECL_HANDLER(xxx_yyy) を先頭の行として存在している。このことを知ってないと、検索するのは難しいが、次のようにすると楽に検索できる。

```
探す場所:     /wine/server/
探すファイル: *.c
検索文字列:   (xxx_yyy)
```


### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ



## end
Contact Form7で独自ショートコードを使う際「wpcf7_add_shortcode」も「wpcf7_add_form_tag」も要らなかった

Contact Form7を利用して運用しているフォームで独自ショートコードを使用する必要が出てきたため、調べたところ`wpcf7_add_shortcode`や`wpcf7_add_form_tag`についての情報が出てきました。
<strong>結論から言うと、これらの関数を使う必要はなく単純に`add_shortcode`でいけました。</strong>なんでや…。
この記事では私の一連の行動を記録しておきます。

#動作環境
この情報は下記の環境で起こった内容をまとめております。
- Wordpress 4.9.4
- Contact Form7 Ver 5.0 

#`wpcf7_add_shortcode`を使ってみるも動かない
検索でひっかかった情報から`wpcf7_add_shortcode`を使うとええんやな！と理解してやってみるもショートコードが表示されるだけで動かない。

こういう時は公式サイト！ということでContact Form 7のサイトを見たところ[ver4.6のリリースノート](https://contactform7.com/ja/2016/12/03/contact-form-7-46/)に下記の通り記載されておりました。

>##WPCF7_Shortcode は非推奨に
>WPCF7_Shortcode クラスは廃止予定につき使用非推奨になります。カスタムコードで WPCF7_Shortcode >を使用している場合は WPCF7_FormTag に変更してください。そうしないと、デバッグモードで運用している場>合に警告が表示されます。
>この改名を行った理由は、”shortcode” という用語が紛らわしかったからです。実際には Contact Form 7 プラグインのフォームタグを指すものですが、あたかも WordPress 自身のショートコードを指しているかのように誤解させていました。これら二つはよく似ていますが根本的に異なる概念です。
>同様の理由から、その他のいくつかのクラス、メソッド、関数についても非推奨化されています。

>| 廃止予定 | 代替 |
| WPCF7_Shortcode | WPCF7_FormTag |
| WPCF7_ShortcodeManager | WPCF7_FormTagsManager |
| wpcf7_add_shortcode() | wpcf7_add_form_tag() |
| wpcf7_scan_shortcode() | wpcf7_scan_form_tags() |

という事で`wpcf7_add_form_tag`を使ってみることに。

#`wpcf7_add_form_tag`でも動かない
他様のサイトのサンプルを参考にソースを書いてみるも出力されるのは無慈悲なショートコード。
元々の関数が悪いのかと思って試しに`add_shortcode`を使って他のページに出力してみる。
希望通りに出力されました。なんでやねん。

#`add_shortcode`で書いたショートコードをフォーム内に追加したら動いた
ダメ元と思いながらもフォーム内に↑で追加したショートコードを書いたら希望通りに出力されました。
***
ということで一連の顛末でした。
もしも`wpcf7_add_shortcode`や`wpcf7_add_form_tag`を使用してもショートコードが動かないという方がいらっしゃったら参考にしてください。
スマホとPCのデバイスごとにhtmlファイルを切り分ける方法 ~『JavaScript』で条件分岐~

この前、パソコンとスマートフォンで表示させるhtmlファイルを変えたかった時に調べたのでメモがてら。

以下のコードをパソコンでの閲覧時に表示させたいファイルのhead内に記述することで、デバイスごとに条件分岐させることができます。

```html
<script type="text/javascript">
if ((navigator.userAgent.indexOf('iPhone') > 0 && navigator.userAgent.indexOf('iPad') == -1) || navigator.userAgent.indexOf('iPod') > 0 || navigator.userAgent.indexOf('Android') > 0) {
	// スマホ用のページにリダイレクトする
	location.href = '/sp/';
}
</script>
```

## 追記
このあと汎用CSSファイルが効かなくなったので別汎用ファイルを用意したのですが、何か理由があるのでしょうか、、

## 参考
https://manablog.org/sp-pc/
zshの起動がまた遅くなった(oh-my-zshのcomposerプラグイン)

しばらく前からまた遅くなった気がしてたんだけどちょっとやる気になったので真面目に調べたらoh-my-zshのcomposerプラグインのロードに300ms強かかっていることが判明。

`composer.plugin.zsh`の中身をざっと見るとほとんどは補完設定とかalias定義だけど最後の行に怪しいの発見。

```zsh
# Add Composer's global binaries to PATH
export PATH=$PATH:$(composer global config bin-dir --absolute 2>/dev/null)
```

時間を計ってみると

```console
% time composer global config bin-dir --absolute
Changed current directory to /Users/matsui/.composer
/Users/matsui/.composer/vendor/bin
composer global config bin-dir --absolute  0.17s user 0.10s system 89% cpu 0.305 total
```

てな具合でビンゴ。

どう対策するか考えたんだけど、

* どうせほとんどの場合は`~/.composer/vendor/bin`になるんだろうけど変な設定をしてる人がいるかもしれないと考えるとプラグインとしては一般性をもたせて`composer global config bin-dir --absolute`でとるしかないのかな
* composerコマンドがただパスを出力するだけにしては遅い気がするけどちょっと手を出すのは難しそう

ということで直してもらうのも難しそうだし[^1]、といってforkして改造するのも後が面倒で気が進まないのでプラグインのロード中だけcomposerコマンドをaliasで置き換えるように`.zshrc`に記述することにした。

```zsh

alias composer="echo $HOME/.composer/vendor/bin"

zplug load # --verbose

unalias composer
```

[^1]: いちおうoh-my-zshの方に遅いからキャッシュとかして欲しいというissueを出してみた。( https://github.com/robbyrussell/oh-my-zsh/issues/6647 ) ただ、oh-my-zshはissuesもPRも何百オーダーで溜まっているので対応はあまり期待できない気がする。
Inside Wine; DLL と共有ライブラリの関係

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; DLL と共有ライブラリの関係


## WINE の DLL に関して

本当に WINE によって実装されている dll の場合、例えば、user32.dll の場合なら、

```
user32.dll.so
```

などが本体。中身は、Linux が直接理解できる「共有ライブラリ」の形式になっている。

他に、user32.dll.fake なるものがある。これは、Win32 の PE 形式の DLL を模倣したもので、基本的に中身は偽者であるハズ。ただし、Win32 や アプリ自体が、このファイルを読んで何かやることがある場合には、偽者であっても、PE 形式のそれらしきファイルが存在している事が必要となる可能性がある。

WINE 公式で、「native」な、DLL とされるものは、Windows OS にとっての native という意味である。Linux にとっては、*.dll.so の方が native である。

## WINEDLLPATH

user32.dll.so などが探される場所として、環境変数 WINEDLLPATH が参照される。ただし、本家から DL したままだと、検索の優先順位に問題があるため、修正しないと上手く行かない :

[WINEDLLPATHの不具合] (https://qiita.com/Yutaka_Aoki/items/3b61104197b22e3ccd1a)


## libwine.so.1.0

"~/wine/libs/wine"

libwine.so.1.0     # ELF 形式の共有ライブラリ, loader など。
libwine.so.1 -> libwine.so.1.0
libwine.so   -> libwine.so.1.0

本体は、libwine.so.1.0 であるが、WINE 起動時に実際に探されるファイル名は、libwine.so.1 らしい。そのため、

```
$ ln libwine.dll.so.1.0 libwine.dll.so.1
```


の意味でのリンクが用意されている。wine は、dll.so.1.0 ではなく、dll.so.1 の方を探すのである。この性質を利用すると、dll.so の検索パスを「偽装」して、make install しないで済ますことができることがある。


### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ



## end
Tips: Kerasで Resource exhausted: OOM when allocating tensor が出る時チェックすること

ずばり

```
config.gpu_options.allow_growth = True
```
にしてないでしょうか。

`Resource exhausted: OOM when allocating tensor...` のエラーはGPUのメモリが足りないときに出るようです。
そして、 `config.gpu_options.allow_growth` を `True` にすると、
実行時に必要な分だけ確保するようになる、というメリットがあるものの、
一方で自動的にはメモリを開放しないので、メモリが断片化して性能が悪化する可能性がある、とのことでした。

私のケースではこの記述を削除した所、エラーが起きなくなりました。

※[@namakemono さまの記事](https://qiita.com/namakemono/items/12ad8a9f6d0561929056)を参考にさせて頂きました。

以上です！
高卒エンジニアによる初めての自作アプリ～序章～

#はじめに
この記事は連載物になります。
初心者の方がこの記事を見ながらアプリを作れるようになったら嬉しいなと思い、
毎回細かい内容まで書こうと思ってます。
おそらくベテランの方には何の役にも立たない記事です。
しかしこれを職場の新人君であったりに共有することで、
新人君のモチベーションにつながり、
僕の記事が伸びればそれでいいです。
#作者について
- 普通科高校卒業後塾講師を1年
- 完全未経験やる気採用で都内SI系零細企業に転身
- 最初はAndroid開発がメイン
- 半年で運用保守チーム(名ばかりのなんでも屋さん)に異動
- 北関東支社設立計画のリーダーに指名されそうになる
- 入社10ヶ月で退職し個人事業主に転身(この2月に退職したて)
- 重度のApple信者
    - しかしJavaが大好きなのでAndroidを持ってないのにAndroid開発ばっかやってる

今は大手SIと契約し常駐しながら、勉強会の司会や個人事業なんかをやってます。

#なぜ作るのか
塾講師の時も零細SIでも割と稼働時間がすごいことになっており、
趣味はたまの土日に酒を飲みながらコードのリファクタリングをゆったりとやることでした。
(今年もあんな風に夏休みを過ごしたい)
ただ大手SIは僕には暇すぎでした。
業務中の1/3をQiitaに、1/3をアプリの設計にあてても稼働時間が足りない(仕事がない)
激務に慣れるとこんな弊害がでるんですね()
とゆうわけでちゃんとアプリ作ってQiitaにも書こうと思った次第です。

#作りたいもの
ジャンルとしてはマッチングアプリになると思います。
送信者の端末からSNSのIDを拡散する(1日2回の制限有)と不特定の10人にそのIDが送信されるというものです。
Firebaseを使いながらサーバーレスで実装しようと考えてます。
またデザインと実装の一部は仲間にも手伝ってもらいながらやろうかと考えてます。
#次回予告
次回は設計編になります。
仕事しながら書いているので次は3月中旬くらいですかね。
まあこんな人でもフリーランスでやっていけるし月商45くらいあるからなんか励みになればとおもいます。
JavascriptからWebAPIを呼び出す前にオフラインの判定をする

## オフライン判定の重要性
Webアプリケーションを開発するうえで、JavascriptからWebAPIを呼び出してデータを取得することはよくあります。最近であれば`axios`のようなhttpクライアントのライブラリが人気で、簡単に実装することができるようになりました。HTTPリクエストを扱うにあたって、返却されたレスポンスのステータスコードなどを見てフロントエンドでエラーメッセージを表示する、ということはよくやっているかと思いますが、オフラインの場合は503のようなエラーコードが取得できません。オフライン時に適切なメッセージを表示することでユーザに気づかせることができます。

## Javascriptでオフラインの判定をする
長々と前フリをかきましたが、実装方法は至ってシンプルです。

```javascript:request.js
if (!navigator.onLine) {
  alert('オフラインになっています。電波状況が良い場所で再度お試しください。');
} else {
  // HTTPリクエストを投げる処理
}
```

## ブラウザ実装状況
https://developer.mozilla.org/ja/docs/Web/API/NavigatorOnLine/onLine
こちらを見ると、「？」が多いですが、私の手元で下記確認してます。

- Mobile Safari 10/11
- Mobile Chrome


おしまい。
PostgreSQLでカタログファイルが見つからない

# 状況

日次でデータベースよりデータを抽出してファイルに書き出すバッチファイルを動かしていた。
ある日、出力結果を確認してみたところ、空っぽになっていた。


# 環境等

- Linux 4.14.13-200.fc26.x86_64
- PostgreSQL 9.6.6


# 状況調査

## 出力ファイルの確認

空っぽ。

## 出力ファイルの元となるビュー、テーブルのデータ確認

ビューを確認すると、空っぽ。

ビューの元となるテーブルを参照すると、データは存在するように見える。


## PostgreSQLのログ確認

```text
[2018-02-27 08:25:19 JST][11420][][] ERROR:  トランザクション3960637355のステータスにアクセスできませんでした
[2018-02-27 08:25:19 JST][11420][][] 詳細:  ファイル"pg_clog/0EC1"をオープンできませんでした: No such file or directory。
[2018-02-27 08:25:19 JST][11420][][] コンテキスト:  テーブル"hoge.public.sometable"の自動解析
[2018-02-27 08:26:19 JST][11437][][] ERROR:  トランザクション3960637355のステータスにアクセスできませんでした
[2018-02-27 08:26:19 JST][11437][][] 詳細:  ファイル"pg_clog/0EC1"をオープンできませんでした: No such file or directory。
[2018-02-27 08:26:19 JST][11437][][] コンテキスト:  テーブル"hoge.public.sometable"の自動解析
[2018-02-27 08:27:19 JST][11445][][] ERROR:  トランザクション3960637355のステータスにアクセスできませんでした
[2018-02-27 08:27:19 JST][11445][][] 詳細:  ファイル"pg_clog/0EC1"をオープンできませんでした: No such file or directory。
```
ふぁっ？！

**`pg_clog/0EC1` が無いとおっしゃる**

念のため確認

```bash
$ sudo su - postgres
-bash-4.4$ cd /var/lib/pgsql/data/pg_clog
-bash-4.4$ ll
合計 4392
-rw-------. 1 postgres postgres 262144 12月 21 11:03 0000
-rw-------  1 postgres postgres 262144 12月 21 13:08 0001
-rw-------  1 postgres postgres 262144 12月 21 21:28 0002
-rw-------  1 postgres postgres 262144 12月 22 19:59 0003
-rw-------  1 postgres postgres 262144 12月 23 18:34 0004
-rw-------  1 postgres postgres 262144 12月 24 16:49 0005
-rw-------  1 postgres postgres 262144 12月 25 08:59 0006
-rw-------  1 postgres postgres 262144  1月  9 20:40 0007
-rw-------  1 postgres postgres 262144  1月 10 13:55 0008
-rw-------  1 postgres postgres 262144  1月 12 10:06 0009
-rw-------  1 postgres postgres 262144  1月 13 12:21 000A
-rw-------  1 postgres postgres 262144  1月 15 01:52 000B
-rw-------  1 postgres postgres 262144  1月 15 11:57 000C
-rw-------  1 postgres postgres 262144  1月 16 00:37 000D
-rw-------  1 postgres postgres 262144  1月 17 01:28 000E
-rw-------  1 postgres postgres 262144  1月 18 02:08 000F
-rw-------  1 postgres postgres 262144  2月 20 01:43 0010
-bash-4.4$ 
```

確かに無い。



# 対応

実際にやってみたこと

## pg_ctlgのバックアップ

早急にPostgreSQLを止めて、`pg_ctlg`ディレクトリのバックアップを取得する。

```bash
$ sudo systemctl stop postgresql.service
$ sudo su - postgres
-bash-4.4$ cd /var/lib/pgsql/data
-bash-4.4$ cp -r pg_ctlg pg_ctlg.bk
-bash-4.4$ 
```

## 空のカタログファイルの手動作成

ブロックサイズを合わせる必要があるようなので
`dd`コマンドを用いて指定サイズ(256k)でゼロ埋めされたファイルを作る

```bash
$ sudo su - postgres
-bash-4.4$ dd if=/dev/zero of=/var/lib/pgsql/data/pg_clog/0EC1 bs=256k count=1
```

## データベースを起動し、`VACUUM` を実行する

念のため

```bash
$ sudo systemctl start postgresql.service
$ sudo su - postgres
-bash-4.4$ vacuumdb -a -v F
```

公式ドキュメントによると、 `vacuumdbはPostgreSQLの問い合わせオプティマイザが使用する内部的な統計情報も生成します。` とあるので、カタログファイルを再生成してくれないかなーと期待を込めて

https://www.postgresql.jp/document/9.2/html/app-vacuumdb.html


## 動作確認

ビューの元となるテーブルを参照すると、今まで通りデータは存在するように見える。

**クライアントより、テーブルのソートを行ったところ、メモリをアロケートできない旨のエラーが表示された。**

なんじゃらほい ＿(┐「ε:)_

(具体的なエラーメッセージは失念)

**しかし、この状態で十分ほど放置していたら直った。謎い。**


# 所感

どうして直ったのか分からないので、大変モヤモヤする結果となった。
データ加工におけるRvsPython対応表 (随時更新予定)


RとPythonを両方使っていると、「あれ？RのこれってPythonでどうやるんだっけ？」とよくなる (逆もまた然り) ので、自分用にメモ。
ひとまず、データ加工についてまとめてみます。
気付いたら適宜追記します。

## 略記
x: 任意の1次元配列 (Pythonはlistとarrayがある点に注意→コメント欄で補足)
n: 任意の整数値
str: 任意の文字列
df: 任意のデータフレーム
func: 任意の関数
(上記以外にfilenameとかvarとか唐突にでてきますが、なんとなく察して下さい)

## 前提
Rは{tidyverse}を使用 (`library(tidyverse)`)
Pythonはnumpy, pandasを使用 (`import numpy as np; import pandas as pd`)
バージョンは、執筆時点の最新版を使用

## データの処理

|やること|R|Python|コメント|
|---|---|---|---|
|論理値を表現する|`TRUE`, `FALSE`|`True`, `False`|大文字小文字に注意|
|データ型を確認する|`str(x)|`type(x)`||
|引数の有無を確認する|`missing(var)`|`var == None`|関数内で使用|

## 配列の処理

|やること|R|Python|コメント|
|---|---|---|---|
|2値化する|`ifelse(x>=0.5, 1, 0)`|`np.where(x >= 0.5, 1, 0)`|左記は0-1の範囲の配列を四捨五入する処理|
|配列の各要素を処理|`sapply(x, func)`|`[func(r) for r in x]`||
|任意の長さの配列を作る (値は0)|`numeric(length = n)`|`[0 for _ in range(n)]`<br>または`np.zeros(shape = n)`||
|共通の要素を取り出す|`x1[x1 %in% x2]`|`set(x1) & set(x2)`||
|数値を0詰めしてn桁に揃える|`formatC(x, width = n, flag = "0")`|`str(x).zfill(n)`|xは数値型. 出力は文字列型|

## データフレームの処理

|やること|R|Python|コメント|
|---|---|---|---|
|csvを読み込んでデータフレームにする|`read_csv(filename, ...)`|`pd.read_csv(filename, ...)`||
|配列をデータフレームにする|`as.data.frame(x)`|`pd.DataFrame(x, columns = ["colname"])`||
|データの次元数を見る|`dim(df)`|`df.shape`||
|欠損のある行を除く|`na.omit(df)`|`df.dropna()`||
|論理値の配列で抽出して、行番号を振り直す|`filter(df, boolean)`|`df[boolean].reset_index(drop = True)`||
|行番号で抽出する|`slice(df, x)`|`df.ix[x]`||
|横向きに結合する|`cbind(df1, df2)`|`pd.concat([df1, df2], axis = 1)`|concatをaxis=0にするとRのrbindになる|
|列ごとに集計関数を適用する|`apply(df, 2, func)`|`df.apply(func)`||
|csvに書き出す|`write.csv(df, "filename.csv", ...)`|`df.to_csv("filename.csv", ...)`||
Inside Wine; MDI Child Window のタイトルバーのドラッグ

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; MDI Child Window のタイトルバーのドラッグ


## Wine で、MDI Child Wnd の TITLE BAR をドラッグしたときの処理

```c:
DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
-->case WM_NCLBUTTONDOWN
-->NC_HandleNCLButtonDown()
-->case HTCAPTION
-->SendMessageW( hwnd, WM_SYSCOMMAND, SC_MOVE + HTCAPTION, lParam )
-->DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
-->case WM_SYSCOMMAND
-->NC_HandleSysCommand()
-->WINPOS_SysCommandSizeMove()
```

マウスをクリックしてドラッグを開始してから、マウスを離すまで、最後の関数の中のメッセージループの中を回り続けて戻ってこない。

```c:
void WINPOS_SysCommandSizeMove( HWND hwnd, WPARAM wParam )
```

内部には、GetMessageW() のループがあり、次のようなコードがある :

```c:~/wine/dlls\user32\winpos.c"
                if (!iconic)
                {
                    if(!DragFullWindows)
                        draw_moving_frame( parent, hdc, &sizingRect, thickframe );
                    else
                    {
                        RECT rect = sizingRect;
                        MapWindowPoints( 0, parent, (POINT *)&rect, 2 );
                        SetWindowPos( hwnd, 0, rect.left, rect.top,
                                      rect.right - rect.left, rect.bottom - rect.top,
                                      ( hittest == HTCAPTION ) ? SWP_NOSIZE : 0 );
                    }
                }
```

ここで、draw_moving_frame() は、XOR 反転枠を書く関数らしい。上記を見ると、実際に動かす前に「枠」を書くか、実際の Window の位置を即座に動かしてしまうかは、変数 DragFullWindows の値によって変更するようになっている事が分かる。




### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ



## end
Inside Wine; WM_MOUSEMOVE メッセージの生成

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; WM_MOUSEMOVE メッセージの生成



## 通常時、WM_MOUSEMOVE がキューへ追加される時の実行経路

```c:
X11DRV_MsgWaitForMultipleObjectsEx()
--> process_events()
---> call_event_handler( Display *display, XEvent *event )
---> handlers[event->type]( hwnd, event );
      event->type = MotionNotify (6)
---> X11DRV_MotionNotify( HWND hwnd, XEvent *xev )
      XMotionEvent *event = &xev->xmotion;
      INPUT input;
---> send_mouse_input( hwnd, event->window, event->state, &input );
---> __wine_send_input( HWND hwnd, const INPUT *input )
---> send_hardware_message( hwnd, input, 0 );
      SERVER_START_REQ( send_hardware_message ) {
        switch (input->type)
        case INPUT_MOUSE:
      }
---> wine_server_call( req );
---> DECL_HANDLER(send_hardware_message)
     (send a hardware message to a thread queue)
---> queue_mouse_message( desktop, req->win, &req->input, req->flags, sender );
     messages[MOUSEEVENTF_MOVE (1)] = WM_MOUSEMOVE
---> queue_hardware_message() : WM_MOUSEMOVE
        list_add_tail( &input->msg_list, &msg->entry );
        set_queue_bits( thread->queue, get_hardware_msg_bit(msg) );
--->
    if (!always_queue || merge_message( input, msg )) free_message( msg );
    else {
        msg->unique_id = 0;  /* will be set once we return it to the app */
        list_add_tail( &input->msg_list, &msg->entry );
        set_queue_bits( thread->queue, get_hardware_msg_bit(msg) );
    }
```

## WM_NCMOUSEMOVE は WM_MOUSEMOVE から修正される

PeekMessageW() または GetMessageW() の中で、hittest が HTCLIENT 以外
の場合は、WM_MOUSEMOVE が WM_NCMOUSEMOVE に修正される :

```c:
PeekMessageW() または、GetMessageW()
---> peek_message()
---> switch(info.type)
　　 case MSG_HARDWARE :
---> process_hardware_message()
---> process_mouse_message() {
　　 if (hittest != HTCLIENT) {
　　　 message += WM_NCMOUSEMOVE - WM_MOUSEMOVE;
　　　 wparam = hittest;
　　 }
```





### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ



## end
Inside Wine; CreateWindow から XCreateWindow

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; Window の作成


## CreateWidowEx() から、X Window の Window が生成されるまでの流れ

非常に分かりにくいのですが、結論から言えば、CreateWidowEx() した際に実際に、X Window の XCreateWindow() を呼び出しているのは、「set_window_pos()」の中から呼び出される所のX11DRV_WindowPosChanging()の中です。その関数から、X11DRV_create_win_data() が呼び出され、create_whole_window() が呼び出され、XCreateWindow() が呼び出されて、戻り値の 「Window」という型の ID 値を、data->whole_window の中に代入しています。なお、Window 型は、構造体型ではありません。

```c:
CreateWindowExW()
--->
WIN_CreateWindowEx()
  call set_window_pos()
--> wine/dlls/user32/winpos.c
--> X11DRV_WindowPosChanging()
--> X11DRV_create_win_data()
--> dlls/winex11.drv/window.c :
    static void create_whole_window( struct x11drv_win_data *data )
--->
 data->whole_window = XCreateWindow(
              data->display, root_window, pos.x, pos.y,
              cx, cy, 0, data->vis.depth, InputOutput,
              data->vis.visual, mask, &attr );
```

という流れのようです。

```c:
static struct x11drv_win_data *X11DRV_create_win_data( HWND hwnd, const RECT *window_rect,
                                                       const RECT *client_rect ) {
    Display *display;
    struct x11drv_win_data *data;
    HWND parent;
    if (!(parent = GetAncestor( hwnd, GA_PARENT ))) return NULL;  /* desktop */
    /* don't create win data for HWND_MESSAGE windows */
    if (parent != GetDesktopWindow() && !GetAncestor( parent, GA_PARENT )) return NULL;
    if (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId()) return NULL;
    display = thread_init_display();
    init_clip_window();  /* make sure the clip window is initialized in this thread */
    if (!(data = alloc_win_data( display, hwnd ))) return NULL;
    data->whole_rect = data->window_rect = *window_rect;
    data->client_rect = *client_rect;
    if (parent == GetDesktopWindow()){
        create_whole_window( data );
        TRACE( "win %p/%lx window %s whole %s client %s\n",
               hwnd, data->whole_window, wine_dbgstr_rect( &data->window_rect ),
               wine_dbgstr_rect( &data->whole_rect ), wine_dbgstr_rect( &data->client_rect ));
    }
    return data;
}
```


### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ



## end
Inside Wine; 透明色

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; 透明色


## 色

親が Desktop Window の場合の Win32 の Window は、X Windowで は、depth = 24 で、XCreateWindow() されます。これは、8*3 = 24 BIT の、RGB カラーに相当します。

dwExStyle に WS_EX_LAYERED 属性を指定して、かつ、完全透明色を用いている場合は、X Window 側の depth は、24 のままです。透明は、XShpae を用いて、実装されています。XShape は、本来は、長方形以外の輪郭を持つ Window を作成するためのものです。だから、実測では、一回辺り、完全に処理が終わるまで、0.15秒(150 ms)程度の比較的長い時間がかかります。それは、XShape の設計においては、Window の外形は、Window 作成時に一回だけ設定されることを前提にしているためでしょう。問題なのは、その速度が遅いことよりも、Linux の場合、XFlush()、XSync() を行っても、10 ms 程度ですぐに帰ってきてしまい、本当の処理が完了する 150 ms は、WINE や、アプリが感知する方法が見つからない事です。

このことは、再描画が必要な時には、いったん、InvalidateRect()で、（再描画が必要な事を示す）マークだけしておけば、メッセージ・キューに残されている未処理のメッセージ（比較的、マウスやキーボードのメッセージであることが多い）の個数によって直前または最近の描画の重たさを測ることで、今後の WM_PAINT の発行タイミングを自動調整する方針を取っている Win32 では、致命的な問題へと発展し、Linux OS の数分間以上の事実上のハングアップ（操作不能状態）に至ります。そうなった場合、マウスカーソルだけしか動かせなくなり、タスクバーも全く機能しなくなります。そのことは、後に述べる予定です。大筋で言えば、処理が追いついて無いのに大量の Request を X Server にとめどもなく発行してしまうために、待ち行列に未処理のリクエストが大量に溜まってしまった X Server を「救うため」、Linux システムが X Server のみに CPU リソースを与え、他の プロセスは、完全停止状態にしてしまうことが原因と考えられます。


## X Window で、XShape を使わない本当の透明色

X Window で透明色を扱うのはとても簡単です。

XCreateWindow() を、depth = 32 として Window を作成するだけです。

これで、色値が、ARGB の　A,R,G,B 構成となり、A が専門用語で「α値」と呼ばれる値になります。

A = 0 で完全透明、A = 255 で完全不透明となり、その間の値では、中間的な半透明となります。基本的には、最終的な色値 D2 は、その背面にある色値 D に対して、

```c:
D2 = (int)( ( D * (255.0 - A) + S * A ) / 255.0 );
```

のような計算式で計算されます。S は、上に重なっている所の物の色(ARGB の RGB 部分)です。






### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ

### aaa

あああ



## end
[ 斜方投射 ]  落下地点を予測する

[こちら](https://qiita.com/ELIXIR/items/59cbdc1fada8c85079e2)の記事で、任意の場所にオブジェクトを飛ばすことができますが、同様に、角度と大きさを決めて落下地点を予測することができます

```DrawParabolicLine.cs
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class DrawParabolicLine : MonoBehaviour {
    public Vector3 dir = new Vector3(10f, 10f, 10f);
    public Vector3 origin = Vector3.zero;
    public float calcTime = 5f;
    [SerializeField, Range(0.001f,0.5f)]public float timeScale = 0.1f;
	// Use this for initialization
	void Start () {
		
	}
	
	// Update is called once per frame
	void Update () {
        Vector3 pos = origin;
        Vector3 newPos = pos;
        float time = 0f;
        List<Vector3> posList = new List<Vector3>();
        while(time<calcTime){
            Vector3 dirXZ = new Vector3(dir.x, 0f, dir.z);
            // h=v0t+1/2*g*t^2
            float h = dir.y*time + 0.5f * Physics.gravity.y * time * time;
            newPos = origin + dirXZ * time + Vector3.up * h;
            posList.Add(newPos);
            Debug.DrawLine(pos, newPos, Color.yellow);
            pos = newPos;
            time += timeScale;
        }
	}
}
```

![スクリーンショット 2018-02-27 9.00.21.png](https://qiita-image-store.s3.amazonaws.com/0/59911/4622dc08-9684-4429-74ce-ae5e1750c4aa.png)
【Swift】UIViewのタッチエリアを擬似的に拡大する

この前Responder Chainについて調べたついでに学んだことをメモします。

Appleの[ヒューマンインターフェイスガイド](https://developer.apple.com/design/tips/jp/)に記載もあるようにコントロール要素は最低44X44ポイント以上の大きさで作成することが推奨されていますが、デザインの関係でUIButtonなどがかなり小さくなる場合があります。
その際にUIButtonの代わりにUIGestureRecognizerを設定したUIViewを使うなどで反応を広げることも可能ですが、
タッチ時の当たり判定でtrueになる範囲を広げることで
擬似的にボタンを大きくすることで対処できます。

```ExpandedButton.swift


class ExpandedButton: UIButton {

    private let minimumHitArea = CGSize(width: 44, height: 44)

    override open func point(inside point: CGPoint, with _: UIEvent?) -> Bool {
        if self.isHidden || !self.isUserInteractionEnabled || self.alpha < 0.01 { return  false }
        
        let buttonSize = self.bounds.size
        let widthToAdd = max(minimumHitArea.width - buttonSize.width, 0)
        let heightToAdd = max(minimumHitArea.height - buttonSize.height, 0)
        let area = self.bounds.insetBy(dx: -widthToAdd / 2, dy: -heightToAdd / 2)
        return area.contains(point)
    }
}
```

タッチ判定をするメソッドでもう一つ[hitTest(_:with:)](https://developer.apple.com/documentation/uikit/uiview/1622469-hittest)があり、
こちらでも同じことが可能でしたが、
Viewを返してくれるのでタッチ判定を無効にして
subviewに処理を任せたいときなどに活用している方が多いように感じました。
※もしこっちの方が良いなどございましたら教えてください:bow_tone1:

```NoTouchView.swift


class NoTouchView: UIView {
    
    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
    }
    
    override init(frame: CGRect) {
        super.init(frame:frame)
        
    }

    override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {

        // 自分自身のタッチは無効にする
        let view = super.hitTest(point, with: event)        
        if view == self {
            return nil
        }
        return view
    }
}
```
Inside Wine; Build

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; Build



## 基本ビルド

git の設定が終わった事を前提にする。

```
$ ./configure
$ make -j 10
$ sudo make -j 10 install
```

が基本。既に wineserver が起動している場合には、

```
$ wineserver -k
```

で wineserver をいったん、終了させる。

この状態で、

```
$ wine notepad
```

などとすると、wineserver が自動的に起動される。

この後、Windows アプリによっては、日本語フォント関連で問題が生じることがある。その場合、自分の場合、

```
$ sudo apt-get remove wine
$ sudo apt-get install wine
```

で元に戻った。

## 本当のビルド

```
$ ./configure --prefix=/xxx/yyy
$ make -j 10
$ make -j 10 install
```

などとすることを勧めます。

現実に実験してみると、/xxx/yyy の permission のせいでしょうが、make install の sudo は必要ありませんでした。

こうすると、/usr/local/bin, /usr/local/lib の代わりに、
/xxx/yyy/bin, /xxx/yyy/lib にバイナリがインストールされます。

## 実際の現場のビルド

このままだとビルドとインストールにとてつもなく長く時間を取られます。

なので、ビルドに関しては、user32 にあるファイルだけを修正した場合には、

```
$ cd /dlls/user32
$ make -j 10
```

などとすると、そこに、user32.dll.so というファイルができるので、それを、wineserver に読み込ませてやれば、「ルート」からの全フォルダに対する make の必要もなく、make install の作業も必要なくなります。

その事は、環境変数 WINEDLLPATH の修正で行いますが、デフォルトでは、検索パスの優先順位に問題があるので、loader.c も修正します。さらに修正後の loader が利用されるように、さらに環境変数を設定します。これは、後に述べます。
Inside Wine; ソース DL

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; ソース DL

```
$ git clone git://source.winehq.org/git/wine.git
```

でローカルにまるまる DL することが出来る。

すると、カレントディレクトリが ~ であるなら、

```
~/wine
```

というフォルダが作成されて、その中に *.c, *.h, *.def, *.map, *.spec, configure, Makefile が全て入る。

紛らわしいが、このフォルダは、「wine」であって、「.wine」ではない。結果、

```
~/.wine      # 設定ファイル
~/wine       # ソース
```

の二つが出来る。
Laravel 5.5 API開発のプロファイルはClockwork

LaravelとVueでSPAを作っていると、Laravel Debugbarみたいなのが欲しいなぁ。と
常日頃思っていましたが、普通にあるんですね。

@aikawame さんの次の記事を見つけて、[Clockwork](https://github.com/itsgoingd/clockwork)を試してみました。
[Laravel DebugbarをAPI開発でも使う](https://qiita.com/aikawame/items/613d7a4a3e1f68b63cc8)

Laravel 5.5以降ではPackage Auto Discoveryが使えるため、かなり楽です。
また、この記事ではGoogle Chromeを利用していますが、FireFoxでも利用出来るようです。

# 実行環境

- Laravel 5.5
- Google Chrome 64

# Clockworkの導入

## Laravel

```
composer require itsgoingd/clockwork --dev
```

## Chrome 機能拡張

Chrome ウェブストアから機能拡張をインストールしてください。

- [Clockwork - Chrome ウェブストア](https://chrome.google.com/webstore/detail/clockwork/dmggabnehkmmfmdffgajcflpdjlnoemp)

# 動作確認

これだけの作業で、ChromeのデベロッパーツールにClockworkのタブが追加され、
プロファイルが出来ます。

![001.png](https://qiita-image-store.s3.amazonaws.com/0/25028/5f41f649-7186-9c57-ccb3-d78023a0e741.png)
Inside Wine; バイナリのフォルダ構成

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; バイナリのフォルダ構成

~/.wine に設定ファイルがある。
~ は、/home/ユーザー名 を短縮した物。.wine は、隠しファイルなので、見逃すことがあるかも知れないが存在している。

```
/usr/local/bin
/usr/local/lib
```

あたりに wine, wineserver, winecfg や、
user32.dll.so などがインストールされる。
Inside Wine; はじめに

[目次] (https://qiita.com/Yutaka_Aoki/items/9d38ea98406f4096435b)

# Inside Wine; はじめに

以下、Linux の Ubuntu 環境での、WINE 3.1 の内部的な動作を調査した結果を書いておきます。WINE の修正が活発に行われる事を期待して。

本題とは離れるが、もう一つの結論として、Ubuntu 12.0 系では、WINE 2.3 程度までしかパッケージ版は用意されていないが、本家の git からソースを DL して、ビルドしてみると、WINE 3.1 をインストールすることが出来た。Ubuntu は 12.0 のままで。

```
OS: Linux, 3.2.0-58-generic
    Ubuntu 12.04 LTS
Platform: i386
Wine : wine-3.1-316-g65989f2  (<---build version)
```
改修/要望の時に、意識することをEASYにまとめる

# 改修/要望の際に、ぼーっとしてると痛い目に合うので、まとめておく

##アクターの確認
今回の新機能を具体的に使いたい人（要望者はだれなのか？）
=>まず登場人物を洗い出す!
=>そのうえでだれの要望なのか＝お客さん？社員さん？など

## レイヤーの整理
資料等を渡されてある場合、アクターと照らし合わせた上で、
例えば、その項目などの精査をする
使うアクターはXXXなのに、この項目はなぜいる？など
クライアントは、何でも出力しようとしているケースが多い
しっかりとアクター、レイヤーを意識して、MTGを重ねる

## データの鮮度の確認
データのリアルタイム性がそこまで求められないならば、
定期的にバッチ処理で、1日1回や何時間に1回などと負荷を軽減できてWIN-WIN

## まとめ
ヒアリングに、ふわっとしている要望は特に注意
Nuxt.js のディレクトリと設定ファイル

## ディレクトリ一覧

| ディレクトリ名   | ディレクトリ名の変更 | 用途                                                     |
| :--------- | :------------ | :------------------------------------------------------- |
| assets     | 可            | コンパイルされていないCSSファイルやJSファイルを入れる                           |
| components | 可            | Vue.jsのコンポーネントファイルを入れる                                  |
| layouts    | 不可          | レイアウトファイルを入れる                                           |
| middleware | 可            | ミドルウェアを入れる<br>ページをレンダリングするよりも前に実行されるカスタム関数を定義できる |
| pages      | 不可          | ビュー及びルーティングファイルを入れる                                    |
| plugins    | 可            | アプリケーションをインスタンス化する前に実行したいJSプラグインを入れる                |
| static     | 不可          | 静的ファイルを入れる<br>このディレクトリ内のファイルはいずれも / に配置される         |
| store      | 不可          | Vuex ストア のファイルを入れる                                      |


# 設定ファイル

> nuxt.config.js

* ファイル名変更不可

| オプション名    | 用途                                                                        |
| :--------- | :-------------------------------------------------------------------------- |
| build      | vendor.bundle.jsファイルにモジュールを追加できる                                          |
| css        | グローバルに利用したいCSSを指定できる                                                    |
| dev        | 開発モードまたはプロダクションモードを定義できる                                                |
| env        | クライアントサイドでもサーバーサイドでも使える環境変数を指定できる                                    |
| generate   | 動的なルーティングをしているアプリケーションをHTMLに変換するときに使う<br>動的なルーティングに用いるパラメータを指定できる |
| head       | アプリケーションのメタ情報を指定できる                                                     |
| loading    | デフォルトのローディングコンポーネントをカスタマイズできる                                               |
| modules    | プロジェクトにnuxtモジュールを追加できる                                                    |
| plugins    | アプリケーションをインスタンス化する前に実行したいJSプラグインを指定できる                                |
| rootDir    | アプリケーションのワークスペースを指定できる                                                    |
| router     | デフォルトの vue-router 設定を上書きできる                                             |
| srcDir     | アプリケーションのソースディレクトリを指定できる                                                  |
| transition | ページ間のトランジションのデフォルト設定を指定できる                                             |
Angularで作るER DIAGRAM TOOL - 第五回　ngx-bootstrap - Modals を使って、data 編集機能を実装

navbarからモーダルでフォームを開き、dataを編集できるようにします。

■ngx-bootstrap - Modals
https://valor-software.com/ngx-bootstrap/#/modals

今回は、Service examplesのComponentに書いてある方法で進めます。
その際、NgModuleのentryComponentsにコンポーネントを追加する必要があることに気を付けましょう。



##（１）Modals モーダルコンポーネントの作成

まずは、modalで開くフォームのコンポーネントを作ります。

/src/app/modal-data/modal-data.component.ts
https://github.com/dog-ears/er-diagram-tool/commit/49cc5251c0fe05d01a378150dbea970f2ae5292c#diff-6c652fa972bc4950cc49fa13685b044f

・モーダルを閉じるために、BsModalRefをDIしてます。

/src/app/modal-data/modal-data.component.html
https://github.com/dog-ears/er-diagram-tool/commit/49cc5251c0fe05d01a378150dbea970f2ae5292c#diff-4a3e1aab3610dc87b97cca9d3478bdbc

・ (click)="bsModalRef.hide()"が、モーダルを閉じる処理になります。
・[(ngModel)]="data.app_type" で、双方向バインディングを定義してます。



##（２）モジュールに読み込み

/src/app/app.module.ts
https://github.com/dog-ears/er-diagram-tool/commit/49cc5251c0fe05d01a378150dbea970f2ae5292c#diff-fc6b22833aeaf77f8440c4970ade705e

・モーダルで開くフォームで、双方向バインディングを使うため、FormModuleを読み込んでます。
・ModalModuleを読み込みました。
・ModalDataComponentを読み込みました。また、declarationsに追加するとともに、entryComponentsにも追加するのを忘れないようにしましょう。

/src/app/navbar/navbar.component.ts
https://github.com/dog-ears/er-diagram-tool/commit/49cc5251c0fe05d01a378150dbea970f2ae5292c#diff-12468dba4acc93d6788c4f72b2b89a70

・BsModalService、BsModalRef、DataService、ModalDataComponentをimportします。
・メンバー変数bsModalRefを追加
・bsModalService、dataServiceをDI
・メニューの各メソッドを定義。今回実装するdataSetting以外は空です。
・dataSettingメソッドで、モーダルを開きつつ、dataを渡す処理を記述。

/src/app/navbar/navbar.component.html
https://github.com/dog-ears/er-diagram-tool/commit/49cc5251c0fe05d01a378150dbea970f2ae5292c#diff-017b6e710461134e5b4c9fd34aeabe7c

・各メニューから(click)="createModel()"のようにして、メソッドを呼び出すように修正



これでメニューのSetting - Data Setting で、モーダルが開き、
フォームの内容を変えると、即データが更新されていることが確認できると思います。

次回は、いよいよモデル作成にとりかかります。
データベース基礎

# データ型の指定
日付型（date）の指定： 'yyyy-mm-dd'
日時型（datetime）の指定： 'yyyy-mm-dd hh:mm:ss.nnn'

# LIKE述語
%：　任意の文字（0文字含む）
-：　任意の一文字

[例]
* 「高」を含む：　WHERE 列名 LIKE '%高%'
* 「高」で始まる：　WHERE 列名 LIKE '高%'
* 「高」で始まる3文字：　WHERE 列名 LIKE '高__'

# バッチファイルからSQLを実行
SQLServerをインストールしている環境では、sqlcmdを使うことができる。

## Windows認証でServer接続
```bat: sql.bat
set Server=%COMPUTERNAME%\SQLEXPRESS
echo %Server%

CD %~dp0
SQLCMD -S %Server% -i input.txt -s, -W -o output.txt
pause
```

```bat: input.txt
USE [testDB]
GO

SELECT * FROM [dbo].[DATATABLE];
GO
```

## sqlファイルに引数を渡す
バッチファイルからSQLが書かれたファイル（sqlファイル）に引数を渡す。
```bat: sql.bat
set Server=%COMPUTERNAME%\SQLEXPRESS
echo %Server%

CD %~dp0
SQLCMD -S %Server% -i input.txt -v start_date="2017-07-01 00:00:00" -s, -W -o output.txt
pause
```

```bat: input.txt
USE [testDB]
GO

SELECT * FROM [dbo].[DATATABLE] WHERE [file_start_date] > '$(start_date)';
GO
```

# sqlcmd オプション
sqlcmd   
   -a packet_size  
   -A (dedicated administrator connection)  
   -b (terminate batch job if there is an error)  
   -c batch_terminator  
   -C (trust the server certificate)  
   -d db_name  
   -e (echo input)  
   -E (use trusted connection)  
   -f codepage | i:codepage[,o:codepage] | o:codepage[,i:codepage] 
   -g (enable column encryption) 
   -G (use Azure Active Directory for authentication)
   -h rows_per_header  
   -H workstation_name  
   ** -i input_file **  
   -I (enable quoted identifiers)  
   -j (Print raw error messages)
   -k[1 | 2] (remove or replace control characters)  
   -K application_intent  
   -l login_timeout  
   -L[c] (list servers, optional clean output)  
   -m error_level  
   -M multisubnet_failover  
   -N (encrypt connection)  
   ** -o output_file ** 
   -p[1] (print statistics, optional colon format)  
   -P password  
   -q "cmdline query"  
   -Q "cmdline query" (and exit)  
   -r[0 | 1] (msgs to stderr)  
   -R (use client regional settings)  
   -s col_separator  
   ** -S [protocol:]server[instance_name][,port] ** 
   -t query_timeout  
   -u (unicode output file)  
   -U login_id  
   ** -v var = "value" ** 
   -V error_severity_level  
   -w column_width  
   ** -W (remove trailing spaces) ** 
   -x (disable variable substitution)  
   -X[1] (disable commands, startup script, environment variables, optional exit)  
   -y variable_length_type_display_width  
   -Y fixed_length_type_display_width  
   -z new_password   
   -Z new_password (and exit)  
   -? (usage)

## 参考
* https://docs.microsoft.com/ja-jp/sql/tools/sqlcmd-utility
シンプルさの重要性をWebGLヘルパーで学ぶ

#概要
シンプルさの重要性( http://eed3si9n.com/ja/simplicity-matters )をWebGLヘルパーの作成によって学びました。

#WebGLは順序依存が強いライブラリ

WebGLでは、次の例のような順序に関する依存性があります。

テクスチャをフラグメントシェーダのユニフォームに適用するために、以下の関数を近接して発行する必要がある。

```js
const texIndex = 0;
const actTex = (texIndex === 0) ? gl.TEXTURE0 : (texIndex === 0) ? gl.TEXTURE1 : gl.TEXTURE2;
const uniformLocation = gl.getUniformLocation(pg, key); // ロケーションオブジェクトを取得
gl.activeTexture(actTex); // プログラムにおいて複数のテクスチャを分類する
gl.bindTexture(gl.TEXTURE_2D, ftValue.texture); // テクスチャオブジェクトをバインド
gl.uniform1i(uniformLocation, texIndex); // ロケーションオブジェクトとテクスチャオブジェクトを関連付け
```

プログラムを実行するために、頂点データを設定し、今のプログラムを設定し、出力先、頂点シェーダ頂点情報、フラグメントシェーダのパラメータを設定し、実行する必要がある。

```js
const vertexBuffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, vertexBuffer); // 現在のアレイバッファを設定
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array([-1, -1, 1, -1, -1, 1, 1, 1]), gl.STATIC_DRAW); // アレイバッファにデータを設定
gl.useProgram(pg); // 現在のプログラムオブジェクトを設定
gl.bindFramebuffer(gl.FRAMEBUFFER, out.framebuffer); // プログラムの出力先を指定
gl.viewport(0, 0, this.width, this.height); // 出力先の描画範囲を指定
const attribLocation = gl.getAttribLocation(pg, calcKeys.attrib); // プログラムの頂点シェーダのロケーションオブジェクトを取得
gl.enableVertexAttribArray(attribLocation); // ロケーションを有効化
gl.vertexAttribPointer(attribLocation, 2, gl.FLOAT, false, 0, 0); // ロケーションに、前回設定したアレイバッファを関連付け
const uniformLocation = gl.getUniformLocation(pg, key); // フラグメントシェーダの各ロケーションオブジェクトを取得
gl.uniform1f(uniformLocation, value); // ロケーションに値を設定
gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); // 描画
gl.flush(); // 必要に応じてフラッシュ
```

#マップによって複雑さをシンプルな表現に置き換えることができる

拙作uni2vecの中にあるCalcGLクラスを利用すれば、マップ表現で計算指示を出すことができます。
https://sites.google.com/site/uni2vec/cab/uni2vec.html

- マップはハッシュテーブルまたは連想データ構造(シンプルさの重要性の用語)とも呼ばれます。Javascriptではオブジェクトのリテラルを利用することも可能です。
- WebGL APIの順序に関する依存性の大部分は、CalcGLの各プロトタイプ関数の内部で処理されます。
- CalcGLを利用するプログラムは、必要になるまでは複雑さに目を向けなくても良いという意味で、WebGLの複雑さはCalcGLによって隠蔽されています。(必要になるまではデスクトップパソコンのカバーを開けなくても良いというメタファ)
- CalcGLは、uni2vecで使用していないuniformデータ型の設定を、calcプロトタイプ関数で実装していません。必要になったらデスクトップパソコンのカバーを開ければ良いし、機能の追加が簡単なようにWebGL APIもなっているし、機能の追加が簡単なようにCalcGLも実装しているつもりです。(マザーボードは特定のアーキテクチャに従っていますよねというメタファ)

以下の例のように。※

```js
const env = new ShaderEnv(); // 複数のフラグメントシェーダのenv入力に渡す16個の環境変数を管理するクラス
// ...
function processNormalize(matName) { // 複数のベクトルを並列に正規化する機能の例
	const mat = ftMap[matName]; // 事前に生成していたFrameTexオブジェクトを、連想データ構造から取得(FrameTexはフレームバッファとテクスチャを関連付けた連想データ構造)
	const workFtScr = ftMap['work0']; // ワーク領域を表すFrameTexオブジェクトを、連想データ構造から取得

	calcgl.calc({
		pg: pgMap['inverseNorm'], // プログラムの連動データ構造から、各ベクトルのノルムの逆数を並列計算するプログラムを取得
		env: env.env, // フラグメントシェーダのvec4入力の一つを設定
		matTex: mat, // フラグメントシェーダのテクスチャ入力の一つをFrameTexとして設定
		out: workFtSrc, //出力先をFrameTexとして設定
	});
	
	calcgl.calc({
		pg: pgMap['scalarProd'], // プログラムの連動データ構造から、各ベクトルのスカラー倍を並列計算するプログラムを取得
		env: env.env,
		matTex: mat, // フラグメントシェーダのテクスチャ入力の一つを、FrameTex連想データ構造として設定
		workTexScr: workFtScr, // 前段で計算したノルムの逆数をFrameTexとして設定
		out: ftMap['tmp'], //出力先をFrameTexとして設定
	});

	toggleMat(matName); // matNameで取得できるFrameTexオブジェクトを、前段で出力した一時FrameTexオブジェクトに置き換え
}
```

※例示のため、Javascriptの中括弧表現に置き換えています。uni2vec内ではパフォーマンスチューニングのため、マップオブジェクトを再利用する表現になっています。