あした思い出すよう

あさってもその次も

Mini DisplayPort HDMI変換アダプタ for Mac 接続使用感想

エレコム
Mini DisplayPort HDMI変換アダプタ for Mac
型番:AD-MDPHDMIWH
http://www2.elecom.co.jp/cable/adapter/display/ad-mdphdmi/

f:id:dokosuke:20170807234248j:plain
Mini DisplayPort[オス]---HDMI[メス]


「for Mac」とありますが特にMac用というわけではなく、Mini DisplayPortがあれば問題ありません。
用途としてはMini DisplayPortのあるノートPC等とモニタを接続するためのケーブル。


・見た目
接続部分がツヤツヤしていて好み。
変にゴム素材ではなく引っかかりが少ない。

 

f:id:dokosuke:20170807234715j:plain
ケーブル部分はそれなりの摩擦感。


・Mini DisplayPortについて
思ったよりグニグニ動く。HDMIの様にグサッとささっている感ではない。
Mini DisplayPortの特性ではあるのでしょうが、もう少しささっている感はほしい。


仕様ページをみると「Mini DisplayPortからHDMIへ」出力は可能なものの、その逆は不可とのこと。

 

f:id:dokosuke:20170807235744j:plain
HDMIとMini DisplayPortのあるノートPCから、搭載グラフィックとして可能であれば2画面(HDMIとMini DisplayPortを用いて)ディスプレイすることも。
Mini DisplayPort[オス]---HDMI[オス] といった1つのケーブルもありますが、HDMIは単なるHDMIケーブル(オス---オス)として使用していた方が、各接続を差し替えをするときなど後々役に立つのではないかと思います。


Mini DisplayPort HDMI変換アダプタを使用した感想でした。

ブラウザ雑記 Kinzaでの再生について(2017-07)

FirefoxとKinzaを使用比較して数ヶ月。

ブラウジングしていてなにかしら引っかかりがあると作業が止まってあまりよろしくないなと。

 

・Kinzaで再生エラーが起きるものがある

今に始まったことではありませんが、Kinzaを使用しているとき組み込まれた動画などのメディア を再生しようとすると「メディアを再生できませんでした。」が発生するとしょんぼりです。再生しようとするなら他のブラウザにコピペして再生することになります。

 

f:id:dokosuke:20170716182559p:plain
再生時に表示されるこれ

 

GIFの組み込みのような動画でも再生できるものとできないものがあり、再生の三角をクリックしてみるまでよくわからないのはもどかしい。
DRMコンテンツ等の再生はKinzaにとって鬼門で、AmazonビデオのようなものもKinzaでは再生不可です。

 

FirefoxとKinzaを使用して数ヶ月

メインブラウザとしてはFirefoxとKinzaを使用してみて、Kinzaにおける上記のメディア再生については気になるところではあります。どちらのブラウザでもメインで使用しているGoogleへログインしているため(Kinzaの方では「Kinzaにログイン」も)、両方のブラウザでGoogleサービスを使用することがよくあります。

Chrome系のブラウザだけあってGoogleサービスを使用しているときはFirefox仕様時よりKinzaの方が安定しています。(Google Keepで複数の画像付きメモをページに多く読み込んでいるときなど)

 

縦タブツリーでブラウジング可能なGoogleサービス仕様時専用ブラウザとしても良いです。

 

FirefoxはいつもどおりというかGoogle Keepの画像多めに表示したページでは時折つらそうな感じです。ただ再生に関してはKinzaのようなことを感じることはあまりありません。

それぞれの得意不得意を意識しながらKinzaとFirefoxでの使い分けで楽しくブラウジングしています。

 

・とはいえ再生で止まってほしくない

再生するまで(再生する毎に)再生できるかどうかわからないのは困ります。DRM関連の動画が仕様上再生が不能であるなら、それは避ける方法でなんとかなるはずですがDRM以外にもちらほら再生エラーが起きるものもあります。

それ毎にURLをコピーするのも手間ですし、止まった際にはそもそも再生できないことが発生しそうにない他のブラウザでアクセスしたくもなりました。

 

そのあたりがKinzaのなんだかとてももったいない部分だなと思います。

 

