今日はこれをやりたい、と心の底から思えるようなことがないと早起きができないタチなんだろうな、と自覚しつつある。
TOPIK I (初級) を受験した
受験しました。
受験のモチベーション
Duolingoで韓国語の学習を2年以上続けていて、韓国語のブルアカの二次創作がちょっと読めるようになったり、韓国に渡航して同人誌を買うことができたりしているけど、韓国語の読解力がどれくらい付いているのか、客観的に知りたくなったのが大きい。Duolingoだと問題形式によってはヒントが見放題で、どれくらい定着しているのかパッと分からない。TOPIKは「韓国政府が公式認定する唯一の韓国語能力試験」と説明されているので、これを受けてみるのがよいだろうと思って、受験することにした。
実は7月開催の試験を受けられるとちょうどよいんじゃないかと思っていたけど、申し込みタイミングをすっかり逃していた*1ので10月開催のものを受験することになった、という裏話もあった。
試験対策
実はTOPIKに向けた勉強というのはあんまりやってない！ 7月に試験の申し込みをやって、TOPIK用の対策本を買ったけど全く手をつけなかった。試験本番3週間前ぐらいになって、トリリンガルのトミのオンライン模試でTOPIKの過去問 (第96回TOPIKⅠ模試) を解いたのが最初の試験対策になると思う。
模試の点数は以下の通り。
- 듣기 (リスニング): 90/100点
- 읽기 (リーディング) 98/100点
合計で188/200点だった。合格基準*2によると、合計80点以上で1級、140点以上で2級*3に認定される。あれ、わりと解けているな？ という感触がこの時点で得られたので、あんまりやることないなと思った。その後、もう2回ぐらい過去問を解いて、記録がちゃんと残ってないけど9割ぐらい取れていたと思う。
買った対策本の模試もやったけど、点数がTOPIKの過去問を解いたときよりぜんぜん低くて、一方で解説を読んでも納得できない感じだったので、あてにしないことにした。いちおう書いておくと、買ったのはこれです。模試1回しか解いてないので音声の順番が違うみたいなレビューと同じ状況は踏み抜いていない気がする……。
![韓国語能力試験TOPIK I 総合対策[第3版]](https://m.media-amazon.com/images/I/51jIJ02QS0L._SL500_.jpg "韓国語能力試験TOPIK I 総合対策[第3版]")
あとは毎日Duolingoをやりつつ、暇なときに韓国語能力試験初級単語4択クイズ 100をぽちぽち解いて、分からなかった単語を覚え直すぐらいしかしてない。
本番当日
朝9時半までに試験会場にいる、という最難関ミッションを無事クリアできた。試験開始前に、日本語での指示の音声がボリューム確認も兼ねて流される、というのをそこで初めて知った。
直前まで単語4択クイズを解いてから試験に臨む。久しぶりにマークシートに向き合ったので、受験番号と問題冊子の偶奇*4のマークを間違えていないか、にいちばん注意を払った。
リーディングの試験中に本人確認が行われるの、まあ分かるけど人によっては集中を削がれてパフォーマンスに影響しそうだなーとも思った。しかし何十人の本人確認を事前に済ませつつ試験を時間通りに始めるとなると、集合時間がもっと早くなって大変になるだろう、というのも想像できる。
リスニングは自信のない問題がぽつぽつありつつも、まあ8割はカタいんじゃないかな～という感触だった。リーディングは自信のない問題が2つぐらいしかなくて、ヘマをしていなければ9割取れているんじゃないか、という感じで、解き終わってから試験時間が20分ぐらい余って暇だった。
振り返り
リスニングで流れる音声の速さがDuolingoよりも遅かったり、Duolingoで死ぬほど見た基礎語彙が分かれば解けるような問題が多かったりで、思ったよりも難易度が高くないな、というのが全体的な感想だった。2年もDuolingoやり続ける前のどっかで受験するぐらいがちょうどよかったんだろう。デイリーリフレッシュに突入した時点とかちょうどよさそう。
おそらくTOEICぶりにマークシートで外国語の試験を受ける、というのができてなかなか楽しかった。限られた時間で問題文を読み解いて主張に合うものを選んだり、文意が通るように4つの文を並べ替えたり、センター試験ってこういう感じだったっけ、というのを思い出しながらやっていた。派手にマークミスしていなければいけると思っているけど、問題用紙も回収されているので正確に振り返ることはもはや困難になっている。
まとめ・今後の展望
TOPIK Iを受験して、手応え的にはいけてそう、Duolingoを毎日ぽちぽち続けてブルアカの二次創作を読んでたらリーディングについては難しくなく感じた、というのが総評だった。
次回は成績発表でお会いしましょう。更に次回、TOPIK IIの受験でお会いしましょう？？ ライティングの練習をしないといけないし、リスニング・リーディングの難易度も全体的に上がると考えられるので、更に困難になりそう。
2025/12/11 追記
試験結果が出たので記事を書きました。あわせてどうぞ。
TOPIK Iを受験したい人向けっぽい情報
語学の専門家では全くないし、まだ試験結果も出ていないので、この節は素人が経験則でなんか言ってると思って雑に読み流してください。
Duolingoで韓国語を学習している人はそのまま継続して、韓国語コースの終わりが見えてきたらTOPIK Iの受験を検討するとよさそう。TOPIK I 1級だと4割取れていたら合格なので、実際にはもっと早い段階で受験してもいいかもしれない。
TOPIK公式の日本語のYouTubeチャンネルがあるので、ここからTOPIK I向けの動画をかいつまんで見ていくといいと思う。
あとは、最近TOPIK公式のガイドブックが出ていたので、これを読んでもいいかもしれない。本屋でチラッと読んだ感じはよさそうな気がする。著者のイ・ドンジュンさんはTOPIK公式チャンネルに出演している人。
語彙力をつけるのはDuolingoをやっていたらそれなりに付くと思うけど、更にカバレッジを大きくしたいならトリリンガルのトミの100問クイズがなんだかんだでいい気がする。無料だし、TOPIKに頻出だけどDuolingoではカバーされていない単語・表現とかも知れる。
*1:試験のだいたい3ヶ月前に申し込みを行う必要がある
*2:https://www.kref.or.jp/topik/about/overview/
*3:TOPIKは英検・漢検などと異なり、級の数字が大きいほど難易度が高い
*4:受験番号の末尾が偶数か奇数かによって、配られる問題冊子が異なるので、どちらで解答したのかマークする必要がある
VSCodeのターミナルのsticky scrollを無効化する
韓国語を学びはじめて2年経っていた
この記事を書いている時点で、Duolingoの連続日数が764日になっていたので、2年と1ヶ月ぐらい？ 先述した記事にあるように、ブルーアーカイブの二次創作作品に書いてある韓国語が自力で読めると面白いだろう、というのが最初のモチベーションだったと思う。
まだ知らない文法とかいろいろあるけど、それを抜きにしても語彙力とか音から単語を復元する能力とか、瞬発力が足りていないな～と思う局面がけっこうある。使う機会がないとなかなか磨かれないと思う。知ってる単語を含む言葉を投げかけられたときに、その単語と結びつかなくて、あとから振り返ると分かったな～と思ったことが先日の旅行中に何度もあった。旅行記はそのうち出ると思う。
漢字語に対するアンテナはこの1年ぐらいでかなり伸びたと思う。この本を読んで、漢字語の音とハングルの対応規則がちょっと分かって、初見の言葉でもだいたいこういう漢字語になっていそうだなーというのが想像できるようになった。
これは弘大入口のMOM'S TOUCHあたりで見かけた、たぶん「自由意志」って書いてある落書きです。こういうのを見て、漢字語だな～と思えるようになったのが最近の進歩。
あんまりブログに書いていなかったと思うけど、来週TOPIK Iを受けることにしている。過去問を解いた限りだとまあそれなりに得点できそうに見えているけど、どうなることやら、ご期待ください。
そういえば2017年のツイートを発掘したので見てください。この頃はハングルの読み方もまったく分かっていなかったと思う。
韓国語読めなくて，見かける二次創作のうち3割ぐらいはフィーリングで読んでいる気がする
— うたがわきき (@utgwkk) 2017年12月15日
あとこれは誰か知ってる人いたら教えてください。
文末を당で締める文体、「〜したよん」みたいな効能があるのか？ 韓国語の若者言葉に精通してる人がいたら教えてください
— うたがわきき (@utgwkk) 2025年5月5日
Go Conference 2025に参加した #gocon
参加しました。最近はTypeScriptとNext.jsが主戦場になっており、Goを書く頻度が減っています。
例によって、聞いたトークのメモはCosenseにあります。
全体的な感想
testing/synctest
testing/synctestに関するトークを2つ聞きました。内部で何が起こっているのかはなんとなく分かり、testing/synctestのインタフェースも分かりはしたけど、しかし使い方をうまく見極めないと複雑になりすぎて人智を超えるんじゃないかな〜というのが現時点での感想です。実時間sleepする必要があるテストを直ちにラップして実行時間を短くできる、とかは分かりやすく導入しやすそう。あとは単一の非同期処理ライブラリのテストに使うとかがいいのかな。
黒魔術
個人的にはkaramaruさんのトークが優勝です。40分枠あってもよかったと思う。
reflectパッケージだけだとメソッドを実行時に作成できないことはreflectあるあるの1つだったと思うけど、あらゆるズルを駆使することでその制約を乗り越えらえる、ということが分かって勇気づけられました (この勇気をもらうことが本当にいいことなのか、については目をつぶることにします)。
LT
盛り上がっていてこれぞLTじゃん、と思って好意的に受け止めていました。一方で、初めてのLT登壇だったり、コロナ渦におけるリモート中心のコミュニティしか見たことがなかったりすると雰囲気に圧倒されるかもしれない、というのも想像はできそう。
堂々と発表する、5分に収まりきらなくても駆け抜ける、拍手されてもヤジを飛ばされても構わず喋りつづける、とかを意識して登壇してもらえるといいのかな、と個人的には思っています。
タイピング
優勝しました。
最終の結果発表〜🥳
— ばばしお🦕 (@tokyo_887) 2025年9月28日
utgwkkさん、yukukotakiさん、yjingyzさん、おめでとうございます🎉
皆さま2日間ご参加いただきありがとうございました🙏🏼✨
少しでも楽しんでいただけていましたら幸いです😌🫧
今後とも、ファインディをよろしくお願いします！#Findy #gocon pic.twitter.com/rkDJKZ0cN8
トークの倍率とか、トークの色
トークの応募数の正確な数字がどこかに公開されていたと思うけど忘れてしまった……。1人3つまでトークを応募できるようになった影響がどれくらいあるかという感じだけど、かなり倍率が高くて熾烈な争いになっていたと思います。自分も応募したけど落選しました。
追記: 27/244 だったようです。10倍以上?
来年、今のままでいけば500プロポーザルになるのか。
— luccafort@技術書典19 (@luccafort) 2025年9月28日
恐ろしすぎる……。
#gocon pic.twitter.com/Yego9idED4
誰かと話していたと思うのですが、カンファレンスごとに採択されるトークの雰囲気ってけっこう違っていて、そこにスタッフが実現したいことのメッセージが表現されていると思うので、意図を汲みつつ自分が話したいことの価値をアピールする、みたいなことをうまくできるとよさそうですね。
トートバッグ
どこのブースでも、ノベルティとしてトートバッグが配られていなかったので、ノベルティの持ち運びに少し苦戦していました。複数ブースあってもいいので、次回はどこかのブースでトートバッグが配られていると助かりそうです。
Ask the Speaker・Official Party・二次会・三次会でいろいろ話せて、個人的にはホクホクした状態で終えられたと思っています。来年も参加したいですね。
Kaigi on Rails 2025 1日目に参加した #kaigionrails
2日目は別のイベント (Go Conference 2025) に被ってしまったので、1日目だけの参加でした。1年は365〜366日しかないのでそういうこともありますね。
聞いたトークのメモはCosenseにだいたいあります。特におもしろいと思ったトークについて個別に取り上げてみます。
- ハッピーパスに集中しよう、最適なコードの配置が分かるまでは「最もシンプルで、うまくいく」場所に置こう、ということが実践されている
- 最初から作り込みすぎずに全容が分かってきてからコードを動かす、というスタイルは自分も好き
- 一方で、忙しさが高まりすぎると全容が分かってもコードを動かす暇を作りづらい、みたいな構造になりやすい (なったことがある) のも気になる
- フットワーク軽く動くのと、チーム全体の開発をブロックしないことをうまく両立できるようにありたいね
- 普段はReactやNext.jsを使いまくっていて、Hotwireはまったく触っていない、という立場の上で……
- 高度なUIを作るときの本質的な難しさにうまく向き合えるアーキテクチャを実践しよう、という話だと理解した
- 状態管理をうまくやってスパゲティ化しないようにする、とか
- ReactだろうがHotwireだろうが変わらなさそう
- Railsには、リクエストのHTTPメソッドに応じて参照するDBをprimary/repliceで切り替える機能がある
- read/write splitting
- 一方で、GraphQL APIだと標準のread/write splitting機能が使えない
- 参照系・更新系いずれもHTTP POSTだから
- graphql-rubyのフックポイントで参照先DBを切り替える機能を実装した
- query (HTTP GET相当) で更新しているクエリはDB切り替えの対象外とできるようにした
- GraphQL APIをGETで叩けるようにして、クエリ文字列はpersisted queryでハッシュだけ送れるようにすると、標準機能に乗っかれるかも? とか登壇後に議論させていただけてよかった
- persisted query用のクライアント・サーバーの実装も要るし、トレードオフがありそう
この件改めて考え直してみたが、フィールド名が変わったり削除されたり追加されたりした時に、HTTPキャッシュなどが絡むと、そのフィールドある(ない)ことにしたFEのリリースとキャッシュサイクルも関係するのも面倒だな〜という問題もありそう https://t.co/eItNhYcJmL
— Koya Masuda (@koxya) 2025年9月26日
- Server-Sent Eventsのことはある程度知ってたけど、けっこう知らない仕様があった
- Last-Event-IDとか
- async gemの採用事例いろいろ見れておもしろかった
- 長時間にわたる常時接続だとデプロイ時に接続が切れたときのハンドリングとかが要る? というのがちょっとずつ気になってきた
- SSEのLast-Event-IDヘッダはこのあたりを意識した仕様なのかな
来年はもう日程が分かっているし、なんとかして両日参加したいな〜〜。
iPhone 17 Pro買った
iPhone 15 Proを買ってから2年ぐらい経っててちょうどいいので。マシンスペック的には困ってなかったと思うけど、新しい方がアガると思う。
