月別アーカイブ 8月 2018

takahashi 著者:takahashi

PostgreSQLで大文字のカラム名を指定する方法

一番最初に触ったDBがMySQLだったのですが、それに慣れてしまったがゆえに、他のDBエンジンを触った時にその作法の違いに苦労することがあります。

今回、PostgreSQLを使用したシステムの補修を行ったのですが、例えばSelect文を書く時、MySQLを触っていた時の癖で

SELECT * FROM table WHERE column="value";

のように書いていたのですが、PostgreSQLだとエラーになってしまいます。
というのも、PostgreSQLでは “” は文字列を意味するのではなく、カラム名などを大文字を表すときに使うためです。

では文字列を囲うようにするにはどうすればいいかというと

SELECT * FROM table WHERE column='value';

とシングルコートを用いればいいようです。

基本的にSQLを使ったDBでは、SQL文はほぼ同様に使えるのですが、細かい”作法”が結構異なっているものも多いので注意が必要です。

  • この記事いいね! (0)
著者:杉浦

空中写真とオルソ画像

 地図は全ての地点において真上から見たような視点で地形が描かれます。しかし空中からの写真撮影はそうはいきません。撮影を行った一点から放射上に広がり、遠くのものほど傾いて映ります。この傾いた写真を空中写真、地図の様に傾きを直した写真をオルソ画像と呼びます。下の図はオルソ画像について|国土地理院から引用した図です。
 
 図の様に写真の端を中央に寄せて真上から見たときと同じ大きさに収めるわけです。ただの圧縮なので傾きによって映った側面の部分は画像に残ったままです。この手法によって写真が整形されているからこそ、下図の様な地図を重ね合わせを少ない違和感で実現できています。

  • この記事いいね! (0)
村上 著者:村上

【Android】「Cannot add task ‘:processDebugGoogleServices’ as a task with that name already exists.」エラーの対処法

本日遭遇したエラーの対処法です。
状況はというと、Cordovaでアプリを開発中、プラグインの追加・削除のため、どうしてもブラウザやAndroidなどのプラットフォームを削除しなくてはならなくなり、削除 → 再インストールを実行したところ、Androidで上記エラーが発生しました。
なお、build.gradle ファイル内で発生したエラーです。

 

エラー文を色々検索し、ヒットした解決策を試したのですが、状況に一致しなかったり、解決しなかったり…。
で、エラー文に戻って、「already exists(=もう存在している)」とあったので、なら Google Services という名前のものを削除すればいいのか?と安直に試したところ…なんとビンゴでした。

具体的には、下記の記述をコメントアウトし、「Try again」を実行しました。

apply from: "cordova-support-google-services/[プロジェクト名]-build.gradle"

こんなに単純なことだったとは…ちょっと拍子抜けでした。
でも、解決できたので良しとします!

 

以上、Cordovaのプラグインの影響で発生した(と思われる)Android Studio のエラーの対処法でした。
なお、今回のエラーは Firebase関連のプラグインが原因のようでした。
もし同じことにお困りの方は、参考にしていただければ幸いです。

  • この記事いいね! (1)
asaba 著者:asaba

Failed to fetch plugin:ERRの赤文字から逃れた話

前回【androidJava】プラグイン導入できない!?Failed to fetch pluginとは・・・

の記事で、ホラー映画さながらの大量の赤文字エラーが解決できないでいましたが、あっさりと解決することができました。

やり方も非常に簡単で、まずプラットフォームを全て消した後に、その後プラグインも全部rmで削除してしまいます。


cordova prugin rm


cordova platfoms rm

でその後に入れたいプラグインを入力します。

 

cordova prugin add 入れたいプラグイン

でも前回はiosとandroidも消したはず。ただ.ideaとbrowserを消していなかったのですが、全部削除しないとダメだったのか・・・?解決はしましたが腑に落ちない結末でした。
あと一応ソースツリーの作業ツリーのファイルも全て消しておいたほうがいいです。configとかpackageが先祖返りしてpluginなんて知らないってとぼけるかもしれないので・・・


