  |
はてなキーワード: スタイルシートとは
いやそれはちょっと違う。
日本語Windowsで見た時は游ゴシックが表示に使われるが、Windowsがほっそい游ゴシックをキレイに表示できるレンダリング性能を持ってないせい。
4Kモニタとかなら気にならんだろうが、FHDとかのモニタ使ってるならMacTypeを入れると大分マシになる。
というか多少検索能力に自信のあるWindows使いならみんなMacType使え。
blogとかのスクショでギッザギザのメイリオとか見ると無様すぎて泣けてくるようになる。
MacTypeと、githubにあるbeta2パッチを導入し、
noMeiryoUIでシステムフォントを全部IPA Pゴシック(10pt以上)に変更し、
UEFIでセキュアブートを無効にした上でMacTypeをレジストリモードで運用するといい。
Chromeのショートカットには引数で--disable-directwrite-for-uiを入れ、
Chromeの設定でフォントカスタマイズからデフォルトフォントをIPA PゴないしP明に変え、
Stylusでスタイルシート弄ってメイリオやMSPゴなどをIPA系に置き換えてしまえ。ここで游ゴも置き換えてもいい。細すぎるし。
タスクバーやスタートパネル、UWPアプリなどにはMacTypeやフォント置換は効かないが、これでだいたいフォント描画への不満はなくなる。
ただあらゆるトラブルの元凶になる可能性があるアプリなんで何か起きた時は真っ先にオフにすること。メジャーアプデ時も事前にオフにすること。
とあるジャンルで同人誌を出している。ネット上にも小説を上げている。
ひとつ前に出していたジャンルではあまり売れなかった。全くと言っていいぐらいに売れなかった。ジャンル友達もいないので他人がどれぐらい売れているかなんて聞いたことはない。それでも毎回20部売れれば良いほうだった。
自分の文章が下手だからだと思った。面白くないから読まれないのだと思った。他の同カップリングの書き手は（片手の指ほどもいなかったけれども）パロがうまいとかエロがうまいとかキャッチーな部分がある。自分はそれがない。だから人気が無いのだと思った。
面白い話を書きたくて、映画を見た。小説を読んだ。面白い話の構造を分解してどうして面白いか探ろうとした。売れている物をなるべく見るようにした。
とあるジャンルにハマってそちらで小説を書き始めた。前のジャンルの数十倍は人がいる。比喩ではない。私の書く小説ですら、閲覧数が20倍になったので人がいる。このあたりで他人と比べてしまうのが嫌で、スタイルシートを変更して閲覧数と評価数が見えないようにした。
話の傾向は変わらない。キャッチーさはない。エロも殆どない。面白いパラレルが書けるわけではない。好きなものを好きに書いた。
感想を時折もらえるようになった。人が多いからだろうと思った。
同人誌を書いた。即売会に出た。売れた。前のジャンルと同じ部数を刷ったらすぐに捌けた。
次の即売会では倍にした。捌けた。感想を言いに来てくれた人がいた。
その次の即売会では1.5倍にした。それでも捌けた。今度こそ余ると思っていた。
この時、売り子として友達に入ってもらったお陰で周囲を見る余裕ができた。同じ島で一番人が並んでいた。
書いている話の傾向は変わらない。文章力は上がったとは思えない。何も変わっていないはずだった。なのに売れる本の冊数も10倍近くなった。
ジャンルが変わるとこれだけの人に見てもらえる。怖くなった。今は売れている、反応もある、感想ももらえる。でもこれはジャンルのおかげだ。私自身の文章力や話の構成力、キャラの再現力がどうなのかわからない。傲るのが怖かった。自分の話が上手いんじゃないかと勘違いするのが怖くなった。下駄を履かせてくれるジャンル自体が怖くなった。他の人より売れている、人が来てくれる、嬉しい、そう思ってしまった自分に嫌悪感を持った。
オフをやめた。話は書き続けている。相変わらず閲覧数や評価を見えないようにしている。面白い話を書きたくて映画や小説、漫画を取り込むようにしている。構造分析もするようにしている。好きな子たちが萌えることをしているところを、少しでも面白い話として読みたい。でも他人と較べてしまうのは嫌だ。
オフはまたやらないのですかとたまに訊かれる。オンは1万字程度しか書かない。オフは10万字前後の話を書いていた。長い話を楽しんでもらえるのは嬉しい。そのうちオンライン上に長い話をアップしたい。
ずっと旧ページ使ってて、どうにも窮屈な感じがしたので。
.wrapper-container-inner { box-sizing: border-box; width: 100%; padding: 20px 20px 0; background-image: none; } #right-container { display: none; } #center-container { box-sizing: border-box; padding: 0 0 0 20px; width: calc(100% - 180px); }
右カラムは消した。
あくまで広くしただけ。
幅が広すぎる！って場合は最後の width: calc(100% - 180px); にある100%の値を調整すればいい。
にしても、まさかレイアウトでfloat使ってるとは思わなかった。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
なんで PC 画面がワイド化してんのに、ブコメ表示部がこんなに幅狭いんだよ……。というわけで、お気に入りページのサイドバーとサムネイル消して表示幅を広げるユーザースタイルシート。
.wrapper-container-inner { width: 90%; } #center-container { width: 100%; } #left-container, #right-container, .entry-image-block { display: none; } .wrapper-container-inner.left-column-line { background-image: none; } .entry-title, .entry-block blockquote, .entry-data, .user-comment-meta, .starContainer { display: inline; } .profile-image { width: 1.2em !important; height: 1.2em !important; }
縦線の消し方をブコメで教わりました。ありがとうございます！ ＞ id:ikihaji_kun
要約文を消してさらに縦を圧縮するなら、以下を追加すればよいですね。
.entry-block blockquote { display: none; }
.entry-summary { display: none }
http://anond.hatelabo.jp/20170510110944
Hatelabo::AnonymousDiary
はてな ＞ はてラボ ＞ はてな匿名ダイアリー
ざっくり言いたい人必見！
俺氏、ライブドアニュース風ソースを公開へ
ざっくり言うと
✓ もっとみんなにもざっくり言ってほしい
✓ ソース公開したら良くね
<p class="font-l"><b>Hatelabo::<font color=#4296A5>AnonymousDiary</font></b></p>
<p class="recentitem"></p>
<p class="font-ss">はてな ＞ はてラボ ＞ はてな匿名ダイアリー</p>
<br>
<p class="font-ll"><b>タイトル</b></p>
<p class="font-ss"><font color=#2C4F99>■</font> <font color=#2CAAF0>■</font> yyyy年mm月dd日 hh時mm分</p>
<br>
<br>
<p class="box-bg-gr">ざっくり言うと</p>
<br>
<font color=#4296A5>✓</font> 内容
<br>
<font color=#4296A5>✓</font> 内容
<br>
<font color=#4296A5>✓</font> 内容
<br>
文字が90度回転している場合、日本語特有の縦書きがうまく表示できていない可能性がある
ユーザースタイルシートで以下を指定すれば解決するかも(ユーザースタイルシートとは私が使っているcalibreに存在する機能 他にあるのかは知らない)
*{
-webkit-writing-mode: initial !important;
writing-mode: initial !important;
}
その他の対処1 epubの実体はzipなので拡張子をzipにして解凍、中のHTMLが本体なのでそのHTMLを読む
その他の対処2 表示がおかしいのはzip内のstylesheet.cssが原因なのでエディタで開いて全部削除 再び圧縮しなおして拡張子をepubに戻せば文章だけは読めるようになる EXPLZHが便利
Twitterにおける「@username」に近いかもしれない。
記事中のどこかに記事のURLを入れておけば、その記事に対して自動でトラックバックが飛んで、トラックバックツリーが形成される。
ちなみにURLを記事タイトルの欄に入れるのは慣習にすぎないので遵守する必要はない。
はてな記法と少し違う。
はてなダイアリーでは改行2つで空行だが、
↑このように半角スペースを入れることでも空行が作れるが、
これはHTML的に言えば<br />ではなく<p></p>なので微妙に違う。
改行タグを挿入する（改行記法） - はてなダイアリーのヘルプ
はてな記法と同じ。
[http://anond.hatelabo.jp/:title]と書けばページタイトルが取得されて表示される。→はてな匿名ダイアリー
[http://anond.hatelabo.jp/:title=自由なタイトル]と書くこともできる。→自由なタイトル
リンクを簡単に記述する（http記法、mailto記法） - はてなダイアリーのヘルプ
はてな記法と同じ。
>>
オルフェーヴル (Orfevre）は日本の競走馬。 中央競馬史上7頭目のクラシック三冠馬。おもな勝ち鞍は皐月賞、東京優駿、菊花賞（2011年）、宝塚記念（2012年）、有馬記念（2011年、2013年）。馬名はフランス語で「金細工師」（仏：Orfèvre）。
<<
こう書くと、
オルフェーヴル (Orfevre）は日本の競走馬。 中央競馬史上7頭目のクラシック三冠馬。おもな勝ち鞍は皐月賞、東京優駿、菊花賞（2011年）、宝塚記念（2012年）、有馬記念（2011年、2013年）。馬名はフランス語で「金細工師」（仏：Orfèvre）。
こうなる。
引用ブロックを作る（引用記法） - はてなダイアリーのヘルプ
はてな記法と同じ。
|*馬名|*出生年|*獲得賞金|
こう書くと、
| 馬名 | 出生年 | 獲得賞金 |
|---|---|---|
| オルフェーヴル | 2008年 | 13億4408万円 |
| ディープインパクト | 2002年 | 14億5455万円 |
こうなる。
はてな記法と少し違う。
増田では記事タイトルは別入力なので、「*」ひとつで小見出し記法の扱いになる。
もちろん時刻付き見出し記法は使えない。
小見出しをつける（小見出し記法、小々見出し記法） - はてなダイアリーのヘルプ
記事のタイトルの最初に[今日知った言葉]などと書くとカテゴリーを設定できる。
カテゴリーを設定しておくと、同じカテゴリーの記事を簡単に一覧できる。
使えたり使えなかったりする。
とりあえず、リンクと引用と表組みの使用頻度が高いんじゃないだろうかと思ったので、それ以外の説明は省く。
記事タイトルが長くなると、ちゃんと表示されるかと心配になって、つい「確認する」ボタンを押してしまいがちだが、実は確認画面では長いタイトルはちょん切られてしまう。
「確認する」ボタンを押さずに、そのまま「この内容を登録する」ボタンを押せば、記事タイトルが長大でも省略されずに投稿される。
増田標準のCSSを利用することでいろんなスタイルを使えるが裏ワザみたいなものだからあんまり多用してはいけません。
はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ
増田には連投規制がないので、記事登録時に「この内容を登録する」を連打すると、そのぶんだけ同じ記事が投稿されてしまう。
悪意はなくても、増田が重くなったときなどに投稿が反映されなくて、思わず連打してしまうことがある。
「反応が遅いだけできっと増田に投稿できている」と信じて、登録ボタンを押すのは一回だけに留めよう。
警告なしにぶった切られるので、めちゃくちゃ気合の入った長文記事ほど途中で終わり、
しかも執筆者本人はそれに気付かない、という悲劇が起こったりする。
<> ←ちゃんと表示される。
あなたの夢はどの馬ですか？ 伝説の名馬へ投票もできちゃうスペシャル企画！現時点ではサイレンススズカが単勝１番人気です。 【JRA】スペシャルＣＭ「夢の第１１レース」特設サイトを開設します！ https://t.co/911dJ2ZP09— (株)中央競馬ピーアール・センター (@JRA_PRC) 2015, 12月 10
増田は実験サービスなので、連投規制もないし、それが実装される予定もない。
はてなは増田なんかロクに見てないので、荒らしやbotが跳梁跋扈していてもBANしてくれる可能性は少ない。
そういう迷惑な増田を見かけたら問い合わせフォームから通報しよう。
カルピスのおまけでついてきた生姜の粉、カルピスに入れて飲んだらおいしくてあったかくなった。でも二袋しかついてこなかったからもうない。
あと、はてな村奇譚が Nexus7 (初代) の Firefox で見ると文章の一部が隠れたきり出てこないの、自分だけだと思ってたらそうでもなかったみたいであったかくなった。
横長画面にしたら一応見られるんだけど、普段は画面の自動回転オフにしてて、ここ見る時だけ回転オンにして横向きにして、見終わったら縦向きにして回転オフに戻して、って操作するのめんどいしんどい。
てな訳で、間に合わせで適用させてるユーザスタイルシートおすそ分けしとくね。
@namespace url(http://www.w3.org/1999/xhtml); @-moz-document domain("orangestar.hatenadiary.jp") { #content { width: auto; } #main { width: 90%; float: left; } #box2 { width: 90%; } }
見た感じ、強気で横幅いじってる (具体的には #content { width: 1080px; } #main { width: 880px; } #box2 { width: 180px; }) のが原因みたい。
元の CSS を修正するんじゃなく、後ろの方に同じプロパティを新しい値で書き足す形で書かれてるせいで、元の CSS に記述されてるタブレット用の値が全部消し飛ばされてる。
書き足し形式をやめて元の CSS を修正するか、もしくはスマホ・タブレット用の記述もコピペして一番下に書き足せば、ひとまず文章は全部見えるようになると思う。
じんじゃーね。
アドバイス罪くさいからここに書くだけにしといたんだけど、描いてる人に伝わったみたいで直った。少なくとも我が家では直った。良かった。
あと、62話目までは画像クリックするとほとらいふのトップに飛ばされて寂寥感ひしひしだったんだけど、63話目から画像クリックするとその場で画面いっぱいにびろーんて絵が出てくれる方式になってた。良かった。