Subscribed unsubscribe Subscribe Subscribe

ハーバード大学哲学科が教える、哲学を学ぶ理由

ハーバード大学哲学科のサイトにあった「なぜ哲学を学ぶのか」があまりに良かったので、精度が上がったという評判のGoogle翻訳を試すついでに訳してみました*1

僕も大学で哲学を勉強していました。もはや半可通でしかないのですが*2、後半にある「哲学があなたに教えるスキル」は僕が仕事をする上で全ての基礎になっています。哲学を勉強してよかった。

原文はこちら。訂正などありましたら是非コメントください。

Why Study Philosophy? | Harvard University Department of Philosophy


カリフォルニア大学バークレー校の哲学者であるジョン・キャンベルは、哲学についてこう考えていますー「それは、私たちがふだん凄いスピードで行っていることを分解し、説明し、評価する。すると、別の選択肢が可能であることがあきらかになる」。

哲学を学ぶことは、何千年もの間人類を悩ませてきた問いに、過去存在した偉大な思想家たちとの対話を通じて取り組むことです。1つ2つの授業を取る、集中して哲学を学ぶ、どちらの場合も、生徒たちは哲学を学ぶことが大学生活で最も有益な知的体験であることを知ります。哲学を研究する主な理由は、反省と熟考の本質的な価値を知ることです。

それにもかかわらず、哲学に惹かれている多くの学部生は、哲学の学位は貧困への道だと心配しています。しかし実際のところ、哲学を学ぶことで得られるスキルは、不安定かつ急速に変化する経済環境の中で、高い市場価値があります。多くの特化したスキルは最終的に時代遅れになり、いずれの場合でもほとんどの人は人生の中で何度もキャリアを変えてしまいます。哲学があなたに教えるスキルは、常に需要が高いはずです。明快に思考し、書くこと。認識されていない前提を明らかにすること。複雑なアイデアを明快に説明すること。つながりと含意を解きほぐすこと。幅広い文脈で物事をとらえること。慣習に挑戦すること。一言で言えば、哲学はどんな業種でも適用できるスキルを提供します。

ハーバード大学の哲学専攻生は、多様で価値あるキャリアを追求してきました。哲学の卒業生は、法律、財務およびコンサルティング、ビジネス、インターネットのスタートアップ、医学、ジャーナリズム、芸術、非営利の仕事、教育、学術(哲学と他の学問分野の両方)で成功を収めています。あなた自身に問うべき質問は「私は哲学の学位で何ができますか?」ではなく、「私が哲学の学位でできないことは何でしょうか?」でしょう。

*1:Google翻訳したものを自分で直しました。文体が不自然だったり、なぜか訳出されない箇所があったりで、結構直した

*2:先日学部の友人と話していて「藤村君が学生の頃とは常識が変わった」と言われました。ですよねー。いつかじっくり時間をとってキャッチアップを試みたい

起業してました&エンジニア募集しています

近況報告としては、退職のご報告からすっかり間が空きました。TechCrunch東京新聞の記事で既にご存知の方もいらっしゃるかもしれませんが、2015年10月にProper, Inc.を共同創業し、現在「近所のつながりを通して、地域の課題を解決する」というミッションのもと、ご近所SNSマチマチを運営しています。

前職をやめてからは結構悩みましたが、こういう時は一番ハードルが高くてテンションが上がるやつを選ぶべきだ!ということで「自分でやる」って選択肢を選びました。パートナーは、直近だとOh My Glassesをやっていた六人部生馬です。複数のスタートアップを経験している、Rubyistと仕事をしている、神奈川出身であるなど共感できるところが多々ありつつキャラ的にも能力的にも補完的という、良いチームになりました。

今、マチマチの開発チームは、現在エンジニア1人(僕)デザイナー1人(元山さん)の2人です。まだまだやるべきことが満足のいくスピードでやれていない状況です。また、現状Web版だけのマチマチですが、多くの方からアプリ化の要望を頂いています。ということで、一緒に働く仲間を募集することにしました。具体的にはWebエンジニア、iOSエンジニア、Androidエンジニアに加えて、ビジネス側のメンバーを募集しています。下にWantedlyのリンクを貼っているので、詳細はそちらをご覧ください。

