結婚後の姓変更手続きをやっと進めたので記録

結婚して9ヶ月くらい(?)経ったけど、新姓と旧姓をまぜて生活していた。手続きは面倒なので必要に迫られるまでやらないいつものスタイルを貫いていたところ、ついに困ったことが起きた。確定申告の還付金が振り込めないと言う*1

私のお金が!返ってこない!ということでやっと銀行やクレジットカードを更新し始めた。やってみて、ポイントは銀行絡みの3つかなと思った

  • 事前に住所を最新化しておけば銀行の姓更新もオンラインで出来る*2ので便利っぽい。もちろん銀行による
  • 銀行口座の更新は、そこからの各種引き落としが凪なタイミングを狙うと良い。結婚したらすぐ手続き!とすると面倒なことになりそう
  • ネットバンキングは使えるようにしておこう(使ってない人がいるのか分からないけど)

結婚して割とすぐ更新したもの

  • マイナンバーカード: 婚姻届を出すとそのまま役所で手続きされる。新旧の姓が印字されるので、色々な更新手続きに欠かせない。
  • 保険証: お医者さんに行くので必要だった。会社にお願いして再発行となった
  • パスポート: USのグリーンカードの抽選に申し込んだので必要だった。全く新規で発行し直すことも、今のパスポートの姓を変えて再発行することもできる。5年くらい残っていたので再発行にしたが、決まりで苗字が変わっただけなのにお金がかかる(6,000円)のは1ミリ納得がいかない

要するに公的書類はなんだかんだ必要なのでさっさと更新してあった。運転免許は持っていない。

確定申告をきっかけに更新したもの

  • 銀行の口座名義: 公的書類と一致しないと還付金をゲットできないことがすべての出発点。今後他にも問題が出てくるかもしれない
  • クレジットカードの名義: 引き落としの銀行口座と名義が一致しないと使えない
  • 証券口座の名義: 入金の銀行口座と名義が一致しないと使えない
  • 銀行やクレカを使うサービスの登録名: なんとかペイとかECサイトとかモバイルSuicaとか。新しい名義に合わせないと困ったことになったら面倒

依存する登録銀行口座を更新したのは

  • 会社(副業先や印税含む)の給与振込先
  • LOVOTの代金引き落とし先

更新対象を洗い出すにあたってはマネフォ様様で、銀行の動き履歴から漏れなく拾うことができた。ありがとうございます!

銀行口座名義更新体験記

ひとまずUFJだけ更新した。今どき、姓変更だけならオンラインで出来るらしい!

www.bk.mufg.jp

しかも、その手続きをすると印鑑レス口座に切り替わるとかめっちゃいい。
でもこの手続ではもちろん本人確認をするわけだが、公的書類に記載の住所と銀行の登録住所が異なっているとアウト。私は3つくらい前の住所が登録されていたので、諦めて窓口へ行くことに…。入籍前に住所だけアップデートしてれば出かけなくて済んだのかと思うと体験が違いすぎる。

予約せずに行った窓口ではフォンブースみたいなところに案内され、リモートでオペレーターの方に対応していただいた。家で電話するのとは違い、スキャナーとプリンターが設置されていて書類もやりとりできる。
窓口に持参したいものは

  • 本人確認に使える公的書類
  • 新旧の印鑑(旧はなくても何とかなる)
  • 口座情報が分かるもの(要はキャッシュカードや通帳があれば良いが、これらの現物が必要になるわけではない)

ちなみに私は旧印鑑を持たずに行った。邪魔だなこの印鑑…とか思いながら収納の奥底にしまった記憶だけがあって、実際どこにあるか分からなかったので早々に諦めた。なので、住所・姓・印鑑の変更手続きをしていただいたことになる。印鑑がないと手続き完了までの時間が少し伸びるらしく、2〜3週間かかる模様。完了通知は来ず*3、ネットバンクにログインして変わってればOKって感じみたい。カードも再発行はなく旧姓のものを使い続けることができる*4
書類は3枚書いたけど、署名と捺印だけの紙もあったし大した量じゃなかった。総じて、身構えるほど面倒ではないなという印象に終わった。ちょくちょく待ち時間があったので、それを活用してクレカや証券系の更新を行った。

クレジットカード名義更新体験記

使ってるカードが5枚くらいあるので頑張ってポチポチした。大体オンラインで出来るが、新幹線のエクスプレスカードでお世話になっているセディナだけは申請書を取り寄せて物理提出が必要みたい。
姓の更新手続きは「名義変更」か「再発行」っていうような名前になっており、後者について、言われてみれば当然だけど再発行という発想がなかったのでなかなか見つけられなくて泣いた。引き落とし口座の更新は実際に銀行の方の手続きが完了しないと出来ないので、また今度やる。

我がカードちゃんたちは4日、10日、27日に引き落としがあって、今回の手続きは12日に行ったわけだが図らずもベストタイミングだった。クレカの名義変更は済んでるけど銀行はまだ、となると多分名義人不一致で引き落とせなくて1ミリ面倒なことになるので、それを避けられそうな期間に済ませるのが良さそう。

ヤフーカードはこの再発行のおかげで予定より半年近く早くPayPayカードに切り替わることとなった。ちょっと嬉しい。

追記: 実はヤフーカードも申請書が届くパターンだった。カード来たと思ったら紙だった…なんか意外。

その他体験記

モバイルSuicaは運用でカバーみのある段取りだった。サイトから「姓を変更したい」と申請すると、(多分手動で)名前を更新できる状態に切り替えてくれる。すると1回だけ変更できるようになるのだ!もし間違えたら申請からやり直しだと思われる。どうしてこうなっているんだろうか?ポンポン変えられても困るけど、内容を審査するほどのことではない、みたいな感じかな…。

証券口座は古巣FOLIOのだけ持っているが、氏名の変更機能、自分で作った…というかプロジェクトマネジメントしていた気がする。懐

感想

  • 最強に面倒なことだと思って避けてきたけど、半〜1日まとめて作業すれば終わるかもしれない。ただ完了まではバラバラとラグがあるのでやっぱり心理的にはだるい
  • 銀行の名義変更、各種引き落としに間に合って欲しい
  • 住所入力フォーム、2022年になっても半角で入れろとか全角じゃないとエラーみたいなやつがいっぱいで辛い
  • 京都の住所が長すぎて入力できないシステムがまだあって辛い。逆に、全部入力しないと審査で弾かれる場合もあるので、空気を読まなくてはならない

これ以外は引き続き放置して(というかもう更新対象が把握できてないみたいなところがある)、気が向いたら変えていこう。もし自分が確定申告をしないタイプの人間だった場合、何がきっかけになっていたんだろう。
ちなみに仕事とか外に出る活動は旧姓のまま行っている。あとお店の予約は一緒に行く人がどちらで認識しているかと気分で変えている。

夫婦別姓はよ!!!とは思わないというか、私個人としてはどっちでもいいので流れに身を任せるけど、シンプルに面倒くさいな。とはいえ思ったよりは面倒じゃなかった。いや、面倒だけど仕組みの進化は感じる。まぁ全部マイナンバーでなんとかしてください!

*1:これについては後日、ちゃんと機能する銀行口座を指定するための書類が郵送で届くらしい

*2:オンライン完結と郵送を伴うパターンがありそうだけど、少なくとも店舗に行かなくて済む

*3:正確には印鑑の更新完了通知のみ郵送で届くらしい。実際、名前の更新もこのタイミングで完了していることがほとんどだとか

*4:希望すれば再発行もできるっぽかった

PyLadies x Java女子部 の軌跡とコミュニティコラボのいいところ

これは PyLadies Japan Advent Calendar 2021 15日目の記事です。もう12月も半分過ぎようとしているんですね、恐ろしい。

Java女子部の運営をしておりますよこなと申します!
Java, Scala, Ruby, JavaScript, Goなど「ほんのちょっとでも書いたことがある言語」なら色々ありますが、Pythonだけは本当に全く書いたことがなくてごめんなさい (このポピュラーな言語をここまで書かずに来たんだからもうそのまま引退したいという謎の思いすら湧いている) 。

そんな私ですが、PyLadiesさんとは結構縁があって何度かイベントでご一緒したことがあります。

