vol46. サングラスと白人
なぜ外人はサングラス率が高いのかな？
海外に行くと外人(白人)がサングラスをかけててとてもカッコいい。
鼻が高くてとっても似合っている。男性だけでなく女性もかける。
外人ってサングラス率がすごい高いよね。
日本人の場合は、太陽光が直接目に入ってくる状況ではサングラスをかけるけど、
それ以外の場合は、よほどの夏日でない限りないんじゃないかな？
でも、アメリカでは違う。車を運転する時なんて、特にそう。
夏の昼間ならみんなサングラスをかけている印象。
なんでなんだろう？
というわけでなんで外人はサングラス率が高いか調べてみた。
結論
結論から言うと、白人は虹彩(こうさい)の色が薄いため。
人の目は、虹彩と瞳孔(どうこう、黒目の部分)の２つの領域からなる。
虹彩とは、黒目の周りの部分。伸縮してひとみの大きさを変え、目の中に入ってくる
光の量を調節する役割がある。
白人の瞳は虹彩の色がうすく、青や緑ががかっている。虹彩の色が薄いと目の
中に入ってくる量が増える。虹彩の色が薄い白人は、かなりまぶしいらしい。
(日本人は大半が茶色とか黒っぽい色。だから入る光の量が少なく、よって眩しいと感じにくい。)
なるほどー。
ふと振り返ると、確かにアメリカの家やホテルといった、屋内の電球も、
色温度が3000Kあたりのオレンジ色の電球がメイン。日本のような4000K
や5000Kの白色の電球はあまり使われないなぁ。
そういうことかー。
vol45. 本庶佑さんの開発したがん治療法について整理してみた
ノーベル医学生理学賞に、本庶佑（ほんじょたすく）さんが受賞。
聞けば、がんに効く薬を発明されたとか。
すでにその薬も実用され、多くの人がガンを克服し、健康を取り戻しているとか。
いやぁ、素晴らしい。
この薬が普及すれば、抗がん剤で苦しむ人々もだいぶ少なくなるのではないか？
そして、現在の死因１位ががんという状況も変わってくるのではないか？
どんな方かを調べて見た。
本庶佑さん
- 76 歳 (2018/10現在)
- 京都大
- 1999年10月、京大医学部長だった本庶さんは既にノーベル賞の有力候補だった
- 92年に今回の授賞理由ともなったPD－1を発見以来、毎年のように有力候補として注目されてきた
受賞理由は、PD-1という分子を発見したこと
今回の受賞の理由は、PD-1という分子を発見し、がん免疫治療法の急速な進歩に寄与した
事に対するものだという。
PD-1とは何か？調べたら、どうやら以下のようなものらしい。。。。
PD1
- 免疫細胞(T細胞)の表面に発現する
- 免疫細胞表面に存在するPD-L1と結合することにより、がん細胞を攻撃する免疫細胞
に、攻撃ブレーキをかける分子- 免疫は暴走して自分の臓器や神経を攻撃しはじめることもあるので、そう
ならないようにブレーキ機能がついている
- 免疫は暴走して自分の臓器や神経を攻撃しはじめることもあるので、そう
PD-L1
- がん細胞の表面に発現する分子
- PD-1と結合する事で、T細胞の活性化を抑止する
がんが生き残るしくみ
がんの全体のメカニズムとしては、以下の通り
- がん細胞ができる。
- 免疫細胞(T細胞)は、他の悪性細胞と同様に、がん細胞を攻撃する
- がん細胞は、免疫細胞から身を守るため、免疫細胞をストップさせる分子(PD-L1)を出す
- このPD-L1と、免疫細胞の表面にあるPD1細胞が結合すると、免疫細胞の活動が抑制され
てしまう。結果、がん細胞は免疫細胞からの攻撃から逃れることになる。
そこで、この仕組みに目をつけ、オプシーボという新薬を開発した。
オプシーボ
- ニボルマブ（商品名オプジーボ）
- 免疫チェックポイント阻害薬
- PD-L1とPD-1の結合を阻害する抗体
- PD-1にピンポイントで結合する抗体
PD-1受容体すなわち受け皿に蓋（ふた）をして、PD-L1が結合しないようにする。
- PD-1にピンポイントで結合する抗体
- PD-L1とPD-1の結合を阻害する抗体
本庶佑さんが開発した治療方法は、従来のアプローチとは全く異なるアプローチだとか
従来のアプローチ
まとめ
抗ガン剤に頼らなくても、回復する可能性があるなんて、なんて素晴らしいがん治療法なんだ！！ 素晴らしい！！これで平均寿命も劇的に伸びるのでは？？
参考
https://www.ono-oncology.jp/contents/patient/immuno-oncology/step3_05.html
vol44. イギリス
出張でイギリスに行くことになった。友人に英語で話そうとすると、あれ？？イギリスっ
て英語でなんて言うんだっけ？とふと疑問に思った。
ぱっと思いつくだけで、イギリスを表す言葉がいくつかある
なんで、こんな色々な言い方があるんだろう。 ということで、調べてみた。
イギリスとは
- United Kingdom of Great Britain and Northern Ireland
グレートブリテン及び北アイルランド連合王国を指す - 日本語における一般的な略称は、イギリスか英国
- イングランド、ウェールズ、スコットランド、北アイルランドの4つの国で構成されている
- 「イギリス」はポルトガル語でイングランドを指すInglez（イングレス）が語源で、 元の意味にかかわらず連合王国全体を指して使われている。
- グレートブリテン島・アイルランド島北東部・その他多くの島々から成る
イングランドとは
グレートブリテンとは
グレート・ブリテンという島の名前がある
グレートブリテンという王国は、1707 年に成立した。現イギリスの前身。
1801年にアイルランド王国と合同し、新たにグレートブリテンおよびアイルランド連合王国(イギリス)が成立した。
ブリティッシュとは
「イギリスの」「イギリス人の」「イギリス式の」を表す英単語 British
イングランド人を呼ぶ時は、English スコットランド人を呼ぶ時は、Scottish ウェールズ人を呼ぶ時はWelsh 北アイルランド人を呼ぶ時は、Nothern-Irish
「日本の」「日本人の」「日本式の」はJapanese
参考
ここのまとめサイトがうまくまとまっている。
ユニオン・フラグ（連合王国旗）は、イングランド、スコットラ
ンド、北アイルランドの旗が合成されてできたものだったのね。
知らなかった。
他に参考したサイトはこちら
- https://e-concern.com/uk/#i
- https://1ovely.com/united-kingdom-or-great-britain/
- https://schoolwith.me/columns/32142
vol43. DNSサーバーとping
たまに、dns server が落ちたりして、名前解決ができない事がある。
これまで、dns server の生存確認に、以下のように、ping を使っていたのだが、
$ ping 156.154.70.1
ping は通らないけど、dnsは動いているということがあるのね。。
(下のスクリーンショットから、ping の応答はないけど、DNSのresponse はあることが確認できる。)
まぁ、冷静に考えれば、そのdns server がicmp プロトコルをサポートしていなければ、
ping に対する応答がないのは当然であるといえば当然なのだが、
icmp はすべてのネットワーク機器はサポートしていると思い込んでいた。。
少しググると、dns のquery メッセージは、dig コマンドで投げることができる。
DNS server が生きていれば、DNS response メッセージを返すので、
これで確認できる。
dig [@server]
$ dig @156.154.70.2 ; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @156.154.70.2
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1469
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS;; ANSWER SECTION:
. 512788 IN NS a.root-servers.net.
. 512788 IN NS b.root-servers.net.
. 512788 IN NS c.root-servers.net.
. 512788 IN NS d.root-servers.net.
. 512788 IN NS e.root-servers.net.
. 512788 IN NS f.root-servers.net.
. 512788 IN NS g.root-servers.net.
. 512788 IN NS h.root-servers.net.
. 512788 IN NS i.root-servers.net.
. 512788 IN NS j.root-servers.net.
. 512788 IN NS k.root-servers.net.
. 512788 IN NS l.root-servers.net.
. 512788 IN NS m.root-servers.net.;; Query time: 20 msec
;; SERVER: 156.154.70.2#53(156.154.70.2)
;; WHEN: Mon Oct 01 18:04:31 EDT 2018
;; MSG SIZE rcvd: 239
ちなみに、Linux では、dns server の設定は、/etc/resolv.conf で行う。
$ cat /etc/resolv.conf
domain ol.csi.178
search ol.csi.178
nameserver 156.154.70.1
nameserver の後のip address がDNS server のip address だ。
vol42. Quitaについて調べてみた
疑問
何か技術情報を調べるためにググると、最近はよくQuitaのサイトに投稿されている記事 がヒットする。
「Quitaって何だろう？」
「Quita はエンジニアに評判がいいと聞くけどなんでだろう？」
「なんでみんな技術ネタはQuita に投稿するの？」
ふと疑問に思ったので、Quitaについて少し調べてみた。
Quitaは
日本で最大のプログラマーコミュニティー
- 言語化することで自分の知識を整理
- 自分の備忘録
- 他者にも最大限貢献したい という目的を果たしている。
再利用可能な技術情報共有サイトというコンセプトに則って、サイトが設計されている
- 情報の取得がしやすい仕組みを整えている。(フォローやストック、ニュース フィード機能など。）
Quitaの概要
Quitaの特徴
- 再利用可能な知識の保存が目的
- タグを付けた文章、シンタックスハイライトされたコードで保存
- ニュースフィード
- エンジニアに特化した
- フォロー
- 興味のある言語をフォローできる
- ストック
- 興味のある記事をストックし、後で閲覧できる
感想
確かにQuitaのサイトを覗いてみると、UIは情報を検索するのに、使いやすそうな印象を受ける。 日本のエンジニアを応援するようなサービスが増えるのは、１エンジニアとしても嬉しい。
海外ではみな技術ネタはどこに投稿するんだろう？ 今度しらべてみよう
vol41. home theater room をつくろう
ミシガン州に住みはじめてはや１年経過。移住当初は文化の違い、言葉の違いに色々大変
な思いもしたが、最近は、ようやく余裕もでて日常生活を楽しめ始めるようになってきた
。
一軒家を賃貸しているのだが、アメリカの家には、地下室があるのが一般的。
finishされていない家も多数ある中、幸いなことに、我が家の地下室は物置場とfinishさ
れている部屋が一つある。
これまで地下室はほとんど利用されず、たまに子供の遊び場として利用したのだが、家族が 子供の夏休みを利用して帰国し、自分の時間を確保できるようになったため 、このチャンス を逃すものかと、この部屋を念願のhome theater room にすることにした。
地下室のtheater roomは、涼しいので夏はとても快適。大音量を出しても、1階には多少音 が伝わるかもしれないが、寝室のある2階までには迷惑かからないので、真夜中にも好き な映画が音楽が楽しめる。
TVはリビングで使っていた55inch のSHARPのTVを移動、あとは、PS4とDVD/Blueray player (アメリカではregionが日本と異なるため、PS4でアメリカのDVDは見れない。 Bluerayはregion freeなため視聴可能)を地下に移動する。あとは、音響だ。理想はもち ろん7.1ch !!
調べ始めると、アンプは思ったよりも安価で手に入る。
あとはスピーカーだけど、ググるとうわーめっちゃ高い。一つのスピーカーに５万も払えないよー
。どうしようー。でいろいろ調べてみると、以下のやつが手頃で良さそう。まずはこのエ
ントリーモデルのやつから初めて、もし欲が出て来たら少しずつ買い足していこうかな。
。
- Speaker
- Yamaha NS-SP1800BL 5.1ch
- $149
- Yamaha NS-SP1800BL 5.1ch
この世界は本当に「底のない沼」世界で、追求すればするほど、お金が湯水のようにとん
でいくみたい。スピーカー一つに何十万円もかけるらしいので気をつけなくては。。
vol40. RTP関連のRFCたち
RTPにまつわるRFCの内容を整理してみた。
RTP(Real-time Transport Protocol)。音声や動画などのデータストリームをリアルタイ ムに配信するための、通信プロトコル。でも、どういう仕組みで、リアルタイムを実現し ているのか？
RTPはアプリケーション層のプロトコル。 トランスポート層に通信オーバヘッドの軽く、再送要求のない、UDPを用いるだけでは不 十分なのか？
そんなことをふと疑問に思ったので、調べてみた。
一言でまとめると、UDPはsequence number がないので、順序の組み立てができない。 よって、RTPの「sequence number」を用いて、正しい順番にパケットを並び戻すことができる。 また「timestamp」を用いることで、意図的に遅延したフレームは破棄をすることで、 リアルタイム性を確保できる。
調べてみると、RTP基礎部分のRFCだけでもいくつかあるので、いかにまとめておく。
RTP: A Transport Protocol for Real-Time Applications
- RFC number
- RFC3550
- RFC1889(obsolete)
- 内容
- RTP header の定義
- 送信側のパケット送出タイミングを受信側でも復元できるようにする
- 符号データのパケット化
- 送信者のシーケンス番号とタイムスタンプ情報を送信
- 受信側は、これを参照にリアルタイム性を確保
- 送信側のパケット送出タイミングを受信側でも復元できるようにする
- RTP header
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- RTP header の定義
RTP Profile for Audio and Video Conferences with Minimal Control
- RFC number
- RFC3551
- RFC1890(obsolete)
- 内容
- 符号データごとの具体的なフレーミング方法，すなわちRTPパケットのフォーマット
オーティオやビデオデータの圧縮方法ごとにペイロードフォーマットがある それらを定義
定義されている payload type (audio)
PT encoding media type clock rate channels name (Hz) ___________________________________________________ 0 PCMU A 8,000 1 1 reserved A 2 reserved A 3 GSM A 8,000 1 4 G723 A 8,000 1 5 DVI4 A 8,000 1 6 DVI4 A 16,000 1 7 LPC A 8,000 1 8 PCMA A 8,000 1 9 G722 A 8,000 1 10 L16 A 44,100 2 11 L16 A 44,100 1 12 QCELP A 8,000 1 13 CN A 8,000 1 14 MPA A 90,000 (see text) 15 G728 A 8,000 1 16 DVI4 A 11,025 1 17 DVI4 A 22,050 1 18 G729 A 8,000 1 19 reserved A 20 unassigned A 21 unassigned A 22 unassigned A 23 unassigned A dyn G726-40 A 8,000 1 dyn G726-32 A 8,000 1 dyn G726-24 A 8,000 1 dyn G726-16 A 8,000 1 dyn G729D A 8,000 1 dyn G729E A 8,000 1 dyn GSM-EFR A 8,000 1 dyn L8 A var. var. dyn RED A (see text) dyn VDVI A var. 1 Table 4: Payload types (PT) for audio encodings定義されている payload type (video)
PT encoding media type clock rate name (Hz) _____________________________________________ 24 unassigned V 25 CelB V 90,000 26 JPEG V 90,000 27 unassigned V 28 nv V 90,000 29 unassigned V 30 unassigned V 31 H261 V 90,000 32 MPV V 90,000 33 MP2T AV 90,000 34 H263 V 90,000 35-71 unassigned ? 72-76 reserved N/A N/A 77-95 unassigned ? 96-127 dynamic ? dyn H263-1998 V 90,000 Table 5: Payload types (PT) for video and combined encodings
RTP Payload Format for H.264 Video
- RFC number RFC6184 RFC3984(obsolete)
- 内容
- h264 をRTPにのせる為のpayload format を定義
3種類のpayload structure を用意
- Single NAL Unit Packet
- 一つのNAL unitを一つのRTP message で送信する
- Aggregation Packet
- 複数のNAL unitを一つのRTP message で送信する
- Fragmentation Unit
- 一つのNAL unitを複数のRTP message に分割して送信する
Table 1. Summary of NAL unit types and the corresponding packet types NAL Unit Packet Packet Type Name Section Type Type ------------------------------------------------------------- 0 reserved - 1-23 NAL unit Single NAL unit packet 5.6 24 STAP-A Single-time aggregation packet 5.7.1 25 STAP-B Single-time aggregation packet 5.7.1 26 MTAP16 Multi-time aggregation packet 5.7.2 27 MTAP24 Multi-time aggregation packet 5.7.2 28 FU-A Fragmentation unit 5.8 29 FU-B Fragmentation unit 5.8 30-31 reserved -
- 一つのNAL unitを複数のRTP message に分割して送信する
- Single NAL Unit Packet
Ethernet AVB IEEE1722 で定義されているstream format の一つであるCVFを用 いて、h264 を送信する際も、このプロトコルを利用する
Value Name Description 0 MJPEG MJPEG Format (RFC 2435) 1 H264 H.264 Format (RFC 6184) 2 JPEG2000 JPEG 2000 Video (RFC 5371) IEEE1722-2016 Table 20 format_subtype field for RFC Format より
