大きくハンドルを回すと長いトンネルであった

さて、25日の夜も更けてまいりました（遅くなってごめんなさ い!）。これはRubyist近況[1] Advent Calendar 2021の25日目のエントリーです。

adventar.org

気づくと全部埋まりましたね、すごい。いくつか、自分も興味深く読みました。

諸々をまとめなきゃ、と思っていた矢先、いい感じの名前のアドベントカレンダーがあったのが参加理由 です。ただ情報量多めで、タイトルも抽象的になってしまいました。それぞれできるだけ短くしましたが、正直、 また1つずつ別エントリーにしたいところ。

まぁ主には、大学院生生活の話です。

TL;DR

この2年弱で、社会人を辞め、学位授与機構で学士の学位を取得し、社会人入試を経て大学院に入学し、 学位授与機構から「機構長緑秀賞」をいただきつつ、今は残り少ない大学院生生活を楽しんでいます。もう終わ るのかよ、という気持ちしかない。

社会人を辞めた (2020年2月)

昨年2月、2011年春から9年弱働いていた職場を辞めました。またそれによって、社会人自体を辞めることにしま した。後述する大学院への入学のためです。社会人生活は人に迷惑もかけたし、振り返って色々ありましたが、 一言で言えば「楽しかった」かな。楽しい人たちと知り合えて、興味深い事業に関われて、とても光栄でした。 お世話になった方々、ありがとうございました。

しかし最後、情勢が情勢だったので、対面でご挨拶どころじゃなかったのは心残りです。

学位授与機構から学位を取得 (2020年2月)

上と前後しますが、学位授与機構という国の機関*1の制度によって、学士（工学）の学位を取得することができました。 健康の問題があって人の何倍もの長〜〜〜い時間がかかりましたが、この時点でようやく大卒相当、ということです。

www.niad.ac.jp

よくがんばりました＞俺。そして少しずつ助けてくださったたくさんの方々、ありがとうございました。

大学院に入学 (2020年4月)

その後の昨年春、大学院に入学して、修士課程の学生になりました。ずっと心残りだった研究生活をしたくなったからです。 社会人入試の制度は使いましたが、入学後は100%フルタイムの、単なるふつうの学生です。入試ではタイミングの問題で 学士の学位（取得見込み）が出願資格として使えず、ひやひやしました。専門はプログラミング言語と その処理系で、大きく見ればコンピューターサイエンスと言われる分野に当たると思います。

入学も一筋縄では行かず色々あったので、また書きたいな。関係・応援してくださった皆様には、本当に感謝し ています。

学位授与機構から「機構長緑秀賞」を受賞 (2020年11月)

大学院入学後の昨年秋、ありがたいことに学位授与機構から機構長緑秀 賞という賞をいただく事ができました（リンク先の写真は、自宅でスーツを着る齋藤氏）。

www.niad.ac.jp

学士学位取得者の中で「生涯学習に努め、特に精励したと認められた者」を 表彰する制度であるそうで、例年3000人以上の学位取得者が いる中から の3人として選んでいただいたのは驚きであり、本当に光栄でした。

学士学位取得の過程とこの受賞については、特に別エントリーを書きたい……ところです。

大学院生活と2年目の今 (2021年)

そういうわけで、昨年・2020年春から今に至るまで、大学院生をやっています。最初は何も分からず、焦りばかり 先行して辛かったのですが、今は研究というものが朧気に見えてきて、楽しくなってきたところです。 というところで、はい残り3ヶ月、というのは、なかなかに辛い。

しんどさ

特に最初はほんと、辛かったですね。確かに去年春ごろは今よりももっとピリピリしてて、誰だって辛かったと思 います。しかし自分はその上で、大きな環境の変化が重なってしまいました。入学式はもちろんなく*2、 大学や他の学生の雰囲気が一切分からないまま、遠隔で授業とゼミが続く日々。 研究室に入れるようになりメンバー全員の顔が分かったのは、制限が緩んだ秋ごろでした。

やってできなかったことではなく、やりたくてもやれなかったことがたくさんあったのは、振り返ればとても悔 しい日々でした。大学院の授業は結局、一度も教室で受けられないまま、単位を取り終わってしまいました。ま た色んな煽りを受けてか、自分も体調不良が長く続いて、本当に悩まされました。

うれしさ

それでも研究室があり、（あまり行けなかったけど）自分の席があり、という、研究のための環境があったのは 本当に幸せでした。優秀でポップカルチャーにも理解のある同期*3・後輩と、 何より良い先生に恵まれました。また大学の制度・チャンスも探して、いくつかは活用できました。

