Quantcast
Channel: うたブログ〜情報編
Viewing all 44 articles
Browse latest View live
↧

QHM(haik)を使うときのXAMPPインストール上の注意(自分覚え書き)

April 8, 2016, 6:25 am
$
0
0
QHM(haik)を使うときのXAMPPインストール上の注意。


・バージョンはPHPがV5.xのものにする
　QHM haikがV7のPHPに対応しておらず、エラーが発生するので
・Apache～Configでhttpd.conf内のListen 80->81に変更
・PHP V7と両方入れてしまったときの環境移行方法
    ・Wordpressはそれぞれでインストール(フォルダをコピーしても動かない)
    ・xampp\apps\wordpress\htdocs\wp-contents下をコピー(\uploadsだけでも良いかも)
    ・http://localhost:81/dashboard/ から phpMyAdminを開く
        左側からbitnami_wordpressを選び、エクスポートする
            設定はここ参照；ただしこれはバージョンが古いためちょっと違う
            http://websae.net/wordpress-backup-without-plugin-20140924/
                デフォルトから変更する重要なのは以下の項目
                Export method:詳細
                出力をファイルに保存する
                    圧縮：zip
                フォーマット特有のオプション:
                    Export views as tables
                    Export metadata
                追加コマンド：
                    CREATE DATABASE / USE コマンドを追加する以外全て

    新しい方でphpMyAdminからインポート

・Skypeが起動しているとApacheは起動できない


どえらく苦労したので、記録。

追記:
新しいブラウザVivaldi v1.0xではphpMyAdminが開けない。PHPで生成されるHTMLに何かしら問題があるような気がするけど、このあたりは全く解らないので詳細不明。現状、XAMPPはVivaldiでは使いにくいということで。
↧
Search

vivaldiのバグについて

April 28, 2016, 1:44 am
$
0
0
新しいブラウザVivaldiは軽快でなかなか快適なのだけど、私が使うのに１つ致命的な大バグが居る。

「画像をドラッグして入れようとすると落ちる」
動画も同様。

実際にドラッグして入れるときだけでなく、ブラウザの上を通過するだけでも落ちるため、Vivaldiを開きながら他のソフトでドラッグするときには細心の注意が必要になる。

ところが落ちない場合もあっていろいろ調べてみると、Picasaからドラッグして入れるときに落ちると判明。フォルダから直接ファイルをドラッグした時には落ちない。
Picasaからの画像ドラッグはどうもショートカットを渡しているようで、Vivaldiはその扱いにバグが居るという感じ。追加調査の結果、 Picasaを起動している状態ではフォルダからの直ドラッグでも落ちると判明。要するに、Picasaさえ起動していなければ問題ない。

Chrome/Firefox/IEでは発生しない。Mac版で発生するかどうかは不明。

なので、当面の回避策はPicasaを終了してからドラッグすることしかない。

なお、同じ画像閲覧ソフトでもNikon ViewNXやCanon My Image Gardenでは発生しない。ということはPicasaの方が特殊なのかも知れないけど、超有名ソフトだから、対応して欲しいかと。

・・・

このバグさえ直れば、メインのブラウザをこれに変更してもいい位Vivaldiは良い。
劇遅になってしまったChromeや落ちる頻度が高いFirefoxに比べて高速で安定している。
動画再生時に処理負荷が低いのも好印象。Gyao動画見ながら作業していること多いから。
お勧め。

2016/05/06追記：
最新版１.2.470.11では落ちにくくなったような気もするがやはり落ちる。静止画では大丈夫なこともあるが動画をドラッグすると一発。

2016/05/16追記：
最新版の1.2.479.8では確実に落ちるようになった。全く修正される気配がない。他のバグも顕著化している上にAdblock plus導入時の処理速度が極端に遅くなったので、メインブラウザから外すかどうか検討中。
→Adblockはproにすると速度低下が殆ど感じられなくなった。proでも無料なので問題なし。

↧
↧

Bluetoothマウスの動きがおかしい時に確認すること

September 7, 2016, 2:46 pm
$
0
0
ある時からBluetoothマウスの動きがどうにもおかしくなった。
マウスを動かしてもカーソルが1秒位遅れて動くのだ。

