vgoを今やり始めると辛いからやめとけ

注意

ここの記事で書かれている操作は、 https://github.com/golang/go/issues/24917 で報告した https://github.com/ory/fosite-example をvgoでビルドしようとして検証しています。

利用したvgo

  • golang.org/x/vgo203abfb0741bf96c7c5e8dab019f6fe9c89bded3 の時点で go get -u golang.org/x/vgo したもの
  • go version go1.10.2 darwin/amd64 vgo:2018-02-20.1

TL;DL

思った通りの状態にならない。
ライブラリ作者全員semverで殴って回る必要がある。
ログから情報が得られない。
実行もクソ遅い。
ゆえに辛い。

まずはじめに

Goユーザは $GOPATH の中で生きている。
アプリケーションのパッケージ管理のため、vendoringの仕組みができた。
パッケージマネージャとしてgbとかdepとか色々なものがあった。

あったけど、最終的にgoコマンドに組み込みとなる、最終的なパッケージ管理の仕組みが生まれようとしている。
vgoだ。
今はvgoという名前だけど、最終的にはgoに組み込まれる(はずだ)。
このproposalは既にacceptedになっていて、未来は確定しつつあります。

この記事ではこれ以上のvgoについての説明を行わない。
詳しく知りたい人は、Go & Versioning[和訳]を読むといいだろう。

vgoのここが良い!

まずは良いところを。

$GOPATH free

プロジェクトを配置する場所が $GOPATH 配下に限定されなくなります。
好きな場所に置いてよい!やったー!

SemVerの採用とタグベースの運用

Goもsemverで運用されていきます。
何かしら更新があれば、gitでtagを打ちpushされる世界になるでしょう。
この文化が浸透すれば、依存しているライブラリのバージョンアップは非常に容易な作業になっていくでしょう。
npmにpublishしているユーザがみんなお行儀よくなっていったように、Goコミュニティもsemverに慣れていくでしょう。

同一ライブラリの異なるバージョンへの依存への(文化的)解決

複数のライブラリを使う場合、依存関係的には孫にあたるライブラリが重複し、かつ異なるバージョンを参照したい場合があります。
これは、今までの単層のvendoringでは難しかったのですが、これに対して github.com/vvakame/hoge/v1github.com/vvakame/hoge/v2 に分けておけばいいじゃない という斜め上の解決が行われました。

斜め上といえば斜め上なんですが、旧バージョンについてもpatchを受け付けられるとか、管理がしやすくなるという点で良いこともあります。

素直に読むと、リポジトリのrootに置いてあるコードは互換性のためにずっと残しておけ、みたいなことを言っててヤベーこと言いよる…という気持ちです。
でもまぁこれは v0 を切って、最初はそこで開発するなどの開発者側のワークアラウンドでなんとかなるレベルかもしれません。

