DSC-QX10の接続の方法

Android端末で、レンズカメラのDSC-QX10を使う為に、Google PlayからPlayMemories Mobileをダウンロードするとわかるが、このアプリケーションはとても評判が悪い。
その理由は、

1)アプリケーションに求められる機能が備わっていない
 カメラ内の画像データのcopyはできるが削除ができない。
 カメラの撮影時の調整機能が乏しい

2)アプリケーションの出来が悪い 
wifiへの接続が悪く、レンズカメラなのに操作ができない端末が存在する

3）アプリケーションの使い方の説明が稚拙
マニュアルが乏しい。

といいった所だろう。 

アプリのコメント欄を見ると、

Wifiが繋がりません Experia z3 (Android 6.0.1) と DSC-WX200 ですが、パスワードどが違うと 全くダメです。なんとかして下さい。  

みたいなのが散見される。

iPhoneの事はわからないが（おそらく高級カメラを備えたiphoneを使っている人で、このカメラを購入するひとは稀だろう）、カメラ機能が乏しいAndroid端末の場合での接続についてかんがえて見た。

 NFCがついている場合

 NFCが付いている端末の場合で、カードリーダー等の他のNFCアプリがインストールされているケースでは、最初に行うカメラとの接続動作において他のアプリの干渉を受ける場合がある。
これを避けるには、面倒でも誤動作しそうな他のアプリを削除してから接続処理を行うと良い。

他のWiFiの干渉

このカメラは2.4GHzのWifi-DIRECTを使うが、他の多くのwifi端末やアクセスポイントがある場合に、接続傷害に陥ってしまう場合がある。
これを回避するには、WifiAutoSwitcherのようなwifi接続の優先順位を指定できるようなアプリをいれておくと良い。

カメラとの接続に成功すると、保存済みネットワーク には
DIRECT-reQ0:DSC-QX10
みたいなのができるので、これへの接続の優先順位をトップにセットしておけば良い。

接続が上手くゆかない場合

PlayMemoriesを停止した状態で、最初にwifiの詳細設定で、接続先のWiFI周波数帯域を2.4GHzのみとする。次にカメラの電源を入れてwifi設定。パスワードはQX10の裏蓋に記述してある物を利用。
接続が確認できたらPlayMemoriesを起動。ネットワークにDIRECT-xxxxxxx みたいなのがあるのでそれをクリック。
おそらくこれでカメラのモニターが開始されるハズだ。いったん接続先を記憶すれば、WifiAutoSwitcherで優先接続先をセットさえすれば、このネットワークに優先して接続するので、何十台ものスマホやアクセスポイントが集まるところでも、比較的安定して接続できるのではないかと思われる。（・・・多分）

このカメラの問題点

wifi接続での2.4GHzを利用した事。この帯域はbandが重複しており接続が不安定なのに、どうしてこの帯域を採用したのかは謎。せめて外で5GHzが利用できるようになるまで待てなかったか？

次にカメラとの通信にwifiを利用した事。これは明らかにマズイ。
サムネイル転送サイズを小さくしてでもBluetoothでの接続を考えるべきだったんじゃないか？

先日、Bluetooth5の規格が決定したので、バッテリー問題も加味すると、次期バージョンのカメラはBluetoothでの接続にすべきだろう。
スマホアプリ操作で飛ばすドローンがこんなにたくさん発売されている昨今、こんなもの程度の操作アプリが作れないなんて、SONYは恥だと思わないのだろうか・・・・・。

nexus5でnfcが使えない

nexus5のバッテリー交換を行い、ついでに初期化して新しく環境構築した所、nfcが使えなくなった。

nfc関係のアプリをインストールする際に、「この端末じゃ使えネーから」と言われなかったので、ハードウエアが故障しているようには思えない。
nfcカードリーダーを起動すると、「nfc有効になってねーから」と怒られるが、とっくに有効にしている・・・・。

裏蓋を開けて接触部分を確認しても、特に問題はみつからない。
作業は薄手のゴム手をつけておこなったので、静電気なんかは起きていないハズだし・・・・。

途方に暮れてweb検索・・・、"adb nfc" で検索してみると、

Enable/Disable NFC with ADB command

というのが見つかる。ここにコマンドの説明がされているので読んで見るが、イマイチわからない。

