PC自作、情報の集め方

自作PCを作る前には、情報を集める必要があります。特に凝ったPCを作ろうとすればするほど下調べは重要になってきます。

こういった情報の集め方は重要だと思いますが、ググっても今一ピンとくるサイトが引っかからなかったので、自分が意識している情報の集め方を書きます。

「調べる」以外のこと

ただググっても出てこない、という時に、自分で調べるのが本当に効率的かは分かりません。

場合によってはネット上に答えが無いということもありますし、「調べる」以外にも情報を得る方法はあります。

メーカーに問い合わせる

意外と盲点になっている方法で、特にパーツのメカニカルデータは公表されていない場合もあり、調べても、質問しても、誰も答えられないという状況はよくあります。

そういった場合には、メーカーに対して質問を投げるのが最も効率的なやり方です。

自分としては、基本的に他人に質問を投げる前にメーカー問い合わせをした方が良いだろうとも思っています。返答にかなりの確実性が期待できますし、返答の内容に関して、相手が責任を持ってくれるというのは大きいです。

友人を頼る

0番目の方法、誰かの知恵を借りるというのが一番早いです。

自作PCを本気で考えようとすると、どうしても広範囲なパーツの知識が必要になるので、調べるには相応の時間が掛かります。時間がもったいないというなら他人を頼ってみるのも良いでしょう。

そんなことするならBTOとかゲーミングノートとかでも良い気がしますが……。

2ch価格.comなどで質問してみるのも良いですが、こちらは回答が来るか確実性に欠ける点には注意が必要です。

調べ方

自分は、ただググっても出ない時には、「検索を工夫する」、「他言語の情報を当たる」、「間接的に情報を得る」、という3つの方法を意識しています。

Google検索の機能を利用する

まず基本中の基本として、Google検索を上手く使わなければ、必要な情報に辿り着くことはできません。ただググるだけでは、古すぎる情報が混ざってしまったり、似た別の情報が混ざってしまったりして、上手く情報を辿れないことは非常に多いです。

そういった際には、Google検索の機能を利用して結果を絞り込む必要があります。特に期間指定、除外、完全一致の3つは使えるようになっておくと、自作PCだけでなく、色々と役立ちます(ツール内の完全一致オプションではなく、検索ワードに対する完全一致オプションです)。

期間指定はGoogle検索のツールから、除外は除外したいワードの先頭にマイナスを置き、完全一致はダブルクォートで囲います。例えば、CPUクーラーのCryorig C1について、C1に完全一致し、同メーカーのCPUクーラーC7を除く検索は以下のようになります。

「Cryorig "C1" -C7」

以下のドキュメントには除外や完全一致以外にも詳しい説明があります。

support.google.com

この他にも、画像検索を用いることで、言語のみの検索とはまた違った形で情報を得られる場合があります。

Google検索とは違いますが、Ctrl+fでのページ内検索も併用してやることで、検索の効率は大幅に上がります。

日本語以外の情報を当たる

自作PCについての情報は、日本語で見つからなかったとしても、英語や中国語といった日本語以外の言語で落ちている場合が多いです。

読める読めないの問題があるので、自分は基本的に日本語→英語→中国語の順で調べるようにしています。

中国語に関しては調べることが少ないので何とも言えませんが、少なくとも英語ではPCパーツ関連のかなり踏み込んだ情報を取り扱う大手サイトが複数あるので、日本語よりも情報が豊富なのは確かです。

ググる以外の手段

上記のような工夫をしてもまだ情報に辿り着けないような場合、自分はYoutubeや様々な通販サイトのレビューなどを見るようにしています。

これらはGoogle検索の仕様で検索結果に表示されない場合があるので、それぞれのサイト内で検索するとまた違った情報を得ることができる場合があります。

特に自分がよく利用するのはYoutubeです。

間接的に情報を得る

検索方法を工夫をしてもどうしようもないことが多いのは、複数製品の比較や、パーツとパーツの物理的な干渉問題です。これらの情報は、普通の人間が比較する機会がまず無かったり、その特定の組み合わせについて検証している人間が居なかったりと、情報が存在する確率が低い傾向にあります。

