日々常々

ふつうのプログラマがあたりまえにしたいこと。

わからないことの調べかたを考えてみる(2018年版)

ブログの下書きを眺めてたら長文がみつかったので供養しておきます。


開発では、何かを調べることに多くの時間が費やされます。私の調べ物のやりかたや、他の人のを見て思っていることを書いてみます。

前提条件

  • 調べ物が苦手
  • 何か効率が悪い気がする
  • 調べ物に時間がかかる
  • 間違った情報に振り回されている
  • 情報が間違っているのかやり方が間違っているのかわからない

と言った方には役に立つかもしれません。 自分で調べ物ができるかた、そのやり方に疑問のない方には何の足しにもなりません。 あと私のやり方と、私から見える人の私からの見え方でしかないので、他のコンテキストは知りません。

また、ここでの「調べる」は初めて使用するツールの使い方など、未知領域の課題解決を行うためにインターネット等を検索することを指します。 実際は検索する前に意識/無意識にかかわらず課題の切り分けを行い、問題領域によって手段を変えているはずです。

調べ物のレベル

レベル感をふわっと書いてみます。

  1. 何を調べたらいいかわからない
    • 何がわからないかわからない、どう言うキーワードで調べればいいかわからない。思ったものが全く出てこず、解決しない。稀に何とかなったりするけれど、ほんと稀。
  2. 検索上位にでてきたものをそのまま試す
    • 短時間でたどり着くこともあるが、打率は低い。動かないときは「調べた通りにやったけれど、なぜか動かなかった。」でゲームセット。
  3. 検索で出てきたものを手当たり次第に試す
    • うまくいかないときは永久にたどり着かないが、当人は「いつかたどり着く」と思っていたりする。そのため「時間が足りない」と言うが、どれくらい時間があればたどり着くかの予想もできない。
  4. 検索結果をさらに自分の条件に照らし合わせてフィルタリングして試す
    • それなりの精度と質で解決できたりする。しかしなぜそれでいいかの説明ができることは稀。「出典はWikipedia」程度の信頼性。
  5. 公式ドキュメントの手順に従う
    • ドキュメントのGettingStartedなど、手順的なドキュメントがなければお手上げだったりする。
  6. 公式ドキュメントから設定を理解した上で調整する
    • だいたいの問題はクリアできる。逃れられない問題として、ドキュメントの質に依存する。記載されている箇所が見つけにくかったり、そもそもドキュメントが使い物にならないプロダクトも稀によくある。
  7. ソースコードを当たって解決する
    • (コードが使える場合)解決できる問題なら解決できないほうがおかしくなる。しかしドキュメントされていないトリッキーな解決をしてしまう可能性もある。機能を損傷したり、片手落ちな設定をしてしまったりすることもある。
  8. コンセプトを踏まえて解決する
    • 「こういうコンセプトで作られているから」から導かれる解決。「そう言うことに使うものではない」と捨てる判断も早い。ドキュメントはもちろん、経験や歴史を把握していると可能になる。かもしれない。
  9. サポートに問い合わせる
    • 金の弾丸。サポートの人に教えることになることになったり、言う通りにしたら環境が壊れたとかも稀によくあるので、万能ではない。

だいたい前段階はクリアしているので、その手段でなくても前段で解決できたりします。分水嶺は5、公式ドキュメントを読めるか。これが冒頭のツイートのラインです。4までくればそれなりの精度と質で解決できてしまうので、その辺りで満足してしまっているのも多そうな感じがしています。

Qiitaが一部の人に嫌われる理由

特定サービスを出して申し訳ない。別にQiitaに限ったことではありませんが、検索時に

調べ物をしている人を見ていると、高確率でQiitaを参照しています。検索上位にくるのはサービスの努力も大きいでしょうが、同様の問題で困った方が書いていたりするので、近い語彙なのでヒットしやすいと言うのもあるのかなと思います。

Qiitaの記事が玉石混交であると言う事実はありますが、それは他のQAサービスやブログ、情報サイトでも変わりません。 なので問題点はそこではなく レイアウトが統一されていることによる区別のつきづらさ に由来すると思います。 これは「ソースはWikipedia」と言うのが揶揄の対象となるのと近いのですが、Qiitaも同様に「Qiitaに載ってた」と言うような場合に問題になります。 つまり、記事の質は個人に由来するサービスの特性に対して、情報を判定する精度が個人に由来していないのです。

