4K HDR 対応I/F(HDMI、DisplayPort、Thunderbolt3)
- Thu
- 12:08
- misc
2018年になってそろそろ4K HDRの環境がそろってきたと思ったら案外古い規格のポートだったりいろいろややこしいのでまずはHDMI、DisplayPort、Thunderbolt3の各I/Fまとめ。
4K、HDRに対応するI/Fバージョン表
今、ディスプレイ買うなら32インチのHDMI2.0a以降、DP1.4以降、USB Type-C(PD対応)のポートを揃えてるものが理想。
31.5インチのBenQ EW3270Uか、42.51インチのフィリップス 436M6VBRAB/11辺りが良さそうなんだけど、どっちももう一歩足りない。惜しい
Macbook等のApple製品は、Thunderbolt3一本のみ(IntelとAppleの共同開発だから)。ちなみに、Thunderbolt2は2012年頃のMacbook Proに搭載されたもので今からこれを採用する機種はないので割愛。
Windowsでは、HDMIかDisplayPortの選択となるのですが、ディスプレイ側はなぜが2018年になってもHDMI 2.0までやDisplayPort 1.2までしか対応してなかったりとPC側の性能を十分引き出せないものがまだ出ています。
Thunderbolt3は4K HDRのみでなく、8K@60Hzまで対応してる。現状ではThunderbolt3一強。ここまでくるとディスプレイ側の進歩が待たれます。
ちょうど過渡期を抜けそうな時期だし、規格の実験段階終了ということでディスプレイメーカで取捨選択した方がユーザもPC側パーツメーカも幸せになれるんじゃないかな。
各I/FのWikipediaへのリンク
HDMI - Wikipedia
DisplayPort - Wikipedia
Thunderbolt - Wikipedia
4K、HDRに対応するI/Fバージョン表
I/F規格 | 4k | HDR |
HDMI | 1.4 (@30Hz) 2.0 (@60Hz) | 2.0a |
DisplayPort | 1.2 (@60Hz) | 1.4 |
Thunderbolt3 | ○ | ○ |
今、ディスプレイ買うなら32インチのHDMI2.0a以降、DP1.4以降、USB Type-C(PD対応)のポートを揃えてるものが理想。
31.5インチのBenQ EW3270Uか、42.51インチのフィリップス 436M6VBRAB/11辺りが良さそうなんだけど、どっちももう一歩足りない。惜しい
Macbook等のApple製品は、Thunderbolt3一本のみ(IntelとAppleの共同開発だから)。ちなみに、Thunderbolt2は2012年頃のMacbook Proに搭載されたもので今からこれを採用する機種はないので割愛。
Windowsでは、HDMIかDisplayPortの選択となるのですが、ディスプレイ側はなぜが2018年になってもHDMI 2.0までやDisplayPort 1.2までしか対応してなかったりとPC側の性能を十分引き出せないものがまだ出ています。
Thunderbolt3は4K HDRのみでなく、8K@60Hzまで対応してる。現状ではThunderbolt3一強。ここまでくるとディスプレイ側の進歩が待たれます。
ちょうど過渡期を抜けそうな時期だし、規格の実験段階終了ということでディスプレイメーカで取捨選択した方がユーザもPC側パーツメーカも幸せになれるんじゃないかな。
各I/FのWikipediaへのリンク
HDMI - Wikipedia
DisplayPort - Wikipedia
Thunderbolt - Wikipedia
Nokia 2を購入したので早速開封
- Sat
- 17:07
- misc
2018年元旦にアメリカのAmazon.comでお買い物
- Thu
- 21:04
- misc
ということで、どういうわけか元旦からアメリカのAmazon.comでお買い物したので、そのメモ。
配送方法は、Shipping Speed: AmazonGlobal Standard Shippingという、一番安い標準のもの。
支払い方法や届け先住所などは日本と同じ。
支払方法のところで日本円表示にすることも可能。
スマホの送料は853円。もっと大きいものだともっとするかも。詳細は商品のリンクから。
Order Details › Track Package でどこまで配送が進んでいるかでますが、予定を過ぎると下記のように新しい配送予定が表示されます。
See detailsをクリックすると下記のような詳細を見ることが可能。
ほぼ配送がすんでるのでいろいろ表示されてます。
AmazonGlobal Standard Shippingで配送するとトラッキングされないという話もあったのですが、できるようです。
Initiated customs clearance processがあると海外へ配送済みで、
Completed customs clearance processがあると日本に到着してるはず。多分。
今回はUPSで配送されているようなのでi-parcelのページからトラッキング可能。
https://tracking.i-parcel.com/ UPS i-parcel: Tracking
See detailsにTracking IDがあるので上記のページにいれると詳細が表示されます。
が、AmazonのSee detailsとほとんど同じ。
元旦購入ということで、実際に配送が始まったのが9日でやや時間がかかったようです。また、予定では18日届く予定だったのですが、1、2日遅れているようです。
ということで、大体20日みとけば大丈夫かなと思いました。
配送方法は、Shipping Speed: AmazonGlobal Standard Shippingという、一番安い標準のもの。
支払い方法や届け先住所などは日本と同じ。
Country:Japan (選択) Full name:氏名 Street address:上段に「番地, 町名」、下段にマンション名部屋番号など 例:1-18-21, Shibuya City:市区町村 例:Shibuyaku State / Province / Region:都道府県 例:Tokyo Zip code:郵便番号 例:150-8010 Phone number:電話番号。東京都の場合、「+81-3-XXXX-XXXXX」 市外局番の「03」の最初の0は不要。
支払方法のところで日本円表示にすることも可能。
スマホの送料は853円。もっと大きいものだともっとするかも。詳細は商品のリンクから。
Order Summary Item(s) Subtotal: JPY NNNN Shipping & Handling: JPY 853 Total before tax: JPY NNNN+送料 Estimated tax to be collected: JPY 0 Grand Total: JPY NNNN+送料
Order Details › Track Package でどこまで配送が進んでいるかでますが、予定を過ぎると下記のように新しい配送予定が表示されます。