情報が存在しない場合には、自分は間接的に情報を割り出すことをしています。

例えばCPUクーラー同士の比較であれば、別環境で同一CPUでのデータがある場合や、CPU温度と、CPUのTDP、TDWといった情報からある程度情報を割り出して比較することができる場合があります。少なくとも「2製品でどちらが優れているか」、という傾向を割り出すだけであれば、割と簡単にデータを得ることができます。

ケースやCPUクーラー、メモリといった干渉の有無を確認する際には、その製品と別の製品の組み合わせから干渉の有無を割り出せる場合があります。前述した画像検索やYoutubeでの検索は、画像や動画では実物を色々な角度から見るこという利点があるので、このように情報を得ようという場合には非常に役立ちます。

他には、メモリのヒートシンク高を商品画像から割り出したこともあります。メモリは横幅が決まっているので、意外と簡単に割り出すことができました。

ただし、情報の精度という点では直接的に情報を得た場合に敵わず、検索時間も長くなる点には注意が必要かなと思います。

まとめ

「検索を工夫する」、「他言語の情報を当たる」、「間接的に情報を得る」、「他人に聞く」、この4つが必要な情報を得るために重要な要素だと自分は思っています。

調べごと以外で

個人的には、自作PCに限った話ではなく、ブログやSNSなどで優れた情報発信者を見つけておくことが重要だと思っています。

自分は、自作PCに関してであれば、企業系のサイト以外では、自身で取ったデータを掲載しているようなサイトは信用し、2chまとめのようなサイトはほぼ信用しないことにしています。

情報を調べる際には、その発信者が信用できるかと、その発信者の動向をこれからも追うか、という観点で見てみると、より深い知識を得ることにつながるかな、と思います。

読書感想「最悪の事故が起こるまで人は何をしていたのか」

 こちらの本を読んだので、感想を書きます。

最悪の事故が起こるまで人は何をしていたのか

最悪の事故が起こるまで人は何をしていたのか

 

 有能な人が無能者になる瞬間

 普段から物知りなのに、ある知識について勘違いしていたり、緻密に計画を立てたのに、ほんの少しの勘違いから計画を台無しにしてしまったり、それまでは有能だった人間が、一瞬無能となってしまうシーンを、自分は日常の中で多々見かけます。

 

 これが内輪の話であれば、その失敗は笑い話になったり、あるいは記憶にも残らずに忘れ去られ、その人の評価は"有能な人"のままです。 しかし、これが外部を巻き込む話であれば、その規模が大きければ大きいほど、どれだけの能力を持った人間であっても、一瞬の無能が一生のレッテルへと変じます。

 

 自分はこの本を読んで、その一瞬の無能こそが最悪の事故を引き起こす原因だという事実と、 同時に、その一瞬から一個人が逃れることの難しさを感じました。

どれほど低い確率でも、0でないならそれは起きるということ

 この本では、様々な事故の発生するまでの過程が描かれますが、その中に共通しているのは、そこに『誰かを害してやろう』だとか『誰かを不幸にしてやろう』なんていう悪意は一切無く、ただ大勢の人間の「無知・無能・無関心」が積み重なっていく様子しか無いという点です。

 

「無知・無能・無関心」は、たった一つでもシステムを壊滅させ、破壊をまき散らす可能性を持っているものです。 それが沢山集まったなら、例えどれだけシステムが危険性を排除したとしても、可能性は0ではなくなり、そしていつかコトが起きてしまう――その過程が、この本では余すところなく描写されています。

 

 本文中で語られる、「現在の機械やシステムというものは複雑で巨大なものとなり、その管理のためには一個人ではどうしようもない程の知識と能力、そして危機への警戒心が必要となっている」、という筆者の主張に、自分は強く同意します。

