- Ruby / Rails関連
週刊Railsウォッチ(20200707後編)Rubyで無名structリテラル提案、書籍『AWS認定ソリューションアーキテクト』、21世紀のC言語ほか
こんにちは、hachi8833です。七夕なのに悪天候...
- 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ
- 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄
⚓Ruby
⚓提案: 無名structリテラル
# 同issueより
${a: 1, b: 2}
# 上は以下とほぼ同じ
Struct.new(:a, :b).new(1, 2)
# 同issueより
s1 = ${a: 1, b: 2, c: 3}
s2 = ${a: 1, b: 2, c: 3}
assert s1 == s2
s3 = ${a: 1, c: 3, b: 2}
s4 = ${d: 4}
assert_equal false, s1 == s3
assert_equal false, s1 == s4
つっつきボイス:「Rubyに無名structリテラルがあってもいいですよね」「むしろ今までなかったのが不思議かも」「C言語ならこういうのをよくstructマクロで実現したりしますよね: Rubyはマクロがないからこういうふうに構文で実現する必要がありますけど」「なるほど」
「進行中なのでこれからでしょうね」「ついに$
マークを使うのかな?」「あとStruct
とOpenStruct
のあり方にどう影響するかも気になる」
- Rubyドキュメント: class
OpenStruct
(Ruby 2.7.0 リファレンスマニュアル)
「あとは今後structリテラル#{}
が今のRubyのハッシュリテラル{}
のようにどんどん使われるようになるかどうかでしょうね: リテラルが用意されるとみんな一気に使うようになる傾向があると思うんですよ」
「たしかに、Rubyでハッシュがつい乱用されがちなのは、Rubyのハッシュリテラルが書きやすすぎるからなのかもと思うときがあります」「それそれ、そんな感じでstructリテラル#{}
が導入されたら今よりもStruct
が使われるかもしれませんね」
「そうなると今度はハッシュとstructリテラルをうまく使い分けられなくてわけわからないコードになる可能性もあるかも」「ふむふむ」「RubyでStruct
を使う人はたいていの場合あえて意識的に使っていますし」「特に何も考えないとついハッシュを使っちゃったりしますね😅」
追記(2020/07/07)
記事公開後に以下のツイートにやっと気づきました。
いいですね。そういうのを {|k1:v1, k2:v2|} みたいに作れればというアイディアを温めています。
— Yukihiro Matsumoto (@yukihiro_matz) June 25, 2020
⚓Rubyのエンコーディングエラー(Ruby Weeklyより)
つっつきボイス:「文字エンコーディングはたまにしくじることありますね」「この辺は日本人の方が知見たまってるかも🇯🇵」
「エンコーディングのCompatibilityError
は昔ちょくちょく踏んだけど最近あまり見なくなったかな〜」
# 同記事より: CompatibilityError
string_in_utf8 = "Löve"
string_in_ascii = "Löve".force_encoding('US-ASCII')
string_in_utf8.start_with?(string_in_ascii)
...
# Encoding::CompatibilityError (incompatible character encodings: UTF-8 and US-ASCII)
# == で比較するとraiseされずにfalseが返る
string_in_utf8 = "Löve"
string_in_ascii = "Löve".force_encoding('US-ASCII')
string_in_utf8 == string_in_ascii
=> false
「まあ今でもUTF-8とcp932を行き来するときなんかはエンコーディングエラーに気をつけないといけませんけど」「ですね」
参考: Microsoftコードページ932 - Wikipedia
同記事見出しより:
- エンコーディングをざっくり知る
- エンコーディングエラーとは
Encoding::ConverterNotFoundError
がいつ起きるかと修正方法Encoding::CompatibilityError
がいつ起きるかと修正方法Encoding::UndefinedConversionError
がいつ起きるかと修正方法Encoding::InvalidByteSequenceError
がいつ起きるかと修正方法- エンコーディング問題のもう少し複雑な解決方法
- その他の問題
⚓Ruby実装ごとの互換性レポート(Ruby Weeklyより)
つっつきボイス:「こんな表が掲載されてます↓」
「CRubyの100パーセントおめでとうございます〜🎉」「当然です😆」
「TruffleRubyのスコアが高いですね」「JRubyより高いのが意外だけど、考えてみたらコマンドラインの部分はJRubyが低くても仕方なさそう」
- サイト: Home — JRuby.org
「Opalまである😆」「オパールって何でしたっけ?」「RubyからJSへのトランスパイラですね」
「Artichokeは?」「う、自分で記事書いておいて思い出せない...😅」「ははぁRustで書かれたRubyですか↓」
「そういえばMiniRubyっていうHaskell実装もありますけど↓、さすがにMRIコンパチではなさそうでしたね」「MiniRubyはRubyライクですって」
「ライクって便利な言葉😋」「まあ本気でライクを超えようとしたらCRubyの巨大なparse.yあたりを再現しないといけなくなるので、新しくRubyと同じものを作ろうとすると大変でしょうけど」
参考: parse.y の歩き方 - ワシの Ruby は 4 式まであるぞ -
「CRubyのコードにgccに依存する部分があったりすると別実装で対応が難しいかな?」「たしかに」「メモリ構造まで一致させないと動かないような部分もあるかもしれないので、互換性を100%にするのはかなり難しいか、もしかすると無理な可能性もあるかも🤔」
参考: GNUコンパイラコレクション - Wikipedia
「でもこの記事を見た感じでは思ったより互換性高い🎉」「スゴいですね🎉」
⚓AWS SDK for Ruby V2のメンテナンスモード移行&サポート終了のお知らせ
- 元記事: Maintenance Mode and End of Support Dates Announced for AWS SDK For Ruby V2 | AWS Developer Blog(Ruby Weeklyより)
つっつきボイス:「SDK for Ruby V2も11月に終るのか〜」「SDKのV2まだ使ってる人いるのかな?」「AWS懐かし〜(今GCPの人なので)、以前V2で作りました」
「今回のSDKのV2->V3移行は、API互換さえ保たれていれば問題なく動くでしょうね: サーバー側でdeprecateされたらダメですけど」「ふむふむ」
⚓クラウドSDKのサードパーティgem依存はつらい
「AWS SDK for Rubyってあまり使ったことないんですけど、GCPにもRubyで似たようなことをやれるヤツがあって、たしかそっちは結構破壊的にインターフェイスが変わったりすることがありました😭」「マジで?」
参考: API と Ruby ライブラリ | Google Cloud
「しかもGCPは内部でfaraday gemに依存しているものがあったりして結構困りました」「サードパーティgemが入ってくるんですか!😳」「そこは切り離して欲しい〜😭」「GCPでちょっとRubyを使いたいだけだったのに内部で古いfaradayがロックされてて、その古いfaradayで動くように他のバージョンを下げないといけなくなったりしてつらかった...」
- リポジトリ: lostisland/faraday: Simple, but flexible HTTP client library, with support for multiple backends.
「なのでこの種のAWS SDKとかGCPのとかは、なるべく外部gemに依存しないように作って欲しいです!」「ほんとそうですよね...」「仮にパフォーマンスのためにサードパーティgemが必要だとしても、せめてサードパーティgemなしでも構築する道を用意して欲しいところです🙏」
⚓その他Ruby
言語がRubyで実装がCRubyみたいな使われ方をしてるので、mrubyの場合は、言語がRubyで実装がmruby(またはmruby/c)という感じだと思います。mrubyという別言語ではないつもりなので(若干挙動が違うけど実装依存ということで)
— Yukihiro Matsumoto (@yukihiro_matz) July 2, 2020
[ゼロからわかる Ruby 超入門の著者、五十嵐邦明氏がプログラミングスクール「フィヨルドブートキャンプ」の顧問に就任|合同会社フィヨルドのプレスリリース](https://t.co/bG46NyQsxL)
— _ko1 (@_ko1) July 2, 2020
⚓クラウド/コンテナ/インフラ/Serverless
⚓書籍『AWS認定ソリューションアーキテクト-プロフェッショナル』
つっつきボイス:「この本早速電子書籍で買いましたよ」「きっと買うだろうなと思いました😋」
参考: 【書評】ついにでた!日本初のAWS認定試験プロフェッショナルレベル対応の書籍は、充実した模擬問題と解説を使って学習できます! | Developers.IO
「そういえば自分の取ったAWSソリューションアーキテクト、そろそろ更新の時期だったかな...?」「おぉ、お持ちなんですね」「この資格が日本に上陸した一番最初に取って、たしか2回更新したから5〜6年前かな〜」「いいな〜」「期限は一応2年間ですが、去年3年間に延長されたんだったかな↓」「最近GCPなのでAWSを1年半触ってませ〜ん😅」「今の自分の資格がどうなってるか確認してみよっと(しばらくダッシュボードを操作)」
参考: AWS 認定ソリューションアーキテクト- プロフェッショナル
⚓プロフェッショナル試験とアソシエイト試験の違い
「ちなみにAWSのプロフェッショナル認定は結構難しいです」「どんなのが出るんですか?」「一応サンプル問題のPDF↓は公開されているんですけど、古い問題がずっと更新されないままなんですよ」「ありゃ😆」
参考: PDF AWS-Certified-Solutions-Architect-Professional_Sample-Questions.pdf
「プロフェッショナル認定試験の難しいところは、文章を読み取る力がかなり要求されるところだと思います: 通常のアソシエイトだとそんなに問題文は長くないんですけど、プロフェッショナル試験は問題文も回答選択肢も長いので」「たしかにこれは長いですね...」「長い文章を読んで適切な選択肢を選ばないと合格できないのがプロフェッショナル」
「自分が取得したアソシエイトレベルの試験は『こういう状態のとき、この部分はどうなるか?』みたいな短めの4択問題だったりしますけど、プロフェッショナルは『こういう前提でこうしようとしているけど、その理由はなぜなのか?』とか『開発者に渡すべきポリシーは次のどれか?』みたいな感じでもっと細かい」「なるほど!」
⚓書籍を買ったらすぐ受験すべき
「この本買っちゃおうかな〜?」「興味があるならもちろんどうぞ: ただこの種の書籍はあっという間に陳腐化するので、買ったらすぐに受けるべきです」「あ〜そうでしたか!😳」「AWSの試験問題はどんどん更新されていきますし、AWSには自分も知らないような新しいサービスが続々入ってきたりサービスの内容が変わったりするので、正直昔の本は受験の役に立ちません」「そうなんですね...」
「たとえば最近だとS3のリザーブドインスタンス(RI)周りが大きく変わりましたよね: スタンダードRIの他にコンバーティブルRIというものも登場しましたし、しかも最近はスタンダードRIもインスタンスタイプを変更できるようになったんですよ」「おぉ〜!」「やべ〜AWS知らないおじさんになってしまった😅」「AWSのサービス内容は結構移り変わりが激しいので」
参考: リザーブドインスタンス(RI)- Amazon EC2 | AWS
「なのでこの種の本は出たら即買いして、そして期間を置かずに受験しないとすぐ陳腐化します」「な〜るほど!」「バカ売れする本でもないので改定される可能性はほとんどないでしょうし」「ありそう😆」「日本語で勉強したいなら即買い即受験をおすすめします」
「それにAWSの認定試験は実務を理解してないと合格が難しいですし、扱う実務の範囲も広いので知らないサービスがよく出てきてその分難しいです」「う〜む」
⚓ドメインレジストラ7社比較レビュー
これは良記事。お名前.com の管理画面は本当にクソだと思う / 他3件のコメント https://t.co/ew5pTUhfpe “ドメインレジストラ7社使ってみたので比較レビュー | 純規の暇人趣味ブログ” (18 users) https://t.co/nUj7VOaxiG
— たにみち (@ttanimichi) July 2, 2020
つっつきボイス:「この前お名前.comからGoogleのドメインへの移行作業やりましたけどお名前.com使いづらかった😢」「お名前.comは合併や買収を繰り返しているので、サービスによってDNSの管理主体も機能も画面も違う場合がありますね」「ありゃ😅」(以下延々)
「ちなみに自分はどのドメインレジストラの場合もたいていRoute 53に向けちゃいます」「ふむふむ」「レジストラとDNSサービスは別物なので、まあこういう記事を参考に自分の好きなところを使えばいいと思います☺️」
参考: Amazon Route 53(スケーラブルなドメインネームシステム (DNS))| AWS
「あと最近は防弾ドメインの評判がよくないせいかWHOIS代行をやるところが減ってますけど、お名前.comは一応今もやっていますね」「へ〜」
参考: 海賊版サイト問題の解決を阻む「防弾ホスティング」 その歴史から現在までを読み解く (3/4) - ITmedia NEWS
⚓その他インフラ
複数タスクを並行して進めるのに定評がある僕ですが、さすがにAWSとGCPのタスクは同時に進めるのは無理でした...(頭の中で混ざる)
— sue445 (@sue445) June 18, 2020
⚓言語/ツール/OS/CPU
⚓PHP 8は今年後期に公開予定
union型とattributesが気になりました。
つっつきボイス:「PHPって7が超新しいみたいな印象なのに8が出るのか〜」「PHPはマイナーバージョンでも仕様が大きく変わりますよね」「もう別物ですよね」
「へ〜、PHP 8にJITコンパイラが入るのね」「JITの前はどうやってたんでしょう?」「PHPは5系までしか知りませんが高速化は昔からやってますね: PHP 5あたりからZend Engineのようなものが入ってますし」「なるほど」
参考: 【PHP】PHP と Zend Engine のバージョン - Qiita
「昔はPHPをApacheモジュールで動かすことが多かったけど、最近だとRailsっぽくPHPサーバーで動かすのが多いのかなという印象ありますね」「自分も最近のはわからないけど後ろにApacheモジュールを置いてZendにNginxを置くとかやってました」
参考: モジュール一覧 - Apache HTTP サーバ バージョン 2.4
「PHPサーバーってFPMとかですよね↓」「そういえばDocker HubにもPHPのFPMイメージがあった気がする」「FPM知らなかった😅」「まあRubyで言うWebrickのようなものと思っておけばいいでしょう」
参考: PHP: FastCGI Process Manager (FPM) - Manual
参考: WEBrick - Wikipedia
「自分はApacheモジュールでPHPを使ってた時期が長かったので、FPMで挙動が変わると怖そうで手出ししてませんが」「わかります」「特にサーバー環境変数はApacheを間に挟むかどうかで変わりそうですし」「自分もまだ勇気出ない😆」「まあFPMは既にすごく使われてるので、新しいプロジェクトならFPM版のPHPでいいんじゃないかと思います: 想像ですけど構造的にもFPM版の方がApacheモジュールよりもアプリケーションリソースを上手に使ってくれそうな雰囲気ですし」「FPMのページ見てるけどめっちゃ細かく設定できるみたい👀」
参考: php - Docker Hub
⚓Dependency Injection
依存の注入はコンストラクタでやろう
↓
依存と生成知識がシステム中に散らばる
↓
生成知識をファクトリーで隠蔽しよう
↓
今度はファクトリーがシステム中に散らばる
↓
ファクトリーはシステム中にDIコンテナひとつでよくね?
↓
今度はDI定義がシステム中に散らばる(一番追いにくい形で)— きりみんさん(きりみんちゃんのマネージャー) (@kirimin) July 3, 2020
つっつきボイス:「『生成知識をファクトリーで隠蔽しよう』のあたりから何となくわかる気もする」「こういうのってDI(依存性の注入)って言うんだ知らなかった〜(やってたけど)😅」「いわゆるコンポジット系のパターンで、インターフェイス経由で叩こうみたいなヤツですね」
「DIという概念自体は昔からあってJava方面で使われてたりしたんですけど、DIを当たり前に使おうみたいに全面的にフィーチャーしてたのはたしかC#勢だったかな〜」「へぇ〜」「あくまで印象ですけど、.NET系が割とDIを多用したことでDIが世の中に広まったのかなと」
参考: ASP.NET Core での依存関係の挿入 | Microsoft Docs
「昔はDIにするとガンガン差し替えられるぞみたいな感じで流行ったところがありますけど、最近はどちらかというとテストしやすくするためにDIを使うことが多いと思うので、昔のように同じインターフェイスを差し替えまくることってそんなにないんじゃないかなという気はしますね」「そうかも」「まあファクトリーまで作り始めると散らばりやすくなるでしょうね」
⚓21世紀のC言語
21世紀のC言語勉強会 #1 に参加を申し込みました! https://t.co/XRYRmnLgCU #21世紀のC
— Yukihiro Matsumoto (@yukihiro_matz) July 3, 2020
つっつきボイス:「21世紀にC言語?!」「まあCRubyがC言語で書かれてますし」「そういうことか」「C++ではないんですね?」「C++はもう全然別の言語といってもいいぐらいでしょう」「それもそうですね😆
参考: C++ - Wikipedia
「この勉強会の参加者数の上限が32767人というところにニヤリとしてしまいます😆」「32ビットsigned intの最大値🤣」「あ〜そういうことか🤣」「unsingnedではないと🤣」
参考: signed と unsigned の違い | C言語 | プログラミング│C│シンメトリック公式BLOG
⚓C言語よもやま
「C言語は読めて損はないと思います: がっつり読むまでいかなくても、ヘッダーとか構造体のあたりを読む必要にかられることはたまにありますし」「C言語、昔挫折したんですよね〜: 何かいい本ないかしら?」「自分はLinuxカーネル周りを読んだりデバイスドライバをちょっといじるためにCを覚えましたね: OSのプロセスやスレッド周りを理解するには、Cをがっつり知らなくてもヘッダーや定義を読んで追うぐらいができれば上等だと思います」「ふむふむ」「あとはCの神マクロとか🤣」「神マクロですか🤣」
「この間はてブで見かけたこの辺の記事↓なんかが参考になりますね: CのマクロはLinuxカーネルを追うのに読まざるを得なかったことがあったので、この記事はとてもわかりみがある」「おぉ」
「記事にあるような意味のよくわからないdo
while
とか出てくるんですよ↓」「わ、わからん😅」「ジェネリック的なマクロとか、ビルド設定に応じて何もしないようにするマクロなんかも本当によく出てきますヨ」
/* 同記事より */
#define swap(a, b) \
do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0)
「これ!こういう構造体のコード↓を見たときにLinuxではこうやるのかと驚きましたし」「こ、これは?」「親構造体へのポインタをマクロで取りに行くというヤツで、要はメモリアドレス的にさかのぼって取りに行くだけですけど」「ひえ...😅」
/* 同記事より */
/**
* container_of - cast a member of a structure out to the containing structure
* @ptr: the pointer to the member.
* @type: the type of the container struct this is embedded in.
* @member: the name of the member within the struct.
*
*/
#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
(type *)( (char *)__mptr - offsetof(type,member) );})
「こういうのとかメモリのアラインメントの話とかでCがちょっとわかった気持ちになれましたね」「Javaだと絶対出てこない感じ😆」「C++は知りませんけど、今はさすがにC++でもこんな書き方しないかな〜?」「しない方がよさそう😆」(以下延々)
⚓その他言語
WEB+DB PRESS最新号のTypeScript特集、フロントエンド赤ちゃんでも分かりやすくてとてもよかった
— sue445 (@sue445) July 2, 2020
つっつきボイス:「そういえば最近雑誌買ってないな〜」「買わないんですか?」「読みたいのはたいてい特集なので、特集が別冊になったときに買うことはあります」「今本屋に物理的に行けなくなってますし」「店頭で買うとたまに同じ号を2冊買っちゃうことがあって😭」「まあそれはそれでいいじゃないですか☺️」
「昔はUNIX Magazineを舐めるように読んでましたし、ぷらっとホームの広告なんかもも楽しく読んでましたし」「最近そういうのしなくなったかも」
参考: UNIX magazine 最終号 | スラド
参考: ぷらっとホーム - Wikipedia
「雑誌の特集は強い人が書いているのでやっぱり質が高いですよね👍」「雑誌だとコピペできないのが残念ですけど」「最近はたいてい記事にURL書いてますよ〜😋」「書籍もURL載せてますし」
「自分は老眼なので電子書籍じゃないと買う気がしないんですけど、Kindleで買ったときに残念なのがソースコードの行の隙間がすごく大きくて場所を取っていることとコピペしづらいこと😭」「あ〜あれはやりづらいですね」「組版のエンジニアが頑張ってくれないとどうしようもない」「ソースコードの背景色がなくて本文と区別が面倒なことも多くて😢」
「それなら画像をキャプチャしてOCRでソースを取り出せばよかったりして」「そこまでやりますか😆」「その方が謎の制御文字やら全角文字やらが入らなさそうですし」
⚓その他
⚓京の形見分け
#理研 R-CCSでは、計算科学研究を支援するための寄附金を募集しております。
一定額以上のご寄附をいただいた方には「#京」から取り出したCPUのグッズ等、特典をお送りすることが可能です。
※お申込みの際は「Society5.0・・・」をご指定ください。
▽詳細はこちらhttps://t.co/1c4AhdVglS pic.twitter.com/mAWGmCT4qS— 理研 計算科学研究センター (@RIKEN_RCCS) February 4, 2020
「京」のCPUが届きました。シリアルナンバーは11/1000です。僕の全系計算が走った石かもしれません(「京」は故障率が低いので、その可能性が高い)。こいつを使うために転職しました。思い入れのある石です。 pic.twitter.com/Tn7p0Wts2w
— ロボ太 (@kaityo256) July 2, 2020
私のところにも京だったものの一部が来ました。お疲れ様でした! pic.twitter.com/3QEGxfQkpI
— hikalium (@hikalium) July 2, 2020
つっつきボイス:「スパコン『京』の形見分けというか」「京に寄付できるのはいいですよね」「5万円以上寄付すると京グッズがもらえるけど先着順のみか〜」「寄付自体は今も継続してますけど、グッズはもうおしまいですね」「桐の化粧箱欲しい〜」
「もらいそこなった人がせめてもとマジックで京と書いてみたのを見つけました↓」「こ、これは😆」「気持ちわかる〜」「Pentium Pro?」「Core 2 Duoって書いてるのが見えた」
京のCPU欲しいので作ってみた pic.twitter.com/URqYPrxJlP
— まっくす@とある物理の電子工作T (@Denshi_max) July 2, 2020
ヒートスプレッダに筆ペンで京って書けばそれっぽくなるんやろ... pic.twitter.com/EVr9oUhN3E
— Haswellお兄さん@Bcm2711 (@njm2360) July 2, 2020
「ついでですが、例の富嶽のアーキテクチャが公開されているのを初めて知りました↓」「そうそう、富嶽は公開されてますヨ: ブロック図なんかもしっかり書かれているので興味ある人はどうぞ」「えらいな〜」
CPUそのものをリバースエンジニアリングするのは、不可能ではないと思いますが困難だと思います。そもそも富士通は次世代のスパコン「富岳」のCPUアーキテクチャを積極的に公開しています。https://t.co/TKAh6MbKCZ
— ロボ太 (@kaityo256) July 2, 2020
「よくぞここまで公開しましたね」「まあ国のプロジェクトですし」「このドキュメントだけでも相当金がかかってるはずですし、しかも日本語ですよ🇯🇵」
「個人的にはA64FXという名前がちょっとAthron 64 FXみたいだな〜って😆」「それちょっと思いました😆」「初めて買ったのがAthron 64 FXでした」
「しかしこういうのを見ると、税金を投入する価値があるって思いますね」「まさに国力に直結しますよね」「もちろん技術者としては英語が読めるべきというのはありますしそれももっともなんですけど、英語の壁のせいでこういう技術のパイが広がらなかったらもったいないですし」「日本語だと読みやすさが違いますし」「ファースト1マイルのところで英語の壁でフィルタされてしまうと、『最初は日本語で勉強するけど後から頑張って英語でも読む』みたいな流れも止まってしまいますし」「たしかに」
⚓番外
⚓論文を読む理由
- 元記事: 論文を読む理由 - いつか博士になる人へ
つっつきボイス:「いつもと毛色が違いますけど、自分が論文をちゃんと読む機会がなくて、この記事みたいに『この論文は自分に読まれるために書かれたのでは?』という気持ちにまだなったことがなくて😅」「論文は読めるようになるまでが相当つらいですけど😆」「やっぱり修練が必要なんですよね...」
⚓論文を読めるために必要なこと
「論文を読むことの難しさは『最初のうちは自分が正しく読めているかどうかがなかなかわからない』という点にあると思うんですよ: だからこの記事みたいに他の人と一緒に輪読したりしてそこを確認しながらでないと読むこと自体がなかなかできない」「おぉ」
「まず論文には、受理されるためによく見せようと書いている部分もあったりするので、そういう部分を疑いながら選り分けて読み進められるようになる必要があります」「ふむふむ」
「それから論文には紙面の限界があるので、分野にもよりますが、論文に記載されていない膨大な背景知識も要求されるんですよ: なので論文をまったく読んだことのない人がたまたま最新の論文を目にしたとしてもまず読みきれないと思います」「あ〜なるほど!」
「もちろんまともな論文であれば関連研究としてリファレンスを記載しているので、それも全部追って読めば一応読めるんですけど、1つの論文を読むために相当数のリファレンスも読まないといけなくなります」「ですよね」
「その分野の論文を読み慣れている人なら、その論文の他に後どれだけのリファレンスを読んで頑張らないといけないかが大体想像つくんですけど、読み慣れていない人だとちょうど記事にもあるようにたいてい『浅いうわっつらしか学べない』で終わっちゃう可能性大でしょうね」「う〜む😅」
「今のCOVID-19関連の論文も、それだけ読んでわかるものでもなさそうですね」「まあ医療系の論文はコンピュータ系とかなり文化が違うようですけど」「あぁ、そうかも😳」
「論文のスタイルは分野によって相当違うことがあります: たとえばコンピュータサイエンス(CS)系だと指導教官がlast authorになるという慣習があるんですけど、分野によっては著者名を単にアルファベット順に記載するところもあるそうです」「へぇ〜」
「論文を知らない人向けに補足すると、論文の多くは共同研究なので著者が複数であることが多くて、1番目がfirst author(筆頭著者)と呼ばれるんですけど、CS方面ではその論文に一番コミットした人がfirst authorになるという慣習があります」「へぇ〜」「そして重要なのは、first authorにならないとその人の業績とみなされない文化があること」「そうなんですね...」
「共同研究はいろいろセンシティブなところがあって、たとえばその論文に50%相当で貢献していたとしても、論文のfirst authorになるかどうかで業界での認識が大きく変わります」「なるほど」「共同研究だと論文を複数出して、論文ごとにfirst authorを交代するなどの配慮をすることもよくありますし」
「つまり論文を読むときは分野の文化的背景についても知っておく必要があるわけです🎓: たとえば論文を読み慣れてくるとlast authorを見るだけで『これはあそこの研究室で出している論文かなるほど』みたいな情報が読み取れるようになる」「な〜るほど!」
「CSだとlast authorは指導教官とか研究チームをリードする立場の人がなることが多いので、last authorの経歴を追えばどんな研究をしているかがだいたい見えてきますし、『この研究所はこういう研究に強いんだな』という情報もそこから芋づる式に見えてきます」「そうやって読むんですね」「大学名よりはlast authorの方がそういう情報にたどり着きやすかったりしますね」
「そういったわけで、論文の読み方やそうした文化的背景をがっつり教えてもらう機会がないと、独力で論文を読めるようになるのはかなり難しいと思います」「大学や大学院ってそのための場所ですよね...」「論文を読めるようになりたい人は、たとえば社会人向けの大学院のようなところで学ぶといいんじゃないかと思います」
後編は以上です。
バックナンバー(2020年度第3四半期)
週刊Railsウォッチ(20200706前編)Railsでのマルチテナンシー実装戦略を比較、Railsでサブクエリを使う、URI.parserが非推奨化ほか
今週の主なニュースソース
ソースの表記されていない項目は独自ルート(TwitterやはてブやRSSやruby-jp SlackやRedditなど)です。