最近読んだ書籍の紹介(UNIXという考え方)

本の紹介

タイトル

  • UNIXという考え方 その設計思想と哲学

読んだきっかけ

  • 確か自分が好きなエンジニアがTwitterか何かで紹介していたから。 ずっと読みたいなーって思っていたけど。実務や資格の学習とかで中々読む時間が無く、ようやく読了。
  • 20年前から現代(令和)まで通ずるエンジニアとしての本質が書かれているとのことで、興味を持った。

要約

  • 概要は以下の9項目。内容はこの9項目について、アメリカ人らしいジョークや実例(20年前の話とあってかなり古い)を 交えながら、解説してある。

  • Small is beautiful.

  • 1つのプログラムには1つのことを上手くやらせる。

  • できるだけ早く試作する。

  • 効率より移植性を重視する。

  • 数値データはASCIIフラットファイルに保存する

  • ソフトウェアを梃子(てこ)として使う

  • シェルスクリプトによって梃子の効果と移植性を高める。

  • 過度の対話的インターフェースを割ける

  • すべてのプログラムをフィルタとして設計する。

この9項目について、自分の所感。

  1. Small is beautiful.

  2. 1つのプログラムには1つのことを上手くやらせる。 -> 上記2点は今の時代では当然かなと思う。ただ、当時の時代はそこまで当たり前ではなくて、 これができていないソフトウェアは、急速なハードウェアのようなプラットフォームに追従できなくて、 敗北していったらしい。今の進歩とはまた違っていて、CPUやメモリ等の本当にハードの部分の進歩。 この辺りの時代背景がかなり具体的に書いてあって、歴史の教科書としてはおもしろかった。

  3. できるだけ早く試作する。 -> これも当たり前なんだけど自分が本当にできているのか、と自問自答したところ、できていない部分もあるな、と思い反省した。 今の時代は顧客側もネットからの情報やIT子会社抱えてたりでそれなりに知識がある状態で、"調べます。"とか"検証します。"みたいな スピード感では、とても追いつけないんだろうなと思った。

  4. 効率より移植性を重視する。

  5. 数値データはASCIIフラットファイルに保存する。 -> ここに対する意見は1, 2と同様。

  6. ソフトウェアを梃子(てこ)として使う

  7. シェルスクリプトによって梃子の効果と移植性を高める。 -> シェルスクリプトには短い文字数で、膨大な処理が書けるんだから、上手く使おうねっていう話。 今のPythonに通ずるような話でおもしろかった。

  8. 過度の対話的インターフェースを割ける

  9. すべてのプログラムをフィルタとして設計する。 -> ここも当然なんだけど、具体例がおもしろかった。特にUNIXは"沈黙を金"と言っている箇所。 WindowsとUNICのファイル一覧出力処理について。

    • Windowsの場合 $> DIR DIRECTORY : NO FILES FOUND $>

    • UNIXの場合 sh> ls sh>

    こんな感じで、UNIXはファイルが何も無かったら、何もメッセージを出力してくれないから、 不親切ですか？そうでもないよね？っていう一例。

    UNIXなら、以下みたいな使い方ができる。

    ls -l | awk '{ print $4}' | sort awkコマンドをパイプで繋げて、lsの出力結果のうち4番目の値のみを出力できる。 これがWindowsのように"DIRECTORY : NO FILES FOUND"っていう結果を出力してしまったら、 "FOUND"を出力してしまうよね。邪魔だよね。UNIX、無駄が無くていいよね。 みたいな話。

所感

  • 本が書かれたのは平成13年(2001年)2月23日。約20年前。最近のバズワードでもある"マイクロサービスアーキテクチャ" みたいな考え方が確かに記載されてあったけど、正直そこまで新鮮な考えは無かった。自分から進んで人に薦める程の書籍では無いかな、という印象。ただ、20年前からこの考えを提唱していることは シンプルにすごいと思った。

  • 本の内容とは関係ないが、休憩の取り方は大事だと思った。休憩時間にスマホとかの電子機器を触るのはNG。 スマホ触ると5分くらいの感覚で15分経ってる。外の景色見ながらぼーっとすると、15分くらい休んだ感覚で3分くらいしか経ってない。 スマホってやっぱり使い方を気を付けないと、無駄な情報を沢山取り込むことになる。

  • ブログでも口頭でもいいが、やっぱり学んだことはアウトプットしないと、自分の理解度は計れない。 こうやって文章にすると、自分が如何に技術的に未術で、普段から感覚的に話をしているかを痛感する。 もっと開発をするなり、勉強をしたことをアウトプットしながら、文字通り体に染み込ませて、自分の知識レベルの基準を高めたい。