合同で主催した勉強会

一緒に登壇したイベント

pycon.jp

event.shoeisha.jp

こうして振り返ると記憶にあるより多かったです。

コミュニティコラボの良さ

この記事で「コラボは良いものだ」と伝えたいのは皆さんお察しの通りですが、どう良いかを一言にすると「幅が広がる」ということですね。

  • イベントのテーマの幅が広がる。お互い知らないことを教え合うイベントも出来るし、共通テーマで言語毎に違うアプローチを知ってみるのも為になるし、特別なエッセンスを入れずただ同じことを学ぶのにも意義がある
  • 参加者の幅が広がる。どんな幅かというと…
    • 参加者の業種や職種、業務内容。同じコミュニティ内でも様々だが、その言語の強みによって多少は偏りが出るのでコラボにより更に広がる
    • 場の雰囲気。それなりに長く運営されているコミュニティにはなんとなくカラーが出てくるが、それも違って面白い *1
    • 参加者が持っている経験値や話のネタ。上2つで上げたような違いから導かれるもの
    • イベント会場の部屋の幅(え)。合同なので単純に人数を集めやすい。特に女性コミュニティは人が少ない問題を抱えるところも少なくないが、その解決方法のひとつになる

上で挙げた過去イベントでいうと、言語に関係なく活用できるGitを一緒に学んだり、「女性コミュニティ」という共通点から対談をしたりしたのは同じテーマを扱ったものです。一方、分析APIの会は「分析」というPythonが強みを持っていそうなジャンルを取り上げながらもJavaを使ってコードを書くことで新しいことを学び合う場でした。

個人としては単純により多くの人と知り合えるのが有益で嬉しいです!私の場合、SNSで日々の挑戦やご活躍に刺激をもらっているPyLadiesの方がいます。イベントで知り合って以来、IT業界特有のゆるさでSNSにて繋がり続けることができているので非常に尊いです。 *2

印象深いのは、生まれて初めて技術的な発表をした「Git for Begineers」の会です。先に書いたとおりコラボイベントは単体のときより人数が多くなりがちです。数十人の前での発表にすごく緊張したものの、皆さんあたたかくてそこから技術に関する登壇のハードルも下がっていきました。初めてはてブのブクマ数が結構いってホットエントリーに入ったぞ!みたいな体験もした気がします(これも人数が多かったのはプラスになったかもしれませんね)。優しい雰囲気の場で成功体験ができたのは今の自分を作っているひとつの要素だと感じます。よく考えたらこれがきっかけでGitの本を出版するまでに至りました。

ちょっと気持ちよく思い出を語ってしまい気持ち悪くて恐縮ですが、皆でわいわいと時間を共有することの良さがちょっぴり伝わるといいなぁ〜という一心です。
実際、私以外にもコラボの話で初めて大勢の前で登壇する経験をしたメンバーを知っていますし、きっと似たようなプラスの要素を得られるケースは少なくないはず!

コラボしようぜ

2022年、またPyLadiesさんとJava女子部で何かやりたいです!それ以外のコミュニティの方も、ぜひなんか一緒にやりましょう。願わくばオフライン…が出来たらいいですが、まずは気軽にオンラインから!

ちなみにJava女子部は年明け1月8日(土)に「座談会」というか参加者でおしゃべりやお悩み相談会をする激ゆるふわイベントをやる予定なので良かったらそこでも会いましょう〜!イベントページまだないんですが、doorkeeperTwitterに情報流す予定です。
…って書くと、自分のコミュニティを宣伝したくてアドベントカレンダーに乗り込んできたみたいにならないか心配ですが、そんな思惑ではなく皆さんと勉強会とかパーティー(?)とかやれたら嬉しいです。

あ、あと自分自身の目標としてコラボイベントではないPyLadiesイベントに参加してみたいのでオススメ会があったら教えて下さい!

最後に

PyLadiesさんやJava女子部がいい感じに紹介されているインタビュー記事を貼って終わりにしまーす!この記事、そして関連するWomen Developers Summit (前述) は2021年の出来事なので新しい情報が詰まってます。

codezine.jp

codezine.jp

