atton.blog: 読書感想文

ラベル 読書感想文 の投稿を表示しています。すべての投稿を表示

2014/11/05

コーディングを支える技術を読んだ

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法を読みました。

プログラミングにおける機構の成り立ちとかを解説してくれる本でした。
if 文は何故あるの、関数は何故あるの、型は、スコープは、... みたいなことを「こういう経緯があって、この言語はこういうアプローチで解決した」という歴史を教えてくれる。なので、機構の名前と機能だけを解説するのではなく、むしろこういう経緯があったんだよー、って話の方がメイン。

取り上げられているトピックも多岐に渡ります。表紙に書かれている要素を列挙すると、演算子、繰り返し、関数、例外、スコープ、動的型付け、型推論、配列、辞書、スレッド、ロック、トランザクショナルメモリ、クラス、インターフェース、継承、委譲、C3線形化、Mix-in、トレイトとなっています。かなりの範囲をカバーしてそう。

あと、複数の解決方法を知ることができるので、言語Aの機構Bは言語Cの機構Dと似ててここが違う、とかが分かるのも良いところ。例えば Ruby の Hash は、他の言語では Dictionary だったり HashMap だったりとか。

さらにおもしろかったのは、同じ単語に対して異なる解釈があること。
私は Ruby をよく使っているので「オブジェクト指向」と言えば「オブジェクトにメッセージを送ることによってオブジェクトそのものに振る舞わせる」ことだと解釈するのですが、C++では「オブジェクト指向」と言えば「ユーザ定義型であるクラスによる処理の再利用」となっていたり。オブジェクト指向に限った話で言えば Perl での処理の共通化、 JavaScript での prototype など、言語による解釈や実装がいくつもあるのだなー、と。

読む前は「オブジェクト指向はクラスだ」という言葉は「なんでメッセージの話が出ないんだろう」と思いましたが、「(ある言語における)オブジェクト指向はクラスだ」みたいに主語が隠れてるんだろうなー、と。
そういう意味でも、自分の知ってる言語の機構名だけで考えるんじゃなくて成り立ちを知ることや他の言語を知ることには利点がありそうだなー、とか。

この本で機構そのものを学ぶというよりは、今までそんなに意識せずに使っていた機構にまつわる経緯は何なのか、とかを知る本です。
なので、ある程度プログラミング言語に触ってから読むと、おまじないにしていた謎が解けたりするかもしれません。
プログラミング言語の勉強の始めに読むのには向いてないけれど、言語の勉強に詰まった時や歴史を知りたい時とかに読むのが良さそう。

2014/02/13

楽々ERDレッスンを読んだ

楽々ERDレッスンを読むなど。

DB分からないー、とか言っていたら貸してもらっていました。
借りたのは良いけれど積んでいたので、この機会に若干飛ばしながらも読み切る。

おおざっぱな感想としては

業務向けっぽい
データベースってデータ管理フレームワークなのだな
どっちかというと読み物

といった感じ。

どうして業務向けかというと、データベースについての話はするのだれど、業務にとって重要かそうでないかとか、自身の経験に基づいているっぽい意見とかが多かったのでそう感じた。おそらく苦労があったのだろうな、とか。

データベースってデータ管理フレームワークなのだな、というのは当然っちゃ当然の話。だけれど、多数の言語から統一インターフェース(SQL)でアクセスできるもので、中身は高速化だのトランザクションだのって実装されている、という点からなんかフレームワークっぽいなー、とか。それを言えばファイルという存在自体フレームワークか、とか書いてて思わなくも無い。

どっちかと言うと読み物、というのは歴史とか経験とかそういった部分も解説されているから。あと、正規化手法とかそういったものは省略されていて、現場ではどうするか、という部分に重きを置いている感じがあったので。あと、2005年な本だったりするので、若干気になるところもあるけれど読み物チックなので良いかな、とか。

とゆーことで読んでて思ったことの列挙とか。若干眠いお時間なので列挙するだけで。

第1部 : DB設計総論

いろいろ変更とかありえるデータを想定したい、というのが念頭にあるみたい。
- 単価が顧客によって変わるとか
- 内部外部で呼び方が違うとか
- そういう意味では負の遺産っぽいな、とか
  - 仕様変更や想定外の要素などが過去にあって大変だったのだろうな、とか
  - そういう意味では経験を語っている本っぽい
