カテゴリ: 書評

すごく面白かった!!

一時期流行った腐女子彼女というBlogの作者さんによる小説です。今作の主人公も著者とその体験が色濃く投影されており、掛け合いのノリは腐女子彼女とそっくりで、ああいう感じのラブコメが楽しい人には大変楽しいと思います。

ラストにちょっとしたどんでん返しがあるのですが、そのへんがちょっと昔の自分とオーバーラップするところがあり号泣してしまいました。(あとから考えてみると、あそこで風邪をもらってきただけかもしれない)

星5つあげる。



このエントリーをはてなブックマークに追加

セプキャン同窓会ことセキュリティ・キャンプフォーラム2014 に参加してきたのですが、そこであのへんの頭おかしい連中 バイナリに知悉した講師陣が新しい本を書いたと知りました。
ここでAmazonから紹介をピックアップしましょう

「5・7・5・7・7 」三十一(みそひと)バイトの機械語コードでなにができるか?
"遊び"と"ルール"の下で行うプログラミング「アセンブラ短歌」を完全解説。

機械語コードはアーキテクチャによってさまざまですが、可変長の命令を持つものならば命令の並びに5・7・5・7・7 各バイトに区切りを持たせることが可能です。あえてそのような制約のもとでプログラムを書いてみようというのが「アセンブラ短歌」です。どのような動作のプログラムになるのかもあわせて紹介していきます。

自然言語における「短歌」も制約を持たせた「言葉遊び」として生まれました。こうして書かれた文章には「味わい」や「感動」があります。それが長い年月をかけて発展し、格調高い文化として成熟してきたわけです。「遊びとルール」の下で行うアセンブラプログラミングを「近未来の文化的趣味」として楽しむため本書は執筆されました。

5・7・5・7・7 合計31バイトという制約を守るにはコツや試行錯誤が必要です。望みどおりの出力結果を得るために必要となる"短歌詠み"の基礎から技巧まで、本書にはプロ歌人の知恵が詰まっています。技術的な内容も多少なりともありますが、それよりも「味わい」のあるプログラムを多く扱うように心がけました。
Chapter.5ではさまざまな歌人による、浪漫主義(明星派)、写実主義(アララギ派)、新現実主義(新思潮派)、理想主義(白樺派)のアセンブラ短歌も紹介していきます。

アセンブラという実用言語が文化の域に到達していく過程の時代の証人に、あなたもなってはみませんか?



