The King's Museum

ソフトウェアエンジニアのブログ。

第226回 TOEIC の結果

去年の12月に受験した TOEIC の結果が返ってきた。

Listening Reading Total
425 445 870

あわよくば 900 超えないかなーなんて思ってたけどそんなことはなかった。 パート2の問題文がまともに頭に入ってこなくて(理由は不明)、かなり適当にマークしてしまった割にはとれたかな。

これまでの TOEIC のスコア推移は次の通り。

受験日 Listening Reading Total
2017/12(今回) 425 445 870
2017/3 430 415 845
2016/3 350 400 750

細切れにしか勉強時間が確保できないから、勉強してる実感はあまりないけど、スコアはちゃんと伸びてきてる。 毎日、少しずつ、ってのは勉強の王道ですね(特に言語学習では)。

前回、845 取ったときは「これぜったい上振れでしょ…」と思ってたけど、今回は 850 を超えたわけで「TOEIC 850 〜」くらいの位置にはいるんだよね。 でも、これくらいのスコアが取れるようになってきて、スコア 900 レベルだと自分のイメージしていた「英語ができる姿」にぜんぜん届かないことが分かってきた。

2年前英語を勉強し始めた頃は「TOEIC は最終的に 900 超が目標かな〜」なんて思ってたが…。

数日前、「暴かれる王国 サウジアラビア」を字幕無しの英語音声で見たけど、

  • 完璧に意味が理解できた(文をリピート出来る): 0.5 割
  • なんとなく意味が理解できた(単語などから推測):2.5 割
  • 言ったことは耳に入った(気がする)が、意味が分からなかった: 3割
  • 何を言ってるのかまったく分からなかった: 4割

って感じで、ゴールの遠さにちょっと絶望した。

でもまあ、ポジティブな面を見れば、Reading に関してはかなりレベルアップした。そこらへんの Developer Guide 程度の文書なら苦労なくスラスラと読めるようになったし。ちょっと砕けたブログとかエッセーだと途端にすらすら読めなくなっちゃうけど…。

Towards over 950

ということもあって、900 点を目標にしていると自分のイメージするゴールに全然到達しないので、まずは目標再設定して 950 点を今年の目標にした。

一般的には Listening のスコアが高くなる傾向があるみたいだけど、自分は感覚的にもスコア的にも Reading の方が明らかに得意。Reading のスコアが高い人の方がスコアが伸びやすいと書いてある記事を目にしたので頑張れば今年中の 950 も夢じゃないかも?とハードルを高めにしてみた。

本当は今までやってきたこととか、今年やろうと思ってる英語ネタを書き連ねようと思ったけど、長くなったので一旦これで終わりにして時間があったらまた書きます。

Gauche の勉強を再開。

2 年前くらいに Gauche を勉強したいなーと思ったんだけど、いろいろあって途中でやめてしまってたのを再開した。

hjm333.hatenablog.com

Scheme は SICP を Streams くらいまではやったので、簡単なプログラミングクイズみたいなのは解けたりするけど、普段使いできるレベルじゃない感じ。

目標は、

  • 普段のちょっとしたスクリプトを Gauche で書けるようになる。

という実務的なところと、

  • Lambda 式は、「レキシカルな環境を保持した手続き」(クロージャ)へと評価される
  • 手続き呼び出しは継続を伴った引数つき goto である

と本に書かれていた意味を理解できるようになる、という興味的なところかな。 まあ、現時点でもひとつ目はなんとなく理解できるけど。

理由

言語を勉強する時って「Hoge を勉強する理由」みたいな話になりがちだけど、Scheme に関しては「単純に興味があるから」くらいしか理由はない。

ここ数年はキャリアに効きそうなことを重視して勉強していたけど、単純に興味あることに少しは時間を費やしてもいいかなーと思ったのもある。 プロゲーマーのウメハラが「最近、なんとなく昔使ってたキャラをメインに使い始めたら、なんとなく人生が楽しくなってきたんですよね。昔、ゲーム始めた頃に持ってた感覚というか、そーゆーのが戻ってきた。」みたいなこと言ってたのに少し影響を受けた。