個人が努力し、それでも無知のは当たり前、問題はその更に先

 自分は、重大な事故の後で現場の人間を責める人間も多々見かけます。 しかし、自分はこの本を読む前から、この主張は大部分が間違ったものであると感じていました。

 少なくともある個人の取った行動が訓練の通り、もしくは訓練されたものでなかったとするなら、それによる事象に対する責任は、個人の教育に責任を持つ組織に帰せられるべきものであり、またそれに関わった個人が専門家として十分な知識を持っていたという実例は多くあるからです。

 

 

 この本を読んで気付いたことは、このような状況が生まれる背景には、「とてもよく訓練された個人の集団というだけでは管理できない物が数えきれないほどにある」という事実と、「その事実に気付き、危機感を持ち、本気で改善しようと考えられる人間は思ったよりも少ない」という事実があるということです。

 そして、例えそれらの事実に気付いていたとしても、可能性が0でないのなら、自分もまたいつか『無能者』になりかねない事実についても気付かされました。

 

 この本を読んだ感想として、また自分の意見として、「重要なのは問題を未然に防ぎ、それを評価するシステムだ」ということを強く感じています。前述の通り、既に今世の中にある物の多くは、「とてもよく訓練された個人の集団というだけでは管理できないもの」だからです。

「優秀な副操縦士

 この本の中では、パイロットの人的過失による航空事故において、副操縦士が果たす役割について触れている項目があります。 それによると、重大な事故においては、運航に遅れがあり、機長が操縦していて、経験の浅い副操縦士が機長のミスを指摘できないでいた、という状況が余りにも多いということでした。

 これは機長や副操縦士が無能だったという話ではなく、機長が気付かない部分を副機長が気付いたか、気付いたとして、修正に移ることができたのか、という話です。

 

 この本の中ではこの事実を基に、「ズケズケとものを言う腕利きの副操縦士」が事故防止には重要だという主張が登場しますが、これこそが危機管理とそれに関するシステム構築の最大の課題だと自分は感じました。

「ズケズケとものを言う腕利きの副操縦士」には、危機を察知できるだけの注意力と、危機と対策を判断できるだけの知識と、自分よりも知識があるであろう人間に、その場で先んじるだけの行動力が必要になります。

 

 自分は、危機管理のシステムにおいて最後に重要となるのは、「権威に対しても屈せずに危険を指摘する人間」だと、この本を読んで感じました。

 この本の中では、洗練された危機管理のシステムがありながら、それを権威が無視させた結果としての大惨事も多く紹介されます。 そしてその権威とは、例えば年齢であり、利益であり、日程でありました。 つまり、上は権威を振りかざさず、下は権威に逆らってでも行動できる風土こそが、事故の予防には必要なのだろうと、自分は感じます。

自分は「優秀な副操縦士」で在れるだろうか

 自分はまだ大学生で、決定的な判断に関わる機会は少ないです。 しかし、実際に他人の『一瞬の無能』に立ち会う瞬間は多くありますし、勉強した内容から、ある分野で年長者よりも知識を持っているという場合も増えてきました。 自分がこれから進む道においては、危機管理を意識したシステムの下で過ごすことができる確率は恐らく低いのだろうとも思っています。

 個人としても、やはり知らない事があり、それが全く無関係の第三者を害することがあるということも自覚しつつあります。

 

 そしてこの本は、そんな未熟な個人である自分が、いざという時に「優秀な副操縦士」であることを求められうるということを考える良い機会になりました。 色々と見逃しがちでしたが、もっと意識してやっていきたいと感じます。

 

「最悪の事故が起こるまで人は何をしていたのか」は、ここに書いたこと以外にも、多くのタメになる知識が載っている、お勧めの一冊です。

最後に

 個人的には、航空機事故について扱った、「メーデー!」シリーズがとても参考になると思います。

