西尾泰和のレビュー一覧

コーディングを支える技術――成り立ちから学ぶプログラミング作法

黄色のハイライト | 位置: 761
構文解析器（パーサ）は、ソースコードを文字列として読み込んで、それを解析し、構文木を作るプログラムです。FORTRANでプログラムがコンパイルされる際にも、この構文解析器がソースコードの文字列を構文木に変換する作業を行っている


黄色のハイライト | 位置: 773
情報は膨大です。「とにかく全部一通り勉強しよう」という戦略はもはや通用しません。必然的に「何を学ぶか、何を学ばないか」を決める必要が出てきます。そのときの指標になるのが「何を作りたいのか」目的を明確にすることです。そして目的を達成するために必要なことから学べばよいのか。


黄色のハイライト | 位置: 776
何を作るかを決めることができない？ もしかして、最初から完璧なものを作ろうと考えていませんか？ 誰も考えたことのないもの、みんなが絶賛してくれるものを作ろうと考えていませんか？ 最初からすごいものを作ろうと考えて、そのせいで手が動かなくなっているのだとすると、いつまで経ってもすごいものは作れないでしょうね。まずは簡単なものでよいので何かを作りましょう。


黄色のハイライト | 位置: 888
今では「コンパイルしてアセンブリ言語に変換し、アセンブルして機械語に変換し、リンクしてつなぎあわせて1つの実行可能ファイルにする」という一連の作業をまとめてコンパイルと呼ぶことも多いかと思いますが、ここではアセンブリ言語に変換することを指してコンパイルと呼んでいる。


黄色のハイライト | 位置: 1,392
1975年にJohn Goodenoughは自らの論文（ 注9）の中で、より良い例外処理の方法を提案しました（ 注10）。彼の主張はこうです。“プログラマは「命令が例外を投げる可能性があることを忘れる」「適切でない場所、または適切でない種類の例外処理を書く」などの失敗をする可能性がある。この可能性を減らし、プログラマがした失敗をコンパイラが警告できるようにするには、2つのものが必要だ。一つは命令がどういう例外を投げる可能性があるかを明示的に宣言させること。そしてもう一つは字句的に「失敗しそうな処理」を囲む構文。


黄色のハイライト | 位置: 1,573
こういう「おかしくなったら処理を停止して速やかに報告すべき」という設計思想は「フェイルファースト」と呼ばれています。ソフトウェアの目的によっては簡単に停止してもらっては困る場合もあるでしょうが、少なくとも学習や開発の段階では、間違えたときにすぐに間違えたことに気付けることのメリットは大きいです。


黄色のハイライト | 位置: 1,666
本章では、プログラムも失敗することがあること、そしてその失敗をどうやって伝えるかを学びました。失敗を伝える方法は大きく分けて2通りあります。「返り値で伝える」と「失敗したらジャンプする」。


黄色のハイライト | 位置: 2,217
銀行や為替などのお金を扱う分野ではこの振る舞いが嫌われるので、そういう場合には固定小数点数やエクセス-3のような10進法での計算が使われます。


黄色のハイライト | 位置: 3,252
一つは「切りの良いところで交代」です。処理の区切りが良いところで処理が自発的に「交代していいよ」とする方法です。この方法で実現されているマルチタスク（並行処理）を協調的マルチタスクと言い


黄色のハイライト | 位置: 3,254
この方法では、どれか1つの処理が「交代していいよ」と言わずに実行を続けると、ほかの処理にいつまで経ってもチャンスが回ってこないという問題点があります。あくまで「すべての処理が、適度な間隔で『交代していいよ』と言う」という信頼のもとで成り立っているシステム


黄色のハイライト | 位置: 3,261
「どういうときに交代するか」のもう一つの決め方は「一定時間で交代」です。この方法では、個々のプログラムよりも偉い立場のプログラム（タスクスケジューラ）が存在します。それが一定時間ごとに今走っている処理を強制的に中断させ、ほかのプログラムが処理を実行できるようにします。 ゲームのたとえで言うならば、母が15分おきに「交代しなさい！」と命令するような状況です。コンピュータの場合は人間が見ても中断されたとわからないように、たとえば20ミリ秒（0.02秒）で交代しています。 この方法で実現されているマルチタスクをプリエンプティブマルチタスクと言います。プリエンプティブとは「他人の行動を阻止するための」という意味の単語で、この手法は協調的マルチタスクと違って「止められる側のプログラムの協力」がなくても強制的に処理を止めてしまうところが特徴です（ 注