別に俺は昔 Scheme 使ってたわけじゃないけど、学生の頃に Lisp ってできるハッカーが使いこなしてるイメージがあっていつか使いこなしたいなーと思って。自分の興味あることを勉強する単純な楽しさみたいなものがここにある気がする。

キーバインド

あと Emacs の Scheme 用のキーバインドをちゃんと使いながらコード書こうとしてるんだけど、ぜんぜんうまくできないのがそれはそれで結構楽しい。 身体と頭が一致しない感じは子供の頃にキーボードの配置覚えた頃を思い出させる。外側の S 式に行こうとして、キーを押したら内側の S 式いっちゃったり。四苦八苦。

でも、頑張って練習してると昨日よりちょっとうまくカーソル動かせたりするとこれが嬉しかったりするんだよなー。

2歳半になる息子が、毎日できないことにもがきながらもどんどん成長している姿を見て、歳をとってもそういう姿勢は持っておきたいなーと感じた。

Effective Java 3rd Edition

Effective Java の 3rd Edition がついに発売するようだ。

Effective Java (3rd Edition)

Effective Java (3rd Edition)

ここからなら EPUB で買えそう。(そうすれば Kindle で読める)

www.informit.com

また解説記事書こうかな。。。

2018年1月21日追記

Effective Java 3rd Edition のまとめを書き始めました。

www.thekingsmuseum.info

ISUCON 7 で予選敗退した

ISUCON というプログラミングコンテストに参加し予選敗退した(100位近辺でした)。

isucon.net

準備

予選の一ヶ月くらい前に、会社の同僚から「今度 ISUCON に参加しません?」という話があって、会社のメンバー三人で参加することにした。

準備として、

  • Go を読み書きできるように Go Tour をやった
  • 2~3日使って ISUCON 6 の予選を一人で解いてみた
  • 同僚と ISUCON 6 の予選を議論した
  • 当日のサーバーセットアップの準備(これは僕じゃなくて同僚がやったのだけど)

あたりをやった。

予選問題をやった感想としては、プログラムとかサーバー構成はかなり簡素だなぁと思った。 デフォルト実装はかなり荒い感じ。 だからこそ、高速化する余地あるということなんだろうけど。

ただ、競技時間8時間という時間制限はなかなかシビアだなぁと思った。

当日

予選は初日に参加。奥さんに子供の世話を頼んで、朝から会社に行った

気合い入れて 9:00 に会社に行ったら開始時間延期になって 12:00 開始の予定と言われ、暇を持て余してしまった。結局、さらに遅れて最終的に始まったのは 13:10 くらいかな。 (二日目も遅れたのはさすがに…)

競技開始直後は、3 台あるサーバーの設定を同僚にまかせて、コードを見つつ高速化ポイントを探す。

お題の Web アプリにブラウザからアクセスしてみるとアイコン画像のロードが明らかに遅い。 MySQL に画像データ入っていて毎回クエリで取り出してるようだ。それは遅いわ。

データをファイルにエクスポートし Nginx で裁くように変更。 ついでにサーバー設定も見直して 50000 点くらいになった。 ここで3時間くらい経過だったかな。

