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/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)