「理科系の作文技術」の感想

全体的な感想

原稿用紙に文章を書いていた時代の作文技術書です。ただし、考え方や基本的な技術の多くは有用です。たとえば、

重点先行主義 

 文章の「言いたいこと」を後回しにせずできるだけ先に出してしまうという考え方は今でも重要な考え方です。

あと、現代でも通用するように、PCやタブレットやスマートフォンでの作文技術を追加して欲しいです。

特に気に入った箇所

本書を読んで、気に入った箇所が沢山ありましたが、特に気に入った箇所を挙げます。

 序論は、読者を最短経路で本論にみちびき入れるようにスーッと書かなければならない

 文章の頭の部分で読むのが面倒になることがよくあるので、この部分が気に入りました。特に「スーッと書」くという表現が腑に落ちました。最短経路かつスムーズに本論に入るための文章が序論になるのです。

事実の裏付けがあってはじめて意見に説得力が生まれる。

 自分が信じるだけだったら「事実の裏付け」がなくても良いのですが、人に伝えるためには、「事実の裏付け」がある「意見」が必要だと強く思いました。

事実の裏打ちのない意見の記述は避ける

上の部分と内容的にはかぶってしまうのですが、ここも気に入りました。上手く避けるのは難しいですが、こころがけるようにしたいです。

それでも原稿はつくれ

 学会講演での心得のひとつです。講演では原稿を「読む」のではなく「話す」のだという話の流れの中で、原稿は必要ないわけではないということです。原稿はキチンとした文章にする必要はなく、メモのような形で良く、話しの流れをおさえたものが必要です。

 まとめ

 題名にあるとおり、理科系の若人を対象にした本ですが、ほとんどの部分は文章を書く人だれにでも受け入れられる内容の本です。読んでよかったと思いました。できることなら、PCやタブレット、スマートフォンなどにも対応した内容に改版して、これからも長く読める本にしてほしいものです。

続・初めてのPerl読書会に参加しました

続・初めてのPerl読書会に参加しました

内容

10章　リファレンスを使った実践的なテクニック

10.1　よりよいソート

10.2　添字を使ったソート

10.3　効率のよいソート

10.4　シュワルツ変換

10.5　シュワルツ変換を使ったマルチレベルソート

10.6　再帰的に定義されたデータ

10.7　再帰的に定義されたデータの構築

10.8　再帰的に定義されたデータの表示

10.9　再帰を避けるために

10.9.1　幅優先のソリューション

感想

Perlには組み込みのsort演算子がありますが、sort順を関数のように定義することができて便利です。デフォルトでソート対象には、$aと$bという変数が割り当てられているところがPerlっぽさを感じます。

シュワルツシュルト変換の公式はおもしろいので引用します。

my @output_data =

map {抽出} ,

sort {比較}

map {構築} ,

@input_data; 

また、Perlには末尾再帰の最適化機能がないので、再帰をしたくなったら要注意です。

 

書評「小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則 」

ビジネスを立ち上げて、経営して、運営していくことについての本。
著者たちは、会社を大きくせずに、小さな企業やグループが楽に仕事できるようなソフトウェアを開発して、確実にビジネスを成長させている実践者です。 本書はその実践から得られた経験をまとめてあります。

今は、小さなビジネスならば誰でも始められる時です。とは言え、いわゆるスタートアップというモデルは否定しています。そして、ビジネスを大きくしようと考えず、身軽を維持し、時間をより良く使った仕事をして少しずつ成長させれば良いのです。製品もゴタゴタと機能満載にするのではなく、むしろ競合製品よりも機能を少なくして本質が伝わるものにするのが良いのです。働き過ぎの否定。睡眠の重要性。小さな決断(大きな決断でない)をして常に前進する(が後で変更しても良いのです)。有名シェフに習って、知識を共有すべきです。人を雇うことについての考えや問題対応についての考えもあります。

技術者向けというより経営者向けの本です。

 

 

目次

はじめに

まず最初に

見直す

　現実の世界なんて無視しよう

　「失敗から学ぶこと」は課題評価されている

　計画は予想に過ぎない

　会社の規模なんて気にしない

　仕事依存症はバカげている

　「企業家」はもうたくさん

先に進む

　世界にささやかに貢献する

　あなたに必要なものを作る

　まずは作り始めよう