目下のタスクは、来月を目指して修士論文を書く、というところです。え、進捗？ そうですね、手元には象の卵についての記述 だけがありますね……*4。ただある程度はすでに書き溜めた内容があるので、 それをまとめ直す＋αをすれば何とかなるかな、と楽観的に考えています。

孤独につける薬

あとそうそう、Twitterでは似た世代・境遇の（現・元）社会人大学院生が何人もいらっしゃるので、フォローして ます。とても励みになっています、ありがとうございます。そういう方々ともチャンスがあれば、ぜひお話してみたいですね。 （なにせ数人しかいないらしい社会人入試の同期、誰とも面識ないので……）

Rubyとの付き合い

少しになりますが、Rubyistとしての話も。Rubyへの貢献は最近、残念ながら昨年のGSoCしかできて いません。ただ研究の評価・集計では、Rubyが大活躍しています。

評価を助ける友

言語処理系をいじっていると比較的低レイヤーな言語を触るときも多いので、それだけで集計をするのはなかなかめんどくさ いものです。なのでデータを集める時は、まずCSVを吐かせるようにしてます。ちょっと複雑ならYAMLで。いず れもライブラリまでは不要で、printfやstd::cout << ...等々の手書きで十分です。

ここからがRubyの出番。最終的に得たいのは、Gnuplotや何やらのグラフだったり、TeXソースに埋め込む表だっ たりします。これと上記の生データとの間を埋めるのに、Rubyスクリプトを書きまくっています。とはいえ書き まくったとして、それほどの量にはならないし、CSVやYAMLの入出力ライブラリもあるし、簡単な集計なら Enumerable::Statisticsとかも使えるし、と気楽なものです。何も特別なことではないでしょうが、ともかくありがとう、我等が友Ruby。

話題を提供する友

また研究室内の輪講では、自分の担当の時、3.1の目玉機能であるYJITの論文を取り上げさせてもらったりもしました。LBBV、なる ほどなぁ。

www.ruby-lang.org

YJIT: a basic block versioning JIT compiler for CRuby | Proceedings of the 13th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages

drops.dagstuhl.de

3.1.0のリリース、おめでとうございます＆ありがとうございます。

そんな感じで、自分とRubyとの付き合いはまだまだ続きます。

まとめ

この2年弱、自分としては中々の急ハンドルを切った期間でした。しかしそれは意図せず、コロナ禍と重なっ た2年弱でもありました。人生の中でも短くてちょっとがんばる特殊な期間、のつもりで始めたのに、世界全体が トンネルに入ってしまう状況では思うように過ごせず、不本意な気持ちが残る期間にもなってしまいました。

ですが、ハンドルを大きく切ってみた感想として一つ言えるのは、「なんとかなるよ」ということです。あれほ ど厚い壁を感じていた学士学位も、不安だった大学院入学も、やるべきことを具体的に考えてガリガリ進めれば、 できた。ちょっと大変かもしれないけど、できるかできないかで言えば、きっとできます。ググって、電話して、 質問して、調べましょう。なんとかなります。そしてなんとかっているのは、なんとかなるように手伝ってくだ さった方々のおかげでもありました。本当にありがとうございます。

あともう一つ、研究は楽しいですね、ほんと楽しい。新しいことを知るのは楽しいし、新しい提案をする過程は割と自由に やっていい気がしています。業務含め、日常生活で身に染みた実体験や興味を活かして考え直せるのは、社会人を経験 した大学院生ならではの特権だと思います。自分とは異なりますが、今はパートタイムや遠隔での研究も やりやすくなっているのかもしれませんし。どうです、やってみません？いつだって、あなたの立つ場所が ロドスですよ。

さて自分は、象の卵を探しにアマゾンの奥地へと飛ばなければ。 どうも美味しいらしいのですが、さて何味で食べようかな。

*1:正確には「独立行政法人 大 学改革支援・学位授与機構」

*2:一年後・今年の春にやりましたが、リモートでした

*3:もちろん年齢は一回り以上離れている

*4:内部テンプレートにあるダミー文言。オリジナルはこちら

Google Summer of Code 2020: 最終レポート

この夏、自分はGoogle Summer of Code (GSoC) 2020に参加しました。

このポストはその最終レポートで、Googleに提出した英語記事 の和訳です。

公式サイト上の、自分のプロジェクトページはこちら: Brush up RBS and related tools for practical Rails apps

やったこと (TL;DR)

• RBSと関連ツールを実践的なRailsアプリに適用
  • Ruby CIの作業ブランチ
  • MastodonのUserモデルの作業ブランチ
  • 型チェックによってアプリ側のバグを発見
    • ruby/rubyci#196
    • Mastodonにはデットコードがありそう