RDBMSの制約、データ所要量、性能見積に関する話

・以下2つの条件が制約がある時、
　- 申請種別は、'1'(立替経費精算), '2'(経費支払依頼)のいずれか
- 支払先は、申請登録時の指定は、経費支払依頼では必須(NOT NULL), 立替経費精算では任意

　検査制約は以下のようになる。

　CHECK(申請種別='1' OR 申請種別='2' AND 支払先 IS NOT NULL)

この時、意味としては以下のようになるはず。
　CHECK(申請種別='1' OR (申請種別='2' AND 支払先 IS NOT NULL))

しかし、括弧は全体を閉じる括弧しか付与しない。一般的な数学の考え方と少し異なるので、注意が必要。


・テーブルのデータ所要量を計算する時、最初に次の3つを確認する。
　1. 見積行数(格納する最大のデータ件数)
2. ページサイズ
3. 平均行長

　RDBMSが、ストレージとデータの入出力を行う単位を、データページという。
　データページの単位のことを、ページサイズと呼ぶ。
　
　平均行長(バイト)とは、平均の行の長さ、つまりテーブルの中の1行(1データ)の容量(バイト)を示す。
　計算で求めるとすれば、テーブル定義表の格納長(バイト)の合計値となる。
　

・1データページ当たりの平均行数(行)
　1データページ当たりの平均行数は、計算で求めることが多い。
　ページサイズ(1データページの大きさ、4,000バイト等)を、平均行長(1行の大きさ)で割って、求める。

　1データページ当たりの平均行数は、以下の計算式で求める。

　= ページサイズ(バイト) * (1 - 空き領域率) / 平均行長(バイト)
※小数第1位を切り捨てる。特に問題文に記載は無いが、基本的に整数で記述することにする。


・必要データページ数(ページ)
　見積行数が1,500,000行、1データページ当たりの平均行数が15行
　1,500,000(行) / 15(行/データページ) = 100,000ページ


・データ所要量
　ページサイズ(バイト) * 必要データページ数(ページ)
　= 4,000 * 100,000
= 400(MB)


・性能見積の問題では、何の業務、処理に対する性能見積であるかを問題文から必ず判断する必要がある。
　今回の場合は、一般経費申請における、性能見積。
　つまり、1秒間に200トランザクションを処理する必要がある。


・1トランザクション当たりのI/O時間を求める問題がある。
　1データページ当たりのストレージへのI/O時間は20ミリsである。
　
　バッファヒット率とは、ディスクアクセスを行うことなく、バッファキャッシュ内で要求されたブロックが
　検出された頻度のこと。

　つまり、バッファヒット率が0%の時は、キャッシュからはデータの取得ができず、
　全てディスクアクセスで必要なデータを取得する。

　バッファヒット率が0%の時、毎回I/Oが発生する形で、1トランザクション当たり、平均50データページにアクセスする。

　50(データページ/トランザクション) * 20(ミリs/データページ)
　= 1000(ミリs/トランザクション)
　= 1(s/トランザクション)

　
・1トランザクション当たりのCPU処理時間は、10ミリs
1トランザクション = 50データページ
　50データページ * 0.6(ヒット率60%) = 30データページ
　この30データページは、キャッシュからデータを取得するので、
　I/Oは発生しない。I/O時間は発生しない。
　
　残りの20データページはI/Oが発生するので、処理時間を計算する。

　問題文にある通り、1データページにかかるI/O処理時間は20ミリsなので、
　20(ミリs/データページ) * 20(データページ) = 400ミリs(I/Oに必要な時間)

　CPUの1データページ当たりの処理時間は、0.2ミリsである。
　0.2(ミリs/データページ) * 50(データページ) = 10ミリs(CPU処理に必要な時間)
　※CPU処理は、I/Oは関係無いため、元々の50データページの処理が必要な点に注意。

　400 + 10 = 410ミリs
= 0.41s


・バッチ処理の処理件数の問題
　
　1. まず、処理の前提条件を確認する。