黄色のハイライト | 位置: 3,270
Windows 95、Mac OS X以降や、UNIX、LinuxなどはみんなOS自体がこの方法で複数のプログラムを並行実行してい


黄色のハイライト | 位置: 3,289
この良くない現象のことを「競合状態」（レースコンディション）と呼んだり、このプログラムを「スレッドセーフでない」と表現したりし


黄色のハイライト | 位置: 3,334
Bさんは「Aさんの書類トレー」に書類を入れてすぐに自分の仕事に戻ります。これがアクターモデルです。 処理は非同期に行われます。Aさんが書類トレーの中の書類をいつ処理するかはBさんにはわかりません。いつ処理が終わったのかも、書類に「終わったらBまで送り返してください」とでも書いておいて、いずれBさんが自分の書類トレーの中でAさんからの返事を発見したときにようやく「ああ、終わったんだな」とわかるしくみです。 この特徴が向いている処理として、まさにメッセージのやりとりそのものが挙げられます。TwitterやFacebookなどの「大量のユーザの間でのメッセージのやりとりを扱うサービス」では、おそらくアクターモデルが向いている処理が多いのでしょ


黄色のハイライト | 位置: 3,356
一つは、ファイバーやコルーチン、グリーンスレッドなどと呼ばれている手法です。スレッドがプリエンプティブなことが割り込まれてしまう原因なのだから、協調的なスレッドを作ればいいじゃないか、というアプローチです。RubyのFiberクラスや、PythonやJavaScriptのジェネレータがこれです（ 注


黄色のハイライト | 位置: 3,369
この方法にはいろいろなバリエーションがあり、ロック、ミューテックス、セマフォなどいろいろな名前がありますが、コアのコンセプトは「使用中」の札と同じです（ 注11）。「ロック」という名前のせいで「ロックを掛けておけばほかの人は入ってこられない」という勘違いをしがちですが、しかし実際は「使用中」の印を付けるだけ、印を確認しないで実行するスレッドがいると台無しになってしまいます。処理の流れの一部分だけ協調的に譲り合うしくみと言えるでしょ


黄色のハイライト | 位置: 3,411
共有されたXとYを書き換える処理AとBがあるとしましょう。Aが「Xをロックして、Yをロックする」という順でロックをかけていて、Bが「Yをロックして、Xをロックする」という順でロックをかけている場合、タイミングによっては問題が発生します。AがXをロックし、BがYをロックした状態で、お互いに相手がロックを解放するのを待ってしまうのです。 これがデッドロックと呼ばれる現象です。この問題を回避するためにプログラマは、プログラム全体でロックの順番が一貫するように気を付けなければいけません。「何をロックすべきか」だけではなく「どういう順でロックすべきか」も把握しなければいけないの


黄色のハイライト | 位置: 3,431
この問題を解決しようとしているのがトランザクショナルメモリというアプローチです（ 注13）。データベースのトランザクションの考え方をメモリにも使う方法です。コンセプトは「手元で試しにやってみて、失敗だったら最初からやりなおし、成功だったら変更を共有する」です（ 図10.2）。XやYを直接書き換えるのではなく、一時的に別のバージョンを作ってそれを書き換え、ひとかたまりの処理が終わってから反映するのがポイント


黄色のハイライト | 位置: 3,492
本章では、並行処理についての重要な概念を学びました。並行処理は昔から大勢の人を悩ませてきた問題で、いまだに多くの人を悩ませ続けている問題です。歴史を追うと、共有→非共有→共有、協調→非協調→協調、ハードウェア→ソフトウェア→ハードウェア、と振り子のように2つの解の間を揺れているように感じます。片方だけでなく両方を学び、バランス良く使うことが大事なのかもしれません


黄色のハイライト | 位置: 3,982
今では子クラスを作るときに気を付けるべきポイントとしてよく言及されるのが「リスコフの置換原則」です。 その原則はこうです──「T型のオブジェクトxに関してある属性q(x)が常に真であるとする。SがTの派生型であれば、S型のオブジェクトyの属性q(y)が常に真でなければならない。」（ 注4）。 今の文脈で言い換えると、「あるクラスTのオブジェクトについて必ず成り立つ条件があるなら、その条件はTの子クラスSのオブジェクトについても必ず成り立たなければいけない」となるでしょう（ 注5）。


