Google App Engineで遊んでみる。２

　　　2. GAEのインストール

http://code.google.com/intl/ja/appengine/

まず、上記サイトからGAEのアカウントを作成する。
Googleのアカウントがあれば基本問題無いはず。
分かりにくいのはSMS認証のとこぐらいか。
キャリアを選んで携帯のメールを入力すると、
認証コードが携帯に送られてくるのでそれを入力するだけ。

アカウントを作ることでアプリをGAEにデプロイできるようになる。

アカウントができたら、開発環境を整備する。
具体的にはGAE SDKのインストール

http://code.google.com/intl/ja/appengine/downloads.html

↑のリンクからイメージをダウンロードして展開。
APPファイルがあるのでアプリケーションディレクトリにでも突っ込む。
で、実行。


/usr/local/binにシンボリックリンク貼る？って聞いてるので、OK。


貼れたらしい。
確認してみる。

[masato@mac] $ ll /usr/local/bin/*.py
lrwxr-xr-x   1 root  wheel  137  7 27 16:23 /usr/local/bin/appcfg.py -> /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/appcfg.py
lrwxr-xr-x   1 root  wheel  152  7 27 16:23 /usr/local/bin/bulkload_client.py -> /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/tools/bulkload_client.py
lrwxr-xr-x   1 root  wheel  144  7 27 16:23 /usr/local/bin/dev_appserver.py -> /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py
[masato@mac] $                                                                [~]

appcfg.py , bulkload_client.py , dev_appserver.pyが使えるようになっていればOK
こいつらを使って実際にデプロイ作業とかを行う。

とりあえず、これでインストールは完成。

　

Google App Engineで遊んでみる。１

Google App Engineで遊んでみるシリーズ

1. インストール、、、の前に
2. GAEのインストール
3. HelloWorldを動かしてみる
4. webapp framework
5. .....

今更な感じもあるが、GoogleAppEngine(以後GAE)で遊んでみる。

ちなみに、GAEとは、pythonで作ったWebアプリをGoogleのインフラ上で動かすことができるサービス。
現時点ではpythonのみだけど、今後はperlとかでも開発できるようになる・・・らしい。
AmazonのEC2に似た感じのサービスだけど、後発な分だけ色々と便利なようだ。とりあえず遊んでみる。
なお、このブログでは開発環境として、OSX10.4を利用する。

1. インストール、、、の前に

早速遊んでみたい所だけど、GAEを動かすためには、pythonのバージョンが2.5.2以上でなくてはならない。
うちのMacは、、、

[masato@mac] $ which python
/usr/bin/python
[masato@mac] $ python -V
Python 2.3.5

ということで全然だめ。
まずはpythonのインストールから始める。

http://www.python.org/download/
上記サイトでpython最新版のイメージをダウンロード。
中のインストーラを起動する。



終わったら確認してみる。

[masato@mac] $ which python
/usr/local/bin/python
[masato@mac] $ python -V
Python 2.5.2
[masato@mac] $

これでOK,バイナリの格納場所も変わったみたいだね。

次へ

レバレッジ勉強法 読破

リバレッジリーディングやリバレッジシンキングに続くリバレッジシリーズ。
リバレッジ勉強法とは又ストレートな題名だ。

この人の本に共通して言えることは、書中でも嫌というほど繰り返されている通り、

『対費用効果を最大にせよ。』

である。（ただし、費用は単純に金銭的なモノに限らず、時間なども含む）

本書も例に漏れず、勉強することの対費用効果を最大にするためにはどうしたら良いか、というテーマに沿って書かれている。
内容は大きくわけて、上記を意識的に行うことのポイントと、そのための具体的なハウツーに別れている。

読んでみてポイントだなーと思ったのは次の２点、

• ・目的意識をもって勉強する
• ・分野を集中して勉強する
  

ただなんとなく英語が必要そうだなぁ・・・と思って勉強をしてもなかなか続かない。勉強することにより発生するメリットを明確にしたうえでとりくむことが必要。うーん、耳がいたい。
また、ちょっとやる気が出たときには欲張ってあれもこれもとなりがちだけど、それも結局は続かない。目的意識を持ったならそれに集中するほうがリバレッジは高い。
言われてみれば全くその通りだが、普段はなかなか忘れてしまいがちな所だとおもう。


あと、ハウツーのところで、即使える。と思ったのは資格試験対策の所の

• ・勉強する前に過去問を解くべし

というところ。
勉強してないから当然とけるはずが無いのだが、問題にあらかじめ触れておくことで勉強しなくてはならないところと、勉強しなくてもいいところが明確になる。
これは、なるほど！と思った。

これ以外にもちょっとしたコツ的な内容も多いので、読んでみて損はないと思う。
文章量も多くないから通勤時間とかによいかな。

レバレッジ勉強法

posted with amazlet at 08.07.24

本田直之
大和書房
売り上げランキング: 4512

Amazon.co.jp で詳細を見る

PROLOGE　勉強とは「いつか役に立つ」ものではない
LEVERAGE.1　あなたの「ビジネス偏差値」は？
LEVERAGE.2　何を勉強するかを決める
LEVERAGE.3　ラクに勉強できる「仕組み」づくり
LEVERAGE.4　成果に直結するスケジューリング
LEVERAGE.5　どんな試験にも受かるテクニック
LEVERAGE.6　挫折しない英語マスター術
LEVERAGE.7　最速で情報を「勉強する」法
LEVERAGE.8　勉強しやすい環境をつくる

彼にGoogleは必要ないのか

同期と飲んだ時の話。

彼曰く、Googleは使えない。

• GoogleDocs

使えない。
アップロードしたらレイアウトが狂った。実用に堪えない。
そもそも容量制限があって役に立たない。
画像をいくつか貼ったPowerPointをアップロードできない。
どんな用途で使えというのか。

• GoogleMap

使えない。
VPNから接続したらAjaxがうまく動かなかった（？）。
ルート検索もできない。役に立たない。
ユーザビリティの面で言えば、既に他のサービスも同様のことができる。

• GoogleCalender

使えない。
仕事で使っているOutlookと同期がとれないようでは話にならない。
Excangeサーバを使っている以上GCalだけではなんともならん。
え？ソフトを介すれば？そんなの知らん。

• Gmail

使えない。
アーカイブしたら見えなくなってしまう。
仕分けルールでディレクトリごとにわけたほうが便利だ。
検索？それだったらOutlookだってできる。
２Gが無料？ローカルのOutlookだったら無制限だ。

• その他Goolgleのサービス

知らん。

• 検索エンジンとしてのGoolgle

ブログばっかり引っかかって使えない。
Yahooの方がましだ。

• で、でも、どこでも使えるってメリットがあるよ。

会社で使えないと話にならない。
むしろ会社以外で使えてもメリットにはならない。


ITを知らないおばちゃんの発言ではなく、それなりに活躍している（？）SEの発言です。

お前が使いこなせてないだけじゃないか。というのは簡単です、が。
もしかしたら俺らが無理をして使っているだけなのかもしれない。と感じた今日この頃。

俺らにしてみたら、そうやって最新のサービスを使うのは正直楽しいものですが、
それじゃエンドユーザはついてこないのかもしれない。

日本の検索エンジンの利用率、GoogleよりもYahooの方が高い理由がちょっとだけわかったきがします。

次世代メモツールとしてのEverNote

http://evernote.com/

しばらく使っているが、かなりいい。
次世代Webサービスの中でもかなりの『当たりサービス』なんじゃないかな。
googleの各種サービスと同じような印象を受ける。


ポイントを纏めてみる。まずはいいところ。

• プラットフォームにこだわらないところがいい。

WebでもWindowsでもはたまたiPhoneでも使える。（ただしMacはOSX10.5以上必須・・・（T-T）
これだけのためにiPhoneを買おうかと思ったぐらい。
まさに、『どこでも』メモがとれる。メモツールとして、この『どこでも』というのはかなり重要なポイントなんじゃないだろうか。

• メモの形式にこだわらないところがいい。

テキストはもちろん、画像や音声でもメモが取れる。
そしてそれらを一元管理できてしまう。テキストだけのメモツールならたくさんあるが、画像も管理できるのはなかなかないのでは？
画像が使えることで、iPhoneとの親和性がかなり高くなってる気がする。
あー、まじでiPhone欲しい。

• 管理の仕方がいい。

最近のWebサービスではもはや常識的ともいえる管理体系、『タグを付けて』『検索する』。
evernoteではきちんとこの仕組みを踏襲している。
有料版では、画像内の文字検索までしてくれるようだ。

悪いところとしては。

• ツールのユーザビリティがまだまだ。

webツールはAjaxを基本とした作りになっているようだが、直感的な操作性とまでは行っていない気がする。たまにjavascriptのエラーが起こるのもイマイチ。
Windows版クライアントの操作性も改善の余地あり。特に日本語との親和性が良くないらしく、テキスト入力をしているときの挙動が少し怪しい。
OSX版クライアントはバージョンの問題で動かせなかった。残念。


改善して欲しいところはいくつもあるものの、コンセプトが非常に素晴らしいサービスだと思う。有料版へのアップグレードも念頭に置きつつしばらく使ってみたい。

なお、inviteはいくつか余っているので、コメントかメールで言ってくれれば招待します。

アーキテクチャとはなんであろう。

かの有名な ぼそっと にて色々と興味深い見解を述べられていたのでノッてみる。
（chiba_さんごめんなさい）


http://d.hatena.ne.jp/chiba_mk3/20080714/1216050596
http://d.hatena.ne.jp/chiba_mk3/20080715/1216135665

まず、俺が思うアーキテクチャ

アーキテクチャとは、構造である。

構成じゃなくて構造だと思います。少なくともITアーキテクチャについては。言葉遊びですけど。
この言葉って「構造化プログラミング」から来てると思うんですよね。

構造化プログラミングは、順次・分岐・繰り返しのみでプログラムするってのがポイントですが、それに加えて、システムを機能単位で分割して組み合わせる、という意味もあります。
サブルーチンの概念ですね。
この「機能単位で分割されたものを組み合わせる」という概念はOOPでもAOPでも変わりません。つまり、現在作られてるシステムはほぼ全て「構造化された」システムである、と言えると思います。

よって俺は、

構造化されたシステムの構造のことを、我々はアーキテクチャと呼んでいる。

と考えます。

つまり、コンポーネントだったりサブルーチンだったりはたまたクラスだったりの組み合わせ方。がシステムのアーキテクチャである。

と私は考えます。

さて、ここまでを踏まえて、俺が違和感を感じたところはここです。

やっぱり、そもそもの言葉の意味的に考えると、「アプリケーション・アーキテクチャの確定＝各問題領域毎のフレームワーク・コンポーネントを組み合わせて要件に適したフルスタックフレームワークを構築すること」と考えても差し支え無いような気がしてきました。

フレームワークを構築することは、アーキテクチャを確定させることの一部でしかないと思うんです。俺は。
確かにフレームワークを確定させれば、システムの大枠は決まります。
でもフレームワークが担うのはあくまで汎用的な機能だったり処理パターンであって、システム独自の機能というのは別途開発しなくてはならないはずです。
その独自の機能のところの構造まで確定させて初めて、アーキテクチャの確定と言えると思います。
全部作れ。と言ってるわけではないです。
インターフェースで下位のクラスの挙動を束縛したり、UML等で概要だけ決めたり、代表的なところだけ作って後はそれを模倣させたり、と構造を確定させる手段は色々とあると思います。
ここまでやらないといけないから、アーキテクトって大変なんですね。多分。


と、俺の理想とするアーキテクト像を元に、言いたいこと言ってみました。

若干後悔していますが、異論もお叱りも認めます。ごめんなさい。

泥カンなんつーもんがあったらしい。

昨日あったらしい。今日知った。

http://www.atmarkit.co.jp/news/200807/14/todai.html

SIerしか知らないので、興味はそこに集中するんだけど、なんじゃこりゃって感じ。
「SIerはウェディングプランナーのようなもの」ですか・・・。
「管理業務がSIerのメインの仕事」ですか・・・。


俺の所感では、
SIerって、非常に幅の広い仕事だと思うんだよね。
お客にシステムを導入するのが仕事でしょ？
そのためには当然管理も必要だし、仕様を固めることも必要だろう。
でもそれがメインじゃなくね？
ベンダーを利用するならその知識も必要になってくる。
自分で作るなら作れるだけの技術も必要だろ。
作って終わりじゃなくて保守もしないといけないだろうし。
そこまで全て踏まえた上でのインテグレーションじゃないのか？
プランニングだけして丸投げするのがSIなのか？

と、ここまで書いて、もしかしたら＠ITに情報操作を食らってるだけなのかもしれないと思い、ほかの人のブログを色々と見ると・・・非常によく纏まったブログを発見。西岡さんblogより

http://nishioka-blog.com/2008/07/it.html

SI代表として。

• たとえばSIerはウェディングプランナーみたいなもの。
• SIは開発のみじゃない。営業とか企画とか全部あわせてのこと。
• 物を作るところで全体を管理している。マネージメントしている。

＠ITの記事よりは、納得できる発言。
　（開発だけではなくて）マネージメント中心になるよね。
というニュアンスだったのかもしれない。

そういう言い方だと、確かに現状として否定できない部分は多い。
前職でもみんな画一的に、
「技術はそれなりに押さえつつ、目標はマネージャーです！」
って声を大にして言っちゃう人、多かったし。

個人的には非常に不満かつ不安だけど、それが日本のSIerなのかなぁ。
でもそれって情報部門とかシステム子会社の役割じゃないの？
そんなSIerって、必要なの？

フレームワークの弊害かも

初めて仕事でJavaを使った時には既にStrutsが使われていて、
実際のところServlet,JSP,JavaBeansを使ったMVCモデルなアーキテクチャって作ったことがない。
作ったことがないどころか、多分これからも作ることはない気がする。

別にMVCモデルに限定した話じゃなくて、
たとえば、データアクセスとかもjdbcでばりばりコーディングすることはないだろう。

これってかなりやばくない？
本質、わかってなくない？
jdbcでトランザクション管理とか組めるのか？俺。

という危機感を最近感じる。

問題解決について

俺が考えている問題解決の手順。
あくまで、『俺流』であることに注意。
最後にも書いたけど、俺自身この手順を踏まないことも多いしね。

• １．問題・状況の明確化

まず、何が起こっているのかを正しく把握する。
「よくわからないけど、動きません。バグってます。おかしいです。」の状況は最悪。
この状態が最悪な理由は、顧客（ユーザ）に対して説明ができないことにある。
上のセリフを客に行ったら、多分キレる。少なくとも俺ならキレる。
どのような際に起こった問題なのか。
期待すべき結果はどうだったのか。
期待すべき結果と比べ、どのような違いがあるのか。
という観点から、起こった事象を論理的に纏める。

• ２. 原因の推定

上で纏めた事象から、原因と思われる箇所をいくつかピックアップする。
ここでピックアップする箇所は、当然のことながら少ないほうが良いのだが、漏れが怖いため、できる限り多めに選ぶ。
原因と思われる箇所を選ぶ、というよりは、決して原因になりえない箇所を消していくという消去法のほうが良いかもしれない。
また、原因となりうる箇所は一ヶ所とは限らない。
複数の箇所が、相互に作用したうえで問題の原因となっている場合もある。

• ３. 状況と原因の結びつけ

上記でいくつか絞った原因の候補群と、実際に起こっている現象の結びつけを行う。

「Aという箇所に○○の問題があったため、次処理にて不具合を起こしたと思われる」

「Aという箇所では○○を出力する可能性があるが、Bではそれを想定していないため、結果に不具合が生じたと思われる」

のように段階を踏んだストーリー的に表せるとよい。
ここでの仮定は３段論法にならないよう注意すること。
ここまできてようやく顧客にまともな説明ができるようになる。
また、この後の作業についても顧客からの理解が得やすくなる。
そのため、作業量は多いが、可及的速やかにここまでこなす必要がある。

• ４．裏取り

上で挙げた仮定を実証する。
ここまで来てようやく実際に手を動かすわけだが、やみくもに原因と思われる箇所に
手を加えることはできるだけ避けること。
問題を解決しなければいけないという逸る気持ちは抑え、上の仮定を実証することに全力を注ぐ。
この際、できればテストシナリオを作成し、それに沿って作業を行うとよい。

「Aという箇所に○○のような修正を加えた場合、仮定１が正しければ結果はBになるし、正しくなければ結果はCになる。」

のようなシナリオをいくつか作成し、実際に作業を行うことでいくつかあった仮定を絞り込んでゆく。
最終的に仮定が１つになれば、それがこの問題の原因であると言えるわけである。
また、ここまでくれば大概は問題に対する解決案もいくつかでてくることと思う。

• ５. 問題の解決

ここまでで導かれた問題・状況とそれに対するいくつかの解決案を顧客に提示し、実際に行う解決法を選択してもらう。
あとは何も考えず、手を動かせばよい。

• おまけ

実際問題として、ここまでの手順をきちんと踏まなくてはならないということはない。
事象を聞いた時点で原因が思いつく場合は多々あるし、それが正しいことは日常茶飯事である。
問題解決はスピードが命なので、即解決ができるのであれば、上のような面倒な手順を追うことは時間の無駄とも言える。
ただ、何をしてよいかわからず、ただやみくもに手を動かすよりは一つ一つの手順をおって行ったほうが
解決は早いし、顧客への説明もやりやすくなる。
状況に応じて使い分けることが必要と言える。

plaxoを試してみる。

http://www.plaxo.com/

最近暇なので似たようなサービスをいろいろ登録している。
brightkiteとかFacebookとかplaxoとか。

とはいっても周りで使ってる人があまりいないので
あくまで自己満足のレベル。

ただ、plaxoはかなりいい。
何がいいって。カレンダーの同期機能がうれしい。
google Calenderとicalとoutlookでバッチリ同期をかけてくれるし
インターフェースもかなり分かりやすい。

カレンダー同期サービスと割り切って使うのもアリかもしれない。

ロジカルライティング読了

積ん読消化月間。今日はロジカルライティングを読んだ。
全体の流れとしては、

• ロジカルシンキング基礎
• ロジカルシンキングで纏めた内容を文書化
• モノを書く上でのテクニック

という流れ。
内容としては、今更・・・的なものも多いけれど、ボリュームも少ないので一度読んでおくのはアリかな。

気になったポイントを備忘。

• 読んだ人に対して、自分のする行動をとってもらえるようなドキュメントをかく。
• MECEのフレームワーク一例
• 　・自社の現状をとらえる３C（競合[Conpetitor]・顧客や市場[Customer]・自社[Company])　
• 　・マーケティングの４P（サービスの特徴[Product]・価格[Price]・訴求方法[Promotion]・販売チャネル[Plice])

とりあえずこのフレームワークは俺が書くようなドキュメントではちょっと役に立たないかも。
実際にモノをかくうえで自分なりのフレームワーク的なものを考えてみたい感じ。

• 論理の組み立て「結論から根拠へ」　→　書き手にとって結論が明確であり、根拠もだいたいわかっている場合。
• 論理の組み立て「根拠から結論へ」　→　多量の情報はあるが、結論と根拠が曖昧

結論が曖昧である場合はテーマの再定義や細分化が必要なのでは？

• 論理の組み立てを行う際には、各項目の独立性及び項目間のつながりに注意する。

項目を単体で読んだときに理解できること。下位の項目が上位の項目の根拠になっていること。

• 結論を先に書くか、論拠を先に書くか。

読み手に伝えたい方・読み手が求めている方を先に書く。根拠から結論を導く過程を伝えたい場合は根拠から書く場合もある。

• 導入部には当該ドキュメントの存在理由を書く。
• 導入部には読後、読者が起こして欲しいアクションを書く。
• 記号やスペースなどを利用して視覚化する。
• 同レベルのセンテンスはMECEの関係に
  
• センテンスの上下関係はSo Whatの関係に
• 付帯条件について、「場合によっては」という曖昧な書き方ではなく、具体的な条件を書く。
• 曖昧な言葉に注意する。３文字略語や業界用語に注意。
• 体言止めを使うと単なるキーワードの列挙になりがちで、重要な情報が抜けやすいので注意する。
• 否定形で終わると抽象的になりやすいので注意する。肯定形で具体的に。

「AはBではない。」→「じゃあAはなに？」

• 「〜は以下の通り」のような表現には注意する。その後に細かい情報を箇条書きなどで書く場合でも概要をきちんと書いておくべき。
• 「〜により、」を多用すると一文が長くなり、結果読みにくくなる。
• 「〜される」のような受動態を使うよりも、能動態にしたほうが主語がはっきりして分かりやすい。
  

ロジカルじゃないな〜（汗

マインドマップが使えない

某マンガで取り上げられたり、自己啓発本が結構出たりして、それなりに周知されてきたマインドマップ。

俺にはどーにも使えない。

思考をそのまま紙にかくから纏めやすい、と聞くけど、あの放射状な感じが俺の思考とは相いれない感じ。

論理展開って普通左から右に、上から下に流れてくもんじゃないの？放射状じゃなくない？

俺みたいな凡人だからそうなのであって、天才肌にはしっくりくるものなのかもしれないけど、俺にはどうにもある種の窮屈さがかんじられちゃうんだよなぁ。

tumblr

tumblrをちょっと使って見ている。

twitterとおんなじようなもんだろうと思ってたけど、実際に使ってみてコンセプトの違いに気がついた。
twitterもtumblrもミニブログとか言われているけど、
両者の違いは、情報の発生元にあるのかなぁとなんなく思ってる。

twitterはつぶやき、つまり自分からの情報を出力するけど、tumblrはもともとwebに公開されている情報を再出力する感じ。再出力というよりは、新聞の切り抜きにちかいかもしれない。

まぁ何はともあれ実際に使ってみるとなかなか楽しいサービスだった。いまさらだけど。

クロージャとオブジェクト指向とJava

クロージャがイマイチ理解できない。
全く理解できないわけじゃないけど、でっていう感じ。


とりあえず、俺の理解的には、
宣言時の変数（状態？）のスコープを引き継ぐ高階関数
だと思っている。

関数ポインタとの最大の違いはスコープを引き継ぐところだというのはわかるんだけど。

結局、状態をもつ関数ってことなんだから、オブジェクトじゃないの？と思ってしまう。

Java７で導入されるみたいだからそれまでに理解しておきたいんだが・・・。

rubyとかで実際に使ってないと難しいかなぁ。

とりあえず、「ふつうのHaskell」は読み終わった。

サンプルも書いた。
でも、ぶっちゃけよくわからんよ、Haskell。

とりあえず、fizzbuzz問題でも解いてみる。れんしゅう。


** 1から100までの数字を列挙。ただし、３の倍数の時はfizz、5の倍数の時はbuzz、15の倍数の時はfizzbuzz。

普通の言語で組むなら100まで回したループの内部で条件分岐、って考えるのがシンプルだが。
haskellループないし。
1から100までのリストを用意して各要素に対してfizzbuzzな関数を適用して出力。かなぁ。

とりあえず1から100までのリストを出してみる。
>|haskell|
main = putStr [1..100]
||< 怒られた。putStrにリストは渡せないか。じゃあ、リストを展開して出すか。 >|haskell|
main = putStr unlines [1..100]
||< 怒られた。unlinesは文字列のリストじゃないとダメか。 >|haskell|
main = print [1..100]
||< でた。んー。最終的な出力形式をどうするかって問題がありそげだけど、とりあえずこれでいいか。 ふむ。入力はIntのリストだけど、出力にはfizzやらbuzzやらが入るんだから、Stringのリストになるのか。 つーことは、fizzbuzz関数の型は [Int] -> [String] か。
とりあえず、fizzbuzz関数を組み込んでみる。

>|haskell|
main = print $ fizzbuzz [1..100]

fizzbuzz :: [Int] -> [String]
fizzbuzz cs = map show cs
||< 問答無用でshow関数使ってIntをStringに変えちゃってるけど、ここに条件入れればおけかな。 >|haskell|
main = print $ fuzzbizz [1..100]

fuzzbizz :: [Int] -> [String]
fuzzbizz cs = map test cs
where
test c = if c `mod` 15 == 0 then "fizzbuzz" else
if c `mod` 5 == 0 then "buzz" else
if c `mod` 3 == 0 then "fizz" else show c
||< でけた。次。 ** 素数を出す。 Haskellとかすごい得意そうな問題だな。 んー。考え方としては、２以上の数のリストを用意して （１が入ると面倒なので） そのリストから先頭一つをとって、その数で割れるかどうかのフィルタリングをして、ってかんじかなー。 こんな感じ？ 2, [ 3, 4, 5, 6, ...] →のリストに対して2で割れないモノだけ抽出するフィルタをかけると 2, [ 3, 5, 7, 9, ...] そしたら、→のリストに同じことを繰り返してく。 2, 3, [ 5, 7, 11, ... ] →のリストがなくなるまで続けて、最後に連結して終わり。 調べればもっと効率的な解法がありそうだけど、とりあえずこれで組んでみる。 >|haskell|
main = print $ prime [2..100]

prime :: [Int] -> [Int]
prime [] = []
prime (x:xs) = x : ( prime $ filter check xs )
where
check c = if c `mod` x /= 0 then True else False
||<>|haskell|
main = print $ prime [2..100]

prime :: [Int] -> [Int]
prime [] = []
prime (x:xs) = x : prime [ c | c <- xs, c `mod` x /= 0 ]
||<

こんなもんかな。

http://d.hatena.ne.jp/masato_spica/20080609