様々な刺激があるので、ニコニコ動画で見るともっと参考になるかなと思います(ボソッ

第1話「タン航空3054便」
 

Androidで、C++とJavaの実行速度を少しだけ比較

AndroidC++コードの実行速度とJavaコードの実行速度を少しだけ比較してみました。
この検証に使ったコードは以下に公開しています。
github.com

環境

開発環境 Android Studio2.3
NDKバージョン 14.1.38168.74
実行デバイス(Androidバージョン) SH-02H(6.0.1)

実行したコード

実行したコードは、for文中にif文を挟むコードです。
計測されている時間はミリ秒です。

エミュレータではJavaの方がC++よりも実行速度が速くなったりと実行速度がおかしかったので実機で計測しました。

C++の導入やそのコードの使用方法については省略します。

C++
extern "C"
JNIEXPORT jint JNICALL Java_com_wrongrong_cpptest_MainActivity_cppForTest(JNIEnv* env, jobject obj){
    int i,j;
    j = 0;

    for(i = 0;i < 200000000;i++){
        if(i&1 == 1)j++;
    }
    return j;
}
Java
public class JavaForTest {
    public int javaForTest(){
        int i,j;
        j = 0;

        for(i = 0; i < 200000000; i++){
            if((i&1) == 1)j++;
        }
        return j;
    }
}
検証用コード
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    TextView tv = (TextView) findViewById(R.id.sample_text);
    String ln = System.lineSeparator();
    JavaForTest jft = new JavaForTest();
    int i,j=0;
    long jftS,jftE,cppS,cppE;

    for(i = 0;i < 200000000;i++)j += i;

    jftS = System.currentTimeMillis();
    i = jft.javaForTest();
    jftE = System.currentTimeMillis();

    cppS = System.currentTimeMillis();
    j = cppForTest();
    cppE = System.currentTimeMillis();

    //出力の整形
    StringBuilder sb = new StringBuilder(String.valueOf(i - j)); sb.append(ln);
    sb.append("Java:"); sb.append(String.valueOf(jftE - jftS)); sb.append(ln);
    sb.append("C++:"); sb.append(String.valueOf(cppE - cppS)); sb.append(ln);
    sb.append("Java/C++:"); sb.append(String.valueOf((double)(jftE - jftS) / (double)(cppE - cppS)));

    tv.setText(sb.toString());
}
脚注

実行速度安定化のための空ループを挟んでみたが、挟まない方がC++Java両方に関して、実行速度は高速でした。
一方、ループを挟まない場合、先に実行した方のコードの実行速度が速くなる傾向がありました。
レジスタの関係でしょうか?

実行結果

JavaC++に対して大体13倍ほど実行速度が遅いという結果になりました。
プログラム実行速度の計測に関して余り知識が無いので何とも言えませんが、やはりリアルタイム処理のような高速性の求められる処理では、C++を用いて処理を行った方が良いのでしょう。

Androidアプリで、タイトルバーを消す方法

色々なサイトを見たが動かない場合によくぶち当たったので、自分の環境で動いた例のサイトを備忘用に保存。

やったこと

values/styles.xml内で、parent="Theme.AppCompat.Light.DarkActionBar"となっている部分をparent="Theme.AppCompat.Light.NoActionBar"と書き換える。

参考サイト

丸々以下の内容。
ja.stackoverflow.com

「生存率計算機」――懲りずにまたアプリを作ってみた

以前作成したScript Calculatorに続き、またアプリを作成してみました。

play.google.com

作成したアプリのタイトルは生存率計算機、厚生労働省のデータを基に生存率を計算します。

play.google.com

github.com

作ったきっかけ

カメラアプリを作ろうと四苦八苦していたのですが、残念ながらリアルで時間が取れない状況が続きそうで、完成まで持っていくには少し厳しい状況と感じていました。

一方この土日は空いていて、開発したいという意欲はあったので、サクッと作ることができそうな題材でアプリを作ってみました。要するに暇つぶしです。

感想

題材が題材だったので、色々なことは感じましたが、取りあえずこのアプリを作ってみた感想としては、暇つぶしでアプリをリリースする日が来るなんて想像していなかった、です。

まあ対して難しいことはしておらず、レベルはお察しな感じですが、ソースコードそのものはきっかり24時間以内で書き上げられたので、そこは成長かなあと思うことにします(笑)。

Android6.0(APIレベル23以上)で、アプリに権限を与える

アプリに権限を与えようとした時に詰まったので、備忘用に。

やること

APIレベル23から、Androidでアプリを動かす際に必要なパーミッションが、アプリインストール時ではなく、その機能を使う時に取得するようになったため、AndroidManifestへの記述だけでなく、そのためのコードが必要になった(今更)。
この権限を与える処理が非常にめんどくさかったので備忘を兼ねて投稿。
ただ、まだ理解が追いついておらず、このやり方で効率が良いのかは確認できていない。
余分なものが入っていないコードはまとめに記載。