• ツール群の改善・バグ修正
  • RBS
    • ruby/rbs#294
    • ruby/rbs#299
    • ruby/rbs#300
    • ruby/rbs#301
    • ruby/rbs#302
  • RBS Rails
    • pocke/rbs_rails#12
    • pocke/rbs_rails#28
    • pocke/rbs_rails#29
    • pocke/rbs_rails#30
    • pocke/rbs_rails#32
  • Steep
    • soutaro/steep#158
    • soutaro/steep#173
• RBSの新しいサブコマンド rbs subtract をほぼ実装
  • Comparing ruby:master...tadd:add-subcommand-subtract · ruby/rbs

背景

プロジェクトページの説明に書いた通り、RBSはRuby 3.0の一部としてリリースされようとしています。

RBSは型注釈の言語というだけでなく、それを操作するツールの名前でもあります。RBSは、SquareのリードRubyエンジニアである松本宗太郎さんによって活発に開発されていています。RBS導入に良い記事として、宗太郎さんご自身によるThe State of Ruby 3 Typing があります（ただし英語）。

RBSによって記述される型の情報によって、Rubyistは静的解析の恩恵を受ける事ができます。最近のPythonやTypeScriptも好きなRubyユーザーは、歓迎するでしょう。

ですが、RBSはまだ開発中であり、すぐに実用になるかどうかはやや不透明でした。特にRubyの主なユースケースとして、現実のRailsアプリの型チェックで役立つかどうかは重要な点です。

このお話には、他にも登場人物がいます。RBS RailsとSteepです。

RBS Railsは、Pockeこと桑原仁雄さんによってメンテされています。RBSとRailsをいい感じに繋げるツールで、例えばRails関連のRBSのシグネチャ(*.rbs) を自動生成してくれます。

またSteepは、RBSと同じく松本宗太郎さんによってメンテされていて、RBSシグネチャを元にしたRuby実装 (*.rb) のチェックを実際に行う型チェッカーです。

これで役者が揃いました。RBS、RBS Rails、Steepです。今回の自分のプロジェクトではこれら3つのツールについて、実用性の検証・改善を試みました。

詳細

この夏、自分が行った作業は、だいたい3つに分けられます。

• RBS関連ツールを現実のRailsアプリに適用
• RBS関連ツールの様々な改善
• RBSの新しいサブコマンド rbs subtract の実装（未完）

RBS関連ツールを現実のRailsアプリに適用

以下2つの実用Railsアプリに対して、前述の3ツールを適用しました。

• Ruby CI (型付けした作業ブランチ)
• Mastodon、特にUserモデル (〃)

まずRuby CIは、Rubyの中央リポジトリのテスト結果を定期的にチェック・表示するWebサイトです。小さく、かつ馴染みのあるサイトなので、今回の題材として選びました。

もう一つのMastodonは、Twitterのようなマイクロブログサービスで、セルフホストができる物です。サイズが逆に大きく、他の現実のサービスと同じようによく使われているため、題材としました。

自分はこれら2つのアプリの *.rbs ファイルを書きましたが、Railsアプリとしての共通部分はRBS Railsが自動生成してくれました。またRBSを書きつつ、Steepによる静的解析を試しました。

全体としてはほぼうまく動き、(Mastodonのような)大きなモデルクラスにも有用でした。小さい問題は断続的に見つかりましたが、次の「改善」で書くように、いずれも既に修正済みか報告済みです。またそういった問題による、作業全体への深刻な影響はありませんでした。

これらによって、Railsアプリ開発の場面でも、RBSと関連する既存ツールが十分効果的・実用的であると示せたと思います。

ただ残念ながら、主にチェックできたのはモデルクラスのみで、大きなコードベースを持つMastodonについては一つのモデルしか検証できていません。他の部分、コントローラー・ビュー・ヘルパーなどへの適用は、将来の課題になります。

バグの発見

Steepによる型チェックは、実装側のクラスをほぼ正しいと判定しましたが、このチェックによって2つのバグがアプリ側に見つかりました。

Ruby CIには500エラーになるバグがありました。これは nil チェックが足りなかったためで、自分のPRによって既に修正済みです。

MastodonのUserモデルには reset_password! メソッドがありますが、これはどうもデッドコードで、依存するgemを含めて他の場所からは呼ばれていないように見えました。これはSteepが、「このメソッド内のsuper がNoMethodError を起こすよ」と教えてくれたために気づいた物です。たしかに、(Mastodonが利用する)Deviseは、同名のメソッドを4年前に廃止しているようです。しかし更に注意深いチェックが必要そうなため、その部分を削除するPRは今後の課題です。

RBS関連ツールの様々な改善

ツールたちをRailsアプリに適用している間に、たくさんの問題が見つかりました。それらはすべて、上流リポジトリに報告済みです。