マウスが劣化しかからかと思って買い換えた。それでもだめなので、ついには
マシンパワーが足りないからかもしれないと思い、思い切って高速PCにも変えてみた。
すると発生しなくなったので「やっぱり」と思ったが、試験設置から本番設置に変えるまた発生した。
こんな高速マシンでも発生するということは、マシンパワーの問題ではない。
一体何が原因？テストと本番の違いは何？
と考えてふと思いつくことがあった。

Bluetoothドングルとマウスの位置関係だ。
テスト時はドングルをつけていたPC背面を横にしてマウスの真横にあった。
本番は当然背面は後ろに来る。
距離が伸びたのだ。
しかしその差はわずか30センチほど。いくらBluetoothでもそんなに届かないはずはない。

WiFiとUSB3が干渉するのは聞いたことがあるがまさかBluetoothもなのか？
と思って調べたら当たり。

結論と回避方法。

USB3とBluetoothは干渉する。
 これはもう仕方ないので、マウスが効くようにするしかない。

うちのUSB3機器はHDDだけだが、これはWindows上の接続を切っていても、ケーブルが刺さっているだけで影響する。 ケーブルやHDD本体から猛烈に電磁波が出ている模様。
干渉すると、猛烈に到達距離が落ちるみたい。

解決法。
１．Bluetoothドングルとの距離を短くすること。
うちでは背面からUSBハブを伸ばして前面に持ってきて、その中でも一番マウスに近い位置にドングルを刺した。これで減少が解消した。

２．Bluetoothドングルとマウスの間にUSB3機器を置かない。
マウスがPCの右側にあるなら、USB３機器は左側にまとめるなど。
電波は距離の２乗に反比例して減衰するので、距離を伸ばせば伸ばすほど効果があるはず。

Mac Miniのように内蔵Bluetoothでは１は無理なので２にするしかないが、２も５０センチも離せば効果がある。
 （うちのMacMiniはUSB3機器をすべて新PCに行こうし、距離も離れたからか、マウスは効くようになった。）



他に考えられるのは、
１．内蔵Bluetoothの動作を止めて外つけを使う
２．Logicoolの独自無線ドングルを持ったものを使う（これが干渉しないという保証はないけど）
３．諦めて優先マウスにする
である。
マウスやキーボードだけなら２、３も行けるけど、その他のBluetooth機器もある場合はこうは行かない。USB3ケーブルをアルミホイルで巻いてみるとかもあるかもしれない。

いずれにしても根本的対策はハードウエアメーカー、というかUSB3やBluetoothの規格をした連中にお願いするしかないわけで（順番から言えば、後で規格作ったUSB3側に責任がある）、なんとかして欲しいところ。

同様の現象でお困りの方はお試しを。

↧

iOS9/10のAutoresizeバグ

September 7, 2016, 2:46 pm
$
0
0
UI要素にautoresize設定をしていた場合、iOS8まではviewWillAppear時点でリサイズ後のサイズが取得できたけど、iOS9/10では得られなくなってしまった。

はっきり言ってこんなん仕様変更どころか完全にバグ。


回避策としては、１つはその上に乗せるものもすべてAutoresizeで制御するようにするとか、
KVOでframeの値に代入された時点で取り出すとか、viewDidAppearまで全要素をhiddenにしてサイズを取得、計算後にhiddenを解除するとかありそうだけど、うまくいくかどうかはわからない。

今回は、 最初の「上に載せるものすべてにAutoreseizeされるようする」で回避した。
   view.autoresizeMask=super.autoresizeMask;

Autoresizeはもう使うなということかもしれないけど、こっちのほうが圧倒的に楽。
Autolayoutも少しはわかるようになったけど、要素数が増えるともう管理しきれなくなる。
あんなもん設定するくらいなら、すべての座標とサイズをプログラムで書いたほうがマシ。
Appleには気合を入れて、もっとまともなリサイズ手法を考えてほしい。

→viewDidLayoutSubviewsで検知できるという情報もあるが、以下の問題がある。
(1)複数回呼びだされることがある
(2).sizeは確定しているが、.originは未定のまま
なので従来のWillAppearからの単純移動ではうまくいかない。

KVOによる.frame監視も全く同様だった。

autoresizeMaskの設定だけではうまくいかない部分もあり、結局viewDidAppear後に取得し、アニメーションで表示することで見目の問題も回避した。
↧
Viewing all 44 articles
Browse latest View live
Search