　「時間が無い」は言い訳にならない

　一線を画す

　ミッション・ステートメント・インポッシブル

　外部の資金は最終手段

　必要なものは思ったより少ない

　新興企業ではなく企業を始めよう

　売却するつもりのビジネスは廃却されることになる

　身軽でいること

進展

　制約を受け入れる

　中途半端な一つの製品でなく、よくできた半分の製品

　芯から始める

　始めのうち詳細は気にしない

　決断することで前に進む

　キュレーターになれ

　やることを減らす

　変わらないものに目を向ける

　ツールより中身が大事

　副産物を売る

　いま、始める

生産性

　書類上の合意は幻想

　やめたほうがいいものを考える

　邪魔が入る環境では生産性は上がらない

　会議は有害

　解決策はそこそこのものでかまわない

　小さな勝利を手に入れる

　ヒーローにはなるな

　睡眠をとろう

　あなたの見積もりは最悪だ

　長すぎるToDoリストは終わることがない

　小さな決断をする

競合相手

　商品をありふれたものにしない

　真似てはいけない

　けんかを売る

　競合相手以下のことしかしない

　競合相手が何をしているのかなんて気にしない

進化

　基本的に「ノー」と言おう

　顧客を（あなたよりも）成長させよう

　熱意を優先順位と混同するな

　自宅でも良いもの

　顧客の声を書き留めてはいけない

プロモーション

　無名であることを受け入れる

　顧客をつくる

　競合相手に「教える」

　料理人を見習おう

　舞台裏を公開する

　造花が好きな人はいない

　プレスリリースはスパム

　「ウォール・ストリート・ジャーナル」は忘れよう

　ドラッグの売人の方法は正しい

　マーケティングは部署ではない

　「一日にして成功」はない

人を雇う

　まずは自分自身から

　限界で人を雇う

　無用な人は雇わない

　会社を「知人のいないパーティ」にしない

　履歴書はばかばかしい

　経験年数は意味がない

　学歴は忘れること

　全員が働く

　「自分マネージャー」を雇う

　文章力のある人を雇う

　最高の逸材はどこにでも

　社員をテストドライブする

ダメージ・コントロール

　過ちへの対応は自分でひきうける

　対応の速度はすべてを変える

　誤り方を知る

　全員を最前線へ

　文句は放っておく

文化

　文化はつくるものではない

　決定は一時的なもの

　ロックスターは環境がつくる

　従業員はガキではない

　五時に帰宅させる

　大げさに反応しない

　あなたらしく話す

　四文字言葉

　「なるたけ早く」は毒

最後に

　ひらめきには賞味期限がある

書評「ハッカーと画家」

ウェブ上にある記事が大半だったためこれまで本書を読まずにいましたが読んで正解でした。ハッカーの生態とポール・グレアム氏のベンチャー起業での経験をエッセーにしてまとめた本。用語集も付いているのでエンジニアでなくとも読めると思いますし、お勧めします。

目次とWeb上の記事へのリンク

参考サイト: naoya_t:ポール・グレアムのエッセイと和訳一覧

tmux ― 端末多重化 (terminal multiplexer)

参考サイト: tmux日本語manpage

tmux ― 端末多重化 (terminal multiplexer)

コンソールを複数タブ展開して作業している人にお勧めのツールです。

一つのスクリーンに複数の仮想端末を作ります。

作業中に接続が切れても、「tmux -attach」すればプロセスは継続できます。

tmux は端末を多重化し、 1 つのスクリーンから複数の端末を作成、アクセス、制御することを可能にします。 tmux をスクリーンからデタッチしバックグランドで動作させておいて、 その後再度アタッチすることができます。

 キーバインド

アタッチしたクライアントから tmux をデフォルトでは 'C-b (Ctrl-b)' のプレフィックスキーと、 それに続くコマンドキーの組み合わせで制御することができます。

デフォルトのキーバインドのいくつか:

c 新しいウィンドウを作成。
d カレントクライアントをデタッチ。
l 直前に選択されていたウィンドウに移動。
n 次のウィンドウに切り替え。
p 前のウィンドウに切り替え。
& カレントウィンドウをkill。
, カレントウィンドウをリネーム。
? 全キーバインドを列挙。

 

セッションとは tmux に管理される疑似端末の集合の 1 つです。 各セッションはリンクする 1 つ以上のウィンドウを持ちます。 ウィンドウはスクリーン全体を占有し、 各々が独立した疑似端末である複数の矩形ペインへ分割することができます tmux のインスタンスはいくつでも同じセッションに接続することができ、 ウィンドウはいくつでも同じセッションに作成しておくことができます。 全セッションが kill されたときに tmux は終了します。

 一つのウィンドウを複数のペインに分割できる

Ctrl + b % (縦分割)
Ctrl + b " (横分割)		 ペイン分割
Ctrl + b o
Ctrl + b 矢印キー(上下左右いける)		 分割したペイン間の移動
Ctrl + b x
Ctrl + d
$ exit		 (分割した)ペインを閉じる

設定ファイル~/.tmux.conf

「[改訂第2版]Java言語プログラミングレッスン 上」の書評

「[改訂第2版]Java言語プログラミングレッスン 上」の書評

 プログラム初心者向けに丁寧な文章になっていました。私はプログラム初心者でもないので、ざっと飛しながら読みました。

オーバーフローの恐しい所は、フローしてデータがおかしな値になることだけでなく、あふれた先でデータ破壊をおこしてしまう所です。

昔の話ですが、いちアプリでオーバーフローを起したためシステムが立ちあがらなくなったことがありました。

Java言語の処理系は動作中のオーバーフローのチェックは行いません。

 Cをやっていたころは、型だけでなくポインタかどうかも確認して、何を指しているのかまで確認していましたが、最近はすっかり忘れてしまっていました。

変数を見たら型を確認しよう。

 コンピューターは指示された通りにしか動作しないという話がありますが、ハードのバグがあるとその原則すら破綻してしまうことを経験ずみです。でも普通はソースを基準に考えた方がよいです。

けれども、コンピュータに常識を期待してはいけません。すべてきちんと明示的にプログラムを書かなくてはならないのです。

 Javaのメソッドなのか、フィールドなのか意識しなければいけないのですね。おなじlengthでも、String型ではメソッドで配列ではフィールドということです。

変数sがString型のとき、その文字列の長さは.s.length()で得られます。s.lengthと表記すると、エラーになります。 配列argsの長さはargs.lengthで得られます。args.length()とカッコをつけて表記するとエラーになります。

 オブジェクト指向という考え方と実装は別の話。

「私はオブジェクト指向については理解している。でもこの言語がどのようにオブジェクト指向を具体化しているかはまだ知らない。」

Lisp Meet Up presented by Shibuya.lisp #13に行ってきました

Lisp Meet Up presented by Shibuya.lisp #13に参加してきました。

新年初のLispイベントでした。今回のお題はCommon Lispでした。
発表は2件(nitro_idiotさんとκeenさん)だけでしたが、それぞれの発表が盛り上り、会場の時間を使い切ってしまいました。
会場は、株式会社サイバーエージェント様の提供でした。
参加人数は19人でした。前回の参加人数が11人なので、かなり増えました。
実際にCommon Lispを使っている人は6～7人くらい、Clojureは12〜13人くらいで、Clojureの勢いを感じます。

発表1. New O/R Mapper for Common Lisp

nitro_idiotさんの発表は自作のO/Rマッパーについて熱く語っていました。
既存のCommon LispのO/Rマッパー「Postmodern」と比較すると、

となっており、既存のO/Rマッパーよりかなり優れた機能をもっています。
実装の話は自分には難しくてわからなかったのですが、Common Lispのオブジェクトを変更したらそれに連動してDBに自動で変更を加えてしまうという話でした。ほとんどRuby on Railsのマイグレーションみたいでした。

発表2. CIM – Common Lisp Implementation Managerを作りました

κeenさんの発表は複数のCommon Lisp処理系を扱えるツールについてでした。
rubyでいうrvmのようなもので、複数のCommon Lisp処理系を切り替えながら使用することができるコマンドライン・ツールです。
実際にデモをしながらの発表でした。
会場で発表を見てすぐにPCにインストールした人がいましたが、早速バグで動作せず、開発中だなと思わせるそのツールの動かなさかげんが、ライブ感を感じさせて、おもしろかったです。

 

懇親会では、魚メインのお店に行きました。佐野さんがκeenさんをいじるという席に同席しました。κeenさんがちょっとかわいそうでした。