• RBS
  • ruby/rbs#294 ドキュメントのバグ修正
  • ruby/rbs#299require_relative を正しく使うように振る舞いを変更
  • ruby/rbs#300 古い名前のお掃除
  • ruby/rbs#301 無名モジュールに関連した、プロトタイプファイル生成での問題をIssueとして登録 (#302で修正)
  • ruby/rbs#302 無名クラス・モジュールの問題を追加で修正
• RBS Rails
  • pocke/rbs_rails#12 対応するAR内のレコードタイプを追加
  • pocke/rbs_rails#28 inet 型サポートの追加
  • pocke/rbs_rails#29 AR::Relation#last のシグネチャ追記
  • pocke/rbs_rails#30 Rails.env のシグネチャ追記
  • pocke/rbs_rails#32 ARが自動的に定義するメソッドのシグネチャを追加
• Steep
  • soutaro/steep#158 単発での型チェックの問題をIssue登録 (#171で修正)
  • soutaro/steep#173 steep watch 終了の高速化

これらの報告はすべて、現実のRailsアプリでの適用実験に基づいた物なので、改善によって更にRBSが実用的になったと考えています。

RBSの新しいサブコマンド rbs subtract の実装（未完）

プロジェクトの最後に、新しいRBSコマンドの機能 rbs subtract を実装しようとしました。残念ながらこれは完成しておらず、マージもまだですが、これによってRBSを伴うRuby開発のワークフローが改善すると思っています。

どうして必要？

まず、ゼロからRBSシグネチャを書くのは大変です。そのためRBSは rbs prototype コマンドを提供していて、プロトタイプとなるファイルを生成する事ができます。

実装 → プロトタイプのRBS

ですがこのコマンドは現在、RBSを書き始める最初に使われる事を意図していて、ファイルの差分を検知する機能はありません。また簡単に作れるとはいえ、自動生成はいつも完全とは限りません。多くの場合、手動修正が必要になります。

実装 → プロトタイプのRBS → 修正済みRBS

さて、開発が進めば実装ファイルが変化します。RBSファイル側にも新しく変更が必要になりますが、これには先程のプロトタイプ生成を使う事ができます。

実装 → プロトタイプのRBS → 修正済みRBS (B)
　 ＼→ 新しい実装 → 新しいプロトタイプのRBS (A)

ここで問題が起こります。開発者は、新しいRBS (ここでは A とします) を生成できますが、先程も書いた通り、これには手動修正が必要になります。一方、修正済みのRBS (B とします) は既に古くなっています。

つまりこのままだと、開発者は実装を変更をする度に、A と B の手動マージを毎回、行わなければいけません。

しかし現実には、B に比べて新しい A にクラスやメソッドが増える事が多いでしょう。理想的には、この増えた差分だけが手動修正の対象になるべきですし、残りの既存部分にはBをそのまま使えるはずです。

そういうわけで、 A - B が必要になります。ここで rbs subtract の出番です。

rbs subtract は文字通り、シグネチャを引き算するコマンドです。引数としてAに対応するファイルを渡すと、既存のシグネチャには存在せずAのみに存在するメソッド・定数などを出力します。実際の作業の流れは、こういう感じになるでしょう。

1. 最初のプロトタイプ sig/app.rbs を生成した後、修正して正しい型を埋める
   • $ rbs prototype rb app.rb >sig/app.rbs
2. 実装ファイル app.rb が更新される
3. 不完全だけれど新しい実装に対応するファイル app-new.rbs を生成
   • $ rbs prototype rb app.rb > app-new.rbs
4. 差分を取るために引き算・追記
   • $ rbs subtract app-new.rbs >> sig/app.rbs
5. これで後は、 sig/app.rbs に追加された差分だけを修正すればOK!

このようにして、実装に追加された差分のみを自動生成できれば、開発中にRBSシグネチャを手書きするコストはかなり下がります。

逆に、実装の内容が減ったケースについては将来の課題です。しかしこの場合、必要なチェックがなくなったり、間違ったチェックがされたりはしないため、実際の不都合は小さい物だと考えています。

実装の詳細

これが進行中の作業ブランチです。まず、新旧シグネチャ間のASTレベルでの重複を除去するため、 RBS::AST::DuplicationFilter を追加しています。また、新しいCLIのサブコマンドなので、 cli.rb 中に run_subtract メソッドを追加し、その中で先程の DuplicationFilter を使っています。

一番の難所はASTのすべてのパターンをカバーするところだと思いますが、その部分はほぼできています。

この機能全体を実現するため、もう少しだけがんばる予定です。

結論

