https://cloud.google.com/endpoints/?hl=ja
CloudEndpointsを使うことで簡単にGAE（GoogleAppEngine）にAPIサーバを作ることが出来る。
Extensible Service Proxyとうなんかすごいやつが、認証やモニタリング、ロギングなどをやってくれ、AppEngineの画面やEndpointの画面でいろいろ見れる
スタンダード環境とフレキシブル環境があり、スタンダードはJavaとPython2.7
フレキシブルは、Go, PHP, node.js, ruby Python3, .NET等がある（β）
ざっくり説明
Swagger（OpenAPI）ベースのAPI定義をCloudEndpointにデプロイ（上の図だとGoogleServiceManagementって部分）して、
それに対応したサーバーサイドを書き、GAEにデプロイする（上の図のAPIContainer）感じになる。
GAEにデプロイするサーバサイドのフレームワークは、PythonだとFlaskとか、PubyだとSinatraとか、NodeだとExpressとかになる。
サンプルコードはチュートリアルからDL出来るので、動かすには困らないし、そのまま拡張しちゃえばいい。
APIキーはGCPのコンソールで発行できる。
しかし、APIキーだけでは認証が弱いので、組み合わせて認証を利用できる
それが
JWT(json web token) ・・・ アプリケーション同士の認証に有効
GoogleIDAuth、FirebaseAuth、Auth0 ・・・ ユーザの認証に有効
となっている。
JWTもまた、GCPコンソールから発行可能なので、キーの発行にコマンドなども必要ないし、管理もGCP上で出来る
認証はAPIキーと、上記２つのどちらかを組み合わせてやる形になる。
この２つの組み合わせが正しくなければ動かない、というふうに作る。
ここまでこなせば、あとはSwaggerのルールにそいながら設定し、実装していけばできていくんだと思う。
Endpointが問題なく動作すれば、モニタリング画面が自動でできる
APIの仕様書もできる
やってて詰まったポイント
プロジェクト外のCloudSQLにつなごうとする場合
IAMの設定
つなぎに行くがわのCloudSQL APIの有効化
が必要となる。
前者は別プロジェクトにアクセスしに行くためににAppEngineのIDを通しておく、ということ
後者はCloudSqlProxyをうごかすためにある
参考：https://cloud.google.com/sql/docs/app-engine-connect?hl=ja
あと、Swaggerをある程度わかったほうがいい。全く知らずに取り組んで少し困った。
チュートリアルはこちら
https://cloud.google.com/endpoints/docs/openapi/tutorials?hl=ja
沿っていけば動く元は作れるはず。別プロジェクトのCloudSQLにつなぐなら前項 を気をつけること
ある日突然、ボットサーバーとして使っていたBluemixのNode-RED starterのサーバーが動かなくなりました。
表示は「未実行」ログには「異常な終了」となっており、いまいち原因がつかめず…。
再起動してみても、同じく異常終了して未実行のまま動作しない。
ということで、IBMCloudの「開始」に書いてあるコマンドライン操作から、ファイルをアップし直してみると解消しました。
一体何が問題だったのか…謎は深まりますが、とりあえずこれで問題なく動作します。
なんなんだ一体…。
pip でインストールしても、numpyがなんとかのエラーが出てインポートすらままならない。
以下を動かすといける
この記事を元に、ノードを作ってったんだけど、ちゃんと作るぞー！と思って色々やってると、ちょっとハマった部分があったのでメモしておこうと思う。
ちなみに今回、LINE BOTを動かすためのノードを作りました。よかったら使ってね。
https://flows.nodered.org/node/node-red-contrib-linebot
ノードを作ってノード配置を完了した後に、名前の変更をしようとするとエラーになる問題
とりあえずノードを作ったあとに「あ、ノード名コレじゃないわ」ってなってから名前を変え、Node-REDを再起動すると「Waiting for missing types to be registered:」と出てきてうまく反映されない事がある。
これを解消するには、~/.node-red/の中にある xxxxxxx.local.jsonを消すと反映される。但し、ローカルに配置したノードは消えるので、JSONでバックアップをとっておくことをおすすめします。
ウェブサービスを作ることになって、さて何を使おうかと考えて、最終的にdjangoを使ってみよう、ということにした。
なぜdjangoにしたかというと、キャリアとしてPythonを知っていることが今後重要になると感じたから。PythonはWeb、ロボット、機械学習、スタンドアロン、なんにでも使えるしPython3を使うのにもいい感じになってきているらしいので。
とりあえず最新版の1.11.x系を触った。
djangoの特徴
MVT
MVT（Model, View, Template）になっている。言葉が違うだけでだいたいMVCと同じ。
Mは同じくModelだけど、ViewはMVCで言うControllerの役目。TemplateがMVCのViewを担う感じ。
ある程度の規約はあるが、比較的自由に書ける。Templateの命名ルールもデフォルト値はあるが簡単に書き換えも可能。しかし規約どおりに作るとコードがどんどん減っていく作りになっている。
form・modelクラス
modelクラスはDBとのつなぎ役をやってくれるわけだけど、formクラスはウェブフォームを定義するクラス。テンプレートで使用するフォームを定義し、テンプレートの読み込ませるとその定義どおりのフォームを自動生成してくれる。
そしてそのformクラスとmodelクラスを組み合わせた、ModelFormというクラスが有り、これを定義すると、モデルとフォームのヒモ付が完了したフォームが自動生成される。
汎用ビュークラス（generic view）
よく使う機能をまるっと集めたクラス。
各CRUDやList、Detail、Redirectなどよく使う機能をお手軽に生成できる。
これを定義する時に、先に紹介したFormやModelを変数に入れるだけで画面ができてしまう。とても簡略的に書くと
class xxxcreateview(CreateView) :
model = XXXX
form = XXXX
template = XXXX
こんなかんじ。手っ取り早く機能だけをズバーっと作りたいときにとても便利。
adminページ
DBをコントロールすることの出来る管理ページが自動生成される。
開発用にDBいじりたいわーとか、テスト用のデータ作りたいわーなんて言う時に便利。
テスターの人に「こういうデータ作って」なんて言われることが減ります。ユーザ発行して作ってもらえば良いんだし。
python manager.py runserver
開発用サーバ立ち上げコマンド。このコマンドを実行すると開発用サーバが立ち上がり、プレビューが可能になる。このコマンドの場合、コードが一部変更されると自動的にサーバが再起動するので、確認が楽。
ちなみに、python manage.pyにはいろんなコマンドがあり、マイグレーションやアプリケーションの作成なども含まれる。
djangoのやりにくさ
利用実績＆最新バージョンの日本語情報は少ない
採用しているサービスが少ないがゆえの宿命だと思う。機械学習が流行ってるから、ぼちぼちdjango使ってみたよーって人は増えてくると思うけど、やっぱり情報が少ない。書籍もほぼ見かけない。公式ドキュメントとstackoverflowと友だちになろう。
プロジェクトの構造どうするのが最適なんだろう？
django-admin のコマンドでプロジェクト生成すると、なーんか気持ちの良くない構造が最初に生成される。VisualStudioでDjangoのプロジェクトを生成するとまた違うプロジェクト構造が生まれてくる。どれがベストプラクティスなん？っていうのも明確にないし、公式が発行しているプロジェクト構造もなんかなーという感じ。ここは模索していくことになるだろう。
エディタ
多分pycharmが最強なんだろうけど、高いし、visual studio codeで書いてるけどいまいち補完が役に立たなかったりする。インポートとかも結構めんどくさかったりもするので、そのへん、いい感じのないのかなー。とおもうと pycharmなんだよなー…。という感じに。
VisualStudioはどうなんだろう。使ってみなければ。
ライブラリ
PHPとかRailsとかに比べればライブラリの数は少ないと思う。なければ作る！の気概がある程度必要。
まとめ
概ね気に入ってます。
初めて触ったWebフレームワークはRailsだったけど、正直肌に合わなかった。理由は使い方以前に規約が多すぎて覚えらんなかったから。djangoは規約はあれどもそこまで強いものではないし、書きやすい。
特に汎用ビューの使い方がわかってくると、どんどん機能を作っていけるようになるから学んでいて楽しいしね。
次からは使い方周りとかをまとめていこうと思います。
（Node-REDアドベントカレンダー 12/6分）
この前、iOSコンソーシアムという集まりのハッカソンに参加してきました。
そこで、雰囲気メガネをビーコンとiOSを組み合わせたものを作ったのですが、その中でふと「サーバーサイドってまともにやったこと無いし、やってみようかな」と思って「サーバーサイドやりまーす」と手を挙げ、APIを作ってみることにしました。
そのイベントの中で「Node-RED」の説明があり、同じチーム人から「簡単にAPI作れるよ」と言われて「簡単ならそれを使うに決まってんじゃん！」とそれを使うことにしました。
そこでNode-REDの説明をして、「どこで困ったか」という点と「ここが良かった」という点、そして「ここがこうなるといいのになー」という点をまとめて書こうと思います。
そもそもNode-REDってなんだ？
Node-REDは、IBMのBluemixで使えるフロー式のロジック作成ツールのようなもので、ノードを繋いでロジックを作り、コードを書かなくてもそこそこ動くものが作れちゃうツールです。
↓こんなの
サーバーサイドのサの字くらいは知ってる、っていう僕でもなんとなーくで使えるツールです。
以前UnrealEngine4のBluePrintを使っていたので、なんとなーく使い方はわかる感じでした。
APIをどんな風に作るのか？
上の絵で説明すると、左上に[get]/user_new ってのがありますが、あんな風にアクセスのURLを指定して、そこにアクセスがあったらどのように動作させるか？というのを、ノードで処理を繋いでいくという感じです。
使ってみてどう思ったか？
困った所
Cloudantを使うとAPIネタがぐっと減る
データベースを、とりあえずそこにあったCloudantを使いました。そしてNode-REDのAPIについて調べていくと、大体がMySQLを使ってるんですよね。「CloudantってJsonで保存してくれるんでしょ？だったらそれに突っ込めばいいや」ってかんじでCloudantを使ったんですが、もうちょっと考えるべきだったかな、と思いました。
JSを書いた場合、どこでデバッグすればいいの？
中身はnode.jsなので、コードはJSで書くわけですが、そうすると「あれ？このオブジェクトの構造みたいけどどうしたら良いんだ？」とか「ここのロジックのconsole.logとかどうやって見るの？」とか分からなくって、でもハッカソンだから時間がなくて、とりあえずエイヤーで動かしたんですが、実際の所どうするのが効率的なのか分からなかった。
フォーム送信した後の送信完了画面の出し方
ある程度の最低限機能ができて、完了画面くらい出すかー、と思ってノードを繋いでたら思った以上にできなくって、チューターの人に聞いてもわかんなくて、、と結構時間を食った。
結局、ノードをつなぐポイントが誤っていた、というのが原因だったんだけど、ノードを繋いでいても実行されない、ということが起こるとは思わなくて混乱した。
ちなみに、コレだと動いて
コレだと動かなかった
クエリのあとにDoneをやろうとすると動作しないんです「クエリ完了したからDone出すだろ！」ってイメージだったんだけど、その常識は通じなかった。
良かった所
楽！
環境つくって、コードの種類を覚えて、書き方覚えて…と考える必要なく、手順を作っていけばとりあえずはなんとかなるのが良いところ。
最初のその学習ハードルを超えて、とりあえずサクッと動かせるのは「作りたい」の気持ちを満たせるという点でとても良い。
先の興味へつながる
ただ、動かしていると「ここでエラーが出た場合は分岐したくて」とかの気持ちが出てくる。
頭のなかで「ここでswitchなりifが使えれば…」と思うけど、それってどう作るんだ？そもそもエラーコードはどう返ってくる？？とかその辺が想像がつきにくくなっている。
それ故に「やっぱちゃんとコードで書けるようになりたい」という、知る動機付けにもなるなーと感じた。
これらをNode-RED上で実装できないのは僕がNode-REDのことをちゃんと知らないからかもしれないけど「全部コレでいいや」にならない分、良い影響を持っていると思う。
コピペしやすい
UnrealEngine4を使っていた頃は、ウェブ上で実装方法を調べても、そのノード構成をコピペで持ってくることは不可能でした（今はどうか知らないけど）。
それに対してNode-REDはノードの配置や内容をJsonデータをエクスポート・インポートが可能になっていることから、とても他の人のノードを参考にしやすい。これは良い。
こう改善されるといいなー
JSの実行コンソールがほしい
上でも書いたけど、js部分の動作が見えないから確認できるようになって欲しい
HTML部分でもifとかforとか使いたい
せっかく変数を受け取れるんだから、それを利用してhtmlの表示の制御がやりたい。手軽に。
チューターの人に聞いたら「JSでなんとかするしか無い」って言われて「えー」って思った。
Macの場合、カーソルがずれてて使いにくい
使った人みんな思っただろうけど、これほんと困る。
まとめ
学びはじめのハードルを低く、手軽に実装できるところはとっても良いと思います。
これって最終的に何を目指すものなんだろ？プロトタイピングツール？サービス実装までのレベルを目指すものなのかな？それによって今後の期待も変わるけど、モックを作るとか、とりあえず見せるものを作るのにいいなーって思います。
2007年から登録していたニコニコプレミアムを解約した。
僕はニコニコは見る専なんだけど、理由はあんまり見てて面白くなくなってきたなーとぼんやり思ったからだ。
そこで、ニコニコプレミアムを解約した。
そして解約して2週間くらいは経ったけど、解約してからかなり動画を見る数が減った。
理由のひとつとして、
「動画を見るのがさっぱり快適ではない」
というのがある。
プレミアムじゃないとニコニコ動画は
・シーク出来ない
・回線速度が遅い
という利用制限が発生するんだけど、
その「シーク出来ない」がクッッッッッソすぎる。
前まではそれなりに面白くない動画でも、シークさせながら最後までなんとなーく見ていたんだけど、プレミアムじゃなくなりそれが出来ないとなると、つまんなくなってきたらソッコーで動画を閉じる、ということが起きる。
そしてそれを繰り返していると、気づくのが
「ほんとに面白いと思ってるモノしか見なくなる」ってことが起きる。
快適じゃないから「とりあえず見てみるかー」が発生しないんですね。
おかげでぼんやりなんとなく動画を見る時間が減り、
何か行動する時間が増え、
部屋を掃除し、
ご飯を作り、
洗濯をし、
出かけて、
本を読むようになった。
あれ？
動画見てた時間ってほんとに時間の無駄だったんじゃねーか？
ニコニコが好きだったから2007年から9年間毎月500円を払ってきた。
6000円 * 9 = 54000円を払ってきたわけだけど、
実は時間とお金を浪費しただけだったのでは、と思い始めてきた。
この状況を振り返ると、小中学生たちがYoutubeを見るという気持ちは凄くよく分かる。
ニコニコは月額を払うことの出来る大人たちのメディアになり、
Youtubeは無料ながらも広告を見ることで快適な動画環境で動画を見ることができる。
だってニコニコユーザーチャンネルは更に月額払わないと見れないしさ。
そんなのを子どもたちはどうやって見るのさ。
ニコニコが古いのではなく、ニコニコが新しい子どもたちを拒絶しているのではないか？
という気がする。
その月額500円で儲けてきたから今更離れられないのかもしれないけど、ニコニコが廃れていくのはしょうがないのかなーと思った。
ssdkfk