ということで、今まで & 2021年の PyLadies x Java女子部 ふりかえりでした。以上!アドベントカレンダー、もう1枠くらい空いてたら技術的な何かも書こうかな。

*1:外れていたら申し訳ありませんが、PyLadiesの皆さんは明るくてお酒が大好きな方が多いイメージです!もちろんそうじゃない方も楽しめる場ですよ!でも、なんかわいわいしてていい雰囲気!

*2:これについてはコラボ会じゃなくても色々なコミュニティに参加すれば良いだけなのですが、知らない人が多い場に行くより、知ってる皆もまとめて合同イベントという方が気楽だという人も少なくないと思うので!

最近久々に元気・ポジティブな状態で頑張れるようになってきた

1年半〜2年くらい前から「う〜ん疲れちゃった…」ってなって、省エネ状態で暮らしていました。
正直昔から頑張れるパワーには波がありますが、ここ2年くらいは人生で1番やる気がなくなっていて、「頑張っても周りの人の足元にも及ばない…」「仮に何かうまくいったとして、人類史に何が残るんだ…」「寝ていたほうがトータルの幸福度は高い」などと考えてふにゃふにゃでした。ちなみにここでいうやる気というのは主に趣味や自己研鑽、コミュニティ活動などオフ時間の頑張りに直結するものです。

かつては何の疑いもなく「頑張る」ことを正としていたにもかかわらず、段々とそのコスパに目がいってしまったこと、背伸びして頑張り続けるのが大変だと知ったことにより立ち止まってしまったようです。

永遠に布団にいる日もあったし、お医者さんにちょっと相談してみたりもしたけど、前職の友にもらった「長い人生だから立ち止まる時間があっても大丈夫」といった力強くありがたい言葉を胸に割とのんびりしていました。その間ちょうどコロナで家にいることも増えて、色々なことを考えました。

  • なんか何事も進捗がない感じがするな〜でも別にそれでも困らないな〜今後も一生この感じでいこうかな〜
  • コロナで大変な世の中だけど自分は何もできないな〜自分がやることが世にとってプラスになるかどうかもっと考えてみたいな〜
  • 今まで何故頑張ってきたんだろう〜これから何を目指して生きていくんだろう〜
  • とにかく好きな人達と関わりを持ち続けながら暮らすのが自分にとっては幸せだな〜そのためには時間やお金や色々な余裕があった方がいいのかな〜

ゆったりした生活による空き時間で、以前はあまりやらなかったゲームをするようになったり、久々な知人に積極的に「元気?」と連絡してみたり、行動にも小さな変化があった気がします。
いずれも「疲れちゃった…」とステイホームが重なったことによるものだと思われますが、「自分は何を考えているのか/大事にしているのか」を考える時間、やらなかったことや疎遠だった人に割く時間が増えたのは結果として良かったみたいです。

結局、立ち止まって色々考えているうちに具体的に実現したい目標ができて、最近漸く浮上してきました。

ということで、このツイートをしたあたりから自分でも驚くほどみるみる元気になってきて、省エネモードはいったん終わりを迎えたのでした。たまには自分との対話に集中してみるもの良いものですね。そして目指すものがあると何をすべきか分かりやすくてとても良い…。

自分の傾向をふまえるとこういうことなのかなという整理もできたので、適度に頑張り続ける生き方を今は選んでみます。

早速、前より起きている時間はめちゃくちゃ長くなったのにやりたいことが片付かなくなりつつあります。つまりはやはり波の大きい人間なんですが、今後は次のレベルアップとしてその波を小さくしていくところを目指します。安定感!

英語のプロフィール(bio)をネイティブな友人に添削して頂いた

biography。バイオ。カンファレンスとかで使うお仕事感あるプロフィールを添削してもらったので知見をメモしておこう。

私が書いたオリジナル

Ayana Yokota is a Developer Advocate at JFrog. Originally she was a web developer, having a background in backend engineering, and experienced various companies. These days developers community management is her favorite activity. She is a founder and organizer of Javajo (the Java Community for women in Japan), and also organizes Japan Java User Group. An author of "The easiest textbook of Git and GitHub".

添削してもらったバージョン