RBSツール類を、RubyCIとMastodonのような実用Railsアプリに適用しました。RBSの実用性を示しただけでなく、実際のバグを実装(アプリ)側に見つけました。

この実験を元にして、RBSと関連ツールに複数の改善と修正を行いました。RBSは十分、実用的なレベルに達していると思います。

また新しいRBSのサブコマンド rbs subtract の実装をほぼ行いました。これが実現すれば、開発のワークフローはより効率的になると思います。完成と上流へのマージは将来のタスクです。

謝辞

まずは自分のメンター、遠藤侑介さんに感謝します。Rubyの深い知識があり、型プロファイラの実装者でもある遠藤さんと作業できたのは、とても心強い事でした。

また、松本宗太郎さんと桑原仁雄さん(Pockeさん)の継続的なサポートにも感謝します。この4人での毎週のZoomミーティングは本当にありがたい存在で、特にお二人のRBS・Steep・RBS Railsのメンテナとしてのアドバイスは有用でした。また笹田耕一さんを始め、様々なコメントを下さったRubyコミッター・Rubyistの皆さんにも感謝しています。

加えて、Ruby OrganizationとしてGSoCに関係して下さった皆さん、特に全体を取りまとめていたHiren Mistry氏に感謝します。週に一度の英語Zoomミーティングでは、たくさんのポジティブなアドバイスと、時々訪れるゲストからの励ましの言葉をもらえました。英会話がまったく得意でない自分は最初、緊張しましたが、Hirenさんや他のメンターの方々はいつも親切で優しく、前向きな雰囲気が保たれているミーティングでした。

最後に、Google Summer of Codeを主催して下さったGoogle社、特に運営に携わった方々に感謝します。フルタイムの担当メンバーがわずか数名の状況で、他の複数のプロジェクトも掛け持ちする中、世界中に散らばった学生とやり取りを続けるのはとても大変だったと想像します。社会貢献でもあるGSoCのようなプロジェクトが、今後も継続される事を願っています。

デルアンバサダープログラム(2020): 昔のXPS 13の問題は改善しているか？

XPS 13を買うと決めて何箇所かで公言したところ、旧モデルのXPS 13を使っているujihisaさんから、 ruby-jp Slackでありがたい情報をいくつかいただきました。中でも「使っててしんどい点」を教えてもらえたのは、普段遣いを 検討してる自分にとってとてもありがたい事でした。

さてその、しんどい点7つについて、2020年現在最新のNew XPS 13 (9300)では解決しているのか・許容範囲なの か？というのを具体的に考えてみました。ただ残念ながら、使ってるアプリの違いで、アプリ固有の部分は一部、 調べられていません。

比較対象

今回の最新モデルと比べることになるのは2015年モデルのXPS 13 3K、です*1。当時の記事はこちら。

1. 本体のコイル鳴きがうるさい

自分には全く気になりませんでした。改善されているのだと思います。

ちょっと別の話になりますが、現状自分が使っているX260に比べたファンの音は、相対的に大きく感じました。 しかし「がんばってる時にそれが分かる」程度で、そこまで大きな音ではなく、いわゆる「コイル鳴き」のような 不快な高い音はほぼ感じませんでした。

2. たまにWi-Fiが切れる上、再起動しないと治らない

これも問題ありませんでした。

最初の記事で書いたとおり、 firmware-iwlwifi を導入する必要があるのはWi-Fi関係でつまずく点かもしれません。しかし一度入れた後は、何も 問題なく動いていました。（最新のファームウェアをゴニョゴニョしていたらむしろ悪化した）

3. ディスプレイの縁が狭い上にタッチパネルなので、開いたり閉じたりするときにタッチしてしまう

「例えば、端を触った時、意図せずウインドウ閉じたりしてしまう」ということでした。特に今のモデルでは ベゼルの狭さが強調されているので、確かにあり得そうな話です。

ですが自分は案外、この機会に遭遇しませんでした。自分がタッチパネルをほとんど使っていなかった、と いうのもあるのですが、それ以上に、PCを開く時、内側である画面側を触る事がなかったように感じています。

それで本体をよ〜く見てみたのですが、形に秘密がある気がしています。この写真で分かるでしょうか？

これは今回のモニター機を真横、開く辺を正面と考えるとその右側から撮った写真。上蓋のディスプレイ側、つまり開く時に触る側が、横から見て鋭角になっています。

つまり、触ってPCを開く時、指はこんな角度で触ります。雑イラストさーせん。*2

銀色の外側に触れるだけで十分に指に引っかかるので、白い内側の角に触る必要がありません。結果として、内 側の縁＝ディスプレイの周辺を触らないので、自分はこの問題にぶつからなかったのではないか、と推測してい ます。

