2018

Viber初体験

書きたいことは山ほどたまっているのですが、次に進みたい気持ちも抑えられず・・・ 前回まで書いていたMonacaアプリwithWPは、形にすることができました。 諸事情により非公開アプリですが、一つ形をつかむと、それを基礎として発展させるアイデアが出てきますね。 それがきっかけでありがたいお話をいただいたりして、そういう意味でも作ってよかったなと思っています。 その後、アメリカ・中国に行ってきたので、その話もまとめておきたいのですが、全体をまとめようとすると膨大なボリュームになってしまうので、その話も挟みつつ、今やっていることも挟みつつ、小さくテーマ分けしていこうと思います。 今回は小さいネタで、Viber。 今どきは、国内だろうが海外だろうが、知人との通話なんていくらでも手段はあると思います。 一番多用しているのはFBのMessenger。LINEもたまに。 今回、アメリカに行くにあたり、FB以外の経路も用意しておこうということで、WhatsAppとViberをインストールすることにしました。 WhatsAppは知っていました。WhatsAppが世界一のユーザ数という話も聞いたことがありますが、現在もそうでしょうか? それに対して、Viber、まったく知りませんでした。 楽天が買収してたのですね。最近は割とヘビー楽天ユーザですが、それでも気付いていませんでした。 今回、一度、Viberに助けられました(と言いつつ助けられ未遂ですが)。 ニューヨークで、現地夜景ツアーを頼んでいたのですが、時間になってもお迎えが現れません。 今回は通信専用SIMで行っていたので、電話もできません。 しかし、Viberは電話回線への電話もできるのですね。それは有償なのですが、GooglePayと連携してくれて、難しい手続きを経ずに利用することができました。 (ただ、未遂に終わったのは、連絡先の事務所が電話に出てくれなかったということで・・・けど、その後あれこれあって素晴らしい夜景を楽しめたというのはまた別の話) さらにそれよりも衝撃を受けたのが、電子マネー機能を持っているということです。 ちょっと、ここからは現在確認できる情報とは齟齬があるので、勘違いか、別の話と混じっていますが、大筋は下記のとおりです。 今回、中国でWeChatPayを使いたかったので、羽田空港でポケットチェンジで入金をしました。 これは、お金を別の通貨の電子マネーとして入金することができるというものです。 すなわち、日本円を投入して、変換したい通貨を指定して、どの電子マネーに入金するかを指定できるのです。 そこで、中国元を指定して、WeChatPayをしていしたのですが、WeChatPay以外にViberも指定できたのです。 (現在下記情報を見ると、ViberはUSDとEURとなっていますが・・・ https://www.pocket-change.jp/ja/voucher-list/ ) で、要はViberは中国でも広く使われているのか、と思ったのです。 その後中国でViberが使われているような気配はなかったので、本当のところはどうか分かりません。 しかし、少なくともWhatsAppにはそんな機能はないと思いますので、実はMessengerアプリの今後の覇権争いは、まだまだこれからなのでは、と感じました。 (しかし、ネタを寝かしても忘れるばかりでよいことありませんね)

関連記事 MonacaアプリwithWP


CORSを乗り越えて

さくらレンタルサーバの共有SSL(続き) さくらにテストサイトを立てて、データもコピーします。 あまり作りこんでいない段階でしたら、普通に、DB新規作成→WordPressをインストール→データエクスポート・インポートでやっても大した手間ではありません。 そして、共有SSLの設定は簡単です。 https://help.sakura.ad.jp/hc/ja/articles/206054862&amp;#8211;%E5%85%B1%E6%9C%89SSL-%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95 これにより、「the content must be served over HTTPS.」のエラーは解消します。 MonacaアプリがさくらサーバからJSON取得する場合のCORS対応 次は、予想通りではありますが、「No ‘Access-Control-Allow-Origin’ header is present on the requested resource.」エラーになります。 ※ちなみに、この辺のエラーは、Chromeデベロッパーツール(F12キー)で確認します。 個人的には、これの対応についての情報も分かりにくかったです。 これは、ブラウザ側の制約だ、ということで、それを回避するのは、クライアント側アプリだと考えました。 しかし、config.xmlには既にの記述があるので、これで回避できていないとおかしいのでは、とかなり悩みました。 結論としては、データを提供する側で回避用のヘッダを付けます。自分が提供するデータを勝手に取られるのはまずいが、データ提供側で許可しているならブラウザも安心して取得する、という感じでしょうか。 ですので、サーバアプリ側でヘッダを追加します。 PHP・WordPress記述なので、こんな感じです。($wpdb->get_results が好き) $rows = $wpdb->get_results($sql); if ($rows) { $json_data = json_encode($rows); } header(‘Access-Control-Allow-Origin: *’); header( ‘Content-Type: application/json; charset=utf-8’ ); echo $json_data; これにより、CORS制約も回避されました。 Monaca(Vue)でのJSON取得処理 これで、データが取得されましたので、あとは画面で使うように加工します。 ここも、まあまあ苦労しましたが、 var data = []; ・・・ axios.get(‘[https://xxx’)][1] .then(function (response) { for(var i = 0; i < response.

GCEの開発環境にSSL証明書を入れようと思ったが

<環境の復習> サーバサイドの開発をAWS Cloud9で行います。 なるべく無料範囲で、ということで、EC2を使用せず、GCP上のGCEに接続します。 ですので、サーバ側開発環境はGCEに立っています。 クライアント側開発は、クロスプラットフォーム開発を行うためにMonacaを使用しています。 ですので、開発中は、MonacaからGCEに接続して、JSONを取得しよう、と考えています。 本番環境は、さくらレンタルサーバにサーバアプリを構築し、Monacaでビルドしたモバイルアプリから接続します。 ここまで、GCE上でWordPressを動作させており、Monacaでデザインの概要を作成しました。 次は、MonacaからJSON取得をしようとしています。 Let’s Encrypt さて、MonacaからGCEに接続してJSONを取得しようとしたところ、 The page at ‘https://ide.monaca.mobi/’ was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ‘http://xxx/’. This request has been blocked; the content must be served over HTTPS. というエラーになりました。 これは、ここまでの調査の中で予期されたエラーなので、では、SSL証明書を導入しましょう、ということになります。 こちら https://nozomi-hiragi.com/gcd_wp_ssl_support/

を参考に、Let’s Encryptを入れようと思いました。 SSL証明書も無料の時代、すごいなと思います。 ところが。やはり、ところが。 ConfigurationError: Requested name xxx.xxx.xxx.xxx is an IP address. The Let’s Encrypt certificate authority will not issue certificates for a bare IP address.


Monaca Onsen UI V2 Vueで外部JSON取得

フロント側画面デザイン作成 ↓ サーバ側WordPress構築 ↓ ということで、再度フロント側に戻り、WordPressのデータを参照します。 いやー、あきらめそうになりましたが、かろうじて持ちこたえました。 $http.getの使用 サンプルを探し始めてすぐに見つかったのが、こちら。 Monaca Onsen UI V2 Vue Navigation 上でサーバサイドから取得したjsonが画面に反映されない この中で使用されているthis.$http.getを使用したいのですが、そのままこの記述を使わせていただくと、 Cannot read property ‘get’ of undefined となります。このエラーメッセージも分かりにくいですが、ただ、比較的すぐに、this.$httpが参照できていないということが分かります。 では$httpは何なのかというと、これもvue-resoureぽいな、ということが分かり、Axiosにとって代わられそうだということも分かります。 が、これらをどう参照したらよいのかが分からず、苦労しました。 先に結論を書くと、monacaのターミナルで、npm install axiosを叩きます。 Vue.js 単一ファイルコンポーネント 結論にたどり着くまでに時間がかかった一つの理由が、多くのサンプルが、単一ファイルコンポーネントの構成を前提にしていないことです。 未だに理解しきっていませんが、単一ファイルコンポーネントの場合は、srcの中で.vueファイルに記述をしていき、Monacaの場合は、保存すると、Webpackが動いてwwwにファイルが作成される、ということのようです。 ですから、src側に外部ライブラリをセットしなければいけないのでは、と考え、しかし、Monacaで用意されている「JS/CSS コンポーネントの追加と削除」では反映されているように見えないし、と悩みました。 CDNで参照したらどうだろう、なども試しましたがダメでした。 (逆に、CDNで参照する方法は取れないの?という疑問は残ります・・・) また、Monacaのターミナル機能は最近の追加機能だと思いますが、それまではどうしていたの??という疑問も・・・ とりあえずは先に進めるようにはなりましたが、axoss.getでの参照はSSLでの接続が要求されているので、それをどうするか(接続先のWordPressはGCE上に構築しており、無償範囲での利用にトライしているため)、またアプリがMonacaでJSON取得先がGCEの場合に、クロスドメイン制約に引っかかるだろう、など乗り越えるべき壁はまだまだありそうです・・・ 浮気 もうダメだと思って、ちょっと浮気も考えました。クロスプラットフォーム開発の基盤として、まずUnity。 ゲーム以外にでも使えるだろうとは思うのですが、はてさて。。。 次に考えたのはXamarin。iOS用のビルドにMac端末が必要とのことで、もうしばらく様子見。 浮気せずにすんだのは、良かったのかな・・・   速習webpack 速習シリーズ posted with カエレバ 山田祥寛 WINGSプロジェクト 2018-04-27 関連記事 VSUG DAY 2013 Summer とりあえずxamarinチュートリアル中(初心者の超入門編)

GCE(Google Compute Engine)上のMariaDBに外部から接続

GCPのファイアウォール GCEにインストールしたMariaDBに、その中のWordPressから接続できていますが、ここにプラグイン用のテーブルを追加したり、データをいじったりしたい。 その際に、全てコマンドベースでやるのもつらいし、さらにphpMyAdminをインストールするのもはまりそうな匂いがプンプン。 ということで、ローカルのツールから接続することにします。 まずは、GCPのファイアウォールルール追加です。 場所は、VPCネットワークの中にあります。 設定するのは、上りで、tcp:3306を許可します。 しかし、これだけではつながりません。 リスナー追加 netstat -tlpn を叩くと、 Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN – と表示されます。 これだと、ローカルからしか接続できないわけです。 これを変更するためには、bind-addressの記述をコメントアウトする、という情報が見つかります。 問題は、この記述がどこにあるかです。 結論としては、 /etc/mysql/mariadb.conf.d/50-server.cnf にありました。 これを修正して、sudo /etc/init.d/mysql restart すると、 tcp6 0 0 :::3306 :::* LISTEN – となってくれました。 しかし、実はこれでもつながりませんでした。 select user, host from mysql.user;すると +—————+———–+ | user | host | +—————+———–+ | hoge | localhost | | xxxxxxxxxxxxx | localhost |

GCE(Google Compute Engine)へのWordPressインストール(2)

今回でWordPressインストールまでたどり着こう。 参考は、こちら。 https://qiita.com/yuichiyuichi447/items/4bb3b9dbb69ee5a693cf GCEへのApacheインストール これは sudo apt install apache2 だけ。 ただ、この時点でちゃんと動作を確認すべき・・・ GCEへのPHP7インストール sudo apt install -y php php-mysql libapache2-mod-php ここでも、動作確認すべき。 GCEへのWordpressインストール さらに、こちらを参考。 https://qiita.com/seijikohara/items/f34753b2a783e03d7db4 /etc/apache2/apache2.conf へのWPインストール先追記は、あえて自分のHOME配下に変更。 そして、そのディレクトリを作成しておく。 curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar こちらでは、curlを使用。wgetとはあまり差はないのですかね。趣味の範囲? wp core download –locale=ja –path=/var/www/html/wordpress –allow-root を叩くときに、apache2.confで指定したパスに変更。 また、wp-config.phpの修正で、AUTH_KEY等はコピペが必要です。 この際、AWS Cloud9でviに張り付ける場合は、右クリックコピーではダメで、必ずCtrl-C Ctrl-Vです。 また、いつも忘れますが、viで複数行削除は、 削除範囲の開始行で「ms」 削除範囲の終了行で「me」 「:’s,’ed」と入力し、Enter です。 さて、これで動くと思いきや、そうは問屋が卸さないのがいつものこと。 まず、手順を二つ参照したために、そもそもWP用のDBを作る作業が抜けていました。 これは CREATE DATABASE xxx DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; GRANT ALL ON xxx.* TO ‘xxx’@’localhost’; だけしておけばOK。 しかし、wp option get homeを叩くと

GCE(Google Compute Engine)へのWordPressインストール(1)

さて、環境を定めたら、WordPressをインストールします。 Cloud Launcherではない GCP・WordPressで検索すると、コンソールのCloud Launcherからインストールする方法が多数ヒットすると思います。 確かに、メニューから選択して簡単にインストールできそうです。

この流れは魅力的。 しかし、これは、WordPress用にインスタンスを立ち上げるサービスになります。 そうすると、結局二つ目のインスタンスになってしまい、Always Freeから外れてしまいます。 今回やりたいのは、既存のGCEインスタンスにWPをインストールするということです。 (完全に言葉が間違っていたので追記) GCP(Google Cloud Platform)はGoogleのクラウドの状のサービス諸々ですね。 ですから、GCP・WordPressで検索すれば当然GCP上にWordPressのサービスを立ち上げる方法がヒットするでしょう。 GCE(Google Compute Engine)は、GCPのサービスの中の一つで、IaaS環境を提供してくれているというものです。今やろうとしているのは、そのGCE環境の中にWordPressをインストールする、ということなので、GCE・WordPressで検索すべきです。そうすると、もう少し違う情報も出てきます。 GCEへのMySQLインストール さて、WordPressをインストールするとなると、必要なのがMySQLです。 方法としては、外部に接続する方法も「あり」かとは思います。 元々さくらレンタルサーバに環境作ろうとしたくらいですので、さくらのDBに繋ぎに行ってもよいわけです。 しかし、ここは、怖いもの見たさで、GCE内にMySQLもインストールします。 そして、ここでも、GCPコンソールから「SQL」という魅力的なアイコンが見えます。 これをクリックすると、簡単にMySQLがインストールできそうです。

しかし、これも、データベース用のインスタンス立ち上げサービスです。 あくまでも、既存のインスタンス内にインストールしたいので、これは使用しません。 MariaDB そこで、一番参考になりそうなのがこちら。 https://qiita.com/mekabuko/items/d0ef4492f60e40f84f84 そして、MariaDBという名前が気になりつつ、MySQL入っていないかなと思って、mysqlを叩いてみました。 $ mysql The program ‘mysql’ can be found in the following packages: mysql-client-core-5.7 mariadb-client-core-10.0 Ask your administrator to install one of them 出た、mariadb。MariaDBって何? 基本情報はググれば分かるとして、最近は利用が伸びていて、PL/SQLに対応し始めた、というのが趣深いですね。 ということで、Mariaをインストールすることにします。 上記では、yumでインストールしていますが、こちらの環境はUbuntuなので、sudo apt-get install mariadb-server。 インストール成功しましたが、こちらと同じ状態になっています。 https://jyn.jp/ubuntu-16-04-mariadb-password-bug/ 書いていただいている対応により、接続できるようになりました。  いったん休憩にします。


AWS Cloud9からさくらレンタルサーバはあきらめた

画面デザインはそれっぽくなってきたので、いったんバックエンドに入ろうと思います。 そして、最初の宣言(Monacaでハイブリッドモバイルアプリ開発)通り、AWS Cloud9+さくらレンタルサーバで作ろうと思いました。 が、結論としては、諦めました。以下、できる方法をお探しの方には、あまりお役に立てません。 さくらレンタルサーバへのSSH公開鍵接続 これに関しては、割と情報はそろっていると思います。肝は、各フォルダへのパーミッション設定のようです。 今回、これに成功したかは不明です。

この画面で「AWS Cloud9 couldn’t connect to SSH server」エラーが出続けました。 このメッセージからはSSHでの接続に失敗しているのではと思い、ずっと調べていました。 こちらの情報は良いと思いました。 https://qiita.com/fukusuke/items/6eb9f8593a296a95798c しかし、これはさくらレンタルサーバでは、root権限がなく、自分のHOME配下外のファイルの参照も厳しいです。 で、ふと思いました。Cloud9はNode.jsが必須だったと。それが原因でこのメッセージなのではないか。 さくらレンタルサーバへのNode.jsインストールは不可 ということで、Node.jsインストールを試みますが、これまた、いろいろ情報がありつつも、難しいという結果。 gmakeで失敗したのは、 logging.cc:(.text._ZN2v84base13DumpBacktraceEv+0x24): undefined reference to backtrace’ logging.cc:(.text._ZN2v84base13DumpBacktraceEv+0x31): undefined reference to backtrace_symbols’ というものですが、最終的には、そもそもインストール禁止だということで納得しました。 そもそも、レンタルサーバは複数のユーザが同じサーバーを共有するのであり、他の利用者に迷惑をかけるような利用は不可です。 正直、レンタルサーバというものを、ちゃんとイメージできていなかったのですが、今回 ls /homeをしてそういうことか、と理解しました。 そうであれば、下記のような禁止事項も納得です。 https://www.sakura.ne.jp/terms.html ・・・daemonとしてサーバーに常駐するプログラムの実行 ということで、さくらへの接続は止めて、今回もGCPで開発環境を構築することにしました。 AWS Cloud9からGCE(Google Compute Engine)への二つ目の接続 さて、すでに開発環境を作ってあるGCP(Google Cloud Platform)のGCE(Google Compute Engine)ですが、せっかくなので、別の環境を作ろうと思いました。 バイブルは、こちら。 https://qiita.com/j-un/items/f5d72d21f67d384d3c84 プロジェクトとして今回用のプロジェクトを作り、インスタンスを作ろうとします。 で、設定を選んでいくと、料金表示がされます。・・・料金。 無料で利用できるということでGCPを選んでいるので、無料の条件を再確認すると、 https://cloud.google.com/free/ 1 f1-micro インスタンス(1 か月あたり、米国リージョンのみ)です。 ということで、既存のインスタンスに接続することにします。 初回作成時に失敗したと思いましたが、Cloud9環境を作るディレクトリは指定できます。 前回は自分のHOMEを指定する形になってしまいましたが、今回は、その下にディレクトリを作って、そちらを指定しました。 ということで、ようやく、バックエンド側開発に入ります。


MonacaでのOnsen UI V2 Vue Tabbar

まず、Monacaで画面デザインを作っています。 新規プロジェクトでは、「Onsen UI V2 Vue Tabbar」を選択します。

しかし、各種サンプルを見ながらなんとかなるかなと思いいつつ、なかなかしんどいですね。 この構成の場合、何かを調べようと思ったら、Monacaという基盤の話なのか、Onsen UIというデザインフレームワークの話なのか、Vueという画面制御フレームワークの話なのか、を切り分けながらそれぞれのマニュアルなり、情報なりを調べる必要があるわけです。 で、いきなり、はまったのが、画面上部のツールバーに画像を表示したいな、と。 そこで考えるべきは、画像をどこに置くのか、どういうパスを書けば参照してくれるのか、普通にimgタグを使うべきなのか、他に作法があるのか、等ですが、それぞれの守備範囲がいまいち理解できずに、調べようがないなと思うわけです。 結論としては、サンプルとして公開されているポケモンアプリ(https://docs.monaca.io/ja/sampleapp/samples/)で、画像の置き場はsrc/publicか、と理解し、あとはimgタグでやってみて、うまくいっているからよいか、みたいな感じです。 もう一つの例としては、画面を黒系統にしたいなと思い、Onsen UIのテーマローラー(https://onsen.io/theme-roller/)というのでDark themeといのがあるのが分かったのですが、それの適用方法が分からない。見てるとテーマローラーで生成したファイル群をダウンロードして、配置して、という方法が出てきますが、細かくカスタマイズしたいならそうかもしれませんが、単にテーマを適用したいだけなんだよ、ということでもう少し調べると、onsen-css-components.cssをonsen-css-components-dark-theme.cssに書き換えればよい、という情報が見つかります。 これはどこに書いてあるのだ、というところから始まりますが、それは検索して、今回の構成の場合はmain.jsに書いてあることが分かります。cssの読み込みをjsでやる、というところで既に古い頭にはつらいのですが、そういうものです。 ところが、このように書き換えてみても反映されない。むむ、と思い、もう少し調べると、dark-onsen-css-components.cssだよ、という情報が見つかり、これでOK。 しかし、なかなか辿り着かないよ、と思いつつ、やっていくうちに馴染むだろうと思い込んで、先に進みます。 React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発 原 一浩,taisa,小松 大輔,永井 孝,池内 孝啓,新井 正貴,橋本 安司,日野 洋一郎 技術評論社 2018-05-09 <div class="kaerebalink-salesranking" style="margin-bottom: 5px;"> 売り上げランキング : 8419 </div> <table style="border: currentcolor; margin-top: 10px;"> <tr> <td style="border: currentcolor; text-align: left;"> </td> <td style="border: currentcolor; padding-left: 10px; font-size: x-small; vertical-align: bottom;"> by <a href="https://kaereba.


Monacaでハイブリッドモバイルアプリ開発

Monaca再開 今回、とあるアプリを作ろうと思い立ち、以前ちょっと遊んでいたMonacaを改めて使ってみたいと思います。 その間色々進歩していると思うので、割と一から勉強の部分も多々ありますが、地道に。 作ろうとしているものの構成は下記の通り。 システム構成 フロントエンド Monaca Onsen UI V2 Vue Navigation https://press.monaca.io/atsushi/2533 Vueを使ってみたいと思ってはいたのですが、この記事に後押しされました。 あまり複雑な画面にはならないと思いますが、その分遊べるところは遊ぼうという感じ。 バックエンド WordPress(REST API) 依然作ったWebアプリは、WordPressの豊富なテンプレートを生かしたこ洒落たUIにしたいという目的で、WordPressのプラグインという形でアプリを作りました。 ところが、WordPressプラグインをゴリゴリ書いていると、UI側のメリットよりも、開発フレームワークとして使いやすいと思うようになりました。 その意味で、WordPressを使い、ユーザ管理、コンテンツ管理、データIOを行って、フロントエンドにはREST APIで返す、という方法をとってみたいと思います。 プラグインの作成 – WordPress Codex 日本語版 開発環境 Cloud9+さくらレンタルサーバ 並行して行っている、Code4Startupの開発環境は、Cloud9+GCE(Google Compute Engine)ですが、ちょっと環境構築がしんどかった https://www.programmers-office.ml/2018/05/03/code4startup-%ef%bd%9e-ubereats%e3%82%92%e4%bd%9c%e3%82%8d%e3%81%86-%ef%bd%9e-python-django%e7%92%b0%e5%a2%83/ ので、今回は、せっかく契約していることもあり、さくらレンタルサーバを使いたいと思います。 バックエンドのWordPressもさくらに立てるので、開発ソースと運用環境が両方さくらにあることのメリットが何かあるかも、探ってみたいと思います。 というわけで、今後に乞うご期待!