2017-09-28

砂場と模型

Mockの訳が模型でもいいかは自信ない(疑似だと味気なかった)。

プログラミングをしていると、テストをどうするかというので困る時がある。例えばあるコンポーネントのテストをしたいが、それはHTTPサーバを必要とする場合とか。実際に必要となるものによっては簡易版を用意してやるとか手はあるが、ユニットテストレベルでそこまでやる気にならないこともある。そもそも、用意した簡易版の何かしらは正しく動くのかとかも気になる。

Sagittariusではいろいろ黒魔術的な何かを使えばライブラリに束縛された値を上書きすることが可能ではある。っが、これをやるとグローバルに変更されるという問題もある。テストの実行単位が常に単一であるとか、単一スレッドでしか走らないとかにしてしまえばこれだけでも問題はないのだが、数が増えるとそれがボトルネックになるのが見えているのでできれば避けたい。

っと、この辺りまでが最近まで悶々としていた問題。もとになったのは、SchemeでもMockitoみたいなのほしいなぁというもの。そこから可搬性とか考えずに、とりあえず束縛だけ一時的に変更できればなんとかできなくね?というところに至る。っで、悶々としている間になんとかなりそうだなぁと思ったので実装してみた。実装の詳細は面白くもないだろうので割愛。(sagittarius sandbox)というライブラリに実装。使い方は以下:
(import (rnrs) (sagittarius sandbox))

