実用CommonLisp -第一章読了-
仕事もようやく落ち着き、勉強の時間がとれるようになったので第6章までしかやってなかった(と思う)実用CommonLispを最初から勉強し直し初めた。 LISPをまともに触るのは久々で、組み込み関数を結構忘れている(汗
でも、暇な時とか煮詰まった時にCLでフィボナッチやアッカーマン関数等を書いて気持ちを切り替える、ということを普段からやっていたのであまり苦労はしなかった。
第一章Lisp入門
nullとnil
読みなおしてみて気になったのは、null関数と値nilだったりした。 あれ、nullとnilって何違うんだっけ???と。 別途こちらの記事に書いた。
pと?
あとは関数定義の際のシンボルで?が使えるんだが、CLでは?の代わりにpを使う(組み込み関数numberpなど)。 あれ、?使えるのにp使うのなんでだっけ???
ドキュメーテーション文字列
ドキュメーテーション文字列が可愛い!
(defun last-name (name) "Select the last name from a name represented as a list." (first (rest name)))
関数定義の中にコメントではなく、文字列として関数の説明を書けるのは好きだなー。
car,cdrはfirst,restの旧名
うーん、旧名って言われるとなんか凄い違和感ある。。。 原文はどうなってるんですかね?
car,cdrの正式名称
carとcdrはそれぞれcontents of the address registerとcontents of the decrement registerを表している。
おー、そうだったっけ。 この辺はかなり忘れていた。
lambdaの由来
P19にlambdaという名前が使われるようになった由来が書いてある。 豆知識として面白い。
スペシャル変数ってグローバル変数?
何か違うんだっけ? 後で調べる。
第一章感想
僅か17ページで変数への代入、関数定義、map、条件分岐、高階関数まで終わらせる。 最初に「プログラミング入門じゃなくてLISP入門」と書いているだけあって、いわゆるプログラミング入門書とは全然違う。 高階関数の後に文字列型でてくるしw
ただ、LISP入門書としてはかなり解りやすいし易しい内容だと思われる。 ただ、演習問題の解答にまだ出てきていない関数(cond, evenp, expt等)がいきなり出てくるのはどうかと思う。 「LISP入門」という章なんだから、演習問題では今まで説明したものだけを使うべきでは???
PeterNorvigさん、この章書いてる時に最後はつかれたのかなw
nullとnilの違い
実用CommonLispの以下のコードを書いていて、そういえばnullとnilの違いってなんぞや?って思い調べてみた。
(defun mappend (fn the-list) "Apply fn to each element of list and append the results." (if (null the-list nil (append (funcall fn (first the-list)) (mappend fn (rest the-list)))))
http://「NULL」と「NIL」の違いを教えてください。 どちらも「無い」みたい
両者は「品詞」が異なります。 どちらも「何もない」というような意味ですが、nullusは代名詞的形容詞といって他の名詞などを修飾するときに使います。(=英語の No news などの「no」に相当) nilは名詞「無」(=nothing)または副詞「決して...でない」(=never)といった使われ方をします。
へぇー!だからヌル判定はnullで値としてのヌルはnilなんだ。勉強になりました。
2013年振り返りと来年の抱負
2013年も残す所あと数日。 今年は色々あったので振り返っておく。
2013年振り返り
- 5月24日からフリーランスになってみた
- フリーランスとしての仕事で一杯一杯で、勉強会・技術書など全然出来なかった
- 仕事でインフラ周りを結構沢山やれた
- AWS
- Nginx
- Postgresql
- Unicorn
- フリーランスになってからずっとRails!!!
- サービスを無事に2個リリース出来た
- 企画とかも色々やったり、WebmasterToolsやAnalyticsとも仲良くなった
- エンジニアとしての技術力と、そのチームに合う・合わないは別(僕の技術力が高いとかいう意味ではなく)
- 円滑な人間関係大事
- 目標が共有できても、目標を達成するための手段やプロセスがメンバーでバラバラだと、チームが上手く動かない
- 各メンバーの能力がそれほど高くなくても、目標とプロセスの共有が上手く行われているチームだと、そのチームのほうが上手く行く
- 契約はちゃんと守ってくださいね(真顔)
- お金の問題は大人としてちゃんと対応しましょう
来年の抱負
ほーふ!
- 実用CommonLisp再開して終わらせる(この記事書き終わったらやるぞー)
- 勉強会にもそれなりに出る
- 実務と直接関係ない基礎技術を磨く(以下3冊を1年で終わらせられたらいいなー)
- 実務頑張る
さーて、clozure-clのインストール終わったからPAIPやりましょう。
PullRequestを早目にだしてみるメソッド
最近うちのチームで行なっているのが、PullRequestを
「取り敢えず動作はするけど、40%とか50%くらいの状態で早目に出す」
というメソッド。
早目にレビューしてもらうのが目的です。 これは元々チームメイトが以前からやっていたのを、僕らのチームでも導入した感じです。
よかったことにも書いてあるけど、うちのチームは一箇所に集まることが週に一回しか出来ないし、それぞれコードを書く時間が本当にバラバラでペアプロが出来ない。 そんな環境だと、ペアプロの代わりになると思っていて凄い良い。
よかったこと
- 早目にPRを出すことで根本的な間違いなどに早く気がつける
- まだ50%くらいなので、ドヤ顔で出したソースコードをボロクソに言われて凹む、というようなことがない
- 早い段階から色々と議論が出来るので、品質の良いものが出来る
- うちのチームは全員が一箇所に集まるのが週に1回くらいなので、ペアプロがあまり出来ない。だが、PRを早目に出してGitHub上で議論しながら進めることで、ペアプロ的な利点を取り入れる事ができる
よくなかったこと
- 今のところ特に思いつかないかも。
これ、エンジニアが凄い増えたら上手く回るのか解らないし、毎日同じ場所にエンジニアが集まれるならもしかして必要ないのかも? その辺は経験ないので解らない。
でも、取り敢えずうちの「少人数で作業場所・時間がバラバラ」という環境だと凄い上手く回っています。 そういう環境のチームにはおすすめです☆
2ヶ月くらい個人事業主生活をしてみた #継続中
よかったこと
- 出社しなくていい
- ずっと猫ともふもふできる
- ストレスから滅茶苦茶解放された
- 苦手だったフロント周りも(CoffeeScriptとか)結構触れるようになった
- 久々にインフラやったら意外と出来た
わるかったこと
- 人間と話す機会の減少
- 休日をまだ一回も取れてない
- 体調を結構崩しまくった
そうていがいだったこと
- 技術書読む時間すらとれない
- RoRばっかで機械学習のお仕事のフェーズまで中々たどり着けない
- お仕事って会社に所属しなくても選ぶほどあった
古いMacBookProにpostgresqlを入れる
古いって行っても、2009年とか。initdbでエラーが出て、ぐぐったら日本の情報が殆ど無かったので他の人のためにメモ。
2012年モデルのMacMiniだと出なかったから、必要ないかもしれないけどw
エラー
initdb /usr/local/var/postgres
... This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space, or exceeded your kernel's SHMALL parameter.
対処方法
/etc/sysctl.conf
を作成。中身は
kern.sysv.shmall=65536
kern.sysv.shmmax=16777216
で、Mac再起動してinitdbしたら無事完了。
最近やっていることまとめ
自分用メモ
最近の作業
- ひたすらRoR
- Deviseをひたすらいじくり回す
- jQueryのライブラリをうにゃうにゃいじくり回す→BackbornJSとかに移行させたいけど、今後の課題
- サーバー構築(nginx,unicorn,jenkins,PostgreSQL,capistrano)
- HTML/CSS(デザインをRoRに合わせる、これが一番時間かかる。。。)
最近買った本
- PostgreSQL完全バイブル
- Ruby on Rails環境構築ガイド
- CleanCoder
最近勉強したこと(仕事以外)
忙しくて勉強の時間が中々取れない・・・
- Making Softwareを乱読
- CleanCoderをトイレで読み進める
最近思ったアジャイルについてのあれこれ
アート・オブ・アジャイル・デベロップメントが手元にないのでうろ覚えけど、確か「ビジネス的な成功・個人的な成功・技術的な成功」の3つの集合の重なりあう所が本当の成功だって書いてあった。これは本当にそうだなーとフリーランスになって強く思う。アジャイルでも多分納期は大切で、ただ納期の他にも大切なことは沢山あるし、場合によっては納期よりも大切なことがあるよね?っていう話しで、納期を疎かにしていいという意味ではないのかなーと。
後は、アジャイルをやるにはやっぱりそのチームにアジャイルをやるだけの下地が必要だと思った。それは各人の能力的な話しよりも、アジャイルを皆がある程度理解して(完全な理解なんてやったことないなら無理だよね)、アジャイルな開発をしたいという思いを全員が共有してないと無理そうだなーと。そういう意味では、「ある時点では」アジャイルに向かないチームっていうのはありそう。そういう時に無理にアジャイルやると逆に破綻しそうだけど、これは多分アジャイルを導入しようとする人の進め方とか説明の仕方に依存する気がする。相手がアジャイルについて「実は」興味が無い(自主的に調べたりはしない)、ということを念頭に置かないと様々なプラクティスが上手く回らない。
後は、アジャイルは開発手法だったり組織論だったり(アジャイルとは何ぞや?っていう細かい議論は置いておいて)すると思うのですが、結局はビジネスとそれに伴う開発を「アジャイル的な意味での成功」に導く(導く?)ものだと思っているのですが、アジャイル的な手法に囚われて何も進みませんでした、という事がないように時には失敗するかもしれないけど、最初から完璧は無理だろうから多少やり直す覚悟で前に進んでみるのも必要かもしれないと思いました(これは多分にチームの力や経験不足からくるものだけど、きっと失敗を経験しないと力なんてつかないかなーとか)。