See detailsをクリックすると下記のような詳細を見ることが可能。
ほぼ配送がすんでるのでいろいろ表示されてます。
AmazonGlobal Standard Shippingで配送するとトラッキングされないという話もあったのですが、できるようです。

Initiated customs clearance processがあると海外へ配送済みで、
Completed customs clearance processがあると日本に到着してるはず。多分。
今回はUPSで配送されているようなのでi-parcelのページからトラッキング可能。
https://tracking.i-parcel.com/ UPS i-parcel: Tracking

See detailsにTracking IDがあるので上記のページにいれると詳細が表示されます。
が、AmazonのSee detailsとほとんど同じ。

元旦購入ということで、実際に配送が始まったのが9日でやや時間がかかったようです。また、予定では18日届く予定だったのですが、1、2日遅れているようです。
ということで、大体20日みとけば大丈夫かなと思いました。
ターンアラウンドタイムとレスポンスタイム
- Sun
- 17:27
- misc
ターンアラウンドタイムとレスポンスタイムについて、誤解があるのか方言があるのか人により微妙に意味が異なっているような時があります。
一般的にターンアラウンドタイムが短縮されるとユーザの満足度が上がり、レスポンスタイムが短縮されるとユーザのイライライ(ストレス)が減るとされています。
で、最近気づいたのが銀行やレンタル屋さんなど昔からあるIBMでいうところの「適用業務」の経験がある人と、Webサービスしか経験がない人との間でその差が大きいような気がします。
どちらの場合も重要なのは、「処理」の区切りをどこにするかというこです。特にターンアラウンドタイムは一連の処理が完了するまでという区切りになるので「処理」の定義をあいまいにしておくと実際にはやらなくていい処理、業後や夜間バッチでやるべき処理まで含めてしまい業務が回らない作業フローやJOBフローを作ってしまう場合があります。

レンタル店の会員カード発行の処理はターンアラウンド/レスポンスタイムを説明するのによく使われる例です。
ポイントは、レスポンス2のところで申込書にある項目全てをその場で入力するのではなく、カード発行に必要な申込書とカードの紐付けだけを行うということです。そうしないと、貸出・返却のお客さんを待たせてしまい、カウンターに長蛇の列ができてしまいます。
名前や住所等その場で必要のない情報は、暇な時間やお店を閉めた後でゆっくりやればいいのです。