黄色のハイライト | 位置: 4,193
そもそも、なぜ多重継承はこんなに問題になっているのでしょう？ 2002年に発表された、トレイトに関する論文（ 注17）では問題点がとてもよく整理されています。 クラスには2つの相反する役割があります。1つ目は「インスタンスを作るためのもの」という役割で、このためには「完結した、必要なものを全部持った、大きなクラス」である必要があります。2つ目は「再利用の単位」という役割で、このためには「機能ごとの、余計な物を持っていない、小さなクラス」である必要があります。 クラスが「インスタンスを作るためのもの」として使われているときには、再利用の単位としては大きすぎるのです。それならば、再利用の単位という役割に特化した、もっと小さい構造（トレイト＝メソッドの束）を作ればよいのではないか？──これがトレイトの考え方です。再利用の単位をクラスと別に作るという点では、Rubyのモジュールに似ていますね。何が違うのでしょ

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

勉強や仕事への取り組み方を、考え方のレベルから順を追って解説されてる感じでよかった。

学習に必要なことを一巡りできるので、どこかしら参考になりそう、実験できそうなアイデアが見つかると思います

多くの思考ツールが紹介されているため、再確認してみたい気持ちになりました。
2000年代のトレンドを総ざらいしてる感じです。
GTD は今でも形を変えて実践しています。

コーディングを支える技術――成り立ちから学ぶプログラミング作法

複数の言語を「比較」して言語の「歴史」から、プログラミング言語について学ぶ本。
僕がプログラミングをし始めたときすでに、C++もJavaもPythonもあって、その成り立ちについて気にしたことなかったので、新鮮な気持ちで読めた。確かにそういう仕組み（文法）があると便利そうやなと思えた。
もうちょい、いろんなプログラミング言語に浸かってからまた読み直してもいいかなと思う。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

速読をすればたくさん学べる、フレームワークを使う、優先順位付けをする、など、誰も疑わずに当たり前だと思っていることが、いかに考えずに行われているかがわかる。自分が、日々周りに対して感じていたけど、何がおかしいのか言語化できていなかったようなことが、的を射るように書かれていた。
自分がこの本を読んでいくらなるほど！と思ったとしても、エンジニアの場合、これをチームに浸透させる必要があるのが難しいと思う。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

学びのサイクル
1 情報収集
2 抽象化・モデル化・パターン化
3 実践・検証

緊急性分解　理論
1 質を下げられないか？
2 量を減らせないか？
3 納期をおばせないか？
4 方法を変えられないか？
5 別なもので代替できないか？
6 お金で解決できないか？
7 どうしようもないなら　やるべき
　
7つの習慣　　
▶︎私的成功を支えるもの
1 主体性を発揮する
2 目的を持って始める
3 重要事項を優先する
▶︎公的成功を支えるもの
4 WIN-WINを　かんがえる
5 理解してから理解される
6 相乗効果を発揮する
全体に対して
7 刃を研ぐ

1つのタスクのやる気を出す
1 タイムボックス（1ポモドーロ＝25分）
2 メールを閉じる

記憶を鍛える　→何度もテストする

何を学ぶべきか
卓越を目指す差別化戦略
1 他人からの知識の獲得はコストが安い
2 他人から得た知識は価値が低い
　
他人を追いかけても付加価値は生まれない。
組織の境界を跨ぐ知識の貿易商　戦略

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

情報のインプットから価値あるアウトプットまでの流れを細かく分割してそれぞれのフェーズでの効率的・効果的な手法を様々な文献から引用しつつ著者の体験を交えて解説している。情報収集のやり方、記憶のメカニズム、情報のまとめ方、アイデアの出し方など、エンジニアとしての価値を高めていく上で必要になる知識を段階的に学べてとても参考になった。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

学びについてかなり分析されていてとても参考になる。
もし、今成長するにはどうしたらいいか悩んでいるならこの本を一度読んでみるといいかも。
また、モデリングという部分でも参考になるところも多々あるので、設計にも通ずるものがあったのが良い発見だった。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

生産性アップ、整理術、発想法などのまとめ直したもの。レファレンス本なので、この本を読んで気になったことについて原典に戻るというのがいいのでは

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

いかにインプットとアウトプットを行うかという内容。少々、自分にとっては内容が学術的な部分もあり、読みづらかったというのは否めない。確かに証拠に基づいて説明するとこういう文章になるのだろう。

「学ぶ」「やる気」「記憶」などのキーワードが出てくるのだが、それぞれが大きな章となっている。

私にとっては、読書の仕方の部分が大変参考になった。中にも書いてあったが、内容全てを１度で理解しようとするのではなく、必要な時に見返しながら使えば良い一冊である気がする。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

知識のインプット、アウトプットについて広くまとまっており、どのように学ぶのかを学ぶことができた。タイトルが「エンジニアの」となっているが、エンジニア以外の人でもタメになると思う。個人的には大学の卒論執筆の前に出会いたかった。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