話は変わりますが、新しい事業を始めるにあたって最も重要な事は「適切な事業領域を選ぶこと」だと思います。

日本は、高齢化、過疎化、少子化、厳しい子育て環境、衰退しつつある地域コミュニティと、大きな課題をいくつも抱えた課題先進国です。また、ベーシック・インカム地域通貨などの新しい再分配のあり方の登場、シェアリング・エコノミーの浸透による家事、買い物など生活スタイルの進化、ライドシェア、自動運転車などで変わる都市における移動と距離感、スマートシティと呼ばれる電力、エネルギーの技術革新など、いま社会には多くの変化が訪れています。

そして、これらの課題・変化、すべて具体的には「地域」で起こっていることです。

ここ、僕らの持っている人生の貴重な時間を使う先として、課題としてのサイズと意義は十分ではないでしょうか。テクノロジーで改善できる事は沢山あります。時間とエネルギーと熱意をつぎ込むに値する、魅力あるフィールドだと思います。僕達はこの領域に対し「つながり」という軸で手を打ちはじめました。

ちょっと熱くなってしまいましたが、そんな感じで面白い事をやっています。良い経営チームとめちゃくちゃ面白い問題は用意できたと思うので、いいチームといいエンジニアリングで、どんどん問題を解いて行きましょう。ぜひみなさんの力を貸してください。

少しでも面白いと思ったら、下記のWantedly、 daisuke.fujimura@proper-inc.com 、各種ソーシャルアカウントでお気軽にご連絡頂ければと思います。みなさんお忙しいと思うのでランチでも行きましょう。転職考えてない人も歓迎です。なお、マチマチの技術的な側面については末尾に付録としてまとめておきましたのでご笑覧ください。

あと、Forkwellさんのミートアップでパネルディスカッションに参加させて頂きます。是非お越しください!

forkwell.connpass.com

直前ですが、Haskell Dayでチュートリアルのチューターをやる予定です。こちらも是非!Simon Payton Jonesさんが来ます!

connpass.com


付録: マチマチを支える技術 ダイジェスト版

現状、主要なコンポーネント

という構成でやっています。サービスの初期ということで、仕様の変化が多く、かつ長期的なコードベースへの影響が大きいので、なるべく素直な構成とコードを心がけています。変更しやすいよう、テストは割と手厚く書いています。

その他、やってることや特徴をピックアップすると、下記のような感じです。

  • GitHub上の全ブランチをデプロイして動作確認できるようにしている
  • 開発用のミドルウェア(DBとか)はdocker-composeで管理
  • End to endテストは書く。それと重複してもなるべくモデルのテストは書く
  • Reactのコンポーネントもある程度はテストを書く
    • End to endテストでカバー出来ているけど、書いたほうが再利用性が上がる
  • ES6, Babel, Browserify, mocha, jsdom, Enzyme, sinon, power-assert
  • 定期実行は全てJenkinsから。cronは使わない
  • 依存ライブラリ(Gem, npm)はJenkinsからPR出して自動でアップデート
  • コードフォーマットはeslint, Rubocopを使ってJenkinsでPR出して自動で修正
  • データ分析はBigQueryとre:dash。データベースとMixpanelからEmbulkを使ってインポートしている
  • Railsカバレッジは95%以上、JavaScript単体は25%程度

機能開発以外の今後の課題は

  • Herokuへのリクエストの太平洋超えレイテンシをなんとかしたいけど、開発効率が良いのでやめたくない
  • 地図データがきれいに揃っていないので整えたい
  • やがてやってくる通知の再実装問題
  • jbuilder遅い

など。興味ある事や知りたい事があったら可能な限りいくらでも情報開示します。気軽に聞いてください。

クリスマスイブに聞く本格ブラックメタル