私も調べ物でQiitaを参照することは多いので、非常に助けられています。なので「Qiitaを見てはいけない」とまで言うつもりはないです。 ちなみに、私がQiitaを参照するときは「誰が書いているか」を気にしていることが多いです。

Qiitaのコンセプトを確認してみる

qiita.com

公式ドキュメントを見るべき理由

解決したときの根拠の説明ができるかが重要です。もし解決しても、なぜそれでいいのかを説明できないのであれば、それは「たまたま」でしかありません。対面していた問題は「たまたま」で解決しちゃっていいものでしょうか。再発した場合に何か対処法はあるでしょうか。他のところに影響は与えないでしょうか。などなどあります。公式ドキュメントに記載のある方法ならば、注意すべきことがあるならば記載されていることも多いです。

また、解決できない場合もドキュメントに記載がないのであれば、ある程度「仕方ない」と思えます。そう言うものを使っていると言う事実を受け止めましょう。「ドキュメントが使い物にならないもの」とわかって使うならば、アプローチの仕方も変わってきます。その判断のためにもドキュメントを参照するべきなのです。

もし、ドキュメントに記載されている通りにやってうまくいかないのであれば、バグの可能性もあります。課題管理システムにアクセスできるなら、課題登録されていないかを検索してみましょう。次バージョンのリリースノートに載っているかもしれません。ともかく、記載の通りにやっているのに動かないのであればサポート問い合わせを検討するのがいいでしょう。OSSなら「Use the Soruce, Luke」もありです。

もう一つの理由は、互換性です。ドキュメントに記載されているものは互換性が保たれる可能性が高いです。ソフトウェアはバージョンアップするものなので、互換性は重要です。ドキュメントされているものは、バージョンアップの方法もドキュメントされることが期待できます。ソースコードから得たトリッキーな解、たとえば内部APIを触ったものなどに互換性は期待できません。更新コストを抑えるためにも、提供元が予想できる使い方をすることは重要なのです。

常に公式ドキュメントを読むか

そうとも限りません。ブログやQiita、StackOverflowなどが検索上位に現れることも多くあります。これを除外するフィルタリングを常に検索エンジンで行うのは骨でしょうし、私はやったことはありません。

公式ドキュメントはピンポイントで私の問題に答えてくれるものではないため、(その瞬間に限って言えば)多くのノイズを含みます。常に公式ドキュメントだけを参照するのは時間がかかります。無限に時間があるならそれでもいいかもしれませんが、私の時間は無限ではないのです。そのため解決したい問題の性質によっては、公式ドキュメントを当たらないこともあります。

前段で「たまたま」と言いましたが、たまたまも悪いものではありません。公式ドキュメントではないにせよ同等の信頼性があると判断できる場合だとか、明確な検証方法がある場合だとか、まあ色々言えますが、ともかく。たまたまで解決できていい問題は、たまたまで解決してしまっても良いのです。ドツボにはまりそうになったら、落ち着いて公式ドキュメントを読めばよいだけです。

私の調べ方

  1. アクセスしやすい公式ドキュメントを参照する
    • Javadocコメントなどに記載されているものであれば、高精度な情報に最速でアクセスできる。検索する必要もない。
  2. 検索結果に一通り目を通す
    • タイトルだけでも。だいたいGoogle検索結果の1ページだけで、たまに2ページ目もみる。
  3. 信頼性の高い情報を試す
    • (後述)
  4. 信頼性の高い情報で得たキーワードで公式ドキュメントを検索する
    • 最初から全部舐めるのは厳しいので。

記事の信頼性判断

検索結果は玉石混交。とは言え砂漠の中で砂金


ここで終わってました。 何書こうとしてたんですかね、2018年の私……

あ、今だと「AIに投げかけてみる」ってのも出てきますね。AIの使い方の話になってきて、これはこれで一大トピックだし、それを書き始めるといつまでもこの下書きが成仏できないのでここまでにしときます。

2023年のふりかえり

ことし10本目のエントリ。