意図的な形状のデザインなのだと思うのですが、そうだとすればこれは「改善された点」と言えるではないでしょ うか。

4. 排気のとこが横向きに床に接してて、液体がくると即死 (実績あり)

いやーほんと、辛い実績……。

これは「現行もやや、当てはまるかも？」という感じ。まず、現行モデルの排気穴は左右でなく、画面向かって奥 の方、遠い方にあります。一方で左右にも穴はありますが、これはどうもスピーカーのようです。

ですので現行、飲み物を置きがちな手前〜左右よりは、ちょっとだけ安全な形になっていそうだと思います。

ただ言葉だけではピンとこないと思うので、ぜひオフィシャルページの「360°で表示」機能を使って、グリグリと 見回して見て下さい。

その他、検証できなかった点

以下の3つはあまり検証できませんでした。

5. タッチパッドのタップの感度がいまいち

自分はタップはあまり使わず、クリック（カチっというまで押す）ばかり使っていたので、これははっきりとは 分かりません。

ただ、ポインタを動かす時や、2本指でのスクロール、fusumaを使った3本指での ブラウザの進む・戻る、などはいずれも、快適にできていました。ですのできっと、問題は解消しているのでは ないかなと思っています。

6. & 7. Chrome絡みの問題（タッチスクリーン不具合とフリーズ）

自分はFirefoxを使っていてChromeは常用していないので、聞いていた以下の2つはやはりきちんと検証できてい ません。

• タッチスクリーンを使うと、ChromeのURLクリックがたまに「リンク先をダウンロード」になってしまう
• Chromeでハードウェアアクセラレータを使うとフリーズして戻らない

これは参考程度ですが、自分でChromiumを少し試した範囲では、いずれの問題も発生しなかった事は書き添えて おきます。

まとめ: 問題なし!

旧モデルの問題点はどれも、現行モデルでは解消されていたか、確認できないものでした。特に最初のコイル鳴 きが辛い時がある、と聞いていましたが、今のモデルでは問題なさそうです。

最後に、ujihisaさんが具体的に困っている点を教えてくださったので、こうして具体的な検証する事ができました。スーパープログラマーujihisaさんに感謝します！

*1:たぶん

*2:伝わる？伝われ！

デルアンバサダープログラム(2020): DAZN雑感

今回のデル アンバサダープログラムでは、モニターしたPCに加えて、DAZNのギフトコード一ヶ月分も付けていただきました。その率直な感想を。

DAZNは良いものな気がする

最初に断ってしまいますと、自分はテレビ、見てません。押し入れの中に追いやったままです。なので、特にスポーツを見る機会も最近、ありませんでした。

ただ、周囲のネット好き全体に比べたら、自分はまだスポーツ好きな方だとは思います。とはいえ熱心に観戦するわけでもないので、自分がDAZNを契約することはおそらく、ないでしょう。

それでも「良いもの」と書いたのは、視聴のスムーズさと、オンデマンドでピンポイントに興味のある映像を見られる体験に感心した点です。

Linux上のFirefoxでも何の問題もなく、というかあっけないくらい簡単に、DAZNで映像を見る事ができました。本当は中継で品質を見たかったのですが、ヨーロッパのサッカーは深夜になってしまうので避けて、去年の鈴鹿でのF1グランプリをちょこっと、あとはeスポーツも見ました。

これが「現代の当たり前」なのかな、とは思いつつ、自分はその当たり前にちょっと驚きました。十分な高画質・高音質の映像が、数クリックですぐ見られる。それが世間でもしマイナーな競技だったとしても、自分のニーズに合わせて何時間でも、ノーカットで見ることができる。

多チャンネルのCS放送が普及し始めた時に、ある意味実現し始めていた事だと思いますが、それがネットを介してより徹底して、視聴者のニーズに寄り添う存在になったんだなと感じました。

正直自分は、日本で展開し始めた時の不安定さとか、ちょっとしつこい宣伝とかで若干、DAZNにネガティブなイメージを持っていました。しかしスポーツが好きな人、とりわけ海外の試合を生で見たい人には、一度検討しないわけには行かないような、必要不可欠な物になっているのだと思います。

つきまとう不安

良いもの、というだけで終わればよかったのですが、このタイミングで先週の報道に触れないわけには行かないでしょう。

DAZN Streaming Service Seeks Exit From UEFA Asia Rights Deal - Bloomberg

ウイルスのせいで、色々なものごとが不安定な状況。試合自体がいつ中断・再開なのか分からない状況で、配信する方も見る方も不安だと思います。ある意味、仕方がない事。そんな中、無観客試合をどうしても見たいファンにとっては、中継はありがたい存在のはずです。

