ハーバード大学哲学科が教える、哲学を学ぶ理由
ハーバード大学哲学科のサイトにあった「なぜ哲学を学ぶのか」があまりに良かったので、精度が上がったという評判のGoogle翻訳を試すついでに訳してみました*1。
僕も大学で哲学を勉強していました。もはや半可通でしかないのですが*2、後半にある「哲学があなたに教えるスキル」は僕が仕事をする上で全ての基礎になっています。哲学を勉強してよかった。
原文はこちら。訂正などありましたら是非コメントください。
Why Study Philosophy? | Harvard University Department of Philosophy
カリフォルニア大学バークレー校の哲学者であるジョン・キャンベルは、哲学についてこう考えていますー「それは、私たちがふだん凄いスピードで行っていることを分解し、説明し、評価する。すると、別の選択肢が可能であることがあきらかになる」。
哲学を学ぶことは、何千年もの間人類を悩ませてきた問いに、過去存在した偉大な思想家たちとの対話を通じて取り組むことです。1つ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さんのミートアップでパネルディスカッションに参加させて頂きます。是非お越しください!
直前ですが、Haskell Dayでチュートリアルのチューターをやる予定です。こちらも是非!Simon Payton Jonesさんが来ます!
付録: マチマチを支える技術 ダイジェスト版
現状、主要なコンポーネントは
- Rails 5.0.0.1
- PostgreSQL 9.5
- React.js 15.3.1
- Heroku
という構成でやっています。サービスの初期ということで、仕様の変化が多く、かつ長期的なコードベースへの影響が大きいので、なるべく素直な構成とコードを心がけています。変更しやすいよう、テストは割と手厚く書いています。
その他、やってることや特徴をピックアップすると、下記のような感じです。
- 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
1989, Hungary
1993, United States
1994, Sweden
1994, Norway
1986, Sweden
1991, Swiss
2001, France
*1:入れたかったけど量的に割愛したバンドが沢山います。BurzumとかKatharsisとかSarcofagoとか。
Hspecベストプラクティス
Hspecベストプラクティス
Haskell Advent Calendar 2015 の14日目のエントリーです。
イントロ
Hspec はHaskellコミュニティにすっかり受け入れられたテスティングフレームワークと言ってよいかと思います。しかし!まだ確たるベストプラクティスは無いと言えるのではないでしょうか!
Hspecの元となったRSpecはRubyコミュニティでデファクト・スタンダードとなっており、ベストプラクティスの蓄積があります。これを、Haskellの事情を鑑みつつ適用してみようという記事です。
ではないので、その辺りは別の記事を読んでください。
あと、オフィシャルのexampleがあるので、これに先に目を通しておくと話が早いかもしれません。
気になる点、賛同できないプラクティス、改善点などありましたら、是非コメントで教えてください。
では始めます!
一般的なディレクトリ構造に従う
- 一つのソースファイルに一つのスペック
- ファイル名は
Spec.hs
で終える - ソースコードのディレクトリ構造に対応させる
が慣用的です。 例えば src/Foo.hs
のSpecはtest/FooSpec.hs
、src/Data/Bar.hs
はtest/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さんもテストの抽象化には反対していました。
とはいえ現実世界では、読みやすい抽象化をすればいいのでは?とか、さすがにボイラープレートコードが多すぎる、とか、悩ましい状況は発生します。適度にルールを破る分には良いかと。
マッチャーを知る
shouldBe
、shouldReturn
などをマッチャーと言います。これはそんなに数多くないので、一度目を通すとよいです。
ドキュメントはこちら にあります*1。
GHCIでテストする
module FooSpec (main, spec) where main :: IO () main = hspec spec spec :: Spec spec = describe "Foo.bar" $ do -- 省略
というようにmain
とspec
を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の人になってしまいました。悲しいですね!
リンク集
本家
この記事の元ネタ
- http://betterspecs.org/jp/
- http://magazine.rubyist.net/?0032-TranslationArticle
- http://www.methodsandtools.com/tools/rspecbestpractices.php
RSpecについて:
Hspecについて
- https://www.reddit.com/r/haskell/comments/3vaj0z/24_days_of_hackage_2015_day_3_hspec_the/
- http://conscientiousprogrammer.com/blog/2015/12/03/24-days-of-hackage-2015-day-3-hspec-the-importance-of-testing/
- http://looprecur.com/blog/testing-a-web-application-with-hspec/
- http://alpmestan.com/posts/2014-06-18-testing-attoparsec-parsers-with-hspec.html
- http://d.hatena.ne.jp/kazu-yamamoto/20121205/1354692144
- http://mike-neck.hatenadiary.com/entry/2015/06/19/103536
- http://oropon.hatenablog.com/entry/2014/03/14/012729
Haskellでなぜストリーム処理ライブラリが必要なのか
関数型ストリーム処理勉強会で発表したので、ブログにも書いておきます。
Haskellでストリームデータを扱う方法としては、Handleを使う方法、Lazy IOがありました。しかし、それぞれに問題があり、再利用性が高く堅牢なコードを書くことは困難でした。
この状況を解決すべく、Conduit、Pipes、io-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
- 良いところ
- 単純でわかりやすい
- 悪いところ
- 純粋な関数で例外が起こる
- いつ、どれだけファイルが開かれ、開放されるか予測しにくい
- 上記と同じ理由でファイルが開放されるタイミングも単純には予測できません*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
- 良い所
- 素朴で理解しやすい
- 悪いところ
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
- 良い所
- 悪いところ
- \(^o^)/ない
まとめ
既存の解決方法には問題がある。
Lazy IO: 純粋な関数で例外が起こる、リソース管理が難しい
Handle: 関数プログラミングっぽくないローレベルなコードになる
ストリーム処理ライブラリで、それら問題を解決できる。
ということで、ストリーム処理ライブラリを活用すると、効率がよく、見通しがよく、サプライズが少ないプログラムが書けるようになります。
参考資料&リンク集
- io-streams
- Conduit
- Pipes
- サンプルコード
- ストリーム処理ライブラリブームの端緒となったIteratee論文
- Iterateeについての発表資料。わかりやすい
- Iterateeの紹介
- io-streamsリリースのお知らせ&紹介。Conduit, Pipesとの比較もある
- Conduit, Pipes, io-streamsの比較 by Conduitの作者Simonさん
- Lazy IOの罠
- Conduit概要
*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シャツで臨もうと思います。
*1:退職エントリ公開初日で60件くらい