Ayana Yokota is currently a Developer Advocate at JFrog. She began her career as a web developer, having a background in backend engineering gained through experience at various companies. These days, management of the developers community is her favorite activity. She is a founder and organizer of Javajo (theJava Community for women in Japan), and also a board member of the Japan Java User Group. Co-author of "The easiest textbook of Git and GitHub".

教えてもらった/話したこと

私: ほとんどの主語がAyana(She)になってしまったけどどうしたらいい?一応These daysで始まる文は主語を変えたのと、最後の文にはくどいのでShe isを付けなかった。
友: ふつう同じ主語が続くことを避けた方が良いのは確かだけど、今回は短いしAyanaのbioなので問題ない。最後の文は主語がなくても明らかだし読みやすくなるので良い工夫だね。

.
友: いろんな会社での経験があることを表すためにgained through experience at various companiesとか付けてみるのはどう?
私: 素晴らしい…gained throughとか自分では思いつかない。

.
私: Java女子部もJJUGも運営メンバーだけど、Java女子部の方だけ設立にも携わってる。これをスマートに表現するのが意外と難しい。a founder and organizer of Javajo and an organizer of JJUGだとくどい気がするから後半をorganizesにして無理やり差を付けたけど…。
友: 違う名詞をつなげた方がシンプルでいいかもね。administratorはどう?
私: あ、board memberって皆よく言ってるかも!

.
私: 共著なんだけどこれでいいのか?
友: Co-authorだね。
(これはググれカスだったね。共著者のちむさんごめん・・・)

その他の知見とか小さい変更点とか

  • 名詞を繋げるのは良いけどdevelopers community managementはちょっと読みづらいのでmanagement of developers communityくらいにしておこう。
  • These daysの後のカンマはまぁなくても問題はないけど読みやすさのために入れよう。
  • bioは自分のことであっても第三者目線で書いて主観が入っていない感じにする。
  • 誰のbioか一目で分かるので、名前から始めるのはgood.

バイバイオ👋

セミコロンの使い方を知りたい(Javaじゃなくて英語の話)

セミコロンを使わないJavaの話はしないぞ!!

コロンは例示とか言い換えを便利にしてくれるものとしてたまに使うけど、セミコロンは何なのかすらちゃんと分かっておらずスルーしていた。ちゃんと調べてみたら要はカンマとピリオドの仲間。等位接続詞の代わりになったり、接続副詞と併せて使ったりするらしい。

例1

She is a programmer; she writes JavaScript code.

情報を付け加える等位接続詞の and の代わりにセミコロンを使ったパターン。

セミコロンなしバージョン

She is a programmer, and she writes JavaScript code.

彼女はプログラマーでJSを書いてるよ。

例2

It is written in Java; it runs anywhere.

こちらは等位接続詞 soセミコロンになっている。

接続副詞使ったバージョン

It is written in Java; therefore, it runs anywhere.

この書き方でもセミコロンが使えるらしい。

セミコロンなしバージョン

It is written in Java, so it runs anywhere.

Javaで書かれてるからどこでも実行できるよ。

感想

かんたんだね!今まで「セミコロンってなんだっけ」と思いつつ深く気にせず調べもせずやってきたがやっと学んだ。自分が使うことはあまりなさそうだけど、ネイティブの人はどういうときに使うのか今度お友達に聞いてみよう。

ちなみに、カンマで区切って何かを並べるときにセミコロンを混ぜることでカテゴライズとかもできるらしい。

Java, JavaScript; India, Indonesia; ham, hamstar

参考文献

Javaのレコード(Records)は入れ子にして便利に使える #javajo #java14

結論

タイトル通り。

前置き

先日Java女子部でこんなイベントを行いました。
javajo.doorkeeper.jp

型の基本から最新情報まで学べる豪華な会で、知らないことも多くとても面白かったです。
他の多くの参加者にとっても同様だったようで、満足度の高いイベントになりました。西川さんありがとうございました!

さて、Java 14からプレビュー機能として「レコード」が追加されました*1

特徴の一部を西川さんの資料から拝借しました:

  • イミュータブルである
  • recordは暗黙のうちにfinalである
  • recordクラスのメンバー変数はfinalである
  • 値がすべて同じならequals()ではtrueを返さなくてはならない