(define s "b")
(define (test) (string-ref s 0))
(with-sandbox
  (lambda ()
    (define-in-sandbox '(rnrs) (string-ref s i) #\a)
    (test)))
;; => #\a

;; (test)
(playground ((string-ref '(rnrs) (lambda (s i) #\a)))
  (test))
;; => #\a
コメントアウトされてるtestのコメント外すと予定と違う値が返ってくるが、既知のバグということで。理由としてはサンドボックス内で作られる束縛は指定されたライブラリのみ作用するけど、上記のtestで使われてるstring-ref(rnrs)が依存しているライブラリの一つで定義されてるので、一回サンドボックス外で実行するとGLOCに置き換わって定義されてるライブラリを直で見に行くから。VM内でGLOCに置き換える部分をもう一段ラップして元の識別子を残すようにすれば解決できるんだけど、性能への影響が怖いのとそこまで需要があるかなぁという気持ちが混じりあってとりあえず保留。性能に影響がでないうまい方法を思いついたらやることにする。

サンドボックスができれば次はモックだということでちゃちゃっと作った。以下のように使える。
(import (rnrs) (srfi :1) (sagittarius mock))

(define (test) (make-list 3 #f))
(let ((status (mock-up ((srfi :1)) 
                (test) (mock-status-of 'make-list))))
  (mock-status-arguments-list status))
;; => ((3 #f))

(mock-up ((srfi :1)) 
  (mock-it '(srfi :1) (make-list . args) '(a a))
  (make-list 3 #f))
;; => (a a)
まだAPIが荒いのでもう少し練らないととは思いつつ、テストに使えそうな感じではある。実装に綺麗い目な黒魔術(絶対にドキュメント化されないという意味で)を多用しているのは、まぁご愛敬ということで。

2017-08-21

浮動小数点とC99とSRFI-144と

Sagittarius 0.8.6でSRFI-144をサポートした。このSRFIをポータブル実装を使ってサポートするとパフォーマンス的に得るものが何もないと思いC側でサポートすることあらかじめ決めていた。ネックになるのはこのSRFIが要求しているのがC99の数学関数であることで、Sagittariusでサポートを明記しているVS2010ではC99がサポートされていない。VS2013からはサポートされているので、4年も前の環境だし上げてもいいかなぁとは思ったが、何かの間違いでこのバージョンを使っている人がソースからコンパイルしているという可能性も0ではないかなぁと思い互換レイヤを書くことにした。

互換レイヤ自体はまぁ、普通の苦労で済んだのだが、そこから先が大変だった。Ubuntu 16.04では動くがTravis上のUbuntu 12.04ではテストがこけるとか、VS2013でのCランタイムではテストがこけるとか完全に環境依存の問題に移行したのである。ちなみに嵌ったのは以下:
  • VS2013以降のtgammaはアンダーフローが起きると0.0を返すが、Linux(glibc)では-0.0が返る(たぶんどっちも仕様上はOK)
  • VS2013以降のynは第二引数が0.0だとNaNを返すが、Linux(glibc)では-inf.0が返る(POSIX見ると第二引数が0.0だとpole errorで-HUGE_VALとあるが、C99が同義かはしらない)
  • glibcの特定のバージョン(2.21以下と思われる)ではremquoとlogbが不正な値を返すことがある。(remquoについてはバグレポートを見つけたが、logbは完全に勘。下手するとeglibc固有の問題化もしれない)
  • fl-leastはDBL_TRUE_MIN(C11)が割り当てられるので、どのバージョンのVSがサポートしてるか不明
とにかく環境がないということの方が辛く、おとなしくポータブル実装を使っておけばよかったという気持ちに何度もさせられた。また、参照実装に付属しているテストが要求する誤差が結構厳しく、適当な実装だと誤差が大きすぎるというのも苦労した(Windows)。

苦労の甲斐があるかはわからないが、Sagittarius上で浮動小数点を扱う際はこのSRFIを使うとCと同等の速度が得られることだけは保証されるようになった。っが、個人的に浮動小数点はあまり使わないので、自分では有難みを享受できないという悲しい話もあったりなかったりする。

2017-07-12

オランダでの収入と支出

ITエンジニアと給料では給料だけにしか触れなかったが、この記事によるとアメリカの一部地域(例:シリコンバレー)では生活コストも高いので世帯年収1200万以下は貧民層となるらしい。生活コストも含めた比較となるとオランダくらいしかできないので、ざっくりとオランダでの生活コストを調べてみた。

生活コスト
日用品等のコストは「Cost of Living in Netherlands」のページが詳しい。基本的には食品はそれなりに安く、家賃は高いという感じらしい。
ざっくりとしたコストとしては「What is the average cost of living in The Netherlands」のページに書いてある。以下は適当な日本語訳したリスト
  • 家賃: €800-1000
  • 電気、水道等: €150
  • インターネット(大抵テレビと電話もついてくる):€30−50
  • 健康保険:€270(3x90 18歳以下の子供は無料)
  • その他保険: €30
  • 交通費: €100
  • 食費:€100週 (€400月)
合わせると€1780−2000くらい。これに交際費等が入ってくるが、感覚的に妥当な数字かもう少しかかるかなぁというところ(上記だと最低限くらいしかない感じ)。

収入
2016年における一人あたりの手取りの平均収入は€2158となっている(参考: Average Salary in European Union 2016)。平均世帯収入は単純に2倍すればいいだろうか?

以下は2017年の額面における手取り額(日本語ただしいか?)
月収(額面)月収(手取り)年収額面
2000169525920
3000222838880
4000273651840
5000324464800
6000372677760
7000417090720
80004614103680
90005058116640
100005502129600
参考:Dutch Income Tax Calculator
年収の算出は月収x12.96になっている(注:オランダでは月8%の休暇手当が義務付けられている)。もちろんボーナスのでる会社もあるので、この年収は月収に対しての最低保証額ということになる。

€2000(上記の生活コスト)+€1000(ある程度の交際費と貯金)くらいを文化的な生活とすると、世帯収入的には年€50000くらいあれば「中の中」くらいだろうか?累進課税がキツ目なので、収入が一人だと年€61000くらいないと厳しい感じである。

現在位置ユーロ130円なので、世帯収入650万円(一人なら793万円)で「中の中」くらいの生活ができるとすれば、アメリカの1200万円で「中の下」と比べるとましなのかね?ただ、年収€61000を新卒(エントリーレベル)で出す会社は今のところオランダでは見たことないので(というか、これくらいだと既にシニアレベル)、やはり給与面ではオランダはアメリカに比べると塩っぱい気がする。少なくともIT産業に於いては。

2017-07-03

引っ越し

7年住んだアパートからの引っ越しが完了した。新居の準備がまだ全部終わっていないが(床のフローリングが一部終了してない等)今週中には終わるだろう。7年も住んでいると普段は気にしなくてもこういう時に物であふれていたんだなぁと気付かされた。引越し業者が荷物の運び出しを完了した後で10箱以上自力で運びだしたりしていた(箱詰めが失敗したとも言えなくないが、細々したものというのは往々にして忘れられがちなのだ)。

オランダのアパートは入る時も出るときも割と面倒である。入るときはだいたい床はコンクリートむき出しの状態、壁紙はあったりなかったり。出るときは以下の状態にして出ろと言われる:
  • 床はコンクリートむき出し
  • 壁は白く塗ってあること
  • 天井も白く塗ってあること
  • 壁に開けた穴は埋めること
まぁ、入った時と同じにしろと言われる。ただ、僕の場合は多少特殊で、入った時は「天井が白ければよい」という条件だったんだけど、途中で大家が変わったので「壁も白くしろ」が追加された。なので、受け取った時は青い壁とか、トイレに模様とかあったんだけど、それらを全て白く塗りつぶせという話になった。納得が行かないが、まぁしょうがない。

偶然にも、新しい居住者が入れ替わりで入ることになりかつその人がフローリング、冷蔵庫、洗濯機、オーブン、ベッドフレームを引き取ると言ったのでそれらの運び出し及び廃棄をする必要がなくなったのは幸運だったのだろう。その人にとってもそれらが無料で手に入るのは悪くない条件だと思う。多少汚れてたりしても…(余談だが、フローリングはアパートが広いこともあって総額で2000ユーロ以上かかってたりする。)

新居の鍵の受け渡しから退去までが一週間しかなく、その間に荷出しとかもあったので、非常に疲れる週であった。連日23時くらいまで運び出しと清掃等を行っていたのだが、22時くらいまでは明るいという非常に幸運な時期に引っ越ししたとも言える。これが冬だったら暗闇の中いろいろやることになっていた。

どうでもいいのだが、敷金が帰ってくるまでに2ヶ月かかるってどういうことなんだろう?どう考えても時間かけ過ぎだと思うだが?

2017-06-20

Kotlin 始めました

2週間前にこんなツイートをした。


このツイートの後えらくだるだるなスプリントを過ごしたので(1スプリント=2週間)、しばらく触っていなかったのだが、今週のプランニングでメンバーから陽に「お前はKotlin使うよな?」と煽られたのでまじめに使い始めた。

書き始めて今日で4日目くらいだけど、Javaと比較してみたりする

【長所】
  • 記述量が減る。無駄なゲッターとかセッター要らない
  • デフォルトでLambda式が使える。(Java8な環境なら関係ないけど)
  • 型推論は良いものだ
  • クラスを別ファイルにしなくてもよいのは便利
  • パッケージ定数とかも便利
  • Javaとの親和性が高い
【短所】
  • 重い。IntelliJが頻繁に固まる
  • Mavenの記述が面倒
  • 素ではMockitoとの相性が悪い(mockito_kotlinで凌ぐ)
  • Javaとの親和性が高いけど、ところどころコンパイル結果を気にする必要がある。(慣れかな)
  • inlineの挙動。混乱するだろ普通…
  • データクラスあるけど、パターンマッチない
  • デフォルトpublic。デフォルトfinalクラス。(好みの問題) 
  • Companionは面倒
Null安全は便利だけど、猫も杓子もNull安全という風潮はだいぶ疑問。まだ使ってない機能がいくつかあるけど、使う時が来たら使う感じかなぁ(Type safe buildersとか使いたいけど、使う場面があんまりないんだよなぁ…)

感想としてはJava++として使うのであれば優秀。 Kotlin的な書き方(チュートリアルにあるようなのだと信じてる)をすれば記述量がだいぶ減る(でもIntelliJが固まるので作業時間的にはトントンというのもある…)。なんだかんだで既存のJavaライブラリがそのまま使えるのはやはりうれしい。

リストとかマップとかのリテラル表記とかあったら便利だろうなぁとか、パターンマッチほしいなぁとか、なんで明示的にreturn書くんだろうとかいろいろ思うけど、今のところはJavaより楽に書けるというメリットの方が大きい感じではある。

2017-06-16

ITエンジニアと給料

Twitterで米国で働くといい給料がもらえる云々の呟きを見た。米国におけるITエンジニアの給料が破格に高いのはまぁ周知の事実として、正確にどれくらいの差があるのかというのはあんまり考えたことがなかった。以前Amazonからもらったオファーは米国なら13万ドル、ルクセンブルグなら7万6千ユーロだったので、単純に2倍弱くらい離れてるのかなぁと思っていた。(正直どうして蹴ってしまったんだと今でもたまに悔やむが、トランプ政権とか見ると行かなくて正解だったのかなぁとも思っている。)

例が一つというものどうかなぁと思ったので、欧州と米国の関数型言語求人に特化したサイトを覗いてちょっと比較してみた(ずいぶん前に登録してた)。
LevelUSEU
Senior$150k-200k€60-75k
Full stack$100k-150k£45k - £60k
Junior$120k£35k - £45k
フルスタックがシニア以下とか、通貨が違うとかはまぁ置いておいて、ぱっと見2倍以上の差はあるのかなぁと。(米国のジュニアはプログラマではないので微妙)。

上記のEUはドイツか英国なんだけど、英国は一応最大で£120kの募集要項もあったので、探せばなくはないかなぁ。

ザクッと要求するスキルを見るとだいたい同レベルのことを求めているので、やれることが同じなら米国の方が2倍くらい給料がいいということにはなる。

物価とか保険とか税金とかどれくらい生活コストがかかるのかは知らないけど、単純に見れば英語ができてチャンスがあるのであれば現状欧州出て米国に行った方がよい給料がもらえる。個人的に気になるのは、欧州はいくらか世界規模のサービス展開している企業があるのに(僕の前職もそう)給与水準は低く抑えられているという点と、ITエンジニアはかなりの奪い合いなんだけどそれに見合った報酬という感じはしないところかな。前にも書いた気がするけど、ヘッドハンターに現状より年間で5千ユーロは高くないと嫌だというと説教食らうところとか(これはオランダだけかもしれんけど)。

いろいろ書いたけど、欧州もそれなりにしょっぱい感じです。オランダ限定なら間違いなくしょっぱいです。

2017-05-19

ちょっとしたジレンマ

仕事でスクラムをやっているのだが、Grooming(最近だとRefinement)、Wikipediaの日本語ページに訳がなかったので英語のままで書くことにする、に微妙に温度差があって多少困っている。
ちなみに、スクラムのプロセスについて書くということはないので、その辺を期待しているのであれば期待はずれになると思われる。

チームでは最近縦のスライスを意識してやることにしている。そうするとどうしても最初はプロトタイプ的なものがチケットになる。このプロトタイプが結構曲者で、今のチームは横のスライスを意識してやってきた経験が長いので、プロトタイプで必要になるコンポーネントがどれくらいに複雑になるかがある程度見えてしまう。というか、開発者であれば、経験上最終的に一つのコンポーネントがどれくらいの機能が必要かが見えるので、それを考慮に入れてしまう感じである。あまりうまく例えられないのだが、レゴで城を作ればいいのに、実際のレンガで城を作ることを考える感じだろうか?

例えば簡単なSMS認証のWebサービスを作るとする。以下がチケットの詳細とAcceptance Criteria(これの訳も知らない):
詳細
ユーザからの携帯番号を受け取り、認証コードを受け取った携帯に送る。ユーザーにリクエストIDとステータスを返す。ユーザーはSMSで送られた認証コードとリクエストIDをサーバに送る。認証コードが一致すればリクエストIDと成功を返す。一致しなければリクエストIDと不一致を返す。なおUIは考えなくてもよい。

Acceptance Criteria
  • SMSを送るには以下のAPIを使う(3rdパーティーAPI)
  • リクエストはデータベースに保存する
  • デモ可能である
後はテスト項目があるけど、それは割愛。

僕はこれに対してPoC(Proof of Concept)でありかつ次のスプリントで改善して行けばいいということを念頭に最短かつ最も単純にやるという方針で5ポイントをつけた。実際JEE開発したことがある人であれば、使うフレームワークにもよるだろうが、この程度1周間もあればできると思うだろう。(ストーリポイントを時間で図るのはいかがかとは思うが、個人的には便利かなぁと思うので一週間=5ポイントにしている。)想定した工程は以下
  • 2つテーブルを作る
  • 3rdパーティAPI用ライブラリを作る
  • REST APIを2つ作る
  • ざっくばらんなMaven処理(モジュール作成等)
フルスクラッチなので、コードの記述量は多いがそれ以外は特に複雑なものはないと判断した。

っが、他のメンバーは13ポイントをつけた。ちなみに今のチームでは13ポイントは1スプリント(ちなみに今のチームでは1スプリント=2週間)ではできないとしている。その理由は:
  • テーブルデザインがいる
  • 3rdパーティAPI用ライブラリのデザインがいる
  • REST APIのデザインと他チームとの強調がいる
  • デプロイ用のサーバ等環境構築
完全にリファクタリングによる手戻りを極力減らそうという感じであった。そうすると確かにきちんとしたデザインとかあるし、それらには時間がかかるのも判る。っが、PoCでやることではない気がとも。あるメンバーはどう考えても1スプリントではできないと言い張ったし…

結局間をとって8ポイントにした。言い出しっぺの法則的に僕がやるということになったが、実際に完了までに1週間(うち1日は病欠したので、正味4日)。自分のスキルレベルをよく把握してるなぁと感心するレベルでの見積もりの正確さであった。

何がジレンマかというか
  1. 見積もりに大幅な開きがある
  2. 他のメンバーは城をレンガで建てようとする(必要以上にかっちり作りたがる)
の2つである。正直どうすればいいのかよく分からない…