Programmers Office

ぬるさくで学んだ基礎を生かして、アプリを作ってみよう！ ぬるさくの学習はこちらNuxt.js と Python でつくるぬるさく AI アプリ開発入門 参考はこちら【Kaggle初心者入門編】タイタニック号で生き残るのは誰？ Kaggleの説明もこちら Kaggleとは？機械学習初心者が知っておくべき3つの使い方 そしてKaggleの入門用コンペ Titanic: Machine Learning from Disaster https://www.kaggle.com/c/titanic 最初にプロジェクト用のディレクトリ（例：titanic）を作成し、その中にdatasetフォルダを作成して、ダウンロードしたデータを配置。 さらにworkspaceディレクトリも作成。 Anaconda-Navigatorを起動 Notebookを起動 プロジェクト用のディレクトリのworkspaceに移動 New > Python 3 そうすると import pandas as pd import numpy as np train = pd.read_csv("../dataset/train.csv") test = pd.read_csv("../dataset/test.csv") で行ける。 「データセットの欠損の確認」のスクリプトは、そのまま貼り付けるとインデントが効いていないので注意。 「文字の数字への置き換え」のところでエラー発生。 train[“Sex”][train[“Sex”] == “male”] = 0 train[“Sex”][train[“Sex”] == “female”] = 1 train[“Embarked”][train[“Embarked”] == “S” ] = 0 train[“Embarked”][train[“Embarked”] == “C” ] = 1 train["

技術書典6で購入した本2冊目。 これも素晴らしい。#技術書典6 の #ぬるさくAI ですが 14時に完売しました！！ ご購入いただいた皆様、本当にありがとうございました！！！ BOOTHでのpdf販売を同時に開始しましたので ぜひ、#技術書典 にお越しいただけなかった方、ご購入ください！https://t.co/S7fajL0B8o — takayama.k (@pco2699) April 14, 2019 なんとか連休中に平成最初のリリースまで持って行きたかったのですが、色々つまり出してきたので、実際に何かを作ってリリースするところを目指したいと思い、Docker環境構築までで一旦まとめておきたいと思います。 Jupyter Notebook いきなり、あなたの知らない世界で、Jupyter Notebook のインストールから。 こちらなども参考に。 https://techacademy.jp/magazine/17430 まずはAnaconda をインストール。Anaconddaで2.3GBも使うんですね・・・ インストールしたら、 Enviroments > 「analytics」 Notebookをインストールしようとして間違えてJupyterLabをインストールしてしまいました。そうしたらNotebookも勝手に入りました。 3.3.1 データセットを読み込む 第１章、第２章も読み応えありますが、作り始めるのは第３章からになります。 初めてJupyter Notebook を使う身としては、色々不明点を抱えながら進めます。どうやって実行するんだ、というところから始まりますが、Runボタンで実行です。 実行すると、エラー。 ModuleNotFoundError Traceback (most recent call last) <ipython-input-2-aed2979e33dd in <module 1 # 分析に必要なライブラリをインポート —- 2 import pandas as pd 3 import numpy as np 4 5 # データセットを読み込む ModuleNotFoundError: No module named ‘pandas’ 先に