-参考
DRM対応動画の再生について(要望) / 新機能や改善の要望 / Kinza 要望やバグ報告

 

-画像
Kinza 「メディアを再生できませんでした。」より

 

Kinza 64bit版をインストールして試す-Kinza Ver4.0.0-

64bit版KinzaがVer4.0.0より登場したようです。

Kinza公式ページ「[リリース] Kinza4.0.0を公開しました」より
https://www.kinza.jp/blog/2017/06/27/kinza-4-0-0-released/

32bit版Kinzaを使用しているだけにこれは素直に嬉しいです。
更新に関してと64bitへの移行メモ。

・64bit版Kinzaダウンロードの場所

32bit版Kinzaを使用している場合、「Kinzaについて」の「Kinzaの最新版があります『今すぐ更新』」をしても32bit版のダウンロードボタンしかないページに移行します。
.jp以下URL /download/?platform=windows_x86

もう一度Kinza公式ページ内上部メニューの「ダウンロード」をクリックすると、32bit版と64bit版それぞれのダウンロードボタンが現れます。
.jp以下URL /download/

f:id:dokosuke:20170628004822p:plain


なんとなくポチポチして64bitになることを避けるためか、このような仕様になっているのかもしれません。

 

・インストール時、無理に32bit版の作業を行わなくてもいい

32bit版がインストールされているWindows 10PCにおいて、/download/よりDLした64bitインストーラーを32bit版Kinzaを起動した状態で実行すると例によって「Kinzaが起動しています。」の警告が出るので32bitの方は閉じましょう。

そのまま64bit版のインストールを進めていくとインストールされていた32bit版Kinzaが64bit版Kinzaになっています。32bit版も使用し続けたい人はインストール時に注意してください。

 

上記のやり方でKinzaの環境が64bitになっても32bit版で行っていた設定やログイン情報・Kinzaにログイン、等はそのままでした。ですので無理に64bit版へ移行するからといって32bit版をわざわざ消すようなことはしなくていいみたいです。

よって普通にインストールする限りは64bit版と32bit版は共存できません。


・変更点について

設定のマテリアルデザイン化も特に変わった部分であります。
Google Chrome 59でも「設定」がそのようになったように、Kinzaでもマテリアルデザインになったかたちです。

Kinzaの「設定」に関しては項目が多いため、そのうち「ピン止め(左メニューの常時表示)」とかが実装されるのではないかと考えています。

f:id:dokosuke:20170628010248p:plain

 

拡張機能」が「設定」に無いのでメニューから開く必要があり、拡張機能は設定から開いていたため若干遠く感じました。


・感想

64bitに移行するにあたってログインのやり直し等手間がかかるものと思っていましたが、あえて手間というならば単に64bit版Kinzaをダウンロードするくらいでした。
そもそも今までのKinzaも更新時は「ダウンロード」ページへ行き更新のためにDLしていたのでいつも通りの操作です。(設定ページから更新できた方がもちろん楽ではあります)

 

Kinza Ver4.0.0となったばかりですし今後細かな修正が入るはずです。
そのあたりの更新を64bit版Kinza Kinza Ver4.0.0では楽しみにしたいと思います。

 

-画像
・キャプチャ
Kinza公式ページ内
Kinzaブラウザ内

 

 

はてなブログ 見たまま編集やアプリでEnter,Shift+EnterしたときのHTML表記

「見たまま」モードならShift+Enterがなんだかんだ使いやすかったです。

HTMLのエディターを使用しても同じことができますが、投稿するためのツール(同ブラウザ)内で完結でき、Shift+Enterに慣れてくると手間が少なくてすみます。

 

以下はてなブログ 見たまま編集やアプリでEnter,Shift+EnterしたときのHTML表記について。

 

・PCブラウザからはてなブログを編集

---例文ここから---

aaaあああ(ここからEnter) 

次の行 あああ

あああ

 

aaaあああ(ここからShift+Enter)
次の行 あああ
あああ

---例文ここまで---

 

上記例文を見たままにて編集しているときの画像は以下のようになり、改行の種類もEnterとShift+Enterの区別はつきます。

f:id:dokosuke:20170624194008p:plain