昔のGoogleはいち早くユーザを検索結果のページの先に飛ばすことを優先していましたが最近は検索結果内で完結できるようにして満足度を上げようとしています。
例えば、queen don't stop me now lyricsを検索すると検索結果ページに歌詞が表示されます。これは、レスポンスタイム3の処理を2に含めることでターンアラウンドタイムを短縮しています。ユーザはさらに別のページ飛ぶ必要がない(待たされない)ので、顧客満足度の向上が期待できます。
このように、ターンアラウンドタイムとレスポンスタイムはサービスを向上させるための大事な指標になります。
処理の区切りを単に「リンクをクリックしてページを表示する」とした場合、ターンアラウンドタイムとレスポンスタイムはほぼ同じものになります。しかし実際にはそういったものを「処理の単位」とすることはほとんどありません。Googleのレスポンスタイム2のように「ユーザの入力時間」「送信時間」「Google側の処理時間」「結果の受信時間」というようにそれぞれの時間の合算になります。
また「ユーザ登録」という処理を考える場合、「ユーザ登録ボタン押下」「ユーザ情報の入力」「内容の確認」「完了報告」というレスポンスタイムを計る必要があるかもしれません。もし「ユーザ情報の入力」の時間が長い場合は、UIが分かり難い、不要な項目まで入力させている、そもそも入力し辛い、などが考えられます。改善することで登録完了数を増やすことが可能かもしれません。但し時間だけを見ても分かり難い場合が多いのでトラッキングや他の指標なんかも参考にする必要があります。
ということで、この2つの処理時間を使ってサービスを改善するためにはターゲットとする処理の単位をどう設定するかが重要になります。
ターンアラウンドタイム | 一連の処理の開始から完了までの時間 |
レスポンスタイム | ユーザのアクションから応答までの時間 |
で、最近気づいたのが銀行やレンタル屋さんなど昔からあるIBMでいうところの「適用業務」の経験がある人と、Webサービスしか経験がない人との間でその差が大きいような気がします。
どちらの場合も重要なのは、「処理」の区切りをどこにするかというこです。特にターンアラウンドタイムは一連の処理が完了するまでという区切りになるので「処理」の定義をあいまいにしておくと実際にはやらなくていい処理、業後や夜間バッチでやるべき処理まで含めてしまい業務が回らない作業フローやJOBフローを作ってしまう場合があります。
レンタル会員のカード発行処理のターンアラウンドタイムとレスポンスタイム

レンタル店の会員カード発行の処理はターンアラウンド/レスポンスタイムを説明するのによく使われる例です。
ポイントは、レスポンス2のところで申込書にある項目全てをその場で入力するのではなく、カード発行に必要な申込書とカードの紐付けだけを行うということです。そうしないと、貸出・返却のお客さんを待たせてしまい、カウンターに長蛇の列ができてしまいます。
名前や住所等その場で必要のない情報は、暇な時間やお店を閉めた後でゆっくりやればいいのです。
GoogleでTPPを調べる処理のターンアラウンドタイムとレスポンスタイム

昔のGoogleはいち早くユーザを検索結果のページの先に飛ばすことを優先していましたが最近は検索結果内で完結できるようにして満足度を上げようとしています。
例えば、queen don't stop me now lyricsを検索すると検索結果ページに歌詞が表示されます。これは、レスポンスタイム3の処理を2に含めることでターンアラウンドタイムを短縮しています。ユーザはさらに別のページ飛ぶ必要がない(待たされない)ので、顧客満足度の向上が期待できます。
このように、ターンアラウンドタイムとレスポンスタイムはサービスを向上させるための大事な指標になります。
処理の区切りを単に「リンクをクリックしてページを表示する」とした場合、ターンアラウンドタイムとレスポンスタイムはほぼ同じものになります。しかし実際にはそういったものを「処理の単位」とすることはほとんどありません。Googleのレスポンスタイム2のように「ユーザの入力時間」「送信時間」「Google側の処理時間」「結果の受信時間」というようにそれぞれの時間の合算になります。
また「ユーザ登録」という処理を考える場合、「ユーザ登録ボタン押下」「ユーザ情報の入力」「内容の確認」「完了報告」というレスポンスタイムを計る必要があるかもしれません。もし「ユーザ情報の入力」の時間が長い場合は、UIが分かり難い、不要な項目まで入力させている、そもそも入力し辛い、などが考えられます。改善することで登録完了数を増やすことが可能かもしれません。但し時間だけを見ても分かり難い場合が多いのでトラッキングや他の指標なんかも参考にする必要があります。
ということで、この2つの処理時間を使ってサービスを改善するためにはターゲットとする処理の単位をどう設定するかが重要になります。