　- 共通マスタのテーブル参照は、試算の対象にしない。
　→当該テーブルの件数のみを対象にすれば良い

　- "旅費申請"、"交通費申請"、"一般経費申請"、"経費伝票"の各年月には、
　 それぞれ処理年月をキーとする索引があるものとする。
　→これらのテーブルは、処理年月により、範囲が選択できる。
　
　- 申請数は、各事業部、各科目、各処理年月に均一に分布する。
　→処理年月で均等

　2. 詳細な処理内容を確認する。
　まず、各処理と、処理によって操作されるテーブルを整理する。

　- 経費伝票作成
"旅費申請"、"交通費申請"、"一般経費申請"、"旅費申請明細"、
　　"交通費申請明細"、"経費伝票"

　- 会計データ作成
　　"経費伝票"

　- 経費分析表作成
　　"経費予算"、"経費伝票"

3. テーブルの行数
　問題文及び表に記載有。

　4. テーブル行数の絞り込みに必要な情報を確認する

　前提条件には、以下の記載がある。
　"探索対象行数"は、参照する全てのテーブルについて、各テーブルの選択条件に一致する行数の合計とする。

　この説明から、探索条件にキーが設定されていて、対象となる行数が絞り込まれているのではないかと考える。

　会計データ作成処理では、"経費伝票"テーブルを操作する。
　"経費伝票"テーブルの見積行数は6,600,000、探索対象行数は110,000となっている。
　6,600,000 / 60 = 110,000
上記の計算(/60)が何らかの理由で実行されているが、その理由は現時点では不明。解説にも記載は無い。

　探索対象行数は、参照するテーブルの選択条件に一致する行数の合計、との記載がある。
　
　バッチPGMの"会計データ作成"処理の内容は、"経費伝票"テーブルの処理年月が、当月に一致する1か月分の
　行ごとに、会計データ1行を編集して、ファイルに出力する、とある。
　
　上記文章は日本語的におかしいが、以下の意味と考えられる。

　"経費伝票"テーブルの内のデータを'処理年月'を1か月毎に集計して、ファイルに出力する。
　(12か月分のデータがあれば、12行に集約して、出力)

　問題文の[システム概要]、1. 現行システム、③には、以下の記述がある。
　60か月前から、現在までのデータが全て保存されている。

　つまり、バッチPGMの処理により、会計データは、60行に集約されて、出力される。


・経費伝票作成処理の処理行数を確認する。

　「処理年月が当月に一致する行を対象に」という記述から、これらのテーブルの"①保存期間"を確認する。

　↑なぜ、'処理年月'ではなく、'保存期間'?
そして'保存期間'という列が存在することをどこから判断できる?


・経費伝票作成処理のサーバ間通信対象行数を求める。

　サーバ間通信対象行数は、「処理ごとに、行の参照、追加のために、DBサーバとAPサーバ間で転送される行数とする。」

　- DBサーバ上でバッチPGMを実行することができないので、バッチPGMはAPサーバ上で実行する。

　- 会計データ作成処理は、110,000件になっている。

　- 「専用サーバでは、利用者はサーバにログインできない。このため、バッチPGMの実行、ファイルシステムへのアクセスを行えないが、
　　Webベースの管理画面を通じて、次の管理機能を利用できる。」

　上記3点の情報から、ファイルシステムはAPサーバ側にある、と判断する必要がある。
　(正直これは問題文からは判断できない。一般的な業務アプリケーションの仕様から、想定する必要がある。)

　結局のところ、「表4 バッチPGMの処理内容」から、以下を判断する必要がある。
　
　- それぞれの処理が、APサーバ、DBサーバ、どちらで処理されるのか。

　- それぞれの処理が、どのテーブルをどのくらいの量(行数)処理するのか。

　一番簡単な会計データ作成処理の場合は以下の通りである。

　"経費伝票"テーブルから、データをSELECT及び集計して、ファイルに出力する。
　- "経費伝票"テーブルは当然DBサーバにある。
　- 見積行数は60か月分で、660万行なので、1か月分は、11万行。
　　DBサーバから、APサーバに11万行を転送する。
　　これは既に問題文に書かれている値と一致する。