「HTML編集」画面。
Enterしたときの<p>はHTMLでも改行されていますがShift+Enterしたときの文章はそのままHTML的には一行になっています。

f:id:dokosuke:20170624194302p:plain

 

はてなブログアプリからはてなブログを編集

はてなブログ」(Android)の編集機能を使って検証。
「アプリで編集→PCはてなから改行の状況をみる」という流れ。

 

f:id:dokosuke:20170624231656p:plain
編集時に端末によっては重さを感じるかもしれません。
「保存」していない状態で編集中にアプリがおちた場合、保存はされていません。つらい。

 

---ここからはてなブログアプリ---

アプリ 改行(スマホIME内 エンター)

あああ 開業先

あああ

---ここからはてなブログアプリここまで---

 

PCブラウザからの編集と同じく、改行の様子の画像が以下。

f:id:dokosuke:20170624231317p:plain

(開業先→改行先 ...。)
HTML編集をみると、見たままでの「Enter」の扱いになるようでHTMLとしては<p>の改行となっています。

f:id:dokosuke:20170624231622p:plain

アプリを用いてスマホで改行していくと<p>が挿入されるのがよくわかりました。
スマホアプリ内編集にて文字を打ち後から編集をすると、Shift+Enterしたいところを後から追加していかなければならず大変かと思いました。

 

この場合のEnterはアプリにて端末のIMEを用いた改行ですので正確には「Enter」したとは言えません。しかし、スマホから「Shift+Enter」する方法が何かしらあったとしても手間が増える分やらないような気がします。 

 

・<p>と<p>のマージン

<p>のパラグラフとパラグラフの間が開いてるならCSSで<p>と<p>の調整が行われているはずなので、CSSを編集することでマージンの値を小さくすると調整ができます。
CSSによってはこのあたりの設定は異なるのかもしれません。
『デザイン→カスタマイズ→デザインCSS
.entry-content p { margin:0}

 

・長文に「HTML編集」用に<p>や<br>を追加することについて

以前「文章をなにかしら外部で作成し、後から<br>などを追加して~」といった記事を書いたことがありますが、このやり方だと文章が増えた際、特に<p>が増えるたびに選択右クリック項目選択を繰り返すこととなりわりと大変です。
「見たまま」モードなら直接「編集」に貼り付けて「Enter」や「Shift+Enter」で調整していく方がやりやすくは思いました。

 

f:id:dokosuke:20170322002919p:plain
以前の記事で使用した画像。
HTML編集をするやり方を知ることができたので、見たまま編集にてShift+Enterに慣れましたがこれはこれであり。

 

-ブログ内記事

ashitaomo.hatenablog.jp

 

 -画像
・キャプチャ
はてなブログ内 編集ページ
Google Play ストア
StyleNote内 編集

 

Firefox 54 マルチプロセス(e10s-multi)はアドオン環境によってはまだ有効化にならず

ベストなFirefox

blog.mozilla.org

今回の54は48からあったマルチプロセス機能(e10s-multi)が正式に使用できるようになるとのことですが、拡張機能をインストールしているユーザーは有効化にはならないようで私の環境では有効にはなっていません。

f:id:dokosuke:20170617111852p:plain
ヘルプ→「トラブルシューティング情報」より。

一体どのアドオンが原因なのか不明...。

 

f:id:dokosuke:20170618150416p:plain
ただセキュリティのこともありますし更新自体は大切です。

 

この記事を書いている段階では約30タブ開いている状態のFirefoxで作業しており、メモリ使用は約1.9GB。Chromeはプロセス自体が別れていて単純にメモリ使用の比較しにくいのですが、1タブ100MB以下メモリ使用のもあれば200~400MBのものもあります。

「縦タブ」多数のページを開くことは、タブの視認性の良さから縦タブの醍醐味で、マルチプロセスによってメモリ負荷が軽くなる(はず)のは大歓迎です。無理やり有効化にすることもできますが変にアドオンが動かなくなっても嫌ですし私は正式なマルチプロセス化が適応されるまで待とうと思います。


重さ自体は「ページによる」のでほんと単純比較はできないのですが、体感的にマルチプロセスの機能でどれだけ速く感じられるかは今後のアップデートに期待です。

 

-画像
Firefox内のスクリーンショット