fmapとliftMとliftそしてliftIO

liftIOって結局何のためにあるのかわからないので調べていたらliftとliftIOの違いがわかり易かった。

RWHによれば

  • fmap: 純粋な関数をファンクタのレベルに引き上げる
  • liftM: 純粋な関数をモナドのレベルに引き上げる
  • lift: モナドアクションを変換子層の一つ下のレベルから現在の層へあげる

liftIOはControl.Monad.IO.Class

class (Monad m) => MonadIO m where
    -- | Lift a computation from the 'IO' monad.
    liftIO :: IO a -> m a

参考

RWH3週目終了

ちょっと前からReal World Haskell 3周目を読んでいて、最近読み終わった。

読み始める前のポストイット(理解が曖昧なところに貼ってある)

1288005286

読後(かなり減った)

1342393758

すごいHaskellのおかげで理解がすすんだとことが結構あって、それをテコにしてRWHの内容がすんなり理解できたりしたのが大きかったかも。

ProductName すごいHaskellたのしく学ぼう!
Miran Lipovača
オーム社 / 2940円 ( 2012-05-23 )


今日の畑(120714)

サツマイモは元気に育っている。

1342342475

オクラはマルチの効果を知りたかったのでマルチ有無の畝に同時に植えたのだけど、マルチがあった方の生育は半端ない。そういえばナスもそうだったな。雑草も防げるし来年はもっと積極的に使うかも

1342342477

ゴーヤの花

1342342479

キュウリの花。ウリ科はだいたい似てる。

1342342481

ゴーヤは今年は畝立てして区画の端の方に植えてみたが、去年同様ワシャワシャとれて欲しい。

1342342482

Haskellで作っている人工無能に感情モデルを組み込んでみた

Haskellで人工無脳をつくろうというものを書いてます。

参考にしている書籍は「恋するプログラム―Rubyでつくる人工無脳」なんですけどね。

ProductName 恋するプログラム―Rubyでつくる人工無脳
秋山 智俊
毎日コミュニケーションズ / ?円 ( 2005-04 )


Rubyの書籍は楽しい本が多いんだけど、絶版することも多いですね。

Rubyで作る奇妙なプログラミング言語も絶版だしねー

ProductName Rubyで作る奇妙なプログラミング言語 ~Esoteric Language~
原 悠
毎日コミュニケーションズ / ?円 ( 2008-12-20 )


Pasec覚えるのに適当な言語のparser書くのも楽しいんだろうなーと思ったり、スタックを使った加減乗除を書いてみるのもよいだろうな。

実用Git

僕のGitバイブルは入門Gitなのだけど、マージ戦略の突っ込んだとことかなんのためにgit init --bareがあってどういう意図なのかとかそういうあたりが足りないなぁと思ったので実用Gitも読んでみた。

ProductName 実用Git
Jon Loeliger
オライリージャパン / 2940円 ( 2010-02-19 )


ファイルをどう管理しているかがわかりやすかったのとマージ戦略が厚くて良かった。GitHub使っていてPullリクエスト送ろうと思うと、マージのあたりは非常に気を使うからねー。

実用Gitだけだと、入門者は確実においていかれるので入門Gitは手放せないよね

ProductName 入門Git
濱野 純(Junio C Hamano)
秀和システム / 2310円 ( 2009-09-19 )


ライフログ関連二本

ライフログのすすめとかライフログ入門なんかとくらべるとコアさが減っていてカジュアルな感じになってきている感じがするが、それはスマホとアプリが充実してきているという状況が大きいんだろうな。

最近ライフログ系を二冊読んだのでまとめて。

記録するだけでうまくいく

久々のDiscover。ライフログが、ビジネス本のノリで書かれていて技術職は皆無。アプリを選択してよろしくやろう的な内容です。

ProductName 記録するだけでうまくいく
佐々木 正悟
ディスカヴァー・トゥエンティワン / 1575円 ( 2012-03-12 )


たった一度の人生を記録しなさい

こっちもアプリをどう選択するか。

ライフログの基本は忘れる前にメモだけど、僕は忘れるためにメモかなとも思ったりする。思い出したほうが新鮮だからね。