この時、ファイル名はデータの sha1 だからアイコン変更があってもキャッシュ破棄しなくていいですねーとかって話は出てたんだけど、実はうまく 304 が返ってなかったようだ。これをちゃんと 304 を返せるようになってれば高いスコアが出たらしい(検証してないから分からんけど

この後の次の一手がなかなか決まらなくて時間を浪費してしまった。 結局、「グローバルなキャッシュが欲しいよね」という話になって、急遽触ったことのない Redis を導入することに(サーバーが1台なら concurrent-map とか使うだけだけどね)。 「まぁ、Get と Set と Delete さえやっとけば大丈夫でしょ」みたいなノリでがりがり実装開始。

結局、導入したけどバグ取りに追われて気がつけば残り時間わずか。 残り10分くらいになって諦めかけたていたところ、奇跡的にバグの原因を見つける。

「これはまさか奇跡の逆転勝利ってやつかな?」と脳内で盛り上がったが、ベンチマークしてみたらスコアが下がって 40000 点くらいで FINISH でした。

よかったこと

目標は予選突破だったから「結果は出ませんでした」なんだけど、いくつかポジティブな面もあったかな。

「バグでスコア 0 点でした〜」ではなかったし、画像ファイルをエクスポートするところまでの流れは良かったと思う。

特に触ったことない Redis を導入するって決断ができたのも個人的にはよかった。 こういう思い切ったチャレンジを本番でやって、一応導入まで持っていけたっていうのは結構満足している。

こういったチャレンジがきっといつか身を結ぶのかなーなんて思ったり。

わるかったこと

二手目の Redis 導入が大した根拠なく進めてしまったのはよくなかった。

プロファイルをちゃんと見たり、スコアの計算方法を見直したり、やるべきことは沢山あった。 プロファイル用の Go ライブラリも調べてはいたけれど、今回のデフォルト実装で使ってたフレームワークと合わなくて導入を諦めてしまった。 もう少し時間を使ってでも導入するべきだったな。

スコアに反映されないのに無意味に /fetch を高速化してしまったりしたのは典型的なダメパターンなのでかなり反省した。

最後の方はさすがに疲れてしまって明らかに頭が働いてない感じがあった。 いい仕事をするためには疲労は大敵だなーというのは改めて感じた。体力やエネルギーはうまく使わないと…。

あと、開始時間のズレとかで一人参加できなくなってしまって二人だけでやるのはちょっと辛かった面があったかな。

おわりに

結局、技術的なことぜんぜん書いてないが Technical な面はちゃんと書かれたブログが他にたくさんありますからね・・・。

とりあえず、ちゃんと 304 が返ってるかはきちんと確認しようね、っていうのは大事だなと思いました。

45年間で東京23区の若年層人口が半減して、高齢者人口は3倍になったという話

IT と全然関係ない話。

たまーに「このニュースのこの数字は覚えておきたいなー」と思うことがあって、そういう時どうしようかなーと思ってたけど、ささっとブログに書いておくことにした(ブログ更新頻度維持のためにも)。

今回はこのニュース。

www.nli-research.co.jp

まとめると、

  1. 1970 年と比較して、2015 年における東京都区部の 15~29 歳の人口は 52.3% 減少
  2. 同じ条件で 65 歳以上の人口は 322.1% 増加
  3. 2016 年の東京都区部の人口増加のうち 33% は外国人。(20~24歳 の増加分に限っていえば 51.5% が外国人)

という話。

1 番目も 2 番目もそれなりにインパクトあるなぁ、と思ってたけど、3 番目は特に印象深い感じ。

確かに都内のコンビニやファストフード店のバイトの人ってほとんど外国人だもんね。

go build -gcflags '-N -l' とは何か

Go を触っててデバッグビルドしようと思って調べる。 いたるところで次のようにしろ出てくる。

go build -gcflags '-N -l' ...

で、この -gclags-N-l は何なのか。

-gcflags

コンパイルツールに渡す引数を指定できるフラグ

-gcflags 'arg list'

arguments to pass on each go tool compile invocation.

ref: go - The Go Programming Language

'-N -l'

それぞれの意味は次の通り。

  • -N: 最適化オフ
  • -l: インライン化オフ

-N

Disable optimizations.

-l

Disable inlining.

ref: compile - The Go Programming Language

『Androidを支える技術〈Ⅰ〉 ~ 60fps を達成するモダンな GUI システム』を読んで

『Androidを支える技術〈Ⅰ〉 ~ 60fps を達成するモダンな GUI システム』を読みました。

Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)

Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)