nexus5の開発モードで、USBデバッグを有効、スリープしないを有効にして、PCとUSB接続。コンソールから

[adb devices]
[adb shell]

を実行。

[service list]

 コマンドでnfcの番号をチェックすると、Android6.0.1では8番だったので、

[service call nfc 8]

を実施して、 

[dumpsys nfc] 

を実行してみると、いろいろ出てくる。この状態でnfcカードリーターを起動しpasmoをかざすと残高が表示された！！。

やったね！。

[exit] 

[adb kill-server]

で切断し、USBケーブルを引っこ抜いて単独で同じようにカード読ませても問題なし！

安心したのもつかの間、今度はSIM接続でWANがちゃんと動かない。

またもやwebを検索した所、設定ミスが判明

【設定】ー【データ使用量】ー【モバイル】ー【モバイルデータ】をON にしないとだめだった。

これってデータ使用量の制限のコマンドなんだから、ここにフラグをもってくる事自体おかしい。
完全にメニューのデザインミスだと思うのだが・・・・・・。
本来は、【ネットワーク】ー【WANを有効】みたいな感じでメニューを作り、そこのサブメニューに通信データ使用量制限みたいなものを設けるのが解りやすいだろう。

前から思っていたが、Androidの設計者はここいらの作りがとても雑だと思う。
たかがスマホだからこれでいいけど、これが自動車だったらと思うとゾッとする。
メニューを作った後は、何にも知らないド素人に説明ゼロの状態で使わせ、もし想定したように使えなかったら、使えるようになるまで改良するのが筋だと思う。
Googleみたいに大儲けしている会社は、余裕でそれができるはずだ。そんなことすらできない会社では、とてもAIなんて信用できない・・・・。

HikariCP経由のPostgresをJettyで使う

自分の中ではDBCP2がコネクションプールの定番だったが、今はHikariCPが鉄板らしい。
そこで、Jettyで使うPostgresq接続のプールをHikariCPで行うの事にしたのだが、かなりハマったのでメモ。

 <New id="hikarids-postgres" class="org.eclipse.jetty.plus.jndi.Resource">
    <Arg>
      <Ref refid="webアプリケーション" />
    </Arg> 
    <Arg>jdbc/hikarids-postgres</Arg>
    <Arg>
      <New class="com.zaxxer.hikari.HikariDataSource">
        <Arg>

<!-- 省略可能
          <New class="com.zaxxer.hikari.HikariConfig">
-->
            <Set name="dataSourceClassName">org.postgresql.ds.PGSimpleDataSource</Set>
            <Set name="minimumIdle">1</Set>
            <Set name="maximumPoolSize">10</Set>
            <Set name="connectionInitSql">select version();</Set>
           
            <Call name="addDataSourceProperty">
              <Arg>user</Arg>
              <Arg>接続ユーザー名</Arg>
            </Call>
            <Call name="addDataSourceProperty">
              <Arg>password</Arg>
              <Arg>接続パスワード</Arg>
            </Call>
            <Call name="addDataSourceProperty">
              <Arg>serverName</Arg>
              <Arg>接続ホスト名（IPアドレスでも可能）</Arg>
            </Call>
            <Call name="addDataSourceProperty">
              <Arg>portNumber</Arg>
              <Arg>接続ポート</Arg>
            </Call>
            <Call name="addDataSourceProperty">
              <Arg>databaseName</Arg>
              <Arg>接続DB名</Arg>
            </Call>




<!-- 省略可能
          </New>

-->

        </Arg>     
      </New>
    </Arg>
  </New>

ここでややこしいのが、postgresの接続情報を指定するのに、HikariDataSourceのインスタンスへ直接指定するのではなく、インスタンス化する引数で使うHikariConfigのaddDataSourcePropertyメソッドを通じて指定している事だ。直接データを指定するメソッドを準備してくれればよいものを、どうしてこんなにまどろっこしい事をしているのか・・・・。
おそらく、db接続に使うアドレス、ユーザー名、パスワード、ポートの指定方法が、いろいろなドライバークラスで統一が取れていないからなんじゃないかと思う。
jdbc:postgresql://ホスト名:port/database名  のような URL形式で接続できたり、バラバラに指定できたりするのが自由に行われているのが原因じゃないだろうか。
JDBCはこのへんを曖昧のまま放置してきたので、いまだにややこしい事が起きている気がする。