とりあえず今後もしこのようなエラーを見かけたらプラットフォームとプラグインを疑ってみてくださいね。それでは!


 

 

  • この記事いいね! (0)
著者:ym

root zone の KSK rollover

前回、昨年?のKSKロールオーバー騒ぎで事前テストしてあって、問題はなかったはずなのですが、いよいよ1ヶ月に迫るので再テストと思って実行してみると、応答無し。

KSK ロールオーバーのテストで、rs.dns-oarc.net. を使ったテスト方法が乗っているのですが、いろんなサーバで実行したりフルリゾルバDNSを指定してしてやっても応答が帰って来ないのです。

dig +short rs.dns-oarc.net TXT

+short を取り外して実行すると SERVFAIL です。しかしブラウザで同じ DNS (フルリゾルバ) を使用した、例のテストURLは 1-4 は PASS (5はFAIL) を返しています。

dig rs.dns-oarc.net TXT

もう 9?% の範囲は問題ない的な記事を見かけたから rs.dns-oarc.net のテストサーバも終わったのだろうか。

porttest は GREAT では無いが GOOD 。
環境によっては GREAT 。

dig +bufsize=1024 rs.dns-oarc.net TXT
dig tcf.rs.dns-oarc.net TXT

どうなってるんだろ。

  • この記事いいね! (0)
著者:杉浦

文字化け解析に役立つサービスもじばけらったの紹介

 文字化け解読ツール「もじばけらった」は文字化けがどの様な変換で起きているかを試すツールを利用できるwebページです。

 使い方は上画像のまま。入力してばけらったすると下画像の様にタブと文字列が出ます。
  
 内タブの文字コードで書かれた文字列が外タブの文字コードでエンコードされると入力された文字列になると示してくれます。いろいろな文字コードの組み合わせで逆変換を試してくれるわけですね。下画像ならSJISっぽい文字コードで書かれたdummy0日本�がUTF-8として見られた結果、dummy0譌・譛ャ隱が出力されたと予想できるわけです。
 文字化けで情報が落ちたら復元できませんし、多重変換、暗黙的な変換なりなんなりが原因となることもあります。単純に解決することは稀ですが、大体大きなヒントになってくれます。
 このサービスは基本的に入力された文字列をphpのmb_convert_encoding($入力文字列,$外タブの文字コード,$内タブの文字コード);で変換してvar_dump()して出力しています。文字化けは誤った変換によるものでその変換は可逆的です。そのため文字化け問題は問題の再現がそのまま解決につながりやすいです。文字化け問題の解決に詰まった時は、もじばけらったの手法を参考にして問題を再現するのも一つの手です。

  • この記事いいね! (0)
asaba 著者:asaba

【androidJava】続・firebaseを使ったアプリをビルドしたらcould not find any versionで怒られた話

今日は、おとといandroid studioに怒られたエラーcould not find any versionの別の対策について書きます。(トップが象なのはgradle関係なので)

前回、上のエラーに遭遇した時は、「以下のようにbuild.gradle(android側)で、リポジトリを追加するコードを書き加えてあげましょう。」という対策を上げましたが

 maven { url "https://maven.google.com" } 

それでもまだエラーがでてくるよという方のためにもう一つの対策法も載せておきます。

まず、前回と同じandroid側のgradleファイルを開いて、dependencies内のclasspathに着目します。そこに書いてあるbuild.gradle〇.〇.〇という数字がありますが、これはgradleのバージョンを意味しています。つまり、何もいじらない段階でエラーが起きているということは、今使っているgradleのバージョンが古い若しくは存在しないバージョンを使っているために引き起こしていると考えられます。