感想

単純にとても面白かったです。

昔、Web ブラウザのレンダリングエンジンをいじっていた頃があって、ちょっとだけそのときのことを思い出した。 ツリーがあって、それをレイアウトして、描画ライブラリに投げて、その先が GPU で、っていう一連の処理とか。(ブラウザだと DOM Tree と Render Tree が別だったりしたね)。 大して理解もしないままその世界から離れてしまったけども。

思い出話は置いておいて、この本の何がすごいかというと、

  • 上は View ツリーの話から、下はシステムコールの話まで書いてある
  • 豊富な図解と分かりやすい説明
  • 現実のコードをベースにした展開
  • 著者が中の人じゃない

というところ。

知識を文字にする時って、実際にアウトプットすることの数倍の知識が必要だと思う。 だから、この筆者はこの本に書かれた数倍の知識を持ってるんだよなーと思って、すごいなーと思った(小並感)。 というか、書籍にまとめるレベルになると10倍くらい必要かもね、、、

感心したところ

HWC と GPU 周りはとても感心して、とくに SurfaceView の仕組みはなるほどーと思った。

  • SurfaceView の View としての特性は「単に領域に穴をあける」だけ(下の描画結果を透過する)
  • アプリレイヤでは SurfaceView.getHolder().getSurface() で Surface が取得できる
    • Surface というのは gralloc() で確保したメモリ領域へのハンドラ。
    • gralloc() は端末ベンダーによって実装される。大抵は描画ハードウェア(GPU や HWC)に近いメモリに置かれる。
  • アプリレイヤで取得したこの Surface を、メディアコーデックに渡す。
    • 結果、コーデックチップが Surface が指す先のメモリに直接結果を書くことができる、
    • そすうれば CPU を使う必要がなくて電池も消費しないしハッピー。
    • さらにいうと、合成に HWC が使えるなら GPU も使わなくていい!

図にするとこんな感じ(本から引用) ^(1)

f:id:hjm333:20170905223646p:plain

うーん、仕組みもよくできているし説明もすごく分かりやすかった。 (gralloc とかなんだよって話だけど、それは本書を読んでください)

(1): 有野和真.『Androidを支える技術〈Ⅰ〉~ 60fps を達成するモダンな GUI システム』,技術評論社,2017.図 6.16(p.250).

得られたもの

この本を読むとなんとなく Android が理解できた気分になれる。

結局、得られるのは気分だけなんだよね。 当たり前だけど。 実際に自分でコードを追ってデバッグしてってやらないと本当に使える知識/技術にはならない(少なくとも自分にとってはね)

だけども、このなんとなく理解出来た気になるのはけっこう重要かなぁという気もしている。 どこかに誰かも書いていたけど、例えばクラッシュログを見ていて、

うーん、この ViewRootImpl.java ってシステム側だからなぁ、、、とりあえずクローズかな、、、

と思っていたのが

そういえば、ここらへん本に出てたし、ちょっと見てみるかな(キリッ

という根拠のない自信に変わったりする。

そう思ってコードを読んだところで、なかなか結果は変わらないんだけど(だって変化したのは気分だけだからね)、こういう姿勢の変化は結構重要だったりする。 めげずにコード読んでるとたまーに結果が出て幸せになれたり、そもそも実際に読んでみないことには知識も得られないままだからね。

Android に対して「まあ、ちょっとコード読んでみるか」というメンタリティが持てるようになったことが、この本を読んで得られた最大のポイントかな。 あとは普通に読んでて楽しかったです(2回目)

Vol. 2 も出ていて、話題的にはこちらの方が興味があるので読むのが楽しみー。

Androidを支える技術〈II〉──真のマルチタスクに挑んだモバイルOSの心臓部 (WEB+DB PRESS plus)

Androidを支える技術〈II〉──真のマルチタスクに挑んだモバイルOSの心臓部 (WEB+DB PRESS plus)

(c) The King's Museum