技術書典6で購入した本１冊目。 ガチで役に立つ本でした。 コンテナ時代のWebサービスの作り方 | 楽描商店 https://t.co/xFdOX3orNn 技術書典6で頒布した本をboothにて委託しております。ご活用ください。#booth_pm #技術書典 — とまと（nasum）技術書典え35楽描帳 (@tomato360) April 14, 2019 とりあえず、76/103ページまでやってみました。ここまで行くと、ソースをコミットしたら自動的にサイトに反映される仕組みが動きます。 が、多少悪戦苦闘したところもありますので、その辺をメモ。 リージョン 書籍では、東京リージョン（ap-northeast-1）を使うことになっていますが、元々オハイオを使っていたのでそちらのus-east-2を使うことにしてみました。 すると、 The image id ‘[ami-785c491f]’ does not exist となります。これはリージョンによって異なるので、ami-8b92b4eeに変更します。（参考）https://docs.docker.com/machine/drivers/aws/ Terraform Terraform初体験。インフラをコードで定義するとはこういうことなんだ。 しかし、これも簡単に進ませてはくれません。 Error inspecting states in the “s3” backend: BucketRegionError: incorrect region, the bucket is not in ‘us-east-2’ region status code: 301, request id: , host id: 今回一番ハマったかもしれないのはこのエラー。 例えば、 aws s3 ls なんかを叩くと帰ってくるので、この接続でs3の所定のバケットが見えていないわけでもない。結局、フォルダ全体を一回消して、再度やり直したらOKという最悪パターンでした。 また、実際の発生順序は前後しますが、さらに進んでまたこのエラーが出るようになりましたが、書籍だと、aws_route_table.tf、aws_route_table_association.tfが、間違っているのでgithub（書籍に記載あり）のソースを見て記載しました。 rubyバージョン 元々のローカル環境がruby2.3.7だったのが悪いと思うのですが、最初にそれで進めてしまい、いざbuildが動くと You must use Bundler 2 or greater with this lockfile が出るようになってしまいました。

Xamarinなかなか踏み込んでくれないなと感じたりしています。 Xamarin 最近どうよ？ – Qiita https://qiita.com/amay077/items/399002a02c1abf9d620b こちらの記事は面白く、中で紹介されている、Xamarin.Forms Visualの画像を見ると、「よいのでは！」と思いますが、さてどうなることやら・・・ これに対して、上記記事でも紹介されているGlideが、めちゃくちゃ踏み込んできていて面白い。 Glide https://www.glideapps.com/ ノンコーディング、ノンデザインセンスで、綺麗なアプリがすぐに作れる。本当にすぐに。ただし、データがあれば。私も、常々、コンテンツを持っている人は強いなと思っており、そういう人とコラボして面白いものを作りたいと思っているのですが、まあ普通の人はもしかしたら、簡単にアプリが作れると言っても、響かないのかもしれません。しかし、・・・ オープンデータがある！ オープンデータの定義は ① 営利目的、非営利目的を問わず二次利用可能なルールが適用されたもの ② 機械判読に適したもの ③ 無償で利用できるもの となります。 https://cio.go.jp/policy-opendata カタログサイトも提供されているので、色々な観点で見てみると、興味があるデータもあるのではないでしょうか。それを、アプリを通じて活用できたら面白いのではと思いました。 Glide実践 では、実際のデータを使用して、アプリを作ってみます。 データ登録 今回は、「港区観光施設」データを使用してみます。 http://www.city.minato.tokyo.jp/opendata/kanko/index1.html CSVで提供されているので、ダウンロードします。 ダウンロードしたら、すかさず、Googleドライブにアップします。 アップして、すかさず開き、すかさずGoggleスプレッドシートで開きます。 データ加工 これだけでアプリ作成に行けますが、あえて最初からデータ加工してみます。 「港区観光施設」データをみると、「エリア名称」と「種別」でカテゴリ分けされていることが分かります。アプリでも、この二つのカテゴリで絞り込みできるようにします。 まず、ファイル名は「港区観光施設」とし、元のシートは「施設一覧」に名前を変更します。次に、シートを追加し、シート名を「エリア名称」とし、A1の値も「エリア名称」とします。 次に、A2に「=Unique」と打ち込みますと、入力アシスタンスが起動しますので、クリックし、「施設一覧」シートのB列を選択します。Enterにより、「エリア名称」シートは値がグルーピングされた状態で表示されます。すごい。 （なお、94行目に余計なデータがあることが分かりますので、行削除してしまいます） で、これだと1行目の「エリア名称」も含まれてしまうので、「=UNIQUE(‘施設一覧’!B2:B)」とします。これできれいになります。
同じように、「種別」シートも作成します。 次に、両シートに細工します。「エリア名称」のB列の1行目を「施設=施設一覧:エリア名称:multiple」として、各行をA列を参照するようにします。「種別」シートも同様です。 これで準備完了です。 Glide基本作成 Glideにログインします。 「＋」でアプリ追加を行います。先ほど作成したファイルを指定して、「Select」クリックにより、アプリが生成されます。 基本的にはこれで動くアプリができています。ただし、さすがに、どの項目をどういう配置で表示するかは指定してあげないといけません。 今回のデータだと、施設一覧データの先頭2列が表示されてしまっているので、これを変更します。しかしそれも簡単です。Titleに「名称」、Detailsに「所在地」を指定すると、それっぽくなると思います。 データを1行選択すると、詳細ページに遷移します。 こちらでも、各項目の設定をします。１項目目のSummaryは、「名称」「種別」が良いかなと思うので変更し、「名称」「種別」「緯度」「経度」は不要かと思うので削除します。さらに、右上の「＋」で項目追加ができますので、ここでMapを指定します。Address欄に「所在地」を指定することで自動的に地図が表示されます。 「エリア名称」「種別」は基本項目が１項目しかないので、明細は自動表示で問題なしです。クリックした先の施設一覧情報は、Inline listの項目を調整します。 完成です！ 今回作ったアプリはこちら。 https://minatoku-kanko.glideapp.io/ Glide仕組みのポイント いきなり単純データを指定してアプリを作ってから、シートを直してもReload sheetにより反映されますので、最初はそのようにしてカスタマイズしていくのが面白いと思います。 一番のポイントは、Inline listの作り方ではないかと思います。上ではさらっと書きましたが、Inline listを作るために、シートに細工をします。最初に行った、multipleの指定です。 シートの中に、multipleの指定を行うと、その項目をInline listに指定することができます。 もう少し具体的に書くと、ある詳細画面に１データを表示している際に、その中に、子データを明細表示できるのが、Inline listです。今回の上記アプリでは、エリアの詳細情報（と言っても今回は１項目だけですが）の中に、エリアに紐づく施設を子データとして明細表示している形になっています。子データというからには、キーによる紐付けが必要で、その定義を1行目の項目記述で行なっています。 「施設=施設一覧:エリア名称:multiple」という記述では、子データの情報名が「施設」、その子データがどこに存在するかが「施設一覧」、紐付けキーが「エリア名称」、そして子データとして複数明細存在することを示す「multiple」という構造になっています。 他にも作ってみました。 面白いので量産しています。

