CTOなので久々に読んだ。「賢くて、物事を成し遂げる人を雇え」ってメッセージは普遍的。プラグマティズムあまり詳しくないのとブランダムなど新しい(僕が哲学科を卒業したのは10年以上前なので結構取り残されている)哲学者の話も読めるということで読んだ。アメリカの哲学はどうしても論理実証主義から分析哲学って流れの説明が多くなっちゃうので、そこら辺の補強に便利だった。普通に読書としても面白い。統合失調症に関心がある人は是非。comment2016-11-12ハーバード大学哲学科が教える、哲学を学ぶ理由ハーバード大学哲学科のサイトにあった「なぜ哲学を学ぶのか」があまりに良かったので、精度が上がったという評判のGoogle翻訳を試すついでに訳してみました*1。僕も大学で哲学を勉強していました。半可通でしかないのですが*2、後半にある「哲学があなたに教えるスキル」は僕が仕事をする上で全ての基礎になっています。哲学を勉強してよかった。訂正などありましたら是非コメントください。Philosophyカリフォルニア大学バークレー校の哲学者であるジョン・キャンベルは、哲学についてこう考えていますー「それは、私たちがふだん凄いスピードで行っていることを分解し、説明し、評価する。すると、別の選択肢が可能であることがあきらかになる」。哲学を学ぶことは、何千年もの間人類を悩ませてきた問いに、過去存在した偉大な思想家たちとの対話を通じて取り組むことです。1つ2つの授業を取る、集中して哲学を学ぶ、どちらの場合も、生徒たちは哲学を学ぶことが大学生活で最も有益な知的体験であることを知ります。哲学を研究する主な理由は、反省と熟考の本質的な価値を知ることです。それにもかかわらず、哲学に惹かれている多くの学部生は、哲学の学位は貧困への道だと心配しています。実際のところ、哲学を学ぶことで得られるスキルは、不安定かつ急速に変化する経済環境の中で、高い市場価値があります。多くの特化したスキルは最終的に時代遅れになり、いずれの場合でもほとんどの人は人生の中で何度もキャリアを変えてしまいます。哲学があなたに教えるスキルは、常に需要が高いはずです。明快に思考し、書くこと。認識されていない前提を明らかにすること。複雑なアイデアを明快に説明すること。つながりと含意を解きほぐすこと。幅広い文脈で物事をとらえること。一言で言えば、哲学はどんな業種でも適用できるスキルを提供します。ハーバード大学の哲学専攻生は、多様で価値あるキャリアを追求してきました。哲学の卒業生は、法律、財務およびコンサルティング、ビジネス、インターネットのスタートアップ、医学、ジャーナリズム、芸術、非営利の仕事、教育、学術(哲学と他の学問分野の両方)で成功を収めています。あなた自身に問うべき質問は「私は哲学の学位で何ができますか?」ではなく、「私が哲学の学位でできないことは何でしょうか?」でしょう。*1:Google翻訳したものを自分で直しました。文体が不自然だったり、なぜか訳出されない箇所があったりで、結構直した*2:先日学部の友人と話していて「藤村君が学生の頃とは常識が変わった」と言われました。comment2016-09-16起業してました&エンジニア募集しています近況報告としては、退職のご報告からすっかり間が空きました。Inc.を共同創業し、現在「近所のつながりを通して、地域の課題を解決する」というミッションのもと、ご近所SNSマチマチを運営しています。前職をやめてからは結構悩みましたが、こういう時は一番ハードルが高くてテンションが上がるやつを選ぶべきだ!ということで「自分でやる」って選択肢を選びました。Glassesをやっていた六人部生馬です。複数のスタートアップを経験している、Rubyistと仕事をしている、神奈川出身であるなど共感できるところが多々ありつつキャラ的にも能力的にも補完的という、良いチームになりました。今、マチマチの開発チームは、現在エンジニア1人(僕)デザイナー1人(元山さん)の2人です。やるべきことが満足のいくスピードでやれていない状況です。現状Web版だけのマチマチですが、多くの方からアプリ化の要望を頂いています。いうことで、一緒に働く仲間を募集することにしました。具体的にはWebエンジニア、iOSエンジニア、Androidエンジニアに加えて、ビジネス側のメンバーを募集しています。下にWantedlyのリンクを貼っているので、詳細はそちらをご覧ください。話は変わりますが、新しい事業を始めるにあたって最も重要な事は「適切な事業領域を選ぶこと」だと思います。しい子育て環境、衰退しつつある地域コミュニティと、大きな課題をいくつも抱えた課題先進国です。ベーシック・インカム、地域通貨などの新しい再分配のあり方の登場、シェアリング・エコノミーの浸透による家事、買い物など生活スタイルの進化、ライドシェア、自動運転車などで変わる都市における移動と距離感、スマートシティと呼ばれる電力、エネルギーの技術革新など、いま社会には多くの変化が訪れています。これらの課題・変化、すべて具体的には「地域」で起こっていることです。ここ、僕らの持っている人生の貴重な時間を使う先として、課題としてのサイズと意義は十分ではないでしょうか。テクノロジーで改善できる事は沢山あります。時間とエネルギーと熱意をつぎ込むに値する、魅力あるフィールドだと思います。僕達はこの領域に対し「つながり」という軸で手を打ちはじめました。熱くなってしまいましたが、そんな感じで面白い事をやっています。良い経営チームとめちゃくちゃ面白い問題は用意できたと思うので、いいチームといいエンジニアリングで、どんどん問題を解いて行きましょう。みなさんの力を貸してください。各種ソーシャルアカウントでお気軽にご連絡頂ければと思います。みなさんお忙しいと思うのでランチでも行きましょう。転職考えてない人も歓迎です。マチマチの技術的な側面については末尾に付録としてまとめておきましたのでご笑覧ください。あと、Forkwellさんのミートアップでパネルディスカッションに参加させて頂きます。Dayでチュートリアルのチューターをやる予定です。15.3.1Herokuという構成でやっています。サービスの初期ということで、仕様の変化が多く、かつ長期的なコードベースへの影響が大きいので、なるべく素直な構成とコードを心がけています。変更しやすいよう、テストは割と手厚く書いています。その他、やってることや特徴をピックアップすると、下記のような感じです。power-assert定期実行は全てJenkinsから。Rubocopを使ってJenkinsでPR出して自動で修正データ分析はBigQueryとre:dash。機能開発以外の今後の課題はHerokuへのリクエストの太平洋超えレイテンシをなんとかしたいけど、開発効率が良いのでやめたくない地図データがきれいに揃っていないので整えたいやがてやってくる通知の再実装問題jbuilder遅いなど。興味ある事や知りたい事があったら可能な限りいくらでも情報開示します。気軽に聞いてください。2015の24日目の記事です。担当がクリスマスイブになったのは偶然です。詳しい説明はしませんが、それぞれその時代と国を代表する正統派ブラックメタルバンドです。本気でブラックメタルを聞いていた人は誰も文句を言わない、ブラックメタルという音楽の本質を味わえるチョイスだと思います*1。ここまで人間のダークサイドにフォーカスした音楽が他にあるでしょうか!?改めて聴いて震えました。Francewww.youtube.com*1:入れたかったけど量的に割愛したバンドが沢山います。BurzumとかKatharsisとかSarcofagoとか。14日目のエントリーです。Haskellコミュニティにすっかり受け入れられたテスティングフレームワークと言ってよいかと思います。!まだ確たるベストプラクティスは無いと言えるのではないでしょうか!Hspecの元となったRSpecはRubyコミュニティでデファクト・スタンダードとなっており、ベストプラクティスの蓄積があります。これを、Haskellの事情を鑑みつつ適用してみようという記事です。HspecのチュートリアルBDDのチュートリアルソフトウェア・テストのチュートリアルではないので、その辺りは別の記事を読んでください。あと、オフィシャルのexampleがあるので、これに先に目を通しておくと話が早いかもしれません。気になる点、賛同できないプラクティス、改善点などありましたら、是非コメントで教えてください。始めます!一般的なディレクトリ構造に従う一つのソースファイルに一つのスペックファイル名はSpec.hsで終えるソースコードのディレクトリ構造に対応させるが慣用的です。src/Foo.hsのSpecはtest/FooSpec.hs、src/Data/Bar.hsはtest/Data/BarSpec.hsとなります。hspec-discoverでテストスイートをまとめる複数あるテストを一つのテストスイートにまとめるのは結構面倒です。Specをエクスポートしておけば、hspec-discoverが規約に沿ったファイルから自動的にテストスイートを作ってくれます。Spec.hsそれぞれの関数について、振る舞いの説明をするdescribeで説明する関数を宣言し、itでその振る舞いを説明します。8contextを活用するcontextに文脈を書くと整理されたテストスイートになります。1一つのテストで一つの振る舞いを確認する複数の振る舞いを確認すると失敗するテストを見つけるのが難しくなります。テストが遅くなりすぎる場合は複数の振る舞いを検証するのもアリです。省略テストをあまり抽象化しないBDDはソフトウェアの振る舞いを記述するための手法です。多少冗長でも、記述された振る舞いの読みやすさを優先したほうがよいです。いい例が思いつかないので、瑣末な例で。省略としておいた方がよいです。前者の例はコードから振る舞いを読み取れません。BDDのテストコードは抽象化の対象ではなくソフトウェアの振る舞いを記述するものである、ということを心に留めておきましょう。HackageでHspecが取り上げられており、コメント欄でYesodやPersistentのメンテナーであるGregさんもテストの抽象化には反対していました。いえ現実世界では、読みやすい抽象化をすればいいのでは?とか、さすがにボイラープレートコードが多すぎる、とか、悩ましい状況は発生します。適度にルールを破る分には良いかと。マッチャーを知るshouldBe、shouldReturnなどをマッチャーと言います。これはそんなに数多くないので、一度目を通すとよいです。somethingという具合にGHCiの中でテストを実行できます。するほうが早いのでオススメ。便利なライブラリがある一時ディレクトリ、一時ファイルの利用はMockeryが便利です。Silentlyを使うと標準入出力をキャプチャできます。WAIにはhspec-wai、Snapにはhspec-snapがあります。ちなみに僕はhspec-waiの作者の一人です。まとめというか所感Hspecいいソフトウェアだと思います。型がリッチな言語とふわっと振る舞いからコードを育てるBDDの相性がめちゃくちゃ良い。Developmentは捗ります。あと、他にもRSpecのベストプラクティスをパクれるところは沢山あると思うので、RubyわかるHaskeller諸氏は是非参考にしてみてください。ChelimskyさんはClojureの人になってしまいました。本家http://hspec.github.iohttp://hackage.haskell.org/package/hspecこの記事の元ネタhttp://betterspecs.org/jp/http://magazine.rubyist.net/?0032-TranslationArticlehttp://www.methodsandtools.com/tools/rspecbestpractices.phpRSpecについて:http://magazine.rubyist.net/?0021-Rspechttp://rspec.info/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.htmlhttp://d.hatena.ne.jp/kazu-yamamoto/20121205/1354692144http://mike-neck.hatenadiary.com/entry/2015/06/19/103536http://oropon.hatenablog.com/entry/2014/03/14/012729*1:ちなみに中置記法があるおかげでRSpecのようにshould/expect論争がないです。comment2015-11-09Haskellでなぜストリーム処理ライブラリが必要なのか関数型ストリーム処理勉強会で発表したので、ブログにも書いておきます。それぞれに問題があり、再利用性が高く堅牢なコードを書くことは困難でした。https://github.com/fujimura/functional-stream-processing-meetup-sampleそもそもストリームとは必要に応じて処理されるデータの連なりのこと。具体的には標準入力、ファイル、ソケットなど。上記の定義はSchemeの実装提案書より。この定義では入力側をストリームと読んでいますが、出力側(標準出力への書き込みなど)もストリームとして扱われてる場合が多い気がします。ストリームは多くの場合、IOです。具体例200MBのテキストファイルに含まれる空白文字の数を調べる、という例で比較します。200MBのファイルを一気にメモリ上に読み込むのは効率的とは言えません。ストリーム処理の出番です。isSpace良いところ単純でわかりやすい悪いところ純粋な関数で例外が起こるreadFileで読んだファイルに不正なバイト列が含まれていた場合は例外が起こります。Haskellは遅延評価なので、値は必要になった時に評価され、例外は評価時に発生します。評価されるまで例外は発生しないのです!この性質により、なんと純粋な関数で例外が起こることがあります。これのデバッグは非常に難しいです。具体的には上記のコードの場合、Text.Lazy.filterで不正なバイト列が評価される時に発生します。いつ、どれだけファイルが開かれ、開放されるか予測しにくい上記と同じ理由でファイルが開放されるタイミングも単純には予測できません*1。大量のファイルが同時に開かれてしまう場合もあります。素朴で理解しやすい悪いところローレベル素朴さの裏返しですが、Olegさん言う所の「Haskellで書かれた、典型的なCのコード」*2で、実にローレベルです。関数プログラミングとは何だったのか!ロジックを書いている部分より、Handleの世話をしている部分が多い実際、ロジックが複雑になると大変なことになります。コード量が増えると、それだけバグの入る可能性も増えます。0良い所ハイレベルでコンポーザブルストリーム自体の扱いはio-streamsが隠蔽しています。>>=で処理を繋ぎます。繋がれたそれぞれ処理は抜き差しがしやすいので、部品化も簡単です。繋いでいくことになります。a)を返すので、bracketで例外を捕捉できます。少ないメモリ使用量io-streamsが面倒見てくれます。悪いところ\(^o^)/ないまとめ既存の解決方法には問題がある。関数プログラミングっぽくないローレベルなコードになるストリーム処理ライブラリで、それら問題を解決できる。サプライズの少ない例外*3、ハイレベルでコンポーザブルただ、リソース管理は自分でやらないといけない。いうことで、ストリーム処理ライブラリを活用すると、効率がよく、見通しがよく、サプライズが少ないプログラムが書けるようになります。参考資料&リンク集io-streamshttps://hackage.haskell.org/package/io-streamsConduithttps://hackage.haskell.org/package/conduitPipeshttps://hackage.haskell.org/package/pipesサンプルコードhttps://github.com/fujimura/functional-stream-processing-meetup-sampleストリーム処理ライブラリブームの端緒となったIteratee論文http://okmij.org/ftp/Haskell/Iteratee/describe.pdfIterateeについての発表資料。http://d.hatena.ne.jp/tanakh/20100824io-streamsリリースのお知らせ&紹介。Pipesとの比較もあるhttp://snapframework.com/blog/2013/03/05/announcing-io-streamsRedditのスレッドが盛り上がった。IOの罠http://newartisans.com/2013/05/three-examples-of-problems-with-lazy-io/Conduit概要https://www.fpcomplete.com/user/snoyberg/library-documentation/conduit-overview*1:seqやBangPatternsを使ってサンクを潰して回る羽目になります*2:http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdfの7ページ参照*3:実はこれHandleでもwithFileを使えば実現できます。