Java女子部のイベントではサンプル付きでレコードについて学んだのですが、
フィールドがint型やString型だけだったので、 「レコードは入れ子にできる?したらどうなる?」という疑問が湧きまして。実際使うときって入れ子にしたいし。
ということで、それを動かして調べてみるのが私の宿題となったのでした。

ソースコード付き実験と解説

レコードを定義してみる

大好きな「あつまれどうぶつの森」風サンプルにしました。実際のあつ森はこの何億倍も複雑ですが。

  • 名前と色の情報を持った家具がある
  • 家具はリメイクすることで色を変えられる
  • 家具は複数個ポケットにしまうことができる

を満たすクラスたちをレコードとして作ってみます (サンプルにおいて package とか import は省略してます)。
f:id:ihcomega:20200804095014j:plain:w300

クラス名の後にコンストラクタ風にメンバー変数を渡すと便利なメソッドやらが色々生成されます(後述)。
Scalacase class みたい。

/**
 * 家具の名前
 */
public record FurnitureName(String value) {}
/**
 * 家具の色
 */
public enum FurnitureColor {
    RED,
    BLUE,
    YELLOW,
}
/**
 * 家具
 */
public record Furniture(FurnitureName name,
                        FurnitureColor color
) {
    // 2021.09 追記: レコードには自動でgetterが生えるので本当はこのメソッド要らないですね…
    // しかし、これがある状態で後述の検証をしちゃったので残しておきます。
    public FurnitureName name() {
        return name;
    }
}
/**
 * 家具を入れるポケット
 * 入れる位置がkey, 中身がvalue
 */
public record Pocket(Map<Integer, Furniture> furniture) {}

FurniturePocketコンパイルされた後どんなメンバーを持つか見てみます。

$ javap -p Pocket.class
Compiled from "Pocket.java"
public final class com.example.animal_crossing.main_character.Pocket extends java.lang.Record {
  private final java.util.Map<java.lang.Integer, com.example.animal_crossing.item.Furniture> furniture;
  public com.example.animal_crossing.main_character.Pocket(java.util.Map<java.lang.Integer, com.example.animal_crossing.item.Furniture>);
  public java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public java.util.Map<java.lang.Integer, com.example.animal_crossing.item.Furniture> furniture();
}
$ javap -p Furniture.class
Compiled from "Furniture.java"
public final class com.example.animal_crossing.item.Furniture extends java.lang.Record {
  private final com.example.animal_crossing.item.FurnitureName name;
  private final com.example.animal_crossing.item.FurnitureColor color;
  public com.example.animal_crossing.item.Furniture(com.example.animal_crossing.item.FurnitureName, com.example.animal_crossing.item.FurnitureColor);
  public com.example.animal_crossing.item.FurnitureName name();
  public java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public com.example.animal_crossing.item.FurnitureColor color();
}

javapコマンドに詳しくなくてもかんたん!以下のことが分かりますね。

  • record で宣言をすると Record クラスを継承したクラスとなる
  • レコードクラス自体は final となる
  • レコードクラスのメンバー変数は private final となる (ので、setterは生成されない)
  • toString(), hashCode(), equals(), getter, コンストラクタが自動で生成される

レコードにふるまいを持たせてみる

さてここで「ポケットから家具をひとつ取り出してリメイクしてまたポケットにしまう」というコードを実行できるようにレコードを拡張してみます。 レコードはイミュータブルなので Furniture インスタンスを直接書き換えることはできません。
ということで、 PocketFurniture にリメイクに必要なメソッドを生やしてみました。
慣れないJavaですが、Stream API使いに改善の余地があったら教えて下さい

/**
 * 家具
 */
public record Furniture(FurnitureName name,
                        FurnitureColor color
) {

    /**
     * 家具の色を指定したものに変える(リメイクする)
     *
     * @param newColor リメイク後の色
     * @return 色の変わった新しい家具
     */
    public Furniture remake(FurnitureColor newColor) {
        return new Furniture(name,
                newColor);
    }
}
/**
 * 家具を入れるポケット
 * 入れる位置がkey, 中身がvalue
 */