Visual Studio 2019がリリースされ、Mac版にも対応されていますので、インストールしてみます。 最初にメッセージが出ますが、インストール中2、３回パスワード入力が必要ですので、完全放置はできませんでした。 インストールしたら、サンプルとして https://docs.microsoft.com/ja-jp/xamarin/cross-platform/samples/ Acquaint ⁨app-acquaint⁩/App⁩/Acquaint.XForms.sln を開きますが、UWPは対応していないというメッセーが出るので、ソリューションからは削除します。 で、左上に「Xcode 10.2でコマンドラインツールがありません」というメッセージが出ているので、これはインストールしてしまいます。 https://developer.apple.com/download/more/ 次に、「アクティブな構成内でプロジェクトがビルドされていません」というメッセージが出て、ビルドが完了しませんが、これは下記が参考になりました。 http://kuxumarin.hatenablog.com/entry/2016/12/01/Xamarin.iOS_%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%A7_%22%E3%82%A2%E3%82%AF%E3%83%86%E3%82%A3%E3%83%96%E3%81%AA%E6%A7%8B%E6%88%90%E5%86%85%E3%81%A7%E3%83%97%E3%83%AD ビルドするとそれでも警告は残っていますが、実行すると、何も設定をしていないのでさすがにデータ保存はできませんが、とりあえず、最初の画面表示はできました。

