Google Cloud SpannerでFORMAT_TIMESTAMP関数使うと時間がずれる

SpannerにUTCでTIMESTAMP型で保存されてるデータをJSTに戻そうとしたときにはまった。

SELECT 
  TIMESTAMP "2017-08-20 20:00:00 UTC"                                                                              AS ORIGIN_UTC,
  TIMESTAMP_ADD(TIMESTAMP "2017-08-20 20:00:00 UTC", INTERVAL 9 HOUR)                                              AS DateTime_9_Plus,
  FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', TIMESTAMP_ADD(TIMESTAMP "2017-08-20 20:00:00 UTC", INTERVAL 9 HOUR))       AS DateTime_WITH_TIME_9_Plus_FORMATED,
  FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', TIMESTAMP_ADD(TIMESTAMP "2017-08-20 20:00:00 UTC", INTERVAL (8 + 9) HOUR)) AS DateTime_8_Plus_9_FORMATED
ORIGIN_UTC DateTime_9_Plus DateTime_WITH_TIME_9_Plus_FORMATED DateTime_8_Plus_9_FORMATED
2017-08-20T20:00:00Z 2017-08-21T05:00:00Z 2017-08-20 22:00:00 (なぜかずれる) 2017-08-21 05:00:00 (8時間を補正分としていれてズレを戻す

よくわからんが、内部で太平洋標準時(たいへいようひょうじゅんじ、Pacific Standard Time: 略称PST)+8:00が影響してるとかしてないとか? www.en.advertisercommunity.com

docs.looker.com

FORMAT_TIMESTAMP関数の第三引数で"+9:00"のように指定しないとだめだった。

FORMAT_TIMESTAMP(format_string, timestamp[, time_zone])

でも、Data Studio使ったときに期間指定すると

(FORMAT_TIMESTAMP('%Y%m%d', t0.DateTime) >= '20181201' AND FORMAT_TIMESTAMP('%Y%m%d', t0.DateTime) <= '20181231')

みたいなクエリになっちゃうので、上記のように手動で8を足しこんだカラムにしないとだめだった

さくらVPSにSoftEtherサーバ構築

基本的にはラズパイに構築したときと同じ
waysaku.hatenablog.com


ただ、すっかり忘れていたのでメモ
基本的にはここの通りにセットアップすればOKだが、vpnserverとvpnclientの両方セットアップが必要
linuxconfig.org

あと、さくらのVPSはiptableが /etc/iptables/iptables.rules で明示的にセットされてしまっているのでデフォだとudp/500とudp/4500がつながらないっぽい。
/etc/iptables/iptables.rules を削除してrebootして解決

golangでbyte配列から整数型への変換メモ

メモ

package main

import (
    "fmt"
    "golang.org/x/crypto/scrypt"
    "encoding/hex"
    "encoding/binary"
    "bytes"
)


func main() {

    b := []byte{0x00, 0x00, 0x00, 0xFF}
    fmt.Println(b)
    fmt.Println(hex.EncodeToString(b))

    var i int32
    buf := bytes.NewReader(b)
    err := binary.Read(buf, binary.LittleEndian, &i)
    if err != nil {
        fmt.Println("binary.Read failded:", err)
    }

    fmt.Println(i)
}

package.jsonのpeerDependenciesについての理解

依存の解決の違い(dependencies, devDependencies, peerDependencies)

親アプリで利用されるためのnpmモジュールを開発している時に、このモジュールをインストールするときはmoduleA:0.5.0と一緒にインストールする必要がある」 というケースを考える

 親アプリ
 |
 |- このモジュール
 |          |
 |          |- moduleA

1. このモジュールのpackage.jsonのdependenciesにmoduleA:0.5.0を書いた場合
親アプリにも自動的にmoduleA:0.5.0がインストールされるが、もし親アプリのpackage.jsonにmoduleA:1.5.0が設定されてた場合は上書きされて実行時エラーになる



2. このモジュールのpackage.jsonのdevDependenciesにmoduleA:0.5.0を書いた場合
親アプリでnpm installした時に、このモジュールのdevDependenciesは無視されるのでmoduleA:0.5.0はインストールされないため実行時エラーになる
対処: 親アプリ側でmoduleA:0.5.0をpackege.jsonに書く必要がある



3. (1.か2.に加えて) このモジュールのpackage.jsonのpeerDependenciesにmoduleA:0.5.0を書いた場合
npm-v3より前の場合は、親アプリのnode_modulesにmoduleA:0.5.0も一緒にインストールされる(WARNは出る)
npm-v3以降の場合は、 `このモジュール@1.0.0 requires a peer of moduleA@^0.5.0 but none was installed.` みたいなWARNが出るだけでmoduleA:0.5.0はインストールされない


それぞれの違い

2.のケースはそもそもとして、このモジュールの実行に必要なmoduleA:0.5.0をdevDependenciesに書くのは間違いである(開発用途に必要なモジュールではなく、実行に必要なモジュールのため)

1.のケースは親アプリ側がこのモジュールを利用するときにmoduleA:0.5.0が必須なことに気づけないため、なんらかの理由で親アプリのpackage.jsonにmoduleA:1.5.0を入れた場合に、このモジュールが動かなくなることを事前に気づくことができない

そのため、3.のpeerDependenciesをこのモジュールが使っていれば、警告として親アプリ側に通知することができるので、親アプリ側は明示的に(意図的に)moduleA:0.5.0を追加することができる。

はまったところ

この時注意が必要なのは、peerDependenciesはあくまで親アプリ側に警告を促すだけである。
親アプリは `このモジュールがmoduleA:0.5.0に依存しているからそれを利用しよう'と意図的に親アプリのpackage.jsonにmoduleA:0.5.0を追加することができるということが重要である。
もしも親アプリがmoduleA:1.5.0を利用したかったとしてもこのモジュールはmoduleA:0.5.0を使っているので、それぞれのモジュールの依存バージョンの互換性を解決してくれるものではない

どういうときに使うのか?

開発ではmoduleA:1.5.0を使っているが、このモジュールを利用するときは最低でもmoduleA:0.5.0を使ってほしいときとか?

結局、親アプリでmoduleA:1.5.0を参照して、このモジュールではmoduleA:0.5.0を参照するようにして依存性をよしなに解決して同時に使いたい

そのままではできないっぽい。
(なんかごにょごにょ工夫すればできるかもしれないけど)

疑問に対する推測

peerDependenciesって親アプリに設定するものじゃないのか?

親アプリのpeerDependenciesに指定することにより、このモジュールがどのバージョンのmoduleAに依存しているのかを指定する使い方なのもと思ったがどうやら違うっぽい

  • 親アプリにpeerDependenciesを設定してもこのモジュールのバージョン依存を解決してくれるわけではないっぽい(WARN出るし)
  • そもそも、peerDependenciesの書式的にどのモジュールがどのモジュールのどのバージョンに依存しているという書き方ができない
じゃぁ、devDependenciesとpeerDependenciesの両方に違うバージョンで書いてあるOSSモジュールをよく見るのはなんで?

これとか
リリースバージョンの依存はpeerDependenciesに書いて、開発中とか動作確認中のものはdevDependenciesに書いているのでは?

このモジュールのpeerDependenciesだけに書いた場合、このモジュールでnpm iinstallした場合はどうなるの?

peerDependenciesに書いただけでは、npm installしてもnode_modulesにインストールされない。
dependenciesかdevDependenciesと組み合わせて利用するみたい。








あんまり情報がなくて推測の部分が多い。
あんまりしっくり来てないけどこれ以上時間かけられないのでこんなもんの理解でとどめておく。




package.jsonのpeerDependenciesについて調べた
http://yukidarake.hateblo.jp/entry/2016/02/16/201614

Peer Dependencies
https://nodejs.org/en/blog/npm/peer-dependencies/

家のRaspberry Pi 2 Model BにSoftetherでVPNを構築

海外に来てから家のNASにアクセスしたりするためにVPN環境を構築した。
自宅には家族しかいないので、万が一ネットワーク設定ミスったりしたらサーバーにアクセスできなくなってしまうので慎重に作業した

いくつか日本語の記事を読んだが、最終的にサーバー設定はWindows用のGUIアプリを使ってたのでコマンドで設定できる方法を模索した。
後から見てみたら、Mac用のGUIアプリも公式に用意されていたのでそっちを使う方法でもよかったのかもしれない

以下を参考にしたらサクッと構築できた。すごい

Goにおけるreflectまわり調べた

javaScalaとGoでそれぞれclass、型、インターフェース、メソッドの用語の意味が微妙に違うから混乱する
なんなら型クラスとかある

なぜ遅いか

  • 静的な型付けがされていたり、コンパイルされていたりする言語でもリフレクションアクセスの場合は interpretiveに解釈されるから 遅い
  • reflectionは メモリアロケーションが多く発生するため 遅い 恐らく、静的型且つ、コンパイル型であるGoにとってダイナミックにメモリアロケーションをするのは特にコストが高いのかも)

  • makeFunc()を見てみると、makeFunc.go#62で呼び出しているfuncLayout()の処理が重そう(完全に雰囲気だけど)
    funcLayout()は渡された汎用型(rtype)を「関数型だったら」「インターフェイス型だったら」とかいっこずつ分解していっって、値型によっても一つ一つみてレイアウト情報を取得してるっぽい。
    if runtime.GOARCH == "amd64p32" { みたいなコードもあるのでCPUアーキテクチャによる分岐もはいってる雰囲気
    いかにも重そう(な雰囲気)

  • 型情報を取得するときは、ValueOf()でValue型に変換して、Type()を呼び出す
    unsafe.Pointerを使って、型の種類ごとに処理が書いてある(Funcならこれやる、Interfaceならこれやるみたいな)
    type.uncommon()でFuncなのかArrayなのか、Sliceなのか…を分岐で判断してる
    それに応じてruntime/type.goのresolveTypeOff()でごにょごにょしてるが、reflectOffsLock()という関数を呼び出しているので、もしかしたらプロセスのメモリ空間のテキストセグメントにアクセスするときに、goroutine同士のメモリ競合しないようにロックを取得しているのかな?

参考

なぜリフレクションは遅いのか
http://postd.cc/why-is-reflection-slow/
golangのある生活
http://ameblo.jp/principia-ca/entry-11929774278.html
The Laws of Reflection
https://blog.golang.org/laws-of-reflection
How slow is Go’s reflection effectively?
https://groups.google.com/forum/#!topic/golang-nuts/HcfutSkJVoY
Unsafe in Go 甘美な世界
https://techblog.ca-reward.co.jp/2016/08/post-117.html

goroutineを調べたときに深掘りしたときに調べたまとめ

並行処理プログラミングのモデル

Shared memory

いわゆるプログラミング言語のランタイムによるアプリケーションスレッド(グリーンスレッド)である
同じプロセス(LWP)内でランタイムによりスイッチされながら実行される並行化の仕組みなので、マルチコアにスケールはしない

[同じプロセス(LWP)内で動く = メモリ空間を共有する]ためグローバルオブジェクトなどへの共有メモリアクセスを制限するため、ランタイム側で実行中のアプリケーションスレッドにロックを取得させている
ロックを取得・開放を繰り返して、スイッチさせながら複数のアプリケーションスレッドを実行しているためCPUバウンドの処理の場合はパフォーマンスは改善しない(むしろスイッチコストがかかるため悪くなる)

ただし、IOバウンドの処理の場合は、IO waitの時にロックが開放されるため効率よく並列化できる。
ネットワークIOやファイルIOを多重化する場合は、アプリケーションスレッドでも効率的に並列化できる

Message passing

Shared memoryがメモリアドレスを共有するのに対して、Message passingは共有しない
データをメッセージとしてやり取りすることにより、送り手と受け手の中でのみメモリ空間を論理的に管理する(送り手と受け手のメモリ空間をライブラリレベルで論理的に管理する)
actor modelが有名

Implicit Interaction

並列化をプログラミングコードレベルでは意識せずに、コンパイラインタプリターで暗黙的に実現する。 プログラマは並列化を意識せずにコードを書くが、コンパイル時に並列実行できるようなコードに変換される(インタプリタの場合は実行時)

並列プログラミングにおける問題のカテゴリ

タスク並列化

データ並列化

暗黙的な並列化

用語

コルーチン

サブルーチンが手続き全体を処理する塊に対して、途中で明示的に実行を停止して制御を返すことができる処理
Pythonで言うyield文を使ったジェネレータ的な

goroutine

CSP (Communicating Sequential Processes)という理論にもとづいている

  • goroutineアプリケーションスレッドのスケジューリング
  • スタック管理
  • ネットワークIO

goroutine は並行性(並列性ではない)を扱いやすくするための機能です。複数スレッドで独立した関数を多重化して coroutine のように実行するというアイデアは以前からありました。 ブロッキングするシステムコールを呼び出したときなどで、ある coroutine がブロックするとき、ランタイムは自動的に OS の同一システムスレッド上で他の coroutine が一緒にブロックされないように、実行可能な別のスレッド上に移動します。プログラマがこれを意識しない、これが重要な点です

軽量スレッドと捉えるよりも、内部的にはジェネレータみたいな呼び出し待ちををランタイムがスケジューリングしてるイメージなのかな。
だからcoroutineをもじって、goroutineなのかな

http requestハンドリングでのgoroutine

golangの標準パッケージのhttp serverの実装はgoroutine per request(connection)になってた(http/server.go#2668)
libuvのような非同期IOを使ったコールバックよりも、goroutineによる並行化の戦略をとってるっぽい
そういうもんなんだろうか、、、?

 参考

Parallel programming model
https://en.wikipedia.org/wiki/Parallel_programming_model

Go 言語の goroutine と channel についての考察
http://qiita.com/izariuo440/items/9e1b1faabcee6e2e94c0

イベントループなしでのハイパフォーマンス – C10K問題へのGoの回答
http://postd.cc/performance-without-the-event-loop/

Coroutine
http://qiita.com/fujimisakari/items/811e350cbaeb45b6165e

Go の並行処理
http://jxck.hatenablog.com/entry/20130414/1365960707

「サーバ書くなら epoll 使うべき」は、今でも正しいのか
http://developer.cybozu.co.jp/archives/kazuho/2009/09/epoll-bac0.html