本の件
引き取ってくださる人からメールが届いてうれしい限りです。
今週末くらいで締め切ろうと思います。
Twitterで欲しいって言った人もメールください。
いろいろあって、本を150冊ほど捨てることにしました。
要らない本の中でも、捨てるに忍びない本があるので、引き取ってもらえる方を募集中です。
人助けだと思って、引き取ってください。
・Joelっぽい本
全部まとめて引き取ってくれるとうれしいです。
Joel on Softwareのみ、先ほど娘がカバーを外してどっかにもっていってしまいました。カバー無しです。
Joel on Software http://www.amazon.co.jp/dp/4274066304
More Joel on Software http://www.amazon.co.jp/dp/4798118923/
Eric Sink on the Business of Software http://www.amazon.co.jp/dp/4798117501/
BEST SOFTWARE WRITING http://www.amazon.co.jp/dp/4798115819/
ソフトウェア開発者採用ガイド http://www.amazon.co.jp/dp/4798115827/
・アジャイルとか
専門じゃないので良い本かどうかは判断できませんが、それなりに話題にはなった本です。
テスト駆動開発入門 http://www.amazon.co.jp/dp/4894717115/
eXtreme Programmingテスト技法―xUnitではじめる実践XPプログラミング http://www.amazon.co.jp/dp/4798101281/
アジャイルソフトウェア開発 http://www.amazon.co.jp/dp/4894715791/
リーンソフトウエア開発~アジャイル開発を実践する22の方法~http://www.amazon.co.jp/dp/4822281930/
・プログラミング
デバッグではじめるCプログラミング http://www.amazon.co.jp/dp/4798114197/
Jythonプログラミング http://www.amazon.co.jp/dp/4839922829/
並列論理型言語GHCとその応用 http://www.amazon.co.jp/dp/4320022661/
リアルタイムUML―オブジェクト指向による組込みシステム開発入門 http://www.amazon.co.jp/dp/4881359797/
オブジェクト指向入門 http://www.amazon.co.jp/dp/4756100503/
(版に注意してください。古い方です。ほとんど読んでないのですが、買ったときから色あせてました。)
・読み物
できれは高校生の人に読んで欲しいですが、高校生がここを見ているかどうか・・・・
数学ガール http://www.amazon.co.jp/dp/4797341378
青色に挑んだ男達 http://www.amazon.co.jp/dp/4532310873
・その他
シャドーワーク http://www.amazon.co.jp/dp/4492521631
プログラマ主役型プロジェクトのススメ ~ソフトウェア開発現場で本来の力を発揮するために http://www.amazon.co.jp/dp/4798106844
ウェブユーザビリティの法則 http://www.amazon.co.jp/dp/4797339098/
球場のビールはなぜ800円でも売れるのか http://www.amazon.co.jp/dp/4426497183
ゲームシナリオライターの仕事 名作RPGに学ぶシナリオ創作術 http://www.amazon.co.jp/dp/4797335963
ファシリテーション・グラフィック―議論を「見える化」する技法 http://www.amazon.co.jp/dp/4532312884
プロダクティブ・プログラマ -プログラマのための生産性向上術 http://www.amazon.co.jp/dp/4873114020/
正規表現とテキスト・マイニング http://www.amazon.co.jp/dp/4750318000
欲しい本がある方は、お名前、住所(送り先)、電話番号を書いて YRW03704@nifty.com までメールください。
電話番号は宅急便の送り先に記載します。私から電話をすることはありません。
収入の少ない人、学生の人を優先したいので、学生か社会人かも教えてください。
目標は8月中に全員に発送です。
ここを見ていると、ソフトウェアのエンジニアと、ハードウェアのエンジニアの違いが分かって面白い。
元のタイトルの釣り能力が高いというか、上手いので、僕も含めて見事に釣られている。仕事で電子工作をやっていると、完成品を動かすのを「電子工作」と呼ぶには抵抗があって、僕自身もぶくまでそんなことを書いてしまったわけです。
あとあと考えて見ると、あそこに「これは電子工作じゃねーよwww」って書く事に何の意味も無いというか、上から目線だなぁと反省しているところ。言葉遊びよりも、あれを見て「ちげーよ」って言っちゃう自分が嫌になった。最初は完成品で遊べば良くて、どうしてもしたいことができなくなったら、外付けでFPGA足すとかファームいじるとかそんな感じで行けば良いんだよな。
Twitterを見ていて、あーこれ僕には絶対無理だってのがあってタイミング無茶苦茶だけど紹介する。
一つ目がずいぶん前の話だけど、mootoh さんのゆびピアノ。ちなみにこの人の名前の読み方が未だに分からない。
http://www.nicovideo.jp/watch/sm2757949
動画を見てもらうと分かるんだけど、ゆびピアノっては、LSIと電池とスピーカとスイッチからできてる。ハードの仕事をしていると、ゆびピアノの本体はLSIなんですよね。mootoh さんが動画の中で言っているように、ゆびの部分はただのスイッチなんですよ。
で、mootoh さんはスイッチとGainerを接続して「ゆびピアノ」と言い張るわけです。この発想は本当素晴らしい。どうしても「いやいやそれはスイッチだから」って突っ込んでしまう。
もう一つが、SPACE BIKE ってやつ。
http://www.madin.jp/diary/?date=20090522
僕は勝手に「てんくうの自転車」って呼んでるんだけど、多分僕だけ。早く地図をドラクエやらFFの世界に対応して欲しい。先に図をもらえたら(お金使って)同じ物は作れるだろうけど、先にハードウェアありきで行くとこんな感じにはならないだろうなと思う。これも Gainer なんだけど、どう見ても作っている人ハードは詳しく無さそう。でもこんなに素晴らしい物ができる。
僕の知らない間に、凄い世の中になってる。ちげーよ!って言ってる暇があったら、自分も手を動かさないと!
この時代にエンジニアでいられることは、本当幸せだと思う。
・Hack the Cell
http://shinh.skr.jp/htc/000.html
これは凄い。
ここまで最適化してもらえるんだったら、CELL開発した人もうれしいだろうな。
・本
http://d.hatena.ne.jp/monamour555/20090603/1244022746
『ところで,品質だ信頼性だと叫んでいる組込み屋方面から,類書が出てきそうな雲行きは全くない.上流設計とテストさえ頑張れば品質はOK?』
同じようなことを考えていて、Concepts, Techniques, and Models of Computer Programmingやら、Java Concurrency in Practiceを読んでいると、スレッドモデルのConcurrencyってのは、組み込み屋の方が10年くらい先を行っている気がする。が、同じレベルの本が出てくるとは思えないんだよな。残念です。
読みました。
http://www.amazon.co.jp/exec/obidos/ASIN/4062837072/
印刷物だから最後まで読めたミステリー。
残りの割合がわからない電子書籍なら100%投げ出していたと思う。4/5はだらだらと話が続いて、最後一瞬盛り上がって、そのまま終わるような作品。
感想を書こうとしたけど、ここが良くまとまっていた。
http://d.hatena.ne.jp/kamiharu/20090516/1242487930
こういうのを読むと、突っ込み所はあるんだけどぐっと読めてしまう西尾維新は素晴らしいと思う。
東北大大学院生が自殺
http://www.yomiuri.co.jp/national/news/20090513-OYT1T00525.htm
准教授が叩かれているけど、問題なのは個人のさじ加減でどうとでもなってしまうシステム。数がいれば変なのも絶対にいるので、変な奴がいる前提のシステムにしないといけない。
あとは親より先に死んじゃいかんと思う。
さくせん:おかんだいじに
タイトルは釣り><
Debug hacks conferenceにもいけず、Debug hacks自体も入手出来ず、流れは読んでませんがそれはデバッガ関係無いですよねに反応。
僕にとってデバッガってのはICEとセットで使う物で、三次元のイメージなんですよね。
参考画像:ICE画像(微エロ)
JTAG ICEが一般的になる前は、ICEってのは測定器と一緒で貴重な物でした。ICE専用に別基板を起こしたり、剣山の上にCPUを乗せてちょっとでも斜め向くと動かないくせにケーブルが重いとか。電源の投入順序で電気的に壊れたりしました。今はJTAG+メモリ読み出し用のコネクタ程度で済むので良い時代になりました。
そんな僕はデバッガやコンパイラに手をいれるなんてとんでもないと思っているので、デバッガに手を入れていくというのに驚きました。この手の開発環境側に手を入れるのはリスクが大きくて、まあ仕事ではやらない。リスクが大きいってのは「手を入れた影響が把握できないから」につきる。デバッガ、コンパイラに比べるとRTOSをいじるのは抵抗が少ない。例えば、割り込みハンドラをフックして何か処理入れるとか、割り込みから戻る時にどこかに履歴を残すとかは大丈夫。結局の所、こういう事をしても他の所への影響は少ない事を、僕が判断できるからだと思う。
一般的にどこに手を入れたら他への影響が少ないのかって事を考えると、出力だけなら影響ないでしょって事でprintfデバッグに繋がる。非同期な処理が絡むとprintfってのは時間的なコストが大きいので、別のやり方を考えた方が良くって、その話はWin32マルチスレッドプログラミングに書いてあった気がする。
組み込み機器ってのは電源落とすまで基本的には無限ループに入っているのでデバッガが使いにくい状況がでてくる。ブレークかけるとWDTが働いてリセットかかっちゃうとか、通信系の受信バッファがあふれた結果相手側がエラーを検知して落としに来るとか、デバッガの手の届かない範囲で、CPUが止まったらエラー通知してシステム落とせ!って状況がある。この場合は、どうせ落ちるのならブレークかけたいところでめいっぱい情報を残して、自分から落ちた方が良かったりする。でも、最近のデバッガは割り込みの処理だけはしてくれるブレークがあるらしい。素晴らしい。
逆にデバッガにしか出来ない事ってのももちろんあって、一番使うのが異常な状況を作り出すこと。「仕様としてはありえないんだけど、ここに不正なデータがあったらこういう動きするよね」って状況で問題を切り分けたい。前段の処理でエラーチェックしているから不正なデータを渡せない、今の動いているプログラムは手を入れたくない、となるとデバッガで無理矢理そういう状況を作るしかない。デバッガ様々です。
組み込みのデバッグ手法って、人から人へのイメージがあるから、組み込み用ICE/デバッガの使いこなし的な本は欲しい。デバッガの各機能がどういう仕組みで動いているのかの解説書も欲しいと思う。「アドレスXXXXにn回アクセスしたときのブレーク」ってのは、アクセスの感知はどういう仕組みになっていて、n回のカウントはどこの保持してあって、ブレークはどうやってかけているのか、は説明欲しい。
例えばROM ICEだとブレーク時にNMIを使う物がある。基板にロジアナを繋いでNMIでトリガーをかけると、ブレーク前後の基板情報が取れる。こういうのもデバッガの拡張に入るのかもしれない。こういうのができるかどうかってのは、やっぱり仕組みがわかっているかどうかに行き着く。
今のJTAGデバッガだとどういう拡張ができるんだろう。
JTAGデバッガだけじゃなくて、本当のバウンダリースキャンや、FPGAのコンフィグ系まで含めてJTAG HACKSなら一冊分のネタが集まる気がする。
Recent Comments