アドビ、3月1日付けでマルケトとの統合を完了（2019年3月6日） https://www.adobe.com/jp/news-room/news/201903/20190306-adobe-marketo-integration.html 「この度の統合によりデジタルにおける顧客体験において、アドビがもつ分析、コンテンツ管理、パーソナライゼーション、広告、コマースといった様々なソリューションに加え、マルケトのリード管理およびアカウントベースドマーケティング技術を合わせて両社のお客様に提供することが可能になります。」 それに先行して アドビ、Magento Commerceを買収 https://www.adobe.com/jp/news-room/news/201805/20180522-magento-commerce.html Magento Commerce Cloudが組み込まれることにより、コマース機能がAdobe Experience Cloudにシームレスに一体化され、B2BとB2C両方の世界中のお客様に単一のプラットフォームを提供できるようになります。 両製品の位置づけ https://www.adobe.com/jp/what-is-adobe-experience-cloud.html Adobe Experience Cloudという製品群の中で 分析：Adobe Analytics オーディエンスのプロファイル：Adobe Audience Manager ・・・ コマース：Adobe Magento B2Bマーケティング：Marketo そもそも、Experience Cloudの位置づけ Creative Cloud：PhotoshopやIllustrator等の提供　一般的（昔からの）なAdobeのイメージ？ Experience Cloud：単一のクラウド基盤に統合された、「エクスペリエンスのための記録システム」 Document Cloud：Acrobat など　これも昔からのAdobeイメージ すなわち、昔ながらのビジネス領域でもクラウド化を進める中で、クラウド自体を基盤としたビジネスも展開し始めているということのよう。 所感 内容が分かりにくすぎる。 Adobe Analytics？Google Analytics的なことを意図しているのは分かりますが、具体的に何ができて、どういう仕掛けが必要なのか、一般情報から何もわからないのは、導入の検討のしようもないかと思います。 個人的には、ビジネス利用としては、Magento、Marketoがより充実したサポートが得られるようになることを期待しつつ、本当はその一つ手前に、CMSが主戦場としてあるべきで、Adobe Experience Manager Sitesがそこを担っているように思われますが、あまりにも情報不足なので、無料提供含めて利用者層を拡大するのが良いのでは。その際の強みは、デザインツールとの統合で、ビジュアル面に優れたサイト構築ができること、かと思います。 期待してます。

ネタは熱いうちに打たないと、テンションはすぐ下がりますね。 まずは、小ネタで、リッチメニューについて。 リッチメニューとは何かについては、 https://www.google.com/search?q=line+%E3%83%AA%E3%83%83%E3%83%81%E3%83%A1%E3%83%8B%E3%83%A5%E3%83%BC&amp;source=lnms&amp;tbm=isch&amp;sa=X&amp;ved=0ahUKEwjChdXvsazhAhVXyIsBHbDIDCAQ_AUIDigB&amp;biw=1628&amp;bih=1054 こんな感じで画像を見るとよくわかりますね。で、これがあってこそ、ボット作ったな感が出ると思うので、まずはここから始めるのはアリかと思います。実際上も、いきなり何を入力したら良いかわからない、という事態を避けるためには、メニューは有効かと思います。 しかし、絵心がない人が、これをどう作るか、というのは悩みどころです。 しかも、６分割メニューを作るなら、画像を６個用意するのかなと思ったら、大きい画像を用意して、その絵の中で６分割の表現をする、ということで、まずはそもそも、どうやってそんな綺麗に分割するのかというところから始まってしまいました。 しかし、これについては、良い方法を思いつきました。あまり大きい画像では持て余すかと思って、400×270で作りましたが、こちらを見ると、本当は1200×810で作った方が良かったようです。 で、良い方法というのは、Excelで列幅133、高さ135のセルを６個作り、それを塗りつぶし、罫線を白にします。その６マスをコピーして、Wordに画像として貼り付ける！これで、よい感じの雛形ができますので、あとは、そのマス内にイラスト等を貼り付けたり文字を書いたりして、周りを塗りつぶす！ 画像アプリを使いこなせない非デザイナにとってはなかなか良い方法ではないでしょうか。 そしてまた、この作業をするにあたっては、macはきつかったです。標準のプレビューアプリでは塗り潰しができず、PhotoScape Xという無料アプリでも、塗りつぶし機能は有償オプションになっていました。この点、Windowsのペイントなら完璧にタスクをこなしてくれます。 しかも、上記のExcelからWord貼り付け作戦は、Googleスプレッドシートではできず、Excelオンラインでもできませんでした。 まさか、画像作成で、macからWindowsに戻るとは・・・ もう一つ注意点としては、アップロードする画像サイズはぴったりサイズでないと受け付けてくれません。エラーメッセージが、jpgかpngでないとダメです、というようなものなのでわかりにくかったのですが、幅399を400にしたら受け付けてもらえました。 ということで、一応参考画像を下に貼っておきますが、次回作る時は、1200×810で作り直そうと思います。（最初からそれにしておいたらアップロードではまらなかった・・・）