- 解決手法として、リソースには unique id を振って、属性とか関連とかを柔軟に追加できるようにしようよ、って感じだったよーな
あとツッコミとして、コードって何やねん、ってなった
- なんかこう、顧客コードとかっていう物体。idとは別らしい。
- code も identifier っぽくてユニークじゃないのか、ってツッコミたかった。
- unique でない「コード」というもの存在している、ってことなのかもしれない

第2部 : RDBMS総論

そもそもDBとはレポート生成システムであるとのこと
DBってデータマネージメントフレームワークぽいな、とか
- データに関する処理を一元実装してしまったもの
- 利用するための共通インターフェースがSQL
- ストアドプロシージャ便利そう
  - プログラミング言語側でSQL組み立てがいらないので、処理もRDBMSに投げられる
  - でも使われているのか、とかって思案が。面倒そうだし。
  - ActiveRecord とか内部でSQL組みたててそうだよなー
RDBMSの特性を理解しようね、とか言ってるような
- ハードウェアスペックに依存した部分もあるよ、とか
  - 正規化の遅さ速さとかって話以前にね
- sql は batch であるとか
  - 何をするにもデータを読むためにselectしちゃうよね、とか
  - これを知らないでやるととんでも無い処理を書いちゃって遅くなるよ、とか

第3部 : 楽々ERDレッスン

イベント/リソースでのデータベース設計
- イベントは「* する」のように言えるもの
- リソースは 5W1H的なもの
- みたいな視点でテーブルを作ってみよう、って感じだった

あとはなんか名言っぽかったの。

「One fact in one place」
「データは蓄積することのみに意味は無く、それを元にアウトプットするための資産である」
「プログラムそのものには価値は無く、どのようにデータを扱うかが重要なのである」

2013/11/11

アプレンティスシップ・パターンを読んだ

アプレンティスシップ・パターンを読みました。

リファクタリング・ウェットウェアを読んだ後、ドレイファスのモデルとかを知ったのは良いけれど具体的に何をするべきなんだろうか、とか言っていたら kimihito さんからこんな本あるよー、とか勧められたので読みました。

実を言うとだいぶ時間を空けながら読んでしまったのと、訳があまり私に合わなかったので正直斜め読みというか記憶があまり無いというか。

さらっと目次を見ると思い出したのですが、憶えようと思っていたのがお茶の話。
パターンで言う「白帯」とかですね。
新しいことを教えようという時に、今までの考えのみを使って考えていたようであれば、教えようにも教えられない、みたいな話。

「すでに一杯になっているカップを持って、私のもとにやって来たのであれば、私がどうやってあなたに何か飲み物を与えられるでしょうか」

と。本文引用。
どうも私は聞きかじりの知識で対応しようとしてしまう癖があるようなので非常に耳の痛い話。
しかも目次を見直すまで今まで憶えずに忘れていたという……。

技術者にまつわるよう問題に対して、どう対応するべきか、みたいなパターン集でした。

2013/11/04

競技プログラマが知るべき97のことを読んだ

最近 @_simanman さんと @kanpe777 さんと #ie_procon なる競技プログラミング勉強会をしているのですが、そこで紹介された薄い本。
競技プログラミングに関する TIPS 本です。
kanpe777 さんから借りて読みました。

印象に残っているのは

競技プログラミングはネトゲである
float ではなく double を使う
定数倍高速化はムダ
100, 300, 600, 1000
コーディング規約
コードの綺麗さ
絨毯爆撃
Editor な話で Vim が無い
摂動
自作ライブラリ、他人の自作ライブラリ
煩雑なデータ構造へのアクセサ

といった感じでしょうか。

それぞれについてちょっとコメントすると

競技プログラミングはネトゲである

みんなが集まってクエスト(問題)を解いていくから、と。なんかそれっぽい。

float ではなく double を使う

精度の関係で double 安定らしいです。

定数倍高速化はムダ

これはちょっと耳が痛い話。

初心者がやりがちらしい話らしくて、定数倍程度のちまちました改善は基本的にムダらしい。

計算量を見直すレベルじゃないとダメだとか。

100, 300, 600, 1000

競技プログラマには解いた問題によって実力の壁があるんだとか。

それが 100, 300, 600, 1000 らしくて、すごい方々は1000とか解いているらしい。

私は100も解いてない。うーむ。

コーディング規約

コードの綺麗さ

競技プログラミングのコードは基本的に書いて終わりだから、綺麗さをどうしようかという話。

競技プログラマのコードは汚いんじゃないか、みたいなイメージもあったりなんだりらしいけれど、競技のコードとそれ以外のコードは分けよう、とか。