　次に、経費伝票作成処理について考える。
　ちなみに、[クラウドサービスの選定・評価]の1. サービスの選定、の(4)に以下の記述があった。
　(4)DBサーバ上でバッチPGMを実行することができないので、バッチPGMはAPサーバ上で実行する。

　つまり、現行システムではDBサーバ上でバッチPGMを実行するが、クラウドサービスではそれができないので、
　APサーバ上で実行すると言っている。
　具体的なサービス名は明記されていないが、おそらくAWS RDS等を想定したシステム構成になっていると考えられる。
　

・サーバ間通信対象行数を求める。
　
　会計データ作成処理の、結果行数と、サーバ間通信対象行数は同じ値になっている。
　110,000。

　これは、バッチPGMの処理内容に記載がある通り、"経費伝票"テーブルからデータを取得して、
　月毎に集約し、会計データ1行を編集してファイルに出力する、という処理から、
　データ抽出(DBサーバ)→ファイル出力(APサーバ)といった流れで、サーバ間通信を
　行っていると考えられる。

　よって経費伝票作成処理も、同様の手順で考えることができる。

　バッチPGMの処理内容から、対象行をバッチPGM中に読み込む、読み込んだ行毎に
　"経費伝票"テーブルの各列に値を設定して1行を追加する、という内容から、
　110,000 * 2 = 220,000だと考えられる。

　
・サーバ間通信対象行数を削減するために、ストアドプロシージャを使う。
　実行可能なSQL文の処理手続きを予め、データベースに格納し、クライアントからの
　命令で実行できるようにしたものをストアドプロシージャと呼ぶ。
　
　利点は主に、以下の2点がある。

　ネットワーク負荷の低減：通信回数・通信量が少なくなる。(実行命令と結果のみ)
　セキュリティの向上：クライアントから直接データにアクセスできなくなる。


・クラスタリング
　検索対象の表に用いられる演算を分析し、演算結果として得られるレコード群を近くの
　領域に配置することで、検索速度を高速化する。


・キーレンジ分割方式
　大量のデータをテーブルに格納する場合、あらかじめテーブルを構成する特定の属性を
　キーとして設定し、そのキー値の範囲によってデータを格納するディスクを決め、分割して
　格納することをキーレンジ分割方式と呼ぶ。データ格納先を分割することで、データの検索処理を
　並列化し、高速化が期待できる。

RDBMSのエンティティの紐解き方、制約、テーブル定義、索引について

・テーブル構造や、ER図だけでなく、問題文からも、
　テーブル間の相関関係を把握することができる。

ex)
- 問題文
一つの仮払に対する精算が複数の日に分かれることもある。

- 分かること
"仮払金申請"テーブルと、"仮払金精算"テーブルを1対多の関係にする必要がある。
また、"仮払金申請"テーブルの存在しない、"仮払金精算"テーブルは存在しない

ここから、以下がわかる。

"仮払金精算"テーブルは、"仮払金申請"テーブルの弱エンティティである。
弱エンティティのことは、別名 弱実体 とも呼ぶ。

弱エンティティは、受注テーブルと受注明細テーブルのうちの受注明細テーブル、
売上ヘッダテーブルと売上明細テーブルのうちの売上明細テーブル、等が該当する。

これより、

"仮払金精算"テーブルの主キーは、"仮払金申請"テーブルの主キーに、
もう一つ何かしらの属性を追加して、1対多の関係になると判断できる。

"仮払金精算"テーブルは、"仮払金申請"テーブルの詳細情報を含むため、
"仮払金申請"テーブルの主キーを持たせ、相関関係を示す必要がある。

そのため、まず"仮払精算"テーブルには"仮払申請"テーブルの主キーである、
申請番号は必須。

そして以下の記述より、

"精算時には、精算日ごとに精算金額を記録する。"

精算日、精算金額が必要。

つまり、以下のテーブル構造になる。

"仮払金精算"テーブル
申請番号(主キー)、精算日(主キー)、精算金額

一つの申請番号に、複数の精算日があることから、
申請番号と、精算日の複合主キーになる。

仮払精算テーブル中の申請番号は、
仮払申請テーブルの外部キーでもある。


・RDBMSのテーブルの列には、NOT NULL制約を指定することができる。
　NOT NULL制約を指定しない列には、NULLか否かを表す1バイトのフラグが付加される。