仕事の方の年度末のパワープレーの影響で、こちらはすっかりご無沙汰になりました。 そして、突然チャットボットを作ることを思い立ち、試してみたところこれがなかなか面白い。ということで、いくつか作ってみたいのですが、前半戦を終えたところで、まとめてみたいと思います。 LINE bot　の処理の流れ 作るにあたって、今回いきなり作り始めましたが、ある程度流れがわかっていると、よりスムーズに入れるのでは、ということで、流れの絵を描いてみました。 絵心のなさアピールしてどうするんだという気持ちもありますが・・・ ①普通に、LINEでトークをする場合に、自分が発言入力したら、それはおそらくLINEのDBに保存されて、画面に表示されて、処理終了となると思います。 チャットボットを作る場合は、利用者の入力に対して、Webhookという仕組みを組み込みます。 設定としては、Webhook送信を「利用する」として、そのURLを指定するのみです（けど、URL指定するなら、「利用する」の当たり前じゃない？？最初、URLだけ指定して、呼び出しに失敗して小一時間ほどハマりました）。 ②LINEはWebhook送信先に、入力内容をPOSTします。 ですので、まずPOSTを受けられるサイトを用意する必要があります。 これを、今回は、GAS（Google Apps Script）を使用して立ち上げました。 しかし、立ち上げたという表現は正しくないかもしれません。「立ち上げる」的な行為は何もしてません。ただ、Googleドキュメントの１ページを作るかのように、ファイルを一つ作成し、そこにおもむろにコードを書きます。 function doPost(e) と書いて、ウェブアプリケーションとして公開するのみです。これがサーバーレス・アーキテクチャというものか・・・とちょっと感動しました。 ③GASの中で色々やっても良いのですが、GASから外部サービスを呼んで、Responseを受け取ることができます。多くの場合はこのパターンではないでしょうか。Webhookはhttpsで呼ぶ必要がありますが、GASからの呼び出しはhttpでもよい、という裏技的な使い方も可能です。 ④受け取った情報を加工して、最後は、LINEのMessaging APIを呼び出します。Replyというのが、要は、利用者にとっての、トーク相手の発言になります。この返し方も、単純なテキストメッセージとして返すだけでなく、様々なフォーマットで返すことができる、というところがボットとしてのインターフェースの魅力につながります。 また、②のPostに対するResponsとしてReplyを返すのではなく、独立したAPI呼び出しになっている、というのもなるほどと思いました。例えば、一つの入力に対して、複数のReplyを返すことができる、ということです。※これはできないっぽい。メッセージを配列で返すことはできます。 ⑤最後に、Replyの内容が、画面上に表示されます。 なぜチャットボットを作るのか 正直、これまで、限られた知り合いとの連絡手段として以外にLINEをあまり使ってこなかったこともあり、ボットの何が良いのかわかりませんでした。 しかし、今回作る方から入ってみて、魅力があることも分かりました。 利用者にとってのチャットボットの魅力 一言で言うならば、「入力画面というインターフェースからの解放」とでも言えば良いのでしょうか。画面にいくつか項目があって、それらを入力して情報を得る、というのは、やはり処理する側の都合に合わせたインターフェースではあると思います。より直接的にこれが欲しいと言ってもらう、あるいは、質問に答えてもらいながら欲しいものを認識する、という方法が、自然な気がしました。 開発者にとってのチャットボットの魅力 主題はこちらですが、意外と良いものでした。 (1)フロント側作業の軽減 LINEとして決まっているReplyの返し方に従っている限り、ある程度の見た目の保証が得られる、かつ、フロント側障害が発生しにくい、ということがあるかと思います。もちろん、綺麗にメニューを出そうと思ったらイラストを書く等が必要になってきたりして、フロント側の才能が不要になるわけではありません。しかし、見た目の印象作りにいつも悩まされる身としては、これだけの作業でこの結果が得られるというコスパはかなり高いと感じます。 (2)クロスプラットフォーム開発 今作っているのも、身近な人用のこじんまりとしたアプリですが、その利用者の中でもiPhoneとアンドロイド端末は半々という感触です。すなわち、各OS向けのアプリと作るか、クロスプラットフォーム開発をするしかない、と考えています。 しかし、クロスプラットフォーム開発は、ここでも色々トライしているように、なかなか決定打が現れないというのが現状かと思います。また、それぞれ作ろうと思っても、macアプリを作ろうと思ったらmacが必要、というのもやはり障壁です。 これに対して、LINEのプラットフォーム上で動作するチャットボット方式はそこへの配慮が０で良い、という点で強力です。 (3)インストールへのハードルの低さ 上とも関係しますが、特に、身近な人向けの野良アプリの場合、作ったものをインストールしてもらおうというのも、一苦労があったりします。iPhoneの場合に野良アプリを配布する方法があるのか、分かりません。 アンドロイドの場合も、apkファイルをダウンロードしてもらう方法は提供できたとして、それをインストールしようとしたら警告が出てしまうことを考えると、ちょっと無理だな、と思ってしまいます。 これに対して、チャットボットであれば、LINEで繋がっている人であれば「おすすめ」でその人を指定することですぐに見てもらうことができますし、友達になる前にQRコードを見せて繋がってもらうこともできます。これであれば、安心して利用してもらえるのではないかと感じました。 開発に向けての情報 世間には１時間で開発できる系の情報がたくさんあります。確かに、１時間で動くもの（入力した文字をそのまま応答する、程度ですが）が完成するので、とっかかりやすいのは間違いないです。そこからさらに、６時間くらいかけて、 ・日→中、中→日、日→英、英→日　翻訳 ・リクルートのスタディサプリAPIからの情報検索 ・クックパッドの情報検索 を作りました（クックパッドは丸パクリですが）。 作ったもののそれぞれの解説をしてみたいと思う他にも、今後の開発に向けての情報として、書きたいことが色々出てきました。 ・GASとは。サーバレストは。 ・GAS版JSON処理方法、XMLパース方法、HTMLスクレイピング方法 ・LINEリッチメニューのコツ ・Flex MessageによるリッチUI ・ローソンアプリ（現在のLINEボットの最高峰？）の分析 ボチボチやっていこうかと思います。