あと、チーム戦なら競技でもちゃんと書いた方が良いし、自分のためにもちゃんと書こう、みたいな。

絨毯爆撃

これは知らなかった。というかその発想は無かった。

撃墜フェーズで良いコーナケースを思い付いたら、それでひたすらに爆撃していくらしい。
大量得点 or 大量失点の大博打らしいです。

Editor な話で Vim が無い

補完の関係では Visuatl Studio, Eclipse とか、構文チェックでは Eclipse, Visual Studio, Emacs + flymake とかが紹介されてました。

Vim も Makefile 書けば quickfix に syntax error 残るし、 quickrun とか quickrun + watchdogs とか syntastics とか入れたら捗りそうなのになー、とかって私見。

摂動

実数を扱う時には誤差を考慮したりするのだとか。知らない世界でした。

自作ライブラリ、他人の自作ライブラリ

競技で頻繁に使うたコードはライブラリにしたりするのだとか。

他人のライブラリと比較したり自分なりのアレンジを作ったりなんだりするらしい。

煩雑なデータ構造へのアクセサ

これは良いなと思った。

クラスを作るようなサイズで無い(とか時間が無い)構造体を定義する時とかに、それにアクセスするためだけのメソッドを定義する、というもの。

triple の変わりの pair pair だと hoge.first.first とかになって分かりづらいので accessor(my_triple hoge) { return hoge.first.first } とか

他にもいろいろありましたがこんなところで。
細かい tips もあったりしたので、簡単に手に入るなら手元の置いておいても良いのかな、とか思いました。

2013/10/14

実践Vim を読んだ

実践Vim を読みました。
買って一ヶ月くらいで読んだ様子。
たぶんしばらく放置して数週間くらいかけて読んだよーな。

内容ですが、 Vim の基本機能に関する TIPS 集みたいな感じでした。200個くらい TIPS がある。というか全ての項目が TIPS としてまとめられてる。

発見したことはいくつかあって、憶えてるのだと

Expression Register
/ した後に :s//hoge/ すると置換のパターンが最後の / と同じになる
:global が便利そう(使ってなかった)
:spell している状態でスペルミスの部分を修正できる(z= とか)

あといくつかあったのですが、結構多くて忘れてる。
大量の TIPS があるので後から見直せば良いのかなー、とか。

あと、読んでて思ったこと。
Vim の基本機能の解説なので、割と知ってる内容でした。
なのと、自分で勝手に使ってる Vim な方法と違う方法が書かれていて違和感。
別の方法もあるよー、的な感じですがこう、読んでて「私ならあーする」みたいなのが脳内に出てきてこの辺は静かに読んでない感。

大量の TIPS 群なので、実際に手を動かしながらやると強力さが分かったりするものもあるんだろーな、と思いながら紙でずっと読んでました。
私としては、使えるものをいくつか拾えたら良いのかな、ってスタンスなのでたぶん使えそうなやつを使うくらい。自分の使いたいように使えば良いと思う。(投げやり)

あと、プラグインの解説とかはメインでは無くて、標準の Vim じゃできないことも、これを入れれば、できるんですよ、みたいな話は無し。コラムにちょろっとあるけれど。 Kana さんと Tim Pope さん流石っぽい。あと KoRon さんとか mattn さんとか名前が載ってたり。
便利なプラグインを入れよう、とかそういう役目は Vim テクニックバイブル担当そうですね。

基本の機能解説には良いと思います。
個人的には基本的機能解説は入門vi を読んでしまったのでそっちが印象強いですが。
Vim を使うならこっちから読んでも良いのかな、でも入門viの方が薄いし。うーん。
とりあえず、入門vi (or|and) 実践Vim からの Vim テクニックバイブルの流れが良さそう。

2013/09/10

リファクタリング・ウェットウェアを読んだ

リファクタリング・ウェットウェアを読みました。

2009年の本らしいです。
なんで今読んだかと言えば、本屋でふらふらまわって立ち読みしてて見付けてしまったので。この辺は本屋流石ですね。

さてこっちも確か読み終わったのは昨日。
最近は一日数章読んで数日かけるスタイルかもしれない。単に一気に読み切る集中力が無いとも言う。

内容としては達人プログラマをちょっとアップデート + プログラマ臭が少し抜けた、みたいな印象。達人プログラマは全部読んでないので憶測ですが。