一方で、「独占配信権」という契約スタイルのリスクも考えさせられます。ある会社が配信を独占する＝ある会社が止めたら終わり。もちろんそれによって、よりたくさんのお金が回るというメリットは大きいのでしょう。しかし、手段にこだわらず「どうしても見たい」だけのファンは、不安に付きまとわれ、一社の方針に翻弄され続けます。

映画やアニメなら、複数チャンネルで見られるのが当たり前だと思いますが、スポーツの中継、何とかならないものなのでしょうか……。

デルアンバサダープログラム(2020): Dell XPS 13 (9300) にLinuxを入れる

ありがたいことに、前回から二年後の今年、再度デルアンバサダープログラムに選んでいただく事ができました。 （前回、割と破天荒な内容だったと思うのですが😅）再度選んでいただけて、本当に感謝です。なんていうか、 「自分が当選できてラッキー」というよりも、「自分みたいな（Windows消してLinux入れちゃう）人間でも 選んでくれるDellさん、まじリスペクト」という感想です。

今回も相変わらず、Linuxを入れます。ただ今回は実用上の必要性から、デュアルブートでの導入にしました。

TL;DR

Linuxでも概ね問題なし、かなり快適。自分は買います。

レビューさせていただいた機種

ひと月お借りした機種はこれ。ノートパソコンのNew XPS 13 (9300)です。

今年の春出たばかりの新モデルです。既に各種メディアでは、概ね高評価を得ているようです。例えばこんな感 じ。

自分がモニターを希望したのは、ずばり「そろそろ買いたいから」です。今使ってるThinkPad X260の後継として、 DellのXPS 13シリーズを検討していました。ていうかほぼ決めていました。十分小型軽量で高性能、US配列キーボード も選べるし。

しかし安くはない買い物、事前にチェックできるチャンスがあるならぜひしたい。店頭でちらっと見る以上に、 もし1カ月、日常使いできるならば、いい面に納得するにもあら探しするにも、十二分な時間です。そういうわけで、 XPS体験モニターに応募させていただき、1カ月丸々、メイン機として使わせていただきました。

Linuxインストールの方針

ただ自分が日常で使っているのは、Linuxであって、PCにプリインストールされているWindowsではありません。 一方、ど〜〜〜してもWindowsを使わなければいけない場面 というのもまだ残っています。つまり自分は現行、デュアルブートで生活している身なのです。

それを次のPCでも継続するつもりなので、今回はLinux/Windowsのデュアルブートで動作を体験してみることに しました。（前回に比べて物騒度がちょっとだけ減りますよね、ね。どうでしょうか……）

今回も入れたのはDebianですが、安定版じゃなくてテスト版 (Bullseye)を入れました。後で書きますが、もし安定版を入れた場合にWiFi 関係がうまく動くのか、状況証拠からはちょっと自信がないです。

Linuxインストール!

そういうわけで本題のLinuxインストール法です。結論から書くと、やはりネットの情報を参考にしまくれば 大きな落とし穴もなく、うまく行きました。

特に、一番まとまってた情報源として、Arch Linuxの当該モデル向けWikiページを挙 げておきます。ほんとありがたかった。まず一通り、目を通してから作業するのがおすすめです。

1. もちろん回復ドライブを作る

今回はWindows消すつもりないにせよ、怖いよね。というわけで当然初手で、Windows回復ドライブをUSBメモリ に作ります。

2. UEFI(BIOS)設定

前回よりもちょっと多めになりました。

セキュアブートを切る

メジャーなディストリビューションならば、最近は切らなくても起動できるらしいのですが、特に大きなメリッ トもない上にトラブルの原因にもなるみたいなので、セキュアブートは切ります。

SATAコントローラをRAID→AHCIにする……のと、その前に

これも前回と同じですね。RAIDになってるのをAHCIに切り替えます。最初忘れてて、インストーラ画面にSSDが 出てこなくて焦った。

……の前に、耳寄りな情報なのですが、どうも上記を切り替える場合、Windowsは事前操作をしないと再インストールが 必要になる場合がある、らしいです（流石に確かめていないです）。これは ググって出てきたブログエントリ の単なる受け売りですが、自分は以下の手順で確かにうまく行き、Windows再インストールをせずに済みました。

1. SATAコントローラを切り替える前に、まずWindowsを起動
2. コマンドプロンプトを管理者として起動
3. bcdedit /set {current} safeboot minimal を実行
4. 再起動してUEFIセットアップ画面に
5. おもむろにRAID→AHCIに切り替え
6. 設定を保存して再起動。するとWindowsがセーフモードで起動する
7. 再度、管理者としてコマンドプロンプトを起動
8. bcdedit /deletevalue {current} safeboot を実行
9. もう一度再起動して無事にWindowsが起動すれば終わり