・RDBMSのテーブル定義の格納長(バイト)は、平均文字数をベースに算出する。

　ex)
　NCHAR VARYING(n)型(最大n文字の全角可変長文字列(1<= n <= 4,000))で、
　全角文字100文字以内、平均文字数が20文字の時、

　バイト数は、20文字 * 2バイトで、40バイト。
　これに制御文字4バイトが加わって、44バイト。
　NOT NULL制約が無い時は、NULLか否かを示す1バイトのフラグが加わる。
　-> 45バイトとなる。
　
　ただし、データ型には、最大文字数を指定する。
　全角文字100文字以内、というルールがある時、データ型は、NCHAR VARYING(100)となる。


・索引の種類には、P(主キーの索引)、U(ユニーク索引)、NU(非ユニーク索引)の3つがある。

Markdownでローカルの画像を埋め込む方法

こんにちは、タケルです。
最近はクラウドアーキテクトしてます。


タイトルの件。
以前にどこかで見たことある気がするが、
中々見つからないので、備忘兼共有。

<img src="fig/fig.png" alt="drowing" width="100">

srcで、ファイルのパスを指定。
widthで、画像のサイズを指定。


以上です。

社会人3年目のITエンジニアが2019年を振り返る。

 
こんにちは。タケルです。
 

私は都内某企業でITエンジニアをやっています。
 
普段の本ブログでは、私が勉強したITの知識（アプリ、インフラ、NW全般）の知識を
広く知ってもらいたい、かつ自分のアウトプットのために書いています。
（たまに雑談もします。）

久しぶりの記事なので簡単に自己紹介。
 

・都内某IT企業で働いています。
・SIerです。
・本職はアプリケーション開発です。Javaが書けますが、レガシーなシステムを担当させて頂いていたので、
　最近流行りのフロントエンドの言語やフレームワークには疎いです。
・プログラミングが好きです。休日はプログラミングか読書かランニングしてます。
 
早速振り返りますね。まずは2019年の初めに立てた目標から。

まずは大目標
１．ブログ作成をする。月100PVを獲得する。
→達成☆
２．HTML、CSS等のWEB作成技術を習得して、月1万自力のみで稼げる能力を身に着ける。
→未達成
３．毎日の生産性を高める。(基本急ぐ。)
→達成☆
４．毎日の満足度を最大限高める。
→未達成
達成率は、50%（2/4）
 
以下が詳細（途中でリスケしたりもあったので、かなり差異があるかも。）
・ブログを週に1回は必ず更新する。
→未達成
・ブログで月間1000PVを獲得する。
→未達成
・毎日筋トレする。
→達成☆
・Andoroidアプリ開発ができるようになる。
→未達成
・毎月2冊は本を読む。
→未達成
・毎日テキストファイルで目標、予定を立て、その通りに行動できるようになる。
→達成☆
・TOEICで600点取る。
→未達成
達成率は、29%（2/7）
 
達成、未達成の原因をそれぞれ考察してみます。

大目標から。
１．ブログ作成をする。月100PVを獲得する。
→達成☆
年に13記事書きましたが、達成できていました。
月100PVって誰でも到達できるんですね。
もう少し振り返りとアウトプットの時間を増やせば300PVくらいは
簡単に到達するのでしょうか。
達成できているので、問題無。

２．HTML、CSS等のWEB作成技術を習得して、月1万自力のみで稼げる能力を身に着ける。
→未達成
これは、、、正直達成できたかどうかもわからない。
本気でやれば稼げるだろうけど、こういうフロントエンドの言語って
自分の職業的にほとんど使わない。
（使うとしてもJSPで実装してる。）
おそらく副業の柱として欲しかったんだろうけど、こういう正直
誰でも少し勉強すればできるようなことを目標に立てても時間も気力も割けない。
反省。

３．毎日の生産性を高める。(基本急ぐ。)
→達成☆
これは毎日1h単位でスケジュール決めて動いていたんで、
達成できたと判断します。
後は気持ちと体力が切れないように、継続するのみ。

４．毎日の満足度を最大限高める。
→未達成
これは曖昧だな、、、こんな曖昧な目標立てる価値もないため、
未達成と判断。
 
次は詳細。

・ブログを週に1回は必ず更新する。
→未達成
正直私がブログ書くときって毎回2hくらいかかっちゃうんですよね。
今後は1記事の内容を濃くしたいので、月1投稿に変えようかなと思います。