割と心理学とかそーいうもの寄りで、効率良く学ぶには、みたいな話とか。
心理学うんぬんで若干うさん臭いけれど、「うさん臭い話ですが」みたいな書き方されてる。根拠が不明瞭な分ちょっと違和感はある。ただ、こういう役に立ちそうな話ありますよ、みたいな感じ。

特に印象的なのがドレイファスのモデル。
「技術を修得するためにはこのような段階を持つ」みたいなの。
実際、これが正しいかとかは謎だけれど。

一応、具体的な学習例とかあるかな、とか思ったけれど割とアバウト。
方針は示してくれるので、本に書かれている通り「レシピ」チック。

「毎年言語を学べ」みたいに、達人プログラマの方が具体的なのかも。あれ。「学べ」って具体的かな?
学習の仕方とかも「目標立てよう」とか。確かに立てた方が良さそうだけれどどうしようーん。みたいな。いやそれも含めて自分で考えなアカンのか……。

うさん臭いうんぬんと言えば、脳の仕組みの活用とかいろいろあったり。別に否定してる訳じゃないけれど。いかに効率を上げるか、みたいなのが大量にあるから少しでも取り入れると良いんじゃないかなー、みたいなスタンスで読んでました。

あとは印象的な単語はエクソコーテクス。
実を言えば「エクソコーテクス」って単語は憶えていなかった。
エクソコーテスが何かと言えば、外部脳、らしい。
本とかを丸暗記するんじゃなくて「この本にはアレが書かれてた」って憶えれば、その知識は活用できるし丸暗記の労力は減るよね。みたいな。
私が「エクソコーテクス」って単語を忘れたら恐らくこの記事を見るはず。ちゃんと「そういうものが残ってる」って憶えてればだけれど。

効率を高めるためのtips集みたいな感じだったかも。

というか Teem Geek といいリファクタリング・ウェットウェアといい、最初の章はインパクト強めなー。立ち読みを買わせる戦略か何かなのだろうか。

Teem Geek を読んだ

Teem Geek を読みました。xHago とかで評判が良かったので読みました。

というか読み切ってました。実を言うと数週間前くらいに読み終えて、感想を今書こうかとしてるところです。
割と記憶が薄れ気味なのでパラパラ捲ったり目次を読みながら書くことにします。

記憶薄れてるってことは微妙だったのか感あるので、まずは憶えてることから。
印象としてはやっぱり HRT 。

Humility - 謙虚
Respect - 尊敬
Trust - 信頼

人と関わるんならこれを信条にしよう、みたいなもの。
確かにHRTを実践できると悪く思う人は減りそうだなー、とは思いました。
ただ、これができたら苦労しないよね、とか思ってしまうので私にはまだまだ精進が必要そう。

次に憶えてるエピソードは文化を大事にしよう、みたいな話。
ここで言う文化はコーディングスタイルとかで、オープンソースなソフトウェアに「とても良い機能だけれど文化が少し違う」ものを取り入れるかどうか、みたいな。
Teem Geek で出てきたエピソードでは、文化を優先するためにそのコードは取り入れてませんでした。そこまでするのかー、と印象に残ってます。
あとは天才の神話とか。「一人でやるには限度がある」とか「誰もが一人で籠って完璧なのを作り幻想を抱くが幻想だ」みたいな感じ。

この辺からパラパラ捲りつつ書きつつ。

全体的な印象としてはオープンソースのコミュニティの失敗例と成功例、みたいな感じ。
「ギークでなくても本書のアドバイスは読む価値がある」って帯に書かれているんだけれど、やっぱり目線はギーク寄りなのかな、とか思う。
なんだろ。この文脈としての「ギーク」は「創造的なことをする」とか「複雑なことをする」とか「それ以外のことに苦痛を感じる」みたいなニュアンスかな。

ブログに感想を書いていて思ったのだけれど「そういう人達の処世術」とかみたいな意味合いっぽいな、とか。この本を一言で言うなら割とそれっぽい感。
最初の辺りに書かれているのが「チームワークについてどう思うか」で「誰も信じられない」とかだし。
この部分立ち読みして買ったのもあるのだけれど、割と冷静に見ると失礼だよなー、とか思う。いや確かにチームワークの思い出には苦いものが当然あるんだけれど。
そういう人に向けてるんだろーな、とか思いました。