情報収集し、抽象化・モデル化・パターン化し、実践・検証するサイクルを回すことが大事。
抽象化は、理解する上で勝手に頭の中で実施していたりするが、改めて本書の内容を読んで、なぜ必要なのかがわかった。

自分の言葉で説明できるか？
自分の経験に基づいて具体例を挙げれるか？
は、理解度を高めるために必要なことと理解しているつもりではあるが、実践できていない。自分の中に落とし込めて知識を使い込めるようにしたい。

また、改めて全体像を掴むことの重要性がわかった。
ドキュメント精査などする際に、大雑把に把握しておくと役に立つ。これもわかっていたつもりであるが、現状、業務であまり活かせていない。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

知的生産に関する本書は、川喜田氏のKJ法をUpdateする意味で、今まで出ていた書籍の方法論の紹介や、著者の経験を交えて知的生産に関する方法論をまとめたもの。
実際問題、やってみないとわからないことは多々あるはずだというのが個人的な意見ではあるが、本書は方法論の紹介だけでなくメリットデメリットも著者なりに書かれてあるので、自分の方法論を試しながら、かつ本書で引用されている書籍などを参考にしつつ、自分の知的生産に関する方法論をUpdateしていくには良い本になっていると思う。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

IT業界のエンジニアとして働くために、常に新しい技術を学び、習得する必要性を感じている。とても参考になった。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

学びのサイクルについて図示されている面についてはわかりやすく整理できた。それだけでなく、ポモドーロ・テクニックやモデルとモジュール、概念をなぜ学ぶのかについて詳細に理由付けされていたため、忘れかけたときに見直すとちょうど良さそう。
業務についてもkj法は使用されているので、フレームワークの重要性について再認識できましたが、一方でエンジニアというよりは研究者寄りの具体例が多かったため、タイトルにそぐわない内容も結構多いかなという印象です。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

情報収集、モデル化、検証という学びのサイクルにおいて何を行うかが具体例豊富にまとめられている。エンジニアの〜 とあるが頭脳労働全般に活用できそう。

全体としては、効果的なインプット、そして情報整理による新たな関連の認識などが大きなテーマに見えた。フェーズや概念には適宜名前を付けて説明されているので一つ一つがわかりやすい。

また著者が活用しているテクニックについて具体的な名前を広く拾うことができる。この本だけでも要点は説明されているが、連鎖的に元ネタをたどるための入り口としても非常に助けになる。
個人的には読書技術についての学びがとても大きかった。

コーディングを支える技術――成り立ちから学ぶプログラミング作法

今月から始まった、今年の新入社員による新人読書会に混ぜてもらって手にした。

新人読書会のテーマ本としてはちょうどよい感じ。この本自体がかなり平易に要点を押さえて書かれているので、単に本の内容をサマってくるだけのまとめ方してくると、全く意味ない。彼ら彼女らには、そのあたりの膨らませ方の力量を期待。一方、自分は老害って言われないようにしないとな(^-^;

コーディングを支える技術――成り立ちから学ぶプログラミング作法

複数のプログラミング言語を学ぶと言語の違いでなんでこれはこうなっているんだろうか？と思うことがでてくる。言語間で共通な文法、概念を解説してくれている。ひとつの言語だけを知っているのでは面白さが分からないかも。PL/Iが出ていて、懐かしい♪と思った。

コーディングを支える技術――成り立ちから学ぶプログラミング作法

様々なプログラミング言語の歴史を紐解きながら、なぜこの文法や概念が生まれたか、を学ぶことができる。
言語の違いも面白いけど、コードを書きやすくするための概念や手法を取り入れながら成長していく過程は勉強になる。
言語拡張についていくのは大変だけどね。

この本を読んで、pythonこわいと感じたのはなぜだろう。

コーディングを支える技術――成り立ちから学ぶプログラミング作法

ブログラムがなぜ動くか、プログラミング言語の成り立ち、発展の仕方から学ぶことあ出来ました。
色々な言語が生まれた背景をしることによって、その言語の特性を理解することができると思います。リストの仕組みや継承、動的、静的型付けなどの特性を言語ごとの仕組みで丁寧に解説されていてわかりやすかったです。
個人的にコラムが言語勉強に役立ちそうとう印象が残ってます。

コーディングを支える技術――成り立ちから学ぶプログラミング作法

プログラミング言語の歴史を面白く読めた。筆者の物事をとことん調べてそれをわかりやすく説明しようと努める姿勢が読んでいて心地いい。欲を言えば関数型言語の話も知りたかった。