にしし ふぁくとりー:西村文宏 個人サイト

カテゴリ「📝」に属する投稿[23件] - 今日のひとことログ

更新

■LOG カテゴリ「📝」に属する投稿[23件]

にししふぁくとりーHOMEに掲載している「今日のひとこと」の過去ログ(掲載履歴)です。 RSS

No.4723 〔772文字〕 📝

LINEはPC版もタブレット版もあるにはあるが、「スマートフォンを所有していない」ユーザのことは一切考慮されていないサービスなのな。今はどうなのか知らないが、昔はアカウント作成時に(たぶん)SMSを受信できる電話番号が必要だったのだと思う。しかし、それはスマートフォンでなくてもガラケーでもできるので、「認証用の電話番号にはガラケーを使い、LINEはPCやタブレットで使う」という方法がこれまでは可能だったのだが、今ではセキュリティが厳しくなったのか、PCやタブレットにLINEを新規インストールしてからログインしようとすると、『セキュリティのため、PCからの初回ログイン時には本人確認が必要。次のコードをスマートフォン版LINEに入力して下さい』というアラートと共に数桁の数字が出てくるらしい。数字を打つ代わりにQRコードを読み取らせる選択肢はあるのだが、タブレット版LINEで読むと『スマートフォン版LINEで読んで下さい』というエラーが表示されてダメだとのこと。SMSで番号を送ってくる選択肢がなく、タブレット版LINEでも対処できないとなると、ガラケーの電話番号でアカウントを作っている場合、PC版LINEの再インストールはできないことに。(^_^;;; 元々スマートフォン版だけで始まったサービスではあるが、PC版もあるのに「スマートフォンを利用していないユーザなど居ない」という潔い(?)仕様とは。(なお、私はそもそもPCにLINEはインストールしていない。というか、日常の連絡手段にLINEを一切使っていない。一応、アカウントはあって、iPod touchにはインストールしてあるのだが。iPod touchにインストールしてあるLINEが「スマートフォン版」と認識されるのか「タブレット版」と認識されるのか、ちょっと気になる。)

No.4662 〔244文字〕 📝

肩から肘までの中間あたりくらいまでが全体的にだるい。じっとしていれば痛くはないが、腕を上方向に動かすと少し痛い感じはする。とはいえ、腕が上げられないほどではない。腕をまっすぐ上に伸ばすとそれなりに痛いが、できないことはない。ほんの微かに、もしかしてこれは頭痛……? というくらいの違和感はなくもないが、薬を飲むほどではない。ワクチン1回目6時間後の副反応としてはそれくらいだ。大したことがなくて良かった。あと、めちゃくちゃ眠いのだが、これは副反応ではなく単に睡眠が不足しているのかどうか。

No.4661 〔767文字〕 📝

ワクチンを打ってきた。ファイザーの1回目。集団接種ではなくクリニックでの個別接種である。ワクチン待機者の中に、保護者に連れられている制服姿の女の子も1人居た。中学生か高校生かは分からなかったが。今は12歳以上から打てるので居てもおかしくはない。注射には驚くほど痛みがなかった。刺す瞬間のほんの一瞬には痛みと呼べるほどではない程度の痛みはあったので、注射されたんだなということは分かったけども。麻疹の予防接種を受けたときよりも全然分からない感じだった。腕というよりも、完全に肩だな。打つ場所は。貼られた絆創膏(正方形の小さいやつ)があるから打った箇所が分かるが、なかったらどこに打たれたのかも認識できないかもしれない。体温は自宅で測って記入したのだが、受付の体温測定マシン(画面の前に立ったら体温を教えてくれるやつ)で測った体温に修正されたので、測っていく必要はなかったようだ。名前を呼ばれて入ったら、次回用の書類をもらって、接種クーポンとお薬手帳を返して貰って、接種。1分程度しか掛からなかった気がする。その後、15分ほど待合で待機。キッチンタイマーを渡されて、しっかり個別に15分計測されて、アラームが鳴ったら回収されて「なんともないですかー?」と質問されて答えたら終わりだった。次回は3週間後。
20210903130357-nishishi.jpg
接種から1時間45分くらい経って、接種した方の腕に痛みを感じ出したので、「ああ、これが副反応かな」と思ったのだが、その痛みは15分もしないうちにほぼ消滅した。よほど腕に意識を集中させれば、「ああ、もしかしてこの辺が今痛いのかな……」と思えなくもないが。感覚としては「痛み」というよりは「だるさ」の方が近いかもしれない。発熱もなさそうだし、頭痛もない。もっとも、まだ3時間しか経っていないので、これから何か出てくるのかもしれないが。

No.4554 〔266文字〕 📝

マウスポインタを高速で動かしたときにだけ、マウスポインタの表示サイズを10倍にする機能が欲しい。デスクトップが広いと、マウスの所在が分からなくなることが多い。[Ctrl]キーを押すことでマウスの周囲に輪っかを表示してポインタの現在位置を教えてくれる機能をONにしてあるのだが、その機能を使っても見つけにくい。その機能で表示される輪っかアニメーションはデスクトップの面積に関係なく一定サイズのようだが、デスクトップの面積に対する割合で大きさが決まる仕組みだったら広いデスクトップでは輪っかも大きく表示されて望ましそうな気がするのだが。

No.4440 〔645文字〕 📝

先日のMicrosoft Officeのアップデートによって、Microsoft Access Database Engineを利用して構築されているソフトウェアが起動できなくなる問題が起きているらしい。うちの環境はどうだろうか、と思って試してみたら、たしかにエラーが出て起動しなかった。しかも、OKボタンを押しても無限に同じエラーが出続けるので、タスクマネージャからプロセスを殺さないと終われない。(^_^;;;
20210730175851-nishishi.png
コントロールパネルから修復インストールを試せば解決するらしいので、後で試そう。私が使っているのは青色申告用の帳簿ソフトなのだが、ここ数日は起動していなかったので開発元からのアナウンスがあるまで気付かなかった。アナウンス前に気付かなくて良かった。自力であれこれしてしても、「Microsoft Access Database Engineを修復すれば良い」とまでは思い至れないだろうから。(おそらく)Windows10側が出しているのだろう上記のエラーメッセージはさすがに不親切ではないか。何がエラーを出しているのかが何も分からないので、このエラーを見せられても解決策を探るのは難しそうだ。ウインドウのタイトルなりメッセージ本文なりに「Microsoft Access Database Engine」という名称が含まれていれば、それを何とかすれば良いのかと思えるけども。このエラーメッセージは、表示される可能性がほとんどないと想定されているレベルのエラーなのかもしれない。

No.4419 〔708文字〕 📝

大谷翔平が活躍したシーンで、現地の実況アナウンサーが「オータァニサーン」とか「サヨナーラ」とか片言の日本語で叫んでいるところを何度かTVの報道番組で見た(耳にした)ことがある。他にも「スワッテクダサーイ」と叫んでいたのも1度だけ聞いたことがあって、これはきっと大谷に負けた(打てなくて三振になった)バッターに対する「Sit down」の意味で言ったのだろうと解説されていた。そこまでは分かるが、この実況アナウンサーは他にも「ドコカニイッテ、ハヲミガク」と叫んだこともあるらしい。Newsweek先週号の大江千里のコラムに書いてあった。これは聞いたことがなかったのだが、さすがに意味が分からなさすぎて普通の報道番組では使わなかったのだろうか。スポーツ番組ならそこも含めて流したのかもしれないが。これは「Go away and brush your teeth」の直訳だろうとのことで、英語で「出直してきな」というような意味らしい。和訳が惜しい。せめて「ハヲミガケ」なら、まあ、でも意味は分からんままだな。(笑) ふと思い出したのだが、高校1年生のときにニュージーランド人の英語の先生(男性)が、授業の終わりに「イキナサーイ」と叫んだことがあった。勇気あるクラスメイトの1人が「どこへ……?」と尋ねたら「ドコデモ」と笑いながら答えが返ってきたのだが。たぶん「授業はこれで終わりだから好きなところへ行け」という意味だと解釈はできたのだが、「いや、出て行くのはあんただろ?」とたぶん教室中が思っただろう。ニュージーランドだともしかしたら生徒の方が教室を移動するのかもしれないが、日本では教員の方が移動するわけで。(^_^;)

No.4418 〔704文字〕 📝

CSSを使うと、「描画領域の空間いっぱいまで文字を表示するが、はみ出る場合には『…』記号等で省略する」という装飾が作れる。描画領域の空間が環境によって変化するときに、文章を複数行に折り返すことなく1行だけ表示させたい場合に使える。概ね、overflow:hidden;white-space:nowrap;text-overflow:ellipsis; と、描画空間を制限する何らかのプロパティ(例えばmax-widthなど)を併用することで実現できる。しかし、一覧表などのような「table内に含まれる特定のセル」をそのように描画したい場合もあるのだが、td要素にtext-overflowプロパティを指定してもうまくいかない。セル幅は可変長な領域なので「はみ出る部分」を判断できないからだろう。table要素にtable-layout:fixed;を指定する手もあるのだが、そうすると各列の幅が自動調整されなくなって困る。そういう場合には、td要素に対してtext-overflowプロパティ等を使うのではなく、td要素の中に何らかの要素(例えばspan要素)を含めておいて、その要素の横幅を固定するのが良さそうに感じる。例えば、span { display:block; overflow:hidden; text-overflow:ellipsis; white-space:nowrap; max-width:50vw; }のようにして、td要素にspan要素を含めると、テーブル全体では列幅の自動調整が働き、問題の列だけは固定幅ではみ出る文字列が「…」記号で省略されるようになり、うまくいく。

No.4200 〔646文字〕 📝

iOS用アプリを作って公開するためには、App Storeに登録する以外にない。App Storeに自作アプリを登録できるようにするには、Appleに年額11,800円(米国だと99ドル)の年間登録料を支払い続ける必要があるので、気軽にちょっと登録してみようかなとは思いにくい。年額ではなく最初の1度限りの費用だったら構わないのだが。Google Play StoreもMicrosoft Storeも「1度限りの支払いで永久登録」な仕組みだ。しかも、Googleは25ドル(2,800円弱)、Microsoftは19ドル(2,100円程度)である。法人登録だともう少し高いが。なお、いま初めて調べたのだが、AndroidアプリでもAmazon App Storeだったら費用ゼロなようだ。Appleだけがめちゃくちゃ強気の料金形態なのな。桁も違うし回数も違う。iOS向けに無料アプリだけを公開している人は、毎年11,800円の赤字なのだ。これまでならAmazon App Storeにアプリを登録しようと考える人はそんなに居なかっただろうけども、Amazon App Storeに登録したAndroidアプリがそのままWindows11でも動作する(可能性がある)となると、今後の登録数は大きく増加するのかもしれない。Microsoftは「Windows11上で動作するAndroidアプリ用ストア」はAmazon以外にも増やすっぽいことを言っているようだけども、他にどこがあるのだろうか。

No.4060 〔965文字〕 📝

いま開催中のAppleの開発者向けイベント(WWDC)で、新しくリリースされるiOS15版Safariに関する話が出ている。なんでも、アドレス欄やボタンなどを配するツールバーが、画面下部でウェブページに重なるように表示されるようになるとか。どういう状況でこのような表示になるのかハッキリしないが、「画面下部にボタンを固定する」デザインを採用したウェブページはかなり扱いにくくなりそうだ。Appleのプレスリリースには動画で動作が説明されていた。リンク先ページのほぼ中央付近にある「再設計されたSafariのブラウズ体験」の部分に短い動画がある。これを見ると、下方向にスクロールしている間は最小化されて出てこないようだが、上方向にスクロールする際には出てくる。これだと、やはり画面下部に固定ボタンを並べて配置するようなデザインのウェブサイトだと、ボタンが使いにくくなるだろう。元々、物理ホームボタンのない端末では画面下部がソフトウェアホームボタンの領域になっているので「ウェブ上で画面下部にボタンを固定するデザイン」は既に使いにくくなっていたとも言えるわけだが。それがより強固な指針になるということか。Appleによるとこの変更は「片手だけで操作しやすくする」ためのようだ。確かに下端にすべてのボタンがあれば、親指だけで操作できそうな気はする。発狂するウェブデザイナーも多々出てきそうな気もするが。(笑) いや、笑いごとではないかも知れない。ちなみに私のサイト(の一部)では、スクロールするとメニューバーが画面端に固定されるようになっているが(PCでもモバイルでも)、固定位置は画面上端である。なので影響はなさそうだ。個人的には、画面下端に何かを固定表示するデザインを使ってこなかったのは、画面の下は「読み進める先」なので、そういう「視線の先」になる場所に何かを固定したりしなかったりする表示はあまり望ましいとは思っていなかったという点もある。もっとも、最大の理由はPCだとボタンを下端に固定すると使いにくくなるから、だが。PCとモバイルとのデザインの差を大きくすると作るのが面倒なので、PC側に合わせたのだ。元々PCだけのことを考えたサイトデザインだったのを、後からモバイル対応にした場合には、このような考え方になりやすいだろう。

No.3958 〔665文字〕 📝

下記のような条件があるとき、ⒶとⒷの関係や、ⒶとⒸの関係を、計算式1つで表す方法はないものか。
Ⓐが  970 のとき、Ⓑは -45 で、Ⓒは 10 になる。
Ⓐが 1070 のとき、Ⓑは -50 で、Ⓒは 12.5 になる。
Ⓐが 1170 のとき、Ⓑは -55 で、Ⓒは 15 になる。
Ⓐが 1270 のとき、Ⓑは -60 で、Ⓒは 17.5 になる。
Ⓐが 1370 のとき、Ⓑは -65 で、Ⓒは 20 になる。

何か思いつきそうな気がしないでもないのだが、私の乏しい数学的センスでは思いつけなかった。
なお、単純に割り算しただけだと以下のようになる。
20210528115013-nishishi.png
なんかⒷとⒸをちょっとどうにかして(笑)下駄を履かせるか脱がせるかすると、いい感じに一定の割合になってくれないかなと思うのだけど。

(追記)
思いついた。Ⓑ÷(Ⓐ-70)、Ⓒ÷(Ⓐ-570) だと、割合が一定になる。
20210528122647-nishishi.png
これで、CSSがそれぞれ1行で済むようになった。めでたし、めでたし。

Excelでこの5行のテーブルを範囲選択してから(選択範囲の)右下端を上へドラッグすることで、この5件の間に存在する法則を保ったままⒶがもっと小さい値のときのⒷとⒸの値を出して(下図の赤色部分)、それらが0になったとき(下図の灰色部分)のⒶの値を引き算してから割合を計算することにしたことで分かったのだけど。こういうのを最初から何か計算で求める方法があると思うのだが、どう考えれば良いのか思いつく脳がない。orz
20210528123311-nishishi.png
まあ、Excelパワーで判明したので良かったのだが。

No.3883 〔458文字〕 📝

なお、先の電話は私宛ではない。家の固定電話の留守電に何かが録音される機会自体がせいぜい半年に1度あるかないか程度の頻度だが、企業からの連絡電話以外となると2~3年に1回あるかないか程度の頻度しかない。しかも、「長年連絡を取っていなかった知人からの留守電」みたいなのだと10年に1回あるかないか程度の頻度ではないか(私の知人ではない)。私の個人的な古い知人から家の固定電話に電話が掛かってくることはない。そもそも大半の知人は電話番号を知らないだろうし、連絡はメールを使えば充分だからだ。メールアドレスをアドレス帳に登録していなかったとしても、私のウェブサイトを検索して見れば連絡先メールアドレスは明らかなので迷うことはないだろう。私がウェブサイトを持っていることを知らない知人は居ない。ウェブサイトのURLを覚えていなくても名前で検索すればすぐに分かる。高校以前の同級生で大学以後に付き合いがない人々は私がウェブサイトを持っていることは知らない可能性が高いだろうが、そういうのは個人的には「知人」の範疇に含めていない。

No.3882 〔487文字〕 📝

家の固定電話の留守電に「この携帯の番号に返事くれ」的なメッセージが残っていたのだが、肝心の電話番号は喋ってくれない。固定電話はナンバーディスプレイを別途契約していない限り発信者の電話番号は分からないのだ。電話と言えば携帯電話を指すことが多い昨今、その事実に気付かない人々も多くなっているのかも知れない。いや、電話がかかってきた直後であれば、136をダイヤルすることで直前の発信者番号を知ることはできる(1回30円)のだが「直近1回の電話」しか分からない仕様なので、留守電が録音された後に別の人から電話が掛かってきていた場合にはその後の人の番号しか得られないから役に立たない。固定電話には自動音声アンケートみたいな電話がよくかかってくるのでその可能性はそこそこある。留守電に録音された後に別の人から電話が掛かってきたかどうかを知る方法はないので、136にダイヤルして得られる電話番号が留守電に入れてくれた人の電話番号である保証はないから、136で番号を知る方法は使えない。したがって、固定電話の留守電に「返事くれ」と入れる場合には自分の電話番号も口頭で述べない限り無理である。

No.3807 〔379文字〕 📝

毎日新聞に、住居が小学校に近い高齢女性ほど鬱リスクが低いという記事が出ていた。こういう相関関係は、因果関係とは限らないので注意が必要だ。相関関係が因果関係とは限らない例を分かりやすく示したページにSpurious Correlationsがある。下図は、このページで紹介されている「米国メイン州での離婚件数(赤線)とマーガリンの消費量(黒線)」の相関関係図である。
20210508091658-nishishi.svg
グラフからはずいぶんと高い相関があることが分かるが、マーガリンを消費すればするほど離婚が増える(または、離婚すればするほどマーガリンがたくさん消費される)わけがないだろう。他にも「プールでの溺死件数とニコラスケイジの映画出演件数」にも高い相関があると先のページで紹介されている。「○○な人ほど○○である」のような相関関係を見かけたら、まず「本当に因果関係にあるだろうか?」と疑った方が良い。

No.3687 〔636文字〕 📝

駅にATMがあるのでついでに記帳しようかと思ったのだが人が並んでいたのでやめておいた。残高はオンラインバンキングで分かるので特に記帳を急ぐ必要はない。紙の通帳に記帳するのは、確定申告のための帳簿に記載する伝票番号を通帳にも書いておくためだ。そうしなければならない規則はないのだが、帳簿の根拠を明確にしておく方が無用なトラブルを防ぐために望ましいと考えている。オンラインバンキングの画面を印刷するなりPDFにするなりする方法だと、通帳のように整頓された情報にならないので(見やすくないと意味がないので)使えない。もちろん1年分の履歴を一括して表示させれば(通帳と同じように)整頓された情報にはなるのだが、帳簿は1年分をまとめてつけるわけではなく毎月少しずつつけるので、画面を保存する方法では使いにくい。1ヶ月分の履歴ずつ印刷すれば計12枚で1年分にはなるのだが、そこまで取引件数が多いわけではないので無駄に煩雑になる。だからやはり今のところは紙の通帳を使うのが最も見やすく扱いやすいのだ。この点がオンラインでも解決されれば、通帳はオンラインだけで良くなるだろう。銀行がペーパーレスを推し進めたいなら(通帳には毎年200円の税金が掛かるらしいので銀行はできるだけ通帳を発行したくないハズだ)、オンラインバンキングの機能をもっと高めて頂きたい。今でもわりと便利ではあるのだが、「紙の通帳なら自由にメモが付加できる」という点をオンラインの取引履歴でも実現されるともっと便利になる。

No.3682 〔291文字〕 📝

インクジェットプリンタの印刷結果を見ると黒色の一部がズレていたので、ノズルのヘッドクリーニングをした。クリーニング結果を確認するためにノズルチェック(吹き出し口1つずつからの印刷テスト)をするのだが、このときA4用紙1枚を消費してしまうのがちょっともったいない。トレイからの自動給紙ではなく手差し給紙をさせてくれる仕様だったら余っている紙片を使って印刷できるのだが、問答無用で自動給紙されてしまう。プリンタのユーティリティに給紙選択を加えるだけで良いのだから実装は簡単だと思うので、実現してくれないものか。
20210422104122-nishishi.jpg
それはともかく、印刷のズレは解消できて、綺麗に印字できるようになった。

No.3638 〔218文字〕 📝

Windows Media Player用の視覚エフェクトアドオン「FRUITY(フルーティ)」が楽しい。
20210417023727-nishishi.png
Windows7までのPCで使っていたのだが、Windows10でも問題なく動作した。DLLの関係で32bitでしか動作しないので、てっきり64bit版Windows10ではダメなのかと思っていたのだが、64bit版のWindows10でも、Windows Media Playerは32bitで動作していたので問題なかった。

No.3589 〔178文字〕 📝

風呂場の蛇口から水漏れがしている。蛇口というと語弊がありそうだが、蛇口そのものではなく、温度調節をするプラスチックレバーの下からポタポタ毎秒2滴くらいのペースで落ちてくる。バケツを置いておくと、一晩で2杯分くらいになる。毎秒2滴だと、1分120滴で、1時間7,200滴。水1滴はずいぶん微量に思えるが、4~5時間で3万滴くらいあるとバケツ一杯に溜まるのか。

No.3145 〔383文字〕 📝

一度知ってしまったら二度と「知らなかった状態」には戻れない。おもしろい映画は何度見ても楽しめると思うのだが、中には1度目に観たときの記憶があると、絶対に「1度目のときと同じ感覚」で2度目を観ることはできない話というのもある。レオナルド・ディカプリオ主演の「シャッターアイランド」という映画が2010年に公開されて映画館で観たのだが、この脚本もまさにそうだ。Amazon VideoでPrime特典に入っていたのを発見したのでお勧めしておきたい。最後まで観てすべてを知ってしまったら、絶対に同じ感覚で2度目を観ることはできないストーリーだ。単に「結末を知っているから」とかそういう問題ではない。そういう映画は他に何があるかな……と思ってふと考えてみると、ブルース・ウィリス主演の「シックスセンス」もそうだ。(シャッターアイランドとシックスセンスにオチの共通点はない。)

No.2643 〔216文字〕 📝

要素の中身をごそっと入れ替えたいときの記述は、JavaScriptのinnerHTMLではプロパティなので「代入」だが、jQueryのhtmlではメソッドなので「引数」に指定しないといけない。うっかり $('.hoge').html = '書き換え内容'; などと書いてしまうと、文法的にはエラーにならないのに、意図通りには動作しない結果になって、首を捻ることになる。$('.hoge').html('書き換え内容'); が正解だ。

No.2571 〔384文字〕 📝

私のメインサイトで使っているドメインは nishishi.com だが、CGIの動作実験用に使っているサイトのドメインは nishishi.org だ。記録を見ると2011年に取得していた(nishishi.comの取得は2000年)。この .org 側サイト(にしし らぼらとりー)のトップページ等は長らく適当なまま放置していたのだが、さすがにそれもどうかと思ったので一念発起して見た目を整備してみた。昨日から今日にかけて、こればっかり作業していた。これまで自分しか読めない場所で書いていた「CGI開発に関係するつぶやき」もどうせならコンテンツの1つにしてしまおうかと、開発放言として公開してある。自分用に書き留めていたメモばかりなので、他者が読んで意味が分かるものばかりではないとは思うのだが。コンテンツが少なすぎるのもどうかと思ったので、賑やかしのようなものだ。

No.2489 〔516文字〕 📝

まだ新メインPCは設置していないのだが(開梱すらしていない)、昨夜は電源タップの配線を作り替えてから、キーボードとマウスを2台のPCで共用できるケーブルを出してきて接続した。いま使っている5代目メインPCとその前の4代目メインPCを共用していた頃に使っていて、その後は押し入れに仕舞っていたケーブルだ。ちゃんと正常に動作している(いや、PC側はまだ1台しかないので、切り替えが正しくいくかどうかは未確認だが)。2台のPCへのUSBケーブルと、キーボードとマウスのUSBケーブルが集中する切り替え本体の背面は磁石になっているので机の背面に貼り付くから便利である。机の背面には他に、電源タップが2個とスイッチングHUBが磁石でひっついている。磁石で机の背面に取り付けられると、床にケーブルが散乱せずに済むので掃除が楽だ。もしこれからPCデスクを調達しようとしている人が居たら、机の側面や背面が金属でできている製品を強くお勧めしたい。PC関連機器は(オフィス用途を考慮しているのだろうが)裏面が磁石になっている製品も多々あるので、そういうのを選ぶと床がスッキリする。ケーブルにはどうしてもホコリが溜まりがちなので、床からは離しておきたい。

No.2267 〔771文字〕 📝

「abandonedly」って英語の辞書に載っていなかったのだが英語ではないのだろうか? と思ったが「abandoned」という単語はあるのか。「fly abandonedly into the sun」をGoogle翻訳にかけると「放棄されて太陽に飛ぶ」という和訳になったが、DeepL翻訳にかけると「日向ぼっこをする」という訳語になった。ええ!? ずいぶん違うな。前者はいかにも直訳で、後者はいかにも意訳のように感じられるけど、文脈からするとどちらも違うような気もしているのだが。(笑) DeepLの場合は特に前後の文も含めて訳せばまた違った和訳になりそうだが、文章ではなくて歌詞だから元々ぶつ切りなのだ。……と思ったが物は試しに、と思って「Spread your wings and prepare to fly. For you have become a butterfly. Fly abandonedly into the sun.」の3文をDeepLで翻訳してみると「翼を広げ、飛ぶ準備をしなさい。あなたは蝶になったのだから。太陽に向かって放心して飛べ。」となった。なるほど、それっぽい。ちなみにこれをGoogle翻訳で和訳すると「翼を広げて飛ぶ準備をしてください。あなたは蝶になっているからです。放棄されて太陽に飛ぶ。」で、懸案の文(=3文目)の訳は同じだった。まあ普通の翻訳ソフトならそうだろう。そういう意味ではやはりDeepLの訳し方がすごいのだな。しかし、最初の「日向ぼっこをする」はどこから出てきたのか。いや、意訳として分からなくはないのだけど(ここでの意味は違うと思うが)。むしろ、最初にその訳を引っ張り出してきたことの方がすごい気もしてきた。ちなみに、マライア・キャリーのButterflyという曲の歌詞である。

No.2240 〔369文字〕 📝

kohprpと入力して漢字変換すると一旦は「個hprp」になるのだが、ちゃんと修復変換候補として「時頃」を出してくれるATOK。すごいと思うのは、全部のキーが1つずつ右にずれているというわけではないのに、ちゃんと「時頃」を出してくれる点だ。本当ならjigoroと入力しなければならないのだから、もし右隣に1個ずつずれたキーを押したならkohptpになる。しかし、rだけは正しく入力できていたので、打ったキーはkohprpだ。それでも「時頃」が修復変換として出てくる。よくできているものだと感心した。この機能ができてからは、多少の打ち間違い(たいていは同じキーを押しすぎる間違い)に気付いてもそのまま強引に変換キーを押すようになった。だいたい7割くらいは、意図したとおりの良い感じに修復して変換結果を出してくれる気がしている。とても便利だ。
2021年7月
123
45678910
11121314151617
18192021222324
25262728293031
2021年8月
1234567
891011121314
15161718192021
22232425262728
293031
2021年9月
1234
567891011
12131415161718
19202122232425
2627282930

Powered by てがろぐ Ver 3.4.0

--- 当サイト内を検索 ---