あとは、エディタがpackage内でちぐはぐなバージョンを自動的にimportしないように気をつける必要があります(つらそう

goコマンドに組み込み

単にgit cloneして、 vgo test all とかすれば、依存ライブラリを自動的に取ってきてくれて動きはじめる!
ライブラリ追加したければ vgo get go.mercari.io/datastore とかやるだけ!
すごい!楽!わかりやすい!初心者の味方!

vgoのここがヤバい

ついでやばいところを述べていきます。

中途半端にタグがついているリポジトリ

google.golang.org/appengine はアクティブに開発されているリポジトリだが、2016年に v1.0.0 タグが切られ、その後は何もない
vgo(やdep)で単純に google.golang.org/appengine を追加すると、2年も前のリビジョンを使わされてしまう!
辛いですね。

この問題はライブラリ作者全員がヤル気を出し、ちゃんとタグをつける運用を開始したら解決されます。
ライブラリ作者全員をsemverで叩いて回りましょう。

使えない master/HEAD

上記の問題を解消するには、 vgo get google.golang.org/appengine@master を実行すれば…。
と思いきや、コレでもダメで、 v1.0.0 にされてしまいます。
vgo get google.golang.org/appengine@b1f26356af11148e710935ed1ac8a7f5702c7612 も同様。
go.mod 中の requiregoogle.golang.org/appengine master に書き換えて vgo get -u しても v1.0.0 に戻される…。

どうすればいいんですかね…?
なにがどうなってどう go.mod が書き換わったのか、というのがログから全く読み取れない…。
気持ちよく動いてる間は便利なのかもしれないけど、意図通りにならない時に完全にブラックボックス化していて辛い。
しかもこのブラックボックスは将来的に go 本体に組み込まれてしまい回避不可能になるんだぜ…。

この問題はライブラリ作者全員がヤル気を出し、ちゃんとタグをつける運用を開始したら(masterを使いたいという欲求がなくなるので)解決されます。

いつの間にか巻き戻るバージョン、消えるパッケージ

vgo get google.golang.org/appengine@master すると何故か require に書かれるパッケージが減ります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
diff --git a/go.mod b/go.mod
index 4c08ba1..d2f7a72 100644
--- a/go.mod
+++ b/go.mod
@@ -2,28 +2,24 @@ module github.com/ory/fosite-example

require (
github.com/asaskevich/govalidator v0.0.0-20180319081651-7d2e70ef918f
- github.com/davecgh/go-spew v1.1.0
github.com/dgrijalva/jwt-go v1.0.2
github.com/golang/mock v1.1.1
github.com/golang/protobuf v1.1.0
github.com/gorilla/context v1.1.1
github.com/gorilla/mux v1.6.2
- github.com/gtank/cryptopasta v0.0.0-20170601214702-1f550f6f2f69
github.com/jtolds/gls v0.0.0-20170503224851-77f18212c9c7
github.com/magiconair/properties v1.8.0
github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826
github.com/moul/http2curl v0.0.0-20170919181001-9ac6cf4d929b
github.com/oleiade/reflections v1.0.0
- github.com/ory/fosite v0.20.3
+ github.com/ory/fosite v0.12.0
github.com/ory/go-convenience v0.0.3
github.com/parnurzeal/gorequest v0.2.15
github.com/pborman/uuid v0.0.0-20180122190007-c65b2f87fee3
github.com/pkg/errors v0.8.0
- github.com/pmezard/go-difflib v1.0.0
github.com/smartystreets/assertions v0.0.0-20180607162144-eb5b59917fa2
github.com/smartystreets/goconvey v0.0.0-20180222194500-ef6db91d284a
github.com/stretchr/objx v0.0.0-20180531200725-0ab728f62c7f
- github.com/stretchr/testify v1.2.1
golang.org/x/crypto v0.0.0-20180606015541-b47b15873692
golang.org/x/net v0.0.0-20180530234432-1e491301e022
golang.org/x/oauth2 v0.0.0-20180603041954-1e0a3fa8ba9a

なんでやねん。
google.golang.org/appengine は変わってないくせに…。
何がどうなってこうなったのかはログからは全くわかりません。

本当に最新なのかわからない vgo list -m -u

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
$ vgo list -m -u
MODULE VERSION LATEST
github.com/ory/fosite-example - -
github.com/asaskevich/govalidator v0.0.0-20180319081651-7d2e70ef918f -
github.com/davecgh/go-spew v1.1.0 (2016-10-30 05:57) -
github.com/dgrijalva/jwt-go v1.0.2 (2014-08-27 05:51) -
github.com/golang/mock v1.1.1 (2018-04-06 06:54) -
github.com/golang/protobuf v1.1.0 (2018-05-01 03:52) -
github.com/gorilla/context v1.1.1 (2016-08-18 03:46) -
github.com/gorilla/mux v1.6.2 (2018-05-13 12:22) -
github.com/gtank/cryptopasta v0.0.0-20170601214702-1f550f6f2f69 -
github.com/jtolds/gls v0.0.0-20170503224851-77f18212c9c7 -
github.com/magiconair/properties v1.8.0 (2018-05-16 05:40) -
github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826 -
github.com/moul/http2curl v0.0.0-20170919181001-9ac6cf4d929b -
github.com/oleiade/reflections v1.0.0 (2016-08-17 15:46) -
github.com/ory/fosite v0.12.0 (2017-10-25 19:16) v0.20.3 (2018-06-07 19:52)
github.com/ory/go-convenience v0.0.3 (2018-05-29 20:36) -
github.com/parnurzeal/gorequest v0.2.15 (2017-02-21 02:20) -
github.com/pborman/uuid v0.0.0-20180122190007-c65b2f87fee3 -
github.com/pkg/errors v0.8.0 (2016-09-29 10:48) -
github.com/pmezard/go-difflib v1.0.0 (2016-01-10 19:55) -
github.com/smartystreets/assertions v0.0.0-20180607162144-eb5b59917fa2 -
github.com/smartystreets/goconvey v0.0.0-20180222194500-ef6db91d284a -
github.com/stretchr/objx v0.0.0-20180531200725-0ab728f62c7f -
github.com/stretchr/testify v1.2.1 (2018-02-01 07:38) -
golang.org/x/crypto v0.0.0-20180606015541-b47b15873692 -
golang.org/x/net v0.0.0-20180530234432-1e491301e022 -
golang.org/x/oauth2 v0.0.0-20180603041954-1e0a3fa8ba9a -
golang.org/x/text v0.3.0 (2017-12-14 22:08) -
google.golang.org/appengine v1.0.0 (2016-09-30 05:31) -

上から順に見てVERSIONがくっそ古い jwt-go を適当に見に行ってみました。
最新はv3.2.0です。
確かに、 ^1.0.0 の範囲だと v1.0.2 は LATESTなんですが、プロジェクトを健全に保つために知りたいLATESTは v3.2.0 だと思います。
vgo get github.com/dgrijalva/jwt-go しても v3.2.0 にはなりません。
vgo get github.com/dgrijalva/jwt-go@v3 してみたら go.mod から jwt-go が消えました。
一体全体どういうことだってばよ…。
何がどうなってこうなったのかはログからは全くわかりません。

ひたすらに遅いコマンド類

1
2
$ time vgo list -m -u
vgo list -m -u 1.60s user 0.89s system 8% cpu 28.836 total

何回も実行した上でコレです。
初めて vgo get google.golang.org/appengine@master を実行した時はカップラーメンのためにお湯を沸かしてお湯入れて待って食べてSplatoon2起動するぐらいの時間がかかりました。

まとめ

この中で何が起こってるかもよくわからず --help でロクな情報が得られないシステム、誰が使えるの???
ストレスでハゲそう。

この記事は社内Slackでクダをまいてたらそれを#4 Open Go Fridayで話せと @tenntenn さんに言われたので書かれました。

技術書典4で『Re:VIEW+CSS組版やっていき』を頒布します

はい。
明日が技術書典4当日なのであまりにもギリギリすぎるブログです。

ひかる黄金わかめ帝国 サークル詳細ページはこちら。
当日は333円、かんたん後払いサービスでのお支払を受け付けています。

筆者である僕が運営スタッフを兼ねているので終日不在の予定です。
ざっくりした店番だけTechBoosterの面々に頼んであります。

TechBoosterのNow and Futureに収録されるか!?されへんか!?どや!?168P?はいドロップ!
という流れだったので、準備がなかなか急でした。

前回の反省は次の通りでした。

  • 前日にKinkosでダウンロードカード刷るのつらい
  • 慢心して見本誌作成しなかったら案外売れ行き伸びなくてつらい

というわけで、今回はかなり色々な割り切りをすることにしました。

  • 現金の取扱をやめ、かんたん後払いのみにする
    • 釣り銭などの準備が不要に!
  • 前回同様、製本はしない 電子版のみ
    • 自分がブースにいない想定なので楽を取っていく
    • TechBooster側に収録されるか不明だったので表紙も発注する暇なかったし
  • 表紙はゆかりさんに頼む
    • 前回はSurface Proで自分で書いたのだった(めんどかった)
    • 写真+デザイン用ツールとしてAffinity Designerを利用
  • ダウンロードカードのダウンロード用URLを全員一律にした
    • Google Driveの共有URLを一律で印刷した
    • Google Driveの場合、後からデータの更新がしやすい
    • URL個別にしたところで再アップロードとかの悪意にあうとさほど意味がない
    • どうせ後でGitHubのリポジトリ公開するし…
    • 表裏のデザインが全カード共通になったので名刺shop.comさんの両面印刷でOK
  • 見本誌ちゃんと刷る
    • 今回はネタ的に既存手法(LaTeX版)と提案手法(CSS版)が比較できないと面白くないので必須
    • セブンイレブンの同人プリントでやった
    • 仕様上の癖が結構あったので、前日に1発で成功させるのはつらそう
  • お品書きちゃんと作る
    • 当日ブースにいないのでなんとなく内容がわかる紙が必要だよねーってなった

内容はざっくり次の通りです。
後日全文をGitHub上に公開します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
     3KB   1044C    29L  はじめに (preface)
1. 4KB 1782C 54L {why-css-typesetting} なぜCSS組版か? (why-css-typesetting)
2. 4KB 1482C 46L CSS組版について知ろう! (whats-css-typesetting)
26L 1 vivliostyle.jsについて
3. 22KB 11432C 476L 実際にやってみる (practice)
12L 1 TechBoosterのワークフロー with Re:VIEW
15L 2 ブラウザからPDF出力の下準備
25L 3 1枚のHTMLを出力する!気合で
36L 4 扉や奥付のページを表示したい!
34L 5 目次を表示したい!
28L 6 ノンブルを打ちたい!
62L 7 柱に現在表示中の章タイトルを表示したい!
61L 8 テキスト周りの見た目をなんとかしたい!
77L 9 脚注を表示したい!
20L 10 画像をセンタリングしたい!
53L 11 ボックス系の見た目をいい感じにしたい!
24L 12 ページ上部に雑に線引きたい!
10L 13 Vivliostyle Viewerを使ってデータを表示する
4. 14KB 6206C 199L 未解決の課題 (issue)
6L 1 問題の上手な切り分け方
30L 2 PDFの生成とフォントの埋込
8L 3 凝ったデザインへの挑戦
9L 4 HTMLBuilderが吐き出すアンカーとリンクを修正する
13L 5 CSSの管理方法
28L 6 ボックス系の見た目と脚注が被る話
18L 7 vivliostyle.jsのレンダリングがリロードで壊れる場合がある
44L 8 CI上でPDFを生成させ再現性を持たせる
8L 9 他のブラウザを検討する
29L 10 他の組版エンジンを検討する
16L 1 [column] トリムマーク社が爆誕した話
5. 5KB 1852C 73L まとめ (conclusion)
3KB 1065C 36L おわりに (afterword)
3KB 1726C 94L Re:VIEW記法出力見本 (syntax-example)
89L 1 出力見本
1L 1 [column] コラム
2L 2 節です
1L 1 項です

お品書き

kmutoさんにも次のお言葉をいただきましたし、やっていきだと思われます。

なお、この本はpentapodさんの本を読んであるとより詳しく知ることができると思いますのでみんな買おう!

実際に入稿したい場合は、負けたくない!Splatoon2のこの辺のログが参考になると思います。

会社の制度で深圳に行ってきた話

最近インプットやらアウトプットやらがめっきり減って危機感を覚えるわかめさんです。
今日は喉風邪を引いて布団でマンガ読みつつゆかりさんとだらだらしてたよ!
ゆかりさん足元で丸くなってぴーすか寝てたまに毛づくろいしててめっちゃ可愛い。

会社の制度?Mercari Tech Research?

なんかそういう制度があって、世界の色々なとこの進んでそうなサービスやら概念を偵察に行けます。
今年は脊椎反射で色々なことに片足突っ込んでみて、後で痛い目にあったら反省しようということにしたので、この制度に応募してみることにしました。

そしたらなんか当選したので深圳に行きました。
他に上海とかインドとかの選択肢がありましたが、昔の秋葉原の電気街っぽい感じとも聞きますし一番肌に会いそうだったので。

「Mercari Tech Research」について

何をしにいったか

すでにみんながスマホでの決済サービスを利用している世界観を体験しにいく

↑これが僕の目的です。
なんかメルペイ社というやつがあり、決済をやるそうなんですが自分たちが実現したい世界の一端が既にわりとあるっぽい土地があるそうなので、見ておいたほうが後々の話が早かろうということで体験しにいきたかったわけです。
なお、ここで書かれていることはvvakame個人の感想であり、うんぬんかんぬんです。

僕が務めるソウゾウ社はメルカリ子会社なんですが、メルペイ社というやつもあり、両社ともアホみたいにパワフルマンを欲しがっています。
強い人を求めていますので気が向いたら適当にソウゾウ/メルペイに応募してみてください。

TL;DR

  • マジで現金1ミリも必要ないしスマホあればなんでもできる
  • どこでも使える のが一番えらい
  • QRコード決済別に早くない
  • NFC(Felica)やっぱ早い
  • QRコード(=非接触読み取り)、応用範囲が広く優れている
  • スマホがSPOFすぎて不具合出るとなんも出来ない
  • スマホすらなくても決済できたほうが便利じゃね?
  • シェア経済、特にモバイルバッテリーのシェア嬉しさがすごい

雑な決済周りのレポート

微信支宝(WeChatPay, weixin)と支付宝(AliPay, 中国語読みわからん)の2強。
外国人(= 俺)でも使いはじめやすいのはweixin。
現地の人は給料の受取もAliPayらしい。weixinは口座に振り込みに手数料取られるそうなので。

weixinで支払いが出来なかったのは空港の茶葉屋さんだけで、他はどんな店でもweixinで支払いができた。
現地で現金は1回も出番なかったです。
“どこでも使える”のが、考えるコストを減らしていて最高に良かった。
ゲーセンのマシンにクレジット追加するのすらQRコードだった。
新規の設備投資無しでも始められるというのも強そう。QRコードとか印刷もできるし…。

weixinでの支払い方は2パターン。
1つ目が自分のスマホでお店のQRコードをスキャンして、金額を入力して、PINコード入れて、店員さんに見せる。
このやり方は屋台などの小売店で多かった。
2つ目が自分のスマホで決済用バーコードを表示して、お店の端末でスキャンしてもらい額面を確認して、PINコード入れて終わり。
こっちはそれなりにデカいお店で多かった。

さて、このQRコードをスキャンする方式ですが、やってみるとわかるんですがスループットが全然出ない。
これで問題になっていないのは、単に店に行列ができないからなのでは?という見立て。
少なくとも日本の朝や昼飯時のコンビニで使う気にはならない。どう考えてもNFC方式のほうが早い。
一方、昼食の会計など、スループットが気にならない場所であれば問題にならない。
慣れてきたら違うのかもしれない…?

QRコードにも良いところがあり、それはNFCのような距離の制限のない光学式であるということ。
僕が一番頭いいなー!と思ったのは、駐車場の出口で壁に1mくらいの大きさのQRコードが貼ってあり、運転席からそれをスキャンして支払いが可能だったこと。
タッチしたりする必要がないので車から出ずに窓すら開けずに出庫できるのはなるほどー考えたなー!という。

で、全てのインタラクションの出入り口がQRコードに集約されているので、町中の支払いとは関係ないQRコードでもとりあえずWeChatアプリで読み取る。
これは企業側としては検索エンジンを自分で作るのに匹敵する”良さ”があるな…と思った。

あと、weixinにはミニプログラムというのが組み込まれていて、要するに認証周りにちょっとチートのあるWebページ(と僕は理解している)で、ここから様々なプログラマブルな決済機能を提供することができる。
具体的に、ゲームセンターの会員サイトや飲食店での注文&決済機能など。
これはあると便利ですわ… 知らない企業に個人情報を渡す頻度が高いのでそこの抵抗感が多少あるけど…。

大変便利なスマホ決済経済圏なんですが、スマホが壊れたり不具合が起こったり電池が切れたりすると一瞬で人権がなくなります。
実際に、現地でアテンドしてくれたエンジニアの人が地下鉄に乗る時に改札でNFCが反応せずに10分くらい詰まってしまい、最終的にチケットを買っていました。
なので、スマホすら無しで決済できるのが最強かもしれない。セキュリティどうするのそれ。

雑にシェア経済について

Mobikeとofoなどの自転車シェアサービスにとどまらず、割りと色々なものがシェアされていてビビる。
傘やモバイルバッテリーや車などもその対象で、スマホの電池が切れると人権がないこの世界ではモバイルバッテリーのシェアは完全に人権が補給できる感じで強そうだった。
そして基本的に料金がハチャメチャに安い…。なんでも、”もってる奴”(=企業側)が負担しろよ〜という空気感があるそうだ。

深センという土地

深センで使う必要がある言葉は3語だけで、weixin, xie xie(ありがとう), bye byeだけだった。
Yes/Noを中国語でなんというのかすら覚えなかった…。

華強北はざっくり20年前の秋葉原はラジオデパートみたいな雰囲気で、楽しそう。
春節のお尻のアタリにぶつかってしまったのであまり街が稼働してなかったんだけどこれは無限にウロウロしていられる予感がした。

わりと儲かっている地域であり、ここ数年は性善説で世界が回り始めているらしい。
実際にボラれそうになったこともなく、わりとみんな笑顔で怒っている人とかいないし親切ですごい。
いい土地。
上海行った組はボラれそうになったタイミングもあったそうで、運の差か土地の差か…?

現地でアテンドしてもらったofoのエンジニアの人と、企業訪問させてもらったCVTEの人達も、めっちゃ優しくて親切だし気前がよかった…。
この辺りの人はだいたいみんな英語できた。
その辺の店員さんとかの英語力は日本人のそれとあまり変わらなさそうだった。

その他

Googleピンイン入力はいいぞ

読めない文字を手書き入力できて最高。
現地の人にここに言いたいこと書いてくれ!って頼んでMicrosoft翻訳とかに突っ込む。
“あなた3回暗証番号間違えたのでこのカードロックされましたよ”って言われた時は泣いた。

クレカの番号6桁

なんか6桁らしいです。
普段の4桁の頭に00つけるとかお尻に00つけるとか色々あるっぽいのであらかじめ調べていきましょう。
基本的にはweixinでいけるので出番はあまりないですが…。

感想

深圳よいとこ一度はおいで。
他にも色々掘り下げられることはあったんだけど、既にここまで書くのに90分かかっているのでこの辺でやめておく。

参考

猫が我が家に来た話

丁度1ヶ月くらい前の11/26に、我が家ににゃんこがやってきました。
猫飼いたい飼いたい言ってたけど正直積極的姿勢ではなく、消極的猫飼いたいでした。
とかいいつつ去年の12月に引っ越した時にペット可物件を選び敷金もデフォで1月分積み増していました。
口ではなんと言っていても財布は正直だな…!

猫データ

項目
名前 ゆかりさん
年齢 3歳?(1歳以上は確定)
体重 3.5Kg
品種 ノルウェージャンフォレストキャットとラグドールのMIX
見た目 ハチワレ(かわいい)

のり子だなんだと名前案が提出されましたがゆかりさんになりました(VOICEROID並感)。
Twitterだと「ふわふわちゃん」とツイートすることが多いですね。
靴下はいてておめめくりくりでふわふわでちっちゃくて可愛い!

様子

来た当初は夜はベッドに乗ってくるにゃんだったゆかりさんですが、僕の寝相が悪かったのに懲りたのかベッドに乗らないにゃんになりました。
避妊手術から帰ってきたあたりから再度ベッドに乗るにゃんと化したふわふわちゃん。
夜寝てる間に蹴っ飛ばさないように、ベッドに斜めに寝るという対処法を編み出しました…。

カラーと包帯をつけてた間は動きが不自由なのでベッドの上にいることが多かったんですが、元気になったらまたキャットタワーの上にお帰りあそばされました。
な、撫でさせてくれぇ……!!

あと過去のツイートをまとめてお茶を濁す!

11/19

面会しに行く。
行く前からこの子がいいかなー、と目星をつけていた。
写真から生後半年枠の子だと思っていたけど3歳くらいだそうな。
子猫はちゃんとお世話できるか自信なかったので丁度エアロ!という気持ちになる。
引き取る事を決め、ひたすら猫グッズを買い集める。

11/26

ふわふわちゃん来る。
引き取りに行ったら自分からケージに入ってくれて嬉しかった。
ペットタクシーで自宅へ。
自宅に来たら割りとすぐにケージから出て部屋を一周探索する。
肝が太い子だなぁ…!と思った(後にそうでもないことがわかる)。

最初からトイレも爪とぎも道具がある場所で適切にできる、躾のいい子で大変楽でした。

11/28

12/02

12/03

12/06

12/09

12/10

12/12

12/13

12/15

12/16

12/18

12/19

なお、この日に避妊手術で入院でした。

12/20

退院。カラーと包帯がストレスなようで可哀想…。
12/26に全てが終わる!

12/24

12/25

一昨日くらいからお腹がピーなので病院に。
注射を打ってもらって飲み薬をもらう。
猫 飲み薬 で検索してみんな絶望しよう!(ちゅーるにお薬載せたら簡単に全部ペロンと食べて杞憂に終わった)

12/27

お薬をまだ飲ませているんだけど、ちゅーるの部分だけ舐めて錠剤をペッ!てする技術を身に着けはじめました。つらい。
ちゅーるでコーティングしていいタイミングで舌の奥に送り込むテクが必要になってきました。

備忘録

わかめさんは大変な心配性かつ保守的人間であるため、にゃんこを飼う前後の心労が激しかったです。
現在、避妊手術の後の包帯&カラー期間なので心労が激しいままです。
来年はもうちょっと心安らかに暮らしたい…。

  • 猫がやりたいことを制限するのはほぼ不可能
    • 行ける所は全部行く!
    • 台所には侵入できないようにしていたが小窓から突入していくのでドアフルオープン化
    • 台所のシンクに突入していくことがあったので台所が常にキレイな状態で保たれるようになった
  • 1週間程度ではまだビビられまくり
    • いかに構わずに放置するかに腐心するフェーズ
  • 1ヶ月程度ではまだ慣れない
    • ちょっと抱っこしたり撫でたりすりすりしたりは平気になった
    • 向こうからすりすりしてきたりはしない
  • 食べ物はあまりちょいちょい変えないほうが良さそう
    • どんな時でもちゅーるは喜ぶ
  • 食べたり飲んだりしてる間はある程度元気な証拠
  • 健康面(ほぼ済)
    • FeLV/FIV陰性
    • 三種混合予防接種
    • 血液検査問題なし
    • 避妊手術
    • マイクロチップ
  • ペットタクシー
    • ワンハウス 動物病院にチラシがあったので利用 Webサイトもうちょっとなんとかならん?
  • ペットホテル&ペットホテル
    • おなじみの猫カフェ ねこまるカフェがサービス提供しているそうなのでいざとなったら…
    • 移動は猫に負担になるので基本はホテルよりシッターさんを頼む方針

猫グッズ

買ってよかったものを抜粋して紹介。

トイレの質が改善された(気がする)。

流れる水がお好きらしい。

あまりご飯を食べないのでどのくらい食べたかの把握に必要。

比較的省スペース。
猫は広さよりも高低差のある運動が必要だそうで。

とりあえず1冊買って勉強。

一番よく遊んでるおもちゃ。

二番目によく遊んでるおもちゃ。一人で遊ぶのが好きで、僕が手に持って遊ぼうとするとすこし及び腰。

大変使い勝手のよいケージ。
普段は入り口のドアを外して部屋の中に置いてあります(たまに入ってくつろいでいる)。

トイレ掃除に。これに入れて縛って捨てると匂いがまじで漏れない(すごい)。

トイレまわりの清掃に便利。

トイレ。シートは週1、砂は月1の交換で全然臭わなくてすごい。
お腹がゆるくなると砂が一瞬で減っていくので買い置きは潤沢に…。

一番お気に入りの爪とぎ。

ご飯茶碗。ちょっと端っこに残ったのが食べにくいっぽい…?

毛がもさもさ取れる。一般的なブラシも試してみたけど、こっちのほうが圧倒的に取れる。
あまり使わせてくれないけど…。気持ちよくはあんまりなさそうな気がする。

最後にほしいも貼っておきますね!(ただし贈ってもらっても恩を3時間で忘れるタイプの雑魚)

きっかけ

色々な要因がありお見合いしにいき、可愛いやん…!ってなってしまったため無事引取…という流れになりました。
ふわふわちゃんかわにゃんオブジイヤーじゃない?

ソウゾウ社に転職した話

めっちゃ今更なんですが10月の頭にソウゾウ社に転職しました。
人間が高速に吸い込まれているとかGAE/Goできる人間が転職したという情報を聞いたら社名を聞かずともどこ行くかわかると評判です。

ソウゾウ社はメルカリ社の100%子会社なんですがメ社に比べると知名度が圧倒的に低いです。
みんな、ソウゾウ社の名前覚えていってくれよな!

ソウゾウ社、いい会社ですよ。
上司的な人に何か言うと「いいですね!!」以外の反応が帰ってこないのでこの承認フローは意味があるのか??と疑問に思ったりすることもありますが私は元気です。

で、わかめさんはソリューションチームというところでなんか社内のためになりそうなことをやる的なアレをしています。
入社してからmercari/datastoreというライブラリをせっせと作っていました。

ぼくが かんがえた さいきょうの でーたすとあ らっぱー

ていうかまだ作ってます。
技術書典公式WebのAPI実装は完全にコレに置き換わっているので、とりあえず1サービスを支えることができる程度の出来上がりにはなっています。

GCPUG Slack#g-cloud-datastore_ja に常駐しているので何かあったら適当にアレしてください。

なんか新規事業をぽこしゃか作っている感があり、最近もメルペイとかいう会社がなんかアレされてそれに参加したい人を集めているらしいです。
わりと楽しそうな雰囲気なので興味がある人があればmeetupにも来てみてね!

ブログ作った

jxckパイセンのブログが羨ましかったので作った。
とはいえ、jxckパイセンのようにWeb技術の最先端の実験とかにはあまり興味がないので何の目的があって作ったのかは怪しい。

プログラミングの話はまぁQiitaに書けばいいかという向きもあるんだけど、クソくだらない事とか読書感想文とかAnovaの話とかぐだぐだ書くにはブログがあったほうがいいよね。
過去にもはてなブロったりしてたけどまぁ引き継ぎとかは考えなくていいかという気持ち。

今回はGitHub上でmarkdownで記事を持っておくとどっかが何かの都合で消し飛んでもまぁ困らないし便利そうだ。

ローカルに自分のブログ記事が全部あるというのはなかなか重要で、自分の著作物全てがローカルにあると適当にgrep1して探すみたいなのが可能である。
過去に日経ソフトウェアやWEB+DB PRESSに書いた原稿ももちろん全てローカルにあるので、Googleに聞くより手元で検索したほうが早いのである。


  1. 1.grepして とか書いているけど実際に使っているのはagである。grepはオプションが覚えられない…。

SOFT SKILLSを読み終わった

最初にこの本のことを知ったのはhigeponさんのブログだったと思う。

この本は全7部、71章からなっている。
僕の感想としては4部まで(つまり前半60%まで)読めばよいと思う。
4部まではvvakameが真似できる範囲・納得できる範囲のことが書いてある。
5部以降はお金の話や不動産の話が増えてきて、面白くはあるが真似をしようとは思わなかった。

結局、如何にしてby nameで頼られる存在になるかどうかというところが要訣かなという感じ。
それまでの道のりが解説されているので、これから成長していく技術者におすすめできそう。

この本で紹介されていたポモドーロ・テクニックとkanbanflowの組み合わせを試してみているが、なかなか良い。
ざっくり言うと、25分作業に集中し外界に影響されない環境を作る。5分休む。これを繰り返すだけである。

僕は作業にかかるまでが割りとダラダラ時間がかかり、一旦集中し始めると後は継続的に作業できるタイプである。
幸い、集中した後にそれを維持するのは既に身についているので、後は如何に手早く集中するかだ。
ポモドーロ・テクニックを使うと、集中状態にすぐに入りやすい。
なんせ、タイマーをスタートさせるだけだ。
あとは儀式の神聖さを守るために、真面目に作業しはじめるだけだ。
儀式を守るために、ポモドーロ・テクニックを使っている時はニコニコ動画などのコンテンツは使わず、Google Musicで高評価をつけた音楽のリストを再生するようにした。

kanbanflowを使うと1日あたりの作業量と、その推移が25分単位で把握できるので大変良い。
今まで作業のトラッキングはあまりやっていなかったので面白い。
DefinitelyTypedのpull requestの処理にかなりの時間が取られていることが(薄々わかってはいたが)明確になってきたので何らかの時短の工夫が必要かもしれない。

現在の課題。
npm installnpm run testなどの比較的待ち時間の長いタスクを実行した時に、如何に集中状態から離脱せずに済ませるかどうかが難しい。

Amazon