ちなみにそういった内容エピソードとしては、チームワークの残念例とか、その対処とか、組織でこの先生きのこるには、とかとか書いてありました。
割とあるある事例紹介みたいなところもあるので、てっきり自分がギークなのかと思わせてしまう辺りも流石かもしれない。
そしてその事例に俺はこうしたぜ、的な。それこそ経験をまとめて本にしちゃいましたー、って流れなのかもしれない。

チームワーク面倒、とかって思ってしまったことある人向け本なのかもなー、とか思いつつ。

2013/07/15

すごいHaskellたのしく学ぼう! を読み終えた

いわゆる「すごいH本」を一応読み終えました。一応。

実を言うとゴールデンウィークくらいから読み始めて、しばらく読んだあとに時間が取れなくなって放置、そして今さっき最後まで読み終える、みたいな流れでした。
ながいごーるでんうぃーくだったなー。

Haskell の入門書として良い感じ、という評判に漏れず、いろいろとさらえた感じ。
実際 Haskell 使ってるわけじゃないので、まだまだ入口にも辿りついてない可能性もありますが。
とりあえず内容としては基本的な構文から関数定義に始まり、再帰関数の話や型定義、くらいまでが他言語から聞いたことあるような話。
んで、 IO, Functor, Applicative Functor, Monad, Zipper くらいから Haskell 特有な感じかなー、と。

こうやって書いてると Haskell 特有なところ、理解度低い感じしてかなしい。
とりあえず、Haskell書くなら手元に置いておきたい一冊かなー、と思う。

んで、Haskell そのものについてコメントるのは以下くらい。

pattern match
guard
where
data type
Functor, Applicative Functor
Monad

pattern match

Haskell では関数定義の時にパターンマッチって構文があるみたいです。
こんなん。

fib 0 = 0
fib 1 = 1
fib n = fib(n-1) + fib(n-2)

フィボナッチ数列を計算する fib 関数。
fib に渡す値が 0 ならー、みたいな if を書かずに書ける、って感じみたいです。
0ならこう、って直接書ける。
あと、 pattern match を使えば強制的に早期 return になるのも良いなー、と

guard

pattern match の条件版みたいなやつ。
こんなん。

isPlus n
| n > 0 = True
| otherwise = False

これは0より大きかったら True を、それ以外は False を返す関数。
条件にあったらここ実行して、みたいなやつをこう書ける。
もちろん条件は複数書いて良い。
otherwise が case の default というか else というか。
pattern match もだけれど、上から調べていくので、 Haskell は巨大な switch 、とかって言ってる方もいたよーな。
これも早期 return っぽくなるし、良いんじゃないかなー、とか

where

これも関数定義。
関数のみ有効なスコープの関数を定義できる。
lambda 以上定義した関数以下、って気分。
スコープを汚さずに、繰り返し処理を書かなくて良い感じ。
let でも同じことができるっぽい。 let は上に書いて where は下に書く。個人的には where 派かも。
こんなん。

squareMinNumber x
    | square x > 100 = x
    | otherwise      = square x
    where square x = x * x

2乗して100以上ならそのままの数値、100以下なら2乗する、って関数。
x * x を2回書かなくて良い、みたいな。

data, class

この辺からあやしい。
とりあえず、型変数が無い型は enum みたいだなー、とか思ったり。
型変数があるやつは class 的に扱えば良いのかな、とか思うけれど自作する場面がふと思いつかない。
木構造とか、リストとか、自分でデータ型を定義とかしないと恩恵や実感湧かなさそう。むむ。
class はなんか Java の Interface チック。
この型 class に所属するものはこの関数が使える、みたいな。

Functor, Applicative Functor

この辺までくると言われたことをやってる感じ。
Functor で包む利点ってなんなのかなー、とか思い始める。
リストは非決定性演算に使えるっぽいけれど、発想が未だArrayなので追いついてない感。

Monad

よー分かんない感じになってくる。
とりえあずいろんな記事とか見てて「プログラマブルなセミコロン」とかあったので、自分なりにMonadを作ってみようとしたけれど ghc に怒られてる。
個人的には、>>= を使って Monad な演算をする分には「モナドに包まれた値に対する演算時に、モナドに付属する値(Maybeとか?)にも演算が同時にできる」ものだと思ってるけれど。
実際謎っぽい。ぐーぬ。
とりあえずもしちゃんと書けたら記事を書こうとは思っている。
もしかしたら「書けませんでした」記事になるやもしれない。
あ、でも Maybe Monad 便利そうだなー、とは思った。使えるかどうかはアレ。

まとめ

Haskell分かってない。

登録: 投稿 (Atom)