長期休暇などでコードフリーズするときにデフォルトブランチへのマージを防ぐ方法ってないのかなと以前から気になっていたのです
調べて見たところ、以下のスレッドが見つかりました。
Branch Protection にある Lock branch という機能で対象ブランチに対する一切の変更が防げるようです。
手持ちの自由になるリポジトリで試して見たところ、マージ可能なPRがマージできなくなりました。一方で、管理者権限を持っているからなのか、もしくは他のbranch protectionのオプションでそうなっているのか、チェックボックスにチェックを入れればマージできるようです。
障害や不具合による一時的なコードフリーズや年末年始などの長期コードフリーズに活用できそうです。ただし、臨時でマージが必要なケースに備えてコードフリーズ期間の平日でも権限持っている人が誰かしらは勤務しているようにしたり、休日等の障害対応を行う人にも権限を付与するなどの権限管理は必要になりますね。
ブログ更新も久しぶりですがRubyKaigi参加はもっと久しぶりでした。
松本へは新宿から特急あずさで。Rubyist on railsは8時は早すぎ、15時はちょっと遅いかなということで12時の電車で現地へ。到着後松本城や会場を下見しつつ、２時間ほど散歩。コンパクトでカフェもコンビニ等もあるので散歩に苦労しなかったですね。
残念ながらGW明けということで松本ブルワリーの直営店をはじめとして多くの店が休業中。開いていたビアバーが少なかったので散歩中に見つけた店に行くとRubyistがいて、その後も続々と押し寄せてくることに。ある程度飲んでからそれぞれのグループが適宜去っていき、自分達は馬刺しの店へ。結果的に馬刺しはこの日しか食べなかったのでラッキーでした。そしてその店もRubyistやスポンサー絡みなど関係者だらけ。
印象に残ったセッションをピックアップで
この30年を振り返るという話で未来についての話はほとんどなかったものの、型についてはAIに推測させればいいのではというトピックはなかなか興味深かった。開発支援にAIを使うという流れはもう不可避なので、言語レベルでそれを当てにするという発想が今後当たり前になる可能性もなくはなく。とはいえ、人間がやるのは正確性の担保なので型推論（？）をAIに任せるというのは果たしてどうなのかという観点も当然あり。今後どうなりますかね。
GVLがいつどういうタイミングで発生してそれがパフォーマンスにどう影響しているかを実際にツールを使って可視化して判断しましょうという話。GVLでの待ち時間が思ったのと違っていて計測する重要性を改めて感じさせてくれたセッション。
ホテルの大ホールで500名ほどが参加したという話らしく、実際人が多くて数年ぶりに会えた人に挨拶しに行くだけでも見つけるのが大変という状況。RubyKaigi戻って来たんだなぁと感じました。料理も美味しく、ビールも日本酒も地元のものが出て素晴らしいパーティーでした。
オフィシャルパーティーを少し早めに抜けてDay 0でやってなかったBACCAブリューイングへ。気になっていたナイトロのインペリアルスタウトはナイトロ100%ということでハイアルコールだけど非常にマイルドでプリンのような舌触り。バニラアイスにかけるなんていうメニューもあってこちらも美味しそうだったけどお腹いっぱいだったのでトライはせず。ペールエールも自分好みの味で満足。
自分でdebuggerをゼロから作るとどうなるかというお話。基本的な機能はわりとあっさり出来ていたのが驚き。でもこの発表で実装されてたところから先に行くといろいろ大変らしい。
Rubyのテストフレームワークで並列にテストを実施するためのgemとその設計の紹介とtest-queueの現状について。スライド前半でいきなり「金で解決」という話が出ていて「ですよねー」となった。
VScodeでdebug gemを使ってデバッグする話。VScodeの機能をかなり活用出来ていてデバッグが捗りそう。
shioyama/im: Isolated Module Autoloader for Rubyに関するセッション。ちなみに「イム」と読む。無名モジュールを使うことで名前空間を分離（＝グローバルに晒さない）というアプローチ。現実的にどこまで使えるのか、ちょっと試してみたくなった。
二日目キーノート。Ruby 3.1で入ったYJITと3.2での改善、Shopifyにおけるパフォーマンス改善から始まり、そこに至るまでのMaximeさんの経歴が語られました。BBVの論文でかなり苦労されたようで、その経験を踏まえてかRubyでのYJIT実装については着実にプロジェクトを進めていたようでした。彗星の如くという感じで出てきたYJITですが、その裏にはそんな背景があったんですね。
二日目はMNTSQ（モンテスキュー）さん主催のイベントで松本ブルワリーの直営店へ。会社の読み方を覚えてもらえれば、と言っていたけどわりとみんなすんなり読めていた気がする。松本ビールをたっぷり堪能できました。
社員エンジニアの方とお話したところ、バックエンドエンジニアの数はまだ少ないようで絶賛募集中のようです。社内でエンジニア職以外もGitHub使ってるとか面白い話が聞けました。特にRubyで仕事していて機械学習系のサービス（こちらはPythonらしい）と接点を持ちたい人にはよさそう。
技術的な話よりもRuby4についてMatzが「自分の引退も見据えてRuby4はコミッティーで決めて欲しい」というコメントが一番記憶に残ってます。大事な観点ですよね。
RBSとSorbetのRBIを比較するという話。思った以上に細かいところで違いがあってびっくり。そしてこういうところにリソース突っ込めるShopifyの凄さを改めて感じる。
STORESさんによるアフターパーティー。横丁というからてっきり野外なのかと思ったら室内で密集したフードコートという感じのフロア構成。初日のオフィシャルパーティーとはまた違った雰囲気で楽しめました。
Day 1も来たんだけど、Day 3はアフターパーティーから流れてきた人でわいわいと。しかしここのバーはほんと長いし広い。そもそもどうやって店に入れたのかレベル。結局、お店の人に聞くのを忘れてどうしたのかはわからないまま。
会期中から評判のよかった麺匠 佐蔵をブランチ代わりに。優しい味の味噌ラーメンでうまい。
食後はまたしばらく市内を散策。初日も感じたけど、コンパクトでなかなかおしゃれな街。市立博物館は移転中ということでやってなかったけど、一度じっくり博物館で歴史とか見たいなという気分になってあずさで帰路へ。
前回の津はオンライン参加だったので、ほんと久々のオフラインRubyKaigiでした。やっぱり実際に人とあって話するとモチベーションあがったりしますね。あとオンラインではなかなか聞けない業界情報なんかも聞けるのはフリーランスの身にはありがたい。
それにしても1200人ほどの参加者があったようで、ほんと大盛況でした。スポンサーブースはずっと人がいたんじゃなかろうか。スタッフの皆さん、お疲れ様でした。すばらしいイベントをありがとうございます。
IIJ mioからpovoにMNP（eSIM）しようとして失敗したっぽいです。
IIJ mioで使っているメイン回線をpovoでeSIM使ってMNPしたい。端末はPixel 4a 5G。
新規向けはeSIMプロファイルをダウンロードして終わり。
■新規契約のお客さま （1） まず、povoで使用するスマートフォン以外の端末を使って、以下URLへアクセスし、eSIMプロファイルをダウンロードしてください。 https://my.au.com/rd/esim_dl （2） 次に、povoで使用するスマートフォンをWi-Fiに接続したうえで以下手順にて設定を完了させてください。 <初期設定手順URL> https://povo.au.com/support/guide/esim/
MNP向けは新規契約手続き前にpovoへの切り替え手続きが必要。
■MNP新規のお客さま （1） まず、MNP予約番号の有効期限内に、povoへの切り替えをしてください。 お手続きには以下が必要です。 ・ご注文番号 ・注文履歴確認用パスワード ・切替予定のお電話番号 https://onlineshop.au.com/common/CSfOrderHistoryDivergence.jsp （2） 次に、povoで使用するスマートフォン以外の端末を使って、以下URLへアクセスし、eSIMプロファイルをダウンロードしてください。 https://my.au.com/rd/esim_dl （3） 最後に、povoで使用するスマートフォンをWi-Fiに接続したうえで、以下手順にて設定を完了させてください。 https://povo.au.com/support/guide/esim/
届いたメールをちゃんと最後まで読まず、上にあった新規契約向けの手続きをやってしまったところ、新規回線として登録になってしまいました。自分が確認した範囲では一度登録されちゃうとMNP切り替え作業はできないようで、注文番号と注文履歴確認用パスワードを入力しても手続きできなくなってました。
povo新規回線（eSIM）とIIJ mio（nano SIM）の二枚体制です。元々ahamoにしようと思っていたんですが、ahamoからSIM届くの時間かかりそうだしeSIMにすればSIMカード要らなくなっていいかなという理由でpovoにしていたので、そのうちahamoがeSIM対応したらahamoにMNPしようと考えてます。IIJ mioの分だけ別に料金かかるのが癪ですが。
少なくとも自分が試した時点では、povoのサポートは存在しないレベルです。ウェブサイトにはチャットで質問できるとありますが、FAQの内容を元に返すだけのボットで有人問い合わせ窓口には繋いでくれないようです。ネットのみで対応というのは良いとしても、チャット・メールなどでオペレーターに確認できないというのはサポート無しと言われても仕方ないような気がします。はっきりいってMVNO以下のサポート力じゃないでしょうか。
ちなみにMNP申請はau shop扱いだったのでau shopの公式LINEアカウントに何かしらMNP出来る方法がないか問い合わせしたんですが、povoは対応外という返答でした。ツイッターなどで検索してみると、注文履歴確認用パスワードを忘れたなどでauのカスタマーサポートに電話してなんとかしてもらった方がいるようです。どうしても困ったらなりふり構わずau側のカスタマーサポートに電話かけまくるしかないのでしょうか。
素人考えだとauがpovo向けのサポート部隊を作ればそれで済むと思うのですが、それが出来てない理由はなんなんでしょうね。ahamoは当初からネット上でサポートを提供していたようですし（混雑してたっぽいけど）、店頭での登録サポートもサービスインしているので、今回のMNOによる格安プラン導入では明らかに動きが良いように見えます。
2021/03/29から2021/04/04の間に気になったニュースのまとめ。
確かにキャッシュを最後に返している箇所がやるほうが合理的といえば合理的ですね。
東京リージョンでプロダクションを動かしているのであれば、とりあえずバックアップだけ大阪リージョンに置いておく、という運用はありですね。
顧客が選んだ商品の認識率は95％で、正しく認識できない5％は「商品を人から人に渡す、商品を持った子どもを親が抱き上げるといったときに発生している」
あー、確かにこれは難しそう。
無人決済システムの導入の影響は人と接触しないことや省人化だけではなく、ファミリーマートの出店方針にも変化をもたらす。ファミリーマートの狩野智宏執行役員は「レジ業務の削減など少ない人数で運営できるので、従来のコンビニよりも狭い商圏、いわゆるマイクロマーケットへ進出できる」という。
なるほど。。
先行エントリーキャンペーンのポイント付与は4/15から始まって移行組が一斉に申し込みするわけですが、大丈夫なんですかね。。
「世界的な半導体不足が生じたのは、不確定要素が増えてオーバーブッキング(重複発注)が増えているためで、特に28nmなどの成熟プロセスは、需要よりも全世界の生産能力の方が上回っている」と述べたと、複数の台湾メディアが報じている。
なかなか衝撃的な発言ですが、記事によるとコロナ禍で各社が在庫を積み上げた後、さらに重複発注をかけたので逼迫したように見える要素もある、と。ということは実需以上にオーダーが来ているということで、どこかで発注が大量キャンセルされる、もしくは発注側で必要以上の在庫積み上がりが発生する可能性があるということですね。半導体株の先行きに影響しそうな話です。
大阪ローカルリージョンを開設した後、関西圏を中心とした西日本、そして愛知県の顧客から「大阪リージョンをDR用途ではなく、フルリージョンとして使いたい」との要望がありました。愛知県とその周辺だけでも、欧州の1国並みの経済規模があります。
なんとなくどこかの自動車関連企業グループの名前が浮かんできますね。
従来のように開発を請け負うだけでなく、内製化や自前保守を指向する企業の支援に取り組む。例えば顧客側の開発人材を育成するトレーニングやコーチング、開発ガイドラインの作成支援などだ。このほか、CTCから開発人材を派遣して開発の立ち上げを支援するサービスなども提供する。
ノーコードやローコードで早期にシステムを立ち上げて内製化を支援する、というのは利益相反も発生しづらくてSIerの今後としてはいい選択肢のひとつのように感じます。
いやぁ、これはメガテンやペルソナシリーズの続編が捗りそうですね。
2021/03/22から2021/03/28の間に気になったけどそれほど話題になってなさそうなニュースのまとめ
思いっきり話題になっているニュースですが、これまでTSMCなどのニュースも継続的にピックしているので、このニュース紹介ではやはり避けられないところですね。以下の記事は本件が地政学リスクに影響しているであろう点について細かく書いてあります。
すでにAppleにも声をかけているということですから、本気度合いが窺えますね。
同氏は「なぜなら、現在アップルは台湾セミコンダクター（TSMC）に完全に依存しているからです」として、台湾TSMCにiPhone用のAシリーズチップやM1チップ等の製造を頼り切っており、代替生産企業のない危うさを指摘しています。
代替生産かどうかと書いてますが、本音はこちらですね。
中国による台湾侵攻の脅威は「ほとんどの人が考えているよりも差し迫っている」と警鐘を鳴らしたばかりであり、アップルとしても台湾TSMCに依存しすぎるリスクは減らしたいはず。
むしろ米政府とインテルの間でやりとりがあったと考えるくらいのほうがわかりやすいかもしれません。大口顧客を抱えないことには製造工場作っても償却できませんからね。10年先を見据えたリスクヘッジということになりそうですが、やはり焦点はちゃんと製造プロセスが立ち上がるかどうか、でしょうか。
第5回の会合では、eSIMの普及促進、SIMロック解除の一層の推進、キャリアメールの「持ち運び」実現、MNP手続きの更なる円滑化について、資料が開示されている。
なぜかはてブでは上記記事（もしくはタイトルだけ）を見て総務省が指示出ししてるような感想を抱いている人が多いようですね。元ネタであるスイッチング円滑化タスクフォースの資料を見ると、各社への事前ヒアリングと総務省が行ったアンケート結果、及び委員からの意見を踏まえて現実的な妥協点に落ち着いたのかなという印象を受けます。
ケータイwatchの記事には書かれていませんでしたが、キャリアメールはIMAP接続となるようです。言ってみれば、メールボックスサービスをドメイン名そのままで他キャリアでも引き続き使えるように切り出すということですね。妥当な落としところだと思います。
導入時期については、「変更元管理方式」におけるシステム開発期間がMNO3社の平均で約1年となっているため、2022年夏頃には実現することが適当とした。
ということで来年夏には可能になるそうですが、ソフトバンクはサービス合併で残っている旧ドメイン（もしかしてvodafoneとか？？）は softbankドメインに移行してから使えるようにするなどの条件はあるようです。ahamoなどの３大キャリア格安プラン登場のときもそうですが、総務省のプランに応じることでむしろキャリアが旧来の制限を外す口実ができる、というのは皮肉といえば皮肉ですね。
内容は言葉から想像つく範囲で「えぇ。。」という感じですね。このIT介護という言葉、自分は初めて聞いたと思うんですが、ちょっと前からあるんですね。2019年初等にはすでにあったようです。
create-next-app する度に「同じことやってるけどこれでいいのかな」と思っていたので、比較できる情報が出てきたのはありがたいです。
比較的小規模なソフトウェア開発会社を経営して数年とか10年という経営者の方からの相談で、ベンチャーキャピタルから資金調達をして自社SaaSプロダクトを主軸に転換したいという内容です。
ウェブ系ではここ10年以上「受託より自社サービスやってるところにいきたい」という開発者が多かったですが、ついに経営者からもそんな声が、というところが新しい点でしょうか。
そのほとんどは数人から十数人いる社員と、その家族が十分に幸せに暮らしていけるような、うまく行っている開発会社です。過去の社歴の中でキャッシュアウトや組織上の修羅場もありつつ、現状ではうまく行っていることがほとんど。それでも「モチベーション的につらい」と言う経営者の方が少なくありません。
10年以上前はこのくらいの規模の受託会社だと社長が営業トップ兼ねていてガンガン案件取ってきて下に投げるようなパターンが多かったように記憶しているんですが、最近はそうではないタイプの経営者が増えているんでしょうか。「受託ビジネスから自社SaaSへの転換の難しさ」や「開発者のモチベーション」など、おなじみのトピックも一通りカバーされていていい記事ですね。
余談ですが、1点だけ逆の話をすると、技術的な探究心や向上心が強い場合にSaaSより受託が良いこともあるかもしれません。5年前の開発フレームワークを使い続けるよりも、納品という明確な終わりがあり、次々に新しいプロジェクトに取り組むほうが性に合うというエンジニアも少なくないからです。
これについては必ずしも成り立たないと思ってます。受託現場で最新のフレームワークを使い続けられるとは限らないですし。どちらかというと様々な業種に触れられるというところで、幅広い知的好奇心がある開発者に向いているという印象です。
このうち旅行事業については、航空や宿泊などの単品売りではなく、検索、予約、購入のタビマエから地上交通、体験、買物、決済などのタビナカまでをひとつのサービスとしてシームレスに提供する「TaaS (Travel as a Service)」を推進していく方針だ。
そもそも旅行はサービスだったのでは、とツッコミたくなりますがそこはさておき、以下はなかなか面白そうですね。
具体的には、耕作放棄地の利活用、2拠点居住、おてつたび(働きながら旅するスタートアップ企業の事業）、ワーケーション、地場産品のブランド化およびECによる販路拡大などに取り組む。また、「地方創生のカギは、労働力不足の解消と域内の経済活動活発化」(高橋氏)として、その解決に向けた関係人口の創出にも力を入れてく。
在宅勤務に加えてワーケーションなども話題に上がっている状況で航空会社が働ける拠点などを作っていくのは合理的な判断だと思います。IT業界はリモートワーク率が他業種に比べて高いので、良いサービスが出てくると真っ先に食いついてくるユーザーも多そうです。
近年、テレワークは一般的な働き方のひとつとして社会に浸透。こうした社会背景の変化にともない、ノートPCにも優れたコラボレーション機能が求められている。
ということでスピーカーやカメラなどを強化しているそうです。こういう明確なターゲットがノートPCに出てきたのは軽量・小型化が浸透してからは久しぶりなんじゃないでしょうか。
とはいえ、ノートPCでスピーカーとカメラを強化してもウェブカムと高品質USBマイクには叶わないと思うので方向性は良くても効果はどうなんでしょう。
また、日本は世界平均に比べて下記のような特異な傾向にあることが分かった。
タイトルではストレスと孤独感の話が出ていたんですが、個人的には他の項目の方が面白かったですね。
63％（世界平均は40％）は「コロナ禍でも生産性が変わらない」と回答 35％（世界平均は27％）は仕事中に孤立していると感じている 48％（世界平均は39％）は仕事で疲労を感じており、45％（世界平均は42％）はストレスを感じている 39％（世界平均は41％）は1年以内の転職を検討している
アンケートの対象者がこの記事だけでは分からないのですが、もし本当に「コロナ禍でも生産性が変わらない」が過半数だとすると散々言われている日本の生産性低下は待望のリモートワーク導入（＝足回り的な意味でのDX）が達成されても変化がないのではないかという懸念が生じるところだと思います。反対に一番最後の転職希望は世界平均より2%低いだけとなっていて、日本全体で見た場合は高い数字なんじゃないでしょうか。
4日から一部の医療機関や調剤薬局での試行が始まっており、足元では全国54施設で実施している。従来の保険証の持参を不要とする本格運用の開始を3月下旬中に予定していた。
試行の時期がだいぶギリギリですね。現時点で明らかになったのは良かったんじゃないでしょうか。
関係者によると、試行ではカードをかざしても、本来の保険証に記載された情報と一致しなかった事例があったという。健康保険を運営する企業などの保険者側のデータ入力に誤りがあったことが原因の一つとみられている。
標準フォーマットの定義が甘い、というのは医療ヘルスケア業界あるあるな印象ですね。きっちり定義するには量が膨大で例外事項も多い、ということが原因なんだとは思いますが。
昨年６月の記事なんですが、在宅勤務を会社が強制できるのかということについて人事コンサルタントが書いた記事です。
契約書などに記載のある勤務場所は、会社（勤務先）の所在地になっています。採用募集や労働契約書の勤務場所には本社や支店、工場、店舗といった記載がされているはずです。自宅勤務がある旨の記載がありません。そもそも自宅勤務という単語が規程や契約書のどこにも書いていない場合が多いのです。
なるほど。
強制するのであれば、「自宅勤務を命ずることがある」という記載が必要です。
明示する必要があるということですね。このほか、経費に関する話も記事には出ています。
これDHHが引き金を引いていた件ですね。そのときの記事もGIGAZINEにありました。
データ分析の中で、同様の信用情報を持つ男性と女性に対して、Apple Cardのアプリケーションが同様の結論を出すことも示されました。
DHHの報告は正しかったと。
Apple Cardがクレジットに関して適切にユーザーを判断していないと感じる人に対して、「配偶者の信用情報に依存していたり、配偶者にクレジットカードの使用を許可されているユーザーは、配偶者と同じ信用情報を持っていると誤解しているかもしれません」と呼びかけました。
でも、配偶者の信用情報に依存してるかどうかって調べようがあるんでしょうか。
毎週ちょっと気になったはてブ少なめのマイナーニュースについて軽く掘り下げる記事です。
S3からオブジェクトを取り出すときにLambdaを挟むことが出来るというシンプルな機能ですが、データフォーマットの変換だけでなくデータに含まれる個人情報の削除などいろいろと応用が利きそうです。
2000年ドットバブル直後くらい死ぬ死ぬと言われて久しいシリコンバレーですが、Tim O'reilly が最新の死亡説を発表したようです。
理由として挙げられている項目は以下の４点。
Consumer internet entrepreneurs lack many of the skills needed for the life sciences revolution. Internet regulation is upon us. Climate response is capital intensive, and inherently local. The end of the betting economy.
１点目のライフサイエンス系の話は10年以上前から聞いている話じゃないでしょうか。未だ実現はしていない感じがしますが、現地ではどういう印象なのか気になるところです。
２点目は最近注目のトピックではありますが、規制がかかってもインターネット上で行われる商取引が減少するというわけではないので、大手プラットフォーマーが消えたとしてもその間を埋める企業がどこから生まれるかが重要で、引き続きシリコンバレーはもっともそれに適性がある場所なんじゃないでしょうか。３点目についても様々な分野で脱炭素が進んだとしても製品がコモディティ化していけば自然とビジネスモデルの優位性が増してくるので、ビジネスの実装を出来るところが強いという点ではやはりインターネットビジネスに強い人材が集約されている土地が強いように見えます。
最後の話は単純に世界的に投資マネーが増えていたらそりゃどうしようもないんじゃないでしょうか、という話ですね。
2021年がスタートしたころ、自分が書いた以下のコラムを読み返した。ありがたいことに、2020年のコラムアクセスランキングで7位を獲得していた。
以下の記事ですね。自分もこの記事を以前読んでいましたが、まだ１年前くらいの記事とは思えないくらい、隔絶の感があります。
劇的に状況が変化した理由は、やはりこれに尽きるでしょうか。
家族それぞれが作業をするため、家庭内でPCが足りなくなるというこれまでは考えられないことが起こったのが2020年だった。
薄型軽量のいわゆるモダンPCの売上についても変化が。
現在でも郊外の家電量販店では、大画面で重くHDD、DVDドライブ搭載のPCがなくなったわけではないが、状況は変わりつつあるという。「1年前に29%だったモダンPCの比率は、1年経って42%まで拡大しました」。
記事の後半はGIGAスクール構想に伴う出荷増と今後について。小中学校はこの３月で一通り整備が終わったものの、高校はまだこれからで必ずしも学校がすべて用意するとは限らないんですね。おそらく、遅くとも再来年くらいからは大学に入る学生のICTリテラシーは大きく向上し、その４年後には新卒採用市場にも影響が見えてくるのでしょう。
日本語記事はサマリーだけで、英語記事はより詳細に報じてます。
クリスティーズでは今年、デジタルアート作家ビープルの作品が７０００万ドルで落札され、仮想空間から富を生み出せるということがはっきりした。
これを持って絶好調と書いているようですね。
アート・マーケットによると、アートディーラーの売上高全体に占めるアートフェアの比率は２０１９年には４３％だったが、２０年は２２％にすぎなかった。この半分弱がデジタル開催のフェアで得られた収入だ。
ということで2019年のアートフェアを通常レベルとすればその1/4程度ということなのですが、これも絶好調ということなんでしょうか。
なので、モデルを探している美容師と、モデルをやりたい個人をつなぐマッチングサイトができて、モデハンをほとんどしなくて済む現代の後輩を本当に羨ましく思います。
2013年にはカットモデル探し（モデハン＝モデルハンティング？）用のサービスが出ていたようです。
おそらく業界の人からすれば今更な話なんでしょうが、業界外の自分にはなかなか興味深い事例でした。
これ、いわゆる３府省２ガイドライン的にアウトなんじゃないでしょうか。
一般社団法人モバイル・コンテンツ・フォーラムは、ドコモの格安新料金プラン「ahamo」におけるキャリア決済の維持およびWebコンテンツ強制解約への反対を主張、プレスリリースを打ちました。
元ネタはこちらのようですね（PDF）
https://www.mcf.or.jp/wordpress/wp-content/uploads/2018/10/mcf_release_20210317.pdf
反対の理由は以下とのこと。
最初の１つ目は確かに知らずに解約してしまう消費者の保護という観点で検討の価値はありそうですが、残りの項目も含めて「未だにキャリア変更を想定できてないサービスのほうが微妙なんじゃないのか」と言われたら返答に詰まりそうな主張ですね。
後半のQ&Aのほうが興味深く感じました。
- 格安プランでは、コストダウンのためSPモード課金の廃止が必要では？
- SPモード課金では、決済手数料がドコモに入るため、格安プランのためのコストダウン効果は考えられない。消費者に、格安プランへの変更かコンテンツサービスの解約かという究極の選択を強いることで、国民の携帯電話料金の低廉化が進まないと考える。
決済手数料がドコモに入るのになぜ止めようとしているか、というところをもうちょっと考えたほうがいいのではないでしょうか。
なるほど。それで今回ahamoがターゲットになっているわけですね。とはいえ、コンテンツプロバイダ再度がちょっとあぐらをかきすぎている印象は拭えませんね。それに3月入ってからの発表ということはコンテンツプロバイダ側も直近まで気付いてなかったんじゃないでしょうか。利用者の味方であるなら、もっと早期に一定の規模でキャンペーンなどを打つべきでしたね。
GitHub AcionsのVM上でTailscaleをセットアップすると、Tailscale経由でGitHub ActionsのVMにsshできます。
Tailscaleが何かご存じない方は、過去に記事を書いているのでそちらを参考にしてください。
SSH_APIKEYSSH_PUBKEY という名前でログインに使うsshの公開鍵を登録しておくこと事前準備が出来たら、まずは試してみましょう。GitHub Actionsで以下のようなworkflowを .github/workflows/tailscale.yml みたいな名前で保存してpushします。
うまくいけば sudo tailscale up が走ったところで以下の様な感じで認証用URLが表示されるはずです。ブラウザでそのURLにアクセスしてホストを認証すればOKです。
Run echo "Setting up tailscale ..."
Setting up tailscale ...
To authenticate, visit:
https://login.tailscale.com/a/XXXXXXXXXXXXXXXXX
※たまにこのメッセージが何もログに出ないでずっとこのステップで止まるときがあったので、意味も無くechoを入れてあります。これを入れてからは再発してませんが、たまたまの可能性もあります。
URLを認証すると自動的に先ほどのステップは終了し、次のステップに移行します。以下のようなメッセージがログに出るはずです。
ssh -i /path/to/your_key runner@100.80.196.90
ここはちょっとアドホックにやっていて、 tailscale status コマンドで一番上の行に表示されるIPアドレスを取ってきています。このコマンドは利用しているアカウントに紐付くノードの情報を表示してくれるのですが、最上段にコマンドを実行したホストのアドレスが表示されているように見えるので、head -n1 で取れるという前提で実装してあります。もしかすると１行目にコマンドを実行しているホストのIPが出ないかもしれないので、その場合はTailscaleのadmin画面から追加されたホストのIPを調査しましょう。自分が試した範囲だと fv-azNNN-NNN というホストで登録されてるようです（Nは数値）。
最後は sleep を使って一定時間待ってます。sleepが終了するとjobの実行が終了し、ホストとの接続は切断されます。sshで接続中でも切られるのでご注意を。
接続が完了したら念のためTailscaleのadmin画面で登録を解除したら作業完了です。
GitHub Actionsに限りませんが、新しいことをやろうとするとCIサーバー上にsshしたいときが出てきます。CircleCIはこの機能が標準で用意されていますが、GitHub Actionsにはありません。
今回試してみて初めて知ったのですが、意外にもGitHub ActionsのLinux VMでは最初からsshdが動いていました。おそらくUbuntuをそのままインストールしたからこうなっているんだとは思うのですが、もしかするとGitHubはこの展開を予想していた...？
なので、基本的にやってることは慣れてる人からすれば「ですよねー」という設定ですが、一カ所ハマりどころが。workflowを実行しているユーザーは runner らしいんですが、どうも /home/runner のパーミッションがデフォルトでは755らしく、他の設定が正しくてもsshでログインできません。上記YAMLファイルでコメントアウトしてる部分にありますが、 tail -f /var/log/auth.log してsshd側のメッセージを見てやっと気付きました。
今回はサンプルということで最後はsleep使ってますが、 tail -f などしておくとGitHub Actions側の最長起動時間制限とかに引っかからなければ長く動いてくれるんじゃないでしょうか。
なお、今回のサンプルではURLをクリックするという手動操作が発生していますが、Pre-authentication keys という機能で事前にキーを生成しておけばこの作業は不要になるようです。頻度高く使う場合はこれを生成しておいてSecretsに入れとくと捗るかもしれません。
今回Tailscaleを試そうとしたきっかけは ruby-jpのSlackにある #ci で mxschmitt/action-tmate というactionが紹介されていたからでした。Tailscale使えばtmateのようなサービスを間に挟むより速いでしょうし、そのまま ssh で繋げるというのもメリットです。
VM上でsshdが動いているので ngrok 使っても同様にsshでログインできるんじゃないかという気がしますが、こちらも間にサービスが挟まれるので直接VMと通信できるTailscaleのほうが操作は快適かもしれません。試してないのでわかりませんけど。
