Djangoでアプリを作りましたが、これを公開するのにローカルのマシンを使うか、クラウドを使うかで迷いました。 そこで、どちらが良いのかメリットとデメリットをそれぞれあげて、有利不利を検討してみようと思います。 まず、コスト ローカルでやる場合には、開発と同じ環境の方が楽です。私はmacのノートで開発しているので、Mac Miniサーバーを考えています。ツールを入れる手順などが、開発環境と全部一緒にできるので、かなり楽だと思うのです。値段も、一番安いもので5万円くらい、CPUがいいものでも7万円ちょっとです。他のことにも使えますから、それほど高い買い物とは言えないと思います。 次に、クラウドです。今回のアプリは領収書の画像を保存するのでデータの保存量がだんだん大きくなっていきます。一枚の領収書のデータサイズを１MBとして、1000枚で1Gです。1年に1,000枚として、お客様１件で１GBという計算になります。 簡単な計算ですが、100件のお客様に使用していただくとすると、１００ギガですが、アマゾンのS3の料金表を見ると最初の 最初の50TBまでは、1GBあたり月$0.025ドルだそうです。つまり、1件につき月3円、１００件で300円、年間でも3,600円です。べらぼうに安いですね。 ソフトウェアの設計の良さ 次にソフトウェア自体の作り方ですが、クラウドを使うことによる大きなメリットがあります。このメリットはある文章を読むまで私も意識していませんでした。 Herokuでサービスを公開する場合、色々面倒くさい設定が必要になります。例えば、まず本番環境に展開する場合には、Githubを通してpushする必要があります。また、依存関係のあるモジュールをあらかじめリストアップして置く必要があります。また、Hrokuでは画像ファイルを保存することができないので、AmazonのS3などの外部ストーレッジを利用する必要があります。 かなり面倒くさいのですが、Herokuで展開する過程で、Herokuの提唱するソフトウェアを効率的に開発するための１２の提言に自動的に準拠することになります。この１２提言は12factors.netとサイトで公開されています。この１２提言がいいのです。 例えばですが、以下の通りです。 1.) セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 2.) 下層のOSへの 依存関係を明確化し、実行環境間での 移植性を最大化する。 3.) モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 4.) 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイを可能にする。 5.) ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップできる。 この観点からはクラウドでやる方が圧倒的によさそうです。 簡単さ 短期的にはローカルの方が簡単かもしれません。ディレクトリ構造は自由に変更できるし、DBなどのインストールも自由です。開発と本番環境も、例えばサーバーでmac miniを使えば同じになります。使い慣れている環境の方が、学習コストも少ないのでツールなどは使いこなしやすいです。 上記の比較からは、クラウドの方がよほど有利に見えます。私は、新しいサービスは、とりあえずローカルではなく、クラウドで始めてみようと思いました。
Category: システム開発
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で動かすまでの話” »
Swift3の文法が変わりすぎて、昔の本がほとんど役に立たなくなってしまいました。あまりに違いすぎて、文法を結局一から勉強しなくちゃいけないのと同じ状況なので、本を一冊買ってきました。 「Swift実践入門」 今をときめくウェブ系の会社であるクックパッドとメルカリの実務家が書かれているので、ただの文法だけ解説した本と違って、それぞれの機能をどのような場面で、どのような理由で使うのかが書いてあり買ってよかったと思います。 クラスと構造体の使い分けなども書いてあるのですが、できるだけクラスを使わずに構造体を使った方がいい、など目から鱗が落ちるような実践的な知識も色々書いてあります。 私にとってよかったのは、「Web APIのクライアントを作ろう」のセクションでした。今のスマートフォンのアプリでは、Web APIを通した情報の取得と、投稿は欠かせない機能です。その部分を実際のコードを使って解説していただいているので、とても役に立ちそうです。
噂には聞いていましたが、Swift 2.xから３.xに変更するのはとても大変です。以前に書いたコードがかなり使えません。全然使えないということはないのですが、引数の使い方が変わったり、関数の名前が変わったりで、マニュアルで直そうとすると、一日じゃとても終わりません。ほぼ新言語をやっているかのようでした。いちいちグーグルで調べても、情報が少なくて良くわからないし。。 Pythonも2.x系から3.x系に移行するときは、ほとんど互換性がなかったと言いますから、Swiftでもこれくらい仕方がないのでしょう。 新しいプログラミング言語を学ぶ時の常ですが、最初はよくわからなくても、我慢して続けていると少しずつわかってきます。継続は力なり。頑張って少しずつ続けてみようt思います。
Pythonを使って毎日少しずつ開発を続けています。 実際にはDjangoというWebサービス用のフレームワークを使っているのですが、これが優れものです。エラーをそれなりに原因が表示されるので、表示されたエラーをGoogleで調べるとそれなりに解決方法に行きつくことが出来ます。 本当に毎日少しずつしかやっていないのですが、それでも、少しずつ出来るようになっていくところが面白いです。プログラミング言語は「手になじむ」という言葉があるように道具なので、使わないとダメなのです。 プログラミングは勉強して資格をとっても、あまり役に立たないというか、時間の効率が悪いというか、眠くなってしまうというか、イマイチ前進している感があまりありません。 それよりは、実際に使うものを作るのが一番早道です。実際に使うものは、どれだけ簡単なもので、シンプルな機能のものにしようと思っていても、いざ作ってこ公開することを前提とすると、結構な数の機能が必要になります。実際に他人に公開しようとすると、内輪で使っている時はまあいいかと思っている少し不便な部分やバグもきちんと作らなくてはならなくなります。 そう、実際に作るだけで相当勉強になるのです。 今日は、初めて有料のIDEであるpycharmをダウンロードしました。プログラミングに限りませんが、あることを続けていると段々その周りにあるものもわかってきます。最初はAtomというエディターでやっていたのですが、インテリセンスの機能が弱いので、やはり効率が良くないです。pycharmを使ってみるのが楽しみです。新しいツールはいつも少しワクワクします。
Dockerというものに初めて触ってみました。Dockerというのは、OSの上に別のOSを走らせる技術で、例えばMacやWindowsの上にLinuxを走らせる事ができます。 こんな事をして何が嬉しいのかというのを、私もイマイチわかりませんでした。でも、何事も百聞は一見にしかず。とりあえず触ってみました。このコンテナをいくつも背中にしょったクジラのイラストがDockerの概念を上手く表していていいですよね。 インストール方法は極めて簡単で、ホームページから、指定されたボタンをクリックするだけ。 Macのターミナルから、docker run -it ubuntu-latestとやるだけで、何やらたくさん文字がダーっと下に流れていくと、プロンプトが#に変わって、Linuxが走り出しました。これに、さらにコマンドをたった2回入力すると、PythonとMySQLがこの環境にインストールされました。 仮想化環境を普段使っている方には当たり前の事なのでしょうが、私にとっては、何か不思議な事が起きたような感覚です。ミラクルだ。 さて、仮想化技術を使って何が嬉しいかなのですが、汚れていないクリーンな環境を自分のパソコンと別に新たに作れる事でしょうか。しかもこの環境を保存する事が出来るようなのです。 よくあることですが、システム開発をしていると、だんだん環境が汚れてきます。モジュールやプログラムを何回もインストールして失敗したり、環境変数などの情報が含まれている大事なファイルを書き換えてしまったりします。 Dockerだと何回失敗してもやり直せるのでとても良いと思いました。 仮想化技術は今まで使う機会もあまりなく、食わず嫌いで縁がありませんでした。システムに限らず私たちの日常でもそうですが、何事もやってみないとわからないことがあるので、しかもやってみると意外に簡単だったりするので、なんでもやってみるのが大事だなと思いました。触ってみると何となくこんなものかということがわかります。
PythonでWebサービスを作る際にいくつかのフレームワークがあるようですが、DjangoがGoogleの検索数などでも一番メジャーのようです。 Pythonというプログラミング言語自体は好きだけど、フレームワークについて日本語の情報が少ないというのは、Pythonをやる人には共通の悩みだと思います。Amazonで本を探しても日本語の本がないんですよね、ちっとも。。PHPの本が他を圧倒していて、次にJava、その次がRubyで、PythonのWebサービスの作り方に関する本は新しいものはほとんど見当たりません。あっても、ちょっとしか書いてないんですよね。 でも、朗報です。 DjangoのTutorialには日本語のページがありました。Tutorialの部分は７ページくらいしかないので、本にしたらその３−4倍の30ページ分くらいのボリュームでしょうか。あまり多くはありませんが、役に立つ情報が多く載っていました。 https://docs.djangoproject.com/ja/1.10/intro/tutorial01/ modelを作って、 データベースに接続して、 URLの書き方とルーティングを設定して、 コントローラの書き方と、 ビューのテンプレートの指定の仕方と、 フレームワークを使うのに必要なことは一通り載っています。CakePHPやASP.NET MVCなどには一通り揃っているHtmlヘルパーの記事が載っていませんでしたが、これは作りながら探していくしかないでしょう。きっとありますよ。海外ではこれだけメジャーな言語ですから。。。 それと他のWebサービスの得意な言語（RubyやPHP）では必ずある簡単なCRUDをするページを一発で作る機能もこのチュートリアルには書いていませんでした。もしかしたら、Djangoにはないのでしょうか？ Djangoでもそうですが、フレームワークを使うとデータベースに接続する処理が、モデルを処理するコードで処理するだけで自動的にできるようになるため非常に簡単です。 DjangoでもMVCの構造を採用していますが、特にいいと思ったのが、フレームワークの設計上でモデルを唯一のデータ操作の入り口にしていることです。これだと、あちこちからデータを操作するコードが入り込む余地がなくなるので、特にデータベースのデータ構造を変更する際に、モデルを変更してマイグレーとさえすれば良いので、バグが入りにくくデータの仕様変更に強そうです。
結論から言うと、Webサービスで大規模になる可能性があり開発資源が潤沢にある場合はPython、個人やスタートアップの小企業が小さく速く始めたいならPHP、Webにする必要がなく計算やローカルPCでスクリプトに使うならPythonでしょうか。 スクリプト言語なんてみんな同じだと思っていませんでしたか？そうでもないですか？私は結構そう思っていました。今回、自分のプロジェクトをスクリプト言語で開発をやりたいと思ったので、Ruby、Python、PHPをそれぞれ20−30時間ずつ触って検証して見ました。ヒマですね。。というツッコミは置いておいて、ファーストインプレッションではありますが、自分ごとですので結構一生懸命評価してみました。 確かに、スクリプト言語の言語仕様だけ比べたらそれほど差はないのかもしれません。 でも、ローカルPCで使う場合にはライブラリの揃い具合で、それぞれの言語は全然違います。Webサービスも実際の開発にはフレームワークを使うので、どんなフレームワークがあるか、どのフレームワークを使いたいかで、選ぶべき言語は全然違います Ruby まず、Rubyは外しました。理由は、日本では人気がある言語ですが、世界的にはどちらかと言うとマイナー言語だからです。Googleの検索件数などの情報を見ても、世界的にはPythonやPHPの方が多いです。多分、使われている分量は5-7倍は違っていると思います。 Worldwide, Jan 2017 compared to a year ago: Rank Change Language Share Trend 1 Java 23.1 % -0.9 % 2 Python 14.4 % +2.7 % 3 PHP 9.7 % -1.0 % 4 C# 8.4 % -0.1 % 5 Javascript 7.7 % +0.5 % 6 C 7.1 % -0.3 % … Read More “Ruby、Python、PHPを実際に試してみた。どれを選べばいいのか。” »
Windows Serverを使わなくても良いWebサービス用の言語を始めたいと思ってRubyの本を買いに行ったのですが、本屋さんでは圧倒的にPythonの本の方が多かったです。 Pythonはマイナーな言語だと思っていたのですが、世界では圧倒的にRubyよりも使われているようですね。折しも機械学習というのが流行っていて、Pythonでは機械学習の世界的に有名なライブラリーが使えるからというのが、今これだけ流行っている理由のようです。この本は入門者向けですが、機械学習の記事までもが載っています。（ということは、ITサイエンスの専門家ではない私でも機械学習のことがわかってしまうのかしら。。？なんて嬉しい妄想を持ってしまいます。） Pythonは初めてだったのですが、この本でスクリプト言語について目からウロコが落ちました。スクリプト言語なんてライト級の言語だっていうし、あまり大したことは出来ないのではないかと思っていたのですが、大間違いでした。 昔、証券会社の同僚が面倒な数字の集計とかリスク管理の話をしていた時に、「パール（Perl）を使えば簡単だよ。」とかさかんに言ってたのですが、なんかその凄さがピンと来ていませんでした。きっとこういう事を言っていたのでしょう。実はスクリプト言語って多機能で色々できそうな上に、C#みたいなコンパイル言語と違って、思い立ったらちょっと書いて見てすぐ使えるので、便利そうですね。 筆者のクジラ飛行机さんの記事は日経ソフトウェアで読んでいて、お名前は知っていたのですが、この本はよかったです。細かい具体例がたくさんあり、実際に手を動かしてプログラムを動作させながら進めていけるようになっています。簡単なスクリプトの書き方はわかったような気にさせられました。こういう風にわかりやすく勘所を説明するのって大変なんだろうなあと思います。 余裕で元は取れますね。