・ブログで月間1000PVを獲得する。
→未達成
継続していない時点で不可能。それよりも今は技術力付けたい。

・毎日筋トレする。
→達成☆
これは今後も継続していきたい。人間運動しないと寿命縮むらしいです。
時間が無いからと言って運動しないのは、自分の人生のトータル時間を削っていることと同じらしい。
自分の限界に挑戦するためにも、これは継続必須。

・Andoroidアプリ開発ができるようになる。
→未達成
これは悔しい。やはりどんなに忙しい日でも、毎日30分でもいいので、
好きなこと（自己研鑽）をやる時間は必要ですね。
習慣化します。

・毎月2冊は本を読む。
→未達成
これは無理。けど月1冊は何かしらの技術書を読んで習得したいな、と思います。
2020年から必達目標に掲げます。

・毎日テキストファイルで目標、予定を立て、その通りに行動できるようになる。
→達成☆
これは良くやれた。

・TOEICで600点取る。
→未達成
技術習得をやるにあたって、やっぱり英語が読めないとしんどいんですよね。
ネットで検索すると英語の記事は桁違いですもんね。
やっぱり一度腰を据えてやるべきかなぁ、、と思ったりもします。

◆2019年の行動総括
＜良かった点＞
・時間を大事にして着実に学習を進めることはできた。
＜改善すべき点＞
・目標設定が曖昧すぎる。
・軸がない。
・習慣化がまだ完全にはできていない。

というわけで反省点の方が多いですね。
 
以上を踏まえて2020年の目標は下記の通りです。
 
 
１．ブログ作成をする。毎月1度は投稿して、自分の技術習得の進捗を確認する。
２．本職に必要な技術力を習得し、その分野に関しては、所属組織一の技術とする。
３．本職とは別に知識を習得する。
（今は昨年達成できなかったAndroidアプリ開発と、機械学習に決めています。）
４．毎月1冊は本を読む。
 
 
目標を大目標と詳細に分けちゃうと、少し管理が面倒なので、
これからは一緒にします。

目標達成の現実性を考えると、これが妥当かな、って思ってます。

技術要素を以下にまとめます。
・Androidアプリ開発を自力で作成、デプロイすることができる。
（自分のスマホにインストールして、お披露目したい。）
・機械学習
（まずは参考書1冊。そこからアプリケーション開発に組み込みできたらな。）
・基盤
（コンテナ、コンテナオーケストレーション）
 
言語で言うとJava、Pythonですね。
最近Python勉強してるんですが、これが全く慣れない、、、
ライブラリが豊富すぎて、いまいち自分で実装している気になれないんですよね。
やっぱりJavaが好きです。慣れてくるとまたこの感覚も変わってくると思うので、
もう少し継続してみます。

後は毎日の振り返りを徹底して、成長したいですね。
 
それにしても1年あっという間ですね。
しっかり振り返って、これからも勉強して、成長したいと思います。
 

東京オリンピックも行きたいな、、、
 
 
 

「サイコパス」の定義についての誤解を解きたい（ドラマ「あなたの番です」を見て）


こんにちは。タケルです。
 
私は都内某企業でITエンジニアをやっています。
相変わらず仕事してます。
 
 
普段の本ブログでは、私が勉強したITの知識（アプリ、インフラ、NW全般）の知識を
広く知ってもらいたい、という思いで書いています。
 
 
しかし、今回の話はITとは全く関係無いので、興味のない方は
ブラウザバックしてください。
 
 
今日のブログの本題に入ります。
 
 
 
少し前の話になってしまいますが、ドラマ「あなたの番です」が
すごくバズりましたよね。
 
 
 
脚本、役者さんの演技共に個人的には大満足のドラマでした。
まだ見ていない方は、今ならHuluに加入すれば見れるんじゃないでしょうか。
※宣伝するつもりは全くありません。
＜Huluリンク＞
https://www.hulu.jp/

そんなこんなで、今回のドラマでは黒幕が猟奇殺人鬼であり、SNSを見ていても、
恐ろしい、サイコパスだ、といった色んな意見が広がっていました。
 
 
 
 
 
 
 
ふと気になったのですが、ドラマの話だけでなく、日常的にも、
ちょっとやばい人がいれば、サイコパスだ、という人がいますよね。
 
 
 
 

