Author: user

Herokuを使ってサービスを作ると、どうしてもストーレッジの問題にぶつかります。Herokuはいいと思うのですが、ストーレッジがないのです。実は知られているようで、結構な数の人が知らなかった落とし穴でもあるようなのですが、Herokuでは画像が保存できません。OSとPythonやRubyなどの言語とデータベースは提供してくれるのですが、画像は保存できないのです。私はこれを知らなかったので、かなりびっくりしてしまいました。。 そこで仕方がなくAWSを始めることにしたのですが、このAWSのs3というサービスがかなり良いので、かえってよかったと思っているところです。 ご存知の方も多いと思いますが、HerokuはPaaSと呼ばれるWebサービスの一種で、ハードディスクのサーバーと、UbuntuなどのOS、それにデータベースやPythonなdの言語、各種のライブラリをまとめて提供してくれます。 私は開発環境がMacなので、自分のところのサーバーもMacでやれば、本番と開発環境が一緒なのでやりやすいのではないかと、色々迷っていました。パーミッションなどの扱いやすさは、手元で実際にいじれる実機のサーバーの方がわかりやすいですし、コストも実際にサーバー機を買ってしまってもそれほどのものではありません。ですが、Herokuなどのクラウドを使うと、１２factor.netなどに書いてある設計上のデザインパターンに自動的に従うことになると言うのに惹かれてHerokuでやってみることにしました。やはりサービスが段々大きくなっていった時にメンテナンスが楽な方がいいですものね。それとやっぱり自己流でやるよりは、信頼性と実績の面からもで世の中で通用しているものでやってみる方が良いのかなと思いました。 s3の良いところは、まず、値段です。1GBあたりの料金は一月で約3円。データが100GBでも月300円です。私の事務所では領収書の画像データを仕訳データに翻訳して、画像と仕訳を一緒に整理して保存するサービスを提供しようと思っていますが、iPhoneで撮影した写真だとデータのサイズは約3MBです。ですので300枚保存してこれでやっと1GBで、これで、3円です。100GB使おうと思ったら、30,000枚の写真データを保存することが出来ますが、これで小さい会社なら2０社分は行けるのではないでしょうか？ 次に、信頼性。これは、Amazonの説明によると99.999999999%の信頼性があるのだそうです。 小数点以下に、9が９個つくので、データが消失する可能性は、1000万分の1と言うことでしょうか。自分のところでサーバーを持ってデータを保存するより、よほど高い信頼性です。使わない手はないですね。 その他、Pythonのboto3をはじめ、RubyやJava、.NETなどの他、おそらく、ほとんどの言語でファイルや閲覧権限等を簡単に操作できるモジュールが用意されています。プログラムの側から簡単にファイルをアップしたりダウンロードできたりするのです。ここだけ見ても、自分でファイルの保存や権限の設定をプログラム的に作るよりよほど簡単で確実です。ソフトウェアの世界に限りませんが、「巨人の肩に乗る」と言う言葉があります。 こう言う新しいもの（全然新しくないけど）はお金を出してもどんどんやってみる方がいいですね。

PyCharmは買う価値があるでしょうか。 使って１ヶ月くらいが経ちますが、私は買ってよかったです。多分、この１ヶ月でも十分に元は取れています。その前は、３−４ヶ月はAtomを使っていたのでよくわかります。やっぱり効率性が劇的に上昇しています。もう、PythonをやるのにAtomには戻れません。どうせプログラミングをするなら、良いツールを使うほうがいいです。効率性が素晴らしい。 Atomとは色々違うのですが、まず、デバッグが出来るようになるのが大きいです。Atomで作った場合は、Atomはエディタですから、直接実行することは出来ません。ターミナルから実行して、エラーが出たら、エラーのログをみて何が悪かったかを解析しなくてはいけません。 PyCharmならブレークポイントを設定できます。エラーが出る場所で、ブレークポイントで実行を停止して、各変数にどのような値が入っているかを確認できます。私が知っている範囲では、Atomのプラグインでは逆立ちしてもそんなことは出来ません。 PythonやRubyなどのスクリプト言語は静的型付け言語に比べて、文法チェックが事前にないところが弱点だと思っているのですが、PyCharmはインスタンスが割り当てられていない変数などに赤の波線を引いてくれます。これで実行する前にある程度のバグの元は潰してくれるんですね。 名前をまとめて変えてくれるリファクタリングの機能もあります。個人的に気に入っているのは、ある変数にマウスのポインタをあてると、同じスペルの変数が全部ハイライトされます。これが、コードの流れを追う時にとても楽になるので助かります。 この他にもテストなど、まだわかっていない機能が色々ある様です。 確かに、最初は有料のツールは躊躇すると思います。なので、最初の数ヶ月をAtomでやって、PythonやらDjangoなどのフレームワークをやっぱり自分ががちゃんと使うと言うことがわかってから買うのでも遅くはないと思います。それに、Atomなどのエディタで開発すると、その手作り感で、どの様に動くのかわかリます。それからPyCharmなどのIDEに移行するのでも遅くはないと思います。 ちなみに私は、もう、Atomに戻ることはなさそうです。