METALバンド Advent Calendar 2015の24日目の記事です。担当がクリスマスイブになったのは偶然です。

詳しい説明はしませんが、それぞれその時代と国を代表する正統派ブラックメタルバンドです。恐らく本気でブラックメタルを聞いていた人は誰も文句を言わない、ブラックメタルという音楽の本質を味わえるチョイスだと思います*1

しかし、ここまで人間のダークサイドにフォーカスした音楽が他にあるでしょうか!?改めて聴いて震えました。カーテンを閉じ、部屋の照明を全て消し、大音量で聞いてください!

1995, France

www.youtube.com

1989, Hungary

www.youtube.com

1993, United States

www.youtube.com

1994, Sweden

www.youtube.com

1994, Norway

www.youtube.com

1986, Sweden

www.youtube.com

1991, Swiss

www.youtube.com

2001, France

www.youtube.com

*1:入れたかったけど量的に割愛したバンドが沢山います。BurzumとかKatharsisとかSarcofagoとか。

Hspecベストプラクティス

Hspecベストプラクティス

Haskell Advent Calendar 2015 の14日目のエントリーです。

イントロ

HspecHaskellコミュニティにすっかり受け入れられたテスティングフレームワークと言ってよいかと思います。しかし!まだ確たるベストプラクティスは無いと言えるのではないでしょうか!

Hspecの元となったRSpecRubyコミュニティでデファクト・スタンダードとなっており、ベストプラクティスの蓄積があります。これを、Haskellの事情を鑑みつつ適用してみようという記事です。

ではないので、その辺りは別の記事を読んでください。

あと、オフィシャルのexampleがあるので、これに先に目を通しておくと話が早いかもしれません。

気になる点、賛同できないプラクティス、改善点などありましたら、是非コメントで教えてください。

では始めます!

一般的なディレクトリ構造に従う

  • 一つのソースファイルに一つのスペック
  • ファイル名はSpec.hsで終える
  • ソースコードのディレクトリ構造に対応させる

が慣用的です。 例えば src/Foo.hsのSpecはtest/FooSpec.hssrc/Data/Bar.hstest/Data/BarSpec.hsとなります。

hspec-discoverでテストスイートをまとめる

複数あるテストを一つのテストスイートにまとめるのは結構面倒です。 上記の命名規則(Spec.hsでファイル名が終わる)に従い、各ファイルでspec :: Specをエクスポートしておけば、hspec-discoverが規約に沿ったファイルから自動的にテストスイートを作ってくれます。

下記のようにファイルを作っておけば $ stack testできるはず。

test/Spec.hs:

{-# OPTIONS_GHC -F -pgmF hspec-discover #-}

foo.cabal:

test-suite foo-test
    main-is: Spec.hs

それぞれの関数について、振る舞いの説明をする

describeで説明する関数を宣言し、itでその振る舞いを説明します。

例:

describe "Foo.bar" $
  it "should return multiple of given number" $ do
    Foo.bar 4 `shouldBe` 8

contextを活用する

contextに文脈を書くと整理されたテストスイートになります。

describe "Foo.baz" $
  context "when [] was given" $ do
    it "should return Nothing" $ do
      Foo.baz [] `shouldBe` Nothing

  context "when [1] was given" $ do
    it "should return Just 1" $ do
      Foo.baz [1] `shouldBe` Just 1

一つのテストで一つの振る舞いを確認する

複数の振る舞いを確認すると失敗するテストを見つけるのが難しくなります。

テストが遅くなりすぎる場合は複数の振る舞いを検証するのもアリです。

Good:

describe "Logger.log" $
  it "should write log to log file" $ do
    -- 省略
  it "should write log to stdout" $ do
    -- 省略

Bad:

describe "Logger.log" $
  it "should write log to log file and stdout" $ do
    -- 省略

テストをあまり抽象化しない

BDDはソフトウェアの振る舞いを記述するための手法です。多少冗長でも、記述された振る舞いの読みやすさを優先したほうがよいです。

ちょっといい例が思いつかないので、瑣末な例で。

describe "Foo.baz" $ do
  forM_ ["cat", "dog", "snake"] $ \name -> do
    context "with '" ++ name ++ "'" $ do
      it "should return " ++  name ++ "-chan" $ do
        -- 省略

describe "Foo.baz" $ do
  context "with 'cat'" $ do
    it "should return cat-chan" $ do
      -- 省略
  context "with 'dog'" $ do
    it "should return dog-chan" $ do
      -- 省略
  context "with 'snake'" $ do
    it "should return snake-chan" $ do
      -- 省略

としておいた方がよいです。前者の例はコードから振る舞いを読み取れません。BDDのテストコードは抽象化の対象ではなくソフトウェアの振る舞いを記述するものである、ということを心に留めておきましょう。

今年の24 days of HackageでHspecが取り上げられており、コメント欄でYesodやPersistentのメンテナーであるGregさんもテストの抽象化には反対していました。

とはいえ現実世界では、読みやすい抽象化をすればいいのでは?とか、さすがにボイラープレートコードが多すぎる、とか、悩ましい状況は発生します。適度にルールを破る分には良いかと。

マッチャーを知る

shouldBeshouldReturnなどをマッチャーと言います。これはそんなに数多くないので、一度目を通すとよいです。 ドキュメントはこちら にあります*1

GHCIでテストする

module FooSpec (main, spec) where

main :: IO ()
main = hspec spec

spec :: Spec
spec = describe "Foo.bar" $ do
  -- 省略

というようにmainspecをexposeしておくと、

$ stack ghci
λ import qualified FooSpec  
λ FooSpec.main
Foo.bar
  should return something
Foo.baz
  should do something

という具合にGHCiの中でテストを実行できます。$ stack test より GHCiの中でreload! するほうが早いのでオススメ。

便利なライブラリがある

一時ディレクトリ、一時ファイルの利用はMockeryが便利です。またSilentlyを使うと標準入出力をキャプチャできます。

WAIにはhspec-wai、Snapにはhspec-snapがあります。ちなみに僕はhspec-waiの作者の一人です。

まとめというか所感

Hspecいいソフトウェアだと思います。型がリッチな言語とふわっと振る舞いからコードを育てるBDDの相性がめちゃくちゃ良い。doctestと併用して、(Type|Test|Behaviour) Driven Developmentは捗ります。

あと、他にもRSpecのベストプラクティスをパクれるところは沢山あると思うので、RubyわかるHaskeller諸氏は是非参考にしてみてください。ちなみにRSpecを長年メンテしてたDavid ChelimskyさんはClojureの人になってしまいました。悲しいですね!

リンク集

本家

この記事の元ネタ

RSpecについて:

Hspecについて

*1:ちなみに中置記法があるおかげでRSpecのようにshould/expect論争がないです。

Haskellでなぜストリーム処理ライブラリが必要なのか

関数型ストリーム処理勉強会で発表したので、ブログにも書いておきます。

元になった資料はこちら

Haskellでストリームデータを扱う方法としては、Handleを使う方法、Lazy IOがありました。しかし、それぞれに問題があり、再利用性が高く堅牢なコードを書くことは困難でした。

この状況を解決すべく、ConduitPipesio-streamsなどのストリーム処理ライブラリが現れたのですが、そもそもそれらが必要とされた経緯は具体的にはどのようなものだったのでしょうか?

元ネタ: http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdf

ソースコード: https://github.com/fujimura/functional-stream-processing-meetup-sample

そもそもストリームとは

必要に応じて処理されるデータの連なりのこと。具体的には標準入力、ファイル、ソケットなど。

上記の定義はScheme実装提案書より。 この定義では入力側をストリームと読んでいますが、出力側(標準出力への書き込みなど)もストリームとして扱われてる場合が多い気がします。

ストリームは多くの場合、IOです。

具体例

200MBのテキストファイルに含まれる空白文字の数を調べる、という例で比較します。200MBのファイルを一気にメモリ上に読み込むのは効率的とは言えません。ストリーム処理の出番です。

Lazy IOの場合

run :: FilePath -> IO ()
run fname = do
  file <- Text.Lazy.readFile fname
  print (countWhiteSpace file)

countWhiteSpace :: Text -> Int
countWhiteSpace = fromIntegral . Text.Lazy.length . Text.Lazy.filter isSpace
  • 良いところ
    • 単純でわかりやすい
  • 悪いところ
    • 純粋な関数で例外が起こる
      • readFileで読んだファイルに不正なバイト列が含まれていた場合は例外が起こります。そして、Haskellは遅延評価なので、値は必要になった時に評価され、例外は評価時に発生します。つまり、評価されるまで例外は発生しないのです!この性質により、なんと純粋な関数で例外が起こることがあります。これのデバッグは非常に難しいです。
      • 具体的には上記のコードの場合、Text.Lazy.filterで不正なバイト列が評価される時に発生します。
    • いつ、どれだけファイルが開かれ、開放されるか予測しにくい
      • 上記と同じ理由でファイルが開放されるタイミングも単純には予測できません*1。また大量のファイルが同時に開かれてしまう場合もあります。

Handleの場合

run :: FilePath -> IO ()
run fname = do
  handle <- openFile fname ReadMode
  i <- countWhiteSpace handle
  print i

countWhiteSpace :: Handle -> IO Int
countWhiteSpace h = loop 0
  where
    loop i = do
      eof <- hIsEOF h
      if eof
        then return i
        else do
          c <- hGetChar h
          if isSpace c then loop (i+1) else loop i
  • 良い所
    • 素朴で理解しやすい
  • 悪いところ
    • ローレベル
      • 素朴さの裏返しですが、Olegさん言う所の「Haskellで書かれた、典型的なCのコード」*2で、実にローレベルです。関数プログラミングとは何だったのか!
      • ロジックを書いている部分より、Handleの世話をしている部分が多い
        • 実際、ロジックが複雑になると大変なことになります。コード量が増えると、それだけバグの入る可能性も増えます。

io-streamsの場合

run :: FilePath -> IO ()
run fname = do
  i <- Streams.withFileAsInput fname countWhiteSpace
  print i

countWhiteSpace :: InputStream ByteString -> IO Int
countWhiteSpace is = Streams.decodeUtf8 is >>=
                     Streams.map (Text.length . Text.filter isSpace) >>=
                     Streams.fold (+) 0
  • 良い所
    • ハイレベルでコンポーザブル
      • ストリーム自体の扱いはio-streamsが隠蔽しています。
      • ストリームを受け取る関数を、Unixのパイプのように >>=で処理を繋ぎます。繋がれたそれぞれ処理は抜き差しがしやすいので、部品化も簡単です。io-streamsで入力を処理する場合、 InputStream a -> IO (InputStream a) を繋いでいくことになります。
    • 安全な例外
      • それぞれの部品はIO (InputStream -> a)を返すので、bracketで例外を捕捉できます。
    • 少ないメモリ使用量
      • io-streamsが面倒見てくれます。
  • 悪いところ
    • \(^o^)/ない

まとめ

既存の解決方法には問題がある。

  • Lazy IO: 純粋な関数で例外が起こる、リソース管理が難しい

  • Handle: 関数プログラミングっぽくないローレベルなコードになる

ストリーム処理ライブラリで、それら問題を解決できる。

  • io-streams: サプライズの少ない例外*3、ハイレベルでコンポーザブル
    • ただ、リソース管理は自分でやらないといけない。

ということで、ストリーム処理ライブラリを活用すると、効率がよく、見通しがよく、サプライズが少ないプログラムが書けるようになります。

参考資料&リンク集

*1:seqやBangPatternsを使ってサンクを潰して回る羽目になります

*2:http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdfの7ページ参照

*3:実はこれHandleでもwithFileを使えば実現できます。

これからエンジニアがやったらよさそうな仕事

技術顧問ブームですね。先日退職してから色々な会社を回ってて、これニーズあるんじゃね?って仕事を何個か思いついたので、列挙してみます。

チーム開発を軸にした技術顧問

やること: 開発プロセスの構築・実行・改善、ミーティングのファシリテートを行い、チーム開発を良い感じにする。

必要そうなスキル: チームを作った経験。ソフトウェア開発プロセスの知識と実務経験。それなりの技術力。

GitHubでコードレビューしてCI/CDを回して、っていうスタートアップでよくあるエンジニアリングの型はある程度できているけど、うまく運用できていないところは少なくないと予想している。わかってる人が手伝ったら軌道に乗るまでが早そう。事業や組織の性質・フェーズに合わせる必要もあるし結構難しい。チームで仕事をするというカルチャーを伝えるのも価値がありそう。人間力が問われますな…。

個別技術を軸にした技術顧問

やること: 技術選定、アーキテクチャやコードのレビュー。

必要そうなスキル: 当該技術への深い知識と経験。

どのテクノロジーも正しく効果的に使うのは簡単ではない。深い知識は価値が高いはず。

採用支援

やること: エンジニアをうまく採用できていない会社の採用活動を支援する。待遇をエンジニアに訴求するものに再構築し、エンジニアに訴求する求人活動を行う。採用基準の策定。面接、スクリーニング。エンジニア組織の構築・改善。

必要そうなスキル: エンジニアの採用経験。マネジメント経験。幅広い技術とそのシーンの把握。人脈。

困っているファウンダーは多いと思います。カンファレンスやコミュニティの運営をしていて、自社で採用していない人とか良いのでは*1。組織がいけてない場合はそこの改善、場合によってはゼロから構築とかも必要かもなあ。

ベンチャーキャピタリスト

やること: 技術面のデューデリジェンスと、開発体制の構築、技術支援、リクルーティングなどのハンズオン。

必要そうなスキル: VC実務能力に加えて、ハンズオンで説得力を持たせられるだけの技術力とマネジメント経験。エンジニア・コミュニティでの人脈。

金融の友達に、会社やめたのでいろんなスタートアップ回ってるって話をしたら、藤村さんVCやったら?って言われた。その発想は全く無かった。そもそものベンチャーキャピタリストとしての素養が必要なのは言うまでもない。技術面のハンズオンは価値あると思われる。エンジニア業界とVC業界はコミュニティが離れてるので、そこを繋げられるのは悪くないかも。アメリカだと普通にいるっぽい。そもそもYコンビネーターのポール・グレアムLISPハッカー

まとめ

ベンチャーキャピタリスト以外は副業でもできそう。こういうハイエンドな仕事を良い感じに流動化したらシニアエンジニア各位の将来も幸せなのではないか。流動化したハイエンドな労働力を良い感じに流通させるしくみが必要なのかも。

こういう仕事もニーズありそうだよ?とか、追加あったら是非教えてください!

*1:人材紹介業は免許がいるので、紹介で直接対価をもらうのは出来ないと思われる。

無職日記 (1)

Quipperを退職しました & 求職中です - fujimuradaisuke's blog から一週間弱経ちました。

ありがたい事に沢山のお声掛けを頂きました*1。大変申し訳ないのですが、全てのご連絡にお返事できていない状況です…すいません!気がつけば今月のランチ・夕食の予定がほぼ埋まってしまいました。

で、7/24-7/28まで福岡に行きます。Rails Girls Fukuokaでコーチ。その後7/30から20日ほどタイ中心にアジアのどこかに行く予定です。シンガポールは確定、あとはスリランカかな。

今は部屋でこれを聞いてます。60分間、ひたすらミニマルに変化し続ける音楽。スーフィーの音楽を思い出しました。ジャケがかっこいい。 www.youtube.com

wishlistからTシャツと本を送って頂きました!ありがとうございます。記念に着て自撮りを行いました。次の仕事の初出勤はこのTシャツで臨もうと思います。

f:id:fujimuradaisuke:20150713160305j:plain

*1:退職エントリ公開初日で60件くらい