ここで私は、「サイコパス」という言葉の定義を改めて考えてみました。
 
 

ここまでの話を聞けば、「サイコパス」の定義って
「やばいやつ」、「殺人鬼」、「狂っている」といった意味に見えますが、、、
 
 
 

ちょっと待ってください。
サイコパスってほんとにこういったマイナスのイメージの意味だけなんでしょうか。
 

実は違います。
 

少しWikipediaで調べてみました。

以下、Wikipediaより引用。

--------------------------------------------------------------
犯罪心理学者のロバート・D・ヘアは以下のように定義している。
・良心が異常に欠如している
・他者に冷淡で共感しない
・慢性的に平然と嘘をつく
・行動に対する責任が全く取れない
・罪悪感が皆無
・自尊心が過大で自己中心的
・口が達者で表面は魅力的
＜Wikipediaリンク＞
https://ja.wikipedia.org/wiki/精神病質
--------------------------------------------------------------

ここまで見ても、悪い意味に見えますね、、、

実はサイコパスの定義って以下だと思ってます。
 

目的のために、手段を選ばない人
 

これは、自分の快楽のために他人を傷つける、とかそういう意味ではありません。
実はこれってビジネスにおいて非常に重要な考え方だと思ってます。
 
 
ビジネスをやるって、時には本当に辛い選択を瞬時に求められます。
だらだらと悩んでいる暇なんてありません。
 
 
以下、一例です。
・あるプロジェクトにおいて、生産性の低い人を下から切る。（クビにする。）
・顧客からの仕様変更要望に対して、自社の瑕疵責任なのかそうでないのか、実現可能か不可能か
　対応することのメリットデメリット（自社と顧客双方について）を瞬時に判断して回答する。
・停滞しているビジネスを全て捨て去り、新しいビジネスに方向転換する。
　（もちろん既存の役割や人も刷新する可能性もある。）
 
人って皆、自分から物事を決めることは好みません。それが自分以外の人間に莫大な影響を与えるのなら、なおのことです。
しかし、人の上に立つ人や、ゼロから「1」を生み出す人、プロジェクトを前に進める人は、常にこういった「選択」、そして「決断」を迫られます。
そういった意思決定を容赦無くできる人のことを、私は「サイコパス」って呼んでいます。
 

ものすごく個人的な意見ですが、世の中の半分以上の人は、
自分で物事を決めない「作業者」だと思ってます。
 
もちろん「決める」ことがめんどくさければ、黙って人のいうことを聞いていれば、
それなりに稼ぐことも、地位を築くこともできます。

しかし、世の中がインターネットで繋がって、今まさに本当に必要な仕事、
役割が求められている時代です。

年齢、国籍、立場に関わらず、今この世で生きている全ての人が、
今自分がやっていること、考えていること、今生きている場所が本当に正しいのかどうか、考えて欲しいなって思います。

考えて生きれば、遊びも仕事もどんどん楽しくなります。
考えること、勉強することって、こんな楽しいんだ、ってことを沢山の人に知って欲しいです。
 
今日のまとめ

・「サイコパス」とは、目的のために、手段を選ばない人
・人は皆、常に考える必要がある、考えた上で、「決断」する必要がある。
・考えること、勉強することで、人生が何倍も楽しくなる。
 
ってことで今日も勉強したいと思います。

それではまた。
 

違法にアップロードされたコンテンツを見ると、個人を特定されるのか。


こんにちは、タケルです。

またしても久々の更新となってしまいました。


長いGWを終えて、色々と収穫があったので、今後少しずつアウトプットしていこうと思います。

 

まず改めて自己紹介から。

私は都内の某企業で、SIerをやっております。
日常業務は主に、アプリケーション開発になります。

 

休み中、私の専門外ではありますが、全く無知でいるのももったいないと思い、
ITインフラの勉強をしました。

そこで改めて、IPアドレスとは、MACアドレスとは、サブネットマスクとは、等基本的なことを復習しました。

(ITに余り興味のない方でも、この辺りは聞いたことがあるのではないでしょうか。)

 

「IPアドレス」、、、これで私はあることを思い出しました。

 

 

 

私が学生の時に、ある迷信が広まっていました。

 