省略可能：
HikariDataSourceのコンストラクタにHikariConfigを渡さない場合でも、HikariConfigを継承しているのでaddDataSourcePropertyをCALLしてやることで、接続情報を指定できる。

スマホやタブレットでのバッテリーの選び方

Nexus7のバッテリー交換をやろうと思いバッテリーを探していた所、いろいろ勉強になったのでメモ

ヨドバシと違ってAmazonは玉石混淆、しかもバッテリーなどのパーツに至っては、詐欺すれすれの境界線上でショッピングしなければならない。
その上、発売から3年経過のNexus7のパーツになると、入手困難となってくる。

そこで、Amazon以外のサイトでの販売はないかと検索すると、めぼしいのが出てきた。

怪しげなサイトに警戒しつつ能書きを読んでゆくと、業者の説明にPSEマークを取得しているので安心してくれとある。
そうか、PSEマークついてるのなら、互換製品だとしても安心か・・・・と思い込んでいたのだが、これが大きな間違いだとわかった。

技適マークと違い、丸型のPSEマークにはどこの審査も受けていなくても、自分で検査したということでオレオレ認証できるらしい。
電池などに必要となる菱型のPSEマークの場合は第三者の認証が必要になるが、

このマークのように、認証した機関のロゴがついているようだ。購入対象の電池屋.comの製品にはPSEマークつきとあったので安心して発注しかけたが、慌てて取り消してセーフ！。
もう少しでダマされる所だった・・・・危ない危ない。
よく読んでみると説明している日本語文法も怪しい上、振り込みは日本の銀行だが、ドメインは中国での登録だ！。ヤバイヤバイ。
Glaxy端末の爆発報道から、いかにリチウム電池が危ないかよーーくわかったので、中国の怪しいバッテリーなんか怖くて使えない。

考えて見ると、技適マークなんかよりもバッテリーのPSEマークのほうが重要だ。
電波違反も確かにヤバいが、違反行為が直接怪我に結びつくことはまずない。
ところがバッテリーの場合は、直接に怪我や火事、ひいては乗り物の事故にまでつながってしまう。

こんな状態の製品が、Amazonあたりのいい加減なチェックの元に販売されているのは、どう考えてもおかしい。

経産省は、他のくだらない天下りよりも、こっちの方面で天下って利権作ってくれ！。
しゃくだけど、この分野での利権は、国民のためにもなる。

Apple Thunderbolt - ギガビットEthernetアダプタ は 使えない・・・・

Macbook pro retina 2013 late にLinuxを入れて使っている場合、ネットワーク接続に問題が有ることが判明した。

無線LAN（ Broadcom Corporation BCM4360 802.11ac）のほうは、"wl"ドライバーで問題なく動くが、有線LANとして使うThunderbold接続のApple純正Ethernetアダプタ （Broadcom Corporation NetXtreme BCM57762 Gigabit Ethernet）は”tg3”にバグがあるのか、とても不安定だ。

Broadcomのチップは発熱が少ないと思っていたのだが、外付けのEthernetに関しては、かなり発熱がある上、コネクションがブチ切れるなど、とても使い物にならない。

あまりに酷いので、Androidでも安心して使い回せる、バッファローのLUA3-U2-ATXを入手した。
こいつのチップは、ASIXのax88178で、本家サイトにはLinux用のドライバソースもちゃんとある。
この会社は、こういう細かい所がとても重要だとちゃんと気付いている。

今は、オンボードチップがメインとなってしまったグラボだが、かつてはボード単体での購入が普通で、その際一番重要視されたのがLinuxドライバーの有無だった。
nvidiaは結構Linuxコミュニティーに親和的であったのにたいし、ATIはずっと塩対応だったので、決してATIのボードは買わなかった記憶が有る。

同じような理由から、今でもプリンターはHPを一番の候補とし、決してCannonは選ばない。

こんな事をしていたら、何れBroadcomはadaptecのようになるんじゃないだろうかと感じる。

DAVdroid

Nexus7からLAN内のカレンダーサーバーへの接続に、Caldav Sync Free Betaを使っていたが、突然同期できなくなってしまった。

この前まで表示されていた設定画面が表示できない・・・・・ ということは、Android6には対応しなくなったということか・・・・。有料バージョンがあるのでそっちを使え ということなんだろうが、時々同期が怪しかった事もあり、今ひとつ使う気になれない。