毎回このブログの1単位を「記事」と呼ぶか「エントリ」と呼ぶかとかで無駄に悩んだりします。「本記事」とか「本投稿」とかそういう、書いている文章内のスコープを指すの。 で意識的には「エントリ」を使ってるんだけど、これははてなブログのどこか(たとえばこの記入欄のURLなどにnew entryとか書かれていたりする)で使われていたからなんだけど、UIを見ると「記事を書く」とか「最近書いた記事」とかだな。えーでも「ホットエントリー」だよなぁ、でもホットエントリーははてブの文脈か。「記事」に統一したそうだから「記事」でいくか。

と、いきなり脱線したけど、別に本線もない。 本線とかいうと電車を思い浮かべるんだけど、Factorioで最近ようやく電車使った拡大を初めてて。どんどんデカくなるけど、世界はもっとでかそうだねぇ。敵(原住生物)が邪魔だけど、邪魔程度で戦い方の工夫とか要らないのがもう少しどうにかならないかなぁって。過密工場地帯みたいなの作ってないから汚染拡大もしないんだよね。ふむー。

今ブログ書こうと思ったのは、かずひらさんがなんか書いてたから。

kazuhira-r.hatenablog.com

そいやふりかえり記事とか書いてたね。

今年のふりかえり

オフラインイベント

JJUG CCC行きました。SpringとFall両方。 関ジャバやりました。

オフラインはいいね。

JJUG CCC Spring

「Webアプリケーションを作りましょう」というタイトルで、ライブコーディング。

あまりそうは見えないって言われるけど、緊張するタイプでして。通常の登壇時も心拍数爆上がりするし喉はカラカラになるし。 そんな奴が一発勝負のライブコーディングなんてやったらどうなるよってね。

笑えるほど腕が震えてほんと笑った。端末環境もあるけど、家でやったことの半分もできないでやんの。

あ、資料公開はしてないです。ライブコーディングありきだし。

オフラインイベントでの面白さはある程度あったかなぁって思いました。 これはJavaコミュ@福岡でも呼んでいただいて再演しました。

javaq.connpass.com

素敵な建物でした。おさけ飲みながらダベるのも楽しかったです。

ライブコーディングはいいんだけど、タイムアタックはオフラインイベントとしてはイマイチな感じがする。 タイムアタックなら動画撮影してYouTubeにでも置いておけばいいしねー。双方向な感じでやりたい。

JJUG CCC Fall

「Gatlingによる負荷テスト入門」というタイトルで、ビギナーセッション。これは資料公開してる。

speakerdeck.com

内容は「色々勉強するのもいいけど、まずできるところからやって眺めるってはじめ方もいいよ」というものです。 資料にもある通りなんだけど、この入門段階では実務に耐えません。全然足んないです。でもやらないよりマシではあると思います。

これは別途独立した記事を書きたいんだよねぇ。

関ジャバでもこの資料や準備を使い回して、Side:BでGatlingに比重おいてやろうとしたんだ。時間制約とかで色々はしょりました。色々。

関ジャバ

別に休止してたつもりもないので再開とか言わないって言い張ってるんだけど、再開以外のなにものでもない。

kanjava.connpass.com

オフラインイベント(要するにJJUG CCC)のたびに「やらないの?」「やりたいね」みたいな話をして、ようやくという感じです。 やってみたらやっぱいいなぁという感じ。でもオンライン勉強会の選択肢が出た以上、オフラインならではを強めたい思いを新たにしています。

「会」ですからね。

次は1月にやる予定だよー。

ゲーム

SteamとNintendo Switchでやってます。 スマホゲーは今年やってない気がするね。外出ないしなぁ。

Surviving Mars

火星でコロニーを作る。 住民は食糧や酸素や水の供給が途絶えてもがき苦しんでます。ドローンかわいい。

延々と同じマップでやる系ではなく、条件と目標を達成するチャレンジモードをこなしていく感じ。 延々と同じマップでやってもいいけど、そんな広くないし。

実績は35/80、プレイ時間は内緒。

Tropico 6

島国の独裁者になって色々やる。 独裁者で弾圧とかもできなくはないけど、やってもいいことない。

延々と同じマップでやる系ではなく、条件と目標を達成するミッションをこなしていく感じ。 延々と同じマップでやってもいいけど、島ごとに方向性決めて発展させるから、別の島でやる方が楽しい。