さて、正常にする方法ですがbuild.gradle〇.〇.〇の上にカーソルを合わせると豆電球アイコンがでます。スクショを取り忘れてしまったので詳細を載せることはできませんが、豆電球の説明に従って適切なバージョンにアップグレードしてください。ちなみにCordovaLib側のバージョンはandroid側と合わせなくてもいいみたいです。

gradleのエラーは一回解決しても次々新しいエラーが出て訳の分からないことになるのであまり触りたくはないのですが、今回のようにバージョンが古かったりプラグインの設定を見直したいという方は慎重にいじってください。一回設定を間違えるとプラットフォームやnode.moduleを一から入れなおしたりと時やたら間を使ってしまうので・・・(汗)

  • この記事いいね! (0)
村上 著者:村上

【Cordova】QRコードリーダーを実装するプラグイン「phonegap-plugin-barcodescanner」

今回はCordovaで開発しているアプリに、QRコードリーダーの機能を実装する方法について。
コードがかなり分かりやすかったのでおすすめのプラグインです。
使用したプラグインは「phonegap-plugin-barcodescanner」。
phonegap という名前が付いていますが、Cordovaでも問題なく使えます。

GitHubはこちらから。

GitHub – phonegap/phonegap-plugin-barcodescanner: cross-platform BarcodeScanner for Cordova / PhoneGap
https://github.com/phonegap/phonegap-plugin-barcodescanner

 

早速実装方法ですが、まず下記のコマンドでプラグインを追加します。

cordova plugin add phonegap-plugin-barcodescanner

プラグインの追加が終ったら、config.xml を確認します。
もし、下記の1行が追加されていなかったら追加してください。

<preference name="android-build-tool" value="gradle" />

また、iOSの場合は、info.plist に 「Privacy – Camera Usage Description」の項目を追加しないと、アプリからカメラが起動できないので、こちらも追加します。
設定はこのくらいです。

あとは、下記のコードを記述するだけです。

cordova.plugins.barcodeScanner.scan(
    function (result) {
        // QRコードの読み込み成功
        // 成功時の処理
        // Result: result.text
        // Format: result.format
        // Cancelled: result.cancelled
    }, 
    function (error) {
        // 読み込み失敗
        // 失敗時の処理
    }
);

上記のコードが実行されると、自動的にカメラを使用するかを尋ねるダイアログが表示され、許可を選択すると、画面内に四角形が表示されているQRコードリーダーが起動します。
で、カメラを適当に作成したQRコードにかざしたところ、無事コード内の情報を取得できました。

ちなみに、試しに作ったQRコードは、本記事のアイキャッチ画像でも使用しています。
なお、取得できるのはこのブログのURL https://cpoint-lab.co.jp/です。
このURLは、上記のコードでは、result.text で取得できます。
適当なコードが見つからない場合は、是非ご利用ください。

 

以上、CordovaアプリでQRコードリーダー機能を実装する方法でした。
最初はカメラを扱うということで、難しいのでは…と思っていましたが、実装が楽なプラグインのおかげでかなり簡単でした!
もし似たようなことを行いたいとお考えでしたら、是非ご参考にしてください。

  • この記事いいね! (0)
村上 著者:村上

【Cordova】iBeaconを扱うための「cordova-plugin-ibeacon」が動作しない時の対処法

先日投稿した、「【Cordova】アプリでiBeaconを扱うための「cordova-plugin-ibeacon」が動作しない【未解決】」という記事の、解決策が見つかりました…!
解決策というより、原因はコードに一部抜けがあったせいなんですけどね!

 

