検察審査員になっていた
去年の 11 月から 4 月まで検察審査員をしていた。以下、時系列で振り返る。
検察審査員に選ばれるまで
裁判所から分厚い封筒が届く。年金未納時の赤い封筒を思い出した。検察審査員の候補者になったことが書いてあった。
この封筒は 100 人に配られる。そこからさらに絞られ、11 人が審査員になる。
なので確率は 11 % かと思いきや、もっとずっと高い。70 歳以上は辞退が多いから。
(検察審査会制度Q&A > 検察審査員を辞退できる場合はあるのですか。)
もちろん 70 歳以上じゃなくても辞退の申し出はできる。
(検察審査会制度Q&A > 検察審査員(補充員含む)の負担が過重なものにならないよう，具体的にどのような措置が講じられているのですか。)
裁判員制度で現場の写真を見て急性ストレス障害になったという事例が過去にあったようで、自分も同じ場面に居合わせたらそうならない自信がなかった。小さい頃に鶏を絞める映像を見て卵料理が数年間食べられなかったことがあった。
実際にそのような事件を担当することはなかったし、そのような事件はそもそも検察審査会に回されなさそうだった。万一回ってきたとしても、事前に事務局の方にその旨伝えておけば、そのような事件を扱う日だけ欠席にしてもらうなど考慮してくれそうだった。
目を細めて見れば耐えられるかもと思ったことや、さすがに 11 人の中には選ばれないだろうと思っていたこともあり、辞退はしなかった。
審査員に選ばれた時
封筒を受け取ってから何ヶ月も経過して油断していたため動揺した。書面でのやりとりのみだったため現実感もなかった。
勤怠をどうすべきか会社に聞いたら有給の公民権行使等休暇ができた。有給か無給かは各企業の判断に委ねられるようで、すんなりと有給になってありがたかった。
審査初日から前期終わりまで (11月-1月)
検察審査員の日常がストーリー仕立てになっている DVD を見る。DVD が年代物なせいか何度か映像が止まって音だけ流れたりして緊張感があった。
その後前期(第3郡)の方たちと合流した。 (検察審査会制度Q&A > 検察審査員の任期はどれくらいですか。)
自己紹介の時間になった。第3郡の方たちは前の方の内容に被せていい感じの一言二言を交えた話をしていたが、自分は名前しか話せなかった。
自己紹介が終わり、その日は事件の摘録を読んで終わった。
その後は月に 1-2 回程度出席し、そのたびに摘録を読み、意見交換をし、議決をしていった。
事件の内容を書けなくて残念だけれど、一つ一つが考えさせられるものだった。
前期最後の審査会の日はスケジュールを勘違いしていて、午前中から外出してしまった。事務局長から電話が来て勘違いに気づいた。午後からでも間に合うなら出席してほしい旨伝えられたが、その後審査員が集まったようでその日は欠席でよくなった。
その後さらに電話が来て会長やりませんか？と言われた。当時は知らなかったが、その日は次期会長を決める日でもあった。やりたい人が他にいないのであれば全然いいですよというようなことを言った。
後期 (2月-4月)
会長になった。審査会を良くも悪くもできる存在になってしまった。審査会には皆がわざわざ時間を割いて来ているので、今日も来てよかったと思うようなものにしたかった。
それには意見交換の時間の改善が必要と思った。改善案を事前に事務局に伝えたら反対されそう(事務局の立場的に)と思ったため、当日その場その場で事務局と審査員にやり方を説明しながらやっていった。
以前の意見交換の流れを書いておく。
- 席ごとにマイクがおかれ、話す前にマイクのスイッチを ON にし、話し終わったら OFF にする。
- 席順に一人 1-3 分程度話して話しの最後には結論を言う。
- 例: "A, B の理由から{不起訴{相当,不当},起訴相当}だと思います"
これは自分から見て以下のような問題があった。
- 会話しづらい
- 結論を話し終わるまでは話の途中のため意見を挟みづらい。
- 結論を話し終わった後はその人の中で結論が出てしまっているため特に反対意見が言いづらい。
- 同調圧力がかかりやすい
- 例えば不起訴相当の結論が続くと他の結論が言いづらい。
- やがて『同調圧力によって決まった結論』に合う理由を探す作業になっていってしまうようになる。
- 具体的には "A, B の理由から不起訴相当だと思います" の A, B を摘録から探す作業になってしまう。
- 席順が後になるにつれて無力感が強まりやすい
- 席順が後になるにつれて結論も理由も言い尽くされていて話すことがなくなってしまう。
- やがて席順が後と判明した時点で資料を読むモチベーションが下がっていってしまうようになる。
- その場で席順が前の方々の意見をまとめれば形になってしまうため。
これらの問題を解決したかった。
会話しやすくするため、おもむろに部屋の中央に椅子を並べ始めた。議決でしか使わなかったホワイトボードも中央に持ってきた。さあみなさん近くに集まって、事件についてもっと気軽に話をしましょうと人を集めようとしたが、審査員の方から (COVID-19 が流行っている) このようなご時世にそのように集まるのは間違っているという強い意見があった。
結局私一人が中央にいる状態になったが、それだけでも話す方の目線が変わった。今までは基本的にはマイクの方を向いて時折横目でこちらの部屋奥の議長席を見るという感じだったのが、マイクは使いつつもまっすぐこちらを見続けるようになった。
その状態でランダムに指名していくというのをやった。iPhone アプリでサイコロを振って出た目と席順が一致する人に、今回の事件に関係することでもそうでないことでも何でもよいので自由に話してもらった。想像以上に自由に、活き活きと、楽しそうに、自身の境遇や内心思っていることなど赤裸々に語られた。自由すぎて事務局が困っていた。全体の雰囲気はすごくよくなった。
そんなことを確か 45 分間行った。
その後、意見交換の時間になった。『不起訴相当だと思いますというような結論は言わないでください』と念押しして始めた。同調圧力がかなり減ったし、発言量も増えた。『あれってどうしてなんでしたっけ？』というような質問の時間も増えた。発言者は先程同様 iPhone アプリのサイコロを使ってランダムに指名していった。
そんな感じで初日は閉会した。他の審査員の方々の協力があってなんとかうまくいった気がする。仕組みだけ変えても参加者の協力が得られなかったら変わらなかった。
閉会後には事務局長と書類仕事を片付けつつ次の会の話をする時間があるが、その際に以下のようなことを教えてもらった。
- 今はコロナということもあってあの形式になってしまって、他の審査会でも同じような悩みを抱えているところは多いこと。
- 過去の期で意見交換のパターンについて、議長が最初に話すパターンや、議長が思いつきで指名するパターン、何もしなくても意見が飛び交いまくるパターン等あったこと。
- 結論を話すようには言ってないけれど皆結論を話してしまって実はモヤモヤしていたこと。
そんな感じの日々を過ごしていた。
おわりに
他の審査員の方々、事務局の方々には大変お世話になりました。良い思い出ができました。
当時の事務局長には特にお世話になりました。ありがとうございました。
Shinjuku.rs #7 に行ってきた
RustのLT会 Shinjuku.rs #7 @FORCIA に行ってきました。会場は新宿駅直結ミライナタワー。都心に久しぶりに行きましたが人や建物が多いせいか暖かくて秋かなって感じですね。立川に戻ったらぐっと寒くてすぐに耳が痛くなりました。
Rustを業務に導入した話
Rust を導入する際に『Rust は書けないけど読める』というメンバーを増やしておくことでビジネスロジックの部分だけでもコードレビューをしてもらえるようにしておくと捗る。なぜかというと、Rust はコンパイルが通っていればたいてい動くため、ビジネスロジックがちゃんとしてそうかだけを見てもらえれば十分という感じのことをお話されていました。たしかになるほどという感じです。
あとは Rust を導入してみてユニットテストが非常に書きやすかったとのことでした。実装コードと同じファイル内の一番下に tests module を定義してテストを書いていって $ cargo test でシュッと実行できるやつ。境界値のテストを書くぐらいがちょうどよかったとのことで、確かに Rust だったらそれで十分そうな気がしました。
RustでSpotifyクライアントを作った話
Spotify の API ( https://developer.spotify.com/documentation/web-api/reference/ ) はいろいろな Platform 向けに提供されていて内容もかなり豊富でアプリでできることならたいていできるとのこと。
作るにあたって以下のようなライブラリを使ったとのこと。
- https://github.com/fdehau/tui-rs
- https://github.com/redox-os/termion
- https://github.com/ramsayleung/rspotify
- https://github.com/crossbeam-rs/crossbeam
アプリのデモをされていましたが、なんというか Vim っぽくてすごく好みでした。音楽はあまり聞きませんが聞くんだったらターミナル経由で操作したいなという気持ちになりました。
コードは https://github.com/togatoga/spoterm
HOGWILD!
難しかった。。とりあえず読み方はホグワイルド。
Rust の場合、Unsafe を使ったとしても Unsafe な部分とそうでない部分が視覚的にわかるのがよいというのを聞いてたしかにそうなりそうと思いました。
https://github.com/rayon-rs/rayon を使ったとのこと。さっき似たようなライブラリで https://github.com/crossbeam-rs/crossbeam が出てきたけれど、rayon は crossbeam-deque に依存しているのね。
RustのWebアプリケーションの計測とチューニング
- https://github.com/fcsonline/drill
- https://github.com/llogiq/flame
flame::startとflame::endで囲った部分や、flame::span_of("foo", || bar())で指定した処理、flame::start_guardを含むブロックを測ったりできる。
「Go言語でつくるインタプリタ」を Rust で移植してみた
Youtube 版は以下。
「Go言語でつくるインタプリタ」は以下。
しんどかったところをどれも解決には持っていっていてすごいと思いました。
Rc や RefCell、わりと見かけるので使いこなせるようになっておきたい。
あと https://github.com/kei-s/waiir/commits/master のようにコミットの本文に日記を書くというの、振り返った時に楽しそう。
cargo makeについて
Cargo makeを使ってみた話 from emakryo
www.slideshare.net
cargo-make (https://github.com/sagiegurari/cargo-make) 、Makefile が TOML で書けて、Predefined tasks も充実していて ( https://github.com/sagiegurari/cargo-make/blob/8a9639e6fa24d2c0ae40c47ffb39b7c2b7a36ac0/src/lib/Makefile.stable.toml これかな？) CI 流す際などに便利に使えるとのことで、さっそく使っていきたい気持ちになりました。
ハマりどころもいくつか紹介されていて、たしかにこれはハマりそうという感じ。先にわかっておけるのありがたい。
Rust.Tokyo 2019 に行ってきた
いやー熱かった！！
『つよつよな人たちばかりなんだろうな・・他に知り合いもいないし・・場違いかな・・』
と当日まで弱気だったけれど、結果ものすごく楽しかった。昼は勇気が出ず一人でラーメンを食べたけど・・。(ラーメンの完成度がすごく高かった。さすが東京。)
行ってみてわかったのは、やっぱりみんな lifetime につまづくよねということ。自分だけじゃなかった。
『Lifetimes: A Survival Guide』の回では Eric Findlay さんが lifetime について熱く語っていた。質疑応答も白熱していた。懇親会でも lifetime の話は盛り上がった。ちなみに自分も過去つまづいて以下の記事を書いたりした。
ライフタイム熟知したい。。
オープニングトークではエラーの変遷の歴史などが語られていた。
標準の error → error-chain → failure という流れだったが、標準の error が使いにくいのはどうなの？となり https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md で直していくぞ！となりつつも failure 側も 1.0 にしていくぞ！というような流れだったとか。(間違っているかも)
自分は最初から failure を使っていて error と error-chain の存在を知らなかったためなるほどと思った。
qnighy さんの発表でも Error について言及されていて、
何やら Trait 派や private enum 派、public enum 派がいるらしい。
あとは https://github.com/gothinkster/realworld などが紹介されていたり、( Rocket のサンプルを見つけた: https://github.com/TatriX/realworld-rust-rocket )
Rust Async + Romio + juliex の組み合わせ、公式チームなる存在を知ったり、
gRPC 実装として https://github.com/hyperium/tonic が紹介されていたり、(懇親会では https://github.com/tower-rs/tower-grpc を使っているという方がいた。) GraphQL 実装として https://github.com/graphql-rust/juniper が紹介されていたり。
Rust で安全に実装するための心得
パフォーマンス向上のためにリソースの開放を遅らせることがあるとのことで、もしかしたら秘密鍵とかパスワードとか乱数などのセンシティブなデータがメモリ上に残っているかも知れない、Heartbleed 怖い、防ぎたい、そんな時には Zeroize があるよ。というような話だったり、
Timing leaks という応答時間の差でパスワードを探っていくやつには https://github.com/dalek-cryptography/subtle で対策できるという話だったり、
Integer Overflow に関しては普通に $ cargo run すると検知してくれるが、--release で実行した時には検知しないので wrapping_* 系など使いましょう(そんなことは言っていなかったかも)という話だったり、
Fuzzing の話だったり。https://github.com/rust-fuzz/cargo-fuzz や https://github.com/rust-fuzz/honggfuzz-rs が紹介されていた。cargo-fuzz がよく使われているとのこと。そういえば LT で Linda_pp さんが fuzzing を実演していた。(ご本人を初めて拝見した。ひょっとしたら本当に犬かもしれないと思っていた。v への alias に親近感を感じた。)
あとは https://github.com/rust-lang/rust-clippy では warning を出してくれたり、 https://github.com/RustSec/cargo-audit では Cargo.lock のチェックをしてくれるらしい。RustSec のデータベースを参照しているとか。 https://github.com/crev-dev/cargo-crev/ なども紹介されていた。
Web-based Data Visualization with Rust and WebAssembly
wasm については最近 yewstack/yew を触っていて『なんだかよくわからないけど $ cargo web start すると wasm というやつが動くぞ』程度の認識だったけれど wasm32-unknown-unknown や wasm-bindgen, https://github.com/rustwasm/create-wasm-app や https://github.com/rustwasm/wasm-pack など wasm 周辺のツールが紹介されていて非常にためになった。
wasm の良い点やいまいちな点も大変参考になった。Rust と JS との間の行き来が頻繁になると Rust のメモリにのっける手間の分いまいちというお話だったり、良い点として SIMD を挙げていたり。昨今 CPU の FLOPS は伸びていて JS だと CPU パワーのごく一部しか使えないけれど wasm なら 128bit の SIMD をサポートしていたり Intel の良いやつの 512 bit も将来的にサポートするだとかで (SIMD がいまいち何だかわかっていないですが..) 明るい未来が待っていそうな感じ。
まとめ
スタッフ、スピーカー、参加者のみなさま、こんなに楽しい機会をどうもありがとうございました。Rust がますます好きになりました。本当におつかれさまでした。
AWSへの苦手意識をなくしたくてQwiklabsに課金していた
最近 Qwiklabs に課金している。
Qwiklabs は『AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト』で知った。
Qwiklabs 自体がどういうものかについてはやってみるのが早くて、例えば DynamoDB の紹介用ラボ『Introduction to Amazon DynamoDB | Qwiklabs』とかは無料で、「ラボを開始」をクリックすればすぐ試せる。
利用する AWS アカウントは Qwiklabs がラボごとに都度払い出してくれるのでそれを使う。
値段は 1 ヶ月使い放題で $55。都度払いする方法もあるけどコスパが悪い。都度払いというのは事前に購入したクレジットをラボを起動するたびに払う方法で、1 クレジット当たり大体 $1。ラボによっては起動するのに 24 クレジット必要だったりする。一度受けたラボであっても起動のたびにクレジットは必要。
概要はそんな感じで、Qwiklabs の良いところを紹介すると
- AWS 破産がない。
- まあ破産はないとしても、うっかり何かを消し忘れたとかで知らない内に課金されてるとかの心配がなくなるのは嬉しい。眠いけどリソース削除しとかなきゃとかから開放される。
- How が身に付く。
- 上に挙げた本だけじゃ What と Why は身に付くけど How が抜け落ちてるので肝心の AWS への苦手意識はなくならない。
- 英語のラボであっても『日本語に翻訳』すれば普通に読める。
- シンプルな文章で書かれているため翻訳しても自然な文章になる。
- たまに変に訳されてしまって
20GiBが20ジブになったりStringがひもになったりするけど、注意深くいれば大丈夫。
- Quest が達成欲を掻き立てる。
- 紐づくラボを全部やるとバッヂが貰える仕組み。
- 参考: Serverless Design with AWS Lambda | Qwiklabs
- ちょっとでも面白そうな Quest を見つけたら登録しておく。後は勝手にやる気が出る。
- ラボの検索が便利。
- 無料なら → https://amazon.qwiklabs.com/catalog?price=free
- Quest で絞りたいなら → https://amazon.qwiklabs.com/catalog?format=quests
- 初級者向けなら → https://amazon.qwiklabs.com/catalog?level=1
逆に Qwiklabs の微妙なところは・・
- 先に進めなくなることが稀にある。
- 例えば・・
- 『アクセスキーはラボのページに張り出されたものを使ってください』と記載があるのに実際には張り出されてなかったり。
- ならばと自分でアクセスキーを発行しようにも権限不足でできなかったり。
- 『他の項目はデフォルトのままにしておいてください』と記載があるが、ラボが書かれた当時とデフォルト値が変わっていたり。
- 『アクセスキーはラボのページに張り出されたものを使ってください』と記載があるのに実際には張り出されてなかったり。
- 例えば・・
- メールがうっとうしい。
- ラボをやるたびに『おめでとうございます！完了スコアは、100.0% です。』メールが届く。
- ラボを起動してすぐキャンセルしても完了スコアが 100% で謎。
そんな感じ。総じて良い。
覚えてるラボの中で、以下は特に面白かった。
- Building Your First Amazon Virtual Private Cloud (VPC)（日本語版） | Qwiklabs
- VPC のラボ。ネットワーク関連は今まで手薄だったためかなり自分に刺さった。
- Challenge Lab | Qwiklabs
- これも VPC のラボだけど、これは珍しく採点方式になっている。自分の理解度のチェックになってよかった。
- Build a Serverless Text-to-Speech Application with Amazon Polly | Qwiklabs
そういえばラボをやっていて PEM ファイルで EC2 にログインさせられることが多くて、.zshrc に以下のような function を定義した。
function qwiklabs_login_with_path_and_ip() {
dst="/tmp/$(basename $1)"
mv $1 $dst
chmod 400 $dst
ssh -i $dst ec2-user@$2
}
使い方は $ qwiklabs_login_with_path_and_ip ~/Downloads/qwikLABS-A123-4567890.pem 198.51.100.1 のような感じ。使った PEM ファイルは /tmp/ 以下に移動してくれるのでラボごとに発行される PEM ファイルで ~/Downloads/ が溢れなくなるとかそんな良さがある。
あとは便利系だと cVim ( cVim - Chrome ウェブストア ) の設定で以下のような定義をした。
openServicesMenu -> {{
document.getElementById("nav-servicesMenu").click();
}}
site 'https://*.?console.aws.amazon.com/*/*' {
map t :call openServicesMenu<CR>
}
t で AWS コンソールのナビゲーションバーの「サービス」ドロップダウンを開閉してくれるやつ。例えば今 EC2 のページにいて t でドロップダウン開いて s3 とか入力して Cmd+Enter で別タブで S3 開くとかできて個人的にはかなりライフチェンジングだった。
ICL手術をして1日が経った
2019/06/04(火) に ICL 手術を受けてきました。結果は成功で、視力は 0.03 から手術翌日には 1.5 弱になりました。
ICL 手術を受けたのは以下のような眼鏡やコンタクトレンズ、レーシックのデメリットに比べて、費用はかかりますが、メリットが多いと思ったからです。
眼鏡のデメリット
- 痛み
- 長い時間付けていると目の奥が疲れる。
- 耳や鼻などの接地面が徐々に痛くなってくる。
- 見かけ上の問題
- 外から見た時に目元が小さく見えてしまう。
- レンズを薄くしてもほとんど効果はなかった。
- ウスカルメガネ(参考: 強度近視メガネのウスカル会)等の眼とレンズの距離を狭くする案は自分の場合まつ毛がぶつかってしまうため不可。
- 外から見た時に目元が小さく見えてしまう。
コンタクトレンズのデメリット
レーシックのデメリット
- 不可逆
- 一度角膜を削ってしまうと元に戻せない。
- 痛そう
- 切る角膜のサイズが大きいため痛そう。レーシックは 28mm 切るのに対し、ICL は 3mm だそうな。
ICL 手術を行う病院は 関東エリア｜クリニック一覧｜ICL研究会 から探しました。
自宅に一番近い『インフィニティメディカル 近藤眼科』のサイトを見てみたところ、ICL の執刀医が YouTube で『近視治療説明会 20分動画』( https://www.youtube.com/watch?v=fEC5B2Ndp-8 ) として ICL に関して説明していることを知り、一通り見て任せてよさそうと判断したためこちらに決めました。
やってみた感想
- 手術中とにかく眩しい
- 手術中は本能が拒否するレベルで眩しい。右眼はなんとか耐えられたけれど、左眼が限界で、パニックで落ちそうだった。
- 眩しさに弱い人で、もし ICL やりたいという場合は事前に医師に相談した方がよさそう。
- すぐ視える！！
- 手術10分後: 眼鏡無しでも外を歩けるレベル。
- 手術4時間後: 遠くの景色ならちょっとぼやけたコンタクトレンズを付けているかのように視える。裸眼なのに不思議。
- 手術9時間後: 散瞳もおさまり外の景色もくっきり。溢れ出る満足感。意味もなく外出したい気持ち。
- 意外と痛くない
- もらっていた痛み止め、何となく飲んでみてはいたけれど、飲む必要はなかったかもしれない。
- 術中も術後も思っていたほど痛くなかった。
- 暇
- 手術前後はとにかく暇。手術前は散瞳や麻酔の効果を待ち、術後は安定を待つ。ひたすらじっとしていなければならない。
- 手術当日はテレビ・読書・パソコン・スマホ禁止のため帰ってからも暇。Audible を聴いては眠るを繰り返した。
- 光の輪っかは気にならない
- 術後別に眩しくない
- 今のところ特に気にならない。
- (6/7 追記: 外で電光看板を見かけた時にもしかしたら術前より眩しく感じるようになっているかもと思った。が、気のせいかも。)
- 眩しさは気にならないけれど、眩しいものを見て瞳孔が動くことで ICL に当たって若干痛いのは気になる。
- (6/7 追記: 術後2日でこの痛みはなくなった。)
- 今のところ特に気にならない。
- 洗髪禁止が辛い
- 頭を
3日間洗えないのは苦痛。(首から下なら手術翌日から洗える。)- (6/6追記: 入浴欄を見返したところ『術後2〜4日目より可能』、『※ 1週間は目に水が入らないように』と記載されていた。さっそく保護用ゴーグルを付けた状態で上を向いたまま洗ってみたところ目に水が入らずに洗えた。)
- (6/6追記: 入浴欄を見返したところ『術後2〜4日目より可能』、『※ 1週間は目に水が入らないように』と記載されていた。さっそく保護用ゴーグルを付けた状態で上を向いたまま洗ってみたところ目に水が入らずに洗えた。)
- 普段1日に2回以上お風呂に入っているためなかなかの苦痛。
- 顔は清浄綿で拭くことで凌いでいる。
- 頭を
- MyTherapyが良い
- 目薬2種類を朝・昼・夕・就寝前、内服薬2種類を毎食後に飲まないといけないが、お薬リマインダー・飲み忘れ防止アプリ MyTherapy が役立っている。
- 薬の期間と用法用量を一度設定したら後は毎日自動で TODO を生成してくれて、点眼・服用する時間になったらプッシュ通知してくれる。時間が来たのにやっていない場合は badge で知らせてくれる。
- 全体的にみて大変
- 眼球に視力アップモジュールを差し込むだけでこんなに大変だなんて肉体そのもののつらみをすごく感じた。
- 4 次元とかの存在になって解消されたい。
- (6/7 追記: なかなか視力が安定しない (※ 特に近見)
- 変動はあるものの、遠くなら常に 1.0 以上見えている感じ。
- スマホぐらいの距離で文字を見た場合に左眼に限って文字が二重に見えることが多い。右眼だと近くでもくっきり見える。
(おまけ) 術後1日診察のQ&A
| Q | A |
|---|---|
| 手術直後に左眼が 15 分間ほど赤いセロファン越しに見ているような視界になっていたがこの原因は？ | 網膜毒性。一時的なものなら大丈夫。 |
| 近くを見る時に右眼がちょっと痛むがなぜか？ | 瞳孔が開いたり閉じたりした時にレンズに当たるため。1週間程度でこの感覚はなくなる。 |
| 術後の左眼の眼圧が 7mmHg と正常値より低かったが大丈夫だったのか？(診察時にはすでに 18mmHg まで上がっていた) | 手術直後に 30mmHg を超えるとかだと問題だけど、そうじゃなければ大丈夫。 |
| 今後視力がどの程度低下していくのか予測できたりするのか？ | 60歳ぐらいで低下すると思う。その時は白内障レンズに変えることになると思う。 |
| 将来白内障になった場合はICLを外す手術と白内障用レンズを入れる手術を同時に行えるのか？ | その時の先生によるが、自分だったら同時にやる。外すのはとても簡単。 |
| 今後眼を長持ちさせるために気をつけることは？ | 糖尿病や高血圧などいわゆるおっさん病に気をつける。症状が眼に出るため。 |
(6/15 追記: 術後1週間検診を受けて
視力検査では、右眼は 1.5 (前回の術後1日検診と同じ値) 出たが、左眼は 1.2 (前回 1.5 弱) だった。 また、前回同様目の表面を見る検査 (水晶体と ICL の距離や、目の表面の傷などを見るらしい) もしたが、問題なさそうだった。
診察では、スマホの文字を近くで見る際に左眼だけ文字が二重に見えることを伝えた。
伝えたところ、レンズの入り方は問題なく、検査で乱視も出ておらず、若いため老眼でもなく、原因はわからないとのこと。 (レンズのとある箇所を通して見た時にそういう見え方になることがあるというようなことを言っていた。)
まだ目に傷があるためそのせいかもしれないということで、ひとまず様子見となった。
検診はそんな感じ。
11日経った現在の所感としては、若干の異物感・ドライアイ感や、まれによく起こる左眼近見のピントずれなどいまいちな点はあるが、全体的にみるとまあやってよかったかなという感じに落ち着いている。
一生モノの眼に対して失敗する可能性のある手術を(必要性はないのに)行うというのはリスクを取りすぎな気がするため人には勧められないけれど。 (今となっては見えることが当然になってしまい公平な考えができずデメリットが浮かびがちになっているとは思う。)
(6/16 追記:
ロードバイクに乗ったが、遠くの葉の1枚1枚の揺らぎまで裸眼で見えて感動した。
以前はロードバイクに乗るとすぐにコンタクトレンズが乾いてしまっていたが、それが一切なくて素敵。
また、以前は乗る度に 1Day のコンタクトレンズを消費していたためもったいなさを感じていたが、それもなくなったためかなり気軽さが増した。
(6/18 追記:
ピントのズレで問題になっていた左眼の近見、昨日辺りからズレが少なくなってきてもう気にならなくなった。安定するのに 2 週間かかるんだなー。
(7/2 追記: 術後1ヶ月検診を受けて
検査の結果、左右の視力は両方共 1.5 出ていた。
診察では、水晶体と ICL との距離が多少短いようで、1〜2年に1度くらいの頻度で検査をした方がよいということを告げられた。
この距離が短いことを Low Vault と呼ぶらしく、先生曰く 0.5mm ぐらいあるかと思っていたが、実際には右眼が 0.23mm、左眼が 0.22mm だった。
この距離がどうなるかは ICL を入れてみるまでわからないらしい。
また、自分は角膜の大きさが他の人よりもかなり小さめで、レンズも 4 種類の中で一番小さいものを使ったとのこと。
水晶体と ICL との間にスペースがないと白内障になってしまうらしいが、多少スペースはあるのと、真ん中に穴が空いているレンズを使っているためそんなに心配するほどではないという感じだった。
年内の診療は無料とのことなので、年末にでももう一度診てもらおうと思う。
「Haskell入門」を読んで
2017年9月27日に発売された「Haskell入門 関数型プログラミング言語の基礎と実践」ですが、先日やっと読み終わりました。
本書のタイトルに入門と含まれていますが、「すごいHaskellたのしく学ぼう！」(通称すごいH本) よりも扱う範囲が広く、実践重視という感じでした。
「すごいH本」はモナドに入った辺りで挫折してしまい最後まで読めていませんが、Haskellに興味を持つきっかけとなった思い入れのある大好きな本の一つです。
本書を読んでよかったこと
1. サンプルコードが豊富
本書では説明に対してサンプルコードが付いていることが多かったです。
説明を理解しているかどうかはサンプルコードと同じコードをまっさらな状態から書けるかどうか試せばわかるため、理解していることを確認しながら安心して先に進むことができました。
具体的な読み進め方ですが、
- サンプルコードがある場合
- サンプルコードと同じコードを import 以外まっさらな状態から書けたら次へ
- サンプルコードがない場合
- 文章を要約したら次へ
という方法を取りました。
また、自分の場合は収集癖をくすぐると捗るため、TODO リストの TODO 欄に <ページ>: <要約> を、メモ欄にサンプルコードを貼るということをしていました。
読み終わった現在では 500 件以上の TODO が登録されていました。
2. モナドに対する苦手意識が克服できた
「すごいH本」でモナドで挫折して以来モナドに関して苦手意識があったのですが、本書の豊富なサンプルコードで苦手意識を克服することができました。
モナドに関しては第5章で個別に Maybe, State s, Either e, Except e, Reader r, ST s 等の説明がなされますが、ここでの理解がいまいちだったとしてもいくつかのモナドに関してはその後モナド変換子含め何度も登場してくるため、苦しみながら最終的にはモナドが何となくわかるようになっています。
例えば、第11章では ExceptT e (AuctionSessionT (InputT IO)) a のような型が登場します。
3. Web アプリケーションが書けるようになった
第10章では Spock という Ruby でいう Sinatra のような薄いフレームワークを使って Web アプリケーションを作るのですが、Web アプリケーションの作成に必要な説明が一通りされているため Haskell でも Web アプリケーションいけるなという感触を得ることができました。
フルスタックな Yesod を使用しないことによって Web アプリケーションの作成に必要なパーツとそのインターフェースの部分をより深く知ることに繋がったと思うので、その点も嬉しかったです。
4. 並行処理の基礎が身についた
「第8章 並列・並行プログラミング」では MVar や TVar, atomically, mask, async などの使い方をサンプルコード豊富に解説されていて、並行処理の経験のない自分にとってはナルホドの連続でした。
本書でも紹介されていましたが、「Haskellによる並列・並行プログラミング」を読んでもっと深く知りたいという気持ちになりました。
5. 冗長な関数名の回避策を知ることができた
Haskell では重複を避けるために関数名が冗長になりがちだと思うのですが、これに関して一部 Control.Lens.TH の makeFields を使うことで例えば userName user を user ^. name のように呼べるようにしているのを見てなんて便利なんだと思いました。
6. パーサを作れるようになった
第9章では jq コマンドのようなものを attoparsec というパーサライブラリを使って書くのですが、途中 fmap (Object . H.fromList) . sequence . fmap sequence $ fmap (fmap $ flip executeQuery value) o と 1 行に fmap が 4 回も出てくるコードが出てきた時はしびれました。
まとめ
読み終わるまでに時間がかかってしまいましたが、最後まで読みきることができ、大変愛着のある本になりました。
著者の方々並びに関係者の方々、楽しいひとときをありがとうございました。