のっけから溢れ出る日本語でおk感がすばらしいですね!(謎

当日は、XSS短歌(XSSで5・7・5・7・7を守る)とバイナリ短歌のどっちが高尚か、とか季語が欲しかったのでSJISとして開くと半角カナで キゴ って入るような命令列を研究したとか、手遅れ感溢れるキチガイ話をたくさん聞いて大変面白かった。
愛甲さんは表紙を自分にデザインさせてくれればベストセラーになったはずなのにと息巻いていたが、はせがわさんに、そもそもこんな本、商業誌で出版されたこと自体が頭おかしいわ。編集は止めるべきだろ! と突っ込んでいたのが超おもしろかった。

というわけで、バイナリアンは全員購入して続編が出せるようにしてあげるといいと思うよ!


このエントリーをはてなブックマークに追加

タイトルにつられて買ったけど、ただのストーリー万歳本だった。このへんもうちょっと深堀りした本はないかねえ。



このエントリーをはてなブックマークに追加

献本御礼。



いつもお世話になっている西尾大先生から献本もらったので、うきうきしながら読みました。

この本をひところで説明するのは大変難しいのだけど、あえていうなら、プログラミング言語の進化よもや話としての読み物の側面と、これから自分の言語を作ろうと考えている人に向けた現在の言語たちの言語仕様のバックグラインドを説明する教科書的な側面があると思う。

C++の世界には「C++の設計と進化」(別名 D&E)というものすごい有名な本があるのだけれども、文体・書かれている内容ともにまったく似ていないのだけれど、読後感は驚くほど似ている。D&EはC++に絞って言語の進化の歴史となぜこの機能を採用したか、なぜ対案を採用しなかったかを記述しており、大変歴史的価値が高い逸品なのであるが、西尾本はプログラミング言語全体において、現代のモダンな言語で使われている諸機能・言語仕様について歴史をさかのぼり、たのしいトリビアを交えつつ設計の背景を教えてくれる。



この本が素晴らしいのは、「どこから調べてきたんだ」唸ってしまうトリビアの数々によりあきさせないこと。それぞれの章が完全に独立して読めるよう注意深く配慮されており、時間がないときでもどこからでも読めるようになっていること。
また、この手の歴史的な経緯を記述する本は往々にして、もう誰もしらない様な古代言語の話で埋まってしまい読んでいて退屈になってしまうのが常であるが、コードが出てくるのは C, Ruby, Perl, Python, JavaScript といった現代言語にだいたい限られており、それ以外は図を多用して説明してくれているので、年代問わず楽しめる書籍になっていることがあげられると思う。

「成り立ちから学ぶプログラミング作法」という副題から感じるニュアンスとはちょっと違って、おっさん層よりも、これからオレオレ言語を作ろうと考えている学生におすすめしたい。


なお公式紹介ページはこちらです: http://nhiro.org/langbook/


目次はこんな感じ

目次

第1章 言語を深く効率的に学ぶには
1.1 比較から学ぶ
1.2 歴史から学ぶ
1.3 まとめ

第2章 プログラミング言語を俯瞰する
2.1 プログラミング言語誕生の歴史
2.2 プログラミング言語の生まれた目的
2.3 まとめ

第3章 文法の誕生
3.1 文法って何だろう?
3.2 スタックマシンとFORTH
3.3 構文木とLISP
3.4 中置記法
3.5 まとめ

第4章 処理の流れのコントロール
4.1 構造化プログラミングの誕生
4.2 ifが生まれる前
4.3 while ──繰り返しのifを読みやすく表現
4.4 for ──数値を増やしながらのwhileを読みやすく表現
4.5 まとめ

第5章 関数
5.1 関数の役割
5.2 戻る命令
5.3 再帰呼び出し
5.4 まとめ

第6章 エラー処理
6.1 プログラムも失敗をする
6.2 失敗をどうやって伝える?
6.3 失敗しそうなコードを囲む構文
6.4 出口を1つにしたい
6.5 どういうときに例外を投げるか
6.6 例外の伝搬
6.7 まとめ

第7章 名前とスコープ
7.1 名前はなぜ必要だったか
7.2 スコープの進化
7.3 静的スコープは完成形?
7.4 まとめ

第8章 型
8.1 型とは何か
8.2 数値をオンとオフで表現する方法
8.3 1つの位に必要なランプはいくつか?
8.4 実数はどうやって表現しよう
8.5 型は何のため?
8.6 型のいろいろな展開
8.7 まとめ

第9章 コンテナと文字列
9.1 いろいろな種類のコンテナがある
9.2 なぜいろいろな種類のコンテナがあるのか
9.3 辞書,ハッシュ,連想配列
9.4 文字とは何か
9.5 文字列とは何か
9.6 まとめ

第10章 並行処理
10.1 並行処理とは何か
10.2 細かく区切って実行する
10.3 処理を切り替える2通りの方法
10.4 競合状態を防ぐには
10.5 ロックの問題点と解決策
10.6 まとめ

第11章 オブジェクトとクラス
11.1 オブジェクト指向とは何か
11.2 変数と関数を束ねて模型を作る方法
11.3 方法1 モジュール,パッケージ
11.4 方法2 関数もハッシュに入れる
11.5 方法3 クロージャ
11.6 方法4 クラス
11.7 まとめ

第12章 継承によるコードの再利用
12.1 継承とは
12.2 多重継承
12.4 まとめ


このエントリーをはてなブックマークに追加

献本御礼
なんで献本もらえたのかまったく不明なんだけど(^^;

ちまたではデバッグ三部作のトリを飾る一作と呼ばれているらしい。

いちおう、DDDとEclipseについても書いてあるけど、メインはどうみてもgdb。なので、Linux上でC言語開発をする羽目になった新人プログラマが読むと、一気にスキルが上がってお得。
昔、新人教育をやっていた時代にこれがあったら、全員に買わせたかもしれん。

ちょっと、長いけど目次を引用

推薦の言葉
まえがき
1章 初心者にもプロにも役立つ予備知識
1.1 本書で扱うデバッガ
1.2 使用するプログラミング言語
1.3 デバッグの原則
1.3.1 デバッグの本質:確認の原則
1.3.2 確認の原則にとってデバッガの価値とは?
1.3.3 その他のデバッグ原則
1.4 テキストベース vs. GUIベース(そして両者の折衷形態)
1.4.1 インタフェースの簡単な比較
1.4.2 テキストベースとGUIの折衷形態
1.5 デバッガの主な操作方法
1.5.1 ソースコードをステップ実行する
1.5.2 変数を調べる
1.5.3 変数の変化を「広域指名手配」する
1.5.4 呼び出しスタックを上下に移動する
1.6 オンラインヘルプ
1.7 最初のデバッグ作業
1.7.1 GDBを用いる
1.7.2 DDDを使った実演
1.7.3 Eclipseを使った実演
1.8 初期化ファイルの使用
2章 調査のために実行を止める
2.1 停止の仕組み
2.2 ブレークポイントの概要
2.3 ブレークポイントを追跡する
2.3.1 GDBでのブレークポイント一覧
2.3.2 DDDでのブレークポイント一覧
2.3.3 Eclipseでのブレークポイント一覧
2.4 ブレークポイントを設定する
2.4.1 GDBでブレークポイントを設定する
2.4.2 DDDでブレークポイントを設定する
2.4.3 Eclipseでブレークポイントを設定する
2.5 GDBの発展例題
2.6 ブレークポイントの持続性
2.7 ブレークポイントを削除・無効にする
2.7.1 GDBでブレークポイントを削除する
2.7.2 GDBでブレークポイントを無効にする
2.7.3 DDDでブレークポイントを削除・無効にする
2.7.4 Eclipseでブレークポイントを削除・無効にする
2.7.5 DDDでブレークポイントを「移動する」
2.7.6 DDDでブレークポイントの操作を元に戻す/やり直す
2.8 ブレークポイントの属性を詳しく見る
2.8.1 GDB
2.8.2 DDD
2.8.3 Eclipse
2.9 実行を再開する
2.9.1 GDB
2.9.2 DDD
2.9.3 Eclipse
2.10 条件つきブレークポイント
2.10.1 GDB
2.10.2 DDD
2.10.3 Eclipse
2.11 ブレークポイント・コマンドリスト
2.12 ウォッチポイント
2.12.1 ウォッチポイントを設定する
2.12.2 式
3章 変数を調査・設定する
3.1 メインの例題コード
3.2 上級の変数調査・設定法
3.2.1 GDBでの調査法
3.2.2 DDDでの調査法
3.2.3 Eclipseでの調査法
3.2.4 動的な配列を調べる
3.2.5 C++ではどうなるの?
3.2.6 ローカル変数を監視する
3.2.7 メモリを直接調べる
3.2.8 printとdisplayの上級オプション
3.3 変数を設定する
3.4 GDB独自の変数
3.4.1 値の履歴を用いる
3.4.2 簡易変数
4章 プログラムがクラッシュしたら
4.1 背景知識:メモリ管理について
4.1.1 なぜプログラムはクラッシュするのか?
4.1.2 プログラムのメモリ配置
4.1.3 ページの概念
4.1.4 ページテーブルの役割の詳細
4.1.5 軽微なメモリアクセスのバグはセグメンテーション違反に
   ならないこともある
4.1.6 セグメンテーション違反とUnixのシグナル
4.1.7 他の種類の例外
4.2 coreファイル
4.2.1 coreファイルの生成方法
4.2.2 シェルによるcore生成の抑制
4.3 例題の拡張
4.3.1 最初のバグ
4.3.2 デバッグ中はGDBを抜けないこと
4.3.3 2番目と3番目のバグ
4.3.4 4番目のバグ
4.3.5 5番目と6番目のバグ
5章 多重実行環境でのデバッグ
5.1 クライアント/サーバ型のネットワークプログラムをデバッグする
5.2 スレッドコードをデバッグする
5.2.1 プロセスとスレッドのおさらい
5.2.2 基本的な例題
5.2.3 バリエーション
5.2.4 GDBのスレッドコマンドのまとめ
5.2.5 DDDのスレッドコマンド
5.2.6 Eclipseのスレッドコマンド
5.3 並列実行アプリケーションをデバッグする
5.3.1 メッセージパッシングシステム
5.3.2 共有メモリシステム
5.4 拡張した例題
5.4.1 OpenMPの概要
5.4.2 OpenMP例題プログラム
6章 特別な話題
6.1 コンパイルもロードもできないときにはどうすればいいですか?
6.1.1 文法エラーメッセージの実体のない行番号
6.1.2 ライブラリが見つからない
6.2 GUIプログラムをデバッグする
6.2.1 cursesプログラムをデバッグする
7章 他のツール
7.1 テキストエディタを活用する
7.1.1 文法ハイライト
7.1.2 カッコの対応づけ
7.1.3 VimとMakefile
7.1.4 Makefileとコンパイラの警告メッセージ
7.1.5 テキストエディタをIDEとみなす最終的な考え
7.2 コンパイラを活用する
7.3 C言語でのエラー報告
7.3.1 errnoを用いる
7.4 straceとltraceを使った快適な暮らし
7.5 静的コードチェッカ:lintとその仲間
7.5.1 splintの使い方
7.5.2 最後に
7.6 動的確保メモリをデバッグする
7.6.1 DAMの問題を発見する戦略
7.6.2 Electric Fence
7.6.3 GNU Cライブラリのツールを使ってDAMの問題をデバッグする
8章 他の言語にGDB、DDD、Eclipseを用いる
8.1 Java
8.1.1 JavaをデバッグするのにGDBを直接用いる
8.1.2 JavaをデバッグするのにDDDをGDBと一緒に使う
8.1.3 DDDをJDBのGUIとして用いる
8.1.4 EclipseでJavaをデバッグする
8.2 Perl
8.2.1 DDDを使ってPerlをデバッグする
8.2.2 EclipseでPerlをデバッグする
8.3 Python
8.3.1 DDDでPythonをデバッグする
8.3.2 EclipseでPythonをデバッグする
8.4 SWIGコードをデバッグする
8.5 アセンブリ言語
付録A Visual C++を用いたデバッグ
A.1 ビルドと実行
A.2 中断と変数の表示
A.3 ブレークポイント設定と実行再開
A.4 不正メモリアクセス
A.5 マルチスレッドのデバッグ
A.6 その他の便利な機能
訳者あとがき
索引


最初の方の1-3章ぐらいがデバッガの使い方解説みたいな感じ。gdbのinfoは章立てが腐っているので、同じ事を書いていてもすごく分かりやすく、理解しやすくてよい。

4章が、coreファイルからバグを特定するまでの実例の解説。こういうのって説明が難しいんですよね

5章がこの本の白眉(だと勝手に思っている)マルチスレッド・マルチプロセス環境のデバッグ方法の解説。
近年、CPUのマルチコア化が進み並列化テクニックを使ったソフトウェアが増えてきたけれども、MPI、OpenMPのデバッグ方法を解説した文献はこれが初めてではなかろうか?

6章は、デバッグ効率あげるなら、ツールも大事だよー。という趣旨のTips集。まあ、たいていのTipsはインターネットで見つかるんですが、まあ、まとまっているのが意味があるのかなと。


Debug Hacksは、読者層を絞り込みすぎているので、なかなか人に紹介しにくいという意見を聞くが、こっちは大学生~新人プログラマに対象を絞っているので、会社の若い連中とかに強くオススメできるいい文献となっている気がします。

デバッガを使いこなしていないなー、という諸兄は是非手にとっていただきたい。デバッグ時間の節約は開発効率に直結するよ

ではでは


併せて読みたい、有名人の書評
やねうらおさん: http://d.hatena.ne.jp/yaneurao/20090604
憂鬱な午後のひとときさん: http://homepage1.nifty.com/herumi/diary/latest.html




このエントリーをはてなブックマークに追加

いつまでもデブと思うなよ で一世を風靡した岡田 斗司夫のオバカ本。

視点が新鮮なので、結構楽しめた。
でも調査不足が感じられるので、このネタで1年間講義とはできまい。とかおもた

まあ暇つぶしにはいい感じですよ。安いし。
あと死ね死ね団超カッコイイ!!


このエントリーをはてなブックマークに追加

Becky用プラグインがあることを知ったのでGoogle Desktopをインストール。
うむうむ、いい感じ。

メールって数が増えると検索がむっさ大変になるんだよね。

ついでに、カレンダソフトやら、タスク管理やらも全部Google Desktopさんへ移す。
しばらくこれでやってみる
このエントリーをはてなブックマークに追加

最近、スケジュールがぐちゃぐちゃ
このエントリーをはてなブックマークに追加

最近読んだ本シリーズ


結局いいたいのは


・日本はアメリカにとって(地政学的に)超重要な同盟だからそうかんたんには、切られない。もっと無理いってもヘーキ


・自衛隊には敵国に兵力を投入する能力が徹底的に欠けているので、自力戦争は無理。だから日米同盟重要だし、ぎゃくに近隣諸国にはこの事を明確につたえて日本脅威論を排除すべき


の二点だけなのかとオモタ。


データとかがすくないので、それ以上は著者の感想にすぎず、あまり意味ないかもしれん。


 



このエントリーをはてなブックマークに追加

いやあ、こんな素晴らしい本をタダでいただけるなんて素晴らしいですね。
ありがとうございます > 高林様、オラ入りー様
 

なにかhyoshiokさんの所では、若干厳しめのレビューをされてるみたい。

たぶん、NHKに取り上げられた 女子大生のブログ炎上とかの記事をみて、ベタ褒めすると炎上する日本のBLOG力学に思うところがあったに違いない。

と、無理やり時事ネタに絡ませつつ、おもしろいから、ここは一発絡んでおこう。
 

#94「プロセッサのメモリオーダリングに注意」の例のプログラムだが、これはメモリオーダリングの例ではなくてアトミックな交換(xchg)が出来ていない例なのではないだろうか?



いやいや。
#94の例では lock_array[me] を変更するのは自分だけで、lock_array[other]を変更するのは相手だけなのでxchgは必須じゃないですよ。
(lock_array[me]を変更するのが自分だけである以上、変更直前の値はかならず自分が前回設定した値だから、チェックするまでもない)

アプリケーションレベルでメモリオーダリングに注意しなければいけない例というのはあまり思いつかなかったのでもし適切な例があればご教示いただきたいところである。



”double checked locking”あたりで検索するといろいろと出てきますよ。
無理やり要約すると

・パターンハッチング(ジョン・ブリシデス著 ビアソン)にてdouble checked lockingパターンが紹介される
・JavaでJavaVMのメモリオーダーが原因でdouble checked lockingパターンを使うとある種のJIT VMでうまく動かない事が報告され、話題になる
・C#はvolatileにメモリオーダー的な意味を追加して、この問題を回避
・Javaもそれに追従して、volatileの意味を改定
・実は元々のC++にも同じ問題があるのだけれど、完全に置いてきぼり(n'ω'`) <--今、ここ


正味の話、たとえば、int変数1個writeするだけだと、strong memory orderだと、pthread_mutex_lockかけなくても正しいけれど、現実のプロセッサはそうではなく、かつ、そのようなメモリオーダーの話が「一般のプログラマには難しすぎるから」というよく分からない理由でmutexとかの説明にマトモに解説されていないので、似たようなバグが次々と量産されているという感じ。

オイラ、元々組み込み屋さんだから、こういうタイミング問題は何回も痛い目にあっているので。

まだ、全部読んでないのでちゃんとした書評はあとで書こうと思うけども、今回はこんなところで。


P.S.
と、ここまで書いてから#94は、double checked locking パターンを題材に書き直せば作為的度が減って、よりグッドになりそうな悪寒がしてきた。
うーん、惜しい。


↓ 初回限定カバーはこんなのらしい
BinaryHacks初回限定カバー



 
このエントリーをはてなブックマークに追加

↑このページのトップヘ