public record Pocket(Map<Integer, Furniture> furniture) {

    /**
     * 指定した位置の家具を取り出す
     *
     * @param position 取り出す位置
     * @return 取り出した家具
     */
    // 余談なんですが、最初はOptional<Furniture>を返すようにしてたものの
    // 呼び出し元がmapやflatMap祭りになって見辛くなったので今回は強気のgetにしました
    public Furniture takeOut(int position) {
        return furniture.get(position);
    }

    /**
     * 指定した位置の家具を、別の家具と入れ替える
     *
     * @param position 入れ替える位置
     * @param newFurniture 入れ替え後、ポケットの指定した位置に入る家具
     * @return 入れ替え後の家具が入った新しいポケット
     */
    // これもうちょっとスマートに書けるのかな?
    public Pocket replace(int position, Furniture newFurniture) {
        Map<Integer, Furniture> replaced =
                furniture.entrySet().stream()
                        .map(e -> {
                            if (e.getKey() == position) {
                                return Map.entry(position, newFurniture);
                            } else {
                                return e;
                            }
                        })
                        .collect(Collectors.toUnmodifiableMap(Map.Entry::getKey, Map.Entry::getValue));
        return new Pocket(replaced);
    }
}

レコードの特徴を確認してみる

Java女子部と同じように equals() メソッドの挙動を見て、値が同じであればtrueを返すのを確認することにしました。
次のようなコードを -enableassertions オプション付きで実行してみます。

Furniture cuteTable = new Furniture(new FurnitureName("かわいいテーブル"), FurnitureColor.RED);
Furniture coolChair = new Furniture(new FurnitureName("かっこいい椅子"), FurnitureColor.BLUE);

// かわいいテーブル(赤)・かっこいい椅子(青)が1つずつ入ったポケットをつくる
Pocket myPocket = new Pocket(Map.of(0, cuteTable, 1, coolChair));

// かわいいテーブルを青にリメイクする
Pocket onceRemadePocket = myPocket.replace(0, myPocket.takeOut(0).remake(FurnitureColor.BLUE));

// かわいいテーブルを再び赤にリメイクする
Pocket remadeAgainPocket = myPocket.replace(0, myPocket.takeOut(0).remake(FurnitureColor.RED));

// 1回目のリメイクでPocketインスタンスが作り直される
assert myPocket != onceRemadePocket;

// 1回目のリメイクでPocketの中身が始めと異なる
assert !myPocket.equals(onceRemadePocket);

// 2回目のリメイクでPocketインスタンスが作り直される
assert onceRemadePocket != remadeAgainPocket;

// 2回目のリメイクでPocketの中身が始めと同じと判定される
assert myPocket.equals(remadeAgainPocket);

System.out.println("問題なくここまでくればOK");

実行結果は次のようになったので、想定通り!

問題なくここまでくればOK

今回はここまで。

余談

javap -p -c -v xxx.classの結果を見て、 equalsメソッドの生成についてもうちょっと細かいところも見てみたんですが
それも記事に入れようとすると公開まで時間がかかりそうなので諦めました。へへへ

このへんにたどり着いた↓ jdk/ObjectMethods.java at 827e5e32264666639d36990edd5e7d0b7e7c78a9 · openjdk/jdk · GitHub

パッと思いつく下手な英文和訳パターン5選

f:id:ihcomega:20200604213016j:plain

前回に引き続き、英語の小ネタです。英語を日本語にするときの「あるある」を思いつくがままに書いてみます。(あくまで私の感覚でより良い訳し方をオススメしている記事にはなりますが)気をつけよう!
なお、例文は不自然じゃない程度になるべく直訳しています。

要らない主語は省こう

  • (例) Before we talk about this issue, let's take a look at the handout.
    • △ 私達がその問題について話す前に、(お手元の)印刷物をご覧ください。
    • ○ その問題について話す前に、(お手元の)印刷物をご覧ください。
  • (例) This tool changes the way you manage bugs.
    • △ このツールで、あなたがバグを管理する方法が変わりますよ。
    • ○ このツールで、バグを管理する方法が変わりますよ。