WooCommerce・WCFM Marketplaceサイトに、PayPal決済を導入します。 お金の動き WooCommerceとして、こういうのを本当は簡単にまとめて欲しいわけですが・・・まず、購入者がPayPalを使って支払う、この支払われたお金は、どこに行くべきか。 WooCommerceだけで考えるなら、このサイト開設者＝店舗なので、そこに行けば良いわけですが、Marketplaceの場合は、基本的には店舗に行きつつ、システム利用料（コミッション）がサイト開設者に行くべきとなります。 で、最終的にはそうなのですが、では、具体的にPayPalの設定は誰のアカウントで設定すべきなのか。店舗ごとに設定するのは大変ではないですか？と考えると、開設者のアカウントで設定し、一旦開設者に支払われた後、店舗に利用料を差し引いた分が支払われる？ そんなことを考えながら、進めます。 上記の予想から考えると、サイトとしての設定はWooCommerceとしてやるべきだろうということと、WooCommerceの方が情報が多いので、それをやってみましょう。 WooCommerceのPayPal設定 ダッシュボードから、WooCommerce→Settings→Paymentsと進むと、支払い方法を選択する画面になります。 たくさん・・・Paypalは二つ、Stripeはたくさん・・・ さて、PayPalには、PayPalという、いわゆるPayPal Standardと、PayPal Checkoutというものがあります。 この違いは何か。 開発者向けTOP（導入方法・技術情報）-PayPal(ペイパル) https://www.paypal.com/jp/webapps/mpp/developer このページの「簡単決済ボタン」と「API決済」に対応するということですね。 簡単決済は、いったんPayPalサイトに飛んで行って戻ってくるタイプ。 API決済はどこまで裏でできることになるか分かりませんが、「よりセキュリティーが高く、画面遷移が少ないため、成約率のアップが期待でき、カゴ落ち率の減少に貢献します。」とのことです。 PayPal Standard（簡単決済ボタン） とりあえず、簡単そうな方から。 Payment methods画面のPayPalの文字、または右端のSetupボタンから、設定画面に移動します。 「PayPal email」に、PayPalサイトの「Sandbox Accounts」で確認した、BUSINESSのアドレスを登録します。 そして、「PayPal sandbox」にチェックします。 「Receiver email」にもBUSINESSアドレスを登録。 「PayPal identity token」は、PayPal画面で確認。 Sandboxのダッシュボードの右上歯車アイコンで、アカウント設定画面に入ります。 左メニューから「アカウント設定」→「販売ツール」→「ウェブサイトの設定」で、 「ウェブペイメントの設定」という画面に入ります。 ここで、自動復帰：オン、復帰先は、サイトのトップにしてみます、そして、支払いデータ転送：オンにすると、IDトークンが表示されます。 あまり日本語情報ないなと思っていましたが、こちらが参考になりました。 https://e-yota.com/webservice/wooccommerce_paypal_standard_payment/ いったんは、これで動作するのではないか、ということで、試してみます。 商品をカートに入れて、支払い画面に遷移すると、注文者情報入力欄の右側に、下記のようなエリアが現れます。 ・・・おっと、これだと配送方法が決定できず、支払いに進めませんので、先にそちらの設定をします。