やったこと

前提として、AndroidManifestにパーミッション関連を記述しておく。

onCreate

今回はアプリ起動時に権限を付与することを想定して、onCreateメソッドから。

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //カメラ権限の確認
    if (ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.CAMERA)!= PackageManager.PERMISSION_GRANTED) {//権限がまだ無い場合
        if (ActivityCompat.shouldShowRequestPermissionRationale(MainActivity.this, Manifest.permission.CAMERA)) {//明示的に権限が拒否されていた時
            //拒否されていた時の処理、なんかしらのメッセージを出すと良いと思われる、今は何も考えずにパーミッションを聞いておく
            ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.CAMERA}, 1);
        } else {//まだ聞いてなかったとき
            //与えても良いか聞く、onRequestPermissionsResultが答えを受ける
            ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.CAMERA}, 1);
        }
    }else {//権限がある場合
        initCameraView();//そのままカメラをセッティング
    }
}

※initCameraViewメソッドは自作したもので、この記事の内容には関係無し

ここではカメラ権限のチェックと、権限が無かった場合の付与を呼び出している。
大半はコード中のコメントに書いた通りで、権限のチェックには

  • 現在権限が与えられているか
    • 権限が無かった場合どうするか
      • 権限が無いのは、ユーザーに拒絶されているからか
        • 拒絶されているならどうするか
        • まだ聞いていないならどうするか
    • 権限が有った場合どうするか

といったような手順が必要。

権限を与えるために呼び出すメソッドは以下。

ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.CAMERA}, 1);

Manifest.permission.CAMERAとなっている部分は取得する権限を意味する。
末尾で与えている定数の1は、後述するonRequestPermissionsResultメソッドで利用する。

onRequestPermissionsResult

このメソッドは、権限付与のために呼び出したrequestPermissionsメソッドに対する返答を受け取るメソッド。
これを書かないと権限の有無を確認しないまま処理が開始されてしまい、権限が無いまま機能を利用しようとしてアプリがSecurityExceptionで落ちたりする。

@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
    switch (requestCode) {
        case 1: { //ActivityCompat#requestPermissions()の第2引数で指定した値
            if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {//許可された場合
                setContentView(R.layout.activity_main);
                initCameraView();
            }else{//拒否された場合の処理
                //とりあえず終了しておく
                MainActivity.this.finish();
            }
            break;
        }
    }
}

ここでrequestCodeをswitchに渡しているが、この数字が先ほどのrequestPermissionsメソッドに与えた定数。
先ほどは1を渡したので、1に関してはカメラの権限付与がどうなったか確認を行っている。
幾つかの権限を与える最には、enumなりを使ってrequestCordを管理した方が良いかも?
とりあえずここまで実装しておけばアプリに権限を与えることができた。

蛇足

onRequestPermissionsResultにて、initCameraの前にsetContentViewを行っているが、これをしないとカメラを起動する前にアプリが落ちた。
原因を理解する前に多分ビューの切り替えがおかしいんだろと予想して切り替えを記述してみたが、ドンピシャだったので何故落ちるか理解できていない。

まとめ

今回載せたコードから、余計なものを取り除いてまとめたものが以下。

@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
    switch (requestCode) {
        case 1: { //requestPermissions()の第2引数で指定した値
            if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {//許可された場合
            }else{//拒否された場合の処理
            }
            break;
        }
    }
}

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //カメラ権限の確認
    if (ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.CAMERA)!= PackageManager.PERMISSION_GRANTED) {//権限がまだ無い場合
        if (ActivityCompat.shouldShowRequestPermissionRationale(MainActivity.this, Manifest.permission.CAMERA)) {//明示的に権限が拒否されていた時
            //拒否されていた時の処理
        } else {//まだ聞いてなかったとき
            //与えても良いか聞く、onRequestPermissionsResultが答えを受ける
            ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.CAMERA}, 1);
        }
    }else {//権限がある場合
    }
}