C++幼女先輩

プログラミング成分多め

営業について

わたしは営業が下手で営業できないからそれ以外の方法
技術力で殴って、コネとSNSで仕事が向こうから来る営業レスのスキームの構築
これを重視していて
実際、ほぼ営業せずに10年ぐらい仕事が追いかけてきている

でも、先日知り合いに、それが圧倒的な営業力だよ! って言われた

なるほど。そういわれるとそうかもしれない。
一般的な方法ではないかもしれないが、それで仕事十分にとれてるから
営業ができているのだろう

そして、今までは仕事を待つスタイルで一人分の仕事は確保してきたが
こっちからも営業をかけて人脈広げれば、それが何倍も案件がきて
社員を数名雇っても十分に食わせてやれる、みんなを幸せに出来るかもしれない

技術者の多くは、営業が出来ないばかりに、営業が出来る会社に搾取されて幸せになれていない
それなら私が裕福にさせてやろう

サーバレス考察 thinking of serverless

メモ

Docker

サーバレスに使うDockerHubを作成中

ServerlessFramework

サーバレス開発を楽にする

serverless.com

上記のフレームワークを使えば、Functionのデプロイがコマンド一発、設定ファイルでFunctionを設定できる
AWS以外のものはPluginを入れれば対応可能
他にもPluginがあり使いこなすと便利だと思われるので調査したいところ
また、AWSだとCloudFormationのYamlを書くことでFunction以外のデプロイも可能
AWS以外のクラウドサービスは出来ないかも

Monolithic vs SinglePurpose

hackernoon.com

SinglePurpose(1機能に1Function)がサーバレスでは普通に使われるが
特定URLに対してFuction内部でルーティングをして複数の機能を1つのFunctionに持たせる事も可能(Monolithic)
どちらが良いかは、プロダクトによるが、Monolithicの開発手法は勉強しておきたい
まだ詳しく考えてないが、Monolithicだと 関数が大きくなるのでColdStartが遅くなる可能性もあるが、一度何かの関数が起動すればHotStartになるので
全体的にみればColdStartの割合が減ると考えられる
コードの管理に関してはDevOpsやればどちらも変わりないかもしれないが一般的にはMonolithicの方が手軽である

aws-serverless-express

qiita.com

qiita.com

通常の express開発と同じコードで動かせるらしい
基本的にはListenを行わくなり、Lambdaから引数を取る作りなのであろうか
Monolithicなのかな? 調べてみよう

Serverless-http

qiita.com

東京の一等地に家を買ってローンレンジャーになるかもしれない話

あらすじ

私は昔からシェアハウスに住んでいる。シェアハウスは良い事と悪い事がある

  • pros
    一人暮らしに比べると家賃が低い
    敷金礼金が低く、頻繁に引っ越せる。住民と気が合わなければすぐに出れる
    ネット通販の荷物が誰かが受け取ってくれる可能性が高い(あるいは集荷箱がある)
    人が沢山住んでいるので防犯面で安全かもしれない
    ご飯を複数人でシェアしたり、生活面で便利な事も多い
    色々な人と会話をして知見が広まる

  • cons
    部屋が狭い(ドミトリだとベッドのみ)なので荷物が置けない(メリットでもある)
    住民トラブルを我慢しなければならない(簡単に出ていけるけど)
    興味がない話や相談を聴かねばならぬ時もある(それも人生だね)

私にとってはメリットの方が多いので、ドミトリのシェアハウスに住んでいる
ただ、ゲームしたり、デスクトップPCで仕事したり、色々な便を考え、最近はそれにプラスして近所に事務所借りている

トラブル発生

住民トラブルであれば、解決もできなくもないが、うちのシェアハウスは管理人の人格が酷い
もちろん、それを面接時に理解したうえで我慢できるので入ったわけだし、実際3年ちょっと我慢しているが
先日、他の住民に被害を与える酷い事をした
私を含め数人の住民がそのことで堪忍袋の緒が切れて、半分のメンバーが退出を決めた

新しいシェアハウス

住民同士は仲がいい、とくに退出するメンバーは元々仲がいいメンバーなので、可能なら一緒のハウスに入ろう
まとまった人数いるから、新しいシェアハウスを作ろうという話になった
ただし、賃貸で借りるといまのシェアハウスよりどうしても賃料が高くなってしまう
私が家を買ってシェアハウスにすれば、賃料を下げる事が可能

そんな流れでシェアハウス運営する事になり、物件を探している

物件計算式

まず、月々のランニングコストだが、8名ほど生活するとして電気水道ガス料金は4万あれば足りるかな・・というところ
インターネット代金、月々の敷金(家電壊れるしトイレットペーパーなどの補充品)考えると7万円みておきたい
例えば 3LDKで2部屋をダブルベッド2個ずつ入れ、1部屋を私の仕事部屋にする計算で
今住んでいる場所の近くでは賃貸だと、月々27万円であるので毎月のランニングコストは34万
8人で割れば4.25万だが 事務所代金6万、1名を掃除や管理スタッフとして家賃を0にし、埋まる率を8割とすると 家賃は5万 家賃を4万まで下げたかったので、賃貸は難しいと判断
ま、もともと賃貸はシェアハウスに厳しいし、家の改造出来ないし

家を買う時の計算だがほんと物次第である
月々のランニングコストはだいたい同じぐらい。固定資産税をいれて8万ぐらいとする
建売新築をこの辺りで買うと 8000万円ぐらいか。建物代金がそのうちの2500万ぐらいだろうか
購入の手数料10%、建物にかかる消費税8%を加えると丁度1000万。また家の什器家電そろえるのに200万として1200万
つまり、土地が5500万、建物その他が3700万円となる
今は東京の土地は高騰していて今後は下がるリスクの方が高い。かりに20%下がるとして地価変動で1100万円
つまり 4800万円ペイできれば土地を売ってもトントンという事になる
で上記の計算で 家賃を4万、一人スタッフ、入居率80%、ランニングコスト8万円とすると月々の家賃収入 16.4万円
で計算すると、24.4年で土地以外をペイできる。
もちろん自分の家賃は計算していないので、仮に私が毎月6万の家賃が浮いているとすれば 17.8年でペイ
気が長い話である
住民にとっては新築一軒家に月4万円はお得だろう

仮に、古い建物で我慢するとして、建物の価値がほとんど存在しないもの、多くみつもっても1000万の場合は
総額6500万。うち土地は5500万。手数料650万。消費税80万。初期設備200万。土地が20%下がったら1100万。リフォームに300万
で計算すると 2330万
これだと11.8年でペイ。自分の家賃6万にすると8.7年
10年でペイとなると悪くはないのだろうか?
土地が暴落しなければいいんだが・・

という事で、いい物件探し中

はじめて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++でも可能ならオブジェクト指向ではなく、テンプレートでダックタイピング継承するし。