他の同種のアプリを調べた所、DAVdroidというのがあった。
解説サイトには、bikalの人形ロゴも出ている！。  こういう解りやすいアピールに弱いので、こっちで決定！。

料金は僅か300円弱だった。しかも超安定でタスクと連絡表付きで、いろんなCaldavとつながる。
こんなに役立つアプリが300円しかとれなくて、どうでも良いLINEのスタンプは、何千円も課金されている・・・・。
携帯の着メロの頃から思っていたが、明らかにこういう物への世の中の評価はおかしい。

Blogger使ってる奴が言うんじゃねーよ って言われそうだが、Googleに予定表を掴まれるのが嫌な人は結構いるだろうし、VPSも手軽に安く借りられるようになってきてるので、ビジネスライクなスケジュールくらいは自分で管理した方がよいだろう。

DAVdroidは、Android端末では必須アプリだと思う・・・・・・

Nexus7 2013の裏蓋を外す

このブログでも前に取り上げたが、2回の修理を経ても、なんとなくNexus7 2013のタッチディスプレイの感度が悪いと感じていた。

何か対策はないものかと久しぶりに検索してみたところ、とんでもない解決方法が編み出されていた事が判った。（今頃かよ・・・というツッコミは却下）

蓋さえ開けられれば素人でも簡単に出来そうなので挑戦してみた所、効果絶大！。

一番の難関が裏蓋外しだったので、忘れないようにメモを残す事にした。

工具の準備

定番のamazonで検索すると、同じような工具でも、200円〜1000円までいろいろある。
画像を見る限りそれぞれに含まれる工具は同一のものだろうが、価格の開きには身構えてしまう。
例えば、ここ なんだが、僅か150円+送料で入手できるが、こんなんで商売になるのだろうか？
発送がamazonではないので、どうも住所の収集目的で出店しているような気がしてならない。

なんか気持ちが悪いので、昔から馴染みがある、IKESHOPで工具を揃えることにした。

 

手順

Nexus7 2013 LTE の裏蓋を外す際の一番のポイントは、最初にSIMスロットごと外す事だ。
これをやらないと、SIMスロットに裏蓋がひっかかって取り外しができない。

最初に左側の真ん中くらいの位置に、青い工具のヘラを差し込んでとっかかりを開ける。
結構強引にいかないとひらかないので、思い切って行く

工具が刺さったら、工具をずらしながらピックみたいなのを使い、左上に移動しながら、徐々にこじ開けていく。この時絶対に左下に移動してはダメ

上部の部分では、イヤフォン穴を割ってしまう可能性が高くなるので、極めて慎重に開けてゆく。
上部が開いたら、右下に向かって開けていく。
もしうまく開かない場合は、右側に工具を刺して、上に向かって開けてもよい。

左・上・右が全て開いたら、残っている下の部分をこじ開けるのではなく、本体を上に、蓋を下にずらして、蓋と本体を分離するようにする。

これで蓋開けはおしまい。



問題の、タッチディスプレイ問題を解決する為に、バッテリーユニット部分を見てみると、何と！！
ネジがちゃんと最後まで締めてない事が判明した。
二回も修理だしたのに、ネジ止めすらいい加減に修理してたんか！！！。
やっぱり、外国企業のメンテナンスは信用ならんなーーー。
取り敢えず、ネジをきちんと止めてから、紙をセットする。

バッテリーユニットのサイズに切り取った紙を用意して、スティックノリで糊付けした後、逆の手順で蓋を締め、SIMスロットを差し込んで修理完了！


タッチの感度が上がった気がするが、今のシーズンは湿度が高いので今ひとつ実感が薄い。
きっと、乾燥する冬になればもっとよく判ると思うが、その頃にはProject Ara を買ってたりして・・・・。

DBCP2ではまった・・・

DBCP2ではまった。

まさか、設定ファイルの項目名が変更になっているとは思わなかったので、
JNDIに渡すクラス名だけ変更し、dbcpの頃の設定ファイルはそのままで使った所、接続できない・・・・・。

何でエラーなんだ？？？？

ログを見ると、maxActiveとか、ありえねぇーから・・・ みたいな事が書いてある。
DBCP2のサイトには注意書きとは言えないサイズで、ちょこっとだけ触れている。