YouTubeや、その他動画サイトに違法アップロードされているコンテンツを見ていると、
逆探知されて捕まるらしい、実際に知り合いが警察に来て注意された、、、といった噂が流れていました。

(先に言っておきますが、私は違法アップロードも、違法アップロードされたコンテンツを閲覧するのも大いに反対派の人間です。)

 

 

 

 

 

タイトルにも挙げておりますが、、、結論から申し上げますと
不可能です。(基本的には、です。)

 

一般的に使われているスマートフォンや、タブレット、PCから、どうやってYoutubeや、違法サイトにアクセスし、コンテンツを閲覧しているのか、簡単に流れを以下に記載します。

 

■外部コンテンツアクセスの流れ(超概要)
個人のデバイス(MACアドレス、IPアドレスを保持)
→各キャリアを経由(グローバルIPアドレスを保持)
→コンテンツのあるサーバーにアクセス

MACアドレス：各デバイス毎に固有の値
IPアドレス：各ネットワーク毎のデバイス毎に固有の値

 

上記のような流れでリクエストを行い、後は逆の流れでレスポンスを受け取って完了です。

 

逆探知が不可能な理由として、私が思った理由は以下の通りです。

・やりとりを行う情報と、個人情報に一切結びつきがない。

 

 

確かに端末毎に固有の情報(MACアドレス、IPアドレス)を持ってはいますが、それが各個人情報(住所や氏名、電話番号等)に一切紐づいていないためです。

 

現在は企業等の大きな規模になると、数百、数千台単位でレンタルPC等があるため、
それら全てに個人情報が紐づいていることはあり得ませんよね。

 

そのため、現在の仕組みでは、違法アップロードコンテンツは閲覧し放題、というわけです。

 

各作家や、アーティストの方々を思い込めて制作したコンテンツを、無料で見て、
それらを違法アップロードしている側の人間は、広告収入を得ている、、、なんて残酷な世界でしょうか。

 

先程も申し上げた通り、私は違法アップロードも、その閲覧も反対の人間です。
(今の時代はたった\1,000/月程で、公式アップロードのコンテンツが見れますよね。)

 

違法アップロード、その閲覧を防ぐために、私が思うその対策は、以下の通りです。

 

①ルールで縛る。(法律や条例等)
これはめちゃくちゃ大変ですが、必要だと思います。法律なり、条例なりで、きっちり厳罰化して、まずはそれを周知することが必要だと思います。
これを思った理由の一つとして、違法コンテンツを扱っている人のほとんどが、罪の意識が全くないためです。
ITインフラが余りにも急速に発達しすぎて、その教育が一切追いついていない、無知のまま、ただ漫然と便利な世の中になったなぁと使っている人が多すぎます。

 

②逆探知できると公表する。
先程私は、逆探知できないと申し上げましたが、術はあると思っています。
なぜなら、MACアドレスは、各端末毎に紐づいてしまっておりますが、IPアドレスは、各プロバイダ(NTTとかKDDIとかですね)が間違いなく、情報を管理しているためです。
これらは明らかな超重要個人情報なので、一般的には公表できない=逆探知できないと判断しましたが、
警察等の限られた立場の方々であれば、電話記録も確認できるらしいので、こういった情報も閲覧できると思われます。

このことを周知するのです。(ある種脅しのようですが、各アーティストの立場を考えると、これくらい行動してもいいのでは、、、と思います。)

 

③いっそのこと、全て無料で公開する。(広告収入等で利益は得られるようにして欲しい。)
極端ですが、これもありなのかな、と思います。
まぁペイできないため、中々進まないのでしょうけど、無料で勝手に見られるくらいなら、いっそのこと、本家がハイクオリティで無料公開し、新たなビジネス展開を行うのもありなのかな、と思います。

 


ここまで、話をしてしまいましたが、海外では、違法アップロードを完全に制限したところ、逆にCDの売上が落ちてしまった、という例もあるようです。

皮肉なことではありますが、違法アップロードのコンテンツが広告の役割をしていた、ということですね。

 


皆様も、価値があると思ったものには、きっちりその分の対価を支払って、
楽しみましょう。

 

 

技術的なことを語りたかったのですが、つい道徳的な話になってしまいました、、
申し訳ありません。

 

明日からは、もう少し専門的なプログラミング、ITインフラの技術について、語っていきたいと思います。


それではまた。