はー。再インストールとか言われると、ちょっと緊張しますね。

細かい設定

さて、あとは細かい設定。スリープからの復帰の時にトラブルになる場合があるらしいので、"Early Logo Display" と "Early Keyboard Backlight" をオフにしときましょう。

3. パーティションの確保

これでUEFIの設定画面とはおさらばして、最後にWindowsの画面です。使い始めたばかりのCドライブに十分に空 きがあるはずなので、それを分割して、新しくできたほうをLinuxで使います。

この時、もちろんGPartedなどのLinuxサイドのソフトでも、NTFSをうまく編集できる はずではありますが、自分はWindowsの「ディスクの管理」からパーティションを切りました。

Windowsのパーティション、Windows側のツールでできる範囲の操作ならば、それが一番無難でリスクが低いと思 います。特に、BitLockerで暗号化してあるパーティションをGPartedで編集すると、不整合が起きてWindowsが 起動したりしなかったりして大変心臓に悪いので、注意しましょう！（検証済）

あ、あと。Linuxインストール時にうっかりWindowsを上書きするのを避けるためにも、パーティションは等分割 しないほうがいいですね。前後をちゃんと見ればいいだけですけれど、サイズが違った方が、どっちがどっちか 分かりやすくて安心です。

4. インストールメディアの準備

ここまでで準備は終わり、いよいよインストールなのですが、今日現在で最新のBullseyeインストー ラであるAlpha 2は、残念ながらうまく動きませんでした。そのため自分は、デイリースナップショットを使いました。

それともう一つ。前回と同じく、non-freeなファームウェアのパッケージがないと、うまくWiFiに繫がりません。 firmware-iwlwifiがそれなので、debファイルを インストールメディア直下か、 /firmware ディレクトリに入れておきましょう。

5. 分割したパーティションにインストール

あとはマウスを使って、グラフィカルなインストーラを適当にポチポチして行くだけです。だけど、パーティショ ン選択の時だけは集中して下さいね、ほんとに。さもないとWindows、消えます。

インストール完了!

お疲れ様でした。いろいろ端折ってますが、こんな感じでインストールはうまく行くはずです。使い始めると、 やることなすこと全部早くて超快適。

当たり前に快適すぎて、スクリーンショット取るの忘れました😢 使い心地については、また別エントリーにでも。

まとめ

細かい注意は必要だったにせよ、Linuxのインストールは概ねスムーズにできました。このエントリーを参考に インストールする人も、各ディストリビューションのページやWiki等、最新の情報をまず探してから作業して 下さいね。

P.S. Dellの中の方へ

Developer Editionの日本発売、ろくろ首になったつもりで待ってます！！１

デルアンバサダープログラム(2018) その2: LinuxからBIOSを上げます

2年ぶりの伏線回収になってしまい😣大変申し訳ない気持ちでいっぱいですが、ともかく、前回のデルアンバサダープログラムで書き残した部分を書いておきます。大まかな記憶しかなくてごめんなさい。

そう、LinuxからBIOSを上げるのを試みました。結果としてはうまく行きました。イヤッホー！

fwupdmgr refresh 後に fwupdmgr upgrade …だったかな。ともかく、LinuxでBIOSを上げるように指示して、リブートしたら更新画面、それが終わったら普通に元のLinuxが立ち上がりました。めでたしめでたし。

これだけのエントリですが、何故書いたかと言うと、これが「前回の」デルアンバサダープログラムになるから、なのでした。（つづく）

GitLab上のプライベートリポジトリgemを使ってNetlifyで静的サイトをビルドする

書きたくて書いてないものは溜まっているけど、書けるところから書くということで。

Netlifyで静的サイトをビルドしてたのですが、自力でジェネレーターを書いていて、そのジェネレーターのソースがGitLab上のプライベートリポジトリに(gemとして)あったわけです。で、どうやってNetlifyからGitLabにアクセスするか。

分かって見ればそんな難しくなかった。

• GitLabの個人設定画面 でトークンを発行・メモ
• Netlifyの各サイト設定画面 → Build & Deploy → Continuous Deployment → Build environment variables に以下を追加
  • Key: BUNDLE_GITLAB__COM (COMの前のアンダースコアは2つ)
  • Value: gitlab-ci-token:<さっきのトークン>
• 最後にこんな感じでGemfileを書いて git push!

git_source(:gitlab) do |repo_name|
  "https://gitlab.com/#{repo_name}.git"
end

gem 'some_private', gitlab: 'yourname/some_private'

まぁNetlifyに限らない小ネタでした。ググっても判然としなかったので、メモも兼ねて。