PythonでWebサービスを作るために色々な事に遭遇したり、調べたりしたので、それをシェアするためのポストです。色々とやってみないとわからない事があり、知ってれば無駄な時間を大量に使う必要のなかった落とし穴があるので、それをシェアしようという趣旨です。 貴重な時間を浪費するのを避けるためにも、次にやる人のかたの参考になれば幸いです。 どの言語を使うか まず言語選びです。ウェブサービスを作る場合には、言語を選ぶ必要があります。可能性としては、C#、Java、Ruby、PHP、Pythonなどがあると思います。最近はサーバーサイドのJavaScriptやLinuxで走るSwiftなどもあります。色々ありますし、どれを使っても一緒と思いそうですが、ライセンスや言語の性質でその後に大きく影響するので、実はとても重要です。 まず、C#はLINQもあり非常に使いやすいのですが、WEBサービスとして公開する際にはライセンスの問題が発生するので注意が必要です。最初からユーザーにライセンスのコストを転嫁できる立場の強いWEBサービスなら別ですが、最初は無料でユーザー数の獲得に力点を置いているような場合には（特に最初は）コスト割れになると思われるので、使わない方が無難です。ちなみに私は簡単便利なLINQは大好きです。社内システムなどで使うようでしたら問題なさそうです。 Javaは開発が重たすぎるので、やめた方がいいという意見も多いです。また、世の中で活躍している有名なWEBサービスはスクリプト言語またはライトウェイト言語と呼ばれているRubyやPHPを使っているところが多いようです。Moneyforwardとかfreeeとか。実際に調べてみると、良いフレームワークやデータベースとの接続を楽にするOR Mappingは随分改良されているようで、Javaも選択肢の一つなのではないかと思いました。 C#やJavaなどは静的型付け言語と呼ばれていますが、静的型付け言語の良いところは、コンパイルする時に型に関するエラーを見つけてくれるので、バグが入りにくいというのがあると思います。実際にiPhoneなどの開発に使われる言語はSwiftですが、これは静的型付け言語です。AppleがSwiftを静的型付け言語にしたのは（統計的にバグが少なくなるなどの）理由があるはずです。 ライトウェイト言語（LL）では、RubyやPython、PHPなどがあります。私は一応全部試してみて、今回はPythonで行こうと決めました。Rubyは日本では大手のWebサービスにも使われておりメジャーなのですが、Googleの検索件数などから逆算した割合だと、世界ではPythonの方が圧倒的に使われています。私の調べた範囲なだけですが、使っているプログラマーの数が多いからかライブラリーの数も豊富です。画像を使ったWebサービスでは必ず必要なPILLOWや、CSVの読み込みや書き出しの処理をするcsv、エクセルやPDFの処理など多数のライブラリーが存在します。きっとRubyやPHPにもあるのでしょうが、海外でのシェアはPythonの方が圧倒的です。 PHPも多くのサイトで使われているし候補ではあったのですが、他の言語では関数やプロパティをA.Bというふうに書きますが、PHPではA->Bという風に書きます。２文字で打ちづらいキーで書かなくてはいけないのと、見た目が何となく好きになれなかったのでやめました。ちょっと本質的な理由ではないですね。 動的型付け言語はバグが多くなり、メンテが大変か？ 静的型付け言語の方がバグが発生しにくいと思われるので、システムが大きくなる予定だったら、メンテナンスのことを考えてJavaを使った方が結局効率がいいのではとは思いました。RubyやPythonなどの動的型付け言語は最初は楽ですが、あとでバグ取り地獄に入ってしまうのだったら、開発の後半でシステムが大きくなっていくほど長い時間がかかりそうに思えました。最初が急坂でだんだん傾斜が緩くなっていくか、最初がゆるいけど、あとで段々きつくなっていくかのどちらにするかのイメージです。 ただ、現状を見回すと急成長しているWebサービスは動的型付け言語でやっているっぽいです。私の見えていない何かがあるのかもしれないと思い、とりあえずその流れに合わせてみることにしました。 エディタ、IDE、開発ツール 最初はATOMを使っていたのですが、開発が本格的になってからPycharmに変えました。 ATOMは無料ですし、入力補助のモジュールもあるのでテキストエディタとしては大変優秀です。ですが、変数のスペルミスなどは事前に見つけてくれないので、実際に走らせてみるまでわかりません。 ATOMに限りませんが、テキストエディタで開発すると、なんでもテキストエディタとターミナルからコマンドを使ってやらなくてはいけないので、プログラムが走るまでの環境をどうやって作るかとか、ツールのインストールの仕方とかとてもよくわかるようになります。私も、ATOMで開発を始めたおかげで、Linux（やMaxOS）がどうなっているかだいぶ勉強になりました。 最初は無料でいいのですが、本格的にやることがわかったら無料でも有料でもIDEを使った方がいいと思います。私の場合はPycharmを個人ライセンスで買ったので89ドルでしたが、スペルチェックのミスを見つけるのやリファクタリングはエディタではできないので、それだけでも十分に元が取れます。 まだ試していない機能がたくさんあるのですが、デバッグでブレークポイントも設定できるようですし、IDEにお金を出す価値は十分すぎるほどあります。 フレームワーク フレームワークはPythonでは一番機能が充実していると言われるDjangoにしました。PythonではそのほかにもFlaskやPyramidなど色々なフレームワークがあるようですが、Djangoが一番機能が充実しているようです。実際、ORMや画面遷移など、とても便利です。 ORMは何を使ったらよいか。 ただ、DjangoのデフォルトのORMは書き方も直感的で便利ではあるのですが、データベースを動的に複数作りたい場合に、構造的にうまくできなさそうなのでやめました。DjangoではDBへの接続を設定ファイルに書いておかなくてはいけないのですが、私が作ろうとしているのは、新しいユーザーがウェブサイトから登録した場合に、個別に新しいDBを作る設計にしたかったので、接続文字列をログインのたびに動的に変更できない（ように少なくともOfficialのTutorialではそう見えた）Django ORMはやめて、sqlalchemyというものを使いました。 sqlalchemyはFlaskやPyramidなどのPyrhonの他のフレームワークで使われているORMなのですが、Djangoでもインポートして使えます。 データベースは何を使うか。 Djangoのデフォルトはsqlite3なのですが、使おうと思ったプラットホームのサービスのHerokuでは、sqlite3は使えなくて、Postgresqlです。その他にMySQLという選択肢もありますが、私にはMySQLでもPostgresqlでもどちらを使っても得られる機能は同じに見えました。sqlite3はデータがファイルなので管理するにしてもわかりやすいのですが、パスワードをつけることができないのでユーザー認証ができず、やめました。 プラットフォームは何を使うか Windowsサーバーはライセンス料が発生するので論外でしょう。 次に、Linuxを使うかMacを使うかですが、普通はLinuxのどれかのバージョンを使うのでしょうが、私は開発をMacでやっているので、WebサーバーもMacにしました。やっぱり環境の構築とか色々覚えるより、使い慣れている環境を使った方が一々調べる手間も減ると思ったので、ハード代くらいは浮くと思ったのです。ハード代といってもmac miniなら5万円くらいで買えるので、Linuxのハードを買ってもそれくらは普通にかかりそうです。 サーバーをローカルで立てるか、クラウドにするかも考えたのですが、今の所は、事務所に実際のサーバーを置いて運用する予定です。最初はHerokuを使おうと思っていたのですが、色々試したところで、動的にアップロードした画像ファイルをHerokuには保存できないということがわかったのでやめました。画像ファイルが保存できないなんて、領収書の保管が必要な私のサービスでは致命的でした。 ちなみにアップロードした画像ファイルはAWSに保存するようにするのが一般的なようなのですが、それだったら最初からAWSを使った方がよくないですか？ 以上、色々と言語の選定から、フレームワーク、データベース、環境構築などに渡りつらつらと書きました。新しくWebサービスを立ち上げる際に沢山の選択肢がありますが、その中からどれを選ぶかなどの参考になれば幸いです。