実績は22/40、プレイ時間は内緒。

This War of Mine

戦争に取り残された民間人を操作して生き延びる。 プレイ中は何やっても悪い方向にしかいかないし、エンディングも救われない。

オートセーブが基本で取り返しがつかない。 セーブできたらヌルゲーでつまんなくなるからやるべきじゃない。

何が楽しいかって、楽しいゲームではないね。 クリアしても達成感や解放感ってより単に気が抜けるだけだし。 でもいいゲームだとは思う。一度はやってみてほしい。一度でいいと思うと言うか、一度でお腹いっぱいになると思う。

実績は20/55、プレイ時間は内緒。

Factorio

惑星に一人で不時着、宇宙船はぶっ壊れてる。そうだロケットを飛ばそう! ……ロケットを飛ばすのが目標なんだけど、別にロケットに自分が乗るわけではない。飛ばすだけ。なんで?

なんとなく壊れた宇宙船の隣でロケットを飛ばすのが好きで、毎回こんな感じで飛ばしてる。

これマジで仕事の知識使えるし、仕事に転用できる要素も多い。 そう言う見方をすれば、だけど。

延々と同じマップでやる系。 違うマップはそれなりに違いがあって面白みもあるんだけど、大規模な鉄道運用とかやるのを違うマップで1からやるとか、ちょっとだるい。

実績は27/38、プレイ時間はマジで内緒。 「雑談する暇はない」はいけてた。「スプーンなんてない」は挑む気すらしない。

Stellaris

銀河を股にかけて、開拓したり戦争したり同盟したりする。 目標は一定期間で一位になることっぽい?

銀河間を飛び回れる文明たちでやり合うけど、そう言うのを認識していない未開の文明を観察したり気づかれたりとかそう言う要素もある。パラメタが大量にあって把握するだけでも結構なもの。ぶっちゃけ情報過多ってか、チュートリアルやっても「これなんだっけ??」ってなる。

あと不具合が多くてめちゃめちゃクラッシュする。やりはじめた時のバージョンが非常にバギーで、色々覚えていこうってタイミングでこう言う中断で水をさされるとやる気無くすよね。てことであまり遊べてない。

実績は21/174。

Plague Inc: Evolved

伝染病を進化させて人類を絶滅させる。 なおコロナ前からあるゲームである。

日本語だと「伝染病株式会社」でスマホアプリとかもあるらしい。

今日始めた。年末に何やってるの?

大学でバクテリアの遺伝子いじるのやってたから、ちらほら「あ、知って・・・・る?気がするけど、もう忘れた・・・」ってなってる。

リングフィットアドベンチャー

12月に買った。

らくしょーって思ってたら運動負荷10だった。

毎日やるのを今年の目標にしたのに、25日間で連続は途絶えた。

void tRrLM();

トリコちゃんかわいい。

まとめ

かずひらさんの記事、および元になったやんくさんの記事を読んで書き始めたのに、なんかゲーム記事になった。

yyyank.blogspot.com

まぁいいや。

アウトプットしようぜー、って言いながら自分がアウトプットあまりできてないなって。

色々事情あって仕方ないんだけど。来年は出ると思います。思うだけ。

いま使ってる音を鳴らす装置たち

なんだかんだで色々あるなぁと。音質の違いなんてわかる耳をしていない私なので、たぶん費用対効果そんな良くないんだけど、まぁ。

違う端末間で接続切り替え面倒、Bluetoothのマルチ接続もできなくはないんだけど、それやるとSlack通知音とかが別の端末で鳴ると進行中のミーティングの音が途切れたりで、微妙だからそれぞれの端末ごとに異なるヘッドホン、ヘッドセット、スピーカーを繋げてる感じ。

AKG K702

開放型?オープンイヤー?のヘッドホンを持っていないなぁと自分に言い訳して買ってみました。 ヘッドホンと言ったら密閉するものと思ってたので「へー、開放型なんてあるんだー」って感じで。

該当スレッド

音は多分いいんだろう。たぶん。他のスピーカーに繋ぎながら音楽かけてる途中でこれに切り替えると途端にシャキッとした感じで、その瞬間は音の違いはわかる、気が、する。でも3分くらい経ったらもう意識してない。

