■

プログラミング言語C++ (アスキーアジソンウェスレイシリーズ―Ascii Addison Wesley programming series)

第4章　型と宣言

完璧でないものは受け入れるな。　無名氏

完璧が達成されるのは崩壊寸前のときである　〜C.N　Parkinson〜

http://d.hatena.ne.jp/book-lover/20090829:前回のエントリーで、アウトプットを出して、マネタイズをする事例をみたとき（宮沢さん、立花さん）、そこになにがしかの不完全があるということに
記述をさせてもらいました。
今回のこのプログラミング本の筆者も、そういった問題意識をおもわせる冒頭の引用がなされています。
CNParkinsonという人も、ある方面では有名な人のようですね。私は今回、はじめてこの人のことを知りました。ITの世界ではちゃんと評判のある人のようです。
紹介は、以下のWikipedia の記事の引用に頼りたいと思います。
あとは、このブログの作りこみをどこまでするかですね。がんがん、いろいろな内容を盛り込もうとすれば、「パーキンソンの法則」という書籍を買って、読んで、それについての書評と組み合わせたら、
いくらでも内容を膨らませるうことができるわけです。
実際、本を執筆するというのは、そういうことなのではないかなと思ったりします。

Cyril Northcote Parkinson (July 30, 1909 – March 9, 1993) was a British naval historian and author of some sixty books, the most famous of which was his bestseller Parkinson's Law, which led him to be also considered as an important scholar within the field of public administration.

In 1958, while still in Singapore, Parkinson published his most famous work Parkinson's Law, a book that expanded upon a humorous article that he had first published in the Economist magazine in November 1955, satirizing government bureaucracies. The 100-page book, first published in the United States and then in Britain, was illustrated by Osbert Lancaster and became an instant best seller. This collection of short studies explained the inevitability of bureaucratic expansion, arguing that 'work expands to fill the time available for its completion'. Typical of his satire and cynical humour, the book included a discourse on Parkinson's Law of Triviality (debates about expenses for a nuclear plant, a bicycle shed, and refreshments), a note on why driving on the left side of the road (see road transport) is natural, and suggested that the Royal Navy would eventually have more admirals than ships

情報システム用語事典：パーキンソンの法則（ぱーきんそんのほうそく） - ITmedia エンタープライズ

ミネソタから北浜へ (内田樹の研究室)

日曜日も朝から原稿書き。
『日本辺境論』、初稿を書き終わる。
１６万字。これでは新書にならない（厚すぎて）。
１３万字くらいまで削らないといけない。ただちにまた頭から書き直しを始める。
しかし、一応全体の構成が完成しているので、書き直しの作業は楽である。
話がくどいところ、繰り返しやわかりにくいたとえ話（というのが多いのだ）を削るだけである。

職業的に、字数を稼ぐ形で、アウトプットを出していくにはどうすればいいのか。
このエントリーを書きながら、私はそんなことを考えます。
完璧さをもとめるがゆえに、なにかやりたいことを途中で放り投げる。
これをやってしまうと、なにものも達成することが出来ない。
これは、私の中で、かなり経験があります。失敗の蓄積です。だからこそ、ないものがたくさんあってもいいから。一度やろうとしたことは、どれだけ不完全な形であれ、
コンプリートにまでもっていくのが大切なのではないか。私は、つくづくそう思います。

http://pukunz.blog32.fc2.com/?q=%B1%D1%B8%EC:虹はどこですか？

虹を見ると必ず思い出すのが、
数年前に日本からワーホリで来て
オークランドに短期間滞在していた友人のこと。

行動力があり、旅慣れている彼女は

「文法とか発音とかできなくても、
　自信持って話せば言葉なんて通じる！」

という千原せいじみたいな持論があり、
日本人にありがちな、すぐ喋れる人に頼るという
シャイさが無かった。
英語が全くできないのに、私と一緒にいても
通訳を頼まず自分で身振りを交えて喋る
ということを徹底していて、
あの間違いを恐れない姿勢はアッパレだった。

4-1　型　
　4-1-1　基本データ型
4-2　論理型
4-3　文字型
　4-3-1　文字リテラル
4-4　整数型
　4-4-1　整数リテラル
4-5　浮動小数点型
　4-5-1　浮動小数点数リテラル
4-6　サイズ
4-7　void
4-8　列挙

4-9　宣言　→ちょっとばかり、つくりが複雑になっています。「こうしてはいけないね」という形式のアドバイスと一緒になっている。
　　　　　　　他の単元との連携の場所が多く記載されています。つまり他のチャプタとの横断が大事。externの内容とか。

　4-9-1　宣言の構造
　4-9-2　複数の名前の宣言
　4-9-3　名前
　4-9-4　スコープ→これも考え方をちゃんと理解していないと、コードが読めなくなる原因になりそうだ。
　4-9-5　初期設定
　4-9-6　オブジェクトと左辺値→すこしわかりづらかった。あとでの復習が必要になると思う。
　4-9-7　typedef
4-10　アドバイス
4-11　練習問題

今日、購読したところは、そんなにしんどいところではなかったと思います。
データのタイプについて、あれやこれやとリスト的に述べているだけなので、
なにがどうと、論理的にしんどい、複雑とか。
そういうことはないわけです。
これから、だんだん、いやらしい分野に突入していくのでしょうけど。

それにしても、ソースコードがやっぱりあらっぽいよね。この人。