Information Technology Tips

Amazon Product Advertising APIがjsonベースの5.0に移行することが発表されました。 Amazonが提供しているSDKを利用していない場合は、APIのリクエストのインターフェースがXMLからJSONに変わるので、コードの書き換えは結構面倒です。 Amazonの公式ページ でもSDKを使用しないバージョンのサンプルコードが公開されていますが、ApacheのHttpComponentsのライブラリとjsonのライブラリが依存関係に含まれていたので、とにかくAPIを動かしてみたい人向けに 標準のJDKだけで動作するサンプルコードを書きました。 (ただし実運用ではJacksonやGSONなど、何らかのjsonライブラリは必須です。) package com.dukesoftware.amazon; import java.io.ByteArrayOutputStream; import java.io.DataOutputStream; import java.io.IOException; import java.io.InputStream; import java.net.HttpURLConnection; import java.net.URL; import java.nio.charset.StandardCharsets; import java.util.Map; import java.util.Map.Entry; import java.util.TreeMap; // Java8で動くように、あえてvarなどのJava8では使えないJava機能は未使用 // スクラッチパッドを使うと便利 // https://webservices.amazon.co.jp/paapi5/scratchpad/ public class AmazonProductAdvertisingApiV5 { public static void main(String[] args) { // request生成部分はJacksonやGSONなどのライブラリを使用するのが現実的 String jsonRequest = "{"

古いJava 3Dのプログラムを動かすために、Java 3Dのインストーラーを探していたところ、OracleのArchiveページからダウンロードできることを発見。 https://www.oracle.com/java/technologies/java-archive-downloads-java-client-downloads.html 2019/09/16現在の情報です。

Web画面上でHTMLを編集するために、Javascript実装のHTMLエディタが必要になることがあると思います(例えばWordpressやBloggerのエディタのようなものです)。 様々なエディタがありますが、 Code Mirror というエディタは高機能で便利です。下記のような機能があります。 100以上の言語をサポート 強力なxmlタグ補完機能 コード折り畳み機能 Vim、Emacsなどと同じキーバインディングのサポート 検索・置換機能 括弧、タグのマッチング機能 たくさんのアドオン

LinuxのコマンドラインからXMLを操作する際には、 XMLStarlet を使うと便利です。 ただし、複雑な処理を適用する場合は、素直にプログラミング言語で提供されているDOMやParserを使う方が良いと思います。 例えば、下記のコマンドを実行すると、特定のxpathにマッチした要素の数を数えることができます。 # selはxml　documentへのクエリや検索を実行するためのオプション # -tはテンプレートを指定するためのオプションで、下記の例では、さらに-vで指定したxpathを実行するように命令しています。 xml sel -t -v &quote;count(/xml/table/row)&quote; data.xml オプションは色々あるので、公式ドキュメントを読んで色々試してみるのが近道かと思います。

Nexus 7 (2012)にAndroid 7.1.2を適用 長年愛用しているNexus 7 (2012)は公式にはAndroid 5.1.1でサポート打ち切られていますが、 調べたところ、下記の記事から有志の作ったAndroid 7.1.2 AOSPを焼けることがわかり早速試してみました。 https://ameblo.jp/nattolecats/entry-12307126801.html Nexus 7 (2012)上でAndroid 7.1.2を通常動作させるところまで行き、満足していました。(動きは比較的軽快でした。)   ところが！  Android 7.1.2 適用前よりも、スリープ時に「Miscellaneous(=雑多)」とい う項目でバッテリがどんどん消費されてしまうという問題が発生し、原因の解明に四苦八苦することになりました orz スリープ時のバッテリ消費の原因 結論から言うと、私の適用したROM ( aosp_grouper-7.1.2-ota-eng-20170811.ds.zip  )のビルドタイプがuserdebugになっていたこと原因でした。 ro.build.type=userdebug どうもデバッグ用の何らかのプロセスが走って、電力を消費してしまうようです。 通常は、 ro.build.type=user です。というわけで、このro.build.typeを書き換えればいいのですが (例えば BuildProp Editor を利用)、build propertyは、root権限がないと書き換えられないため、今度はroot化必須、、、となったところで私は「もういいやwww」となりました。 最終的には、Googleから公式の提供されているFactory Image "nakasi" for Nexus 7 (Wi-Fi)   をGoogle先生の言われたとおり適用して、まっさらな Android 5.1.1状態で使うことにしました。動作がもっさりしていたり、最新のアプリがインストールできなかったり、セキュリティ大丈夫なのか、とかいろいろ問題ありますが、自分はNexus 7を読書用と割り切って使うことにしました。 結局Nexus 7