ケーブルが3mあって、これも長くて使い勝手が良い。外で使いたいなら邪魔だろけど、室内で使うものだろしね。 ただ頭頂部がバネで圧迫されるので、数時間使うと痛くなってくる。これ使い続けると血行悪くなって禿げる気がする。。。 長時間は使わないけど気に入ってはいて、気合い入れる時のルーティン的な使い方をしてます。

ヘッドセットじゃなくヘッドホン。マイクはないので、ミーティングで使う時は別途入力装置は必要。

サンワダイレクト 400-SP090

ネックスピーカー、マイク付き、ワイヤレス。

マイクの位置が右前で、左前のモニターにミーティングを映すことが多いこと相性がわるいとかあるけど、そんな重くないし概ね不自由なく使えています。 音楽は聴き比べると「あー、音楽聴くためのスピーカーじゃないなぁ」というのはわかるけど、聴き比べないとわからない。 でもわざわざこれで音楽聴かないな。もっぱらミーティング用。

Macとの接続で難があって、Mac起動直後の一発目は素直に接続できるんだけど、これの電源を入れ直して再接続すると音が鳴らない。 Mac側のBluetoothをON/OFFしたら鳴るようになる。なんだこれって思いながら使えてるからいいかってやってる。

無線だけど充電しながらも使えるので電池切れでも安心。長めのUSB-Cケーブルが必要だけど。

HiperX HX-HSCA-RD/AS

有線ヘッドセット。ゲーミングって冠してるけど、「ゲーミング」って色使いのことだと思ってる。

3年くらい前に買ってWindows端末で使ってたんだけど、いつからかマイクを認識しなくなり(他の端末だとちゃんと認識する)、これだからWindowsは……と思いつつドライバ再インストールとか試したけどどうにもならないんで諦めてMacBookProで使ってる。

ケーブルに音量調整とマイクのミュートスイッチあるんだけど、使ったら相手にノイズが鳴るとかあって使ってない。音量調整も小さくするとアナログ信号が弱くなる?ぽくて片方から聞こえなくなったりして常に音量はMAXで出力元で調整してる。

有線だから電池切れしないってのはいいよね!

Razer Leviathan V2

届いた時のポスト

サウンドバー。七色に光るから間違いなくゲーミング。

USB-Cで接続してそのまま使えるんだけど、それだと音楽に合わせて七色に光ったりはしない。 Bluetoothでつなぐと七色に光る。光を楽しみたいならUSB-Cで繋ぎつつBluetoothで繋ぐってことになる。 別にBluetoothで繋いだら不自由があるってものでもないんだけど、なんか「ケーブル繋いでるのにBluetoothで繋げるのはイマイチな気がする」で七色に光るのは諦めてる。どうせ目に入らないし……。

Sony LinkBuds WF-L900 WM

耳に入れるタイプかつ外音が聞こえるもの。 外で密閉型とかノイズキャンセルは危険なので、外の音が聞こえるやつをと。あとSonyの持ってないしーと。

確かに外の音は聞こえるんだけど、ドーナツ状の穴から聞こえる形なので、AmbieやShokzなど完全に耳を塞がないものと比べると外音の聞き取りづらさはある。 音楽止めてても会話に支障あるので、その点は期待はずれである。

左右が完全に独立しているかつ耳にかけるタイプじゃないから、メガネや髪と競合しない点はとても使いやすい。 とはいえaudio-technica ATH-CC500BT買ってからは外出時使いの座を譲り、今はほとんど使ってない。 そもそもそんな外出しないしね……。

audio-technica ATH-CC500BT

マイクがゴミ。ソフトウェアのサポートでなんとか使えなくはないって感じだけど、なんとか程度のうえ「声小さいですね」とか言われるので、ミーティングとかで無理してこれ使う理由がない。

Shokz OpenRunProを紛失してしまったので、同じような感じの&骨伝導じゃなく軟骨伝導というので買ってみた。 音楽を聴く分にはとてもいい感じで、使い勝手はOpenRunProと同じ。使い比べができてないのは残念。

外出で使うのはもっぱらこれだけど、髪と競合して邪魔。