PythonにはDjangoという有名なフレームワークがあります。Djangoには簡易サーバーが付いているので、自分のMacで開発するときは、特にApacheやnginxなどのWebサーバーをインストールする必要はありません。開発用の段階ではこれで十分です。 しかし、いざ、iPhoneやAndroidなどの端末からサーバーにアクセスするアプリを開発しようとすると、外側から自分のMacにアクセスできるようになることが必要になります。iPhoneなどの端末から自分のMacにアクセスできないと、ちゃんと動いているかどうかもわかりません。ここで壁となるのが、Djangoに付属して付いてくるこのウェブサーバーでは外側からアクセスできないのです。 私は、今、iPhoneからサーバーに領収書の写真を送って、サーバー側で私たち会計事務所のスタッフが会計データに変換するサービスの開発をやっています。人間が写真のデータを会計データに直すサービスなので、AIなどのかっこいい技術を使うわけではありません。そこはいけていないのですが、そこはちょっと脇に置いておきます。 そのようなわけで、いろいろ調べてみた結果、昔からあるApacheと比較的最近のnginx（エンジンXと読む）が選択肢になったのですが、前にも触ったこともあって馴染みにあるApacheを入れてみることにしました。 具体的なステップ ApacheをDjangoで使えるようにするのには、ほぼ一日仕事でした。速い人は数時間でできるのかもしれませんが、初めての方には、色々とひっかりやすいポイントがあり、結構時間がかかります。 私の環境は、Apache2.4、Python3.6です。 順番に、 Apacheのインストールと起動、 mod_wsgiをインストールしてApacheからPaythonのプログラムファイルを処理できるようにする、 MaxOS/Linuxのファイル権限を変更して、外部からのアクセスでも必要なファイルを読み書きできるようにする、 という順番でやっていきます。 一気にやろうとすると、色々なところでハマるので問題の切り分けができにくくなります。順番にやっていくのがいいと思います。 (1) まず、最初はApacheです。 Apacheは、とりあえず動くようにして、「It works!」の既定のメッセージが見れるようになることが目標です。 まずはターミナルを開けて、appachectl startとコマンドを打ち込みます。問題がなければ、次の行に移動して入力ができるようになります。 そして、Safariか Chromeを開けて、アドレスバーのところに127.0.0.1と打ち込みます。「It works!」と表示されれば、Apacheはちゃんと動いています。 (2) 次に、mod_wsgiをインストールします。 これが、Webでは様々な記事が交錯していて、一番わかりにくく苦労しました。しかし、一度出来てしまえばちゃんと動きます。ポイントはmod_wsgi.soというファイルをApacheの設定ファイルにちゃんと書いて、ApacheへのリクエストがきちんとPythonの処理として認識されるようにすることです。私は、最初、Pythonのプログラムのファイル（例：hello.pyなど）がただのテキストファイルとしか認識してもらえず苦労しました。 手順としては、 ターミナルからpip3を使って、pip3 install mod_wsgiを実行する。ー＞mod_wsgiがインストールされる。 Apacheの設定ファイルであるhttpd.confのファイルを編集する。httpd.confファイルはprivate/etc/apache2という場所にある。これをATOMなどのエディターで開いて、以下のテキストを追加する。場所はどこでもいいようです。 ポイントは、ネットに色々書いてあるような単純なファイル名ではないので、ちゃんとそのsoファイルの場所と名前を発見して、その通りに記述することです。私の場合は、発見したネット情報のPythonバージョンが3.5と少し違っていたので、修正したらちゃんと動きました。 また、Directoryタグの中の記述の仕方もちょっと変わっているようなので、下記のようにすることが重要です。 LoadModule wsgi_module /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-darwin.so WSGIScriptAlias / /users/ichirok/Documents/python_projects/firstDjango/firstDjango/wsgi.py Require all granted この設定がちゃんとできるようになると、Apacheがちゃんと動いて、返ってくるエラーもInternal Server Errorなどになります。それまでは、そもそもPythonのファイルをプログラムファイルとして認識してくれません。 (3) ファイルのアクセス権（Mac OS/Linux)の設定 Permission Deniedなどのエラーが返ってきます。 chmod 755 directoryName コマンドを使って、Apacheがちゃんとファイルを読めるようにしなければなりません。 どこに問題があるか、問題の特定は、Apacheのエラーログを見ると速いです。エラーログは /private/var/log/apache2 … Read More “DjangoをApacheで動かすまでの話” »