C++幼女先輩

プログラミング成分多め

はじめてDockerHubに登録した

cloud.docker.com

DockerHubとは

Dockerを使った色んなレシピを公開する場所

手順

簡単だったので概要のみ

まずDockerfileを作ります。これは普段作ってるやつでいいです
DockerHubのWeb上でAddRepositoryしてレポジトリ作成。nameはユーザ名、リポジトリ名に作るリポジトリ
DockerImageをBuildする。イメージ名として ユーザ名/リポジトリ名 をつける
docker login で、DockerHubにログインする
docker push ユーザ名/リポジトリ名 で、Push

そのイメージを使いたい時は普段と同じく
docker pull ユーザ名/リポジトリ名 とかすればいい

今回作ったモノ

今のDockerImageは使わないで下さい。消すべきものとかも消さず無駄に3GBと大きいので
サーバレスの開発をするにあたり、便利なDockerファイルを作りたかった
面倒なのですべての開発環境をインストールしたイメージを作りたかった
aws-cli、azure-cligcp-cli、aliyun-cli・・・ node、Pythondotnet core、Go・・・ serverless framework、ngrok・・・
ところが、ビルドやファイルサイズが大きくなるので、やはり正当にタグで目的別にレシピを作る事にした

Serverless Framework

サーバレスで開発するに便利なもの。
コンソールで面倒なデプロイが不要になる。Functionひな型を作ってくれる。コマンド1発でFunctionをデプロイ
プラグインを使えば色んなクラウドサービスや言語に対応
ただしAWS以外は機能は足りてない
調査中

ngrok

サーバレスで開発すると面倒なのが、毎回デプロイしてテストする事
用途は限られるが ngrokを使うと、URLフックをして、ローカルPCに飛ばしてくれる
例えばGitのAPIフックや、BOTAPIフックを、ローカルに飛ばせば
デプロイの時間や、関数呼び出し料金がかからず、ローカルでデバッグ実行も可能
とっても便利だ

今後

ファイルサイズが大きいので、いらないものを削除しよう
色々と便利なのでUbuntu使っているが alpineも作ろう
All-inにしたが 同時に色んなクラウドや言語使う事もないのでちゃんとタグでわけよう

インフラに路線変更?

今までの自分は、C++だったりカーネル、グラフィックライブラリ、シェーダーといった低レイヤーが得意で
そちらの仕事が多かった
が、ここ数年 インフラの人だと呼ばれる事が多くなり、インフラの質問をよくされるようになった

Why?

だけど、みんなが私にインフラを期待しているのではないか?
という事でインフラをちゃんと勉強しようと思う

で、インフラではAWSなりAzureなりGCPが主流である
が、中国と仕事をしたいため、Aliyun アリババクラウドをちゃんと日本に広めようと思う
それと同時に、サーバレスを広めたい
もちろん、インスタンスを起動させる需要もまだまだあるので、サーバレスにマッチするのは一部の機能ではあるが
サーバレスに出来るものは多いはずなので、それらを推進するポジションを取る事にした

Golangの値渡し、ポインタ渡し、インタフェース呼び出しの計測

interface呼び出しのパフォーマンスが気になったので
ついでに値レシーバとポインタレシーバの比較もしてみた

package main

import (
    "fmt"
    "time"
)

type IHoge interface {
    Print()
}

type HogeImpl struct {
    num int
}

func (s *HogeImpl) Print() {
    //fmt.Printf("%d\n", s.num)
    //s.num = s.num + 1
}

func print1(s HogeImpl) {
    s.Print()
}
func print2(s *HogeImpl) {
    s.Print()
}

func printInterface1(s IHoge) {
    s.Print()
}
func printInterface2(s *IHoge) {
    (*s).Print()
}


func bench(f func()(),l int){
    start := time.Now()
    for i:=0; i< l; i++{
        f()
    }
    end := time.Now()
    fmt.Printf("%fsec\n", (end.Sub(start)).Seconds())
}

func main() {
    t := 500000000
    h := &HogeImpl{0}
    bench(func(){h.Print()}, t)
    bench(func(){print1(*h)}, t)
    bench(func(){print2(h)}, t)
    bench(func(){printInterface1(h)}, t)

    //  cannot use &h (type **HogeImpl) as type *IHoge in argument to printInterface2:
    //  *IHoge is pointer to interface, not interface
    //printInterface2(&h)
    //printInterface2(&h)

}

play.golang.org

Playgroundでは負荷かかる処理は実行できないのでローカルでどうぞ

今回は、構造体のメンバも int1個なので、ポインタでも値でも変わらないサイズなので
殆どオーバーヘッドはないはず

結果は毎回誤差はあるが

0.640506sec
0.644128sec
0.642002sec
1.175025sec

基本的に、直接呼出し、構造体値渡し、構造体ポインタ渡しは 誤差範囲 ただ、インタフェース呼び出しは約2倍かかった

5億回の呼び出しで0.5秒のオーバーヘッド。10億分の1秒だ
うちのPCが3.6GHzなので、だいたい4クロック程度(スーパースカラー無視して)

オブジェクト指向であれば、仮想関数テーブル呼び出しなどでそこそこ大きなオーバーヘッドが想定されるが
Goの場合はダックタイピングなので、単純に普通の関数呼び出しが1回増えただけなんだろう

オブジェクト指向とちがい、この辺りのオーバーヘッドは無いに等しい
意外とダックタイピングいいかも
ま、C++でも可能ならオブジェクト指向ではなく、テンプレートでダックタイピング継承するし。

Golangのinterfaceに対する疑問を調べてみた

インタフェース使ってDIの作成していたときに
構造体なら暗黙的に ポインタでも実体でも "." でアクセスできます
C++的にいえば "->" が必要な場所でも暗黙的に "." でアクセスできる
ところが interfaceにすると (*s).Hoge() と、明示的にキャストしないといけなく、"->"が存在しないので面倒でした

そこで仮説として、Goのinterfaceは、既に参照ではないか? と思ったので調べてみました

play.golang.org

結論から言えば、やはりすでに参照です(上記の結果は見にくいですが、Interfaceは実態を渡してもメンバ変数が変化している)

C#でSAPが書ける Blazorフレームワークを勉強したい

qiita.com

まず、私のWeb開発に対する意見なんだけど
ごめんなさい、スクリプト言語は私の中では5年前に終わった
Railsが出た当初は、こんなエコなシステム!RailsだけでWebはいいじゃん
って思った時期もあったんだけど、結局はコンパイルできないためテストコードいっぱい必要で開発速度アドバンテージ失い
PaaSの方がアドバンテージ高く
そしてスクリプトの実行速度の遅さに、決定的だったのがCPUがマルチコア化し、プロセス生成ではもうスペック出せない事

そこで、非同期フレームワークnodeが出たのだが、結局はnodeの速度限界とシングルスレッドしか扱えない事、言語構文から無理が出て

最終的には、JavaScala)、Erlang(Elixir)、 C#、Go、Rust・・・ といった、非同期可能なコンパイル言語以外ないなーと思うように その中から選ぶと
Scalaコンパイル遅い。Javaは言語が古かった(最近のJavaはラムダも使えたり十分だが昔は一貫してオブジェクト指向で関数型要素が入ってこなかった)、Erlang(Elixir)はVMの速度が遅いという話で及び腰、Rustは開発がちょっと遅くて安定しない、C#Windowsでしか動かないから論外
で、Goという選択肢を選んだ

が、最近はその状況もかわってきてる

Javaは最近言語をどんどん柔軟に関数型プログラミングを採用してきたので今は十分使える

Erlangは実際に評価してみないとな・・多分今は問題になるほど遅くはないと思う

www.atmarkit.co.jp
MicrosoftがRust をバックアップするとの事で状況は変わってきた

そして、.net Coreという、マルチプラットフォームで動作する .netフレームワークMicrosoftが発表した!!

という事で、最も期待しているのがC#
そのなかで Blazorというフレームワークが面白そうだ

BlazorはC#でSPAを作れるらしい
なんとViewもC#で作れる
仕組みは、C#で書いてビルド時に .netのILからWebAssemblyに変換してブラウザで実行していると!

ってことで、Blazor注目!!

TODOアプリ

そういえば、ライブラリの勉強の時にみんなが作るTODOアプリ
私は1回も書いたことがない
一度作ってみようか?

でも実際は、TrelloとかRedmineGithubを使うんだけど

個人用のTODOアプリを今まで Trelloで使ってて、ちょっと機能大きすぎ感があり
GMailのTODOアプリに変えたけど今度は機能すくなく

今は Microsoft TO-DO がちょうどいい大きさなので、使っています