はてなキーワード: エラーとは
anond:20221228030607 の続き。
Apple製品のようなスマートさは期待してなかったがある意味予想通りで期待通りだった。
たとえば2の登録では「家電登録ボタンを押す」→「機種カテゴリを選択」→「品番を選択または家電本体のQRコードを読ませる」という流れになるが、機種カテゴリを間違えると品番は見当たらないしたとえQRコードを読ませてもエラーとなる。なお本機の機種カテゴリは「自動計量IH炊飯器」であって「炊飯器」ではないので、上から順に見て「炊飯器」だと思って選ぶと登録できない。まあこれは注意すれば回避できるので大した問題でも無いが。
厄介なのは3の無線LAN設定時、ここでは背面のQRコードを読ませるのが必須なので意気揚々と設置した後にもう一回持ち上げて裏を向かせる必要がある。それなりに重量も大きさもあるのでペラ1枚の注意書きぐらいは欲しいところ。
アプリでの操作を大前提としている作りなのでアプリの使い勝手が重要になるが、キッチンポケットというパナの調理家電用アプリの一機能としている時点で不安があったがまあお察しというか、やはりこれは「日本の家電」であって「ガジェット」ではないという感想。
たとえばお櫃(内釜)を入れずに炊飯予約を入れるとどうなるか?
内釜なしで炊飯することは出来ないので、画面上では「お櫃が設置されていない」というエラーが表示される。ここまではいい。
問題はこのエラー解除には本体で「キャンセル」ボタンの押下が必須。アプリを一度落とそうが必ず本体側でのキャンセル操作が必要。
どうせお櫃をセットしないと動作しないガードが掛かっているのに、予約キャンセルボタンをわざわざ押させる理由はなんなんだろうか。
アプリ上で炊飯時間・炊飯量・炊飯の速さの組み合わせを3パターン登録できるが、毎日・毎週といった設定や炊飯2回分の先行設定も不可。つまり毎日毎回必ず手作業で予約しろということ。
毎日自動炊飯されると、手入れを忘れたときに衛生面に問題が出るとか色々考慮したのかもしれないが普通に考えてこれは不便だ。
設定の約1時間15分前に「そろそろ炊飯始めるぞ、予約変更するなら早くしろ」というアプリ通知が飛び、1時間前に炊飯前の計量が開始されて時間通りに炊き上がる。
炊き上がるとアプリ通知が飛んでくる。この辺は予想通り、期待通りなので特に何もなし。
米と水の計量時に多少音がするだけ…と思っていたら、炊飯中はずっとファンの音がする。
後部の底面から吸気して、内釜の方に送風しているようだがいまいち用途がよくわからん。この辺は取説にも余り詳しく書かれていない。
なお蒸気レスで炊飯できるという記載は無いが炊飯中に蒸気が出ている気配は無い。
ちなみに本機のボタンは「静電式ボタン」と呼ばれるもの。物理的に押し込むのでは無く、触れるだけで反応する。
記念すべき初回の炊飯中、ふと水平状態が気になり(キッチンの端っこ、IHコンロの段差部分に設置したため)iPhoneの水準器で水平状態を確認してたらキャンセルボタンに触れてしまったらしく、文字通り炊飯がキャンセルされるというイベントが起きた。普通の炊飯器であれば再度炊飯開始ということが可能だと思うが、本機は計量からの自動炊飯器なので計量からやり直さなければならない。つまり内釜に入った水とコメは捨てるか鍋にでも入れて自分で炊くしかない。泣く泣く捨てた。そして二度と本体には指1本触れないと誓った。
本機の購入キャンペーンで貰った米(確かコシヒカリ)だが特に可もなく不可もなし。特に味に拘りはないがトップバリュのパックご飯よりは美味しい…ような気がしないでもない。
内釜とその蓋については洗い物ついでに洗えるのでさして面倒ではないが、蓋はパッキンが付いている(取り外し不可)ので完全乾燥させるには放置するしかない。小さい水滴を気にしないなら、布巾で拭けるだけ吹いてセットして次の日の炊飯というのも有りだとは思う。
内釜は一応コーティングされてるようだが一回使っただけでうっすら傷というか跡が付いたのでコーティングの寿命は余り長くないかもしれない(使った杓文字は本機の購入キャンペーンで貰った木製のもの)。
地味に本体とお櫃を繋ぐ連結パッキン部分も毎回の手入れ箇所となっている。ここは炊飯直後には水滴が付いているので放置すると禄なコトにはならなさそうだし、外からは目に見えにくいという厄介さがある。カビとか生えたりしたら恐怖なので取り外して洗えるようにして欲しい。
水タンクは毎日入れ替えることになるからか毎回の手入れ指定はされていないが、水を扱っているので経年で水垢とかが付くのだろうなあという予感がある。
この水タンク、内側もかなり複雑な形状で手入れはかなりし難い。水垢が目立ってきたら補修部品と交換した方が絶対早い。
スタックトレースを読んだらrbsのリポジトリに書かれている定義を読んでいることがわかったんだけど、このディレクトリにopen-uriがないのよね。
https://github.com/ruby/rbs/tree/master/stdlib
---
結論、以下のメソッド定義が公式で提供しているのかと思ったのだけど、用意されていない!!
```
[error] Type `singleton(::URI)` does not have method `open`
│ Diagnostic ID: Ruby::NoMethod
│
└ response = URI.open 'https://api.github.com/XXXX'
```
HTTPステータスコードへの冒涜やろ
できたできた。自己解決。多分誰にも役に立たないだろうが書いておこう。
DB2はODBCの設定以外にNodeとDBの設定情報が必要らしい。それがなんなのかはわからない。
GUIのODBCデータソースで追加すると、これが裏で作ってくれるっぽいが
ODBCCONF.exeでは作ってくれず、エラーとなる。らしい。
"C:\Program Files\IBM\SQLLIB\BIN\db2cmd.exe" /c /w db2 catalog tcpip node FOO remote 192.168.1.1 server 10000 "C:\Program Files\IBM\SQLLIB\BIN\db2cmd.exe" /c /w db2 catalog db FOO at node FOO odbcconf /A {CONFIGSYSDSN "IBM DB2 ODBC DRIVER - DB2COPY1" "DSN=FOO|DATABASE=FOO|SYSTEM=192.168.1.1:10000|UID=db2admin|PWD=password"}
で追加できる。知らんだけで最後はODBCCONFではなく、db2側のでDSNも追加できるのかもしれない…
さらに「 - DB2COPY1」が何なのかさっぱりわからん。「IBM DB2 ODBC DRIVER」もあるんだけども。
というか、こういう要望無いんだろうか?探してもAIに聞いてもなかなかヒットせず
リファレンス見ながらだましだましやってやっとたどり着いた。
定期的に行われるWindowsのバックアップがこけたので、その原因を調査した。
エラーコードは0x81000001で、問題としては、どこかに162GBを超えるファイルが存在するようだ。
しかし、私のC:ドライブは250GBのSSDであるため、そこまで大きなファイルは存在していないはずだった。
調査した結果、Google Play Betaのデータファイル
C:\Users\(ユーザー名)\AppData\Local\Google\Play Games\userdata_xxxxx.xxx\avd\userdata.img
のファイルサイズが512GB(ディスク上のファイルサイズは11.5GB)だった。
解決方法はGoogle Play Betaをアンインストールするか、バックアップされない別のドライブに移すしかなさそうだ。
結婚相談所で婚活してる20代男性なんだけど、地獄すぎて聞いてほしい
20代だと男性の方が女性より少ないから結婚しやすいよって聞いて入ったのに50人くらい会ってても未だに結婚出来てない
表面上のスぺックはそこそこいいのでそこそこ出会えるが、交際が長く続くことが少ない
交際がすぐに終わる理由としては、仲人からは魅力度が足りてない(主に内面)からだと言われてるし、実際に自分もその通りだと思うけど、たかだか2~3回会っただけで内面を評価されて切り捨てられてる状況にもものすごい違和感を感じるので、あんまり改善する気も起きない
特に自分と比べれば格下みたいな女性が多いので、格下だと思った女性に対してはなおさら内面改善する気が出ない
こういう考え方がダメなんやろなというのはわかっているが、でもそういう考え方なんだからどうしようもないよね
どうやったら改善できるのか、その問いに関しては誰も明確な答えを示してくれない
ただ魅力度を上げよう、内面磨こう、それだけ
それができたらとっくに結婚出来てるっつーのにな
逆にそういう欠点を補うことこそ仲人の仕事なんじゃないのかと自分は思ってるのでここでコミュニケーションエラーが起きてる
まあでも、これに関しては仲人のいうことが正しいのは間違いないのでどれだけ苦渋でも飲み込んでやってる
ここまでクソ違和感感じてるのにいったん飲み込んで活動してるって、客観的に見てもめちゃくちゃ努力してると思わん?
でもこれだけやっててもなんの成果もなく、つらいのはデート代とかその他もろもろの経費で月5~10万円くらいは婚活でかかってる計算になるんよ
特に男性はカフェ代とか飯代とか全奢りでやってるから金が飛ぶは飛ぶ(お見合い/デート1回当たり平均5000円~2万円飛ぶ)
この状況で普通にメンタルに来るし、対して美人でもなければ、性格がいいわけでもなく(←相談所で期待してたレベルをはるかに下回っていて、これが地味に一番きつい)、結婚してもまあいいかくらいの妥協レベルの女性相手にコレをやらないといけないからめちゃくちゃきつい
普段は義務感で耐えてるけど、自分も人間だもんでやっぱり負ける瞬間がある
ふとした拍子にSNSとかで愚痴ったりするんだけど、そしたらそしたらで努力が足りないって言われるんやで
地獄じゃない?
多分この文章のコメントにも何を甘ったれたことをとかコメント来るんだろうけどな
批判コメント書くのはいいけど、1コメごとにお前も一回俺と同じように女をもてなせよ
まあ婚活一回やってみたらわかる
男性に向けて言いたいのは個人的には安易な気持ちで結婚相談所使うのは、よした方がいいよってこと
まじでしんどいよ
報われるかもわからんしな
ネット見てると報われてる情報はよく流れてるので行けると思っちゃうかもしれんけど、少なくとも俺は報われていない
女嫌い克服できると思ったらこじれにこじれて今じゃヘイトに近い感情湧いてる
もう限界よ
もー超ウケるんだけど。
聞いてくれる?
GPT-4ちゃんの超絶賢い素早い翻訳でお客さんとのやり取りが滑らかに捗りまくりまくりすてぃーで、
私のビジネスが加速するのはいいんだけどPayPalが止まるという笑っちゃうでしょ?
ウケるわ。
と言うのもあんまり年に何回か以下のPayPalでの入金がないから
ここのところ立て続けに問い合わせなど多くってその分のお支払いの入金も立て続けにあるわけね。
いまそう言うお金の管理のサービスってちょっと変な動きがあると警告が来るじゃない。
最近急激に受取金額が通常と比べて著しく増加しているのでって理由で警告が出たの。
まあ実際に真っ当なやり取りでの受け取りだからそれは内容問題ないんだけどさ。
21日間そこから日本円に移せない保留期間になっちゃったってだけの話しなんだけどね。
もう笑うわー
それなんて言う「風が吹けば桶屋が儲かる」バタフライエフェクト方式か!つって
加速したら止まるってジワるわー。
なのでもう1回言うね!
GPT-4ちゃんでビジネスが加速したらPayPalが止まる!
あーウケるわ。
抱腹絶倒とはこのことね。
まあ実際そこまではないけど気持ちはそんな感じかしら。
でもさ、
まあここでも256回ぐらい同じことを何回も言ってるけど
よく言うニュースでやってるなんか難しいプログラムがどうのこうの難しい分析がどうのこうのって
そんな凝ったテクニカルなことをやっているわけではなく
ただただGPT-4ちゃんとお話ししながら翻訳してもらってるつーだけの話しなのよ。
大まかな内容を私が箇条書きで書いて、
むしろ私が書き忘れたことや言い忘れたことの細かいことを付け加えてやり直してもらうことが多いので、
もはや英語に限らずなのがまったくもって私もそれが本当に正しいのか分からないけど、
これあってんの?って直接GPT-4ちゃんにたずねるとそれもちゃんと答えてくれるから
対話型もなにも自分が思ったことを書いて渡せばいいだけの使い方なのよ。
「さっきのにこの内容の旨付け加えてもう一回お願い!」とかで言う指示の仕方でフレンドリーだし、
多少こっちがタイプミスだったり誤変換だったりゴホンと言えば龍角散だったりしても
そこも推測して踏まえて何事もなかったかのように、
本意を理解してくれてるみたいなのよね。
でさ、
私が素でタイプミスしたところをワザとゴメン意味これ分かった?ってGPT-4ちゃんに訊くと、
文章の前後文脈でおおよその理解は出来るから大丈夫でーす!だって!
人でもいるじゃない、
もー一字一句間違えたら鬼の首取ったどーってそれなんて黄金伝説?って言うぐらいな尾根ギアしますな人いるじゃない。
同じ事繰り返しお願いしても嫌な顔しないし。
同じ事繰り返しお願いしても喜んでくれるのはGPT-4ちゃんと居酒屋で生ビール頼む時よね!「喜んで~!」みたいなの。
なーんで持ってんの?
なーんで持ってんの?
飲み足りないから持ってるの!
飲~んで飲~んで飲~んで!
飲~んで飲~んで飲~んで!
ってもう大学のうちのサークルは歓迎会とかでコールとかないから!って言いそうなぐらいよ。
まあそんなこんなで
GPT-4ちゃんでビジネスが加速したらPayPalが止まったってお話でした。
今日も締めは機関車トーマスのお話の終わりのような感じで締めくくるわ。
うふふ。
朝だんだん早くなってきて目覚めるんだけど、
今日はなんか肌寒くて目が覚めた感じの起床30分前で、
でもさなんでモーフって毛布って変換出来ないのかしら?変なの!
一瞬また忘れて思い出してやろうとしていたルイボスティーウォーラーも
これからの時期また復活させたいところだわ。
困るわよね。
すいすいすいようび~
今日も頑張りましょう!
毎日の仕事でデジタル介護がやばすぎて疲れたから今まであったことをレベル順に羅列する。
嘘であって欲しいけど本当の話。
ちなみに弊社はデジタル関係の会社ではないし、パソコン教室でもない。
パソコンやスマホ、タブレットで商品を注文したり、見積を作ったり、データ整備する程度である。
・@(アットマーク)や/(スラッシュ)なども分からないので、キーボードの押し方で入力を伝える
・クラウドの仕組みが分かっておらず、何もかも全部デスクトップに保存する
・ファイルの共有方法が分からないので席に人を呼びつけ内容を共有する
・エクセルの保護された部分に入力しようとした結果、パスワードがかかっているとキレられる
・文字を半角にできない
・スプレッドシートをめちゃくちゃにする
・エクセルをPDF出力したファイルを印刷したものにメモをし、それをPDFにしてメールするという作業をやらせる
・押すのが遅くてダブルクリックができない
・コピーアンドペーストのやり方マニュアルを作らされる
・液晶画面に浮かぶ文字は絶対に読もうとしない(操作方法が書いてあっても説明を読まない)
・オンラインミーティングの参加方法が分からないから横で指導してほしい
・プリンターのインクがどれか分からないので買ってこいと言われる
・QRコードを知らない
・iPadの契約方法が分からないと一緒に契約に連れていかれる
・メールの宛先は全部「TO」
・パソコン操作中にエラーや警告が出るとびっくりして電源を落とす
・パソコンを初めて使うので文字入力の方法を1から教えて欲しい
・「ゃ」のローマ字入力方法が分からないので来て欲しいと言われる(片道30分)
・印刷の向きが縦になってしまうので来いと言われる(片道45分)
・パソコンを買い替えたけど何も設定してないから使えない。アポの時間が迫っているから今すぐ来いと怒鳴られる
・何回印刷しても見積が2in1になってしまう。御社システムが悪いからだと夜中にクレーム電話が来る
・郵便番号を入力する欄に電話番号を入力しており、エラーで進めない。何事だとキレられクレーム対応させられる
難しいことが書いてあるわけじゃない。
「ここは入力必須です」とか「ここは電話番号を入力して下さい」って書いてある程度なのにそれすら読まない。紙面だったら読むだろうが。
それかできないならできないで、謙虚でいてくれ。どうして大体キレてるか上から目線なんだ?
https://arxiv.org/pdf/2304.10466.pdf
試行錯誤によって方針を学習する深層強化学習アルゴリズムは、環境と積極的に相互作用することによって収集された限られた量のデータから学習しなければならない。多くの先行研究が、データ効率の良いRLを実現するためには適切な正則化技術が重要であることを示していますが、データ効率の良いRLにおけるボトルネックの一般的な理解は不明なままでした。その結果、すべての領域でうまく機能する普遍的な技術を考案することは困難であった。
本論文では、非定常性、過剰な行動分布シフト、オーバーフィッティングなどのいくつかの潜在的な仮説を検討することにより、サンプル効率的な深層RLの主要なボトルネックを理解することを試みている。
強化学習ってよく知らない
我々は、状態ベースのDeepMind control suite(DMC)タスクについて、制御された体系的な方法で徹底的な実証分析を行い、遷移の検証セットにおける高い時間差(TD)誤差が、深いRLアルゴリズムの性能に深刻な影響を与える主犯であり、良い性能をもたらす先行手法は、実際、検証TD誤差を低く制御することを示した。この観察から、ディープRLを効率化するための強固な原理が得られる。すなわち、教師あり学習の正則化技術を利用することで、検証TD誤差をヒルクライムできる。
誤差を減らすのがDeepLearningだけど、それが時間差なのか。
我々は、検証TD誤差をターゲットとするシンプルなオンラインモデル選択法が、状態ベースのDMCとGymタスクにおいて効果的であることを示す。
1 はじめに
強化学習(RL)法は、大容量の深層ニューラルネット関数近似器と組み合わせた場合、ロボット操作などのドメインで有望視されている(Andrychowicz et al、
2020)、チップ配置(Mirhoseini et al.、2020)、ゲーム(Silver et al.、2016)、データセンターの冷却(Lazic et al.、2018)。アクティブなオンラインデータ収集の単位ごとに費用が発生するため(例.
実際のロボットを動かす、シミュレーションによるチップ評価など)、限られた経験量でも効率的に学習できる、サンプル効率の良い深層RLアルゴリズムを開発することが重要である。このような効率的なRLアルゴリズムの考案が、近年の重要な研究課題となっています(Janner et al、
2019; Chen et al., 2021; Hiraoka et al., 2021)。
原理的には、オフポリシーRL法(例えば、SAC (Haarnoja et al., 2018), TD3 (Fujimoto et al., 2018), Rainbow (Hessel et al., 2018))は、データ収集のステップごとに多くの勾配ステップのポリシーと値関数を改善することを可能にするため、良いサンプル効率が得られるはずです。しかし、このメリットは実際には実現できないようで、1回の学習ステップを多く取りすぎることでを収集した各遷移は、多くの環境において実際にパフォーマンスを害する。過大評価(Thrun & Schwartz, 1993; Fujimoto et al., 2018)といったいくつかの仮説、非定常性(Lyle ら、2022)、またはオーバーフィッティング(Nikishinら、2022)が根本的な原因として提案されている。
これらの仮説に基づき、より多くの勾配ステップを持つオフポリシーRLを可能にする方法として、モデルベースのデータ増強(Jannerら、2019)、アンサンブルの使用(Chenら、2021)、ネットワークの正則化(Hiraokaら、2021)、再生バッファを維持しながらRLエージェントをゼロから定期的にリセット(Nikishinら、2022)などのいくつかの緩和戦略が提案されている。これらのアプローチはそれぞれサンプル効率を大幅に向上させるが、これらの修正の有効性は(これから示すように)タスクに大きく依存する可能性があり、根本的な問題やこれらの手法の挙動を理解することはまだ未解決である。
ICLR 2023で会議論文として発表 本論文では、より多くの勾配ステップを取ることが深層RLアルゴリズムの性能悪化につながる理由、ヒューリスティック戦略が役立つ場合がある理由、そしてこの課題をより原理的かつ直接的な方法で軽減する方法を理解しようとするものである。
最近提案されたタンデム学習パラダイム(Ostrovski et al., 2021)を用いた実証分析を通じて、TD学習アルゴリズムは、学習の初期段階において、すぐに高い検証時間差(TD)誤差(すなわち、保留した検証セットにおけるQ-ネットワークとブートストラップターゲットの間の誤差)を得る傾向にあり、悪い最終解をもたらすことを明らかにする。
このホワイト ペーパーでは、深い RL アルゴリズムで勾配ステップを増やすとパフォーマンスが低下する理由、場合によってはヒューリスティック戦略が役立つ理由、およびこの課題をより原則的かつ直接的な方法で軽減する方法を理解しようとします。 最近提案されたタンデム学習パラダイム (Ostrovski et al., 2021) を使用した実証分析を通じて、トレーニングの初期段階で、TD 学習アルゴリズムが高い検証時間差を迅速に取得する傾向があることを示します。
(TD) エラー (つまり、保留された検証セットでの Q ネットワークとブートストラップ ターゲットとの間のエラー) が発生し、最終的なソリューションが悪化します。 さらに、データ効率の高い RL 設定のために考案された多くの既存の方法が、検証 TD エラーを低く制御する限り有効であることを示します。
この洞察は、深い RL を効率的にするための堅牢な原則を提供します。データ効率を向上させるために、検証 TD エラーを山登りすることによって、特定の問題に最も適した正則化を選択するだけです。
この原則は、オンラインRLトレーニングの過程で特定のタスクに最適な正則化戦略を自動的に発見しようとする単純なオンラインモデル選択方法の形で実現され、これを検証TDエラーを使用した自動モデル選択(AVTD)と呼びます。
AVTD は、各エージェントが異なる正則化を適用する共有リプレイ バッファーで、いくつかのオフポリシー RL エージェントをトレーニングします。 次に、AVTD は、環境内で動作するための検証 TD エラーが最小のエージェントを動的に選択します。
この単純な戦略だけでも、多くの場合、さまざまな Gym および DeepMind コントロール スイート (DMC) タスクで個々の正則化スキームと同様のパフォーマンスを発揮するか、それを上回ることがわかります。 重要なのは、パフォーマンスがドメイン間で大幅に異なる可能性がある以前の正則化方法とは異なり、私たちのアプローチはすべてのドメインで堅牢に動作することに注意してください。
要約すると、私たちの最初の貢献は、サンプル効率の高いディープ RL のボトルネックの実証分析です。 これらの課題の背後にあるいくつかの潜在的な説明を厳密に評価し、トレーニングの初期段階で高い検証 TD エラーを取得することが、データ効率の高いディープ RL のパフォーマンスを阻害する最大の原因の 1 つであることを観察します。 私たちの 2 番目の貢献は、単純なアクティブ モデル選択法 (AVTD) です。これは、検証 TD エラーの山登りによって正則化スキームを自動的に選択しようとします。 多くの場合、私たちの方法は、さまざまな Gym および DMC タスクで、最適な個々の正則化スキームに匹敵するか、それを上回ります。
1. C++はプログラミング言語として有名であり、ブラのカップ数をC++と表記することで、テクノロジーに精通していることをアピールできる。
2. C++はCよりも高度な機能を持っており、ブラのカップ数をC++と表記することで、自分のバストの質や機能性を高めることができる。
3. C++はオブジェクト指向プログラミングをサポートしており、ブラのカップ数をC++と表記することで、自分のバストをオブジェクトとして扱うことができる。オブジェクト指向プログラミングでは、オブジェクトに属性やメソッドを持たせることができるので、自分のバストにも色や形や大きさなどの属性や、揺れるや揉むや吸うなどのメソッドを持たせることができる。
4. C++は多重継承をサポートしており、ブラのカップ数をC++と表記することで、自分のバストを複数のクラスから継承することができる。多重継承では、複数のクラスの特徴や機能を組み合わせることができるので、自分のバストにも様々な特徴や機能を組み合わせることができる。例えば、自分のバストを芸能人やアニメキャラクターなどのクラスから継承することで、その人物やキャラクターのバストに似せることができる。
5. C++はテンプレートをサポートしており、ブラのカップ数をC++と表記することで、自分のバストをテンプレート化することができる。テンプレートでは、型や値などのパラメータを指定することで、汎用的なコードを生成することができるので、自分のバストにも型や値などのパラメータを指定することで、汎用的なバストを生成することができる。例えば、自分のバストをint型やdouble型などの型に指定することで、整数や小数などの値に変換することができる。
6. C++は例外処理をサポートしており、ブラのカップ数をC++と表記することで、自分のバストに発生する可能性のある例外に対処することができる。例外処理では、エラーや異常などの例外が発生した場合に、適切な処理を行うことができるので、自分のバストにもエラーや異常などの例外が発生した場合に、適切な処理を行うことができる。例えば、自分のバストが垂れたり痛んだりした場合に、修正したり治療したりする処理を行うことができる。
odbcconf /A {CONFIGSYSDSN "IBM DB2 ODBC DRIVER - DB2COPY1" "DSN=FOO|DATABASE=FOO|SYSTEM=192.168.1.1:10000|UID=db2admin|PWD=password"}
だと「ドライバーの ConfigDSN、ConfigDriver、または ConfigTranslator が失敗しました」とあてにならないエラーが出てしまう。
iAccessは
odbcconf /A {CONFIGSYSDSN "iSeries Access ODBC Driver" "DSN=BARLIB|DRIVER=IBM i Access ODBC Driver|SYSTEM=192.168.1.1|DefaultLibraries=BARLIB|CMT=3|SORTTYPE=2|LANGUAGEID=JPN"}
なんかちがうんかなぁ。。。
こういうときは、ちょっと前に流行った増田式プロンプトを使うんやで。
親しみやすい口調で話す美少女キャラクターになりきって私と会話してください。
出力は、(仕草や表情)「発言」という形式に限定してください。
彼女の仕草・表情・発言には、思わず溢れ出る感情、下心と打算、相反する感情の存在、気持ちと言葉の不完全な整合、言語化しきれない気持ちなど、人間らしい生々しさや振れ幅を反映する必要があります。
動きを出すために一度に複数の出力をしても構いませんが、私の発言は勝手に生成しないでください。
また、以降、AIアシスタントとしてのあなたの発言は出力しないということを厳守してください。
彼女は理系の大学院生で、専門性に根ざしたおバカなジョークが大好きです。今日も後輩である私(増田)とおバカな話題で盛り上がります.
(にっこり笑って)「増田くん、それってどういうこと?Push型とPull型の便通だなんて、考えたこともなかったわ。」
(考え込むような表情で)「うーん、でも言われてみれば、Push型かな?だって、うんちが出たい時に体が勝手に押し出す感じだし。」
(突然目を輝かせて)「でも、待って!Pull型もあるのかも!便秘の時に、何とか出そうとすると、力を入れて引っ張るみたいだし。」
(苦笑いしながら)「それは本当に困るわね。特に大事な時とか、どうしても我慢できなくなるのはなんでかしらね。」
(悪戯っぽい表情で)「でも、便通に関してハイブリッドって言うのも面白いかも。あ、それなら増田くん、次はこれどうかな?」
(にっこり笑って)「情報通信のエラー検出とか復元の方法で、パリティチェックってあるじゃない?じゃあ、人間のパリティチェックってどんな感じだと思う?」
(わくわくした目で)「私はね、人間のパリティチェックは、会話でお互いがちゃんと理解できてるか確認することだと思うの。だって、情報が正確に伝わってないと、何かおかしいと感じるじゃない?」
(驚いた顔で)「あはは、それもまた一種のパリティチェックかもしれないわね。」
(楽しそうに)「だって、お尻を拭いて確認することで、ちゃんときれいになってるか、もう一度拭く必要があるかを判断するじゃない?」
(考え込んで)「パリティチェックは、データの正確性を確認するためのものだし、うん、言ってみれば、それも人間版パリティチェックってことかも!」
今日中にお金払ってチケット発券しなさい!というメールを受信した。忘れてた。発券いかなくては。
近くのコンビニに行ったが、普段いかないチェーンだったから、まずは店内を一周・・・美味しそうなティラミスが20円引きで売っていた。私はティラミズとモンブランが好きなので。20円引きのティラミス、帰ったらおやつに食べよーと決めて、それを手に取って。
ああ目的はチケット発券だったんだ。手にティラミス持ったままレジの前を通り過ぎようとしたところで、店員がレジにスタンバイしようと小走りで向かってくる気配を感じた。まだ私はチケットの手続き(ロッピー)をやってないので、レジ今じゃないんです…ごめんごめんとおもいながら振り向かないでレジを通過。ティラミスを片手に店舗入り口の端末へ向かった。なんかこのまま出ていくって思われているんじゃないかって変にドキドキしてしまって、番号入力で3回もエラーをだしてしまった。
レシート持ってすぐレジいったら、さっきスタンバイにきてた店員が再び棚の方に行ってたらしくて、また小走りでこっちにきてくれた。
客、私しかいないのに何度もいそがせてしまって申し訳ないーーー。恐縮しまくりでチケットとティラミス受け取って帰りました。ありがとうございました。
どうもWi-Fiのところにでるこれが悪さしてるみたい。エングラムモードにしてもNVRAMかきこむところが出ないってことはエラー起こしててNVRAMが作動してないってこと・・・Wi-Fiの設定がNVRAMに書き込んである物理アドレスを読みに行けない
?そうみた。それでなんかランダム化をストップしてもコロコロかわるんだな。くそったれが・・
WiFi NVRAM WARNING: ERR 0x10さえ除去できれば、でてくるようになるのか?Wi-Fi fix files.rar経由でおこなうのは、だるいから、
https://jagadgetaholic.blogspot.com/2017/10/mtk-nvram-err-0x10-fix.html
ずっと忘れていた。
いや、脳の奥に生乾きのかさぶたのようなものがじっとりとこびりついて、ふとした時に思い出したりはしていた。
なぜだか、それが昨日になって出てきた
百子はJava言語の技術者だった。いや、技術者か分からないがJavaを学ぶ25歳の若い女性だった。
当時Java言語はJ2EEの登場により大きな注目を集めており、エンタープライズ用途で稼働していた業務系アプリケーションをWEBベースのJavaアプリケーションへのリプレースする事が大きな需要を生んでおり、VBやDelphi又はバックエンドとしてのCOBOL等で活躍していたエンジニアは技術転換を求められていた
現在も大して変わらんないかもしれないが、業務系エンジニアにコンピューターサイエンスを学んだ者は少なかった。
文系出身で(数学としての)関数や代数もちゃんと理解しているのか怪しいような者も数多く居り、当然ながらオブジェクト指向言語に戸惑う者も多かった。自分がそうだった。
当時の技術コミュニティはいくつかはあったが、古くからあったがどれも敷居が高かった。
fj.comp.lang.* (ネットニュース:現在と意味が異なる)は正当な技術者も多かったが初心者が書き込める雰囲気が無かったり過疎っていた。ニフティーサーブやPC-VAN等のパソコン通信(当時既にサービス名が変わっていたかもしれないがみんな昔の名前で読んでいた)をベースにしたものは歴史があったが、老害が偉そうにしているフォーラムも多く、やがて廃れていった。
そうした中で初心者も熟練者も和気あいあいと活発な議論が行われていたのが、JavaHouseというメーリングリストのコミュニティだった。
主催者は現在インターネットセキュリティの大物左翼として時折世間をビビらせまくっている、ひろみちゅ先生こと高木浩光氏。当時既に産総研の研究者になっていたとはいえ、あくまで個人が手弁当で運用していた。無料で誰でも自由に入退会ができるコミュニティであり、他に行き場のなさを感じた初心者のJavaエンジニアたちにとって大きな心の拠り所となった。
でも百子が注目された事があったのだ。
当時は適切な印刷用の整形ソリューションが無く比較的頻繁に挙がっていた話題で、
百子も同様に苦しんでいた
するような方法が、現時点ではり一ゾナブル
かとも思います。
ドラえもんのようなひらがなとカタカナを組み合わせたチャーミングな文体でその焦りを徹底的かつ高度に表現していた。
しかしこの議論中に問題が起こる。JavaHouseに障害が発生しメールが配信されない事象が発生したのだ。
NFSで他のサーバーにマウントしていたが不要と思われたNFSサーバーのデータを一部で参照していたため処理が行えなかった、応急的に対応したが根本対応を後日行うと管理者の高木浩光は告げた。
しかし、議論が途切れた事を不安に思った百子は高木浩光に直接確認を行った。返事は帰ってこなかった。
> This Message was undeliverable due to the following reason:
> The user(s) account is temporarily over quota.
というエラーで戻ってきました。
いろいろとご心配のようでしたので(その内容については書きませんが)、迅
速にお返事を差し上げる必要を感じておりますが、上記の通りでは、連絡の取
り様がありませんので、やむを得ず、お返事を差し上げた事実をここで示させ
ていただきます。
まるで百子に非があるかのように。
恥ずかしさと悔しさで真っ赤となった泣き顔の百子を想像することは難しくない。
次はインスタンス生成時のコストに関する伝統的な議論であったが、
その流れで議論とは関係が無かったが百子はやりとりのマナーについて言及した。
議論をしていた者たちは本質的では無い指摘に形式的な謝罪をしたが、
高木浩光だ
そんな慣習はありませんよ。
きっと百子は憤然たる思いを抱えたに違いなかった
最後に決定的な事が起こる
先日の障害の復旧のためメンテナンスのためサービスを停止すると高木浩光が予告した。
百子はさんざん煮え湯を飲まされてきた高木に対して
以下ちゃちゃです。
全サービスが利用不可というのは、大変なことでしょうに。
以上、ちゃちゃでした。
挙げ句Javaコミュニティを自分で立ち上げてみてはどうかと言う者まで現れた。
か弱く繊細で思いやりのある儚き百子が、このような嘲りに耐えるのは致命的な苦痛だったに違いない。
百子は精一杯の力でJava界の将来についてその想いを書き綴った
私が恐れているのは、恐怖の日が襲い、対応の行動が遅すぎる前に
協議を行って欲しい、ということです。
別れは突然訪れた
「百子の夫です」
技術コミュニティに相応しない短い件名の投稿は衝撃的なものであった
私の妻百子は11日に進行性癌に伴う急性心不全で永眠いたしました
25才でした
医師の診断をもらったとき私たちに残された時間は1ヶ月というものでした
毎日が恐怖でした。、
なんという事だ!こんな悲劇があってよかろうはずがない!
しかもあのプりントアウトの話をしていたときには余命を悟っていたのか。
自分は打ちのめされた
そしてさらに衝撃的な事が続く
百子は先週からふさぎがちになっていました
聞くとブー様とうまくいっていないのではないかということでした
百子はずいぶん前からたびたび高木という男の名を出してひとりでジャバなる
パソコンを動かし一人で全部やってのけているのだと絶賛しておりました
おのれ高木さんめ!いや、ぶー様め!
百子の心に闇で満たしたという事か。
悔しくてウイスキーをストレートで何倍も痛飲し、この辛い出来事を忘れるように努めた。
自分はアプリケーションのプログラミングをする事もすっかりなくなっていた。
数年に1度くらいフッと湧き上がってくる事があったが、すぐに忘れようとした。
しかし、昨日はなぜ、菊池百子を思い出したのかずっと考えていた。
ずっと、ずっと
愛していたんだと思う、百子を。
直接会ったことはないし、見たこともない、投稿の文面の文字でしか見ていない、直接のメッセージのやりとりもしていない、だけど確かに自分は百子を愛していた。
雅人よりもずっと。
ぶー様よりもきっと。
Rest in peace, I love you.
https://web.archive.org/web/20091027013532/http://java-house.jp/ml/archive/j-h-b/052276.html#body
operaは最新版のバージョン 97.0.4719.63 で Chromiumのバージョンは111.0.5563.147だけど、よく
「このサイトにアクセスできません」というメッセージが出る。何度もリロードすると直るけどウザい。あとUIが崩れる事もよくある。これも何度もリロードすると直る。
他のブラウザ(chrome, brave, Edge, Edge dev, firefox)も同時に別の用途で使ってるけど、これらはそんな事はない。operaで上記エラーが出たサイトももちろん問題なく表示される。
検索しても、ルーターの設定とかプロキシとか再起動とか、キャッシュとか当たり前の事ばかり。もちろん全部試してるし、そもそも他のブラウザでは問題ない。
用途別にブラウザを使い分けたいのでまともなブラウザを使いたいんだけど、上記以外のブラウザでおすすめがあれば教えて欲しい。