次は、WooCommerce・WCFM Marketplace からのPayPal決済連携を試したいと思いますが、その前にPayPal決済環境の準備。 PayPal Sandbox 当然、いきなり決済を開始できるわけではないので、まずはお試しをしたい。 そのために、Sandbox環境が用意されています。 いつも、PayPalにログインするものの、開発者サイトへの入り口に悩んで、結局ググって直接、飛んでいく。 PayPal Developer https://developer.paypal.com/ PayPal、仕組み自体は開発者に優しいと思いますが、Webサイトはあまり優しくない。 PayPal Developerにログインしたら、右上にログイン者の情報が表示されるエリアがあるので、その中のDashboard。 そこから先は、こちらなどを参考に。 https://qiita.com/PPJP/items/6ba65ed21da7fba65586 ポイントとして、gmailのアドレスでは、「＋」記号を使ってエイリアスを自動的に作ってくれるところ。これで、買い手用のアカウントと売り手用のアカウントをそれぞれ作ります。 アカウントを作成したら、Sandboxサイトにログインしてみます。 https://www.sandbox.paypal.com/jp/webapps/mpp/home これも、Sandboxだと分かるようにしてくれれば良いと思うのですが、本番サイトさながらのページ。 URLを確認しながら、ログインし、トップページのダッシュボードを確認します。 私の場合、アカウントは以前作ってあったのですが、どこから情報を確認したらよかったんだっけ、という状態でしたので、その場合は、PayPal Developerにログインし、ダッシュボードでアカウントを確認し、そのアカウントで、Sandboxサイトにログインする、ということになります。 このアカウントを使って、決済連携を試してみます。