早速ですが、正常に動作したコードはこちら!

    // 位置情報を取得
    cordova.plugins.locationManager.requestWhenInUseAuthorization();
    cordova.plugins.notification.local.registerPermission(function (granted) {
        // console.log('Permission has been granted: ' + granted);
    });

    // delegateの作成と設定
    var delegate = new cordova.plugins.locationManager.Delegate();
    delegate.didDetermineStateForRegion = function(pluginResult) {
        console.log('didDetermineStateForRegion', pluginResult);
    }
    delegate.didStartMonitoringForRegion = function(pluginResult) {
        console.log('didDetermineStateForRegion', pluginResult);
    }
    
    // ビーコンを検知している間呼ばれる
    delegate.didRangeBeaconsInRegion = function(pluginResult) {
        document.getElementById("rangeDiv").value = JSON.stringify(pluginResult);
    }
    
    // ビーコンをキャッチ
    delegate.didEnterRegion = function(pluginResult) {
    }

    // ビーコンの範囲外に移動
    delegate.didExitRegion = function(pluginResult) {
    }

    // delegate の設定
    cordova.plugins.locationManager.setDelegate(delegate);

    // 監視するビーコンの設定
    var uuid = '00000000-1d4e-1001-b000-001c4dbec041';
    var identifier = 'ibeacon';
    var major = 1;
    var minor = 3;
    var beaconRegion = new cordova.plugins.locationManager.BeaconRegion(identifier, uuid, major, minor);
    beaconRegion.notifyEntryStateOnDisplay = true;

    // 監視の開始
    cordova.plugins.locationManager.startRangingBeaconsInRegion(beaconRegion)
        .fail(function(e) { console.log(e); })
        .done();
    cordova.plugins.locationManager.startMonitoringForRegion(beaconRegion)
        .fail(function(e) { console.log(e); })
        .done();

変更点は、49行目の下記の記述を追加した点です。

cordova.plugins.locationManager.startRangingBeaconsInRegion(beaconRegion)
    .fail(function(e) { console.log(e); })
    .done();

様々なサンプルコードを見比べたところ、ここの記述が不足していました。
で、コードを追加したところ、問題なくビーコンの信号を取得できました!
というわけで、ただの私のポカミスだったわけです。
…凡ミスで恥ずかしい限りです。
今後は気を付けなければいけませんね。

 

ということで、以上、iBeaconを扱うための「cordova-plugin-ibeacon」が動作しない時の対処法でした。
可能であれば、きちんと動作するサンプルコードを改変してアプリ開発を行った方が安全かもしれません。

  • この記事いいね! (0)
著者:杉浦

構造化プログラミングのさわり

 構造化プログラミングはエドガー・ダイクストラらによって唱えられたプログラミング手法です。デザインパターン、オブジェクト指向のような近年も使われるプログラミング手法のひとつかふたつ前ぐらいの少し昔の手法です。少し昔といえど構造化プログラミングの発展として近年のプログラミング手法があります。構造化プログラミングは基礎的でわかりやすいです。
 構造化プログラミングは大きなプログラムを書いた時点でプログラムの正しさを証明することを目的としています。ここでいう大きな、とは達成するべき課題や目的が複雑であるということです。複雑すぎるプログラムの挙動を把握することは困難です。
 構造化プログラミングにおいて、プログラムは部品の集合と例えられます。今のプログラミング言語における関数なりクラスなりがこの部品の扱いです。構造化プログラミングでは人間が正しいと確信できる範囲の部品を積み上げていくことによって正しいプログラムを作成します。下はwikipediaから引用した箇条書きです。ここから部品のことをブロックと呼称します。
 

ダイクストラの三つの知性の道具
  1. 数え上げ推論(enumeration):一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業
  2. 数学的帰納法(mathematical induction):while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業
  3. 抽象(abstraction):プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作

 数え上げ推論と数学的帰納法によって正しいとされたプログラムのブロックに名前を付け抽象化する。抽象化されたブロックを用いてまたプログラミングを行い、できあがったプログラムのブロックを数え上げ推論と数学的帰納法によって正しいと証明して、その正しいとされたブロックを抽象化して、…と繰り返して最後に大きなプログラムを完成させます。
 この手法は一つ一つのプログラムのブロックが正しいとわかるぐらい、理解しやすくなければ実現できません。この辺りが今も読みやすいコードの書き方が大事にされる理由の一つではないでしょうか。

  • この記事いいね! (0)