両方共Evernoteを推してた。自分はあまり使ってないんだけども。

まあ、自分の場合はブログがライフログを兼ねているので。

今日の畑(120707)

ポットで育てていた空芯菜とモロヘイヤを定植してきた。

キュウリ

1342092159

ズッキーニ

1342092161

とうがらし

1342092163

ミニトマト

1342092165 1342092167

コンパニオンプランツとして植えたつるなしインゲン

1342092169

家で干してたニンニクの泥を落とした。

1342092170

一部はニンニク醤油にしてみた。

1342092172

子どもがチャーハン好きなので隠し味に使うつもり。

まだまだニンニクが余っているのでニンニク味噌も作ろうかなと思っているが、砂肝のオリーブオイル煮もうまいからなぁ。料理も楽しいね。

PLEACの8章をHaskellで

PLEACのファイルコンテンツの章が面白そうだったのでHaskellでやってます

import System.IO
import System.Environment
import Control.Concurrent

main = do
  args <- getArgs
  h <- openFile (args!!0) ReadMode
  loop h
  where loop h = do 
          end <- hIsEOF h
          if end then (threadDelay 1000000) >> loop h
          else do
            c <- hGetChar h
            putChar c
            hFlush stdout
            loop h

sleepさせるのはSystem.PosixにもあったんだけどControl.ConcurrentのthreadDelayを使うほうがいいそうなんでそうしてみたけど理由はわからん。

トナリのたんつけ

つけ麺のスープが野菜炒めみたいになってるが、つけ麺です。

1342007598

ワシャワシャ系の麺がうまい。

1342007600

たんからとか唐揚げつけたり餃子つけたりライスつけたりとか多すぎて無理ですね。となりのオネーさんがたんから食べてたけど、もたれないのかなーと。

僕はたんつけで相当きたので、たんつけ小が欲しいくらい。

サラリーマンが“やってはいけない”90のリスト

ネガティブ視点から入っていく。やるべきことをやれじゃなく、やらないべきことは何かを語ってる本。40代の会社にしがみつきたいヒトには参考になる本なのかな?

逆にそういうヒトの思考をちょっと知るにはいい本。まぁ一緒に仕事したくないけど。

部下が報告しないのは、報告の意義を知らないとか、怠慢といった意識の問題ではなく、保身を目的とした意図的な情報隠し、すなわち「情報の私物化」だからである

こんな感じのちょっとネガティブめなのがひたすら書いてある。

ProductName サラリーマンが“やってはいけない”90のリスト
福田秀人
ぱる出版 / 1470円 ( 2012-02-01 )


  • スポーツや音楽の分野で第一級のプロで構成されたグループの事例をもとにしたアンチ管理論やリーダー論に惑わされてはいけない
  • 成果主義は本質的に経営者の経営責任や経営リスクを社員に転嫁する制度でもある
  • 真面目さを一度失えば回復が難しく、成果主義で会社がつぶれた後の転職が難しくなる

著者は成果主義嫌いなんだろうなー(僕もだけど)

GitHub PagesでSphinxを使う

GitHub Pagesを使って文書を管理したら快適そうだったので試してみた。

ゆるふわHaskellというものを書いてます。

Haskellで人工無脳をつくってみたいとか、PLEAC埋めたいとか、Invent with Pythonを書きなおしてみたいとか色々あったのでGitHub+Sphinxでやりたくなったというのがモチベーション。

基本的な流れとしては

  1. gh-pagesというブランチを作る
  2. sphinxtogithubというエクステンションを入れる
  3. Sphinxで文章を書く
  4. make htmlする
  5. cp -pr _build/html/* ./でビルドされたhtmlをカレントディレクトリに移動する
  6. commitしてpushすると公開できるようになる

となるが、4-5のステップはもうちょっとスマートにできると思う。ちなみに参考にしたのが以下のサイトだけど、オフィシャルのヘルプには一通り目を通しておくといいと思う。

GitHub+Sphinxのよさそうなところ(要検証)

  • Issueの管理が楽
  • pull requestで変更を取り込める
  • コードの管理するよりソーシャルなやり取りの敷居が低そう