英語は日本語に比べると主語を明示しがちですが、それを忠実に翻訳する必要はありません。特に、一般論を語るときや大衆を相手にしたときの weyou は典型的な省略対象かなと思います*1

要らない指示語は省こう

  • (例) There is a sweet apple on the desk. You can take it.
    • △ 机の上に甘いりんごがあります。それを持っていっていいですよ。
    • ○ 机の上に甘いりんごがあります。持っていっていいですよ。
  • (例) He was angry. This is because his brother ate all cookies.
    • △ 彼は怒りました。それは何故なら兄(弟)がクッキーを全部食べてしまったからです。
    • ○ 彼は怒りました。何故なら兄(弟)がクッキーを全部食べてしまったからです。

主語の省略に似た話ですが、要らない目的語は割愛しましょう (ひとつめの例)。
また、This is why ~, It is interesting to do ~みたいに訳す必要のない itthisthatなどを使った慣用表現がたくさんあるのでそれも注意しましょう (ふたつめの例)。

関係詞や修飾語で長くなった文・語は区切ろう

  • (例) Spring Batch provides reusable functions that are essential in processing large volumes of records, including logging/tracing, transaction management, job processing statistics, job restart, skip, and resource management.
    • △ Spring Batchは、ロギング・トレーシング、トランザクション管理、ジョブ処理の統計、ジョブの再実行やスキップ、そしてリソース管理などをふくむ大量のレコードを処理するのに不可欠な機能を再利用可能なものとして提供します。
    • ○ Spring Batchは大量のレコードを処理するのに不可欠な機能を再利用可能なものとして提供します。たとえば、ロギング・トレーシング、トランザクション管理、ジョブ処理の統計、ジョブの再実行やスキップ、そしてリソース管理などです。
    • ○ Spring Batchはロギング・トレーシング、トランザクション管理、ジョブ処理の統計、ジョブの再実行やスキップ、そしてリソース管理などの再利用可能な機能を提供します。これらは大量のレコードを処理するには不可欠です。

うーん、めっちゃあるあるなのにいい例が浮かばないよ〜。ひとまず一例をSpring frameworkのドキュメントから拝借しました (リンク)。
しかもこのくらいの長さなら一文でもそんなに問題はないですね。要は原文の文の数に引きずられる必要はないということです!途中で文を区切るのも翻訳者の自由なので、長すぎる名詞や文をそのまま訳す必要はありません。
英語は言葉の前にも後ろにも修飾語をいっぱい付けられるので、気をつけないと主語と述語が行方不明になりそうな長文が爆誕します。

和製英語は程々にしよう

  • (例) Checking emails is my daily routine.
    • △ メールチェックは私のデイリールーティーンです。
    • ○ メールチェックは私の日課です。

上の例文はまだ可愛らしいものですが、カタカナが大量に並んで理解しづらい文をしばしば見かけます。エンジニアは英語圏から来た言葉をそのまま使うことも多いので、技術的な文章ではなおさらありがちですね。
どうしてもカタカナにしかならないものは仕方ないですが、例えばinternationalとかglobalみたいな(似たような例しか浮かばなかった…)カタカナでも漢字でも表現できる言葉はどちらがいいか選ぶ習慣をつけたいものです。

呼びかけや問いかけは日本人が言いそうか考えてみよう

  • (例) Do you need more information?
    • △ もっと情報が欲しいですか?
    • ○ より多くの情報はこちらに掲載しています。
  • (例) Wanna watch the video?
    • △ ビデオが観たいですか?
    • ○ ビデオもご覧いただけます。

プロモーションやキャンペーンなどでよく見かけるのですが、相手を誘うような文言を正直に訳すと「失礼な!」「急に馴れ馴れしいぞ」といった印象を与える文になることがあります。
相手が日本人だったら、なるべく日本流のお誘いをしましょう。

終わりでーす。また思いついたら書きまーす😺

*1:逆に、和文英訳において文脈から判断した主語を補うのは難しさのひとつみたいですね。Twitterで翻訳をしてくれるGoogle translateくんなんかもしょっちゅう間違えてます。私自身について書いたツイートなんだけどHeって書かれていることがしばしば…