MySQLのSQL_CALC_FOUND_ROWSを使用する際の無駄なメモリ消費に注意 ページング機能の実装などのために、ヒットした全件数を取得する必要のある場合があるかと思います。 その場合、下記のようにSQL_CALC_FOUND_ROWSを使うと、検索結果に加えて、そのクエリの全ヒット件数が取得できます。 SELECT SQL_CALC_FOUND_ROWS table.column1, table.column2 ...(途中省略)... FROM table WHERE (条件) しかし、SQL_CALC_FOUND_ROWSを使うと、「絞り込んだ結果にヒットする全べての行の結果のセットを作成する」という大きな欠点があります。 これは、LIMIT, OFFSETを指定していても実行されてしまうので、 SELECTで指定するカラム数やデータ量が多い SELECTの結果返ってくる行数が多い 場合、無駄に領域(≒メモリ)を消費してしまうので注意が必要です。 例えば、100万行検索対象としてヒットするクエリの場合、仮にLIMIT 20と指定して最初の20行を取得するようにクエリを書いても、その100万行分の結果セットが作成されてしまうということになります。 対応策 根本的な対応策としては、SQL_CALC_FOUND_ROWSを使わない(結果行数の取得はCOUNTを用いた別クエリで取得する、結果行数をあらかじめサマリーテーブルに保持しておく)ことですが、 SQL_CALC_FOUND_ROWSをどうしても使う必要がある場合は、 SELECT SQL_CALC_FOUND_ROWS primary_id のように最低限のカラムを指定して結果行セットを取得 (LIMIT OFFSET指定前提) 取得したprimary_idを使って必要なデータを取得 して、SQL_CALC_FOUND_ROWSで使用する領域をできるだけ減らすことで、対応するしかないと思います。 世の中ではLIMIT, OFFSETは使わない方がよいとよく書かれていますが、 SQL_CALC_FOUND_ROWSは、書いてしまえばどんなときも検索にヒットする全結果行セットを作成するので、同じくらい使用する際には注意が必要です。

SELECTの結果をUNIONして ORDER BY する際には下記の点に注意する必要があります。 無駄なメモリ消費 ソートにINDEXが利かない (≒CPU負荷増大) 対応策 可能であればPush-down Condition (各サブクエリ内でORDER BY, LIMIT, OFFSETを適用してからUNION, ORDER BYを実行する)を利用することで、 パフォーマンスを改善できる場合があります。 下記に例を示します。 もともとのクエリ SELECT tmp.* FROM ( SELECT tableA.column1, tableA.column2 FROM tableA WHERE (条件) UNION ALL SELECT tableB.column1, tableB.column2 FROM tableB WHERE (条件) ) AS tmp ORDER BY tmp.column1, tmp.column2 LIMIT 100, 20 Push-down Conditionを用いて書き直したクエリ SELECT tmp.* FROM ( SELECT tableA.column1, tableA.column2 FROM tableA WHERE (条件) ORDER BY tableA.column1, tableA.column2 LIMIT 30 # <- 10 (offset) + 20 (limit) UNION ALL SELECT tableB.column1, tableB.column2 FROM tableB WHERE (条件) ORDER BY tableB.column1, tableB.column2 LIMIT 30 # <- 10 (offset) + 20 (limit) ) AS tmp ORDER BY tmp.column1, tmp.column2 LIMIT 10, 20 ただしこのPush-down Conditionの手法も下記の場合は、効果が半減しますので注意が必要です。 OFFSETの値が大きい場合は、結局全結果セットUNIONと変わらない サブクエリ内のソートで、INDEXが効かない場合