リーン・スタートアップ教をめぐる宗教論争 - ふろむだ＠分裂勘違い君劇場
「PayPal創業者のピーターティールがリーン・スタートアップを完全否定した」と言われている。 ティールは単なる一発屋ではなく、その後も投資家としてfacebookなどに出資して成功しているということもあって、これは結構話題になった。 彼の書いた本を確認してみると、たしかに、多くのリーン・スタートアップ教信者の神経を逆なでするようなことが描かれている。 ティールが批判したのは、現在のシリコンバレー起業家にありがちな以下の４つの考え方だ。 (1)少しずつ段階的に前進すること：壮大なビジョンがドットコム・バブルを引き起こした。だから自分に酔ってはいけない。大口をたたく人間は怪しい。世界を変えたいなら謙虚でなければいけない。小さく段階的な歩みだけが安全だ。 (2)無駄なく柔軟であること：ビジネスの先行きは誰にもわからない。だから計画を作って計画通りにやるのは柔軟性に欠ける。試行錯誤を繰り返し、先
いま最も進化しているウェブベースのタスク管理サービス、Flow (1)
ふだん OmniFocus で仕事の管理をおこなうことが多いのですが、認めましょう、実はかなり無理しています。 というのは OmniFocus は GTD の「プロジェクト・コンテキスト」のマッピングや、パースペクティブといったものをかなり忠実にアプリケーション化していますので、利用するのはとても複雑で慣れを必要とするからです。 また、タスク管理がデスクトップのアプリ側を中心としている点も、時として面倒です。 OmniFocusのデータはiDiskを経由して外のMacにも、iPhoneからも読めますが、やはりデータがどこにあるかというと複数あるMacのうちのどれかということになり、ブラウザ一つあればどこでも読めるクラウド型のタスク管理システムを利用したくなることはよくあります。 そこでいま本気で乗り換えようかと期待しているのが先日一般への公開が始まった Flow です。 Flow の特徴
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
