appengine ja night #33 に行った話
行ってました。
今年に入ったあたりから職種を変えて私自身もapp Engine上での開発をするようになりました。のでapp engineの勉強中です。
弊社プロダクトはpythonで作ってるですけど、みんなgoかjavaばかりで結構悲しい気持ちになりました。まあstandard環境でpython3が使えないからしょうがないね…早く使えるようになってほしいですね
資料はこのへん。
appengine ja night #33 - 資料一覧 - connpass
面白かった箇所
「メルカリ アッテ」を支える Google App Engine と Golang // Speaker Deck
DAU 100万人で 課金額が200万くらい
GoogleクラウドとApp Engineで実現したドローン業務利用
資料見当たらないけど、これは話自体が面白かったやつです。
ドローンを使って建築現場の撮影をしてそれを地図に重ねてあわせてWeb上で見えるようにするところまでをひとまとめとして提供という。
3D詳しくないので、ポリゴンではなく点群なんですって言われても凄さがよくわからなかったり、地図に詳しくないのでGoogleMapはWebメルカトル図法と呼ばれる形式で、国土地理院地図はXYZ形式?だかいう名前のらしい、とかいうのを聞いてもあんまりピンと来ないわけです。
もちろん本業でない以上別に自分で作れるくらい把握できる必要はありません。とはいえせめてどんな話をしてるかくらいはわかるように、浅く広く勉強しておきたいなぁと思いました。
Endpointよりもswaggerの方がいいのか!というのが伝わってきた
GAEレスポンスの1桁ms化
これも資料見当たらないんですけど、興味深い話。
GAEはいままではUSにサーバーがあったわけで、通信が海を超えるわけです。そうするとどんなに簡易な通信でも必ず300ms程度のオーバーヘッドが存在する。ここがgaeが遅いとか言われる1つの原因になっています。
解決法の1つはAsiaにリージョンができることです。これはやっと2016/7にTokyoリージョンができるという話があります。でもすでにUSで動いてるアプリは移動できません、それに今すぐ早くしないとまずいんだということもありえます。
じゃあ東京リージョンをまたずにCDNを使ってしまえということでFastlyを使った話をしていました。
Fastlyは日本にDCがあるので、海を超えずとも通信ができます。物理的に近いというのは強みになりえるのです。
値段も、想定される東京リージョンと比べてもそんなに遜色ないようなので、こっちでもいいんじゃね?というのは興味深いところでした。
pythonを書く話
今年になってからpythonを書くことになって復習がてらなんか書いたりしてました。
こんなのとか。
https://github.com/arvelt/weather-python
これはちょっと時間はかりたいって時に書いた関数を外に出しただけ。
https://github.com/arvelt/measure-time
Pythonはなんというか、変な癖がなくて結構わかりやすくてとてもいいと思いました。ただ2系と3系の断絶がかなりつらいですね。仕事ではGAEと使うので2系を覚えるんですけど、最近3系も使えるっぽいようになりましたが、既存の資産をいきなり差し替えることはできないので、今後も2系とは長く付き合うことになりそうです。
2015年を振り返って
去年立てた目標
Paasで何か1つ作る。ライブラリのようなものを1つ作る。フロントエンドに関する潮流を追いかける。品質管理に関する学習をする。扱う対象について。Javascriptとcss、それらを扱うフレームワーク。Google製品全般、pythonとそれらを扱うフレームワーク。このへんを深めていきたいと思います。
趣味の目標としては、Unityを触って1品ゲームを作ること。DirectXを触って3Dへの造形を深めること。漫画の練習をすること。
目標を達成したか
・Paasで何か1つ作る
→やってない。
・ライブラリのようなものを1つ作る。
→やった。ダンジョン生成プログラムを作ってPyPiに登録した話
・フロントエンドに関する潮流を追いかける。
→一応やってた。
・品質管理を学習。
→やってない。
・Unityで作る。
→やってない。
・DirectX触る。
→やってない。
・漫画の練習
→一応やってた。
所感
2015年は非常に自分が書いたブログ記事が少なくて、これはつまり何もしていなかったので書くことがなかったのだと気づいた。立てた目標もすっかり忘れてたいたし。ゲームのことは別ブログに書くことにしているが、そっちは大量に記事があってなるほどね?みたいな気持ちになった。そういうことだったかー。
Unityでローグライクを作ろうとしてダンジョン生成のアルゴリズムの試作として作ったライブラリを公開したのはよかったが、結局Unityがめんどくさくて作り始めることができなかった。私はUnityの使い方を覚えたいのではなくて、ゲームのアルゴリズムを考えたいのだ。
なにか流行りの技術を試そうとしてhello worldと表示してみても、何も頭に残らずとても触ったとはいえない。そういうものを、一通りまとまった機能の束として試さなくては何も身につかない。そういう開発の環境と公開できる環境がどうしても必要だが、それを用意するハードルが想像以上に高いものだと気づいてきた。どうにかしたい。
最近プログラミングをすることが嫌になってきている気がする。転職して以降仕事ではフロントエンドをやっていたのだが、それが合わなかったのだろうか?これからはサーバー側に行ってみてもいいかもしれない。
プログラミングがそもそも好きじゃないというのはこの仕事についた瞬間から自覚していて自分にとってはいまさら過ぎる話ではある。それと仕様を考えるっていうのがとにかくできなくてどうすればそういうのがうまくなるのかいまだにわからないのでその辺りを勉強したいとずっと思っている。
YAPCとPyconに行った。たまにいくと自分もなんかやらなきゃ!!!みたいな気持ちが3日くらいは維持できるのでそれなりに有効だと思う。
2016年の目標
フロントエンドは諦めたので、サーバー側の勉強をしていく。いかしたAPIはどういうものか?そのための適切な設計は?テストの書き方は?そういう感じのこと。
品質について体系的なことを知りたい、というのは諦めない。
ブログをちゃんと書く。ちゃんと普段から勉強してれば月に1つくらいは書くことあるというのは経験上わかっている。それができるくらいには学習を怠らないようにしなくてはいけない。
やらない言い訳のために自分でハードル上げてしまっている気がするので、もっと気軽にアプリケーションを作りたい。ライブラリだか、ゲームだかはわからないけれど、とりあえず3日くらい勢いで書いて公開方法はあとから考えるくらいの気軽さで取り組めるメンタルに変えていきたい。
あと漫画かけるようになりたい。
PyconJP2015に行ってきた話
いってきました。
起きられないので基調講演とか行ってないです。
聞いたやつ
1日目
mcpiがpython3に対応してないからフォークして直したし、すぐ動かせるdockerファイルも用意したよ!とかいう素敵な内容でした。試してみたらちゃんと動いてたし凄い。
ギター片手にスピーチ。入力した音をpythonでいじって遊ぼうみたいな感じでおもしろかった。私もやってみたい。
【混沌と秩序】pip/Virtualenv(venv)/setuptoolsそしてWarehouse… パッケージング最前線 #PyConJP_M #pyconjp - Togetterまとめ
資料見つからないんですけど公開してないんでしょうか…?こういうのこそ見直したいのに…
あとあーらんの話もいたけど英語だったのでさっぱりわからなかった。
2日目
Pyconjp2015 - Python で作って学ぶ形態素解析
形態素解析ってどういうときに使うんでしょう。検索エンジンとか、辞書アプリとかですかね。
実際dungeon-generatorっていうライブラリをpypiに上げてみたときに色々やりました。ちゃんとできてない気がするので見なおそうかな…という気持ちです。
所感
・どこかでもう言ってたけどpyconは真面目な雰囲気で心地良い。つまらん悪ノリとかあまりない感じ。
・その分内容は難しい気がする…?
・今回の最年少スピーカーが15歳ということで、私もがんばらねばーみたいな気持ちになった。カンファレンスはこのやる気をもらうために行ってる感じがします。
・そのうち発表とかしてみたいけど、普段python使ってないですね
・弊社サービスはGAEで運用しておりますゆえpythonと言えば、Google App Engineだと思ってたんですけど、その話してる人まったくいなくてpythonの人達の間でさえそんな扱いなのか…という悲しい気持ちになりました。
・プレゼントでTシャツが当たりました。ありがとうございます。
YAPC2015に行った話
満を持して2日間チケットかったんですけど、1日のしかも午後からしかいってないので、もうちょい考えてから購入するべきだったと反省しております。だからトークも2つしか聞いてない。
Adventures in Refactoring - YAPC::Asia Tokyo 2015
https://s3.amazonaws.com/dinosaur/refactoring+-+yapc+2015.pdf
なぜリファクタリングするのか?
1.開発者のハッピーのため
2.開発者の教育のため
リファクタリングの評価は?
1.カバレッジ
2.減らした行数
3.性能向上
リファクタ前とリファクタ後のコードレベルでのA/Bテストみたいなことをするツールを使って計測する → github/scientist · GitHub
英語わからないので半分くらいしかわかってないけど多分こういう感じの話。正しいことを正しくやるためにいろいろ工夫してがんばろうという感じで、さすがGithubだなーという思った。
HTTP2 時代の Web - web over http2
mozaic.fmでおなじみのjxckさんのトーク。HTTP2はもうRFCとして公布されたので、いよいよ使うフェーズになりましたね。という感じの内容。
http://www.rfc-editor.org/rfc/rfc7540.txt → 日本語訳「http://summerwind.jp/docs/rfc7540/」
HTTP2を使うことで、Server Push、Cachのコントロール、Service Worcker、Httpsが(基本的に)必須、とかそういう風に変わっていくのよ。じゃあ対応するの?しないの?みたいな内容。
ブラウザ側はもう対応し始めているので、次はサーバー側。みんなサーバーの実装をし始めている。有名どころではnginxが2015年中には対応したい的なことを表明しているらしい。
所感
冒頭に書いたけど、2日チケット買ったのに実質半日分しか享受できなかったので、ちゃんと考えてから買うべきだった。でも一番聞きたかったjxckさんの話聞けたのでよかった。あとrebuildリスナーとしては、歴代なんちゃらのトークできていたらしいmiyagawaさんを目撃したのがラッキー感あった。あれが生miyagawaか…!!!みたいな感じ。なんか勝手に長身だと思い込んでたけど違った。
あと、ベストトーク賞が、Http2の話2つきてしまいどうなるんだーってところで、Perlの話が1位になっていたのは大円団感があって非常によかった。終わりよければすべてよし。
実は去年行った後で、ヤプシーの内輪ノリ感をディスる感想を一言書いたんだけど、今回はなんかそういう雰囲気を極力排除しようとしている気がした。気がしただけでほんとのところはわからない。その記事は.pmリファラーで読まれていたので、一意見として届いていたのかもしれない。
コミュニティーを古参が壊す、というのは万事においての真実なので、YAPC::Asiaとしては一旦クローズするのは、そこらへんを見越してなのかなーとか邪推していた。ユーザーベースなのに大きくなりすぎて大変そう、というのは外から見ていて感じていたし。
言うには言ったけど、ヤプシーが面白い面白くないかでいったら確実に面白いものだったとは思っている。何はともあれ、立ち上げや運営に関わったり盛り上げたりした人達へ、おつかれさまでした、ありがとうございました。という気持ちでいっぱいなのです。
すでにあるWebサービスをElectronを使ってネイティブアプリのように見せるやり方
Electron触って全く意味がわからなかったので手順を残す
Electronでアプリケーションを作ってみよう - Qiita
環境の作成と配布用パッケージングについてはこれを読む
ElectronでChatworkをデスクトップアプリ化 (Webview + badge) - Qiita
中身を表示するやりかたはこれを読む
流れ
・npm -g install electron-prebuilt する
・中身を書く
・表示したいWebはwebviewタグを使って表示する
・npm -g install asar する
・asar pack . ~/tmp/app.asarする
・Electronのディストリビュートをダウンロードしてapp.asarを設置する
・Electronのディストリビュートの名前を変えたりしてから、配布する。
配布するときにどうやるかとかはここにかいてある
electron/application-distribution.md at master · atom/electron · GitHub
Ubuntu+nginx+uwsgiのサーバーに、CicleCIを通したGithubプロジェクトをデプロイできるようにした話
Githubで管理しているflaskアプリを、CicleCiでグリーンになったら、Ubuntu+nginx+uwsgiのVPSサーバーにデプロイできるようにしました。
お遊びアプリ作るときのバックエンド用にさらっとアプリ置ける場所欲しいよね、と思って用意したものです。
使用したバージョン
Ubuntu 14.04.2 LTS
nginx/1.4.6
uwsgi 2.0.10
ansible 1.9.1
Vagrant 1.7.2(手元でテストするときに使った
実現するワークフロー
この結果以下の様なワークフローになります。
2.ansibleのスクリプトを使用し、プロビジョニングする。(ここでUbuntu+nginx+uwsgiのサーバーが完成
3.releace/*ブランチを作成しgithubにpushする
4.CicleCIのテストが動く。
5.グリーンであれば、2のサーバーにデプロイされる。(ここでアプリのデプロイが完了
6.http://arvelt.net/hello-flask でHello World!が表示される(複サブディレクトリを使用できるようにしました。
7.アップデートする場合は3から実施する。
仕組み
2要素にわけて構成しました。
1.サーバーを整えるansibleスクリプト(arvelt/simple-python-api-server-ansible-book · GitHub
表でnginxが振り分けて、うらでuwsgiが動くようになっています。uwsgiを選択したのは、バックエンドはpythonで作る予定だからです。
最初はansible-galaxyをなるべく使おうと思っていましたが、動かしてもあっちこっちの設定が知らないままにされているというようなことになってしまい、返ってハマりがちでした。結局最小の設定を自分で仕込むでいます。
nginxとuwsgiをつなぐ箇所が何度もつまり続けました。unixソケットファイルというのを使うのがよいらしいのですが、どうにもうまくいかないのでポートを使用するようにしています。
2.CicleCI用の設定ファイルを持ったGithubプロジェクト(arvelt/hello-flask · GitHub
このワークフローの構造を作るため取り組みなので、flaskを使用したhello-worldアプリです。cicleCI上でテストを実行しますが、cicle ciはデプロイの設定をすることができます。HerokuやAWSは元から用意されていますが、それ以外にも任意のスクリプトを実行させることができます。
私はデプロイスクリプトとしてansibleコマンドを指定することで、githubからcloneさせてデプロイできるようにしました。
cicle ciから別のサーバーにデプロイするために、CicleCIのProjectSettingからsshの秘密鍵や環境変数を登録できるようになっています。ansibleには変数で受け取るようにしておけばそれらの値を使うことができます。
特にsudoするときのパスワードをどう渡すかは大変苦慮しました。スクリプトではask-sudo-passは使えないからです。ansible-sudo-passwordという値があることに気づいてからは、いかにしてそれに渡すかということに腐心しました。なんとかうまくいってよかったです。
所感
今回はVPSにデプロイできるようにしていますが、これは例えば、リリースブランチにpushするたびにAWSで新規インスタンスを作成して、その上にデプロイする、という様なことも簡単にできます。ここらへんはプロビジョニングツールを使った利点です。
データベース周りがないのですが、今回はそこまでいけずに力尽きたというのがあります。実務で使うものでもないので、MongoDBなどを選択して環境にするかもしれません。
これらのプロビジョニングツールを試したい場合、Vagrantを使用するのが非常に有効です。手元で作っては壊しを何度も繰り返せます。VPSもそれ自体はよいですが、なにぶん外部に公開されていますので、あまりおかしなことはできないというのもあります。
ところでこの仕組は私が考えたものではなく、先人がやっていたことを改めて手元でやってみたという確認です。大本はそちらのほうをごらんください。
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー