  |
はてなキーワード: ダイアログとは
今の40代オタクがボクの師匠、プログラムもCGもDTMも師匠のおかげを書いた増田です。
お前が技術を中心に情報補完しろよと言われたので知っている範囲で情報を補完します。
ただやっぱりネタバレするとゲッサン編集部や作者氏から叱られそうなので、まったく本編には影響しないであろう部分を中心に情報補完させて貰います。
先に謝っておきますがネタバレ回避を考えたら第1話で語れる部分がココしかなかったっす・・・。
主人公の和田一馬が所持するガラケーはデザインに微妙な違いがあるけれど、おそらくはau W41CAで2006年の春モデル。
W41CAはペンギンケータイとも呼ばれたCASIOのヒット機種で、外観はCASIOらしく少々無骨、旧機種のW31CAでは赤外線通信やおサイフケータイへ非対応だったものの、W41CAでは対応を果たし全部入りケータイになった。
ペンギンケータイの由来ともなるマスコットキャラクターのアデリーペンギンが画面上の様々な部分で演出として登場し、ポップなオレンジの筐体色とも合わせてその可愛らしさから人気を博した。
W41CAは無骨さの中にある可愛らしさで人気となったが、CASIOのWn1CAシリーズは本来サラリーマンに高い評価を受けていた端末で、WordファイルやExcelファイルを閲覧できるPCドキュメントビューワーやPC向けWebページを閲覧できるいわゆるフルブラウザを搭載しつつ、USBマスストレージ接続が可能な端末であり、更にはFMラジオを受信できるなど当時のギークからも非常に高い評価を得ており、CASIOガラケーの銘機としてガジェット界隈では歴史に刻まれている。
当時を知る者であれば常識的な話だが、CASIOというか当時のauは学生へ対して強く訴求する携帯電話通信キャリアで「学割と言えばau」という認識が世間でなされており、auや携帯電話へ搭載する機能や展開するサービスも学生を意識したものが多かった。
取り上げているW41CAも着メロの最大発音数は128のステレオ再生、PCM音源の再生機能である着うた(AAC/48Kbps)にも対応していた。しかもSD Audio Playerを搭載しておりminiSD(microSDではない)にUSBマスストレージ経由で保存したAAC(96Kbps)の再生が可能であった。
ちなみにヒロイン(？)が使っている携帯電話は現在でもINFOBARを生み出したとして話題となるau design projectの第3弾端末であるau talby。2004年冬モデルで製造は三洋、型番がA5508SA。デザイン以外に語る部分がぶっちゃけない。
というか当時からハードウェアスペックに関して語られることがあまり無かった機種で、掲示板などで携帯電話のスペックを誇ったり最大限に活用するための情報交換などをするギークなユーザが選ぶ機種ではなかったので殆ど知らないというのが実情。
INFOBARは目新しさもあって結構いろいろ情報交換されたものだけれど第3弾ともなると正直言って失速気味になっていた。
ただ、主人公が最新の携帯電話でヒロインが型落ちのデザイン重視な携帯電話、学生なのでauという細かな描写は作者の意気込みを感じる。
個人的にはこの時期の携帯電話を挙げるならauではなくVodaphoneとNTT DoCoMoから発売されていたNokia 6630を推したく、これがまたSymbian S60で・・・と話が逸れるので別の機会に。
W41CAに搭載されている音源はYAMAHA AudioEngine MA-7i(YMU791)で、前述の通りFM音源の最大発音数は128でステレオ再生が可能であり、AACやMP3のデコードへ対応するなど非常に多機能で多くの携帯電話端末に採用されることとなる2005年に登場した最新LSIによる音源だが、W41CAでは何故かMP3デコードなど一部機能が制限されている。
着メロ形式はSMAF(MMF)で150Kbyte(153,600byte)まで、FM音源の使い勝手としては4オペレータの最大発音数128で、更にFM音源側の最大発音数を減らすことで最大16bit/12,000HzのPCM音源データを使うことが出来、同様にFM音源側の最大発音数を減らすことで着うた登場前後に一瞬だけ流行ったボーカル付き着メロで活用されたHV(合成音声)も使える。
エフェクターなども内蔵しておりMA-7シリーズは当時の着メロ職人からはかなり評価の高い音源であったものの、NTT DoCoMoしか注目しなかった頭内定位を利用した仮想サラウンド再生のための3Dポジショニング機能も実装されており、いつの世も空間に対するオーディオというのは経営者と技術者の心を掴んでしまうんだなと林檎マークを見て思いを馳せる。
ただ人気だったW41CAにも欠点はあり、当時のケータイアプリ開発者から悪名を欲しいままにしたezアプリ、つまりBREWアプリが採用されていた。当時のauは野良アプリ(勝手アプリ)開発者を締め出すことへセキュリティの都合上から躍起となっており、公式ez web以外の経路からのアプリインストールを著しく制限していた。
この制限が無くなるのは平成ヲタク リメンバーズの時間軸で言えばほんの先の未来である2007年に登場するオープンアプリプレーヤー(OAP)を待つ必要があり、W41CAは、というかau端末はその点からギークに毛嫌いされることがよくあった。
BREWアプリの欠点はそれだけでなく、これはBREWアプリよりも前のezplusアプリ時代からそうなのだが1日のアプリ内携帯電話パケット通信3MB制限という謎の縛り(後に6MBまで上限緩和)が設けられておりユーザとケータイアプリ開発者双方からヘイトを買う一因となっていた。ちなみに他社は1度のパケット通信量の上限はあったが1日の上限は無い。
いやそもそもQualcommからカフェインよりもアルコールだよと騙され酔っぱらいJAVAからBREWへ乗り換えたこと自体が愚かで、他社はJAVAのままなので単に開発負担が増え、auで公開されるケータイアプリが減るという結果しか生まなかった。これが解消されるのが前述したOAPであり、OAPの正体はBREW上に構築されたJAVA VM環境であった。
しかしこのOAPもBREW側のセキュリティパーミッションのせいでパケット通信するたびに通信を許可するためのダイアログが表示されるなど不便極まりない仕様であったためユーザの反感を買ってしまう。
マニアックなネタばかり詰め込んでもアレなので、平成ヲタク リメンバーズの本編に影響しないよな？とビクビクしながら選んだのが当時流行っていた携帯電話を活用した位置ゲームのコロニーな生活。当初はウィルコム端末向けだったが後に他の携帯電話通信事業者にも対応し、2005年にコロニーな生活☆PLUSとして改称アップデートされた。
このコロニーな生活☆PLUSはブラウザゲームの一種でコロニーな生活☆PLUSのURLへアクセスするだけでゲームへ参加できた。1km以上の直線移動距離を稼いでゲーム内通貨を貯め、自分の土地の施設を充実させ住民人口を増やしていくというゲーム。
当時を知っている人ならばオチが直ぐにわかっていると思うので間を置かず言ってしまうと、コロニーな生活☆PLUSの略称はコロプラ、現在では白猫プロジェクトやディズニーツムツムの開発元で知られる株式会社コロプラの祖業である。ちなみに今でも一応はスマートフォンアプリでサービス継続しており名称も「コロプラ」へ改称している。
平成ヲタク リメンバーズの世界の時間軸にプレイヤーは存在するだろうけれど今後ネタ被りしたら申し訳ない。
ネタバレ回避も必要だし始まったばかりの第1話でとやかく言えることはないですね。読者の興味を惹こうとする単語が現れたりするので走り出しとしては及第点なんじゃないかなと。
むしろ前述したように登場するガジェットをしっかりと時代に合わせたものにしていたりとセリフやキャラクターだけでなく登場する小物にも注目したほうが楽しめるのかも知れないというのが第1話への感想と今後への期待です。
作者氏は同年代だと思われるので、敵に回すと恐ろしいが味方につけると頼りないと言われるVIPクオリティを発揮してくれたらなと楽しみにしてます。うはｗｗｗおｋｗｗｗｗｗ
以下のスクリプトを登録することで。以下のループを繰り返させることができる。
「https://anond.hatelabo.jp/ここにユーザー名/を開く」→「直近の投稿の編集画面に遷移」→「削除ボタンを押す」→「ダイアログに答える」→「https://anond.hatelabo.jp/ここにユーザー名/に戻る」
実質ダイアログに答えるところだけやればよい。
// ==UserScript== // @name New Userscript // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author You // @match https://anond.hatelabo.jp/ここにユーザー名/ // @icon https://www.google.com/s2/favicons?sz=64&domain=hatelabo.jp // @grant none // ==/UserScript== function sleep(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } (async function() { 'use strict'; await sleep(100); window.location.href = document.querySelectorAll("div.section")[0].querySelector("a.edit").href; })();
// ==UserScript== // @name New Userscript // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author You // @match https://anond.hatelabo.jp/ここにユーザー名/edit* // @icon https://www.google.com/s2/favicons?sz=64&domain=hatelabo.jp // @grant none // ==/UserScript== function sleep(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } (async function() { 'use strict'; await sleep(100); document.querySelector("input.delete-button").click(); })();
DMM版ウマ娘プリティーダービーを遊ぼうとしても、エラーダイアログを出さずに起動しなくなる現象に遭遇した。
Windowsのイベントビューアーを除くと、こんなログが吐かれていた（各IDは削除）。
=====
日付:
ユーザー:
説明:
障害が発生しているアプリケーション名: umamusume.exe、バージョン: 2020.3.24.51085、タイム スタンプ: 0x
障害が発生しているモジュール名: apphelp.dll、バージョン: 10.0.22621.963、タイム スタンプ: 0x
障害が発生しているアプリケーション パス: D:\DMMGames\Umamusume\umamusume.exe
障害が発生しているモジュール パス: C:\WINDOWS\SYSTEM32\apphelp.dll
結論から言うと、Windows本体のapphelp.dllが原因でウマ娘が起動できなくなっているという。
アプリケーションに罪は無いため、DMM Game Playerやウマ娘を何度再インストールしても直らない厄介な現象だ。
Windowsは数十万のファイルが存在するため、今回のようにWindows Updateやアプリケーションのインストール・アンインストールを繰り返すだけでシステムファイルが壊れる事がある。
Windowsでは、これを直すためのコマンドがコンソールUIのみに用意されている。
Windowsのスタートメニューを右クリックして、コマンドプロンプトまたはターミナルを管理者権限で起動する。
を実行する。これは、オンライン上にある正しいWindowsのシステムイメージを元に、壊れたファイルを修復する操作となる。
実行するとこう表示される。
[==========================100.0%==========================] 復元操作は正常に完了しました。
DISM.exeを実行すると、正しいWindowsのシステムイメージがPC内に保存された状態になる。
この状態で、
sfc /scannow
を実行すると、次のように表示される。
システム スキャンを開始しています。これにはしばらく時間がかかります。
Windows リソース保護により、破損したファイルが見つかりましたが、それらは正常に修復されました。
オンライン修復の場合、詳細は次の場所にある CBS ログ ファイルに含まれています
windir\ Logs\CBS\CBS.log (たとえば C:\Windows\Logs\CBS\CBS.log)。オフライン修復の場合、
これで、とりあえずWindows自体の修復コマンドによってシステムファイルが正しい状態に復元された状態となる。
実行してもまだメモリ上には古いシステムファイルが読み込まれて実行されている状態なので、終わったらPCを再起動する。
さて、準備は完了だ。ここまでの操作でWindowsを回復しDMM Game Playerで「ダウンロード版をプレイ」を押す事でウマ娘が起動し…ない！
イベントビューアーには今もウマ娘を起動しようとする度にアプリケーションクラッシュイベントが追加されている。救いは無いのですか？
結局、今回のケースではPCで常駐していたリモートデスクトップ用のSplashtop StreamerとVirtual Desktop Streamerをタスクキルする事でウマ娘が起動できるようになり、DMMブラックフライデーで得た有償石でおはガチャを回すことに23時成功した。
そうなんだ。
ちょっと調べたわ。
If MultiSelect is True, the return value is an array of the selected file names (even if only one file name is selected). Returns False if the user cancels the dialog box.
https://learn.microsoft.com/en-us/office/vba/api/excel.application.getopenfilename
ダイアログをキャンセルするとFalseが返ってくるから、IsArray()とかでガードした方が良いかもな。
取引先が「ペーパーレス化への取り組みのためFAXをやめてPDFファイルでのやり取りに…」ってFAXしてきたから
「対応できます！是非！」って食い気味に返したんだけど、話をよく聞くとクラウドで共有リンクとかは検討すらされてなくて
結構な量のファイルをメール添付で送る話を検討してるっぽいのよね。多分PPAPだよなぁ……
専用のメールアドレスで受け取って、シス管がスタンドアロンで開いて…とかするくらいなら、
自動印刷しない複合機で受けてPDF形式でメール転送からのスクリプトでチャットツールに流して……のが楽なんでFAXでお願いしますってなっちゃうんだよなぁ
ただそうすると「照会依頼：該当するチェックボックスに✓を付けて返送してください」みたいな地獄のFAXが無くならないんだなぁ
ちなみにこの手のやつはGIMPでPDFを開いてテキストレイヤー重ねて印刷ダイアログからMicrosoft print to PDFで書き出してPCFAXすると有料ソフトなしで倒せる…が徒労感が凄まじい
女とコンパイラは意外と似ているのではないだろうか
おめー、セミコロンが文末にないやろ、とか言いがかりをつけられても、
文法はどこも間違っていなくて、
よくわからんが、MSのコンパイラはUTF-8のソースコードも勝手にShift-JISに解釈するらしくて、
Visual Studioは「ビジュアル」なはずなのに、
わざわざプロパティーダイアログ開いて、コマンドラインに書くオプションをそのまま書かされて、
なんか不満をもらしたり、言いがかりをつけてきても、
女も客とか上司とかも、本音の部分はどこか別のところにあって、
わざと本音を隠してるのなら人として？まだ分かるのだけど、
意外と多いのは、本人自身も不満の原因の場所をちゃんと理解しておらず、
頓珍漢な場所について文句をたれるので、そういう人はほんとに困る
でも、意外と多い
わざとはぐらかすにしろ、自分で自分自身を理解できてないにしろ、
まあ、わざとだろうが不愉快だが、わざとの方はまだ頭がいい
当たり前だけど他のサービスのメールは押した瞬間に購読解除になるよ
送金とかそういうクリティカルじゃない機能にこれやるんだったらもう使いたくない
今は会社の給料振込先にしているけど、会社辞めたら口座解約する。絶対に解約する。絶対絶対解約する。俺はブチ切れたからな
特に何度も何度も同じ数列をスマホのちぃせぇ画面で操作繰り返させられたの最悪
AdobeのLightroom CC（Classicでないほう）は使うべきではない。人生の時間を大切にしたいのであれば写真管理は別のアプリケーション、サービスを使うべきだ。以下はそれを実感した私の体験談である。
ことの始まりはLightroom CCの画像ファイルのローカルバックアップの場所を変更しようと思ったことである。写真データは古いDroboに置いていたが、さすがにUSB 2.0では遅く感じるようになったことと、ライブラリを複数のPCで管理したかったので、写真データをNASに移動させることにした。「ピクチャ」フォルダに置いていた”Lightroom CC”のフォルダをNASにコピーし、Lightroomの環境設定でNASのフォルダを「元画像の保存場所」に指定してLightroomを再起動。それほどたくさんの写真があるわけではない。枚数で言えば2万枚超、データサイズは90GByteほどである。私の目論見では、このまま放置しておけば数時間でクラウドとの同期が完了し、データの引っ越しは終わるはずであった。ところがこんな単純なことがうまくいかないのである。
同期にとにかく時間がかかる。「写真をチェック中」とのダイアログがでてカウンタが進んでいくが一秒に2〜3枚くらいづつしか進んでいかない。ときたま考え込んでカウンタが停止したまま数分経過することもある。あまりに長時間動かない時はさしもの私もしびれを切らしてLightroomを再起動させた。再起動させるとまたカウンタが進み始めるのである。そんなこんなを繰り返して7時間ほどかけてようやくチェックが完了。さあこれでクラウドとローカルの照合が終わり引っ越しは完了かと思いきやそうではなかった。次に「写真を移動中」とのダイアログが出てDroboからNASへの写真データのコピーが始まったのである。
は？
写真データははすでにNASにコピーしてあるだろ！「写真をチェック中」って一体何と何をチェックしていたんだよ？！クラウドとNASのデータをチェックしていたんじゃないのかよ！？なぜ古い場所から改めて写真をコピーしてくる必要があるんだ！？
最悪なのはこのコピーのプロセスも途中で止まるということである。途中でうんともすんとも言わなくなる。しかたないので「次の起動まで停止」のボタンで抜けてLightroomを再起動する。普通に考えれば次に起動した時はコピーの続きから再開すると思うだろう。さにあらず、Lightroom CCはまた一番最初のファイルの照合プロセスからやり直し始めるのである。なぜこんな仕様にしているのか理解できない。そしてコピーの途中でまた停止。再起動するとまた一番最初からやり直し。こんなの終わるわけがない。
私もとうとうこのやり方には見切りをつけて、Lightroom CCをアンインストールし、全ての設定データを消してクリーンインストールし直すことにした。
クラウドにはオリジナルの写真が全てアップロードされている。クリーンインストールしたLightroom CCを起動するとまずカタログデータをダウンロードする。そしてローカルバックアプとの照合を行い、ローカルにデータがなければクラウドからデータをダウンロードする。
クリーンインストールしたLightroom CCは古いライブラリからファイルをコピーしようとするような謎動作は行わないようだった。しかし今度もカタログデータのダウンロードで止まる。再起動するとまたダウンロードを始める。そして止まる。また再起動の繰り返し。
ようやく数時間かけてカタログデータをダウンロードし終わると今度はオリジナルデータのダウンロードである。ローカルにバックアップがすでに存在するのにまたクラウドから再ダウンロードするような無駄を私は望んでいない。しかしこれまでの格闘で私は疲れ切っており、もう勝手にしろという気分であった。そしてまたここでも頻繁に停止するのである。停止している時に右上のクラウドのアイコンを押すと、「ネットワークに接続できません」と表示されていることがある。ネットにはもちろん接続されている。何らかの事情でクラウドサーバとの接続が切れてしまい、接続を回復できなくなるのが停止の原因のようにも思われる。それがサーバ側の問題なのか、クライアントの問題なのかはわからない。わかるのはLightroom CCのフォトプランというサービスが、サーバもクライアントソフトウェアもひっくるめて極めて低品質なものであるということだけだ。
Lightroom CCのクラウド同期に問題が発生しているのは自分の環境だけではないようだった。
ネットではいくつかの対処法も見つけることができる。たとえばあるサイトでは同期停止の対処法としてLightroom library.lrlibraryの中にある”Managed Catalog”で始まるファイルを別の場所に移動してアプリケーションを再起動することを提案している。
https://lifehacking.jp/2018/04/lightroom-cc-spinning-wheel/
私もこれをやってみたが何の解決にもならなかった。今までの同期情報が消えてまた最初から同期プロセスが始まり、また停止しただけだった。
Adobe本家のサイトでは同期が止まった場合に写真にフラグを設定することで同期を再開するという対処法を提示している。
https://helpx.adobe.com/jp/lightroom-cc/kb/stuck-syncing.html
私はこれもやってみた。しかし何も起こらなかった。何度フラグを付け直そうが停止した同期プロセスが再開することはなかった。停止した同期プロセスを再開する方法はLightroom CCを一旦終了してまた再起動することだけだった。結局、ドモホルンリンクルを見つめる人のようにずっと同期の進行を監視して、止まったらLightroom CCを手動で再起動するという方法しか対処法はなかった。
はっきり言ってネットの情報は嘘ばかりである。一般ブロガーのサイトの情報があてにならないのはしょうがないが、Adobe公式のヘルプに堂々と嘘が書いてあるのは許しがたい。
これまで写真管理はiPhoto、Apertureを使ってきた。Appleが両ソフトウェアをサポートしなくなり移行先として選んだのがLightroom CCである。Appleへの依存率を下げたいという意図もあった。しかしとんだ見込み違いでLightroom CC/フォトプランはどうしようもなく低品質のプロダクト/サービスであった。たかがローカルバックアップの場所を変更するだけのことに大変な労力と時間を無駄につかわされた。
私はもうLightroom CCは捨てることにする。もともとRAW現像などするような写真趣味があるわけではなく、写真の管理とクラウドバックアップ、カジュアルなレタッチができればよいユーザであった。これからは写真管理とクラウドバックアップは写真appとiCloud+、レタッチはLuminar AIを使うことにする。
これを読まれた読者諸賢も貴重な人生の時間と労力を無駄にしたくないのであれば、Lightroom CC（そしてこんな品質の低いアプリケーションとサービスしか作れないAdobe）には金輪際関わらないことをお勧めする。
ExcelでAlt+Enterと言えばセル内改行でおなじみのショートカットですが、
Excelのそれ以外の箇所でAlt+Enterすると異常な効果が発現することがあり注意喚起と言うか誰か原因知ってる人教えて欲しいのでここに記す。
①新しく空のExcelを開いて直後にAlt+Enter：別窓で新しいBookを開く。
②Excel内のウィンドウを閉じる。リボンメニュー「表示」⇒「Windowの再表示」で再表示できる場合とロスとしている場合がある。
③当該のExcelを閉じる（保存されていない場合は保存するかどうか確認するダイアログが表示される）
④効果なし。
恐らくプログラムが現在参照している項目などで動作が異なるんだろうけど、同じ条件（のつもり）でも再現したりしなかったりするので正直よく判らない。