Users should also be aware that some configuration options (e.g. maxActive to maxTotal) have been renamed to align them with the new names used by Commons Pool 2.

 こういうのは、赤とかで太字表示して欲しいんだよね・・・。もう。

こういうのではまってるのは、自分くらいか？

DBCP2とpostgresとドライバーのバージョン

いつの間にかDBCPは、DBCP2へとバージョンが上がっていた。
そして、各バージョンがサポートするものが微妙に異なるという、わかりにくい状態になっている。

Sunが倒産し、JavaがOracleへドナドナされてからというもの、Javaがわかりにくく進化してきているように思える。

自分の中では、以前はすっきりした言語のイメージがあったJavaが、Java5（Tiger)から導入されたアノテーションの進化と共に、Perlのようなわけがわからない言語に育っている気がしてならない。

関数宣言の上につく、＠の呪文のようなアノテーションがとてもわかりにくい・・・・。
おかげで、ポインタがややこしくて嫌いだったC++の方が、今では理解しやすく使いやすい言語になってしまい、最近ではもっぱらC++ばかり書くようになった。


久々にJDBCを使ったJAASのLoginModuleを作る事になったので、いつものパターンで作り、postgresのバージョンと同じjarを指定して配布し、サーバー起動。


・・・・・・ 何だ！、このエラーの嵐は！  しかもクライアントアプリは接続できないって終了してるし。
コンパイル通ったし、前に同じコードで作ったやつも動いてるから、ありえないから・・・マジで・・・・

困った、何が悪いのかわからんっ！

という事で、困った時は足元からの格言通りに、サーバーアプリケーションのlibフォルダを除いてみると定番のDBCPのjarの名前に違和感のある2の文字が・・・

DBCPのサイトを除いてみるとDBCP2とある。なになに・・・・

 DBCP now comes in three different versions to support different versions of JDBC.
Here is how it works:

    DBCP 2 compiles and runs under Java 7 only (JDBC 4.1)
    DBCP 1.4 compiles and runs under Java 6 only (JDBC 4)
    DBCP 1.3 compiles and runs under Java 1.4-5 only (JDBC 3)

DBCP 2 binaries should be used by applications running under Java 7.

うーーむ・・・・。いつの間にかDBCPは、新しいバージョンが主流になってて、しかもバージョン毎に、JDBCだけでなくJDKのバージョンまで異なった対応になってるのか・・・・知らなかった。

しかも、 DBCP1.4って今まで使ってきた奴は、Java6限定で、JDBCもjdbc4だけしか使えネーんじゃんか・・・！

ええーーっ、jettyとかで、DBCP1.4で、jdk7とJDBC3のドライバーで動かしちゃってるんですけど・・・・(-_-;)

昨年後半は、セキュリティー脆弱性でさんざんJavaが叩かれた記事を目の当たりにしてきたので、さすがにjdkは1.8を使う事にしたのだが、利用する既存DBがPostgres9.1といういぶし銀バージョンの為、ドライバーはずっと[9.1 Build 903] を使ってきた。

DBCP2先輩曰く、

所でオマエ、オレ使うんなら、jdk1.7とjdbc4.1限定な！、それ以外認めないから・・・・・

ガーーン。先輩、そりゃないっすよ・・・・。

jdk==>java8を使って、-version:"1.7.0_80" でもやって使うしかない。

しかし、JDBCはどうにもならんぞ・・・・・困った。と思いながらpostgresのjdbcサイトを覗くと、

This is the current version of the driver. Unless you have unusual requirements (running old applications or JVMs), this is the driver you should be using. It supports Postgresql 7.2 or newer and requires a 1.6 or newer JVM. 

何ですと！

古いJDKバージョンにアプリケーションが縛られるような状態でもない限り、いっちゃん新しいバージョン使えよな。postgres7.2より新しいのは全部サポートしてっから・・・・

だと・・・・？。  ええーーーーっ、 そういう事？。最新バージョンは下位互換性が保持されてるって、全くしらなかった。じゃーー、

JDBC41 Postgresql Driver, Version 9.4-1208

ってのを使えばいいのか・・・・。というわけで、

postgresql-9.4.1208.jre7.jar をダウンロードしてセットし、

postgresql-9.1-903.jdbc3.jar を削除してから、サーバー起動、クライアント認証実施・・・。

さらーーーっと認証終了ですわ。